{ "summary": { "snap": { "added": [], "removed": [], "diff": [] }, "deb": { "added": [ "linux-headers-6.11.0-18", "linux-headers-6.11.0-18-generic", "linux-image-6.11.0-18-generic", "linux-modules-6.11.0-18-generic", "linux-tools-6.11.0-18", "linux-tools-6.11.0-18-generic" ], "removed": [ "linux-headers-6.11.0-14", "linux-headers-6.11.0-14-generic", "linux-image-6.11.0-14-generic", "linux-modules-6.11.0-14-generic", "linux-tools-6.11.0-14", "linux-tools-6.11.0-14-generic" ], "diff": [ "bind9-dnsutils", "bind9-host", "bind9-libs:armhf", "flash-kernel", "krb5-locales", "libc-bin", "libc-dev-bin", "libc6:armhf", "libc6-dev:armhf", "libcap2:armhf", "libcap2-bin", "libgnutls30t64:armhf", "libgssapi-krb5-2:armhf", "libiniparser1:armhf", "libk5crypto3:armhf", "libkrb5-3:armhf", "libkrb5support0:armhf", "libldap-common", "libldap2:armhf", "libpam-cap:armhf", "libpython3.12-minimal:armhf", "libpython3.12-stdlib:armhf", "libpython3.12t64:armhf", "libssl3t64:armhf", "libtasn1-6:armhf", "linux-headers-generic", "linux-headers-virtual", "linux-image-virtual", "linux-libc-dev:armhf", "linux-tools-common", "linux-virtual", "locales", "openssh-client", "openssh-server", "openssh-sftp-server", "openssl", "python3-jinja2", "python3.12", "python3.12-gdbm", "python3.12-minimal", "rsync", "tzdata", "vim", "vim-common", "vim-runtime", "vim-tiny", "xxd" ] } }, "diff": { "deb": [ { "name": "bind9-dnsutils", "from_version": { "source_package_name": "bind9", "source_package_version": "1:9.20.0-2ubuntu3", "version": "1:9.20.0-2ubuntu3" }, "to_version": { "source_package_name": "bind9", "source_package_version": "1:9.20.0-2ubuntu3.1", "version": "1:9.20.0-2ubuntu3.1" }, "cves": [ { "cve": "CVE-2024-11187", "url": "https://ubuntu.com/security/CVE-2024-11187", "cve_description": "It is possible to construct a zone such that some queries to it will generate responses containing numerous records in the Additional section. An attacker sending many such queries can cause either the authoritative server itself or an independent resolver to use disproportionate resources processing the queries. Zones will usually need to have been deliberately crafted to attack this exposure. This issue affects BIND 9 versions 9.11.0 through 9.11.37, 9.16.0 through 9.16.50, 9.18.0 through 9.18.32, 9.20.0 through 9.20.4, 9.21.0 through 9.21.3, 9.11.3-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.50-S1, and 9.18.11-S1 through 9.18.32-S1.", "cve_priority": "medium", "cve_public_date": "2025-01-29 22:15:00 UTC" }, { "cve": "CVE-2024-12705", "url": "https://ubuntu.com/security/CVE-2024-12705", "cve_description": "Clients using DNS-over-HTTPS (DoH) can exhaust a DNS resolver's CPU and/or memory by flooding it with crafted valid or invalid HTTP/2 traffic. This issue affects BIND 9 versions 9.18.0 through 9.18.32, 9.20.0 through 9.20.4, 9.21.0 through 9.21.3, and 9.18.11-S1 through 9.18.32-S1.", "cve_priority": "medium", "cve_public_date": "2025-01-29 22:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2024-11187", "url": "https://ubuntu.com/security/CVE-2024-11187", "cve_description": "It is possible to construct a zone such that some queries to it will generate responses containing numerous records in the Additional section. An attacker sending many such queries can cause either the authoritative server itself or an independent resolver to use disproportionate resources processing the queries. Zones will usually need to have been deliberately crafted to attack this exposure. This issue affects BIND 9 versions 9.11.0 through 9.11.37, 9.16.0 through 9.16.50, 9.18.0 through 9.18.32, 9.20.0 through 9.20.4, 9.21.0 through 9.21.3, 9.11.3-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.50-S1, and 9.18.11-S1 through 9.18.32-S1.", "cve_priority": "medium", "cve_public_date": "2025-01-29 22:15:00 UTC" }, { "cve": "CVE-2024-12705", "url": "https://ubuntu.com/security/CVE-2024-12705", "cve_description": "Clients using DNS-over-HTTPS (DoH) can exhaust a DNS resolver's CPU and/or memory by flooding it with crafted valid or invalid HTTP/2 traffic. This issue affects BIND 9 versions 9.18.0 through 9.18.32, 9.20.0 through 9.20.4, 9.21.0 through 9.21.3, and 9.18.11-S1 through 9.18.32-S1.", "cve_priority": "medium", "cve_public_date": "2025-01-29 22:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Many records in the additional section cause CPU", " exhaustion", " - debian/patches/CVE-2024-11187.patch: limit the additional processing", " for large RDATA sets in bin/tests/*, lib/dns/include/dns/rdataset.h,", " lib/dns/qpzone.c, lib/dns/rbt-zonedb.c, lib/dns/rdataset.c,", " lib/dns/resolver.c, lib/ns/query.c.", " - CVE-2024-11187", " * SECURITY UPDATE: DNS-over-HTTPS implementation suffers from multiple", " issues under heavy query load", " - debian/patches/CVE-2024-12705.patch: fix flooding issues in", " lib/isc/netmgr/http.c, lib/isc/netmgr/netmgr-int.h,", " lib/isc/netmgr/proxystream.c, lib/isc/netmgr/streamdns.c,", " lib/isc/netmgr/tcp.c, lib/isc/netmgr/tlsstream.c, ", " - CVE-2024-12705", "" ], "package": "bind9", "version": "1:9.20.0-2ubuntu3.1", "urgency": "medium", "distributions": "oracular-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Tue, 28 Jan 2025 09:18:29 -0500" } ], "notes": null }, { "name": "bind9-host", "from_version": { "source_package_name": "bind9", "source_package_version": "1:9.20.0-2ubuntu3", "version": "1:9.20.0-2ubuntu3" }, "to_version": { "source_package_name": "bind9", "source_package_version": "1:9.20.0-2ubuntu3.1", "version": "1:9.20.0-2ubuntu3.1" }, "cves": [ { "cve": "CVE-2024-11187", "url": "https://ubuntu.com/security/CVE-2024-11187", "cve_description": "It is possible to construct a zone such that some queries to it will generate responses containing numerous records in the Additional section. An attacker sending many such queries can cause either the authoritative server itself or an independent resolver to use disproportionate resources processing the queries. Zones will usually need to have been deliberately crafted to attack this exposure. This issue affects BIND 9 versions 9.11.0 through 9.11.37, 9.16.0 through 9.16.50, 9.18.0 through 9.18.32, 9.20.0 through 9.20.4, 9.21.0 through 9.21.3, 9.11.3-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.50-S1, and 9.18.11-S1 through 9.18.32-S1.", "cve_priority": "medium", "cve_public_date": "2025-01-29 22:15:00 UTC" }, { "cve": "CVE-2024-12705", "url": "https://ubuntu.com/security/CVE-2024-12705", "cve_description": "Clients using DNS-over-HTTPS (DoH) can exhaust a DNS resolver's CPU and/or memory by flooding it with crafted valid or invalid HTTP/2 traffic. This issue affects BIND 9 versions 9.18.0 through 9.18.32, 9.20.0 through 9.20.4, 9.21.0 through 9.21.3, and 9.18.11-S1 through 9.18.32-S1.", "cve_priority": "medium", "cve_public_date": "2025-01-29 22:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2024-11187", "url": "https://ubuntu.com/security/CVE-2024-11187", "cve_description": "It is possible to construct a zone such that some queries to it will generate responses containing numerous records in the Additional section. An attacker sending many such queries can cause either the authoritative server itself or an independent resolver to use disproportionate resources processing the queries. Zones will usually need to have been deliberately crafted to attack this exposure. This issue affects BIND 9 versions 9.11.0 through 9.11.37, 9.16.0 through 9.16.50, 9.18.0 through 9.18.32, 9.20.0 through 9.20.4, 9.21.0 through 9.21.3, 9.11.3-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.50-S1, and 9.18.11-S1 through 9.18.32-S1.", "cve_priority": "medium", "cve_public_date": "2025-01-29 22:15:00 UTC" }, { "cve": "CVE-2024-12705", "url": "https://ubuntu.com/security/CVE-2024-12705", "cve_description": "Clients using DNS-over-HTTPS (DoH) can exhaust a DNS resolver's CPU and/or memory by flooding it with crafted valid or invalid HTTP/2 traffic. This issue affects BIND 9 versions 9.18.0 through 9.18.32, 9.20.0 through 9.20.4, 9.21.0 through 9.21.3, and 9.18.11-S1 through 9.18.32-S1.", "cve_priority": "medium", "cve_public_date": "2025-01-29 22:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Many records in the additional section cause CPU", " exhaustion", " - debian/patches/CVE-2024-11187.patch: limit the additional processing", " for large RDATA sets in bin/tests/*, lib/dns/include/dns/rdataset.h,", " lib/dns/qpzone.c, lib/dns/rbt-zonedb.c, lib/dns/rdataset.c,", " lib/dns/resolver.c, lib/ns/query.c.", " - CVE-2024-11187", " * SECURITY UPDATE: DNS-over-HTTPS implementation suffers from multiple", " issues under heavy query load", " - debian/patches/CVE-2024-12705.patch: fix flooding issues in", " lib/isc/netmgr/http.c, lib/isc/netmgr/netmgr-int.h,", " lib/isc/netmgr/proxystream.c, lib/isc/netmgr/streamdns.c,", " lib/isc/netmgr/tcp.c, lib/isc/netmgr/tlsstream.c, ", " - CVE-2024-12705", "" ], "package": "bind9", "version": "1:9.20.0-2ubuntu3.1", "urgency": "medium", "distributions": "oracular-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Tue, 28 Jan 2025 09:18:29 -0500" } ], "notes": null }, { "name": "bind9-libs:armhf", "from_version": { "source_package_name": "bind9", "source_package_version": "1:9.20.0-2ubuntu3", "version": "1:9.20.0-2ubuntu3" }, "to_version": { "source_package_name": "bind9", "source_package_version": "1:9.20.0-2ubuntu3.1", "version": "1:9.20.0-2ubuntu3.1" }, "cves": [ { "cve": "CVE-2024-11187", "url": "https://ubuntu.com/security/CVE-2024-11187", "cve_description": "It is possible to construct a zone such that some queries to it will generate responses containing numerous records in the Additional section. An attacker sending many such queries can cause either the authoritative server itself or an independent resolver to use disproportionate resources processing the queries. Zones will usually need to have been deliberately crafted to attack this exposure. This issue affects BIND 9 versions 9.11.0 through 9.11.37, 9.16.0 through 9.16.50, 9.18.0 through 9.18.32, 9.20.0 through 9.20.4, 9.21.0 through 9.21.3, 9.11.3-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.50-S1, and 9.18.11-S1 through 9.18.32-S1.", "cve_priority": "medium", "cve_public_date": "2025-01-29 22:15:00 UTC" }, { "cve": "CVE-2024-12705", "url": "https://ubuntu.com/security/CVE-2024-12705", "cve_description": "Clients using DNS-over-HTTPS (DoH) can exhaust a DNS resolver's CPU and/or memory by flooding it with crafted valid or invalid HTTP/2 traffic. This issue affects BIND 9 versions 9.18.0 through 9.18.32, 9.20.0 through 9.20.4, 9.21.0 through 9.21.3, and 9.18.11-S1 through 9.18.32-S1.", "cve_priority": "medium", "cve_public_date": "2025-01-29 22:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2024-11187", "url": "https://ubuntu.com/security/CVE-2024-11187", "cve_description": "It is possible to construct a zone such that some queries to it will generate responses containing numerous records in the Additional section. An attacker sending many such queries can cause either the authoritative server itself or an independent resolver to use disproportionate resources processing the queries. Zones will usually need to have been deliberately crafted to attack this exposure. This issue affects BIND 9 versions 9.11.0 through 9.11.37, 9.16.0 through 9.16.50, 9.18.0 through 9.18.32, 9.20.0 through 9.20.4, 9.21.0 through 9.21.3, 9.11.3-S1 through 9.11.37-S1, 9.16.8-S1 through 9.16.50-S1, and 9.18.11-S1 through 9.18.32-S1.", "cve_priority": "medium", "cve_public_date": "2025-01-29 22:15:00 UTC" }, { "cve": "CVE-2024-12705", "url": "https://ubuntu.com/security/CVE-2024-12705", "cve_description": "Clients using DNS-over-HTTPS (DoH) can exhaust a DNS resolver's CPU and/or memory by flooding it with crafted valid or invalid HTTP/2 traffic. This issue affects BIND 9 versions 9.18.0 through 9.18.32, 9.20.0 through 9.20.4, 9.21.0 through 9.21.3, and 9.18.11-S1 through 9.18.32-S1.", "cve_priority": "medium", "cve_public_date": "2025-01-29 22:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Many records in the additional section cause CPU", " exhaustion", " - debian/patches/CVE-2024-11187.patch: limit the additional processing", " for large RDATA sets in bin/tests/*, lib/dns/include/dns/rdataset.h,", " lib/dns/qpzone.c, lib/dns/rbt-zonedb.c, lib/dns/rdataset.c,", " lib/dns/resolver.c, lib/ns/query.c.", " - CVE-2024-11187", " * SECURITY UPDATE: DNS-over-HTTPS implementation suffers from multiple", " issues under heavy query load", " - debian/patches/CVE-2024-12705.patch: fix flooding issues in", " lib/isc/netmgr/http.c, lib/isc/netmgr/netmgr-int.h,", " lib/isc/netmgr/proxystream.c, lib/isc/netmgr/streamdns.c,", " lib/isc/netmgr/tcp.c, lib/isc/netmgr/tlsstream.c, ", " - CVE-2024-12705", "" ], "package": "bind9", "version": "1:9.20.0-2ubuntu3.1", "urgency": "medium", "distributions": "oracular-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Tue, 28 Jan 2025 09:18:29 -0500" } ], "notes": null }, { "name": "flash-kernel", "from_version": { "source_package_name": "flash-kernel", "source_package_version": "3.107ubuntu13~24.10.1", "version": "3.107ubuntu13~24.10.1" }, "to_version": { "source_package_name": "flash-kernel", "source_package_version": "3.107ubuntu13~24.10.2", "version": "3.107ubuntu13~24.10.2" }, "cves": [], "launchpad_bugs_fixed": [ 2093200, 2092216 ], "changes": [ { "cves": [], "log": [ "", " [ Heinrich Schuchardt ]", " * db/all.db: Add more RISC-V boards (LP: #2093200)", " - Add entry for DeepComputing FML13V01", " - Add entry for Pine64 Star64", "", " [ Dave Jones ]", " * db/all.db: Add entry for Raspberry Pi 500 (LP: #2092216)", "" ], "package": "flash-kernel", "version": "3.107ubuntu13~24.10.2", "urgency": "medium", "distributions": "oracular", "launchpad_bugs_fixed": [ 2093200, 2092216 ], "author": "Dave Jones ", "date": "Thu, 23 Jan 2025 15:40:01 +0000" } ], "notes": null }, { "name": "krb5-locales", "from_version": { "source_package_name": "krb5", "source_package_version": "1.21.3-3", "version": "1.21.3-3" }, "to_version": { "source_package_name": "krb5", "source_package_version": "1.21.3-3ubuntu0.1", "version": "1.21.3-3ubuntu0.1" }, "cves": [ { "cve": "CVE-2024-3596", "url": "https://ubuntu.com/security/CVE-2024-3596", "cve_description": "RADIUS Protocol under RFC 2865 is susceptible to forgery attacks by a local attacker who can modify any valid Response (Access-Accept, Access-Reject, or Access-Challenge) to any other response using a chosen-prefix collision attack against MD5 Response Authenticator signature.", "cve_priority": "medium", "cve_public_date": "2024-07-09 12:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2024-3596", "url": "https://ubuntu.com/security/CVE-2024-3596", "cve_description": "RADIUS Protocol under RFC 2865 is susceptible to forgery attacks by a local attacker who can modify any valid Response (Access-Accept, Access-Reject, or Access-Challenge) to any other response using a chosen-prefix collision attack against MD5 Response Authenticator signature.", "cve_priority": "medium", "cve_public_date": "2024-07-09 12:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Use of MD5-based message authentication over plaintext", " communications could lead to forgery attacks. ", " - debian/patches/CVE-2024-3596.patch: Secure Response Authenticator ", " by adding support for the Message-Authenticator attribute in non-EAP ", " authentication methods. ", " - CVE-2024-3596$ ", " * Update libk5crypto3 symbols: add k5_hmac_md5 symbol. ", "" ], "package": "krb5", "version": "1.21.3-3ubuntu0.1", "urgency": "medium", "distributions": "oracular-security", "launchpad_bugs_fixed": [], "author": "Nicolas Campuzano Jimenez ", "date": "Tue, 04 Feb 2025 10:56:13 -0500" } ], "notes": null }, { "name": "libc-bin", "from_version": { "source_package_name": "glibc", "source_package_version": "2.40-1ubuntu3", "version": "2.40-1ubuntu3" }, "to_version": { "source_package_name": "glibc", "source_package_version": "2.40-1ubuntu3.1", "version": "2.40-1ubuntu3.1" }, "cves": [ { "cve": "CVE-2025-0395", "url": "https://ubuntu.com/security/CVE-2025-0395", "cve_description": "When the assert() function in the GNU C Library versions 2.13 to 2.40 fails, it does not allocate enough space for the assertion failure message string and size information, which may lead to a buffer overflow if the message string size aligns to page size.", "cve_priority": "medium", "cve_public_date": "2025-01-22 13:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2025-0395", "url": "https://ubuntu.com/security/CVE-2025-0395", "cve_description": "When the assert() function in the GNU C Library versions 2.13 to 2.40 fails, it does not allocate enough space for the assertion failure message string and size information, which may lead to a buffer overflow if the message string size aligns to page size.", "cve_priority": "medium", "cve_public_date": "2025-01-22 13:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Buffer overflow in the assert function.", " - debian/patches/any/CVE-2025-0395.patch: Change total to ALIGN_UP", " calculation and include libc-pointer-arith.h in assert/assert.c and", " sysdeps/posix/libc_fatal.c.", " - CVE-2025-0395", "" ], "package": "glibc", "version": "2.40-1ubuntu3.1", "urgency": "medium", "distributions": "oracular-security", "launchpad_bugs_fixed": [], "author": "Hlib Korzhynskyy ", "date": "Mon, 27 Jan 2025 15:10:33 -0330" } ], "notes": null }, { "name": "libc-dev-bin", "from_version": { "source_package_name": "glibc", "source_package_version": "2.40-1ubuntu3", "version": "2.40-1ubuntu3" }, "to_version": { "source_package_name": "glibc", "source_package_version": "2.40-1ubuntu3.1", "version": "2.40-1ubuntu3.1" }, "cves": [ { "cve": "CVE-2025-0395", "url": "https://ubuntu.com/security/CVE-2025-0395", "cve_description": "When the assert() function in the GNU C Library versions 2.13 to 2.40 fails, it does not allocate enough space for the assertion failure message string and size information, which may lead to a buffer overflow if the message string size aligns to page size.", "cve_priority": "medium", "cve_public_date": "2025-01-22 13:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2025-0395", "url": "https://ubuntu.com/security/CVE-2025-0395", "cve_description": "When the assert() function in the GNU C Library versions 2.13 to 2.40 fails, it does not allocate enough space for the assertion failure message string and size information, which may lead to a buffer overflow if the message string size aligns to page size.", "cve_priority": "medium", "cve_public_date": "2025-01-22 13:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Buffer overflow in the assert function.", " - debian/patches/any/CVE-2025-0395.patch: Change total to ALIGN_UP", " calculation and include libc-pointer-arith.h in assert/assert.c and", " sysdeps/posix/libc_fatal.c.", " - CVE-2025-0395", "" ], "package": "glibc", "version": "2.40-1ubuntu3.1", "urgency": "medium", "distributions": "oracular-security", "launchpad_bugs_fixed": [], "author": "Hlib Korzhynskyy ", "date": "Mon, 27 Jan 2025 15:10:33 -0330" } ], "notes": null }, { "name": "libc6:armhf", "from_version": { "source_package_name": "glibc", "source_package_version": "2.40-1ubuntu3", "version": "2.40-1ubuntu3" }, "to_version": { "source_package_name": "glibc", "source_package_version": "2.40-1ubuntu3.1", "version": "2.40-1ubuntu3.1" }, "cves": [ { "cve": "CVE-2025-0395", "url": "https://ubuntu.com/security/CVE-2025-0395", "cve_description": "When the assert() function in the GNU C Library versions 2.13 to 2.40 fails, it does not allocate enough space for the assertion failure message string and size information, which may lead to a buffer overflow if the message string size aligns to page size.", "cve_priority": "medium", "cve_public_date": "2025-01-22 13:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2025-0395", "url": "https://ubuntu.com/security/CVE-2025-0395", "cve_description": "When the assert() function in the GNU C Library versions 2.13 to 2.40 fails, it does not allocate enough space for the assertion failure message string and size information, which may lead to a buffer overflow if the message string size aligns to page size.", "cve_priority": "medium", "cve_public_date": "2025-01-22 13:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Buffer overflow in the assert function.", " - debian/patches/any/CVE-2025-0395.patch: Change total to ALIGN_UP", " calculation and include libc-pointer-arith.h in assert/assert.c and", " sysdeps/posix/libc_fatal.c.", " - CVE-2025-0395", "" ], "package": "glibc", "version": "2.40-1ubuntu3.1", "urgency": "medium", "distributions": "oracular-security", "launchpad_bugs_fixed": [], "author": "Hlib Korzhynskyy ", "date": "Mon, 27 Jan 2025 15:10:33 -0330" } ], "notes": null }, { "name": "libc6-dev:armhf", "from_version": { "source_package_name": "glibc", "source_package_version": "2.40-1ubuntu3", "version": "2.40-1ubuntu3" }, "to_version": { "source_package_name": "glibc", "source_package_version": "2.40-1ubuntu3.1", "version": "2.40-1ubuntu3.1" }, "cves": [ { "cve": "CVE-2025-0395", "url": "https://ubuntu.com/security/CVE-2025-0395", "cve_description": "When the assert() function in the GNU C Library versions 2.13 to 2.40 fails, it does not allocate enough space for the assertion failure message string and size information, which may lead to a buffer overflow if the message string size aligns to page size.", "cve_priority": "medium", "cve_public_date": "2025-01-22 13:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2025-0395", "url": "https://ubuntu.com/security/CVE-2025-0395", "cve_description": "When the assert() function in the GNU C Library versions 2.13 to 2.40 fails, it does not allocate enough space for the assertion failure message string and size information, which may lead to a buffer overflow if the message string size aligns to page size.", "cve_priority": "medium", "cve_public_date": "2025-01-22 13:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Buffer overflow in the assert function.", " - debian/patches/any/CVE-2025-0395.patch: Change total to ALIGN_UP", " calculation and include libc-pointer-arith.h in assert/assert.c and", " sysdeps/posix/libc_fatal.c.", " - CVE-2025-0395", "" ], "package": "glibc", "version": "2.40-1ubuntu3.1", "urgency": "medium", "distributions": "oracular-security", "launchpad_bugs_fixed": [], "author": "Hlib Korzhynskyy ", "date": "Mon, 27 Jan 2025 15:10:33 -0330" } ], "notes": null }, { "name": "libcap2:armhf", "from_version": { "source_package_name": "libcap2", "source_package_version": "1:2.66-5ubuntu3", "version": "1:2.66-5ubuntu3" }, "to_version": { "source_package_name": "libcap2", "source_package_version": "1:2.66-5ubuntu3.1", "version": "1:2.66-5ubuntu3.1" }, "cves": [ { "cve": "CVE-2025-1390", "url": "https://ubuntu.com/security/CVE-2025-1390", "cve_description": "The PAM module pam_cap.so of libcap configuration supports group names starting with “@”, during actual parsing, configurations not starting with “@” are incorrectly recognized as group names. This may result in nonintended users being granted an inherited capability set, potentially leading to security risks. Attackers can exploit this vulnerability to achieve local privilege escalation on systems where /etc/security/capability.conf is used to configure user inherited privileges by constructing specific usernames.", "cve_priority": "medium", "cve_public_date": "2025-02-20" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2025-1390", "url": "https://ubuntu.com/security/CVE-2025-1390", "cve_description": "The PAM module pam_cap.so of libcap configuration supports group names starting with “@”, during actual parsing, configurations not starting with “@” are incorrectly recognized as group names. This may result in nonintended users being granted an inherited capability set, potentially leading to security risks. Attackers can exploit this vulnerability to achieve local privilege escalation on systems where /etc/security/capability.conf is used to configure user inherited privileges by constructing specific usernames.", "cve_priority": "medium", "cve_public_date": "2025-02-20" } ], "log": [ "", " * SECURITY UPDATE: incorrect group name handling", " - debian/patches/CVE-2025-1390-1.patch: fix potential configuration", " parsing error in pam_cap/pam_cap.c.", " - debian/patches/CVE-2025-1390-2.patch: add a test for bad group prefix", " in pam_cap/sudotest.conf.", " - CVE-2025-1390", "" ], "package": "libcap2", "version": "1:2.66-5ubuntu3.1", "urgency": "medium", "distributions": "oracular-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Thu, 20 Feb 2025 10:47:43 -0500" } ], "notes": null }, { "name": "libcap2-bin", "from_version": { "source_package_name": "libcap2", "source_package_version": "1:2.66-5ubuntu3", "version": "1:2.66-5ubuntu3" }, "to_version": { "source_package_name": "libcap2", "source_package_version": "1:2.66-5ubuntu3.1", "version": "1:2.66-5ubuntu3.1" }, "cves": [ { "cve": "CVE-2025-1390", "url": "https://ubuntu.com/security/CVE-2025-1390", "cve_description": "The PAM module pam_cap.so of libcap configuration supports group names starting with “@”, during actual parsing, configurations not starting with “@” are incorrectly recognized as group names. This may result in nonintended users being granted an inherited capability set, potentially leading to security risks. Attackers can exploit this vulnerability to achieve local privilege escalation on systems where /etc/security/capability.conf is used to configure user inherited privileges by constructing specific usernames.", "cve_priority": "medium", "cve_public_date": "2025-02-20" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2025-1390", "url": "https://ubuntu.com/security/CVE-2025-1390", "cve_description": "The PAM module pam_cap.so of libcap configuration supports group names starting with “@”, during actual parsing, configurations not starting with “@” are incorrectly recognized as group names. This may result in nonintended users being granted an inherited capability set, potentially leading to security risks. Attackers can exploit this vulnerability to achieve local privilege escalation on systems where /etc/security/capability.conf is used to configure user inherited privileges by constructing specific usernames.", "cve_priority": "medium", "cve_public_date": "2025-02-20" } ], "log": [ "", " * SECURITY UPDATE: incorrect group name handling", " - debian/patches/CVE-2025-1390-1.patch: fix potential configuration", " parsing error in pam_cap/pam_cap.c.", " - debian/patches/CVE-2025-1390-2.patch: add a test for bad group prefix", " in pam_cap/sudotest.conf.", " - CVE-2025-1390", "" ], "package": "libcap2", "version": "1:2.66-5ubuntu3.1", "urgency": "medium", "distributions": "oracular-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Thu, 20 Feb 2025 10:47:43 -0500" } ], "notes": null }, { "name": "libgnutls30t64:armhf", "from_version": { "source_package_name": "gnutls28", "source_package_version": "3.8.6-2ubuntu1", "version": "3.8.6-2ubuntu1" }, "to_version": { "source_package_name": "gnutls28", "source_package_version": "3.8.6-2ubuntu1.1", "version": "3.8.6-2ubuntu1.1" }, "cves": [ { "cve": "CVE-2024-12243", "url": "https://ubuntu.com/security/CVE-2024-12243", "cve_description": "A flaw was found in GnuTLS, which relies on libtasn1 for ASN.1 data processing. Due to an inefficient algorithm in libtasn1, decoding certain DER-encoded certificate data can take excessive time, leading to increased resource consumption. This flaw allows a remote attacker to send a specially crafted certificate, causing GnuTLS to become unresponsive or slow, resulting in a denial-of-service condition.", "cve_priority": "medium", "cve_public_date": "2025-02-10 16:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2024-12243", "url": "https://ubuntu.com/security/CVE-2024-12243", "cve_description": "A flaw was found in GnuTLS, which relies on libtasn1 for ASN.1 data processing. Due to an inefficient algorithm in libtasn1, decoding certain DER-encoded certificate data can take excessive time, leading to increased resource consumption. This flaw allows a remote attacker to send a specially crafted certificate, causing GnuTLS to become unresponsive or slow, resulting in a denial-of-service condition.", "cve_priority": "medium", "cve_public_date": "2025-02-10 16:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: resource consumption issue when decoding DER-encoded", " certificate data", " - debian/patches/CVE-2024-12243.patch: optimize name constraints", " processing in lib/datum.c, lib/x509/name_constraints.c,", " lib/x509/x509_ext.c, lib/x509/x509_ext_int.h, lib/x509/x509_int.h.", " - CVE-2024-12243", "" ], "package": "gnutls28", "version": "3.8.6-2ubuntu1.1", "urgency": "medium", "distributions": "oracular-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Wed, 12 Feb 2025 09:52:27 -0500" } ], "notes": null }, { "name": "libgssapi-krb5-2:armhf", "from_version": { "source_package_name": "krb5", "source_package_version": "1.21.3-3", "version": "1.21.3-3" }, "to_version": { "source_package_name": "krb5", "source_package_version": "1.21.3-3ubuntu0.1", "version": "1.21.3-3ubuntu0.1" }, "cves": [ { "cve": "CVE-2024-3596", "url": "https://ubuntu.com/security/CVE-2024-3596", "cve_description": "RADIUS Protocol under RFC 2865 is susceptible to forgery attacks by a local attacker who can modify any valid Response (Access-Accept, Access-Reject, or Access-Challenge) to any other response using a chosen-prefix collision attack against MD5 Response Authenticator signature.", "cve_priority": "medium", "cve_public_date": "2024-07-09 12:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2024-3596", "url": "https://ubuntu.com/security/CVE-2024-3596", "cve_description": "RADIUS Protocol under RFC 2865 is susceptible to forgery attacks by a local attacker who can modify any valid Response (Access-Accept, Access-Reject, or Access-Challenge) to any other response using a chosen-prefix collision attack against MD5 Response Authenticator signature.", "cve_priority": "medium", "cve_public_date": "2024-07-09 12:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Use of MD5-based message authentication over plaintext", " communications could lead to forgery attacks. ", " - debian/patches/CVE-2024-3596.patch: Secure Response Authenticator ", " by adding support for the Message-Authenticator attribute in non-EAP ", " authentication methods. ", " - CVE-2024-3596$ ", " * Update libk5crypto3 symbols: add k5_hmac_md5 symbol. ", "" ], "package": "krb5", "version": "1.21.3-3ubuntu0.1", "urgency": "medium", "distributions": "oracular-security", "launchpad_bugs_fixed": [], "author": "Nicolas Campuzano Jimenez ", "date": "Tue, 04 Feb 2025 10:56:13 -0500" } ], "notes": null }, { "name": "libiniparser1:armhf", "from_version": { "source_package_name": "iniparser", "source_package_version": "4.2.1-1", "version": "4.2.1-1" }, "to_version": { "source_package_name": "iniparser", "source_package_version": "4.2.1-1ubuntu0.1", "version": "4.2.1-1ubuntu0.1" }, "cves": [ { "cve": "CVE-2025-0633", "url": "https://ubuntu.com/security/CVE-2025-0633", "cve_description": "Heap-based Buffer Overflow vulnerability in iniparser_dumpsection_ini() in iniparser allows attacker to read out of bound memory", "cve_priority": "medium", "cve_public_date": "2025-02-19 07:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2025-0633", "url": "https://ubuntu.com/security/CVE-2025-0633", "cve_description": "Heap-based Buffer Overflow vulnerability in iniparser_dumpsection_ini() in iniparser allows attacker to read out of bound memory", "cve_priority": "medium", "cve_public_date": "2025-02-19 07:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: heap overflow in iniparser_dumpsection_ini()", " - debian/patches/CVE-2025-0633-1.patch: return if name doesn't fit in", " buffer in src/iniparser.c.", " - debian/patches/CVE-2025-0633-2.patch: add test to", " test/test_iniparser.c.", " - CVE-2025-0633", "" ], "package": "iniparser", "version": "4.2.1-1ubuntu0.1", "urgency": "medium", "distributions": "oracular-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Fri, 21 Feb 2025 12:44:47 -0500" } ], "notes": null }, { "name": "libk5crypto3:armhf", "from_version": { "source_package_name": "krb5", "source_package_version": "1.21.3-3", "version": "1.21.3-3" }, "to_version": { "source_package_name": "krb5", "source_package_version": "1.21.3-3ubuntu0.1", "version": "1.21.3-3ubuntu0.1" }, "cves": [ { "cve": "CVE-2024-3596", "url": "https://ubuntu.com/security/CVE-2024-3596", "cve_description": "RADIUS Protocol under RFC 2865 is susceptible to forgery attacks by a local attacker who can modify any valid Response (Access-Accept, Access-Reject, or Access-Challenge) to any other response using a chosen-prefix collision attack against MD5 Response Authenticator signature.", "cve_priority": "medium", "cve_public_date": "2024-07-09 12:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2024-3596", "url": "https://ubuntu.com/security/CVE-2024-3596", "cve_description": "RADIUS Protocol under RFC 2865 is susceptible to forgery attacks by a local attacker who can modify any valid Response (Access-Accept, Access-Reject, or Access-Challenge) to any other response using a chosen-prefix collision attack against MD5 Response Authenticator signature.", "cve_priority": "medium", "cve_public_date": "2024-07-09 12:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Use of MD5-based message authentication over plaintext", " communications could lead to forgery attacks. ", " - debian/patches/CVE-2024-3596.patch: Secure Response Authenticator ", " by adding support for the Message-Authenticator attribute in non-EAP ", " authentication methods. ", " - CVE-2024-3596$ ", " * Update libk5crypto3 symbols: add k5_hmac_md5 symbol. ", "" ], "package": "krb5", "version": "1.21.3-3ubuntu0.1", "urgency": "medium", "distributions": "oracular-security", "launchpad_bugs_fixed": [], "author": "Nicolas Campuzano Jimenez ", "date": "Tue, 04 Feb 2025 10:56:13 -0500" } ], "notes": null }, { "name": "libkrb5-3:armhf", "from_version": { "source_package_name": "krb5", "source_package_version": "1.21.3-3", "version": "1.21.3-3" }, "to_version": { "source_package_name": "krb5", "source_package_version": "1.21.3-3ubuntu0.1", "version": "1.21.3-3ubuntu0.1" }, "cves": [ { "cve": "CVE-2024-3596", "url": "https://ubuntu.com/security/CVE-2024-3596", "cve_description": "RADIUS Protocol under RFC 2865 is susceptible to forgery attacks by a local attacker who can modify any valid Response (Access-Accept, Access-Reject, or Access-Challenge) to any other response using a chosen-prefix collision attack against MD5 Response Authenticator signature.", "cve_priority": "medium", "cve_public_date": "2024-07-09 12:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2024-3596", "url": "https://ubuntu.com/security/CVE-2024-3596", "cve_description": "RADIUS Protocol under RFC 2865 is susceptible to forgery attacks by a local attacker who can modify any valid Response (Access-Accept, Access-Reject, or Access-Challenge) to any other response using a chosen-prefix collision attack against MD5 Response Authenticator signature.", "cve_priority": "medium", "cve_public_date": "2024-07-09 12:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Use of MD5-based message authentication over plaintext", " communications could lead to forgery attacks. ", " - debian/patches/CVE-2024-3596.patch: Secure Response Authenticator ", " by adding support for the Message-Authenticator attribute in non-EAP ", " authentication methods. ", " - CVE-2024-3596$ ", " * Update libk5crypto3 symbols: add k5_hmac_md5 symbol. ", "" ], "package": "krb5", "version": "1.21.3-3ubuntu0.1", "urgency": "medium", "distributions": "oracular-security", "launchpad_bugs_fixed": [], "author": "Nicolas Campuzano Jimenez ", "date": "Tue, 04 Feb 2025 10:56:13 -0500" } ], "notes": null }, { "name": "libkrb5support0:armhf", "from_version": { "source_package_name": "krb5", "source_package_version": "1.21.3-3", "version": "1.21.3-3" }, "to_version": { "source_package_name": "krb5", "source_package_version": "1.21.3-3ubuntu0.1", "version": "1.21.3-3ubuntu0.1" }, "cves": [ { "cve": "CVE-2024-3596", "url": "https://ubuntu.com/security/CVE-2024-3596", "cve_description": "RADIUS Protocol under RFC 2865 is susceptible to forgery attacks by a local attacker who can modify any valid Response (Access-Accept, Access-Reject, or Access-Challenge) to any other response using a chosen-prefix collision attack against MD5 Response Authenticator signature.", "cve_priority": "medium", "cve_public_date": "2024-07-09 12:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2024-3596", "url": "https://ubuntu.com/security/CVE-2024-3596", "cve_description": "RADIUS Protocol under RFC 2865 is susceptible to forgery attacks by a local attacker who can modify any valid Response (Access-Accept, Access-Reject, or Access-Challenge) to any other response using a chosen-prefix collision attack against MD5 Response Authenticator signature.", "cve_priority": "medium", "cve_public_date": "2024-07-09 12:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Use of MD5-based message authentication over plaintext", " communications could lead to forgery attacks. ", " - debian/patches/CVE-2024-3596.patch: Secure Response Authenticator ", " by adding support for the Message-Authenticator attribute in non-EAP ", " authentication methods. ", " - CVE-2024-3596$ ", " * Update libk5crypto3 symbols: add k5_hmac_md5 symbol. ", "" ], "package": "krb5", "version": "1.21.3-3ubuntu0.1", "urgency": "medium", "distributions": "oracular-security", "launchpad_bugs_fixed": [], "author": "Nicolas Campuzano Jimenez ", "date": "Tue, 04 Feb 2025 10:56:13 -0500" } ], "notes": null }, { "name": "libldap-common", "from_version": { "source_package_name": "openldap", "source_package_version": "2.6.8+dfsg-1~exp4ubuntu1", "version": "2.6.8+dfsg-1~exp4ubuntu1" }, "to_version": { "source_package_name": "openldap", "source_package_version": "2.6.8+dfsg-1~exp4ubuntu1.1", "version": "2.6.8+dfsg-1~exp4ubuntu1.1" }, "cves": [], "launchpad_bugs_fixed": [ 2090806 ], "changes": [ { "cves": [], "log": [ "", " * Fixup TIMEOUT and NETWORK_TIMEOUT options so they work correctly", " when SSL is involved. Before they would never timeout, causing", " hangs on connection failure. Now they timeout as expected.", " (LP: #2090806)", " - d/p/lp2090806-ITS-8047-Fix-TLS-connection-timeout-handling.patch ", "" ], "package": "openldap", "version": "2.6.8+dfsg-1~exp4ubuntu1.1", "urgency": "medium", "distributions": "oracular", "launchpad_bugs_fixed": [ 2090806 ], "author": "Matthew Ruffell ", "date": "Mon, 09 Dec 2024 15:41:30 +1300" } ], "notes": null }, { "name": "libldap2:armhf", "from_version": { "source_package_name": "openldap", "source_package_version": "2.6.8+dfsg-1~exp4ubuntu1", "version": "2.6.8+dfsg-1~exp4ubuntu1" }, "to_version": { "source_package_name": "openldap", "source_package_version": "2.6.8+dfsg-1~exp4ubuntu1.1", "version": "2.6.8+dfsg-1~exp4ubuntu1.1" }, "cves": [], "launchpad_bugs_fixed": [ 2090806 ], "changes": [ { "cves": [], "log": [ "", " * Fixup TIMEOUT and NETWORK_TIMEOUT options so they work correctly", " when SSL is involved. Before they would never timeout, causing", " hangs on connection failure. Now they timeout as expected.", " (LP: #2090806)", " - d/p/lp2090806-ITS-8047-Fix-TLS-connection-timeout-handling.patch ", "" ], "package": "openldap", "version": "2.6.8+dfsg-1~exp4ubuntu1.1", "urgency": "medium", "distributions": "oracular", "launchpad_bugs_fixed": [ 2090806 ], "author": "Matthew Ruffell ", "date": "Mon, 09 Dec 2024 15:41:30 +1300" } ], "notes": null }, { "name": "libpam-cap:armhf", "from_version": { "source_package_name": "libcap2", "source_package_version": "1:2.66-5ubuntu3", "version": "1:2.66-5ubuntu3" }, "to_version": { "source_package_name": "libcap2", "source_package_version": "1:2.66-5ubuntu3.1", "version": "1:2.66-5ubuntu3.1" }, "cves": [ { "cve": "CVE-2025-1390", "url": "https://ubuntu.com/security/CVE-2025-1390", "cve_description": "The PAM module pam_cap.so of libcap configuration supports group names starting with “@”, during actual parsing, configurations not starting with “@” are incorrectly recognized as group names. This may result in nonintended users being granted an inherited capability set, potentially leading to security risks. Attackers can exploit this vulnerability to achieve local privilege escalation on systems where /etc/security/capability.conf is used to configure user inherited privileges by constructing specific usernames.", "cve_priority": "medium", "cve_public_date": "2025-02-20" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2025-1390", "url": "https://ubuntu.com/security/CVE-2025-1390", "cve_description": "The PAM module pam_cap.so of libcap configuration supports group names starting with “@”, during actual parsing, configurations not starting with “@” are incorrectly recognized as group names. This may result in nonintended users being granted an inherited capability set, potentially leading to security risks. Attackers can exploit this vulnerability to achieve local privilege escalation on systems where /etc/security/capability.conf is used to configure user inherited privileges by constructing specific usernames.", "cve_priority": "medium", "cve_public_date": "2025-02-20" } ], "log": [ "", " * SECURITY UPDATE: incorrect group name handling", " - debian/patches/CVE-2025-1390-1.patch: fix potential configuration", " parsing error in pam_cap/pam_cap.c.", " - debian/patches/CVE-2025-1390-2.patch: add a test for bad group prefix", " in pam_cap/sudotest.conf.", " - CVE-2025-1390", "" ], "package": "libcap2", "version": "1:2.66-5ubuntu3.1", "urgency": "medium", "distributions": "oracular-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Thu, 20 Feb 2025 10:47:43 -0500" } ], "notes": null }, { "name": "libpython3.12-minimal:armhf", "from_version": { "source_package_name": "python3.12", "source_package_version": "3.12.7-1ubuntu1.1", "version": "3.12.7-1ubuntu1.1" }, "to_version": { "source_package_name": "python3.12", "source_package_version": "3.12.7-1ubuntu2", "version": "3.12.7-1ubuntu2" }, "cves": [ { "cve": "CVE-2025-0938", "url": "https://ubuntu.com/security/CVE-2025-0938", "cve_description": "The Python standard library functions `urllib.parse.urlsplit` and `urlparse` accepted domain names that included square brackets which isn't valid according to RFC 3986. Square brackets are only meant to be used as delimiters for specifying IPv6 and IPvFuture hosts in URLs. This could result in differential parsing across the Python URL parser and other specification-compliant URL parsers.", "cve_priority": "medium", "cve_public_date": "2025-01-31 18:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2025-0938", "url": "https://ubuntu.com/security/CVE-2025-0938", "cve_description": "The Python standard library functions `urllib.parse.urlsplit` and `urlparse` accepted domain names that included square brackets which isn't valid according to RFC 3986. Square brackets are only meant to be used as delimiters for specifying IPv6 and IPvFuture hosts in URLs. This could result in differential parsing across the Python URL parser and other specification-compliant URL parsers.", "cve_priority": "medium", "cve_public_date": "2025-01-31 18:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: urlparse does not flag hostname with square brackets", " as incorrect", " - debian/patches/CVE-2025-0938.patch: disallow square brackets in", " domain names for parsed URLs in Lib/test/test_urlparse.py,", " Lib/urllib/parse.py.", " - CVE-2025-0938", "" ], "package": "python3.12", "version": "3.12.7-1ubuntu2", "urgency": "medium", "distributions": "oracular-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Tue, 04 Feb 2025 09:46:03 -0500" } ], "notes": null }, { "name": "libpython3.12-stdlib:armhf", "from_version": { "source_package_name": "python3.12", "source_package_version": "3.12.7-1ubuntu1.1", "version": "3.12.7-1ubuntu1.1" }, "to_version": { "source_package_name": "python3.12", "source_package_version": "3.12.7-1ubuntu2", "version": "3.12.7-1ubuntu2" }, "cves": [ { "cve": "CVE-2025-0938", "url": "https://ubuntu.com/security/CVE-2025-0938", "cve_description": "The Python standard library functions `urllib.parse.urlsplit` and `urlparse` accepted domain names that included square brackets which isn't valid according to RFC 3986. Square brackets are only meant to be used as delimiters for specifying IPv6 and IPvFuture hosts in URLs. This could result in differential parsing across the Python URL parser and other specification-compliant URL parsers.", "cve_priority": "medium", "cve_public_date": "2025-01-31 18:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2025-0938", "url": "https://ubuntu.com/security/CVE-2025-0938", "cve_description": "The Python standard library functions `urllib.parse.urlsplit` and `urlparse` accepted domain names that included square brackets which isn't valid according to RFC 3986. Square brackets are only meant to be used as delimiters for specifying IPv6 and IPvFuture hosts in URLs. This could result in differential parsing across the Python URL parser and other specification-compliant URL parsers.", "cve_priority": "medium", "cve_public_date": "2025-01-31 18:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: urlparse does not flag hostname with square brackets", " as incorrect", " - debian/patches/CVE-2025-0938.patch: disallow square brackets in", " domain names for parsed URLs in Lib/test/test_urlparse.py,", " Lib/urllib/parse.py.", " - CVE-2025-0938", "" ], "package": "python3.12", "version": "3.12.7-1ubuntu2", "urgency": "medium", "distributions": "oracular-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Tue, 04 Feb 2025 09:46:03 -0500" } ], "notes": null }, { "name": "libpython3.12t64:armhf", "from_version": { "source_package_name": "python3.12", "source_package_version": "3.12.7-1ubuntu1.1", "version": "3.12.7-1ubuntu1.1" }, "to_version": { "source_package_name": "python3.12", "source_package_version": "3.12.7-1ubuntu2", "version": "3.12.7-1ubuntu2" }, "cves": [ { "cve": "CVE-2025-0938", "url": "https://ubuntu.com/security/CVE-2025-0938", "cve_description": "The Python standard library functions `urllib.parse.urlsplit` and `urlparse` accepted domain names that included square brackets which isn't valid according to RFC 3986. Square brackets are only meant to be used as delimiters for specifying IPv6 and IPvFuture hosts in URLs. This could result in differential parsing across the Python URL parser and other specification-compliant URL parsers.", "cve_priority": "medium", "cve_public_date": "2025-01-31 18:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2025-0938", "url": "https://ubuntu.com/security/CVE-2025-0938", "cve_description": "The Python standard library functions `urllib.parse.urlsplit` and `urlparse` accepted domain names that included square brackets which isn't valid according to RFC 3986. Square brackets are only meant to be used as delimiters for specifying IPv6 and IPvFuture hosts in URLs. This could result in differential parsing across the Python URL parser and other specification-compliant URL parsers.", "cve_priority": "medium", "cve_public_date": "2025-01-31 18:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: urlparse does not flag hostname with square brackets", " as incorrect", " - debian/patches/CVE-2025-0938.patch: disallow square brackets in", " domain names for parsed URLs in Lib/test/test_urlparse.py,", " Lib/urllib/parse.py.", " - CVE-2025-0938", "" ], "package": "python3.12", "version": "3.12.7-1ubuntu2", "urgency": "medium", "distributions": "oracular-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Tue, 04 Feb 2025 09:46:03 -0500" } ], "notes": null }, { "name": "libssl3t64:armhf", "from_version": { "source_package_name": "openssl", "source_package_version": "3.3.1-2ubuntu2", "version": "3.3.1-2ubuntu2" }, "to_version": { "source_package_name": "openssl", "source_package_version": "3.3.1-2ubuntu2.1", "version": "3.3.1-2ubuntu2.1" }, "cves": [ { "cve": "CVE-2024-9143", "url": "https://ubuntu.com/security/CVE-2024-9143", "cve_description": "Issue summary: Use of the low-level GF(2^m) elliptic curve APIs with untrusted explicit values for the field polynomial can lead to out-of-bounds memory reads or writes. Impact summary: Out of bound memory writes can lead to an application crash or even a possibility of a remote code execution, however, in all the protocols involving Elliptic Curve Cryptography that we're aware of, either only \"named curves\" are supported, or, if explicit curve parameters are supported, they specify an X9.62 encoding of binary (GF(2^m)) curves that can't represent problematic input values. Thus the likelihood of existence of a vulnerable application is low. In particular, the X9.62 encoding is used for ECC keys in X.509 certificates, so problematic inputs cannot occur in the context of processing X.509 certificates. Any problematic use-cases would have to be using an \"exotic\" curve encoding. The affected APIs include: EC_GROUP_new_curve_GF2m(), EC_GROUP_new_from_params(), and various supporting BN_GF2m_*() functions. Applications working with \"exotic\" explicit binary (GF(2^m)) curve parameters, that make it possible to represent invalid field polynomials with a zero constant term, via the above or similar APIs, may terminate abruptly as a result of reading or writing outside of array bounds. Remote code execution cannot easily be ruled out. The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.", "cve_priority": "low", "cve_public_date": "2024-10-16 17:15:00 UTC" }, { "cve": "CVE-2024-13176", "url": "https://ubuntu.com/security/CVE-2024-13176", "cve_description": "Issue summary: A timing side-channel which could potentially allow recovering the private key exists in the ECDSA signature computation. Impact summary: A timing side-channel in ECDSA signature computations could allow recovering the private key by an attacker. However, measuring the timing would require either local access to the signing application or a very fast network connection with low latency. There is a timing signal of around 300 nanoseconds when the top word of the inverted ECDSA nonce value is zero. This can happen with significant probability only for some of the supported elliptic curves. In particular the NIST P-521 curve is affected. To be able to measure this leak, the attacker process must either be located in the same physical computer or must have a very fast network connection with low latency. For that reason the severity of this vulnerability is Low.", "cve_priority": "low", "cve_public_date": "2025-01-20 14:15:00 UTC" }, { "cve": "CVE-2024-12797", "url": "https://ubuntu.com/security/CVE-2024-12797", "cve_description": "Issue summary: Clients using RFC7250 Raw Public Keys (RPKs) to authenticate a server may fail to notice that the server was not authenticated, because handshakes don't abort as expected when the SSL_VERIFY_PEER verification mode is set. Impact summary: TLS and DTLS connections using raw public keys may be vulnerable to man-in-middle attacks when server authentication failure is not detected by clients. RPKs are disabled by default in both TLS clients and TLS servers. The issue only arises when TLS clients explicitly enable RPK use by the server, and the server, likewise, enables sending of an RPK instead of an X.509 certificate chain. The affected clients are those that then rely on the handshake to fail when the server's RPK fails to match one of the expected public keys, by setting the verification mode to SSL_VERIFY_PEER. Clients that enable server-side raw public keys can still find out that raw public key verification failed by calling SSL_get_verify_result(), and those that do, and take appropriate action, are not affected. This issue was introduced in the initial implementation of RPK support in OpenSSL 3.2. The FIPS modules in 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.", "cve_priority": "high", "cve_public_date": "2025-02-11 16:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2024-9143", "url": "https://ubuntu.com/security/CVE-2024-9143", "cve_description": "Issue summary: Use of the low-level GF(2^m) elliptic curve APIs with untrusted explicit values for the field polynomial can lead to out-of-bounds memory reads or writes. Impact summary: Out of bound memory writes can lead to an application crash or even a possibility of a remote code execution, however, in all the protocols involving Elliptic Curve Cryptography that we're aware of, either only \"named curves\" are supported, or, if explicit curve parameters are supported, they specify an X9.62 encoding of binary (GF(2^m)) curves that can't represent problematic input values. Thus the likelihood of existence of a vulnerable application is low. In particular, the X9.62 encoding is used for ECC keys in X.509 certificates, so problematic inputs cannot occur in the context of processing X.509 certificates. Any problematic use-cases would have to be using an \"exotic\" curve encoding. The affected APIs include: EC_GROUP_new_curve_GF2m(), EC_GROUP_new_from_params(), and various supporting BN_GF2m_*() functions. Applications working with \"exotic\" explicit binary (GF(2^m)) curve parameters, that make it possible to represent invalid field polynomials with a zero constant term, via the above or similar APIs, may terminate abruptly as a result of reading or writing outside of array bounds. Remote code execution cannot easily be ruled out. The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.", "cve_priority": "low", "cve_public_date": "2024-10-16 17:15:00 UTC" }, { "cve": "CVE-2024-13176", "url": "https://ubuntu.com/security/CVE-2024-13176", "cve_description": "Issue summary: A timing side-channel which could potentially allow recovering the private key exists in the ECDSA signature computation. Impact summary: A timing side-channel in ECDSA signature computations could allow recovering the private key by an attacker. However, measuring the timing would require either local access to the signing application or a very fast network connection with low latency. There is a timing signal of around 300 nanoseconds when the top word of the inverted ECDSA nonce value is zero. This can happen with significant probability only for some of the supported elliptic curves. In particular the NIST P-521 curve is affected. To be able to measure this leak, the attacker process must either be located in the same physical computer or must have a very fast network connection with low latency. For that reason the severity of this vulnerability is Low.", "cve_priority": "low", "cve_public_date": "2025-01-20 14:15:00 UTC" }, { "cve": "CVE-2024-12797", "url": "https://ubuntu.com/security/CVE-2024-12797", "cve_description": "Issue summary: Clients using RFC7250 Raw Public Keys (RPKs) to authenticate a server may fail to notice that the server was not authenticated, because handshakes don't abort as expected when the SSL_VERIFY_PEER verification mode is set. Impact summary: TLS and DTLS connections using raw public keys may be vulnerable to man-in-middle attacks when server authentication failure is not detected by clients. RPKs are disabled by default in both TLS clients and TLS servers. The issue only arises when TLS clients explicitly enable RPK use by the server, and the server, likewise, enables sending of an RPK instead of an X.509 certificate chain. The affected clients are those that then rely on the handshake to fail when the server's RPK fails to match one of the expected public keys, by setting the verification mode to SSL_VERIFY_PEER. Clients that enable server-side raw public keys can still find out that raw public key verification failed by calling SSL_get_verify_result(), and those that do, and take appropriate action, are not affected. This issue was introduced in the initial implementation of RPK support in OpenSSL 3.2. The FIPS modules in 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.", "cve_priority": "high", "cve_public_date": "2025-02-11 16:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Low-level invalid GF(2^m) parameters lead to OOB", " memory access", " - debian/patches/CVE-2024-9143.patch: harden BN_GF2m_poly2arr against", " misuse in crypto/bn/bn_gf2m.c, test/ec_internal_test.c.", " - CVE-2024-9143", " * SECURITY UPDATE: A timing side-channel which could potentially allow", " recovering the private key exists in the ECDSA signature computation", " - debian/patches/CVE-2024-13176.patch: Fix timing side-channel in", " ECDSA signature computation in crypto/bn/bn_exp.c,", " crypto/ec/ec_lib.c, include/crypto/bn.h.", " - CVE-2024-13176", " * SECURITY UPDATE: RFC7250 handshakes with unauthenticated servers don't", " abort as expected", " - debian/patches/CVE-2024-12797-1.patch: with SSL_VERIFY_PEER client", " RPK should abort on X509 error in ssl/statem/statem_clnt.c,", " test/rpktest.c.", " - debian/patches/CVE-2024-12797-2.patch: use ERR marks also when", " verifying server X.509 certs in ssl/statem/statem_clnt.c,", " test/rpktest.c.", " - CVE-2024-12797", " * debian/patches/issue26466.patch: restore correct registers in aarch64", " AES-CTR code in crypto/aes/asm/aesv8-armx.pl.", "" ], "package": "openssl", "version": "3.3.1-2ubuntu2.1", "urgency": "medium", "distributions": "oracular-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Wed, 05 Feb 2025 07:56:37 -0500" } ], "notes": null }, { "name": "libtasn1-6:armhf", "from_version": { "source_package_name": "libtasn1-6", "source_package_version": "4.19.0-3build1", "version": "4.19.0-3build1" }, "to_version": { "source_package_name": "libtasn1-6", "source_package_version": "4.19.0-3ubuntu0.24.10.1", "version": "4.19.0-3ubuntu0.24.10.1" }, "cves": [ { "cve": "CVE-2024-12133", "url": "https://ubuntu.com/security/CVE-2024-12133", "cve_description": "A flaw in libtasn1 causes inefficient handling of specific certificate data. When processing a large number of elements in a certificate, libtasn1 takes much longer than expected, which can slow down or even crash the system. This flaw allows an attacker to send a specially crafted certificate, causing a denial of service attack.", "cve_priority": "medium", "cve_public_date": "2025-02-10 16:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2024-12133", "url": "https://ubuntu.com/security/CVE-2024-12133", "cve_description": "A flaw in libtasn1 causes inefficient handling of specific certificate data. When processing a large number of elements in a certificate, libtasn1 takes much longer than expected, which can slow down or even crash the system. This flaw allows an attacker to send a specially crafted certificate, causing a denial of service attack.", "cve_priority": "medium", "cve_public_date": "2025-02-10 16:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Denial of service through inefficient algorithm.", " - CVE-2024-12133-x.patch: Add caching and optimize algorithms in", " lib/decoding.c, lib/element.c, lib/element.h, lib/int.h,", " lib/parser_aux.c, and lib/structure.c.", " - CVE-2024-12133", "" ], "package": "libtasn1-6", "version": "4.19.0-3ubuntu0.24.10.1", "urgency": "medium", "distributions": "oracular-security", "launchpad_bugs_fixed": [], "author": "Hlib Korzhynskyy ", "date": "Mon, 10 Feb 2025 17:51:45 -0330" } ], "notes": null }, { "name": "linux-headers-generic", "from_version": { "source_package_name": "linux-meta", "source_package_version": "6.11.0-14.15", "version": "6.11.0-14.15" }, "to_version": { "source_package_name": "linux-meta", "source_package_version": "6.11.0-18.18", "version": "6.11.0-18.18" }, "cves": [], "launchpad_bugs_fixed": [ 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 6.11.0-18.18", "" ], "package": "linux-meta", "version": "6.11.0-18.18", "urgency": "medium", "distributions": "oracular", "launchpad_bugs_fixed": [], "author": "Manuel Diewald ", "date": "Fri, 07 Feb 2025 19:18:05 +0100" }, { "cves": [], "log": [ "", " * Main version: 6.11.0-17.17", "" ], "package": "linux-meta", "version": "6.11.0-17.17", "urgency": "medium", "distributions": "oracular", "launchpad_bugs_fixed": [], "author": "Stefan Bader ", "date": "Thu, 16 Jan 2025 23:24:54 +0100" }, { "cves": [], "log": [ "", " * Main version: 6.11.0-16.16", "", " * Packaging resync (LP: #1786013)", " - [Packaging] resync git-ubuntu-log", " - [Packaging] debian/dkms-versions -- resync from main package", "" ], "package": "linux-meta", "version": "6.11.0-16.16", "urgency": "medium", "distributions": "oracular", "launchpad_bugs_fixed": [ 1786013 ], "author": "Stefan Bader ", "date": "Thu, 16 Jan 2025 22:04:50 +0100" } ], "notes": null }, { "name": "linux-headers-virtual", "from_version": { "source_package_name": "linux-meta", "source_package_version": "6.11.0-14.15", "version": "6.11.0-14.15" }, "to_version": { "source_package_name": "linux-meta", "source_package_version": "6.11.0-18.18", "version": "6.11.0-18.18" }, "cves": [], "launchpad_bugs_fixed": [ 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 6.11.0-18.18", "" ], "package": "linux-meta", "version": "6.11.0-18.18", "urgency": "medium", "distributions": "oracular", "launchpad_bugs_fixed": [], "author": "Manuel Diewald ", "date": "Fri, 07 Feb 2025 19:18:05 +0100" }, { "cves": [], "log": [ "", " * Main version: 6.11.0-17.17", "" ], "package": "linux-meta", "version": "6.11.0-17.17", "urgency": "medium", "distributions": "oracular", "launchpad_bugs_fixed": [], "author": "Stefan Bader ", "date": "Thu, 16 Jan 2025 23:24:54 +0100" }, { "cves": [], "log": [ "", " * Main version: 6.11.0-16.16", "", " * Packaging resync (LP: #1786013)", " - [Packaging] resync git-ubuntu-log", " - [Packaging] debian/dkms-versions -- resync from main package", "" ], "package": "linux-meta", "version": "6.11.0-16.16", "urgency": "medium", "distributions": "oracular", "launchpad_bugs_fixed": [ 1786013 ], "author": "Stefan Bader ", "date": "Thu, 16 Jan 2025 22:04:50 +0100" } ], "notes": null }, { "name": "linux-image-virtual", "from_version": { "source_package_name": "linux-meta", "source_package_version": "6.11.0-14.15", "version": "6.11.0-14.15" }, "to_version": { "source_package_name": "linux-meta", "source_package_version": "6.11.0-18.18", "version": "6.11.0-18.18" }, "cves": [], "launchpad_bugs_fixed": [ 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 6.11.0-18.18", "" ], "package": "linux-meta", "version": "6.11.0-18.18", "urgency": "medium", "distributions": "oracular", "launchpad_bugs_fixed": [], "author": "Manuel Diewald ", "date": "Fri, 07 Feb 2025 19:18:05 +0100" }, { "cves": [], "log": [ "", " * Main version: 6.11.0-17.17", "" ], "package": "linux-meta", "version": "6.11.0-17.17", "urgency": "medium", "distributions": "oracular", "launchpad_bugs_fixed": [], "author": "Stefan Bader ", "date": "Thu, 16 Jan 2025 23:24:54 +0100" }, { "cves": [], "log": [ "", " * Main version: 6.11.0-16.16", "", " * Packaging resync (LP: #1786013)", " - [Packaging] resync git-ubuntu-log", " - [Packaging] debian/dkms-versions -- resync from main package", "" ], "package": "linux-meta", "version": "6.11.0-16.16", "urgency": "medium", "distributions": "oracular", "launchpad_bugs_fixed": [ 1786013 ], "author": "Stefan Bader ", "date": "Thu, 16 Jan 2025 22:04:50 +0100" } ], "notes": null }, { "name": "linux-libc-dev:armhf", "from_version": { "source_package_name": "linux", "source_package_version": "6.11.0-14.15", "version": "6.11.0-14.15" }, "to_version": { "source_package_name": "linux", "source_package_version": "6.11.0-18.18", "version": "6.11.0-18.18" }, "cves": [ { "cve": "CVE-2025-0927", "url": "https://ubuntu.com/security/CVE-2025-0927", "cve_description": "[fs: hfs/hfsplus: add key_len boundary check to hfs_bnode_read_key]", "cve_priority": "medium", "cve_public_date": "2025-02-13" }, { "cve": "CVE-2024-53141", "url": "https://ubuntu.com/security/CVE-2024-53141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: add missing range check in bitmap_ip_uadt When tb[IPSET_ATTR_IP_TO] is not present but tb[IPSET_ATTR_CIDR] exists, the values of ip and ip_to are slightly swapped. Therefore, the range check for ip should be done later, but this part is missing and it seems that the vulnerability occurs. So we should add missing range checks and remove unnecessary range checks.", "cve_priority": "medium", "cve_public_date": "2024-12-06 10:15:00 UTC" }, { "cve": "CVE-2024-50010", "url": "https://ubuntu.com/security/CVE-2024-50010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exec: don't WARN for racy path_noexec check Both i_mode and noexec checks wrapped in WARN_ON stem from an artifact of the previous implementation. They used to legitimately check for the condition, but that got moved up in two commits: 633fb6ac3980 (\"exec: move S_ISREG() check earlier\") 0fd338b2d2cd (\"exec: move path_noexec() check earlier\") Instead of being removed said checks are WARN_ON'ed instead, which has some debug value. However, the spurious path_noexec check is racy, resulting in unwarranted warnings should someone race with setting the noexec flag. One can note there is more to perm-checking whether execve is allowed and none of the conditions are guaranteed to still hold after they were tested for. Additionally this does not validate whether the code path did any perm checking to begin with -- it will pass if the inode happens to be regular. Keep the redundant path_noexec() check even though it's mindless nonsense checking for guarantee that isn't given so drop the WARN. Reword the commentary and do small tidy ups while here. [brauner: keep redundant path_noexec() check]", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-53143", "url": "https://ubuntu.com/security/CVE-2024-53143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fsnotify: Fix ordering of iput() and watched_objects decrement Ensure the superblock is kept alive until we're done with iput(). Holding a reference to an inode is not allowed unless we ensure the superblock stays alive, which fsnotify does by keeping the watched_objects count elevated, so iput() must happen before the watched_objects decrement. This can lead to a UAF of something like sb->s_fs_info in tmpfs, but the UAF is hard to hit because race orderings that oops are more likely, thanks to the CHECK_DATA_CORRUPTION() block in generic_shutdown_super(). Also, ensure that fsnotify_put_sb_watched_objects() doesn't call fsnotify_sb_watched_objects() on a superblock that may have already been freed, which would cause a UAF read of sb->s_fsnotify_info.", "cve_priority": "medium", "cve_public_date": "2024-12-07 07:15:00 UTC" }, { "cve": "CVE-2024-53142", "url": "https://ubuntu.com/security/CVE-2024-53142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: initramfs: avoid filename buffer overrun The initramfs filename field is defined in Documentation/driver-api/early-userspace/buffer-format.rst as: 37 cpio_file := ALGN(4) + cpio_header + filename + \"\\0\" + ALGN(4) + data ... 55 ============= ================== ========================= 56 Field name Field size Meaning 57 ============= ================== ========================= ... 70 c_namesize 8 bytes Length of filename, including final \\0 When extracting an initramfs cpio archive, the kernel's do_name() path handler assumes a zero-terminated path at @collected, passing it directly to filp_open() / init_mkdir() / init_mknod(). If a specially crafted cpio entry carries a non-zero-terminated filename and is followed by uninitialized memory, then a file may be created with trailing characters that represent the uninitialized memory. The ability to create an initramfs entry would imply already having full control of the system, so the buffer overrun shouldn't be considered a security vulnerability. Append the output of the following bash script to an existing initramfs and observe any created /initramfs_test_fname_overrunAA* path. E.g. ./reproducer.sh | gzip >> /myinitramfs It's easiest to observe non-zero uninitialized memory when the output is gzipped, as it'll overflow the heap allocated @out_buf in __gunzip(), rather than the initrd_start+initrd_size block. ---- reproducer.sh ---- nilchar=\"A\"\t# change to \"\\0\" to properly zero terminate / pad magic=\"070701\" ino=1 mode=$(( 0100777 )) uid=0 gid=0 nlink=1 mtime=1 filesize=0 devmajor=0 devminor=1 rdevmajor=0 rdevminor=0 csum=0 fname=\"initramfs_test_fname_overrun\" namelen=$(( ${#fname} + 1 ))\t# plus one to account for terminator printf \"%s%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%s\" \\ \t$magic $ino $mode $uid $gid $nlink $mtime $filesize \\ \t$devmajor $devminor $rdevmajor $rdevminor $namelen $csum $fname termpadlen=$(( 1 + ((4 - ((110 + $namelen) & 3)) % 4) )) printf \"%.s${nilchar}\" $(seq 1 $termpadlen) ---- reproducer.sh ---- Symlink filename fields handled in do_symlink() won't overrun past the data segment, due to the explicit zero-termination of the symlink target. Fix filename buffer overrun by aborting the initramfs FSM if any cpio entry doesn't carry a zero-terminator at the expected (name_len - 1) offset.", "cve_priority": "medium", "cve_public_date": "2024-12-06 10:15:00 UTC" }, { "cve": "CVE-2024-53133", "url": "https://ubuntu.com/security/CVE-2024-53133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Handle dml allocation failure to avoid crash [Why] In the case where a dml allocation fails for any reason, the current state's dml contexts would no longer be valid. Then subsequent calls dc_state_copy_internal would shallow copy invalid memory and if the new state was released, a double free would occur. [How] Reset dml pointers in new_state to NULL and avoid invalid pointer (cherry picked from commit bcafdc61529a48f6f06355d78eb41b3aeda5296c)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53108", "url": "https://ubuntu.com/security/CVE-2024-53108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Adjust VSDB parser for replay feature At some point, the IEEE ID identification for the replay check in the AMD EDID was added. However, this check causes the following out-of-bounds issues when using KASAN: [ 27.804016] BUG: KASAN: slab-out-of-bounds in amdgpu_dm_update_freesync_caps+0xefa/0x17a0 [amdgpu] [ 27.804788] Read of size 1 at addr ffff8881647fdb00 by task systemd-udevd/383 ... [ 27.821207] Memory state around the buggy address: [ 27.821215] ffff8881647fda00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821224] ffff8881647fda80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821234] >ffff8881647fdb00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821243] ^ [ 27.821250] ffff8881647fdb80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821259] ffff8881647fdc00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821268] ================================================================== This is caused because the ID extraction happens outside of the range of the edid lenght. This commit addresses this issue by considering the amd_vsdb_block size. (cherry picked from commit b7e381b1ccd5e778e3d9c44c669ad38439a861d8)", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53134", "url": "https://ubuntu.com/security/CVE-2024-53134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pmdomain: imx93-blk-ctrl: correct remove path The check condition should be 'i < bc->onecell_data.num_domains', not 'bc->onecell_data.num_domains' which will make the look never finish and cause kernel panic. Also disable runtime to address \"imx93-blk-ctrl 4ac10000.system-controller: Unbalanced pm_runtime_enable!\"", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53132", "url": "https://ubuntu.com/security/CVE-2024-53132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/oa: Fix \"Missing outer runtime PM protection\" warning Fix the following drm_WARN: [953.586396] xe 0000:00:02.0: [drm] Missing outer runtime PM protection ... <4> [953.587090] ? xe_pm_runtime_get_noresume+0x8d/0xa0 [xe] <4> [953.587208] guc_exec_queue_add_msg+0x28/0x130 [xe] <4> [953.587319] guc_exec_queue_fini+0x3a/0x40 [xe] <4> [953.587425] xe_exec_queue_destroy+0xb3/0xf0 [xe] <4> [953.587515] xe_oa_release+0x9c/0xc0 [xe] (cherry picked from commit b107c63d2953907908fd0cafb0e543b3c3167b75)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53127", "url": "https://ubuntu.com/security/CVE-2024-53127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Revert \"mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K\" The commit 8396c793ffdf (\"mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K\") increased the max_req_size, even for 4K pages, causing various issues: - Panic booting the kernel/rootfs from an SD card on Rockchip RK3566 - Panic booting the kernel/rootfs from an SD card on StarFive JH7100 - \"swiotlb buffer is full\" and data corruption on StarFive JH7110 At this stage no fix have been found, so it's probably better to just revert the change. This reverts commit 8396c793ffdf28bb8aee7cfe0891080f8cab7890.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53130", "url": "https://ubuntu.com/security/CVE-2024-53130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint When using the \"block:block_dirty_buffer\" tracepoint, mark_buffer_dirty() may cause a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because, since the tracepoint was added in mark_buffer_dirty(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, nilfs_grab_buffer(), which grabs a buffer to read (or create) a block of metadata, including b-tree node blocks, does not set the block device, but instead does so only if the buffer is not in the \"uptodate\" state for each of its caller block reading functions. However, if the uptodate flag is set on a folio/page, and the buffer heads are detached from it by try_to_free_buffers(), and new buffer heads are then attached by create_empty_buffers(), the uptodate flag may be restored to each buffer without the block device being set to bh->b_bdev, and mark_buffer_dirty() may be called later in that state, resulting in the bug mentioned above. Fix this issue by making nilfs_grab_buffer() always set the block device of the super block structure to the buffer head, regardless of the state of the buffer's uptodate flag.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53105", "url": "https://ubuntu.com/security/CVE-2024-53105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: page_alloc: move mlocked flag clearance into free_pages_prepare() Syzbot reported a bad page state problem caused by a page being freed using free_page() still having a mlocked flag at free_pages_prepare() stage: BUG: Bad page state in process syz.5.504 pfn:61f45 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x61f45 flags: 0xfff00000080204(referenced|workingset|mlocked|node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000080204 0000000000000000 dead000000000122 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set page_owner tracks the page as allocated page last allocated via order 0, migratetype Unmovable, gfp_mask 0x400dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO), pid 8443, tgid 8442 (syz.5.504), ts 201884660643, free_ts 201499827394 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1537 prep_new_page mm/page_alloc.c:1545 [inline] get_page_from_freelist+0x303f/0x3190 mm/page_alloc.c:3457 __alloc_pages_noprof+0x292/0x710 mm/page_alloc.c:4733 alloc_pages_mpol_noprof+0x3e8/0x680 mm/mempolicy.c:2265 kvm_coalesced_mmio_init+0x1f/0xf0 virt/kvm/coalesced_mmio.c:99 kvm_create_vm virt/kvm/kvm_main.c:1235 [inline] kvm_dev_ioctl_create_vm virt/kvm/kvm_main.c:5488 [inline] kvm_dev_ioctl+0x12dc/0x2240 virt/kvm/kvm_main.c:5530 __do_compat_sys_ioctl fs/ioctl.c:1007 [inline] __se_compat_sys_ioctl+0x510/0xc90 fs/ioctl.c:950 do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline] __do_fast_syscall_32+0xb4/0x110 arch/x86/entry/common.c:386 do_fast_syscall_32+0x34/0x80 arch/x86/entry/common.c:411 entry_SYSENTER_compat_after_hwframe+0x84/0x8e page last free pid 8399 tgid 8399 stack trace: reset_page_owner include/linux/page_owner.h:25 [inline] free_pages_prepare mm/page_alloc.c:1108 [inline] free_unref_folios+0xf12/0x18d0 mm/page_alloc.c:2686 folios_put_refs+0x76c/0x860 mm/swap.c:1007 free_pages_and_swap_cache+0x5c8/0x690 mm/swap_state.c:335 __tlb_batch_free_encoded_pages mm/mmu_gather.c:136 [inline] tlb_batch_pages_flush mm/mmu_gather.c:149 [inline] tlb_flush_mmu_free mm/mmu_gather.c:366 [inline] tlb_flush_mmu+0x3a3/0x680 mm/mmu_gather.c:373 tlb_finish_mmu+0xd4/0x200 mm/mmu_gather.c:465 exit_mmap+0x496/0xc40 mm/mmap.c:1926 __mmput+0x115/0x390 kernel/fork.c:1348 exit_mm+0x220/0x310 kernel/exit.c:571 do_exit+0x9b2/0x28e0 kernel/exit.c:926 do_group_exit+0x207/0x2c0 kernel/exit.c:1088 __do_sys_exit_group kernel/exit.c:1099 [inline] __se_sys_exit_group kernel/exit.c:1097 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1097 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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 Modules linked in: CPU: 0 UID: 0 PID: 8442 Comm: syz.5.504 Not tainted 6.12.0-rc6-syzkaller #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 bad_page+0x176/0x1d0 mm/page_alloc.c:501 free_page_is_bad mm/page_alloc.c:918 [inline] free_pages_prepare mm/page_alloc.c:1100 [inline] free_unref_page+0xed0/0xf20 mm/page_alloc.c:2638 kvm_destroy_vm virt/kvm/kvm_main.c:1327 [inline] kvm_put_kvm+0xc75/0x1350 virt/kvm/kvm_main.c:1386 kvm_vcpu_release+0x54/0x60 virt/kvm/kvm_main.c:4143 __fput+0x23f/0x880 fs/file_table.c:431 task_work_run+0x24f/0x310 kernel/task_work.c:239 exit_task_work include/linux/task_work.h:43 [inline] do_exit+0xa2f/0x28e0 kernel/exit.c:939 do_group_exit+0x207/0x2c0 kernel/exit.c:1088 __do_sys_exit_group kernel/exit.c:1099 [in ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53109", "url": "https://ubuntu.com/security/CVE-2024-53109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nommu: pass NULL argument to vma_iter_prealloc() When deleting a vma entry from a maple tree, it has to pass NULL to vma_iter_prealloc() in order to calculate internal state of the tree, but it passed a wrong argument. As a result, nommu kernels crashed upon accessing a vma iterator, such as acct_collect() reading the size of vma entries after do_munmap(). This commit fixes this issue by passing a right argument to the preallocation call.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53131", "url": "https://ubuntu.com/security/CVE-2024-53131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint Patch series \"nilfs2: fix null-ptr-deref bugs on block tracepoints\". This series fixes null pointer dereference bugs that occur when using nilfs2 and two block-related tracepoints. This patch (of 2): It has been reported that when using \"block:block_touch_buffer\" tracepoint, touch_buffer() called from __nilfs_get_folio_block() causes a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because since the tracepoint was added in touch_buffer(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, the block_device structure is set after the function returns to the caller. Here, touch_buffer() is used to mark the folio/page that owns the buffer head as accessed, but the common search helper for folio/page used by the caller function was optimized to mark the folio/page as accessed when it was reimplemented a long time ago, eliminating the need to call touch_buffer() here in the first place. So this solves the issue by eliminating the touch_buffer() call itself.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53135", "url": "https://ubuntu.com/security/CVE-2024-53135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: VMX: Bury Intel PT virtualization (guest/host mode) behind CONFIG_BROKEN Hide KVM's pt_mode module param behind CONFIG_BROKEN, i.e. disable support for virtualizing Intel PT via guest/host mode unless BROKEN=y. There are myriad bugs in the implementation, some of which are fatal to the guest, and others which put the stability and health of the host at risk. For guest fatalities, the most glaring issue is that KVM fails to ensure tracing is disabled, and *stays* disabled prior to VM-Enter, which is necessary as hardware disallows loading (the guest's) RTIT_CTL if tracing is enabled (enforced via a VMX consistency check). Per the SDM: If the logical processor is operating with Intel PT enabled (if IA32_RTIT_CTL.TraceEn = 1) at the time of VM entry, the \"load IA32_RTIT_CTL\" VM-entry control must be 0. On the host side, KVM doesn't validate the guest CPUID configuration provided by userspace, and even worse, uses the guest configuration to decide what MSRs to save/load at VM-Enter and VM-Exit. E.g. configuring guest CPUID to enumerate more address ranges than are supported in hardware will result in KVM trying to passthrough, save, and load non-existent MSRs, which generates a variety of WARNs, ToPA ERRORs in the host, a potential deadlock, etc.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53106", "url": "https://ubuntu.com/security/CVE-2024-53106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: fix buffer overrun in ima_eventdigest_init_common Function ima_eventdigest_init() calls ima_eventdigest_init_common() with HASH_ALGO__LAST which is then used to access the array hash_digest_size[] leading to buffer overrun. Have a conditional statement to handle this.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53110", "url": "https://ubuntu.com/security/CVE-2024-53110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vp_vdpa: fix id_table array not null terminated error Allocate one extra virtio_device_id as null terminator, otherwise vdpa_mgmtdev_get_classes() may iterate multiple times and visit undefined memory.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53126", "url": "https://ubuntu.com/security/CVE-2024-53126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa: solidrun: Fix UB bug with devres In psnet_open_pf_bar() and snet_open_vf_bar() a string later passed to pcim_iomap_regions() is placed on the stack. Neither pcim_iomap_regions() nor the functions it calls copy that string. Should the string later ever be used, this, consequently, causes undefined behavior since the stack frame will by then have disappeared. Fix the bug by allocating the strings on the heap through devm_kasprintf().", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53111", "url": "https://ubuntu.com/security/CVE-2024-53111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mremap: fix address wraparound in move_page_tables() On 32-bit platforms, it is possible for the expression `len + old_addr < old_end` to be false-positive if `len + old_addr` wraps around. `old_addr` is the cursor in the old range up to which page table entries have been moved; so if the operation succeeded, `old_addr` is the *end* of the old region, and adding `len` to it can wrap. The overflow causes mremap() to mistakenly believe that PTEs have been copied; the consequence is that mremap() bails out, but doesn't move the PTEs back before the new VMA is unmapped, causing anonymous pages in the region to be lost. So basically if userspace tries to mremap() a private-anon region and hits this bug, mremap() will return an error and the private-anon region's contents appear to have been zeroed. The idea of this check is that `old_end - len` is the original start address, and writing the check that way also makes it easier to read; so fix the check by rearranging the comparison accordingly. (An alternate fix would be to refactor this function by introducing an \"orig_old_start\" variable or such.) Tested in a VM with a 32-bit X86 kernel; without the patch: ``` user@horn:~/big_mremap$ cat test.c #define _GNU_SOURCE #include #include #include #include #define ADDR1 ((void*)0x60000000) #define ADDR2 ((void*)0x10000000) #define SIZE 0x50000000uL int main(void) { unsigned char *p1 = mmap(ADDR1, SIZE, PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0); if (p1 == MAP_FAILED) err(1, \"mmap 1\"); unsigned char *p2 = mmap(ADDR2, SIZE, PROT_NONE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0); if (p2 == MAP_FAILED) err(1, \"mmap 2\"); *p1 = 0x41; printf(\"first char is 0x%02hhx\\n\", *p1); unsigned char *p3 = mremap(p1, SIZE, SIZE, MREMAP_MAYMOVE|MREMAP_FIXED, p2); if (p3 == MAP_FAILED) { printf(\"mremap() failed; first char is 0x%02hhx\\n\", *p1); } else { printf(\"mremap() succeeded; first char is 0x%02hhx\\n\", *p3); } } user@horn:~/big_mremap$ gcc -static -o test test.c user@horn:~/big_mremap$ setarch -R ./test first char is 0x41 mremap() failed; first char is 0x00 ``` With the patch: ``` user@horn:~/big_mremap$ setarch -R ./test first char is 0x41 mremap() succeeded; first char is 0x41 ```", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53107", "url": "https://ubuntu.com/security/CVE-2024-53107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: prevent integer overflow in pagemap_scan_get_args() The \"arg->vec_len\" variable is a u64 that comes from the user at the start of the function. The \"arg->vec_len * sizeof(struct page_region))\" multiplication can lead to integer wrapping. Use size_mul() to avoid that. Also the size_add/mul() functions work on unsigned long so for 32bit systems we need to ensure that \"arg->vec_len\" fits in an unsigned long.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53128", "url": "https://ubuntu.com/security/CVE-2024-53128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/task_stack: fix object_is_on_stack() for KASAN tagged pointers When CONFIG_KASAN_SW_TAGS and CONFIG_KASAN_STACK are enabled, the object_is_on_stack() function may produce incorrect results due to the presence of tags in the obj pointer, while the stack pointer does not have tags. This discrepancy can lead to incorrect stack object detection and subsequently trigger warnings if CONFIG_DEBUG_OBJECTS is also enabled. Example of the warning: ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at lib/debugobjects.c:557 __debug_object_init+0x330/0x364 Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5 #4 Hardware name: linux,dummy-virt (DT) pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __debug_object_init+0x330/0x364 lr : __debug_object_init+0x330/0x364 sp : ffff800082ea7b40 x29: ffff800082ea7b40 x28: 98ff0000c0164518 x27: 98ff0000c0164534 x26: ffff800082d93ec8 x25: 0000000000000001 x24: 1cff0000c00172a0 x23: 0000000000000000 x22: ffff800082d93ed0 x21: ffff800081a24418 x20: 3eff800082ea7bb0 x19: efff800000000000 x18: 0000000000000000 x17: 00000000000000ff x16: 0000000000000047 x15: 206b63617473206e x14: 0000000000000018 x13: ffff800082ea7780 x12: 0ffff800082ea78e x11: 0ffff800082ea790 x10: 0ffff800082ea79d x9 : 34d77febe173e800 x8 : 34d77febe173e800 x7 : 0000000000000001 x6 : 0000000000000001 x5 : feff800082ea74b8 x4 : ffff800082870a90 x3 : ffff80008018d3c4 x2 : 0000000000000001 x1 : ffff800082858810 x0 : 0000000000000050 Call trace: __debug_object_init+0x330/0x364 debug_object_init_on_stack+0x30/0x3c schedule_hrtimeout_range_clock+0xac/0x26c schedule_hrtimeout+0x1c/0x30 wait_task_inactive+0x1d4/0x25c kthread_bind_mask+0x28/0x98 init_rescuer+0x1e8/0x280 workqueue_init+0x1a0/0x3cc kernel_init_freeable+0x118/0x200 kernel_init+0x28/0x1f0 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53112", "url": "https://ubuntu.com/security/CVE-2024-53112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: uncache inode which has failed entering the group Syzbot has reported the following BUG: kernel BUG at fs/ocfs2/uptodate.c:509! ... Call Trace: ? __die_body+0x5f/0xb0 ? die+0x9e/0xc0 ? do_trap+0x15a/0x3a0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? do_error_trap+0x1dc/0x2c0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? __pfx_do_error_trap+0x10/0x10 ? handle_invalid_op+0x34/0x40 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? exc_invalid_op+0x38/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? ocfs2_set_new_buffer_uptodate+0x2e/0x160 ? ocfs2_set_new_buffer_uptodate+0x144/0x160 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ocfs2_group_add+0x39f/0x15a0 ? __pfx_ocfs2_group_add+0x10/0x10 ? __pfx_lock_acquire+0x10/0x10 ? mnt_get_write_access+0x68/0x2b0 ? __pfx_lock_release+0x10/0x10 ? rcu_read_lock_any_held+0xb7/0x160 ? __pfx_rcu_read_lock_any_held+0x10/0x10 ? smack_log+0x123/0x540 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x226/0x2b0 ocfs2_ioctl+0x65e/0x7d0 ? __pfx_ocfs2_ioctl+0x10/0x10 ? smack_file_ioctl+0x29e/0x3a0 ? __pfx_smack_file_ioctl+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x43d/0x780 ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10 ? __pfx_ocfs2_ioctl+0x10/0x10 __se_sys_ioctl+0xfb/0x170 do_syscall_64+0xf3/0x230 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... When 'ioctl(OCFS2_IOC_GROUP_ADD, ...)' has failed for the particular inode in 'ocfs2_verify_group_and_input()', corresponding buffer head remains cached and subsequent call to the same 'ioctl()' for the same inode issues the BUG() in 'ocfs2_set_new_buffer_uptodate()' (trying to cache the same buffer head of that inode). Fix this by uncaching the buffer head with 'ocfs2_remove_from_cache()' on error path in 'ocfs2_group_add()'.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53113", "url": "https://ubuntu.com/security/CVE-2024-53113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: fix NULL pointer dereference in alloc_pages_bulk_noprof We triggered a NULL pointer dereference for ac.preferred_zoneref->zone in alloc_pages_bulk_noprof() when the task is migrated between cpusets. When cpuset is enabled, in prepare_alloc_pages(), ac->nodemask may be ¤t->mems_allowed. when first_zones_zonelist() is called to find preferred_zoneref, the ac->nodemask may be modified concurrently if the task is migrated between different cpusets. Assuming we have 2 NUMA Node, when traversing Node1 in ac->zonelist, the nodemask is 2, and when traversing Node2 in ac->zonelist, the nodemask is 1. As a result, the ac->preferred_zoneref points to NULL zone. In alloc_pages_bulk_noprof(), for_each_zone_zonelist_nodemask() finds a allowable zone and calls zonelist_node_idx(ac.preferred_zoneref), leading to NULL pointer dereference. __alloc_pages_noprof() fixes this issue by checking NULL pointer in commit ea57485af8f4 (\"mm, page_alloc: fix check for NULL preferred_zone\") and commit df76cee6bbeb (\"mm, page_alloc: remove redundant checks from alloc fastpath\"). To fix it, check NULL pointer for preferred_zoneref->zone.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53114", "url": "https://ubuntu.com/security/CVE-2024-53114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 client A number of Zen4 client SoCs advertise the ability to use virtualized VMLOAD/VMSAVE, but using these instructions is reported to be a cause of a random host reboot. These instructions aren't intended to be advertised on Zen4 client so clear the capability.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53137", "url": "https://ubuntu.com/security/CVE-2024-53137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: fix cacheflush with PAN It seems that the cacheflush syscall got broken when PAN for LPAE was implemented. User access was not enabled around the cache maintenance instructions, causing them to fault.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53115", "url": "https://ubuntu.com/security/CVE-2024-53115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: avoid null_ptr_deref in vmw_framebuffer_surface_create_handle The 'vmw_user_object_buffer' function may return NULL with incorrect inputs. To avoid possible null pointer dereference, add a check whether the 'bo' is NULL in the vmw_framebuffer_surface_create_handle.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53116", "url": "https://ubuntu.com/security/CVE-2024-53116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix handling of partial GPU mapping of BOs This commit fixes the bug in the handling of partial mapping of the buffer objects to the GPU, which caused kernel warnings. Panthor didn't correctly handle the case where the partial mapping spanned multiple scatterlists and the mapping offset didn't point to the 1st page of starting scatterlist. The offset variable was not cleared after reaching the starting scatterlist. Following warning messages were seen. WARNING: CPU: 1 PID: 650 at drivers/iommu/io-pgtable-arm.c:659 __arm_lpae_unmap+0x254/0x5a0 pc : __arm_lpae_unmap+0x254/0x5a0 lr : __arm_lpae_unmap+0x2cc/0x5a0 Call trace: __arm_lpae_unmap+0x254/0x5a0 __arm_lpae_unmap+0x108/0x5a0 __arm_lpae_unmap+0x108/0x5a0 __arm_lpae_unmap+0x108/0x5a0 arm_lpae_unmap_pages+0x80/0xa0 panthor_vm_unmap_pages+0xac/0x1c8 [panthor] panthor_gpuva_sm_step_unmap+0x4c/0xc8 [panthor] op_unmap_cb.isra.23.constprop.30+0x54/0x80 __drm_gpuvm_sm_unmap+0x184/0x1c8 drm_gpuvm_sm_unmap+0x40/0x60 panthor_vm_exec_op+0xa8/0x120 [panthor] panthor_vm_bind_exec_sync_op+0xc4/0xe8 [panthor] panthor_ioctl_vm_bind+0x10c/0x170 [panthor] drm_ioctl_kernel+0xbc/0x138 drm_ioctl+0x210/0x4b0 __arm64_sys_ioctl+0xb0/0xf8 invoke_syscall+0x4c/0x110 el0_svc_common.constprop.1+0x98/0xf8 do_el0_svc+0x24/0x38 el0_svc+0x34/0xc8 el0t_64_sync_handler+0xa0/0xc8 el0t_64_sync+0x174/0x178 panthor : [drm] drm_WARN_ON(unmapped_sz != pgsize * pgcount) WARNING: CPU: 1 PID: 650 at drivers/gpu/drm/panthor/panthor_mmu.c:922 panthor_vm_unmap_pages+0x124/0x1c8 [panthor] pc : panthor_vm_unmap_pages+0x124/0x1c8 [panthor] lr : panthor_vm_unmap_pages+0x124/0x1c8 [panthor] panthor : [drm] *ERROR* failed to unmap range ffffa388f000-ffffa3890000 (requested range ffffa388c000-ffffa3890000)", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53117", "url": "https://ubuntu.com/security/CVE-2024-53117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio/vsock: Improve MSG_ZEROCOPY error handling Add a missing kfree_skb() to prevent memory leaks.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53118", "url": "https://ubuntu.com/security/CVE-2024-53118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Fix sk_error_queue memory leak Kernel queues MSG_ZEROCOPY completion notifications on the error queue. Where they remain, until explicitly recv()ed. To prevent memory leaks, clean up the queue when the socket is destroyed. unreferenced object 0xffff8881028beb00 (size 224): comm \"vsock_test\", pid 1218, jiffies 4294694897 hex dump (first 32 bytes): 90 b0 21 17 81 88 ff ff 90 b0 21 17 81 88 ff ff ..!.......!..... 00 00 00 00 00 00 00 00 00 b0 21 17 81 88 ff ff ..........!..... backtrace (crc 6c7031ca): [] kmem_cache_alloc_node_noprof+0x2f7/0x370 [] __alloc_skb+0x132/0x180 [] sock_omalloc+0x4b/0x80 [] msg_zerocopy_realloc+0x9e/0x240 [] virtio_transport_send_pkt_info+0x412/0x4c0 [] virtio_transport_stream_enqueue+0x43/0x50 [] vsock_connectible_sendmsg+0x373/0x450 [] ____sys_sendmsg+0x365/0x3a0 [] ___sys_sendmsg+0x84/0xd0 [] __sys_sendmsg+0x47/0x80 [] do_syscall_64+0x93/0x180 [] entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53119", "url": "https://ubuntu.com/security/CVE-2024-53119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio/vsock: Fix accept_queue memory leak As the final stages of socket destruction may be delayed, it is possible that virtio_transport_recv_listen() will be called after the accept_queue has been flushed, but before the SOCK_DONE flag has been set. As a result, sockets enqueued after the flush would remain unremoved, leading to a memory leak. vsock_release __vsock_release lock virtio_transport_release virtio_transport_close schedule_delayed_work(close_work) sk_shutdown = SHUTDOWN_MASK (!) flush accept_queue release virtio_transport_recv_pkt vsock_find_bound_socket lock if flag(SOCK_DONE) return virtio_transport_recv_listen child = vsock_create_connected (!) vsock_enqueue_accept(child) release close_work lock virtio_transport_do_close set_flag(SOCK_DONE) virtio_transport_remove_sock vsock_remove_sock vsock_remove_bound release Introduce a sk_shutdown check to disallow vsock_enqueue_accept() during socket destruction. unreferenced object 0xffff888109e3f800 (size 2040): comm \"kworker/5:2\", pid 371, jiffies 4294940105 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00 (..@............ backtrace (crc 9e5f4e84): [] kmem_cache_alloc_noprof+0x2c1/0x360 [] sk_prot_alloc+0x30/0x120 [] sk_alloc+0x2c/0x4b0 [] __vsock_create.constprop.0+0x2a/0x310 [] virtio_transport_recv_pkt+0x4dc/0x9a0 [] vsock_loopback_work+0xfd/0x140 [] process_one_work+0x20c/0x570 [] worker_thread+0x1bf/0x3a0 [] kthread+0xdd/0x110 [] ret_from_fork+0x2d/0x50 [] ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53120", "url": "https://ubuntu.com/security/CVE-2024-53120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: CT: Fix null-ptr-deref in add rule err flow In error flow of mlx5_tc_ct_entry_add_rule(), in case ct_rule_add() callback returns error, zone_rule->attr is used uninitiated. Fix it to use attr which has the needed pointer value. Kernel log: BUG: kernel NULL pointer dereference, address: 0000000000000110 RIP: 0010:mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core] … Call Trace: ? __die+0x20/0x70 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x140 ? asm_exc_page_fault+0x22/0x30 ? mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core] ? mlx5_tc_ct_entry_add_rule+0x1d5/0x2f0 [mlx5_core] mlx5_tc_ct_block_flow_offload+0xc6a/0xf90 [mlx5_core] ? nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] flow_offload_work_handler+0x142/0x320 [nf_flow_table] ? finish_task_switch.isra.0+0x15b/0x2b0 process_one_work+0x16c/0x320 worker_thread+0x28c/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xb8/0xf0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53138", "url": "https://ubuntu.com/security/CVE-2024-53138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: kTLS, Fix incorrect page refcounting The kTLS tx handling code is using a mix of get_page() and page_ref_inc() APIs to increment the page reference. But on the release path (mlx5e_ktls_tx_handle_resync_dump_comp()), only put_page() is used. This is an issue when using pages from large folios: the get_page() references are stored on the folio page while the page_ref_inc() references are stored directly in the given page. On release the folio page will be dereferenced too many times. This was found while doing kTLS testing with sendfile() + ZC when the served file was read from NFS on a kernel with NFS large folios support (commit 49b29a573da8 (\"nfs: add support for large folios\")).", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53121", "url": "https://ubuntu.com/security/CVE-2024-53121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: fs, lock FTE when checking if active The referenced commits introduced a two-step process for deleting FTEs: - Lock the FTE, delete it from hardware, set the hardware deletion function to NULL and unlock the FTE. - Lock the parent flow group, delete the software copy of the FTE, and remove it from the xarray. However, this approach encounters a race condition if a rule with the same match value is added simultaneously. In this scenario, fs_core may set the hardware deletion function to NULL prematurely, causing a panic during subsequent rule deletions. To prevent this, ensure the active flag of the FTE is checked under a lock, which will prevent the fs_core layer from attaching a new steering rule to an FTE that is in the process of deletion. [ 438.967589] MOSHE: 2496 mlx5_del_flow_rules del_hw_func [ 438.968205] ------------[ cut here ]------------ [ 438.968654] refcount_t: decrement hit 0; leaking memory. [ 438.969249] WARNING: CPU: 0 PID: 8957 at lib/refcount.c:31 refcount_warn_saturate+0xfb/0x110 [ 438.970054] Modules linked in: act_mirred cls_flower act_gact sch_ingress openvswitch nsh mlx5_vdpa vringh vhost_iotlb vdpa mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core zram zsmalloc fuse [last unloaded: cls_flower] [ 438.973288] CPU: 0 UID: 0 PID: 8957 Comm: tc Not tainted 6.12.0-rc1+ #8 [ 438.973888] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 438.974874] RIP: 0010:refcount_warn_saturate+0xfb/0x110 [ 438.975363] Code: 40 66 3b 82 c6 05 16 e9 4d 01 01 e8 1f 7c a0 ff 0f 0b c3 cc cc cc cc 48 c7 c7 10 66 3b 82 c6 05 fd e8 4d 01 01 e8 05 7c a0 ff <0f> 0b c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 90 [ 438.976947] RSP: 0018:ffff888124a53610 EFLAGS: 00010286 [ 438.977446] RAX: 0000000000000000 RBX: ffff888119d56de0 RCX: 0000000000000000 [ 438.978090] RDX: ffff88852c828700 RSI: ffff88852c81b3c0 RDI: ffff88852c81b3c0 [ 438.978721] RBP: ffff888120fa0e88 R08: 0000000000000000 R09: ffff888124a534b0 [ 438.979353] R10: 0000000000000001 R11: 0000000000000001 R12: ffff888119d56de0 [ 438.979979] R13: ffff888120fa0ec0 R14: ffff888120fa0ee8 R15: ffff888119d56de0 [ 438.980607] FS: 00007fe6dcc0f800(0000) GS:ffff88852c800000(0000) knlGS:0000000000000000 [ 438.983984] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 438.984544] CR2: 00000000004275e0 CR3: 0000000186982001 CR4: 0000000000372eb0 [ 438.985205] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 438.985842] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 438.986507] Call Trace: [ 438.986799] [ 438.987070] ? __warn+0x7d/0x110 [ 438.987426] ? refcount_warn_saturate+0xfb/0x110 [ 438.987877] ? report_bug+0x17d/0x190 [ 438.988261] ? prb_read_valid+0x17/0x20 [ 438.988659] ? handle_bug+0x53/0x90 [ 438.989054] ? exc_invalid_op+0x14/0x70 [ 438.989458] ? asm_exc_invalid_op+0x16/0x20 [ 438.989883] ? refcount_warn_saturate+0xfb/0x110 [ 438.990348] mlx5_del_flow_rules+0x2f7/0x340 [mlx5_core] [ 438.990932] __mlx5_eswitch_del_rule+0x49/0x170 [mlx5_core] [ 438.991519] ? mlx5_lag_is_sriov+0x3c/0x50 [mlx5_core] [ 438.992054] ? xas_load+0x9/0xb0 [ 438.992407] mlx5e_tc_rule_unoffload+0x45/0xe0 [mlx5_core] [ 438.993037] mlx5e_tc_del_fdb_flow+0x2a6/0x2e0 [mlx5_core] [ 438.993623] mlx5e_flow_put+0x29/0x60 [mlx5_core] [ 438.994161] mlx5e_delete_flower+0x261/0x390 [mlx5_core] [ 438.994728] tc_setup_cb_destroy+0xb9/0x190 [ 438.995150] fl_hw_destroy_filter+0x94/0xc0 [cls_flower] [ 438.995650] fl_change+0x11a4/0x13c0 [cls_flower] [ 438.996105] tc_new_tfilter+0x347/0xbc0 [ 438.996503] ? __ ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53122", "url": "https://ubuntu.com/security/CVE-2024-53122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: cope racing subflow creation in mptcp_rcv_space_adjust Additional active subflows - i.e. created by the in kernel path manager - are included into the subflow list before starting the 3whs. A racing recvmsg() spooling data received on an already established subflow would unconditionally call tcp_cleanup_rbuf() on all the current subflows, potentially hitting a divide by zero error on the newly created ones. Explicitly check that the subflow is in a suitable state before invoking tcp_cleanup_rbuf().", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53123", "url": "https://ubuntu.com/security/CVE-2024-53123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: error out earlier on disconnect Eric reported a division by zero splat in the MPTCP protocol: Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 6094 Comm: syz-executor317 Not tainted 6.12.0-rc5-syzkaller-00291-g05b92660cdfe #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:__tcp_select_window+0x5b4/0x1310 net/ipv4/tcp_output.c:3163 Code: f6 44 01 e3 89 df e8 9b 75 09 f8 44 39 f3 0f 8d 11 ff ff ff e8 0d 74 09 f8 45 89 f4 e9 04 ff ff ff e8 00 74 09 f8 44 89 f0 99 7c 24 14 41 29 d6 45 89 f4 e9 ec fe ff ff e8 e8 73 09 f8 48 89 RSP: 0018:ffffc900041f7930 EFLAGS: 00010293 RAX: 0000000000017e67 RBX: 0000000000017e67 RCX: ffffffff8983314b RDX: 0000000000000000 RSI: ffffffff898331b0 RDI: 0000000000000004 RBP: 00000000005d6000 R08: 0000000000000004 R09: 0000000000017e67 R10: 0000000000003e80 R11: 0000000000000000 R12: 0000000000003e80 R13: ffff888031d9b440 R14: 0000000000017e67 R15: 00000000002eb000 FS: 00007feb5d7f16c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007feb5d8adbb8 CR3: 0000000074e4c000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __tcp_cleanup_rbuf+0x3e7/0x4b0 net/ipv4/tcp.c:1493 mptcp_rcv_space_adjust net/mptcp/protocol.c:2085 [inline] mptcp_recvmsg+0x2156/0x2600 net/mptcp/protocol.c:2289 inet_recvmsg+0x469/0x6a0 net/ipv4/af_inet.c:885 sock_recvmsg_nosec net/socket.c:1051 [inline] sock_recvmsg+0x1b2/0x250 net/socket.c:1073 __sys_recvfrom+0x1a5/0x2e0 net/socket.c:2265 __do_sys_recvfrom net/socket.c:2283 [inline] __se_sys_recvfrom net/socket.c:2279 [inline] __x64_sys_recvfrom+0xe0/0x1c0 net/socket.c:2279 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 RIP: 0033:0x7feb5d857559 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:00007feb5d7f1208 EFLAGS: 00000246 ORIG_RAX: 000000000000002d RAX: ffffffffffffffda RBX: 00007feb5d8e1318 RCX: 00007feb5d857559 RDX: 000000800000000e RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007feb5d8e1310 R08: 0000000000000000 R09: ffffffff81000000 R10: 0000000000000100 R11: 0000000000000246 R12: 00007feb5d8e131c R13: 00007feb5d8ae074 R14: 000000800000000e R15: 00000000fffffdef and provided a nice reproducer. The root cause is the current bad handling of racing disconnect. After the blamed commit below, sk_wait_data() can return (with error) with the underlying socket disconnected and a zero rcv_mss. Catch the error and return without performing any additional operations on the current socket.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53124", "url": "https://ubuntu.com/security/CVE-2024-53124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix data-races around sk->sk_forward_alloc Syzkaller reported this warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 16 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x1c5/0x1e0 Modules linked in: CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:inet_sock_destruct+0x1c5/0x1e0 Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 <0f> 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00 RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206 RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007 RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00 RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007 R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00 R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78 FS: 0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn+0x88/0x130 ? inet_sock_destruct+0x1c5/0x1e0 ? report_bug+0x18e/0x1a0 ? handle_bug+0x53/0x90 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? inet_sock_destruct+0x1c5/0x1e0 __sk_destruct+0x2a/0x200 rcu_do_batch+0x1aa/0x530 ? rcu_do_batch+0x13b/0x530 rcu_core+0x159/0x2f0 handle_softirqs+0xd3/0x2b0 ? __pfx_smpboot_thread_fn+0x10/0x10 run_ksoftirqd+0x25/0x30 smpboot_thread_fn+0xdd/0x1d0 kthread+0xd3/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ---[ end trace 0000000000000000 ]--- Its possible that two threads call tcp_v6_do_rcv()/sk_forward_alloc_add() concurrently when sk->sk_state == TCP_LISTEN with sk->sk_lock unlocked, which triggers a data-race around sk->sk_forward_alloc: tcp_v6_rcv tcp_v6_do_rcv skb_clone_and_charge_r sk_rmem_schedule __sk_mem_schedule sk_forward_alloc_add() skb_set_owner_r sk_mem_charge sk_forward_alloc_add() __kfree_skb skb_release_all skb_release_head_state sock_rfree sk_mem_uncharge sk_forward_alloc_add() sk_mem_reclaim // set local var reclaimable __sk_mem_reclaim sk_forward_alloc_add() In this syzkaller testcase, two threads call tcp_v6_do_rcv() with skb->truesize=768, the sk_forward_alloc changes like this: (cpu 1) | (cpu 2) | sk_forward_alloc ... | ... | 0 __sk_mem_schedule() | | +4096 = 4096 | __sk_mem_schedule() | +4096 = 8192 sk_mem_charge() | | -768 = 7424 | sk_mem_charge() | -768 = 6656 ... | ... | sk_mem_uncharge() | | +768 = 7424 reclaimable=7424 | | | sk_mem_uncharge() | +768 = 8192 | reclaimable=8192 | __sk_mem_reclaim() | | -4096 = 4096 | __sk_mem_reclaim() | -8192 = -4096 != 0 The skb_clone_and_charge_r() should not be called in tcp_v6_do_rcv() when sk->sk_state is TCP_LISTEN, it happens later in tcp_v6_syn_recv_sock(). Fix the same issue in dccp_v6_do_rcv().", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53129", "url": "https://ubuntu.com/security/CVE-2024-53129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: vop: Fix a dereferenced before check warning The 'state' can't be NULL, we should check crtc_state. Fix warning: drivers/gpu/drm/rockchip/rockchip_drm_vop.c:1096 vop_plane_atomic_async_check() warn: variable dereferenced before check 'state' (see line 1077)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53139", "url": "https://ubuntu.com/security/CVE-2024-53139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix possible UAF in sctp_v6_available() A lockdep report [1] with CONFIG_PROVE_RCU_LIST=y hints that sctp_v6_available() is calling dev_get_by_index_rcu() and ipv6_chk_addr() without holding rcu. [1] ============================= WARNING: suspicious RCU usage 6.12.0-rc5-virtme #1216 Tainted: G W ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by sctp_hello/31495: #0: ffff9f1ebbdb7418 (sk_lock-AF_INET6){+.+.}-{0:0}, at: sctp_bind (./arch/x86/include/asm/jump_label.h:27 net/sctp/socket.c:315) sctp stack backtrace: CPU: 7 UID: 0 PID: 31495 Comm: sctp_hello Tainted: G W 6.12.0-rc5-virtme #1216 Tainted: [W]=WARN 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:123) lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822) dev_get_by_index_rcu (net/core/dev.c:876 (discriminator 7)) sctp_v6_available (net/sctp/ipv6.c:701) sctp sctp_do_bind (net/sctp/socket.c:400 (discriminator 1)) sctp sctp_bind (net/sctp/socket.c:320) sctp inet6_bind_sk (net/ipv6/af_inet6.c:465) ? security_socket_bind (security/security.c:4581 (discriminator 1)) __sys_bind (net/socket.c:1848 net/socket.c:1869) ? do_user_addr_fault (./include/linux/rcupdate.h:347 ./include/linux/rcupdate.h:880 ./include/linux/mm.h:729 arch/x86/mm/fault.c:1340) ? do_user_addr_fault (./arch/x86/include/asm/preempt.h:84 (discriminator 13) ./include/linux/rcupdate.h:98 (discriminator 13) ./include/linux/rcupdate.h:882 (discriminator 13) ./include/linux/mm.h:729 (discriminator 13) arch/x86/mm/fault.c:1340 (discriminator 13)) __x64_sys_bind (net/socket.c:1877 (discriminator 1) net/socket.c:1875 (discriminator 1) net/socket.c:1875 (discriminator 1)) do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f59b934a1e7 Code: 44 00 00 48 8b 15 39 8c 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 b8 31 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 09 8c 0c 00 f7 d8 64 89 01 48 All code ======== 0:\t44 00 00 \tadd %r8b,(%rax) 3:\t48 8b 15 39 8c 0c 00 \tmov 0xc8c39(%rip),%rdx # 0xc8c43 a:\tf7 d8 \tneg %eax c:\t64 89 02 \tmov %eax,%fs:(%rdx) f:\tb8 ff ff ff ff \tmov $0xffffffff,%eax 14:\teb bd \tjmp 0xffffffffffffffd3 16:\t66 2e 0f 1f 84 00 00 \tcs nopw 0x0(%rax,%rax,1) 1d:\t00 00 00 20:\t0f 1f 00 \tnopl (%rax) 23:\tb8 31 00 00 00 \tmov $0x31,%eax 28:\t0f 05 \tsyscall 2a:*\t48 3d 01 f0 ff ff \tcmp $0xfffffffffffff001,%rax\t\t<-- trapping instruction 30:\t73 01 \tjae 0x33 32:\tc3 \tret 33:\t48 8b 0d 09 8c 0c 00 \tmov 0xc8c09(%rip),%rcx # 0xc8c43 3a:\tf7 d8 \tneg %eax 3c:\t64 89 01 \tmov %eax,%fs:(%rcx) 3f:\t48 \trex.W Code starting with the faulting instruction =========================================== 0:\t48 3d 01 f0 ff ff \tcmp $0xfffffffffffff001,%rax 6:\t73 01 \tjae 0x9 8:\tc3 \tret 9:\t48 8b 0d 09 8c 0c 00 \tmov 0xc8c09(%rip),%rcx # 0xc8c19 10:\tf7 d8 \tneg %eax 12:\t64 89 01 \tmov %eax,%fs:(%rcx) 15:\t48 \trex.W RSP: 002b:00007ffe2d0ad398 EFLAGS: 00000202 ORIG_RAX: 0000000000000031 RAX: ffffffffffffffda RBX: 00007ffe2d0ad3d0 RCX: 00007f59b934a1e7 RDX: 000000000000001c RSI: 00007ffe2d0ad3d0 RDI: 0000000000000005 RBP: 0000000000000005 R08: 1999999999999999 R09: 0000000000000000 R10: 00007f59b9253298 R11: 000000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53140", "url": "https://ubuntu.com/security/CVE-2024-53140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netlink: terminate outstanding dump on socket close Netlink supports iterative dumping of data. It provides the families the following ops: - start - (optional) kicks off the dumping process - dump - actual dump helper, keeps getting called until it returns 0 - done - (optional) pairs with .start, can be used for cleanup The whole process is asynchronous and the repeated calls to .dump don't actually happen in a tight loop, but rather are triggered in response to recvmsg() on the socket. This gives the user full control over the dump, but also means that the user can close the socket without getting to the end of the dump. To make sure .start is always paired with .done we check if there is an ongoing dump before freeing the socket, and if so call .done. The complication is that sockets can get freed from BH and .done is allowed to sleep. So we use a workqueue to defer the call, when needed. Unfortunately this does not work correctly. What we defer is not the cleanup but rather releasing a reference on the socket. We have no guarantee that we own the last reference, if someone else holds the socket they may release it in BH and we're back to square one. The whole dance, however, appears to be unnecessary. Only the user can interact with dumps, so we can clean up when socket is closed. And close always happens in process context. Some async code may still access the socket after close, queue notification skbs to it etc. but no dumps can start, end or otherwise make progress. Delete the workqueue and flush the dump state directly from the release handler. Note that further cleanup is possible in -next, for instance we now always call .done before releasing the main module reference, so dump doesn't have to take a reference of its own.", "cve_priority": "high", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53098", "url": "https://ubuntu.com/security/CVE-2024-53098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/ufence: Prefetch ufence addr to catch bogus address access_ok() only checks for addr overflow so also try to read the addr to catch invalid addr sent from userspace. (cherry picked from commit 9408c4508483ffc60811e910a93d6425b8e63928)", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53099", "url": "https://ubuntu.com/security/CVE-2024-53099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check validity of link->type in bpf_link_show_fdinfo() If a newly-added link type doesn't invoke BPF_LINK_TYPE(), accessing bpf_link_type_strs[link->type] may result in an out-of-bounds access. To spot such missed invocations early in the future, checking the validity of link->type in bpf_link_show_fdinfo() and emitting a warning when such invocations are missed.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53089", "url": "https://ubuntu.com/security/CVE-2024-53089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: KVM: Mark hrtimer to expire in hard interrupt context Like commit 2c0d278f3293f (\"KVM: LAPIC: Mark hrtimer to expire in hard interrupt context\") and commit 9090825fa9974 (\"KVM: arm/arm64: Let the timer expire in hardirq context on RT\"), On PREEMPT_RT enabled kernels unmarked hrtimers are moved into soft interrupt expiry mode by default. Then the timers are canceled from an preempt-notifier which is invoked with disabled preemption which is not allowed on PREEMPT_RT. The timer callback is short so in could be invoked in hard-IRQ context. So let the timer expire on hard-IRQ context even on -RT. This fix a \"scheduling while atomic\" bug for PREEMPT_RT enabled kernels: BUG: scheduling while atomic: qemu-system-loo/1011/0x00000002 Modules linked in: amdgpu rfkill nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat ns CPU: 1 UID: 0 PID: 1011 Comm: qemu-system-loo Tainted: G W 6.12.0-rc2+ #1774 Tainted: [W]=WARN Hardware name: Loongson Loongson-3A5000-7A1000-1w-CRB/Loongson-LS3A5000-7A1000-1w-CRB, BIOS vUDK2018-LoongArch-V2.0.0-prebeta9 10/21/2022 Stack : ffffffffffffffff 0000000000000000 9000000004e3ea38 9000000116744000 90000001167475a0 0000000000000000 90000001167475a8 9000000005644830 90000000058dc000 90000000058dbff8 9000000116747420 0000000000000001 0000000000000001 6a613fc938313980 000000000790c000 90000001001c1140 00000000000003fe 0000000000000001 000000000000000d 0000000000000003 0000000000000030 00000000000003f3 000000000790c000 9000000116747830 90000000057ef000 0000000000000000 9000000005644830 0000000000000004 0000000000000000 90000000057f4b58 0000000000000001 9000000116747868 900000000451b600 9000000005644830 9000000003a13998 0000000010000020 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d ... Call Trace: [<9000000003a13998>] show_stack+0x38/0x180 [<9000000004e3ea34>] dump_stack_lvl+0x84/0xc0 [<9000000003a71708>] __schedule_bug+0x48/0x60 [<9000000004e45734>] __schedule+0x1114/0x1660 [<9000000004e46040>] schedule_rtlock+0x20/0x60 [<9000000004e4e330>] rtlock_slowlock_locked+0x3f0/0x10a0 [<9000000004e4f038>] rt_spin_lock+0x58/0x80 [<9000000003b02d68>] hrtimer_cancel_wait_running+0x68/0xc0 [<9000000003b02e30>] hrtimer_cancel+0x70/0x80 [] kvm_restore_timer+0x50/0x1a0 [kvm] [] kvm_arch_vcpu_load+0x68/0x2a0 [kvm] [] kvm_sched_in+0x34/0x60 [kvm] [<9000000003a749a0>] finish_task_switch.isra.0+0x140/0x2e0 [<9000000004e44a70>] __schedule+0x450/0x1660 [<9000000004e45cb0>] schedule+0x30/0x180 [] kvm_vcpu_block+0x70/0x120 [kvm] [] kvm_vcpu_halt+0x60/0x3e0 [kvm] [] kvm_handle_gspr+0x3f4/0x4e0 [kvm] [] kvm_handle_exit+0x1c8/0x260 [kvm]", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53090", "url": "https://ubuntu.com/security/CVE-2024-53090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix lock recursion afs_wake_up_async_call() can incur lock recursion. The problem is that it is called from AF_RXRPC whilst holding the ->notify_lock, but it tries to take a ref on the afs_call struct in order to pass it to a work queue - but if the afs_call is already queued, we then have an extraneous ref that must be put... calling afs_put_call() may call back down into AF_RXRPC through rxrpc_kernel_shutdown_call(), however, which might try taking the ->notify_lock again. This case isn't very common, however, so defer it to a workqueue. The oops looks something like: BUG: spinlock recursion on CPU#0, krxrpcio/7001/1646 lock: 0xffff888141399b30, .magic: dead4ead, .owner: krxrpcio/7001/1646, .owner_cpu: 0 CPU: 0 UID: 0 PID: 1646 Comm: krxrpcio/7001 Not tainted 6.12.0-rc2-build3+ #4351 Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014 Call Trace: dump_stack_lvl+0x47/0x70 do_raw_spin_lock+0x3c/0x90 rxrpc_kernel_shutdown_call+0x83/0xb0 afs_put_call+0xd7/0x180 rxrpc_notify_socket+0xa0/0x190 rxrpc_input_split_jumbo+0x198/0x1d0 rxrpc_input_data+0x14b/0x1e0 ? rxrpc_input_call_packet+0xc2/0x1f0 rxrpc_input_call_event+0xad/0x6b0 rxrpc_input_packet_on_conn+0x1e1/0x210 rxrpc_input_packet+0x3f2/0x4d0 rxrpc_io_thread+0x243/0x410 ? __pfx_rxrpc_io_thread+0x10/0x10 kthread+0xcf/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x24/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53101", "url": "https://ubuntu.com/security/CVE-2024-53101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized value issue in from_kuid and from_kgid ocfs2_setattr() uses attr->ia_mode, attr->ia_uid and attr->ia_gid in a trace point even though ATTR_MODE, ATTR_UID and ATTR_GID aren't set. Initialize all fields of newattrs to avoid uninitialized variables, by checking if ATTR_MODE, ATTR_UID, ATTR_GID are initialized, otherwise 0.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53091", "url": "https://ubuntu.com/security/CVE-2024-53091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Add sk_is_inet and IS_ICSK check in tls_sw_has_ctx_tx/rx As the introduction of the support for vsock and unix sockets in sockmap, tls_sw_has_ctx_tx/rx cannot presume the socket passed in must be IS_ICSK. vsock and af_unix sockets have vsock_sock and unix_sock instead of inet_connection_sock. For these sockets, tls_get_ctx may return an invalid pointer and cause page fault in function tls_sw_ctx_rx. BUG: unable to handle page fault for address: 0000000000040030 Workqueue: vsock-loopback vsock_loopback_work RIP: 0010:sk_psock_strp_data_ready+0x23/0x60 Call Trace: ? __die+0x81/0xc3 ? no_context+0x194/0x350 ? do_page_fault+0x30/0x110 ? async_page_fault+0x3e/0x50 ? sk_psock_strp_data_ready+0x23/0x60 virtio_transport_recv_pkt+0x750/0x800 ? update_load_avg+0x7e/0x620 vsock_loopback_work+0xd0/0x100 process_one_work+0x1a7/0x360 worker_thread+0x30/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x112/0x130 ? __kthread_cancel_work+0x40/0x40 ret_from_fork+0x1f/0x40 v2: - Add IS_ICSK check v3: - Update the commits in Fixes", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53092", "url": "https://ubuntu.com/security/CVE-2024-53092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_pci: Fix admin vq cleanup by using correct info pointer vp_modern_avq_cleanup() and vp_del_vqs() clean up admin vq resources by virtio_pci_vq_info pointer. The info pointer of admin vq is stored in vp_dev->admin_vq.info instead of vp_dev->vqs[]. Using the info pointer from vp_dev->vqs[] for admin vq causes a kernel NULL pointer dereference bug. In vp_modern_avq_cleanup() and vp_del_vqs(), get the info pointer from vp_dev->admin_vq.info for admin vq to clean up the resources. Also make info ptr as argument of vp_del_vq() to be symmetric with vp_setup_vq(). vp_reset calls vp_modern_avq_cleanup, and causes the Call Trace: ================================================================== BUG: kernel NULL pointer dereference, address:0000000000000000 ... CPU: 49 UID: 0 PID: 4439 Comm: modprobe Not tainted 6.11.0-rc5 #1 RIP: 0010:vp_reset+0x57/0x90 [virtio_pci] Call Trace: ... ? vp_reset+0x57/0x90 [virtio_pci] ? vp_reset+0x38/0x90 [virtio_pci] virtio_reset_device+0x1d/0x30 remove_vq_common+0x1c/0x1a0 [virtio_net] virtnet_remove+0xa1/0xc0 [virtio_net] virtio_dev_remove+0x46/0xa0 ... virtio_pci_driver_exit+0x14/0x810 [virtio_pci] ==================================================================", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53102", "url": "https://ubuntu.com/security/CVE-2024-53102", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53093", "url": "https://ubuntu.com/security/CVE-2024-53093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: defer partition scanning We need to suppress the partition scan from occuring within the controller's scan_work context. If a path error occurs here, the IO will wait until a path becomes available or all paths are torn down, but that action also occurs within scan_work, so it would deadlock. Defer the partion scan to a different context that does not block scan_work.", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53094", "url": "https://ubuntu.com/security/CVE-2024-53094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Add sendpage_ok() check to disable MSG_SPLICE_PAGES While running ISER over SIW, the initiator machine encounters a warning from skb_splice_from_iter() indicating that a slab page is being used in send_page. To address this, it is better to add a sendpage_ok() check within the driver itself, and if it returns 0, then MSG_SPLICE_PAGES flag should be disabled before entering the network stack. A similar issue has been discussed for NVMe in this thread: https://lore.kernel.org/all/20240530142417.146696-1-ofir.gal@volumez.com/ WARNING: CPU: 0 PID: 5342 at net/core/skbuff.c:7140 skb_splice_from_iter+0x173/0x320 Call Trace: tcp_sendmsg_locked+0x368/0xe40 siw_tx_hdt+0x695/0xa40 [siw] siw_qp_sq_process+0x102/0xb00 [siw] siw_sq_resume+0x39/0x110 [siw] siw_run_sq+0x74/0x160 [siw] kthread+0xd2/0x100 ret_from_fork+0x34/0x40 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53100", "url": "https://ubuntu.com/security/CVE-2024-53100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: tcp: avoid race between queue_lock lock and destroy Commit 76d54bf20cdc (\"nvme-tcp: don't access released socket during error recovery\") added a mutex_lock() call for the queue->queue_lock in nvme_tcp_get_address(). However, the mutex_lock() races with mutex_destroy() in nvme_tcp_free_queue(), and causes the WARN below. DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: CPU: 3 PID: 34077 at kernel/locking/mutex.c:587 __mutex_lock+0xcf0/0x1220 Modules linked in: nvmet_tcp nvmet nvme_tcp nvme_fabrics iw_cm ib_cm ib_core pktcdvd nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables qrtr sunrpc ppdev 9pnet_virtio 9pnet pcspkr netfs parport_pc parport e1000 i2c_piix4 i2c_smbus loop fuse nfnetlink zram bochs drm_vram_helper drm_ttm_helper ttm drm_kms_helper xfs drm sym53c8xx floppy nvme scsi_transport_spi nvme_core nvme_auth serio_raw ata_generic pata_acpi dm_multipath qemu_fw_cfg [last unloaded: ib_uverbs] CPU: 3 UID: 0 PID: 34077 Comm: udisksd Not tainted 6.11.0-rc7 #319 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:__mutex_lock+0xcf0/0x1220 Code: 08 84 d2 0f 85 c8 04 00 00 8b 15 ef b6 c8 01 85 d2 0f 85 78 f4 ff ff 48 c7 c6 20 93 ee af 48 c7 c7 60 91 ee af e8 f0 a7 6d fd <0f> 0b e9 5e f4 ff ff 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 RSP: 0018:ffff88811305f760 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff88812c652058 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000001 RBP: ffff88811305f8b0 R08: 0000000000000001 R09: ffffed1075c36341 R10: ffff8883ae1b1a0b R11: 0000000000010498 R12: 0000000000000000 R13: 0000000000000000 R14: dffffc0000000000 R15: ffff88812c652058 FS: 00007f9713ae4980(0000) GS:ffff8883ae180000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcd78483c7c CR3: 0000000122c38000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn.cold+0x5b/0x1af ? __mutex_lock+0xcf0/0x1220 ? report_bug+0x1ec/0x390 ? handle_bug+0x3c/0x80 ? exc_invalid_op+0x13/0x40 ? asm_exc_invalid_op+0x16/0x20 ? __mutex_lock+0xcf0/0x1220 ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] ? __pfx___mutex_lock+0x10/0x10 ? __lock_acquire+0xd6a/0x59e0 ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] ? __pfx_nvme_tcp_get_address+0x10/0x10 [nvme_tcp] nvme_sysfs_show_address+0x81/0xc0 [nvme_core] dev_attr_show+0x42/0x80 ? __asan_memset+0x1f/0x40 sysfs_kf_seq_show+0x1f0/0x370 seq_read_iter+0x2cb/0x1130 ? rw_verify_area+0x3b1/0x590 ? __mutex_lock+0x433/0x1220 vfs_read+0x6a6/0xa20 ? lockdep_hardirqs_on+0x78/0x100 ? __pfx_vfs_read+0x10/0x10 ksys_read+0xf7/0x1d0 ? __pfx_ksys_read+0x10/0x10 ? __x64_sys_openat+0x105/0x1d0 do_syscall_64+0x93/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? __pfx_ksys_read+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? do_syscall_64+0x9f/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f9713f55cfa Code: 55 48 89 e5 48 83 ec 20 48 89 55 e8 48 89 75 f0 89 7d f8 e8 e8 74 f8 ff 48 8b 55 e8 48 8b 75 f0 4 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53095", "url": "https://ubuntu.com/security/CVE-2024-53095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix use-after-free of network namespace. Recently, we got a customer report that CIFS triggers oops while reconnecting to a server. [0] The workload runs on Kubernetes, and some pods mount CIFS servers in non-root network namespaces. The problem rarely happened, but it was always while the pod was dying. The root cause is wrong reference counting for network namespace. CIFS uses kernel sockets, which do not hold refcnt of the netns that the socket belongs to. That means CIFS must ensure the socket is always freed before its netns; otherwise, use-after-free happens. The repro steps are roughly: 1. mount CIFS in a non-root netns 2. drop packets from the netns 3. destroy the netns 4. unmount CIFS We can reproduce the issue quickly with the script [1] below and see the splat [2] if CONFIG_NET_NS_REFCNT_TRACKER is enabled. When the socket is TCP, it is hard to guarantee the netns lifetime without holding refcnt due to async timers. Let's hold netns refcnt for each socket as done for SMC in commit 9744d2bf1976 (\"smc: Fix use-after-free in tcp_write_timer_handler().\"). Note that we need to move put_net() from cifs_put_tcp_session() to clean_demultiplex_info(); otherwise, __sock_create() still could touch a freed netns while cifsd tries to reconnect from cifs_demultiplex_thread(). Also, maybe_get_net() cannot be put just before __sock_create() because the code is not under RCU and there is a small chance that the same address happened to be reallocated to another netns. [0]: CIFS: VFS: \\\\XXXXXXXXXXX has not responded in 15 seconds. Reconnecting... CIFS: Serverclose failed 4 times, giving up Unable to handle kernel paging request at virtual address 14de99e461f84a07 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 CM = 0, WnR = 0 [14de99e461f84a07] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: cls_bpf sch_ingress nls_utf8 cifs cifs_arc4 cifs_md4 dns_resolver tcp_diag inet_diag veth xt_state xt_connmark nf_conntrack_netlink xt_nat xt_statistic xt_MASQUERADE xt_mark xt_addrtype ipt_REJECT nf_reject_ipv4 nft_chain_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment nft_compat nf_tables nfnetlink overlay nls_ascii nls_cp437 sunrpc vfat fat aes_ce_blk aes_ce_cipher ghash_ce sm4_ce_cipher sm4 sm3_ce sm3 sha3_ce sha512_ce sha512_arm64 sha1_ce ena button sch_fq_codel loop fuse configfs dmi_sysfs sha2_ce sha256_arm64 dm_mirror dm_region_hash dm_log dm_mod dax efivarfs CPU: 5 PID: 2690970 Comm: cifsd Not tainted 6.1.103-109.184.amzn2023.aarch64 #1 Hardware name: Amazon EC2 r7g.4xlarge/, BIOS 1.0 11/1/2018 pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : fib_rules_lookup+0x44/0x238 lr : __fib_lookup+0x64/0xbc sp : ffff8000265db790 x29: ffff8000265db790 x28: 0000000000000000 x27: 000000000000bd01 x26: 0000000000000000 x25: ffff000b4baf8000 x24: ffff00047b5e4580 x23: ffff8000265db7e0 x22: 0000000000000000 x21: ffff00047b5e4500 x20: ffff0010e3f694f8 x19: 14de99e461f849f7 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 3f92800abd010002 x11: 0000000000000001 x10: ffff0010e3f69420 x9 : ffff800008a6f294 x8 : 0000000000000000 x7 : 0000000000000006 x6 : 0000000000000000 x5 : 0000000000000001 x4 : ffff001924354280 x3 : ffff8000265db7e0 x2 : 0000000000000000 x1 : ffff0010e3f694f8 x0 : ffff00047b5e4500 Call trace: fib_rules_lookup+0x44/0x238 __fib_lookup+0x64/0xbc ip_route_output_key_hash_rcu+0x2c4/0x398 ip_route_output_key_hash+0x60/0x8c tcp_v4_connect+0x290/0x488 __inet_stream_connect+0x108/0x3d0 inet_stream_connect+0x50/0x78 kernel_connect+0x6c/0xac generic_ip_conne ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-50265", "url": "https://ubuntu.com/security/CVE-2024-50265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove() Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove(): [ 57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12 [ 57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry [ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004 [...] [ 57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [...] [ 57.331328] Call Trace: [ 57.331477] [...] [ 57.333511] ? do_user_addr_fault+0x3e5/0x740 [ 57.333778] ? exc_page_fault+0x70/0x170 [ 57.334016] ? asm_exc_page_fault+0x2b/0x30 [ 57.334263] ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10 [ 57.334596] ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [ 57.334913] ocfs2_xa_remove_entry+0x23/0xc0 [ 57.335164] ocfs2_xa_set+0x704/0xcf0 [ 57.335381] ? _raw_spin_unlock+0x1a/0x40 [ 57.335620] ? ocfs2_inode_cache_unlock+0x16/0x20 [ 57.335915] ? trace_preempt_on+0x1e/0x70 [ 57.336153] ? start_this_handle+0x16c/0x500 [ 57.336410] ? preempt_count_sub+0x50/0x80 [ 57.336656] ? _raw_read_unlock+0x20/0x40 [ 57.336906] ? start_this_handle+0x16c/0x500 [ 57.337162] ocfs2_xattr_block_set+0xa6/0x1e0 [ 57.337424] __ocfs2_xattr_set_handle+0x1fd/0x5d0 [ 57.337706] ? ocfs2_start_trans+0x13d/0x290 [ 57.337971] ocfs2_xattr_set+0xb13/0xfb0 [ 57.338207] ? dput+0x46/0x1c0 [ 57.338393] ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338665] ? ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338948] __vfs_removexattr+0x92/0xc0 [ 57.339182] __vfs_removexattr_locked+0xd5/0x190 [ 57.339456] ? preempt_count_sub+0x50/0x80 [ 57.339705] vfs_removexattr+0x5f/0x100 [...] Reproducer uses faultinject facility to fail ocfs2_xa_remove() -> ocfs2_xa_value_truncate() with -ENOMEM. In this case the comment mentions that we can return 0 if ocfs2_xa_cleanup_value_truncate() is going to wipe the entry anyway. But the following 'rc' check is wrong and execution flow do 'ocfs2_xa_remove_entry(loc);' twice: * 1st: in ocfs2_xa_cleanup_value_truncate(); * 2nd: returning back to ocfs2_xa_remove() instead of going to 'out'. Fix this by skipping the 2nd removal of the same entry and making syzkaller repro happy.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50266", "url": "https://ubuntu.com/security/CVE-2024-50266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: qcom: videocc-sm8350: use HW_CTRL_TRIGGER for vcodec GDSCs A recent change in the venus driver results in a stuck clock on the Lenovo ThinkPad X13s, for example, when streaming video in firefox: \tvideo_cc_mvs0_clk status stuck at 'off' \tWARNING: CPU: 6 PID: 2885 at drivers/clk/qcom/clk-branch.c:87 clk_branch_wait+0x144/0x15c \t... \tCall trace: \t clk_branch_wait+0x144/0x15c \t clk_branch2_enable+0x30/0x40 \t clk_core_enable+0xd8/0x29c \t clk_enable+0x2c/0x4c \t vcodec_clks_enable.isra.0+0x94/0xd8 [venus_core] \t coreid_power_v4+0x464/0x628 [venus_core] \t vdec_start_streaming+0xc4/0x510 [venus_dec] \t vb2_start_streaming+0x6c/0x180 [videobuf2_common] \t vb2_core_streamon+0x120/0x1dc [videobuf2_common] \t vb2_streamon+0x1c/0x6c [videobuf2_v4l2] \t v4l2_m2m_ioctl_streamon+0x30/0x80 [v4l2_mem2mem] \t v4l_streamon+0x24/0x30 [videodev] using the out-of-tree sm8350/sc8280xp venus support. [1] Update also the sm8350/sc8280xp GDSC definitions so that the hw control mode can be changed at runtime as the venus driver now requires.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50267", "url": "https://ubuntu.com/security/CVE-2024-50267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: fix use after free in debug printk The \"dev_dbg(&urb->dev->dev, ...\" which happens after usb_free_urb(urb) is a use after free of the \"urb\" pointer. Store the \"dev\" pointer at the start of the function to avoid this issue.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50268", "url": "https://ubuntu.com/security/CVE-2024-50268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: fix potential out of bounds in ucsi_ccg_update_set_new_cam_cmd() The \"*cmd\" variable can be controlled by the user via debugfs. That means \"new_cam\" can be as high as 255 while the size of the uc->updated[] array is UCSI_MAX_ALTMODES (30). The call tree is: ucsi_cmd() // val comes from simple_attr_write_xsigned() -> ucsi_send_command() -> ucsi_send_command_common() -> ucsi_run_command() // calls ucsi->ops->sync_control() -> ucsi_ccg_sync_control()", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53083", "url": "https://ubuntu.com/security/CVE-2024-53083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: qcom-pmic: init value of hdr_len/txbuf_len earlier If the read of USB_PDPHY_RX_ACKNOWLEDGE_REG failed, then hdr_len and txbuf_len are uninitialized. This commit stops to print uninitialized value and misleading/false data.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50269", "url": "https://ubuntu.com/security/CVE-2024-50269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: musb: sunxi: Fix accessing an released usb phy Commit 6ed05c68cbca (\"usb: musb: sunxi: Explicitly release USB PHY on exit\") will cause that usb phy @glue->xceiv is accessed after released. 1) register platform driver @sunxi_musb_driver // get the usb phy @glue->xceiv sunxi_musb_probe() -> devm_usb_get_phy(). 2) register and unregister platform driver @musb_driver musb_probe() -> sunxi_musb_init() use the phy here //the phy is released here musb_remove() -> sunxi_musb_exit() -> devm_usb_put_phy() 3) register @musb_driver again musb_probe() -> sunxi_musb_init() use the phy here but the phy has been released at 2). ... Fixed by reverting the commit, namely, removing devm_usb_put_phy() from sunxi_musb_exit().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53079", "url": "https://ubuntu.com/security/CVE-2024-53079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/thp: fix deferred split unqueue naming and locking Recent changes are putting more pressure on THP deferred split queues: under load revealing long-standing races, causing list_del corruptions, \"Bad page state\"s and worse (I keep BUGs in both of those, so usually don't get to see how badly they end up without). The relevant recent changes being 6.8's mTHP, 6.10's mTHP swapout, and 6.12's mTHP swapin, improved swap allocation, and underused THP splitting. Before fixing locking: rename misleading folio_undo_large_rmappable(), which does not undo large_rmappable, to folio_unqueue_deferred_split(), which is what it does. But that and its out-of-line __callee are mm internals of very limited usability: add comment and WARN_ON_ONCEs to check usage; and return a bool to say if a deferred split was unqueued, which can then be used in WARN_ON_ONCEs around safety checks (sparing callers the arcane conditionals in __folio_unqueue_deferred_split()). Just omit the folio_unqueue_deferred_split() from free_unref_folios(), all of whose callers now call it beforehand (and if any forget then bad_page() will tell) - except for its caller put_pages_list(), which itself no longer has any callers (and will be deleted separately). Swapout: mem_cgroup_swapout() has been resetting folio->memcg_data 0 without checking and unqueueing a THP folio from deferred split list; which is unfortunate, since the split_queue_lock depends on the memcg (when memcg is enabled); so swapout has been unqueueing such THPs later, when freeing the folio, using the pgdat's lock instead: potentially corrupting the memcg's list. __remove_mapping() has frozen refcount to 0 here, so no problem with calling folio_unqueue_deferred_split() before resetting memcg_data. That goes back to 5.4 commit 87eaceb3faa5 (\"mm: thp: make deferred split shrinker memcg aware\"): which included a check on swapcache before adding to deferred queue, but no check on deferred queue before adding THP to swapcache. That worked fine with the usual sequence of events in reclaim (though there were a couple of rare ways in which a THP on deferred queue could have been swapped out), but 6.12 commit dafff3f4c850 (\"mm: split underused THPs\") avoids splitting underused THPs in reclaim, which makes swapcache THPs on deferred queue commonplace. Keep the check on swapcache before adding to deferred queue? Yes: it is no longer essential, but preserves the existing behaviour, and is likely to be a worthwhile optimization (vmstat showed much more traffic on the queue under swapping load if the check was removed); update its comment. Memcg-v1 move (deprecated): mem_cgroup_move_account() has been changing folio->memcg_data without checking and unqueueing a THP folio from the deferred list, sometimes corrupting \"from\" memcg's list, like swapout. Refcount is non-zero here, so folio_unqueue_deferred_split() can only be used in a WARN_ON_ONCE to validate the fix, which must be done earlier: mem_cgroup_move_charge_pte_range() first try to split the THP (splitting of course unqueues), or skip it if that fails. Not ideal, but moving charge has been requested, and khugepaged should repair the THP later: nobody wants new custom unqueueing code just for this deprecated case. The 87eaceb3faa5 commit did have the code to move from one deferred list to another (but was not conscious of its unsafety while refcount non-0); but that was removed by 5.6 commit fac0516b5534 (\"mm: thp: don't need care deferred split queue in memcg charge move path\"), which argued that the existence of a PMD mapping guarantees that the THP cannot be on a deferred list. As above, false in rare cases, and now commonly false. Backport to 6.11 should be straightforward. Earlier backports must take care that other _deferred_list fixes and dependencies are included. There is not a strong case for backports, but they can fix cornercases.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50270", "url": "https://ubuntu.com/security/CVE-2024-50270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: avoid overflow in damon_feed_loop_next_input() damon_feed_loop_next_input() is inefficient and fragile to overflows. Specifically, 'score_goal_diff_bp' calculation can overflow when 'score' is high. The calculation is actually unnecessary at all because 'goal' is a constant of value 10,000. Calculation of 'compensation' is again fragile to overflow. Final calculation of return value for under-achiving case is again fragile to overflow when the current score is under-achieving the target. Add two corner cases handling at the beginning of the function to make the body easier to read, and rewrite the body of the function to avoid overflows and the unnecessary bp value calcuation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50271", "url": "https://ubuntu.com/security/CVE-2024-50271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: signal: restore the override_rlimit logic Prior to commit d64696905554 (\"Reimplement RLIMIT_SIGPENDING on top of ucounts\") UCOUNT_RLIMIT_SIGPENDING rlimit was not enforced for a class of signals. However now it's enforced unconditionally, even if override_rlimit is set. This behavior change caused production issues. For example, if the limit is reached and a process receives a SIGSEGV signal, sigqueue_alloc fails to allocate the necessary resources for the signal delivery, preventing the signal from being delivered with siginfo. This prevents the process from correctly identifying the fault address and handling the error. From the user-space perspective, applications are unaware that the limit has been reached and that the siginfo is effectively 'corrupted'. This can lead to unpredictable behavior and crashes, as we observed with java applications. Fix this by passing override_rlimit into inc_rlimit_get_ucounts() and skip the comparison to max there if override_rlimit is set. This effectively restores the old behavior.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50272", "url": "https://ubuntu.com/security/CVE-2024-50272", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: filemap: Fix bounds checking in filemap_read() If the caller supplies an iocb->ki_pos value that is close to the filesystem upper limit, and an iterator with a count that causes us to overflow that limit, then filemap_read() enters an infinite loop. This behaviour was discovered when testing xfstests generic/525 with the \"localio\" optimisation for loopback NFS mounts.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53104", "url": "https://ubuntu.com/security/CVE-2024-53104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_parse_format This can lead to out of bounds writes since frames of this type were not taken into account when calculating the size of the frames buffer in uvc_parse_streaming.", "cve_priority": "high", "cve_public_date": "2024-12-02 08:15:00 UTC" }, { "cve": "CVE-2024-50273", "url": "https://ubuntu.com/security/CVE-2024-50273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reinitialize delayed ref list after deleting it from the list At insert_delayed_ref() if we need to update the action of an existing ref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head's ref_add_list using list_del(), which leaves the ref's add_list member not reinitialized, as list_del() sets the next and prev members of the list to LIST_POISON1 and LIST_POISON2, respectively. If later we end up calling drop_delayed_ref() against the ref, which can happen during merging or when destroying delayed refs due to a transaction abort, we can trigger a crash since at drop_delayed_ref() we call list_empty() against the ref's add_list, which returns false since the list was not reinitialized after the list_del() and as a consequence we call list_del() again at drop_delayed_ref(). This results in an invalid list access since the next and prev members are set to poison pointers, resulting in a splat if CONFIG_LIST_HARDENED and CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences otherwise. So fix this by deleting from the list with list_del_init() instead.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53064", "url": "https://ubuntu.com/security/CVE-2024-53064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix idpf_vc_core_init error path In an event where the platform running the device control plane is rebooted, reset is detected on the driver. It releases all the resources and waits for the reset to complete. Once the reset is done, it tries to build the resources back. At this time if the device control plane is not yet started, then the driver timeouts on the virtchnl message and retries to establish the mailbox again. In the retry flow, mailbox is deinitialized but the mailbox workqueue is still alive and polling for the mailbox message. This results in accessing the released control queue leading to null-ptr-deref. Fix it by unrolling the work queue cancellation and mailbox deinitialization in the reverse order which they got initialized.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50274", "url": "https://ubuntu.com/security/CVE-2024-50274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: avoid vport access in idpf_get_link_ksettings When the device control plane is removed or the platform running device control plane is rebooted, a reset is detected on the driver. On driver reset, it releases the resources and waits for the reset to complete. If the reset fails, it takes the error path and releases the vport lock. At this time if the monitoring tools tries to access link settings, it call traces for accessing released vport pointer. To avoid it, move link_speed_mbps to netdev_priv structure which removes the dependency on vport pointer and the vport lock in idpf_get_link_ksettings. Also use netif_carrier_ok() to check the link status and adjust the offsetof to use link_up instead of link_speed_mbps.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53065", "url": "https://ubuntu.com/security/CVE-2024-53065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/slab: fix warning caused by duplicate kmem_cache creation in kmem_buckets_create Commit b035f5a6d852 (\"mm: slab: reduce the kmalloc() minimum alignment if DMA bouncing possible\") reduced ARCH_KMALLOC_MINALIGN to 8 on arm64. However, with KASAN_HW_TAGS enabled, arch_slab_minalign() becomes 16. This causes kmalloc_caches[*][8] to be aliased to kmalloc_caches[*][16], resulting in kmem_buckets_create() attempting to create a kmem_cache for size 16 twice. This duplication triggers warnings on boot: [ 2.325108] ------------[ cut here ]------------ [ 2.325135] kmem_cache of name 'memdup_user-16' already exists [ 2.325783] WARNING: CPU: 0 PID: 1 at mm/slab_common.c:107 __kmem_cache_create_args+0xb8/0x3b0 [ 2.327957] Modules linked in: [ 2.328550] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5mm-unstable-arm64+ #12 [ 2.328683] Hardware name: QEMU QEMU Virtual Machine, BIOS 2024.02-2 03/11/2024 [ 2.328790] pstate: 61000009 (nZCv daif -PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 2.328911] pc : __kmem_cache_create_args+0xb8/0x3b0 [ 2.328930] lr : __kmem_cache_create_args+0xb8/0x3b0 [ 2.328942] sp : ffff800083d6fc50 [ 2.328961] x29: ffff800083d6fc50 x28: f2ff0000c1674410 x27: ffff8000820b0598 [ 2.329061] x26: 000000007fffffff x25: 0000000000000010 x24: 0000000000002000 [ 2.329101] x23: ffff800083d6fce8 x22: ffff8000832222e8 x21: ffff800083222388 [ 2.329118] x20: f2ff0000c1674410 x19: f5ff0000c16364c0 x18: ffff800083d80030 [ 2.329135] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 2.329152] x14: 0000000000000000 x13: 0a73747369786520 x12: 79646165726c6120 [ 2.329169] x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : 0000000000000000 [ 2.329194] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 [ 2.329210] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 2.329226] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 2.329291] Call trace: [ 2.329407] __kmem_cache_create_args+0xb8/0x3b0 [ 2.329499] kmem_buckets_create+0xfc/0x320 [ 2.329526] init_user_buckets+0x34/0x78 [ 2.329540] do_one_initcall+0x64/0x3c8 [ 2.329550] kernel_init_freeable+0x26c/0x578 [ 2.329562] kernel_init+0x3c/0x258 [ 2.329574] ret_from_fork+0x10/0x20 [ 2.329698] ---[ end trace 0000000000000000 ]--- [ 2.403704] ------------[ cut here ]------------ [ 2.404716] kmem_cache of name 'msg_msg-16' already exists [ 2.404801] WARNING: CPU: 2 PID: 1 at mm/slab_common.c:107 __kmem_cache_create_args+0xb8/0x3b0 [ 2.404842] Modules linked in: [ 2.404971] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.12.0-rc5mm-unstable-arm64+ #12 [ 2.405026] Tainted: [W]=WARN [ 2.405043] Hardware name: QEMU QEMU Virtual Machine, BIOS 2024.02-2 03/11/2024 [ 2.405057] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2.405079] pc : __kmem_cache_create_args+0xb8/0x3b0 [ 2.405100] lr : __kmem_cache_create_args+0xb8/0x3b0 [ 2.405111] sp : ffff800083d6fc50 [ 2.405115] x29: ffff800083d6fc50 x28: fbff0000c1674410 x27: ffff8000820b0598 [ 2.405135] x26: 000000000000ffd0 x25: 0000000000000010 x24: 0000000000006000 [ 2.405153] x23: ffff800083d6fce8 x22: ffff8000832222e8 x21: ffff800083222388 [ 2.405169] x20: fbff0000c1674410 x19: fdff0000c163d6c0 x18: ffff800083d80030 [ 2.405185] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 2.405201] x14: 0000000000000000 x13: 0a73747369786520 x12: 79646165726c6120 [ 2.405217] x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : 0000000000000000 [ 2.405233] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 [ 2.405248] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 2.405271] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 2.405287] Call trace: [ 2 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50275", "url": "https://ubuntu.com/security/CVE-2024-50275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64/sve: Discard stale CPU state when handling SVE traps The logic for handling SVE traps manipulates saved FPSIMD/SVE state incorrectly, and a race with preemption can result in a task having TIF_SVE set and TIF_FOREIGN_FPSTATE clear even though the live CPU state is stale (e.g. with SVE traps enabled). This has been observed to result in warnings from do_sve_acc() where SVE traps are not expected while TIF_SVE is set: | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* SVE access shouldn't have trapped */ Warnings of this form have been reported intermittently, e.g. https://lore.kernel.org/linux-arm-kernel/CA+G9fYtEGe_DhY2Ms7+L7NKsLYUomGsgqpdBj+QwDLeSg=JhGg@mail.gmail.com/ https://lore.kernel.org/linux-arm-kernel/000000000000511e9a060ce5a45c@google.com/ The race can occur when the SVE trap handler is preempted before and after manipulating the saved FPSIMD/SVE state, starting and ending on the same CPU, e.g. | void do_sve_acc(unsigned long esr, struct pt_regs *regs) | { | // Trap on CPU 0 with TIF_SVE clear, SVE 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(); | | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* SVE access shouldn't have trapped */ | | sve_init_regs() { | if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) { | ... | } else { | fpsimd_to_sve(current); | current->thread.fp_type = FP_STATE_SVE; | } | } | | 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 SVE 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.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50276", "url": "https://ubuntu.com/security/CVE-2024-50276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: vertexcom: mse102x: Fix possible double free of TX skb The scope of the TX skb is wider than just mse102x_tx_frame_spi(), so in case the TX skb room needs to be expanded, we should free the the temporary skb instead of the original skb. Otherwise the original TX skb pointer would be freed again in mse102x_tx_work(), which leads to crashes: Internal error: Oops: 0000000096000004 [#2] PREEMPT SMP CPU: 0 PID: 712 Comm: kworker/0:1 Tainted: G D 6.6.23 Hardware name: chargebyte Charge SOM DC-ONE (DT) Workqueue: events mse102x_tx_work [mse102x] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_release_data+0xb8/0x1d8 lr : skb_release_data+0x1ac/0x1d8 sp : ffff8000819a3cc0 x29: ffff8000819a3cc0 x28: ffff0000046daa60 x27: ffff0000057f2dc0 x26: ffff000005386c00 x25: 0000000000000002 x24: 00000000ffffffff x23: 0000000000000000 x22: 0000000000000001 x21: ffff0000057f2e50 x20: 0000000000000006 x19: 0000000000000000 x18: ffff00003fdacfcc x17: e69ad452d0c49def x16: 84a005feff870102 x15: 0000000000000000 x14: 000000000000024a x13: 0000000000000002 x12: 0000000000000000 x11: 0000000000000400 x10: 0000000000000930 x9 : ffff00003fd913e8 x8 : fffffc00001bc008 x7 : 0000000000000000 x6 : 0000000000000008 x5 : ffff00003fd91340 x4 : 0000000000000000 x3 : 0000000000000009 x2 : 00000000fffffffe x1 : 0000000000000000 x0 : 0000000000000000 Call trace: skb_release_data+0xb8/0x1d8 kfree_skb_reason+0x48/0xb0 mse102x_tx_work+0x164/0x35c [mse102x] process_one_work+0x138/0x260 worker_thread+0x32c/0x438 kthread+0x118/0x11c ret_from_fork+0x10/0x20 Code: aa1303e0 97fffab6 72001c1f 54000141 (f9400660)", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53066", "url": "https://ubuntu.com/security/CVE-2024-53066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfs: Fix KMSAN warning in decode_getfattr_attrs() Fix the following KMSAN warning: CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G B Tainted: [B]=BAD_PAGE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) ===================================================== ===================================================== BUG: KMSAN: uninit-value in decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_generic+0x806/0xb00 nfs4_xdr_dec_getattr+0x1de/0x240 rpcauth_unwrap_resp_decode+0xab/0x100 rpcauth_unwrap_resp+0x95/0xc0 call_decode+0x4ff/0xb50 __rpc_execute+0x57b/0x19d0 rpc_execute+0x368/0x5e0 rpc_run_task+0xcfe/0xee0 nfs4_proc_getattr+0x5b5/0x990 __nfs_revalidate_inode+0x477/0xd00 nfs_access_get_cached+0x1021/0x1cc0 nfs_do_access+0x9f/0xae0 nfs_permission+0x1e4/0x8c0 inode_permission+0x356/0x6c0 link_path_walk+0x958/0x1330 path_lookupat+0xce/0x6b0 filename_lookup+0x23e/0x770 vfs_statx+0xe7/0x970 vfs_fstatat+0x1f2/0x2c0 __se_sys_newfstatat+0x67/0x880 __x64_sys_newfstatat+0xbd/0x120 x64_sys_call+0x1826/0x3cf0 do_syscall_64+0xd0/0x1b0 entry_SYSCALL_64_after_hwframe+0x77/0x7f The KMSAN warning is triggered in decode_getfattr_attrs(), when calling decode_attr_mdsthreshold(). It appears that fattr->mdsthreshold is not initialized. Fix the issue by initializing fattr->mdsthreshold to NULL in nfs_fattr_init().", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53067", "url": "https://ubuntu.com/security/CVE-2024-53067", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Start the RTC update work later The RTC update work involves runtime resuming the UFS controller. Hence, only start the RTC update work after runtime power management in the UFS driver has been fully initialized. This patch fixes the following kernel crash: Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP Workqueue: events ufshcd_rtc_work Call trace: _raw_spin_lock_irqsave+0x34/0x8c (P) pm_runtime_get_if_active+0x24/0x9c (L) pm_runtime_get_if_active+0x24/0x9c ufshcd_rtc_work+0x138/0x1b4 process_one_work+0x148/0x288 worker_thread+0x2cc/0x3d4 kthread+0x110/0x114 ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50277", "url": "https://ubuntu.com/security/CVE-2024-50277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: fix a crash if blk_alloc_disk fails If blk_alloc_disk fails, the variable md->disk is set to an error value. cleanup_mapped_device will see that md->disk is non-NULL and it will attempt to access it, causing a crash on this statement \"md->disk->private_data = NULL;\".", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50278", "url": "https://ubuntu.com/security/CVE-2024-50278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix potential out-of-bounds access on the first resume Out-of-bounds access occurs if the fast device is expanded unexpectedly before the first-time resume of the cache table. This happens because expanding the fast device requires reloading the cache table for cache_create to allocate new in-core data structures that fit the new size, and the check in cache_preresume is not performed during the first resume, leading to the issue. Reproduce steps: 1. prepare component devices: 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\" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct 2. load a cache table of 512 cache blocks, and deliberately expand the fast device before resuming the cache, making the in-core data structures inadequate. dmsetup create cache --notable dmsetup reload cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" dmsetup reload cdata --table \"0 131072 linear /dev/sdc 8192\" dmsetup resume cdata dmsetup resume cache 3. suspend the cache to write out the in-core dirty bitset and hint array, leading to out-of-bounds access to the dirty bitset at offset 0x40: dmsetup suspend cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80 Read of size 8 at addr ffffc90000085040 by task dmsetup/90 (...snip...) The buggy address belongs to the virtual mapping at [ffffc90000085000, ffffc90000087000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by checking the size change on the first resume.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50279", "url": "https://ubuntu.com/security/CVE-2024-50279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix out-of-bounds access to the dirty bitset when resizing dm-cache checks the dirty bits of the cache blocks to be dropped when shrinking the fast device, but an index bug in bitset iteration causes out-of-bounds access. Reproduce steps: 1. create a cache device of 1024 cache blocks (128 bytes dirty bitset) dmsetup create cmeta --table \"0 8192 linear /dev/sdc 0\" dmsetup create cdata --table \"0 131072 linear /dev/sdc 8192\" dmsetup create corig --table \"0 524288 linear /dev/sdc 262144\" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" 2. shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80) dmsetup suspend cache dmsetup reload cdata --table \"0 65536 linear /dev/sdc 8192\" dmsetup resume cdata dmsetup resume cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131 (...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by making the index post-incremented.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50280", "url": "https://ubuntu.com/security/CVE-2024-50280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix flushing uninitialized delayed_work on cache_ctr error An unexpected WARN_ON from flush_work() may occur when cache creation fails, caused by destroying the uninitialized delayed_work waker in the error path of cache_create(). For example, the warning appears on the superblock checksum error. Reproduce steps: 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\" dd if=/dev/urandom of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" Kernel logs: (snip) WARNING: CPU: 0 PID: 84 at kernel/workqueue.c:4178 __flush_work+0x5d4/0x890 Fix by pulling out the cancel_delayed_work_sync() from the constructor's error path. This patch doesn't affect the use-after-free fix for concurrent dm_resume and dm_destroy (commit 6a459d8edbdb (\"dm cache: Fix UAF in destroy()\")) as cache_dtr is not changed.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50281", "url": "https://ubuntu.com/security/CVE-2024-50281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: trusted: dcp: fix NULL dereference in AEAD crypto operation When sealing or unsealing a key blob we currently do not wait for the AEAD cipher operation to finish and simply return after submitting the request. If there is some load on the system we can exit before the cipher operation is done and the buffer we read from/write to is already removed from the stack. This will e.g. result in NULL pointer dereference errors in the DCP driver during blob creation. Fix this by waiting for the AEAD cipher operation to finish before resuming the seal and unseal calls.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50282", "url": "https://ubuntu.com/security/CVE-2024-50282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read() Avoid a possible buffer overflow if size is larger than 4K. (cherry picked from commit f5d873f5825b40d886d03bd2aede91d4cf002434)", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53071", "url": "https://ubuntu.com/security/CVE-2024-53071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Be stricter about IO mapping flags The current panthor_device_mmap_io() implementation has two issues: 1. For mapping DRM_PANTHOR_USER_FLUSH_ID_MMIO_OFFSET, panthor_device_mmap_io() bails if VM_WRITE is set, but does not clear VM_MAYWRITE. That means userspace can use mprotect() to make the mapping writable later on. This is a classic Linux driver gotcha. I don't think this actually has any impact in practice: When the GPU is powered, writes to the FLUSH_ID seem to be ignored; and when the GPU is not powered, the dummy_latest_flush page provided by the driver is deliberately designed to not do any flushes, so the only thing writing to the dummy_latest_flush could achieve would be to make *more* flushes happen. 2. panthor_device_mmap_io() does not block MAP_PRIVATE mappings (which are mappings without the VM_SHARED flag). MAP_PRIVATE in combination with VM_MAYWRITE indicates that the VMA has copy-on-write semantics, which for VM_PFNMAP are semi-supported but fairly cursed. In particular, in such a mapping, the driver can only install PTEs during mmap() by calling remap_pfn_range() (because remap_pfn_range() wants to **store the physical address of the mapped physical memory into the vm_pgoff of the VMA**); installing PTEs later on with a fault handler (as panthor does) is not supported in private mappings, and so if you try to fault in such a mapping, vmf_insert_pfn_prot() splats when it hits a BUG() check. Fix it by clearing the VM_MAYWRITE flag (userspace writing to the FLUSH_ID doesn't make sense) and requiring VM_SHARED (copy-on-write semantics for the FLUSH_ID don't make sense). Reproducers for both scenarios are in the notes of my patch on the mailing list; I tested that these bugs exist on a Rock 5B machine. Note that I only compile-tested the patch, I haven't tested it; I don't have a working kernel build setup for the test machine yet. Please test it before applying it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53080", "url": "https://ubuntu.com/security/CVE-2024-53080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Lock XArray when getting entries for the VM Similar to commit cac075706f29 (\"drm/panthor: Fix race when converting group handle to group object\") we need to use the XArray's internal locking when retrieving a vm pointer from there. v2: Removed part of the patch that was trying to protect fetching the heap pointer from XArray, as that operation is protected by the @pool->lock.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53084", "url": "https://ubuntu.com/security/CVE-2024-53084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Break an object reference loop When remaining resources are being cleaned up on driver close, outstanding VM mappings may result in resources being leaked, due to an object reference loop, as shown below, with each object (or set of objects) referencing the object below it: PVR GEM Object GPU scheduler \"finished\" fence GPU scheduler “scheduled” fence PVR driver “done” fence PVR Context PVR VM Context PVR VM Mappings PVR GEM Object The reference that the PVR VM Context has on the VM mappings is a soft one, in the sense that the freeing of outstanding VM mappings is done as part of VM context destruction; no reference counts are involved, as is the case for all the other references in the loop. To break the reference loop during cleanup, free the outstanding VM mappings before destroying the PVR Context associated with the VM context.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53085", "url": "https://ubuntu.com/security/CVE-2024-53085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: Lock TPM chip in tpm_pm_suspend() first Setting TPM_CHIP_FLAG_SUSPENDED in the end of tpm_pm_suspend() can be racy according, as this leaves window for tpm_hwrng_read() to be called while the operation is in progress. The recent bug report gives also evidence of this behaviour. Aadress this by locking the TPM chip before checking any chip->flags both in tpm_pm_suspend() and tpm_hwrng_read(). Move TPM_CHIP_FLAG_SUSPENDED check inside tpm_get_random() so that it will be always checked only when the lock is reserved.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53086", "url": "https://ubuntu.com/security/CVE-2024-53086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Drop VM dma-resv lock on xe_sync_in_fence_get failure in exec IOCTL Upon failure all locks need to be dropped before returning to the user. (cherry picked from commit 7d1a4258e602ffdce529f56686925034c1b3b095)", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53087", "url": "https://ubuntu.com/security/CVE-2024-53087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix possible exec queue leak in exec IOCTL In a couple of places after an exec queue is looked up the exec IOCTL returns on input errors without dropping the exec queue ref. Fix this ensuring the exec queue ref is dropped on input error. (cherry picked from commit 07064a200b40ac2195cb6b7b779897d9377e5e6f)", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50283", "url": "https://ubuntu.com/security/CVE-2024-50283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-use-after-free in smb3_preauth_hash_rsp ksmbd_user_session_put should be called under smb3_preauth_hash_rsp(). It will avoid freeing session before calling smb3_preauth_hash_rsp().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50284", "url": "https://ubuntu.com/security/CVE-2024-50284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix the missing xa_store error check xa_store() can fail, it return xa_err(-EINVAL) if the entry cannot be stored in an XArray, or xa_err(-ENOMEM) if memory allocation failed, so check error for xa_store() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50285", "url": "https://ubuntu.com/security/CVE-2024-50285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: check outstanding simultaneous SMB operations If Client send simultaneous SMB operations to ksmbd, It exhausts too much memory through the \"ksmbd_work_cache”. It will cause OOM issue. ksmbd has a credit mechanism but it can't handle this problem. This patch add the check if it exceeds max credits to prevent this problem by assuming that one smb request consumes at least one credit.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50286", "url": "https://ubuntu.com/security/CVE-2024-50286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-use-after-free in ksmbd_smb2_session_create There is a race condition between ksmbd_smb2_session_create and ksmbd_expire_session. This patch add missing sessions_table_lock while adding/deleting session from global session table.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50287", "url": "https://ubuntu.com/security/CVE-2024-50287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-tpg: prevent the risk of a division by zero As reported by Coverity, the logic at tpg_precalculate_line() blindly rescales the buffer even when scaled_witdh is equal to zero. If this ever happens, this will cause a division by zero. Instead, add a WARN_ON_ONCE() to trigger such cases and return without doing any precalculation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50288", "url": "https://ubuntu.com/security/CVE-2024-50288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: fix buffer overwrite when using > 32 buffers The maximum number of buffers that can be requested was increased to 64 for the video capture queue. But video capture used a must_blank array that was still sized for 32 (VIDEO_MAX_FRAME). This caused an out-of-bounds write when using buffer indices >= 32. Create a new define MAX_VID_CAP_BUFFERS that is used to access the must_blank array and set max_num_buffers for the video capture queue. This solves a crash reported by: \thttps://bugzilla.kernel.org/show_bug.cgi?id=219258", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50289", "url": "https://ubuntu.com/security/CVE-2024-50289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: av7110: fix a spectre vulnerability As warned by smatch: \tdrivers/staging/media/av7110/av7110_ca.c:270 dvb_ca_ioctl() warn: potential spectre issue 'av7110->ci_slot' [w] (local cap) There is a spectre-related vulnerability at the code. Fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50290", "url": "https://ubuntu.com/security/CVE-2024-50290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx24116: prevent overflows on SNR calculus as reported by Coverity, if reading SNR registers fail, a negative number will be returned, causing an underflow when reading SNR registers. Prevent that.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53061", "url": "https://ubuntu.com/security/CVE-2024-53061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: s5p-jpeg: prevent buffer overflows The current logic allows word to be less than 2. If this happens, there will be buffer overflows, as reported by smatch. Add extra checks to prevent it. While here, remove an unused word = 0 assignment.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53081", "url": "https://ubuntu.com/security/CVE-2024-53081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ar0521: don't overflow when checking PLL values The PLL checks are comparing 64 bit integers with 32 bit ones, as reported by Coverity. Depending on the values of the variables, this may underflow. Fix it ensuring that both sides of the expression are u64.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53062", "url": "https://ubuntu.com/security/CVE-2024-53062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mgb4: protect driver against spectre Frequency range is set from sysfs via frequency_range_store(), being vulnerable to spectre, as reported by smatch: \tdrivers/media/pci/mgb4/mgb4_cmt.c:231 mgb4_cmt_set_vin_freq_range() warn: potential spectre issue 'cmt_vals_in' [r] \tdrivers/media/pci/mgb4/mgb4_cmt.c:238 mgb4_cmt_set_vin_freq_range() warn: possible spectre second half. 'reg_set' Fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50291", "url": "https://ubuntu.com/security/CVE-2024-50291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvb-core: add missing buffer index check dvb_vb2_expbuf() didn't check if the given buffer index was for a valid buffer. Add this check.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50292", "url": "https://ubuntu.com/security/CVE-2024-50292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: stm32: spdifrx: fix dma channel release in stm32_spdifrx_remove In case of error when requesting ctrl_chan DMA channel, ctrl_chan is not null. So the release of the dma channel leads to the following issue: [ 4.879000] st,stm32-spdifrx 500d0000.audio-controller: dma_request_slave_channel error -19 [ 4.888975] Unable to handle kernel NULL pointer dereference at virtual address 000000000000003d [...] [ 5.096577] Call trace: [ 5.099099] dma_release_channel+0x24/0x100 [ 5.103235] stm32_spdifrx_remove+0x24/0x60 [snd_soc_stm32_spdifrx] [ 5.109494] stm32_spdifrx_probe+0x320/0x4c4 [snd_soc_stm32_spdifrx] To avoid this issue, release channel only if the pointer is valid.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53063", "url": "https://ubuntu.com/security/CVE-2024-53063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvbdev: prevent the risk of out of memory access The dvbdev contains a static variable used to store dvb minors. The behavior of it depends if CONFIG_DVB_DYNAMIC_MINORS is set or not. When not set, dvb_register_device() won't check for boundaries, as it will rely that a previous call to dvb_register_adapter() would already be enforcing it. On a similar way, dvb_device_open() uses the assumption that the register functions already did the needed checks. This can be fragile if some device ends using different calls. This also generate warnings on static check analysers like Coverity. So, add explicit guards to prevent potential risk of OOM issues.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50293", "url": "https://ubuntu.com/security/CVE-2024-50293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: do not leave a dangling sk pointer in __smc_create() Thanks to commit 4bbd360a5084 (\"socket: Print pf->create() when it does not clear sock->sk on failure.\"), syzbot found an issue with AF_SMC: smc_create must clear sock->sk on failure, family: 43, type: 1, protocol: 0 WARNING: CPU: 0 PID: 5827 at net/socket.c:1565 __sock_create+0x96f/0xa30 net/socket.c:1563 Modules linked in: CPU: 0 UID: 0 PID: 5827 Comm: syz-executor259 Not tainted 6.12.0-rc6-next-20241106-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:__sock_create+0x96f/0xa30 net/socket.c:1563 Code: 03 00 74 08 4c 89 e7 e8 4f 3b 85 f8 49 8b 34 24 48 c7 c7 40 89 0c 8d 8b 54 24 04 8b 4c 24 0c 44 8b 44 24 08 e8 32 78 db f7 90 <0f> 0b 90 90 e9 d3 fd ff ff 89 e9 80 e1 07 fe c1 38 c1 0f 8c ee f7 RSP: 0018:ffffc90003e4fda0 EFLAGS: 00010246 RAX: 099c6f938c7f4700 RBX: 1ffffffff1a595fd RCX: ffff888034823c00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 00000000ffffffe9 R08: ffffffff81567052 R09: 1ffff920007c9f50 R10: dffffc0000000000 R11: fffff520007c9f51 R12: ffffffff8d2cafe8 R13: 1ffffffff1a595fe R14: ffffffff9a789c40 R15: ffff8880764298c0 FS: 000055557b518380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa62ff43225 CR3: 0000000031628000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: sock_create net/socket.c:1616 [inline] __sys_socket_create net/socket.c:1653 [inline] __sys_socket+0x150/0x3c0 net/socket.c:1700 __do_sys_socket net/socket.c:1714 [inline] __se_sys_socket net/socket.c:1712 [inline] For reference, see commit 2d859aff775d (\"Merge branch 'do-not-leave-dangling-sk-pointers-in-pf-create-functions'\")", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50294", "url": "https://ubuntu.com/security/CVE-2024-50294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix missing locking causing hanging calls If a call gets aborted (e.g. because kafs saw a signal) between it being queued for connection and the I/O thread picking up the call, the abort will be prioritised over the connection and it will be removed from local->new_client_calls by rxrpc_disconnect_client_call() without a lock being held. This may cause other calls on the list to disappear if a race occurs. Fix this by taking the client_call_lock when removing a call from whatever list its ->wait_link happens to be on.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50295", "url": "https://ubuntu.com/security/CVE-2024-50295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: arc: fix the device for dma_map_single/dma_unmap_single The ndev->dev and pdev->dev aren't the same device, use ndev->dev.parent which has dma_mask, ndev->dev.parent is just pdev->dev. Or it would cause the following issue: [ 39.933526] ------------[ cut here ]------------ [ 39.938414] WARNING: CPU: 1 PID: 501 at kernel/dma/mapping.c:149 dma_map_page_attrs+0x90/0x1f8", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53082", "url": "https://ubuntu.com/security/CVE-2024-53082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_net: Add hash_key_length check Add hash_key_length check in virtnet_probe() to avoid possible out of bound errors when setting/reading the hash key.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50296", "url": "https://ubuntu.com/security/CVE-2024-50296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash when uninstalling driver When the driver is uninstalled and the VF is disabled concurrently, a kernel crash occurs. The reason is that the two actions call function pci_disable_sriov(). The num_VFs is checked to determine whether to release the corresponding resources. During the second calling, num_VFs is not 0 and the resource release function is called. However, the corresponding resource has been released during the first invoking. Therefore, the problem occurs: [15277.839633][T50670] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ... [15278.131557][T50670] Call trace: [15278.134686][T50670] klist_put+0x28/0x12c [15278.138682][T50670] klist_del+0x14/0x20 [15278.142592][T50670] device_del+0xbc/0x3c0 [15278.146676][T50670] pci_remove_bus_device+0x84/0x120 [15278.151714][T50670] pci_stop_and_remove_bus_device+0x6c/0x80 [15278.157447][T50670] pci_iov_remove_virtfn+0xb4/0x12c [15278.162485][T50670] sriov_disable+0x50/0x11c [15278.166829][T50670] pci_disable_sriov+0x24/0x30 [15278.171433][T50670] hnae3_unregister_ae_algo_prepare+0x60/0x90 [hnae3] [15278.178039][T50670] hclge_exit+0x28/0xd0 [hclge] [15278.182730][T50670] __se_sys_delete_module.isra.0+0x164/0x230 [15278.188550][T50670] __arm64_sys_delete_module+0x1c/0x30 [15278.193848][T50670] invoke_syscall+0x50/0x11c [15278.198278][T50670] el0_svc_common.constprop.0+0x158/0x164 [15278.203837][T50670] do_el0_svc+0x34/0xcc [15278.207834][T50670] el0_svc+0x20/0x30 For details, see the following figure. rmmod hclge disable VFs ---------------------------------------------------- hclge_exit() sriov_numvfs_store() ... device_lock() pci_disable_sriov() hns3_pci_sriov_configure() pci_disable_sriov() sriov_disable() sriov_disable() if !num_VFs : if !num_VFs : return; return; sriov_del_vfs() sriov_del_vfs() ... ... klist_put() klist_put() ... ... num_VFs = 0; num_VFs = 0; device_unlock(); In this patch, when driver is removing, we get the device_lock() to protect num_VFs, just like sriov_numvfs_store().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53088", "url": "https://ubuntu.com/security/CVE-2024-53088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: fix race condition by adding filter's intermediate sync state Fix a race condition in the i40e driver that leads to MAC/VLAN filters becoming corrupted and leaking. Address the issue that occurs under heavy load when multiple threads are concurrently modifying MAC/VLAN filters by setting mac and port VLAN. 1. Thread T0 allocates a filter in i40e_add_filter() within i40e_ndo_set_vf_port_vlan(). 2. Thread T1 concurrently frees the filter in __i40e_del_filter() within i40e_ndo_set_vf_mac(). 3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which refers to the already freed filter memory, causing corruption. Reproduction steps: 1. Spawn multiple VFs. 2. Apply a concurrent heavy load by running parallel operations to change MAC addresses on the VFs and change port VLANs on the host. 3. Observe errors in dmesg: \"Error I40E_AQ_RC_ENOSPC adding RX filters on VF XX, \tplease set promiscuous on manually for VF XX\". Exact code for stable reproduction Intel can't open-source now. The fix involves implementing a new intermediate filter state, I40E_FILTER_NEW_SYNC, for the time when a filter is on a tmp_add_list. These filters cannot be deleted from the hash list directly but must be removed using the full process.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50297", "url": "https://ubuntu.com/security/CVE-2024-50297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: xilinx: axienet: Enqueue Tx packets in dql before dmaengine starts Enqueue packets in dql after dma engine starts causes race condition. Tx transfer starts once dma engine is started and may execute dql dequeue in completion before it gets queued. It results in following kernel crash while running iperf stress test: kernel BUG at lib/dynamic_queue_limits.c:99! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP pc : dql_completed+0x238/0x248 lr : dql_completed+0x3c/0x248 Call trace: dql_completed+0x238/0x248 axienet_dma_tx_cb+0xa0/0x170 xilinx_dma_do_tasklet+0xdc/0x290 tasklet_action_common+0xf8/0x11c tasklet_action+0x30/0x3c handle_softirqs+0xf8/0x230 Start dmaengine after enqueue in dql fixes the crash.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50298", "url": "https://ubuntu.com/security/CVE-2024-50298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: enetc: allocate vf_state during PF probes In the previous implementation, vf_state is allocated memory only when VF is enabled. However, net_device_ops::ndo_set_vf_mac() may be called before VF is enabled to configure the MAC address of VF. If this is the case, enetc_pf_set_vf_mac() will access vf_state, resulting in access to a null pointer. The simplified error log is as follows. root@ls1028ardb:~# ip link set eno0 vf 1 mac 00:0c:e7:66:77:89 [ 173.543315] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 [ 173.637254] pc : enetc_pf_set_vf_mac+0x3c/0x80 Message from sy [ 173.641973] lr : do_setlink+0x4a8/0xec8 [ 173.732292] Call trace: [ 173.734740] enetc_pf_set_vf_mac+0x3c/0x80 [ 173.738847] __rtnl_newlink+0x530/0x89c [ 173.742692] rtnl_newlink+0x50/0x7c [ 173.746189] rtnetlink_rcv_msg+0x128/0x390 [ 173.750298] netlink_rcv_skb+0x60/0x130 [ 173.754145] rtnetlink_rcv+0x18/0x24 [ 173.757731] netlink_unicast+0x318/0x380 [ 173.761665] netlink_sendmsg+0x17c/0x3c8", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50299", "url": "https://ubuntu.com/security/CVE-2024-50299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: properly validate chunk size in sctp_sf_ootb() A size validation fix similar to that in Commit 50619dbf8db7 (\"sctp: add size validation when walking chunks\") is also required in sctp_sf_ootb() to address a crash reported by syzbot: BUG: KMSAN: uninit-value in sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_do_sm+0x181/0x93d0 net/sctp/sm_sideeffect.c:1166 sctp_endpoint_bh_rcv+0xc38/0xf90 net/sctp/endpointola.c:407 sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88 sctp_rcv+0x3831/0x3b20 net/sctp/input.c:243 sctp4_rcv+0x42/0x50 net/sctp/protocol.c:1159 ip_protocol_deliver_rcu+0xb51/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50300", "url": "https://ubuntu.com/security/CVE-2024-50300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: rtq2208: Fix uninitialized use of regulator_config Fix rtq2208 driver uninitialized use to cause kernel error.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50301", "url": "https://ubuntu.com/security/CVE-2024-50301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: security/keys: fix slab-out-of-bounds in key_task_permission KASAN reports an out of bounds read: BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline] BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362 CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0x107/0x167 lib/dump_stack.c:123 print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 __kuid_val include/linux/uidgid.h:36 [inline] uid_eq include/linux/uidgid.h:63 [inline] key_task_permission+0x394/0x410 security/keys/permission.c:54 search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793 This issue was also reported by syzbot. It can be reproduced by following these steps(more details [1]): 1. Obtain more than 32 inputs that have similar hashes, which ends with the pattern '0xxxxxxxe6'. 2. Reboot and add the keys obtained in step 1. The reproducer demonstrates how this issue happened: 1. In the search_nested_keyrings function, when it iterates through the slots in a node(below tag ascend_to_node), if the slot pointer is meta and node->back_pointer != NULL(it means a root), it will proceed to descend_to_node. However, there is an exception. If node is the root, and one of the slots points to a shortcut, it will be treated as a keyring. 2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function. However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as ASSOC_ARRAY_PTR_SUBTYPE_MASK. 3. When 32 keys with the similar hashes are added to the tree, the ROOT has keys with hashes that are not similar (e.g. slot 0) and it splits NODE A without using a shortcut. When NODE A is filled with keys that all hashes are xxe6, the keys are similar, NODE A will split with a shortcut. Finally, it forms the tree as shown below, where slot 6 points to a shortcut. NODE A +------>+---+ ROOT | | 0 | xxe6 +---+ | +---+ xxxx | 0 | shortcut : : xxe6 +---+ | +---+ xxe6 : : | | | xxe6 +---+ | +---+ | 6 |---+ : : xxe6 +---+ +---+ xxe6 : : | f | xxe6 +---+ +---+ xxe6 | f | +---+ 4. As mentioned above, If a slot(slot 6) of the root points to a shortcut, it may be mistakenly transferred to a key*, leading to a read out-of-bounds read. To fix this issue, one should jump to descend_to_node if the ptr is a shortcut, regardless of whether the node is root or not. [1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/ [jarkko: tweaked the commit message a bit to have an appropriate closes tag.]", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53072", "url": "https://ubuntu.com/security/CVE-2024-53072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/pmc: Detect when STB is not available Loading the amd_pmc module as: amd_pmc enable_stb=1 ...can result in the following messages in the kernel ring buffer: amd_pmc AMDI0009:00: SMU cmd failed. err: 0xff ioremap on RAM at 0x0000000000000000 - 0x0000000000ffffff WARNING: CPU: 10 PID: 2151 at arch/x86/mm/ioremap.c:217 __ioremap_caller+0x2cd/0x340 Further debugging reveals that this occurs when the requests for S2D_PHYS_ADDR_LOW and S2D_PHYS_ADDR_HIGH return a value of 0, indicating that the STB is inaccessible. To prevent the ioremap warning and provide clarity to the user, handle the invalid address and display an error message.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50302", "url": "https://ubuntu.com/security/CVE-2024-50302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: zero-initialize the report buffer Since the report buffer is used by all kinds of drivers in various ways, let's zero-initialize it during allocation to make sure that it can't be ever used to leak kernel memory via specially-crafted report.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53068", "url": "https://ubuntu.com/security/CVE-2024-53068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix slab-use-after-free in scmi_bus_notifier() The scmi_dev->name is released prematurely in __scmi_device_destroy(), which causes slab-use-after-free when accessing scmi_dev->name in scmi_bus_notifier(). So move the release of scmi_dev->name to scmi_device_release() to avoid slab-use-after-free. | BUG: KASAN: slab-use-after-free in strncmp+0xe4/0xec | Read of size 1 at addr ffffff80a482bcc0 by task swapper/0/1 | | CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.6.38-debug #1 | Hardware name: Qualcomm Technologies, Inc. SA8775P Ride (DT) | Call trace: | dump_backtrace+0x94/0x114 | show_stack+0x18/0x24 | dump_stack_lvl+0x48/0x60 | print_report+0xf4/0x5b0 | kasan_report+0xa4/0xec | __asan_report_load1_noabort+0x20/0x2c | strncmp+0xe4/0xec | scmi_bus_notifier+0x5c/0x54c | notifier_call_chain+0xb4/0x31c | blocking_notifier_call_chain+0x68/0x9c | bus_notify+0x54/0x78 | device_del+0x1bc/0x840 | device_unregister+0x20/0xb4 | __scmi_device_destroy+0xac/0x280 | scmi_device_destroy+0x94/0xd0 | scmi_chan_setup+0x524/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20 | | Allocated by task 1: | kasan_save_stack+0x2c/0x54 | kasan_set_track+0x2c/0x40 | kasan_save_alloc_info+0x24/0x34 | __kasan_kmalloc+0xa0/0xb8 | __kmalloc_node_track_caller+0x6c/0x104 | kstrdup+0x48/0x84 | kstrdup_const+0x34/0x40 | __scmi_device_create.part.0+0x8c/0x408 | scmi_device_create+0x104/0x370 | scmi_chan_setup+0x2a0/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20 | | Freed by task 1: | kasan_save_stack+0x2c/0x54 | kasan_set_track+0x2c/0x40 | kasan_save_free_info+0x38/0x5c | __kasan_slab_free+0xe8/0x164 | __kmem_cache_free+0x11c/0x230 | kfree+0x70/0x130 | kfree_const+0x20/0x40 | __scmi_device_destroy+0x70/0x280 | scmi_device_destroy+0x94/0xd0 | scmi_chan_setup+0x524/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53069", "url": "https://ubuntu.com/security/CVE-2024-53069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: qcom: scm: fix a NULL-pointer dereference Some SCM calls can be invoked with __scm being NULL (the driver may not have been and will not be probed as there's no SCM entry in device-tree). Make sure we don't dereference a NULL pointer.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50212", "url": "https://ubuntu.com/security/CVE-2024-50212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib: alloc_tag_module_unload must wait for pending kfree_rcu calls Ben Greear reports following splat: ------------[ cut here ]------------ net/netfilter/nf_nat_core.c:1114 module nf_nat func:nf_nat_register_fn has 256 allocated at module unload WARNING: CPU: 1 PID: 10421 at lib/alloc_tag.c:168 alloc_tag_module_unload+0x22b/0x3f0 Modules linked in: nf_nat(-) btrfs ufs qnx4 hfsplus hfs minix vfat msdos fat ... Hardware name: Default string Default string/SKYBAY, BIOS 5.12 08/04/2020 RIP: 0010:alloc_tag_module_unload+0x22b/0x3f0 codetag_unload_module+0x19b/0x2a0 ? codetag_load_module+0x80/0x80 nf_nat module exit calls kfree_rcu on those addresses, but the free operation is likely still pending by the time alloc_tag checks for leaks. Wait for outstanding kfree_rcu operations to complete before checking resolves this warning. Reproducer: unshare -n iptables-nft -t nat -A PREROUTING -p tcp grep nf_nat /proc/allocinfo # will list 4 allocations rmmod nft_chain_nat rmmod nf_nat # will WARN. [akpm@linux-foundation.org: add comment]", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53046", "url": "https://ubuntu.com/security/CVE-2024-53046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: dts: imx8ulp: correct the flexspi compatible string The flexspi on imx8ulp only has 16 LUTs, and imx8mm flexspi has 32 LUTs, so correct the compatible string here, otherwise will meet below error: [ 1.119072] ------------[ cut here ]------------ [ 1.123926] WARNING: CPU: 0 PID: 1 at drivers/spi/spi-nxp-fspi.c:855 nxp_fspi_exec_op+0xb04/0xb64 [ 1.133239] Modules linked in: [ 1.136448] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-rc6-next-20240902-00001-g131bf9439dd9 #69 [ 1.146821] Hardware name: NXP i.MX8ULP EVK (DT) [ 1.151647] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.158931] pc : nxp_fspi_exec_op+0xb04/0xb64 [ 1.163496] lr : nxp_fspi_exec_op+0xa34/0xb64 [ 1.168060] sp : ffff80008002b2a0 [ 1.171526] x29: ffff80008002b2d0 x28: 0000000000000000 x27: 0000000000000000 [ 1.179002] x26: ffff2eb645542580 x25: ffff800080610014 x24: ffff800080610000 [ 1.186480] x23: ffff2eb645548080 x22: 0000000000000006 x21: ffff2eb6455425e0 [ 1.193956] x20: 0000000000000000 x19: ffff80008002b5e0 x18: ffffffffffffffff [ 1.201432] x17: ffff2eb644467508 x16: 0000000000000138 x15: 0000000000000002 [ 1.208907] x14: 0000000000000000 x13: ffff2eb6400d8080 x12: 00000000ffffff00 [ 1.216378] x11: 0000000000000000 x10: ffff2eb6400d8080 x9 : ffff2eb697adca80 [ 1.223850] x8 : ffff2eb697ad3cc0 x7 : 0000000100000000 x6 : 0000000000000001 [ 1.231324] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000007a6 [ 1.238795] x2 : 0000000000000000 x1 : 00000000000001ce x0 : 00000000ffffff92 [ 1.246267] Call trace: [ 1.248824] nxp_fspi_exec_op+0xb04/0xb64 [ 1.253031] spi_mem_exec_op+0x3a0/0x430 [ 1.257139] spi_nor_read_id+0x80/0xcc [ 1.261065] spi_nor_scan+0x1ec/0xf10 [ 1.264901] spi_nor_probe+0x108/0x2fc [ 1.268828] spi_mem_probe+0x6c/0xbc [ 1.272574] spi_probe+0x84/0xe4 [ 1.275958] really_probe+0xbc/0x29c [ 1.279713] __driver_probe_device+0x78/0x12c [ 1.284277] driver_probe_device+0xd8/0x15c [ 1.288660] __device_attach_driver+0xb8/0x134 [ 1.293316] bus_for_each_drv+0x88/0xe8 [ 1.297337] __device_attach+0xa0/0x190 [ 1.301353] device_initial_probe+0x14/0x20 [ 1.305734] bus_probe_device+0xac/0xb0 [ 1.309752] device_add+0x5d0/0x790 [ 1.313408] __spi_add_device+0x134/0x204 [ 1.317606] of_register_spi_device+0x3b4/0x590 [ 1.322348] spi_register_controller+0x47c/0x754 [ 1.327181] devm_spi_register_controller+0x4c/0xa4 [ 1.332289] nxp_fspi_probe+0x1cc/0x2b0 [ 1.336307] platform_probe+0x68/0xc4 [ 1.340145] really_probe+0xbc/0x29c [ 1.343893] __driver_probe_device+0x78/0x12c [ 1.348457] driver_probe_device+0xd8/0x15c [ 1.352838] __driver_attach+0x90/0x19c [ 1.356857] bus_for_each_dev+0x7c/0xdc [ 1.360877] driver_attach+0x24/0x30 [ 1.364624] bus_add_driver+0xe4/0x208 [ 1.368552] driver_register+0x5c/0x124 [ 1.372573] __platform_driver_register+0x28/0x34 [ 1.377497] nxp_fspi_driver_init+0x1c/0x28 [ 1.381888] do_one_initcall+0x80/0x1c8 [ 1.385908] kernel_init_freeable+0x1c4/0x28c [ 1.390472] kernel_init+0x20/0x1d8 [ 1.394138] ret_from_fork+0x10/0x20 [ 1.397885] ---[ end trace 0000000000000000 ]--- [ 1.407908] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53052", "url": "https://ubuntu.com/security/CVE-2024-53052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/rw: fix missing NOWAIT check for O_DIRECT start write When io_uring starts a write, it'll call kiocb_start_write() to bump the super block rwsem, preventing any freezes from happening while that write is in-flight. The freeze side will grab that rwsem for writing, excluding any new writers from happening and waiting for existing writes to finish. But io_uring unconditionally uses kiocb_start_write(), which will block if someone is currently attempting to freeze the mount point. This causes a deadlock where freeze is waiting for previous writes to complete, but the previous writes cannot complete, as the task that is supposed to complete them is blocked waiting on starting a new write. This results in the following stuck trace showing that dependency with the write blocked starting a new write: task:fio state:D stack:0 pid:886 tgid:886 ppid:876 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_rwsem_wait+0x1e8/0x3f8 __percpu_down_read+0xe8/0x500 io_write+0xbb8/0xff8 io_issue_sqe+0x10c/0x1020 io_submit_sqes+0x614/0x2110 __arm64_sys_io_uring_enter+0x524/0x1038 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 INFO: task fsfreeze:7364 blocked for more than 15 seconds. Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963 with the attempting freezer stuck trying to grab the rwsem: task:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_down_write+0x2b0/0x680 freeze_super+0x248/0x8a8 do_vfs_ioctl+0x149c/0x1b18 __arm64_sys_ioctl+0xd0/0x1a0 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 Fix this by having the io_uring side honor IOCB_NOWAIT, and only attempt a blocking grab of the super block rwsem if it isn't set. For normal issue where IOCB_NOWAIT would always be set, this returns -EAGAIN which will have io_uring core issue a blocking attempt of the write. That will in turn also get completions run, ensuring forward progress. Since freezing requires CAP_SYS_ADMIN in the first place, this isn't something that can be triggered by a regular user.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50213", "url": "https://ubuntu.com/security/CVE-2024-50213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tests: hdmi: Fix memory leaks in drm_display_mode_from_cea_vic() modprobe drm_hdmi_state_helper_test and then rmmod it, the following memory leak occurs. The `mode` allocated in drm_mode_duplicate() called by drm_display_mode_from_cea_vic() is not freed, which cause the memory leak: \tunreferenced object 0xffffff80ccd18100 (size 128): \t comm \"kunit_try_catch\", pid 1851, jiffies 4295059695 \t hex dump (first 32 bytes): \t 57 62 00 00 80 02 90 02 f0 02 20 03 00 00 e0 01 Wb........ ..... \t ea 01 ec 01 0d 02 00 00 0a 00 00 00 00 00 00 00 ................ \t backtrace (crc c2f1aa95): \t [<000000000f10b11b>] kmemleak_alloc+0x34/0x40 \t [<000000001cd4cf73>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<00000000f1f3cffa>] drm_mode_duplicate+0x44/0x19c \t [<000000008cbeef13>] drm_display_mode_from_cea_vic+0x88/0x98 \t [<0000000019daaacf>] 0xffffffedc11ae69c \t [<000000000aad0f85>] kunit_try_run_case+0x13c/0x3ac \t [<00000000a9210bac>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<000000000a0b2e9e>] kthread+0x2e8/0x374 \t [<00000000bd668858>] ret_from_fork+0x10/0x20 \t...... Free `mode` by using drm_kunit_display_mode_from_cea_vic() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50214", "url": "https://ubuntu.com/security/CVE-2024-50214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/connector: hdmi: Fix memory leak in drm_display_mode_from_cea_vic() modprobe drm_connector_test and then rmmod drm_connector_test, the following memory leak occurs. The `mode` allocated in drm_mode_duplicate() called by drm_display_mode_from_cea_vic() is not freed, which cause the memory leak: \tunreferenced object 0xffffff80cb0ee400 (size 128): \t comm \"kunit_try_catch\", pid 1948, jiffies 4294950339 \t hex dump (first 32 bytes): \t 14 44 02 00 80 07 d8 07 04 08 98 08 00 00 38 04 .D............8. \t 3c 04 41 04 65 04 00 00 05 00 00 00 00 00 00 00 <.A.e........... \t backtrace (crc 90e9585c): \t [<00000000ec42e3d7>] kmemleak_alloc+0x34/0x40 \t [<00000000d0ef055a>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<00000000c2062161>] drm_mode_duplicate+0x44/0x19c \t [<00000000f96c74aa>] drm_display_mode_from_cea_vic+0x88/0x98 \t [<00000000d8f2c8b4>] 0xffffffdc982a4868 \t [<000000005d164dbc>] kunit_try_run_case+0x13c/0x3ac \t [<000000006fb23398>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<000000006ea56ca0>] kthread+0x2e8/0x374 \t [<000000000676063f>] ret_from_fork+0x10/0x20 \t...... Free `mode` by using drm_kunit_display_mode_from_cea_vic() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50215", "url": "https://ubuntu.com/security/CVE-2024-50215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: assign dh_key to NULL after kfree_sensitive ctrl->dh_key might be used across multiple calls to nvmet_setup_dhgroup() for the same controller. So it's better to nullify it after release on error path in order to avoid double free later in nvmet_destroy_auth(). Found by Linux Verification Center (linuxtesting.org) with Svace.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50216", "url": "https://ubuntu.com/security/CVE-2024-50216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix finding a last resort AG in xfs_filestream_pick_ag When the main loop in xfs_filestream_pick_ag fails to find a suitable AG it tries to just pick the online AG. But the loop for that uses args->pag as loop iterator while the later code expects pag to be set. Fix this by reusing the max_pag case for this last resort, and also add a check for impossible case of no AG just to make sure that the uninitialized pag doesn't even escape in theory.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50217", "url": "https://ubuntu.com/security/CVE-2024-50217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free of block device file in __btrfs_free_extra_devids() Mounting btrfs from two images (which have the same one fsid and two different dev_uuids) in certain executing order may trigger an UAF for variable 'device->bdev_file' in __btrfs_free_extra_devids(). And following are the details: 1. Attach image_1 to loop0, attach image_2 to loop1, and scan btrfs devices by ioctl(BTRFS_IOC_SCAN_DEV): / btrfs_device_1 ? loop0 fs_device \\ btrfs_device_2 ? loop1 2. mount /dev/loop0 /mnt btrfs_open_devices btrfs_device_1->bdev_file = btrfs_get_bdev_and_sb(loop0) btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree fail: btrfs_close_devices // -ENOMEM \t btrfs_close_bdev(btrfs_device_1) fput(btrfs_device_1->bdev_file) \t // btrfs_device_1->bdev_file is freed \t btrfs_close_bdev(btrfs_device_2) fput(btrfs_device_2->bdev_file) 3. mount /dev/loop1 /mnt btrfs_open_devices btrfs_get_bdev_and_sb(&bdev_file) // EIO, btrfs_device_1->bdev_file is not assigned, // which points to a freed memory area btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree btrfs_free_extra_devids if (btrfs_device_1->bdev_file) fput(btrfs_device_1->bdev_file) // UAF ! Fix it by setting 'device->bdev_file' as 'NULL' after closing the btrfs_device in btrfs_close_one_device().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53043", "url": "https://ubuntu.com/security/CVE-2024-53043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mctp i2c: handle NULL header address daddr can be NULL if there is no neighbour table entry present, in that case the tx packet should be dropped. saddr will usually be set by MCTP core, but check for NULL in case a packet is transmitted by a different protocol.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50303", "url": "https://ubuntu.com/security/CVE-2024-50303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: resource,kexec: walk_system_ram_res_rev must retain resource flags walk_system_ram_res_rev() erroneously discards resource flags when passing the information to the callback. This causes systems with IORESOURCE_SYSRAM_DRIVER_MANAGED memory to have these resources selected during kexec to store kexec buffers if that memory happens to be at placed above normal system ram. This leads to undefined behavior after reboot. If the kexec buffer is never touched, nothing happens. If the kexec buffer is touched, it could lead to a crash (like below) or undefined behavior. Tested on a system with CXL memory expanders with driver managed memory, TPM enabled, and CONFIG_IMA_KEXEC=y. Adding printk's showed the flags were being discarded and as a result the check for IORESOURCE_SYSRAM_DRIVER_MANAGED passes. find_next_iomem_res: name(System RAM (kmem)) \t\t start(10000000000) \t\t end(1034fffffff) \t\t flags(83000200) locate_mem_hole_top_down: start(10000000000) end(1034fffffff) flags(0) [.] BUG: unable to handle page fault for address: ffff89834ffff000 [.] #PF: supervisor read access in kernel mode [.] #PF: error_code(0x0000) - not-present page [.] PGD c04c8bf067 P4D c04c8bf067 PUD c04c8be067 PMD 0 [.] Oops: 0000 [#1] SMP [.] RIP: 0010:ima_restore_measurement_list+0x95/0x4b0 [.] RSP: 0018:ffffc900000d3a80 EFLAGS: 00010286 [.] RAX: 0000000000001000 RBX: 0000000000000000 RCX: ffff89834ffff000 [.] RDX: 0000000000000018 RSI: ffff89834ffff000 RDI: ffff89834ffff018 [.] RBP: ffffc900000d3ba0 R08: 0000000000000020 R09: ffff888132b8a900 [.] R10: 4000000000000000 R11: 000000003a616d69 R12: 0000000000000000 [.] R13: ffffffff8404ac28 R14: 0000000000000000 R15: ffff89834ffff000 [.] FS: 0000000000000000(0000) GS:ffff893d44640000(0000) knlGS:0000000000000000 [.] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [.] ata5: SATA link down (SStatus 0 SControl 300) [.] CR2: ffff89834ffff000 CR3: 000001034d00f001 CR4: 0000000000770ef0 [.] PKRU: 55555554 [.] Call Trace: [.] [.] ? __die+0x78/0xc0 [.] ? page_fault_oops+0x2a8/0x3a0 [.] ? exc_page_fault+0x84/0x130 [.] ? asm_exc_page_fault+0x22/0x30 [.] ? ima_restore_measurement_list+0x95/0x4b0 [.] ? template_desc_init_fields+0x317/0x410 [.] ? crypto_alloc_tfm_node+0x9c/0xc0 [.] ? init_ima_lsm+0x30/0x30 [.] ima_load_kexec_buffer+0x72/0xa0 [.] ima_init+0x44/0xa0 [.] __initstub__kmod_ima__373_1201_init_ima7+0x1e/0xb0 [.] ? init_ima_lsm+0x30/0x30 [.] do_one_initcall+0xad/0x200 [.] ? idr_alloc_cyclic+0xaa/0x110 [.] ? new_slab+0x12c/0x420 [.] ? new_slab+0x12c/0x420 [.] ? number+0x12a/0x430 [.] ? sysvec_apic_timer_interrupt+0xa/0x80 [.] ? asm_sysvec_apic_timer_interrupt+0x16/0x20 [.] ? parse_args+0xd4/0x380 [.] ? parse_args+0x14b/0x380 [.] kernel_init_freeable+0x1c1/0x2b0 [.] ? rest_init+0xb0/0xb0 [.] kernel_init+0x16/0x1a0 [.] ret_from_fork+0x2f/0x40 [.] ? rest_init+0xb0/0xb0 [.] ret_from_fork_asm+0x11/0x20 [.] ", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50218", "url": "https://ubuntu.com/security/CVE-2024-50218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow Syzbot reported a kernel BUG in ocfs2_truncate_inline. There are two reasons for this: first, the parameter value passed is greater than ocfs2_max_inline_data_with_xattr, second, the start and end parameters of ocfs2_truncate_inline are \"unsigned int\". So, we need to add a sanity check for byte_start and byte_len right before ocfs2_truncate_inline() in ocfs2_remove_inode_range(), if they are greater than ocfs2_max_inline_data_with_xattr return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50219", "url": "https://ubuntu.com/security/CVE-2024-50219", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50263", "url": "https://ubuntu.com/security/CVE-2024-50263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fork: only invoke khugepaged, ksm hooks if no error There is no reason to invoke these hooks early against an mm that is in an incomplete state. The change in commit d24062914837 (\"fork: use __mt_dup() to duplicate maple tree in dup_mmap()\") makes this more pertinent as we may be in a state where entries in the maple tree are not yet consistent. Their placement early in dup_mmap() only appears to have been meaningful for early error checking, and since functionally it'd require a very small allocation to fail (in practice 'too small to fail') that'd only occur in the most dire circumstances, meaning the fork would fail or be OOM'd in any case. Since both khugepaged and KSM tracking are there to provide optimisations to memory performance rather than critical functionality, it doesn't really matter all that much if, under such dire memory pressure, we fail to register an mm with these. As a result, we follow the example of commit d2081b2bf819 (\"mm: khugepaged: make khugepaged_enter() void function\") and make ksm_fork() a void function also. We only expose the mm to these functions once we are done with them and only if no error occurred in the fork operation.", "cve_priority": "medium", "cve_public_date": "2024-11-11 14:15:00 UTC" }, { "cve": "CVE-2024-50220", "url": "https://ubuntu.com/security/CVE-2024-50220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fork: do not invoke uffd on fork if error occurs Patch series \"fork: do not expose incomplete mm on fork\". During fork we may place the virtual memory address space into an inconsistent state before the fork operation is complete. In addition, we may encounter an error during the fork operation that indicates that the virtual memory address space is invalidated. As a result, we should not be exposing it in any way to external machinery that might interact with the mm or VMAs, machinery that is not designed to deal with incomplete state. We specifically update the fork logic to defer khugepaged and ksm to the end of the operation and only to be invoked if no error arose, and disallow uffd from observing fork events should an error have occurred. This patch (of 2): Currently on fork we expose the virtual address space of a process to userland unconditionally if uffd is registered in VMAs, regardless of whether an error arose in the fork. This is performed in dup_userfaultfd_complete() which is invoked unconditionally, and performs two duties - invoking registered handlers for the UFFD_EVENT_FORK event via dup_fctx(), and clearing down userfaultfd_fork_ctx objects established in dup_userfaultfd(). This is problematic, because the virtual address space may not yet be correctly initialised if an error arose. The change in commit d24062914837 (\"fork: use __mt_dup() to duplicate maple tree in dup_mmap()\") makes this more pertinent as we may be in a state where entries in the maple tree are not yet consistent. We address this by, on fork error, ensuring that we roll back state that we would otherwise expect to clean up through the event being handled by userland and perform the memory freeing duty otherwise performed by dup_userfaultfd_complete(). We do this by implementing a new function, dup_userfaultfd_fail(), which performs the same loop, only decrementing reference counts. Note that we perform mmgrab() on the parent and child mm's, however userfaultfd_ctx_put() will mmdrop() this once the reference count drops to zero, so we will avoid memory leaks correctly here.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53047", "url": "https://ubuntu.com/security/CVE-2024-53047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: init: protect sched with rcu_read_lock Enabling CONFIG_PROVE_RCU_LIST with its dependence CONFIG_RCU_EXPERT creates this splat when an MPTCP socket is created: ============================= WARNING: suspicious RCU usage 6.12.0-rc2+ #11 Not tainted ----------------------------- net/mptcp/sched.c:44 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 no locks held by mptcp_connect/176. stack backtrace: CPU: 0 UID: 0 PID: 176 Comm: mptcp_connect Not tainted 6.12.0-rc2+ #11 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl (lib/dump_stack.c:123) lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822) mptcp_sched_find (net/mptcp/sched.c:44 (discriminator 7)) mptcp_init_sock (net/mptcp/protocol.c:2867 (discriminator 1)) ? sock_init_data_uid (arch/x86/include/asm/atomic.h:28) inet_create.part.0.constprop.0 (net/ipv4/af_inet.c:386) ? __sock_create (include/linux/rcupdate.h:347 (discriminator 1)) __sock_create (net/socket.c:1576) __sys_socket (net/socket.c:1671) ? __pfx___sys_socket (net/socket.c:1712) ? do_user_addr_fault (arch/x86/mm/fault.c:1419 (discriminator 1)) __x64_sys_socket (net/socket.c:1728) do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) That's because when the socket is initialised, rcu_read_lock() is not used despite the explicit comment written above the declaration of mptcp_sched_find() in sched.c. Adding the missing lock/unlock avoids the warning.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50221", "url": "https://ubuntu.com/security/CVE-2024-50221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Vangogh: Fix kernel memory out of bounds write KASAN reports that the GPU metrics table allocated in vangogh_tables_init() is not large enough for the memset done in smu_cmn_init_soft_gpu_metrics(). Condensed report follows: [ 33.861314] BUG: KASAN: slab-out-of-bounds in smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu] [ 33.861799] Write of size 168 at addr ffff888129f59500 by task mangoapp/1067 ... [ 33.861808] CPU: 6 UID: 1000 PID: 1067 Comm: mangoapp Tainted: G W 6.12.0-rc4 #356 1a56f59a8b5182eeaf67eb7cb8b13594dd23b544 [ 33.861816] Tainted: [W]=WARN [ 33.861818] Hardware name: Valve Galileo/Galileo, BIOS F7G0107 12/01/2023 [ 33.861822] Call Trace: [ 33.861826] [ 33.861829] dump_stack_lvl+0x66/0x90 [ 33.861838] print_report+0xce/0x620 [ 33.861853] kasan_report+0xda/0x110 [ 33.862794] kasan_check_range+0xfd/0x1a0 [ 33.862799] __asan_memset+0x23/0x40 [ 33.862803] smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.863306] vangogh_get_gpu_metrics_v2_4+0x123/0xad0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.864257] vangogh_common_get_gpu_metrics+0xb0c/0xbc0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.865682] amdgpu_dpm_get_gpu_metrics+0xcc/0x110 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.866160] amdgpu_get_gpu_metrics+0x154/0x2d0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.867135] dev_attr_show+0x43/0xc0 [ 33.867147] sysfs_kf_seq_show+0x1f1/0x3b0 [ 33.867155] seq_read_iter+0x3f8/0x1140 [ 33.867173] vfs_read+0x76c/0xc50 [ 33.867198] ksys_read+0xfb/0x1d0 [ 33.867214] do_syscall_64+0x90/0x160 ... [ 33.867353] Allocated by task 378 on cpu 7 at 22.794876s: [ 33.867358] kasan_save_stack+0x33/0x50 [ 33.867364] kasan_save_track+0x17/0x60 [ 33.867367] __kasan_kmalloc+0x87/0x90 [ 33.867371] vangogh_init_smc_tables+0x3f9/0x840 [amdgpu] [ 33.867835] smu_sw_init+0xa32/0x1850 [amdgpu] [ 33.868299] amdgpu_device_init+0x467b/0x8d90 [amdgpu] [ 33.868733] amdgpu_driver_load_kms+0x19/0xf0 [amdgpu] [ 33.869167] amdgpu_pci_probe+0x2d6/0xcd0 [amdgpu] [ 33.869608] local_pci_probe+0xda/0x180 [ 33.869614] pci_device_probe+0x43f/0x6b0 Empirically we can confirm that the former allocates 152 bytes for the table, while the latter memsets the 168 large block. Root cause appears that when GPU metrics tables for v2_4 parts were added it was not considered to enlarge the table to fit. The fix in this patch is rather \"brute force\" and perhaps later should be done in a smarter way, by extracting and consolidating the part version to size logic to a common helper, instead of brute forcing the largest possible allocation. Nevertheless, for now this works and fixes the out of bounds write. v2: * Drop impossible v3_0 case. (Mario) (cherry picked from commit 0880f58f9609f0200483a49429af0f050d281703)", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50222", "url": "https://ubuntu.com/security/CVE-2024-50222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iov_iter: fix copy_page_from_iter_atomic() if KMAP_LOCAL_FORCE_MAP generic/077 on x86_32 CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP=y with highmem, on huge=always tmpfs, issues a warning and then hangs (interruptibly): WARNING: CPU: 5 PID: 3517 at mm/highmem.c:622 kunmap_local_indexed+0x62/0xc9 CPU: 5 UID: 0 PID: 3517 Comm: cp Not tainted 6.12.0-rc4 #2 ... copy_page_from_iter_atomic+0xa6/0x5ec generic_perform_write+0xf6/0x1b4 shmem_file_write_iter+0x54/0x67 Fix copy_page_from_iter_atomic() by limiting it in that case (include/linux/skbuff.h skb_frag_must_loop() does similar). But going forward, perhaps CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP is too surprising, has outlived its usefulness, and should just be removed?", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50223", "url": "https://ubuntu.com/security/CVE-2024-50223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/numa: Fix the potential null pointer dereference in task_numa_work() When running stress-ng-vm-segv test, we found a null pointer dereference error in task_numa_work(). Here is the backtrace: [323676.066985] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ...... [323676.067108] CPU: 35 PID: 2694524 Comm: stress-ng-vm-se ...... [323676.067113] pstate: 23401009 (nzCv daif +PAN -UAO +TCO +DIT +SSBS BTYPE=--) [323676.067115] pc : vma_migratable+0x1c/0xd0 [323676.067122] lr : task_numa_work+0x1ec/0x4e0 [323676.067127] sp : ffff8000ada73d20 [323676.067128] x29: ffff8000ada73d20 x28: 0000000000000000 x27: 000000003e89f010 [323676.067130] x26: 0000000000080000 x25: ffff800081b5c0d8 x24: ffff800081b27000 [323676.067133] x23: 0000000000010000 x22: 0000000104d18cc0 x21: ffff0009f7158000 [323676.067135] x20: 0000000000000000 x19: 0000000000000000 x18: ffff8000ada73db8 [323676.067138] x17: 0001400000000000 x16: ffff800080df40b0 x15: 0000000000000035 [323676.067140] x14: ffff8000ada73cc8 x13: 1fffe0017cc72001 x12: ffff8000ada73cc8 [323676.067142] x11: ffff80008001160c x10: ffff000be639000c x9 : ffff8000800f4ba4 [323676.067145] x8 : ffff000810375000 x7 : ffff8000ada73974 x6 : 0000000000000001 [323676.067147] x5 : 0068000b33e26707 x4 : 0000000000000001 x3 : ffff0009f7158000 [323676.067149] x2 : 0000000000000041 x1 : 0000000000004400 x0 : 0000000000000000 [323676.067152] Call trace: [323676.067153] vma_migratable+0x1c/0xd0 [323676.067155] task_numa_work+0x1ec/0x4e0 [323676.067157] task_work_run+0x78/0xd8 [323676.067161] do_notify_resume+0x1ec/0x290 [323676.067163] el0_svc+0x150/0x160 [323676.067167] el0t_64_sync_handler+0xf8/0x128 [323676.067170] el0t_64_sync+0x17c/0x180 [323676.067173] Code: d2888001 910003fd f9000bf3 aa0003f3 (f9401000) [323676.067177] SMP: stopping secondary CPUs [323676.070184] Starting crashdump kernel... stress-ng-vm-segv in stress-ng is used to stress test the SIGSEGV error handling function of the system, which tries to cause a SIGSEGV error on return from unmapping the whole address space of the child process. Normally this program will not cause kernel crashes. But before the munmap system call returns to user mode, a potential task_numa_work() for numa balancing could be added and executed. In this scenario, since the child process has no vma after munmap, the vma_next() in task_numa_work() will return a null pointer even if the vma iterator restarts from 0. Recheck the vma pointer before dereferencing it in task_numa_work().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53053", "url": "https://ubuntu.com/security/CVE-2024-53053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Fix another deadlock during RTC update If ufshcd_rtc_work calls ufshcd_rpm_put_sync() and the pm's usage_count is 0, we will enter the runtime suspend callback. However, the runtime suspend callback will wait to flush ufshcd_rtc_work, causing a deadlock. Replace ufshcd_rpm_put_sync() with ufshcd_rpm_put() to avoid the deadlock.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53075", "url": "https://ubuntu.com/security/CVE-2024-53075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv: Prevent a bad reference count on CPU nodes When populating cache leaves we previously fetched the CPU device node at the very beginning. But when ACPI is enabled we go through a specific branch which returns early and does not call 'of_node_put' for the node that was acquired. Since we are not using a CPU device node for the ACPI code anyways, we can simply move the initialization of it just passed the ACPI block, and we are guaranteed to have an 'of_node_put' call for the acquired node. This prevents a bad reference count of the CPU device node. Moreover, the previous function did not check for errors when acquiring the device node, so a return -ENOENT has been added for that case.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50224", "url": "https://ubuntu.com/security/CVE-2024-50224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: spi-fsl-dspi: Fix crash when not using GPIO chip select Add check for the return value of spi_get_csgpiod() to avoid passing a NULL pointer to gpiod_direction_output(), preventing a crash when GPIO chip select is not used. Fix below crash: [ 4.251960] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 4.260762] Mem abort info: [ 4.263556] ESR = 0x0000000096000004 [ 4.267308] EC = 0x25: DABT (current EL), IL = 32 bits [ 4.272624] SET = 0, FnV = 0 [ 4.275681] EA = 0, S1PTW = 0 [ 4.278822] FSC = 0x04: level 0 translation fault [ 4.283704] Data abort info: [ 4.286583] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 4.292074] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 4.297130] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 4.302445] [0000000000000000] user address but active_mm is swapper [ 4.308805] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 4.315072] Modules linked in: [ 4.318124] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc4-next-20241023-00008-ga20ec42c5fc1 #359 [ 4.328130] Hardware name: LS1046A QDS Board (DT) [ 4.332832] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 4.339794] pc : gpiod_direction_output+0x34/0x5c [ 4.344505] lr : gpiod_direction_output+0x18/0x5c [ 4.349208] sp : ffff80008003b8f0 [ 4.352517] x29: ffff80008003b8f0 x28: 0000000000000000 x27: ffffc96bcc7e9068 [ 4.359659] x26: ffffc96bcc6e00b0 x25: ffffc96bcc598398 x24: ffff447400132810 [ 4.366800] x23: 0000000000000000 x22: 0000000011e1a300 x21: 0000000000020002 [ 4.373940] x20: 0000000000000000 x19: 0000000000000000 x18: ffffffffffffffff [ 4.381081] x17: ffff44740016e600 x16: 0000000500000003 x15: 0000000000000007 [ 4.388221] x14: 0000000000989680 x13: 0000000000020000 x12: 000000000000001e [ 4.395362] x11: 0044b82fa09b5a53 x10: 0000000000000019 x9 : 0000000000000008 [ 4.402502] x8 : 0000000000000002 x7 : 0000000000000007 x6 : 0000000000000000 [ 4.409641] x5 : 0000000000000200 x4 : 0000000002000000 x3 : 0000000000000000 [ 4.416781] x2 : 0000000000022202 x1 : 0000000000000000 x0 : 0000000000000000 [ 4.423921] Call trace: [ 4.426362] gpiod_direction_output+0x34/0x5c (P) [ 4.431067] gpiod_direction_output+0x18/0x5c (L) [ 4.435771] dspi_setup+0x220/0x334", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50225", "url": "https://ubuntu.com/security/CVE-2024-50225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix error propagation of split bios The purpose of btrfs_bbio_propagate_error() shall be propagating an error of split bio to its original btrfs_bio, and tell the error to the upper layer. However, it's not working well on some cases. * Case 1. Immediate (or quick) end_bio with an error When btrfs sends btrfs_bio to mirrored devices, btrfs calls btrfs_bio_end_io() when all the mirroring bios are completed. If that btrfs_bio was split, it is from btrfs_clone_bioset and its end_io function is btrfs_orig_write_end_io. For this case, btrfs_bbio_propagate_error() accesses the orig_bbio's bio context to increase the error count. That works well in most cases. However, if the end_io is called enough fast, orig_bbio's (remaining part after split) bio context may not be properly set at that time. Since the bio context is set when the orig_bbio (the last btrfs_bio) is sent to devices, that might be too late for earlier split btrfs_bio's completion. That will result in NULL pointer dereference. That bug is easily reproducible by running btrfs/146 on zoned devices [1] and it shows the following trace. [1] You need raid-stripe-tree feature as it create \"-d raid0 -m raid1\" FS. BUG: kernel NULL pointer dereference, address: 0000000000000020 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 UID: 0 PID: 13 Comm: kworker/u32:1 Not tainted 6.11.0-rc7-BTRFS-ZNS+ #474 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Workqueue: writeback wb_workfn (flush-btrfs-5) RIP: 0010:btrfs_bio_end_io+0xae/0xc0 [btrfs] BTRFS error (device dm-0): bdev /dev/mapper/error-test errs: wr 2, rd 0, flush 0, corrupt 0, gen 0 RSP: 0018:ffffc9000006f248 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888005a7f080 RCX: ffffc9000006f1dc RDX: 0000000000000000 RSI: 000000000000000a RDI: ffff888005a7f080 RBP: ffff888011dfc540 R08: 0000000000000000 R09: 0000000000000001 R10: ffffffff82e508e0 R11: 0000000000000005 R12: ffff88800ddfbe58 R13: ffff888005a7f080 R14: ffff888005a7f158 R15: ffff888005a7f158 FS: 0000000000000000(0000) GS:ffff88803ea80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000020 CR3: 0000000002e22006 CR4: 0000000000370ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __die_body.cold+0x19/0x26 ? page_fault_oops+0x13e/0x2b0 ? _printk+0x58/0x73 ? do_user_addr_fault+0x5f/0x750 ? exc_page_fault+0x76/0x240 ? asm_exc_page_fault+0x22/0x30 ? btrfs_bio_end_io+0xae/0xc0 [btrfs] ? btrfs_log_dev_io_error+0x7f/0x90 [btrfs] btrfs_orig_write_end_io+0x51/0x90 [btrfs] dm_submit_bio+0x5c2/0xa50 [dm_mod] ? find_held_lock+0x2b/0x80 ? blk_try_enter_queue+0x90/0x1e0 __submit_bio+0xe0/0x130 ? ktime_get+0x10a/0x160 ? lockdep_hardirqs_on+0x74/0x100 submit_bio_noacct_nocheck+0x199/0x410 btrfs_submit_bio+0x7d/0x150 [btrfs] btrfs_submit_chunk+0x1a1/0x6d0 [btrfs] ? lockdep_hardirqs_on+0x74/0x100 ? __folio_start_writeback+0x10/0x2c0 btrfs_submit_bbio+0x1c/0x40 [btrfs] submit_one_bio+0x44/0x60 [btrfs] submit_extent_folio+0x13f/0x330 [btrfs] ? btrfs_set_range_writeback+0xa3/0xd0 [btrfs] extent_writepage_io+0x18b/0x360 [btrfs] extent_write_locked_range+0x17c/0x340 [btrfs] ? __pfx_end_bbio_data_write+0x10/0x10 [btrfs] run_delalloc_cow+0x71/0xd0 [btrfs] btrfs_run_delalloc_range+0x176/0x500 [btrfs] ? find_lock_delalloc_range+0x119/0x260 [btrfs] writepage_delalloc+0x2ab/0x480 [btrfs] extent_write_cache_pages+0x236/0x7d0 [btrfs] btrfs_writepages+0x72/0x130 [btrfs] do_writepages+0xd4/0x240 ? find_held_lock+0x2b/0x80 ? wbc_attach_and_unlock_inode+0x12c/0x290 ? wbc_attach_and_unlock_inode+0x12c/0x29 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53054", "url": "https://ubuntu.com/security/CVE-2024-53054", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50226", "url": "https://ubuntu.com/security/CVE-2024-50226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cxl/port: Fix use-after-free, permit out-of-order decoder shutdown In support of investigating an initialization failure report [1], cxl_test was updated to register mock memory-devices after the mock root-port/bus device had been registered. That led to cxl_test crashing with a use-after-free bug with the following signature: cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem0:decoder7.0 @ 0 next: cxl_switch_uport.0 nr_eps: 1 nr_targets: 1 cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem4:decoder14.0 @ 1 next: cxl_switch_uport.0 nr_eps: 2 nr_targets: 1 cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[0] = cxl_switch_dport.0 for mem0:decoder7.0 @ 0 1) cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[1] = cxl_switch_dport.4 for mem4:decoder14.0 @ 1 [..] cxld_unregister: cxl decoder14.0: cxl_region_decode_reset: cxl_region region3: mock_decoder_reset: cxl_port port3: decoder3.0 reset 2) mock_decoder_reset: cxl_port port3: decoder3.0: out of order reset, expected decoder3.1 cxl_endpoint_decoder_release: cxl decoder14.0: [..] cxld_unregister: cxl decoder7.0: 3) cxl_region_decode_reset: cxl_region region3: Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6bc3: 0000 [#1] PREEMPT SMP PTI [..] RIP: 0010:to_cxl_port+0x8/0x60 [cxl_core] [..] Call Trace: cxl_region_decode_reset+0x69/0x190 [cxl_core] cxl_region_detach+0xe8/0x210 [cxl_core] cxl_decoder_kill_region+0x27/0x40 [cxl_core] cxld_unregister+0x5d/0x60 [cxl_core] At 1) a region has been established with 2 endpoint decoders (7.0 and 14.0). Those endpoints share a common switch-decoder in the topology (3.0). At teardown, 2), decoder14.0 is the first to be removed and hits the \"out of order reset case\" in the switch decoder. The effect though is that region3 cleanup is aborted leaving it in-tact and referencing decoder14.0. At 3) the second attempt to teardown region3 trips over the stale decoder14.0 object which has long since been deleted. The fix here is to recognize that the CXL specification places no mandate on in-order shutdown of switch-decoders, the driver enforces in-order allocation, and hardware enforces in-order commit. So, rather than fail and leave objects dangling, always remove them. In support of making cxl_region_decode_reset() always succeed, cxl_region_invalidate_memregion() failures are turned into warnings. Crashing the kernel is ok there since system integrity is at risk if caches cannot be managed around physical address mutation events like CXL region destruction. A new device_for_each_child_reverse_from() is added to cleanup port->commit_end after all dependent decoders have been disabled. In other words if decoders are allocated 0->1->2 and disabled 1->2->0 then port->commit_end only decrements from 2 after 2 has been disabled, and it decrements all the way to zero since 1 was disabled previously.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50227", "url": "https://ubuntu.com/security/CVE-2024-50227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Fix KASAN reported stack out-of-bounds read in tb_retimer_scan() KASAN reported following issue: BUG: KASAN: stack-out-of-bounds in tb_retimer_scan+0xffe/0x1550 [thunderbolt] Read of size 4 at addr ffff88810111fc1c by task kworker/u56:0/11 CPU: 0 UID: 0 PID: 11 Comm: kworker/u56:0 Tainted: G U 6.11.0+ #1387 Tainted: [U]=USER Workqueue: thunderbolt0 tb_handle_hotplug [thunderbolt] Call Trace: dump_stack_lvl+0x6c/0x90 print_report+0xd1/0x630 kasan_report+0xdb/0x110 __asan_report_load4_noabort+0x14/0x20 tb_retimer_scan+0xffe/0x1550 [thunderbolt] tb_scan_port+0xa6f/0x2060 [thunderbolt] tb_handle_hotplug+0x17b1/0x3080 [thunderbolt] process_one_work+0x626/0x1100 worker_thread+0x6c8/0xfa0 kthread+0x2c8/0x3a0 ret_from_fork+0x3a/0x80 ret_from_fork_asm+0x1a/0x30 This happens because the loop variable still gets incremented by one so max becomes 3 instead of 2, and this makes the second loop read past the the array declared on the stack. Fix this by assigning to max directly in the loop body.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50228", "url": "https://ubuntu.com/security/CVE-2024-50228", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50229", "url": "https://ubuntu.com/security/CVE-2024-50229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential deadlock with newly created symlinks Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers memory reclamation involving the filesystem layer, which can result in circular lock dependencies among the reader/writer semaphore nilfs->ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the fs_reclaim pseudo lock. This is because after commit 21fc61c73c39 (\"don't put symlink bodies in pagecache into highmem\"), the gfp flags of the page cache for symbolic links are overwritten to GFP_KERNEL via inode_nohighmem(). This is not a problem for symlinks read from the backing device, because the __GFP_FS flag is dropped after inode_nohighmem() is called. However, when a new symlink is created with nilfs_symlink(), the gfp flags remain overwritten to GFP_KERNEL. Then, memory allocation called from page_symlink() etc. triggers memory reclamation including the FS layer, which may call nilfs_evict_inode() or nilfs_dirty_inode(). And these can cause a deadlock if they are called while nilfs->ns_segctor_sem is held: Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags of newly created symlinks in the same way that nilfs_new_inode() and __nilfs_read_inode() do, as a workaround until we adopt nofs allocation scope consistently or improve the locking constraints.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50230", "url": "https://ubuntu.com/security/CVE-2024-50230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug due to missing clearing of checked flag Syzbot reported that in directory operations after nilfs2 detects filesystem corruption and degrades to read-only, __block_write_begin_int(), which is called to prepare block writes, may fail the BUG_ON check for accesses exceeding the folio/page size, triggering a kernel bug. This was found to be because the \"checked\" flag of a page/folio was not cleared when it was discarded by nilfs2's own routine, which causes the sanity check of directory entries to be skipped when the directory page/folio is reloaded. So, fix that. This was necessary when the use of nilfs2's own page discard routine was applied to more than just metadata files.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50231", "url": "https://ubuntu.com/security/CVE-2024-50231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gts-helper: Fix memory leaks in iio_gts_build_avail_scale_table() modprobe iio-test-gts and rmmod it, then the following memory leak occurs: \tunreferenced object 0xffffff80c810be00 (size 64): \t comm \"kunit_try_catch\", pid 1654, jiffies 4294913981 \t hex dump (first 32 bytes): \t 02 00 00 00 08 00 00 00 20 00 00 00 40 00 00 00 ........ ...@... \t 80 00 00 00 00 02 00 00 00 04 00 00 00 08 00 00 ................ \t backtrace (crc a63d875e): \t [<0000000028c1b3c2>] kmemleak_alloc+0x34/0x40 \t [<000000001d6ecc87>] __kmalloc_noprof+0x2bc/0x3c0 \t [<00000000393795c1>] devm_iio_init_iio_gts+0x4b4/0x16f4 \t [<0000000071bb4b09>] 0xffffffdf052a62e0 \t [<000000000315bc18>] 0xffffffdf052a6488 \t [<00000000f9dc55b5>] kunit_try_run_case+0x13c/0x3ac \t [<00000000175a3fd4>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000f505065d>] kthread+0x2e8/0x374 \t [<00000000bbfb0e5d>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cbfe9e70 (size 16): \t comm \"kunit_try_catch\", pid 1658, jiffies 4294914015 \t hex dump (first 16 bytes): \t 10 00 00 00 40 00 00 00 80 00 00 00 00 00 00 00 ....@........... \t backtrace (crc 857f0cb4): \t [<0000000028c1b3c2>] kmemleak_alloc+0x34/0x40 \t [<000000001d6ecc87>] __kmalloc_noprof+0x2bc/0x3c0 \t [<00000000393795c1>] devm_iio_init_iio_gts+0x4b4/0x16f4 \t [<0000000071bb4b09>] 0xffffffdf052a62e0 \t [<000000007d089d45>] 0xffffffdf052a6864 \t [<00000000f9dc55b5>] kunit_try_run_case+0x13c/0x3ac \t [<00000000175a3fd4>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000f505065d>] kthread+0x2e8/0x374 \t [<00000000bbfb0e5d>] ret_from_fork+0x10/0x20 \t...... It includes 5*5 times \"size 64\" memory leaks, which correspond to 5 times test_init_iio_gain_scale() calls with gts_test_gains size 10 (10*size(int)) and gts_test_itimes size 5. It also includes 5*1 times \"size 16\" memory leak, which correspond to one time __test_init_iio_gain_scale() call with gts_test_gains_gain_low size 3 (3*size(int)) and gts_test_itimes size 5. The reason is that the per_time_gains[i] is not freed which is allocated in the \"gts->num_itime\" for loop in iio_gts_build_avail_scale_table().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53076", "url": "https://ubuntu.com/security/CVE-2024-53076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gts-helper: Fix memory leaks for the error path of iio_gts_build_avail_scale_table() If per_time_scales[i] or per_time_gains[i] kcalloc fails in the for loop of iio_gts_build_avail_scale_table(), the err_free_out will fail to call kfree() each time when i is reduced to 0, so all the per_time_scales[0] and per_time_gains[0] will not be freed, which will cause memory leaks. Fix it by checking if i >= 0.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50232", "url": "https://ubuntu.com/security/CVE-2024-50232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr() In the ad7124_write_raw() function, parameter val can potentially be zero. This may lead to a division by zero when DIV_ROUND_CLOSEST() is called within ad7124_set_channel_odr(). The ad7124_write_raw() function is invoked through the sequence: iio_write_channel_raw() -> iio_write_channel_attribute() -> iio_channel_write(), with no checks in place to ensure val is non-zero.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50233", "url": "https://ubuntu.com/security/CVE-2024-50233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: iio: frequency: ad9832: fix division by zero in ad9832_calc_freqreg() In the ad9832_write_frequency() function, clk_get_rate() might return 0. This can lead to a division by zero when calling ad9832_calc_freqreg(). The check if (fout > (clk_get_rate(st->mclk) / 2)) does not protect against the case when fout is 0. The ad9832_write_frequency() function is called from ad9832_write(), and fout is derived from a text buffer, which can contain any value.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53055", "url": "https://ubuntu.com/security/CVE-2024-53055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix 6 GHz scan construction If more than 255 colocated APs exist for the set of all APs found during 2.4/5 GHz scanning, then the 6 GHz scan construction will loop forever since the loop variable has type u8, which can never reach the number found when that's bigger than 255, and is stored in a u32 variable. Also move it into the loops to have a smaller scope. Using a u32 there is fine, we limit the number of APs in the scan list and each has a limit on the number of RNR entries due to the frame size. With a limit of 1000 scan results, a frame size upper bound of 4096 (really it's more like ~2300) and a TBTT entry size of at least 11, we get an upper bound for the number of ~372k, well in the bounds of a u32.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50234", "url": "https://ubuntu.com/security/CVE-2024-50234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlegacy: Clear stale interrupts before resuming device iwl4965 fails upon resume from hibernation on my laptop. The reason seems to be a stale interrupt which isn't being cleared out before interrupts are enabled. We end up with a race beween the resume trying to bring things back up, and the restart work (queued form the interrupt handler) trying to bring things down. Eventually the whole thing blows up. Fix the problem by clearing out any stale interrupts before interrupts get enabled during resume. Here's a debug log of the indicent: [ 12.042589] ieee80211 phy0: il_isr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000 [ 12.042625] ieee80211 phy0: il4965_irq_tasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000 [ 12.042651] iwl4965 0000:10:00.0: RF_KILL bit toggled to enable radio. [ 12.042653] iwl4965 0000:10:00.0: On demand firmware reload [ 12.042690] ieee80211 phy0: il4965_irq_tasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282 [ 12.052207] ieee80211 phy0: il4965_mac_start enter [ 12.052212] ieee80211 phy0: il_prep_station Add STA to driver ID 31: ff:ff:ff:ff:ff:ff [ 12.052244] ieee80211 phy0: il4965_set_hw_ready hardware ready [ 12.052324] ieee80211 phy0: il_apm_init Init card's basic functions [ 12.052348] ieee80211 phy0: il_apm_init L1 Enabled; Disabling L0S [ 12.055727] ieee80211 phy0: il4965_load_bsm Begin load bsm [ 12.056140] ieee80211 phy0: il4965_verify_bsm Begin verify bsm [ 12.058642] ieee80211 phy0: il4965_verify_bsm BSM bootstrap uCode image OK [ 12.058721] ieee80211 phy0: il4965_load_bsm BSM write complete, poll 1 iterations [ 12.058734] ieee80211 phy0: __il4965_up iwl4965 is coming up [ 12.058737] ieee80211 phy0: il4965_mac_start Start UP work done. [ 12.058757] ieee80211 phy0: __il4965_down iwl4965 is going down [ 12.058761] ieee80211 phy0: il_scan_cancel_timeout Scan cancel timeout [ 12.058762] ieee80211 phy0: il_do_scan_abort Not performing scan to abort [ 12.058765] ieee80211 phy0: il_clear_ucode_stations Clearing ucode stations in driver [ 12.058767] ieee80211 phy0: il_clear_ucode_stations No active stations found to be cleared [ 12.058819] ieee80211 phy0: _il_apm_stop Stop card, put in low power state [ 12.058827] ieee80211 phy0: _il_apm_stop_master stop master [ 12.058864] ieee80211 phy0: il4965_clear_free_frames 0 frames on pre-allocated heap on clear. [ 12.058869] ieee80211 phy0: Hardware restart was requested [ 16.132299] iwl4965 0000:10:00.0: START_ALIVE timeout after 4000ms. [ 16.132303] ------------[ cut here ]------------ [ 16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue. [ 16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132390] Modules linked in: ctr ccm sch_fq_codel xt_tcpudp xt_multiport xt_state iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables binfmt_misc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdh_generic ecc iTCO_wdt i2c_dev iwl4965 iwlegacy coretemp snd_hda_codec_analog pcspkr psmouse mac80211 snd_hda_codec_generic libarc4 sdhci_pci cqhci sha256_generic sdhci libsha256 firewire_ohci snd_hda_intel snd_intel_dspcfg mmc_core snd_hda_codec snd_hwdep firewire_core led_class iosf_mbi snd_hda_core uhci_hcd lpc_ich crc_itu_t cfg80211 ehci_pci ehci_hcd snd_pcm usbcore mfd_core rfkill snd_timer snd usb_common soundcore video parport_pc parport intel_agp wmi intel_gtt backlight e1000e agpgart evdev [ 16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143 [ 16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010 [ 16.132463] Workqueue: async async_run_entry_fn [ 16.132469] RIP: 0010:ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132501] Code: da 02 00 0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50235", "url": "https://ubuntu.com/security/CVE-2024-50235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: clear wdev->cqm_config pointer on free When we free wdev->cqm_config when unregistering, we also need to clear out the pointer since the same wdev/netdev may get re-registered in another network namespace, then destroyed later, running this code again, which results in a double-free.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50236", "url": "https://ubuntu.com/security/CVE-2024-50236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: Fix memory leak in management tx In the current logic, memory is allocated for storing the MSDU context during management packet TX but this memory is not being freed during management TX completion. Similar leaks are seen in the management TX cleanup logic. Kmemleak reports this problem as below, unreferenced object 0xffffff80b64ed250 (size 16): comm \"kworker/u16:7\", pid 148, jiffies 4294687130 (age 714.199s) hex dump (first 16 bytes): 00 2b d8 d8 80 ff ff ff c4 74 e9 fd 07 00 00 00 .+.......t...... backtrace: [] __kmem_cache_alloc_node+0x1e4/0x2d8 [] kmalloc_trace+0x48/0x110 [] ath10k_wmi_tlv_op_gen_mgmt_tx_send+0xd4/0x1d8 [ath10k_core] [] ath10k_mgmt_over_wmi_tx_work+0x134/0x298 [ath10k_core] [] process_scheduled_works+0x1ac/0x400 [] worker_thread+0x208/0x328 [] kthread+0x100/0x1c0 [] ret_from_fork+0x10/0x20 Free the memory during completion and cleanup to fix the leak. Protect the mgmt_pending_tx idr_remove() operation in ath10k_wmi_tlv_op_cleanup_mgmt_tx_send() using ar->data_lock similar to other instances. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50237", "url": "https://ubuntu.com/security/CVE-2024-50237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower Avoid potentially crashing in the driver because of uninitialized private data", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50238", "url": "https://ubuntu.com/security/CVE-2024-50238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usbc: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data from the qcom-qmp-usb driver, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. This bug was later reproduced when the driver was copied to create the qmp-usbc driver. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with these drivers.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50239", "url": "https://ubuntu.com/security/CVE-2024-50239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usb-legacy: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data from the qcom-qmp-usb driver, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. This bug was later reproduced when the driver was copied to create the qmp-usb-legacy driver. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with these drivers.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50240", "url": "https://ubuntu.com/security/CVE-2024-50240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usb: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with this driver.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53077", "url": "https://ubuntu.com/security/CVE-2024-53077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpcrdma: Always release the rpcrdma_device's xa_array Dai pointed out that the xa_init_flags() in rpcrdma_add_one() needs to have a matching xa_destroy() in rpcrdma_remove_one() to release underlying memory that the xarray might have accrued during operation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50242", "url": "https://ubuntu.com/security/CVE-2024-50242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ntfs_file_release", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50243", "url": "https://ubuntu.com/security/CVE-2024-50243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix general protection fault in run_is_mapped_full Fixed deleating of a non-resident attribute in ntfs_create_inode() rollback.", "cve_priority": "low", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50244", "url": "https://ubuntu.com/security/CVE-2024-50244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ni_clear() Checking of NTFS_FLAGS_LOG_REPLAYING added to prevent access to uninitialized bitmap during replay process.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50245", "url": "https://ubuntu.com/security/CVE-2024-50245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix possible deadlock in mi_read Mutex lock with another subclass used in ni_lock_dir().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50246", "url": "https://ubuntu.com/security/CVE-2024-50246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Add rough attr alloc_size check", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50247", "url": "https://ubuntu.com/security/CVE-2024-50247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Check if more than chunk-size bytes are written A incorrectly formatted chunk may decompress into more than LZNT_CHUNK_SIZE bytes and a index out of bounds will occur in s_max_off.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50248", "url": "https://ubuntu.com/security/CVE-2024-50248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Add bounds checking to mi_enum_attr() Added bounds checking to make sure that every attr don't stray beyond valid memory region.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53078", "url": "https://ubuntu.com/security/CVE-2024-53078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Fix NULL vs IS_ERR() check in probe() The iommu_paging_domain_alloc() function doesn't return NULL pointers, it returns error pointers. Update the check to match.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53056", "url": "https://ubuntu.com/security/CVE-2024-53056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Fix potential NULL dereference in mtk_crtc_destroy() In mtk_crtc_create(), if the call to mbox_request_channel() fails then we set the \"mtk_crtc->cmdq_client.chan\" pointer to NULL. In that situation, we do not call cmdq_pkt_create(). During the cleanup, we need to check if the \"mtk_crtc->cmdq_client.chan\" is NULL first before calling cmdq_pkt_destroy(). Calling cmdq_pkt_destroy() is unnecessary if we didn't call cmdq_pkt_create() and it will result in a NULL pointer dereference.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50249", "url": "https://ubuntu.com/security/CVE-2024-50249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Make rmw_lock a raw_spin_lock The following BUG was triggered: ============================= [ BUG: Invalid wait context ] 6.12.0-rc2-XXX #406 Not tainted ----------------------------- kworker/1:1/62 is trying to lock: ffffff8801593030 (&cpc_ptr->rmw_lock){+.+.}-{3:3}, at: cpc_write+0xcc/0x370 other info that might help us debug this: context-{5:5} 2 locks held by kworker/1:1/62: #0: ffffff897ef5ec98 (&rq->__lock){-.-.}-{2:2}, at: raw_spin_rq_lock_nested+0x2c/0x50 #1: ffffff880154e238 (&sg_policy->update_lock){....}-{2:2}, at: sugov_update_shared+0x3c/0x280 stack backtrace: CPU: 1 UID: 0 PID: 62 Comm: kworker/1:1 Not tainted 6.12.0-rc2-g9654bd3e8806 #406 Workqueue: 0x0 (events) Call trace: dump_backtrace+0xa4/0x130 show_stack+0x20/0x38 dump_stack_lvl+0x90/0xd0 dump_stack+0x18/0x28 __lock_acquire+0x480/0x1ad8 lock_acquire+0x114/0x310 _raw_spin_lock+0x50/0x70 cpc_write+0xcc/0x370 cppc_set_perf+0xa0/0x3a8 cppc_cpufreq_fast_switch+0x40/0xc0 cpufreq_driver_fast_switch+0x4c/0x218 sugov_update_shared+0x234/0x280 update_load_avg+0x6ec/0x7b8 dequeue_entities+0x108/0x830 dequeue_task_fair+0x58/0x408 __schedule+0x4f0/0x1070 schedule+0x54/0x130 worker_thread+0xc0/0x2e8 kthread+0x130/0x148 ret_from_fork+0x10/0x20 sugov_update_shared() locks a raw_spinlock while cpc_write() locks a spinlock. To have a correct wait-type order, update rmw_lock to a raw spinlock and ensure that interrupts will be disabled on the CPU holding it. [ rjw: Changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50250", "url": "https://ubuntu.com/security/CVE-2024-50250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fsdax: dax_unshare_iter needs to copy entire blocks The code that copies data from srcmap to iomap in dax_unshare_iter is very very broken, which bfoster's recent fsx changes have exposed. If the pos and len passed to dax_file_unshare are not aligned to an fsblock boundary, the iter pos and length in the _iter function will reflect this unalignment. dax_iomap_direct_access always returns a pointer to the start of the kmapped fsdax page, even if its pos argument is in the middle of that page. This is catastrophic for data integrity when iter->pos is not aligned to a page, because daddr/saddr do not point to the same byte in the file as iter->pos. Hence we corrupt user data by copying it to the wrong place. If iter->pos + iomap_length() in the _iter function not aligned to a page, then we fail to copy a full block, and only partially populate the destination block. This is catastrophic for data confidentiality because we expose stale pmem contents. Fix both of these issues by aligning copy_pos/copy_len to a page boundary (remember, this is fsdax so 1 fsblock == 1 base page) so that we always copy full blocks. We're not done yet -- there's no call to invalidate_inode_pages2_range, so programs that have the file range mmap'd will continue accessing the old memory mapping after the file metadata updates have completed. Be careful with the return value -- if the unshare succeeds, we still need to return the number of bytes that the iomap iter thinks we're operating on.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50251", "url": "https://ubuntu.com/security/CVE-2024-50251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_payload: sanitize offset and length before calling skb_checksum() If access to offset + length is larger than the skbuff length, then skb_checksum() triggers BUG_ON(). skb_checksum() internally subtracts the length parameter while iterating over skbuff, BUG_ON(len) at the end of it checks that the expected length to be included in the checksum calculation is fully consumed.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50252", "url": "https://ubuntu.com/security/CVE-2024-50252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_ipip: Fix memory leak when changing remote IPv6 address The device stores IPv6 addresses that are used for encapsulation in linear memory that is managed by the driver. Changing the remote address of an ip6gre net device never worked properly, but since cited commit the following reproducer [1] would result in a warning [2] and a memory leak [3]. The problem is that the new remote address is never added by the driver to its hash table (and therefore the device) and the old address is never removed from it. Fix by programming the new address when the configuration of the ip6gre net device changes and removing the old one. If the address did not change, then the above would result in increasing the reference count of the address and then decreasing it. [1] # ip link add name bla up type ip6gre local 2001:db8:1::1 remote 2001:db8:2::1 tos inherit ttl inherit # ip link set dev bla type ip6gre remote 2001:db8:3::1 # ip link del dev bla # devlink dev reload pci/0000:01:00.0 [2] WARNING: CPU: 0 PID: 1682 at drivers/net/ethernet/mellanox/mlxsw/spectrum.c:3002 mlxsw_sp_ipv6_addr_put+0x140/0x1d0 Modules linked in: CPU: 0 UID: 0 PID: 1682 Comm: ip Not tainted 6.12.0-rc3-custom-g86b5b55bc835 #151 Hardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023 RIP: 0010:mlxsw_sp_ipv6_addr_put+0x140/0x1d0 [...] Call Trace: mlxsw_sp_router_netdevice_event+0x55f/0x1240 notifier_call_chain+0x5a/0xd0 call_netdevice_notifiers_info+0x39/0x90 unregister_netdevice_many_notify+0x63e/0x9d0 rtnl_dellink+0x16b/0x3a0 rtnetlink_rcv_msg+0x142/0x3f0 netlink_rcv_skb+0x50/0x100 netlink_unicast+0x242/0x390 netlink_sendmsg+0x1de/0x420 ____sys_sendmsg+0x2bd/0x320 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xd0 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f [3] unreferenced object 0xffff898081f597a0 (size 32): comm \"ip\", pid 1626, jiffies 4294719324 hex dump (first 32 bytes): 20 01 0d b8 00 02 00 00 00 00 00 00 00 00 00 01 ............... 21 49 61 83 80 89 ff ff 00 00 00 00 01 00 00 00 !Ia............. backtrace (crc fd9be911): [<00000000df89c55d>] __kmalloc_cache_noprof+0x1da/0x260 [<00000000ff2a1ddb>] mlxsw_sp_ipv6_addr_kvdl_index_get+0x281/0x340 [<000000009ddd445d>] mlxsw_sp_router_netdevice_event+0x47b/0x1240 [<00000000743e7757>] notifier_call_chain+0x5a/0xd0 [<000000007c7b9e13>] call_netdevice_notifiers_info+0x39/0x90 [<000000002509645d>] register_netdevice+0x5f7/0x7a0 [<00000000c2e7d2a9>] ip6gre_newlink_common.isra.0+0x65/0x130 [<0000000087cd6d8d>] ip6gre_newlink+0x72/0x120 [<000000004df7c7cc>] rtnl_newlink+0x471/0xa20 [<0000000057ed632a>] rtnetlink_rcv_msg+0x142/0x3f0 [<0000000032e0d5b5>] netlink_rcv_skb+0x50/0x100 [<00000000908bca63>] netlink_unicast+0x242/0x390 [<00000000cdbe1c87>] netlink_sendmsg+0x1de/0x420 [<0000000011db153e>] ____sys_sendmsg+0x2bd/0x320 [<000000003b6d53eb>] ___sys_sendmsg+0x9a/0xe0 [<00000000cae27c62>] __sys_sendmsg+0x7a/0xd0", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50253", "url": "https://ubuntu.com/security/CVE-2024-50253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check the validity of nr_words in bpf_iter_bits_new() Check the validity of nr_words in bpf_iter_bits_new(). Without this check, when multiplication overflow occurs for nr_bits (e.g., when nr_words = 0x0400-0001, nr_bits becomes 64), stack corruption may occur due to bpf_probe_read_kernel_common(..., nr_bytes = 0x2000-0008). Fix it by limiting the maximum value of nr_words to 511. The value is derived from the current implementation of BPF memory allocator. To ensure compatibility if the BPF memory allocator's size limitation changes in the future, use the helper bpf_mem_alloc_check_size() to check whether nr_bytes is too larger. And return -E2BIG instead of -ENOMEM for oversized nr_bytes.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50254", "url": "https://ubuntu.com/security/CVE-2024-50254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free dynamically allocated bits in bpf_iter_bits_destroy() bpf_iter_bits_destroy() uses \"kit->nr_bits <= 64\" to check whether the bits are dynamically allocated. However, the check is incorrect and may cause a kmemleak as shown below: unreferenced object 0xffff88812628c8c0 (size 32): comm \"swapper/0\", pid 1, jiffies 4294727320 hex dump (first 32 bytes): \tb0 c1 55 f5 81 88 ff ff f0 f0 f0 f0 f0 f0 f0 f0 ..U........... \tf0 f0 f0 f0 f0 f0 f0 f0 00 00 00 00 00 00 00 00 .............. backtrace (crc 781e32cc): \t[<00000000c452b4ab>] kmemleak_alloc+0x4b/0x80 \t[<0000000004e09f80>] __kmalloc_node_noprof+0x480/0x5c0 \t[<00000000597124d6>] __alloc.isra.0+0x89/0xb0 \t[<000000004ebfffcd>] alloc_bulk+0x2af/0x720 \t[<00000000d9c10145>] prefill_mem_cache+0x7f/0xb0 \t[<00000000ff9738ff>] bpf_mem_alloc_init+0x3e2/0x610 \t[<000000008b616eac>] bpf_global_ma_init+0x19/0x30 \t[<00000000fc473efc>] do_one_initcall+0xd3/0x3c0 \t[<00000000ec81498c>] kernel_init_freeable+0x66a/0x940 \t[<00000000b119f72f>] kernel_init+0x20/0x160 \t[<00000000f11ac9a7>] ret_from_fork+0x3c/0x70 \t[<0000000004671da4>] ret_from_fork_asm+0x1a/0x30 That is because nr_bits will be set as zero in bpf_iter_bits_next() after all bits have been iterated. Fix the issue by setting kit->bit to kit->nr_bits instead of setting kit->nr_bits to zero when the iteration completes in bpf_iter_bits_next(). In addition, use \"!nr_bits || bits >= nr_bits\" to check whether the iteration is complete and still use \"nr_bits > 64\" to indicate whether bits are dynamically allocated. The \"!nr_bits\" check is necessary because bpf_iter_bits_new() may fail before setting kit->nr_bits, and this condition will stop the iteration early instead of accessing the zeroed or freed kit->bits. Considering the initial value of kit->bits is -1 and the type of kit->nr_bits is unsigned int, change the type of kit->nr_bits to int. The potential overflow problem will be handled in the following patch.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50255", "url": "https://ubuntu.com/security/CVE-2024-50255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci: fix null-ptr-deref in hci_read_supported_codecs Fix __hci_cmd_sync_sk() to return not NULL for unknown opcodes. __hci_cmd_sync_sk() returns NULL if a command returns a status event. However, it also returns NULL where an opcode doesn't exist in the hci_cc table because hci_cmd_complete_evt() assumes status = skb->data[0] for unknown opcodes. This leads to null-ptr-deref in cmd_sync for HCI_OP_READ_LOCAL_CODECS as there is no hci_cc for HCI_OP_READ_LOCAL_CODECS, which always assumes status = skb->data[0]. KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077] CPU: 1 PID: 2000 Comm: kworker/u9:5 Not tainted 6.9.0-ga6bcb805883c-dirty #10 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: hci7 hci_power_on RIP: 0010:hci_read_supported_codecs+0xb9/0x870 net/bluetooth/hci_codec.c:138 Code: 08 48 89 ef e8 b8 c1 8f fd 48 8b 75 00 e9 96 00 00 00 49 89 c6 48 ba 00 00 00 00 00 fc ff df 4c 8d 60 70 4c 89 e3 48 c1 eb 03 <0f> b6 04 13 84 c0 0f 85 82 06 00 00 41 83 3c 24 02 77 0a e8 bf 78 RSP: 0018:ffff888120bafac8 EFLAGS: 00010212 RAX: 0000000000000000 RBX: 000000000000000e RCX: ffff8881173f0040 RDX: dffffc0000000000 RSI: ffffffffa58496c0 RDI: ffff88810b9ad1e4 RBP: ffff88810b9ac000 R08: ffffffffa77882a7 R09: 1ffffffff4ef1054 R10: dffffc0000000000 R11: fffffbfff4ef1055 R12: 0000000000000070 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88810b9ac000 FS: 0000000000000000(0000) GS:ffff8881f6c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6ddaa3439e CR3: 0000000139764003 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: hci_read_local_codecs_sync net/bluetooth/hci_sync.c:4546 [inline] hci_init_stage_sync net/bluetooth/hci_sync.c:3441 [inline] hci_init4_sync net/bluetooth/hci_sync.c:4706 [inline] hci_init_sync net/bluetooth/hci_sync.c:4742 [inline] hci_dev_init_sync net/bluetooth/hci_sync.c:4912 [inline] hci_dev_open_sync+0x19a9/0x2d30 net/bluetooth/hci_sync.c:4994 hci_dev_do_open net/bluetooth/hci_core.c:483 [inline] hci_power_on+0x11e/0x560 net/bluetooth/hci_core.c:1015 process_one_work kernel/workqueue.c:3267 [inline] process_scheduled_works+0x8ef/0x14f0 kernel/workqueue.c:3348 worker_thread+0x91f/0xe50 kernel/workqueue.c:3429 kthread+0x2cb/0x360 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50256", "url": "https://ubuntu.com/security/CVE-2024-50256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6() I got a syzbot report without a repro [1] crashing in nf_send_reset6() I think the issue is that dev->hard_header_len is zero, and we attempt later to push an Ethernet header. Use LL_MAX_HEADER, as other functions in net/ipv6/netfilter/nf_reject_ipv6.c. [1] skbuff: skb_under_panic: text:ffffffff89b1d008 len:74 put:14 head:ffff88803123aa00 data:ffff88803123a9f2 tail:0x3c end:0x140 dev:syz_tun kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 UID: 0 PID: 7373 Comm: syz.1.568 Not tainted 6.12.0-rc2-syzkaller-00631-g6d858708d465 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:skb_panic net/core/skbuff.c:206 [inline] RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216 Code: 0d 8d 48 c7 c6 60 a6 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 ba 30 38 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP: 0018:ffffc900045269b0 EFLAGS: 00010282 RAX: 0000000000000088 RBX: dffffc0000000000 RCX: cd66dacdc5d8e800 RDX: 0000000000000000 RSI: 0000000000000200 RDI: 0000000000000000 RBP: ffff88802d39a3d0 R08: ffffffff8174afec R09: 1ffff920008a4ccc R10: dffffc0000000000 R11: fffff520008a4ccd R12: 0000000000000140 R13: ffff88803123aa00 R14: ffff88803123a9f2 R15: 000000000000003c FS: 00007fdbee5ff6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000005d322000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: skb_push+0xe5/0x100 net/core/skbuff.c:2636 eth_header+0x38/0x1f0 net/ethernet/eth.c:83 dev_hard_header include/linux/netdevice.h:3208 [inline] nf_send_reset6+0xce6/0x1270 net/ipv6/netfilter/nf_reject_ipv6.c:358 nft_reject_inet_eval+0x3b9/0x690 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x418/0x6b0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] br_nf_pre_routing_ipv6+0x63e/0x770 net/bridge/br_netfilter_ipv6.c:184 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_bridge_pre net/bridge/br_input.c:277 [inline] br_handle_frame+0x9fd/0x1530 net/bridge/br_input.c:424 __netif_receive_skb_core+0x13e8/0x4570 net/core/dev.c:5562 __netif_receive_skb_one_core net/core/dev.c:5666 [inline] __netif_receive_skb+0x12f/0x650 net/core/dev.c:5781 netif_receive_skb_internal net/core/dev.c:5867 [inline] netif_receive_skb+0x1e8/0x890 net/core/dev.c:5926 tun_rx_batched+0x1b7/0x8f0 drivers/net/tun.c:1550 tun_get_user+0x3056/0x47e0 drivers/net/tun.c:2007 tun_chr_write_iter+0x10d/0x1f0 drivers/net/tun.c:2053 new_sync_write fs/read_write.c:590 [inline] vfs_write+0xa6d/0xc90 fs/read_write.c:683 ksys_write+0x183/0x2b0 fs/read_write.c:736 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:0x7fdbeeb7d1ff Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 c9 8d 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 1c 8e 02 00 48 RSP: 002b:00007fdbee5ff000 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fdbeed36058 RCX: 00007fdbeeb7d1ff RDX: 000000000000008e RSI: 0000000020000040 RDI: 00000000000000c8 RBP: 00007fdbeebf12be R08: 0000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50257", "url": "https://ubuntu.com/security/CVE-2024-50257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: Fix use-after-free in get_info() ip6table_nat module unload has refcnt warning for UAF. call trace is: WARNING: CPU: 1 PID: 379 at kernel/module/main.c:853 module_put+0x6f/0x80 Modules linked in: ip6table_nat(-) CPU: 1 UID: 0 PID: 379 Comm: ip6tables Not tainted 6.12.0-rc4-00047-gc2ee9f594da8-dirty #205 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:module_put+0x6f/0x80 Call Trace: get_info+0x128/0x180 do_ip6t_get_ctl+0x6a/0x430 nf_getsockopt+0x46/0x80 ipv6_getsockopt+0xb9/0x100 rawv6_getsockopt+0x42/0x190 do_sock_getsockopt+0xaa/0x180 __sys_getsockopt+0x70/0xc0 __x64_sys_getsockopt+0x20/0x30 do_syscall_64+0xa2/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Concurrent execution of module unload and get_info() trigered the warning. The root cause is as follows: cpu0\t\t\t\t cpu1 module_exit //mod->state = MODULE_STATE_GOING ip6table_nat_exit xt_unregister_template \tkfree(t) \t//removed from templ_list \t\t\t\t getinfo() \t\t\t\t\t t = xt_find_table_lock \t\t\t\t\t\tlist_for_each_entry(tmpl, &xt_templates[af]...) \t\t\t\t\t\t\tif (strcmp(tmpl->name, name)) \t\t\t\t\t\t\t\tcontinue; //table not found \t\t\t\t\t\t\ttry_module_get \t\t\t\t\t\tlist_for_each_entry(t, &xt_net->tables[af]...) \t\t\t\t\t\t\treturn t; //not get refcnt \t\t\t\t\t module_put(t->me) //uaf unregister_pernet_subsys //remove table from xt_net list While xt_table module was going away and has been removed from xt_templates list, we couldnt get refcnt of xt_table->me. Check module in xt_net->tables list re-traversal to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50258", "url": "https://ubuntu.com/security/CVE-2024-50258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix crash when config small gso_max_size/gso_ipv4_max_size Config a small gso_max_size/gso_ipv4_max_size will lead to an underflow in sk_dst_gso_max_size(), which may trigger a BUG_ON crash, because sk->sk_gso_max_size would be much bigger than device limits. Call Trace: tcp_write_xmit tso_segs = tcp_init_tso_segs(skb, mss_now); tcp_set_skb_tso_segs tcp_skb_pcount_set // skb->len = 524288, mss_now = 8 // u16 tso_segs = 524288/8 = 65535 -> 0 tso_segs = DIV_ROUND_UP(skb->len, mss_now) BUG_ON(!tso_segs) Add check for the minimum value of gso_max_size and gso_ipv4_max_size.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50262", "url": "https://ubuntu.com/security/CVE-2024-50262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix out-of-bounds write in trie_get_next_key() trie_get_next_key() allocates a node stack with size trie->max_prefixlen, while it writes (trie->max_prefixlen + 1) nodes to the stack when it has full paths from the root to leaves. For example, consider a trie with max_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ... 0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with .prefixlen = 8 make 9 nodes be written on the node stack with size 8.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53044", "url": "https://ubuntu.com/security/CVE-2024-53044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_api: fix xa_insert() error path in tcf_block_get_ext() This command: $ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact Error: block dev insert failed: -EBUSY. fails because user space requests the same block index to be set for both ingress and egress. [ side note, I don't think it even failed prior to commit 913b47d3424e (\"net/sched: Introduce tc block netdev tracking infra\"), because this is a command from an old set of notes of mine which used to work, but alas, I did not scientifically bisect this ] The problem is not that it fails, but rather, that the second time around, it fails differently (and irrecoverably): $ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact Error: dsa_core: Flow block cb is busy. [ another note: the extack is added by me for illustration purposes. the context of the problem is that clsact_init() obtains the same &q->ingress_block pointer as &q->egress_block, and since we call tcf_block_get_ext() on both of them, \"dev\" will be added to the block->ports xarray twice, thus failing the operation: once through the ingress block pointer, and once again through the egress block pointer. the problem itself is that when xa_insert() fails, we have emitted a FLOW_BLOCK_BIND command through ndo_setup_tc(), but the offload never sees a corresponding FLOW_BLOCK_UNBIND. ] Even correcting the bad user input, we still cannot recover: $ tc qdisc replace dev swp3 ingress_block 1 egress_block 2 clsact Error: dsa_core: Flow block cb is busy. Basically the only way to recover is to reboot the system, or unbind and rebind the net device driver. To fix the bug, we need to fill the correct error teardown path which was missed during code movement, and call tcf_block_offload_unbind() when xa_insert() fails. [ last note, fundamentally I blame the label naming convention in tcf_block_get_ext() for the bug. The labels should be named after what they do, not after the error path that jumps to them. This way, it is obviously wrong that two labels pointing to the same code mean something is wrong, and checking the code correctness at the goto site is also easier ]", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50259", "url": "https://ubuntu.com/security/CVE-2024-50259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netdevsim: Add trailing zero to terminate the string in nsim_nexthop_bucket_activity_write() This was found by a static analyzer. We should not forget the trailing zero after copy_from_user() if we will further do some string operations, sscanf() in this case. Adding a trailing zero will ensure that the function performs properly.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50304", "url": "https://ubuntu.com/security/CVE-2024-50304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find() The per-netns IP tunnel hash table is protected by the RTNL mutex and ip_tunnel_find() is only called from the control path where the mutex is taken. Add a lockdep expression to hlist_for_each_entry_rcu() in ip_tunnel_find() in order to validate that the mutex is held and to silence the suspicious RCU usage warning [1]. [1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gd95d9a31aceb #139 Not tainted ----------------------------- net/ipv4/ip_tunnel.c:221 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/362: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60 stack backtrace: CPU: 12 UID: 0 PID: 362 Comm: ip Not tainted 6.12.0-rc3-custom-gd95d9a31aceb #139 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 ip_tunnel_find+0x435/0x4d0 ip_tunnel_newlink+0x517/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53042", "url": "https://ubuntu.com/security/CVE-2024-53042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_init_flow() There are code paths from which the function is called without holding the RCU read lock, resulting in a suspicious RCU usage warning [1]. Fix by using l3mdev_master_upper_ifindex_by_index() which will acquire the RCU read lock before calling l3mdev_master_upper_ifindex_by_index_rcu(). [1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gac8f72681cf2 #141 Not tainted ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/361: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60 stack backtrace: CPU: 3 UID: 0 PID: 361 Comm: ip Not tainted 6.12.0-rc3-custom-gac8f72681cf2 #141 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 dev_get_by_index_rcu+0x1d3/0x210 l3mdev_master_upper_ifindex_by_index_rcu+0x2b/0xf0 ip_tunnel_bind_dev+0x72f/0xa00 ip_tunnel_newlink+0x368/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53048", "url": "https://ubuntu.com/security/CVE-2024-53048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix crash on probe for DPLL enabled E810 LOM The E810 Lan On Motherboard (LOM) design is vendor specific. Intel provides the reference design, but it is up to vendor on the final product design. For some cases, like Linux DPLL support, the static values defined in the driver does not reflect the actual LOM design. Current implementation of dpll pins is causing the crash on probe of the ice driver for such DPLL enabled E810 LOM designs: WARNING: (...) at drivers/dpll/dpll_core.c:495 dpll_pin_get+0x2c4/0x330 ... Call Trace: ? __warn+0x83/0x130 ? dpll_pin_get+0x2c4/0x330 ? report_bug+0x1b7/0x1d0 ? handle_bug+0x42/0x70 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? dpll_pin_get+0x117/0x330 ? dpll_pin_get+0x2c4/0x330 ? dpll_pin_get+0x117/0x330 ice_dpll_get_pins.isra.0+0x52/0xe0 [ice] ... The number of dpll pins enabled by LOM vendor is greater than expected and defined in the driver for Intel designed NICs, which causes the crash. Prevent the crash and allow generic pin initialization within Linux DPLL subsystem for DPLL enabled E810 LOM designs. Newly designed solution for described issue will be based on \"per HW design\" pin initialization. It requires pin information dynamically acquired from the firmware and is already in progress, planned for next-tree only.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53058", "url": "https://ubuntu.com/security/CVE-2024-53058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data In case the non-paged data of a SKB carries protocol header and protocol payload to be transmitted on a certain platform that the DMA AXI address width is configured to 40-bit/48-bit, or the size of the non-paged data is bigger than TSO_MAX_BUFF_SIZE on a certain platform that the DMA AXI address width is configured to 32-bit, then this SKB requires at least two DMA transmit descriptors to serve it. For example, three descriptors are allocated to split one DMA buffer mapped from one piece of non-paged data: dma_desc[N + 0], dma_desc[N + 1], dma_desc[N + 2]. Then three elements of tx_q->tx_skbuff_dma[] will be allocated to hold extra information to be reused in stmmac_tx_clean(): tx_q->tx_skbuff_dma[N + 0], tx_q->tx_skbuff_dma[N + 1], tx_q->tx_skbuff_dma[N + 2]. Now we focus on tx_q->tx_skbuff_dma[entry].buf, which is the DMA buffer address returned by DMA mapping call. stmmac_tx_clean() will try to unmap the DMA buffer _ONLY_IF_ tx_q->tx_skbuff_dma[entry].buf is a valid buffer address. The expected behavior that saves DMA buffer address of this non-paged data to tx_q->tx_skbuff_dma[entry].buf is: tx_q->tx_skbuff_dma[N + 0].buf = NULL; tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = dma_map_single(); Unfortunately, the current code misbehaves like this: tx_q->tx_skbuff_dma[N + 0].buf = dma_map_single(); tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = NULL; On the stmmac_tx_clean() side, when dma_desc[N + 0] is closed by the DMA engine, tx_q->tx_skbuff_dma[N + 0].buf is a valid buffer address obviously, then the DMA buffer will be unmapped immediately. There may be a rare case that the DMA engine does not finish the pending dma_desc[N + 1], dma_desc[N + 2] yet. Now things will go horribly wrong, DMA is going to access a unmapped/unreferenced memory region, corrupted data will be transmited or iommu fault will be triggered :( In contrast, the for-loop that maps SKB fragments behaves perfectly as expected, and that is how the driver should do for both non-paged data and paged frags actually. This patch corrects DMA map/unmap sequences by fixing the array index for tx_q->tx_skbuff_dma[entry].buf when assigning DMA buffer address. Tested and verified on DWXGMAC CORE 3.20a", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50260", "url": "https://ubuntu.com/security/CVE-2024-50260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sock_map: fix a NULL pointer dereference in sock_map_link_update_prog() The following race condition could trigger a NULL pointer dereference: sock_map_link_detach():\t\tsock_map_link_update_prog(): mutex_lock(&sockmap_mutex); ... sockmap_link->map = NULL; mutex_unlock(&sockmap_mutex); \t\t\t\t mutex_lock(&sockmap_mutex); \t\t\t\t ... \t\t\t\t sock_map_prog_link_lookup(sockmap_link->map); \t\t\t\t mutex_unlock(&sockmap_mutex); Fix it by adding a NULL pointer check. In this specific case, it makes no sense to update a link which is being released.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53045", "url": "https://ubuntu.com/security/CVE-2024-53045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: dapm: fix bounds checker error in dapm_widget_list_create The widgets array in the snd_soc_dapm_widget_list has a __counted_by attribute attached to it, which points to the num_widgets variable. This attribute is used in bounds checking, and if it is not set before the array is filled, then the bounds sanitizer will issue a warning or a kernel panic if CONFIG_UBSAN_TRAP is set. This patch sets the size of the widgets list calculated with list_for_each as the initial value for num_widgets as it is used for allocating memory for the array. It is updated with the actual number of added elements after the array is filled.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50261", "url": "https://ubuntu.com/security/CVE-2024-50261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macsec: Fix use-after-free while sending the offloading packet KASAN reports the following UAF. The metadata_dst, which is used to store the SCI value for macsec offload, is already freed by metadata_dst_free() in macsec_free_netdev(), while driver still use it for sending the packet. To fix this issue, dst_release() is used instead to release metadata_dst. So it is not freed instantly in macsec_free_netdev() if still referenced by skb. BUG: KASAN: slab-use-after-free in mlx5e_xmit+0x1e8f/0x4190 [mlx5_core] Read of size 2 at addr ffff88813e42e038 by task kworker/7:2/714 [...] Workqueue: mld mld_ifc_work Call Trace: dump_stack_lvl+0x51/0x60 print_report+0xc1/0x600 kasan_report+0xab/0xe0 mlx5e_xmit+0x1e8f/0x4190 [mlx5_core] dev_hard_start_xmit+0x120/0x530 sch_direct_xmit+0x149/0x11e0 __qdisc_run+0x3ad/0x1730 __dev_queue_xmit+0x1196/0x2ed0 vlan_dev_hard_start_xmit+0x32e/0x510 [8021q] dev_hard_start_xmit+0x120/0x530 __dev_queue_xmit+0x14a7/0x2ed0 macsec_start_xmit+0x13e9/0x2340 dev_hard_start_xmit+0x120/0x530 __dev_queue_xmit+0x14a7/0x2ed0 ip6_finish_output2+0x923/0x1a70 ip6_finish_output+0x2d7/0x970 ip6_output+0x1ce/0x3a0 NF_HOOK.constprop.0+0x15f/0x190 mld_sendpack+0x59a/0xbd0 mld_ifc_work+0x48a/0xa80 process_one_work+0x5aa/0xe50 worker_thread+0x79c/0x1290 kthread+0x28f/0x350 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x11/0x20 Allocated by task 3922: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 __kasan_kmalloc+0x77/0x90 __kmalloc_noprof+0x188/0x400 metadata_dst_alloc+0x1f/0x4e0 macsec_newlink+0x914/0x1410 __rtnl_newlink+0xe08/0x15b0 rtnl_newlink+0x5f/0x90 rtnetlink_rcv_msg+0x667/0xa80 netlink_rcv_skb+0x12c/0x360 netlink_unicast+0x551/0x770 netlink_sendmsg+0x72d/0xbd0 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x52e/0x6a0 ___sys_sendmsg+0xeb/0x170 __sys_sendmsg+0xb5/0x140 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Freed by task 4011: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x50 poison_slab_object+0x10c/0x190 __kasan_slab_free+0x11/0x30 kfree+0xe0/0x290 macsec_free_netdev+0x3f/0x140 netdev_run_todo+0x450/0xc70 rtnetlink_rcv_msg+0x66f/0xa80 netlink_rcv_skb+0x12c/0x360 netlink_unicast+0x551/0x770 netlink_sendmsg+0x72d/0xbd0 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x52e/0x6a0 ___sys_sendmsg+0xeb/0x170 __sys_sendmsg+0xb5/0x140 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53059", "url": "https://ubuntu.com/security/CVE-2024-53059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd() 1. The size of the response packet is not validated. 2. The response buffer is not freed. Resolve these issues by switching to iwl_mvm_send_cmd_status(), which handles both size validation and frees the buffer.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53074", "url": "https://ubuntu.com/security/CVE-2024-53074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: don't leak a link on AP removal Release the link mapping resource in AP removal. This impacted devices that do not support the MLD API (9260 and down). On those devices, we couldn't start the AP again after the AP has been already started and stopped.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53049", "url": "https://ubuntu.com/security/CVE-2024-53049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slub/kunit: fix a WARNING due to unwrapped __kmalloc_cache_noprof 'modprobe slub_kunit' will have a warning as shown below. The root cause is that __kmalloc_cache_noprof was directly used, which resulted in no alloc_tag being allocated. This caused current->alloc_tag to be null, leading to a warning in alloc_tag_add_check. Let's add an alloc_hook layer to __kmalloc_cache_noprof specifically within lib/slub_kunit.c, which is the only user of this internal slub function outside kmalloc implementation itself. [58162.947016] WARNING: CPU: 2 PID: 6210 at ./include/linux/alloc_tag.h:125 alloc_tagging_slab_alloc_hook+0x268/0x27c [58162.957721] Call trace: [58162.957919] alloc_tagging_slab_alloc_hook+0x268/0x27c [58162.958286] __kmalloc_cache_noprof+0x14c/0x344 [58162.958615] test_kmalloc_redzone_access+0x50/0x10c [slub_kunit] [58162.959045] kunit_try_run_case+0x74/0x184 [kunit] [58162.959401] kunit_generic_run_threadfn_adapter+0x2c/0x4c [kunit] [58162.959841] kthread+0x10c/0x118 [58162.960093] ret_from_fork+0x10/0x20 [58162.960363] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50192", "url": "https://ubuntu.com/security/CVE-2024-50192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v4: Don't allow a VMOVP on a dying VPE Kunkun Jiang reported that there is a small window of opportunity for userspace to force a change of affinity for a VPE while the VPE has already been unmapped, but the corresponding doorbell interrupt still visible in /proc/irq/. Plug the race by checking the value of vmapp_count, which tracks whether the VPE is mapped ot not, and returning an error in this case. This involves making vmapp_count common to both GICv4.1 and its v4.0 ancestor.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50069", "url": "https://ubuntu.com/security/CVE-2024-50069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: apple: check devm_kasprintf() returned value devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked. Fix this lack and check the returned value. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50070", "url": "https://ubuntu.com/security/CVE-2024-50070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: stm32: check devm_kasprintf() returned value devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked. Fix this lack and check the returned value. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50196", "url": "https://ubuntu.com/security/CVE-2024-50196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: ocelot: fix system hang on level based interrupts The current implementation only calls chained_irq_enter() and chained_irq_exit() if it detects pending interrupts. ``` for (i = 0; i < info->stride; i++) { \turegmap_read(info->map, id_reg + 4 * i, ®); \tif (!reg) \t\tcontinue; \tchained_irq_enter(parent_chip, desc); ``` However, in case of GPIO pin configured in level mode and the parent controller configured in edge mode, GPIO interrupt might be lowered by the hardware. In the result, if the interrupt is short enough, the parent interrupt is still pending while the GPIO interrupt is cleared; chained_irq_enter() never gets called and the system hangs trying to service the parent interrupt. Moving chained_irq_enter() and chained_irq_exit() outside the for loop ensures that they are called even when GPIO interrupt is lowered by the hardware. The similar code with chained_irq_enter() / chained_irq_exit() functions wrapping interrupt checking loop may be found in many other drivers: ``` grep -r -A 10 chained_irq_enter drivers/pinctrl ```", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50197", "url": "https://ubuntu.com/security/CVE-2024-50197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: intel: platform: fix error path in device_for_each_child_node() The device_for_each_child_node() loop requires calls to fwnode_handle_put() upon early returns to decrement the refcount of the child node and avoid leaking memory if that error path is triggered. There is one early returns within that loop in intel_platform_pinctrl_prepare_community(), but fwnode_handle_put() is missing. Instead of adding the missing call, the scoped version of the loop can be used to simplify the code and avoid mistakes in the future if new early returns are added, as the child node is only used for parsing, and it is never assigned.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50071", "url": "https://ubuntu.com/security/CVE-2024-50071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: nuvoton: fix a double free in ma35_pinctrl_dt_node_to_map_func() 'new_map' is allocated using devm_* which takes care of freeing the allocated data on device removal, call to \t.dt_free_map = pinconf_generic_dt_free_map double frees the map as pinconf_generic_dt_free_map() calls pinctrl_utils_free_map(). Fix this by using kcalloc() instead of auto-managed devm_kcalloc().", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50072", "url": "https://ubuntu.com/security/CVE-2024-50072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/bugs: Use code segment selector for VERW operand Robert Gill reported below #GP in 32-bit mode when dosemu software was executing vm86() system call: general protection fault: 0000 [#1] PREEMPT SMP CPU: 4 PID: 4610 Comm: dosemu.bin Not tainted 6.6.21-gentoo-x86 #1 Hardware name: Dell Inc. PowerEdge 1950/0H723K, BIOS 2.7.0 10/30/2010 EIP: restore_all_switch_stack+0xbe/0xcf EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000 ESI: 00000000 EDI: 00000000 EBP: 00000000 ESP: ff8affdc DS: 0000 ES: 0000 FS: 0000 GS: 0033 SS: 0068 EFLAGS: 00010046 CR0: 80050033 CR2: 00c2101c CR3: 04b6d000 CR4: 000406d0 Call Trace: show_regs+0x70/0x78 die_addr+0x29/0x70 exc_general_protection+0x13c/0x348 exc_bounds+0x98/0x98 handle_exception+0x14d/0x14d exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf This only happens in 32-bit mode when VERW based mitigations like MDS/RFDS are enabled. This is because segment registers with an arbitrary user value can result in #GP when executing VERW. Intel SDM vol. 2C documents the following behavior for VERW instruction: #GP(0) - If a memory operand effective address is outside the CS, DS, ES, \t FS, or GS segment limit. CLEAR_CPU_BUFFERS macro executes VERW instruction before returning to user space. Use %cs selector to reference VERW operand. This ensures VERW will not #GP for an arbitrary user %ds. [ mingo: Fixed the SOB chain. ]", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50073", "url": "https://ubuntu.com/security/CVE-2024-50073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: Fix use-after-free in gsm_cleanup_mux BUG: KASAN: slab-use-after-free in gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] Read of size 8 at addr ffff88815fe99c00 by task poc/3379 CPU: 0 UID: 0 PID: 3379 Comm: poc Not tainted 6.11.0+ #56 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] __pfx_gsm_cleanup_mux+0x10/0x10 drivers/tty/n_gsm.c:3124 [n_gsm] __pfx_sched_clock_cpu+0x10/0x10 kernel/sched/clock.c:389 update_load_avg+0x1c1/0x27b0 kernel/sched/fair.c:4500 __pfx_min_vruntime_cb_rotate+0x10/0x10 kernel/sched/fair.c:846 __rb_insert_augmented+0x492/0xbf0 lib/rbtree.c:161 gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] _raw_spin_lock_irqsave+0x92/0xf0 arch/x86/include/asm/atomic.h:107 __pfx_gsmld_ioctl+0x10/0x10 drivers/tty/n_gsm.c:3822 [n_gsm] ktime_get+0x5e/0x140 kernel/time/timekeeping.c:195 ldsem_down_read+0x94/0x4e0 arch/x86/include/asm/atomic64_64.h:79 __pfx_ldsem_down_read+0x10/0x10 drivers/tty/tty_ldsem.c:338 __pfx_do_vfs_ioctl+0x10/0x10 fs/ioctl.c:805 tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 Allocated by task 65: gsm_data_alloc.constprop.0+0x27/0x190 drivers/tty/n_gsm.c:926 [n_gsm] gsm_send+0x2c/0x580 drivers/tty/n_gsm.c:819 [n_gsm] gsm1_receive+0x547/0xad0 drivers/tty/n_gsm.c:3038 [n_gsm] gsmld_receive_buf+0x176/0x280 drivers/tty/n_gsm.c:3609 [n_gsm] tty_ldisc_receive_buf+0x101/0x1e0 drivers/tty/tty_buffer.c:391 tty_port_default_receive_buf+0x61/0xa0 drivers/tty/tty_port.c:39 flush_to_ldisc+0x1b0/0x750 drivers/tty/tty_buffer.c:445 process_scheduled_works+0x2b0/0x10d0 kernel/workqueue.c:3229 worker_thread+0x3dc/0x950 kernel/workqueue.c:3391 kthread+0x2a3/0x370 kernel/kthread.c:389 ret_from_fork+0x2d/0x70 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:257 Freed by task 3367: kfree+0x126/0x420 mm/slub.c:4580 gsm_cleanup_mux+0x36c/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 [Analysis] gsm_msg on the tx_ctrl_list or tx_data_list of gsm_mux can be freed by multi threads through ioctl,which leads to the occurrence of uaf. Protect it by gsm tx lock.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50193", "url": "https://ubuntu.com/security/CVE-2024-50193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/entry_32: Clear CPU buffers after register restore in NMI return CPU buffers are currently cleared after call to exc_nmi, but before register state is restored. This may be okay for MDS mitigation but not for RDFS. Because RDFS mitigation requires CPU buffers to be cleared when registers don't have any sensitive data. Move CLEAR_CPU_BUFFERS after RESTORE_ALL_NMI.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50074", "url": "https://ubuntu.com/security/CVE-2024-50074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: parport: Proper fix for array out-of-bounds access The recent fix for array out-of-bounds accesses replaced sprintf() calls blindly with snprintf(). However, since snprintf() returns the would-be-printed size, not the actually output size, the length calculation can still go over the given limit. Use scnprintf() instead of snprintf(), which returns the actually output letters, for addressing the potential out-of-bounds access properly.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50100", "url": "https://ubuntu.com/security/CVE-2024-50100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: gadget: dummy-hcd: Fix \"task hung\" problem The syzbot fuzzer has been encountering \"task hung\" problems ever since the dummy-hcd driver was changed to use hrtimers instead of regular timers. It turns out that the problems are caused by a subtle difference between the timer_pending() and hrtimer_active() APIs. The changeover blindly replaced the first by the second. However, timer_pending() returns True when the timer is queued but not when its callback is running, whereas hrtimer_active() returns True when the hrtimer is queued _or_ its callback is running. This difference occasionally caused dummy_urb_enqueue() to think that the callback routine had not yet started when in fact it was almost finished. As a result the hrtimer was not restarted, which made it impossible for the driver to dequeue later the URB that was just enqueued. This caused usb_kill_urb() to hang, and things got worse from there. Since hrtimers have no API for telling when they are queued and the callback isn't running, the driver must keep track of this for itself. That's what this patch does, adding a new \"timer_pending\" flag and setting or clearing it at the appropriate times.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50075", "url": "https://ubuntu.com/security/CVE-2024-50075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xhci: tegra: fix checked USB2 port number If USB virtualizatoin is enabled, USB2 ports are shared between all Virtual Functions. The USB2 port number owned by an USB2 root hub in a Virtual Function may be less than total USB2 phy number supported by the Tegra XUSB controller. Using total USB2 phy number as port number to check all PORTSC values would cause invalid memory access. [ 116.923438] Unable to handle kernel paging request at virtual address 006c622f7665642f ... [ 117.213640] Call trace: [ 117.216783] tegra_xusb_enter_elpg+0x23c/0x658 [ 117.222021] tegra_xusb_runtime_suspend+0x40/0x68 [ 117.227260] pm_generic_runtime_suspend+0x30/0x50 [ 117.232847] __rpm_callback+0x84/0x3c0 [ 117.237038] rpm_suspend+0x2dc/0x740 [ 117.241229] pm_runtime_work+0xa0/0xb8 [ 117.245769] process_scheduled_works+0x24c/0x478 [ 117.251007] worker_thread+0x23c/0x328 [ 117.255547] kthread+0x104/0x1b0 [ 117.259389] ret_from_fork+0x10/0x20 [ 117.263582] Code: 54000222 f9461ae8 f8747908 b4ffff48 (f9400100)", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50076", "url": "https://ubuntu.com/security/CVE-2024-50076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vt: prevent kernel-infoleak in con_font_get() font.data may not initialize all memory spaces depending on the implementation of vc->vc_sw->con_font_get. This may cause info-leak, so to prevent this, it is safest to modify it to initialize the allocated memory space to 0, and it generally does not affect the overall performance of the system.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50077", "url": "https://ubuntu.com/security/CVE-2024-50077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix multiple init when debugfs is disabled If bt_debugfs is not created successfully, which happens if either CONFIG_DEBUG_FS or CONFIG_DEBUG_FS_ALLOW_ALL is unset, then iso_init() returns early and does not set iso_inited to true. This means that a subsequent call to iso_init() will result in duplicate calls to proto_register(), bt_sock_register(), etc. With CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, the duplicate call to proto_register() triggers this BUG(): list_add double add: new=ffffffffc0b280d0, prev=ffffffffbab56250, next=ffffffffc0b280d0. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:35! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 2 PID: 887 Comm: bluetoothd Not tainted 6.10.11-1-ao-desktop #1 RIP: 0010:__list_add_valid_or_report+0x9a/0xa0 ... __list_add_valid_or_report+0x9a/0xa0 proto_register+0x2b5/0x340 iso_init+0x23/0x150 [bluetooth] set_iso_socket_func+0x68/0x1b0 [bluetooth] kmem_cache_free+0x308/0x330 hci_sock_sendmsg+0x990/0x9e0 [bluetooth] __sock_sendmsg+0x7b/0x80 sock_write_iter+0x9a/0x110 do_iter_readv_writev+0x11d/0x220 vfs_writev+0x180/0x3e0 do_writev+0xca/0x100 ... This change removes the early return. The check for iso_debugfs being NULL was unnecessary, it is always NULL when iso_inited is false.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50078", "url": "https://ubuntu.com/security/CVE-2024-50078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Call iso_exit() on module unload If iso_init() has been called, iso_exit() must be called on module unload. Without that, the struct proto that iso_init() registered with proto_register() becomes invalid, which could cause unpredictable problems later. In my case, with CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, loading the module again usually triggers this BUG(): list_add corruption. next->prev should be prev (ffffffffb5355fd0), but was 0000000000000068. (next=ffffffffc0a010d0). ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:29! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 4159 Comm: modprobe Not tainted 6.10.11-4+bt2-ao-desktop #1 RIP: 0010:__list_add_valid_or_report+0x61/0xa0 ... __list_add_valid_or_report+0x61/0xa0 proto_register+0x299/0x320 hci_sock_init+0x16/0xc0 [bluetooth] bt_init+0x68/0xd0 [bluetooth] __pfx_bt_init+0x10/0x10 [bluetooth] do_one_initcall+0x80/0x2f0 do_init_module+0x8b/0x230 __do_sys_init_module+0x15f/0x190 do_syscall_64+0x68/0x110 ...", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50198", "url": "https://ubuntu.com/security/CVE-2024-50198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: veml6030: fix IIO device retrieval from embedded device The dev pointer that is received as an argument in the in_illuminance_period_available_show function references the device embedded in the IIO device, not in the i2c client. dev_to_iio_dev() must be used to accessthe right data. The current implementation leads to a segmentation fault on every attempt to read the attribute because indio_dev gets a NULL assignment. This bug has been present since the first appearance of the driver, apparently since the last version (V6) before getting applied. A constant attribute was used until then, and the last modifications might have not been tested again.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50201", "url": "https://ubuntu.com/security/CVE-2024-50201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: Fix encoder->possible_clones Include the encoder itself in its possible_clones bitmask. In the past nothing validated that drivers were populating possible_clones correctly, but that changed in commit 74d2aacbe840 (\"drm: Validate encoder->possible_clones\"). Looks like radeon never got the memo and is still not following the rules 100% correctly. This results in some warnings during driver initialization: Bogus possible_clones: [ENCODER:46:TV-46] possible_clones=0x4 (full encoder mask=0x7) WARNING: CPU: 0 PID: 170 at drivers/gpu/drm/drm_mode_config.c:615 drm_mode_config_validate+0x113/0x39c ... (cherry picked from commit 3b6e7d40649c0d75572039aff9d0911864c689db)", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50098", "url": "https://ubuntu.com/security/CVE-2024-50098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Set SDEV_OFFLINE when UFS is shut down There is a history of deadlock if reboot is performed at the beginning of booting. SDEV_QUIESCE was set for all LU's scsi_devices by UFS shutdown, and at that time the audio driver was waiting on blk_mq_submit_bio() holding a mutex_lock while reading the fw binary. After that, a deadlock issue occurred while audio driver shutdown was waiting for mutex_unlock of blk_mq_submit_bio(). To solve this, set SDEV_OFFLINE for all LUs except WLUN, so that any I/O that comes down after a UFS shutdown will return an error. [ 31.907781]I[0: swapper/0: 0] 1 130705007 1651079834 11289729804 0 D( 2) 3 ffffff882e208000 * init [device_shutdown] [ 31.907793]I[0: swapper/0: 0] Mutex: 0xffffff8849a2b8b0: owner[0xffffff882e28cb00 kworker/6:0 :49] [ 31.907806]I[0: swapper/0: 0] Call trace: [ 31.907810]I[0: swapper/0: 0] __switch_to+0x174/0x338 [ 31.907819]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc [ 31.907826]I[0: swapper/0: 0] schedule+0x7c/0xe8 [ 31.907834]I[0: swapper/0: 0] schedule_preempt_disabled+0x24/0x40 [ 31.907842]I[0: swapper/0: 0] __mutex_lock+0x408/0xdac [ 31.907849]I[0: swapper/0: 0] __mutex_lock_slowpath+0x14/0x24 [ 31.907858]I[0: swapper/0: 0] mutex_lock+0x40/0xec [ 31.907866]I[0: swapper/0: 0] device_shutdown+0x108/0x280 [ 31.907875]I[0: swapper/0: 0] kernel_restart+0x4c/0x11c [ 31.907883]I[0: swapper/0: 0] __arm64_sys_reboot+0x15c/0x280 [ 31.907890]I[0: swapper/0: 0] invoke_syscall+0x70/0x158 [ 31.907899]I[0: swapper/0: 0] el0_svc_common+0xb4/0xf4 [ 31.907909]I[0: swapper/0: 0] do_el0_svc+0x2c/0xb0 [ 31.907918]I[0: swapper/0: 0] el0_svc+0x34/0xe0 [ 31.907928]I[0: swapper/0: 0] el0t_64_sync_handler+0x68/0xb4 [ 31.907937]I[0: swapper/0: 0] el0t_64_sync+0x1a0/0x1a4 [ 31.908774]I[0: swapper/0: 0] 49 0 11960702 11236868007 0 D( 2) 6 ffffff882e28cb00 * kworker/6:0 [__bio_queue_enter] [ 31.908783]I[0: swapper/0: 0] Call trace: [ 31.908788]I[0: swapper/0: 0] __switch_to+0x174/0x338 [ 31.908796]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc [ 31.908803]I[0: swapper/0: 0] schedule+0x7c/0xe8 [ 31.908811]I[0: swapper/0: 0] __bio_queue_enter+0xb8/0x178 [ 31.908818]I[0: swapper/0: 0] blk_mq_submit_bio+0x194/0x67c [ 31.908827]I[0: swapper/0: 0] __submit_bio+0xb8/0x19c", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50079", "url": "https://ubuntu.com/security/CVE-2024-50079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/sqpoll: ensure task state is TASK_RUNNING when running task_work When the sqpoll is exiting and cancels pending work items, it may need to run task_work. If this happens from within io_uring_cancel_generic(), then it may be under waiting for the io_uring_task waitqueue. This results in the below splat from the scheduler, as the ring mutex may be attempted grabbed while in a TASK_INTERRUPTIBLE state. Ensure that the task state is set appropriately for that, just like what is done for the other cases in io_run_task_work(). do not call blocking ops when !TASK_RUNNING; state=1 set at [<0000000029387fd2>] prepare_to_wait+0x88/0x2fc WARNING: CPU: 6 PID: 59939 at kernel/sched/core.c:8561 __might_sleep+0xf4/0x140 Modules linked in: CPU: 6 UID: 0 PID: 59939 Comm: iou-sqp-59938 Not tainted 6.12.0-rc3-00113-g8d020023b155 #7456 Hardware name: linux,dummy-virt (DT) pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : __might_sleep+0xf4/0x140 lr : __might_sleep+0xf4/0x140 sp : ffff80008c5e7830 x29: ffff80008c5e7830 x28: ffff0000d93088c0 x27: ffff60001c2d7230 x26: dfff800000000000 x25: ffff0000e16b9180 x24: ffff80008c5e7a50 x23: 1ffff000118bcf4a x22: ffff0000e16b9180 x21: ffff0000e16b9180 x20: 000000000000011b x19: ffff80008310fac0 x18: 1ffff000118bcd90 x17: 30303c5b20746120 x16: 74657320313d6574 x15: 0720072007200720 x14: 0720072007200720 x13: 0720072007200720 x12: ffff600036c64f0b x11: 1fffe00036c64f0a x10: ffff600036c64f0a x9 : dfff800000000000 x8 : 00009fffc939b0f6 x7 : ffff0001b6327853 x6 : 0000000000000001 x5 : ffff0001b6327850 x4 : ffff600036c64f0b x3 : ffff8000803c35bc x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000e16b9180 Call trace: __might_sleep+0xf4/0x140 mutex_lock+0x84/0x124 io_handle_tw_list+0xf4/0x260 tctx_task_work_run+0x94/0x340 io_run_task_work+0x1ec/0x3c0 io_uring_cancel_generic+0x364/0x524 io_sq_thread+0x820/0x124c ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50080", "url": "https://ubuntu.com/security/CVE-2024-50080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: don't allow user copy for unprivileged device UBLK_F_USER_COPY requires userspace to call write() on ublk char device for filling request buffer, and unprivileged device can't be trusted. So don't allow user copy for unprivileged device.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50081", "url": "https://ubuntu.com/security/CVE-2024-50081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-mq: setup queue ->tag_set before initializing hctx Commit 7b815817aa58 (\"blk-mq: add helper for checking if one CPU is mapped to specified hctx\") needs to check queue mapping via tag set in hctx's cpuhp handler. However, q->tag_set may not be setup yet when the cpuhp handler is enabled, then kernel oops is triggered. Fix the issue by setup queue tag_set before initializing hctx.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50082", "url": "https://ubuntu.com/security/CVE-2024-50082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race We're seeing crashes from rq_qos_wake_function that look like this: BUG: unable to handle page fault for address: ffffafe180a40084 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 100000067 P4D 100000067 PUD 10027c067 PMD 10115d067 PTE 0 Oops: Oops: 0002 [#1] PREEMPT SMP PTI CPU: 17 UID: 0 PID: 0 Comm: swapper/17 Not tainted 6.12.0-rc3-00013-geca631b8fe80 #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:_raw_spin_lock_irqsave+0x1d/0x40 Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 9c 41 5c fa 65 ff 05 62 97 30 4c 31 c0 ba 01 00 00 00 0f b1 17 75 0a 4c 89 e0 41 5c c3 cc cc cc cc 89 c6 e8 2c 0b 00 RSP: 0018:ffffafe180580ca0 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffffafe180a3f7a8 RCX: 0000000000000011 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffffafe180a40084 RBP: 0000000000000000 R08: 00000000001e7240 R09: 0000000000000011 R10: 0000000000000028 R11: 0000000000000888 R12: 0000000000000002 R13: ffffafe180a40084 R14: 0000000000000000 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff9aaf1f280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffafe180a40084 CR3: 000000010e428002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: try_to_wake_up+0x5a/0x6a0 rq_qos_wake_function+0x71/0x80 __wake_up_common+0x75/0xa0 __wake_up+0x36/0x60 scale_up.part.0+0x50/0x110 wb_timer_fn+0x227/0x450 ... So rq_qos_wake_function() calls wake_up_process(data->task), which calls try_to_wake_up(), which faults in raw_spin_lock_irqsave(&p->pi_lock). p comes from data->task, and data comes from the waitqueue entry, which is stored on the waiter's stack in rq_qos_wait(). Analyzing the core dump with drgn, I found that the waiter had already woken up and moved on to a completely unrelated code path, clobbering what was previously data->task. Meanwhile, the waker was passing the clobbered garbage in data->task to wake_up_process(), leading to the crash. What's happening is that in between rq_qos_wake_function() deleting the waitqueue entry and calling wake_up_process(), rq_qos_wait() is finding that it already got a token and returning. The race looks like this: rq_qos_wait() rq_qos_wake_function() ============================================================== prepare_to_wait_exclusive() data->got_token = true; list_del_init(&curr->entry); if (data.got_token) break; finish_wait(&rqw->wait, &data.wq); ^- returns immediately because list_empty_careful(&wq_entry->entry) is true ... return, go do something else ... wake_up_process(data->task) (NO LONGER VALID!)-^ Normally, finish_wait() is supposed to synchronize against the waker. But, as noted above, it is returning immediately because the waitqueue entry has already been removed from the waitqueue. The bug is that rq_qos_wake_function() is accessing the waitqueue entry AFTER deleting it. Note that autoremove_wake_function() wakes the waiter and THEN deletes the waitqueue entry, which is the proper order. Fix it by swapping the order. We also need to use list_del_init_careful() to match the list_empty_careful() in finish_wait().", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50101", "url": "https://ubuntu.com/security/CVE-2024-50101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI devices Previously, the domain_context_clear() function incorrectly called pci_for_each_dma_alias() to set up context entries for non-PCI devices. This could lead to kernel hangs or other unexpected behavior. Add a check to only call pci_for_each_dma_alias() for PCI devices. For non-PCI devices, domain_context_clear_one() is called directly.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50083", "url": "https://ubuntu.com/security/CVE-2024-50083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix mptcp DSS corruption due to large pmtu xmit Syzkaller was able to trigger a DSS corruption: TCP: request_sock_subflow_v4: Possible SYN flooding on port [::]:20002. Sending cookies. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 5227 at net/mptcp/protocol.c:695 __mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695 Modules linked in: CPU: 0 UID: 0 PID: 5227 Comm: syz-executor350 Not tainted 6.11.0-syzkaller-08829-gaf9c191ac2a0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:__mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695 Code: 0f b6 dc 31 ff 89 de e8 b5 dd ea f5 89 d8 48 81 c4 50 01 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 98 da ea f5 90 <0f> 0b 90 e9 47 ff ff ff e8 8a da ea f5 90 0f 0b 90 e9 99 e0 ff ff RSP: 0018:ffffc90000006db8 EFLAGS: 00010246 RAX: ffffffff8ba9df18 RBX: 00000000000055f0 RCX: ffff888030023c00 RDX: 0000000000000100 RSI: 00000000000081e5 RDI: 00000000000055f0 RBP: 1ffff110062bf1ae R08: ffffffff8ba9cf12 R09: 1ffff110062bf1b8 R10: dffffc0000000000 R11: ffffed10062bf1b9 R12: 0000000000000000 R13: dffffc0000000000 R14: 00000000700cec61 R15: 00000000000081e5 FS: 000055556679c380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020287000 CR3: 0000000077892000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: move_skbs_to_msk net/mptcp/protocol.c:811 [inline] mptcp_data_ready+0x29c/0xa90 net/mptcp/protocol.c:854 subflow_data_ready+0x34a/0x920 net/mptcp/subflow.c:1490 tcp_data_queue+0x20fd/0x76c0 net/ipv4/tcp_input.c:5283 tcp_rcv_established+0xfba/0x2020 net/ipv4/tcp_input.c:6237 tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915 tcp_v4_rcv+0x2dc0/0x37f0 net/ipv4/tcp_ipv4.c:2350 ip_protocol_deliver_rcu+0x22e/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x341/0x5f0 net/ipv4/ip_input.c:233 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314 __netif_receive_skb_one_core net/core/dev.c:5662 [inline] __netif_receive_skb+0x2bf/0x650 net/core/dev.c:5775 process_backlog+0x662/0x15b0 net/core/dev.c:6107 __napi_poll+0xcb/0x490 net/core/dev.c:6771 napi_poll net/core/dev.c:6840 [inline] net_rx_action+0x89b/0x1240 net/core/dev.c:6962 handle_softirqs+0x2c5/0x980 kernel/softirq.c:554 do_softirq+0x11b/0x1e0 kernel/softirq.c:455 __local_bh_enable_ip+0x1bb/0x200 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0x1764/0x3e80 net/core/dev.c:4451 dev_queue_xmit include/linux/netdevice.h:3094 [inline] neigh_hh_output include/net/neighbour.h:526 [inline] neigh_output include/net/neighbour.h:540 [inline] ip_finish_output2+0xd41/0x1390 net/ipv4/ip_output.c:236 ip_local_out net/ipv4/ip_output.c:130 [inline] __ip_queue_xmit+0x118c/0x1b80 net/ipv4/ip_output.c:536 __tcp_transmit_skb+0x2544/0x3b30 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_mtu_probe net/ipv4/tcp_output.c:2547 [inline] tcp_write_xmit+0x641d/0x6bf0 net/ipv4/tcp_output.c:2752 __tcp_push_pending_frames+0x9b/0x360 net/ipv4/tcp_output.c:3015 tcp_push_pending_frames include/net/tcp.h:2107 [inline] tcp_data_snd_check net/ipv4/tcp_input.c:5714 [inline] tcp_rcv_established+0x1026/0x2020 net/ipv4/tcp_input.c:6239 tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915 sk_backlog_rcv include/net/sock.h:1113 [inline] __release_sock+0x214/0x350 net/core/sock.c:3072 release_sock+0x61/0x1f0 net/core/sock.c:3626 mptcp_push_ ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50068", "url": "https://ubuntu.com/security/CVE-2024-50068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/tests/sysfs-kunit.h: fix memory leak in damon_sysfs_test_add_targets() The sysfs_target->regions allocated in damon_sysfs_regions_alloc() is not freed in damon_sysfs_test_add_targets(), which cause the following memory leak, free it to fix it. \tunreferenced object 0xffffff80c2a8db80 (size 96): \t comm \"kunit_try_catch\", pid 187, jiffies 4294894363 \t hex dump (first 32 bytes): \t 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ \t 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ \t backtrace (crc 0): \t [<0000000001e3714d>] kmemleak_alloc+0x34/0x40 \t [<000000008e6835c1>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000001286d9f8>] damon_sysfs_test_add_targets+0x1cc/0x738 \t [<0000000032ef8f77>] kunit_try_run_case+0x13c/0x3ac \t [<00000000f3edea23>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000adf936cf>] kthread+0x2e8/0x374 \t [<0000000041bb1628>] ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50199", "url": "https://ubuntu.com/security/CVE-2024-50199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/swapfile: skip HugeTLB pages for unuse_vma I got a bad pud error and lost a 1GB HugeTLB when calling swapoff. The problem can be reproduced by the following steps: 1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory. 2. Swapout the above anonymous memory. 3. run swapoff and we will get a bad pud error in kernel message: mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7) We can tell that pud_clear_bad is called by pud_none_or_clear_bad in unuse_pud_range() by ftrace. And therefore the HugeTLB pages will never be freed because we lost it from page table. We can skip HugeTLB pages for unuse_vma to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50066", "url": "https://ubuntu.com/security/CVE-2024-50066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mremap: fix move_normal_pmd/retract_page_tables race In mremap(), move_page_tables() looks at the type of the PMD entry and the specified address range to figure out by which method the next chunk of page table entries should be moved. At that point, the mmap_lock is held in write mode, but no rmap locks are held yet. For PMD entries that point to page tables and are fully covered by the source address range, move_pgt_entry(NORMAL_PMD, ...) is called, which first takes rmap locks, then does move_normal_pmd(). move_normal_pmd() takes the necessary page table locks at source and destination, then moves an entire page table from the source to the destination. The problem is: The rmap locks, which protect against concurrent page table removal by retract_page_tables() in the THP code, are only taken after the PMD entry has been read and it has been decided how to move it. So we can race as follows (with two processes that have mappings of the same tmpfs file that is stored on a tmpfs mount with huge=advise); note that process A accesses page tables through the MM while process B does it through the file rmap: process A process B ========= ========= mremap mremap_to move_vma move_page_tables get_old_pmd alloc_new_pmd *** PREEMPT *** madvise(MADV_COLLAPSE) do_madvise madvise_walk_vmas madvise_vma_behavior madvise_collapse hpage_collapse_scan_file collapse_file retract_page_tables i_mmap_lock_read(mapping) pmdp_collapse_flush i_mmap_unlock_read(mapping) move_pgt_entry(NORMAL_PMD, ...) take_rmap_locks move_normal_pmd drop_rmap_locks When this happens, move_normal_pmd() can end up creating bogus PMD entries in the line `pmd_populate(mm, new_pmd, pmd_pgtable(pmd))`. The effect depends on arch-specific and machine-specific details; on x86, you can end up with physical page 0 mapped as a page table, which is likely exploitable for user->kernel privilege escalation. Fix the race by letting process B recheck that the PMD still points to a page table after the rmap locks have been taken. Otherwise, we bail and let the caller fall back to the PTE-level copying path, which will then bail immediately at the pmd_none() check. Bug reachability: Reaching this bug requires that you can create shmem/file THP mappings - anonymous THP uses different code that doesn't zap stuff under rmap locks. File THP is gated on an experimental config flag (CONFIG_READ_ONLY_THP_FOR_FS), so on normal distro kernels you need shmem THP to hit this bug. As far as I know, getting shmem THP normally requires that you can mount your own tmpfs with the right mount flags, which would require creating your own user+mount namespace; though I don't know if some distros maybe enable shmem THP by default or something like that. Bug impact: This issue can likely be used for user->kernel privilege escalation when it is reachable.", "cve_priority": "medium", "cve_public_date": "2024-10-23 06:15:00 UTC" }, { "cve": "CVE-2024-50202", "url": "https://ubuntu.com/security/CVE-2024-50202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: propagate directory read errors from nilfs_find_entry() Syzbot reported that a task hang occurs in vcs_open() during a fuzzing test for nilfs2. The root cause of this problem is that in nilfs_find_entry(), which searches for directory entries, ignores errors when loading a directory page/folio via nilfs_get_folio() fails. If the filesystem images is corrupted, and the i_size of the directory inode is large, and the directory page/folio is successfully read but fails the sanity check, for example when it is zero-filled, nilfs_check_folio() may continue to spit out error messages in bursts. Fix this issue by propagating the error to the callers when loading a page/folio fails in nilfs_find_entry(). The current interface of nilfs_find_entry() and its callers is outdated and cannot propagate error codes such as -EIO and -ENOMEM returned via nilfs_find_entry(), so fix it together.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50200", "url": "https://ubuntu.com/security/CVE-2024-50200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: maple_tree: correct tree corruption on spanning store Patch series \"maple_tree: correct tree corruption on spanning store\", v3. There has been a nasty yet subtle maple tree corruption bug that appears to have been in existence since the inception of the algorithm. This bug seems far more likely to happen since commit f8d112a4e657 (\"mm/mmap: avoid zeroing vma tree in mmap_region()\"), which is the point at which reports started to be submitted concerning this bug. We were made definitely aware of the bug thanks to the kind efforts of Bert Karwatzki who helped enormously in my being able to track this down and identify the cause of it. The bug arises when an attempt is made to perform a spanning store across two leaf nodes, where the right leaf node is the rightmost child of the shared parent, AND the store completely consumes the right-mode node. This results in mas_wr_spanning_store() mitakenly duplicating the new and existing entries at the maximum pivot within the range, and thus maple tree corruption. The fix patch corrects this by detecting this scenario and disallowing the mistaken duplicate copy. The fix patch commit message goes into great detail as to how this occurs. This series also includes a test which reliably reproduces the issue, and asserts that the fix works correctly. Bert has kindly tested the fix and confirmed it resolved his issues. Also Mikhail Gavrilov kindly reported what appears to be precisely the same bug, which this fix should also resolve. This patch (of 2): There has been a subtle bug present in the maple tree implementation from its inception. This arises from how stores are performed - when a store occurs, it will overwrite overlapping ranges and adjust the tree as necessary to accommodate this. A range may always ultimately span two leaf nodes. In this instance we walk the two leaf nodes, determine which elements are not overwritten to the left and to the right of the start and end of the ranges respectively and then rebalance the tree to contain these entries and the newly inserted one. This kind of store is dubbed a 'spanning store' and is implemented by mas_wr_spanning_store(). In order to reach this stage, mas_store_gfp() invokes mas_wr_preallocate(), mas_wr_store_type() and mas_wr_walk() in turn to walk the tree and update the object (mas) to traverse to the location where the write should be performed, determining its store type. When a spanning store is required, this function returns false stopping at the parent node which contains the target range, and mas_wr_store_type() marks the mas->store_type as wr_spanning_store to denote this fact. When we go to perform the store in mas_wr_spanning_store(), we first determine the elements AFTER the END of the range we wish to store (that is, to the right of the entry to be inserted) - we do this by walking to the NEXT pivot in the tree (i.e. r_mas.last + 1), starting at the node we have just determined contains the range over which we intend to write. We then turn our attention to the entries to the left of the entry we are inserting, whose state is represented by l_mas, and copy these into a 'big node', which is a special node which contains enough slots to contain two leaf node's worth of data. We then copy the entry we wish to store immediately after this - the copy and the insertion of the new entry is performed by mas_store_b_node(). After this we copy the elements to the right of the end of the range which we are inserting, if we have not exceeded the length of the node (i.e. r_mas.offset <= r_mas.end). Herein lies the bug - under very specific circumstances, this logic can break and corrupt the maple tree. Consider the following tree: Height 0 Root Node / \\ pivot = 0xffff / \\ pivot = ULONG_MAX / ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50084", "url": "https://ubuntu.com/security/CVE-2024-50084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: microchip: vcap api: Fix memory leaks in vcap_api_encode_rule_test() Commit a3c1e45156ad (\"net: microchip: vcap: Fix use-after-free error in kunit test\") fixed the use-after-free error, but introduced below memory leaks by removing necessary vcap_free_rule(), add it to fix it. \tunreferenced object 0xffffff80ca58b700 (size 192): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898264 \t hex dump (first 32 bytes): \t 00 12 7a 00 05 00 00 00 0a 00 00 00 64 00 00 00 ..z.........d... \t 00 00 00 00 00 00 00 00 00 04 0b cc 80 ff ff ff ................ \t backtrace (crc 9c09c3fe): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<0000000040a01b8d>] vcap_alloc_rule+0x3cc/0x9c4 \t [<000000003fe86110>] vcap_api_encode_rule_test+0x1ac/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0400 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898265 \t hex dump (first 32 bytes): \t 80 04 0b cc 80 ff ff ff 18 b7 58 ca 80 ff ff ff ..........X..... \t 39 00 00 00 02 00 00 00 06 05 04 03 02 01 ff ff 9............... \t backtrace (crc daf014e9): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<00000000dfdb1e81>] vcap_api_encode_rule_test+0x224/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0700 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898265 \t hex dump (first 32 bytes): \t 80 07 0b cc 80 ff ff ff 28 b7 58 ca 80 ff ff ff ........(.X..... \t 3c 00 00 00 00 00 00 00 01 2f 03 b3 ec ff ff ff <......../...... \t backtrace (crc 8d877792): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000006eadfab7>] vcap_rule_add_action+0x2d0/0x52c \t [<00000000323475d1>] vcap_api_encode_rule_test+0x4d4/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0900 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898266 \t hex dump (first 32 bytes): \t 80 09 0b cc 80 ff ff ff 80 06 0b cc 80 ff ff ff ................ \t 7d 00 00 00 01 00 00 00 00 00 00 00 ff 00 00 00 }............... \t backtrace (crc 34181e56): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<00000000991e3564>] vcap_val_rule+0xcf0/0x13e8 \t [<00000000fc9868e5>] vcap_api_encode_rule_test+0x678/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0980 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898266 \t hex dump (first 32 bytes): \t 18 b7 58 ca 80 ff ff ff 00 09 0b cc 80 ff ff ff ..X............. \t 67 00 00 00 00 00 00 00 01 01 74 88 c0 ff ff ff g.........t..... \t backtrace (crc 275fd9be): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<000000001396a1a2>] test_add_de ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50194", "url": "https://ubuntu.com/security/CVE-2024-50194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Fix uprobes for big-endian kernels The arm64 uprobes code is broken for big-endian kernels as it doesn't convert the in-memory instruction encoding (which is always little-endian) into the kernel's native endianness before analyzing and simulating instructions. This may result in a few distinct problems: * The kernel may may erroneously reject probing an instruction which can safely be probed. * The kernel may erroneously erroneously permit stepping an instruction out-of-line when that instruction cannot be stepped out-of-line safely. * The kernel may erroneously simulate instruction incorrectly dur to interpretting the byte-swapped encoding. The endianness mismatch isn't caught by the compiler or sparse because: * The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so the compiler and sparse have no idea these contain a little-endian 32-bit value. The core uprobes code populates these with a memcpy() which similarly does not handle endianness. * While the uprobe_opcode_t type is an alias for __le32, both arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[] to the similarly-named probe_opcode_t, which is an alias for u32. Hence there is no endianness conversion warning. Fix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and adding the appropriate __le32_to_cpu() conversions prior to consuming the instruction encoding. The core uprobes copies these fields as opaque ranges of bytes, and so is unaffected by this change. At the same time, remove MAX_UINSN_BYTES and consistently use AARCH64_INSN_SIZE for clarity. Tested with the following: | #include | #include | | #define noinline __attribute__((noinline)) | | static noinline void *adrp_self(void) | { | void *addr; | | asm volatile( | \" adrp %x0, adrp_self\\n\" | \" add %x0, %x0, :lo12:adrp_self\\n\" | : \"=r\" (addr)); | } | | | int main(int argc, char *argv) | { | void *ptr = adrp_self(); | bool equal = (ptr == adrp_self); | | printf(\"adrp_self => %p\\n\" | \"adrp_self() => %p\\n\" | \"%s\\n\", | adrp_self, ptr, equal ? \"EQUAL\" : \"NOT EQUAL\"); | | return 0; | } .... where the adrp_self() function was compiled to: | 00000000004007e0 : | 4007e0: 90000000 adrp x0, 400000 <__ehdr_start> | 4007e4: 911f8000 add x0, x0, #0x7e0 | 4007e8: d65f03c0 ret Before this patch, the ADRP is not recognized, and is assumed to be steppable, resulting in corruption of the result: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0xffffffffff7e0 | NOT EQUAL After this patch, the ADRP is correctly recognized and simulated: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50099", "url": "https://ubuntu.com/security/CVE-2024-50099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Remove broken LDR (literal) uprobe support The simulate_ldr_literal() and simulate_ldrsw_literal() functions are unsafe to use for uprobes. Both functions were originally written for use with kprobes, and access memory with plain C accesses. When uprobes was added, these were reused unmodified even though they cannot safely access user memory. There are three key problems: 1) The plain C accesses do not have corresponding extable entries, and thus if they encounter a fault the kernel will treat these as unintentional accesses to user memory, resulting in a BUG() which will kill the kernel thread, and likely lead to further issues (e.g. lockup or panic()). 2) The plain C accesses are subject to HW PAN and SW PAN, and so when either is in use, any attempt to simulate an access to user memory will fault. Thus neither simulate_ldr_literal() nor simulate_ldrsw_literal() can do anything useful when simulating a user instruction on any system with HW PAN or SW PAN. 3) The plain C accesses are privileged, as they run in kernel context, and in practice can access a small range of kernel virtual addresses. The instructions they simulate have a range of +/-1MiB, and since the simulated instructions must itself be a user instructions in the TTBR0 address range, these can address the final 1MiB of the TTBR1 acddress range by wrapping downwards from an address in the first 1MiB of the TTBR0 address range. In contemporary kernels the last 8MiB of TTBR1 address range is reserved, and accesses to this will always fault, meaning this is no worse than (1). Historically, it was theoretically possible for the linear map or vmemmap to spill into the final 8MiB of the TTBR1 address range, but in practice this is extremely unlikely to occur as this would require either: * Having enough physical memory to fill the entire linear map all the way to the final 1MiB of the TTBR1 address range. * Getting unlucky with KASLR randomization of the linear map such that the populated region happens to overlap with the last 1MiB of the TTBR address range. ... and in either case if we were to spill into the final page there would be larger problems as the final page would alias with error pointers. Practically speaking, (1) and (2) are the big issues. Given there have been no reports of problems since the broken code was introduced, it appears that no-one is relying on probing these instructions with uprobes. Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW (literal), limiting the use of simulate_ldr_literal() and simulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR (literal) and LDRSW (literal) will be rejected as arm_probe_decode_insn() will return INSN_REJECTED. In future we can consider introducing working uprobes support for these instructions, but this will require more significant work.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50195", "url": "https://ubuntu.com/security/CVE-2024-50195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-clock: Fix missing timespec64 check in pc_clock_settime() As Andrew pointed out, it will make sense that the PTP core checked timespec64 struct's tv_sec and tv_nsec range before calling ptp->info->settime64(). As the man manual of clock_settime() said, if tp.tv_sec is negative or tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL, which include dynamic clocks which handles PTP clock, and the condition is consistent with timespec64_valid(). As Thomas suggested, timespec64_valid() only check the timespec is valid, but not ensure that the time is in a valid range, so check it ahead using timespec64_valid_strict() in pc_clock_settime() and return -EINVAL if not valid. There are some drivers that use tp->tv_sec and tp->tv_nsec directly to write registers without validity checks and assume that the higher layer has checked it, which is dangerous and will benefit from this, such as hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(), and some drivers can remove the checks of itself.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50085", "url": "https://ubuntu.com/security/CVE-2024-50085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: fix UaF read in mptcp_pm_nl_rm_addr_or_subflow Syzkaller reported this splat: ================================================================== BUG: KASAN: slab-use-after-free in mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881 Read of size 4 at addr ffff8880569ac858 by task syz.1.2799/14662 CPU: 0 UID: 0 PID: 14662 Comm: syz.1.2799 Not tainted 6.12.0-rc2-syzkaller-00307-g36c254515dc6 #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+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881 mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:914 [inline] mptcp_nl_remove_id_zero_address+0x305/0x4a0 net/mptcp/pm_netlink.c:1572 mptcp_pm_nl_del_addr_doit+0x5c9/0x770 net/mptcp/pm_netlink.c:1603 genl_family_rcv_msg_doit+0x202/0x2f0 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x565/0x800 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x165/0x410 net/netlink/af_netlink.c:2551 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1331 [inline] netlink_unicast+0x53c/0x7f0 net/netlink/af_netlink.c:1357 netlink_sendmsg+0x8b8/0xd70 net/netlink/af_netlink.c:1901 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg net/socket.c:744 [inline] ____sys_sendmsg+0x9ae/0xb40 net/socket.c:2607 ___sys_sendmsg+0x135/0x1e0 net/socket.c:2661 __sys_sendmsg+0x117/0x1f0 net/socket.c:2690 do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline] __do_fast_syscall_32+0x73/0x120 arch/x86/entry/common.c:386 do_fast_syscall_32+0x32/0x80 arch/x86/entry/common.c:411 entry_SYSENTER_compat_after_hwframe+0x84/0x8e RIP: 0023:0xf7fe4579 Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00 RSP: 002b:00000000f574556c EFLAGS: 00000296 ORIG_RAX: 0000000000000172 RAX: ffffffffffffffda RBX: 000000000000000b RCX: 0000000020000140 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000296 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Allocated by task 5387: 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 kmalloc_noprof include/linux/slab.h:878 [inline] kzalloc_noprof include/linux/slab.h:1014 [inline] subflow_create_ctx+0x87/0x2a0 net/mptcp/subflow.c:1803 subflow_ulp_init+0xc3/0x4d0 net/mptcp/subflow.c:1956 __tcp_set_ulp net/ipv4/tcp_ulp.c:146 [inline] tcp_set_ulp+0x326/0x7f0 net/ipv4/tcp_ulp.c:167 mptcp_subflow_create_socket+0x4ae/0x10a0 net/mptcp/subflow.c:1764 __mptcp_subflow_connect+0x3cc/0x1490 net/mptcp/subflow.c:1592 mptcp_pm_create_subflow_or_signal_addr+0xbda/0x23a0 net/mptcp/pm_netlink.c:642 mptcp_pm_nl_fully_established net/mptcp/pm_netlink.c:650 [inline] mptcp_pm_nl_work+0x3a1/0x4f0 net/mptcp/pm_netlink.c:943 mptcp_worker+0x15a/0x1240 net/mptcp/protocol.c:2777 process_one_work+0x958/0x1b30 kernel/workqueue.c:3229 process_scheduled_works kernel/workqueue.c:3310 [inline] worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/ke ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50086", "url": "https://ubuntu.com/security/CVE-2024-50086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix user-after-free from session log off There is racy issue between smb2 session log off and smb2 session setup. It will cause user-after-free from session log off. This add session_lock when setting SMB2_SESSION_EXPIRED and referece count to session struct not to free session while it is being used.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50087", "url": "https://ubuntu.com/security/CVE-2024-50087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix uninitialized pointer free on read_alloc_one_name() error The function read_alloc_one_name() does not initialize the name field of the passed fscrypt_str struct if kmalloc fails to allocate the corresponding buffer. Thus, it is not guaranteed that fscrypt_str.name is initialized when freeing it. This is a follow-up to the linked patch that fixes the remaining instances of the bug introduced by commit e43eec81c516 (\"btrfs: use struct qstr instead of name and namelen pairs\").", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50088", "url": "https://ubuntu.com/security/CVE-2024-50088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix uninitialized pointer free in add_inode_ref() The add_inode_ref() function does not initialize the \"name\" struct when it is declared. If any of the following calls to \"read_one_inode() returns NULL, \tdir = read_one_inode(root, parent_objectid); \tif (!dir) { \t\tret = -ENOENT; \t\tgoto out; \t} \tinode = read_one_inode(root, inode_objectid); \tif (!inode) { \t\tret = -EIO; \t\tgoto out; \t} then \"name.name\" would be freed on \"out\" before being initialized. out: \t... \tkfree(name.name); This issue was reported by Coverity with CID 1526744.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50182", "url": "https://ubuntu.com/security/CVE-2024-50182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: secretmem: disable memfd_secret() if arch cannot set direct map Return -ENOSYS from memfd_secret() syscall if !can_set_direct_map(). This is the case for example on some arm64 configurations, where marking 4k PTEs in the direct map not present can only be done if the direct map is set up at 4k granularity in the first place (as ARM's break-before-make semantics do not easily allow breaking apart large/gigantic pages). More precisely, on arm64 systems with !can_set_direct_map(), set_direct_map_invalid_noflush() is a no-op, however it returns success (0) instead of an error. This means that memfd_secret will seemingly \"work\" (e.g. syscall succeeds, you can mmap the fd and fault in pages), but it does not actually achieve its goal of removing its memory from the direct map. Note that with this patch, memfd_secret() will start erroring on systems where can_set_direct_map() returns false (arm64 with CONFIG_RODATA_FULL_DEFAULT_ENABLED=n, CONFIG_DEBUG_PAGEALLOC=n and CONFIG_KFENCE=n), but that still seems better than the current silent failure. Since CONFIG_RODATA_FULL_DEFAULT_ENABLED defaults to 'y', most arm64 systems actually have a working memfd_secret() and aren't be affected. From going through the iterations of the original memfd_secret patch series, it seems that disabling the syscall in these scenarios was the intended behavior [1] (preferred over having set_direct_map_invalid_noflush return an error as that would result in SIGBUSes at page-fault time), however the check for it got dropped between v16 [2] and v17 [3], when secretmem moved away from CMA allocations. [1]: https://lore.kernel.org/lkml/20201124164930.GK8537@kernel.org/ [2]: https://lore.kernel.org/lkml/20210121122723.3446-11-rppt@kernel.org/#t [3]: https://lore.kernel.org/lkml/20201125092208.12544-10-rppt@kernel.org/", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50019", "url": "https://ubuntu.com/security/CVE-2024-50019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kthread: unpark only parked kthread Calling into kthread unparking unconditionally is mostly harmless when the kthread is already unparked. The wake up is then simply ignored because the target is not in TASK_PARKED state. However if the kthread is per CPU, the wake up is preceded by a call to kthread_bind() which expects the task to be inactive and in TASK_PARKED state, which obviously isn't the case if it is unparked. As a result, calling kthread_stop() on an unparked per-cpu kthread triggers such a warning: \tWARNING: CPU: 0 PID: 11 at kernel/kthread.c:525 __kthread_bind_mask kernel/kthread.c:525 \t \t kthread_stop+0x17a/0x630 kernel/kthread.c:707 \t destroy_workqueue+0x136/0xc40 kernel/workqueue.c:5810 \t wg_destruct+0x1e2/0x2e0 drivers/net/wireguard/device.c:257 \t netdev_run_todo+0xe1a/0x1000 net/core/dev.c:10693 \t default_device_exit_batch+0xa14/0xa90 net/core/dev.c:11769 \t ops_exit_list net/core/net_namespace.c:178 [inline] \t cleanup_net+0x89d/0xcc0 net/core/net_namespace.c:640 \t process_one_work kernel/workqueue.c:3231 [inline] \t process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 \t worker_thread+0x86d/0xd70 kernel/workqueue.c:3393 \t kthread+0x2f0/0x390 kernel/kthread.c:389 \t ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 \t ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 \t Fix this with skipping unecessary unparking while stopping a kthread.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50096", "url": "https://ubuntu.com/security/CVE-2024-50096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/dmem: Fix vulnerability in migrate_to_ram upon copy error The `nouveau_dmem_copy_one` function ensures that the copy push command is sent to the device firmware but does not track whether it was executed successfully. In the case of a copy error (e.g., firmware or hardware failure), the copy push command will be sent via the firmware channel, and `nouveau_dmem_copy_one` will likely report success, leading to the `migrate_to_ram` function returning a dirty HIGH_USER page to the user. This can result in a security vulnerability, as a HIGH_USER page that may contain sensitive or corrupted data could be returned to the user. To prevent this vulnerability, we allocate a zero page. Thus, in case of an error, a non-dirty (zero) page will be returned to the user.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50020", "url": "https://ubuntu.com/security/CVE-2024-50020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix improper handling of refcount in ice_sriov_set_msix_vec_count() This patch addresses an issue with improper reference count handling in the ice_sriov_set_msix_vec_count() function. First, the function calls ice_get_vf_by_id(), which increments the reference count of the vf pointer. If the subsequent call to ice_get_vf_vsi() fails, the function currently returns an error without decrementing the reference count of the vf pointer, leading to a reference count leak. The correct behavior, as implemented in this patch, is to decrement the reference count using ice_put_vf(vf) before returning an error when vsi is NULL. Second, the function calls ice_sriov_get_irqs(), which sets vf->first_vector_idx. If this call returns a negative value, indicating an error, the function returns an error without decrementing the reference count of the vf pointer, resulting in another reference count leak. The patch addresses this by adding a call to ice_put_vf(vf) before returning an error when vf->first_vector_idx < 0. This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and identifying potential mismanagement of reference counts. In this case, the tool flagged the missing decrement operation as a potential issue, leading to this patch.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50021", "url": "https://ubuntu.com/security/CVE-2024-50021", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix improper handling of refcount in ice_dpll_init_rclk_pins() This patch addresses a reference count handling issue in the ice_dpll_init_rclk_pins() function. The function calls ice_dpll_get_pins(), which increments the reference count of the relevant resources. However, if the condition WARN_ON((!vsi || !vsi->netdev)) is met, the function currently returns an error without properly releasing the resources acquired by ice_dpll_get_pins(), leading to a reference count leak. To resolve this, the check has been moved to the top of the function. This ensures that the function verifies the state before any resources are acquired, avoiding the need for additional resource management in the error path. This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and detecting potential issues where resources are not properly managed. In this case, the tool flagged the missing release operation as a potential problem, which led to the development of this patch.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50022", "url": "https://ubuntu.com/security/CVE-2024-50022", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: device-dax: correct pgoff align in dax_set_mapping() pgoff should be aligned using ALIGN_DOWN() instead of ALIGN(). Otherwise, vmf->address not aligned to fault_size will be aligned to the next alignment, that can result in memory failure getting the wrong address. It's a subtle situation that only can be observed in page_mapped_in_vma() after the page is page fault handled by dev_dax_huge_fault. Generally, there is little chance to perform page_mapped_in_vma in dev-dax's page unless in specific error injection to the dax device to trigger an MCE - memory-failure. In that case, page_mapped_in_vma() will be triggered to determine which task is accessing the failure address and kill that task in the end. We used self-developed dax device (which is 2M aligned mapping) , to perform error injection to random address. It turned out that error injected to non-2M-aligned address was causing endless MCE until panic. Because page_mapped_in_vma() kept resulting wrong address and the task accessing the failure address was never killed properly: [ 3783.719419] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.049006] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.049190] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.448042] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.448186] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.792026] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.792179] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.162502] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.162633] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.461116] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.461247] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.764730] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.764859] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.042128] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.042259] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.464293] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.464423] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.818090] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.818217] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3787.085297] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3787.085424] Memory failure: 0x200c9742: recovery action for dax page: Recovered It took us several weeks to pinpoint this problem,  but we eventually used bpftrace to trace the page fault and mce address and successfully identified the issue. Joao added: ; Likely we never reproduce in production because we always pin : device-dax regions in the region align they provide (Qemu does : similarly with prealloc in hugetlb/file backed memory). I think this : bug requires that we touch *unpinned* device-dax regions unaligned to : the device-dax selected alignment (page size i.e. 4K/2M/1G)", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50185", "url": "https://ubuntu.com/security/CVE-2024-50185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: handle consistently DSS corruption Bugged peer implementation can send corrupted DSS options, consistently hitting a few warning in the data path. Use DEBUG_NET assertions, to avoid the splat on some builds and handle consistently the error, dumping related MIBs and performing fallback and/or reset according to the subflow type.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50023", "url": "https://ubuntu.com/security/CVE-2024-50023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: Remove LED entry from LEDs list on unregister Commit c938ab4da0eb (\"net: phy: Manual remove LEDs to ensure correct ordering\") correctly fixed a problem with using devm_ but missed removing the LED entry from the LEDs list. This cause kernel panic on specific scenario where the port for the PHY is torn down and up and the kmod for the PHY is removed. On setting the port down the first time, the assosiacted LEDs are correctly unregistered. The associated kmod for the PHY is now removed. The kmod is now added again and the port is now put up, the associated LED are registered again. On putting the port down again for the second time after these step, the LED list now have 4 elements. With the first 2 already unregistered previously and the 2 new one registered again. This cause a kernel panic as the first 2 element should have been removed. Fix this by correctly removing the element when LED is unregistered.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50024", "url": "https://ubuntu.com/security/CVE-2024-50024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: Fix an unsafe loop on the list The kernel may crash when deleting a genetlink family if there are still listeners for that family: Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c000000000c080bc] netlink_update_socket_mc+0x3c/0xc0 LR [c000000000c0f764] __netlink_clear_multicast_users+0x74/0xc0 Call Trace: __netlink_clear_multicast_users+0x74/0xc0 genl_unregister_family+0xd4/0x2d0 Change the unsafe loop on the list to a safe one, because inside the loop there is an element removal from this list.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50186", "url": "https://ubuntu.com/security/CVE-2024-50186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: explicitly clear the sk pointer, when pf->create fails We have recently noticed the exact same KASAN splat as in commit 6cd4a78d962b (\"net: do not leave a dangling sk pointer, when socket creation fails\"). The problem is that commit did not fully address the problem, as some pf->create implementations do not use sk_common_release in their error paths. For example, we can use the same reproducer as in the above commit, but changing ping to arping. arping uses AF_PACKET socket and if packet_create fails, it will just sk_free the allocated sk object. While we could chase all the pf->create implementations and make sure they NULL the freed sk object on error from the socket, we can't guarantee future protocols will not make the same mistake. So it is easier to just explicitly NULL the sk pointer upon return from pf->create in __sock_create. We do know that pf->create always releases the allocated sk object on error, so if the pointer is not NULL, it is definitely dangling.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50025", "url": "https://ubuntu.com/security/CVE-2024-50025", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: fnic: Move flush_work initialization out of if block After commit 379a58caa199 (\"scsi: fnic: Move fnic_fnic_flush_tx() to a work queue\"), it can happen that a work item is sent to an uninitialized work queue. This may has the effect that the item being queued is never actually queued, and any further actions depending on it will not proceed. The following warning is observed while the fnic driver is loaded: kernel: WARNING: CPU: 11 PID: 0 at ../kernel/workqueue.c:1524 __queue_work+0x373/0x410 kernel: kernel: queue_work_on+0x3a/0x50 kernel: fnic_wq_copy_cmpl_handler+0x54a/0x730 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: fnic_isr_msix_wq_copy+0x2d/0x60 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: __handle_irq_event_percpu+0x36/0x1a0 kernel: handle_irq_event_percpu+0x30/0x70 kernel: handle_irq_event+0x34/0x60 kernel: handle_edge_irq+0x7e/0x1a0 kernel: __common_interrupt+0x3b/0xb0 kernel: common_interrupt+0x58/0xa0 kernel: It has been observed that this may break the rediscovery of Fibre Channel devices after a temporary fabric failure. This patch fixes it by moving the work queue initialization out of an if block in fnic_probe().", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50026", "url": "https://ubuntu.com/security/CVE-2024-50026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: wd33c93: Don't use stale scsi_pointer value A regression was introduced with commit dbb2da557a6a (\"scsi: wd33c93: Move the SCSI pointer to private command data\") which results in an oops in wd33c93_intr(). That commit added the scsi_pointer variable and initialized it from hostdata->connected. However, during selection, hostdata->connected is not yet valid. Fix this by getting the current scsi_pointer from hostdata->selecting.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50027", "url": "https://ubuntu.com/security/CVE-2024-50027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: core: Free tzp copy along with the thermal zone The object pointed to by tz->tzp may still be accessed after being freed in thermal_zone_device_unregister(), so move the freeing of it to the point after the removal completion has been completed at which it cannot be accessed any more.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50028", "url": "https://ubuntu.com/security/CVE-2024-50028", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: core: Reference count the zone in thermal_zone_get_by_id() There are places in the thermal netlink code where nothing prevents the thermal zone object from going away while being accessed after it has been returned by thermal_zone_get_by_id(). To address this, make thermal_zone_get_by_id() get a reference on the thermal zone device object to be returned with the help of get_device(), under thermal_list_lock, and adjust all of its callers to this change with the help of the cleanup.h infrastructure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50029", "url": "https://ubuntu.com/security/CVE-2024-50029", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_conn: Fix UAF in hci_enhanced_setup_sync This checks if the ACL connection remains valid as it could be destroyed while hci_enhanced_setup_sync is pending on cmd_sync leading to the following trace: BUG: KASAN: slab-use-after-free in hci_enhanced_setup_sync+0x91b/0xa60 Read of size 1 at addr ffff888002328ffd by task kworker/u5:2/37 CPU: 0 UID: 0 PID: 37 Comm: kworker/u5:2 Not tainted 6.11.0-rc6-01300-g810be445d8d6 #7099 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Workqueue: hci0 hci_cmd_sync_work Call Trace: dump_stack_lvl+0x5d/0x80 ? hci_enhanced_setup_sync+0x91b/0xa60 print_report+0x152/0x4c0 ? hci_enhanced_setup_sync+0x91b/0xa60 ? __virt_addr_valid+0x1fa/0x420 ? hci_enhanced_setup_sync+0x91b/0xa60 kasan_report+0xda/0x1b0 ? hci_enhanced_setup_sync+0x91b/0xa60 hci_enhanced_setup_sync+0x91b/0xa60 ? __pfx_hci_enhanced_setup_sync+0x10/0x10 ? __pfx___mutex_lock+0x10/0x10 hci_cmd_sync_work+0x1c2/0x330 process_one_work+0x7d9/0x1360 ? __pfx_lock_acquire+0x10/0x10 ? __pfx_process_one_work+0x10/0x10 ? assign_work+0x167/0x240 worker_thread+0x5b7/0xf60 ? __kthread_parkme+0xac/0x1c0 ? __pfx_worker_thread+0x10/0x10 ? __pfx_worker_thread+0x10/0x10 kthread+0x293/0x360 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2f/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 34: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __hci_conn_add+0x187/0x17d0 hci_connect_sco+0x2e1/0xb90 sco_sock_connect+0x2a2/0xb80 __sys_connect+0x227/0x2a0 __x64_sys_connect+0x6d/0xb0 do_syscall_64+0x71/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 37: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x101/0x160 kfree+0xd0/0x250 device_release+0x9a/0x210 kobject_put+0x151/0x280 hci_conn_del+0x448/0xbf0 hci_abort_conn_sync+0x46f/0x980 hci_cmd_sync_work+0x1c2/0x330 process_one_work+0x7d9/0x1360 worker_thread+0x5b7/0xf60 kthread+0x293/0x360 ret_from_fork+0x2f/0x70 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50030", "url": "https://ubuntu.com/security/CVE-2024-50030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/ct: prevent UAF in send_recv() Ensure we serialize with completion side to prevent UAF with fence going out of scope on the stack, since we have no clue if it will fire after the timeout before we can erase from the xa. Also we have some dependent loads and stores for which we need the correct ordering, and we lack the needed barriers. Fix this by grabbing the ct->lock after the wait, which is also held by the completion side. v2 (Badal): - Also print done after acquiring the lock and seeing timeout. (cherry picked from commit 52789ce35c55ccd30c4b67b9cc5b2af55e0122ea)", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50187", "url": "https://ubuntu.com/security/CVE-2024-50187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Stop the active perfmon before being destroyed Upon closing the file descriptor, the active performance monitor is not stopped. Although all perfmons are destroyed in `vc4_perfmon_close_file()`, the active performance monitor's pointer (`vc4->active_perfmon`) is still retained. If we open a new file descriptor and submit a few jobs with performance monitors, the driver will attempt to stop the active performance monitor using the stale pointer in `vc4->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50031", "url": "https://ubuntu.com/security/CVE-2024-50031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Stop the active perfmon before being destroyed When running `kmscube` with one or more performance monitors enabled via `GALLIUM_HUD`, the following kernel panic can occur: [ 55.008324] Unable to handle kernel paging request at virtual address 00000000052004a4 [ 55.008368] Mem abort info: [ 55.008377] ESR = 0x0000000096000005 [ 55.008387] EC = 0x25: DABT (current EL), IL = 32 bits [ 55.008402] SET = 0, FnV = 0 [ 55.008412] EA = 0, S1PTW = 0 [ 55.008421] FSC = 0x05: level 1 translation fault [ 55.008434] Data abort info: [ 55.008442] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 55.008455] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 55.008467] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 55.008481] user pgtable: 4k pages, 39-bit VAs, pgdp=00000001046c6000 [ 55.008497] [00000000052004a4] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 55.008525] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP [ 55.008542] Modules linked in: rfcomm [...] vc4 v3d snd_soc_hdmi_codec drm_display_helper gpu_sched drm_shmem_helper cec drm_dma_helper drm_kms_helper i2c_brcmstb drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight [ 55.008799] CPU: 2 PID: 166 Comm: v3d_bin Tainted: G C 6.6.47+rpt-rpi-v8 #1 Debian 1:6.6.47-1+rpt1 [ 55.008824] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [ 55.008838] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 55.008855] pc : __mutex_lock.constprop.0+0x90/0x608 [ 55.008879] lr : __mutex_lock.constprop.0+0x58/0x608 [ 55.008895] sp : ffffffc080673cf0 [ 55.008904] x29: ffffffc080673cf0 x28: 0000000000000000 x27: ffffff8106188a28 [ 55.008926] x26: ffffff8101e78040 x25: ffffff8101baa6c0 x24: ffffffd9d989f148 [ 55.008947] x23: ffffffda1c2a4008 x22: 0000000000000002 x21: ffffffc080673d38 [ 55.008968] x20: ffffff8101238000 x19: ffffff8104f83188 x18: 0000000000000000 [ 55.008988] x17: 0000000000000000 x16: ffffffda1bd04d18 x15: 00000055bb08bc90 [ 55.009715] x14: 0000000000000000 x13: 0000000000000000 x12: ffffffda1bd4cbb0 [ 55.010433] x11: 00000000fa83b2da x10: 0000000000001a40 x9 : ffffffda1bd04d04 [ 55.011162] x8 : ffffff8102097b80 x7 : 0000000000000000 x6 : 00000000030a5857 [ 55.011880] x5 : 00ffffffffffffff x4 : 0300000005200470 x3 : 0300000005200470 [ 55.012598] x2 : ffffff8101238000 x1 : 0000000000000021 x0 : 0300000005200470 [ 55.013292] Call trace: [ 55.013959] __mutex_lock.constprop.0+0x90/0x608 [ 55.014646] __mutex_lock_slowpath+0x1c/0x30 [ 55.015317] mutex_lock+0x50/0x68 [ 55.015961] v3d_perfmon_stop+0x40/0xe0 [v3d] [ 55.016627] v3d_bin_job_run+0x10c/0x2d8 [v3d] [ 55.017282] drm_sched_main+0x178/0x3f8 [gpu_sched] [ 55.017921] kthread+0x11c/0x128 [ 55.018554] ret_from_fork+0x10/0x20 [ 55.019168] Code: f9400260 f1001c1f 54001ea9 927df000 (b9403401) [ 55.019776] ---[ end trace 0000000000000000 ]--- [ 55.020411] note: v3d_bin[166] exited with preempt_count 1 This issue arises because, upon closing the file descriptor (which happens when we interrupt `kmscube`), the active performance monitor is not stopped. Although all perfmons are destroyed in `v3d_perfmon_close_file()`, the active performance monitor's pointer (`v3d->active_perfmon`) is still retained. If `kmscube` is run again, the driver will attempt to stop the active performance monitor using the stale pointer in `v3d->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50189", "url": "https://ubuntu.com/security/CVE-2024-50189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: amd_sfh: Switch to device-managed dmam_alloc_coherent() Using the device-managed version allows to simplify clean-up in probe() error path. Additionally, this device-managed ensures proper cleanup, which helps to resolve memory errors, page faults, btrfs going read-only, and btrfs disk corruption.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50033", "url": "https://ubuntu.com/security/CVE-2024-50033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slip: make slhc_remember() more robust against malicious packets syzbot found that slhc_remember() was missing checks against malicious packets [1]. slhc_remember() only checked the size of the packet was at least 20, which is not good enough. We need to make sure the packet includes the IPv4 and TCP header that are supposed to be carried. Add iph and th pointers to make the code more readable. [1] BUG: KMSAN: uninit-value in slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 ppp_receive_nonmp_frame+0xe45/0x35e0 drivers/net/ppp/ppp_generic.c:2455 ppp_receive_frame drivers/net/ppp/ppp_generic.c:2372 [inline] ppp_do_recv+0x65f/0x40d0 drivers/net/ppp/ppp_generic.c:2212 ppp_input+0x7dc/0xe60 drivers/net/ppp/ppp_generic.c:2327 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 Uninit was created at: slab_post_alloc_hook mm/slub.c:4091 [inline] slab_alloc_node mm/slub.c:4134 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 CPU: 0 UID: 0 PID: 5460 Comm: syz.2.33 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50034", "url": "https://ubuntu.com/security/CVE-2024-50034", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix lacks of icsk_syn_mss with IPPROTO_SMC Eric report a panic on IPPROTO_SMC, and give the facts that when INET_PROTOSW_ICSK was set, icsk->icsk_sync_mss must be set too. Bug: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000086000005 EC = 0x21: IABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault user pgtable: 4k pages, 48-bit VAs, pgdp=00000001195d1000 [0000000000000000] pgd=0800000109c46003, p4d=0800000109c46003, pud=0000000000000000 Internal error: Oops: 0000000086000005 [#1] PREEMPT SMP Modules linked in: CPU: 1 UID: 0 PID: 8037 Comm: syz.3.265 Not tainted 6.11.0-rc7-syzkaller-g5f5673607153 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0x0 lr : cipso_v4_sock_setattr+0x2a8/0x3c0 net/ipv4/cipso_ipv4.c:1910 sp : ffff80009b887a90 x29: ffff80009b887aa0 x28: ffff80008db94050 x27: 0000000000000000 x26: 1fffe0001aa6f5b3 x25: dfff800000000000 x24: ffff0000db75da00 x23: 0000000000000000 x22: ffff0000d8b78518 x21: 0000000000000000 x20: ffff0000d537ad80 x19: ffff0000d8b78000 x18: 1fffe000366d79ee x17: ffff8000800614a8 x16: ffff800080569b84 x15: 0000000000000001 x14: 000000008b336894 x13: 00000000cd96feaa x12: 0000000000000003 x11: 0000000000040000 x10: 00000000000020a3 x9 : 1fffe0001b16f0f1 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 000000000000003f x5 : 0000000000000040 x4 : 0000000000000001 x3 : 0000000000000000 x2 : 0000000000000002 x1 : 0000000000000000 x0 : ffff0000d8b78000 Call trace: 0x0 netlbl_sock_setattr+0x2e4/0x338 net/netlabel/netlabel_kapi.c:1000 smack_netlbl_add+0xa4/0x154 security/smack/smack_lsm.c:2593 smack_socket_post_create+0xa8/0x14c security/smack/smack_lsm.c:2973 security_socket_post_create+0x94/0xd4 security/security.c:4425 __sock_create+0x4c8/0x884 net/socket.c:1587 sock_create net/socket.c:1622 [inline] __sys_socket_create net/socket.c:1659 [inline] __sys_socket+0x134/0x340 net/socket.c:1706 __do_sys_socket net/socket.c:1720 [inline] __se_sys_socket net/socket.c:1718 [inline] __arm64_sys_socket+0x7c/0x94 net/socket.c:1718 __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:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 Code: ???????? ???????? ???????? ???????? (????????) ---[ end trace 0000000000000000 ]--- This patch add a toy implementation that performs a simple return to prevent such panic. This is because MSS can be set in sock_create_kern or smc_setsockopt, similar to how it's done in AF_SMC. However, for AF_SMC, there is currently no way to synchronize MSS within __sys_connect_file. This toy implementation lays the groundwork for us to support such feature for IPPROTO_SMC in the future.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50035", "url": "https://ubuntu.com/security/CVE-2024-50035", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: fix ppp_async_encode() illegal access syzbot reported an issue in ppp_async_encode() [1] In this case, pppoe_sendmsg() is called with a zero size. Then ppp_async_encode() is called with an empty skb. BUG: KMSAN: uninit-value in ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] BUG: KMSAN: uninit-value in ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_send+0x130/0x1b0 drivers/net/ppp/ppp_async.c:634 ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2280 [inline] ppp_input+0x1f1/0xe60 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 Uninit was created at: slab_post_alloc_hook mm/slub.c:4092 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4187 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 CPU: 1 UID: 0 PID: 5411 Comm: syz.1.14 Not tainted 6.12.0-rc1-syzkaller-00165-g360c1f1f24c6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50036", "url": "https://ubuntu.com/security/CVE-2024-50036", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: do not delay dst_entries_add() in dst_release() dst_entries_add() uses per-cpu data that might be freed at netns dismantle from ip6_route_net_exit() calling dst_entries_destroy() Before ip6_route_net_exit() can be called, we release all the dsts associated with this netns, via calls to dst_release(), which waits an rcu grace period before calling dst_destroy() dst_entries_add() use in dst_destroy() is racy, because dst_entries_destroy() could have been called already. Decrementing the number of dsts must happen sooner. Notes: 1) in CONFIG_XFRM case, dst_destroy() can call dst_release_immediate(child), this might also cause UAF if the child does not have DST_NOCOUNT set. IPSEC maintainers might take a look and see how to address this. 2) There is also discussion about removing this count of dst, which might happen in future kernels.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50037", "url": "https://ubuntu.com/security/CVE-2024-50037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/fbdev-dma: Only cleanup deferred I/O if necessary Commit 5a498d4d06d6 (\"drm/fbdev-dma: Only install deferred I/O if necessary\") initializes deferred I/O only if it is used. drm_fbdev_dma_fb_destroy() however calls fb_deferred_io_cleanup() unconditionally with struct fb_info.fbdefio == NULL. KASAN with the out-of-tree Apple silicon display driver posts following warning from __flush_work() of a random struct work_struct instead of the expected NULL pointer derefs. [ 22.053799] ------------[ cut here ]------------ [ 22.054832] WARNING: CPU: 2 PID: 1 at kernel/workqueue.c:4177 __flush_work+0x4d8/0x580 [ 22.056597] Modules linked in: uhid bnep uinput nls_ascii ip6_tables ip_tables i2c_dev loop fuse dm_multipath nfnetlink zram hid_magicmouse btrfs xor xor_neon brcmfmac_wcc raid6_pq hci_bcm4377 bluetooth brcmfmac hid_apple brcmutil nvmem_spmi_mfd simple_mfd_spmi dockchannel_hid cfg80211 joydev regmap_spmi nvme_apple ecdh_generic ecc macsmc_hid rfkill dwc3 appledrm snd_soc_macaudio macsmc_power nvme_core apple_isp phy_apple_atc apple_sart apple_rtkit_helper apple_dockchannel tps6598x macsmc_hwmon snd_soc_cs42l84 videobuf2_v4l2 spmi_apple_controller nvmem_apple_efuses videobuf2_dma_sg apple_z2 videobuf2_memops spi_nor panel_summit videobuf2_common asahi videodev pwm_apple apple_dcp snd_soc_apple_mca apple_admac spi_apple clk_apple_nco i2c_pasemi_platform snd_pcm_dmaengine mc i2c_pasemi_core mux_core ofpart adpdrm drm_dma_helper apple_dart apple_soc_cpufreq leds_pwm phram [ 22.073768] CPU: 2 UID: 0 PID: 1 Comm: systemd-shutdow Not tainted 6.11.2-asahi+ #asahi-dev [ 22.075612] Hardware name: Apple MacBook Pro (13-inch, M2, 2022) (DT) [ 22.077032] pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 22.078567] pc : __flush_work+0x4d8/0x580 [ 22.079471] lr : __flush_work+0x54/0x580 [ 22.080345] sp : ffffc000836ef820 [ 22.081089] x29: ffffc000836ef880 x28: 0000000000000000 x27: ffff80002ddb7128 [ 22.082678] x26: dfffc00000000000 x25: 1ffff000096f0c57 x24: ffffc00082d3e358 [ 22.084263] x23: ffff80004b7862b8 x22: dfffc00000000000 x21: ffff80005aa1d470 [ 22.085855] x20: ffff80004b786000 x19: ffff80004b7862a0 x18: 0000000000000000 [ 22.087439] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000005 [ 22.089030] x14: 1ffff800106ddf0a x13: 0000000000000000 x12: 0000000000000000 [ 22.090618] x11: ffffb800106ddf0f x10: dfffc00000000000 x9 : 1ffff800106ddf0e [ 22.092206] x8 : 0000000000000000 x7 : aaaaaaaaaaaaaaaa x6 : 0000000000000001 [ 22.093790] x5 : ffffc000836ef728 x4 : 0000000000000000 x3 : 0000000000000020 [ 22.095368] x2 : 0000000000000008 x1 : 00000000000000aa x0 : 0000000000000000 [ 22.096955] Call trace: [ 22.097505] __flush_work+0x4d8/0x580 [ 22.098330] flush_delayed_work+0x80/0xb8 [ 22.099231] fb_deferred_io_cleanup+0x3c/0x130 [ 22.100217] drm_fbdev_dma_fb_destroy+0x6c/0xe0 [drm_dma_helper] [ 22.101559] unregister_framebuffer+0x210/0x2f0 [ 22.102575] drm_fb_helper_unregister_info+0x48/0x60 [ 22.103683] drm_fbdev_dma_client_unregister+0x4c/0x80 [drm_dma_helper] [ 22.105147] drm_client_dev_unregister+0x1cc/0x230 [ 22.106217] drm_dev_unregister+0x58/0x570 [ 22.107125] apple_drm_unbind+0x50/0x98 [appledrm] [ 22.108199] component_del+0x1f8/0x3a8 [ 22.109042] dcp_platform_shutdown+0x24/0x38 [apple_dcp] [ 22.110357] platform_shutdown+0x70/0x90 [ 22.111219] device_shutdown+0x368/0x4d8 [ 22.112095] kernel_restart+0x6c/0x1d0 [ 22.112946] __arm64_sys_reboot+0x1c8/0x328 [ 22.113868] invoke_syscall+0x78/0x1a8 [ 22.114703] do_el0_svc+0x124/0x1a0 [ 22.115498] el0_svc+0x3c/0xe0 [ 22.116181] el0t_64_sync_handler+0x70/0xc0 [ 22.117110] el0t_64_sync+0x190/0x198 [ 22.117931] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50092", "url": "https://ubuntu.com/security/CVE-2024-50092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netconsole: fix wrong warning A warning is triggered when there is insufficient space in the buffer for userdata. However, this is not an issue since userdata will be sent in the next iteration. Current warning message: ------------[ cut here ]------------ WARNING: CPU: 13 PID: 3013042 at drivers/net/netconsole.c:1122 write_ext_msg+0x3b6/0x3d0 ? write_ext_msg+0x3b6/0x3d0 console_flush_all+0x1e9/0x330 The code incorrectly issues a warning when this_chunk is zero, which is a valid scenario. The warning should only be triggered when this_chunk is negative.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50038", "url": "https://ubuntu.com/security/CVE-2024-50038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xtables: avoid NFPROTO_UNSPEC where needed syzbot managed to call xt_cluster match via ebtables: WARNING: CPU: 0 PID: 11 at net/netfilter/xt_cluster.c:72 xt_cluster_mt+0x196/0x780 [..] ebt_do_table+0x174b/0x2a40 Module registers to NFPROTO_UNSPEC, but it assumes ipv4/ipv6 packet processing. As this is only useful to restrict locally terminating TCP/UDP traffic, register this for ipv4 and ipv6 family only. Pablo points out that this is a general issue, direct users of the set/getsockopt interface can call into targets/matches that were only intended for use with ip(6)tables. Check all UNSPEC matches and targets for similar issues: - matches and targets are fine except if they assume skb_network_header() is valid -- this is only true when called from inet layer: ip(6) stack pulls the ip/ipv6 header into linear data area. - targets that return XT_CONTINUE or other xtables verdicts must be restricted too, they are incompatbile with the ebtables traverser, e.g. EBT_CONTINUE is a completely different value than XT_CONTINUE. Most matches/targets are changed to register for NFPROTO_IPV4/IPV6, as they are provided for use by ip(6)tables. The MARK target is also used by arptables, so register for NFPROTO_ARP too. While at it, bail out if connbytes fails to enable the corresponding conntrack family. This change passes the selftests in iptables.git.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50039", "url": "https://ubuntu.com/security/CVE-2024-50039", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: accept TCA_STAB only for root qdisc Most qdiscs maintain their backlog using qdisc_pkt_len(skb) on the assumption it is invariant between the enqueue() and dequeue() handlers. Unfortunately syzbot can crash a host rather easily using a TBF + SFQ combination, with an STAB on SFQ [1] We can't support TCA_STAB on arbitrary level, this would require to maintain per-qdisc storage. [1] [ 88.796496] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 88.798611] #PF: supervisor read access in kernel mode [ 88.799014] #PF: error_code(0x0000) - not-present page [ 88.799506] PGD 0 P4D 0 [ 88.799829] Oops: Oops: 0000 [#1] SMP NOPTI [ 88.800569] CPU: 14 UID: 0 PID: 2053 Comm: b371744477 Not tainted 6.12.0-rc1-virtme #1117 [ 88.801107] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 88.801779] RIP: 0010:sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq [ 88.802544] Code: 0f b7 50 12 48 8d 04 d5 00 00 00 00 48 89 d6 48 29 d0 48 8b 91 c0 01 00 00 48 c1 e0 03 48 01 c2 66 83 7a 1a 00 7e c0 48 8b 3a <4c> 8b 07 4c 89 02 49 89 50 08 48 c7 47 08 00 00 00 00 48 c7 07 00 All code ======== 0:\t0f b7 50 12 \tmovzwl 0x12(%rax),%edx 4:\t48 8d 04 d5 00 00 00 \tlea 0x0(,%rdx,8),%rax b:\t00 c:\t48 89 d6 \tmov %rdx,%rsi f:\t48 29 d0 \tsub %rdx,%rax 12:\t48 8b 91 c0 01 00 00 \tmov 0x1c0(%rcx),%rdx 19:\t48 c1 e0 03 \tshl $0x3,%rax 1d:\t48 01 c2 \tadd %rax,%rdx 20:\t66 83 7a 1a 00 \tcmpw $0x0,0x1a(%rdx) 25:\t7e c0 \tjle 0xffffffffffffffe7 27:\t48 8b 3a \tmov (%rdx),%rdi 2a:*\t4c 8b 07 \tmov (%rdi),%r8\t\t<-- trapping instruction 2d:\t4c 89 02 \tmov %r8,(%rdx) 30:\t49 89 50 08 \tmov %rdx,0x8(%r8) 34:\t48 c7 47 08 00 00 00 \tmovq $0x0,0x8(%rdi) 3b:\t00 3c:\t48 \trex.W 3d:\tc7 \t.byte 0xc7 3e:\t07 \t(bad) \t... Code starting with the faulting instruction =========================================== 0:\t4c 8b 07 \tmov (%rdi),%r8 3:\t4c 89 02 \tmov %r8,(%rdx) 6:\t49 89 50 08 \tmov %rdx,0x8(%r8) a:\t48 c7 47 08 00 00 00 \tmovq $0x0,0x8(%rdi) 11:\t00 12:\t48 \trex.W 13:\tc7 \t.byte 0xc7 14:\t07 \t(bad) \t... [ 88.803721] RSP: 0018:ffff9a1f892b7d58 EFLAGS: 00000206 [ 88.804032] RAX: 0000000000000000 RBX: ffff9a1f8420c800 RCX: ffff9a1f8420c800 [ 88.804560] RDX: ffff9a1f81bc1440 RSI: 0000000000000000 RDI: 0000000000000000 [ 88.805056] RBP: ffffffffc04bb0e0 R08: 0000000000000001 R09: 00000000ff7f9a1f [ 88.805473] R10: 000000000001001b R11: 0000000000009a1f R12: 0000000000000140 [ 88.806194] R13: 0000000000000001 R14: ffff9a1f886df400 R15: ffff9a1f886df4ac [ 88.806734] FS: 00007f445601a740(0000) GS:ffff9a2e7fd80000(0000) knlGS:0000000000000000 [ 88.807225] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 88.807672] CR2: 0000000000000000 CR3: 000000050cc46000 CR4: 00000000000006f0 [ 88.808165] Call Trace: [ 88.808459] [ 88.808710] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434) [ 88.809261] ? page_fault_oops (arch/x86/mm/fault.c:715) [ 88.809561] ? exc_page_fault (./arch/x86/include/asm/irqflags.h:26 ./arch/x86/include/asm/irqflags.h:87 ./arch/x86/include/asm/irqflags.h:147 arch/x86/mm/fault.c:1489 arch/x86/mm/fault.c:1539) [ 88.809806] ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623) [ 88.810074] ? sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq [ 88.810411] sfq_reset (net/sched/sch_sfq.c:525) sch_sfq [ 88.810671] qdisc_reset (./include/linux/skbuff.h:2135 ./include/linux/skbuff.h:2441 ./include/linux/skbuff.h:3304 ./include/linux/skbuff.h:3310 net/sched/sch_g ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50040", "url": "https://ubuntu.com/security/CVE-2024-50040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: igb: Do not bring the device up after non-fatal error Commit 004d25060c78 (\"igb: Fix igb_down hung on surprise removal\") changed igb_io_error_detected() to ignore non-fatal pcie errors in order to avoid hung task that can happen when igb_down() is called multiple times. This caused an issue when processing transient non-fatal errors. igb_io_resume(), which is called after igb_io_error_detected(), assumes that device is brought down by igb_io_error_detected() if the interface is up. This resulted in panic with stacktrace below. [ T3256] igb 0000:09:00.0 haeth0: igb: haeth0 NIC Link is Down [ T292] pcieport 0000:00:1c.5: AER: Uncorrected (Non-Fatal) error received: 0000:09:00.0 [ T292] igb 0000:09:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, (Requester ID) [ T292] igb 0000:09:00.0: device [8086:1537] error status/mask=00004000/00000000 [ T292] igb 0000:09:00.0: [14] CmpltTO [ 200.105524,009][ T292] igb 0000:09:00.0: AER: TLP Header: 00000000 00000000 00000000 00000000 [ T292] pcieport 0000:00:1c.5: AER: broadcast error_detected message [ T292] igb 0000:09:00.0: Non-correctable non-fatal error reported. [ T292] pcieport 0000:00:1c.5: AER: broadcast mmio_enabled message [ T292] pcieport 0000:00:1c.5: AER: broadcast resume message [ T292] ------------[ cut here ]------------ [ T292] kernel BUG at net/core/dev.c:6539! [ T292] invalid opcode: 0000 [#1] PREEMPT SMP [ T292] RIP: 0010:napi_enable+0x37/0x40 [ T292] Call Trace: [ T292] [ T292] ? die+0x33/0x90 [ T292] ? do_trap+0xdc/0x110 [ T292] ? napi_enable+0x37/0x40 [ T292] ? do_error_trap+0x70/0xb0 [ T292] ? napi_enable+0x37/0x40 [ T292] ? napi_enable+0x37/0x40 [ T292] ? exc_invalid_op+0x4e/0x70 [ T292] ? napi_enable+0x37/0x40 [ T292] ? asm_exc_invalid_op+0x16/0x20 [ T292] ? napi_enable+0x37/0x40 [ T292] igb_up+0x41/0x150 [ T292] igb_io_resume+0x25/0x70 [ T292] report_resume+0x54/0x70 [ T292] ? report_frozen_detected+0x20/0x20 [ T292] pci_walk_bus+0x6c/0x90 [ T292] ? aer_print_port_info+0xa0/0xa0 [ T292] pcie_do_recovery+0x22f/0x380 [ T292] aer_process_err_devices+0x110/0x160 [ T292] aer_isr+0x1c1/0x1e0 [ T292] ? disable_irq_nosync+0x10/0x10 [ T292] irq_thread_fn+0x1a/0x60 [ T292] irq_thread+0xe3/0x1a0 [ T292] ? irq_set_affinity_notifier+0x120/0x120 [ T292] ? irq_affinity_notify+0x100/0x100 [ T292] kthread+0xe2/0x110 [ T292] ? kthread_complete_and_exit+0x20/0x20 [ T292] ret_from_fork+0x2d/0x50 [ T292] ? kthread_complete_and_exit+0x20/0x20 [ T292] ret_from_fork_asm+0x11/0x20 [ T292] To fix this issue igb_io_resume() checks if the interface is running and the device is not down this means igb_io_error_detected() did not bring the device down and there is no need to bring it up.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50041", "url": "https://ubuntu.com/security/CVE-2024-50041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: Fix macvlan leak by synchronizing access to mac_filter_hash This patch addresses a macvlan leak issue in the i40e driver caused by concurrent access to vsi->mac_filter_hash. The leak occurs when multiple threads attempt to modify the mac_filter_hash simultaneously, leading to inconsistent state and potential memory leaks. To fix this, we now wrap the calls to i40e_del_mac_filter() and zeroing vf->default_lan_addr.addr with spin_lock/unlock_bh(&vsi->mac_filter_hash_lock), ensuring atomic operations and preventing concurrent access. Additionally, we add lockdep_assert_held(&vsi->mac_filter_hash_lock) in i40e_add_mac_filter() to help catch similar issues in the future. Reproduction steps: 1. Spawn VFs and configure port vlan on them. 2. Trigger concurrent macvlan operations (e.g., adding and deleting \tportvlan and/or mac filters). 3. Observe the potential memory leak and inconsistent state in the \tmac_filter_hash. This synchronization ensures the integrity of the mac_filter_hash and prevents the described leak.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50042", "url": "https://ubuntu.com/security/CVE-2024-50042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix increasing MSI-X on VF Increasing MSI-X value on a VF leads to invalid memory operations. This is caused by not reallocating some arrays. Reproducer: modprobe ice echo 0 > /sys/bus/pci/devices/$PF_PCI/sriov_drivers_autoprobe echo 1 > /sys/bus/pci/devices/$PF_PCI/sriov_numvfs echo 17 > /sys/bus/pci/devices/$VF0_PCI/sriov_vf_msix_count Default MSI-X is 16, so 17 and above triggers this issue. KASAN reports: BUG: KASAN: slab-out-of-bounds in ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] Read of size 8 at addr ffff8888b937d180 by task bash/28433 (...) Call Trace: (...) ? ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] kasan_report+0xed/0x120 ? ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] ice_vsi_cfg_def+0x3360/0x4770 [ice] ? mutex_unlock+0x83/0xd0 ? __pfx_ice_vsi_cfg_def+0x10/0x10 [ice] ? __pfx_ice_remove_vsi_lkup_fltr+0x10/0x10 [ice] ice_vsi_cfg+0x7f/0x3b0 [ice] ice_vf_reconfig_vsi+0x114/0x210 [ice] ice_sriov_set_msix_vec_count+0x3d0/0x960 [ice] sriov_vf_msix_count_store+0x21c/0x300 (...) Allocated by task 28201: (...) ice_vsi_cfg_def+0x1c8e/0x4770 [ice] ice_vsi_cfg+0x7f/0x3b0 [ice] ice_vsi_setup+0x179/0xa30 [ice] ice_sriov_configure+0xcaa/0x1520 [ice] sriov_numvfs_store+0x212/0x390 (...) To fix it, use ice_vsi_rebuild() instead of ice_vf_reconfig_vsi(). This causes the required arrays to be reallocated taking the new queue count into account (ice_vsi_realloc_stat_arrays()). Set req_txq and req_rxq before ice_vsi_rebuild(), so that realloc uses the newly set queue count. Additionally, ice_vsi_rebuild() does not remove VSI filters (ice_fltr_remove_all()), so ice_vf_init_host_cfg() is no longer necessary.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50093", "url": "https://ubuntu.com/security/CVE-2024-50093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: intel: int340x: processor: Fix warning during module unload The processor_thermal driver uses pcim_device_enable() to enable a PCI device, which means the device will be automatically disabled on driver detach. Thus there is no need to call pci_disable_device() again on it. With recent PCI device resource management improvements, e.g. commit f748a07a0b64 (\"PCI: Remove legacy pcim_release()\"), this problem is exposed and triggers the warining below. [ 224.010735] proc_thermal_pci 0000:00:04.0: disabling already-disabled device [ 224.010747] WARNING: CPU: 8 PID: 4442 at drivers/pci/pci.c:2250 pci_disable_device+0xe5/0x100 ... [ 224.010844] Call Trace: [ 224.010845] [ 224.010847] ? show_regs+0x6d/0x80 [ 224.010851] ? __warn+0x8c/0x140 [ 224.010854] ? pci_disable_device+0xe5/0x100 [ 224.010856] ? report_bug+0x1c9/0x1e0 [ 224.010859] ? handle_bug+0x46/0x80 [ 224.010862] ? exc_invalid_op+0x1d/0x80 [ 224.010863] ? asm_exc_invalid_op+0x1f/0x30 [ 224.010867] ? pci_disable_device+0xe5/0x100 [ 224.010869] ? pci_disable_device+0xe5/0x100 [ 224.010871] ? kfree+0x21a/0x2b0 [ 224.010873] pcim_disable_device+0x20/0x30 [ 224.010875] devm_action_release+0x16/0x20 [ 224.010878] release_nodes+0x47/0xc0 [ 224.010880] devres_release_all+0x9f/0xe0 [ 224.010883] device_unbind_cleanup+0x12/0x80 [ 224.010885] device_release_driver_internal+0x1ca/0x210 [ 224.010887] driver_detach+0x4e/0xa0 [ 224.010889] bus_remove_driver+0x6f/0xf0 [ 224.010890] driver_unregister+0x35/0x60 [ 224.010892] pci_unregister_driver+0x44/0x90 [ 224.010894] proc_thermal_pci_driver_exit+0x14/0x5f0 [processor_thermal_device_pci] ... [ 224.010921] ---[ end trace 0000000000000000 ]--- Remove the excess pci_disable_device() calls. [ rjw: Subject and changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50043", "url": "https://ubuntu.com/security/CVE-2024-50043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix possible badness in FREE_STATEID When multiple FREE_STATEIDs are sent for the same delegation stateid, it can lead to a possible either use-after-free or counter refcount underflow errors. In nfsd4_free_stateid() under the client lock we find a delegation stateid, however the code drops the lock before calling nfs4_put_stid(), that allows another FREE_STATE to find the stateid again. The first one will proceed to then free the stateid which leads to either use-after-free or decrementing already zeroed counter.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50044", "url": "https://ubuntu.com/security/CVE-2024-50044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change rfcomm_sk_state_change attempts to use sock_lock so it must never be called with it locked but rfcomm_sock_ioctl always attempt to lock it causing the following trace: ====================================================== WARNING: possible circular locking dependency detected 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Not tainted ------------------------------------------------------ syz-executor386/5093 is trying to acquire lock: ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1671 [inline] ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73 but task is already holding lock: ffff88807badfd28 (&d->lock){+.+.}-{3:3}, at: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50045", "url": "https://ubuntu.com/security/CVE-2024-50045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: br_netfilter: fix panic with metadata_dst skb Fix a kernel panic in the br_netfilter module when sending untagged traffic via a VxLAN device. This happens during the check for fragmentation in br_nf_dev_queue_xmit. It is dependent on: 1) the br_netfilter module being loaded; 2) net.bridge.bridge-nf-call-iptables set to 1; 3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port; 4) untagged frames with size higher than the VxLAN MTU forwarded/flooded When forwarding the untagged packet to the VxLAN bridge port, before the netfilter hooks are called, br_handle_egress_vlan_tunnel is called and changes the skb_dst to the tunnel dst. The tunnel_dst is a metadata type of dst, i.e., skb_valid_dst(skb) is false, and metadata->dst.dev is NULL. Then in the br_netfilter hooks, in br_nf_dev_queue_xmit, there's a check for frames that needs to be fragmented: frames with higher MTU than the VxLAN device end up calling br_nf_ip_fragment, which in turns call ip_skb_dst_mtu. The ip_dst_mtu tries to use the skb_dst(skb) as if it was a valid dst with valid dst->dev, thus the crash. This case was never supported in the first place, so drop the packet instead. PING 10.0.0.2 (10.0.0.2) from 0.0.0.0 h1-eth0: 2000(2028) bytes of data. [ 176.291791] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000110 [ 176.292101] Mem abort info: [ 176.292184] ESR = 0x0000000096000004 [ 176.292322] EC = 0x25: DABT (current EL), IL = 32 bits [ 176.292530] SET = 0, FnV = 0 [ 176.292709] EA = 0, S1PTW = 0 [ 176.292862] FSC = 0x04: level 0 translation fault [ 176.293013] Data abort info: [ 176.293104] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 176.293488] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 176.293787] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 176.293995] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043ef5000 [ 176.294166] [0000000000000110] pgd=0000000000000000, p4d=0000000000000000 [ 176.294827] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 176.295252] Modules linked in: vxlan ip6_udp_tunnel udp_tunnel veth br_netfilter bridge stp llc ipv6 crct10dif_ce [ 176.295923] CPU: 0 PID: 188 Comm: ping Not tainted 6.8.0-rc3-g5b3fbd61b9d1 #2 [ 176.296314] Hardware name: linux,dummy-virt (DT) [ 176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 176.296808] pc : br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.297382] lr : br_nf_dev_queue_xmit+0x2ac/0x4ec [br_netfilter] [ 176.297636] sp : ffff800080003630 [ 176.297743] x29: ffff800080003630 x28: 0000000000000008 x27: ffff6828c49ad9f8 [ 176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24: 00000000000003e8 [ 176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21: ffff6828c3b16d28 [ 176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18: 0000000000000014 [ 176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15: 0000000095744632 [ 176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12: ffffb7e137926a70 [ 176.299574] x11: 0000000000000001 x10: ffff6828c3f1c898 x9 : 0000000000000000 [ 176.300049] x8 : ffff6828c49bf070 x7 : 0008460f18d5f20e x6 : f20e0100bebafeca [ 176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 : 0000000000000000 [ 176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 : ffff6828c7f918f0 [ 176.300889] Call trace: [ 176.301123] br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.301411] br_nf_post_routing+0x2a8/0x3e4 [br_netfilter] [ 176.301703] nf_hook_slow+0x48/0x124 [ 176.302060] br_forward_finish+0xc8/0xe8 [bridge] [ 176.302371] br_nf_hook_thresh+0x124/0x134 [br_netfilter] [ 176.302605] br_nf_forward_finish+0x118/0x22c [br_netfilter] [ 176.302824] br_nf_forward_ip.part.0+0x264/0x290 [br_netfilter] [ 176.303136] br_nf_forward+0x2b8/0x4e0 [br_netfilter] [ 176.303359] nf_hook_slow+0x48/0x124 [ 176.303 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50094", "url": "https://ubuntu.com/security/CVE-2024-50094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sfc: Don't invoke xdp_do_flush() from netpoll. Yury reported a crash in the sfc driver originated from netpoll_send_udp(). The netconsole sends a message and then netpoll invokes the driver's NAPI function with a budget of zero. It is dedicated to allow driver to free TX resources, that it may have used while sending the packet. In the netpoll case the driver invokes xdp_do_flush() unconditionally, leading to crash because bpf_net_context was never assigned. Invoke xdp_do_flush() only if budget is not zero.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50188", "url": "https://ubuntu.com/security/CVE-2024-50188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: dp83869: fix memory corruption when enabling fiber When configuring the fiber port, the DP83869 PHY driver incorrectly calls linkmode_set_bit() with a bit mask (1 << 10) rather than a bit number (10). This corrupts some other memory location -- in case of arm64 the priv pointer in the same structure. Since the advertising flags are updated from supported at the end of the function the incorrect line isn't needed at all and can be removed.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50046", "url": "https://ubuntu.com/security/CVE-2024-50046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies() On the node of an NFS client, some files saved in the mountpoint of the NFS server were copied to another location of the same NFS server. Accidentally, the nfs42_complete_copies() got a NULL-pointer dereference crash with the following syslog: [232064.838881] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232064.839360] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232066.588183] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 [232066.588586] Mem abort info: [232066.588701] ESR = 0x0000000096000007 [232066.588862] EC = 0x25: DABT (current EL), IL = 32 bits [232066.589084] SET = 0, FnV = 0 [232066.589216] EA = 0, S1PTW = 0 [232066.589340] FSC = 0x07: level 3 translation fault [232066.589559] Data abort info: [232066.589683] ISV = 0, ISS = 0x00000007 [232066.589842] CM = 0, WnR = 0 [232066.589967] user pgtable: 64k pages, 48-bit VAs, pgdp=00002000956ff400 [232066.590231] [0000000000000058] pgd=08001100ae100003, p4d=08001100ae100003, pud=08001100ae100003, pmd=08001100b3c00003, pte=0000000000000000 [232066.590757] Internal error: Oops: 96000007 [#1] SMP [232066.590958] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm vhost_net vhost vhost_iotlb tap tun ipt_rpfilter xt_multiport ip_set_hash_ip ip_set_hash_net xfrm_interface xfrm6_tunnel tunnel4 tunnel6 esp4 ah4 wireguard libcurve25519_generic veth xt_addrtype xt_set nf_conntrack_netlink ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_bitmap_port ip_set_hash_ipport dummy ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs iptable_filter sch_ingress nfnetlink_cttimeout vport_gre ip_gre ip_tunnel gre vport_geneve geneve vport_vxlan vxlan ip6_udp_tunnel udp_tunnel openvswitch nf_conncount dm_round_robin dm_service_time dm_multipath xt_nat xt_MASQUERADE nft_chain_nat nf_nat xt_mark xt_conntrack xt_comment nft_compat nft_counter nf_tables nfnetlink ocfs2 ocfs2_nodemanager ocfs2_stackglue iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_ssif nbd overlay 8021q garp mrp bonding tls rfkill sunrpc ext4 mbcache jbd2 [232066.591052] vfat fat cas_cache cas_disk ses enclosure scsi_transport_sas sg acpi_ipmi ipmi_si ipmi_devintf ipmi_msghandler ip_tables vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio dm_mirror dm_region_hash dm_log dm_mod nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc fuse xfs libcrc32c ast drm_vram_helper qla2xxx drm_kms_helper syscopyarea crct10dif_ce sysfillrect ghash_ce sysimgblt sha2_ce fb_sys_fops cec sha256_arm64 sha1_ce drm_ttm_helper ttm nvme_fc igb sbsa_gwdt nvme_fabrics drm nvme_core i2c_algo_bit i40e scsi_transport_fc megaraid_sas aes_neon_bs [232066.596953] CPU: 6 PID: 4124696 Comm: 10.253.166.125- Kdump: loaded Not tainted 5.15.131-9.cl9_ocfs2.aarch64 #1 [232066.597356] Hardware name: Great Wall .\\x93\\x8e...RF6260 V5/GWMSSE2GL1T, BIOS T656FBE_V3.0.18 2024-01-06 [232066.597721] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [232066.598034] pc : nfs4_reclaim_open_state+0x220/0x800 [nfsv4] [232066.598327] lr : nfs4_reclaim_open_state+0x12c/0x800 [nfsv4] [232066.598595] sp : ffff8000f568fc70 [232066.598731] x29: ffff8000f568fc70 x28: 0000000000001000 x27: ffff21003db33000 [232066.599030] x26: ffff800005521ae0 x25: ffff0100f98fa3f0 x24: 0000000000000001 [232066.599319] x23: ffff800009920008 x22: ffff21003db33040 x21: ffff21003db33050 [232066.599628] x20: ffff410172fe9e40 x19: ffff410172fe9e00 x18: 0000000000000000 [232066.599914] x17: 0000000000000000 x16: 0000000000000004 x15: 0000000000000000 [232066.600195] x14: 0000000000000000 x13: ffff800008e685a8 x12: 00000000eac0c6e6 [232066.600498] x11: 00000000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50190", "url": "https://ubuntu.com/security/CVE-2024-50190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix memleak in ice_init_tx_topology() Fix leak of the FW blob (DDP pkg). Make ice_cfg_tx_topo() const-correct, so ice_init_tx_topology() can avoid copying whole FW blob. Copy just the topology section, and only when needed. Reuse the buffer allocated for the read of the current topology. This was found by kmemleak, with the following trace for each PF: [] kmemdup_noprof+0x1d/0x50 [] ice_init_ddp_config+0x100/0x220 [ice] [] ice_init_dev+0x6f/0x200 [ice] [] ice_init+0x29/0x560 [ice] [] ice_probe+0x21d/0x310 [ice] Constify ice_cfg_tx_topo() @buf parameter. This cascades further down to few more functions.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50180", "url": "https://ubuntu.com/security/CVE-2024-50180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: sisfb: Fix strbuf array overflow The values of the variables xres and yres are placed in strbuf. These variables are obtained from strbuf1. The strbuf1 array contains digit characters and a space if the array contains non-digit characters. Then, when executing sprintf(strbuf, \"%ux%ux8\", xres, yres); more than 16 bytes will be written to strbuf. It is suggested to increase the size of the strbuf array to 24. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06: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": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50048", "url": "https://ubuntu.com/security/CVE-2024-50048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: Fix a NULL pointer dereference issue in fbcon_putcs syzbot has found a NULL pointer dereference bug in fbcon. Here is the simplified C reproducer: struct param { \tuint8_t type; \tstruct tiocl_selection ts; }; int main() { \tstruct fb_con2fbmap con2fb; \tstruct param param; \tint fd = open(\"/dev/fb1\", 0, 0); \tcon2fb.console = 0x19; \tcon2fb.framebuffer = 0; \tioctl(fd, FBIOPUT_CON2FBMAP, &con2fb); \tparam.type = 2; \tparam.ts.xs = 0; param.ts.ys = 0; \tparam.ts.xe = 0; param.ts.ye = 0; \tparam.ts.sel_mode = 0; \tint fd1 = open(\"/dev/tty1\", O_RDWR, 0); \tioctl(fd1, TIOCLINUX, ¶m); \tcon2fb.console = 1; \tcon2fb.framebuffer = 0; \tioctl(fd, FBIOPUT_CON2FBMAP, &con2fb); \treturn 0; } After calling ioctl(fd1, TIOCLINUX, ¶m), the subsequent ioctl(fd, FBIOPUT_CON2FBMAP, &con2fb) causes the kernel to follow a different execution path: set_con2fb_map -> con2fb_init_display -> fbcon_set_disp -> redraw_screen -> hide_cursor -> clear_selection -> highlight -> invert_screen -> do_update_region -> fbcon_putcs -> ops->putcs Since ops->putcs is a NULL pointer, this leads to a kernel panic. To prevent this, we need to call set_blitting_type() within set_con2fb_map() to properly initialize ops->putcs.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50049", "url": "https://ubuntu.com/security/CVE-2024-50049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before dereferencing se [WHAT & HOW] se is null checked previously in the same function, indicating it might be null; therefore, it must be checked when used again. This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50090", "url": "https://ubuntu.com/security/CVE-2024-50090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/oa: Fix overflow in oa batch buffer By default xe_bb_create_job() appends a MI_BATCH_BUFFER_END to batch buffer, this is not a problem if batch buffer is only used once but oa reuses the batch buffer for the same metric and at each call it appends a MI_BATCH_BUFFER_END, printing the warning below and then overflowing. [ 381.072016] ------------[ cut here ]------------ [ 381.072019] xe 0000:00:02.0: [drm] Assertion `bb->len * 4 + bb_prefetch(q->gt) <= size` failed! platform: LUNARLAKE subplatform: 1 graphics: Xe2_LPG / Xe2_HPG 20.04 step B0 media: Xe2_LPM / Xe2_HPM 20.00 step B0 tile: 0 VRAM 0 B GT: 0 type 1 So here checking if batch buffer already have MI_BATCH_BUFFER_END if not append it. v2: - simply fix, suggestion from Ashutosh (cherry picked from commit 9ba0e0f30ca42a98af3689460063edfb6315718a)", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50183", "url": "https://ubuntu.com/security/CVE-2024-50183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV instance Deleting an NPIV instance requires all fabric ndlps to be released before an NPIV's resources can be torn down. Failure to release fabric ndlps beforehand opens kref imbalance race conditions. Fix by forcing the DA_ID to complete synchronously with usage of wait_queue.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50055", "url": "https://ubuntu.com/security/CVE-2024-50055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: driver core: bus: Fix double free in driver API bus_register() For bus_register(), any error which happens after kset_register() will cause that @priv are freed twice, fixed by setting @priv with NULL after the first free.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50091", "url": "https://ubuntu.com/security/CVE-2024-50091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm vdo: don't refer to dedupe_context after releasing it Clear the dedupe_context pointer in a data_vio whenever ownership of the context is lost, so that vdo can't examine it accidentally.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50056", "url": "https://ubuntu.com/security/CVE-2024-50056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: Fix ERR_PTR dereference in uvc_v4l2.c Fix potential dereferencing of ERR_PTR() in find_format_by_pix() and uvc_v4l2_enum_format(). Fix the following smatch errors: drivers/usb/gadget/function/uvc_v4l2.c:124 find_format_by_pix() error: 'fmtdesc' dereferencing possible ERR_PTR() drivers/usb/gadget/function/uvc_v4l2.c:392 uvc_v4l2_enum_format() error: 'fmtdesc' dereferencing possible ERR_PTR() Also, fix similar issue in uvc_v4l2_try_format() for potential dereferencing of ERR_PTR().", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50184", "url": "https://ubuntu.com/security/CVE-2024-50184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_pmem: Check device status before requesting flush If a pmem device is in a bad status, the driver side could wait for host ack forever in virtio_pmem_flush(), causing the system to hang. So add a status check in the beginning of virtio_pmem_flush() to return early if the device is not activated.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50057", "url": "https://ubuntu.com/security/CVE-2024-50057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: tipd: Free IRQ only if it was requested before In polling mode, if no IRQ was requested there is no need to free it. Call devm_free_irq() only if client->irq is set. This fixes the warning caused by the tps6598x module removal: WARNING: CPU: 2 PID: 333 at kernel/irq/devres.c:144 devm_free_irq+0x80/0x8c ... ... Call trace: devm_free_irq+0x80/0x8c tps6598x_remove+0x28/0x88 [tps6598x] i2c_device_remove+0x2c/0x9c device_remove+0x4c/0x80 device_release_driver_internal+0x1cc/0x228 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 i2c_del_driver+0x54/0x64 tps6598x_i2c_driver_exit+0x18/0xc3c [tps6598x] __arm64_sys_delete_module+0x184/0x264 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc8/0xe8 do_el0_svc+0x20/0x2c el0_svc+0x28/0x98 el0t_64_sync_handler+0x13c/0x158 el0t_64_sync+0x190/0x194", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50058", "url": "https://ubuntu.com/security/CVE-2024-50058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: protect uart_port_dtr_rts() in uart_shutdown() too Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part 3) added few uport == NULL checks. It added one to uart_shutdown(), so the commit assumes, uport can be NULL in there. But right after that protection, there is an unprotected \"uart_port_dtr_rts(uport, false);\" call. That is invoked only if HUPCL is set, so I assume that is the reason why we do not see lots of these reports. Or it cannot be NULL at this point at all for some reason :P. Until the above is investigated, stay on the safe side and move this dereference to the if too. I got this inconsistency from Coverity under CID 1585130. Thanks.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50181", "url": "https://ubuntu.com/security/CVE-2024-50181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: imx: Remove CLK_SET_PARENT_GATE for DRAM mux for i.MX7D For i.MX7D DRAM related mux clock, the clock source change should ONLY be done done in low level asm code without accessing DRAM, and then calling clk API to sync the HW clock status with clk tree, it should never touch real clock source switch via clk API, so CLK_SET_PARENT_GATE flag should NOT be added, otherwise, DRAM's clock parent will be disabled when DRAM is active, and system will hang.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50059", "url": "https://ubuntu.com/security/CVE-2024-50059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntb: ntb_hw_switchtec: Fix use after free vulnerability in switchtec_ntb_remove due to race condition In the switchtec_ntb_add function, it can call switchtec_ntb_init_sndev function, then &sndev->check_link_status_work is bound with check_link_status_work. switchtec_ntb_link_notification may be called to start the work. If we remove the module which will call switchtec_ntb_remove to make cleanup, it will free sndev through kfree(sndev), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | check_link_status_work switchtec_ntb_remove | kfree(sndev); | | if (sndev->link_force_down) | // use sndev Fix it by ensuring that the work is canceled before proceeding with the cleanup in switchtec_ntb_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50060", "url": "https://ubuntu.com/security/CVE-2024-50060", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring: check if we need to reschedule during overflow flush In terms of normal application usage, this list will always be empty. And if an application does overflow a bit, it'll have a few entries. However, nothing obviously prevents syzbot from running a test case that generates a ton of overflow entries, and then flushing them can take quite a while. Check for needing to reschedule while flushing, and drop our locks and do so if necessary. There's no state to maintain here as overflows always prune from head-of-list, hence it's fine to drop and reacquire the locks at the end of the loop.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50061", "url": "https://ubuntu.com/security/CVE-2024-50061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: cdns: Fix use after free vulnerability in cdns_i3c_master Driver Due to Race Condition In the cdns_i3c_master_probe function, &master->hj_work is bound with cdns_i3c_master_hj. And cdns_i3c_master_interrupt can call cnds_i3c_master_demux_ibis function to start the work. If we remove the module which will call cdns_i3c_master_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | cdns_i3c_master_hj cdns_i3c_master_remove | i3c_master_unregister(&master->base) | device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in cdns_i3c_master_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50062", "url": "https://ubuntu.com/security/CVE-2024-50062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-srv: Avoid null pointer deref during path establishment For RTRS path establishment, RTRS client initiates and completes con_num of connections. After establishing all its connections, the information is exchanged between the client and server through the info_req message. During this exchange, it is essential that all connections have been established, and the state of the RTRS srv path is CONNECTED. So add these sanity checks, to make sure we detect and abort process in error scenarios to avoid null pointer deref.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50095", "url": "https://ubuntu.com/security/CVE-2024-50095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mad: Improve handling of timed out WRs of mad agent Current timeout handler of mad agent acquires/releases mad_agent_priv lock for every timed out WRs. This causes heavy locking contention when higher no. of WRs are to be handled inside timeout handler. This leads to softlockup with below trace in some use cases where rdma-cm path is used to establish connection between peer nodes Trace: ----- BUG: soft lockup - CPU#4 stuck for 26s! [kworker/u128:3:19767] CPU: 4 PID: 19767 Comm: kworker/u128:3 Kdump: loaded Tainted: G OE ------- --- 5.14.0-427.13.1.el9_4.x86_64 #1 Hardware name: Dell Inc. PowerEdge R740/01YM03, BIOS 2.4.8 11/26/2019 Workqueue: ib_mad1 timeout_sends [ib_core] RIP: 0010:__do_softirq+0x78/0x2ac RSP: 0018:ffffb253449e4f98 EFLAGS: 00000246 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 000000000000001f RDX: 000000000000001d RSI: 000000003d1879ab RDI: fff363b66fd3a86b RBP: ffffb253604cbcd8 R08: 0000009065635f3b R09: 0000000000000000 R10: 0000000000000040 R11: ffffb253449e4ff8 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000040 FS: 0000000000000000(0000) GS:ffff8caa1fc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd9ec9db900 CR3: 0000000891934006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? __irq_exit_rcu+0xa1/0xc0 ? watchdog_timer_fn+0x1b2/0x210 ? __pfx_watchdog_timer_fn+0x10/0x10 ? __hrtimer_run_queues+0x127/0x2c0 ? hrtimer_interrupt+0xfc/0x210 ? __sysvec_apic_timer_interrupt+0x5c/0x110 ? sysvec_apic_timer_interrupt+0x37/0x90 ? asm_sysvec_apic_timer_interrupt+0x16/0x20 ? __do_softirq+0x78/0x2ac ? __do_softirq+0x60/0x2ac __irq_exit_rcu+0xa1/0xc0 sysvec_call_function_single+0x72/0x90 asm_sysvec_call_function_single+0x16/0x20 RIP: 0010:_raw_spin_unlock_irq+0x14/0x30 RSP: 0018:ffffb253604cbd88 EFLAGS: 00000247 RAX: 000000000001960d RBX: 0000000000000002 RCX: ffff8cad2a064800 RDX: 000000008020001b RSI: 0000000000000001 RDI: ffff8cad5d39f66c RBP: ffff8cad5d39f600 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8caa443e0c00 R11: ffffb253604cbcd8 R12: ffff8cacb8682538 R13: 0000000000000005 R14: ffffb253604cbd90 R15: ffff8cad5d39f66c cm_process_send_error+0x122/0x1d0 [ib_cm] timeout_sends+0x1dd/0x270 [ib_core] process_one_work+0x1e2/0x3b0 ? __pfx_worker_thread+0x10/0x10 worker_thread+0x50/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xdd/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x50 Simplified timeout handler by creating local list of timed out WRs and invoke send handler post creating the list. The new method acquires/ releases lock once to fetch the list and hence helps to reduce locking contetiong when processing higher no. of WRs", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50063", "url": "https://ubuntu.com/security/CVE-2024-50063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Prevent tail call between progs attached to different hooks bpf progs can be attached to kernel functions, and the attached functions can take different parameters or return different return values. If prog attached to one kernel function tail calls prog attached to another kernel function, the ctx access or return value verification could be bypassed. For example, if prog1 is attached to func1 which takes only 1 parameter and prog2 is attached to func2 which takes two parameters. Since verifier assumes the bpf ctx passed to prog2 is constructed based on func2's prototype, verifier allows prog2 to access the second parameter from the bpf ctx passed to it. The problem is that verifier does not prevent prog1 from passing its bpf ctx to prog2 via tail call. In this case, the bpf ctx passed to prog2 is constructed from func1 instead of func2, that is, the assumption for ctx access verification is bypassed. Another example, if BPF LSM prog1 is attached to hook file_alloc_security, and BPF LSM prog2 is attached to hook bpf_lsm_audit_rule_known. Verifier knows the return value rules for these two hooks, e.g. it is legal for bpf_lsm_audit_rule_known to return positive number 1, and it is illegal for file_alloc_security to return positive number. So verifier allows prog2 to return positive number 1, but does not allow prog1 to return positive number. The problem is that verifier does not prevent prog1 from calling prog2 via tail call. In this case, prog2's return value 1 will be used as the return value for prog1's hook file_alloc_security. That is, the return value rule is bypassed. This patch adds restriction for tail call to prevent such bypasses.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50191", "url": "https://ubuntu.com/security/CVE-2024-50191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: don't set SB_RDONLY after filesystem errors When the filesystem is mounted with errors=remount-ro, we were setting SB_RDONLY flag to stop all filesystem modifications. We knew this misses proper locking (sb->s_umount) and does not go through proper filesystem remount procedure but it has been the way this worked since early ext2 days and it was good enough for catastrophic situation damage mitigation. Recently, syzbot has found a way (see link) to trigger warnings in filesystem freezing because the code got confused by SB_RDONLY changing under its hands. Since these days we set EXT4_FLAGS_SHUTDOWN on the superblock which is enough to stop all filesystem modifications, modifying SB_RDONLY shouldn't be needed. So stop doing that.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50064", "url": "https://ubuntu.com/security/CVE-2024-50064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: zram: free secondary algorithms names We need to kfree() secondary algorithms names when reset zram device that had multi-streams, otherwise we leak memory. [senozhatsky@chromium.org: kfree(NULL) is legal] Link: https://lkml.kernel.org/r/20240917013021.868769-1-senozhatsky@chromium.org", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50065", "url": "https://ubuntu.com/security/CVE-2024-50065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Change to non-blocking allocation in ntfs_d_hash d_hash is done while under \"rcu-walk\" and should not sleep. __get_name() allocates using GFP_KERNEL, having the possibility to sleep when under memory pressure. Change the allocation to GFP_NOWAIT.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50089", "url": "https://ubuntu.com/security/CVE-2024-50089", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-49863", "url": "https://ubuntu.com/security/CVE-2024-49863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost/scsi: null-ptr-dereference in vhost_scsi_get_req() Since commit 3f8ca2e115e5 (\"vhost/scsi: Extract common handling code from control queue handler\") a null pointer dereference bug can be triggered when guest sends an SCSI AN request. In vhost_scsi_ctl_handle_vq(), `vc.target` is assigned with `&v_req.tmf.lun[1]` within a switch-case block and is then passed to vhost_scsi_get_req() which extracts `vc->req` and `tpg`. However, for a `VIRTIO_SCSI_T_AN_*` request, tpg is not required, so `vc.target` is set to NULL in this branch. Later, in vhost_scsi_get_req(), `vc->target` is dereferenced without being checked, leading to a null pointer dereference bug. This bug can be triggered from guest. When this bug occurs, the vhost_worker process is killed while holding `vq->mutex` and the corresponding tpg will remain occupied indefinitely. Below is the KASAN report: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 PID: 840 Comm: poc Not tainted 6.10.0+ #1 Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:vhost_scsi_get_req+0x165/0x3a0 Code: 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 02 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 65 30 4c 89 e2 48 c1 ea 03 <0f> b6 04 02 4c 89 e2 83 e2 07 38 d0 7f 08 84 c0 0f 85 be 01 00 00 RSP: 0018:ffff888017affb50 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffff88801b000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888017affcb8 RBP: ffff888017affb80 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff888017affc88 R14: ffff888017affd1c R15: ffff888017993000 FS: 000055556e076500(0000) GS:ffff88806b100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200027c0 CR3: 0000000010ed0004 CR4: 0000000000370ef0 Call Trace: ? show_regs+0x86/0xa0 ? die_addr+0x4b/0xd0 ? exc_general_protection+0x163/0x260 ? asm_exc_general_protection+0x27/0x30 ? vhost_scsi_get_req+0x165/0x3a0 vhost_scsi_ctl_handle_vq+0x2a4/0xca0 ? __pfx_vhost_scsi_ctl_handle_vq+0x10/0x10 ? __switch_to+0x721/0xeb0 ? __schedule+0xda5/0x5710 ? __kasan_check_write+0x14/0x30 ? _raw_spin_lock+0x82/0xf0 vhost_scsi_ctl_handle_kick+0x52/0x90 vhost_run_work_list+0x134/0x1b0 vhost_task_fn+0x121/0x350 ... ---[ end trace 0000000000000000 ]--- Let's add a check in vhost_scsi_get_req. [whitespace fixes]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49864", "url": "https://ubuntu.com/security/CVE-2024-49864", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix a race between socket set up and I/O thread creation In rxrpc_open_socket(), it sets up the socket and then sets up the I/O thread that will handle it. This is a problem, however, as there's a gap between the two phases in which a packet may come into rxrpc_encap_rcv() from the UDP packet but we oops when trying to wake the not-yet created I/O thread. As a quick fix, just make rxrpc_encap_rcv() discard the packet if there's no I/O thread yet. A better, but more intrusive fix would perhaps be to rearrange things such that the socket creation is done by the I/O thread.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49865", "url": "https://ubuntu.com/security/CVE-2024-49865", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: move xa_alloc to prevent UAF Evil user can guess the next id of the vm before the ioctl completes and then call vm destroy ioctl to trigger UAF since create ioctl is still referencing the same vm. Move the xa_alloc all the way to the end to prevent this. v2: - Rebase (cherry picked from commit dcfd3971327f3ee92765154baebbaece833d3ca9)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49955", "url": "https://ubuntu.com/security/CVE-2024-49955", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: battery: Fix possible crash when unregistering a battery hook When a battery hook returns an error when adding a new battery, then the battery hook is automatically unregistered. However the battery hook provider cannot know that, so it will later call battery_hook_unregister() on the already unregistered battery hook, resulting in a crash. Fix this by using the list head to mark already unregistered battery hooks as already being unregistered so that they can be ignored by battery_hook_unregister().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49973", "url": "https://ubuntu.com/security/CVE-2024-49973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: r8169: add tally counter fields added with RTL8125 RTL8125 added fields to the tally counter, what may result in the chip dma'ing these new fields to unallocated memory. Therefore make sure that the allocated memory area is big enough to hold all of the tally counter values, even if we use only parts of it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49974", "url": "https://ubuntu.com/security/CVE-2024-49974", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Limit the number of concurrent async COPY operations Nothing appears to limit the number of concurrent async COPY operations that clients can start. In addition, AFAICT each async COPY can copy an unlimited number of 4MB chunks, so can run for a long time. Thus IMO async COPY can become a DoS vector. Add a restriction mechanism that bounds the number of concurrent background COPY operations. Start simple and try to be fair -- this patch implements a per-namespace limit. An async COPY request that occurs while this limit is exceeded gets NFS4ERR_DELAY. The requesting client can choose to send the request again after a delay or fall back to a traditional read/write style copy. If there is need to make the mechanism more sophisticated, we can visit that in future patches.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49975", "url": "https://ubuntu.com/security/CVE-2024-49975", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uprobes: fix kernel info leak via \"[uprobes]\" vma xol_add_vma() maps the uninitialized page allocated by __create_xol_area() into userspace. On some architectures (x86) this memory is readable even without VM_READ, VM_EXEC results in the same pgprot_t as VM_EXEC|VM_READ, although this doesn't really matter, debugger can read this memory anyway.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50003", "url": "https://ubuntu.com/security/CVE-2024-50003", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix system hang while resume with TBT monitor [Why] Connected with a Thunderbolt monitor and do the suspend and the system may hang while resume. The TBT monitor HPD will be triggered during the resume procedure and call the drm_client_modeset_probe() while struct drm_connector connector->dev->master is NULL. It will mess up the pipe topology after resume. [How] Skip the TBT monitor HPD during the resume procedure because we currently will probe the connectors after resume by default. (cherry picked from commit 453f86a26945207a16b8f66aaed5962dc2b95b85)", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50173", "url": "https://ubuntu.com/security/CVE-2024-50173", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix access to uninitialized variable in tick_ctx_cleanup() The group variable can't be used to retrieve ptdev in our second loop, because it points to the previously iterated list_head, not a valid group. Get the ptdev object from the scheduler instead.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49866", "url": "https://ubuntu.com/security/CVE-2024-49866", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Fix a race during cpuhp processing There is another found exception that the \"timerlat/1\" thread was scheduled on CPU0, and lead to timer corruption finally: ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ``` After tracing the scheduling event, it was discovered that the migration of the \"timerlat/1\" thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() | To fix this, skip online processing if the CPU is already offline.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49976", "url": "https://ubuntu.com/security/CVE-2024-49976", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Drop interface_lock in stop_kthread() stop_kthread() is the offline callback for \"trace/osnoise:online\", since commit 5bfbcd1ee57b (\"tracing/timerlat: Add interface_lock around clearing of kthread in stop_kthread()\"), the following ABBA deadlock scenario is introduced: T1 | T2 [BP] | T3 [AP] osnoise_hotplug_workfn() | work_for_cpu_fn() | cpuhp_thread_fun() | _cpu_down() | osnoise_cpu_die() mutex_lock(&interface_lock) | | stop_kthread() | cpus_write_lock() | mutex_lock(&interface_lock) cpus_read_lock() | cpuhp_kick_ap() | As the interface_lock here in just for protecting the \"kthread\" field of the osn_var, use xchg() instead to fix this issue. Also use for_each_online_cpu() back in stop_per_cpu_kthreads() as it can take cpu_read_lock() again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50005", "url": "https://ubuntu.com/security/CVE-2024-50005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: Fix potential RCU dereference issue in mac802154_scan_worker In the `mac802154_scan_worker` function, the `scan_req->type` field was accessed after the RCU read-side critical section was unlocked. According to RCU usage rules, this is illegal and can lead to unpredictable behavior, such as accessing memory that has been updated or causing use-after-free issues. This possible bug was identified using a static analysis tool developed by myself, specifically designed to detect RCU-related issues. To address this, the `scan_req->type` value is now stored in a local variable `scan_req_type` while still within the RCU read-side critical section. The `scan_req_type` is then used after the RCU lock is released, ensuring that the type value is safely accessed without violating RCU rules.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50012", "url": "https://ubuntu.com/security/CVE-2024-50012", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: Avoid a bad reference count on CPU node In the parse_perf_domain function, if the call to of_parse_phandle_with_args returns an error, then the reference to the CPU device node that was acquired at the start of the function would not be properly decremented. Address this by declaring the variable with the __free(device_node) cleanup attribute.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49867", "url": "https://ubuntu.com/security/CVE-2024-49867", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: wait for fixup workers before stopping cleaner kthread during umount During unmount, at close_ctree(), we have the following steps in this order: 1) Park the cleaner kthread - this doesn't destroy the kthread, it basically halts its execution (wake ups against it work but do nothing); 2) We stop the cleaner kthread - this results in freeing the respective struct task_struct; 3) We call btrfs_stop_all_workers() which waits for any jobs running in all the work queues and then free the work queues. Syzbot reported a case where a fixup worker resulted in a crash when doing a delayed iput on its inode while attempting to wake up the cleaner at btrfs_add_delayed_iput(), because the task_struct of the cleaner kthread was already freed. This can happen during unmount because we don't wait for any fixup workers still running before we call kthread_stop() against the cleaner kthread, which stops and free all its resources. Fix this by waiting for any fixup workers at close_ctree() before we call kthread_stop() against the cleaner and run pending delayed iputs. The stack traces reported by syzbot were the following: BUG: KASAN: slab-use-after-free in __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 Read of size 8 at addr ffff8880272a8a18 by task kworker/u8:3/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.12.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: btrfs-fixup btrfs_work_helper 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 __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline] try_to_wake_up+0xb0/0x1480 kernel/sched/core.c:4154 btrfs_writepage_fixup_worker+0xc16/0xdf0 fs/btrfs/inode.c:2842 btrfs_work_helper+0x390/0xc50 fs/btrfs/async-thread.c:314 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Allocated by task 2: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:319 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345 kasan_slab_alloc include/linux/kasan.h:247 [inline] slab_post_alloc_hook mm/slub.c:4086 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4187 alloc_task_struct_node kernel/fork.c:180 [inline] dup_task_struct+0x57/0x8c0 kernel/fork.c:1107 copy_process+0x5d1/0x3d50 kernel/fork.c:2206 kernel_clone+0x223/0x880 kernel/fork.c:2787 kernel_thread+0x1bc/0x240 kernel/fork.c:2849 create_kthread kernel/kthread.c:412 [inline] kthreadd+0x60d/0x810 kernel/kthread.c:765 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Freed by task 61: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:230 [inline] slab_free_h ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49868", "url": "https://ubuntu.com/security/CVE-2024-49868", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix a NULL pointer dereference when failed to start a new trasacntion [BUG] Syzbot reported a NULL pointer dereference with the following crash: FAULT_INJECTION: forcing a failure. start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676 prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642 relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678 ... BTRFS info (device loop0): balance: ended with status: -12 Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667] RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926 Call Trace: commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496 btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430 del_balance_item fs/btrfs/volumes.c:3678 [inline] reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742 btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574 btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673 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/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [CAUSE] The allocation failure happens at the start_transaction() inside prepare_to_relocate(), and during the error handling we call unset_reloc_control(), which makes fs_info->balance_ctl to be NULL. Then we continue the error path cleanup in btrfs_balance() by calling reset_balance_state() which will call del_balance_item() to fully delete the balance item in the root tree. However during the small window between set_reloc_contrl() and unset_reloc_control(), we can have a subvolume tree update and created a reloc_root for that subvolume. Then we go into the final btrfs_commit_transaction() of del_balance_item(), and into btrfs_update_reloc_root() inside commit_fs_roots(). That function checks if fs_info->reloc_ctl is in the merge_reloc_tree stage, but since fs_info->reloc_ctl is NULL, it results a NULL pointer dereference. [FIX] Just add extra check on fs_info->reloc_ctl inside btrfs_update_reloc_root(), before checking fs_info->reloc_ctl->merge_reloc_tree. That DEAD_RELOC_TREE handling is to prevent further modification to the reloc tree during merge stage, but since there is no reloc_ctl at all, we do not need to bother that.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49869", "url": "https://ubuntu.com/security/CVE-2024-49869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: send: fix buffer overflow detection when copying path to cache entry Starting with commit c0247d289e73 (\"btrfs: send: annotate struct name_cache_entry with __counted_by()\") we annotated the variable length array \"name\" from the name_cache_entry structure with __counted_by() to improve overflow detection. However that alone was not correct, because the length of that array does not match the \"name_len\" field - it matches that plus 1 to include the NUL string terminator, so that makes a fortified kernel think there's an overflow and report a splat like this: strcpy: detected buffer overflow: 20 byte write of buffer size 19 WARNING: CPU: 3 PID: 3310 at __fortify_report+0x45/0x50 CPU: 3 UID: 0 PID: 3310 Comm: btrfs Not tainted 6.11.0-prnet #1 Hardware name: CompuLab Ltd. sbc-ihsw/Intense-PC2 (IPC2), BIOS IPC2_3.330.7 X64 03/15/2018 RIP: 0010:__fortify_report+0x45/0x50 Code: 48 8b 34 (...) RSP: 0018:ffff97ebc0d6f650 EFLAGS: 00010246 RAX: 7749924ef60fa600 RBX: ffff8bf5446a521a RCX: 0000000000000027 RDX: 00000000ffffdfff RSI: ffff97ebc0d6f548 RDI: ffff8bf84e7a1cc8 RBP: ffff8bf548574080 R08: ffffffffa8c40e10 R09: 0000000000005ffd R10: 0000000000000004 R11: ffffffffa8c70e10 R12: ffff8bf551eef400 R13: 0000000000000000 R14: 0000000000000013 R15: 00000000000003a8 FS: 00007fae144de8c0(0000) GS:ffff8bf84e780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fae14691690 CR3: 00000001027a2003 CR4: 00000000001706f0 Call Trace: ? __warn+0x12a/0x1d0 ? __fortify_report+0x45/0x50 ? report_bug+0x154/0x1c0 ? handle_bug+0x42/0x70 ? exc_invalid_op+0x1a/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? __fortify_report+0x45/0x50 __fortify_panic+0x9/0x10 __get_cur_name_and_parent+0x3bc/0x3c0 get_cur_path+0x207/0x3b0 send_extent_data+0x709/0x10d0 ? find_parent_nodes+0x22df/0x25d0 ? mas_nomem+0x13/0x90 ? mtree_insert_range+0xa5/0x110 ? btrfs_lru_cache_store+0x5f/0x1e0 ? iterate_extent_inodes+0x52d/0x5a0 process_extent+0xa96/0x11a0 ? __pfx_lookup_backref_cache+0x10/0x10 ? __pfx_store_backref_cache+0x10/0x10 ? __pfx_iterate_backrefs+0x10/0x10 ? __pfx_check_extent_item+0x10/0x10 changed_cb+0x6fa/0x930 ? tree_advance+0x362/0x390 ? memcmp_extent_buffer+0xd7/0x160 send_subvol+0xf0a/0x1520 btrfs_ioctl_send+0x106b/0x11d0 ? __pfx___clone_root_cmp_sort+0x10/0x10 _btrfs_ioctl_send+0x1ac/0x240 btrfs_ioctl+0x75b/0x850 __se_sys_ioctl+0xca/0x150 do_syscall_64+0x85/0x160 ? __count_memcg_events+0x69/0x100 ? handle_mm_fault+0x1327/0x15c0 ? __se_sys_rt_sigprocmask+0xf1/0x180 ? syscall_exit_to_user_mode+0x75/0xa0 ? do_syscall_64+0x91/0x160 ? do_user_addr_fault+0x21d/0x630 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fae145eeb4f Code: 00 48 89 (...) RSP: 002b:00007ffdf1cb09b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fae145eeb4f RDX: 00007ffdf1cb0ad0 RSI: 0000000040489426 RDI: 0000000000000004 RBP: 00000000000078fe R08: 00007fae144006c0 R09: 00007ffdf1cb0927 R10: 0000000000000008 R11: 0000000000000246 R12: 00007ffdf1cb1ce8 R13: 0000000000000003 R14: 000055c499fab2e0 R15: 0000000000000004 Fix this by not storing the NUL string terminator since we don't actually need it for name cache entries, this way \"name_len\" corresponds to the actual size of the \"name\" array. This requires marking the \"name\" array field with __nonstring and using memcpy() instead of strcpy() as recommended by the guidelines at: https://github.com/KSPP/linux/issues/90", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49870", "url": "https://ubuntu.com/security/CVE-2024-49870", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cachefiles: fix dentry leak in cachefiles_open_file() A dentry leak may be caused when a lookup cookie and a cull are concurrent: P1 | P2 ----------------------------------------------------------- cachefiles_lookup_cookie cachefiles_look_up_object lookup_one_positive_unlocked // get dentry cachefiles_cull inode->i_flags |= S_KERNEL_FILE; cachefiles_open_file cachefiles_mark_inode_in_use __cachefiles_mark_inode_in_use can_use = false if (!(inode->i_flags & S_KERNEL_FILE)) can_use = true \t return false return false // Returns an error but doesn't put dentry After that the following WARNING will be triggered when the backend folder is umounted: ================================================================== BUG: Dentry 000000008ad87947{i=7a,n=Dx_1_1.img} still in use (1) [unmount of ext4 sda] WARNING: CPU: 4 PID: 359261 at fs/dcache.c:1767 umount_check+0x5d/0x70 CPU: 4 PID: 359261 Comm: umount Not tainted 6.6.0-dirty #25 RIP: 0010:umount_check+0x5d/0x70 Call Trace: d_walk+0xda/0x2b0 do_one_tree+0x20/0x40 shrink_dcache_for_umount+0x2c/0x90 generic_shutdown_super+0x20/0x160 kill_block_super+0x1a/0x40 ext4_kill_sb+0x22/0x40 deactivate_locked_super+0x35/0x80 cleanup_mnt+0x104/0x160 ================================================================== Whether cachefiles_open_file() returns true or false, the reference count obtained by lookup_positive_unlocked() in cachefiles_look_up_object() should be released. Therefore release that reference count in cachefiles_look_up_object() to fix the above issue and simplify the code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49871", "url": "https://ubuntu.com/security/CVE-2024-49871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: adp5589-keys - fix NULL pointer dereference We register a devm action to call adp5589_clear_config() and then pass the i2c client as argument so that we can call i2c_get_clientdata() in order to get our device object. However, i2c_set_clientdata() is only being set at the end of the probe function which means that we'll get a NULL pointer dereference in case the probe function fails early.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49872", "url": "https://ubuntu.com/security/CVE-2024-49872", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/gup: fix memfd_pin_folios alloc race panic If memfd_pin_folios tries to create a hugetlb page, but someone else already did, then folio gets the value -EEXIST here: folio = memfd_alloc_folio(memfd, start_idx); if (IS_ERR(folio)) { ret = PTR_ERR(folio); if (ret != -EEXIST) goto err; then on the next trip through the \"while start_idx\" loop we panic here: if (folio) { folio_put(folio); To fix, set the folio to NULL on error.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49964", "url": "https://ubuntu.com/security/CVE-2024-49964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix memfd_pin_folios free_huge_pages leak memfd_pin_folios followed by unpin_folios fails to restore free_huge_pages if the pages were not already faulted in, because the folio refcount for pages created by memfd_alloc_folio never goes to 0. memfd_pin_folios needs another folio_put to undo the folio_try_get below: memfd_alloc_folio() alloc_hugetlb_folio_nodemask() dequeue_hugetlb_folio_nodemask() dequeue_hugetlb_folio_node_exact() folio_ref_unfreeze(folio, 1); ; adds 1 refcount folio_try_get() ; adds 1 refcount hugetlb_add_to_page_cache() ; adds 512 refcount (on x86) With the fix, after memfd_pin_folios + unpin_folios, the refcount for the (unfaulted) page is 512, which is correct, as the refcount for a faulted unpinned page is 513.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49873", "url": "https://ubuntu.com/security/CVE-2024-49873", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/filemap: fix filemap_get_folios_contig THP panic Patch series \"memfd-pin huge page fixes\". Fix multiple bugs that occur when using memfd_pin_folios with hugetlb pages and THP. The hugetlb bugs only bite when the page is not yet faulted in when memfd_pin_folios is called. The THP bug bites when the starting offset passed to memfd_pin_folios is not huge page aligned. See the commit messages for details. This patch (of 5): memfd_pin_folios on memory backed by THP panics if the requested start offset is not huge page aligned: BUG: kernel NULL pointer dereference, address: 0000000000000036 RIP: 0010:filemap_get_folios_contig+0xdf/0x290 RSP: 0018:ffffc9002092fbe8 EFLAGS: 00010202 RAX: 0000000000000002 RBX: 0000000000000002 RCX: 0000000000000002 The fault occurs here, because xas_load returns a folio with value 2: filemap_get_folios_contig() for (folio = xas_load(&xas); folio && xas.xa_index <= end; folio = xas_next(&xas)) { ... if (!folio_try_get(folio)) <-- BOOM \"2\" is an xarray sibling entry. We get it because memfd_pin_folios does not round the indices passed to filemap_get_folios_contig to huge page boundaries for THP, so we load from the middle of a huge page range see a sibling. (It does round for hugetlbfs, at the is_file_hugepages test). To fix, if the folio is a sibling, then return the next index as the starting point for the next call to filemap_get_folios_contig.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49977", "url": "https://ubuntu.com/security/CVE-2024-49977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: Fix zero-division error when disabling tc cbs The commit b8c43360f6e4 (\"net: stmmac: No need to calculate speed divider when offload is disabled\") allows the \"port_transmit_rate_kbps\" to be set to a value of 0, which is then passed to the \"div_s64\" function when tc-cbs is disabled. This leads to a zero-division error. When tc-cbs is disabled, the idleslope, sendslope, and credit values the credit values are not required to be configured. Therefore, adding a return statement after setting the txQ mode to DCB when tc-cbs is disabled would prevent a zero-division error.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49978", "url": "https://ubuntu.com/security/CVE-2024-49978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gso: fix udp gso fraglist segmentation after pull from frag_list Detect gso fraglist skbs with corrupted geometry (see below) and pass these to skb_segment instead of skb_segment_list, as the first can segment them correctly. 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 these skbs, breaking these invariants. In extreme cases they pull all data into skb linear. For UDP, this causes a NULL ptr deref in __udpv4_gso_segment_list_csum at udp_hdr(seg->next)->dest. Detect invalid geometry due to pull, by checking head_skb size. Don't just drop, as this may blackhole a destination. Convert to be able to pass to regular skb_segment.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49979", "url": "https://ubuntu.com/security/CVE-2024-49979", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gso: fix tcp fraglist segmentation after pull from frag_list Detect tcp gso fraglist skbs with corrupted geometry (see below) and pass these to skb_segment instead of skb_segment_list, as the first can segment them correctly. 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 these skbs, breaking these invariants. In extreme cases they pull all data into skb linear. For TCP, this causes a NULL ptr deref in __tcpv4_gso_segment_list_csum at tcp_hdr(seg->next). Detect invalid geometry due to pull, by checking head_skb size. Don't just drop, as this may blackhole a destination. Convert to be able to pass to regular skb_segment. Approach and description based on a patch by Willem de Bruijn.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49980", "url": "https://ubuntu.com/security/CVE-2024-49980", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vrf: revert \"vrf: Remove unnecessary RCU-bh critical section\" This reverts commit 504fc6f4f7f681d2a03aa5f68aad549d90eab853. dev_queue_xmit_nit is expected to be called with BH disabled. __dev_queue_xmit has the following: /* Disable soft irqs for various locks below. Also * stops preemption for RCU. */ rcu_read_lock_bh(); VRF must follow this invariant. The referenced commit removed this protection. Which triggered a lockdep warning: \t================================ \tWARNING: inconsistent lock state \t6.11.0 #1 Tainted: G W \t-------------------------------- \tinconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage. \tbtserver/134819 [HC0[0]:SC0[0]:HE1:SE1] takes: \tffff8882da30c118 (rlock-AF_PACKET){+.?.}-{2:2}, at: tpacket_rcv+0x863/0x3b30 \t{IN-SOFTIRQ-W} state was registered at: \t lock_acquire+0x19a/0x4f0 \t _raw_spin_lock+0x27/0x40 \t packet_rcv+0xa33/0x1320 \t __netif_receive_skb_core.constprop.0+0xcb0/0x3a90 \t __netif_receive_skb_list_core+0x2c9/0x890 \t netif_receive_skb_list_internal+0x610/0xcc0 [...] \tother info that might help us debug this: \t Possible unsafe locking scenario: \t CPU0 \t ---- \t lock(rlock-AF_PACKET); \t \t lock(rlock-AF_PACKET); \t *** DEADLOCK *** \tCall Trace: \t \t dump_stack_lvl+0x73/0xa0 \t mark_lock+0x102e/0x16b0 \t __lock_acquire+0x9ae/0x6170 \t lock_acquire+0x19a/0x4f0 \t _raw_spin_lock+0x27/0x40 \t tpacket_rcv+0x863/0x3b30 \t dev_queue_xmit_nit+0x709/0xa40 \t vrf_finish_direct+0x26e/0x340 [vrf] \t vrf_l3_out+0x5f4/0xe80 [vrf] \t __ip_local_out+0x51e/0x7a0 [...]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49981", "url": "https://ubuntu.com/security/CVE-2024-49981", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: venus: fix use after free bug in venus_remove due to race condition in venus_probe, core->work is bound with venus_sys_error_handler, which is used to handle error. The code use core->sys_err_done to make sync work. The core->work is started in venus_event_notify. If we call venus_remove, there might be an unfished work. The possible sequence is as follows: CPU0 CPU1 |venus_sys_error_handler venus_remove | hfi_destroy\t \t\t | venus_hfi_destroy\t | kfree(hdev);\t | |hfi_reinit \t\t\t\t\t |venus_hfi_queues_reinit |//use hdev Fix it by canceling the work in venus_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49956", "url": "https://ubuntu.com/security/CVE-2024-49956", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: fix double destroy_workqueue error When gfs2_fill_super() fails, destroy_workqueue() is called within gfs2_gl_hash_clear(), and the subsequent code path calls destroy_workqueue() on the same work queue again. This issue can be fixed by setting the work queue pointer to NULL after the first destroy_workqueue() call and checking for a NULL pointer before attempting to destroy the work queue again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50176", "url": "https://ubuntu.com/security/CVE-2024-50176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: k3-r5: Fix error handling when power-up failed By simply bailing out, the driver was violating its rule and internal assumptions that either both or no rproc should be initialized. E.g., this could cause the first core to be available but not the second one, leading to crashes on its shutdown later on while trying to dereference that second instance.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49982", "url": "https://ubuntu.com/security/CVE-2024-49982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: aoe: fix the potential use-after-free problem in more places For fixing CVE-2023-6270, f98364e92662 (\"aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts\") makes tx() calling dev_put() instead of doing in aoecmd_cfg_pkts(). It avoids that the tx() runs into use-after-free. Then Nicolai Stange found more places in aoe have potential use-after-free problem with tx(). e.g. revalidate(), aoecmd_ata_rw(), resend(), probe() and aoecmd_cfg_rsp(). Those functions also use aoenet_xmit() to push packet to tx queue. So they should also use dev_hold() to increase the refcnt of skb->dev. On the other hand, moving dev_put() to tx() causes that the refcnt of skb->dev be reduced to a negative value, because corresponding dev_hold() are not called in revalidate(), aoecmd_ata_rw(), resend(), probe(), and aoecmd_cfg_rsp(). This patch fixed this issue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49874", "url": "https://ubuntu.com/security/CVE-2024-49874", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: svc: Fix use after free vulnerability in svc_i3c_master Driver Due to Race Condition In the svc_i3c_master_probe function, &master->hj_work is bound with svc_i3c_master_hj_work, &master->ibi_work is bound with svc_i3c_master_ibi_work. And svc_i3c_master_ibi_work can start the hj_work, svc_i3c_master_irq_handler can start the ibi_work. If we remove the module which will call svc_i3c_master_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | svc_i3c_master_hj_work svc_i3c_master_remove | i3c_master_unregister(&master->base)| device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in svc_i3c_master_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49875", "url": "https://ubuntu.com/security/CVE-2024-49875", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: map the EBADMSG to nfserr_io to avoid warning Ext4 will throw -EBADMSG through ext4_readdir when a checksum error occurs, resulting in the following WARNING. Fix it by mapping EBADMSG to nfserr_io. nfsd_buffered_readdir iterate_dir // -EBADMSG -74 ext4_readdir // .iterate_shared ext4_dx_readdir ext4_htree_fill_tree htree_dirblock_to_tree ext4_read_dirblock __ext4_read_dirblock ext4_dirblock_csum_verify warn_no_space_for_csum __warn_no_space_for_csum return ERR_PTR(-EFSBADCRC) // -EBADMSG -74 nfserrno // WARNING [ 161.115610] ------------[ cut here ]------------ [ 161.116465] nfsd: non-standard errno: -74 [ 161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0 [ 161.118596] Modules linked in: [ 161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138 [ 161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qe mu.org 04/01/2014 [ 161.123601] RIP: 0010:nfserrno+0x9d/0xd0 [ 161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6 05 ce 2b 61 03 01 e8 99 20 d8 00 <0f> 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33 [ 161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286 [ 161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a [ 161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827 [ 161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021 [ 161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8 [ 161.135244] FS: 0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000 [ 161.136695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0 [ 161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 161.141519] PKRU: 55555554 [ 161.142076] Call Trace: [ 161.142575] ? __warn+0x9b/0x140 [ 161.143229] ? nfserrno+0x9d/0xd0 [ 161.143872] ? report_bug+0x125/0x150 [ 161.144595] ? handle_bug+0x41/0x90 [ 161.145284] ? exc_invalid_op+0x14/0x70 [ 161.146009] ? asm_exc_invalid_op+0x12/0x20 [ 161.146816] ? nfserrno+0x9d/0xd0 [ 161.147487] nfsd_buffered_readdir+0x28b/0x2b0 [ 161.148333] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.149258] ? nfsd_buffered_filldir+0xf0/0xf0 [ 161.150093] ? wait_for_concurrent_writes+0x170/0x170 [ 161.151004] ? generic_file_llseek_size+0x48/0x160 [ 161.151895] nfsd_readdir+0x132/0x190 [ 161.152606] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.153516] ? nfsd_unlink+0x380/0x380 [ 161.154256] ? override_creds+0x45/0x60 [ 161.155006] nfsd4_encode_readdir+0x21a/0x3d0 [ 161.155850] ? nfsd4_encode_readlink+0x210/0x210 [ 161.156731] ? write_bytes_to_xdr_buf+0x97/0xe0 [ 161.157598] ? __write_bytes_to_xdr_buf+0xd0/0xd0 [ 161.158494] ? lock_downgrade+0x90/0x90 [ 161.159232] ? nfs4svc_decode_voidarg+0x10/0x10 [ 161.160092] nfsd4_encode_operation+0x15a/0x440 [ 161.160959] nfsd4_proc_compound+0x718/0xe90 [ 161.161818] nfsd_dispatch+0x18e/0x2c0 [ 161.162586] svc_process_common+0x786/0xc50 [ 161.163403] ? nfsd_svc+0x380/0x380 [ 161.164137] ? svc_printk+0x160/0x160 [ 161.164846] ? svc_xprt_do_enqueue.part.0+0x365/0x380 [ 161.165808] ? nfsd_svc+0x380/0x380 [ 161.166523] ? rcu_is_watching+0x23/0x40 [ 161.167309] svc_process+0x1a5/0x200 [ 161.168019] nfsd+0x1f5/0x380 [ 161.168663] ? nfsd_shutdown_threads+0x260/0x260 [ 161.169554] kthread+0x1c4/0x210 [ 161.170224] ? kthread_insert_work_sanity_check+0x80/0x80 [ 161.171246] ret_from_fork+0x1f/0x30", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50013", "url": "https://ubuntu.com/security/CVE-2024-50013", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix memory leak in exfat_load_bitmap() If the first directory entry in the root directory is not a bitmap directory entry, 'bh' will not be released and reassigned, which will cause a memory leak.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49876", "url": "https://ubuntu.com/security/CVE-2024-49876", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: fix UAF around queue destruction We currently do stuff like queuing the final destruction step on a random system wq, which will outlive the driver instance. With bad timing we can teardown the driver with one or more work workqueue still being alive leading to various UAF splats. Add a fini step to ensure user queues are properly torn down. At this point GuC should already be nuked so queue itself should no longer be referenced from hw pov. v2 (Matt B) - Looks much safer to use a waitqueue and then just wait for the xa_array to become empty before triggering the drain. (cherry picked from commit 861108666cc0e999cffeab6aff17b662e68774e3)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49877", "url": "https://ubuntu.com/security/CVE-2024-49877", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate When doing cleanup, if flags without OCFS2_BH_READAHEAD, it may trigger NULL pointer dereference in the following ocfs2_set_buffer_uptodate() if bh is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49957", "url": "https://ubuntu.com/security/CVE-2024-49957", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix null-ptr-deref when journal load failed. During the mounting process, if journal_reset() fails because of too short journal, then lead to jbd2_journal_load() fails with NULL j_sb_buffer. Subsequently, ocfs2_journal_shutdown() calls jbd2_journal_flush()->jbd2_cleanup_journal_tail()-> __jbd2_update_log_tail()->jbd2_journal_update_sb_log_tail() ->lock_buffer(journal->j_sb_buffer), resulting in a null-pointer dereference error. To resolve this issue, we should check the JBD2_LOADED flag to ensure the journal was properly loaded. Additionally, use journal instead of osb->journal directly to simplify the code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49965", "url": "https://ubuntu.com/security/CVE-2024-49965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove unreasonable unlock in ocfs2_read_blocks Patch series \"Misc fixes for ocfs2_read_blocks\", v5. This series contains 2 fixes for ocfs2_read_blocks(). The first patch fix the issue reported by syzbot, which detects bad unlock balance in ocfs2_read_blocks(). The second patch fixes an issue reported by Heming Zhao when reviewing above fix. This patch (of 2): There was a lock release before exiting, so remove the unreasonable unlock.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49966", "url": "https://ubuntu.com/security/CVE-2024-49966", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: cancel dqi_sync_work before freeing oinfo ocfs2_global_read_info() will initialize and schedule dqi_sync_work at the end, if error occurs after successfully reading global quota, it will trigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled: ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16c This reports that there is an active delayed work when freeing oinfo in error handling, so cancel dqi_sync_work first. BTW, return status instead of -1 when .read_file_info fails.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49958", "url": "https://ubuntu.com/security/CVE-2024-49958", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reserve space for inline xattr before attaching reflink tree One of our customers reported a crash and a corrupted ocfs2 filesystem. The crash was due to the detection of corruption. Upon troubleshooting, the fsck -fn output showed the below corruption [EXTENT_LIST_FREE] Extent list in owner 33080590 claims 230 as the next free chain record, but fsck believes the largest valid value is 227. Clamp the next record value? n The stat output from the debugfs.ocfs2 showed the following corruption where the \"Next Free Rec:\" had overshot the \"Count:\" in the root metadata block. Inode: 33080590 Mode: 0640 Generation: 2619713622 (0x9c25a856) FS Generation: 904309833 (0x35e6ac49) CRC32: 00000000 ECC: 0000 Type: Regular Attr: 0x0 Flags: Valid Dynamic Features: (0x16) HasXattr InlineXattr Refcounted Extended Attributes Block: 0 Extended Attributes Inline Size: 256 User: 0 (root) Group: 0 (root) Size: 281320357888 Links: 1 Clusters: 141738 ctime: 0x66911b56 0x316edcb8 -- Fri Jul 12 06:02:30.829349048 2024 atime: 0x66911d6b 0x7f7a28d -- Fri Jul 12 06:11:23.133669517 2024 mtime: 0x66911b56 0x12ed75d7 -- Fri Jul 12 06:02:30.317552087 2024 dtime: 0x0 -- Wed Dec 31 17:00:00 1969 Refcount Block: 2777346 Last Extblk: 2886943 Orphan Slot: 0 Sub Alloc Slot: 0 Sub Alloc Bit: 14 Tree Depth: 1 Count: 227 Next Free Rec: 230 ## Offset Clusters Block# 0 0 2310 2776351 1 2310 2139 2777375 2 4449 1221 2778399 3 5670 731 2779423 4 6401 566 2780447 ....... .... ....... ....... .... ....... The issue was in the reflink workfow while reserving space for inline xattr. The problematic function is ocfs2_reflink_xattr_inline(). By the time this function is called the reflink tree is already recreated at the destination inode from the source inode. At this point, this function reserves space for inline xattrs at the destination inode without even checking if there is space at the root metadata block. It simply reduces the l_count from 243 to 227 thereby making space of 256 bytes for inline xattr whereas the inode already has extents beyond this index (in this case up to 230), thereby causing corruption. The fix for this is to reserve space for inline metadata at the destination inode before the reflink tree gets recreated. The customer has verified the fix.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49959", "url": "https://ubuntu.com/security/CVE-2024-49959", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail() to recover some journal space. But if an error occurs while executing jbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for free space right away, we try other branches, and if j_committing_transaction is NULL (i.e., the tid is 0), we will get the following complain: ============================================ JBD2: I/O error when updating journal superblock for sdd-8. __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available __jbd2_log_wait_for_space: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Call Trace: add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70 [...] ============================================ So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways. Note that this fix relies on commit 6f6a6fda2945 (\"jbd2: fix ocfs2 corrupt when updating journal superblock fails\") to make jbd2_cleanup_journal_tail return the correct error code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49878", "url": "https://ubuntu.com/security/CVE-2024-49878", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: resource: fix region_intersects() vs add_memory_driver_managed() On a system with CXL memory, the resource tree (/proc/iomem) related to CXL memory may look like something as follows. 490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem) Because drivers/dax/kmem.c calls add_memory_driver_managed() during onlining CXL memory, which makes \"System RAM (kmem)\" a descendant of \"CXL Window X\". This confuses region_intersects(), which expects all \"System RAM\" resources to be at the top level of iomem_resource. This can lead to bugs. For example, when the following command line is executed to write some memory in CXL memory range via /dev/mem, $ dd if=data of=/dev/mem bs=$((1 << 10)) seek=$((0x490000000 >> 10)) count=1 dd: error writing '/dev/mem': Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/s the command fails as expected. However, the error code is wrong. It should be \"Operation not permitted\" instead of \"Bad address\". More seriously, the /dev/mem permission checking in devmem_is_allowed() passes incorrectly. Although the accessing is prevented later because ioremap() isn't allowed to map system RAM, it is a potential security issue. During command executing, the following warning is reported in the kernel log for calling ioremap() on system RAM. ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d Call Trace: memremap+0xcb/0x184 xlate_dev_mem_ptr+0x25/0x2f write_mem+0x94/0xfb vfs_write+0x128/0x26d ksys_write+0xac/0xfe do_syscall_64+0x9a/0xfd entry_SYSCALL_64_after_hwframe+0x4b/0x53 The details of command execution process are as follows. In the above resource tree, \"System RAM\" is a descendant of \"CXL Window 0\" instead of a top level resource. So, region_intersects() will report no System RAM resources in the CXL memory region incorrectly, because it only checks the top level resources. Consequently, devmem_is_allowed() will return 1 (allow access via /dev/mem) for CXL memory region incorrectly. Fortunately, ioremap() doesn't allow to map System RAM and reject the access. So, region_intersects() needs to be fixed to work correctly with the resource tree with \"System RAM\" not at top level as above. To fix it, if we found a unmatched resource in the top level, we will continue to search matched resources in its descendant resources. So, we will not miss any matched resources in resource tree anymore. In the new implementation, an example resource tree |------------- \"CXL Window 0\" ------------| |-- \"System RAM\" --| will behave similar as the following fake resource tree for region_intersects(, IORESOURCE_SYSTEM_RAM, ), |-- \"System RAM\" --||-- \"CXL Window 0a\" --| Where \"CXL Window 0a\" is part of the original \"CXL Window 0\" that isn't covered by \"System RAM\".", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49879", "url": "https://ubuntu.com/security/CVE-2024-49879", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm: omapdrm: Add missing check for alloc_ordered_workqueue As it may return NULL pointer and cause NULL pointer dereference. Add check for the return value of alloc_ordered_workqueue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49880", "url": "https://ubuntu.com/security/CVE-2024-49880", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix off by one issue in alloc_flex_gd() Wesley reported an issue: ================================================================== EXT4-fs (dm-5): resizing filesystem from 7168 to 786432 blocks ------------[ cut here ]------------ kernel BUG at fs/ext4/resize.c:324! CPU: 9 UID: 0 PID: 3576 Comm: resize2fs Not tainted 6.11.0+ #27 RIP: 0010:ext4_resize_fs+0x1212/0x12d0 Call Trace: __ext4_ioctl+0x4e0/0x1800 ext4_ioctl+0x12/0x20 __x64_sys_ioctl+0x99/0xd0 x64_sys_call+0x1206/0x20d0 do_syscall_64+0x72/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e ================================================================== While reviewing the patch, Honza found that when adjusting resize_bg in alloc_flex_gd(), it was possible for flex_gd->resize_bg to be bigger than flexbg_size. The reproduction of the problem requires the following: o_group = flexbg_size * 2 * n; o_size = (o_group + 1) * group_size; n_group: [o_group + flexbg_size, o_group + flexbg_size * 2) o_size = (n_group + 1) * group_size; Take n=0,flexbg_size=16 as an example: last:15 |o---------------|--------------n-| o_group:0 resize to n_group:30 The corresponding reproducer is: img=test.img rm -f $img truncate -s 600M $img mkfs.ext4 -F $img -b 1024 -G 16 8M dev=`losetup -f --show $img` mkdir -p /tmp/test mount $dev /tmp/test resize2fs $dev 248M Delete the problematic plus 1 to fix the issue, and add a WARN_ON_ONCE() to prevent the issue from happening again. [ Note: another reproucer which this commit fixes is: img=test.img rm -f $img truncate -s 25MiB $img mkfs.ext4 -b 4096 -E nodiscard,lazy_itable_init=0,lazy_journal_init=0 $img truncate -s 3GiB $img dev=`losetup -f --show $img` mkdir -p /tmp/test mount $dev /tmp/test resize2fs $dev 3G umount $dev losetup -d $dev -- TYT ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49881", "url": "https://ubuntu.com/security/CVE-2024-49881", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: update orig_path in ext4_find_extent() In ext4_find_extent(), if the path is not big enough, we free it and set *orig_path to NULL. But after reallocating and successfully initializing the path, we don't update *orig_path, in which case the caller gets a valid path but a NULL ppath, and this may cause a NULL pointer dereference or a path memory leak. For example: ext4_split_extent path = *ppath = 2000 ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path = 2000); *orig_path = path = NULL; path = kcalloc() = 3000 ext4_split_extent_at(*ppath = NULL) path = *ppath; ex = path[depth].p_ext; // NULL pointer dereference! ================================================================== BUG: kernel NULL pointer dereference, address: 0000000000000010 CPU: 6 UID: 0 PID: 576 Comm: fsstress Not tainted 6.11.0-rc2-dirty #847 RIP: 0010:ext4_split_extent_at+0x6d/0x560 Call Trace: ext4_split_extent.isra.0+0xcb/0x1b0 ext4_ext_convert_to_initialized+0x168/0x6c0 ext4_ext_handle_unwritten_extents+0x325/0x4d0 ext4_ext_map_blocks+0x520/0xdb0 ext4_map_blocks+0x2b0/0x690 ext4_iomap_begin+0x20e/0x2c0 [...] ================================================================== Therefore, *orig_path is updated when the extent lookup succeeds, so that the caller can safely use path or *ppath.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50014", "url": "https://ubuntu.com/security/CVE-2024-50014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix access to uninitialised lock in fc replay path The following kernel trace can be triggered with fstest generic/629 when executed against a filesystem with fast-commit feature enabled: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x66/0x90 register_lock_class+0x759/0x7d0 __lock_acquire+0x85/0x2630 ? __find_get_block+0xb4/0x380 lock_acquire+0xd1/0x2d0 ? __ext4_journal_get_write_access+0xd5/0x160 _raw_spin_lock+0x33/0x40 ? __ext4_journal_get_write_access+0xd5/0x160 __ext4_journal_get_write_access+0xd5/0x160 ext4_reserve_inode_write+0x61/0xb0 __ext4_mark_inode_dirty+0x79/0x270 ? ext4_ext_replay_set_iblocks+0x2f8/0x450 ext4_ext_replay_set_iblocks+0x330/0x450 ext4_fc_replay+0x14c8/0x1540 ? jread+0x88/0x2e0 ? rcu_is_watching+0x11/0x40 do_one_pass+0x447/0xd00 jbd2_journal_recover+0x139/0x1b0 jbd2_journal_load+0x96/0x390 ext4_load_and_init_journal+0x253/0xd40 ext4_fill_super+0x2cc6/0x3180 ... In the replay path there's an attempt to lock sbi->s_bdev_wb_lock in function ext4_check_bdev_write_error(). Unfortunately, at this point this spinlock has not been initialized yet. Moving it's initialization to an earlier point in __ext4_fill_super() fixes this splat.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49960", "url": "https://ubuntu.com/security/CVE-2024-49960", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix timer use-after-free on failed mount Syzbot has found an ODEBUG bug in ext4_fill_super The del_timer_sync function cancels the s_err_report timer, which reminds about filesystem errors daily. We should guarantee the timer is no longer active before kfree(sbi). When filesystem mounting fails, the flow goes to failed_mount3, where an error occurs when ext4_stop_mmpd is called, causing a read I/O failure. This triggers the ext4_handle_error function that ultimately re-arms the timer, leaving the s_err_report timer active before kfree(sbi) is called. Fix the issue by canceling the s_err_report timer after calling ext4_stop_mmpd.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49882", "url": "https://ubuntu.com/security/CVE-2024-49882", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix double brelse() the buffer of the extents path In ext4_ext_try_to_merge_up(), set path[1].p_bh to NULL after it has been released, otherwise it may be released twice. An example of what triggers this is as follows: split2 map split1 |--------|-------|--------| ext4_ext_map_blocks ext4_ext_handle_unwritten_extents ext4_split_convert_extents // path->p_depth == 0 ext4_split_extent // 1. do split1 ext4_split_extent_at |ext4_ext_insert_extent | ext4_ext_create_new_leaf | ext4_ext_grow_indepth | le16_add_cpu(&neh->eh_depth, 1) | ext4_find_extent | // return -ENOMEM |// get error and try zeroout |path = ext4_find_extent | path->p_depth = 1 |ext4_ext_try_to_merge | ext4_ext_try_to_merge_up | path->p_depth = 0 | brelse(path[1].p_bh) ---> not set to NULL here |// zeroout success // 2. update path ext4_find_extent // 3. do split2 ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth le16_add_cpu(&neh->eh_depth, 1) ext4_find_extent path[0].p_bh = NULL; path->p_depth = 1 read_extent_tree_block ---> return err // path[1].p_bh is still the old value ext4_free_ext_path ext4_ext_drop_refs // path->p_depth == 1 brelse(path[1].p_bh) ---> brelse a buffer twice Finally got the following WARRNING when removing the buffer from lru: ============================================ VFS: brelse: Trying to free free buffer WARNING: CPU: 2 PID: 72 at fs/buffer.c:1241 __brelse+0x58/0x90 CPU: 2 PID: 72 Comm: kworker/u19:1 Not tainted 6.9.0-dirty #716 RIP: 0010:__brelse+0x58/0x90 Call Trace: __find_get_block+0x6e7/0x810 bdev_getblk+0x2b/0x480 __ext4_get_inode_loc+0x48a/0x1240 ext4_get_inode_loc+0xb2/0x150 ext4_reserve_inode_write+0xb7/0x230 __ext4_mark_inode_dirty+0x144/0x6a0 ext4_ext_insert_extent+0x9c8/0x3230 ext4_ext_map_blocks+0xf45/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] ============================================", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49883", "url": "https://ubuntu.com/security/CVE-2024-49883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: aovid use-after-free in ext4_ext_insert_extent() As Ojaswin mentioned in Link, in ext4_ext_insert_extent(), if the path is reallocated in ext4_ext_create_new_leaf(), we'll use the stale path and cause UAF. Below is a sample trace with dummy values: ext4_ext_insert_extent path = *ppath = 2000 ext4_ext_create_new_leaf(ppath) ext4_find_extent(ppath) path = *ppath = 2000 if (depth > path[0].p_maxdepth) kfree(path = 2000); *ppath = path = NULL; path = kcalloc() = 3000 *ppath = 3000; return path; /* here path is still 2000, UAF! */ eh = path[depth].p_hdr ================================================================== BUG: KASAN: slab-use-after-free in ext4_ext_insert_extent+0x26d4/0x3330 Read of size 8 at addr ffff8881027bf7d0 by task kworker/u36:1/179 CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 Not tainted 6.11.0-rc2-dirty #866 Call Trace: ext4_ext_insert_extent+0x26d4/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 [...] Allocated by task 179: ext4_find_extent+0x81c/0x1f70 ext4_ext_map_blocks+0x146/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...] Freed by task 179: kfree+0xcb/0x240 ext4_find_extent+0x7c0/0x1f70 ext4_ext_insert_extent+0xa26/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...] ================================================================== So use *ppath to update the path to avoid the above problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49983", "url": "https://ubuntu.com/security/CVE-2024-49983", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-free When calling ext4_force_split_extent_at() in ext4_ext_replay_update_ex(), the 'ppath' is updated but it is the 'path' that is freed, thus potentially triggering a double-free in the following process: ext4_ext_replay_update_ex ppath = path ext4_force_split_extent_at(&ppath) ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path) ---> path First freed *orig_path = path = NULL ---> null ppath kfree(path) ---> path double-free !!! So drop the unnecessary ppath and use path directly to avoid this problem. And use ext4_find_extent() directly to update path, avoiding unnecessary memory allocation and freeing. Also, propagate the error returned by ext4_find_extent() instead of using strange error codes.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50015", "url": "https://ubuntu.com/security/CVE-2024-50015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: dax: fix overflowing extents beyond inode size when partially writing The dax_iomap_rw() does two things in each iteration: map written blocks and copy user data to blocks. If the process is killed by user(See signal handling in dax_iomap_iter()), the copied data will be returned and added on inode size, which means that the length of written extents may exceed the inode size, then fsck will fail. An example is given as: dd if=/dev/urandom of=file bs=4M count=1 dax_iomap_rw iomap_iter // round 1 ext4_iomap_begin ext4_iomap_alloc // allocate 0~2M extents(written flag) dax_iomap_iter // copy 2M data iomap_iter // round 2 iomap_iter_advance iter->pos += iter->processed // iter->pos = 2M ext4_iomap_begin ext4_iomap_alloc // allocate 2~4M extents(written flag) dax_iomap_iter fatal_signal_pending done = iter->pos - iocb->ki_pos // done = 2M ext4_handle_inode_extension ext4_update_inode_size // inode size = 2M fsck reports: Inode 13, i_size is 2097152, should be 4194304. Fix? Fix the problem by truncating extents if the written length is smaller than expected.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49884", "url": "https://ubuntu.com/security/CVE-2024-49884", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix slab-use-after-free in ext4_split_extent_at() We hit the following use-after-free: ================================================================== BUG: KASAN: slab-use-after-free in ext4_split_extent_at+0xba8/0xcc0 Read of size 2 at addr ffff88810548ed08 by task kworker/u20:0/40 CPU: 0 PID: 40 Comm: kworker/u20:0 Not tainted 6.9.0-dirty #724 Call Trace: kasan_report+0x93/0xc0 ext4_split_extent_at+0xba8/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] Allocated by task 40: __kmalloc_noprof+0x1ac/0x480 ext4_find_extent+0xf3b/0x1e70 ext4_ext_map_blocks+0x188/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] Freed by task 40: kfree+0xf1/0x2b0 ext4_find_extent+0xa71/0x1e70 ext4_ext_insert_extent+0xa22/0x3260 ext4_split_extent_at+0x3ef/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] ================================================================== The flow of issue triggering is as follows: ext4_split_extent_at path = *ppath ext4_ext_insert_extent(ppath) ext4_ext_create_new_leaf(ppath) ext4_find_extent(orig_path) path = *orig_path read_extent_tree_block // return -ENOMEM or -EIO ext4_free_ext_path(path) kfree(path) *orig_path = NULL a. If err is -ENOMEM: ext4_ext_dirty(path + path->p_depth) // path use-after-free !!! b. If err is -EIO and we have EXT_DEBUG defined: ext4_ext_show_leaf(path) eh = path[depth].p_hdr // path also use-after-free !!! So when trying to zeroout or fix the extent length, call ext4_find_extent() to update the path. In addition we use *ppath directly as an ext4_ext_show_leaf() input to avoid possible use-after-free when EXT_DEBUG is defined, and to avoid unnecessary path updates.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49885", "url": "https://ubuntu.com/security/CVE-2024-49885", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm, slub: avoid zeroing kmalloc redzone Since commit 946fa0dbf2d8 (\"mm/slub: extend redzone check to extra allocated kmalloc space than requested\"), setting orig_size treats the wasted space (object_size - orig_size) as a redzone. However with init_on_free=1 we clear the full object->size, including the redzone. Additionally we clear the object metadata, including the stored orig_size, making it zero, which makes check_object() treat the whole object as a redzone. These issues lead to the following BUG report with \"slub_debug=FUZ init_on_free=1\": [ 0.000000] ============================================================================= [ 0.000000] BUG kmalloc-8 (Not tainted): kmalloc Redzone overwritten [ 0.000000] ----------------------------------------------------------------------------- [ 0.000000] [ 0.000000] 0xffff000010032858-0xffff00001003285f @offset=2136. First byte 0x0 instead of 0xcc [ 0.000000] FIX kmalloc-8: Restoring kmalloc Redzone 0xffff000010032858-0xffff00001003285f=0xcc [ 0.000000] Slab 0xfffffdffc0400c80 objects=36 used=23 fp=0xffff000010032a18 flags=0x3fffe0000000200(workingset|node=0|zone=0|lastcpupid=0x1ffff) [ 0.000000] Object 0xffff000010032858 @offset=2136 fp=0xffff0000100328c8 [ 0.000000] [ 0.000000] Redzone ffff000010032850: cc cc cc cc cc cc cc cc ........ [ 0.000000] Object ffff000010032858: cc cc cc cc cc cc cc cc ........ [ 0.000000] Redzone ffff000010032860: cc cc cc cc cc cc cc cc ........ [ 0.000000] Padding ffff0000100328b4: 00 00 00 00 00 00 00 00 00 00 00 00 ............ [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.11.0-rc3-next-20240814-00004-g61844c55c3f4 #144 [ 0.000000] Hardware name: NXP i.MX95 19X19 board (DT) [ 0.000000] Call trace: [ 0.000000] dump_backtrace+0x90/0xe8 [ 0.000000] show_stack+0x18/0x24 [ 0.000000] dump_stack_lvl+0x74/0x8c [ 0.000000] dump_stack+0x18/0x24 [ 0.000000] print_trailer+0x150/0x218 [ 0.000000] check_object+0xe4/0x454 [ 0.000000] free_to_partial_list+0x2f8/0x5ec To address the issue, use orig_size to clear the used area. And restore the value of orig_size after clear the remaining area. When CONFIG_SLUB_DEBUG not defined, (get_orig_size()' directly returns s->object_size. So when using memset to init the area, the size can simply be orig_size, as orig_size returns object_size when CONFIG_SLUB_DEBUG not enabled. And orig_size can never be bigger than object_size.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49961", "url": "https://ubuntu.com/security/CVE-2024-49961", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: ar0521: Use cansleep version of gpiod_set_value() If we use GPIO reset from I2C port expander, we must use *_cansleep() variant of GPIO functions. This was not done in ar0521_power_on()/ar0521_power_off() functions. Let's fix that. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 11 at drivers/gpio/gpiolib.c:3496 gpiod_set_value+0x74/0x7c Modules linked in: CPU: 0 PID: 11 Comm: kworker/u16:0 Not tainted 6.10.0 #53 Hardware name: Diasom DS-RK3568-SOM-EVB (DT) Workqueue: events_unbound deferred_probe_work_func pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : gpiod_set_value+0x74/0x7c lr : ar0521_power_on+0xcc/0x290 sp : ffffff8001d7ab70 x29: ffffff8001d7ab70 x28: ffffff80027dcc90 x27: ffffff8003c82000 x26: ffffff8003ca9250 x25: ffffffc080a39c60 x24: ffffff8003ca9088 x23: ffffff8002402720 x22: ffffff8003ca9080 x21: ffffff8003ca9088 x20: 0000000000000000 x19: ffffff8001eb2a00 x18: ffffff80efeeac80 x17: 756d2d6332692f30 x16: 0000000000000000 x15: 0000000000000000 x14: ffffff8001d91d40 x13: 0000000000000016 x12: ffffffc080e98930 x11: ffffff8001eb2880 x10: 0000000000000890 x9 : ffffff8001d7a9f0 x8 : ffffff8001d92570 x7 : ffffff80efeeac80 x6 : 000000003fc6e780 x5 : ffffff8001d91c80 x4 : 0000000000000002 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000001 Call trace: gpiod_set_value+0x74/0x7c ar0521_power_on+0xcc/0x290 ...", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49985", "url": "https://ubuntu.com/security/CVE-2024-49985", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume In case there is any sort of clock controller attached to this I2C bus controller, for example Versaclock or even an AIC32x4 I2C codec, then an I2C transfer triggered from the clock controller clk_ops .prepare callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex. This is because the clock controller first grabs the prepare_lock mutex and then performs the prepare operation, including its I2C access. The I2C access resumes this I2C bus controller via .runtime_resume callback, which calls clk_prepare_enable(), which attempts to grab the prepare_lock mutex again and deadlocks. Since the clock are already prepared since probe() and unprepared in remove(), use simple clk_enable()/clk_disable() calls to enable and disable the clock on runtime suspend and resume, to avoid hitting the prepare_lock mutex.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49886", "url": "https://ubuntu.com/security/CVE-2024-49886", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bug Attaching SST PCI device to VM causes \"BUG: KASAN: slab-out-of-bounds\". kasan report: [ 19.411889] ================================================================== [ 19.413702] BUG: KASAN: slab-out-of-bounds in _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.415634] Read of size 8 at addr ffff888829e65200 by task cpuhp/16/113 [ 19.417368] [ 19.418627] CPU: 16 PID: 113 Comm: cpuhp/16 Tainted: G E 6.9.0 #10 [ 19.420435] Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.20192059.B64.2207280713 07/28/2022 [ 19.422687] Call Trace: [ 19.424091] [ 19.425448] dump_stack_lvl+0x5d/0x80 [ 19.426963] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.428694] print_report+0x19d/0x52e [ 19.430206] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 19.431837] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.433539] kasan_report+0xf0/0x170 [ 19.435019] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.436709] _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.438379] ? __pfx_sched_clock_cpu+0x10/0x10 [ 19.439910] isst_if_cpu_online+0x406/0x58f [isst_if_common] [ 19.441573] ? __pfx_isst_if_cpu_online+0x10/0x10 [isst_if_common] [ 19.443263] ? ttwu_queue_wakelist+0x2c1/0x360 [ 19.444797] cpuhp_invoke_callback+0x221/0xec0 [ 19.446337] cpuhp_thread_fun+0x21b/0x610 [ 19.447814] ? __pfx_cpuhp_thread_fun+0x10/0x10 [ 19.449354] smpboot_thread_fn+0x2e7/0x6e0 [ 19.450859] ? __pfx_smpboot_thread_fn+0x10/0x10 [ 19.452405] kthread+0x29c/0x350 [ 19.453817] ? __pfx_kthread+0x10/0x10 [ 19.455253] ret_from_fork+0x31/0x70 [ 19.456685] ? __pfx_kthread+0x10/0x10 [ 19.458114] ret_from_fork_asm+0x1a/0x30 [ 19.459573] [ 19.460853] [ 19.462055] Allocated by task 1198: [ 19.463410] kasan_save_stack+0x30/0x50 [ 19.464788] kasan_save_track+0x14/0x30 [ 19.466139] __kasan_kmalloc+0xaa/0xb0 [ 19.467465] __kmalloc+0x1cd/0x470 [ 19.468748] isst_if_cdev_register+0x1da/0x350 [isst_if_common] [ 19.470233] isst_if_mbox_init+0x108/0xff0 [isst_if_mbox_msr] [ 19.471670] do_one_initcall+0xa4/0x380 [ 19.472903] do_init_module+0x238/0x760 [ 19.474105] load_module+0x5239/0x6f00 [ 19.475285] init_module_from_file+0xd1/0x130 [ 19.476506] idempotent_init_module+0x23b/0x650 [ 19.477725] __x64_sys_finit_module+0xbe/0x130 [ 19.476506] idempotent_init_module+0x23b/0x650 [ 19.477725] __x64_sys_finit_module+0xbe/0x130 [ 19.478920] do_syscall_64+0x82/0x160 [ 19.480036] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 19.481292] [ 19.482205] The buggy address belongs to the object at ffff888829e65000 which belongs to the cache kmalloc-512 of size 512 [ 19.484818] The buggy address is located 0 bytes to the right of allocated 512-byte region [ffff888829e65000, ffff888829e65200) [ 19.487447] [ 19.488328] The buggy address belongs to the physical page: [ 19.489569] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888829e60c00 pfn:0x829e60 [ 19.491140] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [ 19.492466] anon flags: 0x57ffffc0000840(slab|head|node=1|zone=2|lastcpupid=0x1fffff) [ 19.493914] page_type: 0xffffffff() [ 19.494988] raw: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [ 19.496451] raw: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [ 19.497906] head: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [ 19.499379] head: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [ 19.500844] head: 0057ffffc0000003 ffffea0020a79801 ffffea0020a79848 00000000ffffffff [ 19.502316] head: 0000000800000000 0000000000000000 00000000ffffffff 0000000000000000 [ 19.503784] page dumped because: k ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49986", "url": "https://ubuntu.com/security/CVE-2024-49986", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: x86-android-tablets: Fix use after free on platform_device_register() errors x86_android_tablet_remove() frees the pdevs[] array, so it should not be used after calling x86_android_tablet_remove(). When platform_device_register() fails, store the pdevs[x] PTR_ERR() value into the local ret variable before calling x86_android_tablet_remove() to avoid using pdevs[] after it has been freed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49887", "url": "https://ubuntu.com/security/CVE-2024-49887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to don't panic system for no free segment fault injection f2fs: fix to don't panic system for no free segment fault injection syzbot reports a f2fs bug as below: F2FS-fs (loop0): inject no free segment in get_new_segment of __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3167 F2FS-fs (loop0): Stopped filesystem due to reason: 7 ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2748! CPU: 0 UID: 0 PID: 5109 Comm: syz-executor304 Not tainted 6.11.0-rc6-syzkaller-00363-g89f5e14d05b4 #0 RIP: 0010:get_new_segment fs/f2fs/segment.c:2748 [inline] RIP: 0010:new_curseg+0x1f61/0x1f70 fs/f2fs/segment.c:2836 Call Trace: __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3167 f2fs_allocate_new_section fs/f2fs/segment.c:3181 [inline] f2fs_allocate_pinning_section+0xfa/0x4e0 fs/f2fs/segment.c:3195 f2fs_expand_inode_data+0x5d6/0xbb0 fs/f2fs/file.c:1799 f2fs_fallocate+0x448/0x960 fs/f2fs/file.c:1903 vfs_fallocate+0x553/0x6c0 fs/open.c:334 do_vfs_ioctl+0x2592/0x2e50 fs/ioctl.c:886 __do_sys_ioctl fs/ioctl.c:905 [inline] __se_sys_ioctl+0x81/0x170 fs/ioctl.c:893 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: 0010:get_new_segment fs/f2fs/segment.c:2748 [inline] RIP: 0010:new_curseg+0x1f61/0x1f70 fs/f2fs/segment.c:2836 The root cause is when we inject no free segment fault into f2fs, we should not panic system, fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49888", "url": "https://ubuntu.com/security/CVE-2024-49888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix a sdiv overflow issue Zac Ecob reported a problem where a bpf program may cause kernel crash due to the following error: Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI The failure is due to the below signed divide: LLONG_MIN/-1 where LLONG_MIN equals to -9,223,372,036,854,775,808. LLONG_MIN/-1 is supposed to give a positive number 9,223,372,036,854,775,808, but it is impossible since for 64-bit system, the maximum positive number is 9,223,372,036,854,775,807. On x86_64, LLONG_MIN/-1 will cause a kernel exception. On arm64, the result for LLONG_MIN/-1 is LLONG_MIN. Further investigation found all the following sdiv/smod cases may trigger an exception when bpf program is running on x86_64 platform: - LLONG_MIN/-1 for 64bit operation - INT_MIN/-1 for 32bit operation - LLONG_MIN%-1 for 64bit operation - INT_MIN%-1 for 32bit operation where -1 can be an immediate or in a register. On arm64, there are no exceptions: - LLONG_MIN/-1 = LLONG_MIN - INT_MIN/-1 = INT_MIN - LLONG_MIN%-1 = 0 - INT_MIN%-1 = 0 where -1 can be an immediate or in a register. Insn patching is needed to handle the above cases and the patched codes produced results aligned with above arm64 result. The below are pseudo codes to handle sdiv/smod exceptions including both divisor -1 and divisor 0 and the divisor is stored in a register. sdiv: tmp = rX tmp += 1 /* [-1, 0] -> [0, 1] if tmp >(unsigned) 1 goto L2 if tmp == 0 goto L1 rY = 0 L1: rY = -rY; goto L3 L2: rY /= rX L3: smod: tmp = rX tmp += 1 /* [-1, 0] -> [0, 1] if tmp >(unsigned) 1 goto L1 if tmp == 1 (is64 ? goto L2 : goto L3) rY = 0; goto L2 L1: rY %= rX L2: goto L4 // only when !is64 L3: wY = wY // only when !is64 L4: [1] https://lore.kernel.org/bpf/tPJLTEh7S_DxFEqAI2Ji5MBSoZVg7_G-Py2iaZpAaWtM961fFTWtsnlzwvTbzBzaUzwQAoNATXKUlt0LZOFgnDcIyKCswAnAGdUF3LBrhGQ=@protonmail.com/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49987", "url": "https://ubuntu.com/security/CVE-2024-49987", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpftool: Fix undefined behavior in qsort(NULL, 0, ...) When netfilter has no entry to display, qsort is called with qsort(NULL, 0, ...). This results in undefined behavior, as UBSan reports: net.c:827:2: runtime error: null pointer passed as argument 1, which is declared to never be null Although the C standard does not explicitly state whether calling qsort with a NULL pointer when the size is 0 constitutes undefined behavior, Section 7.1.4 of the C standard (Use of library functions) mentions: \"Each of the following statements applies unless explicitly stated otherwise in the detailed descriptions that follow: If an argument to a function has an invalid value (such as a value outside the domain of the function, or a pointer outside the address space of the program, or a null pointer, or a pointer to non-modifiable storage when the corresponding parameter is not const-qualified) or a type (after promotion) not expected by a function with variable number of arguments, the behavior is undefined.\" To avoid this, add an early return when nf_link_info is NULL to prevent calling qsort with a NULL pointer.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50006", "url": "https://ubuntu.com/security/CVE-2024-50006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix i_data_sem unlock order in ext4_ind_migrate() Fuzzing reports a possible deadlock in jbd2_log_wait_commit. This issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to require synchronous updates because the file descriptor is opened with O_SYNC. This can lead to the jbd2_journal_stop() function calling jbd2_might_wait_for_commit(), potentially causing a deadlock if the EXT4_IOC_MIGRATE call races with a write(2) system call. This problem only arises when CONFIG_PROVE_LOCKING is enabled. In this case, the jbd2_might_wait_for_commit macro locks jbd2_handle in the jbd2_journal_stop function while i_data_sem is locked. This triggers lockdep because the jbd2_journal_start function might also lock the same jbd2_handle simultaneously. Found by Linux Verification Center (linuxtesting.org) with syzkaller. Rule: add", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49889", "url": "https://ubuntu.com/security/CVE-2024-49889", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid use-after-free in ext4_ext_show_leaf() In ext4_find_extent(), path may be freed by error or be reallocated, so using a previously saved *ppath may have been freed and thus may trigger use-after-free, as follows: ext4_split_extent path = *ppath; ext4_split_extent_at(ppath) path = ext4_find_extent(ppath) ext4_split_extent_at(ppath) // ext4_find_extent fails to free path // but zeroout succeeds ext4_ext_show_leaf(inode, path) eh = path[depth].p_hdr // path use-after-free !!! Similar to ext4_split_extent_at(), we use *ppath directly as an input to ext4_ext_show_leaf(). Fix a spelling error by the way. Same problem in ext4_ext_handle_unwritten_extents(). Since 'path' is only used in ext4_ext_show_leaf(), remove 'path' and use *ppath directly. This issue is triggered only when EXT_DEBUG is defined and therefore does not affect functionality.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49968", "url": "https://ubuntu.com/security/CVE-2024-49968", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: filesystems without casefold feature cannot be mounted with siphash When mounting the ext4 filesystem, if the default hash version is set to DX_HASH_SIPHASH but the casefold feature is not set, exit the mounting.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49988", "url": "https://ubuntu.com/security/CVE-2024-49988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: add refcnt to ksmbd_conn struct When sending an oplock break request, opinfo->conn is used, But freed ->conn can be used on multichannel. This patch add a reference count to the ksmbd_conn struct so that it can be freed when it is no longer used.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49890", "url": "https://ubuntu.com/security/CVE-2024-49890", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: ensure the fw_info is not null before using it This resolves the dereference null return value warning reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49891", "url": "https://ubuntu.com/security/CVE-2024-49891", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata paths When the HBA is undergoing a reset or is handling an errata event, NULL ptr dereference crashes may occur in routines such as lpfc_sli_flush_io_rings(), lpfc_dev_loss_tmo_callbk(), or lpfc_abort_handler(). Add NULL ptr checks before dereferencing hdwq pointers that may have been freed due to operations colliding with a reset or errata event handler.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49892", "url": "https://ubuntu.com/security/CVE-2024-49892", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize get_bytes_per_element's default to 1 Variables, used as denominators and maybe not assigned to other values, should not be 0. bytes_per_element_y & bytes_per_element_c are initialized by get_bytes_per_element() which should never return 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50016", "url": "https://ubuntu.com/security/CVE-2024-50016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Avoid overflow assignment in link_dp_cts sampling_rate is an uint8_t but is assigned an unsigned int, and thus it can overflow. As a result, sampling_rate is changed to uint32_t. Similarly, LINK_QUAL_PATTERN_SET has a size of 2 bits, and it should only be assigned to a value less or equal than 4. This fixes 2 INTEGER_OVERFLOW issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49893", "url": "https://ubuntu.com/security/CVE-2024-49893", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check stream_status before it is used [WHAT & HOW] dc_state_get_stream_status can return null, and therefore null must be checked before stream_status is used. This fixes 1 NULL_RETURNS issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49969", "url": "https://ubuntu.com/security/CVE-2024-49969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 color transformation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_hw_format` function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:180 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:181 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:182 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49970", "url": "https://ubuntu.com/security/CVE-2024-49970", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Implement bounds check for stream encoder creation in DCN401 'stream_enc_regs' array is an array of dcn10_stream_enc_registers structures. The array is initialized with four elements, corresponding to the four calls to stream_enc_regs() in the array initializer. This means that valid indices for this array are 0, 1, 2, and 3. The error message 'stream_enc_regs' 4 <= 5 below, is indicating that there is an attempt to access this array with an index of 5, which is out of bounds. This could lead to undefined behavior Here, eng_id is used as an index to access the stream_enc_regs array. If eng_id is 5, this would result in an out-of-bounds access on the stream_enc_regs array. Thus fixing Buffer overflow error in dcn401_stream_encoder_create Found by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn401/dcn401_resource.c:1209 dcn401_stream_encoder_create() error: buffer overflow 'stream_enc_regs' 4 <= 5", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49894", "url": "https://ubuntu.com/security/CVE-2024-49894", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in degamma hardware format translation Fixes index out of bounds issue in `cm_helper_translate_curve_to_degamma_hw_format` function. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49895", "url": "https://ubuntu.com/security/CVE-2024-49895", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format translation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_degamma_hw_format` function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:338 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:339 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:340 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49971", "url": "https://ubuntu.com/security/CVE-2024-49971", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Increase array size of dummy_boolean [WHY] dml2_core_shared_mode_support and dml_core_mode_support access the third element of dummy_boolean, i.e. hw_debug5 = &s->dummy_boolean[2], when dummy_boolean has size of 2. Any assignment to hw_debug5 causes an OVERRUN. [HOW] Increase dummy_boolean's array size to 3. This fixes 2 OVERRUN issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49972", "url": "https://ubuntu.com/security/CVE-2024-49972", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Deallocate DML memory if allocation fails [Why] When DC state create DML memory allocation fails, memory is not deallocated subsequently, resulting in uninitialized structure that is not NULL. [How] Deallocate memory if DML memory allocation fails.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49896", "url": "https://ubuntu.com/security/CVE-2024-49896", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check stream before comparing them [WHAT & HOW] amdgpu_dm can pass a null stream to dc_is_stream_unchanged. It is necessary to check for null before dereferencing them. This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49897", "url": "https://ubuntu.com/security/CVE-2024-49897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check phantom_stream before it is used dcn32_enable_phantom_stream can return null, so returned value must be checked before used. This fixes 1 NULL_RETURNS issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49898", "url": "https://ubuntu.com/security/CVE-2024-49898", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null-initialized variables [WHAT & HOW] drr_timing and subvp_pipe are initialized to null and they are not always assigned new values. It is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49899", "url": "https://ubuntu.com/security/CVE-2024-49899", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize denominators' default to 1 [WHAT & HOW] Variables used as denominators and maybe not assigned to other values, should not be 0. Change their default to 1 so they are never 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49900", "url": "https://ubuntu.com/security/CVE-2024-49900", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uninit-value access of new_ea in ea_buffer syzbot reports that lzo1x_1_do_compress is using uninit-value: ===================================================== BUG: KMSAN: uninit-value in lzo1x_1_do_compress+0x19f9/0x2510 lib/lzo/lzo1x_compress.c:178 ... Uninit was stored to memory at: ea_put fs/jfs/xattr.c:639 [inline] ... Local variable ea_buf created at: __jfs_setxattr+0x5d/0x1ae0 fs/jfs/xattr.c:662 __jfs_xattr_set+0xe6/0x1f0 fs/jfs/xattr.c:934 ===================================================== The reason is ea_buf->new_ea is not initialized properly. Fix this by using memset to empty its content at the beginning in ea_get().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49901", "url": "https://ubuntu.com/security/CVE-2024-49901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm/adreno: Assign msm_gpu->pdev earlier to avoid nullptrs There are some cases, such as the one uncovered by Commit 46d4efcccc68 (\"drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails\") where msm_gpu_cleanup() : platform_set_drvdata(gpu->pdev, NULL); is called on gpu->pdev == NULL, as the GPU device has not been fully initialized yet. Turns out that there's more than just the aforementioned path that causes this to happen (e.g. the case when there's speedbin data in the catalog, but opp-supported-hw is missing in DT). Assigning msm_gpu->pdev earlier seems like the least painful solution to this, therefore do so. Patchwork: https://patchwork.freedesktop.org/patch/602742/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49902", "url": "https://ubuntu.com/security/CVE-2024-49902", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: check if leafidx greater than num leaves per dmap tree syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf. Shaggy: Modified sanity check to apply to control pages as well as leaf pages.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49903", "url": "https://ubuntu.com/security/CVE-2024-49903", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uaf in dbFreeBits [syzbot reported] ================================================================== BUG: KASAN: slab-use-after-free in __mutex_lock_common kernel/locking/mutex.c:587 [inline] BUG: KASAN: slab-use-after-free in __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 Read of size 8 at addr ffff8880229254b0 by task syz-executor357/5216 CPU: 0 UID: 0 PID: 5216 Comm: syz-executor357 Not tainted 6.11.0-rc3-syzkaller-00156-gd7a5aa4b3c00 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 __mutex_lock_common kernel/locking/mutex.c:587 [inline] __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 dbFreeBits+0x7ea/0xd90 fs/jfs/jfs_dmap.c:2390 dbFreeDmap fs/jfs/jfs_dmap.c:2089 [inline] dbFree+0x35b/0x680 fs/jfs/jfs_dmap.c:409 dbDiscardAG+0x8a9/0xa20 fs/jfs/jfs_dmap.c:1650 jfs_ioc_trim+0x433/0x670 fs/jfs/jfs_discard.c:100 jfs_ioctl+0x2d0/0x3e0 fs/jfs/ioctl.c:131 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 Freed by task 5218: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object+0xe0/0x150 mm/kasan/common.c:240 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2252 [inline] slab_free mm/slub.c:4473 [inline] kfree+0x149/0x360 mm/slub.c:4594 dbUnmount+0x11d/0x190 fs/jfs/jfs_dmap.c:278 jfs_mount_rw+0x4ac/0x6a0 fs/jfs/jfs_mount.c:247 jfs_remount+0x3d1/0x6b0 fs/jfs/super.c:454 reconfigure_super+0x445/0x880 fs/super.c:1083 vfs_cmd_reconfigure fs/fsopen.c:263 [inline] vfs_fsconfig_locked fs/fsopen.c:292 [inline] __do_sys_fsconfig fs/fsopen.c:473 [inline] __se_sys_fsconfig+0xb6e/0xf80 fs/fsopen.c:345 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 [Analysis] There are two paths (dbUnmount and jfs_ioc_trim) that generate race condition when accessing bmap, which leads to the occurrence of uaf. Use the lock s_umount to synchronize them, in order to avoid uaf caused by race condition.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49904", "url": "https://ubuntu.com/security/CVE-2024-49904", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add list empty check to avoid null pointer issue Add list empty check to avoid null pointer issues in some corner cases. - list_for_each_entry_safe()", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49989", "url": "https://ubuntu.com/security/CVE-2024-49989", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix double free issue during amdgpu module unload Flexible endpoints use DIGs from available inflexible endpoints, so only the encoders of inflexible links need to be freed. Otherwise, a double free issue may occur when unloading the amdgpu module. [ 279.190523] RIP: 0010:__slab_free+0x152/0x2f0 [ 279.190577] Call Trace: [ 279.190580] [ 279.190582] ? show_regs+0x69/0x80 [ 279.190590] ? die+0x3b/0x90 [ 279.190595] ? do_trap+0xc8/0xe0 [ 279.190601] ? do_error_trap+0x73/0xa0 [ 279.190605] ? __slab_free+0x152/0x2f0 [ 279.190609] ? exc_invalid_op+0x56/0x70 [ 279.190616] ? __slab_free+0x152/0x2f0 [ 279.190642] ? asm_exc_invalid_op+0x1f/0x30 [ 279.190648] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191096] ? __slab_free+0x152/0x2f0 [ 279.191102] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191469] kfree+0x260/0x2b0 [ 279.191474] dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191821] link_destroy+0xd7/0x130 [amdgpu] [ 279.192248] dc_destruct+0x90/0x270 [amdgpu] [ 279.192666] dc_destroy+0x19/0x40 [amdgpu] [ 279.193020] amdgpu_dm_fini+0x16e/0x200 [amdgpu] [ 279.193432] dm_hw_fini+0x26/0x40 [amdgpu] [ 279.193795] amdgpu_device_fini_hw+0x24c/0x400 [amdgpu] [ 279.194108] amdgpu_driver_unload_kms+0x4f/0x70 [amdgpu] [ 279.194436] amdgpu_pci_remove+0x40/0x80 [amdgpu] [ 279.194632] pci_device_remove+0x3a/0xa0 [ 279.194638] device_remove+0x40/0x70 [ 279.194642] device_release_driver_internal+0x1ad/0x210 [ 279.194647] driver_detach+0x4e/0xa0 [ 279.194650] bus_remove_driver+0x6f/0xf0 [ 279.194653] driver_unregister+0x33/0x60 [ 279.194657] pci_unregister_driver+0x44/0x90 [ 279.194662] amdgpu_exit+0x19/0x1f0 [amdgpu] [ 279.194939] __do_sys_delete_module.isra.0+0x198/0x2f0 [ 279.194946] __x64_sys_delete_module+0x16/0x20 [ 279.194950] do_syscall_64+0x58/0x120 [ 279.194954] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 279.194980] ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49905", "url": "https://ubuntu.com/security/CVE-2024-49905", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for 'afb' in amdgpu_dm_plane_handle_cursor_update (v2) This commit adds a null check for the 'afb' variable in the amdgpu_dm_plane_handle_cursor_update function. Previously, 'afb' was assumed to be null, but was used later in the code without a null check. This could potentially lead to a null pointer dereference. Changes since v1: - Moved the null check for 'afb' to the line where 'afb' is used. (Alex) Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:1298 amdgpu_dm_plane_handle_cursor_update() error: we previously assumed 'afb' could be null (see line 1252)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49906", "url": "https://ubuntu.com/security/CVE-2024-49906", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before try to access it [why & how] Change the order of the pipe_ctx->plane_state check to ensure that plane_state is not null before accessing it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49907", "url": "https://ubuntu.com/security/CVE-2024-49907", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before using dc->clk_mgr [WHY & HOW] dc->clk_mgr is null checked previously in the same function, indicating it might be null. Passing \"dc\" to \"dc->hwss.apply_idle_power_optimizations\", which dereferences null \"dc->clk_mgr\". (The function pointer resolves to \"dcn35_apply_idle_power_optimizations\".) This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49908", "url": "https://ubuntu.com/security/CVE-2024-49908", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for 'afb' in amdgpu_dm_update_cursor (v2) This commit adds a null check for the 'afb' variable in the amdgpu_dm_update_cursor function. Previously, 'afb' was assumed to be null at line 8388, but was used later in the code without a null check. This could potentially lead to a null pointer dereference. Changes since v1: - Moved the null check for 'afb' to the line where 'afb' is used. (Alex) Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:8433 amdgpu_dm_update_cursor() \terror: we previously assumed 'afb' could be null (see line 8388)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50177", "url": "https://ubuntu.com/security/CVE-2024-50177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix a UBSAN warning in DML2.1 When programming phantom pipe, since cursor_width is explicity set to 0, this causes calculation logic to trigger overflow for an unsigned int triggering the kernel's UBSAN check as below: [ 40.962845] UBSAN: shift-out-of-bounds in /tmp/amd.EfpumTkO/amd/amdgpu/../display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c:3312:34 [ 40.962849] shift exponent 4294967170 is too large for 32-bit type 'unsigned int' [ 40.962852] CPU: 1 PID: 1670 Comm: gnome-shell Tainted: G W OE 6.5.0-41-generic #41~22.04.2-Ubuntu [ 40.962854] Hardware name: Gigabyte Technology Co., Ltd. X670E AORUS PRO X/X670E AORUS PRO X, BIOS F21 01/10/2024 [ 40.962856] Call Trace: [ 40.962857] [ 40.962860] dump_stack_lvl+0x48/0x70 [ 40.962870] dump_stack+0x10/0x20 [ 40.962872] __ubsan_handle_shift_out_of_bounds+0x1ac/0x360 [ 40.962878] calculate_cursor_req_attributes.cold+0x1b/0x28 [amdgpu] [ 40.963099] dml_core_mode_support+0x6b91/0x16bc0 [amdgpu] [ 40.963327] ? srso_alias_return_thunk+0x5/0x7f [ 40.963331] ? CalculateWatermarksMALLUseAndDRAMSpeedChangeSupport+0x18b8/0x2790 [amdgpu] [ 40.963534] ? srso_alias_return_thunk+0x5/0x7f [ 40.963536] ? dml_core_mode_support+0xb3db/0x16bc0 [amdgpu] [ 40.963730] dml2_core_calcs_mode_support_ex+0x2c/0x90 [amdgpu] [ 40.963906] ? srso_alias_return_thunk+0x5/0x7f [ 40.963909] ? dml2_core_calcs_mode_support_ex+0x2c/0x90 [amdgpu] [ 40.964078] core_dcn4_mode_support+0x72/0xbf0 [amdgpu] [ 40.964247] dml2_top_optimization_perform_optimization_phase+0x1d3/0x2a0 [amdgpu] [ 40.964420] dml2_build_mode_programming+0x23d/0x750 [amdgpu] [ 40.964587] dml21_validate+0x274/0x770 [amdgpu] [ 40.964761] ? srso_alias_return_thunk+0x5/0x7f [ 40.964763] ? resource_append_dpp_pipes_for_plane_composition+0x27c/0x3b0 [amdgpu] [ 40.964942] dml2_validate+0x504/0x750 [amdgpu] [ 40.965117] ? dml21_copy+0x95/0xb0 [amdgpu] [ 40.965291] ? srso_alias_return_thunk+0x5/0x7f [ 40.965295] dcn401_validate_bandwidth+0x4e/0x70 [amdgpu] [ 40.965491] update_planes_and_stream_state+0x38d/0x5c0 [amdgpu] [ 40.965672] update_planes_and_stream_v3+0x52/0x1e0 [amdgpu] [ 40.965845] ? srso_alias_return_thunk+0x5/0x7f [ 40.965849] dc_update_planes_and_stream+0x71/0xb0 [amdgpu] Fix this by adding a guard for checking cursor width before triggering the size calculation.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49909", "url": "https://ubuntu.com/security/CVE-2024-49909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn32_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn32_set_output_transfer_func function. Previously, set_output_gamma was being checked for null, but then it was being dereferenced without any null check. This could lead to a null pointer dereference if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49910", "url": "https://ubuntu.com/security/CVE-2024-49910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn401_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn401_set_output_transfer_func function. Previously, set_output_gamma was being checked for null, but then it was being dereferenced without any null check. This could lead to a null pointer dereference if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49911", "url": "https://ubuntu.com/security/CVE-2024-49911", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn20_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn20_set_output_transfer_func function. Previously, set_output_gamma was being checked for null at line 1030, but then it was being dereferenced without any null check at line 1048. This could potentially lead to a null pointer dereference error if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma at line 1048.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49912", "url": "https://ubuntu.com/security/CVE-2024-49912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Handle null 'stream_status' in 'planes_changed_for_existing_stream' This commit adds a null check for 'stream_status' in the function 'planes_changed_for_existing_stream'. Previously, the code assumed 'stream_status' could be null, but did not handle the case where it was actually null. This could lead to a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:3784 planes_changed_for_existing_stream() error: we previously assumed 'stream_status' could be null (see line 3774)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49913", "url": "https://ubuntu.com/security/CVE-2024-49913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for top_pipe_to_program in commit_planes_for_stream This commit addresses a null pointer dereference issue in the `commit_planes_for_stream` function at line 4140. The issue could occur when `top_pipe_to_program` is null. The fix adds a check to ensure `top_pipe_to_program` is not null before accessing its stream_res. This prevents a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:4140 commit_planes_for_stream() error: we previously assumed 'top_pipe_to_program' could be null (see line 3906)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49914", "url": "https://ubuntu.com/security/CVE-2024-49914", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for pipe_ctx->plane_state in dcn20_program_pipe This commit addresses a null pointer dereference issue in the `dcn20_program_pipe` function. The issue could occur when `pipe_ctx->plane_state` is null. The fix adds a check to ensure `pipe_ctx->plane_state` is not null before accessing. This prevents a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn20/dcn20_hwseq.c:1925 dcn20_program_pipe() error: we previously assumed 'pipe_ctx->plane_state' could be null (see line 1877)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49915", "url": "https://ubuntu.com/security/CVE-2024-49915", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr in dcn32_init_hw This commit addresses a potential null pointer dereference issue in the `dcn32_init_hw` function. The issue could occur when `dc->clk_mgr` is null. The fix adds a check to ensure `dc->clk_mgr` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn32/dcn32_hwseq.c:961 dcn32_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 782)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49916", "url": "https://ubuntu.com/security/CVE-2024-49916", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in dcn401_init_hw This commit addresses a potential null pointer dereference issue in the `dcn401_init_hw` function. The issue could occur when `dc->clk_mgr` or `dc->clk_mgr->funcs` is null. The fix adds a check to ensure `dc->clk_mgr` and `dc->clk_mgr->funcs` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn401/dcn401_hwseq.c:416 dcn401_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 225)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49917", "url": "https://ubuntu.com/security/CVE-2024-49917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in dcn30_init_hw This commit addresses a potential null pointer dereference issue in the `dcn30_init_hw` function. The issue could occur when `dc->clk_mgr` or `dc->clk_mgr->funcs` is null. The fix adds a check to ensure `dc->clk_mgr` and `dc->clk_mgr->funcs` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:789 dcn30_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 628)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49918", "url": "https://ubuntu.com/security/CVE-2024-49918", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for head_pipe in dcn32_acquire_idle_pipe_for_head_pipe_in_layer This commit addresses a potential null pointer dereference issue in the `dcn32_acquire_idle_pipe_for_head_pipe_in_layer` function. The issue could occur when `head_pipe` is null. The fix adds a check to ensure `head_pipe` is not null before asserting it. If `head_pipe` is null, the function returns NULL to prevent a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn32/dcn32_resource.c:2690 dcn32_acquire_idle_pipe_for_head_pipe_in_layer() error: we previously assumed 'head_pipe' could be null (see line 2681)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49919", "url": "https://ubuntu.com/security/CVE-2024-49919", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for head_pipe in dcn201_acquire_free_pipe_for_layer This commit addresses a potential null pointer dereference issue in the `dcn201_acquire_free_pipe_for_layer` function. The issue could occur when `head_pipe` is null. The fix adds a check to ensure `head_pipe` is not null before asserting it. If `head_pipe` is null, the function returns NULL to prevent a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn201/dcn201_resource.c:1016 dcn201_acquire_free_pipe_for_layer() error: we previously assumed 'head_pipe' could be null (see line 1010)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49991", "url": "https://ubuntu.com/security/CVE-2024-49991", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer Pass pointer reference to amdgpu_bo_unref to clear the correct pointer, otherwise amdgpu_bo_unref clear the local variable, the original pointer not set to NULL, this could cause use-after-free bug.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49920", "url": "https://ubuntu.com/security/CVE-2024-49920", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before multiple uses [WHAT & HOW] Poniters, such as stream_enc and dc->bw_vbios, are null checked previously in the same function, so Coverity warns \"implies that stream_enc and dc->bw_vbios might be null\". They are used multiple times in the subsequent code and need to be checked. This fixes 10 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49921", "url": "https://ubuntu.com/security/CVE-2024-49921", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before used [WHAT & HOW] Poniters, such as dc->clk_mgr, are null checked previously in the same function, so Coverity warns \"implies that \"dc->clk_mgr\" might be null\". As a result, these pointers need to be checked when used again. This fixes 10 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49922", "url": "https://ubuntu.com/security/CVE-2024-49922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before using them [WHAT & HOW] These pointers are null checked previously in the same function, indicating they might be null as reported by Coverity. As a result, they need to be checked when used again. This fixes 3 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49923", "url": "https://ubuntu.com/security/CVE-2024-49923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Pass non-null to dcn20_validate_apply_pipe_split_flags [WHAT & HOW] \"dcn20_validate_apply_pipe_split_flags\" dereferences merge, and thus it cannot be a null pointer. Let's pass a valid pointer to avoid null dereference. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49992", "url": "https://ubuntu.com/security/CVE-2024-49992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/stm: Avoid use-after-free issues with crtc and plane ltdc_load() calls functions drm_crtc_init_with_planes(), drm_universal_plane_init() and drm_encoder_init(). These functions should not be called with parameters allocated with devm_kzalloc() to avoid use-after-free issues [1]. Use allocations managed by the DRM framework. Found by Linux Verification Center (linuxtesting.org). [1] https://lore.kernel.org/lkml/u366i76e3qhh3ra5oxrtngjtm2u5lterkekcz6y2jkndhuxzli@diujon4h7qwb/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49993", "url": "https://ubuntu.com/security/CVE-2024-49993", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49924", "url": "https://ubuntu.com/security/CVE-2024-49924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: pxafb: Fix possible use after free in pxafb_task() In the pxafb_probe function, it calls the pxafb_init_fbinfo function, after which &fbi->task is associated with pxafb_task. Moreover, within this pxafb_init_fbinfo function, the pxafb_blank function within the &pxafb_ops struct is capable of scheduling work. If we remove the module which will call pxafb_remove to make cleanup, it will call unregister_framebuffer function which can call do_unregister_framebuffer to free fbi->fb through put_fb_info(fb_info), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | pxafb_task pxafb_remove | unregister_framebuffer(info) | do_unregister_framebuffer(fb_info) | put_fb_info(fb_info) | // free fbi->fb | set_ctrlr_state(fbi, state) | __pxafb_lcd_power(fbi, 0) | fbi->lcd_power(on, &fbi->fb.var) | //use fbi->fb Fix it by ensuring that the work is canceled before proceeding with the cleanup in pxafb_remove. Note that only root user can remove the driver at runtime.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49925", "url": "https://ubuntu.com/security/CVE-2024-49925", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: efifb: Register sysfs groups through driver core The driver core can register and cleanup sysfs groups already. Make use of that functionality to simplify the error handling and cleanup. Also avoid a UAF race during unregistering where the sysctl attributes were usable after the info struct was freed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49926", "url": "https://ubuntu.com/security/CVE-2024-49926", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rcu-tasks: Fix access non-existent percpu rtpcp variable in rcu_tasks_need_gpcb() For kernels built with CONFIG_FORCE_NR_CPUS=y, the nr_cpu_ids is defined as NR_CPUS instead of the number of possible cpus, this will cause the following system panic: smpboot: Allowing 4 CPUs, 0 hotplug CPUs ... setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:512 nr_node_ids:1 ... BUG: unable to handle page fault for address: ffffffff9911c8c8 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 15 Comm: rcu_tasks_trace Tainted: G W 6.6.21 #1 5dc7acf91a5e8e9ac9dcfc35bee0245691283ea6 RIP: 0010:rcu_tasks_need_gpcb+0x25d/0x2c0 RSP: 0018:ffffa371c00a3e60 EFLAGS: 00010082 CR2: ffffffff9911c8c8 CR3: 000000040fa20005 CR4: 00000000001706f0 Call Trace: ? __die+0x23/0x80 ? page_fault_oops+0xa4/0x180 ? exc_page_fault+0x152/0x180 ? asm_exc_page_fault+0x26/0x40 ? rcu_tasks_need_gpcb+0x25d/0x2c0 ? __pfx_rcu_tasks_kthread+0x40/0x40 rcu_tasks_one_gp+0x69/0x180 rcu_tasks_kthread+0x94/0xc0 kthread+0xe8/0x140 ? __pfx_kthread+0x40/0x40 ret_from_fork+0x34/0x80 ? __pfx_kthread+0x40/0x40 ret_from_fork_asm+0x1b/0x80 Considering that there may be holes in the CPU numbers, use the maximum possible cpu number, instead of nr_cpu_ids, for configuring enqueue and dequeue limits. [ neeraj.upadhyay: Fix htmldocs build error reported by Stephen Rothwell ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50007", "url": "https://ubuntu.com/security/CVE-2024-50007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: asihpi: Fix potential OOB array access ASIHPI driver stores some values in the static array upon a response from the driver, and its index depends on the firmware. We shouldn't trust it blindly. This patch adds a sanity check of the array index to fit in the array size.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50017", "url": "https://ubuntu.com/security/CVE-2024-50017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm/ident_map: Use gbpages only where full GB page should be mapped. When ident_pud_init() uses only GB pages to create identity maps, large ranges of addresses not actually requested can be included in the resulting table; a 4K request will map a full GB. This can include a lot of extra address space past that requested, including areas marked reserved by the BIOS. That allows processor speculation into reserved regions, that on UV systems can cause system halts. Only use GB pages when map creation requests include the full GB page of space. Fall back to using smaller 2M pages when only portions of a GB page are included in the request. No attempt is made to coalesce mapping requests. If a request requires a map entry at the 2M (pmd) level, subsequent mapping requests within the same 1G region will also be at the pmd level, even if adjacent or overlapping such requests could have been combined to map a full GB page. Existing usage starts with larger regions and then adds smaller regions, so this should not have any great consequence.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49927", "url": "https://ubuntu.com/security/CVE-2024-49927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/ioapic: Handle allocation failures gracefully Breno observed panics when using failslab under certain conditions during runtime: can not alloc irq_pin_list (-1,0,20) Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed panic+0x4e9/0x590 mp_irqdomain_alloc+0x9ab/0xa80 irq_domain_alloc_irqs_locked+0x25d/0x8d0 __irq_domain_alloc_irqs+0x80/0x110 mp_map_pin_to_irq+0x645/0x890 acpi_register_gsi_ioapic+0xe6/0x150 hpet_open+0x313/0x480 That's a pointless panic which is a leftover of the historic IO/APIC code which panic'ed during early boot when the interrupt allocation failed. The only place which might justify panic is the PIT/HPET timer_check() code which tries to figure out whether the timer interrupt is delivered through the IO/APIC. But that code does not require to handle interrupt allocation failures. If the interrupt cannot be allocated then timer delivery fails and it either panics due to that or falls back to legacy mode. Cure this by removing the panic wrapper around __add_pin_to_irq_node() and making mp_irqdomain_alloc() aware of the failure condition and handle it as any other failure in this function gracefully.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50008", "url": "https://ubuntu.com/security/CVE-2024-50008", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_cmd_802_11_scan_ext() Replace one-element array with a flexible-array member in `struct host_cmd_ds_802_11_scan_ext`. With this, fix the following warning: elo 16 17:51:58 surfacebook kernel: ------------[ cut here ]------------ elo 16 17:51:58 surfacebook kernel: memcpy: detected field-spanning write (size 243) of single field \"ext_scan->tlv_buffer\" at drivers/net/wireless/marvell/mwifiex/scan.c:2239 (size 1) elo 16 17:51:58 surfacebook kernel: WARNING: CPU: 0 PID: 498 at drivers/net/wireless/marvell/mwifiex/scan.c:2239 mwifiex_cmd_802_11_scan_ext+0x83/0x90 [mwifiex]", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50018", "url": "https://ubuntu.com/security/CVE-2024-50018", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49928", "url": "https://ubuntu.com/security/CVE-2024-49928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: avoid reading out of bounds when loading TX power FW elements Because the loop-expression will do one more time before getting false from cond-expression, the original code copied one more entry size beyond valid region. Fix it by moving the entry copy to loop-body.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50178", "url": "https://ubuntu.com/security/CVE-2024-50178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: loongson3: Use raw_smp_processor_id() in do_service_request() Use raw_smp_processor_id() instead of plain smp_processor_id() in do_service_request(), otherwise we may get some errors with the driver enabled: BUG: using smp_processor_id() in preemptible [00000000] code: (udev-worker)/208 caller is loongson3_cpufreq_probe+0x5c/0x250 [loongson3_cpufreq]", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50009", "url": "https://ubuntu.com/security/CVE-2024-50009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: amd-pstate: add check for cpufreq_cpu_get's return value cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it and return in case of error. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49994", "url": "https://ubuntu.com/security/CVE-2024-49994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix integer overflow in BLKSECDISCARD I independently rediscovered \tcommit 22d24a544b0d49bbcbd61c8c0eaf77d3c9297155 \tblock: fix overflow in blk_ioctl_discard() but for secure erase. Same problem: \tuint64_t r[2] = {512, 18446744073709551104ULL}; \tioctl(fd, BLKSECDISCARD, r); will enter near infinite loop inside blkdev_issue_secure_erase(): \ta.out: attempt to access beyond end of device \tloop0: rw=5, sector=3399043073, nr_sectors = 1024 limit=2048 \tbio_check_eod: 3286214 callbacks suppressed", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49929", "url": "https://ubuntu.com/security/CVE-2024-49929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: avoid NULL pointer dereference iwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta pointer is not NULL. It retrieves this pointer using iwl_mvm_sta_from_mac80211, which is dereferencing the ieee80211_sta pointer. If sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL pointer. Fix this by checking the sta pointer before retrieving the mvmsta from it. If sta is not NULL, then mvmsta isn't either.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49995", "url": "https://ubuntu.com/security/CVE-2024-49995", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: guard against string buffer overrun Smatch reports that copying media_name and if_name to name_parts may overwrite the destination. .../bearer.c:166 bearer_name_validate() error: strcpy() 'media_name' too large for 'name_parts->media_name' (32 vs 16) .../bearer.c:167 bearer_name_validate() error: strcpy() 'if_name' too large for 'name_parts->if_name' (1010102 vs 16) This does seem to be the case so guard against this possibility by using strscpy() and failing if truncation occurs. Introduced by commit b97bf3fd8f6a (\"[TIPC] Initial merge\") Compile tested only.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49962", "url": "https://ubuntu.com/security/CVE-2024-49962", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in acpi_db_convert_to_package() ACPICA commit 4d4547cf13cca820ff7e0f859ba83e1a610b9fd0 ACPI_ALLOCATE_ZEROED() may fail, elements might be NULL and will cause NULL pointer dereference later. [ rjw: Subject and changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49930", "url": "https://ubuntu.com/security/CVE-2024-49930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix array out-of-bound access in SoC stats Currently, the ath11k_soc_dp_stats::hal_reo_error array is defined with a maximum size of DP_REO_DST_RING_MAX. However, the ath11k_dp_process_rx() function access ath11k_soc_dp_stats::hal_reo_error using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath11k_dp_process_rx() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49931", "url": "https://ubuntu.com/security/CVE-2024-49931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix array out-of-bound access in SoC stats Currently, the ath12k_soc_dp_stats::hal_reo_error array is defined with a maximum size of DP_REO_DST_RING_MAX. However, the ath12k_dp_rx_process() function access ath12k_soc_dp_stats::hal_reo_error using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath12k_dp_rx_process() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49932", "url": "https://ubuntu.com/security/CVE-2024-49932", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: don't readahead the relocation inode on RST On relocation we're doing readahead on the relocation inode, but if the filesystem is backed by a RAID stripe tree we can get ENOENT (e.g. due to preallocated extents not being mapped in the RST) from the lookup. But readahead doesn't handle the error and submits invalid reads to the device, causing an assertion in the scatter-gather list code: BTRFS info (device nvme1n1): balance: start -d -m -s BTRFS info (device nvme1n1): relocating block group 6480920576 flags data|raid0 BTRFS error (device nvme1n1): cannot find raid-stripe for logical [6481928192, 6481969152] devid 2, profile raid0 ------------[ cut here ]------------ kernel BUG at include/linux/scatterlist.h:115! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 1012 Comm: btrfs Not tainted 6.10.0-rc7+ #567 RIP: 0010:__blk_rq_map_sg+0x339/0x4a0 RSP: 0018:ffffc90001a43820 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffea00045d4802 RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000 RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000001000 R12: ffff8881003d10b8 R13: ffffc90001a438f0 R14: 0000000000000000 R15: 0000000000003000 FS: 00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000002cd11000 CR3: 00000001109ea001 CR4: 0000000000370eb0 Call Trace: ? __die_body.cold+0x14/0x25 ? die+0x2e/0x50 ? do_trap+0xca/0x110 ? do_error_trap+0x65/0x80 ? __blk_rq_map_sg+0x339/0x4a0 ? exc_invalid_op+0x50/0x70 ? __blk_rq_map_sg+0x339/0x4a0 ? asm_exc_invalid_op+0x1a/0x20 ? __blk_rq_map_sg+0x339/0x4a0 nvme_prep_rq.part.0+0x9d/0x770 nvme_queue_rq+0x7d/0x1e0 __blk_mq_issue_directly+0x2a/0x90 ? blk_mq_get_budget_and_tag+0x61/0x90 blk_mq_try_issue_list_directly+0x56/0xf0 blk_mq_flush_plug_list.part.0+0x52b/0x5d0 __blk_flush_plug+0xc6/0x110 blk_finish_plug+0x28/0x40 read_pages+0x160/0x1c0 page_cache_ra_unbounded+0x109/0x180 relocate_file_extent_cluster+0x611/0x6a0 ? btrfs_search_slot+0xba4/0xd20 ? balance_dirty_pages_ratelimited_flags+0x26/0xb00 relocate_data_extent.constprop.0+0x134/0x160 relocate_block_group+0x3f2/0x500 btrfs_relocate_block_group+0x250/0x430 btrfs_relocate_chunk+0x3f/0x130 btrfs_balance+0x71b/0xef0 ? kmalloc_trace_noprof+0x13b/0x280 btrfs_ioctl+0x2c2e/0x3030 ? kvfree_call_rcu+0x1e6/0x340 ? list_lru_add_obj+0x66/0x80 ? mntput_no_expire+0x3a/0x220 __x64_sys_ioctl+0x96/0xc0 do_syscall_64+0x54/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fcc04514f9b Code: Unable to access opcode bytes at 0x7fcc04514f71. RSP: 002b:00007ffeba923370 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fcc04514f9b RDX: 00007ffeba923460 RSI: 00000000c4009420 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000013 R09: 0000000000000001 R10: 00007fcc043fbba8 R11: 0000000000000246 R12: 00007ffeba924fc5 R13: 00007ffeba923460 R14: 0000000000000002 R15: 00000000004d4bb0 Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:__blk_rq_map_sg+0x339/0x4a0 RSP: 0018:ffffc90001a43820 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffea00045d4802 RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000 RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000001000 R12: ffff8881003d10b8 R13: ffffc90001a438f0 R14: 0000000000000000 R15: 0000000000003000 FS: 00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcc04514f71 CR3: 00000001109ea001 CR4: 0000000000370eb0 Kernel p ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49933", "url": "https://ubuntu.com/security/CVE-2024-49933", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk_iocost: fix more out of bound shifts Recently running UBSAN caught few out of bound shifts in the ioc_forgive_debts() function: UBSAN: shift-out-of-bounds in block/blk-iocost.c:2142:38 shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long long') ... UBSAN: shift-out-of-bounds in block/blk-iocost.c:2144:30 shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long long') ... Call Trace: dump_stack_lvl+0xca/0x130 __ubsan_handle_shift_out_of_bounds+0x22c/0x280 ? __lock_acquire+0x6441/0x7c10 ioc_timer_fn+0x6cec/0x7750 ? blk_iocost_init+0x720/0x720 ? call_timer_fn+0x5d/0x470 call_timer_fn+0xfa/0x470 ? blk_iocost_init+0x720/0x720 __run_timer_base+0x519/0x700 ... Actual impact of this issue was not identified but I propose to fix the undefined behaviour. The proposed fix to prevent those out of bound shifts consist of precalculating exponent before using it the shift operations by taking min value from the actual exponent and maximum possible number of bits.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49934", "url": "https://ubuntu.com/security/CVE-2024-49934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/inode: Prevent dump_mapping() accessing invalid dentry.d_name.name It's observed that a crash occurs during hot-remove a memory device, in which user is accessing the hugetlb. See calltrace as following: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 14045 at arch/x86/mm/fault.c:1278 do_user_addr_fault+0x2a0/0x790 Modules linked in: kmem device_dax cxl_mem cxl_pmem cxl_port cxl_pci dax_hmem dax_pmem nd_pmem cxl_acpi nd_btt cxl_core crc32c_intel nvme virtiofs fuse nvme_core nfit libnvdimm dm_multipath scsi_dh_rdac scsi_dh_emc s mirror dm_region_hash dm_log dm_mod CPU: 1 PID: 14045 Comm: daxctl Not tainted 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:do_user_addr_fault+0x2a0/0x790 Code: 48 8b 00 a8 04 0f 84 b5 fe ff ff e9 1c ff ff ff 4c 89 e9 4c 89 e2 be 01 00 00 00 bf 02 00 00 00 e8 b5 ef 24 00 e9 42 fe ff ff <0f> 0b 48 83 c4 08 4c 89 ea 48 89 ee 4c 89 e7 5b 5d 41 5c 41 5d 41 RSP: 0000:ffffc90000a575f0 EFLAGS: 00010046 RAX: ffff88800c303600 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000001000 RSI: ffffffff82504162 RDI: ffffffff824b2c36 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffc90000a57658 R13: 0000000000001000 R14: ffff88800bc2e040 R15: 0000000000000000 FS: 00007f51cb57d880(0000) GS:ffff88807fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000001000 CR3: 00000000072e2004 CR4: 00000000001706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn+0x8d/0x190 ? do_user_addr_fault+0x2a0/0x790 ? report_bug+0x1c3/0x1d0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? do_user_addr_fault+0x2a0/0x790 ? exc_page_fault+0x31/0x200 exc_page_fault+0x68/0x200 <...snip...> BUG: unable to handle page fault for address: 0000000000001000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI ---[ end trace 0000000000000000 ]--- BUG: unable to handle page fault for address: 0000000000001000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 14045 Comm: daxctl Kdump: loaded Tainted: G W 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:dentry_name+0x1f4/0x440 <...snip...> ? dentry_name+0x2fa/0x440 vsnprintf+0x1f3/0x4f0 vprintk_store+0x23a/0x540 vprintk_emit+0x6d/0x330 _printk+0x58/0x80 dump_mapping+0x10b/0x1a0 ? __pfx_free_object_rcu+0x10/0x10 __dump_page+0x26b/0x3e0 ? vprintk_emit+0xe0/0x330 ? _printk+0x58/0x80 ? dump_page+0x17/0x50 dump_page+0x17/0x50 do_migrate_range+0x2f7/0x7f0 ? do_migrate_range+0x42/0x7f0 ? offline_pages+0x2f4/0x8c0 offline_pages+0x60a/0x8c0 memory_subsys_offline+0x9f/0x1c0 ? lockdep_hardirqs_on+0x77/0x100 ? _raw_spin_unlock_irqrestore+0x38/0x60 device_offline+0xe3/0x110 state_store+0x6e/0xc0 kernfs_fop_write_iter+0x143/0x200 vfs_write+0x39f/0x560 ksys_write+0x65/0xf0 do_syscall_64+0x62/0x130 Previously, some sanity check have been done in dump_mapping() before the print facility parsing '%pd' though, it's still possible to run into an invalid dentry.d_name.name. Since dump_mapping() only needs to dump the filename only, retrieve it by itself in a safer way to prevent an unnecessary crash. Note that either retrieving the filename with '%pd' or strncpy_from_kernel_nofault(), the filename could be unreliable.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49935", "url": "https://ubuntu.com/security/CVE-2024-49935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: PAD: fix crash in exit_round_robin() The kernel occasionally crashes in cpumask_clear_cpu(), which is called within exit_round_robin(), because when executing clear_bit(nr, addr) with nr set to 0xffffffff, the address calculation may cause misalignment within the memory, leading to access to an invalid memory address. ---------- BUG: unable to handle kernel paging request at ffffffffe0740618 ... CPU: 3 PID: 2919323 Comm: acpi_pad/14 Kdump: loaded Tainted: G OE X --------- - - 4.18.0-425.19.2.el8_7.x86_64 #1 ... RIP: 0010:power_saving_thread+0x313/0x411 [acpi_pad] Code: 89 cd 48 89 d3 eb d1 48 c7 c7 55 70 72 c0 e8 64 86 b0 e4 c6 05 0d a1 02 00 01 e9 bc fd ff ff 45 89 e4 42 8b 04 a5 20 82 72 c0 48 0f b3 05 f4 9c 01 00 42 c7 04 a5 20 82 72 c0 ff ff ff ff 31 RSP: 0018:ff72a5d51fa77ec8 EFLAGS: 00010202 RAX: 00000000ffffffff RBX: ff462981e5d8cb80 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246 RBP: ff46297556959d80 R08: 0000000000000382 R09: ff46297c8d0f38d8 R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000000e R13: 0000000000000000 R14: ffffffffffffffff R15: 000000000000000e FS: 0000000000000000(0000) GS:ff46297a800c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffe0740618 CR3: 0000007e20410004 CR4: 0000000000771ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? acpi_pad_add+0x120/0x120 [acpi_pad] kthread+0x10b/0x130 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x1f/0x40 ... CR2: ffffffffe0740618 crash> dis -lr ffffffffc0726923 ... /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 114 0xffffffffc0726918 :\tmov %r12d,%r12d /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 325 0xffffffffc072691b :\tmov -0x3f8d7de0(,%r12,4),%eax /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./arch/x86/include/asm/bitops.h: 80 0xffffffffc0726923 :\tlock btr %rax,0x19cf4(%rip) # 0xffffffffc0740620 crash> px tsk_in_cpu[14] $66 = 0xffffffff crash> px 0xffffffffc072692c+0x19cf4 $99 = 0xffffffffc0740620 crash> sym 0xffffffffc0740620 ffffffffc0740620 (b) pad_busy_cpus_bits [acpi_pad] crash> px pad_busy_cpus_bits[0] $42 = 0xfffc0 ---------- To fix this, ensure that tsk_in_cpu[tsk_index] != -1 before calling cpumask_clear_cpu() in exit_round_robin(), just as it is done in round_robin_cpu(). [ rjw: Subject edit, avoid updates to the same value ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49936", "url": "https://ubuntu.com/security/CVE-2024-49936", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/xen-netback: prevent UAF in xenvif_flush_hash() During the list_for_each_entry_rcu iteration call of xenvif_flush_hash, kfree_rcu does not exist inside the rcu read critical section, so if kfree_rcu is called when the rcu grace period ends during the iteration, UAF occurs when accessing head->next after the entry becomes free. Therefore, to solve this, you need to change it to list_for_each_entry_safe.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49937", "url": "https://ubuntu.com/security/CVE-2024-49937", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Set correct chandef when starting CAC When starting CAC in a mode other than AP mode, it return a \"WARNING: CPU: 0 PID: 63 at cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]\" caused by the chandef.chan being null at the end of CAC. Solution: Ensure the channel definition is set for the different modes when starting CAC to avoid getting a NULL 'chan' at the end of CAC. Call Trace: ? show_regs.part.0+0x14/0x16 ? __warn+0x67/0xc0 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? report_bug+0xa7/0x130 ? exc_overflow+0x30/0x30 ? handle_bug+0x27/0x50 ? exc_invalid_op+0x18/0x60 ? handle_exception+0xf6/0xf6 ? exc_overflow+0x30/0x30 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? exc_overflow+0x30/0x30 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? regulatory_propagate_dfs_state.cold+0x1b/0x4c [cfg80211] ? cfg80211_propagate_cac_done_wk+0x1a/0x30 [cfg80211] ? process_one_work+0x165/0x280 ? worker_thread+0x120/0x3f0 ? kthread+0xc2/0xf0 ? process_one_work+0x280/0x280 ? kthread_complete_and_exit+0x20/0x20 ? ret_from_fork+0x19/0x24 [shorten subject, remove OCB, reorder cases to match previous list]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49938", "url": "https://ubuntu.com/security/CVE-2024-49938", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmit Syzbot points out that skb_trim() has a sanity check on the existing length of the skb, which can be uninitialised in some error paths. The intent here is clearly just to reset the length to zero before resubmitting, so switch to calling __skb_set_length(skb, 0) directly. In addition, __skb_set_length() already contains a call to skb_reset_tail_pointer(), so remove the redundant call. The syzbot report came from ath9k_hif_usb_reg_in_cb(), but there's a similar usage of skb_trim() in ath9k_hif_usb_rx_cb(), change both while we're at it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49939", "url": "https://ubuntu.com/security/CVE-2024-49939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: avoid to add interface to list twice when SER If SER L2 occurs during the WoWLAN resume flow, the add interface flow is triggered by ieee80211_reconfig(). However, due to rtw89_wow_resume() return failure, it will cause the add interface flow to be executed again, resulting in a double add list and causing a kernel panic. Therefore, we have added a check to prevent double adding of the list. list_add double add: new=ffff99d6992e2010, prev=ffff99d6992e2010, next=ffff99d695302628. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:37! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G W O 6.6.30-02659-gc18865c4dfbd #1 770df2933251a0e3c888ba69d1053a817a6376a7 Hardware name: HP Grunt/Grunt, BIOS Google_Grunt.11031.169.0 06/24/2021 Workqueue: events_freezable ieee80211_restart_work [mac80211] RIP: 0010:__list_add_valid_or_report+0x5e/0xb0 Code: c7 74 18 48 39 ce 74 13 b0 01 59 5a 5e 5f 41 58 41 59 41 5a 5d e9 e2 d6 03 00 cc 48 c7 c7 8d 4f 17 83 48 89 c2 e8 02 c0 00 00 <0f> 0b 48 c7 c7 aa 8c 1c 83 e8 f4 bf 00 00 0f 0b 48 c7 c7 c8 bc 12 RSP: 0018:ffffa91b8007bc50 EFLAGS: 00010246 RAX: 0000000000000058 RBX: ffff99d6992e0900 RCX: a014d76c70ef3900 RDX: ffffa91b8007bae8 RSI: 00000000ffffdfff RDI: 0000000000000001 RBP: ffffa91b8007bc88 R08: 0000000000000000 R09: ffffa91b8007bae0 R10: 00000000ffffdfff R11: ffffffff83a79800 R12: ffff99d695302060 R13: ffff99d695300900 R14: ffff99d6992e1be0 R15: ffff99d6992e2010 FS: 0000000000000000(0000) GS:ffff99d6aac00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000078fbdba43480 CR3: 000000010e464000 CR4: 00000000001506f0 Call Trace: ? __die_body+0x1f/0x70 ? die+0x3d/0x60 ? do_trap+0xa4/0x110 ? __list_add_valid_or_report+0x5e/0xb0 ? do_error_trap+0x6d/0x90 ? __list_add_valid_or_report+0x5e/0xb0 ? handle_invalid_op+0x30/0x40 ? __list_add_valid_or_report+0x5e/0xb0 ? exc_invalid_op+0x3c/0x50 ? asm_exc_invalid_op+0x16/0x20 ? __list_add_valid_or_report+0x5e/0xb0 rtw89_ops_add_interface+0x309/0x310 [rtw89_core 7c32b1ee6854761c0321027c8a58c5160e41f48f] drv_add_interface+0x5c/0x130 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ieee80211_reconfig+0x241/0x13d0 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ? finish_wait+0x3e/0x90 ? synchronize_rcu_expedited+0x174/0x260 ? sync_rcu_exp_done_unlocked+0x50/0x50 ? wake_bit_function+0x40/0x40 ieee80211_restart_work+0xf0/0x140 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] process_scheduled_works+0x1e5/0x480 worker_thread+0xea/0x1e0 kthread+0xdb/0x110 ? move_linked_works+0x90/0x90 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork+0x3b/0x50 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork_asm+0x11/0x20 Modules linked in: dm_integrity async_xor xor async_tx lz4 lz4_compress zstd zstd_compress zram zsmalloc rfcomm cmac uinput algif_hash algif_skcipher af_alg btusb btrtl iio_trig_hrtimer industrialio_sw_trigger btmtk industrialio_configfs btbcm btintel uvcvideo videobuf2_vmalloc iio_trig_sysfs videobuf2_memops videobuf2_v4l2 videobuf2_common uvc snd_hda_codec_hdmi veth snd_hda_intel snd_intel_dspcfg acpi_als snd_hda_codec industrialio_triggered_buffer kfifo_buf snd_hwdep industrialio i2c_piix4 snd_hda_core designware_i2s ip6table_nat snd_soc_max98357a xt_MASQUERADE xt_cgroup snd_soc_acp_rt5682_mach fuse rtw89_8922ae(O) rtw89_8922a(O) rtw89_pci(O) rtw89_core(O) 8021q mac80211(O) bluetooth ecdh_generic ecc cfg80211 r8152 mii joydev gsmi: Log Shutdown Reason 0x03 ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49940", "url": "https://ubuntu.com/security/CVE-2024-49940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: prevent possible tunnel refcount underflow When a session is created, it sets a backpointer to its tunnel. When the session refcount drops to 0, l2tp_session_free drops the tunnel refcount if session->tunnel is non-NULL. However, session->tunnel is set in l2tp_session_create, before the tunnel refcount is incremented by l2tp_session_register, which leaves a small window where session->tunnel is non-NULL when the tunnel refcount hasn't been bumped. Moving the assignment to l2tp_session_register is trivial but l2tp_session_create calls l2tp_session_set_header_len which uses session->tunnel to get the tunnel's encap. Add an encap arg to l2tp_session_set_header_len to avoid using session->tunnel. If l2tpv3 sessions have colliding IDs, it is possible for l2tp_v3_session_get to race with l2tp_session_register and fetch a session which doesn't yet have session->tunnel set. Add a check for this case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49941", "url": "https://ubuntu.com/security/CVE-2024-49941", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpiolib: Fix potential NULL pointer dereference in gpiod_get_label() In `gpiod_get_label()`, it is possible that `srcu_dereference_check()` may return a NULL pointer, leading to a scenario where `label->str` is accessed without verifying if `label` itself is NULL. This patch adds a proper NULL check for `label` before accessing `label->str`. The check for `label->str != NULL` is removed because `label->str` can never be NULL if `label` is not NULL. This fixes the issue where the label name was being printed as `(efault)` when dumping the sysfs GPIO file when `label == NULL`.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49996", "url": "https://ubuntu.com/security/CVE-2024-49996", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: Fix buffer overflow when parsing NFS reparse points ReparseDataLength is sum of the InodeType size and DataBuffer size. So to get DataBuffer size it is needed to subtract InodeType's size from ReparseDataLength. Function cifs_strndup_from_utf16() is currentlly accessing buf->DataBuffer at position after the end of the buffer because it does not subtract InodeType size from the length. Fix this problem and correctly subtract variable len. Member InodeType is present only when reparse buffer is large enough. Check for ReparseDataLength before accessing InodeType to prevent another invalid memory access. Major and minor rdev values are present also only when reparse buffer is large enough. Check for reparse buffer size before calling reparse_mkdev().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49942", "url": "https://ubuntu.com/security/CVE-2024-49942", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Prevent null pointer access in xe_migrate_copy xe_migrate_copy designed to copy content of TTM resources. When source resource is null, it will trigger a NULL pointer dereference in xe_migrate_copy. To avoid this situation, update lacks source flag to true for this case, the flag will trigger xe_migrate_clear rather than xe_migrate_copy. Issue trace: <7> [317.089847] xe 0000:00:02.0: [drm:xe_migrate_copy [xe]] Pass 14, sizes: 4194304 & 4194304 <7> [317.089945] xe 0000:00:02.0: [drm:xe_migrate_copy [xe]] Pass 15, sizes: 4194304 & 4194304 <1> [317.128055] BUG: kernel NULL pointer dereference, address: 0000000000000010 <1> [317.128064] #PF: supervisor read access in kernel mode <1> [317.128066] #PF: error_code(0x0000) - not-present page <6> [317.128069] PGD 0 P4D 0 <4> [317.128071] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI <4> [317.128074] CPU: 1 UID: 0 PID: 1440 Comm: kunit_try_catch Tainted: G U N 6.11.0-rc7-xe #1 <4> [317.128078] Tainted: [U]=USER, [N]=TEST <4> [317.128080] Hardware name: Intel Corporation Lunar Lake Client Platform/LNL-M LP5 RVP1, BIOS LNLMFWI1.R00.3221.D80.2407291239 07/29/2024 <4> [317.128082] RIP: 0010:xe_migrate_copy+0x66/0x13e0 [xe] <4> [317.128158] Code: 00 00 48 89 8d e0 fe ff ff 48 8b 40 10 4c 89 85 c8 fe ff ff 44 88 8d bd fe ff ff 65 48 8b 3c 25 28 00 00 00 48 89 7d d0 31 ff <8b> 79 10 48 89 85 a0 fe ff ff 48 8b 00 48 89 b5 d8 fe ff ff 83 ff <4> [317.128162] RSP: 0018:ffffc9000167f9f0 EFLAGS: 00010246 <4> [317.128164] RAX: ffff8881120d8028 RBX: ffff88814d070428 RCX: 0000000000000000 <4> [317.128166] RDX: ffff88813cb99c00 RSI: 0000000004000000 RDI: 0000000000000000 <4> [317.128168] RBP: ffffc9000167fbb8 R08: ffff88814e7b1f08 R09: 0000000000000001 <4> [317.128170] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88814e7b1f08 <4> [317.128172] R13: ffff88814e7b1f08 R14: ffff88813cb99c00 R15: 0000000000000001 <4> [317.128174] FS: 0000000000000000(0000) GS:ffff88846f280000(0000) knlGS:0000000000000000 <4> [317.128176] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [317.128178] CR2: 0000000000000010 CR3: 000000011f676004 CR4: 0000000000770ef0 <4> [317.128180] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 <4> [317.128182] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400 <4> [317.128184] PKRU: 55555554 <4> [317.128185] Call Trace: <4> [317.128187] <4> [317.128189] ? show_regs+0x67/0x70 <4> [317.128194] ? __die_body+0x20/0x70 <4> [317.128196] ? __die+0x2b/0x40 <4> [317.128198] ? page_fault_oops+0x15f/0x4e0 <4> [317.128203] ? do_user_addr_fault+0x3fb/0x970 <4> [317.128205] ? lock_acquire+0xc7/0x2e0 <4> [317.128209] ? exc_page_fault+0x87/0x2b0 <4> [317.128212] ? asm_exc_page_fault+0x27/0x30 <4> [317.128216] ? xe_migrate_copy+0x66/0x13e0 [xe] <4> [317.128263] ? __lock_acquire+0xb9d/0x26f0 <4> [317.128265] ? __lock_acquire+0xb9d/0x26f0 <4> [317.128267] ? sg_free_append_table+0x20/0x80 <4> [317.128271] ? lock_acquire+0xc7/0x2e0 <4> [317.128273] ? mark_held_locks+0x4d/0x80 <4> [317.128275] ? trace_hardirqs_on+0x1e/0xd0 <4> [317.128278] ? _raw_spin_unlock_irqrestore+0x31/0x60 <4> [317.128281] ? __pm_runtime_resume+0x60/0xa0 <4> [317.128284] xe_bo_move+0x682/0xc50 [xe] <4> [317.128315] ? lock_is_held_type+0xaa/0x120 <4> [317.128318] ttm_bo_handle_move_mem+0xe5/0x1a0 [ttm] <4> [317.128324] ttm_bo_validate+0xd1/0x1a0 [ttm] <4> [317.128328] shrink_test_run_device+0x721/0xc10 [xe] <4> [317.128360] ? find_held_lock+0x31/0x90 <4> [317.128363] ? lock_release+0xd1/0x2a0 <4> [317.128365] ? __pfx_kunit_generic_run_threadfn_adapter+0x10/0x10 [kunit] <4> [317.128370] xe_bo_shrink_kunit+0x11/0x20 [xe] <4> [317.128397] kunit_try_run_case+0x6e/0x150 [kunit] <4> [317.128400] ? trace_hardirqs_on+0x1e/0xd0 <4> [317.128402] ? _raw_spin_unlock_irqrestore+0x31/0x60 <4> [317.128404] kunit_generic_run_threadfn_adapter+0x1e/0x40 [ku ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49943", "url": "https://ubuntu.com/security/CVE-2024-49943", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc_submit: add missing locking in wedged_fini Any non-wedged queue can have a zero refcount here and can be running concurrently with an async queue destroy, therefore dereferencing the queue ptr to check wedge status after the lookup can trigger UAF if queue is not wedged. Fix this by keeping the submission_state lock held around the check to postpone the free and make the check safe, before dropping again around the put() to avoid the deadlock. (cherry picked from commit d28af0b6b9580b9f90c265a7da0315b0ad20bbfd)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50011", "url": "https://ubuntu.com/security/CVE-2024-50011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: soc-acpi-intel-rpl-match: add missing empty item There is no links_num in struct snd_soc_acpi_mach {}, and we test !link->num_adr as a condition to end the loop in hda_sdw_machine_select(). So an empty item in struct snd_soc_acpi_link_adr array is required.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50174", "url": "https://ubuntu.com/security/CVE-2024-50174", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix race when converting group handle to group object XArray provides it's own internal lock which protects the internal array when entries are being simultaneously added and removed. However there is still a race between retrieving the pointer from the XArray and incrementing the reference count. To avoid this race simply hold the internal XArray lock when incrementing the reference count, this ensures there cannot be a racing call to xa_erase().", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49944", "url": "https://ubuntu.com/security/CVE-2024-49944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_start In sctp_listen_start() invoked by sctp_inet_listen(), it should set the sk_state back to CLOSED if sctp_autobind() fails due to whatever reason. Otherwise, next time when calling sctp_inet_listen(), if sctp_sk(sk)->reuse is already set via setsockopt(SCTP_REUSE_PORT), sctp_sk(sk)->bind_hash will be dereferenced as sk_state is LISTENING, which causes a crash as bind_hash is NULL. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:sctp_inet_listen+0x7f0/0xa20 net/sctp/socket.c:8617 Call Trace: __sys_listen_socket net/socket.c:1883 [inline] __sys_listen+0x1b7/0x230 net/socket.c:1894 __do_sys_listen net/socket.c:1902 [inline]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49945", "url": "https://ubuntu.com/security/CVE-2024-49945", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/ncsi: Disable the ncsi work before freeing the associated structure The work function can run after the ncsi device is freed, resulting in use-after-free bugs or kernel panic.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49946", "url": "https://ubuntu.com/security/CVE-2024-49946", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: do not assume bh is held in ppp_channel_bridge_input() Networking receive path is usually handled from BH handler. However, some protocols need to acquire the socket lock, and packets might be stored in the socket backlog is the socket was owned by a user process. In this case, release_sock(), __release_sock(), and sk_backlog_rcv() might call the sk->sk_backlog_rcv() handler in process context. sybot caught ppp was not considering this case in ppp_channel_bridge_input() : WARNING: inconsistent lock state 6.11.0-rc7-syzkaller-g5f5673607153 #0 Not tainted -------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. ksoftirqd/1/24 [HC0[0]:SC1[1]:HE1:SE0] takes: ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 {SOFTIRQ-ON-W} state was registered at: lock_acquire+0x240/0x728 kernel/locking/lockdep.c:5759 __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline] _raw_spin_lock+0x48/0x60 kernel/locking/spinlock.c:154 spin_lock include/linux/spinlock.h:351 [inline] ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline] ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0xfc/0x314 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv include/net/sock.h:1111 [inline] __release_sock+0x1a8/0x3d8 net/core/sock.c:3004 release_sock+0x68/0x1b8 net/core/sock.c:3558 pppoe_sendmsg+0xc8/0x5d8 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x374/0x4f4 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __arm64_sys_sendto+0xd8/0xf8 net/socket.c:2212 __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:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 irq event stamp: 282914 hardirqs last enabled at (282914): [] __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:151 [inline] hardirqs last enabled at (282914): [] _raw_spin_unlock_irqrestore+0x38/0x98 kernel/locking/spinlock.c:194 hardirqs last disabled at (282913): [] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline] hardirqs last disabled at (282913): [] _raw_spin_lock_irqsave+0x2c/0x7c kernel/locking/spinlock.c:162 softirqs last enabled at (282904): [] softirq_handle_end kernel/softirq.c:400 [inline] softirqs last enabled at (282904): [] handle_softirqs+0xa3c/0xbfc kernel/softirq.c:582 softirqs last disabled at (282909): [] run_ksoftirqd+0x70/0x158 kernel/softirq.c:928 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&pch->downl); lock(&pch->downl); *** DEADLOCK *** 1 lock held by ksoftirqd/1/24: #0: ffff80008f74dfa0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire+0x10/0x4c include/linux/rcupdate.h:325 stack backtrace: CPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 6.11.0-rc7-syzkaller-g5f5673607153 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call trace: dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:319 show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:326 __dump_sta ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49947", "url": "https://ubuntu.com/security/CVE-2024-49947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: test for not too small csum_start in virtio_net_hdr_to_skb() syzbot was able to trigger this warning [1], after injecting a malicious packet through af_packet, setting skb->csum_start and thus the transport header to an incorrect value. We can at least make sure the transport header is after the end of the network header (with a estimated minimal size). [1] [ 67.873027] skb len=4096 headroom=16 headlen=14 tailroom=0 mac=(-1,-1) mac_len=0 net=(16,-6) trans=10 shinfo(txflags=0 nr_frags=1 gso(size=0 type=0 segs=0)) csum(0xa start=10 offset=0 ip_summed=3 complete_sw=0 valid=0 level=0) hash(0x0 sw=0 l4=0) proto=0x0800 pkttype=0 iif=0 priority=0x0 mark=0x0 alloc_cpu=10 vlan_all=0x0 encapsulation=0 inner(proto=0x0000, mac=0, net=0, trans=0) [ 67.877172] dev name=veth0_vlan feat=0x000061164fdd09e9 [ 67.877764] sk family=17 type=3 proto=0 [ 67.878279] skb linear: 00000000: 00 00 10 00 00 00 00 00 0f 00 00 00 08 00 [ 67.879128] skb frag: 00000000: 0e 00 07 00 00 00 28 00 08 80 1c 00 04 00 00 02 [ 67.879877] skb frag: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.880647] skb frag: 00000020: 00 00 02 00 00 00 08 00 1b 00 00 00 00 00 00 00 [ 67.881156] skb frag: 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.881753] skb frag: 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.882173] skb frag: 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.882790] skb frag: 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.883171] skb frag: 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.883733] skb frag: 00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.884206] skb frag: 00000090: 00 00 00 00 00 00 00 00 00 00 69 70 76 6c 61 6e [ 67.884704] skb frag: 000000a0: 31 00 00 00 00 00 00 00 00 00 2b 00 00 00 00 00 [ 67.885139] skb frag: 000000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.885677] skb frag: 000000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.886042] skb frag: 000000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.886408] skb frag: 000000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.887020] skb frag: 000000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.887384] skb frag: 00000100: 00 00 [ 67.887878] ------------[ cut here ]------------ [ 67.887908] offset (-6) >= skb_headlen() (14) [ 67.888445] WARNING: CPU: 10 PID: 2088 at net/core/dev.c:3332 skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.889353] Modules linked in: macsec macvtap macvlan hsr wireguard curve25519_x86_64 libcurve25519_generic libchacha20poly1305 chacha_x86_64 libchacha poly1305_x86_64 dummy bridge sr_mod cdrom evdev pcspkr i2c_piix4 9pnet_virtio 9p 9pnet netfs [ 67.890111] CPU: 10 UID: 0 PID: 2088 Comm: b363492833 Not tainted 6.11.0-virtme #1011 [ 67.890183] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 67.890309] RIP: 0010:skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891043] Call Trace: [ 67.891173] [ 67.891274] ? __warn (kernel/panic.c:741) [ 67.891320] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891333] ? report_bug (lib/bug.c:180 lib/bug.c:219) [ 67.891348] ? handle_bug (arch/x86/kernel/traps.c:239) [ 67.891363] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) [ 67.891372] ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621) [ 67.891388] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891399] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891416] ip_do_fragment (net/ipv4/ip_output.c:777 (discriminator 1)) [ 67.891448] ? __ip_local_out (./include/linux/skbuff.h:1146 ./include/net/l3mdev.h:196 ./include/net/l3mdev.h:213 ne ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49948", "url": "https://ubuntu.com/security/CVE-2024-49948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: add more sanity checks to qdisc_pkt_len_init() One path takes care of SKB_GSO_DODGY, assuming skb->len is bigger than hdr_len. virtio_net_hdr_to_skb() does not fully dissect TCP headers, it only make sure it is at least 20 bytes. It is possible for an user to provide a malicious 'GSO' packet, total length of 80 bytes. - 20 bytes of IPv4 header - 60 bytes TCP header - a small gso_size like 8 virtio_net_hdr_to_skb() would declare this packet as a normal GSO packet, because it would see 40 bytes of payload, bigger than gso_size. We need to make detect this case to not underflow qdisc_skb_cb(skb)->pkt_len.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49949", "url": "https://ubuntu.com/security/CVE-2024-49949", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: avoid potential underflow in qdisc_pkt_len_init() with UFO After commit 7c6d2ecbda83 (\"net: be more gentle about silly gso requests coming from user\") virtio_net_hdr_to_skb() had sanity check to detect malicious attempts from user space to cook a bad GSO packet. Then commit cf9acc90c80ec (\"net: virtio_net_hdr_to_skb: count transport header in UFO\") while fixing one issue, allowed user space to cook a GSO packet with the following characteristic : IPv4 SKB_GSO_UDP, gso_size=3, skb->len = 28. When this packet arrives in qdisc_pkt_len_init(), we end up with hdr_len = 28 (IPv4 header + UDP header), matching skb->len Then the following sets gso_segs to 0 : gso_segs = DIV_ROUND_UP(skb->len - hdr_len, shinfo->gso_size); Then later we set qdisc_skb_cb(skb)->pkt_len to back to zero :/ qdisc_skb_cb(skb)->pkt_len += (gso_segs - 1) * hdr_len; This leads to the following crash in fq_codel [1] qdisc_pkt_len_init() is best effort, we only want an estimation of the bytes sent on the wire, not crashing the kernel. This patch is fixing this particular issue, a following one adds more sanity checks for another potential bug. [1] [ 70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 70.724561] #PF: supervisor read access in kernel mode [ 70.724561] #PF: error_code(0x0000) - not-present page [ 70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0 [ 70.724561] Oops: Oops: 0000 [#1] SMP NOPTI [ 70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991 [ 70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel [ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 <49> 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49 All code ======== 0:\t24 08 \tand $0x8,%al 2:\t49 c1 e1 06 \tshl $0x6,%r9 6:\t44 89 7c 24 18 \tmov %r15d,0x18(%rsp) b:\t45 31 ed \txor %r13d,%r13d e:\t45 31 c0 \txor %r8d,%r8d 11:\t31 ff \txor %edi,%edi 13:\t89 44 24 14 \tmov %eax,0x14(%rsp) 17:\t4c 03 8b 90 01 00 00 \tadd 0x190(%rbx),%r9 1e:\teb 04 \tjmp 0x24 20:\t39 ca \tcmp %ecx,%edx 22:\t73 37 \tjae 0x5b 24:\t4d 8b 39 \tmov (%r9),%r15 27:\t83 c7 01 \tadd $0x1,%edi 2a:*\t49 8b 17 \tmov (%r15),%rdx\t\t<-- trapping instruction 2d:\t49 89 11 \tmov %rdx,(%r9) 30:\t41 8b 57 28 \tmov 0x28(%r15),%edx 34:\t45 8b 5f 34 \tmov 0x34(%r15),%r11d 38:\t49 c7 07 00 00 00 00 \tmovq $0x0,(%r15) 3f:\t49 \trex.WB Code starting with the faulting instruction =========================================== 0:\t49 8b 17 \tmov (%r15),%rdx 3:\t49 89 11 \tmov %rdx,(%r9) 6:\t41 8b 57 28 \tmov 0x28(%r15),%edx a:\t45 8b 5f 34 \tmov 0x34(%r15),%r11d e:\t49 c7 07 00 00 00 00 \tmovq $0x0,(%r15) 15:\t49 \trex.WB [ 70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202 [ 70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000 [ 70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001 [ 70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000 [ 70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58 [ 70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000 [ 70.724561] FS: 000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000 [ 70.724561] CS: 0010 DS: 0000 ES: 0000 C ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49997", "url": "https://ubuntu.com/security/CVE-2024-49997", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: lantiq_etop: fix memory disclosure When applying padding, the buffer is not zeroed, which results in memory disclosure. The mentioned data is observed on the wire. This patch uses skb_put_padto() to pad Ethernet frames properly. The mentioned function zeroes the expanded buffer. In case the packet cannot be padded it is silently dropped. Statistics are also not incremented. This driver does not support statistics in the old 32-bit format or the new 64-bit format. These will be added in the future. In its current form, the patch should be easily backported to stable versions. Ethernet MACs on Amazon-SE and Danube cannot do padding of the packets in hardware, so software padding must be applied.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49998", "url": "https://ubuntu.com/security/CVE-2024-49998", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: improve shutdown sequence Alexander Sverdlin presents 2 problems during shutdown with the lan9303 driver. One is specific to lan9303 and the other just happens to reproduce there. The first problem is that lan9303 is unique among DSA drivers in that it calls dev_get_drvdata() at \"arbitrary runtime\" (not probe, not shutdown, not remove): phy_state_machine() -> ... -> dsa_user_phy_read() -> ds->ops->phy_read() -> lan9303_phy_read() -> chip->ops->phy_read() -> lan9303_mdio_phy_read() -> dev_get_drvdata() But we never stop the phy_state_machine(), so it may continue to run after dsa_switch_shutdown(). Our common pattern in all DSA drivers is to set drvdata to NULL to suppress the remove() method that may come afterwards. But in this case it will result in an NPD. The second problem is that the way in which we set dp->conduit->dsa_ptr = NULL; is concurrent with receive packet processing. dsa_switch_rcv() checks once whether dev->dsa_ptr is NULL, but afterwards, rather than continuing to use that non-NULL value, dev->dsa_ptr is dereferenced again and again without NULL checks: dsa_conduit_find_user() and many other places. In between dereferences, there is no locking to ensure that what was valid once continues to be valid. Both problems have the common aspect that closing the conduit interface solves them. In the first case, dev_close(conduit) triggers the NETDEV_GOING_DOWN event in dsa_user_netdevice_event() which closes user ports as well. dsa_port_disable_rt() calls phylink_stop(), which synchronously stops the phylink state machine, and ds->ops->phy_read() will thus no longer call into the driver after this point. In the second case, dev_close(conduit) should do this, as per Documentation/networking/driver.rst: | Quiescence | ---------- | | After the ndo_stop routine has been called, the hardware must | not receive or transmit any data. All in flight packets must | be aborted. If necessary, poll or wait for completion of | any reset commands. So it should be sufficient to ensure that later, when we zeroize conduit->dsa_ptr, there will be no concurrent dsa_switch_rcv() call on this conduit. The addition of the netif_device_detach() function is to ensure that ioctls, rtnetlinks and ethtool requests on the user ports no longer propagate down to the driver - we're no longer prepared to handle them. The race condition actually did not exist when commit 0650bf52b31f (\"net: dsa: be compatible with masters which unregister on shutdown\") first introduced dsa_switch_shutdown(). It was created later, when we stopped unregistering the user interfaces from a bad spot, and we just replaced that sequence with a racy zeroization of conduit->dsa_ptr (one which doesn't ensure that the interfaces aren't up).", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49999", "url": "https://ubuntu.com/security/CVE-2024-49999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix the setting of the server responding flag In afs_wait_for_operation(), we set transcribe the call responded flag to the server record that we used after doing the fileserver iteration loop - but it's possible to exit the loop having had a response from the server that we've discarded (e.g. it returned an abort or we started receiving data, but the call didn't complete). This means that op->server might be NULL, but we don't check that before attempting to set the server flag.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49950", "url": "https://ubuntu.com/security/CVE-2024-49950", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix uaf in l2cap_connect [Syzbot reported] BUG: KASAN: slab-use-after-free in l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 Read of size 8 at addr ffff8880241e9800 by task kworker/u9:0/54 CPU: 0 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-00268-g788220eee30d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Workqueue: hci2 hci_rx_work Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 l2cap_connect_req net/bluetooth/l2cap_core.c:4080 [inline] l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:4772 [inline] l2cap_sig_channel net/bluetooth/l2cap_core.c:5543 [inline] l2cap_recv_frame+0xf0b/0x8eb0 net/bluetooth/l2cap_core.c:6825 l2cap_recv_acldata+0x9b4/0xb70 net/bluetooth/l2cap_core.c:7514 hci_acldata_packet net/bluetooth/hci_core.c:3791 [inline] hci_rx_work+0xaab/0x1610 net/bluetooth/hci_core.c:4028 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 ... Freed by task 5245: 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:579 poison_slab_object+0xf7/0x160 mm/kasan/common.c:240 __kasan_slab_free+0x32/0x50 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2256 [inline] slab_free mm/slub.c:4477 [inline] kfree+0x12a/0x3b0 mm/slub.c:4598 l2cap_conn_free net/bluetooth/l2cap_core.c:1810 [inline] kref_put include/linux/kref.h:65 [inline] l2cap_conn_put net/bluetooth/l2cap_core.c:1822 [inline] l2cap_conn_del+0x59d/0x730 net/bluetooth/l2cap_core.c:1802 l2cap_connect_cfm+0x9e6/0xf80 net/bluetooth/l2cap_core.c:7241 hci_connect_cfm include/net/bluetooth/hci_core.h:1960 [inline] hci_conn_failed+0x1c3/0x370 net/bluetooth/hci_conn.c:1265 hci_abort_conn_sync+0x75a/0xb50 net/bluetooth/hci_sync.c:5583 abort_conn_sync+0x197/0x360 net/bluetooth/hci_conn.c:2917 hci_cmd_sync_work+0x1a4/0x410 net/bluetooth/hci_sync.c:328 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49951", "url": "https://ubuntu.com/security/CVE-2024-49951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Fix possible crash on mgmt_index_removed If mgmt_index_removed is called while there are commands queued on cmd_sync it could lead to crashes like the bellow trace: 0x0000053D: __list_del_entry_valid_or_report+0x98/0xdc 0x0000053D: mgmt_pending_remove+0x18/0x58 [bluetooth] 0x0000053E: mgmt_remove_adv_monitor_complete+0x80/0x108 [bluetooth] 0x0000053E: hci_cmd_sync_work+0xbc/0x164 [bluetooth] So while handling mgmt_index_removed this attempts to dequeue commands passed as user_data to cmd_sync.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49952", "url": "https://ubuntu.com/security/CVE-2024-49952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: prevent nf_skb_duplicated corruption syzbot found that nf_dup_ipv4() or nf_dup_ipv6() could write per-cpu variable nf_skb_duplicated in an unsafe way [1]. Disabling preemption as hinted by the splat is not enough, we have to disable soft interrupts as well. [1] BUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316 caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49 nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook+0x2c4/0x450 include/linux/netfilter.h:269 NF_HOOK_COND include/linux/netfilter.h:302 [inline] ip_output+0x185/0x230 net/ipv4/ip_output.c:433 ip_local_out net/ipv4/ip_output.c:129 [inline] ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495 udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981 udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737 __do_sys_sendmmsg net/socket.c:2766 [inline] __se_sys_sendmmsg net/socket.c:2763 [inline] __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763 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:0x7f4ce4f7def9 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:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9 RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006 RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49953", "url": "https://ubuntu.com/security/CVE-2024-49953", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix crash caused by calling __xfrm_state_delete() twice The km.state is not checked in driver's delayed work. When xfrm_state_check_expire() is called, the state can be reset to XFRM_STATE_EXPIRED, even if it is XFRM_STATE_DEAD already. This happens when xfrm state is deleted, but not freed yet. As __xfrm_state_delete() is called again in xfrm timer, the following crash occurs. To fix this issue, skip xfrm_state_check_expire() if km.state is not XFRM_STATE_VALID. Oops: general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] SMP CPU: 5 UID: 0 PID: 7448 Comm: kworker/u102:2 Not tainted 6.11.0-rc2+ #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5e_ipsec: eth%d mlx5e_ipsec_handle_sw_limits [mlx5_core] RIP: 0010:__xfrm_state_delete+0x3d/0x1b0 Code: 0f 84 8b 01 00 00 48 89 fd c6 87 c8 00 00 00 05 48 8d bb 40 10 00 00 e8 11 04 1a 00 48 8b 95 b8 00 00 00 48 8b 85 c0 00 00 00 <48> 89 42 08 48 89 10 48 8b 55 10 48 b8 00 01 00 00 00 00 ad de 48 RSP: 0018:ffff88885f945ec8 EFLAGS: 00010246 RAX: dead000000000122 RBX: ffffffff82afa940 RCX: 0000000000000036 RDX: dead000000000100 RSI: 0000000000000000 RDI: ffffffff82afb980 RBP: ffff888109a20340 R08: ffff88885f945ea0 R09: 0000000000000000 R10: 0000000000000000 R11: ffff88885f945ff8 R12: 0000000000000246 R13: ffff888109a20340 R14: ffff88885f95f420 R15: ffff88885f95f400 FS: 0000000000000000(0000) GS:ffff88885f940000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2163102430 CR3: 00000001128d6001 CR4: 0000000000370eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? die_addr+0x33/0x90 ? exc_general_protection+0x1a2/0x390 ? asm_exc_general_protection+0x22/0x30 ? __xfrm_state_delete+0x3d/0x1b0 ? __xfrm_state_delete+0x2f/0x1b0 xfrm_timer_handler+0x174/0x350 ? __xfrm_state_delete+0x1b0/0x1b0 __hrtimer_run_queues+0x121/0x270 hrtimer_run_softirq+0x88/0xd0 handle_softirqs+0xcc/0x270 do_softirq+0x3c/0x50 __local_bh_enable_ip+0x47/0x50 mlx5e_ipsec_handle_sw_limits+0x7d/0x90 [mlx5_core] process_one_work+0x137/0x2d0 worker_thread+0x28d/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50000", "url": "https://ubuntu.com/security/CVE-2024-50000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix NULL deref in mlx5e_tir_builder_alloc() In mlx5e_tir_builder_alloc() kvzalloc() may return NULL which is dereferenced on the next line in a reference to the modify field. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50001", "url": "https://ubuntu.com/security/CVE-2024-50001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix error path in multi-packet WQE transmit Remove the erroneous unmap in case no DMA mapping was established The multi-packet WQE transmit code attempts to obtain a DMA mapping for the skb. This could fail, e.g. under memory pressure, when the IOMMU driver just can't allocate more memory for page tables. While the code tries to handle this in the path below the err_unmap label it erroneously unmaps one entry from the sq's FIFO list of active mappings. Since the current map attempt failed this unmap is removing some random DMA mapping that might still be required. If the PCI function now presents that IOVA, the IOMMU may assumes a rogue DMA access and e.g. on s390 puts the PCI function in error state. The erroneous behavior was seen in a stress-test environment that created memory pressure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50179", "url": "https://ubuntu.com/security/CVE-2024-50179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: remove the incorrect Fw reference check when dirtying pages When doing the direct-io reads it will also try to mark pages dirty, but for the read path it won't hold the Fw caps and there is case will it get the Fw reference.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49963", "url": "https://ubuntu.com/security/CVE-2024-49963", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mailbox: bcm2835: Fix timeout during suspend mode During noirq suspend phase the Raspberry Pi power driver suffer of firmware property timeouts. The reason is that the IRQ of the underlying BCM2835 mailbox is disabled and rpi_firmware_property_list() will always run into a timeout [1]. Since the VideoCore side isn't consider as a wakeup source, set the IRQF_NO_SUSPEND flag for the mailbox IRQ in order to keep it enabled during suspend-resume cycle. [1] PM: late suspend of devices complete after 1.754 msecs WARNING: CPU: 0 PID: 438 at drivers/firmware/raspberrypi.c:128 rpi_firmware_property_list+0x204/0x22c Firmware transaction 0x00028001 timeout Modules linked in: CPU: 0 PID: 438 Comm: bash Tainted: G C 6.9.3-dirty #17 Hardware name: BCM2835 Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x44 dump_stack_lvl from __warn+0x88/0xec __warn from warn_slowpath_fmt+0x7c/0xb0 warn_slowpath_fmt from rpi_firmware_property_list+0x204/0x22c rpi_firmware_property_list from rpi_firmware_property+0x68/0x8c rpi_firmware_property from rpi_firmware_set_power+0x54/0xc0 rpi_firmware_set_power from _genpd_power_off+0xe4/0x148 _genpd_power_off from genpd_sync_power_off+0x7c/0x11c genpd_sync_power_off from genpd_finish_suspend+0xcc/0xe0 genpd_finish_suspend from dpm_run_callback+0x78/0xd0 dpm_run_callback from device_suspend_noirq+0xc0/0x238 device_suspend_noirq from dpm_suspend_noirq+0xb0/0x168 dpm_suspend_noirq from suspend_devices_and_enter+0x1b8/0x5ac suspend_devices_and_enter from pm_suspend+0x254/0x2e4 pm_suspend from state_store+0xa8/0xd4 state_store from kernfs_fop_write_iter+0x154/0x1a0 kernfs_fop_write_iter from vfs_write+0x12c/0x184 vfs_write from ksys_write+0x78/0xc0 ksys_write from ret_fast_syscall+0x0/0x54 Exception stack(0xcc93dfa8 to 0xcc93dff0) [...] PM: noirq suspend of devices complete after 3095.584 msecs", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49954", "url": "https://ubuntu.com/security/CVE-2024-49954", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: static_call: Replace pointless WARN_ON() in static_call_module_notify() static_call_module_notify() triggers a WARN_ON(), when memory allocation fails in __static_call_add_module(). That's not really justified, because the failure case must be correctly handled by the well known call chain and the error code is passed through to the initiating userspace application. A memory allocation fail is not a fatal problem, but the WARN_ON() takes the machine out when panic_on_warn is set. Replace it with a pr_warn().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50002", "url": "https://ubuntu.com/security/CVE-2024-50002", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: static_call: Handle module init failure correctly in static_call_del_module() Module insertion invokes static_call_add_module() to initialize the static calls in a module. static_call_add_module() invokes __static_call_init(), which allocates a struct static_call_mod to either encapsulate the built-in static call sites of the associated key into it so further modules can be added or to append the module to the module chain. If that allocation fails the function returns with an error code and the module core invokes static_call_del_module() to clean up eventually added static_call_mod entries. This works correctly, when all keys used by the module were converted over to a module chain before the failure. If not then static_call_del_module() causes a #GP as it blindly assumes that key::mods points to a valid struct static_call_mod. The problem is that key::mods is not a individual struct member of struct static_call_key, it's part of a union to save space: union { /* bit 0: 0 = mods, 1 = sites */ unsigned long type; struct static_call_mod *mods; struct static_call_site *sites; \t}; key::sites is a pointer to the list of built-in usage sites of the static call. The type of the pointer is differentiated by bit 0. A mods pointer has the bit clear, the sites pointer has the bit set. As static_call_del_module() blidly assumes that the pointer is a valid static_call_mod type, it fails to check for this failure case and dereferences the pointer to the list of built-in call sites, which is obviously bogus. Cure it by checking whether the key has a sites or a mods pointer. If it's a sites pointer then the key is not to be touched. As the sites are walked in the same order as in __static_call_init() the site walk can be terminated because all subsequent sites have not been touched by the init code due to the error exit. If it was converted before the allocation fail, then the inner loop which searches for a module match will find nothing. A fail in the second allocation in __static_call_init() is harmless and does not require special treatment. The first allocation succeeded and converted the key to a module chain. That first entry has mod::mod == NULL and mod::next == NULL, so the inner loop of static_call_del_module() will neither find a module match nor a module chain. The next site in the walk was either already converted, but can't match the module, or it will exit the outer loop because it has a static_call_site pointer and not a static_call_mod pointer.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-47675", "url": "https://ubuntu.com/security/CVE-2024-47675", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix use-after-free in bpf_uprobe_multi_link_attach() If bpf_link_prime() fails, bpf_uprobe_multi_link_attach() goes to the error_free label and frees the array of bpf_uprobe's without calling bpf_uprobe_unregister(). This leaks bpf_uprobe->uprobe and worse, this frees bpf_uprobe->consumer without removing it from the uprobe->consumers list.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47676", "url": "https://ubuntu.com/security/CVE-2024-47676", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb.c: fix UAF of vma in hugetlb fault pathway Syzbot reports a UAF in hugetlb_fault(). This happens because vmf_anon_prepare() could drop the per-VMA lock and allow the current VMA to be freed before hugetlb_vma_unlock_read() is called. We can fix this by using a modified version of vmf_anon_prepare() that doesn't release the VMA lock on failure, and then release it ourselves after hugetlb_vma_unlock_read().", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47677", "url": "https://ubuntu.com/security/CVE-2024-47677", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: resolve memory leak from exfat_create_upcase_table() If exfat_load_upcase_table reaches end and returns -EINVAL, allocated memory doesn't get freed and while exfat_load_default_upcase_table allocates more memory, leading to a memory leak. Here's link to syzkaller crash report illustrating this issue: https://syzkaller.appspot.com/text?tag=CrashReport&x=1406c201980000", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47725", "url": "https://ubuntu.com/security/CVE-2024-47725", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47739", "url": "https://ubuntu.com/security/CVE-2024-47739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: padata: use integer wrap around to prevent deadlock on seq_nr overflow When submitting more than 2^32 padata objects to padata_do_serial, the current sorting implementation incorrectly sorts padata objects with overflowed seq_nr, causing them to be placed before existing objects in the reorder list. This leads to a deadlock in the serialization process as padata_find_next cannot match padata->seq_nr and pd->processed because the padata instance with overflowed seq_nr will be selected next. To fix this, we use an unsigned integer wrap around to correctly sort padata objects in scenarios with integer overflow.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47678", "url": "https://ubuntu.com/security/CVE-2024-47678", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: icmp: change the order of rate limits ICMP messages are ratelimited : After the blamed commits, the two rate limiters are applied in this order: 1) host wide ratelimit (icmp_global_allow()) 2) Per destination ratelimit (inetpeer based) In order to avoid side-channels attacks, we need to apply the per destination check first. This patch makes the following change : 1) icmp_global_allow() checks if the host wide limit is reached. But credits are not yet consumed. This is deferred to 3) 2) The per destination limit is checked/updated. This might add a new node in inetpeer tree. 3) icmp_global_consume() consumes tokens if prior operations succeeded. This means that host wide ratelimit is still effective in keeping inetpeer tree small even under DDOS. As a bonus, I removed icmp_global.lock as the fast path can use a lock-free operation.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47733", "url": "https://ubuntu.com/security/CVE-2024-47733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfs: Delete subtree of 'fs/netfs' when netfs module exits In netfs_init() or fscache_proc_init(), we create dentry under 'fs/netfs', but in netfs_exit(), we only delete the proc entry of 'fs/netfs' without deleting its subtree. This triggers the following WARNING: ================================================================== remove_proc_entry: removing non-empty directory 'fs/netfs', leaking at least 'requests' WARNING: CPU: 4 PID: 566 at fs/proc/generic.c:717 remove_proc_entry+0x160/0x1c0 Modules linked in: netfs(-) CPU: 4 UID: 0 PID: 566 Comm: rmmod Not tainted 6.11.0-rc3 #860 RIP: 0010:remove_proc_entry+0x160/0x1c0 Call Trace: netfs_exit+0x12/0x620 [netfs] __do_sys_delete_module.isra.0+0x14c/0x2e0 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e ================================================================== Therefore use remove_proc_subtree() instead of remove_proc_entry() to fix the above problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47679", "url": "https://ubuntu.com/security/CVE-2024-47679", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfs: fix race between evice_inodes() and find_inode()&iput() Hi, all Recently I noticed a bug[1] in btrfs, after digged it into and I believe it'a race in vfs. Let's assume there's a inode (ie ino 261) with i_count 1 is called by iput(), and there's a concurrent thread calling generic_shutdown_super(). cpu0: cpu1: iput() // i_count is 1 ->spin_lock(inode) ->dec i_count to 0 ->iput_final() generic_shutdown_super() ->__inode_add_lru() ->evict_inodes() // cause some reason[2] ->if (atomic_read(inode->i_count)) continue; // return before // inode 261 passed the above check // list_lru_add_obj() // and then schedule out ->spin_unlock() // note here: the inode 261 // was still at sb list and hash list, // and I_FREEING|I_WILL_FREE was not been set btrfs_iget() // after some function calls ->find_inode() // found the above inode 261 ->spin_lock(inode) // check I_FREEING|I_WILL_FREE // and passed ->__iget() ->spin_unlock(inode) // schedule back ->spin_lock(inode) // check (I_NEW|I_FREEING|I_WILL_FREE) flags, // passed and set I_FREEING iput() ->spin_unlock(inode) ->spin_lock(inode)\t\t\t ->evict() // dec i_count to 0 ->iput_final() ->spin_unlock() ->evict() Now, we have two threads simultaneously evicting the same inode, which may trigger the BUG(inode->i_state & I_CLEAR) statement both within clear_inode() and iput(). To fix the bug, recheck the inode->i_count after holding i_lock. Because in the most scenarios, the first check is valid, and the overhead of spin_lock() can be reduced. If there is any misunderstanding, please let me know, thanks. [1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/ [2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable() return false when I reproduced the bug.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49859", "url": "https://ubuntu.com/security/CVE-2024-49859", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to check atomic_file in f2fs ioctl interfaces Some f2fs ioctl interfaces like f2fs_ioc_set_pin_file(), f2fs_move_file_range(), and f2fs_defragment_range() missed to check atomic_write status, which may cause potential race issue, fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47680", "url": "https://ubuntu.com/security/CVE-2024-47680", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: check discard support for conventional zones As the helper function f2fs_bdev_support_discard() shows, f2fs checks if the target block devices support discard by calling bdev_max_discard_sectors() and bdev_is_zoned(). This check works well for most cases, but it does not work for conventional zones on zoned block devices. F2fs assumes that zoned block devices support discard, and calls __submit_discard_cmd(). When __submit_discard_cmd() is called for sequential write required zones, it works fine since __submit_discard_cmd() issues zone reset commands instead of discard commands. However, when __submit_discard_cmd() is called for conventional zones, __blkdev_issue_discard() is called even when the devices do not support discard. The inappropriate __blkdev_issue_discard() call was not a problem before the commit 30f1e7241422 (\"block: move discard checks into the ioctl handler\") because __blkdev_issue_discard() checked if the target devices support discard or not. If not, it returned EOPNOTSUPP. After the commit, __blkdev_issue_discard() no longer checks it. It always returns zero and sets NULL to the given bio pointer. This NULL pointer triggers f2fs_bug_on() in __submit_discard_cmd(). The BUG is recreated with the commands below at the umount step, where /dev/nullb0 is a zoned null_blk with 5GB total size, 128MB zone size and 10 conventional zones. $ mkfs.f2fs -f -m /dev/nullb0 $ mount /dev/nullb0 /mnt $ for ((i=0;i<5;i++)); do dd if=/dev/zero of=/mnt/test bs=65536 count=1600 conv=fsync; done $ umount /mnt To fix the BUG, avoid the inappropriate __blkdev_issue_discard() call. When discard is requested for conventional zones, check if the device supports discard or not. If not, return EOPNOTSUPP.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47740", "url": "https://ubuntu.com/security/CVE-2024-47740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: Require FMODE_WRITE for atomic write ioctls The F2FS ioctls for starting and committing atomic writes check for inode_owner_or_capable(), but this does not give LSMs like SELinux or Landlock an opportunity to deny the write access - if the caller's FSUID matches the inode's UID, inode_owner_or_capable() immediately returns true. There are scenarios where LSMs want to deny a process the ability to write particular files, even files that the FSUID of the process owns; but this can currently partially be bypassed using atomic write ioctls in two ways: - F2FS_IOC_START_ATOMIC_REPLACE + F2FS_IOC_COMMIT_ATOMIC_WRITE can truncate an inode to size 0 - F2FS_IOC_START_ATOMIC_WRITE + F2FS_IOC_ABORT_ATOMIC_WRITE can revert changes another process concurrently made to a file Fix it by requiring FMODE_WRITE for these operations, just like for F2FS_IOC_MOVE_RANGE. Since any legitimate caller should only be using these ioctls when intending to write into the file, that seems unlikely to break anything.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47726", "url": "https://ubuntu.com/security/CVE-2024-47726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to wait dio completion It should wait all existing dio write IOs before block removal, otherwise, previous direct write IO may overwrite data in the block which may be reused by other inode.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47741", "url": "https://ubuntu.com/security/CVE-2024-47741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race setting file private on concurrent lseek using same fd When doing concurrent lseek(2) system calls against the same file descriptor, using multiple threads belonging to the same process, we have a short time window where a race happens and can result in a memory leak. The race happens like this: 1) A program opens a file descriptor for a file and then spawns two threads (with the pthreads library for example), lets call them task A and task B; 2) Task A calls lseek with SEEK_DATA or SEEK_HOLE and ends up at file.c:find_desired_extent() while holding a read lock on the inode; 3) At the start of find_desired_extent(), it extracts the file's private_data pointer into a local variable named 'private', which has a value of NULL; 4) Task B also calls lseek with SEEK_DATA or SEEK_HOLE, locks the inode in shared mode and enters file.c:find_desired_extent(), where it also extracts file->private_data into its local variable 'private', which has a NULL value; 5) Because it saw a NULL file private, task A allocates a private structure and assigns to the file structure; 6) Task B also saw a NULL file private so it also allocates its own file private and then assigns it to the same file structure, since both tasks are using the same file descriptor. At this point we leak the private structure allocated by task A. Besides the memory leak, there's also the detail that both tasks end up using the same cached state record in the private structure (struct btrfs_file_private::llseek_cached_state), which can result in a use-after-free problem since one task can free it while the other is still using it (only one task took a reference count on it). Also, sharing the cached state is not a good idea since it could result in incorrect results in the future - right now it should not be a problem because it end ups being used only in extent-io-tree.c:count_range_bits() where we do range validation before using the cached state. Fix this by protecting the private assignment and check of a file while holding the inode's spinlock and keep track of the task that allocated the private, so that it's used only by that task in order to prevent user-after-free issues with the cached state record as well as potentially using it incorrectly in the future.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47681", "url": "https://ubuntu.com/security/CVE-2024-47681", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix NULL pointer dereference in mt7996_mcu_sta_bfer_he Fix the NULL pointer dereference in mt7996_mcu_sta_bfer_he routine adding an sta interface to the mt7996 driver. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49858", "url": "https://ubuntu.com/security/CVE-2024-49858", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption The TPM event log table is a Linux specific construct, where the data produced by the GetEventLog() boot service is cached in memory, and passed on to the OS using an EFI configuration table. The use of EFI_LOADER_DATA here results in the region being left unreserved in the E820 memory map constructed by the EFI stub, and this is the memory description that is passed on to the incoming kernel by kexec, which is therefore unaware that the region should be reserved. Even though the utility of the TPM2 event log after a kexec is questionable, any corruption might send the parsing code off into the weeds and crash the kernel. So let's use EFI_ACPI_RECLAIM_MEMORY instead, which is always treated as reserved by the E820 conversion logic.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49860", "url": "https://ubuntu.com/security/CVE-2024-49860", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: sysfs: validate return type of _STR method Only buffer objects are valid return values of _STR. If something else is returned description_show() will access invalid memory.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47742", "url": "https://ubuntu.com/security/CVE-2024-47742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware_loader: Block path traversal Most firmware names are hardcoded strings, or are constructed from fairly constrained format strings where the dynamic parts are just some hex numbers or such. However, there are a couple codepaths in the kernel where firmware file names contain string components that are passed through from a device or semi-privileged userspace; the ones I could find (not counting interfaces that require root privileges) are: - lpfc_sli4_request_firmware_update() seems to construct the firmware filename from \"ModelName\", a string that was previously parsed out of some descriptor (\"Vital Product Data\") in lpfc_fill_vpd() - nfp_net_fw_find() seems to construct a firmware filename from a model name coming from nfp_hwinfo_lookup(pf->hwinfo, \"nffw.partno\"), which I think parses some descriptor that was read from the device. (But this case likely isn't exploitable because the format string looks like \"netronome/nic_%s\", and there shouldn't be any *folders* starting with \"netronome/nic_\". The previous case was different because there, the \"%s\" is *at the start* of the format string.) - module_flash_fw_schedule() is reachable from the ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is enough to pass the privilege check), and takes a userspace-provided firmware name. (But I think to reach this case, you need to have CAP_NET_ADMIN over a network namespace that a special kind of ethernet device is mapped into, so I think this is not a viable attack path in practice.) Fix it by rejecting any firmware names containing \"..\" path components. For what it's worth, I went looking and haven't found any USB device drivers that use the firmware loader dangerously.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47682", "url": "https://ubuntu.com/security/CVE-2024-47682", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sd: Fix off-by-one error in sd_read_block_characteristics() Ff the device returns page 0xb1 with length 8 (happens with qemu v2.x, for example), sd_read_block_characteristics() may attempt an out-of-bounds memory access when accessing the zoned field at offset 8.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47743", "url": "https://ubuntu.com/security/CVE-2024-47743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: prevent NULL pointer dereference in find_asymmetric_key() In find_asymmetric_key(), if all NULLs are passed in the id_{0,1,2} arguments, the kernel will first emit WARN but then have an oops because id_2 gets dereferenced anyway. Add the missing id_2 check and move WARN_ON() to the final else branch to avoid duplicate NULL checks. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47727", "url": "https://ubuntu.com/security/CVE-2024-47727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/tdx: Fix \"in-kernel MMIO\" check TDX only supports kernel-initiated MMIO operations. The handle_mmio() function checks if the #VE exception occurred in the kernel and rejects the operation if it did not. However, userspace can deceive the kernel into performing MMIO on its behalf. For example, if userspace can point a syscall to an MMIO address, syscall does get_user() or put_user() on it, triggering MMIO #VE. The kernel will treat the #VE as in-kernel MMIO. Ensure that the target MMIO address is within the kernel before decoding instruction.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47744", "url": "https://ubuntu.com/security/CVE-2024-47744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Use dedicated mutex to protect kvm_usage_count to avoid deadlock Use a dedicated mutex to guard kvm_usage_count to fix a potential deadlock on x86 due to a chain of locks and SRCU synchronizations. Translating the below lockdep splat, CPU1 #6 will wait on CPU0 #1, CPU0 #8 will wait on CPU2 #3, and CPU2 #7 will wait on CPU1 #4 (if there's a writer, due to the fairness of r/w semaphores). CPU0 CPU1 CPU2 1 lock(&kvm->slots_lock); 2 lock(&vcpu->mutex); 3 lock(&kvm->srcu); 4 lock(cpu_hotplug_lock); 5 lock(kvm_lock); 6 lock(&kvm->slots_lock); 7 lock(cpu_hotplug_lock); 8 sync(&kvm->srcu); Note, there are likely more potential deadlocks in KVM x86, e.g. the same pattern of taking cpu_hotplug_lock outside of kvm_lock likely exists with __kvmclock_cpufreq_notifier(): cpuhp_cpufreq_online() | -> cpufreq_online() | -> cpufreq_gov_performance_limits() | -> __cpufreq_driver_target() | -> __target_index() | -> cpufreq_freq_transition_begin() | -> cpufreq_notify_transition() | -> ... __kvmclock_cpufreq_notifier() But, actually triggering such deadlocks is beyond rare due to the combination of dependencies and timings involved. E.g. the cpufreq notifier is only used on older CPUs without a constant TSC, mucking with the NX hugepage mitigation while VMs are running is very uncommon, and doing so while also onlining/offlining a CPU (necessary to generate contention on cpu_hotplug_lock) would be even more unusual. The most robust solution to the general cpu_hotplug_lock issue is likely to switch vm_list to be an RCU-protected list, e.g. so that x86's cpufreq notifier doesn't to take kvm_lock. For now, settle for fixing the most blatant deadlock, as switching to an RCU-protected list is a much more involved change, but add a comment in locking.rst to call out that care needs to be taken when walking holding kvm_lock and walking vm_list. ====================================================== WARNING: possible circular locking dependency detected 6.10.0-smp--c257535a0c9d-pip #330 Tainted: G S O ------------------------------------------------------ tee/35048 is trying to acquire lock: ff6a80eced71e0a8 (&kvm->slots_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x179/0x1e0 [kvm] but task is already holding lock: ffffffffc07abb08 (kvm_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x14a/0x1e0 [kvm] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (kvm_lock){+.+.}-{3:3}: __mutex_lock+0x6a/0xb40 mutex_lock_nested+0x1f/0x30 kvm_dev_ioctl+0x4fb/0xe50 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #2 (cpu_hotplug_lock){++++}-{0:0}: cpus_read_lock+0x2e/0xb0 static_key_slow_inc+0x16/0x30 kvm_lapic_set_base+0x6a/0x1c0 [kvm] kvm_set_apic_base+0x8f/0xe0 [kvm] kvm_set_msr_common+0x9ae/0xf80 [kvm] vmx_set_msr+0xa54/0xbe0 [kvm_intel] __kvm_set_msr+0xb6/0x1a0 [kvm] kvm_arch_vcpu_ioctl+0xeca/0x10c0 [kvm] kvm_vcpu_ioctl+0x485/0x5b0 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (&kvm->srcu){.+.+}-{0:0}: __synchronize_srcu+0x44/0x1a0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47719", "url": "https://ubuntu.com/security/CVE-2024-47719", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommufd: Protect against overflow of ALIGN() during iova allocation Userspace can supply an iova and uptr such that the target iova alignment becomes really big and ALIGN() overflows which corrupts the selected area range during allocation. CONFIG_IOMMUFD_TEST can detect this: WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline] WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352 Modules linked in: CPU: 1 PID: 5092 Comm: syz-executor294 Not tainted 6.10.0-rc5-syzkaller-00294-g3ffea9a7a6f7 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024 RIP: 0010:iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline] RIP: 0010:iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352 Code: fc e9 a4 f3 ff ff e8 1a 8b 4c fc 41 be e4 ff ff ff e9 8a f3 ff ff e8 0a 8b 4c fc 90 0f 0b 90 e9 37 f5 ff ff e8 fc 8a 4c fc 90 <0f> 0b 90 e9 68 f3 ff ff 48 c7 c1 ec 82 ad 8f 80 e1 07 80 c1 03 38 RSP: 0018:ffffc90003ebf9e0 EFLAGS: 00010293 RAX: ffffffff85499fa4 RBX: 00000000ffffffef RCX: ffff888079b49e00 RDX: 0000000000000000 RSI: 00000000ffffffef RDI: 0000000000000000 RBP: ffffc90003ebfc50 R08: ffffffff85499b30 R09: ffffffff85499942 R10: 0000000000000002 R11: ffff888079b49e00 R12: ffff8880228e0010 R13: 0000000000000000 R14: 1ffff920007d7f68 R15: ffffc90003ebfd00 FS: 000055557d760380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000005fdeb8 CR3: 000000007404a000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: iommufd_ioas_copy+0x610/0x7b0 drivers/iommu/iommufd/ioas.c:274 iommufd_fops_ioctl+0x4d9/0x5a0 drivers/iommu/iommufd/main.c:421 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Cap the automatic alignment to the huge page size, which is probably a better idea overall. Huge automatic alignments can fragment and chew up the available IOVA space without any reason.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47745", "url": "https://ubuntu.com/security/CVE-2024-47745", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: call the security_mmap_file() LSM hook in remap_file_pages() The remap_file_pages syscall handler calls do_mmap() directly, which doesn't contain the LSM security check. And if the process has called personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for RW pages, this will actually result in remapping the pages to RWX, bypassing a W^X policy enforced by SELinux. So we should check prot by security_mmap_file LSM hook in the remap_file_pages syscall handler before do_mmap() is called. Otherwise, it potentially permits an attacker to bypass a W^X policy enforced by SELinux. The bypass is similar to CVE-2016-10044, which bypass the same thing via AIO and can be found in [1]. The PoC: $ cat > test.c int main(void) { \tsize_t pagesz = sysconf(_SC_PAGE_SIZE); \tint mfd = syscall(SYS_memfd_create, \"test\", 0); \tconst char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE, \t\tMAP_SHARED, mfd, 0); \tunsigned int old = syscall(SYS_personality, 0xffffffff); \tsyscall(SYS_personality, READ_IMPLIES_EXEC | old); \tsyscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0); \tsyscall(SYS_personality, old); \t// show the RWX page exists even if W^X policy is enforced \tint fd = open(\"/proc/self/maps\", O_RDONLY); \tunsigned char buf2[1024]; \twhile (1) { \t\tint ret = read(fd, buf2, 1024); \t\tif (ret <= 0) break; \t\twrite(1, buf2, ret); \t} \tclose(fd); } $ gcc test.c -o test $ ./test | grep rwx 7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted) [PM: subject line tweaks]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47746", "url": "https://ubuntu.com/security/CVE-2024-47746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: use exclusive lock when FUSE_I_CACHE_IO_MODE is set This may be a typo. The comment has said shared locks are not allowed when this bit is set. If using shared lock, the wait in `fuse_file_cached_io_open` may be forever.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47734", "url": "https://ubuntu.com/security/CVE-2024-47734", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: Fix unnecessary warnings and logs from bond_xdp_get_xmit_slave() syzbot reported a WARNING in bond_xdp_get_xmit_slave. To reproduce this[1], one bond device (bond1) has xdpdrv, which increases bpf_master_redirect_enabled_key. Another bond device (bond0) which is unsupported by XDP but its slave (veth3) has xdpgeneric that returns XDP_TX. This triggers WARN_ON_ONCE() from the xdp_master_redirect(). To reduce unnecessary warnings and improve log management, we need to delete the WARN_ON_ONCE() and add ratelimit to the netdev_err(). [1] Steps to reproduce: # Needs tx_xdp with return XDP_TX; ip l add veth0 type veth peer veth1 ip l add veth3 type veth peer veth4 ip l add bond0 type bond mode 6 # BOND_MODE_ALB, unsupported by XDP ip l add bond1 type bond # BOND_MODE_ROUNDROBIN by default ip l set veth0 master bond1 ip l set bond1 up # Increases bpf_master_redirect_enabled_key ip l set dev bond1 xdpdrv object tx_xdp.o section xdp_tx ip l set veth3 master bond0 ip l set bond0 up ip l set veth4 up # Triggers WARN_ON_ONCE() from the xdp_master_redirect() ip l set veth3 xdpgeneric object tx_xdp.o section xdp_tx", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47684", "url": "https://ubuntu.com/security/CVE-2024-47684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: check skb is non-NULL in tcp_rto_delta_us() We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic kernel that are running ceph and recently hit a null ptr dereference in tcp_rearm_rto(). Initially hitting it from the TLP path, but then later we also saw it getting hit from the RACK case as well. Here are examples of the oops messages we saw in each of those cases: Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020 Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode Jul 26 15:05:02 rx [11061395.792971] #PF: error_code(0x0000) - not-present page Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0 Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI Jul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu Jul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023 Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 <48> 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3 Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246 Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000 Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60 Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8 Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900 Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30 Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000 Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0 Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554 Jul 26 15:05:02 rx [11061395.916786] Call Trace: Jul 26 15:05:02 rx [11061395.919488] Jul 26 15:05:02 rx [11061395.921765] ? show_regs.cold+0x1a/0x1f Jul 26 15:05:02 rx [11061395.925859] ? __die+0x90/0xd9 Jul 26 15:05:02 rx [11061395.929169] ? no_context+0x196/0x380 Jul 26 15:05:02 rx [11061395.933088] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0 Jul 26 15:05:02 rx [11061395.938216] ? ip6_sublist_rcv_finish+0x3d/0x50 Jul 26 15:05:02 rx [11061395.943000] ? __bad_area_nosemaphore+0x50/0x1a0 Jul 26 15:05:02 rx [11061395.947873] ? bad_area_nosemaphore+0x16/0x20 Jul 26 15:05:02 rx [11061395.952486] ? do_user_addr_fault+0x267/0x450 Jul 26 15:05:02 rx [11061395.957104] ? ipv6_list_rcv+0x112/0x140 Jul 26 15:05:02 rx [11061395.961279] ? __do_page_fault+0x58/0x90 Jul 26 15:05:02 rx [11061395.965458] ? do_page_fault+0x2c/0xe0 Jul 26 15:05:02 rx [11061395.969465] ? page_fault+0x34/0x40 Jul 26 15:05:02 rx [11061395.973217] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.977313] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.981408] tcp_send_loss_probe+0x10b/0x220 Jul 26 15:05:02 rx [11061395.985937] tcp_write_timer_handler+0x1b4/0x240 Jul 26 15:05:02 rx [11061395.990809] tcp_write_timer+0x9e/0xe0 Jul 26 15:05:02 rx [11061395.994814] ? tcp_write_timer_handler+0x240/0x240 Jul 26 15:05:02 rx [11061395.999866] call_timer_fn+0x32/0x130 Jul 26 15:05:02 rx [11061396.003782] __run_timers.part.0+0x180/0x280 Jul 26 15:05:02 rx [11061396.008309] ? recalibrate_cpu_khz+0x10/0x10 Jul 26 15:05:02 rx [11061396.012841] ? native_x2apic_icr_write+0x30/0x30 Jul 26 15:05:02 rx [11061396.017718] ? lapic_next_even ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47747", "url": "https://ubuntu.com/security/CVE-2024-47747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race Condition In the ether3_probe function, a timer is initialized with a callback function ether3_ledoff, bound to &prev(dev)->timer. Once the timer is started, there is a risk of a race condition if the module or device is removed, triggering the ether3_remove function to perform cleanup. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | ether3_ledoff ether3_remove | free_netdev(dev); | put_devic | kfree(dev); | | ether3_outw(priv(dev)->regs.config2 |= CFG2_CTRLO, REG_CONFIG2); | // use dev Fix it by ensuring that the timer is canceled before proceeding with the cleanup in ether3_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47685", "url": "https://ubuntu.com/security/CVE-2024-47685", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put() syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending garbage on the four reserved tcp bits (th->res1) Use skb_put_zero() to clear the whole TCP header, as done in nf_reject_ip_tcphdr_put() BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5661 [inline] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775 process_backlog+0x4ad/0xa50 net/core/dev.c:6108 __napi_poll+0xe7/0x980 net/core/dev.c:6772 napi_poll net/core/dev.c:6841 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963 handle_softirqs+0x1ce/0x800 kernel/softirq.c:554 __do_softirq+0x14/0x1a kernel/softirq.c:588 do_softirq+0x9a/0x100 kernel/softirq.c:455 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline] __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450 dev_queue_xmit include/linux/netdevice.h:3105 [inline] neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366 inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135 __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143 tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333 __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679 inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750 __sys_connect_file net/socket.c:2061 [inline] __sys_connect+0x606/0x690 net/socket.c:2078 __do_sys_connect net/socket.c:2088 [inline] __se_sys_connect net/socket.c:2085 [inline] __x64_sys_connect+0x91/0xe0 net/socket.c:2085 x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43 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 Uninit was stored to memory at: nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47686", "url": "https://ubuntu.com/security/CVE-2024-47686", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ep93xx: clock: Fix off by one in ep93xx_div_recalc_rate() The psc->div[] array has psc->num_div elements. These values come from when we call clk_hw_register_div(). It's adc_divisors and ARRAY_SIZE(adc_divisors)) and so on. So this condition needs to be >= instead of > to prevent an out of bounds read.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47748", "url": "https://ubuntu.com/security/CVE-2024-47748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost_vdpa: assign irq bypass producer token correctly We used to call irq_bypass_unregister_producer() in vhost_vdpa_setup_vq_irq() which is problematic as we don't know if the token pointer is still valid or not. Actually, we use the eventfd_ctx as the token so the life cycle of the token should be bound to the VHOST_SET_VRING_CALL instead of vhost_vdpa_setup_vq_irq() which could be called by set_status(). Fixing this by setting up irq bypass producer's token when handling VHOST_SET_VRING_CALL and un-registering the producer before calling vhost_vring_ioctl() to prevent a possible use after free as eventfd could have been released in vhost_vring_ioctl(). And such registering and unregistering will only be done if DRIVER_OK is set.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47687", "url": "https://ubuntu.com/security/CVE-2024-47687", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa/mlx5: Fix invalid mr resource destroy Certain error paths from mlx5_vdpa_dev_add() can end up releasing mr resources which never got initialized in the first place. This patch adds the missing check in mlx5_vdpa_destroy_mr_resources() to block releasing non-initialized mr resources. Reference trace: mlx5_core 0000:08:00.2: mlx5_vdpa_dev_add:3274:(pid 2700) warning: No mac address provisioned? BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 140216067 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 8 PID: 2700 Comm: vdpa Kdump: loaded Not tainted 5.14.0-496.el9.x86_64 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:vhost_iotlb_del_range+0xf/0xe0 [vhost_iotlb] Code: [...] RSP: 0018:ff1c823ac23077f0 EFLAGS: 00010246 RAX: ffffffffc1a21a60 RBX: ffffffff899567a0 RCX: 0000000000000000 RDX: ffffffffffffffff RSI: 0000000000000000 RDI: 0000000000000000 RBP: ff1bda1f7c21e800 R08: 0000000000000000 R09: ff1c823ac2307670 R10: ff1c823ac2307668 R11: ffffffff8a9e7b68 R12: 0000000000000000 R13: 0000000000000000 R14: ff1bda1f43e341a0 R15: 00000000ffffffea FS: 00007f56eba7c740(0000) GS:ff1bda269f800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000104d90001 CR4: 0000000000771ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? mlx5_vdpa_free+0x3d/0x150 [mlx5_vdpa] ? __die_body.cold+0x8/0xd ? page_fault_oops+0x134/0x170 ? __irq_work_queue_local+0x2b/0xc0 ? irq_work_queue+0x2c/0x50 ? exc_page_fault+0x62/0x150 ? asm_exc_page_fault+0x22/0x30 ? __pfx_mlx5_vdpa_free+0x10/0x10 [mlx5_vdpa] ? vhost_iotlb_del_range+0xf/0xe0 [vhost_iotlb] mlx5_vdpa_free+0x3d/0x150 [mlx5_vdpa] vdpa_release_dev+0x1e/0x50 [vdpa] device_release+0x31/0x90 kobject_cleanup+0x37/0x130 mlx5_vdpa_dev_add+0x2d2/0x7a0 [mlx5_vdpa] vdpa_nl_cmd_dev_add_set_doit+0x277/0x4c0 [vdpa] genl_family_rcv_msg_doit+0xd9/0x130 genl_family_rcv_msg+0x14d/0x220 ? __pfx_vdpa_nl_cmd_dev_add_set_doit+0x10/0x10 [vdpa] ? _copy_to_user+0x1a/0x30 ? move_addr_to_user+0x4b/0xe0 genl_rcv_msg+0x47/0xa0 ? __import_iovec+0x46/0x150 ? __pfx_genl_rcv_msg+0x10/0x10 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x245/0x370 netlink_sendmsg+0x206/0x440 __sys_sendto+0x1dc/0x1f0 ? do_read_fault+0x10c/0x1d0 ? do_pte_missing+0x10d/0x190 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x5c/0xf0 ? __count_memcg_events+0x4f/0xb0 ? mm_account_fault+0x6c/0x100 ? handle_mm_fault+0x116/0x270 ? do_user_addr_fault+0x1d6/0x6a0 ? do_syscall_64+0x6b/0xf0 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 entry_SYSCALL_64_after_hwframe+0x78/0x80", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47688", "url": "https://ubuntu.com/security/CVE-2024-47688", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: driver core: Fix a potential null-ptr-deref in module_add_driver() Inject fault while probing of-fpga-region, if kasprintf() fails in module_add_driver(), the second sysfs_remove_link() in exit path will cause null-ptr-deref as below because kernfs_name_hash() will call strlen() with NULL driver_name. Fix it by releasing resources based on the exit path sequence. \t KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] \t Mem abort info: \t ESR = 0x0000000096000005 \t EC = 0x25: DABT (current EL), IL = 32 bits \t SET = 0, FnV = 0 \t EA = 0, S1PTW = 0 \t FSC = 0x05: level 1 translation fault \t Data abort info: \t ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 \t CM = 0, WnR = 0, TnD = 0, TagAccess = 0 \t GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 \t [dfffffc000000000] address between user and kernel address ranges \t Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP \t Dumping ftrace buffer: \t (ftrace buffer empty) \t Modules linked in: of_fpga_region(+) fpga_region fpga_bridge cfg80211 rfkill 8021q garp mrp stp llc ipv6 [last unloaded: of_fpga_region] \t CPU: 2 UID: 0 PID: 2036 Comm: modprobe Not tainted 6.11.0-rc2-g6a0e38264012 #295 \t Hardware name: linux,dummy-virt (DT) \t pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) \t pc : strlen+0x24/0xb0 \t lr : kernfs_name_hash+0x1c/0xc4 \t sp : ffffffc081f97380 \t x29: ffffffc081f97380 x28: ffffffc081f97b90 x27: ffffff80c821c2a0 \t x26: ffffffedac0be418 x25: 0000000000000000 x24: ffffff80c09d2000 \t x23: 0000000000000000 x22: 0000000000000000 x21: 0000000000000000 \t x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000001840 \t x17: 0000000000000000 x16: 0000000000000000 x15: 1ffffff8103f2e42 \t x14: 00000000f1f1f1f1 x13: 0000000000000004 x12: ffffffb01812d61d \t x11: 1ffffff01812d61c x10: ffffffb01812d61c x9 : dfffffc000000000 \t x8 : 0000004fe7ed29e4 x7 : ffffff80c096b0e7 x6 : 0000000000000001 \t x5 : ffffff80c096b0e0 x4 : 1ffffffdb990efa2 x3 : 0000000000000000 \t x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000000 \t Call trace: \t strlen+0x24/0xb0 \t kernfs_name_hash+0x1c/0xc4 \t kernfs_find_ns+0x118/0x2e8 \t kernfs_remove_by_name_ns+0x80/0x100 \t sysfs_remove_link+0x74/0xa8 \t module_add_driver+0x278/0x394 \t bus_add_driver+0x1f0/0x43c \t driver_register+0xf4/0x3c0 \t __platform_driver_register+0x60/0x88 \t of_fpga_region_init+0x20/0x1000 [of_fpga_region] \t do_one_initcall+0x110/0x788 \t do_init_module+0x1dc/0x5c8 \t load_module+0x3c38/0x4cac \t init_module_from_file+0xd4/0x128 \t idempotent_init_module+0x2cc/0x528 \t __arm64_sys_finit_module+0xac/0x100 \t invoke_syscall+0x6c/0x258 \t el0_svc_common.constprop.0+0x160/0x22c \t do_el0_svc+0x44/0x5c \t el0_svc+0x48/0xb8 \t el0t_64_sync_handler+0x13c/0x158 \t el0t_64_sync+0x190/0x194 \t Code: f2fbffe1 a90157f4 12000802 aa0003f5 (38e16861) \t ---[ end trace 0000000000000000 ]--- \t Kernel panic - not syncing: Oops: Fatal exception", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47689", "url": "https://ubuntu.com/security/CVE-2024-47689", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to don't set SB_RDONLY in f2fs_handle_critical_error() syzbot reports a f2fs bug as below: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 58 at kernel/rcu/sync.c:177 rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177 CPU: 1 UID: 0 PID: 58 Comm: kworker/1:2 Not tainted 6.10.0-syzkaller-12562-g1722389b0d86 #0 Workqueue: events destroy_super_work RIP: 0010:rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177 Call Trace: percpu_free_rwsem+0x41/0x80 kernel/locking/percpu-rwsem.c:42 destroy_super_work+0xec/0x130 fs/super.c:282 process_one_work kernel/workqueue.c:3231 [inline] process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 worker_thread+0x86d/0xd40 kernel/workqueue.c:3390 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 As Christian Brauner pointed out [1]: the root cause is f2fs sets SB_RDONLY flag in internal function, rather than setting the flag covered w/ sb->s_umount semaphore via remount procedure, then below race condition causes this bug: - freeze_super() - sb_wait_write(sb, SB_FREEZE_WRITE) - sb_wait_write(sb, SB_FREEZE_PAGEFAULT) - sb_wait_write(sb, SB_FREEZE_FS) \t\t\t\t\t- f2fs_handle_critical_error \t\t\t\t\t - sb->s_flags |= SB_RDONLY - thaw_super - thaw_super_locked - sb_rdonly() is true, so it skips sb_freeze_unlock(sb, SB_FREEZE_FS) - deactivate_locked_super Since f2fs has almost the same logic as ext4 [2] when handling critical error in filesystem if it mounts w/ errors=remount-ro option: - set CP_ERROR_FLAG flag which indicates filesystem is stopped - record errors to superblock - set SB_RDONLY falg Once we set CP_ERROR_FLAG flag, all writable interfaces can detect the flag and stop any further updates on filesystem. So, it is safe to not set SB_RDONLY flag, let's remove the logic and keep in line w/ ext4 [3]. [1] https://lore.kernel.org/all/20240729-himbeeren-funknetz-96e62f9c7aee@brauner [2] https://lore.kernel.org/all/20240729132721.hxih6ehigadqf7wx@quack3 [3] https://lore.kernel.org/linux-ext4/20240805201241.27286-1-jack@suse.cz", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47690", "url": "https://ubuntu.com/security/CVE-2024-47690", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: get rid of online repaire on corrupted directory syzbot reports a f2fs bug as below: kernel BUG at fs/f2fs/inode.c:896! RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Call Trace: evict+0x532/0x950 fs/inode.c:704 dispose_list fs/inode.c:747 [inline] evict_inodes+0x5f9/0x690 fs/inode.c:797 generic_shutdown_super+0x9d/0x2d0 fs/super.c:627 kill_block_super+0x44/0x90 fs/super.c:1696 kill_f2fs_super+0x344/0x690 fs/f2fs/super.c:4898 deactivate_locked_super+0xc4/0x130 fs/super.c:473 cleanup_mnt+0x41f/0x4b0 fs/namespace.c:1373 task_work_run+0x24f/0x310 kernel/task_work.c:228 ptrace_notify+0x2d2/0x380 kernel/signal.c:2402 ptrace_report_syscall include/linux/ptrace.h:415 [inline] ptrace_report_syscall_exit include/linux/ptrace.h:477 [inline] syscall_exit_work+0xc6/0x190 kernel/entry/common.c:173 syscall_exit_to_user_mode_prepare kernel/entry/common.c:200 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:205 [inline] syscall_exit_to_user_mode+0x279/0x370 kernel/entry/common.c:218 do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Online repaire on corrupted directory in f2fs_lookup() can generate dirty data/meta while racing w/ readonly remount, it may leave dirty inode after filesystem becomes readonly, however, checkpoint() will skips flushing dirty inode in a state of readonly mode, result in above panic. Let's get rid of online repaire in f2fs_lookup(), and leave the work to fsck.f2fs.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47691", "url": "https://ubuntu.com/security/CVE-2024-47691", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread() syzbot reports a f2fs bug as below: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_report+0xe8/0x550 mm/kasan/report.c:491 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 instrument_atomic_read_write include/linux/instrumented.h:96 [inline] atomic_fetch_add_relaxed include/linux/atomic/atomic-instrumented.h:252 [inline] __refcount_add include/linux/refcount.h:184 [inline] __refcount_inc include/linux/refcount.h:241 [inline] refcount_inc include/linux/refcount.h:258 [inline] get_task_struct include/linux/sched/task.h:118 [inline] kthread_stop+0xca/0x630 kernel/kthread.c:704 f2fs_stop_gc_thread+0x65/0xb0 fs/f2fs/gc.c:210 f2fs_do_shutdown+0x192/0x540 fs/f2fs/file.c:2283 f2fs_ioc_shutdown fs/f2fs/file.c:2325 [inline] __f2fs_ioctl+0x443a/0xbe60 fs/f2fs/file.c:4325 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f The root cause is below race condition, it may cause use-after-free issue in sbi->gc_th pointer. - remount - f2fs_remount - f2fs_stop_gc_thread - kfree(gc_th) \t\t\t\t- f2fs_ioc_shutdown \t\t\t\t - f2fs_do_shutdown \t\t\t\t - f2fs_stop_gc_thread \t\t\t\t - kthread_stop(gc_th->f2fs_gc_task) : sbi->gc_thread = NULL; We will call f2fs_do_shutdown() in two paths: - for f2fs_ioc_shutdown() path, we should grab sb->s_umount semaphore for fixing. - for f2fs_shutdown() path, it's safe since caller has already grabbed sb->s_umount semaphore.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47692", "url": "https://ubuntu.com/security/CVE-2024-47692", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: return -EINVAL when namelen is 0 When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may result in namelen being 0, which will cause memdup_user() to return ZERO_SIZE_PTR. When we access the name.data that has been assigned the value of ZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is triggered. [ T1205] ================================================================== [ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260 [ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205 [ T1205] [ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406 [ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ T1205] Call Trace: [ T1205] dump_stack+0x9a/0xd0 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] __kasan_report.cold+0x34/0x84 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] kasan_report+0x3a/0x50 [ T1205] nfs4_client_to_reclaim+0xe9/0x260 [ T1205] ? nfsd4_release_lockowner+0x410/0x410 [ T1205] cld_pipe_downcall+0x5ca/0x760 [ T1205] ? nfsd4_cld_tracking_exit+0x1d0/0x1d0 [ T1205] ? down_write_killable_nested+0x170/0x170 [ T1205] ? avc_policy_seqno+0x28/0x40 [ T1205] ? selinux_file_permission+0x1b4/0x1e0 [ T1205] rpc_pipe_write+0x84/0xb0 [ T1205] vfs_write+0x143/0x520 [ T1205] ksys_write+0xc9/0x170 [ T1205] ? __ia32_sys_read+0x50/0x50 [ T1205] ? ktime_get_coarse_real_ts64+0xfe/0x110 [ T1205] ? ktime_get_coarse_real_ts64+0xa2/0x110 [ T1205] do_syscall_64+0x33/0x40 [ T1205] entry_SYSCALL_64_after_hwframe+0x67/0xd1 [ T1205] RIP: 0033:0x7fdbdb761bc7 [ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 514 [ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7 [ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008 [ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001 [ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b [ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000 [ T1205] ================================================================== Fix it by checking namelen.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47737", "url": "https://ubuntu.com/security/CVE-2024-47737", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: call cache_put if xdr_reserve_space returns NULL If not enough buffer space available, but idmap_lookup has triggered lookup_fn which calls cache_get and returns successfully. Then we missed to call cache_put here which pairs with cache_get. Reviwed-by: Jeff Layton ", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2023-52917", "url": "https://ubuntu.com/security/CVE-2023-52917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir() The debugfs_create_dir() function returns error pointers. It never returns NULL. So use IS_ERR() to check it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47749", "url": "https://ubuntu.com/security/CVE-2024-47749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Added NULL check for lookup_atid The lookup_atid() function can return NULL if the ATID is invalid or does not exist in the identifier table, which could lead to dereferencing a null pointer without a check in the `act_establish()` and `act_open_rpl()` functions. Add a NULL check to prevent null pointer dereferencing. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47735", "url": "https://ubuntu.com/security/CVE-2024-47735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled Fix missuse of spin_lock_irq()/spin_unlock_irq() when spin_lock_irqsave()/spin_lock_irqrestore() was hold. This was discovered through the lock debugging, and the corresponding log is as follows: raw_local_irq_restore() called with IRQs enabled WARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40 ... Call trace: warn_bogus_irq_restore+0x30/0x40 _raw_spin_unlock_irqrestore+0x84/0xc8 add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2] hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2] hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2] create_qp+0x138/0x258 ib_create_qp_kernel+0x50/0xe8 create_mad_qp+0xa8/0x128 ib_mad_port_open+0x218/0x448 ib_mad_init_device+0x70/0x1f8 add_client_context+0xfc/0x220 enable_device_and_get+0xd0/0x140 ib_register_device.part.0+0xf4/0x1c8 ib_register_device+0x34/0x50 hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2] hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2] __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2] hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47750", "url": "https://ubuntu.com/security/CVE-2024-47750", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix Use-After-Free of rsv_qp on HIP08 Currently rsv_qp is freed before ib_unregister_device() is called on HIP08. During the time interval, users can still dereg MR and rsv_qp will be used in this process, leading to a UAF. Move the release of rsv_qp after calling ib_unregister_device() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47751", "url": "https://ubuntu.com/security/CVE-2024-47751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: kirin: Fix buffer overflow in kirin_pcie_parse_port() Within kirin_pcie_parse_port(), the pcie->num_slots is compared to pcie->gpio_id_reset size (MAX_PCI_SLOTS) which is correct and would lead to an overflow. Thus, fix condition to pcie->num_slots + 1 >= MAX_PCI_SLOTS and move pcie->num_slots increment below the if-statement to avoid out-of-bounds array access. Found by Linux Verification Center (linuxtesting.org) with SVACE. [kwilczynski: commit log]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47693", "url": "https://ubuntu.com/security/CVE-2024-47693", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/core: Fix ib_cache_setup_one error flow cleanup When ib_cache_update return an error, we exit ib_cache_setup_one instantly with no proper cleanup, even though before this we had already successfully done gid_table_setup_one, that results in the kernel WARN below. Do proper cleanup using gid_table_cleanup_one before returning the err in order to fix the issue. WARNING: CPU: 4 PID: 922 at drivers/infiniband/core/cache.c:806 gid_table_release_one+0x181/0x1a0 Modules linked in: CPU: 4 UID: 0 PID: 922 Comm: c_repro Not tainted 6.11.0-rc1+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:gid_table_release_one+0x181/0x1a0 Code: 44 8b 38 75 0c e8 2f cb 34 ff 4d 8b b5 28 05 00 00 e8 23 cb 34 ff 44 89 f9 89 da 4c 89 f6 48 c7 c7 d0 58 14 83 e8 4f de 21 ff <0f> 0b 4c 8b 75 30 e9 54 ff ff ff 48 8 3 c4 10 5b 5d 41 5c 41 5d 41 RSP: 0018:ffffc90002b835b0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c8527 RDX: 0000000000000000 RSI: ffffffff811c8534 RDI: 0000000000000001 RBP: ffff8881011b3d00 R08: ffff88810b3abe00 R09: 205d303839303631 R10: 666572207972746e R11: 72746e6520444947 R12: 0000000000000001 R13: ffff888106390000 R14: ffff8881011f2110 R15: 0000000000000001 FS: 00007fecc3b70800(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000340 CR3: 000000010435a001 CR4: 00000000003706b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? show_regs+0x94/0xa0 ? __warn+0x9e/0x1c0 ? gid_table_release_one+0x181/0x1a0 ? report_bug+0x1f9/0x340 ? gid_table_release_one+0x181/0x1a0 ? handle_bug+0xa2/0x110 ? exc_invalid_op+0x31/0xa0 ? asm_exc_invalid_op+0x16/0x20 ? __warn_printk+0xc7/0x180 ? __warn_printk+0xd4/0x180 ? gid_table_release_one+0x181/0x1a0 ib_device_release+0x71/0xe0 ? __pfx_ib_device_release+0x10/0x10 device_release+0x44/0xd0 kobject_put+0x135/0x3d0 put_device+0x20/0x30 rxe_net_add+0x7d/0xa0 rxe_newlink+0xd7/0x190 nldev_newlink+0x1b0/0x2a0 ? __pfx_nldev_newlink+0x10/0x10 rdma_nl_rcv_msg+0x1ad/0x2e0 rdma_nl_rcv_skb.constprop.0+0x176/0x210 netlink_unicast+0x2de/0x400 netlink_sendmsg+0x306/0x660 __sock_sendmsg+0x110/0x120 ____sys_sendmsg+0x30e/0x390 ___sys_sendmsg+0x9b/0xf0 ? kstrtouint+0x6e/0xa0 ? kstrtouint_from_user+0x7c/0xb0 ? get_pid_task+0xb0/0xd0 ? proc_fail_nth_write+0x5b/0x140 ? __fget_light+0x9a/0x200 ? preempt_count_add+0x47/0xa0 __sys_sendmsg+0x61/0xd0 do_syscall_64+0x50/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47694", "url": "https://ubuntu.com/security/CVE-2024-47694", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mlx5: Fix UMR pd cleanup on error flow of driver init The cited commit moves the pd allocation from function mlx5r_umr_resource_cleanup() to a new function mlx5r_umr_cleanup(). So the fix in commit [1] is broken. In error flow, will hit panic [2]. Fix it by checking pd pointer to avoid panic if it is NULL; [1] RDMA/mlx5: Fix UMR cleanup on error flow of driver init [2] [ 347.567063] infiniband mlx5_0: Couldn't register device with driver model [ 347.591382] BUG: kernel NULL pointer dereference, address: 0000000000000020 [ 347.593438] #PF: supervisor read access in kernel mode [ 347.595176] #PF: error_code(0x0000) - not-present page [ 347.596962] PGD 0 P4D 0 [ 347.601361] RIP: 0010:ib_dealloc_pd_user+0x12/0xc0 [ib_core] [ 347.604171] RSP: 0018:ffff888106293b10 EFLAGS: 00010282 [ 347.604834] RAX: 0000000000000000 RBX: 000000000000000e RCX: 0000000000000000 [ 347.605672] RDX: ffff888106293ad0 RSI: 0000000000000000 RDI: 0000000000000000 [ 347.606529] RBP: 0000000000000000 R08: ffff888106293ae0 R09: ffff888106293ae0 [ 347.607379] R10: 0000000000000a06 R11: 0000000000000000 R12: 0000000000000000 [ 347.608224] R13: ffffffffa0704dc0 R14: 0000000000000001 R15: 0000000000000001 [ 347.609067] FS: 00007fdc720cd9c0(0000) GS:ffff88852c880000(0000) knlGS:0000000000000000 [ 347.610094] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 347.610727] CR2: 0000000000000020 CR3: 0000000103012003 CR4: 0000000000370eb0 [ 347.611421] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 347.612113] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 347.612804] Call Trace: [ 347.613130] [ 347.613417] ? __die+0x20/0x60 [ 347.613793] ? page_fault_oops+0x150/0x3e0 [ 347.614243] ? free_msg+0x68/0x80 [mlx5_core] [ 347.614840] ? cmd_exec+0x48f/0x11d0 [mlx5_core] [ 347.615359] ? exc_page_fault+0x74/0x130 [ 347.615808] ? asm_exc_page_fault+0x22/0x30 [ 347.616273] ? ib_dealloc_pd_user+0x12/0xc0 [ib_core] [ 347.616801] mlx5r_umr_cleanup+0x23/0x90 [mlx5_ib] [ 347.617365] mlx5_ib_stage_pre_ib_reg_umr_cleanup+0x36/0x40 [mlx5_ib] [ 347.618025] __mlx5_ib_add+0x96/0xd0 [mlx5_ib] [ 347.618539] mlx5r_probe+0xe9/0x310 [mlx5_ib] [ 347.619032] ? kernfs_add_one+0x107/0x150 [ 347.619478] ? __mlx5_ib_add+0xd0/0xd0 [mlx5_ib] [ 347.619984] auxiliary_bus_probe+0x3e/0x90 [ 347.620448] really_probe+0xc5/0x3a0 [ 347.620857] __driver_probe_device+0x80/0x160 [ 347.621325] driver_probe_device+0x1e/0x90 [ 347.621770] __driver_attach+0xec/0x1c0 [ 347.622213] ? __device_attach_driver+0x100/0x100 [ 347.622724] bus_for_each_dev+0x71/0xc0 [ 347.623151] bus_add_driver+0xed/0x240 [ 347.623570] driver_register+0x58/0x100 [ 347.623998] __auxiliary_driver_register+0x6a/0xc0 [ 347.624499] ? driver_register+0xae/0x100 [ 347.624940] ? 0xffffffffa0893000 [ 347.625329] mlx5_ib_init+0x16a/0x1e0 [mlx5_ib] [ 347.625845] do_one_initcall+0x4a/0x2a0 [ 347.626273] ? gcov_event+0x2e2/0x3a0 [ 347.626706] do_init_module+0x8a/0x260 [ 347.627126] init_module_from_file+0x8b/0xd0 [ 347.627596] __x64_sys_finit_module+0x1ca/0x2f0 [ 347.628089] do_syscall_64+0x4c/0x100", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47695", "url": "https://ubuntu.com/security/CVE-2024-47695", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds In the function init_conns(), after the create_con() and create_cm() for loop if something fails. In the cleanup for loop after the destroy tag, we access out of bound memory because cid is set to clt_path->s.con_num. This commits resets the cid to clt_path->s.con_num - 1, to stay in bounds in the cleanup loop later.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47752", "url": "https://ubuntu.com/security/CVE-2024-47752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix H264 stateless decoder smatch warning Fix a smatch static checker warning on vdec_h264_req_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47753", "url": "https://ubuntu.com/security/CVE-2024-47753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix VP8 stateless decoder smatch warning Fix a smatch static checker warning on vdec_vp8_req_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47754", "url": "https://ubuntu.com/security/CVE-2024-47754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix H264 multi stateless decoder smatch warning Fix a smatch static checker warning on vdec_h264_req_multi_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47696", "url": "https://ubuntu.com/security/CVE-2024-47696", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency In the commit aee2424246f9 (\"RDMA/iwcm: Fix a use-after-free related to destroying CM IDs\"), the function flush_workqueue is invoked to flush the work queue iwcm_wq. But at that time, the work queue iwcm_wq was created via the function alloc_ordered_workqueue without the flag WQ_MEM_RECLAIM. Because the current process is trying to flush the whole iwcm_wq, if iwcm_wq doesn't have the flag WQ_MEM_RECLAIM, verify that the current process is not reclaiming memory or running on a workqueue which doesn't have the flag WQ_MEM_RECLAIM as that can break forward-progress guarantee leading to a deadlock. The call trace is as below: [ 125.350876][ T1430] Call Trace: [ 125.356281][ T1430] [ 125.361285][ T1430] ? __warn (kernel/panic.c:693) [ 125.367640][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.375689][ T1430] ? report_bug (lib/bug.c:180 lib/bug.c:219) [ 125.382505][ T1430] ? handle_bug (arch/x86/kernel/traps.c:239) [ 125.388987][ T1430] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) [ 125.395831][ T1430] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621) [ 125.403125][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.410984][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.418764][ T1430] __flush_workqueue (kernel/workqueue.c:3970) [ 125.426021][ T1430] ? __pfx___might_resched (kernel/sched/core.c:10151) [ 125.433431][ T1430] ? destroy_cm_id (drivers/infiniband/core/iwcm.c:375) iw_cm [ 125.441209][ T1430] ? __pfx___flush_workqueue (kernel/workqueue.c:3910) [ 125.473900][ T1430] ? _raw_spin_lock_irqsave (arch/x86/include/asm/atomic.h:107 include/linux/atomic/atomic-arch-fallback.h:2170 include/linux/atomic/atomic-instrumented.h:1302 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162) [ 125.473909][ T1430] ? __pfx__raw_spin_lock_irqsave (kernel/locking/spinlock.c:161) [ 125.482537][ T1430] _destroy_id (drivers/infiniband/core/cma.c:2044) rdma_cm [ 125.495072][ T1430] nvme_rdma_free_queue (drivers/nvme/host/rdma.c:656 drivers/nvme/host/rdma.c:650) nvme_rdma [ 125.505827][ T1430] nvme_rdma_reset_ctrl_work (drivers/nvme/host/rdma.c:2180) nvme_rdma [ 125.505831][ T1430] process_one_work (kernel/workqueue.c:3231) [ 125.515122][ T1430] worker_thread (kernel/workqueue.c:3306 kernel/workqueue.c:3393) [ 125.515127][ T1430] ? __pfx_worker_thread (kernel/workqueue.c:3339) [ 125.531837][ T1430] kthread (kernel/kthread.c:389) [ 125.539864][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.550628][ T1430] ret_from_fork (arch/x86/kernel/process.c:147) [ 125.558840][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.558844][ T1430] ret_from_fork_asm (arch/x86/entry/entry_64.S:257) [ 125.566487][ T1430] [ 125.566488][ T1430] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47755", "url": "https://ubuntu.com/security/CVE-2024-47755", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47756", "url": "https://ubuntu.com/security/CVE-2024-47756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: keystone: Fix if-statement expression in ks_pcie_quirk() This code accidentally uses && where || was intended. It potentially results in a NULL dereference. Thus, fix the if-statement expression to use the correct condition. [kwilczynski: commit log]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47697", "url": "https://ubuntu.com/security/CVE-2024-47697", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error Ensure index in rtl2830_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47698", "url": "https://ubuntu.com/security/CVE-2024-47698", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error Ensure index in rtl2832_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue. [hverkuil: added fixes tag, rtl2830_pid_filter -> rtl2832_pid_filter in logmsg]", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47728", "url": "https://ubuntu.com/security/CVE-2024-47728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error For all non-tracing helpers which formerly had ARG_PTR_TO_{LONG,INT} as input arguments, zero the value for the case of an error as otherwise it could leak memory. For tracing, it is not needed given CAP_PERFMON can already read all kernel memory anyway hence bpf_get_func_arg() and bpf_get_func_ret() is skipped in here. Also, the MTU helpers mtu_len pointer value is being written but also read. Technically, the MEM_UNINIT should not be there in order to always force init. Removing MEM_UNINIT needs more verifier rework though: MEM_UNINIT right now implies two things actually: i) write into memory, ii) memory does not have to be initialized. If we lift MEM_UNINIT, it then becomes: i) read into memory, ii) memory must be initialized. This means that for bpf_*_check_mtu() we're readding the issue we're trying to fix, that is, it would then be able to write back into things like .rodata BPF maps. Follow-up work will rework the MEM_UNINIT semantics such that the intent can be better expressed. For now just clear the *mtu_len on error path which can be lifted later again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49861", "url": "https://ubuntu.com/security/CVE-2024-49861", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix helper writes to read-only maps Lonial found an issue that despite user- and BPF-side frozen BPF map (like in case of .rodata), it was still possible to write into it from a BPF program side through specific helpers having ARG_PTR_TO_{LONG,INT} as arguments. In check_func_arg() when the argument is as mentioned, the meta->raw_mode is never set. Later, check_helper_mem_access(), under the case of PTR_TO_MAP_VALUE as register base type, it assumes BPF_READ for the subsequent call to check_map_access_type() and given the BPF map is read-only it succeeds. The helpers really need to be annotated as ARG_PTR_TO_{LONG,INT} | MEM_UNINIT when results are written into them as opposed to read out of them. The latter indicates that it's okay to pass a pointer to uninitialized memory as the memory is written to anyway. However, ARG_PTR_TO_{LONG,INT} is a special case of ARG_PTR_TO_FIXED_SIZE_MEM just with additional alignment requirement. So it is better to just get rid of the ARG_PTR_TO_{LONG,INT} special cases altogether and reuse the fixed size memory types. For this, add MEM_ALIGNED to additionally ensure alignment given these helpers write directly into the args via * = val. The .arg*_size has been initialized reflecting the actual sizeof(*). MEM_ALIGNED can only be used in combination with MEM_FIXED_SIZE annotated argument types, since in !MEM_FIXED_SIZE cases the verifier does not know the buffer size a priori and therefore cannot blindly write * = val.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47757", "url": "https://ubuntu.com/security/CVE-2024-47757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential oob read in nilfs_btree_check_delete() The function nilfs_btree_check_delete(), which checks whether degeneration to direct mapping occurs before deleting a b-tree entry, causes memory access outside the block buffer when retrieving the maximum key if the root node has no entries. This does not usually happen because b-tree mappings with 0 child nodes are never created by mkfs.nilfs2 or nilfs2 itself. However, it can happen if the b-tree root node read from a device is configured that way, so fix this potential issue by adding a check for that case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47699", "url": "https://ubuntu.com/security/CVE-2024-47699", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential null-ptr-deref in nilfs_btree_insert() Patch series \"nilfs2: fix potential issues with empty b-tree nodes\". This series addresses three potential issues with empty b-tree nodes that can occur with corrupted filesystem images, including one recently discovered by syzbot. This patch (of 3): If a b-tree is broken on the device, and the b-tree height is greater than 2 (the level of the root node is greater than 1) even if the number of child nodes of the b-tree root is 0, a NULL pointer dereference occurs in nilfs_btree_prepare_insert(), which is called from nilfs_btree_insert(). This is because, when the number of child nodes of the b-tree root is 0, nilfs_btree_do_lookup() does not set the block buffer head in any of path[x].bp_bh, leaving it as the initial value of NULL, but if the level of the b-tree root node is greater than 1, nilfs_btree_get_nonroot_node(), which accesses the buffer memory of path[x].bp_bh, is called. Fix this issue by adding a check to nilfs_btree_root_broken(), which performs sanity checks when reading the root node from the device, to detect this inconsistency. Thanks to Lizhi Xu for trying to solve the bug and clarifying the cause early on.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47700", "url": "https://ubuntu.com/security/CVE-2024-47700", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: check stripe size compatibility on remount as well We disable stripe size in __ext4_fill_super if it is not a multiple of the cluster ratio however this check is missed when trying to remount. This can leave us with cases where stripe < cluster_ratio after remount:set making EXT4_B2C(sbi->s_stripe) become 0 that can cause some unforeseen bugs like divide by 0. Fix that by adding the check in remount path as well.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47701", "url": "https://ubuntu.com/security/CVE-2024-47701", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid OOB when system.data xattr changes underneath the filesystem When looking up for an entry in an inlined directory, if e_value_offs is changed underneath the filesystem by some change in the block device, it will lead to an out-of-bounds access that KASAN detects as an UAF. EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none. loop0: detected capacity change from 2048 to 2047 ================================================================== BUG: KASAN: use-after-free in ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 Read of size 1 at addr ffff88803e91130f by task syz-executor269/5103 CPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 Not tainted 6.11.0-rc4-syzkaller #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:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 ext4_find_inline_entry+0x4be/0x5e0 fs/ext4/inline.c:1697 __ext4_find_entry+0x2b4/0x1b30 fs/ext4/namei.c:1573 ext4_lookup_entry fs/ext4/namei.c:1727 [inline] ext4_lookup+0x15f/0x750 fs/ext4/namei.c:1795 lookup_one_qstr_excl+0x11f/0x260 fs/namei.c:1633 filename_create+0x297/0x540 fs/namei.c:3980 do_symlinkat+0xf9/0x3a0 fs/namei.c:4587 __do_sys_symlinkat fs/namei.c:4610 [inline] __se_sys_symlinkat fs/namei.c:4607 [inline] __x64_sys_symlinkat+0x95/0xb0 fs/namei.c:4607 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:0x7f3e73ced469 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff4d40c258 EFLAGS: 00000246 ORIG_RAX: 000000000000010a RAX: ffffffffffffffda RBX: 0032656c69662f2e RCX: 00007f3e73ced469 RDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0 RBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290 R10: 0023706f6f6c2f76 R11: 0000000000000246 R12: 00007fff4d40c27c R13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0 Calling ext4_xattr_ibody_find right after reading the inode with ext4_get_inode_loc will lead to a check of the validity of the xattrs, avoiding this problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49850", "url": "https://ubuntu.com/security/CVE-2024-49850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: correctly handle malformed BPF_CORE_TYPE_ID_LOCAL relos In case of malformed relocation record of kind BPF_CORE_TYPE_ID_LOCAL referencing a non-existing BTF type, function bpf_core_calc_relo_insn would cause a null pointer deference. Fix this by adding a proper check upper in call stack, as malformed relocation records could be passed from user space. Simplest reproducer is a program: r0 = 0 exit With a single relocation record: .insn_off = 0, /* patch first instruction */ .type_id = 100500, /* this type id does not exist */ .access_str_off = 6, /* offset of string \"0\" */ .kind = BPF_CORE_TYPE_ID_LOCAL, See the link for original reproducer or next commit for a test case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47702", "url": "https://ubuntu.com/security/CVE-2024-47702", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fail verification for sign-extension of packet data/data_end/data_meta syzbot reported a kernel crash due to commit 1f1e864b6555 (\"bpf: Handle sign-extenstin ctx member accesses\"). The reason is due to sign-extension of 32-bit load for packet data/data_end/data_meta uapi field. The original code looks like: r2 = *(s32 *)(r1 + 76) /* load __sk_buff->data */ r3 = *(u32 *)(r1 + 80) /* load __sk_buff->data_end */ r0 = r2 r0 += 8 if r3 > r0 goto +1 ... Note that __sk_buff->data load has 32-bit sign extension. After verification and convert_ctx_accesses(), the final asm code looks like: r2 = *(u64 *)(r1 +208) r2 = (s32)r2 r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 ... Note that 'r2 = (s32)r2' may make the kernel __sk_buff->data address invalid which may cause runtime failure. Currently, in C code, typically we have void *data = (void *)(long)skb->data; void *data_end = (void *)(long)skb->data_end; ... and it will generate r2 = *(u64 *)(r1 +208) r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 If we allow sign-extension, void *data = (void *)(long)(int)skb->data; void *data_end = (void *)(long)skb->data_end; ... the generated code looks like r2 = *(u64 *)(r1 +208) r2 <<= 32 r2 s>>= 32 r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 and this will cause verification failure since \"r2 <<= 32\" is not allowed as \"r2\" is a packet pointer. To fix this issue for case r2 = *(s32 *)(r1 + 76) /* load __sk_buff->data */ this patch added additional checking in is_valid_access() callback function for packet data/data_end/data_meta access. If those accesses are with sign-extenstion, the verification will fail. [1] https://lore.kernel.org/bpf/000000000000c90eee061d236d37@google.com/", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47703", "url": "https://ubuntu.com/security/CVE-2024-47703", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, lsm: Add check for BPF LSM return value A bpf prog returning a positive number attached to file_alloc_security hook makes kernel panic. This happens because file system can not filter out the positive number returned by the LSM prog using IS_ERR, and misinterprets this positive number as a file pointer. Given that hook file_alloc_security never returned positive number before the introduction of BPF LSM, and other BPF LSM hooks may encounter similar issues, this patch adds LSM return value check in verifier, to ensure no unexpected value is returned.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49851", "url": "https://ubuntu.com/security/CVE-2024-49851", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: Clean up TPM space after command failure tpm_dev_transmit prepares the TPM space before attempting command transmission. However if the command fails no rollback of this preparation is done. This can result in transient handles being leaked if the device is subsequently closed with no further commands performed. Fix this by flushing the space in the event of command transmission failure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47723", "url": "https://ubuntu.com/security/CVE-2024-47723", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: fix out-of-bounds in dbNextAG() and diAlloc() In dbNextAG() , there is no check for the case where bmp->db_numag is greater or same than MAXAG due to a polluted image, which causes an out-of-bounds. Therefore, a bounds check should be added in dbMount(). And in dbNextAG(), a check for the case where agpref is greater than bmp->db_numag should be added, so an out-of-bounds exception should be prevented. Additionally, a check for the case where agno is greater or same than MAXAG should be added in diAlloc() to prevent out-of-bounds.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49852", "url": "https://ubuntu.com/security/CVE-2024-49852", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: elx: libefc: Fix potential use after free in efc_nport_vport_del() The kref_put() function will call nport->release if the refcount drops to zero. The nport->release release function is _efc_nport_free() which frees \"nport\". But then we dereference \"nport\" on the next line which is a use after free. Re-order these lines to avoid the use after free.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47720", "url": "https://ubuntu.com/security/CVE-2024-47720", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for set_output_gamma in dcn30_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn30_set_output_transfer_func function. Previously, set_output_gamma was being checked for nullity at line 386, but then it was being dereferenced without any nullity check at line 401. This could potentially lead to a null pointer dereference error if set_output_gamma is indeed null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a nullity check for set_output_gamma before the call to set_output_gamma at line 401. If set_output_gamma is null, we log an error message and do not call the function. This fix prevents a potential null pointer dereference error. drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:401 dcn30_set_output_transfer_func() error: we previously assumed 'mpc->funcs->set_output_gamma' could be null (see line 386) drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c 373 bool dcn30_set_output_transfer_func(struct dc *dc, 374 struct pipe_ctx *pipe_ctx, 375 const struct dc_stream_state *stream) 376 { 377 int mpcc_id = pipe_ctx->plane_res.hubp->inst; 378 struct mpc *mpc = pipe_ctx->stream_res.opp->ctx->dc->res_pool->mpc; 379 const struct pwl_params *params = NULL; 380 bool ret = false; 381 382 /* program OGAM or 3DLUT only for the top pipe*/ 383 if (pipe_ctx->top_pipe == NULL) { 384 /*program rmu shaper and 3dlut in MPC*/ 385 ret = dcn30_set_mpc_shaper_3dlut(pipe_ctx, stream); 386 if (ret == false && mpc->funcs->set_output_gamma) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If this is NULL 387 if (stream->out_transfer_func.type == TF_TYPE_HWPWL) 388 params = &stream->out_transfer_func.pwl; 389 else if (pipe_ctx->stream->out_transfer_func.type == 390 TF_TYPE_DISTRIBUTED_POINTS && 391 cm3_helper_translate_curve_to_hw_format( 392 &stream->out_transfer_func, 393 &mpc->blender_params, false)) 394 params = &mpc->blender_params; 395 /* there are no ROM LUTs in OUTGAM */ 396 if (stream->out_transfer_func.type == TF_TYPE_PREDEFINED) 397 BREAK_TO_DEBUGGER(); 398 } 399 } 400 --> 401 mpc->funcs->set_output_gamma(mpc, mpcc_id, params); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Then it will crash 402 return ret; 403 }", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47704", "url": "https://ubuntu.com/security/CVE-2024-47704", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check link_res->hpo_dp_link_enc before using it [WHAT & HOW] Functions dp_enable_link_phy and dp_disable_link_phy can pass link_res without initializing hpo_dp_link_enc and it is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49853", "url": "https://ubuntu.com/security/CVE-2024-49853", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix double free in OPTEE transport Channels can be shared between protocols, avoid freeing the same channel descriptors twice when unloading the stack.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47705", "url": "https://ubuntu.com/security/CVE-2024-47705", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix potential invalid pointer dereference in blk_add_partition The blk_add_partition() function initially used a single if-condition (IS_ERR(part)) to check for errors when adding a partition. This was modified to handle the specific case of -ENXIO separately, allowing the function to proceed without logging the error in this case. However, this change unintentionally left a path where md_autodetect_dev() could be called without confirming that part is a valid pointer. This commit separates the error handling logic by splitting the initial if-condition, improving code readability and handling specific error scenarios explicitly. The function now distinguishes the general error case from -ENXIO without altering the existing behavior of md_autodetect_dev() calls.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47736", "url": "https://ubuntu.com/security/CVE-2024-47736", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: handle overlapped pclusters out of crafted images properly syzbot reported a task hang issue due to a deadlock case where it is waiting for the folio lock of a cached folio that will be used for cache I/Os. After looking into the crafted fuzzed image, I found it's formed with several overlapped big pclusters as below: Ext: logical offset | length : physical offset | length 0: 0.. 16384 | 16384 : 151552.. 167936 | 16384 1: 16384.. 32768 | 16384 : 155648.. 172032 | 16384 2: 32768.. 49152 | 16384 : 537223168.. 537239552 | 16384 ... Here, extent 0/1 are physically overlapped although it's entirely _impossible_ for normal filesystem images generated by mkfs. First, managed folios containing compressed data will be marked as up-to-date and then unlocked immediately (unlike in-place folios) when compressed I/Os are complete. If physical blocks are not submitted in the incremental order, there should be separate BIOs to avoid dependency issues. However, the current code mis-arranges z_erofs_fill_bio_vec() and BIO submission which causes unexpected BIO waits. Second, managed folios will be connected to their own pclusters for efficient inter-queries. However, this is somewhat hard to implement easily if overlapped big pclusters exist. Again, these only appear in fuzzed images so let's simply fall back to temporary short-lived pages for correctness. Additionally, it justifies that referenced managed folios cannot be truncated for now and reverts part of commit 2080ca1ed3e4 (\"erofs: tidy up `struct z_erofs_bvec`\") for simplicity although it shouldn't be any difference.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47706", "url": "https://ubuntu.com/security/CVE-2024-47706", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block, bfq: fix possible UAF for bfqq->bic with merge chain 1) initial state, three tasks: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t\t | ? | ?\t\t | ? \t\t | | | |\t\t | | \t\t V | V |\t\t V | \t\t bfqq1 bfqq2\t\t bfqq3 process ref:\t 1\t\t 1\t\t 1 2) bfqq1 merged to bfqq2: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t\t | |\t\t | ? \t\t \\--------------\\|\t\t | | \t\t V\t\t V | \t\t bfqq1--------->bfqq2\t\t bfqq3 process ref:\t 0\t\t 2\t\t 1 3) bfqq2 merged to bfqq3: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t here -> ? |\t\t | \t\t \\--------------\\ \\-------------\\| \t\t V\t\t V \t\t bfqq1--------->bfqq2---------->bfqq3 process ref:\t 0\t\t 1\t\t 3 In this case, IO from Process 1 will get bfqq2 from BIC1 first, and then get bfqq3 through merge chain, and finially handle IO by bfqq3. Howerver, current code will think bfqq2 is owned by BIC1, like initial state, and set bfqq2->bic to BIC1. bfq_insert_request -> by Process 1 bfqq = bfq_init_rq(rq) bfqq = bfq_get_bfqq_handle_split bfqq = bic_to_bfqq -> get bfqq2 from BIC1 bfqq->ref++ rq->elv.priv[0] = bic rq->elv.priv[1] = bfqq if (bfqq_process_refs(bfqq) == 1) bfqq->bic = bic -> record BIC1 to bfqq2 __bfq_insert_request new_bfqq = bfq_setup_cooperator -> get bfqq3 from bfqq2->new_bfqq bfqq_request_freed(bfqq) new_bfqq->ref++ rq->elv.priv[1] = new_bfqq -> handle IO by bfqq3 Fix the problem by checking bfqq is from merge chain fist. And this might fix a following problem reported by our syzkaller(unreproducible): ================================================================== BUG: KASAN: slab-use-after-free in bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] BUG: KASAN: slab-use-after-free in bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] BUG: KASAN: slab-use-after-free in bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 Write of size 1 at addr ffff888123839eb8 by task kworker/0:1H/18595 CPU: 0 PID: 18595 Comm: kworker/0:1H Tainted: G L 6.6.0-07439-gba2303cacfda #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Workqueue: kblockd blk_mq_requeue_work Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [inline] print_report+0x10d/0x610 mm/kasan/report.c:475 kasan_report+0x8e/0xc0 mm/kasan/report.c:588 bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 bfq_get_bfqq_handle_split+0x169/0x5d0 block/bfq-iosched.c:6757 bfq_init_rq block/bfq-iosched.c:6876 [inline] bfq_insert_request block/bfq-iosched.c:6254 [inline] bfq_insert_requests+0x1112/0x5cf0 block/bfq-iosched.c:6304 blk_mq_insert_request+0x290/0x8d0 block/blk-mq.c:2593 blk_mq_requeue_work+0x6bc/0xa70 block/blk-mq.c:1502 process_one_work kernel/workqueue.c:2627 [inline] process_scheduled_works+0x432/0x13f0 kernel/workqueue.c:2700 worker_thread+0x6f2/0x1160 kernel/workqueue.c:2781 kthread+0x33c/0x440 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:305 Allocated by task 20776: kasan_save_stack+0x20/0x40 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 __kasan_slab_alloc+0x87/0x90 mm/kasan/common.c:328 kasan_slab_alloc include/linux/kasan.h:188 [inline] slab_post_alloc_hook mm/slab.h:763 [inline] slab_alloc_node mm/slub.c:3458 [inline] kmem_cache_alloc_node+0x1a4/0x6f0 mm/slub.c:3503 ioc_create_icq block/blk-ioc.c:370 [inline] ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49855", "url": "https://ubuntu.com/security/CVE-2024-49855", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: fix race between timeout and normal completion If request timetout is handled by nbd_requeue_cmd(), normal completion has to be stopped for avoiding to complete this requeued request, other use-after-free can be triggered. Fix the race by clearing NBD_CMD_INFLIGHT in nbd_requeue_cmd(), meantime make sure that cmd->lock is grabbed for clearing the flag and the requeue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47707", "url": "https://ubuntu.com/security/CVE-2024-47707", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev() Blamed commit accidentally removed a check for rt->rt6i_idev being NULL, as spotted by syzbot: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 UID: 0 PID: 10998 Comm: syz-executor Not tainted 6.11.0-rc6-syzkaller-00208-g625403177711 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 RBP: ffffc900047375d0 R08: 0000000000000003 R09: fffff520008e6e8c R10: dffffc0000000000 R11: fffff520008e6e8c R12: 1ffff1100fdf8f18 R13: ffff88807efc7998 R14: 0000000000000000 R15: ffff88807efc7930 FS: 0000000000000000(0000) GS:ffff8880b8900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020002a80 CR3: 0000000022f62000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: addrconf_ifdown+0x15d/0x1bd0 net/ipv6/addrconf.c:3856 addrconf_notify+0x3cb/0x1020 notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93 call_netdevice_notifiers_extack net/core/dev.c:2032 [inline] call_netdevice_notifiers net/core/dev.c:2046 [inline] unregister_netdevice_many_notify+0xd81/0x1c40 net/core/dev.c:11352 unregister_netdevice_many net/core/dev.c:11414 [inline] unregister_netdevice_queue+0x303/0x370 net/core/dev.c:11289 unregister_netdevice include/linux/netdevice.h:3129 [inline] __tun_detach+0x6b9/0x1600 drivers/net/tun.c:685 tun_detach drivers/net/tun.c:701 [inline] tun_chr_close+0x108/0x1b0 drivers/net/tun.c:3510 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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:0x7f1acc77def9 Code: Unable to access opcode bytes at 0x7f1acc77decf. RSP: 002b:00007ffeb26fa738 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1acc77def9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000043 RBP: 00007f1acc7dd508 R08: 00007ffeb26f84d7 R09: 0000000000000003 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 0000000000000003 R14: 00000000ffffffff R15: 00007ffeb26fa8e0 Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 R ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47708", "url": "https://ubuntu.com/security/CVE-2024-47708", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netkit: Assign missing bpf_net_context During the introduction of struct bpf_net_context handling for XDP-redirect, the netkit driver has been missed, which also requires it because NETKIT_REDIRECT invokes skb_do_redirect() which is accessing the per-CPU variables. Otherwise we see the following crash: \tBUG: kernel NULL pointer dereference, address: 0000000000000038 \tbpf_redirect() \tnetkit_xmit() \tdev_hard_start_xmit() Set the bpf_net_context before invoking netkit_xmit() program within the netkit driver.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47709", "url": "https://ubuntu.com/security/CVE-2024-47709", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: Clear bo->bcm_proc_read after remove_proc_entry(). syzbot reported a warning in bcm_release(). [0] The blamed change fixed another warning that is triggered when connect() is issued again for a socket whose connect()ed device has been unregistered. However, if the socket is just close()d without the 2nd connect(), the remaining bo->bcm_proc_read triggers unnecessary remove_proc_entry() in bcm_release(). Let's clear bo->bcm_proc_read after remove_proc_entry() in bcm_notify(). [0] name '4986' WARNING: CPU: 0 PID: 5234 at fs/proc/generic.c:711 remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Modules linked in: CPU: 0 UID: 0 PID: 5234 Comm: syz-executor606 Not tainted 6.11.0-rc5-syzkaller-00178-g5517ae241919 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Code: ff eb 05 e8 cb 1e 5e ff 48 8b 5c 24 10 48 c7 c7 e0 f7 aa 8e e8 2a 38 8e 09 90 48 c7 c7 60 3a 1b 8c 48 89 de e8 da 42 20 ff 90 <0f> 0b 90 90 48 8b 44 24 18 48 c7 44 24 40 0e 36 e0 45 49 c7 04 07 RSP: 0018:ffffc9000345fa20 EFLAGS: 00010246 RAX: 2a2d0aee2eb64600 RBX: ffff888032f1f548 RCX: ffff888029431e00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000345fb08 R08: ffffffff8155b2f2 R09: 1ffff1101710519a R10: dffffc0000000000 R11: ffffed101710519b R12: ffff888011d38640 R13: 0000000000000004 R14: 0000000000000000 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8880b8800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcfb52722f0 CR3: 000000000e734000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: bcm_release+0x250/0x880 net/can/bcm.c:1578 __sock_release net/socket.c:659 [inline] sock_close+0xbc/0x240 net/socket.c:1421 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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:0x7fcfb51ee969 Code: Unable to access opcode bytes at 0x7fcfb51ee93f. RSP: 002b:00007ffce0109ca8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fcfb51ee969 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 00007fcfb526f3b0 R08: ffffffffffffffb8 R09: 0000555500000000 R10: 0000555500000000 R11: 0000000000000246 R12: 00007fcfb526f3b0 R13: 0000000000000000 R14: 00007fcfb5271ee0 R15: 00007fcfb51bf160 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47710", "url": "https://ubuntu.com/security/CVE-2024-47710", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sock_map: Add a cond_resched() in sock_hash_free() Several syzbot soft lockup reports all have in common sock_hash_free() If a map with a large number of buckets is destroyed, we need to yield the cpu when needed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47711", "url": "https://ubuntu.com/security/CVE-2024-47711", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Don't return OOB skb in manage_oob(). syzbot reported use-after-free in unix_stream_recv_urg(). [0] The scenario is 1. send(MSG_OOB) 2. recv(MSG_OOB) -> The consumed OOB remains in recv queue 3. send(MSG_OOB) 4. recv() -> manage_oob() returns the next skb of the consumed OOB -> This is also OOB, but unix_sk(sk)->oob_skb is not cleared 5. recv(MSG_OOB) -> unix_sk(sk)->oob_skb is used but already freed The recent commit 8594d9b85c07 (\"af_unix: Don't call skb_get() for OOB skb.\") uncovered the issue. If the OOB skb is consumed and the next skb is peeked in manage_oob(), we still need to check if the skb is OOB. Let's do so by falling back to the following checks in manage_oob() and add the test case in selftest. Note that we need to add a similar check for SIOCATMARK. [0]: BUG: KASAN: slab-use-after-free in unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959 Read of size 4 at addr ffff8880326abcc4 by task syz-executor178/5235 CPU: 0 UID: 0 PID: 5235 Comm: syz-executor178 Not tainted 6.11.0-rc5-syzkaller-00742-gfbdaffe41adc #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959 unix_stream_recv_urg+0x1df/0x320 net/unix/af_unix.c:2640 unix_stream_read_generic+0x2456/0x2520 net/unix/af_unix.c:2778 unix_stream_recvmsg+0x22b/0x2c0 net/unix/af_unix.c:2996 sock_recvmsg_nosec net/socket.c:1046 [inline] sock_recvmsg+0x22f/0x280 net/socket.c:1068 ____sys_recvmsg+0x1db/0x470 net/socket.c:2816 ___sys_recvmsg net/socket.c:2858 [inline] __sys_recvmsg+0x2f0/0x3e0 net/socket.c:2888 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:0x7f5360d6b4e9 Code: 48 83 c4 28 c3 e8 37 17 00 00 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff29b3a458 EFLAGS: 00000246 ORIG_RAX: 000000000000002f RAX: ffffffffffffffda RBX: 00007fff29b3a638 RCX: 00007f5360d6b4e9 RDX: 0000000000002001 RSI: 0000000020000640 RDI: 0000000000000003 RBP: 00007f5360dde610 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 00007fff29b3a628 R14: 0000000000000001 R15: 0000000000000001 Allocated by task 5235: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:312 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slub.c:3988 [inline] slab_alloc_node mm/slub.c:4037 [inline] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4080 __alloc_skb+0x1c3/0x440 net/core/skbuff.c:667 alloc_skb include/linux/skbuff.h:1320 [inline] alloc_skb_with_frags+0xc3/0x770 net/core/skbuff.c:6528 sock_alloc_send_pskb+0x91a/0xa60 net/core/sock.c:2815 sock_alloc_send_skb include/net/sock.h:1778 [inline] queue_oob+0x108/0x680 net/unix/af_unix.c:2198 unix_stream_sendmsg+0xd24/0xf80 net/unix/af_unix.c:2351 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2680 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 Freed by task 5235: kasan_save_stack mm/kasan/common.c:47 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47712", "url": "https://ubuntu.com/security/CVE-2024-47712", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: fix potential RCU dereference issue in wilc_parse_join_bss_param In the `wilc_parse_join_bss_param` function, the TSF field of the `ies` structure is accessed after the RCU read-side critical section is unlocked. According to RCU usage rules, this is illegal. Reusing this pointer can lead to unpredictable behavior, including accessing memory that has been updated or causing use-after-free issues. This possible bug was identified using a static analysis tool developed by myself, specifically designed to detect RCU-related issues. To address this, the TSF value is now stored in a local variable `ies_tsf` before the RCU lock is released. The `param->tsf_lo` field is then assigned using this local variable, ensuring that the TSF value is safely accessed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47713", "url": "https://ubuntu.com/security/CVE-2024-47713", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop() Since '__dev_queue_xmit()' should be called with interrupts enabled, the following backtrace: ieee80211_do_stop() ... spin_lock_irqsave(&local->queue_stop_reason_lock, flags) ... ieee80211_free_txskb() ieee80211_report_used_skb() ieee80211_report_ack_skb() cfg80211_mgmt_tx_status_ext() nl80211_frame_tx_status() genlmsg_multicast_netns() genlmsg_multicast_netns_filtered() nlmsg_multicast_filtered() \t netlink_broadcast_filtered() \t do_one_broadcast() \t netlink_broadcast_deliver() \t __netlink_sendskb() \t netlink_deliver_tap() \t __netlink_deliver_tap_skb() \t dev_queue_xmit() \t __dev_queue_xmit() ; with IRQS disabled ... spin_unlock_irqrestore(&local->queue_stop_reason_lock, flags) issues the warning (as reported by syzbot reproducer): WARNING: CPU: 2 PID: 5128 at kernel/softirq.c:362 __local_bh_enable_ip+0xc3/0x120 Fix this by implementing a two-phase skb reclamation in 'ieee80211_do_stop()', where actual work is performed outside of a section with interrupts disabled.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47730", "url": "https://ubuntu.com/security/CVE-2024-47730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/qm - inject error before stopping queue The master ooo cannot be completely closed when the accelerator core reports memory error. Therefore, the driver needs to inject the qm error to close the master ooo. Currently, the qm error is injected after stopping queue, memory may be released immediately after stopping queue, causing the device to access the released memory. Therefore, error is injected to close master ooo before stopping queue to ensure that the device does not access the released memory.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49856", "url": "https://ubuntu.com/security/CVE-2024-49856", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/sgx: Fix deadlock in SGX NUMA node search When the current node doesn't have an EPC section configured by firmware and all other EPC sections are used up, CPU can get stuck inside the while loop that looks for an available EPC page from remote nodes indefinitely, leading to a soft lockup. Note how nid_of_current will never be equal to nid in that while loop because nid_of_current is not set in sgx_numa_mask. Also worth mentioning is that it's perfectly fine for the firmware not to setup an EPC section on a node. While setting up an EPC section on each node can enhance performance, it is not a requirement for functionality. Rework the loop to start and end on *a* node that has SGX memory. This avoids the deadlock looking for the current SGX-lacking node to show up in the loop when it never will.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47714", "url": "https://ubuntu.com/security/CVE-2024-47714", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: use hweight16 to get correct tx antenna The chainmask is u16 so using hweight8 cannot get correct tx_ant. Without this patch, the tx_ant of band 2 would be -1 and lead to the following issue: BUG: KASAN: stack-out-of-bounds in mt7996_mcu_add_sta+0x12e0/0x16e0 [mt7996e]", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47715", "url": "https://ubuntu.com/security/CVE-2024-47715", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: fix oops on non-dbdc mt7986 mt7915_band_config() sets band_idx = 1 on the main phy for mt7986 with MT7975_ONE_ADIE or MT7976_ONE_ADIE. Commit 0335c034e726 (\"wifi: mt76: fix race condition related to checking tx queue fill status\") introduced a dereference of the phys array indirectly indexed by band_idx via wcid->phy_idx in mt76_wcid_cleanup(). This caused the following Oops on affected mt7986 devices: Unable to handle kernel read from unreadable memory at virtual address 0000000000000024 Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x00000005 CM = 0, WnR = 0 user pgtable: 4k pages, 39-bit VAs, pgdp=0000000042545000 [0000000000000024] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 Internal error: Oops: 0000000096000005 [#1] SMP Modules linked in: ... mt7915e mt76_connac_lib mt76 mac80211 cfg80211 ... CPU: 2 PID: 1631 Comm: hostapd Not tainted 5.15.150 #0 Hardware name: ZyXEL EX5700 (Telenor) (DT) pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mt76_wcid_cleanup+0x84/0x22c [mt76] lr : mt76_wcid_cleanup+0x64/0x22c [mt76] sp : ffffffc00a803700 x29: ffffffc00a803700 x28: ffffff80008f7300 x27: ffffff80003f3c00 x26: ffffff80000a7880 x25: ffffffc008c26e00 x24: 0000000000000001 x23: ffffffc000a68114 x22: 0000000000000000 x21: ffffff8004172cc8 x20: ffffffc00a803748 x19: ffffff8004152020 x18: 0000000000000000 x17: 00000000000017c0 x16: ffffffc008ef5000 x15: 0000000000000be0 x14: ffffff8004172e28 x13: ffffff8004172e28 x12: 0000000000000000 x11: 0000000000000000 x10: ffffff8004172e30 x9 : ffffff8004172e28 x8 : 0000000000000000 x7 : ffffff8004156020 x6 : 0000000000000000 x5 : 0000000000000031 x4 : 0000000000000000 x3 : 0000000000000001 x2 : 0000000000000000 x1 : ffffff80008f7300 x0 : 0000000000000024 Call trace: mt76_wcid_cleanup+0x84/0x22c [mt76] __mt76_sta_remove+0x70/0xbc [mt76] mt76_sta_state+0x8c/0x1a4 [mt76] mt7915_eeprom_get_power_delta+0x11e4/0x23a0 [mt7915e] drv_sta_state+0x144/0x274 [mac80211] sta_info_move_state+0x1cc/0x2a4 [mac80211] sta_set_sinfo+0xaf8/0xc24 [mac80211] sta_info_destroy_addr_bss+0x4c/0x6c [mac80211] ieee80211_color_change_finish+0x1c08/0x1e70 [mac80211] cfg80211_check_station_change+0x1360/0x4710 [cfg80211] genl_family_rcv_msg_doit+0xb4/0x110 genl_rcv_msg+0xd0/0x1bc netlink_rcv_skb+0x58/0x120 genl_rcv+0x34/0x50 netlink_unicast+0x1f0/0x2ec netlink_sendmsg+0x198/0x3d0 ____sys_sendmsg+0x1b0/0x210 ___sys_sendmsg+0x80/0xf0 __sys_sendmsg+0x44/0xa0 __arm64_sys_sendmsg+0x20/0x30 invoke_syscall.constprop.0+0x4c/0xe0 do_el0_svc+0x40/0xd0 el0_svc+0x14/0x4c el0t_64_sync_handler+0x100/0x110 el0t_64_sync+0x15c/0x160 Code: d2800002 910092c0 52800023 f9800011 (885f7c01) ---[ end trace 7e42dd9a39ed2281 ]--- Fix by using mt76_dev_phy() which will map band_idx to the correct phy for all hardware combinations.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49857", "url": "https://ubuntu.com/security/CVE-2024-49857", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: set the cipher for secured NDP ranging The cipher pointer is not set, but is derefereced trying to set its content, which leads to a NULL pointer dereference. Fix it by pointing to the cipher parameter before dereferencing.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47738", "url": "https://ubuntu.com/security/CVE-2024-47738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: don't use rate mask for offchannel TX either Like the commit ab9177d83c04 (\"wifi: mac80211: don't use rate mask for scanning\"), ignore incorrect settings to avoid no supported rate warning reported by syzbot. The syzbot did bisect and found cause is commit 9df66d5b9f45 (\"cfg80211: fix default HE tx bitrate mask in 2G band\"), which however corrects bitmask of HE MCS and recognizes correctly settings of empty legacy rate plus HE MCS rate instead of returning -EINVAL. As suggestions [1], follow the change of SCAN TX to consider this case of offchannel TX as well. [1] https://lore.kernel.org/linux-wireless/6ab2dc9c3afe753ca6fdcdd1421e7a1f47e87b84.camel@sipsolutions.net/T/#m2ac2a6d2be06a37c9c47a3d8a44b4f647ed4f024", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47731", "url": "https://ubuntu.com/security/CVE-2024-47731", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers/perf: Fix ali_drw_pmu driver interrupt status clearing The alibaba_uncore_pmu driver forgot to clear all interrupt status in the interrupt processing function. After the PMU counter overflow interrupt occurred, an interrupt storm occurred, causing the system to hang. Therefore, clear the correct interrupt status in the interrupt handling function to fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49862", "url": "https://ubuntu.com/security/CVE-2024-49862", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powercap: intel_rapl: Fix off by one in get_rpi() The rp->priv->rpi array is either rpi_msr or rpi_tpmi which have NR_RAPL_PRIMITIVES number of elements. Thus the > needs to be >= to prevent an off by one access.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47716", "url": "https://ubuntu.com/security/CVE-2024-47716", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: 9410/1: vfp: Use asm volatile in fmrx/fmxr macros Floating point instructions in userspace can crash some arm kernels built with clang/LLD 17.0.6: BUG: unsupported FP instruction in kernel mode FPEXC == 0xc0000780 Internal error: Oops - undefined instruction: 0 [#1] ARM CPU: 0 PID: 196 Comm: vfp-reproducer Not tainted 6.10.0 #1 Hardware name: BCM2835 PC is at vfp_support_entry+0xc8/0x2cc LR is at do_undefinstr+0xa8/0x250 pc : [] lr : [] psr: a0000013 sp : dc8d1f68 ip : 60000013 fp : bedea19c r10: ec532b17 r9 : 00000010 r8 : 0044766c r7 : c0000780 r6 : ec532b17 r5 : c1c13800 r4 : dc8d1fb0 r3 : c10072c4 r2 : c0101c88 r1 : ec532b17 r0 : 0044766c Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 00c5387d Table: 0251c008 DAC: 00000051 Register r0 information: non-paged memory Register r1 information: vmalloc memory Register r2 information: non-slab/vmalloc memory Register r3 information: non-slab/vmalloc memory Register r4 information: 2-page vmalloc region Register r5 information: slab kmalloc-cg-2k Register r6 information: vmalloc memory Register r7 information: non-slab/vmalloc memory Register r8 information: non-paged memory Register r9 information: zero-size pointer Register r10 information: vmalloc memory Register r11 information: non-paged memory Register r12 information: non-paged memory Process vfp-reproducer (pid: 196, stack limit = 0x61aaaf8b) Stack: (0xdc8d1f68 to 0xdc8d2000) 1f60: 0000081f b6f69300 0000000f c10073f4 c10072c4 dc8d1fb0 1f80: ec532b17 0c532b17 0044766c b6f9ccd8 00000000 c010a80c 00447670 60000010 1fa0: ffffffff c1c13800 00c5387d c0100f10 b6f68af8 00448fc0 00000000 bedea188 1fc0: bedea314 00000001 00448ebc b6f9d000 00447608 b6f9ccd8 00000000 bedea19c 1fe0: bede9198 bedea188 b6e1061c 0044766c 60000010 ffffffff 00000000 00000000 Call trace: [] (vfp_support_entry) from [] (do_undefinstr+0xa8/0x250) [] (do_undefinstr) from [] (__und_usr+0x70/0x80) Exception stack(0xdc8d1fb0 to 0xdc8d1ff8) 1fa0: b6f68af8 00448fc0 00000000 bedea188 1fc0: bedea314 00000001 00448ebc b6f9d000 00447608 b6f9ccd8 00000000 bedea19c 1fe0: bede9198 bedea188 b6e1061c 0044766c 60000010 ffffffff Code: 0a000061 e3877202 e594003c e3a09010 (eef16a10) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Fatal exception in interrupt ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]--- This is a minimal userspace reproducer on a Raspberry Pi Zero W: #include #include int main(void) { double v = 1.0; printf(\"%fn\", NAN + *(volatile double *)&v); return 0; } Another way to consistently trigger the oops is: calvin@raspberry-pi-zero-w ~$ python -c \"import json\" The bug reproduces only when the kernel is built with DYNAMIC_DEBUG=n, because the pr_debug() calls act as barriers even when not activated. This is the output from the same kernel source built with the same compiler and DYNAMIC_DEBUG=y, where the userspace reproducer works as expected: VFP: bounce: trigger ec532b17 fpexc c0000780 VFP: emulate: INST=0xee377b06 SCR=0x00000000 VFP: bounce: trigger eef1fa10 fpexc c0000780 VFP: emulate: INST=0xeeb40b40 SCR=0x00000000 VFP: raising exceptions 30000000 calvin@raspberry-pi-zero-w ~$ ./vfp-reproducer nan Crudely grepping for vmsr/vmrs instructions in the otherwise nearly idential text for vfp_support_entry() makes the problem obvious: vmlinux.llvm.good [0xc0101cb8] <+48>: vmrs r7, fpexc vmlinux.llvm.good [0xc0101cd8] <+80>: vmsr fpexc, r0 vmlinux.llvm.good [0xc0101d20 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47717", "url": "https://ubuntu.com/security/CVE-2024-47717", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RISC-V: KVM: Don't zero-out PMU snapshot area before freeing data With the latest Linux-6.11-rc3, the below NULL pointer crash is observed when SBI PMU snapshot is enabled for the guest and the guest is forcefully powered-off. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000508 Oops [#1] Modules linked in: kvm CPU: 0 UID: 0 PID: 61 Comm: term-poll Not tainted 6.11.0-rc3-00018-g44d7178dd77a #3 Hardware name: riscv-virtio,qemu (DT) epc : __kvm_write_guest_page+0x94/0xa6 [kvm] ra : __kvm_write_guest_page+0x54/0xa6 [kvm] epc : ffffffff01590e98 ra : ffffffff01590e58 sp : ffff8f80001f39b0 gp : ffffffff81512a60 tp : ffffaf80024872c0 t0 : ffffaf800247e000 t1 : 00000000000007e0 t2 : 0000000000000000 s0 : ffff8f80001f39f0 s1 : 00007fff89ac4000 a0 : ffffffff015dd7e8 a1 : 0000000000000086 a2 : 0000000000000000 a3 : ffffaf8000000000 a4 : ffffaf80024882c0 a5 : 0000000000000000 a6 : ffffaf800328d780 a7 : 00000000000001cc s2 : ffffaf800197bd00 s3 : 00000000000828c4 s4 : ffffaf800248c000 s5 : ffffaf800247d000 s6 : 0000000000001000 s7 : 0000000000001000 s8 : 0000000000000000 s9 : 00007fff861fd500 s10: 0000000000000001 s11: 0000000000800000 t3 : 00000000000004d3 t4 : 00000000000004d3 t5 : ffffffff814126e0 t6 : ffffffff81412700 status: 0000000200000120 badaddr: 0000000000000508 cause: 000000000000000d [] __kvm_write_guest_page+0x94/0xa6 [kvm] [] kvm_vcpu_write_guest+0x56/0x90 [kvm] [] kvm_pmu_clear_snapshot_area+0x42/0x7e [kvm] [] kvm_riscv_vcpu_pmu_deinit.part.0+0xe0/0x14e [kvm] [] kvm_riscv_vcpu_pmu_deinit+0x1a/0x24 [kvm] [] kvm_arch_vcpu_destroy+0x28/0x4c [kvm] [] kvm_destroy_vcpus+0x5a/0xda [kvm] [] kvm_arch_destroy_vm+0x14/0x28 [kvm] [] kvm_destroy_vm+0x168/0x2a0 [kvm] [] kvm_put_kvm+0x3c/0x58 [kvm] [] kvm_vm_release+0x22/0x2e [kvm] Clearly, the kvm_vcpu_write_guest() function is crashing because it is being called from kvm_pmu_clear_snapshot_area() upon guest tear down. To address the above issue, simplify the kvm_pmu_clear_snapshot_area() to not zero-out PMU snapshot area from kvm_pmu_clear_snapshot_area() because the guest is anyway being tore down. The kvm_pmu_clear_snapshot_area() is also called when guest changes PMU snapshot area of a VCPU but even in this case the previous PMU snaphsot area must not be zeroed-out because the guest might have reclaimed the pervious PMU snapshot area for some other purpose.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47721", "url": "https://ubuntu.com/security/CVE-2024-47721", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: remove unused C2H event ID RTW89_MAC_C2H_FUNC_READ_WOW_CAM to prevent out-of-bounds reading The handler of firmware C2H event RTW89_MAC_C2H_FUNC_READ_WOW_CAM isn't implemented, but driver expects number of handlers is NUM_OF_RTW89_MAC_C2H_FUNC_WOW causing out-of-bounds access. Fix it by removing ID. Addresses-Coverity-ID: 1598775 (\"Out-of-bounds read\")", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47732", "url": "https://ubuntu.com/security/CVE-2024-47732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: iaa - Fix potential use after free bug The free_device_compression_mode(iaa_device, device_mode) function frees \"device_mode\" but it iss passed to iaa_compression_modes[i]->free() a few lines later resulting in a use after free. The good news is that, so far as I can tell, nothing implements the ->free() function and the use after free happens in dead code. But, with this fix, when something does implement it, we'll be ready. :)", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47718", "url": "https://ubuntu.com/security/CVE-2024-47718", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: always wait for both firmware loading attempts In 'rtw_wait_firmware_completion()', always wait for both (regular and wowlan) firmware loading attempts. Otherwise if 'rtw_usb_intf_init()' has failed in 'rtw_usb_probe()', 'rtw_usb_disconnect()' may issue 'ieee80211_free_hw()' when one of 'rtw_load_firmware_cb()' (usually the wowlan one) is still in progress, causing UAF detected by KASAN.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47724", "url": "https://ubuntu.com/security/CVE-2024-47724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: use work queue to process beacon tx event Commit 3a415daa3e8b (\"wifi: ath11k: add P2P IE in beacon template\") from Feb 28, 2024 (linux-next), leads to the following Smatch static checker warning: drivers/net/wireless/ath/ath11k/wmi.c:1742 ath11k_wmi_p2p_go_bcn_ie() warn: sleeping in atomic context The reason is that ath11k_bcn_tx_status_event() will directly call might sleep function ath11k_wmi_cmd_send() during RCU read-side critical sections. The call trace is like: ath11k_bcn_tx_status_event() -> rcu_read_lock() -> ath11k_mac_bcn_tx_event() \t-> ath11k_mac_setup_bcn_tmpl() \t…… \t\t-> ath11k_wmi_bcn_tmpl() \t\t\t-> ath11k_wmi_cmd_send() -> rcu_read_unlock() Commit 886433a98425 (\"ath11k: add support for BSS color change\") added the ath11k_mac_bcn_tx_event(), commit 01e782c89108 (\"ath11k: fix warning of RCU usage for ath11k_mac_get_arvif_by_vdev_id()\") added the RCU lock to avoid warning but also introduced this BUG. Use work queue to avoid directly calling ath11k_mac_bcn_tx_event() during RCU critical sections. No need to worry about the deletion of vif because cancel_work_sync() will drop the work if it doesn't start or block vif deletion until the running work is done. 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": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47671", "url": "https://ubuntu.com/security/CVE-2024-47671", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: usbtmc: prevent kernel-usb-infoleak The syzbot reported a kernel-usb-infoleak in usbtmc_write, we need to clear the structure before filling fields.", "cve_priority": "medium", "cve_public_date": "2024-10-09 15:15:00 UTC" }, { "cve": "CVE-2024-46869", "url": "https://ubuntu.com/security/CVE-2024-46869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btintel_pcie: Allocate memory for driver private data Fix driver not allocating memory for struct btintel_data which is used to store internal data.", "cve_priority": "medium", "cve_public_date": "2024-09-30 16:15:00 UTC" }, { "cve": "CVE-2024-53164", "url": "https://ubuntu.com/security/CVE-2024-53164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: fix ordering of qlen adjustment Changes to sch->q.qlen around qdisc_tree_reduce_backlog() need to happen _before_ a call to said function because otherwise it may fail to notify parent qdiscs when the child is about to become empty.", "cve_priority": "medium", "cve_public_date": "2024-12-27 14:15:00 UTC" }, { "cve": "CVE-2024-53103", "url": "https://ubuntu.com/security/CVE-2024-53103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hv_sock: Initializing vsk->trans to NULL to prevent a dangling pointer When hvs is released, there is a possibility that vsk->trans may not be initialized to NULL, which could lead to a dangling pointer. This issue is resolved by initializing vsk->trans to NULL.", "cve_priority": "high", "cve_public_date": "2024-12-02 08:15:00 UTC" } ], "launchpad_bugs_fixed": [ 2093643, 1786013, 2091744, 2091184, 2093146, 2085406, 2089684, 2090932, 2085485, 2089357, 2089306, 2091655, 2091655, 2091655, 2091655, 2091655, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091386, 2091990, 2089327, 2089113, 2086587, 2086606, 2085950, 2085944, 2087853, 2087983, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089020, 2089020, 2089020 ], "changes": [ { "cves": [ { "cve": "CVE-2025-0927", "url": "https://ubuntu.com/security/CVE-2025-0927", "cve_description": "[fs: hfs/hfsplus: add key_len boundary check to hfs_bnode_read_key]", "cve_priority": "medium", "cve_public_date": "2025-02-13" } ], "log": [ "", " * CVE-2025-0927", " - SAUCE: fs: hfs/hfsplus: add key_len boundary check to hfs_bnode_read_key", "" ], "package": "linux", "version": "6.11.0-18.18", "urgency": "medium", "distributions": "oracular", "launchpad_bugs_fixed": [], "author": "Manuel Diewald ", "date": "Fri, 07 Feb 2025 18:44:32 +0100" }, { "cves": [ { "cve": "CVE-2024-53141", "url": "https://ubuntu.com/security/CVE-2024-53141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: add missing range check in bitmap_ip_uadt When tb[IPSET_ATTR_IP_TO] is not present but tb[IPSET_ATTR_CIDR] exists, the values of ip and ip_to are slightly swapped. Therefore, the range check for ip should be done later, but this part is missing and it seems that the vulnerability occurs. So we should add missing range checks and remove unnecessary range checks.", "cve_priority": "medium", "cve_public_date": "2024-12-06 10:15:00 UTC" }, { "cve": "CVE-2024-50010", "url": "https://ubuntu.com/security/CVE-2024-50010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exec: don't WARN for racy path_noexec check Both i_mode and noexec checks wrapped in WARN_ON stem from an artifact of the previous implementation. They used to legitimately check for the condition, but that got moved up in two commits: 633fb6ac3980 (\"exec: move S_ISREG() check earlier\") 0fd338b2d2cd (\"exec: move path_noexec() check earlier\") Instead of being removed said checks are WARN_ON'ed instead, which has some debug value. However, the spurious path_noexec check is racy, resulting in unwarranted warnings should someone race with setting the noexec flag. One can note there is more to perm-checking whether execve is allowed and none of the conditions are guaranteed to still hold after they were tested for. Additionally this does not validate whether the code path did any perm checking to begin with -- it will pass if the inode happens to be regular. Keep the redundant path_noexec() check even though it's mindless nonsense checking for guarantee that isn't given so drop the WARN. Reword the commentary and do small tidy ups while here. [brauner: keep redundant path_noexec() check]", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-53143", "url": "https://ubuntu.com/security/CVE-2024-53143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fsnotify: Fix ordering of iput() and watched_objects decrement Ensure the superblock is kept alive until we're done with iput(). Holding a reference to an inode is not allowed unless we ensure the superblock stays alive, which fsnotify does by keeping the watched_objects count elevated, so iput() must happen before the watched_objects decrement. This can lead to a UAF of something like sb->s_fs_info in tmpfs, but the UAF is hard to hit because race orderings that oops are more likely, thanks to the CHECK_DATA_CORRUPTION() block in generic_shutdown_super(). Also, ensure that fsnotify_put_sb_watched_objects() doesn't call fsnotify_sb_watched_objects() on a superblock that may have already been freed, which would cause a UAF read of sb->s_fsnotify_info.", "cve_priority": "medium", "cve_public_date": "2024-12-07 07:15:00 UTC" }, { "cve": "CVE-2024-53142", "url": "https://ubuntu.com/security/CVE-2024-53142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: initramfs: avoid filename buffer overrun The initramfs filename field is defined in Documentation/driver-api/early-userspace/buffer-format.rst as: 37 cpio_file := ALGN(4) + cpio_header + filename + \"\\0\" + ALGN(4) + data ... 55 ============= ================== ========================= 56 Field name Field size Meaning 57 ============= ================== ========================= ... 70 c_namesize 8 bytes Length of filename, including final \\0 When extracting an initramfs cpio archive, the kernel's do_name() path handler assumes a zero-terminated path at @collected, passing it directly to filp_open() / init_mkdir() / init_mknod(). If a specially crafted cpio entry carries a non-zero-terminated filename and is followed by uninitialized memory, then a file may be created with trailing characters that represent the uninitialized memory. The ability to create an initramfs entry would imply already having full control of the system, so the buffer overrun shouldn't be considered a security vulnerability. Append the output of the following bash script to an existing initramfs and observe any created /initramfs_test_fname_overrunAA* path. E.g. ./reproducer.sh | gzip >> /myinitramfs It's easiest to observe non-zero uninitialized memory when the output is gzipped, as it'll overflow the heap allocated @out_buf in __gunzip(), rather than the initrd_start+initrd_size block. ---- reproducer.sh ---- nilchar=\"A\"\t# change to \"\\0\" to properly zero terminate / pad magic=\"070701\" ino=1 mode=$(( 0100777 )) uid=0 gid=0 nlink=1 mtime=1 filesize=0 devmajor=0 devminor=1 rdevmajor=0 rdevminor=0 csum=0 fname=\"initramfs_test_fname_overrun\" namelen=$(( ${#fname} + 1 ))\t# plus one to account for terminator printf \"%s%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%s\" \\ \t$magic $ino $mode $uid $gid $nlink $mtime $filesize \\ \t$devmajor $devminor $rdevmajor $rdevminor $namelen $csum $fname termpadlen=$(( 1 + ((4 - ((110 + $namelen) & 3)) % 4) )) printf \"%.s${nilchar}\" $(seq 1 $termpadlen) ---- reproducer.sh ---- Symlink filename fields handled in do_symlink() won't overrun past the data segment, due to the explicit zero-termination of the symlink target. Fix filename buffer overrun by aborting the initramfs FSM if any cpio entry doesn't carry a zero-terminator at the expected (name_len - 1) offset.", "cve_priority": "medium", "cve_public_date": "2024-12-06 10:15:00 UTC" }, { "cve": "CVE-2024-53133", "url": "https://ubuntu.com/security/CVE-2024-53133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Handle dml allocation failure to avoid crash [Why] In the case where a dml allocation fails for any reason, the current state's dml contexts would no longer be valid. Then subsequent calls dc_state_copy_internal would shallow copy invalid memory and if the new state was released, a double free would occur. [How] Reset dml pointers in new_state to NULL and avoid invalid pointer (cherry picked from commit bcafdc61529a48f6f06355d78eb41b3aeda5296c)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53108", "url": "https://ubuntu.com/security/CVE-2024-53108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Adjust VSDB parser for replay feature At some point, the IEEE ID identification for the replay check in the AMD EDID was added. However, this check causes the following out-of-bounds issues when using KASAN: [ 27.804016] BUG: KASAN: slab-out-of-bounds in amdgpu_dm_update_freesync_caps+0xefa/0x17a0 [amdgpu] [ 27.804788] Read of size 1 at addr ffff8881647fdb00 by task systemd-udevd/383 ... [ 27.821207] Memory state around the buggy address: [ 27.821215] ffff8881647fda00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821224] ffff8881647fda80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821234] >ffff8881647fdb00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821243] ^ [ 27.821250] ffff8881647fdb80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821259] ffff8881647fdc00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821268] ================================================================== This is caused because the ID extraction happens outside of the range of the edid lenght. This commit addresses this issue by considering the amd_vsdb_block size. (cherry picked from commit b7e381b1ccd5e778e3d9c44c669ad38439a861d8)", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53134", "url": "https://ubuntu.com/security/CVE-2024-53134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pmdomain: imx93-blk-ctrl: correct remove path The check condition should be 'i < bc->onecell_data.num_domains', not 'bc->onecell_data.num_domains' which will make the look never finish and cause kernel panic. Also disable runtime to address \"imx93-blk-ctrl 4ac10000.system-controller: Unbalanced pm_runtime_enable!\"", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53132", "url": "https://ubuntu.com/security/CVE-2024-53132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/oa: Fix \"Missing outer runtime PM protection\" warning Fix the following drm_WARN: [953.586396] xe 0000:00:02.0: [drm] Missing outer runtime PM protection ... <4> [953.587090] ? xe_pm_runtime_get_noresume+0x8d/0xa0 [xe] <4> [953.587208] guc_exec_queue_add_msg+0x28/0x130 [xe] <4> [953.587319] guc_exec_queue_fini+0x3a/0x40 [xe] <4> [953.587425] xe_exec_queue_destroy+0xb3/0xf0 [xe] <4> [953.587515] xe_oa_release+0x9c/0xc0 [xe] (cherry picked from commit b107c63d2953907908fd0cafb0e543b3c3167b75)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53127", "url": "https://ubuntu.com/security/CVE-2024-53127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Revert \"mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K\" The commit 8396c793ffdf (\"mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K\") increased the max_req_size, even for 4K pages, causing various issues: - Panic booting the kernel/rootfs from an SD card on Rockchip RK3566 - Panic booting the kernel/rootfs from an SD card on StarFive JH7100 - \"swiotlb buffer is full\" and data corruption on StarFive JH7110 At this stage no fix have been found, so it's probably better to just revert the change. This reverts commit 8396c793ffdf28bb8aee7cfe0891080f8cab7890.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53130", "url": "https://ubuntu.com/security/CVE-2024-53130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint When using the \"block:block_dirty_buffer\" tracepoint, mark_buffer_dirty() may cause a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because, since the tracepoint was added in mark_buffer_dirty(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, nilfs_grab_buffer(), which grabs a buffer to read (or create) a block of metadata, including b-tree node blocks, does not set the block device, but instead does so only if the buffer is not in the \"uptodate\" state for each of its caller block reading functions. However, if the uptodate flag is set on a folio/page, and the buffer heads are detached from it by try_to_free_buffers(), and new buffer heads are then attached by create_empty_buffers(), the uptodate flag may be restored to each buffer without the block device being set to bh->b_bdev, and mark_buffer_dirty() may be called later in that state, resulting in the bug mentioned above. Fix this issue by making nilfs_grab_buffer() always set the block device of the super block structure to the buffer head, regardless of the state of the buffer's uptodate flag.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53105", "url": "https://ubuntu.com/security/CVE-2024-53105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: page_alloc: move mlocked flag clearance into free_pages_prepare() Syzbot reported a bad page state problem caused by a page being freed using free_page() still having a mlocked flag at free_pages_prepare() stage: BUG: Bad page state in process syz.5.504 pfn:61f45 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x61f45 flags: 0xfff00000080204(referenced|workingset|mlocked|node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000080204 0000000000000000 dead000000000122 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set page_owner tracks the page as allocated page last allocated via order 0, migratetype Unmovable, gfp_mask 0x400dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO), pid 8443, tgid 8442 (syz.5.504), ts 201884660643, free_ts 201499827394 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1537 prep_new_page mm/page_alloc.c:1545 [inline] get_page_from_freelist+0x303f/0x3190 mm/page_alloc.c:3457 __alloc_pages_noprof+0x292/0x710 mm/page_alloc.c:4733 alloc_pages_mpol_noprof+0x3e8/0x680 mm/mempolicy.c:2265 kvm_coalesced_mmio_init+0x1f/0xf0 virt/kvm/coalesced_mmio.c:99 kvm_create_vm virt/kvm/kvm_main.c:1235 [inline] kvm_dev_ioctl_create_vm virt/kvm/kvm_main.c:5488 [inline] kvm_dev_ioctl+0x12dc/0x2240 virt/kvm/kvm_main.c:5530 __do_compat_sys_ioctl fs/ioctl.c:1007 [inline] __se_compat_sys_ioctl+0x510/0xc90 fs/ioctl.c:950 do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline] __do_fast_syscall_32+0xb4/0x110 arch/x86/entry/common.c:386 do_fast_syscall_32+0x34/0x80 arch/x86/entry/common.c:411 entry_SYSENTER_compat_after_hwframe+0x84/0x8e page last free pid 8399 tgid 8399 stack trace: reset_page_owner include/linux/page_owner.h:25 [inline] free_pages_prepare mm/page_alloc.c:1108 [inline] free_unref_folios+0xf12/0x18d0 mm/page_alloc.c:2686 folios_put_refs+0x76c/0x860 mm/swap.c:1007 free_pages_and_swap_cache+0x5c8/0x690 mm/swap_state.c:335 __tlb_batch_free_encoded_pages mm/mmu_gather.c:136 [inline] tlb_batch_pages_flush mm/mmu_gather.c:149 [inline] tlb_flush_mmu_free mm/mmu_gather.c:366 [inline] tlb_flush_mmu+0x3a3/0x680 mm/mmu_gather.c:373 tlb_finish_mmu+0xd4/0x200 mm/mmu_gather.c:465 exit_mmap+0x496/0xc40 mm/mmap.c:1926 __mmput+0x115/0x390 kernel/fork.c:1348 exit_mm+0x220/0x310 kernel/exit.c:571 do_exit+0x9b2/0x28e0 kernel/exit.c:926 do_group_exit+0x207/0x2c0 kernel/exit.c:1088 __do_sys_exit_group kernel/exit.c:1099 [inline] __se_sys_exit_group kernel/exit.c:1097 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1097 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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 Modules linked in: CPU: 0 UID: 0 PID: 8442 Comm: syz.5.504 Not tainted 6.12.0-rc6-syzkaller #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 bad_page+0x176/0x1d0 mm/page_alloc.c:501 free_page_is_bad mm/page_alloc.c:918 [inline] free_pages_prepare mm/page_alloc.c:1100 [inline] free_unref_page+0xed0/0xf20 mm/page_alloc.c:2638 kvm_destroy_vm virt/kvm/kvm_main.c:1327 [inline] kvm_put_kvm+0xc75/0x1350 virt/kvm/kvm_main.c:1386 kvm_vcpu_release+0x54/0x60 virt/kvm/kvm_main.c:4143 __fput+0x23f/0x880 fs/file_table.c:431 task_work_run+0x24f/0x310 kernel/task_work.c:239 exit_task_work include/linux/task_work.h:43 [inline] do_exit+0xa2f/0x28e0 kernel/exit.c:939 do_group_exit+0x207/0x2c0 kernel/exit.c:1088 __do_sys_exit_group kernel/exit.c:1099 [in ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53109", "url": "https://ubuntu.com/security/CVE-2024-53109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nommu: pass NULL argument to vma_iter_prealloc() When deleting a vma entry from a maple tree, it has to pass NULL to vma_iter_prealloc() in order to calculate internal state of the tree, but it passed a wrong argument. As a result, nommu kernels crashed upon accessing a vma iterator, such as acct_collect() reading the size of vma entries after do_munmap(). This commit fixes this issue by passing a right argument to the preallocation call.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53131", "url": "https://ubuntu.com/security/CVE-2024-53131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint Patch series \"nilfs2: fix null-ptr-deref bugs on block tracepoints\". This series fixes null pointer dereference bugs that occur when using nilfs2 and two block-related tracepoints. This patch (of 2): It has been reported that when using \"block:block_touch_buffer\" tracepoint, touch_buffer() called from __nilfs_get_folio_block() causes a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because since the tracepoint was added in touch_buffer(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, the block_device structure is set after the function returns to the caller. Here, touch_buffer() is used to mark the folio/page that owns the buffer head as accessed, but the common search helper for folio/page used by the caller function was optimized to mark the folio/page as accessed when it was reimplemented a long time ago, eliminating the need to call touch_buffer() here in the first place. So this solves the issue by eliminating the touch_buffer() call itself.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53135", "url": "https://ubuntu.com/security/CVE-2024-53135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: VMX: Bury Intel PT virtualization (guest/host mode) behind CONFIG_BROKEN Hide KVM's pt_mode module param behind CONFIG_BROKEN, i.e. disable support for virtualizing Intel PT via guest/host mode unless BROKEN=y. There are myriad bugs in the implementation, some of which are fatal to the guest, and others which put the stability and health of the host at risk. For guest fatalities, the most glaring issue is that KVM fails to ensure tracing is disabled, and *stays* disabled prior to VM-Enter, which is necessary as hardware disallows loading (the guest's) RTIT_CTL if tracing is enabled (enforced via a VMX consistency check). Per the SDM: If the logical processor is operating with Intel PT enabled (if IA32_RTIT_CTL.TraceEn = 1) at the time of VM entry, the \"load IA32_RTIT_CTL\" VM-entry control must be 0. On the host side, KVM doesn't validate the guest CPUID configuration provided by userspace, and even worse, uses the guest configuration to decide what MSRs to save/load at VM-Enter and VM-Exit. E.g. configuring guest CPUID to enumerate more address ranges than are supported in hardware will result in KVM trying to passthrough, save, and load non-existent MSRs, which generates a variety of WARNs, ToPA ERRORs in the host, a potential deadlock, etc.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53106", "url": "https://ubuntu.com/security/CVE-2024-53106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: fix buffer overrun in ima_eventdigest_init_common Function ima_eventdigest_init() calls ima_eventdigest_init_common() with HASH_ALGO__LAST which is then used to access the array hash_digest_size[] leading to buffer overrun. Have a conditional statement to handle this.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53110", "url": "https://ubuntu.com/security/CVE-2024-53110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vp_vdpa: fix id_table array not null terminated error Allocate one extra virtio_device_id as null terminator, otherwise vdpa_mgmtdev_get_classes() may iterate multiple times and visit undefined memory.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53126", "url": "https://ubuntu.com/security/CVE-2024-53126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa: solidrun: Fix UB bug with devres In psnet_open_pf_bar() and snet_open_vf_bar() a string later passed to pcim_iomap_regions() is placed on the stack. Neither pcim_iomap_regions() nor the functions it calls copy that string. Should the string later ever be used, this, consequently, causes undefined behavior since the stack frame will by then have disappeared. Fix the bug by allocating the strings on the heap through devm_kasprintf().", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53111", "url": "https://ubuntu.com/security/CVE-2024-53111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mremap: fix address wraparound in move_page_tables() On 32-bit platforms, it is possible for the expression `len + old_addr < old_end` to be false-positive if `len + old_addr` wraps around. `old_addr` is the cursor in the old range up to which page table entries have been moved; so if the operation succeeded, `old_addr` is the *end* of the old region, and adding `len` to it can wrap. The overflow causes mremap() to mistakenly believe that PTEs have been copied; the consequence is that mremap() bails out, but doesn't move the PTEs back before the new VMA is unmapped, causing anonymous pages in the region to be lost. So basically if userspace tries to mremap() a private-anon region and hits this bug, mremap() will return an error and the private-anon region's contents appear to have been zeroed. The idea of this check is that `old_end - len` is the original start address, and writing the check that way also makes it easier to read; so fix the check by rearranging the comparison accordingly. (An alternate fix would be to refactor this function by introducing an \"orig_old_start\" variable or such.) Tested in a VM with a 32-bit X86 kernel; without the patch: ``` user@horn:~/big_mremap$ cat test.c #define _GNU_SOURCE #include #include #include #include #define ADDR1 ((void*)0x60000000) #define ADDR2 ((void*)0x10000000) #define SIZE 0x50000000uL int main(void) { unsigned char *p1 = mmap(ADDR1, SIZE, PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0); if (p1 == MAP_FAILED) err(1, \"mmap 1\"); unsigned char *p2 = mmap(ADDR2, SIZE, PROT_NONE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0); if (p2 == MAP_FAILED) err(1, \"mmap 2\"); *p1 = 0x41; printf(\"first char is 0x%02hhx\\n\", *p1); unsigned char *p3 = mremap(p1, SIZE, SIZE, MREMAP_MAYMOVE|MREMAP_FIXED, p2); if (p3 == MAP_FAILED) { printf(\"mremap() failed; first char is 0x%02hhx\\n\", *p1); } else { printf(\"mremap() succeeded; first char is 0x%02hhx\\n\", *p3); } } user@horn:~/big_mremap$ gcc -static -o test test.c user@horn:~/big_mremap$ setarch -R ./test first char is 0x41 mremap() failed; first char is 0x00 ``` With the patch: ``` user@horn:~/big_mremap$ setarch -R ./test first char is 0x41 mremap() succeeded; first char is 0x41 ```", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53107", "url": "https://ubuntu.com/security/CVE-2024-53107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: prevent integer overflow in pagemap_scan_get_args() The \"arg->vec_len\" variable is a u64 that comes from the user at the start of the function. The \"arg->vec_len * sizeof(struct page_region))\" multiplication can lead to integer wrapping. Use size_mul() to avoid that. Also the size_add/mul() functions work on unsigned long so for 32bit systems we need to ensure that \"arg->vec_len\" fits in an unsigned long.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53128", "url": "https://ubuntu.com/security/CVE-2024-53128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/task_stack: fix object_is_on_stack() for KASAN tagged pointers When CONFIG_KASAN_SW_TAGS and CONFIG_KASAN_STACK are enabled, the object_is_on_stack() function may produce incorrect results due to the presence of tags in the obj pointer, while the stack pointer does not have tags. This discrepancy can lead to incorrect stack object detection and subsequently trigger warnings if CONFIG_DEBUG_OBJECTS is also enabled. Example of the warning: ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at lib/debugobjects.c:557 __debug_object_init+0x330/0x364 Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5 #4 Hardware name: linux,dummy-virt (DT) pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __debug_object_init+0x330/0x364 lr : __debug_object_init+0x330/0x364 sp : ffff800082ea7b40 x29: ffff800082ea7b40 x28: 98ff0000c0164518 x27: 98ff0000c0164534 x26: ffff800082d93ec8 x25: 0000000000000001 x24: 1cff0000c00172a0 x23: 0000000000000000 x22: ffff800082d93ed0 x21: ffff800081a24418 x20: 3eff800082ea7bb0 x19: efff800000000000 x18: 0000000000000000 x17: 00000000000000ff x16: 0000000000000047 x15: 206b63617473206e x14: 0000000000000018 x13: ffff800082ea7780 x12: 0ffff800082ea78e x11: 0ffff800082ea790 x10: 0ffff800082ea79d x9 : 34d77febe173e800 x8 : 34d77febe173e800 x7 : 0000000000000001 x6 : 0000000000000001 x5 : feff800082ea74b8 x4 : ffff800082870a90 x3 : ffff80008018d3c4 x2 : 0000000000000001 x1 : ffff800082858810 x0 : 0000000000000050 Call trace: __debug_object_init+0x330/0x364 debug_object_init_on_stack+0x30/0x3c schedule_hrtimeout_range_clock+0xac/0x26c schedule_hrtimeout+0x1c/0x30 wait_task_inactive+0x1d4/0x25c kthread_bind_mask+0x28/0x98 init_rescuer+0x1e8/0x280 workqueue_init+0x1a0/0x3cc kernel_init_freeable+0x118/0x200 kernel_init+0x28/0x1f0 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53112", "url": "https://ubuntu.com/security/CVE-2024-53112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: uncache inode which has failed entering the group Syzbot has reported the following BUG: kernel BUG at fs/ocfs2/uptodate.c:509! ... Call Trace: ? __die_body+0x5f/0xb0 ? die+0x9e/0xc0 ? do_trap+0x15a/0x3a0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? do_error_trap+0x1dc/0x2c0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? __pfx_do_error_trap+0x10/0x10 ? handle_invalid_op+0x34/0x40 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? exc_invalid_op+0x38/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? ocfs2_set_new_buffer_uptodate+0x2e/0x160 ? ocfs2_set_new_buffer_uptodate+0x144/0x160 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ocfs2_group_add+0x39f/0x15a0 ? __pfx_ocfs2_group_add+0x10/0x10 ? __pfx_lock_acquire+0x10/0x10 ? mnt_get_write_access+0x68/0x2b0 ? __pfx_lock_release+0x10/0x10 ? rcu_read_lock_any_held+0xb7/0x160 ? __pfx_rcu_read_lock_any_held+0x10/0x10 ? smack_log+0x123/0x540 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x226/0x2b0 ocfs2_ioctl+0x65e/0x7d0 ? __pfx_ocfs2_ioctl+0x10/0x10 ? smack_file_ioctl+0x29e/0x3a0 ? __pfx_smack_file_ioctl+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x43d/0x780 ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10 ? __pfx_ocfs2_ioctl+0x10/0x10 __se_sys_ioctl+0xfb/0x170 do_syscall_64+0xf3/0x230 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... When 'ioctl(OCFS2_IOC_GROUP_ADD, ...)' has failed for the particular inode in 'ocfs2_verify_group_and_input()', corresponding buffer head remains cached and subsequent call to the same 'ioctl()' for the same inode issues the BUG() in 'ocfs2_set_new_buffer_uptodate()' (trying to cache the same buffer head of that inode). Fix this by uncaching the buffer head with 'ocfs2_remove_from_cache()' on error path in 'ocfs2_group_add()'.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53113", "url": "https://ubuntu.com/security/CVE-2024-53113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: fix NULL pointer dereference in alloc_pages_bulk_noprof We triggered a NULL pointer dereference for ac.preferred_zoneref->zone in alloc_pages_bulk_noprof() when the task is migrated between cpusets. When cpuset is enabled, in prepare_alloc_pages(), ac->nodemask may be ¤t->mems_allowed. when first_zones_zonelist() is called to find preferred_zoneref, the ac->nodemask may be modified concurrently if the task is migrated between different cpusets. Assuming we have 2 NUMA Node, when traversing Node1 in ac->zonelist, the nodemask is 2, and when traversing Node2 in ac->zonelist, the nodemask is 1. As a result, the ac->preferred_zoneref points to NULL zone. In alloc_pages_bulk_noprof(), for_each_zone_zonelist_nodemask() finds a allowable zone and calls zonelist_node_idx(ac.preferred_zoneref), leading to NULL pointer dereference. __alloc_pages_noprof() fixes this issue by checking NULL pointer in commit ea57485af8f4 (\"mm, page_alloc: fix check for NULL preferred_zone\") and commit df76cee6bbeb (\"mm, page_alloc: remove redundant checks from alloc fastpath\"). To fix it, check NULL pointer for preferred_zoneref->zone.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53114", "url": "https://ubuntu.com/security/CVE-2024-53114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 client A number of Zen4 client SoCs advertise the ability to use virtualized VMLOAD/VMSAVE, but using these instructions is reported to be a cause of a random host reboot. These instructions aren't intended to be advertised on Zen4 client so clear the capability.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53137", "url": "https://ubuntu.com/security/CVE-2024-53137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: fix cacheflush with PAN It seems that the cacheflush syscall got broken when PAN for LPAE was implemented. User access was not enabled around the cache maintenance instructions, causing them to fault.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53115", "url": "https://ubuntu.com/security/CVE-2024-53115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: avoid null_ptr_deref in vmw_framebuffer_surface_create_handle The 'vmw_user_object_buffer' function may return NULL with incorrect inputs. To avoid possible null pointer dereference, add a check whether the 'bo' is NULL in the vmw_framebuffer_surface_create_handle.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53116", "url": "https://ubuntu.com/security/CVE-2024-53116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix handling of partial GPU mapping of BOs This commit fixes the bug in the handling of partial mapping of the buffer objects to the GPU, which caused kernel warnings. Panthor didn't correctly handle the case where the partial mapping spanned multiple scatterlists and the mapping offset didn't point to the 1st page of starting scatterlist. The offset variable was not cleared after reaching the starting scatterlist. Following warning messages were seen. WARNING: CPU: 1 PID: 650 at drivers/iommu/io-pgtable-arm.c:659 __arm_lpae_unmap+0x254/0x5a0 pc : __arm_lpae_unmap+0x254/0x5a0 lr : __arm_lpae_unmap+0x2cc/0x5a0 Call trace: __arm_lpae_unmap+0x254/0x5a0 __arm_lpae_unmap+0x108/0x5a0 __arm_lpae_unmap+0x108/0x5a0 __arm_lpae_unmap+0x108/0x5a0 arm_lpae_unmap_pages+0x80/0xa0 panthor_vm_unmap_pages+0xac/0x1c8 [panthor] panthor_gpuva_sm_step_unmap+0x4c/0xc8 [panthor] op_unmap_cb.isra.23.constprop.30+0x54/0x80 __drm_gpuvm_sm_unmap+0x184/0x1c8 drm_gpuvm_sm_unmap+0x40/0x60 panthor_vm_exec_op+0xa8/0x120 [panthor] panthor_vm_bind_exec_sync_op+0xc4/0xe8 [panthor] panthor_ioctl_vm_bind+0x10c/0x170 [panthor] drm_ioctl_kernel+0xbc/0x138 drm_ioctl+0x210/0x4b0 __arm64_sys_ioctl+0xb0/0xf8 invoke_syscall+0x4c/0x110 el0_svc_common.constprop.1+0x98/0xf8 do_el0_svc+0x24/0x38 el0_svc+0x34/0xc8 el0t_64_sync_handler+0xa0/0xc8 el0t_64_sync+0x174/0x178 panthor : [drm] drm_WARN_ON(unmapped_sz != pgsize * pgcount) WARNING: CPU: 1 PID: 650 at drivers/gpu/drm/panthor/panthor_mmu.c:922 panthor_vm_unmap_pages+0x124/0x1c8 [panthor] pc : panthor_vm_unmap_pages+0x124/0x1c8 [panthor] lr : panthor_vm_unmap_pages+0x124/0x1c8 [panthor] panthor : [drm] *ERROR* failed to unmap range ffffa388f000-ffffa3890000 (requested range ffffa388c000-ffffa3890000)", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53117", "url": "https://ubuntu.com/security/CVE-2024-53117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio/vsock: Improve MSG_ZEROCOPY error handling Add a missing kfree_skb() to prevent memory leaks.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53118", "url": "https://ubuntu.com/security/CVE-2024-53118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Fix sk_error_queue memory leak Kernel queues MSG_ZEROCOPY completion notifications on the error queue. Where they remain, until explicitly recv()ed. To prevent memory leaks, clean up the queue when the socket is destroyed. unreferenced object 0xffff8881028beb00 (size 224): comm \"vsock_test\", pid 1218, jiffies 4294694897 hex dump (first 32 bytes): 90 b0 21 17 81 88 ff ff 90 b0 21 17 81 88 ff ff ..!.......!..... 00 00 00 00 00 00 00 00 00 b0 21 17 81 88 ff ff ..........!..... backtrace (crc 6c7031ca): [] kmem_cache_alloc_node_noprof+0x2f7/0x370 [] __alloc_skb+0x132/0x180 [] sock_omalloc+0x4b/0x80 [] msg_zerocopy_realloc+0x9e/0x240 [] virtio_transport_send_pkt_info+0x412/0x4c0 [] virtio_transport_stream_enqueue+0x43/0x50 [] vsock_connectible_sendmsg+0x373/0x450 [] ____sys_sendmsg+0x365/0x3a0 [] ___sys_sendmsg+0x84/0xd0 [] __sys_sendmsg+0x47/0x80 [] do_syscall_64+0x93/0x180 [] entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53119", "url": "https://ubuntu.com/security/CVE-2024-53119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio/vsock: Fix accept_queue memory leak As the final stages of socket destruction may be delayed, it is possible that virtio_transport_recv_listen() will be called after the accept_queue has been flushed, but before the SOCK_DONE flag has been set. As a result, sockets enqueued after the flush would remain unremoved, leading to a memory leak. vsock_release __vsock_release lock virtio_transport_release virtio_transport_close schedule_delayed_work(close_work) sk_shutdown = SHUTDOWN_MASK (!) flush accept_queue release virtio_transport_recv_pkt vsock_find_bound_socket lock if flag(SOCK_DONE) return virtio_transport_recv_listen child = vsock_create_connected (!) vsock_enqueue_accept(child) release close_work lock virtio_transport_do_close set_flag(SOCK_DONE) virtio_transport_remove_sock vsock_remove_sock vsock_remove_bound release Introduce a sk_shutdown check to disallow vsock_enqueue_accept() during socket destruction. unreferenced object 0xffff888109e3f800 (size 2040): comm \"kworker/5:2\", pid 371, jiffies 4294940105 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00 (..@............ backtrace (crc 9e5f4e84): [] kmem_cache_alloc_noprof+0x2c1/0x360 [] sk_prot_alloc+0x30/0x120 [] sk_alloc+0x2c/0x4b0 [] __vsock_create.constprop.0+0x2a/0x310 [] virtio_transport_recv_pkt+0x4dc/0x9a0 [] vsock_loopback_work+0xfd/0x140 [] process_one_work+0x20c/0x570 [] worker_thread+0x1bf/0x3a0 [] kthread+0xdd/0x110 [] ret_from_fork+0x2d/0x50 [] ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53120", "url": "https://ubuntu.com/security/CVE-2024-53120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: CT: Fix null-ptr-deref in add rule err flow In error flow of mlx5_tc_ct_entry_add_rule(), in case ct_rule_add() callback returns error, zone_rule->attr is used uninitiated. Fix it to use attr which has the needed pointer value. Kernel log: BUG: kernel NULL pointer dereference, address: 0000000000000110 RIP: 0010:mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core] … Call Trace: ? __die+0x20/0x70 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x140 ? asm_exc_page_fault+0x22/0x30 ? mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core] ? mlx5_tc_ct_entry_add_rule+0x1d5/0x2f0 [mlx5_core] mlx5_tc_ct_block_flow_offload+0xc6a/0xf90 [mlx5_core] ? nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] flow_offload_work_handler+0x142/0x320 [nf_flow_table] ? finish_task_switch.isra.0+0x15b/0x2b0 process_one_work+0x16c/0x320 worker_thread+0x28c/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xb8/0xf0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53138", "url": "https://ubuntu.com/security/CVE-2024-53138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: kTLS, Fix incorrect page refcounting The kTLS tx handling code is using a mix of get_page() and page_ref_inc() APIs to increment the page reference. But on the release path (mlx5e_ktls_tx_handle_resync_dump_comp()), only put_page() is used. This is an issue when using pages from large folios: the get_page() references are stored on the folio page while the page_ref_inc() references are stored directly in the given page. On release the folio page will be dereferenced too many times. This was found while doing kTLS testing with sendfile() + ZC when the served file was read from NFS on a kernel with NFS large folios support (commit 49b29a573da8 (\"nfs: add support for large folios\")).", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53121", "url": "https://ubuntu.com/security/CVE-2024-53121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: fs, lock FTE when checking if active The referenced commits introduced a two-step process for deleting FTEs: - Lock the FTE, delete it from hardware, set the hardware deletion function to NULL and unlock the FTE. - Lock the parent flow group, delete the software copy of the FTE, and remove it from the xarray. However, this approach encounters a race condition if a rule with the same match value is added simultaneously. In this scenario, fs_core may set the hardware deletion function to NULL prematurely, causing a panic during subsequent rule deletions. To prevent this, ensure the active flag of the FTE is checked under a lock, which will prevent the fs_core layer from attaching a new steering rule to an FTE that is in the process of deletion. [ 438.967589] MOSHE: 2496 mlx5_del_flow_rules del_hw_func [ 438.968205] ------------[ cut here ]------------ [ 438.968654] refcount_t: decrement hit 0; leaking memory. [ 438.969249] WARNING: CPU: 0 PID: 8957 at lib/refcount.c:31 refcount_warn_saturate+0xfb/0x110 [ 438.970054] Modules linked in: act_mirred cls_flower act_gact sch_ingress openvswitch nsh mlx5_vdpa vringh vhost_iotlb vdpa mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core zram zsmalloc fuse [last unloaded: cls_flower] [ 438.973288] CPU: 0 UID: 0 PID: 8957 Comm: tc Not tainted 6.12.0-rc1+ #8 [ 438.973888] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 438.974874] RIP: 0010:refcount_warn_saturate+0xfb/0x110 [ 438.975363] Code: 40 66 3b 82 c6 05 16 e9 4d 01 01 e8 1f 7c a0 ff 0f 0b c3 cc cc cc cc 48 c7 c7 10 66 3b 82 c6 05 fd e8 4d 01 01 e8 05 7c a0 ff <0f> 0b c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 90 [ 438.976947] RSP: 0018:ffff888124a53610 EFLAGS: 00010286 [ 438.977446] RAX: 0000000000000000 RBX: ffff888119d56de0 RCX: 0000000000000000 [ 438.978090] RDX: ffff88852c828700 RSI: ffff88852c81b3c0 RDI: ffff88852c81b3c0 [ 438.978721] RBP: ffff888120fa0e88 R08: 0000000000000000 R09: ffff888124a534b0 [ 438.979353] R10: 0000000000000001 R11: 0000000000000001 R12: ffff888119d56de0 [ 438.979979] R13: ffff888120fa0ec0 R14: ffff888120fa0ee8 R15: ffff888119d56de0 [ 438.980607] FS: 00007fe6dcc0f800(0000) GS:ffff88852c800000(0000) knlGS:0000000000000000 [ 438.983984] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 438.984544] CR2: 00000000004275e0 CR3: 0000000186982001 CR4: 0000000000372eb0 [ 438.985205] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 438.985842] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 438.986507] Call Trace: [ 438.986799] [ 438.987070] ? __warn+0x7d/0x110 [ 438.987426] ? refcount_warn_saturate+0xfb/0x110 [ 438.987877] ? report_bug+0x17d/0x190 [ 438.988261] ? prb_read_valid+0x17/0x20 [ 438.988659] ? handle_bug+0x53/0x90 [ 438.989054] ? exc_invalid_op+0x14/0x70 [ 438.989458] ? asm_exc_invalid_op+0x16/0x20 [ 438.989883] ? refcount_warn_saturate+0xfb/0x110 [ 438.990348] mlx5_del_flow_rules+0x2f7/0x340 [mlx5_core] [ 438.990932] __mlx5_eswitch_del_rule+0x49/0x170 [mlx5_core] [ 438.991519] ? mlx5_lag_is_sriov+0x3c/0x50 [mlx5_core] [ 438.992054] ? xas_load+0x9/0xb0 [ 438.992407] mlx5e_tc_rule_unoffload+0x45/0xe0 [mlx5_core] [ 438.993037] mlx5e_tc_del_fdb_flow+0x2a6/0x2e0 [mlx5_core] [ 438.993623] mlx5e_flow_put+0x29/0x60 [mlx5_core] [ 438.994161] mlx5e_delete_flower+0x261/0x390 [mlx5_core] [ 438.994728] tc_setup_cb_destroy+0xb9/0x190 [ 438.995150] fl_hw_destroy_filter+0x94/0xc0 [cls_flower] [ 438.995650] fl_change+0x11a4/0x13c0 [cls_flower] [ 438.996105] tc_new_tfilter+0x347/0xbc0 [ 438.996503] ? __ ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53122", "url": "https://ubuntu.com/security/CVE-2024-53122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: cope racing subflow creation in mptcp_rcv_space_adjust Additional active subflows - i.e. created by the in kernel path manager - are included into the subflow list before starting the 3whs. A racing recvmsg() spooling data received on an already established subflow would unconditionally call tcp_cleanup_rbuf() on all the current subflows, potentially hitting a divide by zero error on the newly created ones. Explicitly check that the subflow is in a suitable state before invoking tcp_cleanup_rbuf().", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53123", "url": "https://ubuntu.com/security/CVE-2024-53123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: error out earlier on disconnect Eric reported a division by zero splat in the MPTCP protocol: Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 6094 Comm: syz-executor317 Not tainted 6.12.0-rc5-syzkaller-00291-g05b92660cdfe #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:__tcp_select_window+0x5b4/0x1310 net/ipv4/tcp_output.c:3163 Code: f6 44 01 e3 89 df e8 9b 75 09 f8 44 39 f3 0f 8d 11 ff ff ff e8 0d 74 09 f8 45 89 f4 e9 04 ff ff ff e8 00 74 09 f8 44 89 f0 99 7c 24 14 41 29 d6 45 89 f4 e9 ec fe ff ff e8 e8 73 09 f8 48 89 RSP: 0018:ffffc900041f7930 EFLAGS: 00010293 RAX: 0000000000017e67 RBX: 0000000000017e67 RCX: ffffffff8983314b RDX: 0000000000000000 RSI: ffffffff898331b0 RDI: 0000000000000004 RBP: 00000000005d6000 R08: 0000000000000004 R09: 0000000000017e67 R10: 0000000000003e80 R11: 0000000000000000 R12: 0000000000003e80 R13: ffff888031d9b440 R14: 0000000000017e67 R15: 00000000002eb000 FS: 00007feb5d7f16c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007feb5d8adbb8 CR3: 0000000074e4c000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __tcp_cleanup_rbuf+0x3e7/0x4b0 net/ipv4/tcp.c:1493 mptcp_rcv_space_adjust net/mptcp/protocol.c:2085 [inline] mptcp_recvmsg+0x2156/0x2600 net/mptcp/protocol.c:2289 inet_recvmsg+0x469/0x6a0 net/ipv4/af_inet.c:885 sock_recvmsg_nosec net/socket.c:1051 [inline] sock_recvmsg+0x1b2/0x250 net/socket.c:1073 __sys_recvfrom+0x1a5/0x2e0 net/socket.c:2265 __do_sys_recvfrom net/socket.c:2283 [inline] __se_sys_recvfrom net/socket.c:2279 [inline] __x64_sys_recvfrom+0xe0/0x1c0 net/socket.c:2279 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 RIP: 0033:0x7feb5d857559 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:00007feb5d7f1208 EFLAGS: 00000246 ORIG_RAX: 000000000000002d RAX: ffffffffffffffda RBX: 00007feb5d8e1318 RCX: 00007feb5d857559 RDX: 000000800000000e RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007feb5d8e1310 R08: 0000000000000000 R09: ffffffff81000000 R10: 0000000000000100 R11: 0000000000000246 R12: 00007feb5d8e131c R13: 00007feb5d8ae074 R14: 000000800000000e R15: 00000000fffffdef and provided a nice reproducer. The root cause is the current bad handling of racing disconnect. After the blamed commit below, sk_wait_data() can return (with error) with the underlying socket disconnected and a zero rcv_mss. Catch the error and return without performing any additional operations on the current socket.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53124", "url": "https://ubuntu.com/security/CVE-2024-53124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix data-races around sk->sk_forward_alloc Syzkaller reported this warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 16 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x1c5/0x1e0 Modules linked in: CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:inet_sock_destruct+0x1c5/0x1e0 Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 <0f> 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00 RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206 RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007 RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00 RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007 R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00 R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78 FS: 0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn+0x88/0x130 ? inet_sock_destruct+0x1c5/0x1e0 ? report_bug+0x18e/0x1a0 ? handle_bug+0x53/0x90 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? inet_sock_destruct+0x1c5/0x1e0 __sk_destruct+0x2a/0x200 rcu_do_batch+0x1aa/0x530 ? rcu_do_batch+0x13b/0x530 rcu_core+0x159/0x2f0 handle_softirqs+0xd3/0x2b0 ? __pfx_smpboot_thread_fn+0x10/0x10 run_ksoftirqd+0x25/0x30 smpboot_thread_fn+0xdd/0x1d0 kthread+0xd3/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ---[ end trace 0000000000000000 ]--- Its possible that two threads call tcp_v6_do_rcv()/sk_forward_alloc_add() concurrently when sk->sk_state == TCP_LISTEN with sk->sk_lock unlocked, which triggers a data-race around sk->sk_forward_alloc: tcp_v6_rcv tcp_v6_do_rcv skb_clone_and_charge_r sk_rmem_schedule __sk_mem_schedule sk_forward_alloc_add() skb_set_owner_r sk_mem_charge sk_forward_alloc_add() __kfree_skb skb_release_all skb_release_head_state sock_rfree sk_mem_uncharge sk_forward_alloc_add() sk_mem_reclaim // set local var reclaimable __sk_mem_reclaim sk_forward_alloc_add() In this syzkaller testcase, two threads call tcp_v6_do_rcv() with skb->truesize=768, the sk_forward_alloc changes like this: (cpu 1) | (cpu 2) | sk_forward_alloc ... | ... | 0 __sk_mem_schedule() | | +4096 = 4096 | __sk_mem_schedule() | +4096 = 8192 sk_mem_charge() | | -768 = 7424 | sk_mem_charge() | -768 = 6656 ... | ... | sk_mem_uncharge() | | +768 = 7424 reclaimable=7424 | | | sk_mem_uncharge() | +768 = 8192 | reclaimable=8192 | __sk_mem_reclaim() | | -4096 = 4096 | __sk_mem_reclaim() | -8192 = -4096 != 0 The skb_clone_and_charge_r() should not be called in tcp_v6_do_rcv() when sk->sk_state is TCP_LISTEN, it happens later in tcp_v6_syn_recv_sock(). Fix the same issue in dccp_v6_do_rcv().", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53129", "url": "https://ubuntu.com/security/CVE-2024-53129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: vop: Fix a dereferenced before check warning The 'state' can't be NULL, we should check crtc_state. Fix warning: drivers/gpu/drm/rockchip/rockchip_drm_vop.c:1096 vop_plane_atomic_async_check() warn: variable dereferenced before check 'state' (see line 1077)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53139", "url": "https://ubuntu.com/security/CVE-2024-53139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix possible UAF in sctp_v6_available() A lockdep report [1] with CONFIG_PROVE_RCU_LIST=y hints that sctp_v6_available() is calling dev_get_by_index_rcu() and ipv6_chk_addr() without holding rcu. [1] ============================= WARNING: suspicious RCU usage 6.12.0-rc5-virtme #1216 Tainted: G W ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by sctp_hello/31495: #0: ffff9f1ebbdb7418 (sk_lock-AF_INET6){+.+.}-{0:0}, at: sctp_bind (./arch/x86/include/asm/jump_label.h:27 net/sctp/socket.c:315) sctp stack backtrace: CPU: 7 UID: 0 PID: 31495 Comm: sctp_hello Tainted: G W 6.12.0-rc5-virtme #1216 Tainted: [W]=WARN 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:123) lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822) dev_get_by_index_rcu (net/core/dev.c:876 (discriminator 7)) sctp_v6_available (net/sctp/ipv6.c:701) sctp sctp_do_bind (net/sctp/socket.c:400 (discriminator 1)) sctp sctp_bind (net/sctp/socket.c:320) sctp inet6_bind_sk (net/ipv6/af_inet6.c:465) ? security_socket_bind (security/security.c:4581 (discriminator 1)) __sys_bind (net/socket.c:1848 net/socket.c:1869) ? do_user_addr_fault (./include/linux/rcupdate.h:347 ./include/linux/rcupdate.h:880 ./include/linux/mm.h:729 arch/x86/mm/fault.c:1340) ? do_user_addr_fault (./arch/x86/include/asm/preempt.h:84 (discriminator 13) ./include/linux/rcupdate.h:98 (discriminator 13) ./include/linux/rcupdate.h:882 (discriminator 13) ./include/linux/mm.h:729 (discriminator 13) arch/x86/mm/fault.c:1340 (discriminator 13)) __x64_sys_bind (net/socket.c:1877 (discriminator 1) net/socket.c:1875 (discriminator 1) net/socket.c:1875 (discriminator 1)) do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f59b934a1e7 Code: 44 00 00 48 8b 15 39 8c 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 b8 31 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 09 8c 0c 00 f7 d8 64 89 01 48 All code ======== 0:\t44 00 00 \tadd %r8b,(%rax) 3:\t48 8b 15 39 8c 0c 00 \tmov 0xc8c39(%rip),%rdx # 0xc8c43 a:\tf7 d8 \tneg %eax c:\t64 89 02 \tmov %eax,%fs:(%rdx) f:\tb8 ff ff ff ff \tmov $0xffffffff,%eax 14:\teb bd \tjmp 0xffffffffffffffd3 16:\t66 2e 0f 1f 84 00 00 \tcs nopw 0x0(%rax,%rax,1) 1d:\t00 00 00 20:\t0f 1f 00 \tnopl (%rax) 23:\tb8 31 00 00 00 \tmov $0x31,%eax 28:\t0f 05 \tsyscall 2a:*\t48 3d 01 f0 ff ff \tcmp $0xfffffffffffff001,%rax\t\t<-- trapping instruction 30:\t73 01 \tjae 0x33 32:\tc3 \tret 33:\t48 8b 0d 09 8c 0c 00 \tmov 0xc8c09(%rip),%rcx # 0xc8c43 3a:\tf7 d8 \tneg %eax 3c:\t64 89 01 \tmov %eax,%fs:(%rcx) 3f:\t48 \trex.W Code starting with the faulting instruction =========================================== 0:\t48 3d 01 f0 ff ff \tcmp $0xfffffffffffff001,%rax 6:\t73 01 \tjae 0x9 8:\tc3 \tret 9:\t48 8b 0d 09 8c 0c 00 \tmov 0xc8c09(%rip),%rcx # 0xc8c19 10:\tf7 d8 \tneg %eax 12:\t64 89 01 \tmov %eax,%fs:(%rcx) 15:\t48 \trex.W RSP: 002b:00007ffe2d0ad398 EFLAGS: 00000202 ORIG_RAX: 0000000000000031 RAX: ffffffffffffffda RBX: 00007ffe2d0ad3d0 RCX: 00007f59b934a1e7 RDX: 000000000000001c RSI: 00007ffe2d0ad3d0 RDI: 0000000000000005 RBP: 0000000000000005 R08: 1999999999999999 R09: 0000000000000000 R10: 00007f59b9253298 R11: 000000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53140", "url": "https://ubuntu.com/security/CVE-2024-53140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netlink: terminate outstanding dump on socket close Netlink supports iterative dumping of data. It provides the families the following ops: - start - (optional) kicks off the dumping process - dump - actual dump helper, keeps getting called until it returns 0 - done - (optional) pairs with .start, can be used for cleanup The whole process is asynchronous and the repeated calls to .dump don't actually happen in a tight loop, but rather are triggered in response to recvmsg() on the socket. This gives the user full control over the dump, but also means that the user can close the socket without getting to the end of the dump. To make sure .start is always paired with .done we check if there is an ongoing dump before freeing the socket, and if so call .done. The complication is that sockets can get freed from BH and .done is allowed to sleep. So we use a workqueue to defer the call, when needed. Unfortunately this does not work correctly. What we defer is not the cleanup but rather releasing a reference on the socket. We have no guarantee that we own the last reference, if someone else holds the socket they may release it in BH and we're back to square one. The whole dance, however, appears to be unnecessary. Only the user can interact with dumps, so we can clean up when socket is closed. And close always happens in process context. Some async code may still access the socket after close, queue notification skbs to it etc. but no dumps can start, end or otherwise make progress. Delete the workqueue and flush the dump state directly from the release handler. Note that further cleanup is possible in -next, for instance we now always call .done before releasing the main module reference, so dump doesn't have to take a reference of its own.", "cve_priority": "high", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53098", "url": "https://ubuntu.com/security/CVE-2024-53098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/ufence: Prefetch ufence addr to catch bogus address access_ok() only checks for addr overflow so also try to read the addr to catch invalid addr sent from userspace. (cherry picked from commit 9408c4508483ffc60811e910a93d6425b8e63928)", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53099", "url": "https://ubuntu.com/security/CVE-2024-53099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check validity of link->type in bpf_link_show_fdinfo() If a newly-added link type doesn't invoke BPF_LINK_TYPE(), accessing bpf_link_type_strs[link->type] may result in an out-of-bounds access. To spot such missed invocations early in the future, checking the validity of link->type in bpf_link_show_fdinfo() and emitting a warning when such invocations are missed.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53089", "url": "https://ubuntu.com/security/CVE-2024-53089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: KVM: Mark hrtimer to expire in hard interrupt context Like commit 2c0d278f3293f (\"KVM: LAPIC: Mark hrtimer to expire in hard interrupt context\") and commit 9090825fa9974 (\"KVM: arm/arm64: Let the timer expire in hardirq context on RT\"), On PREEMPT_RT enabled kernels unmarked hrtimers are moved into soft interrupt expiry mode by default. Then the timers are canceled from an preempt-notifier which is invoked with disabled preemption which is not allowed on PREEMPT_RT. The timer callback is short so in could be invoked in hard-IRQ context. So let the timer expire on hard-IRQ context even on -RT. This fix a \"scheduling while atomic\" bug for PREEMPT_RT enabled kernels: BUG: scheduling while atomic: qemu-system-loo/1011/0x00000002 Modules linked in: amdgpu rfkill nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat ns CPU: 1 UID: 0 PID: 1011 Comm: qemu-system-loo Tainted: G W 6.12.0-rc2+ #1774 Tainted: [W]=WARN Hardware name: Loongson Loongson-3A5000-7A1000-1w-CRB/Loongson-LS3A5000-7A1000-1w-CRB, BIOS vUDK2018-LoongArch-V2.0.0-prebeta9 10/21/2022 Stack : ffffffffffffffff 0000000000000000 9000000004e3ea38 9000000116744000 90000001167475a0 0000000000000000 90000001167475a8 9000000005644830 90000000058dc000 90000000058dbff8 9000000116747420 0000000000000001 0000000000000001 6a613fc938313980 000000000790c000 90000001001c1140 00000000000003fe 0000000000000001 000000000000000d 0000000000000003 0000000000000030 00000000000003f3 000000000790c000 9000000116747830 90000000057ef000 0000000000000000 9000000005644830 0000000000000004 0000000000000000 90000000057f4b58 0000000000000001 9000000116747868 900000000451b600 9000000005644830 9000000003a13998 0000000010000020 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d ... Call Trace: [<9000000003a13998>] show_stack+0x38/0x180 [<9000000004e3ea34>] dump_stack_lvl+0x84/0xc0 [<9000000003a71708>] __schedule_bug+0x48/0x60 [<9000000004e45734>] __schedule+0x1114/0x1660 [<9000000004e46040>] schedule_rtlock+0x20/0x60 [<9000000004e4e330>] rtlock_slowlock_locked+0x3f0/0x10a0 [<9000000004e4f038>] rt_spin_lock+0x58/0x80 [<9000000003b02d68>] hrtimer_cancel_wait_running+0x68/0xc0 [<9000000003b02e30>] hrtimer_cancel+0x70/0x80 [] kvm_restore_timer+0x50/0x1a0 [kvm] [] kvm_arch_vcpu_load+0x68/0x2a0 [kvm] [] kvm_sched_in+0x34/0x60 [kvm] [<9000000003a749a0>] finish_task_switch.isra.0+0x140/0x2e0 [<9000000004e44a70>] __schedule+0x450/0x1660 [<9000000004e45cb0>] schedule+0x30/0x180 [] kvm_vcpu_block+0x70/0x120 [kvm] [] kvm_vcpu_halt+0x60/0x3e0 [kvm] [] kvm_handle_gspr+0x3f4/0x4e0 [kvm] [] kvm_handle_exit+0x1c8/0x260 [kvm]", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53090", "url": "https://ubuntu.com/security/CVE-2024-53090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix lock recursion afs_wake_up_async_call() can incur lock recursion. The problem is that it is called from AF_RXRPC whilst holding the ->notify_lock, but it tries to take a ref on the afs_call struct in order to pass it to a work queue - but if the afs_call is already queued, we then have an extraneous ref that must be put... calling afs_put_call() may call back down into AF_RXRPC through rxrpc_kernel_shutdown_call(), however, which might try taking the ->notify_lock again. This case isn't very common, however, so defer it to a workqueue. The oops looks something like: BUG: spinlock recursion on CPU#0, krxrpcio/7001/1646 lock: 0xffff888141399b30, .magic: dead4ead, .owner: krxrpcio/7001/1646, .owner_cpu: 0 CPU: 0 UID: 0 PID: 1646 Comm: krxrpcio/7001 Not tainted 6.12.0-rc2-build3+ #4351 Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014 Call Trace: dump_stack_lvl+0x47/0x70 do_raw_spin_lock+0x3c/0x90 rxrpc_kernel_shutdown_call+0x83/0xb0 afs_put_call+0xd7/0x180 rxrpc_notify_socket+0xa0/0x190 rxrpc_input_split_jumbo+0x198/0x1d0 rxrpc_input_data+0x14b/0x1e0 ? rxrpc_input_call_packet+0xc2/0x1f0 rxrpc_input_call_event+0xad/0x6b0 rxrpc_input_packet_on_conn+0x1e1/0x210 rxrpc_input_packet+0x3f2/0x4d0 rxrpc_io_thread+0x243/0x410 ? __pfx_rxrpc_io_thread+0x10/0x10 kthread+0xcf/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x24/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53101", "url": "https://ubuntu.com/security/CVE-2024-53101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized value issue in from_kuid and from_kgid ocfs2_setattr() uses attr->ia_mode, attr->ia_uid and attr->ia_gid in a trace point even though ATTR_MODE, ATTR_UID and ATTR_GID aren't set. Initialize all fields of newattrs to avoid uninitialized variables, by checking if ATTR_MODE, ATTR_UID, ATTR_GID are initialized, otherwise 0.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53091", "url": "https://ubuntu.com/security/CVE-2024-53091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Add sk_is_inet and IS_ICSK check in tls_sw_has_ctx_tx/rx As the introduction of the support for vsock and unix sockets in sockmap, tls_sw_has_ctx_tx/rx cannot presume the socket passed in must be IS_ICSK. vsock and af_unix sockets have vsock_sock and unix_sock instead of inet_connection_sock. For these sockets, tls_get_ctx may return an invalid pointer and cause page fault in function tls_sw_ctx_rx. BUG: unable to handle page fault for address: 0000000000040030 Workqueue: vsock-loopback vsock_loopback_work RIP: 0010:sk_psock_strp_data_ready+0x23/0x60 Call Trace: ? __die+0x81/0xc3 ? no_context+0x194/0x350 ? do_page_fault+0x30/0x110 ? async_page_fault+0x3e/0x50 ? sk_psock_strp_data_ready+0x23/0x60 virtio_transport_recv_pkt+0x750/0x800 ? update_load_avg+0x7e/0x620 vsock_loopback_work+0xd0/0x100 process_one_work+0x1a7/0x360 worker_thread+0x30/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x112/0x130 ? __kthread_cancel_work+0x40/0x40 ret_from_fork+0x1f/0x40 v2: - Add IS_ICSK check v3: - Update the commits in Fixes", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53092", "url": "https://ubuntu.com/security/CVE-2024-53092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_pci: Fix admin vq cleanup by using correct info pointer vp_modern_avq_cleanup() and vp_del_vqs() clean up admin vq resources by virtio_pci_vq_info pointer. The info pointer of admin vq is stored in vp_dev->admin_vq.info instead of vp_dev->vqs[]. Using the info pointer from vp_dev->vqs[] for admin vq causes a kernel NULL pointer dereference bug. In vp_modern_avq_cleanup() and vp_del_vqs(), get the info pointer from vp_dev->admin_vq.info for admin vq to clean up the resources. Also make info ptr as argument of vp_del_vq() to be symmetric with vp_setup_vq(). vp_reset calls vp_modern_avq_cleanup, and causes the Call Trace: ================================================================== BUG: kernel NULL pointer dereference, address:0000000000000000 ... CPU: 49 UID: 0 PID: 4439 Comm: modprobe Not tainted 6.11.0-rc5 #1 RIP: 0010:vp_reset+0x57/0x90 [virtio_pci] Call Trace: ... ? vp_reset+0x57/0x90 [virtio_pci] ? vp_reset+0x38/0x90 [virtio_pci] virtio_reset_device+0x1d/0x30 remove_vq_common+0x1c/0x1a0 [virtio_net] virtnet_remove+0xa1/0xc0 [virtio_net] virtio_dev_remove+0x46/0xa0 ... virtio_pci_driver_exit+0x14/0x810 [virtio_pci] ==================================================================", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53102", "url": "https://ubuntu.com/security/CVE-2024-53102", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53093", "url": "https://ubuntu.com/security/CVE-2024-53093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: defer partition scanning We need to suppress the partition scan from occuring within the controller's scan_work context. If a path error occurs here, the IO will wait until a path becomes available or all paths are torn down, but that action also occurs within scan_work, so it would deadlock. Defer the partion scan to a different context that does not block scan_work.", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53094", "url": "https://ubuntu.com/security/CVE-2024-53094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Add sendpage_ok() check to disable MSG_SPLICE_PAGES While running ISER over SIW, the initiator machine encounters a warning from skb_splice_from_iter() indicating that a slab page is being used in send_page. To address this, it is better to add a sendpage_ok() check within the driver itself, and if it returns 0, then MSG_SPLICE_PAGES flag should be disabled before entering the network stack. A similar issue has been discussed for NVMe in this thread: https://lore.kernel.org/all/20240530142417.146696-1-ofir.gal@volumez.com/ WARNING: CPU: 0 PID: 5342 at net/core/skbuff.c:7140 skb_splice_from_iter+0x173/0x320 Call Trace: tcp_sendmsg_locked+0x368/0xe40 siw_tx_hdt+0x695/0xa40 [siw] siw_qp_sq_process+0x102/0xb00 [siw] siw_sq_resume+0x39/0x110 [siw] siw_run_sq+0x74/0x160 [siw] kthread+0xd2/0x100 ret_from_fork+0x34/0x40 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53100", "url": "https://ubuntu.com/security/CVE-2024-53100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: tcp: avoid race between queue_lock lock and destroy Commit 76d54bf20cdc (\"nvme-tcp: don't access released socket during error recovery\") added a mutex_lock() call for the queue->queue_lock in nvme_tcp_get_address(). However, the mutex_lock() races with mutex_destroy() in nvme_tcp_free_queue(), and causes the WARN below. DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: CPU: 3 PID: 34077 at kernel/locking/mutex.c:587 __mutex_lock+0xcf0/0x1220 Modules linked in: nvmet_tcp nvmet nvme_tcp nvme_fabrics iw_cm ib_cm ib_core pktcdvd nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables qrtr sunrpc ppdev 9pnet_virtio 9pnet pcspkr netfs parport_pc parport e1000 i2c_piix4 i2c_smbus loop fuse nfnetlink zram bochs drm_vram_helper drm_ttm_helper ttm drm_kms_helper xfs drm sym53c8xx floppy nvme scsi_transport_spi nvme_core nvme_auth serio_raw ata_generic pata_acpi dm_multipath qemu_fw_cfg [last unloaded: ib_uverbs] CPU: 3 UID: 0 PID: 34077 Comm: udisksd Not tainted 6.11.0-rc7 #319 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:__mutex_lock+0xcf0/0x1220 Code: 08 84 d2 0f 85 c8 04 00 00 8b 15 ef b6 c8 01 85 d2 0f 85 78 f4 ff ff 48 c7 c6 20 93 ee af 48 c7 c7 60 91 ee af e8 f0 a7 6d fd <0f> 0b e9 5e f4 ff ff 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 RSP: 0018:ffff88811305f760 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff88812c652058 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000001 RBP: ffff88811305f8b0 R08: 0000000000000001 R09: ffffed1075c36341 R10: ffff8883ae1b1a0b R11: 0000000000010498 R12: 0000000000000000 R13: 0000000000000000 R14: dffffc0000000000 R15: ffff88812c652058 FS: 00007f9713ae4980(0000) GS:ffff8883ae180000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcd78483c7c CR3: 0000000122c38000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn.cold+0x5b/0x1af ? __mutex_lock+0xcf0/0x1220 ? report_bug+0x1ec/0x390 ? handle_bug+0x3c/0x80 ? exc_invalid_op+0x13/0x40 ? asm_exc_invalid_op+0x16/0x20 ? __mutex_lock+0xcf0/0x1220 ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] ? __pfx___mutex_lock+0x10/0x10 ? __lock_acquire+0xd6a/0x59e0 ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] ? __pfx_nvme_tcp_get_address+0x10/0x10 [nvme_tcp] nvme_sysfs_show_address+0x81/0xc0 [nvme_core] dev_attr_show+0x42/0x80 ? __asan_memset+0x1f/0x40 sysfs_kf_seq_show+0x1f0/0x370 seq_read_iter+0x2cb/0x1130 ? rw_verify_area+0x3b1/0x590 ? __mutex_lock+0x433/0x1220 vfs_read+0x6a6/0xa20 ? lockdep_hardirqs_on+0x78/0x100 ? __pfx_vfs_read+0x10/0x10 ksys_read+0xf7/0x1d0 ? __pfx_ksys_read+0x10/0x10 ? __x64_sys_openat+0x105/0x1d0 do_syscall_64+0x93/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? __pfx_ksys_read+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? do_syscall_64+0x9f/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f9713f55cfa Code: 55 48 89 e5 48 83 ec 20 48 89 55 e8 48 89 75 f0 89 7d f8 e8 e8 74 f8 ff 48 8b 55 e8 48 8b 75 f0 4 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53095", "url": "https://ubuntu.com/security/CVE-2024-53095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix use-after-free of network namespace. Recently, we got a customer report that CIFS triggers oops while reconnecting to a server. [0] The workload runs on Kubernetes, and some pods mount CIFS servers in non-root network namespaces. The problem rarely happened, but it was always while the pod was dying. The root cause is wrong reference counting for network namespace. CIFS uses kernel sockets, which do not hold refcnt of the netns that the socket belongs to. That means CIFS must ensure the socket is always freed before its netns; otherwise, use-after-free happens. The repro steps are roughly: 1. mount CIFS in a non-root netns 2. drop packets from the netns 3. destroy the netns 4. unmount CIFS We can reproduce the issue quickly with the script [1] below and see the splat [2] if CONFIG_NET_NS_REFCNT_TRACKER is enabled. When the socket is TCP, it is hard to guarantee the netns lifetime without holding refcnt due to async timers. Let's hold netns refcnt for each socket as done for SMC in commit 9744d2bf1976 (\"smc: Fix use-after-free in tcp_write_timer_handler().\"). Note that we need to move put_net() from cifs_put_tcp_session() to clean_demultiplex_info(); otherwise, __sock_create() still could touch a freed netns while cifsd tries to reconnect from cifs_demultiplex_thread(). Also, maybe_get_net() cannot be put just before __sock_create() because the code is not under RCU and there is a small chance that the same address happened to be reallocated to another netns. [0]: CIFS: VFS: \\\\XXXXXXXXXXX has not responded in 15 seconds. Reconnecting... CIFS: Serverclose failed 4 times, giving up Unable to handle kernel paging request at virtual address 14de99e461f84a07 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 CM = 0, WnR = 0 [14de99e461f84a07] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: cls_bpf sch_ingress nls_utf8 cifs cifs_arc4 cifs_md4 dns_resolver tcp_diag inet_diag veth xt_state xt_connmark nf_conntrack_netlink xt_nat xt_statistic xt_MASQUERADE xt_mark xt_addrtype ipt_REJECT nf_reject_ipv4 nft_chain_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment nft_compat nf_tables nfnetlink overlay nls_ascii nls_cp437 sunrpc vfat fat aes_ce_blk aes_ce_cipher ghash_ce sm4_ce_cipher sm4 sm3_ce sm3 sha3_ce sha512_ce sha512_arm64 sha1_ce ena button sch_fq_codel loop fuse configfs dmi_sysfs sha2_ce sha256_arm64 dm_mirror dm_region_hash dm_log dm_mod dax efivarfs CPU: 5 PID: 2690970 Comm: cifsd Not tainted 6.1.103-109.184.amzn2023.aarch64 #1 Hardware name: Amazon EC2 r7g.4xlarge/, BIOS 1.0 11/1/2018 pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : fib_rules_lookup+0x44/0x238 lr : __fib_lookup+0x64/0xbc sp : ffff8000265db790 x29: ffff8000265db790 x28: 0000000000000000 x27: 000000000000bd01 x26: 0000000000000000 x25: ffff000b4baf8000 x24: ffff00047b5e4580 x23: ffff8000265db7e0 x22: 0000000000000000 x21: ffff00047b5e4500 x20: ffff0010e3f694f8 x19: 14de99e461f849f7 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 3f92800abd010002 x11: 0000000000000001 x10: ffff0010e3f69420 x9 : ffff800008a6f294 x8 : 0000000000000000 x7 : 0000000000000006 x6 : 0000000000000000 x5 : 0000000000000001 x4 : ffff001924354280 x3 : ffff8000265db7e0 x2 : 0000000000000000 x1 : ffff0010e3f694f8 x0 : ffff00047b5e4500 Call trace: fib_rules_lookup+0x44/0x238 __fib_lookup+0x64/0xbc ip_route_output_key_hash_rcu+0x2c4/0x398 ip_route_output_key_hash+0x60/0x8c tcp_v4_connect+0x290/0x488 __inet_stream_connect+0x108/0x3d0 inet_stream_connect+0x50/0x78 kernel_connect+0x6c/0xac generic_ip_conne ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-50265", "url": "https://ubuntu.com/security/CVE-2024-50265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove() Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove(): [ 57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12 [ 57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry [ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004 [...] [ 57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [...] [ 57.331328] Call Trace: [ 57.331477] [...] [ 57.333511] ? do_user_addr_fault+0x3e5/0x740 [ 57.333778] ? exc_page_fault+0x70/0x170 [ 57.334016] ? asm_exc_page_fault+0x2b/0x30 [ 57.334263] ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10 [ 57.334596] ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [ 57.334913] ocfs2_xa_remove_entry+0x23/0xc0 [ 57.335164] ocfs2_xa_set+0x704/0xcf0 [ 57.335381] ? _raw_spin_unlock+0x1a/0x40 [ 57.335620] ? ocfs2_inode_cache_unlock+0x16/0x20 [ 57.335915] ? trace_preempt_on+0x1e/0x70 [ 57.336153] ? start_this_handle+0x16c/0x500 [ 57.336410] ? preempt_count_sub+0x50/0x80 [ 57.336656] ? _raw_read_unlock+0x20/0x40 [ 57.336906] ? start_this_handle+0x16c/0x500 [ 57.337162] ocfs2_xattr_block_set+0xa6/0x1e0 [ 57.337424] __ocfs2_xattr_set_handle+0x1fd/0x5d0 [ 57.337706] ? ocfs2_start_trans+0x13d/0x290 [ 57.337971] ocfs2_xattr_set+0xb13/0xfb0 [ 57.338207] ? dput+0x46/0x1c0 [ 57.338393] ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338665] ? ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338948] __vfs_removexattr+0x92/0xc0 [ 57.339182] __vfs_removexattr_locked+0xd5/0x190 [ 57.339456] ? preempt_count_sub+0x50/0x80 [ 57.339705] vfs_removexattr+0x5f/0x100 [...] Reproducer uses faultinject facility to fail ocfs2_xa_remove() -> ocfs2_xa_value_truncate() with -ENOMEM. In this case the comment mentions that we can return 0 if ocfs2_xa_cleanup_value_truncate() is going to wipe the entry anyway. But the following 'rc' check is wrong and execution flow do 'ocfs2_xa_remove_entry(loc);' twice: * 1st: in ocfs2_xa_cleanup_value_truncate(); * 2nd: returning back to ocfs2_xa_remove() instead of going to 'out'. Fix this by skipping the 2nd removal of the same entry and making syzkaller repro happy.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50266", "url": "https://ubuntu.com/security/CVE-2024-50266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: qcom: videocc-sm8350: use HW_CTRL_TRIGGER for vcodec GDSCs A recent change in the venus driver results in a stuck clock on the Lenovo ThinkPad X13s, for example, when streaming video in firefox: \tvideo_cc_mvs0_clk status stuck at 'off' \tWARNING: CPU: 6 PID: 2885 at drivers/clk/qcom/clk-branch.c:87 clk_branch_wait+0x144/0x15c \t... \tCall trace: \t clk_branch_wait+0x144/0x15c \t clk_branch2_enable+0x30/0x40 \t clk_core_enable+0xd8/0x29c \t clk_enable+0x2c/0x4c \t vcodec_clks_enable.isra.0+0x94/0xd8 [venus_core] \t coreid_power_v4+0x464/0x628 [venus_core] \t vdec_start_streaming+0xc4/0x510 [venus_dec] \t vb2_start_streaming+0x6c/0x180 [videobuf2_common] \t vb2_core_streamon+0x120/0x1dc [videobuf2_common] \t vb2_streamon+0x1c/0x6c [videobuf2_v4l2] \t v4l2_m2m_ioctl_streamon+0x30/0x80 [v4l2_mem2mem] \t v4l_streamon+0x24/0x30 [videodev] using the out-of-tree sm8350/sc8280xp venus support. [1] Update also the sm8350/sc8280xp GDSC definitions so that the hw control mode can be changed at runtime as the venus driver now requires.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50267", "url": "https://ubuntu.com/security/CVE-2024-50267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: fix use after free in debug printk The \"dev_dbg(&urb->dev->dev, ...\" which happens after usb_free_urb(urb) is a use after free of the \"urb\" pointer. Store the \"dev\" pointer at the start of the function to avoid this issue.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50268", "url": "https://ubuntu.com/security/CVE-2024-50268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: fix potential out of bounds in ucsi_ccg_update_set_new_cam_cmd() The \"*cmd\" variable can be controlled by the user via debugfs. That means \"new_cam\" can be as high as 255 while the size of the uc->updated[] array is UCSI_MAX_ALTMODES (30). The call tree is: ucsi_cmd() // val comes from simple_attr_write_xsigned() -> ucsi_send_command() -> ucsi_send_command_common() -> ucsi_run_command() // calls ucsi->ops->sync_control() -> ucsi_ccg_sync_control()", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53083", "url": "https://ubuntu.com/security/CVE-2024-53083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: qcom-pmic: init value of hdr_len/txbuf_len earlier If the read of USB_PDPHY_RX_ACKNOWLEDGE_REG failed, then hdr_len and txbuf_len are uninitialized. This commit stops to print uninitialized value and misleading/false data.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50269", "url": "https://ubuntu.com/security/CVE-2024-50269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: musb: sunxi: Fix accessing an released usb phy Commit 6ed05c68cbca (\"usb: musb: sunxi: Explicitly release USB PHY on exit\") will cause that usb phy @glue->xceiv is accessed after released. 1) register platform driver @sunxi_musb_driver // get the usb phy @glue->xceiv sunxi_musb_probe() -> devm_usb_get_phy(). 2) register and unregister platform driver @musb_driver musb_probe() -> sunxi_musb_init() use the phy here //the phy is released here musb_remove() -> sunxi_musb_exit() -> devm_usb_put_phy() 3) register @musb_driver again musb_probe() -> sunxi_musb_init() use the phy here but the phy has been released at 2). ... Fixed by reverting the commit, namely, removing devm_usb_put_phy() from sunxi_musb_exit().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53079", "url": "https://ubuntu.com/security/CVE-2024-53079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/thp: fix deferred split unqueue naming and locking Recent changes are putting more pressure on THP deferred split queues: under load revealing long-standing races, causing list_del corruptions, \"Bad page state\"s and worse (I keep BUGs in both of those, so usually don't get to see how badly they end up without). The relevant recent changes being 6.8's mTHP, 6.10's mTHP swapout, and 6.12's mTHP swapin, improved swap allocation, and underused THP splitting. Before fixing locking: rename misleading folio_undo_large_rmappable(), which does not undo large_rmappable, to folio_unqueue_deferred_split(), which is what it does. But that and its out-of-line __callee are mm internals of very limited usability: add comment and WARN_ON_ONCEs to check usage; and return a bool to say if a deferred split was unqueued, which can then be used in WARN_ON_ONCEs around safety checks (sparing callers the arcane conditionals in __folio_unqueue_deferred_split()). Just omit the folio_unqueue_deferred_split() from free_unref_folios(), all of whose callers now call it beforehand (and if any forget then bad_page() will tell) - except for its caller put_pages_list(), which itself no longer has any callers (and will be deleted separately). Swapout: mem_cgroup_swapout() has been resetting folio->memcg_data 0 without checking and unqueueing a THP folio from deferred split list; which is unfortunate, since the split_queue_lock depends on the memcg (when memcg is enabled); so swapout has been unqueueing such THPs later, when freeing the folio, using the pgdat's lock instead: potentially corrupting the memcg's list. __remove_mapping() has frozen refcount to 0 here, so no problem with calling folio_unqueue_deferred_split() before resetting memcg_data. That goes back to 5.4 commit 87eaceb3faa5 (\"mm: thp: make deferred split shrinker memcg aware\"): which included a check on swapcache before adding to deferred queue, but no check on deferred queue before adding THP to swapcache. That worked fine with the usual sequence of events in reclaim (though there were a couple of rare ways in which a THP on deferred queue could have been swapped out), but 6.12 commit dafff3f4c850 (\"mm: split underused THPs\") avoids splitting underused THPs in reclaim, which makes swapcache THPs on deferred queue commonplace. Keep the check on swapcache before adding to deferred queue? Yes: it is no longer essential, but preserves the existing behaviour, and is likely to be a worthwhile optimization (vmstat showed much more traffic on the queue under swapping load if the check was removed); update its comment. Memcg-v1 move (deprecated): mem_cgroup_move_account() has been changing folio->memcg_data without checking and unqueueing a THP folio from the deferred list, sometimes corrupting \"from\" memcg's list, like swapout. Refcount is non-zero here, so folio_unqueue_deferred_split() can only be used in a WARN_ON_ONCE to validate the fix, which must be done earlier: mem_cgroup_move_charge_pte_range() first try to split the THP (splitting of course unqueues), or skip it if that fails. Not ideal, but moving charge has been requested, and khugepaged should repair the THP later: nobody wants new custom unqueueing code just for this deprecated case. The 87eaceb3faa5 commit did have the code to move from one deferred list to another (but was not conscious of its unsafety while refcount non-0); but that was removed by 5.6 commit fac0516b5534 (\"mm: thp: don't need care deferred split queue in memcg charge move path\"), which argued that the existence of a PMD mapping guarantees that the THP cannot be on a deferred list. As above, false in rare cases, and now commonly false. Backport to 6.11 should be straightforward. Earlier backports must take care that other _deferred_list fixes and dependencies are included. There is not a strong case for backports, but they can fix cornercases.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50270", "url": "https://ubuntu.com/security/CVE-2024-50270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: avoid overflow in damon_feed_loop_next_input() damon_feed_loop_next_input() is inefficient and fragile to overflows. Specifically, 'score_goal_diff_bp' calculation can overflow when 'score' is high. The calculation is actually unnecessary at all because 'goal' is a constant of value 10,000. Calculation of 'compensation' is again fragile to overflow. Final calculation of return value for under-achiving case is again fragile to overflow when the current score is under-achieving the target. Add two corner cases handling at the beginning of the function to make the body easier to read, and rewrite the body of the function to avoid overflows and the unnecessary bp value calcuation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50271", "url": "https://ubuntu.com/security/CVE-2024-50271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: signal: restore the override_rlimit logic Prior to commit d64696905554 (\"Reimplement RLIMIT_SIGPENDING on top of ucounts\") UCOUNT_RLIMIT_SIGPENDING rlimit was not enforced for a class of signals. However now it's enforced unconditionally, even if override_rlimit is set. This behavior change caused production issues. For example, if the limit is reached and a process receives a SIGSEGV signal, sigqueue_alloc fails to allocate the necessary resources for the signal delivery, preventing the signal from being delivered with siginfo. This prevents the process from correctly identifying the fault address and handling the error. From the user-space perspective, applications are unaware that the limit has been reached and that the siginfo is effectively 'corrupted'. This can lead to unpredictable behavior and crashes, as we observed with java applications. Fix this by passing override_rlimit into inc_rlimit_get_ucounts() and skip the comparison to max there if override_rlimit is set. This effectively restores the old behavior.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50272", "url": "https://ubuntu.com/security/CVE-2024-50272", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: filemap: Fix bounds checking in filemap_read() If the caller supplies an iocb->ki_pos value that is close to the filesystem upper limit, and an iterator with a count that causes us to overflow that limit, then filemap_read() enters an infinite loop. This behaviour was discovered when testing xfstests generic/525 with the \"localio\" optimisation for loopback NFS mounts.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53104", "url": "https://ubuntu.com/security/CVE-2024-53104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_parse_format This can lead to out of bounds writes since frames of this type were not taken into account when calculating the size of the frames buffer in uvc_parse_streaming.", "cve_priority": "high", "cve_public_date": "2024-12-02 08:15:00 UTC" }, { "cve": "CVE-2024-50273", "url": "https://ubuntu.com/security/CVE-2024-50273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reinitialize delayed ref list after deleting it from the list At insert_delayed_ref() if we need to update the action of an existing ref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head's ref_add_list using list_del(), which leaves the ref's add_list member not reinitialized, as list_del() sets the next and prev members of the list to LIST_POISON1 and LIST_POISON2, respectively. If later we end up calling drop_delayed_ref() against the ref, which can happen during merging or when destroying delayed refs due to a transaction abort, we can trigger a crash since at drop_delayed_ref() we call list_empty() against the ref's add_list, which returns false since the list was not reinitialized after the list_del() and as a consequence we call list_del() again at drop_delayed_ref(). This results in an invalid list access since the next and prev members are set to poison pointers, resulting in a splat if CONFIG_LIST_HARDENED and CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences otherwise. So fix this by deleting from the list with list_del_init() instead.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53064", "url": "https://ubuntu.com/security/CVE-2024-53064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix idpf_vc_core_init error path In an event where the platform running the device control plane is rebooted, reset is detected on the driver. It releases all the resources and waits for the reset to complete. Once the reset is done, it tries to build the resources back. At this time if the device control plane is not yet started, then the driver timeouts on the virtchnl message and retries to establish the mailbox again. In the retry flow, mailbox is deinitialized but the mailbox workqueue is still alive and polling for the mailbox message. This results in accessing the released control queue leading to null-ptr-deref. Fix it by unrolling the work queue cancellation and mailbox deinitialization in the reverse order which they got initialized.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50274", "url": "https://ubuntu.com/security/CVE-2024-50274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: avoid vport access in idpf_get_link_ksettings When the device control plane is removed or the platform running device control plane is rebooted, a reset is detected on the driver. On driver reset, it releases the resources and waits for the reset to complete. If the reset fails, it takes the error path and releases the vport lock. At this time if the monitoring tools tries to access link settings, it call traces for accessing released vport pointer. To avoid it, move link_speed_mbps to netdev_priv structure which removes the dependency on vport pointer and the vport lock in idpf_get_link_ksettings. Also use netif_carrier_ok() to check the link status and adjust the offsetof to use link_up instead of link_speed_mbps.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53065", "url": "https://ubuntu.com/security/CVE-2024-53065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/slab: fix warning caused by duplicate kmem_cache creation in kmem_buckets_create Commit b035f5a6d852 (\"mm: slab: reduce the kmalloc() minimum alignment if DMA bouncing possible\") reduced ARCH_KMALLOC_MINALIGN to 8 on arm64. However, with KASAN_HW_TAGS enabled, arch_slab_minalign() becomes 16. This causes kmalloc_caches[*][8] to be aliased to kmalloc_caches[*][16], resulting in kmem_buckets_create() attempting to create a kmem_cache for size 16 twice. This duplication triggers warnings on boot: [ 2.325108] ------------[ cut here ]------------ [ 2.325135] kmem_cache of name 'memdup_user-16' already exists [ 2.325783] WARNING: CPU: 0 PID: 1 at mm/slab_common.c:107 __kmem_cache_create_args+0xb8/0x3b0 [ 2.327957] Modules linked in: [ 2.328550] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5mm-unstable-arm64+ #12 [ 2.328683] Hardware name: QEMU QEMU Virtual Machine, BIOS 2024.02-2 03/11/2024 [ 2.328790] pstate: 61000009 (nZCv daif -PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 2.328911] pc : __kmem_cache_create_args+0xb8/0x3b0 [ 2.328930] lr : __kmem_cache_create_args+0xb8/0x3b0 [ 2.328942] sp : ffff800083d6fc50 [ 2.328961] x29: ffff800083d6fc50 x28: f2ff0000c1674410 x27: ffff8000820b0598 [ 2.329061] x26: 000000007fffffff x25: 0000000000000010 x24: 0000000000002000 [ 2.329101] x23: ffff800083d6fce8 x22: ffff8000832222e8 x21: ffff800083222388 [ 2.329118] x20: f2ff0000c1674410 x19: f5ff0000c16364c0 x18: ffff800083d80030 [ 2.329135] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 2.329152] x14: 0000000000000000 x13: 0a73747369786520 x12: 79646165726c6120 [ 2.329169] x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : 0000000000000000 [ 2.329194] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 [ 2.329210] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 2.329226] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 2.329291] Call trace: [ 2.329407] __kmem_cache_create_args+0xb8/0x3b0 [ 2.329499] kmem_buckets_create+0xfc/0x320 [ 2.329526] init_user_buckets+0x34/0x78 [ 2.329540] do_one_initcall+0x64/0x3c8 [ 2.329550] kernel_init_freeable+0x26c/0x578 [ 2.329562] kernel_init+0x3c/0x258 [ 2.329574] ret_from_fork+0x10/0x20 [ 2.329698] ---[ end trace 0000000000000000 ]--- [ 2.403704] ------------[ cut here ]------------ [ 2.404716] kmem_cache of name 'msg_msg-16' already exists [ 2.404801] WARNING: CPU: 2 PID: 1 at mm/slab_common.c:107 __kmem_cache_create_args+0xb8/0x3b0 [ 2.404842] Modules linked in: [ 2.404971] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.12.0-rc5mm-unstable-arm64+ #12 [ 2.405026] Tainted: [W]=WARN [ 2.405043] Hardware name: QEMU QEMU Virtual Machine, BIOS 2024.02-2 03/11/2024 [ 2.405057] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2.405079] pc : __kmem_cache_create_args+0xb8/0x3b0 [ 2.405100] lr : __kmem_cache_create_args+0xb8/0x3b0 [ 2.405111] sp : ffff800083d6fc50 [ 2.405115] x29: ffff800083d6fc50 x28: fbff0000c1674410 x27: ffff8000820b0598 [ 2.405135] x26: 000000000000ffd0 x25: 0000000000000010 x24: 0000000000006000 [ 2.405153] x23: ffff800083d6fce8 x22: ffff8000832222e8 x21: ffff800083222388 [ 2.405169] x20: fbff0000c1674410 x19: fdff0000c163d6c0 x18: ffff800083d80030 [ 2.405185] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 2.405201] x14: 0000000000000000 x13: 0a73747369786520 x12: 79646165726c6120 [ 2.405217] x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : 0000000000000000 [ 2.405233] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 [ 2.405248] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 2.405271] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 2.405287] Call trace: [ 2 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50275", "url": "https://ubuntu.com/security/CVE-2024-50275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64/sve: Discard stale CPU state when handling SVE traps The logic for handling SVE traps manipulates saved FPSIMD/SVE state incorrectly, and a race with preemption can result in a task having TIF_SVE set and TIF_FOREIGN_FPSTATE clear even though the live CPU state is stale (e.g. with SVE traps enabled). This has been observed to result in warnings from do_sve_acc() where SVE traps are not expected while TIF_SVE is set: | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* SVE access shouldn't have trapped */ Warnings of this form have been reported intermittently, e.g. https://lore.kernel.org/linux-arm-kernel/CA+G9fYtEGe_DhY2Ms7+L7NKsLYUomGsgqpdBj+QwDLeSg=JhGg@mail.gmail.com/ https://lore.kernel.org/linux-arm-kernel/000000000000511e9a060ce5a45c@google.com/ The race can occur when the SVE trap handler is preempted before and after manipulating the saved FPSIMD/SVE state, starting and ending on the same CPU, e.g. | void do_sve_acc(unsigned long esr, struct pt_regs *regs) | { | // Trap on CPU 0 with TIF_SVE clear, SVE 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(); | | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* SVE access shouldn't have trapped */ | | sve_init_regs() { | if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) { | ... | } else { | fpsimd_to_sve(current); | current->thread.fp_type = FP_STATE_SVE; | } | } | | 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 SVE 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.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50276", "url": "https://ubuntu.com/security/CVE-2024-50276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: vertexcom: mse102x: Fix possible double free of TX skb The scope of the TX skb is wider than just mse102x_tx_frame_spi(), so in case the TX skb room needs to be expanded, we should free the the temporary skb instead of the original skb. Otherwise the original TX skb pointer would be freed again in mse102x_tx_work(), which leads to crashes: Internal error: Oops: 0000000096000004 [#2] PREEMPT SMP CPU: 0 PID: 712 Comm: kworker/0:1 Tainted: G D 6.6.23 Hardware name: chargebyte Charge SOM DC-ONE (DT) Workqueue: events mse102x_tx_work [mse102x] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_release_data+0xb8/0x1d8 lr : skb_release_data+0x1ac/0x1d8 sp : ffff8000819a3cc0 x29: ffff8000819a3cc0 x28: ffff0000046daa60 x27: ffff0000057f2dc0 x26: ffff000005386c00 x25: 0000000000000002 x24: 00000000ffffffff x23: 0000000000000000 x22: 0000000000000001 x21: ffff0000057f2e50 x20: 0000000000000006 x19: 0000000000000000 x18: ffff00003fdacfcc x17: e69ad452d0c49def x16: 84a005feff870102 x15: 0000000000000000 x14: 000000000000024a x13: 0000000000000002 x12: 0000000000000000 x11: 0000000000000400 x10: 0000000000000930 x9 : ffff00003fd913e8 x8 : fffffc00001bc008 x7 : 0000000000000000 x6 : 0000000000000008 x5 : ffff00003fd91340 x4 : 0000000000000000 x3 : 0000000000000009 x2 : 00000000fffffffe x1 : 0000000000000000 x0 : 0000000000000000 Call trace: skb_release_data+0xb8/0x1d8 kfree_skb_reason+0x48/0xb0 mse102x_tx_work+0x164/0x35c [mse102x] process_one_work+0x138/0x260 worker_thread+0x32c/0x438 kthread+0x118/0x11c ret_from_fork+0x10/0x20 Code: aa1303e0 97fffab6 72001c1f 54000141 (f9400660)", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53066", "url": "https://ubuntu.com/security/CVE-2024-53066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfs: Fix KMSAN warning in decode_getfattr_attrs() Fix the following KMSAN warning: CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G B Tainted: [B]=BAD_PAGE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) ===================================================== ===================================================== BUG: KMSAN: uninit-value in decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_generic+0x806/0xb00 nfs4_xdr_dec_getattr+0x1de/0x240 rpcauth_unwrap_resp_decode+0xab/0x100 rpcauth_unwrap_resp+0x95/0xc0 call_decode+0x4ff/0xb50 __rpc_execute+0x57b/0x19d0 rpc_execute+0x368/0x5e0 rpc_run_task+0xcfe/0xee0 nfs4_proc_getattr+0x5b5/0x990 __nfs_revalidate_inode+0x477/0xd00 nfs_access_get_cached+0x1021/0x1cc0 nfs_do_access+0x9f/0xae0 nfs_permission+0x1e4/0x8c0 inode_permission+0x356/0x6c0 link_path_walk+0x958/0x1330 path_lookupat+0xce/0x6b0 filename_lookup+0x23e/0x770 vfs_statx+0xe7/0x970 vfs_fstatat+0x1f2/0x2c0 __se_sys_newfstatat+0x67/0x880 __x64_sys_newfstatat+0xbd/0x120 x64_sys_call+0x1826/0x3cf0 do_syscall_64+0xd0/0x1b0 entry_SYSCALL_64_after_hwframe+0x77/0x7f The KMSAN warning is triggered in decode_getfattr_attrs(), when calling decode_attr_mdsthreshold(). It appears that fattr->mdsthreshold is not initialized. Fix the issue by initializing fattr->mdsthreshold to NULL in nfs_fattr_init().", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53067", "url": "https://ubuntu.com/security/CVE-2024-53067", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Start the RTC update work later The RTC update work involves runtime resuming the UFS controller. Hence, only start the RTC update work after runtime power management in the UFS driver has been fully initialized. This patch fixes the following kernel crash: Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP Workqueue: events ufshcd_rtc_work Call trace: _raw_spin_lock_irqsave+0x34/0x8c (P) pm_runtime_get_if_active+0x24/0x9c (L) pm_runtime_get_if_active+0x24/0x9c ufshcd_rtc_work+0x138/0x1b4 process_one_work+0x148/0x288 worker_thread+0x2cc/0x3d4 kthread+0x110/0x114 ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50277", "url": "https://ubuntu.com/security/CVE-2024-50277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: fix a crash if blk_alloc_disk fails If blk_alloc_disk fails, the variable md->disk is set to an error value. cleanup_mapped_device will see that md->disk is non-NULL and it will attempt to access it, causing a crash on this statement \"md->disk->private_data = NULL;\".", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50278", "url": "https://ubuntu.com/security/CVE-2024-50278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix potential out-of-bounds access on the first resume Out-of-bounds access occurs if the fast device is expanded unexpectedly before the first-time resume of the cache table. This happens because expanding the fast device requires reloading the cache table for cache_create to allocate new in-core data structures that fit the new size, and the check in cache_preresume is not performed during the first resume, leading to the issue. Reproduce steps: 1. prepare component devices: 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\" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct 2. load a cache table of 512 cache blocks, and deliberately expand the fast device before resuming the cache, making the in-core data structures inadequate. dmsetup create cache --notable dmsetup reload cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" dmsetup reload cdata --table \"0 131072 linear /dev/sdc 8192\" dmsetup resume cdata dmsetup resume cache 3. suspend the cache to write out the in-core dirty bitset and hint array, leading to out-of-bounds access to the dirty bitset at offset 0x40: dmsetup suspend cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80 Read of size 8 at addr ffffc90000085040 by task dmsetup/90 (...snip...) The buggy address belongs to the virtual mapping at [ffffc90000085000, ffffc90000087000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by checking the size change on the first resume.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50279", "url": "https://ubuntu.com/security/CVE-2024-50279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix out-of-bounds access to the dirty bitset when resizing dm-cache checks the dirty bits of the cache blocks to be dropped when shrinking the fast device, but an index bug in bitset iteration causes out-of-bounds access. Reproduce steps: 1. create a cache device of 1024 cache blocks (128 bytes dirty bitset) dmsetup create cmeta --table \"0 8192 linear /dev/sdc 0\" dmsetup create cdata --table \"0 131072 linear /dev/sdc 8192\" dmsetup create corig --table \"0 524288 linear /dev/sdc 262144\" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" 2. shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80) dmsetup suspend cache dmsetup reload cdata --table \"0 65536 linear /dev/sdc 8192\" dmsetup resume cdata dmsetup resume cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131 (...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by making the index post-incremented.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50280", "url": "https://ubuntu.com/security/CVE-2024-50280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix flushing uninitialized delayed_work on cache_ctr error An unexpected WARN_ON from flush_work() may occur when cache creation fails, caused by destroying the uninitialized delayed_work waker in the error path of cache_create(). For example, the warning appears on the superblock checksum error. Reproduce steps: 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\" dd if=/dev/urandom of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" Kernel logs: (snip) WARNING: CPU: 0 PID: 84 at kernel/workqueue.c:4178 __flush_work+0x5d4/0x890 Fix by pulling out the cancel_delayed_work_sync() from the constructor's error path. This patch doesn't affect the use-after-free fix for concurrent dm_resume and dm_destroy (commit 6a459d8edbdb (\"dm cache: Fix UAF in destroy()\")) as cache_dtr is not changed.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50281", "url": "https://ubuntu.com/security/CVE-2024-50281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: trusted: dcp: fix NULL dereference in AEAD crypto operation When sealing or unsealing a key blob we currently do not wait for the AEAD cipher operation to finish and simply return after submitting the request. If there is some load on the system we can exit before the cipher operation is done and the buffer we read from/write to is already removed from the stack. This will e.g. result in NULL pointer dereference errors in the DCP driver during blob creation. Fix this by waiting for the AEAD cipher operation to finish before resuming the seal and unseal calls.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50282", "url": "https://ubuntu.com/security/CVE-2024-50282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read() Avoid a possible buffer overflow if size is larger than 4K. (cherry picked from commit f5d873f5825b40d886d03bd2aede91d4cf002434)", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53071", "url": "https://ubuntu.com/security/CVE-2024-53071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Be stricter about IO mapping flags The current panthor_device_mmap_io() implementation has two issues: 1. For mapping DRM_PANTHOR_USER_FLUSH_ID_MMIO_OFFSET, panthor_device_mmap_io() bails if VM_WRITE is set, but does not clear VM_MAYWRITE. That means userspace can use mprotect() to make the mapping writable later on. This is a classic Linux driver gotcha. I don't think this actually has any impact in practice: When the GPU is powered, writes to the FLUSH_ID seem to be ignored; and when the GPU is not powered, the dummy_latest_flush page provided by the driver is deliberately designed to not do any flushes, so the only thing writing to the dummy_latest_flush could achieve would be to make *more* flushes happen. 2. panthor_device_mmap_io() does not block MAP_PRIVATE mappings (which are mappings without the VM_SHARED flag). MAP_PRIVATE in combination with VM_MAYWRITE indicates that the VMA has copy-on-write semantics, which for VM_PFNMAP are semi-supported but fairly cursed. In particular, in such a mapping, the driver can only install PTEs during mmap() by calling remap_pfn_range() (because remap_pfn_range() wants to **store the physical address of the mapped physical memory into the vm_pgoff of the VMA**); installing PTEs later on with a fault handler (as panthor does) is not supported in private mappings, and so if you try to fault in such a mapping, vmf_insert_pfn_prot() splats when it hits a BUG() check. Fix it by clearing the VM_MAYWRITE flag (userspace writing to the FLUSH_ID doesn't make sense) and requiring VM_SHARED (copy-on-write semantics for the FLUSH_ID don't make sense). Reproducers for both scenarios are in the notes of my patch on the mailing list; I tested that these bugs exist on a Rock 5B machine. Note that I only compile-tested the patch, I haven't tested it; I don't have a working kernel build setup for the test machine yet. Please test it before applying it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53080", "url": "https://ubuntu.com/security/CVE-2024-53080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Lock XArray when getting entries for the VM Similar to commit cac075706f29 (\"drm/panthor: Fix race when converting group handle to group object\") we need to use the XArray's internal locking when retrieving a vm pointer from there. v2: Removed part of the patch that was trying to protect fetching the heap pointer from XArray, as that operation is protected by the @pool->lock.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53084", "url": "https://ubuntu.com/security/CVE-2024-53084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Break an object reference loop When remaining resources are being cleaned up on driver close, outstanding VM mappings may result in resources being leaked, due to an object reference loop, as shown below, with each object (or set of objects) referencing the object below it: PVR GEM Object GPU scheduler \"finished\" fence GPU scheduler “scheduled” fence PVR driver “done” fence PVR Context PVR VM Context PVR VM Mappings PVR GEM Object The reference that the PVR VM Context has on the VM mappings is a soft one, in the sense that the freeing of outstanding VM mappings is done as part of VM context destruction; no reference counts are involved, as is the case for all the other references in the loop. To break the reference loop during cleanup, free the outstanding VM mappings before destroying the PVR Context associated with the VM context.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53085", "url": "https://ubuntu.com/security/CVE-2024-53085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: Lock TPM chip in tpm_pm_suspend() first Setting TPM_CHIP_FLAG_SUSPENDED in the end of tpm_pm_suspend() can be racy according, as this leaves window for tpm_hwrng_read() to be called while the operation is in progress. The recent bug report gives also evidence of this behaviour. Aadress this by locking the TPM chip before checking any chip->flags both in tpm_pm_suspend() and tpm_hwrng_read(). Move TPM_CHIP_FLAG_SUSPENDED check inside tpm_get_random() so that it will be always checked only when the lock is reserved.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53086", "url": "https://ubuntu.com/security/CVE-2024-53086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Drop VM dma-resv lock on xe_sync_in_fence_get failure in exec IOCTL Upon failure all locks need to be dropped before returning to the user. (cherry picked from commit 7d1a4258e602ffdce529f56686925034c1b3b095)", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53087", "url": "https://ubuntu.com/security/CVE-2024-53087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix possible exec queue leak in exec IOCTL In a couple of places after an exec queue is looked up the exec IOCTL returns on input errors without dropping the exec queue ref. Fix this ensuring the exec queue ref is dropped on input error. (cherry picked from commit 07064a200b40ac2195cb6b7b779897d9377e5e6f)", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50283", "url": "https://ubuntu.com/security/CVE-2024-50283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-use-after-free in smb3_preauth_hash_rsp ksmbd_user_session_put should be called under smb3_preauth_hash_rsp(). It will avoid freeing session before calling smb3_preauth_hash_rsp().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50284", "url": "https://ubuntu.com/security/CVE-2024-50284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix the missing xa_store error check xa_store() can fail, it return xa_err(-EINVAL) if the entry cannot be stored in an XArray, or xa_err(-ENOMEM) if memory allocation failed, so check error for xa_store() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50285", "url": "https://ubuntu.com/security/CVE-2024-50285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: check outstanding simultaneous SMB operations If Client send simultaneous SMB operations to ksmbd, It exhausts too much memory through the \"ksmbd_work_cache”. It will cause OOM issue. ksmbd has a credit mechanism but it can't handle this problem. This patch add the check if it exceeds max credits to prevent this problem by assuming that one smb request consumes at least one credit.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50286", "url": "https://ubuntu.com/security/CVE-2024-50286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-use-after-free in ksmbd_smb2_session_create There is a race condition between ksmbd_smb2_session_create and ksmbd_expire_session. This patch add missing sessions_table_lock while adding/deleting session from global session table.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50287", "url": "https://ubuntu.com/security/CVE-2024-50287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-tpg: prevent the risk of a division by zero As reported by Coverity, the logic at tpg_precalculate_line() blindly rescales the buffer even when scaled_witdh is equal to zero. If this ever happens, this will cause a division by zero. Instead, add a WARN_ON_ONCE() to trigger such cases and return without doing any precalculation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50288", "url": "https://ubuntu.com/security/CVE-2024-50288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: fix buffer overwrite when using > 32 buffers The maximum number of buffers that can be requested was increased to 64 for the video capture queue. But video capture used a must_blank array that was still sized for 32 (VIDEO_MAX_FRAME). This caused an out-of-bounds write when using buffer indices >= 32. Create a new define MAX_VID_CAP_BUFFERS that is used to access the must_blank array and set max_num_buffers for the video capture queue. This solves a crash reported by: \thttps://bugzilla.kernel.org/show_bug.cgi?id=219258", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50289", "url": "https://ubuntu.com/security/CVE-2024-50289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: av7110: fix a spectre vulnerability As warned by smatch: \tdrivers/staging/media/av7110/av7110_ca.c:270 dvb_ca_ioctl() warn: potential spectre issue 'av7110->ci_slot' [w] (local cap) There is a spectre-related vulnerability at the code. Fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50290", "url": "https://ubuntu.com/security/CVE-2024-50290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx24116: prevent overflows on SNR calculus as reported by Coverity, if reading SNR registers fail, a negative number will be returned, causing an underflow when reading SNR registers. Prevent that.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53061", "url": "https://ubuntu.com/security/CVE-2024-53061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: s5p-jpeg: prevent buffer overflows The current logic allows word to be less than 2. If this happens, there will be buffer overflows, as reported by smatch. Add extra checks to prevent it. While here, remove an unused word = 0 assignment.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53081", "url": "https://ubuntu.com/security/CVE-2024-53081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ar0521: don't overflow when checking PLL values The PLL checks are comparing 64 bit integers with 32 bit ones, as reported by Coverity. Depending on the values of the variables, this may underflow. Fix it ensuring that both sides of the expression are u64.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53062", "url": "https://ubuntu.com/security/CVE-2024-53062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mgb4: protect driver against spectre Frequency range is set from sysfs via frequency_range_store(), being vulnerable to spectre, as reported by smatch: \tdrivers/media/pci/mgb4/mgb4_cmt.c:231 mgb4_cmt_set_vin_freq_range() warn: potential spectre issue 'cmt_vals_in' [r] \tdrivers/media/pci/mgb4/mgb4_cmt.c:238 mgb4_cmt_set_vin_freq_range() warn: possible spectre second half. 'reg_set' Fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50291", "url": "https://ubuntu.com/security/CVE-2024-50291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvb-core: add missing buffer index check dvb_vb2_expbuf() didn't check if the given buffer index was for a valid buffer. Add this check.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50292", "url": "https://ubuntu.com/security/CVE-2024-50292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: stm32: spdifrx: fix dma channel release in stm32_spdifrx_remove In case of error when requesting ctrl_chan DMA channel, ctrl_chan is not null. So the release of the dma channel leads to the following issue: [ 4.879000] st,stm32-spdifrx 500d0000.audio-controller: dma_request_slave_channel error -19 [ 4.888975] Unable to handle kernel NULL pointer dereference at virtual address 000000000000003d [...] [ 5.096577] Call trace: [ 5.099099] dma_release_channel+0x24/0x100 [ 5.103235] stm32_spdifrx_remove+0x24/0x60 [snd_soc_stm32_spdifrx] [ 5.109494] stm32_spdifrx_probe+0x320/0x4c4 [snd_soc_stm32_spdifrx] To avoid this issue, release channel only if the pointer is valid.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53063", "url": "https://ubuntu.com/security/CVE-2024-53063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvbdev: prevent the risk of out of memory access The dvbdev contains a static variable used to store dvb minors. The behavior of it depends if CONFIG_DVB_DYNAMIC_MINORS is set or not. When not set, dvb_register_device() won't check for boundaries, as it will rely that a previous call to dvb_register_adapter() would already be enforcing it. On a similar way, dvb_device_open() uses the assumption that the register functions already did the needed checks. This can be fragile if some device ends using different calls. This also generate warnings on static check analysers like Coverity. So, add explicit guards to prevent potential risk of OOM issues.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50293", "url": "https://ubuntu.com/security/CVE-2024-50293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: do not leave a dangling sk pointer in __smc_create() Thanks to commit 4bbd360a5084 (\"socket: Print pf->create() when it does not clear sock->sk on failure.\"), syzbot found an issue with AF_SMC: smc_create must clear sock->sk on failure, family: 43, type: 1, protocol: 0 WARNING: CPU: 0 PID: 5827 at net/socket.c:1565 __sock_create+0x96f/0xa30 net/socket.c:1563 Modules linked in: CPU: 0 UID: 0 PID: 5827 Comm: syz-executor259 Not tainted 6.12.0-rc6-next-20241106-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:__sock_create+0x96f/0xa30 net/socket.c:1563 Code: 03 00 74 08 4c 89 e7 e8 4f 3b 85 f8 49 8b 34 24 48 c7 c7 40 89 0c 8d 8b 54 24 04 8b 4c 24 0c 44 8b 44 24 08 e8 32 78 db f7 90 <0f> 0b 90 90 e9 d3 fd ff ff 89 e9 80 e1 07 fe c1 38 c1 0f 8c ee f7 RSP: 0018:ffffc90003e4fda0 EFLAGS: 00010246 RAX: 099c6f938c7f4700 RBX: 1ffffffff1a595fd RCX: ffff888034823c00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 00000000ffffffe9 R08: ffffffff81567052 R09: 1ffff920007c9f50 R10: dffffc0000000000 R11: fffff520007c9f51 R12: ffffffff8d2cafe8 R13: 1ffffffff1a595fe R14: ffffffff9a789c40 R15: ffff8880764298c0 FS: 000055557b518380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa62ff43225 CR3: 0000000031628000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: sock_create net/socket.c:1616 [inline] __sys_socket_create net/socket.c:1653 [inline] __sys_socket+0x150/0x3c0 net/socket.c:1700 __do_sys_socket net/socket.c:1714 [inline] __se_sys_socket net/socket.c:1712 [inline] For reference, see commit 2d859aff775d (\"Merge branch 'do-not-leave-dangling-sk-pointers-in-pf-create-functions'\")", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50294", "url": "https://ubuntu.com/security/CVE-2024-50294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix missing locking causing hanging calls If a call gets aborted (e.g. because kafs saw a signal) between it being queued for connection and the I/O thread picking up the call, the abort will be prioritised over the connection and it will be removed from local->new_client_calls by rxrpc_disconnect_client_call() without a lock being held. This may cause other calls on the list to disappear if a race occurs. Fix this by taking the client_call_lock when removing a call from whatever list its ->wait_link happens to be on.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50295", "url": "https://ubuntu.com/security/CVE-2024-50295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: arc: fix the device for dma_map_single/dma_unmap_single The ndev->dev and pdev->dev aren't the same device, use ndev->dev.parent which has dma_mask, ndev->dev.parent is just pdev->dev. Or it would cause the following issue: [ 39.933526] ------------[ cut here ]------------ [ 39.938414] WARNING: CPU: 1 PID: 501 at kernel/dma/mapping.c:149 dma_map_page_attrs+0x90/0x1f8", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53082", "url": "https://ubuntu.com/security/CVE-2024-53082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_net: Add hash_key_length check Add hash_key_length check in virtnet_probe() to avoid possible out of bound errors when setting/reading the hash key.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50296", "url": "https://ubuntu.com/security/CVE-2024-50296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash when uninstalling driver When the driver is uninstalled and the VF is disabled concurrently, a kernel crash occurs. The reason is that the two actions call function pci_disable_sriov(). The num_VFs is checked to determine whether to release the corresponding resources. During the second calling, num_VFs is not 0 and the resource release function is called. However, the corresponding resource has been released during the first invoking. Therefore, the problem occurs: [15277.839633][T50670] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ... [15278.131557][T50670] Call trace: [15278.134686][T50670] klist_put+0x28/0x12c [15278.138682][T50670] klist_del+0x14/0x20 [15278.142592][T50670] device_del+0xbc/0x3c0 [15278.146676][T50670] pci_remove_bus_device+0x84/0x120 [15278.151714][T50670] pci_stop_and_remove_bus_device+0x6c/0x80 [15278.157447][T50670] pci_iov_remove_virtfn+0xb4/0x12c [15278.162485][T50670] sriov_disable+0x50/0x11c [15278.166829][T50670] pci_disable_sriov+0x24/0x30 [15278.171433][T50670] hnae3_unregister_ae_algo_prepare+0x60/0x90 [hnae3] [15278.178039][T50670] hclge_exit+0x28/0xd0 [hclge] [15278.182730][T50670] __se_sys_delete_module.isra.0+0x164/0x230 [15278.188550][T50670] __arm64_sys_delete_module+0x1c/0x30 [15278.193848][T50670] invoke_syscall+0x50/0x11c [15278.198278][T50670] el0_svc_common.constprop.0+0x158/0x164 [15278.203837][T50670] do_el0_svc+0x34/0xcc [15278.207834][T50670] el0_svc+0x20/0x30 For details, see the following figure. rmmod hclge disable VFs ---------------------------------------------------- hclge_exit() sriov_numvfs_store() ... device_lock() pci_disable_sriov() hns3_pci_sriov_configure() pci_disable_sriov() sriov_disable() sriov_disable() if !num_VFs : if !num_VFs : return; return; sriov_del_vfs() sriov_del_vfs() ... ... klist_put() klist_put() ... ... num_VFs = 0; num_VFs = 0; device_unlock(); In this patch, when driver is removing, we get the device_lock() to protect num_VFs, just like sriov_numvfs_store().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53088", "url": "https://ubuntu.com/security/CVE-2024-53088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: fix race condition by adding filter's intermediate sync state Fix a race condition in the i40e driver that leads to MAC/VLAN filters becoming corrupted and leaking. Address the issue that occurs under heavy load when multiple threads are concurrently modifying MAC/VLAN filters by setting mac and port VLAN. 1. Thread T0 allocates a filter in i40e_add_filter() within i40e_ndo_set_vf_port_vlan(). 2. Thread T1 concurrently frees the filter in __i40e_del_filter() within i40e_ndo_set_vf_mac(). 3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which refers to the already freed filter memory, causing corruption. Reproduction steps: 1. Spawn multiple VFs. 2. Apply a concurrent heavy load by running parallel operations to change MAC addresses on the VFs and change port VLANs on the host. 3. Observe errors in dmesg: \"Error I40E_AQ_RC_ENOSPC adding RX filters on VF XX, \tplease set promiscuous on manually for VF XX\". Exact code for stable reproduction Intel can't open-source now. The fix involves implementing a new intermediate filter state, I40E_FILTER_NEW_SYNC, for the time when a filter is on a tmp_add_list. These filters cannot be deleted from the hash list directly but must be removed using the full process.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50297", "url": "https://ubuntu.com/security/CVE-2024-50297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: xilinx: axienet: Enqueue Tx packets in dql before dmaengine starts Enqueue packets in dql after dma engine starts causes race condition. Tx transfer starts once dma engine is started and may execute dql dequeue in completion before it gets queued. It results in following kernel crash while running iperf stress test: kernel BUG at lib/dynamic_queue_limits.c:99! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP pc : dql_completed+0x238/0x248 lr : dql_completed+0x3c/0x248 Call trace: dql_completed+0x238/0x248 axienet_dma_tx_cb+0xa0/0x170 xilinx_dma_do_tasklet+0xdc/0x290 tasklet_action_common+0xf8/0x11c tasklet_action+0x30/0x3c handle_softirqs+0xf8/0x230 Start dmaengine after enqueue in dql fixes the crash.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50298", "url": "https://ubuntu.com/security/CVE-2024-50298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: enetc: allocate vf_state during PF probes In the previous implementation, vf_state is allocated memory only when VF is enabled. However, net_device_ops::ndo_set_vf_mac() may be called before VF is enabled to configure the MAC address of VF. If this is the case, enetc_pf_set_vf_mac() will access vf_state, resulting in access to a null pointer. The simplified error log is as follows. root@ls1028ardb:~# ip link set eno0 vf 1 mac 00:0c:e7:66:77:89 [ 173.543315] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 [ 173.637254] pc : enetc_pf_set_vf_mac+0x3c/0x80 Message from sy [ 173.641973] lr : do_setlink+0x4a8/0xec8 [ 173.732292] Call trace: [ 173.734740] enetc_pf_set_vf_mac+0x3c/0x80 [ 173.738847] __rtnl_newlink+0x530/0x89c [ 173.742692] rtnl_newlink+0x50/0x7c [ 173.746189] rtnetlink_rcv_msg+0x128/0x390 [ 173.750298] netlink_rcv_skb+0x60/0x130 [ 173.754145] rtnetlink_rcv+0x18/0x24 [ 173.757731] netlink_unicast+0x318/0x380 [ 173.761665] netlink_sendmsg+0x17c/0x3c8", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50299", "url": "https://ubuntu.com/security/CVE-2024-50299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: properly validate chunk size in sctp_sf_ootb() A size validation fix similar to that in Commit 50619dbf8db7 (\"sctp: add size validation when walking chunks\") is also required in sctp_sf_ootb() to address a crash reported by syzbot: BUG: KMSAN: uninit-value in sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_do_sm+0x181/0x93d0 net/sctp/sm_sideeffect.c:1166 sctp_endpoint_bh_rcv+0xc38/0xf90 net/sctp/endpointola.c:407 sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88 sctp_rcv+0x3831/0x3b20 net/sctp/input.c:243 sctp4_rcv+0x42/0x50 net/sctp/protocol.c:1159 ip_protocol_deliver_rcu+0xb51/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50300", "url": "https://ubuntu.com/security/CVE-2024-50300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: rtq2208: Fix uninitialized use of regulator_config Fix rtq2208 driver uninitialized use to cause kernel error.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50301", "url": "https://ubuntu.com/security/CVE-2024-50301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: security/keys: fix slab-out-of-bounds in key_task_permission KASAN reports an out of bounds read: BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline] BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362 CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0x107/0x167 lib/dump_stack.c:123 print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 __kuid_val include/linux/uidgid.h:36 [inline] uid_eq include/linux/uidgid.h:63 [inline] key_task_permission+0x394/0x410 security/keys/permission.c:54 search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793 This issue was also reported by syzbot. It can be reproduced by following these steps(more details [1]): 1. Obtain more than 32 inputs that have similar hashes, which ends with the pattern '0xxxxxxxe6'. 2. Reboot and add the keys obtained in step 1. The reproducer demonstrates how this issue happened: 1. In the search_nested_keyrings function, when it iterates through the slots in a node(below tag ascend_to_node), if the slot pointer is meta and node->back_pointer != NULL(it means a root), it will proceed to descend_to_node. However, there is an exception. If node is the root, and one of the slots points to a shortcut, it will be treated as a keyring. 2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function. However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as ASSOC_ARRAY_PTR_SUBTYPE_MASK. 3. When 32 keys with the similar hashes are added to the tree, the ROOT has keys with hashes that are not similar (e.g. slot 0) and it splits NODE A without using a shortcut. When NODE A is filled with keys that all hashes are xxe6, the keys are similar, NODE A will split with a shortcut. Finally, it forms the tree as shown below, where slot 6 points to a shortcut. NODE A +------>+---+ ROOT | | 0 | xxe6 +---+ | +---+ xxxx | 0 | shortcut : : xxe6 +---+ | +---+ xxe6 : : | | | xxe6 +---+ | +---+ | 6 |---+ : : xxe6 +---+ +---+ xxe6 : : | f | xxe6 +---+ +---+ xxe6 | f | +---+ 4. As mentioned above, If a slot(slot 6) of the root points to a shortcut, it may be mistakenly transferred to a key*, leading to a read out-of-bounds read. To fix this issue, one should jump to descend_to_node if the ptr is a shortcut, regardless of whether the node is root or not. [1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/ [jarkko: tweaked the commit message a bit to have an appropriate closes tag.]", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53072", "url": "https://ubuntu.com/security/CVE-2024-53072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/pmc: Detect when STB is not available Loading the amd_pmc module as: amd_pmc enable_stb=1 ...can result in the following messages in the kernel ring buffer: amd_pmc AMDI0009:00: SMU cmd failed. err: 0xff ioremap on RAM at 0x0000000000000000 - 0x0000000000ffffff WARNING: CPU: 10 PID: 2151 at arch/x86/mm/ioremap.c:217 __ioremap_caller+0x2cd/0x340 Further debugging reveals that this occurs when the requests for S2D_PHYS_ADDR_LOW and S2D_PHYS_ADDR_HIGH return a value of 0, indicating that the STB is inaccessible. To prevent the ioremap warning and provide clarity to the user, handle the invalid address and display an error message.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50302", "url": "https://ubuntu.com/security/CVE-2024-50302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: zero-initialize the report buffer Since the report buffer is used by all kinds of drivers in various ways, let's zero-initialize it during allocation to make sure that it can't be ever used to leak kernel memory via specially-crafted report.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53068", "url": "https://ubuntu.com/security/CVE-2024-53068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix slab-use-after-free in scmi_bus_notifier() The scmi_dev->name is released prematurely in __scmi_device_destroy(), which causes slab-use-after-free when accessing scmi_dev->name in scmi_bus_notifier(). So move the release of scmi_dev->name to scmi_device_release() to avoid slab-use-after-free. | BUG: KASAN: slab-use-after-free in strncmp+0xe4/0xec | Read of size 1 at addr ffffff80a482bcc0 by task swapper/0/1 | | CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.6.38-debug #1 | Hardware name: Qualcomm Technologies, Inc. SA8775P Ride (DT) | Call trace: | dump_backtrace+0x94/0x114 | show_stack+0x18/0x24 | dump_stack_lvl+0x48/0x60 | print_report+0xf4/0x5b0 | kasan_report+0xa4/0xec | __asan_report_load1_noabort+0x20/0x2c | strncmp+0xe4/0xec | scmi_bus_notifier+0x5c/0x54c | notifier_call_chain+0xb4/0x31c | blocking_notifier_call_chain+0x68/0x9c | bus_notify+0x54/0x78 | device_del+0x1bc/0x840 | device_unregister+0x20/0xb4 | __scmi_device_destroy+0xac/0x280 | scmi_device_destroy+0x94/0xd0 | scmi_chan_setup+0x524/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20 | | Allocated by task 1: | kasan_save_stack+0x2c/0x54 | kasan_set_track+0x2c/0x40 | kasan_save_alloc_info+0x24/0x34 | __kasan_kmalloc+0xa0/0xb8 | __kmalloc_node_track_caller+0x6c/0x104 | kstrdup+0x48/0x84 | kstrdup_const+0x34/0x40 | __scmi_device_create.part.0+0x8c/0x408 | scmi_device_create+0x104/0x370 | scmi_chan_setup+0x2a0/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20 | | Freed by task 1: | kasan_save_stack+0x2c/0x54 | kasan_set_track+0x2c/0x40 | kasan_save_free_info+0x38/0x5c | __kasan_slab_free+0xe8/0x164 | __kmem_cache_free+0x11c/0x230 | kfree+0x70/0x130 | kfree_const+0x20/0x40 | __scmi_device_destroy+0x70/0x280 | scmi_device_destroy+0x94/0xd0 | scmi_chan_setup+0x524/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53069", "url": "https://ubuntu.com/security/CVE-2024-53069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: qcom: scm: fix a NULL-pointer dereference Some SCM calls can be invoked with __scm being NULL (the driver may not have been and will not be probed as there's no SCM entry in device-tree). Make sure we don't dereference a NULL pointer.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50212", "url": "https://ubuntu.com/security/CVE-2024-50212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib: alloc_tag_module_unload must wait for pending kfree_rcu calls Ben Greear reports following splat: ------------[ cut here ]------------ net/netfilter/nf_nat_core.c:1114 module nf_nat func:nf_nat_register_fn has 256 allocated at module unload WARNING: CPU: 1 PID: 10421 at lib/alloc_tag.c:168 alloc_tag_module_unload+0x22b/0x3f0 Modules linked in: nf_nat(-) btrfs ufs qnx4 hfsplus hfs minix vfat msdos fat ... Hardware name: Default string Default string/SKYBAY, BIOS 5.12 08/04/2020 RIP: 0010:alloc_tag_module_unload+0x22b/0x3f0 codetag_unload_module+0x19b/0x2a0 ? codetag_load_module+0x80/0x80 nf_nat module exit calls kfree_rcu on those addresses, but the free operation is likely still pending by the time alloc_tag checks for leaks. Wait for outstanding kfree_rcu operations to complete before checking resolves this warning. Reproducer: unshare -n iptables-nft -t nat -A PREROUTING -p tcp grep nf_nat /proc/allocinfo # will list 4 allocations rmmod nft_chain_nat rmmod nf_nat # will WARN. [akpm@linux-foundation.org: add comment]", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53046", "url": "https://ubuntu.com/security/CVE-2024-53046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: dts: imx8ulp: correct the flexspi compatible string The flexspi on imx8ulp only has 16 LUTs, and imx8mm flexspi has 32 LUTs, so correct the compatible string here, otherwise will meet below error: [ 1.119072] ------------[ cut here ]------------ [ 1.123926] WARNING: CPU: 0 PID: 1 at drivers/spi/spi-nxp-fspi.c:855 nxp_fspi_exec_op+0xb04/0xb64 [ 1.133239] Modules linked in: [ 1.136448] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-rc6-next-20240902-00001-g131bf9439dd9 #69 [ 1.146821] Hardware name: NXP i.MX8ULP EVK (DT) [ 1.151647] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.158931] pc : nxp_fspi_exec_op+0xb04/0xb64 [ 1.163496] lr : nxp_fspi_exec_op+0xa34/0xb64 [ 1.168060] sp : ffff80008002b2a0 [ 1.171526] x29: ffff80008002b2d0 x28: 0000000000000000 x27: 0000000000000000 [ 1.179002] x26: ffff2eb645542580 x25: ffff800080610014 x24: ffff800080610000 [ 1.186480] x23: ffff2eb645548080 x22: 0000000000000006 x21: ffff2eb6455425e0 [ 1.193956] x20: 0000000000000000 x19: ffff80008002b5e0 x18: ffffffffffffffff [ 1.201432] x17: ffff2eb644467508 x16: 0000000000000138 x15: 0000000000000002 [ 1.208907] x14: 0000000000000000 x13: ffff2eb6400d8080 x12: 00000000ffffff00 [ 1.216378] x11: 0000000000000000 x10: ffff2eb6400d8080 x9 : ffff2eb697adca80 [ 1.223850] x8 : ffff2eb697ad3cc0 x7 : 0000000100000000 x6 : 0000000000000001 [ 1.231324] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000007a6 [ 1.238795] x2 : 0000000000000000 x1 : 00000000000001ce x0 : 00000000ffffff92 [ 1.246267] Call trace: [ 1.248824] nxp_fspi_exec_op+0xb04/0xb64 [ 1.253031] spi_mem_exec_op+0x3a0/0x430 [ 1.257139] spi_nor_read_id+0x80/0xcc [ 1.261065] spi_nor_scan+0x1ec/0xf10 [ 1.264901] spi_nor_probe+0x108/0x2fc [ 1.268828] spi_mem_probe+0x6c/0xbc [ 1.272574] spi_probe+0x84/0xe4 [ 1.275958] really_probe+0xbc/0x29c [ 1.279713] __driver_probe_device+0x78/0x12c [ 1.284277] driver_probe_device+0xd8/0x15c [ 1.288660] __device_attach_driver+0xb8/0x134 [ 1.293316] bus_for_each_drv+0x88/0xe8 [ 1.297337] __device_attach+0xa0/0x190 [ 1.301353] device_initial_probe+0x14/0x20 [ 1.305734] bus_probe_device+0xac/0xb0 [ 1.309752] device_add+0x5d0/0x790 [ 1.313408] __spi_add_device+0x134/0x204 [ 1.317606] of_register_spi_device+0x3b4/0x590 [ 1.322348] spi_register_controller+0x47c/0x754 [ 1.327181] devm_spi_register_controller+0x4c/0xa4 [ 1.332289] nxp_fspi_probe+0x1cc/0x2b0 [ 1.336307] platform_probe+0x68/0xc4 [ 1.340145] really_probe+0xbc/0x29c [ 1.343893] __driver_probe_device+0x78/0x12c [ 1.348457] driver_probe_device+0xd8/0x15c [ 1.352838] __driver_attach+0x90/0x19c [ 1.356857] bus_for_each_dev+0x7c/0xdc [ 1.360877] driver_attach+0x24/0x30 [ 1.364624] bus_add_driver+0xe4/0x208 [ 1.368552] driver_register+0x5c/0x124 [ 1.372573] __platform_driver_register+0x28/0x34 [ 1.377497] nxp_fspi_driver_init+0x1c/0x28 [ 1.381888] do_one_initcall+0x80/0x1c8 [ 1.385908] kernel_init_freeable+0x1c4/0x28c [ 1.390472] kernel_init+0x20/0x1d8 [ 1.394138] ret_from_fork+0x10/0x20 [ 1.397885] ---[ end trace 0000000000000000 ]--- [ 1.407908] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53052", "url": "https://ubuntu.com/security/CVE-2024-53052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/rw: fix missing NOWAIT check for O_DIRECT start write When io_uring starts a write, it'll call kiocb_start_write() to bump the super block rwsem, preventing any freezes from happening while that write is in-flight. The freeze side will grab that rwsem for writing, excluding any new writers from happening and waiting for existing writes to finish. But io_uring unconditionally uses kiocb_start_write(), which will block if someone is currently attempting to freeze the mount point. This causes a deadlock where freeze is waiting for previous writes to complete, but the previous writes cannot complete, as the task that is supposed to complete them is blocked waiting on starting a new write. This results in the following stuck trace showing that dependency with the write blocked starting a new write: task:fio state:D stack:0 pid:886 tgid:886 ppid:876 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_rwsem_wait+0x1e8/0x3f8 __percpu_down_read+0xe8/0x500 io_write+0xbb8/0xff8 io_issue_sqe+0x10c/0x1020 io_submit_sqes+0x614/0x2110 __arm64_sys_io_uring_enter+0x524/0x1038 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 INFO: task fsfreeze:7364 blocked for more than 15 seconds. Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963 with the attempting freezer stuck trying to grab the rwsem: task:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_down_write+0x2b0/0x680 freeze_super+0x248/0x8a8 do_vfs_ioctl+0x149c/0x1b18 __arm64_sys_ioctl+0xd0/0x1a0 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 Fix this by having the io_uring side honor IOCB_NOWAIT, and only attempt a blocking grab of the super block rwsem if it isn't set. For normal issue where IOCB_NOWAIT would always be set, this returns -EAGAIN which will have io_uring core issue a blocking attempt of the write. That will in turn also get completions run, ensuring forward progress. Since freezing requires CAP_SYS_ADMIN in the first place, this isn't something that can be triggered by a regular user.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50213", "url": "https://ubuntu.com/security/CVE-2024-50213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tests: hdmi: Fix memory leaks in drm_display_mode_from_cea_vic() modprobe drm_hdmi_state_helper_test and then rmmod it, the following memory leak occurs. The `mode` allocated in drm_mode_duplicate() called by drm_display_mode_from_cea_vic() is not freed, which cause the memory leak: \tunreferenced object 0xffffff80ccd18100 (size 128): \t comm \"kunit_try_catch\", pid 1851, jiffies 4295059695 \t hex dump (first 32 bytes): \t 57 62 00 00 80 02 90 02 f0 02 20 03 00 00 e0 01 Wb........ ..... \t ea 01 ec 01 0d 02 00 00 0a 00 00 00 00 00 00 00 ................ \t backtrace (crc c2f1aa95): \t [<000000000f10b11b>] kmemleak_alloc+0x34/0x40 \t [<000000001cd4cf73>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<00000000f1f3cffa>] drm_mode_duplicate+0x44/0x19c \t [<000000008cbeef13>] drm_display_mode_from_cea_vic+0x88/0x98 \t [<0000000019daaacf>] 0xffffffedc11ae69c \t [<000000000aad0f85>] kunit_try_run_case+0x13c/0x3ac \t [<00000000a9210bac>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<000000000a0b2e9e>] kthread+0x2e8/0x374 \t [<00000000bd668858>] ret_from_fork+0x10/0x20 \t...... Free `mode` by using drm_kunit_display_mode_from_cea_vic() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50214", "url": "https://ubuntu.com/security/CVE-2024-50214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/connector: hdmi: Fix memory leak in drm_display_mode_from_cea_vic() modprobe drm_connector_test and then rmmod drm_connector_test, the following memory leak occurs. The `mode` allocated in drm_mode_duplicate() called by drm_display_mode_from_cea_vic() is not freed, which cause the memory leak: \tunreferenced object 0xffffff80cb0ee400 (size 128): \t comm \"kunit_try_catch\", pid 1948, jiffies 4294950339 \t hex dump (first 32 bytes): \t 14 44 02 00 80 07 d8 07 04 08 98 08 00 00 38 04 .D............8. \t 3c 04 41 04 65 04 00 00 05 00 00 00 00 00 00 00 <.A.e........... \t backtrace (crc 90e9585c): \t [<00000000ec42e3d7>] kmemleak_alloc+0x34/0x40 \t [<00000000d0ef055a>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<00000000c2062161>] drm_mode_duplicate+0x44/0x19c \t [<00000000f96c74aa>] drm_display_mode_from_cea_vic+0x88/0x98 \t [<00000000d8f2c8b4>] 0xffffffdc982a4868 \t [<000000005d164dbc>] kunit_try_run_case+0x13c/0x3ac \t [<000000006fb23398>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<000000006ea56ca0>] kthread+0x2e8/0x374 \t [<000000000676063f>] ret_from_fork+0x10/0x20 \t...... Free `mode` by using drm_kunit_display_mode_from_cea_vic() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50215", "url": "https://ubuntu.com/security/CVE-2024-50215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: assign dh_key to NULL after kfree_sensitive ctrl->dh_key might be used across multiple calls to nvmet_setup_dhgroup() for the same controller. So it's better to nullify it after release on error path in order to avoid double free later in nvmet_destroy_auth(). Found by Linux Verification Center (linuxtesting.org) with Svace.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50216", "url": "https://ubuntu.com/security/CVE-2024-50216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix finding a last resort AG in xfs_filestream_pick_ag When the main loop in xfs_filestream_pick_ag fails to find a suitable AG it tries to just pick the online AG. But the loop for that uses args->pag as loop iterator while the later code expects pag to be set. Fix this by reusing the max_pag case for this last resort, and also add a check for impossible case of no AG just to make sure that the uninitialized pag doesn't even escape in theory.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50217", "url": "https://ubuntu.com/security/CVE-2024-50217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free of block device file in __btrfs_free_extra_devids() Mounting btrfs from two images (which have the same one fsid and two different dev_uuids) in certain executing order may trigger an UAF for variable 'device->bdev_file' in __btrfs_free_extra_devids(). And following are the details: 1. Attach image_1 to loop0, attach image_2 to loop1, and scan btrfs devices by ioctl(BTRFS_IOC_SCAN_DEV): / btrfs_device_1 ? loop0 fs_device \\ btrfs_device_2 ? loop1 2. mount /dev/loop0 /mnt btrfs_open_devices btrfs_device_1->bdev_file = btrfs_get_bdev_and_sb(loop0) btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree fail: btrfs_close_devices // -ENOMEM \t btrfs_close_bdev(btrfs_device_1) fput(btrfs_device_1->bdev_file) \t // btrfs_device_1->bdev_file is freed \t btrfs_close_bdev(btrfs_device_2) fput(btrfs_device_2->bdev_file) 3. mount /dev/loop1 /mnt btrfs_open_devices btrfs_get_bdev_and_sb(&bdev_file) // EIO, btrfs_device_1->bdev_file is not assigned, // which points to a freed memory area btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree btrfs_free_extra_devids if (btrfs_device_1->bdev_file) fput(btrfs_device_1->bdev_file) // UAF ! Fix it by setting 'device->bdev_file' as 'NULL' after closing the btrfs_device in btrfs_close_one_device().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53043", "url": "https://ubuntu.com/security/CVE-2024-53043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mctp i2c: handle NULL header address daddr can be NULL if there is no neighbour table entry present, in that case the tx packet should be dropped. saddr will usually be set by MCTP core, but check for NULL in case a packet is transmitted by a different protocol.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50303", "url": "https://ubuntu.com/security/CVE-2024-50303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: resource,kexec: walk_system_ram_res_rev must retain resource flags walk_system_ram_res_rev() erroneously discards resource flags when passing the information to the callback. This causes systems with IORESOURCE_SYSRAM_DRIVER_MANAGED memory to have these resources selected during kexec to store kexec buffers if that memory happens to be at placed above normal system ram. This leads to undefined behavior after reboot. If the kexec buffer is never touched, nothing happens. If the kexec buffer is touched, it could lead to a crash (like below) or undefined behavior. Tested on a system with CXL memory expanders with driver managed memory, TPM enabled, and CONFIG_IMA_KEXEC=y. Adding printk's showed the flags were being discarded and as a result the check for IORESOURCE_SYSRAM_DRIVER_MANAGED passes. find_next_iomem_res: name(System RAM (kmem)) \t\t start(10000000000) \t\t end(1034fffffff) \t\t flags(83000200) locate_mem_hole_top_down: start(10000000000) end(1034fffffff) flags(0) [.] BUG: unable to handle page fault for address: ffff89834ffff000 [.] #PF: supervisor read access in kernel mode [.] #PF: error_code(0x0000) - not-present page [.] PGD c04c8bf067 P4D c04c8bf067 PUD c04c8be067 PMD 0 [.] Oops: 0000 [#1] SMP [.] RIP: 0010:ima_restore_measurement_list+0x95/0x4b0 [.] RSP: 0018:ffffc900000d3a80 EFLAGS: 00010286 [.] RAX: 0000000000001000 RBX: 0000000000000000 RCX: ffff89834ffff000 [.] RDX: 0000000000000018 RSI: ffff89834ffff000 RDI: ffff89834ffff018 [.] RBP: ffffc900000d3ba0 R08: 0000000000000020 R09: ffff888132b8a900 [.] R10: 4000000000000000 R11: 000000003a616d69 R12: 0000000000000000 [.] R13: ffffffff8404ac28 R14: 0000000000000000 R15: ffff89834ffff000 [.] FS: 0000000000000000(0000) GS:ffff893d44640000(0000) knlGS:0000000000000000 [.] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [.] ata5: SATA link down (SStatus 0 SControl 300) [.] CR2: ffff89834ffff000 CR3: 000001034d00f001 CR4: 0000000000770ef0 [.] PKRU: 55555554 [.] Call Trace: [.] [.] ? __die+0x78/0xc0 [.] ? page_fault_oops+0x2a8/0x3a0 [.] ? exc_page_fault+0x84/0x130 [.] ? asm_exc_page_fault+0x22/0x30 [.] ? ima_restore_measurement_list+0x95/0x4b0 [.] ? template_desc_init_fields+0x317/0x410 [.] ? crypto_alloc_tfm_node+0x9c/0xc0 [.] ? init_ima_lsm+0x30/0x30 [.] ima_load_kexec_buffer+0x72/0xa0 [.] ima_init+0x44/0xa0 [.] __initstub__kmod_ima__373_1201_init_ima7+0x1e/0xb0 [.] ? init_ima_lsm+0x30/0x30 [.] do_one_initcall+0xad/0x200 [.] ? idr_alloc_cyclic+0xaa/0x110 [.] ? new_slab+0x12c/0x420 [.] ? new_slab+0x12c/0x420 [.] ? number+0x12a/0x430 [.] ? sysvec_apic_timer_interrupt+0xa/0x80 [.] ? asm_sysvec_apic_timer_interrupt+0x16/0x20 [.] ? parse_args+0xd4/0x380 [.] ? parse_args+0x14b/0x380 [.] kernel_init_freeable+0x1c1/0x2b0 [.] ? rest_init+0xb0/0xb0 [.] kernel_init+0x16/0x1a0 [.] ret_from_fork+0x2f/0x40 [.] ? rest_init+0xb0/0xb0 [.] ret_from_fork_asm+0x11/0x20 [.] ", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50218", "url": "https://ubuntu.com/security/CVE-2024-50218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow Syzbot reported a kernel BUG in ocfs2_truncate_inline. There are two reasons for this: first, the parameter value passed is greater than ocfs2_max_inline_data_with_xattr, second, the start and end parameters of ocfs2_truncate_inline are \"unsigned int\". So, we need to add a sanity check for byte_start and byte_len right before ocfs2_truncate_inline() in ocfs2_remove_inode_range(), if they are greater than ocfs2_max_inline_data_with_xattr return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50219", "url": "https://ubuntu.com/security/CVE-2024-50219", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50263", "url": "https://ubuntu.com/security/CVE-2024-50263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fork: only invoke khugepaged, ksm hooks if no error There is no reason to invoke these hooks early against an mm that is in an incomplete state. The change in commit d24062914837 (\"fork: use __mt_dup() to duplicate maple tree in dup_mmap()\") makes this more pertinent as we may be in a state where entries in the maple tree are not yet consistent. Their placement early in dup_mmap() only appears to have been meaningful for early error checking, and since functionally it'd require a very small allocation to fail (in practice 'too small to fail') that'd only occur in the most dire circumstances, meaning the fork would fail or be OOM'd in any case. Since both khugepaged and KSM tracking are there to provide optimisations to memory performance rather than critical functionality, it doesn't really matter all that much if, under such dire memory pressure, we fail to register an mm with these. As a result, we follow the example of commit d2081b2bf819 (\"mm: khugepaged: make khugepaged_enter() void function\") and make ksm_fork() a void function also. We only expose the mm to these functions once we are done with them and only if no error occurred in the fork operation.", "cve_priority": "medium", "cve_public_date": "2024-11-11 14:15:00 UTC" }, { "cve": "CVE-2024-50220", "url": "https://ubuntu.com/security/CVE-2024-50220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fork: do not invoke uffd on fork if error occurs Patch series \"fork: do not expose incomplete mm on fork\". During fork we may place the virtual memory address space into an inconsistent state before the fork operation is complete. In addition, we may encounter an error during the fork operation that indicates that the virtual memory address space is invalidated. As a result, we should not be exposing it in any way to external machinery that might interact with the mm or VMAs, machinery that is not designed to deal with incomplete state. We specifically update the fork logic to defer khugepaged and ksm to the end of the operation and only to be invoked if no error arose, and disallow uffd from observing fork events should an error have occurred. This patch (of 2): Currently on fork we expose the virtual address space of a process to userland unconditionally if uffd is registered in VMAs, regardless of whether an error arose in the fork. This is performed in dup_userfaultfd_complete() which is invoked unconditionally, and performs two duties - invoking registered handlers for the UFFD_EVENT_FORK event via dup_fctx(), and clearing down userfaultfd_fork_ctx objects established in dup_userfaultfd(). This is problematic, because the virtual address space may not yet be correctly initialised if an error arose. The change in commit d24062914837 (\"fork: use __mt_dup() to duplicate maple tree in dup_mmap()\") makes this more pertinent as we may be in a state where entries in the maple tree are not yet consistent. We address this by, on fork error, ensuring that we roll back state that we would otherwise expect to clean up through the event being handled by userland and perform the memory freeing duty otherwise performed by dup_userfaultfd_complete(). We do this by implementing a new function, dup_userfaultfd_fail(), which performs the same loop, only decrementing reference counts. Note that we perform mmgrab() on the parent and child mm's, however userfaultfd_ctx_put() will mmdrop() this once the reference count drops to zero, so we will avoid memory leaks correctly here.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53047", "url": "https://ubuntu.com/security/CVE-2024-53047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: init: protect sched with rcu_read_lock Enabling CONFIG_PROVE_RCU_LIST with its dependence CONFIG_RCU_EXPERT creates this splat when an MPTCP socket is created: ============================= WARNING: suspicious RCU usage 6.12.0-rc2+ #11 Not tainted ----------------------------- net/mptcp/sched.c:44 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 no locks held by mptcp_connect/176. stack backtrace: CPU: 0 UID: 0 PID: 176 Comm: mptcp_connect Not tainted 6.12.0-rc2+ #11 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl (lib/dump_stack.c:123) lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822) mptcp_sched_find (net/mptcp/sched.c:44 (discriminator 7)) mptcp_init_sock (net/mptcp/protocol.c:2867 (discriminator 1)) ? sock_init_data_uid (arch/x86/include/asm/atomic.h:28) inet_create.part.0.constprop.0 (net/ipv4/af_inet.c:386) ? __sock_create (include/linux/rcupdate.h:347 (discriminator 1)) __sock_create (net/socket.c:1576) __sys_socket (net/socket.c:1671) ? __pfx___sys_socket (net/socket.c:1712) ? do_user_addr_fault (arch/x86/mm/fault.c:1419 (discriminator 1)) __x64_sys_socket (net/socket.c:1728) do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) That's because when the socket is initialised, rcu_read_lock() is not used despite the explicit comment written above the declaration of mptcp_sched_find() in sched.c. Adding the missing lock/unlock avoids the warning.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50221", "url": "https://ubuntu.com/security/CVE-2024-50221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Vangogh: Fix kernel memory out of bounds write KASAN reports that the GPU metrics table allocated in vangogh_tables_init() is not large enough for the memset done in smu_cmn_init_soft_gpu_metrics(). Condensed report follows: [ 33.861314] BUG: KASAN: slab-out-of-bounds in smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu] [ 33.861799] Write of size 168 at addr ffff888129f59500 by task mangoapp/1067 ... [ 33.861808] CPU: 6 UID: 1000 PID: 1067 Comm: mangoapp Tainted: G W 6.12.0-rc4 #356 1a56f59a8b5182eeaf67eb7cb8b13594dd23b544 [ 33.861816] Tainted: [W]=WARN [ 33.861818] Hardware name: Valve Galileo/Galileo, BIOS F7G0107 12/01/2023 [ 33.861822] Call Trace: [ 33.861826] [ 33.861829] dump_stack_lvl+0x66/0x90 [ 33.861838] print_report+0xce/0x620 [ 33.861853] kasan_report+0xda/0x110 [ 33.862794] kasan_check_range+0xfd/0x1a0 [ 33.862799] __asan_memset+0x23/0x40 [ 33.862803] smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.863306] vangogh_get_gpu_metrics_v2_4+0x123/0xad0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.864257] vangogh_common_get_gpu_metrics+0xb0c/0xbc0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.865682] amdgpu_dpm_get_gpu_metrics+0xcc/0x110 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.866160] amdgpu_get_gpu_metrics+0x154/0x2d0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.867135] dev_attr_show+0x43/0xc0 [ 33.867147] sysfs_kf_seq_show+0x1f1/0x3b0 [ 33.867155] seq_read_iter+0x3f8/0x1140 [ 33.867173] vfs_read+0x76c/0xc50 [ 33.867198] ksys_read+0xfb/0x1d0 [ 33.867214] do_syscall_64+0x90/0x160 ... [ 33.867353] Allocated by task 378 on cpu 7 at 22.794876s: [ 33.867358] kasan_save_stack+0x33/0x50 [ 33.867364] kasan_save_track+0x17/0x60 [ 33.867367] __kasan_kmalloc+0x87/0x90 [ 33.867371] vangogh_init_smc_tables+0x3f9/0x840 [amdgpu] [ 33.867835] smu_sw_init+0xa32/0x1850 [amdgpu] [ 33.868299] amdgpu_device_init+0x467b/0x8d90 [amdgpu] [ 33.868733] amdgpu_driver_load_kms+0x19/0xf0 [amdgpu] [ 33.869167] amdgpu_pci_probe+0x2d6/0xcd0 [amdgpu] [ 33.869608] local_pci_probe+0xda/0x180 [ 33.869614] pci_device_probe+0x43f/0x6b0 Empirically we can confirm that the former allocates 152 bytes for the table, while the latter memsets the 168 large block. Root cause appears that when GPU metrics tables for v2_4 parts were added it was not considered to enlarge the table to fit. The fix in this patch is rather \"brute force\" and perhaps later should be done in a smarter way, by extracting and consolidating the part version to size logic to a common helper, instead of brute forcing the largest possible allocation. Nevertheless, for now this works and fixes the out of bounds write. v2: * Drop impossible v3_0 case. (Mario) (cherry picked from commit 0880f58f9609f0200483a49429af0f050d281703)", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50222", "url": "https://ubuntu.com/security/CVE-2024-50222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iov_iter: fix copy_page_from_iter_atomic() if KMAP_LOCAL_FORCE_MAP generic/077 on x86_32 CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP=y with highmem, on huge=always tmpfs, issues a warning and then hangs (interruptibly): WARNING: CPU: 5 PID: 3517 at mm/highmem.c:622 kunmap_local_indexed+0x62/0xc9 CPU: 5 UID: 0 PID: 3517 Comm: cp Not tainted 6.12.0-rc4 #2 ... copy_page_from_iter_atomic+0xa6/0x5ec generic_perform_write+0xf6/0x1b4 shmem_file_write_iter+0x54/0x67 Fix copy_page_from_iter_atomic() by limiting it in that case (include/linux/skbuff.h skb_frag_must_loop() does similar). But going forward, perhaps CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP is too surprising, has outlived its usefulness, and should just be removed?", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50223", "url": "https://ubuntu.com/security/CVE-2024-50223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/numa: Fix the potential null pointer dereference in task_numa_work() When running stress-ng-vm-segv test, we found a null pointer dereference error in task_numa_work(). Here is the backtrace: [323676.066985] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ...... [323676.067108] CPU: 35 PID: 2694524 Comm: stress-ng-vm-se ...... [323676.067113] pstate: 23401009 (nzCv daif +PAN -UAO +TCO +DIT +SSBS BTYPE=--) [323676.067115] pc : vma_migratable+0x1c/0xd0 [323676.067122] lr : task_numa_work+0x1ec/0x4e0 [323676.067127] sp : ffff8000ada73d20 [323676.067128] x29: ffff8000ada73d20 x28: 0000000000000000 x27: 000000003e89f010 [323676.067130] x26: 0000000000080000 x25: ffff800081b5c0d8 x24: ffff800081b27000 [323676.067133] x23: 0000000000010000 x22: 0000000104d18cc0 x21: ffff0009f7158000 [323676.067135] x20: 0000000000000000 x19: 0000000000000000 x18: ffff8000ada73db8 [323676.067138] x17: 0001400000000000 x16: ffff800080df40b0 x15: 0000000000000035 [323676.067140] x14: ffff8000ada73cc8 x13: 1fffe0017cc72001 x12: ffff8000ada73cc8 [323676.067142] x11: ffff80008001160c x10: ffff000be639000c x9 : ffff8000800f4ba4 [323676.067145] x8 : ffff000810375000 x7 : ffff8000ada73974 x6 : 0000000000000001 [323676.067147] x5 : 0068000b33e26707 x4 : 0000000000000001 x3 : ffff0009f7158000 [323676.067149] x2 : 0000000000000041 x1 : 0000000000004400 x0 : 0000000000000000 [323676.067152] Call trace: [323676.067153] vma_migratable+0x1c/0xd0 [323676.067155] task_numa_work+0x1ec/0x4e0 [323676.067157] task_work_run+0x78/0xd8 [323676.067161] do_notify_resume+0x1ec/0x290 [323676.067163] el0_svc+0x150/0x160 [323676.067167] el0t_64_sync_handler+0xf8/0x128 [323676.067170] el0t_64_sync+0x17c/0x180 [323676.067173] Code: d2888001 910003fd f9000bf3 aa0003f3 (f9401000) [323676.067177] SMP: stopping secondary CPUs [323676.070184] Starting crashdump kernel... stress-ng-vm-segv in stress-ng is used to stress test the SIGSEGV error handling function of the system, which tries to cause a SIGSEGV error on return from unmapping the whole address space of the child process. Normally this program will not cause kernel crashes. But before the munmap system call returns to user mode, a potential task_numa_work() for numa balancing could be added and executed. In this scenario, since the child process has no vma after munmap, the vma_next() in task_numa_work() will return a null pointer even if the vma iterator restarts from 0. Recheck the vma pointer before dereferencing it in task_numa_work().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53053", "url": "https://ubuntu.com/security/CVE-2024-53053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Fix another deadlock during RTC update If ufshcd_rtc_work calls ufshcd_rpm_put_sync() and the pm's usage_count is 0, we will enter the runtime suspend callback. However, the runtime suspend callback will wait to flush ufshcd_rtc_work, causing a deadlock. Replace ufshcd_rpm_put_sync() with ufshcd_rpm_put() to avoid the deadlock.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53075", "url": "https://ubuntu.com/security/CVE-2024-53075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv: Prevent a bad reference count on CPU nodes When populating cache leaves we previously fetched the CPU device node at the very beginning. But when ACPI is enabled we go through a specific branch which returns early and does not call 'of_node_put' for the node that was acquired. Since we are not using a CPU device node for the ACPI code anyways, we can simply move the initialization of it just passed the ACPI block, and we are guaranteed to have an 'of_node_put' call for the acquired node. This prevents a bad reference count of the CPU device node. Moreover, the previous function did not check for errors when acquiring the device node, so a return -ENOENT has been added for that case.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50224", "url": "https://ubuntu.com/security/CVE-2024-50224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: spi-fsl-dspi: Fix crash when not using GPIO chip select Add check for the return value of spi_get_csgpiod() to avoid passing a NULL pointer to gpiod_direction_output(), preventing a crash when GPIO chip select is not used. Fix below crash: [ 4.251960] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 4.260762] Mem abort info: [ 4.263556] ESR = 0x0000000096000004 [ 4.267308] EC = 0x25: DABT (current EL), IL = 32 bits [ 4.272624] SET = 0, FnV = 0 [ 4.275681] EA = 0, S1PTW = 0 [ 4.278822] FSC = 0x04: level 0 translation fault [ 4.283704] Data abort info: [ 4.286583] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 4.292074] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 4.297130] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 4.302445] [0000000000000000] user address but active_mm is swapper [ 4.308805] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 4.315072] Modules linked in: [ 4.318124] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc4-next-20241023-00008-ga20ec42c5fc1 #359 [ 4.328130] Hardware name: LS1046A QDS Board (DT) [ 4.332832] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 4.339794] pc : gpiod_direction_output+0x34/0x5c [ 4.344505] lr : gpiod_direction_output+0x18/0x5c [ 4.349208] sp : ffff80008003b8f0 [ 4.352517] x29: ffff80008003b8f0 x28: 0000000000000000 x27: ffffc96bcc7e9068 [ 4.359659] x26: ffffc96bcc6e00b0 x25: ffffc96bcc598398 x24: ffff447400132810 [ 4.366800] x23: 0000000000000000 x22: 0000000011e1a300 x21: 0000000000020002 [ 4.373940] x20: 0000000000000000 x19: 0000000000000000 x18: ffffffffffffffff [ 4.381081] x17: ffff44740016e600 x16: 0000000500000003 x15: 0000000000000007 [ 4.388221] x14: 0000000000989680 x13: 0000000000020000 x12: 000000000000001e [ 4.395362] x11: 0044b82fa09b5a53 x10: 0000000000000019 x9 : 0000000000000008 [ 4.402502] x8 : 0000000000000002 x7 : 0000000000000007 x6 : 0000000000000000 [ 4.409641] x5 : 0000000000000200 x4 : 0000000002000000 x3 : 0000000000000000 [ 4.416781] x2 : 0000000000022202 x1 : 0000000000000000 x0 : 0000000000000000 [ 4.423921] Call trace: [ 4.426362] gpiod_direction_output+0x34/0x5c (P) [ 4.431067] gpiod_direction_output+0x18/0x5c (L) [ 4.435771] dspi_setup+0x220/0x334", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50225", "url": "https://ubuntu.com/security/CVE-2024-50225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix error propagation of split bios The purpose of btrfs_bbio_propagate_error() shall be propagating an error of split bio to its original btrfs_bio, and tell the error to the upper layer. However, it's not working well on some cases. * Case 1. Immediate (or quick) end_bio with an error When btrfs sends btrfs_bio to mirrored devices, btrfs calls btrfs_bio_end_io() when all the mirroring bios are completed. If that btrfs_bio was split, it is from btrfs_clone_bioset and its end_io function is btrfs_orig_write_end_io. For this case, btrfs_bbio_propagate_error() accesses the orig_bbio's bio context to increase the error count. That works well in most cases. However, if the end_io is called enough fast, orig_bbio's (remaining part after split) bio context may not be properly set at that time. Since the bio context is set when the orig_bbio (the last btrfs_bio) is sent to devices, that might be too late for earlier split btrfs_bio's completion. That will result in NULL pointer dereference. That bug is easily reproducible by running btrfs/146 on zoned devices [1] and it shows the following trace. [1] You need raid-stripe-tree feature as it create \"-d raid0 -m raid1\" FS. BUG: kernel NULL pointer dereference, address: 0000000000000020 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 UID: 0 PID: 13 Comm: kworker/u32:1 Not tainted 6.11.0-rc7-BTRFS-ZNS+ #474 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Workqueue: writeback wb_workfn (flush-btrfs-5) RIP: 0010:btrfs_bio_end_io+0xae/0xc0 [btrfs] BTRFS error (device dm-0): bdev /dev/mapper/error-test errs: wr 2, rd 0, flush 0, corrupt 0, gen 0 RSP: 0018:ffffc9000006f248 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888005a7f080 RCX: ffffc9000006f1dc RDX: 0000000000000000 RSI: 000000000000000a RDI: ffff888005a7f080 RBP: ffff888011dfc540 R08: 0000000000000000 R09: 0000000000000001 R10: ffffffff82e508e0 R11: 0000000000000005 R12: ffff88800ddfbe58 R13: ffff888005a7f080 R14: ffff888005a7f158 R15: ffff888005a7f158 FS: 0000000000000000(0000) GS:ffff88803ea80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000020 CR3: 0000000002e22006 CR4: 0000000000370ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __die_body.cold+0x19/0x26 ? page_fault_oops+0x13e/0x2b0 ? _printk+0x58/0x73 ? do_user_addr_fault+0x5f/0x750 ? exc_page_fault+0x76/0x240 ? asm_exc_page_fault+0x22/0x30 ? btrfs_bio_end_io+0xae/0xc0 [btrfs] ? btrfs_log_dev_io_error+0x7f/0x90 [btrfs] btrfs_orig_write_end_io+0x51/0x90 [btrfs] dm_submit_bio+0x5c2/0xa50 [dm_mod] ? find_held_lock+0x2b/0x80 ? blk_try_enter_queue+0x90/0x1e0 __submit_bio+0xe0/0x130 ? ktime_get+0x10a/0x160 ? lockdep_hardirqs_on+0x74/0x100 submit_bio_noacct_nocheck+0x199/0x410 btrfs_submit_bio+0x7d/0x150 [btrfs] btrfs_submit_chunk+0x1a1/0x6d0 [btrfs] ? lockdep_hardirqs_on+0x74/0x100 ? __folio_start_writeback+0x10/0x2c0 btrfs_submit_bbio+0x1c/0x40 [btrfs] submit_one_bio+0x44/0x60 [btrfs] submit_extent_folio+0x13f/0x330 [btrfs] ? btrfs_set_range_writeback+0xa3/0xd0 [btrfs] extent_writepage_io+0x18b/0x360 [btrfs] extent_write_locked_range+0x17c/0x340 [btrfs] ? __pfx_end_bbio_data_write+0x10/0x10 [btrfs] run_delalloc_cow+0x71/0xd0 [btrfs] btrfs_run_delalloc_range+0x176/0x500 [btrfs] ? find_lock_delalloc_range+0x119/0x260 [btrfs] writepage_delalloc+0x2ab/0x480 [btrfs] extent_write_cache_pages+0x236/0x7d0 [btrfs] btrfs_writepages+0x72/0x130 [btrfs] do_writepages+0xd4/0x240 ? find_held_lock+0x2b/0x80 ? wbc_attach_and_unlock_inode+0x12c/0x290 ? wbc_attach_and_unlock_inode+0x12c/0x29 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53054", "url": "https://ubuntu.com/security/CVE-2024-53054", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50226", "url": "https://ubuntu.com/security/CVE-2024-50226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cxl/port: Fix use-after-free, permit out-of-order decoder shutdown In support of investigating an initialization failure report [1], cxl_test was updated to register mock memory-devices after the mock root-port/bus device had been registered. That led to cxl_test crashing with a use-after-free bug with the following signature: cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem0:decoder7.0 @ 0 next: cxl_switch_uport.0 nr_eps: 1 nr_targets: 1 cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem4:decoder14.0 @ 1 next: cxl_switch_uport.0 nr_eps: 2 nr_targets: 1 cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[0] = cxl_switch_dport.0 for mem0:decoder7.0 @ 0 1) cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[1] = cxl_switch_dport.4 for mem4:decoder14.0 @ 1 [..] cxld_unregister: cxl decoder14.0: cxl_region_decode_reset: cxl_region region3: mock_decoder_reset: cxl_port port3: decoder3.0 reset 2) mock_decoder_reset: cxl_port port3: decoder3.0: out of order reset, expected decoder3.1 cxl_endpoint_decoder_release: cxl decoder14.0: [..] cxld_unregister: cxl decoder7.0: 3) cxl_region_decode_reset: cxl_region region3: Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6bc3: 0000 [#1] PREEMPT SMP PTI [..] RIP: 0010:to_cxl_port+0x8/0x60 [cxl_core] [..] Call Trace: cxl_region_decode_reset+0x69/0x190 [cxl_core] cxl_region_detach+0xe8/0x210 [cxl_core] cxl_decoder_kill_region+0x27/0x40 [cxl_core] cxld_unregister+0x5d/0x60 [cxl_core] At 1) a region has been established with 2 endpoint decoders (7.0 and 14.0). Those endpoints share a common switch-decoder in the topology (3.0). At teardown, 2), decoder14.0 is the first to be removed and hits the \"out of order reset case\" in the switch decoder. The effect though is that region3 cleanup is aborted leaving it in-tact and referencing decoder14.0. At 3) the second attempt to teardown region3 trips over the stale decoder14.0 object which has long since been deleted. The fix here is to recognize that the CXL specification places no mandate on in-order shutdown of switch-decoders, the driver enforces in-order allocation, and hardware enforces in-order commit. So, rather than fail and leave objects dangling, always remove them. In support of making cxl_region_decode_reset() always succeed, cxl_region_invalidate_memregion() failures are turned into warnings. Crashing the kernel is ok there since system integrity is at risk if caches cannot be managed around physical address mutation events like CXL region destruction. A new device_for_each_child_reverse_from() is added to cleanup port->commit_end after all dependent decoders have been disabled. In other words if decoders are allocated 0->1->2 and disabled 1->2->0 then port->commit_end only decrements from 2 after 2 has been disabled, and it decrements all the way to zero since 1 was disabled previously.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50227", "url": "https://ubuntu.com/security/CVE-2024-50227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Fix KASAN reported stack out-of-bounds read in tb_retimer_scan() KASAN reported following issue: BUG: KASAN: stack-out-of-bounds in tb_retimer_scan+0xffe/0x1550 [thunderbolt] Read of size 4 at addr ffff88810111fc1c by task kworker/u56:0/11 CPU: 0 UID: 0 PID: 11 Comm: kworker/u56:0 Tainted: G U 6.11.0+ #1387 Tainted: [U]=USER Workqueue: thunderbolt0 tb_handle_hotplug [thunderbolt] Call Trace: dump_stack_lvl+0x6c/0x90 print_report+0xd1/0x630 kasan_report+0xdb/0x110 __asan_report_load4_noabort+0x14/0x20 tb_retimer_scan+0xffe/0x1550 [thunderbolt] tb_scan_port+0xa6f/0x2060 [thunderbolt] tb_handle_hotplug+0x17b1/0x3080 [thunderbolt] process_one_work+0x626/0x1100 worker_thread+0x6c8/0xfa0 kthread+0x2c8/0x3a0 ret_from_fork+0x3a/0x80 ret_from_fork_asm+0x1a/0x30 This happens because the loop variable still gets incremented by one so max becomes 3 instead of 2, and this makes the second loop read past the the array declared on the stack. Fix this by assigning to max directly in the loop body.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50228", "url": "https://ubuntu.com/security/CVE-2024-50228", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50229", "url": "https://ubuntu.com/security/CVE-2024-50229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential deadlock with newly created symlinks Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers memory reclamation involving the filesystem layer, which can result in circular lock dependencies among the reader/writer semaphore nilfs->ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the fs_reclaim pseudo lock. This is because after commit 21fc61c73c39 (\"don't put symlink bodies in pagecache into highmem\"), the gfp flags of the page cache for symbolic links are overwritten to GFP_KERNEL via inode_nohighmem(). This is not a problem for symlinks read from the backing device, because the __GFP_FS flag is dropped after inode_nohighmem() is called. However, when a new symlink is created with nilfs_symlink(), the gfp flags remain overwritten to GFP_KERNEL. Then, memory allocation called from page_symlink() etc. triggers memory reclamation including the FS layer, which may call nilfs_evict_inode() or nilfs_dirty_inode(). And these can cause a deadlock if they are called while nilfs->ns_segctor_sem is held: Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags of newly created symlinks in the same way that nilfs_new_inode() and __nilfs_read_inode() do, as a workaround until we adopt nofs allocation scope consistently or improve the locking constraints.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50230", "url": "https://ubuntu.com/security/CVE-2024-50230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug due to missing clearing of checked flag Syzbot reported that in directory operations after nilfs2 detects filesystem corruption and degrades to read-only, __block_write_begin_int(), which is called to prepare block writes, may fail the BUG_ON check for accesses exceeding the folio/page size, triggering a kernel bug. This was found to be because the \"checked\" flag of a page/folio was not cleared when it was discarded by nilfs2's own routine, which causes the sanity check of directory entries to be skipped when the directory page/folio is reloaded. So, fix that. This was necessary when the use of nilfs2's own page discard routine was applied to more than just metadata files.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50231", "url": "https://ubuntu.com/security/CVE-2024-50231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gts-helper: Fix memory leaks in iio_gts_build_avail_scale_table() modprobe iio-test-gts and rmmod it, then the following memory leak occurs: \tunreferenced object 0xffffff80c810be00 (size 64): \t comm \"kunit_try_catch\", pid 1654, jiffies 4294913981 \t hex dump (first 32 bytes): \t 02 00 00 00 08 00 00 00 20 00 00 00 40 00 00 00 ........ ...@... \t 80 00 00 00 00 02 00 00 00 04 00 00 00 08 00 00 ................ \t backtrace (crc a63d875e): \t [<0000000028c1b3c2>] kmemleak_alloc+0x34/0x40 \t [<000000001d6ecc87>] __kmalloc_noprof+0x2bc/0x3c0 \t [<00000000393795c1>] devm_iio_init_iio_gts+0x4b4/0x16f4 \t [<0000000071bb4b09>] 0xffffffdf052a62e0 \t [<000000000315bc18>] 0xffffffdf052a6488 \t [<00000000f9dc55b5>] kunit_try_run_case+0x13c/0x3ac \t [<00000000175a3fd4>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000f505065d>] kthread+0x2e8/0x374 \t [<00000000bbfb0e5d>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cbfe9e70 (size 16): \t comm \"kunit_try_catch\", pid 1658, jiffies 4294914015 \t hex dump (first 16 bytes): \t 10 00 00 00 40 00 00 00 80 00 00 00 00 00 00 00 ....@........... \t backtrace (crc 857f0cb4): \t [<0000000028c1b3c2>] kmemleak_alloc+0x34/0x40 \t [<000000001d6ecc87>] __kmalloc_noprof+0x2bc/0x3c0 \t [<00000000393795c1>] devm_iio_init_iio_gts+0x4b4/0x16f4 \t [<0000000071bb4b09>] 0xffffffdf052a62e0 \t [<000000007d089d45>] 0xffffffdf052a6864 \t [<00000000f9dc55b5>] kunit_try_run_case+0x13c/0x3ac \t [<00000000175a3fd4>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000f505065d>] kthread+0x2e8/0x374 \t [<00000000bbfb0e5d>] ret_from_fork+0x10/0x20 \t...... It includes 5*5 times \"size 64\" memory leaks, which correspond to 5 times test_init_iio_gain_scale() calls with gts_test_gains size 10 (10*size(int)) and gts_test_itimes size 5. It also includes 5*1 times \"size 16\" memory leak, which correspond to one time __test_init_iio_gain_scale() call with gts_test_gains_gain_low size 3 (3*size(int)) and gts_test_itimes size 5. The reason is that the per_time_gains[i] is not freed which is allocated in the \"gts->num_itime\" for loop in iio_gts_build_avail_scale_table().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53076", "url": "https://ubuntu.com/security/CVE-2024-53076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gts-helper: Fix memory leaks for the error path of iio_gts_build_avail_scale_table() If per_time_scales[i] or per_time_gains[i] kcalloc fails in the for loop of iio_gts_build_avail_scale_table(), the err_free_out will fail to call kfree() each time when i is reduced to 0, so all the per_time_scales[0] and per_time_gains[0] will not be freed, which will cause memory leaks. Fix it by checking if i >= 0.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50232", "url": "https://ubuntu.com/security/CVE-2024-50232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr() In the ad7124_write_raw() function, parameter val can potentially be zero. This may lead to a division by zero when DIV_ROUND_CLOSEST() is called within ad7124_set_channel_odr(). The ad7124_write_raw() function is invoked through the sequence: iio_write_channel_raw() -> iio_write_channel_attribute() -> iio_channel_write(), with no checks in place to ensure val is non-zero.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50233", "url": "https://ubuntu.com/security/CVE-2024-50233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: iio: frequency: ad9832: fix division by zero in ad9832_calc_freqreg() In the ad9832_write_frequency() function, clk_get_rate() might return 0. This can lead to a division by zero when calling ad9832_calc_freqreg(). The check if (fout > (clk_get_rate(st->mclk) / 2)) does not protect against the case when fout is 0. The ad9832_write_frequency() function is called from ad9832_write(), and fout is derived from a text buffer, which can contain any value.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53055", "url": "https://ubuntu.com/security/CVE-2024-53055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix 6 GHz scan construction If more than 255 colocated APs exist for the set of all APs found during 2.4/5 GHz scanning, then the 6 GHz scan construction will loop forever since the loop variable has type u8, which can never reach the number found when that's bigger than 255, and is stored in a u32 variable. Also move it into the loops to have a smaller scope. Using a u32 there is fine, we limit the number of APs in the scan list and each has a limit on the number of RNR entries due to the frame size. With a limit of 1000 scan results, a frame size upper bound of 4096 (really it's more like ~2300) and a TBTT entry size of at least 11, we get an upper bound for the number of ~372k, well in the bounds of a u32.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50234", "url": "https://ubuntu.com/security/CVE-2024-50234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlegacy: Clear stale interrupts before resuming device iwl4965 fails upon resume from hibernation on my laptop. The reason seems to be a stale interrupt which isn't being cleared out before interrupts are enabled. We end up with a race beween the resume trying to bring things back up, and the restart work (queued form the interrupt handler) trying to bring things down. Eventually the whole thing blows up. Fix the problem by clearing out any stale interrupts before interrupts get enabled during resume. Here's a debug log of the indicent: [ 12.042589] ieee80211 phy0: il_isr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000 [ 12.042625] ieee80211 phy0: il4965_irq_tasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000 [ 12.042651] iwl4965 0000:10:00.0: RF_KILL bit toggled to enable radio. [ 12.042653] iwl4965 0000:10:00.0: On demand firmware reload [ 12.042690] ieee80211 phy0: il4965_irq_tasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282 [ 12.052207] ieee80211 phy0: il4965_mac_start enter [ 12.052212] ieee80211 phy0: il_prep_station Add STA to driver ID 31: ff:ff:ff:ff:ff:ff [ 12.052244] ieee80211 phy0: il4965_set_hw_ready hardware ready [ 12.052324] ieee80211 phy0: il_apm_init Init card's basic functions [ 12.052348] ieee80211 phy0: il_apm_init L1 Enabled; Disabling L0S [ 12.055727] ieee80211 phy0: il4965_load_bsm Begin load bsm [ 12.056140] ieee80211 phy0: il4965_verify_bsm Begin verify bsm [ 12.058642] ieee80211 phy0: il4965_verify_bsm BSM bootstrap uCode image OK [ 12.058721] ieee80211 phy0: il4965_load_bsm BSM write complete, poll 1 iterations [ 12.058734] ieee80211 phy0: __il4965_up iwl4965 is coming up [ 12.058737] ieee80211 phy0: il4965_mac_start Start UP work done. [ 12.058757] ieee80211 phy0: __il4965_down iwl4965 is going down [ 12.058761] ieee80211 phy0: il_scan_cancel_timeout Scan cancel timeout [ 12.058762] ieee80211 phy0: il_do_scan_abort Not performing scan to abort [ 12.058765] ieee80211 phy0: il_clear_ucode_stations Clearing ucode stations in driver [ 12.058767] ieee80211 phy0: il_clear_ucode_stations No active stations found to be cleared [ 12.058819] ieee80211 phy0: _il_apm_stop Stop card, put in low power state [ 12.058827] ieee80211 phy0: _il_apm_stop_master stop master [ 12.058864] ieee80211 phy0: il4965_clear_free_frames 0 frames on pre-allocated heap on clear. [ 12.058869] ieee80211 phy0: Hardware restart was requested [ 16.132299] iwl4965 0000:10:00.0: START_ALIVE timeout after 4000ms. [ 16.132303] ------------[ cut here ]------------ [ 16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue. [ 16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132390] Modules linked in: ctr ccm sch_fq_codel xt_tcpudp xt_multiport xt_state iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables binfmt_misc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdh_generic ecc iTCO_wdt i2c_dev iwl4965 iwlegacy coretemp snd_hda_codec_analog pcspkr psmouse mac80211 snd_hda_codec_generic libarc4 sdhci_pci cqhci sha256_generic sdhci libsha256 firewire_ohci snd_hda_intel snd_intel_dspcfg mmc_core snd_hda_codec snd_hwdep firewire_core led_class iosf_mbi snd_hda_core uhci_hcd lpc_ich crc_itu_t cfg80211 ehci_pci ehci_hcd snd_pcm usbcore mfd_core rfkill snd_timer snd usb_common soundcore video parport_pc parport intel_agp wmi intel_gtt backlight e1000e agpgart evdev [ 16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143 [ 16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010 [ 16.132463] Workqueue: async async_run_entry_fn [ 16.132469] RIP: 0010:ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132501] Code: da 02 00 0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50235", "url": "https://ubuntu.com/security/CVE-2024-50235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: clear wdev->cqm_config pointer on free When we free wdev->cqm_config when unregistering, we also need to clear out the pointer since the same wdev/netdev may get re-registered in another network namespace, then destroyed later, running this code again, which results in a double-free.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50236", "url": "https://ubuntu.com/security/CVE-2024-50236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: Fix memory leak in management tx In the current logic, memory is allocated for storing the MSDU context during management packet TX but this memory is not being freed during management TX completion. Similar leaks are seen in the management TX cleanup logic. Kmemleak reports this problem as below, unreferenced object 0xffffff80b64ed250 (size 16): comm \"kworker/u16:7\", pid 148, jiffies 4294687130 (age 714.199s) hex dump (first 16 bytes): 00 2b d8 d8 80 ff ff ff c4 74 e9 fd 07 00 00 00 .+.......t...... backtrace: [] __kmem_cache_alloc_node+0x1e4/0x2d8 [] kmalloc_trace+0x48/0x110 [] ath10k_wmi_tlv_op_gen_mgmt_tx_send+0xd4/0x1d8 [ath10k_core] [] ath10k_mgmt_over_wmi_tx_work+0x134/0x298 [ath10k_core] [] process_scheduled_works+0x1ac/0x400 [] worker_thread+0x208/0x328 [] kthread+0x100/0x1c0 [] ret_from_fork+0x10/0x20 Free the memory during completion and cleanup to fix the leak. Protect the mgmt_pending_tx idr_remove() operation in ath10k_wmi_tlv_op_cleanup_mgmt_tx_send() using ar->data_lock similar to other instances. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50237", "url": "https://ubuntu.com/security/CVE-2024-50237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower Avoid potentially crashing in the driver because of uninitialized private data", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50238", "url": "https://ubuntu.com/security/CVE-2024-50238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usbc: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data from the qcom-qmp-usb driver, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. This bug was later reproduced when the driver was copied to create the qmp-usbc driver. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with these drivers.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50239", "url": "https://ubuntu.com/security/CVE-2024-50239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usb-legacy: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data from the qcom-qmp-usb driver, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. This bug was later reproduced when the driver was copied to create the qmp-usb-legacy driver. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with these drivers.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50240", "url": "https://ubuntu.com/security/CVE-2024-50240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usb: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with this driver.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53077", "url": "https://ubuntu.com/security/CVE-2024-53077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpcrdma: Always release the rpcrdma_device's xa_array Dai pointed out that the xa_init_flags() in rpcrdma_add_one() needs to have a matching xa_destroy() in rpcrdma_remove_one() to release underlying memory that the xarray might have accrued during operation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50242", "url": "https://ubuntu.com/security/CVE-2024-50242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ntfs_file_release", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50243", "url": "https://ubuntu.com/security/CVE-2024-50243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix general protection fault in run_is_mapped_full Fixed deleating of a non-resident attribute in ntfs_create_inode() rollback.", "cve_priority": "low", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50244", "url": "https://ubuntu.com/security/CVE-2024-50244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ni_clear() Checking of NTFS_FLAGS_LOG_REPLAYING added to prevent access to uninitialized bitmap during replay process.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50245", "url": "https://ubuntu.com/security/CVE-2024-50245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix possible deadlock in mi_read Mutex lock with another subclass used in ni_lock_dir().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50246", "url": "https://ubuntu.com/security/CVE-2024-50246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Add rough attr alloc_size check", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50247", "url": "https://ubuntu.com/security/CVE-2024-50247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Check if more than chunk-size bytes are written A incorrectly formatted chunk may decompress into more than LZNT_CHUNK_SIZE bytes and a index out of bounds will occur in s_max_off.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50248", "url": "https://ubuntu.com/security/CVE-2024-50248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Add bounds checking to mi_enum_attr() Added bounds checking to make sure that every attr don't stray beyond valid memory region.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53078", "url": "https://ubuntu.com/security/CVE-2024-53078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Fix NULL vs IS_ERR() check in probe() The iommu_paging_domain_alloc() function doesn't return NULL pointers, it returns error pointers. Update the check to match.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53056", "url": "https://ubuntu.com/security/CVE-2024-53056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Fix potential NULL dereference in mtk_crtc_destroy() In mtk_crtc_create(), if the call to mbox_request_channel() fails then we set the \"mtk_crtc->cmdq_client.chan\" pointer to NULL. In that situation, we do not call cmdq_pkt_create(). During the cleanup, we need to check if the \"mtk_crtc->cmdq_client.chan\" is NULL first before calling cmdq_pkt_destroy(). Calling cmdq_pkt_destroy() is unnecessary if we didn't call cmdq_pkt_create() and it will result in a NULL pointer dereference.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50249", "url": "https://ubuntu.com/security/CVE-2024-50249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Make rmw_lock a raw_spin_lock The following BUG was triggered: ============================= [ BUG: Invalid wait context ] 6.12.0-rc2-XXX #406 Not tainted ----------------------------- kworker/1:1/62 is trying to lock: ffffff8801593030 (&cpc_ptr->rmw_lock){+.+.}-{3:3}, at: cpc_write+0xcc/0x370 other info that might help us debug this: context-{5:5} 2 locks held by kworker/1:1/62: #0: ffffff897ef5ec98 (&rq->__lock){-.-.}-{2:2}, at: raw_spin_rq_lock_nested+0x2c/0x50 #1: ffffff880154e238 (&sg_policy->update_lock){....}-{2:2}, at: sugov_update_shared+0x3c/0x280 stack backtrace: CPU: 1 UID: 0 PID: 62 Comm: kworker/1:1 Not tainted 6.12.0-rc2-g9654bd3e8806 #406 Workqueue: 0x0 (events) Call trace: dump_backtrace+0xa4/0x130 show_stack+0x20/0x38 dump_stack_lvl+0x90/0xd0 dump_stack+0x18/0x28 __lock_acquire+0x480/0x1ad8 lock_acquire+0x114/0x310 _raw_spin_lock+0x50/0x70 cpc_write+0xcc/0x370 cppc_set_perf+0xa0/0x3a8 cppc_cpufreq_fast_switch+0x40/0xc0 cpufreq_driver_fast_switch+0x4c/0x218 sugov_update_shared+0x234/0x280 update_load_avg+0x6ec/0x7b8 dequeue_entities+0x108/0x830 dequeue_task_fair+0x58/0x408 __schedule+0x4f0/0x1070 schedule+0x54/0x130 worker_thread+0xc0/0x2e8 kthread+0x130/0x148 ret_from_fork+0x10/0x20 sugov_update_shared() locks a raw_spinlock while cpc_write() locks a spinlock. To have a correct wait-type order, update rmw_lock to a raw spinlock and ensure that interrupts will be disabled on the CPU holding it. [ rjw: Changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50250", "url": "https://ubuntu.com/security/CVE-2024-50250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fsdax: dax_unshare_iter needs to copy entire blocks The code that copies data from srcmap to iomap in dax_unshare_iter is very very broken, which bfoster's recent fsx changes have exposed. If the pos and len passed to dax_file_unshare are not aligned to an fsblock boundary, the iter pos and length in the _iter function will reflect this unalignment. dax_iomap_direct_access always returns a pointer to the start of the kmapped fsdax page, even if its pos argument is in the middle of that page. This is catastrophic for data integrity when iter->pos is not aligned to a page, because daddr/saddr do not point to the same byte in the file as iter->pos. Hence we corrupt user data by copying it to the wrong place. If iter->pos + iomap_length() in the _iter function not aligned to a page, then we fail to copy a full block, and only partially populate the destination block. This is catastrophic for data confidentiality because we expose stale pmem contents. Fix both of these issues by aligning copy_pos/copy_len to a page boundary (remember, this is fsdax so 1 fsblock == 1 base page) so that we always copy full blocks. We're not done yet -- there's no call to invalidate_inode_pages2_range, so programs that have the file range mmap'd will continue accessing the old memory mapping after the file metadata updates have completed. Be careful with the return value -- if the unshare succeeds, we still need to return the number of bytes that the iomap iter thinks we're operating on.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50251", "url": "https://ubuntu.com/security/CVE-2024-50251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_payload: sanitize offset and length before calling skb_checksum() If access to offset + length is larger than the skbuff length, then skb_checksum() triggers BUG_ON(). skb_checksum() internally subtracts the length parameter while iterating over skbuff, BUG_ON(len) at the end of it checks that the expected length to be included in the checksum calculation is fully consumed.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50252", "url": "https://ubuntu.com/security/CVE-2024-50252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_ipip: Fix memory leak when changing remote IPv6 address The device stores IPv6 addresses that are used for encapsulation in linear memory that is managed by the driver. Changing the remote address of an ip6gre net device never worked properly, but since cited commit the following reproducer [1] would result in a warning [2] and a memory leak [3]. The problem is that the new remote address is never added by the driver to its hash table (and therefore the device) and the old address is never removed from it. Fix by programming the new address when the configuration of the ip6gre net device changes and removing the old one. If the address did not change, then the above would result in increasing the reference count of the address and then decreasing it. [1] # ip link add name bla up type ip6gre local 2001:db8:1::1 remote 2001:db8:2::1 tos inherit ttl inherit # ip link set dev bla type ip6gre remote 2001:db8:3::1 # ip link del dev bla # devlink dev reload pci/0000:01:00.0 [2] WARNING: CPU: 0 PID: 1682 at drivers/net/ethernet/mellanox/mlxsw/spectrum.c:3002 mlxsw_sp_ipv6_addr_put+0x140/0x1d0 Modules linked in: CPU: 0 UID: 0 PID: 1682 Comm: ip Not tainted 6.12.0-rc3-custom-g86b5b55bc835 #151 Hardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023 RIP: 0010:mlxsw_sp_ipv6_addr_put+0x140/0x1d0 [...] Call Trace: mlxsw_sp_router_netdevice_event+0x55f/0x1240 notifier_call_chain+0x5a/0xd0 call_netdevice_notifiers_info+0x39/0x90 unregister_netdevice_many_notify+0x63e/0x9d0 rtnl_dellink+0x16b/0x3a0 rtnetlink_rcv_msg+0x142/0x3f0 netlink_rcv_skb+0x50/0x100 netlink_unicast+0x242/0x390 netlink_sendmsg+0x1de/0x420 ____sys_sendmsg+0x2bd/0x320 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xd0 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f [3] unreferenced object 0xffff898081f597a0 (size 32): comm \"ip\", pid 1626, jiffies 4294719324 hex dump (first 32 bytes): 20 01 0d b8 00 02 00 00 00 00 00 00 00 00 00 01 ............... 21 49 61 83 80 89 ff ff 00 00 00 00 01 00 00 00 !Ia............. backtrace (crc fd9be911): [<00000000df89c55d>] __kmalloc_cache_noprof+0x1da/0x260 [<00000000ff2a1ddb>] mlxsw_sp_ipv6_addr_kvdl_index_get+0x281/0x340 [<000000009ddd445d>] mlxsw_sp_router_netdevice_event+0x47b/0x1240 [<00000000743e7757>] notifier_call_chain+0x5a/0xd0 [<000000007c7b9e13>] call_netdevice_notifiers_info+0x39/0x90 [<000000002509645d>] register_netdevice+0x5f7/0x7a0 [<00000000c2e7d2a9>] ip6gre_newlink_common.isra.0+0x65/0x130 [<0000000087cd6d8d>] ip6gre_newlink+0x72/0x120 [<000000004df7c7cc>] rtnl_newlink+0x471/0xa20 [<0000000057ed632a>] rtnetlink_rcv_msg+0x142/0x3f0 [<0000000032e0d5b5>] netlink_rcv_skb+0x50/0x100 [<00000000908bca63>] netlink_unicast+0x242/0x390 [<00000000cdbe1c87>] netlink_sendmsg+0x1de/0x420 [<0000000011db153e>] ____sys_sendmsg+0x2bd/0x320 [<000000003b6d53eb>] ___sys_sendmsg+0x9a/0xe0 [<00000000cae27c62>] __sys_sendmsg+0x7a/0xd0", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50253", "url": "https://ubuntu.com/security/CVE-2024-50253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check the validity of nr_words in bpf_iter_bits_new() Check the validity of nr_words in bpf_iter_bits_new(). Without this check, when multiplication overflow occurs for nr_bits (e.g., when nr_words = 0x0400-0001, nr_bits becomes 64), stack corruption may occur due to bpf_probe_read_kernel_common(..., nr_bytes = 0x2000-0008). Fix it by limiting the maximum value of nr_words to 511. The value is derived from the current implementation of BPF memory allocator. To ensure compatibility if the BPF memory allocator's size limitation changes in the future, use the helper bpf_mem_alloc_check_size() to check whether nr_bytes is too larger. And return -E2BIG instead of -ENOMEM for oversized nr_bytes.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50254", "url": "https://ubuntu.com/security/CVE-2024-50254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free dynamically allocated bits in bpf_iter_bits_destroy() bpf_iter_bits_destroy() uses \"kit->nr_bits <= 64\" to check whether the bits are dynamically allocated. However, the check is incorrect and may cause a kmemleak as shown below: unreferenced object 0xffff88812628c8c0 (size 32): comm \"swapper/0\", pid 1, jiffies 4294727320 hex dump (first 32 bytes): \tb0 c1 55 f5 81 88 ff ff f0 f0 f0 f0 f0 f0 f0 f0 ..U........... \tf0 f0 f0 f0 f0 f0 f0 f0 00 00 00 00 00 00 00 00 .............. backtrace (crc 781e32cc): \t[<00000000c452b4ab>] kmemleak_alloc+0x4b/0x80 \t[<0000000004e09f80>] __kmalloc_node_noprof+0x480/0x5c0 \t[<00000000597124d6>] __alloc.isra.0+0x89/0xb0 \t[<000000004ebfffcd>] alloc_bulk+0x2af/0x720 \t[<00000000d9c10145>] prefill_mem_cache+0x7f/0xb0 \t[<00000000ff9738ff>] bpf_mem_alloc_init+0x3e2/0x610 \t[<000000008b616eac>] bpf_global_ma_init+0x19/0x30 \t[<00000000fc473efc>] do_one_initcall+0xd3/0x3c0 \t[<00000000ec81498c>] kernel_init_freeable+0x66a/0x940 \t[<00000000b119f72f>] kernel_init+0x20/0x160 \t[<00000000f11ac9a7>] ret_from_fork+0x3c/0x70 \t[<0000000004671da4>] ret_from_fork_asm+0x1a/0x30 That is because nr_bits will be set as zero in bpf_iter_bits_next() after all bits have been iterated. Fix the issue by setting kit->bit to kit->nr_bits instead of setting kit->nr_bits to zero when the iteration completes in bpf_iter_bits_next(). In addition, use \"!nr_bits || bits >= nr_bits\" to check whether the iteration is complete and still use \"nr_bits > 64\" to indicate whether bits are dynamically allocated. The \"!nr_bits\" check is necessary because bpf_iter_bits_new() may fail before setting kit->nr_bits, and this condition will stop the iteration early instead of accessing the zeroed or freed kit->bits. Considering the initial value of kit->bits is -1 and the type of kit->nr_bits is unsigned int, change the type of kit->nr_bits to int. The potential overflow problem will be handled in the following patch.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50255", "url": "https://ubuntu.com/security/CVE-2024-50255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci: fix null-ptr-deref in hci_read_supported_codecs Fix __hci_cmd_sync_sk() to return not NULL for unknown opcodes. __hci_cmd_sync_sk() returns NULL if a command returns a status event. However, it also returns NULL where an opcode doesn't exist in the hci_cc table because hci_cmd_complete_evt() assumes status = skb->data[0] for unknown opcodes. This leads to null-ptr-deref in cmd_sync for HCI_OP_READ_LOCAL_CODECS as there is no hci_cc for HCI_OP_READ_LOCAL_CODECS, which always assumes status = skb->data[0]. KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077] CPU: 1 PID: 2000 Comm: kworker/u9:5 Not tainted 6.9.0-ga6bcb805883c-dirty #10 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: hci7 hci_power_on RIP: 0010:hci_read_supported_codecs+0xb9/0x870 net/bluetooth/hci_codec.c:138 Code: 08 48 89 ef e8 b8 c1 8f fd 48 8b 75 00 e9 96 00 00 00 49 89 c6 48 ba 00 00 00 00 00 fc ff df 4c 8d 60 70 4c 89 e3 48 c1 eb 03 <0f> b6 04 13 84 c0 0f 85 82 06 00 00 41 83 3c 24 02 77 0a e8 bf 78 RSP: 0018:ffff888120bafac8 EFLAGS: 00010212 RAX: 0000000000000000 RBX: 000000000000000e RCX: ffff8881173f0040 RDX: dffffc0000000000 RSI: ffffffffa58496c0 RDI: ffff88810b9ad1e4 RBP: ffff88810b9ac000 R08: ffffffffa77882a7 R09: 1ffffffff4ef1054 R10: dffffc0000000000 R11: fffffbfff4ef1055 R12: 0000000000000070 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88810b9ac000 FS: 0000000000000000(0000) GS:ffff8881f6c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6ddaa3439e CR3: 0000000139764003 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: hci_read_local_codecs_sync net/bluetooth/hci_sync.c:4546 [inline] hci_init_stage_sync net/bluetooth/hci_sync.c:3441 [inline] hci_init4_sync net/bluetooth/hci_sync.c:4706 [inline] hci_init_sync net/bluetooth/hci_sync.c:4742 [inline] hci_dev_init_sync net/bluetooth/hci_sync.c:4912 [inline] hci_dev_open_sync+0x19a9/0x2d30 net/bluetooth/hci_sync.c:4994 hci_dev_do_open net/bluetooth/hci_core.c:483 [inline] hci_power_on+0x11e/0x560 net/bluetooth/hci_core.c:1015 process_one_work kernel/workqueue.c:3267 [inline] process_scheduled_works+0x8ef/0x14f0 kernel/workqueue.c:3348 worker_thread+0x91f/0xe50 kernel/workqueue.c:3429 kthread+0x2cb/0x360 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50256", "url": "https://ubuntu.com/security/CVE-2024-50256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6() I got a syzbot report without a repro [1] crashing in nf_send_reset6() I think the issue is that dev->hard_header_len is zero, and we attempt later to push an Ethernet header. Use LL_MAX_HEADER, as other functions in net/ipv6/netfilter/nf_reject_ipv6.c. [1] skbuff: skb_under_panic: text:ffffffff89b1d008 len:74 put:14 head:ffff88803123aa00 data:ffff88803123a9f2 tail:0x3c end:0x140 dev:syz_tun kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 UID: 0 PID: 7373 Comm: syz.1.568 Not tainted 6.12.0-rc2-syzkaller-00631-g6d858708d465 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:skb_panic net/core/skbuff.c:206 [inline] RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216 Code: 0d 8d 48 c7 c6 60 a6 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 ba 30 38 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP: 0018:ffffc900045269b0 EFLAGS: 00010282 RAX: 0000000000000088 RBX: dffffc0000000000 RCX: cd66dacdc5d8e800 RDX: 0000000000000000 RSI: 0000000000000200 RDI: 0000000000000000 RBP: ffff88802d39a3d0 R08: ffffffff8174afec R09: 1ffff920008a4ccc R10: dffffc0000000000 R11: fffff520008a4ccd R12: 0000000000000140 R13: ffff88803123aa00 R14: ffff88803123a9f2 R15: 000000000000003c FS: 00007fdbee5ff6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000005d322000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: skb_push+0xe5/0x100 net/core/skbuff.c:2636 eth_header+0x38/0x1f0 net/ethernet/eth.c:83 dev_hard_header include/linux/netdevice.h:3208 [inline] nf_send_reset6+0xce6/0x1270 net/ipv6/netfilter/nf_reject_ipv6.c:358 nft_reject_inet_eval+0x3b9/0x690 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x418/0x6b0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] br_nf_pre_routing_ipv6+0x63e/0x770 net/bridge/br_netfilter_ipv6.c:184 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_bridge_pre net/bridge/br_input.c:277 [inline] br_handle_frame+0x9fd/0x1530 net/bridge/br_input.c:424 __netif_receive_skb_core+0x13e8/0x4570 net/core/dev.c:5562 __netif_receive_skb_one_core net/core/dev.c:5666 [inline] __netif_receive_skb+0x12f/0x650 net/core/dev.c:5781 netif_receive_skb_internal net/core/dev.c:5867 [inline] netif_receive_skb+0x1e8/0x890 net/core/dev.c:5926 tun_rx_batched+0x1b7/0x8f0 drivers/net/tun.c:1550 tun_get_user+0x3056/0x47e0 drivers/net/tun.c:2007 tun_chr_write_iter+0x10d/0x1f0 drivers/net/tun.c:2053 new_sync_write fs/read_write.c:590 [inline] vfs_write+0xa6d/0xc90 fs/read_write.c:683 ksys_write+0x183/0x2b0 fs/read_write.c:736 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:0x7fdbeeb7d1ff Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 c9 8d 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 1c 8e 02 00 48 RSP: 002b:00007fdbee5ff000 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fdbeed36058 RCX: 00007fdbeeb7d1ff RDX: 000000000000008e RSI: 0000000020000040 RDI: 00000000000000c8 RBP: 00007fdbeebf12be R08: 0000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50257", "url": "https://ubuntu.com/security/CVE-2024-50257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: Fix use-after-free in get_info() ip6table_nat module unload has refcnt warning for UAF. call trace is: WARNING: CPU: 1 PID: 379 at kernel/module/main.c:853 module_put+0x6f/0x80 Modules linked in: ip6table_nat(-) CPU: 1 UID: 0 PID: 379 Comm: ip6tables Not tainted 6.12.0-rc4-00047-gc2ee9f594da8-dirty #205 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:module_put+0x6f/0x80 Call Trace: get_info+0x128/0x180 do_ip6t_get_ctl+0x6a/0x430 nf_getsockopt+0x46/0x80 ipv6_getsockopt+0xb9/0x100 rawv6_getsockopt+0x42/0x190 do_sock_getsockopt+0xaa/0x180 __sys_getsockopt+0x70/0xc0 __x64_sys_getsockopt+0x20/0x30 do_syscall_64+0xa2/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Concurrent execution of module unload and get_info() trigered the warning. The root cause is as follows: cpu0\t\t\t\t cpu1 module_exit //mod->state = MODULE_STATE_GOING ip6table_nat_exit xt_unregister_template \tkfree(t) \t//removed from templ_list \t\t\t\t getinfo() \t\t\t\t\t t = xt_find_table_lock \t\t\t\t\t\tlist_for_each_entry(tmpl, &xt_templates[af]...) \t\t\t\t\t\t\tif (strcmp(tmpl->name, name)) \t\t\t\t\t\t\t\tcontinue; //table not found \t\t\t\t\t\t\ttry_module_get \t\t\t\t\t\tlist_for_each_entry(t, &xt_net->tables[af]...) \t\t\t\t\t\t\treturn t; //not get refcnt \t\t\t\t\t module_put(t->me) //uaf unregister_pernet_subsys //remove table from xt_net list While xt_table module was going away and has been removed from xt_templates list, we couldnt get refcnt of xt_table->me. Check module in xt_net->tables list re-traversal to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50258", "url": "https://ubuntu.com/security/CVE-2024-50258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix crash when config small gso_max_size/gso_ipv4_max_size Config a small gso_max_size/gso_ipv4_max_size will lead to an underflow in sk_dst_gso_max_size(), which may trigger a BUG_ON crash, because sk->sk_gso_max_size would be much bigger than device limits. Call Trace: tcp_write_xmit tso_segs = tcp_init_tso_segs(skb, mss_now); tcp_set_skb_tso_segs tcp_skb_pcount_set // skb->len = 524288, mss_now = 8 // u16 tso_segs = 524288/8 = 65535 -> 0 tso_segs = DIV_ROUND_UP(skb->len, mss_now) BUG_ON(!tso_segs) Add check for the minimum value of gso_max_size and gso_ipv4_max_size.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50262", "url": "https://ubuntu.com/security/CVE-2024-50262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix out-of-bounds write in trie_get_next_key() trie_get_next_key() allocates a node stack with size trie->max_prefixlen, while it writes (trie->max_prefixlen + 1) nodes to the stack when it has full paths from the root to leaves. For example, consider a trie with max_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ... 0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with .prefixlen = 8 make 9 nodes be written on the node stack with size 8.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53044", "url": "https://ubuntu.com/security/CVE-2024-53044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_api: fix xa_insert() error path in tcf_block_get_ext() This command: $ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact Error: block dev insert failed: -EBUSY. fails because user space requests the same block index to be set for both ingress and egress. [ side note, I don't think it even failed prior to commit 913b47d3424e (\"net/sched: Introduce tc block netdev tracking infra\"), because this is a command from an old set of notes of mine which used to work, but alas, I did not scientifically bisect this ] The problem is not that it fails, but rather, that the second time around, it fails differently (and irrecoverably): $ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact Error: dsa_core: Flow block cb is busy. [ another note: the extack is added by me for illustration purposes. the context of the problem is that clsact_init() obtains the same &q->ingress_block pointer as &q->egress_block, and since we call tcf_block_get_ext() on both of them, \"dev\" will be added to the block->ports xarray twice, thus failing the operation: once through the ingress block pointer, and once again through the egress block pointer. the problem itself is that when xa_insert() fails, we have emitted a FLOW_BLOCK_BIND command through ndo_setup_tc(), but the offload never sees a corresponding FLOW_BLOCK_UNBIND. ] Even correcting the bad user input, we still cannot recover: $ tc qdisc replace dev swp3 ingress_block 1 egress_block 2 clsact Error: dsa_core: Flow block cb is busy. Basically the only way to recover is to reboot the system, or unbind and rebind the net device driver. To fix the bug, we need to fill the correct error teardown path which was missed during code movement, and call tcf_block_offload_unbind() when xa_insert() fails. [ last note, fundamentally I blame the label naming convention in tcf_block_get_ext() for the bug. The labels should be named after what they do, not after the error path that jumps to them. This way, it is obviously wrong that two labels pointing to the same code mean something is wrong, and checking the code correctness at the goto site is also easier ]", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50259", "url": "https://ubuntu.com/security/CVE-2024-50259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netdevsim: Add trailing zero to terminate the string in nsim_nexthop_bucket_activity_write() This was found by a static analyzer. We should not forget the trailing zero after copy_from_user() if we will further do some string operations, sscanf() in this case. Adding a trailing zero will ensure that the function performs properly.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50304", "url": "https://ubuntu.com/security/CVE-2024-50304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find() The per-netns IP tunnel hash table is protected by the RTNL mutex and ip_tunnel_find() is only called from the control path where the mutex is taken. Add a lockdep expression to hlist_for_each_entry_rcu() in ip_tunnel_find() in order to validate that the mutex is held and to silence the suspicious RCU usage warning [1]. [1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gd95d9a31aceb #139 Not tainted ----------------------------- net/ipv4/ip_tunnel.c:221 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/362: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60 stack backtrace: CPU: 12 UID: 0 PID: 362 Comm: ip Not tainted 6.12.0-rc3-custom-gd95d9a31aceb #139 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 ip_tunnel_find+0x435/0x4d0 ip_tunnel_newlink+0x517/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53042", "url": "https://ubuntu.com/security/CVE-2024-53042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_init_flow() There are code paths from which the function is called without holding the RCU read lock, resulting in a suspicious RCU usage warning [1]. Fix by using l3mdev_master_upper_ifindex_by_index() which will acquire the RCU read lock before calling l3mdev_master_upper_ifindex_by_index_rcu(). [1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gac8f72681cf2 #141 Not tainted ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/361: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60 stack backtrace: CPU: 3 UID: 0 PID: 361 Comm: ip Not tainted 6.12.0-rc3-custom-gac8f72681cf2 #141 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 dev_get_by_index_rcu+0x1d3/0x210 l3mdev_master_upper_ifindex_by_index_rcu+0x2b/0xf0 ip_tunnel_bind_dev+0x72f/0xa00 ip_tunnel_newlink+0x368/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53048", "url": "https://ubuntu.com/security/CVE-2024-53048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix crash on probe for DPLL enabled E810 LOM The E810 Lan On Motherboard (LOM) design is vendor specific. Intel provides the reference design, but it is up to vendor on the final product design. For some cases, like Linux DPLL support, the static values defined in the driver does not reflect the actual LOM design. Current implementation of dpll pins is causing the crash on probe of the ice driver for such DPLL enabled E810 LOM designs: WARNING: (...) at drivers/dpll/dpll_core.c:495 dpll_pin_get+0x2c4/0x330 ... Call Trace: ? __warn+0x83/0x130 ? dpll_pin_get+0x2c4/0x330 ? report_bug+0x1b7/0x1d0 ? handle_bug+0x42/0x70 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? dpll_pin_get+0x117/0x330 ? dpll_pin_get+0x2c4/0x330 ? dpll_pin_get+0x117/0x330 ice_dpll_get_pins.isra.0+0x52/0xe0 [ice] ... The number of dpll pins enabled by LOM vendor is greater than expected and defined in the driver for Intel designed NICs, which causes the crash. Prevent the crash and allow generic pin initialization within Linux DPLL subsystem for DPLL enabled E810 LOM designs. Newly designed solution for described issue will be based on \"per HW design\" pin initialization. It requires pin information dynamically acquired from the firmware and is already in progress, planned for next-tree only.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53058", "url": "https://ubuntu.com/security/CVE-2024-53058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data In case the non-paged data of a SKB carries protocol header and protocol payload to be transmitted on a certain platform that the DMA AXI address width is configured to 40-bit/48-bit, or the size of the non-paged data is bigger than TSO_MAX_BUFF_SIZE on a certain platform that the DMA AXI address width is configured to 32-bit, then this SKB requires at least two DMA transmit descriptors to serve it. For example, three descriptors are allocated to split one DMA buffer mapped from one piece of non-paged data: dma_desc[N + 0], dma_desc[N + 1], dma_desc[N + 2]. Then three elements of tx_q->tx_skbuff_dma[] will be allocated to hold extra information to be reused in stmmac_tx_clean(): tx_q->tx_skbuff_dma[N + 0], tx_q->tx_skbuff_dma[N + 1], tx_q->tx_skbuff_dma[N + 2]. Now we focus on tx_q->tx_skbuff_dma[entry].buf, which is the DMA buffer address returned by DMA mapping call. stmmac_tx_clean() will try to unmap the DMA buffer _ONLY_IF_ tx_q->tx_skbuff_dma[entry].buf is a valid buffer address. The expected behavior that saves DMA buffer address of this non-paged data to tx_q->tx_skbuff_dma[entry].buf is: tx_q->tx_skbuff_dma[N + 0].buf = NULL; tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = dma_map_single(); Unfortunately, the current code misbehaves like this: tx_q->tx_skbuff_dma[N + 0].buf = dma_map_single(); tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = NULL; On the stmmac_tx_clean() side, when dma_desc[N + 0] is closed by the DMA engine, tx_q->tx_skbuff_dma[N + 0].buf is a valid buffer address obviously, then the DMA buffer will be unmapped immediately. There may be a rare case that the DMA engine does not finish the pending dma_desc[N + 1], dma_desc[N + 2] yet. Now things will go horribly wrong, DMA is going to access a unmapped/unreferenced memory region, corrupted data will be transmited or iommu fault will be triggered :( In contrast, the for-loop that maps SKB fragments behaves perfectly as expected, and that is how the driver should do for both non-paged data and paged frags actually. This patch corrects DMA map/unmap sequences by fixing the array index for tx_q->tx_skbuff_dma[entry].buf when assigning DMA buffer address. Tested and verified on DWXGMAC CORE 3.20a", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50260", "url": "https://ubuntu.com/security/CVE-2024-50260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sock_map: fix a NULL pointer dereference in sock_map_link_update_prog() The following race condition could trigger a NULL pointer dereference: sock_map_link_detach():\t\tsock_map_link_update_prog(): mutex_lock(&sockmap_mutex); ... sockmap_link->map = NULL; mutex_unlock(&sockmap_mutex); \t\t\t\t mutex_lock(&sockmap_mutex); \t\t\t\t ... \t\t\t\t sock_map_prog_link_lookup(sockmap_link->map); \t\t\t\t mutex_unlock(&sockmap_mutex); Fix it by adding a NULL pointer check. In this specific case, it makes no sense to update a link which is being released.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53045", "url": "https://ubuntu.com/security/CVE-2024-53045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: dapm: fix bounds checker error in dapm_widget_list_create The widgets array in the snd_soc_dapm_widget_list has a __counted_by attribute attached to it, which points to the num_widgets variable. This attribute is used in bounds checking, and if it is not set before the array is filled, then the bounds sanitizer will issue a warning or a kernel panic if CONFIG_UBSAN_TRAP is set. This patch sets the size of the widgets list calculated with list_for_each as the initial value for num_widgets as it is used for allocating memory for the array. It is updated with the actual number of added elements after the array is filled.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50261", "url": "https://ubuntu.com/security/CVE-2024-50261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macsec: Fix use-after-free while sending the offloading packet KASAN reports the following UAF. The metadata_dst, which is used to store the SCI value for macsec offload, is already freed by metadata_dst_free() in macsec_free_netdev(), while driver still use it for sending the packet. To fix this issue, dst_release() is used instead to release metadata_dst. So it is not freed instantly in macsec_free_netdev() if still referenced by skb. BUG: KASAN: slab-use-after-free in mlx5e_xmit+0x1e8f/0x4190 [mlx5_core] Read of size 2 at addr ffff88813e42e038 by task kworker/7:2/714 [...] Workqueue: mld mld_ifc_work Call Trace: dump_stack_lvl+0x51/0x60 print_report+0xc1/0x600 kasan_report+0xab/0xe0 mlx5e_xmit+0x1e8f/0x4190 [mlx5_core] dev_hard_start_xmit+0x120/0x530 sch_direct_xmit+0x149/0x11e0 __qdisc_run+0x3ad/0x1730 __dev_queue_xmit+0x1196/0x2ed0 vlan_dev_hard_start_xmit+0x32e/0x510 [8021q] dev_hard_start_xmit+0x120/0x530 __dev_queue_xmit+0x14a7/0x2ed0 macsec_start_xmit+0x13e9/0x2340 dev_hard_start_xmit+0x120/0x530 __dev_queue_xmit+0x14a7/0x2ed0 ip6_finish_output2+0x923/0x1a70 ip6_finish_output+0x2d7/0x970 ip6_output+0x1ce/0x3a0 NF_HOOK.constprop.0+0x15f/0x190 mld_sendpack+0x59a/0xbd0 mld_ifc_work+0x48a/0xa80 process_one_work+0x5aa/0xe50 worker_thread+0x79c/0x1290 kthread+0x28f/0x350 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x11/0x20 Allocated by task 3922: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 __kasan_kmalloc+0x77/0x90 __kmalloc_noprof+0x188/0x400 metadata_dst_alloc+0x1f/0x4e0 macsec_newlink+0x914/0x1410 __rtnl_newlink+0xe08/0x15b0 rtnl_newlink+0x5f/0x90 rtnetlink_rcv_msg+0x667/0xa80 netlink_rcv_skb+0x12c/0x360 netlink_unicast+0x551/0x770 netlink_sendmsg+0x72d/0xbd0 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x52e/0x6a0 ___sys_sendmsg+0xeb/0x170 __sys_sendmsg+0xb5/0x140 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Freed by task 4011: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x50 poison_slab_object+0x10c/0x190 __kasan_slab_free+0x11/0x30 kfree+0xe0/0x290 macsec_free_netdev+0x3f/0x140 netdev_run_todo+0x450/0xc70 rtnetlink_rcv_msg+0x66f/0xa80 netlink_rcv_skb+0x12c/0x360 netlink_unicast+0x551/0x770 netlink_sendmsg+0x72d/0xbd0 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x52e/0x6a0 ___sys_sendmsg+0xeb/0x170 __sys_sendmsg+0xb5/0x140 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53059", "url": "https://ubuntu.com/security/CVE-2024-53059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd() 1. The size of the response packet is not validated. 2. The response buffer is not freed. Resolve these issues by switching to iwl_mvm_send_cmd_status(), which handles both size validation and frees the buffer.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53074", "url": "https://ubuntu.com/security/CVE-2024-53074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: don't leak a link on AP removal Release the link mapping resource in AP removal. This impacted devices that do not support the MLD API (9260 and down). On those devices, we couldn't start the AP again after the AP has been already started and stopped.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53049", "url": "https://ubuntu.com/security/CVE-2024-53049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slub/kunit: fix a WARNING due to unwrapped __kmalloc_cache_noprof 'modprobe slub_kunit' will have a warning as shown below. The root cause is that __kmalloc_cache_noprof was directly used, which resulted in no alloc_tag being allocated. This caused current->alloc_tag to be null, leading to a warning in alloc_tag_add_check. Let's add an alloc_hook layer to __kmalloc_cache_noprof specifically within lib/slub_kunit.c, which is the only user of this internal slub function outside kmalloc implementation itself. [58162.947016] WARNING: CPU: 2 PID: 6210 at ./include/linux/alloc_tag.h:125 alloc_tagging_slab_alloc_hook+0x268/0x27c [58162.957721] Call trace: [58162.957919] alloc_tagging_slab_alloc_hook+0x268/0x27c [58162.958286] __kmalloc_cache_noprof+0x14c/0x344 [58162.958615] test_kmalloc_redzone_access+0x50/0x10c [slub_kunit] [58162.959045] kunit_try_run_case+0x74/0x184 [kunit] [58162.959401] kunit_generic_run_threadfn_adapter+0x2c/0x4c [kunit] [58162.959841] kthread+0x10c/0x118 [58162.960093] ret_from_fork+0x10/0x20 [58162.960363] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50192", "url": "https://ubuntu.com/security/CVE-2024-50192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v4: Don't allow a VMOVP on a dying VPE Kunkun Jiang reported that there is a small window of opportunity for userspace to force a change of affinity for a VPE while the VPE has already been unmapped, but the corresponding doorbell interrupt still visible in /proc/irq/. Plug the race by checking the value of vmapp_count, which tracks whether the VPE is mapped ot not, and returning an error in this case. This involves making vmapp_count common to both GICv4.1 and its v4.0 ancestor.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50069", "url": "https://ubuntu.com/security/CVE-2024-50069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: apple: check devm_kasprintf() returned value devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked. Fix this lack and check the returned value. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50070", "url": "https://ubuntu.com/security/CVE-2024-50070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: stm32: check devm_kasprintf() returned value devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked. Fix this lack and check the returned value. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50196", "url": "https://ubuntu.com/security/CVE-2024-50196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: ocelot: fix system hang on level based interrupts The current implementation only calls chained_irq_enter() and chained_irq_exit() if it detects pending interrupts. ``` for (i = 0; i < info->stride; i++) { \turegmap_read(info->map, id_reg + 4 * i, ®); \tif (!reg) \t\tcontinue; \tchained_irq_enter(parent_chip, desc); ``` However, in case of GPIO pin configured in level mode and the parent controller configured in edge mode, GPIO interrupt might be lowered by the hardware. In the result, if the interrupt is short enough, the parent interrupt is still pending while the GPIO interrupt is cleared; chained_irq_enter() never gets called and the system hangs trying to service the parent interrupt. Moving chained_irq_enter() and chained_irq_exit() outside the for loop ensures that they are called even when GPIO interrupt is lowered by the hardware. The similar code with chained_irq_enter() / chained_irq_exit() functions wrapping interrupt checking loop may be found in many other drivers: ``` grep -r -A 10 chained_irq_enter drivers/pinctrl ```", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50197", "url": "https://ubuntu.com/security/CVE-2024-50197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: intel: platform: fix error path in device_for_each_child_node() The device_for_each_child_node() loop requires calls to fwnode_handle_put() upon early returns to decrement the refcount of the child node and avoid leaking memory if that error path is triggered. There is one early returns within that loop in intel_platform_pinctrl_prepare_community(), but fwnode_handle_put() is missing. Instead of adding the missing call, the scoped version of the loop can be used to simplify the code and avoid mistakes in the future if new early returns are added, as the child node is only used for parsing, and it is never assigned.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50071", "url": "https://ubuntu.com/security/CVE-2024-50071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: nuvoton: fix a double free in ma35_pinctrl_dt_node_to_map_func() 'new_map' is allocated using devm_* which takes care of freeing the allocated data on device removal, call to \t.dt_free_map = pinconf_generic_dt_free_map double frees the map as pinconf_generic_dt_free_map() calls pinctrl_utils_free_map(). Fix this by using kcalloc() instead of auto-managed devm_kcalloc().", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50072", "url": "https://ubuntu.com/security/CVE-2024-50072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/bugs: Use code segment selector for VERW operand Robert Gill reported below #GP in 32-bit mode when dosemu software was executing vm86() system call: general protection fault: 0000 [#1] PREEMPT SMP CPU: 4 PID: 4610 Comm: dosemu.bin Not tainted 6.6.21-gentoo-x86 #1 Hardware name: Dell Inc. PowerEdge 1950/0H723K, BIOS 2.7.0 10/30/2010 EIP: restore_all_switch_stack+0xbe/0xcf EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000 ESI: 00000000 EDI: 00000000 EBP: 00000000 ESP: ff8affdc DS: 0000 ES: 0000 FS: 0000 GS: 0033 SS: 0068 EFLAGS: 00010046 CR0: 80050033 CR2: 00c2101c CR3: 04b6d000 CR4: 000406d0 Call Trace: show_regs+0x70/0x78 die_addr+0x29/0x70 exc_general_protection+0x13c/0x348 exc_bounds+0x98/0x98 handle_exception+0x14d/0x14d exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf This only happens in 32-bit mode when VERW based mitigations like MDS/RFDS are enabled. This is because segment registers with an arbitrary user value can result in #GP when executing VERW. Intel SDM vol. 2C documents the following behavior for VERW instruction: #GP(0) - If a memory operand effective address is outside the CS, DS, ES, \t FS, or GS segment limit. CLEAR_CPU_BUFFERS macro executes VERW instruction before returning to user space. Use %cs selector to reference VERW operand. This ensures VERW will not #GP for an arbitrary user %ds. [ mingo: Fixed the SOB chain. ]", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50073", "url": "https://ubuntu.com/security/CVE-2024-50073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: Fix use-after-free in gsm_cleanup_mux BUG: KASAN: slab-use-after-free in gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] Read of size 8 at addr ffff88815fe99c00 by task poc/3379 CPU: 0 UID: 0 PID: 3379 Comm: poc Not tainted 6.11.0+ #56 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] __pfx_gsm_cleanup_mux+0x10/0x10 drivers/tty/n_gsm.c:3124 [n_gsm] __pfx_sched_clock_cpu+0x10/0x10 kernel/sched/clock.c:389 update_load_avg+0x1c1/0x27b0 kernel/sched/fair.c:4500 __pfx_min_vruntime_cb_rotate+0x10/0x10 kernel/sched/fair.c:846 __rb_insert_augmented+0x492/0xbf0 lib/rbtree.c:161 gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] _raw_spin_lock_irqsave+0x92/0xf0 arch/x86/include/asm/atomic.h:107 __pfx_gsmld_ioctl+0x10/0x10 drivers/tty/n_gsm.c:3822 [n_gsm] ktime_get+0x5e/0x140 kernel/time/timekeeping.c:195 ldsem_down_read+0x94/0x4e0 arch/x86/include/asm/atomic64_64.h:79 __pfx_ldsem_down_read+0x10/0x10 drivers/tty/tty_ldsem.c:338 __pfx_do_vfs_ioctl+0x10/0x10 fs/ioctl.c:805 tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 Allocated by task 65: gsm_data_alloc.constprop.0+0x27/0x190 drivers/tty/n_gsm.c:926 [n_gsm] gsm_send+0x2c/0x580 drivers/tty/n_gsm.c:819 [n_gsm] gsm1_receive+0x547/0xad0 drivers/tty/n_gsm.c:3038 [n_gsm] gsmld_receive_buf+0x176/0x280 drivers/tty/n_gsm.c:3609 [n_gsm] tty_ldisc_receive_buf+0x101/0x1e0 drivers/tty/tty_buffer.c:391 tty_port_default_receive_buf+0x61/0xa0 drivers/tty/tty_port.c:39 flush_to_ldisc+0x1b0/0x750 drivers/tty/tty_buffer.c:445 process_scheduled_works+0x2b0/0x10d0 kernel/workqueue.c:3229 worker_thread+0x3dc/0x950 kernel/workqueue.c:3391 kthread+0x2a3/0x370 kernel/kthread.c:389 ret_from_fork+0x2d/0x70 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:257 Freed by task 3367: kfree+0x126/0x420 mm/slub.c:4580 gsm_cleanup_mux+0x36c/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 [Analysis] gsm_msg on the tx_ctrl_list or tx_data_list of gsm_mux can be freed by multi threads through ioctl,which leads to the occurrence of uaf. Protect it by gsm tx lock.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50193", "url": "https://ubuntu.com/security/CVE-2024-50193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/entry_32: Clear CPU buffers after register restore in NMI return CPU buffers are currently cleared after call to exc_nmi, but before register state is restored. This may be okay for MDS mitigation but not for RDFS. Because RDFS mitigation requires CPU buffers to be cleared when registers don't have any sensitive data. Move CLEAR_CPU_BUFFERS after RESTORE_ALL_NMI.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50074", "url": "https://ubuntu.com/security/CVE-2024-50074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: parport: Proper fix for array out-of-bounds access The recent fix for array out-of-bounds accesses replaced sprintf() calls blindly with snprintf(). However, since snprintf() returns the would-be-printed size, not the actually output size, the length calculation can still go over the given limit. Use scnprintf() instead of snprintf(), which returns the actually output letters, for addressing the potential out-of-bounds access properly.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50100", "url": "https://ubuntu.com/security/CVE-2024-50100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: gadget: dummy-hcd: Fix \"task hung\" problem The syzbot fuzzer has been encountering \"task hung\" problems ever since the dummy-hcd driver was changed to use hrtimers instead of regular timers. It turns out that the problems are caused by a subtle difference between the timer_pending() and hrtimer_active() APIs. The changeover blindly replaced the first by the second. However, timer_pending() returns True when the timer is queued but not when its callback is running, whereas hrtimer_active() returns True when the hrtimer is queued _or_ its callback is running. This difference occasionally caused dummy_urb_enqueue() to think that the callback routine had not yet started when in fact it was almost finished. As a result the hrtimer was not restarted, which made it impossible for the driver to dequeue later the URB that was just enqueued. This caused usb_kill_urb() to hang, and things got worse from there. Since hrtimers have no API for telling when they are queued and the callback isn't running, the driver must keep track of this for itself. That's what this patch does, adding a new \"timer_pending\" flag and setting or clearing it at the appropriate times.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50075", "url": "https://ubuntu.com/security/CVE-2024-50075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xhci: tegra: fix checked USB2 port number If USB virtualizatoin is enabled, USB2 ports are shared between all Virtual Functions. The USB2 port number owned by an USB2 root hub in a Virtual Function may be less than total USB2 phy number supported by the Tegra XUSB controller. Using total USB2 phy number as port number to check all PORTSC values would cause invalid memory access. [ 116.923438] Unable to handle kernel paging request at virtual address 006c622f7665642f ... [ 117.213640] Call trace: [ 117.216783] tegra_xusb_enter_elpg+0x23c/0x658 [ 117.222021] tegra_xusb_runtime_suspend+0x40/0x68 [ 117.227260] pm_generic_runtime_suspend+0x30/0x50 [ 117.232847] __rpm_callback+0x84/0x3c0 [ 117.237038] rpm_suspend+0x2dc/0x740 [ 117.241229] pm_runtime_work+0xa0/0xb8 [ 117.245769] process_scheduled_works+0x24c/0x478 [ 117.251007] worker_thread+0x23c/0x328 [ 117.255547] kthread+0x104/0x1b0 [ 117.259389] ret_from_fork+0x10/0x20 [ 117.263582] Code: 54000222 f9461ae8 f8747908 b4ffff48 (f9400100)", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50076", "url": "https://ubuntu.com/security/CVE-2024-50076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vt: prevent kernel-infoleak in con_font_get() font.data may not initialize all memory spaces depending on the implementation of vc->vc_sw->con_font_get. This may cause info-leak, so to prevent this, it is safest to modify it to initialize the allocated memory space to 0, and it generally does not affect the overall performance of the system.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50077", "url": "https://ubuntu.com/security/CVE-2024-50077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix multiple init when debugfs is disabled If bt_debugfs is not created successfully, which happens if either CONFIG_DEBUG_FS or CONFIG_DEBUG_FS_ALLOW_ALL is unset, then iso_init() returns early and does not set iso_inited to true. This means that a subsequent call to iso_init() will result in duplicate calls to proto_register(), bt_sock_register(), etc. With CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, the duplicate call to proto_register() triggers this BUG(): list_add double add: new=ffffffffc0b280d0, prev=ffffffffbab56250, next=ffffffffc0b280d0. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:35! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 2 PID: 887 Comm: bluetoothd Not tainted 6.10.11-1-ao-desktop #1 RIP: 0010:__list_add_valid_or_report+0x9a/0xa0 ... __list_add_valid_or_report+0x9a/0xa0 proto_register+0x2b5/0x340 iso_init+0x23/0x150 [bluetooth] set_iso_socket_func+0x68/0x1b0 [bluetooth] kmem_cache_free+0x308/0x330 hci_sock_sendmsg+0x990/0x9e0 [bluetooth] __sock_sendmsg+0x7b/0x80 sock_write_iter+0x9a/0x110 do_iter_readv_writev+0x11d/0x220 vfs_writev+0x180/0x3e0 do_writev+0xca/0x100 ... This change removes the early return. The check for iso_debugfs being NULL was unnecessary, it is always NULL when iso_inited is false.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50078", "url": "https://ubuntu.com/security/CVE-2024-50078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Call iso_exit() on module unload If iso_init() has been called, iso_exit() must be called on module unload. Without that, the struct proto that iso_init() registered with proto_register() becomes invalid, which could cause unpredictable problems later. In my case, with CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, loading the module again usually triggers this BUG(): list_add corruption. next->prev should be prev (ffffffffb5355fd0), but was 0000000000000068. (next=ffffffffc0a010d0). ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:29! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 4159 Comm: modprobe Not tainted 6.10.11-4+bt2-ao-desktop #1 RIP: 0010:__list_add_valid_or_report+0x61/0xa0 ... __list_add_valid_or_report+0x61/0xa0 proto_register+0x299/0x320 hci_sock_init+0x16/0xc0 [bluetooth] bt_init+0x68/0xd0 [bluetooth] __pfx_bt_init+0x10/0x10 [bluetooth] do_one_initcall+0x80/0x2f0 do_init_module+0x8b/0x230 __do_sys_init_module+0x15f/0x190 do_syscall_64+0x68/0x110 ...", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50198", "url": "https://ubuntu.com/security/CVE-2024-50198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: veml6030: fix IIO device retrieval from embedded device The dev pointer that is received as an argument in the in_illuminance_period_available_show function references the device embedded in the IIO device, not in the i2c client. dev_to_iio_dev() must be used to accessthe right data. The current implementation leads to a segmentation fault on every attempt to read the attribute because indio_dev gets a NULL assignment. This bug has been present since the first appearance of the driver, apparently since the last version (V6) before getting applied. A constant attribute was used until then, and the last modifications might have not been tested again.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50201", "url": "https://ubuntu.com/security/CVE-2024-50201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: Fix encoder->possible_clones Include the encoder itself in its possible_clones bitmask. In the past nothing validated that drivers were populating possible_clones correctly, but that changed in commit 74d2aacbe840 (\"drm: Validate encoder->possible_clones\"). Looks like radeon never got the memo and is still not following the rules 100% correctly. This results in some warnings during driver initialization: Bogus possible_clones: [ENCODER:46:TV-46] possible_clones=0x4 (full encoder mask=0x7) WARNING: CPU: 0 PID: 170 at drivers/gpu/drm/drm_mode_config.c:615 drm_mode_config_validate+0x113/0x39c ... (cherry picked from commit 3b6e7d40649c0d75572039aff9d0911864c689db)", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50098", "url": "https://ubuntu.com/security/CVE-2024-50098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Set SDEV_OFFLINE when UFS is shut down There is a history of deadlock if reboot is performed at the beginning of booting. SDEV_QUIESCE was set for all LU's scsi_devices by UFS shutdown, and at that time the audio driver was waiting on blk_mq_submit_bio() holding a mutex_lock while reading the fw binary. After that, a deadlock issue occurred while audio driver shutdown was waiting for mutex_unlock of blk_mq_submit_bio(). To solve this, set SDEV_OFFLINE for all LUs except WLUN, so that any I/O that comes down after a UFS shutdown will return an error. [ 31.907781]I[0: swapper/0: 0] 1 130705007 1651079834 11289729804 0 D( 2) 3 ffffff882e208000 * init [device_shutdown] [ 31.907793]I[0: swapper/0: 0] Mutex: 0xffffff8849a2b8b0: owner[0xffffff882e28cb00 kworker/6:0 :49] [ 31.907806]I[0: swapper/0: 0] Call trace: [ 31.907810]I[0: swapper/0: 0] __switch_to+0x174/0x338 [ 31.907819]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc [ 31.907826]I[0: swapper/0: 0] schedule+0x7c/0xe8 [ 31.907834]I[0: swapper/0: 0] schedule_preempt_disabled+0x24/0x40 [ 31.907842]I[0: swapper/0: 0] __mutex_lock+0x408/0xdac [ 31.907849]I[0: swapper/0: 0] __mutex_lock_slowpath+0x14/0x24 [ 31.907858]I[0: swapper/0: 0] mutex_lock+0x40/0xec [ 31.907866]I[0: swapper/0: 0] device_shutdown+0x108/0x280 [ 31.907875]I[0: swapper/0: 0] kernel_restart+0x4c/0x11c [ 31.907883]I[0: swapper/0: 0] __arm64_sys_reboot+0x15c/0x280 [ 31.907890]I[0: swapper/0: 0] invoke_syscall+0x70/0x158 [ 31.907899]I[0: swapper/0: 0] el0_svc_common+0xb4/0xf4 [ 31.907909]I[0: swapper/0: 0] do_el0_svc+0x2c/0xb0 [ 31.907918]I[0: swapper/0: 0] el0_svc+0x34/0xe0 [ 31.907928]I[0: swapper/0: 0] el0t_64_sync_handler+0x68/0xb4 [ 31.907937]I[0: swapper/0: 0] el0t_64_sync+0x1a0/0x1a4 [ 31.908774]I[0: swapper/0: 0] 49 0 11960702 11236868007 0 D( 2) 6 ffffff882e28cb00 * kworker/6:0 [__bio_queue_enter] [ 31.908783]I[0: swapper/0: 0] Call trace: [ 31.908788]I[0: swapper/0: 0] __switch_to+0x174/0x338 [ 31.908796]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc [ 31.908803]I[0: swapper/0: 0] schedule+0x7c/0xe8 [ 31.908811]I[0: swapper/0: 0] __bio_queue_enter+0xb8/0x178 [ 31.908818]I[0: swapper/0: 0] blk_mq_submit_bio+0x194/0x67c [ 31.908827]I[0: swapper/0: 0] __submit_bio+0xb8/0x19c", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50079", "url": "https://ubuntu.com/security/CVE-2024-50079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/sqpoll: ensure task state is TASK_RUNNING when running task_work When the sqpoll is exiting and cancels pending work items, it may need to run task_work. If this happens from within io_uring_cancel_generic(), then it may be under waiting for the io_uring_task waitqueue. This results in the below splat from the scheduler, as the ring mutex may be attempted grabbed while in a TASK_INTERRUPTIBLE state. Ensure that the task state is set appropriately for that, just like what is done for the other cases in io_run_task_work(). do not call blocking ops when !TASK_RUNNING; state=1 set at [<0000000029387fd2>] prepare_to_wait+0x88/0x2fc WARNING: CPU: 6 PID: 59939 at kernel/sched/core.c:8561 __might_sleep+0xf4/0x140 Modules linked in: CPU: 6 UID: 0 PID: 59939 Comm: iou-sqp-59938 Not tainted 6.12.0-rc3-00113-g8d020023b155 #7456 Hardware name: linux,dummy-virt (DT) pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : __might_sleep+0xf4/0x140 lr : __might_sleep+0xf4/0x140 sp : ffff80008c5e7830 x29: ffff80008c5e7830 x28: ffff0000d93088c0 x27: ffff60001c2d7230 x26: dfff800000000000 x25: ffff0000e16b9180 x24: ffff80008c5e7a50 x23: 1ffff000118bcf4a x22: ffff0000e16b9180 x21: ffff0000e16b9180 x20: 000000000000011b x19: ffff80008310fac0 x18: 1ffff000118bcd90 x17: 30303c5b20746120 x16: 74657320313d6574 x15: 0720072007200720 x14: 0720072007200720 x13: 0720072007200720 x12: ffff600036c64f0b x11: 1fffe00036c64f0a x10: ffff600036c64f0a x9 : dfff800000000000 x8 : 00009fffc939b0f6 x7 : ffff0001b6327853 x6 : 0000000000000001 x5 : ffff0001b6327850 x4 : ffff600036c64f0b x3 : ffff8000803c35bc x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000e16b9180 Call trace: __might_sleep+0xf4/0x140 mutex_lock+0x84/0x124 io_handle_tw_list+0xf4/0x260 tctx_task_work_run+0x94/0x340 io_run_task_work+0x1ec/0x3c0 io_uring_cancel_generic+0x364/0x524 io_sq_thread+0x820/0x124c ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50080", "url": "https://ubuntu.com/security/CVE-2024-50080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: don't allow user copy for unprivileged device UBLK_F_USER_COPY requires userspace to call write() on ublk char device for filling request buffer, and unprivileged device can't be trusted. So don't allow user copy for unprivileged device.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50081", "url": "https://ubuntu.com/security/CVE-2024-50081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-mq: setup queue ->tag_set before initializing hctx Commit 7b815817aa58 (\"blk-mq: add helper for checking if one CPU is mapped to specified hctx\") needs to check queue mapping via tag set in hctx's cpuhp handler. However, q->tag_set may not be setup yet when the cpuhp handler is enabled, then kernel oops is triggered. Fix the issue by setup queue tag_set before initializing hctx.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50082", "url": "https://ubuntu.com/security/CVE-2024-50082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race We're seeing crashes from rq_qos_wake_function that look like this: BUG: unable to handle page fault for address: ffffafe180a40084 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 100000067 P4D 100000067 PUD 10027c067 PMD 10115d067 PTE 0 Oops: Oops: 0002 [#1] PREEMPT SMP PTI CPU: 17 UID: 0 PID: 0 Comm: swapper/17 Not tainted 6.12.0-rc3-00013-geca631b8fe80 #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:_raw_spin_lock_irqsave+0x1d/0x40 Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 9c 41 5c fa 65 ff 05 62 97 30 4c 31 c0 ba 01 00 00 00 0f b1 17 75 0a 4c 89 e0 41 5c c3 cc cc cc cc 89 c6 e8 2c 0b 00 RSP: 0018:ffffafe180580ca0 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffffafe180a3f7a8 RCX: 0000000000000011 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffffafe180a40084 RBP: 0000000000000000 R08: 00000000001e7240 R09: 0000000000000011 R10: 0000000000000028 R11: 0000000000000888 R12: 0000000000000002 R13: ffffafe180a40084 R14: 0000000000000000 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff9aaf1f280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffafe180a40084 CR3: 000000010e428002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: try_to_wake_up+0x5a/0x6a0 rq_qos_wake_function+0x71/0x80 __wake_up_common+0x75/0xa0 __wake_up+0x36/0x60 scale_up.part.0+0x50/0x110 wb_timer_fn+0x227/0x450 ... So rq_qos_wake_function() calls wake_up_process(data->task), which calls try_to_wake_up(), which faults in raw_spin_lock_irqsave(&p->pi_lock). p comes from data->task, and data comes from the waitqueue entry, which is stored on the waiter's stack in rq_qos_wait(). Analyzing the core dump with drgn, I found that the waiter had already woken up and moved on to a completely unrelated code path, clobbering what was previously data->task. Meanwhile, the waker was passing the clobbered garbage in data->task to wake_up_process(), leading to the crash. What's happening is that in between rq_qos_wake_function() deleting the waitqueue entry and calling wake_up_process(), rq_qos_wait() is finding that it already got a token and returning. The race looks like this: rq_qos_wait() rq_qos_wake_function() ============================================================== prepare_to_wait_exclusive() data->got_token = true; list_del_init(&curr->entry); if (data.got_token) break; finish_wait(&rqw->wait, &data.wq); ^- returns immediately because list_empty_careful(&wq_entry->entry) is true ... return, go do something else ... wake_up_process(data->task) (NO LONGER VALID!)-^ Normally, finish_wait() is supposed to synchronize against the waker. But, as noted above, it is returning immediately because the waitqueue entry has already been removed from the waitqueue. The bug is that rq_qos_wake_function() is accessing the waitqueue entry AFTER deleting it. Note that autoremove_wake_function() wakes the waiter and THEN deletes the waitqueue entry, which is the proper order. Fix it by swapping the order. We also need to use list_del_init_careful() to match the list_empty_careful() in finish_wait().", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50101", "url": "https://ubuntu.com/security/CVE-2024-50101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI devices Previously, the domain_context_clear() function incorrectly called pci_for_each_dma_alias() to set up context entries for non-PCI devices. This could lead to kernel hangs or other unexpected behavior. Add a check to only call pci_for_each_dma_alias() for PCI devices. For non-PCI devices, domain_context_clear_one() is called directly.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50083", "url": "https://ubuntu.com/security/CVE-2024-50083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix mptcp DSS corruption due to large pmtu xmit Syzkaller was able to trigger a DSS corruption: TCP: request_sock_subflow_v4: Possible SYN flooding on port [::]:20002. Sending cookies. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 5227 at net/mptcp/protocol.c:695 __mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695 Modules linked in: CPU: 0 UID: 0 PID: 5227 Comm: syz-executor350 Not tainted 6.11.0-syzkaller-08829-gaf9c191ac2a0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:__mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695 Code: 0f b6 dc 31 ff 89 de e8 b5 dd ea f5 89 d8 48 81 c4 50 01 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 98 da ea f5 90 <0f> 0b 90 e9 47 ff ff ff e8 8a da ea f5 90 0f 0b 90 e9 99 e0 ff ff RSP: 0018:ffffc90000006db8 EFLAGS: 00010246 RAX: ffffffff8ba9df18 RBX: 00000000000055f0 RCX: ffff888030023c00 RDX: 0000000000000100 RSI: 00000000000081e5 RDI: 00000000000055f0 RBP: 1ffff110062bf1ae R08: ffffffff8ba9cf12 R09: 1ffff110062bf1b8 R10: dffffc0000000000 R11: ffffed10062bf1b9 R12: 0000000000000000 R13: dffffc0000000000 R14: 00000000700cec61 R15: 00000000000081e5 FS: 000055556679c380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020287000 CR3: 0000000077892000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: move_skbs_to_msk net/mptcp/protocol.c:811 [inline] mptcp_data_ready+0x29c/0xa90 net/mptcp/protocol.c:854 subflow_data_ready+0x34a/0x920 net/mptcp/subflow.c:1490 tcp_data_queue+0x20fd/0x76c0 net/ipv4/tcp_input.c:5283 tcp_rcv_established+0xfba/0x2020 net/ipv4/tcp_input.c:6237 tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915 tcp_v4_rcv+0x2dc0/0x37f0 net/ipv4/tcp_ipv4.c:2350 ip_protocol_deliver_rcu+0x22e/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x341/0x5f0 net/ipv4/ip_input.c:233 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314 __netif_receive_skb_one_core net/core/dev.c:5662 [inline] __netif_receive_skb+0x2bf/0x650 net/core/dev.c:5775 process_backlog+0x662/0x15b0 net/core/dev.c:6107 __napi_poll+0xcb/0x490 net/core/dev.c:6771 napi_poll net/core/dev.c:6840 [inline] net_rx_action+0x89b/0x1240 net/core/dev.c:6962 handle_softirqs+0x2c5/0x980 kernel/softirq.c:554 do_softirq+0x11b/0x1e0 kernel/softirq.c:455 __local_bh_enable_ip+0x1bb/0x200 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0x1764/0x3e80 net/core/dev.c:4451 dev_queue_xmit include/linux/netdevice.h:3094 [inline] neigh_hh_output include/net/neighbour.h:526 [inline] neigh_output include/net/neighbour.h:540 [inline] ip_finish_output2+0xd41/0x1390 net/ipv4/ip_output.c:236 ip_local_out net/ipv4/ip_output.c:130 [inline] __ip_queue_xmit+0x118c/0x1b80 net/ipv4/ip_output.c:536 __tcp_transmit_skb+0x2544/0x3b30 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_mtu_probe net/ipv4/tcp_output.c:2547 [inline] tcp_write_xmit+0x641d/0x6bf0 net/ipv4/tcp_output.c:2752 __tcp_push_pending_frames+0x9b/0x360 net/ipv4/tcp_output.c:3015 tcp_push_pending_frames include/net/tcp.h:2107 [inline] tcp_data_snd_check net/ipv4/tcp_input.c:5714 [inline] tcp_rcv_established+0x1026/0x2020 net/ipv4/tcp_input.c:6239 tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915 sk_backlog_rcv include/net/sock.h:1113 [inline] __release_sock+0x214/0x350 net/core/sock.c:3072 release_sock+0x61/0x1f0 net/core/sock.c:3626 mptcp_push_ ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50068", "url": "https://ubuntu.com/security/CVE-2024-50068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/tests/sysfs-kunit.h: fix memory leak in damon_sysfs_test_add_targets() The sysfs_target->regions allocated in damon_sysfs_regions_alloc() is not freed in damon_sysfs_test_add_targets(), which cause the following memory leak, free it to fix it. \tunreferenced object 0xffffff80c2a8db80 (size 96): \t comm \"kunit_try_catch\", pid 187, jiffies 4294894363 \t hex dump (first 32 bytes): \t 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ \t 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ \t backtrace (crc 0): \t [<0000000001e3714d>] kmemleak_alloc+0x34/0x40 \t [<000000008e6835c1>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000001286d9f8>] damon_sysfs_test_add_targets+0x1cc/0x738 \t [<0000000032ef8f77>] kunit_try_run_case+0x13c/0x3ac \t [<00000000f3edea23>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000adf936cf>] kthread+0x2e8/0x374 \t [<0000000041bb1628>] ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50199", "url": "https://ubuntu.com/security/CVE-2024-50199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/swapfile: skip HugeTLB pages for unuse_vma I got a bad pud error and lost a 1GB HugeTLB when calling swapoff. The problem can be reproduced by the following steps: 1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory. 2. Swapout the above anonymous memory. 3. run swapoff and we will get a bad pud error in kernel message: mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7) We can tell that pud_clear_bad is called by pud_none_or_clear_bad in unuse_pud_range() by ftrace. And therefore the HugeTLB pages will never be freed because we lost it from page table. We can skip HugeTLB pages for unuse_vma to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50066", "url": "https://ubuntu.com/security/CVE-2024-50066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mremap: fix move_normal_pmd/retract_page_tables race In mremap(), move_page_tables() looks at the type of the PMD entry and the specified address range to figure out by which method the next chunk of page table entries should be moved. At that point, the mmap_lock is held in write mode, but no rmap locks are held yet. For PMD entries that point to page tables and are fully covered by the source address range, move_pgt_entry(NORMAL_PMD, ...) is called, which first takes rmap locks, then does move_normal_pmd(). move_normal_pmd() takes the necessary page table locks at source and destination, then moves an entire page table from the source to the destination. The problem is: The rmap locks, which protect against concurrent page table removal by retract_page_tables() in the THP code, are only taken after the PMD entry has been read and it has been decided how to move it. So we can race as follows (with two processes that have mappings of the same tmpfs file that is stored on a tmpfs mount with huge=advise); note that process A accesses page tables through the MM while process B does it through the file rmap: process A process B ========= ========= mremap mremap_to move_vma move_page_tables get_old_pmd alloc_new_pmd *** PREEMPT *** madvise(MADV_COLLAPSE) do_madvise madvise_walk_vmas madvise_vma_behavior madvise_collapse hpage_collapse_scan_file collapse_file retract_page_tables i_mmap_lock_read(mapping) pmdp_collapse_flush i_mmap_unlock_read(mapping) move_pgt_entry(NORMAL_PMD, ...) take_rmap_locks move_normal_pmd drop_rmap_locks When this happens, move_normal_pmd() can end up creating bogus PMD entries in the line `pmd_populate(mm, new_pmd, pmd_pgtable(pmd))`. The effect depends on arch-specific and machine-specific details; on x86, you can end up with physical page 0 mapped as a page table, which is likely exploitable for user->kernel privilege escalation. Fix the race by letting process B recheck that the PMD still points to a page table after the rmap locks have been taken. Otherwise, we bail and let the caller fall back to the PTE-level copying path, which will then bail immediately at the pmd_none() check. Bug reachability: Reaching this bug requires that you can create shmem/file THP mappings - anonymous THP uses different code that doesn't zap stuff under rmap locks. File THP is gated on an experimental config flag (CONFIG_READ_ONLY_THP_FOR_FS), so on normal distro kernels you need shmem THP to hit this bug. As far as I know, getting shmem THP normally requires that you can mount your own tmpfs with the right mount flags, which would require creating your own user+mount namespace; though I don't know if some distros maybe enable shmem THP by default or something like that. Bug impact: This issue can likely be used for user->kernel privilege escalation when it is reachable.", "cve_priority": "medium", "cve_public_date": "2024-10-23 06:15:00 UTC" }, { "cve": "CVE-2024-50202", "url": "https://ubuntu.com/security/CVE-2024-50202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: propagate directory read errors from nilfs_find_entry() Syzbot reported that a task hang occurs in vcs_open() during a fuzzing test for nilfs2. The root cause of this problem is that in nilfs_find_entry(), which searches for directory entries, ignores errors when loading a directory page/folio via nilfs_get_folio() fails. If the filesystem images is corrupted, and the i_size of the directory inode is large, and the directory page/folio is successfully read but fails the sanity check, for example when it is zero-filled, nilfs_check_folio() may continue to spit out error messages in bursts. Fix this issue by propagating the error to the callers when loading a page/folio fails in nilfs_find_entry(). The current interface of nilfs_find_entry() and its callers is outdated and cannot propagate error codes such as -EIO and -ENOMEM returned via nilfs_find_entry(), so fix it together.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50200", "url": "https://ubuntu.com/security/CVE-2024-50200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: maple_tree: correct tree corruption on spanning store Patch series \"maple_tree: correct tree corruption on spanning store\", v3. There has been a nasty yet subtle maple tree corruption bug that appears to have been in existence since the inception of the algorithm. This bug seems far more likely to happen since commit f8d112a4e657 (\"mm/mmap: avoid zeroing vma tree in mmap_region()\"), which is the point at which reports started to be submitted concerning this bug. We were made definitely aware of the bug thanks to the kind efforts of Bert Karwatzki who helped enormously in my being able to track this down and identify the cause of it. The bug arises when an attempt is made to perform a spanning store across two leaf nodes, where the right leaf node is the rightmost child of the shared parent, AND the store completely consumes the right-mode node. This results in mas_wr_spanning_store() mitakenly duplicating the new and existing entries at the maximum pivot within the range, and thus maple tree corruption. The fix patch corrects this by detecting this scenario and disallowing the mistaken duplicate copy. The fix patch commit message goes into great detail as to how this occurs. This series also includes a test which reliably reproduces the issue, and asserts that the fix works correctly. Bert has kindly tested the fix and confirmed it resolved his issues. Also Mikhail Gavrilov kindly reported what appears to be precisely the same bug, which this fix should also resolve. This patch (of 2): There has been a subtle bug present in the maple tree implementation from its inception. This arises from how stores are performed - when a store occurs, it will overwrite overlapping ranges and adjust the tree as necessary to accommodate this. A range may always ultimately span two leaf nodes. In this instance we walk the two leaf nodes, determine which elements are not overwritten to the left and to the right of the start and end of the ranges respectively and then rebalance the tree to contain these entries and the newly inserted one. This kind of store is dubbed a 'spanning store' and is implemented by mas_wr_spanning_store(). In order to reach this stage, mas_store_gfp() invokes mas_wr_preallocate(), mas_wr_store_type() and mas_wr_walk() in turn to walk the tree and update the object (mas) to traverse to the location where the write should be performed, determining its store type. When a spanning store is required, this function returns false stopping at the parent node which contains the target range, and mas_wr_store_type() marks the mas->store_type as wr_spanning_store to denote this fact. When we go to perform the store in mas_wr_spanning_store(), we first determine the elements AFTER the END of the range we wish to store (that is, to the right of the entry to be inserted) - we do this by walking to the NEXT pivot in the tree (i.e. r_mas.last + 1), starting at the node we have just determined contains the range over which we intend to write. We then turn our attention to the entries to the left of the entry we are inserting, whose state is represented by l_mas, and copy these into a 'big node', which is a special node which contains enough slots to contain two leaf node's worth of data. We then copy the entry we wish to store immediately after this - the copy and the insertion of the new entry is performed by mas_store_b_node(). After this we copy the elements to the right of the end of the range which we are inserting, if we have not exceeded the length of the node (i.e. r_mas.offset <= r_mas.end). Herein lies the bug - under very specific circumstances, this logic can break and corrupt the maple tree. Consider the following tree: Height 0 Root Node / \\ pivot = 0xffff / \\ pivot = ULONG_MAX / ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50084", "url": "https://ubuntu.com/security/CVE-2024-50084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: microchip: vcap api: Fix memory leaks in vcap_api_encode_rule_test() Commit a3c1e45156ad (\"net: microchip: vcap: Fix use-after-free error in kunit test\") fixed the use-after-free error, but introduced below memory leaks by removing necessary vcap_free_rule(), add it to fix it. \tunreferenced object 0xffffff80ca58b700 (size 192): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898264 \t hex dump (first 32 bytes): \t 00 12 7a 00 05 00 00 00 0a 00 00 00 64 00 00 00 ..z.........d... \t 00 00 00 00 00 00 00 00 00 04 0b cc 80 ff ff ff ................ \t backtrace (crc 9c09c3fe): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<0000000040a01b8d>] vcap_alloc_rule+0x3cc/0x9c4 \t [<000000003fe86110>] vcap_api_encode_rule_test+0x1ac/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0400 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898265 \t hex dump (first 32 bytes): \t 80 04 0b cc 80 ff ff ff 18 b7 58 ca 80 ff ff ff ..........X..... \t 39 00 00 00 02 00 00 00 06 05 04 03 02 01 ff ff 9............... \t backtrace (crc daf014e9): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<00000000dfdb1e81>] vcap_api_encode_rule_test+0x224/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0700 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898265 \t hex dump (first 32 bytes): \t 80 07 0b cc 80 ff ff ff 28 b7 58 ca 80 ff ff ff ........(.X..... \t 3c 00 00 00 00 00 00 00 01 2f 03 b3 ec ff ff ff <......../...... \t backtrace (crc 8d877792): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000006eadfab7>] vcap_rule_add_action+0x2d0/0x52c \t [<00000000323475d1>] vcap_api_encode_rule_test+0x4d4/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0900 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898266 \t hex dump (first 32 bytes): \t 80 09 0b cc 80 ff ff ff 80 06 0b cc 80 ff ff ff ................ \t 7d 00 00 00 01 00 00 00 00 00 00 00 ff 00 00 00 }............... \t backtrace (crc 34181e56): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<00000000991e3564>] vcap_val_rule+0xcf0/0x13e8 \t [<00000000fc9868e5>] vcap_api_encode_rule_test+0x678/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0980 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898266 \t hex dump (first 32 bytes): \t 18 b7 58 ca 80 ff ff ff 00 09 0b cc 80 ff ff ff ..X............. \t 67 00 00 00 00 00 00 00 01 01 74 88 c0 ff ff ff g.........t..... \t backtrace (crc 275fd9be): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<000000001396a1a2>] test_add_de ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50194", "url": "https://ubuntu.com/security/CVE-2024-50194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Fix uprobes for big-endian kernels The arm64 uprobes code is broken for big-endian kernels as it doesn't convert the in-memory instruction encoding (which is always little-endian) into the kernel's native endianness before analyzing and simulating instructions. This may result in a few distinct problems: * The kernel may may erroneously reject probing an instruction which can safely be probed. * The kernel may erroneously erroneously permit stepping an instruction out-of-line when that instruction cannot be stepped out-of-line safely. * The kernel may erroneously simulate instruction incorrectly dur to interpretting the byte-swapped encoding. The endianness mismatch isn't caught by the compiler or sparse because: * The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so the compiler and sparse have no idea these contain a little-endian 32-bit value. The core uprobes code populates these with a memcpy() which similarly does not handle endianness. * While the uprobe_opcode_t type is an alias for __le32, both arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[] to the similarly-named probe_opcode_t, which is an alias for u32. Hence there is no endianness conversion warning. Fix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and adding the appropriate __le32_to_cpu() conversions prior to consuming the instruction encoding. The core uprobes copies these fields as opaque ranges of bytes, and so is unaffected by this change. At the same time, remove MAX_UINSN_BYTES and consistently use AARCH64_INSN_SIZE for clarity. Tested with the following: | #include | #include | | #define noinline __attribute__((noinline)) | | static noinline void *adrp_self(void) | { | void *addr; | | asm volatile( | \" adrp %x0, adrp_self\\n\" | \" add %x0, %x0, :lo12:adrp_self\\n\" | : \"=r\" (addr)); | } | | | int main(int argc, char *argv) | { | void *ptr = adrp_self(); | bool equal = (ptr == adrp_self); | | printf(\"adrp_self => %p\\n\" | \"adrp_self() => %p\\n\" | \"%s\\n\", | adrp_self, ptr, equal ? \"EQUAL\" : \"NOT EQUAL\"); | | return 0; | } .... where the adrp_self() function was compiled to: | 00000000004007e0 : | 4007e0: 90000000 adrp x0, 400000 <__ehdr_start> | 4007e4: 911f8000 add x0, x0, #0x7e0 | 4007e8: d65f03c0 ret Before this patch, the ADRP is not recognized, and is assumed to be steppable, resulting in corruption of the result: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0xffffffffff7e0 | NOT EQUAL After this patch, the ADRP is correctly recognized and simulated: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50099", "url": "https://ubuntu.com/security/CVE-2024-50099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Remove broken LDR (literal) uprobe support The simulate_ldr_literal() and simulate_ldrsw_literal() functions are unsafe to use for uprobes. Both functions were originally written for use with kprobes, and access memory with plain C accesses. When uprobes was added, these were reused unmodified even though they cannot safely access user memory. There are three key problems: 1) The plain C accesses do not have corresponding extable entries, and thus if they encounter a fault the kernel will treat these as unintentional accesses to user memory, resulting in a BUG() which will kill the kernel thread, and likely lead to further issues (e.g. lockup or panic()). 2) The plain C accesses are subject to HW PAN and SW PAN, and so when either is in use, any attempt to simulate an access to user memory will fault. Thus neither simulate_ldr_literal() nor simulate_ldrsw_literal() can do anything useful when simulating a user instruction on any system with HW PAN or SW PAN. 3) The plain C accesses are privileged, as they run in kernel context, and in practice can access a small range of kernel virtual addresses. The instructions they simulate have a range of +/-1MiB, and since the simulated instructions must itself be a user instructions in the TTBR0 address range, these can address the final 1MiB of the TTBR1 acddress range by wrapping downwards from an address in the first 1MiB of the TTBR0 address range. In contemporary kernels the last 8MiB of TTBR1 address range is reserved, and accesses to this will always fault, meaning this is no worse than (1). Historically, it was theoretically possible for the linear map or vmemmap to spill into the final 8MiB of the TTBR1 address range, but in practice this is extremely unlikely to occur as this would require either: * Having enough physical memory to fill the entire linear map all the way to the final 1MiB of the TTBR1 address range. * Getting unlucky with KASLR randomization of the linear map such that the populated region happens to overlap with the last 1MiB of the TTBR address range. ... and in either case if we were to spill into the final page there would be larger problems as the final page would alias with error pointers. Practically speaking, (1) and (2) are the big issues. Given there have been no reports of problems since the broken code was introduced, it appears that no-one is relying on probing these instructions with uprobes. Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW (literal), limiting the use of simulate_ldr_literal() and simulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR (literal) and LDRSW (literal) will be rejected as arm_probe_decode_insn() will return INSN_REJECTED. In future we can consider introducing working uprobes support for these instructions, but this will require more significant work.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50195", "url": "https://ubuntu.com/security/CVE-2024-50195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-clock: Fix missing timespec64 check in pc_clock_settime() As Andrew pointed out, it will make sense that the PTP core checked timespec64 struct's tv_sec and tv_nsec range before calling ptp->info->settime64(). As the man manual of clock_settime() said, if tp.tv_sec is negative or tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL, which include dynamic clocks which handles PTP clock, and the condition is consistent with timespec64_valid(). As Thomas suggested, timespec64_valid() only check the timespec is valid, but not ensure that the time is in a valid range, so check it ahead using timespec64_valid_strict() in pc_clock_settime() and return -EINVAL if not valid. There are some drivers that use tp->tv_sec and tp->tv_nsec directly to write registers without validity checks and assume that the higher layer has checked it, which is dangerous and will benefit from this, such as hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(), and some drivers can remove the checks of itself.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50085", "url": "https://ubuntu.com/security/CVE-2024-50085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: fix UaF read in mptcp_pm_nl_rm_addr_or_subflow Syzkaller reported this splat: ================================================================== BUG: KASAN: slab-use-after-free in mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881 Read of size 4 at addr ffff8880569ac858 by task syz.1.2799/14662 CPU: 0 UID: 0 PID: 14662 Comm: syz.1.2799 Not tainted 6.12.0-rc2-syzkaller-00307-g36c254515dc6 #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+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881 mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:914 [inline] mptcp_nl_remove_id_zero_address+0x305/0x4a0 net/mptcp/pm_netlink.c:1572 mptcp_pm_nl_del_addr_doit+0x5c9/0x770 net/mptcp/pm_netlink.c:1603 genl_family_rcv_msg_doit+0x202/0x2f0 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x565/0x800 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x165/0x410 net/netlink/af_netlink.c:2551 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1331 [inline] netlink_unicast+0x53c/0x7f0 net/netlink/af_netlink.c:1357 netlink_sendmsg+0x8b8/0xd70 net/netlink/af_netlink.c:1901 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg net/socket.c:744 [inline] ____sys_sendmsg+0x9ae/0xb40 net/socket.c:2607 ___sys_sendmsg+0x135/0x1e0 net/socket.c:2661 __sys_sendmsg+0x117/0x1f0 net/socket.c:2690 do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline] __do_fast_syscall_32+0x73/0x120 arch/x86/entry/common.c:386 do_fast_syscall_32+0x32/0x80 arch/x86/entry/common.c:411 entry_SYSENTER_compat_after_hwframe+0x84/0x8e RIP: 0023:0xf7fe4579 Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00 RSP: 002b:00000000f574556c EFLAGS: 00000296 ORIG_RAX: 0000000000000172 RAX: ffffffffffffffda RBX: 000000000000000b RCX: 0000000020000140 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000296 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Allocated by task 5387: 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 kmalloc_noprof include/linux/slab.h:878 [inline] kzalloc_noprof include/linux/slab.h:1014 [inline] subflow_create_ctx+0x87/0x2a0 net/mptcp/subflow.c:1803 subflow_ulp_init+0xc3/0x4d0 net/mptcp/subflow.c:1956 __tcp_set_ulp net/ipv4/tcp_ulp.c:146 [inline] tcp_set_ulp+0x326/0x7f0 net/ipv4/tcp_ulp.c:167 mptcp_subflow_create_socket+0x4ae/0x10a0 net/mptcp/subflow.c:1764 __mptcp_subflow_connect+0x3cc/0x1490 net/mptcp/subflow.c:1592 mptcp_pm_create_subflow_or_signal_addr+0xbda/0x23a0 net/mptcp/pm_netlink.c:642 mptcp_pm_nl_fully_established net/mptcp/pm_netlink.c:650 [inline] mptcp_pm_nl_work+0x3a1/0x4f0 net/mptcp/pm_netlink.c:943 mptcp_worker+0x15a/0x1240 net/mptcp/protocol.c:2777 process_one_work+0x958/0x1b30 kernel/workqueue.c:3229 process_scheduled_works kernel/workqueue.c:3310 [inline] worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/ke ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50086", "url": "https://ubuntu.com/security/CVE-2024-50086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix user-after-free from session log off There is racy issue between smb2 session log off and smb2 session setup. It will cause user-after-free from session log off. This add session_lock when setting SMB2_SESSION_EXPIRED and referece count to session struct not to free session while it is being used.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50087", "url": "https://ubuntu.com/security/CVE-2024-50087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix uninitialized pointer free on read_alloc_one_name() error The function read_alloc_one_name() does not initialize the name field of the passed fscrypt_str struct if kmalloc fails to allocate the corresponding buffer. Thus, it is not guaranteed that fscrypt_str.name is initialized when freeing it. This is a follow-up to the linked patch that fixes the remaining instances of the bug introduced by commit e43eec81c516 (\"btrfs: use struct qstr instead of name and namelen pairs\").", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50088", "url": "https://ubuntu.com/security/CVE-2024-50088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix uninitialized pointer free in add_inode_ref() The add_inode_ref() function does not initialize the \"name\" struct when it is declared. If any of the following calls to \"read_one_inode() returns NULL, \tdir = read_one_inode(root, parent_objectid); \tif (!dir) { \t\tret = -ENOENT; \t\tgoto out; \t} \tinode = read_one_inode(root, inode_objectid); \tif (!inode) { \t\tret = -EIO; \t\tgoto out; \t} then \"name.name\" would be freed on \"out\" before being initialized. out: \t... \tkfree(name.name); This issue was reported by Coverity with CID 1526744.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50182", "url": "https://ubuntu.com/security/CVE-2024-50182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: secretmem: disable memfd_secret() if arch cannot set direct map Return -ENOSYS from memfd_secret() syscall if !can_set_direct_map(). This is the case for example on some arm64 configurations, where marking 4k PTEs in the direct map not present can only be done if the direct map is set up at 4k granularity in the first place (as ARM's break-before-make semantics do not easily allow breaking apart large/gigantic pages). More precisely, on arm64 systems with !can_set_direct_map(), set_direct_map_invalid_noflush() is a no-op, however it returns success (0) instead of an error. This means that memfd_secret will seemingly \"work\" (e.g. syscall succeeds, you can mmap the fd and fault in pages), but it does not actually achieve its goal of removing its memory from the direct map. Note that with this patch, memfd_secret() will start erroring on systems where can_set_direct_map() returns false (arm64 with CONFIG_RODATA_FULL_DEFAULT_ENABLED=n, CONFIG_DEBUG_PAGEALLOC=n and CONFIG_KFENCE=n), but that still seems better than the current silent failure. Since CONFIG_RODATA_FULL_DEFAULT_ENABLED defaults to 'y', most arm64 systems actually have a working memfd_secret() and aren't be affected. From going through the iterations of the original memfd_secret patch series, it seems that disabling the syscall in these scenarios was the intended behavior [1] (preferred over having set_direct_map_invalid_noflush return an error as that would result in SIGBUSes at page-fault time), however the check for it got dropped between v16 [2] and v17 [3], when secretmem moved away from CMA allocations. [1]: https://lore.kernel.org/lkml/20201124164930.GK8537@kernel.org/ [2]: https://lore.kernel.org/lkml/20210121122723.3446-11-rppt@kernel.org/#t [3]: https://lore.kernel.org/lkml/20201125092208.12544-10-rppt@kernel.org/", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50019", "url": "https://ubuntu.com/security/CVE-2024-50019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kthread: unpark only parked kthread Calling into kthread unparking unconditionally is mostly harmless when the kthread is already unparked. The wake up is then simply ignored because the target is not in TASK_PARKED state. However if the kthread is per CPU, the wake up is preceded by a call to kthread_bind() which expects the task to be inactive and in TASK_PARKED state, which obviously isn't the case if it is unparked. As a result, calling kthread_stop() on an unparked per-cpu kthread triggers such a warning: \tWARNING: CPU: 0 PID: 11 at kernel/kthread.c:525 __kthread_bind_mask kernel/kthread.c:525 \t \t kthread_stop+0x17a/0x630 kernel/kthread.c:707 \t destroy_workqueue+0x136/0xc40 kernel/workqueue.c:5810 \t wg_destruct+0x1e2/0x2e0 drivers/net/wireguard/device.c:257 \t netdev_run_todo+0xe1a/0x1000 net/core/dev.c:10693 \t default_device_exit_batch+0xa14/0xa90 net/core/dev.c:11769 \t ops_exit_list net/core/net_namespace.c:178 [inline] \t cleanup_net+0x89d/0xcc0 net/core/net_namespace.c:640 \t process_one_work kernel/workqueue.c:3231 [inline] \t process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 \t worker_thread+0x86d/0xd70 kernel/workqueue.c:3393 \t kthread+0x2f0/0x390 kernel/kthread.c:389 \t ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 \t ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 \t Fix this with skipping unecessary unparking while stopping a kthread.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50096", "url": "https://ubuntu.com/security/CVE-2024-50096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/dmem: Fix vulnerability in migrate_to_ram upon copy error The `nouveau_dmem_copy_one` function ensures that the copy push command is sent to the device firmware but does not track whether it was executed successfully. In the case of a copy error (e.g., firmware or hardware failure), the copy push command will be sent via the firmware channel, and `nouveau_dmem_copy_one` will likely report success, leading to the `migrate_to_ram` function returning a dirty HIGH_USER page to the user. This can result in a security vulnerability, as a HIGH_USER page that may contain sensitive or corrupted data could be returned to the user. To prevent this vulnerability, we allocate a zero page. Thus, in case of an error, a non-dirty (zero) page will be returned to the user.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50020", "url": "https://ubuntu.com/security/CVE-2024-50020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix improper handling of refcount in ice_sriov_set_msix_vec_count() This patch addresses an issue with improper reference count handling in the ice_sriov_set_msix_vec_count() function. First, the function calls ice_get_vf_by_id(), which increments the reference count of the vf pointer. If the subsequent call to ice_get_vf_vsi() fails, the function currently returns an error without decrementing the reference count of the vf pointer, leading to a reference count leak. The correct behavior, as implemented in this patch, is to decrement the reference count using ice_put_vf(vf) before returning an error when vsi is NULL. Second, the function calls ice_sriov_get_irqs(), which sets vf->first_vector_idx. If this call returns a negative value, indicating an error, the function returns an error without decrementing the reference count of the vf pointer, resulting in another reference count leak. The patch addresses this by adding a call to ice_put_vf(vf) before returning an error when vf->first_vector_idx < 0. This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and identifying potential mismanagement of reference counts. In this case, the tool flagged the missing decrement operation as a potential issue, leading to this patch.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50021", "url": "https://ubuntu.com/security/CVE-2024-50021", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix improper handling of refcount in ice_dpll_init_rclk_pins() This patch addresses a reference count handling issue in the ice_dpll_init_rclk_pins() function. The function calls ice_dpll_get_pins(), which increments the reference count of the relevant resources. However, if the condition WARN_ON((!vsi || !vsi->netdev)) is met, the function currently returns an error without properly releasing the resources acquired by ice_dpll_get_pins(), leading to a reference count leak. To resolve this, the check has been moved to the top of the function. This ensures that the function verifies the state before any resources are acquired, avoiding the need for additional resource management in the error path. This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and detecting potential issues where resources are not properly managed. In this case, the tool flagged the missing release operation as a potential problem, which led to the development of this patch.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50022", "url": "https://ubuntu.com/security/CVE-2024-50022", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: device-dax: correct pgoff align in dax_set_mapping() pgoff should be aligned using ALIGN_DOWN() instead of ALIGN(). Otherwise, vmf->address not aligned to fault_size will be aligned to the next alignment, that can result in memory failure getting the wrong address. It's a subtle situation that only can be observed in page_mapped_in_vma() after the page is page fault handled by dev_dax_huge_fault. Generally, there is little chance to perform page_mapped_in_vma in dev-dax's page unless in specific error injection to the dax device to trigger an MCE - memory-failure. In that case, page_mapped_in_vma() will be triggered to determine which task is accessing the failure address and kill that task in the end. We used self-developed dax device (which is 2M aligned mapping) , to perform error injection to random address. It turned out that error injected to non-2M-aligned address was causing endless MCE until panic. Because page_mapped_in_vma() kept resulting wrong address and the task accessing the failure address was never killed properly: [ 3783.719419] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.049006] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.049190] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.448042] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.448186] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.792026] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.792179] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.162502] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.162633] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.461116] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.461247] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.764730] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.764859] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.042128] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.042259] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.464293] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.464423] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.818090] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.818217] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3787.085297] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3787.085424] Memory failure: 0x200c9742: recovery action for dax page: Recovered It took us several weeks to pinpoint this problem,  but we eventually used bpftrace to trace the page fault and mce address and successfully identified the issue. Joao added: ; Likely we never reproduce in production because we always pin : device-dax regions in the region align they provide (Qemu does : similarly with prealloc in hugetlb/file backed memory). I think this : bug requires that we touch *unpinned* device-dax regions unaligned to : the device-dax selected alignment (page size i.e. 4K/2M/1G)", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50185", "url": "https://ubuntu.com/security/CVE-2024-50185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: handle consistently DSS corruption Bugged peer implementation can send corrupted DSS options, consistently hitting a few warning in the data path. Use DEBUG_NET assertions, to avoid the splat on some builds and handle consistently the error, dumping related MIBs and performing fallback and/or reset according to the subflow type.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50023", "url": "https://ubuntu.com/security/CVE-2024-50023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: Remove LED entry from LEDs list on unregister Commit c938ab4da0eb (\"net: phy: Manual remove LEDs to ensure correct ordering\") correctly fixed a problem with using devm_ but missed removing the LED entry from the LEDs list. This cause kernel panic on specific scenario where the port for the PHY is torn down and up and the kmod for the PHY is removed. On setting the port down the first time, the assosiacted LEDs are correctly unregistered. The associated kmod for the PHY is now removed. The kmod is now added again and the port is now put up, the associated LED are registered again. On putting the port down again for the second time after these step, the LED list now have 4 elements. With the first 2 already unregistered previously and the 2 new one registered again. This cause a kernel panic as the first 2 element should have been removed. Fix this by correctly removing the element when LED is unregistered.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50024", "url": "https://ubuntu.com/security/CVE-2024-50024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: Fix an unsafe loop on the list The kernel may crash when deleting a genetlink family if there are still listeners for that family: Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c000000000c080bc] netlink_update_socket_mc+0x3c/0xc0 LR [c000000000c0f764] __netlink_clear_multicast_users+0x74/0xc0 Call Trace: __netlink_clear_multicast_users+0x74/0xc0 genl_unregister_family+0xd4/0x2d0 Change the unsafe loop on the list to a safe one, because inside the loop there is an element removal from this list.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50186", "url": "https://ubuntu.com/security/CVE-2024-50186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: explicitly clear the sk pointer, when pf->create fails We have recently noticed the exact same KASAN splat as in commit 6cd4a78d962b (\"net: do not leave a dangling sk pointer, when socket creation fails\"). The problem is that commit did not fully address the problem, as some pf->create implementations do not use sk_common_release in their error paths. For example, we can use the same reproducer as in the above commit, but changing ping to arping. arping uses AF_PACKET socket and if packet_create fails, it will just sk_free the allocated sk object. While we could chase all the pf->create implementations and make sure they NULL the freed sk object on error from the socket, we can't guarantee future protocols will not make the same mistake. So it is easier to just explicitly NULL the sk pointer upon return from pf->create in __sock_create. We do know that pf->create always releases the allocated sk object on error, so if the pointer is not NULL, it is definitely dangling.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50025", "url": "https://ubuntu.com/security/CVE-2024-50025", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: fnic: Move flush_work initialization out of if block After commit 379a58caa199 (\"scsi: fnic: Move fnic_fnic_flush_tx() to a work queue\"), it can happen that a work item is sent to an uninitialized work queue. This may has the effect that the item being queued is never actually queued, and any further actions depending on it will not proceed. The following warning is observed while the fnic driver is loaded: kernel: WARNING: CPU: 11 PID: 0 at ../kernel/workqueue.c:1524 __queue_work+0x373/0x410 kernel: kernel: queue_work_on+0x3a/0x50 kernel: fnic_wq_copy_cmpl_handler+0x54a/0x730 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: fnic_isr_msix_wq_copy+0x2d/0x60 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: __handle_irq_event_percpu+0x36/0x1a0 kernel: handle_irq_event_percpu+0x30/0x70 kernel: handle_irq_event+0x34/0x60 kernel: handle_edge_irq+0x7e/0x1a0 kernel: __common_interrupt+0x3b/0xb0 kernel: common_interrupt+0x58/0xa0 kernel: It has been observed that this may break the rediscovery of Fibre Channel devices after a temporary fabric failure. This patch fixes it by moving the work queue initialization out of an if block in fnic_probe().", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50026", "url": "https://ubuntu.com/security/CVE-2024-50026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: wd33c93: Don't use stale scsi_pointer value A regression was introduced with commit dbb2da557a6a (\"scsi: wd33c93: Move the SCSI pointer to private command data\") which results in an oops in wd33c93_intr(). That commit added the scsi_pointer variable and initialized it from hostdata->connected. However, during selection, hostdata->connected is not yet valid. Fix this by getting the current scsi_pointer from hostdata->selecting.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50027", "url": "https://ubuntu.com/security/CVE-2024-50027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: core: Free tzp copy along with the thermal zone The object pointed to by tz->tzp may still be accessed after being freed in thermal_zone_device_unregister(), so move the freeing of it to the point after the removal completion has been completed at which it cannot be accessed any more.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50028", "url": "https://ubuntu.com/security/CVE-2024-50028", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: core: Reference count the zone in thermal_zone_get_by_id() There are places in the thermal netlink code where nothing prevents the thermal zone object from going away while being accessed after it has been returned by thermal_zone_get_by_id(). To address this, make thermal_zone_get_by_id() get a reference on the thermal zone device object to be returned with the help of get_device(), under thermal_list_lock, and adjust all of its callers to this change with the help of the cleanup.h infrastructure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50029", "url": "https://ubuntu.com/security/CVE-2024-50029", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_conn: Fix UAF in hci_enhanced_setup_sync This checks if the ACL connection remains valid as it could be destroyed while hci_enhanced_setup_sync is pending on cmd_sync leading to the following trace: BUG: KASAN: slab-use-after-free in hci_enhanced_setup_sync+0x91b/0xa60 Read of size 1 at addr ffff888002328ffd by task kworker/u5:2/37 CPU: 0 UID: 0 PID: 37 Comm: kworker/u5:2 Not tainted 6.11.0-rc6-01300-g810be445d8d6 #7099 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Workqueue: hci0 hci_cmd_sync_work Call Trace: dump_stack_lvl+0x5d/0x80 ? hci_enhanced_setup_sync+0x91b/0xa60 print_report+0x152/0x4c0 ? hci_enhanced_setup_sync+0x91b/0xa60 ? __virt_addr_valid+0x1fa/0x420 ? hci_enhanced_setup_sync+0x91b/0xa60 kasan_report+0xda/0x1b0 ? hci_enhanced_setup_sync+0x91b/0xa60 hci_enhanced_setup_sync+0x91b/0xa60 ? __pfx_hci_enhanced_setup_sync+0x10/0x10 ? __pfx___mutex_lock+0x10/0x10 hci_cmd_sync_work+0x1c2/0x330 process_one_work+0x7d9/0x1360 ? __pfx_lock_acquire+0x10/0x10 ? __pfx_process_one_work+0x10/0x10 ? assign_work+0x167/0x240 worker_thread+0x5b7/0xf60 ? __kthread_parkme+0xac/0x1c0 ? __pfx_worker_thread+0x10/0x10 ? __pfx_worker_thread+0x10/0x10 kthread+0x293/0x360 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2f/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 34: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __hci_conn_add+0x187/0x17d0 hci_connect_sco+0x2e1/0xb90 sco_sock_connect+0x2a2/0xb80 __sys_connect+0x227/0x2a0 __x64_sys_connect+0x6d/0xb0 do_syscall_64+0x71/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 37: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x101/0x160 kfree+0xd0/0x250 device_release+0x9a/0x210 kobject_put+0x151/0x280 hci_conn_del+0x448/0xbf0 hci_abort_conn_sync+0x46f/0x980 hci_cmd_sync_work+0x1c2/0x330 process_one_work+0x7d9/0x1360 worker_thread+0x5b7/0xf60 kthread+0x293/0x360 ret_from_fork+0x2f/0x70 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50030", "url": "https://ubuntu.com/security/CVE-2024-50030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/ct: prevent UAF in send_recv() Ensure we serialize with completion side to prevent UAF with fence going out of scope on the stack, since we have no clue if it will fire after the timeout before we can erase from the xa. Also we have some dependent loads and stores for which we need the correct ordering, and we lack the needed barriers. Fix this by grabbing the ct->lock after the wait, which is also held by the completion side. v2 (Badal): - Also print done after acquiring the lock and seeing timeout. (cherry picked from commit 52789ce35c55ccd30c4b67b9cc5b2af55e0122ea)", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50187", "url": "https://ubuntu.com/security/CVE-2024-50187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Stop the active perfmon before being destroyed Upon closing the file descriptor, the active performance monitor is not stopped. Although all perfmons are destroyed in `vc4_perfmon_close_file()`, the active performance monitor's pointer (`vc4->active_perfmon`) is still retained. If we open a new file descriptor and submit a few jobs with performance monitors, the driver will attempt to stop the active performance monitor using the stale pointer in `vc4->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50031", "url": "https://ubuntu.com/security/CVE-2024-50031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Stop the active perfmon before being destroyed When running `kmscube` with one or more performance monitors enabled via `GALLIUM_HUD`, the following kernel panic can occur: [ 55.008324] Unable to handle kernel paging request at virtual address 00000000052004a4 [ 55.008368] Mem abort info: [ 55.008377] ESR = 0x0000000096000005 [ 55.008387] EC = 0x25: DABT (current EL), IL = 32 bits [ 55.008402] SET = 0, FnV = 0 [ 55.008412] EA = 0, S1PTW = 0 [ 55.008421] FSC = 0x05: level 1 translation fault [ 55.008434] Data abort info: [ 55.008442] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 55.008455] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 55.008467] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 55.008481] user pgtable: 4k pages, 39-bit VAs, pgdp=00000001046c6000 [ 55.008497] [00000000052004a4] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 55.008525] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP [ 55.008542] Modules linked in: rfcomm [...] vc4 v3d snd_soc_hdmi_codec drm_display_helper gpu_sched drm_shmem_helper cec drm_dma_helper drm_kms_helper i2c_brcmstb drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight [ 55.008799] CPU: 2 PID: 166 Comm: v3d_bin Tainted: G C 6.6.47+rpt-rpi-v8 #1 Debian 1:6.6.47-1+rpt1 [ 55.008824] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [ 55.008838] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 55.008855] pc : __mutex_lock.constprop.0+0x90/0x608 [ 55.008879] lr : __mutex_lock.constprop.0+0x58/0x608 [ 55.008895] sp : ffffffc080673cf0 [ 55.008904] x29: ffffffc080673cf0 x28: 0000000000000000 x27: ffffff8106188a28 [ 55.008926] x26: ffffff8101e78040 x25: ffffff8101baa6c0 x24: ffffffd9d989f148 [ 55.008947] x23: ffffffda1c2a4008 x22: 0000000000000002 x21: ffffffc080673d38 [ 55.008968] x20: ffffff8101238000 x19: ffffff8104f83188 x18: 0000000000000000 [ 55.008988] x17: 0000000000000000 x16: ffffffda1bd04d18 x15: 00000055bb08bc90 [ 55.009715] x14: 0000000000000000 x13: 0000000000000000 x12: ffffffda1bd4cbb0 [ 55.010433] x11: 00000000fa83b2da x10: 0000000000001a40 x9 : ffffffda1bd04d04 [ 55.011162] x8 : ffffff8102097b80 x7 : 0000000000000000 x6 : 00000000030a5857 [ 55.011880] x5 : 00ffffffffffffff x4 : 0300000005200470 x3 : 0300000005200470 [ 55.012598] x2 : ffffff8101238000 x1 : 0000000000000021 x0 : 0300000005200470 [ 55.013292] Call trace: [ 55.013959] __mutex_lock.constprop.0+0x90/0x608 [ 55.014646] __mutex_lock_slowpath+0x1c/0x30 [ 55.015317] mutex_lock+0x50/0x68 [ 55.015961] v3d_perfmon_stop+0x40/0xe0 [v3d] [ 55.016627] v3d_bin_job_run+0x10c/0x2d8 [v3d] [ 55.017282] drm_sched_main+0x178/0x3f8 [gpu_sched] [ 55.017921] kthread+0x11c/0x128 [ 55.018554] ret_from_fork+0x10/0x20 [ 55.019168] Code: f9400260 f1001c1f 54001ea9 927df000 (b9403401) [ 55.019776] ---[ end trace 0000000000000000 ]--- [ 55.020411] note: v3d_bin[166] exited with preempt_count 1 This issue arises because, upon closing the file descriptor (which happens when we interrupt `kmscube`), the active performance monitor is not stopped. Although all perfmons are destroyed in `v3d_perfmon_close_file()`, the active performance monitor's pointer (`v3d->active_perfmon`) is still retained. If `kmscube` is run again, the driver will attempt to stop the active performance monitor using the stale pointer in `v3d->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50189", "url": "https://ubuntu.com/security/CVE-2024-50189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: amd_sfh: Switch to device-managed dmam_alloc_coherent() Using the device-managed version allows to simplify clean-up in probe() error path. Additionally, this device-managed ensures proper cleanup, which helps to resolve memory errors, page faults, btrfs going read-only, and btrfs disk corruption.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50033", "url": "https://ubuntu.com/security/CVE-2024-50033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slip: make slhc_remember() more robust against malicious packets syzbot found that slhc_remember() was missing checks against malicious packets [1]. slhc_remember() only checked the size of the packet was at least 20, which is not good enough. We need to make sure the packet includes the IPv4 and TCP header that are supposed to be carried. Add iph and th pointers to make the code more readable. [1] BUG: KMSAN: uninit-value in slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 ppp_receive_nonmp_frame+0xe45/0x35e0 drivers/net/ppp/ppp_generic.c:2455 ppp_receive_frame drivers/net/ppp/ppp_generic.c:2372 [inline] ppp_do_recv+0x65f/0x40d0 drivers/net/ppp/ppp_generic.c:2212 ppp_input+0x7dc/0xe60 drivers/net/ppp/ppp_generic.c:2327 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 Uninit was created at: slab_post_alloc_hook mm/slub.c:4091 [inline] slab_alloc_node mm/slub.c:4134 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 CPU: 0 UID: 0 PID: 5460 Comm: syz.2.33 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50034", "url": "https://ubuntu.com/security/CVE-2024-50034", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix lacks of icsk_syn_mss with IPPROTO_SMC Eric report a panic on IPPROTO_SMC, and give the facts that when INET_PROTOSW_ICSK was set, icsk->icsk_sync_mss must be set too. Bug: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000086000005 EC = 0x21: IABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault user pgtable: 4k pages, 48-bit VAs, pgdp=00000001195d1000 [0000000000000000] pgd=0800000109c46003, p4d=0800000109c46003, pud=0000000000000000 Internal error: Oops: 0000000086000005 [#1] PREEMPT SMP Modules linked in: CPU: 1 UID: 0 PID: 8037 Comm: syz.3.265 Not tainted 6.11.0-rc7-syzkaller-g5f5673607153 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0x0 lr : cipso_v4_sock_setattr+0x2a8/0x3c0 net/ipv4/cipso_ipv4.c:1910 sp : ffff80009b887a90 x29: ffff80009b887aa0 x28: ffff80008db94050 x27: 0000000000000000 x26: 1fffe0001aa6f5b3 x25: dfff800000000000 x24: ffff0000db75da00 x23: 0000000000000000 x22: ffff0000d8b78518 x21: 0000000000000000 x20: ffff0000d537ad80 x19: ffff0000d8b78000 x18: 1fffe000366d79ee x17: ffff8000800614a8 x16: ffff800080569b84 x15: 0000000000000001 x14: 000000008b336894 x13: 00000000cd96feaa x12: 0000000000000003 x11: 0000000000040000 x10: 00000000000020a3 x9 : 1fffe0001b16f0f1 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 000000000000003f x5 : 0000000000000040 x4 : 0000000000000001 x3 : 0000000000000000 x2 : 0000000000000002 x1 : 0000000000000000 x0 : ffff0000d8b78000 Call trace: 0x0 netlbl_sock_setattr+0x2e4/0x338 net/netlabel/netlabel_kapi.c:1000 smack_netlbl_add+0xa4/0x154 security/smack/smack_lsm.c:2593 smack_socket_post_create+0xa8/0x14c security/smack/smack_lsm.c:2973 security_socket_post_create+0x94/0xd4 security/security.c:4425 __sock_create+0x4c8/0x884 net/socket.c:1587 sock_create net/socket.c:1622 [inline] __sys_socket_create net/socket.c:1659 [inline] __sys_socket+0x134/0x340 net/socket.c:1706 __do_sys_socket net/socket.c:1720 [inline] __se_sys_socket net/socket.c:1718 [inline] __arm64_sys_socket+0x7c/0x94 net/socket.c:1718 __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:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 Code: ???????? ???????? ???????? ???????? (????????) ---[ end trace 0000000000000000 ]--- This patch add a toy implementation that performs a simple return to prevent such panic. This is because MSS can be set in sock_create_kern or smc_setsockopt, similar to how it's done in AF_SMC. However, for AF_SMC, there is currently no way to synchronize MSS within __sys_connect_file. This toy implementation lays the groundwork for us to support such feature for IPPROTO_SMC in the future.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50035", "url": "https://ubuntu.com/security/CVE-2024-50035", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: fix ppp_async_encode() illegal access syzbot reported an issue in ppp_async_encode() [1] In this case, pppoe_sendmsg() is called with a zero size. Then ppp_async_encode() is called with an empty skb. BUG: KMSAN: uninit-value in ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] BUG: KMSAN: uninit-value in ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_send+0x130/0x1b0 drivers/net/ppp/ppp_async.c:634 ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2280 [inline] ppp_input+0x1f1/0xe60 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 Uninit was created at: slab_post_alloc_hook mm/slub.c:4092 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4187 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 CPU: 1 UID: 0 PID: 5411 Comm: syz.1.14 Not tainted 6.12.0-rc1-syzkaller-00165-g360c1f1f24c6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50036", "url": "https://ubuntu.com/security/CVE-2024-50036", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: do not delay dst_entries_add() in dst_release() dst_entries_add() uses per-cpu data that might be freed at netns dismantle from ip6_route_net_exit() calling dst_entries_destroy() Before ip6_route_net_exit() can be called, we release all the dsts associated with this netns, via calls to dst_release(), which waits an rcu grace period before calling dst_destroy() dst_entries_add() use in dst_destroy() is racy, because dst_entries_destroy() could have been called already. Decrementing the number of dsts must happen sooner. Notes: 1) in CONFIG_XFRM case, dst_destroy() can call dst_release_immediate(child), this might also cause UAF if the child does not have DST_NOCOUNT set. IPSEC maintainers might take a look and see how to address this. 2) There is also discussion about removing this count of dst, which might happen in future kernels.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50037", "url": "https://ubuntu.com/security/CVE-2024-50037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/fbdev-dma: Only cleanup deferred I/O if necessary Commit 5a498d4d06d6 (\"drm/fbdev-dma: Only install deferred I/O if necessary\") initializes deferred I/O only if it is used. drm_fbdev_dma_fb_destroy() however calls fb_deferred_io_cleanup() unconditionally with struct fb_info.fbdefio == NULL. KASAN with the out-of-tree Apple silicon display driver posts following warning from __flush_work() of a random struct work_struct instead of the expected NULL pointer derefs. [ 22.053799] ------------[ cut here ]------------ [ 22.054832] WARNING: CPU: 2 PID: 1 at kernel/workqueue.c:4177 __flush_work+0x4d8/0x580 [ 22.056597] Modules linked in: uhid bnep uinput nls_ascii ip6_tables ip_tables i2c_dev loop fuse dm_multipath nfnetlink zram hid_magicmouse btrfs xor xor_neon brcmfmac_wcc raid6_pq hci_bcm4377 bluetooth brcmfmac hid_apple brcmutil nvmem_spmi_mfd simple_mfd_spmi dockchannel_hid cfg80211 joydev regmap_spmi nvme_apple ecdh_generic ecc macsmc_hid rfkill dwc3 appledrm snd_soc_macaudio macsmc_power nvme_core apple_isp phy_apple_atc apple_sart apple_rtkit_helper apple_dockchannel tps6598x macsmc_hwmon snd_soc_cs42l84 videobuf2_v4l2 spmi_apple_controller nvmem_apple_efuses videobuf2_dma_sg apple_z2 videobuf2_memops spi_nor panel_summit videobuf2_common asahi videodev pwm_apple apple_dcp snd_soc_apple_mca apple_admac spi_apple clk_apple_nco i2c_pasemi_platform snd_pcm_dmaengine mc i2c_pasemi_core mux_core ofpart adpdrm drm_dma_helper apple_dart apple_soc_cpufreq leds_pwm phram [ 22.073768] CPU: 2 UID: 0 PID: 1 Comm: systemd-shutdow Not tainted 6.11.2-asahi+ #asahi-dev [ 22.075612] Hardware name: Apple MacBook Pro (13-inch, M2, 2022) (DT) [ 22.077032] pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 22.078567] pc : __flush_work+0x4d8/0x580 [ 22.079471] lr : __flush_work+0x54/0x580 [ 22.080345] sp : ffffc000836ef820 [ 22.081089] x29: ffffc000836ef880 x28: 0000000000000000 x27: ffff80002ddb7128 [ 22.082678] x26: dfffc00000000000 x25: 1ffff000096f0c57 x24: ffffc00082d3e358 [ 22.084263] x23: ffff80004b7862b8 x22: dfffc00000000000 x21: ffff80005aa1d470 [ 22.085855] x20: ffff80004b786000 x19: ffff80004b7862a0 x18: 0000000000000000 [ 22.087439] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000005 [ 22.089030] x14: 1ffff800106ddf0a x13: 0000000000000000 x12: 0000000000000000 [ 22.090618] x11: ffffb800106ddf0f x10: dfffc00000000000 x9 : 1ffff800106ddf0e [ 22.092206] x8 : 0000000000000000 x7 : aaaaaaaaaaaaaaaa x6 : 0000000000000001 [ 22.093790] x5 : ffffc000836ef728 x4 : 0000000000000000 x3 : 0000000000000020 [ 22.095368] x2 : 0000000000000008 x1 : 00000000000000aa x0 : 0000000000000000 [ 22.096955] Call trace: [ 22.097505] __flush_work+0x4d8/0x580 [ 22.098330] flush_delayed_work+0x80/0xb8 [ 22.099231] fb_deferred_io_cleanup+0x3c/0x130 [ 22.100217] drm_fbdev_dma_fb_destroy+0x6c/0xe0 [drm_dma_helper] [ 22.101559] unregister_framebuffer+0x210/0x2f0 [ 22.102575] drm_fb_helper_unregister_info+0x48/0x60 [ 22.103683] drm_fbdev_dma_client_unregister+0x4c/0x80 [drm_dma_helper] [ 22.105147] drm_client_dev_unregister+0x1cc/0x230 [ 22.106217] drm_dev_unregister+0x58/0x570 [ 22.107125] apple_drm_unbind+0x50/0x98 [appledrm] [ 22.108199] component_del+0x1f8/0x3a8 [ 22.109042] dcp_platform_shutdown+0x24/0x38 [apple_dcp] [ 22.110357] platform_shutdown+0x70/0x90 [ 22.111219] device_shutdown+0x368/0x4d8 [ 22.112095] kernel_restart+0x6c/0x1d0 [ 22.112946] __arm64_sys_reboot+0x1c8/0x328 [ 22.113868] invoke_syscall+0x78/0x1a8 [ 22.114703] do_el0_svc+0x124/0x1a0 [ 22.115498] el0_svc+0x3c/0xe0 [ 22.116181] el0t_64_sync_handler+0x70/0xc0 [ 22.117110] el0t_64_sync+0x190/0x198 [ 22.117931] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50092", "url": "https://ubuntu.com/security/CVE-2024-50092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netconsole: fix wrong warning A warning is triggered when there is insufficient space in the buffer for userdata. However, this is not an issue since userdata will be sent in the next iteration. Current warning message: ------------[ cut here ]------------ WARNING: CPU: 13 PID: 3013042 at drivers/net/netconsole.c:1122 write_ext_msg+0x3b6/0x3d0 ? write_ext_msg+0x3b6/0x3d0 console_flush_all+0x1e9/0x330 The code incorrectly issues a warning when this_chunk is zero, which is a valid scenario. The warning should only be triggered when this_chunk is negative.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50038", "url": "https://ubuntu.com/security/CVE-2024-50038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xtables: avoid NFPROTO_UNSPEC where needed syzbot managed to call xt_cluster match via ebtables: WARNING: CPU: 0 PID: 11 at net/netfilter/xt_cluster.c:72 xt_cluster_mt+0x196/0x780 [..] ebt_do_table+0x174b/0x2a40 Module registers to NFPROTO_UNSPEC, but it assumes ipv4/ipv6 packet processing. As this is only useful to restrict locally terminating TCP/UDP traffic, register this for ipv4 and ipv6 family only. Pablo points out that this is a general issue, direct users of the set/getsockopt interface can call into targets/matches that were only intended for use with ip(6)tables. Check all UNSPEC matches and targets for similar issues: - matches and targets are fine except if they assume skb_network_header() is valid -- this is only true when called from inet layer: ip(6) stack pulls the ip/ipv6 header into linear data area. - targets that return XT_CONTINUE or other xtables verdicts must be restricted too, they are incompatbile with the ebtables traverser, e.g. EBT_CONTINUE is a completely different value than XT_CONTINUE. Most matches/targets are changed to register for NFPROTO_IPV4/IPV6, as they are provided for use by ip(6)tables. The MARK target is also used by arptables, so register for NFPROTO_ARP too. While at it, bail out if connbytes fails to enable the corresponding conntrack family. This change passes the selftests in iptables.git.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50039", "url": "https://ubuntu.com/security/CVE-2024-50039", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: accept TCA_STAB only for root qdisc Most qdiscs maintain their backlog using qdisc_pkt_len(skb) on the assumption it is invariant between the enqueue() and dequeue() handlers. Unfortunately syzbot can crash a host rather easily using a TBF + SFQ combination, with an STAB on SFQ [1] We can't support TCA_STAB on arbitrary level, this would require to maintain per-qdisc storage. [1] [ 88.796496] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 88.798611] #PF: supervisor read access in kernel mode [ 88.799014] #PF: error_code(0x0000) - not-present page [ 88.799506] PGD 0 P4D 0 [ 88.799829] Oops: Oops: 0000 [#1] SMP NOPTI [ 88.800569] CPU: 14 UID: 0 PID: 2053 Comm: b371744477 Not tainted 6.12.0-rc1-virtme #1117 [ 88.801107] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 88.801779] RIP: 0010:sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq [ 88.802544] Code: 0f b7 50 12 48 8d 04 d5 00 00 00 00 48 89 d6 48 29 d0 48 8b 91 c0 01 00 00 48 c1 e0 03 48 01 c2 66 83 7a 1a 00 7e c0 48 8b 3a <4c> 8b 07 4c 89 02 49 89 50 08 48 c7 47 08 00 00 00 00 48 c7 07 00 All code ======== 0:\t0f b7 50 12 \tmovzwl 0x12(%rax),%edx 4:\t48 8d 04 d5 00 00 00 \tlea 0x0(,%rdx,8),%rax b:\t00 c:\t48 89 d6 \tmov %rdx,%rsi f:\t48 29 d0 \tsub %rdx,%rax 12:\t48 8b 91 c0 01 00 00 \tmov 0x1c0(%rcx),%rdx 19:\t48 c1 e0 03 \tshl $0x3,%rax 1d:\t48 01 c2 \tadd %rax,%rdx 20:\t66 83 7a 1a 00 \tcmpw $0x0,0x1a(%rdx) 25:\t7e c0 \tjle 0xffffffffffffffe7 27:\t48 8b 3a \tmov (%rdx),%rdi 2a:*\t4c 8b 07 \tmov (%rdi),%r8\t\t<-- trapping instruction 2d:\t4c 89 02 \tmov %r8,(%rdx) 30:\t49 89 50 08 \tmov %rdx,0x8(%r8) 34:\t48 c7 47 08 00 00 00 \tmovq $0x0,0x8(%rdi) 3b:\t00 3c:\t48 \trex.W 3d:\tc7 \t.byte 0xc7 3e:\t07 \t(bad) \t... Code starting with the faulting instruction =========================================== 0:\t4c 8b 07 \tmov (%rdi),%r8 3:\t4c 89 02 \tmov %r8,(%rdx) 6:\t49 89 50 08 \tmov %rdx,0x8(%r8) a:\t48 c7 47 08 00 00 00 \tmovq $0x0,0x8(%rdi) 11:\t00 12:\t48 \trex.W 13:\tc7 \t.byte 0xc7 14:\t07 \t(bad) \t... [ 88.803721] RSP: 0018:ffff9a1f892b7d58 EFLAGS: 00000206 [ 88.804032] RAX: 0000000000000000 RBX: ffff9a1f8420c800 RCX: ffff9a1f8420c800 [ 88.804560] RDX: ffff9a1f81bc1440 RSI: 0000000000000000 RDI: 0000000000000000 [ 88.805056] RBP: ffffffffc04bb0e0 R08: 0000000000000001 R09: 00000000ff7f9a1f [ 88.805473] R10: 000000000001001b R11: 0000000000009a1f R12: 0000000000000140 [ 88.806194] R13: 0000000000000001 R14: ffff9a1f886df400 R15: ffff9a1f886df4ac [ 88.806734] FS: 00007f445601a740(0000) GS:ffff9a2e7fd80000(0000) knlGS:0000000000000000 [ 88.807225] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 88.807672] CR2: 0000000000000000 CR3: 000000050cc46000 CR4: 00000000000006f0 [ 88.808165] Call Trace: [ 88.808459] [ 88.808710] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434) [ 88.809261] ? page_fault_oops (arch/x86/mm/fault.c:715) [ 88.809561] ? exc_page_fault (./arch/x86/include/asm/irqflags.h:26 ./arch/x86/include/asm/irqflags.h:87 ./arch/x86/include/asm/irqflags.h:147 arch/x86/mm/fault.c:1489 arch/x86/mm/fault.c:1539) [ 88.809806] ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623) [ 88.810074] ? sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq [ 88.810411] sfq_reset (net/sched/sch_sfq.c:525) sch_sfq [ 88.810671] qdisc_reset (./include/linux/skbuff.h:2135 ./include/linux/skbuff.h:2441 ./include/linux/skbuff.h:3304 ./include/linux/skbuff.h:3310 net/sched/sch_g ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50040", "url": "https://ubuntu.com/security/CVE-2024-50040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: igb: Do not bring the device up after non-fatal error Commit 004d25060c78 (\"igb: Fix igb_down hung on surprise removal\") changed igb_io_error_detected() to ignore non-fatal pcie errors in order to avoid hung task that can happen when igb_down() is called multiple times. This caused an issue when processing transient non-fatal errors. igb_io_resume(), which is called after igb_io_error_detected(), assumes that device is brought down by igb_io_error_detected() if the interface is up. This resulted in panic with stacktrace below. [ T3256] igb 0000:09:00.0 haeth0: igb: haeth0 NIC Link is Down [ T292] pcieport 0000:00:1c.5: AER: Uncorrected (Non-Fatal) error received: 0000:09:00.0 [ T292] igb 0000:09:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, (Requester ID) [ T292] igb 0000:09:00.0: device [8086:1537] error status/mask=00004000/00000000 [ T292] igb 0000:09:00.0: [14] CmpltTO [ 200.105524,009][ T292] igb 0000:09:00.0: AER: TLP Header: 00000000 00000000 00000000 00000000 [ T292] pcieport 0000:00:1c.5: AER: broadcast error_detected message [ T292] igb 0000:09:00.0: Non-correctable non-fatal error reported. [ T292] pcieport 0000:00:1c.5: AER: broadcast mmio_enabled message [ T292] pcieport 0000:00:1c.5: AER: broadcast resume message [ T292] ------------[ cut here ]------------ [ T292] kernel BUG at net/core/dev.c:6539! [ T292] invalid opcode: 0000 [#1] PREEMPT SMP [ T292] RIP: 0010:napi_enable+0x37/0x40 [ T292] Call Trace: [ T292] [ T292] ? die+0x33/0x90 [ T292] ? do_trap+0xdc/0x110 [ T292] ? napi_enable+0x37/0x40 [ T292] ? do_error_trap+0x70/0xb0 [ T292] ? napi_enable+0x37/0x40 [ T292] ? napi_enable+0x37/0x40 [ T292] ? exc_invalid_op+0x4e/0x70 [ T292] ? napi_enable+0x37/0x40 [ T292] ? asm_exc_invalid_op+0x16/0x20 [ T292] ? napi_enable+0x37/0x40 [ T292] igb_up+0x41/0x150 [ T292] igb_io_resume+0x25/0x70 [ T292] report_resume+0x54/0x70 [ T292] ? report_frozen_detected+0x20/0x20 [ T292] pci_walk_bus+0x6c/0x90 [ T292] ? aer_print_port_info+0xa0/0xa0 [ T292] pcie_do_recovery+0x22f/0x380 [ T292] aer_process_err_devices+0x110/0x160 [ T292] aer_isr+0x1c1/0x1e0 [ T292] ? disable_irq_nosync+0x10/0x10 [ T292] irq_thread_fn+0x1a/0x60 [ T292] irq_thread+0xe3/0x1a0 [ T292] ? irq_set_affinity_notifier+0x120/0x120 [ T292] ? irq_affinity_notify+0x100/0x100 [ T292] kthread+0xe2/0x110 [ T292] ? kthread_complete_and_exit+0x20/0x20 [ T292] ret_from_fork+0x2d/0x50 [ T292] ? kthread_complete_and_exit+0x20/0x20 [ T292] ret_from_fork_asm+0x11/0x20 [ T292] To fix this issue igb_io_resume() checks if the interface is running and the device is not down this means igb_io_error_detected() did not bring the device down and there is no need to bring it up.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50041", "url": "https://ubuntu.com/security/CVE-2024-50041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: Fix macvlan leak by synchronizing access to mac_filter_hash This patch addresses a macvlan leak issue in the i40e driver caused by concurrent access to vsi->mac_filter_hash. The leak occurs when multiple threads attempt to modify the mac_filter_hash simultaneously, leading to inconsistent state and potential memory leaks. To fix this, we now wrap the calls to i40e_del_mac_filter() and zeroing vf->default_lan_addr.addr with spin_lock/unlock_bh(&vsi->mac_filter_hash_lock), ensuring atomic operations and preventing concurrent access. Additionally, we add lockdep_assert_held(&vsi->mac_filter_hash_lock) in i40e_add_mac_filter() to help catch similar issues in the future. Reproduction steps: 1. Spawn VFs and configure port vlan on them. 2. Trigger concurrent macvlan operations (e.g., adding and deleting \tportvlan and/or mac filters). 3. Observe the potential memory leak and inconsistent state in the \tmac_filter_hash. This synchronization ensures the integrity of the mac_filter_hash and prevents the described leak.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50042", "url": "https://ubuntu.com/security/CVE-2024-50042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix increasing MSI-X on VF Increasing MSI-X value on a VF leads to invalid memory operations. This is caused by not reallocating some arrays. Reproducer: modprobe ice echo 0 > /sys/bus/pci/devices/$PF_PCI/sriov_drivers_autoprobe echo 1 > /sys/bus/pci/devices/$PF_PCI/sriov_numvfs echo 17 > /sys/bus/pci/devices/$VF0_PCI/sriov_vf_msix_count Default MSI-X is 16, so 17 and above triggers this issue. KASAN reports: BUG: KASAN: slab-out-of-bounds in ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] Read of size 8 at addr ffff8888b937d180 by task bash/28433 (...) Call Trace: (...) ? ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] kasan_report+0xed/0x120 ? ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] ice_vsi_cfg_def+0x3360/0x4770 [ice] ? mutex_unlock+0x83/0xd0 ? __pfx_ice_vsi_cfg_def+0x10/0x10 [ice] ? __pfx_ice_remove_vsi_lkup_fltr+0x10/0x10 [ice] ice_vsi_cfg+0x7f/0x3b0 [ice] ice_vf_reconfig_vsi+0x114/0x210 [ice] ice_sriov_set_msix_vec_count+0x3d0/0x960 [ice] sriov_vf_msix_count_store+0x21c/0x300 (...) Allocated by task 28201: (...) ice_vsi_cfg_def+0x1c8e/0x4770 [ice] ice_vsi_cfg+0x7f/0x3b0 [ice] ice_vsi_setup+0x179/0xa30 [ice] ice_sriov_configure+0xcaa/0x1520 [ice] sriov_numvfs_store+0x212/0x390 (...) To fix it, use ice_vsi_rebuild() instead of ice_vf_reconfig_vsi(). This causes the required arrays to be reallocated taking the new queue count into account (ice_vsi_realloc_stat_arrays()). Set req_txq and req_rxq before ice_vsi_rebuild(), so that realloc uses the newly set queue count. Additionally, ice_vsi_rebuild() does not remove VSI filters (ice_fltr_remove_all()), so ice_vf_init_host_cfg() is no longer necessary.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50093", "url": "https://ubuntu.com/security/CVE-2024-50093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: intel: int340x: processor: Fix warning during module unload The processor_thermal driver uses pcim_device_enable() to enable a PCI device, which means the device will be automatically disabled on driver detach. Thus there is no need to call pci_disable_device() again on it. With recent PCI device resource management improvements, e.g. commit f748a07a0b64 (\"PCI: Remove legacy pcim_release()\"), this problem is exposed and triggers the warining below. [ 224.010735] proc_thermal_pci 0000:00:04.0: disabling already-disabled device [ 224.010747] WARNING: CPU: 8 PID: 4442 at drivers/pci/pci.c:2250 pci_disable_device+0xe5/0x100 ... [ 224.010844] Call Trace: [ 224.010845] [ 224.010847] ? show_regs+0x6d/0x80 [ 224.010851] ? __warn+0x8c/0x140 [ 224.010854] ? pci_disable_device+0xe5/0x100 [ 224.010856] ? report_bug+0x1c9/0x1e0 [ 224.010859] ? handle_bug+0x46/0x80 [ 224.010862] ? exc_invalid_op+0x1d/0x80 [ 224.010863] ? asm_exc_invalid_op+0x1f/0x30 [ 224.010867] ? pci_disable_device+0xe5/0x100 [ 224.010869] ? pci_disable_device+0xe5/0x100 [ 224.010871] ? kfree+0x21a/0x2b0 [ 224.010873] pcim_disable_device+0x20/0x30 [ 224.010875] devm_action_release+0x16/0x20 [ 224.010878] release_nodes+0x47/0xc0 [ 224.010880] devres_release_all+0x9f/0xe0 [ 224.010883] device_unbind_cleanup+0x12/0x80 [ 224.010885] device_release_driver_internal+0x1ca/0x210 [ 224.010887] driver_detach+0x4e/0xa0 [ 224.010889] bus_remove_driver+0x6f/0xf0 [ 224.010890] driver_unregister+0x35/0x60 [ 224.010892] pci_unregister_driver+0x44/0x90 [ 224.010894] proc_thermal_pci_driver_exit+0x14/0x5f0 [processor_thermal_device_pci] ... [ 224.010921] ---[ end trace 0000000000000000 ]--- Remove the excess pci_disable_device() calls. [ rjw: Subject and changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50043", "url": "https://ubuntu.com/security/CVE-2024-50043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix possible badness in FREE_STATEID When multiple FREE_STATEIDs are sent for the same delegation stateid, it can lead to a possible either use-after-free or counter refcount underflow errors. In nfsd4_free_stateid() under the client lock we find a delegation stateid, however the code drops the lock before calling nfs4_put_stid(), that allows another FREE_STATE to find the stateid again. The first one will proceed to then free the stateid which leads to either use-after-free or decrementing already zeroed counter.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50044", "url": "https://ubuntu.com/security/CVE-2024-50044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change rfcomm_sk_state_change attempts to use sock_lock so it must never be called with it locked but rfcomm_sock_ioctl always attempt to lock it causing the following trace: ====================================================== WARNING: possible circular locking dependency detected 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Not tainted ------------------------------------------------------ syz-executor386/5093 is trying to acquire lock: ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1671 [inline] ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73 but task is already holding lock: ffff88807badfd28 (&d->lock){+.+.}-{3:3}, at: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50045", "url": "https://ubuntu.com/security/CVE-2024-50045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: br_netfilter: fix panic with metadata_dst skb Fix a kernel panic in the br_netfilter module when sending untagged traffic via a VxLAN device. This happens during the check for fragmentation in br_nf_dev_queue_xmit. It is dependent on: 1) the br_netfilter module being loaded; 2) net.bridge.bridge-nf-call-iptables set to 1; 3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port; 4) untagged frames with size higher than the VxLAN MTU forwarded/flooded When forwarding the untagged packet to the VxLAN bridge port, before the netfilter hooks are called, br_handle_egress_vlan_tunnel is called and changes the skb_dst to the tunnel dst. The tunnel_dst is a metadata type of dst, i.e., skb_valid_dst(skb) is false, and metadata->dst.dev is NULL. Then in the br_netfilter hooks, in br_nf_dev_queue_xmit, there's a check for frames that needs to be fragmented: frames with higher MTU than the VxLAN device end up calling br_nf_ip_fragment, which in turns call ip_skb_dst_mtu. The ip_dst_mtu tries to use the skb_dst(skb) as if it was a valid dst with valid dst->dev, thus the crash. This case was never supported in the first place, so drop the packet instead. PING 10.0.0.2 (10.0.0.2) from 0.0.0.0 h1-eth0: 2000(2028) bytes of data. [ 176.291791] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000110 [ 176.292101] Mem abort info: [ 176.292184] ESR = 0x0000000096000004 [ 176.292322] EC = 0x25: DABT (current EL), IL = 32 bits [ 176.292530] SET = 0, FnV = 0 [ 176.292709] EA = 0, S1PTW = 0 [ 176.292862] FSC = 0x04: level 0 translation fault [ 176.293013] Data abort info: [ 176.293104] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 176.293488] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 176.293787] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 176.293995] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043ef5000 [ 176.294166] [0000000000000110] pgd=0000000000000000, p4d=0000000000000000 [ 176.294827] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 176.295252] Modules linked in: vxlan ip6_udp_tunnel udp_tunnel veth br_netfilter bridge stp llc ipv6 crct10dif_ce [ 176.295923] CPU: 0 PID: 188 Comm: ping Not tainted 6.8.0-rc3-g5b3fbd61b9d1 #2 [ 176.296314] Hardware name: linux,dummy-virt (DT) [ 176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 176.296808] pc : br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.297382] lr : br_nf_dev_queue_xmit+0x2ac/0x4ec [br_netfilter] [ 176.297636] sp : ffff800080003630 [ 176.297743] x29: ffff800080003630 x28: 0000000000000008 x27: ffff6828c49ad9f8 [ 176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24: 00000000000003e8 [ 176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21: ffff6828c3b16d28 [ 176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18: 0000000000000014 [ 176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15: 0000000095744632 [ 176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12: ffffb7e137926a70 [ 176.299574] x11: 0000000000000001 x10: ffff6828c3f1c898 x9 : 0000000000000000 [ 176.300049] x8 : ffff6828c49bf070 x7 : 0008460f18d5f20e x6 : f20e0100bebafeca [ 176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 : 0000000000000000 [ 176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 : ffff6828c7f918f0 [ 176.300889] Call trace: [ 176.301123] br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.301411] br_nf_post_routing+0x2a8/0x3e4 [br_netfilter] [ 176.301703] nf_hook_slow+0x48/0x124 [ 176.302060] br_forward_finish+0xc8/0xe8 [bridge] [ 176.302371] br_nf_hook_thresh+0x124/0x134 [br_netfilter] [ 176.302605] br_nf_forward_finish+0x118/0x22c [br_netfilter] [ 176.302824] br_nf_forward_ip.part.0+0x264/0x290 [br_netfilter] [ 176.303136] br_nf_forward+0x2b8/0x4e0 [br_netfilter] [ 176.303359] nf_hook_slow+0x48/0x124 [ 176.303 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50094", "url": "https://ubuntu.com/security/CVE-2024-50094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sfc: Don't invoke xdp_do_flush() from netpoll. Yury reported a crash in the sfc driver originated from netpoll_send_udp(). The netconsole sends a message and then netpoll invokes the driver's NAPI function with a budget of zero. It is dedicated to allow driver to free TX resources, that it may have used while sending the packet. In the netpoll case the driver invokes xdp_do_flush() unconditionally, leading to crash because bpf_net_context was never assigned. Invoke xdp_do_flush() only if budget is not zero.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50188", "url": "https://ubuntu.com/security/CVE-2024-50188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: dp83869: fix memory corruption when enabling fiber When configuring the fiber port, the DP83869 PHY driver incorrectly calls linkmode_set_bit() with a bit mask (1 << 10) rather than a bit number (10). This corrupts some other memory location -- in case of arm64 the priv pointer in the same structure. Since the advertising flags are updated from supported at the end of the function the incorrect line isn't needed at all and can be removed.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50046", "url": "https://ubuntu.com/security/CVE-2024-50046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies() On the node of an NFS client, some files saved in the mountpoint of the NFS server were copied to another location of the same NFS server. Accidentally, the nfs42_complete_copies() got a NULL-pointer dereference crash with the following syslog: [232064.838881] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232064.839360] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232066.588183] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 [232066.588586] Mem abort info: [232066.588701] ESR = 0x0000000096000007 [232066.588862] EC = 0x25: DABT (current EL), IL = 32 bits [232066.589084] SET = 0, FnV = 0 [232066.589216] EA = 0, S1PTW = 0 [232066.589340] FSC = 0x07: level 3 translation fault [232066.589559] Data abort info: [232066.589683] ISV = 0, ISS = 0x00000007 [232066.589842] CM = 0, WnR = 0 [232066.589967] user pgtable: 64k pages, 48-bit VAs, pgdp=00002000956ff400 [232066.590231] [0000000000000058] pgd=08001100ae100003, p4d=08001100ae100003, pud=08001100ae100003, pmd=08001100b3c00003, pte=0000000000000000 [232066.590757] Internal error: Oops: 96000007 [#1] SMP [232066.590958] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm vhost_net vhost vhost_iotlb tap tun ipt_rpfilter xt_multiport ip_set_hash_ip ip_set_hash_net xfrm_interface xfrm6_tunnel tunnel4 tunnel6 esp4 ah4 wireguard libcurve25519_generic veth xt_addrtype xt_set nf_conntrack_netlink ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_bitmap_port ip_set_hash_ipport dummy ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs iptable_filter sch_ingress nfnetlink_cttimeout vport_gre ip_gre ip_tunnel gre vport_geneve geneve vport_vxlan vxlan ip6_udp_tunnel udp_tunnel openvswitch nf_conncount dm_round_robin dm_service_time dm_multipath xt_nat xt_MASQUERADE nft_chain_nat nf_nat xt_mark xt_conntrack xt_comment nft_compat nft_counter nf_tables nfnetlink ocfs2 ocfs2_nodemanager ocfs2_stackglue iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_ssif nbd overlay 8021q garp mrp bonding tls rfkill sunrpc ext4 mbcache jbd2 [232066.591052] vfat fat cas_cache cas_disk ses enclosure scsi_transport_sas sg acpi_ipmi ipmi_si ipmi_devintf ipmi_msghandler ip_tables vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio dm_mirror dm_region_hash dm_log dm_mod nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc fuse xfs libcrc32c ast drm_vram_helper qla2xxx drm_kms_helper syscopyarea crct10dif_ce sysfillrect ghash_ce sysimgblt sha2_ce fb_sys_fops cec sha256_arm64 sha1_ce drm_ttm_helper ttm nvme_fc igb sbsa_gwdt nvme_fabrics drm nvme_core i2c_algo_bit i40e scsi_transport_fc megaraid_sas aes_neon_bs [232066.596953] CPU: 6 PID: 4124696 Comm: 10.253.166.125- Kdump: loaded Not tainted 5.15.131-9.cl9_ocfs2.aarch64 #1 [232066.597356] Hardware name: Great Wall .\\x93\\x8e...RF6260 V5/GWMSSE2GL1T, BIOS T656FBE_V3.0.18 2024-01-06 [232066.597721] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [232066.598034] pc : nfs4_reclaim_open_state+0x220/0x800 [nfsv4] [232066.598327] lr : nfs4_reclaim_open_state+0x12c/0x800 [nfsv4] [232066.598595] sp : ffff8000f568fc70 [232066.598731] x29: ffff8000f568fc70 x28: 0000000000001000 x27: ffff21003db33000 [232066.599030] x26: ffff800005521ae0 x25: ffff0100f98fa3f0 x24: 0000000000000001 [232066.599319] x23: ffff800009920008 x22: ffff21003db33040 x21: ffff21003db33050 [232066.599628] x20: ffff410172fe9e40 x19: ffff410172fe9e00 x18: 0000000000000000 [232066.599914] x17: 0000000000000000 x16: 0000000000000004 x15: 0000000000000000 [232066.600195] x14: 0000000000000000 x13: ffff800008e685a8 x12: 00000000eac0c6e6 [232066.600498] x11: 00000000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50190", "url": "https://ubuntu.com/security/CVE-2024-50190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix memleak in ice_init_tx_topology() Fix leak of the FW blob (DDP pkg). Make ice_cfg_tx_topo() const-correct, so ice_init_tx_topology() can avoid copying whole FW blob. Copy just the topology section, and only when needed. Reuse the buffer allocated for the read of the current topology. This was found by kmemleak, with the following trace for each PF: [] kmemdup_noprof+0x1d/0x50 [] ice_init_ddp_config+0x100/0x220 [ice] [] ice_init_dev+0x6f/0x200 [ice] [] ice_init+0x29/0x560 [ice] [] ice_probe+0x21d/0x310 [ice] Constify ice_cfg_tx_topo() @buf parameter. This cascades further down to few more functions.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50180", "url": "https://ubuntu.com/security/CVE-2024-50180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: sisfb: Fix strbuf array overflow The values of the variables xres and yres are placed in strbuf. These variables are obtained from strbuf1. The strbuf1 array contains digit characters and a space if the array contains non-digit characters. Then, when executing sprintf(strbuf, \"%ux%ux8\", xres, yres); more than 16 bytes will be written to strbuf. It is suggested to increase the size of the strbuf array to 24. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06: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": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50048", "url": "https://ubuntu.com/security/CVE-2024-50048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: Fix a NULL pointer dereference issue in fbcon_putcs syzbot has found a NULL pointer dereference bug in fbcon. Here is the simplified C reproducer: struct param { \tuint8_t type; \tstruct tiocl_selection ts; }; int main() { \tstruct fb_con2fbmap con2fb; \tstruct param param; \tint fd = open(\"/dev/fb1\", 0, 0); \tcon2fb.console = 0x19; \tcon2fb.framebuffer = 0; \tioctl(fd, FBIOPUT_CON2FBMAP, &con2fb); \tparam.type = 2; \tparam.ts.xs = 0; param.ts.ys = 0; \tparam.ts.xe = 0; param.ts.ye = 0; \tparam.ts.sel_mode = 0; \tint fd1 = open(\"/dev/tty1\", O_RDWR, 0); \tioctl(fd1, TIOCLINUX, ¶m); \tcon2fb.console = 1; \tcon2fb.framebuffer = 0; \tioctl(fd, FBIOPUT_CON2FBMAP, &con2fb); \treturn 0; } After calling ioctl(fd1, TIOCLINUX, ¶m), the subsequent ioctl(fd, FBIOPUT_CON2FBMAP, &con2fb) causes the kernel to follow a different execution path: set_con2fb_map -> con2fb_init_display -> fbcon_set_disp -> redraw_screen -> hide_cursor -> clear_selection -> highlight -> invert_screen -> do_update_region -> fbcon_putcs -> ops->putcs Since ops->putcs is a NULL pointer, this leads to a kernel panic. To prevent this, we need to call set_blitting_type() within set_con2fb_map() to properly initialize ops->putcs.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50049", "url": "https://ubuntu.com/security/CVE-2024-50049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before dereferencing se [WHAT & HOW] se is null checked previously in the same function, indicating it might be null; therefore, it must be checked when used again. This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50090", "url": "https://ubuntu.com/security/CVE-2024-50090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/oa: Fix overflow in oa batch buffer By default xe_bb_create_job() appends a MI_BATCH_BUFFER_END to batch buffer, this is not a problem if batch buffer is only used once but oa reuses the batch buffer for the same metric and at each call it appends a MI_BATCH_BUFFER_END, printing the warning below and then overflowing. [ 381.072016] ------------[ cut here ]------------ [ 381.072019] xe 0000:00:02.0: [drm] Assertion `bb->len * 4 + bb_prefetch(q->gt) <= size` failed! platform: LUNARLAKE subplatform: 1 graphics: Xe2_LPG / Xe2_HPG 20.04 step B0 media: Xe2_LPM / Xe2_HPM 20.00 step B0 tile: 0 VRAM 0 B GT: 0 type 1 So here checking if batch buffer already have MI_BATCH_BUFFER_END if not append it. v2: - simply fix, suggestion from Ashutosh (cherry picked from commit 9ba0e0f30ca42a98af3689460063edfb6315718a)", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50183", "url": "https://ubuntu.com/security/CVE-2024-50183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV instance Deleting an NPIV instance requires all fabric ndlps to be released before an NPIV's resources can be torn down. Failure to release fabric ndlps beforehand opens kref imbalance race conditions. Fix by forcing the DA_ID to complete synchronously with usage of wait_queue.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50055", "url": "https://ubuntu.com/security/CVE-2024-50055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: driver core: bus: Fix double free in driver API bus_register() For bus_register(), any error which happens after kset_register() will cause that @priv are freed twice, fixed by setting @priv with NULL after the first free.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50091", "url": "https://ubuntu.com/security/CVE-2024-50091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm vdo: don't refer to dedupe_context after releasing it Clear the dedupe_context pointer in a data_vio whenever ownership of the context is lost, so that vdo can't examine it accidentally.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50056", "url": "https://ubuntu.com/security/CVE-2024-50056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: Fix ERR_PTR dereference in uvc_v4l2.c Fix potential dereferencing of ERR_PTR() in find_format_by_pix() and uvc_v4l2_enum_format(). Fix the following smatch errors: drivers/usb/gadget/function/uvc_v4l2.c:124 find_format_by_pix() error: 'fmtdesc' dereferencing possible ERR_PTR() drivers/usb/gadget/function/uvc_v4l2.c:392 uvc_v4l2_enum_format() error: 'fmtdesc' dereferencing possible ERR_PTR() Also, fix similar issue in uvc_v4l2_try_format() for potential dereferencing of ERR_PTR().", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50184", "url": "https://ubuntu.com/security/CVE-2024-50184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_pmem: Check device status before requesting flush If a pmem device is in a bad status, the driver side could wait for host ack forever in virtio_pmem_flush(), causing the system to hang. So add a status check in the beginning of virtio_pmem_flush() to return early if the device is not activated.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50057", "url": "https://ubuntu.com/security/CVE-2024-50057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: tipd: Free IRQ only if it was requested before In polling mode, if no IRQ was requested there is no need to free it. Call devm_free_irq() only if client->irq is set. This fixes the warning caused by the tps6598x module removal: WARNING: CPU: 2 PID: 333 at kernel/irq/devres.c:144 devm_free_irq+0x80/0x8c ... ... Call trace: devm_free_irq+0x80/0x8c tps6598x_remove+0x28/0x88 [tps6598x] i2c_device_remove+0x2c/0x9c device_remove+0x4c/0x80 device_release_driver_internal+0x1cc/0x228 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 i2c_del_driver+0x54/0x64 tps6598x_i2c_driver_exit+0x18/0xc3c [tps6598x] __arm64_sys_delete_module+0x184/0x264 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc8/0xe8 do_el0_svc+0x20/0x2c el0_svc+0x28/0x98 el0t_64_sync_handler+0x13c/0x158 el0t_64_sync+0x190/0x194", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50058", "url": "https://ubuntu.com/security/CVE-2024-50058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: protect uart_port_dtr_rts() in uart_shutdown() too Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part 3) added few uport == NULL checks. It added one to uart_shutdown(), so the commit assumes, uport can be NULL in there. But right after that protection, there is an unprotected \"uart_port_dtr_rts(uport, false);\" call. That is invoked only if HUPCL is set, so I assume that is the reason why we do not see lots of these reports. Or it cannot be NULL at this point at all for some reason :P. Until the above is investigated, stay on the safe side and move this dereference to the if too. I got this inconsistency from Coverity under CID 1585130. Thanks.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50181", "url": "https://ubuntu.com/security/CVE-2024-50181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: imx: Remove CLK_SET_PARENT_GATE for DRAM mux for i.MX7D For i.MX7D DRAM related mux clock, the clock source change should ONLY be done done in low level asm code without accessing DRAM, and then calling clk API to sync the HW clock status with clk tree, it should never touch real clock source switch via clk API, so CLK_SET_PARENT_GATE flag should NOT be added, otherwise, DRAM's clock parent will be disabled when DRAM is active, and system will hang.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50059", "url": "https://ubuntu.com/security/CVE-2024-50059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntb: ntb_hw_switchtec: Fix use after free vulnerability in switchtec_ntb_remove due to race condition In the switchtec_ntb_add function, it can call switchtec_ntb_init_sndev function, then &sndev->check_link_status_work is bound with check_link_status_work. switchtec_ntb_link_notification may be called to start the work. If we remove the module which will call switchtec_ntb_remove to make cleanup, it will free sndev through kfree(sndev), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | check_link_status_work switchtec_ntb_remove | kfree(sndev); | | if (sndev->link_force_down) | // use sndev Fix it by ensuring that the work is canceled before proceeding with the cleanup in switchtec_ntb_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50060", "url": "https://ubuntu.com/security/CVE-2024-50060", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring: check if we need to reschedule during overflow flush In terms of normal application usage, this list will always be empty. And if an application does overflow a bit, it'll have a few entries. However, nothing obviously prevents syzbot from running a test case that generates a ton of overflow entries, and then flushing them can take quite a while. Check for needing to reschedule while flushing, and drop our locks and do so if necessary. There's no state to maintain here as overflows always prune from head-of-list, hence it's fine to drop and reacquire the locks at the end of the loop.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50061", "url": "https://ubuntu.com/security/CVE-2024-50061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: cdns: Fix use after free vulnerability in cdns_i3c_master Driver Due to Race Condition In the cdns_i3c_master_probe function, &master->hj_work is bound with cdns_i3c_master_hj. And cdns_i3c_master_interrupt can call cnds_i3c_master_demux_ibis function to start the work. If we remove the module which will call cdns_i3c_master_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | cdns_i3c_master_hj cdns_i3c_master_remove | i3c_master_unregister(&master->base) | device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in cdns_i3c_master_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50062", "url": "https://ubuntu.com/security/CVE-2024-50062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-srv: Avoid null pointer deref during path establishment For RTRS path establishment, RTRS client initiates and completes con_num of connections. After establishing all its connections, the information is exchanged between the client and server through the info_req message. During this exchange, it is essential that all connections have been established, and the state of the RTRS srv path is CONNECTED. So add these sanity checks, to make sure we detect and abort process in error scenarios to avoid null pointer deref.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50095", "url": "https://ubuntu.com/security/CVE-2024-50095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mad: Improve handling of timed out WRs of mad agent Current timeout handler of mad agent acquires/releases mad_agent_priv lock for every timed out WRs. This causes heavy locking contention when higher no. of WRs are to be handled inside timeout handler. This leads to softlockup with below trace in some use cases where rdma-cm path is used to establish connection between peer nodes Trace: ----- BUG: soft lockup - CPU#4 stuck for 26s! [kworker/u128:3:19767] CPU: 4 PID: 19767 Comm: kworker/u128:3 Kdump: loaded Tainted: G OE ------- --- 5.14.0-427.13.1.el9_4.x86_64 #1 Hardware name: Dell Inc. PowerEdge R740/01YM03, BIOS 2.4.8 11/26/2019 Workqueue: ib_mad1 timeout_sends [ib_core] RIP: 0010:__do_softirq+0x78/0x2ac RSP: 0018:ffffb253449e4f98 EFLAGS: 00000246 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 000000000000001f RDX: 000000000000001d RSI: 000000003d1879ab RDI: fff363b66fd3a86b RBP: ffffb253604cbcd8 R08: 0000009065635f3b R09: 0000000000000000 R10: 0000000000000040 R11: ffffb253449e4ff8 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000040 FS: 0000000000000000(0000) GS:ffff8caa1fc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd9ec9db900 CR3: 0000000891934006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? __irq_exit_rcu+0xa1/0xc0 ? watchdog_timer_fn+0x1b2/0x210 ? __pfx_watchdog_timer_fn+0x10/0x10 ? __hrtimer_run_queues+0x127/0x2c0 ? hrtimer_interrupt+0xfc/0x210 ? __sysvec_apic_timer_interrupt+0x5c/0x110 ? sysvec_apic_timer_interrupt+0x37/0x90 ? asm_sysvec_apic_timer_interrupt+0x16/0x20 ? __do_softirq+0x78/0x2ac ? __do_softirq+0x60/0x2ac __irq_exit_rcu+0xa1/0xc0 sysvec_call_function_single+0x72/0x90 asm_sysvec_call_function_single+0x16/0x20 RIP: 0010:_raw_spin_unlock_irq+0x14/0x30 RSP: 0018:ffffb253604cbd88 EFLAGS: 00000247 RAX: 000000000001960d RBX: 0000000000000002 RCX: ffff8cad2a064800 RDX: 000000008020001b RSI: 0000000000000001 RDI: ffff8cad5d39f66c RBP: ffff8cad5d39f600 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8caa443e0c00 R11: ffffb253604cbcd8 R12: ffff8cacb8682538 R13: 0000000000000005 R14: ffffb253604cbd90 R15: ffff8cad5d39f66c cm_process_send_error+0x122/0x1d0 [ib_cm] timeout_sends+0x1dd/0x270 [ib_core] process_one_work+0x1e2/0x3b0 ? __pfx_worker_thread+0x10/0x10 worker_thread+0x50/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xdd/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x50 Simplified timeout handler by creating local list of timed out WRs and invoke send handler post creating the list. The new method acquires/ releases lock once to fetch the list and hence helps to reduce locking contetiong when processing higher no. of WRs", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50063", "url": "https://ubuntu.com/security/CVE-2024-50063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Prevent tail call between progs attached to different hooks bpf progs can be attached to kernel functions, and the attached functions can take different parameters or return different return values. If prog attached to one kernel function tail calls prog attached to another kernel function, the ctx access or return value verification could be bypassed. For example, if prog1 is attached to func1 which takes only 1 parameter and prog2 is attached to func2 which takes two parameters. Since verifier assumes the bpf ctx passed to prog2 is constructed based on func2's prototype, verifier allows prog2 to access the second parameter from the bpf ctx passed to it. The problem is that verifier does not prevent prog1 from passing its bpf ctx to prog2 via tail call. In this case, the bpf ctx passed to prog2 is constructed from func1 instead of func2, that is, the assumption for ctx access verification is bypassed. Another example, if BPF LSM prog1 is attached to hook file_alloc_security, and BPF LSM prog2 is attached to hook bpf_lsm_audit_rule_known. Verifier knows the return value rules for these two hooks, e.g. it is legal for bpf_lsm_audit_rule_known to return positive number 1, and it is illegal for file_alloc_security to return positive number. So verifier allows prog2 to return positive number 1, but does not allow prog1 to return positive number. The problem is that verifier does not prevent prog1 from calling prog2 via tail call. In this case, prog2's return value 1 will be used as the return value for prog1's hook file_alloc_security. That is, the return value rule is bypassed. This patch adds restriction for tail call to prevent such bypasses.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50191", "url": "https://ubuntu.com/security/CVE-2024-50191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: don't set SB_RDONLY after filesystem errors When the filesystem is mounted with errors=remount-ro, we were setting SB_RDONLY flag to stop all filesystem modifications. We knew this misses proper locking (sb->s_umount) and does not go through proper filesystem remount procedure but it has been the way this worked since early ext2 days and it was good enough for catastrophic situation damage mitigation. Recently, syzbot has found a way (see link) to trigger warnings in filesystem freezing because the code got confused by SB_RDONLY changing under its hands. Since these days we set EXT4_FLAGS_SHUTDOWN on the superblock which is enough to stop all filesystem modifications, modifying SB_RDONLY shouldn't be needed. So stop doing that.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50064", "url": "https://ubuntu.com/security/CVE-2024-50064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: zram: free secondary algorithms names We need to kfree() secondary algorithms names when reset zram device that had multi-streams, otherwise we leak memory. [senozhatsky@chromium.org: kfree(NULL) is legal] Link: https://lkml.kernel.org/r/20240917013021.868769-1-senozhatsky@chromium.org", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50065", "url": "https://ubuntu.com/security/CVE-2024-50065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Change to non-blocking allocation in ntfs_d_hash d_hash is done while under \"rcu-walk\" and should not sleep. __get_name() allocates using GFP_KERNEL, having the possibility to sleep when under memory pressure. Change the allocation to GFP_NOWAIT.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50089", "url": "https://ubuntu.com/security/CVE-2024-50089", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-49863", "url": "https://ubuntu.com/security/CVE-2024-49863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost/scsi: null-ptr-dereference in vhost_scsi_get_req() Since commit 3f8ca2e115e5 (\"vhost/scsi: Extract common handling code from control queue handler\") a null pointer dereference bug can be triggered when guest sends an SCSI AN request. In vhost_scsi_ctl_handle_vq(), `vc.target` is assigned with `&v_req.tmf.lun[1]` within a switch-case block and is then passed to vhost_scsi_get_req() which extracts `vc->req` and `tpg`. However, for a `VIRTIO_SCSI_T_AN_*` request, tpg is not required, so `vc.target` is set to NULL in this branch. Later, in vhost_scsi_get_req(), `vc->target` is dereferenced without being checked, leading to a null pointer dereference bug. This bug can be triggered from guest. When this bug occurs, the vhost_worker process is killed while holding `vq->mutex` and the corresponding tpg will remain occupied indefinitely. Below is the KASAN report: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 PID: 840 Comm: poc Not tainted 6.10.0+ #1 Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:vhost_scsi_get_req+0x165/0x3a0 Code: 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 02 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 65 30 4c 89 e2 48 c1 ea 03 <0f> b6 04 02 4c 89 e2 83 e2 07 38 d0 7f 08 84 c0 0f 85 be 01 00 00 RSP: 0018:ffff888017affb50 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffff88801b000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888017affcb8 RBP: ffff888017affb80 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff888017affc88 R14: ffff888017affd1c R15: ffff888017993000 FS: 000055556e076500(0000) GS:ffff88806b100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200027c0 CR3: 0000000010ed0004 CR4: 0000000000370ef0 Call Trace: ? show_regs+0x86/0xa0 ? die_addr+0x4b/0xd0 ? exc_general_protection+0x163/0x260 ? asm_exc_general_protection+0x27/0x30 ? vhost_scsi_get_req+0x165/0x3a0 vhost_scsi_ctl_handle_vq+0x2a4/0xca0 ? __pfx_vhost_scsi_ctl_handle_vq+0x10/0x10 ? __switch_to+0x721/0xeb0 ? __schedule+0xda5/0x5710 ? __kasan_check_write+0x14/0x30 ? _raw_spin_lock+0x82/0xf0 vhost_scsi_ctl_handle_kick+0x52/0x90 vhost_run_work_list+0x134/0x1b0 vhost_task_fn+0x121/0x350 ... ---[ end trace 0000000000000000 ]--- Let's add a check in vhost_scsi_get_req. [whitespace fixes]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49864", "url": "https://ubuntu.com/security/CVE-2024-49864", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix a race between socket set up and I/O thread creation In rxrpc_open_socket(), it sets up the socket and then sets up the I/O thread that will handle it. This is a problem, however, as there's a gap between the two phases in which a packet may come into rxrpc_encap_rcv() from the UDP packet but we oops when trying to wake the not-yet created I/O thread. As a quick fix, just make rxrpc_encap_rcv() discard the packet if there's no I/O thread yet. A better, but more intrusive fix would perhaps be to rearrange things such that the socket creation is done by the I/O thread.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49865", "url": "https://ubuntu.com/security/CVE-2024-49865", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: move xa_alloc to prevent UAF Evil user can guess the next id of the vm before the ioctl completes and then call vm destroy ioctl to trigger UAF since create ioctl is still referencing the same vm. Move the xa_alloc all the way to the end to prevent this. v2: - Rebase (cherry picked from commit dcfd3971327f3ee92765154baebbaece833d3ca9)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49955", "url": "https://ubuntu.com/security/CVE-2024-49955", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: battery: Fix possible crash when unregistering a battery hook When a battery hook returns an error when adding a new battery, then the battery hook is automatically unregistered. However the battery hook provider cannot know that, so it will later call battery_hook_unregister() on the already unregistered battery hook, resulting in a crash. Fix this by using the list head to mark already unregistered battery hooks as already being unregistered so that they can be ignored by battery_hook_unregister().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49973", "url": "https://ubuntu.com/security/CVE-2024-49973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: r8169: add tally counter fields added with RTL8125 RTL8125 added fields to the tally counter, what may result in the chip dma'ing these new fields to unallocated memory. Therefore make sure that the allocated memory area is big enough to hold all of the tally counter values, even if we use only parts of it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49974", "url": "https://ubuntu.com/security/CVE-2024-49974", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Limit the number of concurrent async COPY operations Nothing appears to limit the number of concurrent async COPY operations that clients can start. In addition, AFAICT each async COPY can copy an unlimited number of 4MB chunks, so can run for a long time. Thus IMO async COPY can become a DoS vector. Add a restriction mechanism that bounds the number of concurrent background COPY operations. Start simple and try to be fair -- this patch implements a per-namespace limit. An async COPY request that occurs while this limit is exceeded gets NFS4ERR_DELAY. The requesting client can choose to send the request again after a delay or fall back to a traditional read/write style copy. If there is need to make the mechanism more sophisticated, we can visit that in future patches.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49975", "url": "https://ubuntu.com/security/CVE-2024-49975", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uprobes: fix kernel info leak via \"[uprobes]\" vma xol_add_vma() maps the uninitialized page allocated by __create_xol_area() into userspace. On some architectures (x86) this memory is readable even without VM_READ, VM_EXEC results in the same pgprot_t as VM_EXEC|VM_READ, although this doesn't really matter, debugger can read this memory anyway.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50003", "url": "https://ubuntu.com/security/CVE-2024-50003", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix system hang while resume with TBT monitor [Why] Connected with a Thunderbolt monitor and do the suspend and the system may hang while resume. The TBT monitor HPD will be triggered during the resume procedure and call the drm_client_modeset_probe() while struct drm_connector connector->dev->master is NULL. It will mess up the pipe topology after resume. [How] Skip the TBT monitor HPD during the resume procedure because we currently will probe the connectors after resume by default. (cherry picked from commit 453f86a26945207a16b8f66aaed5962dc2b95b85)", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50173", "url": "https://ubuntu.com/security/CVE-2024-50173", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix access to uninitialized variable in tick_ctx_cleanup() The group variable can't be used to retrieve ptdev in our second loop, because it points to the previously iterated list_head, not a valid group. Get the ptdev object from the scheduler instead.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49866", "url": "https://ubuntu.com/security/CVE-2024-49866", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Fix a race during cpuhp processing There is another found exception that the \"timerlat/1\" thread was scheduled on CPU0, and lead to timer corruption finally: ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ``` After tracing the scheduling event, it was discovered that the migration of the \"timerlat/1\" thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() | To fix this, skip online processing if the CPU is already offline.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49976", "url": "https://ubuntu.com/security/CVE-2024-49976", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Drop interface_lock in stop_kthread() stop_kthread() is the offline callback for \"trace/osnoise:online\", since commit 5bfbcd1ee57b (\"tracing/timerlat: Add interface_lock around clearing of kthread in stop_kthread()\"), the following ABBA deadlock scenario is introduced: T1 | T2 [BP] | T3 [AP] osnoise_hotplug_workfn() | work_for_cpu_fn() | cpuhp_thread_fun() | _cpu_down() | osnoise_cpu_die() mutex_lock(&interface_lock) | | stop_kthread() | cpus_write_lock() | mutex_lock(&interface_lock) cpus_read_lock() | cpuhp_kick_ap() | As the interface_lock here in just for protecting the \"kthread\" field of the osn_var, use xchg() instead to fix this issue. Also use for_each_online_cpu() back in stop_per_cpu_kthreads() as it can take cpu_read_lock() again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50005", "url": "https://ubuntu.com/security/CVE-2024-50005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: Fix potential RCU dereference issue in mac802154_scan_worker In the `mac802154_scan_worker` function, the `scan_req->type` field was accessed after the RCU read-side critical section was unlocked. According to RCU usage rules, this is illegal and can lead to unpredictable behavior, such as accessing memory that has been updated or causing use-after-free issues. This possible bug was identified using a static analysis tool developed by myself, specifically designed to detect RCU-related issues. To address this, the `scan_req->type` value is now stored in a local variable `scan_req_type` while still within the RCU read-side critical section. The `scan_req_type` is then used after the RCU lock is released, ensuring that the type value is safely accessed without violating RCU rules.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50012", "url": "https://ubuntu.com/security/CVE-2024-50012", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: Avoid a bad reference count on CPU node In the parse_perf_domain function, if the call to of_parse_phandle_with_args returns an error, then the reference to the CPU device node that was acquired at the start of the function would not be properly decremented. Address this by declaring the variable with the __free(device_node) cleanup attribute.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49867", "url": "https://ubuntu.com/security/CVE-2024-49867", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: wait for fixup workers before stopping cleaner kthread during umount During unmount, at close_ctree(), we have the following steps in this order: 1) Park the cleaner kthread - this doesn't destroy the kthread, it basically halts its execution (wake ups against it work but do nothing); 2) We stop the cleaner kthread - this results in freeing the respective struct task_struct; 3) We call btrfs_stop_all_workers() which waits for any jobs running in all the work queues and then free the work queues. Syzbot reported a case where a fixup worker resulted in a crash when doing a delayed iput on its inode while attempting to wake up the cleaner at btrfs_add_delayed_iput(), because the task_struct of the cleaner kthread was already freed. This can happen during unmount because we don't wait for any fixup workers still running before we call kthread_stop() against the cleaner kthread, which stops and free all its resources. Fix this by waiting for any fixup workers at close_ctree() before we call kthread_stop() against the cleaner and run pending delayed iputs. The stack traces reported by syzbot were the following: BUG: KASAN: slab-use-after-free in __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 Read of size 8 at addr ffff8880272a8a18 by task kworker/u8:3/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.12.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: btrfs-fixup btrfs_work_helper 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 __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline] try_to_wake_up+0xb0/0x1480 kernel/sched/core.c:4154 btrfs_writepage_fixup_worker+0xc16/0xdf0 fs/btrfs/inode.c:2842 btrfs_work_helper+0x390/0xc50 fs/btrfs/async-thread.c:314 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Allocated by task 2: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:319 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345 kasan_slab_alloc include/linux/kasan.h:247 [inline] slab_post_alloc_hook mm/slub.c:4086 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4187 alloc_task_struct_node kernel/fork.c:180 [inline] dup_task_struct+0x57/0x8c0 kernel/fork.c:1107 copy_process+0x5d1/0x3d50 kernel/fork.c:2206 kernel_clone+0x223/0x880 kernel/fork.c:2787 kernel_thread+0x1bc/0x240 kernel/fork.c:2849 create_kthread kernel/kthread.c:412 [inline] kthreadd+0x60d/0x810 kernel/kthread.c:765 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Freed by task 61: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:230 [inline] slab_free_h ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49868", "url": "https://ubuntu.com/security/CVE-2024-49868", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix a NULL pointer dereference when failed to start a new trasacntion [BUG] Syzbot reported a NULL pointer dereference with the following crash: FAULT_INJECTION: forcing a failure. start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676 prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642 relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678 ... BTRFS info (device loop0): balance: ended with status: -12 Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667] RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926 Call Trace: commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496 btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430 del_balance_item fs/btrfs/volumes.c:3678 [inline] reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742 btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574 btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673 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/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [CAUSE] The allocation failure happens at the start_transaction() inside prepare_to_relocate(), and during the error handling we call unset_reloc_control(), which makes fs_info->balance_ctl to be NULL. Then we continue the error path cleanup in btrfs_balance() by calling reset_balance_state() which will call del_balance_item() to fully delete the balance item in the root tree. However during the small window between set_reloc_contrl() and unset_reloc_control(), we can have a subvolume tree update and created a reloc_root for that subvolume. Then we go into the final btrfs_commit_transaction() of del_balance_item(), and into btrfs_update_reloc_root() inside commit_fs_roots(). That function checks if fs_info->reloc_ctl is in the merge_reloc_tree stage, but since fs_info->reloc_ctl is NULL, it results a NULL pointer dereference. [FIX] Just add extra check on fs_info->reloc_ctl inside btrfs_update_reloc_root(), before checking fs_info->reloc_ctl->merge_reloc_tree. That DEAD_RELOC_TREE handling is to prevent further modification to the reloc tree during merge stage, but since there is no reloc_ctl at all, we do not need to bother that.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49869", "url": "https://ubuntu.com/security/CVE-2024-49869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: send: fix buffer overflow detection when copying path to cache entry Starting with commit c0247d289e73 (\"btrfs: send: annotate struct name_cache_entry with __counted_by()\") we annotated the variable length array \"name\" from the name_cache_entry structure with __counted_by() to improve overflow detection. However that alone was not correct, because the length of that array does not match the \"name_len\" field - it matches that plus 1 to include the NUL string terminator, so that makes a fortified kernel think there's an overflow and report a splat like this: strcpy: detected buffer overflow: 20 byte write of buffer size 19 WARNING: CPU: 3 PID: 3310 at __fortify_report+0x45/0x50 CPU: 3 UID: 0 PID: 3310 Comm: btrfs Not tainted 6.11.0-prnet #1 Hardware name: CompuLab Ltd. sbc-ihsw/Intense-PC2 (IPC2), BIOS IPC2_3.330.7 X64 03/15/2018 RIP: 0010:__fortify_report+0x45/0x50 Code: 48 8b 34 (...) RSP: 0018:ffff97ebc0d6f650 EFLAGS: 00010246 RAX: 7749924ef60fa600 RBX: ffff8bf5446a521a RCX: 0000000000000027 RDX: 00000000ffffdfff RSI: ffff97ebc0d6f548 RDI: ffff8bf84e7a1cc8 RBP: ffff8bf548574080 R08: ffffffffa8c40e10 R09: 0000000000005ffd R10: 0000000000000004 R11: ffffffffa8c70e10 R12: ffff8bf551eef400 R13: 0000000000000000 R14: 0000000000000013 R15: 00000000000003a8 FS: 00007fae144de8c0(0000) GS:ffff8bf84e780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fae14691690 CR3: 00000001027a2003 CR4: 00000000001706f0 Call Trace: ? __warn+0x12a/0x1d0 ? __fortify_report+0x45/0x50 ? report_bug+0x154/0x1c0 ? handle_bug+0x42/0x70 ? exc_invalid_op+0x1a/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? __fortify_report+0x45/0x50 __fortify_panic+0x9/0x10 __get_cur_name_and_parent+0x3bc/0x3c0 get_cur_path+0x207/0x3b0 send_extent_data+0x709/0x10d0 ? find_parent_nodes+0x22df/0x25d0 ? mas_nomem+0x13/0x90 ? mtree_insert_range+0xa5/0x110 ? btrfs_lru_cache_store+0x5f/0x1e0 ? iterate_extent_inodes+0x52d/0x5a0 process_extent+0xa96/0x11a0 ? __pfx_lookup_backref_cache+0x10/0x10 ? __pfx_store_backref_cache+0x10/0x10 ? __pfx_iterate_backrefs+0x10/0x10 ? __pfx_check_extent_item+0x10/0x10 changed_cb+0x6fa/0x930 ? tree_advance+0x362/0x390 ? memcmp_extent_buffer+0xd7/0x160 send_subvol+0xf0a/0x1520 btrfs_ioctl_send+0x106b/0x11d0 ? __pfx___clone_root_cmp_sort+0x10/0x10 _btrfs_ioctl_send+0x1ac/0x240 btrfs_ioctl+0x75b/0x850 __se_sys_ioctl+0xca/0x150 do_syscall_64+0x85/0x160 ? __count_memcg_events+0x69/0x100 ? handle_mm_fault+0x1327/0x15c0 ? __se_sys_rt_sigprocmask+0xf1/0x180 ? syscall_exit_to_user_mode+0x75/0xa0 ? do_syscall_64+0x91/0x160 ? do_user_addr_fault+0x21d/0x630 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fae145eeb4f Code: 00 48 89 (...) RSP: 002b:00007ffdf1cb09b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fae145eeb4f RDX: 00007ffdf1cb0ad0 RSI: 0000000040489426 RDI: 0000000000000004 RBP: 00000000000078fe R08: 00007fae144006c0 R09: 00007ffdf1cb0927 R10: 0000000000000008 R11: 0000000000000246 R12: 00007ffdf1cb1ce8 R13: 0000000000000003 R14: 000055c499fab2e0 R15: 0000000000000004 Fix this by not storing the NUL string terminator since we don't actually need it for name cache entries, this way \"name_len\" corresponds to the actual size of the \"name\" array. This requires marking the \"name\" array field with __nonstring and using memcpy() instead of strcpy() as recommended by the guidelines at: https://github.com/KSPP/linux/issues/90", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49870", "url": "https://ubuntu.com/security/CVE-2024-49870", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cachefiles: fix dentry leak in cachefiles_open_file() A dentry leak may be caused when a lookup cookie and a cull are concurrent: P1 | P2 ----------------------------------------------------------- cachefiles_lookup_cookie cachefiles_look_up_object lookup_one_positive_unlocked // get dentry cachefiles_cull inode->i_flags |= S_KERNEL_FILE; cachefiles_open_file cachefiles_mark_inode_in_use __cachefiles_mark_inode_in_use can_use = false if (!(inode->i_flags & S_KERNEL_FILE)) can_use = true \t return false return false // Returns an error but doesn't put dentry After that the following WARNING will be triggered when the backend folder is umounted: ================================================================== BUG: Dentry 000000008ad87947{i=7a,n=Dx_1_1.img} still in use (1) [unmount of ext4 sda] WARNING: CPU: 4 PID: 359261 at fs/dcache.c:1767 umount_check+0x5d/0x70 CPU: 4 PID: 359261 Comm: umount Not tainted 6.6.0-dirty #25 RIP: 0010:umount_check+0x5d/0x70 Call Trace: d_walk+0xda/0x2b0 do_one_tree+0x20/0x40 shrink_dcache_for_umount+0x2c/0x90 generic_shutdown_super+0x20/0x160 kill_block_super+0x1a/0x40 ext4_kill_sb+0x22/0x40 deactivate_locked_super+0x35/0x80 cleanup_mnt+0x104/0x160 ================================================================== Whether cachefiles_open_file() returns true or false, the reference count obtained by lookup_positive_unlocked() in cachefiles_look_up_object() should be released. Therefore release that reference count in cachefiles_look_up_object() to fix the above issue and simplify the code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49871", "url": "https://ubuntu.com/security/CVE-2024-49871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: adp5589-keys - fix NULL pointer dereference We register a devm action to call adp5589_clear_config() and then pass the i2c client as argument so that we can call i2c_get_clientdata() in order to get our device object. However, i2c_set_clientdata() is only being set at the end of the probe function which means that we'll get a NULL pointer dereference in case the probe function fails early.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49872", "url": "https://ubuntu.com/security/CVE-2024-49872", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/gup: fix memfd_pin_folios alloc race panic If memfd_pin_folios tries to create a hugetlb page, but someone else already did, then folio gets the value -EEXIST here: folio = memfd_alloc_folio(memfd, start_idx); if (IS_ERR(folio)) { ret = PTR_ERR(folio); if (ret != -EEXIST) goto err; then on the next trip through the \"while start_idx\" loop we panic here: if (folio) { folio_put(folio); To fix, set the folio to NULL on error.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49964", "url": "https://ubuntu.com/security/CVE-2024-49964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix memfd_pin_folios free_huge_pages leak memfd_pin_folios followed by unpin_folios fails to restore free_huge_pages if the pages were not already faulted in, because the folio refcount for pages created by memfd_alloc_folio never goes to 0. memfd_pin_folios needs another folio_put to undo the folio_try_get below: memfd_alloc_folio() alloc_hugetlb_folio_nodemask() dequeue_hugetlb_folio_nodemask() dequeue_hugetlb_folio_node_exact() folio_ref_unfreeze(folio, 1); ; adds 1 refcount folio_try_get() ; adds 1 refcount hugetlb_add_to_page_cache() ; adds 512 refcount (on x86) With the fix, after memfd_pin_folios + unpin_folios, the refcount for the (unfaulted) page is 512, which is correct, as the refcount for a faulted unpinned page is 513.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49873", "url": "https://ubuntu.com/security/CVE-2024-49873", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/filemap: fix filemap_get_folios_contig THP panic Patch series \"memfd-pin huge page fixes\". Fix multiple bugs that occur when using memfd_pin_folios with hugetlb pages and THP. The hugetlb bugs only bite when the page is not yet faulted in when memfd_pin_folios is called. The THP bug bites when the starting offset passed to memfd_pin_folios is not huge page aligned. See the commit messages for details. This patch (of 5): memfd_pin_folios on memory backed by THP panics if the requested start offset is not huge page aligned: BUG: kernel NULL pointer dereference, address: 0000000000000036 RIP: 0010:filemap_get_folios_contig+0xdf/0x290 RSP: 0018:ffffc9002092fbe8 EFLAGS: 00010202 RAX: 0000000000000002 RBX: 0000000000000002 RCX: 0000000000000002 The fault occurs here, because xas_load returns a folio with value 2: filemap_get_folios_contig() for (folio = xas_load(&xas); folio && xas.xa_index <= end; folio = xas_next(&xas)) { ... if (!folio_try_get(folio)) <-- BOOM \"2\" is an xarray sibling entry. We get it because memfd_pin_folios does not round the indices passed to filemap_get_folios_contig to huge page boundaries for THP, so we load from the middle of a huge page range see a sibling. (It does round for hugetlbfs, at the is_file_hugepages test). To fix, if the folio is a sibling, then return the next index as the starting point for the next call to filemap_get_folios_contig.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49977", "url": "https://ubuntu.com/security/CVE-2024-49977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: Fix zero-division error when disabling tc cbs The commit b8c43360f6e4 (\"net: stmmac: No need to calculate speed divider when offload is disabled\") allows the \"port_transmit_rate_kbps\" to be set to a value of 0, which is then passed to the \"div_s64\" function when tc-cbs is disabled. This leads to a zero-division error. When tc-cbs is disabled, the idleslope, sendslope, and credit values the credit values are not required to be configured. Therefore, adding a return statement after setting the txQ mode to DCB when tc-cbs is disabled would prevent a zero-division error.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49978", "url": "https://ubuntu.com/security/CVE-2024-49978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gso: fix udp gso fraglist segmentation after pull from frag_list Detect gso fraglist skbs with corrupted geometry (see below) and pass these to skb_segment instead of skb_segment_list, as the first can segment them correctly. 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 these skbs, breaking these invariants. In extreme cases they pull all data into skb linear. For UDP, this causes a NULL ptr deref in __udpv4_gso_segment_list_csum at udp_hdr(seg->next)->dest. Detect invalid geometry due to pull, by checking head_skb size. Don't just drop, as this may blackhole a destination. Convert to be able to pass to regular skb_segment.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49979", "url": "https://ubuntu.com/security/CVE-2024-49979", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gso: fix tcp fraglist segmentation after pull from frag_list Detect tcp gso fraglist skbs with corrupted geometry (see below) and pass these to skb_segment instead of skb_segment_list, as the first can segment them correctly. 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 these skbs, breaking these invariants. In extreme cases they pull all data into skb linear. For TCP, this causes a NULL ptr deref in __tcpv4_gso_segment_list_csum at tcp_hdr(seg->next). Detect invalid geometry due to pull, by checking head_skb size. Don't just drop, as this may blackhole a destination. Convert to be able to pass to regular skb_segment. Approach and description based on a patch by Willem de Bruijn.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49980", "url": "https://ubuntu.com/security/CVE-2024-49980", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vrf: revert \"vrf: Remove unnecessary RCU-bh critical section\" This reverts commit 504fc6f4f7f681d2a03aa5f68aad549d90eab853. dev_queue_xmit_nit is expected to be called with BH disabled. __dev_queue_xmit has the following: /* Disable soft irqs for various locks below. Also * stops preemption for RCU. */ rcu_read_lock_bh(); VRF must follow this invariant. The referenced commit removed this protection. Which triggered a lockdep warning: \t================================ \tWARNING: inconsistent lock state \t6.11.0 #1 Tainted: G W \t-------------------------------- \tinconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage. \tbtserver/134819 [HC0[0]:SC0[0]:HE1:SE1] takes: \tffff8882da30c118 (rlock-AF_PACKET){+.?.}-{2:2}, at: tpacket_rcv+0x863/0x3b30 \t{IN-SOFTIRQ-W} state was registered at: \t lock_acquire+0x19a/0x4f0 \t _raw_spin_lock+0x27/0x40 \t packet_rcv+0xa33/0x1320 \t __netif_receive_skb_core.constprop.0+0xcb0/0x3a90 \t __netif_receive_skb_list_core+0x2c9/0x890 \t netif_receive_skb_list_internal+0x610/0xcc0 [...] \tother info that might help us debug this: \t Possible unsafe locking scenario: \t CPU0 \t ---- \t lock(rlock-AF_PACKET); \t \t lock(rlock-AF_PACKET); \t *** DEADLOCK *** \tCall Trace: \t \t dump_stack_lvl+0x73/0xa0 \t mark_lock+0x102e/0x16b0 \t __lock_acquire+0x9ae/0x6170 \t lock_acquire+0x19a/0x4f0 \t _raw_spin_lock+0x27/0x40 \t tpacket_rcv+0x863/0x3b30 \t dev_queue_xmit_nit+0x709/0xa40 \t vrf_finish_direct+0x26e/0x340 [vrf] \t vrf_l3_out+0x5f4/0xe80 [vrf] \t __ip_local_out+0x51e/0x7a0 [...]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49981", "url": "https://ubuntu.com/security/CVE-2024-49981", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: venus: fix use after free bug in venus_remove due to race condition in venus_probe, core->work is bound with venus_sys_error_handler, which is used to handle error. The code use core->sys_err_done to make sync work. The core->work is started in venus_event_notify. If we call venus_remove, there might be an unfished work. The possible sequence is as follows: CPU0 CPU1 |venus_sys_error_handler venus_remove | hfi_destroy\t \t\t | venus_hfi_destroy\t | kfree(hdev);\t | |hfi_reinit \t\t\t\t\t |venus_hfi_queues_reinit |//use hdev Fix it by canceling the work in venus_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49956", "url": "https://ubuntu.com/security/CVE-2024-49956", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: fix double destroy_workqueue error When gfs2_fill_super() fails, destroy_workqueue() is called within gfs2_gl_hash_clear(), and the subsequent code path calls destroy_workqueue() on the same work queue again. This issue can be fixed by setting the work queue pointer to NULL after the first destroy_workqueue() call and checking for a NULL pointer before attempting to destroy the work queue again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50176", "url": "https://ubuntu.com/security/CVE-2024-50176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: k3-r5: Fix error handling when power-up failed By simply bailing out, the driver was violating its rule and internal assumptions that either both or no rproc should be initialized. E.g., this could cause the first core to be available but not the second one, leading to crashes on its shutdown later on while trying to dereference that second instance.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49982", "url": "https://ubuntu.com/security/CVE-2024-49982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: aoe: fix the potential use-after-free problem in more places For fixing CVE-2023-6270, f98364e92662 (\"aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts\") makes tx() calling dev_put() instead of doing in aoecmd_cfg_pkts(). It avoids that the tx() runs into use-after-free. Then Nicolai Stange found more places in aoe have potential use-after-free problem with tx(). e.g. revalidate(), aoecmd_ata_rw(), resend(), probe() and aoecmd_cfg_rsp(). Those functions also use aoenet_xmit() to push packet to tx queue. So they should also use dev_hold() to increase the refcnt of skb->dev. On the other hand, moving dev_put() to tx() causes that the refcnt of skb->dev be reduced to a negative value, because corresponding dev_hold() are not called in revalidate(), aoecmd_ata_rw(), resend(), probe(), and aoecmd_cfg_rsp(). This patch fixed this issue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49874", "url": "https://ubuntu.com/security/CVE-2024-49874", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: svc: Fix use after free vulnerability in svc_i3c_master Driver Due to Race Condition In the svc_i3c_master_probe function, &master->hj_work is bound with svc_i3c_master_hj_work, &master->ibi_work is bound with svc_i3c_master_ibi_work. And svc_i3c_master_ibi_work can start the hj_work, svc_i3c_master_irq_handler can start the ibi_work. If we remove the module which will call svc_i3c_master_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | svc_i3c_master_hj_work svc_i3c_master_remove | i3c_master_unregister(&master->base)| device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in svc_i3c_master_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49875", "url": "https://ubuntu.com/security/CVE-2024-49875", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: map the EBADMSG to nfserr_io to avoid warning Ext4 will throw -EBADMSG through ext4_readdir when a checksum error occurs, resulting in the following WARNING. Fix it by mapping EBADMSG to nfserr_io. nfsd_buffered_readdir iterate_dir // -EBADMSG -74 ext4_readdir // .iterate_shared ext4_dx_readdir ext4_htree_fill_tree htree_dirblock_to_tree ext4_read_dirblock __ext4_read_dirblock ext4_dirblock_csum_verify warn_no_space_for_csum __warn_no_space_for_csum return ERR_PTR(-EFSBADCRC) // -EBADMSG -74 nfserrno // WARNING [ 161.115610] ------------[ cut here ]------------ [ 161.116465] nfsd: non-standard errno: -74 [ 161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0 [ 161.118596] Modules linked in: [ 161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138 [ 161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qe mu.org 04/01/2014 [ 161.123601] RIP: 0010:nfserrno+0x9d/0xd0 [ 161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6 05 ce 2b 61 03 01 e8 99 20 d8 00 <0f> 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33 [ 161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286 [ 161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a [ 161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827 [ 161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021 [ 161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8 [ 161.135244] FS: 0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000 [ 161.136695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0 [ 161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 161.141519] PKRU: 55555554 [ 161.142076] Call Trace: [ 161.142575] ? __warn+0x9b/0x140 [ 161.143229] ? nfserrno+0x9d/0xd0 [ 161.143872] ? report_bug+0x125/0x150 [ 161.144595] ? handle_bug+0x41/0x90 [ 161.145284] ? exc_invalid_op+0x14/0x70 [ 161.146009] ? asm_exc_invalid_op+0x12/0x20 [ 161.146816] ? nfserrno+0x9d/0xd0 [ 161.147487] nfsd_buffered_readdir+0x28b/0x2b0 [ 161.148333] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.149258] ? nfsd_buffered_filldir+0xf0/0xf0 [ 161.150093] ? wait_for_concurrent_writes+0x170/0x170 [ 161.151004] ? generic_file_llseek_size+0x48/0x160 [ 161.151895] nfsd_readdir+0x132/0x190 [ 161.152606] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.153516] ? nfsd_unlink+0x380/0x380 [ 161.154256] ? override_creds+0x45/0x60 [ 161.155006] nfsd4_encode_readdir+0x21a/0x3d0 [ 161.155850] ? nfsd4_encode_readlink+0x210/0x210 [ 161.156731] ? write_bytes_to_xdr_buf+0x97/0xe0 [ 161.157598] ? __write_bytes_to_xdr_buf+0xd0/0xd0 [ 161.158494] ? lock_downgrade+0x90/0x90 [ 161.159232] ? nfs4svc_decode_voidarg+0x10/0x10 [ 161.160092] nfsd4_encode_operation+0x15a/0x440 [ 161.160959] nfsd4_proc_compound+0x718/0xe90 [ 161.161818] nfsd_dispatch+0x18e/0x2c0 [ 161.162586] svc_process_common+0x786/0xc50 [ 161.163403] ? nfsd_svc+0x380/0x380 [ 161.164137] ? svc_printk+0x160/0x160 [ 161.164846] ? svc_xprt_do_enqueue.part.0+0x365/0x380 [ 161.165808] ? nfsd_svc+0x380/0x380 [ 161.166523] ? rcu_is_watching+0x23/0x40 [ 161.167309] svc_process+0x1a5/0x200 [ 161.168019] nfsd+0x1f5/0x380 [ 161.168663] ? nfsd_shutdown_threads+0x260/0x260 [ 161.169554] kthread+0x1c4/0x210 [ 161.170224] ? kthread_insert_work_sanity_check+0x80/0x80 [ 161.171246] ret_from_fork+0x1f/0x30", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50013", "url": "https://ubuntu.com/security/CVE-2024-50013", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix memory leak in exfat_load_bitmap() If the first directory entry in the root directory is not a bitmap directory entry, 'bh' will not be released and reassigned, which will cause a memory leak.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49876", "url": "https://ubuntu.com/security/CVE-2024-49876", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: fix UAF around queue destruction We currently do stuff like queuing the final destruction step on a random system wq, which will outlive the driver instance. With bad timing we can teardown the driver with one or more work workqueue still being alive leading to various UAF splats. Add a fini step to ensure user queues are properly torn down. At this point GuC should already be nuked so queue itself should no longer be referenced from hw pov. v2 (Matt B) - Looks much safer to use a waitqueue and then just wait for the xa_array to become empty before triggering the drain. (cherry picked from commit 861108666cc0e999cffeab6aff17b662e68774e3)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49877", "url": "https://ubuntu.com/security/CVE-2024-49877", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate When doing cleanup, if flags without OCFS2_BH_READAHEAD, it may trigger NULL pointer dereference in the following ocfs2_set_buffer_uptodate() if bh is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49957", "url": "https://ubuntu.com/security/CVE-2024-49957", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix null-ptr-deref when journal load failed. During the mounting process, if journal_reset() fails because of too short journal, then lead to jbd2_journal_load() fails with NULL j_sb_buffer. Subsequently, ocfs2_journal_shutdown() calls jbd2_journal_flush()->jbd2_cleanup_journal_tail()-> __jbd2_update_log_tail()->jbd2_journal_update_sb_log_tail() ->lock_buffer(journal->j_sb_buffer), resulting in a null-pointer dereference error. To resolve this issue, we should check the JBD2_LOADED flag to ensure the journal was properly loaded. Additionally, use journal instead of osb->journal directly to simplify the code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49965", "url": "https://ubuntu.com/security/CVE-2024-49965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove unreasonable unlock in ocfs2_read_blocks Patch series \"Misc fixes for ocfs2_read_blocks\", v5. This series contains 2 fixes for ocfs2_read_blocks(). The first patch fix the issue reported by syzbot, which detects bad unlock balance in ocfs2_read_blocks(). The second patch fixes an issue reported by Heming Zhao when reviewing above fix. This patch (of 2): There was a lock release before exiting, so remove the unreasonable unlock.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49966", "url": "https://ubuntu.com/security/CVE-2024-49966", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: cancel dqi_sync_work before freeing oinfo ocfs2_global_read_info() will initialize and schedule dqi_sync_work at the end, if error occurs after successfully reading global quota, it will trigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled: ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16c This reports that there is an active delayed work when freeing oinfo in error handling, so cancel dqi_sync_work first. BTW, return status instead of -1 when .read_file_info fails.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49958", "url": "https://ubuntu.com/security/CVE-2024-49958", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reserve space for inline xattr before attaching reflink tree One of our customers reported a crash and a corrupted ocfs2 filesystem. The crash was due to the detection of corruption. Upon troubleshooting, the fsck -fn output showed the below corruption [EXTENT_LIST_FREE] Extent list in owner 33080590 claims 230 as the next free chain record, but fsck believes the largest valid value is 227. Clamp the next record value? n The stat output from the debugfs.ocfs2 showed the following corruption where the \"Next Free Rec:\" had overshot the \"Count:\" in the root metadata block. Inode: 33080590 Mode: 0640 Generation: 2619713622 (0x9c25a856) FS Generation: 904309833 (0x35e6ac49) CRC32: 00000000 ECC: 0000 Type: Regular Attr: 0x0 Flags: Valid Dynamic Features: (0x16) HasXattr InlineXattr Refcounted Extended Attributes Block: 0 Extended Attributes Inline Size: 256 User: 0 (root) Group: 0 (root) Size: 281320357888 Links: 1 Clusters: 141738 ctime: 0x66911b56 0x316edcb8 -- Fri Jul 12 06:02:30.829349048 2024 atime: 0x66911d6b 0x7f7a28d -- Fri Jul 12 06:11:23.133669517 2024 mtime: 0x66911b56 0x12ed75d7 -- Fri Jul 12 06:02:30.317552087 2024 dtime: 0x0 -- Wed Dec 31 17:00:00 1969 Refcount Block: 2777346 Last Extblk: 2886943 Orphan Slot: 0 Sub Alloc Slot: 0 Sub Alloc Bit: 14 Tree Depth: 1 Count: 227 Next Free Rec: 230 ## Offset Clusters Block# 0 0 2310 2776351 1 2310 2139 2777375 2 4449 1221 2778399 3 5670 731 2779423 4 6401 566 2780447 ....... .... ....... ....... .... ....... The issue was in the reflink workfow while reserving space for inline xattr. The problematic function is ocfs2_reflink_xattr_inline(). By the time this function is called the reflink tree is already recreated at the destination inode from the source inode. At this point, this function reserves space for inline xattrs at the destination inode without even checking if there is space at the root metadata block. It simply reduces the l_count from 243 to 227 thereby making space of 256 bytes for inline xattr whereas the inode already has extents beyond this index (in this case up to 230), thereby causing corruption. The fix for this is to reserve space for inline metadata at the destination inode before the reflink tree gets recreated. The customer has verified the fix.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49959", "url": "https://ubuntu.com/security/CVE-2024-49959", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail() to recover some journal space. But if an error occurs while executing jbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for free space right away, we try other branches, and if j_committing_transaction is NULL (i.e., the tid is 0), we will get the following complain: ============================================ JBD2: I/O error when updating journal superblock for sdd-8. __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available __jbd2_log_wait_for_space: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Call Trace: add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70 [...] ============================================ So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways. Note that this fix relies on commit 6f6a6fda2945 (\"jbd2: fix ocfs2 corrupt when updating journal superblock fails\") to make jbd2_cleanup_journal_tail return the correct error code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49878", "url": "https://ubuntu.com/security/CVE-2024-49878", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: resource: fix region_intersects() vs add_memory_driver_managed() On a system with CXL memory, the resource tree (/proc/iomem) related to CXL memory may look like something as follows. 490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem) Because drivers/dax/kmem.c calls add_memory_driver_managed() during onlining CXL memory, which makes \"System RAM (kmem)\" a descendant of \"CXL Window X\". This confuses region_intersects(), which expects all \"System RAM\" resources to be at the top level of iomem_resource. This can lead to bugs. For example, when the following command line is executed to write some memory in CXL memory range via /dev/mem, $ dd if=data of=/dev/mem bs=$((1 << 10)) seek=$((0x490000000 >> 10)) count=1 dd: error writing '/dev/mem': Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/s the command fails as expected. However, the error code is wrong. It should be \"Operation not permitted\" instead of \"Bad address\". More seriously, the /dev/mem permission checking in devmem_is_allowed() passes incorrectly. Although the accessing is prevented later because ioremap() isn't allowed to map system RAM, it is a potential security issue. During command executing, the following warning is reported in the kernel log for calling ioremap() on system RAM. ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d Call Trace: memremap+0xcb/0x184 xlate_dev_mem_ptr+0x25/0x2f write_mem+0x94/0xfb vfs_write+0x128/0x26d ksys_write+0xac/0xfe do_syscall_64+0x9a/0xfd entry_SYSCALL_64_after_hwframe+0x4b/0x53 The details of command execution process are as follows. In the above resource tree, \"System RAM\" is a descendant of \"CXL Window 0\" instead of a top level resource. So, region_intersects() will report no System RAM resources in the CXL memory region incorrectly, because it only checks the top level resources. Consequently, devmem_is_allowed() will return 1 (allow access via /dev/mem) for CXL memory region incorrectly. Fortunately, ioremap() doesn't allow to map System RAM and reject the access. So, region_intersects() needs to be fixed to work correctly with the resource tree with \"System RAM\" not at top level as above. To fix it, if we found a unmatched resource in the top level, we will continue to search matched resources in its descendant resources. So, we will not miss any matched resources in resource tree anymore. In the new implementation, an example resource tree |------------- \"CXL Window 0\" ------------| |-- \"System RAM\" --| will behave similar as the following fake resource tree for region_intersects(, IORESOURCE_SYSTEM_RAM, ), |-- \"System RAM\" --||-- \"CXL Window 0a\" --| Where \"CXL Window 0a\" is part of the original \"CXL Window 0\" that isn't covered by \"System RAM\".", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49879", "url": "https://ubuntu.com/security/CVE-2024-49879", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm: omapdrm: Add missing check for alloc_ordered_workqueue As it may return NULL pointer and cause NULL pointer dereference. Add check for the return value of alloc_ordered_workqueue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49880", "url": "https://ubuntu.com/security/CVE-2024-49880", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix off by one issue in alloc_flex_gd() Wesley reported an issue: ================================================================== EXT4-fs (dm-5): resizing filesystem from 7168 to 786432 blocks ------------[ cut here ]------------ kernel BUG at fs/ext4/resize.c:324! CPU: 9 UID: 0 PID: 3576 Comm: resize2fs Not tainted 6.11.0+ #27 RIP: 0010:ext4_resize_fs+0x1212/0x12d0 Call Trace: __ext4_ioctl+0x4e0/0x1800 ext4_ioctl+0x12/0x20 __x64_sys_ioctl+0x99/0xd0 x64_sys_call+0x1206/0x20d0 do_syscall_64+0x72/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e ================================================================== While reviewing the patch, Honza found that when adjusting resize_bg in alloc_flex_gd(), it was possible for flex_gd->resize_bg to be bigger than flexbg_size. The reproduction of the problem requires the following: o_group = flexbg_size * 2 * n; o_size = (o_group + 1) * group_size; n_group: [o_group + flexbg_size, o_group + flexbg_size * 2) o_size = (n_group + 1) * group_size; Take n=0,flexbg_size=16 as an example: last:15 |o---------------|--------------n-| o_group:0 resize to n_group:30 The corresponding reproducer is: img=test.img rm -f $img truncate -s 600M $img mkfs.ext4 -F $img -b 1024 -G 16 8M dev=`losetup -f --show $img` mkdir -p /tmp/test mount $dev /tmp/test resize2fs $dev 248M Delete the problematic plus 1 to fix the issue, and add a WARN_ON_ONCE() to prevent the issue from happening again. [ Note: another reproucer which this commit fixes is: img=test.img rm -f $img truncate -s 25MiB $img mkfs.ext4 -b 4096 -E nodiscard,lazy_itable_init=0,lazy_journal_init=0 $img truncate -s 3GiB $img dev=`losetup -f --show $img` mkdir -p /tmp/test mount $dev /tmp/test resize2fs $dev 3G umount $dev losetup -d $dev -- TYT ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49881", "url": "https://ubuntu.com/security/CVE-2024-49881", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: update orig_path in ext4_find_extent() In ext4_find_extent(), if the path is not big enough, we free it and set *orig_path to NULL. But after reallocating and successfully initializing the path, we don't update *orig_path, in which case the caller gets a valid path but a NULL ppath, and this may cause a NULL pointer dereference or a path memory leak. For example: ext4_split_extent path = *ppath = 2000 ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path = 2000); *orig_path = path = NULL; path = kcalloc() = 3000 ext4_split_extent_at(*ppath = NULL) path = *ppath; ex = path[depth].p_ext; // NULL pointer dereference! ================================================================== BUG: kernel NULL pointer dereference, address: 0000000000000010 CPU: 6 UID: 0 PID: 576 Comm: fsstress Not tainted 6.11.0-rc2-dirty #847 RIP: 0010:ext4_split_extent_at+0x6d/0x560 Call Trace: ext4_split_extent.isra.0+0xcb/0x1b0 ext4_ext_convert_to_initialized+0x168/0x6c0 ext4_ext_handle_unwritten_extents+0x325/0x4d0 ext4_ext_map_blocks+0x520/0xdb0 ext4_map_blocks+0x2b0/0x690 ext4_iomap_begin+0x20e/0x2c0 [...] ================================================================== Therefore, *orig_path is updated when the extent lookup succeeds, so that the caller can safely use path or *ppath.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50014", "url": "https://ubuntu.com/security/CVE-2024-50014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix access to uninitialised lock in fc replay path The following kernel trace can be triggered with fstest generic/629 when executed against a filesystem with fast-commit feature enabled: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x66/0x90 register_lock_class+0x759/0x7d0 __lock_acquire+0x85/0x2630 ? __find_get_block+0xb4/0x380 lock_acquire+0xd1/0x2d0 ? __ext4_journal_get_write_access+0xd5/0x160 _raw_spin_lock+0x33/0x40 ? __ext4_journal_get_write_access+0xd5/0x160 __ext4_journal_get_write_access+0xd5/0x160 ext4_reserve_inode_write+0x61/0xb0 __ext4_mark_inode_dirty+0x79/0x270 ? ext4_ext_replay_set_iblocks+0x2f8/0x450 ext4_ext_replay_set_iblocks+0x330/0x450 ext4_fc_replay+0x14c8/0x1540 ? jread+0x88/0x2e0 ? rcu_is_watching+0x11/0x40 do_one_pass+0x447/0xd00 jbd2_journal_recover+0x139/0x1b0 jbd2_journal_load+0x96/0x390 ext4_load_and_init_journal+0x253/0xd40 ext4_fill_super+0x2cc6/0x3180 ... In the replay path there's an attempt to lock sbi->s_bdev_wb_lock in function ext4_check_bdev_write_error(). Unfortunately, at this point this spinlock has not been initialized yet. Moving it's initialization to an earlier point in __ext4_fill_super() fixes this splat.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49960", "url": "https://ubuntu.com/security/CVE-2024-49960", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix timer use-after-free on failed mount Syzbot has found an ODEBUG bug in ext4_fill_super The del_timer_sync function cancels the s_err_report timer, which reminds about filesystem errors daily. We should guarantee the timer is no longer active before kfree(sbi). When filesystem mounting fails, the flow goes to failed_mount3, where an error occurs when ext4_stop_mmpd is called, causing a read I/O failure. This triggers the ext4_handle_error function that ultimately re-arms the timer, leaving the s_err_report timer active before kfree(sbi) is called. Fix the issue by canceling the s_err_report timer after calling ext4_stop_mmpd.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49882", "url": "https://ubuntu.com/security/CVE-2024-49882", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix double brelse() the buffer of the extents path In ext4_ext_try_to_merge_up(), set path[1].p_bh to NULL after it has been released, otherwise it may be released twice. An example of what triggers this is as follows: split2 map split1 |--------|-------|--------| ext4_ext_map_blocks ext4_ext_handle_unwritten_extents ext4_split_convert_extents // path->p_depth == 0 ext4_split_extent // 1. do split1 ext4_split_extent_at |ext4_ext_insert_extent | ext4_ext_create_new_leaf | ext4_ext_grow_indepth | le16_add_cpu(&neh->eh_depth, 1) | ext4_find_extent | // return -ENOMEM |// get error and try zeroout |path = ext4_find_extent | path->p_depth = 1 |ext4_ext_try_to_merge | ext4_ext_try_to_merge_up | path->p_depth = 0 | brelse(path[1].p_bh) ---> not set to NULL here |// zeroout success // 2. update path ext4_find_extent // 3. do split2 ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth le16_add_cpu(&neh->eh_depth, 1) ext4_find_extent path[0].p_bh = NULL; path->p_depth = 1 read_extent_tree_block ---> return err // path[1].p_bh is still the old value ext4_free_ext_path ext4_ext_drop_refs // path->p_depth == 1 brelse(path[1].p_bh) ---> brelse a buffer twice Finally got the following WARRNING when removing the buffer from lru: ============================================ VFS: brelse: Trying to free free buffer WARNING: CPU: 2 PID: 72 at fs/buffer.c:1241 __brelse+0x58/0x90 CPU: 2 PID: 72 Comm: kworker/u19:1 Not tainted 6.9.0-dirty #716 RIP: 0010:__brelse+0x58/0x90 Call Trace: __find_get_block+0x6e7/0x810 bdev_getblk+0x2b/0x480 __ext4_get_inode_loc+0x48a/0x1240 ext4_get_inode_loc+0xb2/0x150 ext4_reserve_inode_write+0xb7/0x230 __ext4_mark_inode_dirty+0x144/0x6a0 ext4_ext_insert_extent+0x9c8/0x3230 ext4_ext_map_blocks+0xf45/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] ============================================", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49883", "url": "https://ubuntu.com/security/CVE-2024-49883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: aovid use-after-free in ext4_ext_insert_extent() As Ojaswin mentioned in Link, in ext4_ext_insert_extent(), if the path is reallocated in ext4_ext_create_new_leaf(), we'll use the stale path and cause UAF. Below is a sample trace with dummy values: ext4_ext_insert_extent path = *ppath = 2000 ext4_ext_create_new_leaf(ppath) ext4_find_extent(ppath) path = *ppath = 2000 if (depth > path[0].p_maxdepth) kfree(path = 2000); *ppath = path = NULL; path = kcalloc() = 3000 *ppath = 3000; return path; /* here path is still 2000, UAF! */ eh = path[depth].p_hdr ================================================================== BUG: KASAN: slab-use-after-free in ext4_ext_insert_extent+0x26d4/0x3330 Read of size 8 at addr ffff8881027bf7d0 by task kworker/u36:1/179 CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 Not tainted 6.11.0-rc2-dirty #866 Call Trace: ext4_ext_insert_extent+0x26d4/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 [...] Allocated by task 179: ext4_find_extent+0x81c/0x1f70 ext4_ext_map_blocks+0x146/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...] Freed by task 179: kfree+0xcb/0x240 ext4_find_extent+0x7c0/0x1f70 ext4_ext_insert_extent+0xa26/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...] ================================================================== So use *ppath to update the path to avoid the above problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49983", "url": "https://ubuntu.com/security/CVE-2024-49983", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-free When calling ext4_force_split_extent_at() in ext4_ext_replay_update_ex(), the 'ppath' is updated but it is the 'path' that is freed, thus potentially triggering a double-free in the following process: ext4_ext_replay_update_ex ppath = path ext4_force_split_extent_at(&ppath) ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path) ---> path First freed *orig_path = path = NULL ---> null ppath kfree(path) ---> path double-free !!! So drop the unnecessary ppath and use path directly to avoid this problem. And use ext4_find_extent() directly to update path, avoiding unnecessary memory allocation and freeing. Also, propagate the error returned by ext4_find_extent() instead of using strange error codes.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50015", "url": "https://ubuntu.com/security/CVE-2024-50015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: dax: fix overflowing extents beyond inode size when partially writing The dax_iomap_rw() does two things in each iteration: map written blocks and copy user data to blocks. If the process is killed by user(See signal handling in dax_iomap_iter()), the copied data will be returned and added on inode size, which means that the length of written extents may exceed the inode size, then fsck will fail. An example is given as: dd if=/dev/urandom of=file bs=4M count=1 dax_iomap_rw iomap_iter // round 1 ext4_iomap_begin ext4_iomap_alloc // allocate 0~2M extents(written flag) dax_iomap_iter // copy 2M data iomap_iter // round 2 iomap_iter_advance iter->pos += iter->processed // iter->pos = 2M ext4_iomap_begin ext4_iomap_alloc // allocate 2~4M extents(written flag) dax_iomap_iter fatal_signal_pending done = iter->pos - iocb->ki_pos // done = 2M ext4_handle_inode_extension ext4_update_inode_size // inode size = 2M fsck reports: Inode 13, i_size is 2097152, should be 4194304. Fix? Fix the problem by truncating extents if the written length is smaller than expected.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49884", "url": "https://ubuntu.com/security/CVE-2024-49884", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix slab-use-after-free in ext4_split_extent_at() We hit the following use-after-free: ================================================================== BUG: KASAN: slab-use-after-free in ext4_split_extent_at+0xba8/0xcc0 Read of size 2 at addr ffff88810548ed08 by task kworker/u20:0/40 CPU: 0 PID: 40 Comm: kworker/u20:0 Not tainted 6.9.0-dirty #724 Call Trace: kasan_report+0x93/0xc0 ext4_split_extent_at+0xba8/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] Allocated by task 40: __kmalloc_noprof+0x1ac/0x480 ext4_find_extent+0xf3b/0x1e70 ext4_ext_map_blocks+0x188/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] Freed by task 40: kfree+0xf1/0x2b0 ext4_find_extent+0xa71/0x1e70 ext4_ext_insert_extent+0xa22/0x3260 ext4_split_extent_at+0x3ef/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] ================================================================== The flow of issue triggering is as follows: ext4_split_extent_at path = *ppath ext4_ext_insert_extent(ppath) ext4_ext_create_new_leaf(ppath) ext4_find_extent(orig_path) path = *orig_path read_extent_tree_block // return -ENOMEM or -EIO ext4_free_ext_path(path) kfree(path) *orig_path = NULL a. If err is -ENOMEM: ext4_ext_dirty(path + path->p_depth) // path use-after-free !!! b. If err is -EIO and we have EXT_DEBUG defined: ext4_ext_show_leaf(path) eh = path[depth].p_hdr // path also use-after-free !!! So when trying to zeroout or fix the extent length, call ext4_find_extent() to update the path. In addition we use *ppath directly as an ext4_ext_show_leaf() input to avoid possible use-after-free when EXT_DEBUG is defined, and to avoid unnecessary path updates.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49885", "url": "https://ubuntu.com/security/CVE-2024-49885", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm, slub: avoid zeroing kmalloc redzone Since commit 946fa0dbf2d8 (\"mm/slub: extend redzone check to extra allocated kmalloc space than requested\"), setting orig_size treats the wasted space (object_size - orig_size) as a redzone. However with init_on_free=1 we clear the full object->size, including the redzone. Additionally we clear the object metadata, including the stored orig_size, making it zero, which makes check_object() treat the whole object as a redzone. These issues lead to the following BUG report with \"slub_debug=FUZ init_on_free=1\": [ 0.000000] ============================================================================= [ 0.000000] BUG kmalloc-8 (Not tainted): kmalloc Redzone overwritten [ 0.000000] ----------------------------------------------------------------------------- [ 0.000000] [ 0.000000] 0xffff000010032858-0xffff00001003285f @offset=2136. First byte 0x0 instead of 0xcc [ 0.000000] FIX kmalloc-8: Restoring kmalloc Redzone 0xffff000010032858-0xffff00001003285f=0xcc [ 0.000000] Slab 0xfffffdffc0400c80 objects=36 used=23 fp=0xffff000010032a18 flags=0x3fffe0000000200(workingset|node=0|zone=0|lastcpupid=0x1ffff) [ 0.000000] Object 0xffff000010032858 @offset=2136 fp=0xffff0000100328c8 [ 0.000000] [ 0.000000] Redzone ffff000010032850: cc cc cc cc cc cc cc cc ........ [ 0.000000] Object ffff000010032858: cc cc cc cc cc cc cc cc ........ [ 0.000000] Redzone ffff000010032860: cc cc cc cc cc cc cc cc ........ [ 0.000000] Padding ffff0000100328b4: 00 00 00 00 00 00 00 00 00 00 00 00 ............ [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.11.0-rc3-next-20240814-00004-g61844c55c3f4 #144 [ 0.000000] Hardware name: NXP i.MX95 19X19 board (DT) [ 0.000000] Call trace: [ 0.000000] dump_backtrace+0x90/0xe8 [ 0.000000] show_stack+0x18/0x24 [ 0.000000] dump_stack_lvl+0x74/0x8c [ 0.000000] dump_stack+0x18/0x24 [ 0.000000] print_trailer+0x150/0x218 [ 0.000000] check_object+0xe4/0x454 [ 0.000000] free_to_partial_list+0x2f8/0x5ec To address the issue, use orig_size to clear the used area. And restore the value of orig_size after clear the remaining area. When CONFIG_SLUB_DEBUG not defined, (get_orig_size()' directly returns s->object_size. So when using memset to init the area, the size can simply be orig_size, as orig_size returns object_size when CONFIG_SLUB_DEBUG not enabled. And orig_size can never be bigger than object_size.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49961", "url": "https://ubuntu.com/security/CVE-2024-49961", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: ar0521: Use cansleep version of gpiod_set_value() If we use GPIO reset from I2C port expander, we must use *_cansleep() variant of GPIO functions. This was not done in ar0521_power_on()/ar0521_power_off() functions. Let's fix that. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 11 at drivers/gpio/gpiolib.c:3496 gpiod_set_value+0x74/0x7c Modules linked in: CPU: 0 PID: 11 Comm: kworker/u16:0 Not tainted 6.10.0 #53 Hardware name: Diasom DS-RK3568-SOM-EVB (DT) Workqueue: events_unbound deferred_probe_work_func pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : gpiod_set_value+0x74/0x7c lr : ar0521_power_on+0xcc/0x290 sp : ffffff8001d7ab70 x29: ffffff8001d7ab70 x28: ffffff80027dcc90 x27: ffffff8003c82000 x26: ffffff8003ca9250 x25: ffffffc080a39c60 x24: ffffff8003ca9088 x23: ffffff8002402720 x22: ffffff8003ca9080 x21: ffffff8003ca9088 x20: 0000000000000000 x19: ffffff8001eb2a00 x18: ffffff80efeeac80 x17: 756d2d6332692f30 x16: 0000000000000000 x15: 0000000000000000 x14: ffffff8001d91d40 x13: 0000000000000016 x12: ffffffc080e98930 x11: ffffff8001eb2880 x10: 0000000000000890 x9 : ffffff8001d7a9f0 x8 : ffffff8001d92570 x7 : ffffff80efeeac80 x6 : 000000003fc6e780 x5 : ffffff8001d91c80 x4 : 0000000000000002 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000001 Call trace: gpiod_set_value+0x74/0x7c ar0521_power_on+0xcc/0x290 ...", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49985", "url": "https://ubuntu.com/security/CVE-2024-49985", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume In case there is any sort of clock controller attached to this I2C bus controller, for example Versaclock or even an AIC32x4 I2C codec, then an I2C transfer triggered from the clock controller clk_ops .prepare callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex. This is because the clock controller first grabs the prepare_lock mutex and then performs the prepare operation, including its I2C access. The I2C access resumes this I2C bus controller via .runtime_resume callback, which calls clk_prepare_enable(), which attempts to grab the prepare_lock mutex again and deadlocks. Since the clock are already prepared since probe() and unprepared in remove(), use simple clk_enable()/clk_disable() calls to enable and disable the clock on runtime suspend and resume, to avoid hitting the prepare_lock mutex.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49886", "url": "https://ubuntu.com/security/CVE-2024-49886", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bug Attaching SST PCI device to VM causes \"BUG: KASAN: slab-out-of-bounds\". kasan report: [ 19.411889] ================================================================== [ 19.413702] BUG: KASAN: slab-out-of-bounds in _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.415634] Read of size 8 at addr ffff888829e65200 by task cpuhp/16/113 [ 19.417368] [ 19.418627] CPU: 16 PID: 113 Comm: cpuhp/16 Tainted: G E 6.9.0 #10 [ 19.420435] Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.20192059.B64.2207280713 07/28/2022 [ 19.422687] Call Trace: [ 19.424091] [ 19.425448] dump_stack_lvl+0x5d/0x80 [ 19.426963] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.428694] print_report+0x19d/0x52e [ 19.430206] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 19.431837] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.433539] kasan_report+0xf0/0x170 [ 19.435019] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.436709] _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.438379] ? __pfx_sched_clock_cpu+0x10/0x10 [ 19.439910] isst_if_cpu_online+0x406/0x58f [isst_if_common] [ 19.441573] ? __pfx_isst_if_cpu_online+0x10/0x10 [isst_if_common] [ 19.443263] ? ttwu_queue_wakelist+0x2c1/0x360 [ 19.444797] cpuhp_invoke_callback+0x221/0xec0 [ 19.446337] cpuhp_thread_fun+0x21b/0x610 [ 19.447814] ? __pfx_cpuhp_thread_fun+0x10/0x10 [ 19.449354] smpboot_thread_fn+0x2e7/0x6e0 [ 19.450859] ? __pfx_smpboot_thread_fn+0x10/0x10 [ 19.452405] kthread+0x29c/0x350 [ 19.453817] ? __pfx_kthread+0x10/0x10 [ 19.455253] ret_from_fork+0x31/0x70 [ 19.456685] ? __pfx_kthread+0x10/0x10 [ 19.458114] ret_from_fork_asm+0x1a/0x30 [ 19.459573] [ 19.460853] [ 19.462055] Allocated by task 1198: [ 19.463410] kasan_save_stack+0x30/0x50 [ 19.464788] kasan_save_track+0x14/0x30 [ 19.466139] __kasan_kmalloc+0xaa/0xb0 [ 19.467465] __kmalloc+0x1cd/0x470 [ 19.468748] isst_if_cdev_register+0x1da/0x350 [isst_if_common] [ 19.470233] isst_if_mbox_init+0x108/0xff0 [isst_if_mbox_msr] [ 19.471670] do_one_initcall+0xa4/0x380 [ 19.472903] do_init_module+0x238/0x760 [ 19.474105] load_module+0x5239/0x6f00 [ 19.475285] init_module_from_file+0xd1/0x130 [ 19.476506] idempotent_init_module+0x23b/0x650 [ 19.477725] __x64_sys_finit_module+0xbe/0x130 [ 19.476506] idempotent_init_module+0x23b/0x650 [ 19.477725] __x64_sys_finit_module+0xbe/0x130 [ 19.478920] do_syscall_64+0x82/0x160 [ 19.480036] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 19.481292] [ 19.482205] The buggy address belongs to the object at ffff888829e65000 which belongs to the cache kmalloc-512 of size 512 [ 19.484818] The buggy address is located 0 bytes to the right of allocated 512-byte region [ffff888829e65000, ffff888829e65200) [ 19.487447] [ 19.488328] The buggy address belongs to the physical page: [ 19.489569] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888829e60c00 pfn:0x829e60 [ 19.491140] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [ 19.492466] anon flags: 0x57ffffc0000840(slab|head|node=1|zone=2|lastcpupid=0x1fffff) [ 19.493914] page_type: 0xffffffff() [ 19.494988] raw: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [ 19.496451] raw: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [ 19.497906] head: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [ 19.499379] head: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [ 19.500844] head: 0057ffffc0000003 ffffea0020a79801 ffffea0020a79848 00000000ffffffff [ 19.502316] head: 0000000800000000 0000000000000000 00000000ffffffff 0000000000000000 [ 19.503784] page dumped because: k ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49986", "url": "https://ubuntu.com/security/CVE-2024-49986", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: x86-android-tablets: Fix use after free on platform_device_register() errors x86_android_tablet_remove() frees the pdevs[] array, so it should not be used after calling x86_android_tablet_remove(). When platform_device_register() fails, store the pdevs[x] PTR_ERR() value into the local ret variable before calling x86_android_tablet_remove() to avoid using pdevs[] after it has been freed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49887", "url": "https://ubuntu.com/security/CVE-2024-49887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to don't panic system for no free segment fault injection f2fs: fix to don't panic system for no free segment fault injection syzbot reports a f2fs bug as below: F2FS-fs (loop0): inject no free segment in get_new_segment of __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3167 F2FS-fs (loop0): Stopped filesystem due to reason: 7 ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2748! CPU: 0 UID: 0 PID: 5109 Comm: syz-executor304 Not tainted 6.11.0-rc6-syzkaller-00363-g89f5e14d05b4 #0 RIP: 0010:get_new_segment fs/f2fs/segment.c:2748 [inline] RIP: 0010:new_curseg+0x1f61/0x1f70 fs/f2fs/segment.c:2836 Call Trace: __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3167 f2fs_allocate_new_section fs/f2fs/segment.c:3181 [inline] f2fs_allocate_pinning_section+0xfa/0x4e0 fs/f2fs/segment.c:3195 f2fs_expand_inode_data+0x5d6/0xbb0 fs/f2fs/file.c:1799 f2fs_fallocate+0x448/0x960 fs/f2fs/file.c:1903 vfs_fallocate+0x553/0x6c0 fs/open.c:334 do_vfs_ioctl+0x2592/0x2e50 fs/ioctl.c:886 __do_sys_ioctl fs/ioctl.c:905 [inline] __se_sys_ioctl+0x81/0x170 fs/ioctl.c:893 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: 0010:get_new_segment fs/f2fs/segment.c:2748 [inline] RIP: 0010:new_curseg+0x1f61/0x1f70 fs/f2fs/segment.c:2836 The root cause is when we inject no free segment fault into f2fs, we should not panic system, fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49888", "url": "https://ubuntu.com/security/CVE-2024-49888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix a sdiv overflow issue Zac Ecob reported a problem where a bpf program may cause kernel crash due to the following error: Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI The failure is due to the below signed divide: LLONG_MIN/-1 where LLONG_MIN equals to -9,223,372,036,854,775,808. LLONG_MIN/-1 is supposed to give a positive number 9,223,372,036,854,775,808, but it is impossible since for 64-bit system, the maximum positive number is 9,223,372,036,854,775,807. On x86_64, LLONG_MIN/-1 will cause a kernel exception. On arm64, the result for LLONG_MIN/-1 is LLONG_MIN. Further investigation found all the following sdiv/smod cases may trigger an exception when bpf program is running on x86_64 platform: - LLONG_MIN/-1 for 64bit operation - INT_MIN/-1 for 32bit operation - LLONG_MIN%-1 for 64bit operation - INT_MIN%-1 for 32bit operation where -1 can be an immediate or in a register. On arm64, there are no exceptions: - LLONG_MIN/-1 = LLONG_MIN - INT_MIN/-1 = INT_MIN - LLONG_MIN%-1 = 0 - INT_MIN%-1 = 0 where -1 can be an immediate or in a register. Insn patching is needed to handle the above cases and the patched codes produced results aligned with above arm64 result. The below are pseudo codes to handle sdiv/smod exceptions including both divisor -1 and divisor 0 and the divisor is stored in a register. sdiv: tmp = rX tmp += 1 /* [-1, 0] -> [0, 1] if tmp >(unsigned) 1 goto L2 if tmp == 0 goto L1 rY = 0 L1: rY = -rY; goto L3 L2: rY /= rX L3: smod: tmp = rX tmp += 1 /* [-1, 0] -> [0, 1] if tmp >(unsigned) 1 goto L1 if tmp == 1 (is64 ? goto L2 : goto L3) rY = 0; goto L2 L1: rY %= rX L2: goto L4 // only when !is64 L3: wY = wY // only when !is64 L4: [1] https://lore.kernel.org/bpf/tPJLTEh7S_DxFEqAI2Ji5MBSoZVg7_G-Py2iaZpAaWtM961fFTWtsnlzwvTbzBzaUzwQAoNATXKUlt0LZOFgnDcIyKCswAnAGdUF3LBrhGQ=@protonmail.com/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49987", "url": "https://ubuntu.com/security/CVE-2024-49987", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpftool: Fix undefined behavior in qsort(NULL, 0, ...) When netfilter has no entry to display, qsort is called with qsort(NULL, 0, ...). This results in undefined behavior, as UBSan reports: net.c:827:2: runtime error: null pointer passed as argument 1, which is declared to never be null Although the C standard does not explicitly state whether calling qsort with a NULL pointer when the size is 0 constitutes undefined behavior, Section 7.1.4 of the C standard (Use of library functions) mentions: \"Each of the following statements applies unless explicitly stated otherwise in the detailed descriptions that follow: If an argument to a function has an invalid value (such as a value outside the domain of the function, or a pointer outside the address space of the program, or a null pointer, or a pointer to non-modifiable storage when the corresponding parameter is not const-qualified) or a type (after promotion) not expected by a function with variable number of arguments, the behavior is undefined.\" To avoid this, add an early return when nf_link_info is NULL to prevent calling qsort with a NULL pointer.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50006", "url": "https://ubuntu.com/security/CVE-2024-50006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix i_data_sem unlock order in ext4_ind_migrate() Fuzzing reports a possible deadlock in jbd2_log_wait_commit. This issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to require synchronous updates because the file descriptor is opened with O_SYNC. This can lead to the jbd2_journal_stop() function calling jbd2_might_wait_for_commit(), potentially causing a deadlock if the EXT4_IOC_MIGRATE call races with a write(2) system call. This problem only arises when CONFIG_PROVE_LOCKING is enabled. In this case, the jbd2_might_wait_for_commit macro locks jbd2_handle in the jbd2_journal_stop function while i_data_sem is locked. This triggers lockdep because the jbd2_journal_start function might also lock the same jbd2_handle simultaneously. Found by Linux Verification Center (linuxtesting.org) with syzkaller. Rule: add", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49889", "url": "https://ubuntu.com/security/CVE-2024-49889", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid use-after-free in ext4_ext_show_leaf() In ext4_find_extent(), path may be freed by error or be reallocated, so using a previously saved *ppath may have been freed and thus may trigger use-after-free, as follows: ext4_split_extent path = *ppath; ext4_split_extent_at(ppath) path = ext4_find_extent(ppath) ext4_split_extent_at(ppath) // ext4_find_extent fails to free path // but zeroout succeeds ext4_ext_show_leaf(inode, path) eh = path[depth].p_hdr // path use-after-free !!! Similar to ext4_split_extent_at(), we use *ppath directly as an input to ext4_ext_show_leaf(). Fix a spelling error by the way. Same problem in ext4_ext_handle_unwritten_extents(). Since 'path' is only used in ext4_ext_show_leaf(), remove 'path' and use *ppath directly. This issue is triggered only when EXT_DEBUG is defined and therefore does not affect functionality.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49968", "url": "https://ubuntu.com/security/CVE-2024-49968", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: filesystems without casefold feature cannot be mounted with siphash When mounting the ext4 filesystem, if the default hash version is set to DX_HASH_SIPHASH but the casefold feature is not set, exit the mounting.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49988", "url": "https://ubuntu.com/security/CVE-2024-49988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: add refcnt to ksmbd_conn struct When sending an oplock break request, opinfo->conn is used, But freed ->conn can be used on multichannel. This patch add a reference count to the ksmbd_conn struct so that it can be freed when it is no longer used.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49890", "url": "https://ubuntu.com/security/CVE-2024-49890", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: ensure the fw_info is not null before using it This resolves the dereference null return value warning reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49891", "url": "https://ubuntu.com/security/CVE-2024-49891", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata paths When the HBA is undergoing a reset or is handling an errata event, NULL ptr dereference crashes may occur in routines such as lpfc_sli_flush_io_rings(), lpfc_dev_loss_tmo_callbk(), or lpfc_abort_handler(). Add NULL ptr checks before dereferencing hdwq pointers that may have been freed due to operations colliding with a reset or errata event handler.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49892", "url": "https://ubuntu.com/security/CVE-2024-49892", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize get_bytes_per_element's default to 1 Variables, used as denominators and maybe not assigned to other values, should not be 0. bytes_per_element_y & bytes_per_element_c are initialized by get_bytes_per_element() which should never return 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50016", "url": "https://ubuntu.com/security/CVE-2024-50016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Avoid overflow assignment in link_dp_cts sampling_rate is an uint8_t but is assigned an unsigned int, and thus it can overflow. As a result, sampling_rate is changed to uint32_t. Similarly, LINK_QUAL_PATTERN_SET has a size of 2 bits, and it should only be assigned to a value less or equal than 4. This fixes 2 INTEGER_OVERFLOW issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49893", "url": "https://ubuntu.com/security/CVE-2024-49893", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check stream_status before it is used [WHAT & HOW] dc_state_get_stream_status can return null, and therefore null must be checked before stream_status is used. This fixes 1 NULL_RETURNS issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49969", "url": "https://ubuntu.com/security/CVE-2024-49969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 color transformation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_hw_format` function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:180 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:181 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:182 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49970", "url": "https://ubuntu.com/security/CVE-2024-49970", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Implement bounds check for stream encoder creation in DCN401 'stream_enc_regs' array is an array of dcn10_stream_enc_registers structures. The array is initialized with four elements, corresponding to the four calls to stream_enc_regs() in the array initializer. This means that valid indices for this array are 0, 1, 2, and 3. The error message 'stream_enc_regs' 4 <= 5 below, is indicating that there is an attempt to access this array with an index of 5, which is out of bounds. This could lead to undefined behavior Here, eng_id is used as an index to access the stream_enc_regs array. If eng_id is 5, this would result in an out-of-bounds access on the stream_enc_regs array. Thus fixing Buffer overflow error in dcn401_stream_encoder_create Found by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn401/dcn401_resource.c:1209 dcn401_stream_encoder_create() error: buffer overflow 'stream_enc_regs' 4 <= 5", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49894", "url": "https://ubuntu.com/security/CVE-2024-49894", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in degamma hardware format translation Fixes index out of bounds issue in `cm_helper_translate_curve_to_degamma_hw_format` function. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49895", "url": "https://ubuntu.com/security/CVE-2024-49895", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format translation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_degamma_hw_format` function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:338 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:339 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:340 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49971", "url": "https://ubuntu.com/security/CVE-2024-49971", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Increase array size of dummy_boolean [WHY] dml2_core_shared_mode_support and dml_core_mode_support access the third element of dummy_boolean, i.e. hw_debug5 = &s->dummy_boolean[2], when dummy_boolean has size of 2. Any assignment to hw_debug5 causes an OVERRUN. [HOW] Increase dummy_boolean's array size to 3. This fixes 2 OVERRUN issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49972", "url": "https://ubuntu.com/security/CVE-2024-49972", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Deallocate DML memory if allocation fails [Why] When DC state create DML memory allocation fails, memory is not deallocated subsequently, resulting in uninitialized structure that is not NULL. [How] Deallocate memory if DML memory allocation fails.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49896", "url": "https://ubuntu.com/security/CVE-2024-49896", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check stream before comparing them [WHAT & HOW] amdgpu_dm can pass a null stream to dc_is_stream_unchanged. It is necessary to check for null before dereferencing them. This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49897", "url": "https://ubuntu.com/security/CVE-2024-49897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check phantom_stream before it is used dcn32_enable_phantom_stream can return null, so returned value must be checked before used. This fixes 1 NULL_RETURNS issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49898", "url": "https://ubuntu.com/security/CVE-2024-49898", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null-initialized variables [WHAT & HOW] drr_timing and subvp_pipe are initialized to null and they are not always assigned new values. It is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49899", "url": "https://ubuntu.com/security/CVE-2024-49899", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize denominators' default to 1 [WHAT & HOW] Variables used as denominators and maybe not assigned to other values, should not be 0. Change their default to 1 so they are never 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49900", "url": "https://ubuntu.com/security/CVE-2024-49900", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uninit-value access of new_ea in ea_buffer syzbot reports that lzo1x_1_do_compress is using uninit-value: ===================================================== BUG: KMSAN: uninit-value in lzo1x_1_do_compress+0x19f9/0x2510 lib/lzo/lzo1x_compress.c:178 ... Uninit was stored to memory at: ea_put fs/jfs/xattr.c:639 [inline] ... Local variable ea_buf created at: __jfs_setxattr+0x5d/0x1ae0 fs/jfs/xattr.c:662 __jfs_xattr_set+0xe6/0x1f0 fs/jfs/xattr.c:934 ===================================================== The reason is ea_buf->new_ea is not initialized properly. Fix this by using memset to empty its content at the beginning in ea_get().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49901", "url": "https://ubuntu.com/security/CVE-2024-49901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm/adreno: Assign msm_gpu->pdev earlier to avoid nullptrs There are some cases, such as the one uncovered by Commit 46d4efcccc68 (\"drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails\") where msm_gpu_cleanup() : platform_set_drvdata(gpu->pdev, NULL); is called on gpu->pdev == NULL, as the GPU device has not been fully initialized yet. Turns out that there's more than just the aforementioned path that causes this to happen (e.g. the case when there's speedbin data in the catalog, but opp-supported-hw is missing in DT). Assigning msm_gpu->pdev earlier seems like the least painful solution to this, therefore do so. Patchwork: https://patchwork.freedesktop.org/patch/602742/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49902", "url": "https://ubuntu.com/security/CVE-2024-49902", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: check if leafidx greater than num leaves per dmap tree syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf. Shaggy: Modified sanity check to apply to control pages as well as leaf pages.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49903", "url": "https://ubuntu.com/security/CVE-2024-49903", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uaf in dbFreeBits [syzbot reported] ================================================================== BUG: KASAN: slab-use-after-free in __mutex_lock_common kernel/locking/mutex.c:587 [inline] BUG: KASAN: slab-use-after-free in __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 Read of size 8 at addr ffff8880229254b0 by task syz-executor357/5216 CPU: 0 UID: 0 PID: 5216 Comm: syz-executor357 Not tainted 6.11.0-rc3-syzkaller-00156-gd7a5aa4b3c00 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 __mutex_lock_common kernel/locking/mutex.c:587 [inline] __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 dbFreeBits+0x7ea/0xd90 fs/jfs/jfs_dmap.c:2390 dbFreeDmap fs/jfs/jfs_dmap.c:2089 [inline] dbFree+0x35b/0x680 fs/jfs/jfs_dmap.c:409 dbDiscardAG+0x8a9/0xa20 fs/jfs/jfs_dmap.c:1650 jfs_ioc_trim+0x433/0x670 fs/jfs/jfs_discard.c:100 jfs_ioctl+0x2d0/0x3e0 fs/jfs/ioctl.c:131 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 Freed by task 5218: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object+0xe0/0x150 mm/kasan/common.c:240 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2252 [inline] slab_free mm/slub.c:4473 [inline] kfree+0x149/0x360 mm/slub.c:4594 dbUnmount+0x11d/0x190 fs/jfs/jfs_dmap.c:278 jfs_mount_rw+0x4ac/0x6a0 fs/jfs/jfs_mount.c:247 jfs_remount+0x3d1/0x6b0 fs/jfs/super.c:454 reconfigure_super+0x445/0x880 fs/super.c:1083 vfs_cmd_reconfigure fs/fsopen.c:263 [inline] vfs_fsconfig_locked fs/fsopen.c:292 [inline] __do_sys_fsconfig fs/fsopen.c:473 [inline] __se_sys_fsconfig+0xb6e/0xf80 fs/fsopen.c:345 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 [Analysis] There are two paths (dbUnmount and jfs_ioc_trim) that generate race condition when accessing bmap, which leads to the occurrence of uaf. Use the lock s_umount to synchronize them, in order to avoid uaf caused by race condition.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49904", "url": "https://ubuntu.com/security/CVE-2024-49904", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add list empty check to avoid null pointer issue Add list empty check to avoid null pointer issues in some corner cases. - list_for_each_entry_safe()", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49989", "url": "https://ubuntu.com/security/CVE-2024-49989", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix double free issue during amdgpu module unload Flexible endpoints use DIGs from available inflexible endpoints, so only the encoders of inflexible links need to be freed. Otherwise, a double free issue may occur when unloading the amdgpu module. [ 279.190523] RIP: 0010:__slab_free+0x152/0x2f0 [ 279.190577] Call Trace: [ 279.190580] [ 279.190582] ? show_regs+0x69/0x80 [ 279.190590] ? die+0x3b/0x90 [ 279.190595] ? do_trap+0xc8/0xe0 [ 279.190601] ? do_error_trap+0x73/0xa0 [ 279.190605] ? __slab_free+0x152/0x2f0 [ 279.190609] ? exc_invalid_op+0x56/0x70 [ 279.190616] ? __slab_free+0x152/0x2f0 [ 279.190642] ? asm_exc_invalid_op+0x1f/0x30 [ 279.190648] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191096] ? __slab_free+0x152/0x2f0 [ 279.191102] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191469] kfree+0x260/0x2b0 [ 279.191474] dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191821] link_destroy+0xd7/0x130 [amdgpu] [ 279.192248] dc_destruct+0x90/0x270 [amdgpu] [ 279.192666] dc_destroy+0x19/0x40 [amdgpu] [ 279.193020] amdgpu_dm_fini+0x16e/0x200 [amdgpu] [ 279.193432] dm_hw_fini+0x26/0x40 [amdgpu] [ 279.193795] amdgpu_device_fini_hw+0x24c/0x400 [amdgpu] [ 279.194108] amdgpu_driver_unload_kms+0x4f/0x70 [amdgpu] [ 279.194436] amdgpu_pci_remove+0x40/0x80 [amdgpu] [ 279.194632] pci_device_remove+0x3a/0xa0 [ 279.194638] device_remove+0x40/0x70 [ 279.194642] device_release_driver_internal+0x1ad/0x210 [ 279.194647] driver_detach+0x4e/0xa0 [ 279.194650] bus_remove_driver+0x6f/0xf0 [ 279.194653] driver_unregister+0x33/0x60 [ 279.194657] pci_unregister_driver+0x44/0x90 [ 279.194662] amdgpu_exit+0x19/0x1f0 [amdgpu] [ 279.194939] __do_sys_delete_module.isra.0+0x198/0x2f0 [ 279.194946] __x64_sys_delete_module+0x16/0x20 [ 279.194950] do_syscall_64+0x58/0x120 [ 279.194954] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 279.194980] ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49905", "url": "https://ubuntu.com/security/CVE-2024-49905", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for 'afb' in amdgpu_dm_plane_handle_cursor_update (v2) This commit adds a null check for the 'afb' variable in the amdgpu_dm_plane_handle_cursor_update function. Previously, 'afb' was assumed to be null, but was used later in the code without a null check. This could potentially lead to a null pointer dereference. Changes since v1: - Moved the null check for 'afb' to the line where 'afb' is used. (Alex) Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:1298 amdgpu_dm_plane_handle_cursor_update() error: we previously assumed 'afb' could be null (see line 1252)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49906", "url": "https://ubuntu.com/security/CVE-2024-49906", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before try to access it [why & how] Change the order of the pipe_ctx->plane_state check to ensure that plane_state is not null before accessing it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49907", "url": "https://ubuntu.com/security/CVE-2024-49907", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before using dc->clk_mgr [WHY & HOW] dc->clk_mgr is null checked previously in the same function, indicating it might be null. Passing \"dc\" to \"dc->hwss.apply_idle_power_optimizations\", which dereferences null \"dc->clk_mgr\". (The function pointer resolves to \"dcn35_apply_idle_power_optimizations\".) This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49908", "url": "https://ubuntu.com/security/CVE-2024-49908", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for 'afb' in amdgpu_dm_update_cursor (v2) This commit adds a null check for the 'afb' variable in the amdgpu_dm_update_cursor function. Previously, 'afb' was assumed to be null at line 8388, but was used later in the code without a null check. This could potentially lead to a null pointer dereference. Changes since v1: - Moved the null check for 'afb' to the line where 'afb' is used. (Alex) Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:8433 amdgpu_dm_update_cursor() \terror: we previously assumed 'afb' could be null (see line 8388)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50177", "url": "https://ubuntu.com/security/CVE-2024-50177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix a UBSAN warning in DML2.1 When programming phantom pipe, since cursor_width is explicity set to 0, this causes calculation logic to trigger overflow for an unsigned int triggering the kernel's UBSAN check as below: [ 40.962845] UBSAN: shift-out-of-bounds in /tmp/amd.EfpumTkO/amd/amdgpu/../display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c:3312:34 [ 40.962849] shift exponent 4294967170 is too large for 32-bit type 'unsigned int' [ 40.962852] CPU: 1 PID: 1670 Comm: gnome-shell Tainted: G W OE 6.5.0-41-generic #41~22.04.2-Ubuntu [ 40.962854] Hardware name: Gigabyte Technology Co., Ltd. X670E AORUS PRO X/X670E AORUS PRO X, BIOS F21 01/10/2024 [ 40.962856] Call Trace: [ 40.962857] [ 40.962860] dump_stack_lvl+0x48/0x70 [ 40.962870] dump_stack+0x10/0x20 [ 40.962872] __ubsan_handle_shift_out_of_bounds+0x1ac/0x360 [ 40.962878] calculate_cursor_req_attributes.cold+0x1b/0x28 [amdgpu] [ 40.963099] dml_core_mode_support+0x6b91/0x16bc0 [amdgpu] [ 40.963327] ? srso_alias_return_thunk+0x5/0x7f [ 40.963331] ? CalculateWatermarksMALLUseAndDRAMSpeedChangeSupport+0x18b8/0x2790 [amdgpu] [ 40.963534] ? srso_alias_return_thunk+0x5/0x7f [ 40.963536] ? dml_core_mode_support+0xb3db/0x16bc0 [amdgpu] [ 40.963730] dml2_core_calcs_mode_support_ex+0x2c/0x90 [amdgpu] [ 40.963906] ? srso_alias_return_thunk+0x5/0x7f [ 40.963909] ? dml2_core_calcs_mode_support_ex+0x2c/0x90 [amdgpu] [ 40.964078] core_dcn4_mode_support+0x72/0xbf0 [amdgpu] [ 40.964247] dml2_top_optimization_perform_optimization_phase+0x1d3/0x2a0 [amdgpu] [ 40.964420] dml2_build_mode_programming+0x23d/0x750 [amdgpu] [ 40.964587] dml21_validate+0x274/0x770 [amdgpu] [ 40.964761] ? srso_alias_return_thunk+0x5/0x7f [ 40.964763] ? resource_append_dpp_pipes_for_plane_composition+0x27c/0x3b0 [amdgpu] [ 40.964942] dml2_validate+0x504/0x750 [amdgpu] [ 40.965117] ? dml21_copy+0x95/0xb0 [amdgpu] [ 40.965291] ? srso_alias_return_thunk+0x5/0x7f [ 40.965295] dcn401_validate_bandwidth+0x4e/0x70 [amdgpu] [ 40.965491] update_planes_and_stream_state+0x38d/0x5c0 [amdgpu] [ 40.965672] update_planes_and_stream_v3+0x52/0x1e0 [amdgpu] [ 40.965845] ? srso_alias_return_thunk+0x5/0x7f [ 40.965849] dc_update_planes_and_stream+0x71/0xb0 [amdgpu] Fix this by adding a guard for checking cursor width before triggering the size calculation.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49909", "url": "https://ubuntu.com/security/CVE-2024-49909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn32_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn32_set_output_transfer_func function. Previously, set_output_gamma was being checked for null, but then it was being dereferenced without any null check. This could lead to a null pointer dereference if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49910", "url": "https://ubuntu.com/security/CVE-2024-49910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn401_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn401_set_output_transfer_func function. Previously, set_output_gamma was being checked for null, but then it was being dereferenced without any null check. This could lead to a null pointer dereference if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49911", "url": "https://ubuntu.com/security/CVE-2024-49911", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn20_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn20_set_output_transfer_func function. Previously, set_output_gamma was being checked for null at line 1030, but then it was being dereferenced without any null check at line 1048. This could potentially lead to a null pointer dereference error if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma at line 1048.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49912", "url": "https://ubuntu.com/security/CVE-2024-49912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Handle null 'stream_status' in 'planes_changed_for_existing_stream' This commit adds a null check for 'stream_status' in the function 'planes_changed_for_existing_stream'. Previously, the code assumed 'stream_status' could be null, but did not handle the case where it was actually null. This could lead to a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:3784 planes_changed_for_existing_stream() error: we previously assumed 'stream_status' could be null (see line 3774)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49913", "url": "https://ubuntu.com/security/CVE-2024-49913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for top_pipe_to_program in commit_planes_for_stream This commit addresses a null pointer dereference issue in the `commit_planes_for_stream` function at line 4140. The issue could occur when `top_pipe_to_program` is null. The fix adds a check to ensure `top_pipe_to_program` is not null before accessing its stream_res. This prevents a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:4140 commit_planes_for_stream() error: we previously assumed 'top_pipe_to_program' could be null (see line 3906)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49914", "url": "https://ubuntu.com/security/CVE-2024-49914", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for pipe_ctx->plane_state in dcn20_program_pipe This commit addresses a null pointer dereference issue in the `dcn20_program_pipe` function. The issue could occur when `pipe_ctx->plane_state` is null. The fix adds a check to ensure `pipe_ctx->plane_state` is not null before accessing. This prevents a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn20/dcn20_hwseq.c:1925 dcn20_program_pipe() error: we previously assumed 'pipe_ctx->plane_state' could be null (see line 1877)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49915", "url": "https://ubuntu.com/security/CVE-2024-49915", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr in dcn32_init_hw This commit addresses a potential null pointer dereference issue in the `dcn32_init_hw` function. The issue could occur when `dc->clk_mgr` is null. The fix adds a check to ensure `dc->clk_mgr` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn32/dcn32_hwseq.c:961 dcn32_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 782)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49916", "url": "https://ubuntu.com/security/CVE-2024-49916", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in dcn401_init_hw This commit addresses a potential null pointer dereference issue in the `dcn401_init_hw` function. The issue could occur when `dc->clk_mgr` or `dc->clk_mgr->funcs` is null. The fix adds a check to ensure `dc->clk_mgr` and `dc->clk_mgr->funcs` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn401/dcn401_hwseq.c:416 dcn401_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 225)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49917", "url": "https://ubuntu.com/security/CVE-2024-49917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in dcn30_init_hw This commit addresses a potential null pointer dereference issue in the `dcn30_init_hw` function. The issue could occur when `dc->clk_mgr` or `dc->clk_mgr->funcs` is null. The fix adds a check to ensure `dc->clk_mgr` and `dc->clk_mgr->funcs` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:789 dcn30_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 628)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49918", "url": "https://ubuntu.com/security/CVE-2024-49918", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for head_pipe in dcn32_acquire_idle_pipe_for_head_pipe_in_layer This commit addresses a potential null pointer dereference issue in the `dcn32_acquire_idle_pipe_for_head_pipe_in_layer` function. The issue could occur when `head_pipe` is null. The fix adds a check to ensure `head_pipe` is not null before asserting it. If `head_pipe` is null, the function returns NULL to prevent a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn32/dcn32_resource.c:2690 dcn32_acquire_idle_pipe_for_head_pipe_in_layer() error: we previously assumed 'head_pipe' could be null (see line 2681)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49919", "url": "https://ubuntu.com/security/CVE-2024-49919", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for head_pipe in dcn201_acquire_free_pipe_for_layer This commit addresses a potential null pointer dereference issue in the `dcn201_acquire_free_pipe_for_layer` function. The issue could occur when `head_pipe` is null. The fix adds a check to ensure `head_pipe` is not null before asserting it. If `head_pipe` is null, the function returns NULL to prevent a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn201/dcn201_resource.c:1016 dcn201_acquire_free_pipe_for_layer() error: we previously assumed 'head_pipe' could be null (see line 1010)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49991", "url": "https://ubuntu.com/security/CVE-2024-49991", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer Pass pointer reference to amdgpu_bo_unref to clear the correct pointer, otherwise amdgpu_bo_unref clear the local variable, the original pointer not set to NULL, this could cause use-after-free bug.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49920", "url": "https://ubuntu.com/security/CVE-2024-49920", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before multiple uses [WHAT & HOW] Poniters, such as stream_enc and dc->bw_vbios, are null checked previously in the same function, so Coverity warns \"implies that stream_enc and dc->bw_vbios might be null\". They are used multiple times in the subsequent code and need to be checked. This fixes 10 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49921", "url": "https://ubuntu.com/security/CVE-2024-49921", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before used [WHAT & HOW] Poniters, such as dc->clk_mgr, are null checked previously in the same function, so Coverity warns \"implies that \"dc->clk_mgr\" might be null\". As a result, these pointers need to be checked when used again. This fixes 10 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49922", "url": "https://ubuntu.com/security/CVE-2024-49922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before using them [WHAT & HOW] These pointers are null checked previously in the same function, indicating they might be null as reported by Coverity. As a result, they need to be checked when used again. This fixes 3 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49923", "url": "https://ubuntu.com/security/CVE-2024-49923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Pass non-null to dcn20_validate_apply_pipe_split_flags [WHAT & HOW] \"dcn20_validate_apply_pipe_split_flags\" dereferences merge, and thus it cannot be a null pointer. Let's pass a valid pointer to avoid null dereference. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49992", "url": "https://ubuntu.com/security/CVE-2024-49992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/stm: Avoid use-after-free issues with crtc and plane ltdc_load() calls functions drm_crtc_init_with_planes(), drm_universal_plane_init() and drm_encoder_init(). These functions should not be called with parameters allocated with devm_kzalloc() to avoid use-after-free issues [1]. Use allocations managed by the DRM framework. Found by Linux Verification Center (linuxtesting.org). [1] https://lore.kernel.org/lkml/u366i76e3qhh3ra5oxrtngjtm2u5lterkekcz6y2jkndhuxzli@diujon4h7qwb/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49993", "url": "https://ubuntu.com/security/CVE-2024-49993", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49924", "url": "https://ubuntu.com/security/CVE-2024-49924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: pxafb: Fix possible use after free in pxafb_task() In the pxafb_probe function, it calls the pxafb_init_fbinfo function, after which &fbi->task is associated with pxafb_task. Moreover, within this pxafb_init_fbinfo function, the pxafb_blank function within the &pxafb_ops struct is capable of scheduling work. If we remove the module which will call pxafb_remove to make cleanup, it will call unregister_framebuffer function which can call do_unregister_framebuffer to free fbi->fb through put_fb_info(fb_info), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | pxafb_task pxafb_remove | unregister_framebuffer(info) | do_unregister_framebuffer(fb_info) | put_fb_info(fb_info) | // free fbi->fb | set_ctrlr_state(fbi, state) | __pxafb_lcd_power(fbi, 0) | fbi->lcd_power(on, &fbi->fb.var) | //use fbi->fb Fix it by ensuring that the work is canceled before proceeding with the cleanup in pxafb_remove. Note that only root user can remove the driver at runtime.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49925", "url": "https://ubuntu.com/security/CVE-2024-49925", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: efifb: Register sysfs groups through driver core The driver core can register and cleanup sysfs groups already. Make use of that functionality to simplify the error handling and cleanup. Also avoid a UAF race during unregistering where the sysctl attributes were usable after the info struct was freed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49926", "url": "https://ubuntu.com/security/CVE-2024-49926", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rcu-tasks: Fix access non-existent percpu rtpcp variable in rcu_tasks_need_gpcb() For kernels built with CONFIG_FORCE_NR_CPUS=y, the nr_cpu_ids is defined as NR_CPUS instead of the number of possible cpus, this will cause the following system panic: smpboot: Allowing 4 CPUs, 0 hotplug CPUs ... setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:512 nr_node_ids:1 ... BUG: unable to handle page fault for address: ffffffff9911c8c8 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 15 Comm: rcu_tasks_trace Tainted: G W 6.6.21 #1 5dc7acf91a5e8e9ac9dcfc35bee0245691283ea6 RIP: 0010:rcu_tasks_need_gpcb+0x25d/0x2c0 RSP: 0018:ffffa371c00a3e60 EFLAGS: 00010082 CR2: ffffffff9911c8c8 CR3: 000000040fa20005 CR4: 00000000001706f0 Call Trace: ? __die+0x23/0x80 ? page_fault_oops+0xa4/0x180 ? exc_page_fault+0x152/0x180 ? asm_exc_page_fault+0x26/0x40 ? rcu_tasks_need_gpcb+0x25d/0x2c0 ? __pfx_rcu_tasks_kthread+0x40/0x40 rcu_tasks_one_gp+0x69/0x180 rcu_tasks_kthread+0x94/0xc0 kthread+0xe8/0x140 ? __pfx_kthread+0x40/0x40 ret_from_fork+0x34/0x80 ? __pfx_kthread+0x40/0x40 ret_from_fork_asm+0x1b/0x80 Considering that there may be holes in the CPU numbers, use the maximum possible cpu number, instead of nr_cpu_ids, for configuring enqueue and dequeue limits. [ neeraj.upadhyay: Fix htmldocs build error reported by Stephen Rothwell ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50007", "url": "https://ubuntu.com/security/CVE-2024-50007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: asihpi: Fix potential OOB array access ASIHPI driver stores some values in the static array upon a response from the driver, and its index depends on the firmware. We shouldn't trust it blindly. This patch adds a sanity check of the array index to fit in the array size.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50017", "url": "https://ubuntu.com/security/CVE-2024-50017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm/ident_map: Use gbpages only where full GB page should be mapped. When ident_pud_init() uses only GB pages to create identity maps, large ranges of addresses not actually requested can be included in the resulting table; a 4K request will map a full GB. This can include a lot of extra address space past that requested, including areas marked reserved by the BIOS. That allows processor speculation into reserved regions, that on UV systems can cause system halts. Only use GB pages when map creation requests include the full GB page of space. Fall back to using smaller 2M pages when only portions of a GB page are included in the request. No attempt is made to coalesce mapping requests. If a request requires a map entry at the 2M (pmd) level, subsequent mapping requests within the same 1G region will also be at the pmd level, even if adjacent or overlapping such requests could have been combined to map a full GB page. Existing usage starts with larger regions and then adds smaller regions, so this should not have any great consequence.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49927", "url": "https://ubuntu.com/security/CVE-2024-49927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/ioapic: Handle allocation failures gracefully Breno observed panics when using failslab under certain conditions during runtime: can not alloc irq_pin_list (-1,0,20) Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed panic+0x4e9/0x590 mp_irqdomain_alloc+0x9ab/0xa80 irq_domain_alloc_irqs_locked+0x25d/0x8d0 __irq_domain_alloc_irqs+0x80/0x110 mp_map_pin_to_irq+0x645/0x890 acpi_register_gsi_ioapic+0xe6/0x150 hpet_open+0x313/0x480 That's a pointless panic which is a leftover of the historic IO/APIC code which panic'ed during early boot when the interrupt allocation failed. The only place which might justify panic is the PIT/HPET timer_check() code which tries to figure out whether the timer interrupt is delivered through the IO/APIC. But that code does not require to handle interrupt allocation failures. If the interrupt cannot be allocated then timer delivery fails and it either panics due to that or falls back to legacy mode. Cure this by removing the panic wrapper around __add_pin_to_irq_node() and making mp_irqdomain_alloc() aware of the failure condition and handle it as any other failure in this function gracefully.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50008", "url": "https://ubuntu.com/security/CVE-2024-50008", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_cmd_802_11_scan_ext() Replace one-element array with a flexible-array member in `struct host_cmd_ds_802_11_scan_ext`. With this, fix the following warning: elo 16 17:51:58 surfacebook kernel: ------------[ cut here ]------------ elo 16 17:51:58 surfacebook kernel: memcpy: detected field-spanning write (size 243) of single field \"ext_scan->tlv_buffer\" at drivers/net/wireless/marvell/mwifiex/scan.c:2239 (size 1) elo 16 17:51:58 surfacebook kernel: WARNING: CPU: 0 PID: 498 at drivers/net/wireless/marvell/mwifiex/scan.c:2239 mwifiex_cmd_802_11_scan_ext+0x83/0x90 [mwifiex]", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50018", "url": "https://ubuntu.com/security/CVE-2024-50018", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49928", "url": "https://ubuntu.com/security/CVE-2024-49928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: avoid reading out of bounds when loading TX power FW elements Because the loop-expression will do one more time before getting false from cond-expression, the original code copied one more entry size beyond valid region. Fix it by moving the entry copy to loop-body.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50178", "url": "https://ubuntu.com/security/CVE-2024-50178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: loongson3: Use raw_smp_processor_id() in do_service_request() Use raw_smp_processor_id() instead of plain smp_processor_id() in do_service_request(), otherwise we may get some errors with the driver enabled: BUG: using smp_processor_id() in preemptible [00000000] code: (udev-worker)/208 caller is loongson3_cpufreq_probe+0x5c/0x250 [loongson3_cpufreq]", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50009", "url": "https://ubuntu.com/security/CVE-2024-50009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: amd-pstate: add check for cpufreq_cpu_get's return value cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it and return in case of error. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49994", "url": "https://ubuntu.com/security/CVE-2024-49994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix integer overflow in BLKSECDISCARD I independently rediscovered \tcommit 22d24a544b0d49bbcbd61c8c0eaf77d3c9297155 \tblock: fix overflow in blk_ioctl_discard() but for secure erase. Same problem: \tuint64_t r[2] = {512, 18446744073709551104ULL}; \tioctl(fd, BLKSECDISCARD, r); will enter near infinite loop inside blkdev_issue_secure_erase(): \ta.out: attempt to access beyond end of device \tloop0: rw=5, sector=3399043073, nr_sectors = 1024 limit=2048 \tbio_check_eod: 3286214 callbacks suppressed", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49929", "url": "https://ubuntu.com/security/CVE-2024-49929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: avoid NULL pointer dereference iwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta pointer is not NULL. It retrieves this pointer using iwl_mvm_sta_from_mac80211, which is dereferencing the ieee80211_sta pointer. If sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL pointer. Fix this by checking the sta pointer before retrieving the mvmsta from it. If sta is not NULL, then mvmsta isn't either.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49995", "url": "https://ubuntu.com/security/CVE-2024-49995", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: guard against string buffer overrun Smatch reports that copying media_name and if_name to name_parts may overwrite the destination. .../bearer.c:166 bearer_name_validate() error: strcpy() 'media_name' too large for 'name_parts->media_name' (32 vs 16) .../bearer.c:167 bearer_name_validate() error: strcpy() 'if_name' too large for 'name_parts->if_name' (1010102 vs 16) This does seem to be the case so guard against this possibility by using strscpy() and failing if truncation occurs. Introduced by commit b97bf3fd8f6a (\"[TIPC] Initial merge\") Compile tested only.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49962", "url": "https://ubuntu.com/security/CVE-2024-49962", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in acpi_db_convert_to_package() ACPICA commit 4d4547cf13cca820ff7e0f859ba83e1a610b9fd0 ACPI_ALLOCATE_ZEROED() may fail, elements might be NULL and will cause NULL pointer dereference later. [ rjw: Subject and changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49930", "url": "https://ubuntu.com/security/CVE-2024-49930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix array out-of-bound access in SoC stats Currently, the ath11k_soc_dp_stats::hal_reo_error array is defined with a maximum size of DP_REO_DST_RING_MAX. However, the ath11k_dp_process_rx() function access ath11k_soc_dp_stats::hal_reo_error using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath11k_dp_process_rx() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49931", "url": "https://ubuntu.com/security/CVE-2024-49931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix array out-of-bound access in SoC stats Currently, the ath12k_soc_dp_stats::hal_reo_error array is defined with a maximum size of DP_REO_DST_RING_MAX. However, the ath12k_dp_rx_process() function access ath12k_soc_dp_stats::hal_reo_error using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath12k_dp_rx_process() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49932", "url": "https://ubuntu.com/security/CVE-2024-49932", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: don't readahead the relocation inode on RST On relocation we're doing readahead on the relocation inode, but if the filesystem is backed by a RAID stripe tree we can get ENOENT (e.g. due to preallocated extents not being mapped in the RST) from the lookup. But readahead doesn't handle the error and submits invalid reads to the device, causing an assertion in the scatter-gather list code: BTRFS info (device nvme1n1): balance: start -d -m -s BTRFS info (device nvme1n1): relocating block group 6480920576 flags data|raid0 BTRFS error (device nvme1n1): cannot find raid-stripe for logical [6481928192, 6481969152] devid 2, profile raid0 ------------[ cut here ]------------ kernel BUG at include/linux/scatterlist.h:115! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 1012 Comm: btrfs Not tainted 6.10.0-rc7+ #567 RIP: 0010:__blk_rq_map_sg+0x339/0x4a0 RSP: 0018:ffffc90001a43820 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffea00045d4802 RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000 RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000001000 R12: ffff8881003d10b8 R13: ffffc90001a438f0 R14: 0000000000000000 R15: 0000000000003000 FS: 00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000002cd11000 CR3: 00000001109ea001 CR4: 0000000000370eb0 Call Trace: ? __die_body.cold+0x14/0x25 ? die+0x2e/0x50 ? do_trap+0xca/0x110 ? do_error_trap+0x65/0x80 ? __blk_rq_map_sg+0x339/0x4a0 ? exc_invalid_op+0x50/0x70 ? __blk_rq_map_sg+0x339/0x4a0 ? asm_exc_invalid_op+0x1a/0x20 ? __blk_rq_map_sg+0x339/0x4a0 nvme_prep_rq.part.0+0x9d/0x770 nvme_queue_rq+0x7d/0x1e0 __blk_mq_issue_directly+0x2a/0x90 ? blk_mq_get_budget_and_tag+0x61/0x90 blk_mq_try_issue_list_directly+0x56/0xf0 blk_mq_flush_plug_list.part.0+0x52b/0x5d0 __blk_flush_plug+0xc6/0x110 blk_finish_plug+0x28/0x40 read_pages+0x160/0x1c0 page_cache_ra_unbounded+0x109/0x180 relocate_file_extent_cluster+0x611/0x6a0 ? btrfs_search_slot+0xba4/0xd20 ? balance_dirty_pages_ratelimited_flags+0x26/0xb00 relocate_data_extent.constprop.0+0x134/0x160 relocate_block_group+0x3f2/0x500 btrfs_relocate_block_group+0x250/0x430 btrfs_relocate_chunk+0x3f/0x130 btrfs_balance+0x71b/0xef0 ? kmalloc_trace_noprof+0x13b/0x280 btrfs_ioctl+0x2c2e/0x3030 ? kvfree_call_rcu+0x1e6/0x340 ? list_lru_add_obj+0x66/0x80 ? mntput_no_expire+0x3a/0x220 __x64_sys_ioctl+0x96/0xc0 do_syscall_64+0x54/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fcc04514f9b Code: Unable to access opcode bytes at 0x7fcc04514f71. RSP: 002b:00007ffeba923370 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fcc04514f9b RDX: 00007ffeba923460 RSI: 00000000c4009420 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000013 R09: 0000000000000001 R10: 00007fcc043fbba8 R11: 0000000000000246 R12: 00007ffeba924fc5 R13: 00007ffeba923460 R14: 0000000000000002 R15: 00000000004d4bb0 Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:__blk_rq_map_sg+0x339/0x4a0 RSP: 0018:ffffc90001a43820 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffea00045d4802 RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000 RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000001000 R12: ffff8881003d10b8 R13: ffffc90001a438f0 R14: 0000000000000000 R15: 0000000000003000 FS: 00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcc04514f71 CR3: 00000001109ea001 CR4: 0000000000370eb0 Kernel p ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49933", "url": "https://ubuntu.com/security/CVE-2024-49933", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk_iocost: fix more out of bound shifts Recently running UBSAN caught few out of bound shifts in the ioc_forgive_debts() function: UBSAN: shift-out-of-bounds in block/blk-iocost.c:2142:38 shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long long') ... UBSAN: shift-out-of-bounds in block/blk-iocost.c:2144:30 shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long long') ... Call Trace: dump_stack_lvl+0xca/0x130 __ubsan_handle_shift_out_of_bounds+0x22c/0x280 ? __lock_acquire+0x6441/0x7c10 ioc_timer_fn+0x6cec/0x7750 ? blk_iocost_init+0x720/0x720 ? call_timer_fn+0x5d/0x470 call_timer_fn+0xfa/0x470 ? blk_iocost_init+0x720/0x720 __run_timer_base+0x519/0x700 ... Actual impact of this issue was not identified but I propose to fix the undefined behaviour. The proposed fix to prevent those out of bound shifts consist of precalculating exponent before using it the shift operations by taking min value from the actual exponent and maximum possible number of bits.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49934", "url": "https://ubuntu.com/security/CVE-2024-49934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/inode: Prevent dump_mapping() accessing invalid dentry.d_name.name It's observed that a crash occurs during hot-remove a memory device, in which user is accessing the hugetlb. See calltrace as following: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 14045 at arch/x86/mm/fault.c:1278 do_user_addr_fault+0x2a0/0x790 Modules linked in: kmem device_dax cxl_mem cxl_pmem cxl_port cxl_pci dax_hmem dax_pmem nd_pmem cxl_acpi nd_btt cxl_core crc32c_intel nvme virtiofs fuse nvme_core nfit libnvdimm dm_multipath scsi_dh_rdac scsi_dh_emc s mirror dm_region_hash dm_log dm_mod CPU: 1 PID: 14045 Comm: daxctl Not tainted 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:do_user_addr_fault+0x2a0/0x790 Code: 48 8b 00 a8 04 0f 84 b5 fe ff ff e9 1c ff ff ff 4c 89 e9 4c 89 e2 be 01 00 00 00 bf 02 00 00 00 e8 b5 ef 24 00 e9 42 fe ff ff <0f> 0b 48 83 c4 08 4c 89 ea 48 89 ee 4c 89 e7 5b 5d 41 5c 41 5d 41 RSP: 0000:ffffc90000a575f0 EFLAGS: 00010046 RAX: ffff88800c303600 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000001000 RSI: ffffffff82504162 RDI: ffffffff824b2c36 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffc90000a57658 R13: 0000000000001000 R14: ffff88800bc2e040 R15: 0000000000000000 FS: 00007f51cb57d880(0000) GS:ffff88807fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000001000 CR3: 00000000072e2004 CR4: 00000000001706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn+0x8d/0x190 ? do_user_addr_fault+0x2a0/0x790 ? report_bug+0x1c3/0x1d0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? do_user_addr_fault+0x2a0/0x790 ? exc_page_fault+0x31/0x200 exc_page_fault+0x68/0x200 <...snip...> BUG: unable to handle page fault for address: 0000000000001000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI ---[ end trace 0000000000000000 ]--- BUG: unable to handle page fault for address: 0000000000001000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 14045 Comm: daxctl Kdump: loaded Tainted: G W 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:dentry_name+0x1f4/0x440 <...snip...> ? dentry_name+0x2fa/0x440 vsnprintf+0x1f3/0x4f0 vprintk_store+0x23a/0x540 vprintk_emit+0x6d/0x330 _printk+0x58/0x80 dump_mapping+0x10b/0x1a0 ? __pfx_free_object_rcu+0x10/0x10 __dump_page+0x26b/0x3e0 ? vprintk_emit+0xe0/0x330 ? _printk+0x58/0x80 ? dump_page+0x17/0x50 dump_page+0x17/0x50 do_migrate_range+0x2f7/0x7f0 ? do_migrate_range+0x42/0x7f0 ? offline_pages+0x2f4/0x8c0 offline_pages+0x60a/0x8c0 memory_subsys_offline+0x9f/0x1c0 ? lockdep_hardirqs_on+0x77/0x100 ? _raw_spin_unlock_irqrestore+0x38/0x60 device_offline+0xe3/0x110 state_store+0x6e/0xc0 kernfs_fop_write_iter+0x143/0x200 vfs_write+0x39f/0x560 ksys_write+0x65/0xf0 do_syscall_64+0x62/0x130 Previously, some sanity check have been done in dump_mapping() before the print facility parsing '%pd' though, it's still possible to run into an invalid dentry.d_name.name. Since dump_mapping() only needs to dump the filename only, retrieve it by itself in a safer way to prevent an unnecessary crash. Note that either retrieving the filename with '%pd' or strncpy_from_kernel_nofault(), the filename could be unreliable.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49935", "url": "https://ubuntu.com/security/CVE-2024-49935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: PAD: fix crash in exit_round_robin() The kernel occasionally crashes in cpumask_clear_cpu(), which is called within exit_round_robin(), because when executing clear_bit(nr, addr) with nr set to 0xffffffff, the address calculation may cause misalignment within the memory, leading to access to an invalid memory address. ---------- BUG: unable to handle kernel paging request at ffffffffe0740618 ... CPU: 3 PID: 2919323 Comm: acpi_pad/14 Kdump: loaded Tainted: G OE X --------- - - 4.18.0-425.19.2.el8_7.x86_64 #1 ... RIP: 0010:power_saving_thread+0x313/0x411 [acpi_pad] Code: 89 cd 48 89 d3 eb d1 48 c7 c7 55 70 72 c0 e8 64 86 b0 e4 c6 05 0d a1 02 00 01 e9 bc fd ff ff 45 89 e4 42 8b 04 a5 20 82 72 c0 48 0f b3 05 f4 9c 01 00 42 c7 04 a5 20 82 72 c0 ff ff ff ff 31 RSP: 0018:ff72a5d51fa77ec8 EFLAGS: 00010202 RAX: 00000000ffffffff RBX: ff462981e5d8cb80 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246 RBP: ff46297556959d80 R08: 0000000000000382 R09: ff46297c8d0f38d8 R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000000e R13: 0000000000000000 R14: ffffffffffffffff R15: 000000000000000e FS: 0000000000000000(0000) GS:ff46297a800c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffe0740618 CR3: 0000007e20410004 CR4: 0000000000771ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? acpi_pad_add+0x120/0x120 [acpi_pad] kthread+0x10b/0x130 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x1f/0x40 ... CR2: ffffffffe0740618 crash> dis -lr ffffffffc0726923 ... /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 114 0xffffffffc0726918 :\tmov %r12d,%r12d /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 325 0xffffffffc072691b :\tmov -0x3f8d7de0(,%r12,4),%eax /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./arch/x86/include/asm/bitops.h: 80 0xffffffffc0726923 :\tlock btr %rax,0x19cf4(%rip) # 0xffffffffc0740620 crash> px tsk_in_cpu[14] $66 = 0xffffffff crash> px 0xffffffffc072692c+0x19cf4 $99 = 0xffffffffc0740620 crash> sym 0xffffffffc0740620 ffffffffc0740620 (b) pad_busy_cpus_bits [acpi_pad] crash> px pad_busy_cpus_bits[0] $42 = 0xfffc0 ---------- To fix this, ensure that tsk_in_cpu[tsk_index] != -1 before calling cpumask_clear_cpu() in exit_round_robin(), just as it is done in round_robin_cpu(). [ rjw: Subject edit, avoid updates to the same value ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49936", "url": "https://ubuntu.com/security/CVE-2024-49936", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/xen-netback: prevent UAF in xenvif_flush_hash() During the list_for_each_entry_rcu iteration call of xenvif_flush_hash, kfree_rcu does not exist inside the rcu read critical section, so if kfree_rcu is called when the rcu grace period ends during the iteration, UAF occurs when accessing head->next after the entry becomes free. Therefore, to solve this, you need to change it to list_for_each_entry_safe.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49937", "url": "https://ubuntu.com/security/CVE-2024-49937", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Set correct chandef when starting CAC When starting CAC in a mode other than AP mode, it return a \"WARNING: CPU: 0 PID: 63 at cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]\" caused by the chandef.chan being null at the end of CAC. Solution: Ensure the channel definition is set for the different modes when starting CAC to avoid getting a NULL 'chan' at the end of CAC. Call Trace: ? show_regs.part.0+0x14/0x16 ? __warn+0x67/0xc0 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? report_bug+0xa7/0x130 ? exc_overflow+0x30/0x30 ? handle_bug+0x27/0x50 ? exc_invalid_op+0x18/0x60 ? handle_exception+0xf6/0xf6 ? exc_overflow+0x30/0x30 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? exc_overflow+0x30/0x30 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? regulatory_propagate_dfs_state.cold+0x1b/0x4c [cfg80211] ? cfg80211_propagate_cac_done_wk+0x1a/0x30 [cfg80211] ? process_one_work+0x165/0x280 ? worker_thread+0x120/0x3f0 ? kthread+0xc2/0xf0 ? process_one_work+0x280/0x280 ? kthread_complete_and_exit+0x20/0x20 ? ret_from_fork+0x19/0x24 [shorten subject, remove OCB, reorder cases to match previous list]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49938", "url": "https://ubuntu.com/security/CVE-2024-49938", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmit Syzbot points out that skb_trim() has a sanity check on the existing length of the skb, which can be uninitialised in some error paths. The intent here is clearly just to reset the length to zero before resubmitting, so switch to calling __skb_set_length(skb, 0) directly. In addition, __skb_set_length() already contains a call to skb_reset_tail_pointer(), so remove the redundant call. The syzbot report came from ath9k_hif_usb_reg_in_cb(), but there's a similar usage of skb_trim() in ath9k_hif_usb_rx_cb(), change both while we're at it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49939", "url": "https://ubuntu.com/security/CVE-2024-49939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: avoid to add interface to list twice when SER If SER L2 occurs during the WoWLAN resume flow, the add interface flow is triggered by ieee80211_reconfig(). However, due to rtw89_wow_resume() return failure, it will cause the add interface flow to be executed again, resulting in a double add list and causing a kernel panic. Therefore, we have added a check to prevent double adding of the list. list_add double add: new=ffff99d6992e2010, prev=ffff99d6992e2010, next=ffff99d695302628. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:37! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G W O 6.6.30-02659-gc18865c4dfbd #1 770df2933251a0e3c888ba69d1053a817a6376a7 Hardware name: HP Grunt/Grunt, BIOS Google_Grunt.11031.169.0 06/24/2021 Workqueue: events_freezable ieee80211_restart_work [mac80211] RIP: 0010:__list_add_valid_or_report+0x5e/0xb0 Code: c7 74 18 48 39 ce 74 13 b0 01 59 5a 5e 5f 41 58 41 59 41 5a 5d e9 e2 d6 03 00 cc 48 c7 c7 8d 4f 17 83 48 89 c2 e8 02 c0 00 00 <0f> 0b 48 c7 c7 aa 8c 1c 83 e8 f4 bf 00 00 0f 0b 48 c7 c7 c8 bc 12 RSP: 0018:ffffa91b8007bc50 EFLAGS: 00010246 RAX: 0000000000000058 RBX: ffff99d6992e0900 RCX: a014d76c70ef3900 RDX: ffffa91b8007bae8 RSI: 00000000ffffdfff RDI: 0000000000000001 RBP: ffffa91b8007bc88 R08: 0000000000000000 R09: ffffa91b8007bae0 R10: 00000000ffffdfff R11: ffffffff83a79800 R12: ffff99d695302060 R13: ffff99d695300900 R14: ffff99d6992e1be0 R15: ffff99d6992e2010 FS: 0000000000000000(0000) GS:ffff99d6aac00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000078fbdba43480 CR3: 000000010e464000 CR4: 00000000001506f0 Call Trace: ? __die_body+0x1f/0x70 ? die+0x3d/0x60 ? do_trap+0xa4/0x110 ? __list_add_valid_or_report+0x5e/0xb0 ? do_error_trap+0x6d/0x90 ? __list_add_valid_or_report+0x5e/0xb0 ? handle_invalid_op+0x30/0x40 ? __list_add_valid_or_report+0x5e/0xb0 ? exc_invalid_op+0x3c/0x50 ? asm_exc_invalid_op+0x16/0x20 ? __list_add_valid_or_report+0x5e/0xb0 rtw89_ops_add_interface+0x309/0x310 [rtw89_core 7c32b1ee6854761c0321027c8a58c5160e41f48f] drv_add_interface+0x5c/0x130 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ieee80211_reconfig+0x241/0x13d0 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ? finish_wait+0x3e/0x90 ? synchronize_rcu_expedited+0x174/0x260 ? sync_rcu_exp_done_unlocked+0x50/0x50 ? wake_bit_function+0x40/0x40 ieee80211_restart_work+0xf0/0x140 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] process_scheduled_works+0x1e5/0x480 worker_thread+0xea/0x1e0 kthread+0xdb/0x110 ? move_linked_works+0x90/0x90 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork+0x3b/0x50 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork_asm+0x11/0x20 Modules linked in: dm_integrity async_xor xor async_tx lz4 lz4_compress zstd zstd_compress zram zsmalloc rfcomm cmac uinput algif_hash algif_skcipher af_alg btusb btrtl iio_trig_hrtimer industrialio_sw_trigger btmtk industrialio_configfs btbcm btintel uvcvideo videobuf2_vmalloc iio_trig_sysfs videobuf2_memops videobuf2_v4l2 videobuf2_common uvc snd_hda_codec_hdmi veth snd_hda_intel snd_intel_dspcfg acpi_als snd_hda_codec industrialio_triggered_buffer kfifo_buf snd_hwdep industrialio i2c_piix4 snd_hda_core designware_i2s ip6table_nat snd_soc_max98357a xt_MASQUERADE xt_cgroup snd_soc_acp_rt5682_mach fuse rtw89_8922ae(O) rtw89_8922a(O) rtw89_pci(O) rtw89_core(O) 8021q mac80211(O) bluetooth ecdh_generic ecc cfg80211 r8152 mii joydev gsmi: Log Shutdown Reason 0x03 ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49940", "url": "https://ubuntu.com/security/CVE-2024-49940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: prevent possible tunnel refcount underflow When a session is created, it sets a backpointer to its tunnel. When the session refcount drops to 0, l2tp_session_free drops the tunnel refcount if session->tunnel is non-NULL. However, session->tunnel is set in l2tp_session_create, before the tunnel refcount is incremented by l2tp_session_register, which leaves a small window where session->tunnel is non-NULL when the tunnel refcount hasn't been bumped. Moving the assignment to l2tp_session_register is trivial but l2tp_session_create calls l2tp_session_set_header_len which uses session->tunnel to get the tunnel's encap. Add an encap arg to l2tp_session_set_header_len to avoid using session->tunnel. If l2tpv3 sessions have colliding IDs, it is possible for l2tp_v3_session_get to race with l2tp_session_register and fetch a session which doesn't yet have session->tunnel set. Add a check for this case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49941", "url": "https://ubuntu.com/security/CVE-2024-49941", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpiolib: Fix potential NULL pointer dereference in gpiod_get_label() In `gpiod_get_label()`, it is possible that `srcu_dereference_check()` may return a NULL pointer, leading to a scenario where `label->str` is accessed without verifying if `label` itself is NULL. This patch adds a proper NULL check for `label` before accessing `label->str`. The check for `label->str != NULL` is removed because `label->str` can never be NULL if `label` is not NULL. This fixes the issue where the label name was being printed as `(efault)` when dumping the sysfs GPIO file when `label == NULL`.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49996", "url": "https://ubuntu.com/security/CVE-2024-49996", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: Fix buffer overflow when parsing NFS reparse points ReparseDataLength is sum of the InodeType size and DataBuffer size. So to get DataBuffer size it is needed to subtract InodeType's size from ReparseDataLength. Function cifs_strndup_from_utf16() is currentlly accessing buf->DataBuffer at position after the end of the buffer because it does not subtract InodeType size from the length. Fix this problem and correctly subtract variable len. Member InodeType is present only when reparse buffer is large enough. Check for ReparseDataLength before accessing InodeType to prevent another invalid memory access. Major and minor rdev values are present also only when reparse buffer is large enough. Check for reparse buffer size before calling reparse_mkdev().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49942", "url": "https://ubuntu.com/security/CVE-2024-49942", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Prevent null pointer access in xe_migrate_copy xe_migrate_copy designed to copy content of TTM resources. When source resource is null, it will trigger a NULL pointer dereference in xe_migrate_copy. To avoid this situation, update lacks source flag to true for this case, the flag will trigger xe_migrate_clear rather than xe_migrate_copy. Issue trace: <7> [317.089847] xe 0000:00:02.0: [drm:xe_migrate_copy [xe]] Pass 14, sizes: 4194304 & 4194304 <7> [317.089945] xe 0000:00:02.0: [drm:xe_migrate_copy [xe]] Pass 15, sizes: 4194304 & 4194304 <1> [317.128055] BUG: kernel NULL pointer dereference, address: 0000000000000010 <1> [317.128064] #PF: supervisor read access in kernel mode <1> [317.128066] #PF: error_code(0x0000) - not-present page <6> [317.128069] PGD 0 P4D 0 <4> [317.128071] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI <4> [317.128074] CPU: 1 UID: 0 PID: 1440 Comm: kunit_try_catch Tainted: G U N 6.11.0-rc7-xe #1 <4> [317.128078] Tainted: [U]=USER, [N]=TEST <4> [317.128080] Hardware name: Intel Corporation Lunar Lake Client Platform/LNL-M LP5 RVP1, BIOS LNLMFWI1.R00.3221.D80.2407291239 07/29/2024 <4> [317.128082] RIP: 0010:xe_migrate_copy+0x66/0x13e0 [xe] <4> [317.128158] Code: 00 00 48 89 8d e0 fe ff ff 48 8b 40 10 4c 89 85 c8 fe ff ff 44 88 8d bd fe ff ff 65 48 8b 3c 25 28 00 00 00 48 89 7d d0 31 ff <8b> 79 10 48 89 85 a0 fe ff ff 48 8b 00 48 89 b5 d8 fe ff ff 83 ff <4> [317.128162] RSP: 0018:ffffc9000167f9f0 EFLAGS: 00010246 <4> [317.128164] RAX: ffff8881120d8028 RBX: ffff88814d070428 RCX: 0000000000000000 <4> [317.128166] RDX: ffff88813cb99c00 RSI: 0000000004000000 RDI: 0000000000000000 <4> [317.128168] RBP: ffffc9000167fbb8 R08: ffff88814e7b1f08 R09: 0000000000000001 <4> [317.128170] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88814e7b1f08 <4> [317.128172] R13: ffff88814e7b1f08 R14: ffff88813cb99c00 R15: 0000000000000001 <4> [317.128174] FS: 0000000000000000(0000) GS:ffff88846f280000(0000) knlGS:0000000000000000 <4> [317.128176] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [317.128178] CR2: 0000000000000010 CR3: 000000011f676004 CR4: 0000000000770ef0 <4> [317.128180] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 <4> [317.128182] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400 <4> [317.128184] PKRU: 55555554 <4> [317.128185] Call Trace: <4> [317.128187] <4> [317.128189] ? show_regs+0x67/0x70 <4> [317.128194] ? __die_body+0x20/0x70 <4> [317.128196] ? __die+0x2b/0x40 <4> [317.128198] ? page_fault_oops+0x15f/0x4e0 <4> [317.128203] ? do_user_addr_fault+0x3fb/0x970 <4> [317.128205] ? lock_acquire+0xc7/0x2e0 <4> [317.128209] ? exc_page_fault+0x87/0x2b0 <4> [317.128212] ? asm_exc_page_fault+0x27/0x30 <4> [317.128216] ? xe_migrate_copy+0x66/0x13e0 [xe] <4> [317.128263] ? __lock_acquire+0xb9d/0x26f0 <4> [317.128265] ? __lock_acquire+0xb9d/0x26f0 <4> [317.128267] ? sg_free_append_table+0x20/0x80 <4> [317.128271] ? lock_acquire+0xc7/0x2e0 <4> [317.128273] ? mark_held_locks+0x4d/0x80 <4> [317.128275] ? trace_hardirqs_on+0x1e/0xd0 <4> [317.128278] ? _raw_spin_unlock_irqrestore+0x31/0x60 <4> [317.128281] ? __pm_runtime_resume+0x60/0xa0 <4> [317.128284] xe_bo_move+0x682/0xc50 [xe] <4> [317.128315] ? lock_is_held_type+0xaa/0x120 <4> [317.128318] ttm_bo_handle_move_mem+0xe5/0x1a0 [ttm] <4> [317.128324] ttm_bo_validate+0xd1/0x1a0 [ttm] <4> [317.128328] shrink_test_run_device+0x721/0xc10 [xe] <4> [317.128360] ? find_held_lock+0x31/0x90 <4> [317.128363] ? lock_release+0xd1/0x2a0 <4> [317.128365] ? __pfx_kunit_generic_run_threadfn_adapter+0x10/0x10 [kunit] <4> [317.128370] xe_bo_shrink_kunit+0x11/0x20 [xe] <4> [317.128397] kunit_try_run_case+0x6e/0x150 [kunit] <4> [317.128400] ? trace_hardirqs_on+0x1e/0xd0 <4> [317.128402] ? _raw_spin_unlock_irqrestore+0x31/0x60 <4> [317.128404] kunit_generic_run_threadfn_adapter+0x1e/0x40 [ku ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49943", "url": "https://ubuntu.com/security/CVE-2024-49943", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc_submit: add missing locking in wedged_fini Any non-wedged queue can have a zero refcount here and can be running concurrently with an async queue destroy, therefore dereferencing the queue ptr to check wedge status after the lookup can trigger UAF if queue is not wedged. Fix this by keeping the submission_state lock held around the check to postpone the free and make the check safe, before dropping again around the put() to avoid the deadlock. (cherry picked from commit d28af0b6b9580b9f90c265a7da0315b0ad20bbfd)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50011", "url": "https://ubuntu.com/security/CVE-2024-50011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: soc-acpi-intel-rpl-match: add missing empty item There is no links_num in struct snd_soc_acpi_mach {}, and we test !link->num_adr as a condition to end the loop in hda_sdw_machine_select(). So an empty item in struct snd_soc_acpi_link_adr array is required.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50174", "url": "https://ubuntu.com/security/CVE-2024-50174", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix race when converting group handle to group object XArray provides it's own internal lock which protects the internal array when entries are being simultaneously added and removed. However there is still a race between retrieving the pointer from the XArray and incrementing the reference count. To avoid this race simply hold the internal XArray lock when incrementing the reference count, this ensures there cannot be a racing call to xa_erase().", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49944", "url": "https://ubuntu.com/security/CVE-2024-49944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_start In sctp_listen_start() invoked by sctp_inet_listen(), it should set the sk_state back to CLOSED if sctp_autobind() fails due to whatever reason. Otherwise, next time when calling sctp_inet_listen(), if sctp_sk(sk)->reuse is already set via setsockopt(SCTP_REUSE_PORT), sctp_sk(sk)->bind_hash will be dereferenced as sk_state is LISTENING, which causes a crash as bind_hash is NULL. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:sctp_inet_listen+0x7f0/0xa20 net/sctp/socket.c:8617 Call Trace: __sys_listen_socket net/socket.c:1883 [inline] __sys_listen+0x1b7/0x230 net/socket.c:1894 __do_sys_listen net/socket.c:1902 [inline]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49945", "url": "https://ubuntu.com/security/CVE-2024-49945", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/ncsi: Disable the ncsi work before freeing the associated structure The work function can run after the ncsi device is freed, resulting in use-after-free bugs or kernel panic.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49946", "url": "https://ubuntu.com/security/CVE-2024-49946", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: do not assume bh is held in ppp_channel_bridge_input() Networking receive path is usually handled from BH handler. However, some protocols need to acquire the socket lock, and packets might be stored in the socket backlog is the socket was owned by a user process. In this case, release_sock(), __release_sock(), and sk_backlog_rcv() might call the sk->sk_backlog_rcv() handler in process context. sybot caught ppp was not considering this case in ppp_channel_bridge_input() : WARNING: inconsistent lock state 6.11.0-rc7-syzkaller-g5f5673607153 #0 Not tainted -------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. ksoftirqd/1/24 [HC0[0]:SC1[1]:HE1:SE0] takes: ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 {SOFTIRQ-ON-W} state was registered at: lock_acquire+0x240/0x728 kernel/locking/lockdep.c:5759 __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline] _raw_spin_lock+0x48/0x60 kernel/locking/spinlock.c:154 spin_lock include/linux/spinlock.h:351 [inline] ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline] ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0xfc/0x314 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv include/net/sock.h:1111 [inline] __release_sock+0x1a8/0x3d8 net/core/sock.c:3004 release_sock+0x68/0x1b8 net/core/sock.c:3558 pppoe_sendmsg+0xc8/0x5d8 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x374/0x4f4 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __arm64_sys_sendto+0xd8/0xf8 net/socket.c:2212 __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:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 irq event stamp: 282914 hardirqs last enabled at (282914): [] __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:151 [inline] hardirqs last enabled at (282914): [] _raw_spin_unlock_irqrestore+0x38/0x98 kernel/locking/spinlock.c:194 hardirqs last disabled at (282913): [] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline] hardirqs last disabled at (282913): [] _raw_spin_lock_irqsave+0x2c/0x7c kernel/locking/spinlock.c:162 softirqs last enabled at (282904): [] softirq_handle_end kernel/softirq.c:400 [inline] softirqs last enabled at (282904): [] handle_softirqs+0xa3c/0xbfc kernel/softirq.c:582 softirqs last disabled at (282909): [] run_ksoftirqd+0x70/0x158 kernel/softirq.c:928 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&pch->downl); lock(&pch->downl); *** DEADLOCK *** 1 lock held by ksoftirqd/1/24: #0: ffff80008f74dfa0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire+0x10/0x4c include/linux/rcupdate.h:325 stack backtrace: CPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 6.11.0-rc7-syzkaller-g5f5673607153 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call trace: dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:319 show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:326 __dump_sta ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49947", "url": "https://ubuntu.com/security/CVE-2024-49947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: test for not too small csum_start in virtio_net_hdr_to_skb() syzbot was able to trigger this warning [1], after injecting a malicious packet through af_packet, setting skb->csum_start and thus the transport header to an incorrect value. We can at least make sure the transport header is after the end of the network header (with a estimated minimal size). [1] [ 67.873027] skb len=4096 headroom=16 headlen=14 tailroom=0 mac=(-1,-1) mac_len=0 net=(16,-6) trans=10 shinfo(txflags=0 nr_frags=1 gso(size=0 type=0 segs=0)) csum(0xa start=10 offset=0 ip_summed=3 complete_sw=0 valid=0 level=0) hash(0x0 sw=0 l4=0) proto=0x0800 pkttype=0 iif=0 priority=0x0 mark=0x0 alloc_cpu=10 vlan_all=0x0 encapsulation=0 inner(proto=0x0000, mac=0, net=0, trans=0) [ 67.877172] dev name=veth0_vlan feat=0x000061164fdd09e9 [ 67.877764] sk family=17 type=3 proto=0 [ 67.878279] skb linear: 00000000: 00 00 10 00 00 00 00 00 0f 00 00 00 08 00 [ 67.879128] skb frag: 00000000: 0e 00 07 00 00 00 28 00 08 80 1c 00 04 00 00 02 [ 67.879877] skb frag: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.880647] skb frag: 00000020: 00 00 02 00 00 00 08 00 1b 00 00 00 00 00 00 00 [ 67.881156] skb frag: 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.881753] skb frag: 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.882173] skb frag: 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.882790] skb frag: 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.883171] skb frag: 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.883733] skb frag: 00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.884206] skb frag: 00000090: 00 00 00 00 00 00 00 00 00 00 69 70 76 6c 61 6e [ 67.884704] skb frag: 000000a0: 31 00 00 00 00 00 00 00 00 00 2b 00 00 00 00 00 [ 67.885139] skb frag: 000000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.885677] skb frag: 000000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.886042] skb frag: 000000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.886408] skb frag: 000000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.887020] skb frag: 000000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.887384] skb frag: 00000100: 00 00 [ 67.887878] ------------[ cut here ]------------ [ 67.887908] offset (-6) >= skb_headlen() (14) [ 67.888445] WARNING: CPU: 10 PID: 2088 at net/core/dev.c:3332 skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.889353] Modules linked in: macsec macvtap macvlan hsr wireguard curve25519_x86_64 libcurve25519_generic libchacha20poly1305 chacha_x86_64 libchacha poly1305_x86_64 dummy bridge sr_mod cdrom evdev pcspkr i2c_piix4 9pnet_virtio 9p 9pnet netfs [ 67.890111] CPU: 10 UID: 0 PID: 2088 Comm: b363492833 Not tainted 6.11.0-virtme #1011 [ 67.890183] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 67.890309] RIP: 0010:skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891043] Call Trace: [ 67.891173] [ 67.891274] ? __warn (kernel/panic.c:741) [ 67.891320] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891333] ? report_bug (lib/bug.c:180 lib/bug.c:219) [ 67.891348] ? handle_bug (arch/x86/kernel/traps.c:239) [ 67.891363] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) [ 67.891372] ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621) [ 67.891388] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891399] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891416] ip_do_fragment (net/ipv4/ip_output.c:777 (discriminator 1)) [ 67.891448] ? __ip_local_out (./include/linux/skbuff.h:1146 ./include/net/l3mdev.h:196 ./include/net/l3mdev.h:213 ne ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49948", "url": "https://ubuntu.com/security/CVE-2024-49948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: add more sanity checks to qdisc_pkt_len_init() One path takes care of SKB_GSO_DODGY, assuming skb->len is bigger than hdr_len. virtio_net_hdr_to_skb() does not fully dissect TCP headers, it only make sure it is at least 20 bytes. It is possible for an user to provide a malicious 'GSO' packet, total length of 80 bytes. - 20 bytes of IPv4 header - 60 bytes TCP header - a small gso_size like 8 virtio_net_hdr_to_skb() would declare this packet as a normal GSO packet, because it would see 40 bytes of payload, bigger than gso_size. We need to make detect this case to not underflow qdisc_skb_cb(skb)->pkt_len.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49949", "url": "https://ubuntu.com/security/CVE-2024-49949", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: avoid potential underflow in qdisc_pkt_len_init() with UFO After commit 7c6d2ecbda83 (\"net: be more gentle about silly gso requests coming from user\") virtio_net_hdr_to_skb() had sanity check to detect malicious attempts from user space to cook a bad GSO packet. Then commit cf9acc90c80ec (\"net: virtio_net_hdr_to_skb: count transport header in UFO\") while fixing one issue, allowed user space to cook a GSO packet with the following characteristic : IPv4 SKB_GSO_UDP, gso_size=3, skb->len = 28. When this packet arrives in qdisc_pkt_len_init(), we end up with hdr_len = 28 (IPv4 header + UDP header), matching skb->len Then the following sets gso_segs to 0 : gso_segs = DIV_ROUND_UP(skb->len - hdr_len, shinfo->gso_size); Then later we set qdisc_skb_cb(skb)->pkt_len to back to zero :/ qdisc_skb_cb(skb)->pkt_len += (gso_segs - 1) * hdr_len; This leads to the following crash in fq_codel [1] qdisc_pkt_len_init() is best effort, we only want an estimation of the bytes sent on the wire, not crashing the kernel. This patch is fixing this particular issue, a following one adds more sanity checks for another potential bug. [1] [ 70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 70.724561] #PF: supervisor read access in kernel mode [ 70.724561] #PF: error_code(0x0000) - not-present page [ 70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0 [ 70.724561] Oops: Oops: 0000 [#1] SMP NOPTI [ 70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991 [ 70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel [ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 <49> 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49 All code ======== 0:\t24 08 \tand $0x8,%al 2:\t49 c1 e1 06 \tshl $0x6,%r9 6:\t44 89 7c 24 18 \tmov %r15d,0x18(%rsp) b:\t45 31 ed \txor %r13d,%r13d e:\t45 31 c0 \txor %r8d,%r8d 11:\t31 ff \txor %edi,%edi 13:\t89 44 24 14 \tmov %eax,0x14(%rsp) 17:\t4c 03 8b 90 01 00 00 \tadd 0x190(%rbx),%r9 1e:\teb 04 \tjmp 0x24 20:\t39 ca \tcmp %ecx,%edx 22:\t73 37 \tjae 0x5b 24:\t4d 8b 39 \tmov (%r9),%r15 27:\t83 c7 01 \tadd $0x1,%edi 2a:*\t49 8b 17 \tmov (%r15),%rdx\t\t<-- trapping instruction 2d:\t49 89 11 \tmov %rdx,(%r9) 30:\t41 8b 57 28 \tmov 0x28(%r15),%edx 34:\t45 8b 5f 34 \tmov 0x34(%r15),%r11d 38:\t49 c7 07 00 00 00 00 \tmovq $0x0,(%r15) 3f:\t49 \trex.WB Code starting with the faulting instruction =========================================== 0:\t49 8b 17 \tmov (%r15),%rdx 3:\t49 89 11 \tmov %rdx,(%r9) 6:\t41 8b 57 28 \tmov 0x28(%r15),%edx a:\t45 8b 5f 34 \tmov 0x34(%r15),%r11d e:\t49 c7 07 00 00 00 00 \tmovq $0x0,(%r15) 15:\t49 \trex.WB [ 70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202 [ 70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000 [ 70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001 [ 70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000 [ 70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58 [ 70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000 [ 70.724561] FS: 000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000 [ 70.724561] CS: 0010 DS: 0000 ES: 0000 C ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49997", "url": "https://ubuntu.com/security/CVE-2024-49997", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: lantiq_etop: fix memory disclosure When applying padding, the buffer is not zeroed, which results in memory disclosure. The mentioned data is observed on the wire. This patch uses skb_put_padto() to pad Ethernet frames properly. The mentioned function zeroes the expanded buffer. In case the packet cannot be padded it is silently dropped. Statistics are also not incremented. This driver does not support statistics in the old 32-bit format or the new 64-bit format. These will be added in the future. In its current form, the patch should be easily backported to stable versions. Ethernet MACs on Amazon-SE and Danube cannot do padding of the packets in hardware, so software padding must be applied.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49998", "url": "https://ubuntu.com/security/CVE-2024-49998", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: improve shutdown sequence Alexander Sverdlin presents 2 problems during shutdown with the lan9303 driver. One is specific to lan9303 and the other just happens to reproduce there. The first problem is that lan9303 is unique among DSA drivers in that it calls dev_get_drvdata() at \"arbitrary runtime\" (not probe, not shutdown, not remove): phy_state_machine() -> ... -> dsa_user_phy_read() -> ds->ops->phy_read() -> lan9303_phy_read() -> chip->ops->phy_read() -> lan9303_mdio_phy_read() -> dev_get_drvdata() But we never stop the phy_state_machine(), so it may continue to run after dsa_switch_shutdown(). Our common pattern in all DSA drivers is to set drvdata to NULL to suppress the remove() method that may come afterwards. But in this case it will result in an NPD. The second problem is that the way in which we set dp->conduit->dsa_ptr = NULL; is concurrent with receive packet processing. dsa_switch_rcv() checks once whether dev->dsa_ptr is NULL, but afterwards, rather than continuing to use that non-NULL value, dev->dsa_ptr is dereferenced again and again without NULL checks: dsa_conduit_find_user() and many other places. In between dereferences, there is no locking to ensure that what was valid once continues to be valid. Both problems have the common aspect that closing the conduit interface solves them. In the first case, dev_close(conduit) triggers the NETDEV_GOING_DOWN event in dsa_user_netdevice_event() which closes user ports as well. dsa_port_disable_rt() calls phylink_stop(), which synchronously stops the phylink state machine, and ds->ops->phy_read() will thus no longer call into the driver after this point. In the second case, dev_close(conduit) should do this, as per Documentation/networking/driver.rst: | Quiescence | ---------- | | After the ndo_stop routine has been called, the hardware must | not receive or transmit any data. All in flight packets must | be aborted. If necessary, poll or wait for completion of | any reset commands. So it should be sufficient to ensure that later, when we zeroize conduit->dsa_ptr, there will be no concurrent dsa_switch_rcv() call on this conduit. The addition of the netif_device_detach() function is to ensure that ioctls, rtnetlinks and ethtool requests on the user ports no longer propagate down to the driver - we're no longer prepared to handle them. The race condition actually did not exist when commit 0650bf52b31f (\"net: dsa: be compatible with masters which unregister on shutdown\") first introduced dsa_switch_shutdown(). It was created later, when we stopped unregistering the user interfaces from a bad spot, and we just replaced that sequence with a racy zeroization of conduit->dsa_ptr (one which doesn't ensure that the interfaces aren't up).", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49999", "url": "https://ubuntu.com/security/CVE-2024-49999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix the setting of the server responding flag In afs_wait_for_operation(), we set transcribe the call responded flag to the server record that we used after doing the fileserver iteration loop - but it's possible to exit the loop having had a response from the server that we've discarded (e.g. it returned an abort or we started receiving data, but the call didn't complete). This means that op->server might be NULL, but we don't check that before attempting to set the server flag.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49950", "url": "https://ubuntu.com/security/CVE-2024-49950", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix uaf in l2cap_connect [Syzbot reported] BUG: KASAN: slab-use-after-free in l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 Read of size 8 at addr ffff8880241e9800 by task kworker/u9:0/54 CPU: 0 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-00268-g788220eee30d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Workqueue: hci2 hci_rx_work Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 l2cap_connect_req net/bluetooth/l2cap_core.c:4080 [inline] l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:4772 [inline] l2cap_sig_channel net/bluetooth/l2cap_core.c:5543 [inline] l2cap_recv_frame+0xf0b/0x8eb0 net/bluetooth/l2cap_core.c:6825 l2cap_recv_acldata+0x9b4/0xb70 net/bluetooth/l2cap_core.c:7514 hci_acldata_packet net/bluetooth/hci_core.c:3791 [inline] hci_rx_work+0xaab/0x1610 net/bluetooth/hci_core.c:4028 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 ... Freed by task 5245: 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:579 poison_slab_object+0xf7/0x160 mm/kasan/common.c:240 __kasan_slab_free+0x32/0x50 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2256 [inline] slab_free mm/slub.c:4477 [inline] kfree+0x12a/0x3b0 mm/slub.c:4598 l2cap_conn_free net/bluetooth/l2cap_core.c:1810 [inline] kref_put include/linux/kref.h:65 [inline] l2cap_conn_put net/bluetooth/l2cap_core.c:1822 [inline] l2cap_conn_del+0x59d/0x730 net/bluetooth/l2cap_core.c:1802 l2cap_connect_cfm+0x9e6/0xf80 net/bluetooth/l2cap_core.c:7241 hci_connect_cfm include/net/bluetooth/hci_core.h:1960 [inline] hci_conn_failed+0x1c3/0x370 net/bluetooth/hci_conn.c:1265 hci_abort_conn_sync+0x75a/0xb50 net/bluetooth/hci_sync.c:5583 abort_conn_sync+0x197/0x360 net/bluetooth/hci_conn.c:2917 hci_cmd_sync_work+0x1a4/0x410 net/bluetooth/hci_sync.c:328 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49951", "url": "https://ubuntu.com/security/CVE-2024-49951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Fix possible crash on mgmt_index_removed If mgmt_index_removed is called while there are commands queued on cmd_sync it could lead to crashes like the bellow trace: 0x0000053D: __list_del_entry_valid_or_report+0x98/0xdc 0x0000053D: mgmt_pending_remove+0x18/0x58 [bluetooth] 0x0000053E: mgmt_remove_adv_monitor_complete+0x80/0x108 [bluetooth] 0x0000053E: hci_cmd_sync_work+0xbc/0x164 [bluetooth] So while handling mgmt_index_removed this attempts to dequeue commands passed as user_data to cmd_sync.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49952", "url": "https://ubuntu.com/security/CVE-2024-49952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: prevent nf_skb_duplicated corruption syzbot found that nf_dup_ipv4() or nf_dup_ipv6() could write per-cpu variable nf_skb_duplicated in an unsafe way [1]. Disabling preemption as hinted by the splat is not enough, we have to disable soft interrupts as well. [1] BUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316 caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49 nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook+0x2c4/0x450 include/linux/netfilter.h:269 NF_HOOK_COND include/linux/netfilter.h:302 [inline] ip_output+0x185/0x230 net/ipv4/ip_output.c:433 ip_local_out net/ipv4/ip_output.c:129 [inline] ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495 udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981 udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737 __do_sys_sendmmsg net/socket.c:2766 [inline] __se_sys_sendmmsg net/socket.c:2763 [inline] __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763 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:0x7f4ce4f7def9 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:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9 RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006 RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49953", "url": "https://ubuntu.com/security/CVE-2024-49953", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix crash caused by calling __xfrm_state_delete() twice The km.state is not checked in driver's delayed work. When xfrm_state_check_expire() is called, the state can be reset to XFRM_STATE_EXPIRED, even if it is XFRM_STATE_DEAD already. This happens when xfrm state is deleted, but not freed yet. As __xfrm_state_delete() is called again in xfrm timer, the following crash occurs. To fix this issue, skip xfrm_state_check_expire() if km.state is not XFRM_STATE_VALID. Oops: general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] SMP CPU: 5 UID: 0 PID: 7448 Comm: kworker/u102:2 Not tainted 6.11.0-rc2+ #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5e_ipsec: eth%d mlx5e_ipsec_handle_sw_limits [mlx5_core] RIP: 0010:__xfrm_state_delete+0x3d/0x1b0 Code: 0f 84 8b 01 00 00 48 89 fd c6 87 c8 00 00 00 05 48 8d bb 40 10 00 00 e8 11 04 1a 00 48 8b 95 b8 00 00 00 48 8b 85 c0 00 00 00 <48> 89 42 08 48 89 10 48 8b 55 10 48 b8 00 01 00 00 00 00 ad de 48 RSP: 0018:ffff88885f945ec8 EFLAGS: 00010246 RAX: dead000000000122 RBX: ffffffff82afa940 RCX: 0000000000000036 RDX: dead000000000100 RSI: 0000000000000000 RDI: ffffffff82afb980 RBP: ffff888109a20340 R08: ffff88885f945ea0 R09: 0000000000000000 R10: 0000000000000000 R11: ffff88885f945ff8 R12: 0000000000000246 R13: ffff888109a20340 R14: ffff88885f95f420 R15: ffff88885f95f400 FS: 0000000000000000(0000) GS:ffff88885f940000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2163102430 CR3: 00000001128d6001 CR4: 0000000000370eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? die_addr+0x33/0x90 ? exc_general_protection+0x1a2/0x390 ? asm_exc_general_protection+0x22/0x30 ? __xfrm_state_delete+0x3d/0x1b0 ? __xfrm_state_delete+0x2f/0x1b0 xfrm_timer_handler+0x174/0x350 ? __xfrm_state_delete+0x1b0/0x1b0 __hrtimer_run_queues+0x121/0x270 hrtimer_run_softirq+0x88/0xd0 handle_softirqs+0xcc/0x270 do_softirq+0x3c/0x50 __local_bh_enable_ip+0x47/0x50 mlx5e_ipsec_handle_sw_limits+0x7d/0x90 [mlx5_core] process_one_work+0x137/0x2d0 worker_thread+0x28d/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50000", "url": "https://ubuntu.com/security/CVE-2024-50000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix NULL deref in mlx5e_tir_builder_alloc() In mlx5e_tir_builder_alloc() kvzalloc() may return NULL which is dereferenced on the next line in a reference to the modify field. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50001", "url": "https://ubuntu.com/security/CVE-2024-50001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix error path in multi-packet WQE transmit Remove the erroneous unmap in case no DMA mapping was established The multi-packet WQE transmit code attempts to obtain a DMA mapping for the skb. This could fail, e.g. under memory pressure, when the IOMMU driver just can't allocate more memory for page tables. While the code tries to handle this in the path below the err_unmap label it erroneously unmaps one entry from the sq's FIFO list of active mappings. Since the current map attempt failed this unmap is removing some random DMA mapping that might still be required. If the PCI function now presents that IOVA, the IOMMU may assumes a rogue DMA access and e.g. on s390 puts the PCI function in error state. The erroneous behavior was seen in a stress-test environment that created memory pressure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50179", "url": "https://ubuntu.com/security/CVE-2024-50179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: remove the incorrect Fw reference check when dirtying pages When doing the direct-io reads it will also try to mark pages dirty, but for the read path it won't hold the Fw caps and there is case will it get the Fw reference.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49963", "url": "https://ubuntu.com/security/CVE-2024-49963", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mailbox: bcm2835: Fix timeout during suspend mode During noirq suspend phase the Raspberry Pi power driver suffer of firmware property timeouts. The reason is that the IRQ of the underlying BCM2835 mailbox is disabled and rpi_firmware_property_list() will always run into a timeout [1]. Since the VideoCore side isn't consider as a wakeup source, set the IRQF_NO_SUSPEND flag for the mailbox IRQ in order to keep it enabled during suspend-resume cycle. [1] PM: late suspend of devices complete after 1.754 msecs WARNING: CPU: 0 PID: 438 at drivers/firmware/raspberrypi.c:128 rpi_firmware_property_list+0x204/0x22c Firmware transaction 0x00028001 timeout Modules linked in: CPU: 0 PID: 438 Comm: bash Tainted: G C 6.9.3-dirty #17 Hardware name: BCM2835 Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x44 dump_stack_lvl from __warn+0x88/0xec __warn from warn_slowpath_fmt+0x7c/0xb0 warn_slowpath_fmt from rpi_firmware_property_list+0x204/0x22c rpi_firmware_property_list from rpi_firmware_property+0x68/0x8c rpi_firmware_property from rpi_firmware_set_power+0x54/0xc0 rpi_firmware_set_power from _genpd_power_off+0xe4/0x148 _genpd_power_off from genpd_sync_power_off+0x7c/0x11c genpd_sync_power_off from genpd_finish_suspend+0xcc/0xe0 genpd_finish_suspend from dpm_run_callback+0x78/0xd0 dpm_run_callback from device_suspend_noirq+0xc0/0x238 device_suspend_noirq from dpm_suspend_noirq+0xb0/0x168 dpm_suspend_noirq from suspend_devices_and_enter+0x1b8/0x5ac suspend_devices_and_enter from pm_suspend+0x254/0x2e4 pm_suspend from state_store+0xa8/0xd4 state_store from kernfs_fop_write_iter+0x154/0x1a0 kernfs_fop_write_iter from vfs_write+0x12c/0x184 vfs_write from ksys_write+0x78/0xc0 ksys_write from ret_fast_syscall+0x0/0x54 Exception stack(0xcc93dfa8 to 0xcc93dff0) [...] PM: noirq suspend of devices complete after 3095.584 msecs", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49954", "url": "https://ubuntu.com/security/CVE-2024-49954", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: static_call: Replace pointless WARN_ON() in static_call_module_notify() static_call_module_notify() triggers a WARN_ON(), when memory allocation fails in __static_call_add_module(). That's not really justified, because the failure case must be correctly handled by the well known call chain and the error code is passed through to the initiating userspace application. A memory allocation fail is not a fatal problem, but the WARN_ON() takes the machine out when panic_on_warn is set. Replace it with a pr_warn().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50002", "url": "https://ubuntu.com/security/CVE-2024-50002", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: static_call: Handle module init failure correctly in static_call_del_module() Module insertion invokes static_call_add_module() to initialize the static calls in a module. static_call_add_module() invokes __static_call_init(), which allocates a struct static_call_mod to either encapsulate the built-in static call sites of the associated key into it so further modules can be added or to append the module to the module chain. If that allocation fails the function returns with an error code and the module core invokes static_call_del_module() to clean up eventually added static_call_mod entries. This works correctly, when all keys used by the module were converted over to a module chain before the failure. If not then static_call_del_module() causes a #GP as it blindly assumes that key::mods points to a valid struct static_call_mod. The problem is that key::mods is not a individual struct member of struct static_call_key, it's part of a union to save space: union { /* bit 0: 0 = mods, 1 = sites */ unsigned long type; struct static_call_mod *mods; struct static_call_site *sites; \t}; key::sites is a pointer to the list of built-in usage sites of the static call. The type of the pointer is differentiated by bit 0. A mods pointer has the bit clear, the sites pointer has the bit set. As static_call_del_module() blidly assumes that the pointer is a valid static_call_mod type, it fails to check for this failure case and dereferences the pointer to the list of built-in call sites, which is obviously bogus. Cure it by checking whether the key has a sites or a mods pointer. If it's a sites pointer then the key is not to be touched. As the sites are walked in the same order as in __static_call_init() the site walk can be terminated because all subsequent sites have not been touched by the init code due to the error exit. If it was converted before the allocation fail, then the inner loop which searches for a module match will find nothing. A fail in the second allocation in __static_call_init() is harmless and does not require special treatment. The first allocation succeeded and converted the key to a module chain. That first entry has mod::mod == NULL and mod::next == NULL, so the inner loop of static_call_del_module() will neither find a module match nor a module chain. The next site in the walk was either already converted, but can't match the module, or it will exit the outer loop because it has a static_call_site pointer and not a static_call_mod pointer.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-47675", "url": "https://ubuntu.com/security/CVE-2024-47675", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix use-after-free in bpf_uprobe_multi_link_attach() If bpf_link_prime() fails, bpf_uprobe_multi_link_attach() goes to the error_free label and frees the array of bpf_uprobe's without calling bpf_uprobe_unregister(). This leaks bpf_uprobe->uprobe and worse, this frees bpf_uprobe->consumer without removing it from the uprobe->consumers list.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47676", "url": "https://ubuntu.com/security/CVE-2024-47676", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb.c: fix UAF of vma in hugetlb fault pathway Syzbot reports a UAF in hugetlb_fault(). This happens because vmf_anon_prepare() could drop the per-VMA lock and allow the current VMA to be freed before hugetlb_vma_unlock_read() is called. We can fix this by using a modified version of vmf_anon_prepare() that doesn't release the VMA lock on failure, and then release it ourselves after hugetlb_vma_unlock_read().", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47677", "url": "https://ubuntu.com/security/CVE-2024-47677", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: resolve memory leak from exfat_create_upcase_table() If exfat_load_upcase_table reaches end and returns -EINVAL, allocated memory doesn't get freed and while exfat_load_default_upcase_table allocates more memory, leading to a memory leak. Here's link to syzkaller crash report illustrating this issue: https://syzkaller.appspot.com/text?tag=CrashReport&x=1406c201980000", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47725", "url": "https://ubuntu.com/security/CVE-2024-47725", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47739", "url": "https://ubuntu.com/security/CVE-2024-47739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: padata: use integer wrap around to prevent deadlock on seq_nr overflow When submitting more than 2^32 padata objects to padata_do_serial, the current sorting implementation incorrectly sorts padata objects with overflowed seq_nr, causing them to be placed before existing objects in the reorder list. This leads to a deadlock in the serialization process as padata_find_next cannot match padata->seq_nr and pd->processed because the padata instance with overflowed seq_nr will be selected next. To fix this, we use an unsigned integer wrap around to correctly sort padata objects in scenarios with integer overflow.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47678", "url": "https://ubuntu.com/security/CVE-2024-47678", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: icmp: change the order of rate limits ICMP messages are ratelimited : After the blamed commits, the two rate limiters are applied in this order: 1) host wide ratelimit (icmp_global_allow()) 2) Per destination ratelimit (inetpeer based) In order to avoid side-channels attacks, we need to apply the per destination check first. This patch makes the following change : 1) icmp_global_allow() checks if the host wide limit is reached. But credits are not yet consumed. This is deferred to 3) 2) The per destination limit is checked/updated. This might add a new node in inetpeer tree. 3) icmp_global_consume() consumes tokens if prior operations succeeded. This means that host wide ratelimit is still effective in keeping inetpeer tree small even under DDOS. As a bonus, I removed icmp_global.lock as the fast path can use a lock-free operation.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47733", "url": "https://ubuntu.com/security/CVE-2024-47733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfs: Delete subtree of 'fs/netfs' when netfs module exits In netfs_init() or fscache_proc_init(), we create dentry under 'fs/netfs', but in netfs_exit(), we only delete the proc entry of 'fs/netfs' without deleting its subtree. This triggers the following WARNING: ================================================================== remove_proc_entry: removing non-empty directory 'fs/netfs', leaking at least 'requests' WARNING: CPU: 4 PID: 566 at fs/proc/generic.c:717 remove_proc_entry+0x160/0x1c0 Modules linked in: netfs(-) CPU: 4 UID: 0 PID: 566 Comm: rmmod Not tainted 6.11.0-rc3 #860 RIP: 0010:remove_proc_entry+0x160/0x1c0 Call Trace: netfs_exit+0x12/0x620 [netfs] __do_sys_delete_module.isra.0+0x14c/0x2e0 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e ================================================================== Therefore use remove_proc_subtree() instead of remove_proc_entry() to fix the above problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47679", "url": "https://ubuntu.com/security/CVE-2024-47679", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfs: fix race between evice_inodes() and find_inode()&iput() Hi, all Recently I noticed a bug[1] in btrfs, after digged it into and I believe it'a race in vfs. Let's assume there's a inode (ie ino 261) with i_count 1 is called by iput(), and there's a concurrent thread calling generic_shutdown_super(). cpu0: cpu1: iput() // i_count is 1 ->spin_lock(inode) ->dec i_count to 0 ->iput_final() generic_shutdown_super() ->__inode_add_lru() ->evict_inodes() // cause some reason[2] ->if (atomic_read(inode->i_count)) continue; // return before // inode 261 passed the above check // list_lru_add_obj() // and then schedule out ->spin_unlock() // note here: the inode 261 // was still at sb list and hash list, // and I_FREEING|I_WILL_FREE was not been set btrfs_iget() // after some function calls ->find_inode() // found the above inode 261 ->spin_lock(inode) // check I_FREEING|I_WILL_FREE // and passed ->__iget() ->spin_unlock(inode) // schedule back ->spin_lock(inode) // check (I_NEW|I_FREEING|I_WILL_FREE) flags, // passed and set I_FREEING iput() ->spin_unlock(inode) ->spin_lock(inode)\t\t\t ->evict() // dec i_count to 0 ->iput_final() ->spin_unlock() ->evict() Now, we have two threads simultaneously evicting the same inode, which may trigger the BUG(inode->i_state & I_CLEAR) statement both within clear_inode() and iput(). To fix the bug, recheck the inode->i_count after holding i_lock. Because in the most scenarios, the first check is valid, and the overhead of spin_lock() can be reduced. If there is any misunderstanding, please let me know, thanks. [1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/ [2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable() return false when I reproduced the bug.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49859", "url": "https://ubuntu.com/security/CVE-2024-49859", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to check atomic_file in f2fs ioctl interfaces Some f2fs ioctl interfaces like f2fs_ioc_set_pin_file(), f2fs_move_file_range(), and f2fs_defragment_range() missed to check atomic_write status, which may cause potential race issue, fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47680", "url": "https://ubuntu.com/security/CVE-2024-47680", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: check discard support for conventional zones As the helper function f2fs_bdev_support_discard() shows, f2fs checks if the target block devices support discard by calling bdev_max_discard_sectors() and bdev_is_zoned(). This check works well for most cases, but it does not work for conventional zones on zoned block devices. F2fs assumes that zoned block devices support discard, and calls __submit_discard_cmd(). When __submit_discard_cmd() is called for sequential write required zones, it works fine since __submit_discard_cmd() issues zone reset commands instead of discard commands. However, when __submit_discard_cmd() is called for conventional zones, __blkdev_issue_discard() is called even when the devices do not support discard. The inappropriate __blkdev_issue_discard() call was not a problem before the commit 30f1e7241422 (\"block: move discard checks into the ioctl handler\") because __blkdev_issue_discard() checked if the target devices support discard or not. If not, it returned EOPNOTSUPP. After the commit, __blkdev_issue_discard() no longer checks it. It always returns zero and sets NULL to the given bio pointer. This NULL pointer triggers f2fs_bug_on() in __submit_discard_cmd(). The BUG is recreated with the commands below at the umount step, where /dev/nullb0 is a zoned null_blk with 5GB total size, 128MB zone size and 10 conventional zones. $ mkfs.f2fs -f -m /dev/nullb0 $ mount /dev/nullb0 /mnt $ for ((i=0;i<5;i++)); do dd if=/dev/zero of=/mnt/test bs=65536 count=1600 conv=fsync; done $ umount /mnt To fix the BUG, avoid the inappropriate __blkdev_issue_discard() call. When discard is requested for conventional zones, check if the device supports discard or not. If not, return EOPNOTSUPP.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47740", "url": "https://ubuntu.com/security/CVE-2024-47740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: Require FMODE_WRITE for atomic write ioctls The F2FS ioctls for starting and committing atomic writes check for inode_owner_or_capable(), but this does not give LSMs like SELinux or Landlock an opportunity to deny the write access - if the caller's FSUID matches the inode's UID, inode_owner_or_capable() immediately returns true. There are scenarios where LSMs want to deny a process the ability to write particular files, even files that the FSUID of the process owns; but this can currently partially be bypassed using atomic write ioctls in two ways: - F2FS_IOC_START_ATOMIC_REPLACE + F2FS_IOC_COMMIT_ATOMIC_WRITE can truncate an inode to size 0 - F2FS_IOC_START_ATOMIC_WRITE + F2FS_IOC_ABORT_ATOMIC_WRITE can revert changes another process concurrently made to a file Fix it by requiring FMODE_WRITE for these operations, just like for F2FS_IOC_MOVE_RANGE. Since any legitimate caller should only be using these ioctls when intending to write into the file, that seems unlikely to break anything.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47726", "url": "https://ubuntu.com/security/CVE-2024-47726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to wait dio completion It should wait all existing dio write IOs before block removal, otherwise, previous direct write IO may overwrite data in the block which may be reused by other inode.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47741", "url": "https://ubuntu.com/security/CVE-2024-47741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race setting file private on concurrent lseek using same fd When doing concurrent lseek(2) system calls against the same file descriptor, using multiple threads belonging to the same process, we have a short time window where a race happens and can result in a memory leak. The race happens like this: 1) A program opens a file descriptor for a file and then spawns two threads (with the pthreads library for example), lets call them task A and task B; 2) Task A calls lseek with SEEK_DATA or SEEK_HOLE and ends up at file.c:find_desired_extent() while holding a read lock on the inode; 3) At the start of find_desired_extent(), it extracts the file's private_data pointer into a local variable named 'private', which has a value of NULL; 4) Task B also calls lseek with SEEK_DATA or SEEK_HOLE, locks the inode in shared mode and enters file.c:find_desired_extent(), where it also extracts file->private_data into its local variable 'private', which has a NULL value; 5) Because it saw a NULL file private, task A allocates a private structure and assigns to the file structure; 6) Task B also saw a NULL file private so it also allocates its own file private and then assigns it to the same file structure, since both tasks are using the same file descriptor. At this point we leak the private structure allocated by task A. Besides the memory leak, there's also the detail that both tasks end up using the same cached state record in the private structure (struct btrfs_file_private::llseek_cached_state), which can result in a use-after-free problem since one task can free it while the other is still using it (only one task took a reference count on it). Also, sharing the cached state is not a good idea since it could result in incorrect results in the future - right now it should not be a problem because it end ups being used only in extent-io-tree.c:count_range_bits() where we do range validation before using the cached state. Fix this by protecting the private assignment and check of a file while holding the inode's spinlock and keep track of the task that allocated the private, so that it's used only by that task in order to prevent user-after-free issues with the cached state record as well as potentially using it incorrectly in the future.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47681", "url": "https://ubuntu.com/security/CVE-2024-47681", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix NULL pointer dereference in mt7996_mcu_sta_bfer_he Fix the NULL pointer dereference in mt7996_mcu_sta_bfer_he routine adding an sta interface to the mt7996 driver. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49858", "url": "https://ubuntu.com/security/CVE-2024-49858", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption The TPM event log table is a Linux specific construct, where the data produced by the GetEventLog() boot service is cached in memory, and passed on to the OS using an EFI configuration table. The use of EFI_LOADER_DATA here results in the region being left unreserved in the E820 memory map constructed by the EFI stub, and this is the memory description that is passed on to the incoming kernel by kexec, which is therefore unaware that the region should be reserved. Even though the utility of the TPM2 event log after a kexec is questionable, any corruption might send the parsing code off into the weeds and crash the kernel. So let's use EFI_ACPI_RECLAIM_MEMORY instead, which is always treated as reserved by the E820 conversion logic.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49860", "url": "https://ubuntu.com/security/CVE-2024-49860", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: sysfs: validate return type of _STR method Only buffer objects are valid return values of _STR. If something else is returned description_show() will access invalid memory.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47742", "url": "https://ubuntu.com/security/CVE-2024-47742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware_loader: Block path traversal Most firmware names are hardcoded strings, or are constructed from fairly constrained format strings where the dynamic parts are just some hex numbers or such. However, there are a couple codepaths in the kernel where firmware file names contain string components that are passed through from a device or semi-privileged userspace; the ones I could find (not counting interfaces that require root privileges) are: - lpfc_sli4_request_firmware_update() seems to construct the firmware filename from \"ModelName\", a string that was previously parsed out of some descriptor (\"Vital Product Data\") in lpfc_fill_vpd() - nfp_net_fw_find() seems to construct a firmware filename from a model name coming from nfp_hwinfo_lookup(pf->hwinfo, \"nffw.partno\"), which I think parses some descriptor that was read from the device. (But this case likely isn't exploitable because the format string looks like \"netronome/nic_%s\", and there shouldn't be any *folders* starting with \"netronome/nic_\". The previous case was different because there, the \"%s\" is *at the start* of the format string.) - module_flash_fw_schedule() is reachable from the ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is enough to pass the privilege check), and takes a userspace-provided firmware name. (But I think to reach this case, you need to have CAP_NET_ADMIN over a network namespace that a special kind of ethernet device is mapped into, so I think this is not a viable attack path in practice.) Fix it by rejecting any firmware names containing \"..\" path components. For what it's worth, I went looking and haven't found any USB device drivers that use the firmware loader dangerously.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47682", "url": "https://ubuntu.com/security/CVE-2024-47682", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sd: Fix off-by-one error in sd_read_block_characteristics() Ff the device returns page 0xb1 with length 8 (happens with qemu v2.x, for example), sd_read_block_characteristics() may attempt an out-of-bounds memory access when accessing the zoned field at offset 8.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47743", "url": "https://ubuntu.com/security/CVE-2024-47743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: prevent NULL pointer dereference in find_asymmetric_key() In find_asymmetric_key(), if all NULLs are passed in the id_{0,1,2} arguments, the kernel will first emit WARN but then have an oops because id_2 gets dereferenced anyway. Add the missing id_2 check and move WARN_ON() to the final else branch to avoid duplicate NULL checks. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47727", "url": "https://ubuntu.com/security/CVE-2024-47727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/tdx: Fix \"in-kernel MMIO\" check TDX only supports kernel-initiated MMIO operations. The handle_mmio() function checks if the #VE exception occurred in the kernel and rejects the operation if it did not. However, userspace can deceive the kernel into performing MMIO on its behalf. For example, if userspace can point a syscall to an MMIO address, syscall does get_user() or put_user() on it, triggering MMIO #VE. The kernel will treat the #VE as in-kernel MMIO. Ensure that the target MMIO address is within the kernel before decoding instruction.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47744", "url": "https://ubuntu.com/security/CVE-2024-47744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Use dedicated mutex to protect kvm_usage_count to avoid deadlock Use a dedicated mutex to guard kvm_usage_count to fix a potential deadlock on x86 due to a chain of locks and SRCU synchronizations. Translating the below lockdep splat, CPU1 #6 will wait on CPU0 #1, CPU0 #8 will wait on CPU2 #3, and CPU2 #7 will wait on CPU1 #4 (if there's a writer, due to the fairness of r/w semaphores). CPU0 CPU1 CPU2 1 lock(&kvm->slots_lock); 2 lock(&vcpu->mutex); 3 lock(&kvm->srcu); 4 lock(cpu_hotplug_lock); 5 lock(kvm_lock); 6 lock(&kvm->slots_lock); 7 lock(cpu_hotplug_lock); 8 sync(&kvm->srcu); Note, there are likely more potential deadlocks in KVM x86, e.g. the same pattern of taking cpu_hotplug_lock outside of kvm_lock likely exists with __kvmclock_cpufreq_notifier(): cpuhp_cpufreq_online() | -> cpufreq_online() | -> cpufreq_gov_performance_limits() | -> __cpufreq_driver_target() | -> __target_index() | -> cpufreq_freq_transition_begin() | -> cpufreq_notify_transition() | -> ... __kvmclock_cpufreq_notifier() But, actually triggering such deadlocks is beyond rare due to the combination of dependencies and timings involved. E.g. the cpufreq notifier is only used on older CPUs without a constant TSC, mucking with the NX hugepage mitigation while VMs are running is very uncommon, and doing so while also onlining/offlining a CPU (necessary to generate contention on cpu_hotplug_lock) would be even more unusual. The most robust solution to the general cpu_hotplug_lock issue is likely to switch vm_list to be an RCU-protected list, e.g. so that x86's cpufreq notifier doesn't to take kvm_lock. For now, settle for fixing the most blatant deadlock, as switching to an RCU-protected list is a much more involved change, but add a comment in locking.rst to call out that care needs to be taken when walking holding kvm_lock and walking vm_list. ====================================================== WARNING: possible circular locking dependency detected 6.10.0-smp--c257535a0c9d-pip #330 Tainted: G S O ------------------------------------------------------ tee/35048 is trying to acquire lock: ff6a80eced71e0a8 (&kvm->slots_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x179/0x1e0 [kvm] but task is already holding lock: ffffffffc07abb08 (kvm_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x14a/0x1e0 [kvm] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (kvm_lock){+.+.}-{3:3}: __mutex_lock+0x6a/0xb40 mutex_lock_nested+0x1f/0x30 kvm_dev_ioctl+0x4fb/0xe50 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #2 (cpu_hotplug_lock){++++}-{0:0}: cpus_read_lock+0x2e/0xb0 static_key_slow_inc+0x16/0x30 kvm_lapic_set_base+0x6a/0x1c0 [kvm] kvm_set_apic_base+0x8f/0xe0 [kvm] kvm_set_msr_common+0x9ae/0xf80 [kvm] vmx_set_msr+0xa54/0xbe0 [kvm_intel] __kvm_set_msr+0xb6/0x1a0 [kvm] kvm_arch_vcpu_ioctl+0xeca/0x10c0 [kvm] kvm_vcpu_ioctl+0x485/0x5b0 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (&kvm->srcu){.+.+}-{0:0}: __synchronize_srcu+0x44/0x1a0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47719", "url": "https://ubuntu.com/security/CVE-2024-47719", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommufd: Protect against overflow of ALIGN() during iova allocation Userspace can supply an iova and uptr such that the target iova alignment becomes really big and ALIGN() overflows which corrupts the selected area range during allocation. CONFIG_IOMMUFD_TEST can detect this: WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline] WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352 Modules linked in: CPU: 1 PID: 5092 Comm: syz-executor294 Not tainted 6.10.0-rc5-syzkaller-00294-g3ffea9a7a6f7 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024 RIP: 0010:iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline] RIP: 0010:iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352 Code: fc e9 a4 f3 ff ff e8 1a 8b 4c fc 41 be e4 ff ff ff e9 8a f3 ff ff e8 0a 8b 4c fc 90 0f 0b 90 e9 37 f5 ff ff e8 fc 8a 4c fc 90 <0f> 0b 90 e9 68 f3 ff ff 48 c7 c1 ec 82 ad 8f 80 e1 07 80 c1 03 38 RSP: 0018:ffffc90003ebf9e0 EFLAGS: 00010293 RAX: ffffffff85499fa4 RBX: 00000000ffffffef RCX: ffff888079b49e00 RDX: 0000000000000000 RSI: 00000000ffffffef RDI: 0000000000000000 RBP: ffffc90003ebfc50 R08: ffffffff85499b30 R09: ffffffff85499942 R10: 0000000000000002 R11: ffff888079b49e00 R12: ffff8880228e0010 R13: 0000000000000000 R14: 1ffff920007d7f68 R15: ffffc90003ebfd00 FS: 000055557d760380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000005fdeb8 CR3: 000000007404a000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: iommufd_ioas_copy+0x610/0x7b0 drivers/iommu/iommufd/ioas.c:274 iommufd_fops_ioctl+0x4d9/0x5a0 drivers/iommu/iommufd/main.c:421 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Cap the automatic alignment to the huge page size, which is probably a better idea overall. Huge automatic alignments can fragment and chew up the available IOVA space without any reason.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47745", "url": "https://ubuntu.com/security/CVE-2024-47745", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: call the security_mmap_file() LSM hook in remap_file_pages() The remap_file_pages syscall handler calls do_mmap() directly, which doesn't contain the LSM security check. And if the process has called personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for RW pages, this will actually result in remapping the pages to RWX, bypassing a W^X policy enforced by SELinux. So we should check prot by security_mmap_file LSM hook in the remap_file_pages syscall handler before do_mmap() is called. Otherwise, it potentially permits an attacker to bypass a W^X policy enforced by SELinux. The bypass is similar to CVE-2016-10044, which bypass the same thing via AIO and can be found in [1]. The PoC: $ cat > test.c int main(void) { \tsize_t pagesz = sysconf(_SC_PAGE_SIZE); \tint mfd = syscall(SYS_memfd_create, \"test\", 0); \tconst char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE, \t\tMAP_SHARED, mfd, 0); \tunsigned int old = syscall(SYS_personality, 0xffffffff); \tsyscall(SYS_personality, READ_IMPLIES_EXEC | old); \tsyscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0); \tsyscall(SYS_personality, old); \t// show the RWX page exists even if W^X policy is enforced \tint fd = open(\"/proc/self/maps\", O_RDONLY); \tunsigned char buf2[1024]; \twhile (1) { \t\tint ret = read(fd, buf2, 1024); \t\tif (ret <= 0) break; \t\twrite(1, buf2, ret); \t} \tclose(fd); } $ gcc test.c -o test $ ./test | grep rwx 7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted) [PM: subject line tweaks]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47746", "url": "https://ubuntu.com/security/CVE-2024-47746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: use exclusive lock when FUSE_I_CACHE_IO_MODE is set This may be a typo. The comment has said shared locks are not allowed when this bit is set. If using shared lock, the wait in `fuse_file_cached_io_open` may be forever.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47734", "url": "https://ubuntu.com/security/CVE-2024-47734", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: Fix unnecessary warnings and logs from bond_xdp_get_xmit_slave() syzbot reported a WARNING in bond_xdp_get_xmit_slave. To reproduce this[1], one bond device (bond1) has xdpdrv, which increases bpf_master_redirect_enabled_key. Another bond device (bond0) which is unsupported by XDP but its slave (veth3) has xdpgeneric that returns XDP_TX. This triggers WARN_ON_ONCE() from the xdp_master_redirect(). To reduce unnecessary warnings and improve log management, we need to delete the WARN_ON_ONCE() and add ratelimit to the netdev_err(). [1] Steps to reproduce: # Needs tx_xdp with return XDP_TX; ip l add veth0 type veth peer veth1 ip l add veth3 type veth peer veth4 ip l add bond0 type bond mode 6 # BOND_MODE_ALB, unsupported by XDP ip l add bond1 type bond # BOND_MODE_ROUNDROBIN by default ip l set veth0 master bond1 ip l set bond1 up # Increases bpf_master_redirect_enabled_key ip l set dev bond1 xdpdrv object tx_xdp.o section xdp_tx ip l set veth3 master bond0 ip l set bond0 up ip l set veth4 up # Triggers WARN_ON_ONCE() from the xdp_master_redirect() ip l set veth3 xdpgeneric object tx_xdp.o section xdp_tx", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47684", "url": "https://ubuntu.com/security/CVE-2024-47684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: check skb is non-NULL in tcp_rto_delta_us() We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic kernel that are running ceph and recently hit a null ptr dereference in tcp_rearm_rto(). Initially hitting it from the TLP path, but then later we also saw it getting hit from the RACK case as well. Here are examples of the oops messages we saw in each of those cases: Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020 Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode Jul 26 15:05:02 rx [11061395.792971] #PF: error_code(0x0000) - not-present page Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0 Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI Jul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu Jul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023 Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 <48> 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3 Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246 Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000 Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60 Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8 Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900 Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30 Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000 Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0 Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554 Jul 26 15:05:02 rx [11061395.916786] Call Trace: Jul 26 15:05:02 rx [11061395.919488] Jul 26 15:05:02 rx [11061395.921765] ? show_regs.cold+0x1a/0x1f Jul 26 15:05:02 rx [11061395.925859] ? __die+0x90/0xd9 Jul 26 15:05:02 rx [11061395.929169] ? no_context+0x196/0x380 Jul 26 15:05:02 rx [11061395.933088] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0 Jul 26 15:05:02 rx [11061395.938216] ? ip6_sublist_rcv_finish+0x3d/0x50 Jul 26 15:05:02 rx [11061395.943000] ? __bad_area_nosemaphore+0x50/0x1a0 Jul 26 15:05:02 rx [11061395.947873] ? bad_area_nosemaphore+0x16/0x20 Jul 26 15:05:02 rx [11061395.952486] ? do_user_addr_fault+0x267/0x450 Jul 26 15:05:02 rx [11061395.957104] ? ipv6_list_rcv+0x112/0x140 Jul 26 15:05:02 rx [11061395.961279] ? __do_page_fault+0x58/0x90 Jul 26 15:05:02 rx [11061395.965458] ? do_page_fault+0x2c/0xe0 Jul 26 15:05:02 rx [11061395.969465] ? page_fault+0x34/0x40 Jul 26 15:05:02 rx [11061395.973217] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.977313] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.981408] tcp_send_loss_probe+0x10b/0x220 Jul 26 15:05:02 rx [11061395.985937] tcp_write_timer_handler+0x1b4/0x240 Jul 26 15:05:02 rx [11061395.990809] tcp_write_timer+0x9e/0xe0 Jul 26 15:05:02 rx [11061395.994814] ? tcp_write_timer_handler+0x240/0x240 Jul 26 15:05:02 rx [11061395.999866] call_timer_fn+0x32/0x130 Jul 26 15:05:02 rx [11061396.003782] __run_timers.part.0+0x180/0x280 Jul 26 15:05:02 rx [11061396.008309] ? recalibrate_cpu_khz+0x10/0x10 Jul 26 15:05:02 rx [11061396.012841] ? native_x2apic_icr_write+0x30/0x30 Jul 26 15:05:02 rx [11061396.017718] ? lapic_next_even ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47747", "url": "https://ubuntu.com/security/CVE-2024-47747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race Condition In the ether3_probe function, a timer is initialized with a callback function ether3_ledoff, bound to &prev(dev)->timer. Once the timer is started, there is a risk of a race condition if the module or device is removed, triggering the ether3_remove function to perform cleanup. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | ether3_ledoff ether3_remove | free_netdev(dev); | put_devic | kfree(dev); | | ether3_outw(priv(dev)->regs.config2 |= CFG2_CTRLO, REG_CONFIG2); | // use dev Fix it by ensuring that the timer is canceled before proceeding with the cleanup in ether3_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47685", "url": "https://ubuntu.com/security/CVE-2024-47685", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put() syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending garbage on the four reserved tcp bits (th->res1) Use skb_put_zero() to clear the whole TCP header, as done in nf_reject_ip_tcphdr_put() BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5661 [inline] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775 process_backlog+0x4ad/0xa50 net/core/dev.c:6108 __napi_poll+0xe7/0x980 net/core/dev.c:6772 napi_poll net/core/dev.c:6841 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963 handle_softirqs+0x1ce/0x800 kernel/softirq.c:554 __do_softirq+0x14/0x1a kernel/softirq.c:588 do_softirq+0x9a/0x100 kernel/softirq.c:455 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline] __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450 dev_queue_xmit include/linux/netdevice.h:3105 [inline] neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366 inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135 __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143 tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333 __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679 inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750 __sys_connect_file net/socket.c:2061 [inline] __sys_connect+0x606/0x690 net/socket.c:2078 __do_sys_connect net/socket.c:2088 [inline] __se_sys_connect net/socket.c:2085 [inline] __x64_sys_connect+0x91/0xe0 net/socket.c:2085 x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43 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 Uninit was stored to memory at: nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47686", "url": "https://ubuntu.com/security/CVE-2024-47686", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ep93xx: clock: Fix off by one in ep93xx_div_recalc_rate() The psc->div[] array has psc->num_div elements. These values come from when we call clk_hw_register_div(). It's adc_divisors and ARRAY_SIZE(adc_divisors)) and so on. So this condition needs to be >= instead of > to prevent an out of bounds read.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47748", "url": "https://ubuntu.com/security/CVE-2024-47748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost_vdpa: assign irq bypass producer token correctly We used to call irq_bypass_unregister_producer() in vhost_vdpa_setup_vq_irq() which is problematic as we don't know if the token pointer is still valid or not. Actually, we use the eventfd_ctx as the token so the life cycle of the token should be bound to the VHOST_SET_VRING_CALL instead of vhost_vdpa_setup_vq_irq() which could be called by set_status(). Fixing this by setting up irq bypass producer's token when handling VHOST_SET_VRING_CALL and un-registering the producer before calling vhost_vring_ioctl() to prevent a possible use after free as eventfd could have been released in vhost_vring_ioctl(). And such registering and unregistering will only be done if DRIVER_OK is set.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47687", "url": "https://ubuntu.com/security/CVE-2024-47687", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa/mlx5: Fix invalid mr resource destroy Certain error paths from mlx5_vdpa_dev_add() can end up releasing mr resources which never got initialized in the first place. This patch adds the missing check in mlx5_vdpa_destroy_mr_resources() to block releasing non-initialized mr resources. Reference trace: mlx5_core 0000:08:00.2: mlx5_vdpa_dev_add:3274:(pid 2700) warning: No mac address provisioned? BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 140216067 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 8 PID: 2700 Comm: vdpa Kdump: loaded Not tainted 5.14.0-496.el9.x86_64 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:vhost_iotlb_del_range+0xf/0xe0 [vhost_iotlb] Code: [...] RSP: 0018:ff1c823ac23077f0 EFLAGS: 00010246 RAX: ffffffffc1a21a60 RBX: ffffffff899567a0 RCX: 0000000000000000 RDX: ffffffffffffffff RSI: 0000000000000000 RDI: 0000000000000000 RBP: ff1bda1f7c21e800 R08: 0000000000000000 R09: ff1c823ac2307670 R10: ff1c823ac2307668 R11: ffffffff8a9e7b68 R12: 0000000000000000 R13: 0000000000000000 R14: ff1bda1f43e341a0 R15: 00000000ffffffea FS: 00007f56eba7c740(0000) GS:ff1bda269f800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000104d90001 CR4: 0000000000771ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? mlx5_vdpa_free+0x3d/0x150 [mlx5_vdpa] ? __die_body.cold+0x8/0xd ? page_fault_oops+0x134/0x170 ? __irq_work_queue_local+0x2b/0xc0 ? irq_work_queue+0x2c/0x50 ? exc_page_fault+0x62/0x150 ? asm_exc_page_fault+0x22/0x30 ? __pfx_mlx5_vdpa_free+0x10/0x10 [mlx5_vdpa] ? vhost_iotlb_del_range+0xf/0xe0 [vhost_iotlb] mlx5_vdpa_free+0x3d/0x150 [mlx5_vdpa] vdpa_release_dev+0x1e/0x50 [vdpa] device_release+0x31/0x90 kobject_cleanup+0x37/0x130 mlx5_vdpa_dev_add+0x2d2/0x7a0 [mlx5_vdpa] vdpa_nl_cmd_dev_add_set_doit+0x277/0x4c0 [vdpa] genl_family_rcv_msg_doit+0xd9/0x130 genl_family_rcv_msg+0x14d/0x220 ? __pfx_vdpa_nl_cmd_dev_add_set_doit+0x10/0x10 [vdpa] ? _copy_to_user+0x1a/0x30 ? move_addr_to_user+0x4b/0xe0 genl_rcv_msg+0x47/0xa0 ? __import_iovec+0x46/0x150 ? __pfx_genl_rcv_msg+0x10/0x10 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x245/0x370 netlink_sendmsg+0x206/0x440 __sys_sendto+0x1dc/0x1f0 ? do_read_fault+0x10c/0x1d0 ? do_pte_missing+0x10d/0x190 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x5c/0xf0 ? __count_memcg_events+0x4f/0xb0 ? mm_account_fault+0x6c/0x100 ? handle_mm_fault+0x116/0x270 ? do_user_addr_fault+0x1d6/0x6a0 ? do_syscall_64+0x6b/0xf0 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 entry_SYSCALL_64_after_hwframe+0x78/0x80", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47688", "url": "https://ubuntu.com/security/CVE-2024-47688", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: driver core: Fix a potential null-ptr-deref in module_add_driver() Inject fault while probing of-fpga-region, if kasprintf() fails in module_add_driver(), the second sysfs_remove_link() in exit path will cause null-ptr-deref as below because kernfs_name_hash() will call strlen() with NULL driver_name. Fix it by releasing resources based on the exit path sequence. \t KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] \t Mem abort info: \t ESR = 0x0000000096000005 \t EC = 0x25: DABT (current EL), IL = 32 bits \t SET = 0, FnV = 0 \t EA = 0, S1PTW = 0 \t FSC = 0x05: level 1 translation fault \t Data abort info: \t ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 \t CM = 0, WnR = 0, TnD = 0, TagAccess = 0 \t GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 \t [dfffffc000000000] address between user and kernel address ranges \t Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP \t Dumping ftrace buffer: \t (ftrace buffer empty) \t Modules linked in: of_fpga_region(+) fpga_region fpga_bridge cfg80211 rfkill 8021q garp mrp stp llc ipv6 [last unloaded: of_fpga_region] \t CPU: 2 UID: 0 PID: 2036 Comm: modprobe Not tainted 6.11.0-rc2-g6a0e38264012 #295 \t Hardware name: linux,dummy-virt (DT) \t pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) \t pc : strlen+0x24/0xb0 \t lr : kernfs_name_hash+0x1c/0xc4 \t sp : ffffffc081f97380 \t x29: ffffffc081f97380 x28: ffffffc081f97b90 x27: ffffff80c821c2a0 \t x26: ffffffedac0be418 x25: 0000000000000000 x24: ffffff80c09d2000 \t x23: 0000000000000000 x22: 0000000000000000 x21: 0000000000000000 \t x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000001840 \t x17: 0000000000000000 x16: 0000000000000000 x15: 1ffffff8103f2e42 \t x14: 00000000f1f1f1f1 x13: 0000000000000004 x12: ffffffb01812d61d \t x11: 1ffffff01812d61c x10: ffffffb01812d61c x9 : dfffffc000000000 \t x8 : 0000004fe7ed29e4 x7 : ffffff80c096b0e7 x6 : 0000000000000001 \t x5 : ffffff80c096b0e0 x4 : 1ffffffdb990efa2 x3 : 0000000000000000 \t x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000000 \t Call trace: \t strlen+0x24/0xb0 \t kernfs_name_hash+0x1c/0xc4 \t kernfs_find_ns+0x118/0x2e8 \t kernfs_remove_by_name_ns+0x80/0x100 \t sysfs_remove_link+0x74/0xa8 \t module_add_driver+0x278/0x394 \t bus_add_driver+0x1f0/0x43c \t driver_register+0xf4/0x3c0 \t __platform_driver_register+0x60/0x88 \t of_fpga_region_init+0x20/0x1000 [of_fpga_region] \t do_one_initcall+0x110/0x788 \t do_init_module+0x1dc/0x5c8 \t load_module+0x3c38/0x4cac \t init_module_from_file+0xd4/0x128 \t idempotent_init_module+0x2cc/0x528 \t __arm64_sys_finit_module+0xac/0x100 \t invoke_syscall+0x6c/0x258 \t el0_svc_common.constprop.0+0x160/0x22c \t do_el0_svc+0x44/0x5c \t el0_svc+0x48/0xb8 \t el0t_64_sync_handler+0x13c/0x158 \t el0t_64_sync+0x190/0x194 \t Code: f2fbffe1 a90157f4 12000802 aa0003f5 (38e16861) \t ---[ end trace 0000000000000000 ]--- \t Kernel panic - not syncing: Oops: Fatal exception", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47689", "url": "https://ubuntu.com/security/CVE-2024-47689", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to don't set SB_RDONLY in f2fs_handle_critical_error() syzbot reports a f2fs bug as below: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 58 at kernel/rcu/sync.c:177 rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177 CPU: 1 UID: 0 PID: 58 Comm: kworker/1:2 Not tainted 6.10.0-syzkaller-12562-g1722389b0d86 #0 Workqueue: events destroy_super_work RIP: 0010:rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177 Call Trace: percpu_free_rwsem+0x41/0x80 kernel/locking/percpu-rwsem.c:42 destroy_super_work+0xec/0x130 fs/super.c:282 process_one_work kernel/workqueue.c:3231 [inline] process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 worker_thread+0x86d/0xd40 kernel/workqueue.c:3390 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 As Christian Brauner pointed out [1]: the root cause is f2fs sets SB_RDONLY flag in internal function, rather than setting the flag covered w/ sb->s_umount semaphore via remount procedure, then below race condition causes this bug: - freeze_super() - sb_wait_write(sb, SB_FREEZE_WRITE) - sb_wait_write(sb, SB_FREEZE_PAGEFAULT) - sb_wait_write(sb, SB_FREEZE_FS) \t\t\t\t\t- f2fs_handle_critical_error \t\t\t\t\t - sb->s_flags |= SB_RDONLY - thaw_super - thaw_super_locked - sb_rdonly() is true, so it skips sb_freeze_unlock(sb, SB_FREEZE_FS) - deactivate_locked_super Since f2fs has almost the same logic as ext4 [2] when handling critical error in filesystem if it mounts w/ errors=remount-ro option: - set CP_ERROR_FLAG flag which indicates filesystem is stopped - record errors to superblock - set SB_RDONLY falg Once we set CP_ERROR_FLAG flag, all writable interfaces can detect the flag and stop any further updates on filesystem. So, it is safe to not set SB_RDONLY flag, let's remove the logic and keep in line w/ ext4 [3]. [1] https://lore.kernel.org/all/20240729-himbeeren-funknetz-96e62f9c7aee@brauner [2] https://lore.kernel.org/all/20240729132721.hxih6ehigadqf7wx@quack3 [3] https://lore.kernel.org/linux-ext4/20240805201241.27286-1-jack@suse.cz", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47690", "url": "https://ubuntu.com/security/CVE-2024-47690", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: get rid of online repaire on corrupted directory syzbot reports a f2fs bug as below: kernel BUG at fs/f2fs/inode.c:896! RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Call Trace: evict+0x532/0x950 fs/inode.c:704 dispose_list fs/inode.c:747 [inline] evict_inodes+0x5f9/0x690 fs/inode.c:797 generic_shutdown_super+0x9d/0x2d0 fs/super.c:627 kill_block_super+0x44/0x90 fs/super.c:1696 kill_f2fs_super+0x344/0x690 fs/f2fs/super.c:4898 deactivate_locked_super+0xc4/0x130 fs/super.c:473 cleanup_mnt+0x41f/0x4b0 fs/namespace.c:1373 task_work_run+0x24f/0x310 kernel/task_work.c:228 ptrace_notify+0x2d2/0x380 kernel/signal.c:2402 ptrace_report_syscall include/linux/ptrace.h:415 [inline] ptrace_report_syscall_exit include/linux/ptrace.h:477 [inline] syscall_exit_work+0xc6/0x190 kernel/entry/common.c:173 syscall_exit_to_user_mode_prepare kernel/entry/common.c:200 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:205 [inline] syscall_exit_to_user_mode+0x279/0x370 kernel/entry/common.c:218 do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Online repaire on corrupted directory in f2fs_lookup() can generate dirty data/meta while racing w/ readonly remount, it may leave dirty inode after filesystem becomes readonly, however, checkpoint() will skips flushing dirty inode in a state of readonly mode, result in above panic. Let's get rid of online repaire in f2fs_lookup(), and leave the work to fsck.f2fs.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47691", "url": "https://ubuntu.com/security/CVE-2024-47691", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread() syzbot reports a f2fs bug as below: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_report+0xe8/0x550 mm/kasan/report.c:491 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 instrument_atomic_read_write include/linux/instrumented.h:96 [inline] atomic_fetch_add_relaxed include/linux/atomic/atomic-instrumented.h:252 [inline] __refcount_add include/linux/refcount.h:184 [inline] __refcount_inc include/linux/refcount.h:241 [inline] refcount_inc include/linux/refcount.h:258 [inline] get_task_struct include/linux/sched/task.h:118 [inline] kthread_stop+0xca/0x630 kernel/kthread.c:704 f2fs_stop_gc_thread+0x65/0xb0 fs/f2fs/gc.c:210 f2fs_do_shutdown+0x192/0x540 fs/f2fs/file.c:2283 f2fs_ioc_shutdown fs/f2fs/file.c:2325 [inline] __f2fs_ioctl+0x443a/0xbe60 fs/f2fs/file.c:4325 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f The root cause is below race condition, it may cause use-after-free issue in sbi->gc_th pointer. - remount - f2fs_remount - f2fs_stop_gc_thread - kfree(gc_th) \t\t\t\t- f2fs_ioc_shutdown \t\t\t\t - f2fs_do_shutdown \t\t\t\t - f2fs_stop_gc_thread \t\t\t\t - kthread_stop(gc_th->f2fs_gc_task) : sbi->gc_thread = NULL; We will call f2fs_do_shutdown() in two paths: - for f2fs_ioc_shutdown() path, we should grab sb->s_umount semaphore for fixing. - for f2fs_shutdown() path, it's safe since caller has already grabbed sb->s_umount semaphore.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47692", "url": "https://ubuntu.com/security/CVE-2024-47692", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: return -EINVAL when namelen is 0 When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may result in namelen being 0, which will cause memdup_user() to return ZERO_SIZE_PTR. When we access the name.data that has been assigned the value of ZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is triggered. [ T1205] ================================================================== [ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260 [ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205 [ T1205] [ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406 [ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ T1205] Call Trace: [ T1205] dump_stack+0x9a/0xd0 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] __kasan_report.cold+0x34/0x84 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] kasan_report+0x3a/0x50 [ T1205] nfs4_client_to_reclaim+0xe9/0x260 [ T1205] ? nfsd4_release_lockowner+0x410/0x410 [ T1205] cld_pipe_downcall+0x5ca/0x760 [ T1205] ? nfsd4_cld_tracking_exit+0x1d0/0x1d0 [ T1205] ? down_write_killable_nested+0x170/0x170 [ T1205] ? avc_policy_seqno+0x28/0x40 [ T1205] ? selinux_file_permission+0x1b4/0x1e0 [ T1205] rpc_pipe_write+0x84/0xb0 [ T1205] vfs_write+0x143/0x520 [ T1205] ksys_write+0xc9/0x170 [ T1205] ? __ia32_sys_read+0x50/0x50 [ T1205] ? ktime_get_coarse_real_ts64+0xfe/0x110 [ T1205] ? ktime_get_coarse_real_ts64+0xa2/0x110 [ T1205] do_syscall_64+0x33/0x40 [ T1205] entry_SYSCALL_64_after_hwframe+0x67/0xd1 [ T1205] RIP: 0033:0x7fdbdb761bc7 [ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 514 [ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7 [ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008 [ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001 [ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b [ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000 [ T1205] ================================================================== Fix it by checking namelen.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47737", "url": "https://ubuntu.com/security/CVE-2024-47737", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: call cache_put if xdr_reserve_space returns NULL If not enough buffer space available, but idmap_lookup has triggered lookup_fn which calls cache_get and returns successfully. Then we missed to call cache_put here which pairs with cache_get. Reviwed-by: Jeff Layton ", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2023-52917", "url": "https://ubuntu.com/security/CVE-2023-52917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir() The debugfs_create_dir() function returns error pointers. It never returns NULL. So use IS_ERR() to check it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47749", "url": "https://ubuntu.com/security/CVE-2024-47749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Added NULL check for lookup_atid The lookup_atid() function can return NULL if the ATID is invalid or does not exist in the identifier table, which could lead to dereferencing a null pointer without a check in the `act_establish()` and `act_open_rpl()` functions. Add a NULL check to prevent null pointer dereferencing. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47735", "url": "https://ubuntu.com/security/CVE-2024-47735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled Fix missuse of spin_lock_irq()/spin_unlock_irq() when spin_lock_irqsave()/spin_lock_irqrestore() was hold. This was discovered through the lock debugging, and the corresponding log is as follows: raw_local_irq_restore() called with IRQs enabled WARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40 ... Call trace: warn_bogus_irq_restore+0x30/0x40 _raw_spin_unlock_irqrestore+0x84/0xc8 add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2] hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2] hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2] create_qp+0x138/0x258 ib_create_qp_kernel+0x50/0xe8 create_mad_qp+0xa8/0x128 ib_mad_port_open+0x218/0x448 ib_mad_init_device+0x70/0x1f8 add_client_context+0xfc/0x220 enable_device_and_get+0xd0/0x140 ib_register_device.part.0+0xf4/0x1c8 ib_register_device+0x34/0x50 hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2] hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2] __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2] hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47750", "url": "https://ubuntu.com/security/CVE-2024-47750", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix Use-After-Free of rsv_qp on HIP08 Currently rsv_qp is freed before ib_unregister_device() is called on HIP08. During the time interval, users can still dereg MR and rsv_qp will be used in this process, leading to a UAF. Move the release of rsv_qp after calling ib_unregister_device() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47751", "url": "https://ubuntu.com/security/CVE-2024-47751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: kirin: Fix buffer overflow in kirin_pcie_parse_port() Within kirin_pcie_parse_port(), the pcie->num_slots is compared to pcie->gpio_id_reset size (MAX_PCI_SLOTS) which is correct and would lead to an overflow. Thus, fix condition to pcie->num_slots + 1 >= MAX_PCI_SLOTS and move pcie->num_slots increment below the if-statement to avoid out-of-bounds array access. Found by Linux Verification Center (linuxtesting.org) with SVACE. [kwilczynski: commit log]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47693", "url": "https://ubuntu.com/security/CVE-2024-47693", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/core: Fix ib_cache_setup_one error flow cleanup When ib_cache_update return an error, we exit ib_cache_setup_one instantly with no proper cleanup, even though before this we had already successfully done gid_table_setup_one, that results in the kernel WARN below. Do proper cleanup using gid_table_cleanup_one before returning the err in order to fix the issue. WARNING: CPU: 4 PID: 922 at drivers/infiniband/core/cache.c:806 gid_table_release_one+0x181/0x1a0 Modules linked in: CPU: 4 UID: 0 PID: 922 Comm: c_repro Not tainted 6.11.0-rc1+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:gid_table_release_one+0x181/0x1a0 Code: 44 8b 38 75 0c e8 2f cb 34 ff 4d 8b b5 28 05 00 00 e8 23 cb 34 ff 44 89 f9 89 da 4c 89 f6 48 c7 c7 d0 58 14 83 e8 4f de 21 ff <0f> 0b 4c 8b 75 30 e9 54 ff ff ff 48 8 3 c4 10 5b 5d 41 5c 41 5d 41 RSP: 0018:ffffc90002b835b0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c8527 RDX: 0000000000000000 RSI: ffffffff811c8534 RDI: 0000000000000001 RBP: ffff8881011b3d00 R08: ffff88810b3abe00 R09: 205d303839303631 R10: 666572207972746e R11: 72746e6520444947 R12: 0000000000000001 R13: ffff888106390000 R14: ffff8881011f2110 R15: 0000000000000001 FS: 00007fecc3b70800(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000340 CR3: 000000010435a001 CR4: 00000000003706b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? show_regs+0x94/0xa0 ? __warn+0x9e/0x1c0 ? gid_table_release_one+0x181/0x1a0 ? report_bug+0x1f9/0x340 ? gid_table_release_one+0x181/0x1a0 ? handle_bug+0xa2/0x110 ? exc_invalid_op+0x31/0xa0 ? asm_exc_invalid_op+0x16/0x20 ? __warn_printk+0xc7/0x180 ? __warn_printk+0xd4/0x180 ? gid_table_release_one+0x181/0x1a0 ib_device_release+0x71/0xe0 ? __pfx_ib_device_release+0x10/0x10 device_release+0x44/0xd0 kobject_put+0x135/0x3d0 put_device+0x20/0x30 rxe_net_add+0x7d/0xa0 rxe_newlink+0xd7/0x190 nldev_newlink+0x1b0/0x2a0 ? __pfx_nldev_newlink+0x10/0x10 rdma_nl_rcv_msg+0x1ad/0x2e0 rdma_nl_rcv_skb.constprop.0+0x176/0x210 netlink_unicast+0x2de/0x400 netlink_sendmsg+0x306/0x660 __sock_sendmsg+0x110/0x120 ____sys_sendmsg+0x30e/0x390 ___sys_sendmsg+0x9b/0xf0 ? kstrtouint+0x6e/0xa0 ? kstrtouint_from_user+0x7c/0xb0 ? get_pid_task+0xb0/0xd0 ? proc_fail_nth_write+0x5b/0x140 ? __fget_light+0x9a/0x200 ? preempt_count_add+0x47/0xa0 __sys_sendmsg+0x61/0xd0 do_syscall_64+0x50/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47694", "url": "https://ubuntu.com/security/CVE-2024-47694", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mlx5: Fix UMR pd cleanup on error flow of driver init The cited commit moves the pd allocation from function mlx5r_umr_resource_cleanup() to a new function mlx5r_umr_cleanup(). So the fix in commit [1] is broken. In error flow, will hit panic [2]. Fix it by checking pd pointer to avoid panic if it is NULL; [1] RDMA/mlx5: Fix UMR cleanup on error flow of driver init [2] [ 347.567063] infiniband mlx5_0: Couldn't register device with driver model [ 347.591382] BUG: kernel NULL pointer dereference, address: 0000000000000020 [ 347.593438] #PF: supervisor read access in kernel mode [ 347.595176] #PF: error_code(0x0000) - not-present page [ 347.596962] PGD 0 P4D 0 [ 347.601361] RIP: 0010:ib_dealloc_pd_user+0x12/0xc0 [ib_core] [ 347.604171] RSP: 0018:ffff888106293b10 EFLAGS: 00010282 [ 347.604834] RAX: 0000000000000000 RBX: 000000000000000e RCX: 0000000000000000 [ 347.605672] RDX: ffff888106293ad0 RSI: 0000000000000000 RDI: 0000000000000000 [ 347.606529] RBP: 0000000000000000 R08: ffff888106293ae0 R09: ffff888106293ae0 [ 347.607379] R10: 0000000000000a06 R11: 0000000000000000 R12: 0000000000000000 [ 347.608224] R13: ffffffffa0704dc0 R14: 0000000000000001 R15: 0000000000000001 [ 347.609067] FS: 00007fdc720cd9c0(0000) GS:ffff88852c880000(0000) knlGS:0000000000000000 [ 347.610094] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 347.610727] CR2: 0000000000000020 CR3: 0000000103012003 CR4: 0000000000370eb0 [ 347.611421] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 347.612113] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 347.612804] Call Trace: [ 347.613130] [ 347.613417] ? __die+0x20/0x60 [ 347.613793] ? page_fault_oops+0x150/0x3e0 [ 347.614243] ? free_msg+0x68/0x80 [mlx5_core] [ 347.614840] ? cmd_exec+0x48f/0x11d0 [mlx5_core] [ 347.615359] ? exc_page_fault+0x74/0x130 [ 347.615808] ? asm_exc_page_fault+0x22/0x30 [ 347.616273] ? ib_dealloc_pd_user+0x12/0xc0 [ib_core] [ 347.616801] mlx5r_umr_cleanup+0x23/0x90 [mlx5_ib] [ 347.617365] mlx5_ib_stage_pre_ib_reg_umr_cleanup+0x36/0x40 [mlx5_ib] [ 347.618025] __mlx5_ib_add+0x96/0xd0 [mlx5_ib] [ 347.618539] mlx5r_probe+0xe9/0x310 [mlx5_ib] [ 347.619032] ? kernfs_add_one+0x107/0x150 [ 347.619478] ? __mlx5_ib_add+0xd0/0xd0 [mlx5_ib] [ 347.619984] auxiliary_bus_probe+0x3e/0x90 [ 347.620448] really_probe+0xc5/0x3a0 [ 347.620857] __driver_probe_device+0x80/0x160 [ 347.621325] driver_probe_device+0x1e/0x90 [ 347.621770] __driver_attach+0xec/0x1c0 [ 347.622213] ? __device_attach_driver+0x100/0x100 [ 347.622724] bus_for_each_dev+0x71/0xc0 [ 347.623151] bus_add_driver+0xed/0x240 [ 347.623570] driver_register+0x58/0x100 [ 347.623998] __auxiliary_driver_register+0x6a/0xc0 [ 347.624499] ? driver_register+0xae/0x100 [ 347.624940] ? 0xffffffffa0893000 [ 347.625329] mlx5_ib_init+0x16a/0x1e0 [mlx5_ib] [ 347.625845] do_one_initcall+0x4a/0x2a0 [ 347.626273] ? gcov_event+0x2e2/0x3a0 [ 347.626706] do_init_module+0x8a/0x260 [ 347.627126] init_module_from_file+0x8b/0xd0 [ 347.627596] __x64_sys_finit_module+0x1ca/0x2f0 [ 347.628089] do_syscall_64+0x4c/0x100", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47695", "url": "https://ubuntu.com/security/CVE-2024-47695", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds In the function init_conns(), after the create_con() and create_cm() for loop if something fails. In the cleanup for loop after the destroy tag, we access out of bound memory because cid is set to clt_path->s.con_num. This commits resets the cid to clt_path->s.con_num - 1, to stay in bounds in the cleanup loop later.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47752", "url": "https://ubuntu.com/security/CVE-2024-47752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix H264 stateless decoder smatch warning Fix a smatch static checker warning on vdec_h264_req_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47753", "url": "https://ubuntu.com/security/CVE-2024-47753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix VP8 stateless decoder smatch warning Fix a smatch static checker warning on vdec_vp8_req_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47754", "url": "https://ubuntu.com/security/CVE-2024-47754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix H264 multi stateless decoder smatch warning Fix a smatch static checker warning on vdec_h264_req_multi_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47696", "url": "https://ubuntu.com/security/CVE-2024-47696", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency In the commit aee2424246f9 (\"RDMA/iwcm: Fix a use-after-free related to destroying CM IDs\"), the function flush_workqueue is invoked to flush the work queue iwcm_wq. But at that time, the work queue iwcm_wq was created via the function alloc_ordered_workqueue without the flag WQ_MEM_RECLAIM. Because the current process is trying to flush the whole iwcm_wq, if iwcm_wq doesn't have the flag WQ_MEM_RECLAIM, verify that the current process is not reclaiming memory or running on a workqueue which doesn't have the flag WQ_MEM_RECLAIM as that can break forward-progress guarantee leading to a deadlock. The call trace is as below: [ 125.350876][ T1430] Call Trace: [ 125.356281][ T1430] [ 125.361285][ T1430] ? __warn (kernel/panic.c:693) [ 125.367640][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.375689][ T1430] ? report_bug (lib/bug.c:180 lib/bug.c:219) [ 125.382505][ T1430] ? handle_bug (arch/x86/kernel/traps.c:239) [ 125.388987][ T1430] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) [ 125.395831][ T1430] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621) [ 125.403125][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.410984][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.418764][ T1430] __flush_workqueue (kernel/workqueue.c:3970) [ 125.426021][ T1430] ? __pfx___might_resched (kernel/sched/core.c:10151) [ 125.433431][ T1430] ? destroy_cm_id (drivers/infiniband/core/iwcm.c:375) iw_cm [ 125.441209][ T1430] ? __pfx___flush_workqueue (kernel/workqueue.c:3910) [ 125.473900][ T1430] ? _raw_spin_lock_irqsave (arch/x86/include/asm/atomic.h:107 include/linux/atomic/atomic-arch-fallback.h:2170 include/linux/atomic/atomic-instrumented.h:1302 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162) [ 125.473909][ T1430] ? __pfx__raw_spin_lock_irqsave (kernel/locking/spinlock.c:161) [ 125.482537][ T1430] _destroy_id (drivers/infiniband/core/cma.c:2044) rdma_cm [ 125.495072][ T1430] nvme_rdma_free_queue (drivers/nvme/host/rdma.c:656 drivers/nvme/host/rdma.c:650) nvme_rdma [ 125.505827][ T1430] nvme_rdma_reset_ctrl_work (drivers/nvme/host/rdma.c:2180) nvme_rdma [ 125.505831][ T1430] process_one_work (kernel/workqueue.c:3231) [ 125.515122][ T1430] worker_thread (kernel/workqueue.c:3306 kernel/workqueue.c:3393) [ 125.515127][ T1430] ? __pfx_worker_thread (kernel/workqueue.c:3339) [ 125.531837][ T1430] kthread (kernel/kthread.c:389) [ 125.539864][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.550628][ T1430] ret_from_fork (arch/x86/kernel/process.c:147) [ 125.558840][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.558844][ T1430] ret_from_fork_asm (arch/x86/entry/entry_64.S:257) [ 125.566487][ T1430] [ 125.566488][ T1430] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47755", "url": "https://ubuntu.com/security/CVE-2024-47755", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47756", "url": "https://ubuntu.com/security/CVE-2024-47756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: keystone: Fix if-statement expression in ks_pcie_quirk() This code accidentally uses && where || was intended. It potentially results in a NULL dereference. Thus, fix the if-statement expression to use the correct condition. [kwilczynski: commit log]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47697", "url": "https://ubuntu.com/security/CVE-2024-47697", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error Ensure index in rtl2830_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47698", "url": "https://ubuntu.com/security/CVE-2024-47698", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error Ensure index in rtl2832_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue. [hverkuil: added fixes tag, rtl2830_pid_filter -> rtl2832_pid_filter in logmsg]", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47728", "url": "https://ubuntu.com/security/CVE-2024-47728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error For all non-tracing helpers which formerly had ARG_PTR_TO_{LONG,INT} as input arguments, zero the value for the case of an error as otherwise it could leak memory. For tracing, it is not needed given CAP_PERFMON can already read all kernel memory anyway hence bpf_get_func_arg() and bpf_get_func_ret() is skipped in here. Also, the MTU helpers mtu_len pointer value is being written but also read. Technically, the MEM_UNINIT should not be there in order to always force init. Removing MEM_UNINIT needs more verifier rework though: MEM_UNINIT right now implies two things actually: i) write into memory, ii) memory does not have to be initialized. If we lift MEM_UNINIT, it then becomes: i) read into memory, ii) memory must be initialized. This means that for bpf_*_check_mtu() we're readding the issue we're trying to fix, that is, it would then be able to write back into things like .rodata BPF maps. Follow-up work will rework the MEM_UNINIT semantics such that the intent can be better expressed. For now just clear the *mtu_len on error path which can be lifted later again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49861", "url": "https://ubuntu.com/security/CVE-2024-49861", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix helper writes to read-only maps Lonial found an issue that despite user- and BPF-side frozen BPF map (like in case of .rodata), it was still possible to write into it from a BPF program side through specific helpers having ARG_PTR_TO_{LONG,INT} as arguments. In check_func_arg() when the argument is as mentioned, the meta->raw_mode is never set. Later, check_helper_mem_access(), under the case of PTR_TO_MAP_VALUE as register base type, it assumes BPF_READ for the subsequent call to check_map_access_type() and given the BPF map is read-only it succeeds. The helpers really need to be annotated as ARG_PTR_TO_{LONG,INT} | MEM_UNINIT when results are written into them as opposed to read out of them. The latter indicates that it's okay to pass a pointer to uninitialized memory as the memory is written to anyway. However, ARG_PTR_TO_{LONG,INT} is a special case of ARG_PTR_TO_FIXED_SIZE_MEM just with additional alignment requirement. So it is better to just get rid of the ARG_PTR_TO_{LONG,INT} special cases altogether and reuse the fixed size memory types. For this, add MEM_ALIGNED to additionally ensure alignment given these helpers write directly into the args via * = val. The .arg*_size has been initialized reflecting the actual sizeof(*). MEM_ALIGNED can only be used in combination with MEM_FIXED_SIZE annotated argument types, since in !MEM_FIXED_SIZE cases the verifier does not know the buffer size a priori and therefore cannot blindly write * = val.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47757", "url": "https://ubuntu.com/security/CVE-2024-47757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential oob read in nilfs_btree_check_delete() The function nilfs_btree_check_delete(), which checks whether degeneration to direct mapping occurs before deleting a b-tree entry, causes memory access outside the block buffer when retrieving the maximum key if the root node has no entries. This does not usually happen because b-tree mappings with 0 child nodes are never created by mkfs.nilfs2 or nilfs2 itself. However, it can happen if the b-tree root node read from a device is configured that way, so fix this potential issue by adding a check for that case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47699", "url": "https://ubuntu.com/security/CVE-2024-47699", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential null-ptr-deref in nilfs_btree_insert() Patch series \"nilfs2: fix potential issues with empty b-tree nodes\". This series addresses three potential issues with empty b-tree nodes that can occur with corrupted filesystem images, including one recently discovered by syzbot. This patch (of 3): If a b-tree is broken on the device, and the b-tree height is greater than 2 (the level of the root node is greater than 1) even if the number of child nodes of the b-tree root is 0, a NULL pointer dereference occurs in nilfs_btree_prepare_insert(), which is called from nilfs_btree_insert(). This is because, when the number of child nodes of the b-tree root is 0, nilfs_btree_do_lookup() does not set the block buffer head in any of path[x].bp_bh, leaving it as the initial value of NULL, but if the level of the b-tree root node is greater than 1, nilfs_btree_get_nonroot_node(), which accesses the buffer memory of path[x].bp_bh, is called. Fix this issue by adding a check to nilfs_btree_root_broken(), which performs sanity checks when reading the root node from the device, to detect this inconsistency. Thanks to Lizhi Xu for trying to solve the bug and clarifying the cause early on.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47700", "url": "https://ubuntu.com/security/CVE-2024-47700", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: check stripe size compatibility on remount as well We disable stripe size in __ext4_fill_super if it is not a multiple of the cluster ratio however this check is missed when trying to remount. This can leave us with cases where stripe < cluster_ratio after remount:set making EXT4_B2C(sbi->s_stripe) become 0 that can cause some unforeseen bugs like divide by 0. Fix that by adding the check in remount path as well.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47701", "url": "https://ubuntu.com/security/CVE-2024-47701", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid OOB when system.data xattr changes underneath the filesystem When looking up for an entry in an inlined directory, if e_value_offs is changed underneath the filesystem by some change in the block device, it will lead to an out-of-bounds access that KASAN detects as an UAF. EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none. loop0: detected capacity change from 2048 to 2047 ================================================================== BUG: KASAN: use-after-free in ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 Read of size 1 at addr ffff88803e91130f by task syz-executor269/5103 CPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 Not tainted 6.11.0-rc4-syzkaller #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:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 ext4_find_inline_entry+0x4be/0x5e0 fs/ext4/inline.c:1697 __ext4_find_entry+0x2b4/0x1b30 fs/ext4/namei.c:1573 ext4_lookup_entry fs/ext4/namei.c:1727 [inline] ext4_lookup+0x15f/0x750 fs/ext4/namei.c:1795 lookup_one_qstr_excl+0x11f/0x260 fs/namei.c:1633 filename_create+0x297/0x540 fs/namei.c:3980 do_symlinkat+0xf9/0x3a0 fs/namei.c:4587 __do_sys_symlinkat fs/namei.c:4610 [inline] __se_sys_symlinkat fs/namei.c:4607 [inline] __x64_sys_symlinkat+0x95/0xb0 fs/namei.c:4607 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:0x7f3e73ced469 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff4d40c258 EFLAGS: 00000246 ORIG_RAX: 000000000000010a RAX: ffffffffffffffda RBX: 0032656c69662f2e RCX: 00007f3e73ced469 RDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0 RBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290 R10: 0023706f6f6c2f76 R11: 0000000000000246 R12: 00007fff4d40c27c R13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0 Calling ext4_xattr_ibody_find right after reading the inode with ext4_get_inode_loc will lead to a check of the validity of the xattrs, avoiding this problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49850", "url": "https://ubuntu.com/security/CVE-2024-49850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: correctly handle malformed BPF_CORE_TYPE_ID_LOCAL relos In case of malformed relocation record of kind BPF_CORE_TYPE_ID_LOCAL referencing a non-existing BTF type, function bpf_core_calc_relo_insn would cause a null pointer deference. Fix this by adding a proper check upper in call stack, as malformed relocation records could be passed from user space. Simplest reproducer is a program: r0 = 0 exit With a single relocation record: .insn_off = 0, /* patch first instruction */ .type_id = 100500, /* this type id does not exist */ .access_str_off = 6, /* offset of string \"0\" */ .kind = BPF_CORE_TYPE_ID_LOCAL, See the link for original reproducer or next commit for a test case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47702", "url": "https://ubuntu.com/security/CVE-2024-47702", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fail verification for sign-extension of packet data/data_end/data_meta syzbot reported a kernel crash due to commit 1f1e864b6555 (\"bpf: Handle sign-extenstin ctx member accesses\"). The reason is due to sign-extension of 32-bit load for packet data/data_end/data_meta uapi field. The original code looks like: r2 = *(s32 *)(r1 + 76) /* load __sk_buff->data */ r3 = *(u32 *)(r1 + 80) /* load __sk_buff->data_end */ r0 = r2 r0 += 8 if r3 > r0 goto +1 ... Note that __sk_buff->data load has 32-bit sign extension. After verification and convert_ctx_accesses(), the final asm code looks like: r2 = *(u64 *)(r1 +208) r2 = (s32)r2 r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 ... Note that 'r2 = (s32)r2' may make the kernel __sk_buff->data address invalid which may cause runtime failure. Currently, in C code, typically we have void *data = (void *)(long)skb->data; void *data_end = (void *)(long)skb->data_end; ... and it will generate r2 = *(u64 *)(r1 +208) r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 If we allow sign-extension, void *data = (void *)(long)(int)skb->data; void *data_end = (void *)(long)skb->data_end; ... the generated code looks like r2 = *(u64 *)(r1 +208) r2 <<= 32 r2 s>>= 32 r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 and this will cause verification failure since \"r2 <<= 32\" is not allowed as \"r2\" is a packet pointer. To fix this issue for case r2 = *(s32 *)(r1 + 76) /* load __sk_buff->data */ this patch added additional checking in is_valid_access() callback function for packet data/data_end/data_meta access. If those accesses are with sign-extenstion, the verification will fail. [1] https://lore.kernel.org/bpf/000000000000c90eee061d236d37@google.com/", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47703", "url": "https://ubuntu.com/security/CVE-2024-47703", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, lsm: Add check for BPF LSM return value A bpf prog returning a positive number attached to file_alloc_security hook makes kernel panic. This happens because file system can not filter out the positive number returned by the LSM prog using IS_ERR, and misinterprets this positive number as a file pointer. Given that hook file_alloc_security never returned positive number before the introduction of BPF LSM, and other BPF LSM hooks may encounter similar issues, this patch adds LSM return value check in verifier, to ensure no unexpected value is returned.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49851", "url": "https://ubuntu.com/security/CVE-2024-49851", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: Clean up TPM space after command failure tpm_dev_transmit prepares the TPM space before attempting command transmission. However if the command fails no rollback of this preparation is done. This can result in transient handles being leaked if the device is subsequently closed with no further commands performed. Fix this by flushing the space in the event of command transmission failure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47723", "url": "https://ubuntu.com/security/CVE-2024-47723", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: fix out-of-bounds in dbNextAG() and diAlloc() In dbNextAG() , there is no check for the case where bmp->db_numag is greater or same than MAXAG due to a polluted image, which causes an out-of-bounds. Therefore, a bounds check should be added in dbMount(). And in dbNextAG(), a check for the case where agpref is greater than bmp->db_numag should be added, so an out-of-bounds exception should be prevented. Additionally, a check for the case where agno is greater or same than MAXAG should be added in diAlloc() to prevent out-of-bounds.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49852", "url": "https://ubuntu.com/security/CVE-2024-49852", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: elx: libefc: Fix potential use after free in efc_nport_vport_del() The kref_put() function will call nport->release if the refcount drops to zero. The nport->release release function is _efc_nport_free() which frees \"nport\". But then we dereference \"nport\" on the next line which is a use after free. Re-order these lines to avoid the use after free.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47720", "url": "https://ubuntu.com/security/CVE-2024-47720", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for set_output_gamma in dcn30_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn30_set_output_transfer_func function. Previously, set_output_gamma was being checked for nullity at line 386, but then it was being dereferenced without any nullity check at line 401. This could potentially lead to a null pointer dereference error if set_output_gamma is indeed null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a nullity check for set_output_gamma before the call to set_output_gamma at line 401. If set_output_gamma is null, we log an error message and do not call the function. This fix prevents a potential null pointer dereference error. drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:401 dcn30_set_output_transfer_func() error: we previously assumed 'mpc->funcs->set_output_gamma' could be null (see line 386) drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c 373 bool dcn30_set_output_transfer_func(struct dc *dc, 374 struct pipe_ctx *pipe_ctx, 375 const struct dc_stream_state *stream) 376 { 377 int mpcc_id = pipe_ctx->plane_res.hubp->inst; 378 struct mpc *mpc = pipe_ctx->stream_res.opp->ctx->dc->res_pool->mpc; 379 const struct pwl_params *params = NULL; 380 bool ret = false; 381 382 /* program OGAM or 3DLUT only for the top pipe*/ 383 if (pipe_ctx->top_pipe == NULL) { 384 /*program rmu shaper and 3dlut in MPC*/ 385 ret = dcn30_set_mpc_shaper_3dlut(pipe_ctx, stream); 386 if (ret == false && mpc->funcs->set_output_gamma) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If this is NULL 387 if (stream->out_transfer_func.type == TF_TYPE_HWPWL) 388 params = &stream->out_transfer_func.pwl; 389 else if (pipe_ctx->stream->out_transfer_func.type == 390 TF_TYPE_DISTRIBUTED_POINTS && 391 cm3_helper_translate_curve_to_hw_format( 392 &stream->out_transfer_func, 393 &mpc->blender_params, false)) 394 params = &mpc->blender_params; 395 /* there are no ROM LUTs in OUTGAM */ 396 if (stream->out_transfer_func.type == TF_TYPE_PREDEFINED) 397 BREAK_TO_DEBUGGER(); 398 } 399 } 400 --> 401 mpc->funcs->set_output_gamma(mpc, mpcc_id, params); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Then it will crash 402 return ret; 403 }", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47704", "url": "https://ubuntu.com/security/CVE-2024-47704", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check link_res->hpo_dp_link_enc before using it [WHAT & HOW] Functions dp_enable_link_phy and dp_disable_link_phy can pass link_res without initializing hpo_dp_link_enc and it is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49853", "url": "https://ubuntu.com/security/CVE-2024-49853", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix double free in OPTEE transport Channels can be shared between protocols, avoid freeing the same channel descriptors twice when unloading the stack.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47705", "url": "https://ubuntu.com/security/CVE-2024-47705", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix potential invalid pointer dereference in blk_add_partition The blk_add_partition() function initially used a single if-condition (IS_ERR(part)) to check for errors when adding a partition. This was modified to handle the specific case of -ENXIO separately, allowing the function to proceed without logging the error in this case. However, this change unintentionally left a path where md_autodetect_dev() could be called without confirming that part is a valid pointer. This commit separates the error handling logic by splitting the initial if-condition, improving code readability and handling specific error scenarios explicitly. The function now distinguishes the general error case from -ENXIO without altering the existing behavior of md_autodetect_dev() calls.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47736", "url": "https://ubuntu.com/security/CVE-2024-47736", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: handle overlapped pclusters out of crafted images properly syzbot reported a task hang issue due to a deadlock case where it is waiting for the folio lock of a cached folio that will be used for cache I/Os. After looking into the crafted fuzzed image, I found it's formed with several overlapped big pclusters as below: Ext: logical offset | length : physical offset | length 0: 0.. 16384 | 16384 : 151552.. 167936 | 16384 1: 16384.. 32768 | 16384 : 155648.. 172032 | 16384 2: 32768.. 49152 | 16384 : 537223168.. 537239552 | 16384 ... Here, extent 0/1 are physically overlapped although it's entirely _impossible_ for normal filesystem images generated by mkfs. First, managed folios containing compressed data will be marked as up-to-date and then unlocked immediately (unlike in-place folios) when compressed I/Os are complete. If physical blocks are not submitted in the incremental order, there should be separate BIOs to avoid dependency issues. However, the current code mis-arranges z_erofs_fill_bio_vec() and BIO submission which causes unexpected BIO waits. Second, managed folios will be connected to their own pclusters for efficient inter-queries. However, this is somewhat hard to implement easily if overlapped big pclusters exist. Again, these only appear in fuzzed images so let's simply fall back to temporary short-lived pages for correctness. Additionally, it justifies that referenced managed folios cannot be truncated for now and reverts part of commit 2080ca1ed3e4 (\"erofs: tidy up `struct z_erofs_bvec`\") for simplicity although it shouldn't be any difference.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47706", "url": "https://ubuntu.com/security/CVE-2024-47706", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block, bfq: fix possible UAF for bfqq->bic with merge chain 1) initial state, three tasks: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t\t | ? | ?\t\t | ? \t\t | | | |\t\t | | \t\t V | V |\t\t V | \t\t bfqq1 bfqq2\t\t bfqq3 process ref:\t 1\t\t 1\t\t 1 2) bfqq1 merged to bfqq2: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t\t | |\t\t | ? \t\t \\--------------\\|\t\t | | \t\t V\t\t V | \t\t bfqq1--------->bfqq2\t\t bfqq3 process ref:\t 0\t\t 2\t\t 1 3) bfqq2 merged to bfqq3: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t here -> ? |\t\t | \t\t \\--------------\\ \\-------------\\| \t\t V\t\t V \t\t bfqq1--------->bfqq2---------->bfqq3 process ref:\t 0\t\t 1\t\t 3 In this case, IO from Process 1 will get bfqq2 from BIC1 first, and then get bfqq3 through merge chain, and finially handle IO by bfqq3. Howerver, current code will think bfqq2 is owned by BIC1, like initial state, and set bfqq2->bic to BIC1. bfq_insert_request -> by Process 1 bfqq = bfq_init_rq(rq) bfqq = bfq_get_bfqq_handle_split bfqq = bic_to_bfqq -> get bfqq2 from BIC1 bfqq->ref++ rq->elv.priv[0] = bic rq->elv.priv[1] = bfqq if (bfqq_process_refs(bfqq) == 1) bfqq->bic = bic -> record BIC1 to bfqq2 __bfq_insert_request new_bfqq = bfq_setup_cooperator -> get bfqq3 from bfqq2->new_bfqq bfqq_request_freed(bfqq) new_bfqq->ref++ rq->elv.priv[1] = new_bfqq -> handle IO by bfqq3 Fix the problem by checking bfqq is from merge chain fist. And this might fix a following problem reported by our syzkaller(unreproducible): ================================================================== BUG: KASAN: slab-use-after-free in bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] BUG: KASAN: slab-use-after-free in bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] BUG: KASAN: slab-use-after-free in bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 Write of size 1 at addr ffff888123839eb8 by task kworker/0:1H/18595 CPU: 0 PID: 18595 Comm: kworker/0:1H Tainted: G L 6.6.0-07439-gba2303cacfda #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Workqueue: kblockd blk_mq_requeue_work Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [inline] print_report+0x10d/0x610 mm/kasan/report.c:475 kasan_report+0x8e/0xc0 mm/kasan/report.c:588 bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 bfq_get_bfqq_handle_split+0x169/0x5d0 block/bfq-iosched.c:6757 bfq_init_rq block/bfq-iosched.c:6876 [inline] bfq_insert_request block/bfq-iosched.c:6254 [inline] bfq_insert_requests+0x1112/0x5cf0 block/bfq-iosched.c:6304 blk_mq_insert_request+0x290/0x8d0 block/blk-mq.c:2593 blk_mq_requeue_work+0x6bc/0xa70 block/blk-mq.c:1502 process_one_work kernel/workqueue.c:2627 [inline] process_scheduled_works+0x432/0x13f0 kernel/workqueue.c:2700 worker_thread+0x6f2/0x1160 kernel/workqueue.c:2781 kthread+0x33c/0x440 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:305 Allocated by task 20776: kasan_save_stack+0x20/0x40 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 __kasan_slab_alloc+0x87/0x90 mm/kasan/common.c:328 kasan_slab_alloc include/linux/kasan.h:188 [inline] slab_post_alloc_hook mm/slab.h:763 [inline] slab_alloc_node mm/slub.c:3458 [inline] kmem_cache_alloc_node+0x1a4/0x6f0 mm/slub.c:3503 ioc_create_icq block/blk-ioc.c:370 [inline] ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49855", "url": "https://ubuntu.com/security/CVE-2024-49855", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: fix race between timeout and normal completion If request timetout is handled by nbd_requeue_cmd(), normal completion has to be stopped for avoiding to complete this requeued request, other use-after-free can be triggered. Fix the race by clearing NBD_CMD_INFLIGHT in nbd_requeue_cmd(), meantime make sure that cmd->lock is grabbed for clearing the flag and the requeue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47707", "url": "https://ubuntu.com/security/CVE-2024-47707", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev() Blamed commit accidentally removed a check for rt->rt6i_idev being NULL, as spotted by syzbot: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 UID: 0 PID: 10998 Comm: syz-executor Not tainted 6.11.0-rc6-syzkaller-00208-g625403177711 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 RBP: ffffc900047375d0 R08: 0000000000000003 R09: fffff520008e6e8c R10: dffffc0000000000 R11: fffff520008e6e8c R12: 1ffff1100fdf8f18 R13: ffff88807efc7998 R14: 0000000000000000 R15: ffff88807efc7930 FS: 0000000000000000(0000) GS:ffff8880b8900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020002a80 CR3: 0000000022f62000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: addrconf_ifdown+0x15d/0x1bd0 net/ipv6/addrconf.c:3856 addrconf_notify+0x3cb/0x1020 notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93 call_netdevice_notifiers_extack net/core/dev.c:2032 [inline] call_netdevice_notifiers net/core/dev.c:2046 [inline] unregister_netdevice_many_notify+0xd81/0x1c40 net/core/dev.c:11352 unregister_netdevice_many net/core/dev.c:11414 [inline] unregister_netdevice_queue+0x303/0x370 net/core/dev.c:11289 unregister_netdevice include/linux/netdevice.h:3129 [inline] __tun_detach+0x6b9/0x1600 drivers/net/tun.c:685 tun_detach drivers/net/tun.c:701 [inline] tun_chr_close+0x108/0x1b0 drivers/net/tun.c:3510 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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:0x7f1acc77def9 Code: Unable to access opcode bytes at 0x7f1acc77decf. RSP: 002b:00007ffeb26fa738 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1acc77def9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000043 RBP: 00007f1acc7dd508 R08: 00007ffeb26f84d7 R09: 0000000000000003 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 0000000000000003 R14: 00000000ffffffff R15: 00007ffeb26fa8e0 Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 R ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47708", "url": "https://ubuntu.com/security/CVE-2024-47708", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netkit: Assign missing bpf_net_context During the introduction of struct bpf_net_context handling for XDP-redirect, the netkit driver has been missed, which also requires it because NETKIT_REDIRECT invokes skb_do_redirect() which is accessing the per-CPU variables. Otherwise we see the following crash: \tBUG: kernel NULL pointer dereference, address: 0000000000000038 \tbpf_redirect() \tnetkit_xmit() \tdev_hard_start_xmit() Set the bpf_net_context before invoking netkit_xmit() program within the netkit driver.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47709", "url": "https://ubuntu.com/security/CVE-2024-47709", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: Clear bo->bcm_proc_read after remove_proc_entry(). syzbot reported a warning in bcm_release(). [0] The blamed change fixed another warning that is triggered when connect() is issued again for a socket whose connect()ed device has been unregistered. However, if the socket is just close()d without the 2nd connect(), the remaining bo->bcm_proc_read triggers unnecessary remove_proc_entry() in bcm_release(). Let's clear bo->bcm_proc_read after remove_proc_entry() in bcm_notify(). [0] name '4986' WARNING: CPU: 0 PID: 5234 at fs/proc/generic.c:711 remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Modules linked in: CPU: 0 UID: 0 PID: 5234 Comm: syz-executor606 Not tainted 6.11.0-rc5-syzkaller-00178-g5517ae241919 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Code: ff eb 05 e8 cb 1e 5e ff 48 8b 5c 24 10 48 c7 c7 e0 f7 aa 8e e8 2a 38 8e 09 90 48 c7 c7 60 3a 1b 8c 48 89 de e8 da 42 20 ff 90 <0f> 0b 90 90 48 8b 44 24 18 48 c7 44 24 40 0e 36 e0 45 49 c7 04 07 RSP: 0018:ffffc9000345fa20 EFLAGS: 00010246 RAX: 2a2d0aee2eb64600 RBX: ffff888032f1f548 RCX: ffff888029431e00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000345fb08 R08: ffffffff8155b2f2 R09: 1ffff1101710519a R10: dffffc0000000000 R11: ffffed101710519b R12: ffff888011d38640 R13: 0000000000000004 R14: 0000000000000000 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8880b8800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcfb52722f0 CR3: 000000000e734000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: bcm_release+0x250/0x880 net/can/bcm.c:1578 __sock_release net/socket.c:659 [inline] sock_close+0xbc/0x240 net/socket.c:1421 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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:0x7fcfb51ee969 Code: Unable to access opcode bytes at 0x7fcfb51ee93f. RSP: 002b:00007ffce0109ca8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fcfb51ee969 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 00007fcfb526f3b0 R08: ffffffffffffffb8 R09: 0000555500000000 R10: 0000555500000000 R11: 0000000000000246 R12: 00007fcfb526f3b0 R13: 0000000000000000 R14: 00007fcfb5271ee0 R15: 00007fcfb51bf160 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47710", "url": "https://ubuntu.com/security/CVE-2024-47710", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sock_map: Add a cond_resched() in sock_hash_free() Several syzbot soft lockup reports all have in common sock_hash_free() If a map with a large number of buckets is destroyed, we need to yield the cpu when needed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47711", "url": "https://ubuntu.com/security/CVE-2024-47711", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Don't return OOB skb in manage_oob(). syzbot reported use-after-free in unix_stream_recv_urg(). [0] The scenario is 1. send(MSG_OOB) 2. recv(MSG_OOB) -> The consumed OOB remains in recv queue 3. send(MSG_OOB) 4. recv() -> manage_oob() returns the next skb of the consumed OOB -> This is also OOB, but unix_sk(sk)->oob_skb is not cleared 5. recv(MSG_OOB) -> unix_sk(sk)->oob_skb is used but already freed The recent commit 8594d9b85c07 (\"af_unix: Don't call skb_get() for OOB skb.\") uncovered the issue. If the OOB skb is consumed and the next skb is peeked in manage_oob(), we still need to check if the skb is OOB. Let's do so by falling back to the following checks in manage_oob() and add the test case in selftest. Note that we need to add a similar check for SIOCATMARK. [0]: BUG: KASAN: slab-use-after-free in unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959 Read of size 4 at addr ffff8880326abcc4 by task syz-executor178/5235 CPU: 0 UID: 0 PID: 5235 Comm: syz-executor178 Not tainted 6.11.0-rc5-syzkaller-00742-gfbdaffe41adc #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959 unix_stream_recv_urg+0x1df/0x320 net/unix/af_unix.c:2640 unix_stream_read_generic+0x2456/0x2520 net/unix/af_unix.c:2778 unix_stream_recvmsg+0x22b/0x2c0 net/unix/af_unix.c:2996 sock_recvmsg_nosec net/socket.c:1046 [inline] sock_recvmsg+0x22f/0x280 net/socket.c:1068 ____sys_recvmsg+0x1db/0x470 net/socket.c:2816 ___sys_recvmsg net/socket.c:2858 [inline] __sys_recvmsg+0x2f0/0x3e0 net/socket.c:2888 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:0x7f5360d6b4e9 Code: 48 83 c4 28 c3 e8 37 17 00 00 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff29b3a458 EFLAGS: 00000246 ORIG_RAX: 000000000000002f RAX: ffffffffffffffda RBX: 00007fff29b3a638 RCX: 00007f5360d6b4e9 RDX: 0000000000002001 RSI: 0000000020000640 RDI: 0000000000000003 RBP: 00007f5360dde610 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 00007fff29b3a628 R14: 0000000000000001 R15: 0000000000000001 Allocated by task 5235: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:312 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slub.c:3988 [inline] slab_alloc_node mm/slub.c:4037 [inline] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4080 __alloc_skb+0x1c3/0x440 net/core/skbuff.c:667 alloc_skb include/linux/skbuff.h:1320 [inline] alloc_skb_with_frags+0xc3/0x770 net/core/skbuff.c:6528 sock_alloc_send_pskb+0x91a/0xa60 net/core/sock.c:2815 sock_alloc_send_skb include/net/sock.h:1778 [inline] queue_oob+0x108/0x680 net/unix/af_unix.c:2198 unix_stream_sendmsg+0xd24/0xf80 net/unix/af_unix.c:2351 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2680 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 Freed by task 5235: kasan_save_stack mm/kasan/common.c:47 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47712", "url": "https://ubuntu.com/security/CVE-2024-47712", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: fix potential RCU dereference issue in wilc_parse_join_bss_param In the `wilc_parse_join_bss_param` function, the TSF field of the `ies` structure is accessed after the RCU read-side critical section is unlocked. According to RCU usage rules, this is illegal. Reusing this pointer can lead to unpredictable behavior, including accessing memory that has been updated or causing use-after-free issues. This possible bug was identified using a static analysis tool developed by myself, specifically designed to detect RCU-related issues. To address this, the TSF value is now stored in a local variable `ies_tsf` before the RCU lock is released. The `param->tsf_lo` field is then assigned using this local variable, ensuring that the TSF value is safely accessed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47713", "url": "https://ubuntu.com/security/CVE-2024-47713", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop() Since '__dev_queue_xmit()' should be called with interrupts enabled, the following backtrace: ieee80211_do_stop() ... spin_lock_irqsave(&local->queue_stop_reason_lock, flags) ... ieee80211_free_txskb() ieee80211_report_used_skb() ieee80211_report_ack_skb() cfg80211_mgmt_tx_status_ext() nl80211_frame_tx_status() genlmsg_multicast_netns() genlmsg_multicast_netns_filtered() nlmsg_multicast_filtered() \t netlink_broadcast_filtered() \t do_one_broadcast() \t netlink_broadcast_deliver() \t __netlink_sendskb() \t netlink_deliver_tap() \t __netlink_deliver_tap_skb() \t dev_queue_xmit() \t __dev_queue_xmit() ; with IRQS disabled ... spin_unlock_irqrestore(&local->queue_stop_reason_lock, flags) issues the warning (as reported by syzbot reproducer): WARNING: CPU: 2 PID: 5128 at kernel/softirq.c:362 __local_bh_enable_ip+0xc3/0x120 Fix this by implementing a two-phase skb reclamation in 'ieee80211_do_stop()', where actual work is performed outside of a section with interrupts disabled.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47730", "url": "https://ubuntu.com/security/CVE-2024-47730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/qm - inject error before stopping queue The master ooo cannot be completely closed when the accelerator core reports memory error. Therefore, the driver needs to inject the qm error to close the master ooo. Currently, the qm error is injected after stopping queue, memory may be released immediately after stopping queue, causing the device to access the released memory. Therefore, error is injected to close master ooo before stopping queue to ensure that the device does not access the released memory.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49856", "url": "https://ubuntu.com/security/CVE-2024-49856", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/sgx: Fix deadlock in SGX NUMA node search When the current node doesn't have an EPC section configured by firmware and all other EPC sections are used up, CPU can get stuck inside the while loop that looks for an available EPC page from remote nodes indefinitely, leading to a soft lockup. Note how nid_of_current will never be equal to nid in that while loop because nid_of_current is not set in sgx_numa_mask. Also worth mentioning is that it's perfectly fine for the firmware not to setup an EPC section on a node. While setting up an EPC section on each node can enhance performance, it is not a requirement for functionality. Rework the loop to start and end on *a* node that has SGX memory. This avoids the deadlock looking for the current SGX-lacking node to show up in the loop when it never will.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47714", "url": "https://ubuntu.com/security/CVE-2024-47714", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: use hweight16 to get correct tx antenna The chainmask is u16 so using hweight8 cannot get correct tx_ant. Without this patch, the tx_ant of band 2 would be -1 and lead to the following issue: BUG: KASAN: stack-out-of-bounds in mt7996_mcu_add_sta+0x12e0/0x16e0 [mt7996e]", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47715", "url": "https://ubuntu.com/security/CVE-2024-47715", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: fix oops on non-dbdc mt7986 mt7915_band_config() sets band_idx = 1 on the main phy for mt7986 with MT7975_ONE_ADIE or MT7976_ONE_ADIE. Commit 0335c034e726 (\"wifi: mt76: fix race condition related to checking tx queue fill status\") introduced a dereference of the phys array indirectly indexed by band_idx via wcid->phy_idx in mt76_wcid_cleanup(). This caused the following Oops on affected mt7986 devices: Unable to handle kernel read from unreadable memory at virtual address 0000000000000024 Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x00000005 CM = 0, WnR = 0 user pgtable: 4k pages, 39-bit VAs, pgdp=0000000042545000 [0000000000000024] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 Internal error: Oops: 0000000096000005 [#1] SMP Modules linked in: ... mt7915e mt76_connac_lib mt76 mac80211 cfg80211 ... CPU: 2 PID: 1631 Comm: hostapd Not tainted 5.15.150 #0 Hardware name: ZyXEL EX5700 (Telenor) (DT) pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mt76_wcid_cleanup+0x84/0x22c [mt76] lr : mt76_wcid_cleanup+0x64/0x22c [mt76] sp : ffffffc00a803700 x29: ffffffc00a803700 x28: ffffff80008f7300 x27: ffffff80003f3c00 x26: ffffff80000a7880 x25: ffffffc008c26e00 x24: 0000000000000001 x23: ffffffc000a68114 x22: 0000000000000000 x21: ffffff8004172cc8 x20: ffffffc00a803748 x19: ffffff8004152020 x18: 0000000000000000 x17: 00000000000017c0 x16: ffffffc008ef5000 x15: 0000000000000be0 x14: ffffff8004172e28 x13: ffffff8004172e28 x12: 0000000000000000 x11: 0000000000000000 x10: ffffff8004172e30 x9 : ffffff8004172e28 x8 : 0000000000000000 x7 : ffffff8004156020 x6 : 0000000000000000 x5 : 0000000000000031 x4 : 0000000000000000 x3 : 0000000000000001 x2 : 0000000000000000 x1 : ffffff80008f7300 x0 : 0000000000000024 Call trace: mt76_wcid_cleanup+0x84/0x22c [mt76] __mt76_sta_remove+0x70/0xbc [mt76] mt76_sta_state+0x8c/0x1a4 [mt76] mt7915_eeprom_get_power_delta+0x11e4/0x23a0 [mt7915e] drv_sta_state+0x144/0x274 [mac80211] sta_info_move_state+0x1cc/0x2a4 [mac80211] sta_set_sinfo+0xaf8/0xc24 [mac80211] sta_info_destroy_addr_bss+0x4c/0x6c [mac80211] ieee80211_color_change_finish+0x1c08/0x1e70 [mac80211] cfg80211_check_station_change+0x1360/0x4710 [cfg80211] genl_family_rcv_msg_doit+0xb4/0x110 genl_rcv_msg+0xd0/0x1bc netlink_rcv_skb+0x58/0x120 genl_rcv+0x34/0x50 netlink_unicast+0x1f0/0x2ec netlink_sendmsg+0x198/0x3d0 ____sys_sendmsg+0x1b0/0x210 ___sys_sendmsg+0x80/0xf0 __sys_sendmsg+0x44/0xa0 __arm64_sys_sendmsg+0x20/0x30 invoke_syscall.constprop.0+0x4c/0xe0 do_el0_svc+0x40/0xd0 el0_svc+0x14/0x4c el0t_64_sync_handler+0x100/0x110 el0t_64_sync+0x15c/0x160 Code: d2800002 910092c0 52800023 f9800011 (885f7c01) ---[ end trace 7e42dd9a39ed2281 ]--- Fix by using mt76_dev_phy() which will map band_idx to the correct phy for all hardware combinations.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49857", "url": "https://ubuntu.com/security/CVE-2024-49857", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: set the cipher for secured NDP ranging The cipher pointer is not set, but is derefereced trying to set its content, which leads to a NULL pointer dereference. Fix it by pointing to the cipher parameter before dereferencing.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47738", "url": "https://ubuntu.com/security/CVE-2024-47738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: don't use rate mask for offchannel TX either Like the commit ab9177d83c04 (\"wifi: mac80211: don't use rate mask for scanning\"), ignore incorrect settings to avoid no supported rate warning reported by syzbot. The syzbot did bisect and found cause is commit 9df66d5b9f45 (\"cfg80211: fix default HE tx bitrate mask in 2G band\"), which however corrects bitmask of HE MCS and recognizes correctly settings of empty legacy rate plus HE MCS rate instead of returning -EINVAL. As suggestions [1], follow the change of SCAN TX to consider this case of offchannel TX as well. [1] https://lore.kernel.org/linux-wireless/6ab2dc9c3afe753ca6fdcdd1421e7a1f47e87b84.camel@sipsolutions.net/T/#m2ac2a6d2be06a37c9c47a3d8a44b4f647ed4f024", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47731", "url": "https://ubuntu.com/security/CVE-2024-47731", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers/perf: Fix ali_drw_pmu driver interrupt status clearing The alibaba_uncore_pmu driver forgot to clear all interrupt status in the interrupt processing function. After the PMU counter overflow interrupt occurred, an interrupt storm occurred, causing the system to hang. Therefore, clear the correct interrupt status in the interrupt handling function to fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49862", "url": "https://ubuntu.com/security/CVE-2024-49862", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powercap: intel_rapl: Fix off by one in get_rpi() The rp->priv->rpi array is either rpi_msr or rpi_tpmi which have NR_RAPL_PRIMITIVES number of elements. Thus the > needs to be >= to prevent an off by one access.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47716", "url": "https://ubuntu.com/security/CVE-2024-47716", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: 9410/1: vfp: Use asm volatile in fmrx/fmxr macros Floating point instructions in userspace can crash some arm kernels built with clang/LLD 17.0.6: BUG: unsupported FP instruction in kernel mode FPEXC == 0xc0000780 Internal error: Oops - undefined instruction: 0 [#1] ARM CPU: 0 PID: 196 Comm: vfp-reproducer Not tainted 6.10.0 #1 Hardware name: BCM2835 PC is at vfp_support_entry+0xc8/0x2cc LR is at do_undefinstr+0xa8/0x250 pc : [] lr : [] psr: a0000013 sp : dc8d1f68 ip : 60000013 fp : bedea19c r10: ec532b17 r9 : 00000010 r8 : 0044766c r7 : c0000780 r6 : ec532b17 r5 : c1c13800 r4 : dc8d1fb0 r3 : c10072c4 r2 : c0101c88 r1 : ec532b17 r0 : 0044766c Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 00c5387d Table: 0251c008 DAC: 00000051 Register r0 information: non-paged memory Register r1 information: vmalloc memory Register r2 information: non-slab/vmalloc memory Register r3 information: non-slab/vmalloc memory Register r4 information: 2-page vmalloc region Register r5 information: slab kmalloc-cg-2k Register r6 information: vmalloc memory Register r7 information: non-slab/vmalloc memory Register r8 information: non-paged memory Register r9 information: zero-size pointer Register r10 information: vmalloc memory Register r11 information: non-paged memory Register r12 information: non-paged memory Process vfp-reproducer (pid: 196, stack limit = 0x61aaaf8b) Stack: (0xdc8d1f68 to 0xdc8d2000) 1f60: 0000081f b6f69300 0000000f c10073f4 c10072c4 dc8d1fb0 1f80: ec532b17 0c532b17 0044766c b6f9ccd8 00000000 c010a80c 00447670 60000010 1fa0: ffffffff c1c13800 00c5387d c0100f10 b6f68af8 00448fc0 00000000 bedea188 1fc0: bedea314 00000001 00448ebc b6f9d000 00447608 b6f9ccd8 00000000 bedea19c 1fe0: bede9198 bedea188 b6e1061c 0044766c 60000010 ffffffff 00000000 00000000 Call trace: [] (vfp_support_entry) from [] (do_undefinstr+0xa8/0x250) [] (do_undefinstr) from [] (__und_usr+0x70/0x80) Exception stack(0xdc8d1fb0 to 0xdc8d1ff8) 1fa0: b6f68af8 00448fc0 00000000 bedea188 1fc0: bedea314 00000001 00448ebc b6f9d000 00447608 b6f9ccd8 00000000 bedea19c 1fe0: bede9198 bedea188 b6e1061c 0044766c 60000010 ffffffff Code: 0a000061 e3877202 e594003c e3a09010 (eef16a10) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Fatal exception in interrupt ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]--- This is a minimal userspace reproducer on a Raspberry Pi Zero W: #include #include int main(void) { double v = 1.0; printf(\"%fn\", NAN + *(volatile double *)&v); return 0; } Another way to consistently trigger the oops is: calvin@raspberry-pi-zero-w ~$ python -c \"import json\" The bug reproduces only when the kernel is built with DYNAMIC_DEBUG=n, because the pr_debug() calls act as barriers even when not activated. This is the output from the same kernel source built with the same compiler and DYNAMIC_DEBUG=y, where the userspace reproducer works as expected: VFP: bounce: trigger ec532b17 fpexc c0000780 VFP: emulate: INST=0xee377b06 SCR=0x00000000 VFP: bounce: trigger eef1fa10 fpexc c0000780 VFP: emulate: INST=0xeeb40b40 SCR=0x00000000 VFP: raising exceptions 30000000 calvin@raspberry-pi-zero-w ~$ ./vfp-reproducer nan Crudely grepping for vmsr/vmrs instructions in the otherwise nearly idential text for vfp_support_entry() makes the problem obvious: vmlinux.llvm.good [0xc0101cb8] <+48>: vmrs r7, fpexc vmlinux.llvm.good [0xc0101cd8] <+80>: vmsr fpexc, r0 vmlinux.llvm.good [0xc0101d20 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47717", "url": "https://ubuntu.com/security/CVE-2024-47717", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RISC-V: KVM: Don't zero-out PMU snapshot area before freeing data With the latest Linux-6.11-rc3, the below NULL pointer crash is observed when SBI PMU snapshot is enabled for the guest and the guest is forcefully powered-off. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000508 Oops [#1] Modules linked in: kvm CPU: 0 UID: 0 PID: 61 Comm: term-poll Not tainted 6.11.0-rc3-00018-g44d7178dd77a #3 Hardware name: riscv-virtio,qemu (DT) epc : __kvm_write_guest_page+0x94/0xa6 [kvm] ra : __kvm_write_guest_page+0x54/0xa6 [kvm] epc : ffffffff01590e98 ra : ffffffff01590e58 sp : ffff8f80001f39b0 gp : ffffffff81512a60 tp : ffffaf80024872c0 t0 : ffffaf800247e000 t1 : 00000000000007e0 t2 : 0000000000000000 s0 : ffff8f80001f39f0 s1 : 00007fff89ac4000 a0 : ffffffff015dd7e8 a1 : 0000000000000086 a2 : 0000000000000000 a3 : ffffaf8000000000 a4 : ffffaf80024882c0 a5 : 0000000000000000 a6 : ffffaf800328d780 a7 : 00000000000001cc s2 : ffffaf800197bd00 s3 : 00000000000828c4 s4 : ffffaf800248c000 s5 : ffffaf800247d000 s6 : 0000000000001000 s7 : 0000000000001000 s8 : 0000000000000000 s9 : 00007fff861fd500 s10: 0000000000000001 s11: 0000000000800000 t3 : 00000000000004d3 t4 : 00000000000004d3 t5 : ffffffff814126e0 t6 : ffffffff81412700 status: 0000000200000120 badaddr: 0000000000000508 cause: 000000000000000d [] __kvm_write_guest_page+0x94/0xa6 [kvm] [] kvm_vcpu_write_guest+0x56/0x90 [kvm] [] kvm_pmu_clear_snapshot_area+0x42/0x7e [kvm] [] kvm_riscv_vcpu_pmu_deinit.part.0+0xe0/0x14e [kvm] [] kvm_riscv_vcpu_pmu_deinit+0x1a/0x24 [kvm] [] kvm_arch_vcpu_destroy+0x28/0x4c [kvm] [] kvm_destroy_vcpus+0x5a/0xda [kvm] [] kvm_arch_destroy_vm+0x14/0x28 [kvm] [] kvm_destroy_vm+0x168/0x2a0 [kvm] [] kvm_put_kvm+0x3c/0x58 [kvm] [] kvm_vm_release+0x22/0x2e [kvm] Clearly, the kvm_vcpu_write_guest() function is crashing because it is being called from kvm_pmu_clear_snapshot_area() upon guest tear down. To address the above issue, simplify the kvm_pmu_clear_snapshot_area() to not zero-out PMU snapshot area from kvm_pmu_clear_snapshot_area() because the guest is anyway being tore down. The kvm_pmu_clear_snapshot_area() is also called when guest changes PMU snapshot area of a VCPU but even in this case the previous PMU snaphsot area must not be zeroed-out because the guest might have reclaimed the pervious PMU snapshot area for some other purpose.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47721", "url": "https://ubuntu.com/security/CVE-2024-47721", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: remove unused C2H event ID RTW89_MAC_C2H_FUNC_READ_WOW_CAM to prevent out-of-bounds reading The handler of firmware C2H event RTW89_MAC_C2H_FUNC_READ_WOW_CAM isn't implemented, but driver expects number of handlers is NUM_OF_RTW89_MAC_C2H_FUNC_WOW causing out-of-bounds access. Fix it by removing ID. Addresses-Coverity-ID: 1598775 (\"Out-of-bounds read\")", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47732", "url": "https://ubuntu.com/security/CVE-2024-47732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: iaa - Fix potential use after free bug The free_device_compression_mode(iaa_device, device_mode) function frees \"device_mode\" but it iss passed to iaa_compression_modes[i]->free() a few lines later resulting in a use after free. The good news is that, so far as I can tell, nothing implements the ->free() function and the use after free happens in dead code. But, with this fix, when something does implement it, we'll be ready. :)", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47718", "url": "https://ubuntu.com/security/CVE-2024-47718", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: always wait for both firmware loading attempts In 'rtw_wait_firmware_completion()', always wait for both (regular and wowlan) firmware loading attempts. Otherwise if 'rtw_usb_intf_init()' has failed in 'rtw_usb_probe()', 'rtw_usb_disconnect()' may issue 'ieee80211_free_hw()' when one of 'rtw_load_firmware_cb()' (usually the wowlan one) is still in progress, causing UAF detected by KASAN.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47724", "url": "https://ubuntu.com/security/CVE-2024-47724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: use work queue to process beacon tx event Commit 3a415daa3e8b (\"wifi: ath11k: add P2P IE in beacon template\") from Feb 28, 2024 (linux-next), leads to the following Smatch static checker warning: drivers/net/wireless/ath/ath11k/wmi.c:1742 ath11k_wmi_p2p_go_bcn_ie() warn: sleeping in atomic context The reason is that ath11k_bcn_tx_status_event() will directly call might sleep function ath11k_wmi_cmd_send() during RCU read-side critical sections. The call trace is like: ath11k_bcn_tx_status_event() -> rcu_read_lock() -> ath11k_mac_bcn_tx_event() \t-> ath11k_mac_setup_bcn_tmpl() \t…… \t\t-> ath11k_wmi_bcn_tmpl() \t\t\t-> ath11k_wmi_cmd_send() -> rcu_read_unlock() Commit 886433a98425 (\"ath11k: add support for BSS color change\") added the ath11k_mac_bcn_tx_event(), commit 01e782c89108 (\"ath11k: fix warning of RCU usage for ath11k_mac_get_arvif_by_vdev_id()\") added the RCU lock to avoid warning but also introduced this BUG. Use work queue to avoid directly calling ath11k_mac_bcn_tx_event() during RCU critical sections. No need to worry about the deletion of vif because cancel_work_sync() will drop the work if it doesn't start or block vif deletion until the running work is done. 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": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47671", "url": "https://ubuntu.com/security/CVE-2024-47671", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: usbtmc: prevent kernel-usb-infoleak The syzbot reported a kernel-usb-infoleak in usbtmc_write, we need to clear the structure before filling fields.", "cve_priority": "medium", "cve_public_date": "2024-10-09 15:15:00 UTC" }, { "cve": "CVE-2024-46869", "url": "https://ubuntu.com/security/CVE-2024-46869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btintel_pcie: Allocate memory for driver private data Fix driver not allocating memory for struct btintel_data which is used to store internal data.", "cve_priority": "medium", "cve_public_date": "2024-09-30 16:15:00 UTC" }, { "cve": "CVE-2024-53164", "url": "https://ubuntu.com/security/CVE-2024-53164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: fix ordering of qlen adjustment Changes to sch->q.qlen around qdisc_tree_reduce_backlog() need to happen _before_ a call to said function because otherwise it may fail to notify parent qdiscs when the child is about to become empty.", "cve_priority": "medium", "cve_public_date": "2024-12-27 14:15:00 UTC" }, { "cve": "CVE-2024-53103", "url": "https://ubuntu.com/security/CVE-2024-53103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hv_sock: Initializing vsk->trans to NULL to prevent a dangling pointer When hvs is released, there is a possibility that vsk->trans may not be initialized to NULL, which could lead to a dangling pointer. This issue is resolved by initializing vsk->trans to NULL.", "cve_priority": "high", "cve_public_date": "2024-12-02 08:15:00 UTC" } ], "log": [ "", " * oracular/linux: 6.11.0-17.17 -proposed tracker (LP: #2093643)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/2025.01.13)", "", " * When /dev/vmbus/hv_kvp is not present, disable hv-kvp-daemon (LP: #2091744)", " - [Packaging] disable hv-kvp-daemon if needed", "", " * Backport \"netkit: Add option for scrubbing skb meta data\" to 6.8", " (LP: #2091184)", " - netkit: Add option for scrubbing skb meta data", "", " * KVM: Cache CPUID at KVM.ko module init to reduce latency of VM-Enter and VM-", " Exit (LP: #2093146)", " - KVM: x86: Cache CPUID.0xD XSTATE offsets+sizes during module init", "", " * [SRU] add support of QCA BT 0489:e0fc (LP: #2085406)", " - Bluetooth: btusb: add Foxconn 0xe0fc for Qualcomm WCN785x", "", " * oracular: ubuntu_boot lib/dynamic_queue_limits.c:99! (LP: #2089684)", " - virtio_net: correct netdev_tx_reset_queue() invocation point", " - virtio_ring: add a func argument 'recycle_done' to virtqueue_resize()", " - virtio_net: ensure netdev_tx_reset_queue is called on tx ring resize", "", " * Failed to probe for OVTI02C1: chip id mismatch: 560243!=0 (LP: #2090932)", " - SAUCE: ACPI: scan: Update HID for new platform", "", " * Bluetooth[8086:a876] crash with \"hci0: Failed to read MSFT supported", " features (-110)\" (LP: #2085485)", " - Bluetooth: btintel_pcie: Add recovery mechanism", "", " * Poor bluetooth performance on Lenovo X13s (LP: #2089357)", " - SAUCE: Bluetooth: qca: Support downloading board ID specific NVM for WCN6855", "", " * vfio_pci soft lockup on VM start while using PCIe passthrough (LP: #2089306)", " - SAUCE: Revert \"mm: use rwsem assertion macros for mmap_lock\"", " - SAUCE: Revert \"vfio/pci: Insert full vma on mmap'd MMIO fault\"", " - SAUCE: Revert \"vfio/pci: Use unmap_mapping_range()\"", "", " * Oracular update: v6.11.11 upstream stable release (LP: #2091655)", " - wifi: mac80211: Fix setting txpower with emulate_chanctx", " - wifi: cfg80211: Add wiphy_delayed_work_pending()", " - wifi: mac80211: Convert color collision detection to wiphy work", " - wifi: radiotap: Avoid -Wflex-array-member-not-at-end warnings", " - spi: stm32: fix missing device mode capability in stm32mp25", " - ASoC: codecs: rt5640: Always disable IRQs from rt5640_cancel_work()", " - ASoC: Intel: bytcr_rt5640: Add support for non ACPI instantiated codec", " - ASoC: Intel: bytcr_rt5640: Add DMI quirk for Vexia Edu Atla 10 tablet", " - ASoC: Intel: sst: Support LPE0F28 ACPI HID", " - wifi: iwlwifi: mvm: Use the sync timepoint API in suspend", " - wifi: iwlwifi: mvm: SAR table alignment", " - mac80211: fix user-power when emulating chanctx", " - usb: add support for new USB device ID 0x17EF:0x3098 for the r8152 driver", " - usb: typec: use cleanup facility for 'altmodes_node'", " - selftests/watchdog-test: Fix system accidentally reset after watchdog-test", " - ALSA: hda/realtek: Add subwoofer quirk for Infinix ZERO BOOK 13", " - ASoC: codecs: wcd937x: add missing LO Switch control", " - ASoC: codecs: wcd937x: relax the AUX PDM watchdog", " - x86/amd_nb: Fix compile-testing without CONFIG_AMD_NB", " - bpf: fix filed access without lock", " - net: usb: qmi_wwan: add Quectel RG650V", " - soc: qcom: Add check devm_kasprintf() returned value", " - firmware: arm_scmi: Reject clear channel request on A2P", " - regulator: rk808: Add apply_bit for BUCK3 on RK809", " - platform/x86: dell-smbios-base: Extends support to Alienware products", " - platform/x86: dell-wmi-base: Handle META key Lock/Unlock events", " - platform/x86: ideapad-laptop: add missing Ideapad Pro 5 fn keys", " - ASoC: tas2781: Add new driver version for tas2563 & tas2781 qfn chip", " - tools/lib/thermal: Remove the thermal.h soft link when doing make clean", " - can: j1939: fix error in J1939 documentation.", " - platform/x86: thinkpad_acpi: Fix for ThinkPad's with ECFW showing incorrect", " fan speed", " - ASoC: amd: yc: Support dmic on another model of Lenovo Thinkpad E14 Gen 6", " - ASoC: stm: Prevent potential division by zero in stm32_sai_mclk_round_rate()", " - ASoC: stm: Prevent potential division by zero in stm32_sai_get_clk_div()", " - drm: panel-orientation-quirks: Make Lenovo Yoga Tab 3 X90F DMI match less", " strict", " - proc/softirqs: replace seq_printf with seq_put_decimal_ull_width", " - integrity: Use static_assert() to check struct sizes", " - ASoC: audio-graph-card2: Purge absent supplies for device tree nodes", " - LoongArch: For all possible CPUs setup logical-physical CPU mapping", " - LoongArch: Define a default value for VM_DATA_DEFAULT_FLAGS", " - ASoC: max9768: Fix event generation for playback mute", " - ALSA: usb-audio: Fix Yamaha P-125 Quirk Entry", " - ARM: 9420/1: smp: Fix SMP for xip kernels", " - ARM: 9434/1: cfi: Fix compilation corner case", " - ipmr: Fix access to mfc_cache_list without lock held", " - f2fs: fix fiemap failure issue when page size is 16KB", " - drm/amd/display: Skip Invalid Streams from DSC Policy", " - drm/amd/display: Fix incorrect DSC recompute trigger", " - s390/facilities: Fix warning about shadow of global variable", " - efs: fix the efs new mount api implementation", " - arm64: probes: Disable kprobes/uprobes on MOPS instructions", " - kselftest/arm64: hwcap: fix f8dp2 cpuinfo name", " - kselftest/arm64: mte: fix printf type warnings about __u64", " - kselftest/arm64: mte: fix printf type warnings about longs", " - block/fs: Pass an iocb to generic_atomic_write_valid()", " - fs/block: Check for IOCB_DIRECT in generic_atomic_write_valid()", " - s390/cio: Do not unregister the subchannel based on DNV", " - s390/pageattr: Implement missing kernel_page_present()", " - x86/pvh: Set phys_base when calling xen_prepare_pvh()", " - x86/pvh: Call C code via the kernel virtual mapping", " - brd: defer automatic disk creation until module initialization succeeds", " - ext4: avoid remount errors with 'abort' mount option", " - mips: asm: fix warning when disabling MIPS_FP_SUPPORT", " - arm64: Expose ID_AA64ISAR1_EL1.XS to sanitised feature consumers", " - kselftest/arm64: Fix encoding for SVE B16B16 test", " - nvme-pci: fix freeing of the HMB descriptor table", " - m68k: mvme147: Fix SCSI controller IRQ numbers", " - m68k: mvme147: Reinstate early console", " - arm64: fix .data.rel.ro size assertion when CONFIG_LTO_CLANG", " - acpi/arm64: Adjust error handling procedure in gtdt_parse_timer_block()", " - loop: fix type of block size", " - cachefiles: Fix incorrect length return value in", " cachefiles_ondemand_fd_write_iter()", " - cachefiles: Fix missing pos updates in cachefiles_ondemand_fd_write_iter()", " - cachefiles: Fix NULL pointer dereference in object->file", " - netfs/fscache: Add a memory barrier for FSCACHE_VOLUME_CREATING", " - block: constify the lim argument to queue_limits_max_zone_append_sectors", " - block: properly handle REQ_OP_ZONE_APPEND in __bio_split_to_limits", " - block: take chunk_sectors into account in bio_split_write_zeroes", " - block: fix bio_split_rw_at to take zone_write_granularity into account", " - s390/syscalls: Avoid creation of arch/arch/ directory", " - hfsplus: don't query the device logical block size multiple times", " - ext4: pipeline buffer reads in mext_page_mkuptodate()", " - ext4: remove array of buffer_heads from mext_page_mkuptodate()", " - ext4: fix race in buffer_head read fault injection", " - nvme-pci: reverse request order in nvme_queue_rqs", " - virtio_blk: reverse request order in virtio_queue_rqs", " - crypto: mxs-dcp - Fix AES-CBC with hardware-bound keys", " - crypto: caam - Fix the pointer passed to caam_qi_shutdown()", " - crypto: qat - remove check after debugfs_create_dir()", " - crypto: qat/qat_420xx - fix off by one in uof_get_name()", " - crypto: qat/qat_4xxx - fix off by one in uof_get_name()", " - firmware: google: Unregister driver_info on failure", " - EDAC/bluefield: Fix potential integer overflow", " - crypto: qat - remove faulty arbiter config reset", " - thermal: core: Initialize thermal zones before registering them", " - thermal: core: Drop thermal_zone_device_is_enabled()", " - thermal: core: Rearrange PM notification code", " - thermal: core: Represent suspend-related thermal zone flags as bits", " - thermal: core: Mark thermal zones as initializing to start with", " - thermal: core: Fix race between zone registration and system suspend", " - EDAC/fsl_ddr: Fix bad bit shift operations", " - EDAC/skx_common: Differentiate memory error sources", " - EDAC/{skx_common,i10nm}: Fix incorrect far-memory error source indicator", " - crypto: pcrypt - Call crypto layer directly when padata_do_parallel() return", " -EBUSY", " - crypto: cavium - Fix the if condition to exit loop after timeout", " - cpufreq/amd-pstate: Don't update CPPC request in", " amd_pstate_cpu_boost_update()", " - amd-pstate: Set min_perf to nominal_perf for active mode performance gov", " - crypto: hisilicon/qm - disable same error report before resetting", " - EDAC/igen6: Avoid segmentation fault on module unload", " - crypto: qat - Fix missing destroy_workqueue in adf_init_aer()", " - crypto: inside-secure - Fix the return value of safexcel_xcbcmac_cra_init()", " - sched/cpufreq: Ensure sd is rebuilt for EAS check", " - doc: rcu: update printed dynticks counter bits", " - rcu/srcutiny: don't return before reenabling preemption", " - rcu/kvfree: Fix data-race in __mod_timer / kvfree_call_rcu", " - hwmon: (pmbus/core) clear faults after setting smbalert mask", " - hwmon: (nct6775-core) Fix overflows seen when writing limit attributes", " - ACPI: CPPC: Fix _CPC register setting issue", " - crypto: caam - add error check to caam_rsa_set_priv_key_form", " - crypto: bcm - add error check in the ahash_hmac_init function", " - crypto: cavium - Fix an error handling path in cpt_ucode_load_fw()", " - rcuscale: Do a proper cleanup if kfree_scale_init() fails", " - tools/lib/thermal: Make more generic the command encoding function", " - thermal/lib: Fix memory leak on error in thermal_genl_auto()", " - x86/unwind/orc: Fix unwind for newly forked tasks", " - Revert \"scripts/faddr2line: Check only two symbols when calculating symbol", " size\"", " - cleanup: Remove address space of returned pointer", " - time: Partially revert cleanup on msecs_to_jiffies() documentation", " - time: Fix references to _msecs_to_jiffies() handling of values", " - locking/atomic/x86: Use ALT_OUTPUT_SP() for __alternative_atomic64()", " - locking/atomic/x86: Use ALT_OUTPUT_SP() for __arch_{,try_}cmpxchg64_emu()", " - kcsan, seqlock: Support seqcount_latch_t", " - kcsan, seqlock: Fix incorrect assumption in read_seqbegin()", " - clocksource/drivers:sp804: Make user selectable", " - clocksource/drivers/timer-ti-dm: Fix child node refcount handling", " - regulator: qcom-smd: make smd_vreg_rpm static", " - spi: spi-fsl-lpspi: Use IRQF_NO_AUTOEN flag in request_irq()", " - arm64: dts: qcom: qcs6390-rb3gen2: use modem.mbn for modem DSP", " - ARM: dts: renesas: genmai: Fix partition size for QSPI NOR Flash", " - drivers: soc: xilinx: add the missing kfree in xlnx_add_cb_for_suspend()", " - microblaze: Export xmb_manager functions", " - arm64: dts: mediatek: mt8188: Fix wrong clock provider in MFG1 power domain", " - arm64: dts: mediatek: mt8395-genio-1200-evk: Fix dtbs_check error for phy", " - arm64: dts: mt8195: Fix dtbs_check error for mutex node", " - arm64: dts: mt8195: Fix dtbs_check error for infracfg_ao node", " - soc: ti: smartreflex: Use IRQF_NO_AUTOEN flag in request_irq()", " - soc: qcom: geni-se: fix array underflow in geni_se_clk_tbl_get()", " - arm64: dts: qcom: sm6350: Fix GPU frequencies missing on some speedbins", " - arm64: dts: qcom: sda660-ifc6560: fix l10a voltage ranges", " - ARM: dts: microchip: sam9x60: Add missing property atmel,usart-mode", " - mmc: mmc_spi: drop buggy snprintf()", " - scripts/kernel-doc: Do not track section counter across processed files", " - arm64: dts: qcom: x1e80100-slim7x: Drop orientation-switch from USB SS[0-1]", " QMP PHYs", " - arm64: dts: qcom: x1e80100-vivobook-s15: Drop orientation-switch from USB", " SS[0-1] QMP PHYs", " - openrisc: Implement fixmap to fix earlycon", " - efi/libstub: fix efi_parse_options() ignoring the default command line", " - tpm: fix signed/unsigned bug when checking event logs", " - media: i2c: vgxy61: Fix an error handling path in vgxy61_detect()", " - media: i2c: ds90ub960: Fix missing return check on ub960_rxport_read call", " - arm64: dts: mt8183: krane: Fix the address of eeprom at i2c4", " - arm64: dts: mt8183: kukui: Fix the address of eeprom at i2c4", " - arm64: dts: qcom: x1e80100: Resize GIC Redistributor register region", " - kernel-doc: allow object-like macros in ReST output", " - arm64: dts: ti: k3-am62x-phyboard-lyra: Drop unnecessary McASP AFIFOs", " - arm64: dts: mediatek: mt8173-elm-hana: Add vdd-supply to second source", " trackpad", " - arm64: dts: mediatek: mt8188: Fix USB3 PHY port default status", " - arm64: dts: mediatek: mt8195-cherry: Use correct audio codec DAI", " - Revert \"cgroup: Fix memory leak caused by missing cgroup_bpf_offline\"", " - cgroup/bpf: only cgroup v2 can be attached by bpf programs", " - regulator: rk808: Restrict DVS GPIOs to the RK808 variant only", " - power: sequencing: make the QCom PMU pwrseq driver depend on CONFIG_OF", " - [Config] updateconfigs for POWER_SEQUENCING_QCOM_WCN", " - arm64: dts: rockchip: Remove 'enable-active-low' from two boards", " - arm64: dts: mt8183: fennel: add i2c2's i2c-scl-internal-delay-ns", " - arm64: dts: mt8183: burnet: add i2c2's i2c-scl-internal-delay-ns", " - arm64: dts: mt8183: cozmo: add i2c2's i2c-scl-internal-delay-ns", " - arm64: dts: mt8183: Damu: add i2c2's i2c-scl-internal-delay-ns", " - pwm: imx27: Workaround of the pwm output bug when decrease the duty cycle", " - ARM: dts: cubieboard4: Fix DCDC5 regulator constraints", " - arm64: dts: ti: k3-j7200: Fix register map for main domain pmx", " - arm64: dts: ti: k3-j7200: Fix clock ids for MCSPI instances", " - arm64: dts: ti: k3-j721e: Fix clock IDs for MCSPI instances", " - arm64: dts: ti: k3-j721s2: Fix clock IDs for MCSPI instances", " - watchdog: Add HAS_IOPORT dependency for SBC8360 and SBC7240", " - arm64: dts: qcom: x1e80100: Update C4/C5 residency/exit numbers", " - dt-bindings: cache: qcom,llcc: Fix X1E80100 reg entries", " - of/fdt: add dt_phys arg to early_init_dt_scan and early_init_dt_verify", " - pmdomain: ti-sci: Add missing of_node_put() for args.np", " - spi: tegra210-quad: Avoid shift-out-of-bounds", " - spi: zynqmp-gqspi: Undo runtime PM changes at driver exit time​", " - regmap: irq: Set lockdep class for hierarchical IRQ domains", " - arm64: dts: renesas: hihope: Drop #sound-dai-cells", " - arm64: dts: imx8mn-tqma8mqnl-mba8mx-usbot: fix coexistence of output-low and", " output-high in GPIO", " - arm64: dts: mediatek: Add ADC node on MT6357, MT6358, MT6359 PMICs", " - arm64: dts: mediatek: mt6358: fix dtbs_check error", " - arm64: dts: mediatek: mt8183-kukui-jacuzzi: Fix DP bridge supply names", " - arm64: dts: mediatek: mt8183-kukui-jacuzzi: Add supplies for fixed", " regulators", " - selftests/resctrl: Print accurate buffer size as part of MBM results", " - selftests/resctrl: Fix memory overflow due to unhandled wraparound", " - selftests/resctrl: Protect against array overrun during iMC config parsing", " - firmware: arm_scpi: Check the DVFS OPP count returned by the firmware", " - media: ipu6: Fix DMA and physical address debugging messages for 32-bit", " - media: ipu6: not override the dma_ops of device in driver", " - pwm: Assume a disabled PWM to emit a constant inactive output", " - media: atomisp: Add check for rgby_data memory allocation failure", " - arm64: dts: rockchip: correct analog audio name on Indiedroid Nova", " - HID: hyperv: streamline driver probe to avoid devres issues", " - platform/x86: panasonic-laptop: Return errno correctly in show callback", " - drm/imagination: Convert to use time_before macro", " - drm/imagination: Use pvr_vm_context_get()", " - drm/mm: Mark drm_mm_interval_tree*() functions with __maybe_unused", " - drm/vc4: hvs: Don't write gamma luts on 2711", " - drm/vc4: hdmi: Avoid hang with debug registers when suspended", " - drm/vc4: hvs: Fix dlist debug not resetting the next entry pointer", " - drm/vc4: hvs: Remove incorrect limit from hvs_dlist debugfs function", " - drm/vc4: hvs: Correct logic on stopping an HVS channel", " - wifi: ath9k: add range check for conn_rsp_epid in htc_connect_service()", " - drm/omap: Fix possible NULL dereference", " - drm/omap: Fix locking in omap_gem_new_dmabuf()", " - drm/v3d: Appease lockdep while updating GPU stats", " - wifi: p54: Use IRQF_NO_AUTOEN flag in request_irq()", " - wifi: mwifiex: Use IRQF_NO_AUTOEN flag in request_irq()", " - udmabuf: change folios array from kmalloc to kvmalloc", " - udmabuf: fix vmap_udmabuf error page set", " - [Config] updateconfigs for VMAP_PFN", " - drm/imx/dcss: Use IRQF_NO_AUTOEN flag in request_irq()", " - drm/imx/ipuv3: Use IRQF_NO_AUTOEN flag in request_irq()", " - drm/panel: nt35510: Make new commands optional", " - drm/v3d: Address race-condition in MMU flush", " - drm/v3d: Flush the MMU before we supply more memory to the binner", " - drm/amdgpu: Fix JPEG v4.0.3 register write", " - wifi: ath10k: fix invalid VHT parameters in supported_vht_mcs_rate_nss1", " - wifi: ath10k: fix invalid VHT parameters in supported_vht_mcs_rate_nss2", " - wifi: ath12k: Skip Rx TID cleanup for self peer", " - dt-bindings: vendor-prefixes: Add NeoFidelity, Inc", " - ASoC: fsl_micfil: fix regmap_write_bits usage", " - ASoC: dt-bindings: mt6359: Update generic node name and dmic-mode", " - ASoC: fsl-asoc-card: Add missing handling of {hp,mic}-dt-gpios", " - drm/bridge: anx7625: Drop EDID cache on bridge power off", " - drm/bridge: it6505: Drop EDID cache on bridge power off", " - libbpf: Fix expected_attach_type set handling in program load callback", " - libbpf: Fix output .symtab byte-order during linking", " - dlm: fix swapped args sb_flags vs sb_status", " - wifi: rtl8xxxu: Perform update_beacon_work when beaconing is enabled", " - drm/amd/display: fix a memleak issue when driver is removed", " - wifi: ath12k: fix use-after-free in ath12k_dp_cc_cleanup()", " - wifi: ath12k: fix one more memcpy size error", " - bpf: Fix the xdp_adjust_tail sample prog issue", " - selftests/bpf: netns_new() and netns_free() helpers.", " - selftests/bpf: Fix backtrace printing for selftests crashes", " - wifi: ath11k: Fix CE offset address calculation for WCN6750 in SSR", " - selftests/bpf: add missing header include for htons", " - wifi: cfg80211: check radio iface combination for multi radio per wiphy", " - ice: consistently use q_idx in ice_vc_cfg_qs_msg()", " - drm/vc4: hdmi: Increase audio MAI fifo dreq threshold", " - drm/vc4: Introduce generation number enum", " - drm/vc4: Match drm_dev_enter and exit calls in vc4_hvs_lut_load", " - drm/vc4: Match drm_dev_enter and exit calls in vc4_hvs_atomic_flush", " - drm/vc4: Correct generation check in vc4_hvs_lut_load", " - libbpf: fix sym_is_subprog() logic for weak global subprogs", " - accel/ivpu: Prevent recovery invocation during probe and resume", " - ASoC: rt722-sdca: Remove logically deadcode in rt722-sdca.c", " - libbpf: never interpret subprogs in .text as entry programs", " - netdevsim: copy addresses for both in and out paths", " - drm/bridge: tc358767: Fix link properties discovery", " - selftests/bpf: Fix msg_verify_data in test_sockmap", " - selftests/bpf: Fix txmsg_redir of test_txmsg_pull in test_sockmap", " - wifi: wilc1000: Set MAC after operation mode", " - wifi: mwifiex: Fix memcpy() field-spanning write warning in", " mwifiex_config_scan()", " - drm: fsl-dcu: enable PIXCLK on LS1021A", " - drm: panel: nv3052c: correct spi_device_id for RG35XX panel", " - drm/msm/dpu: on SDM845 move DSPP_3 to LM_5 block", " - drm/msm/dpu: drop LM_3 / LM_4 on SDM845", " - drm/msm/dpu: drop LM_3 / LM_4 on MSM8998", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_common.c", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_ethtool.c", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_flows.c", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in cn10k.c", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dmac_flt.c", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dcbnl.c", " - selftests/bpf: fix test_spin_lock_fail.c's global vars usage", " - libbpf: move global data mmap()'ing into bpf_object__load()", " - drm/panfrost: Remove unused id_mask from struct panfrost_model", " - bpf, arm64: Remove garbage frame for struct_ops trampoline", " - drm/msm/adreno: Use IRQF_NO_AUTOEN flag in request_irq()", " - drm/msm/gpu: Check the status of registration to PM QoS", " - drm/xe/hdcp: Fix gsc structure check in fw check status", " - drm/etnaviv: Request pages from DMA32 zone on addressing_limited", " - drm/etnaviv: hold GPU lock across perfmon sampling", " - drm/amd/display: Increase idle worker HPD detection time", " - drm/amd/display: Reduce HPD Detection Interval for IPS", " - drm/nouveau/gr/gf100: Fix missing unlock in gf100_gr_chan_new()", " - drm: zynqmp_kms: Unplug DRM device before removal", " - drm: xlnx: zynqmp_disp: layer may be null while releasing", " - wifi: wfx: Fix error handling in wfx_core_init()", " - wifi: cw1200: Fix potential NULL dereference", " - drm/msm/dpu: cast crtc_clk calculation to u64 in _dpu_core_perf_calc_clk()", " - bpf, bpftool: Fix incorrect disasm pc", " - bpf: Tighten tail call checks for lingering locks, RCU, preempt_disable", " - drm/vkms: Drop unnecessary call to drm_crtc_cleanup()", " - drm/amdgpu: Fix the memory allocation issue in", " amdgpu_discovery_get_nps_info()", " - bpf: Support __nullable argument suffix for tp_btf", " - selftests/bpf: Add test for __nullable suffix in tp_btf", " - bpf: Mark raw_tp arguments with PTR_MAYBE_NULL", " - drm: use ATOMIC64_INIT() for atomic64_t", " - netfilter: nf_tables: avoid false-positive lockdep splat on rule deletion", " - netfilter: nf_tables: must hold rcu read lock while iterating expression", " type list", " - netfilter: nf_tables: must hold rcu read lock while iterating object type", " list", " - netlink: typographical error in nlmsg_type constants definition", " - wifi: rtw89: coex: check NULL return of kmalloc in btc_fw_set_monreg()", " - drm/panfrost: Add missing OPP table refcnt decremental", " - drm/panthor: introduce job cycle and timestamp accounting", " - drm/panthor: record current and maximum device clock frequencies", " - drm/panthor: Fix OPP refcnt leaks in devfreq initialisation", " - isofs: avoid memory leak in iocharset", " - selftests/bpf: Add txmsg_pass to pull/push/pop in test_sockmap", " - selftests/bpf: Fix SENDPAGE data logic in test_sockmap", " - selftests/bpf: Fix total_bytes in msg_loop_rx in test_sockmap", " - selftests/bpf: Add push/pop checking for msg_verify_data in test_sockmap", " - bpf, sockmap: Several fixes to bpf_msg_push_data", " - bpf, sockmap: Several fixes to bpf_msg_pop_data", " - bpf, sockmap: Fix sk_msg_reset_curr", " - ipv6: release nexthop on device removal", " - selftests: net: really check for bg process completion", " - wifi: cfg80211: Remove the Medium Synchronization Delay validity check", " - wifi: iwlwifi: allow fast resume on ax200", " - wifi: iwlwifi: mvm: tell iwlmei when we finished suspending", " - drm/amdgpu: fix ACA bank count boundary check error", " - drm/amdgpu: Fix map/unmap queue logic", " - drm/amdkfd: Fix wrong usage of INIT_WORK()", " - bpf: Allow return values 0 and 1 for kprobe session", " - bpf: Force uprobe bpf program to always return 0", " - selftests/bpf: skip the timer_lockup test for single-CPU nodes", " - ipv6: Fix soft lockups in fib6_select_path under high next hop churn", " - net: rfkill: gpio: Add check for clk_enable()", " - Revert \"wifi: iwlegacy: do not skip frames with bad FCS\"", " - bpf: Use function pointers count as struct_ops links count", " - bpf: Add kernel symbol for struct_ops trampoline", " - ALSA: usx2y: Use snd_card_free_when_closed() at disconnection", " - ALSA: us122l: Use snd_card_free_when_closed() at disconnection", " - ALSA: caiaq: Use snd_card_free_when_closed() at disconnection", " - ALSA: 6fire: Release resources at card release", " - i2c: dev: Fix memory leak when underlying adapter does not support I2C", " - selftests: netfilter: Fix missing return values in conntrack_dump_flush", " - Bluetooth: btintel_pcie: Add handshake between driver and firmware", " - Bluetooth: btintel: Do no pass vendor events to stack", " - Bluetooth: btmtk: adjust the position to init iso data anchor", " - Bluetooth: btbcm: fix missing of_node_put() in btbcm_get_board_name()", " - Bluetooth: ISO: Use kref to track lifetime of iso_conn", " - Bluetooth: ISO: Do not emit LE PA Create Sync if previous is pending", " - Bluetooth: ISO: Do not emit LE BIG Create Sync if previous is pending", " - Bluetooth: ISO: Send BIG Create Sync via hci_sync", " - Bluetooth: fix use-after-free in device_for_each_child()", " - xsk: Free skb when TX metadata options are invalid", " - erofs: handle NONHEAD !delta[1] lclusters gracefully", " - dlm: fix dlm_recover_members refcount on error", " - eth: fbnic: don't disable the PCI device twice", " - net: txgbe: remove GPIO interrupt controller", " - net: txgbe: fix null pointer to pcs", " - netpoll: Use rcu_access_pointer() in netpoll_poll_lock", " - wireguard: selftests: load nf_conntrack if not present", " - bpf: fix recursive lock when verdict program return SK_PASS", " - unicode: Fix utf8_load() error path", " - cppc_cpufreq: Use desired perf if feedback ctrs are 0 or unchanged", " - RDMA/core: Provide rdma_user_mmap_disassociate() to disassociate mmap pages", " - RDMA/hns: Disassociate mmap pages for all uctx when HW is being reset", " - clk: mediatek: drop two dead config options", " - [Config] drop COMMON_CLK_MT8195_{AUDSYS,MSDC}", " - trace/trace_event_perf: remove duplicate samples on the first tracepoint", " event", " - pinctrl: zynqmp: drop excess struct member description", " - pinctrl: renesas: Select PINCTRL_RZG2L for RZ/V2H(P) SoC", " - clk: qcom: videocc-sm8550: depend on either gcc-sm8550 or gcc-sm8650", " - iommu/s390: Implement blocking domain", " - scsi: hisi_sas: Enable all PHYs that are not disabled by user during", " controller reset", " - powerpc/vdso: Flag VDSO64 entry points as functions", " - mfd: tps65010: Use IRQF_NO_AUTOEN flag in request_irq() to fix race", " - mfd: da9052-spi: Change read-mask to write-mask", " - mfd: intel_soc_pmic_bxtwc: Use IRQ domain for USB Type-C device", " - mfd: intel_soc_pmic_bxtwc: Use IRQ domain for TMU device", " - mfd: intel_soc_pmic_bxtwc: Use IRQ domain for PMIC devices", " - irqdomain: Simplify simple and legacy domain creation", " - irqdomain: Cleanup domain name allocation", " - irqdomain: Allow giving name suffix for domain", " - regmap: Allow setting IRQ domain name suffix", " - mfd: intel_soc_pmic_bxtwc: Fix IRQ domain names duplication", " - cpufreq: loongson2: Unregister platform_driver on failure", " - powerpc/fadump: Refactor and prepare fadump_cma_init for late init", " - powerpc/fadump: Move fadump_cma_init to setup_arch() after initmem_init()", " - mtd: hyperbus: rpc-if: Add missing MODULE_DEVICE_TABLE", " - mtd: rawnand: atmel: Fix possible memory leak", " - powerpc/mm/fault: Fix kfence page fault reporting", " - clk: sophgo: avoid integer overflow in sg2042_pll_recalc_rate()", " - mtd: spi-nor: spansion: Use nor->addr_nbytes in octal DTR mode in", " RD_ANY_REG_OP", " - powerpc/pseries: Fix dtl_access_lock to be a rw_semaphore", " - cpufreq: CPPC: Fix possible null-ptr-deref for cpufreq_cpu_get_raw()", " - cpufreq: CPPC: Fix possible null-ptr-deref for cppc_get_cpu_cost()", " - iommu/amd: Remove amd_iommu_domain_update() from page table freeing", " - iommu/amd: Remove the amd_iommu_domain_set_pt_root() and related", " - iommu/amd: Rename struct amd_io_pgtable iopt to pgtbl", " - iommu/amd: Store the nid in io_pgtable_cfg instead of the domain", " - iommu/amd: Narrow the use of struct protection_domain to invalidation", " - iommu/amd/pgtbl_v2: Take protection domain lock before invalidating TLB", " - RDMA/hns: Fix an AEQE overflow error caused by untimely update of eq_db_ci", " - RDMA/hns: Fix flush cqe error when racing with destroy qp", " - RDMA/hns: Modify debugfs name", " - RDMA/hns: Use dev_* printings in hem code instead of ibdev_*", " - RDMA/hns: Fix cpu stuck caused by printings during reset", " - RDMA/rxe: Fix the qp flush warnings in req", " - RDMA/bnxt_re: Check cqe flags to know imm_data vs inv_irkey", " - clk: sunxi-ng: d1: Fix PLL_AUDIO0 preset", " - clk: renesas: rzg2l: Fix FOUTPOSTDIV clk", " - RDMA/rxe: Set queue pair cur_qp_state when being queried", " - RISC-V: KVM: Fix APLIC in_clrip and clripnum write emulation", " - riscv: kvm: Fix out-of-bounds array access", " - clk: imx: lpcg-scu: SW workaround for errata (e10858)", " - clk: imx: fracn-gppll: correct PLL initialization flow", " - clk: imx: fracn-gppll: fix pll power up", " - clk: imx: clk-scu: fix clk enable state save and restore", " - clk: imx: imx8-acm: Fix return value check in", " clk_imx_acm_attach_pm_domains()", " - iommu/vt-d: Fix checks and print in dmar_fault_dump_ptes()", " - iommu/vt-d: Fix checks and print in pgtable_walk()", " - checkpatch: always parse orig_commit in fixes tag", " - mfd: rt5033: Fix missing regmap_del_irq_chip()", " - leds: max5970: Fix unreleased fwnode_handle in probe function", " - leds: ktd2692: Set missing timing properties", " - fs/proc/kcore.c: fix coccinelle reported ERROR instances", " - scsi: target: Fix incorrect function name in pscsi_create_type_disk()", " - scsi: bfa: Fix use-after-free in bfad_im_module_exit()", " - scsi: fusion: Remove unused variable 'rc'", " - scsi: qedf: Fix a possible memory leak in qedf_alloc_and_init_sb()", " - scsi: qedi: Fix a possible memory leak in qedi_alloc_and_init_sb()", " - scsi: sg: Enable runtime power management", " - x86/tdx: Introduce wrappers to read and write TD metadata", " - x86/tdx: Rename tdx_parse_tdinfo() to tdx_setup()", " - x86/tdx: Dynamically disable SEPT violations from causing #VEs", " - powerpc/fadump: allocate memory for additional parameters early", " - fadump: reserve param area if below boot_mem_top", " - RDMA/hns: Fix out-of-order issue of requester when setting FENCE", " - RDMA/hns: Fix NULL pointer derefernce in hns_roce_map_mr_sg()", " - cpufreq: loongson3: Check for error code from devm_mutex_init() call", " - cpufreq: CPPC: Fix wrong return value in cppc_get_cpu_cost()", " - cpufreq: CPPC: Fix wrong return value in cppc_get_cpu_power()", " - kasan: move checks to do_strncpy_from_user", " - kunit: skb: use \"gfp\" variable instead of hardcoding GFP_KERNEL", " - ocfs2: fix uninitialized value in ocfs2_file_read_iter()", " - dax: delete a stale directory pmem", " - KVM: PPC: Book3S HV: Stop using vc->dpdes for nested KVM guests", " - KVM: PPC: Book3S HV: Avoid returning to nested hypervisor on pending", " doorbells", " - powerpc/sstep: make emulate_vsx_load and emulate_vsx_store static", " - RDMA/hns: Fix different dgids mapping to the same dip_idx", " - KVM: PPC: Book3S HV: Fix kmv -> kvm typo", " - powerpc/kexec: Fix return of uninitialized variable", " - fbdev: sh7760fb: Fix a possible memory leak in sh7760fb_alloc_mem()", " - RDMA/mlx5: Move events notifier registration to be after device registration", " - clk: clk-apple-nco: Add NULL check in applnco_probe", " - clk: ralink: mtmips: fix clock plan for Ralink SoC RT3883", " - clk: ralink: mtmips: fix clocks probe order in oldest ralink SoCs", " - clk: en7523: remove REG_PCIE*_{MEM,MEM_MASK} configuration", " - clk: en7523: move clock_register in hw_init callback", " - clk: en7523: introduce chip_scu regmap", " - clk: en7523: fix estimation of fixed rate for EN7581", " - dt-bindings: clock: axi-clkgen: include AXI clk", " - clk: clk-axi-clkgen: make sure to enable the AXI bus clock", " - arm64: dts: qcom: sc8180x: Add a SoC-specific compatible to cpufreq-hw", " - pinctrl: k210: Undef K210_PC_DEFAULT", " - rtla/timerlat: Do not set params->user_workload with -U", " - smb: cached directories can be more than root file handle", " - mailbox: mtk-cmdq: fix wrong use of sizeof in cmdq_get_clocks()", " - mailbox: arm_mhuv2: clean up loop in get_irq_chan_comb()", " - x86: fix off-by-one in access_ok()", " - perf cs-etm: Don't flush when packet_queue fills up", " - gfs2: Rename GLF_VERIFY_EVICT to GLF_VERIFY_DELETE", " - gfs2: Allow immediate GLF_VERIFY_DELETE work", " - gfs2: Fix unlinked inode cleanup", " - perf test: Add test for Intel TPEBS counting mode", " - perf mem: Fix printing PERF_MEM_LVLNUM_{L2_MHB|MSC}", " - PCI: Fix reset_method_store() memory leak", " - perf stat: Close cork_fd when create_perf_stat_counter() failed", " - perf stat: Fix affinity memory leaks on error path", " - perf trace: Keep exited threads for summary", " - perf test attr: Add back missing topdown events", " - f2fs: compress: fix inconsistent update of i_blocks in", " release_compress_blocks and reserve_compress_blocks", " - f2fs: fix null-ptr-deref in f2fs_submit_page_bio()", " - f2fs: fix to account dirty data in __get_secs_required()", " - perf dso: Fix symtab_type for kmod compression", " - perf probe: Fix libdw memory leak", " - perf probe: Correct demangled symbols in C++ program", " - rust: kernel: fix THIS_MODULE header path in ThisModule doc comment", " - rust: macros: fix documentation of the paste! macro", " - PCI: cpqphp: Use PCI_POSSIBLE_ERROR() to check config reads", " - PCI: cpqphp: Fix PCIBIOS_* return value confusion", " - rust: block: fix formatting of `kernel::block::mq::request` module", " - perf disasm: Use disasm_line__free() to properly free disasm_line", " - virtiofs: use pages instead of pointer for kernel direct IO", " - perf ftrace latency: Fix unit on histogram first entry when using --use-nsec", " - i3c: master: Remove i3c_dev_disable_ibi_locked(olddev) on device hotjoin", " - f2fs: fix the wrong f2fs_bug_on condition in f2fs_do_replace_block", " - f2fs: check curseg->inited before write_sum_page in change_curseg", " - f2fs: Fix not used variable 'index'", " - f2fs: fix to avoid potential deadlock in f2fs_record_stop_reason()", " - f2fs: fix to avoid use GC_AT when setting gc_mode as GC_URGENT_LOW or", " GC_URGENT_MID", " - PCI: qcom-ep: Move controller cleanups to qcom_pcie_perst_deassert()", " - PCI: tegra194: Move controller cleanups to pex_ep_event_pex_rst_deassert()", " - PCI: cadence: Extract link setup sequence from cdns_pcie_host_setup()", " - PCI: cadence: Set cdns_pcie_host_init() global", " - PCI: j721e: Add reset GPIO to struct j721e_pcie", " - PCI: j721e: Use T_PERST_CLK_US macro", " - PCI: j721e: Add suspend and resume support", " - PCI: j721e: Deassert PERST# after a delay of PCIE_T_PVPERL_MS milliseconds", " - perf build: Add missing cflags when building with custom libtraceevent", " - f2fs: fix race in concurrent f2fs_stop_gc_thread", " - f2fs: fix to map blocks correctly for direct write", " - f2fs: fix to avoid forcing direct write to use buffered IO on inline_data", " inode", " - perf trace: avoid garbage when not printing a trace event's arguments", " - m68k: mcfgpio: Fix incorrect register offset for CONFIG_M5441x", " - m68k: coldfire/device.c: only build FEC when HW macros are defined", " - svcrdma: Address an integer overflow", " - nfsd: drop inode parameter from nfsd4_change_attribute()", " - perf list: Fix topic and pmu_name argument order", " - perf trace: Fix tracing itself, creating feedback loops", " - perf trace: Do not lose last events in a race", " - perf trace: Avoid garbage when not printing a syscall's arguments", " - remoteproc: qcom: pas: Remove subdevs on the error path of adsp_probe()", " - remoteproc: qcom: adsp: Remove subdevs on the error path of adsp_probe()", " - remoteproc: qcom: pas: add minidump_id to SM8350 resources", " - rpmsg: glink: use only lower 16-bits of param2 for CMD_OPEN name length", " - remoteproc: qcom_q6v5_mss: Re-order writes to the IMEM region", " - PCI: endpoint: epf-mhi: Avoid NULL dereference if DT lacks 'mmio'", " - NFSD: Prevent NULL dereference in nfsd4_process_cb_update()", " - NFSD: Cap the number of bytes copied by nfs4_reset_recoverydir()", " - nfsd: release svc_expkey/svc_export with rcu_work", " - svcrdma: fix miss destroy percpu_counter in svc_rdma_proc_init()", " - NFSD: Fix nfsd4_shutdown_copy()", " - f2fs: clean up val{>>,<<}F2FS_BLKSIZE_BITS", " - f2fs: fix to do cast in F2FS_{BLK_TO_BYTES, BTYES_TO_BLK} to avoid overflow", " - hwmon: (tps23861) Fix reporting of negative temperatures", " - hwmon: (aquacomputer_d5next) Fix length of speed_input array", " - phy: airoha: Fix REG_CSR_2L_PLL_CMN_RESERVE0 config in", " airoha_pcie_phy_init_clk_out()", " - phy: airoha: Fix REG_PCIE_PMA_TX_RESET config in", " airoha_pcie_phy_init_csr_2l()", " - phy: airoha: Fix REG_CSR_2L_JCPLL_SDM_HREN config in", " airoha_pcie_phy_init_ssc_jcpll()", " - phy: airoha: Fix REG_CSR_2L_RX{0,1}_REV0 definitions", " - vdpa/mlx5: Fix suboptimal range on iotlb iteration", " - vfio/mlx5: Fix an unwind issue in mlx5vf_add_migration_pages()", " - vfio/mlx5: Fix unwind flows in mlx5vf_pci_save/resume_device_data()", " - selftests/mount_setattr: Fix failures on 64K PAGE_SIZE kernels", " - gpio: zevio: Add missed label initialisation", " - vfio/pci: Properly hide first-in-list PCIe extended capability", " - fs_parser: update mount_api doc to match function signature", " - LoongArch: Fix build failure with GCC 15 (-std=gnu23)", " - LoongArch: BPF: Sign-extend return values", " - power: supply: core: Remove might_sleep() from power_supply_put()", " - power: supply: bq27xxx: Fix registers of bq27426", " - power: supply: rt9471: Fix wrong WDT function regfield declaration", " - power: supply: rt9471: Use IC status regfield to report real charger status", " - net: usb: lan78xx: Fix double free issue with interrupt buffer allocation", " - net: usb: lan78xx: Fix memory leak on device unplug by freeing PHY device", " - tg3: Set coherent DMA mask bits to 31 for BCM57766 chipsets", " - net: usb: lan78xx: Fix refcounting and autosuspend on invalid WoL", " configuration", " - net: microchip: vcap: Add typegroup table terminators in kunit tests", " - netlink: fix false positive warning in extack during dumps", " - exfat: fix file being changed by unaligned direct write", " - s390/iucv: MSG_PEEK causes memory leak in iucv_sock_destruct()", " - net/ipv6: delete temporary address if mngtmpaddr is removed or unmanaged", " - net: mdio-ipq4019: add missing error check", " - marvell: pxa168_eth: fix call balance of pep->clk handling routines", " - net: stmmac: dwmac-socfpga: Set RX watchdog interrupt as broken", " - octeontx2-af: RPM: Fix mismatch in lmac type", " - octeontx2-af: RPM: Fix low network performance", " - octeontx2-af: RPM: fix stale RSFEC counters", " - octeontx2-af: RPM: fix stale FCFEC counters", " - octeontx2-af: Quiesce traffic before NIX block reset", " - spi: atmel-quadspi: Fix register name in verbose logging function", " - net: hsr: fix hsr_init_sk() vs network/transport headers.", " - bnxt_en: Reserve rings after PCIe AER recovery if NIC interface is down", " - bnxt_en: Set backplane link modes correctly for ethtool", " - bnxt_en: Fix receive ring space parameters when XDP is active", " - bnxt_en: Refactor bnxt_ptp_init()", " - bnxt_en: Unregister PTP during PCI shutdown and suspend", " - Bluetooth: MGMT: Fix slab-use-after-free Read in set_powered_sync", " - Bluetooth: MGMT: Fix possible deadlocks", " - llc: Improve setsockopt() handling of malformed user input", " - rxrpc: Improve setsockopt() handling of malformed user input", " - tcp: Fix use-after-free of nreq in reqsk_timer_handler().", " - ip6mr: fix tables suspicious RCU usage", " - ipmr: fix tables suspicious RCU usage", " - iio: light: al3010: Fix an error handling path in al3010_probe()", " - usb: using mutex lock and supporting O_NONBLOCK flag in iowarrior_read()", " - usb: yurex: make waiting on yurex_write interruptible", " - USB: chaoskey: fail open after removal", " - USB: chaoskey: Fix possible deadlock chaoskey_list_lock", " - misc: apds990x: Fix missing pm_runtime_disable()", " - devres: Fix page faults when tracing devres from unloaded modules", " - usb: gadget: uvc: wake pump everytime we update the free list", " - interconnect: qcom: icc-rpmh: probe defer incase of missing QoS clock", " dependency", " - phy: realtek: usb: fix NULL deref in rtk_usb2phy_probe", " - phy: realtek: usb: fix NULL deref in rtk_usb3phy_probe", " - counter: stm32-timer-cnt: Add check for clk_enable()", " - counter: ti-ecap-capture: Add check for clk_enable()", " - bus: mhi: host: Switch trace_mhi_gen_tre fields to native endian", " - usb: typec: fix potential array underflow in ucsi_ccg_sync_control()", " - firmware_loader: Fix possible resource leak in fw_log_firmware_info()", " - ALSA: hda/realtek: Update ALC256 depop procedure", " - drm/radeon: add helper rdev_to_drm(rdev)", " - drm/radeon: change rdev->ddev to rdev_to_drm(rdev)", " - drm/radeon: Fix spurious unplug event on radeon HDMI", " - drm/amd/display: Fix null check for pipe_ctx->plane_state in", " dcn20_program_pipe", " - drm/amd/display: Fix null check for pipe_ctx->plane_state in hwss_setup_dpp", " - ASoC: imx-audmix: Add NULL check in imx_audmix_probe", " - drm/xe/ufence: Wake up waiters after setting ufence->signalled", " - apparmor: fix 'Do simple duplicate message elimination'", " - ALSA: core: Fix possible NULL dereference caused by kunit_kzalloc()", " - ASoC: amd: yc: Fix for enabling DMIC on acp6x via _DSD entry", " - ASoC: mediatek: Check num_codecs is not zero to avoid panic during probe", " - s390/pci: Fix potential double remove of hotplug slot", " - net_sched: sch_fq: don't follow the fast path if Tx is behind now", " - xen: Fix the issue of resource not being properly released in", " xenbus_dev_probe()", " - ALSA: usb-audio: Fix potential out-of-bound accesses for Extigy and Mbox", " devices", " - ALSA: usb-audio: Fix out of bounds reads when finding clock sources", " - usb: ehci-spear: fix call balance of sehci clk handling routines", " - usb: typec: ucsi: glink: fix off-by-one in connector_status", " - dm-cache: fix warnings about duplicate slab caches", " - dm-bufio: fix warnings about duplicate slab caches", " - ASoC: Intel: sst: Fix used of uninitialized ctx to log an error", " - soc: qcom: socinfo: fix revision check in qcom_socinfo_probe()", " - irqdomain: Always associate interrupts for legacy domains", " - ext4: supress data-race warnings in ext4_free_inodes_{count,set}()", " - ext4: fix FS_IOC_GETFSMAP handling", " - jfs: xattr: check invalid xattr size more strictly", " - ASoC: amd: yc: Add a quirk for microfone on Lenovo ThinkPad P14s Gen 5", " 21MES00B00", " - ASoC: codecs: Fix atomicity violation in snd_soc_component_get_drvdata()", " - ASoC: da7213: Populate max_register to regmap_config", " - perf/x86/intel/pt: Fix buffer full but size is 0 case", " - crypto: x86/aegis128 - access 32-bit arguments as 32-bit", " - KVM: x86: switch hugepage recovery thread to vhost_task", " - KVM: x86/mmu: Skip the \"try unsync\" path iff the old SPTE was a leaf SPTE", " - powerpc/pseries: Fix KVM guest detection for disabling hardlockup detector", " - KVM: arm64: vgic-v3: Sanitise guest writes to GICR_INVLPIR", " - KVM: arm64: Ignore PMCNTENSET_EL0 while checking for overflow status", " - KVM: arm64: Don't retire aborted MMIO instruction", " - KVM: arm64: vgic-its: Clear ITE when DISCARD frees an ITE", " - KVM: arm64: Get rid of userspace_irqchip_in_use", " - KVM: arm64: vgic-its: Add a data length check in vgic_its_save_*", " - KVM: arm64: vgic-its: Clear DTE when MAPD unmaps a device", " - Compiler Attributes: disable __counted_by for clang < 19.1.3", " - PCI: Fix use-after-free of slot->bus on hot remove", " - LoongArch: Explicitly specify code model in Makefile", " - clk: clk-loongson2: Fix memory corruption bug in struct", " loongson2_clk_provider", " - clk: clk-loongson2: Fix potential buffer overflow in flexible-array member", " access", " - fsnotify: fix sending inotify event with unexpected filename", " - comedi: Flush partial mappings in error case", " - apparmor: test: Fix memory leak for aa_unpack_strdup()", " - iio: dac: adi-axi-dac: fix wrong register bitfield", " - tty: ldsic: fix tty_ldisc_autoload sysctl's proc_handler", " - locking/lockdep: Avoid creating new name string literals in", " lockdep_set_subclass()", " - tools/nolibc: s390: include std.h", " - pinctrl: qcom: spmi: fix debugfs drive strength", " - dt-bindings: pinctrl: samsung: Fix interrupt constraint for variants with", " fallbacks", " - dt-bindings: iio: dac: ad3552r: fix maximum spi speed", " - exfat: fix uninit-value in __exfat_get_dentry_set", " - exfat: fix out-of-bounds access of directory entries", " - xhci: Fix control transfer error on Etron xHCI host", " - xhci: Combine two if statements for Etron xHCI host", " - xhci: Don't perform Soft Retry for Etron xHCI host", " - xhci: Don't issue Reset Device command to Etron xHCI host", " - Bluetooth: Fix type of len in rfcomm_sock_getsockopt{,_old}()", " - usb: xhci: Limit Stop Endpoint retries", " - usb: xhci: Fix TD invalidation under pending Set TR Dequeue", " - usb: xhci: Avoid queuing redundant Stop Endpoint commands", " - ARM: dts: omap36xx: declare 1GHz OPP as turbo again", " - wifi: ath12k: fix warning when unbinding", " - wifi: rtlwifi: Drastically reduce the attempts to read efuse in case of", " failures", " - wifi: nl80211: fix bounds checker error in nl80211_parse_sched_scan", " - wifi: ath12k: fix crash when unbinding", " - wifi: brcmfmac: release 'root' node in all execution paths", " - Revert \"fs: don't block i_writecount during exec\"", " - Revert \"f2fs: remove unreachable lazytime mount option parsing\"", " - Revert \"usb: gadget: composite: fix OS descriptors w_value logic\"", " - serial: sh-sci: Clean sci_ports[0] after at earlycon exit", " - Revert \"serial: sh-sci: Clean sci_ports[0] after at earlycon exit\"", " - io_uring: fix corner case forgetting to vunmap", " - io_uring: check for overflows in io_pin_pages", " - blk-settings: round down io_opt to physical_block_size", " - gpio: exar: set value when external pull-up or pull-down is present", " - spi: Fix acpi deferred irq probe", " - mtd: spi-nor: core: replace dummy buswidth from addr to data", " - cpufreq: mediatek-hw: Fix wrong return value in mtk_cpufreq_get_cpu_power()", " - cifs: support mounting with alternate password to allow password rotation", " - parisc/ftrace: Fix function graph tracing disablement", " - RISC-V: Scalar unaligned access emulated on hotplug CPUs", " - RISC-V: Check scalar unaligned access on all CPUs", " - ksmbd: fix use-after-free in SMB request handling", " - smb: client: fix NULL ptr deref in crypto_aead_setkey()", " - platform/chrome: cros_ec_typec: fix missing fwnode reference decrement", " - irqchip/irq-mvebu-sei: Move misplaced select() callback to SEI CP domain", " - x86/CPU/AMD: Terminate the erratum_1386_microcode array", " - ubi: wl: Put source PEB into correct list if trying locking LEB failed", " - um: ubd: Do not use drvdata in release", " - um: net: Do not use drvdata in release", " - dt-bindings: serial: rs485: Fix rs485-rts-delay property", " - serial: 8250_fintek: Add support for F81216E", " - serial: 8250: omap: Move pm_runtime_get_sync", " - serial: amba-pl011: Fix RX stall when DMA is used", " - serial: amba-pl011: fix build regression", " - mtd: ubi: fix unreleased fwnode_handle in find_volume_fwnode()", " - block: Prevent potential deadlock in blk_revalidate_disk_zones()", " - um: vector: Do not use drvdata in release", " - sh: cpuinfo: Fix a warning for CONFIG_CPUMASK_OFFSTACK", " - iio: gts: Fix uninitialized symbol 'ret'", " - ublk: fix ublk_ch_mmap() for 64K page size", " - arm64: tls: Fix context-switching of tpidrro_el0 when kpti is enabled", " - block: fix missing dispatching request when queue is started or unquiesced", " - block: fix ordering between checking QUEUE_FLAG_QUIESCED request adding", " - block: fix ordering between checking BLK_MQ_S_STOPPED request adding", " - blk-mq: Make blk_mq_quiesce_tagset() hold the tag list mutex less long", " - gve: Flow steering trigger reset only for timeout error", " - HID: wacom: Interpret tilt data from Intuos Pro BT as signed values", " - i40e: Fix handling changed priv flags", " - media: wl128x: Fix atomicity violation in fmc_send_cmd()", " - media: intel/ipu6: do not handle interrupts when device is disabled", " - arm64: dts: mediatek: mt8186-corsola-voltorb: Merge speaker codec nodes", " - netdev-genl: Hold rcu_read_lock in napi_get", " - soc: fsl: rcpm: fix missing of_node_put() in copy_ippdexpcr1_setting()", " - media: v4l2-core: v4l2-dv-timings: check cvt/gtf result", " - ALSA: rawmidi: Fix kvfree() call in spinlock", " - ALSA: ump: Fix evaluation of MIDI 1.0 FB info", " - ALSA: pcm: Add sanity NULL check for the default mmap fault handler", " - ALSA: hda/realtek: Update ALC225 depop procedure", " - ALSA: hda/realtek: Set PCBeep to default value for ALC274", " - ALSA: hda/realtek: Fix Internal Speaker and Mic boost of Infinix Y4 Max", " - ALSA: hda/realtek: Apply quirk for Medion E15433", " - smb3: request handle caching when caching directories", " - smb: client: handle max length for SMB symlinks", " - smb: Don't leak cfid when reconnect races with open_cached_dir", " - smb: prevent use-after-free due to open_cached_dir error paths", " - smb: During unmount, ensure all cached dir instances drop their dentry", " - usb: misc: ljca: set small runtime autosuspend delay", " - usb: misc: ljca: move usb_autopm_put_interface() after wait for response", " - usb: dwc3: ep0: Don't clear ep0 DWC3_EP_TRANSFER_STARTED", " - usb: musb: Fix hardware lockup on first Rx endpoint request", " - usb: dwc3: gadget: Fix checking for number of TRBs left", " - usb: dwc3: gadget: Fix looping of queued SG entries", " - staging: vchiq_arm: Fix missing refcount decrement in error path for fw_node", " - counter: stm32-timer-cnt: fix device_node handling in probe_encoder()", " - ublk: fix error code for unsupported command", " - lib: string_helpers: silence snprintf() output truncation warning", " - f2fs: fix to do sanity check on node blkaddr in truncate_node()", " - ipc: fix memleak if msg_init_ns failed in create_ipc_ns", " - Input: cs40l50 - fix wrong usage of INIT_WORK()", " - NFSD: Prevent a potential integer overflow", " - SUNRPC: make sure cache entry active before cache_show", " - um: Fix potential integer overflow during physmem setup", " - um: Fix the return value of elf_core_copy_task_fpregs", " - kfifo: don't include dma-mapping.h in kfifo.h", " - um: ubd: Initialize ubd's disk pointer in ubd_add", " - um: Always dump trace for specified task in show_stack", " - NFSv4.0: Fix a use-after-free problem in the asynchronous open()", " - rtc: st-lpc: Use IRQF_NO_AUTOEN flag in request_irq()", " - rtc: abx80x: Fix WDT bit position of the status register", " - rtc: check if __rtc_read_time was successful in rtc_timer_do_work()", " - ubi: fastmap: wl: Schedule fm_work if wear-leveling pool is empty", " - ubifs: Correct the total block count by deducting journal reservation", " - ubi: fastmap: Fix duplicate slab cache names while attaching", " - ubifs: authentication: Fix use-after-free in ubifs_tnc_end_commit", " - jffs2: fix use of uninitialized variable", " - rtc: rzn1: fix BCD to rtc_time conversion errors", " - Revert \"nfs: don't reuse partially completed requests in", " nfs_lock_and_join_requests\"", " - nvme-multipath: avoid hang on inaccessible namespaces", " - nvme/multipath: Fix RCU list traversal to use SRCU primitive", " - blk-mq: add non_owner variant of start_freeze/unfreeze queue APIs", " - block: model freeze & enter queue as lock for supporting lockdep", " - block: fix uaf for flush rq while iterating tags", " - block: return unsigned int from bdev_io_min", " - nvme-fabrics: fix kernel crash while shutting down controller", " - 9p/xen: fix init sequence", " - 9p/xen: fix release of IRQ", " - perf/arm-smmuv3: Fix lockdep assert in ->event_init()", " - perf/arm-cmn: Ensure port and device id bits are set properly", " - smb: client: disable directory caching when dir_cache_timeout is zero", " - x86/Documentation: Update algo in init_size description of boot protocol", " - cifs: Fix parsing native symlinks relative to the export", " - cifs: Fix parsing reparse point with native symlink in SMB1 non-UNICODE", " session", " - rtc: ab-eoz9: don't fail temperature reads on undervoltage notification", " - Rename .data.unlikely to .data..unlikely", " - Rename .data.once to .data..once to fix resetting WARN*_ONCE", " - kbuild: deb-pkg: Don't fail if modules.order is missing", " - smb: Initialize cfid->tcon before performing network ops", " - block: Don't allow an atomic write be truncated in blkdev_write_iter()", " - modpost: remove incorrect code in do_eisa_entry()", " - cifs: during remount, make sure passwords are in sync", " - cifs: unlock on error in smb3_reconfigure()", " - nfs: ignore SB_RDONLY when mounting nfs", " - sunrpc: clear XPRT_SOCK_UPD_TIMEOUT when reset transport", " - SUNRPC: timeout and cancel TLS handshake with -ETIMEDOUT", " - sunrpc: fix one UAF issue caused by sunrpc kernel tcp socket", " - nfs/blocklayout: Don't attempt unregister for invalid block device", " - nfs/blocklayout: Limit repeat device registration on failure", " - block, bfq: fix bfqq uaf in bfq_limit_depth()", " - brd: decrease the number of allocated pages which discarded", " - sh: intc: Fix use-after-free bug in register_intc_controller()", " - tools/power turbostat: Fix trailing '\\n' parsing", " - tools/power turbostat: Fix child's argument forwarding", " - block: always verify unfreeze lock on the owner task", " - block: don't verify IO lock for freeze/unfreeze in elevator_init_mq()", " - Linux 6.11.11", "", " * Oracular update: v6.11.11 upstream stable release (LP: #2091655) //", " CVE-2024-53141", " - netfilter: ipset: add missing range check in bitmap_ip_uadt", "", " * Oracular update: v6.11.11 upstream stable release (LP: #2091655) //", " CVE-2024-50010", " - Revert \"exec: don't WARN for racy path_noexec check\"", "", " * Oracular update: v6.11.11 upstream stable release (LP: #2091655) //", " CVE-2024-53143", " - fsnotify: Fix ordering of iput() and watched_objects decrement", "", " * Oracular update: v6.11.11 upstream stable release (LP: #2091655) //", " CVE-2024-53142", " - initramfs: avoid filename buffer overrun", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650)", " - net: vertexcom: mse102x: Fix tx_bytes calculation", " - net/mlx5: Fix msix vectors to respect platform limit", " - net/mlx5e: clear xdp features on non-uplink representors", " - net/mlx5e: Disable loopback self-test on multi-PF netdev", " - drm/i915/gsc: ARL-H and ARL-U need a newer GSC FW.", " - drivers: perf: Fix wrong put_cpu() placement", " - Bluetooth: hci_core: Fix calling mgmt_device_connected", " - Bluetooth: btintel: Direct exception event to bluetooth stack", " - net: sched: cls_u32: Fix u32's systematic failure to free IDR entries for", " hnodes.", " - net: phylink: ensure PHY momentary link-fails are handled", " - samples: pktgen: correct dev to DEV", " - net: stmmac: dwmac-mediatek: Fix inverted handling of mediatek,mac-wol", " - net: Make copy_safe_from_sockptr() match documentation", " - stmmac: dwmac-intel-plat: fix call balance of tx_clk handling routines", " - net: ti: icssg-prueth: Fix 1 PPS sync", " - bonding: add ns target multicast address to slave device", " - ARM: 9419/1: mm: Fix kernel memory mapping for xip kernels", " - tools/mm: fix compile error", " - drm/amd/display: Run idle optimizations at end of vblank handler", " - drm/amd/display: Change some variable name of psr", " - drm/amd/display: Fix Panel Replay not update screen correctly", " - x86/mm: Fix a kdump kernel failure on SME system when CONFIG_IMA_KEXEC=y", " - x86/stackprotector: Work around strict Clang TLS symbol requirements", " - crash, powerpc: default to CRASH_DUMP=n on PPC_BOOK3S_32", " - [Config] enable ARCH_DEFAULT_CRASH_DUMP", " - mm: revert \"mm: shmem: fix data-race in shmem_getattr()\"", " - vdpa/mlx5: Fix PA offset with unaligned starting iotlb map", " - evm: stop avoidably reading i_writecount in evm_file_release", " - KVM: selftests: Disable strict aliasing", " - KVM: nVMX: Treat vpid01 as current if L2 is active, but with VPID disabled", " - KVM: x86: Unconditionally set irr_pending when updating APICv state", " - tpm: Disable TPM on tpm2_create_primary() failure", " - ALSA: hda/realtek - Fixed Clevo platform headset Mic issue", " - ALSA: hda/realtek - update set GPIO3 to default for Thinkpad with ALC1318", " - mptcp: update local address flags when setting it", " - mptcp: hold pm lock when deleting entry", " - mptcp: pm: use _rcu variant under rcu_read_lock", " - ocfs2: fix UBSAN warning in ocfs2_verify_volume()", " - LoongArch: Fix early_numa_add_cpu() usage for FDT systems", " - LoongArch: Disable KASAN if PGDIR_SIZE is too large for cpu_vabits", " - LoongArch: Add WriteCombine shadow mapping in KASAN", " - LoongArch: Fix AP booting issue in VM mode", " - LoongArch: Make KASAN work with 5-level page-tables", " - selftests: hugetlb_dio: fixup check for initial conditions to skip in the", " start", " - btrfs: fix incorrect comparison for delayed refs", " - mailbox: qcom-cpucp: Mark the irq with IRQF_NO_SUSPEND flag", " - firmware: arm_scmi: Skip opp duplicates", " - firmware: arm_scmi: Report duplicate opps as firmware bugs", " - mmc: sunxi-mmc: Fix A100 compatible description", " - drm/bridge: tc358768: Fix DSI command tx", " - drm/xe: handle flat ccs during hibernation on igpu", " - pmdomain: arm: Use FLAG_DEV_NAME_FW to ensure unique names", " - pmdomain: core: Add GENPD_FLAG_DEV_NAME_FW flag", " - nouveau: fw: sync dma after setup is called.", " - nouveau: handle EBUSY and EAGAIN for GSP aux errors.", " - nouveau/dp: handle retries for AUX CH transfers with GSP.", " - drm/amd: Fix initialization mistake for NBIO 7.7.0", " - drm/amdgpu: fix check in gmc_v9_0_get_vm_pte()", " - drm/amdgpu: Fix video caps for H264 and HEVC encode maximum size", " - drm/amd/pm: print pp_dpm_mclk in ascending order on SMU v14.0.0", " - drm/amdgpu: enable GTT fallback handling for dGPUs only", " - drm/amdgpu/mes12: correct kiq unmap latency", " - drm/amd/display: Require minimum VBlank size for stutter optimization", " - drm/amd/display: Fix failure to read vram info due to static BP_RESULT", " - mm: refactor arch_calc_vm_flag_bits() and arm64 MTE handling", " - drm/xe: Restore system memory GGTT mappings", " - drm/xe: improve hibernation on igpu", " - lib/buildid: Fix build ID parsing logic", " - net: sched: u32: Add test case for systematic hnode IDR leaks", " - media: dvbdev: fix the logic when DVB_DYNAMIC_MINORS is not set", " - Linux 6.11.10", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53133", " - drm/amd/display: Handle dml allocation failure to avoid crash", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53108", " - drm/amd/display: Adjust VSDB parser for replay feature", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53134", " - pmdomain: imx93-blk-ctrl: correct remove path", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53132", " - drm/xe/oa: Fix \"Missing outer runtime PM protection\" warning", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53127", " - Revert \"mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K\"", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53130", " - nilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53105", " - mm: page_alloc: move mlocked flag clearance into free_pages_prepare()", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53109", " - nommu: pass NULL argument to vma_iter_prealloc()", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53131", " - nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53135", " - KVM: VMX: Bury Intel PT virtualization (guest/host mode) behind", " CONFIG_BROKEN", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53106", " - ima: fix buffer overrun in ima_eventdigest_init_common", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53110", " - vp_vdpa: fix id_table array not null terminated error", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53126", " - vdpa: solidrun: Fix UB bug with devres", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53111", " - mm/mremap: fix address wraparound in move_page_tables()", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53107", " - fs/proc/task_mmu: prevent integer overflow in pagemap_scan_get_args()", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53128", " - sched/task_stack: fix object_is_on_stack() for KASAN tagged pointers", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53112", " - ocfs2: uncache inode which has failed entering the group", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53113", " - mm: fix NULL pointer dereference in alloc_pages_bulk_noprof", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53114", " - x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 client", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53137", " - ARM: fix cacheflush with PAN", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53115", " - drm/vmwgfx: avoid null_ptr_deref in vmw_framebuffer_surface_create_handle", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53116", " - drm/panthor: Fix handling of partial GPU mapping of BOs", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53117", " - virtio/vsock: Improve MSG_ZEROCOPY error handling", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53118", " - vsock: Fix sk_error_queue memory leak", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53119", " - virtio/vsock: Fix accept_queue memory leak", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53120", " - net/mlx5e: CT: Fix null-ptr-deref in add rule err flow", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53138", " - net/mlx5e: kTLS, Fix incorrect page refcounting", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53121", " - net/mlx5: fs, lock FTE when checking if active", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53122", " - mptcp: cope racing subflow creation in mptcp_rcv_space_adjust", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53123", " - mptcp: error out earlier on disconnect", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53124", " - net: fix data-races around sk->sk_forward_alloc", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53129", " - drm/rockchip: vop: Fix a dereferenced before check warning", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53139", " - sctp: fix possible UAF in sctp_v6_available()", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53140", " - netlink: terminate outstanding dump on socket close", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649)", " - nvme/host: Fix RCU list traversal to use SRCU primitive", " - 9p: v9fs_fid_find: also lookup by inode if not found dentry", " - 9p: Avoid creating multiple slab caches with the same name", " - selftests/bpf: Verify that sync_linked_regs preserves subreg_def", " - nvmet-passthru: clear EUID/NGUID/UUID while using loop target", " - irqchip/ocelot: Fix trigger register address", " - pinctrl: aw9523: add missing mutex_destroy", " - pinctrl: intel: platform: Add Panther Lake to the list of supported", " - block: Fix elevator_get_default() checking for NULL q->tag_set", " - HID: multitouch: Add support for B2402FVA track point", " - HID: multitouch: Add quirk for HONOR MagicBook Art 14 touchpad", " - iommu/arm-smmu: Clarify MMU-500 CPRE workaround", " - nvme: disable CC.CRIME (NVME_CC_CRIME)", " - bpf: use kvzmalloc to allocate BPF verifier environment", " - crypto: api - Fix liveliness check in crypto_alg_tested", " - crypto: marvell/cesa - Disable hash algorithms", " - s390/ap: Fix CCA crypto card behavior within protected execution environment", " - sound: Make CONFIG_SND depend on INDIRECT_IOMEM instead of UML", " - drm/vmwgfx: Limit display layout ioctl array size to", " VMWGFX_NUM_DISPLAY_UNITS", " - selftests/bpf: Assert link info uprobe_multi count & path_size if unset", " - ALSA: hda/tas2781: Add new quirk for Lenovo, ASUS, Dell projects", " - drm/amdkfd: Accounting pdd vram_usage for svm", " - powerpc/powernv: Free name on error in opal_event_init()", " - net: phy: mdio-bcm-unimac: Add BCM6846 support", " - drm/xe/query: Increase timestamp width", " - nvme-loop: flush off pending I/O while shutting down loop controller", " - samples/landlock: Fix port parsing in sandboxer", " - vDPA/ifcvf: Fix pci_read_config_byte() return code handling", " - bpf: Fix mismatched RCU unlock flavour in bpf_out_neigh_v6", " - ASoC: Intel: avs: Update stream status in a separate thread", " - ASoC: codecs: Fix error handling in aw_dev_get_dsp_status function", " - ASoC: amd: yc: Add quirk for ASUS Vivobook S15 M3502RA", " - ASoC: amd: yc: Fix non-functional mic on ASUS E1404FA", " - ASoC: Intel: soc-acpi: lnl: Add match entry for TM2 laptops", " - netfs: Downgrade i_rwsem for a buffered write", " - HID: i2c-hid: Delayed i2c resume wakeup for 0x0d42 Goodix touchpad", " - HID: multitouch: Add quirk for Logitech Bolt receiver w/ Casa touchpad", " - HID: lenovo: Add support for Thinkpad X1 Tablet Gen 3 keyboard", " - ASoC: codecs: lpass-rx-macro: fix RXn(rx,n) macro for DSM_CTL and SEC7 regs", " - RISCV: KVM: use raw_spinlock for critical section in imsic", " - ASoC: rt722-sdca: increase clk_stop_timeout to fix clock stop issue", " - LoongArch: Use \"Exception return address\" to comment ERA", " - ASoC: fsl_micfil: Add sample rate constraint", " - net: usb: qmi_wwan: add Fibocom FG132 0x0112 composition", " - drm/xe: Enlarge the invalidation timeout from 150 to 500", " - drm/xe/guc/ct: Flush g2h worker in case of g2h response timeout", " - drm/xe: Handle unreliable MMIO reads during forcewake", " - drm/xe: Don't restart parallel queues multiple times on GT reset", " - mm: krealloc: Fix MTE false alarm in __do_krealloc", " - 9p: fix slab cache name creation for real", " - Linux 6.11.9", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53098", " - drm/xe/ufence: Prefetch ufence addr to catch bogus address", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53099", " - bpf: Check validity of link->type in bpf_link_show_fdinfo()", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53089", " - LoongArch: KVM: Mark hrtimer to expire in hard interrupt context", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53090", " - afs: Fix lock recursion", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53101", " - fs: Fix uninitialized value issue in from_kuid and from_kgid", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53091", " - bpf: Add sk_is_inet and IS_ICSK check in tls_sw_has_ctx_tx/rx", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53092", " - virtio_pci: Fix admin vq cleanup by using correct info pointer", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53102", " - nvme: make keep-alive synchronous operation", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53093", " - nvme-multipath: defer partition scanning", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53094", " - RDMA/siw: Add sendpage_ok() check to disable MSG_SPLICE_PAGES", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53100", " - nvme: tcp: avoid race between queue_lock lock and destroy", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53095", " - smb: client: Fix use-after-free of network namespace.", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645)", " - arm64: dts: rockchip: Fix rt5651 compatible value on rk3399-eaidk-610", " - arm64: dts: rockchip: Fix rt5651 compatible value on rk3399-sapphire-", " excavator", " - arm64: dts: rockchip: Move L3 cache outside CPUs in RK3588(S) SoC dtsi", " - arm64: dts: rockchip: Start cooling maps numbering from zero on ROCK 5B", " - arm64: dts: rockchip: Designate Turing RK1's system power controller", " - EDAC/qcom: Make irq configuration optional", " - arm64: dts: rockchip: Remove hdmi's 2nd interrupt on rk3328", " - arm64: dts: rockchip: Fix wakeup prop names on PineNote BT node", " - arm64: dts: rockchip: Fix reset-gpios property on brcm BT nodes", " - arm64: dts: rockchip: fix i2c2 pinctrl-names property on anbernic-rg353p/v", " - arm64: dts: rockchip: Drop regulator-init-microvolt from two boards", " - arm64: dts: rockchip: Fix bluetooth properties on rk3566 box demo", " - arm64: dts: rockchip: Fix bluetooth properties on Rock960 boards", " - arm64: dts: rockchip: Add DTS for FriendlyARM NanoPi R2S Plus", " - arm64: dts: rockchip: Remove undocumented supports-emmc property", " - arm64: dts: rockchip: Remove #cooling-cells from fan on Theobroma lion", " - arm64: dts: rockchip: Fix LED triggers on rk3308-roc-cc", " - arm64: dts: rockchip: remove num-slots property from rk3328-nanopi-r2s-plus", " - arm64: dts: qcom: sm8450 fix PIPE clock specification for pcie1", " - arm64: dts: imx8-ss-vpu: Fix imx8qm VPU IRQs", " - arm64: dts: imx8mp: correct sdhc ipg clk", " - arm64: dts: imx8mp-phyboard-pollux: Set Video PLL1 frequency to 506.8 MHz", " - firmware: qcom: scm: Return -EOPNOTSUPP for unsupported SHM bridge enabling", " - arm64: dts: rockchip: remove orphaned pinctrl-names from pinephone pro", " - ARM: dts: rockchip: fix rk3036 acodec node", " - ARM: dts: rockchip: drop grf reference from rk3036 hdmi", " - ARM: dts: rockchip: Fix the spi controller on rk3036", " - ARM: dts: rockchip: Fix the realtek audio codec on rk3036-kylin", " - arm64: dts: rockchip: Correct GPIO polarity on brcm BT nodes", " - sunrpc: handle -ENOTCONN in xs_tcp_setup_socket()", " - NFSv3: only use NFS timeout for MOUNT when protocols are compatible", " - NFS: Fix attribute delegation behaviour on exclusive create", " - NFS: Further fixes to attribute delegation a/mtime changes", " - nfs: avoid i_lock contention in nfs_clear_invalid_mapping", " - net: enetc: set MAC address to the VF net_device", " - net: dpaa_eth: print FD status in CPU endianness in dpaa_eth_fd tracepoint", " - dt-bindings: net: xlnx,axi-ethernet: Correct phy-mode property value", " - can: c_can: fix {rx,tx}_errors statistics", " - ice: change q_index variable type to s16 to store -1 value", " - e1000e: Remove Meteor Lake SMBUS workarounds", " - net: phy: ti: add PHY_RST_AFTER_CLK_EN flag", " - net: stmmac: Fix unbalanced IRQ wake disable warning on single irq case", " - netfilter: nf_tables: wait for rcu grace period on net_device removal", " - virtio_net: Support dynamic rss indirection table size", " - virtio_net: Sync rss config to device when virtnet_probe", " - virtio_net: Update rss when set queue", " - net: arc: rockchip: fix emac mdio node support", " - drivers: net: ionic: add missed debugfs cleanup to ionic_probe() error path", " - Revert \"ALSA: hda/conexant: Mute speakers at suspend / shutdown\"", " - media: stb0899_algo: initialize cfr before using it", " - media: dvb_frontend: don't play tricks with underflow values", " - media: adv7604: prevent underflow condition when reporting colorspace", " - scsi: sd_zbc: Use kvzalloc() to allocate REPORT ZONES buffer", " - ALSA: firewire-lib: fix return value on fail in amdtp_tscm_init()", " - tools/lib/thermal: Fix sampling handler context ptr", " - thermal/of: support thermal zones w/o trips subnode", " - ASoC: SOF: sof-client-probes-ipc4: Set param_size extension bits", " - media: pulse8-cec: fix data timestamp at pulse8_setup()", " - media: v4l2-ctrls-api: fix error handling for v4l2_g_ctrl()", " - can: m_can: m_can_close(): don't call free_irq() for IRQ-less devices", " - can: mcp251xfd: mcp251xfd_get_tef_len(): fix length calculation", " - can: mcp251xfd: mcp251xfd_ring_alloc(): fix coalescing configuration when", " switching CAN modes", " - can: {cc770,sja1000}_isa: allow building on x86_64", " - [Config] updateconfigs for CAN_{CC770,SJA1000}_ISA", " - drm/xe: Set mask bits for CCS_MODE register", " - pwm: imx-tpm: Use correct MODULO value for EPWM mode", " - rpmsg: glink: Handle rejected intent request better", " - drm/amd/pm: always pick the pptable from IFWI", " - drm/amd/display: Fix brightness level not retained over reboot", " - drm/imagination: Add a per-file PVR context list", " - drm/amdgpu: Adjust debugfs eviction and IB access permissions", " - drm/amdgpu: Adjust debugfs register access permissions", " - drm/amdgpu: Fix DPX valid mode check on GC 9.4.3", " - drm/amdgpu: prevent NULL pointer dereference if ATIF is not supported", " - thermal/drivers/qcom/lmh: Remove false lockdep backtrace", " - dm cache: correct the number of origin blocks to match the target length", " - dm cache: optimize dirty bit checking with find_next_bit when resizing", " - dm-unstriped: cast an operand to sector_t to prevent potential uint32_t", " overflow", " - mptcp: no admin perm to list endpoints", " - ALSA: usb-audio: Add quirk for HP 320 FHD Webcam", " - tracing: Fix tracefs mount options", " - net: wwan: t7xx: Fix off-by-one error in t7xx_dpmaif_rx_buf_alloc()", " - mptcp: use sock_kfree_s instead of kfree", " - arm64: Kconfig: Make SME depend on BROKEN for now", " - [Config] updateconfigs for ARM64_SME", " - arm64: smccc: Remove broken support for SMCCCv1.3 SVE discard hint", " - KVM: PPC: Book3S HV: Mask off LPCR_MER for a vCPU before running it to avoid", " spurious interrupts", " - btrfs: fix the length of reserved qgroup to free", " - btrfs: fix per-subvolume RO/RW flags with new mount API", " - platform/x86/amd/pmf: Relocate CPU ID macros to the PMF header", " - platform/x86/amd/pmf: Update SMU metrics table for 1AH family series", " - platform/x86/amd/pmf: Add SMU metrics table support for 1Ah family 60h model", " - i2c: designware: do not hold SCL low when I2C_DYNAMIC_TAR_UPDATE is not set", " - clk: qcom: gcc-x1e80100: Fix USB MP SS1 PHY GDSC pwrsts flags", " - clk: qcom: clk-alpha-pll: Fix pll post div mask when width is not set", " - fs/proc: fix compile warning about variable 'vmcore_mmap_ops'", " - objpool: fix to make percpu slot allocation more robust", " - mm/damon/core: handle zero {aggregation,ops_update} intervals", " - mm/damon/core: handle zero schemes apply interval", " - mm/mlock: set the correct prev on failure", " - thunderbolt: Add only on-board retimers when !CONFIG_USB4_DEBUGFS_MARGINING", " - usb: dwc3: fix fault at system suspend if device was already runtime", " suspended", " - USB: serial: qcserial: add support for Sierra Wireless EM86xx", " - USB: serial: option: add Fibocom FG132 0x0112 composition", " - USB: serial: option: add Quectel RG650V", " - clk: qcom: gcc-x1e80100: Fix halt_check for pipediv2 clocks", " - thunderbolt: Fix connection issue with Pluggable UD-4VPD dock", " - staging: vchiq_arm: Use devm_kzalloc() for drv_mgmt allocation", " - staging: vchiq_arm: Use devm_kzalloc() for vchiq_arm_state allocation", " - irqchip/gic-v3: Force propagation of the active state with a read-back", " - ucounts: fix counter leak in inc_rlimit_get_ucounts()", " - selftests: hugetlb_dio: check for initial conditions to skip in the start", " - firmware: qcom: scm: Refactor code to support multiple dload mode", " - [Config] updateconfigs for QCOM_SCM_DOWNLOAD_MODE_DEFAULT", " - firmware: qcom: scm: suppress download mode error", " - block: rework bio splitting", " - block: fix queue limits checks in blk_rq_map_user_bvec for real", " - drm/xe: Move LNL scheduling WA to xe_device.h", " - drm/xe/ufence: Flush xe ordered_wq in case of ufence timeout", " - drm/xe/guc/tlb: Flush g2h worker in case of tlb timeout", " - ASoC: amd: yc: fix internal mic on Xiaomi Book Pro 14 2022", " - xtensa: Emulate one-byte cmpxchg", " - Linux 6.11.8", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50265", " - ocfs2: remove entry once instead of null-ptr-dereference in", " ocfs2_xa_remove()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50266", " - clk: qcom: videocc-sm8350: use HW_CTRL_TRIGGER for vcodec GDSCs", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50267", " - USB: serial: io_edgeport: fix use after free in debug printk", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50268", " - usb: typec: fix potential out of bounds in ucsi_ccg_update_set_new_cam_cmd()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53083", " - usb: typec: qcom-pmic: init value of hdr_len/txbuf_len earlier", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50269", " - usb: musb: sunxi: Fix accessing an released usb phy", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53079", " - mm/thp: fix deferred split unqueue naming and locking", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50270", " - mm/damon/core: avoid overflow in damon_feed_loop_next_input()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50271", " - signal: restore the override_rlimit logic", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50272", " - filemap: Fix bounds checking in filemap_read()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53104", " - media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in", " uvc_parse_format", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50273", " - btrfs: reinitialize delayed ref list after deleting it from the list", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53064", " - idpf: fix idpf_vc_core_init error path", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50274", " - idpf: avoid vport access in idpf_get_link_ksettings", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53065", " - mm/slab: fix warning caused by duplicate kmem_cache creation in", " kmem_buckets_create", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50275", " - arm64/sve: Discard stale CPU state when handling SVE traps", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50276", " - net: vertexcom: mse102x: Fix possible double free of TX skb", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53066", " - nfs: Fix KMSAN warning in decode_getfattr_attrs()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53067", " - scsi: ufs: core: Start the RTC update work later", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50277", " - dm: fix a crash if blk_alloc_disk fails", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50278", " - dm cache: fix potential out-of-bounds access on the first resume", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50279", " - dm cache: fix out-of-bounds access to the dirty bitset when resizing", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50280", " - dm cache: fix flushing uninitialized delayed_work on cache_ctr error", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50281", " - KEYS: trusted: dcp: fix NULL dereference in AEAD crypto operation", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50282", " - drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53071", " - drm/panthor: Be stricter about IO mapping flags", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53080", " - drm/panthor: Lock XArray when getting entries for the VM", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53084", " - drm/imagination: Break an object reference loop", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53085", " - tpm: Lock TPM chip in tpm_pm_suspend() first", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53086", " - drm/xe: Drop VM dma-resv lock on xe_sync_in_fence_get failure in exec IOCTL", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53087", " - drm/xe: Fix possible exec queue leak in exec IOCTL", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50283", " - ksmbd: fix slab-use-after-free in smb3_preauth_hash_rsp", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50284", " - ksmbd: Fix the missing xa_store error check", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50285", " - ksmbd: check outstanding simultaneous SMB operations", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50286", " - ksmbd: fix slab-use-after-free in ksmbd_smb2_session_create", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50287", " - media: v4l2-tpg: prevent the risk of a division by zero", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50288", " - media: vivid: fix buffer overwrite when using > 32 buffers", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50289", " - media: av7110: fix a spectre vulnerability", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50290", " - media: cx24116: prevent overflows on SNR calculus", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53061", " - media: s5p-jpeg: prevent buffer overflows", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53081", " - media: ar0521: don't overflow when checking PLL values", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53062", " - media: mgb4: protect driver against spectre", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50291", " - media: dvb-core: add missing buffer index check", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50292", " - ASoC: stm32: spdifrx: fix dma channel release in stm32_spdifrx_remove", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53063", " - media: dvbdev: prevent the risk of out of memory access", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50293", " - net/smc: do not leave a dangling sk pointer in __smc_create()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50294", " - rxrpc: Fix missing locking causing hanging calls", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50295", " - net: arc: fix the device for dma_map_single/dma_unmap_single", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53082", " - virtio_net: Add hash_key_length check", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50296", " - net: hns3: fix kernel crash when uninstalling driver", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53088", " - i40e: fix race condition by adding filter's intermediate sync state", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50297", " - net: xilinx: axienet: Enqueue Tx packets in dql before dmaengine starts", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50298", " - net: enetc: allocate vf_state during PF probes", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50299", " - sctp: properly validate chunk size in sctp_sf_ootb()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50300", " - regulator: rtq2208: Fix uninitialized use of regulator_config", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50301", " - security/keys: fix slab-out-of-bounds in key_task_permission", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53072", " - platform/x86/amd/pmc: Detect when STB is not available", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50302", " - HID: core: zero-initialize the report buffer", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53068", " - firmware: arm_scmi: Fix slab-use-after-free in scmi_bus_notifier()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53069", " - firmware: qcom: scm: fix a NULL-pointer dereference", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629)", " - drm/amdgpu: fix random data corruption for sdma 7", " - cgroup: Fix potential overflow issue when checking max_depth", " - spi: geni-qcom: Fix boot warning related to pm_runtime and devres", " - perf trace: Fix non-listed archs in the syscalltbl routines", " - perf python: Fix up the build on architectures without HAVE_KVM_STAT_SUPPORT", " - scsi: scsi_debug: Fix do_device_access() handling of unexpected SG copy", " length", " - wifi: iwlegacy: Fix \"field-spanning write\" warning in il_enqueue_hcmd()", " - mac80211: MAC80211_MESSAGE_TRACING should depend on TRACING", " - wifi: mac80211: skip non-uploaded keys in ieee80211_iter_keys", " - wifi: ath11k: Fix invalid ring usage in full monitor mode", " - wifi: rtw89: pci: early chips only enable 36-bit DMA on specific PCI hosts", " - wifi: brcm80211: BRCM_TRACING should depend on TRACING", " - RDMA/cxgb4: Dump vendor specific QP details", " - RDMA/mlx5: Round max_rd_atomic/max_dest_rd_atomic up instead of down", " - RDMA/bnxt_re: Fix the usage of control path spin locks", " - RDMA/bnxt_re: synchronize the qp-handle table array", " - wifi: iwlwifi: mvm: really send iwl_txpower_constraints_cmd", " - wifi: iwlwifi: mvm: don't add default link in fw restart flow", " - Revert \"wifi: iwlwifi: remove retry loops in start\"", " - ASoC: cs42l51: Fix some error handling paths in cs42l51_probe()", " - net: stmmac: dwmac4: Fix high address display by updating reg_space[] from", " register values", " - dpll: add Embedded SYNC feature for a pin", " - ice: add callbacks for Embedded SYNC enablement on dpll pins", " - gtp: allow -1 to be specified as file description from userspace", " - bpf: Force checkpoint when jmp history is too long", " - bpf: Add bpf_mem_alloc_check_size() helper", " - net: skip offload for NETIF_F_IPV6_CSUM if ipv6 header contains extension", " - mlxsw: spectrum_ptp: Add missing verification before pushing Tx header", " - mlxsw: pci: Sync Rx buffers for CPU", " - mlxsw: pci: Sync Rx buffers for device", " - net: ethernet: mtk_wed: fix path of MT7988 WO firmware", " - bpf, test_run: Fix LIVE_FRAME frame update after a page has been recycled", " - iomap: improve shared block detection in iomap_unshare_iter", " - iomap: don't bother unsharing delalloc extents", " - iomap: share iomap_unshare_iter predicate code with fsdax", " - fsdax: remove zeroing code from dax_unshare_iter", " - iomap: turn iomap_want_unshare_iter into an inline function", " - kasan: Fix Software Tag-Based KASAN with GCC", " - firmware: arm_sdei: Fix the input parameter of cpuhp_remove_state()", " - afs: Fix missing subdir edit when renamed between parent dirs", " - gpio: sloppy-logic-analyzer: Check for error code from devm_mutex_init()", " call", " - smb: client: fix parsing of device numbers", " - smb: client: set correct device number on nfs reparse points", " - drm/mediatek: ovl: Remove the color format comment for ovl_fmt_convert()", " - drm/mediatek: Fix color format MACROs in OVL", " - drm/mediatek: Fix get efuse issue for MT8188 DPTX", " - drm/mediatek: Use cmdq_pkt_create() and cmdq_pkt_destroy()", " - cxl/events: Fix Trace DRAM Event Record", " - PCI: Fix pci_enable_acs() support for the ACS quirks", " - nvme: module parameter to disable pi with offsets", " - drm/panthor: Fix firmware initialization on systems with a page size > 4k", " - drm/panthor: Fail job creation when the group is dead", " - drm/panthor: Report group as timedout when we fail to properly suspend", " - fs/ntfs3: Fix warning possible deadlock in ntfs_set_state", " - fs/ntfs3: Stale inode instead of bad", " - rust: device: change the from_raw() function", " - scsi: scsi_transport_fc: Allow setting rport state to current state", " - cifs: Improve creating native symlinks pointing to directory", " - cifs: Fix creating native symlinks pointing to current or parent directory", " - ACPI: resource: Fold Asus Vivobook Pro N6506M* DMI quirks together", " - powercap: intel_rapl_msr: Add PL4 support for Arrowlake-U", " - thermal: intel: int340x: processor: Remove MMIO RAPL CPU hotplug support", " - thermal: intel: int340x: processor: Add MMIO RAPL PL4 support", " - net: amd: mvme147: Fix probe banner message", " - NFS: remove revoked delegation from server's delegation list", " - misc: sgi-gru: Don't disable preemption in GRU driver", " - NFSD: Initialize struct nfsd4_copy earlier", " - NFSD: Never decrement pending_async_copies on error", " - ALSA: usb-audio: Add quirks for Dell WD19 dock", " - wifi: rtlwifi: rtl8192du: Don't claim USB ID 0bda:8171", " - usbip: tools: Fix detach_port() invalid port error path", " - usb: phy: Fix API devm_usb_put_phy() can not release the phy", " - usb: typec: fix unreleased fwnode_handle in typec_port_register_altmodes()", " - usb: typec: tcpm: restrict SNK_WAIT_CAPABILITIES_TIMEOUT transitions to non", " self-powered devices", " - usb: typec: qcom-pmic-typec: use fwnode_handle_put() to release fwnodes", " - usb: typec: qcom-pmic-typec: fix missing fwnode removal in error path", " - xhci: Fix Link TRB DMA in command ring stopped completion event", " - xhci: Use pm_runtime_get to prevent RPM on unsupported systems", " - Revert \"driver core: Fix uevent_show() vs driver detach race\"", " - dt-bindings: iio: adc: ad7380: fix ad7380-4 reference supply", " - iio: light: veml6030: fix microlux value calculation", " - RISC-V: ACPI: fix early_ioremap to early_memremap", " - tools/mm: -Werror fixes in page-types/slabinfo", " - mm: shrinker: avoid memleak in alloc_shrinker_info", " - firmware: microchip: auto-update: fix poll_complete() to not report spurious", " timeout errors", " - thunderbolt: Honor TMU requirements in the domain when setting TMU mode", " - soc: qcom: pmic_glink: Handle GLINK intent allocation rejections", " - cxl/port: Fix CXL port initialization order when the subsystem is built-in", " - mmc: sdhci-pci-gli: GL9767: Fix low power mode on the set clock function", " - mmc: sdhci-pci-gli: GL9767: Fix low power mode in the SD Express process", " - block: fix sanity checks in blk_rq_map_user_bvec", " - phy: freescale: imx8m-pcie: Do CMN_RST just before PHY PLL lock check", " - btrfs: merge btrfs_orig_bbio_end_io() into btrfs_bio_end_io()", " - riscv: vdso: Prevent the compiler from inserting calls to memset()", " - Input: edt-ft5x06 - fix regmap leak when probe fails", " - ALSA: hda/realtek: Limit internal Mic boost on Dell platform", " - riscv: efi: Set NX compat flag in PE/COFF header", " - riscv: Use '%u' to format the output of 'cpu'", " - riscv: Remove unused GENERATING_ASM_OFFSETS", " - riscv: Remove duplicated GET_RM", " - cxl/port: Fix cxl_bus_rescan() vs bus_rescan_devices()", " - cxl/acpi: Ensure ports ready at cxl_acpi_probe() return", " - posix-cpu-timers: Clear TICK_DEP_BIT_POSIX_TIMER on clone", " - tpm: Return tpm2_sessions_init() when null key creation fails", " - tpm: Rollback tpm2_load_null()", " - drm/amdgpu/smu13: fix profile reporting", " - tpm: Lazily flush the auth session", " - mei: use kvmalloc for read buffer", " - x86/traps: Enable UBSAN traps on x86", " - x86/traps: move kmsan check after instrumentation_begin", " - accel/ivpu: Fix NOC firewall interrupt handling", " - ALSA: hda/realtek: Fix headset mic on TUXEDO Gemini 17 Gen3", " - ALSA: hda/realtek: Fix headset mic on TUXEDO Stellaris 16 Gen6 mb1", " - nvme: re-fix error-handling for io_uring nvme-passthrough", " - kasan: remove vmalloc_percpu test", " - drm/tests: helpers: Add helper for drm_display_mode_from_cea_vic()", " - drm/xe: Fix register definition order in xe_regs.h", " - drm/xe: Kill regs/xe_sriov_regs.h", " - drm/xe: Add mmio read before GGTT invalidate", " - drm/xe: Don't short circuit TDR on jobs not started", " - btrfs: fix extent map merging not happening for adjacent extents", " - btrfs: fix defrag not merging contiguous extents due to merged extent maps", " - gpiolib: fix debugfs newline separators", " - gpiolib: fix debugfs dangling chip separator", " - vmscan,migrate: fix page count imbalance on node stats when demoting pages", " - mm, mmap: limit THP alignment of anonymous mappings to PMD-aligned sizes", " - Input: fix regression when re-registering input handlers", " - mm: multi-gen LRU: ignore non-leaf pmd_young for force_scan=true", " - mm: multi-gen LRU: remove MM_LEAF_OLD and MM_NONLEAF_TOTAL stats", " - mm: shrink skip folio mapped by an exiting process", " - mm: multi-gen LRU: use {ptep,pmdp}_clear_young_notify()", " - riscv: dts: starfive: Update ethernet phy0 delay parameter values for Star64", " - riscv: dts: starfive: disable unused csi/camss nodes", " - arm64: dts: qcom: msm8939: revert use of APCS mbox for RPM", " - arm64: dts: qcom: x1e80100-yoga-slim7x: fix nvme regulator boot glitch", " - arm64: dts: qcom: x1e80100: Fix up BAR spaces", " - arm64: dts: qcom: x1e80100-vivobook-s15: fix nvme regulator boot glitch", " - arm64: dts: qcom: x1e80100: fix PCIe4 interconnect", " - arm64: dts: qcom: x1e80100-qcp: fix nvme regulator boot glitch", " - arm64: dts: qcom: x1e80100-crd: fix nvme regulator boot glitch", " - arm64: dts: qcom: x1e80100: Add Broadcast_AND region in LLCC block", " - arm64: dts: qcom: x1e80100: fix PCIe4 and PCIe6a PHY clocks", " - drm/xe/xe2hpg: Add Wa_15016589081", " - drm/amdgpu/swsmu: fix ordering for setting workload_mask", " - drm/amdgpu/swsmu: default to fullscreen 3D profile for dGPUs", " - fs/ntfs3: Sequential field availability check in mi_enum_attr()", " - drm/amdgpu: handle default profile on on devices without fullscreen 3D", " - MIPS: export __cmpxchg_small()", " - RISC-V: disallow gcc + rust builds", " - [Config] updateconfigs after disabling rust with gcc on riscv", " - rcu/kvfree: Add kvfree_rcu_barrier() API", " - rcu/kvfree: Refactor kvfree_rcu_queue_batch()", " - Linux 6.11.7", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50212", " - lib: alloc_tag_module_unload must wait for pending kfree_rcu calls", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53046", " - arm64: dts: imx8ulp: correct the flexspi compatible string", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53052", " - io_uring/rw: fix missing NOWAIT check for O_DIRECT start write", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50213", " - drm/tests: hdmi: Fix memory leaks in drm_display_mode_from_cea_vic()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50214", " - drm/connector: hdmi: Fix memory leak in drm_display_mode_from_cea_vic()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50215", " - nvmet-auth: assign dh_key to NULL after kfree_sensitive", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50216", " - xfs: fix finding a last resort AG in xfs_filestream_pick_ag", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50217", " - btrfs: fix use-after-free of block device file in", " __btrfs_free_extra_devids()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53043", " - mctp i2c: handle NULL header address", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50303", " - resource,kexec: walk_system_ram_res_rev must retain resource flags", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50218", " - ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50219", " - mm/page_alloc: let GFP_ATOMIC order-0 allocs access highatomic reserves", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50263", " - fork: only invoke khugepaged, ksm hooks if no error", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50220", " - fork: do not invoke uffd on fork if error occurs", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53047", " - mptcp: init: protect sched with rcu_read_lock", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50221", " - drm/amd/pm: Vangogh: Fix kernel memory out of bounds write", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50222", " - iov_iter: fix copy_page_from_iter_atomic() if KMAP_LOCAL_FORCE_MAP", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50223", " - sched/numa: Fix the potential null pointer dereference in task_numa_work()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53053", " - scsi: ufs: core: Fix another deadlock during RTC update", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53075", " - riscv: Prevent a bad reference count on CPU nodes", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50224", " - spi: spi-fsl-dspi: Fix crash when not using GPIO chip select", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50225", " - btrfs: fix error propagation of split bios", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53054", " - cgroup/bpf: use a dedicated workqueue for cgroup bpf destruction", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50226", " - cxl/port: Fix use-after-free, permit out-of-order decoder shutdown", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50227", " - thunderbolt: Fix KASAN reported stack out-of-bounds read in", " tb_retimer_scan()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50228", " - mm: shmem: fix data-race in shmem_getattr()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50229", " - nilfs2: fix potential deadlock with newly created symlinks", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50230", " - nilfs2: fix kernel bug due to missing clearing of checked flag", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50231", " - iio: gts-helper: Fix memory leaks in iio_gts_build_avail_scale_table()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53076", " - iio: gts-helper: Fix memory leaks for the error path of", " iio_gts_build_avail_scale_table()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50232", " - iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50233", " - staging: iio: frequency: ad9832: fix division by zero in", " ad9832_calc_freqreg()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53055", " - wifi: iwlwifi: mvm: fix 6 GHz scan construction", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50234", " - wifi: iwlegacy: Clear stale interrupts before resuming device", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50235", " - wifi: cfg80211: clear wdev->cqm_config pointer on free", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50236", " - wifi: ath10k: Fix memory leak in management tx", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50237", " - wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50238", " - phy: qcom: qmp-usbc: fix NULL-deref on runtime suspend", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50239", " - phy: qcom: qmp-usb-legacy: fix NULL-deref on runtime suspend", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50240", " - phy: qcom: qmp-usb: fix NULL-deref on runtime suspend", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53077", " - rpcrdma: Always release the rpcrdma_device's xa_array", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50242", " - fs/ntfs3: Additional check in ntfs_file_release", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50243", " - fs/ntfs3: Fix general protection fault in run_is_mapped_full", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50244", " - fs/ntfs3: Additional check in ni_clear()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50245", " - fs/ntfs3: Fix possible deadlock in mi_read", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50246", " - fs/ntfs3: Add rough attr alloc_size check", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50247", " - fs/ntfs3: Check if more than chunk-size bytes are written", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50248", " - ntfs3: Add bounds checking to mi_enum_attr()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53078", " - drm/tegra: Fix NULL vs IS_ERR() check in probe()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53056", " - drm/mediatek: Fix potential NULL dereference in mtk_crtc_destroy()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50249", " - ACPI: CPPC: Make rmw_lock a raw_spin_lock", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50250", " - fsdax: dax_unshare_iter needs to copy entire blocks", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50251", " - netfilter: nft_payload: sanitize offset and length before calling", " skb_checksum()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50252", " - mlxsw: spectrum_ipip: Fix memory leak when changing remote IPv6 address", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50253", " - bpf: Check the validity of nr_words in bpf_iter_bits_new()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50254", " - bpf: Free dynamically allocated bits in bpf_iter_bits_destroy()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50255", " - Bluetooth: hci: fix null-ptr-deref in hci_read_supported_codecs", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50256", " - netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50257", " - netfilter: Fix use-after-free in get_info()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50258", " - net: fix crash when config small gso_max_size/gso_ipv4_max_size", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50262", " - bpf: Fix out-of-bounds write in trie_get_next_key()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53044", " - net/sched: sch_api: fix xa_insert() error path in tcf_block_get_ext()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50259", " - netdevsim: Add trailing zero to terminate the string in", " nsim_nexthop_bucket_activity_write()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50304", " - ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53042", " - ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_init_flow()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53048", " - ice: fix crash on probe for DPLL enabled E810 LOM", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53058", " - net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50260", " - sock_map: fix a NULL pointer dereference in sock_map_link_update_prog()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53045", " - ASoC: dapm: fix bounds checker error in dapm_widget_list_create", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50261", " - macsec: Fix use-after-free while sending the offloading packet", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53059", " - wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53074", " - wifi: iwlwifi: mvm: don't leak a link on AP removal", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53049", " - slub/kunit: fix a WARNING due to unwrapped __kmalloc_cache_noprof", "", " * Oracular update: v6.11.6 upstream stable release (LP: #2091386)", " - bpf: Use raw_spinlock_t in ringbuf", " - iio: accel: bma400: Fix uninitialized variable field_value in tap event", " handling.", " - reset: starfive: jh71x0: Fix accessing the empty member on JH7110 SoC", " - bpf: sync_linked_regs() must preserve subreg_def", " - bpf: Make sure internal and UAPI bpf_redirect flags don't overlap", " - irqchip/riscv-imsic: Fix output text of base address", " - bpf: devmap: provide rxq after redirect", " - cpufreq/amd-pstate: Fix amd_pstate mode switch on shared memory systems", " - lib/Kconfig.debug: fix grammar in RUST_BUILD_ASSERT_ALLOW", " - bpf: Fix memory leak in bpf_core_apply", " - RDMA/bnxt_re: Fix a possible memory leak", " - RDMA/bnxt_re: Fix incorrect AVID type in WQE structure", " - RDMA/bnxt_re: Add a check for memory allocation", " - x86/resctrl: Avoid overflow in MB settings in bw_validate()", " - ARM: dts: bcm2837-rpi-cm3-io3: Fix HDMI hpd-gpio pin", " - clk: rockchip: fix finding of maximum clock ID", " - bpf: Check the remaining info_cnt before repeating btf fields", " - bpf: fix unpopulated name_len field in perf_event link info", " - selftests/bpf: fix perf_event link info name_len assertion", " - riscv, bpf: Fix possible infinite tailcall when CONFIG_CFI_CLANG is enabled", " - s390/pci: Handle PCI error codes other than 0x3a", " - bpf: fix kfunc btf caching for modules", " - iio: frequency: {admv4420,adrf6780}: format Kconfig entries", " - iio: frequency: admv4420: fix missing select REMAP_SPI in Kconfig", " - drm/vmwgfx: Handle possible ENOMEM in vmw_stdu_connector_atomic_check", " - selftests/bpf: Fix cross-compiling urandom_read", " - bpf: Fix unpopulated path_size when uprobe_multi fields unset", " - sched/core: Disable page allocation in task_tick_mm_cid()", " - ALSA: hda/cs8409: Fix possible NULL dereference", " - firmware: arm_scmi: Fix the double free in scmi_debugfs_common_setup()", " - RDMA/cxgb4: Fix RDMA_CM_EVENT_UNREACHABLE error for iWARP", " - RDMA/irdma: Fix misspelling of \"accept*\"", " - RDMA/srpt: Make slab cache names unique", " - elevator: do not request_module if elevator exists", " - elevator: Remove argument from elevator_find_get", " - ipv4: give an IPv4 dev to blackhole_netdev", " - net: sparx5: fix source port register when mirroring", " - RDMA/bnxt_re: Fix the max CQ WQEs for older adapters", " - RDMA/bnxt_re: Fix out of bound check", " - RDMA/bnxt_re: Fix incorrect dereference of srq in async event", " - RDMA/bnxt_re: Return more meaningful error", " - RDMA/bnxt_re: Avoid CPU lockups due fifo occupancy check loop", " - RDMA/bnxt_re: Get the toggle bits from SRQ events", " - RDMA/bnxt_re: Change the sequence of updating the CQ toggle value", " - RDMA/bnxt_re: Fix a bug while setting up Level-2 PBL pages", " - RDMA/bnxt_re: Fix the GID table length", " - accel/qaic: Fix the for loop used to walk SG table", " - drm/panel: himax-hx83102: Adjust power and gamma to optimize brightness", " - drm/msm/dpu: make sure phys resources are properly initialized", " - drm/msm/dpu: move CRTC resource assignment to dpu_encoder_virt_atomic_check", " - drm/msm/dpu: check for overflow in _dpu_crtc_setup_lm_bounds()", " - drm/msm/dsi: improve/fix dsc pclk calculation", " - drm/msm/dsi: fix 32-bit signed integer extension in pclk_rate calculation", " - drm/msm: Avoid NULL dereference in msm_disp_state_print_regs()", " - drm/msm: Allocate memory for disp snapshot with kvzalloc()", " - firmware: arm_scmi: Queue in scmi layer for mailbox implementation", " - net/smc: Fix memory leak when using percpu refs", " - [PATCH} hwmon: (jc42) Properly detect TSE2004-compliant devices again", " - net: usb: usbnet: fix race in probe failure", " - net: stmmac: dwmac-tegra: Fix link bring-up sequence", " - octeontx2-af: Fix potential integer overflows on integer shifts", " - ring-buffer: Fix reader locking when changing the sub buffer order", " - drm/amd/amdgpu: Fix double unlock in amdgpu_mes_add_ring", " - macsec: don't increment counters for an unrelated SA", " - netdevsim: use cond_resched() in nsim_dev_trap_report_work()", " - net: ethernet: aeroflex: fix potential memory leak in", " greth_start_xmit_gbit()", " - net/smc: Fix searching in list of known pnetids in smc_pnet_add_pnetid", " - net: xilinx: axienet: fix potential memory leak in axienet_start_xmit()", " - net: ethernet: rtsn: fix potential memory leak in rtsn_start_xmit()", " - bpf: Fix truncation bug in coerce_reg_to_size_sx()", " - net: systemport: fix potential memory leak in bcm_sysport_xmit()", " - irqchip/renesas-rzg2l: Fix missing put_device", " - drm/msm/dpu: Don't always set merge_3d pending flush", " - drm/msm/dpu: don't always program merge_3d block", " - net: bcmasp: fix potential memory leak in bcmasp_xmit()", " - drm/msm/a6xx+: Insert a fence wait before SMMU table update", " - tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink().", " - net: dsa: mv88e6xxx: Fix the max_vid definition for the MV88E6361", " - genetlink: hold RCU in genlmsg_mcast()", " - ravb: Remove setting of RX software timestamp", " - net: ravb: Only advertise Rx/Tx timestamps if hardware supports it", " - net: dsa: vsc73xx: fix reception from VLAN-unaware bridges", " - scsi: target: core: Fix null-ptr-deref in target_alloc_device()", " - smb: client: fix possible double free in smb2_set_ea()", " - smb: client: fix OOBs when building SMB2_IOCTL request", " - usb: typec: altmode should keep reference to parent", " - s390: Initialize psw mask in perf_arch_fetch_caller_regs()", " - drm/xe: fix unbalanced rpm put() with fence_fini()", " - drm/xe: fix unbalanced rpm put() with declare_wedged()", " - drm/xe: Take job list lock in xe_sched_add_pending_job", " - drm/xe: Don't free job in TDR", " - drm/xe: Use bookkeep slots for external BO's in exec IOCTL", " - bpf: Fix link info netfilter flags to populate defrag flag", " - Bluetooth: bnep: fix wild-memory-access in proto_unregister", " - vmxnet3: Fix packet corruption in vmxnet3_xdp_xmit_frame", " - net: ethernet: mtk_eth_soc: fix memory corruption during fq dma init", " - net/mlx5: Check for invalid vector index on EQ creation", " - net/mlx5: Fix command bitmask initialization", " - net/mlx5: Unregister notifier on eswitch init failure", " - net/mlx5e: Don't call cleanup on profile rollback failure", " - bpf, sockmap: SK_DROP on attempted redirects of unsupported af_vsock", " - vsock: Update rx_bytes on read_skb()", " - vsock: Update msg_count on read_skb()", " - bpf, vsock: Drop static vsock_bpf_prot initialization", " - riscv, bpf: Make BPF_CMPXCHG fully ordered", " - nvme-pci: fix race condition between reset and nvme_dev_disable()", " - bpf: Fix iter/task tid filtering", " - bpf: Fix incorrect delta propagation between linked registers", " - bpf: Fix print_reg_state's constant scalar dump", " - cdrom: Avoid barrier_nospec() in cdrom_ioctl_media_changed()", " - fgraph: Allocate ret_stack_list with proper size", " - mm: shmem: rename shmem_is_huge() to shmem_huge_global_enabled()", " - mm: shmem: move shmem_huge_global_enabled() into", " shmem_allowable_huge_orders()", " - mm: huge_memory: add vma_thp_disabled() and thp_disabled_by_hw()", " - mm: don't install PMD mappings when THPs are disabled by the hw/process/vma", " - iio: adc: ti-lmp92064: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - xhci: dbgtty: remove kfifo_out() wrapper", " - xhci: dbgtty: use kfifo from tty_port struct", " - xhci: dbc: honor usb transfer size boundaries.", " - uprobe: avoid out-of-bounds memory access of fetching args", " - drm/vboxvideo: Replace fake VLA at end of vbva_mouse_pointer_shape with real", " VLA", " - ASoC: amd: yc: Add quirk for HP Dragonfly pro one", " - ASoC: codecs: lpass-rx-macro: add missing CDC_RX_BCL_VBAT_RF_PROC2 to", " default regs values", " - ASoC: fsl_sai: Enable 'FIFO continue on error' FCONT bit", " - arm64: Force position-independent veneers", " - udf: refactor udf_current_aext() to handle error", " - udf: refactor udf_next_aext() to handle error", " - udf: refactor inode_bmap() to handle error", " - udf: fix uninit-value use in udf_get_fileshortad", " - ASoC: qcom: sm8250: add qrb4210-rb2-sndcard compatible string", " - fsnotify: Avoid data race between fsnotify_recalc_mask() and", " fsnotify_object_watched()", " - drm/xe/mcr: Use Xe2_LPM steering tables for Xe2_HPM", " - cifs: Validate content of NFS reparse point buffer", " - LoongArch: Don't crash in stack_top() for tasks without vDSO", " - objpool: fix choosing allocation for percpu slots", " - jfs: Fix sanity check in dbMount", " - tracing/probes: Fix MAX_TRACE_ARGS limit handling", " - tracing: Consider the NULL character when validating the event length", " - xfrm: extract dst lookup parameters into a struct", " - xfrm: respect ip protocols rules criteria when performing dst lookups", " - xfrm: validate new SA's prefixlen using SA family when sel.family is unset", " - netfilter: bpf: must hold reference on net namespace", " - net: pse-pd: Fix out of bound for loop", " - net/sun3_82586: fix potential memory leak in sun3_82586_send_packet()", " - be2net: fix potential memory leak in be_xmit()", " - net: plip: fix break; causing plip to never transmit", " - bnxt_en: replace ptp_lock with irqsave variant", " - octeon_ep: Implement helper for iterating packets in Rx queue", " - octeon_ep: Add SKB allocation failures handling in __octep_oq_process_rx()", " - net: dsa: mv88e6xxx: Fix error when setting port policy on mv88e6393x", " - bpf, arm64: Fix address emission with tag-based KASAN enabled", " - fsl/fman: Save device references taken in mac_probe()", " - fsl/fman: Fix refcount handling of fman-related devices", " - net: wwan: fix global oob in wwan_rtnl_policy", " - net: fix races in netdev_tx_sent_queue()/dev_watchdog()", " - virtio_net: fix integer overflow in stats", " - mlxsw: spectrum_router: fix xa_store() error checking", " - net: usb: usbnet: fix name regression", " - bpf: Preserve param->string when parsing mount options", " - bpf: Add MEM_WRITE attribute", " - bpf: Fix overloading of MEM_UNINIT's meaning", " - bpf: Remove MEM_UNINIT from skb/xdp MTU helpers", " - net/sched: act_api: deny mismatched skip_sw/skip_hw flags for actions", " created by classifiers", " - net: sched: fix use-after-free in taprio_change()", " - net: sched: use RCU read-side critical section in taprio_dump()", " - r8169: avoid unsolicited interrupts", " - posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime()", " - Bluetooth: hci_core: Disable works on hci_unregister_dev", " - Bluetooth: SCO: Fix UAF on sco_sock_timeout", " - Bluetooth: ISO: Fix UAF on iso_sock_timeout", " - bpf,perf: Fix perf_event_detach_bpf_prog error handling", " - bpf: fix do_misc_fixups() for bpf_get_branch_snapshot()", " - net: dsa: microchip: disable EEE for KSZ879x/KSZ877x/KSZ876x", " - net: dsa: mv88e6xxx: group cycle counter coefficients", " - net: dsa: mv88e6xxx: read cycle counter period from hardware", " - net: dsa: mv88e6xxx: support 4000ps cycle counter period", " - bpf: Add the missing BPF_LINK_TYPE invocation for sockmap", " - ASoC: dt-bindings: davinci-mcasp: Fix interrupts property", " - ASoC: dt-bindings: davinci-mcasp: Fix interrupt properties", " - ASoC: loongson: Fix component check failed on FDT systems", " - ASoC: topology: Bump minimal topology ABI version", " - ASoC: max98388: Fix missing increment of variable slot_found", " - ASoC: rsnd: Fix probe failure on HiHope boards due to endpoint parsing", " - PCI: Hold rescan lock while adding devices during host probe", " - fs: pass offset and result to backing_file end_write() callback", " - fuse: update inode size after extending passthrough write", " - ASoC: fsl_micfil: Add a flag to distinguish with different volume control", " types", " - ALSA: firewire-lib: Avoid division by zero in apply_constraint_to_size()", " - fbdev: wm8505fb: select CONFIG_FB_IOMEM_FOPS", " - powercap: dtpm_devfreq: Fix error check against dev_pm_qos_add_request()", " - nfsd: cancel nfsd_shrinker_work using sync mode in nfs4_state_shutdown_net", " - ALSA: hda/realtek: Update default depop procedure", " - smb: client: Handle kstrdup failures for passwords", " - cifs: fix warning when destroy 'cifs_io_request_pool'", " - PCI/pwrctl: Add WCN6855 support", " - PCI/pwrctl: Abandon QCom WCN probe on pre-pwrseq device-trees", " - cpufreq: CPPC: fix perf_to_khz/khz_to_perf conversion exception", " - btrfs: qgroup: set a more sane default value for subtree drop threshold", " - btrfs: clear force-compress on remount when compress mount option is given", " - btrfs: fix passing 0 to ERR_PTR in btrfs_search_dir_index_item()", " - perf/x86/rapl: Fix the energy-pkg event for AMD CPUs", " - btrfs: reject ro->rw reconfiguration if there are hard ro requirements", " - btrfs: zoned: fix zone unusable accounting for freed reserved extent", " - btrfs: fix read corruption due to race with extent map merging", " - drm/amd: Guard against bad data for ATIF ACPI method", " - ACPI: resource: Add LG 16T90SP to irq1_level_low_skip_override[]", " - ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context", " - ACPI: button: Add DMI quirk for Samsung Galaxy Book2 to fix initial lid", " detection issue", " - nilfs2: fix kernel bug due to missing clearing of buffer delay flag", " - fs: don't try and remove empty rbtree node", " - xfs: don't fail repairs on metadata files with no attr fork", " - openat2: explicitly return -E2BIG for (usize > PAGE_SIZE)", " - KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory", " - KVM: arm64: Unregister redistributor for failed vCPU creation", " - KVM: arm64: Fix shift-out-of-bounds bug", " - KVM: arm64: Don't eagerly teardown the vgic on init error", " - firewire: core: fix invalid port index for parent device", " - x86/lam: Disable ADDRESS_MASKING in most cases", " - [Config] updateconfigs to disable ADDRESS_MASKING", " - x86/sev: Ensure that RMP table fixups are reserved", " - ALSA: hda/tas2781: select CRC32 instead of CRC32_SARWATE", " - ALSA: hda/realtek: Add subwoofer quirk for Acer Predator G9-593", " - LoongArch: Get correct cores_per_package for SMT systems", " - LoongArch: Enable IRQ if do_ale() triggered in irq-enabled context", " - LoongArch: Make KASAN usable for variable cpu_vabits", " - xfrm: fix one more kernel-infoleak in algo dumping", " - hv_netvsc: Fix VF namespace also in synthetic NIC NETDEV_REGISTER event", " - md/raid10: fix null ptr dereference in raid10_size()", " - drm/bridge: Fix assignment of the of_node of the parent to aux bridge", " - drm/amd/display: Disable PSR-SU on Parade 08-01 TCON too", " - platform/x86/intel/pmc: Fix pmc_core_iounmap to call iounmap for valid", " addresses", " - fgraph: Fix missing unlock in register_ftrace_graph()", " - fgraph: Change the name of cpuhp state to \"fgraph:online\"", " - net: phy: dp83822: Fix reset pin definitions", " - nfsd: fix race between laundromat and free_stateid", " - drm/amd/display: temp w/a for DP Link Layer compliance", " - ata: libata: Set DID_TIME_OUT for commands that actually timed out", " - ASoC: SOF: Intel: hda-loader: do not wait for HDaudio IOC", " - ASoC: SOF: Intel: hda: Handle prepare without close for non-HDA DAI's", " - ASoC: SOF: Intel: hda: Always clean up link DMA during stop", " - ASoC: SOF: ipc4-topology: Do not set ALH node_id for aggregated DAIs", " - ASoC: dapm: avoid container_of() to get component", " - ASoC: qcom: sc7280: Fix missing Soundwire runtime stream alloc", " - ASoC: qcom: sdm845: add missing soundwire runtime stream alloc", " - ASoC: qcom: Fix NULL Dereference in asoc_qcom_lpass_cpu_platform_probe()", " - Revert \" fs/9p: mitigate inode collisions\"", " - Revert \"fs/9p: remove redundant pointer v9ses\"", " - Revert \"fs/9p: fix uaf in in v9fs_stat2inode_dotl\"", " - Revert \"fs/9p: simplify iget to remove unnecessary paths\"", " - soundwire: intel_ace2x: Send PDI stream number during prepare", " - x86: support user address masking instead of non-speculative conditional", " - x86: fix whitespace in runtime-const assembler output", " - x86: fix user address masking non-canonical speculation issue", " - platform/x86: dell-wmi: Ignore suspend notifications", " - ACPI: PRM: Clean up guid type in struct prm_handler_info", " - ASoC: qcom: Select missing common Soundwire module code on SDM845", " - Linux 6.11.6", "", " * ovs/linuxbridge jobs running on ubuntu jammy broken with latest kernel", " 5.15.0-127.137 (LP: #2091990)", " - netfilter: xtables: fix typo causing some targets not to load on IPv6", "", " * By always inlining _compound_head(), clone() sees 3%+ performance increase", " (LP: #2089327)", " - mm: always inline _compound_head() with", " CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP=y", "", " * Keyboard backlight controls do not work on Asus ROG Zephyrus GA503RM in", " Oracular (LP: #2089113)", " - hid-asus: use hid for brightness control on keyboard", "", " * Random flickering with Intel i915 (Comet Lake and Kaby Lake) on Linux 6.8+", " (LP: #2086587)", " - SAUCE: iommu/intel: disable DMAR for KBL and CML integrated gfx", "", " * Add list of source files to linux-buildinfo (LP: #2086606)", " - [Packaging] Sort build dependencies alphabetically", " - [Packaging] Add list of used source files to buildinfo package", "", " * asus: Fix thermal profile initialization on Lunar Lake (LP: #2085950)", " - platform/x86: asus-wmi: Fix thermal profile initialization", "", " * drm/xe: Fix LNL getting wedged after idling (LP: #2085944)", " - drm/xe/guc/ct: Flush g2h worker in case of g2h response timeout", "", " * UFS: uspi->s_3apb UBSAN: shift-out-of-bounds (LP: #2087853)", " - ufs: ufs_sb_private_info: remove unused s_{2, 3}apb fields", "", " * Mute/mic LEDs don't function on HP EliteBook 645 G10 (LP: #2087983)", " - ALSA: hda/realtek: fix mute/micmute LEDs for a HP EliteBook 645 G10", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152)", " - ALSA: scarlett2: Add error check after retrieving PEQ filter values", " - ALSA: hda/conexant - Fix audio routing for HP EliteOne 1000 G2", " - net: enetc: remove xdp_drops statistic from enetc_xdp_drop()", " - net: enetc: block concurrent XDP transmissions during ring reconfiguration", " - net: enetc: disable Tx BD rings after they are empty", " - net: enetc: disable NAPI after all rings are disabled", " - net: enetc: add missing static descriptor and inline keyword", " - udp: Compute L4 checksum as usual when not segmenting the skb", " - arm64: dts: marvell: cn9130-sr-som: fix cp0 mdio pin numbers", " - arm64: probes: Fix simulate_ldr*_literal()", " - net: macb: Avoid 20s boot delay by skipping MDIO bus registration for fixed-", " link PHY", " - selftests: mptcp: join: test for prohibited MPC to port-based endp", " - fat: fix uninitialized variable", " - mm: khugepaged: fix the arguments order in khugepaged_collapse_file trace", " point", " - net: fec: Move `fec_ptp_read()` to the top of the file", " - net: fec: Remove duplicated code", " - mptcp: prevent MPC handshake on port-based signal endpoints", " - s390/sclp: Deactivate sclp after all its users", " - s390/sclp_vt220: Convert newlines to CRLF instead of LFCR", " - KVM: s390: gaccess: Check if guest address is in memslot", " - KVM: s390: Change virtual to physical address access in diag 0x258 handler", " - x86/cpufeatures: Define X86_FEATURE_AMD_IBPB_RET", " - x86/cpufeatures: Add a IBPB_NO_RET BUG flag", " - x86/entry: Have entry_ibpb() invalidate return predictions", " - x86/bugs: Skip RSB fill at VMEXIT", " - x86/bugs: Do not use UNTRAIN_RET with IBPB on entry", " - fgraph: Use CPU hotplug mechanism to initialize idle shadow stacks", " - Input: xpad - add support for 8BitDo Ultimate 2C Wireless Controller", " - io_uring/sqpoll: close race on waiting for sqring entries", " - selftest: hid: add the missing tests directory", " - Input: xpad - add support for MSI Claw A1M", " - scsi: mpi3mr: Validate SAS port assignments", " - scsi: ufs: core: Fix the issue of ICU failure", " - scsi: ufs: core: Requeue aborted request", " - drm/i915/dp_mst: Handle error during DSC BW overhead/slice calculation", " - drm/i915/dp_mst: Don't require DSC hblank quirk for a non-DSC compatible", " mode", " - drm/xe/xe_sync: initialise ufence.signalled", " - drm/xe/ufence: ufence can be signaled right after wait_woken", " - drm/vmwgfx: Cleanup kms setup without 3d", " - drm/vmwgfx: Handle surface check failure correctly", " - drm/amdgpu/mes: fix issue of writing to the same log buffer from 2 MES pipes", " - drm/amdgpu/smu13: always apply the powersave optimization", " - drm/amdgpu/swsmu: Only force workload setup on init", " - drm/amdgpu: prevent BO_HANDLES error from being overwritten", " - iio: dac: ad5770r: add missing select REGMAP_SPI in Kconfig", " - iio: dac: ltc1660: add missing select REGMAP_SPI in Kconfig", " - iio: dac: stm32-dac-core: add missing select REGMAP_MMIO in Kconfig", " - iio: adc: ti-ads8688: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: hid-sensors: Fix an error handling path in", " _hid_sensor_set_report_latency()", " - iio: light: veml6030: fix ALS sensor resolution", " - iio: light: opt3001: add missing full-scale range value", " - iio: amplifiers: ada4250: add missing select REGMAP_SPI in Kconfig", " - iio: frequency: adf4377: add missing select REMAP_SPI in Kconfig", " - iio: chemical: ens160: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: light: bu27008: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: magnetometer: af8133j: add missing select IIO_(TRIGGERED_)BUFFER in", " Kconfig", " - iio: resolver: ad2s1210 add missing select REGMAP in Kconfig", " - iio: pressure: bm1390: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: dac: ad5766: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: proximity: mb1232: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: dac: ad3552r: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: adc: ti-lmp92064: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: adc: ti-lmp92064: add missing select REGMAP_SPI in Kconfig", " - iio: adc: ti-ads124s08: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: resolver: ad2s1210: add missing select (TRIGGERED_)BUFFER in Kconfig", " - iio: adc: ad7944: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: accel: kx022a: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - Bluetooth: Remove debugfs directory on module init failure", " - Bluetooth: btusb: Fix not being able to reconnect after suspend", " - Bluetooth: btusb: Fix regression with fake CSR controllers 0a12:0001", " - xhci: Fix incorrect stream context type macro", " - xhci: Mitigate failed set dequeue pointer commands", " - USB: serial: option: add support for Quectel EG916Q-GL", " - USB: serial: option: add Telit FN920C04 MBIM compositions", " - usb: typec: qcom-pmic-typec: fix sink status being overwritten with RP_DEF", " - usb: gadget: f_uac2: fix return value for UAC2_ATTRIBUTE_STRING store", " - usb: dwc3: Wait for EndXfer completion before restoring GUSB2PHYCFG", " - usb: dwc3: core: Fix system suspend on TI AM62 platforms", " - misc: microchip: pci1xxxx: add support for NVMEM_DEVID_AUTO for EEPROM", " device", " - misc: microchip: pci1xxxx: add support for NVMEM_DEVID_AUTO for OTP device", " - serial: imx: Update mctrl old_status on RTSD interrupt", " - x86/resctrl: Annotate get_mem_config() functions as __init", " - x86/CPU/AMD: Only apply Zenbleed fix for Zen2 during late microcode load", " - x86/entry_32: Do not clobber user EFLAGS.ZF", " - irqchip/sifive-plic: Unmask interrupt in plic_irq_enable()", " - irqchip/sifive-plic: Return error code on failure", " - serial: qcom-geni: fix polled console initialisation", " - serial: qcom-geni: revert broken hibernation support", " - serial: qcom-geni: fix shutdown race", " - serial: qcom-geni: fix dma rx cancellation", " - serial: qcom-geni: fix receiver enable", " - mm: vmscan.c: fix OOM on swap stress test", " - ALSA: hda/conexant - Use cached pin control for Node 0x1d on HP EliteOne", " 1000 G2", " - Linux 6.11.5", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50192", " - irqchip/gic-v4: Don't allow a VMOVP on a dying VPE", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50069", " - pinctrl: apple: check devm_kasprintf() returned value", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50070", " - pinctrl: stm32: check devm_kasprintf() returned value", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50196", " - pinctrl: ocelot: fix system hang on level based interrupts", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50197", " - pinctrl: intel: platform: fix error path in device_for_each_child_node()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50071", " - pinctrl: nuvoton: fix a double free in ma35_pinctrl_dt_node_to_map_func()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50072", " - x86/bugs: Use code segment selector for VERW operand", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50073", " - tty: n_gsm: Fix use-after-free in gsm_cleanup_mux", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50193", " - x86/entry_32: Clear CPU buffers after register restore in NMI return", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50074", " - parport: Proper fix for array out-of-bounds access", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50100", " - USB: gadget: dummy-hcd: Fix \"task hung\" problem", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50075", " - xhci: tegra: fix checked USB2 port number", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50076", " - vt: prevent kernel-infoleak in con_font_get()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50077", " - Bluetooth: ISO: Fix multiple init when debugfs is disabled", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50078", " - Bluetooth: Call iso_exit() on module unload", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50198", " - iio: light: veml6030: fix IIO device retrieval from embedded device", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50201", " - drm/radeon: Fix encoder->possible_clones", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50098", " - scsi: ufs: core: Set SDEV_OFFLINE when UFS is shut down", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50079", " - io_uring/sqpoll: ensure task state is TASK_RUNNING when running task_work", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50080", " - ublk: don't allow user copy for unprivileged device", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50081", " - blk-mq: setup queue ->tag_set before initializing hctx", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50082", " - blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50101", " - iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI devices", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50083", " - tcp: fix mptcp DSS corruption due to large pmtu xmit", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50068", " - mm/damon/tests/sysfs-kunit.h: fix memory leak in", " damon_sysfs_test_add_targets()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50199", " - mm/swapfile: skip HugeTLB pages for unuse_vma", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50066", " - mm/mremap: fix move_normal_pmd/retract_page_tables race", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50202", " - nilfs2: propagate directory read errors from nilfs_find_entry()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50200", " - maple_tree: correct tree corruption on spanning store", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50084", " - net: microchip: vcap api: Fix memory leaks in vcap_api_encode_rule_test()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50194", " - arm64: probes: Fix uprobes for big-endian kernels", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50099", " - arm64: probes: Remove broken LDR (literal) uprobe support", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50195", " - posix-clock: Fix missing timespec64 check in pc_clock_settime()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50085", " - mptcp: pm: fix UaF read in mptcp_pm_nl_rm_addr_or_subflow", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50086", " - ksmbd: fix user-after-free from session log off", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50087", " - btrfs: fix uninitialized pointer free on read_alloc_one_name() error", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50088", " - btrfs: fix uninitialized pointer free in add_inode_ref()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068)", " - net: fec: don't save PTP state if PTP is unsupported", " - fs/ntfs3: Do not call file_modified if collapse range failed", " - fs/ntfs3: Optimize large writes into sparse file", " - fs/ntfs3: Fix sparse warning for bigendian", " - fs/ntfs3: Fix sparse warning in ni_fiemap", " - fs/ntfs3: Refactor enum_rstbl to suppress static checker", " - vdpa/octeon_ep: Fix format specifier for pointers in debug messages", " - virtio_console: fix misc probe bugs", " - perf vdso: Missed put on 32-bit dsos", " - perf build: Fix static compilation error when libdw is not installed", " - perf build: Fix build feature-dwarf_getlocations fail for old libdw", " - zram: don't free statically defined names", " - bpf: Call the missed btf_record_free() when map creation fails", " - selftests/bpf: Fix ARG_PTR_TO_LONG {half-,}uninitialized test", " - bpf: Check percpu map value size first", " - s390/facility: Disable compile time optimization for decompressor code", " - s390/mm: Add cond_resched() to cmm_alloc/free_pages()", " - bpf, x64: Fix a jit convergence issue", " - ext4: nested locking for xattr inode", " - s390/cpum_sf: Remove WARN_ON_ONCE statements", " - s390/traps: Handle early warnings gracefully", " - ktest.pl: Avoid false positives with grub2 skip regex", " - soundwire: intel_bus_common: enable interrupts before exiting reset", " - PCI: Add function 0 DMA alias quirk for Glenfly Arise chip", " - clk: bcm: bcm53573: fix OF node leak in init", " - PCI: Add ACS quirk for Qualcomm SA8775P", " - i2c: i801: Use a different adapter-name for IDF adapters", " - PCI: Mark Creative Labs EMU20k2 INTx masking as broken", " - RISC-V: Don't have MAX_PHYSMEM_BITS exceed phys_addr_t", " - mfd: intel_soc_pmic_chtwc: Make Lenovo Yoga Tab 3 X90F DMI match less strict", " - mfd: intel-lpss: Add Intel Panther Lake LPSS PCI IDs", " - riscv: Omit optimized string routines when using KASAN", " - riscv: avoid Imbalance in RAS", " - RDMA/mlx5: Enforce umem boundaries for explicit ODP page faults", " - PCI: qcom: Disable mirroring of DBI and iATU register space in BAR region", " - PCI: endpoint: Assign PCI domain number for endpoint controllers", " - soundwire: cadence: re-check Peripheral status with delayed_work", " - riscv/kexec_file: Fix relocation type R_RISCV_ADD16 and R_RISCV_SUB16", " unknown", " - media: videobuf2-core: clear memory related fields in", " __vb2_plane_dmabuf_put()", " - remoteproc: imx_rproc: Use imx specific hook for find_loaded_rsc_table", " - usb: chipidea: udc: enable suspend interrupt after usb reset", " - usb: dwc2: Adjust the timing of USB Driver Interrupt Registration in the", " Crashkernel Scenario", " - xhci: dbc: Fix STALL transfer event handling", " - usb: host: xhci-plat: Parse xhci-missing_cas_quirk and apply quirk", " - comedi: ni_routing: tools: Check when the file could not be opened", " - LoongArch: Fix memleak in pci_acpi_scan_root()", " - netfilter: nf_nat: don't try nat source port reallocation for reverse dir", " clash", " - netfilter: nf_reject: Fix build warning when CONFIG_BRIDGE_NETFILTER=n", " - tools/iio: Add memory allocation failure check for trigger_name", " - staging: vme_user: added bound check to geoid", " - driver core: bus: Return -EIO instead of 0 when show/store invalid bus", " attribute", " - scsi: lpfc: Add ELS_RSP cmd to the list of WQEs to flush in", " lpfc_els_flush_cmd()", " - scsi: lpfc: Revise TRACE_EVENT log flag severities from KERN_ERR to", " KERN_WARNING", " - NFSD: Mark filecache \"down\" if init fails", " - nfsd: nfsd_destroy_serv() must call svc_destroy() even if nfsd_startup_net()", " failed", " - ice: set correct dst VSI in only LAN filters", " - ice: clear port vlan config during reset", " - ice: disallow DPLL_PIN_STATE_SELECTABLE for dpll output pins", " - ice: fix VLAN replay after reset", " - SUNRPC: Fix integer overflow in decode_rc_list()", " - net: phy: aquantia: AQR115c fix up PMA capabilities", " - net: phy: aquantia: remove usage of phy_set_max_speed", " - tcp: fix to allow timestamp undo if no retransmits were sent", " - tcp: fix tcp_enter_recovery() to zero retrans_stamp when it's safe", " - tcp: fix TFO SYN_RECV to not zero retrans_stamp with retransmits out", " - rxrpc: Fix uninitialised variable in rxrpc_send_data()", " - net: dsa: sja1105: fix reception from VLAN-unaware bridges", " - selftests: net: no_forwarding: fix VID for $swp2 in one_bridge_two_pvids()", " test", " - net: pse-pd: Fix enabled status mismatch", " - Bluetooth: btusb: Don't fail external suspend requests", " - net: phy: bcm84881: Fix some error handling paths", " - net: ethernet: adi: adin1110: Fix some error handling path in", " adin1110_read_fifo()", " - net: dsa: b53: fix jumbo frame mtu check", " - net: dsa: b53: fix max MTU for 1g switches", " - net: dsa: b53: fix max MTU for BCM5325/BCM5365", " - net: dsa: b53: allow lower MTUs on BCM5325/5365", " - net: dsa: b53: fix jumbo frames on 10/100 ports", " - drm/nouveau: pass cli to nouveau_channel_new() instead of drm+device", " - nouveau/dmem: Fix privileged error in copy engine channel", " - gpio: aspeed: Add the flush write to ensure the write complete.", " - gpio: aspeed: Use devm_clk api to manage clock source", " - x86/xen: mark boot CPU of PV guest in MSR_IA32_APICBASE", " - powercap: intel_rapl_tpmi: Ignore minor version change", " - ice: Fix entering Safe Mode", " - ice: Fix netif_is_ice() in Safe Mode", " - ice: Flush FDB entries before reset", " - drm/xe: Restore GT freq on GSC load error", " - drm/xe: Make wedged_mode debugfs writable", " - net: ibm: emac: mal: fix wrong goto", " - net: ti: icssg-prueth: Fix race condition for VLAN table access", " - btrfs: zoned: fix missing RCU locking in error message when loading zone", " info", " - sctp: ensure sk_state is set to CLOSED if hashing fails in sctp_listen_start", " - netfilter: fib: check correct rtable in vrf setups", " - net: ibm: emac: mal: add dcr_unmap to _remove", " - net: dsa: refuse cross-chip mirroring operations", " - rtnetlink: Add bulk registration helpers for rtnetlink message handlers.", " - vxlan: Handle error of rtnl_register_module().", " - bridge: Handle error of rtnl_register_module().", " - mctp: Handle error of rtnl_register_module().", " - mpls: Handle error of rtnl_register_module().", " - phonet: Handle error of rtnl_register_module().", " - rcu/nocb: Fix rcuog wake-up from offline softirq", " - HID: multitouch: Add support for lenovo Y9000P Touchpad", " - hwmon: intel-m10-bmc-hwmon: relabel Columbiaville to CVL Die Temperature", " - hwmon: (tmp513) Add missing dependency on REGMAP_I2C", " - hwmon: (mc34vr500) Add missing dependency on REGMAP_I2C", " - hwmon: (adm9240) Add missing dependency on REGMAP_I2C", " - hwmon: (adt7470) Add missing dependency on REGMAP_I2C", " - hwmon: (ltc2991) Add missing dependency on REGMAP_I2C", " - HID: plantronics: Workaround for an unexcepted opposite volume key", " - HID: wacom: Hardcode (non-inverted) AES pens as BTN_TOOL_PEN", " - Revert \"usb: yurex: Replace snprintf() with the safer scnprintf() variant\"", " - usb: dwc3: core: Stop processing of pending events if controller is halted", " - usb: xhci: Fix problem with xhci resume from suspend", " - usb: storage: ignore bogus device raised by JieLi BR21 USB sound chip", " - usb: dwc3: re-enable runtime PM after failed resume", " - usb: gadget: core: force synchronous registration", " - hid: intel-ish-hid: Fix uninitialized variable 'rv' in", " ish_fw_xfer_direct_dma", " - ACPI: resource: Make Asus ExpertBook B2402 matches cover more models", " - ACPI: resource: Make Asus ExpertBook B2502 matches cover more models", " - drm/amdgpu: partially revert powerplay `__counted_by` changes", " - drm/amd/display: Clear update flags after update has been applied", " - drm/amdkfd: Fix an eviction fence leak", " - drm/amd/display: fix hibernate entry for DCN35+", " - drm/xe/guc_submit: fix xa_store() error checking", " - drm/i915/hdcp: fix connector refcounting", " - drm/xe/ct: fix xa_store() error checking", " - scsi: ufs: Use pre-calculated offsets in ufshcd_init_lrb()", " - Revert \"mmc: mvsdio: Use sg_miter for PIO\"", " - mmc: sdhci-of-dwcmshc: Prevent stale command interrupt handling", " - mptcp: fallback when MPTCP opts are dropped after 1st data", " - ata: libata: avoid superfluous disk spin down + spin up during hibernation", " - OPP: fix error code in dev_pm_opp_set_config()", " - net: dsa: lan9303: ensure chip reset and wait for READY status", " - net: phy: realtek: Fix MMD access on RTL8126A-integrated PHY", " - mptcp: pm: do not remove closing subflows", " - powercap: intel_rapl_tpmi: Fix bogus register reading", " - selftests/mm: fix incorrect buffer->mirror size in hmm2 double_map test", " - selftests/rseq: Fix mm_cid test failure", " - btrfs: split remaining space to discard in chunks", " - btrfs: add cancellation points to trim loops", " - PM: domains: Fix alloc/free in dev_pm_domain_attach|detach_list()", " - idpf: use actual mbx receive payload length", " - fs/proc/kcore.c: allow translation of physical memory addresses", " - PCI: Pass domain number to pci_bus_release_domain_nr() explicitly", " - io_uring/rw: fix cflags posting for single issue multishot read", " - Linux 6.11.4", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50182", " - secretmem: disable memfd_secret() if arch cannot set direct map", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50019", " - kthread: unpark only parked kthread", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50096", " - nouveau/dmem: Fix vulnerability in migrate_to_ram upon copy error", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50020", " - ice: Fix improper handling of refcount in ice_sriov_set_msix_vec_count()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50021", " - ice: Fix improper handling of refcount in ice_dpll_init_rclk_pins()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50022", " - device-dax: correct pgoff align in dax_set_mapping()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50185", " - mptcp: handle consistently DSS corruption", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50023", " - net: phy: Remove LED entry from LEDs list on unregister", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50024", " - net: Fix an unsafe loop on the list", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50186", " - net: explicitly clear the sk pointer, when pf->create fails", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50025", " - scsi: fnic: Move flush_work initialization out of if block", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50026", " - scsi: wd33c93: Don't use stale scsi_pointer value", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50027", " - thermal: core: Free tzp copy along with the thermal zone", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50028", " - thermal: core: Reference count the zone in thermal_zone_get_by_id()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50029", " - Bluetooth: hci_conn: Fix UAF in hci_enhanced_setup_sync", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50030", " - drm/xe/ct: prevent UAF in send_recv()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50187", " - drm/vc4: Stop the active perfmon before being destroyed", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50031", " - drm/v3d: Stop the active perfmon before being destroyed", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50189", " - HID: amd_sfh: Switch to device-managed dmam_alloc_coherent()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50033", " - slip: make slhc_remember() more robust against malicious packets", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50034", " - net/smc: fix lacks of icsk_syn_mss with IPPROTO_SMC", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50035", " - ppp: fix ppp_async_encode() illegal access", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50036", " - net: do not delay dst_entries_add() in dst_release()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50037", " - drm/fbdev-dma: Only cleanup deferred I/O if necessary", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50092", " - net: netconsole: fix wrong warning", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50038", " - netfilter: xtables: avoid NFPROTO_UNSPEC where needed", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50039", " - net/sched: accept TCA_STAB only for root qdisc", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50040", " - igb: Do not bring the device up after non-fatal error", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50041", " - i40e: Fix macvlan leak by synchronizing access to mac_filter_hash", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50042", " - ice: Fix increasing MSI-X on VF", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50093", " - thermal: intel: int340x: processor: Fix warning during module unload", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50043", " - nfsd: fix possible badness in FREE_STATEID", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50044", " - Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50045", " - netfilter: br_netfilter: fix panic with metadata_dst skb", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50094", " - sfc: Don't invoke xdp_do_flush() from netpoll.", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50188", " - net: phy: dp83869: fix memory corruption when enabling fiber", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50046", " - NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50190", " - ice: fix memleak in ice_init_tx_topology()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50180", " - fbdev: sisfb: Fix strbuf array overflow", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50047", " - smb: client: fix UAF in async decryption", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50048", " - fbcon: Fix a NULL pointer dereference issue in fbcon_putcs", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50049", " - drm/amd/display: Check null pointer before dereferencing se", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50090", " - drm/xe/oa: Fix overflow in oa batch buffer", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50183", " - scsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV", " instance", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50055", " - driver core: bus: Fix double free in driver API bus_register()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50091", " - dm vdo: don't refer to dedupe_context after releasing it", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50056", " - usb: gadget: uvc: Fix ERR_PTR dereference in uvc_v4l2.c", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50184", " - virtio_pmem: Check device status before requesting flush", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50057", " - usb: typec: tipd: Free IRQ only if it was requested before", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50058", " - serial: protect uart_port_dtr_rts() in uart_shutdown() too", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50181", " - clk: imx: Remove CLK_SET_PARENT_GATE for DRAM mux for i.MX7D", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50059", " - ntb: ntb_hw_switchtec: Fix use after free vulnerability in", " switchtec_ntb_remove due to race condition", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50060", " - io_uring: check if we need to reschedule during overflow flush", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50061", " - i3c: master: cdns: Fix use after free vulnerability in cdns_i3c_master", " Driver Due to Race Condition", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50062", " - RDMA/rtrs-srv: Avoid null pointer deref during path establishment", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50095", " - RDMA/mad: Improve handling of timed out WRs of mad agent", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50063", " - bpf: Prevent tail call between progs attached to different hooks", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50191", " - ext4: don't set SB_RDONLY after filesystem errors", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50064", " - zram: free secondary algorithms names", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50065", " - ntfs3: Change to non-blocking allocation in ntfs_d_hash", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50089", " - unicode: Don't special case ignorable code points", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052)", " - jump_label: Fix static_key_slow_dec() yet again", " - scsi: st: Fix input/output error on empty drive reset", " - scsi: pm8001: Do not overwrite PCI queue mapping", " - drm/i915/psr: Do not wait for PSR being idle on on Panel Replay", " - drm/i915/display: BMG supports UHBR13.5", " - drm/i915/dp: Fix AUX IO power enabling for eDP PSR", " - drm/amdgpu: Fix get each xcp macro", " - drm/amd/display: handle nulled pipe context in DCE110's set_drr()", " - ksmbd: fix warning: comparison of distinct pointer types lacks a cast", " - mailbox: ARM_MHU_V3 should depend on ARM64", " - [Config] updateconfigs for ARM_MHU_V3", " - mailbox: rockchip: fix a typo in module autoloading", " - ceph: fix a memory leak on cap_auths in MDS client", " - drm/i915/dp: Fix colorimetry detection", " - ieee802154: Fix build error", " - net: sparx5: Fix invalid timestamps", " - net/mlx5: Added cond_resched() to crdump collection", " - net/mlx5e: SHAMPO, Fix overflow of hd_per_wq", " - netfilter: uapi: NFTA_FLOWTABLE_HOOK is NLA_NESTED", " - net: ieee802154: mcr20a: Use IRQF_NO_AUTOEN flag in request_irq()", " - net: wwan: qcom_bam_dmux: Fix missing pm_runtime_disable()", " - selftests: netfilter: Fix nft_audit.sh for newer nft binaries", " - selftests: netfilter: Add missing return value", " - Bluetooth: btmrvl: Use IRQF_NO_AUTOEN flag in request_irq()", " - afs: Fix missing wire-up of afs_retry_request()", " - net: Add netif_get_gro_max_size helper for GRO", " - net: Fix gso_features_check to check for both dev->gso_{ipv4_,}max_size", " - net: fec: Restart PPS after link state change", " - net: fec: Reload PTP registers after link-state change", " - net: stmmac: dwmac4: extend timeout for VLAN Tag register busy bit check", " - ipv4: ip_gre: Fix drops of small packets in ipgre_xmit", " - netfs: Fix missing wakeup after issuing writes", " - net: phy: realtek: Check the index value in led_hw_control_get", " - bridge: mcast: Fail MDB get request on empty entry", " - iomap: constrain the file range passed to iomap_file_unshare", " - dt-bindings: net: xlnx,axi-ethernet: Add missing reg minItems", " - ASoC: topology: Fix incorrect addressing assignments", " - ASoC: atmel: mchp-pdmc: Skip ALSA restoration if substream runtime is", " uninitialized", " - drm/connector: hdmi: Fix writing Dynamic Range Mastering infoframes", " - io_uring: fix memory leak when cache init fail", " - rust: kbuild: split up helpers.c", " - rust: kbuild: auto generate helper exports", " - rust: mutex: fix __mutex_init() usage in case of PREEMPT_RT", " - ALSA: mixer_oss: Remove some incorrect kfree_const() usages", " - ALSA: hda/realtek: Fix the push button function for the ALC257", " - cifs: Remove intermediate object of failed create reparse call", " - drm/panthor: Lock the VM resv before calling drm_gpuvm_bo_obtain_prealloc()", " - ALSA: hda/generic: Unconditionally prefer preferred_dacs pairs", " - ASoC: imx-card: Set card.owner to avoid a warning calltrace if SND=m", " - drm/xe: Restore pci state upon resume", " - drm/xe: Resume TDR after GT reset", " - cifs: Do not convert delimiter when parsing NFS-style symlinks", " - tools/rtla: Fix installation from out-of-tree build", " - ALSA: gus: Fix some error handling paths related to get_bpos() usage", " - ALSA: hda/conexant: Fix conflicting quirk for System76 Pangolin", " - drm/amd/display: Disable replay if VRR capability is false", " - drm/amd/display: Fix VRR cannot enable", " - drm/amd/display: Re-enable panel replay feature", " - e1000e: avoid failing the system during pm_suspend", " - wifi: ath9k: fix possible integer overflow in ath9k_get_et_stats()", " - crypto: x86/sha256 - Add parentheses around macros' single arguments", " - crypto: octeontx - Fix authenc setkey", " - crypto: octeontx2 - Fix authenc setkey", " - ice: Adjust over allocation of memory in ice_sched_add_root_node() and", " ice_sched_add_node()", " - wifi: iwlwifi: mvm: Fix a race in scan abort flow", " - wifi: iwlwifi: mvm: drop wrong STA selection in TX", " - net: hisilicon: hip04: fix OF node leak in probe()", " - net: hisilicon: hns_dsaf_mac: fix OF node leak in hns_mac_get_info()", " - net: hisilicon: hns_mdio: fix OF node leak in probe()", " - ACPICA: Fix memory leak if acpi_ps_get_next_namepath() fails", " - ACPICA: Fix memory leak if acpi_ps_get_next_field() fails", " - ACPI: resource: Skip IRQ override on Asus Vivobook Go E1404GAB", " - wifi: mt76: mt7915: disable tx worker during tx BA session enable/disable", " - net: sched: consistently use rcu_replace_pointer() in taprio_change()", " - Bluetooth: btusb: Add Realtek RTL8852C support ID 0x0489:0xe122", " - Bluetooth: btrtl: Set msft ext address filter quirk for RTL8852B", " - ACPI: video: Add force_vendor quirk for Panasonic Toughbook CF-18", " - ACPI: CPPC: Add support for setting EPP register in FFH", " - wifi: rtw88: select WANT_DEV_COREDUMP", " - l2tp: free sessions using rcu", " - l2tp: use rcu list add/del when updating lists", " - ACPI: EC: Do not release locks during operation region accesses", " - net: skbuff: sprinkle more __GFP_NOWARN on ingress allocs", " - net: mvpp2: Increase size of queue_name buffer", " - bnxt_en: Extend maximum length of version string by 1 byte", " - ipv4: Check !in_dev earlier for ioctl(SIOCSIFADDR).", " - wifi: rtw89: correct base HT rate mask for firmware", " - netfilter: nf_tables: do not remove elements if set backend implements", " .abort", " - ipv4: Mask upper DSCP bits and ECN bits in NETLINK_FIB_LOOKUP family", " - nvme-keyring: restrict match length for version '1' identifiers", " - nvme-tcp: sanitize TLS key handling", " - nvme-tcp: check for invalidated or revoked key", " - net: atlantic: Avoid warning about potential string truncation", " - crypto: simd - Do not call crypto_alloc_tfm during registration", " - netpoll: Ensure clean state on setup failures", " - tcp: avoid reusing FIN_WAIT2 when trying to find port in connect() process", " - wifi: iwlwifi: mvm: use correct key iteration", " - wifi: iwlwifi: allow only CN mcc from WRDD", " - virt: sev-guest: Ensure the SNP guest messages do not exceed a page", " - wifi: mac80211: fix RCU list iterations", " - ACPICA: iasl: handle empty connection_node", " - proc: add config & param to block forcing mem writes", " - [Config] updateconfigs to select PROC_MEM_ALWAYS_FORCE", " - vfs: use RCU in ilookup", " - drivers/perf: arm_spe: Use perf_allow_kernel() for permissions", " - nvme: fix metadata handling in nvme-passthrough", " - can: netlink: avoid call to do_set_data_bittiming callback with stale", " can_priv::ctrlmode", " - netdev-genl: Set extack and fix error on napi-get", " - wifi: wilc1000: Do not operate uninitialized hardware during suspend/resume", " - arm64: trans_pgd: mark PTEs entries as valid to avoid dead kexec()", " - net: phy: Check for read errors in SIOCGMIIREG", " - x86/bugs: Add missing NO_SSB flag", " - x86/bugs: Fix handling when SRSO mitigation is disabled", " - crypto: hisilicon - fix missed error branch", " - wifi: mt76: mt7915: add dummy HW offload of IEEE 802.11 fragmentation", " - wifi: mt76: mt7915: hold dev->mt76.mutex while disabling tx worker", " - netfs: Cancel dirty folios that have no storage destination", " - nfp: Use IRQF_NO_AUTOEN flag in request_irq()", " - ALSA: usb-audio: Add input value sanity checks for standard types", " - x86/apic: Remove logical destination mode for 64-bit", " - ALSA: usb-audio: Define macros for quirk table entries", " - ALSA: usb-audio: Replace complex quirk lines with macros", " - ALSA: usb-audio: Add quirk for RME Digiface USB", " - ALSA: usb-audio: Add mixer quirk for RME Digiface USB", " - ALSA: hda/realtek: Refactor and simplify Samsung Galaxy Book init", " - ALSA: usb-audio: Add logitech Audio profile quirk", " - ASoC: codecs: wsa883x: Handle reading version failure", " - ALSA: control: Take power_ref lock primarily", " - tools/x86/kcpuid: Protect against faulty \"max subleaf\" values", " - x86/pkeys: Add PKRU as a parameter in signal handling functions", " - x86/pkeys: Restore altstack access in sigreturn()", " - x86/kexec: Add EFI config table identity mapping for kexec kernel", " - ALSA: hdsp: Break infinite MIDI input flush loop", " - tools/nolibc: powerpc: limit stack-protector workaround to GCC", " - selftests/nolibc: avoid passing NULL to printf(\"%s\")", " - x86/syscall: Avoid memcpy() for ia32 syscall_get_arguments()", " - ASoC: Intel: boards: always check the result of", " acpi_dev_get_first_match_dev()", " - hwmon: (nct6775) add G15CF to ASUS WMI monitoring list", " - pmdomain: core: Don't hold the genpd-lock when calling dev_pm_domain_set()", " - pmdomain: core: Use dev_name() instead of kobject_get_path() in debugfs", " - rcuscale: Provide clear error when async specified without primitives", " - power: reset: brcmstb: Do not go into infinite loop if reset fails", " - iommu/arm-smmu-v3: Match Stall behaviour for S2", " - iommu/vt-d: Always reserve a domain ID for identity setup", " - iommu/vt-d: Unconditionally flush device TLB for pasid table updates", " - iommu/arm-smmu-v3: Do not use devm for the cd table allocations", " - drm/amdgpu: disallow multiple BO_HANDLES chunks in one submit", " - drm/amd/display: Use gpuvm_min_page_size_kbytes for DML2 surfaces", " - ata: pata_serverworks: Do not use the term blacklist", " - ata: sata_sil: Rename sil_blacklist to sil_quirks", " - selftests/bpf: fix uprobe.path leak in bpf_testmod", " - scsi: smartpqi: Add new controller PCI IDs", " - HID: Ignore battery for all ELAN I2C-HID devices", " - drm/amd/display: Underflow Seen on DCN401 eGPU", " - drm/xe: Name and document Wa_14019789679", " - jfs: UBSAN: shift-out-of-bounds in dbFindBits", " - scsi: smartpqi: correct stream detection", " - scsi: smartpqi: add new controller PCI IDs", " - drm/amdgpu: add raven1 gfxoff quirk", " - drm/amdgpu: enable gfxoff quirk on HP 705G4", " - drm/amdkfd: Fix resource leak in criu restore queue", " - HID: multitouch: Add support for Thinkpad X12 Gen 2 Kbd Portfolio", " - platform/x86: touchscreen_dmi: add nanote-next quirk", " - platform/x86/amd: pmf: Add quirk for TUF Gaming A14", " - drm/stm: ltdc: reset plane transparency after plane disable", " - drm/amdgpu/gfx12: properly handle error ints on all pipes", " - drm/amdgpu/gfx9: properly handle error ints on all pipes", " - drm/amd/display: Fix possible overflow in integer multiplication", " - drm/printer: Allow NULL data in devcoredump printer", " - perf,x86: avoid missing caller address in stack traces captured in uprobe", " - scsi: aacraid: Rearrange order of struct aac_srb_unit", " - scsi: lpfc: Fix unsolicited FLOGI kref imbalance when in direct attached", " topology", " - scsi: lpfc: Update PRLO handling in direct attached topology", " - drm/amd/display: Force enable 3DLUT DMA check for dcn401 in DML", " - drm/amdgpu: fix unchecked return value warning for amdgpu_gfx", " - drm/amdgpu: fix unchecked return value warning for amdgpu_atombios", " - perf: Fix event_function_call() locking", " - scsi: NCR5380: Initialize buffer for MSG IN and STATUS transfers", " - drm/radeon/r100: Handle unknown family in r100_cp_init_microcode()", " - drm/amd/display: Unlock Pipes Based On DET Allocation", " - drm/amdgpu: fix ptr check warning in gfx9 ip_dump", " - drm/amdgpu: fix ptr check warning in gfx10 ip_dump", " - drm/amdgpu: fix ptr check warning in gfx11 ip_dump", " - drm/amdgpu: Block MMR_READ IOCTL in reset", " - drm/amdgpu/gfx9: use rlc safe mode for soft recovery", " - drm/amdgpu/gfx11: enter safe mode before touching CP_INT_CNTL", " - drm/xe: Use topology to determine page fault queue size", " - drm/amdkfd: Check int source id for utcl2 poison event", " - of/irq: Refer to actual buffer size in of_irq_parse_one()", " - drm/amd/display: guard write a 0 post_divider value to HW", " - powerpc/pseries: Use correct data types from pseries_hp_errorlog struct", " - ovl: fsync after metadata copy-up", " - drm/amdgpu/gfx12: use rlc safe mode for soft recovery", " - drm/amdgpu/gfx11: use rlc safe mode for soft recovery", " - drm/amdgpu/gfx10: use rlc safe mode for soft recovery", " - platform/x86: lenovo-ymc: Ignore the 0x0 state", " - tools/hv: Add memory allocation check in hv_fcopy_start", " - HID: i2c-hid: ensure various commands do not interfere with each other", " - platform/mellanox: mlxbf-pmc: fix lockdep warning", " - platform/x86: x86-android-tablets: Adjust Xiaomi Pad 2 bottom bezel touch", " buttons LED", " - bpf: Make the pointer returned by iter next method valid", " - ext4: ext4_search_dir should return a proper error", " - bpftool: Fix undefined behavior caused by shifting into the sign bit", " - iomap: handle a post-direct I/O invalidate race in", " iomap_write_delalloc_release", " - EINJ, CXL: Fix CXL device SBDF calculation", " - spi: spi-imx: Fix pm_runtime_set_suspended() with runtime pm enabled", " - spi: spi-cadence: Fix pm_runtime_set_suspended() with runtime pm enabled", " - spi: spi-cadence: Fix missing spi_controller_is_target() check", " - selftest: hid: add missing run-hid-tools-tests.sh", " - spi: s3c64xx: fix timeout counters in flush_fifo", " - kselftest/devices/probe: Fix SyntaxWarning in regex strings for Python3", " - selftests: breakpoints: use remaining time to check if suspend succeed", " - accel/ivpu: Add missing MODULE_FIRMWARE metadata", " - spi: rpc-if: Add missing MODULE_DEVICE_TABLE", " - ALSA: control: Fix power_ref lock order for compat code, too", " - perf callchain: Fix stitch LBR memory leaks", " - perf: Really fix event_function_call() locking", " - drm/xe: fixup xe_alloc_pf_queue", " - drm/xe: Fix memory leak on xe_alloc_pf_queue failure", " - selftests: vDSO: fix vDSO name for powerpc", " - selftests: vDSO: fix vdso_config for powerpc", " - selftests: vDSO: fix vDSO symbols lookup for powerpc64", " - ext4: fix error message when rejecting the default hash", " - selftests/mm: fix charge_reserved_hugetlb.sh test", " - nvme-tcp: fix link failure for TCP auth", " - f2fs: add write priority option based on zone UFS", " - powerpc/vdso: Fix VDSO data access when running in a non-root time namespace", " - selftests: vDSO: fix ELF hash table entry size for s390x", " - selftests: vDSO: fix vdso_config for s390", " - f2fs: make BG GC more aggressive for zoned devices", " - f2fs: introduce migration_window_granularity", " - f2fs: increase BG GC migration window granularity when boosted for zoned", " devices", " - f2fs: do FG_GC when GC boosting is required for zoned devices", " - f2fs: forcibly migrate to secure space for zoned device file pinning", " - Revert \"ALSA: hda: Conditionally use snooping for AMD HDMI\"", " - KVM: arm64: Fix kvm_has_feat*() handling of negative features", " - i2c: qcom-geni: Use IRQF_NO_AUTOEN flag in request_irq()", " - i2c: xiic: Wait for TX empty to avoid missed TX NAKs", " - i2c: core: Lock address during client device instantiation", " - i2c: xiic: Fix pm_runtime_set_suspended() with runtime pm enabled", " - i2c: designware: fix controller is holding SCL low while ENABLE bit is", " disabled", " - i2c: synquacer: Deal with optional PCLK correctly", " - rust: sync: require `T: Sync` for `LockedBy::access`", " - ovl: fail if trusted xattrs are needed but caller lacks permission", " - firmware: tegra: bpmp: Drop unused mbox_client_to_bpmp()", " - memory: tegra186-emc: drop unused to_tegra186_emc()", " - dt-bindings: clock: exynos7885: Fix duplicated binding", " - spi: bcm63xx: Fix module autoloading", " - spi: bcm63xx: Fix missing pm_runtime_disable()", " - power: supply: hwmon: Fix missing temp1_max_alarm attribute", " - power: supply: Drop use_cnt check from power_supply_property_is_writeable()", " - perf/core: Fix small negative period being ignored", " - drm/v3d: Prevent out of bounds access in performance query extensions", " - parisc: Fix itlb miss handler for 64-bit programs", " - drm/mediatek: ovl_adaptor: Add missing of_node_put()", " - drm: Consistently use struct drm_mode_rect for FB_DAMAGE_CLIPS", " - ALSA: hda/tas2781: Add new quirk for Lenovo Y990 Laptop", " - ALSA: core: add isascii() check to card ID generator", " - ALSA: usb-audio: Add delay quirk for VIVO USB-C HEADSET", " - ALSA: usb-audio: Add native DSD support for Luxman D-08u", " - ALSA: line6: add hw monitor volume control to POD HD500X", " - ALSA: hda/realtek: fix mute/micmute LED for HP mt645 G8", " - ALSA: hda/realtek: Add quirk for Huawei MateBook 13 KLV-WX9", " - ALSA: hda/realtek: Add a quirk for HP Pavilion 15z-ec200", " - ext4: correct encrypted dentry name hash when not casefolded", " - ext4: propagate errors from ext4_find_extent() in ext4_insert_range()", " - ext4: fix incorrect tid assumption in ext4_fc_mark_ineligible()", " - ext4: fix incorrect tid assumption in __jbd2_log_wait_for_space()", " - ext4: fix incorrect tid assumption in ext4_wait_for_tail_page_commit()", " - ext4: fix incorrect tid assumption in jbd2_journal_shrink_checkpoint_list()", " - ext4: fix fast commit inode enqueueing during a full journal commit", " - ext4: use handle to mark fc as ineligible in __track_dentry_update()", " - ext4: mark fc as ineligible using an handle in ext4_xattr_set()", " - parisc: Fix 64-bit userspace syscall path", " - parisc: Allow mmap(MAP_STACK) memory to automatically expand upwards", " - parisc: Fix stack start for ADDR_NO_RANDOMIZE personality", " - drm/rockchip: vop: clear DMA stop bit on RK3066", " - of: address: Report error on resource bounds overflow", " - of/irq: Support #msi-cells=<0> in of_msi_get_domain", " - lib/buildid: harden build ID parsing logic", " - jbd2: correctly compare tids with tid_geq function in jbd2_fc_begin_commit", " - mm: krealloc: consider spare memory for __GFP_ZERO", " - ocfs2: fix the la space leak when unmounting an ocfs2 volume", " - ocfs2: fix uninit-value in ocfs2_get_block()", " - scripts/gdb: fix timerlist parsing issue", " - scripts/gdb: add iteration function for rbtree", " - scripts/gdb: fix lx-mounts command error", " - arm64: fix selection of HAVE_DYNAMIC_FTRACE_WITH_ARGS", " - arm64: Subscribe Microsoft Azure Cobalt 100 to erratum 3194386", " - drm/xe/oa: Don't reset OAC_CONTEXT_ENABLE on OA stream close", " - sched/deadline: Comment sched_dl_entity::dl_server variable", " - sched/core: Add clearing of ->dl_server in put_prev_task_balance()", " - sched/core: Clear prev->dl_server in CFS pick fast path", " - sched: psi: fix bogus pressure spikes from aggregation race", " - riscv: define ILLEGAL_POINTER_VALUE for 64bit", " - [Config] updateconfigs for ILLEGAL_POINTER_VALUE on riscv", " - perf python: Disable -Wno-cast-function-type-mismatch if present on clang", " - perf hist: Update hist symbol when updating maps", " - nfsd: fix delegation_blocked() to block correctly for at least 30 seconds", " - NFSD: Fix NFSv4's PUTPUBFH operation", " - sysctl: avoid spurious permanent empty tables", " - RDMA/mana_ib: use the correct page table index based on hardware page size", " - RDMA/mana_ib: use the correct page size for mapping user-mode doorbell page", " - drivers/perf: riscv: Align errno for unsupported perf event", " - riscv: Fix kernel stack size when KASAN is enabled", " - media: imx335: Fix reset-gpio handling", " - clk: rockchip: fix error for unknown clocks", " - leds: pca9532: Remove irrelevant blink configuration error message", " - media: videobuf2: Drop minimum allocation requirement of 2 buffers", " - clk: qcom: dispcc-sm8250: use CLK_SET_RATE_PARENT for branch clocks", " - media: sun4i_csi: Implement link validate for sun4i_csi subdev", " - clk: qcom: gcc-sm8450: Do not turn off PCIe GDSCs during gdsc_disable()", " - media: uapi/linux/cec.h: cec_msg_set_reply_to: zero flags", " - dt-bindings: clock: qcom: Add GPLL9 support on gcc-sc8180x", " - clk: qcom: gcc-sc8180x: Register QUPv3 RCGs for DFS on sc8180x", " - clk: qcom: clk-rpmh: Fix overflow in BCM vote", " - clk: samsung: exynos7885: Update CLKS_NR_FSYS after bindings fix", " - clk: qcom: gcc-sm8150: De-register gcc_cpuss_ahb_clk_src", " - clk: qcom: gcc-sm8250: Do not turn off PCIe GDSCs during gdsc_disable()", " - clk: qcom: gcc-sc8180x: Add GPLL9 support", " - clk: qcom: gcc-sc8180x: Fix the sdcc2 and sdcc4 clocks freq table", " - clk: qcom: clk-alpha-pll: Fix CAL_L_VAL override for LUCID EVO PLL", " - drm/amd/display: avoid set dispclk to 0", " - smb: client: use actual path when queryfs", " - smb3: fix incorrect mode displayed for read-only files", " - iio: magnetometer: ak8975: Fix reading for ak099xx sensors", " - iio: pressure: bmp280: Fix regmap for BMP280 device", " - iio: pressure: bmp280: Fix waiting time for BMP3xx configuration", " - tomoyo: fallback to realpath if symlink's pathname does not exist", " - kselftests: mm: fix wrong __NR_userfaultfd value", " - rtc: at91sam9: fix OF node leak in probe() error path", " - mm/hugetlb: fix memfd_pin_folios resv_huge_pages leak", " - mm/gup: fix memfd_pin_folios hugetlb page allocation", " - mm/hugetlb: simplify refs in memfd_alloc_folio", " - Input: adp5589-keys - fix adp5589_gpio_get_value()", " - HID: bpf: fix cfi stubs for hid_bpf_ops", " - pidfs: check for valid pid namespace", " - ACPI: video: Add backlight=native quirk for Dell OptiPlex 5480 AIO", " - ACPI: resource: Remove duplicate Asus E1504GAB IRQ override", " - ACPI: resource: Loosen the Asus E1404GAB DMI match to also cover the E1404GA", " - ACPI: resource: Add Asus Vivobook X1704VAP to irq1_level_low_skip_override[]", " - ACPI: resource: Add Asus ExpertBook B2502CVA to", " irq1_level_low_skip_override[]", " - btrfs: drop the backref cache during relocation if we commit", " - btrfs: send: fix invalid clone operation for file that got its size", " decreased", " - cpufreq: intel_pstate: Make hwp_notify_lock a raw spinlock", " - gpio: davinci: fix lazy disable", " - net: pcs: xpcs: fix the wrong register that was written back", " - Bluetooth: hci_event: Align BR/EDR JUST_WORKS paring with LE", " - io_uring/net: harden multishot termination case for recv", " - ceph: fix cap ref leak via netfs init_request", " - tracing/hwlat: Fix a race during cpuhp processing", " - tracing/timerlat: Fix duplicated kthread creation due to CPU online/offline", " - rtla: Fix the help text in osnoise and timerlat top tools", " - firmware/sysfb: Disable sysfb for firmware buffers with unknown parent", " - close_range(): fix the logics in descriptor table trimming", " - drm/i915/gem: fix bitwise and logical AND mixup", " - drm/panthor: Don't add write fences to the shared BOs", " - drm/panthor: Don't declare a queue blocked if deferred operations are", " pending", " - drm/sched: Fix dynamic job-flow control race", " - drm/sched: Add locking to drm_sched_entity_modify_sched", " - drm/sched: Always wake up correct scheduler in drm_sched_entity_push_job", " - drm/sched: Always increment correct scheduler score", " - drm/amd/display: Restore Optimized pbn Value if Failed to Disable DSC", " - drm/amd/display: Add HDR workaround for specific eDP", " - drm/amd/display: Enable idle workqueue for more IPS modes", " - kconfig: fix infinite loop in sym_calc_choice()", " - kconfig: qconf: move conf_read() before drawing tree pain", " - kconfig: qconf: fix buffer overflow in debug links", " - arm64: cputype: Add Neoverse-N3 definitions", " - arm64: errata: Expand speculative SSBS workaround once more", " - mm: z3fold: deprecate CONFIG_Z3FOLD", " - [Config] updateconfigs after deprecating Z3FOLD", " - drm/amd/display: Allow backlight to go below", " `AMDGPU_DM_DEFAULT_MIN_BACKLIGHT`", " - sunrpc: change sp_nrthreads from atomic_t to unsigned int.", " - NFSD: Async COPY result needs to return a write verifier", " - remoteproc: k3-r5: Acquire mailbox handle during probe routine", " - remoteproc: k3-r5: Delay notification of wakeup event", " - r8169: Fix spelling mistake: \"tx_underun\" -> \"tx_underrun\"", " - ACPI: battery: Simplify battery hook locking", " - drm/xe: Clean up VM / exec queue file lock usage.", " - drm/rockchip: vop: enable VOP_FEATURE_INTERNAL_RGB on RK3066", " - drm/xe/vram: fix ccs offset calculation", " - drm/sched: revert \"Always increment correct scheduler score\"", " - ALSA: control: Fix leftover snd_power_unref()", " - crypto: octeontx* - Select CRYPTO_AUTHENC", " - drm/amd/display: Revert Avoid overflow assignment", " - perf report: Fix segfault when 'sym' sort key is not used", " - pmdomain: core: Reduce debug summary table width", " - perf python: Allow checking for the existence of warning options in clang", " - Linux 6.11.3", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49863", " - vhost/scsi: null-ptr-dereference in vhost_scsi_get_req()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49864", " - rxrpc: Fix a race between socket set up and I/O thread creation", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49865", " - drm/xe/vm: move xa_alloc to prevent UAF", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49955", " - ACPI: battery: Fix possible crash when unregistering a battery hook", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49973", " - r8169: add tally counter fields added with RTL8125", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49974", " - NFSD: Limit the number of concurrent async COPY operations", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49975", " - uprobes: fix kernel info leak via \"[uprobes]\" vma", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50003", " - drm/amd/display: Fix system hang while resume with TBT monitor", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50173", " - drm/panthor: Fix access to uninitialized variable in tick_ctx_cleanup()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49866", " - tracing/timerlat: Fix a race during cpuhp processing", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49976", " - tracing/timerlat: Drop interface_lock in stop_kthread()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50005", " - mac802154: Fix potential RCU dereference issue in mac802154_scan_worker", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50012", " - cpufreq: Avoid a bad reference count on CPU node", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49867", " - btrfs: wait for fixup workers before stopping cleaner kthread during umount", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49868", " - btrfs: fix a NULL pointer dereference when failed to start a new trasacntion", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49869", " - btrfs: send: fix buffer overflow detection when copying path to cache entry", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49870", " - cachefiles: fix dentry leak in cachefiles_open_file()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49871", " - Input: adp5589-keys - fix NULL pointer dereference", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49872", " - mm/gup: fix memfd_pin_folios alloc race panic", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49964", " - mm/hugetlb: fix memfd_pin_folios free_huge_pages leak", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49873", " - mm/filemap: fix filemap_get_folios_contig THP panic", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49977", " - net: stmmac: Fix zero-division error when disabling tc cbs", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49978", " - gso: fix udp gso fraglist segmentation after pull from frag_list", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49979", " - net: gso: fix tcp fraglist segmentation after pull from frag_list", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49980", " - vrf: revert \"vrf: Remove unnecessary RCU-bh critical section\"", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49981", " - media: venus: fix use after free bug in venus_remove due to race condition", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49956", " - gfs2: fix double destroy_workqueue error", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50176", " - remoteproc: k3-r5: Fix error handling when power-up failed", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49982", " - aoe: fix the potential use-after-free problem in more places", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49874", " - i3c: master: svc: Fix use after free vulnerability in svc_i3c_master Driver", " Due to Race Condition", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49875", " - nfsd: map the EBADMSG to nfserr_io to avoid warning", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50013", " - exfat: fix memory leak in exfat_load_bitmap()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49876", " - drm/xe: fix UAF around queue destruction", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49877", " - ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49957", " - ocfs2: fix null-ptr-deref when journal load failed.", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49965", " - ocfs2: remove unreasonable unlock in ocfs2_read_blocks", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49966", " - ocfs2: cancel dqi_sync_work before freeing oinfo", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49958", " - ocfs2: reserve space for inline xattr before attaching reflink tree", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49959", " - jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49878", " - resource: fix region_intersects() vs add_memory_driver_managed()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49879", " - drm: omapdrm: Add missing check for alloc_ordered_workqueue", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49880", " - ext4: fix off by one issue in alloc_flex_gd()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49881", " - ext4: update orig_path in ext4_find_extent()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50014", " - ext4: fix access to uninitialised lock in fc replay path", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49960", " - ext4: fix timer use-after-free on failed mount", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49882", " - ext4: fix double brelse() the buffer of the extents path", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49883", " - ext4: aovid use-after-free in ext4_ext_insert_extent()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49983", " - ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-free", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50015", " - ext4: dax: fix overflowing extents beyond inode size when partially writing", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49884", " - ext4: fix slab-use-after-free in ext4_split_extent_at()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49885", " - mm, slub: avoid zeroing kmalloc redzone", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49961", " - media: i2c: ar0521: Use cansleep version of gpiod_set_value()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49985", " - i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49886", " - platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bug", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49986", " - platform/x86: x86-android-tablets: Fix use after free on", " platform_device_register() errors", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49887", " - f2fs: fix to don't panic system for no free segment fault injection", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49888", " - bpf: Fix a sdiv overflow issue", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49987", " - bpftool: Fix undefined behavior in qsort(NULL, 0, ...)", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50006", " - ext4: fix i_data_sem unlock order in ext4_ind_migrate()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49889", " - ext4: avoid use-after-free in ext4_ext_show_leaf()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49968", " - ext4: filesystems without casefold feature cannot be mounted with siphash", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49988", " - ksmbd: add refcnt to ksmbd_conn struct", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49890", " - drm/amd/pm: ensure the fw_info is not null before using it", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49891", " - scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata", " paths", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49892", " - drm/amd/display: Initialize get_bytes_per_element's default to 1", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50016", " - drm/amd/display: Avoid overflow assignment in link_dp_cts", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49893", " - drm/amd/display: Check stream_status before it is used", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49969", " - drm/amd/display: Fix index out of bounds in DCN30 color transformation", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49970", " - drm/amd/display: Implement bounds check for stream encoder creation in", " DCN401", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49894", " - drm/amd/display: Fix index out of bounds in degamma hardware format", " translation", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49895", " - drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format", " translation", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49971", " - drm/amd/display: Increase array size of dummy_boolean", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49972", " - drm/amd/display: Deallocate DML memory if allocation fails", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49896", " - drm/amd/display: Check stream before comparing them", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49897", " - drm/amd/display: Check phantom_stream before it is used", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49898", " - drm/amd/display: Check null-initialized variables", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49899", " - drm/amd/display: Initialize denominators' default to 1", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49900", " - jfs: Fix uninit-value access of new_ea in ea_buffer", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49901", " - drm/msm/adreno: Assign msm_gpu->pdev earlier to avoid nullptrs", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49902", " - jfs: check if leafidx greater than num leaves per dmap tree", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49903", " - jfs: Fix uaf in dbFreeBits", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49904", " - drm/amdgpu: add list empty check to avoid null pointer issue", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49989", " - drm/amd/display: fix double free issue during amdgpu module unload", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49905", " - drm/amd/display: Add null check for 'afb' in", " amdgpu_dm_plane_handle_cursor_update (v2)", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49906", " - drm/amd/display: Check null pointer before try to access it", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49907", " - drm/amd/display: Check null pointers before using dc->clk_mgr", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49908", " - drm/amd/display: Add null check for 'afb' in amdgpu_dm_update_cursor (v2)", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50177", " - drm/amd/display: fix a UBSAN warning in DML2.1", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49909", " - drm/amd/display: Add NULL check for function pointer in", " dcn32_set_output_transfer_func", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49910", " - drm/amd/display: Add NULL check for function pointer in", " dcn401_set_output_transfer_func", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49911", " - drm/amd/display: Add NULL check for function pointer in", " dcn20_set_output_transfer_func", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49912", " - drm/amd/display: Handle null 'stream_status' in", " 'planes_changed_for_existing_stream'", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49913", " - drm/amd/display: Add null check for top_pipe_to_program in", " commit_planes_for_stream", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49914", " - drm/amd/display: Add null check for pipe_ctx->plane_state in", " dcn20_program_pipe", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49915", " - drm/amd/display: Add NULL check for clk_mgr in dcn32_init_hw", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49916", " - drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in", " dcn401_init_hw", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49917", " - drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in", " dcn30_init_hw", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49918", " - drm/amd/display: Add null check for head_pipe in", " dcn32_acquire_idle_pipe_for_head_pipe_in_layer", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49919", " - drm/amd/display: Add null check for head_pipe in", " dcn201_acquire_free_pipe_for_layer", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49991", " - drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49920", " - drm/amd/display: Check null pointers before multiple uses", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49921", " - drm/amd/display: Check null pointers before used", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49922", " - drm/amd/display: Check null pointers before using them", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49923", " - drm/amd/display: Pass non-null to dcn20_validate_apply_pipe_split_flags", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49992", " - drm/stm: Avoid use-after-free issues with crtc and plane", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49993", " - iommu/vt-d: Fix potential lockup if qi_submit_sync called with 0 count", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49924", " - fbdev: pxafb: Fix possible use after free in pxafb_task()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49925", " - fbdev: efifb: Register sysfs groups through driver core", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49926", " - rcu-tasks: Fix access non-existent percpu rtpcp variable in", " rcu_tasks_need_gpcb()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50007", " - ALSA: asihpi: Fix potential OOB array access", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50017", " - x86/mm/ident_map: Use gbpages only where full GB page should be mapped.", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49927", " - x86/ioapic: Handle allocation failures gracefully", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50008", " - wifi: mwifiex: Fix memcpy() field-spanning write warning in", " mwifiex_cmd_802_11_scan_ext()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50018", " - net: napi: Prevent overflow of napi_defer_hard_irqs", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49928", " - wifi: rtw89: avoid reading out of bounds when loading TX power FW elements", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50178", " - cpufreq: loongson3: Use raw_smp_processor_id() in do_service_request()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50009", " - cpufreq: amd-pstate: add check for cpufreq_cpu_get's return value", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49994", " - block: fix integer overflow in BLKSECDISCARD", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49929", " - wifi: iwlwifi: mvm: avoid NULL pointer dereference", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49995", " - tipc: guard against string buffer overrun", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49962", " - ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in", " acpi_db_convert_to_package()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49930", " - wifi: ath11k: fix array out-of-bound access in SoC stats", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49931", " - wifi: ath12k: fix array out-of-bound access in SoC stats", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49932", " - btrfs: don't readahead the relocation inode on RST", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49933", " - blk_iocost: fix more out of bound shifts", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49934", " - fs/inode: Prevent dump_mapping() accessing invalid dentry.d_name.name", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50010", " - exec: don't WARN for racy path_noexec check", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49935", " - ACPI: PAD: fix crash in exit_round_robin()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49936", " - net/xen-netback: prevent UAF in xenvif_flush_hash()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49937", " - wifi: cfg80211: Set correct chandef when starting CAC", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49938", " - wifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmit", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49939", " - wifi: rtw89: avoid to add interface to list twice when SER", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49940", " - l2tp: prevent possible tunnel refcount underflow", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49941", " - gpiolib: Fix potential NULL pointer dereference in gpiod_get_label()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49996", " - cifs: Fix buffer overflow when parsing NFS reparse points", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49942", " - drm/xe: Prevent null pointer access in xe_migrate_copy", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49943", " - drm/xe/guc_submit: add missing locking in wedged_fini", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50011", " - ASoC: Intel: soc-acpi-intel-rpl-match: add missing empty item", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50174", " - drm/panthor: Fix race when converting group handle to group object", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49944", " - sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_start", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49945", " - net/ncsi: Disable the ncsi work before freeing the associated structure", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49946", " - ppp: do not assume bh is held in ppp_channel_bridge_input()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49947", " - net: test for not too small csum_start in virtio_net_hdr_to_skb()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49948", " - net: add more sanity checks to qdisc_pkt_len_init()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49949", " - net: avoid potential underflow in qdisc_pkt_len_init() with UFO", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49997", " - net: ethernet: lantiq_etop: fix memory disclosure", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49998", " - net: dsa: improve shutdown sequence", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49999", " - afs: Fix the setting of the server responding flag", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49950", " - Bluetooth: L2CAP: Fix uaf in l2cap_connect", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49951", " - Bluetooth: MGMT: Fix possible crash on mgmt_index_removed", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49952", " - netfilter: nf_tables: prevent nf_skb_duplicated corruption", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49953", " - net/mlx5e: Fix crash caused by calling __xfrm_state_delete() twice", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50000", " - net/mlx5e: Fix NULL deref in mlx5e_tir_builder_alloc()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50001", " - net/mlx5: Fix error path in multi-packet WQE transmit", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50179", " - ceph: remove the incorrect Fw reference check when dirtying pages", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49963", " - mailbox: bcm2835: Fix timeout during suspend mode", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49954", " - static_call: Replace pointless WARN_ON() in static_call_module_notify()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50002", " - static_call: Handle module init failure correctly in", " static_call_del_module()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033)", " - EDAC/synopsys: Fix error injection on Zynq UltraScale+", " - crypto: xor - fix template benchmarking", " - crypto: qat - disable IOV in adf_dev_stop()", " - crypto: qat - fix recovery flow for VFs", " - crypto: qat - ensure correct order in VF restarting handler", " - ACPI: PMIC: Remove unneeded check in tps68470_pmic_opregion_probe()", " - eth: fbnic: select DEVLINK and PAGE_POOL", " - wifi: brcmfmac: introducing fwil query functions", " - wifi: ath9k: Remove error checks when creating debugfs entries", " - wifi: ath12k: fix BSS chan info request WMI command", " - wifi: ath12k: match WMI BSS chan info structure with firmware definition", " - wifi: ath12k: fix invalid AMPDU factor calculation in", " ath12k_peer_assoc_h_he()", " - hwrng: cn10k - Enable by default CN10K driver if Thunder SoC is enabled", " - crypto: x86/aes-gcm - fix PREEMPT_RT issue in gcm_crypt()", " - net: stmmac: dwmac-loongson: Init ref and PTP clocks rate", " - virtio: rename virtio_config_enabled to virtio_config_core_enabled", " - virtio: allow driver to disable the configure change notification", " - virtio-net: synchronize operstate with admin state on up/down", " - virtio-net: synchronize probe with ndo_set_features", " - arm64: signal: Fix some under-bracketed UAPI macros", " - wifi: rtw88: remove CPT execution branch never used", " - RISC-V: KVM: Fix sbiret init before forwarding to userspace", " - RISC-V: KVM: Allow legacy PMU access from guest", " - RISC-V: KVM: Fix to allow hpmcounter31 from the guest", " - mount: handle OOM on mnt_warn_timestamp_expiry", " - autofs: fix missing fput for FSCONFIG_SET_FD", " - netfilter: nf_tables: store new sets in dedicated list", " - wifi: rtw89: limit the PPDU length for VHT rate to 0x40000", " - kselftest/arm64: signal: fix/refactor SVE vector length enumeration", " - arm64: smp: smp_send_stop() and crash_smp_send_stop() should try non-NMI", " first", " - thermal: core: Fold two functions into their respective callers", " - thermal: core: Fix rounding of delay jiffies", " - perf/dwc_pcie: Fix registration issue in multi PCIe controller instances", " - perf/dwc_pcie: Always register for PCIe bus notifier", " - crypto: qat - fix \"Full Going True\" macro definition", " - ACPI: video: force native for Apple MacbookPro9,2", " - wifi: mac80211_hwsim: correct MODULE_PARM_DESC of multi_radio", " - wifi: iwlwifi: config: label 'gl' devices as discrete", " - wifi: iwlwifi: mvm: increase the time between ranging measurements", " - wifi: cfg80211: fix bug of mapping AF3x to incorrect User Priority", " - wifi: mac80211: fix the comeback long retry times", " - wifi: iwlwifi: mvm: allow ESR when we the ROC expires", " - wifi: mac80211: Check for missing VHT elements only for 5 GHz", " - ACPICA: Implement ACPI_WARNING_ONCE and ACPI_ERROR_ONCE", " - ACPICA: executer/exsystem: Don't nag user about every Stall() violating the", " spec", " - padata: Honor the caller's alignment in case of chunk_size 0", " - drivers/perf: hisi_pcie: Record hardware counts correctly", " - drivers/perf: hisi_pcie: Fix TLP headers bandwidth counting", " - kselftest/arm64: Actually test SME vector length changes via sigreturn", " - can: j1939: use correct function name in comment", " - wifi: rtw89: wow: fix wait condition for AOAC report request", " - ACPI: CPPC: Fix MASK_VAL() usage", " - netfilter: nf_tables: elements with timeout below CONFIG_HZ never expire", " - netfilter: nf_tables: reject element expiration with no timeout", " - netfilter: nf_tables: reject expiration higher than timeout", " - netfilter: nf_tables: remove annotation to access set timeout while holding", " lock", " - netfilter: nft_dynset: annotate data-races around set timeout", " - perf/arm-cmn: Refactor node ID handling. Again.", " - perf/arm-cmn: Fix CCLA register offset", " - perf/arm-cmn: Ensure dtm_idx is big enough", " - cpufreq: ti-cpufreq: Introduce quirks to handle syscon fails appropriately", " - thermal: gov_bang_bang: Adjust states of all uninitialized instances", " - wifi: mt76: mt7921: fix wrong UNII-4 freq range check for the channel usage", " - wifi: mt76: mt7996: fix traffic delay when switching back to working channel", " - wifi: mt76: mt7996: fix wmm set of station interface to 3", " - wifi: mt76: mt7996: fix HE and EHT beamforming capabilities", " - wifi: mt76: mt7996: fix EHT beamforming capability check", " - pm:cpupower: Add missing powercap_set_enabled() stub function", " - crypto: ccp - do not request interrupt on cmd completion when irqs disabled", " - crypto: hisilicon/hpre - mask cluster timeout error", " - crypto: hisilicon/qm - reset device before enabling it", " - wifi: mt76: mt7996: fix handling mbss enable/disable", " - wifi: mt76: connac: fix checksum offload fields of connac3 RXD", " - wifi: mt76: mt7603: fix mixed declarations and code", " - wifi: cfg80211: fix UBSAN noise in cfg80211_wext_siwscan()", " - wifi: mt76: mt7915: fix rx filter setting for bfee functionality", " - wifi: mt76: mt7996: fix uninitialized TLV data", " - wifi: cfg80211: fix two more possible UBSAN-detected off-by-one errors", " - af_unix: Don't call skb_get() for OOB skb.", " - af_unix: Remove single nest in manage_oob().", " - af_unix: Rename unlinked_skb in manage_oob().", " - af_unix: Move spin_lock() in manage_oob().", " - Bluetooth: hci_core: Fix sending MGMT_EV_CONNECT_FAILED", " - Bluetooth: hci_sync: Ignore errors from HCI_OP_REMOTE_NAME_REQ_CANCEL", " - can: m_can: enable NAPI before enabling interrupts", " - can: m_can: m_can_close(): stop clocks after device has been shut down", " - Bluetooth: btusb: Fix not handling ZPL/short-transfer", " - bareudp: Pull inner IP header in bareudp_udp_encap_recv().", " - bareudp: Pull inner IP header on xmit.", " - net: enetc: Use IRQF_NO_AUTOEN flag in request_irq()", " - crypto: n2 - Set err to EINVAL if snprintf fails for hmac", " - xsk: fix batch alloc API on non-coherent systems", " - net: ipv6: rpl_iptunnel: Fix memory leak in rpl_input", " - fbnic: Set napi irq value after calling netif_napi_add", " - net: tipc: avoid possible garbage value", " - ublk: move zone report data out of request pdu", " - block, bfq: choose the last bfqq from merge chain in bfq_setup_cooperator()", " - block, bfq: don't break merge chain in bfq_split_bfqq()", " - cachefiles: Fix non-taking of sb_writers around set/removexattr", " - nbd: correct the maximum value for discard sectors", " - erofs: fix incorrect symlink detection in fast symlink", " - erofs: fix error handling in z_erofs_init_decompressor", " - block, bfq: fix uaf for accessing waker_bfqq after splitting", " - block, bfq: fix procress reference leakage for bfqq in merge chain", " - io_uring/io-wq: do not allow pinning outside of cpuset", " - io_uring/io-wq: inherit cpuset of cgroup in io worker", " - spi: ppc4xx: handle irq_of_parse_and_map() errors", " - arm64: dts: exynos: exynos7885-jackpotlte: Correct RAM amount to 4GB", " - arm64: dts: mediatek: mt8186: Fix supported-hw mask for GPU OPPs", " - spi: ppc4xx: Avoid returning 0 when failed to parse and map IRQ", " - firmware: qcom: scm: Disable SDI and write no dump to dump mode", " - regulator: Return actual error in of_regulator_bulk_get_all()", " - arm64: dts: renesas: r9a08g045: Correct GICD and GICR sizes", " - arm64: dts: renesas: r9a07g043u: Correct GICD and GICR sizes", " - arm64: dts: renesas: r9a07g054: Correct GICD and GICR sizes", " - arm64: dts: renesas: r9a07g044: Correct GICD and GICR sizes", " - ARM: dts: microchip: sam9x60: Fix rtc/rtt clocks", " - arm64: tegra: Correct location of power-sensors for IGX Orin", " - arm64: dts: rockchip: Correct vendor prefix for Hardkernel ODROID-M1", " - arm64: dts: ti: k3-j721e-sk: Fix reversed C6x carveout locations", " - arm64: dts: ti: k3-j721e-beagleboneai64: Fix reversed C6x carveout locations", " - spi: bcmbca-hsspi: Fix missing pm_runtime_disable()", " - arm64: dts: qcom: x1e80100: Fix PHY for DP2", " - ARM: dts: microchip: sama7g5: Fix RTT clock", " - ARM: dts: imx7d-zii-rmu2: fix Ethernet PHY pinctrl property", " - arm64: dts: ti: k3-am654-idk: Fix dtbs_check warning in ICSSG dmas", " - ARM: versatile: fix OF node leak in CPUs prepare", " - reset: berlin: fix OF node leak in probe() error path", " - reset: k210: fix OF node leak in probe() error path", " - platform: cznic: turris-omnia-mcu: Fix error check in", " omnia_mcu_register_trng()", " - clocksource/drivers/qcom: Add missing iounmap() on errors in", " msm_dt_timer_init()", " - arm64: dts: mediatek: mt8195: Correct clock order for dp_intf*", " - x86/mm: Use IPIs to synchronize LAM enablement", " - ASoC: rt5682s: Return devm_of_clk_add_hw_provider to transfer the error", " - ASoC: tas2781: Fix a compiling warning reported by robot kernel test due to", " adding tas2563_dvc_table", " - ASoC: tas2781-i2c: Drop weird GPIO code", " - ASoC: tas2781-i2c: Get the right GPIO line", " - selftests/ftrace: Add required dependency for kprobe tests", " - ALSA: hda: cs35l41: fix module autoloading", " - selftests/ftrace: Fix test to handle both old and new kernels", " - x86/boot/64: Strip percpu address space when setting up GDT descriptors", " - m68k: Fix kernel_clone_args.flags in m68k_clone()", " - ASoC: loongson: fix error release", " - selftests/ftrace: Fix eventfs ownership testcase to find mount point", " - selftests:resctrl: Fix build failure on archs without __cpuid_count()", " - cgroup/pids: Avoid spurious event notification", " - hwmon: (max16065) Fix overflows seen when writing limits", " - hwmon: (max16065) Fix alarm attributes", " - iommu/arm-smmu: Un-demote unhandled-fault msg", " - iommu/arm-smmu-v3: Fix a NULL vs IS_ERR() check", " - mtd: slram: insert break after errors in parsing the map", " - hwmon: (ntc_thermistor) fix module autoloading", " - power: supply: axp20x_battery: Remove design from min and max voltage", " - power: supply: max17042_battery: Fix SOC threshold calc w/ no current sense", " - fbdev: hpfb: Fix an error handling path in hpfb_dio_probe()", " - iommu/amd: Handle error path in amd_iommu_probe_device()", " - iommu/amd: Allocate the page table root using GFP_KERNEL", " - iommu/amd: Move allocation of the top table into v1_alloc_pgtable", " - iommu/amd: Set the pgsize_bitmap correctly", " - iommu/amd: Do not set the D bit on AMD v2 table entries", " - mtd: powernv: Add check devm_kasprintf() returned value", " - rcu/nocb: Fix RT throttling hrtimer armed from offline CPU", " - mtd: rawnand: mtk: Use for_each_child_of_node_scoped()", " - mtd: rawnand: mtk: Factorize out the logic cleaning mtk chips", " - mtd: rawnand: mtk: Fix init error path", " - iommu/arm-smmu-qcom: hide last LPASS SMMU context bank from linux", " - iommu/arm-smmu-qcom: Work around SDM845 Adreno SMMU w/ 16K pages", " - iommu/arm-smmu-qcom: apply num_context_bank fixes for SDM630 / SDM660", " - pmdomain: core: Harden inter-column space in debug summary", " - pmdomain: core: Fix \"managed by\" alignment in debug summary", " - drm/stm: Fix an error handling path in stm_drm_platform_probe()", " - drm/stm: ltdc: check memory returned by devm_kzalloc()", " - drm/amd/display: free bo used for dmub bounding box", " - drm/amdgpu: properly handle vbios fake edid sizing", " - drm/radeon: properly handle vbios fake edid sizing", " - drm/amd/display: Reset VRR config during resume", " - scsi: smartpqi: revert propagate-the-multipath-failure-to-SML-quickly", " - scsi: sd: Don't check if a write for REQ_ATOMIC", " - scsi: block: Don't check REQ_ATOMIC for reads", " - scsi: NCR5380: Check for phase match during PDMA fixup", " - drm/amd/amdgpu: Properly tune the size of struct", " - drm/amd/display: Improve FAM control for DCN401", " - drm/rockchip: vop: Allow 4096px width scaling", " - drm/rockchip: dw_hdmi: Fix reading EDID when using a forced mode", " - drm/radeon/evergreen_cs: fix int overflow errors in cs track offsets", " - drm/bridge: lontium-lt8912b: Validate mode in drm_bridge_funcs::mode_valid()", " - drm/vc4: hdmi: Handle error case of pm_runtime_resume_and_get", " - drm/mediatek: Fix missing configuration flags in mtk_crtc_ddp_config()", " - drm/mediatek: Use spin_lock_irqsave() for CRTC event lock", " - powerpc/8xx: Fix initial memory mapping", " - powerpc/8xx: Fix kernel vs user address comparison", " - powerpc/vdso: Inconditionally use CFUNC macro", " - drm/msm: Use a7xx family directly in gpu_state", " - drm/msm: Dump correct dbgahb clusters on a750", " - drm/msm: Fix CP_BV_DRAW_STATE_ADDR name", " - drm/msm: Fix incorrect file name output in adreno_request_fw()", " - drm/msm/a5xx: disable preemption in submits by default", " - drm/msm/a5xx: properly clear preemption records on resume", " - drm/msm/a5xx: fix races in preemption evaluation stage", " - drm/msm/a5xx: workaround early ring-buffer emptiness check", " - ipmi: docs: don't advertise deprecated sysfs entries", " - drm/msm/dp: enable widebus on all relevant chipsets", " - drm/msm/dsi: correct programming sequence for SM8350 / SM8450", " - drm/msm: fix %s null argument error", " - platform/x86: ideapad-laptop: Make the scope_guard() clear of its scope", " - kselftest: dt: Ignore nodes that have ancestors disabled", " - drivers:drm:exynos_drm_gsc:Fix wrong assignment in gsc_bind()", " - drm/amdgpu: fix invalid fence handling in amdgpu_vm_tlb_flush", " - xen: use correct end address of kernel for conflict checking", " - HID: wacom: Support sequence numbers smaller than 16-bit", " - HID: wacom: Do not warn about dropped packets for first packet", " - ata: libata: Clear DID_TIME_OUT for ATA PT commands with sense data", " - xen: introduce generic helper checking for memory map conflicts", " - xen: move max_pfn in xen_memory_setup() out of function scope", " - xen: add capability to remap non-RAM pages to different PFNs", " - xen: tolerate ACPI NVS memory overlapping with Xen allocated memory", " - drm/xe: fix missing 'xe_vm_put'", " - xen/swiotlb: add alignment check for dma buffers", " - xen/swiotlb: fix allocated size", " - sched/fair: Make SCHED_IDLE entity be preempted in strict hierarchy", " - bpf, x64: Fix tailcall hierarchy", " - bpf, arm64: Fix tailcall hierarchy", " - bpf: Fix compare error in function retval_range_within", " - selftests/bpf: Workaround strict bpf_lsm return value check.", " - selftests/bpf: Fix error linking uprobe_multi on mips", " - selftests/bpf: Fix wrong binary in Makefile log output", " - tools/runqslower: Fix LDFLAGS and add LDLIBS support", " - selftests/bpf: Use pid_t consistently in test_progs.c", " - selftests/bpf: Fix compile error from rlim_t in sk_storage_map.c", " - selftests/bpf: Fix error compiling bpf_iter_setsockopt.c with musl libc", " - selftests/bpf: Drop unneeded error.h includes", " - selftests/bpf: Fix missing ARRAY_SIZE() definition in bench.c", " - selftests/bpf: Fix missing UINT_MAX definitions in benchmarks", " - selftests/bpf: Fix missing BUILD_BUG_ON() declaration", " - selftests/bpf: Fix include of ", " - selftests/bpf: Fix compiling parse_tcp_hdr_opt.c with musl-libc", " - selftests/bpf: Fix compiling kfree_skb.c with musl-libc", " - selftests/bpf: Fix compiling flow_dissector.c with musl-libc", " - selftests/bpf: Fix compiling tcp_rtt.c with musl-libc", " - selftests/bpf: Fix compiling core_reloc.c with musl-libc", " - selftests/bpf: Fix errors compiling lwt_redirect.c with musl libc", " - selftests/bpf: Fix errors compiling decap_sanity.c with musl libc", " - selftests/bpf: Fix errors compiling crypto_sanity.c with musl libc", " - selftests/bpf: Fix errors compiling cg_storage_multi.h with musl libc", " - libbpf: Don't take direct pointers into BTF data from st_ops", " - selftests/bpf: Fix arg parsing in veristat, test_progs", " - selftests/bpf: Fix error compiling test_lru_map.c", " - selftests/bpf: Fix C++ compile error from missing _Bool type", " - selftests/bpf: Fix redefinition errors compiling lwt_reroute.c", " - selftests/bpf: Fix compile if backtrace support missing in libc", " - selftests/bpf: Fix error compiling tc_redirect.c with musl libc", " - s390/entry: Move early program check handler to entry.S", " - s390/entry: Make early program check handler relocated lowcore aware", " - libbpf: Fix license for btf_relocate.c", " - samples/bpf: Fix compilation errors with cf-protection option", " - selftests/bpf: no need to track next_match_pos in struct test_loader", " - selftests/bpf: extract test_loader->expect_msgs as a data structure", " - selftests/bpf: allow checking xlated programs in verifier_* tests", " - selftests/bpf: __arch_* macro to limit test cases to specific archs", " - selftests/bpf: fix to avoid __msg tag de-duplication by clang", " - selftests/bpf: Fix incorrect parameters in NULL pointer checking", " - libbpf: Fix bpf_object__open_skeleton()'s mishandling of options", " - s390/ap: Fix deadlock caused by recursive lock of the AP bus scan mutex", " - libbpf: Ensure new BTF objects inherit input endianness", " - xz: cleanup CRC32 edits from 2018", " - kthread: fix task state in kthread worker if being frozen", " - ext4: clear EXT4_GROUP_INFO_WAS_TRIMMED_BIT even mount with discard", " - bpftool: Fix handling enum64 in btf dump sorting", " - sched/deadline: Fix schedstats vs deadline servers", " - smackfs: Use rcu_assign_pointer() to ensure safe assignment in smk_set_cipso", " - ext4: avoid buffer_head leak in ext4_mark_inode_used()", " - ext4: avoid potential buffer_head leak in __ext4_new_inode()", " - ext4: avoid negative min_clusters in find_group_orlov()", " - ext4: return error on ext4_find_inline_entry", " - sched/numa: Fix the vma scan starving issue", " - nilfs2: determine empty node blocks as corrupted", " - sched/pelt: Use rq_clock_task() for hw_pressure", " - bpf: Fix bpf_strtol and bpf_strtoul helpers for 32bit", " - bpf: Improve check_raw_mode_ok test for MEM_UNINIT-tagged types", " - perf scripts python cs-etm: Restore first sample log in verbose mode", " - perf bpf: Move BPF disassembly routines to separate file to avoid clash with", " capstone bpf headers", " - perf mem: Free the allocated sort string, fixing a leak", " - perf lock contention: Change stack_id type to s32", " - perf vendor events: SKX, CLX, SNR uncore cache event fixes", " - perf inject: Fix leader sampling inserting additional samples", " - perf report: Fix --total-cycles --stdio output error", " - perf build: Fix up broken capstone feature detection fast path", " - perf sched timehist: Fix missing free of session in perf_sched__timehist()", " - perf stat: Display iostat headers correctly", " - perf dwarf-aux: Check allowed location expressions when collecting variables", " - perf annotate-data: Fix off-by-one in location range check", " - perf dwarf-aux: Handle bitfield members from pointer access", " - perf hist: Don't set hpp_fmt_value for members in --no-group", " - perf sched timehist: Fixed timestamp error when unable to confirm event", " sched_in time", " - perf time-utils: Fix 32-bit nsec parsing", " - perf mem: Check mem_events for all eligible PMUs", " - perf mem: Fix missed p-core mem events on ADL and RPL", " - clk: imx: clk-audiomix: Correct parent clock for earc_phy and audpll", " - clk: imx: imx6ul: fix default parent for enet*_ref_sel", " - clk: imx: composite-8m: Enable gate clk with mcore_booted", " - clk: imx: composite-93: keep root clock on when mcore enabled", " - clk: imx: composite-7ulp: Check the PCC present bit", " - clk: imx: fracn-gppll: fix fractional part of PLL getting lost", " - clk: imx: imx8mp: fix clock tree update of TF-A managed clocks", " - clk: imx: imx8qxp: Register dc0_bypass0_clk before disp clk", " - clk: imx: imx8qxp: Parent should be initialized earlier than the clock", " - quota: avoid missing put_quota_format when DQUOT_SUSPENDED is passed", " - remoteproc: imx_rproc: Correct ddr alias for i.MX8M", " - remoteproc: imx_rproc: Initialize workqueue earlier", " - clk: rockchip: Set parent rate for DCLK_VOP clock on RK3228", " - clk: qcom: dispcc-sm8550: fix several supposed typos", " - clk: qcom: dispcc-sm8550: use rcg2_ops for mdss_dptx1_aux_clk_src", " - clk: qcom: dispcc-sm8650: Update the GDSC flags", " - clk: qcom: dispcc-sm8550: use rcg2_shared_ops for ESC RCGs", " - leds: bd2606mvv: Fix device child node usage in bd2606mvv_probe()", " - pinctrl: renesas: rzg2l: Return -EINVAL if the pin doesn't support", " PIN_CFG_OEN", " - pinctrl: ti: ti-iodelay: Fix some error handling paths", " - phy: phy-rockchip-samsung-hdptx: Explicitly include pm_runtime.h", " - Input: ilitek_ts_i2c - avoid wrong input subsystem sync", " - Input: ilitek_ts_i2c - add report id message validation", " - media: raspberrypi: VIDEO_RASPBERRYPI_PISP_BE should depend on ARCH_BCM2835", " - [Config] updateconfigs for VIDEO_RASPBERRYPI_PISP_BE", " - PCI: Wait for Link before restoring Downstream Buses", " - firewire: core: correct range of block for case of switch statement", " - media: staging: media: starfive: camss: Drop obsolete return value", " documentation", " - clk: qcom: ipq5332: Register gcc_qdss_tsctr_clk_src", " - clk: qcom: dispcc-sm8250: use special function for Lucid 5LPE PLL", " - leds: pca995x: Use device_for_each_child_node() to access device child nodes", " - leds: pca995x: Fix device child node usage in pca995x_probe()", " - x86/PCI: Check pcie_find_root_port() return for NULL", " - PCI: xilinx-nwl: Fix register misspelling", " - PCI: xilinx-nwl: Clean up clock on probe failure/removal", " - leds: gpio: Set num_leds after allocation", " - media: platform: rzg2l-cru: rzg2l-csi2: Add missing MODULE_DEVICE_TABLE", " - pinctrl: single: fix missing error code in pcs_probe()", " - clk: at91: sama7g5: Allocate only the needed amount of memory for PLLs", " - iommufd/selftest: Fix buffer read overrrun in the dirty test", " - RDMA/bnxt_re: Fix the table size for PSN/MSN entries", " - media: imagination: VIDEO_E5010_JPEG_ENC should depend on ARCH_K3", " - [Config] updateconfigs for VIDEO_E5010_JPEG_ENC", " - RDMA/rtrs: Reset hb_missed_cnt after receiving other traffic from peer", " - clk: ti: dra7-atl: Fix leak of of_nodes", " - clk: starfive: Use pm_runtime_resume_and_get to fix pm_runtime_get_sync()", " usage", " - clk: rockchip: rk3588: Fix 32k clock name for pmu_24m_32k_100m_src_p", " - nfsd: remove unneeded EEXIST error check in nfsd_do_file_acquire", " - nfsd: fix refcount leak when file is unhashed after being found", " - pinctrl: mvebu: Fix devinit_dove_pinctrl_probe function", " - dt-bindings: PCI: layerscape-pci: Replace fsl,lx2160a-pcie with", " fsl,lx2160ar2-pcie", " - iommufd: Check the domain owner of the parent before creating a nesting", " domain", " - RDMA/erdma: Return QP state in erdma_query_qp", " - RDMA/mlx5: Fix counter update on MR cache mkey creation", " - RDMA/mlx5: Limit usage of over-sized mkeys from the MR cache", " - RDMA/mlx5: Drop redundant work canceling from clean_keys()", " - RDMA/mlx5: Fix MR cache temp entries cleanup", " - watchdog: imx_sc_wdt: Don't disable WDT in suspend", " - RDMA/hns: Don't modify rq next block addr in HIP09 QPC", " - RDMA/hns: Fix the overflow risk of hem_list_calc_ba_range()", " - RDMA/hns: Fix VF triggering PF reset in abnormal interrupt handler", " - RDMA/hns: Fix 1bit-ECC recovery address in non-4K OS", " - RDMA/hns: Optimize hem allocation performance", " - RDMA/hns: Fix restricted __le16 degrades to integer issue", " - Input: ims-pcu - fix calling interruptible mutex", " - RDMA/mlx5: Obtain upper net device only when needed", " - PCI: qcom-ep: Enable controller resources like PHY only after refclk is", " available", " - riscv: Fix fp alignment bug in perf_callchain_user()", " - RDMA/hns: Fix ah error counter in sw stat not increasing", " - RDMA/irdma: fix error message in irdma_modify_qp_roce()", " - ntb_perf: Fix printk format", " - ntb: Force physically contiguous allocation of rx ring buffers", " - nfsd: untangle code in nfsd4_deleg_getattr_conflict()", " - nfsd: fix initial getattr on write delegation", " - crypto: caam - Pad SG length when allocating hash edesc", " - crypto: powerpc/p10-aes-gcm - Disable CRYPTO_AES_GCM_P10", " - [Config] disable CRYPTO_AES_GCM_P10", " - f2fs: atomic: fix to avoid racing w/ GC", " - f2fs: reduce expensive checkpoint trigger frequency", " - f2fs: fix to avoid racing in between read and OPU dio write", " - f2fs: Create COW inode from parent dentry for atomic write", " - f2fs: fix to wait page writeback before setting gcing flag", " - f2fs: atomic: fix to truncate pagecache before on-disk metadata truncation", " - f2fs: compress: don't redirty sparse cluster during {,de}compress", " - f2fs: prevent atomic file from being dirtied before commit", " - spi: airoha: fix dirmap_{read,write} operations", " - spi: airoha: fix airoha_snand_{write,read}_data data_len estimation", " - spi: atmel-quadspi: Undo runtime PM changes at driver exit time", " - spi: spi-fsl-lpspi: Undo runtime PM changes at driver exit time", " - lib/sbitmap: define swap_lock as raw_spinlock_t", " - spi: airoha: remove read cache in airoha_snand_dirmap_read()", " - spi: atmel-quadspi: Avoid overwriting delay register settings", " - NFSv4.2: Fix detection of \"Proxying of Times\" server support", " - nvme-multipath: system fails to create generic nvme device", " - iio: adc: ad7606: fix oversampling gpio array", " - iio: adc: ad7606: fix standby gpio state to match the documentation", " - driver core: Fix error handling in driver API device_rename()", " - ABI: testing: fix admv8818 attr description", " - iio: chemical: bme680: Fix read/write ops to device by adding mutexes", " - iio: magnetometer: ak8975: drop incorrect AK09116 compatible", " - dt-bindings: iio: asahi-kasei,ak8975: drop incorrect AK09116 compatible", " - serial: 8250: omap: Cleanup on error in request_irq", " - Coresight: Set correct cs_mode for TPDM to fix disable issue", " - Coresight: Set correct cs_mode for dummy source to fix disable issue", " - coresight: tmc: sg: Do not leak sg_table", " - interconnect: icc-clk: Add missed num_nodes initialization", " - interconnect: qcom: sm8250: Enable sync_state", " - dm integrity: fix gcc 5 warning", " - cxl/pci: Fix to record only non-zero ranges", " - um: remove ARCH_NO_PREEMPT_DYNAMIC", " - Revert \"dm: requeue IO if mapping table not yet available\"", " - net: phy: aquantia: fix -ETIMEDOUT PHY probe failure when firmware not", " present", " - net: xilinx: axienet: Schedule NAPI in two steps", " - net: xilinx: axienet: Fix packet counting", " - net: ipv6: select DST_CACHE from IPV6_RPL_LWTUNNEL", " - net: qrtr: Update packets cloning when broadcasting", " - net: phy: aquantia: fix setting active_low bit", " - net: phy: aquantia: fix applying active_low bit after reset", " - net: ravb: Fix maximum TX frame size for GbEth devices", " - net: ravb: Fix R-Car RX frame size limit", " - virtio_net: Fix mismatched buf address when unmapping for small packets", " - netfilter: nf_tables: Keep deleted flowtable hooks until after RCU", " - netfilter: ctnetlink: compile ctnetlink_label_size with", " CONFIG_NF_CONNTRACK_EVENTS", " - netfilter: nf_tables: use rcu chain hook list iterator from netlink dump", " path", " - netfilter: nf_tables: missing objects with no memcg accounting", " - selftests: netfilter: Avoid hanging ipvs.sh", " - io_uring/sqpoll: do not allow pinning outside of cpuset", " - io_uring/rw: treat -EOPNOTSUPP for IOCB_NOWAIT like -EAGAIN", " - io_uring: check for presence of task_work rather than TIF_NOTIFY_SIGNAL", " - mm: migrate: annotate data-race in migrate_folio_unmap()", " - drm/amd/display: Fix Synaptics Cascaded Panamera DSC Determination", " - drm/amd/display: Add DSC Debug Log", " - drm/amdgpu/display: Fix a mistake in revert commit", " - xen: move checks for e820 conflicts further up", " - xen: allow mapping ACPI data using a different physical address", " - io_uring/sqpoll: retain test for whether the CPU is valid", " - drm/amd/display: disable_hpo_dp_link_output: Check link_res->hpo_dp_link_enc", " before using it", " - io_uring/sqpoll: do not put cpumask on stack", " - selftests/bpf: correctly move 'log' upon successful match", " - Remove *.orig pattern from .gitignore", " - PCI: Revert to the original speed after PCIe failed link retraining", " - PCI: Clear the LBMS bit after a link retrain", " - PCI: dra7xx: Fix threaded IRQ request for \"dra7xx-pcie-main\" IRQ", " - PCI: imx6: Fix missing call to phy_power_off() in error handling", " - PCI: imx6: Fix establish link failure in EP mode for i.MX8MM and i.MX8MP", " - PCI: imx6: Fix i.MX8MP PCIe EP's occasional failure to trigger MSI", " - PCI: Correct error reporting with PCIe failed link retraining", " - PCI: Use an error code with PCIe failed link retraining", " - PCI: xilinx-nwl: Fix off-by-one in INTx IRQ handler", " - PCI: dra7xx: Fix error handling when IRQ request fails in probe", " - Revert \"soc: qcom: smd-rpm: Match rpmsg channel instead of compatible\"", " - ASoC: rt5682: Return devm_of_clk_add_hw_provider to transfer the error", " - soc: fsl: cpm1: qmc: Update TRNSYNC only in transparent mode", " - soc: fsl: cpm1: tsa: Fix tsa_write8()", " - soc: versatile: integrator: fix OF node leak in probe() error path", " - Revert \"media: tuners: fix error return code of", " hybrid_tuner_request_state()\"", " - iommu/amd: Fix argument order in amd_iommu_dev_flush_pasid_all()", " - Input: adp5588-keys - fix check on return code", " - Input: i8042 - add TUXEDO Stellaris 16 Gen5 AMD to i8042 quirk table", " - Input: i8042 - add TUXEDO Stellaris 15 Slim Gen6 AMD to i8042 quirk table", " - Input: i8042 - add another board name for TUXEDO Stellaris Gen5 AMD line", " - KVM: arm64: Add memory length checks and remove inline in do_ffa_mem_xfer", " - KVM: x86: Enforce x2APIC's must-be-zero reserved ICR bits", " - KVM: x86: Move x2APIC ICR helper above kvm_apic_write_nodecode()", " - KVM: x86: Re-split x2APIC ICR into ICR+ICR2 for AMD (x2AVIC)", " - drm/amdgpu/mes12: reduce timeout", " - drm/amdgpu/mes11: reduce timeout", " - drm/amdkfd: Add SDMA queue quantum support for GFX12", " - drm/amdgpu: update golden regs for gfx12", " - drm/amdgpu/mes12: set enable_level_process_quantum_check", " - drm/amdgpu/vcn: enable AV1 on both instances", " - drm/amd/pm: update workload mask after the setting", " - drm/amdgpu: fix PTE copy corruption for sdma 7", " - drm/amdgpu: bump driver version for cleared VRAM", " - drm/amdgpu/mes12: switch SET_SHADER_DEBUGGER pkt to mes schq pipe", " - drm/amdgpu: Fix selfring initialization sequence on soc24", " - drm/amd/display: Add HDMI DSC native YCbCr422 support", " - drm/amd/display: Round calculated vtotal", " - drm/amd/display: Clean up dsc blocks in accelerated mode", " - drm/amd/display: Block timing sync for different output formats in pmo", " - drm/amd/display: Validate backlight caps are sane", " - drm/amd/display: Disable SYMCLK32_LE root clock gating", " - drm/amd/display: Block dynamic IPS2 on DCN35 for incompatible FW versions", " - drm/amd/display: Enable DML2 override_det_buffer_size_kbytes", " - drm/amd/display: Skip to enable dsc if it has been off", " - drm/amd/display: Fix underflow when setting underscan on DCN401", " - drm/amd/display: Update IPS default mode for DCN35/DCN351", " - objtool: Handle frame pointer related instructions", " - powerpc/atomic: Use YZ constraints for DS-form instructions", " - ksmbd: make __dir_empty() compatible with POSIX", " - ksmbd: allow write with FILE_APPEND_DATA", " - ksmbd: handle caseless file creation", " - ata: libata-scsi: Fix ata_msense_control() CDL page reporting", " - scsi: ufs: qcom: Update MODE_MAX cfg_bw value", " - scsi: lpfc: Restrict support for 32 byte CDBs to specific HBAs", " - scsi: mac_scsi: Revise printk(KERN_DEBUG ...) messages", " - scsi: mac_scsi: Refactor polling loop", " - scsi: mac_scsi: Disallow bus errors during PDMA send", " - can: esd_usb: Remove CAN_CTRLMODE_3_SAMPLES for CAN-USB/3-FD", " - wifi: rtw88: Fix USB/SDIO devices not transmitting beacons", " - usbnet: fix cyclical race on disconnect with work queue", " - arm64: dts: mediatek: mt8195-cherry: Mark USB 3.0 on xhci1 as disabled", " - arm64: dts: mediatek: mt8395-nio-12l: Mark USB 3.0 on xhci1 as disabled", " - USB: appledisplay: close race between probe and completion handler", " - USB: misc: cypress_cy7c63: check for short transfer", " - USB: class: CDC-ACM: fix race between get_serial and set_serial", " - USB: misc: yurex: fix race between read and write", " - usb: xhci: fix loss of data on Cadence xHC", " - usb: cdnsp: Fix incorrect usb_request status", " - usb: xHCI: add XHCI_RESET_ON_RESUME quirk for Phytium xHCI host", " - usb: gadget: dummy_hcd: execute hrtimer callback in softirq context", " - usb: dwc2: drd: fix clock gating on USB role switch", " - bus: integrator-lm: fix OF node leak in probe()", " - bus: mhi: host: pci_generic: Update EDL firmware path for Foxconn modems", " - bus: mhi: host: pci_generic: Fix the name for the Telit FE990A", " - tty: rp2: Fix reset with non forgiving PCIe host bridges", " - pps: add an error check in parport_attach", " - serial: don't use uninitialized value in uart_poll_init()", " - xhci: Set quirky xHC PCI hosts to D3 _after_ stopping and freeing them.", " - serial: qcom-geni: fix fifo polling timeout", " - serial: qcom-geni: fix false console tx restart", " - crypto: qcom-rng - fix support for ACPI-based systems", " - crypto: ccp - Properly unregister /dev/sev on sev PLATFORM_STATUS failure", " - drbd: Fix atomicity violation in drbd_uuid_set_bm()", " - drbd: Add NULL check for net_conf to prevent dereference in state validation", " - ACPI: resource: Do IRQ override on MECHREV GM7XG0M", " - ACPI: resource: Add another DMI match for the TongFang GMxXGxx", " - intel_idle: add Granite Rapids Xeon support", " - intel_idle: fix ACPI _CST matching for newer Xeon platforms", " - x86/entry: Remove unwanted instrumentation in common_interrupt()", " - perf/x86/intel: Allow to setup LBR for counting event for BPF", " - perf/x86/intel/pt: Fix sampling synchronization", " - btrfs: subpage: fix the bitmap dump which can cause bitmap corruption", " - wifi: mt76: mt7921: Check devm_kasprintf() returned value", " - wifi: mt76: mt7915: check devm_kasprintf() returned value", " - idpf: fix netdev Tx queue stop/wake", " - wifi: rtw88: 8821cu: Remove VID/PID 0bda:c82c", " - wifi: rtw88: 8822c: Fix reported RX band width", " - wifi: rtw88: 8703b: Fix reported RX band width", " - wifi: mt76: mt7615: check devm_kasprintf() returned value", " - wifi: mt76: mt7925: fix a potential association failure upon resuming", " - debugfs show actual source in /proc/mounts", " - debugobjects: Fix conditions in fill_pool()", " - btrfs: tree-checker: fix the wrong output of data backref objectid", " - btrfs: always update fstrim_range on failure in FITRIM ioctl", " - f2fs: fix several potential integer overflows in file offsets", " - f2fs: prevent possible int overflow in dir_block_index()", " - f2fs: avoid potential int overflow in sanity_check_area_boundary()", " - hwrng: mtk - Use devm_pm_runtime_enable", " - hwrng: bcm2835 - Add missing clk_disable_unprepare in bcm2835_rng_init", " - hwrng: cctrng - Add missing clk_disable_unprepare in cctrng_resume", " - arm64: esr: Define ESR_ELx_EC_* constants as UL", " - arm64: errata: Enable the AC03_CPU_38 workaround for ampere1a", " - arm64: dts: mediatek: mt8186-corsola: Disable DPI display interface", " - arm64: dts: rockchip: Raise Pinebook Pro's panel backlight PWM frequency", " - arm64: dts: qcom: sa8775p: Mark APPS and PCIe SMMUs as DMA coherent", " - arm64: dts: rockchip: Correct the Pinebook Pro battery design capacity", " - fs: Fix file_set_fowner LSM hook inconsistencies", " - nfs: fix memory leak in error path of nfs4_do_reclaim", " - EDAC/igen6: Fix conversion of system address to physical memory address", " - eventpoll: Annotate data-race of busy_poll_usecs", " - md: Don't flush sync_work in md_write_start()", " - cpuidle: riscv-sbi: Use scoped device node handling to fix missing", " of_node_put", " - lsm: add the inode_free_security_rcu() LSM implementation hook", " - spi: fspi: involve lut_num for struct nxp_fspi_devtype_data", " - dt-bindings: spi: nxp-fspi: add imx8ulp support", " - ARM: dts: imx6ul-geam: fix fsl,pins property in tscgrp pinctrl", " - ARM: dts: imx6ull-seeed-npi: fix fsl,pins property in tscgrp pinctrl", " - tools/nolibc: include arch.h from string.h", " - soc: versatile: realview: fix memory leak during device remove", " - soc: versatile: realview: fix soc_dev leak during device remove", " - usb: typec: ucsi: Call CANCEL from single location", " - usb: typec: ucsi: Fix busy loop on ASUS VivoBooks", " - soc: qcom: geni-se: add GP_LENGTH/IRQ_EN_SET/IRQ_EN_CLEAR registers", " - serial: qcom-geni: fix arg types for qcom_geni_serial_poll_bit()", " - serial: qcom-geni: introduce qcom_geni_serial_poll_bitfield()", " - serial: qcom-geni: fix console corruption", " - thermal: core: Store trip sysfs attributes in thermal_trip_desc", " - thermal: sysfs: Get to trips via attribute pointers", " - thermal: sysfs: Refine the handling of trip hysteresis changes", " - thermal: sysfs: Add sanity checks for trip temperature and hysteresis", " - bpf: lsm: Set bpf_lsm_blob_sizes.lbs_task to 0", " - compiler.h: specify correct attribute for .rodata..c_jump_table", " - lockdep: fix deadlock issue between lockdep and rcu", " - mm/hugetlb_vmemmap: batch HVO work when demoting", " - s390/ftrace: Avoid calling unwinder in ftrace_return_address()", " - selftest mm/mseal: fix test_seal_mremap_move_dontunmap_anyaddr", " - mm: only enforce minimum stack gap size if it's sensible", " - spi: fspi: add support for imx8ulp", " - module: Fix KCOV-ignored file name", " - fbdev: xen-fbfront: Assign fb_info->device", " - tpm: export tpm2_sessions_init() to fix ibmvtpm building", " - mm/huge_memory: ensure huge_zero_folio won't have large_rmappable flag set", " - mm: change vmf_anon_prepare() to __vmf_anon_prepare()", " - mm/damon/vaddr: protect vma traversal in __damon_va_thre_regions() with rcu", " read lock", " - i2c: aspeed: Update the stop sw state when the bus recovery occurs", " - i2c: isch: Add missed 'else'", " - i2c: xiic: Try re-initialization on bus busy timeout", " - Documentation: KVM: fix warning in \"make htmldocs\"", " - spi: atmel-quadspi: Fix wrong register value written to MR", " - Revert: \"dm-verity: restart or panic on an I/O error\"", " - Linux 6.11.2", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47675", " - bpf: Fix use-after-free in bpf_uprobe_multi_link_attach()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47676", " - mm/hugetlb.c: fix UAF of vma in hugetlb fault pathway", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47677", " - exfat: resolve memory leak from exfat_create_upcase_table()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47725", " - dm-verity: restart or panic on an I/O error", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47739", " - padata: use integer wrap around to prevent deadlock on seq_nr overflow", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47678", " - icmp: change the order of rate limits", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47733", " - netfs: Delete subtree of 'fs/netfs' when netfs module exits", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47679", " - vfs: fix race between evice_inodes() and find_inode()&iput()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49859", " - f2fs: fix to check atomic_file in f2fs ioctl interfaces", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47680", " - f2fs: check discard support for conventional zones", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47740", " - f2fs: Require FMODE_WRITE for atomic write ioctls", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47726", " - f2fs: fix to wait dio completion", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47741", " - btrfs: fix race setting file private on concurrent lseek using same fd", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47681", " - wifi: mt76: mt7996: fix NULL pointer dereference in mt7996_mcu_sta_bfer_he", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49858", " - efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49860", " - ACPI: sysfs: validate return type of _STR method", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47742", " - firmware_loader: Block path traversal", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47682", " - scsi: sd: Fix off-by-one error in sd_read_block_characteristics()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47743", " - KEYS: prevent NULL pointer dereference in find_asymmetric_key()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47727", " - x86/tdx: Fix \"in-kernel MMIO\" check", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47744", " - KVM: Use dedicated mutex to protect kvm_usage_count to avoid deadlock", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47719", " - iommufd: Protect against overflow of ALIGN() during iova allocation", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47745", " - mm: call the security_mmap_file() LSM hook in remap_file_pages()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47746", " - fuse: use exclusive lock when FUSE_I_CACHE_IO_MODE is set", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47734", " - bonding: Fix unnecessary warnings and logs from bond_xdp_get_xmit_slave()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47684", " - tcp: check skb is non-NULL in tcp_rto_delta_us()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47747", " - net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race", " Condition", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47685", " - netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47686", " - ep93xx: clock: Fix off by one in ep93xx_div_recalc_rate()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47748", " - vhost_vdpa: assign irq bypass producer token correctly", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47687", " - vdpa/mlx5: Fix invalid mr resource destroy", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47688", " - driver core: Fix a potential null-ptr-deref in module_add_driver()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47689", " - f2fs: fix to don't set SB_RDONLY in f2fs_handle_critical_error()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47690", " - f2fs: get rid of online repaire on corrupted directory", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47691", " - f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47692", " - nfsd: return -EINVAL when namelen is 0", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47737", " - nfsd: call cache_put if xdr_reserve_space returns NULL", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2023-52917", " - ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47749", " - RDMA/cxgb4: Added NULL check for lookup_atid", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47735", " - RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47750", " - RDMA/hns: Fix Use-After-Free of rsv_qp on HIP08", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47751", " - PCI: kirin: Fix buffer overflow in kirin_pcie_parse_port()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47693", " - IB/core: Fix ib_cache_setup_one error flow cleanup", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47694", " - IB/mlx5: Fix UMR pd cleanup on error flow of driver init", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47695", " - RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47752", " - media: mediatek: vcodec: Fix H264 stateless decoder smatch warning", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47753", " - media: mediatek: vcodec: Fix VP8 stateless decoder smatch warning", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47754", " - media: mediatek: vcodec: Fix H264 multi stateless decoder smatch warning", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47696", " - RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47755", " - nvdimm: Fix devs leaks in scan_labels()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47756", " - PCI: keystone: Fix if-statement expression in ks_pcie_quirk()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47697", " - drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47698", " - drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47728", " - bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49861", " - bpf: Fix helper writes to read-only maps", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47757", " - nilfs2: fix potential oob read in nilfs_btree_check_delete()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47699", " - nilfs2: fix potential null-ptr-deref in nilfs_btree_insert()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47700", " - ext4: check stripe size compatibility on remount as well", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47701", " - ext4: avoid OOB when system.data xattr changes underneath the filesystem", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49850", " - bpf: correctly handle malformed BPF_CORE_TYPE_ID_LOCAL relos", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47702", " - bpf: Fail verification for sign-extension of packet data/data_end/data_meta", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47703", " - bpf, lsm: Add check for BPF LSM return value", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49851", " - tpm: Clean up TPM space after command failure", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47723", " - jfs: fix out-of-bounds in dbNextAG() and diAlloc()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49852", " - scsi: elx: libefc: Fix potential use after free in efc_nport_vport_del()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47720", " - drm/amd/display: Add null check for set_output_gamma in", " dcn30_set_output_transfer_func", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47704", " - drm/amd/display: Check link_res->hpo_dp_link_enc before using it", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49853", " - firmware: arm_scmi: Fix double free in OPTEE transport", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47705", " - block: fix potential invalid pointer dereference in blk_add_partition", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47736", " - erofs: handle overlapped pclusters out of crafted images properly", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47706", " - block, bfq: fix possible UAF for bfqq->bic with merge chain", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49855", " - nbd: fix race between timeout and normal completion", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47707", " - ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47708", " - netkit: Assign missing bpf_net_context", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47709", " - can: bcm: Clear bo->bcm_proc_read after remove_proc_entry().", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47710", " - sock_map: Add a cond_resched() in sock_hash_free()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47711", " - af_unix: Don't return OOB skb in manage_oob().", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47712", " - wifi: wilc1000: fix potential RCU dereference issue in", " wilc_parse_join_bss_param", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47713", " - wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47730", " - crypto: hisilicon/qm - inject error before stopping queue", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49856", " - x86/sgx: Fix deadlock in SGX NUMA node search", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47714", " - wifi: mt76: mt7996: use hweight16 to get correct tx antenna", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47715", " - wifi: mt76: mt7915: fix oops on non-dbdc mt7986", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49857", " - wifi: iwlwifi: mvm: set the cipher for secured NDP ranging", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47738", " - wifi: mac80211: don't use rate mask for offchannel TX either", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47731", " - drivers/perf: Fix ali_drw_pmu driver interrupt status clearing", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49862", " - powercap: intel_rapl: Fix off by one in get_rpi()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47716", " - ARM: 9410/1: vfp: Use asm volatile in fmrx/fmxr macros", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47717", " - RISC-V: KVM: Don't zero-out PMU snapshot area before freeing data", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47721", " - wifi: rtw89: remove unused C2H event ID RTW89_MAC_C2H_FUNC_READ_WOW_CAM to", " prevent out-of-bounds reading", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47732", " - crypto: iaa - Fix potential use after free bug", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47718", " - wifi: rtw88: always wait for both firmware loading attempts", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47724", " - wifi: ath11k: use work queue to process beacon tx event", "", " * Oracular update: v6.11.1 upstream stable release (LP: #2089020)", " - powercap/intel_rapl: Add support for AMD family 1Ah", " - powercap/intel_rapl: Fix the energy-pkg event for AMD CPUs", " - cpufreq/amd-pstate: Add the missing cpufreq_cpu_put()", " - netfilter: nft_socket: Fix a NULL vs IS_ERR() bug in", " nft_socket_cgroup_subtree_level()", " - ASoC: amd: acp: add ZSC control register programming sequence", " - nvme-pci: qdepth 1 quirk", " - USB: serial: pl2303: add device id for Macrosilicon MS3020", " - powercap: intel_rapl: Change an error pointer to NULL", " - Linux 6.11.1", "", " * Oracular update: v6.11.1 upstream stable release (LP: #2089020) //", " CVE-2024-47671", " - USB: usbtmc: prevent kernel-usb-infoleak", "", " * Oracular update: v6.11.1 upstream stable release (LP: #2089020) //", " CVE-2024-46869", " - Bluetooth: btintel_pcie: Allocate memory for driver private data", "", " * CVE-2024-53164", " - net: sched: fix ordering of qlen adjustment", "", " * CVE-2024-53103", " - hv_sock: Initializing vsk->trans to NULL to prevent a dangling pointer", "" ], "package": "linux", "version": "6.11.0-17.17", "urgency": "medium", "distributions": "oracular", "launchpad_bugs_fixed": [ 2093643, 1786013, 2091744, 2091184, 2093146, 2085406, 2089684, 2090932, 2085485, 2089357, 2089306, 2091655, 2091655, 2091655, 2091655, 2091655, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091386, 2091990, 2089327, 2089113, 2086587, 2086606, 2085950, 2085944, 2087853, 2087983, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089020, 2089020, 2089020 ], "author": "Stefan Bader ", "date": "Thu, 16 Jan 2025 22:38:59 +0100" } ], "notes": null }, { "name": "linux-tools-common", "from_version": { "source_package_name": "linux", "source_package_version": "6.11.0-14.15", "version": "6.11.0-14.15" }, "to_version": { "source_package_name": "linux", "source_package_version": "6.11.0-18.18", "version": "6.11.0-18.18" }, "cves": [ { "cve": "CVE-2025-0927", "url": "https://ubuntu.com/security/CVE-2025-0927", "cve_description": "[fs: hfs/hfsplus: add key_len boundary check to hfs_bnode_read_key]", "cve_priority": "medium", "cve_public_date": "2025-02-13" }, { "cve": "CVE-2024-53141", "url": "https://ubuntu.com/security/CVE-2024-53141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: add missing range check in bitmap_ip_uadt When tb[IPSET_ATTR_IP_TO] is not present but tb[IPSET_ATTR_CIDR] exists, the values of ip and ip_to are slightly swapped. Therefore, the range check for ip should be done later, but this part is missing and it seems that the vulnerability occurs. So we should add missing range checks and remove unnecessary range checks.", "cve_priority": "medium", "cve_public_date": "2024-12-06 10:15:00 UTC" }, { "cve": "CVE-2024-50010", "url": "https://ubuntu.com/security/CVE-2024-50010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exec: don't WARN for racy path_noexec check Both i_mode and noexec checks wrapped in WARN_ON stem from an artifact of the previous implementation. They used to legitimately check for the condition, but that got moved up in two commits: 633fb6ac3980 (\"exec: move S_ISREG() check earlier\") 0fd338b2d2cd (\"exec: move path_noexec() check earlier\") Instead of being removed said checks are WARN_ON'ed instead, which has some debug value. However, the spurious path_noexec check is racy, resulting in unwarranted warnings should someone race with setting the noexec flag. One can note there is more to perm-checking whether execve is allowed and none of the conditions are guaranteed to still hold after they were tested for. Additionally this does not validate whether the code path did any perm checking to begin with -- it will pass if the inode happens to be regular. Keep the redundant path_noexec() check even though it's mindless nonsense checking for guarantee that isn't given so drop the WARN. Reword the commentary and do small tidy ups while here. [brauner: keep redundant path_noexec() check]", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-53143", "url": "https://ubuntu.com/security/CVE-2024-53143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fsnotify: Fix ordering of iput() and watched_objects decrement Ensure the superblock is kept alive until we're done with iput(). Holding a reference to an inode is not allowed unless we ensure the superblock stays alive, which fsnotify does by keeping the watched_objects count elevated, so iput() must happen before the watched_objects decrement. This can lead to a UAF of something like sb->s_fs_info in tmpfs, but the UAF is hard to hit because race orderings that oops are more likely, thanks to the CHECK_DATA_CORRUPTION() block in generic_shutdown_super(). Also, ensure that fsnotify_put_sb_watched_objects() doesn't call fsnotify_sb_watched_objects() on a superblock that may have already been freed, which would cause a UAF read of sb->s_fsnotify_info.", "cve_priority": "medium", "cve_public_date": "2024-12-07 07:15:00 UTC" }, { "cve": "CVE-2024-53142", "url": "https://ubuntu.com/security/CVE-2024-53142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: initramfs: avoid filename buffer overrun The initramfs filename field is defined in Documentation/driver-api/early-userspace/buffer-format.rst as: 37 cpio_file := ALGN(4) + cpio_header + filename + \"\\0\" + ALGN(4) + data ... 55 ============= ================== ========================= 56 Field name Field size Meaning 57 ============= ================== ========================= ... 70 c_namesize 8 bytes Length of filename, including final \\0 When extracting an initramfs cpio archive, the kernel's do_name() path handler assumes a zero-terminated path at @collected, passing it directly to filp_open() / init_mkdir() / init_mknod(). If a specially crafted cpio entry carries a non-zero-terminated filename and is followed by uninitialized memory, then a file may be created with trailing characters that represent the uninitialized memory. The ability to create an initramfs entry would imply already having full control of the system, so the buffer overrun shouldn't be considered a security vulnerability. Append the output of the following bash script to an existing initramfs and observe any created /initramfs_test_fname_overrunAA* path. E.g. ./reproducer.sh | gzip >> /myinitramfs It's easiest to observe non-zero uninitialized memory when the output is gzipped, as it'll overflow the heap allocated @out_buf in __gunzip(), rather than the initrd_start+initrd_size block. ---- reproducer.sh ---- nilchar=\"A\"\t# change to \"\\0\" to properly zero terminate / pad magic=\"070701\" ino=1 mode=$(( 0100777 )) uid=0 gid=0 nlink=1 mtime=1 filesize=0 devmajor=0 devminor=1 rdevmajor=0 rdevminor=0 csum=0 fname=\"initramfs_test_fname_overrun\" namelen=$(( ${#fname} + 1 ))\t# plus one to account for terminator printf \"%s%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%s\" \\ \t$magic $ino $mode $uid $gid $nlink $mtime $filesize \\ \t$devmajor $devminor $rdevmajor $rdevminor $namelen $csum $fname termpadlen=$(( 1 + ((4 - ((110 + $namelen) & 3)) % 4) )) printf \"%.s${nilchar}\" $(seq 1 $termpadlen) ---- reproducer.sh ---- Symlink filename fields handled in do_symlink() won't overrun past the data segment, due to the explicit zero-termination of the symlink target. Fix filename buffer overrun by aborting the initramfs FSM if any cpio entry doesn't carry a zero-terminator at the expected (name_len - 1) offset.", "cve_priority": "medium", "cve_public_date": "2024-12-06 10:15:00 UTC" }, { "cve": "CVE-2024-53133", "url": "https://ubuntu.com/security/CVE-2024-53133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Handle dml allocation failure to avoid crash [Why] In the case where a dml allocation fails for any reason, the current state's dml contexts would no longer be valid. Then subsequent calls dc_state_copy_internal would shallow copy invalid memory and if the new state was released, a double free would occur. [How] Reset dml pointers in new_state to NULL and avoid invalid pointer (cherry picked from commit bcafdc61529a48f6f06355d78eb41b3aeda5296c)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53108", "url": "https://ubuntu.com/security/CVE-2024-53108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Adjust VSDB parser for replay feature At some point, the IEEE ID identification for the replay check in the AMD EDID was added. However, this check causes the following out-of-bounds issues when using KASAN: [ 27.804016] BUG: KASAN: slab-out-of-bounds in amdgpu_dm_update_freesync_caps+0xefa/0x17a0 [amdgpu] [ 27.804788] Read of size 1 at addr ffff8881647fdb00 by task systemd-udevd/383 ... [ 27.821207] Memory state around the buggy address: [ 27.821215] ffff8881647fda00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821224] ffff8881647fda80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821234] >ffff8881647fdb00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821243] ^ [ 27.821250] ffff8881647fdb80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821259] ffff8881647fdc00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821268] ================================================================== This is caused because the ID extraction happens outside of the range of the edid lenght. This commit addresses this issue by considering the amd_vsdb_block size. (cherry picked from commit b7e381b1ccd5e778e3d9c44c669ad38439a861d8)", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53134", "url": "https://ubuntu.com/security/CVE-2024-53134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pmdomain: imx93-blk-ctrl: correct remove path The check condition should be 'i < bc->onecell_data.num_domains', not 'bc->onecell_data.num_domains' which will make the look never finish and cause kernel panic. Also disable runtime to address \"imx93-blk-ctrl 4ac10000.system-controller: Unbalanced pm_runtime_enable!\"", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53132", "url": "https://ubuntu.com/security/CVE-2024-53132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/oa: Fix \"Missing outer runtime PM protection\" warning Fix the following drm_WARN: [953.586396] xe 0000:00:02.0: [drm] Missing outer runtime PM protection ... <4> [953.587090] ? xe_pm_runtime_get_noresume+0x8d/0xa0 [xe] <4> [953.587208] guc_exec_queue_add_msg+0x28/0x130 [xe] <4> [953.587319] guc_exec_queue_fini+0x3a/0x40 [xe] <4> [953.587425] xe_exec_queue_destroy+0xb3/0xf0 [xe] <4> [953.587515] xe_oa_release+0x9c/0xc0 [xe] (cherry picked from commit b107c63d2953907908fd0cafb0e543b3c3167b75)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53127", "url": "https://ubuntu.com/security/CVE-2024-53127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Revert \"mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K\" The commit 8396c793ffdf (\"mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K\") increased the max_req_size, even for 4K pages, causing various issues: - Panic booting the kernel/rootfs from an SD card on Rockchip RK3566 - Panic booting the kernel/rootfs from an SD card on StarFive JH7100 - \"swiotlb buffer is full\" and data corruption on StarFive JH7110 At this stage no fix have been found, so it's probably better to just revert the change. This reverts commit 8396c793ffdf28bb8aee7cfe0891080f8cab7890.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53130", "url": "https://ubuntu.com/security/CVE-2024-53130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint When using the \"block:block_dirty_buffer\" tracepoint, mark_buffer_dirty() may cause a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because, since the tracepoint was added in mark_buffer_dirty(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, nilfs_grab_buffer(), which grabs a buffer to read (or create) a block of metadata, including b-tree node blocks, does not set the block device, but instead does so only if the buffer is not in the \"uptodate\" state for each of its caller block reading functions. However, if the uptodate flag is set on a folio/page, and the buffer heads are detached from it by try_to_free_buffers(), and new buffer heads are then attached by create_empty_buffers(), the uptodate flag may be restored to each buffer without the block device being set to bh->b_bdev, and mark_buffer_dirty() may be called later in that state, resulting in the bug mentioned above. Fix this issue by making nilfs_grab_buffer() always set the block device of the super block structure to the buffer head, regardless of the state of the buffer's uptodate flag.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53105", "url": "https://ubuntu.com/security/CVE-2024-53105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: page_alloc: move mlocked flag clearance into free_pages_prepare() Syzbot reported a bad page state problem caused by a page being freed using free_page() still having a mlocked flag at free_pages_prepare() stage: BUG: Bad page state in process syz.5.504 pfn:61f45 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x61f45 flags: 0xfff00000080204(referenced|workingset|mlocked|node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000080204 0000000000000000 dead000000000122 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set page_owner tracks the page as allocated page last allocated via order 0, migratetype Unmovable, gfp_mask 0x400dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO), pid 8443, tgid 8442 (syz.5.504), ts 201884660643, free_ts 201499827394 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1537 prep_new_page mm/page_alloc.c:1545 [inline] get_page_from_freelist+0x303f/0x3190 mm/page_alloc.c:3457 __alloc_pages_noprof+0x292/0x710 mm/page_alloc.c:4733 alloc_pages_mpol_noprof+0x3e8/0x680 mm/mempolicy.c:2265 kvm_coalesced_mmio_init+0x1f/0xf0 virt/kvm/coalesced_mmio.c:99 kvm_create_vm virt/kvm/kvm_main.c:1235 [inline] kvm_dev_ioctl_create_vm virt/kvm/kvm_main.c:5488 [inline] kvm_dev_ioctl+0x12dc/0x2240 virt/kvm/kvm_main.c:5530 __do_compat_sys_ioctl fs/ioctl.c:1007 [inline] __se_compat_sys_ioctl+0x510/0xc90 fs/ioctl.c:950 do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline] __do_fast_syscall_32+0xb4/0x110 arch/x86/entry/common.c:386 do_fast_syscall_32+0x34/0x80 arch/x86/entry/common.c:411 entry_SYSENTER_compat_after_hwframe+0x84/0x8e page last free pid 8399 tgid 8399 stack trace: reset_page_owner include/linux/page_owner.h:25 [inline] free_pages_prepare mm/page_alloc.c:1108 [inline] free_unref_folios+0xf12/0x18d0 mm/page_alloc.c:2686 folios_put_refs+0x76c/0x860 mm/swap.c:1007 free_pages_and_swap_cache+0x5c8/0x690 mm/swap_state.c:335 __tlb_batch_free_encoded_pages mm/mmu_gather.c:136 [inline] tlb_batch_pages_flush mm/mmu_gather.c:149 [inline] tlb_flush_mmu_free mm/mmu_gather.c:366 [inline] tlb_flush_mmu+0x3a3/0x680 mm/mmu_gather.c:373 tlb_finish_mmu+0xd4/0x200 mm/mmu_gather.c:465 exit_mmap+0x496/0xc40 mm/mmap.c:1926 __mmput+0x115/0x390 kernel/fork.c:1348 exit_mm+0x220/0x310 kernel/exit.c:571 do_exit+0x9b2/0x28e0 kernel/exit.c:926 do_group_exit+0x207/0x2c0 kernel/exit.c:1088 __do_sys_exit_group kernel/exit.c:1099 [inline] __se_sys_exit_group kernel/exit.c:1097 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1097 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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 Modules linked in: CPU: 0 UID: 0 PID: 8442 Comm: syz.5.504 Not tainted 6.12.0-rc6-syzkaller #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 bad_page+0x176/0x1d0 mm/page_alloc.c:501 free_page_is_bad mm/page_alloc.c:918 [inline] free_pages_prepare mm/page_alloc.c:1100 [inline] free_unref_page+0xed0/0xf20 mm/page_alloc.c:2638 kvm_destroy_vm virt/kvm/kvm_main.c:1327 [inline] kvm_put_kvm+0xc75/0x1350 virt/kvm/kvm_main.c:1386 kvm_vcpu_release+0x54/0x60 virt/kvm/kvm_main.c:4143 __fput+0x23f/0x880 fs/file_table.c:431 task_work_run+0x24f/0x310 kernel/task_work.c:239 exit_task_work include/linux/task_work.h:43 [inline] do_exit+0xa2f/0x28e0 kernel/exit.c:939 do_group_exit+0x207/0x2c0 kernel/exit.c:1088 __do_sys_exit_group kernel/exit.c:1099 [in ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53109", "url": "https://ubuntu.com/security/CVE-2024-53109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nommu: pass NULL argument to vma_iter_prealloc() When deleting a vma entry from a maple tree, it has to pass NULL to vma_iter_prealloc() in order to calculate internal state of the tree, but it passed a wrong argument. As a result, nommu kernels crashed upon accessing a vma iterator, such as acct_collect() reading the size of vma entries after do_munmap(). This commit fixes this issue by passing a right argument to the preallocation call.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53131", "url": "https://ubuntu.com/security/CVE-2024-53131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint Patch series \"nilfs2: fix null-ptr-deref bugs on block tracepoints\". This series fixes null pointer dereference bugs that occur when using nilfs2 and two block-related tracepoints. This patch (of 2): It has been reported that when using \"block:block_touch_buffer\" tracepoint, touch_buffer() called from __nilfs_get_folio_block() causes a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because since the tracepoint was added in touch_buffer(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, the block_device structure is set after the function returns to the caller. Here, touch_buffer() is used to mark the folio/page that owns the buffer head as accessed, but the common search helper for folio/page used by the caller function was optimized to mark the folio/page as accessed when it was reimplemented a long time ago, eliminating the need to call touch_buffer() here in the first place. So this solves the issue by eliminating the touch_buffer() call itself.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53135", "url": "https://ubuntu.com/security/CVE-2024-53135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: VMX: Bury Intel PT virtualization (guest/host mode) behind CONFIG_BROKEN Hide KVM's pt_mode module param behind CONFIG_BROKEN, i.e. disable support for virtualizing Intel PT via guest/host mode unless BROKEN=y. There are myriad bugs in the implementation, some of which are fatal to the guest, and others which put the stability and health of the host at risk. For guest fatalities, the most glaring issue is that KVM fails to ensure tracing is disabled, and *stays* disabled prior to VM-Enter, which is necessary as hardware disallows loading (the guest's) RTIT_CTL if tracing is enabled (enforced via a VMX consistency check). Per the SDM: If the logical processor is operating with Intel PT enabled (if IA32_RTIT_CTL.TraceEn = 1) at the time of VM entry, the \"load IA32_RTIT_CTL\" VM-entry control must be 0. On the host side, KVM doesn't validate the guest CPUID configuration provided by userspace, and even worse, uses the guest configuration to decide what MSRs to save/load at VM-Enter and VM-Exit. E.g. configuring guest CPUID to enumerate more address ranges than are supported in hardware will result in KVM trying to passthrough, save, and load non-existent MSRs, which generates a variety of WARNs, ToPA ERRORs in the host, a potential deadlock, etc.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53106", "url": "https://ubuntu.com/security/CVE-2024-53106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: fix buffer overrun in ima_eventdigest_init_common Function ima_eventdigest_init() calls ima_eventdigest_init_common() with HASH_ALGO__LAST which is then used to access the array hash_digest_size[] leading to buffer overrun. Have a conditional statement to handle this.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53110", "url": "https://ubuntu.com/security/CVE-2024-53110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vp_vdpa: fix id_table array not null terminated error Allocate one extra virtio_device_id as null terminator, otherwise vdpa_mgmtdev_get_classes() may iterate multiple times and visit undefined memory.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53126", "url": "https://ubuntu.com/security/CVE-2024-53126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa: solidrun: Fix UB bug with devres In psnet_open_pf_bar() and snet_open_vf_bar() a string later passed to pcim_iomap_regions() is placed on the stack. Neither pcim_iomap_regions() nor the functions it calls copy that string. Should the string later ever be used, this, consequently, causes undefined behavior since the stack frame will by then have disappeared. Fix the bug by allocating the strings on the heap through devm_kasprintf().", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53111", "url": "https://ubuntu.com/security/CVE-2024-53111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mremap: fix address wraparound in move_page_tables() On 32-bit platforms, it is possible for the expression `len + old_addr < old_end` to be false-positive if `len + old_addr` wraps around. `old_addr` is the cursor in the old range up to which page table entries have been moved; so if the operation succeeded, `old_addr` is the *end* of the old region, and adding `len` to it can wrap. The overflow causes mremap() to mistakenly believe that PTEs have been copied; the consequence is that mremap() bails out, but doesn't move the PTEs back before the new VMA is unmapped, causing anonymous pages in the region to be lost. So basically if userspace tries to mremap() a private-anon region and hits this bug, mremap() will return an error and the private-anon region's contents appear to have been zeroed. The idea of this check is that `old_end - len` is the original start address, and writing the check that way also makes it easier to read; so fix the check by rearranging the comparison accordingly. (An alternate fix would be to refactor this function by introducing an \"orig_old_start\" variable or such.) Tested in a VM with a 32-bit X86 kernel; without the patch: ``` user@horn:~/big_mremap$ cat test.c #define _GNU_SOURCE #include #include #include #include #define ADDR1 ((void*)0x60000000) #define ADDR2 ((void*)0x10000000) #define SIZE 0x50000000uL int main(void) { unsigned char *p1 = mmap(ADDR1, SIZE, PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0); if (p1 == MAP_FAILED) err(1, \"mmap 1\"); unsigned char *p2 = mmap(ADDR2, SIZE, PROT_NONE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0); if (p2 == MAP_FAILED) err(1, \"mmap 2\"); *p1 = 0x41; printf(\"first char is 0x%02hhx\\n\", *p1); unsigned char *p3 = mremap(p1, SIZE, SIZE, MREMAP_MAYMOVE|MREMAP_FIXED, p2); if (p3 == MAP_FAILED) { printf(\"mremap() failed; first char is 0x%02hhx\\n\", *p1); } else { printf(\"mremap() succeeded; first char is 0x%02hhx\\n\", *p3); } } user@horn:~/big_mremap$ gcc -static -o test test.c user@horn:~/big_mremap$ setarch -R ./test first char is 0x41 mremap() failed; first char is 0x00 ``` With the patch: ``` user@horn:~/big_mremap$ setarch -R ./test first char is 0x41 mremap() succeeded; first char is 0x41 ```", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53107", "url": "https://ubuntu.com/security/CVE-2024-53107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: prevent integer overflow in pagemap_scan_get_args() The \"arg->vec_len\" variable is a u64 that comes from the user at the start of the function. The \"arg->vec_len * sizeof(struct page_region))\" multiplication can lead to integer wrapping. Use size_mul() to avoid that. Also the size_add/mul() functions work on unsigned long so for 32bit systems we need to ensure that \"arg->vec_len\" fits in an unsigned long.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53128", "url": "https://ubuntu.com/security/CVE-2024-53128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/task_stack: fix object_is_on_stack() for KASAN tagged pointers When CONFIG_KASAN_SW_TAGS and CONFIG_KASAN_STACK are enabled, the object_is_on_stack() function may produce incorrect results due to the presence of tags in the obj pointer, while the stack pointer does not have tags. This discrepancy can lead to incorrect stack object detection and subsequently trigger warnings if CONFIG_DEBUG_OBJECTS is also enabled. Example of the warning: ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at lib/debugobjects.c:557 __debug_object_init+0x330/0x364 Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5 #4 Hardware name: linux,dummy-virt (DT) pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __debug_object_init+0x330/0x364 lr : __debug_object_init+0x330/0x364 sp : ffff800082ea7b40 x29: ffff800082ea7b40 x28: 98ff0000c0164518 x27: 98ff0000c0164534 x26: ffff800082d93ec8 x25: 0000000000000001 x24: 1cff0000c00172a0 x23: 0000000000000000 x22: ffff800082d93ed0 x21: ffff800081a24418 x20: 3eff800082ea7bb0 x19: efff800000000000 x18: 0000000000000000 x17: 00000000000000ff x16: 0000000000000047 x15: 206b63617473206e x14: 0000000000000018 x13: ffff800082ea7780 x12: 0ffff800082ea78e x11: 0ffff800082ea790 x10: 0ffff800082ea79d x9 : 34d77febe173e800 x8 : 34d77febe173e800 x7 : 0000000000000001 x6 : 0000000000000001 x5 : feff800082ea74b8 x4 : ffff800082870a90 x3 : ffff80008018d3c4 x2 : 0000000000000001 x1 : ffff800082858810 x0 : 0000000000000050 Call trace: __debug_object_init+0x330/0x364 debug_object_init_on_stack+0x30/0x3c schedule_hrtimeout_range_clock+0xac/0x26c schedule_hrtimeout+0x1c/0x30 wait_task_inactive+0x1d4/0x25c kthread_bind_mask+0x28/0x98 init_rescuer+0x1e8/0x280 workqueue_init+0x1a0/0x3cc kernel_init_freeable+0x118/0x200 kernel_init+0x28/0x1f0 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53112", "url": "https://ubuntu.com/security/CVE-2024-53112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: uncache inode which has failed entering the group Syzbot has reported the following BUG: kernel BUG at fs/ocfs2/uptodate.c:509! ... Call Trace: ? __die_body+0x5f/0xb0 ? die+0x9e/0xc0 ? do_trap+0x15a/0x3a0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? do_error_trap+0x1dc/0x2c0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? __pfx_do_error_trap+0x10/0x10 ? handle_invalid_op+0x34/0x40 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? exc_invalid_op+0x38/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? ocfs2_set_new_buffer_uptodate+0x2e/0x160 ? ocfs2_set_new_buffer_uptodate+0x144/0x160 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ocfs2_group_add+0x39f/0x15a0 ? __pfx_ocfs2_group_add+0x10/0x10 ? __pfx_lock_acquire+0x10/0x10 ? mnt_get_write_access+0x68/0x2b0 ? __pfx_lock_release+0x10/0x10 ? rcu_read_lock_any_held+0xb7/0x160 ? __pfx_rcu_read_lock_any_held+0x10/0x10 ? smack_log+0x123/0x540 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x226/0x2b0 ocfs2_ioctl+0x65e/0x7d0 ? __pfx_ocfs2_ioctl+0x10/0x10 ? smack_file_ioctl+0x29e/0x3a0 ? __pfx_smack_file_ioctl+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x43d/0x780 ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10 ? __pfx_ocfs2_ioctl+0x10/0x10 __se_sys_ioctl+0xfb/0x170 do_syscall_64+0xf3/0x230 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... When 'ioctl(OCFS2_IOC_GROUP_ADD, ...)' has failed for the particular inode in 'ocfs2_verify_group_and_input()', corresponding buffer head remains cached and subsequent call to the same 'ioctl()' for the same inode issues the BUG() in 'ocfs2_set_new_buffer_uptodate()' (trying to cache the same buffer head of that inode). Fix this by uncaching the buffer head with 'ocfs2_remove_from_cache()' on error path in 'ocfs2_group_add()'.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53113", "url": "https://ubuntu.com/security/CVE-2024-53113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: fix NULL pointer dereference in alloc_pages_bulk_noprof We triggered a NULL pointer dereference for ac.preferred_zoneref->zone in alloc_pages_bulk_noprof() when the task is migrated between cpusets. When cpuset is enabled, in prepare_alloc_pages(), ac->nodemask may be ¤t->mems_allowed. when first_zones_zonelist() is called to find preferred_zoneref, the ac->nodemask may be modified concurrently if the task is migrated between different cpusets. Assuming we have 2 NUMA Node, when traversing Node1 in ac->zonelist, the nodemask is 2, and when traversing Node2 in ac->zonelist, the nodemask is 1. As a result, the ac->preferred_zoneref points to NULL zone. In alloc_pages_bulk_noprof(), for_each_zone_zonelist_nodemask() finds a allowable zone and calls zonelist_node_idx(ac.preferred_zoneref), leading to NULL pointer dereference. __alloc_pages_noprof() fixes this issue by checking NULL pointer in commit ea57485af8f4 (\"mm, page_alloc: fix check for NULL preferred_zone\") and commit df76cee6bbeb (\"mm, page_alloc: remove redundant checks from alloc fastpath\"). To fix it, check NULL pointer for preferred_zoneref->zone.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53114", "url": "https://ubuntu.com/security/CVE-2024-53114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 client A number of Zen4 client SoCs advertise the ability to use virtualized VMLOAD/VMSAVE, but using these instructions is reported to be a cause of a random host reboot. These instructions aren't intended to be advertised on Zen4 client so clear the capability.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53137", "url": "https://ubuntu.com/security/CVE-2024-53137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: fix cacheflush with PAN It seems that the cacheflush syscall got broken when PAN for LPAE was implemented. User access was not enabled around the cache maintenance instructions, causing them to fault.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53115", "url": "https://ubuntu.com/security/CVE-2024-53115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: avoid null_ptr_deref in vmw_framebuffer_surface_create_handle The 'vmw_user_object_buffer' function may return NULL with incorrect inputs. To avoid possible null pointer dereference, add a check whether the 'bo' is NULL in the vmw_framebuffer_surface_create_handle.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53116", "url": "https://ubuntu.com/security/CVE-2024-53116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix handling of partial GPU mapping of BOs This commit fixes the bug in the handling of partial mapping of the buffer objects to the GPU, which caused kernel warnings. Panthor didn't correctly handle the case where the partial mapping spanned multiple scatterlists and the mapping offset didn't point to the 1st page of starting scatterlist. The offset variable was not cleared after reaching the starting scatterlist. Following warning messages were seen. WARNING: CPU: 1 PID: 650 at drivers/iommu/io-pgtable-arm.c:659 __arm_lpae_unmap+0x254/0x5a0 pc : __arm_lpae_unmap+0x254/0x5a0 lr : __arm_lpae_unmap+0x2cc/0x5a0 Call trace: __arm_lpae_unmap+0x254/0x5a0 __arm_lpae_unmap+0x108/0x5a0 __arm_lpae_unmap+0x108/0x5a0 __arm_lpae_unmap+0x108/0x5a0 arm_lpae_unmap_pages+0x80/0xa0 panthor_vm_unmap_pages+0xac/0x1c8 [panthor] panthor_gpuva_sm_step_unmap+0x4c/0xc8 [panthor] op_unmap_cb.isra.23.constprop.30+0x54/0x80 __drm_gpuvm_sm_unmap+0x184/0x1c8 drm_gpuvm_sm_unmap+0x40/0x60 panthor_vm_exec_op+0xa8/0x120 [panthor] panthor_vm_bind_exec_sync_op+0xc4/0xe8 [panthor] panthor_ioctl_vm_bind+0x10c/0x170 [panthor] drm_ioctl_kernel+0xbc/0x138 drm_ioctl+0x210/0x4b0 __arm64_sys_ioctl+0xb0/0xf8 invoke_syscall+0x4c/0x110 el0_svc_common.constprop.1+0x98/0xf8 do_el0_svc+0x24/0x38 el0_svc+0x34/0xc8 el0t_64_sync_handler+0xa0/0xc8 el0t_64_sync+0x174/0x178 panthor : [drm] drm_WARN_ON(unmapped_sz != pgsize * pgcount) WARNING: CPU: 1 PID: 650 at drivers/gpu/drm/panthor/panthor_mmu.c:922 panthor_vm_unmap_pages+0x124/0x1c8 [panthor] pc : panthor_vm_unmap_pages+0x124/0x1c8 [panthor] lr : panthor_vm_unmap_pages+0x124/0x1c8 [panthor] panthor : [drm] *ERROR* failed to unmap range ffffa388f000-ffffa3890000 (requested range ffffa388c000-ffffa3890000)", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53117", "url": "https://ubuntu.com/security/CVE-2024-53117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio/vsock: Improve MSG_ZEROCOPY error handling Add a missing kfree_skb() to prevent memory leaks.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53118", "url": "https://ubuntu.com/security/CVE-2024-53118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Fix sk_error_queue memory leak Kernel queues MSG_ZEROCOPY completion notifications on the error queue. Where they remain, until explicitly recv()ed. To prevent memory leaks, clean up the queue when the socket is destroyed. unreferenced object 0xffff8881028beb00 (size 224): comm \"vsock_test\", pid 1218, jiffies 4294694897 hex dump (first 32 bytes): 90 b0 21 17 81 88 ff ff 90 b0 21 17 81 88 ff ff ..!.......!..... 00 00 00 00 00 00 00 00 00 b0 21 17 81 88 ff ff ..........!..... backtrace (crc 6c7031ca): [] kmem_cache_alloc_node_noprof+0x2f7/0x370 [] __alloc_skb+0x132/0x180 [] sock_omalloc+0x4b/0x80 [] msg_zerocopy_realloc+0x9e/0x240 [] virtio_transport_send_pkt_info+0x412/0x4c0 [] virtio_transport_stream_enqueue+0x43/0x50 [] vsock_connectible_sendmsg+0x373/0x450 [] ____sys_sendmsg+0x365/0x3a0 [] ___sys_sendmsg+0x84/0xd0 [] __sys_sendmsg+0x47/0x80 [] do_syscall_64+0x93/0x180 [] entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53119", "url": "https://ubuntu.com/security/CVE-2024-53119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio/vsock: Fix accept_queue memory leak As the final stages of socket destruction may be delayed, it is possible that virtio_transport_recv_listen() will be called after the accept_queue has been flushed, but before the SOCK_DONE flag has been set. As a result, sockets enqueued after the flush would remain unremoved, leading to a memory leak. vsock_release __vsock_release lock virtio_transport_release virtio_transport_close schedule_delayed_work(close_work) sk_shutdown = SHUTDOWN_MASK (!) flush accept_queue release virtio_transport_recv_pkt vsock_find_bound_socket lock if flag(SOCK_DONE) return virtio_transport_recv_listen child = vsock_create_connected (!) vsock_enqueue_accept(child) release close_work lock virtio_transport_do_close set_flag(SOCK_DONE) virtio_transport_remove_sock vsock_remove_sock vsock_remove_bound release Introduce a sk_shutdown check to disallow vsock_enqueue_accept() during socket destruction. unreferenced object 0xffff888109e3f800 (size 2040): comm \"kworker/5:2\", pid 371, jiffies 4294940105 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00 (..@............ backtrace (crc 9e5f4e84): [] kmem_cache_alloc_noprof+0x2c1/0x360 [] sk_prot_alloc+0x30/0x120 [] sk_alloc+0x2c/0x4b0 [] __vsock_create.constprop.0+0x2a/0x310 [] virtio_transport_recv_pkt+0x4dc/0x9a0 [] vsock_loopback_work+0xfd/0x140 [] process_one_work+0x20c/0x570 [] worker_thread+0x1bf/0x3a0 [] kthread+0xdd/0x110 [] ret_from_fork+0x2d/0x50 [] ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53120", "url": "https://ubuntu.com/security/CVE-2024-53120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: CT: Fix null-ptr-deref in add rule err flow In error flow of mlx5_tc_ct_entry_add_rule(), in case ct_rule_add() callback returns error, zone_rule->attr is used uninitiated. Fix it to use attr which has the needed pointer value. Kernel log: BUG: kernel NULL pointer dereference, address: 0000000000000110 RIP: 0010:mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core] … Call Trace: ? __die+0x20/0x70 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x140 ? asm_exc_page_fault+0x22/0x30 ? mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core] ? mlx5_tc_ct_entry_add_rule+0x1d5/0x2f0 [mlx5_core] mlx5_tc_ct_block_flow_offload+0xc6a/0xf90 [mlx5_core] ? nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] flow_offload_work_handler+0x142/0x320 [nf_flow_table] ? finish_task_switch.isra.0+0x15b/0x2b0 process_one_work+0x16c/0x320 worker_thread+0x28c/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xb8/0xf0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53138", "url": "https://ubuntu.com/security/CVE-2024-53138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: kTLS, Fix incorrect page refcounting The kTLS tx handling code is using a mix of get_page() and page_ref_inc() APIs to increment the page reference. But on the release path (mlx5e_ktls_tx_handle_resync_dump_comp()), only put_page() is used. This is an issue when using pages from large folios: the get_page() references are stored on the folio page while the page_ref_inc() references are stored directly in the given page. On release the folio page will be dereferenced too many times. This was found while doing kTLS testing with sendfile() + ZC when the served file was read from NFS on a kernel with NFS large folios support (commit 49b29a573da8 (\"nfs: add support for large folios\")).", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53121", "url": "https://ubuntu.com/security/CVE-2024-53121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: fs, lock FTE when checking if active The referenced commits introduced a two-step process for deleting FTEs: - Lock the FTE, delete it from hardware, set the hardware deletion function to NULL and unlock the FTE. - Lock the parent flow group, delete the software copy of the FTE, and remove it from the xarray. However, this approach encounters a race condition if a rule with the same match value is added simultaneously. In this scenario, fs_core may set the hardware deletion function to NULL prematurely, causing a panic during subsequent rule deletions. To prevent this, ensure the active flag of the FTE is checked under a lock, which will prevent the fs_core layer from attaching a new steering rule to an FTE that is in the process of deletion. [ 438.967589] MOSHE: 2496 mlx5_del_flow_rules del_hw_func [ 438.968205] ------------[ cut here ]------------ [ 438.968654] refcount_t: decrement hit 0; leaking memory. [ 438.969249] WARNING: CPU: 0 PID: 8957 at lib/refcount.c:31 refcount_warn_saturate+0xfb/0x110 [ 438.970054] Modules linked in: act_mirred cls_flower act_gact sch_ingress openvswitch nsh mlx5_vdpa vringh vhost_iotlb vdpa mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core zram zsmalloc fuse [last unloaded: cls_flower] [ 438.973288] CPU: 0 UID: 0 PID: 8957 Comm: tc Not tainted 6.12.0-rc1+ #8 [ 438.973888] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 438.974874] RIP: 0010:refcount_warn_saturate+0xfb/0x110 [ 438.975363] Code: 40 66 3b 82 c6 05 16 e9 4d 01 01 e8 1f 7c a0 ff 0f 0b c3 cc cc cc cc 48 c7 c7 10 66 3b 82 c6 05 fd e8 4d 01 01 e8 05 7c a0 ff <0f> 0b c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 90 [ 438.976947] RSP: 0018:ffff888124a53610 EFLAGS: 00010286 [ 438.977446] RAX: 0000000000000000 RBX: ffff888119d56de0 RCX: 0000000000000000 [ 438.978090] RDX: ffff88852c828700 RSI: ffff88852c81b3c0 RDI: ffff88852c81b3c0 [ 438.978721] RBP: ffff888120fa0e88 R08: 0000000000000000 R09: ffff888124a534b0 [ 438.979353] R10: 0000000000000001 R11: 0000000000000001 R12: ffff888119d56de0 [ 438.979979] R13: ffff888120fa0ec0 R14: ffff888120fa0ee8 R15: ffff888119d56de0 [ 438.980607] FS: 00007fe6dcc0f800(0000) GS:ffff88852c800000(0000) knlGS:0000000000000000 [ 438.983984] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 438.984544] CR2: 00000000004275e0 CR3: 0000000186982001 CR4: 0000000000372eb0 [ 438.985205] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 438.985842] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 438.986507] Call Trace: [ 438.986799] [ 438.987070] ? __warn+0x7d/0x110 [ 438.987426] ? refcount_warn_saturate+0xfb/0x110 [ 438.987877] ? report_bug+0x17d/0x190 [ 438.988261] ? prb_read_valid+0x17/0x20 [ 438.988659] ? handle_bug+0x53/0x90 [ 438.989054] ? exc_invalid_op+0x14/0x70 [ 438.989458] ? asm_exc_invalid_op+0x16/0x20 [ 438.989883] ? refcount_warn_saturate+0xfb/0x110 [ 438.990348] mlx5_del_flow_rules+0x2f7/0x340 [mlx5_core] [ 438.990932] __mlx5_eswitch_del_rule+0x49/0x170 [mlx5_core] [ 438.991519] ? mlx5_lag_is_sriov+0x3c/0x50 [mlx5_core] [ 438.992054] ? xas_load+0x9/0xb0 [ 438.992407] mlx5e_tc_rule_unoffload+0x45/0xe0 [mlx5_core] [ 438.993037] mlx5e_tc_del_fdb_flow+0x2a6/0x2e0 [mlx5_core] [ 438.993623] mlx5e_flow_put+0x29/0x60 [mlx5_core] [ 438.994161] mlx5e_delete_flower+0x261/0x390 [mlx5_core] [ 438.994728] tc_setup_cb_destroy+0xb9/0x190 [ 438.995150] fl_hw_destroy_filter+0x94/0xc0 [cls_flower] [ 438.995650] fl_change+0x11a4/0x13c0 [cls_flower] [ 438.996105] tc_new_tfilter+0x347/0xbc0 [ 438.996503] ? __ ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53122", "url": "https://ubuntu.com/security/CVE-2024-53122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: cope racing subflow creation in mptcp_rcv_space_adjust Additional active subflows - i.e. created by the in kernel path manager - are included into the subflow list before starting the 3whs. A racing recvmsg() spooling data received on an already established subflow would unconditionally call tcp_cleanup_rbuf() on all the current subflows, potentially hitting a divide by zero error on the newly created ones. Explicitly check that the subflow is in a suitable state before invoking tcp_cleanup_rbuf().", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53123", "url": "https://ubuntu.com/security/CVE-2024-53123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: error out earlier on disconnect Eric reported a division by zero splat in the MPTCP protocol: Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 6094 Comm: syz-executor317 Not tainted 6.12.0-rc5-syzkaller-00291-g05b92660cdfe #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:__tcp_select_window+0x5b4/0x1310 net/ipv4/tcp_output.c:3163 Code: f6 44 01 e3 89 df e8 9b 75 09 f8 44 39 f3 0f 8d 11 ff ff ff e8 0d 74 09 f8 45 89 f4 e9 04 ff ff ff e8 00 74 09 f8 44 89 f0 99 7c 24 14 41 29 d6 45 89 f4 e9 ec fe ff ff e8 e8 73 09 f8 48 89 RSP: 0018:ffffc900041f7930 EFLAGS: 00010293 RAX: 0000000000017e67 RBX: 0000000000017e67 RCX: ffffffff8983314b RDX: 0000000000000000 RSI: ffffffff898331b0 RDI: 0000000000000004 RBP: 00000000005d6000 R08: 0000000000000004 R09: 0000000000017e67 R10: 0000000000003e80 R11: 0000000000000000 R12: 0000000000003e80 R13: ffff888031d9b440 R14: 0000000000017e67 R15: 00000000002eb000 FS: 00007feb5d7f16c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007feb5d8adbb8 CR3: 0000000074e4c000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __tcp_cleanup_rbuf+0x3e7/0x4b0 net/ipv4/tcp.c:1493 mptcp_rcv_space_adjust net/mptcp/protocol.c:2085 [inline] mptcp_recvmsg+0x2156/0x2600 net/mptcp/protocol.c:2289 inet_recvmsg+0x469/0x6a0 net/ipv4/af_inet.c:885 sock_recvmsg_nosec net/socket.c:1051 [inline] sock_recvmsg+0x1b2/0x250 net/socket.c:1073 __sys_recvfrom+0x1a5/0x2e0 net/socket.c:2265 __do_sys_recvfrom net/socket.c:2283 [inline] __se_sys_recvfrom net/socket.c:2279 [inline] __x64_sys_recvfrom+0xe0/0x1c0 net/socket.c:2279 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 RIP: 0033:0x7feb5d857559 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:00007feb5d7f1208 EFLAGS: 00000246 ORIG_RAX: 000000000000002d RAX: ffffffffffffffda RBX: 00007feb5d8e1318 RCX: 00007feb5d857559 RDX: 000000800000000e RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007feb5d8e1310 R08: 0000000000000000 R09: ffffffff81000000 R10: 0000000000000100 R11: 0000000000000246 R12: 00007feb5d8e131c R13: 00007feb5d8ae074 R14: 000000800000000e R15: 00000000fffffdef and provided a nice reproducer. The root cause is the current bad handling of racing disconnect. After the blamed commit below, sk_wait_data() can return (with error) with the underlying socket disconnected and a zero rcv_mss. Catch the error and return without performing any additional operations on the current socket.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53124", "url": "https://ubuntu.com/security/CVE-2024-53124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix data-races around sk->sk_forward_alloc Syzkaller reported this warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 16 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x1c5/0x1e0 Modules linked in: CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:inet_sock_destruct+0x1c5/0x1e0 Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 <0f> 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00 RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206 RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007 RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00 RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007 R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00 R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78 FS: 0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn+0x88/0x130 ? inet_sock_destruct+0x1c5/0x1e0 ? report_bug+0x18e/0x1a0 ? handle_bug+0x53/0x90 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? inet_sock_destruct+0x1c5/0x1e0 __sk_destruct+0x2a/0x200 rcu_do_batch+0x1aa/0x530 ? rcu_do_batch+0x13b/0x530 rcu_core+0x159/0x2f0 handle_softirqs+0xd3/0x2b0 ? __pfx_smpboot_thread_fn+0x10/0x10 run_ksoftirqd+0x25/0x30 smpboot_thread_fn+0xdd/0x1d0 kthread+0xd3/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ---[ end trace 0000000000000000 ]--- Its possible that two threads call tcp_v6_do_rcv()/sk_forward_alloc_add() concurrently when sk->sk_state == TCP_LISTEN with sk->sk_lock unlocked, which triggers a data-race around sk->sk_forward_alloc: tcp_v6_rcv tcp_v6_do_rcv skb_clone_and_charge_r sk_rmem_schedule __sk_mem_schedule sk_forward_alloc_add() skb_set_owner_r sk_mem_charge sk_forward_alloc_add() __kfree_skb skb_release_all skb_release_head_state sock_rfree sk_mem_uncharge sk_forward_alloc_add() sk_mem_reclaim // set local var reclaimable __sk_mem_reclaim sk_forward_alloc_add() In this syzkaller testcase, two threads call tcp_v6_do_rcv() with skb->truesize=768, the sk_forward_alloc changes like this: (cpu 1) | (cpu 2) | sk_forward_alloc ... | ... | 0 __sk_mem_schedule() | | +4096 = 4096 | __sk_mem_schedule() | +4096 = 8192 sk_mem_charge() | | -768 = 7424 | sk_mem_charge() | -768 = 6656 ... | ... | sk_mem_uncharge() | | +768 = 7424 reclaimable=7424 | | | sk_mem_uncharge() | +768 = 8192 | reclaimable=8192 | __sk_mem_reclaim() | | -4096 = 4096 | __sk_mem_reclaim() | -8192 = -4096 != 0 The skb_clone_and_charge_r() should not be called in tcp_v6_do_rcv() when sk->sk_state is TCP_LISTEN, it happens later in tcp_v6_syn_recv_sock(). Fix the same issue in dccp_v6_do_rcv().", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53129", "url": "https://ubuntu.com/security/CVE-2024-53129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: vop: Fix a dereferenced before check warning The 'state' can't be NULL, we should check crtc_state. Fix warning: drivers/gpu/drm/rockchip/rockchip_drm_vop.c:1096 vop_plane_atomic_async_check() warn: variable dereferenced before check 'state' (see line 1077)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53139", "url": "https://ubuntu.com/security/CVE-2024-53139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix possible UAF in sctp_v6_available() A lockdep report [1] with CONFIG_PROVE_RCU_LIST=y hints that sctp_v6_available() is calling dev_get_by_index_rcu() and ipv6_chk_addr() without holding rcu. [1] ============================= WARNING: suspicious RCU usage 6.12.0-rc5-virtme #1216 Tainted: G W ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by sctp_hello/31495: #0: ffff9f1ebbdb7418 (sk_lock-AF_INET6){+.+.}-{0:0}, at: sctp_bind (./arch/x86/include/asm/jump_label.h:27 net/sctp/socket.c:315) sctp stack backtrace: CPU: 7 UID: 0 PID: 31495 Comm: sctp_hello Tainted: G W 6.12.0-rc5-virtme #1216 Tainted: [W]=WARN 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:123) lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822) dev_get_by_index_rcu (net/core/dev.c:876 (discriminator 7)) sctp_v6_available (net/sctp/ipv6.c:701) sctp sctp_do_bind (net/sctp/socket.c:400 (discriminator 1)) sctp sctp_bind (net/sctp/socket.c:320) sctp inet6_bind_sk (net/ipv6/af_inet6.c:465) ? security_socket_bind (security/security.c:4581 (discriminator 1)) __sys_bind (net/socket.c:1848 net/socket.c:1869) ? do_user_addr_fault (./include/linux/rcupdate.h:347 ./include/linux/rcupdate.h:880 ./include/linux/mm.h:729 arch/x86/mm/fault.c:1340) ? do_user_addr_fault (./arch/x86/include/asm/preempt.h:84 (discriminator 13) ./include/linux/rcupdate.h:98 (discriminator 13) ./include/linux/rcupdate.h:882 (discriminator 13) ./include/linux/mm.h:729 (discriminator 13) arch/x86/mm/fault.c:1340 (discriminator 13)) __x64_sys_bind (net/socket.c:1877 (discriminator 1) net/socket.c:1875 (discriminator 1) net/socket.c:1875 (discriminator 1)) do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f59b934a1e7 Code: 44 00 00 48 8b 15 39 8c 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 b8 31 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 09 8c 0c 00 f7 d8 64 89 01 48 All code ======== 0:\t44 00 00 \tadd %r8b,(%rax) 3:\t48 8b 15 39 8c 0c 00 \tmov 0xc8c39(%rip),%rdx # 0xc8c43 a:\tf7 d8 \tneg %eax c:\t64 89 02 \tmov %eax,%fs:(%rdx) f:\tb8 ff ff ff ff \tmov $0xffffffff,%eax 14:\teb bd \tjmp 0xffffffffffffffd3 16:\t66 2e 0f 1f 84 00 00 \tcs nopw 0x0(%rax,%rax,1) 1d:\t00 00 00 20:\t0f 1f 00 \tnopl (%rax) 23:\tb8 31 00 00 00 \tmov $0x31,%eax 28:\t0f 05 \tsyscall 2a:*\t48 3d 01 f0 ff ff \tcmp $0xfffffffffffff001,%rax\t\t<-- trapping instruction 30:\t73 01 \tjae 0x33 32:\tc3 \tret 33:\t48 8b 0d 09 8c 0c 00 \tmov 0xc8c09(%rip),%rcx # 0xc8c43 3a:\tf7 d8 \tneg %eax 3c:\t64 89 01 \tmov %eax,%fs:(%rcx) 3f:\t48 \trex.W Code starting with the faulting instruction =========================================== 0:\t48 3d 01 f0 ff ff \tcmp $0xfffffffffffff001,%rax 6:\t73 01 \tjae 0x9 8:\tc3 \tret 9:\t48 8b 0d 09 8c 0c 00 \tmov 0xc8c09(%rip),%rcx # 0xc8c19 10:\tf7 d8 \tneg %eax 12:\t64 89 01 \tmov %eax,%fs:(%rcx) 15:\t48 \trex.W RSP: 002b:00007ffe2d0ad398 EFLAGS: 00000202 ORIG_RAX: 0000000000000031 RAX: ffffffffffffffda RBX: 00007ffe2d0ad3d0 RCX: 00007f59b934a1e7 RDX: 000000000000001c RSI: 00007ffe2d0ad3d0 RDI: 0000000000000005 RBP: 0000000000000005 R08: 1999999999999999 R09: 0000000000000000 R10: 00007f59b9253298 R11: 000000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53140", "url": "https://ubuntu.com/security/CVE-2024-53140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netlink: terminate outstanding dump on socket close Netlink supports iterative dumping of data. It provides the families the following ops: - start - (optional) kicks off the dumping process - dump - actual dump helper, keeps getting called until it returns 0 - done - (optional) pairs with .start, can be used for cleanup The whole process is asynchronous and the repeated calls to .dump don't actually happen in a tight loop, but rather are triggered in response to recvmsg() on the socket. This gives the user full control over the dump, but also means that the user can close the socket without getting to the end of the dump. To make sure .start is always paired with .done we check if there is an ongoing dump before freeing the socket, and if so call .done. The complication is that sockets can get freed from BH and .done is allowed to sleep. So we use a workqueue to defer the call, when needed. Unfortunately this does not work correctly. What we defer is not the cleanup but rather releasing a reference on the socket. We have no guarantee that we own the last reference, if someone else holds the socket they may release it in BH and we're back to square one. The whole dance, however, appears to be unnecessary. Only the user can interact with dumps, so we can clean up when socket is closed. And close always happens in process context. Some async code may still access the socket after close, queue notification skbs to it etc. but no dumps can start, end or otherwise make progress. Delete the workqueue and flush the dump state directly from the release handler. Note that further cleanup is possible in -next, for instance we now always call .done before releasing the main module reference, so dump doesn't have to take a reference of its own.", "cve_priority": "high", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53098", "url": "https://ubuntu.com/security/CVE-2024-53098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/ufence: Prefetch ufence addr to catch bogus address access_ok() only checks for addr overflow so also try to read the addr to catch invalid addr sent from userspace. (cherry picked from commit 9408c4508483ffc60811e910a93d6425b8e63928)", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53099", "url": "https://ubuntu.com/security/CVE-2024-53099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check validity of link->type in bpf_link_show_fdinfo() If a newly-added link type doesn't invoke BPF_LINK_TYPE(), accessing bpf_link_type_strs[link->type] may result in an out-of-bounds access. To spot such missed invocations early in the future, checking the validity of link->type in bpf_link_show_fdinfo() and emitting a warning when such invocations are missed.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53089", "url": "https://ubuntu.com/security/CVE-2024-53089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: KVM: Mark hrtimer to expire in hard interrupt context Like commit 2c0d278f3293f (\"KVM: LAPIC: Mark hrtimer to expire in hard interrupt context\") and commit 9090825fa9974 (\"KVM: arm/arm64: Let the timer expire in hardirq context on RT\"), On PREEMPT_RT enabled kernels unmarked hrtimers are moved into soft interrupt expiry mode by default. Then the timers are canceled from an preempt-notifier which is invoked with disabled preemption which is not allowed on PREEMPT_RT. The timer callback is short so in could be invoked in hard-IRQ context. So let the timer expire on hard-IRQ context even on -RT. This fix a \"scheduling while atomic\" bug for PREEMPT_RT enabled kernels: BUG: scheduling while atomic: qemu-system-loo/1011/0x00000002 Modules linked in: amdgpu rfkill nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat ns CPU: 1 UID: 0 PID: 1011 Comm: qemu-system-loo Tainted: G W 6.12.0-rc2+ #1774 Tainted: [W]=WARN Hardware name: Loongson Loongson-3A5000-7A1000-1w-CRB/Loongson-LS3A5000-7A1000-1w-CRB, BIOS vUDK2018-LoongArch-V2.0.0-prebeta9 10/21/2022 Stack : ffffffffffffffff 0000000000000000 9000000004e3ea38 9000000116744000 90000001167475a0 0000000000000000 90000001167475a8 9000000005644830 90000000058dc000 90000000058dbff8 9000000116747420 0000000000000001 0000000000000001 6a613fc938313980 000000000790c000 90000001001c1140 00000000000003fe 0000000000000001 000000000000000d 0000000000000003 0000000000000030 00000000000003f3 000000000790c000 9000000116747830 90000000057ef000 0000000000000000 9000000005644830 0000000000000004 0000000000000000 90000000057f4b58 0000000000000001 9000000116747868 900000000451b600 9000000005644830 9000000003a13998 0000000010000020 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d ... Call Trace: [<9000000003a13998>] show_stack+0x38/0x180 [<9000000004e3ea34>] dump_stack_lvl+0x84/0xc0 [<9000000003a71708>] __schedule_bug+0x48/0x60 [<9000000004e45734>] __schedule+0x1114/0x1660 [<9000000004e46040>] schedule_rtlock+0x20/0x60 [<9000000004e4e330>] rtlock_slowlock_locked+0x3f0/0x10a0 [<9000000004e4f038>] rt_spin_lock+0x58/0x80 [<9000000003b02d68>] hrtimer_cancel_wait_running+0x68/0xc0 [<9000000003b02e30>] hrtimer_cancel+0x70/0x80 [] kvm_restore_timer+0x50/0x1a0 [kvm] [] kvm_arch_vcpu_load+0x68/0x2a0 [kvm] [] kvm_sched_in+0x34/0x60 [kvm] [<9000000003a749a0>] finish_task_switch.isra.0+0x140/0x2e0 [<9000000004e44a70>] __schedule+0x450/0x1660 [<9000000004e45cb0>] schedule+0x30/0x180 [] kvm_vcpu_block+0x70/0x120 [kvm] [] kvm_vcpu_halt+0x60/0x3e0 [kvm] [] kvm_handle_gspr+0x3f4/0x4e0 [kvm] [] kvm_handle_exit+0x1c8/0x260 [kvm]", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53090", "url": "https://ubuntu.com/security/CVE-2024-53090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix lock recursion afs_wake_up_async_call() can incur lock recursion. The problem is that it is called from AF_RXRPC whilst holding the ->notify_lock, but it tries to take a ref on the afs_call struct in order to pass it to a work queue - but if the afs_call is already queued, we then have an extraneous ref that must be put... calling afs_put_call() may call back down into AF_RXRPC through rxrpc_kernel_shutdown_call(), however, which might try taking the ->notify_lock again. This case isn't very common, however, so defer it to a workqueue. The oops looks something like: BUG: spinlock recursion on CPU#0, krxrpcio/7001/1646 lock: 0xffff888141399b30, .magic: dead4ead, .owner: krxrpcio/7001/1646, .owner_cpu: 0 CPU: 0 UID: 0 PID: 1646 Comm: krxrpcio/7001 Not tainted 6.12.0-rc2-build3+ #4351 Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014 Call Trace: dump_stack_lvl+0x47/0x70 do_raw_spin_lock+0x3c/0x90 rxrpc_kernel_shutdown_call+0x83/0xb0 afs_put_call+0xd7/0x180 rxrpc_notify_socket+0xa0/0x190 rxrpc_input_split_jumbo+0x198/0x1d0 rxrpc_input_data+0x14b/0x1e0 ? rxrpc_input_call_packet+0xc2/0x1f0 rxrpc_input_call_event+0xad/0x6b0 rxrpc_input_packet_on_conn+0x1e1/0x210 rxrpc_input_packet+0x3f2/0x4d0 rxrpc_io_thread+0x243/0x410 ? __pfx_rxrpc_io_thread+0x10/0x10 kthread+0xcf/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x24/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53101", "url": "https://ubuntu.com/security/CVE-2024-53101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized value issue in from_kuid and from_kgid ocfs2_setattr() uses attr->ia_mode, attr->ia_uid and attr->ia_gid in a trace point even though ATTR_MODE, ATTR_UID and ATTR_GID aren't set. Initialize all fields of newattrs to avoid uninitialized variables, by checking if ATTR_MODE, ATTR_UID, ATTR_GID are initialized, otherwise 0.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53091", "url": "https://ubuntu.com/security/CVE-2024-53091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Add sk_is_inet and IS_ICSK check in tls_sw_has_ctx_tx/rx As the introduction of the support for vsock and unix sockets in sockmap, tls_sw_has_ctx_tx/rx cannot presume the socket passed in must be IS_ICSK. vsock and af_unix sockets have vsock_sock and unix_sock instead of inet_connection_sock. For these sockets, tls_get_ctx may return an invalid pointer and cause page fault in function tls_sw_ctx_rx. BUG: unable to handle page fault for address: 0000000000040030 Workqueue: vsock-loopback vsock_loopback_work RIP: 0010:sk_psock_strp_data_ready+0x23/0x60 Call Trace: ? __die+0x81/0xc3 ? no_context+0x194/0x350 ? do_page_fault+0x30/0x110 ? async_page_fault+0x3e/0x50 ? sk_psock_strp_data_ready+0x23/0x60 virtio_transport_recv_pkt+0x750/0x800 ? update_load_avg+0x7e/0x620 vsock_loopback_work+0xd0/0x100 process_one_work+0x1a7/0x360 worker_thread+0x30/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x112/0x130 ? __kthread_cancel_work+0x40/0x40 ret_from_fork+0x1f/0x40 v2: - Add IS_ICSK check v3: - Update the commits in Fixes", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53092", "url": "https://ubuntu.com/security/CVE-2024-53092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_pci: Fix admin vq cleanup by using correct info pointer vp_modern_avq_cleanup() and vp_del_vqs() clean up admin vq resources by virtio_pci_vq_info pointer. The info pointer of admin vq is stored in vp_dev->admin_vq.info instead of vp_dev->vqs[]. Using the info pointer from vp_dev->vqs[] for admin vq causes a kernel NULL pointer dereference bug. In vp_modern_avq_cleanup() and vp_del_vqs(), get the info pointer from vp_dev->admin_vq.info for admin vq to clean up the resources. Also make info ptr as argument of vp_del_vq() to be symmetric with vp_setup_vq(). vp_reset calls vp_modern_avq_cleanup, and causes the Call Trace: ================================================================== BUG: kernel NULL pointer dereference, address:0000000000000000 ... CPU: 49 UID: 0 PID: 4439 Comm: modprobe Not tainted 6.11.0-rc5 #1 RIP: 0010:vp_reset+0x57/0x90 [virtio_pci] Call Trace: ... ? vp_reset+0x57/0x90 [virtio_pci] ? vp_reset+0x38/0x90 [virtio_pci] virtio_reset_device+0x1d/0x30 remove_vq_common+0x1c/0x1a0 [virtio_net] virtnet_remove+0xa1/0xc0 [virtio_net] virtio_dev_remove+0x46/0xa0 ... virtio_pci_driver_exit+0x14/0x810 [virtio_pci] ==================================================================", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53102", "url": "https://ubuntu.com/security/CVE-2024-53102", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53093", "url": "https://ubuntu.com/security/CVE-2024-53093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: defer partition scanning We need to suppress the partition scan from occuring within the controller's scan_work context. If a path error occurs here, the IO will wait until a path becomes available or all paths are torn down, but that action also occurs within scan_work, so it would deadlock. Defer the partion scan to a different context that does not block scan_work.", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53094", "url": "https://ubuntu.com/security/CVE-2024-53094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Add sendpage_ok() check to disable MSG_SPLICE_PAGES While running ISER over SIW, the initiator machine encounters a warning from skb_splice_from_iter() indicating that a slab page is being used in send_page. To address this, it is better to add a sendpage_ok() check within the driver itself, and if it returns 0, then MSG_SPLICE_PAGES flag should be disabled before entering the network stack. A similar issue has been discussed for NVMe in this thread: https://lore.kernel.org/all/20240530142417.146696-1-ofir.gal@volumez.com/ WARNING: CPU: 0 PID: 5342 at net/core/skbuff.c:7140 skb_splice_from_iter+0x173/0x320 Call Trace: tcp_sendmsg_locked+0x368/0xe40 siw_tx_hdt+0x695/0xa40 [siw] siw_qp_sq_process+0x102/0xb00 [siw] siw_sq_resume+0x39/0x110 [siw] siw_run_sq+0x74/0x160 [siw] kthread+0xd2/0x100 ret_from_fork+0x34/0x40 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53100", "url": "https://ubuntu.com/security/CVE-2024-53100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: tcp: avoid race between queue_lock lock and destroy Commit 76d54bf20cdc (\"nvme-tcp: don't access released socket during error recovery\") added a mutex_lock() call for the queue->queue_lock in nvme_tcp_get_address(). However, the mutex_lock() races with mutex_destroy() in nvme_tcp_free_queue(), and causes the WARN below. DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: CPU: 3 PID: 34077 at kernel/locking/mutex.c:587 __mutex_lock+0xcf0/0x1220 Modules linked in: nvmet_tcp nvmet nvme_tcp nvme_fabrics iw_cm ib_cm ib_core pktcdvd nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables qrtr sunrpc ppdev 9pnet_virtio 9pnet pcspkr netfs parport_pc parport e1000 i2c_piix4 i2c_smbus loop fuse nfnetlink zram bochs drm_vram_helper drm_ttm_helper ttm drm_kms_helper xfs drm sym53c8xx floppy nvme scsi_transport_spi nvme_core nvme_auth serio_raw ata_generic pata_acpi dm_multipath qemu_fw_cfg [last unloaded: ib_uverbs] CPU: 3 UID: 0 PID: 34077 Comm: udisksd Not tainted 6.11.0-rc7 #319 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:__mutex_lock+0xcf0/0x1220 Code: 08 84 d2 0f 85 c8 04 00 00 8b 15 ef b6 c8 01 85 d2 0f 85 78 f4 ff ff 48 c7 c6 20 93 ee af 48 c7 c7 60 91 ee af e8 f0 a7 6d fd <0f> 0b e9 5e f4 ff ff 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 RSP: 0018:ffff88811305f760 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff88812c652058 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000001 RBP: ffff88811305f8b0 R08: 0000000000000001 R09: ffffed1075c36341 R10: ffff8883ae1b1a0b R11: 0000000000010498 R12: 0000000000000000 R13: 0000000000000000 R14: dffffc0000000000 R15: ffff88812c652058 FS: 00007f9713ae4980(0000) GS:ffff8883ae180000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcd78483c7c CR3: 0000000122c38000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn.cold+0x5b/0x1af ? __mutex_lock+0xcf0/0x1220 ? report_bug+0x1ec/0x390 ? handle_bug+0x3c/0x80 ? exc_invalid_op+0x13/0x40 ? asm_exc_invalid_op+0x16/0x20 ? __mutex_lock+0xcf0/0x1220 ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] ? __pfx___mutex_lock+0x10/0x10 ? __lock_acquire+0xd6a/0x59e0 ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] ? __pfx_nvme_tcp_get_address+0x10/0x10 [nvme_tcp] nvme_sysfs_show_address+0x81/0xc0 [nvme_core] dev_attr_show+0x42/0x80 ? __asan_memset+0x1f/0x40 sysfs_kf_seq_show+0x1f0/0x370 seq_read_iter+0x2cb/0x1130 ? rw_verify_area+0x3b1/0x590 ? __mutex_lock+0x433/0x1220 vfs_read+0x6a6/0xa20 ? lockdep_hardirqs_on+0x78/0x100 ? __pfx_vfs_read+0x10/0x10 ksys_read+0xf7/0x1d0 ? __pfx_ksys_read+0x10/0x10 ? __x64_sys_openat+0x105/0x1d0 do_syscall_64+0x93/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? __pfx_ksys_read+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? do_syscall_64+0x9f/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f9713f55cfa Code: 55 48 89 e5 48 83 ec 20 48 89 55 e8 48 89 75 f0 89 7d f8 e8 e8 74 f8 ff 48 8b 55 e8 48 8b 75 f0 4 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53095", "url": "https://ubuntu.com/security/CVE-2024-53095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix use-after-free of network namespace. Recently, we got a customer report that CIFS triggers oops while reconnecting to a server. [0] The workload runs on Kubernetes, and some pods mount CIFS servers in non-root network namespaces. The problem rarely happened, but it was always while the pod was dying. The root cause is wrong reference counting for network namespace. CIFS uses kernel sockets, which do not hold refcnt of the netns that the socket belongs to. That means CIFS must ensure the socket is always freed before its netns; otherwise, use-after-free happens. The repro steps are roughly: 1. mount CIFS in a non-root netns 2. drop packets from the netns 3. destroy the netns 4. unmount CIFS We can reproduce the issue quickly with the script [1] below and see the splat [2] if CONFIG_NET_NS_REFCNT_TRACKER is enabled. When the socket is TCP, it is hard to guarantee the netns lifetime without holding refcnt due to async timers. Let's hold netns refcnt for each socket as done for SMC in commit 9744d2bf1976 (\"smc: Fix use-after-free in tcp_write_timer_handler().\"). Note that we need to move put_net() from cifs_put_tcp_session() to clean_demultiplex_info(); otherwise, __sock_create() still could touch a freed netns while cifsd tries to reconnect from cifs_demultiplex_thread(). Also, maybe_get_net() cannot be put just before __sock_create() because the code is not under RCU and there is a small chance that the same address happened to be reallocated to another netns. [0]: CIFS: VFS: \\\\XXXXXXXXXXX has not responded in 15 seconds. Reconnecting... CIFS: Serverclose failed 4 times, giving up Unable to handle kernel paging request at virtual address 14de99e461f84a07 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 CM = 0, WnR = 0 [14de99e461f84a07] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: cls_bpf sch_ingress nls_utf8 cifs cifs_arc4 cifs_md4 dns_resolver tcp_diag inet_diag veth xt_state xt_connmark nf_conntrack_netlink xt_nat xt_statistic xt_MASQUERADE xt_mark xt_addrtype ipt_REJECT nf_reject_ipv4 nft_chain_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment nft_compat nf_tables nfnetlink overlay nls_ascii nls_cp437 sunrpc vfat fat aes_ce_blk aes_ce_cipher ghash_ce sm4_ce_cipher sm4 sm3_ce sm3 sha3_ce sha512_ce sha512_arm64 sha1_ce ena button sch_fq_codel loop fuse configfs dmi_sysfs sha2_ce sha256_arm64 dm_mirror dm_region_hash dm_log dm_mod dax efivarfs CPU: 5 PID: 2690970 Comm: cifsd Not tainted 6.1.103-109.184.amzn2023.aarch64 #1 Hardware name: Amazon EC2 r7g.4xlarge/, BIOS 1.0 11/1/2018 pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : fib_rules_lookup+0x44/0x238 lr : __fib_lookup+0x64/0xbc sp : ffff8000265db790 x29: ffff8000265db790 x28: 0000000000000000 x27: 000000000000bd01 x26: 0000000000000000 x25: ffff000b4baf8000 x24: ffff00047b5e4580 x23: ffff8000265db7e0 x22: 0000000000000000 x21: ffff00047b5e4500 x20: ffff0010e3f694f8 x19: 14de99e461f849f7 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 3f92800abd010002 x11: 0000000000000001 x10: ffff0010e3f69420 x9 : ffff800008a6f294 x8 : 0000000000000000 x7 : 0000000000000006 x6 : 0000000000000000 x5 : 0000000000000001 x4 : ffff001924354280 x3 : ffff8000265db7e0 x2 : 0000000000000000 x1 : ffff0010e3f694f8 x0 : ffff00047b5e4500 Call trace: fib_rules_lookup+0x44/0x238 __fib_lookup+0x64/0xbc ip_route_output_key_hash_rcu+0x2c4/0x398 ip_route_output_key_hash+0x60/0x8c tcp_v4_connect+0x290/0x488 __inet_stream_connect+0x108/0x3d0 inet_stream_connect+0x50/0x78 kernel_connect+0x6c/0xac generic_ip_conne ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-50265", "url": "https://ubuntu.com/security/CVE-2024-50265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove() Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove(): [ 57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12 [ 57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry [ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004 [...] [ 57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [...] [ 57.331328] Call Trace: [ 57.331477] [...] [ 57.333511] ? do_user_addr_fault+0x3e5/0x740 [ 57.333778] ? exc_page_fault+0x70/0x170 [ 57.334016] ? asm_exc_page_fault+0x2b/0x30 [ 57.334263] ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10 [ 57.334596] ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [ 57.334913] ocfs2_xa_remove_entry+0x23/0xc0 [ 57.335164] ocfs2_xa_set+0x704/0xcf0 [ 57.335381] ? _raw_spin_unlock+0x1a/0x40 [ 57.335620] ? ocfs2_inode_cache_unlock+0x16/0x20 [ 57.335915] ? trace_preempt_on+0x1e/0x70 [ 57.336153] ? start_this_handle+0x16c/0x500 [ 57.336410] ? preempt_count_sub+0x50/0x80 [ 57.336656] ? _raw_read_unlock+0x20/0x40 [ 57.336906] ? start_this_handle+0x16c/0x500 [ 57.337162] ocfs2_xattr_block_set+0xa6/0x1e0 [ 57.337424] __ocfs2_xattr_set_handle+0x1fd/0x5d0 [ 57.337706] ? ocfs2_start_trans+0x13d/0x290 [ 57.337971] ocfs2_xattr_set+0xb13/0xfb0 [ 57.338207] ? dput+0x46/0x1c0 [ 57.338393] ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338665] ? ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338948] __vfs_removexattr+0x92/0xc0 [ 57.339182] __vfs_removexattr_locked+0xd5/0x190 [ 57.339456] ? preempt_count_sub+0x50/0x80 [ 57.339705] vfs_removexattr+0x5f/0x100 [...] Reproducer uses faultinject facility to fail ocfs2_xa_remove() -> ocfs2_xa_value_truncate() with -ENOMEM. In this case the comment mentions that we can return 0 if ocfs2_xa_cleanup_value_truncate() is going to wipe the entry anyway. But the following 'rc' check is wrong and execution flow do 'ocfs2_xa_remove_entry(loc);' twice: * 1st: in ocfs2_xa_cleanup_value_truncate(); * 2nd: returning back to ocfs2_xa_remove() instead of going to 'out'. Fix this by skipping the 2nd removal of the same entry and making syzkaller repro happy.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50266", "url": "https://ubuntu.com/security/CVE-2024-50266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: qcom: videocc-sm8350: use HW_CTRL_TRIGGER for vcodec GDSCs A recent change in the venus driver results in a stuck clock on the Lenovo ThinkPad X13s, for example, when streaming video in firefox: \tvideo_cc_mvs0_clk status stuck at 'off' \tWARNING: CPU: 6 PID: 2885 at drivers/clk/qcom/clk-branch.c:87 clk_branch_wait+0x144/0x15c \t... \tCall trace: \t clk_branch_wait+0x144/0x15c \t clk_branch2_enable+0x30/0x40 \t clk_core_enable+0xd8/0x29c \t clk_enable+0x2c/0x4c \t vcodec_clks_enable.isra.0+0x94/0xd8 [venus_core] \t coreid_power_v4+0x464/0x628 [venus_core] \t vdec_start_streaming+0xc4/0x510 [venus_dec] \t vb2_start_streaming+0x6c/0x180 [videobuf2_common] \t vb2_core_streamon+0x120/0x1dc [videobuf2_common] \t vb2_streamon+0x1c/0x6c [videobuf2_v4l2] \t v4l2_m2m_ioctl_streamon+0x30/0x80 [v4l2_mem2mem] \t v4l_streamon+0x24/0x30 [videodev] using the out-of-tree sm8350/sc8280xp venus support. [1] Update also the sm8350/sc8280xp GDSC definitions so that the hw control mode can be changed at runtime as the venus driver now requires.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50267", "url": "https://ubuntu.com/security/CVE-2024-50267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: fix use after free in debug printk The \"dev_dbg(&urb->dev->dev, ...\" which happens after usb_free_urb(urb) is a use after free of the \"urb\" pointer. Store the \"dev\" pointer at the start of the function to avoid this issue.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50268", "url": "https://ubuntu.com/security/CVE-2024-50268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: fix potential out of bounds in ucsi_ccg_update_set_new_cam_cmd() The \"*cmd\" variable can be controlled by the user via debugfs. That means \"new_cam\" can be as high as 255 while the size of the uc->updated[] array is UCSI_MAX_ALTMODES (30). The call tree is: ucsi_cmd() // val comes from simple_attr_write_xsigned() -> ucsi_send_command() -> ucsi_send_command_common() -> ucsi_run_command() // calls ucsi->ops->sync_control() -> ucsi_ccg_sync_control()", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53083", "url": "https://ubuntu.com/security/CVE-2024-53083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: qcom-pmic: init value of hdr_len/txbuf_len earlier If the read of USB_PDPHY_RX_ACKNOWLEDGE_REG failed, then hdr_len and txbuf_len are uninitialized. This commit stops to print uninitialized value and misleading/false data.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50269", "url": "https://ubuntu.com/security/CVE-2024-50269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: musb: sunxi: Fix accessing an released usb phy Commit 6ed05c68cbca (\"usb: musb: sunxi: Explicitly release USB PHY on exit\") will cause that usb phy @glue->xceiv is accessed after released. 1) register platform driver @sunxi_musb_driver // get the usb phy @glue->xceiv sunxi_musb_probe() -> devm_usb_get_phy(). 2) register and unregister platform driver @musb_driver musb_probe() -> sunxi_musb_init() use the phy here //the phy is released here musb_remove() -> sunxi_musb_exit() -> devm_usb_put_phy() 3) register @musb_driver again musb_probe() -> sunxi_musb_init() use the phy here but the phy has been released at 2). ... Fixed by reverting the commit, namely, removing devm_usb_put_phy() from sunxi_musb_exit().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53079", "url": "https://ubuntu.com/security/CVE-2024-53079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/thp: fix deferred split unqueue naming and locking Recent changes are putting more pressure on THP deferred split queues: under load revealing long-standing races, causing list_del corruptions, \"Bad page state\"s and worse (I keep BUGs in both of those, so usually don't get to see how badly they end up without). The relevant recent changes being 6.8's mTHP, 6.10's mTHP swapout, and 6.12's mTHP swapin, improved swap allocation, and underused THP splitting. Before fixing locking: rename misleading folio_undo_large_rmappable(), which does not undo large_rmappable, to folio_unqueue_deferred_split(), which is what it does. But that and its out-of-line __callee are mm internals of very limited usability: add comment and WARN_ON_ONCEs to check usage; and return a bool to say if a deferred split was unqueued, which can then be used in WARN_ON_ONCEs around safety checks (sparing callers the arcane conditionals in __folio_unqueue_deferred_split()). Just omit the folio_unqueue_deferred_split() from free_unref_folios(), all of whose callers now call it beforehand (and if any forget then bad_page() will tell) - except for its caller put_pages_list(), which itself no longer has any callers (and will be deleted separately). Swapout: mem_cgroup_swapout() has been resetting folio->memcg_data 0 without checking and unqueueing a THP folio from deferred split list; which is unfortunate, since the split_queue_lock depends on the memcg (when memcg is enabled); so swapout has been unqueueing such THPs later, when freeing the folio, using the pgdat's lock instead: potentially corrupting the memcg's list. __remove_mapping() has frozen refcount to 0 here, so no problem with calling folio_unqueue_deferred_split() before resetting memcg_data. That goes back to 5.4 commit 87eaceb3faa5 (\"mm: thp: make deferred split shrinker memcg aware\"): which included a check on swapcache before adding to deferred queue, but no check on deferred queue before adding THP to swapcache. That worked fine with the usual sequence of events in reclaim (though there were a couple of rare ways in which a THP on deferred queue could have been swapped out), but 6.12 commit dafff3f4c850 (\"mm: split underused THPs\") avoids splitting underused THPs in reclaim, which makes swapcache THPs on deferred queue commonplace. Keep the check on swapcache before adding to deferred queue? Yes: it is no longer essential, but preserves the existing behaviour, and is likely to be a worthwhile optimization (vmstat showed much more traffic on the queue under swapping load if the check was removed); update its comment. Memcg-v1 move (deprecated): mem_cgroup_move_account() has been changing folio->memcg_data without checking and unqueueing a THP folio from the deferred list, sometimes corrupting \"from\" memcg's list, like swapout. Refcount is non-zero here, so folio_unqueue_deferred_split() can only be used in a WARN_ON_ONCE to validate the fix, which must be done earlier: mem_cgroup_move_charge_pte_range() first try to split the THP (splitting of course unqueues), or skip it if that fails. Not ideal, but moving charge has been requested, and khugepaged should repair the THP later: nobody wants new custom unqueueing code just for this deprecated case. The 87eaceb3faa5 commit did have the code to move from one deferred list to another (but was not conscious of its unsafety while refcount non-0); but that was removed by 5.6 commit fac0516b5534 (\"mm: thp: don't need care deferred split queue in memcg charge move path\"), which argued that the existence of a PMD mapping guarantees that the THP cannot be on a deferred list. As above, false in rare cases, and now commonly false. Backport to 6.11 should be straightforward. Earlier backports must take care that other _deferred_list fixes and dependencies are included. There is not a strong case for backports, but they can fix cornercases.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50270", "url": "https://ubuntu.com/security/CVE-2024-50270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: avoid overflow in damon_feed_loop_next_input() damon_feed_loop_next_input() is inefficient and fragile to overflows. Specifically, 'score_goal_diff_bp' calculation can overflow when 'score' is high. The calculation is actually unnecessary at all because 'goal' is a constant of value 10,000. Calculation of 'compensation' is again fragile to overflow. Final calculation of return value for under-achiving case is again fragile to overflow when the current score is under-achieving the target. Add two corner cases handling at the beginning of the function to make the body easier to read, and rewrite the body of the function to avoid overflows and the unnecessary bp value calcuation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50271", "url": "https://ubuntu.com/security/CVE-2024-50271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: signal: restore the override_rlimit logic Prior to commit d64696905554 (\"Reimplement RLIMIT_SIGPENDING on top of ucounts\") UCOUNT_RLIMIT_SIGPENDING rlimit was not enforced for a class of signals. However now it's enforced unconditionally, even if override_rlimit is set. This behavior change caused production issues. For example, if the limit is reached and a process receives a SIGSEGV signal, sigqueue_alloc fails to allocate the necessary resources for the signal delivery, preventing the signal from being delivered with siginfo. This prevents the process from correctly identifying the fault address and handling the error. From the user-space perspective, applications are unaware that the limit has been reached and that the siginfo is effectively 'corrupted'. This can lead to unpredictable behavior and crashes, as we observed with java applications. Fix this by passing override_rlimit into inc_rlimit_get_ucounts() and skip the comparison to max there if override_rlimit is set. This effectively restores the old behavior.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50272", "url": "https://ubuntu.com/security/CVE-2024-50272", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: filemap: Fix bounds checking in filemap_read() If the caller supplies an iocb->ki_pos value that is close to the filesystem upper limit, and an iterator with a count that causes us to overflow that limit, then filemap_read() enters an infinite loop. This behaviour was discovered when testing xfstests generic/525 with the \"localio\" optimisation for loopback NFS mounts.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53104", "url": "https://ubuntu.com/security/CVE-2024-53104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_parse_format This can lead to out of bounds writes since frames of this type were not taken into account when calculating the size of the frames buffer in uvc_parse_streaming.", "cve_priority": "high", "cve_public_date": "2024-12-02 08:15:00 UTC" }, { "cve": "CVE-2024-50273", "url": "https://ubuntu.com/security/CVE-2024-50273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reinitialize delayed ref list after deleting it from the list At insert_delayed_ref() if we need to update the action of an existing ref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head's ref_add_list using list_del(), which leaves the ref's add_list member not reinitialized, as list_del() sets the next and prev members of the list to LIST_POISON1 and LIST_POISON2, respectively. If later we end up calling drop_delayed_ref() against the ref, which can happen during merging or when destroying delayed refs due to a transaction abort, we can trigger a crash since at drop_delayed_ref() we call list_empty() against the ref's add_list, which returns false since the list was not reinitialized after the list_del() and as a consequence we call list_del() again at drop_delayed_ref(). This results in an invalid list access since the next and prev members are set to poison pointers, resulting in a splat if CONFIG_LIST_HARDENED and CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences otherwise. So fix this by deleting from the list with list_del_init() instead.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53064", "url": "https://ubuntu.com/security/CVE-2024-53064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix idpf_vc_core_init error path In an event where the platform running the device control plane is rebooted, reset is detected on the driver. It releases all the resources and waits for the reset to complete. Once the reset is done, it tries to build the resources back. At this time if the device control plane is not yet started, then the driver timeouts on the virtchnl message and retries to establish the mailbox again. In the retry flow, mailbox is deinitialized but the mailbox workqueue is still alive and polling for the mailbox message. This results in accessing the released control queue leading to null-ptr-deref. Fix it by unrolling the work queue cancellation and mailbox deinitialization in the reverse order which they got initialized.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50274", "url": "https://ubuntu.com/security/CVE-2024-50274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: avoid vport access in idpf_get_link_ksettings When the device control plane is removed or the platform running device control plane is rebooted, a reset is detected on the driver. On driver reset, it releases the resources and waits for the reset to complete. If the reset fails, it takes the error path and releases the vport lock. At this time if the monitoring tools tries to access link settings, it call traces for accessing released vport pointer. To avoid it, move link_speed_mbps to netdev_priv structure which removes the dependency on vport pointer and the vport lock in idpf_get_link_ksettings. Also use netif_carrier_ok() to check the link status and adjust the offsetof to use link_up instead of link_speed_mbps.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53065", "url": "https://ubuntu.com/security/CVE-2024-53065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/slab: fix warning caused by duplicate kmem_cache creation in kmem_buckets_create Commit b035f5a6d852 (\"mm: slab: reduce the kmalloc() minimum alignment if DMA bouncing possible\") reduced ARCH_KMALLOC_MINALIGN to 8 on arm64. However, with KASAN_HW_TAGS enabled, arch_slab_minalign() becomes 16. This causes kmalloc_caches[*][8] to be aliased to kmalloc_caches[*][16], resulting in kmem_buckets_create() attempting to create a kmem_cache for size 16 twice. This duplication triggers warnings on boot: [ 2.325108] ------------[ cut here ]------------ [ 2.325135] kmem_cache of name 'memdup_user-16' already exists [ 2.325783] WARNING: CPU: 0 PID: 1 at mm/slab_common.c:107 __kmem_cache_create_args+0xb8/0x3b0 [ 2.327957] Modules linked in: [ 2.328550] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5mm-unstable-arm64+ #12 [ 2.328683] Hardware name: QEMU QEMU Virtual Machine, BIOS 2024.02-2 03/11/2024 [ 2.328790] pstate: 61000009 (nZCv daif -PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 2.328911] pc : __kmem_cache_create_args+0xb8/0x3b0 [ 2.328930] lr : __kmem_cache_create_args+0xb8/0x3b0 [ 2.328942] sp : ffff800083d6fc50 [ 2.328961] x29: ffff800083d6fc50 x28: f2ff0000c1674410 x27: ffff8000820b0598 [ 2.329061] x26: 000000007fffffff x25: 0000000000000010 x24: 0000000000002000 [ 2.329101] x23: ffff800083d6fce8 x22: ffff8000832222e8 x21: ffff800083222388 [ 2.329118] x20: f2ff0000c1674410 x19: f5ff0000c16364c0 x18: ffff800083d80030 [ 2.329135] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 2.329152] x14: 0000000000000000 x13: 0a73747369786520 x12: 79646165726c6120 [ 2.329169] x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : 0000000000000000 [ 2.329194] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 [ 2.329210] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 2.329226] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 2.329291] Call trace: [ 2.329407] __kmem_cache_create_args+0xb8/0x3b0 [ 2.329499] kmem_buckets_create+0xfc/0x320 [ 2.329526] init_user_buckets+0x34/0x78 [ 2.329540] do_one_initcall+0x64/0x3c8 [ 2.329550] kernel_init_freeable+0x26c/0x578 [ 2.329562] kernel_init+0x3c/0x258 [ 2.329574] ret_from_fork+0x10/0x20 [ 2.329698] ---[ end trace 0000000000000000 ]--- [ 2.403704] ------------[ cut here ]------------ [ 2.404716] kmem_cache of name 'msg_msg-16' already exists [ 2.404801] WARNING: CPU: 2 PID: 1 at mm/slab_common.c:107 __kmem_cache_create_args+0xb8/0x3b0 [ 2.404842] Modules linked in: [ 2.404971] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.12.0-rc5mm-unstable-arm64+ #12 [ 2.405026] Tainted: [W]=WARN [ 2.405043] Hardware name: QEMU QEMU Virtual Machine, BIOS 2024.02-2 03/11/2024 [ 2.405057] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2.405079] pc : __kmem_cache_create_args+0xb8/0x3b0 [ 2.405100] lr : __kmem_cache_create_args+0xb8/0x3b0 [ 2.405111] sp : ffff800083d6fc50 [ 2.405115] x29: ffff800083d6fc50 x28: fbff0000c1674410 x27: ffff8000820b0598 [ 2.405135] x26: 000000000000ffd0 x25: 0000000000000010 x24: 0000000000006000 [ 2.405153] x23: ffff800083d6fce8 x22: ffff8000832222e8 x21: ffff800083222388 [ 2.405169] x20: fbff0000c1674410 x19: fdff0000c163d6c0 x18: ffff800083d80030 [ 2.405185] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 2.405201] x14: 0000000000000000 x13: 0a73747369786520 x12: 79646165726c6120 [ 2.405217] x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : 0000000000000000 [ 2.405233] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 [ 2.405248] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 2.405271] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 2.405287] Call trace: [ 2 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50275", "url": "https://ubuntu.com/security/CVE-2024-50275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64/sve: Discard stale CPU state when handling SVE traps The logic for handling SVE traps manipulates saved FPSIMD/SVE state incorrectly, and a race with preemption can result in a task having TIF_SVE set and TIF_FOREIGN_FPSTATE clear even though the live CPU state is stale (e.g. with SVE traps enabled). This has been observed to result in warnings from do_sve_acc() where SVE traps are not expected while TIF_SVE is set: | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* SVE access shouldn't have trapped */ Warnings of this form have been reported intermittently, e.g. https://lore.kernel.org/linux-arm-kernel/CA+G9fYtEGe_DhY2Ms7+L7NKsLYUomGsgqpdBj+QwDLeSg=JhGg@mail.gmail.com/ https://lore.kernel.org/linux-arm-kernel/000000000000511e9a060ce5a45c@google.com/ The race can occur when the SVE trap handler is preempted before and after manipulating the saved FPSIMD/SVE state, starting and ending on the same CPU, e.g. | void do_sve_acc(unsigned long esr, struct pt_regs *regs) | { | // Trap on CPU 0 with TIF_SVE clear, SVE 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(); | | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* SVE access shouldn't have trapped */ | | sve_init_regs() { | if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) { | ... | } else { | fpsimd_to_sve(current); | current->thread.fp_type = FP_STATE_SVE; | } | } | | 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 SVE 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.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50276", "url": "https://ubuntu.com/security/CVE-2024-50276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: vertexcom: mse102x: Fix possible double free of TX skb The scope of the TX skb is wider than just mse102x_tx_frame_spi(), so in case the TX skb room needs to be expanded, we should free the the temporary skb instead of the original skb. Otherwise the original TX skb pointer would be freed again in mse102x_tx_work(), which leads to crashes: Internal error: Oops: 0000000096000004 [#2] PREEMPT SMP CPU: 0 PID: 712 Comm: kworker/0:1 Tainted: G D 6.6.23 Hardware name: chargebyte Charge SOM DC-ONE (DT) Workqueue: events mse102x_tx_work [mse102x] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_release_data+0xb8/0x1d8 lr : skb_release_data+0x1ac/0x1d8 sp : ffff8000819a3cc0 x29: ffff8000819a3cc0 x28: ffff0000046daa60 x27: ffff0000057f2dc0 x26: ffff000005386c00 x25: 0000000000000002 x24: 00000000ffffffff x23: 0000000000000000 x22: 0000000000000001 x21: ffff0000057f2e50 x20: 0000000000000006 x19: 0000000000000000 x18: ffff00003fdacfcc x17: e69ad452d0c49def x16: 84a005feff870102 x15: 0000000000000000 x14: 000000000000024a x13: 0000000000000002 x12: 0000000000000000 x11: 0000000000000400 x10: 0000000000000930 x9 : ffff00003fd913e8 x8 : fffffc00001bc008 x7 : 0000000000000000 x6 : 0000000000000008 x5 : ffff00003fd91340 x4 : 0000000000000000 x3 : 0000000000000009 x2 : 00000000fffffffe x1 : 0000000000000000 x0 : 0000000000000000 Call trace: skb_release_data+0xb8/0x1d8 kfree_skb_reason+0x48/0xb0 mse102x_tx_work+0x164/0x35c [mse102x] process_one_work+0x138/0x260 worker_thread+0x32c/0x438 kthread+0x118/0x11c ret_from_fork+0x10/0x20 Code: aa1303e0 97fffab6 72001c1f 54000141 (f9400660)", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53066", "url": "https://ubuntu.com/security/CVE-2024-53066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfs: Fix KMSAN warning in decode_getfattr_attrs() Fix the following KMSAN warning: CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G B Tainted: [B]=BAD_PAGE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) ===================================================== ===================================================== BUG: KMSAN: uninit-value in decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_generic+0x806/0xb00 nfs4_xdr_dec_getattr+0x1de/0x240 rpcauth_unwrap_resp_decode+0xab/0x100 rpcauth_unwrap_resp+0x95/0xc0 call_decode+0x4ff/0xb50 __rpc_execute+0x57b/0x19d0 rpc_execute+0x368/0x5e0 rpc_run_task+0xcfe/0xee0 nfs4_proc_getattr+0x5b5/0x990 __nfs_revalidate_inode+0x477/0xd00 nfs_access_get_cached+0x1021/0x1cc0 nfs_do_access+0x9f/0xae0 nfs_permission+0x1e4/0x8c0 inode_permission+0x356/0x6c0 link_path_walk+0x958/0x1330 path_lookupat+0xce/0x6b0 filename_lookup+0x23e/0x770 vfs_statx+0xe7/0x970 vfs_fstatat+0x1f2/0x2c0 __se_sys_newfstatat+0x67/0x880 __x64_sys_newfstatat+0xbd/0x120 x64_sys_call+0x1826/0x3cf0 do_syscall_64+0xd0/0x1b0 entry_SYSCALL_64_after_hwframe+0x77/0x7f The KMSAN warning is triggered in decode_getfattr_attrs(), when calling decode_attr_mdsthreshold(). It appears that fattr->mdsthreshold is not initialized. Fix the issue by initializing fattr->mdsthreshold to NULL in nfs_fattr_init().", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53067", "url": "https://ubuntu.com/security/CVE-2024-53067", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Start the RTC update work later The RTC update work involves runtime resuming the UFS controller. Hence, only start the RTC update work after runtime power management in the UFS driver has been fully initialized. This patch fixes the following kernel crash: Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP Workqueue: events ufshcd_rtc_work Call trace: _raw_spin_lock_irqsave+0x34/0x8c (P) pm_runtime_get_if_active+0x24/0x9c (L) pm_runtime_get_if_active+0x24/0x9c ufshcd_rtc_work+0x138/0x1b4 process_one_work+0x148/0x288 worker_thread+0x2cc/0x3d4 kthread+0x110/0x114 ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50277", "url": "https://ubuntu.com/security/CVE-2024-50277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: fix a crash if blk_alloc_disk fails If blk_alloc_disk fails, the variable md->disk is set to an error value. cleanup_mapped_device will see that md->disk is non-NULL and it will attempt to access it, causing a crash on this statement \"md->disk->private_data = NULL;\".", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50278", "url": "https://ubuntu.com/security/CVE-2024-50278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix potential out-of-bounds access on the first resume Out-of-bounds access occurs if the fast device is expanded unexpectedly before the first-time resume of the cache table. This happens because expanding the fast device requires reloading the cache table for cache_create to allocate new in-core data structures that fit the new size, and the check in cache_preresume is not performed during the first resume, leading to the issue. Reproduce steps: 1. prepare component devices: 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\" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct 2. load a cache table of 512 cache blocks, and deliberately expand the fast device before resuming the cache, making the in-core data structures inadequate. dmsetup create cache --notable dmsetup reload cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" dmsetup reload cdata --table \"0 131072 linear /dev/sdc 8192\" dmsetup resume cdata dmsetup resume cache 3. suspend the cache to write out the in-core dirty bitset and hint array, leading to out-of-bounds access to the dirty bitset at offset 0x40: dmsetup suspend cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80 Read of size 8 at addr ffffc90000085040 by task dmsetup/90 (...snip...) The buggy address belongs to the virtual mapping at [ffffc90000085000, ffffc90000087000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by checking the size change on the first resume.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50279", "url": "https://ubuntu.com/security/CVE-2024-50279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix out-of-bounds access to the dirty bitset when resizing dm-cache checks the dirty bits of the cache blocks to be dropped when shrinking the fast device, but an index bug in bitset iteration causes out-of-bounds access. Reproduce steps: 1. create a cache device of 1024 cache blocks (128 bytes dirty bitset) dmsetup create cmeta --table \"0 8192 linear /dev/sdc 0\" dmsetup create cdata --table \"0 131072 linear /dev/sdc 8192\" dmsetup create corig --table \"0 524288 linear /dev/sdc 262144\" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" 2. shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80) dmsetup suspend cache dmsetup reload cdata --table \"0 65536 linear /dev/sdc 8192\" dmsetup resume cdata dmsetup resume cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131 (...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by making the index post-incremented.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50280", "url": "https://ubuntu.com/security/CVE-2024-50280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix flushing uninitialized delayed_work on cache_ctr error An unexpected WARN_ON from flush_work() may occur when cache creation fails, caused by destroying the uninitialized delayed_work waker in the error path of cache_create(). For example, the warning appears on the superblock checksum error. Reproduce steps: 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\" dd if=/dev/urandom of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" Kernel logs: (snip) WARNING: CPU: 0 PID: 84 at kernel/workqueue.c:4178 __flush_work+0x5d4/0x890 Fix by pulling out the cancel_delayed_work_sync() from the constructor's error path. This patch doesn't affect the use-after-free fix for concurrent dm_resume and dm_destroy (commit 6a459d8edbdb (\"dm cache: Fix UAF in destroy()\")) as cache_dtr is not changed.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50281", "url": "https://ubuntu.com/security/CVE-2024-50281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: trusted: dcp: fix NULL dereference in AEAD crypto operation When sealing or unsealing a key blob we currently do not wait for the AEAD cipher operation to finish and simply return after submitting the request. If there is some load on the system we can exit before the cipher operation is done and the buffer we read from/write to is already removed from the stack. This will e.g. result in NULL pointer dereference errors in the DCP driver during blob creation. Fix this by waiting for the AEAD cipher operation to finish before resuming the seal and unseal calls.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50282", "url": "https://ubuntu.com/security/CVE-2024-50282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read() Avoid a possible buffer overflow if size is larger than 4K. (cherry picked from commit f5d873f5825b40d886d03bd2aede91d4cf002434)", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53071", "url": "https://ubuntu.com/security/CVE-2024-53071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Be stricter about IO mapping flags The current panthor_device_mmap_io() implementation has two issues: 1. For mapping DRM_PANTHOR_USER_FLUSH_ID_MMIO_OFFSET, panthor_device_mmap_io() bails if VM_WRITE is set, but does not clear VM_MAYWRITE. That means userspace can use mprotect() to make the mapping writable later on. This is a classic Linux driver gotcha. I don't think this actually has any impact in practice: When the GPU is powered, writes to the FLUSH_ID seem to be ignored; and when the GPU is not powered, the dummy_latest_flush page provided by the driver is deliberately designed to not do any flushes, so the only thing writing to the dummy_latest_flush could achieve would be to make *more* flushes happen. 2. panthor_device_mmap_io() does not block MAP_PRIVATE mappings (which are mappings without the VM_SHARED flag). MAP_PRIVATE in combination with VM_MAYWRITE indicates that the VMA has copy-on-write semantics, which for VM_PFNMAP are semi-supported but fairly cursed. In particular, in such a mapping, the driver can only install PTEs during mmap() by calling remap_pfn_range() (because remap_pfn_range() wants to **store the physical address of the mapped physical memory into the vm_pgoff of the VMA**); installing PTEs later on with a fault handler (as panthor does) is not supported in private mappings, and so if you try to fault in such a mapping, vmf_insert_pfn_prot() splats when it hits a BUG() check. Fix it by clearing the VM_MAYWRITE flag (userspace writing to the FLUSH_ID doesn't make sense) and requiring VM_SHARED (copy-on-write semantics for the FLUSH_ID don't make sense). Reproducers for both scenarios are in the notes of my patch on the mailing list; I tested that these bugs exist on a Rock 5B machine. Note that I only compile-tested the patch, I haven't tested it; I don't have a working kernel build setup for the test machine yet. Please test it before applying it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53080", "url": "https://ubuntu.com/security/CVE-2024-53080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Lock XArray when getting entries for the VM Similar to commit cac075706f29 (\"drm/panthor: Fix race when converting group handle to group object\") we need to use the XArray's internal locking when retrieving a vm pointer from there. v2: Removed part of the patch that was trying to protect fetching the heap pointer from XArray, as that operation is protected by the @pool->lock.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53084", "url": "https://ubuntu.com/security/CVE-2024-53084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Break an object reference loop When remaining resources are being cleaned up on driver close, outstanding VM mappings may result in resources being leaked, due to an object reference loop, as shown below, with each object (or set of objects) referencing the object below it: PVR GEM Object GPU scheduler \"finished\" fence GPU scheduler “scheduled” fence PVR driver “done” fence PVR Context PVR VM Context PVR VM Mappings PVR GEM Object The reference that the PVR VM Context has on the VM mappings is a soft one, in the sense that the freeing of outstanding VM mappings is done as part of VM context destruction; no reference counts are involved, as is the case for all the other references in the loop. To break the reference loop during cleanup, free the outstanding VM mappings before destroying the PVR Context associated with the VM context.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53085", "url": "https://ubuntu.com/security/CVE-2024-53085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: Lock TPM chip in tpm_pm_suspend() first Setting TPM_CHIP_FLAG_SUSPENDED in the end of tpm_pm_suspend() can be racy according, as this leaves window for tpm_hwrng_read() to be called while the operation is in progress. The recent bug report gives also evidence of this behaviour. Aadress this by locking the TPM chip before checking any chip->flags both in tpm_pm_suspend() and tpm_hwrng_read(). Move TPM_CHIP_FLAG_SUSPENDED check inside tpm_get_random() so that it will be always checked only when the lock is reserved.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53086", "url": "https://ubuntu.com/security/CVE-2024-53086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Drop VM dma-resv lock on xe_sync_in_fence_get failure in exec IOCTL Upon failure all locks need to be dropped before returning to the user. (cherry picked from commit 7d1a4258e602ffdce529f56686925034c1b3b095)", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53087", "url": "https://ubuntu.com/security/CVE-2024-53087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix possible exec queue leak in exec IOCTL In a couple of places after an exec queue is looked up the exec IOCTL returns on input errors without dropping the exec queue ref. Fix this ensuring the exec queue ref is dropped on input error. (cherry picked from commit 07064a200b40ac2195cb6b7b779897d9377e5e6f)", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50283", "url": "https://ubuntu.com/security/CVE-2024-50283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-use-after-free in smb3_preauth_hash_rsp ksmbd_user_session_put should be called under smb3_preauth_hash_rsp(). It will avoid freeing session before calling smb3_preauth_hash_rsp().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50284", "url": "https://ubuntu.com/security/CVE-2024-50284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix the missing xa_store error check xa_store() can fail, it return xa_err(-EINVAL) if the entry cannot be stored in an XArray, or xa_err(-ENOMEM) if memory allocation failed, so check error for xa_store() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50285", "url": "https://ubuntu.com/security/CVE-2024-50285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: check outstanding simultaneous SMB operations If Client send simultaneous SMB operations to ksmbd, It exhausts too much memory through the \"ksmbd_work_cache”. It will cause OOM issue. ksmbd has a credit mechanism but it can't handle this problem. This patch add the check if it exceeds max credits to prevent this problem by assuming that one smb request consumes at least one credit.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50286", "url": "https://ubuntu.com/security/CVE-2024-50286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-use-after-free in ksmbd_smb2_session_create There is a race condition between ksmbd_smb2_session_create and ksmbd_expire_session. This patch add missing sessions_table_lock while adding/deleting session from global session table.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50287", "url": "https://ubuntu.com/security/CVE-2024-50287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-tpg: prevent the risk of a division by zero As reported by Coverity, the logic at tpg_precalculate_line() blindly rescales the buffer even when scaled_witdh is equal to zero. If this ever happens, this will cause a division by zero. Instead, add a WARN_ON_ONCE() to trigger such cases and return without doing any precalculation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50288", "url": "https://ubuntu.com/security/CVE-2024-50288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: fix buffer overwrite when using > 32 buffers The maximum number of buffers that can be requested was increased to 64 for the video capture queue. But video capture used a must_blank array that was still sized for 32 (VIDEO_MAX_FRAME). This caused an out-of-bounds write when using buffer indices >= 32. Create a new define MAX_VID_CAP_BUFFERS that is used to access the must_blank array and set max_num_buffers for the video capture queue. This solves a crash reported by: \thttps://bugzilla.kernel.org/show_bug.cgi?id=219258", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50289", "url": "https://ubuntu.com/security/CVE-2024-50289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: av7110: fix a spectre vulnerability As warned by smatch: \tdrivers/staging/media/av7110/av7110_ca.c:270 dvb_ca_ioctl() warn: potential spectre issue 'av7110->ci_slot' [w] (local cap) There is a spectre-related vulnerability at the code. Fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50290", "url": "https://ubuntu.com/security/CVE-2024-50290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx24116: prevent overflows on SNR calculus as reported by Coverity, if reading SNR registers fail, a negative number will be returned, causing an underflow when reading SNR registers. Prevent that.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53061", "url": "https://ubuntu.com/security/CVE-2024-53061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: s5p-jpeg: prevent buffer overflows The current logic allows word to be less than 2. If this happens, there will be buffer overflows, as reported by smatch. Add extra checks to prevent it. While here, remove an unused word = 0 assignment.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53081", "url": "https://ubuntu.com/security/CVE-2024-53081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ar0521: don't overflow when checking PLL values The PLL checks are comparing 64 bit integers with 32 bit ones, as reported by Coverity. Depending on the values of the variables, this may underflow. Fix it ensuring that both sides of the expression are u64.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53062", "url": "https://ubuntu.com/security/CVE-2024-53062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mgb4: protect driver against spectre Frequency range is set from sysfs via frequency_range_store(), being vulnerable to spectre, as reported by smatch: \tdrivers/media/pci/mgb4/mgb4_cmt.c:231 mgb4_cmt_set_vin_freq_range() warn: potential spectre issue 'cmt_vals_in' [r] \tdrivers/media/pci/mgb4/mgb4_cmt.c:238 mgb4_cmt_set_vin_freq_range() warn: possible spectre second half. 'reg_set' Fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50291", "url": "https://ubuntu.com/security/CVE-2024-50291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvb-core: add missing buffer index check dvb_vb2_expbuf() didn't check if the given buffer index was for a valid buffer. Add this check.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50292", "url": "https://ubuntu.com/security/CVE-2024-50292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: stm32: spdifrx: fix dma channel release in stm32_spdifrx_remove In case of error when requesting ctrl_chan DMA channel, ctrl_chan is not null. So the release of the dma channel leads to the following issue: [ 4.879000] st,stm32-spdifrx 500d0000.audio-controller: dma_request_slave_channel error -19 [ 4.888975] Unable to handle kernel NULL pointer dereference at virtual address 000000000000003d [...] [ 5.096577] Call trace: [ 5.099099] dma_release_channel+0x24/0x100 [ 5.103235] stm32_spdifrx_remove+0x24/0x60 [snd_soc_stm32_spdifrx] [ 5.109494] stm32_spdifrx_probe+0x320/0x4c4 [snd_soc_stm32_spdifrx] To avoid this issue, release channel only if the pointer is valid.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53063", "url": "https://ubuntu.com/security/CVE-2024-53063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvbdev: prevent the risk of out of memory access The dvbdev contains a static variable used to store dvb minors. The behavior of it depends if CONFIG_DVB_DYNAMIC_MINORS is set or not. When not set, dvb_register_device() won't check for boundaries, as it will rely that a previous call to dvb_register_adapter() would already be enforcing it. On a similar way, dvb_device_open() uses the assumption that the register functions already did the needed checks. This can be fragile if some device ends using different calls. This also generate warnings on static check analysers like Coverity. So, add explicit guards to prevent potential risk of OOM issues.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50293", "url": "https://ubuntu.com/security/CVE-2024-50293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: do not leave a dangling sk pointer in __smc_create() Thanks to commit 4bbd360a5084 (\"socket: Print pf->create() when it does not clear sock->sk on failure.\"), syzbot found an issue with AF_SMC: smc_create must clear sock->sk on failure, family: 43, type: 1, protocol: 0 WARNING: CPU: 0 PID: 5827 at net/socket.c:1565 __sock_create+0x96f/0xa30 net/socket.c:1563 Modules linked in: CPU: 0 UID: 0 PID: 5827 Comm: syz-executor259 Not tainted 6.12.0-rc6-next-20241106-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:__sock_create+0x96f/0xa30 net/socket.c:1563 Code: 03 00 74 08 4c 89 e7 e8 4f 3b 85 f8 49 8b 34 24 48 c7 c7 40 89 0c 8d 8b 54 24 04 8b 4c 24 0c 44 8b 44 24 08 e8 32 78 db f7 90 <0f> 0b 90 90 e9 d3 fd ff ff 89 e9 80 e1 07 fe c1 38 c1 0f 8c ee f7 RSP: 0018:ffffc90003e4fda0 EFLAGS: 00010246 RAX: 099c6f938c7f4700 RBX: 1ffffffff1a595fd RCX: ffff888034823c00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 00000000ffffffe9 R08: ffffffff81567052 R09: 1ffff920007c9f50 R10: dffffc0000000000 R11: fffff520007c9f51 R12: ffffffff8d2cafe8 R13: 1ffffffff1a595fe R14: ffffffff9a789c40 R15: ffff8880764298c0 FS: 000055557b518380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa62ff43225 CR3: 0000000031628000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: sock_create net/socket.c:1616 [inline] __sys_socket_create net/socket.c:1653 [inline] __sys_socket+0x150/0x3c0 net/socket.c:1700 __do_sys_socket net/socket.c:1714 [inline] __se_sys_socket net/socket.c:1712 [inline] For reference, see commit 2d859aff775d (\"Merge branch 'do-not-leave-dangling-sk-pointers-in-pf-create-functions'\")", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50294", "url": "https://ubuntu.com/security/CVE-2024-50294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix missing locking causing hanging calls If a call gets aborted (e.g. because kafs saw a signal) between it being queued for connection and the I/O thread picking up the call, the abort will be prioritised over the connection and it will be removed from local->new_client_calls by rxrpc_disconnect_client_call() without a lock being held. This may cause other calls on the list to disappear if a race occurs. Fix this by taking the client_call_lock when removing a call from whatever list its ->wait_link happens to be on.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50295", "url": "https://ubuntu.com/security/CVE-2024-50295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: arc: fix the device for dma_map_single/dma_unmap_single The ndev->dev and pdev->dev aren't the same device, use ndev->dev.parent which has dma_mask, ndev->dev.parent is just pdev->dev. Or it would cause the following issue: [ 39.933526] ------------[ cut here ]------------ [ 39.938414] WARNING: CPU: 1 PID: 501 at kernel/dma/mapping.c:149 dma_map_page_attrs+0x90/0x1f8", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53082", "url": "https://ubuntu.com/security/CVE-2024-53082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_net: Add hash_key_length check Add hash_key_length check in virtnet_probe() to avoid possible out of bound errors when setting/reading the hash key.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50296", "url": "https://ubuntu.com/security/CVE-2024-50296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash when uninstalling driver When the driver is uninstalled and the VF is disabled concurrently, a kernel crash occurs. The reason is that the two actions call function pci_disable_sriov(). The num_VFs is checked to determine whether to release the corresponding resources. During the second calling, num_VFs is not 0 and the resource release function is called. However, the corresponding resource has been released during the first invoking. Therefore, the problem occurs: [15277.839633][T50670] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ... [15278.131557][T50670] Call trace: [15278.134686][T50670] klist_put+0x28/0x12c [15278.138682][T50670] klist_del+0x14/0x20 [15278.142592][T50670] device_del+0xbc/0x3c0 [15278.146676][T50670] pci_remove_bus_device+0x84/0x120 [15278.151714][T50670] pci_stop_and_remove_bus_device+0x6c/0x80 [15278.157447][T50670] pci_iov_remove_virtfn+0xb4/0x12c [15278.162485][T50670] sriov_disable+0x50/0x11c [15278.166829][T50670] pci_disable_sriov+0x24/0x30 [15278.171433][T50670] hnae3_unregister_ae_algo_prepare+0x60/0x90 [hnae3] [15278.178039][T50670] hclge_exit+0x28/0xd0 [hclge] [15278.182730][T50670] __se_sys_delete_module.isra.0+0x164/0x230 [15278.188550][T50670] __arm64_sys_delete_module+0x1c/0x30 [15278.193848][T50670] invoke_syscall+0x50/0x11c [15278.198278][T50670] el0_svc_common.constprop.0+0x158/0x164 [15278.203837][T50670] do_el0_svc+0x34/0xcc [15278.207834][T50670] el0_svc+0x20/0x30 For details, see the following figure. rmmod hclge disable VFs ---------------------------------------------------- hclge_exit() sriov_numvfs_store() ... device_lock() pci_disable_sriov() hns3_pci_sriov_configure() pci_disable_sriov() sriov_disable() sriov_disable() if !num_VFs : if !num_VFs : return; return; sriov_del_vfs() sriov_del_vfs() ... ... klist_put() klist_put() ... ... num_VFs = 0; num_VFs = 0; device_unlock(); In this patch, when driver is removing, we get the device_lock() to protect num_VFs, just like sriov_numvfs_store().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53088", "url": "https://ubuntu.com/security/CVE-2024-53088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: fix race condition by adding filter's intermediate sync state Fix a race condition in the i40e driver that leads to MAC/VLAN filters becoming corrupted and leaking. Address the issue that occurs under heavy load when multiple threads are concurrently modifying MAC/VLAN filters by setting mac and port VLAN. 1. Thread T0 allocates a filter in i40e_add_filter() within i40e_ndo_set_vf_port_vlan(). 2. Thread T1 concurrently frees the filter in __i40e_del_filter() within i40e_ndo_set_vf_mac(). 3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which refers to the already freed filter memory, causing corruption. Reproduction steps: 1. Spawn multiple VFs. 2. Apply a concurrent heavy load by running parallel operations to change MAC addresses on the VFs and change port VLANs on the host. 3. Observe errors in dmesg: \"Error I40E_AQ_RC_ENOSPC adding RX filters on VF XX, \tplease set promiscuous on manually for VF XX\". Exact code for stable reproduction Intel can't open-source now. The fix involves implementing a new intermediate filter state, I40E_FILTER_NEW_SYNC, for the time when a filter is on a tmp_add_list. These filters cannot be deleted from the hash list directly but must be removed using the full process.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50297", "url": "https://ubuntu.com/security/CVE-2024-50297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: xilinx: axienet: Enqueue Tx packets in dql before dmaengine starts Enqueue packets in dql after dma engine starts causes race condition. Tx transfer starts once dma engine is started and may execute dql dequeue in completion before it gets queued. It results in following kernel crash while running iperf stress test: kernel BUG at lib/dynamic_queue_limits.c:99! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP pc : dql_completed+0x238/0x248 lr : dql_completed+0x3c/0x248 Call trace: dql_completed+0x238/0x248 axienet_dma_tx_cb+0xa0/0x170 xilinx_dma_do_tasklet+0xdc/0x290 tasklet_action_common+0xf8/0x11c tasklet_action+0x30/0x3c handle_softirqs+0xf8/0x230 Start dmaengine after enqueue in dql fixes the crash.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50298", "url": "https://ubuntu.com/security/CVE-2024-50298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: enetc: allocate vf_state during PF probes In the previous implementation, vf_state is allocated memory only when VF is enabled. However, net_device_ops::ndo_set_vf_mac() may be called before VF is enabled to configure the MAC address of VF. If this is the case, enetc_pf_set_vf_mac() will access vf_state, resulting in access to a null pointer. The simplified error log is as follows. root@ls1028ardb:~# ip link set eno0 vf 1 mac 00:0c:e7:66:77:89 [ 173.543315] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 [ 173.637254] pc : enetc_pf_set_vf_mac+0x3c/0x80 Message from sy [ 173.641973] lr : do_setlink+0x4a8/0xec8 [ 173.732292] Call trace: [ 173.734740] enetc_pf_set_vf_mac+0x3c/0x80 [ 173.738847] __rtnl_newlink+0x530/0x89c [ 173.742692] rtnl_newlink+0x50/0x7c [ 173.746189] rtnetlink_rcv_msg+0x128/0x390 [ 173.750298] netlink_rcv_skb+0x60/0x130 [ 173.754145] rtnetlink_rcv+0x18/0x24 [ 173.757731] netlink_unicast+0x318/0x380 [ 173.761665] netlink_sendmsg+0x17c/0x3c8", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50299", "url": "https://ubuntu.com/security/CVE-2024-50299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: properly validate chunk size in sctp_sf_ootb() A size validation fix similar to that in Commit 50619dbf8db7 (\"sctp: add size validation when walking chunks\") is also required in sctp_sf_ootb() to address a crash reported by syzbot: BUG: KMSAN: uninit-value in sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_do_sm+0x181/0x93d0 net/sctp/sm_sideeffect.c:1166 sctp_endpoint_bh_rcv+0xc38/0xf90 net/sctp/endpointola.c:407 sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88 sctp_rcv+0x3831/0x3b20 net/sctp/input.c:243 sctp4_rcv+0x42/0x50 net/sctp/protocol.c:1159 ip_protocol_deliver_rcu+0xb51/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50300", "url": "https://ubuntu.com/security/CVE-2024-50300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: rtq2208: Fix uninitialized use of regulator_config Fix rtq2208 driver uninitialized use to cause kernel error.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50301", "url": "https://ubuntu.com/security/CVE-2024-50301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: security/keys: fix slab-out-of-bounds in key_task_permission KASAN reports an out of bounds read: BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline] BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362 CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0x107/0x167 lib/dump_stack.c:123 print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 __kuid_val include/linux/uidgid.h:36 [inline] uid_eq include/linux/uidgid.h:63 [inline] key_task_permission+0x394/0x410 security/keys/permission.c:54 search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793 This issue was also reported by syzbot. It can be reproduced by following these steps(more details [1]): 1. Obtain more than 32 inputs that have similar hashes, which ends with the pattern '0xxxxxxxe6'. 2. Reboot and add the keys obtained in step 1. The reproducer demonstrates how this issue happened: 1. In the search_nested_keyrings function, when it iterates through the slots in a node(below tag ascend_to_node), if the slot pointer is meta and node->back_pointer != NULL(it means a root), it will proceed to descend_to_node. However, there is an exception. If node is the root, and one of the slots points to a shortcut, it will be treated as a keyring. 2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function. However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as ASSOC_ARRAY_PTR_SUBTYPE_MASK. 3. When 32 keys with the similar hashes are added to the tree, the ROOT has keys with hashes that are not similar (e.g. slot 0) and it splits NODE A without using a shortcut. When NODE A is filled with keys that all hashes are xxe6, the keys are similar, NODE A will split with a shortcut. Finally, it forms the tree as shown below, where slot 6 points to a shortcut. NODE A +------>+---+ ROOT | | 0 | xxe6 +---+ | +---+ xxxx | 0 | shortcut : : xxe6 +---+ | +---+ xxe6 : : | | | xxe6 +---+ | +---+ | 6 |---+ : : xxe6 +---+ +---+ xxe6 : : | f | xxe6 +---+ +---+ xxe6 | f | +---+ 4. As mentioned above, If a slot(slot 6) of the root points to a shortcut, it may be mistakenly transferred to a key*, leading to a read out-of-bounds read. To fix this issue, one should jump to descend_to_node if the ptr is a shortcut, regardless of whether the node is root or not. [1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/ [jarkko: tweaked the commit message a bit to have an appropriate closes tag.]", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53072", "url": "https://ubuntu.com/security/CVE-2024-53072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/pmc: Detect when STB is not available Loading the amd_pmc module as: amd_pmc enable_stb=1 ...can result in the following messages in the kernel ring buffer: amd_pmc AMDI0009:00: SMU cmd failed. err: 0xff ioremap on RAM at 0x0000000000000000 - 0x0000000000ffffff WARNING: CPU: 10 PID: 2151 at arch/x86/mm/ioremap.c:217 __ioremap_caller+0x2cd/0x340 Further debugging reveals that this occurs when the requests for S2D_PHYS_ADDR_LOW and S2D_PHYS_ADDR_HIGH return a value of 0, indicating that the STB is inaccessible. To prevent the ioremap warning and provide clarity to the user, handle the invalid address and display an error message.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50302", "url": "https://ubuntu.com/security/CVE-2024-50302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: zero-initialize the report buffer Since the report buffer is used by all kinds of drivers in various ways, let's zero-initialize it during allocation to make sure that it can't be ever used to leak kernel memory via specially-crafted report.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53068", "url": "https://ubuntu.com/security/CVE-2024-53068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix slab-use-after-free in scmi_bus_notifier() The scmi_dev->name is released prematurely in __scmi_device_destroy(), which causes slab-use-after-free when accessing scmi_dev->name in scmi_bus_notifier(). So move the release of scmi_dev->name to scmi_device_release() to avoid slab-use-after-free. | BUG: KASAN: slab-use-after-free in strncmp+0xe4/0xec | Read of size 1 at addr ffffff80a482bcc0 by task swapper/0/1 | | CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.6.38-debug #1 | Hardware name: Qualcomm Technologies, Inc. SA8775P Ride (DT) | Call trace: | dump_backtrace+0x94/0x114 | show_stack+0x18/0x24 | dump_stack_lvl+0x48/0x60 | print_report+0xf4/0x5b0 | kasan_report+0xa4/0xec | __asan_report_load1_noabort+0x20/0x2c | strncmp+0xe4/0xec | scmi_bus_notifier+0x5c/0x54c | notifier_call_chain+0xb4/0x31c | blocking_notifier_call_chain+0x68/0x9c | bus_notify+0x54/0x78 | device_del+0x1bc/0x840 | device_unregister+0x20/0xb4 | __scmi_device_destroy+0xac/0x280 | scmi_device_destroy+0x94/0xd0 | scmi_chan_setup+0x524/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20 | | Allocated by task 1: | kasan_save_stack+0x2c/0x54 | kasan_set_track+0x2c/0x40 | kasan_save_alloc_info+0x24/0x34 | __kasan_kmalloc+0xa0/0xb8 | __kmalloc_node_track_caller+0x6c/0x104 | kstrdup+0x48/0x84 | kstrdup_const+0x34/0x40 | __scmi_device_create.part.0+0x8c/0x408 | scmi_device_create+0x104/0x370 | scmi_chan_setup+0x2a0/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20 | | Freed by task 1: | kasan_save_stack+0x2c/0x54 | kasan_set_track+0x2c/0x40 | kasan_save_free_info+0x38/0x5c | __kasan_slab_free+0xe8/0x164 | __kmem_cache_free+0x11c/0x230 | kfree+0x70/0x130 | kfree_const+0x20/0x40 | __scmi_device_destroy+0x70/0x280 | scmi_device_destroy+0x94/0xd0 | scmi_chan_setup+0x524/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53069", "url": "https://ubuntu.com/security/CVE-2024-53069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: qcom: scm: fix a NULL-pointer dereference Some SCM calls can be invoked with __scm being NULL (the driver may not have been and will not be probed as there's no SCM entry in device-tree). Make sure we don't dereference a NULL pointer.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50212", "url": "https://ubuntu.com/security/CVE-2024-50212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib: alloc_tag_module_unload must wait for pending kfree_rcu calls Ben Greear reports following splat: ------------[ cut here ]------------ net/netfilter/nf_nat_core.c:1114 module nf_nat func:nf_nat_register_fn has 256 allocated at module unload WARNING: CPU: 1 PID: 10421 at lib/alloc_tag.c:168 alloc_tag_module_unload+0x22b/0x3f0 Modules linked in: nf_nat(-) btrfs ufs qnx4 hfsplus hfs minix vfat msdos fat ... Hardware name: Default string Default string/SKYBAY, BIOS 5.12 08/04/2020 RIP: 0010:alloc_tag_module_unload+0x22b/0x3f0 codetag_unload_module+0x19b/0x2a0 ? codetag_load_module+0x80/0x80 nf_nat module exit calls kfree_rcu on those addresses, but the free operation is likely still pending by the time alloc_tag checks for leaks. Wait for outstanding kfree_rcu operations to complete before checking resolves this warning. Reproducer: unshare -n iptables-nft -t nat -A PREROUTING -p tcp grep nf_nat /proc/allocinfo # will list 4 allocations rmmod nft_chain_nat rmmod nf_nat # will WARN. [akpm@linux-foundation.org: add comment]", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53046", "url": "https://ubuntu.com/security/CVE-2024-53046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: dts: imx8ulp: correct the flexspi compatible string The flexspi on imx8ulp only has 16 LUTs, and imx8mm flexspi has 32 LUTs, so correct the compatible string here, otherwise will meet below error: [ 1.119072] ------------[ cut here ]------------ [ 1.123926] WARNING: CPU: 0 PID: 1 at drivers/spi/spi-nxp-fspi.c:855 nxp_fspi_exec_op+0xb04/0xb64 [ 1.133239] Modules linked in: [ 1.136448] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-rc6-next-20240902-00001-g131bf9439dd9 #69 [ 1.146821] Hardware name: NXP i.MX8ULP EVK (DT) [ 1.151647] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.158931] pc : nxp_fspi_exec_op+0xb04/0xb64 [ 1.163496] lr : nxp_fspi_exec_op+0xa34/0xb64 [ 1.168060] sp : ffff80008002b2a0 [ 1.171526] x29: ffff80008002b2d0 x28: 0000000000000000 x27: 0000000000000000 [ 1.179002] x26: ffff2eb645542580 x25: ffff800080610014 x24: ffff800080610000 [ 1.186480] x23: ffff2eb645548080 x22: 0000000000000006 x21: ffff2eb6455425e0 [ 1.193956] x20: 0000000000000000 x19: ffff80008002b5e0 x18: ffffffffffffffff [ 1.201432] x17: ffff2eb644467508 x16: 0000000000000138 x15: 0000000000000002 [ 1.208907] x14: 0000000000000000 x13: ffff2eb6400d8080 x12: 00000000ffffff00 [ 1.216378] x11: 0000000000000000 x10: ffff2eb6400d8080 x9 : ffff2eb697adca80 [ 1.223850] x8 : ffff2eb697ad3cc0 x7 : 0000000100000000 x6 : 0000000000000001 [ 1.231324] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000007a6 [ 1.238795] x2 : 0000000000000000 x1 : 00000000000001ce x0 : 00000000ffffff92 [ 1.246267] Call trace: [ 1.248824] nxp_fspi_exec_op+0xb04/0xb64 [ 1.253031] spi_mem_exec_op+0x3a0/0x430 [ 1.257139] spi_nor_read_id+0x80/0xcc [ 1.261065] spi_nor_scan+0x1ec/0xf10 [ 1.264901] spi_nor_probe+0x108/0x2fc [ 1.268828] spi_mem_probe+0x6c/0xbc [ 1.272574] spi_probe+0x84/0xe4 [ 1.275958] really_probe+0xbc/0x29c [ 1.279713] __driver_probe_device+0x78/0x12c [ 1.284277] driver_probe_device+0xd8/0x15c [ 1.288660] __device_attach_driver+0xb8/0x134 [ 1.293316] bus_for_each_drv+0x88/0xe8 [ 1.297337] __device_attach+0xa0/0x190 [ 1.301353] device_initial_probe+0x14/0x20 [ 1.305734] bus_probe_device+0xac/0xb0 [ 1.309752] device_add+0x5d0/0x790 [ 1.313408] __spi_add_device+0x134/0x204 [ 1.317606] of_register_spi_device+0x3b4/0x590 [ 1.322348] spi_register_controller+0x47c/0x754 [ 1.327181] devm_spi_register_controller+0x4c/0xa4 [ 1.332289] nxp_fspi_probe+0x1cc/0x2b0 [ 1.336307] platform_probe+0x68/0xc4 [ 1.340145] really_probe+0xbc/0x29c [ 1.343893] __driver_probe_device+0x78/0x12c [ 1.348457] driver_probe_device+0xd8/0x15c [ 1.352838] __driver_attach+0x90/0x19c [ 1.356857] bus_for_each_dev+0x7c/0xdc [ 1.360877] driver_attach+0x24/0x30 [ 1.364624] bus_add_driver+0xe4/0x208 [ 1.368552] driver_register+0x5c/0x124 [ 1.372573] __platform_driver_register+0x28/0x34 [ 1.377497] nxp_fspi_driver_init+0x1c/0x28 [ 1.381888] do_one_initcall+0x80/0x1c8 [ 1.385908] kernel_init_freeable+0x1c4/0x28c [ 1.390472] kernel_init+0x20/0x1d8 [ 1.394138] ret_from_fork+0x10/0x20 [ 1.397885] ---[ end trace 0000000000000000 ]--- [ 1.407908] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53052", "url": "https://ubuntu.com/security/CVE-2024-53052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/rw: fix missing NOWAIT check for O_DIRECT start write When io_uring starts a write, it'll call kiocb_start_write() to bump the super block rwsem, preventing any freezes from happening while that write is in-flight. The freeze side will grab that rwsem for writing, excluding any new writers from happening and waiting for existing writes to finish. But io_uring unconditionally uses kiocb_start_write(), which will block if someone is currently attempting to freeze the mount point. This causes a deadlock where freeze is waiting for previous writes to complete, but the previous writes cannot complete, as the task that is supposed to complete them is blocked waiting on starting a new write. This results in the following stuck trace showing that dependency with the write blocked starting a new write: task:fio state:D stack:0 pid:886 tgid:886 ppid:876 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_rwsem_wait+0x1e8/0x3f8 __percpu_down_read+0xe8/0x500 io_write+0xbb8/0xff8 io_issue_sqe+0x10c/0x1020 io_submit_sqes+0x614/0x2110 __arm64_sys_io_uring_enter+0x524/0x1038 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 INFO: task fsfreeze:7364 blocked for more than 15 seconds. Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963 with the attempting freezer stuck trying to grab the rwsem: task:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_down_write+0x2b0/0x680 freeze_super+0x248/0x8a8 do_vfs_ioctl+0x149c/0x1b18 __arm64_sys_ioctl+0xd0/0x1a0 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 Fix this by having the io_uring side honor IOCB_NOWAIT, and only attempt a blocking grab of the super block rwsem if it isn't set. For normal issue where IOCB_NOWAIT would always be set, this returns -EAGAIN which will have io_uring core issue a blocking attempt of the write. That will in turn also get completions run, ensuring forward progress. Since freezing requires CAP_SYS_ADMIN in the first place, this isn't something that can be triggered by a regular user.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50213", "url": "https://ubuntu.com/security/CVE-2024-50213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tests: hdmi: Fix memory leaks in drm_display_mode_from_cea_vic() modprobe drm_hdmi_state_helper_test and then rmmod it, the following memory leak occurs. The `mode` allocated in drm_mode_duplicate() called by drm_display_mode_from_cea_vic() is not freed, which cause the memory leak: \tunreferenced object 0xffffff80ccd18100 (size 128): \t comm \"kunit_try_catch\", pid 1851, jiffies 4295059695 \t hex dump (first 32 bytes): \t 57 62 00 00 80 02 90 02 f0 02 20 03 00 00 e0 01 Wb........ ..... \t ea 01 ec 01 0d 02 00 00 0a 00 00 00 00 00 00 00 ................ \t backtrace (crc c2f1aa95): \t [<000000000f10b11b>] kmemleak_alloc+0x34/0x40 \t [<000000001cd4cf73>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<00000000f1f3cffa>] drm_mode_duplicate+0x44/0x19c \t [<000000008cbeef13>] drm_display_mode_from_cea_vic+0x88/0x98 \t [<0000000019daaacf>] 0xffffffedc11ae69c \t [<000000000aad0f85>] kunit_try_run_case+0x13c/0x3ac \t [<00000000a9210bac>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<000000000a0b2e9e>] kthread+0x2e8/0x374 \t [<00000000bd668858>] ret_from_fork+0x10/0x20 \t...... Free `mode` by using drm_kunit_display_mode_from_cea_vic() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50214", "url": "https://ubuntu.com/security/CVE-2024-50214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/connector: hdmi: Fix memory leak in drm_display_mode_from_cea_vic() modprobe drm_connector_test and then rmmod drm_connector_test, the following memory leak occurs. The `mode` allocated in drm_mode_duplicate() called by drm_display_mode_from_cea_vic() is not freed, which cause the memory leak: \tunreferenced object 0xffffff80cb0ee400 (size 128): \t comm \"kunit_try_catch\", pid 1948, jiffies 4294950339 \t hex dump (first 32 bytes): \t 14 44 02 00 80 07 d8 07 04 08 98 08 00 00 38 04 .D............8. \t 3c 04 41 04 65 04 00 00 05 00 00 00 00 00 00 00 <.A.e........... \t backtrace (crc 90e9585c): \t [<00000000ec42e3d7>] kmemleak_alloc+0x34/0x40 \t [<00000000d0ef055a>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<00000000c2062161>] drm_mode_duplicate+0x44/0x19c \t [<00000000f96c74aa>] drm_display_mode_from_cea_vic+0x88/0x98 \t [<00000000d8f2c8b4>] 0xffffffdc982a4868 \t [<000000005d164dbc>] kunit_try_run_case+0x13c/0x3ac \t [<000000006fb23398>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<000000006ea56ca0>] kthread+0x2e8/0x374 \t [<000000000676063f>] ret_from_fork+0x10/0x20 \t...... Free `mode` by using drm_kunit_display_mode_from_cea_vic() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50215", "url": "https://ubuntu.com/security/CVE-2024-50215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: assign dh_key to NULL after kfree_sensitive ctrl->dh_key might be used across multiple calls to nvmet_setup_dhgroup() for the same controller. So it's better to nullify it after release on error path in order to avoid double free later in nvmet_destroy_auth(). Found by Linux Verification Center (linuxtesting.org) with Svace.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50216", "url": "https://ubuntu.com/security/CVE-2024-50216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix finding a last resort AG in xfs_filestream_pick_ag When the main loop in xfs_filestream_pick_ag fails to find a suitable AG it tries to just pick the online AG. But the loop for that uses args->pag as loop iterator while the later code expects pag to be set. Fix this by reusing the max_pag case for this last resort, and also add a check for impossible case of no AG just to make sure that the uninitialized pag doesn't even escape in theory.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50217", "url": "https://ubuntu.com/security/CVE-2024-50217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free of block device file in __btrfs_free_extra_devids() Mounting btrfs from two images (which have the same one fsid and two different dev_uuids) in certain executing order may trigger an UAF for variable 'device->bdev_file' in __btrfs_free_extra_devids(). And following are the details: 1. Attach image_1 to loop0, attach image_2 to loop1, and scan btrfs devices by ioctl(BTRFS_IOC_SCAN_DEV): / btrfs_device_1 ? loop0 fs_device \\ btrfs_device_2 ? loop1 2. mount /dev/loop0 /mnt btrfs_open_devices btrfs_device_1->bdev_file = btrfs_get_bdev_and_sb(loop0) btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree fail: btrfs_close_devices // -ENOMEM \t btrfs_close_bdev(btrfs_device_1) fput(btrfs_device_1->bdev_file) \t // btrfs_device_1->bdev_file is freed \t btrfs_close_bdev(btrfs_device_2) fput(btrfs_device_2->bdev_file) 3. mount /dev/loop1 /mnt btrfs_open_devices btrfs_get_bdev_and_sb(&bdev_file) // EIO, btrfs_device_1->bdev_file is not assigned, // which points to a freed memory area btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree btrfs_free_extra_devids if (btrfs_device_1->bdev_file) fput(btrfs_device_1->bdev_file) // UAF ! Fix it by setting 'device->bdev_file' as 'NULL' after closing the btrfs_device in btrfs_close_one_device().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53043", "url": "https://ubuntu.com/security/CVE-2024-53043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mctp i2c: handle NULL header address daddr can be NULL if there is no neighbour table entry present, in that case the tx packet should be dropped. saddr will usually be set by MCTP core, but check for NULL in case a packet is transmitted by a different protocol.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50303", "url": "https://ubuntu.com/security/CVE-2024-50303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: resource,kexec: walk_system_ram_res_rev must retain resource flags walk_system_ram_res_rev() erroneously discards resource flags when passing the information to the callback. This causes systems with IORESOURCE_SYSRAM_DRIVER_MANAGED memory to have these resources selected during kexec to store kexec buffers if that memory happens to be at placed above normal system ram. This leads to undefined behavior after reboot. If the kexec buffer is never touched, nothing happens. If the kexec buffer is touched, it could lead to a crash (like below) or undefined behavior. Tested on a system with CXL memory expanders with driver managed memory, TPM enabled, and CONFIG_IMA_KEXEC=y. Adding printk's showed the flags were being discarded and as a result the check for IORESOURCE_SYSRAM_DRIVER_MANAGED passes. find_next_iomem_res: name(System RAM (kmem)) \t\t start(10000000000) \t\t end(1034fffffff) \t\t flags(83000200) locate_mem_hole_top_down: start(10000000000) end(1034fffffff) flags(0) [.] BUG: unable to handle page fault for address: ffff89834ffff000 [.] #PF: supervisor read access in kernel mode [.] #PF: error_code(0x0000) - not-present page [.] PGD c04c8bf067 P4D c04c8bf067 PUD c04c8be067 PMD 0 [.] Oops: 0000 [#1] SMP [.] RIP: 0010:ima_restore_measurement_list+0x95/0x4b0 [.] RSP: 0018:ffffc900000d3a80 EFLAGS: 00010286 [.] RAX: 0000000000001000 RBX: 0000000000000000 RCX: ffff89834ffff000 [.] RDX: 0000000000000018 RSI: ffff89834ffff000 RDI: ffff89834ffff018 [.] RBP: ffffc900000d3ba0 R08: 0000000000000020 R09: ffff888132b8a900 [.] R10: 4000000000000000 R11: 000000003a616d69 R12: 0000000000000000 [.] R13: ffffffff8404ac28 R14: 0000000000000000 R15: ffff89834ffff000 [.] FS: 0000000000000000(0000) GS:ffff893d44640000(0000) knlGS:0000000000000000 [.] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [.] ata5: SATA link down (SStatus 0 SControl 300) [.] CR2: ffff89834ffff000 CR3: 000001034d00f001 CR4: 0000000000770ef0 [.] PKRU: 55555554 [.] Call Trace: [.] [.] ? __die+0x78/0xc0 [.] ? page_fault_oops+0x2a8/0x3a0 [.] ? exc_page_fault+0x84/0x130 [.] ? asm_exc_page_fault+0x22/0x30 [.] ? ima_restore_measurement_list+0x95/0x4b0 [.] ? template_desc_init_fields+0x317/0x410 [.] ? crypto_alloc_tfm_node+0x9c/0xc0 [.] ? init_ima_lsm+0x30/0x30 [.] ima_load_kexec_buffer+0x72/0xa0 [.] ima_init+0x44/0xa0 [.] __initstub__kmod_ima__373_1201_init_ima7+0x1e/0xb0 [.] ? init_ima_lsm+0x30/0x30 [.] do_one_initcall+0xad/0x200 [.] ? idr_alloc_cyclic+0xaa/0x110 [.] ? new_slab+0x12c/0x420 [.] ? new_slab+0x12c/0x420 [.] ? number+0x12a/0x430 [.] ? sysvec_apic_timer_interrupt+0xa/0x80 [.] ? asm_sysvec_apic_timer_interrupt+0x16/0x20 [.] ? parse_args+0xd4/0x380 [.] ? parse_args+0x14b/0x380 [.] kernel_init_freeable+0x1c1/0x2b0 [.] ? rest_init+0xb0/0xb0 [.] kernel_init+0x16/0x1a0 [.] ret_from_fork+0x2f/0x40 [.] ? rest_init+0xb0/0xb0 [.] ret_from_fork_asm+0x11/0x20 [.] ", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50218", "url": "https://ubuntu.com/security/CVE-2024-50218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow Syzbot reported a kernel BUG in ocfs2_truncate_inline. There are two reasons for this: first, the parameter value passed is greater than ocfs2_max_inline_data_with_xattr, second, the start and end parameters of ocfs2_truncate_inline are \"unsigned int\". So, we need to add a sanity check for byte_start and byte_len right before ocfs2_truncate_inline() in ocfs2_remove_inode_range(), if they are greater than ocfs2_max_inline_data_with_xattr return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50219", "url": "https://ubuntu.com/security/CVE-2024-50219", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50263", "url": "https://ubuntu.com/security/CVE-2024-50263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fork: only invoke khugepaged, ksm hooks if no error There is no reason to invoke these hooks early against an mm that is in an incomplete state. The change in commit d24062914837 (\"fork: use __mt_dup() to duplicate maple tree in dup_mmap()\") makes this more pertinent as we may be in a state where entries in the maple tree are not yet consistent. Their placement early in dup_mmap() only appears to have been meaningful for early error checking, and since functionally it'd require a very small allocation to fail (in practice 'too small to fail') that'd only occur in the most dire circumstances, meaning the fork would fail or be OOM'd in any case. Since both khugepaged and KSM tracking are there to provide optimisations to memory performance rather than critical functionality, it doesn't really matter all that much if, under such dire memory pressure, we fail to register an mm with these. As a result, we follow the example of commit d2081b2bf819 (\"mm: khugepaged: make khugepaged_enter() void function\") and make ksm_fork() a void function also. We only expose the mm to these functions once we are done with them and only if no error occurred in the fork operation.", "cve_priority": "medium", "cve_public_date": "2024-11-11 14:15:00 UTC" }, { "cve": "CVE-2024-50220", "url": "https://ubuntu.com/security/CVE-2024-50220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fork: do not invoke uffd on fork if error occurs Patch series \"fork: do not expose incomplete mm on fork\". During fork we may place the virtual memory address space into an inconsistent state before the fork operation is complete. In addition, we may encounter an error during the fork operation that indicates that the virtual memory address space is invalidated. As a result, we should not be exposing it in any way to external machinery that might interact with the mm or VMAs, machinery that is not designed to deal with incomplete state. We specifically update the fork logic to defer khugepaged and ksm to the end of the operation and only to be invoked if no error arose, and disallow uffd from observing fork events should an error have occurred. This patch (of 2): Currently on fork we expose the virtual address space of a process to userland unconditionally if uffd is registered in VMAs, regardless of whether an error arose in the fork. This is performed in dup_userfaultfd_complete() which is invoked unconditionally, and performs two duties - invoking registered handlers for the UFFD_EVENT_FORK event via dup_fctx(), and clearing down userfaultfd_fork_ctx objects established in dup_userfaultfd(). This is problematic, because the virtual address space may not yet be correctly initialised if an error arose. The change in commit d24062914837 (\"fork: use __mt_dup() to duplicate maple tree in dup_mmap()\") makes this more pertinent as we may be in a state where entries in the maple tree are not yet consistent. We address this by, on fork error, ensuring that we roll back state that we would otherwise expect to clean up through the event being handled by userland and perform the memory freeing duty otherwise performed by dup_userfaultfd_complete(). We do this by implementing a new function, dup_userfaultfd_fail(), which performs the same loop, only decrementing reference counts. Note that we perform mmgrab() on the parent and child mm's, however userfaultfd_ctx_put() will mmdrop() this once the reference count drops to zero, so we will avoid memory leaks correctly here.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53047", "url": "https://ubuntu.com/security/CVE-2024-53047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: init: protect sched with rcu_read_lock Enabling CONFIG_PROVE_RCU_LIST with its dependence CONFIG_RCU_EXPERT creates this splat when an MPTCP socket is created: ============================= WARNING: suspicious RCU usage 6.12.0-rc2+ #11 Not tainted ----------------------------- net/mptcp/sched.c:44 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 no locks held by mptcp_connect/176. stack backtrace: CPU: 0 UID: 0 PID: 176 Comm: mptcp_connect Not tainted 6.12.0-rc2+ #11 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl (lib/dump_stack.c:123) lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822) mptcp_sched_find (net/mptcp/sched.c:44 (discriminator 7)) mptcp_init_sock (net/mptcp/protocol.c:2867 (discriminator 1)) ? sock_init_data_uid (arch/x86/include/asm/atomic.h:28) inet_create.part.0.constprop.0 (net/ipv4/af_inet.c:386) ? __sock_create (include/linux/rcupdate.h:347 (discriminator 1)) __sock_create (net/socket.c:1576) __sys_socket (net/socket.c:1671) ? __pfx___sys_socket (net/socket.c:1712) ? do_user_addr_fault (arch/x86/mm/fault.c:1419 (discriminator 1)) __x64_sys_socket (net/socket.c:1728) do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) That's because when the socket is initialised, rcu_read_lock() is not used despite the explicit comment written above the declaration of mptcp_sched_find() in sched.c. Adding the missing lock/unlock avoids the warning.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50221", "url": "https://ubuntu.com/security/CVE-2024-50221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Vangogh: Fix kernel memory out of bounds write KASAN reports that the GPU metrics table allocated in vangogh_tables_init() is not large enough for the memset done in smu_cmn_init_soft_gpu_metrics(). Condensed report follows: [ 33.861314] BUG: KASAN: slab-out-of-bounds in smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu] [ 33.861799] Write of size 168 at addr ffff888129f59500 by task mangoapp/1067 ... [ 33.861808] CPU: 6 UID: 1000 PID: 1067 Comm: mangoapp Tainted: G W 6.12.0-rc4 #356 1a56f59a8b5182eeaf67eb7cb8b13594dd23b544 [ 33.861816] Tainted: [W]=WARN [ 33.861818] Hardware name: Valve Galileo/Galileo, BIOS F7G0107 12/01/2023 [ 33.861822] Call Trace: [ 33.861826] [ 33.861829] dump_stack_lvl+0x66/0x90 [ 33.861838] print_report+0xce/0x620 [ 33.861853] kasan_report+0xda/0x110 [ 33.862794] kasan_check_range+0xfd/0x1a0 [ 33.862799] __asan_memset+0x23/0x40 [ 33.862803] smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.863306] vangogh_get_gpu_metrics_v2_4+0x123/0xad0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.864257] vangogh_common_get_gpu_metrics+0xb0c/0xbc0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.865682] amdgpu_dpm_get_gpu_metrics+0xcc/0x110 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.866160] amdgpu_get_gpu_metrics+0x154/0x2d0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.867135] dev_attr_show+0x43/0xc0 [ 33.867147] sysfs_kf_seq_show+0x1f1/0x3b0 [ 33.867155] seq_read_iter+0x3f8/0x1140 [ 33.867173] vfs_read+0x76c/0xc50 [ 33.867198] ksys_read+0xfb/0x1d0 [ 33.867214] do_syscall_64+0x90/0x160 ... [ 33.867353] Allocated by task 378 on cpu 7 at 22.794876s: [ 33.867358] kasan_save_stack+0x33/0x50 [ 33.867364] kasan_save_track+0x17/0x60 [ 33.867367] __kasan_kmalloc+0x87/0x90 [ 33.867371] vangogh_init_smc_tables+0x3f9/0x840 [amdgpu] [ 33.867835] smu_sw_init+0xa32/0x1850 [amdgpu] [ 33.868299] amdgpu_device_init+0x467b/0x8d90 [amdgpu] [ 33.868733] amdgpu_driver_load_kms+0x19/0xf0 [amdgpu] [ 33.869167] amdgpu_pci_probe+0x2d6/0xcd0 [amdgpu] [ 33.869608] local_pci_probe+0xda/0x180 [ 33.869614] pci_device_probe+0x43f/0x6b0 Empirically we can confirm that the former allocates 152 bytes for the table, while the latter memsets the 168 large block. Root cause appears that when GPU metrics tables for v2_4 parts were added it was not considered to enlarge the table to fit. The fix in this patch is rather \"brute force\" and perhaps later should be done in a smarter way, by extracting and consolidating the part version to size logic to a common helper, instead of brute forcing the largest possible allocation. Nevertheless, for now this works and fixes the out of bounds write. v2: * Drop impossible v3_0 case. (Mario) (cherry picked from commit 0880f58f9609f0200483a49429af0f050d281703)", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50222", "url": "https://ubuntu.com/security/CVE-2024-50222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iov_iter: fix copy_page_from_iter_atomic() if KMAP_LOCAL_FORCE_MAP generic/077 on x86_32 CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP=y with highmem, on huge=always tmpfs, issues a warning and then hangs (interruptibly): WARNING: CPU: 5 PID: 3517 at mm/highmem.c:622 kunmap_local_indexed+0x62/0xc9 CPU: 5 UID: 0 PID: 3517 Comm: cp Not tainted 6.12.0-rc4 #2 ... copy_page_from_iter_atomic+0xa6/0x5ec generic_perform_write+0xf6/0x1b4 shmem_file_write_iter+0x54/0x67 Fix copy_page_from_iter_atomic() by limiting it in that case (include/linux/skbuff.h skb_frag_must_loop() does similar). But going forward, perhaps CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP is too surprising, has outlived its usefulness, and should just be removed?", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50223", "url": "https://ubuntu.com/security/CVE-2024-50223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/numa: Fix the potential null pointer dereference in task_numa_work() When running stress-ng-vm-segv test, we found a null pointer dereference error in task_numa_work(). Here is the backtrace: [323676.066985] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ...... [323676.067108] CPU: 35 PID: 2694524 Comm: stress-ng-vm-se ...... [323676.067113] pstate: 23401009 (nzCv daif +PAN -UAO +TCO +DIT +SSBS BTYPE=--) [323676.067115] pc : vma_migratable+0x1c/0xd0 [323676.067122] lr : task_numa_work+0x1ec/0x4e0 [323676.067127] sp : ffff8000ada73d20 [323676.067128] x29: ffff8000ada73d20 x28: 0000000000000000 x27: 000000003e89f010 [323676.067130] x26: 0000000000080000 x25: ffff800081b5c0d8 x24: ffff800081b27000 [323676.067133] x23: 0000000000010000 x22: 0000000104d18cc0 x21: ffff0009f7158000 [323676.067135] x20: 0000000000000000 x19: 0000000000000000 x18: ffff8000ada73db8 [323676.067138] x17: 0001400000000000 x16: ffff800080df40b0 x15: 0000000000000035 [323676.067140] x14: ffff8000ada73cc8 x13: 1fffe0017cc72001 x12: ffff8000ada73cc8 [323676.067142] x11: ffff80008001160c x10: ffff000be639000c x9 : ffff8000800f4ba4 [323676.067145] x8 : ffff000810375000 x7 : ffff8000ada73974 x6 : 0000000000000001 [323676.067147] x5 : 0068000b33e26707 x4 : 0000000000000001 x3 : ffff0009f7158000 [323676.067149] x2 : 0000000000000041 x1 : 0000000000004400 x0 : 0000000000000000 [323676.067152] Call trace: [323676.067153] vma_migratable+0x1c/0xd0 [323676.067155] task_numa_work+0x1ec/0x4e0 [323676.067157] task_work_run+0x78/0xd8 [323676.067161] do_notify_resume+0x1ec/0x290 [323676.067163] el0_svc+0x150/0x160 [323676.067167] el0t_64_sync_handler+0xf8/0x128 [323676.067170] el0t_64_sync+0x17c/0x180 [323676.067173] Code: d2888001 910003fd f9000bf3 aa0003f3 (f9401000) [323676.067177] SMP: stopping secondary CPUs [323676.070184] Starting crashdump kernel... stress-ng-vm-segv in stress-ng is used to stress test the SIGSEGV error handling function of the system, which tries to cause a SIGSEGV error on return from unmapping the whole address space of the child process. Normally this program will not cause kernel crashes. But before the munmap system call returns to user mode, a potential task_numa_work() for numa balancing could be added and executed. In this scenario, since the child process has no vma after munmap, the vma_next() in task_numa_work() will return a null pointer even if the vma iterator restarts from 0. Recheck the vma pointer before dereferencing it in task_numa_work().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53053", "url": "https://ubuntu.com/security/CVE-2024-53053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Fix another deadlock during RTC update If ufshcd_rtc_work calls ufshcd_rpm_put_sync() and the pm's usage_count is 0, we will enter the runtime suspend callback. However, the runtime suspend callback will wait to flush ufshcd_rtc_work, causing a deadlock. Replace ufshcd_rpm_put_sync() with ufshcd_rpm_put() to avoid the deadlock.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53075", "url": "https://ubuntu.com/security/CVE-2024-53075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv: Prevent a bad reference count on CPU nodes When populating cache leaves we previously fetched the CPU device node at the very beginning. But when ACPI is enabled we go through a specific branch which returns early and does not call 'of_node_put' for the node that was acquired. Since we are not using a CPU device node for the ACPI code anyways, we can simply move the initialization of it just passed the ACPI block, and we are guaranteed to have an 'of_node_put' call for the acquired node. This prevents a bad reference count of the CPU device node. Moreover, the previous function did not check for errors when acquiring the device node, so a return -ENOENT has been added for that case.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50224", "url": "https://ubuntu.com/security/CVE-2024-50224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: spi-fsl-dspi: Fix crash when not using GPIO chip select Add check for the return value of spi_get_csgpiod() to avoid passing a NULL pointer to gpiod_direction_output(), preventing a crash when GPIO chip select is not used. Fix below crash: [ 4.251960] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 4.260762] Mem abort info: [ 4.263556] ESR = 0x0000000096000004 [ 4.267308] EC = 0x25: DABT (current EL), IL = 32 bits [ 4.272624] SET = 0, FnV = 0 [ 4.275681] EA = 0, S1PTW = 0 [ 4.278822] FSC = 0x04: level 0 translation fault [ 4.283704] Data abort info: [ 4.286583] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 4.292074] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 4.297130] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 4.302445] [0000000000000000] user address but active_mm is swapper [ 4.308805] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 4.315072] Modules linked in: [ 4.318124] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc4-next-20241023-00008-ga20ec42c5fc1 #359 [ 4.328130] Hardware name: LS1046A QDS Board (DT) [ 4.332832] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 4.339794] pc : gpiod_direction_output+0x34/0x5c [ 4.344505] lr : gpiod_direction_output+0x18/0x5c [ 4.349208] sp : ffff80008003b8f0 [ 4.352517] x29: ffff80008003b8f0 x28: 0000000000000000 x27: ffffc96bcc7e9068 [ 4.359659] x26: ffffc96bcc6e00b0 x25: ffffc96bcc598398 x24: ffff447400132810 [ 4.366800] x23: 0000000000000000 x22: 0000000011e1a300 x21: 0000000000020002 [ 4.373940] x20: 0000000000000000 x19: 0000000000000000 x18: ffffffffffffffff [ 4.381081] x17: ffff44740016e600 x16: 0000000500000003 x15: 0000000000000007 [ 4.388221] x14: 0000000000989680 x13: 0000000000020000 x12: 000000000000001e [ 4.395362] x11: 0044b82fa09b5a53 x10: 0000000000000019 x9 : 0000000000000008 [ 4.402502] x8 : 0000000000000002 x7 : 0000000000000007 x6 : 0000000000000000 [ 4.409641] x5 : 0000000000000200 x4 : 0000000002000000 x3 : 0000000000000000 [ 4.416781] x2 : 0000000000022202 x1 : 0000000000000000 x0 : 0000000000000000 [ 4.423921] Call trace: [ 4.426362] gpiod_direction_output+0x34/0x5c (P) [ 4.431067] gpiod_direction_output+0x18/0x5c (L) [ 4.435771] dspi_setup+0x220/0x334", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50225", "url": "https://ubuntu.com/security/CVE-2024-50225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix error propagation of split bios The purpose of btrfs_bbio_propagate_error() shall be propagating an error of split bio to its original btrfs_bio, and tell the error to the upper layer. However, it's not working well on some cases. * Case 1. Immediate (or quick) end_bio with an error When btrfs sends btrfs_bio to mirrored devices, btrfs calls btrfs_bio_end_io() when all the mirroring bios are completed. If that btrfs_bio was split, it is from btrfs_clone_bioset and its end_io function is btrfs_orig_write_end_io. For this case, btrfs_bbio_propagate_error() accesses the orig_bbio's bio context to increase the error count. That works well in most cases. However, if the end_io is called enough fast, orig_bbio's (remaining part after split) bio context may not be properly set at that time. Since the bio context is set when the orig_bbio (the last btrfs_bio) is sent to devices, that might be too late for earlier split btrfs_bio's completion. That will result in NULL pointer dereference. That bug is easily reproducible by running btrfs/146 on zoned devices [1] and it shows the following trace. [1] You need raid-stripe-tree feature as it create \"-d raid0 -m raid1\" FS. BUG: kernel NULL pointer dereference, address: 0000000000000020 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 UID: 0 PID: 13 Comm: kworker/u32:1 Not tainted 6.11.0-rc7-BTRFS-ZNS+ #474 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Workqueue: writeback wb_workfn (flush-btrfs-5) RIP: 0010:btrfs_bio_end_io+0xae/0xc0 [btrfs] BTRFS error (device dm-0): bdev /dev/mapper/error-test errs: wr 2, rd 0, flush 0, corrupt 0, gen 0 RSP: 0018:ffffc9000006f248 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888005a7f080 RCX: ffffc9000006f1dc RDX: 0000000000000000 RSI: 000000000000000a RDI: ffff888005a7f080 RBP: ffff888011dfc540 R08: 0000000000000000 R09: 0000000000000001 R10: ffffffff82e508e0 R11: 0000000000000005 R12: ffff88800ddfbe58 R13: ffff888005a7f080 R14: ffff888005a7f158 R15: ffff888005a7f158 FS: 0000000000000000(0000) GS:ffff88803ea80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000020 CR3: 0000000002e22006 CR4: 0000000000370ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __die_body.cold+0x19/0x26 ? page_fault_oops+0x13e/0x2b0 ? _printk+0x58/0x73 ? do_user_addr_fault+0x5f/0x750 ? exc_page_fault+0x76/0x240 ? asm_exc_page_fault+0x22/0x30 ? btrfs_bio_end_io+0xae/0xc0 [btrfs] ? btrfs_log_dev_io_error+0x7f/0x90 [btrfs] btrfs_orig_write_end_io+0x51/0x90 [btrfs] dm_submit_bio+0x5c2/0xa50 [dm_mod] ? find_held_lock+0x2b/0x80 ? blk_try_enter_queue+0x90/0x1e0 __submit_bio+0xe0/0x130 ? ktime_get+0x10a/0x160 ? lockdep_hardirqs_on+0x74/0x100 submit_bio_noacct_nocheck+0x199/0x410 btrfs_submit_bio+0x7d/0x150 [btrfs] btrfs_submit_chunk+0x1a1/0x6d0 [btrfs] ? lockdep_hardirqs_on+0x74/0x100 ? __folio_start_writeback+0x10/0x2c0 btrfs_submit_bbio+0x1c/0x40 [btrfs] submit_one_bio+0x44/0x60 [btrfs] submit_extent_folio+0x13f/0x330 [btrfs] ? btrfs_set_range_writeback+0xa3/0xd0 [btrfs] extent_writepage_io+0x18b/0x360 [btrfs] extent_write_locked_range+0x17c/0x340 [btrfs] ? __pfx_end_bbio_data_write+0x10/0x10 [btrfs] run_delalloc_cow+0x71/0xd0 [btrfs] btrfs_run_delalloc_range+0x176/0x500 [btrfs] ? find_lock_delalloc_range+0x119/0x260 [btrfs] writepage_delalloc+0x2ab/0x480 [btrfs] extent_write_cache_pages+0x236/0x7d0 [btrfs] btrfs_writepages+0x72/0x130 [btrfs] do_writepages+0xd4/0x240 ? find_held_lock+0x2b/0x80 ? wbc_attach_and_unlock_inode+0x12c/0x290 ? wbc_attach_and_unlock_inode+0x12c/0x29 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53054", "url": "https://ubuntu.com/security/CVE-2024-53054", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50226", "url": "https://ubuntu.com/security/CVE-2024-50226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cxl/port: Fix use-after-free, permit out-of-order decoder shutdown In support of investigating an initialization failure report [1], cxl_test was updated to register mock memory-devices after the mock root-port/bus device had been registered. That led to cxl_test crashing with a use-after-free bug with the following signature: cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem0:decoder7.0 @ 0 next: cxl_switch_uport.0 nr_eps: 1 nr_targets: 1 cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem4:decoder14.0 @ 1 next: cxl_switch_uport.0 nr_eps: 2 nr_targets: 1 cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[0] = cxl_switch_dport.0 for mem0:decoder7.0 @ 0 1) cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[1] = cxl_switch_dport.4 for mem4:decoder14.0 @ 1 [..] cxld_unregister: cxl decoder14.0: cxl_region_decode_reset: cxl_region region3: mock_decoder_reset: cxl_port port3: decoder3.0 reset 2) mock_decoder_reset: cxl_port port3: decoder3.0: out of order reset, expected decoder3.1 cxl_endpoint_decoder_release: cxl decoder14.0: [..] cxld_unregister: cxl decoder7.0: 3) cxl_region_decode_reset: cxl_region region3: Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6bc3: 0000 [#1] PREEMPT SMP PTI [..] RIP: 0010:to_cxl_port+0x8/0x60 [cxl_core] [..] Call Trace: cxl_region_decode_reset+0x69/0x190 [cxl_core] cxl_region_detach+0xe8/0x210 [cxl_core] cxl_decoder_kill_region+0x27/0x40 [cxl_core] cxld_unregister+0x5d/0x60 [cxl_core] At 1) a region has been established with 2 endpoint decoders (7.0 and 14.0). Those endpoints share a common switch-decoder in the topology (3.0). At teardown, 2), decoder14.0 is the first to be removed and hits the \"out of order reset case\" in the switch decoder. The effect though is that region3 cleanup is aborted leaving it in-tact and referencing decoder14.0. At 3) the second attempt to teardown region3 trips over the stale decoder14.0 object which has long since been deleted. The fix here is to recognize that the CXL specification places no mandate on in-order shutdown of switch-decoders, the driver enforces in-order allocation, and hardware enforces in-order commit. So, rather than fail and leave objects dangling, always remove them. In support of making cxl_region_decode_reset() always succeed, cxl_region_invalidate_memregion() failures are turned into warnings. Crashing the kernel is ok there since system integrity is at risk if caches cannot be managed around physical address mutation events like CXL region destruction. A new device_for_each_child_reverse_from() is added to cleanup port->commit_end after all dependent decoders have been disabled. In other words if decoders are allocated 0->1->2 and disabled 1->2->0 then port->commit_end only decrements from 2 after 2 has been disabled, and it decrements all the way to zero since 1 was disabled previously.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50227", "url": "https://ubuntu.com/security/CVE-2024-50227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Fix KASAN reported stack out-of-bounds read in tb_retimer_scan() KASAN reported following issue: BUG: KASAN: stack-out-of-bounds in tb_retimer_scan+0xffe/0x1550 [thunderbolt] Read of size 4 at addr ffff88810111fc1c by task kworker/u56:0/11 CPU: 0 UID: 0 PID: 11 Comm: kworker/u56:0 Tainted: G U 6.11.0+ #1387 Tainted: [U]=USER Workqueue: thunderbolt0 tb_handle_hotplug [thunderbolt] Call Trace: dump_stack_lvl+0x6c/0x90 print_report+0xd1/0x630 kasan_report+0xdb/0x110 __asan_report_load4_noabort+0x14/0x20 tb_retimer_scan+0xffe/0x1550 [thunderbolt] tb_scan_port+0xa6f/0x2060 [thunderbolt] tb_handle_hotplug+0x17b1/0x3080 [thunderbolt] process_one_work+0x626/0x1100 worker_thread+0x6c8/0xfa0 kthread+0x2c8/0x3a0 ret_from_fork+0x3a/0x80 ret_from_fork_asm+0x1a/0x30 This happens because the loop variable still gets incremented by one so max becomes 3 instead of 2, and this makes the second loop read past the the array declared on the stack. Fix this by assigning to max directly in the loop body.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50228", "url": "https://ubuntu.com/security/CVE-2024-50228", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50229", "url": "https://ubuntu.com/security/CVE-2024-50229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential deadlock with newly created symlinks Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers memory reclamation involving the filesystem layer, which can result in circular lock dependencies among the reader/writer semaphore nilfs->ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the fs_reclaim pseudo lock. This is because after commit 21fc61c73c39 (\"don't put symlink bodies in pagecache into highmem\"), the gfp flags of the page cache for symbolic links are overwritten to GFP_KERNEL via inode_nohighmem(). This is not a problem for symlinks read from the backing device, because the __GFP_FS flag is dropped after inode_nohighmem() is called. However, when a new symlink is created with nilfs_symlink(), the gfp flags remain overwritten to GFP_KERNEL. Then, memory allocation called from page_symlink() etc. triggers memory reclamation including the FS layer, which may call nilfs_evict_inode() or nilfs_dirty_inode(). And these can cause a deadlock if they are called while nilfs->ns_segctor_sem is held: Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags of newly created symlinks in the same way that nilfs_new_inode() and __nilfs_read_inode() do, as a workaround until we adopt nofs allocation scope consistently or improve the locking constraints.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50230", "url": "https://ubuntu.com/security/CVE-2024-50230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug due to missing clearing of checked flag Syzbot reported that in directory operations after nilfs2 detects filesystem corruption and degrades to read-only, __block_write_begin_int(), which is called to prepare block writes, may fail the BUG_ON check for accesses exceeding the folio/page size, triggering a kernel bug. This was found to be because the \"checked\" flag of a page/folio was not cleared when it was discarded by nilfs2's own routine, which causes the sanity check of directory entries to be skipped when the directory page/folio is reloaded. So, fix that. This was necessary when the use of nilfs2's own page discard routine was applied to more than just metadata files.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50231", "url": "https://ubuntu.com/security/CVE-2024-50231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gts-helper: Fix memory leaks in iio_gts_build_avail_scale_table() modprobe iio-test-gts and rmmod it, then the following memory leak occurs: \tunreferenced object 0xffffff80c810be00 (size 64): \t comm \"kunit_try_catch\", pid 1654, jiffies 4294913981 \t hex dump (first 32 bytes): \t 02 00 00 00 08 00 00 00 20 00 00 00 40 00 00 00 ........ ...@... \t 80 00 00 00 00 02 00 00 00 04 00 00 00 08 00 00 ................ \t backtrace (crc a63d875e): \t [<0000000028c1b3c2>] kmemleak_alloc+0x34/0x40 \t [<000000001d6ecc87>] __kmalloc_noprof+0x2bc/0x3c0 \t [<00000000393795c1>] devm_iio_init_iio_gts+0x4b4/0x16f4 \t [<0000000071bb4b09>] 0xffffffdf052a62e0 \t [<000000000315bc18>] 0xffffffdf052a6488 \t [<00000000f9dc55b5>] kunit_try_run_case+0x13c/0x3ac \t [<00000000175a3fd4>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000f505065d>] kthread+0x2e8/0x374 \t [<00000000bbfb0e5d>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cbfe9e70 (size 16): \t comm \"kunit_try_catch\", pid 1658, jiffies 4294914015 \t hex dump (first 16 bytes): \t 10 00 00 00 40 00 00 00 80 00 00 00 00 00 00 00 ....@........... \t backtrace (crc 857f0cb4): \t [<0000000028c1b3c2>] kmemleak_alloc+0x34/0x40 \t [<000000001d6ecc87>] __kmalloc_noprof+0x2bc/0x3c0 \t [<00000000393795c1>] devm_iio_init_iio_gts+0x4b4/0x16f4 \t [<0000000071bb4b09>] 0xffffffdf052a62e0 \t [<000000007d089d45>] 0xffffffdf052a6864 \t [<00000000f9dc55b5>] kunit_try_run_case+0x13c/0x3ac \t [<00000000175a3fd4>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000f505065d>] kthread+0x2e8/0x374 \t [<00000000bbfb0e5d>] ret_from_fork+0x10/0x20 \t...... It includes 5*5 times \"size 64\" memory leaks, which correspond to 5 times test_init_iio_gain_scale() calls with gts_test_gains size 10 (10*size(int)) and gts_test_itimes size 5. It also includes 5*1 times \"size 16\" memory leak, which correspond to one time __test_init_iio_gain_scale() call with gts_test_gains_gain_low size 3 (3*size(int)) and gts_test_itimes size 5. The reason is that the per_time_gains[i] is not freed which is allocated in the \"gts->num_itime\" for loop in iio_gts_build_avail_scale_table().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53076", "url": "https://ubuntu.com/security/CVE-2024-53076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gts-helper: Fix memory leaks for the error path of iio_gts_build_avail_scale_table() If per_time_scales[i] or per_time_gains[i] kcalloc fails in the for loop of iio_gts_build_avail_scale_table(), the err_free_out will fail to call kfree() each time when i is reduced to 0, so all the per_time_scales[0] and per_time_gains[0] will not be freed, which will cause memory leaks. Fix it by checking if i >= 0.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50232", "url": "https://ubuntu.com/security/CVE-2024-50232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr() In the ad7124_write_raw() function, parameter val can potentially be zero. This may lead to a division by zero when DIV_ROUND_CLOSEST() is called within ad7124_set_channel_odr(). The ad7124_write_raw() function is invoked through the sequence: iio_write_channel_raw() -> iio_write_channel_attribute() -> iio_channel_write(), with no checks in place to ensure val is non-zero.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50233", "url": "https://ubuntu.com/security/CVE-2024-50233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: iio: frequency: ad9832: fix division by zero in ad9832_calc_freqreg() In the ad9832_write_frequency() function, clk_get_rate() might return 0. This can lead to a division by zero when calling ad9832_calc_freqreg(). The check if (fout > (clk_get_rate(st->mclk) / 2)) does not protect against the case when fout is 0. The ad9832_write_frequency() function is called from ad9832_write(), and fout is derived from a text buffer, which can contain any value.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53055", "url": "https://ubuntu.com/security/CVE-2024-53055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix 6 GHz scan construction If more than 255 colocated APs exist for the set of all APs found during 2.4/5 GHz scanning, then the 6 GHz scan construction will loop forever since the loop variable has type u8, which can never reach the number found when that's bigger than 255, and is stored in a u32 variable. Also move it into the loops to have a smaller scope. Using a u32 there is fine, we limit the number of APs in the scan list and each has a limit on the number of RNR entries due to the frame size. With a limit of 1000 scan results, a frame size upper bound of 4096 (really it's more like ~2300) and a TBTT entry size of at least 11, we get an upper bound for the number of ~372k, well in the bounds of a u32.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50234", "url": "https://ubuntu.com/security/CVE-2024-50234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlegacy: Clear stale interrupts before resuming device iwl4965 fails upon resume from hibernation on my laptop. The reason seems to be a stale interrupt which isn't being cleared out before interrupts are enabled. We end up with a race beween the resume trying to bring things back up, and the restart work (queued form the interrupt handler) trying to bring things down. Eventually the whole thing blows up. Fix the problem by clearing out any stale interrupts before interrupts get enabled during resume. Here's a debug log of the indicent: [ 12.042589] ieee80211 phy0: il_isr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000 [ 12.042625] ieee80211 phy0: il4965_irq_tasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000 [ 12.042651] iwl4965 0000:10:00.0: RF_KILL bit toggled to enable radio. [ 12.042653] iwl4965 0000:10:00.0: On demand firmware reload [ 12.042690] ieee80211 phy0: il4965_irq_tasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282 [ 12.052207] ieee80211 phy0: il4965_mac_start enter [ 12.052212] ieee80211 phy0: il_prep_station Add STA to driver ID 31: ff:ff:ff:ff:ff:ff [ 12.052244] ieee80211 phy0: il4965_set_hw_ready hardware ready [ 12.052324] ieee80211 phy0: il_apm_init Init card's basic functions [ 12.052348] ieee80211 phy0: il_apm_init L1 Enabled; Disabling L0S [ 12.055727] ieee80211 phy0: il4965_load_bsm Begin load bsm [ 12.056140] ieee80211 phy0: il4965_verify_bsm Begin verify bsm [ 12.058642] ieee80211 phy0: il4965_verify_bsm BSM bootstrap uCode image OK [ 12.058721] ieee80211 phy0: il4965_load_bsm BSM write complete, poll 1 iterations [ 12.058734] ieee80211 phy0: __il4965_up iwl4965 is coming up [ 12.058737] ieee80211 phy0: il4965_mac_start Start UP work done. [ 12.058757] ieee80211 phy0: __il4965_down iwl4965 is going down [ 12.058761] ieee80211 phy0: il_scan_cancel_timeout Scan cancel timeout [ 12.058762] ieee80211 phy0: il_do_scan_abort Not performing scan to abort [ 12.058765] ieee80211 phy0: il_clear_ucode_stations Clearing ucode stations in driver [ 12.058767] ieee80211 phy0: il_clear_ucode_stations No active stations found to be cleared [ 12.058819] ieee80211 phy0: _il_apm_stop Stop card, put in low power state [ 12.058827] ieee80211 phy0: _il_apm_stop_master stop master [ 12.058864] ieee80211 phy0: il4965_clear_free_frames 0 frames on pre-allocated heap on clear. [ 12.058869] ieee80211 phy0: Hardware restart was requested [ 16.132299] iwl4965 0000:10:00.0: START_ALIVE timeout after 4000ms. [ 16.132303] ------------[ cut here ]------------ [ 16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue. [ 16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132390] Modules linked in: ctr ccm sch_fq_codel xt_tcpudp xt_multiport xt_state iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables binfmt_misc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdh_generic ecc iTCO_wdt i2c_dev iwl4965 iwlegacy coretemp snd_hda_codec_analog pcspkr psmouse mac80211 snd_hda_codec_generic libarc4 sdhci_pci cqhci sha256_generic sdhci libsha256 firewire_ohci snd_hda_intel snd_intel_dspcfg mmc_core snd_hda_codec snd_hwdep firewire_core led_class iosf_mbi snd_hda_core uhci_hcd lpc_ich crc_itu_t cfg80211 ehci_pci ehci_hcd snd_pcm usbcore mfd_core rfkill snd_timer snd usb_common soundcore video parport_pc parport intel_agp wmi intel_gtt backlight e1000e agpgart evdev [ 16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143 [ 16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010 [ 16.132463] Workqueue: async async_run_entry_fn [ 16.132469] RIP: 0010:ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132501] Code: da 02 00 0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50235", "url": "https://ubuntu.com/security/CVE-2024-50235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: clear wdev->cqm_config pointer on free When we free wdev->cqm_config when unregistering, we also need to clear out the pointer since the same wdev/netdev may get re-registered in another network namespace, then destroyed later, running this code again, which results in a double-free.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50236", "url": "https://ubuntu.com/security/CVE-2024-50236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: Fix memory leak in management tx In the current logic, memory is allocated for storing the MSDU context during management packet TX but this memory is not being freed during management TX completion. Similar leaks are seen in the management TX cleanup logic. Kmemleak reports this problem as below, unreferenced object 0xffffff80b64ed250 (size 16): comm \"kworker/u16:7\", pid 148, jiffies 4294687130 (age 714.199s) hex dump (first 16 bytes): 00 2b d8 d8 80 ff ff ff c4 74 e9 fd 07 00 00 00 .+.......t...... backtrace: [] __kmem_cache_alloc_node+0x1e4/0x2d8 [] kmalloc_trace+0x48/0x110 [] ath10k_wmi_tlv_op_gen_mgmt_tx_send+0xd4/0x1d8 [ath10k_core] [] ath10k_mgmt_over_wmi_tx_work+0x134/0x298 [ath10k_core] [] process_scheduled_works+0x1ac/0x400 [] worker_thread+0x208/0x328 [] kthread+0x100/0x1c0 [] ret_from_fork+0x10/0x20 Free the memory during completion and cleanup to fix the leak. Protect the mgmt_pending_tx idr_remove() operation in ath10k_wmi_tlv_op_cleanup_mgmt_tx_send() using ar->data_lock similar to other instances. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50237", "url": "https://ubuntu.com/security/CVE-2024-50237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower Avoid potentially crashing in the driver because of uninitialized private data", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50238", "url": "https://ubuntu.com/security/CVE-2024-50238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usbc: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data from the qcom-qmp-usb driver, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. This bug was later reproduced when the driver was copied to create the qmp-usbc driver. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with these drivers.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50239", "url": "https://ubuntu.com/security/CVE-2024-50239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usb-legacy: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data from the qcom-qmp-usb driver, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. This bug was later reproduced when the driver was copied to create the qmp-usb-legacy driver. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with these drivers.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50240", "url": "https://ubuntu.com/security/CVE-2024-50240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usb: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with this driver.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53077", "url": "https://ubuntu.com/security/CVE-2024-53077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpcrdma: Always release the rpcrdma_device's xa_array Dai pointed out that the xa_init_flags() in rpcrdma_add_one() needs to have a matching xa_destroy() in rpcrdma_remove_one() to release underlying memory that the xarray might have accrued during operation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50242", "url": "https://ubuntu.com/security/CVE-2024-50242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ntfs_file_release", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50243", "url": "https://ubuntu.com/security/CVE-2024-50243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix general protection fault in run_is_mapped_full Fixed deleating of a non-resident attribute in ntfs_create_inode() rollback.", "cve_priority": "low", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50244", "url": "https://ubuntu.com/security/CVE-2024-50244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ni_clear() Checking of NTFS_FLAGS_LOG_REPLAYING added to prevent access to uninitialized bitmap during replay process.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50245", "url": "https://ubuntu.com/security/CVE-2024-50245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix possible deadlock in mi_read Mutex lock with another subclass used in ni_lock_dir().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50246", "url": "https://ubuntu.com/security/CVE-2024-50246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Add rough attr alloc_size check", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50247", "url": "https://ubuntu.com/security/CVE-2024-50247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Check if more than chunk-size bytes are written A incorrectly formatted chunk may decompress into more than LZNT_CHUNK_SIZE bytes and a index out of bounds will occur in s_max_off.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50248", "url": "https://ubuntu.com/security/CVE-2024-50248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Add bounds checking to mi_enum_attr() Added bounds checking to make sure that every attr don't stray beyond valid memory region.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53078", "url": "https://ubuntu.com/security/CVE-2024-53078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Fix NULL vs IS_ERR() check in probe() The iommu_paging_domain_alloc() function doesn't return NULL pointers, it returns error pointers. Update the check to match.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53056", "url": "https://ubuntu.com/security/CVE-2024-53056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Fix potential NULL dereference in mtk_crtc_destroy() In mtk_crtc_create(), if the call to mbox_request_channel() fails then we set the \"mtk_crtc->cmdq_client.chan\" pointer to NULL. In that situation, we do not call cmdq_pkt_create(). During the cleanup, we need to check if the \"mtk_crtc->cmdq_client.chan\" is NULL first before calling cmdq_pkt_destroy(). Calling cmdq_pkt_destroy() is unnecessary if we didn't call cmdq_pkt_create() and it will result in a NULL pointer dereference.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50249", "url": "https://ubuntu.com/security/CVE-2024-50249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Make rmw_lock a raw_spin_lock The following BUG was triggered: ============================= [ BUG: Invalid wait context ] 6.12.0-rc2-XXX #406 Not tainted ----------------------------- kworker/1:1/62 is trying to lock: ffffff8801593030 (&cpc_ptr->rmw_lock){+.+.}-{3:3}, at: cpc_write+0xcc/0x370 other info that might help us debug this: context-{5:5} 2 locks held by kworker/1:1/62: #0: ffffff897ef5ec98 (&rq->__lock){-.-.}-{2:2}, at: raw_spin_rq_lock_nested+0x2c/0x50 #1: ffffff880154e238 (&sg_policy->update_lock){....}-{2:2}, at: sugov_update_shared+0x3c/0x280 stack backtrace: CPU: 1 UID: 0 PID: 62 Comm: kworker/1:1 Not tainted 6.12.0-rc2-g9654bd3e8806 #406 Workqueue: 0x0 (events) Call trace: dump_backtrace+0xa4/0x130 show_stack+0x20/0x38 dump_stack_lvl+0x90/0xd0 dump_stack+0x18/0x28 __lock_acquire+0x480/0x1ad8 lock_acquire+0x114/0x310 _raw_spin_lock+0x50/0x70 cpc_write+0xcc/0x370 cppc_set_perf+0xa0/0x3a8 cppc_cpufreq_fast_switch+0x40/0xc0 cpufreq_driver_fast_switch+0x4c/0x218 sugov_update_shared+0x234/0x280 update_load_avg+0x6ec/0x7b8 dequeue_entities+0x108/0x830 dequeue_task_fair+0x58/0x408 __schedule+0x4f0/0x1070 schedule+0x54/0x130 worker_thread+0xc0/0x2e8 kthread+0x130/0x148 ret_from_fork+0x10/0x20 sugov_update_shared() locks a raw_spinlock while cpc_write() locks a spinlock. To have a correct wait-type order, update rmw_lock to a raw spinlock and ensure that interrupts will be disabled on the CPU holding it. [ rjw: Changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50250", "url": "https://ubuntu.com/security/CVE-2024-50250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fsdax: dax_unshare_iter needs to copy entire blocks The code that copies data from srcmap to iomap in dax_unshare_iter is very very broken, which bfoster's recent fsx changes have exposed. If the pos and len passed to dax_file_unshare are not aligned to an fsblock boundary, the iter pos and length in the _iter function will reflect this unalignment. dax_iomap_direct_access always returns a pointer to the start of the kmapped fsdax page, even if its pos argument is in the middle of that page. This is catastrophic for data integrity when iter->pos is not aligned to a page, because daddr/saddr do not point to the same byte in the file as iter->pos. Hence we corrupt user data by copying it to the wrong place. If iter->pos + iomap_length() in the _iter function not aligned to a page, then we fail to copy a full block, and only partially populate the destination block. This is catastrophic for data confidentiality because we expose stale pmem contents. Fix both of these issues by aligning copy_pos/copy_len to a page boundary (remember, this is fsdax so 1 fsblock == 1 base page) so that we always copy full blocks. We're not done yet -- there's no call to invalidate_inode_pages2_range, so programs that have the file range mmap'd will continue accessing the old memory mapping after the file metadata updates have completed. Be careful with the return value -- if the unshare succeeds, we still need to return the number of bytes that the iomap iter thinks we're operating on.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50251", "url": "https://ubuntu.com/security/CVE-2024-50251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_payload: sanitize offset and length before calling skb_checksum() If access to offset + length is larger than the skbuff length, then skb_checksum() triggers BUG_ON(). skb_checksum() internally subtracts the length parameter while iterating over skbuff, BUG_ON(len) at the end of it checks that the expected length to be included in the checksum calculation is fully consumed.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50252", "url": "https://ubuntu.com/security/CVE-2024-50252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_ipip: Fix memory leak when changing remote IPv6 address The device stores IPv6 addresses that are used for encapsulation in linear memory that is managed by the driver. Changing the remote address of an ip6gre net device never worked properly, but since cited commit the following reproducer [1] would result in a warning [2] and a memory leak [3]. The problem is that the new remote address is never added by the driver to its hash table (and therefore the device) and the old address is never removed from it. Fix by programming the new address when the configuration of the ip6gre net device changes and removing the old one. If the address did not change, then the above would result in increasing the reference count of the address and then decreasing it. [1] # ip link add name bla up type ip6gre local 2001:db8:1::1 remote 2001:db8:2::1 tos inherit ttl inherit # ip link set dev bla type ip6gre remote 2001:db8:3::1 # ip link del dev bla # devlink dev reload pci/0000:01:00.0 [2] WARNING: CPU: 0 PID: 1682 at drivers/net/ethernet/mellanox/mlxsw/spectrum.c:3002 mlxsw_sp_ipv6_addr_put+0x140/0x1d0 Modules linked in: CPU: 0 UID: 0 PID: 1682 Comm: ip Not tainted 6.12.0-rc3-custom-g86b5b55bc835 #151 Hardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023 RIP: 0010:mlxsw_sp_ipv6_addr_put+0x140/0x1d0 [...] Call Trace: mlxsw_sp_router_netdevice_event+0x55f/0x1240 notifier_call_chain+0x5a/0xd0 call_netdevice_notifiers_info+0x39/0x90 unregister_netdevice_many_notify+0x63e/0x9d0 rtnl_dellink+0x16b/0x3a0 rtnetlink_rcv_msg+0x142/0x3f0 netlink_rcv_skb+0x50/0x100 netlink_unicast+0x242/0x390 netlink_sendmsg+0x1de/0x420 ____sys_sendmsg+0x2bd/0x320 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xd0 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f [3] unreferenced object 0xffff898081f597a0 (size 32): comm \"ip\", pid 1626, jiffies 4294719324 hex dump (first 32 bytes): 20 01 0d b8 00 02 00 00 00 00 00 00 00 00 00 01 ............... 21 49 61 83 80 89 ff ff 00 00 00 00 01 00 00 00 !Ia............. backtrace (crc fd9be911): [<00000000df89c55d>] __kmalloc_cache_noprof+0x1da/0x260 [<00000000ff2a1ddb>] mlxsw_sp_ipv6_addr_kvdl_index_get+0x281/0x340 [<000000009ddd445d>] mlxsw_sp_router_netdevice_event+0x47b/0x1240 [<00000000743e7757>] notifier_call_chain+0x5a/0xd0 [<000000007c7b9e13>] call_netdevice_notifiers_info+0x39/0x90 [<000000002509645d>] register_netdevice+0x5f7/0x7a0 [<00000000c2e7d2a9>] ip6gre_newlink_common.isra.0+0x65/0x130 [<0000000087cd6d8d>] ip6gre_newlink+0x72/0x120 [<000000004df7c7cc>] rtnl_newlink+0x471/0xa20 [<0000000057ed632a>] rtnetlink_rcv_msg+0x142/0x3f0 [<0000000032e0d5b5>] netlink_rcv_skb+0x50/0x100 [<00000000908bca63>] netlink_unicast+0x242/0x390 [<00000000cdbe1c87>] netlink_sendmsg+0x1de/0x420 [<0000000011db153e>] ____sys_sendmsg+0x2bd/0x320 [<000000003b6d53eb>] ___sys_sendmsg+0x9a/0xe0 [<00000000cae27c62>] __sys_sendmsg+0x7a/0xd0", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50253", "url": "https://ubuntu.com/security/CVE-2024-50253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check the validity of nr_words in bpf_iter_bits_new() Check the validity of nr_words in bpf_iter_bits_new(). Without this check, when multiplication overflow occurs for nr_bits (e.g., when nr_words = 0x0400-0001, nr_bits becomes 64), stack corruption may occur due to bpf_probe_read_kernel_common(..., nr_bytes = 0x2000-0008). Fix it by limiting the maximum value of nr_words to 511. The value is derived from the current implementation of BPF memory allocator. To ensure compatibility if the BPF memory allocator's size limitation changes in the future, use the helper bpf_mem_alloc_check_size() to check whether nr_bytes is too larger. And return -E2BIG instead of -ENOMEM for oversized nr_bytes.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50254", "url": "https://ubuntu.com/security/CVE-2024-50254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free dynamically allocated bits in bpf_iter_bits_destroy() bpf_iter_bits_destroy() uses \"kit->nr_bits <= 64\" to check whether the bits are dynamically allocated. However, the check is incorrect and may cause a kmemleak as shown below: unreferenced object 0xffff88812628c8c0 (size 32): comm \"swapper/0\", pid 1, jiffies 4294727320 hex dump (first 32 bytes): \tb0 c1 55 f5 81 88 ff ff f0 f0 f0 f0 f0 f0 f0 f0 ..U........... \tf0 f0 f0 f0 f0 f0 f0 f0 00 00 00 00 00 00 00 00 .............. backtrace (crc 781e32cc): \t[<00000000c452b4ab>] kmemleak_alloc+0x4b/0x80 \t[<0000000004e09f80>] __kmalloc_node_noprof+0x480/0x5c0 \t[<00000000597124d6>] __alloc.isra.0+0x89/0xb0 \t[<000000004ebfffcd>] alloc_bulk+0x2af/0x720 \t[<00000000d9c10145>] prefill_mem_cache+0x7f/0xb0 \t[<00000000ff9738ff>] bpf_mem_alloc_init+0x3e2/0x610 \t[<000000008b616eac>] bpf_global_ma_init+0x19/0x30 \t[<00000000fc473efc>] do_one_initcall+0xd3/0x3c0 \t[<00000000ec81498c>] kernel_init_freeable+0x66a/0x940 \t[<00000000b119f72f>] kernel_init+0x20/0x160 \t[<00000000f11ac9a7>] ret_from_fork+0x3c/0x70 \t[<0000000004671da4>] ret_from_fork_asm+0x1a/0x30 That is because nr_bits will be set as zero in bpf_iter_bits_next() after all bits have been iterated. Fix the issue by setting kit->bit to kit->nr_bits instead of setting kit->nr_bits to zero when the iteration completes in bpf_iter_bits_next(). In addition, use \"!nr_bits || bits >= nr_bits\" to check whether the iteration is complete and still use \"nr_bits > 64\" to indicate whether bits are dynamically allocated. The \"!nr_bits\" check is necessary because bpf_iter_bits_new() may fail before setting kit->nr_bits, and this condition will stop the iteration early instead of accessing the zeroed or freed kit->bits. Considering the initial value of kit->bits is -1 and the type of kit->nr_bits is unsigned int, change the type of kit->nr_bits to int. The potential overflow problem will be handled in the following patch.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50255", "url": "https://ubuntu.com/security/CVE-2024-50255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci: fix null-ptr-deref in hci_read_supported_codecs Fix __hci_cmd_sync_sk() to return not NULL for unknown opcodes. __hci_cmd_sync_sk() returns NULL if a command returns a status event. However, it also returns NULL where an opcode doesn't exist in the hci_cc table because hci_cmd_complete_evt() assumes status = skb->data[0] for unknown opcodes. This leads to null-ptr-deref in cmd_sync for HCI_OP_READ_LOCAL_CODECS as there is no hci_cc for HCI_OP_READ_LOCAL_CODECS, which always assumes status = skb->data[0]. KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077] CPU: 1 PID: 2000 Comm: kworker/u9:5 Not tainted 6.9.0-ga6bcb805883c-dirty #10 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: hci7 hci_power_on RIP: 0010:hci_read_supported_codecs+0xb9/0x870 net/bluetooth/hci_codec.c:138 Code: 08 48 89 ef e8 b8 c1 8f fd 48 8b 75 00 e9 96 00 00 00 49 89 c6 48 ba 00 00 00 00 00 fc ff df 4c 8d 60 70 4c 89 e3 48 c1 eb 03 <0f> b6 04 13 84 c0 0f 85 82 06 00 00 41 83 3c 24 02 77 0a e8 bf 78 RSP: 0018:ffff888120bafac8 EFLAGS: 00010212 RAX: 0000000000000000 RBX: 000000000000000e RCX: ffff8881173f0040 RDX: dffffc0000000000 RSI: ffffffffa58496c0 RDI: ffff88810b9ad1e4 RBP: ffff88810b9ac000 R08: ffffffffa77882a7 R09: 1ffffffff4ef1054 R10: dffffc0000000000 R11: fffffbfff4ef1055 R12: 0000000000000070 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88810b9ac000 FS: 0000000000000000(0000) GS:ffff8881f6c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6ddaa3439e CR3: 0000000139764003 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: hci_read_local_codecs_sync net/bluetooth/hci_sync.c:4546 [inline] hci_init_stage_sync net/bluetooth/hci_sync.c:3441 [inline] hci_init4_sync net/bluetooth/hci_sync.c:4706 [inline] hci_init_sync net/bluetooth/hci_sync.c:4742 [inline] hci_dev_init_sync net/bluetooth/hci_sync.c:4912 [inline] hci_dev_open_sync+0x19a9/0x2d30 net/bluetooth/hci_sync.c:4994 hci_dev_do_open net/bluetooth/hci_core.c:483 [inline] hci_power_on+0x11e/0x560 net/bluetooth/hci_core.c:1015 process_one_work kernel/workqueue.c:3267 [inline] process_scheduled_works+0x8ef/0x14f0 kernel/workqueue.c:3348 worker_thread+0x91f/0xe50 kernel/workqueue.c:3429 kthread+0x2cb/0x360 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50256", "url": "https://ubuntu.com/security/CVE-2024-50256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6() I got a syzbot report without a repro [1] crashing in nf_send_reset6() I think the issue is that dev->hard_header_len is zero, and we attempt later to push an Ethernet header. Use LL_MAX_HEADER, as other functions in net/ipv6/netfilter/nf_reject_ipv6.c. [1] skbuff: skb_under_panic: text:ffffffff89b1d008 len:74 put:14 head:ffff88803123aa00 data:ffff88803123a9f2 tail:0x3c end:0x140 dev:syz_tun kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 UID: 0 PID: 7373 Comm: syz.1.568 Not tainted 6.12.0-rc2-syzkaller-00631-g6d858708d465 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:skb_panic net/core/skbuff.c:206 [inline] RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216 Code: 0d 8d 48 c7 c6 60 a6 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 ba 30 38 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP: 0018:ffffc900045269b0 EFLAGS: 00010282 RAX: 0000000000000088 RBX: dffffc0000000000 RCX: cd66dacdc5d8e800 RDX: 0000000000000000 RSI: 0000000000000200 RDI: 0000000000000000 RBP: ffff88802d39a3d0 R08: ffffffff8174afec R09: 1ffff920008a4ccc R10: dffffc0000000000 R11: fffff520008a4ccd R12: 0000000000000140 R13: ffff88803123aa00 R14: ffff88803123a9f2 R15: 000000000000003c FS: 00007fdbee5ff6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000005d322000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: skb_push+0xe5/0x100 net/core/skbuff.c:2636 eth_header+0x38/0x1f0 net/ethernet/eth.c:83 dev_hard_header include/linux/netdevice.h:3208 [inline] nf_send_reset6+0xce6/0x1270 net/ipv6/netfilter/nf_reject_ipv6.c:358 nft_reject_inet_eval+0x3b9/0x690 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x418/0x6b0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] br_nf_pre_routing_ipv6+0x63e/0x770 net/bridge/br_netfilter_ipv6.c:184 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_bridge_pre net/bridge/br_input.c:277 [inline] br_handle_frame+0x9fd/0x1530 net/bridge/br_input.c:424 __netif_receive_skb_core+0x13e8/0x4570 net/core/dev.c:5562 __netif_receive_skb_one_core net/core/dev.c:5666 [inline] __netif_receive_skb+0x12f/0x650 net/core/dev.c:5781 netif_receive_skb_internal net/core/dev.c:5867 [inline] netif_receive_skb+0x1e8/0x890 net/core/dev.c:5926 tun_rx_batched+0x1b7/0x8f0 drivers/net/tun.c:1550 tun_get_user+0x3056/0x47e0 drivers/net/tun.c:2007 tun_chr_write_iter+0x10d/0x1f0 drivers/net/tun.c:2053 new_sync_write fs/read_write.c:590 [inline] vfs_write+0xa6d/0xc90 fs/read_write.c:683 ksys_write+0x183/0x2b0 fs/read_write.c:736 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:0x7fdbeeb7d1ff Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 c9 8d 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 1c 8e 02 00 48 RSP: 002b:00007fdbee5ff000 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fdbeed36058 RCX: 00007fdbeeb7d1ff RDX: 000000000000008e RSI: 0000000020000040 RDI: 00000000000000c8 RBP: 00007fdbeebf12be R08: 0000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50257", "url": "https://ubuntu.com/security/CVE-2024-50257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: Fix use-after-free in get_info() ip6table_nat module unload has refcnt warning for UAF. call trace is: WARNING: CPU: 1 PID: 379 at kernel/module/main.c:853 module_put+0x6f/0x80 Modules linked in: ip6table_nat(-) CPU: 1 UID: 0 PID: 379 Comm: ip6tables Not tainted 6.12.0-rc4-00047-gc2ee9f594da8-dirty #205 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:module_put+0x6f/0x80 Call Trace: get_info+0x128/0x180 do_ip6t_get_ctl+0x6a/0x430 nf_getsockopt+0x46/0x80 ipv6_getsockopt+0xb9/0x100 rawv6_getsockopt+0x42/0x190 do_sock_getsockopt+0xaa/0x180 __sys_getsockopt+0x70/0xc0 __x64_sys_getsockopt+0x20/0x30 do_syscall_64+0xa2/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Concurrent execution of module unload and get_info() trigered the warning. The root cause is as follows: cpu0\t\t\t\t cpu1 module_exit //mod->state = MODULE_STATE_GOING ip6table_nat_exit xt_unregister_template \tkfree(t) \t//removed from templ_list \t\t\t\t getinfo() \t\t\t\t\t t = xt_find_table_lock \t\t\t\t\t\tlist_for_each_entry(tmpl, &xt_templates[af]...) \t\t\t\t\t\t\tif (strcmp(tmpl->name, name)) \t\t\t\t\t\t\t\tcontinue; //table not found \t\t\t\t\t\t\ttry_module_get \t\t\t\t\t\tlist_for_each_entry(t, &xt_net->tables[af]...) \t\t\t\t\t\t\treturn t; //not get refcnt \t\t\t\t\t module_put(t->me) //uaf unregister_pernet_subsys //remove table from xt_net list While xt_table module was going away and has been removed from xt_templates list, we couldnt get refcnt of xt_table->me. Check module in xt_net->tables list re-traversal to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50258", "url": "https://ubuntu.com/security/CVE-2024-50258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix crash when config small gso_max_size/gso_ipv4_max_size Config a small gso_max_size/gso_ipv4_max_size will lead to an underflow in sk_dst_gso_max_size(), which may trigger a BUG_ON crash, because sk->sk_gso_max_size would be much bigger than device limits. Call Trace: tcp_write_xmit tso_segs = tcp_init_tso_segs(skb, mss_now); tcp_set_skb_tso_segs tcp_skb_pcount_set // skb->len = 524288, mss_now = 8 // u16 tso_segs = 524288/8 = 65535 -> 0 tso_segs = DIV_ROUND_UP(skb->len, mss_now) BUG_ON(!tso_segs) Add check for the minimum value of gso_max_size and gso_ipv4_max_size.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50262", "url": "https://ubuntu.com/security/CVE-2024-50262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix out-of-bounds write in trie_get_next_key() trie_get_next_key() allocates a node stack with size trie->max_prefixlen, while it writes (trie->max_prefixlen + 1) nodes to the stack when it has full paths from the root to leaves. For example, consider a trie with max_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ... 0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with .prefixlen = 8 make 9 nodes be written on the node stack with size 8.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53044", "url": "https://ubuntu.com/security/CVE-2024-53044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_api: fix xa_insert() error path in tcf_block_get_ext() This command: $ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact Error: block dev insert failed: -EBUSY. fails because user space requests the same block index to be set for both ingress and egress. [ side note, I don't think it even failed prior to commit 913b47d3424e (\"net/sched: Introduce tc block netdev tracking infra\"), because this is a command from an old set of notes of mine which used to work, but alas, I did not scientifically bisect this ] The problem is not that it fails, but rather, that the second time around, it fails differently (and irrecoverably): $ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact Error: dsa_core: Flow block cb is busy. [ another note: the extack is added by me for illustration purposes. the context of the problem is that clsact_init() obtains the same &q->ingress_block pointer as &q->egress_block, and since we call tcf_block_get_ext() on both of them, \"dev\" will be added to the block->ports xarray twice, thus failing the operation: once through the ingress block pointer, and once again through the egress block pointer. the problem itself is that when xa_insert() fails, we have emitted a FLOW_BLOCK_BIND command through ndo_setup_tc(), but the offload never sees a corresponding FLOW_BLOCK_UNBIND. ] Even correcting the bad user input, we still cannot recover: $ tc qdisc replace dev swp3 ingress_block 1 egress_block 2 clsact Error: dsa_core: Flow block cb is busy. Basically the only way to recover is to reboot the system, or unbind and rebind the net device driver. To fix the bug, we need to fill the correct error teardown path which was missed during code movement, and call tcf_block_offload_unbind() when xa_insert() fails. [ last note, fundamentally I blame the label naming convention in tcf_block_get_ext() for the bug. The labels should be named after what they do, not after the error path that jumps to them. This way, it is obviously wrong that two labels pointing to the same code mean something is wrong, and checking the code correctness at the goto site is also easier ]", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50259", "url": "https://ubuntu.com/security/CVE-2024-50259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netdevsim: Add trailing zero to terminate the string in nsim_nexthop_bucket_activity_write() This was found by a static analyzer. We should not forget the trailing zero after copy_from_user() if we will further do some string operations, sscanf() in this case. Adding a trailing zero will ensure that the function performs properly.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50304", "url": "https://ubuntu.com/security/CVE-2024-50304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find() The per-netns IP tunnel hash table is protected by the RTNL mutex and ip_tunnel_find() is only called from the control path where the mutex is taken. Add a lockdep expression to hlist_for_each_entry_rcu() in ip_tunnel_find() in order to validate that the mutex is held and to silence the suspicious RCU usage warning [1]. [1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gd95d9a31aceb #139 Not tainted ----------------------------- net/ipv4/ip_tunnel.c:221 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/362: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60 stack backtrace: CPU: 12 UID: 0 PID: 362 Comm: ip Not tainted 6.12.0-rc3-custom-gd95d9a31aceb #139 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 ip_tunnel_find+0x435/0x4d0 ip_tunnel_newlink+0x517/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53042", "url": "https://ubuntu.com/security/CVE-2024-53042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_init_flow() There are code paths from which the function is called without holding the RCU read lock, resulting in a suspicious RCU usage warning [1]. Fix by using l3mdev_master_upper_ifindex_by_index() which will acquire the RCU read lock before calling l3mdev_master_upper_ifindex_by_index_rcu(). [1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gac8f72681cf2 #141 Not tainted ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/361: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60 stack backtrace: CPU: 3 UID: 0 PID: 361 Comm: ip Not tainted 6.12.0-rc3-custom-gac8f72681cf2 #141 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 dev_get_by_index_rcu+0x1d3/0x210 l3mdev_master_upper_ifindex_by_index_rcu+0x2b/0xf0 ip_tunnel_bind_dev+0x72f/0xa00 ip_tunnel_newlink+0x368/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53048", "url": "https://ubuntu.com/security/CVE-2024-53048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix crash on probe for DPLL enabled E810 LOM The E810 Lan On Motherboard (LOM) design is vendor specific. Intel provides the reference design, but it is up to vendor on the final product design. For some cases, like Linux DPLL support, the static values defined in the driver does not reflect the actual LOM design. Current implementation of dpll pins is causing the crash on probe of the ice driver for such DPLL enabled E810 LOM designs: WARNING: (...) at drivers/dpll/dpll_core.c:495 dpll_pin_get+0x2c4/0x330 ... Call Trace: ? __warn+0x83/0x130 ? dpll_pin_get+0x2c4/0x330 ? report_bug+0x1b7/0x1d0 ? handle_bug+0x42/0x70 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? dpll_pin_get+0x117/0x330 ? dpll_pin_get+0x2c4/0x330 ? dpll_pin_get+0x117/0x330 ice_dpll_get_pins.isra.0+0x52/0xe0 [ice] ... The number of dpll pins enabled by LOM vendor is greater than expected and defined in the driver for Intel designed NICs, which causes the crash. Prevent the crash and allow generic pin initialization within Linux DPLL subsystem for DPLL enabled E810 LOM designs. Newly designed solution for described issue will be based on \"per HW design\" pin initialization. It requires pin information dynamically acquired from the firmware and is already in progress, planned for next-tree only.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53058", "url": "https://ubuntu.com/security/CVE-2024-53058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data In case the non-paged data of a SKB carries protocol header and protocol payload to be transmitted on a certain platform that the DMA AXI address width is configured to 40-bit/48-bit, or the size of the non-paged data is bigger than TSO_MAX_BUFF_SIZE on a certain platform that the DMA AXI address width is configured to 32-bit, then this SKB requires at least two DMA transmit descriptors to serve it. For example, three descriptors are allocated to split one DMA buffer mapped from one piece of non-paged data: dma_desc[N + 0], dma_desc[N + 1], dma_desc[N + 2]. Then three elements of tx_q->tx_skbuff_dma[] will be allocated to hold extra information to be reused in stmmac_tx_clean(): tx_q->tx_skbuff_dma[N + 0], tx_q->tx_skbuff_dma[N + 1], tx_q->tx_skbuff_dma[N + 2]. Now we focus on tx_q->tx_skbuff_dma[entry].buf, which is the DMA buffer address returned by DMA mapping call. stmmac_tx_clean() will try to unmap the DMA buffer _ONLY_IF_ tx_q->tx_skbuff_dma[entry].buf is a valid buffer address. The expected behavior that saves DMA buffer address of this non-paged data to tx_q->tx_skbuff_dma[entry].buf is: tx_q->tx_skbuff_dma[N + 0].buf = NULL; tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = dma_map_single(); Unfortunately, the current code misbehaves like this: tx_q->tx_skbuff_dma[N + 0].buf = dma_map_single(); tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = NULL; On the stmmac_tx_clean() side, when dma_desc[N + 0] is closed by the DMA engine, tx_q->tx_skbuff_dma[N + 0].buf is a valid buffer address obviously, then the DMA buffer will be unmapped immediately. There may be a rare case that the DMA engine does not finish the pending dma_desc[N + 1], dma_desc[N + 2] yet. Now things will go horribly wrong, DMA is going to access a unmapped/unreferenced memory region, corrupted data will be transmited or iommu fault will be triggered :( In contrast, the for-loop that maps SKB fragments behaves perfectly as expected, and that is how the driver should do for both non-paged data and paged frags actually. This patch corrects DMA map/unmap sequences by fixing the array index for tx_q->tx_skbuff_dma[entry].buf when assigning DMA buffer address. Tested and verified on DWXGMAC CORE 3.20a", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50260", "url": "https://ubuntu.com/security/CVE-2024-50260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sock_map: fix a NULL pointer dereference in sock_map_link_update_prog() The following race condition could trigger a NULL pointer dereference: sock_map_link_detach():\t\tsock_map_link_update_prog(): mutex_lock(&sockmap_mutex); ... sockmap_link->map = NULL; mutex_unlock(&sockmap_mutex); \t\t\t\t mutex_lock(&sockmap_mutex); \t\t\t\t ... \t\t\t\t sock_map_prog_link_lookup(sockmap_link->map); \t\t\t\t mutex_unlock(&sockmap_mutex); Fix it by adding a NULL pointer check. In this specific case, it makes no sense to update a link which is being released.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53045", "url": "https://ubuntu.com/security/CVE-2024-53045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: dapm: fix bounds checker error in dapm_widget_list_create The widgets array in the snd_soc_dapm_widget_list has a __counted_by attribute attached to it, which points to the num_widgets variable. This attribute is used in bounds checking, and if it is not set before the array is filled, then the bounds sanitizer will issue a warning or a kernel panic if CONFIG_UBSAN_TRAP is set. This patch sets the size of the widgets list calculated with list_for_each as the initial value for num_widgets as it is used for allocating memory for the array. It is updated with the actual number of added elements after the array is filled.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50261", "url": "https://ubuntu.com/security/CVE-2024-50261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macsec: Fix use-after-free while sending the offloading packet KASAN reports the following UAF. The metadata_dst, which is used to store the SCI value for macsec offload, is already freed by metadata_dst_free() in macsec_free_netdev(), while driver still use it for sending the packet. To fix this issue, dst_release() is used instead to release metadata_dst. So it is not freed instantly in macsec_free_netdev() if still referenced by skb. BUG: KASAN: slab-use-after-free in mlx5e_xmit+0x1e8f/0x4190 [mlx5_core] Read of size 2 at addr ffff88813e42e038 by task kworker/7:2/714 [...] Workqueue: mld mld_ifc_work Call Trace: dump_stack_lvl+0x51/0x60 print_report+0xc1/0x600 kasan_report+0xab/0xe0 mlx5e_xmit+0x1e8f/0x4190 [mlx5_core] dev_hard_start_xmit+0x120/0x530 sch_direct_xmit+0x149/0x11e0 __qdisc_run+0x3ad/0x1730 __dev_queue_xmit+0x1196/0x2ed0 vlan_dev_hard_start_xmit+0x32e/0x510 [8021q] dev_hard_start_xmit+0x120/0x530 __dev_queue_xmit+0x14a7/0x2ed0 macsec_start_xmit+0x13e9/0x2340 dev_hard_start_xmit+0x120/0x530 __dev_queue_xmit+0x14a7/0x2ed0 ip6_finish_output2+0x923/0x1a70 ip6_finish_output+0x2d7/0x970 ip6_output+0x1ce/0x3a0 NF_HOOK.constprop.0+0x15f/0x190 mld_sendpack+0x59a/0xbd0 mld_ifc_work+0x48a/0xa80 process_one_work+0x5aa/0xe50 worker_thread+0x79c/0x1290 kthread+0x28f/0x350 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x11/0x20 Allocated by task 3922: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 __kasan_kmalloc+0x77/0x90 __kmalloc_noprof+0x188/0x400 metadata_dst_alloc+0x1f/0x4e0 macsec_newlink+0x914/0x1410 __rtnl_newlink+0xe08/0x15b0 rtnl_newlink+0x5f/0x90 rtnetlink_rcv_msg+0x667/0xa80 netlink_rcv_skb+0x12c/0x360 netlink_unicast+0x551/0x770 netlink_sendmsg+0x72d/0xbd0 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x52e/0x6a0 ___sys_sendmsg+0xeb/0x170 __sys_sendmsg+0xb5/0x140 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Freed by task 4011: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x50 poison_slab_object+0x10c/0x190 __kasan_slab_free+0x11/0x30 kfree+0xe0/0x290 macsec_free_netdev+0x3f/0x140 netdev_run_todo+0x450/0xc70 rtnetlink_rcv_msg+0x66f/0xa80 netlink_rcv_skb+0x12c/0x360 netlink_unicast+0x551/0x770 netlink_sendmsg+0x72d/0xbd0 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x52e/0x6a0 ___sys_sendmsg+0xeb/0x170 __sys_sendmsg+0xb5/0x140 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53059", "url": "https://ubuntu.com/security/CVE-2024-53059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd() 1. The size of the response packet is not validated. 2. The response buffer is not freed. Resolve these issues by switching to iwl_mvm_send_cmd_status(), which handles both size validation and frees the buffer.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53074", "url": "https://ubuntu.com/security/CVE-2024-53074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: don't leak a link on AP removal Release the link mapping resource in AP removal. This impacted devices that do not support the MLD API (9260 and down). On those devices, we couldn't start the AP again after the AP has been already started and stopped.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53049", "url": "https://ubuntu.com/security/CVE-2024-53049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slub/kunit: fix a WARNING due to unwrapped __kmalloc_cache_noprof 'modprobe slub_kunit' will have a warning as shown below. The root cause is that __kmalloc_cache_noprof was directly used, which resulted in no alloc_tag being allocated. This caused current->alloc_tag to be null, leading to a warning in alloc_tag_add_check. Let's add an alloc_hook layer to __kmalloc_cache_noprof specifically within lib/slub_kunit.c, which is the only user of this internal slub function outside kmalloc implementation itself. [58162.947016] WARNING: CPU: 2 PID: 6210 at ./include/linux/alloc_tag.h:125 alloc_tagging_slab_alloc_hook+0x268/0x27c [58162.957721] Call trace: [58162.957919] alloc_tagging_slab_alloc_hook+0x268/0x27c [58162.958286] __kmalloc_cache_noprof+0x14c/0x344 [58162.958615] test_kmalloc_redzone_access+0x50/0x10c [slub_kunit] [58162.959045] kunit_try_run_case+0x74/0x184 [kunit] [58162.959401] kunit_generic_run_threadfn_adapter+0x2c/0x4c [kunit] [58162.959841] kthread+0x10c/0x118 [58162.960093] ret_from_fork+0x10/0x20 [58162.960363] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50192", "url": "https://ubuntu.com/security/CVE-2024-50192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v4: Don't allow a VMOVP on a dying VPE Kunkun Jiang reported that there is a small window of opportunity for userspace to force a change of affinity for a VPE while the VPE has already been unmapped, but the corresponding doorbell interrupt still visible in /proc/irq/. Plug the race by checking the value of vmapp_count, which tracks whether the VPE is mapped ot not, and returning an error in this case. This involves making vmapp_count common to both GICv4.1 and its v4.0 ancestor.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50069", "url": "https://ubuntu.com/security/CVE-2024-50069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: apple: check devm_kasprintf() returned value devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked. Fix this lack and check the returned value. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50070", "url": "https://ubuntu.com/security/CVE-2024-50070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: stm32: check devm_kasprintf() returned value devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked. Fix this lack and check the returned value. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50196", "url": "https://ubuntu.com/security/CVE-2024-50196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: ocelot: fix system hang on level based interrupts The current implementation only calls chained_irq_enter() and chained_irq_exit() if it detects pending interrupts. ``` for (i = 0; i < info->stride; i++) { \turegmap_read(info->map, id_reg + 4 * i, ®); \tif (!reg) \t\tcontinue; \tchained_irq_enter(parent_chip, desc); ``` However, in case of GPIO pin configured in level mode and the parent controller configured in edge mode, GPIO interrupt might be lowered by the hardware. In the result, if the interrupt is short enough, the parent interrupt is still pending while the GPIO interrupt is cleared; chained_irq_enter() never gets called and the system hangs trying to service the parent interrupt. Moving chained_irq_enter() and chained_irq_exit() outside the for loop ensures that they are called even when GPIO interrupt is lowered by the hardware. The similar code with chained_irq_enter() / chained_irq_exit() functions wrapping interrupt checking loop may be found in many other drivers: ``` grep -r -A 10 chained_irq_enter drivers/pinctrl ```", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50197", "url": "https://ubuntu.com/security/CVE-2024-50197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: intel: platform: fix error path in device_for_each_child_node() The device_for_each_child_node() loop requires calls to fwnode_handle_put() upon early returns to decrement the refcount of the child node and avoid leaking memory if that error path is triggered. There is one early returns within that loop in intel_platform_pinctrl_prepare_community(), but fwnode_handle_put() is missing. Instead of adding the missing call, the scoped version of the loop can be used to simplify the code and avoid mistakes in the future if new early returns are added, as the child node is only used for parsing, and it is never assigned.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50071", "url": "https://ubuntu.com/security/CVE-2024-50071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: nuvoton: fix a double free in ma35_pinctrl_dt_node_to_map_func() 'new_map' is allocated using devm_* which takes care of freeing the allocated data on device removal, call to \t.dt_free_map = pinconf_generic_dt_free_map double frees the map as pinconf_generic_dt_free_map() calls pinctrl_utils_free_map(). Fix this by using kcalloc() instead of auto-managed devm_kcalloc().", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50072", "url": "https://ubuntu.com/security/CVE-2024-50072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/bugs: Use code segment selector for VERW operand Robert Gill reported below #GP in 32-bit mode when dosemu software was executing vm86() system call: general protection fault: 0000 [#1] PREEMPT SMP CPU: 4 PID: 4610 Comm: dosemu.bin Not tainted 6.6.21-gentoo-x86 #1 Hardware name: Dell Inc. PowerEdge 1950/0H723K, BIOS 2.7.0 10/30/2010 EIP: restore_all_switch_stack+0xbe/0xcf EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000 ESI: 00000000 EDI: 00000000 EBP: 00000000 ESP: ff8affdc DS: 0000 ES: 0000 FS: 0000 GS: 0033 SS: 0068 EFLAGS: 00010046 CR0: 80050033 CR2: 00c2101c CR3: 04b6d000 CR4: 000406d0 Call Trace: show_regs+0x70/0x78 die_addr+0x29/0x70 exc_general_protection+0x13c/0x348 exc_bounds+0x98/0x98 handle_exception+0x14d/0x14d exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf This only happens in 32-bit mode when VERW based mitigations like MDS/RFDS are enabled. This is because segment registers with an arbitrary user value can result in #GP when executing VERW. Intel SDM vol. 2C documents the following behavior for VERW instruction: #GP(0) - If a memory operand effective address is outside the CS, DS, ES, \t FS, or GS segment limit. CLEAR_CPU_BUFFERS macro executes VERW instruction before returning to user space. Use %cs selector to reference VERW operand. This ensures VERW will not #GP for an arbitrary user %ds. [ mingo: Fixed the SOB chain. ]", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50073", "url": "https://ubuntu.com/security/CVE-2024-50073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: Fix use-after-free in gsm_cleanup_mux BUG: KASAN: slab-use-after-free in gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] Read of size 8 at addr ffff88815fe99c00 by task poc/3379 CPU: 0 UID: 0 PID: 3379 Comm: poc Not tainted 6.11.0+ #56 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] __pfx_gsm_cleanup_mux+0x10/0x10 drivers/tty/n_gsm.c:3124 [n_gsm] __pfx_sched_clock_cpu+0x10/0x10 kernel/sched/clock.c:389 update_load_avg+0x1c1/0x27b0 kernel/sched/fair.c:4500 __pfx_min_vruntime_cb_rotate+0x10/0x10 kernel/sched/fair.c:846 __rb_insert_augmented+0x492/0xbf0 lib/rbtree.c:161 gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] _raw_spin_lock_irqsave+0x92/0xf0 arch/x86/include/asm/atomic.h:107 __pfx_gsmld_ioctl+0x10/0x10 drivers/tty/n_gsm.c:3822 [n_gsm] ktime_get+0x5e/0x140 kernel/time/timekeeping.c:195 ldsem_down_read+0x94/0x4e0 arch/x86/include/asm/atomic64_64.h:79 __pfx_ldsem_down_read+0x10/0x10 drivers/tty/tty_ldsem.c:338 __pfx_do_vfs_ioctl+0x10/0x10 fs/ioctl.c:805 tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 Allocated by task 65: gsm_data_alloc.constprop.0+0x27/0x190 drivers/tty/n_gsm.c:926 [n_gsm] gsm_send+0x2c/0x580 drivers/tty/n_gsm.c:819 [n_gsm] gsm1_receive+0x547/0xad0 drivers/tty/n_gsm.c:3038 [n_gsm] gsmld_receive_buf+0x176/0x280 drivers/tty/n_gsm.c:3609 [n_gsm] tty_ldisc_receive_buf+0x101/0x1e0 drivers/tty/tty_buffer.c:391 tty_port_default_receive_buf+0x61/0xa0 drivers/tty/tty_port.c:39 flush_to_ldisc+0x1b0/0x750 drivers/tty/tty_buffer.c:445 process_scheduled_works+0x2b0/0x10d0 kernel/workqueue.c:3229 worker_thread+0x3dc/0x950 kernel/workqueue.c:3391 kthread+0x2a3/0x370 kernel/kthread.c:389 ret_from_fork+0x2d/0x70 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:257 Freed by task 3367: kfree+0x126/0x420 mm/slub.c:4580 gsm_cleanup_mux+0x36c/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 [Analysis] gsm_msg on the tx_ctrl_list or tx_data_list of gsm_mux can be freed by multi threads through ioctl,which leads to the occurrence of uaf. Protect it by gsm tx lock.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50193", "url": "https://ubuntu.com/security/CVE-2024-50193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/entry_32: Clear CPU buffers after register restore in NMI return CPU buffers are currently cleared after call to exc_nmi, but before register state is restored. This may be okay for MDS mitigation but not for RDFS. Because RDFS mitigation requires CPU buffers to be cleared when registers don't have any sensitive data. Move CLEAR_CPU_BUFFERS after RESTORE_ALL_NMI.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50074", "url": "https://ubuntu.com/security/CVE-2024-50074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: parport: Proper fix for array out-of-bounds access The recent fix for array out-of-bounds accesses replaced sprintf() calls blindly with snprintf(). However, since snprintf() returns the would-be-printed size, not the actually output size, the length calculation can still go over the given limit. Use scnprintf() instead of snprintf(), which returns the actually output letters, for addressing the potential out-of-bounds access properly.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50100", "url": "https://ubuntu.com/security/CVE-2024-50100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: gadget: dummy-hcd: Fix \"task hung\" problem The syzbot fuzzer has been encountering \"task hung\" problems ever since the dummy-hcd driver was changed to use hrtimers instead of regular timers. It turns out that the problems are caused by a subtle difference between the timer_pending() and hrtimer_active() APIs. The changeover blindly replaced the first by the second. However, timer_pending() returns True when the timer is queued but not when its callback is running, whereas hrtimer_active() returns True when the hrtimer is queued _or_ its callback is running. This difference occasionally caused dummy_urb_enqueue() to think that the callback routine had not yet started when in fact it was almost finished. As a result the hrtimer was not restarted, which made it impossible for the driver to dequeue later the URB that was just enqueued. This caused usb_kill_urb() to hang, and things got worse from there. Since hrtimers have no API for telling when they are queued and the callback isn't running, the driver must keep track of this for itself. That's what this patch does, adding a new \"timer_pending\" flag and setting or clearing it at the appropriate times.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50075", "url": "https://ubuntu.com/security/CVE-2024-50075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xhci: tegra: fix checked USB2 port number If USB virtualizatoin is enabled, USB2 ports are shared between all Virtual Functions. The USB2 port number owned by an USB2 root hub in a Virtual Function may be less than total USB2 phy number supported by the Tegra XUSB controller. Using total USB2 phy number as port number to check all PORTSC values would cause invalid memory access. [ 116.923438] Unable to handle kernel paging request at virtual address 006c622f7665642f ... [ 117.213640] Call trace: [ 117.216783] tegra_xusb_enter_elpg+0x23c/0x658 [ 117.222021] tegra_xusb_runtime_suspend+0x40/0x68 [ 117.227260] pm_generic_runtime_suspend+0x30/0x50 [ 117.232847] __rpm_callback+0x84/0x3c0 [ 117.237038] rpm_suspend+0x2dc/0x740 [ 117.241229] pm_runtime_work+0xa0/0xb8 [ 117.245769] process_scheduled_works+0x24c/0x478 [ 117.251007] worker_thread+0x23c/0x328 [ 117.255547] kthread+0x104/0x1b0 [ 117.259389] ret_from_fork+0x10/0x20 [ 117.263582] Code: 54000222 f9461ae8 f8747908 b4ffff48 (f9400100)", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50076", "url": "https://ubuntu.com/security/CVE-2024-50076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vt: prevent kernel-infoleak in con_font_get() font.data may not initialize all memory spaces depending on the implementation of vc->vc_sw->con_font_get. This may cause info-leak, so to prevent this, it is safest to modify it to initialize the allocated memory space to 0, and it generally does not affect the overall performance of the system.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50077", "url": "https://ubuntu.com/security/CVE-2024-50077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix multiple init when debugfs is disabled If bt_debugfs is not created successfully, which happens if either CONFIG_DEBUG_FS or CONFIG_DEBUG_FS_ALLOW_ALL is unset, then iso_init() returns early and does not set iso_inited to true. This means that a subsequent call to iso_init() will result in duplicate calls to proto_register(), bt_sock_register(), etc. With CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, the duplicate call to proto_register() triggers this BUG(): list_add double add: new=ffffffffc0b280d0, prev=ffffffffbab56250, next=ffffffffc0b280d0. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:35! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 2 PID: 887 Comm: bluetoothd Not tainted 6.10.11-1-ao-desktop #1 RIP: 0010:__list_add_valid_or_report+0x9a/0xa0 ... __list_add_valid_or_report+0x9a/0xa0 proto_register+0x2b5/0x340 iso_init+0x23/0x150 [bluetooth] set_iso_socket_func+0x68/0x1b0 [bluetooth] kmem_cache_free+0x308/0x330 hci_sock_sendmsg+0x990/0x9e0 [bluetooth] __sock_sendmsg+0x7b/0x80 sock_write_iter+0x9a/0x110 do_iter_readv_writev+0x11d/0x220 vfs_writev+0x180/0x3e0 do_writev+0xca/0x100 ... This change removes the early return. The check for iso_debugfs being NULL was unnecessary, it is always NULL when iso_inited is false.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50078", "url": "https://ubuntu.com/security/CVE-2024-50078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Call iso_exit() on module unload If iso_init() has been called, iso_exit() must be called on module unload. Without that, the struct proto that iso_init() registered with proto_register() becomes invalid, which could cause unpredictable problems later. In my case, with CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, loading the module again usually triggers this BUG(): list_add corruption. next->prev should be prev (ffffffffb5355fd0), but was 0000000000000068. (next=ffffffffc0a010d0). ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:29! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 4159 Comm: modprobe Not tainted 6.10.11-4+bt2-ao-desktop #1 RIP: 0010:__list_add_valid_or_report+0x61/0xa0 ... __list_add_valid_or_report+0x61/0xa0 proto_register+0x299/0x320 hci_sock_init+0x16/0xc0 [bluetooth] bt_init+0x68/0xd0 [bluetooth] __pfx_bt_init+0x10/0x10 [bluetooth] do_one_initcall+0x80/0x2f0 do_init_module+0x8b/0x230 __do_sys_init_module+0x15f/0x190 do_syscall_64+0x68/0x110 ...", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50198", "url": "https://ubuntu.com/security/CVE-2024-50198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: veml6030: fix IIO device retrieval from embedded device The dev pointer that is received as an argument in the in_illuminance_period_available_show function references the device embedded in the IIO device, not in the i2c client. dev_to_iio_dev() must be used to accessthe right data. The current implementation leads to a segmentation fault on every attempt to read the attribute because indio_dev gets a NULL assignment. This bug has been present since the first appearance of the driver, apparently since the last version (V6) before getting applied. A constant attribute was used until then, and the last modifications might have not been tested again.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50201", "url": "https://ubuntu.com/security/CVE-2024-50201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: Fix encoder->possible_clones Include the encoder itself in its possible_clones bitmask. In the past nothing validated that drivers were populating possible_clones correctly, but that changed in commit 74d2aacbe840 (\"drm: Validate encoder->possible_clones\"). Looks like radeon never got the memo and is still not following the rules 100% correctly. This results in some warnings during driver initialization: Bogus possible_clones: [ENCODER:46:TV-46] possible_clones=0x4 (full encoder mask=0x7) WARNING: CPU: 0 PID: 170 at drivers/gpu/drm/drm_mode_config.c:615 drm_mode_config_validate+0x113/0x39c ... (cherry picked from commit 3b6e7d40649c0d75572039aff9d0911864c689db)", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50098", "url": "https://ubuntu.com/security/CVE-2024-50098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Set SDEV_OFFLINE when UFS is shut down There is a history of deadlock if reboot is performed at the beginning of booting. SDEV_QUIESCE was set for all LU's scsi_devices by UFS shutdown, and at that time the audio driver was waiting on blk_mq_submit_bio() holding a mutex_lock while reading the fw binary. After that, a deadlock issue occurred while audio driver shutdown was waiting for mutex_unlock of blk_mq_submit_bio(). To solve this, set SDEV_OFFLINE for all LUs except WLUN, so that any I/O that comes down after a UFS shutdown will return an error. [ 31.907781]I[0: swapper/0: 0] 1 130705007 1651079834 11289729804 0 D( 2) 3 ffffff882e208000 * init [device_shutdown] [ 31.907793]I[0: swapper/0: 0] Mutex: 0xffffff8849a2b8b0: owner[0xffffff882e28cb00 kworker/6:0 :49] [ 31.907806]I[0: swapper/0: 0] Call trace: [ 31.907810]I[0: swapper/0: 0] __switch_to+0x174/0x338 [ 31.907819]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc [ 31.907826]I[0: swapper/0: 0] schedule+0x7c/0xe8 [ 31.907834]I[0: swapper/0: 0] schedule_preempt_disabled+0x24/0x40 [ 31.907842]I[0: swapper/0: 0] __mutex_lock+0x408/0xdac [ 31.907849]I[0: swapper/0: 0] __mutex_lock_slowpath+0x14/0x24 [ 31.907858]I[0: swapper/0: 0] mutex_lock+0x40/0xec [ 31.907866]I[0: swapper/0: 0] device_shutdown+0x108/0x280 [ 31.907875]I[0: swapper/0: 0] kernel_restart+0x4c/0x11c [ 31.907883]I[0: swapper/0: 0] __arm64_sys_reboot+0x15c/0x280 [ 31.907890]I[0: swapper/0: 0] invoke_syscall+0x70/0x158 [ 31.907899]I[0: swapper/0: 0] el0_svc_common+0xb4/0xf4 [ 31.907909]I[0: swapper/0: 0] do_el0_svc+0x2c/0xb0 [ 31.907918]I[0: swapper/0: 0] el0_svc+0x34/0xe0 [ 31.907928]I[0: swapper/0: 0] el0t_64_sync_handler+0x68/0xb4 [ 31.907937]I[0: swapper/0: 0] el0t_64_sync+0x1a0/0x1a4 [ 31.908774]I[0: swapper/0: 0] 49 0 11960702 11236868007 0 D( 2) 6 ffffff882e28cb00 * kworker/6:0 [__bio_queue_enter] [ 31.908783]I[0: swapper/0: 0] Call trace: [ 31.908788]I[0: swapper/0: 0] __switch_to+0x174/0x338 [ 31.908796]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc [ 31.908803]I[0: swapper/0: 0] schedule+0x7c/0xe8 [ 31.908811]I[0: swapper/0: 0] __bio_queue_enter+0xb8/0x178 [ 31.908818]I[0: swapper/0: 0] blk_mq_submit_bio+0x194/0x67c [ 31.908827]I[0: swapper/0: 0] __submit_bio+0xb8/0x19c", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50079", "url": "https://ubuntu.com/security/CVE-2024-50079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/sqpoll: ensure task state is TASK_RUNNING when running task_work When the sqpoll is exiting and cancels pending work items, it may need to run task_work. If this happens from within io_uring_cancel_generic(), then it may be under waiting for the io_uring_task waitqueue. This results in the below splat from the scheduler, as the ring mutex may be attempted grabbed while in a TASK_INTERRUPTIBLE state. Ensure that the task state is set appropriately for that, just like what is done for the other cases in io_run_task_work(). do not call blocking ops when !TASK_RUNNING; state=1 set at [<0000000029387fd2>] prepare_to_wait+0x88/0x2fc WARNING: CPU: 6 PID: 59939 at kernel/sched/core.c:8561 __might_sleep+0xf4/0x140 Modules linked in: CPU: 6 UID: 0 PID: 59939 Comm: iou-sqp-59938 Not tainted 6.12.0-rc3-00113-g8d020023b155 #7456 Hardware name: linux,dummy-virt (DT) pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : __might_sleep+0xf4/0x140 lr : __might_sleep+0xf4/0x140 sp : ffff80008c5e7830 x29: ffff80008c5e7830 x28: ffff0000d93088c0 x27: ffff60001c2d7230 x26: dfff800000000000 x25: ffff0000e16b9180 x24: ffff80008c5e7a50 x23: 1ffff000118bcf4a x22: ffff0000e16b9180 x21: ffff0000e16b9180 x20: 000000000000011b x19: ffff80008310fac0 x18: 1ffff000118bcd90 x17: 30303c5b20746120 x16: 74657320313d6574 x15: 0720072007200720 x14: 0720072007200720 x13: 0720072007200720 x12: ffff600036c64f0b x11: 1fffe00036c64f0a x10: ffff600036c64f0a x9 : dfff800000000000 x8 : 00009fffc939b0f6 x7 : ffff0001b6327853 x6 : 0000000000000001 x5 : ffff0001b6327850 x4 : ffff600036c64f0b x3 : ffff8000803c35bc x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000e16b9180 Call trace: __might_sleep+0xf4/0x140 mutex_lock+0x84/0x124 io_handle_tw_list+0xf4/0x260 tctx_task_work_run+0x94/0x340 io_run_task_work+0x1ec/0x3c0 io_uring_cancel_generic+0x364/0x524 io_sq_thread+0x820/0x124c ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50080", "url": "https://ubuntu.com/security/CVE-2024-50080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: don't allow user copy for unprivileged device UBLK_F_USER_COPY requires userspace to call write() on ublk char device for filling request buffer, and unprivileged device can't be trusted. So don't allow user copy for unprivileged device.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50081", "url": "https://ubuntu.com/security/CVE-2024-50081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-mq: setup queue ->tag_set before initializing hctx Commit 7b815817aa58 (\"blk-mq: add helper for checking if one CPU is mapped to specified hctx\") needs to check queue mapping via tag set in hctx's cpuhp handler. However, q->tag_set may not be setup yet when the cpuhp handler is enabled, then kernel oops is triggered. Fix the issue by setup queue tag_set before initializing hctx.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50082", "url": "https://ubuntu.com/security/CVE-2024-50082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race We're seeing crashes from rq_qos_wake_function that look like this: BUG: unable to handle page fault for address: ffffafe180a40084 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 100000067 P4D 100000067 PUD 10027c067 PMD 10115d067 PTE 0 Oops: Oops: 0002 [#1] PREEMPT SMP PTI CPU: 17 UID: 0 PID: 0 Comm: swapper/17 Not tainted 6.12.0-rc3-00013-geca631b8fe80 #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:_raw_spin_lock_irqsave+0x1d/0x40 Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 9c 41 5c fa 65 ff 05 62 97 30 4c 31 c0 ba 01 00 00 00 0f b1 17 75 0a 4c 89 e0 41 5c c3 cc cc cc cc 89 c6 e8 2c 0b 00 RSP: 0018:ffffafe180580ca0 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffffafe180a3f7a8 RCX: 0000000000000011 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffffafe180a40084 RBP: 0000000000000000 R08: 00000000001e7240 R09: 0000000000000011 R10: 0000000000000028 R11: 0000000000000888 R12: 0000000000000002 R13: ffffafe180a40084 R14: 0000000000000000 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff9aaf1f280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffafe180a40084 CR3: 000000010e428002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: try_to_wake_up+0x5a/0x6a0 rq_qos_wake_function+0x71/0x80 __wake_up_common+0x75/0xa0 __wake_up+0x36/0x60 scale_up.part.0+0x50/0x110 wb_timer_fn+0x227/0x450 ... So rq_qos_wake_function() calls wake_up_process(data->task), which calls try_to_wake_up(), which faults in raw_spin_lock_irqsave(&p->pi_lock). p comes from data->task, and data comes from the waitqueue entry, which is stored on the waiter's stack in rq_qos_wait(). Analyzing the core dump with drgn, I found that the waiter had already woken up and moved on to a completely unrelated code path, clobbering what was previously data->task. Meanwhile, the waker was passing the clobbered garbage in data->task to wake_up_process(), leading to the crash. What's happening is that in between rq_qos_wake_function() deleting the waitqueue entry and calling wake_up_process(), rq_qos_wait() is finding that it already got a token and returning. The race looks like this: rq_qos_wait() rq_qos_wake_function() ============================================================== prepare_to_wait_exclusive() data->got_token = true; list_del_init(&curr->entry); if (data.got_token) break; finish_wait(&rqw->wait, &data.wq); ^- returns immediately because list_empty_careful(&wq_entry->entry) is true ... return, go do something else ... wake_up_process(data->task) (NO LONGER VALID!)-^ Normally, finish_wait() is supposed to synchronize against the waker. But, as noted above, it is returning immediately because the waitqueue entry has already been removed from the waitqueue. The bug is that rq_qos_wake_function() is accessing the waitqueue entry AFTER deleting it. Note that autoremove_wake_function() wakes the waiter and THEN deletes the waitqueue entry, which is the proper order. Fix it by swapping the order. We also need to use list_del_init_careful() to match the list_empty_careful() in finish_wait().", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50101", "url": "https://ubuntu.com/security/CVE-2024-50101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI devices Previously, the domain_context_clear() function incorrectly called pci_for_each_dma_alias() to set up context entries for non-PCI devices. This could lead to kernel hangs or other unexpected behavior. Add a check to only call pci_for_each_dma_alias() for PCI devices. For non-PCI devices, domain_context_clear_one() is called directly.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50083", "url": "https://ubuntu.com/security/CVE-2024-50083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix mptcp DSS corruption due to large pmtu xmit Syzkaller was able to trigger a DSS corruption: TCP: request_sock_subflow_v4: Possible SYN flooding on port [::]:20002. Sending cookies. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 5227 at net/mptcp/protocol.c:695 __mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695 Modules linked in: CPU: 0 UID: 0 PID: 5227 Comm: syz-executor350 Not tainted 6.11.0-syzkaller-08829-gaf9c191ac2a0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:__mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695 Code: 0f b6 dc 31 ff 89 de e8 b5 dd ea f5 89 d8 48 81 c4 50 01 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 98 da ea f5 90 <0f> 0b 90 e9 47 ff ff ff e8 8a da ea f5 90 0f 0b 90 e9 99 e0 ff ff RSP: 0018:ffffc90000006db8 EFLAGS: 00010246 RAX: ffffffff8ba9df18 RBX: 00000000000055f0 RCX: ffff888030023c00 RDX: 0000000000000100 RSI: 00000000000081e5 RDI: 00000000000055f0 RBP: 1ffff110062bf1ae R08: ffffffff8ba9cf12 R09: 1ffff110062bf1b8 R10: dffffc0000000000 R11: ffffed10062bf1b9 R12: 0000000000000000 R13: dffffc0000000000 R14: 00000000700cec61 R15: 00000000000081e5 FS: 000055556679c380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020287000 CR3: 0000000077892000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: move_skbs_to_msk net/mptcp/protocol.c:811 [inline] mptcp_data_ready+0x29c/0xa90 net/mptcp/protocol.c:854 subflow_data_ready+0x34a/0x920 net/mptcp/subflow.c:1490 tcp_data_queue+0x20fd/0x76c0 net/ipv4/tcp_input.c:5283 tcp_rcv_established+0xfba/0x2020 net/ipv4/tcp_input.c:6237 tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915 tcp_v4_rcv+0x2dc0/0x37f0 net/ipv4/tcp_ipv4.c:2350 ip_protocol_deliver_rcu+0x22e/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x341/0x5f0 net/ipv4/ip_input.c:233 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314 __netif_receive_skb_one_core net/core/dev.c:5662 [inline] __netif_receive_skb+0x2bf/0x650 net/core/dev.c:5775 process_backlog+0x662/0x15b0 net/core/dev.c:6107 __napi_poll+0xcb/0x490 net/core/dev.c:6771 napi_poll net/core/dev.c:6840 [inline] net_rx_action+0x89b/0x1240 net/core/dev.c:6962 handle_softirqs+0x2c5/0x980 kernel/softirq.c:554 do_softirq+0x11b/0x1e0 kernel/softirq.c:455 __local_bh_enable_ip+0x1bb/0x200 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0x1764/0x3e80 net/core/dev.c:4451 dev_queue_xmit include/linux/netdevice.h:3094 [inline] neigh_hh_output include/net/neighbour.h:526 [inline] neigh_output include/net/neighbour.h:540 [inline] ip_finish_output2+0xd41/0x1390 net/ipv4/ip_output.c:236 ip_local_out net/ipv4/ip_output.c:130 [inline] __ip_queue_xmit+0x118c/0x1b80 net/ipv4/ip_output.c:536 __tcp_transmit_skb+0x2544/0x3b30 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_mtu_probe net/ipv4/tcp_output.c:2547 [inline] tcp_write_xmit+0x641d/0x6bf0 net/ipv4/tcp_output.c:2752 __tcp_push_pending_frames+0x9b/0x360 net/ipv4/tcp_output.c:3015 tcp_push_pending_frames include/net/tcp.h:2107 [inline] tcp_data_snd_check net/ipv4/tcp_input.c:5714 [inline] tcp_rcv_established+0x1026/0x2020 net/ipv4/tcp_input.c:6239 tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915 sk_backlog_rcv include/net/sock.h:1113 [inline] __release_sock+0x214/0x350 net/core/sock.c:3072 release_sock+0x61/0x1f0 net/core/sock.c:3626 mptcp_push_ ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50068", "url": "https://ubuntu.com/security/CVE-2024-50068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/tests/sysfs-kunit.h: fix memory leak in damon_sysfs_test_add_targets() The sysfs_target->regions allocated in damon_sysfs_regions_alloc() is not freed in damon_sysfs_test_add_targets(), which cause the following memory leak, free it to fix it. \tunreferenced object 0xffffff80c2a8db80 (size 96): \t comm \"kunit_try_catch\", pid 187, jiffies 4294894363 \t hex dump (first 32 bytes): \t 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ \t 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ \t backtrace (crc 0): \t [<0000000001e3714d>] kmemleak_alloc+0x34/0x40 \t [<000000008e6835c1>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000001286d9f8>] damon_sysfs_test_add_targets+0x1cc/0x738 \t [<0000000032ef8f77>] kunit_try_run_case+0x13c/0x3ac \t [<00000000f3edea23>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000adf936cf>] kthread+0x2e8/0x374 \t [<0000000041bb1628>] ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50199", "url": "https://ubuntu.com/security/CVE-2024-50199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/swapfile: skip HugeTLB pages for unuse_vma I got a bad pud error and lost a 1GB HugeTLB when calling swapoff. The problem can be reproduced by the following steps: 1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory. 2. Swapout the above anonymous memory. 3. run swapoff and we will get a bad pud error in kernel message: mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7) We can tell that pud_clear_bad is called by pud_none_or_clear_bad in unuse_pud_range() by ftrace. And therefore the HugeTLB pages will never be freed because we lost it from page table. We can skip HugeTLB pages for unuse_vma to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50066", "url": "https://ubuntu.com/security/CVE-2024-50066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mremap: fix move_normal_pmd/retract_page_tables race In mremap(), move_page_tables() looks at the type of the PMD entry and the specified address range to figure out by which method the next chunk of page table entries should be moved. At that point, the mmap_lock is held in write mode, but no rmap locks are held yet. For PMD entries that point to page tables and are fully covered by the source address range, move_pgt_entry(NORMAL_PMD, ...) is called, which first takes rmap locks, then does move_normal_pmd(). move_normal_pmd() takes the necessary page table locks at source and destination, then moves an entire page table from the source to the destination. The problem is: The rmap locks, which protect against concurrent page table removal by retract_page_tables() in the THP code, are only taken after the PMD entry has been read and it has been decided how to move it. So we can race as follows (with two processes that have mappings of the same tmpfs file that is stored on a tmpfs mount with huge=advise); note that process A accesses page tables through the MM while process B does it through the file rmap: process A process B ========= ========= mremap mremap_to move_vma move_page_tables get_old_pmd alloc_new_pmd *** PREEMPT *** madvise(MADV_COLLAPSE) do_madvise madvise_walk_vmas madvise_vma_behavior madvise_collapse hpage_collapse_scan_file collapse_file retract_page_tables i_mmap_lock_read(mapping) pmdp_collapse_flush i_mmap_unlock_read(mapping) move_pgt_entry(NORMAL_PMD, ...) take_rmap_locks move_normal_pmd drop_rmap_locks When this happens, move_normal_pmd() can end up creating bogus PMD entries in the line `pmd_populate(mm, new_pmd, pmd_pgtable(pmd))`. The effect depends on arch-specific and machine-specific details; on x86, you can end up with physical page 0 mapped as a page table, which is likely exploitable for user->kernel privilege escalation. Fix the race by letting process B recheck that the PMD still points to a page table after the rmap locks have been taken. Otherwise, we bail and let the caller fall back to the PTE-level copying path, which will then bail immediately at the pmd_none() check. Bug reachability: Reaching this bug requires that you can create shmem/file THP mappings - anonymous THP uses different code that doesn't zap stuff under rmap locks. File THP is gated on an experimental config flag (CONFIG_READ_ONLY_THP_FOR_FS), so on normal distro kernels you need shmem THP to hit this bug. As far as I know, getting shmem THP normally requires that you can mount your own tmpfs with the right mount flags, which would require creating your own user+mount namespace; though I don't know if some distros maybe enable shmem THP by default or something like that. Bug impact: This issue can likely be used for user->kernel privilege escalation when it is reachable.", "cve_priority": "medium", "cve_public_date": "2024-10-23 06:15:00 UTC" }, { "cve": "CVE-2024-50202", "url": "https://ubuntu.com/security/CVE-2024-50202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: propagate directory read errors from nilfs_find_entry() Syzbot reported that a task hang occurs in vcs_open() during a fuzzing test for nilfs2. The root cause of this problem is that in nilfs_find_entry(), which searches for directory entries, ignores errors when loading a directory page/folio via nilfs_get_folio() fails. If the filesystem images is corrupted, and the i_size of the directory inode is large, and the directory page/folio is successfully read but fails the sanity check, for example when it is zero-filled, nilfs_check_folio() may continue to spit out error messages in bursts. Fix this issue by propagating the error to the callers when loading a page/folio fails in nilfs_find_entry(). The current interface of nilfs_find_entry() and its callers is outdated and cannot propagate error codes such as -EIO and -ENOMEM returned via nilfs_find_entry(), so fix it together.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50200", "url": "https://ubuntu.com/security/CVE-2024-50200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: maple_tree: correct tree corruption on spanning store Patch series \"maple_tree: correct tree corruption on spanning store\", v3. There has been a nasty yet subtle maple tree corruption bug that appears to have been in existence since the inception of the algorithm. This bug seems far more likely to happen since commit f8d112a4e657 (\"mm/mmap: avoid zeroing vma tree in mmap_region()\"), which is the point at which reports started to be submitted concerning this bug. We were made definitely aware of the bug thanks to the kind efforts of Bert Karwatzki who helped enormously in my being able to track this down and identify the cause of it. The bug arises when an attempt is made to perform a spanning store across two leaf nodes, where the right leaf node is the rightmost child of the shared parent, AND the store completely consumes the right-mode node. This results in mas_wr_spanning_store() mitakenly duplicating the new and existing entries at the maximum pivot within the range, and thus maple tree corruption. The fix patch corrects this by detecting this scenario and disallowing the mistaken duplicate copy. The fix patch commit message goes into great detail as to how this occurs. This series also includes a test which reliably reproduces the issue, and asserts that the fix works correctly. Bert has kindly tested the fix and confirmed it resolved his issues. Also Mikhail Gavrilov kindly reported what appears to be precisely the same bug, which this fix should also resolve. This patch (of 2): There has been a subtle bug present in the maple tree implementation from its inception. This arises from how stores are performed - when a store occurs, it will overwrite overlapping ranges and adjust the tree as necessary to accommodate this. A range may always ultimately span two leaf nodes. In this instance we walk the two leaf nodes, determine which elements are not overwritten to the left and to the right of the start and end of the ranges respectively and then rebalance the tree to contain these entries and the newly inserted one. This kind of store is dubbed a 'spanning store' and is implemented by mas_wr_spanning_store(). In order to reach this stage, mas_store_gfp() invokes mas_wr_preallocate(), mas_wr_store_type() and mas_wr_walk() in turn to walk the tree and update the object (mas) to traverse to the location where the write should be performed, determining its store type. When a spanning store is required, this function returns false stopping at the parent node which contains the target range, and mas_wr_store_type() marks the mas->store_type as wr_spanning_store to denote this fact. When we go to perform the store in mas_wr_spanning_store(), we first determine the elements AFTER the END of the range we wish to store (that is, to the right of the entry to be inserted) - we do this by walking to the NEXT pivot in the tree (i.e. r_mas.last + 1), starting at the node we have just determined contains the range over which we intend to write. We then turn our attention to the entries to the left of the entry we are inserting, whose state is represented by l_mas, and copy these into a 'big node', which is a special node which contains enough slots to contain two leaf node's worth of data. We then copy the entry we wish to store immediately after this - the copy and the insertion of the new entry is performed by mas_store_b_node(). After this we copy the elements to the right of the end of the range which we are inserting, if we have not exceeded the length of the node (i.e. r_mas.offset <= r_mas.end). Herein lies the bug - under very specific circumstances, this logic can break and corrupt the maple tree. Consider the following tree: Height 0 Root Node / \\ pivot = 0xffff / \\ pivot = ULONG_MAX / ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50084", "url": "https://ubuntu.com/security/CVE-2024-50084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: microchip: vcap api: Fix memory leaks in vcap_api_encode_rule_test() Commit a3c1e45156ad (\"net: microchip: vcap: Fix use-after-free error in kunit test\") fixed the use-after-free error, but introduced below memory leaks by removing necessary vcap_free_rule(), add it to fix it. \tunreferenced object 0xffffff80ca58b700 (size 192): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898264 \t hex dump (first 32 bytes): \t 00 12 7a 00 05 00 00 00 0a 00 00 00 64 00 00 00 ..z.........d... \t 00 00 00 00 00 00 00 00 00 04 0b cc 80 ff ff ff ................ \t backtrace (crc 9c09c3fe): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<0000000040a01b8d>] vcap_alloc_rule+0x3cc/0x9c4 \t [<000000003fe86110>] vcap_api_encode_rule_test+0x1ac/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0400 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898265 \t hex dump (first 32 bytes): \t 80 04 0b cc 80 ff ff ff 18 b7 58 ca 80 ff ff ff ..........X..... \t 39 00 00 00 02 00 00 00 06 05 04 03 02 01 ff ff 9............... \t backtrace (crc daf014e9): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<00000000dfdb1e81>] vcap_api_encode_rule_test+0x224/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0700 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898265 \t hex dump (first 32 bytes): \t 80 07 0b cc 80 ff ff ff 28 b7 58 ca 80 ff ff ff ........(.X..... \t 3c 00 00 00 00 00 00 00 01 2f 03 b3 ec ff ff ff <......../...... \t backtrace (crc 8d877792): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000006eadfab7>] vcap_rule_add_action+0x2d0/0x52c \t [<00000000323475d1>] vcap_api_encode_rule_test+0x4d4/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0900 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898266 \t hex dump (first 32 bytes): \t 80 09 0b cc 80 ff ff ff 80 06 0b cc 80 ff ff ff ................ \t 7d 00 00 00 01 00 00 00 00 00 00 00 ff 00 00 00 }............... \t backtrace (crc 34181e56): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<00000000991e3564>] vcap_val_rule+0xcf0/0x13e8 \t [<00000000fc9868e5>] vcap_api_encode_rule_test+0x678/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0980 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898266 \t hex dump (first 32 bytes): \t 18 b7 58 ca 80 ff ff ff 00 09 0b cc 80 ff ff ff ..X............. \t 67 00 00 00 00 00 00 00 01 01 74 88 c0 ff ff ff g.........t..... \t backtrace (crc 275fd9be): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<000000001396a1a2>] test_add_de ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50194", "url": "https://ubuntu.com/security/CVE-2024-50194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Fix uprobes for big-endian kernels The arm64 uprobes code is broken for big-endian kernels as it doesn't convert the in-memory instruction encoding (which is always little-endian) into the kernel's native endianness before analyzing and simulating instructions. This may result in a few distinct problems: * The kernel may may erroneously reject probing an instruction which can safely be probed. * The kernel may erroneously erroneously permit stepping an instruction out-of-line when that instruction cannot be stepped out-of-line safely. * The kernel may erroneously simulate instruction incorrectly dur to interpretting the byte-swapped encoding. The endianness mismatch isn't caught by the compiler or sparse because: * The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so the compiler and sparse have no idea these contain a little-endian 32-bit value. The core uprobes code populates these with a memcpy() which similarly does not handle endianness. * While the uprobe_opcode_t type is an alias for __le32, both arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[] to the similarly-named probe_opcode_t, which is an alias for u32. Hence there is no endianness conversion warning. Fix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and adding the appropriate __le32_to_cpu() conversions prior to consuming the instruction encoding. The core uprobes copies these fields as opaque ranges of bytes, and so is unaffected by this change. At the same time, remove MAX_UINSN_BYTES and consistently use AARCH64_INSN_SIZE for clarity. Tested with the following: | #include | #include | | #define noinline __attribute__((noinline)) | | static noinline void *adrp_self(void) | { | void *addr; | | asm volatile( | \" adrp %x0, adrp_self\\n\" | \" add %x0, %x0, :lo12:adrp_self\\n\" | : \"=r\" (addr)); | } | | | int main(int argc, char *argv) | { | void *ptr = adrp_self(); | bool equal = (ptr == adrp_self); | | printf(\"adrp_self => %p\\n\" | \"adrp_self() => %p\\n\" | \"%s\\n\", | adrp_self, ptr, equal ? \"EQUAL\" : \"NOT EQUAL\"); | | return 0; | } .... where the adrp_self() function was compiled to: | 00000000004007e0 : | 4007e0: 90000000 adrp x0, 400000 <__ehdr_start> | 4007e4: 911f8000 add x0, x0, #0x7e0 | 4007e8: d65f03c0 ret Before this patch, the ADRP is not recognized, and is assumed to be steppable, resulting in corruption of the result: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0xffffffffff7e0 | NOT EQUAL After this patch, the ADRP is correctly recognized and simulated: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50099", "url": "https://ubuntu.com/security/CVE-2024-50099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Remove broken LDR (literal) uprobe support The simulate_ldr_literal() and simulate_ldrsw_literal() functions are unsafe to use for uprobes. Both functions were originally written for use with kprobes, and access memory with plain C accesses. When uprobes was added, these were reused unmodified even though they cannot safely access user memory. There are three key problems: 1) The plain C accesses do not have corresponding extable entries, and thus if they encounter a fault the kernel will treat these as unintentional accesses to user memory, resulting in a BUG() which will kill the kernel thread, and likely lead to further issues (e.g. lockup or panic()). 2) The plain C accesses are subject to HW PAN and SW PAN, and so when either is in use, any attempt to simulate an access to user memory will fault. Thus neither simulate_ldr_literal() nor simulate_ldrsw_literal() can do anything useful when simulating a user instruction on any system with HW PAN or SW PAN. 3) The plain C accesses are privileged, as they run in kernel context, and in practice can access a small range of kernel virtual addresses. The instructions they simulate have a range of +/-1MiB, and since the simulated instructions must itself be a user instructions in the TTBR0 address range, these can address the final 1MiB of the TTBR1 acddress range by wrapping downwards from an address in the first 1MiB of the TTBR0 address range. In contemporary kernels the last 8MiB of TTBR1 address range is reserved, and accesses to this will always fault, meaning this is no worse than (1). Historically, it was theoretically possible for the linear map or vmemmap to spill into the final 8MiB of the TTBR1 address range, but in practice this is extremely unlikely to occur as this would require either: * Having enough physical memory to fill the entire linear map all the way to the final 1MiB of the TTBR1 address range. * Getting unlucky with KASLR randomization of the linear map such that the populated region happens to overlap with the last 1MiB of the TTBR address range. ... and in either case if we were to spill into the final page there would be larger problems as the final page would alias with error pointers. Practically speaking, (1) and (2) are the big issues. Given there have been no reports of problems since the broken code was introduced, it appears that no-one is relying on probing these instructions with uprobes. Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW (literal), limiting the use of simulate_ldr_literal() and simulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR (literal) and LDRSW (literal) will be rejected as arm_probe_decode_insn() will return INSN_REJECTED. In future we can consider introducing working uprobes support for these instructions, but this will require more significant work.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50195", "url": "https://ubuntu.com/security/CVE-2024-50195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-clock: Fix missing timespec64 check in pc_clock_settime() As Andrew pointed out, it will make sense that the PTP core checked timespec64 struct's tv_sec and tv_nsec range before calling ptp->info->settime64(). As the man manual of clock_settime() said, if tp.tv_sec is negative or tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL, which include dynamic clocks which handles PTP clock, and the condition is consistent with timespec64_valid(). As Thomas suggested, timespec64_valid() only check the timespec is valid, but not ensure that the time is in a valid range, so check it ahead using timespec64_valid_strict() in pc_clock_settime() and return -EINVAL if not valid. There are some drivers that use tp->tv_sec and tp->tv_nsec directly to write registers without validity checks and assume that the higher layer has checked it, which is dangerous and will benefit from this, such as hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(), and some drivers can remove the checks of itself.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50085", "url": "https://ubuntu.com/security/CVE-2024-50085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: fix UaF read in mptcp_pm_nl_rm_addr_or_subflow Syzkaller reported this splat: ================================================================== BUG: KASAN: slab-use-after-free in mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881 Read of size 4 at addr ffff8880569ac858 by task syz.1.2799/14662 CPU: 0 UID: 0 PID: 14662 Comm: syz.1.2799 Not tainted 6.12.0-rc2-syzkaller-00307-g36c254515dc6 #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+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881 mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:914 [inline] mptcp_nl_remove_id_zero_address+0x305/0x4a0 net/mptcp/pm_netlink.c:1572 mptcp_pm_nl_del_addr_doit+0x5c9/0x770 net/mptcp/pm_netlink.c:1603 genl_family_rcv_msg_doit+0x202/0x2f0 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x565/0x800 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x165/0x410 net/netlink/af_netlink.c:2551 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1331 [inline] netlink_unicast+0x53c/0x7f0 net/netlink/af_netlink.c:1357 netlink_sendmsg+0x8b8/0xd70 net/netlink/af_netlink.c:1901 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg net/socket.c:744 [inline] ____sys_sendmsg+0x9ae/0xb40 net/socket.c:2607 ___sys_sendmsg+0x135/0x1e0 net/socket.c:2661 __sys_sendmsg+0x117/0x1f0 net/socket.c:2690 do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline] __do_fast_syscall_32+0x73/0x120 arch/x86/entry/common.c:386 do_fast_syscall_32+0x32/0x80 arch/x86/entry/common.c:411 entry_SYSENTER_compat_after_hwframe+0x84/0x8e RIP: 0023:0xf7fe4579 Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00 RSP: 002b:00000000f574556c EFLAGS: 00000296 ORIG_RAX: 0000000000000172 RAX: ffffffffffffffda RBX: 000000000000000b RCX: 0000000020000140 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000296 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Allocated by task 5387: 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 kmalloc_noprof include/linux/slab.h:878 [inline] kzalloc_noprof include/linux/slab.h:1014 [inline] subflow_create_ctx+0x87/0x2a0 net/mptcp/subflow.c:1803 subflow_ulp_init+0xc3/0x4d0 net/mptcp/subflow.c:1956 __tcp_set_ulp net/ipv4/tcp_ulp.c:146 [inline] tcp_set_ulp+0x326/0x7f0 net/ipv4/tcp_ulp.c:167 mptcp_subflow_create_socket+0x4ae/0x10a0 net/mptcp/subflow.c:1764 __mptcp_subflow_connect+0x3cc/0x1490 net/mptcp/subflow.c:1592 mptcp_pm_create_subflow_or_signal_addr+0xbda/0x23a0 net/mptcp/pm_netlink.c:642 mptcp_pm_nl_fully_established net/mptcp/pm_netlink.c:650 [inline] mptcp_pm_nl_work+0x3a1/0x4f0 net/mptcp/pm_netlink.c:943 mptcp_worker+0x15a/0x1240 net/mptcp/protocol.c:2777 process_one_work+0x958/0x1b30 kernel/workqueue.c:3229 process_scheduled_works kernel/workqueue.c:3310 [inline] worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/ke ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50086", "url": "https://ubuntu.com/security/CVE-2024-50086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix user-after-free from session log off There is racy issue between smb2 session log off and smb2 session setup. It will cause user-after-free from session log off. This add session_lock when setting SMB2_SESSION_EXPIRED and referece count to session struct not to free session while it is being used.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50087", "url": "https://ubuntu.com/security/CVE-2024-50087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix uninitialized pointer free on read_alloc_one_name() error The function read_alloc_one_name() does not initialize the name field of the passed fscrypt_str struct if kmalloc fails to allocate the corresponding buffer. Thus, it is not guaranteed that fscrypt_str.name is initialized when freeing it. This is a follow-up to the linked patch that fixes the remaining instances of the bug introduced by commit e43eec81c516 (\"btrfs: use struct qstr instead of name and namelen pairs\").", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50088", "url": "https://ubuntu.com/security/CVE-2024-50088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix uninitialized pointer free in add_inode_ref() The add_inode_ref() function does not initialize the \"name\" struct when it is declared. If any of the following calls to \"read_one_inode() returns NULL, \tdir = read_one_inode(root, parent_objectid); \tif (!dir) { \t\tret = -ENOENT; \t\tgoto out; \t} \tinode = read_one_inode(root, inode_objectid); \tif (!inode) { \t\tret = -EIO; \t\tgoto out; \t} then \"name.name\" would be freed on \"out\" before being initialized. out: \t... \tkfree(name.name); This issue was reported by Coverity with CID 1526744.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50182", "url": "https://ubuntu.com/security/CVE-2024-50182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: secretmem: disable memfd_secret() if arch cannot set direct map Return -ENOSYS from memfd_secret() syscall if !can_set_direct_map(). This is the case for example on some arm64 configurations, where marking 4k PTEs in the direct map not present can only be done if the direct map is set up at 4k granularity in the first place (as ARM's break-before-make semantics do not easily allow breaking apart large/gigantic pages). More precisely, on arm64 systems with !can_set_direct_map(), set_direct_map_invalid_noflush() is a no-op, however it returns success (0) instead of an error. This means that memfd_secret will seemingly \"work\" (e.g. syscall succeeds, you can mmap the fd and fault in pages), but it does not actually achieve its goal of removing its memory from the direct map. Note that with this patch, memfd_secret() will start erroring on systems where can_set_direct_map() returns false (arm64 with CONFIG_RODATA_FULL_DEFAULT_ENABLED=n, CONFIG_DEBUG_PAGEALLOC=n and CONFIG_KFENCE=n), but that still seems better than the current silent failure. Since CONFIG_RODATA_FULL_DEFAULT_ENABLED defaults to 'y', most arm64 systems actually have a working memfd_secret() and aren't be affected. From going through the iterations of the original memfd_secret patch series, it seems that disabling the syscall in these scenarios was the intended behavior [1] (preferred over having set_direct_map_invalid_noflush return an error as that would result in SIGBUSes at page-fault time), however the check for it got dropped between v16 [2] and v17 [3], when secretmem moved away from CMA allocations. [1]: https://lore.kernel.org/lkml/20201124164930.GK8537@kernel.org/ [2]: https://lore.kernel.org/lkml/20210121122723.3446-11-rppt@kernel.org/#t [3]: https://lore.kernel.org/lkml/20201125092208.12544-10-rppt@kernel.org/", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50019", "url": "https://ubuntu.com/security/CVE-2024-50019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kthread: unpark only parked kthread Calling into kthread unparking unconditionally is mostly harmless when the kthread is already unparked. The wake up is then simply ignored because the target is not in TASK_PARKED state. However if the kthread is per CPU, the wake up is preceded by a call to kthread_bind() which expects the task to be inactive and in TASK_PARKED state, which obviously isn't the case if it is unparked. As a result, calling kthread_stop() on an unparked per-cpu kthread triggers such a warning: \tWARNING: CPU: 0 PID: 11 at kernel/kthread.c:525 __kthread_bind_mask kernel/kthread.c:525 \t \t kthread_stop+0x17a/0x630 kernel/kthread.c:707 \t destroy_workqueue+0x136/0xc40 kernel/workqueue.c:5810 \t wg_destruct+0x1e2/0x2e0 drivers/net/wireguard/device.c:257 \t netdev_run_todo+0xe1a/0x1000 net/core/dev.c:10693 \t default_device_exit_batch+0xa14/0xa90 net/core/dev.c:11769 \t ops_exit_list net/core/net_namespace.c:178 [inline] \t cleanup_net+0x89d/0xcc0 net/core/net_namespace.c:640 \t process_one_work kernel/workqueue.c:3231 [inline] \t process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 \t worker_thread+0x86d/0xd70 kernel/workqueue.c:3393 \t kthread+0x2f0/0x390 kernel/kthread.c:389 \t ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 \t ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 \t Fix this with skipping unecessary unparking while stopping a kthread.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50096", "url": "https://ubuntu.com/security/CVE-2024-50096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/dmem: Fix vulnerability in migrate_to_ram upon copy error The `nouveau_dmem_copy_one` function ensures that the copy push command is sent to the device firmware but does not track whether it was executed successfully. In the case of a copy error (e.g., firmware or hardware failure), the copy push command will be sent via the firmware channel, and `nouveau_dmem_copy_one` will likely report success, leading to the `migrate_to_ram` function returning a dirty HIGH_USER page to the user. This can result in a security vulnerability, as a HIGH_USER page that may contain sensitive or corrupted data could be returned to the user. To prevent this vulnerability, we allocate a zero page. Thus, in case of an error, a non-dirty (zero) page will be returned to the user.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50020", "url": "https://ubuntu.com/security/CVE-2024-50020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix improper handling of refcount in ice_sriov_set_msix_vec_count() This patch addresses an issue with improper reference count handling in the ice_sriov_set_msix_vec_count() function. First, the function calls ice_get_vf_by_id(), which increments the reference count of the vf pointer. If the subsequent call to ice_get_vf_vsi() fails, the function currently returns an error without decrementing the reference count of the vf pointer, leading to a reference count leak. The correct behavior, as implemented in this patch, is to decrement the reference count using ice_put_vf(vf) before returning an error when vsi is NULL. Second, the function calls ice_sriov_get_irqs(), which sets vf->first_vector_idx. If this call returns a negative value, indicating an error, the function returns an error without decrementing the reference count of the vf pointer, resulting in another reference count leak. The patch addresses this by adding a call to ice_put_vf(vf) before returning an error when vf->first_vector_idx < 0. This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and identifying potential mismanagement of reference counts. In this case, the tool flagged the missing decrement operation as a potential issue, leading to this patch.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50021", "url": "https://ubuntu.com/security/CVE-2024-50021", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix improper handling of refcount in ice_dpll_init_rclk_pins() This patch addresses a reference count handling issue in the ice_dpll_init_rclk_pins() function. The function calls ice_dpll_get_pins(), which increments the reference count of the relevant resources. However, if the condition WARN_ON((!vsi || !vsi->netdev)) is met, the function currently returns an error without properly releasing the resources acquired by ice_dpll_get_pins(), leading to a reference count leak. To resolve this, the check has been moved to the top of the function. This ensures that the function verifies the state before any resources are acquired, avoiding the need for additional resource management in the error path. This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and detecting potential issues where resources are not properly managed. In this case, the tool flagged the missing release operation as a potential problem, which led to the development of this patch.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50022", "url": "https://ubuntu.com/security/CVE-2024-50022", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: device-dax: correct pgoff align in dax_set_mapping() pgoff should be aligned using ALIGN_DOWN() instead of ALIGN(). Otherwise, vmf->address not aligned to fault_size will be aligned to the next alignment, that can result in memory failure getting the wrong address. It's a subtle situation that only can be observed in page_mapped_in_vma() after the page is page fault handled by dev_dax_huge_fault. Generally, there is little chance to perform page_mapped_in_vma in dev-dax's page unless in specific error injection to the dax device to trigger an MCE - memory-failure. In that case, page_mapped_in_vma() will be triggered to determine which task is accessing the failure address and kill that task in the end. We used self-developed dax device (which is 2M aligned mapping) , to perform error injection to random address. It turned out that error injected to non-2M-aligned address was causing endless MCE until panic. Because page_mapped_in_vma() kept resulting wrong address and the task accessing the failure address was never killed properly: [ 3783.719419] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.049006] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.049190] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.448042] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.448186] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.792026] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.792179] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.162502] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.162633] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.461116] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.461247] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.764730] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.764859] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.042128] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.042259] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.464293] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.464423] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.818090] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.818217] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3787.085297] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3787.085424] Memory failure: 0x200c9742: recovery action for dax page: Recovered It took us several weeks to pinpoint this problem,  but we eventually used bpftrace to trace the page fault and mce address and successfully identified the issue. Joao added: ; Likely we never reproduce in production because we always pin : device-dax regions in the region align they provide (Qemu does : similarly with prealloc in hugetlb/file backed memory). I think this : bug requires that we touch *unpinned* device-dax regions unaligned to : the device-dax selected alignment (page size i.e. 4K/2M/1G)", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50185", "url": "https://ubuntu.com/security/CVE-2024-50185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: handle consistently DSS corruption Bugged peer implementation can send corrupted DSS options, consistently hitting a few warning in the data path. Use DEBUG_NET assertions, to avoid the splat on some builds and handle consistently the error, dumping related MIBs and performing fallback and/or reset according to the subflow type.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50023", "url": "https://ubuntu.com/security/CVE-2024-50023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: Remove LED entry from LEDs list on unregister Commit c938ab4da0eb (\"net: phy: Manual remove LEDs to ensure correct ordering\") correctly fixed a problem with using devm_ but missed removing the LED entry from the LEDs list. This cause kernel panic on specific scenario where the port for the PHY is torn down and up and the kmod for the PHY is removed. On setting the port down the first time, the assosiacted LEDs are correctly unregistered. The associated kmod for the PHY is now removed. The kmod is now added again and the port is now put up, the associated LED are registered again. On putting the port down again for the second time after these step, the LED list now have 4 elements. With the first 2 already unregistered previously and the 2 new one registered again. This cause a kernel panic as the first 2 element should have been removed. Fix this by correctly removing the element when LED is unregistered.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50024", "url": "https://ubuntu.com/security/CVE-2024-50024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: Fix an unsafe loop on the list The kernel may crash when deleting a genetlink family if there are still listeners for that family: Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c000000000c080bc] netlink_update_socket_mc+0x3c/0xc0 LR [c000000000c0f764] __netlink_clear_multicast_users+0x74/0xc0 Call Trace: __netlink_clear_multicast_users+0x74/0xc0 genl_unregister_family+0xd4/0x2d0 Change the unsafe loop on the list to a safe one, because inside the loop there is an element removal from this list.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50186", "url": "https://ubuntu.com/security/CVE-2024-50186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: explicitly clear the sk pointer, when pf->create fails We have recently noticed the exact same KASAN splat as in commit 6cd4a78d962b (\"net: do not leave a dangling sk pointer, when socket creation fails\"). The problem is that commit did not fully address the problem, as some pf->create implementations do not use sk_common_release in their error paths. For example, we can use the same reproducer as in the above commit, but changing ping to arping. arping uses AF_PACKET socket and if packet_create fails, it will just sk_free the allocated sk object. While we could chase all the pf->create implementations and make sure they NULL the freed sk object on error from the socket, we can't guarantee future protocols will not make the same mistake. So it is easier to just explicitly NULL the sk pointer upon return from pf->create in __sock_create. We do know that pf->create always releases the allocated sk object on error, so if the pointer is not NULL, it is definitely dangling.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50025", "url": "https://ubuntu.com/security/CVE-2024-50025", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: fnic: Move flush_work initialization out of if block After commit 379a58caa199 (\"scsi: fnic: Move fnic_fnic_flush_tx() to a work queue\"), it can happen that a work item is sent to an uninitialized work queue. This may has the effect that the item being queued is never actually queued, and any further actions depending on it will not proceed. The following warning is observed while the fnic driver is loaded: kernel: WARNING: CPU: 11 PID: 0 at ../kernel/workqueue.c:1524 __queue_work+0x373/0x410 kernel: kernel: queue_work_on+0x3a/0x50 kernel: fnic_wq_copy_cmpl_handler+0x54a/0x730 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: fnic_isr_msix_wq_copy+0x2d/0x60 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: __handle_irq_event_percpu+0x36/0x1a0 kernel: handle_irq_event_percpu+0x30/0x70 kernel: handle_irq_event+0x34/0x60 kernel: handle_edge_irq+0x7e/0x1a0 kernel: __common_interrupt+0x3b/0xb0 kernel: common_interrupt+0x58/0xa0 kernel: It has been observed that this may break the rediscovery of Fibre Channel devices after a temporary fabric failure. This patch fixes it by moving the work queue initialization out of an if block in fnic_probe().", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50026", "url": "https://ubuntu.com/security/CVE-2024-50026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: wd33c93: Don't use stale scsi_pointer value A regression was introduced with commit dbb2da557a6a (\"scsi: wd33c93: Move the SCSI pointer to private command data\") which results in an oops in wd33c93_intr(). That commit added the scsi_pointer variable and initialized it from hostdata->connected. However, during selection, hostdata->connected is not yet valid. Fix this by getting the current scsi_pointer from hostdata->selecting.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50027", "url": "https://ubuntu.com/security/CVE-2024-50027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: core: Free tzp copy along with the thermal zone The object pointed to by tz->tzp may still be accessed after being freed in thermal_zone_device_unregister(), so move the freeing of it to the point after the removal completion has been completed at which it cannot be accessed any more.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50028", "url": "https://ubuntu.com/security/CVE-2024-50028", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: core: Reference count the zone in thermal_zone_get_by_id() There are places in the thermal netlink code where nothing prevents the thermal zone object from going away while being accessed after it has been returned by thermal_zone_get_by_id(). To address this, make thermal_zone_get_by_id() get a reference on the thermal zone device object to be returned with the help of get_device(), under thermal_list_lock, and adjust all of its callers to this change with the help of the cleanup.h infrastructure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50029", "url": "https://ubuntu.com/security/CVE-2024-50029", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_conn: Fix UAF in hci_enhanced_setup_sync This checks if the ACL connection remains valid as it could be destroyed while hci_enhanced_setup_sync is pending on cmd_sync leading to the following trace: BUG: KASAN: slab-use-after-free in hci_enhanced_setup_sync+0x91b/0xa60 Read of size 1 at addr ffff888002328ffd by task kworker/u5:2/37 CPU: 0 UID: 0 PID: 37 Comm: kworker/u5:2 Not tainted 6.11.0-rc6-01300-g810be445d8d6 #7099 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Workqueue: hci0 hci_cmd_sync_work Call Trace: dump_stack_lvl+0x5d/0x80 ? hci_enhanced_setup_sync+0x91b/0xa60 print_report+0x152/0x4c0 ? hci_enhanced_setup_sync+0x91b/0xa60 ? __virt_addr_valid+0x1fa/0x420 ? hci_enhanced_setup_sync+0x91b/0xa60 kasan_report+0xda/0x1b0 ? hci_enhanced_setup_sync+0x91b/0xa60 hci_enhanced_setup_sync+0x91b/0xa60 ? __pfx_hci_enhanced_setup_sync+0x10/0x10 ? __pfx___mutex_lock+0x10/0x10 hci_cmd_sync_work+0x1c2/0x330 process_one_work+0x7d9/0x1360 ? __pfx_lock_acquire+0x10/0x10 ? __pfx_process_one_work+0x10/0x10 ? assign_work+0x167/0x240 worker_thread+0x5b7/0xf60 ? __kthread_parkme+0xac/0x1c0 ? __pfx_worker_thread+0x10/0x10 ? __pfx_worker_thread+0x10/0x10 kthread+0x293/0x360 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2f/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 34: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __hci_conn_add+0x187/0x17d0 hci_connect_sco+0x2e1/0xb90 sco_sock_connect+0x2a2/0xb80 __sys_connect+0x227/0x2a0 __x64_sys_connect+0x6d/0xb0 do_syscall_64+0x71/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 37: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x101/0x160 kfree+0xd0/0x250 device_release+0x9a/0x210 kobject_put+0x151/0x280 hci_conn_del+0x448/0xbf0 hci_abort_conn_sync+0x46f/0x980 hci_cmd_sync_work+0x1c2/0x330 process_one_work+0x7d9/0x1360 worker_thread+0x5b7/0xf60 kthread+0x293/0x360 ret_from_fork+0x2f/0x70 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50030", "url": "https://ubuntu.com/security/CVE-2024-50030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/ct: prevent UAF in send_recv() Ensure we serialize with completion side to prevent UAF with fence going out of scope on the stack, since we have no clue if it will fire after the timeout before we can erase from the xa. Also we have some dependent loads and stores for which we need the correct ordering, and we lack the needed barriers. Fix this by grabbing the ct->lock after the wait, which is also held by the completion side. v2 (Badal): - Also print done after acquiring the lock and seeing timeout. (cherry picked from commit 52789ce35c55ccd30c4b67b9cc5b2af55e0122ea)", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50187", "url": "https://ubuntu.com/security/CVE-2024-50187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Stop the active perfmon before being destroyed Upon closing the file descriptor, the active performance monitor is not stopped. Although all perfmons are destroyed in `vc4_perfmon_close_file()`, the active performance monitor's pointer (`vc4->active_perfmon`) is still retained. If we open a new file descriptor and submit a few jobs with performance monitors, the driver will attempt to stop the active performance monitor using the stale pointer in `vc4->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50031", "url": "https://ubuntu.com/security/CVE-2024-50031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Stop the active perfmon before being destroyed When running `kmscube` with one or more performance monitors enabled via `GALLIUM_HUD`, the following kernel panic can occur: [ 55.008324] Unable to handle kernel paging request at virtual address 00000000052004a4 [ 55.008368] Mem abort info: [ 55.008377] ESR = 0x0000000096000005 [ 55.008387] EC = 0x25: DABT (current EL), IL = 32 bits [ 55.008402] SET = 0, FnV = 0 [ 55.008412] EA = 0, S1PTW = 0 [ 55.008421] FSC = 0x05: level 1 translation fault [ 55.008434] Data abort info: [ 55.008442] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 55.008455] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 55.008467] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 55.008481] user pgtable: 4k pages, 39-bit VAs, pgdp=00000001046c6000 [ 55.008497] [00000000052004a4] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 55.008525] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP [ 55.008542] Modules linked in: rfcomm [...] vc4 v3d snd_soc_hdmi_codec drm_display_helper gpu_sched drm_shmem_helper cec drm_dma_helper drm_kms_helper i2c_brcmstb drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight [ 55.008799] CPU: 2 PID: 166 Comm: v3d_bin Tainted: G C 6.6.47+rpt-rpi-v8 #1 Debian 1:6.6.47-1+rpt1 [ 55.008824] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [ 55.008838] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 55.008855] pc : __mutex_lock.constprop.0+0x90/0x608 [ 55.008879] lr : __mutex_lock.constprop.0+0x58/0x608 [ 55.008895] sp : ffffffc080673cf0 [ 55.008904] x29: ffffffc080673cf0 x28: 0000000000000000 x27: ffffff8106188a28 [ 55.008926] x26: ffffff8101e78040 x25: ffffff8101baa6c0 x24: ffffffd9d989f148 [ 55.008947] x23: ffffffda1c2a4008 x22: 0000000000000002 x21: ffffffc080673d38 [ 55.008968] x20: ffffff8101238000 x19: ffffff8104f83188 x18: 0000000000000000 [ 55.008988] x17: 0000000000000000 x16: ffffffda1bd04d18 x15: 00000055bb08bc90 [ 55.009715] x14: 0000000000000000 x13: 0000000000000000 x12: ffffffda1bd4cbb0 [ 55.010433] x11: 00000000fa83b2da x10: 0000000000001a40 x9 : ffffffda1bd04d04 [ 55.011162] x8 : ffffff8102097b80 x7 : 0000000000000000 x6 : 00000000030a5857 [ 55.011880] x5 : 00ffffffffffffff x4 : 0300000005200470 x3 : 0300000005200470 [ 55.012598] x2 : ffffff8101238000 x1 : 0000000000000021 x0 : 0300000005200470 [ 55.013292] Call trace: [ 55.013959] __mutex_lock.constprop.0+0x90/0x608 [ 55.014646] __mutex_lock_slowpath+0x1c/0x30 [ 55.015317] mutex_lock+0x50/0x68 [ 55.015961] v3d_perfmon_stop+0x40/0xe0 [v3d] [ 55.016627] v3d_bin_job_run+0x10c/0x2d8 [v3d] [ 55.017282] drm_sched_main+0x178/0x3f8 [gpu_sched] [ 55.017921] kthread+0x11c/0x128 [ 55.018554] ret_from_fork+0x10/0x20 [ 55.019168] Code: f9400260 f1001c1f 54001ea9 927df000 (b9403401) [ 55.019776] ---[ end trace 0000000000000000 ]--- [ 55.020411] note: v3d_bin[166] exited with preempt_count 1 This issue arises because, upon closing the file descriptor (which happens when we interrupt `kmscube`), the active performance monitor is not stopped. Although all perfmons are destroyed in `v3d_perfmon_close_file()`, the active performance monitor's pointer (`v3d->active_perfmon`) is still retained. If `kmscube` is run again, the driver will attempt to stop the active performance monitor using the stale pointer in `v3d->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50189", "url": "https://ubuntu.com/security/CVE-2024-50189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: amd_sfh: Switch to device-managed dmam_alloc_coherent() Using the device-managed version allows to simplify clean-up in probe() error path. Additionally, this device-managed ensures proper cleanup, which helps to resolve memory errors, page faults, btrfs going read-only, and btrfs disk corruption.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50033", "url": "https://ubuntu.com/security/CVE-2024-50033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slip: make slhc_remember() more robust against malicious packets syzbot found that slhc_remember() was missing checks against malicious packets [1]. slhc_remember() only checked the size of the packet was at least 20, which is not good enough. We need to make sure the packet includes the IPv4 and TCP header that are supposed to be carried. Add iph and th pointers to make the code more readable. [1] BUG: KMSAN: uninit-value in slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 ppp_receive_nonmp_frame+0xe45/0x35e0 drivers/net/ppp/ppp_generic.c:2455 ppp_receive_frame drivers/net/ppp/ppp_generic.c:2372 [inline] ppp_do_recv+0x65f/0x40d0 drivers/net/ppp/ppp_generic.c:2212 ppp_input+0x7dc/0xe60 drivers/net/ppp/ppp_generic.c:2327 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 Uninit was created at: slab_post_alloc_hook mm/slub.c:4091 [inline] slab_alloc_node mm/slub.c:4134 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 CPU: 0 UID: 0 PID: 5460 Comm: syz.2.33 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50034", "url": "https://ubuntu.com/security/CVE-2024-50034", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix lacks of icsk_syn_mss with IPPROTO_SMC Eric report a panic on IPPROTO_SMC, and give the facts that when INET_PROTOSW_ICSK was set, icsk->icsk_sync_mss must be set too. Bug: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000086000005 EC = 0x21: IABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault user pgtable: 4k pages, 48-bit VAs, pgdp=00000001195d1000 [0000000000000000] pgd=0800000109c46003, p4d=0800000109c46003, pud=0000000000000000 Internal error: Oops: 0000000086000005 [#1] PREEMPT SMP Modules linked in: CPU: 1 UID: 0 PID: 8037 Comm: syz.3.265 Not tainted 6.11.0-rc7-syzkaller-g5f5673607153 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0x0 lr : cipso_v4_sock_setattr+0x2a8/0x3c0 net/ipv4/cipso_ipv4.c:1910 sp : ffff80009b887a90 x29: ffff80009b887aa0 x28: ffff80008db94050 x27: 0000000000000000 x26: 1fffe0001aa6f5b3 x25: dfff800000000000 x24: ffff0000db75da00 x23: 0000000000000000 x22: ffff0000d8b78518 x21: 0000000000000000 x20: ffff0000d537ad80 x19: ffff0000d8b78000 x18: 1fffe000366d79ee x17: ffff8000800614a8 x16: ffff800080569b84 x15: 0000000000000001 x14: 000000008b336894 x13: 00000000cd96feaa x12: 0000000000000003 x11: 0000000000040000 x10: 00000000000020a3 x9 : 1fffe0001b16f0f1 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 000000000000003f x5 : 0000000000000040 x4 : 0000000000000001 x3 : 0000000000000000 x2 : 0000000000000002 x1 : 0000000000000000 x0 : ffff0000d8b78000 Call trace: 0x0 netlbl_sock_setattr+0x2e4/0x338 net/netlabel/netlabel_kapi.c:1000 smack_netlbl_add+0xa4/0x154 security/smack/smack_lsm.c:2593 smack_socket_post_create+0xa8/0x14c security/smack/smack_lsm.c:2973 security_socket_post_create+0x94/0xd4 security/security.c:4425 __sock_create+0x4c8/0x884 net/socket.c:1587 sock_create net/socket.c:1622 [inline] __sys_socket_create net/socket.c:1659 [inline] __sys_socket+0x134/0x340 net/socket.c:1706 __do_sys_socket net/socket.c:1720 [inline] __se_sys_socket net/socket.c:1718 [inline] __arm64_sys_socket+0x7c/0x94 net/socket.c:1718 __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:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 Code: ???????? ???????? ???????? ???????? (????????) ---[ end trace 0000000000000000 ]--- This patch add a toy implementation that performs a simple return to prevent such panic. This is because MSS can be set in sock_create_kern or smc_setsockopt, similar to how it's done in AF_SMC. However, for AF_SMC, there is currently no way to synchronize MSS within __sys_connect_file. This toy implementation lays the groundwork for us to support such feature for IPPROTO_SMC in the future.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50035", "url": "https://ubuntu.com/security/CVE-2024-50035", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: fix ppp_async_encode() illegal access syzbot reported an issue in ppp_async_encode() [1] In this case, pppoe_sendmsg() is called with a zero size. Then ppp_async_encode() is called with an empty skb. BUG: KMSAN: uninit-value in ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] BUG: KMSAN: uninit-value in ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_send+0x130/0x1b0 drivers/net/ppp/ppp_async.c:634 ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2280 [inline] ppp_input+0x1f1/0xe60 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 Uninit was created at: slab_post_alloc_hook mm/slub.c:4092 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4187 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 CPU: 1 UID: 0 PID: 5411 Comm: syz.1.14 Not tainted 6.12.0-rc1-syzkaller-00165-g360c1f1f24c6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50036", "url": "https://ubuntu.com/security/CVE-2024-50036", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: do not delay dst_entries_add() in dst_release() dst_entries_add() uses per-cpu data that might be freed at netns dismantle from ip6_route_net_exit() calling dst_entries_destroy() Before ip6_route_net_exit() can be called, we release all the dsts associated with this netns, via calls to dst_release(), which waits an rcu grace period before calling dst_destroy() dst_entries_add() use in dst_destroy() is racy, because dst_entries_destroy() could have been called already. Decrementing the number of dsts must happen sooner. Notes: 1) in CONFIG_XFRM case, dst_destroy() can call dst_release_immediate(child), this might also cause UAF if the child does not have DST_NOCOUNT set. IPSEC maintainers might take a look and see how to address this. 2) There is also discussion about removing this count of dst, which might happen in future kernels.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50037", "url": "https://ubuntu.com/security/CVE-2024-50037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/fbdev-dma: Only cleanup deferred I/O if necessary Commit 5a498d4d06d6 (\"drm/fbdev-dma: Only install deferred I/O if necessary\") initializes deferred I/O only if it is used. drm_fbdev_dma_fb_destroy() however calls fb_deferred_io_cleanup() unconditionally with struct fb_info.fbdefio == NULL. KASAN with the out-of-tree Apple silicon display driver posts following warning from __flush_work() of a random struct work_struct instead of the expected NULL pointer derefs. [ 22.053799] ------------[ cut here ]------------ [ 22.054832] WARNING: CPU: 2 PID: 1 at kernel/workqueue.c:4177 __flush_work+0x4d8/0x580 [ 22.056597] Modules linked in: uhid bnep uinput nls_ascii ip6_tables ip_tables i2c_dev loop fuse dm_multipath nfnetlink zram hid_magicmouse btrfs xor xor_neon brcmfmac_wcc raid6_pq hci_bcm4377 bluetooth brcmfmac hid_apple brcmutil nvmem_spmi_mfd simple_mfd_spmi dockchannel_hid cfg80211 joydev regmap_spmi nvme_apple ecdh_generic ecc macsmc_hid rfkill dwc3 appledrm snd_soc_macaudio macsmc_power nvme_core apple_isp phy_apple_atc apple_sart apple_rtkit_helper apple_dockchannel tps6598x macsmc_hwmon snd_soc_cs42l84 videobuf2_v4l2 spmi_apple_controller nvmem_apple_efuses videobuf2_dma_sg apple_z2 videobuf2_memops spi_nor panel_summit videobuf2_common asahi videodev pwm_apple apple_dcp snd_soc_apple_mca apple_admac spi_apple clk_apple_nco i2c_pasemi_platform snd_pcm_dmaengine mc i2c_pasemi_core mux_core ofpart adpdrm drm_dma_helper apple_dart apple_soc_cpufreq leds_pwm phram [ 22.073768] CPU: 2 UID: 0 PID: 1 Comm: systemd-shutdow Not tainted 6.11.2-asahi+ #asahi-dev [ 22.075612] Hardware name: Apple MacBook Pro (13-inch, M2, 2022) (DT) [ 22.077032] pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 22.078567] pc : __flush_work+0x4d8/0x580 [ 22.079471] lr : __flush_work+0x54/0x580 [ 22.080345] sp : ffffc000836ef820 [ 22.081089] x29: ffffc000836ef880 x28: 0000000000000000 x27: ffff80002ddb7128 [ 22.082678] x26: dfffc00000000000 x25: 1ffff000096f0c57 x24: ffffc00082d3e358 [ 22.084263] x23: ffff80004b7862b8 x22: dfffc00000000000 x21: ffff80005aa1d470 [ 22.085855] x20: ffff80004b786000 x19: ffff80004b7862a0 x18: 0000000000000000 [ 22.087439] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000005 [ 22.089030] x14: 1ffff800106ddf0a x13: 0000000000000000 x12: 0000000000000000 [ 22.090618] x11: ffffb800106ddf0f x10: dfffc00000000000 x9 : 1ffff800106ddf0e [ 22.092206] x8 : 0000000000000000 x7 : aaaaaaaaaaaaaaaa x6 : 0000000000000001 [ 22.093790] x5 : ffffc000836ef728 x4 : 0000000000000000 x3 : 0000000000000020 [ 22.095368] x2 : 0000000000000008 x1 : 00000000000000aa x0 : 0000000000000000 [ 22.096955] Call trace: [ 22.097505] __flush_work+0x4d8/0x580 [ 22.098330] flush_delayed_work+0x80/0xb8 [ 22.099231] fb_deferred_io_cleanup+0x3c/0x130 [ 22.100217] drm_fbdev_dma_fb_destroy+0x6c/0xe0 [drm_dma_helper] [ 22.101559] unregister_framebuffer+0x210/0x2f0 [ 22.102575] drm_fb_helper_unregister_info+0x48/0x60 [ 22.103683] drm_fbdev_dma_client_unregister+0x4c/0x80 [drm_dma_helper] [ 22.105147] drm_client_dev_unregister+0x1cc/0x230 [ 22.106217] drm_dev_unregister+0x58/0x570 [ 22.107125] apple_drm_unbind+0x50/0x98 [appledrm] [ 22.108199] component_del+0x1f8/0x3a8 [ 22.109042] dcp_platform_shutdown+0x24/0x38 [apple_dcp] [ 22.110357] platform_shutdown+0x70/0x90 [ 22.111219] device_shutdown+0x368/0x4d8 [ 22.112095] kernel_restart+0x6c/0x1d0 [ 22.112946] __arm64_sys_reboot+0x1c8/0x328 [ 22.113868] invoke_syscall+0x78/0x1a8 [ 22.114703] do_el0_svc+0x124/0x1a0 [ 22.115498] el0_svc+0x3c/0xe0 [ 22.116181] el0t_64_sync_handler+0x70/0xc0 [ 22.117110] el0t_64_sync+0x190/0x198 [ 22.117931] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50092", "url": "https://ubuntu.com/security/CVE-2024-50092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netconsole: fix wrong warning A warning is triggered when there is insufficient space in the buffer for userdata. However, this is not an issue since userdata will be sent in the next iteration. Current warning message: ------------[ cut here ]------------ WARNING: CPU: 13 PID: 3013042 at drivers/net/netconsole.c:1122 write_ext_msg+0x3b6/0x3d0 ? write_ext_msg+0x3b6/0x3d0 console_flush_all+0x1e9/0x330 The code incorrectly issues a warning when this_chunk is zero, which is a valid scenario. The warning should only be triggered when this_chunk is negative.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50038", "url": "https://ubuntu.com/security/CVE-2024-50038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xtables: avoid NFPROTO_UNSPEC where needed syzbot managed to call xt_cluster match via ebtables: WARNING: CPU: 0 PID: 11 at net/netfilter/xt_cluster.c:72 xt_cluster_mt+0x196/0x780 [..] ebt_do_table+0x174b/0x2a40 Module registers to NFPROTO_UNSPEC, but it assumes ipv4/ipv6 packet processing. As this is only useful to restrict locally terminating TCP/UDP traffic, register this for ipv4 and ipv6 family only. Pablo points out that this is a general issue, direct users of the set/getsockopt interface can call into targets/matches that were only intended for use with ip(6)tables. Check all UNSPEC matches and targets for similar issues: - matches and targets are fine except if they assume skb_network_header() is valid -- this is only true when called from inet layer: ip(6) stack pulls the ip/ipv6 header into linear data area. - targets that return XT_CONTINUE or other xtables verdicts must be restricted too, they are incompatbile with the ebtables traverser, e.g. EBT_CONTINUE is a completely different value than XT_CONTINUE. Most matches/targets are changed to register for NFPROTO_IPV4/IPV6, as they are provided for use by ip(6)tables. The MARK target is also used by arptables, so register for NFPROTO_ARP too. While at it, bail out if connbytes fails to enable the corresponding conntrack family. This change passes the selftests in iptables.git.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50039", "url": "https://ubuntu.com/security/CVE-2024-50039", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: accept TCA_STAB only for root qdisc Most qdiscs maintain their backlog using qdisc_pkt_len(skb) on the assumption it is invariant between the enqueue() and dequeue() handlers. Unfortunately syzbot can crash a host rather easily using a TBF + SFQ combination, with an STAB on SFQ [1] We can't support TCA_STAB on arbitrary level, this would require to maintain per-qdisc storage. [1] [ 88.796496] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 88.798611] #PF: supervisor read access in kernel mode [ 88.799014] #PF: error_code(0x0000) - not-present page [ 88.799506] PGD 0 P4D 0 [ 88.799829] Oops: Oops: 0000 [#1] SMP NOPTI [ 88.800569] CPU: 14 UID: 0 PID: 2053 Comm: b371744477 Not tainted 6.12.0-rc1-virtme #1117 [ 88.801107] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 88.801779] RIP: 0010:sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq [ 88.802544] Code: 0f b7 50 12 48 8d 04 d5 00 00 00 00 48 89 d6 48 29 d0 48 8b 91 c0 01 00 00 48 c1 e0 03 48 01 c2 66 83 7a 1a 00 7e c0 48 8b 3a <4c> 8b 07 4c 89 02 49 89 50 08 48 c7 47 08 00 00 00 00 48 c7 07 00 All code ======== 0:\t0f b7 50 12 \tmovzwl 0x12(%rax),%edx 4:\t48 8d 04 d5 00 00 00 \tlea 0x0(,%rdx,8),%rax b:\t00 c:\t48 89 d6 \tmov %rdx,%rsi f:\t48 29 d0 \tsub %rdx,%rax 12:\t48 8b 91 c0 01 00 00 \tmov 0x1c0(%rcx),%rdx 19:\t48 c1 e0 03 \tshl $0x3,%rax 1d:\t48 01 c2 \tadd %rax,%rdx 20:\t66 83 7a 1a 00 \tcmpw $0x0,0x1a(%rdx) 25:\t7e c0 \tjle 0xffffffffffffffe7 27:\t48 8b 3a \tmov (%rdx),%rdi 2a:*\t4c 8b 07 \tmov (%rdi),%r8\t\t<-- trapping instruction 2d:\t4c 89 02 \tmov %r8,(%rdx) 30:\t49 89 50 08 \tmov %rdx,0x8(%r8) 34:\t48 c7 47 08 00 00 00 \tmovq $0x0,0x8(%rdi) 3b:\t00 3c:\t48 \trex.W 3d:\tc7 \t.byte 0xc7 3e:\t07 \t(bad) \t... Code starting with the faulting instruction =========================================== 0:\t4c 8b 07 \tmov (%rdi),%r8 3:\t4c 89 02 \tmov %r8,(%rdx) 6:\t49 89 50 08 \tmov %rdx,0x8(%r8) a:\t48 c7 47 08 00 00 00 \tmovq $0x0,0x8(%rdi) 11:\t00 12:\t48 \trex.W 13:\tc7 \t.byte 0xc7 14:\t07 \t(bad) \t... [ 88.803721] RSP: 0018:ffff9a1f892b7d58 EFLAGS: 00000206 [ 88.804032] RAX: 0000000000000000 RBX: ffff9a1f8420c800 RCX: ffff9a1f8420c800 [ 88.804560] RDX: ffff9a1f81bc1440 RSI: 0000000000000000 RDI: 0000000000000000 [ 88.805056] RBP: ffffffffc04bb0e0 R08: 0000000000000001 R09: 00000000ff7f9a1f [ 88.805473] R10: 000000000001001b R11: 0000000000009a1f R12: 0000000000000140 [ 88.806194] R13: 0000000000000001 R14: ffff9a1f886df400 R15: ffff9a1f886df4ac [ 88.806734] FS: 00007f445601a740(0000) GS:ffff9a2e7fd80000(0000) knlGS:0000000000000000 [ 88.807225] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 88.807672] CR2: 0000000000000000 CR3: 000000050cc46000 CR4: 00000000000006f0 [ 88.808165] Call Trace: [ 88.808459] [ 88.808710] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434) [ 88.809261] ? page_fault_oops (arch/x86/mm/fault.c:715) [ 88.809561] ? exc_page_fault (./arch/x86/include/asm/irqflags.h:26 ./arch/x86/include/asm/irqflags.h:87 ./arch/x86/include/asm/irqflags.h:147 arch/x86/mm/fault.c:1489 arch/x86/mm/fault.c:1539) [ 88.809806] ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623) [ 88.810074] ? sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq [ 88.810411] sfq_reset (net/sched/sch_sfq.c:525) sch_sfq [ 88.810671] qdisc_reset (./include/linux/skbuff.h:2135 ./include/linux/skbuff.h:2441 ./include/linux/skbuff.h:3304 ./include/linux/skbuff.h:3310 net/sched/sch_g ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50040", "url": "https://ubuntu.com/security/CVE-2024-50040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: igb: Do not bring the device up after non-fatal error Commit 004d25060c78 (\"igb: Fix igb_down hung on surprise removal\") changed igb_io_error_detected() to ignore non-fatal pcie errors in order to avoid hung task that can happen when igb_down() is called multiple times. This caused an issue when processing transient non-fatal errors. igb_io_resume(), which is called after igb_io_error_detected(), assumes that device is brought down by igb_io_error_detected() if the interface is up. This resulted in panic with stacktrace below. [ T3256] igb 0000:09:00.0 haeth0: igb: haeth0 NIC Link is Down [ T292] pcieport 0000:00:1c.5: AER: Uncorrected (Non-Fatal) error received: 0000:09:00.0 [ T292] igb 0000:09:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, (Requester ID) [ T292] igb 0000:09:00.0: device [8086:1537] error status/mask=00004000/00000000 [ T292] igb 0000:09:00.0: [14] CmpltTO [ 200.105524,009][ T292] igb 0000:09:00.0: AER: TLP Header: 00000000 00000000 00000000 00000000 [ T292] pcieport 0000:00:1c.5: AER: broadcast error_detected message [ T292] igb 0000:09:00.0: Non-correctable non-fatal error reported. [ T292] pcieport 0000:00:1c.5: AER: broadcast mmio_enabled message [ T292] pcieport 0000:00:1c.5: AER: broadcast resume message [ T292] ------------[ cut here ]------------ [ T292] kernel BUG at net/core/dev.c:6539! [ T292] invalid opcode: 0000 [#1] PREEMPT SMP [ T292] RIP: 0010:napi_enable+0x37/0x40 [ T292] Call Trace: [ T292] [ T292] ? die+0x33/0x90 [ T292] ? do_trap+0xdc/0x110 [ T292] ? napi_enable+0x37/0x40 [ T292] ? do_error_trap+0x70/0xb0 [ T292] ? napi_enable+0x37/0x40 [ T292] ? napi_enable+0x37/0x40 [ T292] ? exc_invalid_op+0x4e/0x70 [ T292] ? napi_enable+0x37/0x40 [ T292] ? asm_exc_invalid_op+0x16/0x20 [ T292] ? napi_enable+0x37/0x40 [ T292] igb_up+0x41/0x150 [ T292] igb_io_resume+0x25/0x70 [ T292] report_resume+0x54/0x70 [ T292] ? report_frozen_detected+0x20/0x20 [ T292] pci_walk_bus+0x6c/0x90 [ T292] ? aer_print_port_info+0xa0/0xa0 [ T292] pcie_do_recovery+0x22f/0x380 [ T292] aer_process_err_devices+0x110/0x160 [ T292] aer_isr+0x1c1/0x1e0 [ T292] ? disable_irq_nosync+0x10/0x10 [ T292] irq_thread_fn+0x1a/0x60 [ T292] irq_thread+0xe3/0x1a0 [ T292] ? irq_set_affinity_notifier+0x120/0x120 [ T292] ? irq_affinity_notify+0x100/0x100 [ T292] kthread+0xe2/0x110 [ T292] ? kthread_complete_and_exit+0x20/0x20 [ T292] ret_from_fork+0x2d/0x50 [ T292] ? kthread_complete_and_exit+0x20/0x20 [ T292] ret_from_fork_asm+0x11/0x20 [ T292] To fix this issue igb_io_resume() checks if the interface is running and the device is not down this means igb_io_error_detected() did not bring the device down and there is no need to bring it up.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50041", "url": "https://ubuntu.com/security/CVE-2024-50041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: Fix macvlan leak by synchronizing access to mac_filter_hash This patch addresses a macvlan leak issue in the i40e driver caused by concurrent access to vsi->mac_filter_hash. The leak occurs when multiple threads attempt to modify the mac_filter_hash simultaneously, leading to inconsistent state and potential memory leaks. To fix this, we now wrap the calls to i40e_del_mac_filter() and zeroing vf->default_lan_addr.addr with spin_lock/unlock_bh(&vsi->mac_filter_hash_lock), ensuring atomic operations and preventing concurrent access. Additionally, we add lockdep_assert_held(&vsi->mac_filter_hash_lock) in i40e_add_mac_filter() to help catch similar issues in the future. Reproduction steps: 1. Spawn VFs and configure port vlan on them. 2. Trigger concurrent macvlan operations (e.g., adding and deleting \tportvlan and/or mac filters). 3. Observe the potential memory leak and inconsistent state in the \tmac_filter_hash. This synchronization ensures the integrity of the mac_filter_hash and prevents the described leak.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50042", "url": "https://ubuntu.com/security/CVE-2024-50042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix increasing MSI-X on VF Increasing MSI-X value on a VF leads to invalid memory operations. This is caused by not reallocating some arrays. Reproducer: modprobe ice echo 0 > /sys/bus/pci/devices/$PF_PCI/sriov_drivers_autoprobe echo 1 > /sys/bus/pci/devices/$PF_PCI/sriov_numvfs echo 17 > /sys/bus/pci/devices/$VF0_PCI/sriov_vf_msix_count Default MSI-X is 16, so 17 and above triggers this issue. KASAN reports: BUG: KASAN: slab-out-of-bounds in ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] Read of size 8 at addr ffff8888b937d180 by task bash/28433 (...) Call Trace: (...) ? ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] kasan_report+0xed/0x120 ? ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] ice_vsi_cfg_def+0x3360/0x4770 [ice] ? mutex_unlock+0x83/0xd0 ? __pfx_ice_vsi_cfg_def+0x10/0x10 [ice] ? __pfx_ice_remove_vsi_lkup_fltr+0x10/0x10 [ice] ice_vsi_cfg+0x7f/0x3b0 [ice] ice_vf_reconfig_vsi+0x114/0x210 [ice] ice_sriov_set_msix_vec_count+0x3d0/0x960 [ice] sriov_vf_msix_count_store+0x21c/0x300 (...) Allocated by task 28201: (...) ice_vsi_cfg_def+0x1c8e/0x4770 [ice] ice_vsi_cfg+0x7f/0x3b0 [ice] ice_vsi_setup+0x179/0xa30 [ice] ice_sriov_configure+0xcaa/0x1520 [ice] sriov_numvfs_store+0x212/0x390 (...) To fix it, use ice_vsi_rebuild() instead of ice_vf_reconfig_vsi(). This causes the required arrays to be reallocated taking the new queue count into account (ice_vsi_realloc_stat_arrays()). Set req_txq and req_rxq before ice_vsi_rebuild(), so that realloc uses the newly set queue count. Additionally, ice_vsi_rebuild() does not remove VSI filters (ice_fltr_remove_all()), so ice_vf_init_host_cfg() is no longer necessary.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50093", "url": "https://ubuntu.com/security/CVE-2024-50093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: intel: int340x: processor: Fix warning during module unload The processor_thermal driver uses pcim_device_enable() to enable a PCI device, which means the device will be automatically disabled on driver detach. Thus there is no need to call pci_disable_device() again on it. With recent PCI device resource management improvements, e.g. commit f748a07a0b64 (\"PCI: Remove legacy pcim_release()\"), this problem is exposed and triggers the warining below. [ 224.010735] proc_thermal_pci 0000:00:04.0: disabling already-disabled device [ 224.010747] WARNING: CPU: 8 PID: 4442 at drivers/pci/pci.c:2250 pci_disable_device+0xe5/0x100 ... [ 224.010844] Call Trace: [ 224.010845] [ 224.010847] ? show_regs+0x6d/0x80 [ 224.010851] ? __warn+0x8c/0x140 [ 224.010854] ? pci_disable_device+0xe5/0x100 [ 224.010856] ? report_bug+0x1c9/0x1e0 [ 224.010859] ? handle_bug+0x46/0x80 [ 224.010862] ? exc_invalid_op+0x1d/0x80 [ 224.010863] ? asm_exc_invalid_op+0x1f/0x30 [ 224.010867] ? pci_disable_device+0xe5/0x100 [ 224.010869] ? pci_disable_device+0xe5/0x100 [ 224.010871] ? kfree+0x21a/0x2b0 [ 224.010873] pcim_disable_device+0x20/0x30 [ 224.010875] devm_action_release+0x16/0x20 [ 224.010878] release_nodes+0x47/0xc0 [ 224.010880] devres_release_all+0x9f/0xe0 [ 224.010883] device_unbind_cleanup+0x12/0x80 [ 224.010885] device_release_driver_internal+0x1ca/0x210 [ 224.010887] driver_detach+0x4e/0xa0 [ 224.010889] bus_remove_driver+0x6f/0xf0 [ 224.010890] driver_unregister+0x35/0x60 [ 224.010892] pci_unregister_driver+0x44/0x90 [ 224.010894] proc_thermal_pci_driver_exit+0x14/0x5f0 [processor_thermal_device_pci] ... [ 224.010921] ---[ end trace 0000000000000000 ]--- Remove the excess pci_disable_device() calls. [ rjw: Subject and changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50043", "url": "https://ubuntu.com/security/CVE-2024-50043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix possible badness in FREE_STATEID When multiple FREE_STATEIDs are sent for the same delegation stateid, it can lead to a possible either use-after-free or counter refcount underflow errors. In nfsd4_free_stateid() under the client lock we find a delegation stateid, however the code drops the lock before calling nfs4_put_stid(), that allows another FREE_STATE to find the stateid again. The first one will proceed to then free the stateid which leads to either use-after-free or decrementing already zeroed counter.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50044", "url": "https://ubuntu.com/security/CVE-2024-50044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change rfcomm_sk_state_change attempts to use sock_lock so it must never be called with it locked but rfcomm_sock_ioctl always attempt to lock it causing the following trace: ====================================================== WARNING: possible circular locking dependency detected 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Not tainted ------------------------------------------------------ syz-executor386/5093 is trying to acquire lock: ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1671 [inline] ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73 but task is already holding lock: ffff88807badfd28 (&d->lock){+.+.}-{3:3}, at: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50045", "url": "https://ubuntu.com/security/CVE-2024-50045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: br_netfilter: fix panic with metadata_dst skb Fix a kernel panic in the br_netfilter module when sending untagged traffic via a VxLAN device. This happens during the check for fragmentation in br_nf_dev_queue_xmit. It is dependent on: 1) the br_netfilter module being loaded; 2) net.bridge.bridge-nf-call-iptables set to 1; 3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port; 4) untagged frames with size higher than the VxLAN MTU forwarded/flooded When forwarding the untagged packet to the VxLAN bridge port, before the netfilter hooks are called, br_handle_egress_vlan_tunnel is called and changes the skb_dst to the tunnel dst. The tunnel_dst is a metadata type of dst, i.e., skb_valid_dst(skb) is false, and metadata->dst.dev is NULL. Then in the br_netfilter hooks, in br_nf_dev_queue_xmit, there's a check for frames that needs to be fragmented: frames with higher MTU than the VxLAN device end up calling br_nf_ip_fragment, which in turns call ip_skb_dst_mtu. The ip_dst_mtu tries to use the skb_dst(skb) as if it was a valid dst with valid dst->dev, thus the crash. This case was never supported in the first place, so drop the packet instead. PING 10.0.0.2 (10.0.0.2) from 0.0.0.0 h1-eth0: 2000(2028) bytes of data. [ 176.291791] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000110 [ 176.292101] Mem abort info: [ 176.292184] ESR = 0x0000000096000004 [ 176.292322] EC = 0x25: DABT (current EL), IL = 32 bits [ 176.292530] SET = 0, FnV = 0 [ 176.292709] EA = 0, S1PTW = 0 [ 176.292862] FSC = 0x04: level 0 translation fault [ 176.293013] Data abort info: [ 176.293104] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 176.293488] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 176.293787] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 176.293995] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043ef5000 [ 176.294166] [0000000000000110] pgd=0000000000000000, p4d=0000000000000000 [ 176.294827] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 176.295252] Modules linked in: vxlan ip6_udp_tunnel udp_tunnel veth br_netfilter bridge stp llc ipv6 crct10dif_ce [ 176.295923] CPU: 0 PID: 188 Comm: ping Not tainted 6.8.0-rc3-g5b3fbd61b9d1 #2 [ 176.296314] Hardware name: linux,dummy-virt (DT) [ 176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 176.296808] pc : br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.297382] lr : br_nf_dev_queue_xmit+0x2ac/0x4ec [br_netfilter] [ 176.297636] sp : ffff800080003630 [ 176.297743] x29: ffff800080003630 x28: 0000000000000008 x27: ffff6828c49ad9f8 [ 176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24: 00000000000003e8 [ 176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21: ffff6828c3b16d28 [ 176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18: 0000000000000014 [ 176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15: 0000000095744632 [ 176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12: ffffb7e137926a70 [ 176.299574] x11: 0000000000000001 x10: ffff6828c3f1c898 x9 : 0000000000000000 [ 176.300049] x8 : ffff6828c49bf070 x7 : 0008460f18d5f20e x6 : f20e0100bebafeca [ 176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 : 0000000000000000 [ 176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 : ffff6828c7f918f0 [ 176.300889] Call trace: [ 176.301123] br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.301411] br_nf_post_routing+0x2a8/0x3e4 [br_netfilter] [ 176.301703] nf_hook_slow+0x48/0x124 [ 176.302060] br_forward_finish+0xc8/0xe8 [bridge] [ 176.302371] br_nf_hook_thresh+0x124/0x134 [br_netfilter] [ 176.302605] br_nf_forward_finish+0x118/0x22c [br_netfilter] [ 176.302824] br_nf_forward_ip.part.0+0x264/0x290 [br_netfilter] [ 176.303136] br_nf_forward+0x2b8/0x4e0 [br_netfilter] [ 176.303359] nf_hook_slow+0x48/0x124 [ 176.303 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50094", "url": "https://ubuntu.com/security/CVE-2024-50094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sfc: Don't invoke xdp_do_flush() from netpoll. Yury reported a crash in the sfc driver originated from netpoll_send_udp(). The netconsole sends a message and then netpoll invokes the driver's NAPI function with a budget of zero. It is dedicated to allow driver to free TX resources, that it may have used while sending the packet. In the netpoll case the driver invokes xdp_do_flush() unconditionally, leading to crash because bpf_net_context was never assigned. Invoke xdp_do_flush() only if budget is not zero.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50188", "url": "https://ubuntu.com/security/CVE-2024-50188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: dp83869: fix memory corruption when enabling fiber When configuring the fiber port, the DP83869 PHY driver incorrectly calls linkmode_set_bit() with a bit mask (1 << 10) rather than a bit number (10). This corrupts some other memory location -- in case of arm64 the priv pointer in the same structure. Since the advertising flags are updated from supported at the end of the function the incorrect line isn't needed at all and can be removed.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50046", "url": "https://ubuntu.com/security/CVE-2024-50046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies() On the node of an NFS client, some files saved in the mountpoint of the NFS server were copied to another location of the same NFS server. Accidentally, the nfs42_complete_copies() got a NULL-pointer dereference crash with the following syslog: [232064.838881] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232064.839360] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232066.588183] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 [232066.588586] Mem abort info: [232066.588701] ESR = 0x0000000096000007 [232066.588862] EC = 0x25: DABT (current EL), IL = 32 bits [232066.589084] SET = 0, FnV = 0 [232066.589216] EA = 0, S1PTW = 0 [232066.589340] FSC = 0x07: level 3 translation fault [232066.589559] Data abort info: [232066.589683] ISV = 0, ISS = 0x00000007 [232066.589842] CM = 0, WnR = 0 [232066.589967] user pgtable: 64k pages, 48-bit VAs, pgdp=00002000956ff400 [232066.590231] [0000000000000058] pgd=08001100ae100003, p4d=08001100ae100003, pud=08001100ae100003, pmd=08001100b3c00003, pte=0000000000000000 [232066.590757] Internal error: Oops: 96000007 [#1] SMP [232066.590958] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm vhost_net vhost vhost_iotlb tap tun ipt_rpfilter xt_multiport ip_set_hash_ip ip_set_hash_net xfrm_interface xfrm6_tunnel tunnel4 tunnel6 esp4 ah4 wireguard libcurve25519_generic veth xt_addrtype xt_set nf_conntrack_netlink ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_bitmap_port ip_set_hash_ipport dummy ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs iptable_filter sch_ingress nfnetlink_cttimeout vport_gre ip_gre ip_tunnel gre vport_geneve geneve vport_vxlan vxlan ip6_udp_tunnel udp_tunnel openvswitch nf_conncount dm_round_robin dm_service_time dm_multipath xt_nat xt_MASQUERADE nft_chain_nat nf_nat xt_mark xt_conntrack xt_comment nft_compat nft_counter nf_tables nfnetlink ocfs2 ocfs2_nodemanager ocfs2_stackglue iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_ssif nbd overlay 8021q garp mrp bonding tls rfkill sunrpc ext4 mbcache jbd2 [232066.591052] vfat fat cas_cache cas_disk ses enclosure scsi_transport_sas sg acpi_ipmi ipmi_si ipmi_devintf ipmi_msghandler ip_tables vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio dm_mirror dm_region_hash dm_log dm_mod nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc fuse xfs libcrc32c ast drm_vram_helper qla2xxx drm_kms_helper syscopyarea crct10dif_ce sysfillrect ghash_ce sysimgblt sha2_ce fb_sys_fops cec sha256_arm64 sha1_ce drm_ttm_helper ttm nvme_fc igb sbsa_gwdt nvme_fabrics drm nvme_core i2c_algo_bit i40e scsi_transport_fc megaraid_sas aes_neon_bs [232066.596953] CPU: 6 PID: 4124696 Comm: 10.253.166.125- Kdump: loaded Not tainted 5.15.131-9.cl9_ocfs2.aarch64 #1 [232066.597356] Hardware name: Great Wall .\\x93\\x8e...RF6260 V5/GWMSSE2GL1T, BIOS T656FBE_V3.0.18 2024-01-06 [232066.597721] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [232066.598034] pc : nfs4_reclaim_open_state+0x220/0x800 [nfsv4] [232066.598327] lr : nfs4_reclaim_open_state+0x12c/0x800 [nfsv4] [232066.598595] sp : ffff8000f568fc70 [232066.598731] x29: ffff8000f568fc70 x28: 0000000000001000 x27: ffff21003db33000 [232066.599030] x26: ffff800005521ae0 x25: ffff0100f98fa3f0 x24: 0000000000000001 [232066.599319] x23: ffff800009920008 x22: ffff21003db33040 x21: ffff21003db33050 [232066.599628] x20: ffff410172fe9e40 x19: ffff410172fe9e00 x18: 0000000000000000 [232066.599914] x17: 0000000000000000 x16: 0000000000000004 x15: 0000000000000000 [232066.600195] x14: 0000000000000000 x13: ffff800008e685a8 x12: 00000000eac0c6e6 [232066.600498] x11: 00000000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50190", "url": "https://ubuntu.com/security/CVE-2024-50190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix memleak in ice_init_tx_topology() Fix leak of the FW blob (DDP pkg). Make ice_cfg_tx_topo() const-correct, so ice_init_tx_topology() can avoid copying whole FW blob. Copy just the topology section, and only when needed. Reuse the buffer allocated for the read of the current topology. This was found by kmemleak, with the following trace for each PF: [] kmemdup_noprof+0x1d/0x50 [] ice_init_ddp_config+0x100/0x220 [ice] [] ice_init_dev+0x6f/0x200 [ice] [] ice_init+0x29/0x560 [ice] [] ice_probe+0x21d/0x310 [ice] Constify ice_cfg_tx_topo() @buf parameter. This cascades further down to few more functions.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50180", "url": "https://ubuntu.com/security/CVE-2024-50180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: sisfb: Fix strbuf array overflow The values of the variables xres and yres are placed in strbuf. These variables are obtained from strbuf1. The strbuf1 array contains digit characters and a space if the array contains non-digit characters. Then, when executing sprintf(strbuf, \"%ux%ux8\", xres, yres); more than 16 bytes will be written to strbuf. It is suggested to increase the size of the strbuf array to 24. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06: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": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50048", "url": "https://ubuntu.com/security/CVE-2024-50048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: Fix a NULL pointer dereference issue in fbcon_putcs syzbot has found a NULL pointer dereference bug in fbcon. Here is the simplified C reproducer: struct param { \tuint8_t type; \tstruct tiocl_selection ts; }; int main() { \tstruct fb_con2fbmap con2fb; \tstruct param param; \tint fd = open(\"/dev/fb1\", 0, 0); \tcon2fb.console = 0x19; \tcon2fb.framebuffer = 0; \tioctl(fd, FBIOPUT_CON2FBMAP, &con2fb); \tparam.type = 2; \tparam.ts.xs = 0; param.ts.ys = 0; \tparam.ts.xe = 0; param.ts.ye = 0; \tparam.ts.sel_mode = 0; \tint fd1 = open(\"/dev/tty1\", O_RDWR, 0); \tioctl(fd1, TIOCLINUX, ¶m); \tcon2fb.console = 1; \tcon2fb.framebuffer = 0; \tioctl(fd, FBIOPUT_CON2FBMAP, &con2fb); \treturn 0; } After calling ioctl(fd1, TIOCLINUX, ¶m), the subsequent ioctl(fd, FBIOPUT_CON2FBMAP, &con2fb) causes the kernel to follow a different execution path: set_con2fb_map -> con2fb_init_display -> fbcon_set_disp -> redraw_screen -> hide_cursor -> clear_selection -> highlight -> invert_screen -> do_update_region -> fbcon_putcs -> ops->putcs Since ops->putcs is a NULL pointer, this leads to a kernel panic. To prevent this, we need to call set_blitting_type() within set_con2fb_map() to properly initialize ops->putcs.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50049", "url": "https://ubuntu.com/security/CVE-2024-50049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before dereferencing se [WHAT & HOW] se is null checked previously in the same function, indicating it might be null; therefore, it must be checked when used again. This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50090", "url": "https://ubuntu.com/security/CVE-2024-50090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/oa: Fix overflow in oa batch buffer By default xe_bb_create_job() appends a MI_BATCH_BUFFER_END to batch buffer, this is not a problem if batch buffer is only used once but oa reuses the batch buffer for the same metric and at each call it appends a MI_BATCH_BUFFER_END, printing the warning below and then overflowing. [ 381.072016] ------------[ cut here ]------------ [ 381.072019] xe 0000:00:02.0: [drm] Assertion `bb->len * 4 + bb_prefetch(q->gt) <= size` failed! platform: LUNARLAKE subplatform: 1 graphics: Xe2_LPG / Xe2_HPG 20.04 step B0 media: Xe2_LPM / Xe2_HPM 20.00 step B0 tile: 0 VRAM 0 B GT: 0 type 1 So here checking if batch buffer already have MI_BATCH_BUFFER_END if not append it. v2: - simply fix, suggestion from Ashutosh (cherry picked from commit 9ba0e0f30ca42a98af3689460063edfb6315718a)", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50183", "url": "https://ubuntu.com/security/CVE-2024-50183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV instance Deleting an NPIV instance requires all fabric ndlps to be released before an NPIV's resources can be torn down. Failure to release fabric ndlps beforehand opens kref imbalance race conditions. Fix by forcing the DA_ID to complete synchronously with usage of wait_queue.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50055", "url": "https://ubuntu.com/security/CVE-2024-50055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: driver core: bus: Fix double free in driver API bus_register() For bus_register(), any error which happens after kset_register() will cause that @priv are freed twice, fixed by setting @priv with NULL after the first free.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50091", "url": "https://ubuntu.com/security/CVE-2024-50091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm vdo: don't refer to dedupe_context after releasing it Clear the dedupe_context pointer in a data_vio whenever ownership of the context is lost, so that vdo can't examine it accidentally.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50056", "url": "https://ubuntu.com/security/CVE-2024-50056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: Fix ERR_PTR dereference in uvc_v4l2.c Fix potential dereferencing of ERR_PTR() in find_format_by_pix() and uvc_v4l2_enum_format(). Fix the following smatch errors: drivers/usb/gadget/function/uvc_v4l2.c:124 find_format_by_pix() error: 'fmtdesc' dereferencing possible ERR_PTR() drivers/usb/gadget/function/uvc_v4l2.c:392 uvc_v4l2_enum_format() error: 'fmtdesc' dereferencing possible ERR_PTR() Also, fix similar issue in uvc_v4l2_try_format() for potential dereferencing of ERR_PTR().", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50184", "url": "https://ubuntu.com/security/CVE-2024-50184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_pmem: Check device status before requesting flush If a pmem device is in a bad status, the driver side could wait for host ack forever in virtio_pmem_flush(), causing the system to hang. So add a status check in the beginning of virtio_pmem_flush() to return early if the device is not activated.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50057", "url": "https://ubuntu.com/security/CVE-2024-50057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: tipd: Free IRQ only if it was requested before In polling mode, if no IRQ was requested there is no need to free it. Call devm_free_irq() only if client->irq is set. This fixes the warning caused by the tps6598x module removal: WARNING: CPU: 2 PID: 333 at kernel/irq/devres.c:144 devm_free_irq+0x80/0x8c ... ... Call trace: devm_free_irq+0x80/0x8c tps6598x_remove+0x28/0x88 [tps6598x] i2c_device_remove+0x2c/0x9c device_remove+0x4c/0x80 device_release_driver_internal+0x1cc/0x228 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 i2c_del_driver+0x54/0x64 tps6598x_i2c_driver_exit+0x18/0xc3c [tps6598x] __arm64_sys_delete_module+0x184/0x264 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc8/0xe8 do_el0_svc+0x20/0x2c el0_svc+0x28/0x98 el0t_64_sync_handler+0x13c/0x158 el0t_64_sync+0x190/0x194", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50058", "url": "https://ubuntu.com/security/CVE-2024-50058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: protect uart_port_dtr_rts() in uart_shutdown() too Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part 3) added few uport == NULL checks. It added one to uart_shutdown(), so the commit assumes, uport can be NULL in there. But right after that protection, there is an unprotected \"uart_port_dtr_rts(uport, false);\" call. That is invoked only if HUPCL is set, so I assume that is the reason why we do not see lots of these reports. Or it cannot be NULL at this point at all for some reason :P. Until the above is investigated, stay on the safe side and move this dereference to the if too. I got this inconsistency from Coverity under CID 1585130. Thanks.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50181", "url": "https://ubuntu.com/security/CVE-2024-50181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: imx: Remove CLK_SET_PARENT_GATE for DRAM mux for i.MX7D For i.MX7D DRAM related mux clock, the clock source change should ONLY be done done in low level asm code without accessing DRAM, and then calling clk API to sync the HW clock status with clk tree, it should never touch real clock source switch via clk API, so CLK_SET_PARENT_GATE flag should NOT be added, otherwise, DRAM's clock parent will be disabled when DRAM is active, and system will hang.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50059", "url": "https://ubuntu.com/security/CVE-2024-50059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntb: ntb_hw_switchtec: Fix use after free vulnerability in switchtec_ntb_remove due to race condition In the switchtec_ntb_add function, it can call switchtec_ntb_init_sndev function, then &sndev->check_link_status_work is bound with check_link_status_work. switchtec_ntb_link_notification may be called to start the work. If we remove the module which will call switchtec_ntb_remove to make cleanup, it will free sndev through kfree(sndev), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | check_link_status_work switchtec_ntb_remove | kfree(sndev); | | if (sndev->link_force_down) | // use sndev Fix it by ensuring that the work is canceled before proceeding with the cleanup in switchtec_ntb_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50060", "url": "https://ubuntu.com/security/CVE-2024-50060", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring: check if we need to reschedule during overflow flush In terms of normal application usage, this list will always be empty. And if an application does overflow a bit, it'll have a few entries. However, nothing obviously prevents syzbot from running a test case that generates a ton of overflow entries, and then flushing them can take quite a while. Check for needing to reschedule while flushing, and drop our locks and do so if necessary. There's no state to maintain here as overflows always prune from head-of-list, hence it's fine to drop and reacquire the locks at the end of the loop.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50061", "url": "https://ubuntu.com/security/CVE-2024-50061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: cdns: Fix use after free vulnerability in cdns_i3c_master Driver Due to Race Condition In the cdns_i3c_master_probe function, &master->hj_work is bound with cdns_i3c_master_hj. And cdns_i3c_master_interrupt can call cnds_i3c_master_demux_ibis function to start the work. If we remove the module which will call cdns_i3c_master_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | cdns_i3c_master_hj cdns_i3c_master_remove | i3c_master_unregister(&master->base) | device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in cdns_i3c_master_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50062", "url": "https://ubuntu.com/security/CVE-2024-50062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-srv: Avoid null pointer deref during path establishment For RTRS path establishment, RTRS client initiates and completes con_num of connections. After establishing all its connections, the information is exchanged between the client and server through the info_req message. During this exchange, it is essential that all connections have been established, and the state of the RTRS srv path is CONNECTED. So add these sanity checks, to make sure we detect and abort process in error scenarios to avoid null pointer deref.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50095", "url": "https://ubuntu.com/security/CVE-2024-50095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mad: Improve handling of timed out WRs of mad agent Current timeout handler of mad agent acquires/releases mad_agent_priv lock for every timed out WRs. This causes heavy locking contention when higher no. of WRs are to be handled inside timeout handler. This leads to softlockup with below trace in some use cases where rdma-cm path is used to establish connection between peer nodes Trace: ----- BUG: soft lockup - CPU#4 stuck for 26s! [kworker/u128:3:19767] CPU: 4 PID: 19767 Comm: kworker/u128:3 Kdump: loaded Tainted: G OE ------- --- 5.14.0-427.13.1.el9_4.x86_64 #1 Hardware name: Dell Inc. PowerEdge R740/01YM03, BIOS 2.4.8 11/26/2019 Workqueue: ib_mad1 timeout_sends [ib_core] RIP: 0010:__do_softirq+0x78/0x2ac RSP: 0018:ffffb253449e4f98 EFLAGS: 00000246 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 000000000000001f RDX: 000000000000001d RSI: 000000003d1879ab RDI: fff363b66fd3a86b RBP: ffffb253604cbcd8 R08: 0000009065635f3b R09: 0000000000000000 R10: 0000000000000040 R11: ffffb253449e4ff8 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000040 FS: 0000000000000000(0000) GS:ffff8caa1fc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd9ec9db900 CR3: 0000000891934006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? __irq_exit_rcu+0xa1/0xc0 ? watchdog_timer_fn+0x1b2/0x210 ? __pfx_watchdog_timer_fn+0x10/0x10 ? __hrtimer_run_queues+0x127/0x2c0 ? hrtimer_interrupt+0xfc/0x210 ? __sysvec_apic_timer_interrupt+0x5c/0x110 ? sysvec_apic_timer_interrupt+0x37/0x90 ? asm_sysvec_apic_timer_interrupt+0x16/0x20 ? __do_softirq+0x78/0x2ac ? __do_softirq+0x60/0x2ac __irq_exit_rcu+0xa1/0xc0 sysvec_call_function_single+0x72/0x90 asm_sysvec_call_function_single+0x16/0x20 RIP: 0010:_raw_spin_unlock_irq+0x14/0x30 RSP: 0018:ffffb253604cbd88 EFLAGS: 00000247 RAX: 000000000001960d RBX: 0000000000000002 RCX: ffff8cad2a064800 RDX: 000000008020001b RSI: 0000000000000001 RDI: ffff8cad5d39f66c RBP: ffff8cad5d39f600 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8caa443e0c00 R11: ffffb253604cbcd8 R12: ffff8cacb8682538 R13: 0000000000000005 R14: ffffb253604cbd90 R15: ffff8cad5d39f66c cm_process_send_error+0x122/0x1d0 [ib_cm] timeout_sends+0x1dd/0x270 [ib_core] process_one_work+0x1e2/0x3b0 ? __pfx_worker_thread+0x10/0x10 worker_thread+0x50/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xdd/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x50 Simplified timeout handler by creating local list of timed out WRs and invoke send handler post creating the list. The new method acquires/ releases lock once to fetch the list and hence helps to reduce locking contetiong when processing higher no. of WRs", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50063", "url": "https://ubuntu.com/security/CVE-2024-50063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Prevent tail call between progs attached to different hooks bpf progs can be attached to kernel functions, and the attached functions can take different parameters or return different return values. If prog attached to one kernel function tail calls prog attached to another kernel function, the ctx access or return value verification could be bypassed. For example, if prog1 is attached to func1 which takes only 1 parameter and prog2 is attached to func2 which takes two parameters. Since verifier assumes the bpf ctx passed to prog2 is constructed based on func2's prototype, verifier allows prog2 to access the second parameter from the bpf ctx passed to it. The problem is that verifier does not prevent prog1 from passing its bpf ctx to prog2 via tail call. In this case, the bpf ctx passed to prog2 is constructed from func1 instead of func2, that is, the assumption for ctx access verification is bypassed. Another example, if BPF LSM prog1 is attached to hook file_alloc_security, and BPF LSM prog2 is attached to hook bpf_lsm_audit_rule_known. Verifier knows the return value rules for these two hooks, e.g. it is legal for bpf_lsm_audit_rule_known to return positive number 1, and it is illegal for file_alloc_security to return positive number. So verifier allows prog2 to return positive number 1, but does not allow prog1 to return positive number. The problem is that verifier does not prevent prog1 from calling prog2 via tail call. In this case, prog2's return value 1 will be used as the return value for prog1's hook file_alloc_security. That is, the return value rule is bypassed. This patch adds restriction for tail call to prevent such bypasses.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50191", "url": "https://ubuntu.com/security/CVE-2024-50191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: don't set SB_RDONLY after filesystem errors When the filesystem is mounted with errors=remount-ro, we were setting SB_RDONLY flag to stop all filesystem modifications. We knew this misses proper locking (sb->s_umount) and does not go through proper filesystem remount procedure but it has been the way this worked since early ext2 days and it was good enough for catastrophic situation damage mitigation. Recently, syzbot has found a way (see link) to trigger warnings in filesystem freezing because the code got confused by SB_RDONLY changing under its hands. Since these days we set EXT4_FLAGS_SHUTDOWN on the superblock which is enough to stop all filesystem modifications, modifying SB_RDONLY shouldn't be needed. So stop doing that.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50064", "url": "https://ubuntu.com/security/CVE-2024-50064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: zram: free secondary algorithms names We need to kfree() secondary algorithms names when reset zram device that had multi-streams, otherwise we leak memory. [senozhatsky@chromium.org: kfree(NULL) is legal] Link: https://lkml.kernel.org/r/20240917013021.868769-1-senozhatsky@chromium.org", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50065", "url": "https://ubuntu.com/security/CVE-2024-50065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Change to non-blocking allocation in ntfs_d_hash d_hash is done while under \"rcu-walk\" and should not sleep. __get_name() allocates using GFP_KERNEL, having the possibility to sleep when under memory pressure. Change the allocation to GFP_NOWAIT.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50089", "url": "https://ubuntu.com/security/CVE-2024-50089", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-49863", "url": "https://ubuntu.com/security/CVE-2024-49863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost/scsi: null-ptr-dereference in vhost_scsi_get_req() Since commit 3f8ca2e115e5 (\"vhost/scsi: Extract common handling code from control queue handler\") a null pointer dereference bug can be triggered when guest sends an SCSI AN request. In vhost_scsi_ctl_handle_vq(), `vc.target` is assigned with `&v_req.tmf.lun[1]` within a switch-case block and is then passed to vhost_scsi_get_req() which extracts `vc->req` and `tpg`. However, for a `VIRTIO_SCSI_T_AN_*` request, tpg is not required, so `vc.target` is set to NULL in this branch. Later, in vhost_scsi_get_req(), `vc->target` is dereferenced without being checked, leading to a null pointer dereference bug. This bug can be triggered from guest. When this bug occurs, the vhost_worker process is killed while holding `vq->mutex` and the corresponding tpg will remain occupied indefinitely. Below is the KASAN report: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 PID: 840 Comm: poc Not tainted 6.10.0+ #1 Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:vhost_scsi_get_req+0x165/0x3a0 Code: 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 02 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 65 30 4c 89 e2 48 c1 ea 03 <0f> b6 04 02 4c 89 e2 83 e2 07 38 d0 7f 08 84 c0 0f 85 be 01 00 00 RSP: 0018:ffff888017affb50 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffff88801b000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888017affcb8 RBP: ffff888017affb80 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff888017affc88 R14: ffff888017affd1c R15: ffff888017993000 FS: 000055556e076500(0000) GS:ffff88806b100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200027c0 CR3: 0000000010ed0004 CR4: 0000000000370ef0 Call Trace: ? show_regs+0x86/0xa0 ? die_addr+0x4b/0xd0 ? exc_general_protection+0x163/0x260 ? asm_exc_general_protection+0x27/0x30 ? vhost_scsi_get_req+0x165/0x3a0 vhost_scsi_ctl_handle_vq+0x2a4/0xca0 ? __pfx_vhost_scsi_ctl_handle_vq+0x10/0x10 ? __switch_to+0x721/0xeb0 ? __schedule+0xda5/0x5710 ? __kasan_check_write+0x14/0x30 ? _raw_spin_lock+0x82/0xf0 vhost_scsi_ctl_handle_kick+0x52/0x90 vhost_run_work_list+0x134/0x1b0 vhost_task_fn+0x121/0x350 ... ---[ end trace 0000000000000000 ]--- Let's add a check in vhost_scsi_get_req. [whitespace fixes]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49864", "url": "https://ubuntu.com/security/CVE-2024-49864", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix a race between socket set up and I/O thread creation In rxrpc_open_socket(), it sets up the socket and then sets up the I/O thread that will handle it. This is a problem, however, as there's a gap between the two phases in which a packet may come into rxrpc_encap_rcv() from the UDP packet but we oops when trying to wake the not-yet created I/O thread. As a quick fix, just make rxrpc_encap_rcv() discard the packet if there's no I/O thread yet. A better, but more intrusive fix would perhaps be to rearrange things such that the socket creation is done by the I/O thread.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49865", "url": "https://ubuntu.com/security/CVE-2024-49865", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: move xa_alloc to prevent UAF Evil user can guess the next id of the vm before the ioctl completes and then call vm destroy ioctl to trigger UAF since create ioctl is still referencing the same vm. Move the xa_alloc all the way to the end to prevent this. v2: - Rebase (cherry picked from commit dcfd3971327f3ee92765154baebbaece833d3ca9)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49955", "url": "https://ubuntu.com/security/CVE-2024-49955", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: battery: Fix possible crash when unregistering a battery hook When a battery hook returns an error when adding a new battery, then the battery hook is automatically unregistered. However the battery hook provider cannot know that, so it will later call battery_hook_unregister() on the already unregistered battery hook, resulting in a crash. Fix this by using the list head to mark already unregistered battery hooks as already being unregistered so that they can be ignored by battery_hook_unregister().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49973", "url": "https://ubuntu.com/security/CVE-2024-49973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: r8169: add tally counter fields added with RTL8125 RTL8125 added fields to the tally counter, what may result in the chip dma'ing these new fields to unallocated memory. Therefore make sure that the allocated memory area is big enough to hold all of the tally counter values, even if we use only parts of it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49974", "url": "https://ubuntu.com/security/CVE-2024-49974", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Limit the number of concurrent async COPY operations Nothing appears to limit the number of concurrent async COPY operations that clients can start. In addition, AFAICT each async COPY can copy an unlimited number of 4MB chunks, so can run for a long time. Thus IMO async COPY can become a DoS vector. Add a restriction mechanism that bounds the number of concurrent background COPY operations. Start simple and try to be fair -- this patch implements a per-namespace limit. An async COPY request that occurs while this limit is exceeded gets NFS4ERR_DELAY. The requesting client can choose to send the request again after a delay or fall back to a traditional read/write style copy. If there is need to make the mechanism more sophisticated, we can visit that in future patches.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49975", "url": "https://ubuntu.com/security/CVE-2024-49975", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uprobes: fix kernel info leak via \"[uprobes]\" vma xol_add_vma() maps the uninitialized page allocated by __create_xol_area() into userspace. On some architectures (x86) this memory is readable even without VM_READ, VM_EXEC results in the same pgprot_t as VM_EXEC|VM_READ, although this doesn't really matter, debugger can read this memory anyway.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50003", "url": "https://ubuntu.com/security/CVE-2024-50003", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix system hang while resume with TBT monitor [Why] Connected with a Thunderbolt monitor and do the suspend and the system may hang while resume. The TBT monitor HPD will be triggered during the resume procedure and call the drm_client_modeset_probe() while struct drm_connector connector->dev->master is NULL. It will mess up the pipe topology after resume. [How] Skip the TBT monitor HPD during the resume procedure because we currently will probe the connectors after resume by default. (cherry picked from commit 453f86a26945207a16b8f66aaed5962dc2b95b85)", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50173", "url": "https://ubuntu.com/security/CVE-2024-50173", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix access to uninitialized variable in tick_ctx_cleanup() The group variable can't be used to retrieve ptdev in our second loop, because it points to the previously iterated list_head, not a valid group. Get the ptdev object from the scheduler instead.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49866", "url": "https://ubuntu.com/security/CVE-2024-49866", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Fix a race during cpuhp processing There is another found exception that the \"timerlat/1\" thread was scheduled on CPU0, and lead to timer corruption finally: ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ``` After tracing the scheduling event, it was discovered that the migration of the \"timerlat/1\" thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() | To fix this, skip online processing if the CPU is already offline.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49976", "url": "https://ubuntu.com/security/CVE-2024-49976", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Drop interface_lock in stop_kthread() stop_kthread() is the offline callback for \"trace/osnoise:online\", since commit 5bfbcd1ee57b (\"tracing/timerlat: Add interface_lock around clearing of kthread in stop_kthread()\"), the following ABBA deadlock scenario is introduced: T1 | T2 [BP] | T3 [AP] osnoise_hotplug_workfn() | work_for_cpu_fn() | cpuhp_thread_fun() | _cpu_down() | osnoise_cpu_die() mutex_lock(&interface_lock) | | stop_kthread() | cpus_write_lock() | mutex_lock(&interface_lock) cpus_read_lock() | cpuhp_kick_ap() | As the interface_lock here in just for protecting the \"kthread\" field of the osn_var, use xchg() instead to fix this issue. Also use for_each_online_cpu() back in stop_per_cpu_kthreads() as it can take cpu_read_lock() again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50005", "url": "https://ubuntu.com/security/CVE-2024-50005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: Fix potential RCU dereference issue in mac802154_scan_worker In the `mac802154_scan_worker` function, the `scan_req->type` field was accessed after the RCU read-side critical section was unlocked. According to RCU usage rules, this is illegal and can lead to unpredictable behavior, such as accessing memory that has been updated or causing use-after-free issues. This possible bug was identified using a static analysis tool developed by myself, specifically designed to detect RCU-related issues. To address this, the `scan_req->type` value is now stored in a local variable `scan_req_type` while still within the RCU read-side critical section. The `scan_req_type` is then used after the RCU lock is released, ensuring that the type value is safely accessed without violating RCU rules.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50012", "url": "https://ubuntu.com/security/CVE-2024-50012", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: Avoid a bad reference count on CPU node In the parse_perf_domain function, if the call to of_parse_phandle_with_args returns an error, then the reference to the CPU device node that was acquired at the start of the function would not be properly decremented. Address this by declaring the variable with the __free(device_node) cleanup attribute.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49867", "url": "https://ubuntu.com/security/CVE-2024-49867", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: wait for fixup workers before stopping cleaner kthread during umount During unmount, at close_ctree(), we have the following steps in this order: 1) Park the cleaner kthread - this doesn't destroy the kthread, it basically halts its execution (wake ups against it work but do nothing); 2) We stop the cleaner kthread - this results in freeing the respective struct task_struct; 3) We call btrfs_stop_all_workers() which waits for any jobs running in all the work queues and then free the work queues. Syzbot reported a case where a fixup worker resulted in a crash when doing a delayed iput on its inode while attempting to wake up the cleaner at btrfs_add_delayed_iput(), because the task_struct of the cleaner kthread was already freed. This can happen during unmount because we don't wait for any fixup workers still running before we call kthread_stop() against the cleaner kthread, which stops and free all its resources. Fix this by waiting for any fixup workers at close_ctree() before we call kthread_stop() against the cleaner and run pending delayed iputs. The stack traces reported by syzbot were the following: BUG: KASAN: slab-use-after-free in __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 Read of size 8 at addr ffff8880272a8a18 by task kworker/u8:3/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.12.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: btrfs-fixup btrfs_work_helper 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 __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline] try_to_wake_up+0xb0/0x1480 kernel/sched/core.c:4154 btrfs_writepage_fixup_worker+0xc16/0xdf0 fs/btrfs/inode.c:2842 btrfs_work_helper+0x390/0xc50 fs/btrfs/async-thread.c:314 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Allocated by task 2: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:319 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345 kasan_slab_alloc include/linux/kasan.h:247 [inline] slab_post_alloc_hook mm/slub.c:4086 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4187 alloc_task_struct_node kernel/fork.c:180 [inline] dup_task_struct+0x57/0x8c0 kernel/fork.c:1107 copy_process+0x5d1/0x3d50 kernel/fork.c:2206 kernel_clone+0x223/0x880 kernel/fork.c:2787 kernel_thread+0x1bc/0x240 kernel/fork.c:2849 create_kthread kernel/kthread.c:412 [inline] kthreadd+0x60d/0x810 kernel/kthread.c:765 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Freed by task 61: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:230 [inline] slab_free_h ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49868", "url": "https://ubuntu.com/security/CVE-2024-49868", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix a NULL pointer dereference when failed to start a new trasacntion [BUG] Syzbot reported a NULL pointer dereference with the following crash: FAULT_INJECTION: forcing a failure. start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676 prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642 relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678 ... BTRFS info (device loop0): balance: ended with status: -12 Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667] RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926 Call Trace: commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496 btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430 del_balance_item fs/btrfs/volumes.c:3678 [inline] reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742 btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574 btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673 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/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [CAUSE] The allocation failure happens at the start_transaction() inside prepare_to_relocate(), and during the error handling we call unset_reloc_control(), which makes fs_info->balance_ctl to be NULL. Then we continue the error path cleanup in btrfs_balance() by calling reset_balance_state() which will call del_balance_item() to fully delete the balance item in the root tree. However during the small window between set_reloc_contrl() and unset_reloc_control(), we can have a subvolume tree update and created a reloc_root for that subvolume. Then we go into the final btrfs_commit_transaction() of del_balance_item(), and into btrfs_update_reloc_root() inside commit_fs_roots(). That function checks if fs_info->reloc_ctl is in the merge_reloc_tree stage, but since fs_info->reloc_ctl is NULL, it results a NULL pointer dereference. [FIX] Just add extra check on fs_info->reloc_ctl inside btrfs_update_reloc_root(), before checking fs_info->reloc_ctl->merge_reloc_tree. That DEAD_RELOC_TREE handling is to prevent further modification to the reloc tree during merge stage, but since there is no reloc_ctl at all, we do not need to bother that.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49869", "url": "https://ubuntu.com/security/CVE-2024-49869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: send: fix buffer overflow detection when copying path to cache entry Starting with commit c0247d289e73 (\"btrfs: send: annotate struct name_cache_entry with __counted_by()\") we annotated the variable length array \"name\" from the name_cache_entry structure with __counted_by() to improve overflow detection. However that alone was not correct, because the length of that array does not match the \"name_len\" field - it matches that plus 1 to include the NUL string terminator, so that makes a fortified kernel think there's an overflow and report a splat like this: strcpy: detected buffer overflow: 20 byte write of buffer size 19 WARNING: CPU: 3 PID: 3310 at __fortify_report+0x45/0x50 CPU: 3 UID: 0 PID: 3310 Comm: btrfs Not tainted 6.11.0-prnet #1 Hardware name: CompuLab Ltd. sbc-ihsw/Intense-PC2 (IPC2), BIOS IPC2_3.330.7 X64 03/15/2018 RIP: 0010:__fortify_report+0x45/0x50 Code: 48 8b 34 (...) RSP: 0018:ffff97ebc0d6f650 EFLAGS: 00010246 RAX: 7749924ef60fa600 RBX: ffff8bf5446a521a RCX: 0000000000000027 RDX: 00000000ffffdfff RSI: ffff97ebc0d6f548 RDI: ffff8bf84e7a1cc8 RBP: ffff8bf548574080 R08: ffffffffa8c40e10 R09: 0000000000005ffd R10: 0000000000000004 R11: ffffffffa8c70e10 R12: ffff8bf551eef400 R13: 0000000000000000 R14: 0000000000000013 R15: 00000000000003a8 FS: 00007fae144de8c0(0000) GS:ffff8bf84e780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fae14691690 CR3: 00000001027a2003 CR4: 00000000001706f0 Call Trace: ? __warn+0x12a/0x1d0 ? __fortify_report+0x45/0x50 ? report_bug+0x154/0x1c0 ? handle_bug+0x42/0x70 ? exc_invalid_op+0x1a/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? __fortify_report+0x45/0x50 __fortify_panic+0x9/0x10 __get_cur_name_and_parent+0x3bc/0x3c0 get_cur_path+0x207/0x3b0 send_extent_data+0x709/0x10d0 ? find_parent_nodes+0x22df/0x25d0 ? mas_nomem+0x13/0x90 ? mtree_insert_range+0xa5/0x110 ? btrfs_lru_cache_store+0x5f/0x1e0 ? iterate_extent_inodes+0x52d/0x5a0 process_extent+0xa96/0x11a0 ? __pfx_lookup_backref_cache+0x10/0x10 ? __pfx_store_backref_cache+0x10/0x10 ? __pfx_iterate_backrefs+0x10/0x10 ? __pfx_check_extent_item+0x10/0x10 changed_cb+0x6fa/0x930 ? tree_advance+0x362/0x390 ? memcmp_extent_buffer+0xd7/0x160 send_subvol+0xf0a/0x1520 btrfs_ioctl_send+0x106b/0x11d0 ? __pfx___clone_root_cmp_sort+0x10/0x10 _btrfs_ioctl_send+0x1ac/0x240 btrfs_ioctl+0x75b/0x850 __se_sys_ioctl+0xca/0x150 do_syscall_64+0x85/0x160 ? __count_memcg_events+0x69/0x100 ? handle_mm_fault+0x1327/0x15c0 ? __se_sys_rt_sigprocmask+0xf1/0x180 ? syscall_exit_to_user_mode+0x75/0xa0 ? do_syscall_64+0x91/0x160 ? do_user_addr_fault+0x21d/0x630 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fae145eeb4f Code: 00 48 89 (...) RSP: 002b:00007ffdf1cb09b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fae145eeb4f RDX: 00007ffdf1cb0ad0 RSI: 0000000040489426 RDI: 0000000000000004 RBP: 00000000000078fe R08: 00007fae144006c0 R09: 00007ffdf1cb0927 R10: 0000000000000008 R11: 0000000000000246 R12: 00007ffdf1cb1ce8 R13: 0000000000000003 R14: 000055c499fab2e0 R15: 0000000000000004 Fix this by not storing the NUL string terminator since we don't actually need it for name cache entries, this way \"name_len\" corresponds to the actual size of the \"name\" array. This requires marking the \"name\" array field with __nonstring and using memcpy() instead of strcpy() as recommended by the guidelines at: https://github.com/KSPP/linux/issues/90", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49870", "url": "https://ubuntu.com/security/CVE-2024-49870", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cachefiles: fix dentry leak in cachefiles_open_file() A dentry leak may be caused when a lookup cookie and a cull are concurrent: P1 | P2 ----------------------------------------------------------- cachefiles_lookup_cookie cachefiles_look_up_object lookup_one_positive_unlocked // get dentry cachefiles_cull inode->i_flags |= S_KERNEL_FILE; cachefiles_open_file cachefiles_mark_inode_in_use __cachefiles_mark_inode_in_use can_use = false if (!(inode->i_flags & S_KERNEL_FILE)) can_use = true \t return false return false // Returns an error but doesn't put dentry After that the following WARNING will be triggered when the backend folder is umounted: ================================================================== BUG: Dentry 000000008ad87947{i=7a,n=Dx_1_1.img} still in use (1) [unmount of ext4 sda] WARNING: CPU: 4 PID: 359261 at fs/dcache.c:1767 umount_check+0x5d/0x70 CPU: 4 PID: 359261 Comm: umount Not tainted 6.6.0-dirty #25 RIP: 0010:umount_check+0x5d/0x70 Call Trace: d_walk+0xda/0x2b0 do_one_tree+0x20/0x40 shrink_dcache_for_umount+0x2c/0x90 generic_shutdown_super+0x20/0x160 kill_block_super+0x1a/0x40 ext4_kill_sb+0x22/0x40 deactivate_locked_super+0x35/0x80 cleanup_mnt+0x104/0x160 ================================================================== Whether cachefiles_open_file() returns true or false, the reference count obtained by lookup_positive_unlocked() in cachefiles_look_up_object() should be released. Therefore release that reference count in cachefiles_look_up_object() to fix the above issue and simplify the code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49871", "url": "https://ubuntu.com/security/CVE-2024-49871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: adp5589-keys - fix NULL pointer dereference We register a devm action to call adp5589_clear_config() and then pass the i2c client as argument so that we can call i2c_get_clientdata() in order to get our device object. However, i2c_set_clientdata() is only being set at the end of the probe function which means that we'll get a NULL pointer dereference in case the probe function fails early.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49872", "url": "https://ubuntu.com/security/CVE-2024-49872", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/gup: fix memfd_pin_folios alloc race panic If memfd_pin_folios tries to create a hugetlb page, but someone else already did, then folio gets the value -EEXIST here: folio = memfd_alloc_folio(memfd, start_idx); if (IS_ERR(folio)) { ret = PTR_ERR(folio); if (ret != -EEXIST) goto err; then on the next trip through the \"while start_idx\" loop we panic here: if (folio) { folio_put(folio); To fix, set the folio to NULL on error.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49964", "url": "https://ubuntu.com/security/CVE-2024-49964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix memfd_pin_folios free_huge_pages leak memfd_pin_folios followed by unpin_folios fails to restore free_huge_pages if the pages were not already faulted in, because the folio refcount for pages created by memfd_alloc_folio never goes to 0. memfd_pin_folios needs another folio_put to undo the folio_try_get below: memfd_alloc_folio() alloc_hugetlb_folio_nodemask() dequeue_hugetlb_folio_nodemask() dequeue_hugetlb_folio_node_exact() folio_ref_unfreeze(folio, 1); ; adds 1 refcount folio_try_get() ; adds 1 refcount hugetlb_add_to_page_cache() ; adds 512 refcount (on x86) With the fix, after memfd_pin_folios + unpin_folios, the refcount for the (unfaulted) page is 512, which is correct, as the refcount for a faulted unpinned page is 513.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49873", "url": "https://ubuntu.com/security/CVE-2024-49873", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/filemap: fix filemap_get_folios_contig THP panic Patch series \"memfd-pin huge page fixes\". Fix multiple bugs that occur when using memfd_pin_folios with hugetlb pages and THP. The hugetlb bugs only bite when the page is not yet faulted in when memfd_pin_folios is called. The THP bug bites when the starting offset passed to memfd_pin_folios is not huge page aligned. See the commit messages for details. This patch (of 5): memfd_pin_folios on memory backed by THP panics if the requested start offset is not huge page aligned: BUG: kernel NULL pointer dereference, address: 0000000000000036 RIP: 0010:filemap_get_folios_contig+0xdf/0x290 RSP: 0018:ffffc9002092fbe8 EFLAGS: 00010202 RAX: 0000000000000002 RBX: 0000000000000002 RCX: 0000000000000002 The fault occurs here, because xas_load returns a folio with value 2: filemap_get_folios_contig() for (folio = xas_load(&xas); folio && xas.xa_index <= end; folio = xas_next(&xas)) { ... if (!folio_try_get(folio)) <-- BOOM \"2\" is an xarray sibling entry. We get it because memfd_pin_folios does not round the indices passed to filemap_get_folios_contig to huge page boundaries for THP, so we load from the middle of a huge page range see a sibling. (It does round for hugetlbfs, at the is_file_hugepages test). To fix, if the folio is a sibling, then return the next index as the starting point for the next call to filemap_get_folios_contig.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49977", "url": "https://ubuntu.com/security/CVE-2024-49977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: Fix zero-division error when disabling tc cbs The commit b8c43360f6e4 (\"net: stmmac: No need to calculate speed divider when offload is disabled\") allows the \"port_transmit_rate_kbps\" to be set to a value of 0, which is then passed to the \"div_s64\" function when tc-cbs is disabled. This leads to a zero-division error. When tc-cbs is disabled, the idleslope, sendslope, and credit values the credit values are not required to be configured. Therefore, adding a return statement after setting the txQ mode to DCB when tc-cbs is disabled would prevent a zero-division error.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49978", "url": "https://ubuntu.com/security/CVE-2024-49978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gso: fix udp gso fraglist segmentation after pull from frag_list Detect gso fraglist skbs with corrupted geometry (see below) and pass these to skb_segment instead of skb_segment_list, as the first can segment them correctly. 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 these skbs, breaking these invariants. In extreme cases they pull all data into skb linear. For UDP, this causes a NULL ptr deref in __udpv4_gso_segment_list_csum at udp_hdr(seg->next)->dest. Detect invalid geometry due to pull, by checking head_skb size. Don't just drop, as this may blackhole a destination. Convert to be able to pass to regular skb_segment.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49979", "url": "https://ubuntu.com/security/CVE-2024-49979", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gso: fix tcp fraglist segmentation after pull from frag_list Detect tcp gso fraglist skbs with corrupted geometry (see below) and pass these to skb_segment instead of skb_segment_list, as the first can segment them correctly. 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 these skbs, breaking these invariants. In extreme cases they pull all data into skb linear. For TCP, this causes a NULL ptr deref in __tcpv4_gso_segment_list_csum at tcp_hdr(seg->next). Detect invalid geometry due to pull, by checking head_skb size. Don't just drop, as this may blackhole a destination. Convert to be able to pass to regular skb_segment. Approach and description based on a patch by Willem de Bruijn.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49980", "url": "https://ubuntu.com/security/CVE-2024-49980", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vrf: revert \"vrf: Remove unnecessary RCU-bh critical section\" This reverts commit 504fc6f4f7f681d2a03aa5f68aad549d90eab853. dev_queue_xmit_nit is expected to be called with BH disabled. __dev_queue_xmit has the following: /* Disable soft irqs for various locks below. Also * stops preemption for RCU. */ rcu_read_lock_bh(); VRF must follow this invariant. The referenced commit removed this protection. Which triggered a lockdep warning: \t================================ \tWARNING: inconsistent lock state \t6.11.0 #1 Tainted: G W \t-------------------------------- \tinconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage. \tbtserver/134819 [HC0[0]:SC0[0]:HE1:SE1] takes: \tffff8882da30c118 (rlock-AF_PACKET){+.?.}-{2:2}, at: tpacket_rcv+0x863/0x3b30 \t{IN-SOFTIRQ-W} state was registered at: \t lock_acquire+0x19a/0x4f0 \t _raw_spin_lock+0x27/0x40 \t packet_rcv+0xa33/0x1320 \t __netif_receive_skb_core.constprop.0+0xcb0/0x3a90 \t __netif_receive_skb_list_core+0x2c9/0x890 \t netif_receive_skb_list_internal+0x610/0xcc0 [...] \tother info that might help us debug this: \t Possible unsafe locking scenario: \t CPU0 \t ---- \t lock(rlock-AF_PACKET); \t \t lock(rlock-AF_PACKET); \t *** DEADLOCK *** \tCall Trace: \t \t dump_stack_lvl+0x73/0xa0 \t mark_lock+0x102e/0x16b0 \t __lock_acquire+0x9ae/0x6170 \t lock_acquire+0x19a/0x4f0 \t _raw_spin_lock+0x27/0x40 \t tpacket_rcv+0x863/0x3b30 \t dev_queue_xmit_nit+0x709/0xa40 \t vrf_finish_direct+0x26e/0x340 [vrf] \t vrf_l3_out+0x5f4/0xe80 [vrf] \t __ip_local_out+0x51e/0x7a0 [...]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49981", "url": "https://ubuntu.com/security/CVE-2024-49981", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: venus: fix use after free bug in venus_remove due to race condition in venus_probe, core->work is bound with venus_sys_error_handler, which is used to handle error. The code use core->sys_err_done to make sync work. The core->work is started in venus_event_notify. If we call venus_remove, there might be an unfished work. The possible sequence is as follows: CPU0 CPU1 |venus_sys_error_handler venus_remove | hfi_destroy\t \t\t | venus_hfi_destroy\t | kfree(hdev);\t | |hfi_reinit \t\t\t\t\t |venus_hfi_queues_reinit |//use hdev Fix it by canceling the work in venus_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49956", "url": "https://ubuntu.com/security/CVE-2024-49956", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: fix double destroy_workqueue error When gfs2_fill_super() fails, destroy_workqueue() is called within gfs2_gl_hash_clear(), and the subsequent code path calls destroy_workqueue() on the same work queue again. This issue can be fixed by setting the work queue pointer to NULL after the first destroy_workqueue() call and checking for a NULL pointer before attempting to destroy the work queue again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50176", "url": "https://ubuntu.com/security/CVE-2024-50176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: k3-r5: Fix error handling when power-up failed By simply bailing out, the driver was violating its rule and internal assumptions that either both or no rproc should be initialized. E.g., this could cause the first core to be available but not the second one, leading to crashes on its shutdown later on while trying to dereference that second instance.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49982", "url": "https://ubuntu.com/security/CVE-2024-49982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: aoe: fix the potential use-after-free problem in more places For fixing CVE-2023-6270, f98364e92662 (\"aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts\") makes tx() calling dev_put() instead of doing in aoecmd_cfg_pkts(). It avoids that the tx() runs into use-after-free. Then Nicolai Stange found more places in aoe have potential use-after-free problem with tx(). e.g. revalidate(), aoecmd_ata_rw(), resend(), probe() and aoecmd_cfg_rsp(). Those functions also use aoenet_xmit() to push packet to tx queue. So they should also use dev_hold() to increase the refcnt of skb->dev. On the other hand, moving dev_put() to tx() causes that the refcnt of skb->dev be reduced to a negative value, because corresponding dev_hold() are not called in revalidate(), aoecmd_ata_rw(), resend(), probe(), and aoecmd_cfg_rsp(). This patch fixed this issue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49874", "url": "https://ubuntu.com/security/CVE-2024-49874", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: svc: Fix use after free vulnerability in svc_i3c_master Driver Due to Race Condition In the svc_i3c_master_probe function, &master->hj_work is bound with svc_i3c_master_hj_work, &master->ibi_work is bound with svc_i3c_master_ibi_work. And svc_i3c_master_ibi_work can start the hj_work, svc_i3c_master_irq_handler can start the ibi_work. If we remove the module which will call svc_i3c_master_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | svc_i3c_master_hj_work svc_i3c_master_remove | i3c_master_unregister(&master->base)| device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in svc_i3c_master_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49875", "url": "https://ubuntu.com/security/CVE-2024-49875", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: map the EBADMSG to nfserr_io to avoid warning Ext4 will throw -EBADMSG through ext4_readdir when a checksum error occurs, resulting in the following WARNING. Fix it by mapping EBADMSG to nfserr_io. nfsd_buffered_readdir iterate_dir // -EBADMSG -74 ext4_readdir // .iterate_shared ext4_dx_readdir ext4_htree_fill_tree htree_dirblock_to_tree ext4_read_dirblock __ext4_read_dirblock ext4_dirblock_csum_verify warn_no_space_for_csum __warn_no_space_for_csum return ERR_PTR(-EFSBADCRC) // -EBADMSG -74 nfserrno // WARNING [ 161.115610] ------------[ cut here ]------------ [ 161.116465] nfsd: non-standard errno: -74 [ 161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0 [ 161.118596] Modules linked in: [ 161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138 [ 161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qe mu.org 04/01/2014 [ 161.123601] RIP: 0010:nfserrno+0x9d/0xd0 [ 161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6 05 ce 2b 61 03 01 e8 99 20 d8 00 <0f> 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33 [ 161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286 [ 161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a [ 161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827 [ 161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021 [ 161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8 [ 161.135244] FS: 0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000 [ 161.136695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0 [ 161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 161.141519] PKRU: 55555554 [ 161.142076] Call Trace: [ 161.142575] ? __warn+0x9b/0x140 [ 161.143229] ? nfserrno+0x9d/0xd0 [ 161.143872] ? report_bug+0x125/0x150 [ 161.144595] ? handle_bug+0x41/0x90 [ 161.145284] ? exc_invalid_op+0x14/0x70 [ 161.146009] ? asm_exc_invalid_op+0x12/0x20 [ 161.146816] ? nfserrno+0x9d/0xd0 [ 161.147487] nfsd_buffered_readdir+0x28b/0x2b0 [ 161.148333] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.149258] ? nfsd_buffered_filldir+0xf0/0xf0 [ 161.150093] ? wait_for_concurrent_writes+0x170/0x170 [ 161.151004] ? generic_file_llseek_size+0x48/0x160 [ 161.151895] nfsd_readdir+0x132/0x190 [ 161.152606] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.153516] ? nfsd_unlink+0x380/0x380 [ 161.154256] ? override_creds+0x45/0x60 [ 161.155006] nfsd4_encode_readdir+0x21a/0x3d0 [ 161.155850] ? nfsd4_encode_readlink+0x210/0x210 [ 161.156731] ? write_bytes_to_xdr_buf+0x97/0xe0 [ 161.157598] ? __write_bytes_to_xdr_buf+0xd0/0xd0 [ 161.158494] ? lock_downgrade+0x90/0x90 [ 161.159232] ? nfs4svc_decode_voidarg+0x10/0x10 [ 161.160092] nfsd4_encode_operation+0x15a/0x440 [ 161.160959] nfsd4_proc_compound+0x718/0xe90 [ 161.161818] nfsd_dispatch+0x18e/0x2c0 [ 161.162586] svc_process_common+0x786/0xc50 [ 161.163403] ? nfsd_svc+0x380/0x380 [ 161.164137] ? svc_printk+0x160/0x160 [ 161.164846] ? svc_xprt_do_enqueue.part.0+0x365/0x380 [ 161.165808] ? nfsd_svc+0x380/0x380 [ 161.166523] ? rcu_is_watching+0x23/0x40 [ 161.167309] svc_process+0x1a5/0x200 [ 161.168019] nfsd+0x1f5/0x380 [ 161.168663] ? nfsd_shutdown_threads+0x260/0x260 [ 161.169554] kthread+0x1c4/0x210 [ 161.170224] ? kthread_insert_work_sanity_check+0x80/0x80 [ 161.171246] ret_from_fork+0x1f/0x30", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50013", "url": "https://ubuntu.com/security/CVE-2024-50013", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix memory leak in exfat_load_bitmap() If the first directory entry in the root directory is not a bitmap directory entry, 'bh' will not be released and reassigned, which will cause a memory leak.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49876", "url": "https://ubuntu.com/security/CVE-2024-49876", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: fix UAF around queue destruction We currently do stuff like queuing the final destruction step on a random system wq, which will outlive the driver instance. With bad timing we can teardown the driver with one or more work workqueue still being alive leading to various UAF splats. Add a fini step to ensure user queues are properly torn down. At this point GuC should already be nuked so queue itself should no longer be referenced from hw pov. v2 (Matt B) - Looks much safer to use a waitqueue and then just wait for the xa_array to become empty before triggering the drain. (cherry picked from commit 861108666cc0e999cffeab6aff17b662e68774e3)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49877", "url": "https://ubuntu.com/security/CVE-2024-49877", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate When doing cleanup, if flags without OCFS2_BH_READAHEAD, it may trigger NULL pointer dereference in the following ocfs2_set_buffer_uptodate() if bh is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49957", "url": "https://ubuntu.com/security/CVE-2024-49957", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix null-ptr-deref when journal load failed. During the mounting process, if journal_reset() fails because of too short journal, then lead to jbd2_journal_load() fails with NULL j_sb_buffer. Subsequently, ocfs2_journal_shutdown() calls jbd2_journal_flush()->jbd2_cleanup_journal_tail()-> __jbd2_update_log_tail()->jbd2_journal_update_sb_log_tail() ->lock_buffer(journal->j_sb_buffer), resulting in a null-pointer dereference error. To resolve this issue, we should check the JBD2_LOADED flag to ensure the journal was properly loaded. Additionally, use journal instead of osb->journal directly to simplify the code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49965", "url": "https://ubuntu.com/security/CVE-2024-49965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove unreasonable unlock in ocfs2_read_blocks Patch series \"Misc fixes for ocfs2_read_blocks\", v5. This series contains 2 fixes for ocfs2_read_blocks(). The first patch fix the issue reported by syzbot, which detects bad unlock balance in ocfs2_read_blocks(). The second patch fixes an issue reported by Heming Zhao when reviewing above fix. This patch (of 2): There was a lock release before exiting, so remove the unreasonable unlock.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49966", "url": "https://ubuntu.com/security/CVE-2024-49966", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: cancel dqi_sync_work before freeing oinfo ocfs2_global_read_info() will initialize and schedule dqi_sync_work at the end, if error occurs after successfully reading global quota, it will trigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled: ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16c This reports that there is an active delayed work when freeing oinfo in error handling, so cancel dqi_sync_work first. BTW, return status instead of -1 when .read_file_info fails.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49958", "url": "https://ubuntu.com/security/CVE-2024-49958", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reserve space for inline xattr before attaching reflink tree One of our customers reported a crash and a corrupted ocfs2 filesystem. The crash was due to the detection of corruption. Upon troubleshooting, the fsck -fn output showed the below corruption [EXTENT_LIST_FREE] Extent list in owner 33080590 claims 230 as the next free chain record, but fsck believes the largest valid value is 227. Clamp the next record value? n The stat output from the debugfs.ocfs2 showed the following corruption where the \"Next Free Rec:\" had overshot the \"Count:\" in the root metadata block. Inode: 33080590 Mode: 0640 Generation: 2619713622 (0x9c25a856) FS Generation: 904309833 (0x35e6ac49) CRC32: 00000000 ECC: 0000 Type: Regular Attr: 0x0 Flags: Valid Dynamic Features: (0x16) HasXattr InlineXattr Refcounted Extended Attributes Block: 0 Extended Attributes Inline Size: 256 User: 0 (root) Group: 0 (root) Size: 281320357888 Links: 1 Clusters: 141738 ctime: 0x66911b56 0x316edcb8 -- Fri Jul 12 06:02:30.829349048 2024 atime: 0x66911d6b 0x7f7a28d -- Fri Jul 12 06:11:23.133669517 2024 mtime: 0x66911b56 0x12ed75d7 -- Fri Jul 12 06:02:30.317552087 2024 dtime: 0x0 -- Wed Dec 31 17:00:00 1969 Refcount Block: 2777346 Last Extblk: 2886943 Orphan Slot: 0 Sub Alloc Slot: 0 Sub Alloc Bit: 14 Tree Depth: 1 Count: 227 Next Free Rec: 230 ## Offset Clusters Block# 0 0 2310 2776351 1 2310 2139 2777375 2 4449 1221 2778399 3 5670 731 2779423 4 6401 566 2780447 ....... .... ....... ....... .... ....... The issue was in the reflink workfow while reserving space for inline xattr. The problematic function is ocfs2_reflink_xattr_inline(). By the time this function is called the reflink tree is already recreated at the destination inode from the source inode. At this point, this function reserves space for inline xattrs at the destination inode without even checking if there is space at the root metadata block. It simply reduces the l_count from 243 to 227 thereby making space of 256 bytes for inline xattr whereas the inode already has extents beyond this index (in this case up to 230), thereby causing corruption. The fix for this is to reserve space for inline metadata at the destination inode before the reflink tree gets recreated. The customer has verified the fix.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49959", "url": "https://ubuntu.com/security/CVE-2024-49959", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail() to recover some journal space. But if an error occurs while executing jbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for free space right away, we try other branches, and if j_committing_transaction is NULL (i.e., the tid is 0), we will get the following complain: ============================================ JBD2: I/O error when updating journal superblock for sdd-8. __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available __jbd2_log_wait_for_space: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Call Trace: add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70 [...] ============================================ So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways. Note that this fix relies on commit 6f6a6fda2945 (\"jbd2: fix ocfs2 corrupt when updating journal superblock fails\") to make jbd2_cleanup_journal_tail return the correct error code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49878", "url": "https://ubuntu.com/security/CVE-2024-49878", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: resource: fix region_intersects() vs add_memory_driver_managed() On a system with CXL memory, the resource tree (/proc/iomem) related to CXL memory may look like something as follows. 490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem) Because drivers/dax/kmem.c calls add_memory_driver_managed() during onlining CXL memory, which makes \"System RAM (kmem)\" a descendant of \"CXL Window X\". This confuses region_intersects(), which expects all \"System RAM\" resources to be at the top level of iomem_resource. This can lead to bugs. For example, when the following command line is executed to write some memory in CXL memory range via /dev/mem, $ dd if=data of=/dev/mem bs=$((1 << 10)) seek=$((0x490000000 >> 10)) count=1 dd: error writing '/dev/mem': Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/s the command fails as expected. However, the error code is wrong. It should be \"Operation not permitted\" instead of \"Bad address\". More seriously, the /dev/mem permission checking in devmem_is_allowed() passes incorrectly. Although the accessing is prevented later because ioremap() isn't allowed to map system RAM, it is a potential security issue. During command executing, the following warning is reported in the kernel log for calling ioremap() on system RAM. ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d Call Trace: memremap+0xcb/0x184 xlate_dev_mem_ptr+0x25/0x2f write_mem+0x94/0xfb vfs_write+0x128/0x26d ksys_write+0xac/0xfe do_syscall_64+0x9a/0xfd entry_SYSCALL_64_after_hwframe+0x4b/0x53 The details of command execution process are as follows. In the above resource tree, \"System RAM\" is a descendant of \"CXL Window 0\" instead of a top level resource. So, region_intersects() will report no System RAM resources in the CXL memory region incorrectly, because it only checks the top level resources. Consequently, devmem_is_allowed() will return 1 (allow access via /dev/mem) for CXL memory region incorrectly. Fortunately, ioremap() doesn't allow to map System RAM and reject the access. So, region_intersects() needs to be fixed to work correctly with the resource tree with \"System RAM\" not at top level as above. To fix it, if we found a unmatched resource in the top level, we will continue to search matched resources in its descendant resources. So, we will not miss any matched resources in resource tree anymore. In the new implementation, an example resource tree |------------- \"CXL Window 0\" ------------| |-- \"System RAM\" --| will behave similar as the following fake resource tree for region_intersects(, IORESOURCE_SYSTEM_RAM, ), |-- \"System RAM\" --||-- \"CXL Window 0a\" --| Where \"CXL Window 0a\" is part of the original \"CXL Window 0\" that isn't covered by \"System RAM\".", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49879", "url": "https://ubuntu.com/security/CVE-2024-49879", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm: omapdrm: Add missing check for alloc_ordered_workqueue As it may return NULL pointer and cause NULL pointer dereference. Add check for the return value of alloc_ordered_workqueue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49880", "url": "https://ubuntu.com/security/CVE-2024-49880", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix off by one issue in alloc_flex_gd() Wesley reported an issue: ================================================================== EXT4-fs (dm-5): resizing filesystem from 7168 to 786432 blocks ------------[ cut here ]------------ kernel BUG at fs/ext4/resize.c:324! CPU: 9 UID: 0 PID: 3576 Comm: resize2fs Not tainted 6.11.0+ #27 RIP: 0010:ext4_resize_fs+0x1212/0x12d0 Call Trace: __ext4_ioctl+0x4e0/0x1800 ext4_ioctl+0x12/0x20 __x64_sys_ioctl+0x99/0xd0 x64_sys_call+0x1206/0x20d0 do_syscall_64+0x72/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e ================================================================== While reviewing the patch, Honza found that when adjusting resize_bg in alloc_flex_gd(), it was possible for flex_gd->resize_bg to be bigger than flexbg_size. The reproduction of the problem requires the following: o_group = flexbg_size * 2 * n; o_size = (o_group + 1) * group_size; n_group: [o_group + flexbg_size, o_group + flexbg_size * 2) o_size = (n_group + 1) * group_size; Take n=0,flexbg_size=16 as an example: last:15 |o---------------|--------------n-| o_group:0 resize to n_group:30 The corresponding reproducer is: img=test.img rm -f $img truncate -s 600M $img mkfs.ext4 -F $img -b 1024 -G 16 8M dev=`losetup -f --show $img` mkdir -p /tmp/test mount $dev /tmp/test resize2fs $dev 248M Delete the problematic plus 1 to fix the issue, and add a WARN_ON_ONCE() to prevent the issue from happening again. [ Note: another reproucer which this commit fixes is: img=test.img rm -f $img truncate -s 25MiB $img mkfs.ext4 -b 4096 -E nodiscard,lazy_itable_init=0,lazy_journal_init=0 $img truncate -s 3GiB $img dev=`losetup -f --show $img` mkdir -p /tmp/test mount $dev /tmp/test resize2fs $dev 3G umount $dev losetup -d $dev -- TYT ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49881", "url": "https://ubuntu.com/security/CVE-2024-49881", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: update orig_path in ext4_find_extent() In ext4_find_extent(), if the path is not big enough, we free it and set *orig_path to NULL. But after reallocating and successfully initializing the path, we don't update *orig_path, in which case the caller gets a valid path but a NULL ppath, and this may cause a NULL pointer dereference or a path memory leak. For example: ext4_split_extent path = *ppath = 2000 ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path = 2000); *orig_path = path = NULL; path = kcalloc() = 3000 ext4_split_extent_at(*ppath = NULL) path = *ppath; ex = path[depth].p_ext; // NULL pointer dereference! ================================================================== BUG: kernel NULL pointer dereference, address: 0000000000000010 CPU: 6 UID: 0 PID: 576 Comm: fsstress Not tainted 6.11.0-rc2-dirty #847 RIP: 0010:ext4_split_extent_at+0x6d/0x560 Call Trace: ext4_split_extent.isra.0+0xcb/0x1b0 ext4_ext_convert_to_initialized+0x168/0x6c0 ext4_ext_handle_unwritten_extents+0x325/0x4d0 ext4_ext_map_blocks+0x520/0xdb0 ext4_map_blocks+0x2b0/0x690 ext4_iomap_begin+0x20e/0x2c0 [...] ================================================================== Therefore, *orig_path is updated when the extent lookup succeeds, so that the caller can safely use path or *ppath.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50014", "url": "https://ubuntu.com/security/CVE-2024-50014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix access to uninitialised lock in fc replay path The following kernel trace can be triggered with fstest generic/629 when executed against a filesystem with fast-commit feature enabled: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x66/0x90 register_lock_class+0x759/0x7d0 __lock_acquire+0x85/0x2630 ? __find_get_block+0xb4/0x380 lock_acquire+0xd1/0x2d0 ? __ext4_journal_get_write_access+0xd5/0x160 _raw_spin_lock+0x33/0x40 ? __ext4_journal_get_write_access+0xd5/0x160 __ext4_journal_get_write_access+0xd5/0x160 ext4_reserve_inode_write+0x61/0xb0 __ext4_mark_inode_dirty+0x79/0x270 ? ext4_ext_replay_set_iblocks+0x2f8/0x450 ext4_ext_replay_set_iblocks+0x330/0x450 ext4_fc_replay+0x14c8/0x1540 ? jread+0x88/0x2e0 ? rcu_is_watching+0x11/0x40 do_one_pass+0x447/0xd00 jbd2_journal_recover+0x139/0x1b0 jbd2_journal_load+0x96/0x390 ext4_load_and_init_journal+0x253/0xd40 ext4_fill_super+0x2cc6/0x3180 ... In the replay path there's an attempt to lock sbi->s_bdev_wb_lock in function ext4_check_bdev_write_error(). Unfortunately, at this point this spinlock has not been initialized yet. Moving it's initialization to an earlier point in __ext4_fill_super() fixes this splat.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49960", "url": "https://ubuntu.com/security/CVE-2024-49960", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix timer use-after-free on failed mount Syzbot has found an ODEBUG bug in ext4_fill_super The del_timer_sync function cancels the s_err_report timer, which reminds about filesystem errors daily. We should guarantee the timer is no longer active before kfree(sbi). When filesystem mounting fails, the flow goes to failed_mount3, where an error occurs when ext4_stop_mmpd is called, causing a read I/O failure. This triggers the ext4_handle_error function that ultimately re-arms the timer, leaving the s_err_report timer active before kfree(sbi) is called. Fix the issue by canceling the s_err_report timer after calling ext4_stop_mmpd.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49882", "url": "https://ubuntu.com/security/CVE-2024-49882", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix double brelse() the buffer of the extents path In ext4_ext_try_to_merge_up(), set path[1].p_bh to NULL after it has been released, otherwise it may be released twice. An example of what triggers this is as follows: split2 map split1 |--------|-------|--------| ext4_ext_map_blocks ext4_ext_handle_unwritten_extents ext4_split_convert_extents // path->p_depth == 0 ext4_split_extent // 1. do split1 ext4_split_extent_at |ext4_ext_insert_extent | ext4_ext_create_new_leaf | ext4_ext_grow_indepth | le16_add_cpu(&neh->eh_depth, 1) | ext4_find_extent | // return -ENOMEM |// get error and try zeroout |path = ext4_find_extent | path->p_depth = 1 |ext4_ext_try_to_merge | ext4_ext_try_to_merge_up | path->p_depth = 0 | brelse(path[1].p_bh) ---> not set to NULL here |// zeroout success // 2. update path ext4_find_extent // 3. do split2 ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth le16_add_cpu(&neh->eh_depth, 1) ext4_find_extent path[0].p_bh = NULL; path->p_depth = 1 read_extent_tree_block ---> return err // path[1].p_bh is still the old value ext4_free_ext_path ext4_ext_drop_refs // path->p_depth == 1 brelse(path[1].p_bh) ---> brelse a buffer twice Finally got the following WARRNING when removing the buffer from lru: ============================================ VFS: brelse: Trying to free free buffer WARNING: CPU: 2 PID: 72 at fs/buffer.c:1241 __brelse+0x58/0x90 CPU: 2 PID: 72 Comm: kworker/u19:1 Not tainted 6.9.0-dirty #716 RIP: 0010:__brelse+0x58/0x90 Call Trace: __find_get_block+0x6e7/0x810 bdev_getblk+0x2b/0x480 __ext4_get_inode_loc+0x48a/0x1240 ext4_get_inode_loc+0xb2/0x150 ext4_reserve_inode_write+0xb7/0x230 __ext4_mark_inode_dirty+0x144/0x6a0 ext4_ext_insert_extent+0x9c8/0x3230 ext4_ext_map_blocks+0xf45/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] ============================================", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49883", "url": "https://ubuntu.com/security/CVE-2024-49883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: aovid use-after-free in ext4_ext_insert_extent() As Ojaswin mentioned in Link, in ext4_ext_insert_extent(), if the path is reallocated in ext4_ext_create_new_leaf(), we'll use the stale path and cause UAF. Below is a sample trace with dummy values: ext4_ext_insert_extent path = *ppath = 2000 ext4_ext_create_new_leaf(ppath) ext4_find_extent(ppath) path = *ppath = 2000 if (depth > path[0].p_maxdepth) kfree(path = 2000); *ppath = path = NULL; path = kcalloc() = 3000 *ppath = 3000; return path; /* here path is still 2000, UAF! */ eh = path[depth].p_hdr ================================================================== BUG: KASAN: slab-use-after-free in ext4_ext_insert_extent+0x26d4/0x3330 Read of size 8 at addr ffff8881027bf7d0 by task kworker/u36:1/179 CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 Not tainted 6.11.0-rc2-dirty #866 Call Trace: ext4_ext_insert_extent+0x26d4/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 [...] Allocated by task 179: ext4_find_extent+0x81c/0x1f70 ext4_ext_map_blocks+0x146/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...] Freed by task 179: kfree+0xcb/0x240 ext4_find_extent+0x7c0/0x1f70 ext4_ext_insert_extent+0xa26/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...] ================================================================== So use *ppath to update the path to avoid the above problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49983", "url": "https://ubuntu.com/security/CVE-2024-49983", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-free When calling ext4_force_split_extent_at() in ext4_ext_replay_update_ex(), the 'ppath' is updated but it is the 'path' that is freed, thus potentially triggering a double-free in the following process: ext4_ext_replay_update_ex ppath = path ext4_force_split_extent_at(&ppath) ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path) ---> path First freed *orig_path = path = NULL ---> null ppath kfree(path) ---> path double-free !!! So drop the unnecessary ppath and use path directly to avoid this problem. And use ext4_find_extent() directly to update path, avoiding unnecessary memory allocation and freeing. Also, propagate the error returned by ext4_find_extent() instead of using strange error codes.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50015", "url": "https://ubuntu.com/security/CVE-2024-50015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: dax: fix overflowing extents beyond inode size when partially writing The dax_iomap_rw() does two things in each iteration: map written blocks and copy user data to blocks. If the process is killed by user(See signal handling in dax_iomap_iter()), the copied data will be returned and added on inode size, which means that the length of written extents may exceed the inode size, then fsck will fail. An example is given as: dd if=/dev/urandom of=file bs=4M count=1 dax_iomap_rw iomap_iter // round 1 ext4_iomap_begin ext4_iomap_alloc // allocate 0~2M extents(written flag) dax_iomap_iter // copy 2M data iomap_iter // round 2 iomap_iter_advance iter->pos += iter->processed // iter->pos = 2M ext4_iomap_begin ext4_iomap_alloc // allocate 2~4M extents(written flag) dax_iomap_iter fatal_signal_pending done = iter->pos - iocb->ki_pos // done = 2M ext4_handle_inode_extension ext4_update_inode_size // inode size = 2M fsck reports: Inode 13, i_size is 2097152, should be 4194304. Fix? Fix the problem by truncating extents if the written length is smaller than expected.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49884", "url": "https://ubuntu.com/security/CVE-2024-49884", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix slab-use-after-free in ext4_split_extent_at() We hit the following use-after-free: ================================================================== BUG: KASAN: slab-use-after-free in ext4_split_extent_at+0xba8/0xcc0 Read of size 2 at addr ffff88810548ed08 by task kworker/u20:0/40 CPU: 0 PID: 40 Comm: kworker/u20:0 Not tainted 6.9.0-dirty #724 Call Trace: kasan_report+0x93/0xc0 ext4_split_extent_at+0xba8/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] Allocated by task 40: __kmalloc_noprof+0x1ac/0x480 ext4_find_extent+0xf3b/0x1e70 ext4_ext_map_blocks+0x188/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] Freed by task 40: kfree+0xf1/0x2b0 ext4_find_extent+0xa71/0x1e70 ext4_ext_insert_extent+0xa22/0x3260 ext4_split_extent_at+0x3ef/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] ================================================================== The flow of issue triggering is as follows: ext4_split_extent_at path = *ppath ext4_ext_insert_extent(ppath) ext4_ext_create_new_leaf(ppath) ext4_find_extent(orig_path) path = *orig_path read_extent_tree_block // return -ENOMEM or -EIO ext4_free_ext_path(path) kfree(path) *orig_path = NULL a. If err is -ENOMEM: ext4_ext_dirty(path + path->p_depth) // path use-after-free !!! b. If err is -EIO and we have EXT_DEBUG defined: ext4_ext_show_leaf(path) eh = path[depth].p_hdr // path also use-after-free !!! So when trying to zeroout or fix the extent length, call ext4_find_extent() to update the path. In addition we use *ppath directly as an ext4_ext_show_leaf() input to avoid possible use-after-free when EXT_DEBUG is defined, and to avoid unnecessary path updates.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49885", "url": "https://ubuntu.com/security/CVE-2024-49885", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm, slub: avoid zeroing kmalloc redzone Since commit 946fa0dbf2d8 (\"mm/slub: extend redzone check to extra allocated kmalloc space than requested\"), setting orig_size treats the wasted space (object_size - orig_size) as a redzone. However with init_on_free=1 we clear the full object->size, including the redzone. Additionally we clear the object metadata, including the stored orig_size, making it zero, which makes check_object() treat the whole object as a redzone. These issues lead to the following BUG report with \"slub_debug=FUZ init_on_free=1\": [ 0.000000] ============================================================================= [ 0.000000] BUG kmalloc-8 (Not tainted): kmalloc Redzone overwritten [ 0.000000] ----------------------------------------------------------------------------- [ 0.000000] [ 0.000000] 0xffff000010032858-0xffff00001003285f @offset=2136. First byte 0x0 instead of 0xcc [ 0.000000] FIX kmalloc-8: Restoring kmalloc Redzone 0xffff000010032858-0xffff00001003285f=0xcc [ 0.000000] Slab 0xfffffdffc0400c80 objects=36 used=23 fp=0xffff000010032a18 flags=0x3fffe0000000200(workingset|node=0|zone=0|lastcpupid=0x1ffff) [ 0.000000] Object 0xffff000010032858 @offset=2136 fp=0xffff0000100328c8 [ 0.000000] [ 0.000000] Redzone ffff000010032850: cc cc cc cc cc cc cc cc ........ [ 0.000000] Object ffff000010032858: cc cc cc cc cc cc cc cc ........ [ 0.000000] Redzone ffff000010032860: cc cc cc cc cc cc cc cc ........ [ 0.000000] Padding ffff0000100328b4: 00 00 00 00 00 00 00 00 00 00 00 00 ............ [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.11.0-rc3-next-20240814-00004-g61844c55c3f4 #144 [ 0.000000] Hardware name: NXP i.MX95 19X19 board (DT) [ 0.000000] Call trace: [ 0.000000] dump_backtrace+0x90/0xe8 [ 0.000000] show_stack+0x18/0x24 [ 0.000000] dump_stack_lvl+0x74/0x8c [ 0.000000] dump_stack+0x18/0x24 [ 0.000000] print_trailer+0x150/0x218 [ 0.000000] check_object+0xe4/0x454 [ 0.000000] free_to_partial_list+0x2f8/0x5ec To address the issue, use orig_size to clear the used area. And restore the value of orig_size after clear the remaining area. When CONFIG_SLUB_DEBUG not defined, (get_orig_size()' directly returns s->object_size. So when using memset to init the area, the size can simply be orig_size, as orig_size returns object_size when CONFIG_SLUB_DEBUG not enabled. And orig_size can never be bigger than object_size.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49961", "url": "https://ubuntu.com/security/CVE-2024-49961", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: ar0521: Use cansleep version of gpiod_set_value() If we use GPIO reset from I2C port expander, we must use *_cansleep() variant of GPIO functions. This was not done in ar0521_power_on()/ar0521_power_off() functions. Let's fix that. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 11 at drivers/gpio/gpiolib.c:3496 gpiod_set_value+0x74/0x7c Modules linked in: CPU: 0 PID: 11 Comm: kworker/u16:0 Not tainted 6.10.0 #53 Hardware name: Diasom DS-RK3568-SOM-EVB (DT) Workqueue: events_unbound deferred_probe_work_func pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : gpiod_set_value+0x74/0x7c lr : ar0521_power_on+0xcc/0x290 sp : ffffff8001d7ab70 x29: ffffff8001d7ab70 x28: ffffff80027dcc90 x27: ffffff8003c82000 x26: ffffff8003ca9250 x25: ffffffc080a39c60 x24: ffffff8003ca9088 x23: ffffff8002402720 x22: ffffff8003ca9080 x21: ffffff8003ca9088 x20: 0000000000000000 x19: ffffff8001eb2a00 x18: ffffff80efeeac80 x17: 756d2d6332692f30 x16: 0000000000000000 x15: 0000000000000000 x14: ffffff8001d91d40 x13: 0000000000000016 x12: ffffffc080e98930 x11: ffffff8001eb2880 x10: 0000000000000890 x9 : ffffff8001d7a9f0 x8 : ffffff8001d92570 x7 : ffffff80efeeac80 x6 : 000000003fc6e780 x5 : ffffff8001d91c80 x4 : 0000000000000002 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000001 Call trace: gpiod_set_value+0x74/0x7c ar0521_power_on+0xcc/0x290 ...", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49985", "url": "https://ubuntu.com/security/CVE-2024-49985", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume In case there is any sort of clock controller attached to this I2C bus controller, for example Versaclock or even an AIC32x4 I2C codec, then an I2C transfer triggered from the clock controller clk_ops .prepare callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex. This is because the clock controller first grabs the prepare_lock mutex and then performs the prepare operation, including its I2C access. The I2C access resumes this I2C bus controller via .runtime_resume callback, which calls clk_prepare_enable(), which attempts to grab the prepare_lock mutex again and deadlocks. Since the clock are already prepared since probe() and unprepared in remove(), use simple clk_enable()/clk_disable() calls to enable and disable the clock on runtime suspend and resume, to avoid hitting the prepare_lock mutex.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49886", "url": "https://ubuntu.com/security/CVE-2024-49886", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bug Attaching SST PCI device to VM causes \"BUG: KASAN: slab-out-of-bounds\". kasan report: [ 19.411889] ================================================================== [ 19.413702] BUG: KASAN: slab-out-of-bounds in _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.415634] Read of size 8 at addr ffff888829e65200 by task cpuhp/16/113 [ 19.417368] [ 19.418627] CPU: 16 PID: 113 Comm: cpuhp/16 Tainted: G E 6.9.0 #10 [ 19.420435] Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.20192059.B64.2207280713 07/28/2022 [ 19.422687] Call Trace: [ 19.424091] [ 19.425448] dump_stack_lvl+0x5d/0x80 [ 19.426963] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.428694] print_report+0x19d/0x52e [ 19.430206] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 19.431837] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.433539] kasan_report+0xf0/0x170 [ 19.435019] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.436709] _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.438379] ? __pfx_sched_clock_cpu+0x10/0x10 [ 19.439910] isst_if_cpu_online+0x406/0x58f [isst_if_common] [ 19.441573] ? __pfx_isst_if_cpu_online+0x10/0x10 [isst_if_common] [ 19.443263] ? ttwu_queue_wakelist+0x2c1/0x360 [ 19.444797] cpuhp_invoke_callback+0x221/0xec0 [ 19.446337] cpuhp_thread_fun+0x21b/0x610 [ 19.447814] ? __pfx_cpuhp_thread_fun+0x10/0x10 [ 19.449354] smpboot_thread_fn+0x2e7/0x6e0 [ 19.450859] ? __pfx_smpboot_thread_fn+0x10/0x10 [ 19.452405] kthread+0x29c/0x350 [ 19.453817] ? __pfx_kthread+0x10/0x10 [ 19.455253] ret_from_fork+0x31/0x70 [ 19.456685] ? __pfx_kthread+0x10/0x10 [ 19.458114] ret_from_fork_asm+0x1a/0x30 [ 19.459573] [ 19.460853] [ 19.462055] Allocated by task 1198: [ 19.463410] kasan_save_stack+0x30/0x50 [ 19.464788] kasan_save_track+0x14/0x30 [ 19.466139] __kasan_kmalloc+0xaa/0xb0 [ 19.467465] __kmalloc+0x1cd/0x470 [ 19.468748] isst_if_cdev_register+0x1da/0x350 [isst_if_common] [ 19.470233] isst_if_mbox_init+0x108/0xff0 [isst_if_mbox_msr] [ 19.471670] do_one_initcall+0xa4/0x380 [ 19.472903] do_init_module+0x238/0x760 [ 19.474105] load_module+0x5239/0x6f00 [ 19.475285] init_module_from_file+0xd1/0x130 [ 19.476506] idempotent_init_module+0x23b/0x650 [ 19.477725] __x64_sys_finit_module+0xbe/0x130 [ 19.476506] idempotent_init_module+0x23b/0x650 [ 19.477725] __x64_sys_finit_module+0xbe/0x130 [ 19.478920] do_syscall_64+0x82/0x160 [ 19.480036] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 19.481292] [ 19.482205] The buggy address belongs to the object at ffff888829e65000 which belongs to the cache kmalloc-512 of size 512 [ 19.484818] The buggy address is located 0 bytes to the right of allocated 512-byte region [ffff888829e65000, ffff888829e65200) [ 19.487447] [ 19.488328] The buggy address belongs to the physical page: [ 19.489569] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888829e60c00 pfn:0x829e60 [ 19.491140] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [ 19.492466] anon flags: 0x57ffffc0000840(slab|head|node=1|zone=2|lastcpupid=0x1fffff) [ 19.493914] page_type: 0xffffffff() [ 19.494988] raw: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [ 19.496451] raw: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [ 19.497906] head: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [ 19.499379] head: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [ 19.500844] head: 0057ffffc0000003 ffffea0020a79801 ffffea0020a79848 00000000ffffffff [ 19.502316] head: 0000000800000000 0000000000000000 00000000ffffffff 0000000000000000 [ 19.503784] page dumped because: k ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49986", "url": "https://ubuntu.com/security/CVE-2024-49986", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: x86-android-tablets: Fix use after free on platform_device_register() errors x86_android_tablet_remove() frees the pdevs[] array, so it should not be used after calling x86_android_tablet_remove(). When platform_device_register() fails, store the pdevs[x] PTR_ERR() value into the local ret variable before calling x86_android_tablet_remove() to avoid using pdevs[] after it has been freed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49887", "url": "https://ubuntu.com/security/CVE-2024-49887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to don't panic system for no free segment fault injection f2fs: fix to don't panic system for no free segment fault injection syzbot reports a f2fs bug as below: F2FS-fs (loop0): inject no free segment in get_new_segment of __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3167 F2FS-fs (loop0): Stopped filesystem due to reason: 7 ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2748! CPU: 0 UID: 0 PID: 5109 Comm: syz-executor304 Not tainted 6.11.0-rc6-syzkaller-00363-g89f5e14d05b4 #0 RIP: 0010:get_new_segment fs/f2fs/segment.c:2748 [inline] RIP: 0010:new_curseg+0x1f61/0x1f70 fs/f2fs/segment.c:2836 Call Trace: __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3167 f2fs_allocate_new_section fs/f2fs/segment.c:3181 [inline] f2fs_allocate_pinning_section+0xfa/0x4e0 fs/f2fs/segment.c:3195 f2fs_expand_inode_data+0x5d6/0xbb0 fs/f2fs/file.c:1799 f2fs_fallocate+0x448/0x960 fs/f2fs/file.c:1903 vfs_fallocate+0x553/0x6c0 fs/open.c:334 do_vfs_ioctl+0x2592/0x2e50 fs/ioctl.c:886 __do_sys_ioctl fs/ioctl.c:905 [inline] __se_sys_ioctl+0x81/0x170 fs/ioctl.c:893 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: 0010:get_new_segment fs/f2fs/segment.c:2748 [inline] RIP: 0010:new_curseg+0x1f61/0x1f70 fs/f2fs/segment.c:2836 The root cause is when we inject no free segment fault into f2fs, we should not panic system, fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49888", "url": "https://ubuntu.com/security/CVE-2024-49888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix a sdiv overflow issue Zac Ecob reported a problem where a bpf program may cause kernel crash due to the following error: Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI The failure is due to the below signed divide: LLONG_MIN/-1 where LLONG_MIN equals to -9,223,372,036,854,775,808. LLONG_MIN/-1 is supposed to give a positive number 9,223,372,036,854,775,808, but it is impossible since for 64-bit system, the maximum positive number is 9,223,372,036,854,775,807. On x86_64, LLONG_MIN/-1 will cause a kernel exception. On arm64, the result for LLONG_MIN/-1 is LLONG_MIN. Further investigation found all the following sdiv/smod cases may trigger an exception when bpf program is running on x86_64 platform: - LLONG_MIN/-1 for 64bit operation - INT_MIN/-1 for 32bit operation - LLONG_MIN%-1 for 64bit operation - INT_MIN%-1 for 32bit operation where -1 can be an immediate or in a register. On arm64, there are no exceptions: - LLONG_MIN/-1 = LLONG_MIN - INT_MIN/-1 = INT_MIN - LLONG_MIN%-1 = 0 - INT_MIN%-1 = 0 where -1 can be an immediate or in a register. Insn patching is needed to handle the above cases and the patched codes produced results aligned with above arm64 result. The below are pseudo codes to handle sdiv/smod exceptions including both divisor -1 and divisor 0 and the divisor is stored in a register. sdiv: tmp = rX tmp += 1 /* [-1, 0] -> [0, 1] if tmp >(unsigned) 1 goto L2 if tmp == 0 goto L1 rY = 0 L1: rY = -rY; goto L3 L2: rY /= rX L3: smod: tmp = rX tmp += 1 /* [-1, 0] -> [0, 1] if tmp >(unsigned) 1 goto L1 if tmp == 1 (is64 ? goto L2 : goto L3) rY = 0; goto L2 L1: rY %= rX L2: goto L4 // only when !is64 L3: wY = wY // only when !is64 L4: [1] https://lore.kernel.org/bpf/tPJLTEh7S_DxFEqAI2Ji5MBSoZVg7_G-Py2iaZpAaWtM961fFTWtsnlzwvTbzBzaUzwQAoNATXKUlt0LZOFgnDcIyKCswAnAGdUF3LBrhGQ=@protonmail.com/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49987", "url": "https://ubuntu.com/security/CVE-2024-49987", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpftool: Fix undefined behavior in qsort(NULL, 0, ...) When netfilter has no entry to display, qsort is called with qsort(NULL, 0, ...). This results in undefined behavior, as UBSan reports: net.c:827:2: runtime error: null pointer passed as argument 1, which is declared to never be null Although the C standard does not explicitly state whether calling qsort with a NULL pointer when the size is 0 constitutes undefined behavior, Section 7.1.4 of the C standard (Use of library functions) mentions: \"Each of the following statements applies unless explicitly stated otherwise in the detailed descriptions that follow: If an argument to a function has an invalid value (such as a value outside the domain of the function, or a pointer outside the address space of the program, or a null pointer, or a pointer to non-modifiable storage when the corresponding parameter is not const-qualified) or a type (after promotion) not expected by a function with variable number of arguments, the behavior is undefined.\" To avoid this, add an early return when nf_link_info is NULL to prevent calling qsort with a NULL pointer.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50006", "url": "https://ubuntu.com/security/CVE-2024-50006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix i_data_sem unlock order in ext4_ind_migrate() Fuzzing reports a possible deadlock in jbd2_log_wait_commit. This issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to require synchronous updates because the file descriptor is opened with O_SYNC. This can lead to the jbd2_journal_stop() function calling jbd2_might_wait_for_commit(), potentially causing a deadlock if the EXT4_IOC_MIGRATE call races with a write(2) system call. This problem only arises when CONFIG_PROVE_LOCKING is enabled. In this case, the jbd2_might_wait_for_commit macro locks jbd2_handle in the jbd2_journal_stop function while i_data_sem is locked. This triggers lockdep because the jbd2_journal_start function might also lock the same jbd2_handle simultaneously. Found by Linux Verification Center (linuxtesting.org) with syzkaller. Rule: add", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49889", "url": "https://ubuntu.com/security/CVE-2024-49889", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid use-after-free in ext4_ext_show_leaf() In ext4_find_extent(), path may be freed by error or be reallocated, so using a previously saved *ppath may have been freed and thus may trigger use-after-free, as follows: ext4_split_extent path = *ppath; ext4_split_extent_at(ppath) path = ext4_find_extent(ppath) ext4_split_extent_at(ppath) // ext4_find_extent fails to free path // but zeroout succeeds ext4_ext_show_leaf(inode, path) eh = path[depth].p_hdr // path use-after-free !!! Similar to ext4_split_extent_at(), we use *ppath directly as an input to ext4_ext_show_leaf(). Fix a spelling error by the way. Same problem in ext4_ext_handle_unwritten_extents(). Since 'path' is only used in ext4_ext_show_leaf(), remove 'path' and use *ppath directly. This issue is triggered only when EXT_DEBUG is defined and therefore does not affect functionality.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49968", "url": "https://ubuntu.com/security/CVE-2024-49968", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: filesystems without casefold feature cannot be mounted with siphash When mounting the ext4 filesystem, if the default hash version is set to DX_HASH_SIPHASH but the casefold feature is not set, exit the mounting.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49988", "url": "https://ubuntu.com/security/CVE-2024-49988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: add refcnt to ksmbd_conn struct When sending an oplock break request, opinfo->conn is used, But freed ->conn can be used on multichannel. This patch add a reference count to the ksmbd_conn struct so that it can be freed when it is no longer used.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49890", "url": "https://ubuntu.com/security/CVE-2024-49890", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: ensure the fw_info is not null before using it This resolves the dereference null return value warning reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49891", "url": "https://ubuntu.com/security/CVE-2024-49891", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata paths When the HBA is undergoing a reset or is handling an errata event, NULL ptr dereference crashes may occur in routines such as lpfc_sli_flush_io_rings(), lpfc_dev_loss_tmo_callbk(), or lpfc_abort_handler(). Add NULL ptr checks before dereferencing hdwq pointers that may have been freed due to operations colliding with a reset or errata event handler.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49892", "url": "https://ubuntu.com/security/CVE-2024-49892", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize get_bytes_per_element's default to 1 Variables, used as denominators and maybe not assigned to other values, should not be 0. bytes_per_element_y & bytes_per_element_c are initialized by get_bytes_per_element() which should never return 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50016", "url": "https://ubuntu.com/security/CVE-2024-50016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Avoid overflow assignment in link_dp_cts sampling_rate is an uint8_t but is assigned an unsigned int, and thus it can overflow. As a result, sampling_rate is changed to uint32_t. Similarly, LINK_QUAL_PATTERN_SET has a size of 2 bits, and it should only be assigned to a value less or equal than 4. This fixes 2 INTEGER_OVERFLOW issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49893", "url": "https://ubuntu.com/security/CVE-2024-49893", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check stream_status before it is used [WHAT & HOW] dc_state_get_stream_status can return null, and therefore null must be checked before stream_status is used. This fixes 1 NULL_RETURNS issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49969", "url": "https://ubuntu.com/security/CVE-2024-49969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 color transformation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_hw_format` function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:180 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:181 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:182 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49970", "url": "https://ubuntu.com/security/CVE-2024-49970", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Implement bounds check for stream encoder creation in DCN401 'stream_enc_regs' array is an array of dcn10_stream_enc_registers structures. The array is initialized with four elements, corresponding to the four calls to stream_enc_regs() in the array initializer. This means that valid indices for this array are 0, 1, 2, and 3. The error message 'stream_enc_regs' 4 <= 5 below, is indicating that there is an attempt to access this array with an index of 5, which is out of bounds. This could lead to undefined behavior Here, eng_id is used as an index to access the stream_enc_regs array. If eng_id is 5, this would result in an out-of-bounds access on the stream_enc_regs array. Thus fixing Buffer overflow error in dcn401_stream_encoder_create Found by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn401/dcn401_resource.c:1209 dcn401_stream_encoder_create() error: buffer overflow 'stream_enc_regs' 4 <= 5", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49894", "url": "https://ubuntu.com/security/CVE-2024-49894", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in degamma hardware format translation Fixes index out of bounds issue in `cm_helper_translate_curve_to_degamma_hw_format` function. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49895", "url": "https://ubuntu.com/security/CVE-2024-49895", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format translation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_degamma_hw_format` function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:338 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:339 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:340 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49971", "url": "https://ubuntu.com/security/CVE-2024-49971", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Increase array size of dummy_boolean [WHY] dml2_core_shared_mode_support and dml_core_mode_support access the third element of dummy_boolean, i.e. hw_debug5 = &s->dummy_boolean[2], when dummy_boolean has size of 2. Any assignment to hw_debug5 causes an OVERRUN. [HOW] Increase dummy_boolean's array size to 3. This fixes 2 OVERRUN issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49972", "url": "https://ubuntu.com/security/CVE-2024-49972", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Deallocate DML memory if allocation fails [Why] When DC state create DML memory allocation fails, memory is not deallocated subsequently, resulting in uninitialized structure that is not NULL. [How] Deallocate memory if DML memory allocation fails.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49896", "url": "https://ubuntu.com/security/CVE-2024-49896", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check stream before comparing them [WHAT & HOW] amdgpu_dm can pass a null stream to dc_is_stream_unchanged. It is necessary to check for null before dereferencing them. This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49897", "url": "https://ubuntu.com/security/CVE-2024-49897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check phantom_stream before it is used dcn32_enable_phantom_stream can return null, so returned value must be checked before used. This fixes 1 NULL_RETURNS issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49898", "url": "https://ubuntu.com/security/CVE-2024-49898", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null-initialized variables [WHAT & HOW] drr_timing and subvp_pipe are initialized to null and they are not always assigned new values. It is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49899", "url": "https://ubuntu.com/security/CVE-2024-49899", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize denominators' default to 1 [WHAT & HOW] Variables used as denominators and maybe not assigned to other values, should not be 0. Change their default to 1 so they are never 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49900", "url": "https://ubuntu.com/security/CVE-2024-49900", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uninit-value access of new_ea in ea_buffer syzbot reports that lzo1x_1_do_compress is using uninit-value: ===================================================== BUG: KMSAN: uninit-value in lzo1x_1_do_compress+0x19f9/0x2510 lib/lzo/lzo1x_compress.c:178 ... Uninit was stored to memory at: ea_put fs/jfs/xattr.c:639 [inline] ... Local variable ea_buf created at: __jfs_setxattr+0x5d/0x1ae0 fs/jfs/xattr.c:662 __jfs_xattr_set+0xe6/0x1f0 fs/jfs/xattr.c:934 ===================================================== The reason is ea_buf->new_ea is not initialized properly. Fix this by using memset to empty its content at the beginning in ea_get().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49901", "url": "https://ubuntu.com/security/CVE-2024-49901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm/adreno: Assign msm_gpu->pdev earlier to avoid nullptrs There are some cases, such as the one uncovered by Commit 46d4efcccc68 (\"drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails\") where msm_gpu_cleanup() : platform_set_drvdata(gpu->pdev, NULL); is called on gpu->pdev == NULL, as the GPU device has not been fully initialized yet. Turns out that there's more than just the aforementioned path that causes this to happen (e.g. the case when there's speedbin data in the catalog, but opp-supported-hw is missing in DT). Assigning msm_gpu->pdev earlier seems like the least painful solution to this, therefore do so. Patchwork: https://patchwork.freedesktop.org/patch/602742/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49902", "url": "https://ubuntu.com/security/CVE-2024-49902", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: check if leafidx greater than num leaves per dmap tree syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf. Shaggy: Modified sanity check to apply to control pages as well as leaf pages.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49903", "url": "https://ubuntu.com/security/CVE-2024-49903", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uaf in dbFreeBits [syzbot reported] ================================================================== BUG: KASAN: slab-use-after-free in __mutex_lock_common kernel/locking/mutex.c:587 [inline] BUG: KASAN: slab-use-after-free in __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 Read of size 8 at addr ffff8880229254b0 by task syz-executor357/5216 CPU: 0 UID: 0 PID: 5216 Comm: syz-executor357 Not tainted 6.11.0-rc3-syzkaller-00156-gd7a5aa4b3c00 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 __mutex_lock_common kernel/locking/mutex.c:587 [inline] __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 dbFreeBits+0x7ea/0xd90 fs/jfs/jfs_dmap.c:2390 dbFreeDmap fs/jfs/jfs_dmap.c:2089 [inline] dbFree+0x35b/0x680 fs/jfs/jfs_dmap.c:409 dbDiscardAG+0x8a9/0xa20 fs/jfs/jfs_dmap.c:1650 jfs_ioc_trim+0x433/0x670 fs/jfs/jfs_discard.c:100 jfs_ioctl+0x2d0/0x3e0 fs/jfs/ioctl.c:131 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 Freed by task 5218: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object+0xe0/0x150 mm/kasan/common.c:240 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2252 [inline] slab_free mm/slub.c:4473 [inline] kfree+0x149/0x360 mm/slub.c:4594 dbUnmount+0x11d/0x190 fs/jfs/jfs_dmap.c:278 jfs_mount_rw+0x4ac/0x6a0 fs/jfs/jfs_mount.c:247 jfs_remount+0x3d1/0x6b0 fs/jfs/super.c:454 reconfigure_super+0x445/0x880 fs/super.c:1083 vfs_cmd_reconfigure fs/fsopen.c:263 [inline] vfs_fsconfig_locked fs/fsopen.c:292 [inline] __do_sys_fsconfig fs/fsopen.c:473 [inline] __se_sys_fsconfig+0xb6e/0xf80 fs/fsopen.c:345 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 [Analysis] There are two paths (dbUnmount and jfs_ioc_trim) that generate race condition when accessing bmap, which leads to the occurrence of uaf. Use the lock s_umount to synchronize them, in order to avoid uaf caused by race condition.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49904", "url": "https://ubuntu.com/security/CVE-2024-49904", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add list empty check to avoid null pointer issue Add list empty check to avoid null pointer issues in some corner cases. - list_for_each_entry_safe()", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49989", "url": "https://ubuntu.com/security/CVE-2024-49989", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix double free issue during amdgpu module unload Flexible endpoints use DIGs from available inflexible endpoints, so only the encoders of inflexible links need to be freed. Otherwise, a double free issue may occur when unloading the amdgpu module. [ 279.190523] RIP: 0010:__slab_free+0x152/0x2f0 [ 279.190577] Call Trace: [ 279.190580] [ 279.190582] ? show_regs+0x69/0x80 [ 279.190590] ? die+0x3b/0x90 [ 279.190595] ? do_trap+0xc8/0xe0 [ 279.190601] ? do_error_trap+0x73/0xa0 [ 279.190605] ? __slab_free+0x152/0x2f0 [ 279.190609] ? exc_invalid_op+0x56/0x70 [ 279.190616] ? __slab_free+0x152/0x2f0 [ 279.190642] ? asm_exc_invalid_op+0x1f/0x30 [ 279.190648] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191096] ? __slab_free+0x152/0x2f0 [ 279.191102] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191469] kfree+0x260/0x2b0 [ 279.191474] dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191821] link_destroy+0xd7/0x130 [amdgpu] [ 279.192248] dc_destruct+0x90/0x270 [amdgpu] [ 279.192666] dc_destroy+0x19/0x40 [amdgpu] [ 279.193020] amdgpu_dm_fini+0x16e/0x200 [amdgpu] [ 279.193432] dm_hw_fini+0x26/0x40 [amdgpu] [ 279.193795] amdgpu_device_fini_hw+0x24c/0x400 [amdgpu] [ 279.194108] amdgpu_driver_unload_kms+0x4f/0x70 [amdgpu] [ 279.194436] amdgpu_pci_remove+0x40/0x80 [amdgpu] [ 279.194632] pci_device_remove+0x3a/0xa0 [ 279.194638] device_remove+0x40/0x70 [ 279.194642] device_release_driver_internal+0x1ad/0x210 [ 279.194647] driver_detach+0x4e/0xa0 [ 279.194650] bus_remove_driver+0x6f/0xf0 [ 279.194653] driver_unregister+0x33/0x60 [ 279.194657] pci_unregister_driver+0x44/0x90 [ 279.194662] amdgpu_exit+0x19/0x1f0 [amdgpu] [ 279.194939] __do_sys_delete_module.isra.0+0x198/0x2f0 [ 279.194946] __x64_sys_delete_module+0x16/0x20 [ 279.194950] do_syscall_64+0x58/0x120 [ 279.194954] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 279.194980] ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49905", "url": "https://ubuntu.com/security/CVE-2024-49905", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for 'afb' in amdgpu_dm_plane_handle_cursor_update (v2) This commit adds a null check for the 'afb' variable in the amdgpu_dm_plane_handle_cursor_update function. Previously, 'afb' was assumed to be null, but was used later in the code without a null check. This could potentially lead to a null pointer dereference. Changes since v1: - Moved the null check for 'afb' to the line where 'afb' is used. (Alex) Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:1298 amdgpu_dm_plane_handle_cursor_update() error: we previously assumed 'afb' could be null (see line 1252)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49906", "url": "https://ubuntu.com/security/CVE-2024-49906", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before try to access it [why & how] Change the order of the pipe_ctx->plane_state check to ensure that plane_state is not null before accessing it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49907", "url": "https://ubuntu.com/security/CVE-2024-49907", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before using dc->clk_mgr [WHY & HOW] dc->clk_mgr is null checked previously in the same function, indicating it might be null. Passing \"dc\" to \"dc->hwss.apply_idle_power_optimizations\", which dereferences null \"dc->clk_mgr\". (The function pointer resolves to \"dcn35_apply_idle_power_optimizations\".) This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49908", "url": "https://ubuntu.com/security/CVE-2024-49908", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for 'afb' in amdgpu_dm_update_cursor (v2) This commit adds a null check for the 'afb' variable in the amdgpu_dm_update_cursor function. Previously, 'afb' was assumed to be null at line 8388, but was used later in the code without a null check. This could potentially lead to a null pointer dereference. Changes since v1: - Moved the null check for 'afb' to the line where 'afb' is used. (Alex) Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:8433 amdgpu_dm_update_cursor() \terror: we previously assumed 'afb' could be null (see line 8388)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50177", "url": "https://ubuntu.com/security/CVE-2024-50177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix a UBSAN warning in DML2.1 When programming phantom pipe, since cursor_width is explicity set to 0, this causes calculation logic to trigger overflow for an unsigned int triggering the kernel's UBSAN check as below: [ 40.962845] UBSAN: shift-out-of-bounds in /tmp/amd.EfpumTkO/amd/amdgpu/../display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c:3312:34 [ 40.962849] shift exponent 4294967170 is too large for 32-bit type 'unsigned int' [ 40.962852] CPU: 1 PID: 1670 Comm: gnome-shell Tainted: G W OE 6.5.0-41-generic #41~22.04.2-Ubuntu [ 40.962854] Hardware name: Gigabyte Technology Co., Ltd. X670E AORUS PRO X/X670E AORUS PRO X, BIOS F21 01/10/2024 [ 40.962856] Call Trace: [ 40.962857] [ 40.962860] dump_stack_lvl+0x48/0x70 [ 40.962870] dump_stack+0x10/0x20 [ 40.962872] __ubsan_handle_shift_out_of_bounds+0x1ac/0x360 [ 40.962878] calculate_cursor_req_attributes.cold+0x1b/0x28 [amdgpu] [ 40.963099] dml_core_mode_support+0x6b91/0x16bc0 [amdgpu] [ 40.963327] ? srso_alias_return_thunk+0x5/0x7f [ 40.963331] ? CalculateWatermarksMALLUseAndDRAMSpeedChangeSupport+0x18b8/0x2790 [amdgpu] [ 40.963534] ? srso_alias_return_thunk+0x5/0x7f [ 40.963536] ? dml_core_mode_support+0xb3db/0x16bc0 [amdgpu] [ 40.963730] dml2_core_calcs_mode_support_ex+0x2c/0x90 [amdgpu] [ 40.963906] ? srso_alias_return_thunk+0x5/0x7f [ 40.963909] ? dml2_core_calcs_mode_support_ex+0x2c/0x90 [amdgpu] [ 40.964078] core_dcn4_mode_support+0x72/0xbf0 [amdgpu] [ 40.964247] dml2_top_optimization_perform_optimization_phase+0x1d3/0x2a0 [amdgpu] [ 40.964420] dml2_build_mode_programming+0x23d/0x750 [amdgpu] [ 40.964587] dml21_validate+0x274/0x770 [amdgpu] [ 40.964761] ? srso_alias_return_thunk+0x5/0x7f [ 40.964763] ? resource_append_dpp_pipes_for_plane_composition+0x27c/0x3b0 [amdgpu] [ 40.964942] dml2_validate+0x504/0x750 [amdgpu] [ 40.965117] ? dml21_copy+0x95/0xb0 [amdgpu] [ 40.965291] ? srso_alias_return_thunk+0x5/0x7f [ 40.965295] dcn401_validate_bandwidth+0x4e/0x70 [amdgpu] [ 40.965491] update_planes_and_stream_state+0x38d/0x5c0 [amdgpu] [ 40.965672] update_planes_and_stream_v3+0x52/0x1e0 [amdgpu] [ 40.965845] ? srso_alias_return_thunk+0x5/0x7f [ 40.965849] dc_update_planes_and_stream+0x71/0xb0 [amdgpu] Fix this by adding a guard for checking cursor width before triggering the size calculation.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49909", "url": "https://ubuntu.com/security/CVE-2024-49909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn32_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn32_set_output_transfer_func function. Previously, set_output_gamma was being checked for null, but then it was being dereferenced without any null check. This could lead to a null pointer dereference if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49910", "url": "https://ubuntu.com/security/CVE-2024-49910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn401_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn401_set_output_transfer_func function. Previously, set_output_gamma was being checked for null, but then it was being dereferenced without any null check. This could lead to a null pointer dereference if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49911", "url": "https://ubuntu.com/security/CVE-2024-49911", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn20_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn20_set_output_transfer_func function. Previously, set_output_gamma was being checked for null at line 1030, but then it was being dereferenced without any null check at line 1048. This could potentially lead to a null pointer dereference error if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma at line 1048.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49912", "url": "https://ubuntu.com/security/CVE-2024-49912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Handle null 'stream_status' in 'planes_changed_for_existing_stream' This commit adds a null check for 'stream_status' in the function 'planes_changed_for_existing_stream'. Previously, the code assumed 'stream_status' could be null, but did not handle the case where it was actually null. This could lead to a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:3784 planes_changed_for_existing_stream() error: we previously assumed 'stream_status' could be null (see line 3774)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49913", "url": "https://ubuntu.com/security/CVE-2024-49913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for top_pipe_to_program in commit_planes_for_stream This commit addresses a null pointer dereference issue in the `commit_planes_for_stream` function at line 4140. The issue could occur when `top_pipe_to_program` is null. The fix adds a check to ensure `top_pipe_to_program` is not null before accessing its stream_res. This prevents a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:4140 commit_planes_for_stream() error: we previously assumed 'top_pipe_to_program' could be null (see line 3906)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49914", "url": "https://ubuntu.com/security/CVE-2024-49914", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for pipe_ctx->plane_state in dcn20_program_pipe This commit addresses a null pointer dereference issue in the `dcn20_program_pipe` function. The issue could occur when `pipe_ctx->plane_state` is null. The fix adds a check to ensure `pipe_ctx->plane_state` is not null before accessing. This prevents a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn20/dcn20_hwseq.c:1925 dcn20_program_pipe() error: we previously assumed 'pipe_ctx->plane_state' could be null (see line 1877)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49915", "url": "https://ubuntu.com/security/CVE-2024-49915", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr in dcn32_init_hw This commit addresses a potential null pointer dereference issue in the `dcn32_init_hw` function. The issue could occur when `dc->clk_mgr` is null. The fix adds a check to ensure `dc->clk_mgr` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn32/dcn32_hwseq.c:961 dcn32_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 782)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49916", "url": "https://ubuntu.com/security/CVE-2024-49916", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in dcn401_init_hw This commit addresses a potential null pointer dereference issue in the `dcn401_init_hw` function. The issue could occur when `dc->clk_mgr` or `dc->clk_mgr->funcs` is null. The fix adds a check to ensure `dc->clk_mgr` and `dc->clk_mgr->funcs` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn401/dcn401_hwseq.c:416 dcn401_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 225)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49917", "url": "https://ubuntu.com/security/CVE-2024-49917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in dcn30_init_hw This commit addresses a potential null pointer dereference issue in the `dcn30_init_hw` function. The issue could occur when `dc->clk_mgr` or `dc->clk_mgr->funcs` is null. The fix adds a check to ensure `dc->clk_mgr` and `dc->clk_mgr->funcs` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:789 dcn30_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 628)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49918", "url": "https://ubuntu.com/security/CVE-2024-49918", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for head_pipe in dcn32_acquire_idle_pipe_for_head_pipe_in_layer This commit addresses a potential null pointer dereference issue in the `dcn32_acquire_idle_pipe_for_head_pipe_in_layer` function. The issue could occur when `head_pipe` is null. The fix adds a check to ensure `head_pipe` is not null before asserting it. If `head_pipe` is null, the function returns NULL to prevent a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn32/dcn32_resource.c:2690 dcn32_acquire_idle_pipe_for_head_pipe_in_layer() error: we previously assumed 'head_pipe' could be null (see line 2681)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49919", "url": "https://ubuntu.com/security/CVE-2024-49919", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for head_pipe in dcn201_acquire_free_pipe_for_layer This commit addresses a potential null pointer dereference issue in the `dcn201_acquire_free_pipe_for_layer` function. The issue could occur when `head_pipe` is null. The fix adds a check to ensure `head_pipe` is not null before asserting it. If `head_pipe` is null, the function returns NULL to prevent a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn201/dcn201_resource.c:1016 dcn201_acquire_free_pipe_for_layer() error: we previously assumed 'head_pipe' could be null (see line 1010)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49991", "url": "https://ubuntu.com/security/CVE-2024-49991", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer Pass pointer reference to amdgpu_bo_unref to clear the correct pointer, otherwise amdgpu_bo_unref clear the local variable, the original pointer not set to NULL, this could cause use-after-free bug.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49920", "url": "https://ubuntu.com/security/CVE-2024-49920", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before multiple uses [WHAT & HOW] Poniters, such as stream_enc and dc->bw_vbios, are null checked previously in the same function, so Coverity warns \"implies that stream_enc and dc->bw_vbios might be null\". They are used multiple times in the subsequent code and need to be checked. This fixes 10 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49921", "url": "https://ubuntu.com/security/CVE-2024-49921", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before used [WHAT & HOW] Poniters, such as dc->clk_mgr, are null checked previously in the same function, so Coverity warns \"implies that \"dc->clk_mgr\" might be null\". As a result, these pointers need to be checked when used again. This fixes 10 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49922", "url": "https://ubuntu.com/security/CVE-2024-49922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before using them [WHAT & HOW] These pointers are null checked previously in the same function, indicating they might be null as reported by Coverity. As a result, they need to be checked when used again. This fixes 3 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49923", "url": "https://ubuntu.com/security/CVE-2024-49923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Pass non-null to dcn20_validate_apply_pipe_split_flags [WHAT & HOW] \"dcn20_validate_apply_pipe_split_flags\" dereferences merge, and thus it cannot be a null pointer. Let's pass a valid pointer to avoid null dereference. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49992", "url": "https://ubuntu.com/security/CVE-2024-49992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/stm: Avoid use-after-free issues with crtc and plane ltdc_load() calls functions drm_crtc_init_with_planes(), drm_universal_plane_init() and drm_encoder_init(). These functions should not be called with parameters allocated with devm_kzalloc() to avoid use-after-free issues [1]. Use allocations managed by the DRM framework. Found by Linux Verification Center (linuxtesting.org). [1] https://lore.kernel.org/lkml/u366i76e3qhh3ra5oxrtngjtm2u5lterkekcz6y2jkndhuxzli@diujon4h7qwb/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49993", "url": "https://ubuntu.com/security/CVE-2024-49993", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49924", "url": "https://ubuntu.com/security/CVE-2024-49924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: pxafb: Fix possible use after free in pxafb_task() In the pxafb_probe function, it calls the pxafb_init_fbinfo function, after which &fbi->task is associated with pxafb_task. Moreover, within this pxafb_init_fbinfo function, the pxafb_blank function within the &pxafb_ops struct is capable of scheduling work. If we remove the module which will call pxafb_remove to make cleanup, it will call unregister_framebuffer function which can call do_unregister_framebuffer to free fbi->fb through put_fb_info(fb_info), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | pxafb_task pxafb_remove | unregister_framebuffer(info) | do_unregister_framebuffer(fb_info) | put_fb_info(fb_info) | // free fbi->fb | set_ctrlr_state(fbi, state) | __pxafb_lcd_power(fbi, 0) | fbi->lcd_power(on, &fbi->fb.var) | //use fbi->fb Fix it by ensuring that the work is canceled before proceeding with the cleanup in pxafb_remove. Note that only root user can remove the driver at runtime.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49925", "url": "https://ubuntu.com/security/CVE-2024-49925", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: efifb: Register sysfs groups through driver core The driver core can register and cleanup sysfs groups already. Make use of that functionality to simplify the error handling and cleanup. Also avoid a UAF race during unregistering where the sysctl attributes were usable after the info struct was freed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49926", "url": "https://ubuntu.com/security/CVE-2024-49926", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rcu-tasks: Fix access non-existent percpu rtpcp variable in rcu_tasks_need_gpcb() For kernels built with CONFIG_FORCE_NR_CPUS=y, the nr_cpu_ids is defined as NR_CPUS instead of the number of possible cpus, this will cause the following system panic: smpboot: Allowing 4 CPUs, 0 hotplug CPUs ... setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:512 nr_node_ids:1 ... BUG: unable to handle page fault for address: ffffffff9911c8c8 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 15 Comm: rcu_tasks_trace Tainted: G W 6.6.21 #1 5dc7acf91a5e8e9ac9dcfc35bee0245691283ea6 RIP: 0010:rcu_tasks_need_gpcb+0x25d/0x2c0 RSP: 0018:ffffa371c00a3e60 EFLAGS: 00010082 CR2: ffffffff9911c8c8 CR3: 000000040fa20005 CR4: 00000000001706f0 Call Trace: ? __die+0x23/0x80 ? page_fault_oops+0xa4/0x180 ? exc_page_fault+0x152/0x180 ? asm_exc_page_fault+0x26/0x40 ? rcu_tasks_need_gpcb+0x25d/0x2c0 ? __pfx_rcu_tasks_kthread+0x40/0x40 rcu_tasks_one_gp+0x69/0x180 rcu_tasks_kthread+0x94/0xc0 kthread+0xe8/0x140 ? __pfx_kthread+0x40/0x40 ret_from_fork+0x34/0x80 ? __pfx_kthread+0x40/0x40 ret_from_fork_asm+0x1b/0x80 Considering that there may be holes in the CPU numbers, use the maximum possible cpu number, instead of nr_cpu_ids, for configuring enqueue and dequeue limits. [ neeraj.upadhyay: Fix htmldocs build error reported by Stephen Rothwell ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50007", "url": "https://ubuntu.com/security/CVE-2024-50007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: asihpi: Fix potential OOB array access ASIHPI driver stores some values in the static array upon a response from the driver, and its index depends on the firmware. We shouldn't trust it blindly. This patch adds a sanity check of the array index to fit in the array size.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50017", "url": "https://ubuntu.com/security/CVE-2024-50017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm/ident_map: Use gbpages only where full GB page should be mapped. When ident_pud_init() uses only GB pages to create identity maps, large ranges of addresses not actually requested can be included in the resulting table; a 4K request will map a full GB. This can include a lot of extra address space past that requested, including areas marked reserved by the BIOS. That allows processor speculation into reserved regions, that on UV systems can cause system halts. Only use GB pages when map creation requests include the full GB page of space. Fall back to using smaller 2M pages when only portions of a GB page are included in the request. No attempt is made to coalesce mapping requests. If a request requires a map entry at the 2M (pmd) level, subsequent mapping requests within the same 1G region will also be at the pmd level, even if adjacent or overlapping such requests could have been combined to map a full GB page. Existing usage starts with larger regions and then adds smaller regions, so this should not have any great consequence.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49927", "url": "https://ubuntu.com/security/CVE-2024-49927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/ioapic: Handle allocation failures gracefully Breno observed panics when using failslab under certain conditions during runtime: can not alloc irq_pin_list (-1,0,20) Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed panic+0x4e9/0x590 mp_irqdomain_alloc+0x9ab/0xa80 irq_domain_alloc_irqs_locked+0x25d/0x8d0 __irq_domain_alloc_irqs+0x80/0x110 mp_map_pin_to_irq+0x645/0x890 acpi_register_gsi_ioapic+0xe6/0x150 hpet_open+0x313/0x480 That's a pointless panic which is a leftover of the historic IO/APIC code which panic'ed during early boot when the interrupt allocation failed. The only place which might justify panic is the PIT/HPET timer_check() code which tries to figure out whether the timer interrupt is delivered through the IO/APIC. But that code does not require to handle interrupt allocation failures. If the interrupt cannot be allocated then timer delivery fails and it either panics due to that or falls back to legacy mode. Cure this by removing the panic wrapper around __add_pin_to_irq_node() and making mp_irqdomain_alloc() aware of the failure condition and handle it as any other failure in this function gracefully.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50008", "url": "https://ubuntu.com/security/CVE-2024-50008", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_cmd_802_11_scan_ext() Replace one-element array with a flexible-array member in `struct host_cmd_ds_802_11_scan_ext`. With this, fix the following warning: elo 16 17:51:58 surfacebook kernel: ------------[ cut here ]------------ elo 16 17:51:58 surfacebook kernel: memcpy: detected field-spanning write (size 243) of single field \"ext_scan->tlv_buffer\" at drivers/net/wireless/marvell/mwifiex/scan.c:2239 (size 1) elo 16 17:51:58 surfacebook kernel: WARNING: CPU: 0 PID: 498 at drivers/net/wireless/marvell/mwifiex/scan.c:2239 mwifiex_cmd_802_11_scan_ext+0x83/0x90 [mwifiex]", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50018", "url": "https://ubuntu.com/security/CVE-2024-50018", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49928", "url": "https://ubuntu.com/security/CVE-2024-49928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: avoid reading out of bounds when loading TX power FW elements Because the loop-expression will do one more time before getting false from cond-expression, the original code copied one more entry size beyond valid region. Fix it by moving the entry copy to loop-body.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50178", "url": "https://ubuntu.com/security/CVE-2024-50178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: loongson3: Use raw_smp_processor_id() in do_service_request() Use raw_smp_processor_id() instead of plain smp_processor_id() in do_service_request(), otherwise we may get some errors with the driver enabled: BUG: using smp_processor_id() in preemptible [00000000] code: (udev-worker)/208 caller is loongson3_cpufreq_probe+0x5c/0x250 [loongson3_cpufreq]", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50009", "url": "https://ubuntu.com/security/CVE-2024-50009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: amd-pstate: add check for cpufreq_cpu_get's return value cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it and return in case of error. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49994", "url": "https://ubuntu.com/security/CVE-2024-49994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix integer overflow in BLKSECDISCARD I independently rediscovered \tcommit 22d24a544b0d49bbcbd61c8c0eaf77d3c9297155 \tblock: fix overflow in blk_ioctl_discard() but for secure erase. Same problem: \tuint64_t r[2] = {512, 18446744073709551104ULL}; \tioctl(fd, BLKSECDISCARD, r); will enter near infinite loop inside blkdev_issue_secure_erase(): \ta.out: attempt to access beyond end of device \tloop0: rw=5, sector=3399043073, nr_sectors = 1024 limit=2048 \tbio_check_eod: 3286214 callbacks suppressed", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49929", "url": "https://ubuntu.com/security/CVE-2024-49929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: avoid NULL pointer dereference iwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta pointer is not NULL. It retrieves this pointer using iwl_mvm_sta_from_mac80211, which is dereferencing the ieee80211_sta pointer. If sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL pointer. Fix this by checking the sta pointer before retrieving the mvmsta from it. If sta is not NULL, then mvmsta isn't either.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49995", "url": "https://ubuntu.com/security/CVE-2024-49995", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: guard against string buffer overrun Smatch reports that copying media_name and if_name to name_parts may overwrite the destination. .../bearer.c:166 bearer_name_validate() error: strcpy() 'media_name' too large for 'name_parts->media_name' (32 vs 16) .../bearer.c:167 bearer_name_validate() error: strcpy() 'if_name' too large for 'name_parts->if_name' (1010102 vs 16) This does seem to be the case so guard against this possibility by using strscpy() and failing if truncation occurs. Introduced by commit b97bf3fd8f6a (\"[TIPC] Initial merge\") Compile tested only.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49962", "url": "https://ubuntu.com/security/CVE-2024-49962", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in acpi_db_convert_to_package() ACPICA commit 4d4547cf13cca820ff7e0f859ba83e1a610b9fd0 ACPI_ALLOCATE_ZEROED() may fail, elements might be NULL and will cause NULL pointer dereference later. [ rjw: Subject and changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49930", "url": "https://ubuntu.com/security/CVE-2024-49930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix array out-of-bound access in SoC stats Currently, the ath11k_soc_dp_stats::hal_reo_error array is defined with a maximum size of DP_REO_DST_RING_MAX. However, the ath11k_dp_process_rx() function access ath11k_soc_dp_stats::hal_reo_error using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath11k_dp_process_rx() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49931", "url": "https://ubuntu.com/security/CVE-2024-49931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix array out-of-bound access in SoC stats Currently, the ath12k_soc_dp_stats::hal_reo_error array is defined with a maximum size of DP_REO_DST_RING_MAX. However, the ath12k_dp_rx_process() function access ath12k_soc_dp_stats::hal_reo_error using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath12k_dp_rx_process() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49932", "url": "https://ubuntu.com/security/CVE-2024-49932", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: don't readahead the relocation inode on RST On relocation we're doing readahead on the relocation inode, but if the filesystem is backed by a RAID stripe tree we can get ENOENT (e.g. due to preallocated extents not being mapped in the RST) from the lookup. But readahead doesn't handle the error and submits invalid reads to the device, causing an assertion in the scatter-gather list code: BTRFS info (device nvme1n1): balance: start -d -m -s BTRFS info (device nvme1n1): relocating block group 6480920576 flags data|raid0 BTRFS error (device nvme1n1): cannot find raid-stripe for logical [6481928192, 6481969152] devid 2, profile raid0 ------------[ cut here ]------------ kernel BUG at include/linux/scatterlist.h:115! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 1012 Comm: btrfs Not tainted 6.10.0-rc7+ #567 RIP: 0010:__blk_rq_map_sg+0x339/0x4a0 RSP: 0018:ffffc90001a43820 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffea00045d4802 RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000 RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000001000 R12: ffff8881003d10b8 R13: ffffc90001a438f0 R14: 0000000000000000 R15: 0000000000003000 FS: 00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000002cd11000 CR3: 00000001109ea001 CR4: 0000000000370eb0 Call Trace: ? __die_body.cold+0x14/0x25 ? die+0x2e/0x50 ? do_trap+0xca/0x110 ? do_error_trap+0x65/0x80 ? __blk_rq_map_sg+0x339/0x4a0 ? exc_invalid_op+0x50/0x70 ? __blk_rq_map_sg+0x339/0x4a0 ? asm_exc_invalid_op+0x1a/0x20 ? __blk_rq_map_sg+0x339/0x4a0 nvme_prep_rq.part.0+0x9d/0x770 nvme_queue_rq+0x7d/0x1e0 __blk_mq_issue_directly+0x2a/0x90 ? blk_mq_get_budget_and_tag+0x61/0x90 blk_mq_try_issue_list_directly+0x56/0xf0 blk_mq_flush_plug_list.part.0+0x52b/0x5d0 __blk_flush_plug+0xc6/0x110 blk_finish_plug+0x28/0x40 read_pages+0x160/0x1c0 page_cache_ra_unbounded+0x109/0x180 relocate_file_extent_cluster+0x611/0x6a0 ? btrfs_search_slot+0xba4/0xd20 ? balance_dirty_pages_ratelimited_flags+0x26/0xb00 relocate_data_extent.constprop.0+0x134/0x160 relocate_block_group+0x3f2/0x500 btrfs_relocate_block_group+0x250/0x430 btrfs_relocate_chunk+0x3f/0x130 btrfs_balance+0x71b/0xef0 ? kmalloc_trace_noprof+0x13b/0x280 btrfs_ioctl+0x2c2e/0x3030 ? kvfree_call_rcu+0x1e6/0x340 ? list_lru_add_obj+0x66/0x80 ? mntput_no_expire+0x3a/0x220 __x64_sys_ioctl+0x96/0xc0 do_syscall_64+0x54/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fcc04514f9b Code: Unable to access opcode bytes at 0x7fcc04514f71. RSP: 002b:00007ffeba923370 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fcc04514f9b RDX: 00007ffeba923460 RSI: 00000000c4009420 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000013 R09: 0000000000000001 R10: 00007fcc043fbba8 R11: 0000000000000246 R12: 00007ffeba924fc5 R13: 00007ffeba923460 R14: 0000000000000002 R15: 00000000004d4bb0 Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:__blk_rq_map_sg+0x339/0x4a0 RSP: 0018:ffffc90001a43820 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffea00045d4802 RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000 RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000001000 R12: ffff8881003d10b8 R13: ffffc90001a438f0 R14: 0000000000000000 R15: 0000000000003000 FS: 00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcc04514f71 CR3: 00000001109ea001 CR4: 0000000000370eb0 Kernel p ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49933", "url": "https://ubuntu.com/security/CVE-2024-49933", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk_iocost: fix more out of bound shifts Recently running UBSAN caught few out of bound shifts in the ioc_forgive_debts() function: UBSAN: shift-out-of-bounds in block/blk-iocost.c:2142:38 shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long long') ... UBSAN: shift-out-of-bounds in block/blk-iocost.c:2144:30 shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long long') ... Call Trace: dump_stack_lvl+0xca/0x130 __ubsan_handle_shift_out_of_bounds+0x22c/0x280 ? __lock_acquire+0x6441/0x7c10 ioc_timer_fn+0x6cec/0x7750 ? blk_iocost_init+0x720/0x720 ? call_timer_fn+0x5d/0x470 call_timer_fn+0xfa/0x470 ? blk_iocost_init+0x720/0x720 __run_timer_base+0x519/0x700 ... Actual impact of this issue was not identified but I propose to fix the undefined behaviour. The proposed fix to prevent those out of bound shifts consist of precalculating exponent before using it the shift operations by taking min value from the actual exponent and maximum possible number of bits.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49934", "url": "https://ubuntu.com/security/CVE-2024-49934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/inode: Prevent dump_mapping() accessing invalid dentry.d_name.name It's observed that a crash occurs during hot-remove a memory device, in which user is accessing the hugetlb. See calltrace as following: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 14045 at arch/x86/mm/fault.c:1278 do_user_addr_fault+0x2a0/0x790 Modules linked in: kmem device_dax cxl_mem cxl_pmem cxl_port cxl_pci dax_hmem dax_pmem nd_pmem cxl_acpi nd_btt cxl_core crc32c_intel nvme virtiofs fuse nvme_core nfit libnvdimm dm_multipath scsi_dh_rdac scsi_dh_emc s mirror dm_region_hash dm_log dm_mod CPU: 1 PID: 14045 Comm: daxctl Not tainted 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:do_user_addr_fault+0x2a0/0x790 Code: 48 8b 00 a8 04 0f 84 b5 fe ff ff e9 1c ff ff ff 4c 89 e9 4c 89 e2 be 01 00 00 00 bf 02 00 00 00 e8 b5 ef 24 00 e9 42 fe ff ff <0f> 0b 48 83 c4 08 4c 89 ea 48 89 ee 4c 89 e7 5b 5d 41 5c 41 5d 41 RSP: 0000:ffffc90000a575f0 EFLAGS: 00010046 RAX: ffff88800c303600 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000001000 RSI: ffffffff82504162 RDI: ffffffff824b2c36 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffc90000a57658 R13: 0000000000001000 R14: ffff88800bc2e040 R15: 0000000000000000 FS: 00007f51cb57d880(0000) GS:ffff88807fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000001000 CR3: 00000000072e2004 CR4: 00000000001706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn+0x8d/0x190 ? do_user_addr_fault+0x2a0/0x790 ? report_bug+0x1c3/0x1d0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? do_user_addr_fault+0x2a0/0x790 ? exc_page_fault+0x31/0x200 exc_page_fault+0x68/0x200 <...snip...> BUG: unable to handle page fault for address: 0000000000001000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI ---[ end trace 0000000000000000 ]--- BUG: unable to handle page fault for address: 0000000000001000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 14045 Comm: daxctl Kdump: loaded Tainted: G W 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:dentry_name+0x1f4/0x440 <...snip...> ? dentry_name+0x2fa/0x440 vsnprintf+0x1f3/0x4f0 vprintk_store+0x23a/0x540 vprintk_emit+0x6d/0x330 _printk+0x58/0x80 dump_mapping+0x10b/0x1a0 ? __pfx_free_object_rcu+0x10/0x10 __dump_page+0x26b/0x3e0 ? vprintk_emit+0xe0/0x330 ? _printk+0x58/0x80 ? dump_page+0x17/0x50 dump_page+0x17/0x50 do_migrate_range+0x2f7/0x7f0 ? do_migrate_range+0x42/0x7f0 ? offline_pages+0x2f4/0x8c0 offline_pages+0x60a/0x8c0 memory_subsys_offline+0x9f/0x1c0 ? lockdep_hardirqs_on+0x77/0x100 ? _raw_spin_unlock_irqrestore+0x38/0x60 device_offline+0xe3/0x110 state_store+0x6e/0xc0 kernfs_fop_write_iter+0x143/0x200 vfs_write+0x39f/0x560 ksys_write+0x65/0xf0 do_syscall_64+0x62/0x130 Previously, some sanity check have been done in dump_mapping() before the print facility parsing '%pd' though, it's still possible to run into an invalid dentry.d_name.name. Since dump_mapping() only needs to dump the filename only, retrieve it by itself in a safer way to prevent an unnecessary crash. Note that either retrieving the filename with '%pd' or strncpy_from_kernel_nofault(), the filename could be unreliable.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49935", "url": "https://ubuntu.com/security/CVE-2024-49935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: PAD: fix crash in exit_round_robin() The kernel occasionally crashes in cpumask_clear_cpu(), which is called within exit_round_robin(), because when executing clear_bit(nr, addr) with nr set to 0xffffffff, the address calculation may cause misalignment within the memory, leading to access to an invalid memory address. ---------- BUG: unable to handle kernel paging request at ffffffffe0740618 ... CPU: 3 PID: 2919323 Comm: acpi_pad/14 Kdump: loaded Tainted: G OE X --------- - - 4.18.0-425.19.2.el8_7.x86_64 #1 ... RIP: 0010:power_saving_thread+0x313/0x411 [acpi_pad] Code: 89 cd 48 89 d3 eb d1 48 c7 c7 55 70 72 c0 e8 64 86 b0 e4 c6 05 0d a1 02 00 01 e9 bc fd ff ff 45 89 e4 42 8b 04 a5 20 82 72 c0 48 0f b3 05 f4 9c 01 00 42 c7 04 a5 20 82 72 c0 ff ff ff ff 31 RSP: 0018:ff72a5d51fa77ec8 EFLAGS: 00010202 RAX: 00000000ffffffff RBX: ff462981e5d8cb80 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246 RBP: ff46297556959d80 R08: 0000000000000382 R09: ff46297c8d0f38d8 R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000000e R13: 0000000000000000 R14: ffffffffffffffff R15: 000000000000000e FS: 0000000000000000(0000) GS:ff46297a800c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffe0740618 CR3: 0000007e20410004 CR4: 0000000000771ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? acpi_pad_add+0x120/0x120 [acpi_pad] kthread+0x10b/0x130 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x1f/0x40 ... CR2: ffffffffe0740618 crash> dis -lr ffffffffc0726923 ... /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 114 0xffffffffc0726918 :\tmov %r12d,%r12d /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 325 0xffffffffc072691b :\tmov -0x3f8d7de0(,%r12,4),%eax /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./arch/x86/include/asm/bitops.h: 80 0xffffffffc0726923 :\tlock btr %rax,0x19cf4(%rip) # 0xffffffffc0740620 crash> px tsk_in_cpu[14] $66 = 0xffffffff crash> px 0xffffffffc072692c+0x19cf4 $99 = 0xffffffffc0740620 crash> sym 0xffffffffc0740620 ffffffffc0740620 (b) pad_busy_cpus_bits [acpi_pad] crash> px pad_busy_cpus_bits[0] $42 = 0xfffc0 ---------- To fix this, ensure that tsk_in_cpu[tsk_index] != -1 before calling cpumask_clear_cpu() in exit_round_robin(), just as it is done in round_robin_cpu(). [ rjw: Subject edit, avoid updates to the same value ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49936", "url": "https://ubuntu.com/security/CVE-2024-49936", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/xen-netback: prevent UAF in xenvif_flush_hash() During the list_for_each_entry_rcu iteration call of xenvif_flush_hash, kfree_rcu does not exist inside the rcu read critical section, so if kfree_rcu is called when the rcu grace period ends during the iteration, UAF occurs when accessing head->next after the entry becomes free. Therefore, to solve this, you need to change it to list_for_each_entry_safe.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49937", "url": "https://ubuntu.com/security/CVE-2024-49937", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Set correct chandef when starting CAC When starting CAC in a mode other than AP mode, it return a \"WARNING: CPU: 0 PID: 63 at cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]\" caused by the chandef.chan being null at the end of CAC. Solution: Ensure the channel definition is set for the different modes when starting CAC to avoid getting a NULL 'chan' at the end of CAC. Call Trace: ? show_regs.part.0+0x14/0x16 ? __warn+0x67/0xc0 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? report_bug+0xa7/0x130 ? exc_overflow+0x30/0x30 ? handle_bug+0x27/0x50 ? exc_invalid_op+0x18/0x60 ? handle_exception+0xf6/0xf6 ? exc_overflow+0x30/0x30 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? exc_overflow+0x30/0x30 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? regulatory_propagate_dfs_state.cold+0x1b/0x4c [cfg80211] ? cfg80211_propagate_cac_done_wk+0x1a/0x30 [cfg80211] ? process_one_work+0x165/0x280 ? worker_thread+0x120/0x3f0 ? kthread+0xc2/0xf0 ? process_one_work+0x280/0x280 ? kthread_complete_and_exit+0x20/0x20 ? ret_from_fork+0x19/0x24 [shorten subject, remove OCB, reorder cases to match previous list]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49938", "url": "https://ubuntu.com/security/CVE-2024-49938", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmit Syzbot points out that skb_trim() has a sanity check on the existing length of the skb, which can be uninitialised in some error paths. The intent here is clearly just to reset the length to zero before resubmitting, so switch to calling __skb_set_length(skb, 0) directly. In addition, __skb_set_length() already contains a call to skb_reset_tail_pointer(), so remove the redundant call. The syzbot report came from ath9k_hif_usb_reg_in_cb(), but there's a similar usage of skb_trim() in ath9k_hif_usb_rx_cb(), change both while we're at it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49939", "url": "https://ubuntu.com/security/CVE-2024-49939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: avoid to add interface to list twice when SER If SER L2 occurs during the WoWLAN resume flow, the add interface flow is triggered by ieee80211_reconfig(). However, due to rtw89_wow_resume() return failure, it will cause the add interface flow to be executed again, resulting in a double add list and causing a kernel panic. Therefore, we have added a check to prevent double adding of the list. list_add double add: new=ffff99d6992e2010, prev=ffff99d6992e2010, next=ffff99d695302628. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:37! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G W O 6.6.30-02659-gc18865c4dfbd #1 770df2933251a0e3c888ba69d1053a817a6376a7 Hardware name: HP Grunt/Grunt, BIOS Google_Grunt.11031.169.0 06/24/2021 Workqueue: events_freezable ieee80211_restart_work [mac80211] RIP: 0010:__list_add_valid_or_report+0x5e/0xb0 Code: c7 74 18 48 39 ce 74 13 b0 01 59 5a 5e 5f 41 58 41 59 41 5a 5d e9 e2 d6 03 00 cc 48 c7 c7 8d 4f 17 83 48 89 c2 e8 02 c0 00 00 <0f> 0b 48 c7 c7 aa 8c 1c 83 e8 f4 bf 00 00 0f 0b 48 c7 c7 c8 bc 12 RSP: 0018:ffffa91b8007bc50 EFLAGS: 00010246 RAX: 0000000000000058 RBX: ffff99d6992e0900 RCX: a014d76c70ef3900 RDX: ffffa91b8007bae8 RSI: 00000000ffffdfff RDI: 0000000000000001 RBP: ffffa91b8007bc88 R08: 0000000000000000 R09: ffffa91b8007bae0 R10: 00000000ffffdfff R11: ffffffff83a79800 R12: ffff99d695302060 R13: ffff99d695300900 R14: ffff99d6992e1be0 R15: ffff99d6992e2010 FS: 0000000000000000(0000) GS:ffff99d6aac00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000078fbdba43480 CR3: 000000010e464000 CR4: 00000000001506f0 Call Trace: ? __die_body+0x1f/0x70 ? die+0x3d/0x60 ? do_trap+0xa4/0x110 ? __list_add_valid_or_report+0x5e/0xb0 ? do_error_trap+0x6d/0x90 ? __list_add_valid_or_report+0x5e/0xb0 ? handle_invalid_op+0x30/0x40 ? __list_add_valid_or_report+0x5e/0xb0 ? exc_invalid_op+0x3c/0x50 ? asm_exc_invalid_op+0x16/0x20 ? __list_add_valid_or_report+0x5e/0xb0 rtw89_ops_add_interface+0x309/0x310 [rtw89_core 7c32b1ee6854761c0321027c8a58c5160e41f48f] drv_add_interface+0x5c/0x130 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ieee80211_reconfig+0x241/0x13d0 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ? finish_wait+0x3e/0x90 ? synchronize_rcu_expedited+0x174/0x260 ? sync_rcu_exp_done_unlocked+0x50/0x50 ? wake_bit_function+0x40/0x40 ieee80211_restart_work+0xf0/0x140 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] process_scheduled_works+0x1e5/0x480 worker_thread+0xea/0x1e0 kthread+0xdb/0x110 ? move_linked_works+0x90/0x90 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork+0x3b/0x50 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork_asm+0x11/0x20 Modules linked in: dm_integrity async_xor xor async_tx lz4 lz4_compress zstd zstd_compress zram zsmalloc rfcomm cmac uinput algif_hash algif_skcipher af_alg btusb btrtl iio_trig_hrtimer industrialio_sw_trigger btmtk industrialio_configfs btbcm btintel uvcvideo videobuf2_vmalloc iio_trig_sysfs videobuf2_memops videobuf2_v4l2 videobuf2_common uvc snd_hda_codec_hdmi veth snd_hda_intel snd_intel_dspcfg acpi_als snd_hda_codec industrialio_triggered_buffer kfifo_buf snd_hwdep industrialio i2c_piix4 snd_hda_core designware_i2s ip6table_nat snd_soc_max98357a xt_MASQUERADE xt_cgroup snd_soc_acp_rt5682_mach fuse rtw89_8922ae(O) rtw89_8922a(O) rtw89_pci(O) rtw89_core(O) 8021q mac80211(O) bluetooth ecdh_generic ecc cfg80211 r8152 mii joydev gsmi: Log Shutdown Reason 0x03 ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49940", "url": "https://ubuntu.com/security/CVE-2024-49940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: prevent possible tunnel refcount underflow When a session is created, it sets a backpointer to its tunnel. When the session refcount drops to 0, l2tp_session_free drops the tunnel refcount if session->tunnel is non-NULL. However, session->tunnel is set in l2tp_session_create, before the tunnel refcount is incremented by l2tp_session_register, which leaves a small window where session->tunnel is non-NULL when the tunnel refcount hasn't been bumped. Moving the assignment to l2tp_session_register is trivial but l2tp_session_create calls l2tp_session_set_header_len which uses session->tunnel to get the tunnel's encap. Add an encap arg to l2tp_session_set_header_len to avoid using session->tunnel. If l2tpv3 sessions have colliding IDs, it is possible for l2tp_v3_session_get to race with l2tp_session_register and fetch a session which doesn't yet have session->tunnel set. Add a check for this case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49941", "url": "https://ubuntu.com/security/CVE-2024-49941", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpiolib: Fix potential NULL pointer dereference in gpiod_get_label() In `gpiod_get_label()`, it is possible that `srcu_dereference_check()` may return a NULL pointer, leading to a scenario where `label->str` is accessed without verifying if `label` itself is NULL. This patch adds a proper NULL check for `label` before accessing `label->str`. The check for `label->str != NULL` is removed because `label->str` can never be NULL if `label` is not NULL. This fixes the issue where the label name was being printed as `(efault)` when dumping the sysfs GPIO file when `label == NULL`.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49996", "url": "https://ubuntu.com/security/CVE-2024-49996", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: Fix buffer overflow when parsing NFS reparse points ReparseDataLength is sum of the InodeType size and DataBuffer size. So to get DataBuffer size it is needed to subtract InodeType's size from ReparseDataLength. Function cifs_strndup_from_utf16() is currentlly accessing buf->DataBuffer at position after the end of the buffer because it does not subtract InodeType size from the length. Fix this problem and correctly subtract variable len. Member InodeType is present only when reparse buffer is large enough. Check for ReparseDataLength before accessing InodeType to prevent another invalid memory access. Major and minor rdev values are present also only when reparse buffer is large enough. Check for reparse buffer size before calling reparse_mkdev().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49942", "url": "https://ubuntu.com/security/CVE-2024-49942", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Prevent null pointer access in xe_migrate_copy xe_migrate_copy designed to copy content of TTM resources. When source resource is null, it will trigger a NULL pointer dereference in xe_migrate_copy. To avoid this situation, update lacks source flag to true for this case, the flag will trigger xe_migrate_clear rather than xe_migrate_copy. Issue trace: <7> [317.089847] xe 0000:00:02.0: [drm:xe_migrate_copy [xe]] Pass 14, sizes: 4194304 & 4194304 <7> [317.089945] xe 0000:00:02.0: [drm:xe_migrate_copy [xe]] Pass 15, sizes: 4194304 & 4194304 <1> [317.128055] BUG: kernel NULL pointer dereference, address: 0000000000000010 <1> [317.128064] #PF: supervisor read access in kernel mode <1> [317.128066] #PF: error_code(0x0000) - not-present page <6> [317.128069] PGD 0 P4D 0 <4> [317.128071] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI <4> [317.128074] CPU: 1 UID: 0 PID: 1440 Comm: kunit_try_catch Tainted: G U N 6.11.0-rc7-xe #1 <4> [317.128078] Tainted: [U]=USER, [N]=TEST <4> [317.128080] Hardware name: Intel Corporation Lunar Lake Client Platform/LNL-M LP5 RVP1, BIOS LNLMFWI1.R00.3221.D80.2407291239 07/29/2024 <4> [317.128082] RIP: 0010:xe_migrate_copy+0x66/0x13e0 [xe] <4> [317.128158] Code: 00 00 48 89 8d e0 fe ff ff 48 8b 40 10 4c 89 85 c8 fe ff ff 44 88 8d bd fe ff ff 65 48 8b 3c 25 28 00 00 00 48 89 7d d0 31 ff <8b> 79 10 48 89 85 a0 fe ff ff 48 8b 00 48 89 b5 d8 fe ff ff 83 ff <4> [317.128162] RSP: 0018:ffffc9000167f9f0 EFLAGS: 00010246 <4> [317.128164] RAX: ffff8881120d8028 RBX: ffff88814d070428 RCX: 0000000000000000 <4> [317.128166] RDX: ffff88813cb99c00 RSI: 0000000004000000 RDI: 0000000000000000 <4> [317.128168] RBP: ffffc9000167fbb8 R08: ffff88814e7b1f08 R09: 0000000000000001 <4> [317.128170] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88814e7b1f08 <4> [317.128172] R13: ffff88814e7b1f08 R14: ffff88813cb99c00 R15: 0000000000000001 <4> [317.128174] FS: 0000000000000000(0000) GS:ffff88846f280000(0000) knlGS:0000000000000000 <4> [317.128176] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [317.128178] CR2: 0000000000000010 CR3: 000000011f676004 CR4: 0000000000770ef0 <4> [317.128180] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 <4> [317.128182] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400 <4> [317.128184] PKRU: 55555554 <4> [317.128185] Call Trace: <4> [317.128187] <4> [317.128189] ? show_regs+0x67/0x70 <4> [317.128194] ? __die_body+0x20/0x70 <4> [317.128196] ? __die+0x2b/0x40 <4> [317.128198] ? page_fault_oops+0x15f/0x4e0 <4> [317.128203] ? do_user_addr_fault+0x3fb/0x970 <4> [317.128205] ? lock_acquire+0xc7/0x2e0 <4> [317.128209] ? exc_page_fault+0x87/0x2b0 <4> [317.128212] ? asm_exc_page_fault+0x27/0x30 <4> [317.128216] ? xe_migrate_copy+0x66/0x13e0 [xe] <4> [317.128263] ? __lock_acquire+0xb9d/0x26f0 <4> [317.128265] ? __lock_acquire+0xb9d/0x26f0 <4> [317.128267] ? sg_free_append_table+0x20/0x80 <4> [317.128271] ? lock_acquire+0xc7/0x2e0 <4> [317.128273] ? mark_held_locks+0x4d/0x80 <4> [317.128275] ? trace_hardirqs_on+0x1e/0xd0 <4> [317.128278] ? _raw_spin_unlock_irqrestore+0x31/0x60 <4> [317.128281] ? __pm_runtime_resume+0x60/0xa0 <4> [317.128284] xe_bo_move+0x682/0xc50 [xe] <4> [317.128315] ? lock_is_held_type+0xaa/0x120 <4> [317.128318] ttm_bo_handle_move_mem+0xe5/0x1a0 [ttm] <4> [317.128324] ttm_bo_validate+0xd1/0x1a0 [ttm] <4> [317.128328] shrink_test_run_device+0x721/0xc10 [xe] <4> [317.128360] ? find_held_lock+0x31/0x90 <4> [317.128363] ? lock_release+0xd1/0x2a0 <4> [317.128365] ? __pfx_kunit_generic_run_threadfn_adapter+0x10/0x10 [kunit] <4> [317.128370] xe_bo_shrink_kunit+0x11/0x20 [xe] <4> [317.128397] kunit_try_run_case+0x6e/0x150 [kunit] <4> [317.128400] ? trace_hardirqs_on+0x1e/0xd0 <4> [317.128402] ? _raw_spin_unlock_irqrestore+0x31/0x60 <4> [317.128404] kunit_generic_run_threadfn_adapter+0x1e/0x40 [ku ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49943", "url": "https://ubuntu.com/security/CVE-2024-49943", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc_submit: add missing locking in wedged_fini Any non-wedged queue can have a zero refcount here and can be running concurrently with an async queue destroy, therefore dereferencing the queue ptr to check wedge status after the lookup can trigger UAF if queue is not wedged. Fix this by keeping the submission_state lock held around the check to postpone the free and make the check safe, before dropping again around the put() to avoid the deadlock. (cherry picked from commit d28af0b6b9580b9f90c265a7da0315b0ad20bbfd)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50011", "url": "https://ubuntu.com/security/CVE-2024-50011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: soc-acpi-intel-rpl-match: add missing empty item There is no links_num in struct snd_soc_acpi_mach {}, and we test !link->num_adr as a condition to end the loop in hda_sdw_machine_select(). So an empty item in struct snd_soc_acpi_link_adr array is required.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50174", "url": "https://ubuntu.com/security/CVE-2024-50174", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix race when converting group handle to group object XArray provides it's own internal lock which protects the internal array when entries are being simultaneously added and removed. However there is still a race between retrieving the pointer from the XArray and incrementing the reference count. To avoid this race simply hold the internal XArray lock when incrementing the reference count, this ensures there cannot be a racing call to xa_erase().", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49944", "url": "https://ubuntu.com/security/CVE-2024-49944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_start In sctp_listen_start() invoked by sctp_inet_listen(), it should set the sk_state back to CLOSED if sctp_autobind() fails due to whatever reason. Otherwise, next time when calling sctp_inet_listen(), if sctp_sk(sk)->reuse is already set via setsockopt(SCTP_REUSE_PORT), sctp_sk(sk)->bind_hash will be dereferenced as sk_state is LISTENING, which causes a crash as bind_hash is NULL. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:sctp_inet_listen+0x7f0/0xa20 net/sctp/socket.c:8617 Call Trace: __sys_listen_socket net/socket.c:1883 [inline] __sys_listen+0x1b7/0x230 net/socket.c:1894 __do_sys_listen net/socket.c:1902 [inline]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49945", "url": "https://ubuntu.com/security/CVE-2024-49945", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/ncsi: Disable the ncsi work before freeing the associated structure The work function can run after the ncsi device is freed, resulting in use-after-free bugs or kernel panic.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49946", "url": "https://ubuntu.com/security/CVE-2024-49946", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: do not assume bh is held in ppp_channel_bridge_input() Networking receive path is usually handled from BH handler. However, some protocols need to acquire the socket lock, and packets might be stored in the socket backlog is the socket was owned by a user process. In this case, release_sock(), __release_sock(), and sk_backlog_rcv() might call the sk->sk_backlog_rcv() handler in process context. sybot caught ppp was not considering this case in ppp_channel_bridge_input() : WARNING: inconsistent lock state 6.11.0-rc7-syzkaller-g5f5673607153 #0 Not tainted -------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. ksoftirqd/1/24 [HC0[0]:SC1[1]:HE1:SE0] takes: ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 {SOFTIRQ-ON-W} state was registered at: lock_acquire+0x240/0x728 kernel/locking/lockdep.c:5759 __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline] _raw_spin_lock+0x48/0x60 kernel/locking/spinlock.c:154 spin_lock include/linux/spinlock.h:351 [inline] ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline] ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0xfc/0x314 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv include/net/sock.h:1111 [inline] __release_sock+0x1a8/0x3d8 net/core/sock.c:3004 release_sock+0x68/0x1b8 net/core/sock.c:3558 pppoe_sendmsg+0xc8/0x5d8 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x374/0x4f4 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __arm64_sys_sendto+0xd8/0xf8 net/socket.c:2212 __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:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 irq event stamp: 282914 hardirqs last enabled at (282914): [] __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:151 [inline] hardirqs last enabled at (282914): [] _raw_spin_unlock_irqrestore+0x38/0x98 kernel/locking/spinlock.c:194 hardirqs last disabled at (282913): [] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline] hardirqs last disabled at (282913): [] _raw_spin_lock_irqsave+0x2c/0x7c kernel/locking/spinlock.c:162 softirqs last enabled at (282904): [] softirq_handle_end kernel/softirq.c:400 [inline] softirqs last enabled at (282904): [] handle_softirqs+0xa3c/0xbfc kernel/softirq.c:582 softirqs last disabled at (282909): [] run_ksoftirqd+0x70/0x158 kernel/softirq.c:928 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&pch->downl); lock(&pch->downl); *** DEADLOCK *** 1 lock held by ksoftirqd/1/24: #0: ffff80008f74dfa0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire+0x10/0x4c include/linux/rcupdate.h:325 stack backtrace: CPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 6.11.0-rc7-syzkaller-g5f5673607153 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call trace: dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:319 show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:326 __dump_sta ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49947", "url": "https://ubuntu.com/security/CVE-2024-49947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: test for not too small csum_start in virtio_net_hdr_to_skb() syzbot was able to trigger this warning [1], after injecting a malicious packet through af_packet, setting skb->csum_start and thus the transport header to an incorrect value. We can at least make sure the transport header is after the end of the network header (with a estimated minimal size). [1] [ 67.873027] skb len=4096 headroom=16 headlen=14 tailroom=0 mac=(-1,-1) mac_len=0 net=(16,-6) trans=10 shinfo(txflags=0 nr_frags=1 gso(size=0 type=0 segs=0)) csum(0xa start=10 offset=0 ip_summed=3 complete_sw=0 valid=0 level=0) hash(0x0 sw=0 l4=0) proto=0x0800 pkttype=0 iif=0 priority=0x0 mark=0x0 alloc_cpu=10 vlan_all=0x0 encapsulation=0 inner(proto=0x0000, mac=0, net=0, trans=0) [ 67.877172] dev name=veth0_vlan feat=0x000061164fdd09e9 [ 67.877764] sk family=17 type=3 proto=0 [ 67.878279] skb linear: 00000000: 00 00 10 00 00 00 00 00 0f 00 00 00 08 00 [ 67.879128] skb frag: 00000000: 0e 00 07 00 00 00 28 00 08 80 1c 00 04 00 00 02 [ 67.879877] skb frag: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.880647] skb frag: 00000020: 00 00 02 00 00 00 08 00 1b 00 00 00 00 00 00 00 [ 67.881156] skb frag: 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.881753] skb frag: 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.882173] skb frag: 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.882790] skb frag: 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.883171] skb frag: 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.883733] skb frag: 00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.884206] skb frag: 00000090: 00 00 00 00 00 00 00 00 00 00 69 70 76 6c 61 6e [ 67.884704] skb frag: 000000a0: 31 00 00 00 00 00 00 00 00 00 2b 00 00 00 00 00 [ 67.885139] skb frag: 000000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.885677] skb frag: 000000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.886042] skb frag: 000000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.886408] skb frag: 000000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.887020] skb frag: 000000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.887384] skb frag: 00000100: 00 00 [ 67.887878] ------------[ cut here ]------------ [ 67.887908] offset (-6) >= skb_headlen() (14) [ 67.888445] WARNING: CPU: 10 PID: 2088 at net/core/dev.c:3332 skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.889353] Modules linked in: macsec macvtap macvlan hsr wireguard curve25519_x86_64 libcurve25519_generic libchacha20poly1305 chacha_x86_64 libchacha poly1305_x86_64 dummy bridge sr_mod cdrom evdev pcspkr i2c_piix4 9pnet_virtio 9p 9pnet netfs [ 67.890111] CPU: 10 UID: 0 PID: 2088 Comm: b363492833 Not tainted 6.11.0-virtme #1011 [ 67.890183] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 67.890309] RIP: 0010:skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891043] Call Trace: [ 67.891173] [ 67.891274] ? __warn (kernel/panic.c:741) [ 67.891320] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891333] ? report_bug (lib/bug.c:180 lib/bug.c:219) [ 67.891348] ? handle_bug (arch/x86/kernel/traps.c:239) [ 67.891363] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) [ 67.891372] ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621) [ 67.891388] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891399] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891416] ip_do_fragment (net/ipv4/ip_output.c:777 (discriminator 1)) [ 67.891448] ? __ip_local_out (./include/linux/skbuff.h:1146 ./include/net/l3mdev.h:196 ./include/net/l3mdev.h:213 ne ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49948", "url": "https://ubuntu.com/security/CVE-2024-49948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: add more sanity checks to qdisc_pkt_len_init() One path takes care of SKB_GSO_DODGY, assuming skb->len is bigger than hdr_len. virtio_net_hdr_to_skb() does not fully dissect TCP headers, it only make sure it is at least 20 bytes. It is possible for an user to provide a malicious 'GSO' packet, total length of 80 bytes. - 20 bytes of IPv4 header - 60 bytes TCP header - a small gso_size like 8 virtio_net_hdr_to_skb() would declare this packet as a normal GSO packet, because it would see 40 bytes of payload, bigger than gso_size. We need to make detect this case to not underflow qdisc_skb_cb(skb)->pkt_len.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49949", "url": "https://ubuntu.com/security/CVE-2024-49949", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: avoid potential underflow in qdisc_pkt_len_init() with UFO After commit 7c6d2ecbda83 (\"net: be more gentle about silly gso requests coming from user\") virtio_net_hdr_to_skb() had sanity check to detect malicious attempts from user space to cook a bad GSO packet. Then commit cf9acc90c80ec (\"net: virtio_net_hdr_to_skb: count transport header in UFO\") while fixing one issue, allowed user space to cook a GSO packet with the following characteristic : IPv4 SKB_GSO_UDP, gso_size=3, skb->len = 28. When this packet arrives in qdisc_pkt_len_init(), we end up with hdr_len = 28 (IPv4 header + UDP header), matching skb->len Then the following sets gso_segs to 0 : gso_segs = DIV_ROUND_UP(skb->len - hdr_len, shinfo->gso_size); Then later we set qdisc_skb_cb(skb)->pkt_len to back to zero :/ qdisc_skb_cb(skb)->pkt_len += (gso_segs - 1) * hdr_len; This leads to the following crash in fq_codel [1] qdisc_pkt_len_init() is best effort, we only want an estimation of the bytes sent on the wire, not crashing the kernel. This patch is fixing this particular issue, a following one adds more sanity checks for another potential bug. [1] [ 70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 70.724561] #PF: supervisor read access in kernel mode [ 70.724561] #PF: error_code(0x0000) - not-present page [ 70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0 [ 70.724561] Oops: Oops: 0000 [#1] SMP NOPTI [ 70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991 [ 70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel [ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 <49> 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49 All code ======== 0:\t24 08 \tand $0x8,%al 2:\t49 c1 e1 06 \tshl $0x6,%r9 6:\t44 89 7c 24 18 \tmov %r15d,0x18(%rsp) b:\t45 31 ed \txor %r13d,%r13d e:\t45 31 c0 \txor %r8d,%r8d 11:\t31 ff \txor %edi,%edi 13:\t89 44 24 14 \tmov %eax,0x14(%rsp) 17:\t4c 03 8b 90 01 00 00 \tadd 0x190(%rbx),%r9 1e:\teb 04 \tjmp 0x24 20:\t39 ca \tcmp %ecx,%edx 22:\t73 37 \tjae 0x5b 24:\t4d 8b 39 \tmov (%r9),%r15 27:\t83 c7 01 \tadd $0x1,%edi 2a:*\t49 8b 17 \tmov (%r15),%rdx\t\t<-- trapping instruction 2d:\t49 89 11 \tmov %rdx,(%r9) 30:\t41 8b 57 28 \tmov 0x28(%r15),%edx 34:\t45 8b 5f 34 \tmov 0x34(%r15),%r11d 38:\t49 c7 07 00 00 00 00 \tmovq $0x0,(%r15) 3f:\t49 \trex.WB Code starting with the faulting instruction =========================================== 0:\t49 8b 17 \tmov (%r15),%rdx 3:\t49 89 11 \tmov %rdx,(%r9) 6:\t41 8b 57 28 \tmov 0x28(%r15),%edx a:\t45 8b 5f 34 \tmov 0x34(%r15),%r11d e:\t49 c7 07 00 00 00 00 \tmovq $0x0,(%r15) 15:\t49 \trex.WB [ 70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202 [ 70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000 [ 70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001 [ 70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000 [ 70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58 [ 70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000 [ 70.724561] FS: 000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000 [ 70.724561] CS: 0010 DS: 0000 ES: 0000 C ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49997", "url": "https://ubuntu.com/security/CVE-2024-49997", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: lantiq_etop: fix memory disclosure When applying padding, the buffer is not zeroed, which results in memory disclosure. The mentioned data is observed on the wire. This patch uses skb_put_padto() to pad Ethernet frames properly. The mentioned function zeroes the expanded buffer. In case the packet cannot be padded it is silently dropped. Statistics are also not incremented. This driver does not support statistics in the old 32-bit format or the new 64-bit format. These will be added in the future. In its current form, the patch should be easily backported to stable versions. Ethernet MACs on Amazon-SE and Danube cannot do padding of the packets in hardware, so software padding must be applied.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49998", "url": "https://ubuntu.com/security/CVE-2024-49998", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: improve shutdown sequence Alexander Sverdlin presents 2 problems during shutdown with the lan9303 driver. One is specific to lan9303 and the other just happens to reproduce there. The first problem is that lan9303 is unique among DSA drivers in that it calls dev_get_drvdata() at \"arbitrary runtime\" (not probe, not shutdown, not remove): phy_state_machine() -> ... -> dsa_user_phy_read() -> ds->ops->phy_read() -> lan9303_phy_read() -> chip->ops->phy_read() -> lan9303_mdio_phy_read() -> dev_get_drvdata() But we never stop the phy_state_machine(), so it may continue to run after dsa_switch_shutdown(). Our common pattern in all DSA drivers is to set drvdata to NULL to suppress the remove() method that may come afterwards. But in this case it will result in an NPD. The second problem is that the way in which we set dp->conduit->dsa_ptr = NULL; is concurrent with receive packet processing. dsa_switch_rcv() checks once whether dev->dsa_ptr is NULL, but afterwards, rather than continuing to use that non-NULL value, dev->dsa_ptr is dereferenced again and again without NULL checks: dsa_conduit_find_user() and many other places. In between dereferences, there is no locking to ensure that what was valid once continues to be valid. Both problems have the common aspect that closing the conduit interface solves them. In the first case, dev_close(conduit) triggers the NETDEV_GOING_DOWN event in dsa_user_netdevice_event() which closes user ports as well. dsa_port_disable_rt() calls phylink_stop(), which synchronously stops the phylink state machine, and ds->ops->phy_read() will thus no longer call into the driver after this point. In the second case, dev_close(conduit) should do this, as per Documentation/networking/driver.rst: | Quiescence | ---------- | | After the ndo_stop routine has been called, the hardware must | not receive or transmit any data. All in flight packets must | be aborted. If necessary, poll or wait for completion of | any reset commands. So it should be sufficient to ensure that later, when we zeroize conduit->dsa_ptr, there will be no concurrent dsa_switch_rcv() call on this conduit. The addition of the netif_device_detach() function is to ensure that ioctls, rtnetlinks and ethtool requests on the user ports no longer propagate down to the driver - we're no longer prepared to handle them. The race condition actually did not exist when commit 0650bf52b31f (\"net: dsa: be compatible with masters which unregister on shutdown\") first introduced dsa_switch_shutdown(). It was created later, when we stopped unregistering the user interfaces from a bad spot, and we just replaced that sequence with a racy zeroization of conduit->dsa_ptr (one which doesn't ensure that the interfaces aren't up).", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49999", "url": "https://ubuntu.com/security/CVE-2024-49999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix the setting of the server responding flag In afs_wait_for_operation(), we set transcribe the call responded flag to the server record that we used after doing the fileserver iteration loop - but it's possible to exit the loop having had a response from the server that we've discarded (e.g. it returned an abort or we started receiving data, but the call didn't complete). This means that op->server might be NULL, but we don't check that before attempting to set the server flag.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49950", "url": "https://ubuntu.com/security/CVE-2024-49950", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix uaf in l2cap_connect [Syzbot reported] BUG: KASAN: slab-use-after-free in l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 Read of size 8 at addr ffff8880241e9800 by task kworker/u9:0/54 CPU: 0 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-00268-g788220eee30d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Workqueue: hci2 hci_rx_work Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 l2cap_connect_req net/bluetooth/l2cap_core.c:4080 [inline] l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:4772 [inline] l2cap_sig_channel net/bluetooth/l2cap_core.c:5543 [inline] l2cap_recv_frame+0xf0b/0x8eb0 net/bluetooth/l2cap_core.c:6825 l2cap_recv_acldata+0x9b4/0xb70 net/bluetooth/l2cap_core.c:7514 hci_acldata_packet net/bluetooth/hci_core.c:3791 [inline] hci_rx_work+0xaab/0x1610 net/bluetooth/hci_core.c:4028 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 ... Freed by task 5245: 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:579 poison_slab_object+0xf7/0x160 mm/kasan/common.c:240 __kasan_slab_free+0x32/0x50 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2256 [inline] slab_free mm/slub.c:4477 [inline] kfree+0x12a/0x3b0 mm/slub.c:4598 l2cap_conn_free net/bluetooth/l2cap_core.c:1810 [inline] kref_put include/linux/kref.h:65 [inline] l2cap_conn_put net/bluetooth/l2cap_core.c:1822 [inline] l2cap_conn_del+0x59d/0x730 net/bluetooth/l2cap_core.c:1802 l2cap_connect_cfm+0x9e6/0xf80 net/bluetooth/l2cap_core.c:7241 hci_connect_cfm include/net/bluetooth/hci_core.h:1960 [inline] hci_conn_failed+0x1c3/0x370 net/bluetooth/hci_conn.c:1265 hci_abort_conn_sync+0x75a/0xb50 net/bluetooth/hci_sync.c:5583 abort_conn_sync+0x197/0x360 net/bluetooth/hci_conn.c:2917 hci_cmd_sync_work+0x1a4/0x410 net/bluetooth/hci_sync.c:328 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49951", "url": "https://ubuntu.com/security/CVE-2024-49951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Fix possible crash on mgmt_index_removed If mgmt_index_removed is called while there are commands queued on cmd_sync it could lead to crashes like the bellow trace: 0x0000053D: __list_del_entry_valid_or_report+0x98/0xdc 0x0000053D: mgmt_pending_remove+0x18/0x58 [bluetooth] 0x0000053E: mgmt_remove_adv_monitor_complete+0x80/0x108 [bluetooth] 0x0000053E: hci_cmd_sync_work+0xbc/0x164 [bluetooth] So while handling mgmt_index_removed this attempts to dequeue commands passed as user_data to cmd_sync.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49952", "url": "https://ubuntu.com/security/CVE-2024-49952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: prevent nf_skb_duplicated corruption syzbot found that nf_dup_ipv4() or nf_dup_ipv6() could write per-cpu variable nf_skb_duplicated in an unsafe way [1]. Disabling preemption as hinted by the splat is not enough, we have to disable soft interrupts as well. [1] BUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316 caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49 nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook+0x2c4/0x450 include/linux/netfilter.h:269 NF_HOOK_COND include/linux/netfilter.h:302 [inline] ip_output+0x185/0x230 net/ipv4/ip_output.c:433 ip_local_out net/ipv4/ip_output.c:129 [inline] ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495 udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981 udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737 __do_sys_sendmmsg net/socket.c:2766 [inline] __se_sys_sendmmsg net/socket.c:2763 [inline] __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763 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:0x7f4ce4f7def9 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:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9 RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006 RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49953", "url": "https://ubuntu.com/security/CVE-2024-49953", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix crash caused by calling __xfrm_state_delete() twice The km.state is not checked in driver's delayed work. When xfrm_state_check_expire() is called, the state can be reset to XFRM_STATE_EXPIRED, even if it is XFRM_STATE_DEAD already. This happens when xfrm state is deleted, but not freed yet. As __xfrm_state_delete() is called again in xfrm timer, the following crash occurs. To fix this issue, skip xfrm_state_check_expire() if km.state is not XFRM_STATE_VALID. Oops: general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] SMP CPU: 5 UID: 0 PID: 7448 Comm: kworker/u102:2 Not tainted 6.11.0-rc2+ #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5e_ipsec: eth%d mlx5e_ipsec_handle_sw_limits [mlx5_core] RIP: 0010:__xfrm_state_delete+0x3d/0x1b0 Code: 0f 84 8b 01 00 00 48 89 fd c6 87 c8 00 00 00 05 48 8d bb 40 10 00 00 e8 11 04 1a 00 48 8b 95 b8 00 00 00 48 8b 85 c0 00 00 00 <48> 89 42 08 48 89 10 48 8b 55 10 48 b8 00 01 00 00 00 00 ad de 48 RSP: 0018:ffff88885f945ec8 EFLAGS: 00010246 RAX: dead000000000122 RBX: ffffffff82afa940 RCX: 0000000000000036 RDX: dead000000000100 RSI: 0000000000000000 RDI: ffffffff82afb980 RBP: ffff888109a20340 R08: ffff88885f945ea0 R09: 0000000000000000 R10: 0000000000000000 R11: ffff88885f945ff8 R12: 0000000000000246 R13: ffff888109a20340 R14: ffff88885f95f420 R15: ffff88885f95f400 FS: 0000000000000000(0000) GS:ffff88885f940000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2163102430 CR3: 00000001128d6001 CR4: 0000000000370eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? die_addr+0x33/0x90 ? exc_general_protection+0x1a2/0x390 ? asm_exc_general_protection+0x22/0x30 ? __xfrm_state_delete+0x3d/0x1b0 ? __xfrm_state_delete+0x2f/0x1b0 xfrm_timer_handler+0x174/0x350 ? __xfrm_state_delete+0x1b0/0x1b0 __hrtimer_run_queues+0x121/0x270 hrtimer_run_softirq+0x88/0xd0 handle_softirqs+0xcc/0x270 do_softirq+0x3c/0x50 __local_bh_enable_ip+0x47/0x50 mlx5e_ipsec_handle_sw_limits+0x7d/0x90 [mlx5_core] process_one_work+0x137/0x2d0 worker_thread+0x28d/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50000", "url": "https://ubuntu.com/security/CVE-2024-50000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix NULL deref in mlx5e_tir_builder_alloc() In mlx5e_tir_builder_alloc() kvzalloc() may return NULL which is dereferenced on the next line in a reference to the modify field. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50001", "url": "https://ubuntu.com/security/CVE-2024-50001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix error path in multi-packet WQE transmit Remove the erroneous unmap in case no DMA mapping was established The multi-packet WQE transmit code attempts to obtain a DMA mapping for the skb. This could fail, e.g. under memory pressure, when the IOMMU driver just can't allocate more memory for page tables. While the code tries to handle this in the path below the err_unmap label it erroneously unmaps one entry from the sq's FIFO list of active mappings. Since the current map attempt failed this unmap is removing some random DMA mapping that might still be required. If the PCI function now presents that IOVA, the IOMMU may assumes a rogue DMA access and e.g. on s390 puts the PCI function in error state. The erroneous behavior was seen in a stress-test environment that created memory pressure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50179", "url": "https://ubuntu.com/security/CVE-2024-50179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: remove the incorrect Fw reference check when dirtying pages When doing the direct-io reads it will also try to mark pages dirty, but for the read path it won't hold the Fw caps and there is case will it get the Fw reference.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49963", "url": "https://ubuntu.com/security/CVE-2024-49963", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mailbox: bcm2835: Fix timeout during suspend mode During noirq suspend phase the Raspberry Pi power driver suffer of firmware property timeouts. The reason is that the IRQ of the underlying BCM2835 mailbox is disabled and rpi_firmware_property_list() will always run into a timeout [1]. Since the VideoCore side isn't consider as a wakeup source, set the IRQF_NO_SUSPEND flag for the mailbox IRQ in order to keep it enabled during suspend-resume cycle. [1] PM: late suspend of devices complete after 1.754 msecs WARNING: CPU: 0 PID: 438 at drivers/firmware/raspberrypi.c:128 rpi_firmware_property_list+0x204/0x22c Firmware transaction 0x00028001 timeout Modules linked in: CPU: 0 PID: 438 Comm: bash Tainted: G C 6.9.3-dirty #17 Hardware name: BCM2835 Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x44 dump_stack_lvl from __warn+0x88/0xec __warn from warn_slowpath_fmt+0x7c/0xb0 warn_slowpath_fmt from rpi_firmware_property_list+0x204/0x22c rpi_firmware_property_list from rpi_firmware_property+0x68/0x8c rpi_firmware_property from rpi_firmware_set_power+0x54/0xc0 rpi_firmware_set_power from _genpd_power_off+0xe4/0x148 _genpd_power_off from genpd_sync_power_off+0x7c/0x11c genpd_sync_power_off from genpd_finish_suspend+0xcc/0xe0 genpd_finish_suspend from dpm_run_callback+0x78/0xd0 dpm_run_callback from device_suspend_noirq+0xc0/0x238 device_suspend_noirq from dpm_suspend_noirq+0xb0/0x168 dpm_suspend_noirq from suspend_devices_and_enter+0x1b8/0x5ac suspend_devices_and_enter from pm_suspend+0x254/0x2e4 pm_suspend from state_store+0xa8/0xd4 state_store from kernfs_fop_write_iter+0x154/0x1a0 kernfs_fop_write_iter from vfs_write+0x12c/0x184 vfs_write from ksys_write+0x78/0xc0 ksys_write from ret_fast_syscall+0x0/0x54 Exception stack(0xcc93dfa8 to 0xcc93dff0) [...] PM: noirq suspend of devices complete after 3095.584 msecs", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49954", "url": "https://ubuntu.com/security/CVE-2024-49954", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: static_call: Replace pointless WARN_ON() in static_call_module_notify() static_call_module_notify() triggers a WARN_ON(), when memory allocation fails in __static_call_add_module(). That's not really justified, because the failure case must be correctly handled by the well known call chain and the error code is passed through to the initiating userspace application. A memory allocation fail is not a fatal problem, but the WARN_ON() takes the machine out when panic_on_warn is set. Replace it with a pr_warn().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50002", "url": "https://ubuntu.com/security/CVE-2024-50002", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: static_call: Handle module init failure correctly in static_call_del_module() Module insertion invokes static_call_add_module() to initialize the static calls in a module. static_call_add_module() invokes __static_call_init(), which allocates a struct static_call_mod to either encapsulate the built-in static call sites of the associated key into it so further modules can be added or to append the module to the module chain. If that allocation fails the function returns with an error code and the module core invokes static_call_del_module() to clean up eventually added static_call_mod entries. This works correctly, when all keys used by the module were converted over to a module chain before the failure. If not then static_call_del_module() causes a #GP as it blindly assumes that key::mods points to a valid struct static_call_mod. The problem is that key::mods is not a individual struct member of struct static_call_key, it's part of a union to save space: union { /* bit 0: 0 = mods, 1 = sites */ unsigned long type; struct static_call_mod *mods; struct static_call_site *sites; \t}; key::sites is a pointer to the list of built-in usage sites of the static call. The type of the pointer is differentiated by bit 0. A mods pointer has the bit clear, the sites pointer has the bit set. As static_call_del_module() blidly assumes that the pointer is a valid static_call_mod type, it fails to check for this failure case and dereferences the pointer to the list of built-in call sites, which is obviously bogus. Cure it by checking whether the key has a sites or a mods pointer. If it's a sites pointer then the key is not to be touched. As the sites are walked in the same order as in __static_call_init() the site walk can be terminated because all subsequent sites have not been touched by the init code due to the error exit. If it was converted before the allocation fail, then the inner loop which searches for a module match will find nothing. A fail in the second allocation in __static_call_init() is harmless and does not require special treatment. The first allocation succeeded and converted the key to a module chain. That first entry has mod::mod == NULL and mod::next == NULL, so the inner loop of static_call_del_module() will neither find a module match nor a module chain. The next site in the walk was either already converted, but can't match the module, or it will exit the outer loop because it has a static_call_site pointer and not a static_call_mod pointer.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-47675", "url": "https://ubuntu.com/security/CVE-2024-47675", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix use-after-free in bpf_uprobe_multi_link_attach() If bpf_link_prime() fails, bpf_uprobe_multi_link_attach() goes to the error_free label and frees the array of bpf_uprobe's without calling bpf_uprobe_unregister(). This leaks bpf_uprobe->uprobe and worse, this frees bpf_uprobe->consumer without removing it from the uprobe->consumers list.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47676", "url": "https://ubuntu.com/security/CVE-2024-47676", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb.c: fix UAF of vma in hugetlb fault pathway Syzbot reports a UAF in hugetlb_fault(). This happens because vmf_anon_prepare() could drop the per-VMA lock and allow the current VMA to be freed before hugetlb_vma_unlock_read() is called. We can fix this by using a modified version of vmf_anon_prepare() that doesn't release the VMA lock on failure, and then release it ourselves after hugetlb_vma_unlock_read().", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47677", "url": "https://ubuntu.com/security/CVE-2024-47677", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: resolve memory leak from exfat_create_upcase_table() If exfat_load_upcase_table reaches end and returns -EINVAL, allocated memory doesn't get freed and while exfat_load_default_upcase_table allocates more memory, leading to a memory leak. Here's link to syzkaller crash report illustrating this issue: https://syzkaller.appspot.com/text?tag=CrashReport&x=1406c201980000", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47725", "url": "https://ubuntu.com/security/CVE-2024-47725", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47739", "url": "https://ubuntu.com/security/CVE-2024-47739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: padata: use integer wrap around to prevent deadlock on seq_nr overflow When submitting more than 2^32 padata objects to padata_do_serial, the current sorting implementation incorrectly sorts padata objects with overflowed seq_nr, causing them to be placed before existing objects in the reorder list. This leads to a deadlock in the serialization process as padata_find_next cannot match padata->seq_nr and pd->processed because the padata instance with overflowed seq_nr will be selected next. To fix this, we use an unsigned integer wrap around to correctly sort padata objects in scenarios with integer overflow.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47678", "url": "https://ubuntu.com/security/CVE-2024-47678", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: icmp: change the order of rate limits ICMP messages are ratelimited : After the blamed commits, the two rate limiters are applied in this order: 1) host wide ratelimit (icmp_global_allow()) 2) Per destination ratelimit (inetpeer based) In order to avoid side-channels attacks, we need to apply the per destination check first. This patch makes the following change : 1) icmp_global_allow() checks if the host wide limit is reached. But credits are not yet consumed. This is deferred to 3) 2) The per destination limit is checked/updated. This might add a new node in inetpeer tree. 3) icmp_global_consume() consumes tokens if prior operations succeeded. This means that host wide ratelimit is still effective in keeping inetpeer tree small even under DDOS. As a bonus, I removed icmp_global.lock as the fast path can use a lock-free operation.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47733", "url": "https://ubuntu.com/security/CVE-2024-47733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfs: Delete subtree of 'fs/netfs' when netfs module exits In netfs_init() or fscache_proc_init(), we create dentry under 'fs/netfs', but in netfs_exit(), we only delete the proc entry of 'fs/netfs' without deleting its subtree. This triggers the following WARNING: ================================================================== remove_proc_entry: removing non-empty directory 'fs/netfs', leaking at least 'requests' WARNING: CPU: 4 PID: 566 at fs/proc/generic.c:717 remove_proc_entry+0x160/0x1c0 Modules linked in: netfs(-) CPU: 4 UID: 0 PID: 566 Comm: rmmod Not tainted 6.11.0-rc3 #860 RIP: 0010:remove_proc_entry+0x160/0x1c0 Call Trace: netfs_exit+0x12/0x620 [netfs] __do_sys_delete_module.isra.0+0x14c/0x2e0 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e ================================================================== Therefore use remove_proc_subtree() instead of remove_proc_entry() to fix the above problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47679", "url": "https://ubuntu.com/security/CVE-2024-47679", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfs: fix race between evice_inodes() and find_inode()&iput() Hi, all Recently I noticed a bug[1] in btrfs, after digged it into and I believe it'a race in vfs. Let's assume there's a inode (ie ino 261) with i_count 1 is called by iput(), and there's a concurrent thread calling generic_shutdown_super(). cpu0: cpu1: iput() // i_count is 1 ->spin_lock(inode) ->dec i_count to 0 ->iput_final() generic_shutdown_super() ->__inode_add_lru() ->evict_inodes() // cause some reason[2] ->if (atomic_read(inode->i_count)) continue; // return before // inode 261 passed the above check // list_lru_add_obj() // and then schedule out ->spin_unlock() // note here: the inode 261 // was still at sb list and hash list, // and I_FREEING|I_WILL_FREE was not been set btrfs_iget() // after some function calls ->find_inode() // found the above inode 261 ->spin_lock(inode) // check I_FREEING|I_WILL_FREE // and passed ->__iget() ->spin_unlock(inode) // schedule back ->spin_lock(inode) // check (I_NEW|I_FREEING|I_WILL_FREE) flags, // passed and set I_FREEING iput() ->spin_unlock(inode) ->spin_lock(inode)\t\t\t ->evict() // dec i_count to 0 ->iput_final() ->spin_unlock() ->evict() Now, we have two threads simultaneously evicting the same inode, which may trigger the BUG(inode->i_state & I_CLEAR) statement both within clear_inode() and iput(). To fix the bug, recheck the inode->i_count after holding i_lock. Because in the most scenarios, the first check is valid, and the overhead of spin_lock() can be reduced. If there is any misunderstanding, please let me know, thanks. [1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/ [2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable() return false when I reproduced the bug.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49859", "url": "https://ubuntu.com/security/CVE-2024-49859", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to check atomic_file in f2fs ioctl interfaces Some f2fs ioctl interfaces like f2fs_ioc_set_pin_file(), f2fs_move_file_range(), and f2fs_defragment_range() missed to check atomic_write status, which may cause potential race issue, fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47680", "url": "https://ubuntu.com/security/CVE-2024-47680", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: check discard support for conventional zones As the helper function f2fs_bdev_support_discard() shows, f2fs checks if the target block devices support discard by calling bdev_max_discard_sectors() and bdev_is_zoned(). This check works well for most cases, but it does not work for conventional zones on zoned block devices. F2fs assumes that zoned block devices support discard, and calls __submit_discard_cmd(). When __submit_discard_cmd() is called for sequential write required zones, it works fine since __submit_discard_cmd() issues zone reset commands instead of discard commands. However, when __submit_discard_cmd() is called for conventional zones, __blkdev_issue_discard() is called even when the devices do not support discard. The inappropriate __blkdev_issue_discard() call was not a problem before the commit 30f1e7241422 (\"block: move discard checks into the ioctl handler\") because __blkdev_issue_discard() checked if the target devices support discard or not. If not, it returned EOPNOTSUPP. After the commit, __blkdev_issue_discard() no longer checks it. It always returns zero and sets NULL to the given bio pointer. This NULL pointer triggers f2fs_bug_on() in __submit_discard_cmd(). The BUG is recreated with the commands below at the umount step, where /dev/nullb0 is a zoned null_blk with 5GB total size, 128MB zone size and 10 conventional zones. $ mkfs.f2fs -f -m /dev/nullb0 $ mount /dev/nullb0 /mnt $ for ((i=0;i<5;i++)); do dd if=/dev/zero of=/mnt/test bs=65536 count=1600 conv=fsync; done $ umount /mnt To fix the BUG, avoid the inappropriate __blkdev_issue_discard() call. When discard is requested for conventional zones, check if the device supports discard or not. If not, return EOPNOTSUPP.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47740", "url": "https://ubuntu.com/security/CVE-2024-47740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: Require FMODE_WRITE for atomic write ioctls The F2FS ioctls for starting and committing atomic writes check for inode_owner_or_capable(), but this does not give LSMs like SELinux or Landlock an opportunity to deny the write access - if the caller's FSUID matches the inode's UID, inode_owner_or_capable() immediately returns true. There are scenarios where LSMs want to deny a process the ability to write particular files, even files that the FSUID of the process owns; but this can currently partially be bypassed using atomic write ioctls in two ways: - F2FS_IOC_START_ATOMIC_REPLACE + F2FS_IOC_COMMIT_ATOMIC_WRITE can truncate an inode to size 0 - F2FS_IOC_START_ATOMIC_WRITE + F2FS_IOC_ABORT_ATOMIC_WRITE can revert changes another process concurrently made to a file Fix it by requiring FMODE_WRITE for these operations, just like for F2FS_IOC_MOVE_RANGE. Since any legitimate caller should only be using these ioctls when intending to write into the file, that seems unlikely to break anything.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47726", "url": "https://ubuntu.com/security/CVE-2024-47726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to wait dio completion It should wait all existing dio write IOs before block removal, otherwise, previous direct write IO may overwrite data in the block which may be reused by other inode.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47741", "url": "https://ubuntu.com/security/CVE-2024-47741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race setting file private on concurrent lseek using same fd When doing concurrent lseek(2) system calls against the same file descriptor, using multiple threads belonging to the same process, we have a short time window where a race happens and can result in a memory leak. The race happens like this: 1) A program opens a file descriptor for a file and then spawns two threads (with the pthreads library for example), lets call them task A and task B; 2) Task A calls lseek with SEEK_DATA or SEEK_HOLE and ends up at file.c:find_desired_extent() while holding a read lock on the inode; 3) At the start of find_desired_extent(), it extracts the file's private_data pointer into a local variable named 'private', which has a value of NULL; 4) Task B also calls lseek with SEEK_DATA or SEEK_HOLE, locks the inode in shared mode and enters file.c:find_desired_extent(), where it also extracts file->private_data into its local variable 'private', which has a NULL value; 5) Because it saw a NULL file private, task A allocates a private structure and assigns to the file structure; 6) Task B also saw a NULL file private so it also allocates its own file private and then assigns it to the same file structure, since both tasks are using the same file descriptor. At this point we leak the private structure allocated by task A. Besides the memory leak, there's also the detail that both tasks end up using the same cached state record in the private structure (struct btrfs_file_private::llseek_cached_state), which can result in a use-after-free problem since one task can free it while the other is still using it (only one task took a reference count on it). Also, sharing the cached state is not a good idea since it could result in incorrect results in the future - right now it should not be a problem because it end ups being used only in extent-io-tree.c:count_range_bits() where we do range validation before using the cached state. Fix this by protecting the private assignment and check of a file while holding the inode's spinlock and keep track of the task that allocated the private, so that it's used only by that task in order to prevent user-after-free issues with the cached state record as well as potentially using it incorrectly in the future.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47681", "url": "https://ubuntu.com/security/CVE-2024-47681", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix NULL pointer dereference in mt7996_mcu_sta_bfer_he Fix the NULL pointer dereference in mt7996_mcu_sta_bfer_he routine adding an sta interface to the mt7996 driver. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49858", "url": "https://ubuntu.com/security/CVE-2024-49858", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption The TPM event log table is a Linux specific construct, where the data produced by the GetEventLog() boot service is cached in memory, and passed on to the OS using an EFI configuration table. The use of EFI_LOADER_DATA here results in the region being left unreserved in the E820 memory map constructed by the EFI stub, and this is the memory description that is passed on to the incoming kernel by kexec, which is therefore unaware that the region should be reserved. Even though the utility of the TPM2 event log after a kexec is questionable, any corruption might send the parsing code off into the weeds and crash the kernel. So let's use EFI_ACPI_RECLAIM_MEMORY instead, which is always treated as reserved by the E820 conversion logic.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49860", "url": "https://ubuntu.com/security/CVE-2024-49860", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: sysfs: validate return type of _STR method Only buffer objects are valid return values of _STR. If something else is returned description_show() will access invalid memory.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47742", "url": "https://ubuntu.com/security/CVE-2024-47742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware_loader: Block path traversal Most firmware names are hardcoded strings, or are constructed from fairly constrained format strings where the dynamic parts are just some hex numbers or such. However, there are a couple codepaths in the kernel where firmware file names contain string components that are passed through from a device or semi-privileged userspace; the ones I could find (not counting interfaces that require root privileges) are: - lpfc_sli4_request_firmware_update() seems to construct the firmware filename from \"ModelName\", a string that was previously parsed out of some descriptor (\"Vital Product Data\") in lpfc_fill_vpd() - nfp_net_fw_find() seems to construct a firmware filename from a model name coming from nfp_hwinfo_lookup(pf->hwinfo, \"nffw.partno\"), which I think parses some descriptor that was read from the device. (But this case likely isn't exploitable because the format string looks like \"netronome/nic_%s\", and there shouldn't be any *folders* starting with \"netronome/nic_\". The previous case was different because there, the \"%s\" is *at the start* of the format string.) - module_flash_fw_schedule() is reachable from the ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is enough to pass the privilege check), and takes a userspace-provided firmware name. (But I think to reach this case, you need to have CAP_NET_ADMIN over a network namespace that a special kind of ethernet device is mapped into, so I think this is not a viable attack path in practice.) Fix it by rejecting any firmware names containing \"..\" path components. For what it's worth, I went looking and haven't found any USB device drivers that use the firmware loader dangerously.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47682", "url": "https://ubuntu.com/security/CVE-2024-47682", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sd: Fix off-by-one error in sd_read_block_characteristics() Ff the device returns page 0xb1 with length 8 (happens with qemu v2.x, for example), sd_read_block_characteristics() may attempt an out-of-bounds memory access when accessing the zoned field at offset 8.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47743", "url": "https://ubuntu.com/security/CVE-2024-47743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: prevent NULL pointer dereference in find_asymmetric_key() In find_asymmetric_key(), if all NULLs are passed in the id_{0,1,2} arguments, the kernel will first emit WARN but then have an oops because id_2 gets dereferenced anyway. Add the missing id_2 check and move WARN_ON() to the final else branch to avoid duplicate NULL checks. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47727", "url": "https://ubuntu.com/security/CVE-2024-47727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/tdx: Fix \"in-kernel MMIO\" check TDX only supports kernel-initiated MMIO operations. The handle_mmio() function checks if the #VE exception occurred in the kernel and rejects the operation if it did not. However, userspace can deceive the kernel into performing MMIO on its behalf. For example, if userspace can point a syscall to an MMIO address, syscall does get_user() or put_user() on it, triggering MMIO #VE. The kernel will treat the #VE as in-kernel MMIO. Ensure that the target MMIO address is within the kernel before decoding instruction.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47744", "url": "https://ubuntu.com/security/CVE-2024-47744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Use dedicated mutex to protect kvm_usage_count to avoid deadlock Use a dedicated mutex to guard kvm_usage_count to fix a potential deadlock on x86 due to a chain of locks and SRCU synchronizations. Translating the below lockdep splat, CPU1 #6 will wait on CPU0 #1, CPU0 #8 will wait on CPU2 #3, and CPU2 #7 will wait on CPU1 #4 (if there's a writer, due to the fairness of r/w semaphores). CPU0 CPU1 CPU2 1 lock(&kvm->slots_lock); 2 lock(&vcpu->mutex); 3 lock(&kvm->srcu); 4 lock(cpu_hotplug_lock); 5 lock(kvm_lock); 6 lock(&kvm->slots_lock); 7 lock(cpu_hotplug_lock); 8 sync(&kvm->srcu); Note, there are likely more potential deadlocks in KVM x86, e.g. the same pattern of taking cpu_hotplug_lock outside of kvm_lock likely exists with __kvmclock_cpufreq_notifier(): cpuhp_cpufreq_online() | -> cpufreq_online() | -> cpufreq_gov_performance_limits() | -> __cpufreq_driver_target() | -> __target_index() | -> cpufreq_freq_transition_begin() | -> cpufreq_notify_transition() | -> ... __kvmclock_cpufreq_notifier() But, actually triggering such deadlocks is beyond rare due to the combination of dependencies and timings involved. E.g. the cpufreq notifier is only used on older CPUs without a constant TSC, mucking with the NX hugepage mitigation while VMs are running is very uncommon, and doing so while also onlining/offlining a CPU (necessary to generate contention on cpu_hotplug_lock) would be even more unusual. The most robust solution to the general cpu_hotplug_lock issue is likely to switch vm_list to be an RCU-protected list, e.g. so that x86's cpufreq notifier doesn't to take kvm_lock. For now, settle for fixing the most blatant deadlock, as switching to an RCU-protected list is a much more involved change, but add a comment in locking.rst to call out that care needs to be taken when walking holding kvm_lock and walking vm_list. ====================================================== WARNING: possible circular locking dependency detected 6.10.0-smp--c257535a0c9d-pip #330 Tainted: G S O ------------------------------------------------------ tee/35048 is trying to acquire lock: ff6a80eced71e0a8 (&kvm->slots_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x179/0x1e0 [kvm] but task is already holding lock: ffffffffc07abb08 (kvm_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x14a/0x1e0 [kvm] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (kvm_lock){+.+.}-{3:3}: __mutex_lock+0x6a/0xb40 mutex_lock_nested+0x1f/0x30 kvm_dev_ioctl+0x4fb/0xe50 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #2 (cpu_hotplug_lock){++++}-{0:0}: cpus_read_lock+0x2e/0xb0 static_key_slow_inc+0x16/0x30 kvm_lapic_set_base+0x6a/0x1c0 [kvm] kvm_set_apic_base+0x8f/0xe0 [kvm] kvm_set_msr_common+0x9ae/0xf80 [kvm] vmx_set_msr+0xa54/0xbe0 [kvm_intel] __kvm_set_msr+0xb6/0x1a0 [kvm] kvm_arch_vcpu_ioctl+0xeca/0x10c0 [kvm] kvm_vcpu_ioctl+0x485/0x5b0 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (&kvm->srcu){.+.+}-{0:0}: __synchronize_srcu+0x44/0x1a0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47719", "url": "https://ubuntu.com/security/CVE-2024-47719", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommufd: Protect against overflow of ALIGN() during iova allocation Userspace can supply an iova and uptr such that the target iova alignment becomes really big and ALIGN() overflows which corrupts the selected area range during allocation. CONFIG_IOMMUFD_TEST can detect this: WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline] WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352 Modules linked in: CPU: 1 PID: 5092 Comm: syz-executor294 Not tainted 6.10.0-rc5-syzkaller-00294-g3ffea9a7a6f7 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024 RIP: 0010:iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline] RIP: 0010:iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352 Code: fc e9 a4 f3 ff ff e8 1a 8b 4c fc 41 be e4 ff ff ff e9 8a f3 ff ff e8 0a 8b 4c fc 90 0f 0b 90 e9 37 f5 ff ff e8 fc 8a 4c fc 90 <0f> 0b 90 e9 68 f3 ff ff 48 c7 c1 ec 82 ad 8f 80 e1 07 80 c1 03 38 RSP: 0018:ffffc90003ebf9e0 EFLAGS: 00010293 RAX: ffffffff85499fa4 RBX: 00000000ffffffef RCX: ffff888079b49e00 RDX: 0000000000000000 RSI: 00000000ffffffef RDI: 0000000000000000 RBP: ffffc90003ebfc50 R08: ffffffff85499b30 R09: ffffffff85499942 R10: 0000000000000002 R11: ffff888079b49e00 R12: ffff8880228e0010 R13: 0000000000000000 R14: 1ffff920007d7f68 R15: ffffc90003ebfd00 FS: 000055557d760380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000005fdeb8 CR3: 000000007404a000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: iommufd_ioas_copy+0x610/0x7b0 drivers/iommu/iommufd/ioas.c:274 iommufd_fops_ioctl+0x4d9/0x5a0 drivers/iommu/iommufd/main.c:421 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Cap the automatic alignment to the huge page size, which is probably a better idea overall. Huge automatic alignments can fragment and chew up the available IOVA space without any reason.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47745", "url": "https://ubuntu.com/security/CVE-2024-47745", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: call the security_mmap_file() LSM hook in remap_file_pages() The remap_file_pages syscall handler calls do_mmap() directly, which doesn't contain the LSM security check. And if the process has called personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for RW pages, this will actually result in remapping the pages to RWX, bypassing a W^X policy enforced by SELinux. So we should check prot by security_mmap_file LSM hook in the remap_file_pages syscall handler before do_mmap() is called. Otherwise, it potentially permits an attacker to bypass a W^X policy enforced by SELinux. The bypass is similar to CVE-2016-10044, which bypass the same thing via AIO and can be found in [1]. The PoC: $ cat > test.c int main(void) { \tsize_t pagesz = sysconf(_SC_PAGE_SIZE); \tint mfd = syscall(SYS_memfd_create, \"test\", 0); \tconst char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE, \t\tMAP_SHARED, mfd, 0); \tunsigned int old = syscall(SYS_personality, 0xffffffff); \tsyscall(SYS_personality, READ_IMPLIES_EXEC | old); \tsyscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0); \tsyscall(SYS_personality, old); \t// show the RWX page exists even if W^X policy is enforced \tint fd = open(\"/proc/self/maps\", O_RDONLY); \tunsigned char buf2[1024]; \twhile (1) { \t\tint ret = read(fd, buf2, 1024); \t\tif (ret <= 0) break; \t\twrite(1, buf2, ret); \t} \tclose(fd); } $ gcc test.c -o test $ ./test | grep rwx 7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted) [PM: subject line tweaks]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47746", "url": "https://ubuntu.com/security/CVE-2024-47746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: use exclusive lock when FUSE_I_CACHE_IO_MODE is set This may be a typo. The comment has said shared locks are not allowed when this bit is set. If using shared lock, the wait in `fuse_file_cached_io_open` may be forever.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47734", "url": "https://ubuntu.com/security/CVE-2024-47734", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: Fix unnecessary warnings and logs from bond_xdp_get_xmit_slave() syzbot reported a WARNING in bond_xdp_get_xmit_slave. To reproduce this[1], one bond device (bond1) has xdpdrv, which increases bpf_master_redirect_enabled_key. Another bond device (bond0) which is unsupported by XDP but its slave (veth3) has xdpgeneric that returns XDP_TX. This triggers WARN_ON_ONCE() from the xdp_master_redirect(). To reduce unnecessary warnings and improve log management, we need to delete the WARN_ON_ONCE() and add ratelimit to the netdev_err(). [1] Steps to reproduce: # Needs tx_xdp with return XDP_TX; ip l add veth0 type veth peer veth1 ip l add veth3 type veth peer veth4 ip l add bond0 type bond mode 6 # BOND_MODE_ALB, unsupported by XDP ip l add bond1 type bond # BOND_MODE_ROUNDROBIN by default ip l set veth0 master bond1 ip l set bond1 up # Increases bpf_master_redirect_enabled_key ip l set dev bond1 xdpdrv object tx_xdp.o section xdp_tx ip l set veth3 master bond0 ip l set bond0 up ip l set veth4 up # Triggers WARN_ON_ONCE() from the xdp_master_redirect() ip l set veth3 xdpgeneric object tx_xdp.o section xdp_tx", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47684", "url": "https://ubuntu.com/security/CVE-2024-47684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: check skb is non-NULL in tcp_rto_delta_us() We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic kernel that are running ceph and recently hit a null ptr dereference in tcp_rearm_rto(). Initially hitting it from the TLP path, but then later we also saw it getting hit from the RACK case as well. Here are examples of the oops messages we saw in each of those cases: Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020 Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode Jul 26 15:05:02 rx [11061395.792971] #PF: error_code(0x0000) - not-present page Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0 Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI Jul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu Jul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023 Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 <48> 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3 Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246 Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000 Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60 Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8 Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900 Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30 Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000 Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0 Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554 Jul 26 15:05:02 rx [11061395.916786] Call Trace: Jul 26 15:05:02 rx [11061395.919488] Jul 26 15:05:02 rx [11061395.921765] ? show_regs.cold+0x1a/0x1f Jul 26 15:05:02 rx [11061395.925859] ? __die+0x90/0xd9 Jul 26 15:05:02 rx [11061395.929169] ? no_context+0x196/0x380 Jul 26 15:05:02 rx [11061395.933088] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0 Jul 26 15:05:02 rx [11061395.938216] ? ip6_sublist_rcv_finish+0x3d/0x50 Jul 26 15:05:02 rx [11061395.943000] ? __bad_area_nosemaphore+0x50/0x1a0 Jul 26 15:05:02 rx [11061395.947873] ? bad_area_nosemaphore+0x16/0x20 Jul 26 15:05:02 rx [11061395.952486] ? do_user_addr_fault+0x267/0x450 Jul 26 15:05:02 rx [11061395.957104] ? ipv6_list_rcv+0x112/0x140 Jul 26 15:05:02 rx [11061395.961279] ? __do_page_fault+0x58/0x90 Jul 26 15:05:02 rx [11061395.965458] ? do_page_fault+0x2c/0xe0 Jul 26 15:05:02 rx [11061395.969465] ? page_fault+0x34/0x40 Jul 26 15:05:02 rx [11061395.973217] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.977313] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.981408] tcp_send_loss_probe+0x10b/0x220 Jul 26 15:05:02 rx [11061395.985937] tcp_write_timer_handler+0x1b4/0x240 Jul 26 15:05:02 rx [11061395.990809] tcp_write_timer+0x9e/0xe0 Jul 26 15:05:02 rx [11061395.994814] ? tcp_write_timer_handler+0x240/0x240 Jul 26 15:05:02 rx [11061395.999866] call_timer_fn+0x32/0x130 Jul 26 15:05:02 rx [11061396.003782] __run_timers.part.0+0x180/0x280 Jul 26 15:05:02 rx [11061396.008309] ? recalibrate_cpu_khz+0x10/0x10 Jul 26 15:05:02 rx [11061396.012841] ? native_x2apic_icr_write+0x30/0x30 Jul 26 15:05:02 rx [11061396.017718] ? lapic_next_even ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47747", "url": "https://ubuntu.com/security/CVE-2024-47747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race Condition In the ether3_probe function, a timer is initialized with a callback function ether3_ledoff, bound to &prev(dev)->timer. Once the timer is started, there is a risk of a race condition if the module or device is removed, triggering the ether3_remove function to perform cleanup. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | ether3_ledoff ether3_remove | free_netdev(dev); | put_devic | kfree(dev); | | ether3_outw(priv(dev)->regs.config2 |= CFG2_CTRLO, REG_CONFIG2); | // use dev Fix it by ensuring that the timer is canceled before proceeding with the cleanup in ether3_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47685", "url": "https://ubuntu.com/security/CVE-2024-47685", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put() syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending garbage on the four reserved tcp bits (th->res1) Use skb_put_zero() to clear the whole TCP header, as done in nf_reject_ip_tcphdr_put() BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5661 [inline] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775 process_backlog+0x4ad/0xa50 net/core/dev.c:6108 __napi_poll+0xe7/0x980 net/core/dev.c:6772 napi_poll net/core/dev.c:6841 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963 handle_softirqs+0x1ce/0x800 kernel/softirq.c:554 __do_softirq+0x14/0x1a kernel/softirq.c:588 do_softirq+0x9a/0x100 kernel/softirq.c:455 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline] __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450 dev_queue_xmit include/linux/netdevice.h:3105 [inline] neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366 inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135 __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143 tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333 __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679 inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750 __sys_connect_file net/socket.c:2061 [inline] __sys_connect+0x606/0x690 net/socket.c:2078 __do_sys_connect net/socket.c:2088 [inline] __se_sys_connect net/socket.c:2085 [inline] __x64_sys_connect+0x91/0xe0 net/socket.c:2085 x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43 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 Uninit was stored to memory at: nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47686", "url": "https://ubuntu.com/security/CVE-2024-47686", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ep93xx: clock: Fix off by one in ep93xx_div_recalc_rate() The psc->div[] array has psc->num_div elements. These values come from when we call clk_hw_register_div(). It's adc_divisors and ARRAY_SIZE(adc_divisors)) and so on. So this condition needs to be >= instead of > to prevent an out of bounds read.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47748", "url": "https://ubuntu.com/security/CVE-2024-47748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost_vdpa: assign irq bypass producer token correctly We used to call irq_bypass_unregister_producer() in vhost_vdpa_setup_vq_irq() which is problematic as we don't know if the token pointer is still valid or not. Actually, we use the eventfd_ctx as the token so the life cycle of the token should be bound to the VHOST_SET_VRING_CALL instead of vhost_vdpa_setup_vq_irq() which could be called by set_status(). Fixing this by setting up irq bypass producer's token when handling VHOST_SET_VRING_CALL and un-registering the producer before calling vhost_vring_ioctl() to prevent a possible use after free as eventfd could have been released in vhost_vring_ioctl(). And such registering and unregistering will only be done if DRIVER_OK is set.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47687", "url": "https://ubuntu.com/security/CVE-2024-47687", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa/mlx5: Fix invalid mr resource destroy Certain error paths from mlx5_vdpa_dev_add() can end up releasing mr resources which never got initialized in the first place. This patch adds the missing check in mlx5_vdpa_destroy_mr_resources() to block releasing non-initialized mr resources. Reference trace: mlx5_core 0000:08:00.2: mlx5_vdpa_dev_add:3274:(pid 2700) warning: No mac address provisioned? BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 140216067 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 8 PID: 2700 Comm: vdpa Kdump: loaded Not tainted 5.14.0-496.el9.x86_64 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:vhost_iotlb_del_range+0xf/0xe0 [vhost_iotlb] Code: [...] RSP: 0018:ff1c823ac23077f0 EFLAGS: 00010246 RAX: ffffffffc1a21a60 RBX: ffffffff899567a0 RCX: 0000000000000000 RDX: ffffffffffffffff RSI: 0000000000000000 RDI: 0000000000000000 RBP: ff1bda1f7c21e800 R08: 0000000000000000 R09: ff1c823ac2307670 R10: ff1c823ac2307668 R11: ffffffff8a9e7b68 R12: 0000000000000000 R13: 0000000000000000 R14: ff1bda1f43e341a0 R15: 00000000ffffffea FS: 00007f56eba7c740(0000) GS:ff1bda269f800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000104d90001 CR4: 0000000000771ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? mlx5_vdpa_free+0x3d/0x150 [mlx5_vdpa] ? __die_body.cold+0x8/0xd ? page_fault_oops+0x134/0x170 ? __irq_work_queue_local+0x2b/0xc0 ? irq_work_queue+0x2c/0x50 ? exc_page_fault+0x62/0x150 ? asm_exc_page_fault+0x22/0x30 ? __pfx_mlx5_vdpa_free+0x10/0x10 [mlx5_vdpa] ? vhost_iotlb_del_range+0xf/0xe0 [vhost_iotlb] mlx5_vdpa_free+0x3d/0x150 [mlx5_vdpa] vdpa_release_dev+0x1e/0x50 [vdpa] device_release+0x31/0x90 kobject_cleanup+0x37/0x130 mlx5_vdpa_dev_add+0x2d2/0x7a0 [mlx5_vdpa] vdpa_nl_cmd_dev_add_set_doit+0x277/0x4c0 [vdpa] genl_family_rcv_msg_doit+0xd9/0x130 genl_family_rcv_msg+0x14d/0x220 ? __pfx_vdpa_nl_cmd_dev_add_set_doit+0x10/0x10 [vdpa] ? _copy_to_user+0x1a/0x30 ? move_addr_to_user+0x4b/0xe0 genl_rcv_msg+0x47/0xa0 ? __import_iovec+0x46/0x150 ? __pfx_genl_rcv_msg+0x10/0x10 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x245/0x370 netlink_sendmsg+0x206/0x440 __sys_sendto+0x1dc/0x1f0 ? do_read_fault+0x10c/0x1d0 ? do_pte_missing+0x10d/0x190 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x5c/0xf0 ? __count_memcg_events+0x4f/0xb0 ? mm_account_fault+0x6c/0x100 ? handle_mm_fault+0x116/0x270 ? do_user_addr_fault+0x1d6/0x6a0 ? do_syscall_64+0x6b/0xf0 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 entry_SYSCALL_64_after_hwframe+0x78/0x80", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47688", "url": "https://ubuntu.com/security/CVE-2024-47688", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: driver core: Fix a potential null-ptr-deref in module_add_driver() Inject fault while probing of-fpga-region, if kasprintf() fails in module_add_driver(), the second sysfs_remove_link() in exit path will cause null-ptr-deref as below because kernfs_name_hash() will call strlen() with NULL driver_name. Fix it by releasing resources based on the exit path sequence. \t KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] \t Mem abort info: \t ESR = 0x0000000096000005 \t EC = 0x25: DABT (current EL), IL = 32 bits \t SET = 0, FnV = 0 \t EA = 0, S1PTW = 0 \t FSC = 0x05: level 1 translation fault \t Data abort info: \t ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 \t CM = 0, WnR = 0, TnD = 0, TagAccess = 0 \t GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 \t [dfffffc000000000] address between user and kernel address ranges \t Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP \t Dumping ftrace buffer: \t (ftrace buffer empty) \t Modules linked in: of_fpga_region(+) fpga_region fpga_bridge cfg80211 rfkill 8021q garp mrp stp llc ipv6 [last unloaded: of_fpga_region] \t CPU: 2 UID: 0 PID: 2036 Comm: modprobe Not tainted 6.11.0-rc2-g6a0e38264012 #295 \t Hardware name: linux,dummy-virt (DT) \t pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) \t pc : strlen+0x24/0xb0 \t lr : kernfs_name_hash+0x1c/0xc4 \t sp : ffffffc081f97380 \t x29: ffffffc081f97380 x28: ffffffc081f97b90 x27: ffffff80c821c2a0 \t x26: ffffffedac0be418 x25: 0000000000000000 x24: ffffff80c09d2000 \t x23: 0000000000000000 x22: 0000000000000000 x21: 0000000000000000 \t x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000001840 \t x17: 0000000000000000 x16: 0000000000000000 x15: 1ffffff8103f2e42 \t x14: 00000000f1f1f1f1 x13: 0000000000000004 x12: ffffffb01812d61d \t x11: 1ffffff01812d61c x10: ffffffb01812d61c x9 : dfffffc000000000 \t x8 : 0000004fe7ed29e4 x7 : ffffff80c096b0e7 x6 : 0000000000000001 \t x5 : ffffff80c096b0e0 x4 : 1ffffffdb990efa2 x3 : 0000000000000000 \t x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000000 \t Call trace: \t strlen+0x24/0xb0 \t kernfs_name_hash+0x1c/0xc4 \t kernfs_find_ns+0x118/0x2e8 \t kernfs_remove_by_name_ns+0x80/0x100 \t sysfs_remove_link+0x74/0xa8 \t module_add_driver+0x278/0x394 \t bus_add_driver+0x1f0/0x43c \t driver_register+0xf4/0x3c0 \t __platform_driver_register+0x60/0x88 \t of_fpga_region_init+0x20/0x1000 [of_fpga_region] \t do_one_initcall+0x110/0x788 \t do_init_module+0x1dc/0x5c8 \t load_module+0x3c38/0x4cac \t init_module_from_file+0xd4/0x128 \t idempotent_init_module+0x2cc/0x528 \t __arm64_sys_finit_module+0xac/0x100 \t invoke_syscall+0x6c/0x258 \t el0_svc_common.constprop.0+0x160/0x22c \t do_el0_svc+0x44/0x5c \t el0_svc+0x48/0xb8 \t el0t_64_sync_handler+0x13c/0x158 \t el0t_64_sync+0x190/0x194 \t Code: f2fbffe1 a90157f4 12000802 aa0003f5 (38e16861) \t ---[ end trace 0000000000000000 ]--- \t Kernel panic - not syncing: Oops: Fatal exception", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47689", "url": "https://ubuntu.com/security/CVE-2024-47689", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to don't set SB_RDONLY in f2fs_handle_critical_error() syzbot reports a f2fs bug as below: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 58 at kernel/rcu/sync.c:177 rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177 CPU: 1 UID: 0 PID: 58 Comm: kworker/1:2 Not tainted 6.10.0-syzkaller-12562-g1722389b0d86 #0 Workqueue: events destroy_super_work RIP: 0010:rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177 Call Trace: percpu_free_rwsem+0x41/0x80 kernel/locking/percpu-rwsem.c:42 destroy_super_work+0xec/0x130 fs/super.c:282 process_one_work kernel/workqueue.c:3231 [inline] process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 worker_thread+0x86d/0xd40 kernel/workqueue.c:3390 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 As Christian Brauner pointed out [1]: the root cause is f2fs sets SB_RDONLY flag in internal function, rather than setting the flag covered w/ sb->s_umount semaphore via remount procedure, then below race condition causes this bug: - freeze_super() - sb_wait_write(sb, SB_FREEZE_WRITE) - sb_wait_write(sb, SB_FREEZE_PAGEFAULT) - sb_wait_write(sb, SB_FREEZE_FS) \t\t\t\t\t- f2fs_handle_critical_error \t\t\t\t\t - sb->s_flags |= SB_RDONLY - thaw_super - thaw_super_locked - sb_rdonly() is true, so it skips sb_freeze_unlock(sb, SB_FREEZE_FS) - deactivate_locked_super Since f2fs has almost the same logic as ext4 [2] when handling critical error in filesystem if it mounts w/ errors=remount-ro option: - set CP_ERROR_FLAG flag which indicates filesystem is stopped - record errors to superblock - set SB_RDONLY falg Once we set CP_ERROR_FLAG flag, all writable interfaces can detect the flag and stop any further updates on filesystem. So, it is safe to not set SB_RDONLY flag, let's remove the logic and keep in line w/ ext4 [3]. [1] https://lore.kernel.org/all/20240729-himbeeren-funknetz-96e62f9c7aee@brauner [2] https://lore.kernel.org/all/20240729132721.hxih6ehigadqf7wx@quack3 [3] https://lore.kernel.org/linux-ext4/20240805201241.27286-1-jack@suse.cz", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47690", "url": "https://ubuntu.com/security/CVE-2024-47690", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: get rid of online repaire on corrupted directory syzbot reports a f2fs bug as below: kernel BUG at fs/f2fs/inode.c:896! RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Call Trace: evict+0x532/0x950 fs/inode.c:704 dispose_list fs/inode.c:747 [inline] evict_inodes+0x5f9/0x690 fs/inode.c:797 generic_shutdown_super+0x9d/0x2d0 fs/super.c:627 kill_block_super+0x44/0x90 fs/super.c:1696 kill_f2fs_super+0x344/0x690 fs/f2fs/super.c:4898 deactivate_locked_super+0xc4/0x130 fs/super.c:473 cleanup_mnt+0x41f/0x4b0 fs/namespace.c:1373 task_work_run+0x24f/0x310 kernel/task_work.c:228 ptrace_notify+0x2d2/0x380 kernel/signal.c:2402 ptrace_report_syscall include/linux/ptrace.h:415 [inline] ptrace_report_syscall_exit include/linux/ptrace.h:477 [inline] syscall_exit_work+0xc6/0x190 kernel/entry/common.c:173 syscall_exit_to_user_mode_prepare kernel/entry/common.c:200 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:205 [inline] syscall_exit_to_user_mode+0x279/0x370 kernel/entry/common.c:218 do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Online repaire on corrupted directory in f2fs_lookup() can generate dirty data/meta while racing w/ readonly remount, it may leave dirty inode after filesystem becomes readonly, however, checkpoint() will skips flushing dirty inode in a state of readonly mode, result in above panic. Let's get rid of online repaire in f2fs_lookup(), and leave the work to fsck.f2fs.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47691", "url": "https://ubuntu.com/security/CVE-2024-47691", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread() syzbot reports a f2fs bug as below: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_report+0xe8/0x550 mm/kasan/report.c:491 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 instrument_atomic_read_write include/linux/instrumented.h:96 [inline] atomic_fetch_add_relaxed include/linux/atomic/atomic-instrumented.h:252 [inline] __refcount_add include/linux/refcount.h:184 [inline] __refcount_inc include/linux/refcount.h:241 [inline] refcount_inc include/linux/refcount.h:258 [inline] get_task_struct include/linux/sched/task.h:118 [inline] kthread_stop+0xca/0x630 kernel/kthread.c:704 f2fs_stop_gc_thread+0x65/0xb0 fs/f2fs/gc.c:210 f2fs_do_shutdown+0x192/0x540 fs/f2fs/file.c:2283 f2fs_ioc_shutdown fs/f2fs/file.c:2325 [inline] __f2fs_ioctl+0x443a/0xbe60 fs/f2fs/file.c:4325 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f The root cause is below race condition, it may cause use-after-free issue in sbi->gc_th pointer. - remount - f2fs_remount - f2fs_stop_gc_thread - kfree(gc_th) \t\t\t\t- f2fs_ioc_shutdown \t\t\t\t - f2fs_do_shutdown \t\t\t\t - f2fs_stop_gc_thread \t\t\t\t - kthread_stop(gc_th->f2fs_gc_task) : sbi->gc_thread = NULL; We will call f2fs_do_shutdown() in two paths: - for f2fs_ioc_shutdown() path, we should grab sb->s_umount semaphore for fixing. - for f2fs_shutdown() path, it's safe since caller has already grabbed sb->s_umount semaphore.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47692", "url": "https://ubuntu.com/security/CVE-2024-47692", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: return -EINVAL when namelen is 0 When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may result in namelen being 0, which will cause memdup_user() to return ZERO_SIZE_PTR. When we access the name.data that has been assigned the value of ZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is triggered. [ T1205] ================================================================== [ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260 [ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205 [ T1205] [ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406 [ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ T1205] Call Trace: [ T1205] dump_stack+0x9a/0xd0 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] __kasan_report.cold+0x34/0x84 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] kasan_report+0x3a/0x50 [ T1205] nfs4_client_to_reclaim+0xe9/0x260 [ T1205] ? nfsd4_release_lockowner+0x410/0x410 [ T1205] cld_pipe_downcall+0x5ca/0x760 [ T1205] ? nfsd4_cld_tracking_exit+0x1d0/0x1d0 [ T1205] ? down_write_killable_nested+0x170/0x170 [ T1205] ? avc_policy_seqno+0x28/0x40 [ T1205] ? selinux_file_permission+0x1b4/0x1e0 [ T1205] rpc_pipe_write+0x84/0xb0 [ T1205] vfs_write+0x143/0x520 [ T1205] ksys_write+0xc9/0x170 [ T1205] ? __ia32_sys_read+0x50/0x50 [ T1205] ? ktime_get_coarse_real_ts64+0xfe/0x110 [ T1205] ? ktime_get_coarse_real_ts64+0xa2/0x110 [ T1205] do_syscall_64+0x33/0x40 [ T1205] entry_SYSCALL_64_after_hwframe+0x67/0xd1 [ T1205] RIP: 0033:0x7fdbdb761bc7 [ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 514 [ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7 [ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008 [ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001 [ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b [ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000 [ T1205] ================================================================== Fix it by checking namelen.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47737", "url": "https://ubuntu.com/security/CVE-2024-47737", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: call cache_put if xdr_reserve_space returns NULL If not enough buffer space available, but idmap_lookup has triggered lookup_fn which calls cache_get and returns successfully. Then we missed to call cache_put here which pairs with cache_get. Reviwed-by: Jeff Layton ", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2023-52917", "url": "https://ubuntu.com/security/CVE-2023-52917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir() The debugfs_create_dir() function returns error pointers. It never returns NULL. So use IS_ERR() to check it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47749", "url": "https://ubuntu.com/security/CVE-2024-47749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Added NULL check for lookup_atid The lookup_atid() function can return NULL if the ATID is invalid or does not exist in the identifier table, which could lead to dereferencing a null pointer without a check in the `act_establish()` and `act_open_rpl()` functions. Add a NULL check to prevent null pointer dereferencing. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47735", "url": "https://ubuntu.com/security/CVE-2024-47735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled Fix missuse of spin_lock_irq()/spin_unlock_irq() when spin_lock_irqsave()/spin_lock_irqrestore() was hold. This was discovered through the lock debugging, and the corresponding log is as follows: raw_local_irq_restore() called with IRQs enabled WARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40 ... Call trace: warn_bogus_irq_restore+0x30/0x40 _raw_spin_unlock_irqrestore+0x84/0xc8 add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2] hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2] hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2] create_qp+0x138/0x258 ib_create_qp_kernel+0x50/0xe8 create_mad_qp+0xa8/0x128 ib_mad_port_open+0x218/0x448 ib_mad_init_device+0x70/0x1f8 add_client_context+0xfc/0x220 enable_device_and_get+0xd0/0x140 ib_register_device.part.0+0xf4/0x1c8 ib_register_device+0x34/0x50 hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2] hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2] __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2] hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47750", "url": "https://ubuntu.com/security/CVE-2024-47750", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix Use-After-Free of rsv_qp on HIP08 Currently rsv_qp is freed before ib_unregister_device() is called on HIP08. During the time interval, users can still dereg MR and rsv_qp will be used in this process, leading to a UAF. Move the release of rsv_qp after calling ib_unregister_device() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47751", "url": "https://ubuntu.com/security/CVE-2024-47751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: kirin: Fix buffer overflow in kirin_pcie_parse_port() Within kirin_pcie_parse_port(), the pcie->num_slots is compared to pcie->gpio_id_reset size (MAX_PCI_SLOTS) which is correct and would lead to an overflow. Thus, fix condition to pcie->num_slots + 1 >= MAX_PCI_SLOTS and move pcie->num_slots increment below the if-statement to avoid out-of-bounds array access. Found by Linux Verification Center (linuxtesting.org) with SVACE. [kwilczynski: commit log]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47693", "url": "https://ubuntu.com/security/CVE-2024-47693", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/core: Fix ib_cache_setup_one error flow cleanup When ib_cache_update return an error, we exit ib_cache_setup_one instantly with no proper cleanup, even though before this we had already successfully done gid_table_setup_one, that results in the kernel WARN below. Do proper cleanup using gid_table_cleanup_one before returning the err in order to fix the issue. WARNING: CPU: 4 PID: 922 at drivers/infiniband/core/cache.c:806 gid_table_release_one+0x181/0x1a0 Modules linked in: CPU: 4 UID: 0 PID: 922 Comm: c_repro Not tainted 6.11.0-rc1+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:gid_table_release_one+0x181/0x1a0 Code: 44 8b 38 75 0c e8 2f cb 34 ff 4d 8b b5 28 05 00 00 e8 23 cb 34 ff 44 89 f9 89 da 4c 89 f6 48 c7 c7 d0 58 14 83 e8 4f de 21 ff <0f> 0b 4c 8b 75 30 e9 54 ff ff ff 48 8 3 c4 10 5b 5d 41 5c 41 5d 41 RSP: 0018:ffffc90002b835b0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c8527 RDX: 0000000000000000 RSI: ffffffff811c8534 RDI: 0000000000000001 RBP: ffff8881011b3d00 R08: ffff88810b3abe00 R09: 205d303839303631 R10: 666572207972746e R11: 72746e6520444947 R12: 0000000000000001 R13: ffff888106390000 R14: ffff8881011f2110 R15: 0000000000000001 FS: 00007fecc3b70800(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000340 CR3: 000000010435a001 CR4: 00000000003706b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? show_regs+0x94/0xa0 ? __warn+0x9e/0x1c0 ? gid_table_release_one+0x181/0x1a0 ? report_bug+0x1f9/0x340 ? gid_table_release_one+0x181/0x1a0 ? handle_bug+0xa2/0x110 ? exc_invalid_op+0x31/0xa0 ? asm_exc_invalid_op+0x16/0x20 ? __warn_printk+0xc7/0x180 ? __warn_printk+0xd4/0x180 ? gid_table_release_one+0x181/0x1a0 ib_device_release+0x71/0xe0 ? __pfx_ib_device_release+0x10/0x10 device_release+0x44/0xd0 kobject_put+0x135/0x3d0 put_device+0x20/0x30 rxe_net_add+0x7d/0xa0 rxe_newlink+0xd7/0x190 nldev_newlink+0x1b0/0x2a0 ? __pfx_nldev_newlink+0x10/0x10 rdma_nl_rcv_msg+0x1ad/0x2e0 rdma_nl_rcv_skb.constprop.0+0x176/0x210 netlink_unicast+0x2de/0x400 netlink_sendmsg+0x306/0x660 __sock_sendmsg+0x110/0x120 ____sys_sendmsg+0x30e/0x390 ___sys_sendmsg+0x9b/0xf0 ? kstrtouint+0x6e/0xa0 ? kstrtouint_from_user+0x7c/0xb0 ? get_pid_task+0xb0/0xd0 ? proc_fail_nth_write+0x5b/0x140 ? __fget_light+0x9a/0x200 ? preempt_count_add+0x47/0xa0 __sys_sendmsg+0x61/0xd0 do_syscall_64+0x50/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47694", "url": "https://ubuntu.com/security/CVE-2024-47694", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mlx5: Fix UMR pd cleanup on error flow of driver init The cited commit moves the pd allocation from function mlx5r_umr_resource_cleanup() to a new function mlx5r_umr_cleanup(). So the fix in commit [1] is broken. In error flow, will hit panic [2]. Fix it by checking pd pointer to avoid panic if it is NULL; [1] RDMA/mlx5: Fix UMR cleanup on error flow of driver init [2] [ 347.567063] infiniband mlx5_0: Couldn't register device with driver model [ 347.591382] BUG: kernel NULL pointer dereference, address: 0000000000000020 [ 347.593438] #PF: supervisor read access in kernel mode [ 347.595176] #PF: error_code(0x0000) - not-present page [ 347.596962] PGD 0 P4D 0 [ 347.601361] RIP: 0010:ib_dealloc_pd_user+0x12/0xc0 [ib_core] [ 347.604171] RSP: 0018:ffff888106293b10 EFLAGS: 00010282 [ 347.604834] RAX: 0000000000000000 RBX: 000000000000000e RCX: 0000000000000000 [ 347.605672] RDX: ffff888106293ad0 RSI: 0000000000000000 RDI: 0000000000000000 [ 347.606529] RBP: 0000000000000000 R08: ffff888106293ae0 R09: ffff888106293ae0 [ 347.607379] R10: 0000000000000a06 R11: 0000000000000000 R12: 0000000000000000 [ 347.608224] R13: ffffffffa0704dc0 R14: 0000000000000001 R15: 0000000000000001 [ 347.609067] FS: 00007fdc720cd9c0(0000) GS:ffff88852c880000(0000) knlGS:0000000000000000 [ 347.610094] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 347.610727] CR2: 0000000000000020 CR3: 0000000103012003 CR4: 0000000000370eb0 [ 347.611421] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 347.612113] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 347.612804] Call Trace: [ 347.613130] [ 347.613417] ? __die+0x20/0x60 [ 347.613793] ? page_fault_oops+0x150/0x3e0 [ 347.614243] ? free_msg+0x68/0x80 [mlx5_core] [ 347.614840] ? cmd_exec+0x48f/0x11d0 [mlx5_core] [ 347.615359] ? exc_page_fault+0x74/0x130 [ 347.615808] ? asm_exc_page_fault+0x22/0x30 [ 347.616273] ? ib_dealloc_pd_user+0x12/0xc0 [ib_core] [ 347.616801] mlx5r_umr_cleanup+0x23/0x90 [mlx5_ib] [ 347.617365] mlx5_ib_stage_pre_ib_reg_umr_cleanup+0x36/0x40 [mlx5_ib] [ 347.618025] __mlx5_ib_add+0x96/0xd0 [mlx5_ib] [ 347.618539] mlx5r_probe+0xe9/0x310 [mlx5_ib] [ 347.619032] ? kernfs_add_one+0x107/0x150 [ 347.619478] ? __mlx5_ib_add+0xd0/0xd0 [mlx5_ib] [ 347.619984] auxiliary_bus_probe+0x3e/0x90 [ 347.620448] really_probe+0xc5/0x3a0 [ 347.620857] __driver_probe_device+0x80/0x160 [ 347.621325] driver_probe_device+0x1e/0x90 [ 347.621770] __driver_attach+0xec/0x1c0 [ 347.622213] ? __device_attach_driver+0x100/0x100 [ 347.622724] bus_for_each_dev+0x71/0xc0 [ 347.623151] bus_add_driver+0xed/0x240 [ 347.623570] driver_register+0x58/0x100 [ 347.623998] __auxiliary_driver_register+0x6a/0xc0 [ 347.624499] ? driver_register+0xae/0x100 [ 347.624940] ? 0xffffffffa0893000 [ 347.625329] mlx5_ib_init+0x16a/0x1e0 [mlx5_ib] [ 347.625845] do_one_initcall+0x4a/0x2a0 [ 347.626273] ? gcov_event+0x2e2/0x3a0 [ 347.626706] do_init_module+0x8a/0x260 [ 347.627126] init_module_from_file+0x8b/0xd0 [ 347.627596] __x64_sys_finit_module+0x1ca/0x2f0 [ 347.628089] do_syscall_64+0x4c/0x100", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47695", "url": "https://ubuntu.com/security/CVE-2024-47695", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds In the function init_conns(), after the create_con() and create_cm() for loop if something fails. In the cleanup for loop after the destroy tag, we access out of bound memory because cid is set to clt_path->s.con_num. This commits resets the cid to clt_path->s.con_num - 1, to stay in bounds in the cleanup loop later.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47752", "url": "https://ubuntu.com/security/CVE-2024-47752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix H264 stateless decoder smatch warning Fix a smatch static checker warning on vdec_h264_req_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47753", "url": "https://ubuntu.com/security/CVE-2024-47753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix VP8 stateless decoder smatch warning Fix a smatch static checker warning on vdec_vp8_req_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47754", "url": "https://ubuntu.com/security/CVE-2024-47754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix H264 multi stateless decoder smatch warning Fix a smatch static checker warning on vdec_h264_req_multi_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47696", "url": "https://ubuntu.com/security/CVE-2024-47696", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency In the commit aee2424246f9 (\"RDMA/iwcm: Fix a use-after-free related to destroying CM IDs\"), the function flush_workqueue is invoked to flush the work queue iwcm_wq. But at that time, the work queue iwcm_wq was created via the function alloc_ordered_workqueue without the flag WQ_MEM_RECLAIM. Because the current process is trying to flush the whole iwcm_wq, if iwcm_wq doesn't have the flag WQ_MEM_RECLAIM, verify that the current process is not reclaiming memory or running on a workqueue which doesn't have the flag WQ_MEM_RECLAIM as that can break forward-progress guarantee leading to a deadlock. The call trace is as below: [ 125.350876][ T1430] Call Trace: [ 125.356281][ T1430] [ 125.361285][ T1430] ? __warn (kernel/panic.c:693) [ 125.367640][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.375689][ T1430] ? report_bug (lib/bug.c:180 lib/bug.c:219) [ 125.382505][ T1430] ? handle_bug (arch/x86/kernel/traps.c:239) [ 125.388987][ T1430] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) [ 125.395831][ T1430] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621) [ 125.403125][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.410984][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.418764][ T1430] __flush_workqueue (kernel/workqueue.c:3970) [ 125.426021][ T1430] ? __pfx___might_resched (kernel/sched/core.c:10151) [ 125.433431][ T1430] ? destroy_cm_id (drivers/infiniband/core/iwcm.c:375) iw_cm [ 125.441209][ T1430] ? __pfx___flush_workqueue (kernel/workqueue.c:3910) [ 125.473900][ T1430] ? _raw_spin_lock_irqsave (arch/x86/include/asm/atomic.h:107 include/linux/atomic/atomic-arch-fallback.h:2170 include/linux/atomic/atomic-instrumented.h:1302 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162) [ 125.473909][ T1430] ? __pfx__raw_spin_lock_irqsave (kernel/locking/spinlock.c:161) [ 125.482537][ T1430] _destroy_id (drivers/infiniband/core/cma.c:2044) rdma_cm [ 125.495072][ T1430] nvme_rdma_free_queue (drivers/nvme/host/rdma.c:656 drivers/nvme/host/rdma.c:650) nvme_rdma [ 125.505827][ T1430] nvme_rdma_reset_ctrl_work (drivers/nvme/host/rdma.c:2180) nvme_rdma [ 125.505831][ T1430] process_one_work (kernel/workqueue.c:3231) [ 125.515122][ T1430] worker_thread (kernel/workqueue.c:3306 kernel/workqueue.c:3393) [ 125.515127][ T1430] ? __pfx_worker_thread (kernel/workqueue.c:3339) [ 125.531837][ T1430] kthread (kernel/kthread.c:389) [ 125.539864][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.550628][ T1430] ret_from_fork (arch/x86/kernel/process.c:147) [ 125.558840][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.558844][ T1430] ret_from_fork_asm (arch/x86/entry/entry_64.S:257) [ 125.566487][ T1430] [ 125.566488][ T1430] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47755", "url": "https://ubuntu.com/security/CVE-2024-47755", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47756", "url": "https://ubuntu.com/security/CVE-2024-47756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: keystone: Fix if-statement expression in ks_pcie_quirk() This code accidentally uses && where || was intended. It potentially results in a NULL dereference. Thus, fix the if-statement expression to use the correct condition. [kwilczynski: commit log]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47697", "url": "https://ubuntu.com/security/CVE-2024-47697", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error Ensure index in rtl2830_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47698", "url": "https://ubuntu.com/security/CVE-2024-47698", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error Ensure index in rtl2832_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue. [hverkuil: added fixes tag, rtl2830_pid_filter -> rtl2832_pid_filter in logmsg]", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47728", "url": "https://ubuntu.com/security/CVE-2024-47728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error For all non-tracing helpers which formerly had ARG_PTR_TO_{LONG,INT} as input arguments, zero the value for the case of an error as otherwise it could leak memory. For tracing, it is not needed given CAP_PERFMON can already read all kernel memory anyway hence bpf_get_func_arg() and bpf_get_func_ret() is skipped in here. Also, the MTU helpers mtu_len pointer value is being written but also read. Technically, the MEM_UNINIT should not be there in order to always force init. Removing MEM_UNINIT needs more verifier rework though: MEM_UNINIT right now implies two things actually: i) write into memory, ii) memory does not have to be initialized. If we lift MEM_UNINIT, it then becomes: i) read into memory, ii) memory must be initialized. This means that for bpf_*_check_mtu() we're readding the issue we're trying to fix, that is, it would then be able to write back into things like .rodata BPF maps. Follow-up work will rework the MEM_UNINIT semantics such that the intent can be better expressed. For now just clear the *mtu_len on error path which can be lifted later again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49861", "url": "https://ubuntu.com/security/CVE-2024-49861", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix helper writes to read-only maps Lonial found an issue that despite user- and BPF-side frozen BPF map (like in case of .rodata), it was still possible to write into it from a BPF program side through specific helpers having ARG_PTR_TO_{LONG,INT} as arguments. In check_func_arg() when the argument is as mentioned, the meta->raw_mode is never set. Later, check_helper_mem_access(), under the case of PTR_TO_MAP_VALUE as register base type, it assumes BPF_READ for the subsequent call to check_map_access_type() and given the BPF map is read-only it succeeds. The helpers really need to be annotated as ARG_PTR_TO_{LONG,INT} | MEM_UNINIT when results are written into them as opposed to read out of them. The latter indicates that it's okay to pass a pointer to uninitialized memory as the memory is written to anyway. However, ARG_PTR_TO_{LONG,INT} is a special case of ARG_PTR_TO_FIXED_SIZE_MEM just with additional alignment requirement. So it is better to just get rid of the ARG_PTR_TO_{LONG,INT} special cases altogether and reuse the fixed size memory types. For this, add MEM_ALIGNED to additionally ensure alignment given these helpers write directly into the args via * = val. The .arg*_size has been initialized reflecting the actual sizeof(*). MEM_ALIGNED can only be used in combination with MEM_FIXED_SIZE annotated argument types, since in !MEM_FIXED_SIZE cases the verifier does not know the buffer size a priori and therefore cannot blindly write * = val.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47757", "url": "https://ubuntu.com/security/CVE-2024-47757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential oob read in nilfs_btree_check_delete() The function nilfs_btree_check_delete(), which checks whether degeneration to direct mapping occurs before deleting a b-tree entry, causes memory access outside the block buffer when retrieving the maximum key if the root node has no entries. This does not usually happen because b-tree mappings with 0 child nodes are never created by mkfs.nilfs2 or nilfs2 itself. However, it can happen if the b-tree root node read from a device is configured that way, so fix this potential issue by adding a check for that case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47699", "url": "https://ubuntu.com/security/CVE-2024-47699", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential null-ptr-deref in nilfs_btree_insert() Patch series \"nilfs2: fix potential issues with empty b-tree nodes\". This series addresses three potential issues with empty b-tree nodes that can occur with corrupted filesystem images, including one recently discovered by syzbot. This patch (of 3): If a b-tree is broken on the device, and the b-tree height is greater than 2 (the level of the root node is greater than 1) even if the number of child nodes of the b-tree root is 0, a NULL pointer dereference occurs in nilfs_btree_prepare_insert(), which is called from nilfs_btree_insert(). This is because, when the number of child nodes of the b-tree root is 0, nilfs_btree_do_lookup() does not set the block buffer head in any of path[x].bp_bh, leaving it as the initial value of NULL, but if the level of the b-tree root node is greater than 1, nilfs_btree_get_nonroot_node(), which accesses the buffer memory of path[x].bp_bh, is called. Fix this issue by adding a check to nilfs_btree_root_broken(), which performs sanity checks when reading the root node from the device, to detect this inconsistency. Thanks to Lizhi Xu for trying to solve the bug and clarifying the cause early on.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47700", "url": "https://ubuntu.com/security/CVE-2024-47700", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: check stripe size compatibility on remount as well We disable stripe size in __ext4_fill_super if it is not a multiple of the cluster ratio however this check is missed when trying to remount. This can leave us with cases where stripe < cluster_ratio after remount:set making EXT4_B2C(sbi->s_stripe) become 0 that can cause some unforeseen bugs like divide by 0. Fix that by adding the check in remount path as well.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47701", "url": "https://ubuntu.com/security/CVE-2024-47701", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid OOB when system.data xattr changes underneath the filesystem When looking up for an entry in an inlined directory, if e_value_offs is changed underneath the filesystem by some change in the block device, it will lead to an out-of-bounds access that KASAN detects as an UAF. EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none. loop0: detected capacity change from 2048 to 2047 ================================================================== BUG: KASAN: use-after-free in ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 Read of size 1 at addr ffff88803e91130f by task syz-executor269/5103 CPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 Not tainted 6.11.0-rc4-syzkaller #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:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 ext4_find_inline_entry+0x4be/0x5e0 fs/ext4/inline.c:1697 __ext4_find_entry+0x2b4/0x1b30 fs/ext4/namei.c:1573 ext4_lookup_entry fs/ext4/namei.c:1727 [inline] ext4_lookup+0x15f/0x750 fs/ext4/namei.c:1795 lookup_one_qstr_excl+0x11f/0x260 fs/namei.c:1633 filename_create+0x297/0x540 fs/namei.c:3980 do_symlinkat+0xf9/0x3a0 fs/namei.c:4587 __do_sys_symlinkat fs/namei.c:4610 [inline] __se_sys_symlinkat fs/namei.c:4607 [inline] __x64_sys_symlinkat+0x95/0xb0 fs/namei.c:4607 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:0x7f3e73ced469 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff4d40c258 EFLAGS: 00000246 ORIG_RAX: 000000000000010a RAX: ffffffffffffffda RBX: 0032656c69662f2e RCX: 00007f3e73ced469 RDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0 RBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290 R10: 0023706f6f6c2f76 R11: 0000000000000246 R12: 00007fff4d40c27c R13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0 Calling ext4_xattr_ibody_find right after reading the inode with ext4_get_inode_loc will lead to a check of the validity of the xattrs, avoiding this problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49850", "url": "https://ubuntu.com/security/CVE-2024-49850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: correctly handle malformed BPF_CORE_TYPE_ID_LOCAL relos In case of malformed relocation record of kind BPF_CORE_TYPE_ID_LOCAL referencing a non-existing BTF type, function bpf_core_calc_relo_insn would cause a null pointer deference. Fix this by adding a proper check upper in call stack, as malformed relocation records could be passed from user space. Simplest reproducer is a program: r0 = 0 exit With a single relocation record: .insn_off = 0, /* patch first instruction */ .type_id = 100500, /* this type id does not exist */ .access_str_off = 6, /* offset of string \"0\" */ .kind = BPF_CORE_TYPE_ID_LOCAL, See the link for original reproducer or next commit for a test case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47702", "url": "https://ubuntu.com/security/CVE-2024-47702", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fail verification for sign-extension of packet data/data_end/data_meta syzbot reported a kernel crash due to commit 1f1e864b6555 (\"bpf: Handle sign-extenstin ctx member accesses\"). The reason is due to sign-extension of 32-bit load for packet data/data_end/data_meta uapi field. The original code looks like: r2 = *(s32 *)(r1 + 76) /* load __sk_buff->data */ r3 = *(u32 *)(r1 + 80) /* load __sk_buff->data_end */ r0 = r2 r0 += 8 if r3 > r0 goto +1 ... Note that __sk_buff->data load has 32-bit sign extension. After verification and convert_ctx_accesses(), the final asm code looks like: r2 = *(u64 *)(r1 +208) r2 = (s32)r2 r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 ... Note that 'r2 = (s32)r2' may make the kernel __sk_buff->data address invalid which may cause runtime failure. Currently, in C code, typically we have void *data = (void *)(long)skb->data; void *data_end = (void *)(long)skb->data_end; ... and it will generate r2 = *(u64 *)(r1 +208) r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 If we allow sign-extension, void *data = (void *)(long)(int)skb->data; void *data_end = (void *)(long)skb->data_end; ... the generated code looks like r2 = *(u64 *)(r1 +208) r2 <<= 32 r2 s>>= 32 r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 and this will cause verification failure since \"r2 <<= 32\" is not allowed as \"r2\" is a packet pointer. To fix this issue for case r2 = *(s32 *)(r1 + 76) /* load __sk_buff->data */ this patch added additional checking in is_valid_access() callback function for packet data/data_end/data_meta access. If those accesses are with sign-extenstion, the verification will fail. [1] https://lore.kernel.org/bpf/000000000000c90eee061d236d37@google.com/", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47703", "url": "https://ubuntu.com/security/CVE-2024-47703", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, lsm: Add check for BPF LSM return value A bpf prog returning a positive number attached to file_alloc_security hook makes kernel panic. This happens because file system can not filter out the positive number returned by the LSM prog using IS_ERR, and misinterprets this positive number as a file pointer. Given that hook file_alloc_security never returned positive number before the introduction of BPF LSM, and other BPF LSM hooks may encounter similar issues, this patch adds LSM return value check in verifier, to ensure no unexpected value is returned.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49851", "url": "https://ubuntu.com/security/CVE-2024-49851", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: Clean up TPM space after command failure tpm_dev_transmit prepares the TPM space before attempting command transmission. However if the command fails no rollback of this preparation is done. This can result in transient handles being leaked if the device is subsequently closed with no further commands performed. Fix this by flushing the space in the event of command transmission failure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47723", "url": "https://ubuntu.com/security/CVE-2024-47723", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: fix out-of-bounds in dbNextAG() and diAlloc() In dbNextAG() , there is no check for the case where bmp->db_numag is greater or same than MAXAG due to a polluted image, which causes an out-of-bounds. Therefore, a bounds check should be added in dbMount(). And in dbNextAG(), a check for the case where agpref is greater than bmp->db_numag should be added, so an out-of-bounds exception should be prevented. Additionally, a check for the case where agno is greater or same than MAXAG should be added in diAlloc() to prevent out-of-bounds.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49852", "url": "https://ubuntu.com/security/CVE-2024-49852", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: elx: libefc: Fix potential use after free in efc_nport_vport_del() The kref_put() function will call nport->release if the refcount drops to zero. The nport->release release function is _efc_nport_free() which frees \"nport\". But then we dereference \"nport\" on the next line which is a use after free. Re-order these lines to avoid the use after free.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47720", "url": "https://ubuntu.com/security/CVE-2024-47720", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for set_output_gamma in dcn30_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn30_set_output_transfer_func function. Previously, set_output_gamma was being checked for nullity at line 386, but then it was being dereferenced without any nullity check at line 401. This could potentially lead to a null pointer dereference error if set_output_gamma is indeed null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a nullity check for set_output_gamma before the call to set_output_gamma at line 401. If set_output_gamma is null, we log an error message and do not call the function. This fix prevents a potential null pointer dereference error. drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:401 dcn30_set_output_transfer_func() error: we previously assumed 'mpc->funcs->set_output_gamma' could be null (see line 386) drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c 373 bool dcn30_set_output_transfer_func(struct dc *dc, 374 struct pipe_ctx *pipe_ctx, 375 const struct dc_stream_state *stream) 376 { 377 int mpcc_id = pipe_ctx->plane_res.hubp->inst; 378 struct mpc *mpc = pipe_ctx->stream_res.opp->ctx->dc->res_pool->mpc; 379 const struct pwl_params *params = NULL; 380 bool ret = false; 381 382 /* program OGAM or 3DLUT only for the top pipe*/ 383 if (pipe_ctx->top_pipe == NULL) { 384 /*program rmu shaper and 3dlut in MPC*/ 385 ret = dcn30_set_mpc_shaper_3dlut(pipe_ctx, stream); 386 if (ret == false && mpc->funcs->set_output_gamma) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If this is NULL 387 if (stream->out_transfer_func.type == TF_TYPE_HWPWL) 388 params = &stream->out_transfer_func.pwl; 389 else if (pipe_ctx->stream->out_transfer_func.type == 390 TF_TYPE_DISTRIBUTED_POINTS && 391 cm3_helper_translate_curve_to_hw_format( 392 &stream->out_transfer_func, 393 &mpc->blender_params, false)) 394 params = &mpc->blender_params; 395 /* there are no ROM LUTs in OUTGAM */ 396 if (stream->out_transfer_func.type == TF_TYPE_PREDEFINED) 397 BREAK_TO_DEBUGGER(); 398 } 399 } 400 --> 401 mpc->funcs->set_output_gamma(mpc, mpcc_id, params); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Then it will crash 402 return ret; 403 }", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47704", "url": "https://ubuntu.com/security/CVE-2024-47704", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check link_res->hpo_dp_link_enc before using it [WHAT & HOW] Functions dp_enable_link_phy and dp_disable_link_phy can pass link_res without initializing hpo_dp_link_enc and it is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49853", "url": "https://ubuntu.com/security/CVE-2024-49853", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix double free in OPTEE transport Channels can be shared between protocols, avoid freeing the same channel descriptors twice when unloading the stack.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47705", "url": "https://ubuntu.com/security/CVE-2024-47705", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix potential invalid pointer dereference in blk_add_partition The blk_add_partition() function initially used a single if-condition (IS_ERR(part)) to check for errors when adding a partition. This was modified to handle the specific case of -ENXIO separately, allowing the function to proceed without logging the error in this case. However, this change unintentionally left a path where md_autodetect_dev() could be called without confirming that part is a valid pointer. This commit separates the error handling logic by splitting the initial if-condition, improving code readability and handling specific error scenarios explicitly. The function now distinguishes the general error case from -ENXIO without altering the existing behavior of md_autodetect_dev() calls.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47736", "url": "https://ubuntu.com/security/CVE-2024-47736", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: handle overlapped pclusters out of crafted images properly syzbot reported a task hang issue due to a deadlock case where it is waiting for the folio lock of a cached folio that will be used for cache I/Os. After looking into the crafted fuzzed image, I found it's formed with several overlapped big pclusters as below: Ext: logical offset | length : physical offset | length 0: 0.. 16384 | 16384 : 151552.. 167936 | 16384 1: 16384.. 32768 | 16384 : 155648.. 172032 | 16384 2: 32768.. 49152 | 16384 : 537223168.. 537239552 | 16384 ... Here, extent 0/1 are physically overlapped although it's entirely _impossible_ for normal filesystem images generated by mkfs. First, managed folios containing compressed data will be marked as up-to-date and then unlocked immediately (unlike in-place folios) when compressed I/Os are complete. If physical blocks are not submitted in the incremental order, there should be separate BIOs to avoid dependency issues. However, the current code mis-arranges z_erofs_fill_bio_vec() and BIO submission which causes unexpected BIO waits. Second, managed folios will be connected to their own pclusters for efficient inter-queries. However, this is somewhat hard to implement easily if overlapped big pclusters exist. Again, these only appear in fuzzed images so let's simply fall back to temporary short-lived pages for correctness. Additionally, it justifies that referenced managed folios cannot be truncated for now and reverts part of commit 2080ca1ed3e4 (\"erofs: tidy up `struct z_erofs_bvec`\") for simplicity although it shouldn't be any difference.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47706", "url": "https://ubuntu.com/security/CVE-2024-47706", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block, bfq: fix possible UAF for bfqq->bic with merge chain 1) initial state, three tasks: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t\t | ? | ?\t\t | ? \t\t | | | |\t\t | | \t\t V | V |\t\t V | \t\t bfqq1 bfqq2\t\t bfqq3 process ref:\t 1\t\t 1\t\t 1 2) bfqq1 merged to bfqq2: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t\t | |\t\t | ? \t\t \\--------------\\|\t\t | | \t\t V\t\t V | \t\t bfqq1--------->bfqq2\t\t bfqq3 process ref:\t 0\t\t 2\t\t 1 3) bfqq2 merged to bfqq3: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t here -> ? |\t\t | \t\t \\--------------\\ \\-------------\\| \t\t V\t\t V \t\t bfqq1--------->bfqq2---------->bfqq3 process ref:\t 0\t\t 1\t\t 3 In this case, IO from Process 1 will get bfqq2 from BIC1 first, and then get bfqq3 through merge chain, and finially handle IO by bfqq3. Howerver, current code will think bfqq2 is owned by BIC1, like initial state, and set bfqq2->bic to BIC1. bfq_insert_request -> by Process 1 bfqq = bfq_init_rq(rq) bfqq = bfq_get_bfqq_handle_split bfqq = bic_to_bfqq -> get bfqq2 from BIC1 bfqq->ref++ rq->elv.priv[0] = bic rq->elv.priv[1] = bfqq if (bfqq_process_refs(bfqq) == 1) bfqq->bic = bic -> record BIC1 to bfqq2 __bfq_insert_request new_bfqq = bfq_setup_cooperator -> get bfqq3 from bfqq2->new_bfqq bfqq_request_freed(bfqq) new_bfqq->ref++ rq->elv.priv[1] = new_bfqq -> handle IO by bfqq3 Fix the problem by checking bfqq is from merge chain fist. And this might fix a following problem reported by our syzkaller(unreproducible): ================================================================== BUG: KASAN: slab-use-after-free in bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] BUG: KASAN: slab-use-after-free in bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] BUG: KASAN: slab-use-after-free in bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 Write of size 1 at addr ffff888123839eb8 by task kworker/0:1H/18595 CPU: 0 PID: 18595 Comm: kworker/0:1H Tainted: G L 6.6.0-07439-gba2303cacfda #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Workqueue: kblockd blk_mq_requeue_work Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [inline] print_report+0x10d/0x610 mm/kasan/report.c:475 kasan_report+0x8e/0xc0 mm/kasan/report.c:588 bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 bfq_get_bfqq_handle_split+0x169/0x5d0 block/bfq-iosched.c:6757 bfq_init_rq block/bfq-iosched.c:6876 [inline] bfq_insert_request block/bfq-iosched.c:6254 [inline] bfq_insert_requests+0x1112/0x5cf0 block/bfq-iosched.c:6304 blk_mq_insert_request+0x290/0x8d0 block/blk-mq.c:2593 blk_mq_requeue_work+0x6bc/0xa70 block/blk-mq.c:1502 process_one_work kernel/workqueue.c:2627 [inline] process_scheduled_works+0x432/0x13f0 kernel/workqueue.c:2700 worker_thread+0x6f2/0x1160 kernel/workqueue.c:2781 kthread+0x33c/0x440 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:305 Allocated by task 20776: kasan_save_stack+0x20/0x40 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 __kasan_slab_alloc+0x87/0x90 mm/kasan/common.c:328 kasan_slab_alloc include/linux/kasan.h:188 [inline] slab_post_alloc_hook mm/slab.h:763 [inline] slab_alloc_node mm/slub.c:3458 [inline] kmem_cache_alloc_node+0x1a4/0x6f0 mm/slub.c:3503 ioc_create_icq block/blk-ioc.c:370 [inline] ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49855", "url": "https://ubuntu.com/security/CVE-2024-49855", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: fix race between timeout and normal completion If request timetout is handled by nbd_requeue_cmd(), normal completion has to be stopped for avoiding to complete this requeued request, other use-after-free can be triggered. Fix the race by clearing NBD_CMD_INFLIGHT in nbd_requeue_cmd(), meantime make sure that cmd->lock is grabbed for clearing the flag and the requeue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47707", "url": "https://ubuntu.com/security/CVE-2024-47707", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev() Blamed commit accidentally removed a check for rt->rt6i_idev being NULL, as spotted by syzbot: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 UID: 0 PID: 10998 Comm: syz-executor Not tainted 6.11.0-rc6-syzkaller-00208-g625403177711 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 RBP: ffffc900047375d0 R08: 0000000000000003 R09: fffff520008e6e8c R10: dffffc0000000000 R11: fffff520008e6e8c R12: 1ffff1100fdf8f18 R13: ffff88807efc7998 R14: 0000000000000000 R15: ffff88807efc7930 FS: 0000000000000000(0000) GS:ffff8880b8900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020002a80 CR3: 0000000022f62000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: addrconf_ifdown+0x15d/0x1bd0 net/ipv6/addrconf.c:3856 addrconf_notify+0x3cb/0x1020 notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93 call_netdevice_notifiers_extack net/core/dev.c:2032 [inline] call_netdevice_notifiers net/core/dev.c:2046 [inline] unregister_netdevice_many_notify+0xd81/0x1c40 net/core/dev.c:11352 unregister_netdevice_many net/core/dev.c:11414 [inline] unregister_netdevice_queue+0x303/0x370 net/core/dev.c:11289 unregister_netdevice include/linux/netdevice.h:3129 [inline] __tun_detach+0x6b9/0x1600 drivers/net/tun.c:685 tun_detach drivers/net/tun.c:701 [inline] tun_chr_close+0x108/0x1b0 drivers/net/tun.c:3510 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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:0x7f1acc77def9 Code: Unable to access opcode bytes at 0x7f1acc77decf. RSP: 002b:00007ffeb26fa738 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1acc77def9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000043 RBP: 00007f1acc7dd508 R08: 00007ffeb26f84d7 R09: 0000000000000003 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 0000000000000003 R14: 00000000ffffffff R15: 00007ffeb26fa8e0 Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 R ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47708", "url": "https://ubuntu.com/security/CVE-2024-47708", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netkit: Assign missing bpf_net_context During the introduction of struct bpf_net_context handling for XDP-redirect, the netkit driver has been missed, which also requires it because NETKIT_REDIRECT invokes skb_do_redirect() which is accessing the per-CPU variables. Otherwise we see the following crash: \tBUG: kernel NULL pointer dereference, address: 0000000000000038 \tbpf_redirect() \tnetkit_xmit() \tdev_hard_start_xmit() Set the bpf_net_context before invoking netkit_xmit() program within the netkit driver.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47709", "url": "https://ubuntu.com/security/CVE-2024-47709", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: Clear bo->bcm_proc_read after remove_proc_entry(). syzbot reported a warning in bcm_release(). [0] The blamed change fixed another warning that is triggered when connect() is issued again for a socket whose connect()ed device has been unregistered. However, if the socket is just close()d without the 2nd connect(), the remaining bo->bcm_proc_read triggers unnecessary remove_proc_entry() in bcm_release(). Let's clear bo->bcm_proc_read after remove_proc_entry() in bcm_notify(). [0] name '4986' WARNING: CPU: 0 PID: 5234 at fs/proc/generic.c:711 remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Modules linked in: CPU: 0 UID: 0 PID: 5234 Comm: syz-executor606 Not tainted 6.11.0-rc5-syzkaller-00178-g5517ae241919 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Code: ff eb 05 e8 cb 1e 5e ff 48 8b 5c 24 10 48 c7 c7 e0 f7 aa 8e e8 2a 38 8e 09 90 48 c7 c7 60 3a 1b 8c 48 89 de e8 da 42 20 ff 90 <0f> 0b 90 90 48 8b 44 24 18 48 c7 44 24 40 0e 36 e0 45 49 c7 04 07 RSP: 0018:ffffc9000345fa20 EFLAGS: 00010246 RAX: 2a2d0aee2eb64600 RBX: ffff888032f1f548 RCX: ffff888029431e00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000345fb08 R08: ffffffff8155b2f2 R09: 1ffff1101710519a R10: dffffc0000000000 R11: ffffed101710519b R12: ffff888011d38640 R13: 0000000000000004 R14: 0000000000000000 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8880b8800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcfb52722f0 CR3: 000000000e734000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: bcm_release+0x250/0x880 net/can/bcm.c:1578 __sock_release net/socket.c:659 [inline] sock_close+0xbc/0x240 net/socket.c:1421 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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:0x7fcfb51ee969 Code: Unable to access opcode bytes at 0x7fcfb51ee93f. RSP: 002b:00007ffce0109ca8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fcfb51ee969 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 00007fcfb526f3b0 R08: ffffffffffffffb8 R09: 0000555500000000 R10: 0000555500000000 R11: 0000000000000246 R12: 00007fcfb526f3b0 R13: 0000000000000000 R14: 00007fcfb5271ee0 R15: 00007fcfb51bf160 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47710", "url": "https://ubuntu.com/security/CVE-2024-47710", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sock_map: Add a cond_resched() in sock_hash_free() Several syzbot soft lockup reports all have in common sock_hash_free() If a map with a large number of buckets is destroyed, we need to yield the cpu when needed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47711", "url": "https://ubuntu.com/security/CVE-2024-47711", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Don't return OOB skb in manage_oob(). syzbot reported use-after-free in unix_stream_recv_urg(). [0] The scenario is 1. send(MSG_OOB) 2. recv(MSG_OOB) -> The consumed OOB remains in recv queue 3. send(MSG_OOB) 4. recv() -> manage_oob() returns the next skb of the consumed OOB -> This is also OOB, but unix_sk(sk)->oob_skb is not cleared 5. recv(MSG_OOB) -> unix_sk(sk)->oob_skb is used but already freed The recent commit 8594d9b85c07 (\"af_unix: Don't call skb_get() for OOB skb.\") uncovered the issue. If the OOB skb is consumed and the next skb is peeked in manage_oob(), we still need to check if the skb is OOB. Let's do so by falling back to the following checks in manage_oob() and add the test case in selftest. Note that we need to add a similar check for SIOCATMARK. [0]: BUG: KASAN: slab-use-after-free in unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959 Read of size 4 at addr ffff8880326abcc4 by task syz-executor178/5235 CPU: 0 UID: 0 PID: 5235 Comm: syz-executor178 Not tainted 6.11.0-rc5-syzkaller-00742-gfbdaffe41adc #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959 unix_stream_recv_urg+0x1df/0x320 net/unix/af_unix.c:2640 unix_stream_read_generic+0x2456/0x2520 net/unix/af_unix.c:2778 unix_stream_recvmsg+0x22b/0x2c0 net/unix/af_unix.c:2996 sock_recvmsg_nosec net/socket.c:1046 [inline] sock_recvmsg+0x22f/0x280 net/socket.c:1068 ____sys_recvmsg+0x1db/0x470 net/socket.c:2816 ___sys_recvmsg net/socket.c:2858 [inline] __sys_recvmsg+0x2f0/0x3e0 net/socket.c:2888 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:0x7f5360d6b4e9 Code: 48 83 c4 28 c3 e8 37 17 00 00 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff29b3a458 EFLAGS: 00000246 ORIG_RAX: 000000000000002f RAX: ffffffffffffffda RBX: 00007fff29b3a638 RCX: 00007f5360d6b4e9 RDX: 0000000000002001 RSI: 0000000020000640 RDI: 0000000000000003 RBP: 00007f5360dde610 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 00007fff29b3a628 R14: 0000000000000001 R15: 0000000000000001 Allocated by task 5235: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:312 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slub.c:3988 [inline] slab_alloc_node mm/slub.c:4037 [inline] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4080 __alloc_skb+0x1c3/0x440 net/core/skbuff.c:667 alloc_skb include/linux/skbuff.h:1320 [inline] alloc_skb_with_frags+0xc3/0x770 net/core/skbuff.c:6528 sock_alloc_send_pskb+0x91a/0xa60 net/core/sock.c:2815 sock_alloc_send_skb include/net/sock.h:1778 [inline] queue_oob+0x108/0x680 net/unix/af_unix.c:2198 unix_stream_sendmsg+0xd24/0xf80 net/unix/af_unix.c:2351 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2680 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 Freed by task 5235: kasan_save_stack mm/kasan/common.c:47 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47712", "url": "https://ubuntu.com/security/CVE-2024-47712", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: fix potential RCU dereference issue in wilc_parse_join_bss_param In the `wilc_parse_join_bss_param` function, the TSF field of the `ies` structure is accessed after the RCU read-side critical section is unlocked. According to RCU usage rules, this is illegal. Reusing this pointer can lead to unpredictable behavior, including accessing memory that has been updated or causing use-after-free issues. This possible bug was identified using a static analysis tool developed by myself, specifically designed to detect RCU-related issues. To address this, the TSF value is now stored in a local variable `ies_tsf` before the RCU lock is released. The `param->tsf_lo` field is then assigned using this local variable, ensuring that the TSF value is safely accessed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47713", "url": "https://ubuntu.com/security/CVE-2024-47713", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop() Since '__dev_queue_xmit()' should be called with interrupts enabled, the following backtrace: ieee80211_do_stop() ... spin_lock_irqsave(&local->queue_stop_reason_lock, flags) ... ieee80211_free_txskb() ieee80211_report_used_skb() ieee80211_report_ack_skb() cfg80211_mgmt_tx_status_ext() nl80211_frame_tx_status() genlmsg_multicast_netns() genlmsg_multicast_netns_filtered() nlmsg_multicast_filtered() \t netlink_broadcast_filtered() \t do_one_broadcast() \t netlink_broadcast_deliver() \t __netlink_sendskb() \t netlink_deliver_tap() \t __netlink_deliver_tap_skb() \t dev_queue_xmit() \t __dev_queue_xmit() ; with IRQS disabled ... spin_unlock_irqrestore(&local->queue_stop_reason_lock, flags) issues the warning (as reported by syzbot reproducer): WARNING: CPU: 2 PID: 5128 at kernel/softirq.c:362 __local_bh_enable_ip+0xc3/0x120 Fix this by implementing a two-phase skb reclamation in 'ieee80211_do_stop()', where actual work is performed outside of a section with interrupts disabled.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47730", "url": "https://ubuntu.com/security/CVE-2024-47730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/qm - inject error before stopping queue The master ooo cannot be completely closed when the accelerator core reports memory error. Therefore, the driver needs to inject the qm error to close the master ooo. Currently, the qm error is injected after stopping queue, memory may be released immediately after stopping queue, causing the device to access the released memory. Therefore, error is injected to close master ooo before stopping queue to ensure that the device does not access the released memory.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49856", "url": "https://ubuntu.com/security/CVE-2024-49856", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/sgx: Fix deadlock in SGX NUMA node search When the current node doesn't have an EPC section configured by firmware and all other EPC sections are used up, CPU can get stuck inside the while loop that looks for an available EPC page from remote nodes indefinitely, leading to a soft lockup. Note how nid_of_current will never be equal to nid in that while loop because nid_of_current is not set in sgx_numa_mask. Also worth mentioning is that it's perfectly fine for the firmware not to setup an EPC section on a node. While setting up an EPC section on each node can enhance performance, it is not a requirement for functionality. Rework the loop to start and end on *a* node that has SGX memory. This avoids the deadlock looking for the current SGX-lacking node to show up in the loop when it never will.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47714", "url": "https://ubuntu.com/security/CVE-2024-47714", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: use hweight16 to get correct tx antenna The chainmask is u16 so using hweight8 cannot get correct tx_ant. Without this patch, the tx_ant of band 2 would be -1 and lead to the following issue: BUG: KASAN: stack-out-of-bounds in mt7996_mcu_add_sta+0x12e0/0x16e0 [mt7996e]", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47715", "url": "https://ubuntu.com/security/CVE-2024-47715", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: fix oops on non-dbdc mt7986 mt7915_band_config() sets band_idx = 1 on the main phy for mt7986 with MT7975_ONE_ADIE or MT7976_ONE_ADIE. Commit 0335c034e726 (\"wifi: mt76: fix race condition related to checking tx queue fill status\") introduced a dereference of the phys array indirectly indexed by band_idx via wcid->phy_idx in mt76_wcid_cleanup(). This caused the following Oops on affected mt7986 devices: Unable to handle kernel read from unreadable memory at virtual address 0000000000000024 Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x00000005 CM = 0, WnR = 0 user pgtable: 4k pages, 39-bit VAs, pgdp=0000000042545000 [0000000000000024] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 Internal error: Oops: 0000000096000005 [#1] SMP Modules linked in: ... mt7915e mt76_connac_lib mt76 mac80211 cfg80211 ... CPU: 2 PID: 1631 Comm: hostapd Not tainted 5.15.150 #0 Hardware name: ZyXEL EX5700 (Telenor) (DT) pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mt76_wcid_cleanup+0x84/0x22c [mt76] lr : mt76_wcid_cleanup+0x64/0x22c [mt76] sp : ffffffc00a803700 x29: ffffffc00a803700 x28: ffffff80008f7300 x27: ffffff80003f3c00 x26: ffffff80000a7880 x25: ffffffc008c26e00 x24: 0000000000000001 x23: ffffffc000a68114 x22: 0000000000000000 x21: ffffff8004172cc8 x20: ffffffc00a803748 x19: ffffff8004152020 x18: 0000000000000000 x17: 00000000000017c0 x16: ffffffc008ef5000 x15: 0000000000000be0 x14: ffffff8004172e28 x13: ffffff8004172e28 x12: 0000000000000000 x11: 0000000000000000 x10: ffffff8004172e30 x9 : ffffff8004172e28 x8 : 0000000000000000 x7 : ffffff8004156020 x6 : 0000000000000000 x5 : 0000000000000031 x4 : 0000000000000000 x3 : 0000000000000001 x2 : 0000000000000000 x1 : ffffff80008f7300 x0 : 0000000000000024 Call trace: mt76_wcid_cleanup+0x84/0x22c [mt76] __mt76_sta_remove+0x70/0xbc [mt76] mt76_sta_state+0x8c/0x1a4 [mt76] mt7915_eeprom_get_power_delta+0x11e4/0x23a0 [mt7915e] drv_sta_state+0x144/0x274 [mac80211] sta_info_move_state+0x1cc/0x2a4 [mac80211] sta_set_sinfo+0xaf8/0xc24 [mac80211] sta_info_destroy_addr_bss+0x4c/0x6c [mac80211] ieee80211_color_change_finish+0x1c08/0x1e70 [mac80211] cfg80211_check_station_change+0x1360/0x4710 [cfg80211] genl_family_rcv_msg_doit+0xb4/0x110 genl_rcv_msg+0xd0/0x1bc netlink_rcv_skb+0x58/0x120 genl_rcv+0x34/0x50 netlink_unicast+0x1f0/0x2ec netlink_sendmsg+0x198/0x3d0 ____sys_sendmsg+0x1b0/0x210 ___sys_sendmsg+0x80/0xf0 __sys_sendmsg+0x44/0xa0 __arm64_sys_sendmsg+0x20/0x30 invoke_syscall.constprop.0+0x4c/0xe0 do_el0_svc+0x40/0xd0 el0_svc+0x14/0x4c el0t_64_sync_handler+0x100/0x110 el0t_64_sync+0x15c/0x160 Code: d2800002 910092c0 52800023 f9800011 (885f7c01) ---[ end trace 7e42dd9a39ed2281 ]--- Fix by using mt76_dev_phy() which will map band_idx to the correct phy for all hardware combinations.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49857", "url": "https://ubuntu.com/security/CVE-2024-49857", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: set the cipher for secured NDP ranging The cipher pointer is not set, but is derefereced trying to set its content, which leads to a NULL pointer dereference. Fix it by pointing to the cipher parameter before dereferencing.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47738", "url": "https://ubuntu.com/security/CVE-2024-47738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: don't use rate mask for offchannel TX either Like the commit ab9177d83c04 (\"wifi: mac80211: don't use rate mask for scanning\"), ignore incorrect settings to avoid no supported rate warning reported by syzbot. The syzbot did bisect and found cause is commit 9df66d5b9f45 (\"cfg80211: fix default HE tx bitrate mask in 2G band\"), which however corrects bitmask of HE MCS and recognizes correctly settings of empty legacy rate plus HE MCS rate instead of returning -EINVAL. As suggestions [1], follow the change of SCAN TX to consider this case of offchannel TX as well. [1] https://lore.kernel.org/linux-wireless/6ab2dc9c3afe753ca6fdcdd1421e7a1f47e87b84.camel@sipsolutions.net/T/#m2ac2a6d2be06a37c9c47a3d8a44b4f647ed4f024", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47731", "url": "https://ubuntu.com/security/CVE-2024-47731", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers/perf: Fix ali_drw_pmu driver interrupt status clearing The alibaba_uncore_pmu driver forgot to clear all interrupt status in the interrupt processing function. After the PMU counter overflow interrupt occurred, an interrupt storm occurred, causing the system to hang. Therefore, clear the correct interrupt status in the interrupt handling function to fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49862", "url": "https://ubuntu.com/security/CVE-2024-49862", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powercap: intel_rapl: Fix off by one in get_rpi() The rp->priv->rpi array is either rpi_msr or rpi_tpmi which have NR_RAPL_PRIMITIVES number of elements. Thus the > needs to be >= to prevent an off by one access.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47716", "url": "https://ubuntu.com/security/CVE-2024-47716", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: 9410/1: vfp: Use asm volatile in fmrx/fmxr macros Floating point instructions in userspace can crash some arm kernels built with clang/LLD 17.0.6: BUG: unsupported FP instruction in kernel mode FPEXC == 0xc0000780 Internal error: Oops - undefined instruction: 0 [#1] ARM CPU: 0 PID: 196 Comm: vfp-reproducer Not tainted 6.10.0 #1 Hardware name: BCM2835 PC is at vfp_support_entry+0xc8/0x2cc LR is at do_undefinstr+0xa8/0x250 pc : [] lr : [] psr: a0000013 sp : dc8d1f68 ip : 60000013 fp : bedea19c r10: ec532b17 r9 : 00000010 r8 : 0044766c r7 : c0000780 r6 : ec532b17 r5 : c1c13800 r4 : dc8d1fb0 r3 : c10072c4 r2 : c0101c88 r1 : ec532b17 r0 : 0044766c Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 00c5387d Table: 0251c008 DAC: 00000051 Register r0 information: non-paged memory Register r1 information: vmalloc memory Register r2 information: non-slab/vmalloc memory Register r3 information: non-slab/vmalloc memory Register r4 information: 2-page vmalloc region Register r5 information: slab kmalloc-cg-2k Register r6 information: vmalloc memory Register r7 information: non-slab/vmalloc memory Register r8 information: non-paged memory Register r9 information: zero-size pointer Register r10 information: vmalloc memory Register r11 information: non-paged memory Register r12 information: non-paged memory Process vfp-reproducer (pid: 196, stack limit = 0x61aaaf8b) Stack: (0xdc8d1f68 to 0xdc8d2000) 1f60: 0000081f b6f69300 0000000f c10073f4 c10072c4 dc8d1fb0 1f80: ec532b17 0c532b17 0044766c b6f9ccd8 00000000 c010a80c 00447670 60000010 1fa0: ffffffff c1c13800 00c5387d c0100f10 b6f68af8 00448fc0 00000000 bedea188 1fc0: bedea314 00000001 00448ebc b6f9d000 00447608 b6f9ccd8 00000000 bedea19c 1fe0: bede9198 bedea188 b6e1061c 0044766c 60000010 ffffffff 00000000 00000000 Call trace: [] (vfp_support_entry) from [] (do_undefinstr+0xa8/0x250) [] (do_undefinstr) from [] (__und_usr+0x70/0x80) Exception stack(0xdc8d1fb0 to 0xdc8d1ff8) 1fa0: b6f68af8 00448fc0 00000000 bedea188 1fc0: bedea314 00000001 00448ebc b6f9d000 00447608 b6f9ccd8 00000000 bedea19c 1fe0: bede9198 bedea188 b6e1061c 0044766c 60000010 ffffffff Code: 0a000061 e3877202 e594003c e3a09010 (eef16a10) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Fatal exception in interrupt ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]--- This is a minimal userspace reproducer on a Raspberry Pi Zero W: #include #include int main(void) { double v = 1.0; printf(\"%fn\", NAN + *(volatile double *)&v); return 0; } Another way to consistently trigger the oops is: calvin@raspberry-pi-zero-w ~$ python -c \"import json\" The bug reproduces only when the kernel is built with DYNAMIC_DEBUG=n, because the pr_debug() calls act as barriers even when not activated. This is the output from the same kernel source built with the same compiler and DYNAMIC_DEBUG=y, where the userspace reproducer works as expected: VFP: bounce: trigger ec532b17 fpexc c0000780 VFP: emulate: INST=0xee377b06 SCR=0x00000000 VFP: bounce: trigger eef1fa10 fpexc c0000780 VFP: emulate: INST=0xeeb40b40 SCR=0x00000000 VFP: raising exceptions 30000000 calvin@raspberry-pi-zero-w ~$ ./vfp-reproducer nan Crudely grepping for vmsr/vmrs instructions in the otherwise nearly idential text for vfp_support_entry() makes the problem obvious: vmlinux.llvm.good [0xc0101cb8] <+48>: vmrs r7, fpexc vmlinux.llvm.good [0xc0101cd8] <+80>: vmsr fpexc, r0 vmlinux.llvm.good [0xc0101d20 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47717", "url": "https://ubuntu.com/security/CVE-2024-47717", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RISC-V: KVM: Don't zero-out PMU snapshot area before freeing data With the latest Linux-6.11-rc3, the below NULL pointer crash is observed when SBI PMU snapshot is enabled for the guest and the guest is forcefully powered-off. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000508 Oops [#1] Modules linked in: kvm CPU: 0 UID: 0 PID: 61 Comm: term-poll Not tainted 6.11.0-rc3-00018-g44d7178dd77a #3 Hardware name: riscv-virtio,qemu (DT) epc : __kvm_write_guest_page+0x94/0xa6 [kvm] ra : __kvm_write_guest_page+0x54/0xa6 [kvm] epc : ffffffff01590e98 ra : ffffffff01590e58 sp : ffff8f80001f39b0 gp : ffffffff81512a60 tp : ffffaf80024872c0 t0 : ffffaf800247e000 t1 : 00000000000007e0 t2 : 0000000000000000 s0 : ffff8f80001f39f0 s1 : 00007fff89ac4000 a0 : ffffffff015dd7e8 a1 : 0000000000000086 a2 : 0000000000000000 a3 : ffffaf8000000000 a4 : ffffaf80024882c0 a5 : 0000000000000000 a6 : ffffaf800328d780 a7 : 00000000000001cc s2 : ffffaf800197bd00 s3 : 00000000000828c4 s4 : ffffaf800248c000 s5 : ffffaf800247d000 s6 : 0000000000001000 s7 : 0000000000001000 s8 : 0000000000000000 s9 : 00007fff861fd500 s10: 0000000000000001 s11: 0000000000800000 t3 : 00000000000004d3 t4 : 00000000000004d3 t5 : ffffffff814126e0 t6 : ffffffff81412700 status: 0000000200000120 badaddr: 0000000000000508 cause: 000000000000000d [] __kvm_write_guest_page+0x94/0xa6 [kvm] [] kvm_vcpu_write_guest+0x56/0x90 [kvm] [] kvm_pmu_clear_snapshot_area+0x42/0x7e [kvm] [] kvm_riscv_vcpu_pmu_deinit.part.0+0xe0/0x14e [kvm] [] kvm_riscv_vcpu_pmu_deinit+0x1a/0x24 [kvm] [] kvm_arch_vcpu_destroy+0x28/0x4c [kvm] [] kvm_destroy_vcpus+0x5a/0xda [kvm] [] kvm_arch_destroy_vm+0x14/0x28 [kvm] [] kvm_destroy_vm+0x168/0x2a0 [kvm] [] kvm_put_kvm+0x3c/0x58 [kvm] [] kvm_vm_release+0x22/0x2e [kvm] Clearly, the kvm_vcpu_write_guest() function is crashing because it is being called from kvm_pmu_clear_snapshot_area() upon guest tear down. To address the above issue, simplify the kvm_pmu_clear_snapshot_area() to not zero-out PMU snapshot area from kvm_pmu_clear_snapshot_area() because the guest is anyway being tore down. The kvm_pmu_clear_snapshot_area() is also called when guest changes PMU snapshot area of a VCPU but even in this case the previous PMU snaphsot area must not be zeroed-out because the guest might have reclaimed the pervious PMU snapshot area for some other purpose.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47721", "url": "https://ubuntu.com/security/CVE-2024-47721", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: remove unused C2H event ID RTW89_MAC_C2H_FUNC_READ_WOW_CAM to prevent out-of-bounds reading The handler of firmware C2H event RTW89_MAC_C2H_FUNC_READ_WOW_CAM isn't implemented, but driver expects number of handlers is NUM_OF_RTW89_MAC_C2H_FUNC_WOW causing out-of-bounds access. Fix it by removing ID. Addresses-Coverity-ID: 1598775 (\"Out-of-bounds read\")", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47732", "url": "https://ubuntu.com/security/CVE-2024-47732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: iaa - Fix potential use after free bug The free_device_compression_mode(iaa_device, device_mode) function frees \"device_mode\" but it iss passed to iaa_compression_modes[i]->free() a few lines later resulting in a use after free. The good news is that, so far as I can tell, nothing implements the ->free() function and the use after free happens in dead code. But, with this fix, when something does implement it, we'll be ready. :)", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47718", "url": "https://ubuntu.com/security/CVE-2024-47718", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: always wait for both firmware loading attempts In 'rtw_wait_firmware_completion()', always wait for both (regular and wowlan) firmware loading attempts. Otherwise if 'rtw_usb_intf_init()' has failed in 'rtw_usb_probe()', 'rtw_usb_disconnect()' may issue 'ieee80211_free_hw()' when one of 'rtw_load_firmware_cb()' (usually the wowlan one) is still in progress, causing UAF detected by KASAN.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47724", "url": "https://ubuntu.com/security/CVE-2024-47724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: use work queue to process beacon tx event Commit 3a415daa3e8b (\"wifi: ath11k: add P2P IE in beacon template\") from Feb 28, 2024 (linux-next), leads to the following Smatch static checker warning: drivers/net/wireless/ath/ath11k/wmi.c:1742 ath11k_wmi_p2p_go_bcn_ie() warn: sleeping in atomic context The reason is that ath11k_bcn_tx_status_event() will directly call might sleep function ath11k_wmi_cmd_send() during RCU read-side critical sections. The call trace is like: ath11k_bcn_tx_status_event() -> rcu_read_lock() -> ath11k_mac_bcn_tx_event() \t-> ath11k_mac_setup_bcn_tmpl() \t…… \t\t-> ath11k_wmi_bcn_tmpl() \t\t\t-> ath11k_wmi_cmd_send() -> rcu_read_unlock() Commit 886433a98425 (\"ath11k: add support for BSS color change\") added the ath11k_mac_bcn_tx_event(), commit 01e782c89108 (\"ath11k: fix warning of RCU usage for ath11k_mac_get_arvif_by_vdev_id()\") added the RCU lock to avoid warning but also introduced this BUG. Use work queue to avoid directly calling ath11k_mac_bcn_tx_event() during RCU critical sections. No need to worry about the deletion of vif because cancel_work_sync() will drop the work if it doesn't start or block vif deletion until the running work is done. 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": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47671", "url": "https://ubuntu.com/security/CVE-2024-47671", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: usbtmc: prevent kernel-usb-infoleak The syzbot reported a kernel-usb-infoleak in usbtmc_write, we need to clear the structure before filling fields.", "cve_priority": "medium", "cve_public_date": "2024-10-09 15:15:00 UTC" }, { "cve": "CVE-2024-46869", "url": "https://ubuntu.com/security/CVE-2024-46869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btintel_pcie: Allocate memory for driver private data Fix driver not allocating memory for struct btintel_data which is used to store internal data.", "cve_priority": "medium", "cve_public_date": "2024-09-30 16:15:00 UTC" }, { "cve": "CVE-2024-53164", "url": "https://ubuntu.com/security/CVE-2024-53164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: fix ordering of qlen adjustment Changes to sch->q.qlen around qdisc_tree_reduce_backlog() need to happen _before_ a call to said function because otherwise it may fail to notify parent qdiscs when the child is about to become empty.", "cve_priority": "medium", "cve_public_date": "2024-12-27 14:15:00 UTC" }, { "cve": "CVE-2024-53103", "url": "https://ubuntu.com/security/CVE-2024-53103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hv_sock: Initializing vsk->trans to NULL to prevent a dangling pointer When hvs is released, there is a possibility that vsk->trans may not be initialized to NULL, which could lead to a dangling pointer. This issue is resolved by initializing vsk->trans to NULL.", "cve_priority": "high", "cve_public_date": "2024-12-02 08:15:00 UTC" } ], "launchpad_bugs_fixed": [ 2093643, 1786013, 2091744, 2091184, 2093146, 2085406, 2089684, 2090932, 2085485, 2089357, 2089306, 2091655, 2091655, 2091655, 2091655, 2091655, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091386, 2091990, 2089327, 2089113, 2086587, 2086606, 2085950, 2085944, 2087853, 2087983, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089020, 2089020, 2089020 ], "changes": [ { "cves": [ { "cve": "CVE-2025-0927", "url": "https://ubuntu.com/security/CVE-2025-0927", "cve_description": "[fs: hfs/hfsplus: add key_len boundary check to hfs_bnode_read_key]", "cve_priority": "medium", "cve_public_date": "2025-02-13" } ], "log": [ "", " * CVE-2025-0927", " - SAUCE: fs: hfs/hfsplus: add key_len boundary check to hfs_bnode_read_key", "" ], "package": "linux", "version": "6.11.0-18.18", "urgency": "medium", "distributions": "oracular", "launchpad_bugs_fixed": [], "author": "Manuel Diewald ", "date": "Fri, 07 Feb 2025 18:44:32 +0100" }, { "cves": [ { "cve": "CVE-2024-53141", "url": "https://ubuntu.com/security/CVE-2024-53141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: add missing range check in bitmap_ip_uadt When tb[IPSET_ATTR_IP_TO] is not present but tb[IPSET_ATTR_CIDR] exists, the values of ip and ip_to are slightly swapped. Therefore, the range check for ip should be done later, but this part is missing and it seems that the vulnerability occurs. So we should add missing range checks and remove unnecessary range checks.", "cve_priority": "medium", "cve_public_date": "2024-12-06 10:15:00 UTC" }, { "cve": "CVE-2024-50010", "url": "https://ubuntu.com/security/CVE-2024-50010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exec: don't WARN for racy path_noexec check Both i_mode and noexec checks wrapped in WARN_ON stem from an artifact of the previous implementation. They used to legitimately check for the condition, but that got moved up in two commits: 633fb6ac3980 (\"exec: move S_ISREG() check earlier\") 0fd338b2d2cd (\"exec: move path_noexec() check earlier\") Instead of being removed said checks are WARN_ON'ed instead, which has some debug value. However, the spurious path_noexec check is racy, resulting in unwarranted warnings should someone race with setting the noexec flag. One can note there is more to perm-checking whether execve is allowed and none of the conditions are guaranteed to still hold after they were tested for. Additionally this does not validate whether the code path did any perm checking to begin with -- it will pass if the inode happens to be regular. Keep the redundant path_noexec() check even though it's mindless nonsense checking for guarantee that isn't given so drop the WARN. Reword the commentary and do small tidy ups while here. [brauner: keep redundant path_noexec() check]", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-53143", "url": "https://ubuntu.com/security/CVE-2024-53143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fsnotify: Fix ordering of iput() and watched_objects decrement Ensure the superblock is kept alive until we're done with iput(). Holding a reference to an inode is not allowed unless we ensure the superblock stays alive, which fsnotify does by keeping the watched_objects count elevated, so iput() must happen before the watched_objects decrement. This can lead to a UAF of something like sb->s_fs_info in tmpfs, but the UAF is hard to hit because race orderings that oops are more likely, thanks to the CHECK_DATA_CORRUPTION() block in generic_shutdown_super(). Also, ensure that fsnotify_put_sb_watched_objects() doesn't call fsnotify_sb_watched_objects() on a superblock that may have already been freed, which would cause a UAF read of sb->s_fsnotify_info.", "cve_priority": "medium", "cve_public_date": "2024-12-07 07:15:00 UTC" }, { "cve": "CVE-2024-53142", "url": "https://ubuntu.com/security/CVE-2024-53142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: initramfs: avoid filename buffer overrun The initramfs filename field is defined in Documentation/driver-api/early-userspace/buffer-format.rst as: 37 cpio_file := ALGN(4) + cpio_header + filename + \"\\0\" + ALGN(4) + data ... 55 ============= ================== ========================= 56 Field name Field size Meaning 57 ============= ================== ========================= ... 70 c_namesize 8 bytes Length of filename, including final \\0 When extracting an initramfs cpio archive, the kernel's do_name() path handler assumes a zero-terminated path at @collected, passing it directly to filp_open() / init_mkdir() / init_mknod(). If a specially crafted cpio entry carries a non-zero-terminated filename and is followed by uninitialized memory, then a file may be created with trailing characters that represent the uninitialized memory. The ability to create an initramfs entry would imply already having full control of the system, so the buffer overrun shouldn't be considered a security vulnerability. Append the output of the following bash script to an existing initramfs and observe any created /initramfs_test_fname_overrunAA* path. E.g. ./reproducer.sh | gzip >> /myinitramfs It's easiest to observe non-zero uninitialized memory when the output is gzipped, as it'll overflow the heap allocated @out_buf in __gunzip(), rather than the initrd_start+initrd_size block. ---- reproducer.sh ---- nilchar=\"A\"\t# change to \"\\0\" to properly zero terminate / pad magic=\"070701\" ino=1 mode=$(( 0100777 )) uid=0 gid=0 nlink=1 mtime=1 filesize=0 devmajor=0 devminor=1 rdevmajor=0 rdevminor=0 csum=0 fname=\"initramfs_test_fname_overrun\" namelen=$(( ${#fname} + 1 ))\t# plus one to account for terminator printf \"%s%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%s\" \\ \t$magic $ino $mode $uid $gid $nlink $mtime $filesize \\ \t$devmajor $devminor $rdevmajor $rdevminor $namelen $csum $fname termpadlen=$(( 1 + ((4 - ((110 + $namelen) & 3)) % 4) )) printf \"%.s${nilchar}\" $(seq 1 $termpadlen) ---- reproducer.sh ---- Symlink filename fields handled in do_symlink() won't overrun past the data segment, due to the explicit zero-termination of the symlink target. Fix filename buffer overrun by aborting the initramfs FSM if any cpio entry doesn't carry a zero-terminator at the expected (name_len - 1) offset.", "cve_priority": "medium", "cve_public_date": "2024-12-06 10:15:00 UTC" }, { "cve": "CVE-2024-53133", "url": "https://ubuntu.com/security/CVE-2024-53133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Handle dml allocation failure to avoid crash [Why] In the case where a dml allocation fails for any reason, the current state's dml contexts would no longer be valid. Then subsequent calls dc_state_copy_internal would shallow copy invalid memory and if the new state was released, a double free would occur. [How] Reset dml pointers in new_state to NULL and avoid invalid pointer (cherry picked from commit bcafdc61529a48f6f06355d78eb41b3aeda5296c)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53108", "url": "https://ubuntu.com/security/CVE-2024-53108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Adjust VSDB parser for replay feature At some point, the IEEE ID identification for the replay check in the AMD EDID was added. However, this check causes the following out-of-bounds issues when using KASAN: [ 27.804016] BUG: KASAN: slab-out-of-bounds in amdgpu_dm_update_freesync_caps+0xefa/0x17a0 [amdgpu] [ 27.804788] Read of size 1 at addr ffff8881647fdb00 by task systemd-udevd/383 ... [ 27.821207] Memory state around the buggy address: [ 27.821215] ffff8881647fda00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821224] ffff8881647fda80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821234] >ffff8881647fdb00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821243] ^ [ 27.821250] ffff8881647fdb80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821259] ffff8881647fdc00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821268] ================================================================== This is caused because the ID extraction happens outside of the range of the edid lenght. This commit addresses this issue by considering the amd_vsdb_block size. (cherry picked from commit b7e381b1ccd5e778e3d9c44c669ad38439a861d8)", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53134", "url": "https://ubuntu.com/security/CVE-2024-53134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pmdomain: imx93-blk-ctrl: correct remove path The check condition should be 'i < bc->onecell_data.num_domains', not 'bc->onecell_data.num_domains' which will make the look never finish and cause kernel panic. Also disable runtime to address \"imx93-blk-ctrl 4ac10000.system-controller: Unbalanced pm_runtime_enable!\"", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53132", "url": "https://ubuntu.com/security/CVE-2024-53132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/oa: Fix \"Missing outer runtime PM protection\" warning Fix the following drm_WARN: [953.586396] xe 0000:00:02.0: [drm] Missing outer runtime PM protection ... <4> [953.587090] ? xe_pm_runtime_get_noresume+0x8d/0xa0 [xe] <4> [953.587208] guc_exec_queue_add_msg+0x28/0x130 [xe] <4> [953.587319] guc_exec_queue_fini+0x3a/0x40 [xe] <4> [953.587425] xe_exec_queue_destroy+0xb3/0xf0 [xe] <4> [953.587515] xe_oa_release+0x9c/0xc0 [xe] (cherry picked from commit b107c63d2953907908fd0cafb0e543b3c3167b75)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53127", "url": "https://ubuntu.com/security/CVE-2024-53127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Revert \"mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K\" The commit 8396c793ffdf (\"mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K\") increased the max_req_size, even for 4K pages, causing various issues: - Panic booting the kernel/rootfs from an SD card on Rockchip RK3566 - Panic booting the kernel/rootfs from an SD card on StarFive JH7100 - \"swiotlb buffer is full\" and data corruption on StarFive JH7110 At this stage no fix have been found, so it's probably better to just revert the change. This reverts commit 8396c793ffdf28bb8aee7cfe0891080f8cab7890.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53130", "url": "https://ubuntu.com/security/CVE-2024-53130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint When using the \"block:block_dirty_buffer\" tracepoint, mark_buffer_dirty() may cause a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because, since the tracepoint was added in mark_buffer_dirty(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, nilfs_grab_buffer(), which grabs a buffer to read (or create) a block of metadata, including b-tree node blocks, does not set the block device, but instead does so only if the buffer is not in the \"uptodate\" state for each of its caller block reading functions. However, if the uptodate flag is set on a folio/page, and the buffer heads are detached from it by try_to_free_buffers(), and new buffer heads are then attached by create_empty_buffers(), the uptodate flag may be restored to each buffer without the block device being set to bh->b_bdev, and mark_buffer_dirty() may be called later in that state, resulting in the bug mentioned above. Fix this issue by making nilfs_grab_buffer() always set the block device of the super block structure to the buffer head, regardless of the state of the buffer's uptodate flag.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53105", "url": "https://ubuntu.com/security/CVE-2024-53105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: page_alloc: move mlocked flag clearance into free_pages_prepare() Syzbot reported a bad page state problem caused by a page being freed using free_page() still having a mlocked flag at free_pages_prepare() stage: BUG: Bad page state in process syz.5.504 pfn:61f45 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x61f45 flags: 0xfff00000080204(referenced|workingset|mlocked|node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000080204 0000000000000000 dead000000000122 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set page_owner tracks the page as allocated page last allocated via order 0, migratetype Unmovable, gfp_mask 0x400dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO), pid 8443, tgid 8442 (syz.5.504), ts 201884660643, free_ts 201499827394 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1537 prep_new_page mm/page_alloc.c:1545 [inline] get_page_from_freelist+0x303f/0x3190 mm/page_alloc.c:3457 __alloc_pages_noprof+0x292/0x710 mm/page_alloc.c:4733 alloc_pages_mpol_noprof+0x3e8/0x680 mm/mempolicy.c:2265 kvm_coalesced_mmio_init+0x1f/0xf0 virt/kvm/coalesced_mmio.c:99 kvm_create_vm virt/kvm/kvm_main.c:1235 [inline] kvm_dev_ioctl_create_vm virt/kvm/kvm_main.c:5488 [inline] kvm_dev_ioctl+0x12dc/0x2240 virt/kvm/kvm_main.c:5530 __do_compat_sys_ioctl fs/ioctl.c:1007 [inline] __se_compat_sys_ioctl+0x510/0xc90 fs/ioctl.c:950 do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline] __do_fast_syscall_32+0xb4/0x110 arch/x86/entry/common.c:386 do_fast_syscall_32+0x34/0x80 arch/x86/entry/common.c:411 entry_SYSENTER_compat_after_hwframe+0x84/0x8e page last free pid 8399 tgid 8399 stack trace: reset_page_owner include/linux/page_owner.h:25 [inline] free_pages_prepare mm/page_alloc.c:1108 [inline] free_unref_folios+0xf12/0x18d0 mm/page_alloc.c:2686 folios_put_refs+0x76c/0x860 mm/swap.c:1007 free_pages_and_swap_cache+0x5c8/0x690 mm/swap_state.c:335 __tlb_batch_free_encoded_pages mm/mmu_gather.c:136 [inline] tlb_batch_pages_flush mm/mmu_gather.c:149 [inline] tlb_flush_mmu_free mm/mmu_gather.c:366 [inline] tlb_flush_mmu+0x3a3/0x680 mm/mmu_gather.c:373 tlb_finish_mmu+0xd4/0x200 mm/mmu_gather.c:465 exit_mmap+0x496/0xc40 mm/mmap.c:1926 __mmput+0x115/0x390 kernel/fork.c:1348 exit_mm+0x220/0x310 kernel/exit.c:571 do_exit+0x9b2/0x28e0 kernel/exit.c:926 do_group_exit+0x207/0x2c0 kernel/exit.c:1088 __do_sys_exit_group kernel/exit.c:1099 [inline] __se_sys_exit_group kernel/exit.c:1097 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1097 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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 Modules linked in: CPU: 0 UID: 0 PID: 8442 Comm: syz.5.504 Not tainted 6.12.0-rc6-syzkaller #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 bad_page+0x176/0x1d0 mm/page_alloc.c:501 free_page_is_bad mm/page_alloc.c:918 [inline] free_pages_prepare mm/page_alloc.c:1100 [inline] free_unref_page+0xed0/0xf20 mm/page_alloc.c:2638 kvm_destroy_vm virt/kvm/kvm_main.c:1327 [inline] kvm_put_kvm+0xc75/0x1350 virt/kvm/kvm_main.c:1386 kvm_vcpu_release+0x54/0x60 virt/kvm/kvm_main.c:4143 __fput+0x23f/0x880 fs/file_table.c:431 task_work_run+0x24f/0x310 kernel/task_work.c:239 exit_task_work include/linux/task_work.h:43 [inline] do_exit+0xa2f/0x28e0 kernel/exit.c:939 do_group_exit+0x207/0x2c0 kernel/exit.c:1088 __do_sys_exit_group kernel/exit.c:1099 [in ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53109", "url": "https://ubuntu.com/security/CVE-2024-53109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nommu: pass NULL argument to vma_iter_prealloc() When deleting a vma entry from a maple tree, it has to pass NULL to vma_iter_prealloc() in order to calculate internal state of the tree, but it passed a wrong argument. As a result, nommu kernels crashed upon accessing a vma iterator, such as acct_collect() reading the size of vma entries after do_munmap(). This commit fixes this issue by passing a right argument to the preallocation call.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53131", "url": "https://ubuntu.com/security/CVE-2024-53131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint Patch series \"nilfs2: fix null-ptr-deref bugs on block tracepoints\". This series fixes null pointer dereference bugs that occur when using nilfs2 and two block-related tracepoints. This patch (of 2): It has been reported that when using \"block:block_touch_buffer\" tracepoint, touch_buffer() called from __nilfs_get_folio_block() causes a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because since the tracepoint was added in touch_buffer(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, the block_device structure is set after the function returns to the caller. Here, touch_buffer() is used to mark the folio/page that owns the buffer head as accessed, but the common search helper for folio/page used by the caller function was optimized to mark the folio/page as accessed when it was reimplemented a long time ago, eliminating the need to call touch_buffer() here in the first place. So this solves the issue by eliminating the touch_buffer() call itself.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53135", "url": "https://ubuntu.com/security/CVE-2024-53135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: VMX: Bury Intel PT virtualization (guest/host mode) behind CONFIG_BROKEN Hide KVM's pt_mode module param behind CONFIG_BROKEN, i.e. disable support for virtualizing Intel PT via guest/host mode unless BROKEN=y. There are myriad bugs in the implementation, some of which are fatal to the guest, and others which put the stability and health of the host at risk. For guest fatalities, the most glaring issue is that KVM fails to ensure tracing is disabled, and *stays* disabled prior to VM-Enter, which is necessary as hardware disallows loading (the guest's) RTIT_CTL if tracing is enabled (enforced via a VMX consistency check). Per the SDM: If the logical processor is operating with Intel PT enabled (if IA32_RTIT_CTL.TraceEn = 1) at the time of VM entry, the \"load IA32_RTIT_CTL\" VM-entry control must be 0. On the host side, KVM doesn't validate the guest CPUID configuration provided by userspace, and even worse, uses the guest configuration to decide what MSRs to save/load at VM-Enter and VM-Exit. E.g. configuring guest CPUID to enumerate more address ranges than are supported in hardware will result in KVM trying to passthrough, save, and load non-existent MSRs, which generates a variety of WARNs, ToPA ERRORs in the host, a potential deadlock, etc.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53106", "url": "https://ubuntu.com/security/CVE-2024-53106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: fix buffer overrun in ima_eventdigest_init_common Function ima_eventdigest_init() calls ima_eventdigest_init_common() with HASH_ALGO__LAST which is then used to access the array hash_digest_size[] leading to buffer overrun. Have a conditional statement to handle this.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53110", "url": "https://ubuntu.com/security/CVE-2024-53110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vp_vdpa: fix id_table array not null terminated error Allocate one extra virtio_device_id as null terminator, otherwise vdpa_mgmtdev_get_classes() may iterate multiple times and visit undefined memory.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53126", "url": "https://ubuntu.com/security/CVE-2024-53126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa: solidrun: Fix UB bug with devres In psnet_open_pf_bar() and snet_open_vf_bar() a string later passed to pcim_iomap_regions() is placed on the stack. Neither pcim_iomap_regions() nor the functions it calls copy that string. Should the string later ever be used, this, consequently, causes undefined behavior since the stack frame will by then have disappeared. Fix the bug by allocating the strings on the heap through devm_kasprintf().", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53111", "url": "https://ubuntu.com/security/CVE-2024-53111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mremap: fix address wraparound in move_page_tables() On 32-bit platforms, it is possible for the expression `len + old_addr < old_end` to be false-positive if `len + old_addr` wraps around. `old_addr` is the cursor in the old range up to which page table entries have been moved; so if the operation succeeded, `old_addr` is the *end* of the old region, and adding `len` to it can wrap. The overflow causes mremap() to mistakenly believe that PTEs have been copied; the consequence is that mremap() bails out, but doesn't move the PTEs back before the new VMA is unmapped, causing anonymous pages in the region to be lost. So basically if userspace tries to mremap() a private-anon region and hits this bug, mremap() will return an error and the private-anon region's contents appear to have been zeroed. The idea of this check is that `old_end - len` is the original start address, and writing the check that way also makes it easier to read; so fix the check by rearranging the comparison accordingly. (An alternate fix would be to refactor this function by introducing an \"orig_old_start\" variable or such.) Tested in a VM with a 32-bit X86 kernel; without the patch: ``` user@horn:~/big_mremap$ cat test.c #define _GNU_SOURCE #include #include #include #include #define ADDR1 ((void*)0x60000000) #define ADDR2 ((void*)0x10000000) #define SIZE 0x50000000uL int main(void) { unsigned char *p1 = mmap(ADDR1, SIZE, PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0); if (p1 == MAP_FAILED) err(1, \"mmap 1\"); unsigned char *p2 = mmap(ADDR2, SIZE, PROT_NONE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0); if (p2 == MAP_FAILED) err(1, \"mmap 2\"); *p1 = 0x41; printf(\"first char is 0x%02hhx\\n\", *p1); unsigned char *p3 = mremap(p1, SIZE, SIZE, MREMAP_MAYMOVE|MREMAP_FIXED, p2); if (p3 == MAP_FAILED) { printf(\"mremap() failed; first char is 0x%02hhx\\n\", *p1); } else { printf(\"mremap() succeeded; first char is 0x%02hhx\\n\", *p3); } } user@horn:~/big_mremap$ gcc -static -o test test.c user@horn:~/big_mremap$ setarch -R ./test first char is 0x41 mremap() failed; first char is 0x00 ``` With the patch: ``` user@horn:~/big_mremap$ setarch -R ./test first char is 0x41 mremap() succeeded; first char is 0x41 ```", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53107", "url": "https://ubuntu.com/security/CVE-2024-53107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: prevent integer overflow in pagemap_scan_get_args() The \"arg->vec_len\" variable is a u64 that comes from the user at the start of the function. The \"arg->vec_len * sizeof(struct page_region))\" multiplication can lead to integer wrapping. Use size_mul() to avoid that. Also the size_add/mul() functions work on unsigned long so for 32bit systems we need to ensure that \"arg->vec_len\" fits in an unsigned long.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53128", "url": "https://ubuntu.com/security/CVE-2024-53128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/task_stack: fix object_is_on_stack() for KASAN tagged pointers When CONFIG_KASAN_SW_TAGS and CONFIG_KASAN_STACK are enabled, the object_is_on_stack() function may produce incorrect results due to the presence of tags in the obj pointer, while the stack pointer does not have tags. This discrepancy can lead to incorrect stack object detection and subsequently trigger warnings if CONFIG_DEBUG_OBJECTS is also enabled. Example of the warning: ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at lib/debugobjects.c:557 __debug_object_init+0x330/0x364 Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5 #4 Hardware name: linux,dummy-virt (DT) pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __debug_object_init+0x330/0x364 lr : __debug_object_init+0x330/0x364 sp : ffff800082ea7b40 x29: ffff800082ea7b40 x28: 98ff0000c0164518 x27: 98ff0000c0164534 x26: ffff800082d93ec8 x25: 0000000000000001 x24: 1cff0000c00172a0 x23: 0000000000000000 x22: ffff800082d93ed0 x21: ffff800081a24418 x20: 3eff800082ea7bb0 x19: efff800000000000 x18: 0000000000000000 x17: 00000000000000ff x16: 0000000000000047 x15: 206b63617473206e x14: 0000000000000018 x13: ffff800082ea7780 x12: 0ffff800082ea78e x11: 0ffff800082ea790 x10: 0ffff800082ea79d x9 : 34d77febe173e800 x8 : 34d77febe173e800 x7 : 0000000000000001 x6 : 0000000000000001 x5 : feff800082ea74b8 x4 : ffff800082870a90 x3 : ffff80008018d3c4 x2 : 0000000000000001 x1 : ffff800082858810 x0 : 0000000000000050 Call trace: __debug_object_init+0x330/0x364 debug_object_init_on_stack+0x30/0x3c schedule_hrtimeout_range_clock+0xac/0x26c schedule_hrtimeout+0x1c/0x30 wait_task_inactive+0x1d4/0x25c kthread_bind_mask+0x28/0x98 init_rescuer+0x1e8/0x280 workqueue_init+0x1a0/0x3cc kernel_init_freeable+0x118/0x200 kernel_init+0x28/0x1f0 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53112", "url": "https://ubuntu.com/security/CVE-2024-53112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: uncache inode which has failed entering the group Syzbot has reported the following BUG: kernel BUG at fs/ocfs2/uptodate.c:509! ... Call Trace: ? __die_body+0x5f/0xb0 ? die+0x9e/0xc0 ? do_trap+0x15a/0x3a0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? do_error_trap+0x1dc/0x2c0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? __pfx_do_error_trap+0x10/0x10 ? handle_invalid_op+0x34/0x40 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? exc_invalid_op+0x38/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? ocfs2_set_new_buffer_uptodate+0x2e/0x160 ? ocfs2_set_new_buffer_uptodate+0x144/0x160 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ocfs2_group_add+0x39f/0x15a0 ? __pfx_ocfs2_group_add+0x10/0x10 ? __pfx_lock_acquire+0x10/0x10 ? mnt_get_write_access+0x68/0x2b0 ? __pfx_lock_release+0x10/0x10 ? rcu_read_lock_any_held+0xb7/0x160 ? __pfx_rcu_read_lock_any_held+0x10/0x10 ? smack_log+0x123/0x540 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x226/0x2b0 ocfs2_ioctl+0x65e/0x7d0 ? __pfx_ocfs2_ioctl+0x10/0x10 ? smack_file_ioctl+0x29e/0x3a0 ? __pfx_smack_file_ioctl+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x43d/0x780 ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10 ? __pfx_ocfs2_ioctl+0x10/0x10 __se_sys_ioctl+0xfb/0x170 do_syscall_64+0xf3/0x230 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... When 'ioctl(OCFS2_IOC_GROUP_ADD, ...)' has failed for the particular inode in 'ocfs2_verify_group_and_input()', corresponding buffer head remains cached and subsequent call to the same 'ioctl()' for the same inode issues the BUG() in 'ocfs2_set_new_buffer_uptodate()' (trying to cache the same buffer head of that inode). Fix this by uncaching the buffer head with 'ocfs2_remove_from_cache()' on error path in 'ocfs2_group_add()'.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53113", "url": "https://ubuntu.com/security/CVE-2024-53113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: fix NULL pointer dereference in alloc_pages_bulk_noprof We triggered a NULL pointer dereference for ac.preferred_zoneref->zone in alloc_pages_bulk_noprof() when the task is migrated between cpusets. When cpuset is enabled, in prepare_alloc_pages(), ac->nodemask may be ¤t->mems_allowed. when first_zones_zonelist() is called to find preferred_zoneref, the ac->nodemask may be modified concurrently if the task is migrated between different cpusets. Assuming we have 2 NUMA Node, when traversing Node1 in ac->zonelist, the nodemask is 2, and when traversing Node2 in ac->zonelist, the nodemask is 1. As a result, the ac->preferred_zoneref points to NULL zone. In alloc_pages_bulk_noprof(), for_each_zone_zonelist_nodemask() finds a allowable zone and calls zonelist_node_idx(ac.preferred_zoneref), leading to NULL pointer dereference. __alloc_pages_noprof() fixes this issue by checking NULL pointer in commit ea57485af8f4 (\"mm, page_alloc: fix check for NULL preferred_zone\") and commit df76cee6bbeb (\"mm, page_alloc: remove redundant checks from alloc fastpath\"). To fix it, check NULL pointer for preferred_zoneref->zone.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53114", "url": "https://ubuntu.com/security/CVE-2024-53114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 client A number of Zen4 client SoCs advertise the ability to use virtualized VMLOAD/VMSAVE, but using these instructions is reported to be a cause of a random host reboot. These instructions aren't intended to be advertised on Zen4 client so clear the capability.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53137", "url": "https://ubuntu.com/security/CVE-2024-53137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: fix cacheflush with PAN It seems that the cacheflush syscall got broken when PAN for LPAE was implemented. User access was not enabled around the cache maintenance instructions, causing them to fault.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53115", "url": "https://ubuntu.com/security/CVE-2024-53115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: avoid null_ptr_deref in vmw_framebuffer_surface_create_handle The 'vmw_user_object_buffer' function may return NULL with incorrect inputs. To avoid possible null pointer dereference, add a check whether the 'bo' is NULL in the vmw_framebuffer_surface_create_handle.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53116", "url": "https://ubuntu.com/security/CVE-2024-53116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix handling of partial GPU mapping of BOs This commit fixes the bug in the handling of partial mapping of the buffer objects to the GPU, which caused kernel warnings. Panthor didn't correctly handle the case where the partial mapping spanned multiple scatterlists and the mapping offset didn't point to the 1st page of starting scatterlist. The offset variable was not cleared after reaching the starting scatterlist. Following warning messages were seen. WARNING: CPU: 1 PID: 650 at drivers/iommu/io-pgtable-arm.c:659 __arm_lpae_unmap+0x254/0x5a0 pc : __arm_lpae_unmap+0x254/0x5a0 lr : __arm_lpae_unmap+0x2cc/0x5a0 Call trace: __arm_lpae_unmap+0x254/0x5a0 __arm_lpae_unmap+0x108/0x5a0 __arm_lpae_unmap+0x108/0x5a0 __arm_lpae_unmap+0x108/0x5a0 arm_lpae_unmap_pages+0x80/0xa0 panthor_vm_unmap_pages+0xac/0x1c8 [panthor] panthor_gpuva_sm_step_unmap+0x4c/0xc8 [panthor] op_unmap_cb.isra.23.constprop.30+0x54/0x80 __drm_gpuvm_sm_unmap+0x184/0x1c8 drm_gpuvm_sm_unmap+0x40/0x60 panthor_vm_exec_op+0xa8/0x120 [panthor] panthor_vm_bind_exec_sync_op+0xc4/0xe8 [panthor] panthor_ioctl_vm_bind+0x10c/0x170 [panthor] drm_ioctl_kernel+0xbc/0x138 drm_ioctl+0x210/0x4b0 __arm64_sys_ioctl+0xb0/0xf8 invoke_syscall+0x4c/0x110 el0_svc_common.constprop.1+0x98/0xf8 do_el0_svc+0x24/0x38 el0_svc+0x34/0xc8 el0t_64_sync_handler+0xa0/0xc8 el0t_64_sync+0x174/0x178 panthor : [drm] drm_WARN_ON(unmapped_sz != pgsize * pgcount) WARNING: CPU: 1 PID: 650 at drivers/gpu/drm/panthor/panthor_mmu.c:922 panthor_vm_unmap_pages+0x124/0x1c8 [panthor] pc : panthor_vm_unmap_pages+0x124/0x1c8 [panthor] lr : panthor_vm_unmap_pages+0x124/0x1c8 [panthor] panthor : [drm] *ERROR* failed to unmap range ffffa388f000-ffffa3890000 (requested range ffffa388c000-ffffa3890000)", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53117", "url": "https://ubuntu.com/security/CVE-2024-53117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio/vsock: Improve MSG_ZEROCOPY error handling Add a missing kfree_skb() to prevent memory leaks.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53118", "url": "https://ubuntu.com/security/CVE-2024-53118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Fix sk_error_queue memory leak Kernel queues MSG_ZEROCOPY completion notifications on the error queue. Where they remain, until explicitly recv()ed. To prevent memory leaks, clean up the queue when the socket is destroyed. unreferenced object 0xffff8881028beb00 (size 224): comm \"vsock_test\", pid 1218, jiffies 4294694897 hex dump (first 32 bytes): 90 b0 21 17 81 88 ff ff 90 b0 21 17 81 88 ff ff ..!.......!..... 00 00 00 00 00 00 00 00 00 b0 21 17 81 88 ff ff ..........!..... backtrace (crc 6c7031ca): [] kmem_cache_alloc_node_noprof+0x2f7/0x370 [] __alloc_skb+0x132/0x180 [] sock_omalloc+0x4b/0x80 [] msg_zerocopy_realloc+0x9e/0x240 [] virtio_transport_send_pkt_info+0x412/0x4c0 [] virtio_transport_stream_enqueue+0x43/0x50 [] vsock_connectible_sendmsg+0x373/0x450 [] ____sys_sendmsg+0x365/0x3a0 [] ___sys_sendmsg+0x84/0xd0 [] __sys_sendmsg+0x47/0x80 [] do_syscall_64+0x93/0x180 [] entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53119", "url": "https://ubuntu.com/security/CVE-2024-53119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio/vsock: Fix accept_queue memory leak As the final stages of socket destruction may be delayed, it is possible that virtio_transport_recv_listen() will be called after the accept_queue has been flushed, but before the SOCK_DONE flag has been set. As a result, sockets enqueued after the flush would remain unremoved, leading to a memory leak. vsock_release __vsock_release lock virtio_transport_release virtio_transport_close schedule_delayed_work(close_work) sk_shutdown = SHUTDOWN_MASK (!) flush accept_queue release virtio_transport_recv_pkt vsock_find_bound_socket lock if flag(SOCK_DONE) return virtio_transport_recv_listen child = vsock_create_connected (!) vsock_enqueue_accept(child) release close_work lock virtio_transport_do_close set_flag(SOCK_DONE) virtio_transport_remove_sock vsock_remove_sock vsock_remove_bound release Introduce a sk_shutdown check to disallow vsock_enqueue_accept() during socket destruction. unreferenced object 0xffff888109e3f800 (size 2040): comm \"kworker/5:2\", pid 371, jiffies 4294940105 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00 (..@............ backtrace (crc 9e5f4e84): [] kmem_cache_alloc_noprof+0x2c1/0x360 [] sk_prot_alloc+0x30/0x120 [] sk_alloc+0x2c/0x4b0 [] __vsock_create.constprop.0+0x2a/0x310 [] virtio_transport_recv_pkt+0x4dc/0x9a0 [] vsock_loopback_work+0xfd/0x140 [] process_one_work+0x20c/0x570 [] worker_thread+0x1bf/0x3a0 [] kthread+0xdd/0x110 [] ret_from_fork+0x2d/0x50 [] ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53120", "url": "https://ubuntu.com/security/CVE-2024-53120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: CT: Fix null-ptr-deref in add rule err flow In error flow of mlx5_tc_ct_entry_add_rule(), in case ct_rule_add() callback returns error, zone_rule->attr is used uninitiated. Fix it to use attr which has the needed pointer value. Kernel log: BUG: kernel NULL pointer dereference, address: 0000000000000110 RIP: 0010:mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core] … Call Trace: ? __die+0x20/0x70 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x140 ? asm_exc_page_fault+0x22/0x30 ? mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core] ? mlx5_tc_ct_entry_add_rule+0x1d5/0x2f0 [mlx5_core] mlx5_tc_ct_block_flow_offload+0xc6a/0xf90 [mlx5_core] ? nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] flow_offload_work_handler+0x142/0x320 [nf_flow_table] ? finish_task_switch.isra.0+0x15b/0x2b0 process_one_work+0x16c/0x320 worker_thread+0x28c/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xb8/0xf0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53138", "url": "https://ubuntu.com/security/CVE-2024-53138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: kTLS, Fix incorrect page refcounting The kTLS tx handling code is using a mix of get_page() and page_ref_inc() APIs to increment the page reference. But on the release path (mlx5e_ktls_tx_handle_resync_dump_comp()), only put_page() is used. This is an issue when using pages from large folios: the get_page() references are stored on the folio page while the page_ref_inc() references are stored directly in the given page. On release the folio page will be dereferenced too many times. This was found while doing kTLS testing with sendfile() + ZC when the served file was read from NFS on a kernel with NFS large folios support (commit 49b29a573da8 (\"nfs: add support for large folios\")).", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53121", "url": "https://ubuntu.com/security/CVE-2024-53121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: fs, lock FTE when checking if active The referenced commits introduced a two-step process for deleting FTEs: - Lock the FTE, delete it from hardware, set the hardware deletion function to NULL and unlock the FTE. - Lock the parent flow group, delete the software copy of the FTE, and remove it from the xarray. However, this approach encounters a race condition if a rule with the same match value is added simultaneously. In this scenario, fs_core may set the hardware deletion function to NULL prematurely, causing a panic during subsequent rule deletions. To prevent this, ensure the active flag of the FTE is checked under a lock, which will prevent the fs_core layer from attaching a new steering rule to an FTE that is in the process of deletion. [ 438.967589] MOSHE: 2496 mlx5_del_flow_rules del_hw_func [ 438.968205] ------------[ cut here ]------------ [ 438.968654] refcount_t: decrement hit 0; leaking memory. [ 438.969249] WARNING: CPU: 0 PID: 8957 at lib/refcount.c:31 refcount_warn_saturate+0xfb/0x110 [ 438.970054] Modules linked in: act_mirred cls_flower act_gact sch_ingress openvswitch nsh mlx5_vdpa vringh vhost_iotlb vdpa mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core zram zsmalloc fuse [last unloaded: cls_flower] [ 438.973288] CPU: 0 UID: 0 PID: 8957 Comm: tc Not tainted 6.12.0-rc1+ #8 [ 438.973888] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 438.974874] RIP: 0010:refcount_warn_saturate+0xfb/0x110 [ 438.975363] Code: 40 66 3b 82 c6 05 16 e9 4d 01 01 e8 1f 7c a0 ff 0f 0b c3 cc cc cc cc 48 c7 c7 10 66 3b 82 c6 05 fd e8 4d 01 01 e8 05 7c a0 ff <0f> 0b c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 90 [ 438.976947] RSP: 0018:ffff888124a53610 EFLAGS: 00010286 [ 438.977446] RAX: 0000000000000000 RBX: ffff888119d56de0 RCX: 0000000000000000 [ 438.978090] RDX: ffff88852c828700 RSI: ffff88852c81b3c0 RDI: ffff88852c81b3c0 [ 438.978721] RBP: ffff888120fa0e88 R08: 0000000000000000 R09: ffff888124a534b0 [ 438.979353] R10: 0000000000000001 R11: 0000000000000001 R12: ffff888119d56de0 [ 438.979979] R13: ffff888120fa0ec0 R14: ffff888120fa0ee8 R15: ffff888119d56de0 [ 438.980607] FS: 00007fe6dcc0f800(0000) GS:ffff88852c800000(0000) knlGS:0000000000000000 [ 438.983984] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 438.984544] CR2: 00000000004275e0 CR3: 0000000186982001 CR4: 0000000000372eb0 [ 438.985205] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 438.985842] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 438.986507] Call Trace: [ 438.986799] [ 438.987070] ? __warn+0x7d/0x110 [ 438.987426] ? refcount_warn_saturate+0xfb/0x110 [ 438.987877] ? report_bug+0x17d/0x190 [ 438.988261] ? prb_read_valid+0x17/0x20 [ 438.988659] ? handle_bug+0x53/0x90 [ 438.989054] ? exc_invalid_op+0x14/0x70 [ 438.989458] ? asm_exc_invalid_op+0x16/0x20 [ 438.989883] ? refcount_warn_saturate+0xfb/0x110 [ 438.990348] mlx5_del_flow_rules+0x2f7/0x340 [mlx5_core] [ 438.990932] __mlx5_eswitch_del_rule+0x49/0x170 [mlx5_core] [ 438.991519] ? mlx5_lag_is_sriov+0x3c/0x50 [mlx5_core] [ 438.992054] ? xas_load+0x9/0xb0 [ 438.992407] mlx5e_tc_rule_unoffload+0x45/0xe0 [mlx5_core] [ 438.993037] mlx5e_tc_del_fdb_flow+0x2a6/0x2e0 [mlx5_core] [ 438.993623] mlx5e_flow_put+0x29/0x60 [mlx5_core] [ 438.994161] mlx5e_delete_flower+0x261/0x390 [mlx5_core] [ 438.994728] tc_setup_cb_destroy+0xb9/0x190 [ 438.995150] fl_hw_destroy_filter+0x94/0xc0 [cls_flower] [ 438.995650] fl_change+0x11a4/0x13c0 [cls_flower] [ 438.996105] tc_new_tfilter+0x347/0xbc0 [ 438.996503] ? __ ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53122", "url": "https://ubuntu.com/security/CVE-2024-53122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: cope racing subflow creation in mptcp_rcv_space_adjust Additional active subflows - i.e. created by the in kernel path manager - are included into the subflow list before starting the 3whs. A racing recvmsg() spooling data received on an already established subflow would unconditionally call tcp_cleanup_rbuf() on all the current subflows, potentially hitting a divide by zero error on the newly created ones. Explicitly check that the subflow is in a suitable state before invoking tcp_cleanup_rbuf().", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53123", "url": "https://ubuntu.com/security/CVE-2024-53123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: error out earlier on disconnect Eric reported a division by zero splat in the MPTCP protocol: Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 6094 Comm: syz-executor317 Not tainted 6.12.0-rc5-syzkaller-00291-g05b92660cdfe #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:__tcp_select_window+0x5b4/0x1310 net/ipv4/tcp_output.c:3163 Code: f6 44 01 e3 89 df e8 9b 75 09 f8 44 39 f3 0f 8d 11 ff ff ff e8 0d 74 09 f8 45 89 f4 e9 04 ff ff ff e8 00 74 09 f8 44 89 f0 99 7c 24 14 41 29 d6 45 89 f4 e9 ec fe ff ff e8 e8 73 09 f8 48 89 RSP: 0018:ffffc900041f7930 EFLAGS: 00010293 RAX: 0000000000017e67 RBX: 0000000000017e67 RCX: ffffffff8983314b RDX: 0000000000000000 RSI: ffffffff898331b0 RDI: 0000000000000004 RBP: 00000000005d6000 R08: 0000000000000004 R09: 0000000000017e67 R10: 0000000000003e80 R11: 0000000000000000 R12: 0000000000003e80 R13: ffff888031d9b440 R14: 0000000000017e67 R15: 00000000002eb000 FS: 00007feb5d7f16c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007feb5d8adbb8 CR3: 0000000074e4c000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __tcp_cleanup_rbuf+0x3e7/0x4b0 net/ipv4/tcp.c:1493 mptcp_rcv_space_adjust net/mptcp/protocol.c:2085 [inline] mptcp_recvmsg+0x2156/0x2600 net/mptcp/protocol.c:2289 inet_recvmsg+0x469/0x6a0 net/ipv4/af_inet.c:885 sock_recvmsg_nosec net/socket.c:1051 [inline] sock_recvmsg+0x1b2/0x250 net/socket.c:1073 __sys_recvfrom+0x1a5/0x2e0 net/socket.c:2265 __do_sys_recvfrom net/socket.c:2283 [inline] __se_sys_recvfrom net/socket.c:2279 [inline] __x64_sys_recvfrom+0xe0/0x1c0 net/socket.c:2279 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 RIP: 0033:0x7feb5d857559 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:00007feb5d7f1208 EFLAGS: 00000246 ORIG_RAX: 000000000000002d RAX: ffffffffffffffda RBX: 00007feb5d8e1318 RCX: 00007feb5d857559 RDX: 000000800000000e RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007feb5d8e1310 R08: 0000000000000000 R09: ffffffff81000000 R10: 0000000000000100 R11: 0000000000000246 R12: 00007feb5d8e131c R13: 00007feb5d8ae074 R14: 000000800000000e R15: 00000000fffffdef and provided a nice reproducer. The root cause is the current bad handling of racing disconnect. After the blamed commit below, sk_wait_data() can return (with error) with the underlying socket disconnected and a zero rcv_mss. Catch the error and return without performing any additional operations on the current socket.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53124", "url": "https://ubuntu.com/security/CVE-2024-53124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix data-races around sk->sk_forward_alloc Syzkaller reported this warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 16 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x1c5/0x1e0 Modules linked in: CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:inet_sock_destruct+0x1c5/0x1e0 Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 <0f> 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00 RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206 RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007 RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00 RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007 R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00 R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78 FS: 0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn+0x88/0x130 ? inet_sock_destruct+0x1c5/0x1e0 ? report_bug+0x18e/0x1a0 ? handle_bug+0x53/0x90 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? inet_sock_destruct+0x1c5/0x1e0 __sk_destruct+0x2a/0x200 rcu_do_batch+0x1aa/0x530 ? rcu_do_batch+0x13b/0x530 rcu_core+0x159/0x2f0 handle_softirqs+0xd3/0x2b0 ? __pfx_smpboot_thread_fn+0x10/0x10 run_ksoftirqd+0x25/0x30 smpboot_thread_fn+0xdd/0x1d0 kthread+0xd3/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ---[ end trace 0000000000000000 ]--- Its possible that two threads call tcp_v6_do_rcv()/sk_forward_alloc_add() concurrently when sk->sk_state == TCP_LISTEN with sk->sk_lock unlocked, which triggers a data-race around sk->sk_forward_alloc: tcp_v6_rcv tcp_v6_do_rcv skb_clone_and_charge_r sk_rmem_schedule __sk_mem_schedule sk_forward_alloc_add() skb_set_owner_r sk_mem_charge sk_forward_alloc_add() __kfree_skb skb_release_all skb_release_head_state sock_rfree sk_mem_uncharge sk_forward_alloc_add() sk_mem_reclaim // set local var reclaimable __sk_mem_reclaim sk_forward_alloc_add() In this syzkaller testcase, two threads call tcp_v6_do_rcv() with skb->truesize=768, the sk_forward_alloc changes like this: (cpu 1) | (cpu 2) | sk_forward_alloc ... | ... | 0 __sk_mem_schedule() | | +4096 = 4096 | __sk_mem_schedule() | +4096 = 8192 sk_mem_charge() | | -768 = 7424 | sk_mem_charge() | -768 = 6656 ... | ... | sk_mem_uncharge() | | +768 = 7424 reclaimable=7424 | | | sk_mem_uncharge() | +768 = 8192 | reclaimable=8192 | __sk_mem_reclaim() | | -4096 = 4096 | __sk_mem_reclaim() | -8192 = -4096 != 0 The skb_clone_and_charge_r() should not be called in tcp_v6_do_rcv() when sk->sk_state is TCP_LISTEN, it happens later in tcp_v6_syn_recv_sock(). Fix the same issue in dccp_v6_do_rcv().", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53129", "url": "https://ubuntu.com/security/CVE-2024-53129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: vop: Fix a dereferenced before check warning The 'state' can't be NULL, we should check crtc_state. Fix warning: drivers/gpu/drm/rockchip/rockchip_drm_vop.c:1096 vop_plane_atomic_async_check() warn: variable dereferenced before check 'state' (see line 1077)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53139", "url": "https://ubuntu.com/security/CVE-2024-53139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix possible UAF in sctp_v6_available() A lockdep report [1] with CONFIG_PROVE_RCU_LIST=y hints that sctp_v6_available() is calling dev_get_by_index_rcu() and ipv6_chk_addr() without holding rcu. [1] ============================= WARNING: suspicious RCU usage 6.12.0-rc5-virtme #1216 Tainted: G W ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by sctp_hello/31495: #0: ffff9f1ebbdb7418 (sk_lock-AF_INET6){+.+.}-{0:0}, at: sctp_bind (./arch/x86/include/asm/jump_label.h:27 net/sctp/socket.c:315) sctp stack backtrace: CPU: 7 UID: 0 PID: 31495 Comm: sctp_hello Tainted: G W 6.12.0-rc5-virtme #1216 Tainted: [W]=WARN 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:123) lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822) dev_get_by_index_rcu (net/core/dev.c:876 (discriminator 7)) sctp_v6_available (net/sctp/ipv6.c:701) sctp sctp_do_bind (net/sctp/socket.c:400 (discriminator 1)) sctp sctp_bind (net/sctp/socket.c:320) sctp inet6_bind_sk (net/ipv6/af_inet6.c:465) ? security_socket_bind (security/security.c:4581 (discriminator 1)) __sys_bind (net/socket.c:1848 net/socket.c:1869) ? do_user_addr_fault (./include/linux/rcupdate.h:347 ./include/linux/rcupdate.h:880 ./include/linux/mm.h:729 arch/x86/mm/fault.c:1340) ? do_user_addr_fault (./arch/x86/include/asm/preempt.h:84 (discriminator 13) ./include/linux/rcupdate.h:98 (discriminator 13) ./include/linux/rcupdate.h:882 (discriminator 13) ./include/linux/mm.h:729 (discriminator 13) arch/x86/mm/fault.c:1340 (discriminator 13)) __x64_sys_bind (net/socket.c:1877 (discriminator 1) net/socket.c:1875 (discriminator 1) net/socket.c:1875 (discriminator 1)) do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f59b934a1e7 Code: 44 00 00 48 8b 15 39 8c 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 b8 31 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 09 8c 0c 00 f7 d8 64 89 01 48 All code ======== 0:\t44 00 00 \tadd %r8b,(%rax) 3:\t48 8b 15 39 8c 0c 00 \tmov 0xc8c39(%rip),%rdx # 0xc8c43 a:\tf7 d8 \tneg %eax c:\t64 89 02 \tmov %eax,%fs:(%rdx) f:\tb8 ff ff ff ff \tmov $0xffffffff,%eax 14:\teb bd \tjmp 0xffffffffffffffd3 16:\t66 2e 0f 1f 84 00 00 \tcs nopw 0x0(%rax,%rax,1) 1d:\t00 00 00 20:\t0f 1f 00 \tnopl (%rax) 23:\tb8 31 00 00 00 \tmov $0x31,%eax 28:\t0f 05 \tsyscall 2a:*\t48 3d 01 f0 ff ff \tcmp $0xfffffffffffff001,%rax\t\t<-- trapping instruction 30:\t73 01 \tjae 0x33 32:\tc3 \tret 33:\t48 8b 0d 09 8c 0c 00 \tmov 0xc8c09(%rip),%rcx # 0xc8c43 3a:\tf7 d8 \tneg %eax 3c:\t64 89 01 \tmov %eax,%fs:(%rcx) 3f:\t48 \trex.W Code starting with the faulting instruction =========================================== 0:\t48 3d 01 f0 ff ff \tcmp $0xfffffffffffff001,%rax 6:\t73 01 \tjae 0x9 8:\tc3 \tret 9:\t48 8b 0d 09 8c 0c 00 \tmov 0xc8c09(%rip),%rcx # 0xc8c19 10:\tf7 d8 \tneg %eax 12:\t64 89 01 \tmov %eax,%fs:(%rcx) 15:\t48 \trex.W RSP: 002b:00007ffe2d0ad398 EFLAGS: 00000202 ORIG_RAX: 0000000000000031 RAX: ffffffffffffffda RBX: 00007ffe2d0ad3d0 RCX: 00007f59b934a1e7 RDX: 000000000000001c RSI: 00007ffe2d0ad3d0 RDI: 0000000000000005 RBP: 0000000000000005 R08: 1999999999999999 R09: 0000000000000000 R10: 00007f59b9253298 R11: 000000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53140", "url": "https://ubuntu.com/security/CVE-2024-53140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netlink: terminate outstanding dump on socket close Netlink supports iterative dumping of data. It provides the families the following ops: - start - (optional) kicks off the dumping process - dump - actual dump helper, keeps getting called until it returns 0 - done - (optional) pairs with .start, can be used for cleanup The whole process is asynchronous and the repeated calls to .dump don't actually happen in a tight loop, but rather are triggered in response to recvmsg() on the socket. This gives the user full control over the dump, but also means that the user can close the socket without getting to the end of the dump. To make sure .start is always paired with .done we check if there is an ongoing dump before freeing the socket, and if so call .done. The complication is that sockets can get freed from BH and .done is allowed to sleep. So we use a workqueue to defer the call, when needed. Unfortunately this does not work correctly. What we defer is not the cleanup but rather releasing a reference on the socket. We have no guarantee that we own the last reference, if someone else holds the socket they may release it in BH and we're back to square one. The whole dance, however, appears to be unnecessary. Only the user can interact with dumps, so we can clean up when socket is closed. And close always happens in process context. Some async code may still access the socket after close, queue notification skbs to it etc. but no dumps can start, end or otherwise make progress. Delete the workqueue and flush the dump state directly from the release handler. Note that further cleanup is possible in -next, for instance we now always call .done before releasing the main module reference, so dump doesn't have to take a reference of its own.", "cve_priority": "high", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53098", "url": "https://ubuntu.com/security/CVE-2024-53098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/ufence: Prefetch ufence addr to catch bogus address access_ok() only checks for addr overflow so also try to read the addr to catch invalid addr sent from userspace. (cherry picked from commit 9408c4508483ffc60811e910a93d6425b8e63928)", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53099", "url": "https://ubuntu.com/security/CVE-2024-53099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check validity of link->type in bpf_link_show_fdinfo() If a newly-added link type doesn't invoke BPF_LINK_TYPE(), accessing bpf_link_type_strs[link->type] may result in an out-of-bounds access. To spot such missed invocations early in the future, checking the validity of link->type in bpf_link_show_fdinfo() and emitting a warning when such invocations are missed.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53089", "url": "https://ubuntu.com/security/CVE-2024-53089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: KVM: Mark hrtimer to expire in hard interrupt context Like commit 2c0d278f3293f (\"KVM: LAPIC: Mark hrtimer to expire in hard interrupt context\") and commit 9090825fa9974 (\"KVM: arm/arm64: Let the timer expire in hardirq context on RT\"), On PREEMPT_RT enabled kernels unmarked hrtimers are moved into soft interrupt expiry mode by default. Then the timers are canceled from an preempt-notifier which is invoked with disabled preemption which is not allowed on PREEMPT_RT. The timer callback is short so in could be invoked in hard-IRQ context. So let the timer expire on hard-IRQ context even on -RT. This fix a \"scheduling while atomic\" bug for PREEMPT_RT enabled kernels: BUG: scheduling while atomic: qemu-system-loo/1011/0x00000002 Modules linked in: amdgpu rfkill nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat ns CPU: 1 UID: 0 PID: 1011 Comm: qemu-system-loo Tainted: G W 6.12.0-rc2+ #1774 Tainted: [W]=WARN Hardware name: Loongson Loongson-3A5000-7A1000-1w-CRB/Loongson-LS3A5000-7A1000-1w-CRB, BIOS vUDK2018-LoongArch-V2.0.0-prebeta9 10/21/2022 Stack : ffffffffffffffff 0000000000000000 9000000004e3ea38 9000000116744000 90000001167475a0 0000000000000000 90000001167475a8 9000000005644830 90000000058dc000 90000000058dbff8 9000000116747420 0000000000000001 0000000000000001 6a613fc938313980 000000000790c000 90000001001c1140 00000000000003fe 0000000000000001 000000000000000d 0000000000000003 0000000000000030 00000000000003f3 000000000790c000 9000000116747830 90000000057ef000 0000000000000000 9000000005644830 0000000000000004 0000000000000000 90000000057f4b58 0000000000000001 9000000116747868 900000000451b600 9000000005644830 9000000003a13998 0000000010000020 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d ... Call Trace: [<9000000003a13998>] show_stack+0x38/0x180 [<9000000004e3ea34>] dump_stack_lvl+0x84/0xc0 [<9000000003a71708>] __schedule_bug+0x48/0x60 [<9000000004e45734>] __schedule+0x1114/0x1660 [<9000000004e46040>] schedule_rtlock+0x20/0x60 [<9000000004e4e330>] rtlock_slowlock_locked+0x3f0/0x10a0 [<9000000004e4f038>] rt_spin_lock+0x58/0x80 [<9000000003b02d68>] hrtimer_cancel_wait_running+0x68/0xc0 [<9000000003b02e30>] hrtimer_cancel+0x70/0x80 [] kvm_restore_timer+0x50/0x1a0 [kvm] [] kvm_arch_vcpu_load+0x68/0x2a0 [kvm] [] kvm_sched_in+0x34/0x60 [kvm] [<9000000003a749a0>] finish_task_switch.isra.0+0x140/0x2e0 [<9000000004e44a70>] __schedule+0x450/0x1660 [<9000000004e45cb0>] schedule+0x30/0x180 [] kvm_vcpu_block+0x70/0x120 [kvm] [] kvm_vcpu_halt+0x60/0x3e0 [kvm] [] kvm_handle_gspr+0x3f4/0x4e0 [kvm] [] kvm_handle_exit+0x1c8/0x260 [kvm]", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53090", "url": "https://ubuntu.com/security/CVE-2024-53090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix lock recursion afs_wake_up_async_call() can incur lock recursion. The problem is that it is called from AF_RXRPC whilst holding the ->notify_lock, but it tries to take a ref on the afs_call struct in order to pass it to a work queue - but if the afs_call is already queued, we then have an extraneous ref that must be put... calling afs_put_call() may call back down into AF_RXRPC through rxrpc_kernel_shutdown_call(), however, which might try taking the ->notify_lock again. This case isn't very common, however, so defer it to a workqueue. The oops looks something like: BUG: spinlock recursion on CPU#0, krxrpcio/7001/1646 lock: 0xffff888141399b30, .magic: dead4ead, .owner: krxrpcio/7001/1646, .owner_cpu: 0 CPU: 0 UID: 0 PID: 1646 Comm: krxrpcio/7001 Not tainted 6.12.0-rc2-build3+ #4351 Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014 Call Trace: dump_stack_lvl+0x47/0x70 do_raw_spin_lock+0x3c/0x90 rxrpc_kernel_shutdown_call+0x83/0xb0 afs_put_call+0xd7/0x180 rxrpc_notify_socket+0xa0/0x190 rxrpc_input_split_jumbo+0x198/0x1d0 rxrpc_input_data+0x14b/0x1e0 ? rxrpc_input_call_packet+0xc2/0x1f0 rxrpc_input_call_event+0xad/0x6b0 rxrpc_input_packet_on_conn+0x1e1/0x210 rxrpc_input_packet+0x3f2/0x4d0 rxrpc_io_thread+0x243/0x410 ? __pfx_rxrpc_io_thread+0x10/0x10 kthread+0xcf/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x24/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53101", "url": "https://ubuntu.com/security/CVE-2024-53101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized value issue in from_kuid and from_kgid ocfs2_setattr() uses attr->ia_mode, attr->ia_uid and attr->ia_gid in a trace point even though ATTR_MODE, ATTR_UID and ATTR_GID aren't set. Initialize all fields of newattrs to avoid uninitialized variables, by checking if ATTR_MODE, ATTR_UID, ATTR_GID are initialized, otherwise 0.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53091", "url": "https://ubuntu.com/security/CVE-2024-53091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Add sk_is_inet and IS_ICSK check in tls_sw_has_ctx_tx/rx As the introduction of the support for vsock and unix sockets in sockmap, tls_sw_has_ctx_tx/rx cannot presume the socket passed in must be IS_ICSK. vsock and af_unix sockets have vsock_sock and unix_sock instead of inet_connection_sock. For these sockets, tls_get_ctx may return an invalid pointer and cause page fault in function tls_sw_ctx_rx. BUG: unable to handle page fault for address: 0000000000040030 Workqueue: vsock-loopback vsock_loopback_work RIP: 0010:sk_psock_strp_data_ready+0x23/0x60 Call Trace: ? __die+0x81/0xc3 ? no_context+0x194/0x350 ? do_page_fault+0x30/0x110 ? async_page_fault+0x3e/0x50 ? sk_psock_strp_data_ready+0x23/0x60 virtio_transport_recv_pkt+0x750/0x800 ? update_load_avg+0x7e/0x620 vsock_loopback_work+0xd0/0x100 process_one_work+0x1a7/0x360 worker_thread+0x30/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x112/0x130 ? __kthread_cancel_work+0x40/0x40 ret_from_fork+0x1f/0x40 v2: - Add IS_ICSK check v3: - Update the commits in Fixes", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53092", "url": "https://ubuntu.com/security/CVE-2024-53092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_pci: Fix admin vq cleanup by using correct info pointer vp_modern_avq_cleanup() and vp_del_vqs() clean up admin vq resources by virtio_pci_vq_info pointer. The info pointer of admin vq is stored in vp_dev->admin_vq.info instead of vp_dev->vqs[]. Using the info pointer from vp_dev->vqs[] for admin vq causes a kernel NULL pointer dereference bug. In vp_modern_avq_cleanup() and vp_del_vqs(), get the info pointer from vp_dev->admin_vq.info for admin vq to clean up the resources. Also make info ptr as argument of vp_del_vq() to be symmetric with vp_setup_vq(). vp_reset calls vp_modern_avq_cleanup, and causes the Call Trace: ================================================================== BUG: kernel NULL pointer dereference, address:0000000000000000 ... CPU: 49 UID: 0 PID: 4439 Comm: modprobe Not tainted 6.11.0-rc5 #1 RIP: 0010:vp_reset+0x57/0x90 [virtio_pci] Call Trace: ... ? vp_reset+0x57/0x90 [virtio_pci] ? vp_reset+0x38/0x90 [virtio_pci] virtio_reset_device+0x1d/0x30 remove_vq_common+0x1c/0x1a0 [virtio_net] virtnet_remove+0xa1/0xc0 [virtio_net] virtio_dev_remove+0x46/0xa0 ... virtio_pci_driver_exit+0x14/0x810 [virtio_pci] ==================================================================", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53102", "url": "https://ubuntu.com/security/CVE-2024-53102", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53093", "url": "https://ubuntu.com/security/CVE-2024-53093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: defer partition scanning We need to suppress the partition scan from occuring within the controller's scan_work context. If a path error occurs here, the IO will wait until a path becomes available or all paths are torn down, but that action also occurs within scan_work, so it would deadlock. Defer the partion scan to a different context that does not block scan_work.", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53094", "url": "https://ubuntu.com/security/CVE-2024-53094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Add sendpage_ok() check to disable MSG_SPLICE_PAGES While running ISER over SIW, the initiator machine encounters a warning from skb_splice_from_iter() indicating that a slab page is being used in send_page. To address this, it is better to add a sendpage_ok() check within the driver itself, and if it returns 0, then MSG_SPLICE_PAGES flag should be disabled before entering the network stack. A similar issue has been discussed for NVMe in this thread: https://lore.kernel.org/all/20240530142417.146696-1-ofir.gal@volumez.com/ WARNING: CPU: 0 PID: 5342 at net/core/skbuff.c:7140 skb_splice_from_iter+0x173/0x320 Call Trace: tcp_sendmsg_locked+0x368/0xe40 siw_tx_hdt+0x695/0xa40 [siw] siw_qp_sq_process+0x102/0xb00 [siw] siw_sq_resume+0x39/0x110 [siw] siw_run_sq+0x74/0x160 [siw] kthread+0xd2/0x100 ret_from_fork+0x34/0x40 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53100", "url": "https://ubuntu.com/security/CVE-2024-53100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: tcp: avoid race between queue_lock lock and destroy Commit 76d54bf20cdc (\"nvme-tcp: don't access released socket during error recovery\") added a mutex_lock() call for the queue->queue_lock in nvme_tcp_get_address(). However, the mutex_lock() races with mutex_destroy() in nvme_tcp_free_queue(), and causes the WARN below. DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: CPU: 3 PID: 34077 at kernel/locking/mutex.c:587 __mutex_lock+0xcf0/0x1220 Modules linked in: nvmet_tcp nvmet nvme_tcp nvme_fabrics iw_cm ib_cm ib_core pktcdvd nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables qrtr sunrpc ppdev 9pnet_virtio 9pnet pcspkr netfs parport_pc parport e1000 i2c_piix4 i2c_smbus loop fuse nfnetlink zram bochs drm_vram_helper drm_ttm_helper ttm drm_kms_helper xfs drm sym53c8xx floppy nvme scsi_transport_spi nvme_core nvme_auth serio_raw ata_generic pata_acpi dm_multipath qemu_fw_cfg [last unloaded: ib_uverbs] CPU: 3 UID: 0 PID: 34077 Comm: udisksd Not tainted 6.11.0-rc7 #319 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:__mutex_lock+0xcf0/0x1220 Code: 08 84 d2 0f 85 c8 04 00 00 8b 15 ef b6 c8 01 85 d2 0f 85 78 f4 ff ff 48 c7 c6 20 93 ee af 48 c7 c7 60 91 ee af e8 f0 a7 6d fd <0f> 0b e9 5e f4 ff ff 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 RSP: 0018:ffff88811305f760 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff88812c652058 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000001 RBP: ffff88811305f8b0 R08: 0000000000000001 R09: ffffed1075c36341 R10: ffff8883ae1b1a0b R11: 0000000000010498 R12: 0000000000000000 R13: 0000000000000000 R14: dffffc0000000000 R15: ffff88812c652058 FS: 00007f9713ae4980(0000) GS:ffff8883ae180000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcd78483c7c CR3: 0000000122c38000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn.cold+0x5b/0x1af ? __mutex_lock+0xcf0/0x1220 ? report_bug+0x1ec/0x390 ? handle_bug+0x3c/0x80 ? exc_invalid_op+0x13/0x40 ? asm_exc_invalid_op+0x16/0x20 ? __mutex_lock+0xcf0/0x1220 ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] ? __pfx___mutex_lock+0x10/0x10 ? __lock_acquire+0xd6a/0x59e0 ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] ? __pfx_nvme_tcp_get_address+0x10/0x10 [nvme_tcp] nvme_sysfs_show_address+0x81/0xc0 [nvme_core] dev_attr_show+0x42/0x80 ? __asan_memset+0x1f/0x40 sysfs_kf_seq_show+0x1f0/0x370 seq_read_iter+0x2cb/0x1130 ? rw_verify_area+0x3b1/0x590 ? __mutex_lock+0x433/0x1220 vfs_read+0x6a6/0xa20 ? lockdep_hardirqs_on+0x78/0x100 ? __pfx_vfs_read+0x10/0x10 ksys_read+0xf7/0x1d0 ? __pfx_ksys_read+0x10/0x10 ? __x64_sys_openat+0x105/0x1d0 do_syscall_64+0x93/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? __pfx_ksys_read+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? do_syscall_64+0x9f/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f9713f55cfa Code: 55 48 89 e5 48 83 ec 20 48 89 55 e8 48 89 75 f0 89 7d f8 e8 e8 74 f8 ff 48 8b 55 e8 48 8b 75 f0 4 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53095", "url": "https://ubuntu.com/security/CVE-2024-53095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix use-after-free of network namespace. Recently, we got a customer report that CIFS triggers oops while reconnecting to a server. [0] The workload runs on Kubernetes, and some pods mount CIFS servers in non-root network namespaces. The problem rarely happened, but it was always while the pod was dying. The root cause is wrong reference counting for network namespace. CIFS uses kernel sockets, which do not hold refcnt of the netns that the socket belongs to. That means CIFS must ensure the socket is always freed before its netns; otherwise, use-after-free happens. The repro steps are roughly: 1. mount CIFS in a non-root netns 2. drop packets from the netns 3. destroy the netns 4. unmount CIFS We can reproduce the issue quickly with the script [1] below and see the splat [2] if CONFIG_NET_NS_REFCNT_TRACKER is enabled. When the socket is TCP, it is hard to guarantee the netns lifetime without holding refcnt due to async timers. Let's hold netns refcnt for each socket as done for SMC in commit 9744d2bf1976 (\"smc: Fix use-after-free in tcp_write_timer_handler().\"). Note that we need to move put_net() from cifs_put_tcp_session() to clean_demultiplex_info(); otherwise, __sock_create() still could touch a freed netns while cifsd tries to reconnect from cifs_demultiplex_thread(). Also, maybe_get_net() cannot be put just before __sock_create() because the code is not under RCU and there is a small chance that the same address happened to be reallocated to another netns. [0]: CIFS: VFS: \\\\XXXXXXXXXXX has not responded in 15 seconds. Reconnecting... CIFS: Serverclose failed 4 times, giving up Unable to handle kernel paging request at virtual address 14de99e461f84a07 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 CM = 0, WnR = 0 [14de99e461f84a07] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: cls_bpf sch_ingress nls_utf8 cifs cifs_arc4 cifs_md4 dns_resolver tcp_diag inet_diag veth xt_state xt_connmark nf_conntrack_netlink xt_nat xt_statistic xt_MASQUERADE xt_mark xt_addrtype ipt_REJECT nf_reject_ipv4 nft_chain_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment nft_compat nf_tables nfnetlink overlay nls_ascii nls_cp437 sunrpc vfat fat aes_ce_blk aes_ce_cipher ghash_ce sm4_ce_cipher sm4 sm3_ce sm3 sha3_ce sha512_ce sha512_arm64 sha1_ce ena button sch_fq_codel loop fuse configfs dmi_sysfs sha2_ce sha256_arm64 dm_mirror dm_region_hash dm_log dm_mod dax efivarfs CPU: 5 PID: 2690970 Comm: cifsd Not tainted 6.1.103-109.184.amzn2023.aarch64 #1 Hardware name: Amazon EC2 r7g.4xlarge/, BIOS 1.0 11/1/2018 pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : fib_rules_lookup+0x44/0x238 lr : __fib_lookup+0x64/0xbc sp : ffff8000265db790 x29: ffff8000265db790 x28: 0000000000000000 x27: 000000000000bd01 x26: 0000000000000000 x25: ffff000b4baf8000 x24: ffff00047b5e4580 x23: ffff8000265db7e0 x22: 0000000000000000 x21: ffff00047b5e4500 x20: ffff0010e3f694f8 x19: 14de99e461f849f7 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 3f92800abd010002 x11: 0000000000000001 x10: ffff0010e3f69420 x9 : ffff800008a6f294 x8 : 0000000000000000 x7 : 0000000000000006 x6 : 0000000000000000 x5 : 0000000000000001 x4 : ffff001924354280 x3 : ffff8000265db7e0 x2 : 0000000000000000 x1 : ffff0010e3f694f8 x0 : ffff00047b5e4500 Call trace: fib_rules_lookup+0x44/0x238 __fib_lookup+0x64/0xbc ip_route_output_key_hash_rcu+0x2c4/0x398 ip_route_output_key_hash+0x60/0x8c tcp_v4_connect+0x290/0x488 __inet_stream_connect+0x108/0x3d0 inet_stream_connect+0x50/0x78 kernel_connect+0x6c/0xac generic_ip_conne ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-50265", "url": "https://ubuntu.com/security/CVE-2024-50265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove() Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove(): [ 57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12 [ 57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry [ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004 [...] [ 57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [...] [ 57.331328] Call Trace: [ 57.331477] [...] [ 57.333511] ? do_user_addr_fault+0x3e5/0x740 [ 57.333778] ? exc_page_fault+0x70/0x170 [ 57.334016] ? asm_exc_page_fault+0x2b/0x30 [ 57.334263] ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10 [ 57.334596] ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [ 57.334913] ocfs2_xa_remove_entry+0x23/0xc0 [ 57.335164] ocfs2_xa_set+0x704/0xcf0 [ 57.335381] ? _raw_spin_unlock+0x1a/0x40 [ 57.335620] ? ocfs2_inode_cache_unlock+0x16/0x20 [ 57.335915] ? trace_preempt_on+0x1e/0x70 [ 57.336153] ? start_this_handle+0x16c/0x500 [ 57.336410] ? preempt_count_sub+0x50/0x80 [ 57.336656] ? _raw_read_unlock+0x20/0x40 [ 57.336906] ? start_this_handle+0x16c/0x500 [ 57.337162] ocfs2_xattr_block_set+0xa6/0x1e0 [ 57.337424] __ocfs2_xattr_set_handle+0x1fd/0x5d0 [ 57.337706] ? ocfs2_start_trans+0x13d/0x290 [ 57.337971] ocfs2_xattr_set+0xb13/0xfb0 [ 57.338207] ? dput+0x46/0x1c0 [ 57.338393] ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338665] ? ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338948] __vfs_removexattr+0x92/0xc0 [ 57.339182] __vfs_removexattr_locked+0xd5/0x190 [ 57.339456] ? preempt_count_sub+0x50/0x80 [ 57.339705] vfs_removexattr+0x5f/0x100 [...] Reproducer uses faultinject facility to fail ocfs2_xa_remove() -> ocfs2_xa_value_truncate() with -ENOMEM. In this case the comment mentions that we can return 0 if ocfs2_xa_cleanup_value_truncate() is going to wipe the entry anyway. But the following 'rc' check is wrong and execution flow do 'ocfs2_xa_remove_entry(loc);' twice: * 1st: in ocfs2_xa_cleanup_value_truncate(); * 2nd: returning back to ocfs2_xa_remove() instead of going to 'out'. Fix this by skipping the 2nd removal of the same entry and making syzkaller repro happy.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50266", "url": "https://ubuntu.com/security/CVE-2024-50266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: qcom: videocc-sm8350: use HW_CTRL_TRIGGER for vcodec GDSCs A recent change in the venus driver results in a stuck clock on the Lenovo ThinkPad X13s, for example, when streaming video in firefox: \tvideo_cc_mvs0_clk status stuck at 'off' \tWARNING: CPU: 6 PID: 2885 at drivers/clk/qcom/clk-branch.c:87 clk_branch_wait+0x144/0x15c \t... \tCall trace: \t clk_branch_wait+0x144/0x15c \t clk_branch2_enable+0x30/0x40 \t clk_core_enable+0xd8/0x29c \t clk_enable+0x2c/0x4c \t vcodec_clks_enable.isra.0+0x94/0xd8 [venus_core] \t coreid_power_v4+0x464/0x628 [venus_core] \t vdec_start_streaming+0xc4/0x510 [venus_dec] \t vb2_start_streaming+0x6c/0x180 [videobuf2_common] \t vb2_core_streamon+0x120/0x1dc [videobuf2_common] \t vb2_streamon+0x1c/0x6c [videobuf2_v4l2] \t v4l2_m2m_ioctl_streamon+0x30/0x80 [v4l2_mem2mem] \t v4l_streamon+0x24/0x30 [videodev] using the out-of-tree sm8350/sc8280xp venus support. [1] Update also the sm8350/sc8280xp GDSC definitions so that the hw control mode can be changed at runtime as the venus driver now requires.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50267", "url": "https://ubuntu.com/security/CVE-2024-50267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: fix use after free in debug printk The \"dev_dbg(&urb->dev->dev, ...\" which happens after usb_free_urb(urb) is a use after free of the \"urb\" pointer. Store the \"dev\" pointer at the start of the function to avoid this issue.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50268", "url": "https://ubuntu.com/security/CVE-2024-50268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: fix potential out of bounds in ucsi_ccg_update_set_new_cam_cmd() The \"*cmd\" variable can be controlled by the user via debugfs. That means \"new_cam\" can be as high as 255 while the size of the uc->updated[] array is UCSI_MAX_ALTMODES (30). The call tree is: ucsi_cmd() // val comes from simple_attr_write_xsigned() -> ucsi_send_command() -> ucsi_send_command_common() -> ucsi_run_command() // calls ucsi->ops->sync_control() -> ucsi_ccg_sync_control()", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53083", "url": "https://ubuntu.com/security/CVE-2024-53083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: qcom-pmic: init value of hdr_len/txbuf_len earlier If the read of USB_PDPHY_RX_ACKNOWLEDGE_REG failed, then hdr_len and txbuf_len are uninitialized. This commit stops to print uninitialized value and misleading/false data.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50269", "url": "https://ubuntu.com/security/CVE-2024-50269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: musb: sunxi: Fix accessing an released usb phy Commit 6ed05c68cbca (\"usb: musb: sunxi: Explicitly release USB PHY on exit\") will cause that usb phy @glue->xceiv is accessed after released. 1) register platform driver @sunxi_musb_driver // get the usb phy @glue->xceiv sunxi_musb_probe() -> devm_usb_get_phy(). 2) register and unregister platform driver @musb_driver musb_probe() -> sunxi_musb_init() use the phy here //the phy is released here musb_remove() -> sunxi_musb_exit() -> devm_usb_put_phy() 3) register @musb_driver again musb_probe() -> sunxi_musb_init() use the phy here but the phy has been released at 2). ... Fixed by reverting the commit, namely, removing devm_usb_put_phy() from sunxi_musb_exit().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53079", "url": "https://ubuntu.com/security/CVE-2024-53079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/thp: fix deferred split unqueue naming and locking Recent changes are putting more pressure on THP deferred split queues: under load revealing long-standing races, causing list_del corruptions, \"Bad page state\"s and worse (I keep BUGs in both of those, so usually don't get to see how badly they end up without). The relevant recent changes being 6.8's mTHP, 6.10's mTHP swapout, and 6.12's mTHP swapin, improved swap allocation, and underused THP splitting. Before fixing locking: rename misleading folio_undo_large_rmappable(), which does not undo large_rmappable, to folio_unqueue_deferred_split(), which is what it does. But that and its out-of-line __callee are mm internals of very limited usability: add comment and WARN_ON_ONCEs to check usage; and return a bool to say if a deferred split was unqueued, which can then be used in WARN_ON_ONCEs around safety checks (sparing callers the arcane conditionals in __folio_unqueue_deferred_split()). Just omit the folio_unqueue_deferred_split() from free_unref_folios(), all of whose callers now call it beforehand (and if any forget then bad_page() will tell) - except for its caller put_pages_list(), which itself no longer has any callers (and will be deleted separately). Swapout: mem_cgroup_swapout() has been resetting folio->memcg_data 0 without checking and unqueueing a THP folio from deferred split list; which is unfortunate, since the split_queue_lock depends on the memcg (when memcg is enabled); so swapout has been unqueueing such THPs later, when freeing the folio, using the pgdat's lock instead: potentially corrupting the memcg's list. __remove_mapping() has frozen refcount to 0 here, so no problem with calling folio_unqueue_deferred_split() before resetting memcg_data. That goes back to 5.4 commit 87eaceb3faa5 (\"mm: thp: make deferred split shrinker memcg aware\"): which included a check on swapcache before adding to deferred queue, but no check on deferred queue before adding THP to swapcache. That worked fine with the usual sequence of events in reclaim (though there were a couple of rare ways in which a THP on deferred queue could have been swapped out), but 6.12 commit dafff3f4c850 (\"mm: split underused THPs\") avoids splitting underused THPs in reclaim, which makes swapcache THPs on deferred queue commonplace. Keep the check on swapcache before adding to deferred queue? Yes: it is no longer essential, but preserves the existing behaviour, and is likely to be a worthwhile optimization (vmstat showed much more traffic on the queue under swapping load if the check was removed); update its comment. Memcg-v1 move (deprecated): mem_cgroup_move_account() has been changing folio->memcg_data without checking and unqueueing a THP folio from the deferred list, sometimes corrupting \"from\" memcg's list, like swapout. Refcount is non-zero here, so folio_unqueue_deferred_split() can only be used in a WARN_ON_ONCE to validate the fix, which must be done earlier: mem_cgroup_move_charge_pte_range() first try to split the THP (splitting of course unqueues), or skip it if that fails. Not ideal, but moving charge has been requested, and khugepaged should repair the THP later: nobody wants new custom unqueueing code just for this deprecated case. The 87eaceb3faa5 commit did have the code to move from one deferred list to another (but was not conscious of its unsafety while refcount non-0); but that was removed by 5.6 commit fac0516b5534 (\"mm: thp: don't need care deferred split queue in memcg charge move path\"), which argued that the existence of a PMD mapping guarantees that the THP cannot be on a deferred list. As above, false in rare cases, and now commonly false. Backport to 6.11 should be straightforward. Earlier backports must take care that other _deferred_list fixes and dependencies are included. There is not a strong case for backports, but they can fix cornercases.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50270", "url": "https://ubuntu.com/security/CVE-2024-50270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: avoid overflow in damon_feed_loop_next_input() damon_feed_loop_next_input() is inefficient and fragile to overflows. Specifically, 'score_goal_diff_bp' calculation can overflow when 'score' is high. The calculation is actually unnecessary at all because 'goal' is a constant of value 10,000. Calculation of 'compensation' is again fragile to overflow. Final calculation of return value for under-achiving case is again fragile to overflow when the current score is under-achieving the target. Add two corner cases handling at the beginning of the function to make the body easier to read, and rewrite the body of the function to avoid overflows and the unnecessary bp value calcuation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50271", "url": "https://ubuntu.com/security/CVE-2024-50271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: signal: restore the override_rlimit logic Prior to commit d64696905554 (\"Reimplement RLIMIT_SIGPENDING on top of ucounts\") UCOUNT_RLIMIT_SIGPENDING rlimit was not enforced for a class of signals. However now it's enforced unconditionally, even if override_rlimit is set. This behavior change caused production issues. For example, if the limit is reached and a process receives a SIGSEGV signal, sigqueue_alloc fails to allocate the necessary resources for the signal delivery, preventing the signal from being delivered with siginfo. This prevents the process from correctly identifying the fault address and handling the error. From the user-space perspective, applications are unaware that the limit has been reached and that the siginfo is effectively 'corrupted'. This can lead to unpredictable behavior and crashes, as we observed with java applications. Fix this by passing override_rlimit into inc_rlimit_get_ucounts() and skip the comparison to max there if override_rlimit is set. This effectively restores the old behavior.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50272", "url": "https://ubuntu.com/security/CVE-2024-50272", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: filemap: Fix bounds checking in filemap_read() If the caller supplies an iocb->ki_pos value that is close to the filesystem upper limit, and an iterator with a count that causes us to overflow that limit, then filemap_read() enters an infinite loop. This behaviour was discovered when testing xfstests generic/525 with the \"localio\" optimisation for loopback NFS mounts.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53104", "url": "https://ubuntu.com/security/CVE-2024-53104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_parse_format This can lead to out of bounds writes since frames of this type were not taken into account when calculating the size of the frames buffer in uvc_parse_streaming.", "cve_priority": "high", "cve_public_date": "2024-12-02 08:15:00 UTC" }, { "cve": "CVE-2024-50273", "url": "https://ubuntu.com/security/CVE-2024-50273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reinitialize delayed ref list after deleting it from the list At insert_delayed_ref() if we need to update the action of an existing ref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head's ref_add_list using list_del(), which leaves the ref's add_list member not reinitialized, as list_del() sets the next and prev members of the list to LIST_POISON1 and LIST_POISON2, respectively. If later we end up calling drop_delayed_ref() against the ref, which can happen during merging or when destroying delayed refs due to a transaction abort, we can trigger a crash since at drop_delayed_ref() we call list_empty() against the ref's add_list, which returns false since the list was not reinitialized after the list_del() and as a consequence we call list_del() again at drop_delayed_ref(). This results in an invalid list access since the next and prev members are set to poison pointers, resulting in a splat if CONFIG_LIST_HARDENED and CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences otherwise. So fix this by deleting from the list with list_del_init() instead.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53064", "url": "https://ubuntu.com/security/CVE-2024-53064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix idpf_vc_core_init error path In an event where the platform running the device control plane is rebooted, reset is detected on the driver. It releases all the resources and waits for the reset to complete. Once the reset is done, it tries to build the resources back. At this time if the device control plane is not yet started, then the driver timeouts on the virtchnl message and retries to establish the mailbox again. In the retry flow, mailbox is deinitialized but the mailbox workqueue is still alive and polling for the mailbox message. This results in accessing the released control queue leading to null-ptr-deref. Fix it by unrolling the work queue cancellation and mailbox deinitialization in the reverse order which they got initialized.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50274", "url": "https://ubuntu.com/security/CVE-2024-50274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: avoid vport access in idpf_get_link_ksettings When the device control plane is removed or the platform running device control plane is rebooted, a reset is detected on the driver. On driver reset, it releases the resources and waits for the reset to complete. If the reset fails, it takes the error path and releases the vport lock. At this time if the monitoring tools tries to access link settings, it call traces for accessing released vport pointer. To avoid it, move link_speed_mbps to netdev_priv structure which removes the dependency on vport pointer and the vport lock in idpf_get_link_ksettings. Also use netif_carrier_ok() to check the link status and adjust the offsetof to use link_up instead of link_speed_mbps.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53065", "url": "https://ubuntu.com/security/CVE-2024-53065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/slab: fix warning caused by duplicate kmem_cache creation in kmem_buckets_create Commit b035f5a6d852 (\"mm: slab: reduce the kmalloc() minimum alignment if DMA bouncing possible\") reduced ARCH_KMALLOC_MINALIGN to 8 on arm64. However, with KASAN_HW_TAGS enabled, arch_slab_minalign() becomes 16. This causes kmalloc_caches[*][8] to be aliased to kmalloc_caches[*][16], resulting in kmem_buckets_create() attempting to create a kmem_cache for size 16 twice. This duplication triggers warnings on boot: [ 2.325108] ------------[ cut here ]------------ [ 2.325135] kmem_cache of name 'memdup_user-16' already exists [ 2.325783] WARNING: CPU: 0 PID: 1 at mm/slab_common.c:107 __kmem_cache_create_args+0xb8/0x3b0 [ 2.327957] Modules linked in: [ 2.328550] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5mm-unstable-arm64+ #12 [ 2.328683] Hardware name: QEMU QEMU Virtual Machine, BIOS 2024.02-2 03/11/2024 [ 2.328790] pstate: 61000009 (nZCv daif -PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 2.328911] pc : __kmem_cache_create_args+0xb8/0x3b0 [ 2.328930] lr : __kmem_cache_create_args+0xb8/0x3b0 [ 2.328942] sp : ffff800083d6fc50 [ 2.328961] x29: ffff800083d6fc50 x28: f2ff0000c1674410 x27: ffff8000820b0598 [ 2.329061] x26: 000000007fffffff x25: 0000000000000010 x24: 0000000000002000 [ 2.329101] x23: ffff800083d6fce8 x22: ffff8000832222e8 x21: ffff800083222388 [ 2.329118] x20: f2ff0000c1674410 x19: f5ff0000c16364c0 x18: ffff800083d80030 [ 2.329135] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 2.329152] x14: 0000000000000000 x13: 0a73747369786520 x12: 79646165726c6120 [ 2.329169] x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : 0000000000000000 [ 2.329194] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 [ 2.329210] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 2.329226] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 2.329291] Call trace: [ 2.329407] __kmem_cache_create_args+0xb8/0x3b0 [ 2.329499] kmem_buckets_create+0xfc/0x320 [ 2.329526] init_user_buckets+0x34/0x78 [ 2.329540] do_one_initcall+0x64/0x3c8 [ 2.329550] kernel_init_freeable+0x26c/0x578 [ 2.329562] kernel_init+0x3c/0x258 [ 2.329574] ret_from_fork+0x10/0x20 [ 2.329698] ---[ end trace 0000000000000000 ]--- [ 2.403704] ------------[ cut here ]------------ [ 2.404716] kmem_cache of name 'msg_msg-16' already exists [ 2.404801] WARNING: CPU: 2 PID: 1 at mm/slab_common.c:107 __kmem_cache_create_args+0xb8/0x3b0 [ 2.404842] Modules linked in: [ 2.404971] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.12.0-rc5mm-unstable-arm64+ #12 [ 2.405026] Tainted: [W]=WARN [ 2.405043] Hardware name: QEMU QEMU Virtual Machine, BIOS 2024.02-2 03/11/2024 [ 2.405057] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2.405079] pc : __kmem_cache_create_args+0xb8/0x3b0 [ 2.405100] lr : __kmem_cache_create_args+0xb8/0x3b0 [ 2.405111] sp : ffff800083d6fc50 [ 2.405115] x29: ffff800083d6fc50 x28: fbff0000c1674410 x27: ffff8000820b0598 [ 2.405135] x26: 000000000000ffd0 x25: 0000000000000010 x24: 0000000000006000 [ 2.405153] x23: ffff800083d6fce8 x22: ffff8000832222e8 x21: ffff800083222388 [ 2.405169] x20: fbff0000c1674410 x19: fdff0000c163d6c0 x18: ffff800083d80030 [ 2.405185] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 2.405201] x14: 0000000000000000 x13: 0a73747369786520 x12: 79646165726c6120 [ 2.405217] x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : 0000000000000000 [ 2.405233] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 [ 2.405248] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 2.405271] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 2.405287] Call trace: [ 2 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50275", "url": "https://ubuntu.com/security/CVE-2024-50275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64/sve: Discard stale CPU state when handling SVE traps The logic for handling SVE traps manipulates saved FPSIMD/SVE state incorrectly, and a race with preemption can result in a task having TIF_SVE set and TIF_FOREIGN_FPSTATE clear even though the live CPU state is stale (e.g. with SVE traps enabled). This has been observed to result in warnings from do_sve_acc() where SVE traps are not expected while TIF_SVE is set: | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* SVE access shouldn't have trapped */ Warnings of this form have been reported intermittently, e.g. https://lore.kernel.org/linux-arm-kernel/CA+G9fYtEGe_DhY2Ms7+L7NKsLYUomGsgqpdBj+QwDLeSg=JhGg@mail.gmail.com/ https://lore.kernel.org/linux-arm-kernel/000000000000511e9a060ce5a45c@google.com/ The race can occur when the SVE trap handler is preempted before and after manipulating the saved FPSIMD/SVE state, starting and ending on the same CPU, e.g. | void do_sve_acc(unsigned long esr, struct pt_regs *regs) | { | // Trap on CPU 0 with TIF_SVE clear, SVE 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(); | | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* SVE access shouldn't have trapped */ | | sve_init_regs() { | if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) { | ... | } else { | fpsimd_to_sve(current); | current->thread.fp_type = FP_STATE_SVE; | } | } | | 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 SVE 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.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50276", "url": "https://ubuntu.com/security/CVE-2024-50276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: vertexcom: mse102x: Fix possible double free of TX skb The scope of the TX skb is wider than just mse102x_tx_frame_spi(), so in case the TX skb room needs to be expanded, we should free the the temporary skb instead of the original skb. Otherwise the original TX skb pointer would be freed again in mse102x_tx_work(), which leads to crashes: Internal error: Oops: 0000000096000004 [#2] PREEMPT SMP CPU: 0 PID: 712 Comm: kworker/0:1 Tainted: G D 6.6.23 Hardware name: chargebyte Charge SOM DC-ONE (DT) Workqueue: events mse102x_tx_work [mse102x] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_release_data+0xb8/0x1d8 lr : skb_release_data+0x1ac/0x1d8 sp : ffff8000819a3cc0 x29: ffff8000819a3cc0 x28: ffff0000046daa60 x27: ffff0000057f2dc0 x26: ffff000005386c00 x25: 0000000000000002 x24: 00000000ffffffff x23: 0000000000000000 x22: 0000000000000001 x21: ffff0000057f2e50 x20: 0000000000000006 x19: 0000000000000000 x18: ffff00003fdacfcc x17: e69ad452d0c49def x16: 84a005feff870102 x15: 0000000000000000 x14: 000000000000024a x13: 0000000000000002 x12: 0000000000000000 x11: 0000000000000400 x10: 0000000000000930 x9 : ffff00003fd913e8 x8 : fffffc00001bc008 x7 : 0000000000000000 x6 : 0000000000000008 x5 : ffff00003fd91340 x4 : 0000000000000000 x3 : 0000000000000009 x2 : 00000000fffffffe x1 : 0000000000000000 x0 : 0000000000000000 Call trace: skb_release_data+0xb8/0x1d8 kfree_skb_reason+0x48/0xb0 mse102x_tx_work+0x164/0x35c [mse102x] process_one_work+0x138/0x260 worker_thread+0x32c/0x438 kthread+0x118/0x11c ret_from_fork+0x10/0x20 Code: aa1303e0 97fffab6 72001c1f 54000141 (f9400660)", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53066", "url": "https://ubuntu.com/security/CVE-2024-53066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfs: Fix KMSAN warning in decode_getfattr_attrs() Fix the following KMSAN warning: CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G B Tainted: [B]=BAD_PAGE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) ===================================================== ===================================================== BUG: KMSAN: uninit-value in decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_generic+0x806/0xb00 nfs4_xdr_dec_getattr+0x1de/0x240 rpcauth_unwrap_resp_decode+0xab/0x100 rpcauth_unwrap_resp+0x95/0xc0 call_decode+0x4ff/0xb50 __rpc_execute+0x57b/0x19d0 rpc_execute+0x368/0x5e0 rpc_run_task+0xcfe/0xee0 nfs4_proc_getattr+0x5b5/0x990 __nfs_revalidate_inode+0x477/0xd00 nfs_access_get_cached+0x1021/0x1cc0 nfs_do_access+0x9f/0xae0 nfs_permission+0x1e4/0x8c0 inode_permission+0x356/0x6c0 link_path_walk+0x958/0x1330 path_lookupat+0xce/0x6b0 filename_lookup+0x23e/0x770 vfs_statx+0xe7/0x970 vfs_fstatat+0x1f2/0x2c0 __se_sys_newfstatat+0x67/0x880 __x64_sys_newfstatat+0xbd/0x120 x64_sys_call+0x1826/0x3cf0 do_syscall_64+0xd0/0x1b0 entry_SYSCALL_64_after_hwframe+0x77/0x7f The KMSAN warning is triggered in decode_getfattr_attrs(), when calling decode_attr_mdsthreshold(). It appears that fattr->mdsthreshold is not initialized. Fix the issue by initializing fattr->mdsthreshold to NULL in nfs_fattr_init().", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53067", "url": "https://ubuntu.com/security/CVE-2024-53067", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Start the RTC update work later The RTC update work involves runtime resuming the UFS controller. Hence, only start the RTC update work after runtime power management in the UFS driver has been fully initialized. This patch fixes the following kernel crash: Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP Workqueue: events ufshcd_rtc_work Call trace: _raw_spin_lock_irqsave+0x34/0x8c (P) pm_runtime_get_if_active+0x24/0x9c (L) pm_runtime_get_if_active+0x24/0x9c ufshcd_rtc_work+0x138/0x1b4 process_one_work+0x148/0x288 worker_thread+0x2cc/0x3d4 kthread+0x110/0x114 ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50277", "url": "https://ubuntu.com/security/CVE-2024-50277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: fix a crash if blk_alloc_disk fails If blk_alloc_disk fails, the variable md->disk is set to an error value. cleanup_mapped_device will see that md->disk is non-NULL and it will attempt to access it, causing a crash on this statement \"md->disk->private_data = NULL;\".", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50278", "url": "https://ubuntu.com/security/CVE-2024-50278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix potential out-of-bounds access on the first resume Out-of-bounds access occurs if the fast device is expanded unexpectedly before the first-time resume of the cache table. This happens because expanding the fast device requires reloading the cache table for cache_create to allocate new in-core data structures that fit the new size, and the check in cache_preresume is not performed during the first resume, leading to the issue. Reproduce steps: 1. prepare component devices: 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\" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct 2. load a cache table of 512 cache blocks, and deliberately expand the fast device before resuming the cache, making the in-core data structures inadequate. dmsetup create cache --notable dmsetup reload cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" dmsetup reload cdata --table \"0 131072 linear /dev/sdc 8192\" dmsetup resume cdata dmsetup resume cache 3. suspend the cache to write out the in-core dirty bitset and hint array, leading to out-of-bounds access to the dirty bitset at offset 0x40: dmsetup suspend cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80 Read of size 8 at addr ffffc90000085040 by task dmsetup/90 (...snip...) The buggy address belongs to the virtual mapping at [ffffc90000085000, ffffc90000087000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by checking the size change on the first resume.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50279", "url": "https://ubuntu.com/security/CVE-2024-50279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix out-of-bounds access to the dirty bitset when resizing dm-cache checks the dirty bits of the cache blocks to be dropped when shrinking the fast device, but an index bug in bitset iteration causes out-of-bounds access. Reproduce steps: 1. create a cache device of 1024 cache blocks (128 bytes dirty bitset) dmsetup create cmeta --table \"0 8192 linear /dev/sdc 0\" dmsetup create cdata --table \"0 131072 linear /dev/sdc 8192\" dmsetup create corig --table \"0 524288 linear /dev/sdc 262144\" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" 2. shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80) dmsetup suspend cache dmsetup reload cdata --table \"0 65536 linear /dev/sdc 8192\" dmsetup resume cdata dmsetup resume cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131 (...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by making the index post-incremented.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50280", "url": "https://ubuntu.com/security/CVE-2024-50280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix flushing uninitialized delayed_work on cache_ctr error An unexpected WARN_ON from flush_work() may occur when cache creation fails, caused by destroying the uninitialized delayed_work waker in the error path of cache_create(). For example, the warning appears on the superblock checksum error. Reproduce steps: 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\" dd if=/dev/urandom of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" Kernel logs: (snip) WARNING: CPU: 0 PID: 84 at kernel/workqueue.c:4178 __flush_work+0x5d4/0x890 Fix by pulling out the cancel_delayed_work_sync() from the constructor's error path. This patch doesn't affect the use-after-free fix for concurrent dm_resume and dm_destroy (commit 6a459d8edbdb (\"dm cache: Fix UAF in destroy()\")) as cache_dtr is not changed.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50281", "url": "https://ubuntu.com/security/CVE-2024-50281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: trusted: dcp: fix NULL dereference in AEAD crypto operation When sealing or unsealing a key blob we currently do not wait for the AEAD cipher operation to finish and simply return after submitting the request. If there is some load on the system we can exit before the cipher operation is done and the buffer we read from/write to is already removed from the stack. This will e.g. result in NULL pointer dereference errors in the DCP driver during blob creation. Fix this by waiting for the AEAD cipher operation to finish before resuming the seal and unseal calls.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50282", "url": "https://ubuntu.com/security/CVE-2024-50282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read() Avoid a possible buffer overflow if size is larger than 4K. (cherry picked from commit f5d873f5825b40d886d03bd2aede91d4cf002434)", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53071", "url": "https://ubuntu.com/security/CVE-2024-53071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Be stricter about IO mapping flags The current panthor_device_mmap_io() implementation has two issues: 1. For mapping DRM_PANTHOR_USER_FLUSH_ID_MMIO_OFFSET, panthor_device_mmap_io() bails if VM_WRITE is set, but does not clear VM_MAYWRITE. That means userspace can use mprotect() to make the mapping writable later on. This is a classic Linux driver gotcha. I don't think this actually has any impact in practice: When the GPU is powered, writes to the FLUSH_ID seem to be ignored; and when the GPU is not powered, the dummy_latest_flush page provided by the driver is deliberately designed to not do any flushes, so the only thing writing to the dummy_latest_flush could achieve would be to make *more* flushes happen. 2. panthor_device_mmap_io() does not block MAP_PRIVATE mappings (which are mappings without the VM_SHARED flag). MAP_PRIVATE in combination with VM_MAYWRITE indicates that the VMA has copy-on-write semantics, which for VM_PFNMAP are semi-supported but fairly cursed. In particular, in such a mapping, the driver can only install PTEs during mmap() by calling remap_pfn_range() (because remap_pfn_range() wants to **store the physical address of the mapped physical memory into the vm_pgoff of the VMA**); installing PTEs later on with a fault handler (as panthor does) is not supported in private mappings, and so if you try to fault in such a mapping, vmf_insert_pfn_prot() splats when it hits a BUG() check. Fix it by clearing the VM_MAYWRITE flag (userspace writing to the FLUSH_ID doesn't make sense) and requiring VM_SHARED (copy-on-write semantics for the FLUSH_ID don't make sense). Reproducers for both scenarios are in the notes of my patch on the mailing list; I tested that these bugs exist on a Rock 5B machine. Note that I only compile-tested the patch, I haven't tested it; I don't have a working kernel build setup for the test machine yet. Please test it before applying it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53080", "url": "https://ubuntu.com/security/CVE-2024-53080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Lock XArray when getting entries for the VM Similar to commit cac075706f29 (\"drm/panthor: Fix race when converting group handle to group object\") we need to use the XArray's internal locking when retrieving a vm pointer from there. v2: Removed part of the patch that was trying to protect fetching the heap pointer from XArray, as that operation is protected by the @pool->lock.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53084", "url": "https://ubuntu.com/security/CVE-2024-53084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Break an object reference loop When remaining resources are being cleaned up on driver close, outstanding VM mappings may result in resources being leaked, due to an object reference loop, as shown below, with each object (or set of objects) referencing the object below it: PVR GEM Object GPU scheduler \"finished\" fence GPU scheduler “scheduled” fence PVR driver “done” fence PVR Context PVR VM Context PVR VM Mappings PVR GEM Object The reference that the PVR VM Context has on the VM mappings is a soft one, in the sense that the freeing of outstanding VM mappings is done as part of VM context destruction; no reference counts are involved, as is the case for all the other references in the loop. To break the reference loop during cleanup, free the outstanding VM mappings before destroying the PVR Context associated with the VM context.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53085", "url": "https://ubuntu.com/security/CVE-2024-53085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: Lock TPM chip in tpm_pm_suspend() first Setting TPM_CHIP_FLAG_SUSPENDED in the end of tpm_pm_suspend() can be racy according, as this leaves window for tpm_hwrng_read() to be called while the operation is in progress. The recent bug report gives also evidence of this behaviour. Aadress this by locking the TPM chip before checking any chip->flags both in tpm_pm_suspend() and tpm_hwrng_read(). Move TPM_CHIP_FLAG_SUSPENDED check inside tpm_get_random() so that it will be always checked only when the lock is reserved.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53086", "url": "https://ubuntu.com/security/CVE-2024-53086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Drop VM dma-resv lock on xe_sync_in_fence_get failure in exec IOCTL Upon failure all locks need to be dropped before returning to the user. (cherry picked from commit 7d1a4258e602ffdce529f56686925034c1b3b095)", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53087", "url": "https://ubuntu.com/security/CVE-2024-53087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix possible exec queue leak in exec IOCTL In a couple of places after an exec queue is looked up the exec IOCTL returns on input errors without dropping the exec queue ref. Fix this ensuring the exec queue ref is dropped on input error. (cherry picked from commit 07064a200b40ac2195cb6b7b779897d9377e5e6f)", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50283", "url": "https://ubuntu.com/security/CVE-2024-50283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-use-after-free in smb3_preauth_hash_rsp ksmbd_user_session_put should be called under smb3_preauth_hash_rsp(). It will avoid freeing session before calling smb3_preauth_hash_rsp().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50284", "url": "https://ubuntu.com/security/CVE-2024-50284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix the missing xa_store error check xa_store() can fail, it return xa_err(-EINVAL) if the entry cannot be stored in an XArray, or xa_err(-ENOMEM) if memory allocation failed, so check error for xa_store() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50285", "url": "https://ubuntu.com/security/CVE-2024-50285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: check outstanding simultaneous SMB operations If Client send simultaneous SMB operations to ksmbd, It exhausts too much memory through the \"ksmbd_work_cache”. It will cause OOM issue. ksmbd has a credit mechanism but it can't handle this problem. This patch add the check if it exceeds max credits to prevent this problem by assuming that one smb request consumes at least one credit.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50286", "url": "https://ubuntu.com/security/CVE-2024-50286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-use-after-free in ksmbd_smb2_session_create There is a race condition between ksmbd_smb2_session_create and ksmbd_expire_session. This patch add missing sessions_table_lock while adding/deleting session from global session table.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50287", "url": "https://ubuntu.com/security/CVE-2024-50287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-tpg: prevent the risk of a division by zero As reported by Coverity, the logic at tpg_precalculate_line() blindly rescales the buffer even when scaled_witdh is equal to zero. If this ever happens, this will cause a division by zero. Instead, add a WARN_ON_ONCE() to trigger such cases and return without doing any precalculation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50288", "url": "https://ubuntu.com/security/CVE-2024-50288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: fix buffer overwrite when using > 32 buffers The maximum number of buffers that can be requested was increased to 64 for the video capture queue. But video capture used a must_blank array that was still sized for 32 (VIDEO_MAX_FRAME). This caused an out-of-bounds write when using buffer indices >= 32. Create a new define MAX_VID_CAP_BUFFERS that is used to access the must_blank array and set max_num_buffers for the video capture queue. This solves a crash reported by: \thttps://bugzilla.kernel.org/show_bug.cgi?id=219258", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50289", "url": "https://ubuntu.com/security/CVE-2024-50289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: av7110: fix a spectre vulnerability As warned by smatch: \tdrivers/staging/media/av7110/av7110_ca.c:270 dvb_ca_ioctl() warn: potential spectre issue 'av7110->ci_slot' [w] (local cap) There is a spectre-related vulnerability at the code. Fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50290", "url": "https://ubuntu.com/security/CVE-2024-50290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx24116: prevent overflows on SNR calculus as reported by Coverity, if reading SNR registers fail, a negative number will be returned, causing an underflow when reading SNR registers. Prevent that.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53061", "url": "https://ubuntu.com/security/CVE-2024-53061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: s5p-jpeg: prevent buffer overflows The current logic allows word to be less than 2. If this happens, there will be buffer overflows, as reported by smatch. Add extra checks to prevent it. While here, remove an unused word = 0 assignment.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53081", "url": "https://ubuntu.com/security/CVE-2024-53081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ar0521: don't overflow when checking PLL values The PLL checks are comparing 64 bit integers with 32 bit ones, as reported by Coverity. Depending on the values of the variables, this may underflow. Fix it ensuring that both sides of the expression are u64.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53062", "url": "https://ubuntu.com/security/CVE-2024-53062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mgb4: protect driver against spectre Frequency range is set from sysfs via frequency_range_store(), being vulnerable to spectre, as reported by smatch: \tdrivers/media/pci/mgb4/mgb4_cmt.c:231 mgb4_cmt_set_vin_freq_range() warn: potential spectre issue 'cmt_vals_in' [r] \tdrivers/media/pci/mgb4/mgb4_cmt.c:238 mgb4_cmt_set_vin_freq_range() warn: possible spectre second half. 'reg_set' Fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50291", "url": "https://ubuntu.com/security/CVE-2024-50291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvb-core: add missing buffer index check dvb_vb2_expbuf() didn't check if the given buffer index was for a valid buffer. Add this check.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50292", "url": "https://ubuntu.com/security/CVE-2024-50292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: stm32: spdifrx: fix dma channel release in stm32_spdifrx_remove In case of error when requesting ctrl_chan DMA channel, ctrl_chan is not null. So the release of the dma channel leads to the following issue: [ 4.879000] st,stm32-spdifrx 500d0000.audio-controller: dma_request_slave_channel error -19 [ 4.888975] Unable to handle kernel NULL pointer dereference at virtual address 000000000000003d [...] [ 5.096577] Call trace: [ 5.099099] dma_release_channel+0x24/0x100 [ 5.103235] stm32_spdifrx_remove+0x24/0x60 [snd_soc_stm32_spdifrx] [ 5.109494] stm32_spdifrx_probe+0x320/0x4c4 [snd_soc_stm32_spdifrx] To avoid this issue, release channel only if the pointer is valid.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53063", "url": "https://ubuntu.com/security/CVE-2024-53063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvbdev: prevent the risk of out of memory access The dvbdev contains a static variable used to store dvb minors. The behavior of it depends if CONFIG_DVB_DYNAMIC_MINORS is set or not. When not set, dvb_register_device() won't check for boundaries, as it will rely that a previous call to dvb_register_adapter() would already be enforcing it. On a similar way, dvb_device_open() uses the assumption that the register functions already did the needed checks. This can be fragile if some device ends using different calls. This also generate warnings on static check analysers like Coverity. So, add explicit guards to prevent potential risk of OOM issues.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50293", "url": "https://ubuntu.com/security/CVE-2024-50293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: do not leave a dangling sk pointer in __smc_create() Thanks to commit 4bbd360a5084 (\"socket: Print pf->create() when it does not clear sock->sk on failure.\"), syzbot found an issue with AF_SMC: smc_create must clear sock->sk on failure, family: 43, type: 1, protocol: 0 WARNING: CPU: 0 PID: 5827 at net/socket.c:1565 __sock_create+0x96f/0xa30 net/socket.c:1563 Modules linked in: CPU: 0 UID: 0 PID: 5827 Comm: syz-executor259 Not tainted 6.12.0-rc6-next-20241106-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:__sock_create+0x96f/0xa30 net/socket.c:1563 Code: 03 00 74 08 4c 89 e7 e8 4f 3b 85 f8 49 8b 34 24 48 c7 c7 40 89 0c 8d 8b 54 24 04 8b 4c 24 0c 44 8b 44 24 08 e8 32 78 db f7 90 <0f> 0b 90 90 e9 d3 fd ff ff 89 e9 80 e1 07 fe c1 38 c1 0f 8c ee f7 RSP: 0018:ffffc90003e4fda0 EFLAGS: 00010246 RAX: 099c6f938c7f4700 RBX: 1ffffffff1a595fd RCX: ffff888034823c00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 00000000ffffffe9 R08: ffffffff81567052 R09: 1ffff920007c9f50 R10: dffffc0000000000 R11: fffff520007c9f51 R12: ffffffff8d2cafe8 R13: 1ffffffff1a595fe R14: ffffffff9a789c40 R15: ffff8880764298c0 FS: 000055557b518380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa62ff43225 CR3: 0000000031628000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: sock_create net/socket.c:1616 [inline] __sys_socket_create net/socket.c:1653 [inline] __sys_socket+0x150/0x3c0 net/socket.c:1700 __do_sys_socket net/socket.c:1714 [inline] __se_sys_socket net/socket.c:1712 [inline] For reference, see commit 2d859aff775d (\"Merge branch 'do-not-leave-dangling-sk-pointers-in-pf-create-functions'\")", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50294", "url": "https://ubuntu.com/security/CVE-2024-50294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix missing locking causing hanging calls If a call gets aborted (e.g. because kafs saw a signal) between it being queued for connection and the I/O thread picking up the call, the abort will be prioritised over the connection and it will be removed from local->new_client_calls by rxrpc_disconnect_client_call() without a lock being held. This may cause other calls on the list to disappear if a race occurs. Fix this by taking the client_call_lock when removing a call from whatever list its ->wait_link happens to be on.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50295", "url": "https://ubuntu.com/security/CVE-2024-50295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: arc: fix the device for dma_map_single/dma_unmap_single The ndev->dev and pdev->dev aren't the same device, use ndev->dev.parent which has dma_mask, ndev->dev.parent is just pdev->dev. Or it would cause the following issue: [ 39.933526] ------------[ cut here ]------------ [ 39.938414] WARNING: CPU: 1 PID: 501 at kernel/dma/mapping.c:149 dma_map_page_attrs+0x90/0x1f8", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53082", "url": "https://ubuntu.com/security/CVE-2024-53082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_net: Add hash_key_length check Add hash_key_length check in virtnet_probe() to avoid possible out of bound errors when setting/reading the hash key.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50296", "url": "https://ubuntu.com/security/CVE-2024-50296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash when uninstalling driver When the driver is uninstalled and the VF is disabled concurrently, a kernel crash occurs. The reason is that the two actions call function pci_disable_sriov(). The num_VFs is checked to determine whether to release the corresponding resources. During the second calling, num_VFs is not 0 and the resource release function is called. However, the corresponding resource has been released during the first invoking. Therefore, the problem occurs: [15277.839633][T50670] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ... [15278.131557][T50670] Call trace: [15278.134686][T50670] klist_put+0x28/0x12c [15278.138682][T50670] klist_del+0x14/0x20 [15278.142592][T50670] device_del+0xbc/0x3c0 [15278.146676][T50670] pci_remove_bus_device+0x84/0x120 [15278.151714][T50670] pci_stop_and_remove_bus_device+0x6c/0x80 [15278.157447][T50670] pci_iov_remove_virtfn+0xb4/0x12c [15278.162485][T50670] sriov_disable+0x50/0x11c [15278.166829][T50670] pci_disable_sriov+0x24/0x30 [15278.171433][T50670] hnae3_unregister_ae_algo_prepare+0x60/0x90 [hnae3] [15278.178039][T50670] hclge_exit+0x28/0xd0 [hclge] [15278.182730][T50670] __se_sys_delete_module.isra.0+0x164/0x230 [15278.188550][T50670] __arm64_sys_delete_module+0x1c/0x30 [15278.193848][T50670] invoke_syscall+0x50/0x11c [15278.198278][T50670] el0_svc_common.constprop.0+0x158/0x164 [15278.203837][T50670] do_el0_svc+0x34/0xcc [15278.207834][T50670] el0_svc+0x20/0x30 For details, see the following figure. rmmod hclge disable VFs ---------------------------------------------------- hclge_exit() sriov_numvfs_store() ... device_lock() pci_disable_sriov() hns3_pci_sriov_configure() pci_disable_sriov() sriov_disable() sriov_disable() if !num_VFs : if !num_VFs : return; return; sriov_del_vfs() sriov_del_vfs() ... ... klist_put() klist_put() ... ... num_VFs = 0; num_VFs = 0; device_unlock(); In this patch, when driver is removing, we get the device_lock() to protect num_VFs, just like sriov_numvfs_store().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53088", "url": "https://ubuntu.com/security/CVE-2024-53088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: fix race condition by adding filter's intermediate sync state Fix a race condition in the i40e driver that leads to MAC/VLAN filters becoming corrupted and leaking. Address the issue that occurs under heavy load when multiple threads are concurrently modifying MAC/VLAN filters by setting mac and port VLAN. 1. Thread T0 allocates a filter in i40e_add_filter() within i40e_ndo_set_vf_port_vlan(). 2. Thread T1 concurrently frees the filter in __i40e_del_filter() within i40e_ndo_set_vf_mac(). 3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which refers to the already freed filter memory, causing corruption. Reproduction steps: 1. Spawn multiple VFs. 2. Apply a concurrent heavy load by running parallel operations to change MAC addresses on the VFs and change port VLANs on the host. 3. Observe errors in dmesg: \"Error I40E_AQ_RC_ENOSPC adding RX filters on VF XX, \tplease set promiscuous on manually for VF XX\". Exact code for stable reproduction Intel can't open-source now. The fix involves implementing a new intermediate filter state, I40E_FILTER_NEW_SYNC, for the time when a filter is on a tmp_add_list. These filters cannot be deleted from the hash list directly but must be removed using the full process.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50297", "url": "https://ubuntu.com/security/CVE-2024-50297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: xilinx: axienet: Enqueue Tx packets in dql before dmaengine starts Enqueue packets in dql after dma engine starts causes race condition. Tx transfer starts once dma engine is started and may execute dql dequeue in completion before it gets queued. It results in following kernel crash while running iperf stress test: kernel BUG at lib/dynamic_queue_limits.c:99! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP pc : dql_completed+0x238/0x248 lr : dql_completed+0x3c/0x248 Call trace: dql_completed+0x238/0x248 axienet_dma_tx_cb+0xa0/0x170 xilinx_dma_do_tasklet+0xdc/0x290 tasklet_action_common+0xf8/0x11c tasklet_action+0x30/0x3c handle_softirqs+0xf8/0x230 Start dmaengine after enqueue in dql fixes the crash.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50298", "url": "https://ubuntu.com/security/CVE-2024-50298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: enetc: allocate vf_state during PF probes In the previous implementation, vf_state is allocated memory only when VF is enabled. However, net_device_ops::ndo_set_vf_mac() may be called before VF is enabled to configure the MAC address of VF. If this is the case, enetc_pf_set_vf_mac() will access vf_state, resulting in access to a null pointer. The simplified error log is as follows. root@ls1028ardb:~# ip link set eno0 vf 1 mac 00:0c:e7:66:77:89 [ 173.543315] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 [ 173.637254] pc : enetc_pf_set_vf_mac+0x3c/0x80 Message from sy [ 173.641973] lr : do_setlink+0x4a8/0xec8 [ 173.732292] Call trace: [ 173.734740] enetc_pf_set_vf_mac+0x3c/0x80 [ 173.738847] __rtnl_newlink+0x530/0x89c [ 173.742692] rtnl_newlink+0x50/0x7c [ 173.746189] rtnetlink_rcv_msg+0x128/0x390 [ 173.750298] netlink_rcv_skb+0x60/0x130 [ 173.754145] rtnetlink_rcv+0x18/0x24 [ 173.757731] netlink_unicast+0x318/0x380 [ 173.761665] netlink_sendmsg+0x17c/0x3c8", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50299", "url": "https://ubuntu.com/security/CVE-2024-50299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: properly validate chunk size in sctp_sf_ootb() A size validation fix similar to that in Commit 50619dbf8db7 (\"sctp: add size validation when walking chunks\") is also required in sctp_sf_ootb() to address a crash reported by syzbot: BUG: KMSAN: uninit-value in sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_do_sm+0x181/0x93d0 net/sctp/sm_sideeffect.c:1166 sctp_endpoint_bh_rcv+0xc38/0xf90 net/sctp/endpointola.c:407 sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88 sctp_rcv+0x3831/0x3b20 net/sctp/input.c:243 sctp4_rcv+0x42/0x50 net/sctp/protocol.c:1159 ip_protocol_deliver_rcu+0xb51/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50300", "url": "https://ubuntu.com/security/CVE-2024-50300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: rtq2208: Fix uninitialized use of regulator_config Fix rtq2208 driver uninitialized use to cause kernel error.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50301", "url": "https://ubuntu.com/security/CVE-2024-50301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: security/keys: fix slab-out-of-bounds in key_task_permission KASAN reports an out of bounds read: BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline] BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362 CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0x107/0x167 lib/dump_stack.c:123 print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 __kuid_val include/linux/uidgid.h:36 [inline] uid_eq include/linux/uidgid.h:63 [inline] key_task_permission+0x394/0x410 security/keys/permission.c:54 search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793 This issue was also reported by syzbot. It can be reproduced by following these steps(more details [1]): 1. Obtain more than 32 inputs that have similar hashes, which ends with the pattern '0xxxxxxxe6'. 2. Reboot and add the keys obtained in step 1. The reproducer demonstrates how this issue happened: 1. In the search_nested_keyrings function, when it iterates through the slots in a node(below tag ascend_to_node), if the slot pointer is meta and node->back_pointer != NULL(it means a root), it will proceed to descend_to_node. However, there is an exception. If node is the root, and one of the slots points to a shortcut, it will be treated as a keyring. 2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function. However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as ASSOC_ARRAY_PTR_SUBTYPE_MASK. 3. When 32 keys with the similar hashes are added to the tree, the ROOT has keys with hashes that are not similar (e.g. slot 0) and it splits NODE A without using a shortcut. When NODE A is filled with keys that all hashes are xxe6, the keys are similar, NODE A will split with a shortcut. Finally, it forms the tree as shown below, where slot 6 points to a shortcut. NODE A +------>+---+ ROOT | | 0 | xxe6 +---+ | +---+ xxxx | 0 | shortcut : : xxe6 +---+ | +---+ xxe6 : : | | | xxe6 +---+ | +---+ | 6 |---+ : : xxe6 +---+ +---+ xxe6 : : | f | xxe6 +---+ +---+ xxe6 | f | +---+ 4. As mentioned above, If a slot(slot 6) of the root points to a shortcut, it may be mistakenly transferred to a key*, leading to a read out-of-bounds read. To fix this issue, one should jump to descend_to_node if the ptr is a shortcut, regardless of whether the node is root or not. [1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/ [jarkko: tweaked the commit message a bit to have an appropriate closes tag.]", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53072", "url": "https://ubuntu.com/security/CVE-2024-53072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/pmc: Detect when STB is not available Loading the amd_pmc module as: amd_pmc enable_stb=1 ...can result in the following messages in the kernel ring buffer: amd_pmc AMDI0009:00: SMU cmd failed. err: 0xff ioremap on RAM at 0x0000000000000000 - 0x0000000000ffffff WARNING: CPU: 10 PID: 2151 at arch/x86/mm/ioremap.c:217 __ioremap_caller+0x2cd/0x340 Further debugging reveals that this occurs when the requests for S2D_PHYS_ADDR_LOW and S2D_PHYS_ADDR_HIGH return a value of 0, indicating that the STB is inaccessible. To prevent the ioremap warning and provide clarity to the user, handle the invalid address and display an error message.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50302", "url": "https://ubuntu.com/security/CVE-2024-50302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: zero-initialize the report buffer Since the report buffer is used by all kinds of drivers in various ways, let's zero-initialize it during allocation to make sure that it can't be ever used to leak kernel memory via specially-crafted report.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53068", "url": "https://ubuntu.com/security/CVE-2024-53068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix slab-use-after-free in scmi_bus_notifier() The scmi_dev->name is released prematurely in __scmi_device_destroy(), which causes slab-use-after-free when accessing scmi_dev->name in scmi_bus_notifier(). So move the release of scmi_dev->name to scmi_device_release() to avoid slab-use-after-free. | BUG: KASAN: slab-use-after-free in strncmp+0xe4/0xec | Read of size 1 at addr ffffff80a482bcc0 by task swapper/0/1 | | CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.6.38-debug #1 | Hardware name: Qualcomm Technologies, Inc. SA8775P Ride (DT) | Call trace: | dump_backtrace+0x94/0x114 | show_stack+0x18/0x24 | dump_stack_lvl+0x48/0x60 | print_report+0xf4/0x5b0 | kasan_report+0xa4/0xec | __asan_report_load1_noabort+0x20/0x2c | strncmp+0xe4/0xec | scmi_bus_notifier+0x5c/0x54c | notifier_call_chain+0xb4/0x31c | blocking_notifier_call_chain+0x68/0x9c | bus_notify+0x54/0x78 | device_del+0x1bc/0x840 | device_unregister+0x20/0xb4 | __scmi_device_destroy+0xac/0x280 | scmi_device_destroy+0x94/0xd0 | scmi_chan_setup+0x524/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20 | | Allocated by task 1: | kasan_save_stack+0x2c/0x54 | kasan_set_track+0x2c/0x40 | kasan_save_alloc_info+0x24/0x34 | __kasan_kmalloc+0xa0/0xb8 | __kmalloc_node_track_caller+0x6c/0x104 | kstrdup+0x48/0x84 | kstrdup_const+0x34/0x40 | __scmi_device_create.part.0+0x8c/0x408 | scmi_device_create+0x104/0x370 | scmi_chan_setup+0x2a0/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20 | | Freed by task 1: | kasan_save_stack+0x2c/0x54 | kasan_set_track+0x2c/0x40 | kasan_save_free_info+0x38/0x5c | __kasan_slab_free+0xe8/0x164 | __kmem_cache_free+0x11c/0x230 | kfree+0x70/0x130 | kfree_const+0x20/0x40 | __scmi_device_destroy+0x70/0x280 | scmi_device_destroy+0x94/0xd0 | scmi_chan_setup+0x524/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53069", "url": "https://ubuntu.com/security/CVE-2024-53069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: qcom: scm: fix a NULL-pointer dereference Some SCM calls can be invoked with __scm being NULL (the driver may not have been and will not be probed as there's no SCM entry in device-tree). Make sure we don't dereference a NULL pointer.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50212", "url": "https://ubuntu.com/security/CVE-2024-50212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib: alloc_tag_module_unload must wait for pending kfree_rcu calls Ben Greear reports following splat: ------------[ cut here ]------------ net/netfilter/nf_nat_core.c:1114 module nf_nat func:nf_nat_register_fn has 256 allocated at module unload WARNING: CPU: 1 PID: 10421 at lib/alloc_tag.c:168 alloc_tag_module_unload+0x22b/0x3f0 Modules linked in: nf_nat(-) btrfs ufs qnx4 hfsplus hfs minix vfat msdos fat ... Hardware name: Default string Default string/SKYBAY, BIOS 5.12 08/04/2020 RIP: 0010:alloc_tag_module_unload+0x22b/0x3f0 codetag_unload_module+0x19b/0x2a0 ? codetag_load_module+0x80/0x80 nf_nat module exit calls kfree_rcu on those addresses, but the free operation is likely still pending by the time alloc_tag checks for leaks. Wait for outstanding kfree_rcu operations to complete before checking resolves this warning. Reproducer: unshare -n iptables-nft -t nat -A PREROUTING -p tcp grep nf_nat /proc/allocinfo # will list 4 allocations rmmod nft_chain_nat rmmod nf_nat # will WARN. [akpm@linux-foundation.org: add comment]", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53046", "url": "https://ubuntu.com/security/CVE-2024-53046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: dts: imx8ulp: correct the flexspi compatible string The flexspi on imx8ulp only has 16 LUTs, and imx8mm flexspi has 32 LUTs, so correct the compatible string here, otherwise will meet below error: [ 1.119072] ------------[ cut here ]------------ [ 1.123926] WARNING: CPU: 0 PID: 1 at drivers/spi/spi-nxp-fspi.c:855 nxp_fspi_exec_op+0xb04/0xb64 [ 1.133239] Modules linked in: [ 1.136448] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-rc6-next-20240902-00001-g131bf9439dd9 #69 [ 1.146821] Hardware name: NXP i.MX8ULP EVK (DT) [ 1.151647] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.158931] pc : nxp_fspi_exec_op+0xb04/0xb64 [ 1.163496] lr : nxp_fspi_exec_op+0xa34/0xb64 [ 1.168060] sp : ffff80008002b2a0 [ 1.171526] x29: ffff80008002b2d0 x28: 0000000000000000 x27: 0000000000000000 [ 1.179002] x26: ffff2eb645542580 x25: ffff800080610014 x24: ffff800080610000 [ 1.186480] x23: ffff2eb645548080 x22: 0000000000000006 x21: ffff2eb6455425e0 [ 1.193956] x20: 0000000000000000 x19: ffff80008002b5e0 x18: ffffffffffffffff [ 1.201432] x17: ffff2eb644467508 x16: 0000000000000138 x15: 0000000000000002 [ 1.208907] x14: 0000000000000000 x13: ffff2eb6400d8080 x12: 00000000ffffff00 [ 1.216378] x11: 0000000000000000 x10: ffff2eb6400d8080 x9 : ffff2eb697adca80 [ 1.223850] x8 : ffff2eb697ad3cc0 x7 : 0000000100000000 x6 : 0000000000000001 [ 1.231324] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000007a6 [ 1.238795] x2 : 0000000000000000 x1 : 00000000000001ce x0 : 00000000ffffff92 [ 1.246267] Call trace: [ 1.248824] nxp_fspi_exec_op+0xb04/0xb64 [ 1.253031] spi_mem_exec_op+0x3a0/0x430 [ 1.257139] spi_nor_read_id+0x80/0xcc [ 1.261065] spi_nor_scan+0x1ec/0xf10 [ 1.264901] spi_nor_probe+0x108/0x2fc [ 1.268828] spi_mem_probe+0x6c/0xbc [ 1.272574] spi_probe+0x84/0xe4 [ 1.275958] really_probe+0xbc/0x29c [ 1.279713] __driver_probe_device+0x78/0x12c [ 1.284277] driver_probe_device+0xd8/0x15c [ 1.288660] __device_attach_driver+0xb8/0x134 [ 1.293316] bus_for_each_drv+0x88/0xe8 [ 1.297337] __device_attach+0xa0/0x190 [ 1.301353] device_initial_probe+0x14/0x20 [ 1.305734] bus_probe_device+0xac/0xb0 [ 1.309752] device_add+0x5d0/0x790 [ 1.313408] __spi_add_device+0x134/0x204 [ 1.317606] of_register_spi_device+0x3b4/0x590 [ 1.322348] spi_register_controller+0x47c/0x754 [ 1.327181] devm_spi_register_controller+0x4c/0xa4 [ 1.332289] nxp_fspi_probe+0x1cc/0x2b0 [ 1.336307] platform_probe+0x68/0xc4 [ 1.340145] really_probe+0xbc/0x29c [ 1.343893] __driver_probe_device+0x78/0x12c [ 1.348457] driver_probe_device+0xd8/0x15c [ 1.352838] __driver_attach+0x90/0x19c [ 1.356857] bus_for_each_dev+0x7c/0xdc [ 1.360877] driver_attach+0x24/0x30 [ 1.364624] bus_add_driver+0xe4/0x208 [ 1.368552] driver_register+0x5c/0x124 [ 1.372573] __platform_driver_register+0x28/0x34 [ 1.377497] nxp_fspi_driver_init+0x1c/0x28 [ 1.381888] do_one_initcall+0x80/0x1c8 [ 1.385908] kernel_init_freeable+0x1c4/0x28c [ 1.390472] kernel_init+0x20/0x1d8 [ 1.394138] ret_from_fork+0x10/0x20 [ 1.397885] ---[ end trace 0000000000000000 ]--- [ 1.407908] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53052", "url": "https://ubuntu.com/security/CVE-2024-53052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/rw: fix missing NOWAIT check for O_DIRECT start write When io_uring starts a write, it'll call kiocb_start_write() to bump the super block rwsem, preventing any freezes from happening while that write is in-flight. The freeze side will grab that rwsem for writing, excluding any new writers from happening and waiting for existing writes to finish. But io_uring unconditionally uses kiocb_start_write(), which will block if someone is currently attempting to freeze the mount point. This causes a deadlock where freeze is waiting for previous writes to complete, but the previous writes cannot complete, as the task that is supposed to complete them is blocked waiting on starting a new write. This results in the following stuck trace showing that dependency with the write blocked starting a new write: task:fio state:D stack:0 pid:886 tgid:886 ppid:876 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_rwsem_wait+0x1e8/0x3f8 __percpu_down_read+0xe8/0x500 io_write+0xbb8/0xff8 io_issue_sqe+0x10c/0x1020 io_submit_sqes+0x614/0x2110 __arm64_sys_io_uring_enter+0x524/0x1038 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 INFO: task fsfreeze:7364 blocked for more than 15 seconds. Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963 with the attempting freezer stuck trying to grab the rwsem: task:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_down_write+0x2b0/0x680 freeze_super+0x248/0x8a8 do_vfs_ioctl+0x149c/0x1b18 __arm64_sys_ioctl+0xd0/0x1a0 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 Fix this by having the io_uring side honor IOCB_NOWAIT, and only attempt a blocking grab of the super block rwsem if it isn't set. For normal issue where IOCB_NOWAIT would always be set, this returns -EAGAIN which will have io_uring core issue a blocking attempt of the write. That will in turn also get completions run, ensuring forward progress. Since freezing requires CAP_SYS_ADMIN in the first place, this isn't something that can be triggered by a regular user.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50213", "url": "https://ubuntu.com/security/CVE-2024-50213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tests: hdmi: Fix memory leaks in drm_display_mode_from_cea_vic() modprobe drm_hdmi_state_helper_test and then rmmod it, the following memory leak occurs. The `mode` allocated in drm_mode_duplicate() called by drm_display_mode_from_cea_vic() is not freed, which cause the memory leak: \tunreferenced object 0xffffff80ccd18100 (size 128): \t comm \"kunit_try_catch\", pid 1851, jiffies 4295059695 \t hex dump (first 32 bytes): \t 57 62 00 00 80 02 90 02 f0 02 20 03 00 00 e0 01 Wb........ ..... \t ea 01 ec 01 0d 02 00 00 0a 00 00 00 00 00 00 00 ................ \t backtrace (crc c2f1aa95): \t [<000000000f10b11b>] kmemleak_alloc+0x34/0x40 \t [<000000001cd4cf73>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<00000000f1f3cffa>] drm_mode_duplicate+0x44/0x19c \t [<000000008cbeef13>] drm_display_mode_from_cea_vic+0x88/0x98 \t [<0000000019daaacf>] 0xffffffedc11ae69c \t [<000000000aad0f85>] kunit_try_run_case+0x13c/0x3ac \t [<00000000a9210bac>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<000000000a0b2e9e>] kthread+0x2e8/0x374 \t [<00000000bd668858>] ret_from_fork+0x10/0x20 \t...... Free `mode` by using drm_kunit_display_mode_from_cea_vic() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50214", "url": "https://ubuntu.com/security/CVE-2024-50214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/connector: hdmi: Fix memory leak in drm_display_mode_from_cea_vic() modprobe drm_connector_test and then rmmod drm_connector_test, the following memory leak occurs. The `mode` allocated in drm_mode_duplicate() called by drm_display_mode_from_cea_vic() is not freed, which cause the memory leak: \tunreferenced object 0xffffff80cb0ee400 (size 128): \t comm \"kunit_try_catch\", pid 1948, jiffies 4294950339 \t hex dump (first 32 bytes): \t 14 44 02 00 80 07 d8 07 04 08 98 08 00 00 38 04 .D............8. \t 3c 04 41 04 65 04 00 00 05 00 00 00 00 00 00 00 <.A.e........... \t backtrace (crc 90e9585c): \t [<00000000ec42e3d7>] kmemleak_alloc+0x34/0x40 \t [<00000000d0ef055a>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<00000000c2062161>] drm_mode_duplicate+0x44/0x19c \t [<00000000f96c74aa>] drm_display_mode_from_cea_vic+0x88/0x98 \t [<00000000d8f2c8b4>] 0xffffffdc982a4868 \t [<000000005d164dbc>] kunit_try_run_case+0x13c/0x3ac \t [<000000006fb23398>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<000000006ea56ca0>] kthread+0x2e8/0x374 \t [<000000000676063f>] ret_from_fork+0x10/0x20 \t...... Free `mode` by using drm_kunit_display_mode_from_cea_vic() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50215", "url": "https://ubuntu.com/security/CVE-2024-50215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: assign dh_key to NULL after kfree_sensitive ctrl->dh_key might be used across multiple calls to nvmet_setup_dhgroup() for the same controller. So it's better to nullify it after release on error path in order to avoid double free later in nvmet_destroy_auth(). Found by Linux Verification Center (linuxtesting.org) with Svace.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50216", "url": "https://ubuntu.com/security/CVE-2024-50216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix finding a last resort AG in xfs_filestream_pick_ag When the main loop in xfs_filestream_pick_ag fails to find a suitable AG it tries to just pick the online AG. But the loop for that uses args->pag as loop iterator while the later code expects pag to be set. Fix this by reusing the max_pag case for this last resort, and also add a check for impossible case of no AG just to make sure that the uninitialized pag doesn't even escape in theory.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50217", "url": "https://ubuntu.com/security/CVE-2024-50217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free of block device file in __btrfs_free_extra_devids() Mounting btrfs from two images (which have the same one fsid and two different dev_uuids) in certain executing order may trigger an UAF for variable 'device->bdev_file' in __btrfs_free_extra_devids(). And following are the details: 1. Attach image_1 to loop0, attach image_2 to loop1, and scan btrfs devices by ioctl(BTRFS_IOC_SCAN_DEV): / btrfs_device_1 ? loop0 fs_device \\ btrfs_device_2 ? loop1 2. mount /dev/loop0 /mnt btrfs_open_devices btrfs_device_1->bdev_file = btrfs_get_bdev_and_sb(loop0) btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree fail: btrfs_close_devices // -ENOMEM \t btrfs_close_bdev(btrfs_device_1) fput(btrfs_device_1->bdev_file) \t // btrfs_device_1->bdev_file is freed \t btrfs_close_bdev(btrfs_device_2) fput(btrfs_device_2->bdev_file) 3. mount /dev/loop1 /mnt btrfs_open_devices btrfs_get_bdev_and_sb(&bdev_file) // EIO, btrfs_device_1->bdev_file is not assigned, // which points to a freed memory area btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree btrfs_free_extra_devids if (btrfs_device_1->bdev_file) fput(btrfs_device_1->bdev_file) // UAF ! Fix it by setting 'device->bdev_file' as 'NULL' after closing the btrfs_device in btrfs_close_one_device().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53043", "url": "https://ubuntu.com/security/CVE-2024-53043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mctp i2c: handle NULL header address daddr can be NULL if there is no neighbour table entry present, in that case the tx packet should be dropped. saddr will usually be set by MCTP core, but check for NULL in case a packet is transmitted by a different protocol.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50303", "url": "https://ubuntu.com/security/CVE-2024-50303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: resource,kexec: walk_system_ram_res_rev must retain resource flags walk_system_ram_res_rev() erroneously discards resource flags when passing the information to the callback. This causes systems with IORESOURCE_SYSRAM_DRIVER_MANAGED memory to have these resources selected during kexec to store kexec buffers if that memory happens to be at placed above normal system ram. This leads to undefined behavior after reboot. If the kexec buffer is never touched, nothing happens. If the kexec buffer is touched, it could lead to a crash (like below) or undefined behavior. Tested on a system with CXL memory expanders with driver managed memory, TPM enabled, and CONFIG_IMA_KEXEC=y. Adding printk's showed the flags were being discarded and as a result the check for IORESOURCE_SYSRAM_DRIVER_MANAGED passes. find_next_iomem_res: name(System RAM (kmem)) \t\t start(10000000000) \t\t end(1034fffffff) \t\t flags(83000200) locate_mem_hole_top_down: start(10000000000) end(1034fffffff) flags(0) [.] BUG: unable to handle page fault for address: ffff89834ffff000 [.] #PF: supervisor read access in kernel mode [.] #PF: error_code(0x0000) - not-present page [.] PGD c04c8bf067 P4D c04c8bf067 PUD c04c8be067 PMD 0 [.] Oops: 0000 [#1] SMP [.] RIP: 0010:ima_restore_measurement_list+0x95/0x4b0 [.] RSP: 0018:ffffc900000d3a80 EFLAGS: 00010286 [.] RAX: 0000000000001000 RBX: 0000000000000000 RCX: ffff89834ffff000 [.] RDX: 0000000000000018 RSI: ffff89834ffff000 RDI: ffff89834ffff018 [.] RBP: ffffc900000d3ba0 R08: 0000000000000020 R09: ffff888132b8a900 [.] R10: 4000000000000000 R11: 000000003a616d69 R12: 0000000000000000 [.] R13: ffffffff8404ac28 R14: 0000000000000000 R15: ffff89834ffff000 [.] FS: 0000000000000000(0000) GS:ffff893d44640000(0000) knlGS:0000000000000000 [.] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [.] ata5: SATA link down (SStatus 0 SControl 300) [.] CR2: ffff89834ffff000 CR3: 000001034d00f001 CR4: 0000000000770ef0 [.] PKRU: 55555554 [.] Call Trace: [.] [.] ? __die+0x78/0xc0 [.] ? page_fault_oops+0x2a8/0x3a0 [.] ? exc_page_fault+0x84/0x130 [.] ? asm_exc_page_fault+0x22/0x30 [.] ? ima_restore_measurement_list+0x95/0x4b0 [.] ? template_desc_init_fields+0x317/0x410 [.] ? crypto_alloc_tfm_node+0x9c/0xc0 [.] ? init_ima_lsm+0x30/0x30 [.] ima_load_kexec_buffer+0x72/0xa0 [.] ima_init+0x44/0xa0 [.] __initstub__kmod_ima__373_1201_init_ima7+0x1e/0xb0 [.] ? init_ima_lsm+0x30/0x30 [.] do_one_initcall+0xad/0x200 [.] ? idr_alloc_cyclic+0xaa/0x110 [.] ? new_slab+0x12c/0x420 [.] ? new_slab+0x12c/0x420 [.] ? number+0x12a/0x430 [.] ? sysvec_apic_timer_interrupt+0xa/0x80 [.] ? asm_sysvec_apic_timer_interrupt+0x16/0x20 [.] ? parse_args+0xd4/0x380 [.] ? parse_args+0x14b/0x380 [.] kernel_init_freeable+0x1c1/0x2b0 [.] ? rest_init+0xb0/0xb0 [.] kernel_init+0x16/0x1a0 [.] ret_from_fork+0x2f/0x40 [.] ? rest_init+0xb0/0xb0 [.] ret_from_fork_asm+0x11/0x20 [.] ", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50218", "url": "https://ubuntu.com/security/CVE-2024-50218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow Syzbot reported a kernel BUG in ocfs2_truncate_inline. There are two reasons for this: first, the parameter value passed is greater than ocfs2_max_inline_data_with_xattr, second, the start and end parameters of ocfs2_truncate_inline are \"unsigned int\". So, we need to add a sanity check for byte_start and byte_len right before ocfs2_truncate_inline() in ocfs2_remove_inode_range(), if they are greater than ocfs2_max_inline_data_with_xattr return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50219", "url": "https://ubuntu.com/security/CVE-2024-50219", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50263", "url": "https://ubuntu.com/security/CVE-2024-50263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fork: only invoke khugepaged, ksm hooks if no error There is no reason to invoke these hooks early against an mm that is in an incomplete state. The change in commit d24062914837 (\"fork: use __mt_dup() to duplicate maple tree in dup_mmap()\") makes this more pertinent as we may be in a state where entries in the maple tree are not yet consistent. Their placement early in dup_mmap() only appears to have been meaningful for early error checking, and since functionally it'd require a very small allocation to fail (in practice 'too small to fail') that'd only occur in the most dire circumstances, meaning the fork would fail or be OOM'd in any case. Since both khugepaged and KSM tracking are there to provide optimisations to memory performance rather than critical functionality, it doesn't really matter all that much if, under such dire memory pressure, we fail to register an mm with these. As a result, we follow the example of commit d2081b2bf819 (\"mm: khugepaged: make khugepaged_enter() void function\") and make ksm_fork() a void function also. We only expose the mm to these functions once we are done with them and only if no error occurred in the fork operation.", "cve_priority": "medium", "cve_public_date": "2024-11-11 14:15:00 UTC" }, { "cve": "CVE-2024-50220", "url": "https://ubuntu.com/security/CVE-2024-50220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fork: do not invoke uffd on fork if error occurs Patch series \"fork: do not expose incomplete mm on fork\". During fork we may place the virtual memory address space into an inconsistent state before the fork operation is complete. In addition, we may encounter an error during the fork operation that indicates that the virtual memory address space is invalidated. As a result, we should not be exposing it in any way to external machinery that might interact with the mm or VMAs, machinery that is not designed to deal with incomplete state. We specifically update the fork logic to defer khugepaged and ksm to the end of the operation and only to be invoked if no error arose, and disallow uffd from observing fork events should an error have occurred. This patch (of 2): Currently on fork we expose the virtual address space of a process to userland unconditionally if uffd is registered in VMAs, regardless of whether an error arose in the fork. This is performed in dup_userfaultfd_complete() which is invoked unconditionally, and performs two duties - invoking registered handlers for the UFFD_EVENT_FORK event via dup_fctx(), and clearing down userfaultfd_fork_ctx objects established in dup_userfaultfd(). This is problematic, because the virtual address space may not yet be correctly initialised if an error arose. The change in commit d24062914837 (\"fork: use __mt_dup() to duplicate maple tree in dup_mmap()\") makes this more pertinent as we may be in a state where entries in the maple tree are not yet consistent. We address this by, on fork error, ensuring that we roll back state that we would otherwise expect to clean up through the event being handled by userland and perform the memory freeing duty otherwise performed by dup_userfaultfd_complete(). We do this by implementing a new function, dup_userfaultfd_fail(), which performs the same loop, only decrementing reference counts. Note that we perform mmgrab() on the parent and child mm's, however userfaultfd_ctx_put() will mmdrop() this once the reference count drops to zero, so we will avoid memory leaks correctly here.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53047", "url": "https://ubuntu.com/security/CVE-2024-53047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: init: protect sched with rcu_read_lock Enabling CONFIG_PROVE_RCU_LIST with its dependence CONFIG_RCU_EXPERT creates this splat when an MPTCP socket is created: ============================= WARNING: suspicious RCU usage 6.12.0-rc2+ #11 Not tainted ----------------------------- net/mptcp/sched.c:44 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 no locks held by mptcp_connect/176. stack backtrace: CPU: 0 UID: 0 PID: 176 Comm: mptcp_connect Not tainted 6.12.0-rc2+ #11 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl (lib/dump_stack.c:123) lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822) mptcp_sched_find (net/mptcp/sched.c:44 (discriminator 7)) mptcp_init_sock (net/mptcp/protocol.c:2867 (discriminator 1)) ? sock_init_data_uid (arch/x86/include/asm/atomic.h:28) inet_create.part.0.constprop.0 (net/ipv4/af_inet.c:386) ? __sock_create (include/linux/rcupdate.h:347 (discriminator 1)) __sock_create (net/socket.c:1576) __sys_socket (net/socket.c:1671) ? __pfx___sys_socket (net/socket.c:1712) ? do_user_addr_fault (arch/x86/mm/fault.c:1419 (discriminator 1)) __x64_sys_socket (net/socket.c:1728) do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) That's because when the socket is initialised, rcu_read_lock() is not used despite the explicit comment written above the declaration of mptcp_sched_find() in sched.c. Adding the missing lock/unlock avoids the warning.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50221", "url": "https://ubuntu.com/security/CVE-2024-50221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Vangogh: Fix kernel memory out of bounds write KASAN reports that the GPU metrics table allocated in vangogh_tables_init() is not large enough for the memset done in smu_cmn_init_soft_gpu_metrics(). Condensed report follows: [ 33.861314] BUG: KASAN: slab-out-of-bounds in smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu] [ 33.861799] Write of size 168 at addr ffff888129f59500 by task mangoapp/1067 ... [ 33.861808] CPU: 6 UID: 1000 PID: 1067 Comm: mangoapp Tainted: G W 6.12.0-rc4 #356 1a56f59a8b5182eeaf67eb7cb8b13594dd23b544 [ 33.861816] Tainted: [W]=WARN [ 33.861818] Hardware name: Valve Galileo/Galileo, BIOS F7G0107 12/01/2023 [ 33.861822] Call Trace: [ 33.861826] [ 33.861829] dump_stack_lvl+0x66/0x90 [ 33.861838] print_report+0xce/0x620 [ 33.861853] kasan_report+0xda/0x110 [ 33.862794] kasan_check_range+0xfd/0x1a0 [ 33.862799] __asan_memset+0x23/0x40 [ 33.862803] smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.863306] vangogh_get_gpu_metrics_v2_4+0x123/0xad0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.864257] vangogh_common_get_gpu_metrics+0xb0c/0xbc0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.865682] amdgpu_dpm_get_gpu_metrics+0xcc/0x110 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.866160] amdgpu_get_gpu_metrics+0x154/0x2d0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.867135] dev_attr_show+0x43/0xc0 [ 33.867147] sysfs_kf_seq_show+0x1f1/0x3b0 [ 33.867155] seq_read_iter+0x3f8/0x1140 [ 33.867173] vfs_read+0x76c/0xc50 [ 33.867198] ksys_read+0xfb/0x1d0 [ 33.867214] do_syscall_64+0x90/0x160 ... [ 33.867353] Allocated by task 378 on cpu 7 at 22.794876s: [ 33.867358] kasan_save_stack+0x33/0x50 [ 33.867364] kasan_save_track+0x17/0x60 [ 33.867367] __kasan_kmalloc+0x87/0x90 [ 33.867371] vangogh_init_smc_tables+0x3f9/0x840 [amdgpu] [ 33.867835] smu_sw_init+0xa32/0x1850 [amdgpu] [ 33.868299] amdgpu_device_init+0x467b/0x8d90 [amdgpu] [ 33.868733] amdgpu_driver_load_kms+0x19/0xf0 [amdgpu] [ 33.869167] amdgpu_pci_probe+0x2d6/0xcd0 [amdgpu] [ 33.869608] local_pci_probe+0xda/0x180 [ 33.869614] pci_device_probe+0x43f/0x6b0 Empirically we can confirm that the former allocates 152 bytes for the table, while the latter memsets the 168 large block. Root cause appears that when GPU metrics tables for v2_4 parts were added it was not considered to enlarge the table to fit. The fix in this patch is rather \"brute force\" and perhaps later should be done in a smarter way, by extracting and consolidating the part version to size logic to a common helper, instead of brute forcing the largest possible allocation. Nevertheless, for now this works and fixes the out of bounds write. v2: * Drop impossible v3_0 case. (Mario) (cherry picked from commit 0880f58f9609f0200483a49429af0f050d281703)", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50222", "url": "https://ubuntu.com/security/CVE-2024-50222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iov_iter: fix copy_page_from_iter_atomic() if KMAP_LOCAL_FORCE_MAP generic/077 on x86_32 CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP=y with highmem, on huge=always tmpfs, issues a warning and then hangs (interruptibly): WARNING: CPU: 5 PID: 3517 at mm/highmem.c:622 kunmap_local_indexed+0x62/0xc9 CPU: 5 UID: 0 PID: 3517 Comm: cp Not tainted 6.12.0-rc4 #2 ... copy_page_from_iter_atomic+0xa6/0x5ec generic_perform_write+0xf6/0x1b4 shmem_file_write_iter+0x54/0x67 Fix copy_page_from_iter_atomic() by limiting it in that case (include/linux/skbuff.h skb_frag_must_loop() does similar). But going forward, perhaps CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP is too surprising, has outlived its usefulness, and should just be removed?", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50223", "url": "https://ubuntu.com/security/CVE-2024-50223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/numa: Fix the potential null pointer dereference in task_numa_work() When running stress-ng-vm-segv test, we found a null pointer dereference error in task_numa_work(). Here is the backtrace: [323676.066985] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ...... [323676.067108] CPU: 35 PID: 2694524 Comm: stress-ng-vm-se ...... [323676.067113] pstate: 23401009 (nzCv daif +PAN -UAO +TCO +DIT +SSBS BTYPE=--) [323676.067115] pc : vma_migratable+0x1c/0xd0 [323676.067122] lr : task_numa_work+0x1ec/0x4e0 [323676.067127] sp : ffff8000ada73d20 [323676.067128] x29: ffff8000ada73d20 x28: 0000000000000000 x27: 000000003e89f010 [323676.067130] x26: 0000000000080000 x25: ffff800081b5c0d8 x24: ffff800081b27000 [323676.067133] x23: 0000000000010000 x22: 0000000104d18cc0 x21: ffff0009f7158000 [323676.067135] x20: 0000000000000000 x19: 0000000000000000 x18: ffff8000ada73db8 [323676.067138] x17: 0001400000000000 x16: ffff800080df40b0 x15: 0000000000000035 [323676.067140] x14: ffff8000ada73cc8 x13: 1fffe0017cc72001 x12: ffff8000ada73cc8 [323676.067142] x11: ffff80008001160c x10: ffff000be639000c x9 : ffff8000800f4ba4 [323676.067145] x8 : ffff000810375000 x7 : ffff8000ada73974 x6 : 0000000000000001 [323676.067147] x5 : 0068000b33e26707 x4 : 0000000000000001 x3 : ffff0009f7158000 [323676.067149] x2 : 0000000000000041 x1 : 0000000000004400 x0 : 0000000000000000 [323676.067152] Call trace: [323676.067153] vma_migratable+0x1c/0xd0 [323676.067155] task_numa_work+0x1ec/0x4e0 [323676.067157] task_work_run+0x78/0xd8 [323676.067161] do_notify_resume+0x1ec/0x290 [323676.067163] el0_svc+0x150/0x160 [323676.067167] el0t_64_sync_handler+0xf8/0x128 [323676.067170] el0t_64_sync+0x17c/0x180 [323676.067173] Code: d2888001 910003fd f9000bf3 aa0003f3 (f9401000) [323676.067177] SMP: stopping secondary CPUs [323676.070184] Starting crashdump kernel... stress-ng-vm-segv in stress-ng is used to stress test the SIGSEGV error handling function of the system, which tries to cause a SIGSEGV error on return from unmapping the whole address space of the child process. Normally this program will not cause kernel crashes. But before the munmap system call returns to user mode, a potential task_numa_work() for numa balancing could be added and executed. In this scenario, since the child process has no vma after munmap, the vma_next() in task_numa_work() will return a null pointer even if the vma iterator restarts from 0. Recheck the vma pointer before dereferencing it in task_numa_work().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53053", "url": "https://ubuntu.com/security/CVE-2024-53053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Fix another deadlock during RTC update If ufshcd_rtc_work calls ufshcd_rpm_put_sync() and the pm's usage_count is 0, we will enter the runtime suspend callback. However, the runtime suspend callback will wait to flush ufshcd_rtc_work, causing a deadlock. Replace ufshcd_rpm_put_sync() with ufshcd_rpm_put() to avoid the deadlock.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53075", "url": "https://ubuntu.com/security/CVE-2024-53075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv: Prevent a bad reference count on CPU nodes When populating cache leaves we previously fetched the CPU device node at the very beginning. But when ACPI is enabled we go through a specific branch which returns early and does not call 'of_node_put' for the node that was acquired. Since we are not using a CPU device node for the ACPI code anyways, we can simply move the initialization of it just passed the ACPI block, and we are guaranteed to have an 'of_node_put' call for the acquired node. This prevents a bad reference count of the CPU device node. Moreover, the previous function did not check for errors when acquiring the device node, so a return -ENOENT has been added for that case.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50224", "url": "https://ubuntu.com/security/CVE-2024-50224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: spi-fsl-dspi: Fix crash when not using GPIO chip select Add check for the return value of spi_get_csgpiod() to avoid passing a NULL pointer to gpiod_direction_output(), preventing a crash when GPIO chip select is not used. Fix below crash: [ 4.251960] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 4.260762] Mem abort info: [ 4.263556] ESR = 0x0000000096000004 [ 4.267308] EC = 0x25: DABT (current EL), IL = 32 bits [ 4.272624] SET = 0, FnV = 0 [ 4.275681] EA = 0, S1PTW = 0 [ 4.278822] FSC = 0x04: level 0 translation fault [ 4.283704] Data abort info: [ 4.286583] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 4.292074] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 4.297130] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 4.302445] [0000000000000000] user address but active_mm is swapper [ 4.308805] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 4.315072] Modules linked in: [ 4.318124] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc4-next-20241023-00008-ga20ec42c5fc1 #359 [ 4.328130] Hardware name: LS1046A QDS Board (DT) [ 4.332832] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 4.339794] pc : gpiod_direction_output+0x34/0x5c [ 4.344505] lr : gpiod_direction_output+0x18/0x5c [ 4.349208] sp : ffff80008003b8f0 [ 4.352517] x29: ffff80008003b8f0 x28: 0000000000000000 x27: ffffc96bcc7e9068 [ 4.359659] x26: ffffc96bcc6e00b0 x25: ffffc96bcc598398 x24: ffff447400132810 [ 4.366800] x23: 0000000000000000 x22: 0000000011e1a300 x21: 0000000000020002 [ 4.373940] x20: 0000000000000000 x19: 0000000000000000 x18: ffffffffffffffff [ 4.381081] x17: ffff44740016e600 x16: 0000000500000003 x15: 0000000000000007 [ 4.388221] x14: 0000000000989680 x13: 0000000000020000 x12: 000000000000001e [ 4.395362] x11: 0044b82fa09b5a53 x10: 0000000000000019 x9 : 0000000000000008 [ 4.402502] x8 : 0000000000000002 x7 : 0000000000000007 x6 : 0000000000000000 [ 4.409641] x5 : 0000000000000200 x4 : 0000000002000000 x3 : 0000000000000000 [ 4.416781] x2 : 0000000000022202 x1 : 0000000000000000 x0 : 0000000000000000 [ 4.423921] Call trace: [ 4.426362] gpiod_direction_output+0x34/0x5c (P) [ 4.431067] gpiod_direction_output+0x18/0x5c (L) [ 4.435771] dspi_setup+0x220/0x334", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50225", "url": "https://ubuntu.com/security/CVE-2024-50225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix error propagation of split bios The purpose of btrfs_bbio_propagate_error() shall be propagating an error of split bio to its original btrfs_bio, and tell the error to the upper layer. However, it's not working well on some cases. * Case 1. Immediate (or quick) end_bio with an error When btrfs sends btrfs_bio to mirrored devices, btrfs calls btrfs_bio_end_io() when all the mirroring bios are completed. If that btrfs_bio was split, it is from btrfs_clone_bioset and its end_io function is btrfs_orig_write_end_io. For this case, btrfs_bbio_propagate_error() accesses the orig_bbio's bio context to increase the error count. That works well in most cases. However, if the end_io is called enough fast, orig_bbio's (remaining part after split) bio context may not be properly set at that time. Since the bio context is set when the orig_bbio (the last btrfs_bio) is sent to devices, that might be too late for earlier split btrfs_bio's completion. That will result in NULL pointer dereference. That bug is easily reproducible by running btrfs/146 on zoned devices [1] and it shows the following trace. [1] You need raid-stripe-tree feature as it create \"-d raid0 -m raid1\" FS. BUG: kernel NULL pointer dereference, address: 0000000000000020 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 UID: 0 PID: 13 Comm: kworker/u32:1 Not tainted 6.11.0-rc7-BTRFS-ZNS+ #474 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Workqueue: writeback wb_workfn (flush-btrfs-5) RIP: 0010:btrfs_bio_end_io+0xae/0xc0 [btrfs] BTRFS error (device dm-0): bdev /dev/mapper/error-test errs: wr 2, rd 0, flush 0, corrupt 0, gen 0 RSP: 0018:ffffc9000006f248 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888005a7f080 RCX: ffffc9000006f1dc RDX: 0000000000000000 RSI: 000000000000000a RDI: ffff888005a7f080 RBP: ffff888011dfc540 R08: 0000000000000000 R09: 0000000000000001 R10: ffffffff82e508e0 R11: 0000000000000005 R12: ffff88800ddfbe58 R13: ffff888005a7f080 R14: ffff888005a7f158 R15: ffff888005a7f158 FS: 0000000000000000(0000) GS:ffff88803ea80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000020 CR3: 0000000002e22006 CR4: 0000000000370ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __die_body.cold+0x19/0x26 ? page_fault_oops+0x13e/0x2b0 ? _printk+0x58/0x73 ? do_user_addr_fault+0x5f/0x750 ? exc_page_fault+0x76/0x240 ? asm_exc_page_fault+0x22/0x30 ? btrfs_bio_end_io+0xae/0xc0 [btrfs] ? btrfs_log_dev_io_error+0x7f/0x90 [btrfs] btrfs_orig_write_end_io+0x51/0x90 [btrfs] dm_submit_bio+0x5c2/0xa50 [dm_mod] ? find_held_lock+0x2b/0x80 ? blk_try_enter_queue+0x90/0x1e0 __submit_bio+0xe0/0x130 ? ktime_get+0x10a/0x160 ? lockdep_hardirqs_on+0x74/0x100 submit_bio_noacct_nocheck+0x199/0x410 btrfs_submit_bio+0x7d/0x150 [btrfs] btrfs_submit_chunk+0x1a1/0x6d0 [btrfs] ? lockdep_hardirqs_on+0x74/0x100 ? __folio_start_writeback+0x10/0x2c0 btrfs_submit_bbio+0x1c/0x40 [btrfs] submit_one_bio+0x44/0x60 [btrfs] submit_extent_folio+0x13f/0x330 [btrfs] ? btrfs_set_range_writeback+0xa3/0xd0 [btrfs] extent_writepage_io+0x18b/0x360 [btrfs] extent_write_locked_range+0x17c/0x340 [btrfs] ? __pfx_end_bbio_data_write+0x10/0x10 [btrfs] run_delalloc_cow+0x71/0xd0 [btrfs] btrfs_run_delalloc_range+0x176/0x500 [btrfs] ? find_lock_delalloc_range+0x119/0x260 [btrfs] writepage_delalloc+0x2ab/0x480 [btrfs] extent_write_cache_pages+0x236/0x7d0 [btrfs] btrfs_writepages+0x72/0x130 [btrfs] do_writepages+0xd4/0x240 ? find_held_lock+0x2b/0x80 ? wbc_attach_and_unlock_inode+0x12c/0x290 ? wbc_attach_and_unlock_inode+0x12c/0x29 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53054", "url": "https://ubuntu.com/security/CVE-2024-53054", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50226", "url": "https://ubuntu.com/security/CVE-2024-50226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cxl/port: Fix use-after-free, permit out-of-order decoder shutdown In support of investigating an initialization failure report [1], cxl_test was updated to register mock memory-devices after the mock root-port/bus device had been registered. That led to cxl_test crashing with a use-after-free bug with the following signature: cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem0:decoder7.0 @ 0 next: cxl_switch_uport.0 nr_eps: 1 nr_targets: 1 cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem4:decoder14.0 @ 1 next: cxl_switch_uport.0 nr_eps: 2 nr_targets: 1 cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[0] = cxl_switch_dport.0 for mem0:decoder7.0 @ 0 1) cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[1] = cxl_switch_dport.4 for mem4:decoder14.0 @ 1 [..] cxld_unregister: cxl decoder14.0: cxl_region_decode_reset: cxl_region region3: mock_decoder_reset: cxl_port port3: decoder3.0 reset 2) mock_decoder_reset: cxl_port port3: decoder3.0: out of order reset, expected decoder3.1 cxl_endpoint_decoder_release: cxl decoder14.0: [..] cxld_unregister: cxl decoder7.0: 3) cxl_region_decode_reset: cxl_region region3: Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6bc3: 0000 [#1] PREEMPT SMP PTI [..] RIP: 0010:to_cxl_port+0x8/0x60 [cxl_core] [..] Call Trace: cxl_region_decode_reset+0x69/0x190 [cxl_core] cxl_region_detach+0xe8/0x210 [cxl_core] cxl_decoder_kill_region+0x27/0x40 [cxl_core] cxld_unregister+0x5d/0x60 [cxl_core] At 1) a region has been established with 2 endpoint decoders (7.0 and 14.0). Those endpoints share a common switch-decoder in the topology (3.0). At teardown, 2), decoder14.0 is the first to be removed and hits the \"out of order reset case\" in the switch decoder. The effect though is that region3 cleanup is aborted leaving it in-tact and referencing decoder14.0. At 3) the second attempt to teardown region3 trips over the stale decoder14.0 object which has long since been deleted. The fix here is to recognize that the CXL specification places no mandate on in-order shutdown of switch-decoders, the driver enforces in-order allocation, and hardware enforces in-order commit. So, rather than fail and leave objects dangling, always remove them. In support of making cxl_region_decode_reset() always succeed, cxl_region_invalidate_memregion() failures are turned into warnings. Crashing the kernel is ok there since system integrity is at risk if caches cannot be managed around physical address mutation events like CXL region destruction. A new device_for_each_child_reverse_from() is added to cleanup port->commit_end after all dependent decoders have been disabled. In other words if decoders are allocated 0->1->2 and disabled 1->2->0 then port->commit_end only decrements from 2 after 2 has been disabled, and it decrements all the way to zero since 1 was disabled previously.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50227", "url": "https://ubuntu.com/security/CVE-2024-50227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Fix KASAN reported stack out-of-bounds read in tb_retimer_scan() KASAN reported following issue: BUG: KASAN: stack-out-of-bounds in tb_retimer_scan+0xffe/0x1550 [thunderbolt] Read of size 4 at addr ffff88810111fc1c by task kworker/u56:0/11 CPU: 0 UID: 0 PID: 11 Comm: kworker/u56:0 Tainted: G U 6.11.0+ #1387 Tainted: [U]=USER Workqueue: thunderbolt0 tb_handle_hotplug [thunderbolt] Call Trace: dump_stack_lvl+0x6c/0x90 print_report+0xd1/0x630 kasan_report+0xdb/0x110 __asan_report_load4_noabort+0x14/0x20 tb_retimer_scan+0xffe/0x1550 [thunderbolt] tb_scan_port+0xa6f/0x2060 [thunderbolt] tb_handle_hotplug+0x17b1/0x3080 [thunderbolt] process_one_work+0x626/0x1100 worker_thread+0x6c8/0xfa0 kthread+0x2c8/0x3a0 ret_from_fork+0x3a/0x80 ret_from_fork_asm+0x1a/0x30 This happens because the loop variable still gets incremented by one so max becomes 3 instead of 2, and this makes the second loop read past the the array declared on the stack. Fix this by assigning to max directly in the loop body.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50228", "url": "https://ubuntu.com/security/CVE-2024-50228", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50229", "url": "https://ubuntu.com/security/CVE-2024-50229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential deadlock with newly created symlinks Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers memory reclamation involving the filesystem layer, which can result in circular lock dependencies among the reader/writer semaphore nilfs->ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the fs_reclaim pseudo lock. This is because after commit 21fc61c73c39 (\"don't put symlink bodies in pagecache into highmem\"), the gfp flags of the page cache for symbolic links are overwritten to GFP_KERNEL via inode_nohighmem(). This is not a problem for symlinks read from the backing device, because the __GFP_FS flag is dropped after inode_nohighmem() is called. However, when a new symlink is created with nilfs_symlink(), the gfp flags remain overwritten to GFP_KERNEL. Then, memory allocation called from page_symlink() etc. triggers memory reclamation including the FS layer, which may call nilfs_evict_inode() or nilfs_dirty_inode(). And these can cause a deadlock if they are called while nilfs->ns_segctor_sem is held: Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags of newly created symlinks in the same way that nilfs_new_inode() and __nilfs_read_inode() do, as a workaround until we adopt nofs allocation scope consistently or improve the locking constraints.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50230", "url": "https://ubuntu.com/security/CVE-2024-50230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug due to missing clearing of checked flag Syzbot reported that in directory operations after nilfs2 detects filesystem corruption and degrades to read-only, __block_write_begin_int(), which is called to prepare block writes, may fail the BUG_ON check for accesses exceeding the folio/page size, triggering a kernel bug. This was found to be because the \"checked\" flag of a page/folio was not cleared when it was discarded by nilfs2's own routine, which causes the sanity check of directory entries to be skipped when the directory page/folio is reloaded. So, fix that. This was necessary when the use of nilfs2's own page discard routine was applied to more than just metadata files.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50231", "url": "https://ubuntu.com/security/CVE-2024-50231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gts-helper: Fix memory leaks in iio_gts_build_avail_scale_table() modprobe iio-test-gts and rmmod it, then the following memory leak occurs: \tunreferenced object 0xffffff80c810be00 (size 64): \t comm \"kunit_try_catch\", pid 1654, jiffies 4294913981 \t hex dump (first 32 bytes): \t 02 00 00 00 08 00 00 00 20 00 00 00 40 00 00 00 ........ ...@... \t 80 00 00 00 00 02 00 00 00 04 00 00 00 08 00 00 ................ \t backtrace (crc a63d875e): \t [<0000000028c1b3c2>] kmemleak_alloc+0x34/0x40 \t [<000000001d6ecc87>] __kmalloc_noprof+0x2bc/0x3c0 \t [<00000000393795c1>] devm_iio_init_iio_gts+0x4b4/0x16f4 \t [<0000000071bb4b09>] 0xffffffdf052a62e0 \t [<000000000315bc18>] 0xffffffdf052a6488 \t [<00000000f9dc55b5>] kunit_try_run_case+0x13c/0x3ac \t [<00000000175a3fd4>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000f505065d>] kthread+0x2e8/0x374 \t [<00000000bbfb0e5d>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cbfe9e70 (size 16): \t comm \"kunit_try_catch\", pid 1658, jiffies 4294914015 \t hex dump (first 16 bytes): \t 10 00 00 00 40 00 00 00 80 00 00 00 00 00 00 00 ....@........... \t backtrace (crc 857f0cb4): \t [<0000000028c1b3c2>] kmemleak_alloc+0x34/0x40 \t [<000000001d6ecc87>] __kmalloc_noprof+0x2bc/0x3c0 \t [<00000000393795c1>] devm_iio_init_iio_gts+0x4b4/0x16f4 \t [<0000000071bb4b09>] 0xffffffdf052a62e0 \t [<000000007d089d45>] 0xffffffdf052a6864 \t [<00000000f9dc55b5>] kunit_try_run_case+0x13c/0x3ac \t [<00000000175a3fd4>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000f505065d>] kthread+0x2e8/0x374 \t [<00000000bbfb0e5d>] ret_from_fork+0x10/0x20 \t...... It includes 5*5 times \"size 64\" memory leaks, which correspond to 5 times test_init_iio_gain_scale() calls with gts_test_gains size 10 (10*size(int)) and gts_test_itimes size 5. It also includes 5*1 times \"size 16\" memory leak, which correspond to one time __test_init_iio_gain_scale() call with gts_test_gains_gain_low size 3 (3*size(int)) and gts_test_itimes size 5. The reason is that the per_time_gains[i] is not freed which is allocated in the \"gts->num_itime\" for loop in iio_gts_build_avail_scale_table().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53076", "url": "https://ubuntu.com/security/CVE-2024-53076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gts-helper: Fix memory leaks for the error path of iio_gts_build_avail_scale_table() If per_time_scales[i] or per_time_gains[i] kcalloc fails in the for loop of iio_gts_build_avail_scale_table(), the err_free_out will fail to call kfree() each time when i is reduced to 0, so all the per_time_scales[0] and per_time_gains[0] will not be freed, which will cause memory leaks. Fix it by checking if i >= 0.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50232", "url": "https://ubuntu.com/security/CVE-2024-50232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr() In the ad7124_write_raw() function, parameter val can potentially be zero. This may lead to a division by zero when DIV_ROUND_CLOSEST() is called within ad7124_set_channel_odr(). The ad7124_write_raw() function is invoked through the sequence: iio_write_channel_raw() -> iio_write_channel_attribute() -> iio_channel_write(), with no checks in place to ensure val is non-zero.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50233", "url": "https://ubuntu.com/security/CVE-2024-50233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: iio: frequency: ad9832: fix division by zero in ad9832_calc_freqreg() In the ad9832_write_frequency() function, clk_get_rate() might return 0. This can lead to a division by zero when calling ad9832_calc_freqreg(). The check if (fout > (clk_get_rate(st->mclk) / 2)) does not protect against the case when fout is 0. The ad9832_write_frequency() function is called from ad9832_write(), and fout is derived from a text buffer, which can contain any value.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53055", "url": "https://ubuntu.com/security/CVE-2024-53055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix 6 GHz scan construction If more than 255 colocated APs exist for the set of all APs found during 2.4/5 GHz scanning, then the 6 GHz scan construction will loop forever since the loop variable has type u8, which can never reach the number found when that's bigger than 255, and is stored in a u32 variable. Also move it into the loops to have a smaller scope. Using a u32 there is fine, we limit the number of APs in the scan list and each has a limit on the number of RNR entries due to the frame size. With a limit of 1000 scan results, a frame size upper bound of 4096 (really it's more like ~2300) and a TBTT entry size of at least 11, we get an upper bound for the number of ~372k, well in the bounds of a u32.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50234", "url": "https://ubuntu.com/security/CVE-2024-50234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlegacy: Clear stale interrupts before resuming device iwl4965 fails upon resume from hibernation on my laptop. The reason seems to be a stale interrupt which isn't being cleared out before interrupts are enabled. We end up with a race beween the resume trying to bring things back up, and the restart work (queued form the interrupt handler) trying to bring things down. Eventually the whole thing blows up. Fix the problem by clearing out any stale interrupts before interrupts get enabled during resume. Here's a debug log of the indicent: [ 12.042589] ieee80211 phy0: il_isr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000 [ 12.042625] ieee80211 phy0: il4965_irq_tasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000 [ 12.042651] iwl4965 0000:10:00.0: RF_KILL bit toggled to enable radio. [ 12.042653] iwl4965 0000:10:00.0: On demand firmware reload [ 12.042690] ieee80211 phy0: il4965_irq_tasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282 [ 12.052207] ieee80211 phy0: il4965_mac_start enter [ 12.052212] ieee80211 phy0: il_prep_station Add STA to driver ID 31: ff:ff:ff:ff:ff:ff [ 12.052244] ieee80211 phy0: il4965_set_hw_ready hardware ready [ 12.052324] ieee80211 phy0: il_apm_init Init card's basic functions [ 12.052348] ieee80211 phy0: il_apm_init L1 Enabled; Disabling L0S [ 12.055727] ieee80211 phy0: il4965_load_bsm Begin load bsm [ 12.056140] ieee80211 phy0: il4965_verify_bsm Begin verify bsm [ 12.058642] ieee80211 phy0: il4965_verify_bsm BSM bootstrap uCode image OK [ 12.058721] ieee80211 phy0: il4965_load_bsm BSM write complete, poll 1 iterations [ 12.058734] ieee80211 phy0: __il4965_up iwl4965 is coming up [ 12.058737] ieee80211 phy0: il4965_mac_start Start UP work done. [ 12.058757] ieee80211 phy0: __il4965_down iwl4965 is going down [ 12.058761] ieee80211 phy0: il_scan_cancel_timeout Scan cancel timeout [ 12.058762] ieee80211 phy0: il_do_scan_abort Not performing scan to abort [ 12.058765] ieee80211 phy0: il_clear_ucode_stations Clearing ucode stations in driver [ 12.058767] ieee80211 phy0: il_clear_ucode_stations No active stations found to be cleared [ 12.058819] ieee80211 phy0: _il_apm_stop Stop card, put in low power state [ 12.058827] ieee80211 phy0: _il_apm_stop_master stop master [ 12.058864] ieee80211 phy0: il4965_clear_free_frames 0 frames on pre-allocated heap on clear. [ 12.058869] ieee80211 phy0: Hardware restart was requested [ 16.132299] iwl4965 0000:10:00.0: START_ALIVE timeout after 4000ms. [ 16.132303] ------------[ cut here ]------------ [ 16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue. [ 16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132390] Modules linked in: ctr ccm sch_fq_codel xt_tcpudp xt_multiport xt_state iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables binfmt_misc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdh_generic ecc iTCO_wdt i2c_dev iwl4965 iwlegacy coretemp snd_hda_codec_analog pcspkr psmouse mac80211 snd_hda_codec_generic libarc4 sdhci_pci cqhci sha256_generic sdhci libsha256 firewire_ohci snd_hda_intel snd_intel_dspcfg mmc_core snd_hda_codec snd_hwdep firewire_core led_class iosf_mbi snd_hda_core uhci_hcd lpc_ich crc_itu_t cfg80211 ehci_pci ehci_hcd snd_pcm usbcore mfd_core rfkill snd_timer snd usb_common soundcore video parport_pc parport intel_agp wmi intel_gtt backlight e1000e agpgart evdev [ 16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143 [ 16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010 [ 16.132463] Workqueue: async async_run_entry_fn [ 16.132469] RIP: 0010:ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132501] Code: da 02 00 0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50235", "url": "https://ubuntu.com/security/CVE-2024-50235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: clear wdev->cqm_config pointer on free When we free wdev->cqm_config when unregistering, we also need to clear out the pointer since the same wdev/netdev may get re-registered in another network namespace, then destroyed later, running this code again, which results in a double-free.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50236", "url": "https://ubuntu.com/security/CVE-2024-50236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: Fix memory leak in management tx In the current logic, memory is allocated for storing the MSDU context during management packet TX but this memory is not being freed during management TX completion. Similar leaks are seen in the management TX cleanup logic. Kmemleak reports this problem as below, unreferenced object 0xffffff80b64ed250 (size 16): comm \"kworker/u16:7\", pid 148, jiffies 4294687130 (age 714.199s) hex dump (first 16 bytes): 00 2b d8 d8 80 ff ff ff c4 74 e9 fd 07 00 00 00 .+.......t...... backtrace: [] __kmem_cache_alloc_node+0x1e4/0x2d8 [] kmalloc_trace+0x48/0x110 [] ath10k_wmi_tlv_op_gen_mgmt_tx_send+0xd4/0x1d8 [ath10k_core] [] ath10k_mgmt_over_wmi_tx_work+0x134/0x298 [ath10k_core] [] process_scheduled_works+0x1ac/0x400 [] worker_thread+0x208/0x328 [] kthread+0x100/0x1c0 [] ret_from_fork+0x10/0x20 Free the memory during completion and cleanup to fix the leak. Protect the mgmt_pending_tx idr_remove() operation in ath10k_wmi_tlv_op_cleanup_mgmt_tx_send() using ar->data_lock similar to other instances. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50237", "url": "https://ubuntu.com/security/CVE-2024-50237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower Avoid potentially crashing in the driver because of uninitialized private data", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50238", "url": "https://ubuntu.com/security/CVE-2024-50238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usbc: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data from the qcom-qmp-usb driver, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. This bug was later reproduced when the driver was copied to create the qmp-usbc driver. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with these drivers.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50239", "url": "https://ubuntu.com/security/CVE-2024-50239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usb-legacy: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data from the qcom-qmp-usb driver, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. This bug was later reproduced when the driver was copied to create the qmp-usb-legacy driver. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with these drivers.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50240", "url": "https://ubuntu.com/security/CVE-2024-50240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usb: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with this driver.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53077", "url": "https://ubuntu.com/security/CVE-2024-53077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpcrdma: Always release the rpcrdma_device's xa_array Dai pointed out that the xa_init_flags() in rpcrdma_add_one() needs to have a matching xa_destroy() in rpcrdma_remove_one() to release underlying memory that the xarray might have accrued during operation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50242", "url": "https://ubuntu.com/security/CVE-2024-50242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ntfs_file_release", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50243", "url": "https://ubuntu.com/security/CVE-2024-50243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix general protection fault in run_is_mapped_full Fixed deleating of a non-resident attribute in ntfs_create_inode() rollback.", "cve_priority": "low", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50244", "url": "https://ubuntu.com/security/CVE-2024-50244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ni_clear() Checking of NTFS_FLAGS_LOG_REPLAYING added to prevent access to uninitialized bitmap during replay process.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50245", "url": "https://ubuntu.com/security/CVE-2024-50245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix possible deadlock in mi_read Mutex lock with another subclass used in ni_lock_dir().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50246", "url": "https://ubuntu.com/security/CVE-2024-50246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Add rough attr alloc_size check", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50247", "url": "https://ubuntu.com/security/CVE-2024-50247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Check if more than chunk-size bytes are written A incorrectly formatted chunk may decompress into more than LZNT_CHUNK_SIZE bytes and a index out of bounds will occur in s_max_off.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50248", "url": "https://ubuntu.com/security/CVE-2024-50248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Add bounds checking to mi_enum_attr() Added bounds checking to make sure that every attr don't stray beyond valid memory region.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53078", "url": "https://ubuntu.com/security/CVE-2024-53078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Fix NULL vs IS_ERR() check in probe() The iommu_paging_domain_alloc() function doesn't return NULL pointers, it returns error pointers. Update the check to match.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53056", "url": "https://ubuntu.com/security/CVE-2024-53056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Fix potential NULL dereference in mtk_crtc_destroy() In mtk_crtc_create(), if the call to mbox_request_channel() fails then we set the \"mtk_crtc->cmdq_client.chan\" pointer to NULL. In that situation, we do not call cmdq_pkt_create(). During the cleanup, we need to check if the \"mtk_crtc->cmdq_client.chan\" is NULL first before calling cmdq_pkt_destroy(). Calling cmdq_pkt_destroy() is unnecessary if we didn't call cmdq_pkt_create() and it will result in a NULL pointer dereference.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50249", "url": "https://ubuntu.com/security/CVE-2024-50249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Make rmw_lock a raw_spin_lock The following BUG was triggered: ============================= [ BUG: Invalid wait context ] 6.12.0-rc2-XXX #406 Not tainted ----------------------------- kworker/1:1/62 is trying to lock: ffffff8801593030 (&cpc_ptr->rmw_lock){+.+.}-{3:3}, at: cpc_write+0xcc/0x370 other info that might help us debug this: context-{5:5} 2 locks held by kworker/1:1/62: #0: ffffff897ef5ec98 (&rq->__lock){-.-.}-{2:2}, at: raw_spin_rq_lock_nested+0x2c/0x50 #1: ffffff880154e238 (&sg_policy->update_lock){....}-{2:2}, at: sugov_update_shared+0x3c/0x280 stack backtrace: CPU: 1 UID: 0 PID: 62 Comm: kworker/1:1 Not tainted 6.12.0-rc2-g9654bd3e8806 #406 Workqueue: 0x0 (events) Call trace: dump_backtrace+0xa4/0x130 show_stack+0x20/0x38 dump_stack_lvl+0x90/0xd0 dump_stack+0x18/0x28 __lock_acquire+0x480/0x1ad8 lock_acquire+0x114/0x310 _raw_spin_lock+0x50/0x70 cpc_write+0xcc/0x370 cppc_set_perf+0xa0/0x3a8 cppc_cpufreq_fast_switch+0x40/0xc0 cpufreq_driver_fast_switch+0x4c/0x218 sugov_update_shared+0x234/0x280 update_load_avg+0x6ec/0x7b8 dequeue_entities+0x108/0x830 dequeue_task_fair+0x58/0x408 __schedule+0x4f0/0x1070 schedule+0x54/0x130 worker_thread+0xc0/0x2e8 kthread+0x130/0x148 ret_from_fork+0x10/0x20 sugov_update_shared() locks a raw_spinlock while cpc_write() locks a spinlock. To have a correct wait-type order, update rmw_lock to a raw spinlock and ensure that interrupts will be disabled on the CPU holding it. [ rjw: Changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50250", "url": "https://ubuntu.com/security/CVE-2024-50250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fsdax: dax_unshare_iter needs to copy entire blocks The code that copies data from srcmap to iomap in dax_unshare_iter is very very broken, which bfoster's recent fsx changes have exposed. If the pos and len passed to dax_file_unshare are not aligned to an fsblock boundary, the iter pos and length in the _iter function will reflect this unalignment. dax_iomap_direct_access always returns a pointer to the start of the kmapped fsdax page, even if its pos argument is in the middle of that page. This is catastrophic for data integrity when iter->pos is not aligned to a page, because daddr/saddr do not point to the same byte in the file as iter->pos. Hence we corrupt user data by copying it to the wrong place. If iter->pos + iomap_length() in the _iter function not aligned to a page, then we fail to copy a full block, and only partially populate the destination block. This is catastrophic for data confidentiality because we expose stale pmem contents. Fix both of these issues by aligning copy_pos/copy_len to a page boundary (remember, this is fsdax so 1 fsblock == 1 base page) so that we always copy full blocks. We're not done yet -- there's no call to invalidate_inode_pages2_range, so programs that have the file range mmap'd will continue accessing the old memory mapping after the file metadata updates have completed. Be careful with the return value -- if the unshare succeeds, we still need to return the number of bytes that the iomap iter thinks we're operating on.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50251", "url": "https://ubuntu.com/security/CVE-2024-50251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_payload: sanitize offset and length before calling skb_checksum() If access to offset + length is larger than the skbuff length, then skb_checksum() triggers BUG_ON(). skb_checksum() internally subtracts the length parameter while iterating over skbuff, BUG_ON(len) at the end of it checks that the expected length to be included in the checksum calculation is fully consumed.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50252", "url": "https://ubuntu.com/security/CVE-2024-50252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_ipip: Fix memory leak when changing remote IPv6 address The device stores IPv6 addresses that are used for encapsulation in linear memory that is managed by the driver. Changing the remote address of an ip6gre net device never worked properly, but since cited commit the following reproducer [1] would result in a warning [2] and a memory leak [3]. The problem is that the new remote address is never added by the driver to its hash table (and therefore the device) and the old address is never removed from it. Fix by programming the new address when the configuration of the ip6gre net device changes and removing the old one. If the address did not change, then the above would result in increasing the reference count of the address and then decreasing it. [1] # ip link add name bla up type ip6gre local 2001:db8:1::1 remote 2001:db8:2::1 tos inherit ttl inherit # ip link set dev bla type ip6gre remote 2001:db8:3::1 # ip link del dev bla # devlink dev reload pci/0000:01:00.0 [2] WARNING: CPU: 0 PID: 1682 at drivers/net/ethernet/mellanox/mlxsw/spectrum.c:3002 mlxsw_sp_ipv6_addr_put+0x140/0x1d0 Modules linked in: CPU: 0 UID: 0 PID: 1682 Comm: ip Not tainted 6.12.0-rc3-custom-g86b5b55bc835 #151 Hardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023 RIP: 0010:mlxsw_sp_ipv6_addr_put+0x140/0x1d0 [...] Call Trace: mlxsw_sp_router_netdevice_event+0x55f/0x1240 notifier_call_chain+0x5a/0xd0 call_netdevice_notifiers_info+0x39/0x90 unregister_netdevice_many_notify+0x63e/0x9d0 rtnl_dellink+0x16b/0x3a0 rtnetlink_rcv_msg+0x142/0x3f0 netlink_rcv_skb+0x50/0x100 netlink_unicast+0x242/0x390 netlink_sendmsg+0x1de/0x420 ____sys_sendmsg+0x2bd/0x320 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xd0 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f [3] unreferenced object 0xffff898081f597a0 (size 32): comm \"ip\", pid 1626, jiffies 4294719324 hex dump (first 32 bytes): 20 01 0d b8 00 02 00 00 00 00 00 00 00 00 00 01 ............... 21 49 61 83 80 89 ff ff 00 00 00 00 01 00 00 00 !Ia............. backtrace (crc fd9be911): [<00000000df89c55d>] __kmalloc_cache_noprof+0x1da/0x260 [<00000000ff2a1ddb>] mlxsw_sp_ipv6_addr_kvdl_index_get+0x281/0x340 [<000000009ddd445d>] mlxsw_sp_router_netdevice_event+0x47b/0x1240 [<00000000743e7757>] notifier_call_chain+0x5a/0xd0 [<000000007c7b9e13>] call_netdevice_notifiers_info+0x39/0x90 [<000000002509645d>] register_netdevice+0x5f7/0x7a0 [<00000000c2e7d2a9>] ip6gre_newlink_common.isra.0+0x65/0x130 [<0000000087cd6d8d>] ip6gre_newlink+0x72/0x120 [<000000004df7c7cc>] rtnl_newlink+0x471/0xa20 [<0000000057ed632a>] rtnetlink_rcv_msg+0x142/0x3f0 [<0000000032e0d5b5>] netlink_rcv_skb+0x50/0x100 [<00000000908bca63>] netlink_unicast+0x242/0x390 [<00000000cdbe1c87>] netlink_sendmsg+0x1de/0x420 [<0000000011db153e>] ____sys_sendmsg+0x2bd/0x320 [<000000003b6d53eb>] ___sys_sendmsg+0x9a/0xe0 [<00000000cae27c62>] __sys_sendmsg+0x7a/0xd0", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50253", "url": "https://ubuntu.com/security/CVE-2024-50253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check the validity of nr_words in bpf_iter_bits_new() Check the validity of nr_words in bpf_iter_bits_new(). Without this check, when multiplication overflow occurs for nr_bits (e.g., when nr_words = 0x0400-0001, nr_bits becomes 64), stack corruption may occur due to bpf_probe_read_kernel_common(..., nr_bytes = 0x2000-0008). Fix it by limiting the maximum value of nr_words to 511. The value is derived from the current implementation of BPF memory allocator. To ensure compatibility if the BPF memory allocator's size limitation changes in the future, use the helper bpf_mem_alloc_check_size() to check whether nr_bytes is too larger. And return -E2BIG instead of -ENOMEM for oversized nr_bytes.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50254", "url": "https://ubuntu.com/security/CVE-2024-50254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free dynamically allocated bits in bpf_iter_bits_destroy() bpf_iter_bits_destroy() uses \"kit->nr_bits <= 64\" to check whether the bits are dynamically allocated. However, the check is incorrect and may cause a kmemleak as shown below: unreferenced object 0xffff88812628c8c0 (size 32): comm \"swapper/0\", pid 1, jiffies 4294727320 hex dump (first 32 bytes): \tb0 c1 55 f5 81 88 ff ff f0 f0 f0 f0 f0 f0 f0 f0 ..U........... \tf0 f0 f0 f0 f0 f0 f0 f0 00 00 00 00 00 00 00 00 .............. backtrace (crc 781e32cc): \t[<00000000c452b4ab>] kmemleak_alloc+0x4b/0x80 \t[<0000000004e09f80>] __kmalloc_node_noprof+0x480/0x5c0 \t[<00000000597124d6>] __alloc.isra.0+0x89/0xb0 \t[<000000004ebfffcd>] alloc_bulk+0x2af/0x720 \t[<00000000d9c10145>] prefill_mem_cache+0x7f/0xb0 \t[<00000000ff9738ff>] bpf_mem_alloc_init+0x3e2/0x610 \t[<000000008b616eac>] bpf_global_ma_init+0x19/0x30 \t[<00000000fc473efc>] do_one_initcall+0xd3/0x3c0 \t[<00000000ec81498c>] kernel_init_freeable+0x66a/0x940 \t[<00000000b119f72f>] kernel_init+0x20/0x160 \t[<00000000f11ac9a7>] ret_from_fork+0x3c/0x70 \t[<0000000004671da4>] ret_from_fork_asm+0x1a/0x30 That is because nr_bits will be set as zero in bpf_iter_bits_next() after all bits have been iterated. Fix the issue by setting kit->bit to kit->nr_bits instead of setting kit->nr_bits to zero when the iteration completes in bpf_iter_bits_next(). In addition, use \"!nr_bits || bits >= nr_bits\" to check whether the iteration is complete and still use \"nr_bits > 64\" to indicate whether bits are dynamically allocated. The \"!nr_bits\" check is necessary because bpf_iter_bits_new() may fail before setting kit->nr_bits, and this condition will stop the iteration early instead of accessing the zeroed or freed kit->bits. Considering the initial value of kit->bits is -1 and the type of kit->nr_bits is unsigned int, change the type of kit->nr_bits to int. The potential overflow problem will be handled in the following patch.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50255", "url": "https://ubuntu.com/security/CVE-2024-50255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci: fix null-ptr-deref in hci_read_supported_codecs Fix __hci_cmd_sync_sk() to return not NULL for unknown opcodes. __hci_cmd_sync_sk() returns NULL if a command returns a status event. However, it also returns NULL where an opcode doesn't exist in the hci_cc table because hci_cmd_complete_evt() assumes status = skb->data[0] for unknown opcodes. This leads to null-ptr-deref in cmd_sync for HCI_OP_READ_LOCAL_CODECS as there is no hci_cc for HCI_OP_READ_LOCAL_CODECS, which always assumes status = skb->data[0]. KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077] CPU: 1 PID: 2000 Comm: kworker/u9:5 Not tainted 6.9.0-ga6bcb805883c-dirty #10 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: hci7 hci_power_on RIP: 0010:hci_read_supported_codecs+0xb9/0x870 net/bluetooth/hci_codec.c:138 Code: 08 48 89 ef e8 b8 c1 8f fd 48 8b 75 00 e9 96 00 00 00 49 89 c6 48 ba 00 00 00 00 00 fc ff df 4c 8d 60 70 4c 89 e3 48 c1 eb 03 <0f> b6 04 13 84 c0 0f 85 82 06 00 00 41 83 3c 24 02 77 0a e8 bf 78 RSP: 0018:ffff888120bafac8 EFLAGS: 00010212 RAX: 0000000000000000 RBX: 000000000000000e RCX: ffff8881173f0040 RDX: dffffc0000000000 RSI: ffffffffa58496c0 RDI: ffff88810b9ad1e4 RBP: ffff88810b9ac000 R08: ffffffffa77882a7 R09: 1ffffffff4ef1054 R10: dffffc0000000000 R11: fffffbfff4ef1055 R12: 0000000000000070 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88810b9ac000 FS: 0000000000000000(0000) GS:ffff8881f6c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6ddaa3439e CR3: 0000000139764003 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: hci_read_local_codecs_sync net/bluetooth/hci_sync.c:4546 [inline] hci_init_stage_sync net/bluetooth/hci_sync.c:3441 [inline] hci_init4_sync net/bluetooth/hci_sync.c:4706 [inline] hci_init_sync net/bluetooth/hci_sync.c:4742 [inline] hci_dev_init_sync net/bluetooth/hci_sync.c:4912 [inline] hci_dev_open_sync+0x19a9/0x2d30 net/bluetooth/hci_sync.c:4994 hci_dev_do_open net/bluetooth/hci_core.c:483 [inline] hci_power_on+0x11e/0x560 net/bluetooth/hci_core.c:1015 process_one_work kernel/workqueue.c:3267 [inline] process_scheduled_works+0x8ef/0x14f0 kernel/workqueue.c:3348 worker_thread+0x91f/0xe50 kernel/workqueue.c:3429 kthread+0x2cb/0x360 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50256", "url": "https://ubuntu.com/security/CVE-2024-50256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6() I got a syzbot report without a repro [1] crashing in nf_send_reset6() I think the issue is that dev->hard_header_len is zero, and we attempt later to push an Ethernet header. Use LL_MAX_HEADER, as other functions in net/ipv6/netfilter/nf_reject_ipv6.c. [1] skbuff: skb_under_panic: text:ffffffff89b1d008 len:74 put:14 head:ffff88803123aa00 data:ffff88803123a9f2 tail:0x3c end:0x140 dev:syz_tun kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 UID: 0 PID: 7373 Comm: syz.1.568 Not tainted 6.12.0-rc2-syzkaller-00631-g6d858708d465 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:skb_panic net/core/skbuff.c:206 [inline] RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216 Code: 0d 8d 48 c7 c6 60 a6 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 ba 30 38 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP: 0018:ffffc900045269b0 EFLAGS: 00010282 RAX: 0000000000000088 RBX: dffffc0000000000 RCX: cd66dacdc5d8e800 RDX: 0000000000000000 RSI: 0000000000000200 RDI: 0000000000000000 RBP: ffff88802d39a3d0 R08: ffffffff8174afec R09: 1ffff920008a4ccc R10: dffffc0000000000 R11: fffff520008a4ccd R12: 0000000000000140 R13: ffff88803123aa00 R14: ffff88803123a9f2 R15: 000000000000003c FS: 00007fdbee5ff6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000005d322000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: skb_push+0xe5/0x100 net/core/skbuff.c:2636 eth_header+0x38/0x1f0 net/ethernet/eth.c:83 dev_hard_header include/linux/netdevice.h:3208 [inline] nf_send_reset6+0xce6/0x1270 net/ipv6/netfilter/nf_reject_ipv6.c:358 nft_reject_inet_eval+0x3b9/0x690 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x418/0x6b0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] br_nf_pre_routing_ipv6+0x63e/0x770 net/bridge/br_netfilter_ipv6.c:184 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_bridge_pre net/bridge/br_input.c:277 [inline] br_handle_frame+0x9fd/0x1530 net/bridge/br_input.c:424 __netif_receive_skb_core+0x13e8/0x4570 net/core/dev.c:5562 __netif_receive_skb_one_core net/core/dev.c:5666 [inline] __netif_receive_skb+0x12f/0x650 net/core/dev.c:5781 netif_receive_skb_internal net/core/dev.c:5867 [inline] netif_receive_skb+0x1e8/0x890 net/core/dev.c:5926 tun_rx_batched+0x1b7/0x8f0 drivers/net/tun.c:1550 tun_get_user+0x3056/0x47e0 drivers/net/tun.c:2007 tun_chr_write_iter+0x10d/0x1f0 drivers/net/tun.c:2053 new_sync_write fs/read_write.c:590 [inline] vfs_write+0xa6d/0xc90 fs/read_write.c:683 ksys_write+0x183/0x2b0 fs/read_write.c:736 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:0x7fdbeeb7d1ff Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 c9 8d 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 1c 8e 02 00 48 RSP: 002b:00007fdbee5ff000 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fdbeed36058 RCX: 00007fdbeeb7d1ff RDX: 000000000000008e RSI: 0000000020000040 RDI: 00000000000000c8 RBP: 00007fdbeebf12be R08: 0000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50257", "url": "https://ubuntu.com/security/CVE-2024-50257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: Fix use-after-free in get_info() ip6table_nat module unload has refcnt warning for UAF. call trace is: WARNING: CPU: 1 PID: 379 at kernel/module/main.c:853 module_put+0x6f/0x80 Modules linked in: ip6table_nat(-) CPU: 1 UID: 0 PID: 379 Comm: ip6tables Not tainted 6.12.0-rc4-00047-gc2ee9f594da8-dirty #205 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:module_put+0x6f/0x80 Call Trace: get_info+0x128/0x180 do_ip6t_get_ctl+0x6a/0x430 nf_getsockopt+0x46/0x80 ipv6_getsockopt+0xb9/0x100 rawv6_getsockopt+0x42/0x190 do_sock_getsockopt+0xaa/0x180 __sys_getsockopt+0x70/0xc0 __x64_sys_getsockopt+0x20/0x30 do_syscall_64+0xa2/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Concurrent execution of module unload and get_info() trigered the warning. The root cause is as follows: cpu0\t\t\t\t cpu1 module_exit //mod->state = MODULE_STATE_GOING ip6table_nat_exit xt_unregister_template \tkfree(t) \t//removed from templ_list \t\t\t\t getinfo() \t\t\t\t\t t = xt_find_table_lock \t\t\t\t\t\tlist_for_each_entry(tmpl, &xt_templates[af]...) \t\t\t\t\t\t\tif (strcmp(tmpl->name, name)) \t\t\t\t\t\t\t\tcontinue; //table not found \t\t\t\t\t\t\ttry_module_get \t\t\t\t\t\tlist_for_each_entry(t, &xt_net->tables[af]...) \t\t\t\t\t\t\treturn t; //not get refcnt \t\t\t\t\t module_put(t->me) //uaf unregister_pernet_subsys //remove table from xt_net list While xt_table module was going away and has been removed from xt_templates list, we couldnt get refcnt of xt_table->me. Check module in xt_net->tables list re-traversal to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50258", "url": "https://ubuntu.com/security/CVE-2024-50258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix crash when config small gso_max_size/gso_ipv4_max_size Config a small gso_max_size/gso_ipv4_max_size will lead to an underflow in sk_dst_gso_max_size(), which may trigger a BUG_ON crash, because sk->sk_gso_max_size would be much bigger than device limits. Call Trace: tcp_write_xmit tso_segs = tcp_init_tso_segs(skb, mss_now); tcp_set_skb_tso_segs tcp_skb_pcount_set // skb->len = 524288, mss_now = 8 // u16 tso_segs = 524288/8 = 65535 -> 0 tso_segs = DIV_ROUND_UP(skb->len, mss_now) BUG_ON(!tso_segs) Add check for the minimum value of gso_max_size and gso_ipv4_max_size.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50262", "url": "https://ubuntu.com/security/CVE-2024-50262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix out-of-bounds write in trie_get_next_key() trie_get_next_key() allocates a node stack with size trie->max_prefixlen, while it writes (trie->max_prefixlen + 1) nodes to the stack when it has full paths from the root to leaves. For example, consider a trie with max_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ... 0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with .prefixlen = 8 make 9 nodes be written on the node stack with size 8.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53044", "url": "https://ubuntu.com/security/CVE-2024-53044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_api: fix xa_insert() error path in tcf_block_get_ext() This command: $ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact Error: block dev insert failed: -EBUSY. fails because user space requests the same block index to be set for both ingress and egress. [ side note, I don't think it even failed prior to commit 913b47d3424e (\"net/sched: Introduce tc block netdev tracking infra\"), because this is a command from an old set of notes of mine which used to work, but alas, I did not scientifically bisect this ] The problem is not that it fails, but rather, that the second time around, it fails differently (and irrecoverably): $ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact Error: dsa_core: Flow block cb is busy. [ another note: the extack is added by me for illustration purposes. the context of the problem is that clsact_init() obtains the same &q->ingress_block pointer as &q->egress_block, and since we call tcf_block_get_ext() on both of them, \"dev\" will be added to the block->ports xarray twice, thus failing the operation: once through the ingress block pointer, and once again through the egress block pointer. the problem itself is that when xa_insert() fails, we have emitted a FLOW_BLOCK_BIND command through ndo_setup_tc(), but the offload never sees a corresponding FLOW_BLOCK_UNBIND. ] Even correcting the bad user input, we still cannot recover: $ tc qdisc replace dev swp3 ingress_block 1 egress_block 2 clsact Error: dsa_core: Flow block cb is busy. Basically the only way to recover is to reboot the system, or unbind and rebind the net device driver. To fix the bug, we need to fill the correct error teardown path which was missed during code movement, and call tcf_block_offload_unbind() when xa_insert() fails. [ last note, fundamentally I blame the label naming convention in tcf_block_get_ext() for the bug. The labels should be named after what they do, not after the error path that jumps to them. This way, it is obviously wrong that two labels pointing to the same code mean something is wrong, and checking the code correctness at the goto site is also easier ]", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50259", "url": "https://ubuntu.com/security/CVE-2024-50259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netdevsim: Add trailing zero to terminate the string in nsim_nexthop_bucket_activity_write() This was found by a static analyzer. We should not forget the trailing zero after copy_from_user() if we will further do some string operations, sscanf() in this case. Adding a trailing zero will ensure that the function performs properly.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50304", "url": "https://ubuntu.com/security/CVE-2024-50304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find() The per-netns IP tunnel hash table is protected by the RTNL mutex and ip_tunnel_find() is only called from the control path where the mutex is taken. Add a lockdep expression to hlist_for_each_entry_rcu() in ip_tunnel_find() in order to validate that the mutex is held and to silence the suspicious RCU usage warning [1]. [1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gd95d9a31aceb #139 Not tainted ----------------------------- net/ipv4/ip_tunnel.c:221 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/362: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60 stack backtrace: CPU: 12 UID: 0 PID: 362 Comm: ip Not tainted 6.12.0-rc3-custom-gd95d9a31aceb #139 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 ip_tunnel_find+0x435/0x4d0 ip_tunnel_newlink+0x517/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53042", "url": "https://ubuntu.com/security/CVE-2024-53042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_init_flow() There are code paths from which the function is called without holding the RCU read lock, resulting in a suspicious RCU usage warning [1]. Fix by using l3mdev_master_upper_ifindex_by_index() which will acquire the RCU read lock before calling l3mdev_master_upper_ifindex_by_index_rcu(). [1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gac8f72681cf2 #141 Not tainted ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/361: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60 stack backtrace: CPU: 3 UID: 0 PID: 361 Comm: ip Not tainted 6.12.0-rc3-custom-gac8f72681cf2 #141 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 dev_get_by_index_rcu+0x1d3/0x210 l3mdev_master_upper_ifindex_by_index_rcu+0x2b/0xf0 ip_tunnel_bind_dev+0x72f/0xa00 ip_tunnel_newlink+0x368/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53048", "url": "https://ubuntu.com/security/CVE-2024-53048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix crash on probe for DPLL enabled E810 LOM The E810 Lan On Motherboard (LOM) design is vendor specific. Intel provides the reference design, but it is up to vendor on the final product design. For some cases, like Linux DPLL support, the static values defined in the driver does not reflect the actual LOM design. Current implementation of dpll pins is causing the crash on probe of the ice driver for such DPLL enabled E810 LOM designs: WARNING: (...) at drivers/dpll/dpll_core.c:495 dpll_pin_get+0x2c4/0x330 ... Call Trace: ? __warn+0x83/0x130 ? dpll_pin_get+0x2c4/0x330 ? report_bug+0x1b7/0x1d0 ? handle_bug+0x42/0x70 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? dpll_pin_get+0x117/0x330 ? dpll_pin_get+0x2c4/0x330 ? dpll_pin_get+0x117/0x330 ice_dpll_get_pins.isra.0+0x52/0xe0 [ice] ... The number of dpll pins enabled by LOM vendor is greater than expected and defined in the driver for Intel designed NICs, which causes the crash. Prevent the crash and allow generic pin initialization within Linux DPLL subsystem for DPLL enabled E810 LOM designs. Newly designed solution for described issue will be based on \"per HW design\" pin initialization. It requires pin information dynamically acquired from the firmware and is already in progress, planned for next-tree only.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53058", "url": "https://ubuntu.com/security/CVE-2024-53058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data In case the non-paged data of a SKB carries protocol header and protocol payload to be transmitted on a certain platform that the DMA AXI address width is configured to 40-bit/48-bit, or the size of the non-paged data is bigger than TSO_MAX_BUFF_SIZE on a certain platform that the DMA AXI address width is configured to 32-bit, then this SKB requires at least two DMA transmit descriptors to serve it. For example, three descriptors are allocated to split one DMA buffer mapped from one piece of non-paged data: dma_desc[N + 0], dma_desc[N + 1], dma_desc[N + 2]. Then three elements of tx_q->tx_skbuff_dma[] will be allocated to hold extra information to be reused in stmmac_tx_clean(): tx_q->tx_skbuff_dma[N + 0], tx_q->tx_skbuff_dma[N + 1], tx_q->tx_skbuff_dma[N + 2]. Now we focus on tx_q->tx_skbuff_dma[entry].buf, which is the DMA buffer address returned by DMA mapping call. stmmac_tx_clean() will try to unmap the DMA buffer _ONLY_IF_ tx_q->tx_skbuff_dma[entry].buf is a valid buffer address. The expected behavior that saves DMA buffer address of this non-paged data to tx_q->tx_skbuff_dma[entry].buf is: tx_q->tx_skbuff_dma[N + 0].buf = NULL; tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = dma_map_single(); Unfortunately, the current code misbehaves like this: tx_q->tx_skbuff_dma[N + 0].buf = dma_map_single(); tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = NULL; On the stmmac_tx_clean() side, when dma_desc[N + 0] is closed by the DMA engine, tx_q->tx_skbuff_dma[N + 0].buf is a valid buffer address obviously, then the DMA buffer will be unmapped immediately. There may be a rare case that the DMA engine does not finish the pending dma_desc[N + 1], dma_desc[N + 2] yet. Now things will go horribly wrong, DMA is going to access a unmapped/unreferenced memory region, corrupted data will be transmited or iommu fault will be triggered :( In contrast, the for-loop that maps SKB fragments behaves perfectly as expected, and that is how the driver should do for both non-paged data and paged frags actually. This patch corrects DMA map/unmap sequences by fixing the array index for tx_q->tx_skbuff_dma[entry].buf when assigning DMA buffer address. Tested and verified on DWXGMAC CORE 3.20a", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50260", "url": "https://ubuntu.com/security/CVE-2024-50260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sock_map: fix a NULL pointer dereference in sock_map_link_update_prog() The following race condition could trigger a NULL pointer dereference: sock_map_link_detach():\t\tsock_map_link_update_prog(): mutex_lock(&sockmap_mutex); ... sockmap_link->map = NULL; mutex_unlock(&sockmap_mutex); \t\t\t\t mutex_lock(&sockmap_mutex); \t\t\t\t ... \t\t\t\t sock_map_prog_link_lookup(sockmap_link->map); \t\t\t\t mutex_unlock(&sockmap_mutex); Fix it by adding a NULL pointer check. In this specific case, it makes no sense to update a link which is being released.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53045", "url": "https://ubuntu.com/security/CVE-2024-53045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: dapm: fix bounds checker error in dapm_widget_list_create The widgets array in the snd_soc_dapm_widget_list has a __counted_by attribute attached to it, which points to the num_widgets variable. This attribute is used in bounds checking, and if it is not set before the array is filled, then the bounds sanitizer will issue a warning or a kernel panic if CONFIG_UBSAN_TRAP is set. This patch sets the size of the widgets list calculated with list_for_each as the initial value for num_widgets as it is used for allocating memory for the array. It is updated with the actual number of added elements after the array is filled.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50261", "url": "https://ubuntu.com/security/CVE-2024-50261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macsec: Fix use-after-free while sending the offloading packet KASAN reports the following UAF. The metadata_dst, which is used to store the SCI value for macsec offload, is already freed by metadata_dst_free() in macsec_free_netdev(), while driver still use it for sending the packet. To fix this issue, dst_release() is used instead to release metadata_dst. So it is not freed instantly in macsec_free_netdev() if still referenced by skb. BUG: KASAN: slab-use-after-free in mlx5e_xmit+0x1e8f/0x4190 [mlx5_core] Read of size 2 at addr ffff88813e42e038 by task kworker/7:2/714 [...] Workqueue: mld mld_ifc_work Call Trace: dump_stack_lvl+0x51/0x60 print_report+0xc1/0x600 kasan_report+0xab/0xe0 mlx5e_xmit+0x1e8f/0x4190 [mlx5_core] dev_hard_start_xmit+0x120/0x530 sch_direct_xmit+0x149/0x11e0 __qdisc_run+0x3ad/0x1730 __dev_queue_xmit+0x1196/0x2ed0 vlan_dev_hard_start_xmit+0x32e/0x510 [8021q] dev_hard_start_xmit+0x120/0x530 __dev_queue_xmit+0x14a7/0x2ed0 macsec_start_xmit+0x13e9/0x2340 dev_hard_start_xmit+0x120/0x530 __dev_queue_xmit+0x14a7/0x2ed0 ip6_finish_output2+0x923/0x1a70 ip6_finish_output+0x2d7/0x970 ip6_output+0x1ce/0x3a0 NF_HOOK.constprop.0+0x15f/0x190 mld_sendpack+0x59a/0xbd0 mld_ifc_work+0x48a/0xa80 process_one_work+0x5aa/0xe50 worker_thread+0x79c/0x1290 kthread+0x28f/0x350 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x11/0x20 Allocated by task 3922: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 __kasan_kmalloc+0x77/0x90 __kmalloc_noprof+0x188/0x400 metadata_dst_alloc+0x1f/0x4e0 macsec_newlink+0x914/0x1410 __rtnl_newlink+0xe08/0x15b0 rtnl_newlink+0x5f/0x90 rtnetlink_rcv_msg+0x667/0xa80 netlink_rcv_skb+0x12c/0x360 netlink_unicast+0x551/0x770 netlink_sendmsg+0x72d/0xbd0 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x52e/0x6a0 ___sys_sendmsg+0xeb/0x170 __sys_sendmsg+0xb5/0x140 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Freed by task 4011: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x50 poison_slab_object+0x10c/0x190 __kasan_slab_free+0x11/0x30 kfree+0xe0/0x290 macsec_free_netdev+0x3f/0x140 netdev_run_todo+0x450/0xc70 rtnetlink_rcv_msg+0x66f/0xa80 netlink_rcv_skb+0x12c/0x360 netlink_unicast+0x551/0x770 netlink_sendmsg+0x72d/0xbd0 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x52e/0x6a0 ___sys_sendmsg+0xeb/0x170 __sys_sendmsg+0xb5/0x140 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53059", "url": "https://ubuntu.com/security/CVE-2024-53059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd() 1. The size of the response packet is not validated. 2. The response buffer is not freed. Resolve these issues by switching to iwl_mvm_send_cmd_status(), which handles both size validation and frees the buffer.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53074", "url": "https://ubuntu.com/security/CVE-2024-53074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: don't leak a link on AP removal Release the link mapping resource in AP removal. This impacted devices that do not support the MLD API (9260 and down). On those devices, we couldn't start the AP again after the AP has been already started and stopped.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53049", "url": "https://ubuntu.com/security/CVE-2024-53049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slub/kunit: fix a WARNING due to unwrapped __kmalloc_cache_noprof 'modprobe slub_kunit' will have a warning as shown below. The root cause is that __kmalloc_cache_noprof was directly used, which resulted in no alloc_tag being allocated. This caused current->alloc_tag to be null, leading to a warning in alloc_tag_add_check. Let's add an alloc_hook layer to __kmalloc_cache_noprof specifically within lib/slub_kunit.c, which is the only user of this internal slub function outside kmalloc implementation itself. [58162.947016] WARNING: CPU: 2 PID: 6210 at ./include/linux/alloc_tag.h:125 alloc_tagging_slab_alloc_hook+0x268/0x27c [58162.957721] Call trace: [58162.957919] alloc_tagging_slab_alloc_hook+0x268/0x27c [58162.958286] __kmalloc_cache_noprof+0x14c/0x344 [58162.958615] test_kmalloc_redzone_access+0x50/0x10c [slub_kunit] [58162.959045] kunit_try_run_case+0x74/0x184 [kunit] [58162.959401] kunit_generic_run_threadfn_adapter+0x2c/0x4c [kunit] [58162.959841] kthread+0x10c/0x118 [58162.960093] ret_from_fork+0x10/0x20 [58162.960363] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50192", "url": "https://ubuntu.com/security/CVE-2024-50192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v4: Don't allow a VMOVP on a dying VPE Kunkun Jiang reported that there is a small window of opportunity for userspace to force a change of affinity for a VPE while the VPE has already been unmapped, but the corresponding doorbell interrupt still visible in /proc/irq/. Plug the race by checking the value of vmapp_count, which tracks whether the VPE is mapped ot not, and returning an error in this case. This involves making vmapp_count common to both GICv4.1 and its v4.0 ancestor.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50069", "url": "https://ubuntu.com/security/CVE-2024-50069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: apple: check devm_kasprintf() returned value devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked. Fix this lack and check the returned value. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50070", "url": "https://ubuntu.com/security/CVE-2024-50070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: stm32: check devm_kasprintf() returned value devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked. Fix this lack and check the returned value. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50196", "url": "https://ubuntu.com/security/CVE-2024-50196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: ocelot: fix system hang on level based interrupts The current implementation only calls chained_irq_enter() and chained_irq_exit() if it detects pending interrupts. ``` for (i = 0; i < info->stride; i++) { \turegmap_read(info->map, id_reg + 4 * i, ®); \tif (!reg) \t\tcontinue; \tchained_irq_enter(parent_chip, desc); ``` However, in case of GPIO pin configured in level mode and the parent controller configured in edge mode, GPIO interrupt might be lowered by the hardware. In the result, if the interrupt is short enough, the parent interrupt is still pending while the GPIO interrupt is cleared; chained_irq_enter() never gets called and the system hangs trying to service the parent interrupt. Moving chained_irq_enter() and chained_irq_exit() outside the for loop ensures that they are called even when GPIO interrupt is lowered by the hardware. The similar code with chained_irq_enter() / chained_irq_exit() functions wrapping interrupt checking loop may be found in many other drivers: ``` grep -r -A 10 chained_irq_enter drivers/pinctrl ```", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50197", "url": "https://ubuntu.com/security/CVE-2024-50197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: intel: platform: fix error path in device_for_each_child_node() The device_for_each_child_node() loop requires calls to fwnode_handle_put() upon early returns to decrement the refcount of the child node and avoid leaking memory if that error path is triggered. There is one early returns within that loop in intel_platform_pinctrl_prepare_community(), but fwnode_handle_put() is missing. Instead of adding the missing call, the scoped version of the loop can be used to simplify the code and avoid mistakes in the future if new early returns are added, as the child node is only used for parsing, and it is never assigned.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50071", "url": "https://ubuntu.com/security/CVE-2024-50071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: nuvoton: fix a double free in ma35_pinctrl_dt_node_to_map_func() 'new_map' is allocated using devm_* which takes care of freeing the allocated data on device removal, call to \t.dt_free_map = pinconf_generic_dt_free_map double frees the map as pinconf_generic_dt_free_map() calls pinctrl_utils_free_map(). Fix this by using kcalloc() instead of auto-managed devm_kcalloc().", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50072", "url": "https://ubuntu.com/security/CVE-2024-50072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/bugs: Use code segment selector for VERW operand Robert Gill reported below #GP in 32-bit mode when dosemu software was executing vm86() system call: general protection fault: 0000 [#1] PREEMPT SMP CPU: 4 PID: 4610 Comm: dosemu.bin Not tainted 6.6.21-gentoo-x86 #1 Hardware name: Dell Inc. PowerEdge 1950/0H723K, BIOS 2.7.0 10/30/2010 EIP: restore_all_switch_stack+0xbe/0xcf EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000 ESI: 00000000 EDI: 00000000 EBP: 00000000 ESP: ff8affdc DS: 0000 ES: 0000 FS: 0000 GS: 0033 SS: 0068 EFLAGS: 00010046 CR0: 80050033 CR2: 00c2101c CR3: 04b6d000 CR4: 000406d0 Call Trace: show_regs+0x70/0x78 die_addr+0x29/0x70 exc_general_protection+0x13c/0x348 exc_bounds+0x98/0x98 handle_exception+0x14d/0x14d exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf This only happens in 32-bit mode when VERW based mitigations like MDS/RFDS are enabled. This is because segment registers with an arbitrary user value can result in #GP when executing VERW. Intel SDM vol. 2C documents the following behavior for VERW instruction: #GP(0) - If a memory operand effective address is outside the CS, DS, ES, \t FS, or GS segment limit. CLEAR_CPU_BUFFERS macro executes VERW instruction before returning to user space. Use %cs selector to reference VERW operand. This ensures VERW will not #GP for an arbitrary user %ds. [ mingo: Fixed the SOB chain. ]", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50073", "url": "https://ubuntu.com/security/CVE-2024-50073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: Fix use-after-free in gsm_cleanup_mux BUG: KASAN: slab-use-after-free in gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] Read of size 8 at addr ffff88815fe99c00 by task poc/3379 CPU: 0 UID: 0 PID: 3379 Comm: poc Not tainted 6.11.0+ #56 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] __pfx_gsm_cleanup_mux+0x10/0x10 drivers/tty/n_gsm.c:3124 [n_gsm] __pfx_sched_clock_cpu+0x10/0x10 kernel/sched/clock.c:389 update_load_avg+0x1c1/0x27b0 kernel/sched/fair.c:4500 __pfx_min_vruntime_cb_rotate+0x10/0x10 kernel/sched/fair.c:846 __rb_insert_augmented+0x492/0xbf0 lib/rbtree.c:161 gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] _raw_spin_lock_irqsave+0x92/0xf0 arch/x86/include/asm/atomic.h:107 __pfx_gsmld_ioctl+0x10/0x10 drivers/tty/n_gsm.c:3822 [n_gsm] ktime_get+0x5e/0x140 kernel/time/timekeeping.c:195 ldsem_down_read+0x94/0x4e0 arch/x86/include/asm/atomic64_64.h:79 __pfx_ldsem_down_read+0x10/0x10 drivers/tty/tty_ldsem.c:338 __pfx_do_vfs_ioctl+0x10/0x10 fs/ioctl.c:805 tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 Allocated by task 65: gsm_data_alloc.constprop.0+0x27/0x190 drivers/tty/n_gsm.c:926 [n_gsm] gsm_send+0x2c/0x580 drivers/tty/n_gsm.c:819 [n_gsm] gsm1_receive+0x547/0xad0 drivers/tty/n_gsm.c:3038 [n_gsm] gsmld_receive_buf+0x176/0x280 drivers/tty/n_gsm.c:3609 [n_gsm] tty_ldisc_receive_buf+0x101/0x1e0 drivers/tty/tty_buffer.c:391 tty_port_default_receive_buf+0x61/0xa0 drivers/tty/tty_port.c:39 flush_to_ldisc+0x1b0/0x750 drivers/tty/tty_buffer.c:445 process_scheduled_works+0x2b0/0x10d0 kernel/workqueue.c:3229 worker_thread+0x3dc/0x950 kernel/workqueue.c:3391 kthread+0x2a3/0x370 kernel/kthread.c:389 ret_from_fork+0x2d/0x70 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:257 Freed by task 3367: kfree+0x126/0x420 mm/slub.c:4580 gsm_cleanup_mux+0x36c/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 [Analysis] gsm_msg on the tx_ctrl_list or tx_data_list of gsm_mux can be freed by multi threads through ioctl,which leads to the occurrence of uaf. Protect it by gsm tx lock.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50193", "url": "https://ubuntu.com/security/CVE-2024-50193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/entry_32: Clear CPU buffers after register restore in NMI return CPU buffers are currently cleared after call to exc_nmi, but before register state is restored. This may be okay for MDS mitigation but not for RDFS. Because RDFS mitigation requires CPU buffers to be cleared when registers don't have any sensitive data. Move CLEAR_CPU_BUFFERS after RESTORE_ALL_NMI.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50074", "url": "https://ubuntu.com/security/CVE-2024-50074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: parport: Proper fix for array out-of-bounds access The recent fix for array out-of-bounds accesses replaced sprintf() calls blindly with snprintf(). However, since snprintf() returns the would-be-printed size, not the actually output size, the length calculation can still go over the given limit. Use scnprintf() instead of snprintf(), which returns the actually output letters, for addressing the potential out-of-bounds access properly.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50100", "url": "https://ubuntu.com/security/CVE-2024-50100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: gadget: dummy-hcd: Fix \"task hung\" problem The syzbot fuzzer has been encountering \"task hung\" problems ever since the dummy-hcd driver was changed to use hrtimers instead of regular timers. It turns out that the problems are caused by a subtle difference between the timer_pending() and hrtimer_active() APIs. The changeover blindly replaced the first by the second. However, timer_pending() returns True when the timer is queued but not when its callback is running, whereas hrtimer_active() returns True when the hrtimer is queued _or_ its callback is running. This difference occasionally caused dummy_urb_enqueue() to think that the callback routine had not yet started when in fact it was almost finished. As a result the hrtimer was not restarted, which made it impossible for the driver to dequeue later the URB that was just enqueued. This caused usb_kill_urb() to hang, and things got worse from there. Since hrtimers have no API for telling when they are queued and the callback isn't running, the driver must keep track of this for itself. That's what this patch does, adding a new \"timer_pending\" flag and setting or clearing it at the appropriate times.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50075", "url": "https://ubuntu.com/security/CVE-2024-50075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xhci: tegra: fix checked USB2 port number If USB virtualizatoin is enabled, USB2 ports are shared between all Virtual Functions. The USB2 port number owned by an USB2 root hub in a Virtual Function may be less than total USB2 phy number supported by the Tegra XUSB controller. Using total USB2 phy number as port number to check all PORTSC values would cause invalid memory access. [ 116.923438] Unable to handle kernel paging request at virtual address 006c622f7665642f ... [ 117.213640] Call trace: [ 117.216783] tegra_xusb_enter_elpg+0x23c/0x658 [ 117.222021] tegra_xusb_runtime_suspend+0x40/0x68 [ 117.227260] pm_generic_runtime_suspend+0x30/0x50 [ 117.232847] __rpm_callback+0x84/0x3c0 [ 117.237038] rpm_suspend+0x2dc/0x740 [ 117.241229] pm_runtime_work+0xa0/0xb8 [ 117.245769] process_scheduled_works+0x24c/0x478 [ 117.251007] worker_thread+0x23c/0x328 [ 117.255547] kthread+0x104/0x1b0 [ 117.259389] ret_from_fork+0x10/0x20 [ 117.263582] Code: 54000222 f9461ae8 f8747908 b4ffff48 (f9400100)", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50076", "url": "https://ubuntu.com/security/CVE-2024-50076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vt: prevent kernel-infoleak in con_font_get() font.data may not initialize all memory spaces depending on the implementation of vc->vc_sw->con_font_get. This may cause info-leak, so to prevent this, it is safest to modify it to initialize the allocated memory space to 0, and it generally does not affect the overall performance of the system.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50077", "url": "https://ubuntu.com/security/CVE-2024-50077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix multiple init when debugfs is disabled If bt_debugfs is not created successfully, which happens if either CONFIG_DEBUG_FS or CONFIG_DEBUG_FS_ALLOW_ALL is unset, then iso_init() returns early and does not set iso_inited to true. This means that a subsequent call to iso_init() will result in duplicate calls to proto_register(), bt_sock_register(), etc. With CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, the duplicate call to proto_register() triggers this BUG(): list_add double add: new=ffffffffc0b280d0, prev=ffffffffbab56250, next=ffffffffc0b280d0. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:35! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 2 PID: 887 Comm: bluetoothd Not tainted 6.10.11-1-ao-desktop #1 RIP: 0010:__list_add_valid_or_report+0x9a/0xa0 ... __list_add_valid_or_report+0x9a/0xa0 proto_register+0x2b5/0x340 iso_init+0x23/0x150 [bluetooth] set_iso_socket_func+0x68/0x1b0 [bluetooth] kmem_cache_free+0x308/0x330 hci_sock_sendmsg+0x990/0x9e0 [bluetooth] __sock_sendmsg+0x7b/0x80 sock_write_iter+0x9a/0x110 do_iter_readv_writev+0x11d/0x220 vfs_writev+0x180/0x3e0 do_writev+0xca/0x100 ... This change removes the early return. The check for iso_debugfs being NULL was unnecessary, it is always NULL when iso_inited is false.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50078", "url": "https://ubuntu.com/security/CVE-2024-50078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Call iso_exit() on module unload If iso_init() has been called, iso_exit() must be called on module unload. Without that, the struct proto that iso_init() registered with proto_register() becomes invalid, which could cause unpredictable problems later. In my case, with CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, loading the module again usually triggers this BUG(): list_add corruption. next->prev should be prev (ffffffffb5355fd0), but was 0000000000000068. (next=ffffffffc0a010d0). ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:29! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 4159 Comm: modprobe Not tainted 6.10.11-4+bt2-ao-desktop #1 RIP: 0010:__list_add_valid_or_report+0x61/0xa0 ... __list_add_valid_or_report+0x61/0xa0 proto_register+0x299/0x320 hci_sock_init+0x16/0xc0 [bluetooth] bt_init+0x68/0xd0 [bluetooth] __pfx_bt_init+0x10/0x10 [bluetooth] do_one_initcall+0x80/0x2f0 do_init_module+0x8b/0x230 __do_sys_init_module+0x15f/0x190 do_syscall_64+0x68/0x110 ...", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50198", "url": "https://ubuntu.com/security/CVE-2024-50198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: veml6030: fix IIO device retrieval from embedded device The dev pointer that is received as an argument in the in_illuminance_period_available_show function references the device embedded in the IIO device, not in the i2c client. dev_to_iio_dev() must be used to accessthe right data. The current implementation leads to a segmentation fault on every attempt to read the attribute because indio_dev gets a NULL assignment. This bug has been present since the first appearance of the driver, apparently since the last version (V6) before getting applied. A constant attribute was used until then, and the last modifications might have not been tested again.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50201", "url": "https://ubuntu.com/security/CVE-2024-50201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: Fix encoder->possible_clones Include the encoder itself in its possible_clones bitmask. In the past nothing validated that drivers were populating possible_clones correctly, but that changed in commit 74d2aacbe840 (\"drm: Validate encoder->possible_clones\"). Looks like radeon never got the memo and is still not following the rules 100% correctly. This results in some warnings during driver initialization: Bogus possible_clones: [ENCODER:46:TV-46] possible_clones=0x4 (full encoder mask=0x7) WARNING: CPU: 0 PID: 170 at drivers/gpu/drm/drm_mode_config.c:615 drm_mode_config_validate+0x113/0x39c ... (cherry picked from commit 3b6e7d40649c0d75572039aff9d0911864c689db)", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50098", "url": "https://ubuntu.com/security/CVE-2024-50098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Set SDEV_OFFLINE when UFS is shut down There is a history of deadlock if reboot is performed at the beginning of booting. SDEV_QUIESCE was set for all LU's scsi_devices by UFS shutdown, and at that time the audio driver was waiting on blk_mq_submit_bio() holding a mutex_lock while reading the fw binary. After that, a deadlock issue occurred while audio driver shutdown was waiting for mutex_unlock of blk_mq_submit_bio(). To solve this, set SDEV_OFFLINE for all LUs except WLUN, so that any I/O that comes down after a UFS shutdown will return an error. [ 31.907781]I[0: swapper/0: 0] 1 130705007 1651079834 11289729804 0 D( 2) 3 ffffff882e208000 * init [device_shutdown] [ 31.907793]I[0: swapper/0: 0] Mutex: 0xffffff8849a2b8b0: owner[0xffffff882e28cb00 kworker/6:0 :49] [ 31.907806]I[0: swapper/0: 0] Call trace: [ 31.907810]I[0: swapper/0: 0] __switch_to+0x174/0x338 [ 31.907819]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc [ 31.907826]I[0: swapper/0: 0] schedule+0x7c/0xe8 [ 31.907834]I[0: swapper/0: 0] schedule_preempt_disabled+0x24/0x40 [ 31.907842]I[0: swapper/0: 0] __mutex_lock+0x408/0xdac [ 31.907849]I[0: swapper/0: 0] __mutex_lock_slowpath+0x14/0x24 [ 31.907858]I[0: swapper/0: 0] mutex_lock+0x40/0xec [ 31.907866]I[0: swapper/0: 0] device_shutdown+0x108/0x280 [ 31.907875]I[0: swapper/0: 0] kernel_restart+0x4c/0x11c [ 31.907883]I[0: swapper/0: 0] __arm64_sys_reboot+0x15c/0x280 [ 31.907890]I[0: swapper/0: 0] invoke_syscall+0x70/0x158 [ 31.907899]I[0: swapper/0: 0] el0_svc_common+0xb4/0xf4 [ 31.907909]I[0: swapper/0: 0] do_el0_svc+0x2c/0xb0 [ 31.907918]I[0: swapper/0: 0] el0_svc+0x34/0xe0 [ 31.907928]I[0: swapper/0: 0] el0t_64_sync_handler+0x68/0xb4 [ 31.907937]I[0: swapper/0: 0] el0t_64_sync+0x1a0/0x1a4 [ 31.908774]I[0: swapper/0: 0] 49 0 11960702 11236868007 0 D( 2) 6 ffffff882e28cb00 * kworker/6:0 [__bio_queue_enter] [ 31.908783]I[0: swapper/0: 0] Call trace: [ 31.908788]I[0: swapper/0: 0] __switch_to+0x174/0x338 [ 31.908796]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc [ 31.908803]I[0: swapper/0: 0] schedule+0x7c/0xe8 [ 31.908811]I[0: swapper/0: 0] __bio_queue_enter+0xb8/0x178 [ 31.908818]I[0: swapper/0: 0] blk_mq_submit_bio+0x194/0x67c [ 31.908827]I[0: swapper/0: 0] __submit_bio+0xb8/0x19c", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50079", "url": "https://ubuntu.com/security/CVE-2024-50079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/sqpoll: ensure task state is TASK_RUNNING when running task_work When the sqpoll is exiting and cancels pending work items, it may need to run task_work. If this happens from within io_uring_cancel_generic(), then it may be under waiting for the io_uring_task waitqueue. This results in the below splat from the scheduler, as the ring mutex may be attempted grabbed while in a TASK_INTERRUPTIBLE state. Ensure that the task state is set appropriately for that, just like what is done for the other cases in io_run_task_work(). do not call blocking ops when !TASK_RUNNING; state=1 set at [<0000000029387fd2>] prepare_to_wait+0x88/0x2fc WARNING: CPU: 6 PID: 59939 at kernel/sched/core.c:8561 __might_sleep+0xf4/0x140 Modules linked in: CPU: 6 UID: 0 PID: 59939 Comm: iou-sqp-59938 Not tainted 6.12.0-rc3-00113-g8d020023b155 #7456 Hardware name: linux,dummy-virt (DT) pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : __might_sleep+0xf4/0x140 lr : __might_sleep+0xf4/0x140 sp : ffff80008c5e7830 x29: ffff80008c5e7830 x28: ffff0000d93088c0 x27: ffff60001c2d7230 x26: dfff800000000000 x25: ffff0000e16b9180 x24: ffff80008c5e7a50 x23: 1ffff000118bcf4a x22: ffff0000e16b9180 x21: ffff0000e16b9180 x20: 000000000000011b x19: ffff80008310fac0 x18: 1ffff000118bcd90 x17: 30303c5b20746120 x16: 74657320313d6574 x15: 0720072007200720 x14: 0720072007200720 x13: 0720072007200720 x12: ffff600036c64f0b x11: 1fffe00036c64f0a x10: ffff600036c64f0a x9 : dfff800000000000 x8 : 00009fffc939b0f6 x7 : ffff0001b6327853 x6 : 0000000000000001 x5 : ffff0001b6327850 x4 : ffff600036c64f0b x3 : ffff8000803c35bc x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000e16b9180 Call trace: __might_sleep+0xf4/0x140 mutex_lock+0x84/0x124 io_handle_tw_list+0xf4/0x260 tctx_task_work_run+0x94/0x340 io_run_task_work+0x1ec/0x3c0 io_uring_cancel_generic+0x364/0x524 io_sq_thread+0x820/0x124c ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50080", "url": "https://ubuntu.com/security/CVE-2024-50080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: don't allow user copy for unprivileged device UBLK_F_USER_COPY requires userspace to call write() on ublk char device for filling request buffer, and unprivileged device can't be trusted. So don't allow user copy for unprivileged device.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50081", "url": "https://ubuntu.com/security/CVE-2024-50081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-mq: setup queue ->tag_set before initializing hctx Commit 7b815817aa58 (\"blk-mq: add helper for checking if one CPU is mapped to specified hctx\") needs to check queue mapping via tag set in hctx's cpuhp handler. However, q->tag_set may not be setup yet when the cpuhp handler is enabled, then kernel oops is triggered. Fix the issue by setup queue tag_set before initializing hctx.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50082", "url": "https://ubuntu.com/security/CVE-2024-50082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race We're seeing crashes from rq_qos_wake_function that look like this: BUG: unable to handle page fault for address: ffffafe180a40084 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 100000067 P4D 100000067 PUD 10027c067 PMD 10115d067 PTE 0 Oops: Oops: 0002 [#1] PREEMPT SMP PTI CPU: 17 UID: 0 PID: 0 Comm: swapper/17 Not tainted 6.12.0-rc3-00013-geca631b8fe80 #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:_raw_spin_lock_irqsave+0x1d/0x40 Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 9c 41 5c fa 65 ff 05 62 97 30 4c 31 c0 ba 01 00 00 00 0f b1 17 75 0a 4c 89 e0 41 5c c3 cc cc cc cc 89 c6 e8 2c 0b 00 RSP: 0018:ffffafe180580ca0 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffffafe180a3f7a8 RCX: 0000000000000011 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffffafe180a40084 RBP: 0000000000000000 R08: 00000000001e7240 R09: 0000000000000011 R10: 0000000000000028 R11: 0000000000000888 R12: 0000000000000002 R13: ffffafe180a40084 R14: 0000000000000000 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff9aaf1f280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffafe180a40084 CR3: 000000010e428002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: try_to_wake_up+0x5a/0x6a0 rq_qos_wake_function+0x71/0x80 __wake_up_common+0x75/0xa0 __wake_up+0x36/0x60 scale_up.part.0+0x50/0x110 wb_timer_fn+0x227/0x450 ... So rq_qos_wake_function() calls wake_up_process(data->task), which calls try_to_wake_up(), which faults in raw_spin_lock_irqsave(&p->pi_lock). p comes from data->task, and data comes from the waitqueue entry, which is stored on the waiter's stack in rq_qos_wait(). Analyzing the core dump with drgn, I found that the waiter had already woken up and moved on to a completely unrelated code path, clobbering what was previously data->task. Meanwhile, the waker was passing the clobbered garbage in data->task to wake_up_process(), leading to the crash. What's happening is that in between rq_qos_wake_function() deleting the waitqueue entry and calling wake_up_process(), rq_qos_wait() is finding that it already got a token and returning. The race looks like this: rq_qos_wait() rq_qos_wake_function() ============================================================== prepare_to_wait_exclusive() data->got_token = true; list_del_init(&curr->entry); if (data.got_token) break; finish_wait(&rqw->wait, &data.wq); ^- returns immediately because list_empty_careful(&wq_entry->entry) is true ... return, go do something else ... wake_up_process(data->task) (NO LONGER VALID!)-^ Normally, finish_wait() is supposed to synchronize against the waker. But, as noted above, it is returning immediately because the waitqueue entry has already been removed from the waitqueue. The bug is that rq_qos_wake_function() is accessing the waitqueue entry AFTER deleting it. Note that autoremove_wake_function() wakes the waiter and THEN deletes the waitqueue entry, which is the proper order. Fix it by swapping the order. We also need to use list_del_init_careful() to match the list_empty_careful() in finish_wait().", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50101", "url": "https://ubuntu.com/security/CVE-2024-50101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI devices Previously, the domain_context_clear() function incorrectly called pci_for_each_dma_alias() to set up context entries for non-PCI devices. This could lead to kernel hangs or other unexpected behavior. Add a check to only call pci_for_each_dma_alias() for PCI devices. For non-PCI devices, domain_context_clear_one() is called directly.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50083", "url": "https://ubuntu.com/security/CVE-2024-50083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix mptcp DSS corruption due to large pmtu xmit Syzkaller was able to trigger a DSS corruption: TCP: request_sock_subflow_v4: Possible SYN flooding on port [::]:20002. Sending cookies. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 5227 at net/mptcp/protocol.c:695 __mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695 Modules linked in: CPU: 0 UID: 0 PID: 5227 Comm: syz-executor350 Not tainted 6.11.0-syzkaller-08829-gaf9c191ac2a0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:__mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695 Code: 0f b6 dc 31 ff 89 de e8 b5 dd ea f5 89 d8 48 81 c4 50 01 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 98 da ea f5 90 <0f> 0b 90 e9 47 ff ff ff e8 8a da ea f5 90 0f 0b 90 e9 99 e0 ff ff RSP: 0018:ffffc90000006db8 EFLAGS: 00010246 RAX: ffffffff8ba9df18 RBX: 00000000000055f0 RCX: ffff888030023c00 RDX: 0000000000000100 RSI: 00000000000081e5 RDI: 00000000000055f0 RBP: 1ffff110062bf1ae R08: ffffffff8ba9cf12 R09: 1ffff110062bf1b8 R10: dffffc0000000000 R11: ffffed10062bf1b9 R12: 0000000000000000 R13: dffffc0000000000 R14: 00000000700cec61 R15: 00000000000081e5 FS: 000055556679c380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020287000 CR3: 0000000077892000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: move_skbs_to_msk net/mptcp/protocol.c:811 [inline] mptcp_data_ready+0x29c/0xa90 net/mptcp/protocol.c:854 subflow_data_ready+0x34a/0x920 net/mptcp/subflow.c:1490 tcp_data_queue+0x20fd/0x76c0 net/ipv4/tcp_input.c:5283 tcp_rcv_established+0xfba/0x2020 net/ipv4/tcp_input.c:6237 tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915 tcp_v4_rcv+0x2dc0/0x37f0 net/ipv4/tcp_ipv4.c:2350 ip_protocol_deliver_rcu+0x22e/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x341/0x5f0 net/ipv4/ip_input.c:233 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314 __netif_receive_skb_one_core net/core/dev.c:5662 [inline] __netif_receive_skb+0x2bf/0x650 net/core/dev.c:5775 process_backlog+0x662/0x15b0 net/core/dev.c:6107 __napi_poll+0xcb/0x490 net/core/dev.c:6771 napi_poll net/core/dev.c:6840 [inline] net_rx_action+0x89b/0x1240 net/core/dev.c:6962 handle_softirqs+0x2c5/0x980 kernel/softirq.c:554 do_softirq+0x11b/0x1e0 kernel/softirq.c:455 __local_bh_enable_ip+0x1bb/0x200 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0x1764/0x3e80 net/core/dev.c:4451 dev_queue_xmit include/linux/netdevice.h:3094 [inline] neigh_hh_output include/net/neighbour.h:526 [inline] neigh_output include/net/neighbour.h:540 [inline] ip_finish_output2+0xd41/0x1390 net/ipv4/ip_output.c:236 ip_local_out net/ipv4/ip_output.c:130 [inline] __ip_queue_xmit+0x118c/0x1b80 net/ipv4/ip_output.c:536 __tcp_transmit_skb+0x2544/0x3b30 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_mtu_probe net/ipv4/tcp_output.c:2547 [inline] tcp_write_xmit+0x641d/0x6bf0 net/ipv4/tcp_output.c:2752 __tcp_push_pending_frames+0x9b/0x360 net/ipv4/tcp_output.c:3015 tcp_push_pending_frames include/net/tcp.h:2107 [inline] tcp_data_snd_check net/ipv4/tcp_input.c:5714 [inline] tcp_rcv_established+0x1026/0x2020 net/ipv4/tcp_input.c:6239 tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915 sk_backlog_rcv include/net/sock.h:1113 [inline] __release_sock+0x214/0x350 net/core/sock.c:3072 release_sock+0x61/0x1f0 net/core/sock.c:3626 mptcp_push_ ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50068", "url": "https://ubuntu.com/security/CVE-2024-50068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/tests/sysfs-kunit.h: fix memory leak in damon_sysfs_test_add_targets() The sysfs_target->regions allocated in damon_sysfs_regions_alloc() is not freed in damon_sysfs_test_add_targets(), which cause the following memory leak, free it to fix it. \tunreferenced object 0xffffff80c2a8db80 (size 96): \t comm \"kunit_try_catch\", pid 187, jiffies 4294894363 \t hex dump (first 32 bytes): \t 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ \t 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ \t backtrace (crc 0): \t [<0000000001e3714d>] kmemleak_alloc+0x34/0x40 \t [<000000008e6835c1>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000001286d9f8>] damon_sysfs_test_add_targets+0x1cc/0x738 \t [<0000000032ef8f77>] kunit_try_run_case+0x13c/0x3ac \t [<00000000f3edea23>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000adf936cf>] kthread+0x2e8/0x374 \t [<0000000041bb1628>] ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50199", "url": "https://ubuntu.com/security/CVE-2024-50199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/swapfile: skip HugeTLB pages for unuse_vma I got a bad pud error and lost a 1GB HugeTLB when calling swapoff. The problem can be reproduced by the following steps: 1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory. 2. Swapout the above anonymous memory. 3. run swapoff and we will get a bad pud error in kernel message: mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7) We can tell that pud_clear_bad is called by pud_none_or_clear_bad in unuse_pud_range() by ftrace. And therefore the HugeTLB pages will never be freed because we lost it from page table. We can skip HugeTLB pages for unuse_vma to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50066", "url": "https://ubuntu.com/security/CVE-2024-50066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mremap: fix move_normal_pmd/retract_page_tables race In mremap(), move_page_tables() looks at the type of the PMD entry and the specified address range to figure out by which method the next chunk of page table entries should be moved. At that point, the mmap_lock is held in write mode, but no rmap locks are held yet. For PMD entries that point to page tables and are fully covered by the source address range, move_pgt_entry(NORMAL_PMD, ...) is called, which first takes rmap locks, then does move_normal_pmd(). move_normal_pmd() takes the necessary page table locks at source and destination, then moves an entire page table from the source to the destination. The problem is: The rmap locks, which protect against concurrent page table removal by retract_page_tables() in the THP code, are only taken after the PMD entry has been read and it has been decided how to move it. So we can race as follows (with two processes that have mappings of the same tmpfs file that is stored on a tmpfs mount with huge=advise); note that process A accesses page tables through the MM while process B does it through the file rmap: process A process B ========= ========= mremap mremap_to move_vma move_page_tables get_old_pmd alloc_new_pmd *** PREEMPT *** madvise(MADV_COLLAPSE) do_madvise madvise_walk_vmas madvise_vma_behavior madvise_collapse hpage_collapse_scan_file collapse_file retract_page_tables i_mmap_lock_read(mapping) pmdp_collapse_flush i_mmap_unlock_read(mapping) move_pgt_entry(NORMAL_PMD, ...) take_rmap_locks move_normal_pmd drop_rmap_locks When this happens, move_normal_pmd() can end up creating bogus PMD entries in the line `pmd_populate(mm, new_pmd, pmd_pgtable(pmd))`. The effect depends on arch-specific and machine-specific details; on x86, you can end up with physical page 0 mapped as a page table, which is likely exploitable for user->kernel privilege escalation. Fix the race by letting process B recheck that the PMD still points to a page table after the rmap locks have been taken. Otherwise, we bail and let the caller fall back to the PTE-level copying path, which will then bail immediately at the pmd_none() check. Bug reachability: Reaching this bug requires that you can create shmem/file THP mappings - anonymous THP uses different code that doesn't zap stuff under rmap locks. File THP is gated on an experimental config flag (CONFIG_READ_ONLY_THP_FOR_FS), so on normal distro kernels you need shmem THP to hit this bug. As far as I know, getting shmem THP normally requires that you can mount your own tmpfs with the right mount flags, which would require creating your own user+mount namespace; though I don't know if some distros maybe enable shmem THP by default or something like that. Bug impact: This issue can likely be used for user->kernel privilege escalation when it is reachable.", "cve_priority": "medium", "cve_public_date": "2024-10-23 06:15:00 UTC" }, { "cve": "CVE-2024-50202", "url": "https://ubuntu.com/security/CVE-2024-50202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: propagate directory read errors from nilfs_find_entry() Syzbot reported that a task hang occurs in vcs_open() during a fuzzing test for nilfs2. The root cause of this problem is that in nilfs_find_entry(), which searches for directory entries, ignores errors when loading a directory page/folio via nilfs_get_folio() fails. If the filesystem images is corrupted, and the i_size of the directory inode is large, and the directory page/folio is successfully read but fails the sanity check, for example when it is zero-filled, nilfs_check_folio() may continue to spit out error messages in bursts. Fix this issue by propagating the error to the callers when loading a page/folio fails in nilfs_find_entry(). The current interface of nilfs_find_entry() and its callers is outdated and cannot propagate error codes such as -EIO and -ENOMEM returned via nilfs_find_entry(), so fix it together.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50200", "url": "https://ubuntu.com/security/CVE-2024-50200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: maple_tree: correct tree corruption on spanning store Patch series \"maple_tree: correct tree corruption on spanning store\", v3. There has been a nasty yet subtle maple tree corruption bug that appears to have been in existence since the inception of the algorithm. This bug seems far more likely to happen since commit f8d112a4e657 (\"mm/mmap: avoid zeroing vma tree in mmap_region()\"), which is the point at which reports started to be submitted concerning this bug. We were made definitely aware of the bug thanks to the kind efforts of Bert Karwatzki who helped enormously in my being able to track this down and identify the cause of it. The bug arises when an attempt is made to perform a spanning store across two leaf nodes, where the right leaf node is the rightmost child of the shared parent, AND the store completely consumes the right-mode node. This results in mas_wr_spanning_store() mitakenly duplicating the new and existing entries at the maximum pivot within the range, and thus maple tree corruption. The fix patch corrects this by detecting this scenario and disallowing the mistaken duplicate copy. The fix patch commit message goes into great detail as to how this occurs. This series also includes a test which reliably reproduces the issue, and asserts that the fix works correctly. Bert has kindly tested the fix and confirmed it resolved his issues. Also Mikhail Gavrilov kindly reported what appears to be precisely the same bug, which this fix should also resolve. This patch (of 2): There has been a subtle bug present in the maple tree implementation from its inception. This arises from how stores are performed - when a store occurs, it will overwrite overlapping ranges and adjust the tree as necessary to accommodate this. A range may always ultimately span two leaf nodes. In this instance we walk the two leaf nodes, determine which elements are not overwritten to the left and to the right of the start and end of the ranges respectively and then rebalance the tree to contain these entries and the newly inserted one. This kind of store is dubbed a 'spanning store' and is implemented by mas_wr_spanning_store(). In order to reach this stage, mas_store_gfp() invokes mas_wr_preallocate(), mas_wr_store_type() and mas_wr_walk() in turn to walk the tree and update the object (mas) to traverse to the location where the write should be performed, determining its store type. When a spanning store is required, this function returns false stopping at the parent node which contains the target range, and mas_wr_store_type() marks the mas->store_type as wr_spanning_store to denote this fact. When we go to perform the store in mas_wr_spanning_store(), we first determine the elements AFTER the END of the range we wish to store (that is, to the right of the entry to be inserted) - we do this by walking to the NEXT pivot in the tree (i.e. r_mas.last + 1), starting at the node we have just determined contains the range over which we intend to write. We then turn our attention to the entries to the left of the entry we are inserting, whose state is represented by l_mas, and copy these into a 'big node', which is a special node which contains enough slots to contain two leaf node's worth of data. We then copy the entry we wish to store immediately after this - the copy and the insertion of the new entry is performed by mas_store_b_node(). After this we copy the elements to the right of the end of the range which we are inserting, if we have not exceeded the length of the node (i.e. r_mas.offset <= r_mas.end). Herein lies the bug - under very specific circumstances, this logic can break and corrupt the maple tree. Consider the following tree: Height 0 Root Node / \\ pivot = 0xffff / \\ pivot = ULONG_MAX / ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50084", "url": "https://ubuntu.com/security/CVE-2024-50084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: microchip: vcap api: Fix memory leaks in vcap_api_encode_rule_test() Commit a3c1e45156ad (\"net: microchip: vcap: Fix use-after-free error in kunit test\") fixed the use-after-free error, but introduced below memory leaks by removing necessary vcap_free_rule(), add it to fix it. \tunreferenced object 0xffffff80ca58b700 (size 192): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898264 \t hex dump (first 32 bytes): \t 00 12 7a 00 05 00 00 00 0a 00 00 00 64 00 00 00 ..z.........d... \t 00 00 00 00 00 00 00 00 00 04 0b cc 80 ff ff ff ................ \t backtrace (crc 9c09c3fe): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<0000000040a01b8d>] vcap_alloc_rule+0x3cc/0x9c4 \t [<000000003fe86110>] vcap_api_encode_rule_test+0x1ac/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0400 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898265 \t hex dump (first 32 bytes): \t 80 04 0b cc 80 ff ff ff 18 b7 58 ca 80 ff ff ff ..........X..... \t 39 00 00 00 02 00 00 00 06 05 04 03 02 01 ff ff 9............... \t backtrace (crc daf014e9): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<00000000dfdb1e81>] vcap_api_encode_rule_test+0x224/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0700 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898265 \t hex dump (first 32 bytes): \t 80 07 0b cc 80 ff ff ff 28 b7 58 ca 80 ff ff ff ........(.X..... \t 3c 00 00 00 00 00 00 00 01 2f 03 b3 ec ff ff ff <......../...... \t backtrace (crc 8d877792): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000006eadfab7>] vcap_rule_add_action+0x2d0/0x52c \t [<00000000323475d1>] vcap_api_encode_rule_test+0x4d4/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0900 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898266 \t hex dump (first 32 bytes): \t 80 09 0b cc 80 ff ff ff 80 06 0b cc 80 ff ff ff ................ \t 7d 00 00 00 01 00 00 00 00 00 00 00 ff 00 00 00 }............... \t backtrace (crc 34181e56): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<00000000991e3564>] vcap_val_rule+0xcf0/0x13e8 \t [<00000000fc9868e5>] vcap_api_encode_rule_test+0x678/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0980 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898266 \t hex dump (first 32 bytes): \t 18 b7 58 ca 80 ff ff ff 00 09 0b cc 80 ff ff ff ..X............. \t 67 00 00 00 00 00 00 00 01 01 74 88 c0 ff ff ff g.........t..... \t backtrace (crc 275fd9be): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<000000001396a1a2>] test_add_de ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50194", "url": "https://ubuntu.com/security/CVE-2024-50194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Fix uprobes for big-endian kernels The arm64 uprobes code is broken for big-endian kernels as it doesn't convert the in-memory instruction encoding (which is always little-endian) into the kernel's native endianness before analyzing and simulating instructions. This may result in a few distinct problems: * The kernel may may erroneously reject probing an instruction which can safely be probed. * The kernel may erroneously erroneously permit stepping an instruction out-of-line when that instruction cannot be stepped out-of-line safely. * The kernel may erroneously simulate instruction incorrectly dur to interpretting the byte-swapped encoding. The endianness mismatch isn't caught by the compiler or sparse because: * The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so the compiler and sparse have no idea these contain a little-endian 32-bit value. The core uprobes code populates these with a memcpy() which similarly does not handle endianness. * While the uprobe_opcode_t type is an alias for __le32, both arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[] to the similarly-named probe_opcode_t, which is an alias for u32. Hence there is no endianness conversion warning. Fix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and adding the appropriate __le32_to_cpu() conversions prior to consuming the instruction encoding. The core uprobes copies these fields as opaque ranges of bytes, and so is unaffected by this change. At the same time, remove MAX_UINSN_BYTES and consistently use AARCH64_INSN_SIZE for clarity. Tested with the following: | #include | #include | | #define noinline __attribute__((noinline)) | | static noinline void *adrp_self(void) | { | void *addr; | | asm volatile( | \" adrp %x0, adrp_self\\n\" | \" add %x0, %x0, :lo12:adrp_self\\n\" | : \"=r\" (addr)); | } | | | int main(int argc, char *argv) | { | void *ptr = adrp_self(); | bool equal = (ptr == adrp_self); | | printf(\"adrp_self => %p\\n\" | \"adrp_self() => %p\\n\" | \"%s\\n\", | adrp_self, ptr, equal ? \"EQUAL\" : \"NOT EQUAL\"); | | return 0; | } .... where the adrp_self() function was compiled to: | 00000000004007e0 : | 4007e0: 90000000 adrp x0, 400000 <__ehdr_start> | 4007e4: 911f8000 add x0, x0, #0x7e0 | 4007e8: d65f03c0 ret Before this patch, the ADRP is not recognized, and is assumed to be steppable, resulting in corruption of the result: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0xffffffffff7e0 | NOT EQUAL After this patch, the ADRP is correctly recognized and simulated: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50099", "url": "https://ubuntu.com/security/CVE-2024-50099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Remove broken LDR (literal) uprobe support The simulate_ldr_literal() and simulate_ldrsw_literal() functions are unsafe to use for uprobes. Both functions were originally written for use with kprobes, and access memory with plain C accesses. When uprobes was added, these were reused unmodified even though they cannot safely access user memory. There are three key problems: 1) The plain C accesses do not have corresponding extable entries, and thus if they encounter a fault the kernel will treat these as unintentional accesses to user memory, resulting in a BUG() which will kill the kernel thread, and likely lead to further issues (e.g. lockup or panic()). 2) The plain C accesses are subject to HW PAN and SW PAN, and so when either is in use, any attempt to simulate an access to user memory will fault. Thus neither simulate_ldr_literal() nor simulate_ldrsw_literal() can do anything useful when simulating a user instruction on any system with HW PAN or SW PAN. 3) The plain C accesses are privileged, as they run in kernel context, and in practice can access a small range of kernel virtual addresses. The instructions they simulate have a range of +/-1MiB, and since the simulated instructions must itself be a user instructions in the TTBR0 address range, these can address the final 1MiB of the TTBR1 acddress range by wrapping downwards from an address in the first 1MiB of the TTBR0 address range. In contemporary kernels the last 8MiB of TTBR1 address range is reserved, and accesses to this will always fault, meaning this is no worse than (1). Historically, it was theoretically possible for the linear map or vmemmap to spill into the final 8MiB of the TTBR1 address range, but in practice this is extremely unlikely to occur as this would require either: * Having enough physical memory to fill the entire linear map all the way to the final 1MiB of the TTBR1 address range. * Getting unlucky with KASLR randomization of the linear map such that the populated region happens to overlap with the last 1MiB of the TTBR address range. ... and in either case if we were to spill into the final page there would be larger problems as the final page would alias with error pointers. Practically speaking, (1) and (2) are the big issues. Given there have been no reports of problems since the broken code was introduced, it appears that no-one is relying on probing these instructions with uprobes. Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW (literal), limiting the use of simulate_ldr_literal() and simulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR (literal) and LDRSW (literal) will be rejected as arm_probe_decode_insn() will return INSN_REJECTED. In future we can consider introducing working uprobes support for these instructions, but this will require more significant work.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50195", "url": "https://ubuntu.com/security/CVE-2024-50195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-clock: Fix missing timespec64 check in pc_clock_settime() As Andrew pointed out, it will make sense that the PTP core checked timespec64 struct's tv_sec and tv_nsec range before calling ptp->info->settime64(). As the man manual of clock_settime() said, if tp.tv_sec is negative or tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL, which include dynamic clocks which handles PTP clock, and the condition is consistent with timespec64_valid(). As Thomas suggested, timespec64_valid() only check the timespec is valid, but not ensure that the time is in a valid range, so check it ahead using timespec64_valid_strict() in pc_clock_settime() and return -EINVAL if not valid. There are some drivers that use tp->tv_sec and tp->tv_nsec directly to write registers without validity checks and assume that the higher layer has checked it, which is dangerous and will benefit from this, such as hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(), and some drivers can remove the checks of itself.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50085", "url": "https://ubuntu.com/security/CVE-2024-50085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: fix UaF read in mptcp_pm_nl_rm_addr_or_subflow Syzkaller reported this splat: ================================================================== BUG: KASAN: slab-use-after-free in mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881 Read of size 4 at addr ffff8880569ac858 by task syz.1.2799/14662 CPU: 0 UID: 0 PID: 14662 Comm: syz.1.2799 Not tainted 6.12.0-rc2-syzkaller-00307-g36c254515dc6 #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+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881 mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:914 [inline] mptcp_nl_remove_id_zero_address+0x305/0x4a0 net/mptcp/pm_netlink.c:1572 mptcp_pm_nl_del_addr_doit+0x5c9/0x770 net/mptcp/pm_netlink.c:1603 genl_family_rcv_msg_doit+0x202/0x2f0 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x565/0x800 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x165/0x410 net/netlink/af_netlink.c:2551 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1331 [inline] netlink_unicast+0x53c/0x7f0 net/netlink/af_netlink.c:1357 netlink_sendmsg+0x8b8/0xd70 net/netlink/af_netlink.c:1901 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg net/socket.c:744 [inline] ____sys_sendmsg+0x9ae/0xb40 net/socket.c:2607 ___sys_sendmsg+0x135/0x1e0 net/socket.c:2661 __sys_sendmsg+0x117/0x1f0 net/socket.c:2690 do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline] __do_fast_syscall_32+0x73/0x120 arch/x86/entry/common.c:386 do_fast_syscall_32+0x32/0x80 arch/x86/entry/common.c:411 entry_SYSENTER_compat_after_hwframe+0x84/0x8e RIP: 0023:0xf7fe4579 Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00 RSP: 002b:00000000f574556c EFLAGS: 00000296 ORIG_RAX: 0000000000000172 RAX: ffffffffffffffda RBX: 000000000000000b RCX: 0000000020000140 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000296 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Allocated by task 5387: 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 kmalloc_noprof include/linux/slab.h:878 [inline] kzalloc_noprof include/linux/slab.h:1014 [inline] subflow_create_ctx+0x87/0x2a0 net/mptcp/subflow.c:1803 subflow_ulp_init+0xc3/0x4d0 net/mptcp/subflow.c:1956 __tcp_set_ulp net/ipv4/tcp_ulp.c:146 [inline] tcp_set_ulp+0x326/0x7f0 net/ipv4/tcp_ulp.c:167 mptcp_subflow_create_socket+0x4ae/0x10a0 net/mptcp/subflow.c:1764 __mptcp_subflow_connect+0x3cc/0x1490 net/mptcp/subflow.c:1592 mptcp_pm_create_subflow_or_signal_addr+0xbda/0x23a0 net/mptcp/pm_netlink.c:642 mptcp_pm_nl_fully_established net/mptcp/pm_netlink.c:650 [inline] mptcp_pm_nl_work+0x3a1/0x4f0 net/mptcp/pm_netlink.c:943 mptcp_worker+0x15a/0x1240 net/mptcp/protocol.c:2777 process_one_work+0x958/0x1b30 kernel/workqueue.c:3229 process_scheduled_works kernel/workqueue.c:3310 [inline] worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/ke ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50086", "url": "https://ubuntu.com/security/CVE-2024-50086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix user-after-free from session log off There is racy issue between smb2 session log off and smb2 session setup. It will cause user-after-free from session log off. This add session_lock when setting SMB2_SESSION_EXPIRED and referece count to session struct not to free session while it is being used.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50087", "url": "https://ubuntu.com/security/CVE-2024-50087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix uninitialized pointer free on read_alloc_one_name() error The function read_alloc_one_name() does not initialize the name field of the passed fscrypt_str struct if kmalloc fails to allocate the corresponding buffer. Thus, it is not guaranteed that fscrypt_str.name is initialized when freeing it. This is a follow-up to the linked patch that fixes the remaining instances of the bug introduced by commit e43eec81c516 (\"btrfs: use struct qstr instead of name and namelen pairs\").", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50088", "url": "https://ubuntu.com/security/CVE-2024-50088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix uninitialized pointer free in add_inode_ref() The add_inode_ref() function does not initialize the \"name\" struct when it is declared. If any of the following calls to \"read_one_inode() returns NULL, \tdir = read_one_inode(root, parent_objectid); \tif (!dir) { \t\tret = -ENOENT; \t\tgoto out; \t} \tinode = read_one_inode(root, inode_objectid); \tif (!inode) { \t\tret = -EIO; \t\tgoto out; \t} then \"name.name\" would be freed on \"out\" before being initialized. out: \t... \tkfree(name.name); This issue was reported by Coverity with CID 1526744.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50182", "url": "https://ubuntu.com/security/CVE-2024-50182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: secretmem: disable memfd_secret() if arch cannot set direct map Return -ENOSYS from memfd_secret() syscall if !can_set_direct_map(). This is the case for example on some arm64 configurations, where marking 4k PTEs in the direct map not present can only be done if the direct map is set up at 4k granularity in the first place (as ARM's break-before-make semantics do not easily allow breaking apart large/gigantic pages). More precisely, on arm64 systems with !can_set_direct_map(), set_direct_map_invalid_noflush() is a no-op, however it returns success (0) instead of an error. This means that memfd_secret will seemingly \"work\" (e.g. syscall succeeds, you can mmap the fd and fault in pages), but it does not actually achieve its goal of removing its memory from the direct map. Note that with this patch, memfd_secret() will start erroring on systems where can_set_direct_map() returns false (arm64 with CONFIG_RODATA_FULL_DEFAULT_ENABLED=n, CONFIG_DEBUG_PAGEALLOC=n and CONFIG_KFENCE=n), but that still seems better than the current silent failure. Since CONFIG_RODATA_FULL_DEFAULT_ENABLED defaults to 'y', most arm64 systems actually have a working memfd_secret() and aren't be affected. From going through the iterations of the original memfd_secret patch series, it seems that disabling the syscall in these scenarios was the intended behavior [1] (preferred over having set_direct_map_invalid_noflush return an error as that would result in SIGBUSes at page-fault time), however the check for it got dropped between v16 [2] and v17 [3], when secretmem moved away from CMA allocations. [1]: https://lore.kernel.org/lkml/20201124164930.GK8537@kernel.org/ [2]: https://lore.kernel.org/lkml/20210121122723.3446-11-rppt@kernel.org/#t [3]: https://lore.kernel.org/lkml/20201125092208.12544-10-rppt@kernel.org/", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50019", "url": "https://ubuntu.com/security/CVE-2024-50019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kthread: unpark only parked kthread Calling into kthread unparking unconditionally is mostly harmless when the kthread is already unparked. The wake up is then simply ignored because the target is not in TASK_PARKED state. However if the kthread is per CPU, the wake up is preceded by a call to kthread_bind() which expects the task to be inactive and in TASK_PARKED state, which obviously isn't the case if it is unparked. As a result, calling kthread_stop() on an unparked per-cpu kthread triggers such a warning: \tWARNING: CPU: 0 PID: 11 at kernel/kthread.c:525 __kthread_bind_mask kernel/kthread.c:525 \t \t kthread_stop+0x17a/0x630 kernel/kthread.c:707 \t destroy_workqueue+0x136/0xc40 kernel/workqueue.c:5810 \t wg_destruct+0x1e2/0x2e0 drivers/net/wireguard/device.c:257 \t netdev_run_todo+0xe1a/0x1000 net/core/dev.c:10693 \t default_device_exit_batch+0xa14/0xa90 net/core/dev.c:11769 \t ops_exit_list net/core/net_namespace.c:178 [inline] \t cleanup_net+0x89d/0xcc0 net/core/net_namespace.c:640 \t process_one_work kernel/workqueue.c:3231 [inline] \t process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 \t worker_thread+0x86d/0xd70 kernel/workqueue.c:3393 \t kthread+0x2f0/0x390 kernel/kthread.c:389 \t ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 \t ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 \t Fix this with skipping unecessary unparking while stopping a kthread.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50096", "url": "https://ubuntu.com/security/CVE-2024-50096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/dmem: Fix vulnerability in migrate_to_ram upon copy error The `nouveau_dmem_copy_one` function ensures that the copy push command is sent to the device firmware but does not track whether it was executed successfully. In the case of a copy error (e.g., firmware or hardware failure), the copy push command will be sent via the firmware channel, and `nouveau_dmem_copy_one` will likely report success, leading to the `migrate_to_ram` function returning a dirty HIGH_USER page to the user. This can result in a security vulnerability, as a HIGH_USER page that may contain sensitive or corrupted data could be returned to the user. To prevent this vulnerability, we allocate a zero page. Thus, in case of an error, a non-dirty (zero) page will be returned to the user.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50020", "url": "https://ubuntu.com/security/CVE-2024-50020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix improper handling of refcount in ice_sriov_set_msix_vec_count() This patch addresses an issue with improper reference count handling in the ice_sriov_set_msix_vec_count() function. First, the function calls ice_get_vf_by_id(), which increments the reference count of the vf pointer. If the subsequent call to ice_get_vf_vsi() fails, the function currently returns an error without decrementing the reference count of the vf pointer, leading to a reference count leak. The correct behavior, as implemented in this patch, is to decrement the reference count using ice_put_vf(vf) before returning an error when vsi is NULL. Second, the function calls ice_sriov_get_irqs(), which sets vf->first_vector_idx. If this call returns a negative value, indicating an error, the function returns an error without decrementing the reference count of the vf pointer, resulting in another reference count leak. The patch addresses this by adding a call to ice_put_vf(vf) before returning an error when vf->first_vector_idx < 0. This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and identifying potential mismanagement of reference counts. In this case, the tool flagged the missing decrement operation as a potential issue, leading to this patch.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50021", "url": "https://ubuntu.com/security/CVE-2024-50021", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix improper handling of refcount in ice_dpll_init_rclk_pins() This patch addresses a reference count handling issue in the ice_dpll_init_rclk_pins() function. The function calls ice_dpll_get_pins(), which increments the reference count of the relevant resources. However, if the condition WARN_ON((!vsi || !vsi->netdev)) is met, the function currently returns an error without properly releasing the resources acquired by ice_dpll_get_pins(), leading to a reference count leak. To resolve this, the check has been moved to the top of the function. This ensures that the function verifies the state before any resources are acquired, avoiding the need for additional resource management in the error path. This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and detecting potential issues where resources are not properly managed. In this case, the tool flagged the missing release operation as a potential problem, which led to the development of this patch.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50022", "url": "https://ubuntu.com/security/CVE-2024-50022", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: device-dax: correct pgoff align in dax_set_mapping() pgoff should be aligned using ALIGN_DOWN() instead of ALIGN(). Otherwise, vmf->address not aligned to fault_size will be aligned to the next alignment, that can result in memory failure getting the wrong address. It's a subtle situation that only can be observed in page_mapped_in_vma() after the page is page fault handled by dev_dax_huge_fault. Generally, there is little chance to perform page_mapped_in_vma in dev-dax's page unless in specific error injection to the dax device to trigger an MCE - memory-failure. In that case, page_mapped_in_vma() will be triggered to determine which task is accessing the failure address and kill that task in the end. We used self-developed dax device (which is 2M aligned mapping) , to perform error injection to random address. It turned out that error injected to non-2M-aligned address was causing endless MCE until panic. Because page_mapped_in_vma() kept resulting wrong address and the task accessing the failure address was never killed properly: [ 3783.719419] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.049006] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.049190] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.448042] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.448186] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.792026] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.792179] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.162502] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.162633] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.461116] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.461247] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.764730] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.764859] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.042128] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.042259] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.464293] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.464423] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.818090] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.818217] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3787.085297] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3787.085424] Memory failure: 0x200c9742: recovery action for dax page: Recovered It took us several weeks to pinpoint this problem,  but we eventually used bpftrace to trace the page fault and mce address and successfully identified the issue. Joao added: ; Likely we never reproduce in production because we always pin : device-dax regions in the region align they provide (Qemu does : similarly with prealloc in hugetlb/file backed memory). I think this : bug requires that we touch *unpinned* device-dax regions unaligned to : the device-dax selected alignment (page size i.e. 4K/2M/1G)", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50185", "url": "https://ubuntu.com/security/CVE-2024-50185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: handle consistently DSS corruption Bugged peer implementation can send corrupted DSS options, consistently hitting a few warning in the data path. Use DEBUG_NET assertions, to avoid the splat on some builds and handle consistently the error, dumping related MIBs and performing fallback and/or reset according to the subflow type.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50023", "url": "https://ubuntu.com/security/CVE-2024-50023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: Remove LED entry from LEDs list on unregister Commit c938ab4da0eb (\"net: phy: Manual remove LEDs to ensure correct ordering\") correctly fixed a problem with using devm_ but missed removing the LED entry from the LEDs list. This cause kernel panic on specific scenario where the port for the PHY is torn down and up and the kmod for the PHY is removed. On setting the port down the first time, the assosiacted LEDs are correctly unregistered. The associated kmod for the PHY is now removed. The kmod is now added again and the port is now put up, the associated LED are registered again. On putting the port down again for the second time after these step, the LED list now have 4 elements. With the first 2 already unregistered previously and the 2 new one registered again. This cause a kernel panic as the first 2 element should have been removed. Fix this by correctly removing the element when LED is unregistered.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50024", "url": "https://ubuntu.com/security/CVE-2024-50024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: Fix an unsafe loop on the list The kernel may crash when deleting a genetlink family if there are still listeners for that family: Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c000000000c080bc] netlink_update_socket_mc+0x3c/0xc0 LR [c000000000c0f764] __netlink_clear_multicast_users+0x74/0xc0 Call Trace: __netlink_clear_multicast_users+0x74/0xc0 genl_unregister_family+0xd4/0x2d0 Change the unsafe loop on the list to a safe one, because inside the loop there is an element removal from this list.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50186", "url": "https://ubuntu.com/security/CVE-2024-50186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: explicitly clear the sk pointer, when pf->create fails We have recently noticed the exact same KASAN splat as in commit 6cd4a78d962b (\"net: do not leave a dangling sk pointer, when socket creation fails\"). The problem is that commit did not fully address the problem, as some pf->create implementations do not use sk_common_release in their error paths. For example, we can use the same reproducer as in the above commit, but changing ping to arping. arping uses AF_PACKET socket and if packet_create fails, it will just sk_free the allocated sk object. While we could chase all the pf->create implementations and make sure they NULL the freed sk object on error from the socket, we can't guarantee future protocols will not make the same mistake. So it is easier to just explicitly NULL the sk pointer upon return from pf->create in __sock_create. We do know that pf->create always releases the allocated sk object on error, so if the pointer is not NULL, it is definitely dangling.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50025", "url": "https://ubuntu.com/security/CVE-2024-50025", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: fnic: Move flush_work initialization out of if block After commit 379a58caa199 (\"scsi: fnic: Move fnic_fnic_flush_tx() to a work queue\"), it can happen that a work item is sent to an uninitialized work queue. This may has the effect that the item being queued is never actually queued, and any further actions depending on it will not proceed. The following warning is observed while the fnic driver is loaded: kernel: WARNING: CPU: 11 PID: 0 at ../kernel/workqueue.c:1524 __queue_work+0x373/0x410 kernel: kernel: queue_work_on+0x3a/0x50 kernel: fnic_wq_copy_cmpl_handler+0x54a/0x730 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: fnic_isr_msix_wq_copy+0x2d/0x60 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: __handle_irq_event_percpu+0x36/0x1a0 kernel: handle_irq_event_percpu+0x30/0x70 kernel: handle_irq_event+0x34/0x60 kernel: handle_edge_irq+0x7e/0x1a0 kernel: __common_interrupt+0x3b/0xb0 kernel: common_interrupt+0x58/0xa0 kernel: It has been observed that this may break the rediscovery of Fibre Channel devices after a temporary fabric failure. This patch fixes it by moving the work queue initialization out of an if block in fnic_probe().", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50026", "url": "https://ubuntu.com/security/CVE-2024-50026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: wd33c93: Don't use stale scsi_pointer value A regression was introduced with commit dbb2da557a6a (\"scsi: wd33c93: Move the SCSI pointer to private command data\") which results in an oops in wd33c93_intr(). That commit added the scsi_pointer variable and initialized it from hostdata->connected. However, during selection, hostdata->connected is not yet valid. Fix this by getting the current scsi_pointer from hostdata->selecting.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50027", "url": "https://ubuntu.com/security/CVE-2024-50027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: core: Free tzp copy along with the thermal zone The object pointed to by tz->tzp may still be accessed after being freed in thermal_zone_device_unregister(), so move the freeing of it to the point after the removal completion has been completed at which it cannot be accessed any more.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50028", "url": "https://ubuntu.com/security/CVE-2024-50028", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: core: Reference count the zone in thermal_zone_get_by_id() There are places in the thermal netlink code where nothing prevents the thermal zone object from going away while being accessed after it has been returned by thermal_zone_get_by_id(). To address this, make thermal_zone_get_by_id() get a reference on the thermal zone device object to be returned with the help of get_device(), under thermal_list_lock, and adjust all of its callers to this change with the help of the cleanup.h infrastructure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50029", "url": "https://ubuntu.com/security/CVE-2024-50029", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_conn: Fix UAF in hci_enhanced_setup_sync This checks if the ACL connection remains valid as it could be destroyed while hci_enhanced_setup_sync is pending on cmd_sync leading to the following trace: BUG: KASAN: slab-use-after-free in hci_enhanced_setup_sync+0x91b/0xa60 Read of size 1 at addr ffff888002328ffd by task kworker/u5:2/37 CPU: 0 UID: 0 PID: 37 Comm: kworker/u5:2 Not tainted 6.11.0-rc6-01300-g810be445d8d6 #7099 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Workqueue: hci0 hci_cmd_sync_work Call Trace: dump_stack_lvl+0x5d/0x80 ? hci_enhanced_setup_sync+0x91b/0xa60 print_report+0x152/0x4c0 ? hci_enhanced_setup_sync+0x91b/0xa60 ? __virt_addr_valid+0x1fa/0x420 ? hci_enhanced_setup_sync+0x91b/0xa60 kasan_report+0xda/0x1b0 ? hci_enhanced_setup_sync+0x91b/0xa60 hci_enhanced_setup_sync+0x91b/0xa60 ? __pfx_hci_enhanced_setup_sync+0x10/0x10 ? __pfx___mutex_lock+0x10/0x10 hci_cmd_sync_work+0x1c2/0x330 process_one_work+0x7d9/0x1360 ? __pfx_lock_acquire+0x10/0x10 ? __pfx_process_one_work+0x10/0x10 ? assign_work+0x167/0x240 worker_thread+0x5b7/0xf60 ? __kthread_parkme+0xac/0x1c0 ? __pfx_worker_thread+0x10/0x10 ? __pfx_worker_thread+0x10/0x10 kthread+0x293/0x360 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2f/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 34: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __hci_conn_add+0x187/0x17d0 hci_connect_sco+0x2e1/0xb90 sco_sock_connect+0x2a2/0xb80 __sys_connect+0x227/0x2a0 __x64_sys_connect+0x6d/0xb0 do_syscall_64+0x71/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 37: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x101/0x160 kfree+0xd0/0x250 device_release+0x9a/0x210 kobject_put+0x151/0x280 hci_conn_del+0x448/0xbf0 hci_abort_conn_sync+0x46f/0x980 hci_cmd_sync_work+0x1c2/0x330 process_one_work+0x7d9/0x1360 worker_thread+0x5b7/0xf60 kthread+0x293/0x360 ret_from_fork+0x2f/0x70 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50030", "url": "https://ubuntu.com/security/CVE-2024-50030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/ct: prevent UAF in send_recv() Ensure we serialize with completion side to prevent UAF with fence going out of scope on the stack, since we have no clue if it will fire after the timeout before we can erase from the xa. Also we have some dependent loads and stores for which we need the correct ordering, and we lack the needed barriers. Fix this by grabbing the ct->lock after the wait, which is also held by the completion side. v2 (Badal): - Also print done after acquiring the lock and seeing timeout. (cherry picked from commit 52789ce35c55ccd30c4b67b9cc5b2af55e0122ea)", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50187", "url": "https://ubuntu.com/security/CVE-2024-50187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Stop the active perfmon before being destroyed Upon closing the file descriptor, the active performance monitor is not stopped. Although all perfmons are destroyed in `vc4_perfmon_close_file()`, the active performance monitor's pointer (`vc4->active_perfmon`) is still retained. If we open a new file descriptor and submit a few jobs with performance monitors, the driver will attempt to stop the active performance monitor using the stale pointer in `vc4->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50031", "url": "https://ubuntu.com/security/CVE-2024-50031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Stop the active perfmon before being destroyed When running `kmscube` with one or more performance monitors enabled via `GALLIUM_HUD`, the following kernel panic can occur: [ 55.008324] Unable to handle kernel paging request at virtual address 00000000052004a4 [ 55.008368] Mem abort info: [ 55.008377] ESR = 0x0000000096000005 [ 55.008387] EC = 0x25: DABT (current EL), IL = 32 bits [ 55.008402] SET = 0, FnV = 0 [ 55.008412] EA = 0, S1PTW = 0 [ 55.008421] FSC = 0x05: level 1 translation fault [ 55.008434] Data abort info: [ 55.008442] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 55.008455] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 55.008467] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 55.008481] user pgtable: 4k pages, 39-bit VAs, pgdp=00000001046c6000 [ 55.008497] [00000000052004a4] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 55.008525] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP [ 55.008542] Modules linked in: rfcomm [...] vc4 v3d snd_soc_hdmi_codec drm_display_helper gpu_sched drm_shmem_helper cec drm_dma_helper drm_kms_helper i2c_brcmstb drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight [ 55.008799] CPU: 2 PID: 166 Comm: v3d_bin Tainted: G C 6.6.47+rpt-rpi-v8 #1 Debian 1:6.6.47-1+rpt1 [ 55.008824] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [ 55.008838] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 55.008855] pc : __mutex_lock.constprop.0+0x90/0x608 [ 55.008879] lr : __mutex_lock.constprop.0+0x58/0x608 [ 55.008895] sp : ffffffc080673cf0 [ 55.008904] x29: ffffffc080673cf0 x28: 0000000000000000 x27: ffffff8106188a28 [ 55.008926] x26: ffffff8101e78040 x25: ffffff8101baa6c0 x24: ffffffd9d989f148 [ 55.008947] x23: ffffffda1c2a4008 x22: 0000000000000002 x21: ffffffc080673d38 [ 55.008968] x20: ffffff8101238000 x19: ffffff8104f83188 x18: 0000000000000000 [ 55.008988] x17: 0000000000000000 x16: ffffffda1bd04d18 x15: 00000055bb08bc90 [ 55.009715] x14: 0000000000000000 x13: 0000000000000000 x12: ffffffda1bd4cbb0 [ 55.010433] x11: 00000000fa83b2da x10: 0000000000001a40 x9 : ffffffda1bd04d04 [ 55.011162] x8 : ffffff8102097b80 x7 : 0000000000000000 x6 : 00000000030a5857 [ 55.011880] x5 : 00ffffffffffffff x4 : 0300000005200470 x3 : 0300000005200470 [ 55.012598] x2 : ffffff8101238000 x1 : 0000000000000021 x0 : 0300000005200470 [ 55.013292] Call trace: [ 55.013959] __mutex_lock.constprop.0+0x90/0x608 [ 55.014646] __mutex_lock_slowpath+0x1c/0x30 [ 55.015317] mutex_lock+0x50/0x68 [ 55.015961] v3d_perfmon_stop+0x40/0xe0 [v3d] [ 55.016627] v3d_bin_job_run+0x10c/0x2d8 [v3d] [ 55.017282] drm_sched_main+0x178/0x3f8 [gpu_sched] [ 55.017921] kthread+0x11c/0x128 [ 55.018554] ret_from_fork+0x10/0x20 [ 55.019168] Code: f9400260 f1001c1f 54001ea9 927df000 (b9403401) [ 55.019776] ---[ end trace 0000000000000000 ]--- [ 55.020411] note: v3d_bin[166] exited with preempt_count 1 This issue arises because, upon closing the file descriptor (which happens when we interrupt `kmscube`), the active performance monitor is not stopped. Although all perfmons are destroyed in `v3d_perfmon_close_file()`, the active performance monitor's pointer (`v3d->active_perfmon`) is still retained. If `kmscube` is run again, the driver will attempt to stop the active performance monitor using the stale pointer in `v3d->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50189", "url": "https://ubuntu.com/security/CVE-2024-50189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: amd_sfh: Switch to device-managed dmam_alloc_coherent() Using the device-managed version allows to simplify clean-up in probe() error path. Additionally, this device-managed ensures proper cleanup, which helps to resolve memory errors, page faults, btrfs going read-only, and btrfs disk corruption.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50033", "url": "https://ubuntu.com/security/CVE-2024-50033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slip: make slhc_remember() more robust against malicious packets syzbot found that slhc_remember() was missing checks against malicious packets [1]. slhc_remember() only checked the size of the packet was at least 20, which is not good enough. We need to make sure the packet includes the IPv4 and TCP header that are supposed to be carried. Add iph and th pointers to make the code more readable. [1] BUG: KMSAN: uninit-value in slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 ppp_receive_nonmp_frame+0xe45/0x35e0 drivers/net/ppp/ppp_generic.c:2455 ppp_receive_frame drivers/net/ppp/ppp_generic.c:2372 [inline] ppp_do_recv+0x65f/0x40d0 drivers/net/ppp/ppp_generic.c:2212 ppp_input+0x7dc/0xe60 drivers/net/ppp/ppp_generic.c:2327 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 Uninit was created at: slab_post_alloc_hook mm/slub.c:4091 [inline] slab_alloc_node mm/slub.c:4134 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 CPU: 0 UID: 0 PID: 5460 Comm: syz.2.33 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50034", "url": "https://ubuntu.com/security/CVE-2024-50034", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix lacks of icsk_syn_mss with IPPROTO_SMC Eric report a panic on IPPROTO_SMC, and give the facts that when INET_PROTOSW_ICSK was set, icsk->icsk_sync_mss must be set too. Bug: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000086000005 EC = 0x21: IABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault user pgtable: 4k pages, 48-bit VAs, pgdp=00000001195d1000 [0000000000000000] pgd=0800000109c46003, p4d=0800000109c46003, pud=0000000000000000 Internal error: Oops: 0000000086000005 [#1] PREEMPT SMP Modules linked in: CPU: 1 UID: 0 PID: 8037 Comm: syz.3.265 Not tainted 6.11.0-rc7-syzkaller-g5f5673607153 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0x0 lr : cipso_v4_sock_setattr+0x2a8/0x3c0 net/ipv4/cipso_ipv4.c:1910 sp : ffff80009b887a90 x29: ffff80009b887aa0 x28: ffff80008db94050 x27: 0000000000000000 x26: 1fffe0001aa6f5b3 x25: dfff800000000000 x24: ffff0000db75da00 x23: 0000000000000000 x22: ffff0000d8b78518 x21: 0000000000000000 x20: ffff0000d537ad80 x19: ffff0000d8b78000 x18: 1fffe000366d79ee x17: ffff8000800614a8 x16: ffff800080569b84 x15: 0000000000000001 x14: 000000008b336894 x13: 00000000cd96feaa x12: 0000000000000003 x11: 0000000000040000 x10: 00000000000020a3 x9 : 1fffe0001b16f0f1 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 000000000000003f x5 : 0000000000000040 x4 : 0000000000000001 x3 : 0000000000000000 x2 : 0000000000000002 x1 : 0000000000000000 x0 : ffff0000d8b78000 Call trace: 0x0 netlbl_sock_setattr+0x2e4/0x338 net/netlabel/netlabel_kapi.c:1000 smack_netlbl_add+0xa4/0x154 security/smack/smack_lsm.c:2593 smack_socket_post_create+0xa8/0x14c security/smack/smack_lsm.c:2973 security_socket_post_create+0x94/0xd4 security/security.c:4425 __sock_create+0x4c8/0x884 net/socket.c:1587 sock_create net/socket.c:1622 [inline] __sys_socket_create net/socket.c:1659 [inline] __sys_socket+0x134/0x340 net/socket.c:1706 __do_sys_socket net/socket.c:1720 [inline] __se_sys_socket net/socket.c:1718 [inline] __arm64_sys_socket+0x7c/0x94 net/socket.c:1718 __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:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 Code: ???????? ???????? ???????? ???????? (????????) ---[ end trace 0000000000000000 ]--- This patch add a toy implementation that performs a simple return to prevent such panic. This is because MSS can be set in sock_create_kern or smc_setsockopt, similar to how it's done in AF_SMC. However, for AF_SMC, there is currently no way to synchronize MSS within __sys_connect_file. This toy implementation lays the groundwork for us to support such feature for IPPROTO_SMC in the future.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50035", "url": "https://ubuntu.com/security/CVE-2024-50035", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: fix ppp_async_encode() illegal access syzbot reported an issue in ppp_async_encode() [1] In this case, pppoe_sendmsg() is called with a zero size. Then ppp_async_encode() is called with an empty skb. BUG: KMSAN: uninit-value in ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] BUG: KMSAN: uninit-value in ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_send+0x130/0x1b0 drivers/net/ppp/ppp_async.c:634 ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2280 [inline] ppp_input+0x1f1/0xe60 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 Uninit was created at: slab_post_alloc_hook mm/slub.c:4092 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4187 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 CPU: 1 UID: 0 PID: 5411 Comm: syz.1.14 Not tainted 6.12.0-rc1-syzkaller-00165-g360c1f1f24c6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50036", "url": "https://ubuntu.com/security/CVE-2024-50036", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: do not delay dst_entries_add() in dst_release() dst_entries_add() uses per-cpu data that might be freed at netns dismantle from ip6_route_net_exit() calling dst_entries_destroy() Before ip6_route_net_exit() can be called, we release all the dsts associated with this netns, via calls to dst_release(), which waits an rcu grace period before calling dst_destroy() dst_entries_add() use in dst_destroy() is racy, because dst_entries_destroy() could have been called already. Decrementing the number of dsts must happen sooner. Notes: 1) in CONFIG_XFRM case, dst_destroy() can call dst_release_immediate(child), this might also cause UAF if the child does not have DST_NOCOUNT set. IPSEC maintainers might take a look and see how to address this. 2) There is also discussion about removing this count of dst, which might happen in future kernels.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50037", "url": "https://ubuntu.com/security/CVE-2024-50037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/fbdev-dma: Only cleanup deferred I/O if necessary Commit 5a498d4d06d6 (\"drm/fbdev-dma: Only install deferred I/O if necessary\") initializes deferred I/O only if it is used. drm_fbdev_dma_fb_destroy() however calls fb_deferred_io_cleanup() unconditionally with struct fb_info.fbdefio == NULL. KASAN with the out-of-tree Apple silicon display driver posts following warning from __flush_work() of a random struct work_struct instead of the expected NULL pointer derefs. [ 22.053799] ------------[ cut here ]------------ [ 22.054832] WARNING: CPU: 2 PID: 1 at kernel/workqueue.c:4177 __flush_work+0x4d8/0x580 [ 22.056597] Modules linked in: uhid bnep uinput nls_ascii ip6_tables ip_tables i2c_dev loop fuse dm_multipath nfnetlink zram hid_magicmouse btrfs xor xor_neon brcmfmac_wcc raid6_pq hci_bcm4377 bluetooth brcmfmac hid_apple brcmutil nvmem_spmi_mfd simple_mfd_spmi dockchannel_hid cfg80211 joydev regmap_spmi nvme_apple ecdh_generic ecc macsmc_hid rfkill dwc3 appledrm snd_soc_macaudio macsmc_power nvme_core apple_isp phy_apple_atc apple_sart apple_rtkit_helper apple_dockchannel tps6598x macsmc_hwmon snd_soc_cs42l84 videobuf2_v4l2 spmi_apple_controller nvmem_apple_efuses videobuf2_dma_sg apple_z2 videobuf2_memops spi_nor panel_summit videobuf2_common asahi videodev pwm_apple apple_dcp snd_soc_apple_mca apple_admac spi_apple clk_apple_nco i2c_pasemi_platform snd_pcm_dmaengine mc i2c_pasemi_core mux_core ofpart adpdrm drm_dma_helper apple_dart apple_soc_cpufreq leds_pwm phram [ 22.073768] CPU: 2 UID: 0 PID: 1 Comm: systemd-shutdow Not tainted 6.11.2-asahi+ #asahi-dev [ 22.075612] Hardware name: Apple MacBook Pro (13-inch, M2, 2022) (DT) [ 22.077032] pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 22.078567] pc : __flush_work+0x4d8/0x580 [ 22.079471] lr : __flush_work+0x54/0x580 [ 22.080345] sp : ffffc000836ef820 [ 22.081089] x29: ffffc000836ef880 x28: 0000000000000000 x27: ffff80002ddb7128 [ 22.082678] x26: dfffc00000000000 x25: 1ffff000096f0c57 x24: ffffc00082d3e358 [ 22.084263] x23: ffff80004b7862b8 x22: dfffc00000000000 x21: ffff80005aa1d470 [ 22.085855] x20: ffff80004b786000 x19: ffff80004b7862a0 x18: 0000000000000000 [ 22.087439] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000005 [ 22.089030] x14: 1ffff800106ddf0a x13: 0000000000000000 x12: 0000000000000000 [ 22.090618] x11: ffffb800106ddf0f x10: dfffc00000000000 x9 : 1ffff800106ddf0e [ 22.092206] x8 : 0000000000000000 x7 : aaaaaaaaaaaaaaaa x6 : 0000000000000001 [ 22.093790] x5 : ffffc000836ef728 x4 : 0000000000000000 x3 : 0000000000000020 [ 22.095368] x2 : 0000000000000008 x1 : 00000000000000aa x0 : 0000000000000000 [ 22.096955] Call trace: [ 22.097505] __flush_work+0x4d8/0x580 [ 22.098330] flush_delayed_work+0x80/0xb8 [ 22.099231] fb_deferred_io_cleanup+0x3c/0x130 [ 22.100217] drm_fbdev_dma_fb_destroy+0x6c/0xe0 [drm_dma_helper] [ 22.101559] unregister_framebuffer+0x210/0x2f0 [ 22.102575] drm_fb_helper_unregister_info+0x48/0x60 [ 22.103683] drm_fbdev_dma_client_unregister+0x4c/0x80 [drm_dma_helper] [ 22.105147] drm_client_dev_unregister+0x1cc/0x230 [ 22.106217] drm_dev_unregister+0x58/0x570 [ 22.107125] apple_drm_unbind+0x50/0x98 [appledrm] [ 22.108199] component_del+0x1f8/0x3a8 [ 22.109042] dcp_platform_shutdown+0x24/0x38 [apple_dcp] [ 22.110357] platform_shutdown+0x70/0x90 [ 22.111219] device_shutdown+0x368/0x4d8 [ 22.112095] kernel_restart+0x6c/0x1d0 [ 22.112946] __arm64_sys_reboot+0x1c8/0x328 [ 22.113868] invoke_syscall+0x78/0x1a8 [ 22.114703] do_el0_svc+0x124/0x1a0 [ 22.115498] el0_svc+0x3c/0xe0 [ 22.116181] el0t_64_sync_handler+0x70/0xc0 [ 22.117110] el0t_64_sync+0x190/0x198 [ 22.117931] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50092", "url": "https://ubuntu.com/security/CVE-2024-50092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netconsole: fix wrong warning A warning is triggered when there is insufficient space in the buffer for userdata. However, this is not an issue since userdata will be sent in the next iteration. Current warning message: ------------[ cut here ]------------ WARNING: CPU: 13 PID: 3013042 at drivers/net/netconsole.c:1122 write_ext_msg+0x3b6/0x3d0 ? write_ext_msg+0x3b6/0x3d0 console_flush_all+0x1e9/0x330 The code incorrectly issues a warning when this_chunk is zero, which is a valid scenario. The warning should only be triggered when this_chunk is negative.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50038", "url": "https://ubuntu.com/security/CVE-2024-50038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xtables: avoid NFPROTO_UNSPEC where needed syzbot managed to call xt_cluster match via ebtables: WARNING: CPU: 0 PID: 11 at net/netfilter/xt_cluster.c:72 xt_cluster_mt+0x196/0x780 [..] ebt_do_table+0x174b/0x2a40 Module registers to NFPROTO_UNSPEC, but it assumes ipv4/ipv6 packet processing. As this is only useful to restrict locally terminating TCP/UDP traffic, register this for ipv4 and ipv6 family only. Pablo points out that this is a general issue, direct users of the set/getsockopt interface can call into targets/matches that were only intended for use with ip(6)tables. Check all UNSPEC matches and targets for similar issues: - matches and targets are fine except if they assume skb_network_header() is valid -- this is only true when called from inet layer: ip(6) stack pulls the ip/ipv6 header into linear data area. - targets that return XT_CONTINUE or other xtables verdicts must be restricted too, they are incompatbile with the ebtables traverser, e.g. EBT_CONTINUE is a completely different value than XT_CONTINUE. Most matches/targets are changed to register for NFPROTO_IPV4/IPV6, as they are provided for use by ip(6)tables. The MARK target is also used by arptables, so register for NFPROTO_ARP too. While at it, bail out if connbytes fails to enable the corresponding conntrack family. This change passes the selftests in iptables.git.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50039", "url": "https://ubuntu.com/security/CVE-2024-50039", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: accept TCA_STAB only for root qdisc Most qdiscs maintain their backlog using qdisc_pkt_len(skb) on the assumption it is invariant between the enqueue() and dequeue() handlers. Unfortunately syzbot can crash a host rather easily using a TBF + SFQ combination, with an STAB on SFQ [1] We can't support TCA_STAB on arbitrary level, this would require to maintain per-qdisc storage. [1] [ 88.796496] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 88.798611] #PF: supervisor read access in kernel mode [ 88.799014] #PF: error_code(0x0000) - not-present page [ 88.799506] PGD 0 P4D 0 [ 88.799829] Oops: Oops: 0000 [#1] SMP NOPTI [ 88.800569] CPU: 14 UID: 0 PID: 2053 Comm: b371744477 Not tainted 6.12.0-rc1-virtme #1117 [ 88.801107] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 88.801779] RIP: 0010:sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq [ 88.802544] Code: 0f b7 50 12 48 8d 04 d5 00 00 00 00 48 89 d6 48 29 d0 48 8b 91 c0 01 00 00 48 c1 e0 03 48 01 c2 66 83 7a 1a 00 7e c0 48 8b 3a <4c> 8b 07 4c 89 02 49 89 50 08 48 c7 47 08 00 00 00 00 48 c7 07 00 All code ======== 0:\t0f b7 50 12 \tmovzwl 0x12(%rax),%edx 4:\t48 8d 04 d5 00 00 00 \tlea 0x0(,%rdx,8),%rax b:\t00 c:\t48 89 d6 \tmov %rdx,%rsi f:\t48 29 d0 \tsub %rdx,%rax 12:\t48 8b 91 c0 01 00 00 \tmov 0x1c0(%rcx),%rdx 19:\t48 c1 e0 03 \tshl $0x3,%rax 1d:\t48 01 c2 \tadd %rax,%rdx 20:\t66 83 7a 1a 00 \tcmpw $0x0,0x1a(%rdx) 25:\t7e c0 \tjle 0xffffffffffffffe7 27:\t48 8b 3a \tmov (%rdx),%rdi 2a:*\t4c 8b 07 \tmov (%rdi),%r8\t\t<-- trapping instruction 2d:\t4c 89 02 \tmov %r8,(%rdx) 30:\t49 89 50 08 \tmov %rdx,0x8(%r8) 34:\t48 c7 47 08 00 00 00 \tmovq $0x0,0x8(%rdi) 3b:\t00 3c:\t48 \trex.W 3d:\tc7 \t.byte 0xc7 3e:\t07 \t(bad) \t... Code starting with the faulting instruction =========================================== 0:\t4c 8b 07 \tmov (%rdi),%r8 3:\t4c 89 02 \tmov %r8,(%rdx) 6:\t49 89 50 08 \tmov %rdx,0x8(%r8) a:\t48 c7 47 08 00 00 00 \tmovq $0x0,0x8(%rdi) 11:\t00 12:\t48 \trex.W 13:\tc7 \t.byte 0xc7 14:\t07 \t(bad) \t... [ 88.803721] RSP: 0018:ffff9a1f892b7d58 EFLAGS: 00000206 [ 88.804032] RAX: 0000000000000000 RBX: ffff9a1f8420c800 RCX: ffff9a1f8420c800 [ 88.804560] RDX: ffff9a1f81bc1440 RSI: 0000000000000000 RDI: 0000000000000000 [ 88.805056] RBP: ffffffffc04bb0e0 R08: 0000000000000001 R09: 00000000ff7f9a1f [ 88.805473] R10: 000000000001001b R11: 0000000000009a1f R12: 0000000000000140 [ 88.806194] R13: 0000000000000001 R14: ffff9a1f886df400 R15: ffff9a1f886df4ac [ 88.806734] FS: 00007f445601a740(0000) GS:ffff9a2e7fd80000(0000) knlGS:0000000000000000 [ 88.807225] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 88.807672] CR2: 0000000000000000 CR3: 000000050cc46000 CR4: 00000000000006f0 [ 88.808165] Call Trace: [ 88.808459] [ 88.808710] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434) [ 88.809261] ? page_fault_oops (arch/x86/mm/fault.c:715) [ 88.809561] ? exc_page_fault (./arch/x86/include/asm/irqflags.h:26 ./arch/x86/include/asm/irqflags.h:87 ./arch/x86/include/asm/irqflags.h:147 arch/x86/mm/fault.c:1489 arch/x86/mm/fault.c:1539) [ 88.809806] ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623) [ 88.810074] ? sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq [ 88.810411] sfq_reset (net/sched/sch_sfq.c:525) sch_sfq [ 88.810671] qdisc_reset (./include/linux/skbuff.h:2135 ./include/linux/skbuff.h:2441 ./include/linux/skbuff.h:3304 ./include/linux/skbuff.h:3310 net/sched/sch_g ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50040", "url": "https://ubuntu.com/security/CVE-2024-50040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: igb: Do not bring the device up after non-fatal error Commit 004d25060c78 (\"igb: Fix igb_down hung on surprise removal\") changed igb_io_error_detected() to ignore non-fatal pcie errors in order to avoid hung task that can happen when igb_down() is called multiple times. This caused an issue when processing transient non-fatal errors. igb_io_resume(), which is called after igb_io_error_detected(), assumes that device is brought down by igb_io_error_detected() if the interface is up. This resulted in panic with stacktrace below. [ T3256] igb 0000:09:00.0 haeth0: igb: haeth0 NIC Link is Down [ T292] pcieport 0000:00:1c.5: AER: Uncorrected (Non-Fatal) error received: 0000:09:00.0 [ T292] igb 0000:09:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, (Requester ID) [ T292] igb 0000:09:00.0: device [8086:1537] error status/mask=00004000/00000000 [ T292] igb 0000:09:00.0: [14] CmpltTO [ 200.105524,009][ T292] igb 0000:09:00.0: AER: TLP Header: 00000000 00000000 00000000 00000000 [ T292] pcieport 0000:00:1c.5: AER: broadcast error_detected message [ T292] igb 0000:09:00.0: Non-correctable non-fatal error reported. [ T292] pcieport 0000:00:1c.5: AER: broadcast mmio_enabled message [ T292] pcieport 0000:00:1c.5: AER: broadcast resume message [ T292] ------------[ cut here ]------------ [ T292] kernel BUG at net/core/dev.c:6539! [ T292] invalid opcode: 0000 [#1] PREEMPT SMP [ T292] RIP: 0010:napi_enable+0x37/0x40 [ T292] Call Trace: [ T292] [ T292] ? die+0x33/0x90 [ T292] ? do_trap+0xdc/0x110 [ T292] ? napi_enable+0x37/0x40 [ T292] ? do_error_trap+0x70/0xb0 [ T292] ? napi_enable+0x37/0x40 [ T292] ? napi_enable+0x37/0x40 [ T292] ? exc_invalid_op+0x4e/0x70 [ T292] ? napi_enable+0x37/0x40 [ T292] ? asm_exc_invalid_op+0x16/0x20 [ T292] ? napi_enable+0x37/0x40 [ T292] igb_up+0x41/0x150 [ T292] igb_io_resume+0x25/0x70 [ T292] report_resume+0x54/0x70 [ T292] ? report_frozen_detected+0x20/0x20 [ T292] pci_walk_bus+0x6c/0x90 [ T292] ? aer_print_port_info+0xa0/0xa0 [ T292] pcie_do_recovery+0x22f/0x380 [ T292] aer_process_err_devices+0x110/0x160 [ T292] aer_isr+0x1c1/0x1e0 [ T292] ? disable_irq_nosync+0x10/0x10 [ T292] irq_thread_fn+0x1a/0x60 [ T292] irq_thread+0xe3/0x1a0 [ T292] ? irq_set_affinity_notifier+0x120/0x120 [ T292] ? irq_affinity_notify+0x100/0x100 [ T292] kthread+0xe2/0x110 [ T292] ? kthread_complete_and_exit+0x20/0x20 [ T292] ret_from_fork+0x2d/0x50 [ T292] ? kthread_complete_and_exit+0x20/0x20 [ T292] ret_from_fork_asm+0x11/0x20 [ T292] To fix this issue igb_io_resume() checks if the interface is running and the device is not down this means igb_io_error_detected() did not bring the device down and there is no need to bring it up.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50041", "url": "https://ubuntu.com/security/CVE-2024-50041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: Fix macvlan leak by synchronizing access to mac_filter_hash This patch addresses a macvlan leak issue in the i40e driver caused by concurrent access to vsi->mac_filter_hash. The leak occurs when multiple threads attempt to modify the mac_filter_hash simultaneously, leading to inconsistent state and potential memory leaks. To fix this, we now wrap the calls to i40e_del_mac_filter() and zeroing vf->default_lan_addr.addr with spin_lock/unlock_bh(&vsi->mac_filter_hash_lock), ensuring atomic operations and preventing concurrent access. Additionally, we add lockdep_assert_held(&vsi->mac_filter_hash_lock) in i40e_add_mac_filter() to help catch similar issues in the future. Reproduction steps: 1. Spawn VFs and configure port vlan on them. 2. Trigger concurrent macvlan operations (e.g., adding and deleting \tportvlan and/or mac filters). 3. Observe the potential memory leak and inconsistent state in the \tmac_filter_hash. This synchronization ensures the integrity of the mac_filter_hash and prevents the described leak.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50042", "url": "https://ubuntu.com/security/CVE-2024-50042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix increasing MSI-X on VF Increasing MSI-X value on a VF leads to invalid memory operations. This is caused by not reallocating some arrays. Reproducer: modprobe ice echo 0 > /sys/bus/pci/devices/$PF_PCI/sriov_drivers_autoprobe echo 1 > /sys/bus/pci/devices/$PF_PCI/sriov_numvfs echo 17 > /sys/bus/pci/devices/$VF0_PCI/sriov_vf_msix_count Default MSI-X is 16, so 17 and above triggers this issue. KASAN reports: BUG: KASAN: slab-out-of-bounds in ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] Read of size 8 at addr ffff8888b937d180 by task bash/28433 (...) Call Trace: (...) ? ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] kasan_report+0xed/0x120 ? ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] ice_vsi_cfg_def+0x3360/0x4770 [ice] ? mutex_unlock+0x83/0xd0 ? __pfx_ice_vsi_cfg_def+0x10/0x10 [ice] ? __pfx_ice_remove_vsi_lkup_fltr+0x10/0x10 [ice] ice_vsi_cfg+0x7f/0x3b0 [ice] ice_vf_reconfig_vsi+0x114/0x210 [ice] ice_sriov_set_msix_vec_count+0x3d0/0x960 [ice] sriov_vf_msix_count_store+0x21c/0x300 (...) Allocated by task 28201: (...) ice_vsi_cfg_def+0x1c8e/0x4770 [ice] ice_vsi_cfg+0x7f/0x3b0 [ice] ice_vsi_setup+0x179/0xa30 [ice] ice_sriov_configure+0xcaa/0x1520 [ice] sriov_numvfs_store+0x212/0x390 (...) To fix it, use ice_vsi_rebuild() instead of ice_vf_reconfig_vsi(). This causes the required arrays to be reallocated taking the new queue count into account (ice_vsi_realloc_stat_arrays()). Set req_txq and req_rxq before ice_vsi_rebuild(), so that realloc uses the newly set queue count. Additionally, ice_vsi_rebuild() does not remove VSI filters (ice_fltr_remove_all()), so ice_vf_init_host_cfg() is no longer necessary.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50093", "url": "https://ubuntu.com/security/CVE-2024-50093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: intel: int340x: processor: Fix warning during module unload The processor_thermal driver uses pcim_device_enable() to enable a PCI device, which means the device will be automatically disabled on driver detach. Thus there is no need to call pci_disable_device() again on it. With recent PCI device resource management improvements, e.g. commit f748a07a0b64 (\"PCI: Remove legacy pcim_release()\"), this problem is exposed and triggers the warining below. [ 224.010735] proc_thermal_pci 0000:00:04.0: disabling already-disabled device [ 224.010747] WARNING: CPU: 8 PID: 4442 at drivers/pci/pci.c:2250 pci_disable_device+0xe5/0x100 ... [ 224.010844] Call Trace: [ 224.010845] [ 224.010847] ? show_regs+0x6d/0x80 [ 224.010851] ? __warn+0x8c/0x140 [ 224.010854] ? pci_disable_device+0xe5/0x100 [ 224.010856] ? report_bug+0x1c9/0x1e0 [ 224.010859] ? handle_bug+0x46/0x80 [ 224.010862] ? exc_invalid_op+0x1d/0x80 [ 224.010863] ? asm_exc_invalid_op+0x1f/0x30 [ 224.010867] ? pci_disable_device+0xe5/0x100 [ 224.010869] ? pci_disable_device+0xe5/0x100 [ 224.010871] ? kfree+0x21a/0x2b0 [ 224.010873] pcim_disable_device+0x20/0x30 [ 224.010875] devm_action_release+0x16/0x20 [ 224.010878] release_nodes+0x47/0xc0 [ 224.010880] devres_release_all+0x9f/0xe0 [ 224.010883] device_unbind_cleanup+0x12/0x80 [ 224.010885] device_release_driver_internal+0x1ca/0x210 [ 224.010887] driver_detach+0x4e/0xa0 [ 224.010889] bus_remove_driver+0x6f/0xf0 [ 224.010890] driver_unregister+0x35/0x60 [ 224.010892] pci_unregister_driver+0x44/0x90 [ 224.010894] proc_thermal_pci_driver_exit+0x14/0x5f0 [processor_thermal_device_pci] ... [ 224.010921] ---[ end trace 0000000000000000 ]--- Remove the excess pci_disable_device() calls. [ rjw: Subject and changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50043", "url": "https://ubuntu.com/security/CVE-2024-50043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix possible badness in FREE_STATEID When multiple FREE_STATEIDs are sent for the same delegation stateid, it can lead to a possible either use-after-free or counter refcount underflow errors. In nfsd4_free_stateid() under the client lock we find a delegation stateid, however the code drops the lock before calling nfs4_put_stid(), that allows another FREE_STATE to find the stateid again. The first one will proceed to then free the stateid which leads to either use-after-free or decrementing already zeroed counter.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50044", "url": "https://ubuntu.com/security/CVE-2024-50044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change rfcomm_sk_state_change attempts to use sock_lock so it must never be called with it locked but rfcomm_sock_ioctl always attempt to lock it causing the following trace: ====================================================== WARNING: possible circular locking dependency detected 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Not tainted ------------------------------------------------------ syz-executor386/5093 is trying to acquire lock: ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1671 [inline] ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73 but task is already holding lock: ffff88807badfd28 (&d->lock){+.+.}-{3:3}, at: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50045", "url": "https://ubuntu.com/security/CVE-2024-50045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: br_netfilter: fix panic with metadata_dst skb Fix a kernel panic in the br_netfilter module when sending untagged traffic via a VxLAN device. This happens during the check for fragmentation in br_nf_dev_queue_xmit. It is dependent on: 1) the br_netfilter module being loaded; 2) net.bridge.bridge-nf-call-iptables set to 1; 3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port; 4) untagged frames with size higher than the VxLAN MTU forwarded/flooded When forwarding the untagged packet to the VxLAN bridge port, before the netfilter hooks are called, br_handle_egress_vlan_tunnel is called and changes the skb_dst to the tunnel dst. The tunnel_dst is a metadata type of dst, i.e., skb_valid_dst(skb) is false, and metadata->dst.dev is NULL. Then in the br_netfilter hooks, in br_nf_dev_queue_xmit, there's a check for frames that needs to be fragmented: frames with higher MTU than the VxLAN device end up calling br_nf_ip_fragment, which in turns call ip_skb_dst_mtu. The ip_dst_mtu tries to use the skb_dst(skb) as if it was a valid dst with valid dst->dev, thus the crash. This case was never supported in the first place, so drop the packet instead. PING 10.0.0.2 (10.0.0.2) from 0.0.0.0 h1-eth0: 2000(2028) bytes of data. [ 176.291791] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000110 [ 176.292101] Mem abort info: [ 176.292184] ESR = 0x0000000096000004 [ 176.292322] EC = 0x25: DABT (current EL), IL = 32 bits [ 176.292530] SET = 0, FnV = 0 [ 176.292709] EA = 0, S1PTW = 0 [ 176.292862] FSC = 0x04: level 0 translation fault [ 176.293013] Data abort info: [ 176.293104] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 176.293488] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 176.293787] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 176.293995] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043ef5000 [ 176.294166] [0000000000000110] pgd=0000000000000000, p4d=0000000000000000 [ 176.294827] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 176.295252] Modules linked in: vxlan ip6_udp_tunnel udp_tunnel veth br_netfilter bridge stp llc ipv6 crct10dif_ce [ 176.295923] CPU: 0 PID: 188 Comm: ping Not tainted 6.8.0-rc3-g5b3fbd61b9d1 #2 [ 176.296314] Hardware name: linux,dummy-virt (DT) [ 176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 176.296808] pc : br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.297382] lr : br_nf_dev_queue_xmit+0x2ac/0x4ec [br_netfilter] [ 176.297636] sp : ffff800080003630 [ 176.297743] x29: ffff800080003630 x28: 0000000000000008 x27: ffff6828c49ad9f8 [ 176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24: 00000000000003e8 [ 176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21: ffff6828c3b16d28 [ 176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18: 0000000000000014 [ 176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15: 0000000095744632 [ 176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12: ffffb7e137926a70 [ 176.299574] x11: 0000000000000001 x10: ffff6828c3f1c898 x9 : 0000000000000000 [ 176.300049] x8 : ffff6828c49bf070 x7 : 0008460f18d5f20e x6 : f20e0100bebafeca [ 176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 : 0000000000000000 [ 176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 : ffff6828c7f918f0 [ 176.300889] Call trace: [ 176.301123] br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.301411] br_nf_post_routing+0x2a8/0x3e4 [br_netfilter] [ 176.301703] nf_hook_slow+0x48/0x124 [ 176.302060] br_forward_finish+0xc8/0xe8 [bridge] [ 176.302371] br_nf_hook_thresh+0x124/0x134 [br_netfilter] [ 176.302605] br_nf_forward_finish+0x118/0x22c [br_netfilter] [ 176.302824] br_nf_forward_ip.part.0+0x264/0x290 [br_netfilter] [ 176.303136] br_nf_forward+0x2b8/0x4e0 [br_netfilter] [ 176.303359] nf_hook_slow+0x48/0x124 [ 176.303 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50094", "url": "https://ubuntu.com/security/CVE-2024-50094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sfc: Don't invoke xdp_do_flush() from netpoll. Yury reported a crash in the sfc driver originated from netpoll_send_udp(). The netconsole sends a message and then netpoll invokes the driver's NAPI function with a budget of zero. It is dedicated to allow driver to free TX resources, that it may have used while sending the packet. In the netpoll case the driver invokes xdp_do_flush() unconditionally, leading to crash because bpf_net_context was never assigned. Invoke xdp_do_flush() only if budget is not zero.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50188", "url": "https://ubuntu.com/security/CVE-2024-50188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: dp83869: fix memory corruption when enabling fiber When configuring the fiber port, the DP83869 PHY driver incorrectly calls linkmode_set_bit() with a bit mask (1 << 10) rather than a bit number (10). This corrupts some other memory location -- in case of arm64 the priv pointer in the same structure. Since the advertising flags are updated from supported at the end of the function the incorrect line isn't needed at all and can be removed.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50046", "url": "https://ubuntu.com/security/CVE-2024-50046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies() On the node of an NFS client, some files saved in the mountpoint of the NFS server were copied to another location of the same NFS server. Accidentally, the nfs42_complete_copies() got a NULL-pointer dereference crash with the following syslog: [232064.838881] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232064.839360] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232066.588183] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 [232066.588586] Mem abort info: [232066.588701] ESR = 0x0000000096000007 [232066.588862] EC = 0x25: DABT (current EL), IL = 32 bits [232066.589084] SET = 0, FnV = 0 [232066.589216] EA = 0, S1PTW = 0 [232066.589340] FSC = 0x07: level 3 translation fault [232066.589559] Data abort info: [232066.589683] ISV = 0, ISS = 0x00000007 [232066.589842] CM = 0, WnR = 0 [232066.589967] user pgtable: 64k pages, 48-bit VAs, pgdp=00002000956ff400 [232066.590231] [0000000000000058] pgd=08001100ae100003, p4d=08001100ae100003, pud=08001100ae100003, pmd=08001100b3c00003, pte=0000000000000000 [232066.590757] Internal error: Oops: 96000007 [#1] SMP [232066.590958] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm vhost_net vhost vhost_iotlb tap tun ipt_rpfilter xt_multiport ip_set_hash_ip ip_set_hash_net xfrm_interface xfrm6_tunnel tunnel4 tunnel6 esp4 ah4 wireguard libcurve25519_generic veth xt_addrtype xt_set nf_conntrack_netlink ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_bitmap_port ip_set_hash_ipport dummy ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs iptable_filter sch_ingress nfnetlink_cttimeout vport_gre ip_gre ip_tunnel gre vport_geneve geneve vport_vxlan vxlan ip6_udp_tunnel udp_tunnel openvswitch nf_conncount dm_round_robin dm_service_time dm_multipath xt_nat xt_MASQUERADE nft_chain_nat nf_nat xt_mark xt_conntrack xt_comment nft_compat nft_counter nf_tables nfnetlink ocfs2 ocfs2_nodemanager ocfs2_stackglue iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_ssif nbd overlay 8021q garp mrp bonding tls rfkill sunrpc ext4 mbcache jbd2 [232066.591052] vfat fat cas_cache cas_disk ses enclosure scsi_transport_sas sg acpi_ipmi ipmi_si ipmi_devintf ipmi_msghandler ip_tables vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio dm_mirror dm_region_hash dm_log dm_mod nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc fuse xfs libcrc32c ast drm_vram_helper qla2xxx drm_kms_helper syscopyarea crct10dif_ce sysfillrect ghash_ce sysimgblt sha2_ce fb_sys_fops cec sha256_arm64 sha1_ce drm_ttm_helper ttm nvme_fc igb sbsa_gwdt nvme_fabrics drm nvme_core i2c_algo_bit i40e scsi_transport_fc megaraid_sas aes_neon_bs [232066.596953] CPU: 6 PID: 4124696 Comm: 10.253.166.125- Kdump: loaded Not tainted 5.15.131-9.cl9_ocfs2.aarch64 #1 [232066.597356] Hardware name: Great Wall .\\x93\\x8e...RF6260 V5/GWMSSE2GL1T, BIOS T656FBE_V3.0.18 2024-01-06 [232066.597721] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [232066.598034] pc : nfs4_reclaim_open_state+0x220/0x800 [nfsv4] [232066.598327] lr : nfs4_reclaim_open_state+0x12c/0x800 [nfsv4] [232066.598595] sp : ffff8000f568fc70 [232066.598731] x29: ffff8000f568fc70 x28: 0000000000001000 x27: ffff21003db33000 [232066.599030] x26: ffff800005521ae0 x25: ffff0100f98fa3f0 x24: 0000000000000001 [232066.599319] x23: ffff800009920008 x22: ffff21003db33040 x21: ffff21003db33050 [232066.599628] x20: ffff410172fe9e40 x19: ffff410172fe9e00 x18: 0000000000000000 [232066.599914] x17: 0000000000000000 x16: 0000000000000004 x15: 0000000000000000 [232066.600195] x14: 0000000000000000 x13: ffff800008e685a8 x12: 00000000eac0c6e6 [232066.600498] x11: 00000000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50190", "url": "https://ubuntu.com/security/CVE-2024-50190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix memleak in ice_init_tx_topology() Fix leak of the FW blob (DDP pkg). Make ice_cfg_tx_topo() const-correct, so ice_init_tx_topology() can avoid copying whole FW blob. Copy just the topology section, and only when needed. Reuse the buffer allocated for the read of the current topology. This was found by kmemleak, with the following trace for each PF: [] kmemdup_noprof+0x1d/0x50 [] ice_init_ddp_config+0x100/0x220 [ice] [] ice_init_dev+0x6f/0x200 [ice] [] ice_init+0x29/0x560 [ice] [] ice_probe+0x21d/0x310 [ice] Constify ice_cfg_tx_topo() @buf parameter. This cascades further down to few more functions.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50180", "url": "https://ubuntu.com/security/CVE-2024-50180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: sisfb: Fix strbuf array overflow The values of the variables xres and yres are placed in strbuf. These variables are obtained from strbuf1. The strbuf1 array contains digit characters and a space if the array contains non-digit characters. Then, when executing sprintf(strbuf, \"%ux%ux8\", xres, yres); more than 16 bytes will be written to strbuf. It is suggested to increase the size of the strbuf array to 24. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06: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": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50048", "url": "https://ubuntu.com/security/CVE-2024-50048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: Fix a NULL pointer dereference issue in fbcon_putcs syzbot has found a NULL pointer dereference bug in fbcon. Here is the simplified C reproducer: struct param { \tuint8_t type; \tstruct tiocl_selection ts; }; int main() { \tstruct fb_con2fbmap con2fb; \tstruct param param; \tint fd = open(\"/dev/fb1\", 0, 0); \tcon2fb.console = 0x19; \tcon2fb.framebuffer = 0; \tioctl(fd, FBIOPUT_CON2FBMAP, &con2fb); \tparam.type = 2; \tparam.ts.xs = 0; param.ts.ys = 0; \tparam.ts.xe = 0; param.ts.ye = 0; \tparam.ts.sel_mode = 0; \tint fd1 = open(\"/dev/tty1\", O_RDWR, 0); \tioctl(fd1, TIOCLINUX, ¶m); \tcon2fb.console = 1; \tcon2fb.framebuffer = 0; \tioctl(fd, FBIOPUT_CON2FBMAP, &con2fb); \treturn 0; } After calling ioctl(fd1, TIOCLINUX, ¶m), the subsequent ioctl(fd, FBIOPUT_CON2FBMAP, &con2fb) causes the kernel to follow a different execution path: set_con2fb_map -> con2fb_init_display -> fbcon_set_disp -> redraw_screen -> hide_cursor -> clear_selection -> highlight -> invert_screen -> do_update_region -> fbcon_putcs -> ops->putcs Since ops->putcs is a NULL pointer, this leads to a kernel panic. To prevent this, we need to call set_blitting_type() within set_con2fb_map() to properly initialize ops->putcs.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50049", "url": "https://ubuntu.com/security/CVE-2024-50049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before dereferencing se [WHAT & HOW] se is null checked previously in the same function, indicating it might be null; therefore, it must be checked when used again. This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50090", "url": "https://ubuntu.com/security/CVE-2024-50090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/oa: Fix overflow in oa batch buffer By default xe_bb_create_job() appends a MI_BATCH_BUFFER_END to batch buffer, this is not a problem if batch buffer is only used once but oa reuses the batch buffer for the same metric and at each call it appends a MI_BATCH_BUFFER_END, printing the warning below and then overflowing. [ 381.072016] ------------[ cut here ]------------ [ 381.072019] xe 0000:00:02.0: [drm] Assertion `bb->len * 4 + bb_prefetch(q->gt) <= size` failed! platform: LUNARLAKE subplatform: 1 graphics: Xe2_LPG / Xe2_HPG 20.04 step B0 media: Xe2_LPM / Xe2_HPM 20.00 step B0 tile: 0 VRAM 0 B GT: 0 type 1 So here checking if batch buffer already have MI_BATCH_BUFFER_END if not append it. v2: - simply fix, suggestion from Ashutosh (cherry picked from commit 9ba0e0f30ca42a98af3689460063edfb6315718a)", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50183", "url": "https://ubuntu.com/security/CVE-2024-50183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV instance Deleting an NPIV instance requires all fabric ndlps to be released before an NPIV's resources can be torn down. Failure to release fabric ndlps beforehand opens kref imbalance race conditions. Fix by forcing the DA_ID to complete synchronously with usage of wait_queue.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50055", "url": "https://ubuntu.com/security/CVE-2024-50055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: driver core: bus: Fix double free in driver API bus_register() For bus_register(), any error which happens after kset_register() will cause that @priv are freed twice, fixed by setting @priv with NULL after the first free.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50091", "url": "https://ubuntu.com/security/CVE-2024-50091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm vdo: don't refer to dedupe_context after releasing it Clear the dedupe_context pointer in a data_vio whenever ownership of the context is lost, so that vdo can't examine it accidentally.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50056", "url": "https://ubuntu.com/security/CVE-2024-50056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: Fix ERR_PTR dereference in uvc_v4l2.c Fix potential dereferencing of ERR_PTR() in find_format_by_pix() and uvc_v4l2_enum_format(). Fix the following smatch errors: drivers/usb/gadget/function/uvc_v4l2.c:124 find_format_by_pix() error: 'fmtdesc' dereferencing possible ERR_PTR() drivers/usb/gadget/function/uvc_v4l2.c:392 uvc_v4l2_enum_format() error: 'fmtdesc' dereferencing possible ERR_PTR() Also, fix similar issue in uvc_v4l2_try_format() for potential dereferencing of ERR_PTR().", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50184", "url": "https://ubuntu.com/security/CVE-2024-50184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_pmem: Check device status before requesting flush If a pmem device is in a bad status, the driver side could wait for host ack forever in virtio_pmem_flush(), causing the system to hang. So add a status check in the beginning of virtio_pmem_flush() to return early if the device is not activated.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50057", "url": "https://ubuntu.com/security/CVE-2024-50057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: tipd: Free IRQ only if it was requested before In polling mode, if no IRQ was requested there is no need to free it. Call devm_free_irq() only if client->irq is set. This fixes the warning caused by the tps6598x module removal: WARNING: CPU: 2 PID: 333 at kernel/irq/devres.c:144 devm_free_irq+0x80/0x8c ... ... Call trace: devm_free_irq+0x80/0x8c tps6598x_remove+0x28/0x88 [tps6598x] i2c_device_remove+0x2c/0x9c device_remove+0x4c/0x80 device_release_driver_internal+0x1cc/0x228 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 i2c_del_driver+0x54/0x64 tps6598x_i2c_driver_exit+0x18/0xc3c [tps6598x] __arm64_sys_delete_module+0x184/0x264 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc8/0xe8 do_el0_svc+0x20/0x2c el0_svc+0x28/0x98 el0t_64_sync_handler+0x13c/0x158 el0t_64_sync+0x190/0x194", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50058", "url": "https://ubuntu.com/security/CVE-2024-50058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: protect uart_port_dtr_rts() in uart_shutdown() too Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part 3) added few uport == NULL checks. It added one to uart_shutdown(), so the commit assumes, uport can be NULL in there. But right after that protection, there is an unprotected \"uart_port_dtr_rts(uport, false);\" call. That is invoked only if HUPCL is set, so I assume that is the reason why we do not see lots of these reports. Or it cannot be NULL at this point at all for some reason :P. Until the above is investigated, stay on the safe side and move this dereference to the if too. I got this inconsistency from Coverity under CID 1585130. Thanks.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50181", "url": "https://ubuntu.com/security/CVE-2024-50181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: imx: Remove CLK_SET_PARENT_GATE for DRAM mux for i.MX7D For i.MX7D DRAM related mux clock, the clock source change should ONLY be done done in low level asm code without accessing DRAM, and then calling clk API to sync the HW clock status with clk tree, it should never touch real clock source switch via clk API, so CLK_SET_PARENT_GATE flag should NOT be added, otherwise, DRAM's clock parent will be disabled when DRAM is active, and system will hang.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50059", "url": "https://ubuntu.com/security/CVE-2024-50059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntb: ntb_hw_switchtec: Fix use after free vulnerability in switchtec_ntb_remove due to race condition In the switchtec_ntb_add function, it can call switchtec_ntb_init_sndev function, then &sndev->check_link_status_work is bound with check_link_status_work. switchtec_ntb_link_notification may be called to start the work. If we remove the module which will call switchtec_ntb_remove to make cleanup, it will free sndev through kfree(sndev), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | check_link_status_work switchtec_ntb_remove | kfree(sndev); | | if (sndev->link_force_down) | // use sndev Fix it by ensuring that the work is canceled before proceeding with the cleanup in switchtec_ntb_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50060", "url": "https://ubuntu.com/security/CVE-2024-50060", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring: check if we need to reschedule during overflow flush In terms of normal application usage, this list will always be empty. And if an application does overflow a bit, it'll have a few entries. However, nothing obviously prevents syzbot from running a test case that generates a ton of overflow entries, and then flushing them can take quite a while. Check for needing to reschedule while flushing, and drop our locks and do so if necessary. There's no state to maintain here as overflows always prune from head-of-list, hence it's fine to drop and reacquire the locks at the end of the loop.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50061", "url": "https://ubuntu.com/security/CVE-2024-50061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: cdns: Fix use after free vulnerability in cdns_i3c_master Driver Due to Race Condition In the cdns_i3c_master_probe function, &master->hj_work is bound with cdns_i3c_master_hj. And cdns_i3c_master_interrupt can call cnds_i3c_master_demux_ibis function to start the work. If we remove the module which will call cdns_i3c_master_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | cdns_i3c_master_hj cdns_i3c_master_remove | i3c_master_unregister(&master->base) | device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in cdns_i3c_master_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50062", "url": "https://ubuntu.com/security/CVE-2024-50062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-srv: Avoid null pointer deref during path establishment For RTRS path establishment, RTRS client initiates and completes con_num of connections. After establishing all its connections, the information is exchanged between the client and server through the info_req message. During this exchange, it is essential that all connections have been established, and the state of the RTRS srv path is CONNECTED. So add these sanity checks, to make sure we detect and abort process in error scenarios to avoid null pointer deref.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50095", "url": "https://ubuntu.com/security/CVE-2024-50095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mad: Improve handling of timed out WRs of mad agent Current timeout handler of mad agent acquires/releases mad_agent_priv lock for every timed out WRs. This causes heavy locking contention when higher no. of WRs are to be handled inside timeout handler. This leads to softlockup with below trace in some use cases where rdma-cm path is used to establish connection between peer nodes Trace: ----- BUG: soft lockup - CPU#4 stuck for 26s! [kworker/u128:3:19767] CPU: 4 PID: 19767 Comm: kworker/u128:3 Kdump: loaded Tainted: G OE ------- --- 5.14.0-427.13.1.el9_4.x86_64 #1 Hardware name: Dell Inc. PowerEdge R740/01YM03, BIOS 2.4.8 11/26/2019 Workqueue: ib_mad1 timeout_sends [ib_core] RIP: 0010:__do_softirq+0x78/0x2ac RSP: 0018:ffffb253449e4f98 EFLAGS: 00000246 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 000000000000001f RDX: 000000000000001d RSI: 000000003d1879ab RDI: fff363b66fd3a86b RBP: ffffb253604cbcd8 R08: 0000009065635f3b R09: 0000000000000000 R10: 0000000000000040 R11: ffffb253449e4ff8 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000040 FS: 0000000000000000(0000) GS:ffff8caa1fc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd9ec9db900 CR3: 0000000891934006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? __irq_exit_rcu+0xa1/0xc0 ? watchdog_timer_fn+0x1b2/0x210 ? __pfx_watchdog_timer_fn+0x10/0x10 ? __hrtimer_run_queues+0x127/0x2c0 ? hrtimer_interrupt+0xfc/0x210 ? __sysvec_apic_timer_interrupt+0x5c/0x110 ? sysvec_apic_timer_interrupt+0x37/0x90 ? asm_sysvec_apic_timer_interrupt+0x16/0x20 ? __do_softirq+0x78/0x2ac ? __do_softirq+0x60/0x2ac __irq_exit_rcu+0xa1/0xc0 sysvec_call_function_single+0x72/0x90 asm_sysvec_call_function_single+0x16/0x20 RIP: 0010:_raw_spin_unlock_irq+0x14/0x30 RSP: 0018:ffffb253604cbd88 EFLAGS: 00000247 RAX: 000000000001960d RBX: 0000000000000002 RCX: ffff8cad2a064800 RDX: 000000008020001b RSI: 0000000000000001 RDI: ffff8cad5d39f66c RBP: ffff8cad5d39f600 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8caa443e0c00 R11: ffffb253604cbcd8 R12: ffff8cacb8682538 R13: 0000000000000005 R14: ffffb253604cbd90 R15: ffff8cad5d39f66c cm_process_send_error+0x122/0x1d0 [ib_cm] timeout_sends+0x1dd/0x270 [ib_core] process_one_work+0x1e2/0x3b0 ? __pfx_worker_thread+0x10/0x10 worker_thread+0x50/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xdd/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x50 Simplified timeout handler by creating local list of timed out WRs and invoke send handler post creating the list. The new method acquires/ releases lock once to fetch the list and hence helps to reduce locking contetiong when processing higher no. of WRs", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50063", "url": "https://ubuntu.com/security/CVE-2024-50063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Prevent tail call between progs attached to different hooks bpf progs can be attached to kernel functions, and the attached functions can take different parameters or return different return values. If prog attached to one kernel function tail calls prog attached to another kernel function, the ctx access or return value verification could be bypassed. For example, if prog1 is attached to func1 which takes only 1 parameter and prog2 is attached to func2 which takes two parameters. Since verifier assumes the bpf ctx passed to prog2 is constructed based on func2's prototype, verifier allows prog2 to access the second parameter from the bpf ctx passed to it. The problem is that verifier does not prevent prog1 from passing its bpf ctx to prog2 via tail call. In this case, the bpf ctx passed to prog2 is constructed from func1 instead of func2, that is, the assumption for ctx access verification is bypassed. Another example, if BPF LSM prog1 is attached to hook file_alloc_security, and BPF LSM prog2 is attached to hook bpf_lsm_audit_rule_known. Verifier knows the return value rules for these two hooks, e.g. it is legal for bpf_lsm_audit_rule_known to return positive number 1, and it is illegal for file_alloc_security to return positive number. So verifier allows prog2 to return positive number 1, but does not allow prog1 to return positive number. The problem is that verifier does not prevent prog1 from calling prog2 via tail call. In this case, prog2's return value 1 will be used as the return value for prog1's hook file_alloc_security. That is, the return value rule is bypassed. This patch adds restriction for tail call to prevent such bypasses.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50191", "url": "https://ubuntu.com/security/CVE-2024-50191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: don't set SB_RDONLY after filesystem errors When the filesystem is mounted with errors=remount-ro, we were setting SB_RDONLY flag to stop all filesystem modifications. We knew this misses proper locking (sb->s_umount) and does not go through proper filesystem remount procedure but it has been the way this worked since early ext2 days and it was good enough for catastrophic situation damage mitigation. Recently, syzbot has found a way (see link) to trigger warnings in filesystem freezing because the code got confused by SB_RDONLY changing under its hands. Since these days we set EXT4_FLAGS_SHUTDOWN on the superblock which is enough to stop all filesystem modifications, modifying SB_RDONLY shouldn't be needed. So stop doing that.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50064", "url": "https://ubuntu.com/security/CVE-2024-50064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: zram: free secondary algorithms names We need to kfree() secondary algorithms names when reset zram device that had multi-streams, otherwise we leak memory. [senozhatsky@chromium.org: kfree(NULL) is legal] Link: https://lkml.kernel.org/r/20240917013021.868769-1-senozhatsky@chromium.org", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50065", "url": "https://ubuntu.com/security/CVE-2024-50065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Change to non-blocking allocation in ntfs_d_hash d_hash is done while under \"rcu-walk\" and should not sleep. __get_name() allocates using GFP_KERNEL, having the possibility to sleep when under memory pressure. Change the allocation to GFP_NOWAIT.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50089", "url": "https://ubuntu.com/security/CVE-2024-50089", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-49863", "url": "https://ubuntu.com/security/CVE-2024-49863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost/scsi: null-ptr-dereference in vhost_scsi_get_req() Since commit 3f8ca2e115e5 (\"vhost/scsi: Extract common handling code from control queue handler\") a null pointer dereference bug can be triggered when guest sends an SCSI AN request. In vhost_scsi_ctl_handle_vq(), `vc.target` is assigned with `&v_req.tmf.lun[1]` within a switch-case block and is then passed to vhost_scsi_get_req() which extracts `vc->req` and `tpg`. However, for a `VIRTIO_SCSI_T_AN_*` request, tpg is not required, so `vc.target` is set to NULL in this branch. Later, in vhost_scsi_get_req(), `vc->target` is dereferenced without being checked, leading to a null pointer dereference bug. This bug can be triggered from guest. When this bug occurs, the vhost_worker process is killed while holding `vq->mutex` and the corresponding tpg will remain occupied indefinitely. Below is the KASAN report: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 PID: 840 Comm: poc Not tainted 6.10.0+ #1 Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:vhost_scsi_get_req+0x165/0x3a0 Code: 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 02 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 65 30 4c 89 e2 48 c1 ea 03 <0f> b6 04 02 4c 89 e2 83 e2 07 38 d0 7f 08 84 c0 0f 85 be 01 00 00 RSP: 0018:ffff888017affb50 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffff88801b000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888017affcb8 RBP: ffff888017affb80 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff888017affc88 R14: ffff888017affd1c R15: ffff888017993000 FS: 000055556e076500(0000) GS:ffff88806b100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200027c0 CR3: 0000000010ed0004 CR4: 0000000000370ef0 Call Trace: ? show_regs+0x86/0xa0 ? die_addr+0x4b/0xd0 ? exc_general_protection+0x163/0x260 ? asm_exc_general_protection+0x27/0x30 ? vhost_scsi_get_req+0x165/0x3a0 vhost_scsi_ctl_handle_vq+0x2a4/0xca0 ? __pfx_vhost_scsi_ctl_handle_vq+0x10/0x10 ? __switch_to+0x721/0xeb0 ? __schedule+0xda5/0x5710 ? __kasan_check_write+0x14/0x30 ? _raw_spin_lock+0x82/0xf0 vhost_scsi_ctl_handle_kick+0x52/0x90 vhost_run_work_list+0x134/0x1b0 vhost_task_fn+0x121/0x350 ... ---[ end trace 0000000000000000 ]--- Let's add a check in vhost_scsi_get_req. [whitespace fixes]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49864", "url": "https://ubuntu.com/security/CVE-2024-49864", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix a race between socket set up and I/O thread creation In rxrpc_open_socket(), it sets up the socket and then sets up the I/O thread that will handle it. This is a problem, however, as there's a gap between the two phases in which a packet may come into rxrpc_encap_rcv() from the UDP packet but we oops when trying to wake the not-yet created I/O thread. As a quick fix, just make rxrpc_encap_rcv() discard the packet if there's no I/O thread yet. A better, but more intrusive fix would perhaps be to rearrange things such that the socket creation is done by the I/O thread.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49865", "url": "https://ubuntu.com/security/CVE-2024-49865", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: move xa_alloc to prevent UAF Evil user can guess the next id of the vm before the ioctl completes and then call vm destroy ioctl to trigger UAF since create ioctl is still referencing the same vm. Move the xa_alloc all the way to the end to prevent this. v2: - Rebase (cherry picked from commit dcfd3971327f3ee92765154baebbaece833d3ca9)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49955", "url": "https://ubuntu.com/security/CVE-2024-49955", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: battery: Fix possible crash when unregistering a battery hook When a battery hook returns an error when adding a new battery, then the battery hook is automatically unregistered. However the battery hook provider cannot know that, so it will later call battery_hook_unregister() on the already unregistered battery hook, resulting in a crash. Fix this by using the list head to mark already unregistered battery hooks as already being unregistered so that they can be ignored by battery_hook_unregister().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49973", "url": "https://ubuntu.com/security/CVE-2024-49973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: r8169: add tally counter fields added with RTL8125 RTL8125 added fields to the tally counter, what may result in the chip dma'ing these new fields to unallocated memory. Therefore make sure that the allocated memory area is big enough to hold all of the tally counter values, even if we use only parts of it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49974", "url": "https://ubuntu.com/security/CVE-2024-49974", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Limit the number of concurrent async COPY operations Nothing appears to limit the number of concurrent async COPY operations that clients can start. In addition, AFAICT each async COPY can copy an unlimited number of 4MB chunks, so can run for a long time. Thus IMO async COPY can become a DoS vector. Add a restriction mechanism that bounds the number of concurrent background COPY operations. Start simple and try to be fair -- this patch implements a per-namespace limit. An async COPY request that occurs while this limit is exceeded gets NFS4ERR_DELAY. The requesting client can choose to send the request again after a delay or fall back to a traditional read/write style copy. If there is need to make the mechanism more sophisticated, we can visit that in future patches.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49975", "url": "https://ubuntu.com/security/CVE-2024-49975", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uprobes: fix kernel info leak via \"[uprobes]\" vma xol_add_vma() maps the uninitialized page allocated by __create_xol_area() into userspace. On some architectures (x86) this memory is readable even without VM_READ, VM_EXEC results in the same pgprot_t as VM_EXEC|VM_READ, although this doesn't really matter, debugger can read this memory anyway.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50003", "url": "https://ubuntu.com/security/CVE-2024-50003", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix system hang while resume with TBT monitor [Why] Connected with a Thunderbolt monitor and do the suspend and the system may hang while resume. The TBT monitor HPD will be triggered during the resume procedure and call the drm_client_modeset_probe() while struct drm_connector connector->dev->master is NULL. It will mess up the pipe topology after resume. [How] Skip the TBT monitor HPD during the resume procedure because we currently will probe the connectors after resume by default. (cherry picked from commit 453f86a26945207a16b8f66aaed5962dc2b95b85)", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50173", "url": "https://ubuntu.com/security/CVE-2024-50173", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix access to uninitialized variable in tick_ctx_cleanup() The group variable can't be used to retrieve ptdev in our second loop, because it points to the previously iterated list_head, not a valid group. Get the ptdev object from the scheduler instead.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49866", "url": "https://ubuntu.com/security/CVE-2024-49866", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Fix a race during cpuhp processing There is another found exception that the \"timerlat/1\" thread was scheduled on CPU0, and lead to timer corruption finally: ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ``` After tracing the scheduling event, it was discovered that the migration of the \"timerlat/1\" thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() | To fix this, skip online processing if the CPU is already offline.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49976", "url": "https://ubuntu.com/security/CVE-2024-49976", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Drop interface_lock in stop_kthread() stop_kthread() is the offline callback for \"trace/osnoise:online\", since commit 5bfbcd1ee57b (\"tracing/timerlat: Add interface_lock around clearing of kthread in stop_kthread()\"), the following ABBA deadlock scenario is introduced: T1 | T2 [BP] | T3 [AP] osnoise_hotplug_workfn() | work_for_cpu_fn() | cpuhp_thread_fun() | _cpu_down() | osnoise_cpu_die() mutex_lock(&interface_lock) | | stop_kthread() | cpus_write_lock() | mutex_lock(&interface_lock) cpus_read_lock() | cpuhp_kick_ap() | As the interface_lock here in just for protecting the \"kthread\" field of the osn_var, use xchg() instead to fix this issue. Also use for_each_online_cpu() back in stop_per_cpu_kthreads() as it can take cpu_read_lock() again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50005", "url": "https://ubuntu.com/security/CVE-2024-50005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: Fix potential RCU dereference issue in mac802154_scan_worker In the `mac802154_scan_worker` function, the `scan_req->type` field was accessed after the RCU read-side critical section was unlocked. According to RCU usage rules, this is illegal and can lead to unpredictable behavior, such as accessing memory that has been updated or causing use-after-free issues. This possible bug was identified using a static analysis tool developed by myself, specifically designed to detect RCU-related issues. To address this, the `scan_req->type` value is now stored in a local variable `scan_req_type` while still within the RCU read-side critical section. The `scan_req_type` is then used after the RCU lock is released, ensuring that the type value is safely accessed without violating RCU rules.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50012", "url": "https://ubuntu.com/security/CVE-2024-50012", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: Avoid a bad reference count on CPU node In the parse_perf_domain function, if the call to of_parse_phandle_with_args returns an error, then the reference to the CPU device node that was acquired at the start of the function would not be properly decremented. Address this by declaring the variable with the __free(device_node) cleanup attribute.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49867", "url": "https://ubuntu.com/security/CVE-2024-49867", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: wait for fixup workers before stopping cleaner kthread during umount During unmount, at close_ctree(), we have the following steps in this order: 1) Park the cleaner kthread - this doesn't destroy the kthread, it basically halts its execution (wake ups against it work but do nothing); 2) We stop the cleaner kthread - this results in freeing the respective struct task_struct; 3) We call btrfs_stop_all_workers() which waits for any jobs running in all the work queues and then free the work queues. Syzbot reported a case where a fixup worker resulted in a crash when doing a delayed iput on its inode while attempting to wake up the cleaner at btrfs_add_delayed_iput(), because the task_struct of the cleaner kthread was already freed. This can happen during unmount because we don't wait for any fixup workers still running before we call kthread_stop() against the cleaner kthread, which stops and free all its resources. Fix this by waiting for any fixup workers at close_ctree() before we call kthread_stop() against the cleaner and run pending delayed iputs. The stack traces reported by syzbot were the following: BUG: KASAN: slab-use-after-free in __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 Read of size 8 at addr ffff8880272a8a18 by task kworker/u8:3/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.12.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: btrfs-fixup btrfs_work_helper 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 __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline] try_to_wake_up+0xb0/0x1480 kernel/sched/core.c:4154 btrfs_writepage_fixup_worker+0xc16/0xdf0 fs/btrfs/inode.c:2842 btrfs_work_helper+0x390/0xc50 fs/btrfs/async-thread.c:314 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Allocated by task 2: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:319 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345 kasan_slab_alloc include/linux/kasan.h:247 [inline] slab_post_alloc_hook mm/slub.c:4086 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4187 alloc_task_struct_node kernel/fork.c:180 [inline] dup_task_struct+0x57/0x8c0 kernel/fork.c:1107 copy_process+0x5d1/0x3d50 kernel/fork.c:2206 kernel_clone+0x223/0x880 kernel/fork.c:2787 kernel_thread+0x1bc/0x240 kernel/fork.c:2849 create_kthread kernel/kthread.c:412 [inline] kthreadd+0x60d/0x810 kernel/kthread.c:765 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Freed by task 61: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:230 [inline] slab_free_h ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49868", "url": "https://ubuntu.com/security/CVE-2024-49868", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix a NULL pointer dereference when failed to start a new trasacntion [BUG] Syzbot reported a NULL pointer dereference with the following crash: FAULT_INJECTION: forcing a failure. start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676 prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642 relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678 ... BTRFS info (device loop0): balance: ended with status: -12 Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667] RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926 Call Trace: commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496 btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430 del_balance_item fs/btrfs/volumes.c:3678 [inline] reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742 btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574 btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673 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/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [CAUSE] The allocation failure happens at the start_transaction() inside prepare_to_relocate(), and during the error handling we call unset_reloc_control(), which makes fs_info->balance_ctl to be NULL. Then we continue the error path cleanup in btrfs_balance() by calling reset_balance_state() which will call del_balance_item() to fully delete the balance item in the root tree. However during the small window between set_reloc_contrl() and unset_reloc_control(), we can have a subvolume tree update and created a reloc_root for that subvolume. Then we go into the final btrfs_commit_transaction() of del_balance_item(), and into btrfs_update_reloc_root() inside commit_fs_roots(). That function checks if fs_info->reloc_ctl is in the merge_reloc_tree stage, but since fs_info->reloc_ctl is NULL, it results a NULL pointer dereference. [FIX] Just add extra check on fs_info->reloc_ctl inside btrfs_update_reloc_root(), before checking fs_info->reloc_ctl->merge_reloc_tree. That DEAD_RELOC_TREE handling is to prevent further modification to the reloc tree during merge stage, but since there is no reloc_ctl at all, we do not need to bother that.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49869", "url": "https://ubuntu.com/security/CVE-2024-49869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: send: fix buffer overflow detection when copying path to cache entry Starting with commit c0247d289e73 (\"btrfs: send: annotate struct name_cache_entry with __counted_by()\") we annotated the variable length array \"name\" from the name_cache_entry structure with __counted_by() to improve overflow detection. However that alone was not correct, because the length of that array does not match the \"name_len\" field - it matches that plus 1 to include the NUL string terminator, so that makes a fortified kernel think there's an overflow and report a splat like this: strcpy: detected buffer overflow: 20 byte write of buffer size 19 WARNING: CPU: 3 PID: 3310 at __fortify_report+0x45/0x50 CPU: 3 UID: 0 PID: 3310 Comm: btrfs Not tainted 6.11.0-prnet #1 Hardware name: CompuLab Ltd. sbc-ihsw/Intense-PC2 (IPC2), BIOS IPC2_3.330.7 X64 03/15/2018 RIP: 0010:__fortify_report+0x45/0x50 Code: 48 8b 34 (...) RSP: 0018:ffff97ebc0d6f650 EFLAGS: 00010246 RAX: 7749924ef60fa600 RBX: ffff8bf5446a521a RCX: 0000000000000027 RDX: 00000000ffffdfff RSI: ffff97ebc0d6f548 RDI: ffff8bf84e7a1cc8 RBP: ffff8bf548574080 R08: ffffffffa8c40e10 R09: 0000000000005ffd R10: 0000000000000004 R11: ffffffffa8c70e10 R12: ffff8bf551eef400 R13: 0000000000000000 R14: 0000000000000013 R15: 00000000000003a8 FS: 00007fae144de8c0(0000) GS:ffff8bf84e780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fae14691690 CR3: 00000001027a2003 CR4: 00000000001706f0 Call Trace: ? __warn+0x12a/0x1d0 ? __fortify_report+0x45/0x50 ? report_bug+0x154/0x1c0 ? handle_bug+0x42/0x70 ? exc_invalid_op+0x1a/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? __fortify_report+0x45/0x50 __fortify_panic+0x9/0x10 __get_cur_name_and_parent+0x3bc/0x3c0 get_cur_path+0x207/0x3b0 send_extent_data+0x709/0x10d0 ? find_parent_nodes+0x22df/0x25d0 ? mas_nomem+0x13/0x90 ? mtree_insert_range+0xa5/0x110 ? btrfs_lru_cache_store+0x5f/0x1e0 ? iterate_extent_inodes+0x52d/0x5a0 process_extent+0xa96/0x11a0 ? __pfx_lookup_backref_cache+0x10/0x10 ? __pfx_store_backref_cache+0x10/0x10 ? __pfx_iterate_backrefs+0x10/0x10 ? __pfx_check_extent_item+0x10/0x10 changed_cb+0x6fa/0x930 ? tree_advance+0x362/0x390 ? memcmp_extent_buffer+0xd7/0x160 send_subvol+0xf0a/0x1520 btrfs_ioctl_send+0x106b/0x11d0 ? __pfx___clone_root_cmp_sort+0x10/0x10 _btrfs_ioctl_send+0x1ac/0x240 btrfs_ioctl+0x75b/0x850 __se_sys_ioctl+0xca/0x150 do_syscall_64+0x85/0x160 ? __count_memcg_events+0x69/0x100 ? handle_mm_fault+0x1327/0x15c0 ? __se_sys_rt_sigprocmask+0xf1/0x180 ? syscall_exit_to_user_mode+0x75/0xa0 ? do_syscall_64+0x91/0x160 ? do_user_addr_fault+0x21d/0x630 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fae145eeb4f Code: 00 48 89 (...) RSP: 002b:00007ffdf1cb09b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fae145eeb4f RDX: 00007ffdf1cb0ad0 RSI: 0000000040489426 RDI: 0000000000000004 RBP: 00000000000078fe R08: 00007fae144006c0 R09: 00007ffdf1cb0927 R10: 0000000000000008 R11: 0000000000000246 R12: 00007ffdf1cb1ce8 R13: 0000000000000003 R14: 000055c499fab2e0 R15: 0000000000000004 Fix this by not storing the NUL string terminator since we don't actually need it for name cache entries, this way \"name_len\" corresponds to the actual size of the \"name\" array. This requires marking the \"name\" array field with __nonstring and using memcpy() instead of strcpy() as recommended by the guidelines at: https://github.com/KSPP/linux/issues/90", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49870", "url": "https://ubuntu.com/security/CVE-2024-49870", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cachefiles: fix dentry leak in cachefiles_open_file() A dentry leak may be caused when a lookup cookie and a cull are concurrent: P1 | P2 ----------------------------------------------------------- cachefiles_lookup_cookie cachefiles_look_up_object lookup_one_positive_unlocked // get dentry cachefiles_cull inode->i_flags |= S_KERNEL_FILE; cachefiles_open_file cachefiles_mark_inode_in_use __cachefiles_mark_inode_in_use can_use = false if (!(inode->i_flags & S_KERNEL_FILE)) can_use = true \t return false return false // Returns an error but doesn't put dentry After that the following WARNING will be triggered when the backend folder is umounted: ================================================================== BUG: Dentry 000000008ad87947{i=7a,n=Dx_1_1.img} still in use (1) [unmount of ext4 sda] WARNING: CPU: 4 PID: 359261 at fs/dcache.c:1767 umount_check+0x5d/0x70 CPU: 4 PID: 359261 Comm: umount Not tainted 6.6.0-dirty #25 RIP: 0010:umount_check+0x5d/0x70 Call Trace: d_walk+0xda/0x2b0 do_one_tree+0x20/0x40 shrink_dcache_for_umount+0x2c/0x90 generic_shutdown_super+0x20/0x160 kill_block_super+0x1a/0x40 ext4_kill_sb+0x22/0x40 deactivate_locked_super+0x35/0x80 cleanup_mnt+0x104/0x160 ================================================================== Whether cachefiles_open_file() returns true or false, the reference count obtained by lookup_positive_unlocked() in cachefiles_look_up_object() should be released. Therefore release that reference count in cachefiles_look_up_object() to fix the above issue and simplify the code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49871", "url": "https://ubuntu.com/security/CVE-2024-49871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: adp5589-keys - fix NULL pointer dereference We register a devm action to call adp5589_clear_config() and then pass the i2c client as argument so that we can call i2c_get_clientdata() in order to get our device object. However, i2c_set_clientdata() is only being set at the end of the probe function which means that we'll get a NULL pointer dereference in case the probe function fails early.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49872", "url": "https://ubuntu.com/security/CVE-2024-49872", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/gup: fix memfd_pin_folios alloc race panic If memfd_pin_folios tries to create a hugetlb page, but someone else already did, then folio gets the value -EEXIST here: folio = memfd_alloc_folio(memfd, start_idx); if (IS_ERR(folio)) { ret = PTR_ERR(folio); if (ret != -EEXIST) goto err; then on the next trip through the \"while start_idx\" loop we panic here: if (folio) { folio_put(folio); To fix, set the folio to NULL on error.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49964", "url": "https://ubuntu.com/security/CVE-2024-49964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix memfd_pin_folios free_huge_pages leak memfd_pin_folios followed by unpin_folios fails to restore free_huge_pages if the pages were not already faulted in, because the folio refcount for pages created by memfd_alloc_folio never goes to 0. memfd_pin_folios needs another folio_put to undo the folio_try_get below: memfd_alloc_folio() alloc_hugetlb_folio_nodemask() dequeue_hugetlb_folio_nodemask() dequeue_hugetlb_folio_node_exact() folio_ref_unfreeze(folio, 1); ; adds 1 refcount folio_try_get() ; adds 1 refcount hugetlb_add_to_page_cache() ; adds 512 refcount (on x86) With the fix, after memfd_pin_folios + unpin_folios, the refcount for the (unfaulted) page is 512, which is correct, as the refcount for a faulted unpinned page is 513.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49873", "url": "https://ubuntu.com/security/CVE-2024-49873", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/filemap: fix filemap_get_folios_contig THP panic Patch series \"memfd-pin huge page fixes\". Fix multiple bugs that occur when using memfd_pin_folios with hugetlb pages and THP. The hugetlb bugs only bite when the page is not yet faulted in when memfd_pin_folios is called. The THP bug bites when the starting offset passed to memfd_pin_folios is not huge page aligned. See the commit messages for details. This patch (of 5): memfd_pin_folios on memory backed by THP panics if the requested start offset is not huge page aligned: BUG: kernel NULL pointer dereference, address: 0000000000000036 RIP: 0010:filemap_get_folios_contig+0xdf/0x290 RSP: 0018:ffffc9002092fbe8 EFLAGS: 00010202 RAX: 0000000000000002 RBX: 0000000000000002 RCX: 0000000000000002 The fault occurs here, because xas_load returns a folio with value 2: filemap_get_folios_contig() for (folio = xas_load(&xas); folio && xas.xa_index <= end; folio = xas_next(&xas)) { ... if (!folio_try_get(folio)) <-- BOOM \"2\" is an xarray sibling entry. We get it because memfd_pin_folios does not round the indices passed to filemap_get_folios_contig to huge page boundaries for THP, so we load from the middle of a huge page range see a sibling. (It does round for hugetlbfs, at the is_file_hugepages test). To fix, if the folio is a sibling, then return the next index as the starting point for the next call to filemap_get_folios_contig.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49977", "url": "https://ubuntu.com/security/CVE-2024-49977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: Fix zero-division error when disabling tc cbs The commit b8c43360f6e4 (\"net: stmmac: No need to calculate speed divider when offload is disabled\") allows the \"port_transmit_rate_kbps\" to be set to a value of 0, which is then passed to the \"div_s64\" function when tc-cbs is disabled. This leads to a zero-division error. When tc-cbs is disabled, the idleslope, sendslope, and credit values the credit values are not required to be configured. Therefore, adding a return statement after setting the txQ mode to DCB when tc-cbs is disabled would prevent a zero-division error.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49978", "url": "https://ubuntu.com/security/CVE-2024-49978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gso: fix udp gso fraglist segmentation after pull from frag_list Detect gso fraglist skbs with corrupted geometry (see below) and pass these to skb_segment instead of skb_segment_list, as the first can segment them correctly. 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 these skbs, breaking these invariants. In extreme cases they pull all data into skb linear. For UDP, this causes a NULL ptr deref in __udpv4_gso_segment_list_csum at udp_hdr(seg->next)->dest. Detect invalid geometry due to pull, by checking head_skb size. Don't just drop, as this may blackhole a destination. Convert to be able to pass to regular skb_segment.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49979", "url": "https://ubuntu.com/security/CVE-2024-49979", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gso: fix tcp fraglist segmentation after pull from frag_list Detect tcp gso fraglist skbs with corrupted geometry (see below) and pass these to skb_segment instead of skb_segment_list, as the first can segment them correctly. 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 these skbs, breaking these invariants. In extreme cases they pull all data into skb linear. For TCP, this causes a NULL ptr deref in __tcpv4_gso_segment_list_csum at tcp_hdr(seg->next). Detect invalid geometry due to pull, by checking head_skb size. Don't just drop, as this may blackhole a destination. Convert to be able to pass to regular skb_segment. Approach and description based on a patch by Willem de Bruijn.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49980", "url": "https://ubuntu.com/security/CVE-2024-49980", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vrf: revert \"vrf: Remove unnecessary RCU-bh critical section\" This reverts commit 504fc6f4f7f681d2a03aa5f68aad549d90eab853. dev_queue_xmit_nit is expected to be called with BH disabled. __dev_queue_xmit has the following: /* Disable soft irqs for various locks below. Also * stops preemption for RCU. */ rcu_read_lock_bh(); VRF must follow this invariant. The referenced commit removed this protection. Which triggered a lockdep warning: \t================================ \tWARNING: inconsistent lock state \t6.11.0 #1 Tainted: G W \t-------------------------------- \tinconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage. \tbtserver/134819 [HC0[0]:SC0[0]:HE1:SE1] takes: \tffff8882da30c118 (rlock-AF_PACKET){+.?.}-{2:2}, at: tpacket_rcv+0x863/0x3b30 \t{IN-SOFTIRQ-W} state was registered at: \t lock_acquire+0x19a/0x4f0 \t _raw_spin_lock+0x27/0x40 \t packet_rcv+0xa33/0x1320 \t __netif_receive_skb_core.constprop.0+0xcb0/0x3a90 \t __netif_receive_skb_list_core+0x2c9/0x890 \t netif_receive_skb_list_internal+0x610/0xcc0 [...] \tother info that might help us debug this: \t Possible unsafe locking scenario: \t CPU0 \t ---- \t lock(rlock-AF_PACKET); \t \t lock(rlock-AF_PACKET); \t *** DEADLOCK *** \tCall Trace: \t \t dump_stack_lvl+0x73/0xa0 \t mark_lock+0x102e/0x16b0 \t __lock_acquire+0x9ae/0x6170 \t lock_acquire+0x19a/0x4f0 \t _raw_spin_lock+0x27/0x40 \t tpacket_rcv+0x863/0x3b30 \t dev_queue_xmit_nit+0x709/0xa40 \t vrf_finish_direct+0x26e/0x340 [vrf] \t vrf_l3_out+0x5f4/0xe80 [vrf] \t __ip_local_out+0x51e/0x7a0 [...]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49981", "url": "https://ubuntu.com/security/CVE-2024-49981", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: venus: fix use after free bug in venus_remove due to race condition in venus_probe, core->work is bound with venus_sys_error_handler, which is used to handle error. The code use core->sys_err_done to make sync work. The core->work is started in venus_event_notify. If we call venus_remove, there might be an unfished work. The possible sequence is as follows: CPU0 CPU1 |venus_sys_error_handler venus_remove | hfi_destroy\t \t\t | venus_hfi_destroy\t | kfree(hdev);\t | |hfi_reinit \t\t\t\t\t |venus_hfi_queues_reinit |//use hdev Fix it by canceling the work in venus_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49956", "url": "https://ubuntu.com/security/CVE-2024-49956", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: fix double destroy_workqueue error When gfs2_fill_super() fails, destroy_workqueue() is called within gfs2_gl_hash_clear(), and the subsequent code path calls destroy_workqueue() on the same work queue again. This issue can be fixed by setting the work queue pointer to NULL after the first destroy_workqueue() call and checking for a NULL pointer before attempting to destroy the work queue again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50176", "url": "https://ubuntu.com/security/CVE-2024-50176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: k3-r5: Fix error handling when power-up failed By simply bailing out, the driver was violating its rule and internal assumptions that either both or no rproc should be initialized. E.g., this could cause the first core to be available but not the second one, leading to crashes on its shutdown later on while trying to dereference that second instance.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49982", "url": "https://ubuntu.com/security/CVE-2024-49982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: aoe: fix the potential use-after-free problem in more places For fixing CVE-2023-6270, f98364e92662 (\"aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts\") makes tx() calling dev_put() instead of doing in aoecmd_cfg_pkts(). It avoids that the tx() runs into use-after-free. Then Nicolai Stange found more places in aoe have potential use-after-free problem with tx(). e.g. revalidate(), aoecmd_ata_rw(), resend(), probe() and aoecmd_cfg_rsp(). Those functions also use aoenet_xmit() to push packet to tx queue. So they should also use dev_hold() to increase the refcnt of skb->dev. On the other hand, moving dev_put() to tx() causes that the refcnt of skb->dev be reduced to a negative value, because corresponding dev_hold() are not called in revalidate(), aoecmd_ata_rw(), resend(), probe(), and aoecmd_cfg_rsp(). This patch fixed this issue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49874", "url": "https://ubuntu.com/security/CVE-2024-49874", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: svc: Fix use after free vulnerability in svc_i3c_master Driver Due to Race Condition In the svc_i3c_master_probe function, &master->hj_work is bound with svc_i3c_master_hj_work, &master->ibi_work is bound with svc_i3c_master_ibi_work. And svc_i3c_master_ibi_work can start the hj_work, svc_i3c_master_irq_handler can start the ibi_work. If we remove the module which will call svc_i3c_master_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | svc_i3c_master_hj_work svc_i3c_master_remove | i3c_master_unregister(&master->base)| device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in svc_i3c_master_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49875", "url": "https://ubuntu.com/security/CVE-2024-49875", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: map the EBADMSG to nfserr_io to avoid warning Ext4 will throw -EBADMSG through ext4_readdir when a checksum error occurs, resulting in the following WARNING. Fix it by mapping EBADMSG to nfserr_io. nfsd_buffered_readdir iterate_dir // -EBADMSG -74 ext4_readdir // .iterate_shared ext4_dx_readdir ext4_htree_fill_tree htree_dirblock_to_tree ext4_read_dirblock __ext4_read_dirblock ext4_dirblock_csum_verify warn_no_space_for_csum __warn_no_space_for_csum return ERR_PTR(-EFSBADCRC) // -EBADMSG -74 nfserrno // WARNING [ 161.115610] ------------[ cut here ]------------ [ 161.116465] nfsd: non-standard errno: -74 [ 161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0 [ 161.118596] Modules linked in: [ 161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138 [ 161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qe mu.org 04/01/2014 [ 161.123601] RIP: 0010:nfserrno+0x9d/0xd0 [ 161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6 05 ce 2b 61 03 01 e8 99 20 d8 00 <0f> 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33 [ 161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286 [ 161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a [ 161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827 [ 161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021 [ 161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8 [ 161.135244] FS: 0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000 [ 161.136695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0 [ 161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 161.141519] PKRU: 55555554 [ 161.142076] Call Trace: [ 161.142575] ? __warn+0x9b/0x140 [ 161.143229] ? nfserrno+0x9d/0xd0 [ 161.143872] ? report_bug+0x125/0x150 [ 161.144595] ? handle_bug+0x41/0x90 [ 161.145284] ? exc_invalid_op+0x14/0x70 [ 161.146009] ? asm_exc_invalid_op+0x12/0x20 [ 161.146816] ? nfserrno+0x9d/0xd0 [ 161.147487] nfsd_buffered_readdir+0x28b/0x2b0 [ 161.148333] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.149258] ? nfsd_buffered_filldir+0xf0/0xf0 [ 161.150093] ? wait_for_concurrent_writes+0x170/0x170 [ 161.151004] ? generic_file_llseek_size+0x48/0x160 [ 161.151895] nfsd_readdir+0x132/0x190 [ 161.152606] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.153516] ? nfsd_unlink+0x380/0x380 [ 161.154256] ? override_creds+0x45/0x60 [ 161.155006] nfsd4_encode_readdir+0x21a/0x3d0 [ 161.155850] ? nfsd4_encode_readlink+0x210/0x210 [ 161.156731] ? write_bytes_to_xdr_buf+0x97/0xe0 [ 161.157598] ? __write_bytes_to_xdr_buf+0xd0/0xd0 [ 161.158494] ? lock_downgrade+0x90/0x90 [ 161.159232] ? nfs4svc_decode_voidarg+0x10/0x10 [ 161.160092] nfsd4_encode_operation+0x15a/0x440 [ 161.160959] nfsd4_proc_compound+0x718/0xe90 [ 161.161818] nfsd_dispatch+0x18e/0x2c0 [ 161.162586] svc_process_common+0x786/0xc50 [ 161.163403] ? nfsd_svc+0x380/0x380 [ 161.164137] ? svc_printk+0x160/0x160 [ 161.164846] ? svc_xprt_do_enqueue.part.0+0x365/0x380 [ 161.165808] ? nfsd_svc+0x380/0x380 [ 161.166523] ? rcu_is_watching+0x23/0x40 [ 161.167309] svc_process+0x1a5/0x200 [ 161.168019] nfsd+0x1f5/0x380 [ 161.168663] ? nfsd_shutdown_threads+0x260/0x260 [ 161.169554] kthread+0x1c4/0x210 [ 161.170224] ? kthread_insert_work_sanity_check+0x80/0x80 [ 161.171246] ret_from_fork+0x1f/0x30", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50013", "url": "https://ubuntu.com/security/CVE-2024-50013", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix memory leak in exfat_load_bitmap() If the first directory entry in the root directory is not a bitmap directory entry, 'bh' will not be released and reassigned, which will cause a memory leak.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49876", "url": "https://ubuntu.com/security/CVE-2024-49876", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: fix UAF around queue destruction We currently do stuff like queuing the final destruction step on a random system wq, which will outlive the driver instance. With bad timing we can teardown the driver with one or more work workqueue still being alive leading to various UAF splats. Add a fini step to ensure user queues are properly torn down. At this point GuC should already be nuked so queue itself should no longer be referenced from hw pov. v2 (Matt B) - Looks much safer to use a waitqueue and then just wait for the xa_array to become empty before triggering the drain. (cherry picked from commit 861108666cc0e999cffeab6aff17b662e68774e3)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49877", "url": "https://ubuntu.com/security/CVE-2024-49877", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate When doing cleanup, if flags without OCFS2_BH_READAHEAD, it may trigger NULL pointer dereference in the following ocfs2_set_buffer_uptodate() if bh is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49957", "url": "https://ubuntu.com/security/CVE-2024-49957", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix null-ptr-deref when journal load failed. During the mounting process, if journal_reset() fails because of too short journal, then lead to jbd2_journal_load() fails with NULL j_sb_buffer. Subsequently, ocfs2_journal_shutdown() calls jbd2_journal_flush()->jbd2_cleanup_journal_tail()-> __jbd2_update_log_tail()->jbd2_journal_update_sb_log_tail() ->lock_buffer(journal->j_sb_buffer), resulting in a null-pointer dereference error. To resolve this issue, we should check the JBD2_LOADED flag to ensure the journal was properly loaded. Additionally, use journal instead of osb->journal directly to simplify the code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49965", "url": "https://ubuntu.com/security/CVE-2024-49965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove unreasonable unlock in ocfs2_read_blocks Patch series \"Misc fixes for ocfs2_read_blocks\", v5. This series contains 2 fixes for ocfs2_read_blocks(). The first patch fix the issue reported by syzbot, which detects bad unlock balance in ocfs2_read_blocks(). The second patch fixes an issue reported by Heming Zhao when reviewing above fix. This patch (of 2): There was a lock release before exiting, so remove the unreasonable unlock.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49966", "url": "https://ubuntu.com/security/CVE-2024-49966", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: cancel dqi_sync_work before freeing oinfo ocfs2_global_read_info() will initialize and schedule dqi_sync_work at the end, if error occurs after successfully reading global quota, it will trigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled: ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16c This reports that there is an active delayed work when freeing oinfo in error handling, so cancel dqi_sync_work first. BTW, return status instead of -1 when .read_file_info fails.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49958", "url": "https://ubuntu.com/security/CVE-2024-49958", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reserve space for inline xattr before attaching reflink tree One of our customers reported a crash and a corrupted ocfs2 filesystem. The crash was due to the detection of corruption. Upon troubleshooting, the fsck -fn output showed the below corruption [EXTENT_LIST_FREE] Extent list in owner 33080590 claims 230 as the next free chain record, but fsck believes the largest valid value is 227. Clamp the next record value? n The stat output from the debugfs.ocfs2 showed the following corruption where the \"Next Free Rec:\" had overshot the \"Count:\" in the root metadata block. Inode: 33080590 Mode: 0640 Generation: 2619713622 (0x9c25a856) FS Generation: 904309833 (0x35e6ac49) CRC32: 00000000 ECC: 0000 Type: Regular Attr: 0x0 Flags: Valid Dynamic Features: (0x16) HasXattr InlineXattr Refcounted Extended Attributes Block: 0 Extended Attributes Inline Size: 256 User: 0 (root) Group: 0 (root) Size: 281320357888 Links: 1 Clusters: 141738 ctime: 0x66911b56 0x316edcb8 -- Fri Jul 12 06:02:30.829349048 2024 atime: 0x66911d6b 0x7f7a28d -- Fri Jul 12 06:11:23.133669517 2024 mtime: 0x66911b56 0x12ed75d7 -- Fri Jul 12 06:02:30.317552087 2024 dtime: 0x0 -- Wed Dec 31 17:00:00 1969 Refcount Block: 2777346 Last Extblk: 2886943 Orphan Slot: 0 Sub Alloc Slot: 0 Sub Alloc Bit: 14 Tree Depth: 1 Count: 227 Next Free Rec: 230 ## Offset Clusters Block# 0 0 2310 2776351 1 2310 2139 2777375 2 4449 1221 2778399 3 5670 731 2779423 4 6401 566 2780447 ....... .... ....... ....... .... ....... The issue was in the reflink workfow while reserving space for inline xattr. The problematic function is ocfs2_reflink_xattr_inline(). By the time this function is called the reflink tree is already recreated at the destination inode from the source inode. At this point, this function reserves space for inline xattrs at the destination inode without even checking if there is space at the root metadata block. It simply reduces the l_count from 243 to 227 thereby making space of 256 bytes for inline xattr whereas the inode already has extents beyond this index (in this case up to 230), thereby causing corruption. The fix for this is to reserve space for inline metadata at the destination inode before the reflink tree gets recreated. The customer has verified the fix.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49959", "url": "https://ubuntu.com/security/CVE-2024-49959", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail() to recover some journal space. But if an error occurs while executing jbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for free space right away, we try other branches, and if j_committing_transaction is NULL (i.e., the tid is 0), we will get the following complain: ============================================ JBD2: I/O error when updating journal superblock for sdd-8. __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available __jbd2_log_wait_for_space: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Call Trace: add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70 [...] ============================================ So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways. Note that this fix relies on commit 6f6a6fda2945 (\"jbd2: fix ocfs2 corrupt when updating journal superblock fails\") to make jbd2_cleanup_journal_tail return the correct error code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49878", "url": "https://ubuntu.com/security/CVE-2024-49878", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: resource: fix region_intersects() vs add_memory_driver_managed() On a system with CXL memory, the resource tree (/proc/iomem) related to CXL memory may look like something as follows. 490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem) Because drivers/dax/kmem.c calls add_memory_driver_managed() during onlining CXL memory, which makes \"System RAM (kmem)\" a descendant of \"CXL Window X\". This confuses region_intersects(), which expects all \"System RAM\" resources to be at the top level of iomem_resource. This can lead to bugs. For example, when the following command line is executed to write some memory in CXL memory range via /dev/mem, $ dd if=data of=/dev/mem bs=$((1 << 10)) seek=$((0x490000000 >> 10)) count=1 dd: error writing '/dev/mem': Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/s the command fails as expected. However, the error code is wrong. It should be \"Operation not permitted\" instead of \"Bad address\". More seriously, the /dev/mem permission checking in devmem_is_allowed() passes incorrectly. Although the accessing is prevented later because ioremap() isn't allowed to map system RAM, it is a potential security issue. During command executing, the following warning is reported in the kernel log for calling ioremap() on system RAM. ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d Call Trace: memremap+0xcb/0x184 xlate_dev_mem_ptr+0x25/0x2f write_mem+0x94/0xfb vfs_write+0x128/0x26d ksys_write+0xac/0xfe do_syscall_64+0x9a/0xfd entry_SYSCALL_64_after_hwframe+0x4b/0x53 The details of command execution process are as follows. In the above resource tree, \"System RAM\" is a descendant of \"CXL Window 0\" instead of a top level resource. So, region_intersects() will report no System RAM resources in the CXL memory region incorrectly, because it only checks the top level resources. Consequently, devmem_is_allowed() will return 1 (allow access via /dev/mem) for CXL memory region incorrectly. Fortunately, ioremap() doesn't allow to map System RAM and reject the access. So, region_intersects() needs to be fixed to work correctly with the resource tree with \"System RAM\" not at top level as above. To fix it, if we found a unmatched resource in the top level, we will continue to search matched resources in its descendant resources. So, we will not miss any matched resources in resource tree anymore. In the new implementation, an example resource tree |------------- \"CXL Window 0\" ------------| |-- \"System RAM\" --| will behave similar as the following fake resource tree for region_intersects(, IORESOURCE_SYSTEM_RAM, ), |-- \"System RAM\" --||-- \"CXL Window 0a\" --| Where \"CXL Window 0a\" is part of the original \"CXL Window 0\" that isn't covered by \"System RAM\".", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49879", "url": "https://ubuntu.com/security/CVE-2024-49879", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm: omapdrm: Add missing check for alloc_ordered_workqueue As it may return NULL pointer and cause NULL pointer dereference. Add check for the return value of alloc_ordered_workqueue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49880", "url": "https://ubuntu.com/security/CVE-2024-49880", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix off by one issue in alloc_flex_gd() Wesley reported an issue: ================================================================== EXT4-fs (dm-5): resizing filesystem from 7168 to 786432 blocks ------------[ cut here ]------------ kernel BUG at fs/ext4/resize.c:324! CPU: 9 UID: 0 PID: 3576 Comm: resize2fs Not tainted 6.11.0+ #27 RIP: 0010:ext4_resize_fs+0x1212/0x12d0 Call Trace: __ext4_ioctl+0x4e0/0x1800 ext4_ioctl+0x12/0x20 __x64_sys_ioctl+0x99/0xd0 x64_sys_call+0x1206/0x20d0 do_syscall_64+0x72/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e ================================================================== While reviewing the patch, Honza found that when adjusting resize_bg in alloc_flex_gd(), it was possible for flex_gd->resize_bg to be bigger than flexbg_size. The reproduction of the problem requires the following: o_group = flexbg_size * 2 * n; o_size = (o_group + 1) * group_size; n_group: [o_group + flexbg_size, o_group + flexbg_size * 2) o_size = (n_group + 1) * group_size; Take n=0,flexbg_size=16 as an example: last:15 |o---------------|--------------n-| o_group:0 resize to n_group:30 The corresponding reproducer is: img=test.img rm -f $img truncate -s 600M $img mkfs.ext4 -F $img -b 1024 -G 16 8M dev=`losetup -f --show $img` mkdir -p /tmp/test mount $dev /tmp/test resize2fs $dev 248M Delete the problematic plus 1 to fix the issue, and add a WARN_ON_ONCE() to prevent the issue from happening again. [ Note: another reproucer which this commit fixes is: img=test.img rm -f $img truncate -s 25MiB $img mkfs.ext4 -b 4096 -E nodiscard,lazy_itable_init=0,lazy_journal_init=0 $img truncate -s 3GiB $img dev=`losetup -f --show $img` mkdir -p /tmp/test mount $dev /tmp/test resize2fs $dev 3G umount $dev losetup -d $dev -- TYT ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49881", "url": "https://ubuntu.com/security/CVE-2024-49881", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: update orig_path in ext4_find_extent() In ext4_find_extent(), if the path is not big enough, we free it and set *orig_path to NULL. But after reallocating and successfully initializing the path, we don't update *orig_path, in which case the caller gets a valid path but a NULL ppath, and this may cause a NULL pointer dereference or a path memory leak. For example: ext4_split_extent path = *ppath = 2000 ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path = 2000); *orig_path = path = NULL; path = kcalloc() = 3000 ext4_split_extent_at(*ppath = NULL) path = *ppath; ex = path[depth].p_ext; // NULL pointer dereference! ================================================================== BUG: kernel NULL pointer dereference, address: 0000000000000010 CPU: 6 UID: 0 PID: 576 Comm: fsstress Not tainted 6.11.0-rc2-dirty #847 RIP: 0010:ext4_split_extent_at+0x6d/0x560 Call Trace: ext4_split_extent.isra.0+0xcb/0x1b0 ext4_ext_convert_to_initialized+0x168/0x6c0 ext4_ext_handle_unwritten_extents+0x325/0x4d0 ext4_ext_map_blocks+0x520/0xdb0 ext4_map_blocks+0x2b0/0x690 ext4_iomap_begin+0x20e/0x2c0 [...] ================================================================== Therefore, *orig_path is updated when the extent lookup succeeds, so that the caller can safely use path or *ppath.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50014", "url": "https://ubuntu.com/security/CVE-2024-50014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix access to uninitialised lock in fc replay path The following kernel trace can be triggered with fstest generic/629 when executed against a filesystem with fast-commit feature enabled: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x66/0x90 register_lock_class+0x759/0x7d0 __lock_acquire+0x85/0x2630 ? __find_get_block+0xb4/0x380 lock_acquire+0xd1/0x2d0 ? __ext4_journal_get_write_access+0xd5/0x160 _raw_spin_lock+0x33/0x40 ? __ext4_journal_get_write_access+0xd5/0x160 __ext4_journal_get_write_access+0xd5/0x160 ext4_reserve_inode_write+0x61/0xb0 __ext4_mark_inode_dirty+0x79/0x270 ? ext4_ext_replay_set_iblocks+0x2f8/0x450 ext4_ext_replay_set_iblocks+0x330/0x450 ext4_fc_replay+0x14c8/0x1540 ? jread+0x88/0x2e0 ? rcu_is_watching+0x11/0x40 do_one_pass+0x447/0xd00 jbd2_journal_recover+0x139/0x1b0 jbd2_journal_load+0x96/0x390 ext4_load_and_init_journal+0x253/0xd40 ext4_fill_super+0x2cc6/0x3180 ... In the replay path there's an attempt to lock sbi->s_bdev_wb_lock in function ext4_check_bdev_write_error(). Unfortunately, at this point this spinlock has not been initialized yet. Moving it's initialization to an earlier point in __ext4_fill_super() fixes this splat.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49960", "url": "https://ubuntu.com/security/CVE-2024-49960", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix timer use-after-free on failed mount Syzbot has found an ODEBUG bug in ext4_fill_super The del_timer_sync function cancels the s_err_report timer, which reminds about filesystem errors daily. We should guarantee the timer is no longer active before kfree(sbi). When filesystem mounting fails, the flow goes to failed_mount3, where an error occurs when ext4_stop_mmpd is called, causing a read I/O failure. This triggers the ext4_handle_error function that ultimately re-arms the timer, leaving the s_err_report timer active before kfree(sbi) is called. Fix the issue by canceling the s_err_report timer after calling ext4_stop_mmpd.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49882", "url": "https://ubuntu.com/security/CVE-2024-49882", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix double brelse() the buffer of the extents path In ext4_ext_try_to_merge_up(), set path[1].p_bh to NULL after it has been released, otherwise it may be released twice. An example of what triggers this is as follows: split2 map split1 |--------|-------|--------| ext4_ext_map_blocks ext4_ext_handle_unwritten_extents ext4_split_convert_extents // path->p_depth == 0 ext4_split_extent // 1. do split1 ext4_split_extent_at |ext4_ext_insert_extent | ext4_ext_create_new_leaf | ext4_ext_grow_indepth | le16_add_cpu(&neh->eh_depth, 1) | ext4_find_extent | // return -ENOMEM |// get error and try zeroout |path = ext4_find_extent | path->p_depth = 1 |ext4_ext_try_to_merge | ext4_ext_try_to_merge_up | path->p_depth = 0 | brelse(path[1].p_bh) ---> not set to NULL here |// zeroout success // 2. update path ext4_find_extent // 3. do split2 ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth le16_add_cpu(&neh->eh_depth, 1) ext4_find_extent path[0].p_bh = NULL; path->p_depth = 1 read_extent_tree_block ---> return err // path[1].p_bh is still the old value ext4_free_ext_path ext4_ext_drop_refs // path->p_depth == 1 brelse(path[1].p_bh) ---> brelse a buffer twice Finally got the following WARRNING when removing the buffer from lru: ============================================ VFS: brelse: Trying to free free buffer WARNING: CPU: 2 PID: 72 at fs/buffer.c:1241 __brelse+0x58/0x90 CPU: 2 PID: 72 Comm: kworker/u19:1 Not tainted 6.9.0-dirty #716 RIP: 0010:__brelse+0x58/0x90 Call Trace: __find_get_block+0x6e7/0x810 bdev_getblk+0x2b/0x480 __ext4_get_inode_loc+0x48a/0x1240 ext4_get_inode_loc+0xb2/0x150 ext4_reserve_inode_write+0xb7/0x230 __ext4_mark_inode_dirty+0x144/0x6a0 ext4_ext_insert_extent+0x9c8/0x3230 ext4_ext_map_blocks+0xf45/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] ============================================", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49883", "url": "https://ubuntu.com/security/CVE-2024-49883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: aovid use-after-free in ext4_ext_insert_extent() As Ojaswin mentioned in Link, in ext4_ext_insert_extent(), if the path is reallocated in ext4_ext_create_new_leaf(), we'll use the stale path and cause UAF. Below is a sample trace with dummy values: ext4_ext_insert_extent path = *ppath = 2000 ext4_ext_create_new_leaf(ppath) ext4_find_extent(ppath) path = *ppath = 2000 if (depth > path[0].p_maxdepth) kfree(path = 2000); *ppath = path = NULL; path = kcalloc() = 3000 *ppath = 3000; return path; /* here path is still 2000, UAF! */ eh = path[depth].p_hdr ================================================================== BUG: KASAN: slab-use-after-free in ext4_ext_insert_extent+0x26d4/0x3330 Read of size 8 at addr ffff8881027bf7d0 by task kworker/u36:1/179 CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 Not tainted 6.11.0-rc2-dirty #866 Call Trace: ext4_ext_insert_extent+0x26d4/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 [...] Allocated by task 179: ext4_find_extent+0x81c/0x1f70 ext4_ext_map_blocks+0x146/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...] Freed by task 179: kfree+0xcb/0x240 ext4_find_extent+0x7c0/0x1f70 ext4_ext_insert_extent+0xa26/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...] ================================================================== So use *ppath to update the path to avoid the above problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49983", "url": "https://ubuntu.com/security/CVE-2024-49983", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-free When calling ext4_force_split_extent_at() in ext4_ext_replay_update_ex(), the 'ppath' is updated but it is the 'path' that is freed, thus potentially triggering a double-free in the following process: ext4_ext_replay_update_ex ppath = path ext4_force_split_extent_at(&ppath) ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path) ---> path First freed *orig_path = path = NULL ---> null ppath kfree(path) ---> path double-free !!! So drop the unnecessary ppath and use path directly to avoid this problem. And use ext4_find_extent() directly to update path, avoiding unnecessary memory allocation and freeing. Also, propagate the error returned by ext4_find_extent() instead of using strange error codes.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50015", "url": "https://ubuntu.com/security/CVE-2024-50015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: dax: fix overflowing extents beyond inode size when partially writing The dax_iomap_rw() does two things in each iteration: map written blocks and copy user data to blocks. If the process is killed by user(See signal handling in dax_iomap_iter()), the copied data will be returned and added on inode size, which means that the length of written extents may exceed the inode size, then fsck will fail. An example is given as: dd if=/dev/urandom of=file bs=4M count=1 dax_iomap_rw iomap_iter // round 1 ext4_iomap_begin ext4_iomap_alloc // allocate 0~2M extents(written flag) dax_iomap_iter // copy 2M data iomap_iter // round 2 iomap_iter_advance iter->pos += iter->processed // iter->pos = 2M ext4_iomap_begin ext4_iomap_alloc // allocate 2~4M extents(written flag) dax_iomap_iter fatal_signal_pending done = iter->pos - iocb->ki_pos // done = 2M ext4_handle_inode_extension ext4_update_inode_size // inode size = 2M fsck reports: Inode 13, i_size is 2097152, should be 4194304. Fix? Fix the problem by truncating extents if the written length is smaller than expected.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49884", "url": "https://ubuntu.com/security/CVE-2024-49884", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix slab-use-after-free in ext4_split_extent_at() We hit the following use-after-free: ================================================================== BUG: KASAN: slab-use-after-free in ext4_split_extent_at+0xba8/0xcc0 Read of size 2 at addr ffff88810548ed08 by task kworker/u20:0/40 CPU: 0 PID: 40 Comm: kworker/u20:0 Not tainted 6.9.0-dirty #724 Call Trace: kasan_report+0x93/0xc0 ext4_split_extent_at+0xba8/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] Allocated by task 40: __kmalloc_noprof+0x1ac/0x480 ext4_find_extent+0xf3b/0x1e70 ext4_ext_map_blocks+0x188/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] Freed by task 40: kfree+0xf1/0x2b0 ext4_find_extent+0xa71/0x1e70 ext4_ext_insert_extent+0xa22/0x3260 ext4_split_extent_at+0x3ef/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] ================================================================== The flow of issue triggering is as follows: ext4_split_extent_at path = *ppath ext4_ext_insert_extent(ppath) ext4_ext_create_new_leaf(ppath) ext4_find_extent(orig_path) path = *orig_path read_extent_tree_block // return -ENOMEM or -EIO ext4_free_ext_path(path) kfree(path) *orig_path = NULL a. If err is -ENOMEM: ext4_ext_dirty(path + path->p_depth) // path use-after-free !!! b. If err is -EIO and we have EXT_DEBUG defined: ext4_ext_show_leaf(path) eh = path[depth].p_hdr // path also use-after-free !!! So when trying to zeroout or fix the extent length, call ext4_find_extent() to update the path. In addition we use *ppath directly as an ext4_ext_show_leaf() input to avoid possible use-after-free when EXT_DEBUG is defined, and to avoid unnecessary path updates.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49885", "url": "https://ubuntu.com/security/CVE-2024-49885", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm, slub: avoid zeroing kmalloc redzone Since commit 946fa0dbf2d8 (\"mm/slub: extend redzone check to extra allocated kmalloc space than requested\"), setting orig_size treats the wasted space (object_size - orig_size) as a redzone. However with init_on_free=1 we clear the full object->size, including the redzone. Additionally we clear the object metadata, including the stored orig_size, making it zero, which makes check_object() treat the whole object as a redzone. These issues lead to the following BUG report with \"slub_debug=FUZ init_on_free=1\": [ 0.000000] ============================================================================= [ 0.000000] BUG kmalloc-8 (Not tainted): kmalloc Redzone overwritten [ 0.000000] ----------------------------------------------------------------------------- [ 0.000000] [ 0.000000] 0xffff000010032858-0xffff00001003285f @offset=2136. First byte 0x0 instead of 0xcc [ 0.000000] FIX kmalloc-8: Restoring kmalloc Redzone 0xffff000010032858-0xffff00001003285f=0xcc [ 0.000000] Slab 0xfffffdffc0400c80 objects=36 used=23 fp=0xffff000010032a18 flags=0x3fffe0000000200(workingset|node=0|zone=0|lastcpupid=0x1ffff) [ 0.000000] Object 0xffff000010032858 @offset=2136 fp=0xffff0000100328c8 [ 0.000000] [ 0.000000] Redzone ffff000010032850: cc cc cc cc cc cc cc cc ........ [ 0.000000] Object ffff000010032858: cc cc cc cc cc cc cc cc ........ [ 0.000000] Redzone ffff000010032860: cc cc cc cc cc cc cc cc ........ [ 0.000000] Padding ffff0000100328b4: 00 00 00 00 00 00 00 00 00 00 00 00 ............ [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.11.0-rc3-next-20240814-00004-g61844c55c3f4 #144 [ 0.000000] Hardware name: NXP i.MX95 19X19 board (DT) [ 0.000000] Call trace: [ 0.000000] dump_backtrace+0x90/0xe8 [ 0.000000] show_stack+0x18/0x24 [ 0.000000] dump_stack_lvl+0x74/0x8c [ 0.000000] dump_stack+0x18/0x24 [ 0.000000] print_trailer+0x150/0x218 [ 0.000000] check_object+0xe4/0x454 [ 0.000000] free_to_partial_list+0x2f8/0x5ec To address the issue, use orig_size to clear the used area. And restore the value of orig_size after clear the remaining area. When CONFIG_SLUB_DEBUG not defined, (get_orig_size()' directly returns s->object_size. So when using memset to init the area, the size can simply be orig_size, as orig_size returns object_size when CONFIG_SLUB_DEBUG not enabled. And orig_size can never be bigger than object_size.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49961", "url": "https://ubuntu.com/security/CVE-2024-49961", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: ar0521: Use cansleep version of gpiod_set_value() If we use GPIO reset from I2C port expander, we must use *_cansleep() variant of GPIO functions. This was not done in ar0521_power_on()/ar0521_power_off() functions. Let's fix that. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 11 at drivers/gpio/gpiolib.c:3496 gpiod_set_value+0x74/0x7c Modules linked in: CPU: 0 PID: 11 Comm: kworker/u16:0 Not tainted 6.10.0 #53 Hardware name: Diasom DS-RK3568-SOM-EVB (DT) Workqueue: events_unbound deferred_probe_work_func pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : gpiod_set_value+0x74/0x7c lr : ar0521_power_on+0xcc/0x290 sp : ffffff8001d7ab70 x29: ffffff8001d7ab70 x28: ffffff80027dcc90 x27: ffffff8003c82000 x26: ffffff8003ca9250 x25: ffffffc080a39c60 x24: ffffff8003ca9088 x23: ffffff8002402720 x22: ffffff8003ca9080 x21: ffffff8003ca9088 x20: 0000000000000000 x19: ffffff8001eb2a00 x18: ffffff80efeeac80 x17: 756d2d6332692f30 x16: 0000000000000000 x15: 0000000000000000 x14: ffffff8001d91d40 x13: 0000000000000016 x12: ffffffc080e98930 x11: ffffff8001eb2880 x10: 0000000000000890 x9 : ffffff8001d7a9f0 x8 : ffffff8001d92570 x7 : ffffff80efeeac80 x6 : 000000003fc6e780 x5 : ffffff8001d91c80 x4 : 0000000000000002 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000001 Call trace: gpiod_set_value+0x74/0x7c ar0521_power_on+0xcc/0x290 ...", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49985", "url": "https://ubuntu.com/security/CVE-2024-49985", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume In case there is any sort of clock controller attached to this I2C bus controller, for example Versaclock or even an AIC32x4 I2C codec, then an I2C transfer triggered from the clock controller clk_ops .prepare callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex. This is because the clock controller first grabs the prepare_lock mutex and then performs the prepare operation, including its I2C access. The I2C access resumes this I2C bus controller via .runtime_resume callback, which calls clk_prepare_enable(), which attempts to grab the prepare_lock mutex again and deadlocks. Since the clock are already prepared since probe() and unprepared in remove(), use simple clk_enable()/clk_disable() calls to enable and disable the clock on runtime suspend and resume, to avoid hitting the prepare_lock mutex.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49886", "url": "https://ubuntu.com/security/CVE-2024-49886", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bug Attaching SST PCI device to VM causes \"BUG: KASAN: slab-out-of-bounds\". kasan report: [ 19.411889] ================================================================== [ 19.413702] BUG: KASAN: slab-out-of-bounds in _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.415634] Read of size 8 at addr ffff888829e65200 by task cpuhp/16/113 [ 19.417368] [ 19.418627] CPU: 16 PID: 113 Comm: cpuhp/16 Tainted: G E 6.9.0 #10 [ 19.420435] Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.20192059.B64.2207280713 07/28/2022 [ 19.422687] Call Trace: [ 19.424091] [ 19.425448] dump_stack_lvl+0x5d/0x80 [ 19.426963] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.428694] print_report+0x19d/0x52e [ 19.430206] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 19.431837] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.433539] kasan_report+0xf0/0x170 [ 19.435019] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.436709] _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.438379] ? __pfx_sched_clock_cpu+0x10/0x10 [ 19.439910] isst_if_cpu_online+0x406/0x58f [isst_if_common] [ 19.441573] ? __pfx_isst_if_cpu_online+0x10/0x10 [isst_if_common] [ 19.443263] ? ttwu_queue_wakelist+0x2c1/0x360 [ 19.444797] cpuhp_invoke_callback+0x221/0xec0 [ 19.446337] cpuhp_thread_fun+0x21b/0x610 [ 19.447814] ? __pfx_cpuhp_thread_fun+0x10/0x10 [ 19.449354] smpboot_thread_fn+0x2e7/0x6e0 [ 19.450859] ? __pfx_smpboot_thread_fn+0x10/0x10 [ 19.452405] kthread+0x29c/0x350 [ 19.453817] ? __pfx_kthread+0x10/0x10 [ 19.455253] ret_from_fork+0x31/0x70 [ 19.456685] ? __pfx_kthread+0x10/0x10 [ 19.458114] ret_from_fork_asm+0x1a/0x30 [ 19.459573] [ 19.460853] [ 19.462055] Allocated by task 1198: [ 19.463410] kasan_save_stack+0x30/0x50 [ 19.464788] kasan_save_track+0x14/0x30 [ 19.466139] __kasan_kmalloc+0xaa/0xb0 [ 19.467465] __kmalloc+0x1cd/0x470 [ 19.468748] isst_if_cdev_register+0x1da/0x350 [isst_if_common] [ 19.470233] isst_if_mbox_init+0x108/0xff0 [isst_if_mbox_msr] [ 19.471670] do_one_initcall+0xa4/0x380 [ 19.472903] do_init_module+0x238/0x760 [ 19.474105] load_module+0x5239/0x6f00 [ 19.475285] init_module_from_file+0xd1/0x130 [ 19.476506] idempotent_init_module+0x23b/0x650 [ 19.477725] __x64_sys_finit_module+0xbe/0x130 [ 19.476506] idempotent_init_module+0x23b/0x650 [ 19.477725] __x64_sys_finit_module+0xbe/0x130 [ 19.478920] do_syscall_64+0x82/0x160 [ 19.480036] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 19.481292] [ 19.482205] The buggy address belongs to the object at ffff888829e65000 which belongs to the cache kmalloc-512 of size 512 [ 19.484818] The buggy address is located 0 bytes to the right of allocated 512-byte region [ffff888829e65000, ffff888829e65200) [ 19.487447] [ 19.488328] The buggy address belongs to the physical page: [ 19.489569] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888829e60c00 pfn:0x829e60 [ 19.491140] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [ 19.492466] anon flags: 0x57ffffc0000840(slab|head|node=1|zone=2|lastcpupid=0x1fffff) [ 19.493914] page_type: 0xffffffff() [ 19.494988] raw: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [ 19.496451] raw: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [ 19.497906] head: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [ 19.499379] head: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [ 19.500844] head: 0057ffffc0000003 ffffea0020a79801 ffffea0020a79848 00000000ffffffff [ 19.502316] head: 0000000800000000 0000000000000000 00000000ffffffff 0000000000000000 [ 19.503784] page dumped because: k ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49986", "url": "https://ubuntu.com/security/CVE-2024-49986", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: x86-android-tablets: Fix use after free on platform_device_register() errors x86_android_tablet_remove() frees the pdevs[] array, so it should not be used after calling x86_android_tablet_remove(). When platform_device_register() fails, store the pdevs[x] PTR_ERR() value into the local ret variable before calling x86_android_tablet_remove() to avoid using pdevs[] after it has been freed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49887", "url": "https://ubuntu.com/security/CVE-2024-49887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to don't panic system for no free segment fault injection f2fs: fix to don't panic system for no free segment fault injection syzbot reports a f2fs bug as below: F2FS-fs (loop0): inject no free segment in get_new_segment of __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3167 F2FS-fs (loop0): Stopped filesystem due to reason: 7 ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2748! CPU: 0 UID: 0 PID: 5109 Comm: syz-executor304 Not tainted 6.11.0-rc6-syzkaller-00363-g89f5e14d05b4 #0 RIP: 0010:get_new_segment fs/f2fs/segment.c:2748 [inline] RIP: 0010:new_curseg+0x1f61/0x1f70 fs/f2fs/segment.c:2836 Call Trace: __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3167 f2fs_allocate_new_section fs/f2fs/segment.c:3181 [inline] f2fs_allocate_pinning_section+0xfa/0x4e0 fs/f2fs/segment.c:3195 f2fs_expand_inode_data+0x5d6/0xbb0 fs/f2fs/file.c:1799 f2fs_fallocate+0x448/0x960 fs/f2fs/file.c:1903 vfs_fallocate+0x553/0x6c0 fs/open.c:334 do_vfs_ioctl+0x2592/0x2e50 fs/ioctl.c:886 __do_sys_ioctl fs/ioctl.c:905 [inline] __se_sys_ioctl+0x81/0x170 fs/ioctl.c:893 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: 0010:get_new_segment fs/f2fs/segment.c:2748 [inline] RIP: 0010:new_curseg+0x1f61/0x1f70 fs/f2fs/segment.c:2836 The root cause is when we inject no free segment fault into f2fs, we should not panic system, fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49888", "url": "https://ubuntu.com/security/CVE-2024-49888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix a sdiv overflow issue Zac Ecob reported a problem where a bpf program may cause kernel crash due to the following error: Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI The failure is due to the below signed divide: LLONG_MIN/-1 where LLONG_MIN equals to -9,223,372,036,854,775,808. LLONG_MIN/-1 is supposed to give a positive number 9,223,372,036,854,775,808, but it is impossible since for 64-bit system, the maximum positive number is 9,223,372,036,854,775,807. On x86_64, LLONG_MIN/-1 will cause a kernel exception. On arm64, the result for LLONG_MIN/-1 is LLONG_MIN. Further investigation found all the following sdiv/smod cases may trigger an exception when bpf program is running on x86_64 platform: - LLONG_MIN/-1 for 64bit operation - INT_MIN/-1 for 32bit operation - LLONG_MIN%-1 for 64bit operation - INT_MIN%-1 for 32bit operation where -1 can be an immediate or in a register. On arm64, there are no exceptions: - LLONG_MIN/-1 = LLONG_MIN - INT_MIN/-1 = INT_MIN - LLONG_MIN%-1 = 0 - INT_MIN%-1 = 0 where -1 can be an immediate or in a register. Insn patching is needed to handle the above cases and the patched codes produced results aligned with above arm64 result. The below are pseudo codes to handle sdiv/smod exceptions including both divisor -1 and divisor 0 and the divisor is stored in a register. sdiv: tmp = rX tmp += 1 /* [-1, 0] -> [0, 1] if tmp >(unsigned) 1 goto L2 if tmp == 0 goto L1 rY = 0 L1: rY = -rY; goto L3 L2: rY /= rX L3: smod: tmp = rX tmp += 1 /* [-1, 0] -> [0, 1] if tmp >(unsigned) 1 goto L1 if tmp == 1 (is64 ? goto L2 : goto L3) rY = 0; goto L2 L1: rY %= rX L2: goto L4 // only when !is64 L3: wY = wY // only when !is64 L4: [1] https://lore.kernel.org/bpf/tPJLTEh7S_DxFEqAI2Ji5MBSoZVg7_G-Py2iaZpAaWtM961fFTWtsnlzwvTbzBzaUzwQAoNATXKUlt0LZOFgnDcIyKCswAnAGdUF3LBrhGQ=@protonmail.com/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49987", "url": "https://ubuntu.com/security/CVE-2024-49987", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpftool: Fix undefined behavior in qsort(NULL, 0, ...) When netfilter has no entry to display, qsort is called with qsort(NULL, 0, ...). This results in undefined behavior, as UBSan reports: net.c:827:2: runtime error: null pointer passed as argument 1, which is declared to never be null Although the C standard does not explicitly state whether calling qsort with a NULL pointer when the size is 0 constitutes undefined behavior, Section 7.1.4 of the C standard (Use of library functions) mentions: \"Each of the following statements applies unless explicitly stated otherwise in the detailed descriptions that follow: If an argument to a function has an invalid value (such as a value outside the domain of the function, or a pointer outside the address space of the program, or a null pointer, or a pointer to non-modifiable storage when the corresponding parameter is not const-qualified) or a type (after promotion) not expected by a function with variable number of arguments, the behavior is undefined.\" To avoid this, add an early return when nf_link_info is NULL to prevent calling qsort with a NULL pointer.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50006", "url": "https://ubuntu.com/security/CVE-2024-50006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix i_data_sem unlock order in ext4_ind_migrate() Fuzzing reports a possible deadlock in jbd2_log_wait_commit. This issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to require synchronous updates because the file descriptor is opened with O_SYNC. This can lead to the jbd2_journal_stop() function calling jbd2_might_wait_for_commit(), potentially causing a deadlock if the EXT4_IOC_MIGRATE call races with a write(2) system call. This problem only arises when CONFIG_PROVE_LOCKING is enabled. In this case, the jbd2_might_wait_for_commit macro locks jbd2_handle in the jbd2_journal_stop function while i_data_sem is locked. This triggers lockdep because the jbd2_journal_start function might also lock the same jbd2_handle simultaneously. Found by Linux Verification Center (linuxtesting.org) with syzkaller. Rule: add", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49889", "url": "https://ubuntu.com/security/CVE-2024-49889", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid use-after-free in ext4_ext_show_leaf() In ext4_find_extent(), path may be freed by error or be reallocated, so using a previously saved *ppath may have been freed and thus may trigger use-after-free, as follows: ext4_split_extent path = *ppath; ext4_split_extent_at(ppath) path = ext4_find_extent(ppath) ext4_split_extent_at(ppath) // ext4_find_extent fails to free path // but zeroout succeeds ext4_ext_show_leaf(inode, path) eh = path[depth].p_hdr // path use-after-free !!! Similar to ext4_split_extent_at(), we use *ppath directly as an input to ext4_ext_show_leaf(). Fix a spelling error by the way. Same problem in ext4_ext_handle_unwritten_extents(). Since 'path' is only used in ext4_ext_show_leaf(), remove 'path' and use *ppath directly. This issue is triggered only when EXT_DEBUG is defined and therefore does not affect functionality.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49968", "url": "https://ubuntu.com/security/CVE-2024-49968", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: filesystems without casefold feature cannot be mounted with siphash When mounting the ext4 filesystem, if the default hash version is set to DX_HASH_SIPHASH but the casefold feature is not set, exit the mounting.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49988", "url": "https://ubuntu.com/security/CVE-2024-49988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: add refcnt to ksmbd_conn struct When sending an oplock break request, opinfo->conn is used, But freed ->conn can be used on multichannel. This patch add a reference count to the ksmbd_conn struct so that it can be freed when it is no longer used.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49890", "url": "https://ubuntu.com/security/CVE-2024-49890", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: ensure the fw_info is not null before using it This resolves the dereference null return value warning reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49891", "url": "https://ubuntu.com/security/CVE-2024-49891", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata paths When the HBA is undergoing a reset or is handling an errata event, NULL ptr dereference crashes may occur in routines such as lpfc_sli_flush_io_rings(), lpfc_dev_loss_tmo_callbk(), or lpfc_abort_handler(). Add NULL ptr checks before dereferencing hdwq pointers that may have been freed due to operations colliding with a reset or errata event handler.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49892", "url": "https://ubuntu.com/security/CVE-2024-49892", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize get_bytes_per_element's default to 1 Variables, used as denominators and maybe not assigned to other values, should not be 0. bytes_per_element_y & bytes_per_element_c are initialized by get_bytes_per_element() which should never return 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50016", "url": "https://ubuntu.com/security/CVE-2024-50016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Avoid overflow assignment in link_dp_cts sampling_rate is an uint8_t but is assigned an unsigned int, and thus it can overflow. As a result, sampling_rate is changed to uint32_t. Similarly, LINK_QUAL_PATTERN_SET has a size of 2 bits, and it should only be assigned to a value less or equal than 4. This fixes 2 INTEGER_OVERFLOW issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49893", "url": "https://ubuntu.com/security/CVE-2024-49893", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check stream_status before it is used [WHAT & HOW] dc_state_get_stream_status can return null, and therefore null must be checked before stream_status is used. This fixes 1 NULL_RETURNS issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49969", "url": "https://ubuntu.com/security/CVE-2024-49969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 color transformation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_hw_format` function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:180 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:181 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:182 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49970", "url": "https://ubuntu.com/security/CVE-2024-49970", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Implement bounds check for stream encoder creation in DCN401 'stream_enc_regs' array is an array of dcn10_stream_enc_registers structures. The array is initialized with four elements, corresponding to the four calls to stream_enc_regs() in the array initializer. This means that valid indices for this array are 0, 1, 2, and 3. The error message 'stream_enc_regs' 4 <= 5 below, is indicating that there is an attempt to access this array with an index of 5, which is out of bounds. This could lead to undefined behavior Here, eng_id is used as an index to access the stream_enc_regs array. If eng_id is 5, this would result in an out-of-bounds access on the stream_enc_regs array. Thus fixing Buffer overflow error in dcn401_stream_encoder_create Found by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn401/dcn401_resource.c:1209 dcn401_stream_encoder_create() error: buffer overflow 'stream_enc_regs' 4 <= 5", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49894", "url": "https://ubuntu.com/security/CVE-2024-49894", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in degamma hardware format translation Fixes index out of bounds issue in `cm_helper_translate_curve_to_degamma_hw_format` function. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49895", "url": "https://ubuntu.com/security/CVE-2024-49895", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format translation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_degamma_hw_format` function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:338 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:339 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:340 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49971", "url": "https://ubuntu.com/security/CVE-2024-49971", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Increase array size of dummy_boolean [WHY] dml2_core_shared_mode_support and dml_core_mode_support access the third element of dummy_boolean, i.e. hw_debug5 = &s->dummy_boolean[2], when dummy_boolean has size of 2. Any assignment to hw_debug5 causes an OVERRUN. [HOW] Increase dummy_boolean's array size to 3. This fixes 2 OVERRUN issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49972", "url": "https://ubuntu.com/security/CVE-2024-49972", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Deallocate DML memory if allocation fails [Why] When DC state create DML memory allocation fails, memory is not deallocated subsequently, resulting in uninitialized structure that is not NULL. [How] Deallocate memory if DML memory allocation fails.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49896", "url": "https://ubuntu.com/security/CVE-2024-49896", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check stream before comparing them [WHAT & HOW] amdgpu_dm can pass a null stream to dc_is_stream_unchanged. It is necessary to check for null before dereferencing them. This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49897", "url": "https://ubuntu.com/security/CVE-2024-49897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check phantom_stream before it is used dcn32_enable_phantom_stream can return null, so returned value must be checked before used. This fixes 1 NULL_RETURNS issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49898", "url": "https://ubuntu.com/security/CVE-2024-49898", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null-initialized variables [WHAT & HOW] drr_timing and subvp_pipe are initialized to null and they are not always assigned new values. It is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49899", "url": "https://ubuntu.com/security/CVE-2024-49899", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize denominators' default to 1 [WHAT & HOW] Variables used as denominators and maybe not assigned to other values, should not be 0. Change their default to 1 so they are never 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49900", "url": "https://ubuntu.com/security/CVE-2024-49900", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uninit-value access of new_ea in ea_buffer syzbot reports that lzo1x_1_do_compress is using uninit-value: ===================================================== BUG: KMSAN: uninit-value in lzo1x_1_do_compress+0x19f9/0x2510 lib/lzo/lzo1x_compress.c:178 ... Uninit was stored to memory at: ea_put fs/jfs/xattr.c:639 [inline] ... Local variable ea_buf created at: __jfs_setxattr+0x5d/0x1ae0 fs/jfs/xattr.c:662 __jfs_xattr_set+0xe6/0x1f0 fs/jfs/xattr.c:934 ===================================================== The reason is ea_buf->new_ea is not initialized properly. Fix this by using memset to empty its content at the beginning in ea_get().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49901", "url": "https://ubuntu.com/security/CVE-2024-49901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm/adreno: Assign msm_gpu->pdev earlier to avoid nullptrs There are some cases, such as the one uncovered by Commit 46d4efcccc68 (\"drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails\") where msm_gpu_cleanup() : platform_set_drvdata(gpu->pdev, NULL); is called on gpu->pdev == NULL, as the GPU device has not been fully initialized yet. Turns out that there's more than just the aforementioned path that causes this to happen (e.g. the case when there's speedbin data in the catalog, but opp-supported-hw is missing in DT). Assigning msm_gpu->pdev earlier seems like the least painful solution to this, therefore do so. Patchwork: https://patchwork.freedesktop.org/patch/602742/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49902", "url": "https://ubuntu.com/security/CVE-2024-49902", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: check if leafidx greater than num leaves per dmap tree syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf. Shaggy: Modified sanity check to apply to control pages as well as leaf pages.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49903", "url": "https://ubuntu.com/security/CVE-2024-49903", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uaf in dbFreeBits [syzbot reported] ================================================================== BUG: KASAN: slab-use-after-free in __mutex_lock_common kernel/locking/mutex.c:587 [inline] BUG: KASAN: slab-use-after-free in __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 Read of size 8 at addr ffff8880229254b0 by task syz-executor357/5216 CPU: 0 UID: 0 PID: 5216 Comm: syz-executor357 Not tainted 6.11.0-rc3-syzkaller-00156-gd7a5aa4b3c00 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 __mutex_lock_common kernel/locking/mutex.c:587 [inline] __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 dbFreeBits+0x7ea/0xd90 fs/jfs/jfs_dmap.c:2390 dbFreeDmap fs/jfs/jfs_dmap.c:2089 [inline] dbFree+0x35b/0x680 fs/jfs/jfs_dmap.c:409 dbDiscardAG+0x8a9/0xa20 fs/jfs/jfs_dmap.c:1650 jfs_ioc_trim+0x433/0x670 fs/jfs/jfs_discard.c:100 jfs_ioctl+0x2d0/0x3e0 fs/jfs/ioctl.c:131 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 Freed by task 5218: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object+0xe0/0x150 mm/kasan/common.c:240 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2252 [inline] slab_free mm/slub.c:4473 [inline] kfree+0x149/0x360 mm/slub.c:4594 dbUnmount+0x11d/0x190 fs/jfs/jfs_dmap.c:278 jfs_mount_rw+0x4ac/0x6a0 fs/jfs/jfs_mount.c:247 jfs_remount+0x3d1/0x6b0 fs/jfs/super.c:454 reconfigure_super+0x445/0x880 fs/super.c:1083 vfs_cmd_reconfigure fs/fsopen.c:263 [inline] vfs_fsconfig_locked fs/fsopen.c:292 [inline] __do_sys_fsconfig fs/fsopen.c:473 [inline] __se_sys_fsconfig+0xb6e/0xf80 fs/fsopen.c:345 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 [Analysis] There are two paths (dbUnmount and jfs_ioc_trim) that generate race condition when accessing bmap, which leads to the occurrence of uaf. Use the lock s_umount to synchronize them, in order to avoid uaf caused by race condition.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49904", "url": "https://ubuntu.com/security/CVE-2024-49904", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add list empty check to avoid null pointer issue Add list empty check to avoid null pointer issues in some corner cases. - list_for_each_entry_safe()", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49989", "url": "https://ubuntu.com/security/CVE-2024-49989", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix double free issue during amdgpu module unload Flexible endpoints use DIGs from available inflexible endpoints, so only the encoders of inflexible links need to be freed. Otherwise, a double free issue may occur when unloading the amdgpu module. [ 279.190523] RIP: 0010:__slab_free+0x152/0x2f0 [ 279.190577] Call Trace: [ 279.190580] [ 279.190582] ? show_regs+0x69/0x80 [ 279.190590] ? die+0x3b/0x90 [ 279.190595] ? do_trap+0xc8/0xe0 [ 279.190601] ? do_error_trap+0x73/0xa0 [ 279.190605] ? __slab_free+0x152/0x2f0 [ 279.190609] ? exc_invalid_op+0x56/0x70 [ 279.190616] ? __slab_free+0x152/0x2f0 [ 279.190642] ? asm_exc_invalid_op+0x1f/0x30 [ 279.190648] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191096] ? __slab_free+0x152/0x2f0 [ 279.191102] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191469] kfree+0x260/0x2b0 [ 279.191474] dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191821] link_destroy+0xd7/0x130 [amdgpu] [ 279.192248] dc_destruct+0x90/0x270 [amdgpu] [ 279.192666] dc_destroy+0x19/0x40 [amdgpu] [ 279.193020] amdgpu_dm_fini+0x16e/0x200 [amdgpu] [ 279.193432] dm_hw_fini+0x26/0x40 [amdgpu] [ 279.193795] amdgpu_device_fini_hw+0x24c/0x400 [amdgpu] [ 279.194108] amdgpu_driver_unload_kms+0x4f/0x70 [amdgpu] [ 279.194436] amdgpu_pci_remove+0x40/0x80 [amdgpu] [ 279.194632] pci_device_remove+0x3a/0xa0 [ 279.194638] device_remove+0x40/0x70 [ 279.194642] device_release_driver_internal+0x1ad/0x210 [ 279.194647] driver_detach+0x4e/0xa0 [ 279.194650] bus_remove_driver+0x6f/0xf0 [ 279.194653] driver_unregister+0x33/0x60 [ 279.194657] pci_unregister_driver+0x44/0x90 [ 279.194662] amdgpu_exit+0x19/0x1f0 [amdgpu] [ 279.194939] __do_sys_delete_module.isra.0+0x198/0x2f0 [ 279.194946] __x64_sys_delete_module+0x16/0x20 [ 279.194950] do_syscall_64+0x58/0x120 [ 279.194954] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 279.194980] ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49905", "url": "https://ubuntu.com/security/CVE-2024-49905", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for 'afb' in amdgpu_dm_plane_handle_cursor_update (v2) This commit adds a null check for the 'afb' variable in the amdgpu_dm_plane_handle_cursor_update function. Previously, 'afb' was assumed to be null, but was used later in the code without a null check. This could potentially lead to a null pointer dereference. Changes since v1: - Moved the null check for 'afb' to the line where 'afb' is used. (Alex) Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:1298 amdgpu_dm_plane_handle_cursor_update() error: we previously assumed 'afb' could be null (see line 1252)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49906", "url": "https://ubuntu.com/security/CVE-2024-49906", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before try to access it [why & how] Change the order of the pipe_ctx->plane_state check to ensure that plane_state is not null before accessing it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49907", "url": "https://ubuntu.com/security/CVE-2024-49907", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before using dc->clk_mgr [WHY & HOW] dc->clk_mgr is null checked previously in the same function, indicating it might be null. Passing \"dc\" to \"dc->hwss.apply_idle_power_optimizations\", which dereferences null \"dc->clk_mgr\". (The function pointer resolves to \"dcn35_apply_idle_power_optimizations\".) This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49908", "url": "https://ubuntu.com/security/CVE-2024-49908", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for 'afb' in amdgpu_dm_update_cursor (v2) This commit adds a null check for the 'afb' variable in the amdgpu_dm_update_cursor function. Previously, 'afb' was assumed to be null at line 8388, but was used later in the code without a null check. This could potentially lead to a null pointer dereference. Changes since v1: - Moved the null check for 'afb' to the line where 'afb' is used. (Alex) Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:8433 amdgpu_dm_update_cursor() \terror: we previously assumed 'afb' could be null (see line 8388)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50177", "url": "https://ubuntu.com/security/CVE-2024-50177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix a UBSAN warning in DML2.1 When programming phantom pipe, since cursor_width is explicity set to 0, this causes calculation logic to trigger overflow for an unsigned int triggering the kernel's UBSAN check as below: [ 40.962845] UBSAN: shift-out-of-bounds in /tmp/amd.EfpumTkO/amd/amdgpu/../display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c:3312:34 [ 40.962849] shift exponent 4294967170 is too large for 32-bit type 'unsigned int' [ 40.962852] CPU: 1 PID: 1670 Comm: gnome-shell Tainted: G W OE 6.5.0-41-generic #41~22.04.2-Ubuntu [ 40.962854] Hardware name: Gigabyte Technology Co., Ltd. X670E AORUS PRO X/X670E AORUS PRO X, BIOS F21 01/10/2024 [ 40.962856] Call Trace: [ 40.962857] [ 40.962860] dump_stack_lvl+0x48/0x70 [ 40.962870] dump_stack+0x10/0x20 [ 40.962872] __ubsan_handle_shift_out_of_bounds+0x1ac/0x360 [ 40.962878] calculate_cursor_req_attributes.cold+0x1b/0x28 [amdgpu] [ 40.963099] dml_core_mode_support+0x6b91/0x16bc0 [amdgpu] [ 40.963327] ? srso_alias_return_thunk+0x5/0x7f [ 40.963331] ? CalculateWatermarksMALLUseAndDRAMSpeedChangeSupport+0x18b8/0x2790 [amdgpu] [ 40.963534] ? srso_alias_return_thunk+0x5/0x7f [ 40.963536] ? dml_core_mode_support+0xb3db/0x16bc0 [amdgpu] [ 40.963730] dml2_core_calcs_mode_support_ex+0x2c/0x90 [amdgpu] [ 40.963906] ? srso_alias_return_thunk+0x5/0x7f [ 40.963909] ? dml2_core_calcs_mode_support_ex+0x2c/0x90 [amdgpu] [ 40.964078] core_dcn4_mode_support+0x72/0xbf0 [amdgpu] [ 40.964247] dml2_top_optimization_perform_optimization_phase+0x1d3/0x2a0 [amdgpu] [ 40.964420] dml2_build_mode_programming+0x23d/0x750 [amdgpu] [ 40.964587] dml21_validate+0x274/0x770 [amdgpu] [ 40.964761] ? srso_alias_return_thunk+0x5/0x7f [ 40.964763] ? resource_append_dpp_pipes_for_plane_composition+0x27c/0x3b0 [amdgpu] [ 40.964942] dml2_validate+0x504/0x750 [amdgpu] [ 40.965117] ? dml21_copy+0x95/0xb0 [amdgpu] [ 40.965291] ? srso_alias_return_thunk+0x5/0x7f [ 40.965295] dcn401_validate_bandwidth+0x4e/0x70 [amdgpu] [ 40.965491] update_planes_and_stream_state+0x38d/0x5c0 [amdgpu] [ 40.965672] update_planes_and_stream_v3+0x52/0x1e0 [amdgpu] [ 40.965845] ? srso_alias_return_thunk+0x5/0x7f [ 40.965849] dc_update_planes_and_stream+0x71/0xb0 [amdgpu] Fix this by adding a guard for checking cursor width before triggering the size calculation.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49909", "url": "https://ubuntu.com/security/CVE-2024-49909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn32_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn32_set_output_transfer_func function. Previously, set_output_gamma was being checked for null, but then it was being dereferenced without any null check. This could lead to a null pointer dereference if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49910", "url": "https://ubuntu.com/security/CVE-2024-49910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn401_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn401_set_output_transfer_func function. Previously, set_output_gamma was being checked for null, but then it was being dereferenced without any null check. This could lead to a null pointer dereference if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49911", "url": "https://ubuntu.com/security/CVE-2024-49911", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn20_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn20_set_output_transfer_func function. Previously, set_output_gamma was being checked for null at line 1030, but then it was being dereferenced without any null check at line 1048. This could potentially lead to a null pointer dereference error if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma at line 1048.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49912", "url": "https://ubuntu.com/security/CVE-2024-49912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Handle null 'stream_status' in 'planes_changed_for_existing_stream' This commit adds a null check for 'stream_status' in the function 'planes_changed_for_existing_stream'. Previously, the code assumed 'stream_status' could be null, but did not handle the case where it was actually null. This could lead to a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:3784 planes_changed_for_existing_stream() error: we previously assumed 'stream_status' could be null (see line 3774)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49913", "url": "https://ubuntu.com/security/CVE-2024-49913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for top_pipe_to_program in commit_planes_for_stream This commit addresses a null pointer dereference issue in the `commit_planes_for_stream` function at line 4140. The issue could occur when `top_pipe_to_program` is null. The fix adds a check to ensure `top_pipe_to_program` is not null before accessing its stream_res. This prevents a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:4140 commit_planes_for_stream() error: we previously assumed 'top_pipe_to_program' could be null (see line 3906)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49914", "url": "https://ubuntu.com/security/CVE-2024-49914", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for pipe_ctx->plane_state in dcn20_program_pipe This commit addresses a null pointer dereference issue in the `dcn20_program_pipe` function. The issue could occur when `pipe_ctx->plane_state` is null. The fix adds a check to ensure `pipe_ctx->plane_state` is not null before accessing. This prevents a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn20/dcn20_hwseq.c:1925 dcn20_program_pipe() error: we previously assumed 'pipe_ctx->plane_state' could be null (see line 1877)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49915", "url": "https://ubuntu.com/security/CVE-2024-49915", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr in dcn32_init_hw This commit addresses a potential null pointer dereference issue in the `dcn32_init_hw` function. The issue could occur when `dc->clk_mgr` is null. The fix adds a check to ensure `dc->clk_mgr` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn32/dcn32_hwseq.c:961 dcn32_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 782)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49916", "url": "https://ubuntu.com/security/CVE-2024-49916", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in dcn401_init_hw This commit addresses a potential null pointer dereference issue in the `dcn401_init_hw` function. The issue could occur when `dc->clk_mgr` or `dc->clk_mgr->funcs` is null. The fix adds a check to ensure `dc->clk_mgr` and `dc->clk_mgr->funcs` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn401/dcn401_hwseq.c:416 dcn401_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 225)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49917", "url": "https://ubuntu.com/security/CVE-2024-49917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in dcn30_init_hw This commit addresses a potential null pointer dereference issue in the `dcn30_init_hw` function. The issue could occur when `dc->clk_mgr` or `dc->clk_mgr->funcs` is null. The fix adds a check to ensure `dc->clk_mgr` and `dc->clk_mgr->funcs` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:789 dcn30_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 628)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49918", "url": "https://ubuntu.com/security/CVE-2024-49918", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for head_pipe in dcn32_acquire_idle_pipe_for_head_pipe_in_layer This commit addresses a potential null pointer dereference issue in the `dcn32_acquire_idle_pipe_for_head_pipe_in_layer` function. The issue could occur when `head_pipe` is null. The fix adds a check to ensure `head_pipe` is not null before asserting it. If `head_pipe` is null, the function returns NULL to prevent a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn32/dcn32_resource.c:2690 dcn32_acquire_idle_pipe_for_head_pipe_in_layer() error: we previously assumed 'head_pipe' could be null (see line 2681)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49919", "url": "https://ubuntu.com/security/CVE-2024-49919", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for head_pipe in dcn201_acquire_free_pipe_for_layer This commit addresses a potential null pointer dereference issue in the `dcn201_acquire_free_pipe_for_layer` function. The issue could occur when `head_pipe` is null. The fix adds a check to ensure `head_pipe` is not null before asserting it. If `head_pipe` is null, the function returns NULL to prevent a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn201/dcn201_resource.c:1016 dcn201_acquire_free_pipe_for_layer() error: we previously assumed 'head_pipe' could be null (see line 1010)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49991", "url": "https://ubuntu.com/security/CVE-2024-49991", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer Pass pointer reference to amdgpu_bo_unref to clear the correct pointer, otherwise amdgpu_bo_unref clear the local variable, the original pointer not set to NULL, this could cause use-after-free bug.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49920", "url": "https://ubuntu.com/security/CVE-2024-49920", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before multiple uses [WHAT & HOW] Poniters, such as stream_enc and dc->bw_vbios, are null checked previously in the same function, so Coverity warns \"implies that stream_enc and dc->bw_vbios might be null\". They are used multiple times in the subsequent code and need to be checked. This fixes 10 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49921", "url": "https://ubuntu.com/security/CVE-2024-49921", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before used [WHAT & HOW] Poniters, such as dc->clk_mgr, are null checked previously in the same function, so Coverity warns \"implies that \"dc->clk_mgr\" might be null\". As a result, these pointers need to be checked when used again. This fixes 10 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49922", "url": "https://ubuntu.com/security/CVE-2024-49922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before using them [WHAT & HOW] These pointers are null checked previously in the same function, indicating they might be null as reported by Coverity. As a result, they need to be checked when used again. This fixes 3 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49923", "url": "https://ubuntu.com/security/CVE-2024-49923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Pass non-null to dcn20_validate_apply_pipe_split_flags [WHAT & HOW] \"dcn20_validate_apply_pipe_split_flags\" dereferences merge, and thus it cannot be a null pointer. Let's pass a valid pointer to avoid null dereference. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49992", "url": "https://ubuntu.com/security/CVE-2024-49992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/stm: Avoid use-after-free issues with crtc and plane ltdc_load() calls functions drm_crtc_init_with_planes(), drm_universal_plane_init() and drm_encoder_init(). These functions should not be called with parameters allocated with devm_kzalloc() to avoid use-after-free issues [1]. Use allocations managed by the DRM framework. Found by Linux Verification Center (linuxtesting.org). [1] https://lore.kernel.org/lkml/u366i76e3qhh3ra5oxrtngjtm2u5lterkekcz6y2jkndhuxzli@diujon4h7qwb/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49993", "url": "https://ubuntu.com/security/CVE-2024-49993", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49924", "url": "https://ubuntu.com/security/CVE-2024-49924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: pxafb: Fix possible use after free in pxafb_task() In the pxafb_probe function, it calls the pxafb_init_fbinfo function, after which &fbi->task is associated with pxafb_task. Moreover, within this pxafb_init_fbinfo function, the pxafb_blank function within the &pxafb_ops struct is capable of scheduling work. If we remove the module which will call pxafb_remove to make cleanup, it will call unregister_framebuffer function which can call do_unregister_framebuffer to free fbi->fb through put_fb_info(fb_info), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | pxafb_task pxafb_remove | unregister_framebuffer(info) | do_unregister_framebuffer(fb_info) | put_fb_info(fb_info) | // free fbi->fb | set_ctrlr_state(fbi, state) | __pxafb_lcd_power(fbi, 0) | fbi->lcd_power(on, &fbi->fb.var) | //use fbi->fb Fix it by ensuring that the work is canceled before proceeding with the cleanup in pxafb_remove. Note that only root user can remove the driver at runtime.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49925", "url": "https://ubuntu.com/security/CVE-2024-49925", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: efifb: Register sysfs groups through driver core The driver core can register and cleanup sysfs groups already. Make use of that functionality to simplify the error handling and cleanup. Also avoid a UAF race during unregistering where the sysctl attributes were usable after the info struct was freed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49926", "url": "https://ubuntu.com/security/CVE-2024-49926", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rcu-tasks: Fix access non-existent percpu rtpcp variable in rcu_tasks_need_gpcb() For kernels built with CONFIG_FORCE_NR_CPUS=y, the nr_cpu_ids is defined as NR_CPUS instead of the number of possible cpus, this will cause the following system panic: smpboot: Allowing 4 CPUs, 0 hotplug CPUs ... setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:512 nr_node_ids:1 ... BUG: unable to handle page fault for address: ffffffff9911c8c8 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 15 Comm: rcu_tasks_trace Tainted: G W 6.6.21 #1 5dc7acf91a5e8e9ac9dcfc35bee0245691283ea6 RIP: 0010:rcu_tasks_need_gpcb+0x25d/0x2c0 RSP: 0018:ffffa371c00a3e60 EFLAGS: 00010082 CR2: ffffffff9911c8c8 CR3: 000000040fa20005 CR4: 00000000001706f0 Call Trace: ? __die+0x23/0x80 ? page_fault_oops+0xa4/0x180 ? exc_page_fault+0x152/0x180 ? asm_exc_page_fault+0x26/0x40 ? rcu_tasks_need_gpcb+0x25d/0x2c0 ? __pfx_rcu_tasks_kthread+0x40/0x40 rcu_tasks_one_gp+0x69/0x180 rcu_tasks_kthread+0x94/0xc0 kthread+0xe8/0x140 ? __pfx_kthread+0x40/0x40 ret_from_fork+0x34/0x80 ? __pfx_kthread+0x40/0x40 ret_from_fork_asm+0x1b/0x80 Considering that there may be holes in the CPU numbers, use the maximum possible cpu number, instead of nr_cpu_ids, for configuring enqueue and dequeue limits. [ neeraj.upadhyay: Fix htmldocs build error reported by Stephen Rothwell ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50007", "url": "https://ubuntu.com/security/CVE-2024-50007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: asihpi: Fix potential OOB array access ASIHPI driver stores some values in the static array upon a response from the driver, and its index depends on the firmware. We shouldn't trust it blindly. This patch adds a sanity check of the array index to fit in the array size.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50017", "url": "https://ubuntu.com/security/CVE-2024-50017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm/ident_map: Use gbpages only where full GB page should be mapped. When ident_pud_init() uses only GB pages to create identity maps, large ranges of addresses not actually requested can be included in the resulting table; a 4K request will map a full GB. This can include a lot of extra address space past that requested, including areas marked reserved by the BIOS. That allows processor speculation into reserved regions, that on UV systems can cause system halts. Only use GB pages when map creation requests include the full GB page of space. Fall back to using smaller 2M pages when only portions of a GB page are included in the request. No attempt is made to coalesce mapping requests. If a request requires a map entry at the 2M (pmd) level, subsequent mapping requests within the same 1G region will also be at the pmd level, even if adjacent or overlapping such requests could have been combined to map a full GB page. Existing usage starts with larger regions and then adds smaller regions, so this should not have any great consequence.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49927", "url": "https://ubuntu.com/security/CVE-2024-49927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/ioapic: Handle allocation failures gracefully Breno observed panics when using failslab under certain conditions during runtime: can not alloc irq_pin_list (-1,0,20) Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed panic+0x4e9/0x590 mp_irqdomain_alloc+0x9ab/0xa80 irq_domain_alloc_irqs_locked+0x25d/0x8d0 __irq_domain_alloc_irqs+0x80/0x110 mp_map_pin_to_irq+0x645/0x890 acpi_register_gsi_ioapic+0xe6/0x150 hpet_open+0x313/0x480 That's a pointless panic which is a leftover of the historic IO/APIC code which panic'ed during early boot when the interrupt allocation failed. The only place which might justify panic is the PIT/HPET timer_check() code which tries to figure out whether the timer interrupt is delivered through the IO/APIC. But that code does not require to handle interrupt allocation failures. If the interrupt cannot be allocated then timer delivery fails and it either panics due to that or falls back to legacy mode. Cure this by removing the panic wrapper around __add_pin_to_irq_node() and making mp_irqdomain_alloc() aware of the failure condition and handle it as any other failure in this function gracefully.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50008", "url": "https://ubuntu.com/security/CVE-2024-50008", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_cmd_802_11_scan_ext() Replace one-element array with a flexible-array member in `struct host_cmd_ds_802_11_scan_ext`. With this, fix the following warning: elo 16 17:51:58 surfacebook kernel: ------------[ cut here ]------------ elo 16 17:51:58 surfacebook kernel: memcpy: detected field-spanning write (size 243) of single field \"ext_scan->tlv_buffer\" at drivers/net/wireless/marvell/mwifiex/scan.c:2239 (size 1) elo 16 17:51:58 surfacebook kernel: WARNING: CPU: 0 PID: 498 at drivers/net/wireless/marvell/mwifiex/scan.c:2239 mwifiex_cmd_802_11_scan_ext+0x83/0x90 [mwifiex]", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50018", "url": "https://ubuntu.com/security/CVE-2024-50018", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49928", "url": "https://ubuntu.com/security/CVE-2024-49928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: avoid reading out of bounds when loading TX power FW elements Because the loop-expression will do one more time before getting false from cond-expression, the original code copied one more entry size beyond valid region. Fix it by moving the entry copy to loop-body.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50178", "url": "https://ubuntu.com/security/CVE-2024-50178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: loongson3: Use raw_smp_processor_id() in do_service_request() Use raw_smp_processor_id() instead of plain smp_processor_id() in do_service_request(), otherwise we may get some errors with the driver enabled: BUG: using smp_processor_id() in preemptible [00000000] code: (udev-worker)/208 caller is loongson3_cpufreq_probe+0x5c/0x250 [loongson3_cpufreq]", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50009", "url": "https://ubuntu.com/security/CVE-2024-50009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: amd-pstate: add check for cpufreq_cpu_get's return value cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it and return in case of error. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49994", "url": "https://ubuntu.com/security/CVE-2024-49994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix integer overflow in BLKSECDISCARD I independently rediscovered \tcommit 22d24a544b0d49bbcbd61c8c0eaf77d3c9297155 \tblock: fix overflow in blk_ioctl_discard() but for secure erase. Same problem: \tuint64_t r[2] = {512, 18446744073709551104ULL}; \tioctl(fd, BLKSECDISCARD, r); will enter near infinite loop inside blkdev_issue_secure_erase(): \ta.out: attempt to access beyond end of device \tloop0: rw=5, sector=3399043073, nr_sectors = 1024 limit=2048 \tbio_check_eod: 3286214 callbacks suppressed", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49929", "url": "https://ubuntu.com/security/CVE-2024-49929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: avoid NULL pointer dereference iwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta pointer is not NULL. It retrieves this pointer using iwl_mvm_sta_from_mac80211, which is dereferencing the ieee80211_sta pointer. If sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL pointer. Fix this by checking the sta pointer before retrieving the mvmsta from it. If sta is not NULL, then mvmsta isn't either.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49995", "url": "https://ubuntu.com/security/CVE-2024-49995", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: guard against string buffer overrun Smatch reports that copying media_name and if_name to name_parts may overwrite the destination. .../bearer.c:166 bearer_name_validate() error: strcpy() 'media_name' too large for 'name_parts->media_name' (32 vs 16) .../bearer.c:167 bearer_name_validate() error: strcpy() 'if_name' too large for 'name_parts->if_name' (1010102 vs 16) This does seem to be the case so guard against this possibility by using strscpy() and failing if truncation occurs. Introduced by commit b97bf3fd8f6a (\"[TIPC] Initial merge\") Compile tested only.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49962", "url": "https://ubuntu.com/security/CVE-2024-49962", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in acpi_db_convert_to_package() ACPICA commit 4d4547cf13cca820ff7e0f859ba83e1a610b9fd0 ACPI_ALLOCATE_ZEROED() may fail, elements might be NULL and will cause NULL pointer dereference later. [ rjw: Subject and changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49930", "url": "https://ubuntu.com/security/CVE-2024-49930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix array out-of-bound access in SoC stats Currently, the ath11k_soc_dp_stats::hal_reo_error array is defined with a maximum size of DP_REO_DST_RING_MAX. However, the ath11k_dp_process_rx() function access ath11k_soc_dp_stats::hal_reo_error using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath11k_dp_process_rx() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49931", "url": "https://ubuntu.com/security/CVE-2024-49931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix array out-of-bound access in SoC stats Currently, the ath12k_soc_dp_stats::hal_reo_error array is defined with a maximum size of DP_REO_DST_RING_MAX. However, the ath12k_dp_rx_process() function access ath12k_soc_dp_stats::hal_reo_error using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath12k_dp_rx_process() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49932", "url": "https://ubuntu.com/security/CVE-2024-49932", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: don't readahead the relocation inode on RST On relocation we're doing readahead on the relocation inode, but if the filesystem is backed by a RAID stripe tree we can get ENOENT (e.g. due to preallocated extents not being mapped in the RST) from the lookup. But readahead doesn't handle the error and submits invalid reads to the device, causing an assertion in the scatter-gather list code: BTRFS info (device nvme1n1): balance: start -d -m -s BTRFS info (device nvme1n1): relocating block group 6480920576 flags data|raid0 BTRFS error (device nvme1n1): cannot find raid-stripe for logical [6481928192, 6481969152] devid 2, profile raid0 ------------[ cut here ]------------ kernel BUG at include/linux/scatterlist.h:115! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 1012 Comm: btrfs Not tainted 6.10.0-rc7+ #567 RIP: 0010:__blk_rq_map_sg+0x339/0x4a0 RSP: 0018:ffffc90001a43820 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffea00045d4802 RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000 RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000001000 R12: ffff8881003d10b8 R13: ffffc90001a438f0 R14: 0000000000000000 R15: 0000000000003000 FS: 00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000002cd11000 CR3: 00000001109ea001 CR4: 0000000000370eb0 Call Trace: ? __die_body.cold+0x14/0x25 ? die+0x2e/0x50 ? do_trap+0xca/0x110 ? do_error_trap+0x65/0x80 ? __blk_rq_map_sg+0x339/0x4a0 ? exc_invalid_op+0x50/0x70 ? __blk_rq_map_sg+0x339/0x4a0 ? asm_exc_invalid_op+0x1a/0x20 ? __blk_rq_map_sg+0x339/0x4a0 nvme_prep_rq.part.0+0x9d/0x770 nvme_queue_rq+0x7d/0x1e0 __blk_mq_issue_directly+0x2a/0x90 ? blk_mq_get_budget_and_tag+0x61/0x90 blk_mq_try_issue_list_directly+0x56/0xf0 blk_mq_flush_plug_list.part.0+0x52b/0x5d0 __blk_flush_plug+0xc6/0x110 blk_finish_plug+0x28/0x40 read_pages+0x160/0x1c0 page_cache_ra_unbounded+0x109/0x180 relocate_file_extent_cluster+0x611/0x6a0 ? btrfs_search_slot+0xba4/0xd20 ? balance_dirty_pages_ratelimited_flags+0x26/0xb00 relocate_data_extent.constprop.0+0x134/0x160 relocate_block_group+0x3f2/0x500 btrfs_relocate_block_group+0x250/0x430 btrfs_relocate_chunk+0x3f/0x130 btrfs_balance+0x71b/0xef0 ? kmalloc_trace_noprof+0x13b/0x280 btrfs_ioctl+0x2c2e/0x3030 ? kvfree_call_rcu+0x1e6/0x340 ? list_lru_add_obj+0x66/0x80 ? mntput_no_expire+0x3a/0x220 __x64_sys_ioctl+0x96/0xc0 do_syscall_64+0x54/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fcc04514f9b Code: Unable to access opcode bytes at 0x7fcc04514f71. RSP: 002b:00007ffeba923370 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fcc04514f9b RDX: 00007ffeba923460 RSI: 00000000c4009420 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000013 R09: 0000000000000001 R10: 00007fcc043fbba8 R11: 0000000000000246 R12: 00007ffeba924fc5 R13: 00007ffeba923460 R14: 0000000000000002 R15: 00000000004d4bb0 Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:__blk_rq_map_sg+0x339/0x4a0 RSP: 0018:ffffc90001a43820 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffea00045d4802 RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000 RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000001000 R12: ffff8881003d10b8 R13: ffffc90001a438f0 R14: 0000000000000000 R15: 0000000000003000 FS: 00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcc04514f71 CR3: 00000001109ea001 CR4: 0000000000370eb0 Kernel p ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49933", "url": "https://ubuntu.com/security/CVE-2024-49933", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk_iocost: fix more out of bound shifts Recently running UBSAN caught few out of bound shifts in the ioc_forgive_debts() function: UBSAN: shift-out-of-bounds in block/blk-iocost.c:2142:38 shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long long') ... UBSAN: shift-out-of-bounds in block/blk-iocost.c:2144:30 shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long long') ... Call Trace: dump_stack_lvl+0xca/0x130 __ubsan_handle_shift_out_of_bounds+0x22c/0x280 ? __lock_acquire+0x6441/0x7c10 ioc_timer_fn+0x6cec/0x7750 ? blk_iocost_init+0x720/0x720 ? call_timer_fn+0x5d/0x470 call_timer_fn+0xfa/0x470 ? blk_iocost_init+0x720/0x720 __run_timer_base+0x519/0x700 ... Actual impact of this issue was not identified but I propose to fix the undefined behaviour. The proposed fix to prevent those out of bound shifts consist of precalculating exponent before using it the shift operations by taking min value from the actual exponent and maximum possible number of bits.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49934", "url": "https://ubuntu.com/security/CVE-2024-49934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/inode: Prevent dump_mapping() accessing invalid dentry.d_name.name It's observed that a crash occurs during hot-remove a memory device, in which user is accessing the hugetlb. See calltrace as following: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 14045 at arch/x86/mm/fault.c:1278 do_user_addr_fault+0x2a0/0x790 Modules linked in: kmem device_dax cxl_mem cxl_pmem cxl_port cxl_pci dax_hmem dax_pmem nd_pmem cxl_acpi nd_btt cxl_core crc32c_intel nvme virtiofs fuse nvme_core nfit libnvdimm dm_multipath scsi_dh_rdac scsi_dh_emc s mirror dm_region_hash dm_log dm_mod CPU: 1 PID: 14045 Comm: daxctl Not tainted 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:do_user_addr_fault+0x2a0/0x790 Code: 48 8b 00 a8 04 0f 84 b5 fe ff ff e9 1c ff ff ff 4c 89 e9 4c 89 e2 be 01 00 00 00 bf 02 00 00 00 e8 b5 ef 24 00 e9 42 fe ff ff <0f> 0b 48 83 c4 08 4c 89 ea 48 89 ee 4c 89 e7 5b 5d 41 5c 41 5d 41 RSP: 0000:ffffc90000a575f0 EFLAGS: 00010046 RAX: ffff88800c303600 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000001000 RSI: ffffffff82504162 RDI: ffffffff824b2c36 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffc90000a57658 R13: 0000000000001000 R14: ffff88800bc2e040 R15: 0000000000000000 FS: 00007f51cb57d880(0000) GS:ffff88807fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000001000 CR3: 00000000072e2004 CR4: 00000000001706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn+0x8d/0x190 ? do_user_addr_fault+0x2a0/0x790 ? report_bug+0x1c3/0x1d0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? do_user_addr_fault+0x2a0/0x790 ? exc_page_fault+0x31/0x200 exc_page_fault+0x68/0x200 <...snip...> BUG: unable to handle page fault for address: 0000000000001000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI ---[ end trace 0000000000000000 ]--- BUG: unable to handle page fault for address: 0000000000001000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 14045 Comm: daxctl Kdump: loaded Tainted: G W 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:dentry_name+0x1f4/0x440 <...snip...> ? dentry_name+0x2fa/0x440 vsnprintf+0x1f3/0x4f0 vprintk_store+0x23a/0x540 vprintk_emit+0x6d/0x330 _printk+0x58/0x80 dump_mapping+0x10b/0x1a0 ? __pfx_free_object_rcu+0x10/0x10 __dump_page+0x26b/0x3e0 ? vprintk_emit+0xe0/0x330 ? _printk+0x58/0x80 ? dump_page+0x17/0x50 dump_page+0x17/0x50 do_migrate_range+0x2f7/0x7f0 ? do_migrate_range+0x42/0x7f0 ? offline_pages+0x2f4/0x8c0 offline_pages+0x60a/0x8c0 memory_subsys_offline+0x9f/0x1c0 ? lockdep_hardirqs_on+0x77/0x100 ? _raw_spin_unlock_irqrestore+0x38/0x60 device_offline+0xe3/0x110 state_store+0x6e/0xc0 kernfs_fop_write_iter+0x143/0x200 vfs_write+0x39f/0x560 ksys_write+0x65/0xf0 do_syscall_64+0x62/0x130 Previously, some sanity check have been done in dump_mapping() before the print facility parsing '%pd' though, it's still possible to run into an invalid dentry.d_name.name. Since dump_mapping() only needs to dump the filename only, retrieve it by itself in a safer way to prevent an unnecessary crash. Note that either retrieving the filename with '%pd' or strncpy_from_kernel_nofault(), the filename could be unreliable.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49935", "url": "https://ubuntu.com/security/CVE-2024-49935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: PAD: fix crash in exit_round_robin() The kernel occasionally crashes in cpumask_clear_cpu(), which is called within exit_round_robin(), because when executing clear_bit(nr, addr) with nr set to 0xffffffff, the address calculation may cause misalignment within the memory, leading to access to an invalid memory address. ---------- BUG: unable to handle kernel paging request at ffffffffe0740618 ... CPU: 3 PID: 2919323 Comm: acpi_pad/14 Kdump: loaded Tainted: G OE X --------- - - 4.18.0-425.19.2.el8_7.x86_64 #1 ... RIP: 0010:power_saving_thread+0x313/0x411 [acpi_pad] Code: 89 cd 48 89 d3 eb d1 48 c7 c7 55 70 72 c0 e8 64 86 b0 e4 c6 05 0d a1 02 00 01 e9 bc fd ff ff 45 89 e4 42 8b 04 a5 20 82 72 c0 48 0f b3 05 f4 9c 01 00 42 c7 04 a5 20 82 72 c0 ff ff ff ff 31 RSP: 0018:ff72a5d51fa77ec8 EFLAGS: 00010202 RAX: 00000000ffffffff RBX: ff462981e5d8cb80 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246 RBP: ff46297556959d80 R08: 0000000000000382 R09: ff46297c8d0f38d8 R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000000e R13: 0000000000000000 R14: ffffffffffffffff R15: 000000000000000e FS: 0000000000000000(0000) GS:ff46297a800c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffe0740618 CR3: 0000007e20410004 CR4: 0000000000771ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? acpi_pad_add+0x120/0x120 [acpi_pad] kthread+0x10b/0x130 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x1f/0x40 ... CR2: ffffffffe0740618 crash> dis -lr ffffffffc0726923 ... /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 114 0xffffffffc0726918 :\tmov %r12d,%r12d /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 325 0xffffffffc072691b :\tmov -0x3f8d7de0(,%r12,4),%eax /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./arch/x86/include/asm/bitops.h: 80 0xffffffffc0726923 :\tlock btr %rax,0x19cf4(%rip) # 0xffffffffc0740620 crash> px tsk_in_cpu[14] $66 = 0xffffffff crash> px 0xffffffffc072692c+0x19cf4 $99 = 0xffffffffc0740620 crash> sym 0xffffffffc0740620 ffffffffc0740620 (b) pad_busy_cpus_bits [acpi_pad] crash> px pad_busy_cpus_bits[0] $42 = 0xfffc0 ---------- To fix this, ensure that tsk_in_cpu[tsk_index] != -1 before calling cpumask_clear_cpu() in exit_round_robin(), just as it is done in round_robin_cpu(). [ rjw: Subject edit, avoid updates to the same value ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49936", "url": "https://ubuntu.com/security/CVE-2024-49936", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/xen-netback: prevent UAF in xenvif_flush_hash() During the list_for_each_entry_rcu iteration call of xenvif_flush_hash, kfree_rcu does not exist inside the rcu read critical section, so if kfree_rcu is called when the rcu grace period ends during the iteration, UAF occurs when accessing head->next after the entry becomes free. Therefore, to solve this, you need to change it to list_for_each_entry_safe.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49937", "url": "https://ubuntu.com/security/CVE-2024-49937", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Set correct chandef when starting CAC When starting CAC in a mode other than AP mode, it return a \"WARNING: CPU: 0 PID: 63 at cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]\" caused by the chandef.chan being null at the end of CAC. Solution: Ensure the channel definition is set for the different modes when starting CAC to avoid getting a NULL 'chan' at the end of CAC. Call Trace: ? show_regs.part.0+0x14/0x16 ? __warn+0x67/0xc0 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? report_bug+0xa7/0x130 ? exc_overflow+0x30/0x30 ? handle_bug+0x27/0x50 ? exc_invalid_op+0x18/0x60 ? handle_exception+0xf6/0xf6 ? exc_overflow+0x30/0x30 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? exc_overflow+0x30/0x30 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? regulatory_propagate_dfs_state.cold+0x1b/0x4c [cfg80211] ? cfg80211_propagate_cac_done_wk+0x1a/0x30 [cfg80211] ? process_one_work+0x165/0x280 ? worker_thread+0x120/0x3f0 ? kthread+0xc2/0xf0 ? process_one_work+0x280/0x280 ? kthread_complete_and_exit+0x20/0x20 ? ret_from_fork+0x19/0x24 [shorten subject, remove OCB, reorder cases to match previous list]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49938", "url": "https://ubuntu.com/security/CVE-2024-49938", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmit Syzbot points out that skb_trim() has a sanity check on the existing length of the skb, which can be uninitialised in some error paths. The intent here is clearly just to reset the length to zero before resubmitting, so switch to calling __skb_set_length(skb, 0) directly. In addition, __skb_set_length() already contains a call to skb_reset_tail_pointer(), so remove the redundant call. The syzbot report came from ath9k_hif_usb_reg_in_cb(), but there's a similar usage of skb_trim() in ath9k_hif_usb_rx_cb(), change both while we're at it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49939", "url": "https://ubuntu.com/security/CVE-2024-49939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: avoid to add interface to list twice when SER If SER L2 occurs during the WoWLAN resume flow, the add interface flow is triggered by ieee80211_reconfig(). However, due to rtw89_wow_resume() return failure, it will cause the add interface flow to be executed again, resulting in a double add list and causing a kernel panic. Therefore, we have added a check to prevent double adding of the list. list_add double add: new=ffff99d6992e2010, prev=ffff99d6992e2010, next=ffff99d695302628. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:37! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G W O 6.6.30-02659-gc18865c4dfbd #1 770df2933251a0e3c888ba69d1053a817a6376a7 Hardware name: HP Grunt/Grunt, BIOS Google_Grunt.11031.169.0 06/24/2021 Workqueue: events_freezable ieee80211_restart_work [mac80211] RIP: 0010:__list_add_valid_or_report+0x5e/0xb0 Code: c7 74 18 48 39 ce 74 13 b0 01 59 5a 5e 5f 41 58 41 59 41 5a 5d e9 e2 d6 03 00 cc 48 c7 c7 8d 4f 17 83 48 89 c2 e8 02 c0 00 00 <0f> 0b 48 c7 c7 aa 8c 1c 83 e8 f4 bf 00 00 0f 0b 48 c7 c7 c8 bc 12 RSP: 0018:ffffa91b8007bc50 EFLAGS: 00010246 RAX: 0000000000000058 RBX: ffff99d6992e0900 RCX: a014d76c70ef3900 RDX: ffffa91b8007bae8 RSI: 00000000ffffdfff RDI: 0000000000000001 RBP: ffffa91b8007bc88 R08: 0000000000000000 R09: ffffa91b8007bae0 R10: 00000000ffffdfff R11: ffffffff83a79800 R12: ffff99d695302060 R13: ffff99d695300900 R14: ffff99d6992e1be0 R15: ffff99d6992e2010 FS: 0000000000000000(0000) GS:ffff99d6aac00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000078fbdba43480 CR3: 000000010e464000 CR4: 00000000001506f0 Call Trace: ? __die_body+0x1f/0x70 ? die+0x3d/0x60 ? do_trap+0xa4/0x110 ? __list_add_valid_or_report+0x5e/0xb0 ? do_error_trap+0x6d/0x90 ? __list_add_valid_or_report+0x5e/0xb0 ? handle_invalid_op+0x30/0x40 ? __list_add_valid_or_report+0x5e/0xb0 ? exc_invalid_op+0x3c/0x50 ? asm_exc_invalid_op+0x16/0x20 ? __list_add_valid_or_report+0x5e/0xb0 rtw89_ops_add_interface+0x309/0x310 [rtw89_core 7c32b1ee6854761c0321027c8a58c5160e41f48f] drv_add_interface+0x5c/0x130 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ieee80211_reconfig+0x241/0x13d0 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ? finish_wait+0x3e/0x90 ? synchronize_rcu_expedited+0x174/0x260 ? sync_rcu_exp_done_unlocked+0x50/0x50 ? wake_bit_function+0x40/0x40 ieee80211_restart_work+0xf0/0x140 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] process_scheduled_works+0x1e5/0x480 worker_thread+0xea/0x1e0 kthread+0xdb/0x110 ? move_linked_works+0x90/0x90 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork+0x3b/0x50 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork_asm+0x11/0x20 Modules linked in: dm_integrity async_xor xor async_tx lz4 lz4_compress zstd zstd_compress zram zsmalloc rfcomm cmac uinput algif_hash algif_skcipher af_alg btusb btrtl iio_trig_hrtimer industrialio_sw_trigger btmtk industrialio_configfs btbcm btintel uvcvideo videobuf2_vmalloc iio_trig_sysfs videobuf2_memops videobuf2_v4l2 videobuf2_common uvc snd_hda_codec_hdmi veth snd_hda_intel snd_intel_dspcfg acpi_als snd_hda_codec industrialio_triggered_buffer kfifo_buf snd_hwdep industrialio i2c_piix4 snd_hda_core designware_i2s ip6table_nat snd_soc_max98357a xt_MASQUERADE xt_cgroup snd_soc_acp_rt5682_mach fuse rtw89_8922ae(O) rtw89_8922a(O) rtw89_pci(O) rtw89_core(O) 8021q mac80211(O) bluetooth ecdh_generic ecc cfg80211 r8152 mii joydev gsmi: Log Shutdown Reason 0x03 ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49940", "url": "https://ubuntu.com/security/CVE-2024-49940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: prevent possible tunnel refcount underflow When a session is created, it sets a backpointer to its tunnel. When the session refcount drops to 0, l2tp_session_free drops the tunnel refcount if session->tunnel is non-NULL. However, session->tunnel is set in l2tp_session_create, before the tunnel refcount is incremented by l2tp_session_register, which leaves a small window where session->tunnel is non-NULL when the tunnel refcount hasn't been bumped. Moving the assignment to l2tp_session_register is trivial but l2tp_session_create calls l2tp_session_set_header_len which uses session->tunnel to get the tunnel's encap. Add an encap arg to l2tp_session_set_header_len to avoid using session->tunnel. If l2tpv3 sessions have colliding IDs, it is possible for l2tp_v3_session_get to race with l2tp_session_register and fetch a session which doesn't yet have session->tunnel set. Add a check for this case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49941", "url": "https://ubuntu.com/security/CVE-2024-49941", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpiolib: Fix potential NULL pointer dereference in gpiod_get_label() In `gpiod_get_label()`, it is possible that `srcu_dereference_check()` may return a NULL pointer, leading to a scenario where `label->str` is accessed without verifying if `label` itself is NULL. This patch adds a proper NULL check for `label` before accessing `label->str`. The check for `label->str != NULL` is removed because `label->str` can never be NULL if `label` is not NULL. This fixes the issue where the label name was being printed as `(efault)` when dumping the sysfs GPIO file when `label == NULL`.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49996", "url": "https://ubuntu.com/security/CVE-2024-49996", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: Fix buffer overflow when parsing NFS reparse points ReparseDataLength is sum of the InodeType size and DataBuffer size. So to get DataBuffer size it is needed to subtract InodeType's size from ReparseDataLength. Function cifs_strndup_from_utf16() is currentlly accessing buf->DataBuffer at position after the end of the buffer because it does not subtract InodeType size from the length. Fix this problem and correctly subtract variable len. Member InodeType is present only when reparse buffer is large enough. Check for ReparseDataLength before accessing InodeType to prevent another invalid memory access. Major and minor rdev values are present also only when reparse buffer is large enough. Check for reparse buffer size before calling reparse_mkdev().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49942", "url": "https://ubuntu.com/security/CVE-2024-49942", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Prevent null pointer access in xe_migrate_copy xe_migrate_copy designed to copy content of TTM resources. When source resource is null, it will trigger a NULL pointer dereference in xe_migrate_copy. To avoid this situation, update lacks source flag to true for this case, the flag will trigger xe_migrate_clear rather than xe_migrate_copy. Issue trace: <7> [317.089847] xe 0000:00:02.0: [drm:xe_migrate_copy [xe]] Pass 14, sizes: 4194304 & 4194304 <7> [317.089945] xe 0000:00:02.0: [drm:xe_migrate_copy [xe]] Pass 15, sizes: 4194304 & 4194304 <1> [317.128055] BUG: kernel NULL pointer dereference, address: 0000000000000010 <1> [317.128064] #PF: supervisor read access in kernel mode <1> [317.128066] #PF: error_code(0x0000) - not-present page <6> [317.128069] PGD 0 P4D 0 <4> [317.128071] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI <4> [317.128074] CPU: 1 UID: 0 PID: 1440 Comm: kunit_try_catch Tainted: G U N 6.11.0-rc7-xe #1 <4> [317.128078] Tainted: [U]=USER, [N]=TEST <4> [317.128080] Hardware name: Intel Corporation Lunar Lake Client Platform/LNL-M LP5 RVP1, BIOS LNLMFWI1.R00.3221.D80.2407291239 07/29/2024 <4> [317.128082] RIP: 0010:xe_migrate_copy+0x66/0x13e0 [xe] <4> [317.128158] Code: 00 00 48 89 8d e0 fe ff ff 48 8b 40 10 4c 89 85 c8 fe ff ff 44 88 8d bd fe ff ff 65 48 8b 3c 25 28 00 00 00 48 89 7d d0 31 ff <8b> 79 10 48 89 85 a0 fe ff ff 48 8b 00 48 89 b5 d8 fe ff ff 83 ff <4> [317.128162] RSP: 0018:ffffc9000167f9f0 EFLAGS: 00010246 <4> [317.128164] RAX: ffff8881120d8028 RBX: ffff88814d070428 RCX: 0000000000000000 <4> [317.128166] RDX: ffff88813cb99c00 RSI: 0000000004000000 RDI: 0000000000000000 <4> [317.128168] RBP: ffffc9000167fbb8 R08: ffff88814e7b1f08 R09: 0000000000000001 <4> [317.128170] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88814e7b1f08 <4> [317.128172] R13: ffff88814e7b1f08 R14: ffff88813cb99c00 R15: 0000000000000001 <4> [317.128174] FS: 0000000000000000(0000) GS:ffff88846f280000(0000) knlGS:0000000000000000 <4> [317.128176] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [317.128178] CR2: 0000000000000010 CR3: 000000011f676004 CR4: 0000000000770ef0 <4> [317.128180] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 <4> [317.128182] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400 <4> [317.128184] PKRU: 55555554 <4> [317.128185] Call Trace: <4> [317.128187] <4> [317.128189] ? show_regs+0x67/0x70 <4> [317.128194] ? __die_body+0x20/0x70 <4> [317.128196] ? __die+0x2b/0x40 <4> [317.128198] ? page_fault_oops+0x15f/0x4e0 <4> [317.128203] ? do_user_addr_fault+0x3fb/0x970 <4> [317.128205] ? lock_acquire+0xc7/0x2e0 <4> [317.128209] ? exc_page_fault+0x87/0x2b0 <4> [317.128212] ? asm_exc_page_fault+0x27/0x30 <4> [317.128216] ? xe_migrate_copy+0x66/0x13e0 [xe] <4> [317.128263] ? __lock_acquire+0xb9d/0x26f0 <4> [317.128265] ? __lock_acquire+0xb9d/0x26f0 <4> [317.128267] ? sg_free_append_table+0x20/0x80 <4> [317.128271] ? lock_acquire+0xc7/0x2e0 <4> [317.128273] ? mark_held_locks+0x4d/0x80 <4> [317.128275] ? trace_hardirqs_on+0x1e/0xd0 <4> [317.128278] ? _raw_spin_unlock_irqrestore+0x31/0x60 <4> [317.128281] ? __pm_runtime_resume+0x60/0xa0 <4> [317.128284] xe_bo_move+0x682/0xc50 [xe] <4> [317.128315] ? lock_is_held_type+0xaa/0x120 <4> [317.128318] ttm_bo_handle_move_mem+0xe5/0x1a0 [ttm] <4> [317.128324] ttm_bo_validate+0xd1/0x1a0 [ttm] <4> [317.128328] shrink_test_run_device+0x721/0xc10 [xe] <4> [317.128360] ? find_held_lock+0x31/0x90 <4> [317.128363] ? lock_release+0xd1/0x2a0 <4> [317.128365] ? __pfx_kunit_generic_run_threadfn_adapter+0x10/0x10 [kunit] <4> [317.128370] xe_bo_shrink_kunit+0x11/0x20 [xe] <4> [317.128397] kunit_try_run_case+0x6e/0x150 [kunit] <4> [317.128400] ? trace_hardirqs_on+0x1e/0xd0 <4> [317.128402] ? _raw_spin_unlock_irqrestore+0x31/0x60 <4> [317.128404] kunit_generic_run_threadfn_adapter+0x1e/0x40 [ku ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49943", "url": "https://ubuntu.com/security/CVE-2024-49943", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc_submit: add missing locking in wedged_fini Any non-wedged queue can have a zero refcount here and can be running concurrently with an async queue destroy, therefore dereferencing the queue ptr to check wedge status after the lookup can trigger UAF if queue is not wedged. Fix this by keeping the submission_state lock held around the check to postpone the free and make the check safe, before dropping again around the put() to avoid the deadlock. (cherry picked from commit d28af0b6b9580b9f90c265a7da0315b0ad20bbfd)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50011", "url": "https://ubuntu.com/security/CVE-2024-50011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: soc-acpi-intel-rpl-match: add missing empty item There is no links_num in struct snd_soc_acpi_mach {}, and we test !link->num_adr as a condition to end the loop in hda_sdw_machine_select(). So an empty item in struct snd_soc_acpi_link_adr array is required.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50174", "url": "https://ubuntu.com/security/CVE-2024-50174", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix race when converting group handle to group object XArray provides it's own internal lock which protects the internal array when entries are being simultaneously added and removed. However there is still a race between retrieving the pointer from the XArray and incrementing the reference count. To avoid this race simply hold the internal XArray lock when incrementing the reference count, this ensures there cannot be a racing call to xa_erase().", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49944", "url": "https://ubuntu.com/security/CVE-2024-49944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_start In sctp_listen_start() invoked by sctp_inet_listen(), it should set the sk_state back to CLOSED if sctp_autobind() fails due to whatever reason. Otherwise, next time when calling sctp_inet_listen(), if sctp_sk(sk)->reuse is already set via setsockopt(SCTP_REUSE_PORT), sctp_sk(sk)->bind_hash will be dereferenced as sk_state is LISTENING, which causes a crash as bind_hash is NULL. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:sctp_inet_listen+0x7f0/0xa20 net/sctp/socket.c:8617 Call Trace: __sys_listen_socket net/socket.c:1883 [inline] __sys_listen+0x1b7/0x230 net/socket.c:1894 __do_sys_listen net/socket.c:1902 [inline]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49945", "url": "https://ubuntu.com/security/CVE-2024-49945", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/ncsi: Disable the ncsi work before freeing the associated structure The work function can run after the ncsi device is freed, resulting in use-after-free bugs or kernel panic.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49946", "url": "https://ubuntu.com/security/CVE-2024-49946", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: do not assume bh is held in ppp_channel_bridge_input() Networking receive path is usually handled from BH handler. However, some protocols need to acquire the socket lock, and packets might be stored in the socket backlog is the socket was owned by a user process. In this case, release_sock(), __release_sock(), and sk_backlog_rcv() might call the sk->sk_backlog_rcv() handler in process context. sybot caught ppp was not considering this case in ppp_channel_bridge_input() : WARNING: inconsistent lock state 6.11.0-rc7-syzkaller-g5f5673607153 #0 Not tainted -------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. ksoftirqd/1/24 [HC0[0]:SC1[1]:HE1:SE0] takes: ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 {SOFTIRQ-ON-W} state was registered at: lock_acquire+0x240/0x728 kernel/locking/lockdep.c:5759 __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline] _raw_spin_lock+0x48/0x60 kernel/locking/spinlock.c:154 spin_lock include/linux/spinlock.h:351 [inline] ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline] ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0xfc/0x314 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv include/net/sock.h:1111 [inline] __release_sock+0x1a8/0x3d8 net/core/sock.c:3004 release_sock+0x68/0x1b8 net/core/sock.c:3558 pppoe_sendmsg+0xc8/0x5d8 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x374/0x4f4 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __arm64_sys_sendto+0xd8/0xf8 net/socket.c:2212 __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:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 irq event stamp: 282914 hardirqs last enabled at (282914): [] __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:151 [inline] hardirqs last enabled at (282914): [] _raw_spin_unlock_irqrestore+0x38/0x98 kernel/locking/spinlock.c:194 hardirqs last disabled at (282913): [] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline] hardirqs last disabled at (282913): [] _raw_spin_lock_irqsave+0x2c/0x7c kernel/locking/spinlock.c:162 softirqs last enabled at (282904): [] softirq_handle_end kernel/softirq.c:400 [inline] softirqs last enabled at (282904): [] handle_softirqs+0xa3c/0xbfc kernel/softirq.c:582 softirqs last disabled at (282909): [] run_ksoftirqd+0x70/0x158 kernel/softirq.c:928 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&pch->downl); lock(&pch->downl); *** DEADLOCK *** 1 lock held by ksoftirqd/1/24: #0: ffff80008f74dfa0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire+0x10/0x4c include/linux/rcupdate.h:325 stack backtrace: CPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 6.11.0-rc7-syzkaller-g5f5673607153 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call trace: dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:319 show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:326 __dump_sta ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49947", "url": "https://ubuntu.com/security/CVE-2024-49947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: test for not too small csum_start in virtio_net_hdr_to_skb() syzbot was able to trigger this warning [1], after injecting a malicious packet through af_packet, setting skb->csum_start and thus the transport header to an incorrect value. We can at least make sure the transport header is after the end of the network header (with a estimated minimal size). [1] [ 67.873027] skb len=4096 headroom=16 headlen=14 tailroom=0 mac=(-1,-1) mac_len=0 net=(16,-6) trans=10 shinfo(txflags=0 nr_frags=1 gso(size=0 type=0 segs=0)) csum(0xa start=10 offset=0 ip_summed=3 complete_sw=0 valid=0 level=0) hash(0x0 sw=0 l4=0) proto=0x0800 pkttype=0 iif=0 priority=0x0 mark=0x0 alloc_cpu=10 vlan_all=0x0 encapsulation=0 inner(proto=0x0000, mac=0, net=0, trans=0) [ 67.877172] dev name=veth0_vlan feat=0x000061164fdd09e9 [ 67.877764] sk family=17 type=3 proto=0 [ 67.878279] skb linear: 00000000: 00 00 10 00 00 00 00 00 0f 00 00 00 08 00 [ 67.879128] skb frag: 00000000: 0e 00 07 00 00 00 28 00 08 80 1c 00 04 00 00 02 [ 67.879877] skb frag: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.880647] skb frag: 00000020: 00 00 02 00 00 00 08 00 1b 00 00 00 00 00 00 00 [ 67.881156] skb frag: 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.881753] skb frag: 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.882173] skb frag: 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.882790] skb frag: 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.883171] skb frag: 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.883733] skb frag: 00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.884206] skb frag: 00000090: 00 00 00 00 00 00 00 00 00 00 69 70 76 6c 61 6e [ 67.884704] skb frag: 000000a0: 31 00 00 00 00 00 00 00 00 00 2b 00 00 00 00 00 [ 67.885139] skb frag: 000000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.885677] skb frag: 000000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.886042] skb frag: 000000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.886408] skb frag: 000000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.887020] skb frag: 000000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.887384] skb frag: 00000100: 00 00 [ 67.887878] ------------[ cut here ]------------ [ 67.887908] offset (-6) >= skb_headlen() (14) [ 67.888445] WARNING: CPU: 10 PID: 2088 at net/core/dev.c:3332 skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.889353] Modules linked in: macsec macvtap macvlan hsr wireguard curve25519_x86_64 libcurve25519_generic libchacha20poly1305 chacha_x86_64 libchacha poly1305_x86_64 dummy bridge sr_mod cdrom evdev pcspkr i2c_piix4 9pnet_virtio 9p 9pnet netfs [ 67.890111] CPU: 10 UID: 0 PID: 2088 Comm: b363492833 Not tainted 6.11.0-virtme #1011 [ 67.890183] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 67.890309] RIP: 0010:skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891043] Call Trace: [ 67.891173] [ 67.891274] ? __warn (kernel/panic.c:741) [ 67.891320] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891333] ? report_bug (lib/bug.c:180 lib/bug.c:219) [ 67.891348] ? handle_bug (arch/x86/kernel/traps.c:239) [ 67.891363] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) [ 67.891372] ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621) [ 67.891388] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891399] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891416] ip_do_fragment (net/ipv4/ip_output.c:777 (discriminator 1)) [ 67.891448] ? __ip_local_out (./include/linux/skbuff.h:1146 ./include/net/l3mdev.h:196 ./include/net/l3mdev.h:213 ne ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49948", "url": "https://ubuntu.com/security/CVE-2024-49948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: add more sanity checks to qdisc_pkt_len_init() One path takes care of SKB_GSO_DODGY, assuming skb->len is bigger than hdr_len. virtio_net_hdr_to_skb() does not fully dissect TCP headers, it only make sure it is at least 20 bytes. It is possible for an user to provide a malicious 'GSO' packet, total length of 80 bytes. - 20 bytes of IPv4 header - 60 bytes TCP header - a small gso_size like 8 virtio_net_hdr_to_skb() would declare this packet as a normal GSO packet, because it would see 40 bytes of payload, bigger than gso_size. We need to make detect this case to not underflow qdisc_skb_cb(skb)->pkt_len.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49949", "url": "https://ubuntu.com/security/CVE-2024-49949", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: avoid potential underflow in qdisc_pkt_len_init() with UFO After commit 7c6d2ecbda83 (\"net: be more gentle about silly gso requests coming from user\") virtio_net_hdr_to_skb() had sanity check to detect malicious attempts from user space to cook a bad GSO packet. Then commit cf9acc90c80ec (\"net: virtio_net_hdr_to_skb: count transport header in UFO\") while fixing one issue, allowed user space to cook a GSO packet with the following characteristic : IPv4 SKB_GSO_UDP, gso_size=3, skb->len = 28. When this packet arrives in qdisc_pkt_len_init(), we end up with hdr_len = 28 (IPv4 header + UDP header), matching skb->len Then the following sets gso_segs to 0 : gso_segs = DIV_ROUND_UP(skb->len - hdr_len, shinfo->gso_size); Then later we set qdisc_skb_cb(skb)->pkt_len to back to zero :/ qdisc_skb_cb(skb)->pkt_len += (gso_segs - 1) * hdr_len; This leads to the following crash in fq_codel [1] qdisc_pkt_len_init() is best effort, we only want an estimation of the bytes sent on the wire, not crashing the kernel. This patch is fixing this particular issue, a following one adds more sanity checks for another potential bug. [1] [ 70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 70.724561] #PF: supervisor read access in kernel mode [ 70.724561] #PF: error_code(0x0000) - not-present page [ 70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0 [ 70.724561] Oops: Oops: 0000 [#1] SMP NOPTI [ 70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991 [ 70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel [ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 <49> 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49 All code ======== 0:\t24 08 \tand $0x8,%al 2:\t49 c1 e1 06 \tshl $0x6,%r9 6:\t44 89 7c 24 18 \tmov %r15d,0x18(%rsp) b:\t45 31 ed \txor %r13d,%r13d e:\t45 31 c0 \txor %r8d,%r8d 11:\t31 ff \txor %edi,%edi 13:\t89 44 24 14 \tmov %eax,0x14(%rsp) 17:\t4c 03 8b 90 01 00 00 \tadd 0x190(%rbx),%r9 1e:\teb 04 \tjmp 0x24 20:\t39 ca \tcmp %ecx,%edx 22:\t73 37 \tjae 0x5b 24:\t4d 8b 39 \tmov (%r9),%r15 27:\t83 c7 01 \tadd $0x1,%edi 2a:*\t49 8b 17 \tmov (%r15),%rdx\t\t<-- trapping instruction 2d:\t49 89 11 \tmov %rdx,(%r9) 30:\t41 8b 57 28 \tmov 0x28(%r15),%edx 34:\t45 8b 5f 34 \tmov 0x34(%r15),%r11d 38:\t49 c7 07 00 00 00 00 \tmovq $0x0,(%r15) 3f:\t49 \trex.WB Code starting with the faulting instruction =========================================== 0:\t49 8b 17 \tmov (%r15),%rdx 3:\t49 89 11 \tmov %rdx,(%r9) 6:\t41 8b 57 28 \tmov 0x28(%r15),%edx a:\t45 8b 5f 34 \tmov 0x34(%r15),%r11d e:\t49 c7 07 00 00 00 00 \tmovq $0x0,(%r15) 15:\t49 \trex.WB [ 70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202 [ 70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000 [ 70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001 [ 70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000 [ 70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58 [ 70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000 [ 70.724561] FS: 000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000 [ 70.724561] CS: 0010 DS: 0000 ES: 0000 C ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49997", "url": "https://ubuntu.com/security/CVE-2024-49997", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: lantiq_etop: fix memory disclosure When applying padding, the buffer is not zeroed, which results in memory disclosure. The mentioned data is observed on the wire. This patch uses skb_put_padto() to pad Ethernet frames properly. The mentioned function zeroes the expanded buffer. In case the packet cannot be padded it is silently dropped. Statistics are also not incremented. This driver does not support statistics in the old 32-bit format or the new 64-bit format. These will be added in the future. In its current form, the patch should be easily backported to stable versions. Ethernet MACs on Amazon-SE and Danube cannot do padding of the packets in hardware, so software padding must be applied.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49998", "url": "https://ubuntu.com/security/CVE-2024-49998", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: improve shutdown sequence Alexander Sverdlin presents 2 problems during shutdown with the lan9303 driver. One is specific to lan9303 and the other just happens to reproduce there. The first problem is that lan9303 is unique among DSA drivers in that it calls dev_get_drvdata() at \"arbitrary runtime\" (not probe, not shutdown, not remove): phy_state_machine() -> ... -> dsa_user_phy_read() -> ds->ops->phy_read() -> lan9303_phy_read() -> chip->ops->phy_read() -> lan9303_mdio_phy_read() -> dev_get_drvdata() But we never stop the phy_state_machine(), so it may continue to run after dsa_switch_shutdown(). Our common pattern in all DSA drivers is to set drvdata to NULL to suppress the remove() method that may come afterwards. But in this case it will result in an NPD. The second problem is that the way in which we set dp->conduit->dsa_ptr = NULL; is concurrent with receive packet processing. dsa_switch_rcv() checks once whether dev->dsa_ptr is NULL, but afterwards, rather than continuing to use that non-NULL value, dev->dsa_ptr is dereferenced again and again without NULL checks: dsa_conduit_find_user() and many other places. In between dereferences, there is no locking to ensure that what was valid once continues to be valid. Both problems have the common aspect that closing the conduit interface solves them. In the first case, dev_close(conduit) triggers the NETDEV_GOING_DOWN event in dsa_user_netdevice_event() which closes user ports as well. dsa_port_disable_rt() calls phylink_stop(), which synchronously stops the phylink state machine, and ds->ops->phy_read() will thus no longer call into the driver after this point. In the second case, dev_close(conduit) should do this, as per Documentation/networking/driver.rst: | Quiescence | ---------- | | After the ndo_stop routine has been called, the hardware must | not receive or transmit any data. All in flight packets must | be aborted. If necessary, poll or wait for completion of | any reset commands. So it should be sufficient to ensure that later, when we zeroize conduit->dsa_ptr, there will be no concurrent dsa_switch_rcv() call on this conduit. The addition of the netif_device_detach() function is to ensure that ioctls, rtnetlinks and ethtool requests on the user ports no longer propagate down to the driver - we're no longer prepared to handle them. The race condition actually did not exist when commit 0650bf52b31f (\"net: dsa: be compatible with masters which unregister on shutdown\") first introduced dsa_switch_shutdown(). It was created later, when we stopped unregistering the user interfaces from a bad spot, and we just replaced that sequence with a racy zeroization of conduit->dsa_ptr (one which doesn't ensure that the interfaces aren't up).", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49999", "url": "https://ubuntu.com/security/CVE-2024-49999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix the setting of the server responding flag In afs_wait_for_operation(), we set transcribe the call responded flag to the server record that we used after doing the fileserver iteration loop - but it's possible to exit the loop having had a response from the server that we've discarded (e.g. it returned an abort or we started receiving data, but the call didn't complete). This means that op->server might be NULL, but we don't check that before attempting to set the server flag.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49950", "url": "https://ubuntu.com/security/CVE-2024-49950", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix uaf in l2cap_connect [Syzbot reported] BUG: KASAN: slab-use-after-free in l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 Read of size 8 at addr ffff8880241e9800 by task kworker/u9:0/54 CPU: 0 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-00268-g788220eee30d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Workqueue: hci2 hci_rx_work Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 l2cap_connect_req net/bluetooth/l2cap_core.c:4080 [inline] l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:4772 [inline] l2cap_sig_channel net/bluetooth/l2cap_core.c:5543 [inline] l2cap_recv_frame+0xf0b/0x8eb0 net/bluetooth/l2cap_core.c:6825 l2cap_recv_acldata+0x9b4/0xb70 net/bluetooth/l2cap_core.c:7514 hci_acldata_packet net/bluetooth/hci_core.c:3791 [inline] hci_rx_work+0xaab/0x1610 net/bluetooth/hci_core.c:4028 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 ... Freed by task 5245: 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:579 poison_slab_object+0xf7/0x160 mm/kasan/common.c:240 __kasan_slab_free+0x32/0x50 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2256 [inline] slab_free mm/slub.c:4477 [inline] kfree+0x12a/0x3b0 mm/slub.c:4598 l2cap_conn_free net/bluetooth/l2cap_core.c:1810 [inline] kref_put include/linux/kref.h:65 [inline] l2cap_conn_put net/bluetooth/l2cap_core.c:1822 [inline] l2cap_conn_del+0x59d/0x730 net/bluetooth/l2cap_core.c:1802 l2cap_connect_cfm+0x9e6/0xf80 net/bluetooth/l2cap_core.c:7241 hci_connect_cfm include/net/bluetooth/hci_core.h:1960 [inline] hci_conn_failed+0x1c3/0x370 net/bluetooth/hci_conn.c:1265 hci_abort_conn_sync+0x75a/0xb50 net/bluetooth/hci_sync.c:5583 abort_conn_sync+0x197/0x360 net/bluetooth/hci_conn.c:2917 hci_cmd_sync_work+0x1a4/0x410 net/bluetooth/hci_sync.c:328 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49951", "url": "https://ubuntu.com/security/CVE-2024-49951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Fix possible crash on mgmt_index_removed If mgmt_index_removed is called while there are commands queued on cmd_sync it could lead to crashes like the bellow trace: 0x0000053D: __list_del_entry_valid_or_report+0x98/0xdc 0x0000053D: mgmt_pending_remove+0x18/0x58 [bluetooth] 0x0000053E: mgmt_remove_adv_monitor_complete+0x80/0x108 [bluetooth] 0x0000053E: hci_cmd_sync_work+0xbc/0x164 [bluetooth] So while handling mgmt_index_removed this attempts to dequeue commands passed as user_data to cmd_sync.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49952", "url": "https://ubuntu.com/security/CVE-2024-49952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: prevent nf_skb_duplicated corruption syzbot found that nf_dup_ipv4() or nf_dup_ipv6() could write per-cpu variable nf_skb_duplicated in an unsafe way [1]. Disabling preemption as hinted by the splat is not enough, we have to disable soft interrupts as well. [1] BUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316 caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49 nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook+0x2c4/0x450 include/linux/netfilter.h:269 NF_HOOK_COND include/linux/netfilter.h:302 [inline] ip_output+0x185/0x230 net/ipv4/ip_output.c:433 ip_local_out net/ipv4/ip_output.c:129 [inline] ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495 udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981 udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737 __do_sys_sendmmsg net/socket.c:2766 [inline] __se_sys_sendmmsg net/socket.c:2763 [inline] __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763 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:0x7f4ce4f7def9 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:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9 RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006 RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49953", "url": "https://ubuntu.com/security/CVE-2024-49953", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix crash caused by calling __xfrm_state_delete() twice The km.state is not checked in driver's delayed work. When xfrm_state_check_expire() is called, the state can be reset to XFRM_STATE_EXPIRED, even if it is XFRM_STATE_DEAD already. This happens when xfrm state is deleted, but not freed yet. As __xfrm_state_delete() is called again in xfrm timer, the following crash occurs. To fix this issue, skip xfrm_state_check_expire() if km.state is not XFRM_STATE_VALID. Oops: general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] SMP CPU: 5 UID: 0 PID: 7448 Comm: kworker/u102:2 Not tainted 6.11.0-rc2+ #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5e_ipsec: eth%d mlx5e_ipsec_handle_sw_limits [mlx5_core] RIP: 0010:__xfrm_state_delete+0x3d/0x1b0 Code: 0f 84 8b 01 00 00 48 89 fd c6 87 c8 00 00 00 05 48 8d bb 40 10 00 00 e8 11 04 1a 00 48 8b 95 b8 00 00 00 48 8b 85 c0 00 00 00 <48> 89 42 08 48 89 10 48 8b 55 10 48 b8 00 01 00 00 00 00 ad de 48 RSP: 0018:ffff88885f945ec8 EFLAGS: 00010246 RAX: dead000000000122 RBX: ffffffff82afa940 RCX: 0000000000000036 RDX: dead000000000100 RSI: 0000000000000000 RDI: ffffffff82afb980 RBP: ffff888109a20340 R08: ffff88885f945ea0 R09: 0000000000000000 R10: 0000000000000000 R11: ffff88885f945ff8 R12: 0000000000000246 R13: ffff888109a20340 R14: ffff88885f95f420 R15: ffff88885f95f400 FS: 0000000000000000(0000) GS:ffff88885f940000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2163102430 CR3: 00000001128d6001 CR4: 0000000000370eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? die_addr+0x33/0x90 ? exc_general_protection+0x1a2/0x390 ? asm_exc_general_protection+0x22/0x30 ? __xfrm_state_delete+0x3d/0x1b0 ? __xfrm_state_delete+0x2f/0x1b0 xfrm_timer_handler+0x174/0x350 ? __xfrm_state_delete+0x1b0/0x1b0 __hrtimer_run_queues+0x121/0x270 hrtimer_run_softirq+0x88/0xd0 handle_softirqs+0xcc/0x270 do_softirq+0x3c/0x50 __local_bh_enable_ip+0x47/0x50 mlx5e_ipsec_handle_sw_limits+0x7d/0x90 [mlx5_core] process_one_work+0x137/0x2d0 worker_thread+0x28d/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50000", "url": "https://ubuntu.com/security/CVE-2024-50000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix NULL deref in mlx5e_tir_builder_alloc() In mlx5e_tir_builder_alloc() kvzalloc() may return NULL which is dereferenced on the next line in a reference to the modify field. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50001", "url": "https://ubuntu.com/security/CVE-2024-50001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix error path in multi-packet WQE transmit Remove the erroneous unmap in case no DMA mapping was established The multi-packet WQE transmit code attempts to obtain a DMA mapping for the skb. This could fail, e.g. under memory pressure, when the IOMMU driver just can't allocate more memory for page tables. While the code tries to handle this in the path below the err_unmap label it erroneously unmaps one entry from the sq's FIFO list of active mappings. Since the current map attempt failed this unmap is removing some random DMA mapping that might still be required. If the PCI function now presents that IOVA, the IOMMU may assumes a rogue DMA access and e.g. on s390 puts the PCI function in error state. The erroneous behavior was seen in a stress-test environment that created memory pressure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50179", "url": "https://ubuntu.com/security/CVE-2024-50179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: remove the incorrect Fw reference check when dirtying pages When doing the direct-io reads it will also try to mark pages dirty, but for the read path it won't hold the Fw caps and there is case will it get the Fw reference.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49963", "url": "https://ubuntu.com/security/CVE-2024-49963", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mailbox: bcm2835: Fix timeout during suspend mode During noirq suspend phase the Raspberry Pi power driver suffer of firmware property timeouts. The reason is that the IRQ of the underlying BCM2835 mailbox is disabled and rpi_firmware_property_list() will always run into a timeout [1]. Since the VideoCore side isn't consider as a wakeup source, set the IRQF_NO_SUSPEND flag for the mailbox IRQ in order to keep it enabled during suspend-resume cycle. [1] PM: late suspend of devices complete after 1.754 msecs WARNING: CPU: 0 PID: 438 at drivers/firmware/raspberrypi.c:128 rpi_firmware_property_list+0x204/0x22c Firmware transaction 0x00028001 timeout Modules linked in: CPU: 0 PID: 438 Comm: bash Tainted: G C 6.9.3-dirty #17 Hardware name: BCM2835 Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x44 dump_stack_lvl from __warn+0x88/0xec __warn from warn_slowpath_fmt+0x7c/0xb0 warn_slowpath_fmt from rpi_firmware_property_list+0x204/0x22c rpi_firmware_property_list from rpi_firmware_property+0x68/0x8c rpi_firmware_property from rpi_firmware_set_power+0x54/0xc0 rpi_firmware_set_power from _genpd_power_off+0xe4/0x148 _genpd_power_off from genpd_sync_power_off+0x7c/0x11c genpd_sync_power_off from genpd_finish_suspend+0xcc/0xe0 genpd_finish_suspend from dpm_run_callback+0x78/0xd0 dpm_run_callback from device_suspend_noirq+0xc0/0x238 device_suspend_noirq from dpm_suspend_noirq+0xb0/0x168 dpm_suspend_noirq from suspend_devices_and_enter+0x1b8/0x5ac suspend_devices_and_enter from pm_suspend+0x254/0x2e4 pm_suspend from state_store+0xa8/0xd4 state_store from kernfs_fop_write_iter+0x154/0x1a0 kernfs_fop_write_iter from vfs_write+0x12c/0x184 vfs_write from ksys_write+0x78/0xc0 ksys_write from ret_fast_syscall+0x0/0x54 Exception stack(0xcc93dfa8 to 0xcc93dff0) [...] PM: noirq suspend of devices complete after 3095.584 msecs", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49954", "url": "https://ubuntu.com/security/CVE-2024-49954", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: static_call: Replace pointless WARN_ON() in static_call_module_notify() static_call_module_notify() triggers a WARN_ON(), when memory allocation fails in __static_call_add_module(). That's not really justified, because the failure case must be correctly handled by the well known call chain and the error code is passed through to the initiating userspace application. A memory allocation fail is not a fatal problem, but the WARN_ON() takes the machine out when panic_on_warn is set. Replace it with a pr_warn().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50002", "url": "https://ubuntu.com/security/CVE-2024-50002", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: static_call: Handle module init failure correctly in static_call_del_module() Module insertion invokes static_call_add_module() to initialize the static calls in a module. static_call_add_module() invokes __static_call_init(), which allocates a struct static_call_mod to either encapsulate the built-in static call sites of the associated key into it so further modules can be added or to append the module to the module chain. If that allocation fails the function returns with an error code and the module core invokes static_call_del_module() to clean up eventually added static_call_mod entries. This works correctly, when all keys used by the module were converted over to a module chain before the failure. If not then static_call_del_module() causes a #GP as it blindly assumes that key::mods points to a valid struct static_call_mod. The problem is that key::mods is not a individual struct member of struct static_call_key, it's part of a union to save space: union { /* bit 0: 0 = mods, 1 = sites */ unsigned long type; struct static_call_mod *mods; struct static_call_site *sites; \t}; key::sites is a pointer to the list of built-in usage sites of the static call. The type of the pointer is differentiated by bit 0. A mods pointer has the bit clear, the sites pointer has the bit set. As static_call_del_module() blidly assumes that the pointer is a valid static_call_mod type, it fails to check for this failure case and dereferences the pointer to the list of built-in call sites, which is obviously bogus. Cure it by checking whether the key has a sites or a mods pointer. If it's a sites pointer then the key is not to be touched. As the sites are walked in the same order as in __static_call_init() the site walk can be terminated because all subsequent sites have not been touched by the init code due to the error exit. If it was converted before the allocation fail, then the inner loop which searches for a module match will find nothing. A fail in the second allocation in __static_call_init() is harmless and does not require special treatment. The first allocation succeeded and converted the key to a module chain. That first entry has mod::mod == NULL and mod::next == NULL, so the inner loop of static_call_del_module() will neither find a module match nor a module chain. The next site in the walk was either already converted, but can't match the module, or it will exit the outer loop because it has a static_call_site pointer and not a static_call_mod pointer.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-47675", "url": "https://ubuntu.com/security/CVE-2024-47675", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix use-after-free in bpf_uprobe_multi_link_attach() If bpf_link_prime() fails, bpf_uprobe_multi_link_attach() goes to the error_free label and frees the array of bpf_uprobe's without calling bpf_uprobe_unregister(). This leaks bpf_uprobe->uprobe and worse, this frees bpf_uprobe->consumer without removing it from the uprobe->consumers list.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47676", "url": "https://ubuntu.com/security/CVE-2024-47676", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb.c: fix UAF of vma in hugetlb fault pathway Syzbot reports a UAF in hugetlb_fault(). This happens because vmf_anon_prepare() could drop the per-VMA lock and allow the current VMA to be freed before hugetlb_vma_unlock_read() is called. We can fix this by using a modified version of vmf_anon_prepare() that doesn't release the VMA lock on failure, and then release it ourselves after hugetlb_vma_unlock_read().", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47677", "url": "https://ubuntu.com/security/CVE-2024-47677", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: resolve memory leak from exfat_create_upcase_table() If exfat_load_upcase_table reaches end and returns -EINVAL, allocated memory doesn't get freed and while exfat_load_default_upcase_table allocates more memory, leading to a memory leak. Here's link to syzkaller crash report illustrating this issue: https://syzkaller.appspot.com/text?tag=CrashReport&x=1406c201980000", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47725", "url": "https://ubuntu.com/security/CVE-2024-47725", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47739", "url": "https://ubuntu.com/security/CVE-2024-47739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: padata: use integer wrap around to prevent deadlock on seq_nr overflow When submitting more than 2^32 padata objects to padata_do_serial, the current sorting implementation incorrectly sorts padata objects with overflowed seq_nr, causing them to be placed before existing objects in the reorder list. This leads to a deadlock in the serialization process as padata_find_next cannot match padata->seq_nr and pd->processed because the padata instance with overflowed seq_nr will be selected next. To fix this, we use an unsigned integer wrap around to correctly sort padata objects in scenarios with integer overflow.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47678", "url": "https://ubuntu.com/security/CVE-2024-47678", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: icmp: change the order of rate limits ICMP messages are ratelimited : After the blamed commits, the two rate limiters are applied in this order: 1) host wide ratelimit (icmp_global_allow()) 2) Per destination ratelimit (inetpeer based) In order to avoid side-channels attacks, we need to apply the per destination check first. This patch makes the following change : 1) icmp_global_allow() checks if the host wide limit is reached. But credits are not yet consumed. This is deferred to 3) 2) The per destination limit is checked/updated. This might add a new node in inetpeer tree. 3) icmp_global_consume() consumes tokens if prior operations succeeded. This means that host wide ratelimit is still effective in keeping inetpeer tree small even under DDOS. As a bonus, I removed icmp_global.lock as the fast path can use a lock-free operation.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47733", "url": "https://ubuntu.com/security/CVE-2024-47733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfs: Delete subtree of 'fs/netfs' when netfs module exits In netfs_init() or fscache_proc_init(), we create dentry under 'fs/netfs', but in netfs_exit(), we only delete the proc entry of 'fs/netfs' without deleting its subtree. This triggers the following WARNING: ================================================================== remove_proc_entry: removing non-empty directory 'fs/netfs', leaking at least 'requests' WARNING: CPU: 4 PID: 566 at fs/proc/generic.c:717 remove_proc_entry+0x160/0x1c0 Modules linked in: netfs(-) CPU: 4 UID: 0 PID: 566 Comm: rmmod Not tainted 6.11.0-rc3 #860 RIP: 0010:remove_proc_entry+0x160/0x1c0 Call Trace: netfs_exit+0x12/0x620 [netfs] __do_sys_delete_module.isra.0+0x14c/0x2e0 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e ================================================================== Therefore use remove_proc_subtree() instead of remove_proc_entry() to fix the above problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47679", "url": "https://ubuntu.com/security/CVE-2024-47679", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfs: fix race between evice_inodes() and find_inode()&iput() Hi, all Recently I noticed a bug[1] in btrfs, after digged it into and I believe it'a race in vfs. Let's assume there's a inode (ie ino 261) with i_count 1 is called by iput(), and there's a concurrent thread calling generic_shutdown_super(). cpu0: cpu1: iput() // i_count is 1 ->spin_lock(inode) ->dec i_count to 0 ->iput_final() generic_shutdown_super() ->__inode_add_lru() ->evict_inodes() // cause some reason[2] ->if (atomic_read(inode->i_count)) continue; // return before // inode 261 passed the above check // list_lru_add_obj() // and then schedule out ->spin_unlock() // note here: the inode 261 // was still at sb list and hash list, // and I_FREEING|I_WILL_FREE was not been set btrfs_iget() // after some function calls ->find_inode() // found the above inode 261 ->spin_lock(inode) // check I_FREEING|I_WILL_FREE // and passed ->__iget() ->spin_unlock(inode) // schedule back ->spin_lock(inode) // check (I_NEW|I_FREEING|I_WILL_FREE) flags, // passed and set I_FREEING iput() ->spin_unlock(inode) ->spin_lock(inode)\t\t\t ->evict() // dec i_count to 0 ->iput_final() ->spin_unlock() ->evict() Now, we have two threads simultaneously evicting the same inode, which may trigger the BUG(inode->i_state & I_CLEAR) statement both within clear_inode() and iput(). To fix the bug, recheck the inode->i_count after holding i_lock. Because in the most scenarios, the first check is valid, and the overhead of spin_lock() can be reduced. If there is any misunderstanding, please let me know, thanks. [1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/ [2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable() return false when I reproduced the bug.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49859", "url": "https://ubuntu.com/security/CVE-2024-49859", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to check atomic_file in f2fs ioctl interfaces Some f2fs ioctl interfaces like f2fs_ioc_set_pin_file(), f2fs_move_file_range(), and f2fs_defragment_range() missed to check atomic_write status, which may cause potential race issue, fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47680", "url": "https://ubuntu.com/security/CVE-2024-47680", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: check discard support for conventional zones As the helper function f2fs_bdev_support_discard() shows, f2fs checks if the target block devices support discard by calling bdev_max_discard_sectors() and bdev_is_zoned(). This check works well for most cases, but it does not work for conventional zones on zoned block devices. F2fs assumes that zoned block devices support discard, and calls __submit_discard_cmd(). When __submit_discard_cmd() is called for sequential write required zones, it works fine since __submit_discard_cmd() issues zone reset commands instead of discard commands. However, when __submit_discard_cmd() is called for conventional zones, __blkdev_issue_discard() is called even when the devices do not support discard. The inappropriate __blkdev_issue_discard() call was not a problem before the commit 30f1e7241422 (\"block: move discard checks into the ioctl handler\") because __blkdev_issue_discard() checked if the target devices support discard or not. If not, it returned EOPNOTSUPP. After the commit, __blkdev_issue_discard() no longer checks it. It always returns zero and sets NULL to the given bio pointer. This NULL pointer triggers f2fs_bug_on() in __submit_discard_cmd(). The BUG is recreated with the commands below at the umount step, where /dev/nullb0 is a zoned null_blk with 5GB total size, 128MB zone size and 10 conventional zones. $ mkfs.f2fs -f -m /dev/nullb0 $ mount /dev/nullb0 /mnt $ for ((i=0;i<5;i++)); do dd if=/dev/zero of=/mnt/test bs=65536 count=1600 conv=fsync; done $ umount /mnt To fix the BUG, avoid the inappropriate __blkdev_issue_discard() call. When discard is requested for conventional zones, check if the device supports discard or not. If not, return EOPNOTSUPP.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47740", "url": "https://ubuntu.com/security/CVE-2024-47740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: Require FMODE_WRITE for atomic write ioctls The F2FS ioctls for starting and committing atomic writes check for inode_owner_or_capable(), but this does not give LSMs like SELinux or Landlock an opportunity to deny the write access - if the caller's FSUID matches the inode's UID, inode_owner_or_capable() immediately returns true. There are scenarios where LSMs want to deny a process the ability to write particular files, even files that the FSUID of the process owns; but this can currently partially be bypassed using atomic write ioctls in two ways: - F2FS_IOC_START_ATOMIC_REPLACE + F2FS_IOC_COMMIT_ATOMIC_WRITE can truncate an inode to size 0 - F2FS_IOC_START_ATOMIC_WRITE + F2FS_IOC_ABORT_ATOMIC_WRITE can revert changes another process concurrently made to a file Fix it by requiring FMODE_WRITE for these operations, just like for F2FS_IOC_MOVE_RANGE. Since any legitimate caller should only be using these ioctls when intending to write into the file, that seems unlikely to break anything.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47726", "url": "https://ubuntu.com/security/CVE-2024-47726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to wait dio completion It should wait all existing dio write IOs before block removal, otherwise, previous direct write IO may overwrite data in the block which may be reused by other inode.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47741", "url": "https://ubuntu.com/security/CVE-2024-47741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race setting file private on concurrent lseek using same fd When doing concurrent lseek(2) system calls against the same file descriptor, using multiple threads belonging to the same process, we have a short time window where a race happens and can result in a memory leak. The race happens like this: 1) A program opens a file descriptor for a file and then spawns two threads (with the pthreads library for example), lets call them task A and task B; 2) Task A calls lseek with SEEK_DATA or SEEK_HOLE and ends up at file.c:find_desired_extent() while holding a read lock on the inode; 3) At the start of find_desired_extent(), it extracts the file's private_data pointer into a local variable named 'private', which has a value of NULL; 4) Task B also calls lseek with SEEK_DATA or SEEK_HOLE, locks the inode in shared mode and enters file.c:find_desired_extent(), where it also extracts file->private_data into its local variable 'private', which has a NULL value; 5) Because it saw a NULL file private, task A allocates a private structure and assigns to the file structure; 6) Task B also saw a NULL file private so it also allocates its own file private and then assigns it to the same file structure, since both tasks are using the same file descriptor. At this point we leak the private structure allocated by task A. Besides the memory leak, there's also the detail that both tasks end up using the same cached state record in the private structure (struct btrfs_file_private::llseek_cached_state), which can result in a use-after-free problem since one task can free it while the other is still using it (only one task took a reference count on it). Also, sharing the cached state is not a good idea since it could result in incorrect results in the future - right now it should not be a problem because it end ups being used only in extent-io-tree.c:count_range_bits() where we do range validation before using the cached state. Fix this by protecting the private assignment and check of a file while holding the inode's spinlock and keep track of the task that allocated the private, so that it's used only by that task in order to prevent user-after-free issues with the cached state record as well as potentially using it incorrectly in the future.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47681", "url": "https://ubuntu.com/security/CVE-2024-47681", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix NULL pointer dereference in mt7996_mcu_sta_bfer_he Fix the NULL pointer dereference in mt7996_mcu_sta_bfer_he routine adding an sta interface to the mt7996 driver. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49858", "url": "https://ubuntu.com/security/CVE-2024-49858", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption The TPM event log table is a Linux specific construct, where the data produced by the GetEventLog() boot service is cached in memory, and passed on to the OS using an EFI configuration table. The use of EFI_LOADER_DATA here results in the region being left unreserved in the E820 memory map constructed by the EFI stub, and this is the memory description that is passed on to the incoming kernel by kexec, which is therefore unaware that the region should be reserved. Even though the utility of the TPM2 event log after a kexec is questionable, any corruption might send the parsing code off into the weeds and crash the kernel. So let's use EFI_ACPI_RECLAIM_MEMORY instead, which is always treated as reserved by the E820 conversion logic.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49860", "url": "https://ubuntu.com/security/CVE-2024-49860", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: sysfs: validate return type of _STR method Only buffer objects are valid return values of _STR. If something else is returned description_show() will access invalid memory.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47742", "url": "https://ubuntu.com/security/CVE-2024-47742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware_loader: Block path traversal Most firmware names are hardcoded strings, or are constructed from fairly constrained format strings where the dynamic parts are just some hex numbers or such. However, there are a couple codepaths in the kernel where firmware file names contain string components that are passed through from a device or semi-privileged userspace; the ones I could find (not counting interfaces that require root privileges) are: - lpfc_sli4_request_firmware_update() seems to construct the firmware filename from \"ModelName\", a string that was previously parsed out of some descriptor (\"Vital Product Data\") in lpfc_fill_vpd() - nfp_net_fw_find() seems to construct a firmware filename from a model name coming from nfp_hwinfo_lookup(pf->hwinfo, \"nffw.partno\"), which I think parses some descriptor that was read from the device. (But this case likely isn't exploitable because the format string looks like \"netronome/nic_%s\", and there shouldn't be any *folders* starting with \"netronome/nic_\". The previous case was different because there, the \"%s\" is *at the start* of the format string.) - module_flash_fw_schedule() is reachable from the ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is enough to pass the privilege check), and takes a userspace-provided firmware name. (But I think to reach this case, you need to have CAP_NET_ADMIN over a network namespace that a special kind of ethernet device is mapped into, so I think this is not a viable attack path in practice.) Fix it by rejecting any firmware names containing \"..\" path components. For what it's worth, I went looking and haven't found any USB device drivers that use the firmware loader dangerously.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47682", "url": "https://ubuntu.com/security/CVE-2024-47682", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sd: Fix off-by-one error in sd_read_block_characteristics() Ff the device returns page 0xb1 with length 8 (happens with qemu v2.x, for example), sd_read_block_characteristics() may attempt an out-of-bounds memory access when accessing the zoned field at offset 8.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47743", "url": "https://ubuntu.com/security/CVE-2024-47743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: prevent NULL pointer dereference in find_asymmetric_key() In find_asymmetric_key(), if all NULLs are passed in the id_{0,1,2} arguments, the kernel will first emit WARN but then have an oops because id_2 gets dereferenced anyway. Add the missing id_2 check and move WARN_ON() to the final else branch to avoid duplicate NULL checks. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47727", "url": "https://ubuntu.com/security/CVE-2024-47727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/tdx: Fix \"in-kernel MMIO\" check TDX only supports kernel-initiated MMIO operations. The handle_mmio() function checks if the #VE exception occurred in the kernel and rejects the operation if it did not. However, userspace can deceive the kernel into performing MMIO on its behalf. For example, if userspace can point a syscall to an MMIO address, syscall does get_user() or put_user() on it, triggering MMIO #VE. The kernel will treat the #VE as in-kernel MMIO. Ensure that the target MMIO address is within the kernel before decoding instruction.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47744", "url": "https://ubuntu.com/security/CVE-2024-47744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Use dedicated mutex to protect kvm_usage_count to avoid deadlock Use a dedicated mutex to guard kvm_usage_count to fix a potential deadlock on x86 due to a chain of locks and SRCU synchronizations. Translating the below lockdep splat, CPU1 #6 will wait on CPU0 #1, CPU0 #8 will wait on CPU2 #3, and CPU2 #7 will wait on CPU1 #4 (if there's a writer, due to the fairness of r/w semaphores). CPU0 CPU1 CPU2 1 lock(&kvm->slots_lock); 2 lock(&vcpu->mutex); 3 lock(&kvm->srcu); 4 lock(cpu_hotplug_lock); 5 lock(kvm_lock); 6 lock(&kvm->slots_lock); 7 lock(cpu_hotplug_lock); 8 sync(&kvm->srcu); Note, there are likely more potential deadlocks in KVM x86, e.g. the same pattern of taking cpu_hotplug_lock outside of kvm_lock likely exists with __kvmclock_cpufreq_notifier(): cpuhp_cpufreq_online() | -> cpufreq_online() | -> cpufreq_gov_performance_limits() | -> __cpufreq_driver_target() | -> __target_index() | -> cpufreq_freq_transition_begin() | -> cpufreq_notify_transition() | -> ... __kvmclock_cpufreq_notifier() But, actually triggering such deadlocks is beyond rare due to the combination of dependencies and timings involved. E.g. the cpufreq notifier is only used on older CPUs without a constant TSC, mucking with the NX hugepage mitigation while VMs are running is very uncommon, and doing so while also onlining/offlining a CPU (necessary to generate contention on cpu_hotplug_lock) would be even more unusual. The most robust solution to the general cpu_hotplug_lock issue is likely to switch vm_list to be an RCU-protected list, e.g. so that x86's cpufreq notifier doesn't to take kvm_lock. For now, settle for fixing the most blatant deadlock, as switching to an RCU-protected list is a much more involved change, but add a comment in locking.rst to call out that care needs to be taken when walking holding kvm_lock and walking vm_list. ====================================================== WARNING: possible circular locking dependency detected 6.10.0-smp--c257535a0c9d-pip #330 Tainted: G S O ------------------------------------------------------ tee/35048 is trying to acquire lock: ff6a80eced71e0a8 (&kvm->slots_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x179/0x1e0 [kvm] but task is already holding lock: ffffffffc07abb08 (kvm_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x14a/0x1e0 [kvm] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (kvm_lock){+.+.}-{3:3}: __mutex_lock+0x6a/0xb40 mutex_lock_nested+0x1f/0x30 kvm_dev_ioctl+0x4fb/0xe50 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #2 (cpu_hotplug_lock){++++}-{0:0}: cpus_read_lock+0x2e/0xb0 static_key_slow_inc+0x16/0x30 kvm_lapic_set_base+0x6a/0x1c0 [kvm] kvm_set_apic_base+0x8f/0xe0 [kvm] kvm_set_msr_common+0x9ae/0xf80 [kvm] vmx_set_msr+0xa54/0xbe0 [kvm_intel] __kvm_set_msr+0xb6/0x1a0 [kvm] kvm_arch_vcpu_ioctl+0xeca/0x10c0 [kvm] kvm_vcpu_ioctl+0x485/0x5b0 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (&kvm->srcu){.+.+}-{0:0}: __synchronize_srcu+0x44/0x1a0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47719", "url": "https://ubuntu.com/security/CVE-2024-47719", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommufd: Protect against overflow of ALIGN() during iova allocation Userspace can supply an iova and uptr such that the target iova alignment becomes really big and ALIGN() overflows which corrupts the selected area range during allocation. CONFIG_IOMMUFD_TEST can detect this: WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline] WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352 Modules linked in: CPU: 1 PID: 5092 Comm: syz-executor294 Not tainted 6.10.0-rc5-syzkaller-00294-g3ffea9a7a6f7 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024 RIP: 0010:iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline] RIP: 0010:iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352 Code: fc e9 a4 f3 ff ff e8 1a 8b 4c fc 41 be e4 ff ff ff e9 8a f3 ff ff e8 0a 8b 4c fc 90 0f 0b 90 e9 37 f5 ff ff e8 fc 8a 4c fc 90 <0f> 0b 90 e9 68 f3 ff ff 48 c7 c1 ec 82 ad 8f 80 e1 07 80 c1 03 38 RSP: 0018:ffffc90003ebf9e0 EFLAGS: 00010293 RAX: ffffffff85499fa4 RBX: 00000000ffffffef RCX: ffff888079b49e00 RDX: 0000000000000000 RSI: 00000000ffffffef RDI: 0000000000000000 RBP: ffffc90003ebfc50 R08: ffffffff85499b30 R09: ffffffff85499942 R10: 0000000000000002 R11: ffff888079b49e00 R12: ffff8880228e0010 R13: 0000000000000000 R14: 1ffff920007d7f68 R15: ffffc90003ebfd00 FS: 000055557d760380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000005fdeb8 CR3: 000000007404a000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: iommufd_ioas_copy+0x610/0x7b0 drivers/iommu/iommufd/ioas.c:274 iommufd_fops_ioctl+0x4d9/0x5a0 drivers/iommu/iommufd/main.c:421 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Cap the automatic alignment to the huge page size, which is probably a better idea overall. Huge automatic alignments can fragment and chew up the available IOVA space without any reason.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47745", "url": "https://ubuntu.com/security/CVE-2024-47745", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: call the security_mmap_file() LSM hook in remap_file_pages() The remap_file_pages syscall handler calls do_mmap() directly, which doesn't contain the LSM security check. And if the process has called personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for RW pages, this will actually result in remapping the pages to RWX, bypassing a W^X policy enforced by SELinux. So we should check prot by security_mmap_file LSM hook in the remap_file_pages syscall handler before do_mmap() is called. Otherwise, it potentially permits an attacker to bypass a W^X policy enforced by SELinux. The bypass is similar to CVE-2016-10044, which bypass the same thing via AIO and can be found in [1]. The PoC: $ cat > test.c int main(void) { \tsize_t pagesz = sysconf(_SC_PAGE_SIZE); \tint mfd = syscall(SYS_memfd_create, \"test\", 0); \tconst char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE, \t\tMAP_SHARED, mfd, 0); \tunsigned int old = syscall(SYS_personality, 0xffffffff); \tsyscall(SYS_personality, READ_IMPLIES_EXEC | old); \tsyscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0); \tsyscall(SYS_personality, old); \t// show the RWX page exists even if W^X policy is enforced \tint fd = open(\"/proc/self/maps\", O_RDONLY); \tunsigned char buf2[1024]; \twhile (1) { \t\tint ret = read(fd, buf2, 1024); \t\tif (ret <= 0) break; \t\twrite(1, buf2, ret); \t} \tclose(fd); } $ gcc test.c -o test $ ./test | grep rwx 7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted) [PM: subject line tweaks]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47746", "url": "https://ubuntu.com/security/CVE-2024-47746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: use exclusive lock when FUSE_I_CACHE_IO_MODE is set This may be a typo. The comment has said shared locks are not allowed when this bit is set. If using shared lock, the wait in `fuse_file_cached_io_open` may be forever.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47734", "url": "https://ubuntu.com/security/CVE-2024-47734", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: Fix unnecessary warnings and logs from bond_xdp_get_xmit_slave() syzbot reported a WARNING in bond_xdp_get_xmit_slave. To reproduce this[1], one bond device (bond1) has xdpdrv, which increases bpf_master_redirect_enabled_key. Another bond device (bond0) which is unsupported by XDP but its slave (veth3) has xdpgeneric that returns XDP_TX. This triggers WARN_ON_ONCE() from the xdp_master_redirect(). To reduce unnecessary warnings and improve log management, we need to delete the WARN_ON_ONCE() and add ratelimit to the netdev_err(). [1] Steps to reproduce: # Needs tx_xdp with return XDP_TX; ip l add veth0 type veth peer veth1 ip l add veth3 type veth peer veth4 ip l add bond0 type bond mode 6 # BOND_MODE_ALB, unsupported by XDP ip l add bond1 type bond # BOND_MODE_ROUNDROBIN by default ip l set veth0 master bond1 ip l set bond1 up # Increases bpf_master_redirect_enabled_key ip l set dev bond1 xdpdrv object tx_xdp.o section xdp_tx ip l set veth3 master bond0 ip l set bond0 up ip l set veth4 up # Triggers WARN_ON_ONCE() from the xdp_master_redirect() ip l set veth3 xdpgeneric object tx_xdp.o section xdp_tx", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47684", "url": "https://ubuntu.com/security/CVE-2024-47684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: check skb is non-NULL in tcp_rto_delta_us() We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic kernel that are running ceph and recently hit a null ptr dereference in tcp_rearm_rto(). Initially hitting it from the TLP path, but then later we also saw it getting hit from the RACK case as well. Here are examples of the oops messages we saw in each of those cases: Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020 Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode Jul 26 15:05:02 rx [11061395.792971] #PF: error_code(0x0000) - not-present page Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0 Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI Jul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu Jul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023 Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 <48> 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3 Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246 Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000 Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60 Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8 Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900 Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30 Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000 Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0 Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554 Jul 26 15:05:02 rx [11061395.916786] Call Trace: Jul 26 15:05:02 rx [11061395.919488] Jul 26 15:05:02 rx [11061395.921765] ? show_regs.cold+0x1a/0x1f Jul 26 15:05:02 rx [11061395.925859] ? __die+0x90/0xd9 Jul 26 15:05:02 rx [11061395.929169] ? no_context+0x196/0x380 Jul 26 15:05:02 rx [11061395.933088] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0 Jul 26 15:05:02 rx [11061395.938216] ? ip6_sublist_rcv_finish+0x3d/0x50 Jul 26 15:05:02 rx [11061395.943000] ? __bad_area_nosemaphore+0x50/0x1a0 Jul 26 15:05:02 rx [11061395.947873] ? bad_area_nosemaphore+0x16/0x20 Jul 26 15:05:02 rx [11061395.952486] ? do_user_addr_fault+0x267/0x450 Jul 26 15:05:02 rx [11061395.957104] ? ipv6_list_rcv+0x112/0x140 Jul 26 15:05:02 rx [11061395.961279] ? __do_page_fault+0x58/0x90 Jul 26 15:05:02 rx [11061395.965458] ? do_page_fault+0x2c/0xe0 Jul 26 15:05:02 rx [11061395.969465] ? page_fault+0x34/0x40 Jul 26 15:05:02 rx [11061395.973217] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.977313] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.981408] tcp_send_loss_probe+0x10b/0x220 Jul 26 15:05:02 rx [11061395.985937] tcp_write_timer_handler+0x1b4/0x240 Jul 26 15:05:02 rx [11061395.990809] tcp_write_timer+0x9e/0xe0 Jul 26 15:05:02 rx [11061395.994814] ? tcp_write_timer_handler+0x240/0x240 Jul 26 15:05:02 rx [11061395.999866] call_timer_fn+0x32/0x130 Jul 26 15:05:02 rx [11061396.003782] __run_timers.part.0+0x180/0x280 Jul 26 15:05:02 rx [11061396.008309] ? recalibrate_cpu_khz+0x10/0x10 Jul 26 15:05:02 rx [11061396.012841] ? native_x2apic_icr_write+0x30/0x30 Jul 26 15:05:02 rx [11061396.017718] ? lapic_next_even ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47747", "url": "https://ubuntu.com/security/CVE-2024-47747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race Condition In the ether3_probe function, a timer is initialized with a callback function ether3_ledoff, bound to &prev(dev)->timer. Once the timer is started, there is a risk of a race condition if the module or device is removed, triggering the ether3_remove function to perform cleanup. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | ether3_ledoff ether3_remove | free_netdev(dev); | put_devic | kfree(dev); | | ether3_outw(priv(dev)->regs.config2 |= CFG2_CTRLO, REG_CONFIG2); | // use dev Fix it by ensuring that the timer is canceled before proceeding with the cleanup in ether3_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47685", "url": "https://ubuntu.com/security/CVE-2024-47685", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put() syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending garbage on the four reserved tcp bits (th->res1) Use skb_put_zero() to clear the whole TCP header, as done in nf_reject_ip_tcphdr_put() BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5661 [inline] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775 process_backlog+0x4ad/0xa50 net/core/dev.c:6108 __napi_poll+0xe7/0x980 net/core/dev.c:6772 napi_poll net/core/dev.c:6841 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963 handle_softirqs+0x1ce/0x800 kernel/softirq.c:554 __do_softirq+0x14/0x1a kernel/softirq.c:588 do_softirq+0x9a/0x100 kernel/softirq.c:455 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline] __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450 dev_queue_xmit include/linux/netdevice.h:3105 [inline] neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366 inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135 __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143 tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333 __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679 inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750 __sys_connect_file net/socket.c:2061 [inline] __sys_connect+0x606/0x690 net/socket.c:2078 __do_sys_connect net/socket.c:2088 [inline] __se_sys_connect net/socket.c:2085 [inline] __x64_sys_connect+0x91/0xe0 net/socket.c:2085 x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43 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 Uninit was stored to memory at: nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47686", "url": "https://ubuntu.com/security/CVE-2024-47686", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ep93xx: clock: Fix off by one in ep93xx_div_recalc_rate() The psc->div[] array has psc->num_div elements. These values come from when we call clk_hw_register_div(). It's adc_divisors and ARRAY_SIZE(adc_divisors)) and so on. So this condition needs to be >= instead of > to prevent an out of bounds read.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47748", "url": "https://ubuntu.com/security/CVE-2024-47748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost_vdpa: assign irq bypass producer token correctly We used to call irq_bypass_unregister_producer() in vhost_vdpa_setup_vq_irq() which is problematic as we don't know if the token pointer is still valid or not. Actually, we use the eventfd_ctx as the token so the life cycle of the token should be bound to the VHOST_SET_VRING_CALL instead of vhost_vdpa_setup_vq_irq() which could be called by set_status(). Fixing this by setting up irq bypass producer's token when handling VHOST_SET_VRING_CALL and un-registering the producer before calling vhost_vring_ioctl() to prevent a possible use after free as eventfd could have been released in vhost_vring_ioctl(). And such registering and unregistering will only be done if DRIVER_OK is set.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47687", "url": "https://ubuntu.com/security/CVE-2024-47687", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa/mlx5: Fix invalid mr resource destroy Certain error paths from mlx5_vdpa_dev_add() can end up releasing mr resources which never got initialized in the first place. This patch adds the missing check in mlx5_vdpa_destroy_mr_resources() to block releasing non-initialized mr resources. Reference trace: mlx5_core 0000:08:00.2: mlx5_vdpa_dev_add:3274:(pid 2700) warning: No mac address provisioned? BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 140216067 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 8 PID: 2700 Comm: vdpa Kdump: loaded Not tainted 5.14.0-496.el9.x86_64 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:vhost_iotlb_del_range+0xf/0xe0 [vhost_iotlb] Code: [...] RSP: 0018:ff1c823ac23077f0 EFLAGS: 00010246 RAX: ffffffffc1a21a60 RBX: ffffffff899567a0 RCX: 0000000000000000 RDX: ffffffffffffffff RSI: 0000000000000000 RDI: 0000000000000000 RBP: ff1bda1f7c21e800 R08: 0000000000000000 R09: ff1c823ac2307670 R10: ff1c823ac2307668 R11: ffffffff8a9e7b68 R12: 0000000000000000 R13: 0000000000000000 R14: ff1bda1f43e341a0 R15: 00000000ffffffea FS: 00007f56eba7c740(0000) GS:ff1bda269f800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000104d90001 CR4: 0000000000771ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? mlx5_vdpa_free+0x3d/0x150 [mlx5_vdpa] ? __die_body.cold+0x8/0xd ? page_fault_oops+0x134/0x170 ? __irq_work_queue_local+0x2b/0xc0 ? irq_work_queue+0x2c/0x50 ? exc_page_fault+0x62/0x150 ? asm_exc_page_fault+0x22/0x30 ? __pfx_mlx5_vdpa_free+0x10/0x10 [mlx5_vdpa] ? vhost_iotlb_del_range+0xf/0xe0 [vhost_iotlb] mlx5_vdpa_free+0x3d/0x150 [mlx5_vdpa] vdpa_release_dev+0x1e/0x50 [vdpa] device_release+0x31/0x90 kobject_cleanup+0x37/0x130 mlx5_vdpa_dev_add+0x2d2/0x7a0 [mlx5_vdpa] vdpa_nl_cmd_dev_add_set_doit+0x277/0x4c0 [vdpa] genl_family_rcv_msg_doit+0xd9/0x130 genl_family_rcv_msg+0x14d/0x220 ? __pfx_vdpa_nl_cmd_dev_add_set_doit+0x10/0x10 [vdpa] ? _copy_to_user+0x1a/0x30 ? move_addr_to_user+0x4b/0xe0 genl_rcv_msg+0x47/0xa0 ? __import_iovec+0x46/0x150 ? __pfx_genl_rcv_msg+0x10/0x10 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x245/0x370 netlink_sendmsg+0x206/0x440 __sys_sendto+0x1dc/0x1f0 ? do_read_fault+0x10c/0x1d0 ? do_pte_missing+0x10d/0x190 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x5c/0xf0 ? __count_memcg_events+0x4f/0xb0 ? mm_account_fault+0x6c/0x100 ? handle_mm_fault+0x116/0x270 ? do_user_addr_fault+0x1d6/0x6a0 ? do_syscall_64+0x6b/0xf0 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 entry_SYSCALL_64_after_hwframe+0x78/0x80", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47688", "url": "https://ubuntu.com/security/CVE-2024-47688", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: driver core: Fix a potential null-ptr-deref in module_add_driver() Inject fault while probing of-fpga-region, if kasprintf() fails in module_add_driver(), the second sysfs_remove_link() in exit path will cause null-ptr-deref as below because kernfs_name_hash() will call strlen() with NULL driver_name. Fix it by releasing resources based on the exit path sequence. \t KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] \t Mem abort info: \t ESR = 0x0000000096000005 \t EC = 0x25: DABT (current EL), IL = 32 bits \t SET = 0, FnV = 0 \t EA = 0, S1PTW = 0 \t FSC = 0x05: level 1 translation fault \t Data abort info: \t ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 \t CM = 0, WnR = 0, TnD = 0, TagAccess = 0 \t GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 \t [dfffffc000000000] address between user and kernel address ranges \t Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP \t Dumping ftrace buffer: \t (ftrace buffer empty) \t Modules linked in: of_fpga_region(+) fpga_region fpga_bridge cfg80211 rfkill 8021q garp mrp stp llc ipv6 [last unloaded: of_fpga_region] \t CPU: 2 UID: 0 PID: 2036 Comm: modprobe Not tainted 6.11.0-rc2-g6a0e38264012 #295 \t Hardware name: linux,dummy-virt (DT) \t pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) \t pc : strlen+0x24/0xb0 \t lr : kernfs_name_hash+0x1c/0xc4 \t sp : ffffffc081f97380 \t x29: ffffffc081f97380 x28: ffffffc081f97b90 x27: ffffff80c821c2a0 \t x26: ffffffedac0be418 x25: 0000000000000000 x24: ffffff80c09d2000 \t x23: 0000000000000000 x22: 0000000000000000 x21: 0000000000000000 \t x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000001840 \t x17: 0000000000000000 x16: 0000000000000000 x15: 1ffffff8103f2e42 \t x14: 00000000f1f1f1f1 x13: 0000000000000004 x12: ffffffb01812d61d \t x11: 1ffffff01812d61c x10: ffffffb01812d61c x9 : dfffffc000000000 \t x8 : 0000004fe7ed29e4 x7 : ffffff80c096b0e7 x6 : 0000000000000001 \t x5 : ffffff80c096b0e0 x4 : 1ffffffdb990efa2 x3 : 0000000000000000 \t x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000000 \t Call trace: \t strlen+0x24/0xb0 \t kernfs_name_hash+0x1c/0xc4 \t kernfs_find_ns+0x118/0x2e8 \t kernfs_remove_by_name_ns+0x80/0x100 \t sysfs_remove_link+0x74/0xa8 \t module_add_driver+0x278/0x394 \t bus_add_driver+0x1f0/0x43c \t driver_register+0xf4/0x3c0 \t __platform_driver_register+0x60/0x88 \t of_fpga_region_init+0x20/0x1000 [of_fpga_region] \t do_one_initcall+0x110/0x788 \t do_init_module+0x1dc/0x5c8 \t load_module+0x3c38/0x4cac \t init_module_from_file+0xd4/0x128 \t idempotent_init_module+0x2cc/0x528 \t __arm64_sys_finit_module+0xac/0x100 \t invoke_syscall+0x6c/0x258 \t el0_svc_common.constprop.0+0x160/0x22c \t do_el0_svc+0x44/0x5c \t el0_svc+0x48/0xb8 \t el0t_64_sync_handler+0x13c/0x158 \t el0t_64_sync+0x190/0x194 \t Code: f2fbffe1 a90157f4 12000802 aa0003f5 (38e16861) \t ---[ end trace 0000000000000000 ]--- \t Kernel panic - not syncing: Oops: Fatal exception", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47689", "url": "https://ubuntu.com/security/CVE-2024-47689", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to don't set SB_RDONLY in f2fs_handle_critical_error() syzbot reports a f2fs bug as below: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 58 at kernel/rcu/sync.c:177 rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177 CPU: 1 UID: 0 PID: 58 Comm: kworker/1:2 Not tainted 6.10.0-syzkaller-12562-g1722389b0d86 #0 Workqueue: events destroy_super_work RIP: 0010:rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177 Call Trace: percpu_free_rwsem+0x41/0x80 kernel/locking/percpu-rwsem.c:42 destroy_super_work+0xec/0x130 fs/super.c:282 process_one_work kernel/workqueue.c:3231 [inline] process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 worker_thread+0x86d/0xd40 kernel/workqueue.c:3390 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 As Christian Brauner pointed out [1]: the root cause is f2fs sets SB_RDONLY flag in internal function, rather than setting the flag covered w/ sb->s_umount semaphore via remount procedure, then below race condition causes this bug: - freeze_super() - sb_wait_write(sb, SB_FREEZE_WRITE) - sb_wait_write(sb, SB_FREEZE_PAGEFAULT) - sb_wait_write(sb, SB_FREEZE_FS) \t\t\t\t\t- f2fs_handle_critical_error \t\t\t\t\t - sb->s_flags |= SB_RDONLY - thaw_super - thaw_super_locked - sb_rdonly() is true, so it skips sb_freeze_unlock(sb, SB_FREEZE_FS) - deactivate_locked_super Since f2fs has almost the same logic as ext4 [2] when handling critical error in filesystem if it mounts w/ errors=remount-ro option: - set CP_ERROR_FLAG flag which indicates filesystem is stopped - record errors to superblock - set SB_RDONLY falg Once we set CP_ERROR_FLAG flag, all writable interfaces can detect the flag and stop any further updates on filesystem. So, it is safe to not set SB_RDONLY flag, let's remove the logic and keep in line w/ ext4 [3]. [1] https://lore.kernel.org/all/20240729-himbeeren-funknetz-96e62f9c7aee@brauner [2] https://lore.kernel.org/all/20240729132721.hxih6ehigadqf7wx@quack3 [3] https://lore.kernel.org/linux-ext4/20240805201241.27286-1-jack@suse.cz", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47690", "url": "https://ubuntu.com/security/CVE-2024-47690", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: get rid of online repaire on corrupted directory syzbot reports a f2fs bug as below: kernel BUG at fs/f2fs/inode.c:896! RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Call Trace: evict+0x532/0x950 fs/inode.c:704 dispose_list fs/inode.c:747 [inline] evict_inodes+0x5f9/0x690 fs/inode.c:797 generic_shutdown_super+0x9d/0x2d0 fs/super.c:627 kill_block_super+0x44/0x90 fs/super.c:1696 kill_f2fs_super+0x344/0x690 fs/f2fs/super.c:4898 deactivate_locked_super+0xc4/0x130 fs/super.c:473 cleanup_mnt+0x41f/0x4b0 fs/namespace.c:1373 task_work_run+0x24f/0x310 kernel/task_work.c:228 ptrace_notify+0x2d2/0x380 kernel/signal.c:2402 ptrace_report_syscall include/linux/ptrace.h:415 [inline] ptrace_report_syscall_exit include/linux/ptrace.h:477 [inline] syscall_exit_work+0xc6/0x190 kernel/entry/common.c:173 syscall_exit_to_user_mode_prepare kernel/entry/common.c:200 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:205 [inline] syscall_exit_to_user_mode+0x279/0x370 kernel/entry/common.c:218 do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Online repaire on corrupted directory in f2fs_lookup() can generate dirty data/meta while racing w/ readonly remount, it may leave dirty inode after filesystem becomes readonly, however, checkpoint() will skips flushing dirty inode in a state of readonly mode, result in above panic. Let's get rid of online repaire in f2fs_lookup(), and leave the work to fsck.f2fs.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47691", "url": "https://ubuntu.com/security/CVE-2024-47691", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread() syzbot reports a f2fs bug as below: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_report+0xe8/0x550 mm/kasan/report.c:491 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 instrument_atomic_read_write include/linux/instrumented.h:96 [inline] atomic_fetch_add_relaxed include/linux/atomic/atomic-instrumented.h:252 [inline] __refcount_add include/linux/refcount.h:184 [inline] __refcount_inc include/linux/refcount.h:241 [inline] refcount_inc include/linux/refcount.h:258 [inline] get_task_struct include/linux/sched/task.h:118 [inline] kthread_stop+0xca/0x630 kernel/kthread.c:704 f2fs_stop_gc_thread+0x65/0xb0 fs/f2fs/gc.c:210 f2fs_do_shutdown+0x192/0x540 fs/f2fs/file.c:2283 f2fs_ioc_shutdown fs/f2fs/file.c:2325 [inline] __f2fs_ioctl+0x443a/0xbe60 fs/f2fs/file.c:4325 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f The root cause is below race condition, it may cause use-after-free issue in sbi->gc_th pointer. - remount - f2fs_remount - f2fs_stop_gc_thread - kfree(gc_th) \t\t\t\t- f2fs_ioc_shutdown \t\t\t\t - f2fs_do_shutdown \t\t\t\t - f2fs_stop_gc_thread \t\t\t\t - kthread_stop(gc_th->f2fs_gc_task) : sbi->gc_thread = NULL; We will call f2fs_do_shutdown() in two paths: - for f2fs_ioc_shutdown() path, we should grab sb->s_umount semaphore for fixing. - for f2fs_shutdown() path, it's safe since caller has already grabbed sb->s_umount semaphore.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47692", "url": "https://ubuntu.com/security/CVE-2024-47692", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: return -EINVAL when namelen is 0 When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may result in namelen being 0, which will cause memdup_user() to return ZERO_SIZE_PTR. When we access the name.data that has been assigned the value of ZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is triggered. [ T1205] ================================================================== [ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260 [ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205 [ T1205] [ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406 [ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ T1205] Call Trace: [ T1205] dump_stack+0x9a/0xd0 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] __kasan_report.cold+0x34/0x84 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] kasan_report+0x3a/0x50 [ T1205] nfs4_client_to_reclaim+0xe9/0x260 [ T1205] ? nfsd4_release_lockowner+0x410/0x410 [ T1205] cld_pipe_downcall+0x5ca/0x760 [ T1205] ? nfsd4_cld_tracking_exit+0x1d0/0x1d0 [ T1205] ? down_write_killable_nested+0x170/0x170 [ T1205] ? avc_policy_seqno+0x28/0x40 [ T1205] ? selinux_file_permission+0x1b4/0x1e0 [ T1205] rpc_pipe_write+0x84/0xb0 [ T1205] vfs_write+0x143/0x520 [ T1205] ksys_write+0xc9/0x170 [ T1205] ? __ia32_sys_read+0x50/0x50 [ T1205] ? ktime_get_coarse_real_ts64+0xfe/0x110 [ T1205] ? ktime_get_coarse_real_ts64+0xa2/0x110 [ T1205] do_syscall_64+0x33/0x40 [ T1205] entry_SYSCALL_64_after_hwframe+0x67/0xd1 [ T1205] RIP: 0033:0x7fdbdb761bc7 [ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 514 [ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7 [ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008 [ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001 [ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b [ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000 [ T1205] ================================================================== Fix it by checking namelen.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47737", "url": "https://ubuntu.com/security/CVE-2024-47737", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: call cache_put if xdr_reserve_space returns NULL If not enough buffer space available, but idmap_lookup has triggered lookup_fn which calls cache_get and returns successfully. Then we missed to call cache_put here which pairs with cache_get. Reviwed-by: Jeff Layton ", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2023-52917", "url": "https://ubuntu.com/security/CVE-2023-52917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir() The debugfs_create_dir() function returns error pointers. It never returns NULL. So use IS_ERR() to check it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47749", "url": "https://ubuntu.com/security/CVE-2024-47749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Added NULL check for lookup_atid The lookup_atid() function can return NULL if the ATID is invalid or does not exist in the identifier table, which could lead to dereferencing a null pointer without a check in the `act_establish()` and `act_open_rpl()` functions. Add a NULL check to prevent null pointer dereferencing. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47735", "url": "https://ubuntu.com/security/CVE-2024-47735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled Fix missuse of spin_lock_irq()/spin_unlock_irq() when spin_lock_irqsave()/spin_lock_irqrestore() was hold. This was discovered through the lock debugging, and the corresponding log is as follows: raw_local_irq_restore() called with IRQs enabled WARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40 ... Call trace: warn_bogus_irq_restore+0x30/0x40 _raw_spin_unlock_irqrestore+0x84/0xc8 add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2] hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2] hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2] create_qp+0x138/0x258 ib_create_qp_kernel+0x50/0xe8 create_mad_qp+0xa8/0x128 ib_mad_port_open+0x218/0x448 ib_mad_init_device+0x70/0x1f8 add_client_context+0xfc/0x220 enable_device_and_get+0xd0/0x140 ib_register_device.part.0+0xf4/0x1c8 ib_register_device+0x34/0x50 hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2] hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2] __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2] hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47750", "url": "https://ubuntu.com/security/CVE-2024-47750", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix Use-After-Free of rsv_qp on HIP08 Currently rsv_qp is freed before ib_unregister_device() is called on HIP08. During the time interval, users can still dereg MR and rsv_qp will be used in this process, leading to a UAF. Move the release of rsv_qp after calling ib_unregister_device() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47751", "url": "https://ubuntu.com/security/CVE-2024-47751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: kirin: Fix buffer overflow in kirin_pcie_parse_port() Within kirin_pcie_parse_port(), the pcie->num_slots is compared to pcie->gpio_id_reset size (MAX_PCI_SLOTS) which is correct and would lead to an overflow. Thus, fix condition to pcie->num_slots + 1 >= MAX_PCI_SLOTS and move pcie->num_slots increment below the if-statement to avoid out-of-bounds array access. Found by Linux Verification Center (linuxtesting.org) with SVACE. [kwilczynski: commit log]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47693", "url": "https://ubuntu.com/security/CVE-2024-47693", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/core: Fix ib_cache_setup_one error flow cleanup When ib_cache_update return an error, we exit ib_cache_setup_one instantly with no proper cleanup, even though before this we had already successfully done gid_table_setup_one, that results in the kernel WARN below. Do proper cleanup using gid_table_cleanup_one before returning the err in order to fix the issue. WARNING: CPU: 4 PID: 922 at drivers/infiniband/core/cache.c:806 gid_table_release_one+0x181/0x1a0 Modules linked in: CPU: 4 UID: 0 PID: 922 Comm: c_repro Not tainted 6.11.0-rc1+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:gid_table_release_one+0x181/0x1a0 Code: 44 8b 38 75 0c e8 2f cb 34 ff 4d 8b b5 28 05 00 00 e8 23 cb 34 ff 44 89 f9 89 da 4c 89 f6 48 c7 c7 d0 58 14 83 e8 4f de 21 ff <0f> 0b 4c 8b 75 30 e9 54 ff ff ff 48 8 3 c4 10 5b 5d 41 5c 41 5d 41 RSP: 0018:ffffc90002b835b0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c8527 RDX: 0000000000000000 RSI: ffffffff811c8534 RDI: 0000000000000001 RBP: ffff8881011b3d00 R08: ffff88810b3abe00 R09: 205d303839303631 R10: 666572207972746e R11: 72746e6520444947 R12: 0000000000000001 R13: ffff888106390000 R14: ffff8881011f2110 R15: 0000000000000001 FS: 00007fecc3b70800(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000340 CR3: 000000010435a001 CR4: 00000000003706b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? show_regs+0x94/0xa0 ? __warn+0x9e/0x1c0 ? gid_table_release_one+0x181/0x1a0 ? report_bug+0x1f9/0x340 ? gid_table_release_one+0x181/0x1a0 ? handle_bug+0xa2/0x110 ? exc_invalid_op+0x31/0xa0 ? asm_exc_invalid_op+0x16/0x20 ? __warn_printk+0xc7/0x180 ? __warn_printk+0xd4/0x180 ? gid_table_release_one+0x181/0x1a0 ib_device_release+0x71/0xe0 ? __pfx_ib_device_release+0x10/0x10 device_release+0x44/0xd0 kobject_put+0x135/0x3d0 put_device+0x20/0x30 rxe_net_add+0x7d/0xa0 rxe_newlink+0xd7/0x190 nldev_newlink+0x1b0/0x2a0 ? __pfx_nldev_newlink+0x10/0x10 rdma_nl_rcv_msg+0x1ad/0x2e0 rdma_nl_rcv_skb.constprop.0+0x176/0x210 netlink_unicast+0x2de/0x400 netlink_sendmsg+0x306/0x660 __sock_sendmsg+0x110/0x120 ____sys_sendmsg+0x30e/0x390 ___sys_sendmsg+0x9b/0xf0 ? kstrtouint+0x6e/0xa0 ? kstrtouint_from_user+0x7c/0xb0 ? get_pid_task+0xb0/0xd0 ? proc_fail_nth_write+0x5b/0x140 ? __fget_light+0x9a/0x200 ? preempt_count_add+0x47/0xa0 __sys_sendmsg+0x61/0xd0 do_syscall_64+0x50/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47694", "url": "https://ubuntu.com/security/CVE-2024-47694", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mlx5: Fix UMR pd cleanup on error flow of driver init The cited commit moves the pd allocation from function mlx5r_umr_resource_cleanup() to a new function mlx5r_umr_cleanup(). So the fix in commit [1] is broken. In error flow, will hit panic [2]. Fix it by checking pd pointer to avoid panic if it is NULL; [1] RDMA/mlx5: Fix UMR cleanup on error flow of driver init [2] [ 347.567063] infiniband mlx5_0: Couldn't register device with driver model [ 347.591382] BUG: kernel NULL pointer dereference, address: 0000000000000020 [ 347.593438] #PF: supervisor read access in kernel mode [ 347.595176] #PF: error_code(0x0000) - not-present page [ 347.596962] PGD 0 P4D 0 [ 347.601361] RIP: 0010:ib_dealloc_pd_user+0x12/0xc0 [ib_core] [ 347.604171] RSP: 0018:ffff888106293b10 EFLAGS: 00010282 [ 347.604834] RAX: 0000000000000000 RBX: 000000000000000e RCX: 0000000000000000 [ 347.605672] RDX: ffff888106293ad0 RSI: 0000000000000000 RDI: 0000000000000000 [ 347.606529] RBP: 0000000000000000 R08: ffff888106293ae0 R09: ffff888106293ae0 [ 347.607379] R10: 0000000000000a06 R11: 0000000000000000 R12: 0000000000000000 [ 347.608224] R13: ffffffffa0704dc0 R14: 0000000000000001 R15: 0000000000000001 [ 347.609067] FS: 00007fdc720cd9c0(0000) GS:ffff88852c880000(0000) knlGS:0000000000000000 [ 347.610094] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 347.610727] CR2: 0000000000000020 CR3: 0000000103012003 CR4: 0000000000370eb0 [ 347.611421] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 347.612113] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 347.612804] Call Trace: [ 347.613130] [ 347.613417] ? __die+0x20/0x60 [ 347.613793] ? page_fault_oops+0x150/0x3e0 [ 347.614243] ? free_msg+0x68/0x80 [mlx5_core] [ 347.614840] ? cmd_exec+0x48f/0x11d0 [mlx5_core] [ 347.615359] ? exc_page_fault+0x74/0x130 [ 347.615808] ? asm_exc_page_fault+0x22/0x30 [ 347.616273] ? ib_dealloc_pd_user+0x12/0xc0 [ib_core] [ 347.616801] mlx5r_umr_cleanup+0x23/0x90 [mlx5_ib] [ 347.617365] mlx5_ib_stage_pre_ib_reg_umr_cleanup+0x36/0x40 [mlx5_ib] [ 347.618025] __mlx5_ib_add+0x96/0xd0 [mlx5_ib] [ 347.618539] mlx5r_probe+0xe9/0x310 [mlx5_ib] [ 347.619032] ? kernfs_add_one+0x107/0x150 [ 347.619478] ? __mlx5_ib_add+0xd0/0xd0 [mlx5_ib] [ 347.619984] auxiliary_bus_probe+0x3e/0x90 [ 347.620448] really_probe+0xc5/0x3a0 [ 347.620857] __driver_probe_device+0x80/0x160 [ 347.621325] driver_probe_device+0x1e/0x90 [ 347.621770] __driver_attach+0xec/0x1c0 [ 347.622213] ? __device_attach_driver+0x100/0x100 [ 347.622724] bus_for_each_dev+0x71/0xc0 [ 347.623151] bus_add_driver+0xed/0x240 [ 347.623570] driver_register+0x58/0x100 [ 347.623998] __auxiliary_driver_register+0x6a/0xc0 [ 347.624499] ? driver_register+0xae/0x100 [ 347.624940] ? 0xffffffffa0893000 [ 347.625329] mlx5_ib_init+0x16a/0x1e0 [mlx5_ib] [ 347.625845] do_one_initcall+0x4a/0x2a0 [ 347.626273] ? gcov_event+0x2e2/0x3a0 [ 347.626706] do_init_module+0x8a/0x260 [ 347.627126] init_module_from_file+0x8b/0xd0 [ 347.627596] __x64_sys_finit_module+0x1ca/0x2f0 [ 347.628089] do_syscall_64+0x4c/0x100", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47695", "url": "https://ubuntu.com/security/CVE-2024-47695", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds In the function init_conns(), after the create_con() and create_cm() for loop if something fails. In the cleanup for loop after the destroy tag, we access out of bound memory because cid is set to clt_path->s.con_num. This commits resets the cid to clt_path->s.con_num - 1, to stay in bounds in the cleanup loop later.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47752", "url": "https://ubuntu.com/security/CVE-2024-47752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix H264 stateless decoder smatch warning Fix a smatch static checker warning on vdec_h264_req_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47753", "url": "https://ubuntu.com/security/CVE-2024-47753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix VP8 stateless decoder smatch warning Fix a smatch static checker warning on vdec_vp8_req_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47754", "url": "https://ubuntu.com/security/CVE-2024-47754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix H264 multi stateless decoder smatch warning Fix a smatch static checker warning on vdec_h264_req_multi_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47696", "url": "https://ubuntu.com/security/CVE-2024-47696", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency In the commit aee2424246f9 (\"RDMA/iwcm: Fix a use-after-free related to destroying CM IDs\"), the function flush_workqueue is invoked to flush the work queue iwcm_wq. But at that time, the work queue iwcm_wq was created via the function alloc_ordered_workqueue without the flag WQ_MEM_RECLAIM. Because the current process is trying to flush the whole iwcm_wq, if iwcm_wq doesn't have the flag WQ_MEM_RECLAIM, verify that the current process is not reclaiming memory or running on a workqueue which doesn't have the flag WQ_MEM_RECLAIM as that can break forward-progress guarantee leading to a deadlock. The call trace is as below: [ 125.350876][ T1430] Call Trace: [ 125.356281][ T1430] [ 125.361285][ T1430] ? __warn (kernel/panic.c:693) [ 125.367640][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.375689][ T1430] ? report_bug (lib/bug.c:180 lib/bug.c:219) [ 125.382505][ T1430] ? handle_bug (arch/x86/kernel/traps.c:239) [ 125.388987][ T1430] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) [ 125.395831][ T1430] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621) [ 125.403125][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.410984][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.418764][ T1430] __flush_workqueue (kernel/workqueue.c:3970) [ 125.426021][ T1430] ? __pfx___might_resched (kernel/sched/core.c:10151) [ 125.433431][ T1430] ? destroy_cm_id (drivers/infiniband/core/iwcm.c:375) iw_cm [ 125.441209][ T1430] ? __pfx___flush_workqueue (kernel/workqueue.c:3910) [ 125.473900][ T1430] ? _raw_spin_lock_irqsave (arch/x86/include/asm/atomic.h:107 include/linux/atomic/atomic-arch-fallback.h:2170 include/linux/atomic/atomic-instrumented.h:1302 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162) [ 125.473909][ T1430] ? __pfx__raw_spin_lock_irqsave (kernel/locking/spinlock.c:161) [ 125.482537][ T1430] _destroy_id (drivers/infiniband/core/cma.c:2044) rdma_cm [ 125.495072][ T1430] nvme_rdma_free_queue (drivers/nvme/host/rdma.c:656 drivers/nvme/host/rdma.c:650) nvme_rdma [ 125.505827][ T1430] nvme_rdma_reset_ctrl_work (drivers/nvme/host/rdma.c:2180) nvme_rdma [ 125.505831][ T1430] process_one_work (kernel/workqueue.c:3231) [ 125.515122][ T1430] worker_thread (kernel/workqueue.c:3306 kernel/workqueue.c:3393) [ 125.515127][ T1430] ? __pfx_worker_thread (kernel/workqueue.c:3339) [ 125.531837][ T1430] kthread (kernel/kthread.c:389) [ 125.539864][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.550628][ T1430] ret_from_fork (arch/x86/kernel/process.c:147) [ 125.558840][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.558844][ T1430] ret_from_fork_asm (arch/x86/entry/entry_64.S:257) [ 125.566487][ T1430] [ 125.566488][ T1430] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47755", "url": "https://ubuntu.com/security/CVE-2024-47755", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47756", "url": "https://ubuntu.com/security/CVE-2024-47756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: keystone: Fix if-statement expression in ks_pcie_quirk() This code accidentally uses && where || was intended. It potentially results in a NULL dereference. Thus, fix the if-statement expression to use the correct condition. [kwilczynski: commit log]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47697", "url": "https://ubuntu.com/security/CVE-2024-47697", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error Ensure index in rtl2830_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47698", "url": "https://ubuntu.com/security/CVE-2024-47698", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error Ensure index in rtl2832_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue. [hverkuil: added fixes tag, rtl2830_pid_filter -> rtl2832_pid_filter in logmsg]", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47728", "url": "https://ubuntu.com/security/CVE-2024-47728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error For all non-tracing helpers which formerly had ARG_PTR_TO_{LONG,INT} as input arguments, zero the value for the case of an error as otherwise it could leak memory. For tracing, it is not needed given CAP_PERFMON can already read all kernel memory anyway hence bpf_get_func_arg() and bpf_get_func_ret() is skipped in here. Also, the MTU helpers mtu_len pointer value is being written but also read. Technically, the MEM_UNINIT should not be there in order to always force init. Removing MEM_UNINIT needs more verifier rework though: MEM_UNINIT right now implies two things actually: i) write into memory, ii) memory does not have to be initialized. If we lift MEM_UNINIT, it then becomes: i) read into memory, ii) memory must be initialized. This means that for bpf_*_check_mtu() we're readding the issue we're trying to fix, that is, it would then be able to write back into things like .rodata BPF maps. Follow-up work will rework the MEM_UNINIT semantics such that the intent can be better expressed. For now just clear the *mtu_len on error path which can be lifted later again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49861", "url": "https://ubuntu.com/security/CVE-2024-49861", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix helper writes to read-only maps Lonial found an issue that despite user- and BPF-side frozen BPF map (like in case of .rodata), it was still possible to write into it from a BPF program side through specific helpers having ARG_PTR_TO_{LONG,INT} as arguments. In check_func_arg() when the argument is as mentioned, the meta->raw_mode is never set. Later, check_helper_mem_access(), under the case of PTR_TO_MAP_VALUE as register base type, it assumes BPF_READ for the subsequent call to check_map_access_type() and given the BPF map is read-only it succeeds. The helpers really need to be annotated as ARG_PTR_TO_{LONG,INT} | MEM_UNINIT when results are written into them as opposed to read out of them. The latter indicates that it's okay to pass a pointer to uninitialized memory as the memory is written to anyway. However, ARG_PTR_TO_{LONG,INT} is a special case of ARG_PTR_TO_FIXED_SIZE_MEM just with additional alignment requirement. So it is better to just get rid of the ARG_PTR_TO_{LONG,INT} special cases altogether and reuse the fixed size memory types. For this, add MEM_ALIGNED to additionally ensure alignment given these helpers write directly into the args via * = val. The .arg*_size has been initialized reflecting the actual sizeof(*). MEM_ALIGNED can only be used in combination with MEM_FIXED_SIZE annotated argument types, since in !MEM_FIXED_SIZE cases the verifier does not know the buffer size a priori and therefore cannot blindly write * = val.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47757", "url": "https://ubuntu.com/security/CVE-2024-47757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential oob read in nilfs_btree_check_delete() The function nilfs_btree_check_delete(), which checks whether degeneration to direct mapping occurs before deleting a b-tree entry, causes memory access outside the block buffer when retrieving the maximum key if the root node has no entries. This does not usually happen because b-tree mappings with 0 child nodes are never created by mkfs.nilfs2 or nilfs2 itself. However, it can happen if the b-tree root node read from a device is configured that way, so fix this potential issue by adding a check for that case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47699", "url": "https://ubuntu.com/security/CVE-2024-47699", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential null-ptr-deref in nilfs_btree_insert() Patch series \"nilfs2: fix potential issues with empty b-tree nodes\". This series addresses three potential issues with empty b-tree nodes that can occur with corrupted filesystem images, including one recently discovered by syzbot. This patch (of 3): If a b-tree is broken on the device, and the b-tree height is greater than 2 (the level of the root node is greater than 1) even if the number of child nodes of the b-tree root is 0, a NULL pointer dereference occurs in nilfs_btree_prepare_insert(), which is called from nilfs_btree_insert(). This is because, when the number of child nodes of the b-tree root is 0, nilfs_btree_do_lookup() does not set the block buffer head in any of path[x].bp_bh, leaving it as the initial value of NULL, but if the level of the b-tree root node is greater than 1, nilfs_btree_get_nonroot_node(), which accesses the buffer memory of path[x].bp_bh, is called. Fix this issue by adding a check to nilfs_btree_root_broken(), which performs sanity checks when reading the root node from the device, to detect this inconsistency. Thanks to Lizhi Xu for trying to solve the bug and clarifying the cause early on.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47700", "url": "https://ubuntu.com/security/CVE-2024-47700", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: check stripe size compatibility on remount as well We disable stripe size in __ext4_fill_super if it is not a multiple of the cluster ratio however this check is missed when trying to remount. This can leave us with cases where stripe < cluster_ratio after remount:set making EXT4_B2C(sbi->s_stripe) become 0 that can cause some unforeseen bugs like divide by 0. Fix that by adding the check in remount path as well.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47701", "url": "https://ubuntu.com/security/CVE-2024-47701", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid OOB when system.data xattr changes underneath the filesystem When looking up for an entry in an inlined directory, if e_value_offs is changed underneath the filesystem by some change in the block device, it will lead to an out-of-bounds access that KASAN detects as an UAF. EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none. loop0: detected capacity change from 2048 to 2047 ================================================================== BUG: KASAN: use-after-free in ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 Read of size 1 at addr ffff88803e91130f by task syz-executor269/5103 CPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 Not tainted 6.11.0-rc4-syzkaller #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:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 ext4_find_inline_entry+0x4be/0x5e0 fs/ext4/inline.c:1697 __ext4_find_entry+0x2b4/0x1b30 fs/ext4/namei.c:1573 ext4_lookup_entry fs/ext4/namei.c:1727 [inline] ext4_lookup+0x15f/0x750 fs/ext4/namei.c:1795 lookup_one_qstr_excl+0x11f/0x260 fs/namei.c:1633 filename_create+0x297/0x540 fs/namei.c:3980 do_symlinkat+0xf9/0x3a0 fs/namei.c:4587 __do_sys_symlinkat fs/namei.c:4610 [inline] __se_sys_symlinkat fs/namei.c:4607 [inline] __x64_sys_symlinkat+0x95/0xb0 fs/namei.c:4607 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:0x7f3e73ced469 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff4d40c258 EFLAGS: 00000246 ORIG_RAX: 000000000000010a RAX: ffffffffffffffda RBX: 0032656c69662f2e RCX: 00007f3e73ced469 RDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0 RBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290 R10: 0023706f6f6c2f76 R11: 0000000000000246 R12: 00007fff4d40c27c R13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0 Calling ext4_xattr_ibody_find right after reading the inode with ext4_get_inode_loc will lead to a check of the validity of the xattrs, avoiding this problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49850", "url": "https://ubuntu.com/security/CVE-2024-49850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: correctly handle malformed BPF_CORE_TYPE_ID_LOCAL relos In case of malformed relocation record of kind BPF_CORE_TYPE_ID_LOCAL referencing a non-existing BTF type, function bpf_core_calc_relo_insn would cause a null pointer deference. Fix this by adding a proper check upper in call stack, as malformed relocation records could be passed from user space. Simplest reproducer is a program: r0 = 0 exit With a single relocation record: .insn_off = 0, /* patch first instruction */ .type_id = 100500, /* this type id does not exist */ .access_str_off = 6, /* offset of string \"0\" */ .kind = BPF_CORE_TYPE_ID_LOCAL, See the link for original reproducer or next commit for a test case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47702", "url": "https://ubuntu.com/security/CVE-2024-47702", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fail verification for sign-extension of packet data/data_end/data_meta syzbot reported a kernel crash due to commit 1f1e864b6555 (\"bpf: Handle sign-extenstin ctx member accesses\"). The reason is due to sign-extension of 32-bit load for packet data/data_end/data_meta uapi field. The original code looks like: r2 = *(s32 *)(r1 + 76) /* load __sk_buff->data */ r3 = *(u32 *)(r1 + 80) /* load __sk_buff->data_end */ r0 = r2 r0 += 8 if r3 > r0 goto +1 ... Note that __sk_buff->data load has 32-bit sign extension. After verification and convert_ctx_accesses(), the final asm code looks like: r2 = *(u64 *)(r1 +208) r2 = (s32)r2 r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 ... Note that 'r2 = (s32)r2' may make the kernel __sk_buff->data address invalid which may cause runtime failure. Currently, in C code, typically we have void *data = (void *)(long)skb->data; void *data_end = (void *)(long)skb->data_end; ... and it will generate r2 = *(u64 *)(r1 +208) r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 If we allow sign-extension, void *data = (void *)(long)(int)skb->data; void *data_end = (void *)(long)skb->data_end; ... the generated code looks like r2 = *(u64 *)(r1 +208) r2 <<= 32 r2 s>>= 32 r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 and this will cause verification failure since \"r2 <<= 32\" is not allowed as \"r2\" is a packet pointer. To fix this issue for case r2 = *(s32 *)(r1 + 76) /* load __sk_buff->data */ this patch added additional checking in is_valid_access() callback function for packet data/data_end/data_meta access. If those accesses are with sign-extenstion, the verification will fail. [1] https://lore.kernel.org/bpf/000000000000c90eee061d236d37@google.com/", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47703", "url": "https://ubuntu.com/security/CVE-2024-47703", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, lsm: Add check for BPF LSM return value A bpf prog returning a positive number attached to file_alloc_security hook makes kernel panic. This happens because file system can not filter out the positive number returned by the LSM prog using IS_ERR, and misinterprets this positive number as a file pointer. Given that hook file_alloc_security never returned positive number before the introduction of BPF LSM, and other BPF LSM hooks may encounter similar issues, this patch adds LSM return value check in verifier, to ensure no unexpected value is returned.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49851", "url": "https://ubuntu.com/security/CVE-2024-49851", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: Clean up TPM space after command failure tpm_dev_transmit prepares the TPM space before attempting command transmission. However if the command fails no rollback of this preparation is done. This can result in transient handles being leaked if the device is subsequently closed with no further commands performed. Fix this by flushing the space in the event of command transmission failure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47723", "url": "https://ubuntu.com/security/CVE-2024-47723", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: fix out-of-bounds in dbNextAG() and diAlloc() In dbNextAG() , there is no check for the case where bmp->db_numag is greater or same than MAXAG due to a polluted image, which causes an out-of-bounds. Therefore, a bounds check should be added in dbMount(). And in dbNextAG(), a check for the case where agpref is greater than bmp->db_numag should be added, so an out-of-bounds exception should be prevented. Additionally, a check for the case where agno is greater or same than MAXAG should be added in diAlloc() to prevent out-of-bounds.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49852", "url": "https://ubuntu.com/security/CVE-2024-49852", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: elx: libefc: Fix potential use after free in efc_nport_vport_del() The kref_put() function will call nport->release if the refcount drops to zero. The nport->release release function is _efc_nport_free() which frees \"nport\". But then we dereference \"nport\" on the next line which is a use after free. Re-order these lines to avoid the use after free.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47720", "url": "https://ubuntu.com/security/CVE-2024-47720", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for set_output_gamma in dcn30_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn30_set_output_transfer_func function. Previously, set_output_gamma was being checked for nullity at line 386, but then it was being dereferenced without any nullity check at line 401. This could potentially lead to a null pointer dereference error if set_output_gamma is indeed null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a nullity check for set_output_gamma before the call to set_output_gamma at line 401. If set_output_gamma is null, we log an error message and do not call the function. This fix prevents a potential null pointer dereference error. drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:401 dcn30_set_output_transfer_func() error: we previously assumed 'mpc->funcs->set_output_gamma' could be null (see line 386) drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c 373 bool dcn30_set_output_transfer_func(struct dc *dc, 374 struct pipe_ctx *pipe_ctx, 375 const struct dc_stream_state *stream) 376 { 377 int mpcc_id = pipe_ctx->plane_res.hubp->inst; 378 struct mpc *mpc = pipe_ctx->stream_res.opp->ctx->dc->res_pool->mpc; 379 const struct pwl_params *params = NULL; 380 bool ret = false; 381 382 /* program OGAM or 3DLUT only for the top pipe*/ 383 if (pipe_ctx->top_pipe == NULL) { 384 /*program rmu shaper and 3dlut in MPC*/ 385 ret = dcn30_set_mpc_shaper_3dlut(pipe_ctx, stream); 386 if (ret == false && mpc->funcs->set_output_gamma) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If this is NULL 387 if (stream->out_transfer_func.type == TF_TYPE_HWPWL) 388 params = &stream->out_transfer_func.pwl; 389 else if (pipe_ctx->stream->out_transfer_func.type == 390 TF_TYPE_DISTRIBUTED_POINTS && 391 cm3_helper_translate_curve_to_hw_format( 392 &stream->out_transfer_func, 393 &mpc->blender_params, false)) 394 params = &mpc->blender_params; 395 /* there are no ROM LUTs in OUTGAM */ 396 if (stream->out_transfer_func.type == TF_TYPE_PREDEFINED) 397 BREAK_TO_DEBUGGER(); 398 } 399 } 400 --> 401 mpc->funcs->set_output_gamma(mpc, mpcc_id, params); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Then it will crash 402 return ret; 403 }", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47704", "url": "https://ubuntu.com/security/CVE-2024-47704", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check link_res->hpo_dp_link_enc before using it [WHAT & HOW] Functions dp_enable_link_phy and dp_disable_link_phy can pass link_res without initializing hpo_dp_link_enc and it is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49853", "url": "https://ubuntu.com/security/CVE-2024-49853", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix double free in OPTEE transport Channels can be shared between protocols, avoid freeing the same channel descriptors twice when unloading the stack.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47705", "url": "https://ubuntu.com/security/CVE-2024-47705", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix potential invalid pointer dereference in blk_add_partition The blk_add_partition() function initially used a single if-condition (IS_ERR(part)) to check for errors when adding a partition. This was modified to handle the specific case of -ENXIO separately, allowing the function to proceed without logging the error in this case. However, this change unintentionally left a path where md_autodetect_dev() could be called without confirming that part is a valid pointer. This commit separates the error handling logic by splitting the initial if-condition, improving code readability and handling specific error scenarios explicitly. The function now distinguishes the general error case from -ENXIO without altering the existing behavior of md_autodetect_dev() calls.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47736", "url": "https://ubuntu.com/security/CVE-2024-47736", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: handle overlapped pclusters out of crafted images properly syzbot reported a task hang issue due to a deadlock case where it is waiting for the folio lock of a cached folio that will be used for cache I/Os. After looking into the crafted fuzzed image, I found it's formed with several overlapped big pclusters as below: Ext: logical offset | length : physical offset | length 0: 0.. 16384 | 16384 : 151552.. 167936 | 16384 1: 16384.. 32768 | 16384 : 155648.. 172032 | 16384 2: 32768.. 49152 | 16384 : 537223168.. 537239552 | 16384 ... Here, extent 0/1 are physically overlapped although it's entirely _impossible_ for normal filesystem images generated by mkfs. First, managed folios containing compressed data will be marked as up-to-date and then unlocked immediately (unlike in-place folios) when compressed I/Os are complete. If physical blocks are not submitted in the incremental order, there should be separate BIOs to avoid dependency issues. However, the current code mis-arranges z_erofs_fill_bio_vec() and BIO submission which causes unexpected BIO waits. Second, managed folios will be connected to their own pclusters for efficient inter-queries. However, this is somewhat hard to implement easily if overlapped big pclusters exist. Again, these only appear in fuzzed images so let's simply fall back to temporary short-lived pages for correctness. Additionally, it justifies that referenced managed folios cannot be truncated for now and reverts part of commit 2080ca1ed3e4 (\"erofs: tidy up `struct z_erofs_bvec`\") for simplicity although it shouldn't be any difference.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47706", "url": "https://ubuntu.com/security/CVE-2024-47706", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block, bfq: fix possible UAF for bfqq->bic with merge chain 1) initial state, three tasks: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t\t | ? | ?\t\t | ? \t\t | | | |\t\t | | \t\t V | V |\t\t V | \t\t bfqq1 bfqq2\t\t bfqq3 process ref:\t 1\t\t 1\t\t 1 2) bfqq1 merged to bfqq2: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t\t | |\t\t | ? \t\t \\--------------\\|\t\t | | \t\t V\t\t V | \t\t bfqq1--------->bfqq2\t\t bfqq3 process ref:\t 0\t\t 2\t\t 1 3) bfqq2 merged to bfqq3: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t here -> ? |\t\t | \t\t \\--------------\\ \\-------------\\| \t\t V\t\t V \t\t bfqq1--------->bfqq2---------->bfqq3 process ref:\t 0\t\t 1\t\t 3 In this case, IO from Process 1 will get bfqq2 from BIC1 first, and then get bfqq3 through merge chain, and finially handle IO by bfqq3. Howerver, current code will think bfqq2 is owned by BIC1, like initial state, and set bfqq2->bic to BIC1. bfq_insert_request -> by Process 1 bfqq = bfq_init_rq(rq) bfqq = bfq_get_bfqq_handle_split bfqq = bic_to_bfqq -> get bfqq2 from BIC1 bfqq->ref++ rq->elv.priv[0] = bic rq->elv.priv[1] = bfqq if (bfqq_process_refs(bfqq) == 1) bfqq->bic = bic -> record BIC1 to bfqq2 __bfq_insert_request new_bfqq = bfq_setup_cooperator -> get bfqq3 from bfqq2->new_bfqq bfqq_request_freed(bfqq) new_bfqq->ref++ rq->elv.priv[1] = new_bfqq -> handle IO by bfqq3 Fix the problem by checking bfqq is from merge chain fist. And this might fix a following problem reported by our syzkaller(unreproducible): ================================================================== BUG: KASAN: slab-use-after-free in bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] BUG: KASAN: slab-use-after-free in bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] BUG: KASAN: slab-use-after-free in bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 Write of size 1 at addr ffff888123839eb8 by task kworker/0:1H/18595 CPU: 0 PID: 18595 Comm: kworker/0:1H Tainted: G L 6.6.0-07439-gba2303cacfda #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Workqueue: kblockd blk_mq_requeue_work Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [inline] print_report+0x10d/0x610 mm/kasan/report.c:475 kasan_report+0x8e/0xc0 mm/kasan/report.c:588 bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 bfq_get_bfqq_handle_split+0x169/0x5d0 block/bfq-iosched.c:6757 bfq_init_rq block/bfq-iosched.c:6876 [inline] bfq_insert_request block/bfq-iosched.c:6254 [inline] bfq_insert_requests+0x1112/0x5cf0 block/bfq-iosched.c:6304 blk_mq_insert_request+0x290/0x8d0 block/blk-mq.c:2593 blk_mq_requeue_work+0x6bc/0xa70 block/blk-mq.c:1502 process_one_work kernel/workqueue.c:2627 [inline] process_scheduled_works+0x432/0x13f0 kernel/workqueue.c:2700 worker_thread+0x6f2/0x1160 kernel/workqueue.c:2781 kthread+0x33c/0x440 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:305 Allocated by task 20776: kasan_save_stack+0x20/0x40 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 __kasan_slab_alloc+0x87/0x90 mm/kasan/common.c:328 kasan_slab_alloc include/linux/kasan.h:188 [inline] slab_post_alloc_hook mm/slab.h:763 [inline] slab_alloc_node mm/slub.c:3458 [inline] kmem_cache_alloc_node+0x1a4/0x6f0 mm/slub.c:3503 ioc_create_icq block/blk-ioc.c:370 [inline] ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49855", "url": "https://ubuntu.com/security/CVE-2024-49855", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: fix race between timeout and normal completion If request timetout is handled by nbd_requeue_cmd(), normal completion has to be stopped for avoiding to complete this requeued request, other use-after-free can be triggered. Fix the race by clearing NBD_CMD_INFLIGHT in nbd_requeue_cmd(), meantime make sure that cmd->lock is grabbed for clearing the flag and the requeue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47707", "url": "https://ubuntu.com/security/CVE-2024-47707", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev() Blamed commit accidentally removed a check for rt->rt6i_idev being NULL, as spotted by syzbot: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 UID: 0 PID: 10998 Comm: syz-executor Not tainted 6.11.0-rc6-syzkaller-00208-g625403177711 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 RBP: ffffc900047375d0 R08: 0000000000000003 R09: fffff520008e6e8c R10: dffffc0000000000 R11: fffff520008e6e8c R12: 1ffff1100fdf8f18 R13: ffff88807efc7998 R14: 0000000000000000 R15: ffff88807efc7930 FS: 0000000000000000(0000) GS:ffff8880b8900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020002a80 CR3: 0000000022f62000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: addrconf_ifdown+0x15d/0x1bd0 net/ipv6/addrconf.c:3856 addrconf_notify+0x3cb/0x1020 notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93 call_netdevice_notifiers_extack net/core/dev.c:2032 [inline] call_netdevice_notifiers net/core/dev.c:2046 [inline] unregister_netdevice_many_notify+0xd81/0x1c40 net/core/dev.c:11352 unregister_netdevice_many net/core/dev.c:11414 [inline] unregister_netdevice_queue+0x303/0x370 net/core/dev.c:11289 unregister_netdevice include/linux/netdevice.h:3129 [inline] __tun_detach+0x6b9/0x1600 drivers/net/tun.c:685 tun_detach drivers/net/tun.c:701 [inline] tun_chr_close+0x108/0x1b0 drivers/net/tun.c:3510 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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:0x7f1acc77def9 Code: Unable to access opcode bytes at 0x7f1acc77decf. RSP: 002b:00007ffeb26fa738 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1acc77def9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000043 RBP: 00007f1acc7dd508 R08: 00007ffeb26f84d7 R09: 0000000000000003 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 0000000000000003 R14: 00000000ffffffff R15: 00007ffeb26fa8e0 Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 R ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47708", "url": "https://ubuntu.com/security/CVE-2024-47708", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netkit: Assign missing bpf_net_context During the introduction of struct bpf_net_context handling for XDP-redirect, the netkit driver has been missed, which also requires it because NETKIT_REDIRECT invokes skb_do_redirect() which is accessing the per-CPU variables. Otherwise we see the following crash: \tBUG: kernel NULL pointer dereference, address: 0000000000000038 \tbpf_redirect() \tnetkit_xmit() \tdev_hard_start_xmit() Set the bpf_net_context before invoking netkit_xmit() program within the netkit driver.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47709", "url": "https://ubuntu.com/security/CVE-2024-47709", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: Clear bo->bcm_proc_read after remove_proc_entry(). syzbot reported a warning in bcm_release(). [0] The blamed change fixed another warning that is triggered when connect() is issued again for a socket whose connect()ed device has been unregistered. However, if the socket is just close()d without the 2nd connect(), the remaining bo->bcm_proc_read triggers unnecessary remove_proc_entry() in bcm_release(). Let's clear bo->bcm_proc_read after remove_proc_entry() in bcm_notify(). [0] name '4986' WARNING: CPU: 0 PID: 5234 at fs/proc/generic.c:711 remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Modules linked in: CPU: 0 UID: 0 PID: 5234 Comm: syz-executor606 Not tainted 6.11.0-rc5-syzkaller-00178-g5517ae241919 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Code: ff eb 05 e8 cb 1e 5e ff 48 8b 5c 24 10 48 c7 c7 e0 f7 aa 8e e8 2a 38 8e 09 90 48 c7 c7 60 3a 1b 8c 48 89 de e8 da 42 20 ff 90 <0f> 0b 90 90 48 8b 44 24 18 48 c7 44 24 40 0e 36 e0 45 49 c7 04 07 RSP: 0018:ffffc9000345fa20 EFLAGS: 00010246 RAX: 2a2d0aee2eb64600 RBX: ffff888032f1f548 RCX: ffff888029431e00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000345fb08 R08: ffffffff8155b2f2 R09: 1ffff1101710519a R10: dffffc0000000000 R11: ffffed101710519b R12: ffff888011d38640 R13: 0000000000000004 R14: 0000000000000000 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8880b8800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcfb52722f0 CR3: 000000000e734000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: bcm_release+0x250/0x880 net/can/bcm.c:1578 __sock_release net/socket.c:659 [inline] sock_close+0xbc/0x240 net/socket.c:1421 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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:0x7fcfb51ee969 Code: Unable to access opcode bytes at 0x7fcfb51ee93f. RSP: 002b:00007ffce0109ca8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fcfb51ee969 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 00007fcfb526f3b0 R08: ffffffffffffffb8 R09: 0000555500000000 R10: 0000555500000000 R11: 0000000000000246 R12: 00007fcfb526f3b0 R13: 0000000000000000 R14: 00007fcfb5271ee0 R15: 00007fcfb51bf160 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47710", "url": "https://ubuntu.com/security/CVE-2024-47710", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sock_map: Add a cond_resched() in sock_hash_free() Several syzbot soft lockup reports all have in common sock_hash_free() If a map with a large number of buckets is destroyed, we need to yield the cpu when needed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47711", "url": "https://ubuntu.com/security/CVE-2024-47711", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Don't return OOB skb in manage_oob(). syzbot reported use-after-free in unix_stream_recv_urg(). [0] The scenario is 1. send(MSG_OOB) 2. recv(MSG_OOB) -> The consumed OOB remains in recv queue 3. send(MSG_OOB) 4. recv() -> manage_oob() returns the next skb of the consumed OOB -> This is also OOB, but unix_sk(sk)->oob_skb is not cleared 5. recv(MSG_OOB) -> unix_sk(sk)->oob_skb is used but already freed The recent commit 8594d9b85c07 (\"af_unix: Don't call skb_get() for OOB skb.\") uncovered the issue. If the OOB skb is consumed and the next skb is peeked in manage_oob(), we still need to check if the skb is OOB. Let's do so by falling back to the following checks in manage_oob() and add the test case in selftest. Note that we need to add a similar check for SIOCATMARK. [0]: BUG: KASAN: slab-use-after-free in unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959 Read of size 4 at addr ffff8880326abcc4 by task syz-executor178/5235 CPU: 0 UID: 0 PID: 5235 Comm: syz-executor178 Not tainted 6.11.0-rc5-syzkaller-00742-gfbdaffe41adc #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959 unix_stream_recv_urg+0x1df/0x320 net/unix/af_unix.c:2640 unix_stream_read_generic+0x2456/0x2520 net/unix/af_unix.c:2778 unix_stream_recvmsg+0x22b/0x2c0 net/unix/af_unix.c:2996 sock_recvmsg_nosec net/socket.c:1046 [inline] sock_recvmsg+0x22f/0x280 net/socket.c:1068 ____sys_recvmsg+0x1db/0x470 net/socket.c:2816 ___sys_recvmsg net/socket.c:2858 [inline] __sys_recvmsg+0x2f0/0x3e0 net/socket.c:2888 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:0x7f5360d6b4e9 Code: 48 83 c4 28 c3 e8 37 17 00 00 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff29b3a458 EFLAGS: 00000246 ORIG_RAX: 000000000000002f RAX: ffffffffffffffda RBX: 00007fff29b3a638 RCX: 00007f5360d6b4e9 RDX: 0000000000002001 RSI: 0000000020000640 RDI: 0000000000000003 RBP: 00007f5360dde610 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 00007fff29b3a628 R14: 0000000000000001 R15: 0000000000000001 Allocated by task 5235: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:312 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slub.c:3988 [inline] slab_alloc_node mm/slub.c:4037 [inline] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4080 __alloc_skb+0x1c3/0x440 net/core/skbuff.c:667 alloc_skb include/linux/skbuff.h:1320 [inline] alloc_skb_with_frags+0xc3/0x770 net/core/skbuff.c:6528 sock_alloc_send_pskb+0x91a/0xa60 net/core/sock.c:2815 sock_alloc_send_skb include/net/sock.h:1778 [inline] queue_oob+0x108/0x680 net/unix/af_unix.c:2198 unix_stream_sendmsg+0xd24/0xf80 net/unix/af_unix.c:2351 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2680 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 Freed by task 5235: kasan_save_stack mm/kasan/common.c:47 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47712", "url": "https://ubuntu.com/security/CVE-2024-47712", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: fix potential RCU dereference issue in wilc_parse_join_bss_param In the `wilc_parse_join_bss_param` function, the TSF field of the `ies` structure is accessed after the RCU read-side critical section is unlocked. According to RCU usage rules, this is illegal. Reusing this pointer can lead to unpredictable behavior, including accessing memory that has been updated or causing use-after-free issues. This possible bug was identified using a static analysis tool developed by myself, specifically designed to detect RCU-related issues. To address this, the TSF value is now stored in a local variable `ies_tsf` before the RCU lock is released. The `param->tsf_lo` field is then assigned using this local variable, ensuring that the TSF value is safely accessed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47713", "url": "https://ubuntu.com/security/CVE-2024-47713", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop() Since '__dev_queue_xmit()' should be called with interrupts enabled, the following backtrace: ieee80211_do_stop() ... spin_lock_irqsave(&local->queue_stop_reason_lock, flags) ... ieee80211_free_txskb() ieee80211_report_used_skb() ieee80211_report_ack_skb() cfg80211_mgmt_tx_status_ext() nl80211_frame_tx_status() genlmsg_multicast_netns() genlmsg_multicast_netns_filtered() nlmsg_multicast_filtered() \t netlink_broadcast_filtered() \t do_one_broadcast() \t netlink_broadcast_deliver() \t __netlink_sendskb() \t netlink_deliver_tap() \t __netlink_deliver_tap_skb() \t dev_queue_xmit() \t __dev_queue_xmit() ; with IRQS disabled ... spin_unlock_irqrestore(&local->queue_stop_reason_lock, flags) issues the warning (as reported by syzbot reproducer): WARNING: CPU: 2 PID: 5128 at kernel/softirq.c:362 __local_bh_enable_ip+0xc3/0x120 Fix this by implementing a two-phase skb reclamation in 'ieee80211_do_stop()', where actual work is performed outside of a section with interrupts disabled.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47730", "url": "https://ubuntu.com/security/CVE-2024-47730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/qm - inject error before stopping queue The master ooo cannot be completely closed when the accelerator core reports memory error. Therefore, the driver needs to inject the qm error to close the master ooo. Currently, the qm error is injected after stopping queue, memory may be released immediately after stopping queue, causing the device to access the released memory. Therefore, error is injected to close master ooo before stopping queue to ensure that the device does not access the released memory.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49856", "url": "https://ubuntu.com/security/CVE-2024-49856", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/sgx: Fix deadlock in SGX NUMA node search When the current node doesn't have an EPC section configured by firmware and all other EPC sections are used up, CPU can get stuck inside the while loop that looks for an available EPC page from remote nodes indefinitely, leading to a soft lockup. Note how nid_of_current will never be equal to nid in that while loop because nid_of_current is not set in sgx_numa_mask. Also worth mentioning is that it's perfectly fine for the firmware not to setup an EPC section on a node. While setting up an EPC section on each node can enhance performance, it is not a requirement for functionality. Rework the loop to start and end on *a* node that has SGX memory. This avoids the deadlock looking for the current SGX-lacking node to show up in the loop when it never will.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47714", "url": "https://ubuntu.com/security/CVE-2024-47714", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: use hweight16 to get correct tx antenna The chainmask is u16 so using hweight8 cannot get correct tx_ant. Without this patch, the tx_ant of band 2 would be -1 and lead to the following issue: BUG: KASAN: stack-out-of-bounds in mt7996_mcu_add_sta+0x12e0/0x16e0 [mt7996e]", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47715", "url": "https://ubuntu.com/security/CVE-2024-47715", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: fix oops on non-dbdc mt7986 mt7915_band_config() sets band_idx = 1 on the main phy for mt7986 with MT7975_ONE_ADIE or MT7976_ONE_ADIE. Commit 0335c034e726 (\"wifi: mt76: fix race condition related to checking tx queue fill status\") introduced a dereference of the phys array indirectly indexed by band_idx via wcid->phy_idx in mt76_wcid_cleanup(). This caused the following Oops on affected mt7986 devices: Unable to handle kernel read from unreadable memory at virtual address 0000000000000024 Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x00000005 CM = 0, WnR = 0 user pgtable: 4k pages, 39-bit VAs, pgdp=0000000042545000 [0000000000000024] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 Internal error: Oops: 0000000096000005 [#1] SMP Modules linked in: ... mt7915e mt76_connac_lib mt76 mac80211 cfg80211 ... CPU: 2 PID: 1631 Comm: hostapd Not tainted 5.15.150 #0 Hardware name: ZyXEL EX5700 (Telenor) (DT) pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mt76_wcid_cleanup+0x84/0x22c [mt76] lr : mt76_wcid_cleanup+0x64/0x22c [mt76] sp : ffffffc00a803700 x29: ffffffc00a803700 x28: ffffff80008f7300 x27: ffffff80003f3c00 x26: ffffff80000a7880 x25: ffffffc008c26e00 x24: 0000000000000001 x23: ffffffc000a68114 x22: 0000000000000000 x21: ffffff8004172cc8 x20: ffffffc00a803748 x19: ffffff8004152020 x18: 0000000000000000 x17: 00000000000017c0 x16: ffffffc008ef5000 x15: 0000000000000be0 x14: ffffff8004172e28 x13: ffffff8004172e28 x12: 0000000000000000 x11: 0000000000000000 x10: ffffff8004172e30 x9 : ffffff8004172e28 x8 : 0000000000000000 x7 : ffffff8004156020 x6 : 0000000000000000 x5 : 0000000000000031 x4 : 0000000000000000 x3 : 0000000000000001 x2 : 0000000000000000 x1 : ffffff80008f7300 x0 : 0000000000000024 Call trace: mt76_wcid_cleanup+0x84/0x22c [mt76] __mt76_sta_remove+0x70/0xbc [mt76] mt76_sta_state+0x8c/0x1a4 [mt76] mt7915_eeprom_get_power_delta+0x11e4/0x23a0 [mt7915e] drv_sta_state+0x144/0x274 [mac80211] sta_info_move_state+0x1cc/0x2a4 [mac80211] sta_set_sinfo+0xaf8/0xc24 [mac80211] sta_info_destroy_addr_bss+0x4c/0x6c [mac80211] ieee80211_color_change_finish+0x1c08/0x1e70 [mac80211] cfg80211_check_station_change+0x1360/0x4710 [cfg80211] genl_family_rcv_msg_doit+0xb4/0x110 genl_rcv_msg+0xd0/0x1bc netlink_rcv_skb+0x58/0x120 genl_rcv+0x34/0x50 netlink_unicast+0x1f0/0x2ec netlink_sendmsg+0x198/0x3d0 ____sys_sendmsg+0x1b0/0x210 ___sys_sendmsg+0x80/0xf0 __sys_sendmsg+0x44/0xa0 __arm64_sys_sendmsg+0x20/0x30 invoke_syscall.constprop.0+0x4c/0xe0 do_el0_svc+0x40/0xd0 el0_svc+0x14/0x4c el0t_64_sync_handler+0x100/0x110 el0t_64_sync+0x15c/0x160 Code: d2800002 910092c0 52800023 f9800011 (885f7c01) ---[ end trace 7e42dd9a39ed2281 ]--- Fix by using mt76_dev_phy() which will map band_idx to the correct phy for all hardware combinations.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49857", "url": "https://ubuntu.com/security/CVE-2024-49857", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: set the cipher for secured NDP ranging The cipher pointer is not set, but is derefereced trying to set its content, which leads to a NULL pointer dereference. Fix it by pointing to the cipher parameter before dereferencing.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47738", "url": "https://ubuntu.com/security/CVE-2024-47738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: don't use rate mask for offchannel TX either Like the commit ab9177d83c04 (\"wifi: mac80211: don't use rate mask for scanning\"), ignore incorrect settings to avoid no supported rate warning reported by syzbot. The syzbot did bisect and found cause is commit 9df66d5b9f45 (\"cfg80211: fix default HE tx bitrate mask in 2G band\"), which however corrects bitmask of HE MCS and recognizes correctly settings of empty legacy rate plus HE MCS rate instead of returning -EINVAL. As suggestions [1], follow the change of SCAN TX to consider this case of offchannel TX as well. [1] https://lore.kernel.org/linux-wireless/6ab2dc9c3afe753ca6fdcdd1421e7a1f47e87b84.camel@sipsolutions.net/T/#m2ac2a6d2be06a37c9c47a3d8a44b4f647ed4f024", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47731", "url": "https://ubuntu.com/security/CVE-2024-47731", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers/perf: Fix ali_drw_pmu driver interrupt status clearing The alibaba_uncore_pmu driver forgot to clear all interrupt status in the interrupt processing function. After the PMU counter overflow interrupt occurred, an interrupt storm occurred, causing the system to hang. Therefore, clear the correct interrupt status in the interrupt handling function to fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49862", "url": "https://ubuntu.com/security/CVE-2024-49862", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powercap: intel_rapl: Fix off by one in get_rpi() The rp->priv->rpi array is either rpi_msr or rpi_tpmi which have NR_RAPL_PRIMITIVES number of elements. Thus the > needs to be >= to prevent an off by one access.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47716", "url": "https://ubuntu.com/security/CVE-2024-47716", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: 9410/1: vfp: Use asm volatile in fmrx/fmxr macros Floating point instructions in userspace can crash some arm kernels built with clang/LLD 17.0.6: BUG: unsupported FP instruction in kernel mode FPEXC == 0xc0000780 Internal error: Oops - undefined instruction: 0 [#1] ARM CPU: 0 PID: 196 Comm: vfp-reproducer Not tainted 6.10.0 #1 Hardware name: BCM2835 PC is at vfp_support_entry+0xc8/0x2cc LR is at do_undefinstr+0xa8/0x250 pc : [] lr : [] psr: a0000013 sp : dc8d1f68 ip : 60000013 fp : bedea19c r10: ec532b17 r9 : 00000010 r8 : 0044766c r7 : c0000780 r6 : ec532b17 r5 : c1c13800 r4 : dc8d1fb0 r3 : c10072c4 r2 : c0101c88 r1 : ec532b17 r0 : 0044766c Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 00c5387d Table: 0251c008 DAC: 00000051 Register r0 information: non-paged memory Register r1 information: vmalloc memory Register r2 information: non-slab/vmalloc memory Register r3 information: non-slab/vmalloc memory Register r4 information: 2-page vmalloc region Register r5 information: slab kmalloc-cg-2k Register r6 information: vmalloc memory Register r7 information: non-slab/vmalloc memory Register r8 information: non-paged memory Register r9 information: zero-size pointer Register r10 information: vmalloc memory Register r11 information: non-paged memory Register r12 information: non-paged memory Process vfp-reproducer (pid: 196, stack limit = 0x61aaaf8b) Stack: (0xdc8d1f68 to 0xdc8d2000) 1f60: 0000081f b6f69300 0000000f c10073f4 c10072c4 dc8d1fb0 1f80: ec532b17 0c532b17 0044766c b6f9ccd8 00000000 c010a80c 00447670 60000010 1fa0: ffffffff c1c13800 00c5387d c0100f10 b6f68af8 00448fc0 00000000 bedea188 1fc0: bedea314 00000001 00448ebc b6f9d000 00447608 b6f9ccd8 00000000 bedea19c 1fe0: bede9198 bedea188 b6e1061c 0044766c 60000010 ffffffff 00000000 00000000 Call trace: [] (vfp_support_entry) from [] (do_undefinstr+0xa8/0x250) [] (do_undefinstr) from [] (__und_usr+0x70/0x80) Exception stack(0xdc8d1fb0 to 0xdc8d1ff8) 1fa0: b6f68af8 00448fc0 00000000 bedea188 1fc0: bedea314 00000001 00448ebc b6f9d000 00447608 b6f9ccd8 00000000 bedea19c 1fe0: bede9198 bedea188 b6e1061c 0044766c 60000010 ffffffff Code: 0a000061 e3877202 e594003c e3a09010 (eef16a10) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Fatal exception in interrupt ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]--- This is a minimal userspace reproducer on a Raspberry Pi Zero W: #include #include int main(void) { double v = 1.0; printf(\"%fn\", NAN + *(volatile double *)&v); return 0; } Another way to consistently trigger the oops is: calvin@raspberry-pi-zero-w ~$ python -c \"import json\" The bug reproduces only when the kernel is built with DYNAMIC_DEBUG=n, because the pr_debug() calls act as barriers even when not activated. This is the output from the same kernel source built with the same compiler and DYNAMIC_DEBUG=y, where the userspace reproducer works as expected: VFP: bounce: trigger ec532b17 fpexc c0000780 VFP: emulate: INST=0xee377b06 SCR=0x00000000 VFP: bounce: trigger eef1fa10 fpexc c0000780 VFP: emulate: INST=0xeeb40b40 SCR=0x00000000 VFP: raising exceptions 30000000 calvin@raspberry-pi-zero-w ~$ ./vfp-reproducer nan Crudely grepping for vmsr/vmrs instructions in the otherwise nearly idential text for vfp_support_entry() makes the problem obvious: vmlinux.llvm.good [0xc0101cb8] <+48>: vmrs r7, fpexc vmlinux.llvm.good [0xc0101cd8] <+80>: vmsr fpexc, r0 vmlinux.llvm.good [0xc0101d20 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47717", "url": "https://ubuntu.com/security/CVE-2024-47717", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RISC-V: KVM: Don't zero-out PMU snapshot area before freeing data With the latest Linux-6.11-rc3, the below NULL pointer crash is observed when SBI PMU snapshot is enabled for the guest and the guest is forcefully powered-off. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000508 Oops [#1] Modules linked in: kvm CPU: 0 UID: 0 PID: 61 Comm: term-poll Not tainted 6.11.0-rc3-00018-g44d7178dd77a #3 Hardware name: riscv-virtio,qemu (DT) epc : __kvm_write_guest_page+0x94/0xa6 [kvm] ra : __kvm_write_guest_page+0x54/0xa6 [kvm] epc : ffffffff01590e98 ra : ffffffff01590e58 sp : ffff8f80001f39b0 gp : ffffffff81512a60 tp : ffffaf80024872c0 t0 : ffffaf800247e000 t1 : 00000000000007e0 t2 : 0000000000000000 s0 : ffff8f80001f39f0 s1 : 00007fff89ac4000 a0 : ffffffff015dd7e8 a1 : 0000000000000086 a2 : 0000000000000000 a3 : ffffaf8000000000 a4 : ffffaf80024882c0 a5 : 0000000000000000 a6 : ffffaf800328d780 a7 : 00000000000001cc s2 : ffffaf800197bd00 s3 : 00000000000828c4 s4 : ffffaf800248c000 s5 : ffffaf800247d000 s6 : 0000000000001000 s7 : 0000000000001000 s8 : 0000000000000000 s9 : 00007fff861fd500 s10: 0000000000000001 s11: 0000000000800000 t3 : 00000000000004d3 t4 : 00000000000004d3 t5 : ffffffff814126e0 t6 : ffffffff81412700 status: 0000000200000120 badaddr: 0000000000000508 cause: 000000000000000d [] __kvm_write_guest_page+0x94/0xa6 [kvm] [] kvm_vcpu_write_guest+0x56/0x90 [kvm] [] kvm_pmu_clear_snapshot_area+0x42/0x7e [kvm] [] kvm_riscv_vcpu_pmu_deinit.part.0+0xe0/0x14e [kvm] [] kvm_riscv_vcpu_pmu_deinit+0x1a/0x24 [kvm] [] kvm_arch_vcpu_destroy+0x28/0x4c [kvm] [] kvm_destroy_vcpus+0x5a/0xda [kvm] [] kvm_arch_destroy_vm+0x14/0x28 [kvm] [] kvm_destroy_vm+0x168/0x2a0 [kvm] [] kvm_put_kvm+0x3c/0x58 [kvm] [] kvm_vm_release+0x22/0x2e [kvm] Clearly, the kvm_vcpu_write_guest() function is crashing because it is being called from kvm_pmu_clear_snapshot_area() upon guest tear down. To address the above issue, simplify the kvm_pmu_clear_snapshot_area() to not zero-out PMU snapshot area from kvm_pmu_clear_snapshot_area() because the guest is anyway being tore down. The kvm_pmu_clear_snapshot_area() is also called when guest changes PMU snapshot area of a VCPU but even in this case the previous PMU snaphsot area must not be zeroed-out because the guest might have reclaimed the pervious PMU snapshot area for some other purpose.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47721", "url": "https://ubuntu.com/security/CVE-2024-47721", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: remove unused C2H event ID RTW89_MAC_C2H_FUNC_READ_WOW_CAM to prevent out-of-bounds reading The handler of firmware C2H event RTW89_MAC_C2H_FUNC_READ_WOW_CAM isn't implemented, but driver expects number of handlers is NUM_OF_RTW89_MAC_C2H_FUNC_WOW causing out-of-bounds access. Fix it by removing ID. Addresses-Coverity-ID: 1598775 (\"Out-of-bounds read\")", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47732", "url": "https://ubuntu.com/security/CVE-2024-47732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: iaa - Fix potential use after free bug The free_device_compression_mode(iaa_device, device_mode) function frees \"device_mode\" but it iss passed to iaa_compression_modes[i]->free() a few lines later resulting in a use after free. The good news is that, so far as I can tell, nothing implements the ->free() function and the use after free happens in dead code. But, with this fix, when something does implement it, we'll be ready. :)", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47718", "url": "https://ubuntu.com/security/CVE-2024-47718", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: always wait for both firmware loading attempts In 'rtw_wait_firmware_completion()', always wait for both (regular and wowlan) firmware loading attempts. Otherwise if 'rtw_usb_intf_init()' has failed in 'rtw_usb_probe()', 'rtw_usb_disconnect()' may issue 'ieee80211_free_hw()' when one of 'rtw_load_firmware_cb()' (usually the wowlan one) is still in progress, causing UAF detected by KASAN.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47724", "url": "https://ubuntu.com/security/CVE-2024-47724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: use work queue to process beacon tx event Commit 3a415daa3e8b (\"wifi: ath11k: add P2P IE in beacon template\") from Feb 28, 2024 (linux-next), leads to the following Smatch static checker warning: drivers/net/wireless/ath/ath11k/wmi.c:1742 ath11k_wmi_p2p_go_bcn_ie() warn: sleeping in atomic context The reason is that ath11k_bcn_tx_status_event() will directly call might sleep function ath11k_wmi_cmd_send() during RCU read-side critical sections. The call trace is like: ath11k_bcn_tx_status_event() -> rcu_read_lock() -> ath11k_mac_bcn_tx_event() \t-> ath11k_mac_setup_bcn_tmpl() \t…… \t\t-> ath11k_wmi_bcn_tmpl() \t\t\t-> ath11k_wmi_cmd_send() -> rcu_read_unlock() Commit 886433a98425 (\"ath11k: add support for BSS color change\") added the ath11k_mac_bcn_tx_event(), commit 01e782c89108 (\"ath11k: fix warning of RCU usage for ath11k_mac_get_arvif_by_vdev_id()\") added the RCU lock to avoid warning but also introduced this BUG. Use work queue to avoid directly calling ath11k_mac_bcn_tx_event() during RCU critical sections. No need to worry about the deletion of vif because cancel_work_sync() will drop the work if it doesn't start or block vif deletion until the running work is done. 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": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47671", "url": "https://ubuntu.com/security/CVE-2024-47671", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: usbtmc: prevent kernel-usb-infoleak The syzbot reported a kernel-usb-infoleak in usbtmc_write, we need to clear the structure before filling fields.", "cve_priority": "medium", "cve_public_date": "2024-10-09 15:15:00 UTC" }, { "cve": "CVE-2024-46869", "url": "https://ubuntu.com/security/CVE-2024-46869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btintel_pcie: Allocate memory for driver private data Fix driver not allocating memory for struct btintel_data which is used to store internal data.", "cve_priority": "medium", "cve_public_date": "2024-09-30 16:15:00 UTC" }, { "cve": "CVE-2024-53164", "url": "https://ubuntu.com/security/CVE-2024-53164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: fix ordering of qlen adjustment Changes to sch->q.qlen around qdisc_tree_reduce_backlog() need to happen _before_ a call to said function because otherwise it may fail to notify parent qdiscs when the child is about to become empty.", "cve_priority": "medium", "cve_public_date": "2024-12-27 14:15:00 UTC" }, { "cve": "CVE-2024-53103", "url": "https://ubuntu.com/security/CVE-2024-53103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hv_sock: Initializing vsk->trans to NULL to prevent a dangling pointer When hvs is released, there is a possibility that vsk->trans may not be initialized to NULL, which could lead to a dangling pointer. This issue is resolved by initializing vsk->trans to NULL.", "cve_priority": "high", "cve_public_date": "2024-12-02 08:15:00 UTC" } ], "log": [ "", " * oracular/linux: 6.11.0-17.17 -proposed tracker (LP: #2093643)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/2025.01.13)", "", " * When /dev/vmbus/hv_kvp is not present, disable hv-kvp-daemon (LP: #2091744)", " - [Packaging] disable hv-kvp-daemon if needed", "", " * Backport \"netkit: Add option for scrubbing skb meta data\" to 6.8", " (LP: #2091184)", " - netkit: Add option for scrubbing skb meta data", "", " * KVM: Cache CPUID at KVM.ko module init to reduce latency of VM-Enter and VM-", " Exit (LP: #2093146)", " - KVM: x86: Cache CPUID.0xD XSTATE offsets+sizes during module init", "", " * [SRU] add support of QCA BT 0489:e0fc (LP: #2085406)", " - Bluetooth: btusb: add Foxconn 0xe0fc for Qualcomm WCN785x", "", " * oracular: ubuntu_boot lib/dynamic_queue_limits.c:99! (LP: #2089684)", " - virtio_net: correct netdev_tx_reset_queue() invocation point", " - virtio_ring: add a func argument 'recycle_done' to virtqueue_resize()", " - virtio_net: ensure netdev_tx_reset_queue is called on tx ring resize", "", " * Failed to probe for OVTI02C1: chip id mismatch: 560243!=0 (LP: #2090932)", " - SAUCE: ACPI: scan: Update HID for new platform", "", " * Bluetooth[8086:a876] crash with \"hci0: Failed to read MSFT supported", " features (-110)\" (LP: #2085485)", " - Bluetooth: btintel_pcie: Add recovery mechanism", "", " * Poor bluetooth performance on Lenovo X13s (LP: #2089357)", " - SAUCE: Bluetooth: qca: Support downloading board ID specific NVM for WCN6855", "", " * vfio_pci soft lockup on VM start while using PCIe passthrough (LP: #2089306)", " - SAUCE: Revert \"mm: use rwsem assertion macros for mmap_lock\"", " - SAUCE: Revert \"vfio/pci: Insert full vma on mmap'd MMIO fault\"", " - SAUCE: Revert \"vfio/pci: Use unmap_mapping_range()\"", "", " * Oracular update: v6.11.11 upstream stable release (LP: #2091655)", " - wifi: mac80211: Fix setting txpower with emulate_chanctx", " - wifi: cfg80211: Add wiphy_delayed_work_pending()", " - wifi: mac80211: Convert color collision detection to wiphy work", " - wifi: radiotap: Avoid -Wflex-array-member-not-at-end warnings", " - spi: stm32: fix missing device mode capability in stm32mp25", " - ASoC: codecs: rt5640: Always disable IRQs from rt5640_cancel_work()", " - ASoC: Intel: bytcr_rt5640: Add support for non ACPI instantiated codec", " - ASoC: Intel: bytcr_rt5640: Add DMI quirk for Vexia Edu Atla 10 tablet", " - ASoC: Intel: sst: Support LPE0F28 ACPI HID", " - wifi: iwlwifi: mvm: Use the sync timepoint API in suspend", " - wifi: iwlwifi: mvm: SAR table alignment", " - mac80211: fix user-power when emulating chanctx", " - usb: add support for new USB device ID 0x17EF:0x3098 for the r8152 driver", " - usb: typec: use cleanup facility for 'altmodes_node'", " - selftests/watchdog-test: Fix system accidentally reset after watchdog-test", " - ALSA: hda/realtek: Add subwoofer quirk for Infinix ZERO BOOK 13", " - ASoC: codecs: wcd937x: add missing LO Switch control", " - ASoC: codecs: wcd937x: relax the AUX PDM watchdog", " - x86/amd_nb: Fix compile-testing without CONFIG_AMD_NB", " - bpf: fix filed access without lock", " - net: usb: qmi_wwan: add Quectel RG650V", " - soc: qcom: Add check devm_kasprintf() returned value", " - firmware: arm_scmi: Reject clear channel request on A2P", " - regulator: rk808: Add apply_bit for BUCK3 on RK809", " - platform/x86: dell-smbios-base: Extends support to Alienware products", " - platform/x86: dell-wmi-base: Handle META key Lock/Unlock events", " - platform/x86: ideapad-laptop: add missing Ideapad Pro 5 fn keys", " - ASoC: tas2781: Add new driver version for tas2563 & tas2781 qfn chip", " - tools/lib/thermal: Remove the thermal.h soft link when doing make clean", " - can: j1939: fix error in J1939 documentation.", " - platform/x86: thinkpad_acpi: Fix for ThinkPad's with ECFW showing incorrect", " fan speed", " - ASoC: amd: yc: Support dmic on another model of Lenovo Thinkpad E14 Gen 6", " - ASoC: stm: Prevent potential division by zero in stm32_sai_mclk_round_rate()", " - ASoC: stm: Prevent potential division by zero in stm32_sai_get_clk_div()", " - drm: panel-orientation-quirks: Make Lenovo Yoga Tab 3 X90F DMI match less", " strict", " - proc/softirqs: replace seq_printf with seq_put_decimal_ull_width", " - integrity: Use static_assert() to check struct sizes", " - ASoC: audio-graph-card2: Purge absent supplies for device tree nodes", " - LoongArch: For all possible CPUs setup logical-physical CPU mapping", " - LoongArch: Define a default value for VM_DATA_DEFAULT_FLAGS", " - ASoC: max9768: Fix event generation for playback mute", " - ALSA: usb-audio: Fix Yamaha P-125 Quirk Entry", " - ARM: 9420/1: smp: Fix SMP for xip kernels", " - ARM: 9434/1: cfi: Fix compilation corner case", " - ipmr: Fix access to mfc_cache_list without lock held", " - f2fs: fix fiemap failure issue when page size is 16KB", " - drm/amd/display: Skip Invalid Streams from DSC Policy", " - drm/amd/display: Fix incorrect DSC recompute trigger", " - s390/facilities: Fix warning about shadow of global variable", " - efs: fix the efs new mount api implementation", " - arm64: probes: Disable kprobes/uprobes on MOPS instructions", " - kselftest/arm64: hwcap: fix f8dp2 cpuinfo name", " - kselftest/arm64: mte: fix printf type warnings about __u64", " - kselftest/arm64: mte: fix printf type warnings about longs", " - block/fs: Pass an iocb to generic_atomic_write_valid()", " - fs/block: Check for IOCB_DIRECT in generic_atomic_write_valid()", " - s390/cio: Do not unregister the subchannel based on DNV", " - s390/pageattr: Implement missing kernel_page_present()", " - x86/pvh: Set phys_base when calling xen_prepare_pvh()", " - x86/pvh: Call C code via the kernel virtual mapping", " - brd: defer automatic disk creation until module initialization succeeds", " - ext4: avoid remount errors with 'abort' mount option", " - mips: asm: fix warning when disabling MIPS_FP_SUPPORT", " - arm64: Expose ID_AA64ISAR1_EL1.XS to sanitised feature consumers", " - kselftest/arm64: Fix encoding for SVE B16B16 test", " - nvme-pci: fix freeing of the HMB descriptor table", " - m68k: mvme147: Fix SCSI controller IRQ numbers", " - m68k: mvme147: Reinstate early console", " - arm64: fix .data.rel.ro size assertion when CONFIG_LTO_CLANG", " - acpi/arm64: Adjust error handling procedure in gtdt_parse_timer_block()", " - loop: fix type of block size", " - cachefiles: Fix incorrect length return value in", " cachefiles_ondemand_fd_write_iter()", " - cachefiles: Fix missing pos updates in cachefiles_ondemand_fd_write_iter()", " - cachefiles: Fix NULL pointer dereference in object->file", " - netfs/fscache: Add a memory barrier for FSCACHE_VOLUME_CREATING", " - block: constify the lim argument to queue_limits_max_zone_append_sectors", " - block: properly handle REQ_OP_ZONE_APPEND in __bio_split_to_limits", " - block: take chunk_sectors into account in bio_split_write_zeroes", " - block: fix bio_split_rw_at to take zone_write_granularity into account", " - s390/syscalls: Avoid creation of arch/arch/ directory", " - hfsplus: don't query the device logical block size multiple times", " - ext4: pipeline buffer reads in mext_page_mkuptodate()", " - ext4: remove array of buffer_heads from mext_page_mkuptodate()", " - ext4: fix race in buffer_head read fault injection", " - nvme-pci: reverse request order in nvme_queue_rqs", " - virtio_blk: reverse request order in virtio_queue_rqs", " - crypto: mxs-dcp - Fix AES-CBC with hardware-bound keys", " - crypto: caam - Fix the pointer passed to caam_qi_shutdown()", " - crypto: qat - remove check after debugfs_create_dir()", " - crypto: qat/qat_420xx - fix off by one in uof_get_name()", " - crypto: qat/qat_4xxx - fix off by one in uof_get_name()", " - firmware: google: Unregister driver_info on failure", " - EDAC/bluefield: Fix potential integer overflow", " - crypto: qat - remove faulty arbiter config reset", " - thermal: core: Initialize thermal zones before registering them", " - thermal: core: Drop thermal_zone_device_is_enabled()", " - thermal: core: Rearrange PM notification code", " - thermal: core: Represent suspend-related thermal zone flags as bits", " - thermal: core: Mark thermal zones as initializing to start with", " - thermal: core: Fix race between zone registration and system suspend", " - EDAC/fsl_ddr: Fix bad bit shift operations", " - EDAC/skx_common: Differentiate memory error sources", " - EDAC/{skx_common,i10nm}: Fix incorrect far-memory error source indicator", " - crypto: pcrypt - Call crypto layer directly when padata_do_parallel() return", " -EBUSY", " - crypto: cavium - Fix the if condition to exit loop after timeout", " - cpufreq/amd-pstate: Don't update CPPC request in", " amd_pstate_cpu_boost_update()", " - amd-pstate: Set min_perf to nominal_perf for active mode performance gov", " - crypto: hisilicon/qm - disable same error report before resetting", " - EDAC/igen6: Avoid segmentation fault on module unload", " - crypto: qat - Fix missing destroy_workqueue in adf_init_aer()", " - crypto: inside-secure - Fix the return value of safexcel_xcbcmac_cra_init()", " - sched/cpufreq: Ensure sd is rebuilt for EAS check", " - doc: rcu: update printed dynticks counter bits", " - rcu/srcutiny: don't return before reenabling preemption", " - rcu/kvfree: Fix data-race in __mod_timer / kvfree_call_rcu", " - hwmon: (pmbus/core) clear faults after setting smbalert mask", " - hwmon: (nct6775-core) Fix overflows seen when writing limit attributes", " - ACPI: CPPC: Fix _CPC register setting issue", " - crypto: caam - add error check to caam_rsa_set_priv_key_form", " - crypto: bcm - add error check in the ahash_hmac_init function", " - crypto: cavium - Fix an error handling path in cpt_ucode_load_fw()", " - rcuscale: Do a proper cleanup if kfree_scale_init() fails", " - tools/lib/thermal: Make more generic the command encoding function", " - thermal/lib: Fix memory leak on error in thermal_genl_auto()", " - x86/unwind/orc: Fix unwind for newly forked tasks", " - Revert \"scripts/faddr2line: Check only two symbols when calculating symbol", " size\"", " - cleanup: Remove address space of returned pointer", " - time: Partially revert cleanup on msecs_to_jiffies() documentation", " - time: Fix references to _msecs_to_jiffies() handling of values", " - locking/atomic/x86: Use ALT_OUTPUT_SP() for __alternative_atomic64()", " - locking/atomic/x86: Use ALT_OUTPUT_SP() for __arch_{,try_}cmpxchg64_emu()", " - kcsan, seqlock: Support seqcount_latch_t", " - kcsan, seqlock: Fix incorrect assumption in read_seqbegin()", " - clocksource/drivers:sp804: Make user selectable", " - clocksource/drivers/timer-ti-dm: Fix child node refcount handling", " - regulator: qcom-smd: make smd_vreg_rpm static", " - spi: spi-fsl-lpspi: Use IRQF_NO_AUTOEN flag in request_irq()", " - arm64: dts: qcom: qcs6390-rb3gen2: use modem.mbn for modem DSP", " - ARM: dts: renesas: genmai: Fix partition size for QSPI NOR Flash", " - drivers: soc: xilinx: add the missing kfree in xlnx_add_cb_for_suspend()", " - microblaze: Export xmb_manager functions", " - arm64: dts: mediatek: mt8188: Fix wrong clock provider in MFG1 power domain", " - arm64: dts: mediatek: mt8395-genio-1200-evk: Fix dtbs_check error for phy", " - arm64: dts: mt8195: Fix dtbs_check error for mutex node", " - arm64: dts: mt8195: Fix dtbs_check error for infracfg_ao node", " - soc: ti: smartreflex: Use IRQF_NO_AUTOEN flag in request_irq()", " - soc: qcom: geni-se: fix array underflow in geni_se_clk_tbl_get()", " - arm64: dts: qcom: sm6350: Fix GPU frequencies missing on some speedbins", " - arm64: dts: qcom: sda660-ifc6560: fix l10a voltage ranges", " - ARM: dts: microchip: sam9x60: Add missing property atmel,usart-mode", " - mmc: mmc_spi: drop buggy snprintf()", " - scripts/kernel-doc: Do not track section counter across processed files", " - arm64: dts: qcom: x1e80100-slim7x: Drop orientation-switch from USB SS[0-1]", " QMP PHYs", " - arm64: dts: qcom: x1e80100-vivobook-s15: Drop orientation-switch from USB", " SS[0-1] QMP PHYs", " - openrisc: Implement fixmap to fix earlycon", " - efi/libstub: fix efi_parse_options() ignoring the default command line", " - tpm: fix signed/unsigned bug when checking event logs", " - media: i2c: vgxy61: Fix an error handling path in vgxy61_detect()", " - media: i2c: ds90ub960: Fix missing return check on ub960_rxport_read call", " - arm64: dts: mt8183: krane: Fix the address of eeprom at i2c4", " - arm64: dts: mt8183: kukui: Fix the address of eeprom at i2c4", " - arm64: dts: qcom: x1e80100: Resize GIC Redistributor register region", " - kernel-doc: allow object-like macros in ReST output", " - arm64: dts: ti: k3-am62x-phyboard-lyra: Drop unnecessary McASP AFIFOs", " - arm64: dts: mediatek: mt8173-elm-hana: Add vdd-supply to second source", " trackpad", " - arm64: dts: mediatek: mt8188: Fix USB3 PHY port default status", " - arm64: dts: mediatek: mt8195-cherry: Use correct audio codec DAI", " - Revert \"cgroup: Fix memory leak caused by missing cgroup_bpf_offline\"", " - cgroup/bpf: only cgroup v2 can be attached by bpf programs", " - regulator: rk808: Restrict DVS GPIOs to the RK808 variant only", " - power: sequencing: make the QCom PMU pwrseq driver depend on CONFIG_OF", " - [Config] updateconfigs for POWER_SEQUENCING_QCOM_WCN", " - arm64: dts: rockchip: Remove 'enable-active-low' from two boards", " - arm64: dts: mt8183: fennel: add i2c2's i2c-scl-internal-delay-ns", " - arm64: dts: mt8183: burnet: add i2c2's i2c-scl-internal-delay-ns", " - arm64: dts: mt8183: cozmo: add i2c2's i2c-scl-internal-delay-ns", " - arm64: dts: mt8183: Damu: add i2c2's i2c-scl-internal-delay-ns", " - pwm: imx27: Workaround of the pwm output bug when decrease the duty cycle", " - ARM: dts: cubieboard4: Fix DCDC5 regulator constraints", " - arm64: dts: ti: k3-j7200: Fix register map for main domain pmx", " - arm64: dts: ti: k3-j7200: Fix clock ids for MCSPI instances", " - arm64: dts: ti: k3-j721e: Fix clock IDs for MCSPI instances", " - arm64: dts: ti: k3-j721s2: Fix clock IDs for MCSPI instances", " - watchdog: Add HAS_IOPORT dependency for SBC8360 and SBC7240", " - arm64: dts: qcom: x1e80100: Update C4/C5 residency/exit numbers", " - dt-bindings: cache: qcom,llcc: Fix X1E80100 reg entries", " - of/fdt: add dt_phys arg to early_init_dt_scan and early_init_dt_verify", " - pmdomain: ti-sci: Add missing of_node_put() for args.np", " - spi: tegra210-quad: Avoid shift-out-of-bounds", " - spi: zynqmp-gqspi: Undo runtime PM changes at driver exit time​", " - regmap: irq: Set lockdep class for hierarchical IRQ domains", " - arm64: dts: renesas: hihope: Drop #sound-dai-cells", " - arm64: dts: imx8mn-tqma8mqnl-mba8mx-usbot: fix coexistence of output-low and", " output-high in GPIO", " - arm64: dts: mediatek: Add ADC node on MT6357, MT6358, MT6359 PMICs", " - arm64: dts: mediatek: mt6358: fix dtbs_check error", " - arm64: dts: mediatek: mt8183-kukui-jacuzzi: Fix DP bridge supply names", " - arm64: dts: mediatek: mt8183-kukui-jacuzzi: Add supplies for fixed", " regulators", " - selftests/resctrl: Print accurate buffer size as part of MBM results", " - selftests/resctrl: Fix memory overflow due to unhandled wraparound", " - selftests/resctrl: Protect against array overrun during iMC config parsing", " - firmware: arm_scpi: Check the DVFS OPP count returned by the firmware", " - media: ipu6: Fix DMA and physical address debugging messages for 32-bit", " - media: ipu6: not override the dma_ops of device in driver", " - pwm: Assume a disabled PWM to emit a constant inactive output", " - media: atomisp: Add check for rgby_data memory allocation failure", " - arm64: dts: rockchip: correct analog audio name on Indiedroid Nova", " - HID: hyperv: streamline driver probe to avoid devres issues", " - platform/x86: panasonic-laptop: Return errno correctly in show callback", " - drm/imagination: Convert to use time_before macro", " - drm/imagination: Use pvr_vm_context_get()", " - drm/mm: Mark drm_mm_interval_tree*() functions with __maybe_unused", " - drm/vc4: hvs: Don't write gamma luts on 2711", " - drm/vc4: hdmi: Avoid hang with debug registers when suspended", " - drm/vc4: hvs: Fix dlist debug not resetting the next entry pointer", " - drm/vc4: hvs: Remove incorrect limit from hvs_dlist debugfs function", " - drm/vc4: hvs: Correct logic on stopping an HVS channel", " - wifi: ath9k: add range check for conn_rsp_epid in htc_connect_service()", " - drm/omap: Fix possible NULL dereference", " - drm/omap: Fix locking in omap_gem_new_dmabuf()", " - drm/v3d: Appease lockdep while updating GPU stats", " - wifi: p54: Use IRQF_NO_AUTOEN flag in request_irq()", " - wifi: mwifiex: Use IRQF_NO_AUTOEN flag in request_irq()", " - udmabuf: change folios array from kmalloc to kvmalloc", " - udmabuf: fix vmap_udmabuf error page set", " - [Config] updateconfigs for VMAP_PFN", " - drm/imx/dcss: Use IRQF_NO_AUTOEN flag in request_irq()", " - drm/imx/ipuv3: Use IRQF_NO_AUTOEN flag in request_irq()", " - drm/panel: nt35510: Make new commands optional", " - drm/v3d: Address race-condition in MMU flush", " - drm/v3d: Flush the MMU before we supply more memory to the binner", " - drm/amdgpu: Fix JPEG v4.0.3 register write", " - wifi: ath10k: fix invalid VHT parameters in supported_vht_mcs_rate_nss1", " - wifi: ath10k: fix invalid VHT parameters in supported_vht_mcs_rate_nss2", " - wifi: ath12k: Skip Rx TID cleanup for self peer", " - dt-bindings: vendor-prefixes: Add NeoFidelity, Inc", " - ASoC: fsl_micfil: fix regmap_write_bits usage", " - ASoC: dt-bindings: mt6359: Update generic node name and dmic-mode", " - ASoC: fsl-asoc-card: Add missing handling of {hp,mic}-dt-gpios", " - drm/bridge: anx7625: Drop EDID cache on bridge power off", " - drm/bridge: it6505: Drop EDID cache on bridge power off", " - libbpf: Fix expected_attach_type set handling in program load callback", " - libbpf: Fix output .symtab byte-order during linking", " - dlm: fix swapped args sb_flags vs sb_status", " - wifi: rtl8xxxu: Perform update_beacon_work when beaconing is enabled", " - drm/amd/display: fix a memleak issue when driver is removed", " - wifi: ath12k: fix use-after-free in ath12k_dp_cc_cleanup()", " - wifi: ath12k: fix one more memcpy size error", " - bpf: Fix the xdp_adjust_tail sample prog issue", " - selftests/bpf: netns_new() and netns_free() helpers.", " - selftests/bpf: Fix backtrace printing for selftests crashes", " - wifi: ath11k: Fix CE offset address calculation for WCN6750 in SSR", " - selftests/bpf: add missing header include for htons", " - wifi: cfg80211: check radio iface combination for multi radio per wiphy", " - ice: consistently use q_idx in ice_vc_cfg_qs_msg()", " - drm/vc4: hdmi: Increase audio MAI fifo dreq threshold", " - drm/vc4: Introduce generation number enum", " - drm/vc4: Match drm_dev_enter and exit calls in vc4_hvs_lut_load", " - drm/vc4: Match drm_dev_enter and exit calls in vc4_hvs_atomic_flush", " - drm/vc4: Correct generation check in vc4_hvs_lut_load", " - libbpf: fix sym_is_subprog() logic for weak global subprogs", " - accel/ivpu: Prevent recovery invocation during probe and resume", " - ASoC: rt722-sdca: Remove logically deadcode in rt722-sdca.c", " - libbpf: never interpret subprogs in .text as entry programs", " - netdevsim: copy addresses for both in and out paths", " - drm/bridge: tc358767: Fix link properties discovery", " - selftests/bpf: Fix msg_verify_data in test_sockmap", " - selftests/bpf: Fix txmsg_redir of test_txmsg_pull in test_sockmap", " - wifi: wilc1000: Set MAC after operation mode", " - wifi: mwifiex: Fix memcpy() field-spanning write warning in", " mwifiex_config_scan()", " - drm: fsl-dcu: enable PIXCLK on LS1021A", " - drm: panel: nv3052c: correct spi_device_id for RG35XX panel", " - drm/msm/dpu: on SDM845 move DSPP_3 to LM_5 block", " - drm/msm/dpu: drop LM_3 / LM_4 on SDM845", " - drm/msm/dpu: drop LM_3 / LM_4 on MSM8998", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_common.c", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_ethtool.c", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_flows.c", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in cn10k.c", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dmac_flt.c", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dcbnl.c", " - selftests/bpf: fix test_spin_lock_fail.c's global vars usage", " - libbpf: move global data mmap()'ing into bpf_object__load()", " - drm/panfrost: Remove unused id_mask from struct panfrost_model", " - bpf, arm64: Remove garbage frame for struct_ops trampoline", " - drm/msm/adreno: Use IRQF_NO_AUTOEN flag in request_irq()", " - drm/msm/gpu: Check the status of registration to PM QoS", " - drm/xe/hdcp: Fix gsc structure check in fw check status", " - drm/etnaviv: Request pages from DMA32 zone on addressing_limited", " - drm/etnaviv: hold GPU lock across perfmon sampling", " - drm/amd/display: Increase idle worker HPD detection time", " - drm/amd/display: Reduce HPD Detection Interval for IPS", " - drm/nouveau/gr/gf100: Fix missing unlock in gf100_gr_chan_new()", " - drm: zynqmp_kms: Unplug DRM device before removal", " - drm: xlnx: zynqmp_disp: layer may be null while releasing", " - wifi: wfx: Fix error handling in wfx_core_init()", " - wifi: cw1200: Fix potential NULL dereference", " - drm/msm/dpu: cast crtc_clk calculation to u64 in _dpu_core_perf_calc_clk()", " - bpf, bpftool: Fix incorrect disasm pc", " - bpf: Tighten tail call checks for lingering locks, RCU, preempt_disable", " - drm/vkms: Drop unnecessary call to drm_crtc_cleanup()", " - drm/amdgpu: Fix the memory allocation issue in", " amdgpu_discovery_get_nps_info()", " - bpf: Support __nullable argument suffix for tp_btf", " - selftests/bpf: Add test for __nullable suffix in tp_btf", " - bpf: Mark raw_tp arguments with PTR_MAYBE_NULL", " - drm: use ATOMIC64_INIT() for atomic64_t", " - netfilter: nf_tables: avoid false-positive lockdep splat on rule deletion", " - netfilter: nf_tables: must hold rcu read lock while iterating expression", " type list", " - netfilter: nf_tables: must hold rcu read lock while iterating object type", " list", " - netlink: typographical error in nlmsg_type constants definition", " - wifi: rtw89: coex: check NULL return of kmalloc in btc_fw_set_monreg()", " - drm/panfrost: Add missing OPP table refcnt decremental", " - drm/panthor: introduce job cycle and timestamp accounting", " - drm/panthor: record current and maximum device clock frequencies", " - drm/panthor: Fix OPP refcnt leaks in devfreq initialisation", " - isofs: avoid memory leak in iocharset", " - selftests/bpf: Add txmsg_pass to pull/push/pop in test_sockmap", " - selftests/bpf: Fix SENDPAGE data logic in test_sockmap", " - selftests/bpf: Fix total_bytes in msg_loop_rx in test_sockmap", " - selftests/bpf: Add push/pop checking for msg_verify_data in test_sockmap", " - bpf, sockmap: Several fixes to bpf_msg_push_data", " - bpf, sockmap: Several fixes to bpf_msg_pop_data", " - bpf, sockmap: Fix sk_msg_reset_curr", " - ipv6: release nexthop on device removal", " - selftests: net: really check for bg process completion", " - wifi: cfg80211: Remove the Medium Synchronization Delay validity check", " - wifi: iwlwifi: allow fast resume on ax200", " - wifi: iwlwifi: mvm: tell iwlmei when we finished suspending", " - drm/amdgpu: fix ACA bank count boundary check error", " - drm/amdgpu: Fix map/unmap queue logic", " - drm/amdkfd: Fix wrong usage of INIT_WORK()", " - bpf: Allow return values 0 and 1 for kprobe session", " - bpf: Force uprobe bpf program to always return 0", " - selftests/bpf: skip the timer_lockup test for single-CPU nodes", " - ipv6: Fix soft lockups in fib6_select_path under high next hop churn", " - net: rfkill: gpio: Add check for clk_enable()", " - Revert \"wifi: iwlegacy: do not skip frames with bad FCS\"", " - bpf: Use function pointers count as struct_ops links count", " - bpf: Add kernel symbol for struct_ops trampoline", " - ALSA: usx2y: Use snd_card_free_when_closed() at disconnection", " - ALSA: us122l: Use snd_card_free_when_closed() at disconnection", " - ALSA: caiaq: Use snd_card_free_when_closed() at disconnection", " - ALSA: 6fire: Release resources at card release", " - i2c: dev: Fix memory leak when underlying adapter does not support I2C", " - selftests: netfilter: Fix missing return values in conntrack_dump_flush", " - Bluetooth: btintel_pcie: Add handshake between driver and firmware", " - Bluetooth: btintel: Do no pass vendor events to stack", " - Bluetooth: btmtk: adjust the position to init iso data anchor", " - Bluetooth: btbcm: fix missing of_node_put() in btbcm_get_board_name()", " - Bluetooth: ISO: Use kref to track lifetime of iso_conn", " - Bluetooth: ISO: Do not emit LE PA Create Sync if previous is pending", " - Bluetooth: ISO: Do not emit LE BIG Create Sync if previous is pending", " - Bluetooth: ISO: Send BIG Create Sync via hci_sync", " - Bluetooth: fix use-after-free in device_for_each_child()", " - xsk: Free skb when TX metadata options are invalid", " - erofs: handle NONHEAD !delta[1] lclusters gracefully", " - dlm: fix dlm_recover_members refcount on error", " - eth: fbnic: don't disable the PCI device twice", " - net: txgbe: remove GPIO interrupt controller", " - net: txgbe: fix null pointer to pcs", " - netpoll: Use rcu_access_pointer() in netpoll_poll_lock", " - wireguard: selftests: load nf_conntrack if not present", " - bpf: fix recursive lock when verdict program return SK_PASS", " - unicode: Fix utf8_load() error path", " - cppc_cpufreq: Use desired perf if feedback ctrs are 0 or unchanged", " - RDMA/core: Provide rdma_user_mmap_disassociate() to disassociate mmap pages", " - RDMA/hns: Disassociate mmap pages for all uctx when HW is being reset", " - clk: mediatek: drop two dead config options", " - [Config] drop COMMON_CLK_MT8195_{AUDSYS,MSDC}", " - trace/trace_event_perf: remove duplicate samples on the first tracepoint", " event", " - pinctrl: zynqmp: drop excess struct member description", " - pinctrl: renesas: Select PINCTRL_RZG2L for RZ/V2H(P) SoC", " - clk: qcom: videocc-sm8550: depend on either gcc-sm8550 or gcc-sm8650", " - iommu/s390: Implement blocking domain", " - scsi: hisi_sas: Enable all PHYs that are not disabled by user during", " controller reset", " - powerpc/vdso: Flag VDSO64 entry points as functions", " - mfd: tps65010: Use IRQF_NO_AUTOEN flag in request_irq() to fix race", " - mfd: da9052-spi: Change read-mask to write-mask", " - mfd: intel_soc_pmic_bxtwc: Use IRQ domain for USB Type-C device", " - mfd: intel_soc_pmic_bxtwc: Use IRQ domain for TMU device", " - mfd: intel_soc_pmic_bxtwc: Use IRQ domain for PMIC devices", " - irqdomain: Simplify simple and legacy domain creation", " - irqdomain: Cleanup domain name allocation", " - irqdomain: Allow giving name suffix for domain", " - regmap: Allow setting IRQ domain name suffix", " - mfd: intel_soc_pmic_bxtwc: Fix IRQ domain names duplication", " - cpufreq: loongson2: Unregister platform_driver on failure", " - powerpc/fadump: Refactor and prepare fadump_cma_init for late init", " - powerpc/fadump: Move fadump_cma_init to setup_arch() after initmem_init()", " - mtd: hyperbus: rpc-if: Add missing MODULE_DEVICE_TABLE", " - mtd: rawnand: atmel: Fix possible memory leak", " - powerpc/mm/fault: Fix kfence page fault reporting", " - clk: sophgo: avoid integer overflow in sg2042_pll_recalc_rate()", " - mtd: spi-nor: spansion: Use nor->addr_nbytes in octal DTR mode in", " RD_ANY_REG_OP", " - powerpc/pseries: Fix dtl_access_lock to be a rw_semaphore", " - cpufreq: CPPC: Fix possible null-ptr-deref for cpufreq_cpu_get_raw()", " - cpufreq: CPPC: Fix possible null-ptr-deref for cppc_get_cpu_cost()", " - iommu/amd: Remove amd_iommu_domain_update() from page table freeing", " - iommu/amd: Remove the amd_iommu_domain_set_pt_root() and related", " - iommu/amd: Rename struct amd_io_pgtable iopt to pgtbl", " - iommu/amd: Store the nid in io_pgtable_cfg instead of the domain", " - iommu/amd: Narrow the use of struct protection_domain to invalidation", " - iommu/amd/pgtbl_v2: Take protection domain lock before invalidating TLB", " - RDMA/hns: Fix an AEQE overflow error caused by untimely update of eq_db_ci", " - RDMA/hns: Fix flush cqe error when racing with destroy qp", " - RDMA/hns: Modify debugfs name", " - RDMA/hns: Use dev_* printings in hem code instead of ibdev_*", " - RDMA/hns: Fix cpu stuck caused by printings during reset", " - RDMA/rxe: Fix the qp flush warnings in req", " - RDMA/bnxt_re: Check cqe flags to know imm_data vs inv_irkey", " - clk: sunxi-ng: d1: Fix PLL_AUDIO0 preset", " - clk: renesas: rzg2l: Fix FOUTPOSTDIV clk", " - RDMA/rxe: Set queue pair cur_qp_state when being queried", " - RISC-V: KVM: Fix APLIC in_clrip and clripnum write emulation", " - riscv: kvm: Fix out-of-bounds array access", " - clk: imx: lpcg-scu: SW workaround for errata (e10858)", " - clk: imx: fracn-gppll: correct PLL initialization flow", " - clk: imx: fracn-gppll: fix pll power up", " - clk: imx: clk-scu: fix clk enable state save and restore", " - clk: imx: imx8-acm: Fix return value check in", " clk_imx_acm_attach_pm_domains()", " - iommu/vt-d: Fix checks and print in dmar_fault_dump_ptes()", " - iommu/vt-d: Fix checks and print in pgtable_walk()", " - checkpatch: always parse orig_commit in fixes tag", " - mfd: rt5033: Fix missing regmap_del_irq_chip()", " - leds: max5970: Fix unreleased fwnode_handle in probe function", " - leds: ktd2692: Set missing timing properties", " - fs/proc/kcore.c: fix coccinelle reported ERROR instances", " - scsi: target: Fix incorrect function name in pscsi_create_type_disk()", " - scsi: bfa: Fix use-after-free in bfad_im_module_exit()", " - scsi: fusion: Remove unused variable 'rc'", " - scsi: qedf: Fix a possible memory leak in qedf_alloc_and_init_sb()", " - scsi: qedi: Fix a possible memory leak in qedi_alloc_and_init_sb()", " - scsi: sg: Enable runtime power management", " - x86/tdx: Introduce wrappers to read and write TD metadata", " - x86/tdx: Rename tdx_parse_tdinfo() to tdx_setup()", " - x86/tdx: Dynamically disable SEPT violations from causing #VEs", " - powerpc/fadump: allocate memory for additional parameters early", " - fadump: reserve param area if below boot_mem_top", " - RDMA/hns: Fix out-of-order issue of requester when setting FENCE", " - RDMA/hns: Fix NULL pointer derefernce in hns_roce_map_mr_sg()", " - cpufreq: loongson3: Check for error code from devm_mutex_init() call", " - cpufreq: CPPC: Fix wrong return value in cppc_get_cpu_cost()", " - cpufreq: CPPC: Fix wrong return value in cppc_get_cpu_power()", " - kasan: move checks to do_strncpy_from_user", " - kunit: skb: use \"gfp\" variable instead of hardcoding GFP_KERNEL", " - ocfs2: fix uninitialized value in ocfs2_file_read_iter()", " - dax: delete a stale directory pmem", " - KVM: PPC: Book3S HV: Stop using vc->dpdes for nested KVM guests", " - KVM: PPC: Book3S HV: Avoid returning to nested hypervisor on pending", " doorbells", " - powerpc/sstep: make emulate_vsx_load and emulate_vsx_store static", " - RDMA/hns: Fix different dgids mapping to the same dip_idx", " - KVM: PPC: Book3S HV: Fix kmv -> kvm typo", " - powerpc/kexec: Fix return of uninitialized variable", " - fbdev: sh7760fb: Fix a possible memory leak in sh7760fb_alloc_mem()", " - RDMA/mlx5: Move events notifier registration to be after device registration", " - clk: clk-apple-nco: Add NULL check in applnco_probe", " - clk: ralink: mtmips: fix clock plan for Ralink SoC RT3883", " - clk: ralink: mtmips: fix clocks probe order in oldest ralink SoCs", " - clk: en7523: remove REG_PCIE*_{MEM,MEM_MASK} configuration", " - clk: en7523: move clock_register in hw_init callback", " - clk: en7523: introduce chip_scu regmap", " - clk: en7523: fix estimation of fixed rate for EN7581", " - dt-bindings: clock: axi-clkgen: include AXI clk", " - clk: clk-axi-clkgen: make sure to enable the AXI bus clock", " - arm64: dts: qcom: sc8180x: Add a SoC-specific compatible to cpufreq-hw", " - pinctrl: k210: Undef K210_PC_DEFAULT", " - rtla/timerlat: Do not set params->user_workload with -U", " - smb: cached directories can be more than root file handle", " - mailbox: mtk-cmdq: fix wrong use of sizeof in cmdq_get_clocks()", " - mailbox: arm_mhuv2: clean up loop in get_irq_chan_comb()", " - x86: fix off-by-one in access_ok()", " - perf cs-etm: Don't flush when packet_queue fills up", " - gfs2: Rename GLF_VERIFY_EVICT to GLF_VERIFY_DELETE", " - gfs2: Allow immediate GLF_VERIFY_DELETE work", " - gfs2: Fix unlinked inode cleanup", " - perf test: Add test for Intel TPEBS counting mode", " - perf mem: Fix printing PERF_MEM_LVLNUM_{L2_MHB|MSC}", " - PCI: Fix reset_method_store() memory leak", " - perf stat: Close cork_fd when create_perf_stat_counter() failed", " - perf stat: Fix affinity memory leaks on error path", " - perf trace: Keep exited threads for summary", " - perf test attr: Add back missing topdown events", " - f2fs: compress: fix inconsistent update of i_blocks in", " release_compress_blocks and reserve_compress_blocks", " - f2fs: fix null-ptr-deref in f2fs_submit_page_bio()", " - f2fs: fix to account dirty data in __get_secs_required()", " - perf dso: Fix symtab_type for kmod compression", " - perf probe: Fix libdw memory leak", " - perf probe: Correct demangled symbols in C++ program", " - rust: kernel: fix THIS_MODULE header path in ThisModule doc comment", " - rust: macros: fix documentation of the paste! macro", " - PCI: cpqphp: Use PCI_POSSIBLE_ERROR() to check config reads", " - PCI: cpqphp: Fix PCIBIOS_* return value confusion", " - rust: block: fix formatting of `kernel::block::mq::request` module", " - perf disasm: Use disasm_line__free() to properly free disasm_line", " - virtiofs: use pages instead of pointer for kernel direct IO", " - perf ftrace latency: Fix unit on histogram first entry when using --use-nsec", " - i3c: master: Remove i3c_dev_disable_ibi_locked(olddev) on device hotjoin", " - f2fs: fix the wrong f2fs_bug_on condition in f2fs_do_replace_block", " - f2fs: check curseg->inited before write_sum_page in change_curseg", " - f2fs: Fix not used variable 'index'", " - f2fs: fix to avoid potential deadlock in f2fs_record_stop_reason()", " - f2fs: fix to avoid use GC_AT when setting gc_mode as GC_URGENT_LOW or", " GC_URGENT_MID", " - PCI: qcom-ep: Move controller cleanups to qcom_pcie_perst_deassert()", " - PCI: tegra194: Move controller cleanups to pex_ep_event_pex_rst_deassert()", " - PCI: cadence: Extract link setup sequence from cdns_pcie_host_setup()", " - PCI: cadence: Set cdns_pcie_host_init() global", " - PCI: j721e: Add reset GPIO to struct j721e_pcie", " - PCI: j721e: Use T_PERST_CLK_US macro", " - PCI: j721e: Add suspend and resume support", " - PCI: j721e: Deassert PERST# after a delay of PCIE_T_PVPERL_MS milliseconds", " - perf build: Add missing cflags when building with custom libtraceevent", " - f2fs: fix race in concurrent f2fs_stop_gc_thread", " - f2fs: fix to map blocks correctly for direct write", " - f2fs: fix to avoid forcing direct write to use buffered IO on inline_data", " inode", " - perf trace: avoid garbage when not printing a trace event's arguments", " - m68k: mcfgpio: Fix incorrect register offset for CONFIG_M5441x", " - m68k: coldfire/device.c: only build FEC when HW macros are defined", " - svcrdma: Address an integer overflow", " - nfsd: drop inode parameter from nfsd4_change_attribute()", " - perf list: Fix topic and pmu_name argument order", " - perf trace: Fix tracing itself, creating feedback loops", " - perf trace: Do not lose last events in a race", " - perf trace: Avoid garbage when not printing a syscall's arguments", " - remoteproc: qcom: pas: Remove subdevs on the error path of adsp_probe()", " - remoteproc: qcom: adsp: Remove subdevs on the error path of adsp_probe()", " - remoteproc: qcom: pas: add minidump_id to SM8350 resources", " - rpmsg: glink: use only lower 16-bits of param2 for CMD_OPEN name length", " - remoteproc: qcom_q6v5_mss: Re-order writes to the IMEM region", " - PCI: endpoint: epf-mhi: Avoid NULL dereference if DT lacks 'mmio'", " - NFSD: Prevent NULL dereference in nfsd4_process_cb_update()", " - NFSD: Cap the number of bytes copied by nfs4_reset_recoverydir()", " - nfsd: release svc_expkey/svc_export with rcu_work", " - svcrdma: fix miss destroy percpu_counter in svc_rdma_proc_init()", " - NFSD: Fix nfsd4_shutdown_copy()", " - f2fs: clean up val{>>,<<}F2FS_BLKSIZE_BITS", " - f2fs: fix to do cast in F2FS_{BLK_TO_BYTES, BTYES_TO_BLK} to avoid overflow", " - hwmon: (tps23861) Fix reporting of negative temperatures", " - hwmon: (aquacomputer_d5next) Fix length of speed_input array", " - phy: airoha: Fix REG_CSR_2L_PLL_CMN_RESERVE0 config in", " airoha_pcie_phy_init_clk_out()", " - phy: airoha: Fix REG_PCIE_PMA_TX_RESET config in", " airoha_pcie_phy_init_csr_2l()", " - phy: airoha: Fix REG_CSR_2L_JCPLL_SDM_HREN config in", " airoha_pcie_phy_init_ssc_jcpll()", " - phy: airoha: Fix REG_CSR_2L_RX{0,1}_REV0 definitions", " - vdpa/mlx5: Fix suboptimal range on iotlb iteration", " - vfio/mlx5: Fix an unwind issue in mlx5vf_add_migration_pages()", " - vfio/mlx5: Fix unwind flows in mlx5vf_pci_save/resume_device_data()", " - selftests/mount_setattr: Fix failures on 64K PAGE_SIZE kernels", " - gpio: zevio: Add missed label initialisation", " - vfio/pci: Properly hide first-in-list PCIe extended capability", " - fs_parser: update mount_api doc to match function signature", " - LoongArch: Fix build failure with GCC 15 (-std=gnu23)", " - LoongArch: BPF: Sign-extend return values", " - power: supply: core: Remove might_sleep() from power_supply_put()", " - power: supply: bq27xxx: Fix registers of bq27426", " - power: supply: rt9471: Fix wrong WDT function regfield declaration", " - power: supply: rt9471: Use IC status regfield to report real charger status", " - net: usb: lan78xx: Fix double free issue with interrupt buffer allocation", " - net: usb: lan78xx: Fix memory leak on device unplug by freeing PHY device", " - tg3: Set coherent DMA mask bits to 31 for BCM57766 chipsets", " - net: usb: lan78xx: Fix refcounting and autosuspend on invalid WoL", " configuration", " - net: microchip: vcap: Add typegroup table terminators in kunit tests", " - netlink: fix false positive warning in extack during dumps", " - exfat: fix file being changed by unaligned direct write", " - s390/iucv: MSG_PEEK causes memory leak in iucv_sock_destruct()", " - net/ipv6: delete temporary address if mngtmpaddr is removed or unmanaged", " - net: mdio-ipq4019: add missing error check", " - marvell: pxa168_eth: fix call balance of pep->clk handling routines", " - net: stmmac: dwmac-socfpga: Set RX watchdog interrupt as broken", " - octeontx2-af: RPM: Fix mismatch in lmac type", " - octeontx2-af: RPM: Fix low network performance", " - octeontx2-af: RPM: fix stale RSFEC counters", " - octeontx2-af: RPM: fix stale FCFEC counters", " - octeontx2-af: Quiesce traffic before NIX block reset", " - spi: atmel-quadspi: Fix register name in verbose logging function", " - net: hsr: fix hsr_init_sk() vs network/transport headers.", " - bnxt_en: Reserve rings after PCIe AER recovery if NIC interface is down", " - bnxt_en: Set backplane link modes correctly for ethtool", " - bnxt_en: Fix receive ring space parameters when XDP is active", " - bnxt_en: Refactor bnxt_ptp_init()", " - bnxt_en: Unregister PTP during PCI shutdown and suspend", " - Bluetooth: MGMT: Fix slab-use-after-free Read in set_powered_sync", " - Bluetooth: MGMT: Fix possible deadlocks", " - llc: Improve setsockopt() handling of malformed user input", " - rxrpc: Improve setsockopt() handling of malformed user input", " - tcp: Fix use-after-free of nreq in reqsk_timer_handler().", " - ip6mr: fix tables suspicious RCU usage", " - ipmr: fix tables suspicious RCU usage", " - iio: light: al3010: Fix an error handling path in al3010_probe()", " - usb: using mutex lock and supporting O_NONBLOCK flag in iowarrior_read()", " - usb: yurex: make waiting on yurex_write interruptible", " - USB: chaoskey: fail open after removal", " - USB: chaoskey: Fix possible deadlock chaoskey_list_lock", " - misc: apds990x: Fix missing pm_runtime_disable()", " - devres: Fix page faults when tracing devres from unloaded modules", " - usb: gadget: uvc: wake pump everytime we update the free list", " - interconnect: qcom: icc-rpmh: probe defer incase of missing QoS clock", " dependency", " - phy: realtek: usb: fix NULL deref in rtk_usb2phy_probe", " - phy: realtek: usb: fix NULL deref in rtk_usb3phy_probe", " - counter: stm32-timer-cnt: Add check for clk_enable()", " - counter: ti-ecap-capture: Add check for clk_enable()", " - bus: mhi: host: Switch trace_mhi_gen_tre fields to native endian", " - usb: typec: fix potential array underflow in ucsi_ccg_sync_control()", " - firmware_loader: Fix possible resource leak in fw_log_firmware_info()", " - ALSA: hda/realtek: Update ALC256 depop procedure", " - drm/radeon: add helper rdev_to_drm(rdev)", " - drm/radeon: change rdev->ddev to rdev_to_drm(rdev)", " - drm/radeon: Fix spurious unplug event on radeon HDMI", " - drm/amd/display: Fix null check for pipe_ctx->plane_state in", " dcn20_program_pipe", " - drm/amd/display: Fix null check for pipe_ctx->plane_state in hwss_setup_dpp", " - ASoC: imx-audmix: Add NULL check in imx_audmix_probe", " - drm/xe/ufence: Wake up waiters after setting ufence->signalled", " - apparmor: fix 'Do simple duplicate message elimination'", " - ALSA: core: Fix possible NULL dereference caused by kunit_kzalloc()", " - ASoC: amd: yc: Fix for enabling DMIC on acp6x via _DSD entry", " - ASoC: mediatek: Check num_codecs is not zero to avoid panic during probe", " - s390/pci: Fix potential double remove of hotplug slot", " - net_sched: sch_fq: don't follow the fast path if Tx is behind now", " - xen: Fix the issue of resource not being properly released in", " xenbus_dev_probe()", " - ALSA: usb-audio: Fix potential out-of-bound accesses for Extigy and Mbox", " devices", " - ALSA: usb-audio: Fix out of bounds reads when finding clock sources", " - usb: ehci-spear: fix call balance of sehci clk handling routines", " - usb: typec: ucsi: glink: fix off-by-one in connector_status", " - dm-cache: fix warnings about duplicate slab caches", " - dm-bufio: fix warnings about duplicate slab caches", " - ASoC: Intel: sst: Fix used of uninitialized ctx to log an error", " - soc: qcom: socinfo: fix revision check in qcom_socinfo_probe()", " - irqdomain: Always associate interrupts for legacy domains", " - ext4: supress data-race warnings in ext4_free_inodes_{count,set}()", " - ext4: fix FS_IOC_GETFSMAP handling", " - jfs: xattr: check invalid xattr size more strictly", " - ASoC: amd: yc: Add a quirk for microfone on Lenovo ThinkPad P14s Gen 5", " 21MES00B00", " - ASoC: codecs: Fix atomicity violation in snd_soc_component_get_drvdata()", " - ASoC: da7213: Populate max_register to regmap_config", " - perf/x86/intel/pt: Fix buffer full but size is 0 case", " - crypto: x86/aegis128 - access 32-bit arguments as 32-bit", " - KVM: x86: switch hugepage recovery thread to vhost_task", " - KVM: x86/mmu: Skip the \"try unsync\" path iff the old SPTE was a leaf SPTE", " - powerpc/pseries: Fix KVM guest detection for disabling hardlockup detector", " - KVM: arm64: vgic-v3: Sanitise guest writes to GICR_INVLPIR", " - KVM: arm64: Ignore PMCNTENSET_EL0 while checking for overflow status", " - KVM: arm64: Don't retire aborted MMIO instruction", " - KVM: arm64: vgic-its: Clear ITE when DISCARD frees an ITE", " - KVM: arm64: Get rid of userspace_irqchip_in_use", " - KVM: arm64: vgic-its: Add a data length check in vgic_its_save_*", " - KVM: arm64: vgic-its: Clear DTE when MAPD unmaps a device", " - Compiler Attributes: disable __counted_by for clang < 19.1.3", " - PCI: Fix use-after-free of slot->bus on hot remove", " - LoongArch: Explicitly specify code model in Makefile", " - clk: clk-loongson2: Fix memory corruption bug in struct", " loongson2_clk_provider", " - clk: clk-loongson2: Fix potential buffer overflow in flexible-array member", " access", " - fsnotify: fix sending inotify event with unexpected filename", " - comedi: Flush partial mappings in error case", " - apparmor: test: Fix memory leak for aa_unpack_strdup()", " - iio: dac: adi-axi-dac: fix wrong register bitfield", " - tty: ldsic: fix tty_ldisc_autoload sysctl's proc_handler", " - locking/lockdep: Avoid creating new name string literals in", " lockdep_set_subclass()", " - tools/nolibc: s390: include std.h", " - pinctrl: qcom: spmi: fix debugfs drive strength", " - dt-bindings: pinctrl: samsung: Fix interrupt constraint for variants with", " fallbacks", " - dt-bindings: iio: dac: ad3552r: fix maximum spi speed", " - exfat: fix uninit-value in __exfat_get_dentry_set", " - exfat: fix out-of-bounds access of directory entries", " - xhci: Fix control transfer error on Etron xHCI host", " - xhci: Combine two if statements for Etron xHCI host", " - xhci: Don't perform Soft Retry for Etron xHCI host", " - xhci: Don't issue Reset Device command to Etron xHCI host", " - Bluetooth: Fix type of len in rfcomm_sock_getsockopt{,_old}()", " - usb: xhci: Limit Stop Endpoint retries", " - usb: xhci: Fix TD invalidation under pending Set TR Dequeue", " - usb: xhci: Avoid queuing redundant Stop Endpoint commands", " - ARM: dts: omap36xx: declare 1GHz OPP as turbo again", " - wifi: ath12k: fix warning when unbinding", " - wifi: rtlwifi: Drastically reduce the attempts to read efuse in case of", " failures", " - wifi: nl80211: fix bounds checker error in nl80211_parse_sched_scan", " - wifi: ath12k: fix crash when unbinding", " - wifi: brcmfmac: release 'root' node in all execution paths", " - Revert \"fs: don't block i_writecount during exec\"", " - Revert \"f2fs: remove unreachable lazytime mount option parsing\"", " - Revert \"usb: gadget: composite: fix OS descriptors w_value logic\"", " - serial: sh-sci: Clean sci_ports[0] after at earlycon exit", " - Revert \"serial: sh-sci: Clean sci_ports[0] after at earlycon exit\"", " - io_uring: fix corner case forgetting to vunmap", " - io_uring: check for overflows in io_pin_pages", " - blk-settings: round down io_opt to physical_block_size", " - gpio: exar: set value when external pull-up or pull-down is present", " - spi: Fix acpi deferred irq probe", " - mtd: spi-nor: core: replace dummy buswidth from addr to data", " - cpufreq: mediatek-hw: Fix wrong return value in mtk_cpufreq_get_cpu_power()", " - cifs: support mounting with alternate password to allow password rotation", " - parisc/ftrace: Fix function graph tracing disablement", " - RISC-V: Scalar unaligned access emulated on hotplug CPUs", " - RISC-V: Check scalar unaligned access on all CPUs", " - ksmbd: fix use-after-free in SMB request handling", " - smb: client: fix NULL ptr deref in crypto_aead_setkey()", " - platform/chrome: cros_ec_typec: fix missing fwnode reference decrement", " - irqchip/irq-mvebu-sei: Move misplaced select() callback to SEI CP domain", " - x86/CPU/AMD: Terminate the erratum_1386_microcode array", " - ubi: wl: Put source PEB into correct list if trying locking LEB failed", " - um: ubd: Do not use drvdata in release", " - um: net: Do not use drvdata in release", " - dt-bindings: serial: rs485: Fix rs485-rts-delay property", " - serial: 8250_fintek: Add support for F81216E", " - serial: 8250: omap: Move pm_runtime_get_sync", " - serial: amba-pl011: Fix RX stall when DMA is used", " - serial: amba-pl011: fix build regression", " - mtd: ubi: fix unreleased fwnode_handle in find_volume_fwnode()", " - block: Prevent potential deadlock in blk_revalidate_disk_zones()", " - um: vector: Do not use drvdata in release", " - sh: cpuinfo: Fix a warning for CONFIG_CPUMASK_OFFSTACK", " - iio: gts: Fix uninitialized symbol 'ret'", " - ublk: fix ublk_ch_mmap() for 64K page size", " - arm64: tls: Fix context-switching of tpidrro_el0 when kpti is enabled", " - block: fix missing dispatching request when queue is started or unquiesced", " - block: fix ordering between checking QUEUE_FLAG_QUIESCED request adding", " - block: fix ordering between checking BLK_MQ_S_STOPPED request adding", " - blk-mq: Make blk_mq_quiesce_tagset() hold the tag list mutex less long", " - gve: Flow steering trigger reset only for timeout error", " - HID: wacom: Interpret tilt data from Intuos Pro BT as signed values", " - i40e: Fix handling changed priv flags", " - media: wl128x: Fix atomicity violation in fmc_send_cmd()", " - media: intel/ipu6: do not handle interrupts when device is disabled", " - arm64: dts: mediatek: mt8186-corsola-voltorb: Merge speaker codec nodes", " - netdev-genl: Hold rcu_read_lock in napi_get", " - soc: fsl: rcpm: fix missing of_node_put() in copy_ippdexpcr1_setting()", " - media: v4l2-core: v4l2-dv-timings: check cvt/gtf result", " - ALSA: rawmidi: Fix kvfree() call in spinlock", " - ALSA: ump: Fix evaluation of MIDI 1.0 FB info", " - ALSA: pcm: Add sanity NULL check for the default mmap fault handler", " - ALSA: hda/realtek: Update ALC225 depop procedure", " - ALSA: hda/realtek: Set PCBeep to default value for ALC274", " - ALSA: hda/realtek: Fix Internal Speaker and Mic boost of Infinix Y4 Max", " - ALSA: hda/realtek: Apply quirk for Medion E15433", " - smb3: request handle caching when caching directories", " - smb: client: handle max length for SMB symlinks", " - smb: Don't leak cfid when reconnect races with open_cached_dir", " - smb: prevent use-after-free due to open_cached_dir error paths", " - smb: During unmount, ensure all cached dir instances drop their dentry", " - usb: misc: ljca: set small runtime autosuspend delay", " - usb: misc: ljca: move usb_autopm_put_interface() after wait for response", " - usb: dwc3: ep0: Don't clear ep0 DWC3_EP_TRANSFER_STARTED", " - usb: musb: Fix hardware lockup on first Rx endpoint request", " - usb: dwc3: gadget: Fix checking for number of TRBs left", " - usb: dwc3: gadget: Fix looping of queued SG entries", " - staging: vchiq_arm: Fix missing refcount decrement in error path for fw_node", " - counter: stm32-timer-cnt: fix device_node handling in probe_encoder()", " - ublk: fix error code for unsupported command", " - lib: string_helpers: silence snprintf() output truncation warning", " - f2fs: fix to do sanity check on node blkaddr in truncate_node()", " - ipc: fix memleak if msg_init_ns failed in create_ipc_ns", " - Input: cs40l50 - fix wrong usage of INIT_WORK()", " - NFSD: Prevent a potential integer overflow", " - SUNRPC: make sure cache entry active before cache_show", " - um: Fix potential integer overflow during physmem setup", " - um: Fix the return value of elf_core_copy_task_fpregs", " - kfifo: don't include dma-mapping.h in kfifo.h", " - um: ubd: Initialize ubd's disk pointer in ubd_add", " - um: Always dump trace for specified task in show_stack", " - NFSv4.0: Fix a use-after-free problem in the asynchronous open()", " - rtc: st-lpc: Use IRQF_NO_AUTOEN flag in request_irq()", " - rtc: abx80x: Fix WDT bit position of the status register", " - rtc: check if __rtc_read_time was successful in rtc_timer_do_work()", " - ubi: fastmap: wl: Schedule fm_work if wear-leveling pool is empty", " - ubifs: Correct the total block count by deducting journal reservation", " - ubi: fastmap: Fix duplicate slab cache names while attaching", " - ubifs: authentication: Fix use-after-free in ubifs_tnc_end_commit", " - jffs2: fix use of uninitialized variable", " - rtc: rzn1: fix BCD to rtc_time conversion errors", " - Revert \"nfs: don't reuse partially completed requests in", " nfs_lock_and_join_requests\"", " - nvme-multipath: avoid hang on inaccessible namespaces", " - nvme/multipath: Fix RCU list traversal to use SRCU primitive", " - blk-mq: add non_owner variant of start_freeze/unfreeze queue APIs", " - block: model freeze & enter queue as lock for supporting lockdep", " - block: fix uaf for flush rq while iterating tags", " - block: return unsigned int from bdev_io_min", " - nvme-fabrics: fix kernel crash while shutting down controller", " - 9p/xen: fix init sequence", " - 9p/xen: fix release of IRQ", " - perf/arm-smmuv3: Fix lockdep assert in ->event_init()", " - perf/arm-cmn: Ensure port and device id bits are set properly", " - smb: client: disable directory caching when dir_cache_timeout is zero", " - x86/Documentation: Update algo in init_size description of boot protocol", " - cifs: Fix parsing native symlinks relative to the export", " - cifs: Fix parsing reparse point with native symlink in SMB1 non-UNICODE", " session", " - rtc: ab-eoz9: don't fail temperature reads on undervoltage notification", " - Rename .data.unlikely to .data..unlikely", " - Rename .data.once to .data..once to fix resetting WARN*_ONCE", " - kbuild: deb-pkg: Don't fail if modules.order is missing", " - smb: Initialize cfid->tcon before performing network ops", " - block: Don't allow an atomic write be truncated in blkdev_write_iter()", " - modpost: remove incorrect code in do_eisa_entry()", " - cifs: during remount, make sure passwords are in sync", " - cifs: unlock on error in smb3_reconfigure()", " - nfs: ignore SB_RDONLY when mounting nfs", " - sunrpc: clear XPRT_SOCK_UPD_TIMEOUT when reset transport", " - SUNRPC: timeout and cancel TLS handshake with -ETIMEDOUT", " - sunrpc: fix one UAF issue caused by sunrpc kernel tcp socket", " - nfs/blocklayout: Don't attempt unregister for invalid block device", " - nfs/blocklayout: Limit repeat device registration on failure", " - block, bfq: fix bfqq uaf in bfq_limit_depth()", " - brd: decrease the number of allocated pages which discarded", " - sh: intc: Fix use-after-free bug in register_intc_controller()", " - tools/power turbostat: Fix trailing '\\n' parsing", " - tools/power turbostat: Fix child's argument forwarding", " - block: always verify unfreeze lock on the owner task", " - block: don't verify IO lock for freeze/unfreeze in elevator_init_mq()", " - Linux 6.11.11", "", " * Oracular update: v6.11.11 upstream stable release (LP: #2091655) //", " CVE-2024-53141", " - netfilter: ipset: add missing range check in bitmap_ip_uadt", "", " * Oracular update: v6.11.11 upstream stable release (LP: #2091655) //", " CVE-2024-50010", " - Revert \"exec: don't WARN for racy path_noexec check\"", "", " * Oracular update: v6.11.11 upstream stable release (LP: #2091655) //", " CVE-2024-53143", " - fsnotify: Fix ordering of iput() and watched_objects decrement", "", " * Oracular update: v6.11.11 upstream stable release (LP: #2091655) //", " CVE-2024-53142", " - initramfs: avoid filename buffer overrun", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650)", " - net: vertexcom: mse102x: Fix tx_bytes calculation", " - net/mlx5: Fix msix vectors to respect platform limit", " - net/mlx5e: clear xdp features on non-uplink representors", " - net/mlx5e: Disable loopback self-test on multi-PF netdev", " - drm/i915/gsc: ARL-H and ARL-U need a newer GSC FW.", " - drivers: perf: Fix wrong put_cpu() placement", " - Bluetooth: hci_core: Fix calling mgmt_device_connected", " - Bluetooth: btintel: Direct exception event to bluetooth stack", " - net: sched: cls_u32: Fix u32's systematic failure to free IDR entries for", " hnodes.", " - net: phylink: ensure PHY momentary link-fails are handled", " - samples: pktgen: correct dev to DEV", " - net: stmmac: dwmac-mediatek: Fix inverted handling of mediatek,mac-wol", " - net: Make copy_safe_from_sockptr() match documentation", " - stmmac: dwmac-intel-plat: fix call balance of tx_clk handling routines", " - net: ti: icssg-prueth: Fix 1 PPS sync", " - bonding: add ns target multicast address to slave device", " - ARM: 9419/1: mm: Fix kernel memory mapping for xip kernels", " - tools/mm: fix compile error", " - drm/amd/display: Run idle optimizations at end of vblank handler", " - drm/amd/display: Change some variable name of psr", " - drm/amd/display: Fix Panel Replay not update screen correctly", " - x86/mm: Fix a kdump kernel failure on SME system when CONFIG_IMA_KEXEC=y", " - x86/stackprotector: Work around strict Clang TLS symbol requirements", " - crash, powerpc: default to CRASH_DUMP=n on PPC_BOOK3S_32", " - [Config] enable ARCH_DEFAULT_CRASH_DUMP", " - mm: revert \"mm: shmem: fix data-race in shmem_getattr()\"", " - vdpa/mlx5: Fix PA offset with unaligned starting iotlb map", " - evm: stop avoidably reading i_writecount in evm_file_release", " - KVM: selftests: Disable strict aliasing", " - KVM: nVMX: Treat vpid01 as current if L2 is active, but with VPID disabled", " - KVM: x86: Unconditionally set irr_pending when updating APICv state", " - tpm: Disable TPM on tpm2_create_primary() failure", " - ALSA: hda/realtek - Fixed Clevo platform headset Mic issue", " - ALSA: hda/realtek - update set GPIO3 to default for Thinkpad with ALC1318", " - mptcp: update local address flags when setting it", " - mptcp: hold pm lock when deleting entry", " - mptcp: pm: use _rcu variant under rcu_read_lock", " - ocfs2: fix UBSAN warning in ocfs2_verify_volume()", " - LoongArch: Fix early_numa_add_cpu() usage for FDT systems", " - LoongArch: Disable KASAN if PGDIR_SIZE is too large for cpu_vabits", " - LoongArch: Add WriteCombine shadow mapping in KASAN", " - LoongArch: Fix AP booting issue in VM mode", " - LoongArch: Make KASAN work with 5-level page-tables", " - selftests: hugetlb_dio: fixup check for initial conditions to skip in the", " start", " - btrfs: fix incorrect comparison for delayed refs", " - mailbox: qcom-cpucp: Mark the irq with IRQF_NO_SUSPEND flag", " - firmware: arm_scmi: Skip opp duplicates", " - firmware: arm_scmi: Report duplicate opps as firmware bugs", " - mmc: sunxi-mmc: Fix A100 compatible description", " - drm/bridge: tc358768: Fix DSI command tx", " - drm/xe: handle flat ccs during hibernation on igpu", " - pmdomain: arm: Use FLAG_DEV_NAME_FW to ensure unique names", " - pmdomain: core: Add GENPD_FLAG_DEV_NAME_FW flag", " - nouveau: fw: sync dma after setup is called.", " - nouveau: handle EBUSY and EAGAIN for GSP aux errors.", " - nouveau/dp: handle retries for AUX CH transfers with GSP.", " - drm/amd: Fix initialization mistake for NBIO 7.7.0", " - drm/amdgpu: fix check in gmc_v9_0_get_vm_pte()", " - drm/amdgpu: Fix video caps for H264 and HEVC encode maximum size", " - drm/amd/pm: print pp_dpm_mclk in ascending order on SMU v14.0.0", " - drm/amdgpu: enable GTT fallback handling for dGPUs only", " - drm/amdgpu/mes12: correct kiq unmap latency", " - drm/amd/display: Require minimum VBlank size for stutter optimization", " - drm/amd/display: Fix failure to read vram info due to static BP_RESULT", " - mm: refactor arch_calc_vm_flag_bits() and arm64 MTE handling", " - drm/xe: Restore system memory GGTT mappings", " - drm/xe: improve hibernation on igpu", " - lib/buildid: Fix build ID parsing logic", " - net: sched: u32: Add test case for systematic hnode IDR leaks", " - media: dvbdev: fix the logic when DVB_DYNAMIC_MINORS is not set", " - Linux 6.11.10", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53133", " - drm/amd/display: Handle dml allocation failure to avoid crash", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53108", " - drm/amd/display: Adjust VSDB parser for replay feature", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53134", " - pmdomain: imx93-blk-ctrl: correct remove path", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53132", " - drm/xe/oa: Fix \"Missing outer runtime PM protection\" warning", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53127", " - Revert \"mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K\"", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53130", " - nilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53105", " - mm: page_alloc: move mlocked flag clearance into free_pages_prepare()", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53109", " - nommu: pass NULL argument to vma_iter_prealloc()", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53131", " - nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53135", " - KVM: VMX: Bury Intel PT virtualization (guest/host mode) behind", " CONFIG_BROKEN", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53106", " - ima: fix buffer overrun in ima_eventdigest_init_common", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53110", " - vp_vdpa: fix id_table array not null terminated error", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53126", " - vdpa: solidrun: Fix UB bug with devres", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53111", " - mm/mremap: fix address wraparound in move_page_tables()", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53107", " - fs/proc/task_mmu: prevent integer overflow in pagemap_scan_get_args()", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53128", " - sched/task_stack: fix object_is_on_stack() for KASAN tagged pointers", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53112", " - ocfs2: uncache inode which has failed entering the group", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53113", " - mm: fix NULL pointer dereference in alloc_pages_bulk_noprof", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53114", " - x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 client", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53137", " - ARM: fix cacheflush with PAN", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53115", " - drm/vmwgfx: avoid null_ptr_deref in vmw_framebuffer_surface_create_handle", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53116", " - drm/panthor: Fix handling of partial GPU mapping of BOs", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53117", " - virtio/vsock: Improve MSG_ZEROCOPY error handling", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53118", " - vsock: Fix sk_error_queue memory leak", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53119", " - virtio/vsock: Fix accept_queue memory leak", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53120", " - net/mlx5e: CT: Fix null-ptr-deref in add rule err flow", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53138", " - net/mlx5e: kTLS, Fix incorrect page refcounting", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53121", " - net/mlx5: fs, lock FTE when checking if active", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53122", " - mptcp: cope racing subflow creation in mptcp_rcv_space_adjust", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53123", " - mptcp: error out earlier on disconnect", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53124", " - net: fix data-races around sk->sk_forward_alloc", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53129", " - drm/rockchip: vop: Fix a dereferenced before check warning", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53139", " - sctp: fix possible UAF in sctp_v6_available()", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53140", " - netlink: terminate outstanding dump on socket close", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649)", " - nvme/host: Fix RCU list traversal to use SRCU primitive", " - 9p: v9fs_fid_find: also lookup by inode if not found dentry", " - 9p: Avoid creating multiple slab caches with the same name", " - selftests/bpf: Verify that sync_linked_regs preserves subreg_def", " - nvmet-passthru: clear EUID/NGUID/UUID while using loop target", " - irqchip/ocelot: Fix trigger register address", " - pinctrl: aw9523: add missing mutex_destroy", " - pinctrl: intel: platform: Add Panther Lake to the list of supported", " - block: Fix elevator_get_default() checking for NULL q->tag_set", " - HID: multitouch: Add support for B2402FVA track point", " - HID: multitouch: Add quirk for HONOR MagicBook Art 14 touchpad", " - iommu/arm-smmu: Clarify MMU-500 CPRE workaround", " - nvme: disable CC.CRIME (NVME_CC_CRIME)", " - bpf: use kvzmalloc to allocate BPF verifier environment", " - crypto: api - Fix liveliness check in crypto_alg_tested", " - crypto: marvell/cesa - Disable hash algorithms", " - s390/ap: Fix CCA crypto card behavior within protected execution environment", " - sound: Make CONFIG_SND depend on INDIRECT_IOMEM instead of UML", " - drm/vmwgfx: Limit display layout ioctl array size to", " VMWGFX_NUM_DISPLAY_UNITS", " - selftests/bpf: Assert link info uprobe_multi count & path_size if unset", " - ALSA: hda/tas2781: Add new quirk for Lenovo, ASUS, Dell projects", " - drm/amdkfd: Accounting pdd vram_usage for svm", " - powerpc/powernv: Free name on error in opal_event_init()", " - net: phy: mdio-bcm-unimac: Add BCM6846 support", " - drm/xe/query: Increase timestamp width", " - nvme-loop: flush off pending I/O while shutting down loop controller", " - samples/landlock: Fix port parsing in sandboxer", " - vDPA/ifcvf: Fix pci_read_config_byte() return code handling", " - bpf: Fix mismatched RCU unlock flavour in bpf_out_neigh_v6", " - ASoC: Intel: avs: Update stream status in a separate thread", " - ASoC: codecs: Fix error handling in aw_dev_get_dsp_status function", " - ASoC: amd: yc: Add quirk for ASUS Vivobook S15 M3502RA", " - ASoC: amd: yc: Fix non-functional mic on ASUS E1404FA", " - ASoC: Intel: soc-acpi: lnl: Add match entry for TM2 laptops", " - netfs: Downgrade i_rwsem for a buffered write", " - HID: i2c-hid: Delayed i2c resume wakeup for 0x0d42 Goodix touchpad", " - HID: multitouch: Add quirk for Logitech Bolt receiver w/ Casa touchpad", " - HID: lenovo: Add support for Thinkpad X1 Tablet Gen 3 keyboard", " - ASoC: codecs: lpass-rx-macro: fix RXn(rx,n) macro for DSM_CTL and SEC7 regs", " - RISCV: KVM: use raw_spinlock for critical section in imsic", " - ASoC: rt722-sdca: increase clk_stop_timeout to fix clock stop issue", " - LoongArch: Use \"Exception return address\" to comment ERA", " - ASoC: fsl_micfil: Add sample rate constraint", " - net: usb: qmi_wwan: add Fibocom FG132 0x0112 composition", " - drm/xe: Enlarge the invalidation timeout from 150 to 500", " - drm/xe/guc/ct: Flush g2h worker in case of g2h response timeout", " - drm/xe: Handle unreliable MMIO reads during forcewake", " - drm/xe: Don't restart parallel queues multiple times on GT reset", " - mm: krealloc: Fix MTE false alarm in __do_krealloc", " - 9p: fix slab cache name creation for real", " - Linux 6.11.9", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53098", " - drm/xe/ufence: Prefetch ufence addr to catch bogus address", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53099", " - bpf: Check validity of link->type in bpf_link_show_fdinfo()", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53089", " - LoongArch: KVM: Mark hrtimer to expire in hard interrupt context", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53090", " - afs: Fix lock recursion", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53101", " - fs: Fix uninitialized value issue in from_kuid and from_kgid", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53091", " - bpf: Add sk_is_inet and IS_ICSK check in tls_sw_has_ctx_tx/rx", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53092", " - virtio_pci: Fix admin vq cleanup by using correct info pointer", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53102", " - nvme: make keep-alive synchronous operation", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53093", " - nvme-multipath: defer partition scanning", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53094", " - RDMA/siw: Add sendpage_ok() check to disable MSG_SPLICE_PAGES", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53100", " - nvme: tcp: avoid race between queue_lock lock and destroy", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53095", " - smb: client: Fix use-after-free of network namespace.", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645)", " - arm64: dts: rockchip: Fix rt5651 compatible value on rk3399-eaidk-610", " - arm64: dts: rockchip: Fix rt5651 compatible value on rk3399-sapphire-", " excavator", " - arm64: dts: rockchip: Move L3 cache outside CPUs in RK3588(S) SoC dtsi", " - arm64: dts: rockchip: Start cooling maps numbering from zero on ROCK 5B", " - arm64: dts: rockchip: Designate Turing RK1's system power controller", " - EDAC/qcom: Make irq configuration optional", " - arm64: dts: rockchip: Remove hdmi's 2nd interrupt on rk3328", " - arm64: dts: rockchip: Fix wakeup prop names on PineNote BT node", " - arm64: dts: rockchip: Fix reset-gpios property on brcm BT nodes", " - arm64: dts: rockchip: fix i2c2 pinctrl-names property on anbernic-rg353p/v", " - arm64: dts: rockchip: Drop regulator-init-microvolt from two boards", " - arm64: dts: rockchip: Fix bluetooth properties on rk3566 box demo", " - arm64: dts: rockchip: Fix bluetooth properties on Rock960 boards", " - arm64: dts: rockchip: Add DTS for FriendlyARM NanoPi R2S Plus", " - arm64: dts: rockchip: Remove undocumented supports-emmc property", " - arm64: dts: rockchip: Remove #cooling-cells from fan on Theobroma lion", " - arm64: dts: rockchip: Fix LED triggers on rk3308-roc-cc", " - arm64: dts: rockchip: remove num-slots property from rk3328-nanopi-r2s-plus", " - arm64: dts: qcom: sm8450 fix PIPE clock specification for pcie1", " - arm64: dts: imx8-ss-vpu: Fix imx8qm VPU IRQs", " - arm64: dts: imx8mp: correct sdhc ipg clk", " - arm64: dts: imx8mp-phyboard-pollux: Set Video PLL1 frequency to 506.8 MHz", " - firmware: qcom: scm: Return -EOPNOTSUPP for unsupported SHM bridge enabling", " - arm64: dts: rockchip: remove orphaned pinctrl-names from pinephone pro", " - ARM: dts: rockchip: fix rk3036 acodec node", " - ARM: dts: rockchip: drop grf reference from rk3036 hdmi", " - ARM: dts: rockchip: Fix the spi controller on rk3036", " - ARM: dts: rockchip: Fix the realtek audio codec on rk3036-kylin", " - arm64: dts: rockchip: Correct GPIO polarity on brcm BT nodes", " - sunrpc: handle -ENOTCONN in xs_tcp_setup_socket()", " - NFSv3: only use NFS timeout for MOUNT when protocols are compatible", " - NFS: Fix attribute delegation behaviour on exclusive create", " - NFS: Further fixes to attribute delegation a/mtime changes", " - nfs: avoid i_lock contention in nfs_clear_invalid_mapping", " - net: enetc: set MAC address to the VF net_device", " - net: dpaa_eth: print FD status in CPU endianness in dpaa_eth_fd tracepoint", " - dt-bindings: net: xlnx,axi-ethernet: Correct phy-mode property value", " - can: c_can: fix {rx,tx}_errors statistics", " - ice: change q_index variable type to s16 to store -1 value", " - e1000e: Remove Meteor Lake SMBUS workarounds", " - net: phy: ti: add PHY_RST_AFTER_CLK_EN flag", " - net: stmmac: Fix unbalanced IRQ wake disable warning on single irq case", " - netfilter: nf_tables: wait for rcu grace period on net_device removal", " - virtio_net: Support dynamic rss indirection table size", " - virtio_net: Sync rss config to device when virtnet_probe", " - virtio_net: Update rss when set queue", " - net: arc: rockchip: fix emac mdio node support", " - drivers: net: ionic: add missed debugfs cleanup to ionic_probe() error path", " - Revert \"ALSA: hda/conexant: Mute speakers at suspend / shutdown\"", " - media: stb0899_algo: initialize cfr before using it", " - media: dvb_frontend: don't play tricks with underflow values", " - media: adv7604: prevent underflow condition when reporting colorspace", " - scsi: sd_zbc: Use kvzalloc() to allocate REPORT ZONES buffer", " - ALSA: firewire-lib: fix return value on fail in amdtp_tscm_init()", " - tools/lib/thermal: Fix sampling handler context ptr", " - thermal/of: support thermal zones w/o trips subnode", " - ASoC: SOF: sof-client-probes-ipc4: Set param_size extension bits", " - media: pulse8-cec: fix data timestamp at pulse8_setup()", " - media: v4l2-ctrls-api: fix error handling for v4l2_g_ctrl()", " - can: m_can: m_can_close(): don't call free_irq() for IRQ-less devices", " - can: mcp251xfd: mcp251xfd_get_tef_len(): fix length calculation", " - can: mcp251xfd: mcp251xfd_ring_alloc(): fix coalescing configuration when", " switching CAN modes", " - can: {cc770,sja1000}_isa: allow building on x86_64", " - [Config] updateconfigs for CAN_{CC770,SJA1000}_ISA", " - drm/xe: Set mask bits for CCS_MODE register", " - pwm: imx-tpm: Use correct MODULO value for EPWM mode", " - rpmsg: glink: Handle rejected intent request better", " - drm/amd/pm: always pick the pptable from IFWI", " - drm/amd/display: Fix brightness level not retained over reboot", " - drm/imagination: Add a per-file PVR context list", " - drm/amdgpu: Adjust debugfs eviction and IB access permissions", " - drm/amdgpu: Adjust debugfs register access permissions", " - drm/amdgpu: Fix DPX valid mode check on GC 9.4.3", " - drm/amdgpu: prevent NULL pointer dereference if ATIF is not supported", " - thermal/drivers/qcom/lmh: Remove false lockdep backtrace", " - dm cache: correct the number of origin blocks to match the target length", " - dm cache: optimize dirty bit checking with find_next_bit when resizing", " - dm-unstriped: cast an operand to sector_t to prevent potential uint32_t", " overflow", " - mptcp: no admin perm to list endpoints", " - ALSA: usb-audio: Add quirk for HP 320 FHD Webcam", " - tracing: Fix tracefs mount options", " - net: wwan: t7xx: Fix off-by-one error in t7xx_dpmaif_rx_buf_alloc()", " - mptcp: use sock_kfree_s instead of kfree", " - arm64: Kconfig: Make SME depend on BROKEN for now", " - [Config] updateconfigs for ARM64_SME", " - arm64: smccc: Remove broken support for SMCCCv1.3 SVE discard hint", " - KVM: PPC: Book3S HV: Mask off LPCR_MER for a vCPU before running it to avoid", " spurious interrupts", " - btrfs: fix the length of reserved qgroup to free", " - btrfs: fix per-subvolume RO/RW flags with new mount API", " - platform/x86/amd/pmf: Relocate CPU ID macros to the PMF header", " - platform/x86/amd/pmf: Update SMU metrics table for 1AH family series", " - platform/x86/amd/pmf: Add SMU metrics table support for 1Ah family 60h model", " - i2c: designware: do not hold SCL low when I2C_DYNAMIC_TAR_UPDATE is not set", " - clk: qcom: gcc-x1e80100: Fix USB MP SS1 PHY GDSC pwrsts flags", " - clk: qcom: clk-alpha-pll: Fix pll post div mask when width is not set", " - fs/proc: fix compile warning about variable 'vmcore_mmap_ops'", " - objpool: fix to make percpu slot allocation more robust", " - mm/damon/core: handle zero {aggregation,ops_update} intervals", " - mm/damon/core: handle zero schemes apply interval", " - mm/mlock: set the correct prev on failure", " - thunderbolt: Add only on-board retimers when !CONFIG_USB4_DEBUGFS_MARGINING", " - usb: dwc3: fix fault at system suspend if device was already runtime", " suspended", " - USB: serial: qcserial: add support for Sierra Wireless EM86xx", " - USB: serial: option: add Fibocom FG132 0x0112 composition", " - USB: serial: option: add Quectel RG650V", " - clk: qcom: gcc-x1e80100: Fix halt_check for pipediv2 clocks", " - thunderbolt: Fix connection issue with Pluggable UD-4VPD dock", " - staging: vchiq_arm: Use devm_kzalloc() for drv_mgmt allocation", " - staging: vchiq_arm: Use devm_kzalloc() for vchiq_arm_state allocation", " - irqchip/gic-v3: Force propagation of the active state with a read-back", " - ucounts: fix counter leak in inc_rlimit_get_ucounts()", " - selftests: hugetlb_dio: check for initial conditions to skip in the start", " - firmware: qcom: scm: Refactor code to support multiple dload mode", " - [Config] updateconfigs for QCOM_SCM_DOWNLOAD_MODE_DEFAULT", " - firmware: qcom: scm: suppress download mode error", " - block: rework bio splitting", " - block: fix queue limits checks in blk_rq_map_user_bvec for real", " - drm/xe: Move LNL scheduling WA to xe_device.h", " - drm/xe/ufence: Flush xe ordered_wq in case of ufence timeout", " - drm/xe/guc/tlb: Flush g2h worker in case of tlb timeout", " - ASoC: amd: yc: fix internal mic on Xiaomi Book Pro 14 2022", " - xtensa: Emulate one-byte cmpxchg", " - Linux 6.11.8", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50265", " - ocfs2: remove entry once instead of null-ptr-dereference in", " ocfs2_xa_remove()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50266", " - clk: qcom: videocc-sm8350: use HW_CTRL_TRIGGER for vcodec GDSCs", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50267", " - USB: serial: io_edgeport: fix use after free in debug printk", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50268", " - usb: typec: fix potential out of bounds in ucsi_ccg_update_set_new_cam_cmd()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53083", " - usb: typec: qcom-pmic: init value of hdr_len/txbuf_len earlier", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50269", " - usb: musb: sunxi: Fix accessing an released usb phy", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53079", " - mm/thp: fix deferred split unqueue naming and locking", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50270", " - mm/damon/core: avoid overflow in damon_feed_loop_next_input()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50271", " - signal: restore the override_rlimit logic", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50272", " - filemap: Fix bounds checking in filemap_read()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53104", " - media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in", " uvc_parse_format", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50273", " - btrfs: reinitialize delayed ref list after deleting it from the list", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53064", " - idpf: fix idpf_vc_core_init error path", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50274", " - idpf: avoid vport access in idpf_get_link_ksettings", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53065", " - mm/slab: fix warning caused by duplicate kmem_cache creation in", " kmem_buckets_create", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50275", " - arm64/sve: Discard stale CPU state when handling SVE traps", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50276", " - net: vertexcom: mse102x: Fix possible double free of TX skb", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53066", " - nfs: Fix KMSAN warning in decode_getfattr_attrs()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53067", " - scsi: ufs: core: Start the RTC update work later", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50277", " - dm: fix a crash if blk_alloc_disk fails", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50278", " - dm cache: fix potential out-of-bounds access on the first resume", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50279", " - dm cache: fix out-of-bounds access to the dirty bitset when resizing", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50280", " - dm cache: fix flushing uninitialized delayed_work on cache_ctr error", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50281", " - KEYS: trusted: dcp: fix NULL dereference in AEAD crypto operation", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50282", " - drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53071", " - drm/panthor: Be stricter about IO mapping flags", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53080", " - drm/panthor: Lock XArray when getting entries for the VM", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53084", " - drm/imagination: Break an object reference loop", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53085", " - tpm: Lock TPM chip in tpm_pm_suspend() first", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53086", " - drm/xe: Drop VM dma-resv lock on xe_sync_in_fence_get failure in exec IOCTL", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53087", " - drm/xe: Fix possible exec queue leak in exec IOCTL", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50283", " - ksmbd: fix slab-use-after-free in smb3_preauth_hash_rsp", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50284", " - ksmbd: Fix the missing xa_store error check", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50285", " - ksmbd: check outstanding simultaneous SMB operations", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50286", " - ksmbd: fix slab-use-after-free in ksmbd_smb2_session_create", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50287", " - media: v4l2-tpg: prevent the risk of a division by zero", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50288", " - media: vivid: fix buffer overwrite when using > 32 buffers", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50289", " - media: av7110: fix a spectre vulnerability", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50290", " - media: cx24116: prevent overflows on SNR calculus", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53061", " - media: s5p-jpeg: prevent buffer overflows", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53081", " - media: ar0521: don't overflow when checking PLL values", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53062", " - media: mgb4: protect driver against spectre", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50291", " - media: dvb-core: add missing buffer index check", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50292", " - ASoC: stm32: spdifrx: fix dma channel release in stm32_spdifrx_remove", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53063", " - media: dvbdev: prevent the risk of out of memory access", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50293", " - net/smc: do not leave a dangling sk pointer in __smc_create()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50294", " - rxrpc: Fix missing locking causing hanging calls", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50295", " - net: arc: fix the device for dma_map_single/dma_unmap_single", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53082", " - virtio_net: Add hash_key_length check", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50296", " - net: hns3: fix kernel crash when uninstalling driver", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53088", " - i40e: fix race condition by adding filter's intermediate sync state", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50297", " - net: xilinx: axienet: Enqueue Tx packets in dql before dmaengine starts", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50298", " - net: enetc: allocate vf_state during PF probes", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50299", " - sctp: properly validate chunk size in sctp_sf_ootb()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50300", " - regulator: rtq2208: Fix uninitialized use of regulator_config", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50301", " - security/keys: fix slab-out-of-bounds in key_task_permission", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53072", " - platform/x86/amd/pmc: Detect when STB is not available", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50302", " - HID: core: zero-initialize the report buffer", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53068", " - firmware: arm_scmi: Fix slab-use-after-free in scmi_bus_notifier()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53069", " - firmware: qcom: scm: fix a NULL-pointer dereference", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629)", " - drm/amdgpu: fix random data corruption for sdma 7", " - cgroup: Fix potential overflow issue when checking max_depth", " - spi: geni-qcom: Fix boot warning related to pm_runtime and devres", " - perf trace: Fix non-listed archs in the syscalltbl routines", " - perf python: Fix up the build on architectures without HAVE_KVM_STAT_SUPPORT", " - scsi: scsi_debug: Fix do_device_access() handling of unexpected SG copy", " length", " - wifi: iwlegacy: Fix \"field-spanning write\" warning in il_enqueue_hcmd()", " - mac80211: MAC80211_MESSAGE_TRACING should depend on TRACING", " - wifi: mac80211: skip non-uploaded keys in ieee80211_iter_keys", " - wifi: ath11k: Fix invalid ring usage in full monitor mode", " - wifi: rtw89: pci: early chips only enable 36-bit DMA on specific PCI hosts", " - wifi: brcm80211: BRCM_TRACING should depend on TRACING", " - RDMA/cxgb4: Dump vendor specific QP details", " - RDMA/mlx5: Round max_rd_atomic/max_dest_rd_atomic up instead of down", " - RDMA/bnxt_re: Fix the usage of control path spin locks", " - RDMA/bnxt_re: synchronize the qp-handle table array", " - wifi: iwlwifi: mvm: really send iwl_txpower_constraints_cmd", " - wifi: iwlwifi: mvm: don't add default link in fw restart flow", " - Revert \"wifi: iwlwifi: remove retry loops in start\"", " - ASoC: cs42l51: Fix some error handling paths in cs42l51_probe()", " - net: stmmac: dwmac4: Fix high address display by updating reg_space[] from", " register values", " - dpll: add Embedded SYNC feature for a pin", " - ice: add callbacks for Embedded SYNC enablement on dpll pins", " - gtp: allow -1 to be specified as file description from userspace", " - bpf: Force checkpoint when jmp history is too long", " - bpf: Add bpf_mem_alloc_check_size() helper", " - net: skip offload for NETIF_F_IPV6_CSUM if ipv6 header contains extension", " - mlxsw: spectrum_ptp: Add missing verification before pushing Tx header", " - mlxsw: pci: Sync Rx buffers for CPU", " - mlxsw: pci: Sync Rx buffers for device", " - net: ethernet: mtk_wed: fix path of MT7988 WO firmware", " - bpf, test_run: Fix LIVE_FRAME frame update after a page has been recycled", " - iomap: improve shared block detection in iomap_unshare_iter", " - iomap: don't bother unsharing delalloc extents", " - iomap: share iomap_unshare_iter predicate code with fsdax", " - fsdax: remove zeroing code from dax_unshare_iter", " - iomap: turn iomap_want_unshare_iter into an inline function", " - kasan: Fix Software Tag-Based KASAN with GCC", " - firmware: arm_sdei: Fix the input parameter of cpuhp_remove_state()", " - afs: Fix missing subdir edit when renamed between parent dirs", " - gpio: sloppy-logic-analyzer: Check for error code from devm_mutex_init()", " call", " - smb: client: fix parsing of device numbers", " - smb: client: set correct device number on nfs reparse points", " - drm/mediatek: ovl: Remove the color format comment for ovl_fmt_convert()", " - drm/mediatek: Fix color format MACROs in OVL", " - drm/mediatek: Fix get efuse issue for MT8188 DPTX", " - drm/mediatek: Use cmdq_pkt_create() and cmdq_pkt_destroy()", " - cxl/events: Fix Trace DRAM Event Record", " - PCI: Fix pci_enable_acs() support for the ACS quirks", " - nvme: module parameter to disable pi with offsets", " - drm/panthor: Fix firmware initialization on systems with a page size > 4k", " - drm/panthor: Fail job creation when the group is dead", " - drm/panthor: Report group as timedout when we fail to properly suspend", " - fs/ntfs3: Fix warning possible deadlock in ntfs_set_state", " - fs/ntfs3: Stale inode instead of bad", " - rust: device: change the from_raw() function", " - scsi: scsi_transport_fc: Allow setting rport state to current state", " - cifs: Improve creating native symlinks pointing to directory", " - cifs: Fix creating native symlinks pointing to current or parent directory", " - ACPI: resource: Fold Asus Vivobook Pro N6506M* DMI quirks together", " - powercap: intel_rapl_msr: Add PL4 support for Arrowlake-U", " - thermal: intel: int340x: processor: Remove MMIO RAPL CPU hotplug support", " - thermal: intel: int340x: processor: Add MMIO RAPL PL4 support", " - net: amd: mvme147: Fix probe banner message", " - NFS: remove revoked delegation from server's delegation list", " - misc: sgi-gru: Don't disable preemption in GRU driver", " - NFSD: Initialize struct nfsd4_copy earlier", " - NFSD: Never decrement pending_async_copies on error", " - ALSA: usb-audio: Add quirks for Dell WD19 dock", " - wifi: rtlwifi: rtl8192du: Don't claim USB ID 0bda:8171", " - usbip: tools: Fix detach_port() invalid port error path", " - usb: phy: Fix API devm_usb_put_phy() can not release the phy", " - usb: typec: fix unreleased fwnode_handle in typec_port_register_altmodes()", " - usb: typec: tcpm: restrict SNK_WAIT_CAPABILITIES_TIMEOUT transitions to non", " self-powered devices", " - usb: typec: qcom-pmic-typec: use fwnode_handle_put() to release fwnodes", " - usb: typec: qcom-pmic-typec: fix missing fwnode removal in error path", " - xhci: Fix Link TRB DMA in command ring stopped completion event", " - xhci: Use pm_runtime_get to prevent RPM on unsupported systems", " - Revert \"driver core: Fix uevent_show() vs driver detach race\"", " - dt-bindings: iio: adc: ad7380: fix ad7380-4 reference supply", " - iio: light: veml6030: fix microlux value calculation", " - RISC-V: ACPI: fix early_ioremap to early_memremap", " - tools/mm: -Werror fixes in page-types/slabinfo", " - mm: shrinker: avoid memleak in alloc_shrinker_info", " - firmware: microchip: auto-update: fix poll_complete() to not report spurious", " timeout errors", " - thunderbolt: Honor TMU requirements in the domain when setting TMU mode", " - soc: qcom: pmic_glink: Handle GLINK intent allocation rejections", " - cxl/port: Fix CXL port initialization order when the subsystem is built-in", " - mmc: sdhci-pci-gli: GL9767: Fix low power mode on the set clock function", " - mmc: sdhci-pci-gli: GL9767: Fix low power mode in the SD Express process", " - block: fix sanity checks in blk_rq_map_user_bvec", " - phy: freescale: imx8m-pcie: Do CMN_RST just before PHY PLL lock check", " - btrfs: merge btrfs_orig_bbio_end_io() into btrfs_bio_end_io()", " - riscv: vdso: Prevent the compiler from inserting calls to memset()", " - Input: edt-ft5x06 - fix regmap leak when probe fails", " - ALSA: hda/realtek: Limit internal Mic boost on Dell platform", " - riscv: efi: Set NX compat flag in PE/COFF header", " - riscv: Use '%u' to format the output of 'cpu'", " - riscv: Remove unused GENERATING_ASM_OFFSETS", " - riscv: Remove duplicated GET_RM", " - cxl/port: Fix cxl_bus_rescan() vs bus_rescan_devices()", " - cxl/acpi: Ensure ports ready at cxl_acpi_probe() return", " - posix-cpu-timers: Clear TICK_DEP_BIT_POSIX_TIMER on clone", " - tpm: Return tpm2_sessions_init() when null key creation fails", " - tpm: Rollback tpm2_load_null()", " - drm/amdgpu/smu13: fix profile reporting", " - tpm: Lazily flush the auth session", " - mei: use kvmalloc for read buffer", " - x86/traps: Enable UBSAN traps on x86", " - x86/traps: move kmsan check after instrumentation_begin", " - accel/ivpu: Fix NOC firewall interrupt handling", " - ALSA: hda/realtek: Fix headset mic on TUXEDO Gemini 17 Gen3", " - ALSA: hda/realtek: Fix headset mic on TUXEDO Stellaris 16 Gen6 mb1", " - nvme: re-fix error-handling for io_uring nvme-passthrough", " - kasan: remove vmalloc_percpu test", " - drm/tests: helpers: Add helper for drm_display_mode_from_cea_vic()", " - drm/xe: Fix register definition order in xe_regs.h", " - drm/xe: Kill regs/xe_sriov_regs.h", " - drm/xe: Add mmio read before GGTT invalidate", " - drm/xe: Don't short circuit TDR on jobs not started", " - btrfs: fix extent map merging not happening for adjacent extents", " - btrfs: fix defrag not merging contiguous extents due to merged extent maps", " - gpiolib: fix debugfs newline separators", " - gpiolib: fix debugfs dangling chip separator", " - vmscan,migrate: fix page count imbalance on node stats when demoting pages", " - mm, mmap: limit THP alignment of anonymous mappings to PMD-aligned sizes", " - Input: fix regression when re-registering input handlers", " - mm: multi-gen LRU: ignore non-leaf pmd_young for force_scan=true", " - mm: multi-gen LRU: remove MM_LEAF_OLD and MM_NONLEAF_TOTAL stats", " - mm: shrink skip folio mapped by an exiting process", " - mm: multi-gen LRU: use {ptep,pmdp}_clear_young_notify()", " - riscv: dts: starfive: Update ethernet phy0 delay parameter values for Star64", " - riscv: dts: starfive: disable unused csi/camss nodes", " - arm64: dts: qcom: msm8939: revert use of APCS mbox for RPM", " - arm64: dts: qcom: x1e80100-yoga-slim7x: fix nvme regulator boot glitch", " - arm64: dts: qcom: x1e80100: Fix up BAR spaces", " - arm64: dts: qcom: x1e80100-vivobook-s15: fix nvme regulator boot glitch", " - arm64: dts: qcom: x1e80100: fix PCIe4 interconnect", " - arm64: dts: qcom: x1e80100-qcp: fix nvme regulator boot glitch", " - arm64: dts: qcom: x1e80100-crd: fix nvme regulator boot glitch", " - arm64: dts: qcom: x1e80100: Add Broadcast_AND region in LLCC block", " - arm64: dts: qcom: x1e80100: fix PCIe4 and PCIe6a PHY clocks", " - drm/xe/xe2hpg: Add Wa_15016589081", " - drm/amdgpu/swsmu: fix ordering for setting workload_mask", " - drm/amdgpu/swsmu: default to fullscreen 3D profile for dGPUs", " - fs/ntfs3: Sequential field availability check in mi_enum_attr()", " - drm/amdgpu: handle default profile on on devices without fullscreen 3D", " - MIPS: export __cmpxchg_small()", " - RISC-V: disallow gcc + rust builds", " - [Config] updateconfigs after disabling rust with gcc on riscv", " - rcu/kvfree: Add kvfree_rcu_barrier() API", " - rcu/kvfree: Refactor kvfree_rcu_queue_batch()", " - Linux 6.11.7", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50212", " - lib: alloc_tag_module_unload must wait for pending kfree_rcu calls", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53046", " - arm64: dts: imx8ulp: correct the flexspi compatible string", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53052", " - io_uring/rw: fix missing NOWAIT check for O_DIRECT start write", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50213", " - drm/tests: hdmi: Fix memory leaks in drm_display_mode_from_cea_vic()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50214", " - drm/connector: hdmi: Fix memory leak in drm_display_mode_from_cea_vic()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50215", " - nvmet-auth: assign dh_key to NULL after kfree_sensitive", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50216", " - xfs: fix finding a last resort AG in xfs_filestream_pick_ag", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50217", " - btrfs: fix use-after-free of block device file in", " __btrfs_free_extra_devids()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53043", " - mctp i2c: handle NULL header address", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50303", " - resource,kexec: walk_system_ram_res_rev must retain resource flags", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50218", " - ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50219", " - mm/page_alloc: let GFP_ATOMIC order-0 allocs access highatomic reserves", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50263", " - fork: only invoke khugepaged, ksm hooks if no error", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50220", " - fork: do not invoke uffd on fork if error occurs", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53047", " - mptcp: init: protect sched with rcu_read_lock", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50221", " - drm/amd/pm: Vangogh: Fix kernel memory out of bounds write", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50222", " - iov_iter: fix copy_page_from_iter_atomic() if KMAP_LOCAL_FORCE_MAP", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50223", " - sched/numa: Fix the potential null pointer dereference in task_numa_work()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53053", " - scsi: ufs: core: Fix another deadlock during RTC update", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53075", " - riscv: Prevent a bad reference count on CPU nodes", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50224", " - spi: spi-fsl-dspi: Fix crash when not using GPIO chip select", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50225", " - btrfs: fix error propagation of split bios", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53054", " - cgroup/bpf: use a dedicated workqueue for cgroup bpf destruction", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50226", " - cxl/port: Fix use-after-free, permit out-of-order decoder shutdown", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50227", " - thunderbolt: Fix KASAN reported stack out-of-bounds read in", " tb_retimer_scan()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50228", " - mm: shmem: fix data-race in shmem_getattr()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50229", " - nilfs2: fix potential deadlock with newly created symlinks", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50230", " - nilfs2: fix kernel bug due to missing clearing of checked flag", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50231", " - iio: gts-helper: Fix memory leaks in iio_gts_build_avail_scale_table()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53076", " - iio: gts-helper: Fix memory leaks for the error path of", " iio_gts_build_avail_scale_table()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50232", " - iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50233", " - staging: iio: frequency: ad9832: fix division by zero in", " ad9832_calc_freqreg()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53055", " - wifi: iwlwifi: mvm: fix 6 GHz scan construction", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50234", " - wifi: iwlegacy: Clear stale interrupts before resuming device", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50235", " - wifi: cfg80211: clear wdev->cqm_config pointer on free", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50236", " - wifi: ath10k: Fix memory leak in management tx", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50237", " - wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50238", " - phy: qcom: qmp-usbc: fix NULL-deref on runtime suspend", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50239", " - phy: qcom: qmp-usb-legacy: fix NULL-deref on runtime suspend", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50240", " - phy: qcom: qmp-usb: fix NULL-deref on runtime suspend", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53077", " - rpcrdma: Always release the rpcrdma_device's xa_array", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50242", " - fs/ntfs3: Additional check in ntfs_file_release", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50243", " - fs/ntfs3: Fix general protection fault in run_is_mapped_full", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50244", " - fs/ntfs3: Additional check in ni_clear()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50245", " - fs/ntfs3: Fix possible deadlock in mi_read", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50246", " - fs/ntfs3: Add rough attr alloc_size check", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50247", " - fs/ntfs3: Check if more than chunk-size bytes are written", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50248", " - ntfs3: Add bounds checking to mi_enum_attr()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53078", " - drm/tegra: Fix NULL vs IS_ERR() check in probe()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53056", " - drm/mediatek: Fix potential NULL dereference in mtk_crtc_destroy()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50249", " - ACPI: CPPC: Make rmw_lock a raw_spin_lock", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50250", " - fsdax: dax_unshare_iter needs to copy entire blocks", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50251", " - netfilter: nft_payload: sanitize offset and length before calling", " skb_checksum()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50252", " - mlxsw: spectrum_ipip: Fix memory leak when changing remote IPv6 address", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50253", " - bpf: Check the validity of nr_words in bpf_iter_bits_new()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50254", " - bpf: Free dynamically allocated bits in bpf_iter_bits_destroy()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50255", " - Bluetooth: hci: fix null-ptr-deref in hci_read_supported_codecs", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50256", " - netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50257", " - netfilter: Fix use-after-free in get_info()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50258", " - net: fix crash when config small gso_max_size/gso_ipv4_max_size", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50262", " - bpf: Fix out-of-bounds write in trie_get_next_key()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53044", " - net/sched: sch_api: fix xa_insert() error path in tcf_block_get_ext()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50259", " - netdevsim: Add trailing zero to terminate the string in", " nsim_nexthop_bucket_activity_write()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50304", " - ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53042", " - ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_init_flow()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53048", " - ice: fix crash on probe for DPLL enabled E810 LOM", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53058", " - net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50260", " - sock_map: fix a NULL pointer dereference in sock_map_link_update_prog()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53045", " - ASoC: dapm: fix bounds checker error in dapm_widget_list_create", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50261", " - macsec: Fix use-after-free while sending the offloading packet", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53059", " - wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53074", " - wifi: iwlwifi: mvm: don't leak a link on AP removal", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53049", " - slub/kunit: fix a WARNING due to unwrapped __kmalloc_cache_noprof", "", " * Oracular update: v6.11.6 upstream stable release (LP: #2091386)", " - bpf: Use raw_spinlock_t in ringbuf", " - iio: accel: bma400: Fix uninitialized variable field_value in tap event", " handling.", " - reset: starfive: jh71x0: Fix accessing the empty member on JH7110 SoC", " - bpf: sync_linked_regs() must preserve subreg_def", " - bpf: Make sure internal and UAPI bpf_redirect flags don't overlap", " - irqchip/riscv-imsic: Fix output text of base address", " - bpf: devmap: provide rxq after redirect", " - cpufreq/amd-pstate: Fix amd_pstate mode switch on shared memory systems", " - lib/Kconfig.debug: fix grammar in RUST_BUILD_ASSERT_ALLOW", " - bpf: Fix memory leak in bpf_core_apply", " - RDMA/bnxt_re: Fix a possible memory leak", " - RDMA/bnxt_re: Fix incorrect AVID type in WQE structure", " - RDMA/bnxt_re: Add a check for memory allocation", " - x86/resctrl: Avoid overflow in MB settings in bw_validate()", " - ARM: dts: bcm2837-rpi-cm3-io3: Fix HDMI hpd-gpio pin", " - clk: rockchip: fix finding of maximum clock ID", " - bpf: Check the remaining info_cnt before repeating btf fields", " - bpf: fix unpopulated name_len field in perf_event link info", " - selftests/bpf: fix perf_event link info name_len assertion", " - riscv, bpf: Fix possible infinite tailcall when CONFIG_CFI_CLANG is enabled", " - s390/pci: Handle PCI error codes other than 0x3a", " - bpf: fix kfunc btf caching for modules", " - iio: frequency: {admv4420,adrf6780}: format Kconfig entries", " - iio: frequency: admv4420: fix missing select REMAP_SPI in Kconfig", " - drm/vmwgfx: Handle possible ENOMEM in vmw_stdu_connector_atomic_check", " - selftests/bpf: Fix cross-compiling urandom_read", " - bpf: Fix unpopulated path_size when uprobe_multi fields unset", " - sched/core: Disable page allocation in task_tick_mm_cid()", " - ALSA: hda/cs8409: Fix possible NULL dereference", " - firmware: arm_scmi: Fix the double free in scmi_debugfs_common_setup()", " - RDMA/cxgb4: Fix RDMA_CM_EVENT_UNREACHABLE error for iWARP", " - RDMA/irdma: Fix misspelling of \"accept*\"", " - RDMA/srpt: Make slab cache names unique", " - elevator: do not request_module if elevator exists", " - elevator: Remove argument from elevator_find_get", " - ipv4: give an IPv4 dev to blackhole_netdev", " - net: sparx5: fix source port register when mirroring", " - RDMA/bnxt_re: Fix the max CQ WQEs for older adapters", " - RDMA/bnxt_re: Fix out of bound check", " - RDMA/bnxt_re: Fix incorrect dereference of srq in async event", " - RDMA/bnxt_re: Return more meaningful error", " - RDMA/bnxt_re: Avoid CPU lockups due fifo occupancy check loop", " - RDMA/bnxt_re: Get the toggle bits from SRQ events", " - RDMA/bnxt_re: Change the sequence of updating the CQ toggle value", " - RDMA/bnxt_re: Fix a bug while setting up Level-2 PBL pages", " - RDMA/bnxt_re: Fix the GID table length", " - accel/qaic: Fix the for loop used to walk SG table", " - drm/panel: himax-hx83102: Adjust power and gamma to optimize brightness", " - drm/msm/dpu: make sure phys resources are properly initialized", " - drm/msm/dpu: move CRTC resource assignment to dpu_encoder_virt_atomic_check", " - drm/msm/dpu: check for overflow in _dpu_crtc_setup_lm_bounds()", " - drm/msm/dsi: improve/fix dsc pclk calculation", " - drm/msm/dsi: fix 32-bit signed integer extension in pclk_rate calculation", " - drm/msm: Avoid NULL dereference in msm_disp_state_print_regs()", " - drm/msm: Allocate memory for disp snapshot with kvzalloc()", " - firmware: arm_scmi: Queue in scmi layer for mailbox implementation", " - net/smc: Fix memory leak when using percpu refs", " - [PATCH} hwmon: (jc42) Properly detect TSE2004-compliant devices again", " - net: usb: usbnet: fix race in probe failure", " - net: stmmac: dwmac-tegra: Fix link bring-up sequence", " - octeontx2-af: Fix potential integer overflows on integer shifts", " - ring-buffer: Fix reader locking when changing the sub buffer order", " - drm/amd/amdgpu: Fix double unlock in amdgpu_mes_add_ring", " - macsec: don't increment counters for an unrelated SA", " - netdevsim: use cond_resched() in nsim_dev_trap_report_work()", " - net: ethernet: aeroflex: fix potential memory leak in", " greth_start_xmit_gbit()", " - net/smc: Fix searching in list of known pnetids in smc_pnet_add_pnetid", " - net: xilinx: axienet: fix potential memory leak in axienet_start_xmit()", " - net: ethernet: rtsn: fix potential memory leak in rtsn_start_xmit()", " - bpf: Fix truncation bug in coerce_reg_to_size_sx()", " - net: systemport: fix potential memory leak in bcm_sysport_xmit()", " - irqchip/renesas-rzg2l: Fix missing put_device", " - drm/msm/dpu: Don't always set merge_3d pending flush", " - drm/msm/dpu: don't always program merge_3d block", " - net: bcmasp: fix potential memory leak in bcmasp_xmit()", " - drm/msm/a6xx+: Insert a fence wait before SMMU table update", " - tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink().", " - net: dsa: mv88e6xxx: Fix the max_vid definition for the MV88E6361", " - genetlink: hold RCU in genlmsg_mcast()", " - ravb: Remove setting of RX software timestamp", " - net: ravb: Only advertise Rx/Tx timestamps if hardware supports it", " - net: dsa: vsc73xx: fix reception from VLAN-unaware bridges", " - scsi: target: core: Fix null-ptr-deref in target_alloc_device()", " - smb: client: fix possible double free in smb2_set_ea()", " - smb: client: fix OOBs when building SMB2_IOCTL request", " - usb: typec: altmode should keep reference to parent", " - s390: Initialize psw mask in perf_arch_fetch_caller_regs()", " - drm/xe: fix unbalanced rpm put() with fence_fini()", " - drm/xe: fix unbalanced rpm put() with declare_wedged()", " - drm/xe: Take job list lock in xe_sched_add_pending_job", " - drm/xe: Don't free job in TDR", " - drm/xe: Use bookkeep slots for external BO's in exec IOCTL", " - bpf: Fix link info netfilter flags to populate defrag flag", " - Bluetooth: bnep: fix wild-memory-access in proto_unregister", " - vmxnet3: Fix packet corruption in vmxnet3_xdp_xmit_frame", " - net: ethernet: mtk_eth_soc: fix memory corruption during fq dma init", " - net/mlx5: Check for invalid vector index on EQ creation", " - net/mlx5: Fix command bitmask initialization", " - net/mlx5: Unregister notifier on eswitch init failure", " - net/mlx5e: Don't call cleanup on profile rollback failure", " - bpf, sockmap: SK_DROP on attempted redirects of unsupported af_vsock", " - vsock: Update rx_bytes on read_skb()", " - vsock: Update msg_count on read_skb()", " - bpf, vsock: Drop static vsock_bpf_prot initialization", " - riscv, bpf: Make BPF_CMPXCHG fully ordered", " - nvme-pci: fix race condition between reset and nvme_dev_disable()", " - bpf: Fix iter/task tid filtering", " - bpf: Fix incorrect delta propagation between linked registers", " - bpf: Fix print_reg_state's constant scalar dump", " - cdrom: Avoid barrier_nospec() in cdrom_ioctl_media_changed()", " - fgraph: Allocate ret_stack_list with proper size", " - mm: shmem: rename shmem_is_huge() to shmem_huge_global_enabled()", " - mm: shmem: move shmem_huge_global_enabled() into", " shmem_allowable_huge_orders()", " - mm: huge_memory: add vma_thp_disabled() and thp_disabled_by_hw()", " - mm: don't install PMD mappings when THPs are disabled by the hw/process/vma", " - iio: adc: ti-lmp92064: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - xhci: dbgtty: remove kfifo_out() wrapper", " - xhci: dbgtty: use kfifo from tty_port struct", " - xhci: dbc: honor usb transfer size boundaries.", " - uprobe: avoid out-of-bounds memory access of fetching args", " - drm/vboxvideo: Replace fake VLA at end of vbva_mouse_pointer_shape with real", " VLA", " - ASoC: amd: yc: Add quirk for HP Dragonfly pro one", " - ASoC: codecs: lpass-rx-macro: add missing CDC_RX_BCL_VBAT_RF_PROC2 to", " default regs values", " - ASoC: fsl_sai: Enable 'FIFO continue on error' FCONT bit", " - arm64: Force position-independent veneers", " - udf: refactor udf_current_aext() to handle error", " - udf: refactor udf_next_aext() to handle error", " - udf: refactor inode_bmap() to handle error", " - udf: fix uninit-value use in udf_get_fileshortad", " - ASoC: qcom: sm8250: add qrb4210-rb2-sndcard compatible string", " - fsnotify: Avoid data race between fsnotify_recalc_mask() and", " fsnotify_object_watched()", " - drm/xe/mcr: Use Xe2_LPM steering tables for Xe2_HPM", " - cifs: Validate content of NFS reparse point buffer", " - LoongArch: Don't crash in stack_top() for tasks without vDSO", " - objpool: fix choosing allocation for percpu slots", " - jfs: Fix sanity check in dbMount", " - tracing/probes: Fix MAX_TRACE_ARGS limit handling", " - tracing: Consider the NULL character when validating the event length", " - xfrm: extract dst lookup parameters into a struct", " - xfrm: respect ip protocols rules criteria when performing dst lookups", " - xfrm: validate new SA's prefixlen using SA family when sel.family is unset", " - netfilter: bpf: must hold reference on net namespace", " - net: pse-pd: Fix out of bound for loop", " - net/sun3_82586: fix potential memory leak in sun3_82586_send_packet()", " - be2net: fix potential memory leak in be_xmit()", " - net: plip: fix break; causing plip to never transmit", " - bnxt_en: replace ptp_lock with irqsave variant", " - octeon_ep: Implement helper for iterating packets in Rx queue", " - octeon_ep: Add SKB allocation failures handling in __octep_oq_process_rx()", " - net: dsa: mv88e6xxx: Fix error when setting port policy on mv88e6393x", " - bpf, arm64: Fix address emission with tag-based KASAN enabled", " - fsl/fman: Save device references taken in mac_probe()", " - fsl/fman: Fix refcount handling of fman-related devices", " - net: wwan: fix global oob in wwan_rtnl_policy", " - net: fix races in netdev_tx_sent_queue()/dev_watchdog()", " - virtio_net: fix integer overflow in stats", " - mlxsw: spectrum_router: fix xa_store() error checking", " - net: usb: usbnet: fix name regression", " - bpf: Preserve param->string when parsing mount options", " - bpf: Add MEM_WRITE attribute", " - bpf: Fix overloading of MEM_UNINIT's meaning", " - bpf: Remove MEM_UNINIT from skb/xdp MTU helpers", " - net/sched: act_api: deny mismatched skip_sw/skip_hw flags for actions", " created by classifiers", " - net: sched: fix use-after-free in taprio_change()", " - net: sched: use RCU read-side critical section in taprio_dump()", " - r8169: avoid unsolicited interrupts", " - posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime()", " - Bluetooth: hci_core: Disable works on hci_unregister_dev", " - Bluetooth: SCO: Fix UAF on sco_sock_timeout", " - Bluetooth: ISO: Fix UAF on iso_sock_timeout", " - bpf,perf: Fix perf_event_detach_bpf_prog error handling", " - bpf: fix do_misc_fixups() for bpf_get_branch_snapshot()", " - net: dsa: microchip: disable EEE for KSZ879x/KSZ877x/KSZ876x", " - net: dsa: mv88e6xxx: group cycle counter coefficients", " - net: dsa: mv88e6xxx: read cycle counter period from hardware", " - net: dsa: mv88e6xxx: support 4000ps cycle counter period", " - bpf: Add the missing BPF_LINK_TYPE invocation for sockmap", " - ASoC: dt-bindings: davinci-mcasp: Fix interrupts property", " - ASoC: dt-bindings: davinci-mcasp: Fix interrupt properties", " - ASoC: loongson: Fix component check failed on FDT systems", " - ASoC: topology: Bump minimal topology ABI version", " - ASoC: max98388: Fix missing increment of variable slot_found", " - ASoC: rsnd: Fix probe failure on HiHope boards due to endpoint parsing", " - PCI: Hold rescan lock while adding devices during host probe", " - fs: pass offset and result to backing_file end_write() callback", " - fuse: update inode size after extending passthrough write", " - ASoC: fsl_micfil: Add a flag to distinguish with different volume control", " types", " - ALSA: firewire-lib: Avoid division by zero in apply_constraint_to_size()", " - fbdev: wm8505fb: select CONFIG_FB_IOMEM_FOPS", " - powercap: dtpm_devfreq: Fix error check against dev_pm_qos_add_request()", " - nfsd: cancel nfsd_shrinker_work using sync mode in nfs4_state_shutdown_net", " - ALSA: hda/realtek: Update default depop procedure", " - smb: client: Handle kstrdup failures for passwords", " - cifs: fix warning when destroy 'cifs_io_request_pool'", " - PCI/pwrctl: Add WCN6855 support", " - PCI/pwrctl: Abandon QCom WCN probe on pre-pwrseq device-trees", " - cpufreq: CPPC: fix perf_to_khz/khz_to_perf conversion exception", " - btrfs: qgroup: set a more sane default value for subtree drop threshold", " - btrfs: clear force-compress on remount when compress mount option is given", " - btrfs: fix passing 0 to ERR_PTR in btrfs_search_dir_index_item()", " - perf/x86/rapl: Fix the energy-pkg event for AMD CPUs", " - btrfs: reject ro->rw reconfiguration if there are hard ro requirements", " - btrfs: zoned: fix zone unusable accounting for freed reserved extent", " - btrfs: fix read corruption due to race with extent map merging", " - drm/amd: Guard against bad data for ATIF ACPI method", " - ACPI: resource: Add LG 16T90SP to irq1_level_low_skip_override[]", " - ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context", " - ACPI: button: Add DMI quirk for Samsung Galaxy Book2 to fix initial lid", " detection issue", " - nilfs2: fix kernel bug due to missing clearing of buffer delay flag", " - fs: don't try and remove empty rbtree node", " - xfs: don't fail repairs on metadata files with no attr fork", " - openat2: explicitly return -E2BIG for (usize > PAGE_SIZE)", " - KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory", " - KVM: arm64: Unregister redistributor for failed vCPU creation", " - KVM: arm64: Fix shift-out-of-bounds bug", " - KVM: arm64: Don't eagerly teardown the vgic on init error", " - firewire: core: fix invalid port index for parent device", " - x86/lam: Disable ADDRESS_MASKING in most cases", " - [Config] updateconfigs to disable ADDRESS_MASKING", " - x86/sev: Ensure that RMP table fixups are reserved", " - ALSA: hda/tas2781: select CRC32 instead of CRC32_SARWATE", " - ALSA: hda/realtek: Add subwoofer quirk for Acer Predator G9-593", " - LoongArch: Get correct cores_per_package for SMT systems", " - LoongArch: Enable IRQ if do_ale() triggered in irq-enabled context", " - LoongArch: Make KASAN usable for variable cpu_vabits", " - xfrm: fix one more kernel-infoleak in algo dumping", " - hv_netvsc: Fix VF namespace also in synthetic NIC NETDEV_REGISTER event", " - md/raid10: fix null ptr dereference in raid10_size()", " - drm/bridge: Fix assignment of the of_node of the parent to aux bridge", " - drm/amd/display: Disable PSR-SU on Parade 08-01 TCON too", " - platform/x86/intel/pmc: Fix pmc_core_iounmap to call iounmap for valid", " addresses", " - fgraph: Fix missing unlock in register_ftrace_graph()", " - fgraph: Change the name of cpuhp state to \"fgraph:online\"", " - net: phy: dp83822: Fix reset pin definitions", " - nfsd: fix race between laundromat and free_stateid", " - drm/amd/display: temp w/a for DP Link Layer compliance", " - ata: libata: Set DID_TIME_OUT for commands that actually timed out", " - ASoC: SOF: Intel: hda-loader: do not wait for HDaudio IOC", " - ASoC: SOF: Intel: hda: Handle prepare without close for non-HDA DAI's", " - ASoC: SOF: Intel: hda: Always clean up link DMA during stop", " - ASoC: SOF: ipc4-topology: Do not set ALH node_id for aggregated DAIs", " - ASoC: dapm: avoid container_of() to get component", " - ASoC: qcom: sc7280: Fix missing Soundwire runtime stream alloc", " - ASoC: qcom: sdm845: add missing soundwire runtime stream alloc", " - ASoC: qcom: Fix NULL Dereference in asoc_qcom_lpass_cpu_platform_probe()", " - Revert \" fs/9p: mitigate inode collisions\"", " - Revert \"fs/9p: remove redundant pointer v9ses\"", " - Revert \"fs/9p: fix uaf in in v9fs_stat2inode_dotl\"", " - Revert \"fs/9p: simplify iget to remove unnecessary paths\"", " - soundwire: intel_ace2x: Send PDI stream number during prepare", " - x86: support user address masking instead of non-speculative conditional", " - x86: fix whitespace in runtime-const assembler output", " - x86: fix user address masking non-canonical speculation issue", " - platform/x86: dell-wmi: Ignore suspend notifications", " - ACPI: PRM: Clean up guid type in struct prm_handler_info", " - ASoC: qcom: Select missing common Soundwire module code on SDM845", " - Linux 6.11.6", "", " * ovs/linuxbridge jobs running on ubuntu jammy broken with latest kernel", " 5.15.0-127.137 (LP: #2091990)", " - netfilter: xtables: fix typo causing some targets not to load on IPv6", "", " * By always inlining _compound_head(), clone() sees 3%+ performance increase", " (LP: #2089327)", " - mm: always inline _compound_head() with", " CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP=y", "", " * Keyboard backlight controls do not work on Asus ROG Zephyrus GA503RM in", " Oracular (LP: #2089113)", " - hid-asus: use hid for brightness control on keyboard", "", " * Random flickering with Intel i915 (Comet Lake and Kaby Lake) on Linux 6.8+", " (LP: #2086587)", " - SAUCE: iommu/intel: disable DMAR for KBL and CML integrated gfx", "", " * Add list of source files to linux-buildinfo (LP: #2086606)", " - [Packaging] Sort build dependencies alphabetically", " - [Packaging] Add list of used source files to buildinfo package", "", " * asus: Fix thermal profile initialization on Lunar Lake (LP: #2085950)", " - platform/x86: asus-wmi: Fix thermal profile initialization", "", " * drm/xe: Fix LNL getting wedged after idling (LP: #2085944)", " - drm/xe/guc/ct: Flush g2h worker in case of g2h response timeout", "", " * UFS: uspi->s_3apb UBSAN: shift-out-of-bounds (LP: #2087853)", " - ufs: ufs_sb_private_info: remove unused s_{2, 3}apb fields", "", " * Mute/mic LEDs don't function on HP EliteBook 645 G10 (LP: #2087983)", " - ALSA: hda/realtek: fix mute/micmute LEDs for a HP EliteBook 645 G10", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152)", " - ALSA: scarlett2: Add error check after retrieving PEQ filter values", " - ALSA: hda/conexant - Fix audio routing for HP EliteOne 1000 G2", " - net: enetc: remove xdp_drops statistic from enetc_xdp_drop()", " - net: enetc: block concurrent XDP transmissions during ring reconfiguration", " - net: enetc: disable Tx BD rings after they are empty", " - net: enetc: disable NAPI after all rings are disabled", " - net: enetc: add missing static descriptor and inline keyword", " - udp: Compute L4 checksum as usual when not segmenting the skb", " - arm64: dts: marvell: cn9130-sr-som: fix cp0 mdio pin numbers", " - arm64: probes: Fix simulate_ldr*_literal()", " - net: macb: Avoid 20s boot delay by skipping MDIO bus registration for fixed-", " link PHY", " - selftests: mptcp: join: test for prohibited MPC to port-based endp", " - fat: fix uninitialized variable", " - mm: khugepaged: fix the arguments order in khugepaged_collapse_file trace", " point", " - net: fec: Move `fec_ptp_read()` to the top of the file", " - net: fec: Remove duplicated code", " - mptcp: prevent MPC handshake on port-based signal endpoints", " - s390/sclp: Deactivate sclp after all its users", " - s390/sclp_vt220: Convert newlines to CRLF instead of LFCR", " - KVM: s390: gaccess: Check if guest address is in memslot", " - KVM: s390: Change virtual to physical address access in diag 0x258 handler", " - x86/cpufeatures: Define X86_FEATURE_AMD_IBPB_RET", " - x86/cpufeatures: Add a IBPB_NO_RET BUG flag", " - x86/entry: Have entry_ibpb() invalidate return predictions", " - x86/bugs: Skip RSB fill at VMEXIT", " - x86/bugs: Do not use UNTRAIN_RET with IBPB on entry", " - fgraph: Use CPU hotplug mechanism to initialize idle shadow stacks", " - Input: xpad - add support for 8BitDo Ultimate 2C Wireless Controller", " - io_uring/sqpoll: close race on waiting for sqring entries", " - selftest: hid: add the missing tests directory", " - Input: xpad - add support for MSI Claw A1M", " - scsi: mpi3mr: Validate SAS port assignments", " - scsi: ufs: core: Fix the issue of ICU failure", " - scsi: ufs: core: Requeue aborted request", " - drm/i915/dp_mst: Handle error during DSC BW overhead/slice calculation", " - drm/i915/dp_mst: Don't require DSC hblank quirk for a non-DSC compatible", " mode", " - drm/xe/xe_sync: initialise ufence.signalled", " - drm/xe/ufence: ufence can be signaled right after wait_woken", " - drm/vmwgfx: Cleanup kms setup without 3d", " - drm/vmwgfx: Handle surface check failure correctly", " - drm/amdgpu/mes: fix issue of writing to the same log buffer from 2 MES pipes", " - drm/amdgpu/smu13: always apply the powersave optimization", " - drm/amdgpu/swsmu: Only force workload setup on init", " - drm/amdgpu: prevent BO_HANDLES error from being overwritten", " - iio: dac: ad5770r: add missing select REGMAP_SPI in Kconfig", " - iio: dac: ltc1660: add missing select REGMAP_SPI in Kconfig", " - iio: dac: stm32-dac-core: add missing select REGMAP_MMIO in Kconfig", " - iio: adc: ti-ads8688: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: hid-sensors: Fix an error handling path in", " _hid_sensor_set_report_latency()", " - iio: light: veml6030: fix ALS sensor resolution", " - iio: light: opt3001: add missing full-scale range value", " - iio: amplifiers: ada4250: add missing select REGMAP_SPI in Kconfig", " - iio: frequency: adf4377: add missing select REMAP_SPI in Kconfig", " - iio: chemical: ens160: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: light: bu27008: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: magnetometer: af8133j: add missing select IIO_(TRIGGERED_)BUFFER in", " Kconfig", " - iio: resolver: ad2s1210 add missing select REGMAP in Kconfig", " - iio: pressure: bm1390: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: dac: ad5766: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: proximity: mb1232: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: dac: ad3552r: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: adc: ti-lmp92064: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: adc: ti-lmp92064: add missing select REGMAP_SPI in Kconfig", " - iio: adc: ti-ads124s08: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: resolver: ad2s1210: add missing select (TRIGGERED_)BUFFER in Kconfig", " - iio: adc: ad7944: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: accel: kx022a: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - Bluetooth: Remove debugfs directory on module init failure", " - Bluetooth: btusb: Fix not being able to reconnect after suspend", " - Bluetooth: btusb: Fix regression with fake CSR controllers 0a12:0001", " - xhci: Fix incorrect stream context type macro", " - xhci: Mitigate failed set dequeue pointer commands", " - USB: serial: option: add support for Quectel EG916Q-GL", " - USB: serial: option: add Telit FN920C04 MBIM compositions", " - usb: typec: qcom-pmic-typec: fix sink status being overwritten with RP_DEF", " - usb: gadget: f_uac2: fix return value for UAC2_ATTRIBUTE_STRING store", " - usb: dwc3: Wait for EndXfer completion before restoring GUSB2PHYCFG", " - usb: dwc3: core: Fix system suspend on TI AM62 platforms", " - misc: microchip: pci1xxxx: add support for NVMEM_DEVID_AUTO for EEPROM", " device", " - misc: microchip: pci1xxxx: add support for NVMEM_DEVID_AUTO for OTP device", " - serial: imx: Update mctrl old_status on RTSD interrupt", " - x86/resctrl: Annotate get_mem_config() functions as __init", " - x86/CPU/AMD: Only apply Zenbleed fix for Zen2 during late microcode load", " - x86/entry_32: Do not clobber user EFLAGS.ZF", " - irqchip/sifive-plic: Unmask interrupt in plic_irq_enable()", " - irqchip/sifive-plic: Return error code on failure", " - serial: qcom-geni: fix polled console initialisation", " - serial: qcom-geni: revert broken hibernation support", " - serial: qcom-geni: fix shutdown race", " - serial: qcom-geni: fix dma rx cancellation", " - serial: qcom-geni: fix receiver enable", " - mm: vmscan.c: fix OOM on swap stress test", " - ALSA: hda/conexant - Use cached pin control for Node 0x1d on HP EliteOne", " 1000 G2", " - Linux 6.11.5", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50192", " - irqchip/gic-v4: Don't allow a VMOVP on a dying VPE", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50069", " - pinctrl: apple: check devm_kasprintf() returned value", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50070", " - pinctrl: stm32: check devm_kasprintf() returned value", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50196", " - pinctrl: ocelot: fix system hang on level based interrupts", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50197", " - pinctrl: intel: platform: fix error path in device_for_each_child_node()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50071", " - pinctrl: nuvoton: fix a double free in ma35_pinctrl_dt_node_to_map_func()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50072", " - x86/bugs: Use code segment selector for VERW operand", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50073", " - tty: n_gsm: Fix use-after-free in gsm_cleanup_mux", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50193", " - x86/entry_32: Clear CPU buffers after register restore in NMI return", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50074", " - parport: Proper fix for array out-of-bounds access", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50100", " - USB: gadget: dummy-hcd: Fix \"task hung\" problem", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50075", " - xhci: tegra: fix checked USB2 port number", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50076", " - vt: prevent kernel-infoleak in con_font_get()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50077", " - Bluetooth: ISO: Fix multiple init when debugfs is disabled", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50078", " - Bluetooth: Call iso_exit() on module unload", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50198", " - iio: light: veml6030: fix IIO device retrieval from embedded device", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50201", " - drm/radeon: Fix encoder->possible_clones", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50098", " - scsi: ufs: core: Set SDEV_OFFLINE when UFS is shut down", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50079", " - io_uring/sqpoll: ensure task state is TASK_RUNNING when running task_work", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50080", " - ublk: don't allow user copy for unprivileged device", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50081", " - blk-mq: setup queue ->tag_set before initializing hctx", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50082", " - blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50101", " - iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI devices", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50083", " - tcp: fix mptcp DSS corruption due to large pmtu xmit", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50068", " - mm/damon/tests/sysfs-kunit.h: fix memory leak in", " damon_sysfs_test_add_targets()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50199", " - mm/swapfile: skip HugeTLB pages for unuse_vma", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50066", " - mm/mremap: fix move_normal_pmd/retract_page_tables race", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50202", " - nilfs2: propagate directory read errors from nilfs_find_entry()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50200", " - maple_tree: correct tree corruption on spanning store", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50084", " - net: microchip: vcap api: Fix memory leaks in vcap_api_encode_rule_test()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50194", " - arm64: probes: Fix uprobes for big-endian kernels", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50099", " - arm64: probes: Remove broken LDR (literal) uprobe support", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50195", " - posix-clock: Fix missing timespec64 check in pc_clock_settime()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50085", " - mptcp: pm: fix UaF read in mptcp_pm_nl_rm_addr_or_subflow", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50086", " - ksmbd: fix user-after-free from session log off", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50087", " - btrfs: fix uninitialized pointer free on read_alloc_one_name() error", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50088", " - btrfs: fix uninitialized pointer free in add_inode_ref()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068)", " - net: fec: don't save PTP state if PTP is unsupported", " - fs/ntfs3: Do not call file_modified if collapse range failed", " - fs/ntfs3: Optimize large writes into sparse file", " - fs/ntfs3: Fix sparse warning for bigendian", " - fs/ntfs3: Fix sparse warning in ni_fiemap", " - fs/ntfs3: Refactor enum_rstbl to suppress static checker", " - vdpa/octeon_ep: Fix format specifier for pointers in debug messages", " - virtio_console: fix misc probe bugs", " - perf vdso: Missed put on 32-bit dsos", " - perf build: Fix static compilation error when libdw is not installed", " - perf build: Fix build feature-dwarf_getlocations fail for old libdw", " - zram: don't free statically defined names", " - bpf: Call the missed btf_record_free() when map creation fails", " - selftests/bpf: Fix ARG_PTR_TO_LONG {half-,}uninitialized test", " - bpf: Check percpu map value size first", " - s390/facility: Disable compile time optimization for decompressor code", " - s390/mm: Add cond_resched() to cmm_alloc/free_pages()", " - bpf, x64: Fix a jit convergence issue", " - ext4: nested locking for xattr inode", " - s390/cpum_sf: Remove WARN_ON_ONCE statements", " - s390/traps: Handle early warnings gracefully", " - ktest.pl: Avoid false positives with grub2 skip regex", " - soundwire: intel_bus_common: enable interrupts before exiting reset", " - PCI: Add function 0 DMA alias quirk for Glenfly Arise chip", " - clk: bcm: bcm53573: fix OF node leak in init", " - PCI: Add ACS quirk for Qualcomm SA8775P", " - i2c: i801: Use a different adapter-name for IDF adapters", " - PCI: Mark Creative Labs EMU20k2 INTx masking as broken", " - RISC-V: Don't have MAX_PHYSMEM_BITS exceed phys_addr_t", " - mfd: intel_soc_pmic_chtwc: Make Lenovo Yoga Tab 3 X90F DMI match less strict", " - mfd: intel-lpss: Add Intel Panther Lake LPSS PCI IDs", " - riscv: Omit optimized string routines when using KASAN", " - riscv: avoid Imbalance in RAS", " - RDMA/mlx5: Enforce umem boundaries for explicit ODP page faults", " - PCI: qcom: Disable mirroring of DBI and iATU register space in BAR region", " - PCI: endpoint: Assign PCI domain number for endpoint controllers", " - soundwire: cadence: re-check Peripheral status with delayed_work", " - riscv/kexec_file: Fix relocation type R_RISCV_ADD16 and R_RISCV_SUB16", " unknown", " - media: videobuf2-core: clear memory related fields in", " __vb2_plane_dmabuf_put()", " - remoteproc: imx_rproc: Use imx specific hook for find_loaded_rsc_table", " - usb: chipidea: udc: enable suspend interrupt after usb reset", " - usb: dwc2: Adjust the timing of USB Driver Interrupt Registration in the", " Crashkernel Scenario", " - xhci: dbc: Fix STALL transfer event handling", " - usb: host: xhci-plat: Parse xhci-missing_cas_quirk and apply quirk", " - comedi: ni_routing: tools: Check when the file could not be opened", " - LoongArch: Fix memleak in pci_acpi_scan_root()", " - netfilter: nf_nat: don't try nat source port reallocation for reverse dir", " clash", " - netfilter: nf_reject: Fix build warning when CONFIG_BRIDGE_NETFILTER=n", " - tools/iio: Add memory allocation failure check for trigger_name", " - staging: vme_user: added bound check to geoid", " - driver core: bus: Return -EIO instead of 0 when show/store invalid bus", " attribute", " - scsi: lpfc: Add ELS_RSP cmd to the list of WQEs to flush in", " lpfc_els_flush_cmd()", " - scsi: lpfc: Revise TRACE_EVENT log flag severities from KERN_ERR to", " KERN_WARNING", " - NFSD: Mark filecache \"down\" if init fails", " - nfsd: nfsd_destroy_serv() must call svc_destroy() even if nfsd_startup_net()", " failed", " - ice: set correct dst VSI in only LAN filters", " - ice: clear port vlan config during reset", " - ice: disallow DPLL_PIN_STATE_SELECTABLE for dpll output pins", " - ice: fix VLAN replay after reset", " - SUNRPC: Fix integer overflow in decode_rc_list()", " - net: phy: aquantia: AQR115c fix up PMA capabilities", " - net: phy: aquantia: remove usage of phy_set_max_speed", " - tcp: fix to allow timestamp undo if no retransmits were sent", " - tcp: fix tcp_enter_recovery() to zero retrans_stamp when it's safe", " - tcp: fix TFO SYN_RECV to not zero retrans_stamp with retransmits out", " - rxrpc: Fix uninitialised variable in rxrpc_send_data()", " - net: dsa: sja1105: fix reception from VLAN-unaware bridges", " - selftests: net: no_forwarding: fix VID for $swp2 in one_bridge_two_pvids()", " test", " - net: pse-pd: Fix enabled status mismatch", " - Bluetooth: btusb: Don't fail external suspend requests", " - net: phy: bcm84881: Fix some error handling paths", " - net: ethernet: adi: adin1110: Fix some error handling path in", " adin1110_read_fifo()", " - net: dsa: b53: fix jumbo frame mtu check", " - net: dsa: b53: fix max MTU for 1g switches", " - net: dsa: b53: fix max MTU for BCM5325/BCM5365", " - net: dsa: b53: allow lower MTUs on BCM5325/5365", " - net: dsa: b53: fix jumbo frames on 10/100 ports", " - drm/nouveau: pass cli to nouveau_channel_new() instead of drm+device", " - nouveau/dmem: Fix privileged error in copy engine channel", " - gpio: aspeed: Add the flush write to ensure the write complete.", " - gpio: aspeed: Use devm_clk api to manage clock source", " - x86/xen: mark boot CPU of PV guest in MSR_IA32_APICBASE", " - powercap: intel_rapl_tpmi: Ignore minor version change", " - ice: Fix entering Safe Mode", " - ice: Fix netif_is_ice() in Safe Mode", " - ice: Flush FDB entries before reset", " - drm/xe: Restore GT freq on GSC load error", " - drm/xe: Make wedged_mode debugfs writable", " - net: ibm: emac: mal: fix wrong goto", " - net: ti: icssg-prueth: Fix race condition for VLAN table access", " - btrfs: zoned: fix missing RCU locking in error message when loading zone", " info", " - sctp: ensure sk_state is set to CLOSED if hashing fails in sctp_listen_start", " - netfilter: fib: check correct rtable in vrf setups", " - net: ibm: emac: mal: add dcr_unmap to _remove", " - net: dsa: refuse cross-chip mirroring operations", " - rtnetlink: Add bulk registration helpers for rtnetlink message handlers.", " - vxlan: Handle error of rtnl_register_module().", " - bridge: Handle error of rtnl_register_module().", " - mctp: Handle error of rtnl_register_module().", " - mpls: Handle error of rtnl_register_module().", " - phonet: Handle error of rtnl_register_module().", " - rcu/nocb: Fix rcuog wake-up from offline softirq", " - HID: multitouch: Add support for lenovo Y9000P Touchpad", " - hwmon: intel-m10-bmc-hwmon: relabel Columbiaville to CVL Die Temperature", " - hwmon: (tmp513) Add missing dependency on REGMAP_I2C", " - hwmon: (mc34vr500) Add missing dependency on REGMAP_I2C", " - hwmon: (adm9240) Add missing dependency on REGMAP_I2C", " - hwmon: (adt7470) Add missing dependency on REGMAP_I2C", " - hwmon: (ltc2991) Add missing dependency on REGMAP_I2C", " - HID: plantronics: Workaround for an unexcepted opposite volume key", " - HID: wacom: Hardcode (non-inverted) AES pens as BTN_TOOL_PEN", " - Revert \"usb: yurex: Replace snprintf() with the safer scnprintf() variant\"", " - usb: dwc3: core: Stop processing of pending events if controller is halted", " - usb: xhci: Fix problem with xhci resume from suspend", " - usb: storage: ignore bogus device raised by JieLi BR21 USB sound chip", " - usb: dwc3: re-enable runtime PM after failed resume", " - usb: gadget: core: force synchronous registration", " - hid: intel-ish-hid: Fix uninitialized variable 'rv' in", " ish_fw_xfer_direct_dma", " - ACPI: resource: Make Asus ExpertBook B2402 matches cover more models", " - ACPI: resource: Make Asus ExpertBook B2502 matches cover more models", " - drm/amdgpu: partially revert powerplay `__counted_by` changes", " - drm/amd/display: Clear update flags after update has been applied", " - drm/amdkfd: Fix an eviction fence leak", " - drm/amd/display: fix hibernate entry for DCN35+", " - drm/xe/guc_submit: fix xa_store() error checking", " - drm/i915/hdcp: fix connector refcounting", " - drm/xe/ct: fix xa_store() error checking", " - scsi: ufs: Use pre-calculated offsets in ufshcd_init_lrb()", " - Revert \"mmc: mvsdio: Use sg_miter for PIO\"", " - mmc: sdhci-of-dwcmshc: Prevent stale command interrupt handling", " - mptcp: fallback when MPTCP opts are dropped after 1st data", " - ata: libata: avoid superfluous disk spin down + spin up during hibernation", " - OPP: fix error code in dev_pm_opp_set_config()", " - net: dsa: lan9303: ensure chip reset and wait for READY status", " - net: phy: realtek: Fix MMD access on RTL8126A-integrated PHY", " - mptcp: pm: do not remove closing subflows", " - powercap: intel_rapl_tpmi: Fix bogus register reading", " - selftests/mm: fix incorrect buffer->mirror size in hmm2 double_map test", " - selftests/rseq: Fix mm_cid test failure", " - btrfs: split remaining space to discard in chunks", " - btrfs: add cancellation points to trim loops", " - PM: domains: Fix alloc/free in dev_pm_domain_attach|detach_list()", " - idpf: use actual mbx receive payload length", " - fs/proc/kcore.c: allow translation of physical memory addresses", " - PCI: Pass domain number to pci_bus_release_domain_nr() explicitly", " - io_uring/rw: fix cflags posting for single issue multishot read", " - Linux 6.11.4", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50182", " - secretmem: disable memfd_secret() if arch cannot set direct map", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50019", " - kthread: unpark only parked kthread", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50096", " - nouveau/dmem: Fix vulnerability in migrate_to_ram upon copy error", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50020", " - ice: Fix improper handling of refcount in ice_sriov_set_msix_vec_count()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50021", " - ice: Fix improper handling of refcount in ice_dpll_init_rclk_pins()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50022", " - device-dax: correct pgoff align in dax_set_mapping()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50185", " - mptcp: handle consistently DSS corruption", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50023", " - net: phy: Remove LED entry from LEDs list on unregister", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50024", " - net: Fix an unsafe loop on the list", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50186", " - net: explicitly clear the sk pointer, when pf->create fails", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50025", " - scsi: fnic: Move flush_work initialization out of if block", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50026", " - scsi: wd33c93: Don't use stale scsi_pointer value", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50027", " - thermal: core: Free tzp copy along with the thermal zone", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50028", " - thermal: core: Reference count the zone in thermal_zone_get_by_id()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50029", " - Bluetooth: hci_conn: Fix UAF in hci_enhanced_setup_sync", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50030", " - drm/xe/ct: prevent UAF in send_recv()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50187", " - drm/vc4: Stop the active perfmon before being destroyed", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50031", " - drm/v3d: Stop the active perfmon before being destroyed", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50189", " - HID: amd_sfh: Switch to device-managed dmam_alloc_coherent()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50033", " - slip: make slhc_remember() more robust against malicious packets", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50034", " - net/smc: fix lacks of icsk_syn_mss with IPPROTO_SMC", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50035", " - ppp: fix ppp_async_encode() illegal access", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50036", " - net: do not delay dst_entries_add() in dst_release()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50037", " - drm/fbdev-dma: Only cleanup deferred I/O if necessary", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50092", " - net: netconsole: fix wrong warning", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50038", " - netfilter: xtables: avoid NFPROTO_UNSPEC where needed", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50039", " - net/sched: accept TCA_STAB only for root qdisc", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50040", " - igb: Do not bring the device up after non-fatal error", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50041", " - i40e: Fix macvlan leak by synchronizing access to mac_filter_hash", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50042", " - ice: Fix increasing MSI-X on VF", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50093", " - thermal: intel: int340x: processor: Fix warning during module unload", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50043", " - nfsd: fix possible badness in FREE_STATEID", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50044", " - Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50045", " - netfilter: br_netfilter: fix panic with metadata_dst skb", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50094", " - sfc: Don't invoke xdp_do_flush() from netpoll.", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50188", " - net: phy: dp83869: fix memory corruption when enabling fiber", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50046", " - NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50190", " - ice: fix memleak in ice_init_tx_topology()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50180", " - fbdev: sisfb: Fix strbuf array overflow", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50047", " - smb: client: fix UAF in async decryption", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50048", " - fbcon: Fix a NULL pointer dereference issue in fbcon_putcs", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50049", " - drm/amd/display: Check null pointer before dereferencing se", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50090", " - drm/xe/oa: Fix overflow in oa batch buffer", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50183", " - scsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV", " instance", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50055", " - driver core: bus: Fix double free in driver API bus_register()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50091", " - dm vdo: don't refer to dedupe_context after releasing it", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50056", " - usb: gadget: uvc: Fix ERR_PTR dereference in uvc_v4l2.c", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50184", " - virtio_pmem: Check device status before requesting flush", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50057", " - usb: typec: tipd: Free IRQ only if it was requested before", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50058", " - serial: protect uart_port_dtr_rts() in uart_shutdown() too", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50181", " - clk: imx: Remove CLK_SET_PARENT_GATE for DRAM mux for i.MX7D", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50059", " - ntb: ntb_hw_switchtec: Fix use after free vulnerability in", " switchtec_ntb_remove due to race condition", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50060", " - io_uring: check if we need to reschedule during overflow flush", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50061", " - i3c: master: cdns: Fix use after free vulnerability in cdns_i3c_master", " Driver Due to Race Condition", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50062", " - RDMA/rtrs-srv: Avoid null pointer deref during path establishment", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50095", " - RDMA/mad: Improve handling of timed out WRs of mad agent", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50063", " - bpf: Prevent tail call between progs attached to different hooks", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50191", " - ext4: don't set SB_RDONLY after filesystem errors", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50064", " - zram: free secondary algorithms names", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50065", " - ntfs3: Change to non-blocking allocation in ntfs_d_hash", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50089", " - unicode: Don't special case ignorable code points", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052)", " - jump_label: Fix static_key_slow_dec() yet again", " - scsi: st: Fix input/output error on empty drive reset", " - scsi: pm8001: Do not overwrite PCI queue mapping", " - drm/i915/psr: Do not wait for PSR being idle on on Panel Replay", " - drm/i915/display: BMG supports UHBR13.5", " - drm/i915/dp: Fix AUX IO power enabling for eDP PSR", " - drm/amdgpu: Fix get each xcp macro", " - drm/amd/display: handle nulled pipe context in DCE110's set_drr()", " - ksmbd: fix warning: comparison of distinct pointer types lacks a cast", " - mailbox: ARM_MHU_V3 should depend on ARM64", " - [Config] updateconfigs for ARM_MHU_V3", " - mailbox: rockchip: fix a typo in module autoloading", " - ceph: fix a memory leak on cap_auths in MDS client", " - drm/i915/dp: Fix colorimetry detection", " - ieee802154: Fix build error", " - net: sparx5: Fix invalid timestamps", " - net/mlx5: Added cond_resched() to crdump collection", " - net/mlx5e: SHAMPO, Fix overflow of hd_per_wq", " - netfilter: uapi: NFTA_FLOWTABLE_HOOK is NLA_NESTED", " - net: ieee802154: mcr20a: Use IRQF_NO_AUTOEN flag in request_irq()", " - net: wwan: qcom_bam_dmux: Fix missing pm_runtime_disable()", " - selftests: netfilter: Fix nft_audit.sh for newer nft binaries", " - selftests: netfilter: Add missing return value", " - Bluetooth: btmrvl: Use IRQF_NO_AUTOEN flag in request_irq()", " - afs: Fix missing wire-up of afs_retry_request()", " - net: Add netif_get_gro_max_size helper for GRO", " - net: Fix gso_features_check to check for both dev->gso_{ipv4_,}max_size", " - net: fec: Restart PPS after link state change", " - net: fec: Reload PTP registers after link-state change", " - net: stmmac: dwmac4: extend timeout for VLAN Tag register busy bit check", " - ipv4: ip_gre: Fix drops of small packets in ipgre_xmit", " - netfs: Fix missing wakeup after issuing writes", " - net: phy: realtek: Check the index value in led_hw_control_get", " - bridge: mcast: Fail MDB get request on empty entry", " - iomap: constrain the file range passed to iomap_file_unshare", " - dt-bindings: net: xlnx,axi-ethernet: Add missing reg minItems", " - ASoC: topology: Fix incorrect addressing assignments", " - ASoC: atmel: mchp-pdmc: Skip ALSA restoration if substream runtime is", " uninitialized", " - drm/connector: hdmi: Fix writing Dynamic Range Mastering infoframes", " - io_uring: fix memory leak when cache init fail", " - rust: kbuild: split up helpers.c", " - rust: kbuild: auto generate helper exports", " - rust: mutex: fix __mutex_init() usage in case of PREEMPT_RT", " - ALSA: mixer_oss: Remove some incorrect kfree_const() usages", " - ALSA: hda/realtek: Fix the push button function for the ALC257", " - cifs: Remove intermediate object of failed create reparse call", " - drm/panthor: Lock the VM resv before calling drm_gpuvm_bo_obtain_prealloc()", " - ALSA: hda/generic: Unconditionally prefer preferred_dacs pairs", " - ASoC: imx-card: Set card.owner to avoid a warning calltrace if SND=m", " - drm/xe: Restore pci state upon resume", " - drm/xe: Resume TDR after GT reset", " - cifs: Do not convert delimiter when parsing NFS-style symlinks", " - tools/rtla: Fix installation from out-of-tree build", " - ALSA: gus: Fix some error handling paths related to get_bpos() usage", " - ALSA: hda/conexant: Fix conflicting quirk for System76 Pangolin", " - drm/amd/display: Disable replay if VRR capability is false", " - drm/amd/display: Fix VRR cannot enable", " - drm/amd/display: Re-enable panel replay feature", " - e1000e: avoid failing the system during pm_suspend", " - wifi: ath9k: fix possible integer overflow in ath9k_get_et_stats()", " - crypto: x86/sha256 - Add parentheses around macros' single arguments", " - crypto: octeontx - Fix authenc setkey", " - crypto: octeontx2 - Fix authenc setkey", " - ice: Adjust over allocation of memory in ice_sched_add_root_node() and", " ice_sched_add_node()", " - wifi: iwlwifi: mvm: Fix a race in scan abort flow", " - wifi: iwlwifi: mvm: drop wrong STA selection in TX", " - net: hisilicon: hip04: fix OF node leak in probe()", " - net: hisilicon: hns_dsaf_mac: fix OF node leak in hns_mac_get_info()", " - net: hisilicon: hns_mdio: fix OF node leak in probe()", " - ACPICA: Fix memory leak if acpi_ps_get_next_namepath() fails", " - ACPICA: Fix memory leak if acpi_ps_get_next_field() fails", " - ACPI: resource: Skip IRQ override on Asus Vivobook Go E1404GAB", " - wifi: mt76: mt7915: disable tx worker during tx BA session enable/disable", " - net: sched: consistently use rcu_replace_pointer() in taprio_change()", " - Bluetooth: btusb: Add Realtek RTL8852C support ID 0x0489:0xe122", " - Bluetooth: btrtl: Set msft ext address filter quirk for RTL8852B", " - ACPI: video: Add force_vendor quirk for Panasonic Toughbook CF-18", " - ACPI: CPPC: Add support for setting EPP register in FFH", " - wifi: rtw88: select WANT_DEV_COREDUMP", " - l2tp: free sessions using rcu", " - l2tp: use rcu list add/del when updating lists", " - ACPI: EC: Do not release locks during operation region accesses", " - net: skbuff: sprinkle more __GFP_NOWARN on ingress allocs", " - net: mvpp2: Increase size of queue_name buffer", " - bnxt_en: Extend maximum length of version string by 1 byte", " - ipv4: Check !in_dev earlier for ioctl(SIOCSIFADDR).", " - wifi: rtw89: correct base HT rate mask for firmware", " - netfilter: nf_tables: do not remove elements if set backend implements", " .abort", " - ipv4: Mask upper DSCP bits and ECN bits in NETLINK_FIB_LOOKUP family", " - nvme-keyring: restrict match length for version '1' identifiers", " - nvme-tcp: sanitize TLS key handling", " - nvme-tcp: check for invalidated or revoked key", " - net: atlantic: Avoid warning about potential string truncation", " - crypto: simd - Do not call crypto_alloc_tfm during registration", " - netpoll: Ensure clean state on setup failures", " - tcp: avoid reusing FIN_WAIT2 when trying to find port in connect() process", " - wifi: iwlwifi: mvm: use correct key iteration", " - wifi: iwlwifi: allow only CN mcc from WRDD", " - virt: sev-guest: Ensure the SNP guest messages do not exceed a page", " - wifi: mac80211: fix RCU list iterations", " - ACPICA: iasl: handle empty connection_node", " - proc: add config & param to block forcing mem writes", " - [Config] updateconfigs to select PROC_MEM_ALWAYS_FORCE", " - vfs: use RCU in ilookup", " - drivers/perf: arm_spe: Use perf_allow_kernel() for permissions", " - nvme: fix metadata handling in nvme-passthrough", " - can: netlink: avoid call to do_set_data_bittiming callback with stale", " can_priv::ctrlmode", " - netdev-genl: Set extack and fix error on napi-get", " - wifi: wilc1000: Do not operate uninitialized hardware during suspend/resume", " - arm64: trans_pgd: mark PTEs entries as valid to avoid dead kexec()", " - net: phy: Check for read errors in SIOCGMIIREG", " - x86/bugs: Add missing NO_SSB flag", " - x86/bugs: Fix handling when SRSO mitigation is disabled", " - crypto: hisilicon - fix missed error branch", " - wifi: mt76: mt7915: add dummy HW offload of IEEE 802.11 fragmentation", " - wifi: mt76: mt7915: hold dev->mt76.mutex while disabling tx worker", " - netfs: Cancel dirty folios that have no storage destination", " - nfp: Use IRQF_NO_AUTOEN flag in request_irq()", " - ALSA: usb-audio: Add input value sanity checks for standard types", " - x86/apic: Remove logical destination mode for 64-bit", " - ALSA: usb-audio: Define macros for quirk table entries", " - ALSA: usb-audio: Replace complex quirk lines with macros", " - ALSA: usb-audio: Add quirk for RME Digiface USB", " - ALSA: usb-audio: Add mixer quirk for RME Digiface USB", " - ALSA: hda/realtek: Refactor and simplify Samsung Galaxy Book init", " - ALSA: usb-audio: Add logitech Audio profile quirk", " - ASoC: codecs: wsa883x: Handle reading version failure", " - ALSA: control: Take power_ref lock primarily", " - tools/x86/kcpuid: Protect against faulty \"max subleaf\" values", " - x86/pkeys: Add PKRU as a parameter in signal handling functions", " - x86/pkeys: Restore altstack access in sigreturn()", " - x86/kexec: Add EFI config table identity mapping for kexec kernel", " - ALSA: hdsp: Break infinite MIDI input flush loop", " - tools/nolibc: powerpc: limit stack-protector workaround to GCC", " - selftests/nolibc: avoid passing NULL to printf(\"%s\")", " - x86/syscall: Avoid memcpy() for ia32 syscall_get_arguments()", " - ASoC: Intel: boards: always check the result of", " acpi_dev_get_first_match_dev()", " - hwmon: (nct6775) add G15CF to ASUS WMI monitoring list", " - pmdomain: core: Don't hold the genpd-lock when calling dev_pm_domain_set()", " - pmdomain: core: Use dev_name() instead of kobject_get_path() in debugfs", " - rcuscale: Provide clear error when async specified without primitives", " - power: reset: brcmstb: Do not go into infinite loop if reset fails", " - iommu/arm-smmu-v3: Match Stall behaviour for S2", " - iommu/vt-d: Always reserve a domain ID for identity setup", " - iommu/vt-d: Unconditionally flush device TLB for pasid table updates", " - iommu/arm-smmu-v3: Do not use devm for the cd table allocations", " - drm/amdgpu: disallow multiple BO_HANDLES chunks in one submit", " - drm/amd/display: Use gpuvm_min_page_size_kbytes for DML2 surfaces", " - ata: pata_serverworks: Do not use the term blacklist", " - ata: sata_sil: Rename sil_blacklist to sil_quirks", " - selftests/bpf: fix uprobe.path leak in bpf_testmod", " - scsi: smartpqi: Add new controller PCI IDs", " - HID: Ignore battery for all ELAN I2C-HID devices", " - drm/amd/display: Underflow Seen on DCN401 eGPU", " - drm/xe: Name and document Wa_14019789679", " - jfs: UBSAN: shift-out-of-bounds in dbFindBits", " - scsi: smartpqi: correct stream detection", " - scsi: smartpqi: add new controller PCI IDs", " - drm/amdgpu: add raven1 gfxoff quirk", " - drm/amdgpu: enable gfxoff quirk on HP 705G4", " - drm/amdkfd: Fix resource leak in criu restore queue", " - HID: multitouch: Add support for Thinkpad X12 Gen 2 Kbd Portfolio", " - platform/x86: touchscreen_dmi: add nanote-next quirk", " - platform/x86/amd: pmf: Add quirk for TUF Gaming A14", " - drm/stm: ltdc: reset plane transparency after plane disable", " - drm/amdgpu/gfx12: properly handle error ints on all pipes", " - drm/amdgpu/gfx9: properly handle error ints on all pipes", " - drm/amd/display: Fix possible overflow in integer multiplication", " - drm/printer: Allow NULL data in devcoredump printer", " - perf,x86: avoid missing caller address in stack traces captured in uprobe", " - scsi: aacraid: Rearrange order of struct aac_srb_unit", " - scsi: lpfc: Fix unsolicited FLOGI kref imbalance when in direct attached", " topology", " - scsi: lpfc: Update PRLO handling in direct attached topology", " - drm/amd/display: Force enable 3DLUT DMA check for dcn401 in DML", " - drm/amdgpu: fix unchecked return value warning for amdgpu_gfx", " - drm/amdgpu: fix unchecked return value warning for amdgpu_atombios", " - perf: Fix event_function_call() locking", " - scsi: NCR5380: Initialize buffer for MSG IN and STATUS transfers", " - drm/radeon/r100: Handle unknown family in r100_cp_init_microcode()", " - drm/amd/display: Unlock Pipes Based On DET Allocation", " - drm/amdgpu: fix ptr check warning in gfx9 ip_dump", " - drm/amdgpu: fix ptr check warning in gfx10 ip_dump", " - drm/amdgpu: fix ptr check warning in gfx11 ip_dump", " - drm/amdgpu: Block MMR_READ IOCTL in reset", " - drm/amdgpu/gfx9: use rlc safe mode for soft recovery", " - drm/amdgpu/gfx11: enter safe mode before touching CP_INT_CNTL", " - drm/xe: Use topology to determine page fault queue size", " - drm/amdkfd: Check int source id for utcl2 poison event", " - of/irq: Refer to actual buffer size in of_irq_parse_one()", " - drm/amd/display: guard write a 0 post_divider value to HW", " - powerpc/pseries: Use correct data types from pseries_hp_errorlog struct", " - ovl: fsync after metadata copy-up", " - drm/amdgpu/gfx12: use rlc safe mode for soft recovery", " - drm/amdgpu/gfx11: use rlc safe mode for soft recovery", " - drm/amdgpu/gfx10: use rlc safe mode for soft recovery", " - platform/x86: lenovo-ymc: Ignore the 0x0 state", " - tools/hv: Add memory allocation check in hv_fcopy_start", " - HID: i2c-hid: ensure various commands do not interfere with each other", " - platform/mellanox: mlxbf-pmc: fix lockdep warning", " - platform/x86: x86-android-tablets: Adjust Xiaomi Pad 2 bottom bezel touch", " buttons LED", " - bpf: Make the pointer returned by iter next method valid", " - ext4: ext4_search_dir should return a proper error", " - bpftool: Fix undefined behavior caused by shifting into the sign bit", " - iomap: handle a post-direct I/O invalidate race in", " iomap_write_delalloc_release", " - EINJ, CXL: Fix CXL device SBDF calculation", " - spi: spi-imx: Fix pm_runtime_set_suspended() with runtime pm enabled", " - spi: spi-cadence: Fix pm_runtime_set_suspended() with runtime pm enabled", " - spi: spi-cadence: Fix missing spi_controller_is_target() check", " - selftest: hid: add missing run-hid-tools-tests.sh", " - spi: s3c64xx: fix timeout counters in flush_fifo", " - kselftest/devices/probe: Fix SyntaxWarning in regex strings for Python3", " - selftests: breakpoints: use remaining time to check if suspend succeed", " - accel/ivpu: Add missing MODULE_FIRMWARE metadata", " - spi: rpc-if: Add missing MODULE_DEVICE_TABLE", " - ALSA: control: Fix power_ref lock order for compat code, too", " - perf callchain: Fix stitch LBR memory leaks", " - perf: Really fix event_function_call() locking", " - drm/xe: fixup xe_alloc_pf_queue", " - drm/xe: Fix memory leak on xe_alloc_pf_queue failure", " - selftests: vDSO: fix vDSO name for powerpc", " - selftests: vDSO: fix vdso_config for powerpc", " - selftests: vDSO: fix vDSO symbols lookup for powerpc64", " - ext4: fix error message when rejecting the default hash", " - selftests/mm: fix charge_reserved_hugetlb.sh test", " - nvme-tcp: fix link failure for TCP auth", " - f2fs: add write priority option based on zone UFS", " - powerpc/vdso: Fix VDSO data access when running in a non-root time namespace", " - selftests: vDSO: fix ELF hash table entry size for s390x", " - selftests: vDSO: fix vdso_config for s390", " - f2fs: make BG GC more aggressive for zoned devices", " - f2fs: introduce migration_window_granularity", " - f2fs: increase BG GC migration window granularity when boosted for zoned", " devices", " - f2fs: do FG_GC when GC boosting is required for zoned devices", " - f2fs: forcibly migrate to secure space for zoned device file pinning", " - Revert \"ALSA: hda: Conditionally use snooping for AMD HDMI\"", " - KVM: arm64: Fix kvm_has_feat*() handling of negative features", " - i2c: qcom-geni: Use IRQF_NO_AUTOEN flag in request_irq()", " - i2c: xiic: Wait for TX empty to avoid missed TX NAKs", " - i2c: core: Lock address during client device instantiation", " - i2c: xiic: Fix pm_runtime_set_suspended() with runtime pm enabled", " - i2c: designware: fix controller is holding SCL low while ENABLE bit is", " disabled", " - i2c: synquacer: Deal with optional PCLK correctly", " - rust: sync: require `T: Sync` for `LockedBy::access`", " - ovl: fail if trusted xattrs are needed but caller lacks permission", " - firmware: tegra: bpmp: Drop unused mbox_client_to_bpmp()", " - memory: tegra186-emc: drop unused to_tegra186_emc()", " - dt-bindings: clock: exynos7885: Fix duplicated binding", " - spi: bcm63xx: Fix module autoloading", " - spi: bcm63xx: Fix missing pm_runtime_disable()", " - power: supply: hwmon: Fix missing temp1_max_alarm attribute", " - power: supply: Drop use_cnt check from power_supply_property_is_writeable()", " - perf/core: Fix small negative period being ignored", " - drm/v3d: Prevent out of bounds access in performance query extensions", " - parisc: Fix itlb miss handler for 64-bit programs", " - drm/mediatek: ovl_adaptor: Add missing of_node_put()", " - drm: Consistently use struct drm_mode_rect for FB_DAMAGE_CLIPS", " - ALSA: hda/tas2781: Add new quirk for Lenovo Y990 Laptop", " - ALSA: core: add isascii() check to card ID generator", " - ALSA: usb-audio: Add delay quirk for VIVO USB-C HEADSET", " - ALSA: usb-audio: Add native DSD support for Luxman D-08u", " - ALSA: line6: add hw monitor volume control to POD HD500X", " - ALSA: hda/realtek: fix mute/micmute LED for HP mt645 G8", " - ALSA: hda/realtek: Add quirk for Huawei MateBook 13 KLV-WX9", " - ALSA: hda/realtek: Add a quirk for HP Pavilion 15z-ec200", " - ext4: correct encrypted dentry name hash when not casefolded", " - ext4: propagate errors from ext4_find_extent() in ext4_insert_range()", " - ext4: fix incorrect tid assumption in ext4_fc_mark_ineligible()", " - ext4: fix incorrect tid assumption in __jbd2_log_wait_for_space()", " - ext4: fix incorrect tid assumption in ext4_wait_for_tail_page_commit()", " - ext4: fix incorrect tid assumption in jbd2_journal_shrink_checkpoint_list()", " - ext4: fix fast commit inode enqueueing during a full journal commit", " - ext4: use handle to mark fc as ineligible in __track_dentry_update()", " - ext4: mark fc as ineligible using an handle in ext4_xattr_set()", " - parisc: Fix 64-bit userspace syscall path", " - parisc: Allow mmap(MAP_STACK) memory to automatically expand upwards", " - parisc: Fix stack start for ADDR_NO_RANDOMIZE personality", " - drm/rockchip: vop: clear DMA stop bit on RK3066", " - of: address: Report error on resource bounds overflow", " - of/irq: Support #msi-cells=<0> in of_msi_get_domain", " - lib/buildid: harden build ID parsing logic", " - jbd2: correctly compare tids with tid_geq function in jbd2_fc_begin_commit", " - mm: krealloc: consider spare memory for __GFP_ZERO", " - ocfs2: fix the la space leak when unmounting an ocfs2 volume", " - ocfs2: fix uninit-value in ocfs2_get_block()", " - scripts/gdb: fix timerlist parsing issue", " - scripts/gdb: add iteration function for rbtree", " - scripts/gdb: fix lx-mounts command error", " - arm64: fix selection of HAVE_DYNAMIC_FTRACE_WITH_ARGS", " - arm64: Subscribe Microsoft Azure Cobalt 100 to erratum 3194386", " - drm/xe/oa: Don't reset OAC_CONTEXT_ENABLE on OA stream close", " - sched/deadline: Comment sched_dl_entity::dl_server variable", " - sched/core: Add clearing of ->dl_server in put_prev_task_balance()", " - sched/core: Clear prev->dl_server in CFS pick fast path", " - sched: psi: fix bogus pressure spikes from aggregation race", " - riscv: define ILLEGAL_POINTER_VALUE for 64bit", " - [Config] updateconfigs for ILLEGAL_POINTER_VALUE on riscv", " - perf python: Disable -Wno-cast-function-type-mismatch if present on clang", " - perf hist: Update hist symbol when updating maps", " - nfsd: fix delegation_blocked() to block correctly for at least 30 seconds", " - NFSD: Fix NFSv4's PUTPUBFH operation", " - sysctl: avoid spurious permanent empty tables", " - RDMA/mana_ib: use the correct page table index based on hardware page size", " - RDMA/mana_ib: use the correct page size for mapping user-mode doorbell page", " - drivers/perf: riscv: Align errno for unsupported perf event", " - riscv: Fix kernel stack size when KASAN is enabled", " - media: imx335: Fix reset-gpio handling", " - clk: rockchip: fix error for unknown clocks", " - leds: pca9532: Remove irrelevant blink configuration error message", " - media: videobuf2: Drop minimum allocation requirement of 2 buffers", " - clk: qcom: dispcc-sm8250: use CLK_SET_RATE_PARENT for branch clocks", " - media: sun4i_csi: Implement link validate for sun4i_csi subdev", " - clk: qcom: gcc-sm8450: Do not turn off PCIe GDSCs during gdsc_disable()", " - media: uapi/linux/cec.h: cec_msg_set_reply_to: zero flags", " - dt-bindings: clock: qcom: Add GPLL9 support on gcc-sc8180x", " - clk: qcom: gcc-sc8180x: Register QUPv3 RCGs for DFS on sc8180x", " - clk: qcom: clk-rpmh: Fix overflow in BCM vote", " - clk: samsung: exynos7885: Update CLKS_NR_FSYS after bindings fix", " - clk: qcom: gcc-sm8150: De-register gcc_cpuss_ahb_clk_src", " - clk: qcom: gcc-sm8250: Do not turn off PCIe GDSCs during gdsc_disable()", " - clk: qcom: gcc-sc8180x: Add GPLL9 support", " - clk: qcom: gcc-sc8180x: Fix the sdcc2 and sdcc4 clocks freq table", " - clk: qcom: clk-alpha-pll: Fix CAL_L_VAL override for LUCID EVO PLL", " - drm/amd/display: avoid set dispclk to 0", " - smb: client: use actual path when queryfs", " - smb3: fix incorrect mode displayed for read-only files", " - iio: magnetometer: ak8975: Fix reading for ak099xx sensors", " - iio: pressure: bmp280: Fix regmap for BMP280 device", " - iio: pressure: bmp280: Fix waiting time for BMP3xx configuration", " - tomoyo: fallback to realpath if symlink's pathname does not exist", " - kselftests: mm: fix wrong __NR_userfaultfd value", " - rtc: at91sam9: fix OF node leak in probe() error path", " - mm/hugetlb: fix memfd_pin_folios resv_huge_pages leak", " - mm/gup: fix memfd_pin_folios hugetlb page allocation", " - mm/hugetlb: simplify refs in memfd_alloc_folio", " - Input: adp5589-keys - fix adp5589_gpio_get_value()", " - HID: bpf: fix cfi stubs for hid_bpf_ops", " - pidfs: check for valid pid namespace", " - ACPI: video: Add backlight=native quirk for Dell OptiPlex 5480 AIO", " - ACPI: resource: Remove duplicate Asus E1504GAB IRQ override", " - ACPI: resource: Loosen the Asus E1404GAB DMI match to also cover the E1404GA", " - ACPI: resource: Add Asus Vivobook X1704VAP to irq1_level_low_skip_override[]", " - ACPI: resource: Add Asus ExpertBook B2502CVA to", " irq1_level_low_skip_override[]", " - btrfs: drop the backref cache during relocation if we commit", " - btrfs: send: fix invalid clone operation for file that got its size", " decreased", " - cpufreq: intel_pstate: Make hwp_notify_lock a raw spinlock", " - gpio: davinci: fix lazy disable", " - net: pcs: xpcs: fix the wrong register that was written back", " - Bluetooth: hci_event: Align BR/EDR JUST_WORKS paring with LE", " - io_uring/net: harden multishot termination case for recv", " - ceph: fix cap ref leak via netfs init_request", " - tracing/hwlat: Fix a race during cpuhp processing", " - tracing/timerlat: Fix duplicated kthread creation due to CPU online/offline", " - rtla: Fix the help text in osnoise and timerlat top tools", " - firmware/sysfb: Disable sysfb for firmware buffers with unknown parent", " - close_range(): fix the logics in descriptor table trimming", " - drm/i915/gem: fix bitwise and logical AND mixup", " - drm/panthor: Don't add write fences to the shared BOs", " - drm/panthor: Don't declare a queue blocked if deferred operations are", " pending", " - drm/sched: Fix dynamic job-flow control race", " - drm/sched: Add locking to drm_sched_entity_modify_sched", " - drm/sched: Always wake up correct scheduler in drm_sched_entity_push_job", " - drm/sched: Always increment correct scheduler score", " - drm/amd/display: Restore Optimized pbn Value if Failed to Disable DSC", " - drm/amd/display: Add HDR workaround for specific eDP", " - drm/amd/display: Enable idle workqueue for more IPS modes", " - kconfig: fix infinite loop in sym_calc_choice()", " - kconfig: qconf: move conf_read() before drawing tree pain", " - kconfig: qconf: fix buffer overflow in debug links", " - arm64: cputype: Add Neoverse-N3 definitions", " - arm64: errata: Expand speculative SSBS workaround once more", " - mm: z3fold: deprecate CONFIG_Z3FOLD", " - [Config] updateconfigs after deprecating Z3FOLD", " - drm/amd/display: Allow backlight to go below", " `AMDGPU_DM_DEFAULT_MIN_BACKLIGHT`", " - sunrpc: change sp_nrthreads from atomic_t to unsigned int.", " - NFSD: Async COPY result needs to return a write verifier", " - remoteproc: k3-r5: Acquire mailbox handle during probe routine", " - remoteproc: k3-r5: Delay notification of wakeup event", " - r8169: Fix spelling mistake: \"tx_underun\" -> \"tx_underrun\"", " - ACPI: battery: Simplify battery hook locking", " - drm/xe: Clean up VM / exec queue file lock usage.", " - drm/rockchip: vop: enable VOP_FEATURE_INTERNAL_RGB on RK3066", " - drm/xe/vram: fix ccs offset calculation", " - drm/sched: revert \"Always increment correct scheduler score\"", " - ALSA: control: Fix leftover snd_power_unref()", " - crypto: octeontx* - Select CRYPTO_AUTHENC", " - drm/amd/display: Revert Avoid overflow assignment", " - perf report: Fix segfault when 'sym' sort key is not used", " - pmdomain: core: Reduce debug summary table width", " - perf python: Allow checking for the existence of warning options in clang", " - Linux 6.11.3", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49863", " - vhost/scsi: null-ptr-dereference in vhost_scsi_get_req()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49864", " - rxrpc: Fix a race between socket set up and I/O thread creation", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49865", " - drm/xe/vm: move xa_alloc to prevent UAF", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49955", " - ACPI: battery: Fix possible crash when unregistering a battery hook", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49973", " - r8169: add tally counter fields added with RTL8125", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49974", " - NFSD: Limit the number of concurrent async COPY operations", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49975", " - uprobes: fix kernel info leak via \"[uprobes]\" vma", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50003", " - drm/amd/display: Fix system hang while resume with TBT monitor", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50173", " - drm/panthor: Fix access to uninitialized variable in tick_ctx_cleanup()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49866", " - tracing/timerlat: Fix a race during cpuhp processing", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49976", " - tracing/timerlat: Drop interface_lock in stop_kthread()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50005", " - mac802154: Fix potential RCU dereference issue in mac802154_scan_worker", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50012", " - cpufreq: Avoid a bad reference count on CPU node", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49867", " - btrfs: wait for fixup workers before stopping cleaner kthread during umount", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49868", " - btrfs: fix a NULL pointer dereference when failed to start a new trasacntion", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49869", " - btrfs: send: fix buffer overflow detection when copying path to cache entry", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49870", " - cachefiles: fix dentry leak in cachefiles_open_file()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49871", " - Input: adp5589-keys - fix NULL pointer dereference", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49872", " - mm/gup: fix memfd_pin_folios alloc race panic", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49964", " - mm/hugetlb: fix memfd_pin_folios free_huge_pages leak", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49873", " - mm/filemap: fix filemap_get_folios_contig THP panic", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49977", " - net: stmmac: Fix zero-division error when disabling tc cbs", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49978", " - gso: fix udp gso fraglist segmentation after pull from frag_list", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49979", " - net: gso: fix tcp fraglist segmentation after pull from frag_list", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49980", " - vrf: revert \"vrf: Remove unnecessary RCU-bh critical section\"", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49981", " - media: venus: fix use after free bug in venus_remove due to race condition", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49956", " - gfs2: fix double destroy_workqueue error", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50176", " - remoteproc: k3-r5: Fix error handling when power-up failed", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49982", " - aoe: fix the potential use-after-free problem in more places", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49874", " - i3c: master: svc: Fix use after free vulnerability in svc_i3c_master Driver", " Due to Race Condition", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49875", " - nfsd: map the EBADMSG to nfserr_io to avoid warning", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50013", " - exfat: fix memory leak in exfat_load_bitmap()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49876", " - drm/xe: fix UAF around queue destruction", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49877", " - ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49957", " - ocfs2: fix null-ptr-deref when journal load failed.", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49965", " - ocfs2: remove unreasonable unlock in ocfs2_read_blocks", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49966", " - ocfs2: cancel dqi_sync_work before freeing oinfo", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49958", " - ocfs2: reserve space for inline xattr before attaching reflink tree", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49959", " - jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49878", " - resource: fix region_intersects() vs add_memory_driver_managed()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49879", " - drm: omapdrm: Add missing check for alloc_ordered_workqueue", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49880", " - ext4: fix off by one issue in alloc_flex_gd()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49881", " - ext4: update orig_path in ext4_find_extent()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50014", " - ext4: fix access to uninitialised lock in fc replay path", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49960", " - ext4: fix timer use-after-free on failed mount", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49882", " - ext4: fix double brelse() the buffer of the extents path", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49883", " - ext4: aovid use-after-free in ext4_ext_insert_extent()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49983", " - ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-free", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50015", " - ext4: dax: fix overflowing extents beyond inode size when partially writing", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49884", " - ext4: fix slab-use-after-free in ext4_split_extent_at()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49885", " - mm, slub: avoid zeroing kmalloc redzone", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49961", " - media: i2c: ar0521: Use cansleep version of gpiod_set_value()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49985", " - i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49886", " - platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bug", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49986", " - platform/x86: x86-android-tablets: Fix use after free on", " platform_device_register() errors", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49887", " - f2fs: fix to don't panic system for no free segment fault injection", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49888", " - bpf: Fix a sdiv overflow issue", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49987", " - bpftool: Fix undefined behavior in qsort(NULL, 0, ...)", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50006", " - ext4: fix i_data_sem unlock order in ext4_ind_migrate()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49889", " - ext4: avoid use-after-free in ext4_ext_show_leaf()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49968", " - ext4: filesystems without casefold feature cannot be mounted with siphash", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49988", " - ksmbd: add refcnt to ksmbd_conn struct", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49890", " - drm/amd/pm: ensure the fw_info is not null before using it", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49891", " - scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata", " paths", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49892", " - drm/amd/display: Initialize get_bytes_per_element's default to 1", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50016", " - drm/amd/display: Avoid overflow assignment in link_dp_cts", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49893", " - drm/amd/display: Check stream_status before it is used", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49969", " - drm/amd/display: Fix index out of bounds in DCN30 color transformation", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49970", " - drm/amd/display: Implement bounds check for stream encoder creation in", " DCN401", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49894", " - drm/amd/display: Fix index out of bounds in degamma hardware format", " translation", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49895", " - drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format", " translation", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49971", " - drm/amd/display: Increase array size of dummy_boolean", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49972", " - drm/amd/display: Deallocate DML memory if allocation fails", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49896", " - drm/amd/display: Check stream before comparing them", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49897", " - drm/amd/display: Check phantom_stream before it is used", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49898", " - drm/amd/display: Check null-initialized variables", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49899", " - drm/amd/display: Initialize denominators' default to 1", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49900", " - jfs: Fix uninit-value access of new_ea in ea_buffer", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49901", " - drm/msm/adreno: Assign msm_gpu->pdev earlier to avoid nullptrs", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49902", " - jfs: check if leafidx greater than num leaves per dmap tree", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49903", " - jfs: Fix uaf in dbFreeBits", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49904", " - drm/amdgpu: add list empty check to avoid null pointer issue", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49989", " - drm/amd/display: fix double free issue during amdgpu module unload", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49905", " - drm/amd/display: Add null check for 'afb' in", " amdgpu_dm_plane_handle_cursor_update (v2)", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49906", " - drm/amd/display: Check null pointer before try to access it", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49907", " - drm/amd/display: Check null pointers before using dc->clk_mgr", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49908", " - drm/amd/display: Add null check for 'afb' in amdgpu_dm_update_cursor (v2)", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50177", " - drm/amd/display: fix a UBSAN warning in DML2.1", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49909", " - drm/amd/display: Add NULL check for function pointer in", " dcn32_set_output_transfer_func", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49910", " - drm/amd/display: Add NULL check for function pointer in", " dcn401_set_output_transfer_func", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49911", " - drm/amd/display: Add NULL check for function pointer in", " dcn20_set_output_transfer_func", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49912", " - drm/amd/display: Handle null 'stream_status' in", " 'planes_changed_for_existing_stream'", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49913", " - drm/amd/display: Add null check for top_pipe_to_program in", " commit_planes_for_stream", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49914", " - drm/amd/display: Add null check for pipe_ctx->plane_state in", " dcn20_program_pipe", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49915", " - drm/amd/display: Add NULL check for clk_mgr in dcn32_init_hw", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49916", " - drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in", " dcn401_init_hw", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49917", " - drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in", " dcn30_init_hw", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49918", " - drm/amd/display: Add null check for head_pipe in", " dcn32_acquire_idle_pipe_for_head_pipe_in_layer", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49919", " - drm/amd/display: Add null check for head_pipe in", " dcn201_acquire_free_pipe_for_layer", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49991", " - drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49920", " - drm/amd/display: Check null pointers before multiple uses", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49921", " - drm/amd/display: Check null pointers before used", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49922", " - drm/amd/display: Check null pointers before using them", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49923", " - drm/amd/display: Pass non-null to dcn20_validate_apply_pipe_split_flags", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49992", " - drm/stm: Avoid use-after-free issues with crtc and plane", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49993", " - iommu/vt-d: Fix potential lockup if qi_submit_sync called with 0 count", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49924", " - fbdev: pxafb: Fix possible use after free in pxafb_task()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49925", " - fbdev: efifb: Register sysfs groups through driver core", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49926", " - rcu-tasks: Fix access non-existent percpu rtpcp variable in", " rcu_tasks_need_gpcb()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50007", " - ALSA: asihpi: Fix potential OOB array access", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50017", " - x86/mm/ident_map: Use gbpages only where full GB page should be mapped.", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49927", " - x86/ioapic: Handle allocation failures gracefully", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50008", " - wifi: mwifiex: Fix memcpy() field-spanning write warning in", " mwifiex_cmd_802_11_scan_ext()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50018", " - net: napi: Prevent overflow of napi_defer_hard_irqs", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49928", " - wifi: rtw89: avoid reading out of bounds when loading TX power FW elements", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50178", " - cpufreq: loongson3: Use raw_smp_processor_id() in do_service_request()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50009", " - cpufreq: amd-pstate: add check for cpufreq_cpu_get's return value", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49994", " - block: fix integer overflow in BLKSECDISCARD", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49929", " - wifi: iwlwifi: mvm: avoid NULL pointer dereference", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49995", " - tipc: guard against string buffer overrun", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49962", " - ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in", " acpi_db_convert_to_package()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49930", " - wifi: ath11k: fix array out-of-bound access in SoC stats", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49931", " - wifi: ath12k: fix array out-of-bound access in SoC stats", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49932", " - btrfs: don't readahead the relocation inode on RST", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49933", " - blk_iocost: fix more out of bound shifts", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49934", " - fs/inode: Prevent dump_mapping() accessing invalid dentry.d_name.name", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50010", " - exec: don't WARN for racy path_noexec check", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49935", " - ACPI: PAD: fix crash in exit_round_robin()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49936", " - net/xen-netback: prevent UAF in xenvif_flush_hash()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49937", " - wifi: cfg80211: Set correct chandef when starting CAC", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49938", " - wifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmit", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49939", " - wifi: rtw89: avoid to add interface to list twice when SER", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49940", " - l2tp: prevent possible tunnel refcount underflow", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49941", " - gpiolib: Fix potential NULL pointer dereference in gpiod_get_label()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49996", " - cifs: Fix buffer overflow when parsing NFS reparse points", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49942", " - drm/xe: Prevent null pointer access in xe_migrate_copy", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49943", " - drm/xe/guc_submit: add missing locking in wedged_fini", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50011", " - ASoC: Intel: soc-acpi-intel-rpl-match: add missing empty item", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50174", " - drm/panthor: Fix race when converting group handle to group object", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49944", " - sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_start", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49945", " - net/ncsi: Disable the ncsi work before freeing the associated structure", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49946", " - ppp: do not assume bh is held in ppp_channel_bridge_input()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49947", " - net: test for not too small csum_start in virtio_net_hdr_to_skb()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49948", " - net: add more sanity checks to qdisc_pkt_len_init()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49949", " - net: avoid potential underflow in qdisc_pkt_len_init() with UFO", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49997", " - net: ethernet: lantiq_etop: fix memory disclosure", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49998", " - net: dsa: improve shutdown sequence", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49999", " - afs: Fix the setting of the server responding flag", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49950", " - Bluetooth: L2CAP: Fix uaf in l2cap_connect", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49951", " - Bluetooth: MGMT: Fix possible crash on mgmt_index_removed", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49952", " - netfilter: nf_tables: prevent nf_skb_duplicated corruption", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49953", " - net/mlx5e: Fix crash caused by calling __xfrm_state_delete() twice", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50000", " - net/mlx5e: Fix NULL deref in mlx5e_tir_builder_alloc()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50001", " - net/mlx5: Fix error path in multi-packet WQE transmit", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50179", " - ceph: remove the incorrect Fw reference check when dirtying pages", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49963", " - mailbox: bcm2835: Fix timeout during suspend mode", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49954", " - static_call: Replace pointless WARN_ON() in static_call_module_notify()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50002", " - static_call: Handle module init failure correctly in", " static_call_del_module()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033)", " - EDAC/synopsys: Fix error injection on Zynq UltraScale+", " - crypto: xor - fix template benchmarking", " - crypto: qat - disable IOV in adf_dev_stop()", " - crypto: qat - fix recovery flow for VFs", " - crypto: qat - ensure correct order in VF restarting handler", " - ACPI: PMIC: Remove unneeded check in tps68470_pmic_opregion_probe()", " - eth: fbnic: select DEVLINK and PAGE_POOL", " - wifi: brcmfmac: introducing fwil query functions", " - wifi: ath9k: Remove error checks when creating debugfs entries", " - wifi: ath12k: fix BSS chan info request WMI command", " - wifi: ath12k: match WMI BSS chan info structure with firmware definition", " - wifi: ath12k: fix invalid AMPDU factor calculation in", " ath12k_peer_assoc_h_he()", " - hwrng: cn10k - Enable by default CN10K driver if Thunder SoC is enabled", " - crypto: x86/aes-gcm - fix PREEMPT_RT issue in gcm_crypt()", " - net: stmmac: dwmac-loongson: Init ref and PTP clocks rate", " - virtio: rename virtio_config_enabled to virtio_config_core_enabled", " - virtio: allow driver to disable the configure change notification", " - virtio-net: synchronize operstate with admin state on up/down", " - virtio-net: synchronize probe with ndo_set_features", " - arm64: signal: Fix some under-bracketed UAPI macros", " - wifi: rtw88: remove CPT execution branch never used", " - RISC-V: KVM: Fix sbiret init before forwarding to userspace", " - RISC-V: KVM: Allow legacy PMU access from guest", " - RISC-V: KVM: Fix to allow hpmcounter31 from the guest", " - mount: handle OOM on mnt_warn_timestamp_expiry", " - autofs: fix missing fput for FSCONFIG_SET_FD", " - netfilter: nf_tables: store new sets in dedicated list", " - wifi: rtw89: limit the PPDU length for VHT rate to 0x40000", " - kselftest/arm64: signal: fix/refactor SVE vector length enumeration", " - arm64: smp: smp_send_stop() and crash_smp_send_stop() should try non-NMI", " first", " - thermal: core: Fold two functions into their respective callers", " - thermal: core: Fix rounding of delay jiffies", " - perf/dwc_pcie: Fix registration issue in multi PCIe controller instances", " - perf/dwc_pcie: Always register for PCIe bus notifier", " - crypto: qat - fix \"Full Going True\" macro definition", " - ACPI: video: force native for Apple MacbookPro9,2", " - wifi: mac80211_hwsim: correct MODULE_PARM_DESC of multi_radio", " - wifi: iwlwifi: config: label 'gl' devices as discrete", " - wifi: iwlwifi: mvm: increase the time between ranging measurements", " - wifi: cfg80211: fix bug of mapping AF3x to incorrect User Priority", " - wifi: mac80211: fix the comeback long retry times", " - wifi: iwlwifi: mvm: allow ESR when we the ROC expires", " - wifi: mac80211: Check for missing VHT elements only for 5 GHz", " - ACPICA: Implement ACPI_WARNING_ONCE and ACPI_ERROR_ONCE", " - ACPICA: executer/exsystem: Don't nag user about every Stall() violating the", " spec", " - padata: Honor the caller's alignment in case of chunk_size 0", " - drivers/perf: hisi_pcie: Record hardware counts correctly", " - drivers/perf: hisi_pcie: Fix TLP headers bandwidth counting", " - kselftest/arm64: Actually test SME vector length changes via sigreturn", " - can: j1939: use correct function name in comment", " - wifi: rtw89: wow: fix wait condition for AOAC report request", " - ACPI: CPPC: Fix MASK_VAL() usage", " - netfilter: nf_tables: elements with timeout below CONFIG_HZ never expire", " - netfilter: nf_tables: reject element expiration with no timeout", " - netfilter: nf_tables: reject expiration higher than timeout", " - netfilter: nf_tables: remove annotation to access set timeout while holding", " lock", " - netfilter: nft_dynset: annotate data-races around set timeout", " - perf/arm-cmn: Refactor node ID handling. Again.", " - perf/arm-cmn: Fix CCLA register offset", " - perf/arm-cmn: Ensure dtm_idx is big enough", " - cpufreq: ti-cpufreq: Introduce quirks to handle syscon fails appropriately", " - thermal: gov_bang_bang: Adjust states of all uninitialized instances", " - wifi: mt76: mt7921: fix wrong UNII-4 freq range check for the channel usage", " - wifi: mt76: mt7996: fix traffic delay when switching back to working channel", " - wifi: mt76: mt7996: fix wmm set of station interface to 3", " - wifi: mt76: mt7996: fix HE and EHT beamforming capabilities", " - wifi: mt76: mt7996: fix EHT beamforming capability check", " - pm:cpupower: Add missing powercap_set_enabled() stub function", " - crypto: ccp - do not request interrupt on cmd completion when irqs disabled", " - crypto: hisilicon/hpre - mask cluster timeout error", " - crypto: hisilicon/qm - reset device before enabling it", " - wifi: mt76: mt7996: fix handling mbss enable/disable", " - wifi: mt76: connac: fix checksum offload fields of connac3 RXD", " - wifi: mt76: mt7603: fix mixed declarations and code", " - wifi: cfg80211: fix UBSAN noise in cfg80211_wext_siwscan()", " - wifi: mt76: mt7915: fix rx filter setting for bfee functionality", " - wifi: mt76: mt7996: fix uninitialized TLV data", " - wifi: cfg80211: fix two more possible UBSAN-detected off-by-one errors", " - af_unix: Don't call skb_get() for OOB skb.", " - af_unix: Remove single nest in manage_oob().", " - af_unix: Rename unlinked_skb in manage_oob().", " - af_unix: Move spin_lock() in manage_oob().", " - Bluetooth: hci_core: Fix sending MGMT_EV_CONNECT_FAILED", " - Bluetooth: hci_sync: Ignore errors from HCI_OP_REMOTE_NAME_REQ_CANCEL", " - can: m_can: enable NAPI before enabling interrupts", " - can: m_can: m_can_close(): stop clocks after device has been shut down", " - Bluetooth: btusb: Fix not handling ZPL/short-transfer", " - bareudp: Pull inner IP header in bareudp_udp_encap_recv().", " - bareudp: Pull inner IP header on xmit.", " - net: enetc: Use IRQF_NO_AUTOEN flag in request_irq()", " - crypto: n2 - Set err to EINVAL if snprintf fails for hmac", " - xsk: fix batch alloc API on non-coherent systems", " - net: ipv6: rpl_iptunnel: Fix memory leak in rpl_input", " - fbnic: Set napi irq value after calling netif_napi_add", " - net: tipc: avoid possible garbage value", " - ublk: move zone report data out of request pdu", " - block, bfq: choose the last bfqq from merge chain in bfq_setup_cooperator()", " - block, bfq: don't break merge chain in bfq_split_bfqq()", " - cachefiles: Fix non-taking of sb_writers around set/removexattr", " - nbd: correct the maximum value for discard sectors", " - erofs: fix incorrect symlink detection in fast symlink", " - erofs: fix error handling in z_erofs_init_decompressor", " - block, bfq: fix uaf for accessing waker_bfqq after splitting", " - block, bfq: fix procress reference leakage for bfqq in merge chain", " - io_uring/io-wq: do not allow pinning outside of cpuset", " - io_uring/io-wq: inherit cpuset of cgroup in io worker", " - spi: ppc4xx: handle irq_of_parse_and_map() errors", " - arm64: dts: exynos: exynos7885-jackpotlte: Correct RAM amount to 4GB", " - arm64: dts: mediatek: mt8186: Fix supported-hw mask for GPU OPPs", " - spi: ppc4xx: Avoid returning 0 when failed to parse and map IRQ", " - firmware: qcom: scm: Disable SDI and write no dump to dump mode", " - regulator: Return actual error in of_regulator_bulk_get_all()", " - arm64: dts: renesas: r9a08g045: Correct GICD and GICR sizes", " - arm64: dts: renesas: r9a07g043u: Correct GICD and GICR sizes", " - arm64: dts: renesas: r9a07g054: Correct GICD and GICR sizes", " - arm64: dts: renesas: r9a07g044: Correct GICD and GICR sizes", " - ARM: dts: microchip: sam9x60: Fix rtc/rtt clocks", " - arm64: tegra: Correct location of power-sensors for IGX Orin", " - arm64: dts: rockchip: Correct vendor prefix for Hardkernel ODROID-M1", " - arm64: dts: ti: k3-j721e-sk: Fix reversed C6x carveout locations", " - arm64: dts: ti: k3-j721e-beagleboneai64: Fix reversed C6x carveout locations", " - spi: bcmbca-hsspi: Fix missing pm_runtime_disable()", " - arm64: dts: qcom: x1e80100: Fix PHY for DP2", " - ARM: dts: microchip: sama7g5: Fix RTT clock", " - ARM: dts: imx7d-zii-rmu2: fix Ethernet PHY pinctrl property", " - arm64: dts: ti: k3-am654-idk: Fix dtbs_check warning in ICSSG dmas", " - ARM: versatile: fix OF node leak in CPUs prepare", " - reset: berlin: fix OF node leak in probe() error path", " - reset: k210: fix OF node leak in probe() error path", " - platform: cznic: turris-omnia-mcu: Fix error check in", " omnia_mcu_register_trng()", " - clocksource/drivers/qcom: Add missing iounmap() on errors in", " msm_dt_timer_init()", " - arm64: dts: mediatek: mt8195: Correct clock order for dp_intf*", " - x86/mm: Use IPIs to synchronize LAM enablement", " - ASoC: rt5682s: Return devm_of_clk_add_hw_provider to transfer the error", " - ASoC: tas2781: Fix a compiling warning reported by robot kernel test due to", " adding tas2563_dvc_table", " - ASoC: tas2781-i2c: Drop weird GPIO code", " - ASoC: tas2781-i2c: Get the right GPIO line", " - selftests/ftrace: Add required dependency for kprobe tests", " - ALSA: hda: cs35l41: fix module autoloading", " - selftests/ftrace: Fix test to handle both old and new kernels", " - x86/boot/64: Strip percpu address space when setting up GDT descriptors", " - m68k: Fix kernel_clone_args.flags in m68k_clone()", " - ASoC: loongson: fix error release", " - selftests/ftrace: Fix eventfs ownership testcase to find mount point", " - selftests:resctrl: Fix build failure on archs without __cpuid_count()", " - cgroup/pids: Avoid spurious event notification", " - hwmon: (max16065) Fix overflows seen when writing limits", " - hwmon: (max16065) Fix alarm attributes", " - iommu/arm-smmu: Un-demote unhandled-fault msg", " - iommu/arm-smmu-v3: Fix a NULL vs IS_ERR() check", " - mtd: slram: insert break after errors in parsing the map", " - hwmon: (ntc_thermistor) fix module autoloading", " - power: supply: axp20x_battery: Remove design from min and max voltage", " - power: supply: max17042_battery: Fix SOC threshold calc w/ no current sense", " - fbdev: hpfb: Fix an error handling path in hpfb_dio_probe()", " - iommu/amd: Handle error path in amd_iommu_probe_device()", " - iommu/amd: Allocate the page table root using GFP_KERNEL", " - iommu/amd: Move allocation of the top table into v1_alloc_pgtable", " - iommu/amd: Set the pgsize_bitmap correctly", " - iommu/amd: Do not set the D bit on AMD v2 table entries", " - mtd: powernv: Add check devm_kasprintf() returned value", " - rcu/nocb: Fix RT throttling hrtimer armed from offline CPU", " - mtd: rawnand: mtk: Use for_each_child_of_node_scoped()", " - mtd: rawnand: mtk: Factorize out the logic cleaning mtk chips", " - mtd: rawnand: mtk: Fix init error path", " - iommu/arm-smmu-qcom: hide last LPASS SMMU context bank from linux", " - iommu/arm-smmu-qcom: Work around SDM845 Adreno SMMU w/ 16K pages", " - iommu/arm-smmu-qcom: apply num_context_bank fixes for SDM630 / SDM660", " - pmdomain: core: Harden inter-column space in debug summary", " - pmdomain: core: Fix \"managed by\" alignment in debug summary", " - drm/stm: Fix an error handling path in stm_drm_platform_probe()", " - drm/stm: ltdc: check memory returned by devm_kzalloc()", " - drm/amd/display: free bo used for dmub bounding box", " - drm/amdgpu: properly handle vbios fake edid sizing", " - drm/radeon: properly handle vbios fake edid sizing", " - drm/amd/display: Reset VRR config during resume", " - scsi: smartpqi: revert propagate-the-multipath-failure-to-SML-quickly", " - scsi: sd: Don't check if a write for REQ_ATOMIC", " - scsi: block: Don't check REQ_ATOMIC for reads", " - scsi: NCR5380: Check for phase match during PDMA fixup", " - drm/amd/amdgpu: Properly tune the size of struct", " - drm/amd/display: Improve FAM control for DCN401", " - drm/rockchip: vop: Allow 4096px width scaling", " - drm/rockchip: dw_hdmi: Fix reading EDID when using a forced mode", " - drm/radeon/evergreen_cs: fix int overflow errors in cs track offsets", " - drm/bridge: lontium-lt8912b: Validate mode in drm_bridge_funcs::mode_valid()", " - drm/vc4: hdmi: Handle error case of pm_runtime_resume_and_get", " - drm/mediatek: Fix missing configuration flags in mtk_crtc_ddp_config()", " - drm/mediatek: Use spin_lock_irqsave() for CRTC event lock", " - powerpc/8xx: Fix initial memory mapping", " - powerpc/8xx: Fix kernel vs user address comparison", " - powerpc/vdso: Inconditionally use CFUNC macro", " - drm/msm: Use a7xx family directly in gpu_state", " - drm/msm: Dump correct dbgahb clusters on a750", " - drm/msm: Fix CP_BV_DRAW_STATE_ADDR name", " - drm/msm: Fix incorrect file name output in adreno_request_fw()", " - drm/msm/a5xx: disable preemption in submits by default", " - drm/msm/a5xx: properly clear preemption records on resume", " - drm/msm/a5xx: fix races in preemption evaluation stage", " - drm/msm/a5xx: workaround early ring-buffer emptiness check", " - ipmi: docs: don't advertise deprecated sysfs entries", " - drm/msm/dp: enable widebus on all relevant chipsets", " - drm/msm/dsi: correct programming sequence for SM8350 / SM8450", " - drm/msm: fix %s null argument error", " - platform/x86: ideapad-laptop: Make the scope_guard() clear of its scope", " - kselftest: dt: Ignore nodes that have ancestors disabled", " - drivers:drm:exynos_drm_gsc:Fix wrong assignment in gsc_bind()", " - drm/amdgpu: fix invalid fence handling in amdgpu_vm_tlb_flush", " - xen: use correct end address of kernel for conflict checking", " - HID: wacom: Support sequence numbers smaller than 16-bit", " - HID: wacom: Do not warn about dropped packets for first packet", " - ata: libata: Clear DID_TIME_OUT for ATA PT commands with sense data", " - xen: introduce generic helper checking for memory map conflicts", " - xen: move max_pfn in xen_memory_setup() out of function scope", " - xen: add capability to remap non-RAM pages to different PFNs", " - xen: tolerate ACPI NVS memory overlapping with Xen allocated memory", " - drm/xe: fix missing 'xe_vm_put'", " - xen/swiotlb: add alignment check for dma buffers", " - xen/swiotlb: fix allocated size", " - sched/fair: Make SCHED_IDLE entity be preempted in strict hierarchy", " - bpf, x64: Fix tailcall hierarchy", " - bpf, arm64: Fix tailcall hierarchy", " - bpf: Fix compare error in function retval_range_within", " - selftests/bpf: Workaround strict bpf_lsm return value check.", " - selftests/bpf: Fix error linking uprobe_multi on mips", " - selftests/bpf: Fix wrong binary in Makefile log output", " - tools/runqslower: Fix LDFLAGS and add LDLIBS support", " - selftests/bpf: Use pid_t consistently in test_progs.c", " - selftests/bpf: Fix compile error from rlim_t in sk_storage_map.c", " - selftests/bpf: Fix error compiling bpf_iter_setsockopt.c with musl libc", " - selftests/bpf: Drop unneeded error.h includes", " - selftests/bpf: Fix missing ARRAY_SIZE() definition in bench.c", " - selftests/bpf: Fix missing UINT_MAX definitions in benchmarks", " - selftests/bpf: Fix missing BUILD_BUG_ON() declaration", " - selftests/bpf: Fix include of ", " - selftests/bpf: Fix compiling parse_tcp_hdr_opt.c with musl-libc", " - selftests/bpf: Fix compiling kfree_skb.c with musl-libc", " - selftests/bpf: Fix compiling flow_dissector.c with musl-libc", " - selftests/bpf: Fix compiling tcp_rtt.c with musl-libc", " - selftests/bpf: Fix compiling core_reloc.c with musl-libc", " - selftests/bpf: Fix errors compiling lwt_redirect.c with musl libc", " - selftests/bpf: Fix errors compiling decap_sanity.c with musl libc", " - selftests/bpf: Fix errors compiling crypto_sanity.c with musl libc", " - selftests/bpf: Fix errors compiling cg_storage_multi.h with musl libc", " - libbpf: Don't take direct pointers into BTF data from st_ops", " - selftests/bpf: Fix arg parsing in veristat, test_progs", " - selftests/bpf: Fix error compiling test_lru_map.c", " - selftests/bpf: Fix C++ compile error from missing _Bool type", " - selftests/bpf: Fix redefinition errors compiling lwt_reroute.c", " - selftests/bpf: Fix compile if backtrace support missing in libc", " - selftests/bpf: Fix error compiling tc_redirect.c with musl libc", " - s390/entry: Move early program check handler to entry.S", " - s390/entry: Make early program check handler relocated lowcore aware", " - libbpf: Fix license for btf_relocate.c", " - samples/bpf: Fix compilation errors with cf-protection option", " - selftests/bpf: no need to track next_match_pos in struct test_loader", " - selftests/bpf: extract test_loader->expect_msgs as a data structure", " - selftests/bpf: allow checking xlated programs in verifier_* tests", " - selftests/bpf: __arch_* macro to limit test cases to specific archs", " - selftests/bpf: fix to avoid __msg tag de-duplication by clang", " - selftests/bpf: Fix incorrect parameters in NULL pointer checking", " - libbpf: Fix bpf_object__open_skeleton()'s mishandling of options", " - s390/ap: Fix deadlock caused by recursive lock of the AP bus scan mutex", " - libbpf: Ensure new BTF objects inherit input endianness", " - xz: cleanup CRC32 edits from 2018", " - kthread: fix task state in kthread worker if being frozen", " - ext4: clear EXT4_GROUP_INFO_WAS_TRIMMED_BIT even mount with discard", " - bpftool: Fix handling enum64 in btf dump sorting", " - sched/deadline: Fix schedstats vs deadline servers", " - smackfs: Use rcu_assign_pointer() to ensure safe assignment in smk_set_cipso", " - ext4: avoid buffer_head leak in ext4_mark_inode_used()", " - ext4: avoid potential buffer_head leak in __ext4_new_inode()", " - ext4: avoid negative min_clusters in find_group_orlov()", " - ext4: return error on ext4_find_inline_entry", " - sched/numa: Fix the vma scan starving issue", " - nilfs2: determine empty node blocks as corrupted", " - sched/pelt: Use rq_clock_task() for hw_pressure", " - bpf: Fix bpf_strtol and bpf_strtoul helpers for 32bit", " - bpf: Improve check_raw_mode_ok test for MEM_UNINIT-tagged types", " - perf scripts python cs-etm: Restore first sample log in verbose mode", " - perf bpf: Move BPF disassembly routines to separate file to avoid clash with", " capstone bpf headers", " - perf mem: Free the allocated sort string, fixing a leak", " - perf lock contention: Change stack_id type to s32", " - perf vendor events: SKX, CLX, SNR uncore cache event fixes", " - perf inject: Fix leader sampling inserting additional samples", " - perf report: Fix --total-cycles --stdio output error", " - perf build: Fix up broken capstone feature detection fast path", " - perf sched timehist: Fix missing free of session in perf_sched__timehist()", " - perf stat: Display iostat headers correctly", " - perf dwarf-aux: Check allowed location expressions when collecting variables", " - perf annotate-data: Fix off-by-one in location range check", " - perf dwarf-aux: Handle bitfield members from pointer access", " - perf hist: Don't set hpp_fmt_value for members in --no-group", " - perf sched timehist: Fixed timestamp error when unable to confirm event", " sched_in time", " - perf time-utils: Fix 32-bit nsec parsing", " - perf mem: Check mem_events for all eligible PMUs", " - perf mem: Fix missed p-core mem events on ADL and RPL", " - clk: imx: clk-audiomix: Correct parent clock for earc_phy and audpll", " - clk: imx: imx6ul: fix default parent for enet*_ref_sel", " - clk: imx: composite-8m: Enable gate clk with mcore_booted", " - clk: imx: composite-93: keep root clock on when mcore enabled", " - clk: imx: composite-7ulp: Check the PCC present bit", " - clk: imx: fracn-gppll: fix fractional part of PLL getting lost", " - clk: imx: imx8mp: fix clock tree update of TF-A managed clocks", " - clk: imx: imx8qxp: Register dc0_bypass0_clk before disp clk", " - clk: imx: imx8qxp: Parent should be initialized earlier than the clock", " - quota: avoid missing put_quota_format when DQUOT_SUSPENDED is passed", " - remoteproc: imx_rproc: Correct ddr alias for i.MX8M", " - remoteproc: imx_rproc: Initialize workqueue earlier", " - clk: rockchip: Set parent rate for DCLK_VOP clock on RK3228", " - clk: qcom: dispcc-sm8550: fix several supposed typos", " - clk: qcom: dispcc-sm8550: use rcg2_ops for mdss_dptx1_aux_clk_src", " - clk: qcom: dispcc-sm8650: Update the GDSC flags", " - clk: qcom: dispcc-sm8550: use rcg2_shared_ops for ESC RCGs", " - leds: bd2606mvv: Fix device child node usage in bd2606mvv_probe()", " - pinctrl: renesas: rzg2l: Return -EINVAL if the pin doesn't support", " PIN_CFG_OEN", " - pinctrl: ti: ti-iodelay: Fix some error handling paths", " - phy: phy-rockchip-samsung-hdptx: Explicitly include pm_runtime.h", " - Input: ilitek_ts_i2c - avoid wrong input subsystem sync", " - Input: ilitek_ts_i2c - add report id message validation", " - media: raspberrypi: VIDEO_RASPBERRYPI_PISP_BE should depend on ARCH_BCM2835", " - [Config] updateconfigs for VIDEO_RASPBERRYPI_PISP_BE", " - PCI: Wait for Link before restoring Downstream Buses", " - firewire: core: correct range of block for case of switch statement", " - media: staging: media: starfive: camss: Drop obsolete return value", " documentation", " - clk: qcom: ipq5332: Register gcc_qdss_tsctr_clk_src", " - clk: qcom: dispcc-sm8250: use special function for Lucid 5LPE PLL", " - leds: pca995x: Use device_for_each_child_node() to access device child nodes", " - leds: pca995x: Fix device child node usage in pca995x_probe()", " - x86/PCI: Check pcie_find_root_port() return for NULL", " - PCI: xilinx-nwl: Fix register misspelling", " - PCI: xilinx-nwl: Clean up clock on probe failure/removal", " - leds: gpio: Set num_leds after allocation", " - media: platform: rzg2l-cru: rzg2l-csi2: Add missing MODULE_DEVICE_TABLE", " - pinctrl: single: fix missing error code in pcs_probe()", " - clk: at91: sama7g5: Allocate only the needed amount of memory for PLLs", " - iommufd/selftest: Fix buffer read overrrun in the dirty test", " - RDMA/bnxt_re: Fix the table size for PSN/MSN entries", " - media: imagination: VIDEO_E5010_JPEG_ENC should depend on ARCH_K3", " - [Config] updateconfigs for VIDEO_E5010_JPEG_ENC", " - RDMA/rtrs: Reset hb_missed_cnt after receiving other traffic from peer", " - clk: ti: dra7-atl: Fix leak of of_nodes", " - clk: starfive: Use pm_runtime_resume_and_get to fix pm_runtime_get_sync()", " usage", " - clk: rockchip: rk3588: Fix 32k clock name for pmu_24m_32k_100m_src_p", " - nfsd: remove unneeded EEXIST error check in nfsd_do_file_acquire", " - nfsd: fix refcount leak when file is unhashed after being found", " - pinctrl: mvebu: Fix devinit_dove_pinctrl_probe function", " - dt-bindings: PCI: layerscape-pci: Replace fsl,lx2160a-pcie with", " fsl,lx2160ar2-pcie", " - iommufd: Check the domain owner of the parent before creating a nesting", " domain", " - RDMA/erdma: Return QP state in erdma_query_qp", " - RDMA/mlx5: Fix counter update on MR cache mkey creation", " - RDMA/mlx5: Limit usage of over-sized mkeys from the MR cache", " - RDMA/mlx5: Drop redundant work canceling from clean_keys()", " - RDMA/mlx5: Fix MR cache temp entries cleanup", " - watchdog: imx_sc_wdt: Don't disable WDT in suspend", " - RDMA/hns: Don't modify rq next block addr in HIP09 QPC", " - RDMA/hns: Fix the overflow risk of hem_list_calc_ba_range()", " - RDMA/hns: Fix VF triggering PF reset in abnormal interrupt handler", " - RDMA/hns: Fix 1bit-ECC recovery address in non-4K OS", " - RDMA/hns: Optimize hem allocation performance", " - RDMA/hns: Fix restricted __le16 degrades to integer issue", " - Input: ims-pcu - fix calling interruptible mutex", " - RDMA/mlx5: Obtain upper net device only when needed", " - PCI: qcom-ep: Enable controller resources like PHY only after refclk is", " available", " - riscv: Fix fp alignment bug in perf_callchain_user()", " - RDMA/hns: Fix ah error counter in sw stat not increasing", " - RDMA/irdma: fix error message in irdma_modify_qp_roce()", " - ntb_perf: Fix printk format", " - ntb: Force physically contiguous allocation of rx ring buffers", " - nfsd: untangle code in nfsd4_deleg_getattr_conflict()", " - nfsd: fix initial getattr on write delegation", " - crypto: caam - Pad SG length when allocating hash edesc", " - crypto: powerpc/p10-aes-gcm - Disable CRYPTO_AES_GCM_P10", " - [Config] disable CRYPTO_AES_GCM_P10", " - f2fs: atomic: fix to avoid racing w/ GC", " - f2fs: reduce expensive checkpoint trigger frequency", " - f2fs: fix to avoid racing in between read and OPU dio write", " - f2fs: Create COW inode from parent dentry for atomic write", " - f2fs: fix to wait page writeback before setting gcing flag", " - f2fs: atomic: fix to truncate pagecache before on-disk metadata truncation", " - f2fs: compress: don't redirty sparse cluster during {,de}compress", " - f2fs: prevent atomic file from being dirtied before commit", " - spi: airoha: fix dirmap_{read,write} operations", " - spi: airoha: fix airoha_snand_{write,read}_data data_len estimation", " - spi: atmel-quadspi: Undo runtime PM changes at driver exit time", " - spi: spi-fsl-lpspi: Undo runtime PM changes at driver exit time", " - lib/sbitmap: define swap_lock as raw_spinlock_t", " - spi: airoha: remove read cache in airoha_snand_dirmap_read()", " - spi: atmel-quadspi: Avoid overwriting delay register settings", " - NFSv4.2: Fix detection of \"Proxying of Times\" server support", " - nvme-multipath: system fails to create generic nvme device", " - iio: adc: ad7606: fix oversampling gpio array", " - iio: adc: ad7606: fix standby gpio state to match the documentation", " - driver core: Fix error handling in driver API device_rename()", " - ABI: testing: fix admv8818 attr description", " - iio: chemical: bme680: Fix read/write ops to device by adding mutexes", " - iio: magnetometer: ak8975: drop incorrect AK09116 compatible", " - dt-bindings: iio: asahi-kasei,ak8975: drop incorrect AK09116 compatible", " - serial: 8250: omap: Cleanup on error in request_irq", " - Coresight: Set correct cs_mode for TPDM to fix disable issue", " - Coresight: Set correct cs_mode for dummy source to fix disable issue", " - coresight: tmc: sg: Do not leak sg_table", " - interconnect: icc-clk: Add missed num_nodes initialization", " - interconnect: qcom: sm8250: Enable sync_state", " - dm integrity: fix gcc 5 warning", " - cxl/pci: Fix to record only non-zero ranges", " - um: remove ARCH_NO_PREEMPT_DYNAMIC", " - Revert \"dm: requeue IO if mapping table not yet available\"", " - net: phy: aquantia: fix -ETIMEDOUT PHY probe failure when firmware not", " present", " - net: xilinx: axienet: Schedule NAPI in two steps", " - net: xilinx: axienet: Fix packet counting", " - net: ipv6: select DST_CACHE from IPV6_RPL_LWTUNNEL", " - net: qrtr: Update packets cloning when broadcasting", " - net: phy: aquantia: fix setting active_low bit", " - net: phy: aquantia: fix applying active_low bit after reset", " - net: ravb: Fix maximum TX frame size for GbEth devices", " - net: ravb: Fix R-Car RX frame size limit", " - virtio_net: Fix mismatched buf address when unmapping for small packets", " - netfilter: nf_tables: Keep deleted flowtable hooks until after RCU", " - netfilter: ctnetlink: compile ctnetlink_label_size with", " CONFIG_NF_CONNTRACK_EVENTS", " - netfilter: nf_tables: use rcu chain hook list iterator from netlink dump", " path", " - netfilter: nf_tables: missing objects with no memcg accounting", " - selftests: netfilter: Avoid hanging ipvs.sh", " - io_uring/sqpoll: do not allow pinning outside of cpuset", " - io_uring/rw: treat -EOPNOTSUPP for IOCB_NOWAIT like -EAGAIN", " - io_uring: check for presence of task_work rather than TIF_NOTIFY_SIGNAL", " - mm: migrate: annotate data-race in migrate_folio_unmap()", " - drm/amd/display: Fix Synaptics Cascaded Panamera DSC Determination", " - drm/amd/display: Add DSC Debug Log", " - drm/amdgpu/display: Fix a mistake in revert commit", " - xen: move checks for e820 conflicts further up", " - xen: allow mapping ACPI data using a different physical address", " - io_uring/sqpoll: retain test for whether the CPU is valid", " - drm/amd/display: disable_hpo_dp_link_output: Check link_res->hpo_dp_link_enc", " before using it", " - io_uring/sqpoll: do not put cpumask on stack", " - selftests/bpf: correctly move 'log' upon successful match", " - Remove *.orig pattern from .gitignore", " - PCI: Revert to the original speed after PCIe failed link retraining", " - PCI: Clear the LBMS bit after a link retrain", " - PCI: dra7xx: Fix threaded IRQ request for \"dra7xx-pcie-main\" IRQ", " - PCI: imx6: Fix missing call to phy_power_off() in error handling", " - PCI: imx6: Fix establish link failure in EP mode for i.MX8MM and i.MX8MP", " - PCI: imx6: Fix i.MX8MP PCIe EP's occasional failure to trigger MSI", " - PCI: Correct error reporting with PCIe failed link retraining", " - PCI: Use an error code with PCIe failed link retraining", " - PCI: xilinx-nwl: Fix off-by-one in INTx IRQ handler", " - PCI: dra7xx: Fix error handling when IRQ request fails in probe", " - Revert \"soc: qcom: smd-rpm: Match rpmsg channel instead of compatible\"", " - ASoC: rt5682: Return devm_of_clk_add_hw_provider to transfer the error", " - soc: fsl: cpm1: qmc: Update TRNSYNC only in transparent mode", " - soc: fsl: cpm1: tsa: Fix tsa_write8()", " - soc: versatile: integrator: fix OF node leak in probe() error path", " - Revert \"media: tuners: fix error return code of", " hybrid_tuner_request_state()\"", " - iommu/amd: Fix argument order in amd_iommu_dev_flush_pasid_all()", " - Input: adp5588-keys - fix check on return code", " - Input: i8042 - add TUXEDO Stellaris 16 Gen5 AMD to i8042 quirk table", " - Input: i8042 - add TUXEDO Stellaris 15 Slim Gen6 AMD to i8042 quirk table", " - Input: i8042 - add another board name for TUXEDO Stellaris Gen5 AMD line", " - KVM: arm64: Add memory length checks and remove inline in do_ffa_mem_xfer", " - KVM: x86: Enforce x2APIC's must-be-zero reserved ICR bits", " - KVM: x86: Move x2APIC ICR helper above kvm_apic_write_nodecode()", " - KVM: x86: Re-split x2APIC ICR into ICR+ICR2 for AMD (x2AVIC)", " - drm/amdgpu/mes12: reduce timeout", " - drm/amdgpu/mes11: reduce timeout", " - drm/amdkfd: Add SDMA queue quantum support for GFX12", " - drm/amdgpu: update golden regs for gfx12", " - drm/amdgpu/mes12: set enable_level_process_quantum_check", " - drm/amdgpu/vcn: enable AV1 on both instances", " - drm/amd/pm: update workload mask after the setting", " - drm/amdgpu: fix PTE copy corruption for sdma 7", " - drm/amdgpu: bump driver version for cleared VRAM", " - drm/amdgpu/mes12: switch SET_SHADER_DEBUGGER pkt to mes schq pipe", " - drm/amdgpu: Fix selfring initialization sequence on soc24", " - drm/amd/display: Add HDMI DSC native YCbCr422 support", " - drm/amd/display: Round calculated vtotal", " - drm/amd/display: Clean up dsc blocks in accelerated mode", " - drm/amd/display: Block timing sync for different output formats in pmo", " - drm/amd/display: Validate backlight caps are sane", " - drm/amd/display: Disable SYMCLK32_LE root clock gating", " - drm/amd/display: Block dynamic IPS2 on DCN35 for incompatible FW versions", " - drm/amd/display: Enable DML2 override_det_buffer_size_kbytes", " - drm/amd/display: Skip to enable dsc if it has been off", " - drm/amd/display: Fix underflow when setting underscan on DCN401", " - drm/amd/display: Update IPS default mode for DCN35/DCN351", " - objtool: Handle frame pointer related instructions", " - powerpc/atomic: Use YZ constraints for DS-form instructions", " - ksmbd: make __dir_empty() compatible with POSIX", " - ksmbd: allow write with FILE_APPEND_DATA", " - ksmbd: handle caseless file creation", " - ata: libata-scsi: Fix ata_msense_control() CDL page reporting", " - scsi: ufs: qcom: Update MODE_MAX cfg_bw value", " - scsi: lpfc: Restrict support for 32 byte CDBs to specific HBAs", " - scsi: mac_scsi: Revise printk(KERN_DEBUG ...) messages", " - scsi: mac_scsi: Refactor polling loop", " - scsi: mac_scsi: Disallow bus errors during PDMA send", " - can: esd_usb: Remove CAN_CTRLMODE_3_SAMPLES for CAN-USB/3-FD", " - wifi: rtw88: Fix USB/SDIO devices not transmitting beacons", " - usbnet: fix cyclical race on disconnect with work queue", " - arm64: dts: mediatek: mt8195-cherry: Mark USB 3.0 on xhci1 as disabled", " - arm64: dts: mediatek: mt8395-nio-12l: Mark USB 3.0 on xhci1 as disabled", " - USB: appledisplay: close race between probe and completion handler", " - USB: misc: cypress_cy7c63: check for short transfer", " - USB: class: CDC-ACM: fix race between get_serial and set_serial", " - USB: misc: yurex: fix race between read and write", " - usb: xhci: fix loss of data on Cadence xHC", " - usb: cdnsp: Fix incorrect usb_request status", " - usb: xHCI: add XHCI_RESET_ON_RESUME quirk for Phytium xHCI host", " - usb: gadget: dummy_hcd: execute hrtimer callback in softirq context", " - usb: dwc2: drd: fix clock gating on USB role switch", " - bus: integrator-lm: fix OF node leak in probe()", " - bus: mhi: host: pci_generic: Update EDL firmware path for Foxconn modems", " - bus: mhi: host: pci_generic: Fix the name for the Telit FE990A", " - tty: rp2: Fix reset with non forgiving PCIe host bridges", " - pps: add an error check in parport_attach", " - serial: don't use uninitialized value in uart_poll_init()", " - xhci: Set quirky xHC PCI hosts to D3 _after_ stopping and freeing them.", " - serial: qcom-geni: fix fifo polling timeout", " - serial: qcom-geni: fix false console tx restart", " - crypto: qcom-rng - fix support for ACPI-based systems", " - crypto: ccp - Properly unregister /dev/sev on sev PLATFORM_STATUS failure", " - drbd: Fix atomicity violation in drbd_uuid_set_bm()", " - drbd: Add NULL check for net_conf to prevent dereference in state validation", " - ACPI: resource: Do IRQ override on MECHREV GM7XG0M", " - ACPI: resource: Add another DMI match for the TongFang GMxXGxx", " - intel_idle: add Granite Rapids Xeon support", " - intel_idle: fix ACPI _CST matching for newer Xeon platforms", " - x86/entry: Remove unwanted instrumentation in common_interrupt()", " - perf/x86/intel: Allow to setup LBR for counting event for BPF", " - perf/x86/intel/pt: Fix sampling synchronization", " - btrfs: subpage: fix the bitmap dump which can cause bitmap corruption", " - wifi: mt76: mt7921: Check devm_kasprintf() returned value", " - wifi: mt76: mt7915: check devm_kasprintf() returned value", " - idpf: fix netdev Tx queue stop/wake", " - wifi: rtw88: 8821cu: Remove VID/PID 0bda:c82c", " - wifi: rtw88: 8822c: Fix reported RX band width", " - wifi: rtw88: 8703b: Fix reported RX band width", " - wifi: mt76: mt7615: check devm_kasprintf() returned value", " - wifi: mt76: mt7925: fix a potential association failure upon resuming", " - debugfs show actual source in /proc/mounts", " - debugobjects: Fix conditions in fill_pool()", " - btrfs: tree-checker: fix the wrong output of data backref objectid", " - btrfs: always update fstrim_range on failure in FITRIM ioctl", " - f2fs: fix several potential integer overflows in file offsets", " - f2fs: prevent possible int overflow in dir_block_index()", " - f2fs: avoid potential int overflow in sanity_check_area_boundary()", " - hwrng: mtk - Use devm_pm_runtime_enable", " - hwrng: bcm2835 - Add missing clk_disable_unprepare in bcm2835_rng_init", " - hwrng: cctrng - Add missing clk_disable_unprepare in cctrng_resume", " - arm64: esr: Define ESR_ELx_EC_* constants as UL", " - arm64: errata: Enable the AC03_CPU_38 workaround for ampere1a", " - arm64: dts: mediatek: mt8186-corsola: Disable DPI display interface", " - arm64: dts: rockchip: Raise Pinebook Pro's panel backlight PWM frequency", " - arm64: dts: qcom: sa8775p: Mark APPS and PCIe SMMUs as DMA coherent", " - arm64: dts: rockchip: Correct the Pinebook Pro battery design capacity", " - fs: Fix file_set_fowner LSM hook inconsistencies", " - nfs: fix memory leak in error path of nfs4_do_reclaim", " - EDAC/igen6: Fix conversion of system address to physical memory address", " - eventpoll: Annotate data-race of busy_poll_usecs", " - md: Don't flush sync_work in md_write_start()", " - cpuidle: riscv-sbi: Use scoped device node handling to fix missing", " of_node_put", " - lsm: add the inode_free_security_rcu() LSM implementation hook", " - spi: fspi: involve lut_num for struct nxp_fspi_devtype_data", " - dt-bindings: spi: nxp-fspi: add imx8ulp support", " - ARM: dts: imx6ul-geam: fix fsl,pins property in tscgrp pinctrl", " - ARM: dts: imx6ull-seeed-npi: fix fsl,pins property in tscgrp pinctrl", " - tools/nolibc: include arch.h from string.h", " - soc: versatile: realview: fix memory leak during device remove", " - soc: versatile: realview: fix soc_dev leak during device remove", " - usb: typec: ucsi: Call CANCEL from single location", " - usb: typec: ucsi: Fix busy loop on ASUS VivoBooks", " - soc: qcom: geni-se: add GP_LENGTH/IRQ_EN_SET/IRQ_EN_CLEAR registers", " - serial: qcom-geni: fix arg types for qcom_geni_serial_poll_bit()", " - serial: qcom-geni: introduce qcom_geni_serial_poll_bitfield()", " - serial: qcom-geni: fix console corruption", " - thermal: core: Store trip sysfs attributes in thermal_trip_desc", " - thermal: sysfs: Get to trips via attribute pointers", " - thermal: sysfs: Refine the handling of trip hysteresis changes", " - thermal: sysfs: Add sanity checks for trip temperature and hysteresis", " - bpf: lsm: Set bpf_lsm_blob_sizes.lbs_task to 0", " - compiler.h: specify correct attribute for .rodata..c_jump_table", " - lockdep: fix deadlock issue between lockdep and rcu", " - mm/hugetlb_vmemmap: batch HVO work when demoting", " - s390/ftrace: Avoid calling unwinder in ftrace_return_address()", " - selftest mm/mseal: fix test_seal_mremap_move_dontunmap_anyaddr", " - mm: only enforce minimum stack gap size if it's sensible", " - spi: fspi: add support for imx8ulp", " - module: Fix KCOV-ignored file name", " - fbdev: xen-fbfront: Assign fb_info->device", " - tpm: export tpm2_sessions_init() to fix ibmvtpm building", " - mm/huge_memory: ensure huge_zero_folio won't have large_rmappable flag set", " - mm: change vmf_anon_prepare() to __vmf_anon_prepare()", " - mm/damon/vaddr: protect vma traversal in __damon_va_thre_regions() with rcu", " read lock", " - i2c: aspeed: Update the stop sw state when the bus recovery occurs", " - i2c: isch: Add missed 'else'", " - i2c: xiic: Try re-initialization on bus busy timeout", " - Documentation: KVM: fix warning in \"make htmldocs\"", " - spi: atmel-quadspi: Fix wrong register value written to MR", " - Revert: \"dm-verity: restart or panic on an I/O error\"", " - Linux 6.11.2", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47675", " - bpf: Fix use-after-free in bpf_uprobe_multi_link_attach()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47676", " - mm/hugetlb.c: fix UAF of vma in hugetlb fault pathway", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47677", " - exfat: resolve memory leak from exfat_create_upcase_table()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47725", " - dm-verity: restart or panic on an I/O error", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47739", " - padata: use integer wrap around to prevent deadlock on seq_nr overflow", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47678", " - icmp: change the order of rate limits", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47733", " - netfs: Delete subtree of 'fs/netfs' when netfs module exits", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47679", " - vfs: fix race between evice_inodes() and find_inode()&iput()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49859", " - f2fs: fix to check atomic_file in f2fs ioctl interfaces", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47680", " - f2fs: check discard support for conventional zones", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47740", " - f2fs: Require FMODE_WRITE for atomic write ioctls", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47726", " - f2fs: fix to wait dio completion", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47741", " - btrfs: fix race setting file private on concurrent lseek using same fd", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47681", " - wifi: mt76: mt7996: fix NULL pointer dereference in mt7996_mcu_sta_bfer_he", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49858", " - efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49860", " - ACPI: sysfs: validate return type of _STR method", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47742", " - firmware_loader: Block path traversal", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47682", " - scsi: sd: Fix off-by-one error in sd_read_block_characteristics()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47743", " - KEYS: prevent NULL pointer dereference in find_asymmetric_key()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47727", " - x86/tdx: Fix \"in-kernel MMIO\" check", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47744", " - KVM: Use dedicated mutex to protect kvm_usage_count to avoid deadlock", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47719", " - iommufd: Protect against overflow of ALIGN() during iova allocation", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47745", " - mm: call the security_mmap_file() LSM hook in remap_file_pages()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47746", " - fuse: use exclusive lock when FUSE_I_CACHE_IO_MODE is set", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47734", " - bonding: Fix unnecessary warnings and logs from bond_xdp_get_xmit_slave()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47684", " - tcp: check skb is non-NULL in tcp_rto_delta_us()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47747", " - net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race", " Condition", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47685", " - netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47686", " - ep93xx: clock: Fix off by one in ep93xx_div_recalc_rate()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47748", " - vhost_vdpa: assign irq bypass producer token correctly", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47687", " - vdpa/mlx5: Fix invalid mr resource destroy", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47688", " - driver core: Fix a potential null-ptr-deref in module_add_driver()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47689", " - f2fs: fix to don't set SB_RDONLY in f2fs_handle_critical_error()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47690", " - f2fs: get rid of online repaire on corrupted directory", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47691", " - f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47692", " - nfsd: return -EINVAL when namelen is 0", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47737", " - nfsd: call cache_put if xdr_reserve_space returns NULL", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2023-52917", " - ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47749", " - RDMA/cxgb4: Added NULL check for lookup_atid", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47735", " - RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47750", " - RDMA/hns: Fix Use-After-Free of rsv_qp on HIP08", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47751", " - PCI: kirin: Fix buffer overflow in kirin_pcie_parse_port()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47693", " - IB/core: Fix ib_cache_setup_one error flow cleanup", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47694", " - IB/mlx5: Fix UMR pd cleanup on error flow of driver init", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47695", " - RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47752", " - media: mediatek: vcodec: Fix H264 stateless decoder smatch warning", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47753", " - media: mediatek: vcodec: Fix VP8 stateless decoder smatch warning", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47754", " - media: mediatek: vcodec: Fix H264 multi stateless decoder smatch warning", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47696", " - RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47755", " - nvdimm: Fix devs leaks in scan_labels()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47756", " - PCI: keystone: Fix if-statement expression in ks_pcie_quirk()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47697", " - drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47698", " - drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47728", " - bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49861", " - bpf: Fix helper writes to read-only maps", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47757", " - nilfs2: fix potential oob read in nilfs_btree_check_delete()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47699", " - nilfs2: fix potential null-ptr-deref in nilfs_btree_insert()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47700", " - ext4: check stripe size compatibility on remount as well", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47701", " - ext4: avoid OOB when system.data xattr changes underneath the filesystem", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49850", " - bpf: correctly handle malformed BPF_CORE_TYPE_ID_LOCAL relos", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47702", " - bpf: Fail verification for sign-extension of packet data/data_end/data_meta", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47703", " - bpf, lsm: Add check for BPF LSM return value", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49851", " - tpm: Clean up TPM space after command failure", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47723", " - jfs: fix out-of-bounds in dbNextAG() and diAlloc()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49852", " - scsi: elx: libefc: Fix potential use after free in efc_nport_vport_del()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47720", " - drm/amd/display: Add null check for set_output_gamma in", " dcn30_set_output_transfer_func", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47704", " - drm/amd/display: Check link_res->hpo_dp_link_enc before using it", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49853", " - firmware: arm_scmi: Fix double free in OPTEE transport", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47705", " - block: fix potential invalid pointer dereference in blk_add_partition", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47736", " - erofs: handle overlapped pclusters out of crafted images properly", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47706", " - block, bfq: fix possible UAF for bfqq->bic with merge chain", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49855", " - nbd: fix race between timeout and normal completion", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47707", " - ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47708", " - netkit: Assign missing bpf_net_context", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47709", " - can: bcm: Clear bo->bcm_proc_read after remove_proc_entry().", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47710", " - sock_map: Add a cond_resched() in sock_hash_free()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47711", " - af_unix: Don't return OOB skb in manage_oob().", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47712", " - wifi: wilc1000: fix potential RCU dereference issue in", " wilc_parse_join_bss_param", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47713", " - wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47730", " - crypto: hisilicon/qm - inject error before stopping queue", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49856", " - x86/sgx: Fix deadlock in SGX NUMA node search", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47714", " - wifi: mt76: mt7996: use hweight16 to get correct tx antenna", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47715", " - wifi: mt76: mt7915: fix oops on non-dbdc mt7986", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49857", " - wifi: iwlwifi: mvm: set the cipher for secured NDP ranging", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47738", " - wifi: mac80211: don't use rate mask for offchannel TX either", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47731", " - drivers/perf: Fix ali_drw_pmu driver interrupt status clearing", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49862", " - powercap: intel_rapl: Fix off by one in get_rpi()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47716", " - ARM: 9410/1: vfp: Use asm volatile in fmrx/fmxr macros", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47717", " - RISC-V: KVM: Don't zero-out PMU snapshot area before freeing data", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47721", " - wifi: rtw89: remove unused C2H event ID RTW89_MAC_C2H_FUNC_READ_WOW_CAM to", " prevent out-of-bounds reading", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47732", " - crypto: iaa - Fix potential use after free bug", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47718", " - wifi: rtw88: always wait for both firmware loading attempts", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47724", " - wifi: ath11k: use work queue to process beacon tx event", "", " * Oracular update: v6.11.1 upstream stable release (LP: #2089020)", " - powercap/intel_rapl: Add support for AMD family 1Ah", " - powercap/intel_rapl: Fix the energy-pkg event for AMD CPUs", " - cpufreq/amd-pstate: Add the missing cpufreq_cpu_put()", " - netfilter: nft_socket: Fix a NULL vs IS_ERR() bug in", " nft_socket_cgroup_subtree_level()", " - ASoC: amd: acp: add ZSC control register programming sequence", " - nvme-pci: qdepth 1 quirk", " - USB: serial: pl2303: add device id for Macrosilicon MS3020", " - powercap: intel_rapl: Change an error pointer to NULL", " - Linux 6.11.1", "", " * Oracular update: v6.11.1 upstream stable release (LP: #2089020) //", " CVE-2024-47671", " - USB: usbtmc: prevent kernel-usb-infoleak", "", " * Oracular update: v6.11.1 upstream stable release (LP: #2089020) //", " CVE-2024-46869", " - Bluetooth: btintel_pcie: Allocate memory for driver private data", "", " * CVE-2024-53164", " - net: sched: fix ordering of qlen adjustment", "", " * CVE-2024-53103", " - hv_sock: Initializing vsk->trans to NULL to prevent a dangling pointer", "" ], "package": "linux", "version": "6.11.0-17.17", "urgency": "medium", "distributions": "oracular", "launchpad_bugs_fixed": [ 2093643, 1786013, 2091744, 2091184, 2093146, 2085406, 2089684, 2090932, 2085485, 2089357, 2089306, 2091655, 2091655, 2091655, 2091655, 2091655, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091386, 2091990, 2089327, 2089113, 2086587, 2086606, 2085950, 2085944, 2087853, 2087983, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089020, 2089020, 2089020 ], "author": "Stefan Bader ", "date": "Thu, 16 Jan 2025 22:38:59 +0100" } ], "notes": null }, { "name": "linux-virtual", "from_version": { "source_package_name": "linux-meta", "source_package_version": "6.11.0-14.15", "version": "6.11.0-14.15" }, "to_version": { "source_package_name": "linux-meta", "source_package_version": "6.11.0-18.18", "version": "6.11.0-18.18" }, "cves": [], "launchpad_bugs_fixed": [ 1786013 ], "changes": [ { "cves": [], "log": [ "", " * Main version: 6.11.0-18.18", "" ], "package": "linux-meta", "version": "6.11.0-18.18", "urgency": "medium", "distributions": "oracular", "launchpad_bugs_fixed": [], "author": "Manuel Diewald ", "date": "Fri, 07 Feb 2025 19:18:05 +0100" }, { "cves": [], "log": [ "", " * Main version: 6.11.0-17.17", "" ], "package": "linux-meta", "version": "6.11.0-17.17", "urgency": "medium", "distributions": "oracular", "launchpad_bugs_fixed": [], "author": "Stefan Bader ", "date": "Thu, 16 Jan 2025 23:24:54 +0100" }, { "cves": [], "log": [ "", " * Main version: 6.11.0-16.16", "", " * Packaging resync (LP: #1786013)", " - [Packaging] resync git-ubuntu-log", " - [Packaging] debian/dkms-versions -- resync from main package", "" ], "package": "linux-meta", "version": "6.11.0-16.16", "urgency": "medium", "distributions": "oracular", "launchpad_bugs_fixed": [ 1786013 ], "author": "Stefan Bader ", "date": "Thu, 16 Jan 2025 22:04:50 +0100" } ], "notes": null }, { "name": "locales", "from_version": { "source_package_name": "glibc", "source_package_version": "2.40-1ubuntu3", "version": "2.40-1ubuntu3" }, "to_version": { "source_package_name": "glibc", "source_package_version": "2.40-1ubuntu3.1", "version": "2.40-1ubuntu3.1" }, "cves": [ { "cve": "CVE-2025-0395", "url": "https://ubuntu.com/security/CVE-2025-0395", "cve_description": "When the assert() function in the GNU C Library versions 2.13 to 2.40 fails, it does not allocate enough space for the assertion failure message string and size information, which may lead to a buffer overflow if the message string size aligns to page size.", "cve_priority": "medium", "cve_public_date": "2025-01-22 13:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2025-0395", "url": "https://ubuntu.com/security/CVE-2025-0395", "cve_description": "When the assert() function in the GNU C Library versions 2.13 to 2.40 fails, it does not allocate enough space for the assertion failure message string and size information, which may lead to a buffer overflow if the message string size aligns to page size.", "cve_priority": "medium", "cve_public_date": "2025-01-22 13:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Buffer overflow in the assert function.", " - debian/patches/any/CVE-2025-0395.patch: Change total to ALIGN_UP", " calculation and include libc-pointer-arith.h in assert/assert.c and", " sysdeps/posix/libc_fatal.c.", " - CVE-2025-0395", "" ], "package": "glibc", "version": "2.40-1ubuntu3.1", "urgency": "medium", "distributions": "oracular-security", "launchpad_bugs_fixed": [], "author": "Hlib Korzhynskyy ", "date": "Mon, 27 Jan 2025 15:10:33 -0330" } ], "notes": null }, { "name": "openssh-client", "from_version": { "source_package_name": "openssh", "source_package_version": "1:9.7p1-7ubuntu4.1", "version": "1:9.7p1-7ubuntu4.1" }, "to_version": { "source_package_name": "openssh", "source_package_version": "1:9.7p1-7ubuntu4.2", "version": "1:9.7p1-7ubuntu4.2" }, "cves": [ { "cve": "CVE-2025-26465", "url": "https://ubuntu.com/security/CVE-2025-26465", "cve_description": "A vulnerability was found in OpenSSH when the VerifyHostKeyDNS option is enabled. A machine-in-the-middle attack can be performed by a malicious machine impersonating a legit server. This issue occurs due to how OpenSSH mishandles error codes in specific conditions when verifying the host key. For an attack to be considered successful, the attacker needs to manage to exhaust the client's memory resource first, turning the attack complexity high.", "cve_priority": "medium", "cve_public_date": "2025-02-18 19:15:00 UTC" }, { "cve": "CVE-2025-26466", "url": "https://ubuntu.com/security/CVE-2025-26466", "cve_description": "The OpenSSH client and server are vulnerable to a pre-authentication denial-of-service attack: an asymmetric resource consumption of both memory and CPU. This vulnerability was introduced in August 2023 (shortly before OpenSSH 9.5p1) by commit dce6d80 (\"Introduce a transport-level ping facility\").", "cve_priority": "medium", "cve_public_date": "2025-02-18" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2025-26465", "url": "https://ubuntu.com/security/CVE-2025-26465", "cve_description": "A vulnerability was found in OpenSSH when the VerifyHostKeyDNS option is enabled. A machine-in-the-middle attack can be performed by a malicious machine impersonating a legit server. This issue occurs due to how OpenSSH mishandles error codes in specific conditions when verifying the host key. For an attack to be considered successful, the attacker needs to manage to exhaust the client's memory resource first, turning the attack complexity high.", "cve_priority": "medium", "cve_public_date": "2025-02-18 19:15:00 UTC" }, { "cve": "CVE-2025-26466", "url": "https://ubuntu.com/security/CVE-2025-26466", "cve_description": "The OpenSSH client and server are vulnerable to a pre-authentication denial-of-service attack: an asymmetric resource consumption of both memory and CPU. This vulnerability was introduced in August 2023 (shortly before OpenSSH 9.5p1) by commit dce6d80 (\"Introduce a transport-level ping facility\").", "cve_priority": "medium", "cve_public_date": "2025-02-18" } ], "log": [ "", " * SECURITY UPDATE: MitM with VerifyHostKeyDNS option", " - debian/patches/CVE-2025-26465.patch: fix error code handling in", " krl.c, ssh-agent.c, ssh-sk-client.c, sshconnect2.c, sshsig.c.", " - CVE-2025-26465", " * SECURITY UPDATE: pre-authentication denial of service", " - debian/patches/CVE-2025-26466.patch: don't reply to PING in preauth", " or in KEX in packet.c.", " - CVE-2025-26466", "" ], "package": "openssh", "version": "1:9.7p1-7ubuntu4.2", "urgency": "medium", "distributions": "oracular-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Tue, 11 Feb 2025 08:16:00 -0500" } ], "notes": null }, { "name": "openssh-server", "from_version": { "source_package_name": "openssh", "source_package_version": "1:9.7p1-7ubuntu4.1", "version": "1:9.7p1-7ubuntu4.1" }, "to_version": { "source_package_name": "openssh", "source_package_version": "1:9.7p1-7ubuntu4.2", "version": "1:9.7p1-7ubuntu4.2" }, "cves": [ { "cve": "CVE-2025-26465", "url": "https://ubuntu.com/security/CVE-2025-26465", "cve_description": "A vulnerability was found in OpenSSH when the VerifyHostKeyDNS option is enabled. A machine-in-the-middle attack can be performed by a malicious machine impersonating a legit server. This issue occurs due to how OpenSSH mishandles error codes in specific conditions when verifying the host key. For an attack to be considered successful, the attacker needs to manage to exhaust the client's memory resource first, turning the attack complexity high.", "cve_priority": "medium", "cve_public_date": "2025-02-18 19:15:00 UTC" }, { "cve": "CVE-2025-26466", "url": "https://ubuntu.com/security/CVE-2025-26466", "cve_description": "The OpenSSH client and server are vulnerable to a pre-authentication denial-of-service attack: an asymmetric resource consumption of both memory and CPU. This vulnerability was introduced in August 2023 (shortly before OpenSSH 9.5p1) by commit dce6d80 (\"Introduce a transport-level ping facility\").", "cve_priority": "medium", "cve_public_date": "2025-02-18" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2025-26465", "url": "https://ubuntu.com/security/CVE-2025-26465", "cve_description": "A vulnerability was found in OpenSSH when the VerifyHostKeyDNS option is enabled. A machine-in-the-middle attack can be performed by a malicious machine impersonating a legit server. This issue occurs due to how OpenSSH mishandles error codes in specific conditions when verifying the host key. For an attack to be considered successful, the attacker needs to manage to exhaust the client's memory resource first, turning the attack complexity high.", "cve_priority": "medium", "cve_public_date": "2025-02-18 19:15:00 UTC" }, { "cve": "CVE-2025-26466", "url": "https://ubuntu.com/security/CVE-2025-26466", "cve_description": "The OpenSSH client and server are vulnerable to a pre-authentication denial-of-service attack: an asymmetric resource consumption of both memory and CPU. This vulnerability was introduced in August 2023 (shortly before OpenSSH 9.5p1) by commit dce6d80 (\"Introduce a transport-level ping facility\").", "cve_priority": "medium", "cve_public_date": "2025-02-18" } ], "log": [ "", " * SECURITY UPDATE: MitM with VerifyHostKeyDNS option", " - debian/patches/CVE-2025-26465.patch: fix error code handling in", " krl.c, ssh-agent.c, ssh-sk-client.c, sshconnect2.c, sshsig.c.", " - CVE-2025-26465", " * SECURITY UPDATE: pre-authentication denial of service", " - debian/patches/CVE-2025-26466.patch: don't reply to PING in preauth", " or in KEX in packet.c.", " - CVE-2025-26466", "" ], "package": "openssh", "version": "1:9.7p1-7ubuntu4.2", "urgency": "medium", "distributions": "oracular-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Tue, 11 Feb 2025 08:16:00 -0500" } ], "notes": null }, { "name": "openssh-sftp-server", "from_version": { "source_package_name": "openssh", "source_package_version": "1:9.7p1-7ubuntu4.1", "version": "1:9.7p1-7ubuntu4.1" }, "to_version": { "source_package_name": "openssh", "source_package_version": "1:9.7p1-7ubuntu4.2", "version": "1:9.7p1-7ubuntu4.2" }, "cves": [ { "cve": "CVE-2025-26465", "url": "https://ubuntu.com/security/CVE-2025-26465", "cve_description": "A vulnerability was found in OpenSSH when the VerifyHostKeyDNS option is enabled. A machine-in-the-middle attack can be performed by a malicious machine impersonating a legit server. This issue occurs due to how OpenSSH mishandles error codes in specific conditions when verifying the host key. For an attack to be considered successful, the attacker needs to manage to exhaust the client's memory resource first, turning the attack complexity high.", "cve_priority": "medium", "cve_public_date": "2025-02-18 19:15:00 UTC" }, { "cve": "CVE-2025-26466", "url": "https://ubuntu.com/security/CVE-2025-26466", "cve_description": "The OpenSSH client and server are vulnerable to a pre-authentication denial-of-service attack: an asymmetric resource consumption of both memory and CPU. This vulnerability was introduced in August 2023 (shortly before OpenSSH 9.5p1) by commit dce6d80 (\"Introduce a transport-level ping facility\").", "cve_priority": "medium", "cve_public_date": "2025-02-18" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2025-26465", "url": "https://ubuntu.com/security/CVE-2025-26465", "cve_description": "A vulnerability was found in OpenSSH when the VerifyHostKeyDNS option is enabled. A machine-in-the-middle attack can be performed by a malicious machine impersonating a legit server. This issue occurs due to how OpenSSH mishandles error codes in specific conditions when verifying the host key. For an attack to be considered successful, the attacker needs to manage to exhaust the client's memory resource first, turning the attack complexity high.", "cve_priority": "medium", "cve_public_date": "2025-02-18 19:15:00 UTC" }, { "cve": "CVE-2025-26466", "url": "https://ubuntu.com/security/CVE-2025-26466", "cve_description": "The OpenSSH client and server are vulnerable to a pre-authentication denial-of-service attack: an asymmetric resource consumption of both memory and CPU. This vulnerability was introduced in August 2023 (shortly before OpenSSH 9.5p1) by commit dce6d80 (\"Introduce a transport-level ping facility\").", "cve_priority": "medium", "cve_public_date": "2025-02-18" } ], "log": [ "", " * SECURITY UPDATE: MitM with VerifyHostKeyDNS option", " - debian/patches/CVE-2025-26465.patch: fix error code handling in", " krl.c, ssh-agent.c, ssh-sk-client.c, sshconnect2.c, sshsig.c.", " - CVE-2025-26465", " * SECURITY UPDATE: pre-authentication denial of service", " - debian/patches/CVE-2025-26466.patch: don't reply to PING in preauth", " or in KEX in packet.c.", " - CVE-2025-26466", "" ], "package": "openssh", "version": "1:9.7p1-7ubuntu4.2", "urgency": "medium", "distributions": "oracular-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Tue, 11 Feb 2025 08:16:00 -0500" } ], "notes": null }, { "name": "openssl", "from_version": { "source_package_name": "openssl", "source_package_version": "3.3.1-2ubuntu2", "version": "3.3.1-2ubuntu2" }, "to_version": { "source_package_name": "openssl", "source_package_version": "3.3.1-2ubuntu2.1", "version": "3.3.1-2ubuntu2.1" }, "cves": [ { "cve": "CVE-2024-9143", "url": "https://ubuntu.com/security/CVE-2024-9143", "cve_description": "Issue summary: Use of the low-level GF(2^m) elliptic curve APIs with untrusted explicit values for the field polynomial can lead to out-of-bounds memory reads or writes. Impact summary: Out of bound memory writes can lead to an application crash or even a possibility of a remote code execution, however, in all the protocols involving Elliptic Curve Cryptography that we're aware of, either only \"named curves\" are supported, or, if explicit curve parameters are supported, they specify an X9.62 encoding of binary (GF(2^m)) curves that can't represent problematic input values. Thus the likelihood of existence of a vulnerable application is low. In particular, the X9.62 encoding is used for ECC keys in X.509 certificates, so problematic inputs cannot occur in the context of processing X.509 certificates. Any problematic use-cases would have to be using an \"exotic\" curve encoding. The affected APIs include: EC_GROUP_new_curve_GF2m(), EC_GROUP_new_from_params(), and various supporting BN_GF2m_*() functions. Applications working with \"exotic\" explicit binary (GF(2^m)) curve parameters, that make it possible to represent invalid field polynomials with a zero constant term, via the above or similar APIs, may terminate abruptly as a result of reading or writing outside of array bounds. Remote code execution cannot easily be ruled out. The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.", "cve_priority": "low", "cve_public_date": "2024-10-16 17:15:00 UTC" }, { "cve": "CVE-2024-13176", "url": "https://ubuntu.com/security/CVE-2024-13176", "cve_description": "Issue summary: A timing side-channel which could potentially allow recovering the private key exists in the ECDSA signature computation. Impact summary: A timing side-channel in ECDSA signature computations could allow recovering the private key by an attacker. However, measuring the timing would require either local access to the signing application or a very fast network connection with low latency. There is a timing signal of around 300 nanoseconds when the top word of the inverted ECDSA nonce value is zero. This can happen with significant probability only for some of the supported elliptic curves. In particular the NIST P-521 curve is affected. To be able to measure this leak, the attacker process must either be located in the same physical computer or must have a very fast network connection with low latency. For that reason the severity of this vulnerability is Low.", "cve_priority": "low", "cve_public_date": "2025-01-20 14:15:00 UTC" }, { "cve": "CVE-2024-12797", "url": "https://ubuntu.com/security/CVE-2024-12797", "cve_description": "Issue summary: Clients using RFC7250 Raw Public Keys (RPKs) to authenticate a server may fail to notice that the server was not authenticated, because handshakes don't abort as expected when the SSL_VERIFY_PEER verification mode is set. Impact summary: TLS and DTLS connections using raw public keys may be vulnerable to man-in-middle attacks when server authentication failure is not detected by clients. RPKs are disabled by default in both TLS clients and TLS servers. The issue only arises when TLS clients explicitly enable RPK use by the server, and the server, likewise, enables sending of an RPK instead of an X.509 certificate chain. The affected clients are those that then rely on the handshake to fail when the server's RPK fails to match one of the expected public keys, by setting the verification mode to SSL_VERIFY_PEER. Clients that enable server-side raw public keys can still find out that raw public key verification failed by calling SSL_get_verify_result(), and those that do, and take appropriate action, are not affected. This issue was introduced in the initial implementation of RPK support in OpenSSL 3.2. The FIPS modules in 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.", "cve_priority": "high", "cve_public_date": "2025-02-11 16:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2024-9143", "url": "https://ubuntu.com/security/CVE-2024-9143", "cve_description": "Issue summary: Use of the low-level GF(2^m) elliptic curve APIs with untrusted explicit values for the field polynomial can lead to out-of-bounds memory reads or writes. Impact summary: Out of bound memory writes can lead to an application crash or even a possibility of a remote code execution, however, in all the protocols involving Elliptic Curve Cryptography that we're aware of, either only \"named curves\" are supported, or, if explicit curve parameters are supported, they specify an X9.62 encoding of binary (GF(2^m)) curves that can't represent problematic input values. Thus the likelihood of existence of a vulnerable application is low. In particular, the X9.62 encoding is used for ECC keys in X.509 certificates, so problematic inputs cannot occur in the context of processing X.509 certificates. Any problematic use-cases would have to be using an \"exotic\" curve encoding. The affected APIs include: EC_GROUP_new_curve_GF2m(), EC_GROUP_new_from_params(), and various supporting BN_GF2m_*() functions. Applications working with \"exotic\" explicit binary (GF(2^m)) curve parameters, that make it possible to represent invalid field polynomials with a zero constant term, via the above or similar APIs, may terminate abruptly as a result of reading or writing outside of array bounds. Remote code execution cannot easily be ruled out. The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.", "cve_priority": "low", "cve_public_date": "2024-10-16 17:15:00 UTC" }, { "cve": "CVE-2024-13176", "url": "https://ubuntu.com/security/CVE-2024-13176", "cve_description": "Issue summary: A timing side-channel which could potentially allow recovering the private key exists in the ECDSA signature computation. Impact summary: A timing side-channel in ECDSA signature computations could allow recovering the private key by an attacker. However, measuring the timing would require either local access to the signing application or a very fast network connection with low latency. There is a timing signal of around 300 nanoseconds when the top word of the inverted ECDSA nonce value is zero. This can happen with significant probability only for some of the supported elliptic curves. In particular the NIST P-521 curve is affected. To be able to measure this leak, the attacker process must either be located in the same physical computer or must have a very fast network connection with low latency. For that reason the severity of this vulnerability is Low.", "cve_priority": "low", "cve_public_date": "2025-01-20 14:15:00 UTC" }, { "cve": "CVE-2024-12797", "url": "https://ubuntu.com/security/CVE-2024-12797", "cve_description": "Issue summary: Clients using RFC7250 Raw Public Keys (RPKs) to authenticate a server may fail to notice that the server was not authenticated, because handshakes don't abort as expected when the SSL_VERIFY_PEER verification mode is set. Impact summary: TLS and DTLS connections using raw public keys may be vulnerable to man-in-middle attacks when server authentication failure is not detected by clients. RPKs are disabled by default in both TLS clients and TLS servers. The issue only arises when TLS clients explicitly enable RPK use by the server, and the server, likewise, enables sending of an RPK instead of an X.509 certificate chain. The affected clients are those that then rely on the handshake to fail when the server's RPK fails to match one of the expected public keys, by setting the verification mode to SSL_VERIFY_PEER. Clients that enable server-side raw public keys can still find out that raw public key verification failed by calling SSL_get_verify_result(), and those that do, and take appropriate action, are not affected. This issue was introduced in the initial implementation of RPK support in OpenSSL 3.2. The FIPS modules in 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.", "cve_priority": "high", "cve_public_date": "2025-02-11 16:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Low-level invalid GF(2^m) parameters lead to OOB", " memory access", " - debian/patches/CVE-2024-9143.patch: harden BN_GF2m_poly2arr against", " misuse in crypto/bn/bn_gf2m.c, test/ec_internal_test.c.", " - CVE-2024-9143", " * SECURITY UPDATE: A timing side-channel which could potentially allow", " recovering the private key exists in the ECDSA signature computation", " - debian/patches/CVE-2024-13176.patch: Fix timing side-channel in", " ECDSA signature computation in crypto/bn/bn_exp.c,", " crypto/ec/ec_lib.c, include/crypto/bn.h.", " - CVE-2024-13176", " * SECURITY UPDATE: RFC7250 handshakes with unauthenticated servers don't", " abort as expected", " - debian/patches/CVE-2024-12797-1.patch: with SSL_VERIFY_PEER client", " RPK should abort on X509 error in ssl/statem/statem_clnt.c,", " test/rpktest.c.", " - debian/patches/CVE-2024-12797-2.patch: use ERR marks also when", " verifying server X.509 certs in ssl/statem/statem_clnt.c,", " test/rpktest.c.", " - CVE-2024-12797", " * debian/patches/issue26466.patch: restore correct registers in aarch64", " AES-CTR code in crypto/aes/asm/aesv8-armx.pl.", "" ], "package": "openssl", "version": "3.3.1-2ubuntu2.1", "urgency": "medium", "distributions": "oracular-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Wed, 05 Feb 2025 07:56:37 -0500" } ], "notes": null }, { "name": "python3-jinja2", "from_version": { "source_package_name": "jinja2", "source_package_version": "3.1.3-1ubuntu1", "version": "3.1.3-1ubuntu1" }, "to_version": { "source_package_name": "jinja2", "source_package_version": "3.1.3-1ubuntu1.24.10.1", "version": "3.1.3-1ubuntu1.24.10.1" }, "cves": [ { "cve": "CVE-2024-56201", "url": "https://ubuntu.com/security/CVE-2024-56201", "cve_description": "Jinja is an extensible templating engine. In versions on the 3.x branch prior to 3.1.5, a bug in the Jinja compiler allows an attacker that controls both the content and filename of a template to execute arbitrary Python code, regardless of if Jinja's sandbox is used. To exploit the vulnerability, an attacker needs to control both the filename and the contents of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates where the template author can also choose the template filename. This vulnerability is fixed in 3.1.5.", "cve_priority": "medium", "cve_public_date": "2024-12-23 16:15:00 UTC" }, { "cve": "CVE-2024-56326", "url": "https://ubuntu.com/security/CVE-2024-56326", "cve_description": "Jinja is an extensible templating engine. Prior to 3.1.5, An oversight in how the Jinja sandboxed environment detects calls to str.format allows an attacker that controls the content of a template to execute arbitrary Python code. To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates. Jinja's sandbox does catch calls to str.format and ensures they don't escape the sandbox. However, it's possible to store a reference to a malicious string's format method, then pass that to a filter that calls it. No such filters are built-in to Jinja, but could be present through custom filters in an application. After the fix, such indirect calls are also handled by the sandbox. This vulnerability is fixed in 3.1.5.", "cve_priority": "medium", "cve_public_date": "2024-12-23 16:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2024-56201", "url": "https://ubuntu.com/security/CVE-2024-56201", "cve_description": "Jinja is an extensible templating engine. In versions on the 3.x branch prior to 3.1.5, a bug in the Jinja compiler allows an attacker that controls both the content and filename of a template to execute arbitrary Python code, regardless of if Jinja's sandbox is used. To exploit the vulnerability, an attacker needs to control both the filename and the contents of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates where the template author can also choose the template filename. This vulnerability is fixed in 3.1.5.", "cve_priority": "medium", "cve_public_date": "2024-12-23 16:15:00 UTC" }, { "cve": "CVE-2024-56326", "url": "https://ubuntu.com/security/CVE-2024-56326", "cve_description": "Jinja is an extensible templating engine. Prior to 3.1.5, An oversight in how the Jinja sandboxed environment detects calls to str.format allows an attacker that controls the content of a template to execute arbitrary Python code. To exploit the vulnerability, an attacker needs to control the content of a template. Whether that is the case depends on the type of application using Jinja. This vulnerability impacts users of applications which execute untrusted templates. Jinja's sandbox does catch calls to str.format and ensures they don't escape the sandbox. However, it's possible to store a reference to a malicious string's format method, then pass that to a filter that calls it. No such filters are built-in to Jinja, but could be present through custom filters in an application. After the fix, such indirect calls are also handled by the sandbox. This vulnerability is fixed in 3.1.5.", "cve_priority": "medium", "cve_public_date": "2024-12-23 16:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: arbitrary code execution issue in jinja compiler", " - debian/patches/CVE-2024-56201.patch: f-string syntax handling in code", " generation improved in src/jinja2/compiler.py.", " - debian/patches/CVE-2024-56326.patch: oversight on calls to str.format", " adjusted in src/jinja2/sandbox.py.", " - CVE-2024-56201", " - CVE-2024-56326", "" ], "package": "jinja2", "version": "3.1.3-1ubuntu1.24.10.1", "urgency": "medium", "distributions": "oracular-security", "launchpad_bugs_fixed": [], "author": "Evan Caville ", "date": "Tue, 21 Jan 2025 09:00:26 +1000" } ], "notes": null }, { "name": "python3.12", "from_version": { "source_package_name": "python3.12", "source_package_version": "3.12.7-1ubuntu1.1", "version": "3.12.7-1ubuntu1.1" }, "to_version": { "source_package_name": "python3.12", "source_package_version": "3.12.7-1ubuntu2", "version": "3.12.7-1ubuntu2" }, "cves": [ { "cve": "CVE-2025-0938", "url": "https://ubuntu.com/security/CVE-2025-0938", "cve_description": "The Python standard library functions `urllib.parse.urlsplit` and `urlparse` accepted domain names that included square brackets which isn't valid according to RFC 3986. Square brackets are only meant to be used as delimiters for specifying IPv6 and IPvFuture hosts in URLs. This could result in differential parsing across the Python URL parser and other specification-compliant URL parsers.", "cve_priority": "medium", "cve_public_date": "2025-01-31 18:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2025-0938", "url": "https://ubuntu.com/security/CVE-2025-0938", "cve_description": "The Python standard library functions `urllib.parse.urlsplit` and `urlparse` accepted domain names that included square brackets which isn't valid according to RFC 3986. Square brackets are only meant to be used as delimiters for specifying IPv6 and IPvFuture hosts in URLs. This could result in differential parsing across the Python URL parser and other specification-compliant URL parsers.", "cve_priority": "medium", "cve_public_date": "2025-01-31 18:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: urlparse does not flag hostname with square brackets", " as incorrect", " - debian/patches/CVE-2025-0938.patch: disallow square brackets in", " domain names for parsed URLs in Lib/test/test_urlparse.py,", " Lib/urllib/parse.py.", " - CVE-2025-0938", "" ], "package": "python3.12", "version": "3.12.7-1ubuntu2", "urgency": "medium", "distributions": "oracular-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Tue, 04 Feb 2025 09:46:03 -0500" } ], "notes": null }, { "name": "python3.12-gdbm", "from_version": { "source_package_name": "python3.12", "source_package_version": "3.12.7-1ubuntu1.1", "version": "3.12.7-1ubuntu1.1" }, "to_version": { "source_package_name": "python3.12", "source_package_version": "3.12.7-1ubuntu2", "version": "3.12.7-1ubuntu2" }, "cves": [ { "cve": "CVE-2025-0938", "url": "https://ubuntu.com/security/CVE-2025-0938", "cve_description": "The Python standard library functions `urllib.parse.urlsplit` and `urlparse` accepted domain names that included square brackets which isn't valid according to RFC 3986. Square brackets are only meant to be used as delimiters for specifying IPv6 and IPvFuture hosts in URLs. This could result in differential parsing across the Python URL parser and other specification-compliant URL parsers.", "cve_priority": "medium", "cve_public_date": "2025-01-31 18:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2025-0938", "url": "https://ubuntu.com/security/CVE-2025-0938", "cve_description": "The Python standard library functions `urllib.parse.urlsplit` and `urlparse` accepted domain names that included square brackets which isn't valid according to RFC 3986. Square brackets are only meant to be used as delimiters for specifying IPv6 and IPvFuture hosts in URLs. This could result in differential parsing across the Python URL parser and other specification-compliant URL parsers.", "cve_priority": "medium", "cve_public_date": "2025-01-31 18:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: urlparse does not flag hostname with square brackets", " as incorrect", " - debian/patches/CVE-2025-0938.patch: disallow square brackets in", " domain names for parsed URLs in Lib/test/test_urlparse.py,", " Lib/urllib/parse.py.", " - CVE-2025-0938", "" ], "package": "python3.12", "version": "3.12.7-1ubuntu2", "urgency": "medium", "distributions": "oracular-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Tue, 04 Feb 2025 09:46:03 -0500" } ], "notes": null }, { "name": "python3.12-minimal", "from_version": { "source_package_name": "python3.12", "source_package_version": "3.12.7-1ubuntu1.1", "version": "3.12.7-1ubuntu1.1" }, "to_version": { "source_package_name": "python3.12", "source_package_version": "3.12.7-1ubuntu2", "version": "3.12.7-1ubuntu2" }, "cves": [ { "cve": "CVE-2025-0938", "url": "https://ubuntu.com/security/CVE-2025-0938", "cve_description": "The Python standard library functions `urllib.parse.urlsplit` and `urlparse` accepted domain names that included square brackets which isn't valid according to RFC 3986. Square brackets are only meant to be used as delimiters for specifying IPv6 and IPvFuture hosts in URLs. This could result in differential parsing across the Python URL parser and other specification-compliant URL parsers.", "cve_priority": "medium", "cve_public_date": "2025-01-31 18:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2025-0938", "url": "https://ubuntu.com/security/CVE-2025-0938", "cve_description": "The Python standard library functions `urllib.parse.urlsplit` and `urlparse` accepted domain names that included square brackets which isn't valid according to RFC 3986. Square brackets are only meant to be used as delimiters for specifying IPv6 and IPvFuture hosts in URLs. This could result in differential parsing across the Python URL parser and other specification-compliant URL parsers.", "cve_priority": "medium", "cve_public_date": "2025-01-31 18:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: urlparse does not flag hostname with square brackets", " as incorrect", " - debian/patches/CVE-2025-0938.patch: disallow square brackets in", " domain names for parsed URLs in Lib/test/test_urlparse.py,", " Lib/urllib/parse.py.", " - CVE-2025-0938", "" ], "package": "python3.12", "version": "3.12.7-1ubuntu2", "urgency": "medium", "distributions": "oracular-security", "launchpad_bugs_fixed": [], "author": "Marc Deslauriers ", "date": "Tue, 04 Feb 2025 09:46:03 -0500" } ], "notes": null }, { "name": "rsync", "from_version": { "source_package_name": "rsync", "source_package_version": "3.3.0-1ubuntu0.1", "version": "3.3.0-1ubuntu0.1" }, "to_version": { "source_package_name": "rsync", "source_package_version": "3.3.0-1ubuntu0.2", "version": "3.3.0-1ubuntu0.2" }, "cves": [], "launchpad_bugs_fixed": [ 2096914 ], "changes": [ { "cves": [], "log": [ "", " * SECURITY REGRESSION: missing ipv6 support (LP: #2096914)", " - d/p/fix_failing_ipv6_check_while_build.patch: fix main return type", " to int which caused configure to fail", "" ], "package": "rsync", "version": "3.3.0-1ubuntu0.2", "urgency": "medium", "distributions": "oracular-security", "launchpad_bugs_fixed": [ 2096914 ], "author": "Sudhakar Verma ", "date": "Sat, 08 Feb 2025 11:14:20 +0530" } ], "notes": null }, { "name": "tzdata", "from_version": { "source_package_name": "tzdata", "source_package_version": "2024a-4ubuntu1", "version": "2024a-4ubuntu1" }, "to_version": { "source_package_name": "tzdata", "source_package_version": "2024b-1ubuntu2.2", "version": "2024b-1ubuntu2.2" }, "cves": [], "launchpad_bugs_fixed": [ 2096974, 2070285, 2079966 ], "changes": [ { "cves": [], "log": [ "", " * Revert using %z in tzdata.zi data form (LP: #2096974):", " - Enable link to link feature also for rearguard dataform", " - Use dataform rearguard for C++ std::chrono", " - Add chrono autopkgtest to test C++ std::chrono::tzdb parser", "" ], "package": "tzdata", "version": "2024b-1ubuntu2.2", "urgency": "medium", "distributions": "oracular", "launchpad_bugs_fixed": [ 2096974 ], "author": "Benjamin Drung ", "date": "Thu, 30 Jan 2025 20:42:02 +0100" }, { "cves": [], "log": [ "", " * Make remaining legacy timezones selectable in debconf (LP: #2070285)", "" ], "package": "tzdata", "version": "2024b-1ubuntu2.1", "urgency": "medium", "distributions": "oracular", "launchpad_bugs_fixed": [ 2070285 ], "author": "Benjamin Drung ", "date": "Tue, 03 Dec 2024 22:34:58 +0100" }, { "cves": [], "log": [ "", " [ Aurelien Jarno ]", " * Build timezones with zic -b 'fat' (Closes: #1084111)", " * tzdata-legacy: bump Replaces: tzdata version to handle the", " Asia/Choibalsan move", "", " [ Benjamin Drung ]", " * Move UNIX System V zones back from backzone to backwards file", " to keep them unchanged for the stable release updates.", "" ], "package": "tzdata", "version": "2024b-1ubuntu2", "urgency": "medium", "distributions": "oracular", "launchpad_bugs_fixed": [], "author": "Benjamin Drung ", "date": "Tue, 08 Oct 2024 16:52:58 +0200" }, { "cves": [], "log": [ "", " * Merge with Debian unstable. Remaining changes:", " - Ship ICU timezone data which are utilized by PHP in tzdata-icu", " - Add autopkgtest test case for ICU timezone data", " - Do not rename NEWS into changelog.gz, this fixes a build failure on", " moment-timezone.js", " - Point Vcs-Browser/Git to Launchpad", " * Update the ICU timezone data to 2024b", " * Add autopkgtest test case for ICU timezone data 2024b", "" ], "package": "tzdata", "version": "2024b-1ubuntu1", "urgency": "medium", "distributions": "oracular", "launchpad_bugs_fixed": [], "author": "Benjamin Drung ", "date": "Wed, 02 Oct 2024 18:55:59 +0200" }, { "cves": [], "log": [ "", " * New upstream release (LP: #2079966):", " - Improve historical data for Mexico, Mongolia, and Portugal.", " - System V names are now obsolescent.", " - The main data form now uses %z.", " - Asia/Choibalsan is now an alias for Asia/Ulaanbaatar", " * Add autopkgtest test case for 2024b release", " * Update Asia/Choibalsan to Asia/Ulaanbaatar on upgrade and move", " Asia/Choibalsan to tzdata-legacy", " * Bump Standards-Version to 4.7.0", " * generate_debconf_templates: Work around AttributeError on icu import", "" ], "package": "tzdata", "version": "2024b-1", "urgency": "medium", "distributions": "unstable", "launchpad_bugs_fixed": [ 2079966 ], "author": "Benjamin Drung ", "date": "Wed, 02 Oct 2024 18:42:23 +0200" } ], "notes": null }, { "name": "vim", "from_version": { "source_package_name": "vim", "source_package_version": "2:9.1.0496-1ubuntu6.3", "version": "2:9.1.0496-1ubuntu6.3" }, "to_version": { "source_package_name": "vim", "source_package_version": "2:9.1.0496-1ubuntu6.4", "version": "2:9.1.0496-1ubuntu6.4" }, "cves": [ { "cve": "CVE-2025-24014", "url": "https://ubuntu.com/security/CVE-2025-24014", "cve_description": "Vim is an open source, command line text editor. A segmentation fault was found in Vim before 9.1.1043. In silent Ex mode (-s -e), Vim typically doesn't show a screen and just operates silently in batch mode. However, it is still possible to trigger the function that handles the scrolling of a gui version of Vim by feeding some binary characters to Vim. The function that handles the scrolling however may be triggering a redraw, which will access the ScreenLines pointer, even so this variable hasn't been allocated (since there is no screen). This vulnerability is fixed in 9.1.1043.", "cve_priority": "medium", "cve_public_date": "2025-01-20 23:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2025-24014", "url": "https://ubuntu.com/security/CVE-2025-24014", "cve_description": "Vim is an open source, command line text editor. A segmentation fault was found in Vim before 9.1.1043. In silent Ex mode (-s -e), Vim typically doesn't show a screen and just operates silently in batch mode. However, it is still possible to trigger the function that handles the scrolling of a gui version of Vim by feeding some binary characters to Vim. The function that handles the scrolling however may be triggering a redraw, which will access the ScreenLines pointer, even so this variable hasn't been allocated (since there is no screen). This vulnerability is fixed in 9.1.1043.", "cve_priority": "medium", "cve_public_date": "2025-01-20 23:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Denial of service", " - debian/patches/CVE-2025-24014.patch: fix a segfault in win_line()", " in files src/gui.c, src/testdir/crash/ex_redraw_crash,", " src/testdir/test_crash.vim.", " - CVE-2025-24014", "" ], "package": "vim", "version": "2:9.1.0496-1ubuntu6.4", "urgency": "medium", "distributions": "oracular-security", "launchpad_bugs_fixed": [], "author": "Leonidas Da Silva Barbosa ", "date": "Fri, 31 Jan 2025 13:03:26 -0300" } ], "notes": null }, { "name": "vim-common", "from_version": { "source_package_name": "vim", "source_package_version": "2:9.1.0496-1ubuntu6.3", "version": "2:9.1.0496-1ubuntu6.3" }, "to_version": { "source_package_name": "vim", "source_package_version": "2:9.1.0496-1ubuntu6.4", "version": "2:9.1.0496-1ubuntu6.4" }, "cves": [ { "cve": "CVE-2025-24014", "url": "https://ubuntu.com/security/CVE-2025-24014", "cve_description": "Vim is an open source, command line text editor. A segmentation fault was found in Vim before 9.1.1043. In silent Ex mode (-s -e), Vim typically doesn't show a screen and just operates silently in batch mode. However, it is still possible to trigger the function that handles the scrolling of a gui version of Vim by feeding some binary characters to Vim. The function that handles the scrolling however may be triggering a redraw, which will access the ScreenLines pointer, even so this variable hasn't been allocated (since there is no screen). This vulnerability is fixed in 9.1.1043.", "cve_priority": "medium", "cve_public_date": "2025-01-20 23:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2025-24014", "url": "https://ubuntu.com/security/CVE-2025-24014", "cve_description": "Vim is an open source, command line text editor. A segmentation fault was found in Vim before 9.1.1043. In silent Ex mode (-s -e), Vim typically doesn't show a screen and just operates silently in batch mode. However, it is still possible to trigger the function that handles the scrolling of a gui version of Vim by feeding some binary characters to Vim. The function that handles the scrolling however may be triggering a redraw, which will access the ScreenLines pointer, even so this variable hasn't been allocated (since there is no screen). This vulnerability is fixed in 9.1.1043.", "cve_priority": "medium", "cve_public_date": "2025-01-20 23:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Denial of service", " - debian/patches/CVE-2025-24014.patch: fix a segfault in win_line()", " in files src/gui.c, src/testdir/crash/ex_redraw_crash,", " src/testdir/test_crash.vim.", " - CVE-2025-24014", "" ], "package": "vim", "version": "2:9.1.0496-1ubuntu6.4", "urgency": "medium", "distributions": "oracular-security", "launchpad_bugs_fixed": [], "author": "Leonidas Da Silva Barbosa ", "date": "Fri, 31 Jan 2025 13:03:26 -0300" } ], "notes": null }, { "name": "vim-runtime", "from_version": { "source_package_name": "vim", "source_package_version": "2:9.1.0496-1ubuntu6.3", "version": "2:9.1.0496-1ubuntu6.3" }, "to_version": { "source_package_name": "vim", "source_package_version": "2:9.1.0496-1ubuntu6.4", "version": "2:9.1.0496-1ubuntu6.4" }, "cves": [ { "cve": "CVE-2025-24014", "url": "https://ubuntu.com/security/CVE-2025-24014", "cve_description": "Vim is an open source, command line text editor. A segmentation fault was found in Vim before 9.1.1043. In silent Ex mode (-s -e), Vim typically doesn't show a screen and just operates silently in batch mode. However, it is still possible to trigger the function that handles the scrolling of a gui version of Vim by feeding some binary characters to Vim. The function that handles the scrolling however may be triggering a redraw, which will access the ScreenLines pointer, even so this variable hasn't been allocated (since there is no screen). This vulnerability is fixed in 9.1.1043.", "cve_priority": "medium", "cve_public_date": "2025-01-20 23:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2025-24014", "url": "https://ubuntu.com/security/CVE-2025-24014", "cve_description": "Vim is an open source, command line text editor. A segmentation fault was found in Vim before 9.1.1043. In silent Ex mode (-s -e), Vim typically doesn't show a screen and just operates silently in batch mode. However, it is still possible to trigger the function that handles the scrolling of a gui version of Vim by feeding some binary characters to Vim. The function that handles the scrolling however may be triggering a redraw, which will access the ScreenLines pointer, even so this variable hasn't been allocated (since there is no screen). This vulnerability is fixed in 9.1.1043.", "cve_priority": "medium", "cve_public_date": "2025-01-20 23:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Denial of service", " - debian/patches/CVE-2025-24014.patch: fix a segfault in win_line()", " in files src/gui.c, src/testdir/crash/ex_redraw_crash,", " src/testdir/test_crash.vim.", " - CVE-2025-24014", "" ], "package": "vim", "version": "2:9.1.0496-1ubuntu6.4", "urgency": "medium", "distributions": "oracular-security", "launchpad_bugs_fixed": [], "author": "Leonidas Da Silva Barbosa ", "date": "Fri, 31 Jan 2025 13:03:26 -0300" } ], "notes": null }, { "name": "vim-tiny", "from_version": { "source_package_name": "vim", "source_package_version": "2:9.1.0496-1ubuntu6.3", "version": "2:9.1.0496-1ubuntu6.3" }, "to_version": { "source_package_name": "vim", "source_package_version": "2:9.1.0496-1ubuntu6.4", "version": "2:9.1.0496-1ubuntu6.4" }, "cves": [ { "cve": "CVE-2025-24014", "url": "https://ubuntu.com/security/CVE-2025-24014", "cve_description": "Vim is an open source, command line text editor. A segmentation fault was found in Vim before 9.1.1043. In silent Ex mode (-s -e), Vim typically doesn't show a screen and just operates silently in batch mode. However, it is still possible to trigger the function that handles the scrolling of a gui version of Vim by feeding some binary characters to Vim. The function that handles the scrolling however may be triggering a redraw, which will access the ScreenLines pointer, even so this variable hasn't been allocated (since there is no screen). This vulnerability is fixed in 9.1.1043.", "cve_priority": "medium", "cve_public_date": "2025-01-20 23:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2025-24014", "url": "https://ubuntu.com/security/CVE-2025-24014", "cve_description": "Vim is an open source, command line text editor. A segmentation fault was found in Vim before 9.1.1043. In silent Ex mode (-s -e), Vim typically doesn't show a screen and just operates silently in batch mode. However, it is still possible to trigger the function that handles the scrolling of a gui version of Vim by feeding some binary characters to Vim. The function that handles the scrolling however may be triggering a redraw, which will access the ScreenLines pointer, even so this variable hasn't been allocated (since there is no screen). This vulnerability is fixed in 9.1.1043.", "cve_priority": "medium", "cve_public_date": "2025-01-20 23:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Denial of service", " - debian/patches/CVE-2025-24014.patch: fix a segfault in win_line()", " in files src/gui.c, src/testdir/crash/ex_redraw_crash,", " src/testdir/test_crash.vim.", " - CVE-2025-24014", "" ], "package": "vim", "version": "2:9.1.0496-1ubuntu6.4", "urgency": "medium", "distributions": "oracular-security", "launchpad_bugs_fixed": [], "author": "Leonidas Da Silva Barbosa ", "date": "Fri, 31 Jan 2025 13:03:26 -0300" } ], "notes": null }, { "name": "xxd", "from_version": { "source_package_name": "vim", "source_package_version": "2:9.1.0496-1ubuntu6.3", "version": "2:9.1.0496-1ubuntu6.3" }, "to_version": { "source_package_name": "vim", "source_package_version": "2:9.1.0496-1ubuntu6.4", "version": "2:9.1.0496-1ubuntu6.4" }, "cves": [ { "cve": "CVE-2025-24014", "url": "https://ubuntu.com/security/CVE-2025-24014", "cve_description": "Vim is an open source, command line text editor. A segmentation fault was found in Vim before 9.1.1043. In silent Ex mode (-s -e), Vim typically doesn't show a screen and just operates silently in batch mode. However, it is still possible to trigger the function that handles the scrolling of a gui version of Vim by feeding some binary characters to Vim. The function that handles the scrolling however may be triggering a redraw, which will access the ScreenLines pointer, even so this variable hasn't been allocated (since there is no screen). This vulnerability is fixed in 9.1.1043.", "cve_priority": "medium", "cve_public_date": "2025-01-20 23:15:00 UTC" } ], "launchpad_bugs_fixed": [], "changes": [ { "cves": [ { "cve": "CVE-2025-24014", "url": "https://ubuntu.com/security/CVE-2025-24014", "cve_description": "Vim is an open source, command line text editor. A segmentation fault was found in Vim before 9.1.1043. In silent Ex mode (-s -e), Vim typically doesn't show a screen and just operates silently in batch mode. However, it is still possible to trigger the function that handles the scrolling of a gui version of Vim by feeding some binary characters to Vim. The function that handles the scrolling however may be triggering a redraw, which will access the ScreenLines pointer, even so this variable hasn't been allocated (since there is no screen). This vulnerability is fixed in 9.1.1043.", "cve_priority": "medium", "cve_public_date": "2025-01-20 23:15:00 UTC" } ], "log": [ "", " * SECURITY UPDATE: Denial of service", " - debian/patches/CVE-2025-24014.patch: fix a segfault in win_line()", " in files src/gui.c, src/testdir/crash/ex_redraw_crash,", " src/testdir/test_crash.vim.", " - CVE-2025-24014", "" ], "package": "vim", "version": "2:9.1.0496-1ubuntu6.4", "urgency": "medium", "distributions": "oracular-security", "launchpad_bugs_fixed": [], "author": "Leonidas Da Silva Barbosa ", "date": "Fri, 31 Jan 2025 13:03:26 -0300" } ], "notes": null } ], "snap": [] }, "added": { "deb": [ { "name": "linux-headers-6.11.0-18", "from_version": { "source_package_name": "linux", "source_package_version": "6.11.0-14.15", "version": null }, "to_version": { "source_package_name": "linux", "source_package_version": "6.11.0-18.18", "version": "6.11.0-18.18" }, "cves": [ { "cve": "CVE-2025-0927", "url": "https://ubuntu.com/security/CVE-2025-0927", "cve_description": "[fs: hfs/hfsplus: add key_len boundary check to hfs_bnode_read_key]", "cve_priority": "medium", "cve_public_date": "2025-02-13" }, { "cve": "CVE-2024-53141", "url": "https://ubuntu.com/security/CVE-2024-53141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: add missing range check in bitmap_ip_uadt When tb[IPSET_ATTR_IP_TO] is not present but tb[IPSET_ATTR_CIDR] exists, the values of ip and ip_to are slightly swapped. Therefore, the range check for ip should be done later, but this part is missing and it seems that the vulnerability occurs. So we should add missing range checks and remove unnecessary range checks.", "cve_priority": "medium", "cve_public_date": "2024-12-06 10:15:00 UTC" }, { "cve": "CVE-2024-50010", "url": "https://ubuntu.com/security/CVE-2024-50010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exec: don't WARN for racy path_noexec check Both i_mode and noexec checks wrapped in WARN_ON stem from an artifact of the previous implementation. They used to legitimately check for the condition, but that got moved up in two commits: 633fb6ac3980 (\"exec: move S_ISREG() check earlier\") 0fd338b2d2cd (\"exec: move path_noexec() check earlier\") Instead of being removed said checks are WARN_ON'ed instead, which has some debug value. However, the spurious path_noexec check is racy, resulting in unwarranted warnings should someone race with setting the noexec flag. One can note there is more to perm-checking whether execve is allowed and none of the conditions are guaranteed to still hold after they were tested for. Additionally this does not validate whether the code path did any perm checking to begin with -- it will pass if the inode happens to be regular. Keep the redundant path_noexec() check even though it's mindless nonsense checking for guarantee that isn't given so drop the WARN. Reword the commentary and do small tidy ups while here. [brauner: keep redundant path_noexec() check]", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-53143", "url": "https://ubuntu.com/security/CVE-2024-53143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fsnotify: Fix ordering of iput() and watched_objects decrement Ensure the superblock is kept alive until we're done with iput(). Holding a reference to an inode is not allowed unless we ensure the superblock stays alive, which fsnotify does by keeping the watched_objects count elevated, so iput() must happen before the watched_objects decrement. This can lead to a UAF of something like sb->s_fs_info in tmpfs, but the UAF is hard to hit because race orderings that oops are more likely, thanks to the CHECK_DATA_CORRUPTION() block in generic_shutdown_super(). Also, ensure that fsnotify_put_sb_watched_objects() doesn't call fsnotify_sb_watched_objects() on a superblock that may have already been freed, which would cause a UAF read of sb->s_fsnotify_info.", "cve_priority": "medium", "cve_public_date": "2024-12-07 07:15:00 UTC" }, { "cve": "CVE-2024-53142", "url": "https://ubuntu.com/security/CVE-2024-53142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: initramfs: avoid filename buffer overrun The initramfs filename field is defined in Documentation/driver-api/early-userspace/buffer-format.rst as: 37 cpio_file := ALGN(4) + cpio_header + filename + \"\\0\" + ALGN(4) + data ... 55 ============= ================== ========================= 56 Field name Field size Meaning 57 ============= ================== ========================= ... 70 c_namesize 8 bytes Length of filename, including final \\0 When extracting an initramfs cpio archive, the kernel's do_name() path handler assumes a zero-terminated path at @collected, passing it directly to filp_open() / init_mkdir() / init_mknod(). If a specially crafted cpio entry carries a non-zero-terminated filename and is followed by uninitialized memory, then a file may be created with trailing characters that represent the uninitialized memory. The ability to create an initramfs entry would imply already having full control of the system, so the buffer overrun shouldn't be considered a security vulnerability. Append the output of the following bash script to an existing initramfs and observe any created /initramfs_test_fname_overrunAA* path. E.g. ./reproducer.sh | gzip >> /myinitramfs It's easiest to observe non-zero uninitialized memory when the output is gzipped, as it'll overflow the heap allocated @out_buf in __gunzip(), rather than the initrd_start+initrd_size block. ---- reproducer.sh ---- nilchar=\"A\"\t# change to \"\\0\" to properly zero terminate / pad magic=\"070701\" ino=1 mode=$(( 0100777 )) uid=0 gid=0 nlink=1 mtime=1 filesize=0 devmajor=0 devminor=1 rdevmajor=0 rdevminor=0 csum=0 fname=\"initramfs_test_fname_overrun\" namelen=$(( ${#fname} + 1 ))\t# plus one to account for terminator printf \"%s%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%s\" \\ \t$magic $ino $mode $uid $gid $nlink $mtime $filesize \\ \t$devmajor $devminor $rdevmajor $rdevminor $namelen $csum $fname termpadlen=$(( 1 + ((4 - ((110 + $namelen) & 3)) % 4) )) printf \"%.s${nilchar}\" $(seq 1 $termpadlen) ---- reproducer.sh ---- Symlink filename fields handled in do_symlink() won't overrun past the data segment, due to the explicit zero-termination of the symlink target. Fix filename buffer overrun by aborting the initramfs FSM if any cpio entry doesn't carry a zero-terminator at the expected (name_len - 1) offset.", "cve_priority": "medium", "cve_public_date": "2024-12-06 10:15:00 UTC" }, { "cve": "CVE-2024-53133", "url": "https://ubuntu.com/security/CVE-2024-53133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Handle dml allocation failure to avoid crash [Why] In the case where a dml allocation fails for any reason, the current state's dml contexts would no longer be valid. Then subsequent calls dc_state_copy_internal would shallow copy invalid memory and if the new state was released, a double free would occur. [How] Reset dml pointers in new_state to NULL and avoid invalid pointer (cherry picked from commit bcafdc61529a48f6f06355d78eb41b3aeda5296c)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53108", "url": "https://ubuntu.com/security/CVE-2024-53108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Adjust VSDB parser for replay feature At some point, the IEEE ID identification for the replay check in the AMD EDID was added. However, this check causes the following out-of-bounds issues when using KASAN: [ 27.804016] BUG: KASAN: slab-out-of-bounds in amdgpu_dm_update_freesync_caps+0xefa/0x17a0 [amdgpu] [ 27.804788] Read of size 1 at addr ffff8881647fdb00 by task systemd-udevd/383 ... [ 27.821207] Memory state around the buggy address: [ 27.821215] ffff8881647fda00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821224] ffff8881647fda80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821234] >ffff8881647fdb00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821243] ^ [ 27.821250] ffff8881647fdb80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821259] ffff8881647fdc00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821268] ================================================================== This is caused because the ID extraction happens outside of the range of the edid lenght. This commit addresses this issue by considering the amd_vsdb_block size. (cherry picked from commit b7e381b1ccd5e778e3d9c44c669ad38439a861d8)", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53134", "url": "https://ubuntu.com/security/CVE-2024-53134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pmdomain: imx93-blk-ctrl: correct remove path The check condition should be 'i < bc->onecell_data.num_domains', not 'bc->onecell_data.num_domains' which will make the look never finish and cause kernel panic. Also disable runtime to address \"imx93-blk-ctrl 4ac10000.system-controller: Unbalanced pm_runtime_enable!\"", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53132", "url": "https://ubuntu.com/security/CVE-2024-53132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/oa: Fix \"Missing outer runtime PM protection\" warning Fix the following drm_WARN: [953.586396] xe 0000:00:02.0: [drm] Missing outer runtime PM protection ... <4> [953.587090] ? xe_pm_runtime_get_noresume+0x8d/0xa0 [xe] <4> [953.587208] guc_exec_queue_add_msg+0x28/0x130 [xe] <4> [953.587319] guc_exec_queue_fini+0x3a/0x40 [xe] <4> [953.587425] xe_exec_queue_destroy+0xb3/0xf0 [xe] <4> [953.587515] xe_oa_release+0x9c/0xc0 [xe] (cherry picked from commit b107c63d2953907908fd0cafb0e543b3c3167b75)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53127", "url": "https://ubuntu.com/security/CVE-2024-53127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Revert \"mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K\" The commit 8396c793ffdf (\"mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K\") increased the max_req_size, even for 4K pages, causing various issues: - Panic booting the kernel/rootfs from an SD card on Rockchip RK3566 - Panic booting the kernel/rootfs from an SD card on StarFive JH7100 - \"swiotlb buffer is full\" and data corruption on StarFive JH7110 At this stage no fix have been found, so it's probably better to just revert the change. This reverts commit 8396c793ffdf28bb8aee7cfe0891080f8cab7890.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53130", "url": "https://ubuntu.com/security/CVE-2024-53130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint When using the \"block:block_dirty_buffer\" tracepoint, mark_buffer_dirty() may cause a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because, since the tracepoint was added in mark_buffer_dirty(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, nilfs_grab_buffer(), which grabs a buffer to read (or create) a block of metadata, including b-tree node blocks, does not set the block device, but instead does so only if the buffer is not in the \"uptodate\" state for each of its caller block reading functions. However, if the uptodate flag is set on a folio/page, and the buffer heads are detached from it by try_to_free_buffers(), and new buffer heads are then attached by create_empty_buffers(), the uptodate flag may be restored to each buffer without the block device being set to bh->b_bdev, and mark_buffer_dirty() may be called later in that state, resulting in the bug mentioned above. Fix this issue by making nilfs_grab_buffer() always set the block device of the super block structure to the buffer head, regardless of the state of the buffer's uptodate flag.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53105", "url": "https://ubuntu.com/security/CVE-2024-53105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: page_alloc: move mlocked flag clearance into free_pages_prepare() Syzbot reported a bad page state problem caused by a page being freed using free_page() still having a mlocked flag at free_pages_prepare() stage: BUG: Bad page state in process syz.5.504 pfn:61f45 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x61f45 flags: 0xfff00000080204(referenced|workingset|mlocked|node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000080204 0000000000000000 dead000000000122 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set page_owner tracks the page as allocated page last allocated via order 0, migratetype Unmovable, gfp_mask 0x400dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO), pid 8443, tgid 8442 (syz.5.504), ts 201884660643, free_ts 201499827394 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1537 prep_new_page mm/page_alloc.c:1545 [inline] get_page_from_freelist+0x303f/0x3190 mm/page_alloc.c:3457 __alloc_pages_noprof+0x292/0x710 mm/page_alloc.c:4733 alloc_pages_mpol_noprof+0x3e8/0x680 mm/mempolicy.c:2265 kvm_coalesced_mmio_init+0x1f/0xf0 virt/kvm/coalesced_mmio.c:99 kvm_create_vm virt/kvm/kvm_main.c:1235 [inline] kvm_dev_ioctl_create_vm virt/kvm/kvm_main.c:5488 [inline] kvm_dev_ioctl+0x12dc/0x2240 virt/kvm/kvm_main.c:5530 __do_compat_sys_ioctl fs/ioctl.c:1007 [inline] __se_compat_sys_ioctl+0x510/0xc90 fs/ioctl.c:950 do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline] __do_fast_syscall_32+0xb4/0x110 arch/x86/entry/common.c:386 do_fast_syscall_32+0x34/0x80 arch/x86/entry/common.c:411 entry_SYSENTER_compat_after_hwframe+0x84/0x8e page last free pid 8399 tgid 8399 stack trace: reset_page_owner include/linux/page_owner.h:25 [inline] free_pages_prepare mm/page_alloc.c:1108 [inline] free_unref_folios+0xf12/0x18d0 mm/page_alloc.c:2686 folios_put_refs+0x76c/0x860 mm/swap.c:1007 free_pages_and_swap_cache+0x5c8/0x690 mm/swap_state.c:335 __tlb_batch_free_encoded_pages mm/mmu_gather.c:136 [inline] tlb_batch_pages_flush mm/mmu_gather.c:149 [inline] tlb_flush_mmu_free mm/mmu_gather.c:366 [inline] tlb_flush_mmu+0x3a3/0x680 mm/mmu_gather.c:373 tlb_finish_mmu+0xd4/0x200 mm/mmu_gather.c:465 exit_mmap+0x496/0xc40 mm/mmap.c:1926 __mmput+0x115/0x390 kernel/fork.c:1348 exit_mm+0x220/0x310 kernel/exit.c:571 do_exit+0x9b2/0x28e0 kernel/exit.c:926 do_group_exit+0x207/0x2c0 kernel/exit.c:1088 __do_sys_exit_group kernel/exit.c:1099 [inline] __se_sys_exit_group kernel/exit.c:1097 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1097 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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 Modules linked in: CPU: 0 UID: 0 PID: 8442 Comm: syz.5.504 Not tainted 6.12.0-rc6-syzkaller #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 bad_page+0x176/0x1d0 mm/page_alloc.c:501 free_page_is_bad mm/page_alloc.c:918 [inline] free_pages_prepare mm/page_alloc.c:1100 [inline] free_unref_page+0xed0/0xf20 mm/page_alloc.c:2638 kvm_destroy_vm virt/kvm/kvm_main.c:1327 [inline] kvm_put_kvm+0xc75/0x1350 virt/kvm/kvm_main.c:1386 kvm_vcpu_release+0x54/0x60 virt/kvm/kvm_main.c:4143 __fput+0x23f/0x880 fs/file_table.c:431 task_work_run+0x24f/0x310 kernel/task_work.c:239 exit_task_work include/linux/task_work.h:43 [inline] do_exit+0xa2f/0x28e0 kernel/exit.c:939 do_group_exit+0x207/0x2c0 kernel/exit.c:1088 __do_sys_exit_group kernel/exit.c:1099 [in ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53109", "url": "https://ubuntu.com/security/CVE-2024-53109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nommu: pass NULL argument to vma_iter_prealloc() When deleting a vma entry from a maple tree, it has to pass NULL to vma_iter_prealloc() in order to calculate internal state of the tree, but it passed a wrong argument. As a result, nommu kernels crashed upon accessing a vma iterator, such as acct_collect() reading the size of vma entries after do_munmap(). This commit fixes this issue by passing a right argument to the preallocation call.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53131", "url": "https://ubuntu.com/security/CVE-2024-53131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint Patch series \"nilfs2: fix null-ptr-deref bugs on block tracepoints\". This series fixes null pointer dereference bugs that occur when using nilfs2 and two block-related tracepoints. This patch (of 2): It has been reported that when using \"block:block_touch_buffer\" tracepoint, touch_buffer() called from __nilfs_get_folio_block() causes a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because since the tracepoint was added in touch_buffer(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, the block_device structure is set after the function returns to the caller. Here, touch_buffer() is used to mark the folio/page that owns the buffer head as accessed, but the common search helper for folio/page used by the caller function was optimized to mark the folio/page as accessed when it was reimplemented a long time ago, eliminating the need to call touch_buffer() here in the first place. So this solves the issue by eliminating the touch_buffer() call itself.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53135", "url": "https://ubuntu.com/security/CVE-2024-53135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: VMX: Bury Intel PT virtualization (guest/host mode) behind CONFIG_BROKEN Hide KVM's pt_mode module param behind CONFIG_BROKEN, i.e. disable support for virtualizing Intel PT via guest/host mode unless BROKEN=y. There are myriad bugs in the implementation, some of which are fatal to the guest, and others which put the stability and health of the host at risk. For guest fatalities, the most glaring issue is that KVM fails to ensure tracing is disabled, and *stays* disabled prior to VM-Enter, which is necessary as hardware disallows loading (the guest's) RTIT_CTL if tracing is enabled (enforced via a VMX consistency check). Per the SDM: If the logical processor is operating with Intel PT enabled (if IA32_RTIT_CTL.TraceEn = 1) at the time of VM entry, the \"load IA32_RTIT_CTL\" VM-entry control must be 0. On the host side, KVM doesn't validate the guest CPUID configuration provided by userspace, and even worse, uses the guest configuration to decide what MSRs to save/load at VM-Enter and VM-Exit. E.g. configuring guest CPUID to enumerate more address ranges than are supported in hardware will result in KVM trying to passthrough, save, and load non-existent MSRs, which generates a variety of WARNs, ToPA ERRORs in the host, a potential deadlock, etc.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53106", "url": "https://ubuntu.com/security/CVE-2024-53106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: fix buffer overrun in ima_eventdigest_init_common Function ima_eventdigest_init() calls ima_eventdigest_init_common() with HASH_ALGO__LAST which is then used to access the array hash_digest_size[] leading to buffer overrun. Have a conditional statement to handle this.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53110", "url": "https://ubuntu.com/security/CVE-2024-53110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vp_vdpa: fix id_table array not null terminated error Allocate one extra virtio_device_id as null terminator, otherwise vdpa_mgmtdev_get_classes() may iterate multiple times and visit undefined memory.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53126", "url": "https://ubuntu.com/security/CVE-2024-53126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa: solidrun: Fix UB bug with devres In psnet_open_pf_bar() and snet_open_vf_bar() a string later passed to pcim_iomap_regions() is placed on the stack. Neither pcim_iomap_regions() nor the functions it calls copy that string. Should the string later ever be used, this, consequently, causes undefined behavior since the stack frame will by then have disappeared. Fix the bug by allocating the strings on the heap through devm_kasprintf().", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53111", "url": "https://ubuntu.com/security/CVE-2024-53111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mremap: fix address wraparound in move_page_tables() On 32-bit platforms, it is possible for the expression `len + old_addr < old_end` to be false-positive if `len + old_addr` wraps around. `old_addr` is the cursor in the old range up to which page table entries have been moved; so if the operation succeeded, `old_addr` is the *end* of the old region, and adding `len` to it can wrap. The overflow causes mremap() to mistakenly believe that PTEs have been copied; the consequence is that mremap() bails out, but doesn't move the PTEs back before the new VMA is unmapped, causing anonymous pages in the region to be lost. So basically if userspace tries to mremap() a private-anon region and hits this bug, mremap() will return an error and the private-anon region's contents appear to have been zeroed. The idea of this check is that `old_end - len` is the original start address, and writing the check that way also makes it easier to read; so fix the check by rearranging the comparison accordingly. (An alternate fix would be to refactor this function by introducing an \"orig_old_start\" variable or such.) Tested in a VM with a 32-bit X86 kernel; without the patch: ``` user@horn:~/big_mremap$ cat test.c #define _GNU_SOURCE #include #include #include #include #define ADDR1 ((void*)0x60000000) #define ADDR2 ((void*)0x10000000) #define SIZE 0x50000000uL int main(void) { unsigned char *p1 = mmap(ADDR1, SIZE, PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0); if (p1 == MAP_FAILED) err(1, \"mmap 1\"); unsigned char *p2 = mmap(ADDR2, SIZE, PROT_NONE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0); if (p2 == MAP_FAILED) err(1, \"mmap 2\"); *p1 = 0x41; printf(\"first char is 0x%02hhx\\n\", *p1); unsigned char *p3 = mremap(p1, SIZE, SIZE, MREMAP_MAYMOVE|MREMAP_FIXED, p2); if (p3 == MAP_FAILED) { printf(\"mremap() failed; first char is 0x%02hhx\\n\", *p1); } else { printf(\"mremap() succeeded; first char is 0x%02hhx\\n\", *p3); } } user@horn:~/big_mremap$ gcc -static -o test test.c user@horn:~/big_mremap$ setarch -R ./test first char is 0x41 mremap() failed; first char is 0x00 ``` With the patch: ``` user@horn:~/big_mremap$ setarch -R ./test first char is 0x41 mremap() succeeded; first char is 0x41 ```", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53107", "url": "https://ubuntu.com/security/CVE-2024-53107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: prevent integer overflow in pagemap_scan_get_args() The \"arg->vec_len\" variable is a u64 that comes from the user at the start of the function. The \"arg->vec_len * sizeof(struct page_region))\" multiplication can lead to integer wrapping. Use size_mul() to avoid that. Also the size_add/mul() functions work on unsigned long so for 32bit systems we need to ensure that \"arg->vec_len\" fits in an unsigned long.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53128", "url": "https://ubuntu.com/security/CVE-2024-53128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/task_stack: fix object_is_on_stack() for KASAN tagged pointers When CONFIG_KASAN_SW_TAGS and CONFIG_KASAN_STACK are enabled, the object_is_on_stack() function may produce incorrect results due to the presence of tags in the obj pointer, while the stack pointer does not have tags. This discrepancy can lead to incorrect stack object detection and subsequently trigger warnings if CONFIG_DEBUG_OBJECTS is also enabled. Example of the warning: ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at lib/debugobjects.c:557 __debug_object_init+0x330/0x364 Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5 #4 Hardware name: linux,dummy-virt (DT) pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __debug_object_init+0x330/0x364 lr : __debug_object_init+0x330/0x364 sp : ffff800082ea7b40 x29: ffff800082ea7b40 x28: 98ff0000c0164518 x27: 98ff0000c0164534 x26: ffff800082d93ec8 x25: 0000000000000001 x24: 1cff0000c00172a0 x23: 0000000000000000 x22: ffff800082d93ed0 x21: ffff800081a24418 x20: 3eff800082ea7bb0 x19: efff800000000000 x18: 0000000000000000 x17: 00000000000000ff x16: 0000000000000047 x15: 206b63617473206e x14: 0000000000000018 x13: ffff800082ea7780 x12: 0ffff800082ea78e x11: 0ffff800082ea790 x10: 0ffff800082ea79d x9 : 34d77febe173e800 x8 : 34d77febe173e800 x7 : 0000000000000001 x6 : 0000000000000001 x5 : feff800082ea74b8 x4 : ffff800082870a90 x3 : ffff80008018d3c4 x2 : 0000000000000001 x1 : ffff800082858810 x0 : 0000000000000050 Call trace: __debug_object_init+0x330/0x364 debug_object_init_on_stack+0x30/0x3c schedule_hrtimeout_range_clock+0xac/0x26c schedule_hrtimeout+0x1c/0x30 wait_task_inactive+0x1d4/0x25c kthread_bind_mask+0x28/0x98 init_rescuer+0x1e8/0x280 workqueue_init+0x1a0/0x3cc kernel_init_freeable+0x118/0x200 kernel_init+0x28/0x1f0 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53112", "url": "https://ubuntu.com/security/CVE-2024-53112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: uncache inode which has failed entering the group Syzbot has reported the following BUG: kernel BUG at fs/ocfs2/uptodate.c:509! ... Call Trace: ? __die_body+0x5f/0xb0 ? die+0x9e/0xc0 ? do_trap+0x15a/0x3a0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? do_error_trap+0x1dc/0x2c0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? __pfx_do_error_trap+0x10/0x10 ? handle_invalid_op+0x34/0x40 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? exc_invalid_op+0x38/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? ocfs2_set_new_buffer_uptodate+0x2e/0x160 ? ocfs2_set_new_buffer_uptodate+0x144/0x160 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ocfs2_group_add+0x39f/0x15a0 ? __pfx_ocfs2_group_add+0x10/0x10 ? __pfx_lock_acquire+0x10/0x10 ? mnt_get_write_access+0x68/0x2b0 ? __pfx_lock_release+0x10/0x10 ? rcu_read_lock_any_held+0xb7/0x160 ? __pfx_rcu_read_lock_any_held+0x10/0x10 ? smack_log+0x123/0x540 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x226/0x2b0 ocfs2_ioctl+0x65e/0x7d0 ? __pfx_ocfs2_ioctl+0x10/0x10 ? smack_file_ioctl+0x29e/0x3a0 ? __pfx_smack_file_ioctl+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x43d/0x780 ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10 ? __pfx_ocfs2_ioctl+0x10/0x10 __se_sys_ioctl+0xfb/0x170 do_syscall_64+0xf3/0x230 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... When 'ioctl(OCFS2_IOC_GROUP_ADD, ...)' has failed for the particular inode in 'ocfs2_verify_group_and_input()', corresponding buffer head remains cached and subsequent call to the same 'ioctl()' for the same inode issues the BUG() in 'ocfs2_set_new_buffer_uptodate()' (trying to cache the same buffer head of that inode). Fix this by uncaching the buffer head with 'ocfs2_remove_from_cache()' on error path in 'ocfs2_group_add()'.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53113", "url": "https://ubuntu.com/security/CVE-2024-53113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: fix NULL pointer dereference in alloc_pages_bulk_noprof We triggered a NULL pointer dereference for ac.preferred_zoneref->zone in alloc_pages_bulk_noprof() when the task is migrated between cpusets. When cpuset is enabled, in prepare_alloc_pages(), ac->nodemask may be ¤t->mems_allowed. when first_zones_zonelist() is called to find preferred_zoneref, the ac->nodemask may be modified concurrently if the task is migrated between different cpusets. Assuming we have 2 NUMA Node, when traversing Node1 in ac->zonelist, the nodemask is 2, and when traversing Node2 in ac->zonelist, the nodemask is 1. As a result, the ac->preferred_zoneref points to NULL zone. In alloc_pages_bulk_noprof(), for_each_zone_zonelist_nodemask() finds a allowable zone and calls zonelist_node_idx(ac.preferred_zoneref), leading to NULL pointer dereference. __alloc_pages_noprof() fixes this issue by checking NULL pointer in commit ea57485af8f4 (\"mm, page_alloc: fix check for NULL preferred_zone\") and commit df76cee6bbeb (\"mm, page_alloc: remove redundant checks from alloc fastpath\"). To fix it, check NULL pointer for preferred_zoneref->zone.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53114", "url": "https://ubuntu.com/security/CVE-2024-53114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 client A number of Zen4 client SoCs advertise the ability to use virtualized VMLOAD/VMSAVE, but using these instructions is reported to be a cause of a random host reboot. These instructions aren't intended to be advertised on Zen4 client so clear the capability.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53137", "url": "https://ubuntu.com/security/CVE-2024-53137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: fix cacheflush with PAN It seems that the cacheflush syscall got broken when PAN for LPAE was implemented. User access was not enabled around the cache maintenance instructions, causing them to fault.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53115", "url": "https://ubuntu.com/security/CVE-2024-53115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: avoid null_ptr_deref in vmw_framebuffer_surface_create_handle The 'vmw_user_object_buffer' function may return NULL with incorrect inputs. To avoid possible null pointer dereference, add a check whether the 'bo' is NULL in the vmw_framebuffer_surface_create_handle.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53116", "url": "https://ubuntu.com/security/CVE-2024-53116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix handling of partial GPU mapping of BOs This commit fixes the bug in the handling of partial mapping of the buffer objects to the GPU, which caused kernel warnings. Panthor didn't correctly handle the case where the partial mapping spanned multiple scatterlists and the mapping offset didn't point to the 1st page of starting scatterlist. The offset variable was not cleared after reaching the starting scatterlist. Following warning messages were seen. WARNING: CPU: 1 PID: 650 at drivers/iommu/io-pgtable-arm.c:659 __arm_lpae_unmap+0x254/0x5a0 pc : __arm_lpae_unmap+0x254/0x5a0 lr : __arm_lpae_unmap+0x2cc/0x5a0 Call trace: __arm_lpae_unmap+0x254/0x5a0 __arm_lpae_unmap+0x108/0x5a0 __arm_lpae_unmap+0x108/0x5a0 __arm_lpae_unmap+0x108/0x5a0 arm_lpae_unmap_pages+0x80/0xa0 panthor_vm_unmap_pages+0xac/0x1c8 [panthor] panthor_gpuva_sm_step_unmap+0x4c/0xc8 [panthor] op_unmap_cb.isra.23.constprop.30+0x54/0x80 __drm_gpuvm_sm_unmap+0x184/0x1c8 drm_gpuvm_sm_unmap+0x40/0x60 panthor_vm_exec_op+0xa8/0x120 [panthor] panthor_vm_bind_exec_sync_op+0xc4/0xe8 [panthor] panthor_ioctl_vm_bind+0x10c/0x170 [panthor] drm_ioctl_kernel+0xbc/0x138 drm_ioctl+0x210/0x4b0 __arm64_sys_ioctl+0xb0/0xf8 invoke_syscall+0x4c/0x110 el0_svc_common.constprop.1+0x98/0xf8 do_el0_svc+0x24/0x38 el0_svc+0x34/0xc8 el0t_64_sync_handler+0xa0/0xc8 el0t_64_sync+0x174/0x178 panthor : [drm] drm_WARN_ON(unmapped_sz != pgsize * pgcount) WARNING: CPU: 1 PID: 650 at drivers/gpu/drm/panthor/panthor_mmu.c:922 panthor_vm_unmap_pages+0x124/0x1c8 [panthor] pc : panthor_vm_unmap_pages+0x124/0x1c8 [panthor] lr : panthor_vm_unmap_pages+0x124/0x1c8 [panthor] panthor : [drm] *ERROR* failed to unmap range ffffa388f000-ffffa3890000 (requested range ffffa388c000-ffffa3890000)", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53117", "url": "https://ubuntu.com/security/CVE-2024-53117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio/vsock: Improve MSG_ZEROCOPY error handling Add a missing kfree_skb() to prevent memory leaks.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53118", "url": "https://ubuntu.com/security/CVE-2024-53118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Fix sk_error_queue memory leak Kernel queues MSG_ZEROCOPY completion notifications on the error queue. Where they remain, until explicitly recv()ed. To prevent memory leaks, clean up the queue when the socket is destroyed. unreferenced object 0xffff8881028beb00 (size 224): comm \"vsock_test\", pid 1218, jiffies 4294694897 hex dump (first 32 bytes): 90 b0 21 17 81 88 ff ff 90 b0 21 17 81 88 ff ff ..!.......!..... 00 00 00 00 00 00 00 00 00 b0 21 17 81 88 ff ff ..........!..... backtrace (crc 6c7031ca): [] kmem_cache_alloc_node_noprof+0x2f7/0x370 [] __alloc_skb+0x132/0x180 [] sock_omalloc+0x4b/0x80 [] msg_zerocopy_realloc+0x9e/0x240 [] virtio_transport_send_pkt_info+0x412/0x4c0 [] virtio_transport_stream_enqueue+0x43/0x50 [] vsock_connectible_sendmsg+0x373/0x450 [] ____sys_sendmsg+0x365/0x3a0 [] ___sys_sendmsg+0x84/0xd0 [] __sys_sendmsg+0x47/0x80 [] do_syscall_64+0x93/0x180 [] entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53119", "url": "https://ubuntu.com/security/CVE-2024-53119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio/vsock: Fix accept_queue memory leak As the final stages of socket destruction may be delayed, it is possible that virtio_transport_recv_listen() will be called after the accept_queue has been flushed, but before the SOCK_DONE flag has been set. As a result, sockets enqueued after the flush would remain unremoved, leading to a memory leak. vsock_release __vsock_release lock virtio_transport_release virtio_transport_close schedule_delayed_work(close_work) sk_shutdown = SHUTDOWN_MASK (!) flush accept_queue release virtio_transport_recv_pkt vsock_find_bound_socket lock if flag(SOCK_DONE) return virtio_transport_recv_listen child = vsock_create_connected (!) vsock_enqueue_accept(child) release close_work lock virtio_transport_do_close set_flag(SOCK_DONE) virtio_transport_remove_sock vsock_remove_sock vsock_remove_bound release Introduce a sk_shutdown check to disallow vsock_enqueue_accept() during socket destruction. unreferenced object 0xffff888109e3f800 (size 2040): comm \"kworker/5:2\", pid 371, jiffies 4294940105 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00 (..@............ backtrace (crc 9e5f4e84): [] kmem_cache_alloc_noprof+0x2c1/0x360 [] sk_prot_alloc+0x30/0x120 [] sk_alloc+0x2c/0x4b0 [] __vsock_create.constprop.0+0x2a/0x310 [] virtio_transport_recv_pkt+0x4dc/0x9a0 [] vsock_loopback_work+0xfd/0x140 [] process_one_work+0x20c/0x570 [] worker_thread+0x1bf/0x3a0 [] kthread+0xdd/0x110 [] ret_from_fork+0x2d/0x50 [] ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53120", "url": "https://ubuntu.com/security/CVE-2024-53120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: CT: Fix null-ptr-deref in add rule err flow In error flow of mlx5_tc_ct_entry_add_rule(), in case ct_rule_add() callback returns error, zone_rule->attr is used uninitiated. Fix it to use attr which has the needed pointer value. Kernel log: BUG: kernel NULL pointer dereference, address: 0000000000000110 RIP: 0010:mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core] … Call Trace: ? __die+0x20/0x70 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x140 ? asm_exc_page_fault+0x22/0x30 ? mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core] ? mlx5_tc_ct_entry_add_rule+0x1d5/0x2f0 [mlx5_core] mlx5_tc_ct_block_flow_offload+0xc6a/0xf90 [mlx5_core] ? nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] flow_offload_work_handler+0x142/0x320 [nf_flow_table] ? finish_task_switch.isra.0+0x15b/0x2b0 process_one_work+0x16c/0x320 worker_thread+0x28c/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xb8/0xf0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53138", "url": "https://ubuntu.com/security/CVE-2024-53138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: kTLS, Fix incorrect page refcounting The kTLS tx handling code is using a mix of get_page() and page_ref_inc() APIs to increment the page reference. But on the release path (mlx5e_ktls_tx_handle_resync_dump_comp()), only put_page() is used. This is an issue when using pages from large folios: the get_page() references are stored on the folio page while the page_ref_inc() references are stored directly in the given page. On release the folio page will be dereferenced too many times. This was found while doing kTLS testing with sendfile() + ZC when the served file was read from NFS on a kernel with NFS large folios support (commit 49b29a573da8 (\"nfs: add support for large folios\")).", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53121", "url": "https://ubuntu.com/security/CVE-2024-53121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: fs, lock FTE when checking if active The referenced commits introduced a two-step process for deleting FTEs: - Lock the FTE, delete it from hardware, set the hardware deletion function to NULL and unlock the FTE. - Lock the parent flow group, delete the software copy of the FTE, and remove it from the xarray. However, this approach encounters a race condition if a rule with the same match value is added simultaneously. In this scenario, fs_core may set the hardware deletion function to NULL prematurely, causing a panic during subsequent rule deletions. To prevent this, ensure the active flag of the FTE is checked under a lock, which will prevent the fs_core layer from attaching a new steering rule to an FTE that is in the process of deletion. [ 438.967589] MOSHE: 2496 mlx5_del_flow_rules del_hw_func [ 438.968205] ------------[ cut here ]------------ [ 438.968654] refcount_t: decrement hit 0; leaking memory. [ 438.969249] WARNING: CPU: 0 PID: 8957 at lib/refcount.c:31 refcount_warn_saturate+0xfb/0x110 [ 438.970054] Modules linked in: act_mirred cls_flower act_gact sch_ingress openvswitch nsh mlx5_vdpa vringh vhost_iotlb vdpa mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core zram zsmalloc fuse [last unloaded: cls_flower] [ 438.973288] CPU: 0 UID: 0 PID: 8957 Comm: tc Not tainted 6.12.0-rc1+ #8 [ 438.973888] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 438.974874] RIP: 0010:refcount_warn_saturate+0xfb/0x110 [ 438.975363] Code: 40 66 3b 82 c6 05 16 e9 4d 01 01 e8 1f 7c a0 ff 0f 0b c3 cc cc cc cc 48 c7 c7 10 66 3b 82 c6 05 fd e8 4d 01 01 e8 05 7c a0 ff <0f> 0b c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 90 [ 438.976947] RSP: 0018:ffff888124a53610 EFLAGS: 00010286 [ 438.977446] RAX: 0000000000000000 RBX: ffff888119d56de0 RCX: 0000000000000000 [ 438.978090] RDX: ffff88852c828700 RSI: ffff88852c81b3c0 RDI: ffff88852c81b3c0 [ 438.978721] RBP: ffff888120fa0e88 R08: 0000000000000000 R09: ffff888124a534b0 [ 438.979353] R10: 0000000000000001 R11: 0000000000000001 R12: ffff888119d56de0 [ 438.979979] R13: ffff888120fa0ec0 R14: ffff888120fa0ee8 R15: ffff888119d56de0 [ 438.980607] FS: 00007fe6dcc0f800(0000) GS:ffff88852c800000(0000) knlGS:0000000000000000 [ 438.983984] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 438.984544] CR2: 00000000004275e0 CR3: 0000000186982001 CR4: 0000000000372eb0 [ 438.985205] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 438.985842] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 438.986507] Call Trace: [ 438.986799] [ 438.987070] ? __warn+0x7d/0x110 [ 438.987426] ? refcount_warn_saturate+0xfb/0x110 [ 438.987877] ? report_bug+0x17d/0x190 [ 438.988261] ? prb_read_valid+0x17/0x20 [ 438.988659] ? handle_bug+0x53/0x90 [ 438.989054] ? exc_invalid_op+0x14/0x70 [ 438.989458] ? asm_exc_invalid_op+0x16/0x20 [ 438.989883] ? refcount_warn_saturate+0xfb/0x110 [ 438.990348] mlx5_del_flow_rules+0x2f7/0x340 [mlx5_core] [ 438.990932] __mlx5_eswitch_del_rule+0x49/0x170 [mlx5_core] [ 438.991519] ? mlx5_lag_is_sriov+0x3c/0x50 [mlx5_core] [ 438.992054] ? xas_load+0x9/0xb0 [ 438.992407] mlx5e_tc_rule_unoffload+0x45/0xe0 [mlx5_core] [ 438.993037] mlx5e_tc_del_fdb_flow+0x2a6/0x2e0 [mlx5_core] [ 438.993623] mlx5e_flow_put+0x29/0x60 [mlx5_core] [ 438.994161] mlx5e_delete_flower+0x261/0x390 [mlx5_core] [ 438.994728] tc_setup_cb_destroy+0xb9/0x190 [ 438.995150] fl_hw_destroy_filter+0x94/0xc0 [cls_flower] [ 438.995650] fl_change+0x11a4/0x13c0 [cls_flower] [ 438.996105] tc_new_tfilter+0x347/0xbc0 [ 438.996503] ? __ ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53122", "url": "https://ubuntu.com/security/CVE-2024-53122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: cope racing subflow creation in mptcp_rcv_space_adjust Additional active subflows - i.e. created by the in kernel path manager - are included into the subflow list before starting the 3whs. A racing recvmsg() spooling data received on an already established subflow would unconditionally call tcp_cleanup_rbuf() on all the current subflows, potentially hitting a divide by zero error on the newly created ones. Explicitly check that the subflow is in a suitable state before invoking tcp_cleanup_rbuf().", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53123", "url": "https://ubuntu.com/security/CVE-2024-53123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: error out earlier on disconnect Eric reported a division by zero splat in the MPTCP protocol: Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 6094 Comm: syz-executor317 Not tainted 6.12.0-rc5-syzkaller-00291-g05b92660cdfe #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:__tcp_select_window+0x5b4/0x1310 net/ipv4/tcp_output.c:3163 Code: f6 44 01 e3 89 df e8 9b 75 09 f8 44 39 f3 0f 8d 11 ff ff ff e8 0d 74 09 f8 45 89 f4 e9 04 ff ff ff e8 00 74 09 f8 44 89 f0 99 7c 24 14 41 29 d6 45 89 f4 e9 ec fe ff ff e8 e8 73 09 f8 48 89 RSP: 0018:ffffc900041f7930 EFLAGS: 00010293 RAX: 0000000000017e67 RBX: 0000000000017e67 RCX: ffffffff8983314b RDX: 0000000000000000 RSI: ffffffff898331b0 RDI: 0000000000000004 RBP: 00000000005d6000 R08: 0000000000000004 R09: 0000000000017e67 R10: 0000000000003e80 R11: 0000000000000000 R12: 0000000000003e80 R13: ffff888031d9b440 R14: 0000000000017e67 R15: 00000000002eb000 FS: 00007feb5d7f16c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007feb5d8adbb8 CR3: 0000000074e4c000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __tcp_cleanup_rbuf+0x3e7/0x4b0 net/ipv4/tcp.c:1493 mptcp_rcv_space_adjust net/mptcp/protocol.c:2085 [inline] mptcp_recvmsg+0x2156/0x2600 net/mptcp/protocol.c:2289 inet_recvmsg+0x469/0x6a0 net/ipv4/af_inet.c:885 sock_recvmsg_nosec net/socket.c:1051 [inline] sock_recvmsg+0x1b2/0x250 net/socket.c:1073 __sys_recvfrom+0x1a5/0x2e0 net/socket.c:2265 __do_sys_recvfrom net/socket.c:2283 [inline] __se_sys_recvfrom net/socket.c:2279 [inline] __x64_sys_recvfrom+0xe0/0x1c0 net/socket.c:2279 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 RIP: 0033:0x7feb5d857559 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:00007feb5d7f1208 EFLAGS: 00000246 ORIG_RAX: 000000000000002d RAX: ffffffffffffffda RBX: 00007feb5d8e1318 RCX: 00007feb5d857559 RDX: 000000800000000e RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007feb5d8e1310 R08: 0000000000000000 R09: ffffffff81000000 R10: 0000000000000100 R11: 0000000000000246 R12: 00007feb5d8e131c R13: 00007feb5d8ae074 R14: 000000800000000e R15: 00000000fffffdef and provided a nice reproducer. The root cause is the current bad handling of racing disconnect. After the blamed commit below, sk_wait_data() can return (with error) with the underlying socket disconnected and a zero rcv_mss. Catch the error and return without performing any additional operations on the current socket.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53124", "url": "https://ubuntu.com/security/CVE-2024-53124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix data-races around sk->sk_forward_alloc Syzkaller reported this warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 16 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x1c5/0x1e0 Modules linked in: CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:inet_sock_destruct+0x1c5/0x1e0 Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 <0f> 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00 RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206 RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007 RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00 RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007 R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00 R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78 FS: 0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn+0x88/0x130 ? inet_sock_destruct+0x1c5/0x1e0 ? report_bug+0x18e/0x1a0 ? handle_bug+0x53/0x90 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? inet_sock_destruct+0x1c5/0x1e0 __sk_destruct+0x2a/0x200 rcu_do_batch+0x1aa/0x530 ? rcu_do_batch+0x13b/0x530 rcu_core+0x159/0x2f0 handle_softirqs+0xd3/0x2b0 ? __pfx_smpboot_thread_fn+0x10/0x10 run_ksoftirqd+0x25/0x30 smpboot_thread_fn+0xdd/0x1d0 kthread+0xd3/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ---[ end trace 0000000000000000 ]--- Its possible that two threads call tcp_v6_do_rcv()/sk_forward_alloc_add() concurrently when sk->sk_state == TCP_LISTEN with sk->sk_lock unlocked, which triggers a data-race around sk->sk_forward_alloc: tcp_v6_rcv tcp_v6_do_rcv skb_clone_and_charge_r sk_rmem_schedule __sk_mem_schedule sk_forward_alloc_add() skb_set_owner_r sk_mem_charge sk_forward_alloc_add() __kfree_skb skb_release_all skb_release_head_state sock_rfree sk_mem_uncharge sk_forward_alloc_add() sk_mem_reclaim // set local var reclaimable __sk_mem_reclaim sk_forward_alloc_add() In this syzkaller testcase, two threads call tcp_v6_do_rcv() with skb->truesize=768, the sk_forward_alloc changes like this: (cpu 1) | (cpu 2) | sk_forward_alloc ... | ... | 0 __sk_mem_schedule() | | +4096 = 4096 | __sk_mem_schedule() | +4096 = 8192 sk_mem_charge() | | -768 = 7424 | sk_mem_charge() | -768 = 6656 ... | ... | sk_mem_uncharge() | | +768 = 7424 reclaimable=7424 | | | sk_mem_uncharge() | +768 = 8192 | reclaimable=8192 | __sk_mem_reclaim() | | -4096 = 4096 | __sk_mem_reclaim() | -8192 = -4096 != 0 The skb_clone_and_charge_r() should not be called in tcp_v6_do_rcv() when sk->sk_state is TCP_LISTEN, it happens later in tcp_v6_syn_recv_sock(). Fix the same issue in dccp_v6_do_rcv().", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53129", "url": "https://ubuntu.com/security/CVE-2024-53129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: vop: Fix a dereferenced before check warning The 'state' can't be NULL, we should check crtc_state. Fix warning: drivers/gpu/drm/rockchip/rockchip_drm_vop.c:1096 vop_plane_atomic_async_check() warn: variable dereferenced before check 'state' (see line 1077)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53139", "url": "https://ubuntu.com/security/CVE-2024-53139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix possible UAF in sctp_v6_available() A lockdep report [1] with CONFIG_PROVE_RCU_LIST=y hints that sctp_v6_available() is calling dev_get_by_index_rcu() and ipv6_chk_addr() without holding rcu. [1] ============================= WARNING: suspicious RCU usage 6.12.0-rc5-virtme #1216 Tainted: G W ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by sctp_hello/31495: #0: ffff9f1ebbdb7418 (sk_lock-AF_INET6){+.+.}-{0:0}, at: sctp_bind (./arch/x86/include/asm/jump_label.h:27 net/sctp/socket.c:315) sctp stack backtrace: CPU: 7 UID: 0 PID: 31495 Comm: sctp_hello Tainted: G W 6.12.0-rc5-virtme #1216 Tainted: [W]=WARN 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:123) lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822) dev_get_by_index_rcu (net/core/dev.c:876 (discriminator 7)) sctp_v6_available (net/sctp/ipv6.c:701) sctp sctp_do_bind (net/sctp/socket.c:400 (discriminator 1)) sctp sctp_bind (net/sctp/socket.c:320) sctp inet6_bind_sk (net/ipv6/af_inet6.c:465) ? security_socket_bind (security/security.c:4581 (discriminator 1)) __sys_bind (net/socket.c:1848 net/socket.c:1869) ? do_user_addr_fault (./include/linux/rcupdate.h:347 ./include/linux/rcupdate.h:880 ./include/linux/mm.h:729 arch/x86/mm/fault.c:1340) ? do_user_addr_fault (./arch/x86/include/asm/preempt.h:84 (discriminator 13) ./include/linux/rcupdate.h:98 (discriminator 13) ./include/linux/rcupdate.h:882 (discriminator 13) ./include/linux/mm.h:729 (discriminator 13) arch/x86/mm/fault.c:1340 (discriminator 13)) __x64_sys_bind (net/socket.c:1877 (discriminator 1) net/socket.c:1875 (discriminator 1) net/socket.c:1875 (discriminator 1)) do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f59b934a1e7 Code: 44 00 00 48 8b 15 39 8c 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 b8 31 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 09 8c 0c 00 f7 d8 64 89 01 48 All code ======== 0:\t44 00 00 \tadd %r8b,(%rax) 3:\t48 8b 15 39 8c 0c 00 \tmov 0xc8c39(%rip),%rdx # 0xc8c43 a:\tf7 d8 \tneg %eax c:\t64 89 02 \tmov %eax,%fs:(%rdx) f:\tb8 ff ff ff ff \tmov $0xffffffff,%eax 14:\teb bd \tjmp 0xffffffffffffffd3 16:\t66 2e 0f 1f 84 00 00 \tcs nopw 0x0(%rax,%rax,1) 1d:\t00 00 00 20:\t0f 1f 00 \tnopl (%rax) 23:\tb8 31 00 00 00 \tmov $0x31,%eax 28:\t0f 05 \tsyscall 2a:*\t48 3d 01 f0 ff ff \tcmp $0xfffffffffffff001,%rax\t\t<-- trapping instruction 30:\t73 01 \tjae 0x33 32:\tc3 \tret 33:\t48 8b 0d 09 8c 0c 00 \tmov 0xc8c09(%rip),%rcx # 0xc8c43 3a:\tf7 d8 \tneg %eax 3c:\t64 89 01 \tmov %eax,%fs:(%rcx) 3f:\t48 \trex.W Code starting with the faulting instruction =========================================== 0:\t48 3d 01 f0 ff ff \tcmp $0xfffffffffffff001,%rax 6:\t73 01 \tjae 0x9 8:\tc3 \tret 9:\t48 8b 0d 09 8c 0c 00 \tmov 0xc8c09(%rip),%rcx # 0xc8c19 10:\tf7 d8 \tneg %eax 12:\t64 89 01 \tmov %eax,%fs:(%rcx) 15:\t48 \trex.W RSP: 002b:00007ffe2d0ad398 EFLAGS: 00000202 ORIG_RAX: 0000000000000031 RAX: ffffffffffffffda RBX: 00007ffe2d0ad3d0 RCX: 00007f59b934a1e7 RDX: 000000000000001c RSI: 00007ffe2d0ad3d0 RDI: 0000000000000005 RBP: 0000000000000005 R08: 1999999999999999 R09: 0000000000000000 R10: 00007f59b9253298 R11: 000000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53140", "url": "https://ubuntu.com/security/CVE-2024-53140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netlink: terminate outstanding dump on socket close Netlink supports iterative dumping of data. It provides the families the following ops: - start - (optional) kicks off the dumping process - dump - actual dump helper, keeps getting called until it returns 0 - done - (optional) pairs with .start, can be used for cleanup The whole process is asynchronous and the repeated calls to .dump don't actually happen in a tight loop, but rather are triggered in response to recvmsg() on the socket. This gives the user full control over the dump, but also means that the user can close the socket without getting to the end of the dump. To make sure .start is always paired with .done we check if there is an ongoing dump before freeing the socket, and if so call .done. The complication is that sockets can get freed from BH and .done is allowed to sleep. So we use a workqueue to defer the call, when needed. Unfortunately this does not work correctly. What we defer is not the cleanup but rather releasing a reference on the socket. We have no guarantee that we own the last reference, if someone else holds the socket they may release it in BH and we're back to square one. The whole dance, however, appears to be unnecessary. Only the user can interact with dumps, so we can clean up when socket is closed. And close always happens in process context. Some async code may still access the socket after close, queue notification skbs to it etc. but no dumps can start, end or otherwise make progress. Delete the workqueue and flush the dump state directly from the release handler. Note that further cleanup is possible in -next, for instance we now always call .done before releasing the main module reference, so dump doesn't have to take a reference of its own.", "cve_priority": "high", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53098", "url": "https://ubuntu.com/security/CVE-2024-53098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/ufence: Prefetch ufence addr to catch bogus address access_ok() only checks for addr overflow so also try to read the addr to catch invalid addr sent from userspace. (cherry picked from commit 9408c4508483ffc60811e910a93d6425b8e63928)", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53099", "url": "https://ubuntu.com/security/CVE-2024-53099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check validity of link->type in bpf_link_show_fdinfo() If a newly-added link type doesn't invoke BPF_LINK_TYPE(), accessing bpf_link_type_strs[link->type] may result in an out-of-bounds access. To spot such missed invocations early in the future, checking the validity of link->type in bpf_link_show_fdinfo() and emitting a warning when such invocations are missed.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53089", "url": "https://ubuntu.com/security/CVE-2024-53089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: KVM: Mark hrtimer to expire in hard interrupt context Like commit 2c0d278f3293f (\"KVM: LAPIC: Mark hrtimer to expire in hard interrupt context\") and commit 9090825fa9974 (\"KVM: arm/arm64: Let the timer expire in hardirq context on RT\"), On PREEMPT_RT enabled kernels unmarked hrtimers are moved into soft interrupt expiry mode by default. Then the timers are canceled from an preempt-notifier which is invoked with disabled preemption which is not allowed on PREEMPT_RT. The timer callback is short so in could be invoked in hard-IRQ context. So let the timer expire on hard-IRQ context even on -RT. This fix a \"scheduling while atomic\" bug for PREEMPT_RT enabled kernels: BUG: scheduling while atomic: qemu-system-loo/1011/0x00000002 Modules linked in: amdgpu rfkill nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat ns CPU: 1 UID: 0 PID: 1011 Comm: qemu-system-loo Tainted: G W 6.12.0-rc2+ #1774 Tainted: [W]=WARN Hardware name: Loongson Loongson-3A5000-7A1000-1w-CRB/Loongson-LS3A5000-7A1000-1w-CRB, BIOS vUDK2018-LoongArch-V2.0.0-prebeta9 10/21/2022 Stack : ffffffffffffffff 0000000000000000 9000000004e3ea38 9000000116744000 90000001167475a0 0000000000000000 90000001167475a8 9000000005644830 90000000058dc000 90000000058dbff8 9000000116747420 0000000000000001 0000000000000001 6a613fc938313980 000000000790c000 90000001001c1140 00000000000003fe 0000000000000001 000000000000000d 0000000000000003 0000000000000030 00000000000003f3 000000000790c000 9000000116747830 90000000057ef000 0000000000000000 9000000005644830 0000000000000004 0000000000000000 90000000057f4b58 0000000000000001 9000000116747868 900000000451b600 9000000005644830 9000000003a13998 0000000010000020 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d ... Call Trace: [<9000000003a13998>] show_stack+0x38/0x180 [<9000000004e3ea34>] dump_stack_lvl+0x84/0xc0 [<9000000003a71708>] __schedule_bug+0x48/0x60 [<9000000004e45734>] __schedule+0x1114/0x1660 [<9000000004e46040>] schedule_rtlock+0x20/0x60 [<9000000004e4e330>] rtlock_slowlock_locked+0x3f0/0x10a0 [<9000000004e4f038>] rt_spin_lock+0x58/0x80 [<9000000003b02d68>] hrtimer_cancel_wait_running+0x68/0xc0 [<9000000003b02e30>] hrtimer_cancel+0x70/0x80 [] kvm_restore_timer+0x50/0x1a0 [kvm] [] kvm_arch_vcpu_load+0x68/0x2a0 [kvm] [] kvm_sched_in+0x34/0x60 [kvm] [<9000000003a749a0>] finish_task_switch.isra.0+0x140/0x2e0 [<9000000004e44a70>] __schedule+0x450/0x1660 [<9000000004e45cb0>] schedule+0x30/0x180 [] kvm_vcpu_block+0x70/0x120 [kvm] [] kvm_vcpu_halt+0x60/0x3e0 [kvm] [] kvm_handle_gspr+0x3f4/0x4e0 [kvm] [] kvm_handle_exit+0x1c8/0x260 [kvm]", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53090", "url": "https://ubuntu.com/security/CVE-2024-53090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix lock recursion afs_wake_up_async_call() can incur lock recursion. The problem is that it is called from AF_RXRPC whilst holding the ->notify_lock, but it tries to take a ref on the afs_call struct in order to pass it to a work queue - but if the afs_call is already queued, we then have an extraneous ref that must be put... calling afs_put_call() may call back down into AF_RXRPC through rxrpc_kernel_shutdown_call(), however, which might try taking the ->notify_lock again. This case isn't very common, however, so defer it to a workqueue. The oops looks something like: BUG: spinlock recursion on CPU#0, krxrpcio/7001/1646 lock: 0xffff888141399b30, .magic: dead4ead, .owner: krxrpcio/7001/1646, .owner_cpu: 0 CPU: 0 UID: 0 PID: 1646 Comm: krxrpcio/7001 Not tainted 6.12.0-rc2-build3+ #4351 Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014 Call Trace: dump_stack_lvl+0x47/0x70 do_raw_spin_lock+0x3c/0x90 rxrpc_kernel_shutdown_call+0x83/0xb0 afs_put_call+0xd7/0x180 rxrpc_notify_socket+0xa0/0x190 rxrpc_input_split_jumbo+0x198/0x1d0 rxrpc_input_data+0x14b/0x1e0 ? rxrpc_input_call_packet+0xc2/0x1f0 rxrpc_input_call_event+0xad/0x6b0 rxrpc_input_packet_on_conn+0x1e1/0x210 rxrpc_input_packet+0x3f2/0x4d0 rxrpc_io_thread+0x243/0x410 ? __pfx_rxrpc_io_thread+0x10/0x10 kthread+0xcf/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x24/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53101", "url": "https://ubuntu.com/security/CVE-2024-53101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized value issue in from_kuid and from_kgid ocfs2_setattr() uses attr->ia_mode, attr->ia_uid and attr->ia_gid in a trace point even though ATTR_MODE, ATTR_UID and ATTR_GID aren't set. Initialize all fields of newattrs to avoid uninitialized variables, by checking if ATTR_MODE, ATTR_UID, ATTR_GID are initialized, otherwise 0.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53091", "url": "https://ubuntu.com/security/CVE-2024-53091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Add sk_is_inet and IS_ICSK check in tls_sw_has_ctx_tx/rx As the introduction of the support for vsock and unix sockets in sockmap, tls_sw_has_ctx_tx/rx cannot presume the socket passed in must be IS_ICSK. vsock and af_unix sockets have vsock_sock and unix_sock instead of inet_connection_sock. For these sockets, tls_get_ctx may return an invalid pointer and cause page fault in function tls_sw_ctx_rx. BUG: unable to handle page fault for address: 0000000000040030 Workqueue: vsock-loopback vsock_loopback_work RIP: 0010:sk_psock_strp_data_ready+0x23/0x60 Call Trace: ? __die+0x81/0xc3 ? no_context+0x194/0x350 ? do_page_fault+0x30/0x110 ? async_page_fault+0x3e/0x50 ? sk_psock_strp_data_ready+0x23/0x60 virtio_transport_recv_pkt+0x750/0x800 ? update_load_avg+0x7e/0x620 vsock_loopback_work+0xd0/0x100 process_one_work+0x1a7/0x360 worker_thread+0x30/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x112/0x130 ? __kthread_cancel_work+0x40/0x40 ret_from_fork+0x1f/0x40 v2: - Add IS_ICSK check v3: - Update the commits in Fixes", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53092", "url": "https://ubuntu.com/security/CVE-2024-53092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_pci: Fix admin vq cleanup by using correct info pointer vp_modern_avq_cleanup() and vp_del_vqs() clean up admin vq resources by virtio_pci_vq_info pointer. The info pointer of admin vq is stored in vp_dev->admin_vq.info instead of vp_dev->vqs[]. Using the info pointer from vp_dev->vqs[] for admin vq causes a kernel NULL pointer dereference bug. In vp_modern_avq_cleanup() and vp_del_vqs(), get the info pointer from vp_dev->admin_vq.info for admin vq to clean up the resources. Also make info ptr as argument of vp_del_vq() to be symmetric with vp_setup_vq(). vp_reset calls vp_modern_avq_cleanup, and causes the Call Trace: ================================================================== BUG: kernel NULL pointer dereference, address:0000000000000000 ... CPU: 49 UID: 0 PID: 4439 Comm: modprobe Not tainted 6.11.0-rc5 #1 RIP: 0010:vp_reset+0x57/0x90 [virtio_pci] Call Trace: ... ? vp_reset+0x57/0x90 [virtio_pci] ? vp_reset+0x38/0x90 [virtio_pci] virtio_reset_device+0x1d/0x30 remove_vq_common+0x1c/0x1a0 [virtio_net] virtnet_remove+0xa1/0xc0 [virtio_net] virtio_dev_remove+0x46/0xa0 ... virtio_pci_driver_exit+0x14/0x810 [virtio_pci] ==================================================================", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53102", "url": "https://ubuntu.com/security/CVE-2024-53102", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53093", "url": "https://ubuntu.com/security/CVE-2024-53093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: defer partition scanning We need to suppress the partition scan from occuring within the controller's scan_work context. If a path error occurs here, the IO will wait until a path becomes available or all paths are torn down, but that action also occurs within scan_work, so it would deadlock. Defer the partion scan to a different context that does not block scan_work.", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53094", "url": "https://ubuntu.com/security/CVE-2024-53094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Add sendpage_ok() check to disable MSG_SPLICE_PAGES While running ISER over SIW, the initiator machine encounters a warning from skb_splice_from_iter() indicating that a slab page is being used in send_page. To address this, it is better to add a sendpage_ok() check within the driver itself, and if it returns 0, then MSG_SPLICE_PAGES flag should be disabled before entering the network stack. A similar issue has been discussed for NVMe in this thread: https://lore.kernel.org/all/20240530142417.146696-1-ofir.gal@volumez.com/ WARNING: CPU: 0 PID: 5342 at net/core/skbuff.c:7140 skb_splice_from_iter+0x173/0x320 Call Trace: tcp_sendmsg_locked+0x368/0xe40 siw_tx_hdt+0x695/0xa40 [siw] siw_qp_sq_process+0x102/0xb00 [siw] siw_sq_resume+0x39/0x110 [siw] siw_run_sq+0x74/0x160 [siw] kthread+0xd2/0x100 ret_from_fork+0x34/0x40 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53100", "url": "https://ubuntu.com/security/CVE-2024-53100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: tcp: avoid race between queue_lock lock and destroy Commit 76d54bf20cdc (\"nvme-tcp: don't access released socket during error recovery\") added a mutex_lock() call for the queue->queue_lock in nvme_tcp_get_address(). However, the mutex_lock() races with mutex_destroy() in nvme_tcp_free_queue(), and causes the WARN below. DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: CPU: 3 PID: 34077 at kernel/locking/mutex.c:587 __mutex_lock+0xcf0/0x1220 Modules linked in: nvmet_tcp nvmet nvme_tcp nvme_fabrics iw_cm ib_cm ib_core pktcdvd nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables qrtr sunrpc ppdev 9pnet_virtio 9pnet pcspkr netfs parport_pc parport e1000 i2c_piix4 i2c_smbus loop fuse nfnetlink zram bochs drm_vram_helper drm_ttm_helper ttm drm_kms_helper xfs drm sym53c8xx floppy nvme scsi_transport_spi nvme_core nvme_auth serio_raw ata_generic pata_acpi dm_multipath qemu_fw_cfg [last unloaded: ib_uverbs] CPU: 3 UID: 0 PID: 34077 Comm: udisksd Not tainted 6.11.0-rc7 #319 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:__mutex_lock+0xcf0/0x1220 Code: 08 84 d2 0f 85 c8 04 00 00 8b 15 ef b6 c8 01 85 d2 0f 85 78 f4 ff ff 48 c7 c6 20 93 ee af 48 c7 c7 60 91 ee af e8 f0 a7 6d fd <0f> 0b e9 5e f4 ff ff 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 RSP: 0018:ffff88811305f760 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff88812c652058 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000001 RBP: ffff88811305f8b0 R08: 0000000000000001 R09: ffffed1075c36341 R10: ffff8883ae1b1a0b R11: 0000000000010498 R12: 0000000000000000 R13: 0000000000000000 R14: dffffc0000000000 R15: ffff88812c652058 FS: 00007f9713ae4980(0000) GS:ffff8883ae180000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcd78483c7c CR3: 0000000122c38000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn.cold+0x5b/0x1af ? __mutex_lock+0xcf0/0x1220 ? report_bug+0x1ec/0x390 ? handle_bug+0x3c/0x80 ? exc_invalid_op+0x13/0x40 ? asm_exc_invalid_op+0x16/0x20 ? __mutex_lock+0xcf0/0x1220 ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] ? __pfx___mutex_lock+0x10/0x10 ? __lock_acquire+0xd6a/0x59e0 ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] ? __pfx_nvme_tcp_get_address+0x10/0x10 [nvme_tcp] nvme_sysfs_show_address+0x81/0xc0 [nvme_core] dev_attr_show+0x42/0x80 ? __asan_memset+0x1f/0x40 sysfs_kf_seq_show+0x1f0/0x370 seq_read_iter+0x2cb/0x1130 ? rw_verify_area+0x3b1/0x590 ? __mutex_lock+0x433/0x1220 vfs_read+0x6a6/0xa20 ? lockdep_hardirqs_on+0x78/0x100 ? __pfx_vfs_read+0x10/0x10 ksys_read+0xf7/0x1d0 ? __pfx_ksys_read+0x10/0x10 ? __x64_sys_openat+0x105/0x1d0 do_syscall_64+0x93/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? __pfx_ksys_read+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? do_syscall_64+0x9f/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f9713f55cfa Code: 55 48 89 e5 48 83 ec 20 48 89 55 e8 48 89 75 f0 89 7d f8 e8 e8 74 f8 ff 48 8b 55 e8 48 8b 75 f0 4 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53095", "url": "https://ubuntu.com/security/CVE-2024-53095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix use-after-free of network namespace. Recently, we got a customer report that CIFS triggers oops while reconnecting to a server. [0] The workload runs on Kubernetes, and some pods mount CIFS servers in non-root network namespaces. The problem rarely happened, but it was always while the pod was dying. The root cause is wrong reference counting for network namespace. CIFS uses kernel sockets, which do not hold refcnt of the netns that the socket belongs to. That means CIFS must ensure the socket is always freed before its netns; otherwise, use-after-free happens. The repro steps are roughly: 1. mount CIFS in a non-root netns 2. drop packets from the netns 3. destroy the netns 4. unmount CIFS We can reproduce the issue quickly with the script [1] below and see the splat [2] if CONFIG_NET_NS_REFCNT_TRACKER is enabled. When the socket is TCP, it is hard to guarantee the netns lifetime without holding refcnt due to async timers. Let's hold netns refcnt for each socket as done for SMC in commit 9744d2bf1976 (\"smc: Fix use-after-free in tcp_write_timer_handler().\"). Note that we need to move put_net() from cifs_put_tcp_session() to clean_demultiplex_info(); otherwise, __sock_create() still could touch a freed netns while cifsd tries to reconnect from cifs_demultiplex_thread(). Also, maybe_get_net() cannot be put just before __sock_create() because the code is not under RCU and there is a small chance that the same address happened to be reallocated to another netns. [0]: CIFS: VFS: \\\\XXXXXXXXXXX has not responded in 15 seconds. Reconnecting... CIFS: Serverclose failed 4 times, giving up Unable to handle kernel paging request at virtual address 14de99e461f84a07 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 CM = 0, WnR = 0 [14de99e461f84a07] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: cls_bpf sch_ingress nls_utf8 cifs cifs_arc4 cifs_md4 dns_resolver tcp_diag inet_diag veth xt_state xt_connmark nf_conntrack_netlink xt_nat xt_statistic xt_MASQUERADE xt_mark xt_addrtype ipt_REJECT nf_reject_ipv4 nft_chain_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment nft_compat nf_tables nfnetlink overlay nls_ascii nls_cp437 sunrpc vfat fat aes_ce_blk aes_ce_cipher ghash_ce sm4_ce_cipher sm4 sm3_ce sm3 sha3_ce sha512_ce sha512_arm64 sha1_ce ena button sch_fq_codel loop fuse configfs dmi_sysfs sha2_ce sha256_arm64 dm_mirror dm_region_hash dm_log dm_mod dax efivarfs CPU: 5 PID: 2690970 Comm: cifsd Not tainted 6.1.103-109.184.amzn2023.aarch64 #1 Hardware name: Amazon EC2 r7g.4xlarge/, BIOS 1.0 11/1/2018 pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : fib_rules_lookup+0x44/0x238 lr : __fib_lookup+0x64/0xbc sp : ffff8000265db790 x29: ffff8000265db790 x28: 0000000000000000 x27: 000000000000bd01 x26: 0000000000000000 x25: ffff000b4baf8000 x24: ffff00047b5e4580 x23: ffff8000265db7e0 x22: 0000000000000000 x21: ffff00047b5e4500 x20: ffff0010e3f694f8 x19: 14de99e461f849f7 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 3f92800abd010002 x11: 0000000000000001 x10: ffff0010e3f69420 x9 : ffff800008a6f294 x8 : 0000000000000000 x7 : 0000000000000006 x6 : 0000000000000000 x5 : 0000000000000001 x4 : ffff001924354280 x3 : ffff8000265db7e0 x2 : 0000000000000000 x1 : ffff0010e3f694f8 x0 : ffff00047b5e4500 Call trace: fib_rules_lookup+0x44/0x238 __fib_lookup+0x64/0xbc ip_route_output_key_hash_rcu+0x2c4/0x398 ip_route_output_key_hash+0x60/0x8c tcp_v4_connect+0x290/0x488 __inet_stream_connect+0x108/0x3d0 inet_stream_connect+0x50/0x78 kernel_connect+0x6c/0xac generic_ip_conne ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-50265", "url": "https://ubuntu.com/security/CVE-2024-50265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove() Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove(): [ 57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12 [ 57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry [ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004 [...] [ 57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [...] [ 57.331328] Call Trace: [ 57.331477] [...] [ 57.333511] ? do_user_addr_fault+0x3e5/0x740 [ 57.333778] ? exc_page_fault+0x70/0x170 [ 57.334016] ? asm_exc_page_fault+0x2b/0x30 [ 57.334263] ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10 [ 57.334596] ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [ 57.334913] ocfs2_xa_remove_entry+0x23/0xc0 [ 57.335164] ocfs2_xa_set+0x704/0xcf0 [ 57.335381] ? _raw_spin_unlock+0x1a/0x40 [ 57.335620] ? ocfs2_inode_cache_unlock+0x16/0x20 [ 57.335915] ? trace_preempt_on+0x1e/0x70 [ 57.336153] ? start_this_handle+0x16c/0x500 [ 57.336410] ? preempt_count_sub+0x50/0x80 [ 57.336656] ? _raw_read_unlock+0x20/0x40 [ 57.336906] ? start_this_handle+0x16c/0x500 [ 57.337162] ocfs2_xattr_block_set+0xa6/0x1e0 [ 57.337424] __ocfs2_xattr_set_handle+0x1fd/0x5d0 [ 57.337706] ? ocfs2_start_trans+0x13d/0x290 [ 57.337971] ocfs2_xattr_set+0xb13/0xfb0 [ 57.338207] ? dput+0x46/0x1c0 [ 57.338393] ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338665] ? ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338948] __vfs_removexattr+0x92/0xc0 [ 57.339182] __vfs_removexattr_locked+0xd5/0x190 [ 57.339456] ? preempt_count_sub+0x50/0x80 [ 57.339705] vfs_removexattr+0x5f/0x100 [...] Reproducer uses faultinject facility to fail ocfs2_xa_remove() -> ocfs2_xa_value_truncate() with -ENOMEM. In this case the comment mentions that we can return 0 if ocfs2_xa_cleanup_value_truncate() is going to wipe the entry anyway. But the following 'rc' check is wrong and execution flow do 'ocfs2_xa_remove_entry(loc);' twice: * 1st: in ocfs2_xa_cleanup_value_truncate(); * 2nd: returning back to ocfs2_xa_remove() instead of going to 'out'. Fix this by skipping the 2nd removal of the same entry and making syzkaller repro happy.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50266", "url": "https://ubuntu.com/security/CVE-2024-50266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: qcom: videocc-sm8350: use HW_CTRL_TRIGGER for vcodec GDSCs A recent change in the venus driver results in a stuck clock on the Lenovo ThinkPad X13s, for example, when streaming video in firefox: \tvideo_cc_mvs0_clk status stuck at 'off' \tWARNING: CPU: 6 PID: 2885 at drivers/clk/qcom/clk-branch.c:87 clk_branch_wait+0x144/0x15c \t... \tCall trace: \t clk_branch_wait+0x144/0x15c \t clk_branch2_enable+0x30/0x40 \t clk_core_enable+0xd8/0x29c \t clk_enable+0x2c/0x4c \t vcodec_clks_enable.isra.0+0x94/0xd8 [venus_core] \t coreid_power_v4+0x464/0x628 [venus_core] \t vdec_start_streaming+0xc4/0x510 [venus_dec] \t vb2_start_streaming+0x6c/0x180 [videobuf2_common] \t vb2_core_streamon+0x120/0x1dc [videobuf2_common] \t vb2_streamon+0x1c/0x6c [videobuf2_v4l2] \t v4l2_m2m_ioctl_streamon+0x30/0x80 [v4l2_mem2mem] \t v4l_streamon+0x24/0x30 [videodev] using the out-of-tree sm8350/sc8280xp venus support. [1] Update also the sm8350/sc8280xp GDSC definitions so that the hw control mode can be changed at runtime as the venus driver now requires.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50267", "url": "https://ubuntu.com/security/CVE-2024-50267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: fix use after free in debug printk The \"dev_dbg(&urb->dev->dev, ...\" which happens after usb_free_urb(urb) is a use after free of the \"urb\" pointer. Store the \"dev\" pointer at the start of the function to avoid this issue.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50268", "url": "https://ubuntu.com/security/CVE-2024-50268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: fix potential out of bounds in ucsi_ccg_update_set_new_cam_cmd() The \"*cmd\" variable can be controlled by the user via debugfs. That means \"new_cam\" can be as high as 255 while the size of the uc->updated[] array is UCSI_MAX_ALTMODES (30). The call tree is: ucsi_cmd() // val comes from simple_attr_write_xsigned() -> ucsi_send_command() -> ucsi_send_command_common() -> ucsi_run_command() // calls ucsi->ops->sync_control() -> ucsi_ccg_sync_control()", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53083", "url": "https://ubuntu.com/security/CVE-2024-53083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: qcom-pmic: init value of hdr_len/txbuf_len earlier If the read of USB_PDPHY_RX_ACKNOWLEDGE_REG failed, then hdr_len and txbuf_len are uninitialized. This commit stops to print uninitialized value and misleading/false data.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50269", "url": "https://ubuntu.com/security/CVE-2024-50269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: musb: sunxi: Fix accessing an released usb phy Commit 6ed05c68cbca (\"usb: musb: sunxi: Explicitly release USB PHY on exit\") will cause that usb phy @glue->xceiv is accessed after released. 1) register platform driver @sunxi_musb_driver // get the usb phy @glue->xceiv sunxi_musb_probe() -> devm_usb_get_phy(). 2) register and unregister platform driver @musb_driver musb_probe() -> sunxi_musb_init() use the phy here //the phy is released here musb_remove() -> sunxi_musb_exit() -> devm_usb_put_phy() 3) register @musb_driver again musb_probe() -> sunxi_musb_init() use the phy here but the phy has been released at 2). ... Fixed by reverting the commit, namely, removing devm_usb_put_phy() from sunxi_musb_exit().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53079", "url": "https://ubuntu.com/security/CVE-2024-53079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/thp: fix deferred split unqueue naming and locking Recent changes are putting more pressure on THP deferred split queues: under load revealing long-standing races, causing list_del corruptions, \"Bad page state\"s and worse (I keep BUGs in both of those, so usually don't get to see how badly they end up without). The relevant recent changes being 6.8's mTHP, 6.10's mTHP swapout, and 6.12's mTHP swapin, improved swap allocation, and underused THP splitting. Before fixing locking: rename misleading folio_undo_large_rmappable(), which does not undo large_rmappable, to folio_unqueue_deferred_split(), which is what it does. But that and its out-of-line __callee are mm internals of very limited usability: add comment and WARN_ON_ONCEs to check usage; and return a bool to say if a deferred split was unqueued, which can then be used in WARN_ON_ONCEs around safety checks (sparing callers the arcane conditionals in __folio_unqueue_deferred_split()). Just omit the folio_unqueue_deferred_split() from free_unref_folios(), all of whose callers now call it beforehand (and if any forget then bad_page() will tell) - except for its caller put_pages_list(), which itself no longer has any callers (and will be deleted separately). Swapout: mem_cgroup_swapout() has been resetting folio->memcg_data 0 without checking and unqueueing a THP folio from deferred split list; which is unfortunate, since the split_queue_lock depends on the memcg (when memcg is enabled); so swapout has been unqueueing such THPs later, when freeing the folio, using the pgdat's lock instead: potentially corrupting the memcg's list. __remove_mapping() has frozen refcount to 0 here, so no problem with calling folio_unqueue_deferred_split() before resetting memcg_data. That goes back to 5.4 commit 87eaceb3faa5 (\"mm: thp: make deferred split shrinker memcg aware\"): which included a check on swapcache before adding to deferred queue, but no check on deferred queue before adding THP to swapcache. That worked fine with the usual sequence of events in reclaim (though there were a couple of rare ways in which a THP on deferred queue could have been swapped out), but 6.12 commit dafff3f4c850 (\"mm: split underused THPs\") avoids splitting underused THPs in reclaim, which makes swapcache THPs on deferred queue commonplace. Keep the check on swapcache before adding to deferred queue? Yes: it is no longer essential, but preserves the existing behaviour, and is likely to be a worthwhile optimization (vmstat showed much more traffic on the queue under swapping load if the check was removed); update its comment. Memcg-v1 move (deprecated): mem_cgroup_move_account() has been changing folio->memcg_data without checking and unqueueing a THP folio from the deferred list, sometimes corrupting \"from\" memcg's list, like swapout. Refcount is non-zero here, so folio_unqueue_deferred_split() can only be used in a WARN_ON_ONCE to validate the fix, which must be done earlier: mem_cgroup_move_charge_pte_range() first try to split the THP (splitting of course unqueues), or skip it if that fails. Not ideal, but moving charge has been requested, and khugepaged should repair the THP later: nobody wants new custom unqueueing code just for this deprecated case. The 87eaceb3faa5 commit did have the code to move from one deferred list to another (but was not conscious of its unsafety while refcount non-0); but that was removed by 5.6 commit fac0516b5534 (\"mm: thp: don't need care deferred split queue in memcg charge move path\"), which argued that the existence of a PMD mapping guarantees that the THP cannot be on a deferred list. As above, false in rare cases, and now commonly false. Backport to 6.11 should be straightforward. Earlier backports must take care that other _deferred_list fixes and dependencies are included. There is not a strong case for backports, but they can fix cornercases.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50270", "url": "https://ubuntu.com/security/CVE-2024-50270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: avoid overflow in damon_feed_loop_next_input() damon_feed_loop_next_input() is inefficient and fragile to overflows. Specifically, 'score_goal_diff_bp' calculation can overflow when 'score' is high. The calculation is actually unnecessary at all because 'goal' is a constant of value 10,000. Calculation of 'compensation' is again fragile to overflow. Final calculation of return value for under-achiving case is again fragile to overflow when the current score is under-achieving the target. Add two corner cases handling at the beginning of the function to make the body easier to read, and rewrite the body of the function to avoid overflows and the unnecessary bp value calcuation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50271", "url": "https://ubuntu.com/security/CVE-2024-50271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: signal: restore the override_rlimit logic Prior to commit d64696905554 (\"Reimplement RLIMIT_SIGPENDING on top of ucounts\") UCOUNT_RLIMIT_SIGPENDING rlimit was not enforced for a class of signals. However now it's enforced unconditionally, even if override_rlimit is set. This behavior change caused production issues. For example, if the limit is reached and a process receives a SIGSEGV signal, sigqueue_alloc fails to allocate the necessary resources for the signal delivery, preventing the signal from being delivered with siginfo. This prevents the process from correctly identifying the fault address and handling the error. From the user-space perspective, applications are unaware that the limit has been reached and that the siginfo is effectively 'corrupted'. This can lead to unpredictable behavior and crashes, as we observed with java applications. Fix this by passing override_rlimit into inc_rlimit_get_ucounts() and skip the comparison to max there if override_rlimit is set. This effectively restores the old behavior.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50272", "url": "https://ubuntu.com/security/CVE-2024-50272", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: filemap: Fix bounds checking in filemap_read() If the caller supplies an iocb->ki_pos value that is close to the filesystem upper limit, and an iterator with a count that causes us to overflow that limit, then filemap_read() enters an infinite loop. This behaviour was discovered when testing xfstests generic/525 with the \"localio\" optimisation for loopback NFS mounts.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53104", "url": "https://ubuntu.com/security/CVE-2024-53104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_parse_format This can lead to out of bounds writes since frames of this type were not taken into account when calculating the size of the frames buffer in uvc_parse_streaming.", "cve_priority": "high", "cve_public_date": "2024-12-02 08:15:00 UTC" }, { "cve": "CVE-2024-50273", "url": "https://ubuntu.com/security/CVE-2024-50273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reinitialize delayed ref list after deleting it from the list At insert_delayed_ref() if we need to update the action of an existing ref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head's ref_add_list using list_del(), which leaves the ref's add_list member not reinitialized, as list_del() sets the next and prev members of the list to LIST_POISON1 and LIST_POISON2, respectively. If later we end up calling drop_delayed_ref() against the ref, which can happen during merging or when destroying delayed refs due to a transaction abort, we can trigger a crash since at drop_delayed_ref() we call list_empty() against the ref's add_list, which returns false since the list was not reinitialized after the list_del() and as a consequence we call list_del() again at drop_delayed_ref(). This results in an invalid list access since the next and prev members are set to poison pointers, resulting in a splat if CONFIG_LIST_HARDENED and CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences otherwise. So fix this by deleting from the list with list_del_init() instead.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53064", "url": "https://ubuntu.com/security/CVE-2024-53064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix idpf_vc_core_init error path In an event where the platform running the device control plane is rebooted, reset is detected on the driver. It releases all the resources and waits for the reset to complete. Once the reset is done, it tries to build the resources back. At this time if the device control plane is not yet started, then the driver timeouts on the virtchnl message and retries to establish the mailbox again. In the retry flow, mailbox is deinitialized but the mailbox workqueue is still alive and polling for the mailbox message. This results in accessing the released control queue leading to null-ptr-deref. Fix it by unrolling the work queue cancellation and mailbox deinitialization in the reverse order which they got initialized.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50274", "url": "https://ubuntu.com/security/CVE-2024-50274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: avoid vport access in idpf_get_link_ksettings When the device control plane is removed or the platform running device control plane is rebooted, a reset is detected on the driver. On driver reset, it releases the resources and waits for the reset to complete. If the reset fails, it takes the error path and releases the vport lock. At this time if the monitoring tools tries to access link settings, it call traces for accessing released vport pointer. To avoid it, move link_speed_mbps to netdev_priv structure which removes the dependency on vport pointer and the vport lock in idpf_get_link_ksettings. Also use netif_carrier_ok() to check the link status and adjust the offsetof to use link_up instead of link_speed_mbps.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53065", "url": "https://ubuntu.com/security/CVE-2024-53065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/slab: fix warning caused by duplicate kmem_cache creation in kmem_buckets_create Commit b035f5a6d852 (\"mm: slab: reduce the kmalloc() minimum alignment if DMA bouncing possible\") reduced ARCH_KMALLOC_MINALIGN to 8 on arm64. However, with KASAN_HW_TAGS enabled, arch_slab_minalign() becomes 16. This causes kmalloc_caches[*][8] to be aliased to kmalloc_caches[*][16], resulting in kmem_buckets_create() attempting to create a kmem_cache for size 16 twice. This duplication triggers warnings on boot: [ 2.325108] ------------[ cut here ]------------ [ 2.325135] kmem_cache of name 'memdup_user-16' already exists [ 2.325783] WARNING: CPU: 0 PID: 1 at mm/slab_common.c:107 __kmem_cache_create_args+0xb8/0x3b0 [ 2.327957] Modules linked in: [ 2.328550] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5mm-unstable-arm64+ #12 [ 2.328683] Hardware name: QEMU QEMU Virtual Machine, BIOS 2024.02-2 03/11/2024 [ 2.328790] pstate: 61000009 (nZCv daif -PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 2.328911] pc : __kmem_cache_create_args+0xb8/0x3b0 [ 2.328930] lr : __kmem_cache_create_args+0xb8/0x3b0 [ 2.328942] sp : ffff800083d6fc50 [ 2.328961] x29: ffff800083d6fc50 x28: f2ff0000c1674410 x27: ffff8000820b0598 [ 2.329061] x26: 000000007fffffff x25: 0000000000000010 x24: 0000000000002000 [ 2.329101] x23: ffff800083d6fce8 x22: ffff8000832222e8 x21: ffff800083222388 [ 2.329118] x20: f2ff0000c1674410 x19: f5ff0000c16364c0 x18: ffff800083d80030 [ 2.329135] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 2.329152] x14: 0000000000000000 x13: 0a73747369786520 x12: 79646165726c6120 [ 2.329169] x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : 0000000000000000 [ 2.329194] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 [ 2.329210] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 2.329226] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 2.329291] Call trace: [ 2.329407] __kmem_cache_create_args+0xb8/0x3b0 [ 2.329499] kmem_buckets_create+0xfc/0x320 [ 2.329526] init_user_buckets+0x34/0x78 [ 2.329540] do_one_initcall+0x64/0x3c8 [ 2.329550] kernel_init_freeable+0x26c/0x578 [ 2.329562] kernel_init+0x3c/0x258 [ 2.329574] ret_from_fork+0x10/0x20 [ 2.329698] ---[ end trace 0000000000000000 ]--- [ 2.403704] ------------[ cut here ]------------ [ 2.404716] kmem_cache of name 'msg_msg-16' already exists [ 2.404801] WARNING: CPU: 2 PID: 1 at mm/slab_common.c:107 __kmem_cache_create_args+0xb8/0x3b0 [ 2.404842] Modules linked in: [ 2.404971] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.12.0-rc5mm-unstable-arm64+ #12 [ 2.405026] Tainted: [W]=WARN [ 2.405043] Hardware name: QEMU QEMU Virtual Machine, BIOS 2024.02-2 03/11/2024 [ 2.405057] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2.405079] pc : __kmem_cache_create_args+0xb8/0x3b0 [ 2.405100] lr : __kmem_cache_create_args+0xb8/0x3b0 [ 2.405111] sp : ffff800083d6fc50 [ 2.405115] x29: ffff800083d6fc50 x28: fbff0000c1674410 x27: ffff8000820b0598 [ 2.405135] x26: 000000000000ffd0 x25: 0000000000000010 x24: 0000000000006000 [ 2.405153] x23: ffff800083d6fce8 x22: ffff8000832222e8 x21: ffff800083222388 [ 2.405169] x20: fbff0000c1674410 x19: fdff0000c163d6c0 x18: ffff800083d80030 [ 2.405185] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 2.405201] x14: 0000000000000000 x13: 0a73747369786520 x12: 79646165726c6120 [ 2.405217] x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : 0000000000000000 [ 2.405233] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 [ 2.405248] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 2.405271] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 2.405287] Call trace: [ 2 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50275", "url": "https://ubuntu.com/security/CVE-2024-50275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64/sve: Discard stale CPU state when handling SVE traps The logic for handling SVE traps manipulates saved FPSIMD/SVE state incorrectly, and a race with preemption can result in a task having TIF_SVE set and TIF_FOREIGN_FPSTATE clear even though the live CPU state is stale (e.g. with SVE traps enabled). This has been observed to result in warnings from do_sve_acc() where SVE traps are not expected while TIF_SVE is set: | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* SVE access shouldn't have trapped */ Warnings of this form have been reported intermittently, e.g. https://lore.kernel.org/linux-arm-kernel/CA+G9fYtEGe_DhY2Ms7+L7NKsLYUomGsgqpdBj+QwDLeSg=JhGg@mail.gmail.com/ https://lore.kernel.org/linux-arm-kernel/000000000000511e9a060ce5a45c@google.com/ The race can occur when the SVE trap handler is preempted before and after manipulating the saved FPSIMD/SVE state, starting and ending on the same CPU, e.g. | void do_sve_acc(unsigned long esr, struct pt_regs *regs) | { | // Trap on CPU 0 with TIF_SVE clear, SVE 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(); | | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* SVE access shouldn't have trapped */ | | sve_init_regs() { | if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) { | ... | } else { | fpsimd_to_sve(current); | current->thread.fp_type = FP_STATE_SVE; | } | } | | 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 SVE 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.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50276", "url": "https://ubuntu.com/security/CVE-2024-50276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: vertexcom: mse102x: Fix possible double free of TX skb The scope of the TX skb is wider than just mse102x_tx_frame_spi(), so in case the TX skb room needs to be expanded, we should free the the temporary skb instead of the original skb. Otherwise the original TX skb pointer would be freed again in mse102x_tx_work(), which leads to crashes: Internal error: Oops: 0000000096000004 [#2] PREEMPT SMP CPU: 0 PID: 712 Comm: kworker/0:1 Tainted: G D 6.6.23 Hardware name: chargebyte Charge SOM DC-ONE (DT) Workqueue: events mse102x_tx_work [mse102x] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_release_data+0xb8/0x1d8 lr : skb_release_data+0x1ac/0x1d8 sp : ffff8000819a3cc0 x29: ffff8000819a3cc0 x28: ffff0000046daa60 x27: ffff0000057f2dc0 x26: ffff000005386c00 x25: 0000000000000002 x24: 00000000ffffffff x23: 0000000000000000 x22: 0000000000000001 x21: ffff0000057f2e50 x20: 0000000000000006 x19: 0000000000000000 x18: ffff00003fdacfcc x17: e69ad452d0c49def x16: 84a005feff870102 x15: 0000000000000000 x14: 000000000000024a x13: 0000000000000002 x12: 0000000000000000 x11: 0000000000000400 x10: 0000000000000930 x9 : ffff00003fd913e8 x8 : fffffc00001bc008 x7 : 0000000000000000 x6 : 0000000000000008 x5 : ffff00003fd91340 x4 : 0000000000000000 x3 : 0000000000000009 x2 : 00000000fffffffe x1 : 0000000000000000 x0 : 0000000000000000 Call trace: skb_release_data+0xb8/0x1d8 kfree_skb_reason+0x48/0xb0 mse102x_tx_work+0x164/0x35c [mse102x] process_one_work+0x138/0x260 worker_thread+0x32c/0x438 kthread+0x118/0x11c ret_from_fork+0x10/0x20 Code: aa1303e0 97fffab6 72001c1f 54000141 (f9400660)", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53066", "url": "https://ubuntu.com/security/CVE-2024-53066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfs: Fix KMSAN warning in decode_getfattr_attrs() Fix the following KMSAN warning: CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G B Tainted: [B]=BAD_PAGE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) ===================================================== ===================================================== BUG: KMSAN: uninit-value in decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_generic+0x806/0xb00 nfs4_xdr_dec_getattr+0x1de/0x240 rpcauth_unwrap_resp_decode+0xab/0x100 rpcauth_unwrap_resp+0x95/0xc0 call_decode+0x4ff/0xb50 __rpc_execute+0x57b/0x19d0 rpc_execute+0x368/0x5e0 rpc_run_task+0xcfe/0xee0 nfs4_proc_getattr+0x5b5/0x990 __nfs_revalidate_inode+0x477/0xd00 nfs_access_get_cached+0x1021/0x1cc0 nfs_do_access+0x9f/0xae0 nfs_permission+0x1e4/0x8c0 inode_permission+0x356/0x6c0 link_path_walk+0x958/0x1330 path_lookupat+0xce/0x6b0 filename_lookup+0x23e/0x770 vfs_statx+0xe7/0x970 vfs_fstatat+0x1f2/0x2c0 __se_sys_newfstatat+0x67/0x880 __x64_sys_newfstatat+0xbd/0x120 x64_sys_call+0x1826/0x3cf0 do_syscall_64+0xd0/0x1b0 entry_SYSCALL_64_after_hwframe+0x77/0x7f The KMSAN warning is triggered in decode_getfattr_attrs(), when calling decode_attr_mdsthreshold(). It appears that fattr->mdsthreshold is not initialized. Fix the issue by initializing fattr->mdsthreshold to NULL in nfs_fattr_init().", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53067", "url": "https://ubuntu.com/security/CVE-2024-53067", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Start the RTC update work later The RTC update work involves runtime resuming the UFS controller. Hence, only start the RTC update work after runtime power management in the UFS driver has been fully initialized. This patch fixes the following kernel crash: Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP Workqueue: events ufshcd_rtc_work Call trace: _raw_spin_lock_irqsave+0x34/0x8c (P) pm_runtime_get_if_active+0x24/0x9c (L) pm_runtime_get_if_active+0x24/0x9c ufshcd_rtc_work+0x138/0x1b4 process_one_work+0x148/0x288 worker_thread+0x2cc/0x3d4 kthread+0x110/0x114 ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50277", "url": "https://ubuntu.com/security/CVE-2024-50277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: fix a crash if blk_alloc_disk fails If blk_alloc_disk fails, the variable md->disk is set to an error value. cleanup_mapped_device will see that md->disk is non-NULL and it will attempt to access it, causing a crash on this statement \"md->disk->private_data = NULL;\".", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50278", "url": "https://ubuntu.com/security/CVE-2024-50278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix potential out-of-bounds access on the first resume Out-of-bounds access occurs if the fast device is expanded unexpectedly before the first-time resume of the cache table. This happens because expanding the fast device requires reloading the cache table for cache_create to allocate new in-core data structures that fit the new size, and the check in cache_preresume is not performed during the first resume, leading to the issue. Reproduce steps: 1. prepare component devices: 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\" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct 2. load a cache table of 512 cache blocks, and deliberately expand the fast device before resuming the cache, making the in-core data structures inadequate. dmsetup create cache --notable dmsetup reload cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" dmsetup reload cdata --table \"0 131072 linear /dev/sdc 8192\" dmsetup resume cdata dmsetup resume cache 3. suspend the cache to write out the in-core dirty bitset and hint array, leading to out-of-bounds access to the dirty bitset at offset 0x40: dmsetup suspend cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80 Read of size 8 at addr ffffc90000085040 by task dmsetup/90 (...snip...) The buggy address belongs to the virtual mapping at [ffffc90000085000, ffffc90000087000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by checking the size change on the first resume.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50279", "url": "https://ubuntu.com/security/CVE-2024-50279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix out-of-bounds access to the dirty bitset when resizing dm-cache checks the dirty bits of the cache blocks to be dropped when shrinking the fast device, but an index bug in bitset iteration causes out-of-bounds access. Reproduce steps: 1. create a cache device of 1024 cache blocks (128 bytes dirty bitset) dmsetup create cmeta --table \"0 8192 linear /dev/sdc 0\" dmsetup create cdata --table \"0 131072 linear /dev/sdc 8192\" dmsetup create corig --table \"0 524288 linear /dev/sdc 262144\" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" 2. shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80) dmsetup suspend cache dmsetup reload cdata --table \"0 65536 linear /dev/sdc 8192\" dmsetup resume cdata dmsetup resume cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131 (...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by making the index post-incremented.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50280", "url": "https://ubuntu.com/security/CVE-2024-50280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix flushing uninitialized delayed_work on cache_ctr error An unexpected WARN_ON from flush_work() may occur when cache creation fails, caused by destroying the uninitialized delayed_work waker in the error path of cache_create(). For example, the warning appears on the superblock checksum error. Reproduce steps: 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\" dd if=/dev/urandom of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" Kernel logs: (snip) WARNING: CPU: 0 PID: 84 at kernel/workqueue.c:4178 __flush_work+0x5d4/0x890 Fix by pulling out the cancel_delayed_work_sync() from the constructor's error path. This patch doesn't affect the use-after-free fix for concurrent dm_resume and dm_destroy (commit 6a459d8edbdb (\"dm cache: Fix UAF in destroy()\")) as cache_dtr is not changed.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50281", "url": "https://ubuntu.com/security/CVE-2024-50281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: trusted: dcp: fix NULL dereference in AEAD crypto operation When sealing or unsealing a key blob we currently do not wait for the AEAD cipher operation to finish and simply return after submitting the request. If there is some load on the system we can exit before the cipher operation is done and the buffer we read from/write to is already removed from the stack. This will e.g. result in NULL pointer dereference errors in the DCP driver during blob creation. Fix this by waiting for the AEAD cipher operation to finish before resuming the seal and unseal calls.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50282", "url": "https://ubuntu.com/security/CVE-2024-50282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read() Avoid a possible buffer overflow if size is larger than 4K. (cherry picked from commit f5d873f5825b40d886d03bd2aede91d4cf002434)", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53071", "url": "https://ubuntu.com/security/CVE-2024-53071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Be stricter about IO mapping flags The current panthor_device_mmap_io() implementation has two issues: 1. For mapping DRM_PANTHOR_USER_FLUSH_ID_MMIO_OFFSET, panthor_device_mmap_io() bails if VM_WRITE is set, but does not clear VM_MAYWRITE. That means userspace can use mprotect() to make the mapping writable later on. This is a classic Linux driver gotcha. I don't think this actually has any impact in practice: When the GPU is powered, writes to the FLUSH_ID seem to be ignored; and when the GPU is not powered, the dummy_latest_flush page provided by the driver is deliberately designed to not do any flushes, so the only thing writing to the dummy_latest_flush could achieve would be to make *more* flushes happen. 2. panthor_device_mmap_io() does not block MAP_PRIVATE mappings (which are mappings without the VM_SHARED flag). MAP_PRIVATE in combination with VM_MAYWRITE indicates that the VMA has copy-on-write semantics, which for VM_PFNMAP are semi-supported but fairly cursed. In particular, in such a mapping, the driver can only install PTEs during mmap() by calling remap_pfn_range() (because remap_pfn_range() wants to **store the physical address of the mapped physical memory into the vm_pgoff of the VMA**); installing PTEs later on with a fault handler (as panthor does) is not supported in private mappings, and so if you try to fault in such a mapping, vmf_insert_pfn_prot() splats when it hits a BUG() check. Fix it by clearing the VM_MAYWRITE flag (userspace writing to the FLUSH_ID doesn't make sense) and requiring VM_SHARED (copy-on-write semantics for the FLUSH_ID don't make sense). Reproducers for both scenarios are in the notes of my patch on the mailing list; I tested that these bugs exist on a Rock 5B machine. Note that I only compile-tested the patch, I haven't tested it; I don't have a working kernel build setup for the test machine yet. Please test it before applying it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53080", "url": "https://ubuntu.com/security/CVE-2024-53080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Lock XArray when getting entries for the VM Similar to commit cac075706f29 (\"drm/panthor: Fix race when converting group handle to group object\") we need to use the XArray's internal locking when retrieving a vm pointer from there. v2: Removed part of the patch that was trying to protect fetching the heap pointer from XArray, as that operation is protected by the @pool->lock.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53084", "url": "https://ubuntu.com/security/CVE-2024-53084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Break an object reference loop When remaining resources are being cleaned up on driver close, outstanding VM mappings may result in resources being leaked, due to an object reference loop, as shown below, with each object (or set of objects) referencing the object below it: PVR GEM Object GPU scheduler \"finished\" fence GPU scheduler “scheduled” fence PVR driver “done” fence PVR Context PVR VM Context PVR VM Mappings PVR GEM Object The reference that the PVR VM Context has on the VM mappings is a soft one, in the sense that the freeing of outstanding VM mappings is done as part of VM context destruction; no reference counts are involved, as is the case for all the other references in the loop. To break the reference loop during cleanup, free the outstanding VM mappings before destroying the PVR Context associated with the VM context.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53085", "url": "https://ubuntu.com/security/CVE-2024-53085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: Lock TPM chip in tpm_pm_suspend() first Setting TPM_CHIP_FLAG_SUSPENDED in the end of tpm_pm_suspend() can be racy according, as this leaves window for tpm_hwrng_read() to be called while the operation is in progress. The recent bug report gives also evidence of this behaviour. Aadress this by locking the TPM chip before checking any chip->flags both in tpm_pm_suspend() and tpm_hwrng_read(). Move TPM_CHIP_FLAG_SUSPENDED check inside tpm_get_random() so that it will be always checked only when the lock is reserved.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53086", "url": "https://ubuntu.com/security/CVE-2024-53086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Drop VM dma-resv lock on xe_sync_in_fence_get failure in exec IOCTL Upon failure all locks need to be dropped before returning to the user. (cherry picked from commit 7d1a4258e602ffdce529f56686925034c1b3b095)", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53087", "url": "https://ubuntu.com/security/CVE-2024-53087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix possible exec queue leak in exec IOCTL In a couple of places after an exec queue is looked up the exec IOCTL returns on input errors without dropping the exec queue ref. Fix this ensuring the exec queue ref is dropped on input error. (cherry picked from commit 07064a200b40ac2195cb6b7b779897d9377e5e6f)", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50283", "url": "https://ubuntu.com/security/CVE-2024-50283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-use-after-free in smb3_preauth_hash_rsp ksmbd_user_session_put should be called under smb3_preauth_hash_rsp(). It will avoid freeing session before calling smb3_preauth_hash_rsp().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50284", "url": "https://ubuntu.com/security/CVE-2024-50284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix the missing xa_store error check xa_store() can fail, it return xa_err(-EINVAL) if the entry cannot be stored in an XArray, or xa_err(-ENOMEM) if memory allocation failed, so check error for xa_store() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50285", "url": "https://ubuntu.com/security/CVE-2024-50285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: check outstanding simultaneous SMB operations If Client send simultaneous SMB operations to ksmbd, It exhausts too much memory through the \"ksmbd_work_cache”. It will cause OOM issue. ksmbd has a credit mechanism but it can't handle this problem. This patch add the check if it exceeds max credits to prevent this problem by assuming that one smb request consumes at least one credit.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50286", "url": "https://ubuntu.com/security/CVE-2024-50286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-use-after-free in ksmbd_smb2_session_create There is a race condition between ksmbd_smb2_session_create and ksmbd_expire_session. This patch add missing sessions_table_lock while adding/deleting session from global session table.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50287", "url": "https://ubuntu.com/security/CVE-2024-50287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-tpg: prevent the risk of a division by zero As reported by Coverity, the logic at tpg_precalculate_line() blindly rescales the buffer even when scaled_witdh is equal to zero. If this ever happens, this will cause a division by zero. Instead, add a WARN_ON_ONCE() to trigger such cases and return without doing any precalculation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50288", "url": "https://ubuntu.com/security/CVE-2024-50288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: fix buffer overwrite when using > 32 buffers The maximum number of buffers that can be requested was increased to 64 for the video capture queue. But video capture used a must_blank array that was still sized for 32 (VIDEO_MAX_FRAME). This caused an out-of-bounds write when using buffer indices >= 32. Create a new define MAX_VID_CAP_BUFFERS that is used to access the must_blank array and set max_num_buffers for the video capture queue. This solves a crash reported by: \thttps://bugzilla.kernel.org/show_bug.cgi?id=219258", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50289", "url": "https://ubuntu.com/security/CVE-2024-50289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: av7110: fix a spectre vulnerability As warned by smatch: \tdrivers/staging/media/av7110/av7110_ca.c:270 dvb_ca_ioctl() warn: potential spectre issue 'av7110->ci_slot' [w] (local cap) There is a spectre-related vulnerability at the code. Fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50290", "url": "https://ubuntu.com/security/CVE-2024-50290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx24116: prevent overflows on SNR calculus as reported by Coverity, if reading SNR registers fail, a negative number will be returned, causing an underflow when reading SNR registers. Prevent that.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53061", "url": "https://ubuntu.com/security/CVE-2024-53061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: s5p-jpeg: prevent buffer overflows The current logic allows word to be less than 2. If this happens, there will be buffer overflows, as reported by smatch. Add extra checks to prevent it. While here, remove an unused word = 0 assignment.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53081", "url": "https://ubuntu.com/security/CVE-2024-53081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ar0521: don't overflow when checking PLL values The PLL checks are comparing 64 bit integers with 32 bit ones, as reported by Coverity. Depending on the values of the variables, this may underflow. Fix it ensuring that both sides of the expression are u64.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53062", "url": "https://ubuntu.com/security/CVE-2024-53062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mgb4: protect driver against spectre Frequency range is set from sysfs via frequency_range_store(), being vulnerable to spectre, as reported by smatch: \tdrivers/media/pci/mgb4/mgb4_cmt.c:231 mgb4_cmt_set_vin_freq_range() warn: potential spectre issue 'cmt_vals_in' [r] \tdrivers/media/pci/mgb4/mgb4_cmt.c:238 mgb4_cmt_set_vin_freq_range() warn: possible spectre second half. 'reg_set' Fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50291", "url": "https://ubuntu.com/security/CVE-2024-50291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvb-core: add missing buffer index check dvb_vb2_expbuf() didn't check if the given buffer index was for a valid buffer. Add this check.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50292", "url": "https://ubuntu.com/security/CVE-2024-50292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: stm32: spdifrx: fix dma channel release in stm32_spdifrx_remove In case of error when requesting ctrl_chan DMA channel, ctrl_chan is not null. So the release of the dma channel leads to the following issue: [ 4.879000] st,stm32-spdifrx 500d0000.audio-controller: dma_request_slave_channel error -19 [ 4.888975] Unable to handle kernel NULL pointer dereference at virtual address 000000000000003d [...] [ 5.096577] Call trace: [ 5.099099] dma_release_channel+0x24/0x100 [ 5.103235] stm32_spdifrx_remove+0x24/0x60 [snd_soc_stm32_spdifrx] [ 5.109494] stm32_spdifrx_probe+0x320/0x4c4 [snd_soc_stm32_spdifrx] To avoid this issue, release channel only if the pointer is valid.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53063", "url": "https://ubuntu.com/security/CVE-2024-53063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvbdev: prevent the risk of out of memory access The dvbdev contains a static variable used to store dvb minors. The behavior of it depends if CONFIG_DVB_DYNAMIC_MINORS is set or not. When not set, dvb_register_device() won't check for boundaries, as it will rely that a previous call to dvb_register_adapter() would already be enforcing it. On a similar way, dvb_device_open() uses the assumption that the register functions already did the needed checks. This can be fragile if some device ends using different calls. This also generate warnings on static check analysers like Coverity. So, add explicit guards to prevent potential risk of OOM issues.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50293", "url": "https://ubuntu.com/security/CVE-2024-50293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: do not leave a dangling sk pointer in __smc_create() Thanks to commit 4bbd360a5084 (\"socket: Print pf->create() when it does not clear sock->sk on failure.\"), syzbot found an issue with AF_SMC: smc_create must clear sock->sk on failure, family: 43, type: 1, protocol: 0 WARNING: CPU: 0 PID: 5827 at net/socket.c:1565 __sock_create+0x96f/0xa30 net/socket.c:1563 Modules linked in: CPU: 0 UID: 0 PID: 5827 Comm: syz-executor259 Not tainted 6.12.0-rc6-next-20241106-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:__sock_create+0x96f/0xa30 net/socket.c:1563 Code: 03 00 74 08 4c 89 e7 e8 4f 3b 85 f8 49 8b 34 24 48 c7 c7 40 89 0c 8d 8b 54 24 04 8b 4c 24 0c 44 8b 44 24 08 e8 32 78 db f7 90 <0f> 0b 90 90 e9 d3 fd ff ff 89 e9 80 e1 07 fe c1 38 c1 0f 8c ee f7 RSP: 0018:ffffc90003e4fda0 EFLAGS: 00010246 RAX: 099c6f938c7f4700 RBX: 1ffffffff1a595fd RCX: ffff888034823c00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 00000000ffffffe9 R08: ffffffff81567052 R09: 1ffff920007c9f50 R10: dffffc0000000000 R11: fffff520007c9f51 R12: ffffffff8d2cafe8 R13: 1ffffffff1a595fe R14: ffffffff9a789c40 R15: ffff8880764298c0 FS: 000055557b518380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa62ff43225 CR3: 0000000031628000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: sock_create net/socket.c:1616 [inline] __sys_socket_create net/socket.c:1653 [inline] __sys_socket+0x150/0x3c0 net/socket.c:1700 __do_sys_socket net/socket.c:1714 [inline] __se_sys_socket net/socket.c:1712 [inline] For reference, see commit 2d859aff775d (\"Merge branch 'do-not-leave-dangling-sk-pointers-in-pf-create-functions'\")", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50294", "url": "https://ubuntu.com/security/CVE-2024-50294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix missing locking causing hanging calls If a call gets aborted (e.g. because kafs saw a signal) between it being queued for connection and the I/O thread picking up the call, the abort will be prioritised over the connection and it will be removed from local->new_client_calls by rxrpc_disconnect_client_call() without a lock being held. This may cause other calls on the list to disappear if a race occurs. Fix this by taking the client_call_lock when removing a call from whatever list its ->wait_link happens to be on.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50295", "url": "https://ubuntu.com/security/CVE-2024-50295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: arc: fix the device for dma_map_single/dma_unmap_single The ndev->dev and pdev->dev aren't the same device, use ndev->dev.parent which has dma_mask, ndev->dev.parent is just pdev->dev. Or it would cause the following issue: [ 39.933526] ------------[ cut here ]------------ [ 39.938414] WARNING: CPU: 1 PID: 501 at kernel/dma/mapping.c:149 dma_map_page_attrs+0x90/0x1f8", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53082", "url": "https://ubuntu.com/security/CVE-2024-53082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_net: Add hash_key_length check Add hash_key_length check in virtnet_probe() to avoid possible out of bound errors when setting/reading the hash key.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50296", "url": "https://ubuntu.com/security/CVE-2024-50296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash when uninstalling driver When the driver is uninstalled and the VF is disabled concurrently, a kernel crash occurs. The reason is that the two actions call function pci_disable_sriov(). The num_VFs is checked to determine whether to release the corresponding resources. During the second calling, num_VFs is not 0 and the resource release function is called. However, the corresponding resource has been released during the first invoking. Therefore, the problem occurs: [15277.839633][T50670] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ... [15278.131557][T50670] Call trace: [15278.134686][T50670] klist_put+0x28/0x12c [15278.138682][T50670] klist_del+0x14/0x20 [15278.142592][T50670] device_del+0xbc/0x3c0 [15278.146676][T50670] pci_remove_bus_device+0x84/0x120 [15278.151714][T50670] pci_stop_and_remove_bus_device+0x6c/0x80 [15278.157447][T50670] pci_iov_remove_virtfn+0xb4/0x12c [15278.162485][T50670] sriov_disable+0x50/0x11c [15278.166829][T50670] pci_disable_sriov+0x24/0x30 [15278.171433][T50670] hnae3_unregister_ae_algo_prepare+0x60/0x90 [hnae3] [15278.178039][T50670] hclge_exit+0x28/0xd0 [hclge] [15278.182730][T50670] __se_sys_delete_module.isra.0+0x164/0x230 [15278.188550][T50670] __arm64_sys_delete_module+0x1c/0x30 [15278.193848][T50670] invoke_syscall+0x50/0x11c [15278.198278][T50670] el0_svc_common.constprop.0+0x158/0x164 [15278.203837][T50670] do_el0_svc+0x34/0xcc [15278.207834][T50670] el0_svc+0x20/0x30 For details, see the following figure. rmmod hclge disable VFs ---------------------------------------------------- hclge_exit() sriov_numvfs_store() ... device_lock() pci_disable_sriov() hns3_pci_sriov_configure() pci_disable_sriov() sriov_disable() sriov_disable() if !num_VFs : if !num_VFs : return; return; sriov_del_vfs() sriov_del_vfs() ... ... klist_put() klist_put() ... ... num_VFs = 0; num_VFs = 0; device_unlock(); In this patch, when driver is removing, we get the device_lock() to protect num_VFs, just like sriov_numvfs_store().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53088", "url": "https://ubuntu.com/security/CVE-2024-53088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: fix race condition by adding filter's intermediate sync state Fix a race condition in the i40e driver that leads to MAC/VLAN filters becoming corrupted and leaking. Address the issue that occurs under heavy load when multiple threads are concurrently modifying MAC/VLAN filters by setting mac and port VLAN. 1. Thread T0 allocates a filter in i40e_add_filter() within i40e_ndo_set_vf_port_vlan(). 2. Thread T1 concurrently frees the filter in __i40e_del_filter() within i40e_ndo_set_vf_mac(). 3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which refers to the already freed filter memory, causing corruption. Reproduction steps: 1. Spawn multiple VFs. 2. Apply a concurrent heavy load by running parallel operations to change MAC addresses on the VFs and change port VLANs on the host. 3. Observe errors in dmesg: \"Error I40E_AQ_RC_ENOSPC adding RX filters on VF XX, \tplease set promiscuous on manually for VF XX\". Exact code for stable reproduction Intel can't open-source now. The fix involves implementing a new intermediate filter state, I40E_FILTER_NEW_SYNC, for the time when a filter is on a tmp_add_list. These filters cannot be deleted from the hash list directly but must be removed using the full process.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50297", "url": "https://ubuntu.com/security/CVE-2024-50297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: xilinx: axienet: Enqueue Tx packets in dql before dmaengine starts Enqueue packets in dql after dma engine starts causes race condition. Tx transfer starts once dma engine is started and may execute dql dequeue in completion before it gets queued. It results in following kernel crash while running iperf stress test: kernel BUG at lib/dynamic_queue_limits.c:99! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP pc : dql_completed+0x238/0x248 lr : dql_completed+0x3c/0x248 Call trace: dql_completed+0x238/0x248 axienet_dma_tx_cb+0xa0/0x170 xilinx_dma_do_tasklet+0xdc/0x290 tasklet_action_common+0xf8/0x11c tasklet_action+0x30/0x3c handle_softirqs+0xf8/0x230 Start dmaengine after enqueue in dql fixes the crash.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50298", "url": "https://ubuntu.com/security/CVE-2024-50298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: enetc: allocate vf_state during PF probes In the previous implementation, vf_state is allocated memory only when VF is enabled. However, net_device_ops::ndo_set_vf_mac() may be called before VF is enabled to configure the MAC address of VF. If this is the case, enetc_pf_set_vf_mac() will access vf_state, resulting in access to a null pointer. The simplified error log is as follows. root@ls1028ardb:~# ip link set eno0 vf 1 mac 00:0c:e7:66:77:89 [ 173.543315] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 [ 173.637254] pc : enetc_pf_set_vf_mac+0x3c/0x80 Message from sy [ 173.641973] lr : do_setlink+0x4a8/0xec8 [ 173.732292] Call trace: [ 173.734740] enetc_pf_set_vf_mac+0x3c/0x80 [ 173.738847] __rtnl_newlink+0x530/0x89c [ 173.742692] rtnl_newlink+0x50/0x7c [ 173.746189] rtnetlink_rcv_msg+0x128/0x390 [ 173.750298] netlink_rcv_skb+0x60/0x130 [ 173.754145] rtnetlink_rcv+0x18/0x24 [ 173.757731] netlink_unicast+0x318/0x380 [ 173.761665] netlink_sendmsg+0x17c/0x3c8", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50299", "url": "https://ubuntu.com/security/CVE-2024-50299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: properly validate chunk size in sctp_sf_ootb() A size validation fix similar to that in Commit 50619dbf8db7 (\"sctp: add size validation when walking chunks\") is also required in sctp_sf_ootb() to address a crash reported by syzbot: BUG: KMSAN: uninit-value in sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_do_sm+0x181/0x93d0 net/sctp/sm_sideeffect.c:1166 sctp_endpoint_bh_rcv+0xc38/0xf90 net/sctp/endpointola.c:407 sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88 sctp_rcv+0x3831/0x3b20 net/sctp/input.c:243 sctp4_rcv+0x42/0x50 net/sctp/protocol.c:1159 ip_protocol_deliver_rcu+0xb51/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50300", "url": "https://ubuntu.com/security/CVE-2024-50300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: rtq2208: Fix uninitialized use of regulator_config Fix rtq2208 driver uninitialized use to cause kernel error.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50301", "url": "https://ubuntu.com/security/CVE-2024-50301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: security/keys: fix slab-out-of-bounds in key_task_permission KASAN reports an out of bounds read: BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline] BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362 CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0x107/0x167 lib/dump_stack.c:123 print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 __kuid_val include/linux/uidgid.h:36 [inline] uid_eq include/linux/uidgid.h:63 [inline] key_task_permission+0x394/0x410 security/keys/permission.c:54 search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793 This issue was also reported by syzbot. It can be reproduced by following these steps(more details [1]): 1. Obtain more than 32 inputs that have similar hashes, which ends with the pattern '0xxxxxxxe6'. 2. Reboot and add the keys obtained in step 1. The reproducer demonstrates how this issue happened: 1. In the search_nested_keyrings function, when it iterates through the slots in a node(below tag ascend_to_node), if the slot pointer is meta and node->back_pointer != NULL(it means a root), it will proceed to descend_to_node. However, there is an exception. If node is the root, and one of the slots points to a shortcut, it will be treated as a keyring. 2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function. However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as ASSOC_ARRAY_PTR_SUBTYPE_MASK. 3. When 32 keys with the similar hashes are added to the tree, the ROOT has keys with hashes that are not similar (e.g. slot 0) and it splits NODE A without using a shortcut. When NODE A is filled with keys that all hashes are xxe6, the keys are similar, NODE A will split with a shortcut. Finally, it forms the tree as shown below, where slot 6 points to a shortcut. NODE A +------>+---+ ROOT | | 0 | xxe6 +---+ | +---+ xxxx | 0 | shortcut : : xxe6 +---+ | +---+ xxe6 : : | | | xxe6 +---+ | +---+ | 6 |---+ : : xxe6 +---+ +---+ xxe6 : : | f | xxe6 +---+ +---+ xxe6 | f | +---+ 4. As mentioned above, If a slot(slot 6) of the root points to a shortcut, it may be mistakenly transferred to a key*, leading to a read out-of-bounds read. To fix this issue, one should jump to descend_to_node if the ptr is a shortcut, regardless of whether the node is root or not. [1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/ [jarkko: tweaked the commit message a bit to have an appropriate closes tag.]", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53072", "url": "https://ubuntu.com/security/CVE-2024-53072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/pmc: Detect when STB is not available Loading the amd_pmc module as: amd_pmc enable_stb=1 ...can result in the following messages in the kernel ring buffer: amd_pmc AMDI0009:00: SMU cmd failed. err: 0xff ioremap on RAM at 0x0000000000000000 - 0x0000000000ffffff WARNING: CPU: 10 PID: 2151 at arch/x86/mm/ioremap.c:217 __ioremap_caller+0x2cd/0x340 Further debugging reveals that this occurs when the requests for S2D_PHYS_ADDR_LOW and S2D_PHYS_ADDR_HIGH return a value of 0, indicating that the STB is inaccessible. To prevent the ioremap warning and provide clarity to the user, handle the invalid address and display an error message.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50302", "url": "https://ubuntu.com/security/CVE-2024-50302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: zero-initialize the report buffer Since the report buffer is used by all kinds of drivers in various ways, let's zero-initialize it during allocation to make sure that it can't be ever used to leak kernel memory via specially-crafted report.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53068", "url": "https://ubuntu.com/security/CVE-2024-53068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix slab-use-after-free in scmi_bus_notifier() The scmi_dev->name is released prematurely in __scmi_device_destroy(), which causes slab-use-after-free when accessing scmi_dev->name in scmi_bus_notifier(). So move the release of scmi_dev->name to scmi_device_release() to avoid slab-use-after-free. | BUG: KASAN: slab-use-after-free in strncmp+0xe4/0xec | Read of size 1 at addr ffffff80a482bcc0 by task swapper/0/1 | | CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.6.38-debug #1 | Hardware name: Qualcomm Technologies, Inc. SA8775P Ride (DT) | Call trace: | dump_backtrace+0x94/0x114 | show_stack+0x18/0x24 | dump_stack_lvl+0x48/0x60 | print_report+0xf4/0x5b0 | kasan_report+0xa4/0xec | __asan_report_load1_noabort+0x20/0x2c | strncmp+0xe4/0xec | scmi_bus_notifier+0x5c/0x54c | notifier_call_chain+0xb4/0x31c | blocking_notifier_call_chain+0x68/0x9c | bus_notify+0x54/0x78 | device_del+0x1bc/0x840 | device_unregister+0x20/0xb4 | __scmi_device_destroy+0xac/0x280 | scmi_device_destroy+0x94/0xd0 | scmi_chan_setup+0x524/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20 | | Allocated by task 1: | kasan_save_stack+0x2c/0x54 | kasan_set_track+0x2c/0x40 | kasan_save_alloc_info+0x24/0x34 | __kasan_kmalloc+0xa0/0xb8 | __kmalloc_node_track_caller+0x6c/0x104 | kstrdup+0x48/0x84 | kstrdup_const+0x34/0x40 | __scmi_device_create.part.0+0x8c/0x408 | scmi_device_create+0x104/0x370 | scmi_chan_setup+0x2a0/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20 | | Freed by task 1: | kasan_save_stack+0x2c/0x54 | kasan_set_track+0x2c/0x40 | kasan_save_free_info+0x38/0x5c | __kasan_slab_free+0xe8/0x164 | __kmem_cache_free+0x11c/0x230 | kfree+0x70/0x130 | kfree_const+0x20/0x40 | __scmi_device_destroy+0x70/0x280 | scmi_device_destroy+0x94/0xd0 | scmi_chan_setup+0x524/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53069", "url": "https://ubuntu.com/security/CVE-2024-53069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: qcom: scm: fix a NULL-pointer dereference Some SCM calls can be invoked with __scm being NULL (the driver may not have been and will not be probed as there's no SCM entry in device-tree). Make sure we don't dereference a NULL pointer.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50212", "url": "https://ubuntu.com/security/CVE-2024-50212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib: alloc_tag_module_unload must wait for pending kfree_rcu calls Ben Greear reports following splat: ------------[ cut here ]------------ net/netfilter/nf_nat_core.c:1114 module nf_nat func:nf_nat_register_fn has 256 allocated at module unload WARNING: CPU: 1 PID: 10421 at lib/alloc_tag.c:168 alloc_tag_module_unload+0x22b/0x3f0 Modules linked in: nf_nat(-) btrfs ufs qnx4 hfsplus hfs minix vfat msdos fat ... Hardware name: Default string Default string/SKYBAY, BIOS 5.12 08/04/2020 RIP: 0010:alloc_tag_module_unload+0x22b/0x3f0 codetag_unload_module+0x19b/0x2a0 ? codetag_load_module+0x80/0x80 nf_nat module exit calls kfree_rcu on those addresses, but the free operation is likely still pending by the time alloc_tag checks for leaks. Wait for outstanding kfree_rcu operations to complete before checking resolves this warning. Reproducer: unshare -n iptables-nft -t nat -A PREROUTING -p tcp grep nf_nat /proc/allocinfo # will list 4 allocations rmmod nft_chain_nat rmmod nf_nat # will WARN. [akpm@linux-foundation.org: add comment]", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53046", "url": "https://ubuntu.com/security/CVE-2024-53046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: dts: imx8ulp: correct the flexspi compatible string The flexspi on imx8ulp only has 16 LUTs, and imx8mm flexspi has 32 LUTs, so correct the compatible string here, otherwise will meet below error: [ 1.119072] ------------[ cut here ]------------ [ 1.123926] WARNING: CPU: 0 PID: 1 at drivers/spi/spi-nxp-fspi.c:855 nxp_fspi_exec_op+0xb04/0xb64 [ 1.133239] Modules linked in: [ 1.136448] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-rc6-next-20240902-00001-g131bf9439dd9 #69 [ 1.146821] Hardware name: NXP i.MX8ULP EVK (DT) [ 1.151647] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.158931] pc : nxp_fspi_exec_op+0xb04/0xb64 [ 1.163496] lr : nxp_fspi_exec_op+0xa34/0xb64 [ 1.168060] sp : ffff80008002b2a0 [ 1.171526] x29: ffff80008002b2d0 x28: 0000000000000000 x27: 0000000000000000 [ 1.179002] x26: ffff2eb645542580 x25: ffff800080610014 x24: ffff800080610000 [ 1.186480] x23: ffff2eb645548080 x22: 0000000000000006 x21: ffff2eb6455425e0 [ 1.193956] x20: 0000000000000000 x19: ffff80008002b5e0 x18: ffffffffffffffff [ 1.201432] x17: ffff2eb644467508 x16: 0000000000000138 x15: 0000000000000002 [ 1.208907] x14: 0000000000000000 x13: ffff2eb6400d8080 x12: 00000000ffffff00 [ 1.216378] x11: 0000000000000000 x10: ffff2eb6400d8080 x9 : ffff2eb697adca80 [ 1.223850] x8 : ffff2eb697ad3cc0 x7 : 0000000100000000 x6 : 0000000000000001 [ 1.231324] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000007a6 [ 1.238795] x2 : 0000000000000000 x1 : 00000000000001ce x0 : 00000000ffffff92 [ 1.246267] Call trace: [ 1.248824] nxp_fspi_exec_op+0xb04/0xb64 [ 1.253031] spi_mem_exec_op+0x3a0/0x430 [ 1.257139] spi_nor_read_id+0x80/0xcc [ 1.261065] spi_nor_scan+0x1ec/0xf10 [ 1.264901] spi_nor_probe+0x108/0x2fc [ 1.268828] spi_mem_probe+0x6c/0xbc [ 1.272574] spi_probe+0x84/0xe4 [ 1.275958] really_probe+0xbc/0x29c [ 1.279713] __driver_probe_device+0x78/0x12c [ 1.284277] driver_probe_device+0xd8/0x15c [ 1.288660] __device_attach_driver+0xb8/0x134 [ 1.293316] bus_for_each_drv+0x88/0xe8 [ 1.297337] __device_attach+0xa0/0x190 [ 1.301353] device_initial_probe+0x14/0x20 [ 1.305734] bus_probe_device+0xac/0xb0 [ 1.309752] device_add+0x5d0/0x790 [ 1.313408] __spi_add_device+0x134/0x204 [ 1.317606] of_register_spi_device+0x3b4/0x590 [ 1.322348] spi_register_controller+0x47c/0x754 [ 1.327181] devm_spi_register_controller+0x4c/0xa4 [ 1.332289] nxp_fspi_probe+0x1cc/0x2b0 [ 1.336307] platform_probe+0x68/0xc4 [ 1.340145] really_probe+0xbc/0x29c [ 1.343893] __driver_probe_device+0x78/0x12c [ 1.348457] driver_probe_device+0xd8/0x15c [ 1.352838] __driver_attach+0x90/0x19c [ 1.356857] bus_for_each_dev+0x7c/0xdc [ 1.360877] driver_attach+0x24/0x30 [ 1.364624] bus_add_driver+0xe4/0x208 [ 1.368552] driver_register+0x5c/0x124 [ 1.372573] __platform_driver_register+0x28/0x34 [ 1.377497] nxp_fspi_driver_init+0x1c/0x28 [ 1.381888] do_one_initcall+0x80/0x1c8 [ 1.385908] kernel_init_freeable+0x1c4/0x28c [ 1.390472] kernel_init+0x20/0x1d8 [ 1.394138] ret_from_fork+0x10/0x20 [ 1.397885] ---[ end trace 0000000000000000 ]--- [ 1.407908] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53052", "url": "https://ubuntu.com/security/CVE-2024-53052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/rw: fix missing NOWAIT check for O_DIRECT start write When io_uring starts a write, it'll call kiocb_start_write() to bump the super block rwsem, preventing any freezes from happening while that write is in-flight. The freeze side will grab that rwsem for writing, excluding any new writers from happening and waiting for existing writes to finish. But io_uring unconditionally uses kiocb_start_write(), which will block if someone is currently attempting to freeze the mount point. This causes a deadlock where freeze is waiting for previous writes to complete, but the previous writes cannot complete, as the task that is supposed to complete them is blocked waiting on starting a new write. This results in the following stuck trace showing that dependency with the write blocked starting a new write: task:fio state:D stack:0 pid:886 tgid:886 ppid:876 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_rwsem_wait+0x1e8/0x3f8 __percpu_down_read+0xe8/0x500 io_write+0xbb8/0xff8 io_issue_sqe+0x10c/0x1020 io_submit_sqes+0x614/0x2110 __arm64_sys_io_uring_enter+0x524/0x1038 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 INFO: task fsfreeze:7364 blocked for more than 15 seconds. Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963 with the attempting freezer stuck trying to grab the rwsem: task:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_down_write+0x2b0/0x680 freeze_super+0x248/0x8a8 do_vfs_ioctl+0x149c/0x1b18 __arm64_sys_ioctl+0xd0/0x1a0 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 Fix this by having the io_uring side honor IOCB_NOWAIT, and only attempt a blocking grab of the super block rwsem if it isn't set. For normal issue where IOCB_NOWAIT would always be set, this returns -EAGAIN which will have io_uring core issue a blocking attempt of the write. That will in turn also get completions run, ensuring forward progress. Since freezing requires CAP_SYS_ADMIN in the first place, this isn't something that can be triggered by a regular user.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50213", "url": "https://ubuntu.com/security/CVE-2024-50213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tests: hdmi: Fix memory leaks in drm_display_mode_from_cea_vic() modprobe drm_hdmi_state_helper_test and then rmmod it, the following memory leak occurs. The `mode` allocated in drm_mode_duplicate() called by drm_display_mode_from_cea_vic() is not freed, which cause the memory leak: \tunreferenced object 0xffffff80ccd18100 (size 128): \t comm \"kunit_try_catch\", pid 1851, jiffies 4295059695 \t hex dump (first 32 bytes): \t 57 62 00 00 80 02 90 02 f0 02 20 03 00 00 e0 01 Wb........ ..... \t ea 01 ec 01 0d 02 00 00 0a 00 00 00 00 00 00 00 ................ \t backtrace (crc c2f1aa95): \t [<000000000f10b11b>] kmemleak_alloc+0x34/0x40 \t [<000000001cd4cf73>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<00000000f1f3cffa>] drm_mode_duplicate+0x44/0x19c \t [<000000008cbeef13>] drm_display_mode_from_cea_vic+0x88/0x98 \t [<0000000019daaacf>] 0xffffffedc11ae69c \t [<000000000aad0f85>] kunit_try_run_case+0x13c/0x3ac \t [<00000000a9210bac>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<000000000a0b2e9e>] kthread+0x2e8/0x374 \t [<00000000bd668858>] ret_from_fork+0x10/0x20 \t...... Free `mode` by using drm_kunit_display_mode_from_cea_vic() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50214", "url": "https://ubuntu.com/security/CVE-2024-50214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/connector: hdmi: Fix memory leak in drm_display_mode_from_cea_vic() modprobe drm_connector_test and then rmmod drm_connector_test, the following memory leak occurs. The `mode` allocated in drm_mode_duplicate() called by drm_display_mode_from_cea_vic() is not freed, which cause the memory leak: \tunreferenced object 0xffffff80cb0ee400 (size 128): \t comm \"kunit_try_catch\", pid 1948, jiffies 4294950339 \t hex dump (first 32 bytes): \t 14 44 02 00 80 07 d8 07 04 08 98 08 00 00 38 04 .D............8. \t 3c 04 41 04 65 04 00 00 05 00 00 00 00 00 00 00 <.A.e........... \t backtrace (crc 90e9585c): \t [<00000000ec42e3d7>] kmemleak_alloc+0x34/0x40 \t [<00000000d0ef055a>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<00000000c2062161>] drm_mode_duplicate+0x44/0x19c \t [<00000000f96c74aa>] drm_display_mode_from_cea_vic+0x88/0x98 \t [<00000000d8f2c8b4>] 0xffffffdc982a4868 \t [<000000005d164dbc>] kunit_try_run_case+0x13c/0x3ac \t [<000000006fb23398>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<000000006ea56ca0>] kthread+0x2e8/0x374 \t [<000000000676063f>] ret_from_fork+0x10/0x20 \t...... Free `mode` by using drm_kunit_display_mode_from_cea_vic() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50215", "url": "https://ubuntu.com/security/CVE-2024-50215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: assign dh_key to NULL after kfree_sensitive ctrl->dh_key might be used across multiple calls to nvmet_setup_dhgroup() for the same controller. So it's better to nullify it after release on error path in order to avoid double free later in nvmet_destroy_auth(). Found by Linux Verification Center (linuxtesting.org) with Svace.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50216", "url": "https://ubuntu.com/security/CVE-2024-50216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix finding a last resort AG in xfs_filestream_pick_ag When the main loop in xfs_filestream_pick_ag fails to find a suitable AG it tries to just pick the online AG. But the loop for that uses args->pag as loop iterator while the later code expects pag to be set. Fix this by reusing the max_pag case for this last resort, and also add a check for impossible case of no AG just to make sure that the uninitialized pag doesn't even escape in theory.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50217", "url": "https://ubuntu.com/security/CVE-2024-50217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free of block device file in __btrfs_free_extra_devids() Mounting btrfs from two images (which have the same one fsid and two different dev_uuids) in certain executing order may trigger an UAF for variable 'device->bdev_file' in __btrfs_free_extra_devids(). And following are the details: 1. Attach image_1 to loop0, attach image_2 to loop1, and scan btrfs devices by ioctl(BTRFS_IOC_SCAN_DEV): / btrfs_device_1 ? loop0 fs_device \\ btrfs_device_2 ? loop1 2. mount /dev/loop0 /mnt btrfs_open_devices btrfs_device_1->bdev_file = btrfs_get_bdev_and_sb(loop0) btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree fail: btrfs_close_devices // -ENOMEM \t btrfs_close_bdev(btrfs_device_1) fput(btrfs_device_1->bdev_file) \t // btrfs_device_1->bdev_file is freed \t btrfs_close_bdev(btrfs_device_2) fput(btrfs_device_2->bdev_file) 3. mount /dev/loop1 /mnt btrfs_open_devices btrfs_get_bdev_and_sb(&bdev_file) // EIO, btrfs_device_1->bdev_file is not assigned, // which points to a freed memory area btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree btrfs_free_extra_devids if (btrfs_device_1->bdev_file) fput(btrfs_device_1->bdev_file) // UAF ! Fix it by setting 'device->bdev_file' as 'NULL' after closing the btrfs_device in btrfs_close_one_device().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53043", "url": "https://ubuntu.com/security/CVE-2024-53043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mctp i2c: handle NULL header address daddr can be NULL if there is no neighbour table entry present, in that case the tx packet should be dropped. saddr will usually be set by MCTP core, but check for NULL in case a packet is transmitted by a different protocol.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50303", "url": "https://ubuntu.com/security/CVE-2024-50303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: resource,kexec: walk_system_ram_res_rev must retain resource flags walk_system_ram_res_rev() erroneously discards resource flags when passing the information to the callback. This causes systems with IORESOURCE_SYSRAM_DRIVER_MANAGED memory to have these resources selected during kexec to store kexec buffers if that memory happens to be at placed above normal system ram. This leads to undefined behavior after reboot. If the kexec buffer is never touched, nothing happens. If the kexec buffer is touched, it could lead to a crash (like below) or undefined behavior. Tested on a system with CXL memory expanders with driver managed memory, TPM enabled, and CONFIG_IMA_KEXEC=y. Adding printk's showed the flags were being discarded and as a result the check for IORESOURCE_SYSRAM_DRIVER_MANAGED passes. find_next_iomem_res: name(System RAM (kmem)) \t\t start(10000000000) \t\t end(1034fffffff) \t\t flags(83000200) locate_mem_hole_top_down: start(10000000000) end(1034fffffff) flags(0) [.] BUG: unable to handle page fault for address: ffff89834ffff000 [.] #PF: supervisor read access in kernel mode [.] #PF: error_code(0x0000) - not-present page [.] PGD c04c8bf067 P4D c04c8bf067 PUD c04c8be067 PMD 0 [.] Oops: 0000 [#1] SMP [.] RIP: 0010:ima_restore_measurement_list+0x95/0x4b0 [.] RSP: 0018:ffffc900000d3a80 EFLAGS: 00010286 [.] RAX: 0000000000001000 RBX: 0000000000000000 RCX: ffff89834ffff000 [.] RDX: 0000000000000018 RSI: ffff89834ffff000 RDI: ffff89834ffff018 [.] RBP: ffffc900000d3ba0 R08: 0000000000000020 R09: ffff888132b8a900 [.] R10: 4000000000000000 R11: 000000003a616d69 R12: 0000000000000000 [.] R13: ffffffff8404ac28 R14: 0000000000000000 R15: ffff89834ffff000 [.] FS: 0000000000000000(0000) GS:ffff893d44640000(0000) knlGS:0000000000000000 [.] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [.] ata5: SATA link down (SStatus 0 SControl 300) [.] CR2: ffff89834ffff000 CR3: 000001034d00f001 CR4: 0000000000770ef0 [.] PKRU: 55555554 [.] Call Trace: [.] [.] ? __die+0x78/0xc0 [.] ? page_fault_oops+0x2a8/0x3a0 [.] ? exc_page_fault+0x84/0x130 [.] ? asm_exc_page_fault+0x22/0x30 [.] ? ima_restore_measurement_list+0x95/0x4b0 [.] ? template_desc_init_fields+0x317/0x410 [.] ? crypto_alloc_tfm_node+0x9c/0xc0 [.] ? init_ima_lsm+0x30/0x30 [.] ima_load_kexec_buffer+0x72/0xa0 [.] ima_init+0x44/0xa0 [.] __initstub__kmod_ima__373_1201_init_ima7+0x1e/0xb0 [.] ? init_ima_lsm+0x30/0x30 [.] do_one_initcall+0xad/0x200 [.] ? idr_alloc_cyclic+0xaa/0x110 [.] ? new_slab+0x12c/0x420 [.] ? new_slab+0x12c/0x420 [.] ? number+0x12a/0x430 [.] ? sysvec_apic_timer_interrupt+0xa/0x80 [.] ? asm_sysvec_apic_timer_interrupt+0x16/0x20 [.] ? parse_args+0xd4/0x380 [.] ? parse_args+0x14b/0x380 [.] kernel_init_freeable+0x1c1/0x2b0 [.] ? rest_init+0xb0/0xb0 [.] kernel_init+0x16/0x1a0 [.] ret_from_fork+0x2f/0x40 [.] ? rest_init+0xb0/0xb0 [.] ret_from_fork_asm+0x11/0x20 [.] ", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50218", "url": "https://ubuntu.com/security/CVE-2024-50218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow Syzbot reported a kernel BUG in ocfs2_truncate_inline. There are two reasons for this: first, the parameter value passed is greater than ocfs2_max_inline_data_with_xattr, second, the start and end parameters of ocfs2_truncate_inline are \"unsigned int\". So, we need to add a sanity check for byte_start and byte_len right before ocfs2_truncate_inline() in ocfs2_remove_inode_range(), if they are greater than ocfs2_max_inline_data_with_xattr return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50219", "url": "https://ubuntu.com/security/CVE-2024-50219", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50263", "url": "https://ubuntu.com/security/CVE-2024-50263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fork: only invoke khugepaged, ksm hooks if no error There is no reason to invoke these hooks early against an mm that is in an incomplete state. The change in commit d24062914837 (\"fork: use __mt_dup() to duplicate maple tree in dup_mmap()\") makes this more pertinent as we may be in a state where entries in the maple tree are not yet consistent. Their placement early in dup_mmap() only appears to have been meaningful for early error checking, and since functionally it'd require a very small allocation to fail (in practice 'too small to fail') that'd only occur in the most dire circumstances, meaning the fork would fail or be OOM'd in any case. Since both khugepaged and KSM tracking are there to provide optimisations to memory performance rather than critical functionality, it doesn't really matter all that much if, under such dire memory pressure, we fail to register an mm with these. As a result, we follow the example of commit d2081b2bf819 (\"mm: khugepaged: make khugepaged_enter() void function\") and make ksm_fork() a void function also. We only expose the mm to these functions once we are done with them and only if no error occurred in the fork operation.", "cve_priority": "medium", "cve_public_date": "2024-11-11 14:15:00 UTC" }, { "cve": "CVE-2024-50220", "url": "https://ubuntu.com/security/CVE-2024-50220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fork: do not invoke uffd on fork if error occurs Patch series \"fork: do not expose incomplete mm on fork\". During fork we may place the virtual memory address space into an inconsistent state before the fork operation is complete. In addition, we may encounter an error during the fork operation that indicates that the virtual memory address space is invalidated. As a result, we should not be exposing it in any way to external machinery that might interact with the mm or VMAs, machinery that is not designed to deal with incomplete state. We specifically update the fork logic to defer khugepaged and ksm to the end of the operation and only to be invoked if no error arose, and disallow uffd from observing fork events should an error have occurred. This patch (of 2): Currently on fork we expose the virtual address space of a process to userland unconditionally if uffd is registered in VMAs, regardless of whether an error arose in the fork. This is performed in dup_userfaultfd_complete() which is invoked unconditionally, and performs two duties - invoking registered handlers for the UFFD_EVENT_FORK event via dup_fctx(), and clearing down userfaultfd_fork_ctx objects established in dup_userfaultfd(). This is problematic, because the virtual address space may not yet be correctly initialised if an error arose. The change in commit d24062914837 (\"fork: use __mt_dup() to duplicate maple tree in dup_mmap()\") makes this more pertinent as we may be in a state where entries in the maple tree are not yet consistent. We address this by, on fork error, ensuring that we roll back state that we would otherwise expect to clean up through the event being handled by userland and perform the memory freeing duty otherwise performed by dup_userfaultfd_complete(). We do this by implementing a new function, dup_userfaultfd_fail(), which performs the same loop, only decrementing reference counts. Note that we perform mmgrab() on the parent and child mm's, however userfaultfd_ctx_put() will mmdrop() this once the reference count drops to zero, so we will avoid memory leaks correctly here.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53047", "url": "https://ubuntu.com/security/CVE-2024-53047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: init: protect sched with rcu_read_lock Enabling CONFIG_PROVE_RCU_LIST with its dependence CONFIG_RCU_EXPERT creates this splat when an MPTCP socket is created: ============================= WARNING: suspicious RCU usage 6.12.0-rc2+ #11 Not tainted ----------------------------- net/mptcp/sched.c:44 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 no locks held by mptcp_connect/176. stack backtrace: CPU: 0 UID: 0 PID: 176 Comm: mptcp_connect Not tainted 6.12.0-rc2+ #11 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl (lib/dump_stack.c:123) lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822) mptcp_sched_find (net/mptcp/sched.c:44 (discriminator 7)) mptcp_init_sock (net/mptcp/protocol.c:2867 (discriminator 1)) ? sock_init_data_uid (arch/x86/include/asm/atomic.h:28) inet_create.part.0.constprop.0 (net/ipv4/af_inet.c:386) ? __sock_create (include/linux/rcupdate.h:347 (discriminator 1)) __sock_create (net/socket.c:1576) __sys_socket (net/socket.c:1671) ? __pfx___sys_socket (net/socket.c:1712) ? do_user_addr_fault (arch/x86/mm/fault.c:1419 (discriminator 1)) __x64_sys_socket (net/socket.c:1728) do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) That's because when the socket is initialised, rcu_read_lock() is not used despite the explicit comment written above the declaration of mptcp_sched_find() in sched.c. Adding the missing lock/unlock avoids the warning.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50221", "url": "https://ubuntu.com/security/CVE-2024-50221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Vangogh: Fix kernel memory out of bounds write KASAN reports that the GPU metrics table allocated in vangogh_tables_init() is not large enough for the memset done in smu_cmn_init_soft_gpu_metrics(). Condensed report follows: [ 33.861314] BUG: KASAN: slab-out-of-bounds in smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu] [ 33.861799] Write of size 168 at addr ffff888129f59500 by task mangoapp/1067 ... [ 33.861808] CPU: 6 UID: 1000 PID: 1067 Comm: mangoapp Tainted: G W 6.12.0-rc4 #356 1a56f59a8b5182eeaf67eb7cb8b13594dd23b544 [ 33.861816] Tainted: [W]=WARN [ 33.861818] Hardware name: Valve Galileo/Galileo, BIOS F7G0107 12/01/2023 [ 33.861822] Call Trace: [ 33.861826] [ 33.861829] dump_stack_lvl+0x66/0x90 [ 33.861838] print_report+0xce/0x620 [ 33.861853] kasan_report+0xda/0x110 [ 33.862794] kasan_check_range+0xfd/0x1a0 [ 33.862799] __asan_memset+0x23/0x40 [ 33.862803] smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.863306] vangogh_get_gpu_metrics_v2_4+0x123/0xad0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.864257] vangogh_common_get_gpu_metrics+0xb0c/0xbc0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.865682] amdgpu_dpm_get_gpu_metrics+0xcc/0x110 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.866160] amdgpu_get_gpu_metrics+0x154/0x2d0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.867135] dev_attr_show+0x43/0xc0 [ 33.867147] sysfs_kf_seq_show+0x1f1/0x3b0 [ 33.867155] seq_read_iter+0x3f8/0x1140 [ 33.867173] vfs_read+0x76c/0xc50 [ 33.867198] ksys_read+0xfb/0x1d0 [ 33.867214] do_syscall_64+0x90/0x160 ... [ 33.867353] Allocated by task 378 on cpu 7 at 22.794876s: [ 33.867358] kasan_save_stack+0x33/0x50 [ 33.867364] kasan_save_track+0x17/0x60 [ 33.867367] __kasan_kmalloc+0x87/0x90 [ 33.867371] vangogh_init_smc_tables+0x3f9/0x840 [amdgpu] [ 33.867835] smu_sw_init+0xa32/0x1850 [amdgpu] [ 33.868299] amdgpu_device_init+0x467b/0x8d90 [amdgpu] [ 33.868733] amdgpu_driver_load_kms+0x19/0xf0 [amdgpu] [ 33.869167] amdgpu_pci_probe+0x2d6/0xcd0 [amdgpu] [ 33.869608] local_pci_probe+0xda/0x180 [ 33.869614] pci_device_probe+0x43f/0x6b0 Empirically we can confirm that the former allocates 152 bytes for the table, while the latter memsets the 168 large block. Root cause appears that when GPU metrics tables for v2_4 parts were added it was not considered to enlarge the table to fit. The fix in this patch is rather \"brute force\" and perhaps later should be done in a smarter way, by extracting and consolidating the part version to size logic to a common helper, instead of brute forcing the largest possible allocation. Nevertheless, for now this works and fixes the out of bounds write. v2: * Drop impossible v3_0 case. (Mario) (cherry picked from commit 0880f58f9609f0200483a49429af0f050d281703)", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50222", "url": "https://ubuntu.com/security/CVE-2024-50222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iov_iter: fix copy_page_from_iter_atomic() if KMAP_LOCAL_FORCE_MAP generic/077 on x86_32 CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP=y with highmem, on huge=always tmpfs, issues a warning and then hangs (interruptibly): WARNING: CPU: 5 PID: 3517 at mm/highmem.c:622 kunmap_local_indexed+0x62/0xc9 CPU: 5 UID: 0 PID: 3517 Comm: cp Not tainted 6.12.0-rc4 #2 ... copy_page_from_iter_atomic+0xa6/0x5ec generic_perform_write+0xf6/0x1b4 shmem_file_write_iter+0x54/0x67 Fix copy_page_from_iter_atomic() by limiting it in that case (include/linux/skbuff.h skb_frag_must_loop() does similar). But going forward, perhaps CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP is too surprising, has outlived its usefulness, and should just be removed?", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50223", "url": "https://ubuntu.com/security/CVE-2024-50223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/numa: Fix the potential null pointer dereference in task_numa_work() When running stress-ng-vm-segv test, we found a null pointer dereference error in task_numa_work(). Here is the backtrace: [323676.066985] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ...... [323676.067108] CPU: 35 PID: 2694524 Comm: stress-ng-vm-se ...... [323676.067113] pstate: 23401009 (nzCv daif +PAN -UAO +TCO +DIT +SSBS BTYPE=--) [323676.067115] pc : vma_migratable+0x1c/0xd0 [323676.067122] lr : task_numa_work+0x1ec/0x4e0 [323676.067127] sp : ffff8000ada73d20 [323676.067128] x29: ffff8000ada73d20 x28: 0000000000000000 x27: 000000003e89f010 [323676.067130] x26: 0000000000080000 x25: ffff800081b5c0d8 x24: ffff800081b27000 [323676.067133] x23: 0000000000010000 x22: 0000000104d18cc0 x21: ffff0009f7158000 [323676.067135] x20: 0000000000000000 x19: 0000000000000000 x18: ffff8000ada73db8 [323676.067138] x17: 0001400000000000 x16: ffff800080df40b0 x15: 0000000000000035 [323676.067140] x14: ffff8000ada73cc8 x13: 1fffe0017cc72001 x12: ffff8000ada73cc8 [323676.067142] x11: ffff80008001160c x10: ffff000be639000c x9 : ffff8000800f4ba4 [323676.067145] x8 : ffff000810375000 x7 : ffff8000ada73974 x6 : 0000000000000001 [323676.067147] x5 : 0068000b33e26707 x4 : 0000000000000001 x3 : ffff0009f7158000 [323676.067149] x2 : 0000000000000041 x1 : 0000000000004400 x0 : 0000000000000000 [323676.067152] Call trace: [323676.067153] vma_migratable+0x1c/0xd0 [323676.067155] task_numa_work+0x1ec/0x4e0 [323676.067157] task_work_run+0x78/0xd8 [323676.067161] do_notify_resume+0x1ec/0x290 [323676.067163] el0_svc+0x150/0x160 [323676.067167] el0t_64_sync_handler+0xf8/0x128 [323676.067170] el0t_64_sync+0x17c/0x180 [323676.067173] Code: d2888001 910003fd f9000bf3 aa0003f3 (f9401000) [323676.067177] SMP: stopping secondary CPUs [323676.070184] Starting crashdump kernel... stress-ng-vm-segv in stress-ng is used to stress test the SIGSEGV error handling function of the system, which tries to cause a SIGSEGV error on return from unmapping the whole address space of the child process. Normally this program will not cause kernel crashes. But before the munmap system call returns to user mode, a potential task_numa_work() for numa balancing could be added and executed. In this scenario, since the child process has no vma after munmap, the vma_next() in task_numa_work() will return a null pointer even if the vma iterator restarts from 0. Recheck the vma pointer before dereferencing it in task_numa_work().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53053", "url": "https://ubuntu.com/security/CVE-2024-53053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Fix another deadlock during RTC update If ufshcd_rtc_work calls ufshcd_rpm_put_sync() and the pm's usage_count is 0, we will enter the runtime suspend callback. However, the runtime suspend callback will wait to flush ufshcd_rtc_work, causing a deadlock. Replace ufshcd_rpm_put_sync() with ufshcd_rpm_put() to avoid the deadlock.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53075", "url": "https://ubuntu.com/security/CVE-2024-53075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv: Prevent a bad reference count on CPU nodes When populating cache leaves we previously fetched the CPU device node at the very beginning. But when ACPI is enabled we go through a specific branch which returns early and does not call 'of_node_put' for the node that was acquired. Since we are not using a CPU device node for the ACPI code anyways, we can simply move the initialization of it just passed the ACPI block, and we are guaranteed to have an 'of_node_put' call for the acquired node. This prevents a bad reference count of the CPU device node. Moreover, the previous function did not check for errors when acquiring the device node, so a return -ENOENT has been added for that case.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50224", "url": "https://ubuntu.com/security/CVE-2024-50224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: spi-fsl-dspi: Fix crash when not using GPIO chip select Add check for the return value of spi_get_csgpiod() to avoid passing a NULL pointer to gpiod_direction_output(), preventing a crash when GPIO chip select is not used. Fix below crash: [ 4.251960] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 4.260762] Mem abort info: [ 4.263556] ESR = 0x0000000096000004 [ 4.267308] EC = 0x25: DABT (current EL), IL = 32 bits [ 4.272624] SET = 0, FnV = 0 [ 4.275681] EA = 0, S1PTW = 0 [ 4.278822] FSC = 0x04: level 0 translation fault [ 4.283704] Data abort info: [ 4.286583] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 4.292074] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 4.297130] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 4.302445] [0000000000000000] user address but active_mm is swapper [ 4.308805] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 4.315072] Modules linked in: [ 4.318124] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc4-next-20241023-00008-ga20ec42c5fc1 #359 [ 4.328130] Hardware name: LS1046A QDS Board (DT) [ 4.332832] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 4.339794] pc : gpiod_direction_output+0x34/0x5c [ 4.344505] lr : gpiod_direction_output+0x18/0x5c [ 4.349208] sp : ffff80008003b8f0 [ 4.352517] x29: ffff80008003b8f0 x28: 0000000000000000 x27: ffffc96bcc7e9068 [ 4.359659] x26: ffffc96bcc6e00b0 x25: ffffc96bcc598398 x24: ffff447400132810 [ 4.366800] x23: 0000000000000000 x22: 0000000011e1a300 x21: 0000000000020002 [ 4.373940] x20: 0000000000000000 x19: 0000000000000000 x18: ffffffffffffffff [ 4.381081] x17: ffff44740016e600 x16: 0000000500000003 x15: 0000000000000007 [ 4.388221] x14: 0000000000989680 x13: 0000000000020000 x12: 000000000000001e [ 4.395362] x11: 0044b82fa09b5a53 x10: 0000000000000019 x9 : 0000000000000008 [ 4.402502] x8 : 0000000000000002 x7 : 0000000000000007 x6 : 0000000000000000 [ 4.409641] x5 : 0000000000000200 x4 : 0000000002000000 x3 : 0000000000000000 [ 4.416781] x2 : 0000000000022202 x1 : 0000000000000000 x0 : 0000000000000000 [ 4.423921] Call trace: [ 4.426362] gpiod_direction_output+0x34/0x5c (P) [ 4.431067] gpiod_direction_output+0x18/0x5c (L) [ 4.435771] dspi_setup+0x220/0x334", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50225", "url": "https://ubuntu.com/security/CVE-2024-50225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix error propagation of split bios The purpose of btrfs_bbio_propagate_error() shall be propagating an error of split bio to its original btrfs_bio, and tell the error to the upper layer. However, it's not working well on some cases. * Case 1. Immediate (or quick) end_bio with an error When btrfs sends btrfs_bio to mirrored devices, btrfs calls btrfs_bio_end_io() when all the mirroring bios are completed. If that btrfs_bio was split, it is from btrfs_clone_bioset and its end_io function is btrfs_orig_write_end_io. For this case, btrfs_bbio_propagate_error() accesses the orig_bbio's bio context to increase the error count. That works well in most cases. However, if the end_io is called enough fast, orig_bbio's (remaining part after split) bio context may not be properly set at that time. Since the bio context is set when the orig_bbio (the last btrfs_bio) is sent to devices, that might be too late for earlier split btrfs_bio's completion. That will result in NULL pointer dereference. That bug is easily reproducible by running btrfs/146 on zoned devices [1] and it shows the following trace. [1] You need raid-stripe-tree feature as it create \"-d raid0 -m raid1\" FS. BUG: kernel NULL pointer dereference, address: 0000000000000020 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 UID: 0 PID: 13 Comm: kworker/u32:1 Not tainted 6.11.0-rc7-BTRFS-ZNS+ #474 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Workqueue: writeback wb_workfn (flush-btrfs-5) RIP: 0010:btrfs_bio_end_io+0xae/0xc0 [btrfs] BTRFS error (device dm-0): bdev /dev/mapper/error-test errs: wr 2, rd 0, flush 0, corrupt 0, gen 0 RSP: 0018:ffffc9000006f248 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888005a7f080 RCX: ffffc9000006f1dc RDX: 0000000000000000 RSI: 000000000000000a RDI: ffff888005a7f080 RBP: ffff888011dfc540 R08: 0000000000000000 R09: 0000000000000001 R10: ffffffff82e508e0 R11: 0000000000000005 R12: ffff88800ddfbe58 R13: ffff888005a7f080 R14: ffff888005a7f158 R15: ffff888005a7f158 FS: 0000000000000000(0000) GS:ffff88803ea80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000020 CR3: 0000000002e22006 CR4: 0000000000370ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __die_body.cold+0x19/0x26 ? page_fault_oops+0x13e/0x2b0 ? _printk+0x58/0x73 ? do_user_addr_fault+0x5f/0x750 ? exc_page_fault+0x76/0x240 ? asm_exc_page_fault+0x22/0x30 ? btrfs_bio_end_io+0xae/0xc0 [btrfs] ? btrfs_log_dev_io_error+0x7f/0x90 [btrfs] btrfs_orig_write_end_io+0x51/0x90 [btrfs] dm_submit_bio+0x5c2/0xa50 [dm_mod] ? find_held_lock+0x2b/0x80 ? blk_try_enter_queue+0x90/0x1e0 __submit_bio+0xe0/0x130 ? ktime_get+0x10a/0x160 ? lockdep_hardirqs_on+0x74/0x100 submit_bio_noacct_nocheck+0x199/0x410 btrfs_submit_bio+0x7d/0x150 [btrfs] btrfs_submit_chunk+0x1a1/0x6d0 [btrfs] ? lockdep_hardirqs_on+0x74/0x100 ? __folio_start_writeback+0x10/0x2c0 btrfs_submit_bbio+0x1c/0x40 [btrfs] submit_one_bio+0x44/0x60 [btrfs] submit_extent_folio+0x13f/0x330 [btrfs] ? btrfs_set_range_writeback+0xa3/0xd0 [btrfs] extent_writepage_io+0x18b/0x360 [btrfs] extent_write_locked_range+0x17c/0x340 [btrfs] ? __pfx_end_bbio_data_write+0x10/0x10 [btrfs] run_delalloc_cow+0x71/0xd0 [btrfs] btrfs_run_delalloc_range+0x176/0x500 [btrfs] ? find_lock_delalloc_range+0x119/0x260 [btrfs] writepage_delalloc+0x2ab/0x480 [btrfs] extent_write_cache_pages+0x236/0x7d0 [btrfs] btrfs_writepages+0x72/0x130 [btrfs] do_writepages+0xd4/0x240 ? find_held_lock+0x2b/0x80 ? wbc_attach_and_unlock_inode+0x12c/0x290 ? wbc_attach_and_unlock_inode+0x12c/0x29 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53054", "url": "https://ubuntu.com/security/CVE-2024-53054", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50226", "url": "https://ubuntu.com/security/CVE-2024-50226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cxl/port: Fix use-after-free, permit out-of-order decoder shutdown In support of investigating an initialization failure report [1], cxl_test was updated to register mock memory-devices after the mock root-port/bus device had been registered. That led to cxl_test crashing with a use-after-free bug with the following signature: cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem0:decoder7.0 @ 0 next: cxl_switch_uport.0 nr_eps: 1 nr_targets: 1 cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem4:decoder14.0 @ 1 next: cxl_switch_uport.0 nr_eps: 2 nr_targets: 1 cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[0] = cxl_switch_dport.0 for mem0:decoder7.0 @ 0 1) cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[1] = cxl_switch_dport.4 for mem4:decoder14.0 @ 1 [..] cxld_unregister: cxl decoder14.0: cxl_region_decode_reset: cxl_region region3: mock_decoder_reset: cxl_port port3: decoder3.0 reset 2) mock_decoder_reset: cxl_port port3: decoder3.0: out of order reset, expected decoder3.1 cxl_endpoint_decoder_release: cxl decoder14.0: [..] cxld_unregister: cxl decoder7.0: 3) cxl_region_decode_reset: cxl_region region3: Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6bc3: 0000 [#1] PREEMPT SMP PTI [..] RIP: 0010:to_cxl_port+0x8/0x60 [cxl_core] [..] Call Trace: cxl_region_decode_reset+0x69/0x190 [cxl_core] cxl_region_detach+0xe8/0x210 [cxl_core] cxl_decoder_kill_region+0x27/0x40 [cxl_core] cxld_unregister+0x5d/0x60 [cxl_core] At 1) a region has been established with 2 endpoint decoders (7.0 and 14.0). Those endpoints share a common switch-decoder in the topology (3.0). At teardown, 2), decoder14.0 is the first to be removed and hits the \"out of order reset case\" in the switch decoder. The effect though is that region3 cleanup is aborted leaving it in-tact and referencing decoder14.0. At 3) the second attempt to teardown region3 trips over the stale decoder14.0 object which has long since been deleted. The fix here is to recognize that the CXL specification places no mandate on in-order shutdown of switch-decoders, the driver enforces in-order allocation, and hardware enforces in-order commit. So, rather than fail and leave objects dangling, always remove them. In support of making cxl_region_decode_reset() always succeed, cxl_region_invalidate_memregion() failures are turned into warnings. Crashing the kernel is ok there since system integrity is at risk if caches cannot be managed around physical address mutation events like CXL region destruction. A new device_for_each_child_reverse_from() is added to cleanup port->commit_end after all dependent decoders have been disabled. In other words if decoders are allocated 0->1->2 and disabled 1->2->0 then port->commit_end only decrements from 2 after 2 has been disabled, and it decrements all the way to zero since 1 was disabled previously.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50227", "url": "https://ubuntu.com/security/CVE-2024-50227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Fix KASAN reported stack out-of-bounds read in tb_retimer_scan() KASAN reported following issue: BUG: KASAN: stack-out-of-bounds in tb_retimer_scan+0xffe/0x1550 [thunderbolt] Read of size 4 at addr ffff88810111fc1c by task kworker/u56:0/11 CPU: 0 UID: 0 PID: 11 Comm: kworker/u56:0 Tainted: G U 6.11.0+ #1387 Tainted: [U]=USER Workqueue: thunderbolt0 tb_handle_hotplug [thunderbolt] Call Trace: dump_stack_lvl+0x6c/0x90 print_report+0xd1/0x630 kasan_report+0xdb/0x110 __asan_report_load4_noabort+0x14/0x20 tb_retimer_scan+0xffe/0x1550 [thunderbolt] tb_scan_port+0xa6f/0x2060 [thunderbolt] tb_handle_hotplug+0x17b1/0x3080 [thunderbolt] process_one_work+0x626/0x1100 worker_thread+0x6c8/0xfa0 kthread+0x2c8/0x3a0 ret_from_fork+0x3a/0x80 ret_from_fork_asm+0x1a/0x30 This happens because the loop variable still gets incremented by one so max becomes 3 instead of 2, and this makes the second loop read past the the array declared on the stack. Fix this by assigning to max directly in the loop body.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50228", "url": "https://ubuntu.com/security/CVE-2024-50228", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50229", "url": "https://ubuntu.com/security/CVE-2024-50229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential deadlock with newly created symlinks Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers memory reclamation involving the filesystem layer, which can result in circular lock dependencies among the reader/writer semaphore nilfs->ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the fs_reclaim pseudo lock. This is because after commit 21fc61c73c39 (\"don't put symlink bodies in pagecache into highmem\"), the gfp flags of the page cache for symbolic links are overwritten to GFP_KERNEL via inode_nohighmem(). This is not a problem for symlinks read from the backing device, because the __GFP_FS flag is dropped after inode_nohighmem() is called. However, when a new symlink is created with nilfs_symlink(), the gfp flags remain overwritten to GFP_KERNEL. Then, memory allocation called from page_symlink() etc. triggers memory reclamation including the FS layer, which may call nilfs_evict_inode() or nilfs_dirty_inode(). And these can cause a deadlock if they are called while nilfs->ns_segctor_sem is held: Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags of newly created symlinks in the same way that nilfs_new_inode() and __nilfs_read_inode() do, as a workaround until we adopt nofs allocation scope consistently or improve the locking constraints.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50230", "url": "https://ubuntu.com/security/CVE-2024-50230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug due to missing clearing of checked flag Syzbot reported that in directory operations after nilfs2 detects filesystem corruption and degrades to read-only, __block_write_begin_int(), which is called to prepare block writes, may fail the BUG_ON check for accesses exceeding the folio/page size, triggering a kernel bug. This was found to be because the \"checked\" flag of a page/folio was not cleared when it was discarded by nilfs2's own routine, which causes the sanity check of directory entries to be skipped when the directory page/folio is reloaded. So, fix that. This was necessary when the use of nilfs2's own page discard routine was applied to more than just metadata files.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50231", "url": "https://ubuntu.com/security/CVE-2024-50231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gts-helper: Fix memory leaks in iio_gts_build_avail_scale_table() modprobe iio-test-gts and rmmod it, then the following memory leak occurs: \tunreferenced object 0xffffff80c810be00 (size 64): \t comm \"kunit_try_catch\", pid 1654, jiffies 4294913981 \t hex dump (first 32 bytes): \t 02 00 00 00 08 00 00 00 20 00 00 00 40 00 00 00 ........ ...@... \t 80 00 00 00 00 02 00 00 00 04 00 00 00 08 00 00 ................ \t backtrace (crc a63d875e): \t [<0000000028c1b3c2>] kmemleak_alloc+0x34/0x40 \t [<000000001d6ecc87>] __kmalloc_noprof+0x2bc/0x3c0 \t [<00000000393795c1>] devm_iio_init_iio_gts+0x4b4/0x16f4 \t [<0000000071bb4b09>] 0xffffffdf052a62e0 \t [<000000000315bc18>] 0xffffffdf052a6488 \t [<00000000f9dc55b5>] kunit_try_run_case+0x13c/0x3ac \t [<00000000175a3fd4>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000f505065d>] kthread+0x2e8/0x374 \t [<00000000bbfb0e5d>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cbfe9e70 (size 16): \t comm \"kunit_try_catch\", pid 1658, jiffies 4294914015 \t hex dump (first 16 bytes): \t 10 00 00 00 40 00 00 00 80 00 00 00 00 00 00 00 ....@........... \t backtrace (crc 857f0cb4): \t [<0000000028c1b3c2>] kmemleak_alloc+0x34/0x40 \t [<000000001d6ecc87>] __kmalloc_noprof+0x2bc/0x3c0 \t [<00000000393795c1>] devm_iio_init_iio_gts+0x4b4/0x16f4 \t [<0000000071bb4b09>] 0xffffffdf052a62e0 \t [<000000007d089d45>] 0xffffffdf052a6864 \t [<00000000f9dc55b5>] kunit_try_run_case+0x13c/0x3ac \t [<00000000175a3fd4>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000f505065d>] kthread+0x2e8/0x374 \t [<00000000bbfb0e5d>] ret_from_fork+0x10/0x20 \t...... It includes 5*5 times \"size 64\" memory leaks, which correspond to 5 times test_init_iio_gain_scale() calls with gts_test_gains size 10 (10*size(int)) and gts_test_itimes size 5. It also includes 5*1 times \"size 16\" memory leak, which correspond to one time __test_init_iio_gain_scale() call with gts_test_gains_gain_low size 3 (3*size(int)) and gts_test_itimes size 5. The reason is that the per_time_gains[i] is not freed which is allocated in the \"gts->num_itime\" for loop in iio_gts_build_avail_scale_table().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53076", "url": "https://ubuntu.com/security/CVE-2024-53076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gts-helper: Fix memory leaks for the error path of iio_gts_build_avail_scale_table() If per_time_scales[i] or per_time_gains[i] kcalloc fails in the for loop of iio_gts_build_avail_scale_table(), the err_free_out will fail to call kfree() each time when i is reduced to 0, so all the per_time_scales[0] and per_time_gains[0] will not be freed, which will cause memory leaks. Fix it by checking if i >= 0.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50232", "url": "https://ubuntu.com/security/CVE-2024-50232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr() In the ad7124_write_raw() function, parameter val can potentially be zero. This may lead to a division by zero when DIV_ROUND_CLOSEST() is called within ad7124_set_channel_odr(). The ad7124_write_raw() function is invoked through the sequence: iio_write_channel_raw() -> iio_write_channel_attribute() -> iio_channel_write(), with no checks in place to ensure val is non-zero.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50233", "url": "https://ubuntu.com/security/CVE-2024-50233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: iio: frequency: ad9832: fix division by zero in ad9832_calc_freqreg() In the ad9832_write_frequency() function, clk_get_rate() might return 0. This can lead to a division by zero when calling ad9832_calc_freqreg(). The check if (fout > (clk_get_rate(st->mclk) / 2)) does not protect against the case when fout is 0. The ad9832_write_frequency() function is called from ad9832_write(), and fout is derived from a text buffer, which can contain any value.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53055", "url": "https://ubuntu.com/security/CVE-2024-53055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix 6 GHz scan construction If more than 255 colocated APs exist for the set of all APs found during 2.4/5 GHz scanning, then the 6 GHz scan construction will loop forever since the loop variable has type u8, which can never reach the number found when that's bigger than 255, and is stored in a u32 variable. Also move it into the loops to have a smaller scope. Using a u32 there is fine, we limit the number of APs in the scan list and each has a limit on the number of RNR entries due to the frame size. With a limit of 1000 scan results, a frame size upper bound of 4096 (really it's more like ~2300) and a TBTT entry size of at least 11, we get an upper bound for the number of ~372k, well in the bounds of a u32.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50234", "url": "https://ubuntu.com/security/CVE-2024-50234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlegacy: Clear stale interrupts before resuming device iwl4965 fails upon resume from hibernation on my laptop. The reason seems to be a stale interrupt which isn't being cleared out before interrupts are enabled. We end up with a race beween the resume trying to bring things back up, and the restart work (queued form the interrupt handler) trying to bring things down. Eventually the whole thing blows up. Fix the problem by clearing out any stale interrupts before interrupts get enabled during resume. Here's a debug log of the indicent: [ 12.042589] ieee80211 phy0: il_isr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000 [ 12.042625] ieee80211 phy0: il4965_irq_tasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000 [ 12.042651] iwl4965 0000:10:00.0: RF_KILL bit toggled to enable radio. [ 12.042653] iwl4965 0000:10:00.0: On demand firmware reload [ 12.042690] ieee80211 phy0: il4965_irq_tasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282 [ 12.052207] ieee80211 phy0: il4965_mac_start enter [ 12.052212] ieee80211 phy0: il_prep_station Add STA to driver ID 31: ff:ff:ff:ff:ff:ff [ 12.052244] ieee80211 phy0: il4965_set_hw_ready hardware ready [ 12.052324] ieee80211 phy0: il_apm_init Init card's basic functions [ 12.052348] ieee80211 phy0: il_apm_init L1 Enabled; Disabling L0S [ 12.055727] ieee80211 phy0: il4965_load_bsm Begin load bsm [ 12.056140] ieee80211 phy0: il4965_verify_bsm Begin verify bsm [ 12.058642] ieee80211 phy0: il4965_verify_bsm BSM bootstrap uCode image OK [ 12.058721] ieee80211 phy0: il4965_load_bsm BSM write complete, poll 1 iterations [ 12.058734] ieee80211 phy0: __il4965_up iwl4965 is coming up [ 12.058737] ieee80211 phy0: il4965_mac_start Start UP work done. [ 12.058757] ieee80211 phy0: __il4965_down iwl4965 is going down [ 12.058761] ieee80211 phy0: il_scan_cancel_timeout Scan cancel timeout [ 12.058762] ieee80211 phy0: il_do_scan_abort Not performing scan to abort [ 12.058765] ieee80211 phy0: il_clear_ucode_stations Clearing ucode stations in driver [ 12.058767] ieee80211 phy0: il_clear_ucode_stations No active stations found to be cleared [ 12.058819] ieee80211 phy0: _il_apm_stop Stop card, put in low power state [ 12.058827] ieee80211 phy0: _il_apm_stop_master stop master [ 12.058864] ieee80211 phy0: il4965_clear_free_frames 0 frames on pre-allocated heap on clear. [ 12.058869] ieee80211 phy0: Hardware restart was requested [ 16.132299] iwl4965 0000:10:00.0: START_ALIVE timeout after 4000ms. [ 16.132303] ------------[ cut here ]------------ [ 16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue. [ 16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132390] Modules linked in: ctr ccm sch_fq_codel xt_tcpudp xt_multiport xt_state iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables binfmt_misc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdh_generic ecc iTCO_wdt i2c_dev iwl4965 iwlegacy coretemp snd_hda_codec_analog pcspkr psmouse mac80211 snd_hda_codec_generic libarc4 sdhci_pci cqhci sha256_generic sdhci libsha256 firewire_ohci snd_hda_intel snd_intel_dspcfg mmc_core snd_hda_codec snd_hwdep firewire_core led_class iosf_mbi snd_hda_core uhci_hcd lpc_ich crc_itu_t cfg80211 ehci_pci ehci_hcd snd_pcm usbcore mfd_core rfkill snd_timer snd usb_common soundcore video parport_pc parport intel_agp wmi intel_gtt backlight e1000e agpgart evdev [ 16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143 [ 16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010 [ 16.132463] Workqueue: async async_run_entry_fn [ 16.132469] RIP: 0010:ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132501] Code: da 02 00 0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50235", "url": "https://ubuntu.com/security/CVE-2024-50235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: clear wdev->cqm_config pointer on free When we free wdev->cqm_config when unregistering, we also need to clear out the pointer since the same wdev/netdev may get re-registered in another network namespace, then destroyed later, running this code again, which results in a double-free.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50236", "url": "https://ubuntu.com/security/CVE-2024-50236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: Fix memory leak in management tx In the current logic, memory is allocated for storing the MSDU context during management packet TX but this memory is not being freed during management TX completion. Similar leaks are seen in the management TX cleanup logic. Kmemleak reports this problem as below, unreferenced object 0xffffff80b64ed250 (size 16): comm \"kworker/u16:7\", pid 148, jiffies 4294687130 (age 714.199s) hex dump (first 16 bytes): 00 2b d8 d8 80 ff ff ff c4 74 e9 fd 07 00 00 00 .+.......t...... backtrace: [] __kmem_cache_alloc_node+0x1e4/0x2d8 [] kmalloc_trace+0x48/0x110 [] ath10k_wmi_tlv_op_gen_mgmt_tx_send+0xd4/0x1d8 [ath10k_core] [] ath10k_mgmt_over_wmi_tx_work+0x134/0x298 [ath10k_core] [] process_scheduled_works+0x1ac/0x400 [] worker_thread+0x208/0x328 [] kthread+0x100/0x1c0 [] ret_from_fork+0x10/0x20 Free the memory during completion and cleanup to fix the leak. Protect the mgmt_pending_tx idr_remove() operation in ath10k_wmi_tlv_op_cleanup_mgmt_tx_send() using ar->data_lock similar to other instances. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50237", "url": "https://ubuntu.com/security/CVE-2024-50237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower Avoid potentially crashing in the driver because of uninitialized private data", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50238", "url": "https://ubuntu.com/security/CVE-2024-50238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usbc: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data from the qcom-qmp-usb driver, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. This bug was later reproduced when the driver was copied to create the qmp-usbc driver. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with these drivers.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50239", "url": "https://ubuntu.com/security/CVE-2024-50239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usb-legacy: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data from the qcom-qmp-usb driver, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. This bug was later reproduced when the driver was copied to create the qmp-usb-legacy driver. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with these drivers.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50240", "url": "https://ubuntu.com/security/CVE-2024-50240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usb: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with this driver.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53077", "url": "https://ubuntu.com/security/CVE-2024-53077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpcrdma: Always release the rpcrdma_device's xa_array Dai pointed out that the xa_init_flags() in rpcrdma_add_one() needs to have a matching xa_destroy() in rpcrdma_remove_one() to release underlying memory that the xarray might have accrued during operation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50242", "url": "https://ubuntu.com/security/CVE-2024-50242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ntfs_file_release", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50243", "url": "https://ubuntu.com/security/CVE-2024-50243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix general protection fault in run_is_mapped_full Fixed deleating of a non-resident attribute in ntfs_create_inode() rollback.", "cve_priority": "low", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50244", "url": "https://ubuntu.com/security/CVE-2024-50244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ni_clear() Checking of NTFS_FLAGS_LOG_REPLAYING added to prevent access to uninitialized bitmap during replay process.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50245", "url": "https://ubuntu.com/security/CVE-2024-50245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix possible deadlock in mi_read Mutex lock with another subclass used in ni_lock_dir().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50246", "url": "https://ubuntu.com/security/CVE-2024-50246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Add rough attr alloc_size check", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50247", "url": "https://ubuntu.com/security/CVE-2024-50247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Check if more than chunk-size bytes are written A incorrectly formatted chunk may decompress into more than LZNT_CHUNK_SIZE bytes and a index out of bounds will occur in s_max_off.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50248", "url": "https://ubuntu.com/security/CVE-2024-50248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Add bounds checking to mi_enum_attr() Added bounds checking to make sure that every attr don't stray beyond valid memory region.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53078", "url": "https://ubuntu.com/security/CVE-2024-53078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Fix NULL vs IS_ERR() check in probe() The iommu_paging_domain_alloc() function doesn't return NULL pointers, it returns error pointers. Update the check to match.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53056", "url": "https://ubuntu.com/security/CVE-2024-53056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Fix potential NULL dereference in mtk_crtc_destroy() In mtk_crtc_create(), if the call to mbox_request_channel() fails then we set the \"mtk_crtc->cmdq_client.chan\" pointer to NULL. In that situation, we do not call cmdq_pkt_create(). During the cleanup, we need to check if the \"mtk_crtc->cmdq_client.chan\" is NULL first before calling cmdq_pkt_destroy(). Calling cmdq_pkt_destroy() is unnecessary if we didn't call cmdq_pkt_create() and it will result in a NULL pointer dereference.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50249", "url": "https://ubuntu.com/security/CVE-2024-50249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Make rmw_lock a raw_spin_lock The following BUG was triggered: ============================= [ BUG: Invalid wait context ] 6.12.0-rc2-XXX #406 Not tainted ----------------------------- kworker/1:1/62 is trying to lock: ffffff8801593030 (&cpc_ptr->rmw_lock){+.+.}-{3:3}, at: cpc_write+0xcc/0x370 other info that might help us debug this: context-{5:5} 2 locks held by kworker/1:1/62: #0: ffffff897ef5ec98 (&rq->__lock){-.-.}-{2:2}, at: raw_spin_rq_lock_nested+0x2c/0x50 #1: ffffff880154e238 (&sg_policy->update_lock){....}-{2:2}, at: sugov_update_shared+0x3c/0x280 stack backtrace: CPU: 1 UID: 0 PID: 62 Comm: kworker/1:1 Not tainted 6.12.0-rc2-g9654bd3e8806 #406 Workqueue: 0x0 (events) Call trace: dump_backtrace+0xa4/0x130 show_stack+0x20/0x38 dump_stack_lvl+0x90/0xd0 dump_stack+0x18/0x28 __lock_acquire+0x480/0x1ad8 lock_acquire+0x114/0x310 _raw_spin_lock+0x50/0x70 cpc_write+0xcc/0x370 cppc_set_perf+0xa0/0x3a8 cppc_cpufreq_fast_switch+0x40/0xc0 cpufreq_driver_fast_switch+0x4c/0x218 sugov_update_shared+0x234/0x280 update_load_avg+0x6ec/0x7b8 dequeue_entities+0x108/0x830 dequeue_task_fair+0x58/0x408 __schedule+0x4f0/0x1070 schedule+0x54/0x130 worker_thread+0xc0/0x2e8 kthread+0x130/0x148 ret_from_fork+0x10/0x20 sugov_update_shared() locks a raw_spinlock while cpc_write() locks a spinlock. To have a correct wait-type order, update rmw_lock to a raw spinlock and ensure that interrupts will be disabled on the CPU holding it. [ rjw: Changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50250", "url": "https://ubuntu.com/security/CVE-2024-50250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fsdax: dax_unshare_iter needs to copy entire blocks The code that copies data from srcmap to iomap in dax_unshare_iter is very very broken, which bfoster's recent fsx changes have exposed. If the pos and len passed to dax_file_unshare are not aligned to an fsblock boundary, the iter pos and length in the _iter function will reflect this unalignment. dax_iomap_direct_access always returns a pointer to the start of the kmapped fsdax page, even if its pos argument is in the middle of that page. This is catastrophic for data integrity when iter->pos is not aligned to a page, because daddr/saddr do not point to the same byte in the file as iter->pos. Hence we corrupt user data by copying it to the wrong place. If iter->pos + iomap_length() in the _iter function not aligned to a page, then we fail to copy a full block, and only partially populate the destination block. This is catastrophic for data confidentiality because we expose stale pmem contents. Fix both of these issues by aligning copy_pos/copy_len to a page boundary (remember, this is fsdax so 1 fsblock == 1 base page) so that we always copy full blocks. We're not done yet -- there's no call to invalidate_inode_pages2_range, so programs that have the file range mmap'd will continue accessing the old memory mapping after the file metadata updates have completed. Be careful with the return value -- if the unshare succeeds, we still need to return the number of bytes that the iomap iter thinks we're operating on.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50251", "url": "https://ubuntu.com/security/CVE-2024-50251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_payload: sanitize offset and length before calling skb_checksum() If access to offset + length is larger than the skbuff length, then skb_checksum() triggers BUG_ON(). skb_checksum() internally subtracts the length parameter while iterating over skbuff, BUG_ON(len) at the end of it checks that the expected length to be included in the checksum calculation is fully consumed.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50252", "url": "https://ubuntu.com/security/CVE-2024-50252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_ipip: Fix memory leak when changing remote IPv6 address The device stores IPv6 addresses that are used for encapsulation in linear memory that is managed by the driver. Changing the remote address of an ip6gre net device never worked properly, but since cited commit the following reproducer [1] would result in a warning [2] and a memory leak [3]. The problem is that the new remote address is never added by the driver to its hash table (and therefore the device) and the old address is never removed from it. Fix by programming the new address when the configuration of the ip6gre net device changes and removing the old one. If the address did not change, then the above would result in increasing the reference count of the address and then decreasing it. [1] # ip link add name bla up type ip6gre local 2001:db8:1::1 remote 2001:db8:2::1 tos inherit ttl inherit # ip link set dev bla type ip6gre remote 2001:db8:3::1 # ip link del dev bla # devlink dev reload pci/0000:01:00.0 [2] WARNING: CPU: 0 PID: 1682 at drivers/net/ethernet/mellanox/mlxsw/spectrum.c:3002 mlxsw_sp_ipv6_addr_put+0x140/0x1d0 Modules linked in: CPU: 0 UID: 0 PID: 1682 Comm: ip Not tainted 6.12.0-rc3-custom-g86b5b55bc835 #151 Hardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023 RIP: 0010:mlxsw_sp_ipv6_addr_put+0x140/0x1d0 [...] Call Trace: mlxsw_sp_router_netdevice_event+0x55f/0x1240 notifier_call_chain+0x5a/0xd0 call_netdevice_notifiers_info+0x39/0x90 unregister_netdevice_many_notify+0x63e/0x9d0 rtnl_dellink+0x16b/0x3a0 rtnetlink_rcv_msg+0x142/0x3f0 netlink_rcv_skb+0x50/0x100 netlink_unicast+0x242/0x390 netlink_sendmsg+0x1de/0x420 ____sys_sendmsg+0x2bd/0x320 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xd0 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f [3] unreferenced object 0xffff898081f597a0 (size 32): comm \"ip\", pid 1626, jiffies 4294719324 hex dump (first 32 bytes): 20 01 0d b8 00 02 00 00 00 00 00 00 00 00 00 01 ............... 21 49 61 83 80 89 ff ff 00 00 00 00 01 00 00 00 !Ia............. backtrace (crc fd9be911): [<00000000df89c55d>] __kmalloc_cache_noprof+0x1da/0x260 [<00000000ff2a1ddb>] mlxsw_sp_ipv6_addr_kvdl_index_get+0x281/0x340 [<000000009ddd445d>] mlxsw_sp_router_netdevice_event+0x47b/0x1240 [<00000000743e7757>] notifier_call_chain+0x5a/0xd0 [<000000007c7b9e13>] call_netdevice_notifiers_info+0x39/0x90 [<000000002509645d>] register_netdevice+0x5f7/0x7a0 [<00000000c2e7d2a9>] ip6gre_newlink_common.isra.0+0x65/0x130 [<0000000087cd6d8d>] ip6gre_newlink+0x72/0x120 [<000000004df7c7cc>] rtnl_newlink+0x471/0xa20 [<0000000057ed632a>] rtnetlink_rcv_msg+0x142/0x3f0 [<0000000032e0d5b5>] netlink_rcv_skb+0x50/0x100 [<00000000908bca63>] netlink_unicast+0x242/0x390 [<00000000cdbe1c87>] netlink_sendmsg+0x1de/0x420 [<0000000011db153e>] ____sys_sendmsg+0x2bd/0x320 [<000000003b6d53eb>] ___sys_sendmsg+0x9a/0xe0 [<00000000cae27c62>] __sys_sendmsg+0x7a/0xd0", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50253", "url": "https://ubuntu.com/security/CVE-2024-50253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check the validity of nr_words in bpf_iter_bits_new() Check the validity of nr_words in bpf_iter_bits_new(). Without this check, when multiplication overflow occurs for nr_bits (e.g., when nr_words = 0x0400-0001, nr_bits becomes 64), stack corruption may occur due to bpf_probe_read_kernel_common(..., nr_bytes = 0x2000-0008). Fix it by limiting the maximum value of nr_words to 511. The value is derived from the current implementation of BPF memory allocator. To ensure compatibility if the BPF memory allocator's size limitation changes in the future, use the helper bpf_mem_alloc_check_size() to check whether nr_bytes is too larger. And return -E2BIG instead of -ENOMEM for oversized nr_bytes.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50254", "url": "https://ubuntu.com/security/CVE-2024-50254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free dynamically allocated bits in bpf_iter_bits_destroy() bpf_iter_bits_destroy() uses \"kit->nr_bits <= 64\" to check whether the bits are dynamically allocated. However, the check is incorrect and may cause a kmemleak as shown below: unreferenced object 0xffff88812628c8c0 (size 32): comm \"swapper/0\", pid 1, jiffies 4294727320 hex dump (first 32 bytes): \tb0 c1 55 f5 81 88 ff ff f0 f0 f0 f0 f0 f0 f0 f0 ..U........... \tf0 f0 f0 f0 f0 f0 f0 f0 00 00 00 00 00 00 00 00 .............. backtrace (crc 781e32cc): \t[<00000000c452b4ab>] kmemleak_alloc+0x4b/0x80 \t[<0000000004e09f80>] __kmalloc_node_noprof+0x480/0x5c0 \t[<00000000597124d6>] __alloc.isra.0+0x89/0xb0 \t[<000000004ebfffcd>] alloc_bulk+0x2af/0x720 \t[<00000000d9c10145>] prefill_mem_cache+0x7f/0xb0 \t[<00000000ff9738ff>] bpf_mem_alloc_init+0x3e2/0x610 \t[<000000008b616eac>] bpf_global_ma_init+0x19/0x30 \t[<00000000fc473efc>] do_one_initcall+0xd3/0x3c0 \t[<00000000ec81498c>] kernel_init_freeable+0x66a/0x940 \t[<00000000b119f72f>] kernel_init+0x20/0x160 \t[<00000000f11ac9a7>] ret_from_fork+0x3c/0x70 \t[<0000000004671da4>] ret_from_fork_asm+0x1a/0x30 That is because nr_bits will be set as zero in bpf_iter_bits_next() after all bits have been iterated. Fix the issue by setting kit->bit to kit->nr_bits instead of setting kit->nr_bits to zero when the iteration completes in bpf_iter_bits_next(). In addition, use \"!nr_bits || bits >= nr_bits\" to check whether the iteration is complete and still use \"nr_bits > 64\" to indicate whether bits are dynamically allocated. The \"!nr_bits\" check is necessary because bpf_iter_bits_new() may fail before setting kit->nr_bits, and this condition will stop the iteration early instead of accessing the zeroed or freed kit->bits. Considering the initial value of kit->bits is -1 and the type of kit->nr_bits is unsigned int, change the type of kit->nr_bits to int. The potential overflow problem will be handled in the following patch.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50255", "url": "https://ubuntu.com/security/CVE-2024-50255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci: fix null-ptr-deref in hci_read_supported_codecs Fix __hci_cmd_sync_sk() to return not NULL for unknown opcodes. __hci_cmd_sync_sk() returns NULL if a command returns a status event. However, it also returns NULL where an opcode doesn't exist in the hci_cc table because hci_cmd_complete_evt() assumes status = skb->data[0] for unknown opcodes. This leads to null-ptr-deref in cmd_sync for HCI_OP_READ_LOCAL_CODECS as there is no hci_cc for HCI_OP_READ_LOCAL_CODECS, which always assumes status = skb->data[0]. KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077] CPU: 1 PID: 2000 Comm: kworker/u9:5 Not tainted 6.9.0-ga6bcb805883c-dirty #10 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: hci7 hci_power_on RIP: 0010:hci_read_supported_codecs+0xb9/0x870 net/bluetooth/hci_codec.c:138 Code: 08 48 89 ef e8 b8 c1 8f fd 48 8b 75 00 e9 96 00 00 00 49 89 c6 48 ba 00 00 00 00 00 fc ff df 4c 8d 60 70 4c 89 e3 48 c1 eb 03 <0f> b6 04 13 84 c0 0f 85 82 06 00 00 41 83 3c 24 02 77 0a e8 bf 78 RSP: 0018:ffff888120bafac8 EFLAGS: 00010212 RAX: 0000000000000000 RBX: 000000000000000e RCX: ffff8881173f0040 RDX: dffffc0000000000 RSI: ffffffffa58496c0 RDI: ffff88810b9ad1e4 RBP: ffff88810b9ac000 R08: ffffffffa77882a7 R09: 1ffffffff4ef1054 R10: dffffc0000000000 R11: fffffbfff4ef1055 R12: 0000000000000070 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88810b9ac000 FS: 0000000000000000(0000) GS:ffff8881f6c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6ddaa3439e CR3: 0000000139764003 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: hci_read_local_codecs_sync net/bluetooth/hci_sync.c:4546 [inline] hci_init_stage_sync net/bluetooth/hci_sync.c:3441 [inline] hci_init4_sync net/bluetooth/hci_sync.c:4706 [inline] hci_init_sync net/bluetooth/hci_sync.c:4742 [inline] hci_dev_init_sync net/bluetooth/hci_sync.c:4912 [inline] hci_dev_open_sync+0x19a9/0x2d30 net/bluetooth/hci_sync.c:4994 hci_dev_do_open net/bluetooth/hci_core.c:483 [inline] hci_power_on+0x11e/0x560 net/bluetooth/hci_core.c:1015 process_one_work kernel/workqueue.c:3267 [inline] process_scheduled_works+0x8ef/0x14f0 kernel/workqueue.c:3348 worker_thread+0x91f/0xe50 kernel/workqueue.c:3429 kthread+0x2cb/0x360 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50256", "url": "https://ubuntu.com/security/CVE-2024-50256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6() I got a syzbot report without a repro [1] crashing in nf_send_reset6() I think the issue is that dev->hard_header_len is zero, and we attempt later to push an Ethernet header. Use LL_MAX_HEADER, as other functions in net/ipv6/netfilter/nf_reject_ipv6.c. [1] skbuff: skb_under_panic: text:ffffffff89b1d008 len:74 put:14 head:ffff88803123aa00 data:ffff88803123a9f2 tail:0x3c end:0x140 dev:syz_tun kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 UID: 0 PID: 7373 Comm: syz.1.568 Not tainted 6.12.0-rc2-syzkaller-00631-g6d858708d465 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:skb_panic net/core/skbuff.c:206 [inline] RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216 Code: 0d 8d 48 c7 c6 60 a6 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 ba 30 38 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP: 0018:ffffc900045269b0 EFLAGS: 00010282 RAX: 0000000000000088 RBX: dffffc0000000000 RCX: cd66dacdc5d8e800 RDX: 0000000000000000 RSI: 0000000000000200 RDI: 0000000000000000 RBP: ffff88802d39a3d0 R08: ffffffff8174afec R09: 1ffff920008a4ccc R10: dffffc0000000000 R11: fffff520008a4ccd R12: 0000000000000140 R13: ffff88803123aa00 R14: ffff88803123a9f2 R15: 000000000000003c FS: 00007fdbee5ff6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000005d322000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: skb_push+0xe5/0x100 net/core/skbuff.c:2636 eth_header+0x38/0x1f0 net/ethernet/eth.c:83 dev_hard_header include/linux/netdevice.h:3208 [inline] nf_send_reset6+0xce6/0x1270 net/ipv6/netfilter/nf_reject_ipv6.c:358 nft_reject_inet_eval+0x3b9/0x690 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x418/0x6b0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] br_nf_pre_routing_ipv6+0x63e/0x770 net/bridge/br_netfilter_ipv6.c:184 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_bridge_pre net/bridge/br_input.c:277 [inline] br_handle_frame+0x9fd/0x1530 net/bridge/br_input.c:424 __netif_receive_skb_core+0x13e8/0x4570 net/core/dev.c:5562 __netif_receive_skb_one_core net/core/dev.c:5666 [inline] __netif_receive_skb+0x12f/0x650 net/core/dev.c:5781 netif_receive_skb_internal net/core/dev.c:5867 [inline] netif_receive_skb+0x1e8/0x890 net/core/dev.c:5926 tun_rx_batched+0x1b7/0x8f0 drivers/net/tun.c:1550 tun_get_user+0x3056/0x47e0 drivers/net/tun.c:2007 tun_chr_write_iter+0x10d/0x1f0 drivers/net/tun.c:2053 new_sync_write fs/read_write.c:590 [inline] vfs_write+0xa6d/0xc90 fs/read_write.c:683 ksys_write+0x183/0x2b0 fs/read_write.c:736 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:0x7fdbeeb7d1ff Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 c9 8d 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 1c 8e 02 00 48 RSP: 002b:00007fdbee5ff000 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fdbeed36058 RCX: 00007fdbeeb7d1ff RDX: 000000000000008e RSI: 0000000020000040 RDI: 00000000000000c8 RBP: 00007fdbeebf12be R08: 0000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50257", "url": "https://ubuntu.com/security/CVE-2024-50257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: Fix use-after-free in get_info() ip6table_nat module unload has refcnt warning for UAF. call trace is: WARNING: CPU: 1 PID: 379 at kernel/module/main.c:853 module_put+0x6f/0x80 Modules linked in: ip6table_nat(-) CPU: 1 UID: 0 PID: 379 Comm: ip6tables Not tainted 6.12.0-rc4-00047-gc2ee9f594da8-dirty #205 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:module_put+0x6f/0x80 Call Trace: get_info+0x128/0x180 do_ip6t_get_ctl+0x6a/0x430 nf_getsockopt+0x46/0x80 ipv6_getsockopt+0xb9/0x100 rawv6_getsockopt+0x42/0x190 do_sock_getsockopt+0xaa/0x180 __sys_getsockopt+0x70/0xc0 __x64_sys_getsockopt+0x20/0x30 do_syscall_64+0xa2/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Concurrent execution of module unload and get_info() trigered the warning. The root cause is as follows: cpu0\t\t\t\t cpu1 module_exit //mod->state = MODULE_STATE_GOING ip6table_nat_exit xt_unregister_template \tkfree(t) \t//removed from templ_list \t\t\t\t getinfo() \t\t\t\t\t t = xt_find_table_lock \t\t\t\t\t\tlist_for_each_entry(tmpl, &xt_templates[af]...) \t\t\t\t\t\t\tif (strcmp(tmpl->name, name)) \t\t\t\t\t\t\t\tcontinue; //table not found \t\t\t\t\t\t\ttry_module_get \t\t\t\t\t\tlist_for_each_entry(t, &xt_net->tables[af]...) \t\t\t\t\t\t\treturn t; //not get refcnt \t\t\t\t\t module_put(t->me) //uaf unregister_pernet_subsys //remove table from xt_net list While xt_table module was going away and has been removed from xt_templates list, we couldnt get refcnt of xt_table->me. Check module in xt_net->tables list re-traversal to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50258", "url": "https://ubuntu.com/security/CVE-2024-50258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix crash when config small gso_max_size/gso_ipv4_max_size Config a small gso_max_size/gso_ipv4_max_size will lead to an underflow in sk_dst_gso_max_size(), which may trigger a BUG_ON crash, because sk->sk_gso_max_size would be much bigger than device limits. Call Trace: tcp_write_xmit tso_segs = tcp_init_tso_segs(skb, mss_now); tcp_set_skb_tso_segs tcp_skb_pcount_set // skb->len = 524288, mss_now = 8 // u16 tso_segs = 524288/8 = 65535 -> 0 tso_segs = DIV_ROUND_UP(skb->len, mss_now) BUG_ON(!tso_segs) Add check for the minimum value of gso_max_size and gso_ipv4_max_size.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50262", "url": "https://ubuntu.com/security/CVE-2024-50262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix out-of-bounds write in trie_get_next_key() trie_get_next_key() allocates a node stack with size trie->max_prefixlen, while it writes (trie->max_prefixlen + 1) nodes to the stack when it has full paths from the root to leaves. For example, consider a trie with max_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ... 0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with .prefixlen = 8 make 9 nodes be written on the node stack with size 8.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53044", "url": "https://ubuntu.com/security/CVE-2024-53044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_api: fix xa_insert() error path in tcf_block_get_ext() This command: $ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact Error: block dev insert failed: -EBUSY. fails because user space requests the same block index to be set for both ingress and egress. [ side note, I don't think it even failed prior to commit 913b47d3424e (\"net/sched: Introduce tc block netdev tracking infra\"), because this is a command from an old set of notes of mine which used to work, but alas, I did not scientifically bisect this ] The problem is not that it fails, but rather, that the second time around, it fails differently (and irrecoverably): $ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact Error: dsa_core: Flow block cb is busy. [ another note: the extack is added by me for illustration purposes. the context of the problem is that clsact_init() obtains the same &q->ingress_block pointer as &q->egress_block, and since we call tcf_block_get_ext() on both of them, \"dev\" will be added to the block->ports xarray twice, thus failing the operation: once through the ingress block pointer, and once again through the egress block pointer. the problem itself is that when xa_insert() fails, we have emitted a FLOW_BLOCK_BIND command through ndo_setup_tc(), but the offload never sees a corresponding FLOW_BLOCK_UNBIND. ] Even correcting the bad user input, we still cannot recover: $ tc qdisc replace dev swp3 ingress_block 1 egress_block 2 clsact Error: dsa_core: Flow block cb is busy. Basically the only way to recover is to reboot the system, or unbind and rebind the net device driver. To fix the bug, we need to fill the correct error teardown path which was missed during code movement, and call tcf_block_offload_unbind() when xa_insert() fails. [ last note, fundamentally I blame the label naming convention in tcf_block_get_ext() for the bug. The labels should be named after what they do, not after the error path that jumps to them. This way, it is obviously wrong that two labels pointing to the same code mean something is wrong, and checking the code correctness at the goto site is also easier ]", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50259", "url": "https://ubuntu.com/security/CVE-2024-50259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netdevsim: Add trailing zero to terminate the string in nsim_nexthop_bucket_activity_write() This was found by a static analyzer. We should not forget the trailing zero after copy_from_user() if we will further do some string operations, sscanf() in this case. Adding a trailing zero will ensure that the function performs properly.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50304", "url": "https://ubuntu.com/security/CVE-2024-50304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find() The per-netns IP tunnel hash table is protected by the RTNL mutex and ip_tunnel_find() is only called from the control path where the mutex is taken. Add a lockdep expression to hlist_for_each_entry_rcu() in ip_tunnel_find() in order to validate that the mutex is held and to silence the suspicious RCU usage warning [1]. [1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gd95d9a31aceb #139 Not tainted ----------------------------- net/ipv4/ip_tunnel.c:221 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/362: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60 stack backtrace: CPU: 12 UID: 0 PID: 362 Comm: ip Not tainted 6.12.0-rc3-custom-gd95d9a31aceb #139 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 ip_tunnel_find+0x435/0x4d0 ip_tunnel_newlink+0x517/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53042", "url": "https://ubuntu.com/security/CVE-2024-53042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_init_flow() There are code paths from which the function is called without holding the RCU read lock, resulting in a suspicious RCU usage warning [1]. Fix by using l3mdev_master_upper_ifindex_by_index() which will acquire the RCU read lock before calling l3mdev_master_upper_ifindex_by_index_rcu(). [1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gac8f72681cf2 #141 Not tainted ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/361: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60 stack backtrace: CPU: 3 UID: 0 PID: 361 Comm: ip Not tainted 6.12.0-rc3-custom-gac8f72681cf2 #141 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 dev_get_by_index_rcu+0x1d3/0x210 l3mdev_master_upper_ifindex_by_index_rcu+0x2b/0xf0 ip_tunnel_bind_dev+0x72f/0xa00 ip_tunnel_newlink+0x368/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53048", "url": "https://ubuntu.com/security/CVE-2024-53048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix crash on probe for DPLL enabled E810 LOM The E810 Lan On Motherboard (LOM) design is vendor specific. Intel provides the reference design, but it is up to vendor on the final product design. For some cases, like Linux DPLL support, the static values defined in the driver does not reflect the actual LOM design. Current implementation of dpll pins is causing the crash on probe of the ice driver for such DPLL enabled E810 LOM designs: WARNING: (...) at drivers/dpll/dpll_core.c:495 dpll_pin_get+0x2c4/0x330 ... Call Trace: ? __warn+0x83/0x130 ? dpll_pin_get+0x2c4/0x330 ? report_bug+0x1b7/0x1d0 ? handle_bug+0x42/0x70 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? dpll_pin_get+0x117/0x330 ? dpll_pin_get+0x2c4/0x330 ? dpll_pin_get+0x117/0x330 ice_dpll_get_pins.isra.0+0x52/0xe0 [ice] ... The number of dpll pins enabled by LOM vendor is greater than expected and defined in the driver for Intel designed NICs, which causes the crash. Prevent the crash and allow generic pin initialization within Linux DPLL subsystem for DPLL enabled E810 LOM designs. Newly designed solution for described issue will be based on \"per HW design\" pin initialization. It requires pin information dynamically acquired from the firmware and is already in progress, planned for next-tree only.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53058", "url": "https://ubuntu.com/security/CVE-2024-53058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data In case the non-paged data of a SKB carries protocol header and protocol payload to be transmitted on a certain platform that the DMA AXI address width is configured to 40-bit/48-bit, or the size of the non-paged data is bigger than TSO_MAX_BUFF_SIZE on a certain platform that the DMA AXI address width is configured to 32-bit, then this SKB requires at least two DMA transmit descriptors to serve it. For example, three descriptors are allocated to split one DMA buffer mapped from one piece of non-paged data: dma_desc[N + 0], dma_desc[N + 1], dma_desc[N + 2]. Then three elements of tx_q->tx_skbuff_dma[] will be allocated to hold extra information to be reused in stmmac_tx_clean(): tx_q->tx_skbuff_dma[N + 0], tx_q->tx_skbuff_dma[N + 1], tx_q->tx_skbuff_dma[N + 2]. Now we focus on tx_q->tx_skbuff_dma[entry].buf, which is the DMA buffer address returned by DMA mapping call. stmmac_tx_clean() will try to unmap the DMA buffer _ONLY_IF_ tx_q->tx_skbuff_dma[entry].buf is a valid buffer address. The expected behavior that saves DMA buffer address of this non-paged data to tx_q->tx_skbuff_dma[entry].buf is: tx_q->tx_skbuff_dma[N + 0].buf = NULL; tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = dma_map_single(); Unfortunately, the current code misbehaves like this: tx_q->tx_skbuff_dma[N + 0].buf = dma_map_single(); tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = NULL; On the stmmac_tx_clean() side, when dma_desc[N + 0] is closed by the DMA engine, tx_q->tx_skbuff_dma[N + 0].buf is a valid buffer address obviously, then the DMA buffer will be unmapped immediately. There may be a rare case that the DMA engine does not finish the pending dma_desc[N + 1], dma_desc[N + 2] yet. Now things will go horribly wrong, DMA is going to access a unmapped/unreferenced memory region, corrupted data will be transmited or iommu fault will be triggered :( In contrast, the for-loop that maps SKB fragments behaves perfectly as expected, and that is how the driver should do for both non-paged data and paged frags actually. This patch corrects DMA map/unmap sequences by fixing the array index for tx_q->tx_skbuff_dma[entry].buf when assigning DMA buffer address. Tested and verified on DWXGMAC CORE 3.20a", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50260", "url": "https://ubuntu.com/security/CVE-2024-50260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sock_map: fix a NULL pointer dereference in sock_map_link_update_prog() The following race condition could trigger a NULL pointer dereference: sock_map_link_detach():\t\tsock_map_link_update_prog(): mutex_lock(&sockmap_mutex); ... sockmap_link->map = NULL; mutex_unlock(&sockmap_mutex); \t\t\t\t mutex_lock(&sockmap_mutex); \t\t\t\t ... \t\t\t\t sock_map_prog_link_lookup(sockmap_link->map); \t\t\t\t mutex_unlock(&sockmap_mutex); Fix it by adding a NULL pointer check. In this specific case, it makes no sense to update a link which is being released.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53045", "url": "https://ubuntu.com/security/CVE-2024-53045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: dapm: fix bounds checker error in dapm_widget_list_create The widgets array in the snd_soc_dapm_widget_list has a __counted_by attribute attached to it, which points to the num_widgets variable. This attribute is used in bounds checking, and if it is not set before the array is filled, then the bounds sanitizer will issue a warning or a kernel panic if CONFIG_UBSAN_TRAP is set. This patch sets the size of the widgets list calculated with list_for_each as the initial value for num_widgets as it is used for allocating memory for the array. It is updated with the actual number of added elements after the array is filled.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50261", "url": "https://ubuntu.com/security/CVE-2024-50261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macsec: Fix use-after-free while sending the offloading packet KASAN reports the following UAF. The metadata_dst, which is used to store the SCI value for macsec offload, is already freed by metadata_dst_free() in macsec_free_netdev(), while driver still use it for sending the packet. To fix this issue, dst_release() is used instead to release metadata_dst. So it is not freed instantly in macsec_free_netdev() if still referenced by skb. BUG: KASAN: slab-use-after-free in mlx5e_xmit+0x1e8f/0x4190 [mlx5_core] Read of size 2 at addr ffff88813e42e038 by task kworker/7:2/714 [...] Workqueue: mld mld_ifc_work Call Trace: dump_stack_lvl+0x51/0x60 print_report+0xc1/0x600 kasan_report+0xab/0xe0 mlx5e_xmit+0x1e8f/0x4190 [mlx5_core] dev_hard_start_xmit+0x120/0x530 sch_direct_xmit+0x149/0x11e0 __qdisc_run+0x3ad/0x1730 __dev_queue_xmit+0x1196/0x2ed0 vlan_dev_hard_start_xmit+0x32e/0x510 [8021q] dev_hard_start_xmit+0x120/0x530 __dev_queue_xmit+0x14a7/0x2ed0 macsec_start_xmit+0x13e9/0x2340 dev_hard_start_xmit+0x120/0x530 __dev_queue_xmit+0x14a7/0x2ed0 ip6_finish_output2+0x923/0x1a70 ip6_finish_output+0x2d7/0x970 ip6_output+0x1ce/0x3a0 NF_HOOK.constprop.0+0x15f/0x190 mld_sendpack+0x59a/0xbd0 mld_ifc_work+0x48a/0xa80 process_one_work+0x5aa/0xe50 worker_thread+0x79c/0x1290 kthread+0x28f/0x350 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x11/0x20 Allocated by task 3922: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 __kasan_kmalloc+0x77/0x90 __kmalloc_noprof+0x188/0x400 metadata_dst_alloc+0x1f/0x4e0 macsec_newlink+0x914/0x1410 __rtnl_newlink+0xe08/0x15b0 rtnl_newlink+0x5f/0x90 rtnetlink_rcv_msg+0x667/0xa80 netlink_rcv_skb+0x12c/0x360 netlink_unicast+0x551/0x770 netlink_sendmsg+0x72d/0xbd0 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x52e/0x6a0 ___sys_sendmsg+0xeb/0x170 __sys_sendmsg+0xb5/0x140 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Freed by task 4011: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x50 poison_slab_object+0x10c/0x190 __kasan_slab_free+0x11/0x30 kfree+0xe0/0x290 macsec_free_netdev+0x3f/0x140 netdev_run_todo+0x450/0xc70 rtnetlink_rcv_msg+0x66f/0xa80 netlink_rcv_skb+0x12c/0x360 netlink_unicast+0x551/0x770 netlink_sendmsg+0x72d/0xbd0 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x52e/0x6a0 ___sys_sendmsg+0xeb/0x170 __sys_sendmsg+0xb5/0x140 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53059", "url": "https://ubuntu.com/security/CVE-2024-53059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd() 1. The size of the response packet is not validated. 2. The response buffer is not freed. Resolve these issues by switching to iwl_mvm_send_cmd_status(), which handles both size validation and frees the buffer.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53074", "url": "https://ubuntu.com/security/CVE-2024-53074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: don't leak a link on AP removal Release the link mapping resource in AP removal. This impacted devices that do not support the MLD API (9260 and down). On those devices, we couldn't start the AP again after the AP has been already started and stopped.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53049", "url": "https://ubuntu.com/security/CVE-2024-53049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slub/kunit: fix a WARNING due to unwrapped __kmalloc_cache_noprof 'modprobe slub_kunit' will have a warning as shown below. The root cause is that __kmalloc_cache_noprof was directly used, which resulted in no alloc_tag being allocated. This caused current->alloc_tag to be null, leading to a warning in alloc_tag_add_check. Let's add an alloc_hook layer to __kmalloc_cache_noprof specifically within lib/slub_kunit.c, which is the only user of this internal slub function outside kmalloc implementation itself. [58162.947016] WARNING: CPU: 2 PID: 6210 at ./include/linux/alloc_tag.h:125 alloc_tagging_slab_alloc_hook+0x268/0x27c [58162.957721] Call trace: [58162.957919] alloc_tagging_slab_alloc_hook+0x268/0x27c [58162.958286] __kmalloc_cache_noprof+0x14c/0x344 [58162.958615] test_kmalloc_redzone_access+0x50/0x10c [slub_kunit] [58162.959045] kunit_try_run_case+0x74/0x184 [kunit] [58162.959401] kunit_generic_run_threadfn_adapter+0x2c/0x4c [kunit] [58162.959841] kthread+0x10c/0x118 [58162.960093] ret_from_fork+0x10/0x20 [58162.960363] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50192", "url": "https://ubuntu.com/security/CVE-2024-50192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v4: Don't allow a VMOVP on a dying VPE Kunkun Jiang reported that there is a small window of opportunity for userspace to force a change of affinity for a VPE while the VPE has already been unmapped, but the corresponding doorbell interrupt still visible in /proc/irq/. Plug the race by checking the value of vmapp_count, which tracks whether the VPE is mapped ot not, and returning an error in this case. This involves making vmapp_count common to both GICv4.1 and its v4.0 ancestor.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50069", "url": "https://ubuntu.com/security/CVE-2024-50069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: apple: check devm_kasprintf() returned value devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked. Fix this lack and check the returned value. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50070", "url": "https://ubuntu.com/security/CVE-2024-50070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: stm32: check devm_kasprintf() returned value devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked. Fix this lack and check the returned value. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50196", "url": "https://ubuntu.com/security/CVE-2024-50196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: ocelot: fix system hang on level based interrupts The current implementation only calls chained_irq_enter() and chained_irq_exit() if it detects pending interrupts. ``` for (i = 0; i < info->stride; i++) { \turegmap_read(info->map, id_reg + 4 * i, ®); \tif (!reg) \t\tcontinue; \tchained_irq_enter(parent_chip, desc); ``` However, in case of GPIO pin configured in level mode and the parent controller configured in edge mode, GPIO interrupt might be lowered by the hardware. In the result, if the interrupt is short enough, the parent interrupt is still pending while the GPIO interrupt is cleared; chained_irq_enter() never gets called and the system hangs trying to service the parent interrupt. Moving chained_irq_enter() and chained_irq_exit() outside the for loop ensures that they are called even when GPIO interrupt is lowered by the hardware. The similar code with chained_irq_enter() / chained_irq_exit() functions wrapping interrupt checking loop may be found in many other drivers: ``` grep -r -A 10 chained_irq_enter drivers/pinctrl ```", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50197", "url": "https://ubuntu.com/security/CVE-2024-50197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: intel: platform: fix error path in device_for_each_child_node() The device_for_each_child_node() loop requires calls to fwnode_handle_put() upon early returns to decrement the refcount of the child node and avoid leaking memory if that error path is triggered. There is one early returns within that loop in intel_platform_pinctrl_prepare_community(), but fwnode_handle_put() is missing. Instead of adding the missing call, the scoped version of the loop can be used to simplify the code and avoid mistakes in the future if new early returns are added, as the child node is only used for parsing, and it is never assigned.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50071", "url": "https://ubuntu.com/security/CVE-2024-50071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: nuvoton: fix a double free in ma35_pinctrl_dt_node_to_map_func() 'new_map' is allocated using devm_* which takes care of freeing the allocated data on device removal, call to \t.dt_free_map = pinconf_generic_dt_free_map double frees the map as pinconf_generic_dt_free_map() calls pinctrl_utils_free_map(). Fix this by using kcalloc() instead of auto-managed devm_kcalloc().", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50072", "url": "https://ubuntu.com/security/CVE-2024-50072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/bugs: Use code segment selector for VERW operand Robert Gill reported below #GP in 32-bit mode when dosemu software was executing vm86() system call: general protection fault: 0000 [#1] PREEMPT SMP CPU: 4 PID: 4610 Comm: dosemu.bin Not tainted 6.6.21-gentoo-x86 #1 Hardware name: Dell Inc. PowerEdge 1950/0H723K, BIOS 2.7.0 10/30/2010 EIP: restore_all_switch_stack+0xbe/0xcf EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000 ESI: 00000000 EDI: 00000000 EBP: 00000000 ESP: ff8affdc DS: 0000 ES: 0000 FS: 0000 GS: 0033 SS: 0068 EFLAGS: 00010046 CR0: 80050033 CR2: 00c2101c CR3: 04b6d000 CR4: 000406d0 Call Trace: show_regs+0x70/0x78 die_addr+0x29/0x70 exc_general_protection+0x13c/0x348 exc_bounds+0x98/0x98 handle_exception+0x14d/0x14d exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf This only happens in 32-bit mode when VERW based mitigations like MDS/RFDS are enabled. This is because segment registers with an arbitrary user value can result in #GP when executing VERW. Intel SDM vol. 2C documents the following behavior for VERW instruction: #GP(0) - If a memory operand effective address is outside the CS, DS, ES, \t FS, or GS segment limit. CLEAR_CPU_BUFFERS macro executes VERW instruction before returning to user space. Use %cs selector to reference VERW operand. This ensures VERW will not #GP for an arbitrary user %ds. [ mingo: Fixed the SOB chain. ]", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50073", "url": "https://ubuntu.com/security/CVE-2024-50073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: Fix use-after-free in gsm_cleanup_mux BUG: KASAN: slab-use-after-free in gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] Read of size 8 at addr ffff88815fe99c00 by task poc/3379 CPU: 0 UID: 0 PID: 3379 Comm: poc Not tainted 6.11.0+ #56 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] __pfx_gsm_cleanup_mux+0x10/0x10 drivers/tty/n_gsm.c:3124 [n_gsm] __pfx_sched_clock_cpu+0x10/0x10 kernel/sched/clock.c:389 update_load_avg+0x1c1/0x27b0 kernel/sched/fair.c:4500 __pfx_min_vruntime_cb_rotate+0x10/0x10 kernel/sched/fair.c:846 __rb_insert_augmented+0x492/0xbf0 lib/rbtree.c:161 gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] _raw_spin_lock_irqsave+0x92/0xf0 arch/x86/include/asm/atomic.h:107 __pfx_gsmld_ioctl+0x10/0x10 drivers/tty/n_gsm.c:3822 [n_gsm] ktime_get+0x5e/0x140 kernel/time/timekeeping.c:195 ldsem_down_read+0x94/0x4e0 arch/x86/include/asm/atomic64_64.h:79 __pfx_ldsem_down_read+0x10/0x10 drivers/tty/tty_ldsem.c:338 __pfx_do_vfs_ioctl+0x10/0x10 fs/ioctl.c:805 tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 Allocated by task 65: gsm_data_alloc.constprop.0+0x27/0x190 drivers/tty/n_gsm.c:926 [n_gsm] gsm_send+0x2c/0x580 drivers/tty/n_gsm.c:819 [n_gsm] gsm1_receive+0x547/0xad0 drivers/tty/n_gsm.c:3038 [n_gsm] gsmld_receive_buf+0x176/0x280 drivers/tty/n_gsm.c:3609 [n_gsm] tty_ldisc_receive_buf+0x101/0x1e0 drivers/tty/tty_buffer.c:391 tty_port_default_receive_buf+0x61/0xa0 drivers/tty/tty_port.c:39 flush_to_ldisc+0x1b0/0x750 drivers/tty/tty_buffer.c:445 process_scheduled_works+0x2b0/0x10d0 kernel/workqueue.c:3229 worker_thread+0x3dc/0x950 kernel/workqueue.c:3391 kthread+0x2a3/0x370 kernel/kthread.c:389 ret_from_fork+0x2d/0x70 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:257 Freed by task 3367: kfree+0x126/0x420 mm/slub.c:4580 gsm_cleanup_mux+0x36c/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 [Analysis] gsm_msg on the tx_ctrl_list or tx_data_list of gsm_mux can be freed by multi threads through ioctl,which leads to the occurrence of uaf. Protect it by gsm tx lock.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50193", "url": "https://ubuntu.com/security/CVE-2024-50193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/entry_32: Clear CPU buffers after register restore in NMI return CPU buffers are currently cleared after call to exc_nmi, but before register state is restored. This may be okay for MDS mitigation but not for RDFS. Because RDFS mitigation requires CPU buffers to be cleared when registers don't have any sensitive data. Move CLEAR_CPU_BUFFERS after RESTORE_ALL_NMI.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50074", "url": "https://ubuntu.com/security/CVE-2024-50074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: parport: Proper fix for array out-of-bounds access The recent fix for array out-of-bounds accesses replaced sprintf() calls blindly with snprintf(). However, since snprintf() returns the would-be-printed size, not the actually output size, the length calculation can still go over the given limit. Use scnprintf() instead of snprintf(), which returns the actually output letters, for addressing the potential out-of-bounds access properly.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50100", "url": "https://ubuntu.com/security/CVE-2024-50100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: gadget: dummy-hcd: Fix \"task hung\" problem The syzbot fuzzer has been encountering \"task hung\" problems ever since the dummy-hcd driver was changed to use hrtimers instead of regular timers. It turns out that the problems are caused by a subtle difference between the timer_pending() and hrtimer_active() APIs. The changeover blindly replaced the first by the second. However, timer_pending() returns True when the timer is queued but not when its callback is running, whereas hrtimer_active() returns True when the hrtimer is queued _or_ its callback is running. This difference occasionally caused dummy_urb_enqueue() to think that the callback routine had not yet started when in fact it was almost finished. As a result the hrtimer was not restarted, which made it impossible for the driver to dequeue later the URB that was just enqueued. This caused usb_kill_urb() to hang, and things got worse from there. Since hrtimers have no API for telling when they are queued and the callback isn't running, the driver must keep track of this for itself. That's what this patch does, adding a new \"timer_pending\" flag and setting or clearing it at the appropriate times.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50075", "url": "https://ubuntu.com/security/CVE-2024-50075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xhci: tegra: fix checked USB2 port number If USB virtualizatoin is enabled, USB2 ports are shared between all Virtual Functions. The USB2 port number owned by an USB2 root hub in a Virtual Function may be less than total USB2 phy number supported by the Tegra XUSB controller. Using total USB2 phy number as port number to check all PORTSC values would cause invalid memory access. [ 116.923438] Unable to handle kernel paging request at virtual address 006c622f7665642f ... [ 117.213640] Call trace: [ 117.216783] tegra_xusb_enter_elpg+0x23c/0x658 [ 117.222021] tegra_xusb_runtime_suspend+0x40/0x68 [ 117.227260] pm_generic_runtime_suspend+0x30/0x50 [ 117.232847] __rpm_callback+0x84/0x3c0 [ 117.237038] rpm_suspend+0x2dc/0x740 [ 117.241229] pm_runtime_work+0xa0/0xb8 [ 117.245769] process_scheduled_works+0x24c/0x478 [ 117.251007] worker_thread+0x23c/0x328 [ 117.255547] kthread+0x104/0x1b0 [ 117.259389] ret_from_fork+0x10/0x20 [ 117.263582] Code: 54000222 f9461ae8 f8747908 b4ffff48 (f9400100)", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50076", "url": "https://ubuntu.com/security/CVE-2024-50076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vt: prevent kernel-infoleak in con_font_get() font.data may not initialize all memory spaces depending on the implementation of vc->vc_sw->con_font_get. This may cause info-leak, so to prevent this, it is safest to modify it to initialize the allocated memory space to 0, and it generally does not affect the overall performance of the system.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50077", "url": "https://ubuntu.com/security/CVE-2024-50077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix multiple init when debugfs is disabled If bt_debugfs is not created successfully, which happens if either CONFIG_DEBUG_FS or CONFIG_DEBUG_FS_ALLOW_ALL is unset, then iso_init() returns early and does not set iso_inited to true. This means that a subsequent call to iso_init() will result in duplicate calls to proto_register(), bt_sock_register(), etc. With CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, the duplicate call to proto_register() triggers this BUG(): list_add double add: new=ffffffffc0b280d0, prev=ffffffffbab56250, next=ffffffffc0b280d0. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:35! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 2 PID: 887 Comm: bluetoothd Not tainted 6.10.11-1-ao-desktop #1 RIP: 0010:__list_add_valid_or_report+0x9a/0xa0 ... __list_add_valid_or_report+0x9a/0xa0 proto_register+0x2b5/0x340 iso_init+0x23/0x150 [bluetooth] set_iso_socket_func+0x68/0x1b0 [bluetooth] kmem_cache_free+0x308/0x330 hci_sock_sendmsg+0x990/0x9e0 [bluetooth] __sock_sendmsg+0x7b/0x80 sock_write_iter+0x9a/0x110 do_iter_readv_writev+0x11d/0x220 vfs_writev+0x180/0x3e0 do_writev+0xca/0x100 ... This change removes the early return. The check for iso_debugfs being NULL was unnecessary, it is always NULL when iso_inited is false.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50078", "url": "https://ubuntu.com/security/CVE-2024-50078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Call iso_exit() on module unload If iso_init() has been called, iso_exit() must be called on module unload. Without that, the struct proto that iso_init() registered with proto_register() becomes invalid, which could cause unpredictable problems later. In my case, with CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, loading the module again usually triggers this BUG(): list_add corruption. next->prev should be prev (ffffffffb5355fd0), but was 0000000000000068. (next=ffffffffc0a010d0). ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:29! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 4159 Comm: modprobe Not tainted 6.10.11-4+bt2-ao-desktop #1 RIP: 0010:__list_add_valid_or_report+0x61/0xa0 ... __list_add_valid_or_report+0x61/0xa0 proto_register+0x299/0x320 hci_sock_init+0x16/0xc0 [bluetooth] bt_init+0x68/0xd0 [bluetooth] __pfx_bt_init+0x10/0x10 [bluetooth] do_one_initcall+0x80/0x2f0 do_init_module+0x8b/0x230 __do_sys_init_module+0x15f/0x190 do_syscall_64+0x68/0x110 ...", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50198", "url": "https://ubuntu.com/security/CVE-2024-50198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: veml6030: fix IIO device retrieval from embedded device The dev pointer that is received as an argument in the in_illuminance_period_available_show function references the device embedded in the IIO device, not in the i2c client. dev_to_iio_dev() must be used to accessthe right data. The current implementation leads to a segmentation fault on every attempt to read the attribute because indio_dev gets a NULL assignment. This bug has been present since the first appearance of the driver, apparently since the last version (V6) before getting applied. A constant attribute was used until then, and the last modifications might have not been tested again.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50201", "url": "https://ubuntu.com/security/CVE-2024-50201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: Fix encoder->possible_clones Include the encoder itself in its possible_clones bitmask. In the past nothing validated that drivers were populating possible_clones correctly, but that changed in commit 74d2aacbe840 (\"drm: Validate encoder->possible_clones\"). Looks like radeon never got the memo and is still not following the rules 100% correctly. This results in some warnings during driver initialization: Bogus possible_clones: [ENCODER:46:TV-46] possible_clones=0x4 (full encoder mask=0x7) WARNING: CPU: 0 PID: 170 at drivers/gpu/drm/drm_mode_config.c:615 drm_mode_config_validate+0x113/0x39c ... (cherry picked from commit 3b6e7d40649c0d75572039aff9d0911864c689db)", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50098", "url": "https://ubuntu.com/security/CVE-2024-50098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Set SDEV_OFFLINE when UFS is shut down There is a history of deadlock if reboot is performed at the beginning of booting. SDEV_QUIESCE was set for all LU's scsi_devices by UFS shutdown, and at that time the audio driver was waiting on blk_mq_submit_bio() holding a mutex_lock while reading the fw binary. After that, a deadlock issue occurred while audio driver shutdown was waiting for mutex_unlock of blk_mq_submit_bio(). To solve this, set SDEV_OFFLINE for all LUs except WLUN, so that any I/O that comes down after a UFS shutdown will return an error. [ 31.907781]I[0: swapper/0: 0] 1 130705007 1651079834 11289729804 0 D( 2) 3 ffffff882e208000 * init [device_shutdown] [ 31.907793]I[0: swapper/0: 0] Mutex: 0xffffff8849a2b8b0: owner[0xffffff882e28cb00 kworker/6:0 :49] [ 31.907806]I[0: swapper/0: 0] Call trace: [ 31.907810]I[0: swapper/0: 0] __switch_to+0x174/0x338 [ 31.907819]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc [ 31.907826]I[0: swapper/0: 0] schedule+0x7c/0xe8 [ 31.907834]I[0: swapper/0: 0] schedule_preempt_disabled+0x24/0x40 [ 31.907842]I[0: swapper/0: 0] __mutex_lock+0x408/0xdac [ 31.907849]I[0: swapper/0: 0] __mutex_lock_slowpath+0x14/0x24 [ 31.907858]I[0: swapper/0: 0] mutex_lock+0x40/0xec [ 31.907866]I[0: swapper/0: 0] device_shutdown+0x108/0x280 [ 31.907875]I[0: swapper/0: 0] kernel_restart+0x4c/0x11c [ 31.907883]I[0: swapper/0: 0] __arm64_sys_reboot+0x15c/0x280 [ 31.907890]I[0: swapper/0: 0] invoke_syscall+0x70/0x158 [ 31.907899]I[0: swapper/0: 0] el0_svc_common+0xb4/0xf4 [ 31.907909]I[0: swapper/0: 0] do_el0_svc+0x2c/0xb0 [ 31.907918]I[0: swapper/0: 0] el0_svc+0x34/0xe0 [ 31.907928]I[0: swapper/0: 0] el0t_64_sync_handler+0x68/0xb4 [ 31.907937]I[0: swapper/0: 0] el0t_64_sync+0x1a0/0x1a4 [ 31.908774]I[0: swapper/0: 0] 49 0 11960702 11236868007 0 D( 2) 6 ffffff882e28cb00 * kworker/6:0 [__bio_queue_enter] [ 31.908783]I[0: swapper/0: 0] Call trace: [ 31.908788]I[0: swapper/0: 0] __switch_to+0x174/0x338 [ 31.908796]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc [ 31.908803]I[0: swapper/0: 0] schedule+0x7c/0xe8 [ 31.908811]I[0: swapper/0: 0] __bio_queue_enter+0xb8/0x178 [ 31.908818]I[0: swapper/0: 0] blk_mq_submit_bio+0x194/0x67c [ 31.908827]I[0: swapper/0: 0] __submit_bio+0xb8/0x19c", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50079", "url": "https://ubuntu.com/security/CVE-2024-50079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/sqpoll: ensure task state is TASK_RUNNING when running task_work When the sqpoll is exiting and cancels pending work items, it may need to run task_work. If this happens from within io_uring_cancel_generic(), then it may be under waiting for the io_uring_task waitqueue. This results in the below splat from the scheduler, as the ring mutex may be attempted grabbed while in a TASK_INTERRUPTIBLE state. Ensure that the task state is set appropriately for that, just like what is done for the other cases in io_run_task_work(). do not call blocking ops when !TASK_RUNNING; state=1 set at [<0000000029387fd2>] prepare_to_wait+0x88/0x2fc WARNING: CPU: 6 PID: 59939 at kernel/sched/core.c:8561 __might_sleep+0xf4/0x140 Modules linked in: CPU: 6 UID: 0 PID: 59939 Comm: iou-sqp-59938 Not tainted 6.12.0-rc3-00113-g8d020023b155 #7456 Hardware name: linux,dummy-virt (DT) pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : __might_sleep+0xf4/0x140 lr : __might_sleep+0xf4/0x140 sp : ffff80008c5e7830 x29: ffff80008c5e7830 x28: ffff0000d93088c0 x27: ffff60001c2d7230 x26: dfff800000000000 x25: ffff0000e16b9180 x24: ffff80008c5e7a50 x23: 1ffff000118bcf4a x22: ffff0000e16b9180 x21: ffff0000e16b9180 x20: 000000000000011b x19: ffff80008310fac0 x18: 1ffff000118bcd90 x17: 30303c5b20746120 x16: 74657320313d6574 x15: 0720072007200720 x14: 0720072007200720 x13: 0720072007200720 x12: ffff600036c64f0b x11: 1fffe00036c64f0a x10: ffff600036c64f0a x9 : dfff800000000000 x8 : 00009fffc939b0f6 x7 : ffff0001b6327853 x6 : 0000000000000001 x5 : ffff0001b6327850 x4 : ffff600036c64f0b x3 : ffff8000803c35bc x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000e16b9180 Call trace: __might_sleep+0xf4/0x140 mutex_lock+0x84/0x124 io_handle_tw_list+0xf4/0x260 tctx_task_work_run+0x94/0x340 io_run_task_work+0x1ec/0x3c0 io_uring_cancel_generic+0x364/0x524 io_sq_thread+0x820/0x124c ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50080", "url": "https://ubuntu.com/security/CVE-2024-50080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: don't allow user copy for unprivileged device UBLK_F_USER_COPY requires userspace to call write() on ublk char device for filling request buffer, and unprivileged device can't be trusted. So don't allow user copy for unprivileged device.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50081", "url": "https://ubuntu.com/security/CVE-2024-50081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-mq: setup queue ->tag_set before initializing hctx Commit 7b815817aa58 (\"blk-mq: add helper for checking if one CPU is mapped to specified hctx\") needs to check queue mapping via tag set in hctx's cpuhp handler. However, q->tag_set may not be setup yet when the cpuhp handler is enabled, then kernel oops is triggered. Fix the issue by setup queue tag_set before initializing hctx.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50082", "url": "https://ubuntu.com/security/CVE-2024-50082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race We're seeing crashes from rq_qos_wake_function that look like this: BUG: unable to handle page fault for address: ffffafe180a40084 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 100000067 P4D 100000067 PUD 10027c067 PMD 10115d067 PTE 0 Oops: Oops: 0002 [#1] PREEMPT SMP PTI CPU: 17 UID: 0 PID: 0 Comm: swapper/17 Not tainted 6.12.0-rc3-00013-geca631b8fe80 #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:_raw_spin_lock_irqsave+0x1d/0x40 Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 9c 41 5c fa 65 ff 05 62 97 30 4c 31 c0 ba 01 00 00 00 0f b1 17 75 0a 4c 89 e0 41 5c c3 cc cc cc cc 89 c6 e8 2c 0b 00 RSP: 0018:ffffafe180580ca0 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffffafe180a3f7a8 RCX: 0000000000000011 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffffafe180a40084 RBP: 0000000000000000 R08: 00000000001e7240 R09: 0000000000000011 R10: 0000000000000028 R11: 0000000000000888 R12: 0000000000000002 R13: ffffafe180a40084 R14: 0000000000000000 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff9aaf1f280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffafe180a40084 CR3: 000000010e428002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: try_to_wake_up+0x5a/0x6a0 rq_qos_wake_function+0x71/0x80 __wake_up_common+0x75/0xa0 __wake_up+0x36/0x60 scale_up.part.0+0x50/0x110 wb_timer_fn+0x227/0x450 ... So rq_qos_wake_function() calls wake_up_process(data->task), which calls try_to_wake_up(), which faults in raw_spin_lock_irqsave(&p->pi_lock). p comes from data->task, and data comes from the waitqueue entry, which is stored on the waiter's stack in rq_qos_wait(). Analyzing the core dump with drgn, I found that the waiter had already woken up and moved on to a completely unrelated code path, clobbering what was previously data->task. Meanwhile, the waker was passing the clobbered garbage in data->task to wake_up_process(), leading to the crash. What's happening is that in between rq_qos_wake_function() deleting the waitqueue entry and calling wake_up_process(), rq_qos_wait() is finding that it already got a token and returning. The race looks like this: rq_qos_wait() rq_qos_wake_function() ============================================================== prepare_to_wait_exclusive() data->got_token = true; list_del_init(&curr->entry); if (data.got_token) break; finish_wait(&rqw->wait, &data.wq); ^- returns immediately because list_empty_careful(&wq_entry->entry) is true ... return, go do something else ... wake_up_process(data->task) (NO LONGER VALID!)-^ Normally, finish_wait() is supposed to synchronize against the waker. But, as noted above, it is returning immediately because the waitqueue entry has already been removed from the waitqueue. The bug is that rq_qos_wake_function() is accessing the waitqueue entry AFTER deleting it. Note that autoremove_wake_function() wakes the waiter and THEN deletes the waitqueue entry, which is the proper order. Fix it by swapping the order. We also need to use list_del_init_careful() to match the list_empty_careful() in finish_wait().", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50101", "url": "https://ubuntu.com/security/CVE-2024-50101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI devices Previously, the domain_context_clear() function incorrectly called pci_for_each_dma_alias() to set up context entries for non-PCI devices. This could lead to kernel hangs or other unexpected behavior. Add a check to only call pci_for_each_dma_alias() for PCI devices. For non-PCI devices, domain_context_clear_one() is called directly.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50083", "url": "https://ubuntu.com/security/CVE-2024-50083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix mptcp DSS corruption due to large pmtu xmit Syzkaller was able to trigger a DSS corruption: TCP: request_sock_subflow_v4: Possible SYN flooding on port [::]:20002. Sending cookies. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 5227 at net/mptcp/protocol.c:695 __mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695 Modules linked in: CPU: 0 UID: 0 PID: 5227 Comm: syz-executor350 Not tainted 6.11.0-syzkaller-08829-gaf9c191ac2a0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:__mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695 Code: 0f b6 dc 31 ff 89 de e8 b5 dd ea f5 89 d8 48 81 c4 50 01 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 98 da ea f5 90 <0f> 0b 90 e9 47 ff ff ff e8 8a da ea f5 90 0f 0b 90 e9 99 e0 ff ff RSP: 0018:ffffc90000006db8 EFLAGS: 00010246 RAX: ffffffff8ba9df18 RBX: 00000000000055f0 RCX: ffff888030023c00 RDX: 0000000000000100 RSI: 00000000000081e5 RDI: 00000000000055f0 RBP: 1ffff110062bf1ae R08: ffffffff8ba9cf12 R09: 1ffff110062bf1b8 R10: dffffc0000000000 R11: ffffed10062bf1b9 R12: 0000000000000000 R13: dffffc0000000000 R14: 00000000700cec61 R15: 00000000000081e5 FS: 000055556679c380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020287000 CR3: 0000000077892000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: move_skbs_to_msk net/mptcp/protocol.c:811 [inline] mptcp_data_ready+0x29c/0xa90 net/mptcp/protocol.c:854 subflow_data_ready+0x34a/0x920 net/mptcp/subflow.c:1490 tcp_data_queue+0x20fd/0x76c0 net/ipv4/tcp_input.c:5283 tcp_rcv_established+0xfba/0x2020 net/ipv4/tcp_input.c:6237 tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915 tcp_v4_rcv+0x2dc0/0x37f0 net/ipv4/tcp_ipv4.c:2350 ip_protocol_deliver_rcu+0x22e/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x341/0x5f0 net/ipv4/ip_input.c:233 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314 __netif_receive_skb_one_core net/core/dev.c:5662 [inline] __netif_receive_skb+0x2bf/0x650 net/core/dev.c:5775 process_backlog+0x662/0x15b0 net/core/dev.c:6107 __napi_poll+0xcb/0x490 net/core/dev.c:6771 napi_poll net/core/dev.c:6840 [inline] net_rx_action+0x89b/0x1240 net/core/dev.c:6962 handle_softirqs+0x2c5/0x980 kernel/softirq.c:554 do_softirq+0x11b/0x1e0 kernel/softirq.c:455 __local_bh_enable_ip+0x1bb/0x200 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0x1764/0x3e80 net/core/dev.c:4451 dev_queue_xmit include/linux/netdevice.h:3094 [inline] neigh_hh_output include/net/neighbour.h:526 [inline] neigh_output include/net/neighbour.h:540 [inline] ip_finish_output2+0xd41/0x1390 net/ipv4/ip_output.c:236 ip_local_out net/ipv4/ip_output.c:130 [inline] __ip_queue_xmit+0x118c/0x1b80 net/ipv4/ip_output.c:536 __tcp_transmit_skb+0x2544/0x3b30 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_mtu_probe net/ipv4/tcp_output.c:2547 [inline] tcp_write_xmit+0x641d/0x6bf0 net/ipv4/tcp_output.c:2752 __tcp_push_pending_frames+0x9b/0x360 net/ipv4/tcp_output.c:3015 tcp_push_pending_frames include/net/tcp.h:2107 [inline] tcp_data_snd_check net/ipv4/tcp_input.c:5714 [inline] tcp_rcv_established+0x1026/0x2020 net/ipv4/tcp_input.c:6239 tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915 sk_backlog_rcv include/net/sock.h:1113 [inline] __release_sock+0x214/0x350 net/core/sock.c:3072 release_sock+0x61/0x1f0 net/core/sock.c:3626 mptcp_push_ ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50068", "url": "https://ubuntu.com/security/CVE-2024-50068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/tests/sysfs-kunit.h: fix memory leak in damon_sysfs_test_add_targets() The sysfs_target->regions allocated in damon_sysfs_regions_alloc() is not freed in damon_sysfs_test_add_targets(), which cause the following memory leak, free it to fix it. \tunreferenced object 0xffffff80c2a8db80 (size 96): \t comm \"kunit_try_catch\", pid 187, jiffies 4294894363 \t hex dump (first 32 bytes): \t 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ \t 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ \t backtrace (crc 0): \t [<0000000001e3714d>] kmemleak_alloc+0x34/0x40 \t [<000000008e6835c1>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000001286d9f8>] damon_sysfs_test_add_targets+0x1cc/0x738 \t [<0000000032ef8f77>] kunit_try_run_case+0x13c/0x3ac \t [<00000000f3edea23>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000adf936cf>] kthread+0x2e8/0x374 \t [<0000000041bb1628>] ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50199", "url": "https://ubuntu.com/security/CVE-2024-50199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/swapfile: skip HugeTLB pages for unuse_vma I got a bad pud error and lost a 1GB HugeTLB when calling swapoff. The problem can be reproduced by the following steps: 1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory. 2. Swapout the above anonymous memory. 3. run swapoff and we will get a bad pud error in kernel message: mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7) We can tell that pud_clear_bad is called by pud_none_or_clear_bad in unuse_pud_range() by ftrace. And therefore the HugeTLB pages will never be freed because we lost it from page table. We can skip HugeTLB pages for unuse_vma to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50066", "url": "https://ubuntu.com/security/CVE-2024-50066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mremap: fix move_normal_pmd/retract_page_tables race In mremap(), move_page_tables() looks at the type of the PMD entry and the specified address range to figure out by which method the next chunk of page table entries should be moved. At that point, the mmap_lock is held in write mode, but no rmap locks are held yet. For PMD entries that point to page tables and are fully covered by the source address range, move_pgt_entry(NORMAL_PMD, ...) is called, which first takes rmap locks, then does move_normal_pmd(). move_normal_pmd() takes the necessary page table locks at source and destination, then moves an entire page table from the source to the destination. The problem is: The rmap locks, which protect against concurrent page table removal by retract_page_tables() in the THP code, are only taken after the PMD entry has been read and it has been decided how to move it. So we can race as follows (with two processes that have mappings of the same tmpfs file that is stored on a tmpfs mount with huge=advise); note that process A accesses page tables through the MM while process B does it through the file rmap: process A process B ========= ========= mremap mremap_to move_vma move_page_tables get_old_pmd alloc_new_pmd *** PREEMPT *** madvise(MADV_COLLAPSE) do_madvise madvise_walk_vmas madvise_vma_behavior madvise_collapse hpage_collapse_scan_file collapse_file retract_page_tables i_mmap_lock_read(mapping) pmdp_collapse_flush i_mmap_unlock_read(mapping) move_pgt_entry(NORMAL_PMD, ...) take_rmap_locks move_normal_pmd drop_rmap_locks When this happens, move_normal_pmd() can end up creating bogus PMD entries in the line `pmd_populate(mm, new_pmd, pmd_pgtable(pmd))`. The effect depends on arch-specific and machine-specific details; on x86, you can end up with physical page 0 mapped as a page table, which is likely exploitable for user->kernel privilege escalation. Fix the race by letting process B recheck that the PMD still points to a page table after the rmap locks have been taken. Otherwise, we bail and let the caller fall back to the PTE-level copying path, which will then bail immediately at the pmd_none() check. Bug reachability: Reaching this bug requires that you can create shmem/file THP mappings - anonymous THP uses different code that doesn't zap stuff under rmap locks. File THP is gated on an experimental config flag (CONFIG_READ_ONLY_THP_FOR_FS), so on normal distro kernels you need shmem THP to hit this bug. As far as I know, getting shmem THP normally requires that you can mount your own tmpfs with the right mount flags, which would require creating your own user+mount namespace; though I don't know if some distros maybe enable shmem THP by default or something like that. Bug impact: This issue can likely be used for user->kernel privilege escalation when it is reachable.", "cve_priority": "medium", "cve_public_date": "2024-10-23 06:15:00 UTC" }, { "cve": "CVE-2024-50202", "url": "https://ubuntu.com/security/CVE-2024-50202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: propagate directory read errors from nilfs_find_entry() Syzbot reported that a task hang occurs in vcs_open() during a fuzzing test for nilfs2. The root cause of this problem is that in nilfs_find_entry(), which searches for directory entries, ignores errors when loading a directory page/folio via nilfs_get_folio() fails. If the filesystem images is corrupted, and the i_size of the directory inode is large, and the directory page/folio is successfully read but fails the sanity check, for example when it is zero-filled, nilfs_check_folio() may continue to spit out error messages in bursts. Fix this issue by propagating the error to the callers when loading a page/folio fails in nilfs_find_entry(). The current interface of nilfs_find_entry() and its callers is outdated and cannot propagate error codes such as -EIO and -ENOMEM returned via nilfs_find_entry(), so fix it together.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50200", "url": "https://ubuntu.com/security/CVE-2024-50200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: maple_tree: correct tree corruption on spanning store Patch series \"maple_tree: correct tree corruption on spanning store\", v3. There has been a nasty yet subtle maple tree corruption bug that appears to have been in existence since the inception of the algorithm. This bug seems far more likely to happen since commit f8d112a4e657 (\"mm/mmap: avoid zeroing vma tree in mmap_region()\"), which is the point at which reports started to be submitted concerning this bug. We were made definitely aware of the bug thanks to the kind efforts of Bert Karwatzki who helped enormously in my being able to track this down and identify the cause of it. The bug arises when an attempt is made to perform a spanning store across two leaf nodes, where the right leaf node is the rightmost child of the shared parent, AND the store completely consumes the right-mode node. This results in mas_wr_spanning_store() mitakenly duplicating the new and existing entries at the maximum pivot within the range, and thus maple tree corruption. The fix patch corrects this by detecting this scenario and disallowing the mistaken duplicate copy. The fix patch commit message goes into great detail as to how this occurs. This series also includes a test which reliably reproduces the issue, and asserts that the fix works correctly. Bert has kindly tested the fix and confirmed it resolved his issues. Also Mikhail Gavrilov kindly reported what appears to be precisely the same bug, which this fix should also resolve. This patch (of 2): There has been a subtle bug present in the maple tree implementation from its inception. This arises from how stores are performed - when a store occurs, it will overwrite overlapping ranges and adjust the tree as necessary to accommodate this. A range may always ultimately span two leaf nodes. In this instance we walk the two leaf nodes, determine which elements are not overwritten to the left and to the right of the start and end of the ranges respectively and then rebalance the tree to contain these entries and the newly inserted one. This kind of store is dubbed a 'spanning store' and is implemented by mas_wr_spanning_store(). In order to reach this stage, mas_store_gfp() invokes mas_wr_preallocate(), mas_wr_store_type() and mas_wr_walk() in turn to walk the tree and update the object (mas) to traverse to the location where the write should be performed, determining its store type. When a spanning store is required, this function returns false stopping at the parent node which contains the target range, and mas_wr_store_type() marks the mas->store_type as wr_spanning_store to denote this fact. When we go to perform the store in mas_wr_spanning_store(), we first determine the elements AFTER the END of the range we wish to store (that is, to the right of the entry to be inserted) - we do this by walking to the NEXT pivot in the tree (i.e. r_mas.last + 1), starting at the node we have just determined contains the range over which we intend to write. We then turn our attention to the entries to the left of the entry we are inserting, whose state is represented by l_mas, and copy these into a 'big node', which is a special node which contains enough slots to contain two leaf node's worth of data. We then copy the entry we wish to store immediately after this - the copy and the insertion of the new entry is performed by mas_store_b_node(). After this we copy the elements to the right of the end of the range which we are inserting, if we have not exceeded the length of the node (i.e. r_mas.offset <= r_mas.end). Herein lies the bug - under very specific circumstances, this logic can break and corrupt the maple tree. Consider the following tree: Height 0 Root Node / \\ pivot = 0xffff / \\ pivot = ULONG_MAX / ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50084", "url": "https://ubuntu.com/security/CVE-2024-50084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: microchip: vcap api: Fix memory leaks in vcap_api_encode_rule_test() Commit a3c1e45156ad (\"net: microchip: vcap: Fix use-after-free error in kunit test\") fixed the use-after-free error, but introduced below memory leaks by removing necessary vcap_free_rule(), add it to fix it. \tunreferenced object 0xffffff80ca58b700 (size 192): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898264 \t hex dump (first 32 bytes): \t 00 12 7a 00 05 00 00 00 0a 00 00 00 64 00 00 00 ..z.........d... \t 00 00 00 00 00 00 00 00 00 04 0b cc 80 ff ff ff ................ \t backtrace (crc 9c09c3fe): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<0000000040a01b8d>] vcap_alloc_rule+0x3cc/0x9c4 \t [<000000003fe86110>] vcap_api_encode_rule_test+0x1ac/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0400 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898265 \t hex dump (first 32 bytes): \t 80 04 0b cc 80 ff ff ff 18 b7 58 ca 80 ff ff ff ..........X..... \t 39 00 00 00 02 00 00 00 06 05 04 03 02 01 ff ff 9............... \t backtrace (crc daf014e9): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<00000000dfdb1e81>] vcap_api_encode_rule_test+0x224/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0700 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898265 \t hex dump (first 32 bytes): \t 80 07 0b cc 80 ff ff ff 28 b7 58 ca 80 ff ff ff ........(.X..... \t 3c 00 00 00 00 00 00 00 01 2f 03 b3 ec ff ff ff <......../...... \t backtrace (crc 8d877792): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000006eadfab7>] vcap_rule_add_action+0x2d0/0x52c \t [<00000000323475d1>] vcap_api_encode_rule_test+0x4d4/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0900 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898266 \t hex dump (first 32 bytes): \t 80 09 0b cc 80 ff ff ff 80 06 0b cc 80 ff ff ff ................ \t 7d 00 00 00 01 00 00 00 00 00 00 00 ff 00 00 00 }............... \t backtrace (crc 34181e56): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<00000000991e3564>] vcap_val_rule+0xcf0/0x13e8 \t [<00000000fc9868e5>] vcap_api_encode_rule_test+0x678/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0980 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898266 \t hex dump (first 32 bytes): \t 18 b7 58 ca 80 ff ff ff 00 09 0b cc 80 ff ff ff ..X............. \t 67 00 00 00 00 00 00 00 01 01 74 88 c0 ff ff ff g.........t..... \t backtrace (crc 275fd9be): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<000000001396a1a2>] test_add_de ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50194", "url": "https://ubuntu.com/security/CVE-2024-50194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Fix uprobes for big-endian kernels The arm64 uprobes code is broken for big-endian kernels as it doesn't convert the in-memory instruction encoding (which is always little-endian) into the kernel's native endianness before analyzing and simulating instructions. This may result in a few distinct problems: * The kernel may may erroneously reject probing an instruction which can safely be probed. * The kernel may erroneously erroneously permit stepping an instruction out-of-line when that instruction cannot be stepped out-of-line safely. * The kernel may erroneously simulate instruction incorrectly dur to interpretting the byte-swapped encoding. The endianness mismatch isn't caught by the compiler or sparse because: * The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so the compiler and sparse have no idea these contain a little-endian 32-bit value. The core uprobes code populates these with a memcpy() which similarly does not handle endianness. * While the uprobe_opcode_t type is an alias for __le32, both arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[] to the similarly-named probe_opcode_t, which is an alias for u32. Hence there is no endianness conversion warning. Fix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and adding the appropriate __le32_to_cpu() conversions prior to consuming the instruction encoding. The core uprobes copies these fields as opaque ranges of bytes, and so is unaffected by this change. At the same time, remove MAX_UINSN_BYTES and consistently use AARCH64_INSN_SIZE for clarity. Tested with the following: | #include | #include | | #define noinline __attribute__((noinline)) | | static noinline void *adrp_self(void) | { | void *addr; | | asm volatile( | \" adrp %x0, adrp_self\\n\" | \" add %x0, %x0, :lo12:adrp_self\\n\" | : \"=r\" (addr)); | } | | | int main(int argc, char *argv) | { | void *ptr = adrp_self(); | bool equal = (ptr == adrp_self); | | printf(\"adrp_self => %p\\n\" | \"adrp_self() => %p\\n\" | \"%s\\n\", | adrp_self, ptr, equal ? \"EQUAL\" : \"NOT EQUAL\"); | | return 0; | } .... where the adrp_self() function was compiled to: | 00000000004007e0 : | 4007e0: 90000000 adrp x0, 400000 <__ehdr_start> | 4007e4: 911f8000 add x0, x0, #0x7e0 | 4007e8: d65f03c0 ret Before this patch, the ADRP is not recognized, and is assumed to be steppable, resulting in corruption of the result: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0xffffffffff7e0 | NOT EQUAL After this patch, the ADRP is correctly recognized and simulated: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50099", "url": "https://ubuntu.com/security/CVE-2024-50099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Remove broken LDR (literal) uprobe support The simulate_ldr_literal() and simulate_ldrsw_literal() functions are unsafe to use for uprobes. Both functions were originally written for use with kprobes, and access memory with plain C accesses. When uprobes was added, these were reused unmodified even though they cannot safely access user memory. There are three key problems: 1) The plain C accesses do not have corresponding extable entries, and thus if they encounter a fault the kernel will treat these as unintentional accesses to user memory, resulting in a BUG() which will kill the kernel thread, and likely lead to further issues (e.g. lockup or panic()). 2) The plain C accesses are subject to HW PAN and SW PAN, and so when either is in use, any attempt to simulate an access to user memory will fault. Thus neither simulate_ldr_literal() nor simulate_ldrsw_literal() can do anything useful when simulating a user instruction on any system with HW PAN or SW PAN. 3) The plain C accesses are privileged, as they run in kernel context, and in practice can access a small range of kernel virtual addresses. The instructions they simulate have a range of +/-1MiB, and since the simulated instructions must itself be a user instructions in the TTBR0 address range, these can address the final 1MiB of the TTBR1 acddress range by wrapping downwards from an address in the first 1MiB of the TTBR0 address range. In contemporary kernels the last 8MiB of TTBR1 address range is reserved, and accesses to this will always fault, meaning this is no worse than (1). Historically, it was theoretically possible for the linear map or vmemmap to spill into the final 8MiB of the TTBR1 address range, but in practice this is extremely unlikely to occur as this would require either: * Having enough physical memory to fill the entire linear map all the way to the final 1MiB of the TTBR1 address range. * Getting unlucky with KASLR randomization of the linear map such that the populated region happens to overlap with the last 1MiB of the TTBR address range. ... and in either case if we were to spill into the final page there would be larger problems as the final page would alias with error pointers. Practically speaking, (1) and (2) are the big issues. Given there have been no reports of problems since the broken code was introduced, it appears that no-one is relying on probing these instructions with uprobes. Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW (literal), limiting the use of simulate_ldr_literal() and simulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR (literal) and LDRSW (literal) will be rejected as arm_probe_decode_insn() will return INSN_REJECTED. In future we can consider introducing working uprobes support for these instructions, but this will require more significant work.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50195", "url": "https://ubuntu.com/security/CVE-2024-50195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-clock: Fix missing timespec64 check in pc_clock_settime() As Andrew pointed out, it will make sense that the PTP core checked timespec64 struct's tv_sec and tv_nsec range before calling ptp->info->settime64(). As the man manual of clock_settime() said, if tp.tv_sec is negative or tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL, which include dynamic clocks which handles PTP clock, and the condition is consistent with timespec64_valid(). As Thomas suggested, timespec64_valid() only check the timespec is valid, but not ensure that the time is in a valid range, so check it ahead using timespec64_valid_strict() in pc_clock_settime() and return -EINVAL if not valid. There are some drivers that use tp->tv_sec and tp->tv_nsec directly to write registers without validity checks and assume that the higher layer has checked it, which is dangerous and will benefit from this, such as hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(), and some drivers can remove the checks of itself.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50085", "url": "https://ubuntu.com/security/CVE-2024-50085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: fix UaF read in mptcp_pm_nl_rm_addr_or_subflow Syzkaller reported this splat: ================================================================== BUG: KASAN: slab-use-after-free in mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881 Read of size 4 at addr ffff8880569ac858 by task syz.1.2799/14662 CPU: 0 UID: 0 PID: 14662 Comm: syz.1.2799 Not tainted 6.12.0-rc2-syzkaller-00307-g36c254515dc6 #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+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881 mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:914 [inline] mptcp_nl_remove_id_zero_address+0x305/0x4a0 net/mptcp/pm_netlink.c:1572 mptcp_pm_nl_del_addr_doit+0x5c9/0x770 net/mptcp/pm_netlink.c:1603 genl_family_rcv_msg_doit+0x202/0x2f0 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x565/0x800 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x165/0x410 net/netlink/af_netlink.c:2551 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1331 [inline] netlink_unicast+0x53c/0x7f0 net/netlink/af_netlink.c:1357 netlink_sendmsg+0x8b8/0xd70 net/netlink/af_netlink.c:1901 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg net/socket.c:744 [inline] ____sys_sendmsg+0x9ae/0xb40 net/socket.c:2607 ___sys_sendmsg+0x135/0x1e0 net/socket.c:2661 __sys_sendmsg+0x117/0x1f0 net/socket.c:2690 do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline] __do_fast_syscall_32+0x73/0x120 arch/x86/entry/common.c:386 do_fast_syscall_32+0x32/0x80 arch/x86/entry/common.c:411 entry_SYSENTER_compat_after_hwframe+0x84/0x8e RIP: 0023:0xf7fe4579 Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00 RSP: 002b:00000000f574556c EFLAGS: 00000296 ORIG_RAX: 0000000000000172 RAX: ffffffffffffffda RBX: 000000000000000b RCX: 0000000020000140 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000296 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Allocated by task 5387: 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 kmalloc_noprof include/linux/slab.h:878 [inline] kzalloc_noprof include/linux/slab.h:1014 [inline] subflow_create_ctx+0x87/0x2a0 net/mptcp/subflow.c:1803 subflow_ulp_init+0xc3/0x4d0 net/mptcp/subflow.c:1956 __tcp_set_ulp net/ipv4/tcp_ulp.c:146 [inline] tcp_set_ulp+0x326/0x7f0 net/ipv4/tcp_ulp.c:167 mptcp_subflow_create_socket+0x4ae/0x10a0 net/mptcp/subflow.c:1764 __mptcp_subflow_connect+0x3cc/0x1490 net/mptcp/subflow.c:1592 mptcp_pm_create_subflow_or_signal_addr+0xbda/0x23a0 net/mptcp/pm_netlink.c:642 mptcp_pm_nl_fully_established net/mptcp/pm_netlink.c:650 [inline] mptcp_pm_nl_work+0x3a1/0x4f0 net/mptcp/pm_netlink.c:943 mptcp_worker+0x15a/0x1240 net/mptcp/protocol.c:2777 process_one_work+0x958/0x1b30 kernel/workqueue.c:3229 process_scheduled_works kernel/workqueue.c:3310 [inline] worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/ke ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50086", "url": "https://ubuntu.com/security/CVE-2024-50086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix user-after-free from session log off There is racy issue between smb2 session log off and smb2 session setup. It will cause user-after-free from session log off. This add session_lock when setting SMB2_SESSION_EXPIRED and referece count to session struct not to free session while it is being used.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50087", "url": "https://ubuntu.com/security/CVE-2024-50087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix uninitialized pointer free on read_alloc_one_name() error The function read_alloc_one_name() does not initialize the name field of the passed fscrypt_str struct if kmalloc fails to allocate the corresponding buffer. Thus, it is not guaranteed that fscrypt_str.name is initialized when freeing it. This is a follow-up to the linked patch that fixes the remaining instances of the bug introduced by commit e43eec81c516 (\"btrfs: use struct qstr instead of name and namelen pairs\").", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50088", "url": "https://ubuntu.com/security/CVE-2024-50088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix uninitialized pointer free in add_inode_ref() The add_inode_ref() function does not initialize the \"name\" struct when it is declared. If any of the following calls to \"read_one_inode() returns NULL, \tdir = read_one_inode(root, parent_objectid); \tif (!dir) { \t\tret = -ENOENT; \t\tgoto out; \t} \tinode = read_one_inode(root, inode_objectid); \tif (!inode) { \t\tret = -EIO; \t\tgoto out; \t} then \"name.name\" would be freed on \"out\" before being initialized. out: \t... \tkfree(name.name); This issue was reported by Coverity with CID 1526744.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50182", "url": "https://ubuntu.com/security/CVE-2024-50182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: secretmem: disable memfd_secret() if arch cannot set direct map Return -ENOSYS from memfd_secret() syscall if !can_set_direct_map(). This is the case for example on some arm64 configurations, where marking 4k PTEs in the direct map not present can only be done if the direct map is set up at 4k granularity in the first place (as ARM's break-before-make semantics do not easily allow breaking apart large/gigantic pages). More precisely, on arm64 systems with !can_set_direct_map(), set_direct_map_invalid_noflush() is a no-op, however it returns success (0) instead of an error. This means that memfd_secret will seemingly \"work\" (e.g. syscall succeeds, you can mmap the fd and fault in pages), but it does not actually achieve its goal of removing its memory from the direct map. Note that with this patch, memfd_secret() will start erroring on systems where can_set_direct_map() returns false (arm64 with CONFIG_RODATA_FULL_DEFAULT_ENABLED=n, CONFIG_DEBUG_PAGEALLOC=n and CONFIG_KFENCE=n), but that still seems better than the current silent failure. Since CONFIG_RODATA_FULL_DEFAULT_ENABLED defaults to 'y', most arm64 systems actually have a working memfd_secret() and aren't be affected. From going through the iterations of the original memfd_secret patch series, it seems that disabling the syscall in these scenarios was the intended behavior [1] (preferred over having set_direct_map_invalid_noflush return an error as that would result in SIGBUSes at page-fault time), however the check for it got dropped between v16 [2] and v17 [3], when secretmem moved away from CMA allocations. [1]: https://lore.kernel.org/lkml/20201124164930.GK8537@kernel.org/ [2]: https://lore.kernel.org/lkml/20210121122723.3446-11-rppt@kernel.org/#t [3]: https://lore.kernel.org/lkml/20201125092208.12544-10-rppt@kernel.org/", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50019", "url": "https://ubuntu.com/security/CVE-2024-50019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kthread: unpark only parked kthread Calling into kthread unparking unconditionally is mostly harmless when the kthread is already unparked. The wake up is then simply ignored because the target is not in TASK_PARKED state. However if the kthread is per CPU, the wake up is preceded by a call to kthread_bind() which expects the task to be inactive and in TASK_PARKED state, which obviously isn't the case if it is unparked. As a result, calling kthread_stop() on an unparked per-cpu kthread triggers such a warning: \tWARNING: CPU: 0 PID: 11 at kernel/kthread.c:525 __kthread_bind_mask kernel/kthread.c:525 \t \t kthread_stop+0x17a/0x630 kernel/kthread.c:707 \t destroy_workqueue+0x136/0xc40 kernel/workqueue.c:5810 \t wg_destruct+0x1e2/0x2e0 drivers/net/wireguard/device.c:257 \t netdev_run_todo+0xe1a/0x1000 net/core/dev.c:10693 \t default_device_exit_batch+0xa14/0xa90 net/core/dev.c:11769 \t ops_exit_list net/core/net_namespace.c:178 [inline] \t cleanup_net+0x89d/0xcc0 net/core/net_namespace.c:640 \t process_one_work kernel/workqueue.c:3231 [inline] \t process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 \t worker_thread+0x86d/0xd70 kernel/workqueue.c:3393 \t kthread+0x2f0/0x390 kernel/kthread.c:389 \t ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 \t ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 \t Fix this with skipping unecessary unparking while stopping a kthread.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50096", "url": "https://ubuntu.com/security/CVE-2024-50096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/dmem: Fix vulnerability in migrate_to_ram upon copy error The `nouveau_dmem_copy_one` function ensures that the copy push command is sent to the device firmware but does not track whether it was executed successfully. In the case of a copy error (e.g., firmware or hardware failure), the copy push command will be sent via the firmware channel, and `nouveau_dmem_copy_one` will likely report success, leading to the `migrate_to_ram` function returning a dirty HIGH_USER page to the user. This can result in a security vulnerability, as a HIGH_USER page that may contain sensitive or corrupted data could be returned to the user. To prevent this vulnerability, we allocate a zero page. Thus, in case of an error, a non-dirty (zero) page will be returned to the user.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50020", "url": "https://ubuntu.com/security/CVE-2024-50020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix improper handling of refcount in ice_sriov_set_msix_vec_count() This patch addresses an issue with improper reference count handling in the ice_sriov_set_msix_vec_count() function. First, the function calls ice_get_vf_by_id(), which increments the reference count of the vf pointer. If the subsequent call to ice_get_vf_vsi() fails, the function currently returns an error without decrementing the reference count of the vf pointer, leading to a reference count leak. The correct behavior, as implemented in this patch, is to decrement the reference count using ice_put_vf(vf) before returning an error when vsi is NULL. Second, the function calls ice_sriov_get_irqs(), which sets vf->first_vector_idx. If this call returns a negative value, indicating an error, the function returns an error without decrementing the reference count of the vf pointer, resulting in another reference count leak. The patch addresses this by adding a call to ice_put_vf(vf) before returning an error when vf->first_vector_idx < 0. This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and identifying potential mismanagement of reference counts. In this case, the tool flagged the missing decrement operation as a potential issue, leading to this patch.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50021", "url": "https://ubuntu.com/security/CVE-2024-50021", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix improper handling of refcount in ice_dpll_init_rclk_pins() This patch addresses a reference count handling issue in the ice_dpll_init_rclk_pins() function. The function calls ice_dpll_get_pins(), which increments the reference count of the relevant resources. However, if the condition WARN_ON((!vsi || !vsi->netdev)) is met, the function currently returns an error without properly releasing the resources acquired by ice_dpll_get_pins(), leading to a reference count leak. To resolve this, the check has been moved to the top of the function. This ensures that the function verifies the state before any resources are acquired, avoiding the need for additional resource management in the error path. This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and detecting potential issues where resources are not properly managed. In this case, the tool flagged the missing release operation as a potential problem, which led to the development of this patch.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50022", "url": "https://ubuntu.com/security/CVE-2024-50022", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: device-dax: correct pgoff align in dax_set_mapping() pgoff should be aligned using ALIGN_DOWN() instead of ALIGN(). Otherwise, vmf->address not aligned to fault_size will be aligned to the next alignment, that can result in memory failure getting the wrong address. It's a subtle situation that only can be observed in page_mapped_in_vma() after the page is page fault handled by dev_dax_huge_fault. Generally, there is little chance to perform page_mapped_in_vma in dev-dax's page unless in specific error injection to the dax device to trigger an MCE - memory-failure. In that case, page_mapped_in_vma() will be triggered to determine which task is accessing the failure address and kill that task in the end. We used self-developed dax device (which is 2M aligned mapping) , to perform error injection to random address. It turned out that error injected to non-2M-aligned address was causing endless MCE until panic. Because page_mapped_in_vma() kept resulting wrong address and the task accessing the failure address was never killed properly: [ 3783.719419] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.049006] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.049190] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.448042] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.448186] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.792026] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.792179] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.162502] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.162633] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.461116] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.461247] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.764730] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.764859] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.042128] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.042259] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.464293] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.464423] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.818090] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.818217] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3787.085297] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3787.085424] Memory failure: 0x200c9742: recovery action for dax page: Recovered It took us several weeks to pinpoint this problem,  but we eventually used bpftrace to trace the page fault and mce address and successfully identified the issue. Joao added: ; Likely we never reproduce in production because we always pin : device-dax regions in the region align they provide (Qemu does : similarly with prealloc in hugetlb/file backed memory). I think this : bug requires that we touch *unpinned* device-dax regions unaligned to : the device-dax selected alignment (page size i.e. 4K/2M/1G)", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50185", "url": "https://ubuntu.com/security/CVE-2024-50185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: handle consistently DSS corruption Bugged peer implementation can send corrupted DSS options, consistently hitting a few warning in the data path. Use DEBUG_NET assertions, to avoid the splat on some builds and handle consistently the error, dumping related MIBs and performing fallback and/or reset according to the subflow type.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50023", "url": "https://ubuntu.com/security/CVE-2024-50023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: Remove LED entry from LEDs list on unregister Commit c938ab4da0eb (\"net: phy: Manual remove LEDs to ensure correct ordering\") correctly fixed a problem with using devm_ but missed removing the LED entry from the LEDs list. This cause kernel panic on specific scenario where the port for the PHY is torn down and up and the kmod for the PHY is removed. On setting the port down the first time, the assosiacted LEDs are correctly unregistered. The associated kmod for the PHY is now removed. The kmod is now added again and the port is now put up, the associated LED are registered again. On putting the port down again for the second time after these step, the LED list now have 4 elements. With the first 2 already unregistered previously and the 2 new one registered again. This cause a kernel panic as the first 2 element should have been removed. Fix this by correctly removing the element when LED is unregistered.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50024", "url": "https://ubuntu.com/security/CVE-2024-50024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: Fix an unsafe loop on the list The kernel may crash when deleting a genetlink family if there are still listeners for that family: Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c000000000c080bc] netlink_update_socket_mc+0x3c/0xc0 LR [c000000000c0f764] __netlink_clear_multicast_users+0x74/0xc0 Call Trace: __netlink_clear_multicast_users+0x74/0xc0 genl_unregister_family+0xd4/0x2d0 Change the unsafe loop on the list to a safe one, because inside the loop there is an element removal from this list.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50186", "url": "https://ubuntu.com/security/CVE-2024-50186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: explicitly clear the sk pointer, when pf->create fails We have recently noticed the exact same KASAN splat as in commit 6cd4a78d962b (\"net: do not leave a dangling sk pointer, when socket creation fails\"). The problem is that commit did not fully address the problem, as some pf->create implementations do not use sk_common_release in their error paths. For example, we can use the same reproducer as in the above commit, but changing ping to arping. arping uses AF_PACKET socket and if packet_create fails, it will just sk_free the allocated sk object. While we could chase all the pf->create implementations and make sure they NULL the freed sk object on error from the socket, we can't guarantee future protocols will not make the same mistake. So it is easier to just explicitly NULL the sk pointer upon return from pf->create in __sock_create. We do know that pf->create always releases the allocated sk object on error, so if the pointer is not NULL, it is definitely dangling.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50025", "url": "https://ubuntu.com/security/CVE-2024-50025", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: fnic: Move flush_work initialization out of if block After commit 379a58caa199 (\"scsi: fnic: Move fnic_fnic_flush_tx() to a work queue\"), it can happen that a work item is sent to an uninitialized work queue. This may has the effect that the item being queued is never actually queued, and any further actions depending on it will not proceed. The following warning is observed while the fnic driver is loaded: kernel: WARNING: CPU: 11 PID: 0 at ../kernel/workqueue.c:1524 __queue_work+0x373/0x410 kernel: kernel: queue_work_on+0x3a/0x50 kernel: fnic_wq_copy_cmpl_handler+0x54a/0x730 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: fnic_isr_msix_wq_copy+0x2d/0x60 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: __handle_irq_event_percpu+0x36/0x1a0 kernel: handle_irq_event_percpu+0x30/0x70 kernel: handle_irq_event+0x34/0x60 kernel: handle_edge_irq+0x7e/0x1a0 kernel: __common_interrupt+0x3b/0xb0 kernel: common_interrupt+0x58/0xa0 kernel: It has been observed that this may break the rediscovery of Fibre Channel devices after a temporary fabric failure. This patch fixes it by moving the work queue initialization out of an if block in fnic_probe().", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50026", "url": "https://ubuntu.com/security/CVE-2024-50026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: wd33c93: Don't use stale scsi_pointer value A regression was introduced with commit dbb2da557a6a (\"scsi: wd33c93: Move the SCSI pointer to private command data\") which results in an oops in wd33c93_intr(). That commit added the scsi_pointer variable and initialized it from hostdata->connected. However, during selection, hostdata->connected is not yet valid. Fix this by getting the current scsi_pointer from hostdata->selecting.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50027", "url": "https://ubuntu.com/security/CVE-2024-50027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: core: Free tzp copy along with the thermal zone The object pointed to by tz->tzp may still be accessed after being freed in thermal_zone_device_unregister(), so move the freeing of it to the point after the removal completion has been completed at which it cannot be accessed any more.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50028", "url": "https://ubuntu.com/security/CVE-2024-50028", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: core: Reference count the zone in thermal_zone_get_by_id() There are places in the thermal netlink code where nothing prevents the thermal zone object from going away while being accessed after it has been returned by thermal_zone_get_by_id(). To address this, make thermal_zone_get_by_id() get a reference on the thermal zone device object to be returned with the help of get_device(), under thermal_list_lock, and adjust all of its callers to this change with the help of the cleanup.h infrastructure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50029", "url": "https://ubuntu.com/security/CVE-2024-50029", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_conn: Fix UAF in hci_enhanced_setup_sync This checks if the ACL connection remains valid as it could be destroyed while hci_enhanced_setup_sync is pending on cmd_sync leading to the following trace: BUG: KASAN: slab-use-after-free in hci_enhanced_setup_sync+0x91b/0xa60 Read of size 1 at addr ffff888002328ffd by task kworker/u5:2/37 CPU: 0 UID: 0 PID: 37 Comm: kworker/u5:2 Not tainted 6.11.0-rc6-01300-g810be445d8d6 #7099 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Workqueue: hci0 hci_cmd_sync_work Call Trace: dump_stack_lvl+0x5d/0x80 ? hci_enhanced_setup_sync+0x91b/0xa60 print_report+0x152/0x4c0 ? hci_enhanced_setup_sync+0x91b/0xa60 ? __virt_addr_valid+0x1fa/0x420 ? hci_enhanced_setup_sync+0x91b/0xa60 kasan_report+0xda/0x1b0 ? hci_enhanced_setup_sync+0x91b/0xa60 hci_enhanced_setup_sync+0x91b/0xa60 ? __pfx_hci_enhanced_setup_sync+0x10/0x10 ? __pfx___mutex_lock+0x10/0x10 hci_cmd_sync_work+0x1c2/0x330 process_one_work+0x7d9/0x1360 ? __pfx_lock_acquire+0x10/0x10 ? __pfx_process_one_work+0x10/0x10 ? assign_work+0x167/0x240 worker_thread+0x5b7/0xf60 ? __kthread_parkme+0xac/0x1c0 ? __pfx_worker_thread+0x10/0x10 ? __pfx_worker_thread+0x10/0x10 kthread+0x293/0x360 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2f/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 34: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __hci_conn_add+0x187/0x17d0 hci_connect_sco+0x2e1/0xb90 sco_sock_connect+0x2a2/0xb80 __sys_connect+0x227/0x2a0 __x64_sys_connect+0x6d/0xb0 do_syscall_64+0x71/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 37: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x101/0x160 kfree+0xd0/0x250 device_release+0x9a/0x210 kobject_put+0x151/0x280 hci_conn_del+0x448/0xbf0 hci_abort_conn_sync+0x46f/0x980 hci_cmd_sync_work+0x1c2/0x330 process_one_work+0x7d9/0x1360 worker_thread+0x5b7/0xf60 kthread+0x293/0x360 ret_from_fork+0x2f/0x70 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50030", "url": "https://ubuntu.com/security/CVE-2024-50030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/ct: prevent UAF in send_recv() Ensure we serialize with completion side to prevent UAF with fence going out of scope on the stack, since we have no clue if it will fire after the timeout before we can erase from the xa. Also we have some dependent loads and stores for which we need the correct ordering, and we lack the needed barriers. Fix this by grabbing the ct->lock after the wait, which is also held by the completion side. v2 (Badal): - Also print done after acquiring the lock and seeing timeout. (cherry picked from commit 52789ce35c55ccd30c4b67b9cc5b2af55e0122ea)", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50187", "url": "https://ubuntu.com/security/CVE-2024-50187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Stop the active perfmon before being destroyed Upon closing the file descriptor, the active performance monitor is not stopped. Although all perfmons are destroyed in `vc4_perfmon_close_file()`, the active performance monitor's pointer (`vc4->active_perfmon`) is still retained. If we open a new file descriptor and submit a few jobs with performance monitors, the driver will attempt to stop the active performance monitor using the stale pointer in `vc4->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50031", "url": "https://ubuntu.com/security/CVE-2024-50031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Stop the active perfmon before being destroyed When running `kmscube` with one or more performance monitors enabled via `GALLIUM_HUD`, the following kernel panic can occur: [ 55.008324] Unable to handle kernel paging request at virtual address 00000000052004a4 [ 55.008368] Mem abort info: [ 55.008377] ESR = 0x0000000096000005 [ 55.008387] EC = 0x25: DABT (current EL), IL = 32 bits [ 55.008402] SET = 0, FnV = 0 [ 55.008412] EA = 0, S1PTW = 0 [ 55.008421] FSC = 0x05: level 1 translation fault [ 55.008434] Data abort info: [ 55.008442] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 55.008455] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 55.008467] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 55.008481] user pgtable: 4k pages, 39-bit VAs, pgdp=00000001046c6000 [ 55.008497] [00000000052004a4] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 55.008525] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP [ 55.008542] Modules linked in: rfcomm [...] vc4 v3d snd_soc_hdmi_codec drm_display_helper gpu_sched drm_shmem_helper cec drm_dma_helper drm_kms_helper i2c_brcmstb drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight [ 55.008799] CPU: 2 PID: 166 Comm: v3d_bin Tainted: G C 6.6.47+rpt-rpi-v8 #1 Debian 1:6.6.47-1+rpt1 [ 55.008824] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [ 55.008838] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 55.008855] pc : __mutex_lock.constprop.0+0x90/0x608 [ 55.008879] lr : __mutex_lock.constprop.0+0x58/0x608 [ 55.008895] sp : ffffffc080673cf0 [ 55.008904] x29: ffffffc080673cf0 x28: 0000000000000000 x27: ffffff8106188a28 [ 55.008926] x26: ffffff8101e78040 x25: ffffff8101baa6c0 x24: ffffffd9d989f148 [ 55.008947] x23: ffffffda1c2a4008 x22: 0000000000000002 x21: ffffffc080673d38 [ 55.008968] x20: ffffff8101238000 x19: ffffff8104f83188 x18: 0000000000000000 [ 55.008988] x17: 0000000000000000 x16: ffffffda1bd04d18 x15: 00000055bb08bc90 [ 55.009715] x14: 0000000000000000 x13: 0000000000000000 x12: ffffffda1bd4cbb0 [ 55.010433] x11: 00000000fa83b2da x10: 0000000000001a40 x9 : ffffffda1bd04d04 [ 55.011162] x8 : ffffff8102097b80 x7 : 0000000000000000 x6 : 00000000030a5857 [ 55.011880] x5 : 00ffffffffffffff x4 : 0300000005200470 x3 : 0300000005200470 [ 55.012598] x2 : ffffff8101238000 x1 : 0000000000000021 x0 : 0300000005200470 [ 55.013292] Call trace: [ 55.013959] __mutex_lock.constprop.0+0x90/0x608 [ 55.014646] __mutex_lock_slowpath+0x1c/0x30 [ 55.015317] mutex_lock+0x50/0x68 [ 55.015961] v3d_perfmon_stop+0x40/0xe0 [v3d] [ 55.016627] v3d_bin_job_run+0x10c/0x2d8 [v3d] [ 55.017282] drm_sched_main+0x178/0x3f8 [gpu_sched] [ 55.017921] kthread+0x11c/0x128 [ 55.018554] ret_from_fork+0x10/0x20 [ 55.019168] Code: f9400260 f1001c1f 54001ea9 927df000 (b9403401) [ 55.019776] ---[ end trace 0000000000000000 ]--- [ 55.020411] note: v3d_bin[166] exited with preempt_count 1 This issue arises because, upon closing the file descriptor (which happens when we interrupt `kmscube`), the active performance monitor is not stopped. Although all perfmons are destroyed in `v3d_perfmon_close_file()`, the active performance monitor's pointer (`v3d->active_perfmon`) is still retained. If `kmscube` is run again, the driver will attempt to stop the active performance monitor using the stale pointer in `v3d->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50189", "url": "https://ubuntu.com/security/CVE-2024-50189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: amd_sfh: Switch to device-managed dmam_alloc_coherent() Using the device-managed version allows to simplify clean-up in probe() error path. Additionally, this device-managed ensures proper cleanup, which helps to resolve memory errors, page faults, btrfs going read-only, and btrfs disk corruption.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50033", "url": "https://ubuntu.com/security/CVE-2024-50033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slip: make slhc_remember() more robust against malicious packets syzbot found that slhc_remember() was missing checks against malicious packets [1]. slhc_remember() only checked the size of the packet was at least 20, which is not good enough. We need to make sure the packet includes the IPv4 and TCP header that are supposed to be carried. Add iph and th pointers to make the code more readable. [1] BUG: KMSAN: uninit-value in slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 ppp_receive_nonmp_frame+0xe45/0x35e0 drivers/net/ppp/ppp_generic.c:2455 ppp_receive_frame drivers/net/ppp/ppp_generic.c:2372 [inline] ppp_do_recv+0x65f/0x40d0 drivers/net/ppp/ppp_generic.c:2212 ppp_input+0x7dc/0xe60 drivers/net/ppp/ppp_generic.c:2327 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 Uninit was created at: slab_post_alloc_hook mm/slub.c:4091 [inline] slab_alloc_node mm/slub.c:4134 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 CPU: 0 UID: 0 PID: 5460 Comm: syz.2.33 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50034", "url": "https://ubuntu.com/security/CVE-2024-50034", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix lacks of icsk_syn_mss with IPPROTO_SMC Eric report a panic on IPPROTO_SMC, and give the facts that when INET_PROTOSW_ICSK was set, icsk->icsk_sync_mss must be set too. Bug: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000086000005 EC = 0x21: IABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault user pgtable: 4k pages, 48-bit VAs, pgdp=00000001195d1000 [0000000000000000] pgd=0800000109c46003, p4d=0800000109c46003, pud=0000000000000000 Internal error: Oops: 0000000086000005 [#1] PREEMPT SMP Modules linked in: CPU: 1 UID: 0 PID: 8037 Comm: syz.3.265 Not tainted 6.11.0-rc7-syzkaller-g5f5673607153 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0x0 lr : cipso_v4_sock_setattr+0x2a8/0x3c0 net/ipv4/cipso_ipv4.c:1910 sp : ffff80009b887a90 x29: ffff80009b887aa0 x28: ffff80008db94050 x27: 0000000000000000 x26: 1fffe0001aa6f5b3 x25: dfff800000000000 x24: ffff0000db75da00 x23: 0000000000000000 x22: ffff0000d8b78518 x21: 0000000000000000 x20: ffff0000d537ad80 x19: ffff0000d8b78000 x18: 1fffe000366d79ee x17: ffff8000800614a8 x16: ffff800080569b84 x15: 0000000000000001 x14: 000000008b336894 x13: 00000000cd96feaa x12: 0000000000000003 x11: 0000000000040000 x10: 00000000000020a3 x9 : 1fffe0001b16f0f1 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 000000000000003f x5 : 0000000000000040 x4 : 0000000000000001 x3 : 0000000000000000 x2 : 0000000000000002 x1 : 0000000000000000 x0 : ffff0000d8b78000 Call trace: 0x0 netlbl_sock_setattr+0x2e4/0x338 net/netlabel/netlabel_kapi.c:1000 smack_netlbl_add+0xa4/0x154 security/smack/smack_lsm.c:2593 smack_socket_post_create+0xa8/0x14c security/smack/smack_lsm.c:2973 security_socket_post_create+0x94/0xd4 security/security.c:4425 __sock_create+0x4c8/0x884 net/socket.c:1587 sock_create net/socket.c:1622 [inline] __sys_socket_create net/socket.c:1659 [inline] __sys_socket+0x134/0x340 net/socket.c:1706 __do_sys_socket net/socket.c:1720 [inline] __se_sys_socket net/socket.c:1718 [inline] __arm64_sys_socket+0x7c/0x94 net/socket.c:1718 __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:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 Code: ???????? ???????? ???????? ???????? (????????) ---[ end trace 0000000000000000 ]--- This patch add a toy implementation that performs a simple return to prevent such panic. This is because MSS can be set in sock_create_kern or smc_setsockopt, similar to how it's done in AF_SMC. However, for AF_SMC, there is currently no way to synchronize MSS within __sys_connect_file. This toy implementation lays the groundwork for us to support such feature for IPPROTO_SMC in the future.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50035", "url": "https://ubuntu.com/security/CVE-2024-50035", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: fix ppp_async_encode() illegal access syzbot reported an issue in ppp_async_encode() [1] In this case, pppoe_sendmsg() is called with a zero size. Then ppp_async_encode() is called with an empty skb. BUG: KMSAN: uninit-value in ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] BUG: KMSAN: uninit-value in ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_send+0x130/0x1b0 drivers/net/ppp/ppp_async.c:634 ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2280 [inline] ppp_input+0x1f1/0xe60 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 Uninit was created at: slab_post_alloc_hook mm/slub.c:4092 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4187 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 CPU: 1 UID: 0 PID: 5411 Comm: syz.1.14 Not tainted 6.12.0-rc1-syzkaller-00165-g360c1f1f24c6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50036", "url": "https://ubuntu.com/security/CVE-2024-50036", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: do not delay dst_entries_add() in dst_release() dst_entries_add() uses per-cpu data that might be freed at netns dismantle from ip6_route_net_exit() calling dst_entries_destroy() Before ip6_route_net_exit() can be called, we release all the dsts associated with this netns, via calls to dst_release(), which waits an rcu grace period before calling dst_destroy() dst_entries_add() use in dst_destroy() is racy, because dst_entries_destroy() could have been called already. Decrementing the number of dsts must happen sooner. Notes: 1) in CONFIG_XFRM case, dst_destroy() can call dst_release_immediate(child), this might also cause UAF if the child does not have DST_NOCOUNT set. IPSEC maintainers might take a look and see how to address this. 2) There is also discussion about removing this count of dst, which might happen in future kernels.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50037", "url": "https://ubuntu.com/security/CVE-2024-50037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/fbdev-dma: Only cleanup deferred I/O if necessary Commit 5a498d4d06d6 (\"drm/fbdev-dma: Only install deferred I/O if necessary\") initializes deferred I/O only if it is used. drm_fbdev_dma_fb_destroy() however calls fb_deferred_io_cleanup() unconditionally with struct fb_info.fbdefio == NULL. KASAN with the out-of-tree Apple silicon display driver posts following warning from __flush_work() of a random struct work_struct instead of the expected NULL pointer derefs. [ 22.053799] ------------[ cut here ]------------ [ 22.054832] WARNING: CPU: 2 PID: 1 at kernel/workqueue.c:4177 __flush_work+0x4d8/0x580 [ 22.056597] Modules linked in: uhid bnep uinput nls_ascii ip6_tables ip_tables i2c_dev loop fuse dm_multipath nfnetlink zram hid_magicmouse btrfs xor xor_neon brcmfmac_wcc raid6_pq hci_bcm4377 bluetooth brcmfmac hid_apple brcmutil nvmem_spmi_mfd simple_mfd_spmi dockchannel_hid cfg80211 joydev regmap_spmi nvme_apple ecdh_generic ecc macsmc_hid rfkill dwc3 appledrm snd_soc_macaudio macsmc_power nvme_core apple_isp phy_apple_atc apple_sart apple_rtkit_helper apple_dockchannel tps6598x macsmc_hwmon snd_soc_cs42l84 videobuf2_v4l2 spmi_apple_controller nvmem_apple_efuses videobuf2_dma_sg apple_z2 videobuf2_memops spi_nor panel_summit videobuf2_common asahi videodev pwm_apple apple_dcp snd_soc_apple_mca apple_admac spi_apple clk_apple_nco i2c_pasemi_platform snd_pcm_dmaengine mc i2c_pasemi_core mux_core ofpart adpdrm drm_dma_helper apple_dart apple_soc_cpufreq leds_pwm phram [ 22.073768] CPU: 2 UID: 0 PID: 1 Comm: systemd-shutdow Not tainted 6.11.2-asahi+ #asahi-dev [ 22.075612] Hardware name: Apple MacBook Pro (13-inch, M2, 2022) (DT) [ 22.077032] pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 22.078567] pc : __flush_work+0x4d8/0x580 [ 22.079471] lr : __flush_work+0x54/0x580 [ 22.080345] sp : ffffc000836ef820 [ 22.081089] x29: ffffc000836ef880 x28: 0000000000000000 x27: ffff80002ddb7128 [ 22.082678] x26: dfffc00000000000 x25: 1ffff000096f0c57 x24: ffffc00082d3e358 [ 22.084263] x23: ffff80004b7862b8 x22: dfffc00000000000 x21: ffff80005aa1d470 [ 22.085855] x20: ffff80004b786000 x19: ffff80004b7862a0 x18: 0000000000000000 [ 22.087439] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000005 [ 22.089030] x14: 1ffff800106ddf0a x13: 0000000000000000 x12: 0000000000000000 [ 22.090618] x11: ffffb800106ddf0f x10: dfffc00000000000 x9 : 1ffff800106ddf0e [ 22.092206] x8 : 0000000000000000 x7 : aaaaaaaaaaaaaaaa x6 : 0000000000000001 [ 22.093790] x5 : ffffc000836ef728 x4 : 0000000000000000 x3 : 0000000000000020 [ 22.095368] x2 : 0000000000000008 x1 : 00000000000000aa x0 : 0000000000000000 [ 22.096955] Call trace: [ 22.097505] __flush_work+0x4d8/0x580 [ 22.098330] flush_delayed_work+0x80/0xb8 [ 22.099231] fb_deferred_io_cleanup+0x3c/0x130 [ 22.100217] drm_fbdev_dma_fb_destroy+0x6c/0xe0 [drm_dma_helper] [ 22.101559] unregister_framebuffer+0x210/0x2f0 [ 22.102575] drm_fb_helper_unregister_info+0x48/0x60 [ 22.103683] drm_fbdev_dma_client_unregister+0x4c/0x80 [drm_dma_helper] [ 22.105147] drm_client_dev_unregister+0x1cc/0x230 [ 22.106217] drm_dev_unregister+0x58/0x570 [ 22.107125] apple_drm_unbind+0x50/0x98 [appledrm] [ 22.108199] component_del+0x1f8/0x3a8 [ 22.109042] dcp_platform_shutdown+0x24/0x38 [apple_dcp] [ 22.110357] platform_shutdown+0x70/0x90 [ 22.111219] device_shutdown+0x368/0x4d8 [ 22.112095] kernel_restart+0x6c/0x1d0 [ 22.112946] __arm64_sys_reboot+0x1c8/0x328 [ 22.113868] invoke_syscall+0x78/0x1a8 [ 22.114703] do_el0_svc+0x124/0x1a0 [ 22.115498] el0_svc+0x3c/0xe0 [ 22.116181] el0t_64_sync_handler+0x70/0xc0 [ 22.117110] el0t_64_sync+0x190/0x198 [ 22.117931] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50092", "url": "https://ubuntu.com/security/CVE-2024-50092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netconsole: fix wrong warning A warning is triggered when there is insufficient space in the buffer for userdata. However, this is not an issue since userdata will be sent in the next iteration. Current warning message: ------------[ cut here ]------------ WARNING: CPU: 13 PID: 3013042 at drivers/net/netconsole.c:1122 write_ext_msg+0x3b6/0x3d0 ? write_ext_msg+0x3b6/0x3d0 console_flush_all+0x1e9/0x330 The code incorrectly issues a warning when this_chunk is zero, which is a valid scenario. The warning should only be triggered when this_chunk is negative.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50038", "url": "https://ubuntu.com/security/CVE-2024-50038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xtables: avoid NFPROTO_UNSPEC where needed syzbot managed to call xt_cluster match via ebtables: WARNING: CPU: 0 PID: 11 at net/netfilter/xt_cluster.c:72 xt_cluster_mt+0x196/0x780 [..] ebt_do_table+0x174b/0x2a40 Module registers to NFPROTO_UNSPEC, but it assumes ipv4/ipv6 packet processing. As this is only useful to restrict locally terminating TCP/UDP traffic, register this for ipv4 and ipv6 family only. Pablo points out that this is a general issue, direct users of the set/getsockopt interface can call into targets/matches that were only intended for use with ip(6)tables. Check all UNSPEC matches and targets for similar issues: - matches and targets are fine except if they assume skb_network_header() is valid -- this is only true when called from inet layer: ip(6) stack pulls the ip/ipv6 header into linear data area. - targets that return XT_CONTINUE or other xtables verdicts must be restricted too, they are incompatbile with the ebtables traverser, e.g. EBT_CONTINUE is a completely different value than XT_CONTINUE. Most matches/targets are changed to register for NFPROTO_IPV4/IPV6, as they are provided for use by ip(6)tables. The MARK target is also used by arptables, so register for NFPROTO_ARP too. While at it, bail out if connbytes fails to enable the corresponding conntrack family. This change passes the selftests in iptables.git.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50039", "url": "https://ubuntu.com/security/CVE-2024-50039", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: accept TCA_STAB only for root qdisc Most qdiscs maintain their backlog using qdisc_pkt_len(skb) on the assumption it is invariant between the enqueue() and dequeue() handlers. Unfortunately syzbot can crash a host rather easily using a TBF + SFQ combination, with an STAB on SFQ [1] We can't support TCA_STAB on arbitrary level, this would require to maintain per-qdisc storage. [1] [ 88.796496] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 88.798611] #PF: supervisor read access in kernel mode [ 88.799014] #PF: error_code(0x0000) - not-present page [ 88.799506] PGD 0 P4D 0 [ 88.799829] Oops: Oops: 0000 [#1] SMP NOPTI [ 88.800569] CPU: 14 UID: 0 PID: 2053 Comm: b371744477 Not tainted 6.12.0-rc1-virtme #1117 [ 88.801107] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 88.801779] RIP: 0010:sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq [ 88.802544] Code: 0f b7 50 12 48 8d 04 d5 00 00 00 00 48 89 d6 48 29 d0 48 8b 91 c0 01 00 00 48 c1 e0 03 48 01 c2 66 83 7a 1a 00 7e c0 48 8b 3a <4c> 8b 07 4c 89 02 49 89 50 08 48 c7 47 08 00 00 00 00 48 c7 07 00 All code ======== 0:\t0f b7 50 12 \tmovzwl 0x12(%rax),%edx 4:\t48 8d 04 d5 00 00 00 \tlea 0x0(,%rdx,8),%rax b:\t00 c:\t48 89 d6 \tmov %rdx,%rsi f:\t48 29 d0 \tsub %rdx,%rax 12:\t48 8b 91 c0 01 00 00 \tmov 0x1c0(%rcx),%rdx 19:\t48 c1 e0 03 \tshl $0x3,%rax 1d:\t48 01 c2 \tadd %rax,%rdx 20:\t66 83 7a 1a 00 \tcmpw $0x0,0x1a(%rdx) 25:\t7e c0 \tjle 0xffffffffffffffe7 27:\t48 8b 3a \tmov (%rdx),%rdi 2a:*\t4c 8b 07 \tmov (%rdi),%r8\t\t<-- trapping instruction 2d:\t4c 89 02 \tmov %r8,(%rdx) 30:\t49 89 50 08 \tmov %rdx,0x8(%r8) 34:\t48 c7 47 08 00 00 00 \tmovq $0x0,0x8(%rdi) 3b:\t00 3c:\t48 \trex.W 3d:\tc7 \t.byte 0xc7 3e:\t07 \t(bad) \t... Code starting with the faulting instruction =========================================== 0:\t4c 8b 07 \tmov (%rdi),%r8 3:\t4c 89 02 \tmov %r8,(%rdx) 6:\t49 89 50 08 \tmov %rdx,0x8(%r8) a:\t48 c7 47 08 00 00 00 \tmovq $0x0,0x8(%rdi) 11:\t00 12:\t48 \trex.W 13:\tc7 \t.byte 0xc7 14:\t07 \t(bad) \t... [ 88.803721] RSP: 0018:ffff9a1f892b7d58 EFLAGS: 00000206 [ 88.804032] RAX: 0000000000000000 RBX: ffff9a1f8420c800 RCX: ffff9a1f8420c800 [ 88.804560] RDX: ffff9a1f81bc1440 RSI: 0000000000000000 RDI: 0000000000000000 [ 88.805056] RBP: ffffffffc04bb0e0 R08: 0000000000000001 R09: 00000000ff7f9a1f [ 88.805473] R10: 000000000001001b R11: 0000000000009a1f R12: 0000000000000140 [ 88.806194] R13: 0000000000000001 R14: ffff9a1f886df400 R15: ffff9a1f886df4ac [ 88.806734] FS: 00007f445601a740(0000) GS:ffff9a2e7fd80000(0000) knlGS:0000000000000000 [ 88.807225] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 88.807672] CR2: 0000000000000000 CR3: 000000050cc46000 CR4: 00000000000006f0 [ 88.808165] Call Trace: [ 88.808459] [ 88.808710] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434) [ 88.809261] ? page_fault_oops (arch/x86/mm/fault.c:715) [ 88.809561] ? exc_page_fault (./arch/x86/include/asm/irqflags.h:26 ./arch/x86/include/asm/irqflags.h:87 ./arch/x86/include/asm/irqflags.h:147 arch/x86/mm/fault.c:1489 arch/x86/mm/fault.c:1539) [ 88.809806] ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623) [ 88.810074] ? sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq [ 88.810411] sfq_reset (net/sched/sch_sfq.c:525) sch_sfq [ 88.810671] qdisc_reset (./include/linux/skbuff.h:2135 ./include/linux/skbuff.h:2441 ./include/linux/skbuff.h:3304 ./include/linux/skbuff.h:3310 net/sched/sch_g ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50040", "url": "https://ubuntu.com/security/CVE-2024-50040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: igb: Do not bring the device up after non-fatal error Commit 004d25060c78 (\"igb: Fix igb_down hung on surprise removal\") changed igb_io_error_detected() to ignore non-fatal pcie errors in order to avoid hung task that can happen when igb_down() is called multiple times. This caused an issue when processing transient non-fatal errors. igb_io_resume(), which is called after igb_io_error_detected(), assumes that device is brought down by igb_io_error_detected() if the interface is up. This resulted in panic with stacktrace below. [ T3256] igb 0000:09:00.0 haeth0: igb: haeth0 NIC Link is Down [ T292] pcieport 0000:00:1c.5: AER: Uncorrected (Non-Fatal) error received: 0000:09:00.0 [ T292] igb 0000:09:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, (Requester ID) [ T292] igb 0000:09:00.0: device [8086:1537] error status/mask=00004000/00000000 [ T292] igb 0000:09:00.0: [14] CmpltTO [ 200.105524,009][ T292] igb 0000:09:00.0: AER: TLP Header: 00000000 00000000 00000000 00000000 [ T292] pcieport 0000:00:1c.5: AER: broadcast error_detected message [ T292] igb 0000:09:00.0: Non-correctable non-fatal error reported. [ T292] pcieport 0000:00:1c.5: AER: broadcast mmio_enabled message [ T292] pcieport 0000:00:1c.5: AER: broadcast resume message [ T292] ------------[ cut here ]------------ [ T292] kernel BUG at net/core/dev.c:6539! [ T292] invalid opcode: 0000 [#1] PREEMPT SMP [ T292] RIP: 0010:napi_enable+0x37/0x40 [ T292] Call Trace: [ T292] [ T292] ? die+0x33/0x90 [ T292] ? do_trap+0xdc/0x110 [ T292] ? napi_enable+0x37/0x40 [ T292] ? do_error_trap+0x70/0xb0 [ T292] ? napi_enable+0x37/0x40 [ T292] ? napi_enable+0x37/0x40 [ T292] ? exc_invalid_op+0x4e/0x70 [ T292] ? napi_enable+0x37/0x40 [ T292] ? asm_exc_invalid_op+0x16/0x20 [ T292] ? napi_enable+0x37/0x40 [ T292] igb_up+0x41/0x150 [ T292] igb_io_resume+0x25/0x70 [ T292] report_resume+0x54/0x70 [ T292] ? report_frozen_detected+0x20/0x20 [ T292] pci_walk_bus+0x6c/0x90 [ T292] ? aer_print_port_info+0xa0/0xa0 [ T292] pcie_do_recovery+0x22f/0x380 [ T292] aer_process_err_devices+0x110/0x160 [ T292] aer_isr+0x1c1/0x1e0 [ T292] ? disable_irq_nosync+0x10/0x10 [ T292] irq_thread_fn+0x1a/0x60 [ T292] irq_thread+0xe3/0x1a0 [ T292] ? irq_set_affinity_notifier+0x120/0x120 [ T292] ? irq_affinity_notify+0x100/0x100 [ T292] kthread+0xe2/0x110 [ T292] ? kthread_complete_and_exit+0x20/0x20 [ T292] ret_from_fork+0x2d/0x50 [ T292] ? kthread_complete_and_exit+0x20/0x20 [ T292] ret_from_fork_asm+0x11/0x20 [ T292] To fix this issue igb_io_resume() checks if the interface is running and the device is not down this means igb_io_error_detected() did not bring the device down and there is no need to bring it up.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50041", "url": "https://ubuntu.com/security/CVE-2024-50041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: Fix macvlan leak by synchronizing access to mac_filter_hash This patch addresses a macvlan leak issue in the i40e driver caused by concurrent access to vsi->mac_filter_hash. The leak occurs when multiple threads attempt to modify the mac_filter_hash simultaneously, leading to inconsistent state and potential memory leaks. To fix this, we now wrap the calls to i40e_del_mac_filter() and zeroing vf->default_lan_addr.addr with spin_lock/unlock_bh(&vsi->mac_filter_hash_lock), ensuring atomic operations and preventing concurrent access. Additionally, we add lockdep_assert_held(&vsi->mac_filter_hash_lock) in i40e_add_mac_filter() to help catch similar issues in the future. Reproduction steps: 1. Spawn VFs and configure port vlan on them. 2. Trigger concurrent macvlan operations (e.g., adding and deleting \tportvlan and/or mac filters). 3. Observe the potential memory leak and inconsistent state in the \tmac_filter_hash. This synchronization ensures the integrity of the mac_filter_hash and prevents the described leak.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50042", "url": "https://ubuntu.com/security/CVE-2024-50042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix increasing MSI-X on VF Increasing MSI-X value on a VF leads to invalid memory operations. This is caused by not reallocating some arrays. Reproducer: modprobe ice echo 0 > /sys/bus/pci/devices/$PF_PCI/sriov_drivers_autoprobe echo 1 > /sys/bus/pci/devices/$PF_PCI/sriov_numvfs echo 17 > /sys/bus/pci/devices/$VF0_PCI/sriov_vf_msix_count Default MSI-X is 16, so 17 and above triggers this issue. KASAN reports: BUG: KASAN: slab-out-of-bounds in ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] Read of size 8 at addr ffff8888b937d180 by task bash/28433 (...) Call Trace: (...) ? ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] kasan_report+0xed/0x120 ? ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] ice_vsi_cfg_def+0x3360/0x4770 [ice] ? mutex_unlock+0x83/0xd0 ? __pfx_ice_vsi_cfg_def+0x10/0x10 [ice] ? __pfx_ice_remove_vsi_lkup_fltr+0x10/0x10 [ice] ice_vsi_cfg+0x7f/0x3b0 [ice] ice_vf_reconfig_vsi+0x114/0x210 [ice] ice_sriov_set_msix_vec_count+0x3d0/0x960 [ice] sriov_vf_msix_count_store+0x21c/0x300 (...) Allocated by task 28201: (...) ice_vsi_cfg_def+0x1c8e/0x4770 [ice] ice_vsi_cfg+0x7f/0x3b0 [ice] ice_vsi_setup+0x179/0xa30 [ice] ice_sriov_configure+0xcaa/0x1520 [ice] sriov_numvfs_store+0x212/0x390 (...) To fix it, use ice_vsi_rebuild() instead of ice_vf_reconfig_vsi(). This causes the required arrays to be reallocated taking the new queue count into account (ice_vsi_realloc_stat_arrays()). Set req_txq and req_rxq before ice_vsi_rebuild(), so that realloc uses the newly set queue count. Additionally, ice_vsi_rebuild() does not remove VSI filters (ice_fltr_remove_all()), so ice_vf_init_host_cfg() is no longer necessary.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50093", "url": "https://ubuntu.com/security/CVE-2024-50093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: intel: int340x: processor: Fix warning during module unload The processor_thermal driver uses pcim_device_enable() to enable a PCI device, which means the device will be automatically disabled on driver detach. Thus there is no need to call pci_disable_device() again on it. With recent PCI device resource management improvements, e.g. commit f748a07a0b64 (\"PCI: Remove legacy pcim_release()\"), this problem is exposed and triggers the warining below. [ 224.010735] proc_thermal_pci 0000:00:04.0: disabling already-disabled device [ 224.010747] WARNING: CPU: 8 PID: 4442 at drivers/pci/pci.c:2250 pci_disable_device+0xe5/0x100 ... [ 224.010844] Call Trace: [ 224.010845] [ 224.010847] ? show_regs+0x6d/0x80 [ 224.010851] ? __warn+0x8c/0x140 [ 224.010854] ? pci_disable_device+0xe5/0x100 [ 224.010856] ? report_bug+0x1c9/0x1e0 [ 224.010859] ? handle_bug+0x46/0x80 [ 224.010862] ? exc_invalid_op+0x1d/0x80 [ 224.010863] ? asm_exc_invalid_op+0x1f/0x30 [ 224.010867] ? pci_disable_device+0xe5/0x100 [ 224.010869] ? pci_disable_device+0xe5/0x100 [ 224.010871] ? kfree+0x21a/0x2b0 [ 224.010873] pcim_disable_device+0x20/0x30 [ 224.010875] devm_action_release+0x16/0x20 [ 224.010878] release_nodes+0x47/0xc0 [ 224.010880] devres_release_all+0x9f/0xe0 [ 224.010883] device_unbind_cleanup+0x12/0x80 [ 224.010885] device_release_driver_internal+0x1ca/0x210 [ 224.010887] driver_detach+0x4e/0xa0 [ 224.010889] bus_remove_driver+0x6f/0xf0 [ 224.010890] driver_unregister+0x35/0x60 [ 224.010892] pci_unregister_driver+0x44/0x90 [ 224.010894] proc_thermal_pci_driver_exit+0x14/0x5f0 [processor_thermal_device_pci] ... [ 224.010921] ---[ end trace 0000000000000000 ]--- Remove the excess pci_disable_device() calls. [ rjw: Subject and changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50043", "url": "https://ubuntu.com/security/CVE-2024-50043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix possible badness in FREE_STATEID When multiple FREE_STATEIDs are sent for the same delegation stateid, it can lead to a possible either use-after-free or counter refcount underflow errors. In nfsd4_free_stateid() under the client lock we find a delegation stateid, however the code drops the lock before calling nfs4_put_stid(), that allows another FREE_STATE to find the stateid again. The first one will proceed to then free the stateid which leads to either use-after-free or decrementing already zeroed counter.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50044", "url": "https://ubuntu.com/security/CVE-2024-50044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change rfcomm_sk_state_change attempts to use sock_lock so it must never be called with it locked but rfcomm_sock_ioctl always attempt to lock it causing the following trace: ====================================================== WARNING: possible circular locking dependency detected 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Not tainted ------------------------------------------------------ syz-executor386/5093 is trying to acquire lock: ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1671 [inline] ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73 but task is already holding lock: ffff88807badfd28 (&d->lock){+.+.}-{3:3}, at: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50045", "url": "https://ubuntu.com/security/CVE-2024-50045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: br_netfilter: fix panic with metadata_dst skb Fix a kernel panic in the br_netfilter module when sending untagged traffic via a VxLAN device. This happens during the check for fragmentation in br_nf_dev_queue_xmit. It is dependent on: 1) the br_netfilter module being loaded; 2) net.bridge.bridge-nf-call-iptables set to 1; 3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port; 4) untagged frames with size higher than the VxLAN MTU forwarded/flooded When forwarding the untagged packet to the VxLAN bridge port, before the netfilter hooks are called, br_handle_egress_vlan_tunnel is called and changes the skb_dst to the tunnel dst. The tunnel_dst is a metadata type of dst, i.e., skb_valid_dst(skb) is false, and metadata->dst.dev is NULL. Then in the br_netfilter hooks, in br_nf_dev_queue_xmit, there's a check for frames that needs to be fragmented: frames with higher MTU than the VxLAN device end up calling br_nf_ip_fragment, which in turns call ip_skb_dst_mtu. The ip_dst_mtu tries to use the skb_dst(skb) as if it was a valid dst with valid dst->dev, thus the crash. This case was never supported in the first place, so drop the packet instead. PING 10.0.0.2 (10.0.0.2) from 0.0.0.0 h1-eth0: 2000(2028) bytes of data. [ 176.291791] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000110 [ 176.292101] Mem abort info: [ 176.292184] ESR = 0x0000000096000004 [ 176.292322] EC = 0x25: DABT (current EL), IL = 32 bits [ 176.292530] SET = 0, FnV = 0 [ 176.292709] EA = 0, S1PTW = 0 [ 176.292862] FSC = 0x04: level 0 translation fault [ 176.293013] Data abort info: [ 176.293104] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 176.293488] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 176.293787] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 176.293995] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043ef5000 [ 176.294166] [0000000000000110] pgd=0000000000000000, p4d=0000000000000000 [ 176.294827] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 176.295252] Modules linked in: vxlan ip6_udp_tunnel udp_tunnel veth br_netfilter bridge stp llc ipv6 crct10dif_ce [ 176.295923] CPU: 0 PID: 188 Comm: ping Not tainted 6.8.0-rc3-g5b3fbd61b9d1 #2 [ 176.296314] Hardware name: linux,dummy-virt (DT) [ 176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 176.296808] pc : br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.297382] lr : br_nf_dev_queue_xmit+0x2ac/0x4ec [br_netfilter] [ 176.297636] sp : ffff800080003630 [ 176.297743] x29: ffff800080003630 x28: 0000000000000008 x27: ffff6828c49ad9f8 [ 176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24: 00000000000003e8 [ 176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21: ffff6828c3b16d28 [ 176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18: 0000000000000014 [ 176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15: 0000000095744632 [ 176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12: ffffb7e137926a70 [ 176.299574] x11: 0000000000000001 x10: ffff6828c3f1c898 x9 : 0000000000000000 [ 176.300049] x8 : ffff6828c49bf070 x7 : 0008460f18d5f20e x6 : f20e0100bebafeca [ 176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 : 0000000000000000 [ 176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 : ffff6828c7f918f0 [ 176.300889] Call trace: [ 176.301123] br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.301411] br_nf_post_routing+0x2a8/0x3e4 [br_netfilter] [ 176.301703] nf_hook_slow+0x48/0x124 [ 176.302060] br_forward_finish+0xc8/0xe8 [bridge] [ 176.302371] br_nf_hook_thresh+0x124/0x134 [br_netfilter] [ 176.302605] br_nf_forward_finish+0x118/0x22c [br_netfilter] [ 176.302824] br_nf_forward_ip.part.0+0x264/0x290 [br_netfilter] [ 176.303136] br_nf_forward+0x2b8/0x4e0 [br_netfilter] [ 176.303359] nf_hook_slow+0x48/0x124 [ 176.303 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50094", "url": "https://ubuntu.com/security/CVE-2024-50094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sfc: Don't invoke xdp_do_flush() from netpoll. Yury reported a crash in the sfc driver originated from netpoll_send_udp(). The netconsole sends a message and then netpoll invokes the driver's NAPI function with a budget of zero. It is dedicated to allow driver to free TX resources, that it may have used while sending the packet. In the netpoll case the driver invokes xdp_do_flush() unconditionally, leading to crash because bpf_net_context was never assigned. Invoke xdp_do_flush() only if budget is not zero.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50188", "url": "https://ubuntu.com/security/CVE-2024-50188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: dp83869: fix memory corruption when enabling fiber When configuring the fiber port, the DP83869 PHY driver incorrectly calls linkmode_set_bit() with a bit mask (1 << 10) rather than a bit number (10). This corrupts some other memory location -- in case of arm64 the priv pointer in the same structure. Since the advertising flags are updated from supported at the end of the function the incorrect line isn't needed at all and can be removed.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50046", "url": "https://ubuntu.com/security/CVE-2024-50046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies() On the node of an NFS client, some files saved in the mountpoint of the NFS server were copied to another location of the same NFS server. Accidentally, the nfs42_complete_copies() got a NULL-pointer dereference crash with the following syslog: [232064.838881] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232064.839360] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232066.588183] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 [232066.588586] Mem abort info: [232066.588701] ESR = 0x0000000096000007 [232066.588862] EC = 0x25: DABT (current EL), IL = 32 bits [232066.589084] SET = 0, FnV = 0 [232066.589216] EA = 0, S1PTW = 0 [232066.589340] FSC = 0x07: level 3 translation fault [232066.589559] Data abort info: [232066.589683] ISV = 0, ISS = 0x00000007 [232066.589842] CM = 0, WnR = 0 [232066.589967] user pgtable: 64k pages, 48-bit VAs, pgdp=00002000956ff400 [232066.590231] [0000000000000058] pgd=08001100ae100003, p4d=08001100ae100003, pud=08001100ae100003, pmd=08001100b3c00003, pte=0000000000000000 [232066.590757] Internal error: Oops: 96000007 [#1] SMP [232066.590958] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm vhost_net vhost vhost_iotlb tap tun ipt_rpfilter xt_multiport ip_set_hash_ip ip_set_hash_net xfrm_interface xfrm6_tunnel tunnel4 tunnel6 esp4 ah4 wireguard libcurve25519_generic veth xt_addrtype xt_set nf_conntrack_netlink ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_bitmap_port ip_set_hash_ipport dummy ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs iptable_filter sch_ingress nfnetlink_cttimeout vport_gre ip_gre ip_tunnel gre vport_geneve geneve vport_vxlan vxlan ip6_udp_tunnel udp_tunnel openvswitch nf_conncount dm_round_robin dm_service_time dm_multipath xt_nat xt_MASQUERADE nft_chain_nat nf_nat xt_mark xt_conntrack xt_comment nft_compat nft_counter nf_tables nfnetlink ocfs2 ocfs2_nodemanager ocfs2_stackglue iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_ssif nbd overlay 8021q garp mrp bonding tls rfkill sunrpc ext4 mbcache jbd2 [232066.591052] vfat fat cas_cache cas_disk ses enclosure scsi_transport_sas sg acpi_ipmi ipmi_si ipmi_devintf ipmi_msghandler ip_tables vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio dm_mirror dm_region_hash dm_log dm_mod nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc fuse xfs libcrc32c ast drm_vram_helper qla2xxx drm_kms_helper syscopyarea crct10dif_ce sysfillrect ghash_ce sysimgblt sha2_ce fb_sys_fops cec sha256_arm64 sha1_ce drm_ttm_helper ttm nvme_fc igb sbsa_gwdt nvme_fabrics drm nvme_core i2c_algo_bit i40e scsi_transport_fc megaraid_sas aes_neon_bs [232066.596953] CPU: 6 PID: 4124696 Comm: 10.253.166.125- Kdump: loaded Not tainted 5.15.131-9.cl9_ocfs2.aarch64 #1 [232066.597356] Hardware name: Great Wall .\\x93\\x8e...RF6260 V5/GWMSSE2GL1T, BIOS T656FBE_V3.0.18 2024-01-06 [232066.597721] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [232066.598034] pc : nfs4_reclaim_open_state+0x220/0x800 [nfsv4] [232066.598327] lr : nfs4_reclaim_open_state+0x12c/0x800 [nfsv4] [232066.598595] sp : ffff8000f568fc70 [232066.598731] x29: ffff8000f568fc70 x28: 0000000000001000 x27: ffff21003db33000 [232066.599030] x26: ffff800005521ae0 x25: ffff0100f98fa3f0 x24: 0000000000000001 [232066.599319] x23: ffff800009920008 x22: ffff21003db33040 x21: ffff21003db33050 [232066.599628] x20: ffff410172fe9e40 x19: ffff410172fe9e00 x18: 0000000000000000 [232066.599914] x17: 0000000000000000 x16: 0000000000000004 x15: 0000000000000000 [232066.600195] x14: 0000000000000000 x13: ffff800008e685a8 x12: 00000000eac0c6e6 [232066.600498] x11: 00000000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50190", "url": "https://ubuntu.com/security/CVE-2024-50190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix memleak in ice_init_tx_topology() Fix leak of the FW blob (DDP pkg). Make ice_cfg_tx_topo() const-correct, so ice_init_tx_topology() can avoid copying whole FW blob. Copy just the topology section, and only when needed. Reuse the buffer allocated for the read of the current topology. This was found by kmemleak, with the following trace for each PF: [] kmemdup_noprof+0x1d/0x50 [] ice_init_ddp_config+0x100/0x220 [ice] [] ice_init_dev+0x6f/0x200 [ice] [] ice_init+0x29/0x560 [ice] [] ice_probe+0x21d/0x310 [ice] Constify ice_cfg_tx_topo() @buf parameter. This cascades further down to few more functions.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50180", "url": "https://ubuntu.com/security/CVE-2024-50180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: sisfb: Fix strbuf array overflow The values of the variables xres and yres are placed in strbuf. These variables are obtained from strbuf1. The strbuf1 array contains digit characters and a space if the array contains non-digit characters. Then, when executing sprintf(strbuf, \"%ux%ux8\", xres, yres); more than 16 bytes will be written to strbuf. It is suggested to increase the size of the strbuf array to 24. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06: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": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50048", "url": "https://ubuntu.com/security/CVE-2024-50048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: Fix a NULL pointer dereference issue in fbcon_putcs syzbot has found a NULL pointer dereference bug in fbcon. Here is the simplified C reproducer: struct param { \tuint8_t type; \tstruct tiocl_selection ts; }; int main() { \tstruct fb_con2fbmap con2fb; \tstruct param param; \tint fd = open(\"/dev/fb1\", 0, 0); \tcon2fb.console = 0x19; \tcon2fb.framebuffer = 0; \tioctl(fd, FBIOPUT_CON2FBMAP, &con2fb); \tparam.type = 2; \tparam.ts.xs = 0; param.ts.ys = 0; \tparam.ts.xe = 0; param.ts.ye = 0; \tparam.ts.sel_mode = 0; \tint fd1 = open(\"/dev/tty1\", O_RDWR, 0); \tioctl(fd1, TIOCLINUX, ¶m); \tcon2fb.console = 1; \tcon2fb.framebuffer = 0; \tioctl(fd, FBIOPUT_CON2FBMAP, &con2fb); \treturn 0; } After calling ioctl(fd1, TIOCLINUX, ¶m), the subsequent ioctl(fd, FBIOPUT_CON2FBMAP, &con2fb) causes the kernel to follow a different execution path: set_con2fb_map -> con2fb_init_display -> fbcon_set_disp -> redraw_screen -> hide_cursor -> clear_selection -> highlight -> invert_screen -> do_update_region -> fbcon_putcs -> ops->putcs Since ops->putcs is a NULL pointer, this leads to a kernel panic. To prevent this, we need to call set_blitting_type() within set_con2fb_map() to properly initialize ops->putcs.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50049", "url": "https://ubuntu.com/security/CVE-2024-50049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before dereferencing se [WHAT & HOW] se is null checked previously in the same function, indicating it might be null; therefore, it must be checked when used again. This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50090", "url": "https://ubuntu.com/security/CVE-2024-50090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/oa: Fix overflow in oa batch buffer By default xe_bb_create_job() appends a MI_BATCH_BUFFER_END to batch buffer, this is not a problem if batch buffer is only used once but oa reuses the batch buffer for the same metric and at each call it appends a MI_BATCH_BUFFER_END, printing the warning below and then overflowing. [ 381.072016] ------------[ cut here ]------------ [ 381.072019] xe 0000:00:02.0: [drm] Assertion `bb->len * 4 + bb_prefetch(q->gt) <= size` failed! platform: LUNARLAKE subplatform: 1 graphics: Xe2_LPG / Xe2_HPG 20.04 step B0 media: Xe2_LPM / Xe2_HPM 20.00 step B0 tile: 0 VRAM 0 B GT: 0 type 1 So here checking if batch buffer already have MI_BATCH_BUFFER_END if not append it. v2: - simply fix, suggestion from Ashutosh (cherry picked from commit 9ba0e0f30ca42a98af3689460063edfb6315718a)", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50183", "url": "https://ubuntu.com/security/CVE-2024-50183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV instance Deleting an NPIV instance requires all fabric ndlps to be released before an NPIV's resources can be torn down. Failure to release fabric ndlps beforehand opens kref imbalance race conditions. Fix by forcing the DA_ID to complete synchronously with usage of wait_queue.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50055", "url": "https://ubuntu.com/security/CVE-2024-50055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: driver core: bus: Fix double free in driver API bus_register() For bus_register(), any error which happens after kset_register() will cause that @priv are freed twice, fixed by setting @priv with NULL after the first free.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50091", "url": "https://ubuntu.com/security/CVE-2024-50091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm vdo: don't refer to dedupe_context after releasing it Clear the dedupe_context pointer in a data_vio whenever ownership of the context is lost, so that vdo can't examine it accidentally.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50056", "url": "https://ubuntu.com/security/CVE-2024-50056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: Fix ERR_PTR dereference in uvc_v4l2.c Fix potential dereferencing of ERR_PTR() in find_format_by_pix() and uvc_v4l2_enum_format(). Fix the following smatch errors: drivers/usb/gadget/function/uvc_v4l2.c:124 find_format_by_pix() error: 'fmtdesc' dereferencing possible ERR_PTR() drivers/usb/gadget/function/uvc_v4l2.c:392 uvc_v4l2_enum_format() error: 'fmtdesc' dereferencing possible ERR_PTR() Also, fix similar issue in uvc_v4l2_try_format() for potential dereferencing of ERR_PTR().", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50184", "url": "https://ubuntu.com/security/CVE-2024-50184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_pmem: Check device status before requesting flush If a pmem device is in a bad status, the driver side could wait for host ack forever in virtio_pmem_flush(), causing the system to hang. So add a status check in the beginning of virtio_pmem_flush() to return early if the device is not activated.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50057", "url": "https://ubuntu.com/security/CVE-2024-50057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: tipd: Free IRQ only if it was requested before In polling mode, if no IRQ was requested there is no need to free it. Call devm_free_irq() only if client->irq is set. This fixes the warning caused by the tps6598x module removal: WARNING: CPU: 2 PID: 333 at kernel/irq/devres.c:144 devm_free_irq+0x80/0x8c ... ... Call trace: devm_free_irq+0x80/0x8c tps6598x_remove+0x28/0x88 [tps6598x] i2c_device_remove+0x2c/0x9c device_remove+0x4c/0x80 device_release_driver_internal+0x1cc/0x228 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 i2c_del_driver+0x54/0x64 tps6598x_i2c_driver_exit+0x18/0xc3c [tps6598x] __arm64_sys_delete_module+0x184/0x264 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc8/0xe8 do_el0_svc+0x20/0x2c el0_svc+0x28/0x98 el0t_64_sync_handler+0x13c/0x158 el0t_64_sync+0x190/0x194", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50058", "url": "https://ubuntu.com/security/CVE-2024-50058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: protect uart_port_dtr_rts() in uart_shutdown() too Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part 3) added few uport == NULL checks. It added one to uart_shutdown(), so the commit assumes, uport can be NULL in there. But right after that protection, there is an unprotected \"uart_port_dtr_rts(uport, false);\" call. That is invoked only if HUPCL is set, so I assume that is the reason why we do not see lots of these reports. Or it cannot be NULL at this point at all for some reason :P. Until the above is investigated, stay on the safe side and move this dereference to the if too. I got this inconsistency from Coverity under CID 1585130. Thanks.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50181", "url": "https://ubuntu.com/security/CVE-2024-50181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: imx: Remove CLK_SET_PARENT_GATE for DRAM mux for i.MX7D For i.MX7D DRAM related mux clock, the clock source change should ONLY be done done in low level asm code without accessing DRAM, and then calling clk API to sync the HW clock status with clk tree, it should never touch real clock source switch via clk API, so CLK_SET_PARENT_GATE flag should NOT be added, otherwise, DRAM's clock parent will be disabled when DRAM is active, and system will hang.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50059", "url": "https://ubuntu.com/security/CVE-2024-50059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntb: ntb_hw_switchtec: Fix use after free vulnerability in switchtec_ntb_remove due to race condition In the switchtec_ntb_add function, it can call switchtec_ntb_init_sndev function, then &sndev->check_link_status_work is bound with check_link_status_work. switchtec_ntb_link_notification may be called to start the work. If we remove the module which will call switchtec_ntb_remove to make cleanup, it will free sndev through kfree(sndev), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | check_link_status_work switchtec_ntb_remove | kfree(sndev); | | if (sndev->link_force_down) | // use sndev Fix it by ensuring that the work is canceled before proceeding with the cleanup in switchtec_ntb_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50060", "url": "https://ubuntu.com/security/CVE-2024-50060", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring: check if we need to reschedule during overflow flush In terms of normal application usage, this list will always be empty. And if an application does overflow a bit, it'll have a few entries. However, nothing obviously prevents syzbot from running a test case that generates a ton of overflow entries, and then flushing them can take quite a while. Check for needing to reschedule while flushing, and drop our locks and do so if necessary. There's no state to maintain here as overflows always prune from head-of-list, hence it's fine to drop and reacquire the locks at the end of the loop.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50061", "url": "https://ubuntu.com/security/CVE-2024-50061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: cdns: Fix use after free vulnerability in cdns_i3c_master Driver Due to Race Condition In the cdns_i3c_master_probe function, &master->hj_work is bound with cdns_i3c_master_hj. And cdns_i3c_master_interrupt can call cnds_i3c_master_demux_ibis function to start the work. If we remove the module which will call cdns_i3c_master_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | cdns_i3c_master_hj cdns_i3c_master_remove | i3c_master_unregister(&master->base) | device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in cdns_i3c_master_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50062", "url": "https://ubuntu.com/security/CVE-2024-50062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-srv: Avoid null pointer deref during path establishment For RTRS path establishment, RTRS client initiates and completes con_num of connections. After establishing all its connections, the information is exchanged between the client and server through the info_req message. During this exchange, it is essential that all connections have been established, and the state of the RTRS srv path is CONNECTED. So add these sanity checks, to make sure we detect and abort process in error scenarios to avoid null pointer deref.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50095", "url": "https://ubuntu.com/security/CVE-2024-50095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mad: Improve handling of timed out WRs of mad agent Current timeout handler of mad agent acquires/releases mad_agent_priv lock for every timed out WRs. This causes heavy locking contention when higher no. of WRs are to be handled inside timeout handler. This leads to softlockup with below trace in some use cases where rdma-cm path is used to establish connection between peer nodes Trace: ----- BUG: soft lockup - CPU#4 stuck for 26s! [kworker/u128:3:19767] CPU: 4 PID: 19767 Comm: kworker/u128:3 Kdump: loaded Tainted: G OE ------- --- 5.14.0-427.13.1.el9_4.x86_64 #1 Hardware name: Dell Inc. PowerEdge R740/01YM03, BIOS 2.4.8 11/26/2019 Workqueue: ib_mad1 timeout_sends [ib_core] RIP: 0010:__do_softirq+0x78/0x2ac RSP: 0018:ffffb253449e4f98 EFLAGS: 00000246 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 000000000000001f RDX: 000000000000001d RSI: 000000003d1879ab RDI: fff363b66fd3a86b RBP: ffffb253604cbcd8 R08: 0000009065635f3b R09: 0000000000000000 R10: 0000000000000040 R11: ffffb253449e4ff8 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000040 FS: 0000000000000000(0000) GS:ffff8caa1fc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd9ec9db900 CR3: 0000000891934006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? __irq_exit_rcu+0xa1/0xc0 ? watchdog_timer_fn+0x1b2/0x210 ? __pfx_watchdog_timer_fn+0x10/0x10 ? __hrtimer_run_queues+0x127/0x2c0 ? hrtimer_interrupt+0xfc/0x210 ? __sysvec_apic_timer_interrupt+0x5c/0x110 ? sysvec_apic_timer_interrupt+0x37/0x90 ? asm_sysvec_apic_timer_interrupt+0x16/0x20 ? __do_softirq+0x78/0x2ac ? __do_softirq+0x60/0x2ac __irq_exit_rcu+0xa1/0xc0 sysvec_call_function_single+0x72/0x90 asm_sysvec_call_function_single+0x16/0x20 RIP: 0010:_raw_spin_unlock_irq+0x14/0x30 RSP: 0018:ffffb253604cbd88 EFLAGS: 00000247 RAX: 000000000001960d RBX: 0000000000000002 RCX: ffff8cad2a064800 RDX: 000000008020001b RSI: 0000000000000001 RDI: ffff8cad5d39f66c RBP: ffff8cad5d39f600 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8caa443e0c00 R11: ffffb253604cbcd8 R12: ffff8cacb8682538 R13: 0000000000000005 R14: ffffb253604cbd90 R15: ffff8cad5d39f66c cm_process_send_error+0x122/0x1d0 [ib_cm] timeout_sends+0x1dd/0x270 [ib_core] process_one_work+0x1e2/0x3b0 ? __pfx_worker_thread+0x10/0x10 worker_thread+0x50/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xdd/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x50 Simplified timeout handler by creating local list of timed out WRs and invoke send handler post creating the list. The new method acquires/ releases lock once to fetch the list and hence helps to reduce locking contetiong when processing higher no. of WRs", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50063", "url": "https://ubuntu.com/security/CVE-2024-50063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Prevent tail call between progs attached to different hooks bpf progs can be attached to kernel functions, and the attached functions can take different parameters or return different return values. If prog attached to one kernel function tail calls prog attached to another kernel function, the ctx access or return value verification could be bypassed. For example, if prog1 is attached to func1 which takes only 1 parameter and prog2 is attached to func2 which takes two parameters. Since verifier assumes the bpf ctx passed to prog2 is constructed based on func2's prototype, verifier allows prog2 to access the second parameter from the bpf ctx passed to it. The problem is that verifier does not prevent prog1 from passing its bpf ctx to prog2 via tail call. In this case, the bpf ctx passed to prog2 is constructed from func1 instead of func2, that is, the assumption for ctx access verification is bypassed. Another example, if BPF LSM prog1 is attached to hook file_alloc_security, and BPF LSM prog2 is attached to hook bpf_lsm_audit_rule_known. Verifier knows the return value rules for these two hooks, e.g. it is legal for bpf_lsm_audit_rule_known to return positive number 1, and it is illegal for file_alloc_security to return positive number. So verifier allows prog2 to return positive number 1, but does not allow prog1 to return positive number. The problem is that verifier does not prevent prog1 from calling prog2 via tail call. In this case, prog2's return value 1 will be used as the return value for prog1's hook file_alloc_security. That is, the return value rule is bypassed. This patch adds restriction for tail call to prevent such bypasses.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50191", "url": "https://ubuntu.com/security/CVE-2024-50191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: don't set SB_RDONLY after filesystem errors When the filesystem is mounted with errors=remount-ro, we were setting SB_RDONLY flag to stop all filesystem modifications. We knew this misses proper locking (sb->s_umount) and does not go through proper filesystem remount procedure but it has been the way this worked since early ext2 days and it was good enough for catastrophic situation damage mitigation. Recently, syzbot has found a way (see link) to trigger warnings in filesystem freezing because the code got confused by SB_RDONLY changing under its hands. Since these days we set EXT4_FLAGS_SHUTDOWN on the superblock which is enough to stop all filesystem modifications, modifying SB_RDONLY shouldn't be needed. So stop doing that.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50064", "url": "https://ubuntu.com/security/CVE-2024-50064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: zram: free secondary algorithms names We need to kfree() secondary algorithms names when reset zram device that had multi-streams, otherwise we leak memory. [senozhatsky@chromium.org: kfree(NULL) is legal] Link: https://lkml.kernel.org/r/20240917013021.868769-1-senozhatsky@chromium.org", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50065", "url": "https://ubuntu.com/security/CVE-2024-50065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Change to non-blocking allocation in ntfs_d_hash d_hash is done while under \"rcu-walk\" and should not sleep. __get_name() allocates using GFP_KERNEL, having the possibility to sleep when under memory pressure. Change the allocation to GFP_NOWAIT.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50089", "url": "https://ubuntu.com/security/CVE-2024-50089", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-49863", "url": "https://ubuntu.com/security/CVE-2024-49863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost/scsi: null-ptr-dereference in vhost_scsi_get_req() Since commit 3f8ca2e115e5 (\"vhost/scsi: Extract common handling code from control queue handler\") a null pointer dereference bug can be triggered when guest sends an SCSI AN request. In vhost_scsi_ctl_handle_vq(), `vc.target` is assigned with `&v_req.tmf.lun[1]` within a switch-case block and is then passed to vhost_scsi_get_req() which extracts `vc->req` and `tpg`. However, for a `VIRTIO_SCSI_T_AN_*` request, tpg is not required, so `vc.target` is set to NULL in this branch. Later, in vhost_scsi_get_req(), `vc->target` is dereferenced without being checked, leading to a null pointer dereference bug. This bug can be triggered from guest. When this bug occurs, the vhost_worker process is killed while holding `vq->mutex` and the corresponding tpg will remain occupied indefinitely. Below is the KASAN report: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 PID: 840 Comm: poc Not tainted 6.10.0+ #1 Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:vhost_scsi_get_req+0x165/0x3a0 Code: 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 02 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 65 30 4c 89 e2 48 c1 ea 03 <0f> b6 04 02 4c 89 e2 83 e2 07 38 d0 7f 08 84 c0 0f 85 be 01 00 00 RSP: 0018:ffff888017affb50 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffff88801b000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888017affcb8 RBP: ffff888017affb80 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff888017affc88 R14: ffff888017affd1c R15: ffff888017993000 FS: 000055556e076500(0000) GS:ffff88806b100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200027c0 CR3: 0000000010ed0004 CR4: 0000000000370ef0 Call Trace: ? show_regs+0x86/0xa0 ? die_addr+0x4b/0xd0 ? exc_general_protection+0x163/0x260 ? asm_exc_general_protection+0x27/0x30 ? vhost_scsi_get_req+0x165/0x3a0 vhost_scsi_ctl_handle_vq+0x2a4/0xca0 ? __pfx_vhost_scsi_ctl_handle_vq+0x10/0x10 ? __switch_to+0x721/0xeb0 ? __schedule+0xda5/0x5710 ? __kasan_check_write+0x14/0x30 ? _raw_spin_lock+0x82/0xf0 vhost_scsi_ctl_handle_kick+0x52/0x90 vhost_run_work_list+0x134/0x1b0 vhost_task_fn+0x121/0x350 ... ---[ end trace 0000000000000000 ]--- Let's add a check in vhost_scsi_get_req. [whitespace fixes]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49864", "url": "https://ubuntu.com/security/CVE-2024-49864", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix a race between socket set up and I/O thread creation In rxrpc_open_socket(), it sets up the socket and then sets up the I/O thread that will handle it. This is a problem, however, as there's a gap between the two phases in which a packet may come into rxrpc_encap_rcv() from the UDP packet but we oops when trying to wake the not-yet created I/O thread. As a quick fix, just make rxrpc_encap_rcv() discard the packet if there's no I/O thread yet. A better, but more intrusive fix would perhaps be to rearrange things such that the socket creation is done by the I/O thread.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49865", "url": "https://ubuntu.com/security/CVE-2024-49865", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: move xa_alloc to prevent UAF Evil user can guess the next id of the vm before the ioctl completes and then call vm destroy ioctl to trigger UAF since create ioctl is still referencing the same vm. Move the xa_alloc all the way to the end to prevent this. v2: - Rebase (cherry picked from commit dcfd3971327f3ee92765154baebbaece833d3ca9)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49955", "url": "https://ubuntu.com/security/CVE-2024-49955", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: battery: Fix possible crash when unregistering a battery hook When a battery hook returns an error when adding a new battery, then the battery hook is automatically unregistered. However the battery hook provider cannot know that, so it will later call battery_hook_unregister() on the already unregistered battery hook, resulting in a crash. Fix this by using the list head to mark already unregistered battery hooks as already being unregistered so that they can be ignored by battery_hook_unregister().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49973", "url": "https://ubuntu.com/security/CVE-2024-49973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: r8169: add tally counter fields added with RTL8125 RTL8125 added fields to the tally counter, what may result in the chip dma'ing these new fields to unallocated memory. Therefore make sure that the allocated memory area is big enough to hold all of the tally counter values, even if we use only parts of it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49974", "url": "https://ubuntu.com/security/CVE-2024-49974", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Limit the number of concurrent async COPY operations Nothing appears to limit the number of concurrent async COPY operations that clients can start. In addition, AFAICT each async COPY can copy an unlimited number of 4MB chunks, so can run for a long time. Thus IMO async COPY can become a DoS vector. Add a restriction mechanism that bounds the number of concurrent background COPY operations. Start simple and try to be fair -- this patch implements a per-namespace limit. An async COPY request that occurs while this limit is exceeded gets NFS4ERR_DELAY. The requesting client can choose to send the request again after a delay or fall back to a traditional read/write style copy. If there is need to make the mechanism more sophisticated, we can visit that in future patches.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49975", "url": "https://ubuntu.com/security/CVE-2024-49975", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uprobes: fix kernel info leak via \"[uprobes]\" vma xol_add_vma() maps the uninitialized page allocated by __create_xol_area() into userspace. On some architectures (x86) this memory is readable even without VM_READ, VM_EXEC results in the same pgprot_t as VM_EXEC|VM_READ, although this doesn't really matter, debugger can read this memory anyway.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50003", "url": "https://ubuntu.com/security/CVE-2024-50003", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix system hang while resume with TBT monitor [Why] Connected with a Thunderbolt monitor and do the suspend and the system may hang while resume. The TBT monitor HPD will be triggered during the resume procedure and call the drm_client_modeset_probe() while struct drm_connector connector->dev->master is NULL. It will mess up the pipe topology after resume. [How] Skip the TBT monitor HPD during the resume procedure because we currently will probe the connectors after resume by default. (cherry picked from commit 453f86a26945207a16b8f66aaed5962dc2b95b85)", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50173", "url": "https://ubuntu.com/security/CVE-2024-50173", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix access to uninitialized variable in tick_ctx_cleanup() The group variable can't be used to retrieve ptdev in our second loop, because it points to the previously iterated list_head, not a valid group. Get the ptdev object from the scheduler instead.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49866", "url": "https://ubuntu.com/security/CVE-2024-49866", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Fix a race during cpuhp processing There is another found exception that the \"timerlat/1\" thread was scheduled on CPU0, and lead to timer corruption finally: ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ``` After tracing the scheduling event, it was discovered that the migration of the \"timerlat/1\" thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() | To fix this, skip online processing if the CPU is already offline.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49976", "url": "https://ubuntu.com/security/CVE-2024-49976", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Drop interface_lock in stop_kthread() stop_kthread() is the offline callback for \"trace/osnoise:online\", since commit 5bfbcd1ee57b (\"tracing/timerlat: Add interface_lock around clearing of kthread in stop_kthread()\"), the following ABBA deadlock scenario is introduced: T1 | T2 [BP] | T3 [AP] osnoise_hotplug_workfn() | work_for_cpu_fn() | cpuhp_thread_fun() | _cpu_down() | osnoise_cpu_die() mutex_lock(&interface_lock) | | stop_kthread() | cpus_write_lock() | mutex_lock(&interface_lock) cpus_read_lock() | cpuhp_kick_ap() | As the interface_lock here in just for protecting the \"kthread\" field of the osn_var, use xchg() instead to fix this issue. Also use for_each_online_cpu() back in stop_per_cpu_kthreads() as it can take cpu_read_lock() again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50005", "url": "https://ubuntu.com/security/CVE-2024-50005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: Fix potential RCU dereference issue in mac802154_scan_worker In the `mac802154_scan_worker` function, the `scan_req->type` field was accessed after the RCU read-side critical section was unlocked. According to RCU usage rules, this is illegal and can lead to unpredictable behavior, such as accessing memory that has been updated or causing use-after-free issues. This possible bug was identified using a static analysis tool developed by myself, specifically designed to detect RCU-related issues. To address this, the `scan_req->type` value is now stored in a local variable `scan_req_type` while still within the RCU read-side critical section. The `scan_req_type` is then used after the RCU lock is released, ensuring that the type value is safely accessed without violating RCU rules.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50012", "url": "https://ubuntu.com/security/CVE-2024-50012", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: Avoid a bad reference count on CPU node In the parse_perf_domain function, if the call to of_parse_phandle_with_args returns an error, then the reference to the CPU device node that was acquired at the start of the function would not be properly decremented. Address this by declaring the variable with the __free(device_node) cleanup attribute.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49867", "url": "https://ubuntu.com/security/CVE-2024-49867", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: wait for fixup workers before stopping cleaner kthread during umount During unmount, at close_ctree(), we have the following steps in this order: 1) Park the cleaner kthread - this doesn't destroy the kthread, it basically halts its execution (wake ups against it work but do nothing); 2) We stop the cleaner kthread - this results in freeing the respective struct task_struct; 3) We call btrfs_stop_all_workers() which waits for any jobs running in all the work queues and then free the work queues. Syzbot reported a case where a fixup worker resulted in a crash when doing a delayed iput on its inode while attempting to wake up the cleaner at btrfs_add_delayed_iput(), because the task_struct of the cleaner kthread was already freed. This can happen during unmount because we don't wait for any fixup workers still running before we call kthread_stop() against the cleaner kthread, which stops and free all its resources. Fix this by waiting for any fixup workers at close_ctree() before we call kthread_stop() against the cleaner and run pending delayed iputs. The stack traces reported by syzbot were the following: BUG: KASAN: slab-use-after-free in __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 Read of size 8 at addr ffff8880272a8a18 by task kworker/u8:3/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.12.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: btrfs-fixup btrfs_work_helper 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 __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline] try_to_wake_up+0xb0/0x1480 kernel/sched/core.c:4154 btrfs_writepage_fixup_worker+0xc16/0xdf0 fs/btrfs/inode.c:2842 btrfs_work_helper+0x390/0xc50 fs/btrfs/async-thread.c:314 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Allocated by task 2: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:319 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345 kasan_slab_alloc include/linux/kasan.h:247 [inline] slab_post_alloc_hook mm/slub.c:4086 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4187 alloc_task_struct_node kernel/fork.c:180 [inline] dup_task_struct+0x57/0x8c0 kernel/fork.c:1107 copy_process+0x5d1/0x3d50 kernel/fork.c:2206 kernel_clone+0x223/0x880 kernel/fork.c:2787 kernel_thread+0x1bc/0x240 kernel/fork.c:2849 create_kthread kernel/kthread.c:412 [inline] kthreadd+0x60d/0x810 kernel/kthread.c:765 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Freed by task 61: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:230 [inline] slab_free_h ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49868", "url": "https://ubuntu.com/security/CVE-2024-49868", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix a NULL pointer dereference when failed to start a new trasacntion [BUG] Syzbot reported a NULL pointer dereference with the following crash: FAULT_INJECTION: forcing a failure. start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676 prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642 relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678 ... BTRFS info (device loop0): balance: ended with status: -12 Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667] RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926 Call Trace: commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496 btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430 del_balance_item fs/btrfs/volumes.c:3678 [inline] reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742 btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574 btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673 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/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [CAUSE] The allocation failure happens at the start_transaction() inside prepare_to_relocate(), and during the error handling we call unset_reloc_control(), which makes fs_info->balance_ctl to be NULL. Then we continue the error path cleanup in btrfs_balance() by calling reset_balance_state() which will call del_balance_item() to fully delete the balance item in the root tree. However during the small window between set_reloc_contrl() and unset_reloc_control(), we can have a subvolume tree update and created a reloc_root for that subvolume. Then we go into the final btrfs_commit_transaction() of del_balance_item(), and into btrfs_update_reloc_root() inside commit_fs_roots(). That function checks if fs_info->reloc_ctl is in the merge_reloc_tree stage, but since fs_info->reloc_ctl is NULL, it results a NULL pointer dereference. [FIX] Just add extra check on fs_info->reloc_ctl inside btrfs_update_reloc_root(), before checking fs_info->reloc_ctl->merge_reloc_tree. That DEAD_RELOC_TREE handling is to prevent further modification to the reloc tree during merge stage, but since there is no reloc_ctl at all, we do not need to bother that.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49869", "url": "https://ubuntu.com/security/CVE-2024-49869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: send: fix buffer overflow detection when copying path to cache entry Starting with commit c0247d289e73 (\"btrfs: send: annotate struct name_cache_entry with __counted_by()\") we annotated the variable length array \"name\" from the name_cache_entry structure with __counted_by() to improve overflow detection. However that alone was not correct, because the length of that array does not match the \"name_len\" field - it matches that plus 1 to include the NUL string terminator, so that makes a fortified kernel think there's an overflow and report a splat like this: strcpy: detected buffer overflow: 20 byte write of buffer size 19 WARNING: CPU: 3 PID: 3310 at __fortify_report+0x45/0x50 CPU: 3 UID: 0 PID: 3310 Comm: btrfs Not tainted 6.11.0-prnet #1 Hardware name: CompuLab Ltd. sbc-ihsw/Intense-PC2 (IPC2), BIOS IPC2_3.330.7 X64 03/15/2018 RIP: 0010:__fortify_report+0x45/0x50 Code: 48 8b 34 (...) RSP: 0018:ffff97ebc0d6f650 EFLAGS: 00010246 RAX: 7749924ef60fa600 RBX: ffff8bf5446a521a RCX: 0000000000000027 RDX: 00000000ffffdfff RSI: ffff97ebc0d6f548 RDI: ffff8bf84e7a1cc8 RBP: ffff8bf548574080 R08: ffffffffa8c40e10 R09: 0000000000005ffd R10: 0000000000000004 R11: ffffffffa8c70e10 R12: ffff8bf551eef400 R13: 0000000000000000 R14: 0000000000000013 R15: 00000000000003a8 FS: 00007fae144de8c0(0000) GS:ffff8bf84e780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fae14691690 CR3: 00000001027a2003 CR4: 00000000001706f0 Call Trace: ? __warn+0x12a/0x1d0 ? __fortify_report+0x45/0x50 ? report_bug+0x154/0x1c0 ? handle_bug+0x42/0x70 ? exc_invalid_op+0x1a/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? __fortify_report+0x45/0x50 __fortify_panic+0x9/0x10 __get_cur_name_and_parent+0x3bc/0x3c0 get_cur_path+0x207/0x3b0 send_extent_data+0x709/0x10d0 ? find_parent_nodes+0x22df/0x25d0 ? mas_nomem+0x13/0x90 ? mtree_insert_range+0xa5/0x110 ? btrfs_lru_cache_store+0x5f/0x1e0 ? iterate_extent_inodes+0x52d/0x5a0 process_extent+0xa96/0x11a0 ? __pfx_lookup_backref_cache+0x10/0x10 ? __pfx_store_backref_cache+0x10/0x10 ? __pfx_iterate_backrefs+0x10/0x10 ? __pfx_check_extent_item+0x10/0x10 changed_cb+0x6fa/0x930 ? tree_advance+0x362/0x390 ? memcmp_extent_buffer+0xd7/0x160 send_subvol+0xf0a/0x1520 btrfs_ioctl_send+0x106b/0x11d0 ? __pfx___clone_root_cmp_sort+0x10/0x10 _btrfs_ioctl_send+0x1ac/0x240 btrfs_ioctl+0x75b/0x850 __se_sys_ioctl+0xca/0x150 do_syscall_64+0x85/0x160 ? __count_memcg_events+0x69/0x100 ? handle_mm_fault+0x1327/0x15c0 ? __se_sys_rt_sigprocmask+0xf1/0x180 ? syscall_exit_to_user_mode+0x75/0xa0 ? do_syscall_64+0x91/0x160 ? do_user_addr_fault+0x21d/0x630 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fae145eeb4f Code: 00 48 89 (...) RSP: 002b:00007ffdf1cb09b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fae145eeb4f RDX: 00007ffdf1cb0ad0 RSI: 0000000040489426 RDI: 0000000000000004 RBP: 00000000000078fe R08: 00007fae144006c0 R09: 00007ffdf1cb0927 R10: 0000000000000008 R11: 0000000000000246 R12: 00007ffdf1cb1ce8 R13: 0000000000000003 R14: 000055c499fab2e0 R15: 0000000000000004 Fix this by not storing the NUL string terminator since we don't actually need it for name cache entries, this way \"name_len\" corresponds to the actual size of the \"name\" array. This requires marking the \"name\" array field with __nonstring and using memcpy() instead of strcpy() as recommended by the guidelines at: https://github.com/KSPP/linux/issues/90", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49870", "url": "https://ubuntu.com/security/CVE-2024-49870", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cachefiles: fix dentry leak in cachefiles_open_file() A dentry leak may be caused when a lookup cookie and a cull are concurrent: P1 | P2 ----------------------------------------------------------- cachefiles_lookup_cookie cachefiles_look_up_object lookup_one_positive_unlocked // get dentry cachefiles_cull inode->i_flags |= S_KERNEL_FILE; cachefiles_open_file cachefiles_mark_inode_in_use __cachefiles_mark_inode_in_use can_use = false if (!(inode->i_flags & S_KERNEL_FILE)) can_use = true \t return false return false // Returns an error but doesn't put dentry After that the following WARNING will be triggered when the backend folder is umounted: ================================================================== BUG: Dentry 000000008ad87947{i=7a,n=Dx_1_1.img} still in use (1) [unmount of ext4 sda] WARNING: CPU: 4 PID: 359261 at fs/dcache.c:1767 umount_check+0x5d/0x70 CPU: 4 PID: 359261 Comm: umount Not tainted 6.6.0-dirty #25 RIP: 0010:umount_check+0x5d/0x70 Call Trace: d_walk+0xda/0x2b0 do_one_tree+0x20/0x40 shrink_dcache_for_umount+0x2c/0x90 generic_shutdown_super+0x20/0x160 kill_block_super+0x1a/0x40 ext4_kill_sb+0x22/0x40 deactivate_locked_super+0x35/0x80 cleanup_mnt+0x104/0x160 ================================================================== Whether cachefiles_open_file() returns true or false, the reference count obtained by lookup_positive_unlocked() in cachefiles_look_up_object() should be released. Therefore release that reference count in cachefiles_look_up_object() to fix the above issue and simplify the code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49871", "url": "https://ubuntu.com/security/CVE-2024-49871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: adp5589-keys - fix NULL pointer dereference We register a devm action to call adp5589_clear_config() and then pass the i2c client as argument so that we can call i2c_get_clientdata() in order to get our device object. However, i2c_set_clientdata() is only being set at the end of the probe function which means that we'll get a NULL pointer dereference in case the probe function fails early.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49872", "url": "https://ubuntu.com/security/CVE-2024-49872", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/gup: fix memfd_pin_folios alloc race panic If memfd_pin_folios tries to create a hugetlb page, but someone else already did, then folio gets the value -EEXIST here: folio = memfd_alloc_folio(memfd, start_idx); if (IS_ERR(folio)) { ret = PTR_ERR(folio); if (ret != -EEXIST) goto err; then on the next trip through the \"while start_idx\" loop we panic here: if (folio) { folio_put(folio); To fix, set the folio to NULL on error.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49964", "url": "https://ubuntu.com/security/CVE-2024-49964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix memfd_pin_folios free_huge_pages leak memfd_pin_folios followed by unpin_folios fails to restore free_huge_pages if the pages were not already faulted in, because the folio refcount for pages created by memfd_alloc_folio never goes to 0. memfd_pin_folios needs another folio_put to undo the folio_try_get below: memfd_alloc_folio() alloc_hugetlb_folio_nodemask() dequeue_hugetlb_folio_nodemask() dequeue_hugetlb_folio_node_exact() folio_ref_unfreeze(folio, 1); ; adds 1 refcount folio_try_get() ; adds 1 refcount hugetlb_add_to_page_cache() ; adds 512 refcount (on x86) With the fix, after memfd_pin_folios + unpin_folios, the refcount for the (unfaulted) page is 512, which is correct, as the refcount for a faulted unpinned page is 513.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49873", "url": "https://ubuntu.com/security/CVE-2024-49873", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/filemap: fix filemap_get_folios_contig THP panic Patch series \"memfd-pin huge page fixes\". Fix multiple bugs that occur when using memfd_pin_folios with hugetlb pages and THP. The hugetlb bugs only bite when the page is not yet faulted in when memfd_pin_folios is called. The THP bug bites when the starting offset passed to memfd_pin_folios is not huge page aligned. See the commit messages for details. This patch (of 5): memfd_pin_folios on memory backed by THP panics if the requested start offset is not huge page aligned: BUG: kernel NULL pointer dereference, address: 0000000000000036 RIP: 0010:filemap_get_folios_contig+0xdf/0x290 RSP: 0018:ffffc9002092fbe8 EFLAGS: 00010202 RAX: 0000000000000002 RBX: 0000000000000002 RCX: 0000000000000002 The fault occurs here, because xas_load returns a folio with value 2: filemap_get_folios_contig() for (folio = xas_load(&xas); folio && xas.xa_index <= end; folio = xas_next(&xas)) { ... if (!folio_try_get(folio)) <-- BOOM \"2\" is an xarray sibling entry. We get it because memfd_pin_folios does not round the indices passed to filemap_get_folios_contig to huge page boundaries for THP, so we load from the middle of a huge page range see a sibling. (It does round for hugetlbfs, at the is_file_hugepages test). To fix, if the folio is a sibling, then return the next index as the starting point for the next call to filemap_get_folios_contig.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49977", "url": "https://ubuntu.com/security/CVE-2024-49977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: Fix zero-division error when disabling tc cbs The commit b8c43360f6e4 (\"net: stmmac: No need to calculate speed divider when offload is disabled\") allows the \"port_transmit_rate_kbps\" to be set to a value of 0, which is then passed to the \"div_s64\" function when tc-cbs is disabled. This leads to a zero-division error. When tc-cbs is disabled, the idleslope, sendslope, and credit values the credit values are not required to be configured. Therefore, adding a return statement after setting the txQ mode to DCB when tc-cbs is disabled would prevent a zero-division error.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49978", "url": "https://ubuntu.com/security/CVE-2024-49978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gso: fix udp gso fraglist segmentation after pull from frag_list Detect gso fraglist skbs with corrupted geometry (see below) and pass these to skb_segment instead of skb_segment_list, as the first can segment them correctly. 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 these skbs, breaking these invariants. In extreme cases they pull all data into skb linear. For UDP, this causes a NULL ptr deref in __udpv4_gso_segment_list_csum at udp_hdr(seg->next)->dest. Detect invalid geometry due to pull, by checking head_skb size. Don't just drop, as this may blackhole a destination. Convert to be able to pass to regular skb_segment.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49979", "url": "https://ubuntu.com/security/CVE-2024-49979", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gso: fix tcp fraglist segmentation after pull from frag_list Detect tcp gso fraglist skbs with corrupted geometry (see below) and pass these to skb_segment instead of skb_segment_list, as the first can segment them correctly. 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 these skbs, breaking these invariants. In extreme cases they pull all data into skb linear. For TCP, this causes a NULL ptr deref in __tcpv4_gso_segment_list_csum at tcp_hdr(seg->next). Detect invalid geometry due to pull, by checking head_skb size. Don't just drop, as this may blackhole a destination. Convert to be able to pass to regular skb_segment. Approach and description based on a patch by Willem de Bruijn.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49980", "url": "https://ubuntu.com/security/CVE-2024-49980", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vrf: revert \"vrf: Remove unnecessary RCU-bh critical section\" This reverts commit 504fc6f4f7f681d2a03aa5f68aad549d90eab853. dev_queue_xmit_nit is expected to be called with BH disabled. __dev_queue_xmit has the following: /* Disable soft irqs for various locks below. Also * stops preemption for RCU. */ rcu_read_lock_bh(); VRF must follow this invariant. The referenced commit removed this protection. Which triggered a lockdep warning: \t================================ \tWARNING: inconsistent lock state \t6.11.0 #1 Tainted: G W \t-------------------------------- \tinconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage. \tbtserver/134819 [HC0[0]:SC0[0]:HE1:SE1] takes: \tffff8882da30c118 (rlock-AF_PACKET){+.?.}-{2:2}, at: tpacket_rcv+0x863/0x3b30 \t{IN-SOFTIRQ-W} state was registered at: \t lock_acquire+0x19a/0x4f0 \t _raw_spin_lock+0x27/0x40 \t packet_rcv+0xa33/0x1320 \t __netif_receive_skb_core.constprop.0+0xcb0/0x3a90 \t __netif_receive_skb_list_core+0x2c9/0x890 \t netif_receive_skb_list_internal+0x610/0xcc0 [...] \tother info that might help us debug this: \t Possible unsafe locking scenario: \t CPU0 \t ---- \t lock(rlock-AF_PACKET); \t \t lock(rlock-AF_PACKET); \t *** DEADLOCK *** \tCall Trace: \t \t dump_stack_lvl+0x73/0xa0 \t mark_lock+0x102e/0x16b0 \t __lock_acquire+0x9ae/0x6170 \t lock_acquire+0x19a/0x4f0 \t _raw_spin_lock+0x27/0x40 \t tpacket_rcv+0x863/0x3b30 \t dev_queue_xmit_nit+0x709/0xa40 \t vrf_finish_direct+0x26e/0x340 [vrf] \t vrf_l3_out+0x5f4/0xe80 [vrf] \t __ip_local_out+0x51e/0x7a0 [...]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49981", "url": "https://ubuntu.com/security/CVE-2024-49981", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: venus: fix use after free bug in venus_remove due to race condition in venus_probe, core->work is bound with venus_sys_error_handler, which is used to handle error. The code use core->sys_err_done to make sync work. The core->work is started in venus_event_notify. If we call venus_remove, there might be an unfished work. The possible sequence is as follows: CPU0 CPU1 |venus_sys_error_handler venus_remove | hfi_destroy\t \t\t | venus_hfi_destroy\t | kfree(hdev);\t | |hfi_reinit \t\t\t\t\t |venus_hfi_queues_reinit |//use hdev Fix it by canceling the work in venus_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49956", "url": "https://ubuntu.com/security/CVE-2024-49956", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: fix double destroy_workqueue error When gfs2_fill_super() fails, destroy_workqueue() is called within gfs2_gl_hash_clear(), and the subsequent code path calls destroy_workqueue() on the same work queue again. This issue can be fixed by setting the work queue pointer to NULL after the first destroy_workqueue() call and checking for a NULL pointer before attempting to destroy the work queue again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50176", "url": "https://ubuntu.com/security/CVE-2024-50176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: k3-r5: Fix error handling when power-up failed By simply bailing out, the driver was violating its rule and internal assumptions that either both or no rproc should be initialized. E.g., this could cause the first core to be available but not the second one, leading to crashes on its shutdown later on while trying to dereference that second instance.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49982", "url": "https://ubuntu.com/security/CVE-2024-49982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: aoe: fix the potential use-after-free problem in more places For fixing CVE-2023-6270, f98364e92662 (\"aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts\") makes tx() calling dev_put() instead of doing in aoecmd_cfg_pkts(). It avoids that the tx() runs into use-after-free. Then Nicolai Stange found more places in aoe have potential use-after-free problem with tx(). e.g. revalidate(), aoecmd_ata_rw(), resend(), probe() and aoecmd_cfg_rsp(). Those functions also use aoenet_xmit() to push packet to tx queue. So they should also use dev_hold() to increase the refcnt of skb->dev. On the other hand, moving dev_put() to tx() causes that the refcnt of skb->dev be reduced to a negative value, because corresponding dev_hold() are not called in revalidate(), aoecmd_ata_rw(), resend(), probe(), and aoecmd_cfg_rsp(). This patch fixed this issue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49874", "url": "https://ubuntu.com/security/CVE-2024-49874", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: svc: Fix use after free vulnerability in svc_i3c_master Driver Due to Race Condition In the svc_i3c_master_probe function, &master->hj_work is bound with svc_i3c_master_hj_work, &master->ibi_work is bound with svc_i3c_master_ibi_work. And svc_i3c_master_ibi_work can start the hj_work, svc_i3c_master_irq_handler can start the ibi_work. If we remove the module which will call svc_i3c_master_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | svc_i3c_master_hj_work svc_i3c_master_remove | i3c_master_unregister(&master->base)| device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in svc_i3c_master_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49875", "url": "https://ubuntu.com/security/CVE-2024-49875", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: map the EBADMSG to nfserr_io to avoid warning Ext4 will throw -EBADMSG through ext4_readdir when a checksum error occurs, resulting in the following WARNING. Fix it by mapping EBADMSG to nfserr_io. nfsd_buffered_readdir iterate_dir // -EBADMSG -74 ext4_readdir // .iterate_shared ext4_dx_readdir ext4_htree_fill_tree htree_dirblock_to_tree ext4_read_dirblock __ext4_read_dirblock ext4_dirblock_csum_verify warn_no_space_for_csum __warn_no_space_for_csum return ERR_PTR(-EFSBADCRC) // -EBADMSG -74 nfserrno // WARNING [ 161.115610] ------------[ cut here ]------------ [ 161.116465] nfsd: non-standard errno: -74 [ 161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0 [ 161.118596] Modules linked in: [ 161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138 [ 161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qe mu.org 04/01/2014 [ 161.123601] RIP: 0010:nfserrno+0x9d/0xd0 [ 161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6 05 ce 2b 61 03 01 e8 99 20 d8 00 <0f> 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33 [ 161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286 [ 161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a [ 161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827 [ 161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021 [ 161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8 [ 161.135244] FS: 0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000 [ 161.136695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0 [ 161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 161.141519] PKRU: 55555554 [ 161.142076] Call Trace: [ 161.142575] ? __warn+0x9b/0x140 [ 161.143229] ? nfserrno+0x9d/0xd0 [ 161.143872] ? report_bug+0x125/0x150 [ 161.144595] ? handle_bug+0x41/0x90 [ 161.145284] ? exc_invalid_op+0x14/0x70 [ 161.146009] ? asm_exc_invalid_op+0x12/0x20 [ 161.146816] ? nfserrno+0x9d/0xd0 [ 161.147487] nfsd_buffered_readdir+0x28b/0x2b0 [ 161.148333] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.149258] ? nfsd_buffered_filldir+0xf0/0xf0 [ 161.150093] ? wait_for_concurrent_writes+0x170/0x170 [ 161.151004] ? generic_file_llseek_size+0x48/0x160 [ 161.151895] nfsd_readdir+0x132/0x190 [ 161.152606] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.153516] ? nfsd_unlink+0x380/0x380 [ 161.154256] ? override_creds+0x45/0x60 [ 161.155006] nfsd4_encode_readdir+0x21a/0x3d0 [ 161.155850] ? nfsd4_encode_readlink+0x210/0x210 [ 161.156731] ? write_bytes_to_xdr_buf+0x97/0xe0 [ 161.157598] ? __write_bytes_to_xdr_buf+0xd0/0xd0 [ 161.158494] ? lock_downgrade+0x90/0x90 [ 161.159232] ? nfs4svc_decode_voidarg+0x10/0x10 [ 161.160092] nfsd4_encode_operation+0x15a/0x440 [ 161.160959] nfsd4_proc_compound+0x718/0xe90 [ 161.161818] nfsd_dispatch+0x18e/0x2c0 [ 161.162586] svc_process_common+0x786/0xc50 [ 161.163403] ? nfsd_svc+0x380/0x380 [ 161.164137] ? svc_printk+0x160/0x160 [ 161.164846] ? svc_xprt_do_enqueue.part.0+0x365/0x380 [ 161.165808] ? nfsd_svc+0x380/0x380 [ 161.166523] ? rcu_is_watching+0x23/0x40 [ 161.167309] svc_process+0x1a5/0x200 [ 161.168019] nfsd+0x1f5/0x380 [ 161.168663] ? nfsd_shutdown_threads+0x260/0x260 [ 161.169554] kthread+0x1c4/0x210 [ 161.170224] ? kthread_insert_work_sanity_check+0x80/0x80 [ 161.171246] ret_from_fork+0x1f/0x30", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50013", "url": "https://ubuntu.com/security/CVE-2024-50013", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix memory leak in exfat_load_bitmap() If the first directory entry in the root directory is not a bitmap directory entry, 'bh' will not be released and reassigned, which will cause a memory leak.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49876", "url": "https://ubuntu.com/security/CVE-2024-49876", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: fix UAF around queue destruction We currently do stuff like queuing the final destruction step on a random system wq, which will outlive the driver instance. With bad timing we can teardown the driver with one or more work workqueue still being alive leading to various UAF splats. Add a fini step to ensure user queues are properly torn down. At this point GuC should already be nuked so queue itself should no longer be referenced from hw pov. v2 (Matt B) - Looks much safer to use a waitqueue and then just wait for the xa_array to become empty before triggering the drain. (cherry picked from commit 861108666cc0e999cffeab6aff17b662e68774e3)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49877", "url": "https://ubuntu.com/security/CVE-2024-49877", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate When doing cleanup, if flags without OCFS2_BH_READAHEAD, it may trigger NULL pointer dereference in the following ocfs2_set_buffer_uptodate() if bh is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49957", "url": "https://ubuntu.com/security/CVE-2024-49957", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix null-ptr-deref when journal load failed. During the mounting process, if journal_reset() fails because of too short journal, then lead to jbd2_journal_load() fails with NULL j_sb_buffer. Subsequently, ocfs2_journal_shutdown() calls jbd2_journal_flush()->jbd2_cleanup_journal_tail()-> __jbd2_update_log_tail()->jbd2_journal_update_sb_log_tail() ->lock_buffer(journal->j_sb_buffer), resulting in a null-pointer dereference error. To resolve this issue, we should check the JBD2_LOADED flag to ensure the journal was properly loaded. Additionally, use journal instead of osb->journal directly to simplify the code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49965", "url": "https://ubuntu.com/security/CVE-2024-49965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove unreasonable unlock in ocfs2_read_blocks Patch series \"Misc fixes for ocfs2_read_blocks\", v5. This series contains 2 fixes for ocfs2_read_blocks(). The first patch fix the issue reported by syzbot, which detects bad unlock balance in ocfs2_read_blocks(). The second patch fixes an issue reported by Heming Zhao when reviewing above fix. This patch (of 2): There was a lock release before exiting, so remove the unreasonable unlock.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49966", "url": "https://ubuntu.com/security/CVE-2024-49966", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: cancel dqi_sync_work before freeing oinfo ocfs2_global_read_info() will initialize and schedule dqi_sync_work at the end, if error occurs after successfully reading global quota, it will trigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled: ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16c This reports that there is an active delayed work when freeing oinfo in error handling, so cancel dqi_sync_work first. BTW, return status instead of -1 when .read_file_info fails.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49958", "url": "https://ubuntu.com/security/CVE-2024-49958", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reserve space for inline xattr before attaching reflink tree One of our customers reported a crash and a corrupted ocfs2 filesystem. The crash was due to the detection of corruption. Upon troubleshooting, the fsck -fn output showed the below corruption [EXTENT_LIST_FREE] Extent list in owner 33080590 claims 230 as the next free chain record, but fsck believes the largest valid value is 227. Clamp the next record value? n The stat output from the debugfs.ocfs2 showed the following corruption where the \"Next Free Rec:\" had overshot the \"Count:\" in the root metadata block. Inode: 33080590 Mode: 0640 Generation: 2619713622 (0x9c25a856) FS Generation: 904309833 (0x35e6ac49) CRC32: 00000000 ECC: 0000 Type: Regular Attr: 0x0 Flags: Valid Dynamic Features: (0x16) HasXattr InlineXattr Refcounted Extended Attributes Block: 0 Extended Attributes Inline Size: 256 User: 0 (root) Group: 0 (root) Size: 281320357888 Links: 1 Clusters: 141738 ctime: 0x66911b56 0x316edcb8 -- Fri Jul 12 06:02:30.829349048 2024 atime: 0x66911d6b 0x7f7a28d -- Fri Jul 12 06:11:23.133669517 2024 mtime: 0x66911b56 0x12ed75d7 -- Fri Jul 12 06:02:30.317552087 2024 dtime: 0x0 -- Wed Dec 31 17:00:00 1969 Refcount Block: 2777346 Last Extblk: 2886943 Orphan Slot: 0 Sub Alloc Slot: 0 Sub Alloc Bit: 14 Tree Depth: 1 Count: 227 Next Free Rec: 230 ## Offset Clusters Block# 0 0 2310 2776351 1 2310 2139 2777375 2 4449 1221 2778399 3 5670 731 2779423 4 6401 566 2780447 ....... .... ....... ....... .... ....... The issue was in the reflink workfow while reserving space for inline xattr. The problematic function is ocfs2_reflink_xattr_inline(). By the time this function is called the reflink tree is already recreated at the destination inode from the source inode. At this point, this function reserves space for inline xattrs at the destination inode without even checking if there is space at the root metadata block. It simply reduces the l_count from 243 to 227 thereby making space of 256 bytes for inline xattr whereas the inode already has extents beyond this index (in this case up to 230), thereby causing corruption. The fix for this is to reserve space for inline metadata at the destination inode before the reflink tree gets recreated. The customer has verified the fix.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49959", "url": "https://ubuntu.com/security/CVE-2024-49959", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail() to recover some journal space. But if an error occurs while executing jbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for free space right away, we try other branches, and if j_committing_transaction is NULL (i.e., the tid is 0), we will get the following complain: ============================================ JBD2: I/O error when updating journal superblock for sdd-8. __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available __jbd2_log_wait_for_space: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Call Trace: add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70 [...] ============================================ So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways. Note that this fix relies on commit 6f6a6fda2945 (\"jbd2: fix ocfs2 corrupt when updating journal superblock fails\") to make jbd2_cleanup_journal_tail return the correct error code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49878", "url": "https://ubuntu.com/security/CVE-2024-49878", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: resource: fix region_intersects() vs add_memory_driver_managed() On a system with CXL memory, the resource tree (/proc/iomem) related to CXL memory may look like something as follows. 490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem) Because drivers/dax/kmem.c calls add_memory_driver_managed() during onlining CXL memory, which makes \"System RAM (kmem)\" a descendant of \"CXL Window X\". This confuses region_intersects(), which expects all \"System RAM\" resources to be at the top level of iomem_resource. This can lead to bugs. For example, when the following command line is executed to write some memory in CXL memory range via /dev/mem, $ dd if=data of=/dev/mem bs=$((1 << 10)) seek=$((0x490000000 >> 10)) count=1 dd: error writing '/dev/mem': Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/s the command fails as expected. However, the error code is wrong. It should be \"Operation not permitted\" instead of \"Bad address\". More seriously, the /dev/mem permission checking in devmem_is_allowed() passes incorrectly. Although the accessing is prevented later because ioremap() isn't allowed to map system RAM, it is a potential security issue. During command executing, the following warning is reported in the kernel log for calling ioremap() on system RAM. ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d Call Trace: memremap+0xcb/0x184 xlate_dev_mem_ptr+0x25/0x2f write_mem+0x94/0xfb vfs_write+0x128/0x26d ksys_write+0xac/0xfe do_syscall_64+0x9a/0xfd entry_SYSCALL_64_after_hwframe+0x4b/0x53 The details of command execution process are as follows. In the above resource tree, \"System RAM\" is a descendant of \"CXL Window 0\" instead of a top level resource. So, region_intersects() will report no System RAM resources in the CXL memory region incorrectly, because it only checks the top level resources. Consequently, devmem_is_allowed() will return 1 (allow access via /dev/mem) for CXL memory region incorrectly. Fortunately, ioremap() doesn't allow to map System RAM and reject the access. So, region_intersects() needs to be fixed to work correctly with the resource tree with \"System RAM\" not at top level as above. To fix it, if we found a unmatched resource in the top level, we will continue to search matched resources in its descendant resources. So, we will not miss any matched resources in resource tree anymore. In the new implementation, an example resource tree |------------- \"CXL Window 0\" ------------| |-- \"System RAM\" --| will behave similar as the following fake resource tree for region_intersects(, IORESOURCE_SYSTEM_RAM, ), |-- \"System RAM\" --||-- \"CXL Window 0a\" --| Where \"CXL Window 0a\" is part of the original \"CXL Window 0\" that isn't covered by \"System RAM\".", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49879", "url": "https://ubuntu.com/security/CVE-2024-49879", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm: omapdrm: Add missing check for alloc_ordered_workqueue As it may return NULL pointer and cause NULL pointer dereference. Add check for the return value of alloc_ordered_workqueue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49880", "url": "https://ubuntu.com/security/CVE-2024-49880", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix off by one issue in alloc_flex_gd() Wesley reported an issue: ================================================================== EXT4-fs (dm-5): resizing filesystem from 7168 to 786432 blocks ------------[ cut here ]------------ kernel BUG at fs/ext4/resize.c:324! CPU: 9 UID: 0 PID: 3576 Comm: resize2fs Not tainted 6.11.0+ #27 RIP: 0010:ext4_resize_fs+0x1212/0x12d0 Call Trace: __ext4_ioctl+0x4e0/0x1800 ext4_ioctl+0x12/0x20 __x64_sys_ioctl+0x99/0xd0 x64_sys_call+0x1206/0x20d0 do_syscall_64+0x72/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e ================================================================== While reviewing the patch, Honza found that when adjusting resize_bg in alloc_flex_gd(), it was possible for flex_gd->resize_bg to be bigger than flexbg_size. The reproduction of the problem requires the following: o_group = flexbg_size * 2 * n; o_size = (o_group + 1) * group_size; n_group: [o_group + flexbg_size, o_group + flexbg_size * 2) o_size = (n_group + 1) * group_size; Take n=0,flexbg_size=16 as an example: last:15 |o---------------|--------------n-| o_group:0 resize to n_group:30 The corresponding reproducer is: img=test.img rm -f $img truncate -s 600M $img mkfs.ext4 -F $img -b 1024 -G 16 8M dev=`losetup -f --show $img` mkdir -p /tmp/test mount $dev /tmp/test resize2fs $dev 248M Delete the problematic plus 1 to fix the issue, and add a WARN_ON_ONCE() to prevent the issue from happening again. [ Note: another reproucer which this commit fixes is: img=test.img rm -f $img truncate -s 25MiB $img mkfs.ext4 -b 4096 -E nodiscard,lazy_itable_init=0,lazy_journal_init=0 $img truncate -s 3GiB $img dev=`losetup -f --show $img` mkdir -p /tmp/test mount $dev /tmp/test resize2fs $dev 3G umount $dev losetup -d $dev -- TYT ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49881", "url": "https://ubuntu.com/security/CVE-2024-49881", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: update orig_path in ext4_find_extent() In ext4_find_extent(), if the path is not big enough, we free it and set *orig_path to NULL. But after reallocating and successfully initializing the path, we don't update *orig_path, in which case the caller gets a valid path but a NULL ppath, and this may cause a NULL pointer dereference or a path memory leak. For example: ext4_split_extent path = *ppath = 2000 ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path = 2000); *orig_path = path = NULL; path = kcalloc() = 3000 ext4_split_extent_at(*ppath = NULL) path = *ppath; ex = path[depth].p_ext; // NULL pointer dereference! ================================================================== BUG: kernel NULL pointer dereference, address: 0000000000000010 CPU: 6 UID: 0 PID: 576 Comm: fsstress Not tainted 6.11.0-rc2-dirty #847 RIP: 0010:ext4_split_extent_at+0x6d/0x560 Call Trace: ext4_split_extent.isra.0+0xcb/0x1b0 ext4_ext_convert_to_initialized+0x168/0x6c0 ext4_ext_handle_unwritten_extents+0x325/0x4d0 ext4_ext_map_blocks+0x520/0xdb0 ext4_map_blocks+0x2b0/0x690 ext4_iomap_begin+0x20e/0x2c0 [...] ================================================================== Therefore, *orig_path is updated when the extent lookup succeeds, so that the caller can safely use path or *ppath.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50014", "url": "https://ubuntu.com/security/CVE-2024-50014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix access to uninitialised lock in fc replay path The following kernel trace can be triggered with fstest generic/629 when executed against a filesystem with fast-commit feature enabled: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x66/0x90 register_lock_class+0x759/0x7d0 __lock_acquire+0x85/0x2630 ? __find_get_block+0xb4/0x380 lock_acquire+0xd1/0x2d0 ? __ext4_journal_get_write_access+0xd5/0x160 _raw_spin_lock+0x33/0x40 ? __ext4_journal_get_write_access+0xd5/0x160 __ext4_journal_get_write_access+0xd5/0x160 ext4_reserve_inode_write+0x61/0xb0 __ext4_mark_inode_dirty+0x79/0x270 ? ext4_ext_replay_set_iblocks+0x2f8/0x450 ext4_ext_replay_set_iblocks+0x330/0x450 ext4_fc_replay+0x14c8/0x1540 ? jread+0x88/0x2e0 ? rcu_is_watching+0x11/0x40 do_one_pass+0x447/0xd00 jbd2_journal_recover+0x139/0x1b0 jbd2_journal_load+0x96/0x390 ext4_load_and_init_journal+0x253/0xd40 ext4_fill_super+0x2cc6/0x3180 ... In the replay path there's an attempt to lock sbi->s_bdev_wb_lock in function ext4_check_bdev_write_error(). Unfortunately, at this point this spinlock has not been initialized yet. Moving it's initialization to an earlier point in __ext4_fill_super() fixes this splat.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49960", "url": "https://ubuntu.com/security/CVE-2024-49960", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix timer use-after-free on failed mount Syzbot has found an ODEBUG bug in ext4_fill_super The del_timer_sync function cancels the s_err_report timer, which reminds about filesystem errors daily. We should guarantee the timer is no longer active before kfree(sbi). When filesystem mounting fails, the flow goes to failed_mount3, where an error occurs when ext4_stop_mmpd is called, causing a read I/O failure. This triggers the ext4_handle_error function that ultimately re-arms the timer, leaving the s_err_report timer active before kfree(sbi) is called. Fix the issue by canceling the s_err_report timer after calling ext4_stop_mmpd.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49882", "url": "https://ubuntu.com/security/CVE-2024-49882", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix double brelse() the buffer of the extents path In ext4_ext_try_to_merge_up(), set path[1].p_bh to NULL after it has been released, otherwise it may be released twice. An example of what triggers this is as follows: split2 map split1 |--------|-------|--------| ext4_ext_map_blocks ext4_ext_handle_unwritten_extents ext4_split_convert_extents // path->p_depth == 0 ext4_split_extent // 1. do split1 ext4_split_extent_at |ext4_ext_insert_extent | ext4_ext_create_new_leaf | ext4_ext_grow_indepth | le16_add_cpu(&neh->eh_depth, 1) | ext4_find_extent | // return -ENOMEM |// get error and try zeroout |path = ext4_find_extent | path->p_depth = 1 |ext4_ext_try_to_merge | ext4_ext_try_to_merge_up | path->p_depth = 0 | brelse(path[1].p_bh) ---> not set to NULL here |// zeroout success // 2. update path ext4_find_extent // 3. do split2 ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth le16_add_cpu(&neh->eh_depth, 1) ext4_find_extent path[0].p_bh = NULL; path->p_depth = 1 read_extent_tree_block ---> return err // path[1].p_bh is still the old value ext4_free_ext_path ext4_ext_drop_refs // path->p_depth == 1 brelse(path[1].p_bh) ---> brelse a buffer twice Finally got the following WARRNING when removing the buffer from lru: ============================================ VFS: brelse: Trying to free free buffer WARNING: CPU: 2 PID: 72 at fs/buffer.c:1241 __brelse+0x58/0x90 CPU: 2 PID: 72 Comm: kworker/u19:1 Not tainted 6.9.0-dirty #716 RIP: 0010:__brelse+0x58/0x90 Call Trace: __find_get_block+0x6e7/0x810 bdev_getblk+0x2b/0x480 __ext4_get_inode_loc+0x48a/0x1240 ext4_get_inode_loc+0xb2/0x150 ext4_reserve_inode_write+0xb7/0x230 __ext4_mark_inode_dirty+0x144/0x6a0 ext4_ext_insert_extent+0x9c8/0x3230 ext4_ext_map_blocks+0xf45/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] ============================================", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49883", "url": "https://ubuntu.com/security/CVE-2024-49883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: aovid use-after-free in ext4_ext_insert_extent() As Ojaswin mentioned in Link, in ext4_ext_insert_extent(), if the path is reallocated in ext4_ext_create_new_leaf(), we'll use the stale path and cause UAF. Below is a sample trace with dummy values: ext4_ext_insert_extent path = *ppath = 2000 ext4_ext_create_new_leaf(ppath) ext4_find_extent(ppath) path = *ppath = 2000 if (depth > path[0].p_maxdepth) kfree(path = 2000); *ppath = path = NULL; path = kcalloc() = 3000 *ppath = 3000; return path; /* here path is still 2000, UAF! */ eh = path[depth].p_hdr ================================================================== BUG: KASAN: slab-use-after-free in ext4_ext_insert_extent+0x26d4/0x3330 Read of size 8 at addr ffff8881027bf7d0 by task kworker/u36:1/179 CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 Not tainted 6.11.0-rc2-dirty #866 Call Trace: ext4_ext_insert_extent+0x26d4/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 [...] Allocated by task 179: ext4_find_extent+0x81c/0x1f70 ext4_ext_map_blocks+0x146/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...] Freed by task 179: kfree+0xcb/0x240 ext4_find_extent+0x7c0/0x1f70 ext4_ext_insert_extent+0xa26/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...] ================================================================== So use *ppath to update the path to avoid the above problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49983", "url": "https://ubuntu.com/security/CVE-2024-49983", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-free When calling ext4_force_split_extent_at() in ext4_ext_replay_update_ex(), the 'ppath' is updated but it is the 'path' that is freed, thus potentially triggering a double-free in the following process: ext4_ext_replay_update_ex ppath = path ext4_force_split_extent_at(&ppath) ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path) ---> path First freed *orig_path = path = NULL ---> null ppath kfree(path) ---> path double-free !!! So drop the unnecessary ppath and use path directly to avoid this problem. And use ext4_find_extent() directly to update path, avoiding unnecessary memory allocation and freeing. Also, propagate the error returned by ext4_find_extent() instead of using strange error codes.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50015", "url": "https://ubuntu.com/security/CVE-2024-50015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: dax: fix overflowing extents beyond inode size when partially writing The dax_iomap_rw() does two things in each iteration: map written blocks and copy user data to blocks. If the process is killed by user(See signal handling in dax_iomap_iter()), the copied data will be returned and added on inode size, which means that the length of written extents may exceed the inode size, then fsck will fail. An example is given as: dd if=/dev/urandom of=file bs=4M count=1 dax_iomap_rw iomap_iter // round 1 ext4_iomap_begin ext4_iomap_alloc // allocate 0~2M extents(written flag) dax_iomap_iter // copy 2M data iomap_iter // round 2 iomap_iter_advance iter->pos += iter->processed // iter->pos = 2M ext4_iomap_begin ext4_iomap_alloc // allocate 2~4M extents(written flag) dax_iomap_iter fatal_signal_pending done = iter->pos - iocb->ki_pos // done = 2M ext4_handle_inode_extension ext4_update_inode_size // inode size = 2M fsck reports: Inode 13, i_size is 2097152, should be 4194304. Fix? Fix the problem by truncating extents if the written length is smaller than expected.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49884", "url": "https://ubuntu.com/security/CVE-2024-49884", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix slab-use-after-free in ext4_split_extent_at() We hit the following use-after-free: ================================================================== BUG: KASAN: slab-use-after-free in ext4_split_extent_at+0xba8/0xcc0 Read of size 2 at addr ffff88810548ed08 by task kworker/u20:0/40 CPU: 0 PID: 40 Comm: kworker/u20:0 Not tainted 6.9.0-dirty #724 Call Trace: kasan_report+0x93/0xc0 ext4_split_extent_at+0xba8/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] Allocated by task 40: __kmalloc_noprof+0x1ac/0x480 ext4_find_extent+0xf3b/0x1e70 ext4_ext_map_blocks+0x188/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] Freed by task 40: kfree+0xf1/0x2b0 ext4_find_extent+0xa71/0x1e70 ext4_ext_insert_extent+0xa22/0x3260 ext4_split_extent_at+0x3ef/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] ================================================================== The flow of issue triggering is as follows: ext4_split_extent_at path = *ppath ext4_ext_insert_extent(ppath) ext4_ext_create_new_leaf(ppath) ext4_find_extent(orig_path) path = *orig_path read_extent_tree_block // return -ENOMEM or -EIO ext4_free_ext_path(path) kfree(path) *orig_path = NULL a. If err is -ENOMEM: ext4_ext_dirty(path + path->p_depth) // path use-after-free !!! b. If err is -EIO and we have EXT_DEBUG defined: ext4_ext_show_leaf(path) eh = path[depth].p_hdr // path also use-after-free !!! So when trying to zeroout or fix the extent length, call ext4_find_extent() to update the path. In addition we use *ppath directly as an ext4_ext_show_leaf() input to avoid possible use-after-free when EXT_DEBUG is defined, and to avoid unnecessary path updates.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49885", "url": "https://ubuntu.com/security/CVE-2024-49885", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm, slub: avoid zeroing kmalloc redzone Since commit 946fa0dbf2d8 (\"mm/slub: extend redzone check to extra allocated kmalloc space than requested\"), setting orig_size treats the wasted space (object_size - orig_size) as a redzone. However with init_on_free=1 we clear the full object->size, including the redzone. Additionally we clear the object metadata, including the stored orig_size, making it zero, which makes check_object() treat the whole object as a redzone. These issues lead to the following BUG report with \"slub_debug=FUZ init_on_free=1\": [ 0.000000] ============================================================================= [ 0.000000] BUG kmalloc-8 (Not tainted): kmalloc Redzone overwritten [ 0.000000] ----------------------------------------------------------------------------- [ 0.000000] [ 0.000000] 0xffff000010032858-0xffff00001003285f @offset=2136. First byte 0x0 instead of 0xcc [ 0.000000] FIX kmalloc-8: Restoring kmalloc Redzone 0xffff000010032858-0xffff00001003285f=0xcc [ 0.000000] Slab 0xfffffdffc0400c80 objects=36 used=23 fp=0xffff000010032a18 flags=0x3fffe0000000200(workingset|node=0|zone=0|lastcpupid=0x1ffff) [ 0.000000] Object 0xffff000010032858 @offset=2136 fp=0xffff0000100328c8 [ 0.000000] [ 0.000000] Redzone ffff000010032850: cc cc cc cc cc cc cc cc ........ [ 0.000000] Object ffff000010032858: cc cc cc cc cc cc cc cc ........ [ 0.000000] Redzone ffff000010032860: cc cc cc cc cc cc cc cc ........ [ 0.000000] Padding ffff0000100328b4: 00 00 00 00 00 00 00 00 00 00 00 00 ............ [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.11.0-rc3-next-20240814-00004-g61844c55c3f4 #144 [ 0.000000] Hardware name: NXP i.MX95 19X19 board (DT) [ 0.000000] Call trace: [ 0.000000] dump_backtrace+0x90/0xe8 [ 0.000000] show_stack+0x18/0x24 [ 0.000000] dump_stack_lvl+0x74/0x8c [ 0.000000] dump_stack+0x18/0x24 [ 0.000000] print_trailer+0x150/0x218 [ 0.000000] check_object+0xe4/0x454 [ 0.000000] free_to_partial_list+0x2f8/0x5ec To address the issue, use orig_size to clear the used area. And restore the value of orig_size after clear the remaining area. When CONFIG_SLUB_DEBUG not defined, (get_orig_size()' directly returns s->object_size. So when using memset to init the area, the size can simply be orig_size, as orig_size returns object_size when CONFIG_SLUB_DEBUG not enabled. And orig_size can never be bigger than object_size.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49961", "url": "https://ubuntu.com/security/CVE-2024-49961", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: ar0521: Use cansleep version of gpiod_set_value() If we use GPIO reset from I2C port expander, we must use *_cansleep() variant of GPIO functions. This was not done in ar0521_power_on()/ar0521_power_off() functions. Let's fix that. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 11 at drivers/gpio/gpiolib.c:3496 gpiod_set_value+0x74/0x7c Modules linked in: CPU: 0 PID: 11 Comm: kworker/u16:0 Not tainted 6.10.0 #53 Hardware name: Diasom DS-RK3568-SOM-EVB (DT) Workqueue: events_unbound deferred_probe_work_func pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : gpiod_set_value+0x74/0x7c lr : ar0521_power_on+0xcc/0x290 sp : ffffff8001d7ab70 x29: ffffff8001d7ab70 x28: ffffff80027dcc90 x27: ffffff8003c82000 x26: ffffff8003ca9250 x25: ffffffc080a39c60 x24: ffffff8003ca9088 x23: ffffff8002402720 x22: ffffff8003ca9080 x21: ffffff8003ca9088 x20: 0000000000000000 x19: ffffff8001eb2a00 x18: ffffff80efeeac80 x17: 756d2d6332692f30 x16: 0000000000000000 x15: 0000000000000000 x14: ffffff8001d91d40 x13: 0000000000000016 x12: ffffffc080e98930 x11: ffffff8001eb2880 x10: 0000000000000890 x9 : ffffff8001d7a9f0 x8 : ffffff8001d92570 x7 : ffffff80efeeac80 x6 : 000000003fc6e780 x5 : ffffff8001d91c80 x4 : 0000000000000002 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000001 Call trace: gpiod_set_value+0x74/0x7c ar0521_power_on+0xcc/0x290 ...", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49985", "url": "https://ubuntu.com/security/CVE-2024-49985", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume In case there is any sort of clock controller attached to this I2C bus controller, for example Versaclock or even an AIC32x4 I2C codec, then an I2C transfer triggered from the clock controller clk_ops .prepare callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex. This is because the clock controller first grabs the prepare_lock mutex and then performs the prepare operation, including its I2C access. The I2C access resumes this I2C bus controller via .runtime_resume callback, which calls clk_prepare_enable(), which attempts to grab the prepare_lock mutex again and deadlocks. Since the clock are already prepared since probe() and unprepared in remove(), use simple clk_enable()/clk_disable() calls to enable and disable the clock on runtime suspend and resume, to avoid hitting the prepare_lock mutex.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49886", "url": "https://ubuntu.com/security/CVE-2024-49886", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bug Attaching SST PCI device to VM causes \"BUG: KASAN: slab-out-of-bounds\". kasan report: [ 19.411889] ================================================================== [ 19.413702] BUG: KASAN: slab-out-of-bounds in _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.415634] Read of size 8 at addr ffff888829e65200 by task cpuhp/16/113 [ 19.417368] [ 19.418627] CPU: 16 PID: 113 Comm: cpuhp/16 Tainted: G E 6.9.0 #10 [ 19.420435] Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.20192059.B64.2207280713 07/28/2022 [ 19.422687] Call Trace: [ 19.424091] [ 19.425448] dump_stack_lvl+0x5d/0x80 [ 19.426963] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.428694] print_report+0x19d/0x52e [ 19.430206] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 19.431837] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.433539] kasan_report+0xf0/0x170 [ 19.435019] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.436709] _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.438379] ? __pfx_sched_clock_cpu+0x10/0x10 [ 19.439910] isst_if_cpu_online+0x406/0x58f [isst_if_common] [ 19.441573] ? __pfx_isst_if_cpu_online+0x10/0x10 [isst_if_common] [ 19.443263] ? ttwu_queue_wakelist+0x2c1/0x360 [ 19.444797] cpuhp_invoke_callback+0x221/0xec0 [ 19.446337] cpuhp_thread_fun+0x21b/0x610 [ 19.447814] ? __pfx_cpuhp_thread_fun+0x10/0x10 [ 19.449354] smpboot_thread_fn+0x2e7/0x6e0 [ 19.450859] ? __pfx_smpboot_thread_fn+0x10/0x10 [ 19.452405] kthread+0x29c/0x350 [ 19.453817] ? __pfx_kthread+0x10/0x10 [ 19.455253] ret_from_fork+0x31/0x70 [ 19.456685] ? __pfx_kthread+0x10/0x10 [ 19.458114] ret_from_fork_asm+0x1a/0x30 [ 19.459573] [ 19.460853] [ 19.462055] Allocated by task 1198: [ 19.463410] kasan_save_stack+0x30/0x50 [ 19.464788] kasan_save_track+0x14/0x30 [ 19.466139] __kasan_kmalloc+0xaa/0xb0 [ 19.467465] __kmalloc+0x1cd/0x470 [ 19.468748] isst_if_cdev_register+0x1da/0x350 [isst_if_common] [ 19.470233] isst_if_mbox_init+0x108/0xff0 [isst_if_mbox_msr] [ 19.471670] do_one_initcall+0xa4/0x380 [ 19.472903] do_init_module+0x238/0x760 [ 19.474105] load_module+0x5239/0x6f00 [ 19.475285] init_module_from_file+0xd1/0x130 [ 19.476506] idempotent_init_module+0x23b/0x650 [ 19.477725] __x64_sys_finit_module+0xbe/0x130 [ 19.476506] idempotent_init_module+0x23b/0x650 [ 19.477725] __x64_sys_finit_module+0xbe/0x130 [ 19.478920] do_syscall_64+0x82/0x160 [ 19.480036] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 19.481292] [ 19.482205] The buggy address belongs to the object at ffff888829e65000 which belongs to the cache kmalloc-512 of size 512 [ 19.484818] The buggy address is located 0 bytes to the right of allocated 512-byte region [ffff888829e65000, ffff888829e65200) [ 19.487447] [ 19.488328] The buggy address belongs to the physical page: [ 19.489569] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888829e60c00 pfn:0x829e60 [ 19.491140] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [ 19.492466] anon flags: 0x57ffffc0000840(slab|head|node=1|zone=2|lastcpupid=0x1fffff) [ 19.493914] page_type: 0xffffffff() [ 19.494988] raw: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [ 19.496451] raw: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [ 19.497906] head: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [ 19.499379] head: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [ 19.500844] head: 0057ffffc0000003 ffffea0020a79801 ffffea0020a79848 00000000ffffffff [ 19.502316] head: 0000000800000000 0000000000000000 00000000ffffffff 0000000000000000 [ 19.503784] page dumped because: k ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49986", "url": "https://ubuntu.com/security/CVE-2024-49986", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: x86-android-tablets: Fix use after free on platform_device_register() errors x86_android_tablet_remove() frees the pdevs[] array, so it should not be used after calling x86_android_tablet_remove(). When platform_device_register() fails, store the pdevs[x] PTR_ERR() value into the local ret variable before calling x86_android_tablet_remove() to avoid using pdevs[] after it has been freed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49887", "url": "https://ubuntu.com/security/CVE-2024-49887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to don't panic system for no free segment fault injection f2fs: fix to don't panic system for no free segment fault injection syzbot reports a f2fs bug as below: F2FS-fs (loop0): inject no free segment in get_new_segment of __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3167 F2FS-fs (loop0): Stopped filesystem due to reason: 7 ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2748! CPU: 0 UID: 0 PID: 5109 Comm: syz-executor304 Not tainted 6.11.0-rc6-syzkaller-00363-g89f5e14d05b4 #0 RIP: 0010:get_new_segment fs/f2fs/segment.c:2748 [inline] RIP: 0010:new_curseg+0x1f61/0x1f70 fs/f2fs/segment.c:2836 Call Trace: __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3167 f2fs_allocate_new_section fs/f2fs/segment.c:3181 [inline] f2fs_allocate_pinning_section+0xfa/0x4e0 fs/f2fs/segment.c:3195 f2fs_expand_inode_data+0x5d6/0xbb0 fs/f2fs/file.c:1799 f2fs_fallocate+0x448/0x960 fs/f2fs/file.c:1903 vfs_fallocate+0x553/0x6c0 fs/open.c:334 do_vfs_ioctl+0x2592/0x2e50 fs/ioctl.c:886 __do_sys_ioctl fs/ioctl.c:905 [inline] __se_sys_ioctl+0x81/0x170 fs/ioctl.c:893 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: 0010:get_new_segment fs/f2fs/segment.c:2748 [inline] RIP: 0010:new_curseg+0x1f61/0x1f70 fs/f2fs/segment.c:2836 The root cause is when we inject no free segment fault into f2fs, we should not panic system, fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49888", "url": "https://ubuntu.com/security/CVE-2024-49888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix a sdiv overflow issue Zac Ecob reported a problem where a bpf program may cause kernel crash due to the following error: Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI The failure is due to the below signed divide: LLONG_MIN/-1 where LLONG_MIN equals to -9,223,372,036,854,775,808. LLONG_MIN/-1 is supposed to give a positive number 9,223,372,036,854,775,808, but it is impossible since for 64-bit system, the maximum positive number is 9,223,372,036,854,775,807. On x86_64, LLONG_MIN/-1 will cause a kernel exception. On arm64, the result for LLONG_MIN/-1 is LLONG_MIN. Further investigation found all the following sdiv/smod cases may trigger an exception when bpf program is running on x86_64 platform: - LLONG_MIN/-1 for 64bit operation - INT_MIN/-1 for 32bit operation - LLONG_MIN%-1 for 64bit operation - INT_MIN%-1 for 32bit operation where -1 can be an immediate or in a register. On arm64, there are no exceptions: - LLONG_MIN/-1 = LLONG_MIN - INT_MIN/-1 = INT_MIN - LLONG_MIN%-1 = 0 - INT_MIN%-1 = 0 where -1 can be an immediate or in a register. Insn patching is needed to handle the above cases and the patched codes produced results aligned with above arm64 result. The below are pseudo codes to handle sdiv/smod exceptions including both divisor -1 and divisor 0 and the divisor is stored in a register. sdiv: tmp = rX tmp += 1 /* [-1, 0] -> [0, 1] if tmp >(unsigned) 1 goto L2 if tmp == 0 goto L1 rY = 0 L1: rY = -rY; goto L3 L2: rY /= rX L3: smod: tmp = rX tmp += 1 /* [-1, 0] -> [0, 1] if tmp >(unsigned) 1 goto L1 if tmp == 1 (is64 ? goto L2 : goto L3) rY = 0; goto L2 L1: rY %= rX L2: goto L4 // only when !is64 L3: wY = wY // only when !is64 L4: [1] https://lore.kernel.org/bpf/tPJLTEh7S_DxFEqAI2Ji5MBSoZVg7_G-Py2iaZpAaWtM961fFTWtsnlzwvTbzBzaUzwQAoNATXKUlt0LZOFgnDcIyKCswAnAGdUF3LBrhGQ=@protonmail.com/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49987", "url": "https://ubuntu.com/security/CVE-2024-49987", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpftool: Fix undefined behavior in qsort(NULL, 0, ...) When netfilter has no entry to display, qsort is called with qsort(NULL, 0, ...). This results in undefined behavior, as UBSan reports: net.c:827:2: runtime error: null pointer passed as argument 1, which is declared to never be null Although the C standard does not explicitly state whether calling qsort with a NULL pointer when the size is 0 constitutes undefined behavior, Section 7.1.4 of the C standard (Use of library functions) mentions: \"Each of the following statements applies unless explicitly stated otherwise in the detailed descriptions that follow: If an argument to a function has an invalid value (such as a value outside the domain of the function, or a pointer outside the address space of the program, or a null pointer, or a pointer to non-modifiable storage when the corresponding parameter is not const-qualified) or a type (after promotion) not expected by a function with variable number of arguments, the behavior is undefined.\" To avoid this, add an early return when nf_link_info is NULL to prevent calling qsort with a NULL pointer.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50006", "url": "https://ubuntu.com/security/CVE-2024-50006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix i_data_sem unlock order in ext4_ind_migrate() Fuzzing reports a possible deadlock in jbd2_log_wait_commit. This issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to require synchronous updates because the file descriptor is opened with O_SYNC. This can lead to the jbd2_journal_stop() function calling jbd2_might_wait_for_commit(), potentially causing a deadlock if the EXT4_IOC_MIGRATE call races with a write(2) system call. This problem only arises when CONFIG_PROVE_LOCKING is enabled. In this case, the jbd2_might_wait_for_commit macro locks jbd2_handle in the jbd2_journal_stop function while i_data_sem is locked. This triggers lockdep because the jbd2_journal_start function might also lock the same jbd2_handle simultaneously. Found by Linux Verification Center (linuxtesting.org) with syzkaller. Rule: add", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49889", "url": "https://ubuntu.com/security/CVE-2024-49889", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid use-after-free in ext4_ext_show_leaf() In ext4_find_extent(), path may be freed by error or be reallocated, so using a previously saved *ppath may have been freed and thus may trigger use-after-free, as follows: ext4_split_extent path = *ppath; ext4_split_extent_at(ppath) path = ext4_find_extent(ppath) ext4_split_extent_at(ppath) // ext4_find_extent fails to free path // but zeroout succeeds ext4_ext_show_leaf(inode, path) eh = path[depth].p_hdr // path use-after-free !!! Similar to ext4_split_extent_at(), we use *ppath directly as an input to ext4_ext_show_leaf(). Fix a spelling error by the way. Same problem in ext4_ext_handle_unwritten_extents(). Since 'path' is only used in ext4_ext_show_leaf(), remove 'path' and use *ppath directly. This issue is triggered only when EXT_DEBUG is defined and therefore does not affect functionality.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49968", "url": "https://ubuntu.com/security/CVE-2024-49968", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: filesystems without casefold feature cannot be mounted with siphash When mounting the ext4 filesystem, if the default hash version is set to DX_HASH_SIPHASH but the casefold feature is not set, exit the mounting.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49988", "url": "https://ubuntu.com/security/CVE-2024-49988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: add refcnt to ksmbd_conn struct When sending an oplock break request, opinfo->conn is used, But freed ->conn can be used on multichannel. This patch add a reference count to the ksmbd_conn struct so that it can be freed when it is no longer used.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49890", "url": "https://ubuntu.com/security/CVE-2024-49890", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: ensure the fw_info is not null before using it This resolves the dereference null return value warning reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49891", "url": "https://ubuntu.com/security/CVE-2024-49891", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata paths When the HBA is undergoing a reset or is handling an errata event, NULL ptr dereference crashes may occur in routines such as lpfc_sli_flush_io_rings(), lpfc_dev_loss_tmo_callbk(), or lpfc_abort_handler(). Add NULL ptr checks before dereferencing hdwq pointers that may have been freed due to operations colliding with a reset or errata event handler.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49892", "url": "https://ubuntu.com/security/CVE-2024-49892", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize get_bytes_per_element's default to 1 Variables, used as denominators and maybe not assigned to other values, should not be 0. bytes_per_element_y & bytes_per_element_c are initialized by get_bytes_per_element() which should never return 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50016", "url": "https://ubuntu.com/security/CVE-2024-50016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Avoid overflow assignment in link_dp_cts sampling_rate is an uint8_t but is assigned an unsigned int, and thus it can overflow. As a result, sampling_rate is changed to uint32_t. Similarly, LINK_QUAL_PATTERN_SET has a size of 2 bits, and it should only be assigned to a value less or equal than 4. This fixes 2 INTEGER_OVERFLOW issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49893", "url": "https://ubuntu.com/security/CVE-2024-49893", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check stream_status before it is used [WHAT & HOW] dc_state_get_stream_status can return null, and therefore null must be checked before stream_status is used. This fixes 1 NULL_RETURNS issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49969", "url": "https://ubuntu.com/security/CVE-2024-49969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 color transformation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_hw_format` function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:180 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:181 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:182 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49970", "url": "https://ubuntu.com/security/CVE-2024-49970", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Implement bounds check for stream encoder creation in DCN401 'stream_enc_regs' array is an array of dcn10_stream_enc_registers structures. The array is initialized with four elements, corresponding to the four calls to stream_enc_regs() in the array initializer. This means that valid indices for this array are 0, 1, 2, and 3. The error message 'stream_enc_regs' 4 <= 5 below, is indicating that there is an attempt to access this array with an index of 5, which is out of bounds. This could lead to undefined behavior Here, eng_id is used as an index to access the stream_enc_regs array. If eng_id is 5, this would result in an out-of-bounds access on the stream_enc_regs array. Thus fixing Buffer overflow error in dcn401_stream_encoder_create Found by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn401/dcn401_resource.c:1209 dcn401_stream_encoder_create() error: buffer overflow 'stream_enc_regs' 4 <= 5", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49894", "url": "https://ubuntu.com/security/CVE-2024-49894", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in degamma hardware format translation Fixes index out of bounds issue in `cm_helper_translate_curve_to_degamma_hw_format` function. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49895", "url": "https://ubuntu.com/security/CVE-2024-49895", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format translation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_degamma_hw_format` function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:338 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:339 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:340 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49971", "url": "https://ubuntu.com/security/CVE-2024-49971", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Increase array size of dummy_boolean [WHY] dml2_core_shared_mode_support and dml_core_mode_support access the third element of dummy_boolean, i.e. hw_debug5 = &s->dummy_boolean[2], when dummy_boolean has size of 2. Any assignment to hw_debug5 causes an OVERRUN. [HOW] Increase dummy_boolean's array size to 3. This fixes 2 OVERRUN issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49972", "url": "https://ubuntu.com/security/CVE-2024-49972", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Deallocate DML memory if allocation fails [Why] When DC state create DML memory allocation fails, memory is not deallocated subsequently, resulting in uninitialized structure that is not NULL. [How] Deallocate memory if DML memory allocation fails.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49896", "url": "https://ubuntu.com/security/CVE-2024-49896", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check stream before comparing them [WHAT & HOW] amdgpu_dm can pass a null stream to dc_is_stream_unchanged. It is necessary to check for null before dereferencing them. This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49897", "url": "https://ubuntu.com/security/CVE-2024-49897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check phantom_stream before it is used dcn32_enable_phantom_stream can return null, so returned value must be checked before used. This fixes 1 NULL_RETURNS issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49898", "url": "https://ubuntu.com/security/CVE-2024-49898", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null-initialized variables [WHAT & HOW] drr_timing and subvp_pipe are initialized to null and they are not always assigned new values. It is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49899", "url": "https://ubuntu.com/security/CVE-2024-49899", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize denominators' default to 1 [WHAT & HOW] Variables used as denominators and maybe not assigned to other values, should not be 0. Change their default to 1 so they are never 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49900", "url": "https://ubuntu.com/security/CVE-2024-49900", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uninit-value access of new_ea in ea_buffer syzbot reports that lzo1x_1_do_compress is using uninit-value: ===================================================== BUG: KMSAN: uninit-value in lzo1x_1_do_compress+0x19f9/0x2510 lib/lzo/lzo1x_compress.c:178 ... Uninit was stored to memory at: ea_put fs/jfs/xattr.c:639 [inline] ... Local variable ea_buf created at: __jfs_setxattr+0x5d/0x1ae0 fs/jfs/xattr.c:662 __jfs_xattr_set+0xe6/0x1f0 fs/jfs/xattr.c:934 ===================================================== The reason is ea_buf->new_ea is not initialized properly. Fix this by using memset to empty its content at the beginning in ea_get().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49901", "url": "https://ubuntu.com/security/CVE-2024-49901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm/adreno: Assign msm_gpu->pdev earlier to avoid nullptrs There are some cases, such as the one uncovered by Commit 46d4efcccc68 (\"drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails\") where msm_gpu_cleanup() : platform_set_drvdata(gpu->pdev, NULL); is called on gpu->pdev == NULL, as the GPU device has not been fully initialized yet. Turns out that there's more than just the aforementioned path that causes this to happen (e.g. the case when there's speedbin data in the catalog, but opp-supported-hw is missing in DT). Assigning msm_gpu->pdev earlier seems like the least painful solution to this, therefore do so. Patchwork: https://patchwork.freedesktop.org/patch/602742/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49902", "url": "https://ubuntu.com/security/CVE-2024-49902", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: check if leafidx greater than num leaves per dmap tree syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf. Shaggy: Modified sanity check to apply to control pages as well as leaf pages.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49903", "url": "https://ubuntu.com/security/CVE-2024-49903", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uaf in dbFreeBits [syzbot reported] ================================================================== BUG: KASAN: slab-use-after-free in __mutex_lock_common kernel/locking/mutex.c:587 [inline] BUG: KASAN: slab-use-after-free in __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 Read of size 8 at addr ffff8880229254b0 by task syz-executor357/5216 CPU: 0 UID: 0 PID: 5216 Comm: syz-executor357 Not tainted 6.11.0-rc3-syzkaller-00156-gd7a5aa4b3c00 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 __mutex_lock_common kernel/locking/mutex.c:587 [inline] __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 dbFreeBits+0x7ea/0xd90 fs/jfs/jfs_dmap.c:2390 dbFreeDmap fs/jfs/jfs_dmap.c:2089 [inline] dbFree+0x35b/0x680 fs/jfs/jfs_dmap.c:409 dbDiscardAG+0x8a9/0xa20 fs/jfs/jfs_dmap.c:1650 jfs_ioc_trim+0x433/0x670 fs/jfs/jfs_discard.c:100 jfs_ioctl+0x2d0/0x3e0 fs/jfs/ioctl.c:131 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 Freed by task 5218: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object+0xe0/0x150 mm/kasan/common.c:240 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2252 [inline] slab_free mm/slub.c:4473 [inline] kfree+0x149/0x360 mm/slub.c:4594 dbUnmount+0x11d/0x190 fs/jfs/jfs_dmap.c:278 jfs_mount_rw+0x4ac/0x6a0 fs/jfs/jfs_mount.c:247 jfs_remount+0x3d1/0x6b0 fs/jfs/super.c:454 reconfigure_super+0x445/0x880 fs/super.c:1083 vfs_cmd_reconfigure fs/fsopen.c:263 [inline] vfs_fsconfig_locked fs/fsopen.c:292 [inline] __do_sys_fsconfig fs/fsopen.c:473 [inline] __se_sys_fsconfig+0xb6e/0xf80 fs/fsopen.c:345 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 [Analysis] There are two paths (dbUnmount and jfs_ioc_trim) that generate race condition when accessing bmap, which leads to the occurrence of uaf. Use the lock s_umount to synchronize them, in order to avoid uaf caused by race condition.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49904", "url": "https://ubuntu.com/security/CVE-2024-49904", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add list empty check to avoid null pointer issue Add list empty check to avoid null pointer issues in some corner cases. - list_for_each_entry_safe()", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49989", "url": "https://ubuntu.com/security/CVE-2024-49989", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix double free issue during amdgpu module unload Flexible endpoints use DIGs from available inflexible endpoints, so only the encoders of inflexible links need to be freed. Otherwise, a double free issue may occur when unloading the amdgpu module. [ 279.190523] RIP: 0010:__slab_free+0x152/0x2f0 [ 279.190577] Call Trace: [ 279.190580] [ 279.190582] ? show_regs+0x69/0x80 [ 279.190590] ? die+0x3b/0x90 [ 279.190595] ? do_trap+0xc8/0xe0 [ 279.190601] ? do_error_trap+0x73/0xa0 [ 279.190605] ? __slab_free+0x152/0x2f0 [ 279.190609] ? exc_invalid_op+0x56/0x70 [ 279.190616] ? __slab_free+0x152/0x2f0 [ 279.190642] ? asm_exc_invalid_op+0x1f/0x30 [ 279.190648] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191096] ? __slab_free+0x152/0x2f0 [ 279.191102] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191469] kfree+0x260/0x2b0 [ 279.191474] dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191821] link_destroy+0xd7/0x130 [amdgpu] [ 279.192248] dc_destruct+0x90/0x270 [amdgpu] [ 279.192666] dc_destroy+0x19/0x40 [amdgpu] [ 279.193020] amdgpu_dm_fini+0x16e/0x200 [amdgpu] [ 279.193432] dm_hw_fini+0x26/0x40 [amdgpu] [ 279.193795] amdgpu_device_fini_hw+0x24c/0x400 [amdgpu] [ 279.194108] amdgpu_driver_unload_kms+0x4f/0x70 [amdgpu] [ 279.194436] amdgpu_pci_remove+0x40/0x80 [amdgpu] [ 279.194632] pci_device_remove+0x3a/0xa0 [ 279.194638] device_remove+0x40/0x70 [ 279.194642] device_release_driver_internal+0x1ad/0x210 [ 279.194647] driver_detach+0x4e/0xa0 [ 279.194650] bus_remove_driver+0x6f/0xf0 [ 279.194653] driver_unregister+0x33/0x60 [ 279.194657] pci_unregister_driver+0x44/0x90 [ 279.194662] amdgpu_exit+0x19/0x1f0 [amdgpu] [ 279.194939] __do_sys_delete_module.isra.0+0x198/0x2f0 [ 279.194946] __x64_sys_delete_module+0x16/0x20 [ 279.194950] do_syscall_64+0x58/0x120 [ 279.194954] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 279.194980] ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49905", "url": "https://ubuntu.com/security/CVE-2024-49905", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for 'afb' in amdgpu_dm_plane_handle_cursor_update (v2) This commit adds a null check for the 'afb' variable in the amdgpu_dm_plane_handle_cursor_update function. Previously, 'afb' was assumed to be null, but was used later in the code without a null check. This could potentially lead to a null pointer dereference. Changes since v1: - Moved the null check for 'afb' to the line where 'afb' is used. (Alex) Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:1298 amdgpu_dm_plane_handle_cursor_update() error: we previously assumed 'afb' could be null (see line 1252)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49906", "url": "https://ubuntu.com/security/CVE-2024-49906", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before try to access it [why & how] Change the order of the pipe_ctx->plane_state check to ensure that plane_state is not null before accessing it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49907", "url": "https://ubuntu.com/security/CVE-2024-49907", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before using dc->clk_mgr [WHY & HOW] dc->clk_mgr is null checked previously in the same function, indicating it might be null. Passing \"dc\" to \"dc->hwss.apply_idle_power_optimizations\", which dereferences null \"dc->clk_mgr\". (The function pointer resolves to \"dcn35_apply_idle_power_optimizations\".) This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49908", "url": "https://ubuntu.com/security/CVE-2024-49908", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for 'afb' in amdgpu_dm_update_cursor (v2) This commit adds a null check for the 'afb' variable in the amdgpu_dm_update_cursor function. Previously, 'afb' was assumed to be null at line 8388, but was used later in the code without a null check. This could potentially lead to a null pointer dereference. Changes since v1: - Moved the null check for 'afb' to the line where 'afb' is used. (Alex) Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:8433 amdgpu_dm_update_cursor() \terror: we previously assumed 'afb' could be null (see line 8388)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50177", "url": "https://ubuntu.com/security/CVE-2024-50177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix a UBSAN warning in DML2.1 When programming phantom pipe, since cursor_width is explicity set to 0, this causes calculation logic to trigger overflow for an unsigned int triggering the kernel's UBSAN check as below: [ 40.962845] UBSAN: shift-out-of-bounds in /tmp/amd.EfpumTkO/amd/amdgpu/../display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c:3312:34 [ 40.962849] shift exponent 4294967170 is too large for 32-bit type 'unsigned int' [ 40.962852] CPU: 1 PID: 1670 Comm: gnome-shell Tainted: G W OE 6.5.0-41-generic #41~22.04.2-Ubuntu [ 40.962854] Hardware name: Gigabyte Technology Co., Ltd. X670E AORUS PRO X/X670E AORUS PRO X, BIOS F21 01/10/2024 [ 40.962856] Call Trace: [ 40.962857] [ 40.962860] dump_stack_lvl+0x48/0x70 [ 40.962870] dump_stack+0x10/0x20 [ 40.962872] __ubsan_handle_shift_out_of_bounds+0x1ac/0x360 [ 40.962878] calculate_cursor_req_attributes.cold+0x1b/0x28 [amdgpu] [ 40.963099] dml_core_mode_support+0x6b91/0x16bc0 [amdgpu] [ 40.963327] ? srso_alias_return_thunk+0x5/0x7f [ 40.963331] ? CalculateWatermarksMALLUseAndDRAMSpeedChangeSupport+0x18b8/0x2790 [amdgpu] [ 40.963534] ? srso_alias_return_thunk+0x5/0x7f [ 40.963536] ? dml_core_mode_support+0xb3db/0x16bc0 [amdgpu] [ 40.963730] dml2_core_calcs_mode_support_ex+0x2c/0x90 [amdgpu] [ 40.963906] ? srso_alias_return_thunk+0x5/0x7f [ 40.963909] ? dml2_core_calcs_mode_support_ex+0x2c/0x90 [amdgpu] [ 40.964078] core_dcn4_mode_support+0x72/0xbf0 [amdgpu] [ 40.964247] dml2_top_optimization_perform_optimization_phase+0x1d3/0x2a0 [amdgpu] [ 40.964420] dml2_build_mode_programming+0x23d/0x750 [amdgpu] [ 40.964587] dml21_validate+0x274/0x770 [amdgpu] [ 40.964761] ? srso_alias_return_thunk+0x5/0x7f [ 40.964763] ? resource_append_dpp_pipes_for_plane_composition+0x27c/0x3b0 [amdgpu] [ 40.964942] dml2_validate+0x504/0x750 [amdgpu] [ 40.965117] ? dml21_copy+0x95/0xb0 [amdgpu] [ 40.965291] ? srso_alias_return_thunk+0x5/0x7f [ 40.965295] dcn401_validate_bandwidth+0x4e/0x70 [amdgpu] [ 40.965491] update_planes_and_stream_state+0x38d/0x5c0 [amdgpu] [ 40.965672] update_planes_and_stream_v3+0x52/0x1e0 [amdgpu] [ 40.965845] ? srso_alias_return_thunk+0x5/0x7f [ 40.965849] dc_update_planes_and_stream+0x71/0xb0 [amdgpu] Fix this by adding a guard for checking cursor width before triggering the size calculation.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49909", "url": "https://ubuntu.com/security/CVE-2024-49909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn32_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn32_set_output_transfer_func function. Previously, set_output_gamma was being checked for null, but then it was being dereferenced without any null check. This could lead to a null pointer dereference if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49910", "url": "https://ubuntu.com/security/CVE-2024-49910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn401_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn401_set_output_transfer_func function. Previously, set_output_gamma was being checked for null, but then it was being dereferenced without any null check. This could lead to a null pointer dereference if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49911", "url": "https://ubuntu.com/security/CVE-2024-49911", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn20_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn20_set_output_transfer_func function. Previously, set_output_gamma was being checked for null at line 1030, but then it was being dereferenced without any null check at line 1048. This could potentially lead to a null pointer dereference error if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma at line 1048.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49912", "url": "https://ubuntu.com/security/CVE-2024-49912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Handle null 'stream_status' in 'planes_changed_for_existing_stream' This commit adds a null check for 'stream_status' in the function 'planes_changed_for_existing_stream'. Previously, the code assumed 'stream_status' could be null, but did not handle the case where it was actually null. This could lead to a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:3784 planes_changed_for_existing_stream() error: we previously assumed 'stream_status' could be null (see line 3774)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49913", "url": "https://ubuntu.com/security/CVE-2024-49913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for top_pipe_to_program in commit_planes_for_stream This commit addresses a null pointer dereference issue in the `commit_planes_for_stream` function at line 4140. The issue could occur when `top_pipe_to_program` is null. The fix adds a check to ensure `top_pipe_to_program` is not null before accessing its stream_res. This prevents a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:4140 commit_planes_for_stream() error: we previously assumed 'top_pipe_to_program' could be null (see line 3906)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49914", "url": "https://ubuntu.com/security/CVE-2024-49914", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for pipe_ctx->plane_state in dcn20_program_pipe This commit addresses a null pointer dereference issue in the `dcn20_program_pipe` function. The issue could occur when `pipe_ctx->plane_state` is null. The fix adds a check to ensure `pipe_ctx->plane_state` is not null before accessing. This prevents a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn20/dcn20_hwseq.c:1925 dcn20_program_pipe() error: we previously assumed 'pipe_ctx->plane_state' could be null (see line 1877)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49915", "url": "https://ubuntu.com/security/CVE-2024-49915", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr in dcn32_init_hw This commit addresses a potential null pointer dereference issue in the `dcn32_init_hw` function. The issue could occur when `dc->clk_mgr` is null. The fix adds a check to ensure `dc->clk_mgr` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn32/dcn32_hwseq.c:961 dcn32_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 782)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49916", "url": "https://ubuntu.com/security/CVE-2024-49916", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in dcn401_init_hw This commit addresses a potential null pointer dereference issue in the `dcn401_init_hw` function. The issue could occur when `dc->clk_mgr` or `dc->clk_mgr->funcs` is null. The fix adds a check to ensure `dc->clk_mgr` and `dc->clk_mgr->funcs` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn401/dcn401_hwseq.c:416 dcn401_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 225)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49917", "url": "https://ubuntu.com/security/CVE-2024-49917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in dcn30_init_hw This commit addresses a potential null pointer dereference issue in the `dcn30_init_hw` function. The issue could occur when `dc->clk_mgr` or `dc->clk_mgr->funcs` is null. The fix adds a check to ensure `dc->clk_mgr` and `dc->clk_mgr->funcs` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:789 dcn30_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 628)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49918", "url": "https://ubuntu.com/security/CVE-2024-49918", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for head_pipe in dcn32_acquire_idle_pipe_for_head_pipe_in_layer This commit addresses a potential null pointer dereference issue in the `dcn32_acquire_idle_pipe_for_head_pipe_in_layer` function. The issue could occur when `head_pipe` is null. The fix adds a check to ensure `head_pipe` is not null before asserting it. If `head_pipe` is null, the function returns NULL to prevent a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn32/dcn32_resource.c:2690 dcn32_acquire_idle_pipe_for_head_pipe_in_layer() error: we previously assumed 'head_pipe' could be null (see line 2681)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49919", "url": "https://ubuntu.com/security/CVE-2024-49919", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for head_pipe in dcn201_acquire_free_pipe_for_layer This commit addresses a potential null pointer dereference issue in the `dcn201_acquire_free_pipe_for_layer` function. The issue could occur when `head_pipe` is null. The fix adds a check to ensure `head_pipe` is not null before asserting it. If `head_pipe` is null, the function returns NULL to prevent a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn201/dcn201_resource.c:1016 dcn201_acquire_free_pipe_for_layer() error: we previously assumed 'head_pipe' could be null (see line 1010)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49991", "url": "https://ubuntu.com/security/CVE-2024-49991", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer Pass pointer reference to amdgpu_bo_unref to clear the correct pointer, otherwise amdgpu_bo_unref clear the local variable, the original pointer not set to NULL, this could cause use-after-free bug.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49920", "url": "https://ubuntu.com/security/CVE-2024-49920", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before multiple uses [WHAT & HOW] Poniters, such as stream_enc and dc->bw_vbios, are null checked previously in the same function, so Coverity warns \"implies that stream_enc and dc->bw_vbios might be null\". They are used multiple times in the subsequent code and need to be checked. This fixes 10 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49921", "url": "https://ubuntu.com/security/CVE-2024-49921", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before used [WHAT & HOW] Poniters, such as dc->clk_mgr, are null checked previously in the same function, so Coverity warns \"implies that \"dc->clk_mgr\" might be null\". As a result, these pointers need to be checked when used again. This fixes 10 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49922", "url": "https://ubuntu.com/security/CVE-2024-49922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before using them [WHAT & HOW] These pointers are null checked previously in the same function, indicating they might be null as reported by Coverity. As a result, they need to be checked when used again. This fixes 3 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49923", "url": "https://ubuntu.com/security/CVE-2024-49923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Pass non-null to dcn20_validate_apply_pipe_split_flags [WHAT & HOW] \"dcn20_validate_apply_pipe_split_flags\" dereferences merge, and thus it cannot be a null pointer. Let's pass a valid pointer to avoid null dereference. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49992", "url": "https://ubuntu.com/security/CVE-2024-49992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/stm: Avoid use-after-free issues with crtc and plane ltdc_load() calls functions drm_crtc_init_with_planes(), drm_universal_plane_init() and drm_encoder_init(). These functions should not be called with parameters allocated with devm_kzalloc() to avoid use-after-free issues [1]. Use allocations managed by the DRM framework. Found by Linux Verification Center (linuxtesting.org). [1] https://lore.kernel.org/lkml/u366i76e3qhh3ra5oxrtngjtm2u5lterkekcz6y2jkndhuxzli@diujon4h7qwb/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49993", "url": "https://ubuntu.com/security/CVE-2024-49993", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49924", "url": "https://ubuntu.com/security/CVE-2024-49924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: pxafb: Fix possible use after free in pxafb_task() In the pxafb_probe function, it calls the pxafb_init_fbinfo function, after which &fbi->task is associated with pxafb_task. Moreover, within this pxafb_init_fbinfo function, the pxafb_blank function within the &pxafb_ops struct is capable of scheduling work. If we remove the module which will call pxafb_remove to make cleanup, it will call unregister_framebuffer function which can call do_unregister_framebuffer to free fbi->fb through put_fb_info(fb_info), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | pxafb_task pxafb_remove | unregister_framebuffer(info) | do_unregister_framebuffer(fb_info) | put_fb_info(fb_info) | // free fbi->fb | set_ctrlr_state(fbi, state) | __pxafb_lcd_power(fbi, 0) | fbi->lcd_power(on, &fbi->fb.var) | //use fbi->fb Fix it by ensuring that the work is canceled before proceeding with the cleanup in pxafb_remove. Note that only root user can remove the driver at runtime.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49925", "url": "https://ubuntu.com/security/CVE-2024-49925", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: efifb: Register sysfs groups through driver core The driver core can register and cleanup sysfs groups already. Make use of that functionality to simplify the error handling and cleanup. Also avoid a UAF race during unregistering where the sysctl attributes were usable after the info struct was freed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49926", "url": "https://ubuntu.com/security/CVE-2024-49926", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rcu-tasks: Fix access non-existent percpu rtpcp variable in rcu_tasks_need_gpcb() For kernels built with CONFIG_FORCE_NR_CPUS=y, the nr_cpu_ids is defined as NR_CPUS instead of the number of possible cpus, this will cause the following system panic: smpboot: Allowing 4 CPUs, 0 hotplug CPUs ... setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:512 nr_node_ids:1 ... BUG: unable to handle page fault for address: ffffffff9911c8c8 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 15 Comm: rcu_tasks_trace Tainted: G W 6.6.21 #1 5dc7acf91a5e8e9ac9dcfc35bee0245691283ea6 RIP: 0010:rcu_tasks_need_gpcb+0x25d/0x2c0 RSP: 0018:ffffa371c00a3e60 EFLAGS: 00010082 CR2: ffffffff9911c8c8 CR3: 000000040fa20005 CR4: 00000000001706f0 Call Trace: ? __die+0x23/0x80 ? page_fault_oops+0xa4/0x180 ? exc_page_fault+0x152/0x180 ? asm_exc_page_fault+0x26/0x40 ? rcu_tasks_need_gpcb+0x25d/0x2c0 ? __pfx_rcu_tasks_kthread+0x40/0x40 rcu_tasks_one_gp+0x69/0x180 rcu_tasks_kthread+0x94/0xc0 kthread+0xe8/0x140 ? __pfx_kthread+0x40/0x40 ret_from_fork+0x34/0x80 ? __pfx_kthread+0x40/0x40 ret_from_fork_asm+0x1b/0x80 Considering that there may be holes in the CPU numbers, use the maximum possible cpu number, instead of nr_cpu_ids, for configuring enqueue and dequeue limits. [ neeraj.upadhyay: Fix htmldocs build error reported by Stephen Rothwell ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50007", "url": "https://ubuntu.com/security/CVE-2024-50007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: asihpi: Fix potential OOB array access ASIHPI driver stores some values in the static array upon a response from the driver, and its index depends on the firmware. We shouldn't trust it blindly. This patch adds a sanity check of the array index to fit in the array size.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50017", "url": "https://ubuntu.com/security/CVE-2024-50017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm/ident_map: Use gbpages only where full GB page should be mapped. When ident_pud_init() uses only GB pages to create identity maps, large ranges of addresses not actually requested can be included in the resulting table; a 4K request will map a full GB. This can include a lot of extra address space past that requested, including areas marked reserved by the BIOS. That allows processor speculation into reserved regions, that on UV systems can cause system halts. Only use GB pages when map creation requests include the full GB page of space. Fall back to using smaller 2M pages when only portions of a GB page are included in the request. No attempt is made to coalesce mapping requests. If a request requires a map entry at the 2M (pmd) level, subsequent mapping requests within the same 1G region will also be at the pmd level, even if adjacent or overlapping such requests could have been combined to map a full GB page. Existing usage starts with larger regions and then adds smaller regions, so this should not have any great consequence.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49927", "url": "https://ubuntu.com/security/CVE-2024-49927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/ioapic: Handle allocation failures gracefully Breno observed panics when using failslab under certain conditions during runtime: can not alloc irq_pin_list (-1,0,20) Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed panic+0x4e9/0x590 mp_irqdomain_alloc+0x9ab/0xa80 irq_domain_alloc_irqs_locked+0x25d/0x8d0 __irq_domain_alloc_irqs+0x80/0x110 mp_map_pin_to_irq+0x645/0x890 acpi_register_gsi_ioapic+0xe6/0x150 hpet_open+0x313/0x480 That's a pointless panic which is a leftover of the historic IO/APIC code which panic'ed during early boot when the interrupt allocation failed. The only place which might justify panic is the PIT/HPET timer_check() code which tries to figure out whether the timer interrupt is delivered through the IO/APIC. But that code does not require to handle interrupt allocation failures. If the interrupt cannot be allocated then timer delivery fails and it either panics due to that or falls back to legacy mode. Cure this by removing the panic wrapper around __add_pin_to_irq_node() and making mp_irqdomain_alloc() aware of the failure condition and handle it as any other failure in this function gracefully.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50008", "url": "https://ubuntu.com/security/CVE-2024-50008", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_cmd_802_11_scan_ext() Replace one-element array with a flexible-array member in `struct host_cmd_ds_802_11_scan_ext`. With this, fix the following warning: elo 16 17:51:58 surfacebook kernel: ------------[ cut here ]------------ elo 16 17:51:58 surfacebook kernel: memcpy: detected field-spanning write (size 243) of single field \"ext_scan->tlv_buffer\" at drivers/net/wireless/marvell/mwifiex/scan.c:2239 (size 1) elo 16 17:51:58 surfacebook kernel: WARNING: CPU: 0 PID: 498 at drivers/net/wireless/marvell/mwifiex/scan.c:2239 mwifiex_cmd_802_11_scan_ext+0x83/0x90 [mwifiex]", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50018", "url": "https://ubuntu.com/security/CVE-2024-50018", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49928", "url": "https://ubuntu.com/security/CVE-2024-49928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: avoid reading out of bounds when loading TX power FW elements Because the loop-expression will do one more time before getting false from cond-expression, the original code copied one more entry size beyond valid region. Fix it by moving the entry copy to loop-body.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50178", "url": "https://ubuntu.com/security/CVE-2024-50178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: loongson3: Use raw_smp_processor_id() in do_service_request() Use raw_smp_processor_id() instead of plain smp_processor_id() in do_service_request(), otherwise we may get some errors with the driver enabled: BUG: using smp_processor_id() in preemptible [00000000] code: (udev-worker)/208 caller is loongson3_cpufreq_probe+0x5c/0x250 [loongson3_cpufreq]", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50009", "url": "https://ubuntu.com/security/CVE-2024-50009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: amd-pstate: add check for cpufreq_cpu_get's return value cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it and return in case of error. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49994", "url": "https://ubuntu.com/security/CVE-2024-49994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix integer overflow in BLKSECDISCARD I independently rediscovered \tcommit 22d24a544b0d49bbcbd61c8c0eaf77d3c9297155 \tblock: fix overflow in blk_ioctl_discard() but for secure erase. Same problem: \tuint64_t r[2] = {512, 18446744073709551104ULL}; \tioctl(fd, BLKSECDISCARD, r); will enter near infinite loop inside blkdev_issue_secure_erase(): \ta.out: attempt to access beyond end of device \tloop0: rw=5, sector=3399043073, nr_sectors = 1024 limit=2048 \tbio_check_eod: 3286214 callbacks suppressed", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49929", "url": "https://ubuntu.com/security/CVE-2024-49929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: avoid NULL pointer dereference iwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta pointer is not NULL. It retrieves this pointer using iwl_mvm_sta_from_mac80211, which is dereferencing the ieee80211_sta pointer. If sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL pointer. Fix this by checking the sta pointer before retrieving the mvmsta from it. If sta is not NULL, then mvmsta isn't either.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49995", "url": "https://ubuntu.com/security/CVE-2024-49995", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: guard against string buffer overrun Smatch reports that copying media_name and if_name to name_parts may overwrite the destination. .../bearer.c:166 bearer_name_validate() error: strcpy() 'media_name' too large for 'name_parts->media_name' (32 vs 16) .../bearer.c:167 bearer_name_validate() error: strcpy() 'if_name' too large for 'name_parts->if_name' (1010102 vs 16) This does seem to be the case so guard against this possibility by using strscpy() and failing if truncation occurs. Introduced by commit b97bf3fd8f6a (\"[TIPC] Initial merge\") Compile tested only.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49962", "url": "https://ubuntu.com/security/CVE-2024-49962", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in acpi_db_convert_to_package() ACPICA commit 4d4547cf13cca820ff7e0f859ba83e1a610b9fd0 ACPI_ALLOCATE_ZEROED() may fail, elements might be NULL and will cause NULL pointer dereference later. [ rjw: Subject and changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49930", "url": "https://ubuntu.com/security/CVE-2024-49930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix array out-of-bound access in SoC stats Currently, the ath11k_soc_dp_stats::hal_reo_error array is defined with a maximum size of DP_REO_DST_RING_MAX. However, the ath11k_dp_process_rx() function access ath11k_soc_dp_stats::hal_reo_error using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath11k_dp_process_rx() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49931", "url": "https://ubuntu.com/security/CVE-2024-49931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix array out-of-bound access in SoC stats Currently, the ath12k_soc_dp_stats::hal_reo_error array is defined with a maximum size of DP_REO_DST_RING_MAX. However, the ath12k_dp_rx_process() function access ath12k_soc_dp_stats::hal_reo_error using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath12k_dp_rx_process() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49932", "url": "https://ubuntu.com/security/CVE-2024-49932", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: don't readahead the relocation inode on RST On relocation we're doing readahead on the relocation inode, but if the filesystem is backed by a RAID stripe tree we can get ENOENT (e.g. due to preallocated extents not being mapped in the RST) from the lookup. But readahead doesn't handle the error and submits invalid reads to the device, causing an assertion in the scatter-gather list code: BTRFS info (device nvme1n1): balance: start -d -m -s BTRFS info (device nvme1n1): relocating block group 6480920576 flags data|raid0 BTRFS error (device nvme1n1): cannot find raid-stripe for logical [6481928192, 6481969152] devid 2, profile raid0 ------------[ cut here ]------------ kernel BUG at include/linux/scatterlist.h:115! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 1012 Comm: btrfs Not tainted 6.10.0-rc7+ #567 RIP: 0010:__blk_rq_map_sg+0x339/0x4a0 RSP: 0018:ffffc90001a43820 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffea00045d4802 RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000 RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000001000 R12: ffff8881003d10b8 R13: ffffc90001a438f0 R14: 0000000000000000 R15: 0000000000003000 FS: 00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000002cd11000 CR3: 00000001109ea001 CR4: 0000000000370eb0 Call Trace: ? __die_body.cold+0x14/0x25 ? die+0x2e/0x50 ? do_trap+0xca/0x110 ? do_error_trap+0x65/0x80 ? __blk_rq_map_sg+0x339/0x4a0 ? exc_invalid_op+0x50/0x70 ? __blk_rq_map_sg+0x339/0x4a0 ? asm_exc_invalid_op+0x1a/0x20 ? __blk_rq_map_sg+0x339/0x4a0 nvme_prep_rq.part.0+0x9d/0x770 nvme_queue_rq+0x7d/0x1e0 __blk_mq_issue_directly+0x2a/0x90 ? blk_mq_get_budget_and_tag+0x61/0x90 blk_mq_try_issue_list_directly+0x56/0xf0 blk_mq_flush_plug_list.part.0+0x52b/0x5d0 __blk_flush_plug+0xc6/0x110 blk_finish_plug+0x28/0x40 read_pages+0x160/0x1c0 page_cache_ra_unbounded+0x109/0x180 relocate_file_extent_cluster+0x611/0x6a0 ? btrfs_search_slot+0xba4/0xd20 ? balance_dirty_pages_ratelimited_flags+0x26/0xb00 relocate_data_extent.constprop.0+0x134/0x160 relocate_block_group+0x3f2/0x500 btrfs_relocate_block_group+0x250/0x430 btrfs_relocate_chunk+0x3f/0x130 btrfs_balance+0x71b/0xef0 ? kmalloc_trace_noprof+0x13b/0x280 btrfs_ioctl+0x2c2e/0x3030 ? kvfree_call_rcu+0x1e6/0x340 ? list_lru_add_obj+0x66/0x80 ? mntput_no_expire+0x3a/0x220 __x64_sys_ioctl+0x96/0xc0 do_syscall_64+0x54/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fcc04514f9b Code: Unable to access opcode bytes at 0x7fcc04514f71. RSP: 002b:00007ffeba923370 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fcc04514f9b RDX: 00007ffeba923460 RSI: 00000000c4009420 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000013 R09: 0000000000000001 R10: 00007fcc043fbba8 R11: 0000000000000246 R12: 00007ffeba924fc5 R13: 00007ffeba923460 R14: 0000000000000002 R15: 00000000004d4bb0 Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:__blk_rq_map_sg+0x339/0x4a0 RSP: 0018:ffffc90001a43820 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffea00045d4802 RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000 RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000001000 R12: ffff8881003d10b8 R13: ffffc90001a438f0 R14: 0000000000000000 R15: 0000000000003000 FS: 00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcc04514f71 CR3: 00000001109ea001 CR4: 0000000000370eb0 Kernel p ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49933", "url": "https://ubuntu.com/security/CVE-2024-49933", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk_iocost: fix more out of bound shifts Recently running UBSAN caught few out of bound shifts in the ioc_forgive_debts() function: UBSAN: shift-out-of-bounds in block/blk-iocost.c:2142:38 shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long long') ... UBSAN: shift-out-of-bounds in block/blk-iocost.c:2144:30 shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long long') ... Call Trace: dump_stack_lvl+0xca/0x130 __ubsan_handle_shift_out_of_bounds+0x22c/0x280 ? __lock_acquire+0x6441/0x7c10 ioc_timer_fn+0x6cec/0x7750 ? blk_iocost_init+0x720/0x720 ? call_timer_fn+0x5d/0x470 call_timer_fn+0xfa/0x470 ? blk_iocost_init+0x720/0x720 __run_timer_base+0x519/0x700 ... Actual impact of this issue was not identified but I propose to fix the undefined behaviour. The proposed fix to prevent those out of bound shifts consist of precalculating exponent before using it the shift operations by taking min value from the actual exponent and maximum possible number of bits.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49934", "url": "https://ubuntu.com/security/CVE-2024-49934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/inode: Prevent dump_mapping() accessing invalid dentry.d_name.name It's observed that a crash occurs during hot-remove a memory device, in which user is accessing the hugetlb. See calltrace as following: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 14045 at arch/x86/mm/fault.c:1278 do_user_addr_fault+0x2a0/0x790 Modules linked in: kmem device_dax cxl_mem cxl_pmem cxl_port cxl_pci dax_hmem dax_pmem nd_pmem cxl_acpi nd_btt cxl_core crc32c_intel nvme virtiofs fuse nvme_core nfit libnvdimm dm_multipath scsi_dh_rdac scsi_dh_emc s mirror dm_region_hash dm_log dm_mod CPU: 1 PID: 14045 Comm: daxctl Not tainted 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:do_user_addr_fault+0x2a0/0x790 Code: 48 8b 00 a8 04 0f 84 b5 fe ff ff e9 1c ff ff ff 4c 89 e9 4c 89 e2 be 01 00 00 00 bf 02 00 00 00 e8 b5 ef 24 00 e9 42 fe ff ff <0f> 0b 48 83 c4 08 4c 89 ea 48 89 ee 4c 89 e7 5b 5d 41 5c 41 5d 41 RSP: 0000:ffffc90000a575f0 EFLAGS: 00010046 RAX: ffff88800c303600 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000001000 RSI: ffffffff82504162 RDI: ffffffff824b2c36 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffc90000a57658 R13: 0000000000001000 R14: ffff88800bc2e040 R15: 0000000000000000 FS: 00007f51cb57d880(0000) GS:ffff88807fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000001000 CR3: 00000000072e2004 CR4: 00000000001706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn+0x8d/0x190 ? do_user_addr_fault+0x2a0/0x790 ? report_bug+0x1c3/0x1d0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? do_user_addr_fault+0x2a0/0x790 ? exc_page_fault+0x31/0x200 exc_page_fault+0x68/0x200 <...snip...> BUG: unable to handle page fault for address: 0000000000001000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI ---[ end trace 0000000000000000 ]--- BUG: unable to handle page fault for address: 0000000000001000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 14045 Comm: daxctl Kdump: loaded Tainted: G W 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:dentry_name+0x1f4/0x440 <...snip...> ? dentry_name+0x2fa/0x440 vsnprintf+0x1f3/0x4f0 vprintk_store+0x23a/0x540 vprintk_emit+0x6d/0x330 _printk+0x58/0x80 dump_mapping+0x10b/0x1a0 ? __pfx_free_object_rcu+0x10/0x10 __dump_page+0x26b/0x3e0 ? vprintk_emit+0xe0/0x330 ? _printk+0x58/0x80 ? dump_page+0x17/0x50 dump_page+0x17/0x50 do_migrate_range+0x2f7/0x7f0 ? do_migrate_range+0x42/0x7f0 ? offline_pages+0x2f4/0x8c0 offline_pages+0x60a/0x8c0 memory_subsys_offline+0x9f/0x1c0 ? lockdep_hardirqs_on+0x77/0x100 ? _raw_spin_unlock_irqrestore+0x38/0x60 device_offline+0xe3/0x110 state_store+0x6e/0xc0 kernfs_fop_write_iter+0x143/0x200 vfs_write+0x39f/0x560 ksys_write+0x65/0xf0 do_syscall_64+0x62/0x130 Previously, some sanity check have been done in dump_mapping() before the print facility parsing '%pd' though, it's still possible to run into an invalid dentry.d_name.name. Since dump_mapping() only needs to dump the filename only, retrieve it by itself in a safer way to prevent an unnecessary crash. Note that either retrieving the filename with '%pd' or strncpy_from_kernel_nofault(), the filename could be unreliable.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49935", "url": "https://ubuntu.com/security/CVE-2024-49935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: PAD: fix crash in exit_round_robin() The kernel occasionally crashes in cpumask_clear_cpu(), which is called within exit_round_robin(), because when executing clear_bit(nr, addr) with nr set to 0xffffffff, the address calculation may cause misalignment within the memory, leading to access to an invalid memory address. ---------- BUG: unable to handle kernel paging request at ffffffffe0740618 ... CPU: 3 PID: 2919323 Comm: acpi_pad/14 Kdump: loaded Tainted: G OE X --------- - - 4.18.0-425.19.2.el8_7.x86_64 #1 ... RIP: 0010:power_saving_thread+0x313/0x411 [acpi_pad] Code: 89 cd 48 89 d3 eb d1 48 c7 c7 55 70 72 c0 e8 64 86 b0 e4 c6 05 0d a1 02 00 01 e9 bc fd ff ff 45 89 e4 42 8b 04 a5 20 82 72 c0 48 0f b3 05 f4 9c 01 00 42 c7 04 a5 20 82 72 c0 ff ff ff ff 31 RSP: 0018:ff72a5d51fa77ec8 EFLAGS: 00010202 RAX: 00000000ffffffff RBX: ff462981e5d8cb80 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246 RBP: ff46297556959d80 R08: 0000000000000382 R09: ff46297c8d0f38d8 R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000000e R13: 0000000000000000 R14: ffffffffffffffff R15: 000000000000000e FS: 0000000000000000(0000) GS:ff46297a800c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffe0740618 CR3: 0000007e20410004 CR4: 0000000000771ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? acpi_pad_add+0x120/0x120 [acpi_pad] kthread+0x10b/0x130 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x1f/0x40 ... CR2: ffffffffe0740618 crash> dis -lr ffffffffc0726923 ... /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 114 0xffffffffc0726918 :\tmov %r12d,%r12d /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 325 0xffffffffc072691b :\tmov -0x3f8d7de0(,%r12,4),%eax /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./arch/x86/include/asm/bitops.h: 80 0xffffffffc0726923 :\tlock btr %rax,0x19cf4(%rip) # 0xffffffffc0740620 crash> px tsk_in_cpu[14] $66 = 0xffffffff crash> px 0xffffffffc072692c+0x19cf4 $99 = 0xffffffffc0740620 crash> sym 0xffffffffc0740620 ffffffffc0740620 (b) pad_busy_cpus_bits [acpi_pad] crash> px pad_busy_cpus_bits[0] $42 = 0xfffc0 ---------- To fix this, ensure that tsk_in_cpu[tsk_index] != -1 before calling cpumask_clear_cpu() in exit_round_robin(), just as it is done in round_robin_cpu(). [ rjw: Subject edit, avoid updates to the same value ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49936", "url": "https://ubuntu.com/security/CVE-2024-49936", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/xen-netback: prevent UAF in xenvif_flush_hash() During the list_for_each_entry_rcu iteration call of xenvif_flush_hash, kfree_rcu does not exist inside the rcu read critical section, so if kfree_rcu is called when the rcu grace period ends during the iteration, UAF occurs when accessing head->next after the entry becomes free. Therefore, to solve this, you need to change it to list_for_each_entry_safe.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49937", "url": "https://ubuntu.com/security/CVE-2024-49937", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Set correct chandef when starting CAC When starting CAC in a mode other than AP mode, it return a \"WARNING: CPU: 0 PID: 63 at cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]\" caused by the chandef.chan being null at the end of CAC. Solution: Ensure the channel definition is set for the different modes when starting CAC to avoid getting a NULL 'chan' at the end of CAC. Call Trace: ? show_regs.part.0+0x14/0x16 ? __warn+0x67/0xc0 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? report_bug+0xa7/0x130 ? exc_overflow+0x30/0x30 ? handle_bug+0x27/0x50 ? exc_invalid_op+0x18/0x60 ? handle_exception+0xf6/0xf6 ? exc_overflow+0x30/0x30 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? exc_overflow+0x30/0x30 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? regulatory_propagate_dfs_state.cold+0x1b/0x4c [cfg80211] ? cfg80211_propagate_cac_done_wk+0x1a/0x30 [cfg80211] ? process_one_work+0x165/0x280 ? worker_thread+0x120/0x3f0 ? kthread+0xc2/0xf0 ? process_one_work+0x280/0x280 ? kthread_complete_and_exit+0x20/0x20 ? ret_from_fork+0x19/0x24 [shorten subject, remove OCB, reorder cases to match previous list]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49938", "url": "https://ubuntu.com/security/CVE-2024-49938", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmit Syzbot points out that skb_trim() has a sanity check on the existing length of the skb, which can be uninitialised in some error paths. The intent here is clearly just to reset the length to zero before resubmitting, so switch to calling __skb_set_length(skb, 0) directly. In addition, __skb_set_length() already contains a call to skb_reset_tail_pointer(), so remove the redundant call. The syzbot report came from ath9k_hif_usb_reg_in_cb(), but there's a similar usage of skb_trim() in ath9k_hif_usb_rx_cb(), change both while we're at it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49939", "url": "https://ubuntu.com/security/CVE-2024-49939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: avoid to add interface to list twice when SER If SER L2 occurs during the WoWLAN resume flow, the add interface flow is triggered by ieee80211_reconfig(). However, due to rtw89_wow_resume() return failure, it will cause the add interface flow to be executed again, resulting in a double add list and causing a kernel panic. Therefore, we have added a check to prevent double adding of the list. list_add double add: new=ffff99d6992e2010, prev=ffff99d6992e2010, next=ffff99d695302628. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:37! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G W O 6.6.30-02659-gc18865c4dfbd #1 770df2933251a0e3c888ba69d1053a817a6376a7 Hardware name: HP Grunt/Grunt, BIOS Google_Grunt.11031.169.0 06/24/2021 Workqueue: events_freezable ieee80211_restart_work [mac80211] RIP: 0010:__list_add_valid_or_report+0x5e/0xb0 Code: c7 74 18 48 39 ce 74 13 b0 01 59 5a 5e 5f 41 58 41 59 41 5a 5d e9 e2 d6 03 00 cc 48 c7 c7 8d 4f 17 83 48 89 c2 e8 02 c0 00 00 <0f> 0b 48 c7 c7 aa 8c 1c 83 e8 f4 bf 00 00 0f 0b 48 c7 c7 c8 bc 12 RSP: 0018:ffffa91b8007bc50 EFLAGS: 00010246 RAX: 0000000000000058 RBX: ffff99d6992e0900 RCX: a014d76c70ef3900 RDX: ffffa91b8007bae8 RSI: 00000000ffffdfff RDI: 0000000000000001 RBP: ffffa91b8007bc88 R08: 0000000000000000 R09: ffffa91b8007bae0 R10: 00000000ffffdfff R11: ffffffff83a79800 R12: ffff99d695302060 R13: ffff99d695300900 R14: ffff99d6992e1be0 R15: ffff99d6992e2010 FS: 0000000000000000(0000) GS:ffff99d6aac00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000078fbdba43480 CR3: 000000010e464000 CR4: 00000000001506f0 Call Trace: ? __die_body+0x1f/0x70 ? die+0x3d/0x60 ? do_trap+0xa4/0x110 ? __list_add_valid_or_report+0x5e/0xb0 ? do_error_trap+0x6d/0x90 ? __list_add_valid_or_report+0x5e/0xb0 ? handle_invalid_op+0x30/0x40 ? __list_add_valid_or_report+0x5e/0xb0 ? exc_invalid_op+0x3c/0x50 ? asm_exc_invalid_op+0x16/0x20 ? __list_add_valid_or_report+0x5e/0xb0 rtw89_ops_add_interface+0x309/0x310 [rtw89_core 7c32b1ee6854761c0321027c8a58c5160e41f48f] drv_add_interface+0x5c/0x130 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ieee80211_reconfig+0x241/0x13d0 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ? finish_wait+0x3e/0x90 ? synchronize_rcu_expedited+0x174/0x260 ? sync_rcu_exp_done_unlocked+0x50/0x50 ? wake_bit_function+0x40/0x40 ieee80211_restart_work+0xf0/0x140 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] process_scheduled_works+0x1e5/0x480 worker_thread+0xea/0x1e0 kthread+0xdb/0x110 ? move_linked_works+0x90/0x90 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork+0x3b/0x50 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork_asm+0x11/0x20 Modules linked in: dm_integrity async_xor xor async_tx lz4 lz4_compress zstd zstd_compress zram zsmalloc rfcomm cmac uinput algif_hash algif_skcipher af_alg btusb btrtl iio_trig_hrtimer industrialio_sw_trigger btmtk industrialio_configfs btbcm btintel uvcvideo videobuf2_vmalloc iio_trig_sysfs videobuf2_memops videobuf2_v4l2 videobuf2_common uvc snd_hda_codec_hdmi veth snd_hda_intel snd_intel_dspcfg acpi_als snd_hda_codec industrialio_triggered_buffer kfifo_buf snd_hwdep industrialio i2c_piix4 snd_hda_core designware_i2s ip6table_nat snd_soc_max98357a xt_MASQUERADE xt_cgroup snd_soc_acp_rt5682_mach fuse rtw89_8922ae(O) rtw89_8922a(O) rtw89_pci(O) rtw89_core(O) 8021q mac80211(O) bluetooth ecdh_generic ecc cfg80211 r8152 mii joydev gsmi: Log Shutdown Reason 0x03 ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49940", "url": "https://ubuntu.com/security/CVE-2024-49940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: prevent possible tunnel refcount underflow When a session is created, it sets a backpointer to its tunnel. When the session refcount drops to 0, l2tp_session_free drops the tunnel refcount if session->tunnel is non-NULL. However, session->tunnel is set in l2tp_session_create, before the tunnel refcount is incremented by l2tp_session_register, which leaves a small window where session->tunnel is non-NULL when the tunnel refcount hasn't been bumped. Moving the assignment to l2tp_session_register is trivial but l2tp_session_create calls l2tp_session_set_header_len which uses session->tunnel to get the tunnel's encap. Add an encap arg to l2tp_session_set_header_len to avoid using session->tunnel. If l2tpv3 sessions have colliding IDs, it is possible for l2tp_v3_session_get to race with l2tp_session_register and fetch a session which doesn't yet have session->tunnel set. Add a check for this case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49941", "url": "https://ubuntu.com/security/CVE-2024-49941", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpiolib: Fix potential NULL pointer dereference in gpiod_get_label() In `gpiod_get_label()`, it is possible that `srcu_dereference_check()` may return a NULL pointer, leading to a scenario where `label->str` is accessed without verifying if `label` itself is NULL. This patch adds a proper NULL check for `label` before accessing `label->str`. The check for `label->str != NULL` is removed because `label->str` can never be NULL if `label` is not NULL. This fixes the issue where the label name was being printed as `(efault)` when dumping the sysfs GPIO file when `label == NULL`.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49996", "url": "https://ubuntu.com/security/CVE-2024-49996", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: Fix buffer overflow when parsing NFS reparse points ReparseDataLength is sum of the InodeType size and DataBuffer size. So to get DataBuffer size it is needed to subtract InodeType's size from ReparseDataLength. Function cifs_strndup_from_utf16() is currentlly accessing buf->DataBuffer at position after the end of the buffer because it does not subtract InodeType size from the length. Fix this problem and correctly subtract variable len. Member InodeType is present only when reparse buffer is large enough. Check for ReparseDataLength before accessing InodeType to prevent another invalid memory access. Major and minor rdev values are present also only when reparse buffer is large enough. Check for reparse buffer size before calling reparse_mkdev().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49942", "url": "https://ubuntu.com/security/CVE-2024-49942", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Prevent null pointer access in xe_migrate_copy xe_migrate_copy designed to copy content of TTM resources. When source resource is null, it will trigger a NULL pointer dereference in xe_migrate_copy. To avoid this situation, update lacks source flag to true for this case, the flag will trigger xe_migrate_clear rather than xe_migrate_copy. Issue trace: <7> [317.089847] xe 0000:00:02.0: [drm:xe_migrate_copy [xe]] Pass 14, sizes: 4194304 & 4194304 <7> [317.089945] xe 0000:00:02.0: [drm:xe_migrate_copy [xe]] Pass 15, sizes: 4194304 & 4194304 <1> [317.128055] BUG: kernel NULL pointer dereference, address: 0000000000000010 <1> [317.128064] #PF: supervisor read access in kernel mode <1> [317.128066] #PF: error_code(0x0000) - not-present page <6> [317.128069] PGD 0 P4D 0 <4> [317.128071] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI <4> [317.128074] CPU: 1 UID: 0 PID: 1440 Comm: kunit_try_catch Tainted: G U N 6.11.0-rc7-xe #1 <4> [317.128078] Tainted: [U]=USER, [N]=TEST <4> [317.128080] Hardware name: Intel Corporation Lunar Lake Client Platform/LNL-M LP5 RVP1, BIOS LNLMFWI1.R00.3221.D80.2407291239 07/29/2024 <4> [317.128082] RIP: 0010:xe_migrate_copy+0x66/0x13e0 [xe] <4> [317.128158] Code: 00 00 48 89 8d e0 fe ff ff 48 8b 40 10 4c 89 85 c8 fe ff ff 44 88 8d bd fe ff ff 65 48 8b 3c 25 28 00 00 00 48 89 7d d0 31 ff <8b> 79 10 48 89 85 a0 fe ff ff 48 8b 00 48 89 b5 d8 fe ff ff 83 ff <4> [317.128162] RSP: 0018:ffffc9000167f9f0 EFLAGS: 00010246 <4> [317.128164] RAX: ffff8881120d8028 RBX: ffff88814d070428 RCX: 0000000000000000 <4> [317.128166] RDX: ffff88813cb99c00 RSI: 0000000004000000 RDI: 0000000000000000 <4> [317.128168] RBP: ffffc9000167fbb8 R08: ffff88814e7b1f08 R09: 0000000000000001 <4> [317.128170] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88814e7b1f08 <4> [317.128172] R13: ffff88814e7b1f08 R14: ffff88813cb99c00 R15: 0000000000000001 <4> [317.128174] FS: 0000000000000000(0000) GS:ffff88846f280000(0000) knlGS:0000000000000000 <4> [317.128176] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [317.128178] CR2: 0000000000000010 CR3: 000000011f676004 CR4: 0000000000770ef0 <4> [317.128180] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 <4> [317.128182] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400 <4> [317.128184] PKRU: 55555554 <4> [317.128185] Call Trace: <4> [317.128187] <4> [317.128189] ? show_regs+0x67/0x70 <4> [317.128194] ? __die_body+0x20/0x70 <4> [317.128196] ? __die+0x2b/0x40 <4> [317.128198] ? page_fault_oops+0x15f/0x4e0 <4> [317.128203] ? do_user_addr_fault+0x3fb/0x970 <4> [317.128205] ? lock_acquire+0xc7/0x2e0 <4> [317.128209] ? exc_page_fault+0x87/0x2b0 <4> [317.128212] ? asm_exc_page_fault+0x27/0x30 <4> [317.128216] ? xe_migrate_copy+0x66/0x13e0 [xe] <4> [317.128263] ? __lock_acquire+0xb9d/0x26f0 <4> [317.128265] ? __lock_acquire+0xb9d/0x26f0 <4> [317.128267] ? sg_free_append_table+0x20/0x80 <4> [317.128271] ? lock_acquire+0xc7/0x2e0 <4> [317.128273] ? mark_held_locks+0x4d/0x80 <4> [317.128275] ? trace_hardirqs_on+0x1e/0xd0 <4> [317.128278] ? _raw_spin_unlock_irqrestore+0x31/0x60 <4> [317.128281] ? __pm_runtime_resume+0x60/0xa0 <4> [317.128284] xe_bo_move+0x682/0xc50 [xe] <4> [317.128315] ? lock_is_held_type+0xaa/0x120 <4> [317.128318] ttm_bo_handle_move_mem+0xe5/0x1a0 [ttm] <4> [317.128324] ttm_bo_validate+0xd1/0x1a0 [ttm] <4> [317.128328] shrink_test_run_device+0x721/0xc10 [xe] <4> [317.128360] ? find_held_lock+0x31/0x90 <4> [317.128363] ? lock_release+0xd1/0x2a0 <4> [317.128365] ? __pfx_kunit_generic_run_threadfn_adapter+0x10/0x10 [kunit] <4> [317.128370] xe_bo_shrink_kunit+0x11/0x20 [xe] <4> [317.128397] kunit_try_run_case+0x6e/0x150 [kunit] <4> [317.128400] ? trace_hardirqs_on+0x1e/0xd0 <4> [317.128402] ? _raw_spin_unlock_irqrestore+0x31/0x60 <4> [317.128404] kunit_generic_run_threadfn_adapter+0x1e/0x40 [ku ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49943", "url": "https://ubuntu.com/security/CVE-2024-49943", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc_submit: add missing locking in wedged_fini Any non-wedged queue can have a zero refcount here and can be running concurrently with an async queue destroy, therefore dereferencing the queue ptr to check wedge status after the lookup can trigger UAF if queue is not wedged. Fix this by keeping the submission_state lock held around the check to postpone the free and make the check safe, before dropping again around the put() to avoid the deadlock. (cherry picked from commit d28af0b6b9580b9f90c265a7da0315b0ad20bbfd)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50011", "url": "https://ubuntu.com/security/CVE-2024-50011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: soc-acpi-intel-rpl-match: add missing empty item There is no links_num in struct snd_soc_acpi_mach {}, and we test !link->num_adr as a condition to end the loop in hda_sdw_machine_select(). So an empty item in struct snd_soc_acpi_link_adr array is required.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50174", "url": "https://ubuntu.com/security/CVE-2024-50174", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix race when converting group handle to group object XArray provides it's own internal lock which protects the internal array when entries are being simultaneously added and removed. However there is still a race between retrieving the pointer from the XArray and incrementing the reference count. To avoid this race simply hold the internal XArray lock when incrementing the reference count, this ensures there cannot be a racing call to xa_erase().", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49944", "url": "https://ubuntu.com/security/CVE-2024-49944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_start In sctp_listen_start() invoked by sctp_inet_listen(), it should set the sk_state back to CLOSED if sctp_autobind() fails due to whatever reason. Otherwise, next time when calling sctp_inet_listen(), if sctp_sk(sk)->reuse is already set via setsockopt(SCTP_REUSE_PORT), sctp_sk(sk)->bind_hash will be dereferenced as sk_state is LISTENING, which causes a crash as bind_hash is NULL. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:sctp_inet_listen+0x7f0/0xa20 net/sctp/socket.c:8617 Call Trace: __sys_listen_socket net/socket.c:1883 [inline] __sys_listen+0x1b7/0x230 net/socket.c:1894 __do_sys_listen net/socket.c:1902 [inline]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49945", "url": "https://ubuntu.com/security/CVE-2024-49945", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/ncsi: Disable the ncsi work before freeing the associated structure The work function can run after the ncsi device is freed, resulting in use-after-free bugs or kernel panic.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49946", "url": "https://ubuntu.com/security/CVE-2024-49946", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: do not assume bh is held in ppp_channel_bridge_input() Networking receive path is usually handled from BH handler. However, some protocols need to acquire the socket lock, and packets might be stored in the socket backlog is the socket was owned by a user process. In this case, release_sock(), __release_sock(), and sk_backlog_rcv() might call the sk->sk_backlog_rcv() handler in process context. sybot caught ppp was not considering this case in ppp_channel_bridge_input() : WARNING: inconsistent lock state 6.11.0-rc7-syzkaller-g5f5673607153 #0 Not tainted -------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. ksoftirqd/1/24 [HC0[0]:SC1[1]:HE1:SE0] takes: ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 {SOFTIRQ-ON-W} state was registered at: lock_acquire+0x240/0x728 kernel/locking/lockdep.c:5759 __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline] _raw_spin_lock+0x48/0x60 kernel/locking/spinlock.c:154 spin_lock include/linux/spinlock.h:351 [inline] ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline] ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0xfc/0x314 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv include/net/sock.h:1111 [inline] __release_sock+0x1a8/0x3d8 net/core/sock.c:3004 release_sock+0x68/0x1b8 net/core/sock.c:3558 pppoe_sendmsg+0xc8/0x5d8 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x374/0x4f4 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __arm64_sys_sendto+0xd8/0xf8 net/socket.c:2212 __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:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 irq event stamp: 282914 hardirqs last enabled at (282914): [] __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:151 [inline] hardirqs last enabled at (282914): [] _raw_spin_unlock_irqrestore+0x38/0x98 kernel/locking/spinlock.c:194 hardirqs last disabled at (282913): [] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline] hardirqs last disabled at (282913): [] _raw_spin_lock_irqsave+0x2c/0x7c kernel/locking/spinlock.c:162 softirqs last enabled at (282904): [] softirq_handle_end kernel/softirq.c:400 [inline] softirqs last enabled at (282904): [] handle_softirqs+0xa3c/0xbfc kernel/softirq.c:582 softirqs last disabled at (282909): [] run_ksoftirqd+0x70/0x158 kernel/softirq.c:928 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&pch->downl); lock(&pch->downl); *** DEADLOCK *** 1 lock held by ksoftirqd/1/24: #0: ffff80008f74dfa0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire+0x10/0x4c include/linux/rcupdate.h:325 stack backtrace: CPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 6.11.0-rc7-syzkaller-g5f5673607153 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call trace: dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:319 show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:326 __dump_sta ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49947", "url": "https://ubuntu.com/security/CVE-2024-49947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: test for not too small csum_start in virtio_net_hdr_to_skb() syzbot was able to trigger this warning [1], after injecting a malicious packet through af_packet, setting skb->csum_start and thus the transport header to an incorrect value. We can at least make sure the transport header is after the end of the network header (with a estimated minimal size). [1] [ 67.873027] skb len=4096 headroom=16 headlen=14 tailroom=0 mac=(-1,-1) mac_len=0 net=(16,-6) trans=10 shinfo(txflags=0 nr_frags=1 gso(size=0 type=0 segs=0)) csum(0xa start=10 offset=0 ip_summed=3 complete_sw=0 valid=0 level=0) hash(0x0 sw=0 l4=0) proto=0x0800 pkttype=0 iif=0 priority=0x0 mark=0x0 alloc_cpu=10 vlan_all=0x0 encapsulation=0 inner(proto=0x0000, mac=0, net=0, trans=0) [ 67.877172] dev name=veth0_vlan feat=0x000061164fdd09e9 [ 67.877764] sk family=17 type=3 proto=0 [ 67.878279] skb linear: 00000000: 00 00 10 00 00 00 00 00 0f 00 00 00 08 00 [ 67.879128] skb frag: 00000000: 0e 00 07 00 00 00 28 00 08 80 1c 00 04 00 00 02 [ 67.879877] skb frag: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.880647] skb frag: 00000020: 00 00 02 00 00 00 08 00 1b 00 00 00 00 00 00 00 [ 67.881156] skb frag: 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.881753] skb frag: 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.882173] skb frag: 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.882790] skb frag: 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.883171] skb frag: 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.883733] skb frag: 00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.884206] skb frag: 00000090: 00 00 00 00 00 00 00 00 00 00 69 70 76 6c 61 6e [ 67.884704] skb frag: 000000a0: 31 00 00 00 00 00 00 00 00 00 2b 00 00 00 00 00 [ 67.885139] skb frag: 000000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.885677] skb frag: 000000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.886042] skb frag: 000000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.886408] skb frag: 000000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.887020] skb frag: 000000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.887384] skb frag: 00000100: 00 00 [ 67.887878] ------------[ cut here ]------------ [ 67.887908] offset (-6) >= skb_headlen() (14) [ 67.888445] WARNING: CPU: 10 PID: 2088 at net/core/dev.c:3332 skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.889353] Modules linked in: macsec macvtap macvlan hsr wireguard curve25519_x86_64 libcurve25519_generic libchacha20poly1305 chacha_x86_64 libchacha poly1305_x86_64 dummy bridge sr_mod cdrom evdev pcspkr i2c_piix4 9pnet_virtio 9p 9pnet netfs [ 67.890111] CPU: 10 UID: 0 PID: 2088 Comm: b363492833 Not tainted 6.11.0-virtme #1011 [ 67.890183] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 67.890309] RIP: 0010:skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891043] Call Trace: [ 67.891173] [ 67.891274] ? __warn (kernel/panic.c:741) [ 67.891320] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891333] ? report_bug (lib/bug.c:180 lib/bug.c:219) [ 67.891348] ? handle_bug (arch/x86/kernel/traps.c:239) [ 67.891363] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) [ 67.891372] ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621) [ 67.891388] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891399] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891416] ip_do_fragment (net/ipv4/ip_output.c:777 (discriminator 1)) [ 67.891448] ? __ip_local_out (./include/linux/skbuff.h:1146 ./include/net/l3mdev.h:196 ./include/net/l3mdev.h:213 ne ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49948", "url": "https://ubuntu.com/security/CVE-2024-49948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: add more sanity checks to qdisc_pkt_len_init() One path takes care of SKB_GSO_DODGY, assuming skb->len is bigger than hdr_len. virtio_net_hdr_to_skb() does not fully dissect TCP headers, it only make sure it is at least 20 bytes. It is possible for an user to provide a malicious 'GSO' packet, total length of 80 bytes. - 20 bytes of IPv4 header - 60 bytes TCP header - a small gso_size like 8 virtio_net_hdr_to_skb() would declare this packet as a normal GSO packet, because it would see 40 bytes of payload, bigger than gso_size. We need to make detect this case to not underflow qdisc_skb_cb(skb)->pkt_len.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49949", "url": "https://ubuntu.com/security/CVE-2024-49949", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: avoid potential underflow in qdisc_pkt_len_init() with UFO After commit 7c6d2ecbda83 (\"net: be more gentle about silly gso requests coming from user\") virtio_net_hdr_to_skb() had sanity check to detect malicious attempts from user space to cook a bad GSO packet. Then commit cf9acc90c80ec (\"net: virtio_net_hdr_to_skb: count transport header in UFO\") while fixing one issue, allowed user space to cook a GSO packet with the following characteristic : IPv4 SKB_GSO_UDP, gso_size=3, skb->len = 28. When this packet arrives in qdisc_pkt_len_init(), we end up with hdr_len = 28 (IPv4 header + UDP header), matching skb->len Then the following sets gso_segs to 0 : gso_segs = DIV_ROUND_UP(skb->len - hdr_len, shinfo->gso_size); Then later we set qdisc_skb_cb(skb)->pkt_len to back to zero :/ qdisc_skb_cb(skb)->pkt_len += (gso_segs - 1) * hdr_len; This leads to the following crash in fq_codel [1] qdisc_pkt_len_init() is best effort, we only want an estimation of the bytes sent on the wire, not crashing the kernel. This patch is fixing this particular issue, a following one adds more sanity checks for another potential bug. [1] [ 70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 70.724561] #PF: supervisor read access in kernel mode [ 70.724561] #PF: error_code(0x0000) - not-present page [ 70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0 [ 70.724561] Oops: Oops: 0000 [#1] SMP NOPTI [ 70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991 [ 70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel [ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 <49> 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49 All code ======== 0:\t24 08 \tand $0x8,%al 2:\t49 c1 e1 06 \tshl $0x6,%r9 6:\t44 89 7c 24 18 \tmov %r15d,0x18(%rsp) b:\t45 31 ed \txor %r13d,%r13d e:\t45 31 c0 \txor %r8d,%r8d 11:\t31 ff \txor %edi,%edi 13:\t89 44 24 14 \tmov %eax,0x14(%rsp) 17:\t4c 03 8b 90 01 00 00 \tadd 0x190(%rbx),%r9 1e:\teb 04 \tjmp 0x24 20:\t39 ca \tcmp %ecx,%edx 22:\t73 37 \tjae 0x5b 24:\t4d 8b 39 \tmov (%r9),%r15 27:\t83 c7 01 \tadd $0x1,%edi 2a:*\t49 8b 17 \tmov (%r15),%rdx\t\t<-- trapping instruction 2d:\t49 89 11 \tmov %rdx,(%r9) 30:\t41 8b 57 28 \tmov 0x28(%r15),%edx 34:\t45 8b 5f 34 \tmov 0x34(%r15),%r11d 38:\t49 c7 07 00 00 00 00 \tmovq $0x0,(%r15) 3f:\t49 \trex.WB Code starting with the faulting instruction =========================================== 0:\t49 8b 17 \tmov (%r15),%rdx 3:\t49 89 11 \tmov %rdx,(%r9) 6:\t41 8b 57 28 \tmov 0x28(%r15),%edx a:\t45 8b 5f 34 \tmov 0x34(%r15),%r11d e:\t49 c7 07 00 00 00 00 \tmovq $0x0,(%r15) 15:\t49 \trex.WB [ 70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202 [ 70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000 [ 70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001 [ 70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000 [ 70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58 [ 70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000 [ 70.724561] FS: 000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000 [ 70.724561] CS: 0010 DS: 0000 ES: 0000 C ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49997", "url": "https://ubuntu.com/security/CVE-2024-49997", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: lantiq_etop: fix memory disclosure When applying padding, the buffer is not zeroed, which results in memory disclosure. The mentioned data is observed on the wire. This patch uses skb_put_padto() to pad Ethernet frames properly. The mentioned function zeroes the expanded buffer. In case the packet cannot be padded it is silently dropped. Statistics are also not incremented. This driver does not support statistics in the old 32-bit format or the new 64-bit format. These will be added in the future. In its current form, the patch should be easily backported to stable versions. Ethernet MACs on Amazon-SE and Danube cannot do padding of the packets in hardware, so software padding must be applied.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49998", "url": "https://ubuntu.com/security/CVE-2024-49998", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: improve shutdown sequence Alexander Sverdlin presents 2 problems during shutdown with the lan9303 driver. One is specific to lan9303 and the other just happens to reproduce there. The first problem is that lan9303 is unique among DSA drivers in that it calls dev_get_drvdata() at \"arbitrary runtime\" (not probe, not shutdown, not remove): phy_state_machine() -> ... -> dsa_user_phy_read() -> ds->ops->phy_read() -> lan9303_phy_read() -> chip->ops->phy_read() -> lan9303_mdio_phy_read() -> dev_get_drvdata() But we never stop the phy_state_machine(), so it may continue to run after dsa_switch_shutdown(). Our common pattern in all DSA drivers is to set drvdata to NULL to suppress the remove() method that may come afterwards. But in this case it will result in an NPD. The second problem is that the way in which we set dp->conduit->dsa_ptr = NULL; is concurrent with receive packet processing. dsa_switch_rcv() checks once whether dev->dsa_ptr is NULL, but afterwards, rather than continuing to use that non-NULL value, dev->dsa_ptr is dereferenced again and again without NULL checks: dsa_conduit_find_user() and many other places. In between dereferences, there is no locking to ensure that what was valid once continues to be valid. Both problems have the common aspect that closing the conduit interface solves them. In the first case, dev_close(conduit) triggers the NETDEV_GOING_DOWN event in dsa_user_netdevice_event() which closes user ports as well. dsa_port_disable_rt() calls phylink_stop(), which synchronously stops the phylink state machine, and ds->ops->phy_read() will thus no longer call into the driver after this point. In the second case, dev_close(conduit) should do this, as per Documentation/networking/driver.rst: | Quiescence | ---------- | | After the ndo_stop routine has been called, the hardware must | not receive or transmit any data. All in flight packets must | be aborted. If necessary, poll or wait for completion of | any reset commands. So it should be sufficient to ensure that later, when we zeroize conduit->dsa_ptr, there will be no concurrent dsa_switch_rcv() call on this conduit. The addition of the netif_device_detach() function is to ensure that ioctls, rtnetlinks and ethtool requests on the user ports no longer propagate down to the driver - we're no longer prepared to handle them. The race condition actually did not exist when commit 0650bf52b31f (\"net: dsa: be compatible with masters which unregister on shutdown\") first introduced dsa_switch_shutdown(). It was created later, when we stopped unregistering the user interfaces from a bad spot, and we just replaced that sequence with a racy zeroization of conduit->dsa_ptr (one which doesn't ensure that the interfaces aren't up).", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49999", "url": "https://ubuntu.com/security/CVE-2024-49999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix the setting of the server responding flag In afs_wait_for_operation(), we set transcribe the call responded flag to the server record that we used after doing the fileserver iteration loop - but it's possible to exit the loop having had a response from the server that we've discarded (e.g. it returned an abort or we started receiving data, but the call didn't complete). This means that op->server might be NULL, but we don't check that before attempting to set the server flag.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49950", "url": "https://ubuntu.com/security/CVE-2024-49950", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix uaf in l2cap_connect [Syzbot reported] BUG: KASAN: slab-use-after-free in l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 Read of size 8 at addr ffff8880241e9800 by task kworker/u9:0/54 CPU: 0 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-00268-g788220eee30d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Workqueue: hci2 hci_rx_work Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 l2cap_connect_req net/bluetooth/l2cap_core.c:4080 [inline] l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:4772 [inline] l2cap_sig_channel net/bluetooth/l2cap_core.c:5543 [inline] l2cap_recv_frame+0xf0b/0x8eb0 net/bluetooth/l2cap_core.c:6825 l2cap_recv_acldata+0x9b4/0xb70 net/bluetooth/l2cap_core.c:7514 hci_acldata_packet net/bluetooth/hci_core.c:3791 [inline] hci_rx_work+0xaab/0x1610 net/bluetooth/hci_core.c:4028 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 ... Freed by task 5245: 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:579 poison_slab_object+0xf7/0x160 mm/kasan/common.c:240 __kasan_slab_free+0x32/0x50 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2256 [inline] slab_free mm/slub.c:4477 [inline] kfree+0x12a/0x3b0 mm/slub.c:4598 l2cap_conn_free net/bluetooth/l2cap_core.c:1810 [inline] kref_put include/linux/kref.h:65 [inline] l2cap_conn_put net/bluetooth/l2cap_core.c:1822 [inline] l2cap_conn_del+0x59d/0x730 net/bluetooth/l2cap_core.c:1802 l2cap_connect_cfm+0x9e6/0xf80 net/bluetooth/l2cap_core.c:7241 hci_connect_cfm include/net/bluetooth/hci_core.h:1960 [inline] hci_conn_failed+0x1c3/0x370 net/bluetooth/hci_conn.c:1265 hci_abort_conn_sync+0x75a/0xb50 net/bluetooth/hci_sync.c:5583 abort_conn_sync+0x197/0x360 net/bluetooth/hci_conn.c:2917 hci_cmd_sync_work+0x1a4/0x410 net/bluetooth/hci_sync.c:328 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49951", "url": "https://ubuntu.com/security/CVE-2024-49951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Fix possible crash on mgmt_index_removed If mgmt_index_removed is called while there are commands queued on cmd_sync it could lead to crashes like the bellow trace: 0x0000053D: __list_del_entry_valid_or_report+0x98/0xdc 0x0000053D: mgmt_pending_remove+0x18/0x58 [bluetooth] 0x0000053E: mgmt_remove_adv_monitor_complete+0x80/0x108 [bluetooth] 0x0000053E: hci_cmd_sync_work+0xbc/0x164 [bluetooth] So while handling mgmt_index_removed this attempts to dequeue commands passed as user_data to cmd_sync.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49952", "url": "https://ubuntu.com/security/CVE-2024-49952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: prevent nf_skb_duplicated corruption syzbot found that nf_dup_ipv4() or nf_dup_ipv6() could write per-cpu variable nf_skb_duplicated in an unsafe way [1]. Disabling preemption as hinted by the splat is not enough, we have to disable soft interrupts as well. [1] BUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316 caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49 nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook+0x2c4/0x450 include/linux/netfilter.h:269 NF_HOOK_COND include/linux/netfilter.h:302 [inline] ip_output+0x185/0x230 net/ipv4/ip_output.c:433 ip_local_out net/ipv4/ip_output.c:129 [inline] ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495 udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981 udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737 __do_sys_sendmmsg net/socket.c:2766 [inline] __se_sys_sendmmsg net/socket.c:2763 [inline] __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763 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:0x7f4ce4f7def9 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:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9 RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006 RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49953", "url": "https://ubuntu.com/security/CVE-2024-49953", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix crash caused by calling __xfrm_state_delete() twice The km.state is not checked in driver's delayed work. When xfrm_state_check_expire() is called, the state can be reset to XFRM_STATE_EXPIRED, even if it is XFRM_STATE_DEAD already. This happens when xfrm state is deleted, but not freed yet. As __xfrm_state_delete() is called again in xfrm timer, the following crash occurs. To fix this issue, skip xfrm_state_check_expire() if km.state is not XFRM_STATE_VALID. Oops: general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] SMP CPU: 5 UID: 0 PID: 7448 Comm: kworker/u102:2 Not tainted 6.11.0-rc2+ #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5e_ipsec: eth%d mlx5e_ipsec_handle_sw_limits [mlx5_core] RIP: 0010:__xfrm_state_delete+0x3d/0x1b0 Code: 0f 84 8b 01 00 00 48 89 fd c6 87 c8 00 00 00 05 48 8d bb 40 10 00 00 e8 11 04 1a 00 48 8b 95 b8 00 00 00 48 8b 85 c0 00 00 00 <48> 89 42 08 48 89 10 48 8b 55 10 48 b8 00 01 00 00 00 00 ad de 48 RSP: 0018:ffff88885f945ec8 EFLAGS: 00010246 RAX: dead000000000122 RBX: ffffffff82afa940 RCX: 0000000000000036 RDX: dead000000000100 RSI: 0000000000000000 RDI: ffffffff82afb980 RBP: ffff888109a20340 R08: ffff88885f945ea0 R09: 0000000000000000 R10: 0000000000000000 R11: ffff88885f945ff8 R12: 0000000000000246 R13: ffff888109a20340 R14: ffff88885f95f420 R15: ffff88885f95f400 FS: 0000000000000000(0000) GS:ffff88885f940000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2163102430 CR3: 00000001128d6001 CR4: 0000000000370eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? die_addr+0x33/0x90 ? exc_general_protection+0x1a2/0x390 ? asm_exc_general_protection+0x22/0x30 ? __xfrm_state_delete+0x3d/0x1b0 ? __xfrm_state_delete+0x2f/0x1b0 xfrm_timer_handler+0x174/0x350 ? __xfrm_state_delete+0x1b0/0x1b0 __hrtimer_run_queues+0x121/0x270 hrtimer_run_softirq+0x88/0xd0 handle_softirqs+0xcc/0x270 do_softirq+0x3c/0x50 __local_bh_enable_ip+0x47/0x50 mlx5e_ipsec_handle_sw_limits+0x7d/0x90 [mlx5_core] process_one_work+0x137/0x2d0 worker_thread+0x28d/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50000", "url": "https://ubuntu.com/security/CVE-2024-50000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix NULL deref in mlx5e_tir_builder_alloc() In mlx5e_tir_builder_alloc() kvzalloc() may return NULL which is dereferenced on the next line in a reference to the modify field. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50001", "url": "https://ubuntu.com/security/CVE-2024-50001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix error path in multi-packet WQE transmit Remove the erroneous unmap in case no DMA mapping was established The multi-packet WQE transmit code attempts to obtain a DMA mapping for the skb. This could fail, e.g. under memory pressure, when the IOMMU driver just can't allocate more memory for page tables. While the code tries to handle this in the path below the err_unmap label it erroneously unmaps one entry from the sq's FIFO list of active mappings. Since the current map attempt failed this unmap is removing some random DMA mapping that might still be required. If the PCI function now presents that IOVA, the IOMMU may assumes a rogue DMA access and e.g. on s390 puts the PCI function in error state. The erroneous behavior was seen in a stress-test environment that created memory pressure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50179", "url": "https://ubuntu.com/security/CVE-2024-50179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: remove the incorrect Fw reference check when dirtying pages When doing the direct-io reads it will also try to mark pages dirty, but for the read path it won't hold the Fw caps and there is case will it get the Fw reference.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49963", "url": "https://ubuntu.com/security/CVE-2024-49963", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mailbox: bcm2835: Fix timeout during suspend mode During noirq suspend phase the Raspberry Pi power driver suffer of firmware property timeouts. The reason is that the IRQ of the underlying BCM2835 mailbox is disabled and rpi_firmware_property_list() will always run into a timeout [1]. Since the VideoCore side isn't consider as a wakeup source, set the IRQF_NO_SUSPEND flag for the mailbox IRQ in order to keep it enabled during suspend-resume cycle. [1] PM: late suspend of devices complete after 1.754 msecs WARNING: CPU: 0 PID: 438 at drivers/firmware/raspberrypi.c:128 rpi_firmware_property_list+0x204/0x22c Firmware transaction 0x00028001 timeout Modules linked in: CPU: 0 PID: 438 Comm: bash Tainted: G C 6.9.3-dirty #17 Hardware name: BCM2835 Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x44 dump_stack_lvl from __warn+0x88/0xec __warn from warn_slowpath_fmt+0x7c/0xb0 warn_slowpath_fmt from rpi_firmware_property_list+0x204/0x22c rpi_firmware_property_list from rpi_firmware_property+0x68/0x8c rpi_firmware_property from rpi_firmware_set_power+0x54/0xc0 rpi_firmware_set_power from _genpd_power_off+0xe4/0x148 _genpd_power_off from genpd_sync_power_off+0x7c/0x11c genpd_sync_power_off from genpd_finish_suspend+0xcc/0xe0 genpd_finish_suspend from dpm_run_callback+0x78/0xd0 dpm_run_callback from device_suspend_noirq+0xc0/0x238 device_suspend_noirq from dpm_suspend_noirq+0xb0/0x168 dpm_suspend_noirq from suspend_devices_and_enter+0x1b8/0x5ac suspend_devices_and_enter from pm_suspend+0x254/0x2e4 pm_suspend from state_store+0xa8/0xd4 state_store from kernfs_fop_write_iter+0x154/0x1a0 kernfs_fop_write_iter from vfs_write+0x12c/0x184 vfs_write from ksys_write+0x78/0xc0 ksys_write from ret_fast_syscall+0x0/0x54 Exception stack(0xcc93dfa8 to 0xcc93dff0) [...] PM: noirq suspend of devices complete after 3095.584 msecs", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49954", "url": "https://ubuntu.com/security/CVE-2024-49954", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: static_call: Replace pointless WARN_ON() in static_call_module_notify() static_call_module_notify() triggers a WARN_ON(), when memory allocation fails in __static_call_add_module(). That's not really justified, because the failure case must be correctly handled by the well known call chain and the error code is passed through to the initiating userspace application. A memory allocation fail is not a fatal problem, but the WARN_ON() takes the machine out when panic_on_warn is set. Replace it with a pr_warn().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50002", "url": "https://ubuntu.com/security/CVE-2024-50002", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: static_call: Handle module init failure correctly in static_call_del_module() Module insertion invokes static_call_add_module() to initialize the static calls in a module. static_call_add_module() invokes __static_call_init(), which allocates a struct static_call_mod to either encapsulate the built-in static call sites of the associated key into it so further modules can be added or to append the module to the module chain. If that allocation fails the function returns with an error code and the module core invokes static_call_del_module() to clean up eventually added static_call_mod entries. This works correctly, when all keys used by the module were converted over to a module chain before the failure. If not then static_call_del_module() causes a #GP as it blindly assumes that key::mods points to a valid struct static_call_mod. The problem is that key::mods is not a individual struct member of struct static_call_key, it's part of a union to save space: union { /* bit 0: 0 = mods, 1 = sites */ unsigned long type; struct static_call_mod *mods; struct static_call_site *sites; \t}; key::sites is a pointer to the list of built-in usage sites of the static call. The type of the pointer is differentiated by bit 0. A mods pointer has the bit clear, the sites pointer has the bit set. As static_call_del_module() blidly assumes that the pointer is a valid static_call_mod type, it fails to check for this failure case and dereferences the pointer to the list of built-in call sites, which is obviously bogus. Cure it by checking whether the key has a sites or a mods pointer. If it's a sites pointer then the key is not to be touched. As the sites are walked in the same order as in __static_call_init() the site walk can be terminated because all subsequent sites have not been touched by the init code due to the error exit. If it was converted before the allocation fail, then the inner loop which searches for a module match will find nothing. A fail in the second allocation in __static_call_init() is harmless and does not require special treatment. The first allocation succeeded and converted the key to a module chain. That first entry has mod::mod == NULL and mod::next == NULL, so the inner loop of static_call_del_module() will neither find a module match nor a module chain. The next site in the walk was either already converted, but can't match the module, or it will exit the outer loop because it has a static_call_site pointer and not a static_call_mod pointer.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-47675", "url": "https://ubuntu.com/security/CVE-2024-47675", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix use-after-free in bpf_uprobe_multi_link_attach() If bpf_link_prime() fails, bpf_uprobe_multi_link_attach() goes to the error_free label and frees the array of bpf_uprobe's without calling bpf_uprobe_unregister(). This leaks bpf_uprobe->uprobe and worse, this frees bpf_uprobe->consumer without removing it from the uprobe->consumers list.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47676", "url": "https://ubuntu.com/security/CVE-2024-47676", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb.c: fix UAF of vma in hugetlb fault pathway Syzbot reports a UAF in hugetlb_fault(). This happens because vmf_anon_prepare() could drop the per-VMA lock and allow the current VMA to be freed before hugetlb_vma_unlock_read() is called. We can fix this by using a modified version of vmf_anon_prepare() that doesn't release the VMA lock on failure, and then release it ourselves after hugetlb_vma_unlock_read().", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47677", "url": "https://ubuntu.com/security/CVE-2024-47677", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: resolve memory leak from exfat_create_upcase_table() If exfat_load_upcase_table reaches end and returns -EINVAL, allocated memory doesn't get freed and while exfat_load_default_upcase_table allocates more memory, leading to a memory leak. Here's link to syzkaller crash report illustrating this issue: https://syzkaller.appspot.com/text?tag=CrashReport&x=1406c201980000", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47725", "url": "https://ubuntu.com/security/CVE-2024-47725", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47739", "url": "https://ubuntu.com/security/CVE-2024-47739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: padata: use integer wrap around to prevent deadlock on seq_nr overflow When submitting more than 2^32 padata objects to padata_do_serial, the current sorting implementation incorrectly sorts padata objects with overflowed seq_nr, causing them to be placed before existing objects in the reorder list. This leads to a deadlock in the serialization process as padata_find_next cannot match padata->seq_nr and pd->processed because the padata instance with overflowed seq_nr will be selected next. To fix this, we use an unsigned integer wrap around to correctly sort padata objects in scenarios with integer overflow.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47678", "url": "https://ubuntu.com/security/CVE-2024-47678", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: icmp: change the order of rate limits ICMP messages are ratelimited : After the blamed commits, the two rate limiters are applied in this order: 1) host wide ratelimit (icmp_global_allow()) 2) Per destination ratelimit (inetpeer based) In order to avoid side-channels attacks, we need to apply the per destination check first. This patch makes the following change : 1) icmp_global_allow() checks if the host wide limit is reached. But credits are not yet consumed. This is deferred to 3) 2) The per destination limit is checked/updated. This might add a new node in inetpeer tree. 3) icmp_global_consume() consumes tokens if prior operations succeeded. This means that host wide ratelimit is still effective in keeping inetpeer tree small even under DDOS. As a bonus, I removed icmp_global.lock as the fast path can use a lock-free operation.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47733", "url": "https://ubuntu.com/security/CVE-2024-47733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfs: Delete subtree of 'fs/netfs' when netfs module exits In netfs_init() or fscache_proc_init(), we create dentry under 'fs/netfs', but in netfs_exit(), we only delete the proc entry of 'fs/netfs' without deleting its subtree. This triggers the following WARNING: ================================================================== remove_proc_entry: removing non-empty directory 'fs/netfs', leaking at least 'requests' WARNING: CPU: 4 PID: 566 at fs/proc/generic.c:717 remove_proc_entry+0x160/0x1c0 Modules linked in: netfs(-) CPU: 4 UID: 0 PID: 566 Comm: rmmod Not tainted 6.11.0-rc3 #860 RIP: 0010:remove_proc_entry+0x160/0x1c0 Call Trace: netfs_exit+0x12/0x620 [netfs] __do_sys_delete_module.isra.0+0x14c/0x2e0 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e ================================================================== Therefore use remove_proc_subtree() instead of remove_proc_entry() to fix the above problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47679", "url": "https://ubuntu.com/security/CVE-2024-47679", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfs: fix race between evice_inodes() and find_inode()&iput() Hi, all Recently I noticed a bug[1] in btrfs, after digged it into and I believe it'a race in vfs. Let's assume there's a inode (ie ino 261) with i_count 1 is called by iput(), and there's a concurrent thread calling generic_shutdown_super(). cpu0: cpu1: iput() // i_count is 1 ->spin_lock(inode) ->dec i_count to 0 ->iput_final() generic_shutdown_super() ->__inode_add_lru() ->evict_inodes() // cause some reason[2] ->if (atomic_read(inode->i_count)) continue; // return before // inode 261 passed the above check // list_lru_add_obj() // and then schedule out ->spin_unlock() // note here: the inode 261 // was still at sb list and hash list, // and I_FREEING|I_WILL_FREE was not been set btrfs_iget() // after some function calls ->find_inode() // found the above inode 261 ->spin_lock(inode) // check I_FREEING|I_WILL_FREE // and passed ->__iget() ->spin_unlock(inode) // schedule back ->spin_lock(inode) // check (I_NEW|I_FREEING|I_WILL_FREE) flags, // passed and set I_FREEING iput() ->spin_unlock(inode) ->spin_lock(inode)\t\t\t ->evict() // dec i_count to 0 ->iput_final() ->spin_unlock() ->evict() Now, we have two threads simultaneously evicting the same inode, which may trigger the BUG(inode->i_state & I_CLEAR) statement both within clear_inode() and iput(). To fix the bug, recheck the inode->i_count after holding i_lock. Because in the most scenarios, the first check is valid, and the overhead of spin_lock() can be reduced. If there is any misunderstanding, please let me know, thanks. [1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/ [2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable() return false when I reproduced the bug.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49859", "url": "https://ubuntu.com/security/CVE-2024-49859", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to check atomic_file in f2fs ioctl interfaces Some f2fs ioctl interfaces like f2fs_ioc_set_pin_file(), f2fs_move_file_range(), and f2fs_defragment_range() missed to check atomic_write status, which may cause potential race issue, fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47680", "url": "https://ubuntu.com/security/CVE-2024-47680", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: check discard support for conventional zones As the helper function f2fs_bdev_support_discard() shows, f2fs checks if the target block devices support discard by calling bdev_max_discard_sectors() and bdev_is_zoned(). This check works well for most cases, but it does not work for conventional zones on zoned block devices. F2fs assumes that zoned block devices support discard, and calls __submit_discard_cmd(). When __submit_discard_cmd() is called for sequential write required zones, it works fine since __submit_discard_cmd() issues zone reset commands instead of discard commands. However, when __submit_discard_cmd() is called for conventional zones, __blkdev_issue_discard() is called even when the devices do not support discard. The inappropriate __blkdev_issue_discard() call was not a problem before the commit 30f1e7241422 (\"block: move discard checks into the ioctl handler\") because __blkdev_issue_discard() checked if the target devices support discard or not. If not, it returned EOPNOTSUPP. After the commit, __blkdev_issue_discard() no longer checks it. It always returns zero and sets NULL to the given bio pointer. This NULL pointer triggers f2fs_bug_on() in __submit_discard_cmd(). The BUG is recreated with the commands below at the umount step, where /dev/nullb0 is a zoned null_blk with 5GB total size, 128MB zone size and 10 conventional zones. $ mkfs.f2fs -f -m /dev/nullb0 $ mount /dev/nullb0 /mnt $ for ((i=0;i<5;i++)); do dd if=/dev/zero of=/mnt/test bs=65536 count=1600 conv=fsync; done $ umount /mnt To fix the BUG, avoid the inappropriate __blkdev_issue_discard() call. When discard is requested for conventional zones, check if the device supports discard or not. If not, return EOPNOTSUPP.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47740", "url": "https://ubuntu.com/security/CVE-2024-47740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: Require FMODE_WRITE for atomic write ioctls The F2FS ioctls for starting and committing atomic writes check for inode_owner_or_capable(), but this does not give LSMs like SELinux or Landlock an opportunity to deny the write access - if the caller's FSUID matches the inode's UID, inode_owner_or_capable() immediately returns true. There are scenarios where LSMs want to deny a process the ability to write particular files, even files that the FSUID of the process owns; but this can currently partially be bypassed using atomic write ioctls in two ways: - F2FS_IOC_START_ATOMIC_REPLACE + F2FS_IOC_COMMIT_ATOMIC_WRITE can truncate an inode to size 0 - F2FS_IOC_START_ATOMIC_WRITE + F2FS_IOC_ABORT_ATOMIC_WRITE can revert changes another process concurrently made to a file Fix it by requiring FMODE_WRITE for these operations, just like for F2FS_IOC_MOVE_RANGE. Since any legitimate caller should only be using these ioctls when intending to write into the file, that seems unlikely to break anything.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47726", "url": "https://ubuntu.com/security/CVE-2024-47726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to wait dio completion It should wait all existing dio write IOs before block removal, otherwise, previous direct write IO may overwrite data in the block which may be reused by other inode.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47741", "url": "https://ubuntu.com/security/CVE-2024-47741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race setting file private on concurrent lseek using same fd When doing concurrent lseek(2) system calls against the same file descriptor, using multiple threads belonging to the same process, we have a short time window where a race happens and can result in a memory leak. The race happens like this: 1) A program opens a file descriptor for a file and then spawns two threads (with the pthreads library for example), lets call them task A and task B; 2) Task A calls lseek with SEEK_DATA or SEEK_HOLE and ends up at file.c:find_desired_extent() while holding a read lock on the inode; 3) At the start of find_desired_extent(), it extracts the file's private_data pointer into a local variable named 'private', which has a value of NULL; 4) Task B also calls lseek with SEEK_DATA or SEEK_HOLE, locks the inode in shared mode and enters file.c:find_desired_extent(), where it also extracts file->private_data into its local variable 'private', which has a NULL value; 5) Because it saw a NULL file private, task A allocates a private structure and assigns to the file structure; 6) Task B also saw a NULL file private so it also allocates its own file private and then assigns it to the same file structure, since both tasks are using the same file descriptor. At this point we leak the private structure allocated by task A. Besides the memory leak, there's also the detail that both tasks end up using the same cached state record in the private structure (struct btrfs_file_private::llseek_cached_state), which can result in a use-after-free problem since one task can free it while the other is still using it (only one task took a reference count on it). Also, sharing the cached state is not a good idea since it could result in incorrect results in the future - right now it should not be a problem because it end ups being used only in extent-io-tree.c:count_range_bits() where we do range validation before using the cached state. Fix this by protecting the private assignment and check of a file while holding the inode's spinlock and keep track of the task that allocated the private, so that it's used only by that task in order to prevent user-after-free issues with the cached state record as well as potentially using it incorrectly in the future.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47681", "url": "https://ubuntu.com/security/CVE-2024-47681", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix NULL pointer dereference in mt7996_mcu_sta_bfer_he Fix the NULL pointer dereference in mt7996_mcu_sta_bfer_he routine adding an sta interface to the mt7996 driver. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49858", "url": "https://ubuntu.com/security/CVE-2024-49858", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption The TPM event log table is a Linux specific construct, where the data produced by the GetEventLog() boot service is cached in memory, and passed on to the OS using an EFI configuration table. The use of EFI_LOADER_DATA here results in the region being left unreserved in the E820 memory map constructed by the EFI stub, and this is the memory description that is passed on to the incoming kernel by kexec, which is therefore unaware that the region should be reserved. Even though the utility of the TPM2 event log after a kexec is questionable, any corruption might send the parsing code off into the weeds and crash the kernel. So let's use EFI_ACPI_RECLAIM_MEMORY instead, which is always treated as reserved by the E820 conversion logic.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49860", "url": "https://ubuntu.com/security/CVE-2024-49860", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: sysfs: validate return type of _STR method Only buffer objects are valid return values of _STR. If something else is returned description_show() will access invalid memory.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47742", "url": "https://ubuntu.com/security/CVE-2024-47742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware_loader: Block path traversal Most firmware names are hardcoded strings, or are constructed from fairly constrained format strings where the dynamic parts are just some hex numbers or such. However, there are a couple codepaths in the kernel where firmware file names contain string components that are passed through from a device or semi-privileged userspace; the ones I could find (not counting interfaces that require root privileges) are: - lpfc_sli4_request_firmware_update() seems to construct the firmware filename from \"ModelName\", a string that was previously parsed out of some descriptor (\"Vital Product Data\") in lpfc_fill_vpd() - nfp_net_fw_find() seems to construct a firmware filename from a model name coming from nfp_hwinfo_lookup(pf->hwinfo, \"nffw.partno\"), which I think parses some descriptor that was read from the device. (But this case likely isn't exploitable because the format string looks like \"netronome/nic_%s\", and there shouldn't be any *folders* starting with \"netronome/nic_\". The previous case was different because there, the \"%s\" is *at the start* of the format string.) - module_flash_fw_schedule() is reachable from the ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is enough to pass the privilege check), and takes a userspace-provided firmware name. (But I think to reach this case, you need to have CAP_NET_ADMIN over a network namespace that a special kind of ethernet device is mapped into, so I think this is not a viable attack path in practice.) Fix it by rejecting any firmware names containing \"..\" path components. For what it's worth, I went looking and haven't found any USB device drivers that use the firmware loader dangerously.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47682", "url": "https://ubuntu.com/security/CVE-2024-47682", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sd: Fix off-by-one error in sd_read_block_characteristics() Ff the device returns page 0xb1 with length 8 (happens with qemu v2.x, for example), sd_read_block_characteristics() may attempt an out-of-bounds memory access when accessing the zoned field at offset 8.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47743", "url": "https://ubuntu.com/security/CVE-2024-47743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: prevent NULL pointer dereference in find_asymmetric_key() In find_asymmetric_key(), if all NULLs are passed in the id_{0,1,2} arguments, the kernel will first emit WARN but then have an oops because id_2 gets dereferenced anyway. Add the missing id_2 check and move WARN_ON() to the final else branch to avoid duplicate NULL checks. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47727", "url": "https://ubuntu.com/security/CVE-2024-47727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/tdx: Fix \"in-kernel MMIO\" check TDX only supports kernel-initiated MMIO operations. The handle_mmio() function checks if the #VE exception occurred in the kernel and rejects the operation if it did not. However, userspace can deceive the kernel into performing MMIO on its behalf. For example, if userspace can point a syscall to an MMIO address, syscall does get_user() or put_user() on it, triggering MMIO #VE. The kernel will treat the #VE as in-kernel MMIO. Ensure that the target MMIO address is within the kernel before decoding instruction.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47744", "url": "https://ubuntu.com/security/CVE-2024-47744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Use dedicated mutex to protect kvm_usage_count to avoid deadlock Use a dedicated mutex to guard kvm_usage_count to fix a potential deadlock on x86 due to a chain of locks and SRCU synchronizations. Translating the below lockdep splat, CPU1 #6 will wait on CPU0 #1, CPU0 #8 will wait on CPU2 #3, and CPU2 #7 will wait on CPU1 #4 (if there's a writer, due to the fairness of r/w semaphores). CPU0 CPU1 CPU2 1 lock(&kvm->slots_lock); 2 lock(&vcpu->mutex); 3 lock(&kvm->srcu); 4 lock(cpu_hotplug_lock); 5 lock(kvm_lock); 6 lock(&kvm->slots_lock); 7 lock(cpu_hotplug_lock); 8 sync(&kvm->srcu); Note, there are likely more potential deadlocks in KVM x86, e.g. the same pattern of taking cpu_hotplug_lock outside of kvm_lock likely exists with __kvmclock_cpufreq_notifier(): cpuhp_cpufreq_online() | -> cpufreq_online() | -> cpufreq_gov_performance_limits() | -> __cpufreq_driver_target() | -> __target_index() | -> cpufreq_freq_transition_begin() | -> cpufreq_notify_transition() | -> ... __kvmclock_cpufreq_notifier() But, actually triggering such deadlocks is beyond rare due to the combination of dependencies and timings involved. E.g. the cpufreq notifier is only used on older CPUs without a constant TSC, mucking with the NX hugepage mitigation while VMs are running is very uncommon, and doing so while also onlining/offlining a CPU (necessary to generate contention on cpu_hotplug_lock) would be even more unusual. The most robust solution to the general cpu_hotplug_lock issue is likely to switch vm_list to be an RCU-protected list, e.g. so that x86's cpufreq notifier doesn't to take kvm_lock. For now, settle for fixing the most blatant deadlock, as switching to an RCU-protected list is a much more involved change, but add a comment in locking.rst to call out that care needs to be taken when walking holding kvm_lock and walking vm_list. ====================================================== WARNING: possible circular locking dependency detected 6.10.0-smp--c257535a0c9d-pip #330 Tainted: G S O ------------------------------------------------------ tee/35048 is trying to acquire lock: ff6a80eced71e0a8 (&kvm->slots_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x179/0x1e0 [kvm] but task is already holding lock: ffffffffc07abb08 (kvm_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x14a/0x1e0 [kvm] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (kvm_lock){+.+.}-{3:3}: __mutex_lock+0x6a/0xb40 mutex_lock_nested+0x1f/0x30 kvm_dev_ioctl+0x4fb/0xe50 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #2 (cpu_hotplug_lock){++++}-{0:0}: cpus_read_lock+0x2e/0xb0 static_key_slow_inc+0x16/0x30 kvm_lapic_set_base+0x6a/0x1c0 [kvm] kvm_set_apic_base+0x8f/0xe0 [kvm] kvm_set_msr_common+0x9ae/0xf80 [kvm] vmx_set_msr+0xa54/0xbe0 [kvm_intel] __kvm_set_msr+0xb6/0x1a0 [kvm] kvm_arch_vcpu_ioctl+0xeca/0x10c0 [kvm] kvm_vcpu_ioctl+0x485/0x5b0 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (&kvm->srcu){.+.+}-{0:0}: __synchronize_srcu+0x44/0x1a0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47719", "url": "https://ubuntu.com/security/CVE-2024-47719", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommufd: Protect against overflow of ALIGN() during iova allocation Userspace can supply an iova and uptr such that the target iova alignment becomes really big and ALIGN() overflows which corrupts the selected area range during allocation. CONFIG_IOMMUFD_TEST can detect this: WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline] WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352 Modules linked in: CPU: 1 PID: 5092 Comm: syz-executor294 Not tainted 6.10.0-rc5-syzkaller-00294-g3ffea9a7a6f7 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024 RIP: 0010:iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline] RIP: 0010:iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352 Code: fc e9 a4 f3 ff ff e8 1a 8b 4c fc 41 be e4 ff ff ff e9 8a f3 ff ff e8 0a 8b 4c fc 90 0f 0b 90 e9 37 f5 ff ff e8 fc 8a 4c fc 90 <0f> 0b 90 e9 68 f3 ff ff 48 c7 c1 ec 82 ad 8f 80 e1 07 80 c1 03 38 RSP: 0018:ffffc90003ebf9e0 EFLAGS: 00010293 RAX: ffffffff85499fa4 RBX: 00000000ffffffef RCX: ffff888079b49e00 RDX: 0000000000000000 RSI: 00000000ffffffef RDI: 0000000000000000 RBP: ffffc90003ebfc50 R08: ffffffff85499b30 R09: ffffffff85499942 R10: 0000000000000002 R11: ffff888079b49e00 R12: ffff8880228e0010 R13: 0000000000000000 R14: 1ffff920007d7f68 R15: ffffc90003ebfd00 FS: 000055557d760380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000005fdeb8 CR3: 000000007404a000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: iommufd_ioas_copy+0x610/0x7b0 drivers/iommu/iommufd/ioas.c:274 iommufd_fops_ioctl+0x4d9/0x5a0 drivers/iommu/iommufd/main.c:421 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Cap the automatic alignment to the huge page size, which is probably a better idea overall. Huge automatic alignments can fragment and chew up the available IOVA space without any reason.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47745", "url": "https://ubuntu.com/security/CVE-2024-47745", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: call the security_mmap_file() LSM hook in remap_file_pages() The remap_file_pages syscall handler calls do_mmap() directly, which doesn't contain the LSM security check. And if the process has called personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for RW pages, this will actually result in remapping the pages to RWX, bypassing a W^X policy enforced by SELinux. So we should check prot by security_mmap_file LSM hook in the remap_file_pages syscall handler before do_mmap() is called. Otherwise, it potentially permits an attacker to bypass a W^X policy enforced by SELinux. The bypass is similar to CVE-2016-10044, which bypass the same thing via AIO and can be found in [1]. The PoC: $ cat > test.c int main(void) { \tsize_t pagesz = sysconf(_SC_PAGE_SIZE); \tint mfd = syscall(SYS_memfd_create, \"test\", 0); \tconst char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE, \t\tMAP_SHARED, mfd, 0); \tunsigned int old = syscall(SYS_personality, 0xffffffff); \tsyscall(SYS_personality, READ_IMPLIES_EXEC | old); \tsyscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0); \tsyscall(SYS_personality, old); \t// show the RWX page exists even if W^X policy is enforced \tint fd = open(\"/proc/self/maps\", O_RDONLY); \tunsigned char buf2[1024]; \twhile (1) { \t\tint ret = read(fd, buf2, 1024); \t\tif (ret <= 0) break; \t\twrite(1, buf2, ret); \t} \tclose(fd); } $ gcc test.c -o test $ ./test | grep rwx 7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted) [PM: subject line tweaks]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47746", "url": "https://ubuntu.com/security/CVE-2024-47746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: use exclusive lock when FUSE_I_CACHE_IO_MODE is set This may be a typo. The comment has said shared locks are not allowed when this bit is set. If using shared lock, the wait in `fuse_file_cached_io_open` may be forever.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47734", "url": "https://ubuntu.com/security/CVE-2024-47734", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: Fix unnecessary warnings and logs from bond_xdp_get_xmit_slave() syzbot reported a WARNING in bond_xdp_get_xmit_slave. To reproduce this[1], one bond device (bond1) has xdpdrv, which increases bpf_master_redirect_enabled_key. Another bond device (bond0) which is unsupported by XDP but its slave (veth3) has xdpgeneric that returns XDP_TX. This triggers WARN_ON_ONCE() from the xdp_master_redirect(). To reduce unnecessary warnings and improve log management, we need to delete the WARN_ON_ONCE() and add ratelimit to the netdev_err(). [1] Steps to reproduce: # Needs tx_xdp with return XDP_TX; ip l add veth0 type veth peer veth1 ip l add veth3 type veth peer veth4 ip l add bond0 type bond mode 6 # BOND_MODE_ALB, unsupported by XDP ip l add bond1 type bond # BOND_MODE_ROUNDROBIN by default ip l set veth0 master bond1 ip l set bond1 up # Increases bpf_master_redirect_enabled_key ip l set dev bond1 xdpdrv object tx_xdp.o section xdp_tx ip l set veth3 master bond0 ip l set bond0 up ip l set veth4 up # Triggers WARN_ON_ONCE() from the xdp_master_redirect() ip l set veth3 xdpgeneric object tx_xdp.o section xdp_tx", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47684", "url": "https://ubuntu.com/security/CVE-2024-47684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: check skb is non-NULL in tcp_rto_delta_us() We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic kernel that are running ceph and recently hit a null ptr dereference in tcp_rearm_rto(). Initially hitting it from the TLP path, but then later we also saw it getting hit from the RACK case as well. Here are examples of the oops messages we saw in each of those cases: Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020 Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode Jul 26 15:05:02 rx [11061395.792971] #PF: error_code(0x0000) - not-present page Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0 Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI Jul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu Jul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023 Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 <48> 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3 Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246 Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000 Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60 Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8 Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900 Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30 Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000 Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0 Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554 Jul 26 15:05:02 rx [11061395.916786] Call Trace: Jul 26 15:05:02 rx [11061395.919488] Jul 26 15:05:02 rx [11061395.921765] ? show_regs.cold+0x1a/0x1f Jul 26 15:05:02 rx [11061395.925859] ? __die+0x90/0xd9 Jul 26 15:05:02 rx [11061395.929169] ? no_context+0x196/0x380 Jul 26 15:05:02 rx [11061395.933088] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0 Jul 26 15:05:02 rx [11061395.938216] ? ip6_sublist_rcv_finish+0x3d/0x50 Jul 26 15:05:02 rx [11061395.943000] ? __bad_area_nosemaphore+0x50/0x1a0 Jul 26 15:05:02 rx [11061395.947873] ? bad_area_nosemaphore+0x16/0x20 Jul 26 15:05:02 rx [11061395.952486] ? do_user_addr_fault+0x267/0x450 Jul 26 15:05:02 rx [11061395.957104] ? ipv6_list_rcv+0x112/0x140 Jul 26 15:05:02 rx [11061395.961279] ? __do_page_fault+0x58/0x90 Jul 26 15:05:02 rx [11061395.965458] ? do_page_fault+0x2c/0xe0 Jul 26 15:05:02 rx [11061395.969465] ? page_fault+0x34/0x40 Jul 26 15:05:02 rx [11061395.973217] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.977313] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.981408] tcp_send_loss_probe+0x10b/0x220 Jul 26 15:05:02 rx [11061395.985937] tcp_write_timer_handler+0x1b4/0x240 Jul 26 15:05:02 rx [11061395.990809] tcp_write_timer+0x9e/0xe0 Jul 26 15:05:02 rx [11061395.994814] ? tcp_write_timer_handler+0x240/0x240 Jul 26 15:05:02 rx [11061395.999866] call_timer_fn+0x32/0x130 Jul 26 15:05:02 rx [11061396.003782] __run_timers.part.0+0x180/0x280 Jul 26 15:05:02 rx [11061396.008309] ? recalibrate_cpu_khz+0x10/0x10 Jul 26 15:05:02 rx [11061396.012841] ? native_x2apic_icr_write+0x30/0x30 Jul 26 15:05:02 rx [11061396.017718] ? lapic_next_even ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47747", "url": "https://ubuntu.com/security/CVE-2024-47747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race Condition In the ether3_probe function, a timer is initialized with a callback function ether3_ledoff, bound to &prev(dev)->timer. Once the timer is started, there is a risk of a race condition if the module or device is removed, triggering the ether3_remove function to perform cleanup. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | ether3_ledoff ether3_remove | free_netdev(dev); | put_devic | kfree(dev); | | ether3_outw(priv(dev)->regs.config2 |= CFG2_CTRLO, REG_CONFIG2); | // use dev Fix it by ensuring that the timer is canceled before proceeding with the cleanup in ether3_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47685", "url": "https://ubuntu.com/security/CVE-2024-47685", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put() syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending garbage on the four reserved tcp bits (th->res1) Use skb_put_zero() to clear the whole TCP header, as done in nf_reject_ip_tcphdr_put() BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5661 [inline] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775 process_backlog+0x4ad/0xa50 net/core/dev.c:6108 __napi_poll+0xe7/0x980 net/core/dev.c:6772 napi_poll net/core/dev.c:6841 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963 handle_softirqs+0x1ce/0x800 kernel/softirq.c:554 __do_softirq+0x14/0x1a kernel/softirq.c:588 do_softirq+0x9a/0x100 kernel/softirq.c:455 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline] __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450 dev_queue_xmit include/linux/netdevice.h:3105 [inline] neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366 inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135 __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143 tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333 __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679 inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750 __sys_connect_file net/socket.c:2061 [inline] __sys_connect+0x606/0x690 net/socket.c:2078 __do_sys_connect net/socket.c:2088 [inline] __se_sys_connect net/socket.c:2085 [inline] __x64_sys_connect+0x91/0xe0 net/socket.c:2085 x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43 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 Uninit was stored to memory at: nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47686", "url": "https://ubuntu.com/security/CVE-2024-47686", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ep93xx: clock: Fix off by one in ep93xx_div_recalc_rate() The psc->div[] array has psc->num_div elements. These values come from when we call clk_hw_register_div(). It's adc_divisors and ARRAY_SIZE(adc_divisors)) and so on. So this condition needs to be >= instead of > to prevent an out of bounds read.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47748", "url": "https://ubuntu.com/security/CVE-2024-47748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost_vdpa: assign irq bypass producer token correctly We used to call irq_bypass_unregister_producer() in vhost_vdpa_setup_vq_irq() which is problematic as we don't know if the token pointer is still valid or not. Actually, we use the eventfd_ctx as the token so the life cycle of the token should be bound to the VHOST_SET_VRING_CALL instead of vhost_vdpa_setup_vq_irq() which could be called by set_status(). Fixing this by setting up irq bypass producer's token when handling VHOST_SET_VRING_CALL and un-registering the producer before calling vhost_vring_ioctl() to prevent a possible use after free as eventfd could have been released in vhost_vring_ioctl(). And such registering and unregistering will only be done if DRIVER_OK is set.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47687", "url": "https://ubuntu.com/security/CVE-2024-47687", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa/mlx5: Fix invalid mr resource destroy Certain error paths from mlx5_vdpa_dev_add() can end up releasing mr resources which never got initialized in the first place. This patch adds the missing check in mlx5_vdpa_destroy_mr_resources() to block releasing non-initialized mr resources. Reference trace: mlx5_core 0000:08:00.2: mlx5_vdpa_dev_add:3274:(pid 2700) warning: No mac address provisioned? BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 140216067 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 8 PID: 2700 Comm: vdpa Kdump: loaded Not tainted 5.14.0-496.el9.x86_64 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:vhost_iotlb_del_range+0xf/0xe0 [vhost_iotlb] Code: [...] RSP: 0018:ff1c823ac23077f0 EFLAGS: 00010246 RAX: ffffffffc1a21a60 RBX: ffffffff899567a0 RCX: 0000000000000000 RDX: ffffffffffffffff RSI: 0000000000000000 RDI: 0000000000000000 RBP: ff1bda1f7c21e800 R08: 0000000000000000 R09: ff1c823ac2307670 R10: ff1c823ac2307668 R11: ffffffff8a9e7b68 R12: 0000000000000000 R13: 0000000000000000 R14: ff1bda1f43e341a0 R15: 00000000ffffffea FS: 00007f56eba7c740(0000) GS:ff1bda269f800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000104d90001 CR4: 0000000000771ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? mlx5_vdpa_free+0x3d/0x150 [mlx5_vdpa] ? __die_body.cold+0x8/0xd ? page_fault_oops+0x134/0x170 ? __irq_work_queue_local+0x2b/0xc0 ? irq_work_queue+0x2c/0x50 ? exc_page_fault+0x62/0x150 ? asm_exc_page_fault+0x22/0x30 ? __pfx_mlx5_vdpa_free+0x10/0x10 [mlx5_vdpa] ? vhost_iotlb_del_range+0xf/0xe0 [vhost_iotlb] mlx5_vdpa_free+0x3d/0x150 [mlx5_vdpa] vdpa_release_dev+0x1e/0x50 [vdpa] device_release+0x31/0x90 kobject_cleanup+0x37/0x130 mlx5_vdpa_dev_add+0x2d2/0x7a0 [mlx5_vdpa] vdpa_nl_cmd_dev_add_set_doit+0x277/0x4c0 [vdpa] genl_family_rcv_msg_doit+0xd9/0x130 genl_family_rcv_msg+0x14d/0x220 ? __pfx_vdpa_nl_cmd_dev_add_set_doit+0x10/0x10 [vdpa] ? _copy_to_user+0x1a/0x30 ? move_addr_to_user+0x4b/0xe0 genl_rcv_msg+0x47/0xa0 ? __import_iovec+0x46/0x150 ? __pfx_genl_rcv_msg+0x10/0x10 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x245/0x370 netlink_sendmsg+0x206/0x440 __sys_sendto+0x1dc/0x1f0 ? do_read_fault+0x10c/0x1d0 ? do_pte_missing+0x10d/0x190 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x5c/0xf0 ? __count_memcg_events+0x4f/0xb0 ? mm_account_fault+0x6c/0x100 ? handle_mm_fault+0x116/0x270 ? do_user_addr_fault+0x1d6/0x6a0 ? do_syscall_64+0x6b/0xf0 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 entry_SYSCALL_64_after_hwframe+0x78/0x80", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47688", "url": "https://ubuntu.com/security/CVE-2024-47688", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: driver core: Fix a potential null-ptr-deref in module_add_driver() Inject fault while probing of-fpga-region, if kasprintf() fails in module_add_driver(), the second sysfs_remove_link() in exit path will cause null-ptr-deref as below because kernfs_name_hash() will call strlen() with NULL driver_name. Fix it by releasing resources based on the exit path sequence. \t KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] \t Mem abort info: \t ESR = 0x0000000096000005 \t EC = 0x25: DABT (current EL), IL = 32 bits \t SET = 0, FnV = 0 \t EA = 0, S1PTW = 0 \t FSC = 0x05: level 1 translation fault \t Data abort info: \t ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 \t CM = 0, WnR = 0, TnD = 0, TagAccess = 0 \t GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 \t [dfffffc000000000] address between user and kernel address ranges \t Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP \t Dumping ftrace buffer: \t (ftrace buffer empty) \t Modules linked in: of_fpga_region(+) fpga_region fpga_bridge cfg80211 rfkill 8021q garp mrp stp llc ipv6 [last unloaded: of_fpga_region] \t CPU: 2 UID: 0 PID: 2036 Comm: modprobe Not tainted 6.11.0-rc2-g6a0e38264012 #295 \t Hardware name: linux,dummy-virt (DT) \t pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) \t pc : strlen+0x24/0xb0 \t lr : kernfs_name_hash+0x1c/0xc4 \t sp : ffffffc081f97380 \t x29: ffffffc081f97380 x28: ffffffc081f97b90 x27: ffffff80c821c2a0 \t x26: ffffffedac0be418 x25: 0000000000000000 x24: ffffff80c09d2000 \t x23: 0000000000000000 x22: 0000000000000000 x21: 0000000000000000 \t x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000001840 \t x17: 0000000000000000 x16: 0000000000000000 x15: 1ffffff8103f2e42 \t x14: 00000000f1f1f1f1 x13: 0000000000000004 x12: ffffffb01812d61d \t x11: 1ffffff01812d61c x10: ffffffb01812d61c x9 : dfffffc000000000 \t x8 : 0000004fe7ed29e4 x7 : ffffff80c096b0e7 x6 : 0000000000000001 \t x5 : ffffff80c096b0e0 x4 : 1ffffffdb990efa2 x3 : 0000000000000000 \t x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000000 \t Call trace: \t strlen+0x24/0xb0 \t kernfs_name_hash+0x1c/0xc4 \t kernfs_find_ns+0x118/0x2e8 \t kernfs_remove_by_name_ns+0x80/0x100 \t sysfs_remove_link+0x74/0xa8 \t module_add_driver+0x278/0x394 \t bus_add_driver+0x1f0/0x43c \t driver_register+0xf4/0x3c0 \t __platform_driver_register+0x60/0x88 \t of_fpga_region_init+0x20/0x1000 [of_fpga_region] \t do_one_initcall+0x110/0x788 \t do_init_module+0x1dc/0x5c8 \t load_module+0x3c38/0x4cac \t init_module_from_file+0xd4/0x128 \t idempotent_init_module+0x2cc/0x528 \t __arm64_sys_finit_module+0xac/0x100 \t invoke_syscall+0x6c/0x258 \t el0_svc_common.constprop.0+0x160/0x22c \t do_el0_svc+0x44/0x5c \t el0_svc+0x48/0xb8 \t el0t_64_sync_handler+0x13c/0x158 \t el0t_64_sync+0x190/0x194 \t Code: f2fbffe1 a90157f4 12000802 aa0003f5 (38e16861) \t ---[ end trace 0000000000000000 ]--- \t Kernel panic - not syncing: Oops: Fatal exception", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47689", "url": "https://ubuntu.com/security/CVE-2024-47689", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to don't set SB_RDONLY in f2fs_handle_critical_error() syzbot reports a f2fs bug as below: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 58 at kernel/rcu/sync.c:177 rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177 CPU: 1 UID: 0 PID: 58 Comm: kworker/1:2 Not tainted 6.10.0-syzkaller-12562-g1722389b0d86 #0 Workqueue: events destroy_super_work RIP: 0010:rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177 Call Trace: percpu_free_rwsem+0x41/0x80 kernel/locking/percpu-rwsem.c:42 destroy_super_work+0xec/0x130 fs/super.c:282 process_one_work kernel/workqueue.c:3231 [inline] process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 worker_thread+0x86d/0xd40 kernel/workqueue.c:3390 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 As Christian Brauner pointed out [1]: the root cause is f2fs sets SB_RDONLY flag in internal function, rather than setting the flag covered w/ sb->s_umount semaphore via remount procedure, then below race condition causes this bug: - freeze_super() - sb_wait_write(sb, SB_FREEZE_WRITE) - sb_wait_write(sb, SB_FREEZE_PAGEFAULT) - sb_wait_write(sb, SB_FREEZE_FS) \t\t\t\t\t- f2fs_handle_critical_error \t\t\t\t\t - sb->s_flags |= SB_RDONLY - thaw_super - thaw_super_locked - sb_rdonly() is true, so it skips sb_freeze_unlock(sb, SB_FREEZE_FS) - deactivate_locked_super Since f2fs has almost the same logic as ext4 [2] when handling critical error in filesystem if it mounts w/ errors=remount-ro option: - set CP_ERROR_FLAG flag which indicates filesystem is stopped - record errors to superblock - set SB_RDONLY falg Once we set CP_ERROR_FLAG flag, all writable interfaces can detect the flag and stop any further updates on filesystem. So, it is safe to not set SB_RDONLY flag, let's remove the logic and keep in line w/ ext4 [3]. [1] https://lore.kernel.org/all/20240729-himbeeren-funknetz-96e62f9c7aee@brauner [2] https://lore.kernel.org/all/20240729132721.hxih6ehigadqf7wx@quack3 [3] https://lore.kernel.org/linux-ext4/20240805201241.27286-1-jack@suse.cz", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47690", "url": "https://ubuntu.com/security/CVE-2024-47690", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: get rid of online repaire on corrupted directory syzbot reports a f2fs bug as below: kernel BUG at fs/f2fs/inode.c:896! RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Call Trace: evict+0x532/0x950 fs/inode.c:704 dispose_list fs/inode.c:747 [inline] evict_inodes+0x5f9/0x690 fs/inode.c:797 generic_shutdown_super+0x9d/0x2d0 fs/super.c:627 kill_block_super+0x44/0x90 fs/super.c:1696 kill_f2fs_super+0x344/0x690 fs/f2fs/super.c:4898 deactivate_locked_super+0xc4/0x130 fs/super.c:473 cleanup_mnt+0x41f/0x4b0 fs/namespace.c:1373 task_work_run+0x24f/0x310 kernel/task_work.c:228 ptrace_notify+0x2d2/0x380 kernel/signal.c:2402 ptrace_report_syscall include/linux/ptrace.h:415 [inline] ptrace_report_syscall_exit include/linux/ptrace.h:477 [inline] syscall_exit_work+0xc6/0x190 kernel/entry/common.c:173 syscall_exit_to_user_mode_prepare kernel/entry/common.c:200 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:205 [inline] syscall_exit_to_user_mode+0x279/0x370 kernel/entry/common.c:218 do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Online repaire on corrupted directory in f2fs_lookup() can generate dirty data/meta while racing w/ readonly remount, it may leave dirty inode after filesystem becomes readonly, however, checkpoint() will skips flushing dirty inode in a state of readonly mode, result in above panic. Let's get rid of online repaire in f2fs_lookup(), and leave the work to fsck.f2fs.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47691", "url": "https://ubuntu.com/security/CVE-2024-47691", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread() syzbot reports a f2fs bug as below: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_report+0xe8/0x550 mm/kasan/report.c:491 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 instrument_atomic_read_write include/linux/instrumented.h:96 [inline] atomic_fetch_add_relaxed include/linux/atomic/atomic-instrumented.h:252 [inline] __refcount_add include/linux/refcount.h:184 [inline] __refcount_inc include/linux/refcount.h:241 [inline] refcount_inc include/linux/refcount.h:258 [inline] get_task_struct include/linux/sched/task.h:118 [inline] kthread_stop+0xca/0x630 kernel/kthread.c:704 f2fs_stop_gc_thread+0x65/0xb0 fs/f2fs/gc.c:210 f2fs_do_shutdown+0x192/0x540 fs/f2fs/file.c:2283 f2fs_ioc_shutdown fs/f2fs/file.c:2325 [inline] __f2fs_ioctl+0x443a/0xbe60 fs/f2fs/file.c:4325 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f The root cause is below race condition, it may cause use-after-free issue in sbi->gc_th pointer. - remount - f2fs_remount - f2fs_stop_gc_thread - kfree(gc_th) \t\t\t\t- f2fs_ioc_shutdown \t\t\t\t - f2fs_do_shutdown \t\t\t\t - f2fs_stop_gc_thread \t\t\t\t - kthread_stop(gc_th->f2fs_gc_task) : sbi->gc_thread = NULL; We will call f2fs_do_shutdown() in two paths: - for f2fs_ioc_shutdown() path, we should grab sb->s_umount semaphore for fixing. - for f2fs_shutdown() path, it's safe since caller has already grabbed sb->s_umount semaphore.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47692", "url": "https://ubuntu.com/security/CVE-2024-47692", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: return -EINVAL when namelen is 0 When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may result in namelen being 0, which will cause memdup_user() to return ZERO_SIZE_PTR. When we access the name.data that has been assigned the value of ZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is triggered. [ T1205] ================================================================== [ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260 [ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205 [ T1205] [ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406 [ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ T1205] Call Trace: [ T1205] dump_stack+0x9a/0xd0 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] __kasan_report.cold+0x34/0x84 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] kasan_report+0x3a/0x50 [ T1205] nfs4_client_to_reclaim+0xe9/0x260 [ T1205] ? nfsd4_release_lockowner+0x410/0x410 [ T1205] cld_pipe_downcall+0x5ca/0x760 [ T1205] ? nfsd4_cld_tracking_exit+0x1d0/0x1d0 [ T1205] ? down_write_killable_nested+0x170/0x170 [ T1205] ? avc_policy_seqno+0x28/0x40 [ T1205] ? selinux_file_permission+0x1b4/0x1e0 [ T1205] rpc_pipe_write+0x84/0xb0 [ T1205] vfs_write+0x143/0x520 [ T1205] ksys_write+0xc9/0x170 [ T1205] ? __ia32_sys_read+0x50/0x50 [ T1205] ? ktime_get_coarse_real_ts64+0xfe/0x110 [ T1205] ? ktime_get_coarse_real_ts64+0xa2/0x110 [ T1205] do_syscall_64+0x33/0x40 [ T1205] entry_SYSCALL_64_after_hwframe+0x67/0xd1 [ T1205] RIP: 0033:0x7fdbdb761bc7 [ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 514 [ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7 [ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008 [ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001 [ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b [ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000 [ T1205] ================================================================== Fix it by checking namelen.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47737", "url": "https://ubuntu.com/security/CVE-2024-47737", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: call cache_put if xdr_reserve_space returns NULL If not enough buffer space available, but idmap_lookup has triggered lookup_fn which calls cache_get and returns successfully. Then we missed to call cache_put here which pairs with cache_get. Reviwed-by: Jeff Layton ", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2023-52917", "url": "https://ubuntu.com/security/CVE-2023-52917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir() The debugfs_create_dir() function returns error pointers. It never returns NULL. So use IS_ERR() to check it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47749", "url": "https://ubuntu.com/security/CVE-2024-47749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Added NULL check for lookup_atid The lookup_atid() function can return NULL if the ATID is invalid or does not exist in the identifier table, which could lead to dereferencing a null pointer without a check in the `act_establish()` and `act_open_rpl()` functions. Add a NULL check to prevent null pointer dereferencing. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47735", "url": "https://ubuntu.com/security/CVE-2024-47735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled Fix missuse of spin_lock_irq()/spin_unlock_irq() when spin_lock_irqsave()/spin_lock_irqrestore() was hold. This was discovered through the lock debugging, and the corresponding log is as follows: raw_local_irq_restore() called with IRQs enabled WARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40 ... Call trace: warn_bogus_irq_restore+0x30/0x40 _raw_spin_unlock_irqrestore+0x84/0xc8 add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2] hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2] hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2] create_qp+0x138/0x258 ib_create_qp_kernel+0x50/0xe8 create_mad_qp+0xa8/0x128 ib_mad_port_open+0x218/0x448 ib_mad_init_device+0x70/0x1f8 add_client_context+0xfc/0x220 enable_device_and_get+0xd0/0x140 ib_register_device.part.0+0xf4/0x1c8 ib_register_device+0x34/0x50 hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2] hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2] __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2] hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47750", "url": "https://ubuntu.com/security/CVE-2024-47750", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix Use-After-Free of rsv_qp on HIP08 Currently rsv_qp is freed before ib_unregister_device() is called on HIP08. During the time interval, users can still dereg MR and rsv_qp will be used in this process, leading to a UAF. Move the release of rsv_qp after calling ib_unregister_device() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47751", "url": "https://ubuntu.com/security/CVE-2024-47751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: kirin: Fix buffer overflow in kirin_pcie_parse_port() Within kirin_pcie_parse_port(), the pcie->num_slots is compared to pcie->gpio_id_reset size (MAX_PCI_SLOTS) which is correct and would lead to an overflow. Thus, fix condition to pcie->num_slots + 1 >= MAX_PCI_SLOTS and move pcie->num_slots increment below the if-statement to avoid out-of-bounds array access. Found by Linux Verification Center (linuxtesting.org) with SVACE. [kwilczynski: commit log]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47693", "url": "https://ubuntu.com/security/CVE-2024-47693", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/core: Fix ib_cache_setup_one error flow cleanup When ib_cache_update return an error, we exit ib_cache_setup_one instantly with no proper cleanup, even though before this we had already successfully done gid_table_setup_one, that results in the kernel WARN below. Do proper cleanup using gid_table_cleanup_one before returning the err in order to fix the issue. WARNING: CPU: 4 PID: 922 at drivers/infiniband/core/cache.c:806 gid_table_release_one+0x181/0x1a0 Modules linked in: CPU: 4 UID: 0 PID: 922 Comm: c_repro Not tainted 6.11.0-rc1+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:gid_table_release_one+0x181/0x1a0 Code: 44 8b 38 75 0c e8 2f cb 34 ff 4d 8b b5 28 05 00 00 e8 23 cb 34 ff 44 89 f9 89 da 4c 89 f6 48 c7 c7 d0 58 14 83 e8 4f de 21 ff <0f> 0b 4c 8b 75 30 e9 54 ff ff ff 48 8 3 c4 10 5b 5d 41 5c 41 5d 41 RSP: 0018:ffffc90002b835b0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c8527 RDX: 0000000000000000 RSI: ffffffff811c8534 RDI: 0000000000000001 RBP: ffff8881011b3d00 R08: ffff88810b3abe00 R09: 205d303839303631 R10: 666572207972746e R11: 72746e6520444947 R12: 0000000000000001 R13: ffff888106390000 R14: ffff8881011f2110 R15: 0000000000000001 FS: 00007fecc3b70800(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000340 CR3: 000000010435a001 CR4: 00000000003706b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? show_regs+0x94/0xa0 ? __warn+0x9e/0x1c0 ? gid_table_release_one+0x181/0x1a0 ? report_bug+0x1f9/0x340 ? gid_table_release_one+0x181/0x1a0 ? handle_bug+0xa2/0x110 ? exc_invalid_op+0x31/0xa0 ? asm_exc_invalid_op+0x16/0x20 ? __warn_printk+0xc7/0x180 ? __warn_printk+0xd4/0x180 ? gid_table_release_one+0x181/0x1a0 ib_device_release+0x71/0xe0 ? __pfx_ib_device_release+0x10/0x10 device_release+0x44/0xd0 kobject_put+0x135/0x3d0 put_device+0x20/0x30 rxe_net_add+0x7d/0xa0 rxe_newlink+0xd7/0x190 nldev_newlink+0x1b0/0x2a0 ? __pfx_nldev_newlink+0x10/0x10 rdma_nl_rcv_msg+0x1ad/0x2e0 rdma_nl_rcv_skb.constprop.0+0x176/0x210 netlink_unicast+0x2de/0x400 netlink_sendmsg+0x306/0x660 __sock_sendmsg+0x110/0x120 ____sys_sendmsg+0x30e/0x390 ___sys_sendmsg+0x9b/0xf0 ? kstrtouint+0x6e/0xa0 ? kstrtouint_from_user+0x7c/0xb0 ? get_pid_task+0xb0/0xd0 ? proc_fail_nth_write+0x5b/0x140 ? __fget_light+0x9a/0x200 ? preempt_count_add+0x47/0xa0 __sys_sendmsg+0x61/0xd0 do_syscall_64+0x50/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47694", "url": "https://ubuntu.com/security/CVE-2024-47694", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mlx5: Fix UMR pd cleanup on error flow of driver init The cited commit moves the pd allocation from function mlx5r_umr_resource_cleanup() to a new function mlx5r_umr_cleanup(). So the fix in commit [1] is broken. In error flow, will hit panic [2]. Fix it by checking pd pointer to avoid panic if it is NULL; [1] RDMA/mlx5: Fix UMR cleanup on error flow of driver init [2] [ 347.567063] infiniband mlx5_0: Couldn't register device with driver model [ 347.591382] BUG: kernel NULL pointer dereference, address: 0000000000000020 [ 347.593438] #PF: supervisor read access in kernel mode [ 347.595176] #PF: error_code(0x0000) - not-present page [ 347.596962] PGD 0 P4D 0 [ 347.601361] RIP: 0010:ib_dealloc_pd_user+0x12/0xc0 [ib_core] [ 347.604171] RSP: 0018:ffff888106293b10 EFLAGS: 00010282 [ 347.604834] RAX: 0000000000000000 RBX: 000000000000000e RCX: 0000000000000000 [ 347.605672] RDX: ffff888106293ad0 RSI: 0000000000000000 RDI: 0000000000000000 [ 347.606529] RBP: 0000000000000000 R08: ffff888106293ae0 R09: ffff888106293ae0 [ 347.607379] R10: 0000000000000a06 R11: 0000000000000000 R12: 0000000000000000 [ 347.608224] R13: ffffffffa0704dc0 R14: 0000000000000001 R15: 0000000000000001 [ 347.609067] FS: 00007fdc720cd9c0(0000) GS:ffff88852c880000(0000) knlGS:0000000000000000 [ 347.610094] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 347.610727] CR2: 0000000000000020 CR3: 0000000103012003 CR4: 0000000000370eb0 [ 347.611421] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 347.612113] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 347.612804] Call Trace: [ 347.613130] [ 347.613417] ? __die+0x20/0x60 [ 347.613793] ? page_fault_oops+0x150/0x3e0 [ 347.614243] ? free_msg+0x68/0x80 [mlx5_core] [ 347.614840] ? cmd_exec+0x48f/0x11d0 [mlx5_core] [ 347.615359] ? exc_page_fault+0x74/0x130 [ 347.615808] ? asm_exc_page_fault+0x22/0x30 [ 347.616273] ? ib_dealloc_pd_user+0x12/0xc0 [ib_core] [ 347.616801] mlx5r_umr_cleanup+0x23/0x90 [mlx5_ib] [ 347.617365] mlx5_ib_stage_pre_ib_reg_umr_cleanup+0x36/0x40 [mlx5_ib] [ 347.618025] __mlx5_ib_add+0x96/0xd0 [mlx5_ib] [ 347.618539] mlx5r_probe+0xe9/0x310 [mlx5_ib] [ 347.619032] ? kernfs_add_one+0x107/0x150 [ 347.619478] ? __mlx5_ib_add+0xd0/0xd0 [mlx5_ib] [ 347.619984] auxiliary_bus_probe+0x3e/0x90 [ 347.620448] really_probe+0xc5/0x3a0 [ 347.620857] __driver_probe_device+0x80/0x160 [ 347.621325] driver_probe_device+0x1e/0x90 [ 347.621770] __driver_attach+0xec/0x1c0 [ 347.622213] ? __device_attach_driver+0x100/0x100 [ 347.622724] bus_for_each_dev+0x71/0xc0 [ 347.623151] bus_add_driver+0xed/0x240 [ 347.623570] driver_register+0x58/0x100 [ 347.623998] __auxiliary_driver_register+0x6a/0xc0 [ 347.624499] ? driver_register+0xae/0x100 [ 347.624940] ? 0xffffffffa0893000 [ 347.625329] mlx5_ib_init+0x16a/0x1e0 [mlx5_ib] [ 347.625845] do_one_initcall+0x4a/0x2a0 [ 347.626273] ? gcov_event+0x2e2/0x3a0 [ 347.626706] do_init_module+0x8a/0x260 [ 347.627126] init_module_from_file+0x8b/0xd0 [ 347.627596] __x64_sys_finit_module+0x1ca/0x2f0 [ 347.628089] do_syscall_64+0x4c/0x100", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47695", "url": "https://ubuntu.com/security/CVE-2024-47695", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds In the function init_conns(), after the create_con() and create_cm() for loop if something fails. In the cleanup for loop after the destroy tag, we access out of bound memory because cid is set to clt_path->s.con_num. This commits resets the cid to clt_path->s.con_num - 1, to stay in bounds in the cleanup loop later.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47752", "url": "https://ubuntu.com/security/CVE-2024-47752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix H264 stateless decoder smatch warning Fix a smatch static checker warning on vdec_h264_req_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47753", "url": "https://ubuntu.com/security/CVE-2024-47753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix VP8 stateless decoder smatch warning Fix a smatch static checker warning on vdec_vp8_req_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47754", "url": "https://ubuntu.com/security/CVE-2024-47754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix H264 multi stateless decoder smatch warning Fix a smatch static checker warning on vdec_h264_req_multi_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47696", "url": "https://ubuntu.com/security/CVE-2024-47696", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency In the commit aee2424246f9 (\"RDMA/iwcm: Fix a use-after-free related to destroying CM IDs\"), the function flush_workqueue is invoked to flush the work queue iwcm_wq. But at that time, the work queue iwcm_wq was created via the function alloc_ordered_workqueue without the flag WQ_MEM_RECLAIM. Because the current process is trying to flush the whole iwcm_wq, if iwcm_wq doesn't have the flag WQ_MEM_RECLAIM, verify that the current process is not reclaiming memory or running on a workqueue which doesn't have the flag WQ_MEM_RECLAIM as that can break forward-progress guarantee leading to a deadlock. The call trace is as below: [ 125.350876][ T1430] Call Trace: [ 125.356281][ T1430] [ 125.361285][ T1430] ? __warn (kernel/panic.c:693) [ 125.367640][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.375689][ T1430] ? report_bug (lib/bug.c:180 lib/bug.c:219) [ 125.382505][ T1430] ? handle_bug (arch/x86/kernel/traps.c:239) [ 125.388987][ T1430] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) [ 125.395831][ T1430] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621) [ 125.403125][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.410984][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.418764][ T1430] __flush_workqueue (kernel/workqueue.c:3970) [ 125.426021][ T1430] ? __pfx___might_resched (kernel/sched/core.c:10151) [ 125.433431][ T1430] ? destroy_cm_id (drivers/infiniband/core/iwcm.c:375) iw_cm [ 125.441209][ T1430] ? __pfx___flush_workqueue (kernel/workqueue.c:3910) [ 125.473900][ T1430] ? _raw_spin_lock_irqsave (arch/x86/include/asm/atomic.h:107 include/linux/atomic/atomic-arch-fallback.h:2170 include/linux/atomic/atomic-instrumented.h:1302 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162) [ 125.473909][ T1430] ? __pfx__raw_spin_lock_irqsave (kernel/locking/spinlock.c:161) [ 125.482537][ T1430] _destroy_id (drivers/infiniband/core/cma.c:2044) rdma_cm [ 125.495072][ T1430] nvme_rdma_free_queue (drivers/nvme/host/rdma.c:656 drivers/nvme/host/rdma.c:650) nvme_rdma [ 125.505827][ T1430] nvme_rdma_reset_ctrl_work (drivers/nvme/host/rdma.c:2180) nvme_rdma [ 125.505831][ T1430] process_one_work (kernel/workqueue.c:3231) [ 125.515122][ T1430] worker_thread (kernel/workqueue.c:3306 kernel/workqueue.c:3393) [ 125.515127][ T1430] ? __pfx_worker_thread (kernel/workqueue.c:3339) [ 125.531837][ T1430] kthread (kernel/kthread.c:389) [ 125.539864][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.550628][ T1430] ret_from_fork (arch/x86/kernel/process.c:147) [ 125.558840][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.558844][ T1430] ret_from_fork_asm (arch/x86/entry/entry_64.S:257) [ 125.566487][ T1430] [ 125.566488][ T1430] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47755", "url": "https://ubuntu.com/security/CVE-2024-47755", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47756", "url": "https://ubuntu.com/security/CVE-2024-47756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: keystone: Fix if-statement expression in ks_pcie_quirk() This code accidentally uses && where || was intended. It potentially results in a NULL dereference. Thus, fix the if-statement expression to use the correct condition. [kwilczynski: commit log]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47697", "url": "https://ubuntu.com/security/CVE-2024-47697", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error Ensure index in rtl2830_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47698", "url": "https://ubuntu.com/security/CVE-2024-47698", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error Ensure index in rtl2832_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue. [hverkuil: added fixes tag, rtl2830_pid_filter -> rtl2832_pid_filter in logmsg]", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47728", "url": "https://ubuntu.com/security/CVE-2024-47728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error For all non-tracing helpers which formerly had ARG_PTR_TO_{LONG,INT} as input arguments, zero the value for the case of an error as otherwise it could leak memory. For tracing, it is not needed given CAP_PERFMON can already read all kernel memory anyway hence bpf_get_func_arg() and bpf_get_func_ret() is skipped in here. Also, the MTU helpers mtu_len pointer value is being written but also read. Technically, the MEM_UNINIT should not be there in order to always force init. Removing MEM_UNINIT needs more verifier rework though: MEM_UNINIT right now implies two things actually: i) write into memory, ii) memory does not have to be initialized. If we lift MEM_UNINIT, it then becomes: i) read into memory, ii) memory must be initialized. This means that for bpf_*_check_mtu() we're readding the issue we're trying to fix, that is, it would then be able to write back into things like .rodata BPF maps. Follow-up work will rework the MEM_UNINIT semantics such that the intent can be better expressed. For now just clear the *mtu_len on error path which can be lifted later again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49861", "url": "https://ubuntu.com/security/CVE-2024-49861", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix helper writes to read-only maps Lonial found an issue that despite user- and BPF-side frozen BPF map (like in case of .rodata), it was still possible to write into it from a BPF program side through specific helpers having ARG_PTR_TO_{LONG,INT} as arguments. In check_func_arg() when the argument is as mentioned, the meta->raw_mode is never set. Later, check_helper_mem_access(), under the case of PTR_TO_MAP_VALUE as register base type, it assumes BPF_READ for the subsequent call to check_map_access_type() and given the BPF map is read-only it succeeds. The helpers really need to be annotated as ARG_PTR_TO_{LONG,INT} | MEM_UNINIT when results are written into them as opposed to read out of them. The latter indicates that it's okay to pass a pointer to uninitialized memory as the memory is written to anyway. However, ARG_PTR_TO_{LONG,INT} is a special case of ARG_PTR_TO_FIXED_SIZE_MEM just with additional alignment requirement. So it is better to just get rid of the ARG_PTR_TO_{LONG,INT} special cases altogether and reuse the fixed size memory types. For this, add MEM_ALIGNED to additionally ensure alignment given these helpers write directly into the args via * = val. The .arg*_size has been initialized reflecting the actual sizeof(*). MEM_ALIGNED can only be used in combination with MEM_FIXED_SIZE annotated argument types, since in !MEM_FIXED_SIZE cases the verifier does not know the buffer size a priori and therefore cannot blindly write * = val.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47757", "url": "https://ubuntu.com/security/CVE-2024-47757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential oob read in nilfs_btree_check_delete() The function nilfs_btree_check_delete(), which checks whether degeneration to direct mapping occurs before deleting a b-tree entry, causes memory access outside the block buffer when retrieving the maximum key if the root node has no entries. This does not usually happen because b-tree mappings with 0 child nodes are never created by mkfs.nilfs2 or nilfs2 itself. However, it can happen if the b-tree root node read from a device is configured that way, so fix this potential issue by adding a check for that case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47699", "url": "https://ubuntu.com/security/CVE-2024-47699", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential null-ptr-deref in nilfs_btree_insert() Patch series \"nilfs2: fix potential issues with empty b-tree nodes\". This series addresses three potential issues with empty b-tree nodes that can occur with corrupted filesystem images, including one recently discovered by syzbot. This patch (of 3): If a b-tree is broken on the device, and the b-tree height is greater than 2 (the level of the root node is greater than 1) even if the number of child nodes of the b-tree root is 0, a NULL pointer dereference occurs in nilfs_btree_prepare_insert(), which is called from nilfs_btree_insert(). This is because, when the number of child nodes of the b-tree root is 0, nilfs_btree_do_lookup() does not set the block buffer head in any of path[x].bp_bh, leaving it as the initial value of NULL, but if the level of the b-tree root node is greater than 1, nilfs_btree_get_nonroot_node(), which accesses the buffer memory of path[x].bp_bh, is called. Fix this issue by adding a check to nilfs_btree_root_broken(), which performs sanity checks when reading the root node from the device, to detect this inconsistency. Thanks to Lizhi Xu for trying to solve the bug and clarifying the cause early on.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47700", "url": "https://ubuntu.com/security/CVE-2024-47700", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: check stripe size compatibility on remount as well We disable stripe size in __ext4_fill_super if it is not a multiple of the cluster ratio however this check is missed when trying to remount. This can leave us with cases where stripe < cluster_ratio after remount:set making EXT4_B2C(sbi->s_stripe) become 0 that can cause some unforeseen bugs like divide by 0. Fix that by adding the check in remount path as well.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47701", "url": "https://ubuntu.com/security/CVE-2024-47701", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid OOB when system.data xattr changes underneath the filesystem When looking up for an entry in an inlined directory, if e_value_offs is changed underneath the filesystem by some change in the block device, it will lead to an out-of-bounds access that KASAN detects as an UAF. EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none. loop0: detected capacity change from 2048 to 2047 ================================================================== BUG: KASAN: use-after-free in ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 Read of size 1 at addr ffff88803e91130f by task syz-executor269/5103 CPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 Not tainted 6.11.0-rc4-syzkaller #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:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 ext4_find_inline_entry+0x4be/0x5e0 fs/ext4/inline.c:1697 __ext4_find_entry+0x2b4/0x1b30 fs/ext4/namei.c:1573 ext4_lookup_entry fs/ext4/namei.c:1727 [inline] ext4_lookup+0x15f/0x750 fs/ext4/namei.c:1795 lookup_one_qstr_excl+0x11f/0x260 fs/namei.c:1633 filename_create+0x297/0x540 fs/namei.c:3980 do_symlinkat+0xf9/0x3a0 fs/namei.c:4587 __do_sys_symlinkat fs/namei.c:4610 [inline] __se_sys_symlinkat fs/namei.c:4607 [inline] __x64_sys_symlinkat+0x95/0xb0 fs/namei.c:4607 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:0x7f3e73ced469 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff4d40c258 EFLAGS: 00000246 ORIG_RAX: 000000000000010a RAX: ffffffffffffffda RBX: 0032656c69662f2e RCX: 00007f3e73ced469 RDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0 RBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290 R10: 0023706f6f6c2f76 R11: 0000000000000246 R12: 00007fff4d40c27c R13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0 Calling ext4_xattr_ibody_find right after reading the inode with ext4_get_inode_loc will lead to a check of the validity of the xattrs, avoiding this problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49850", "url": "https://ubuntu.com/security/CVE-2024-49850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: correctly handle malformed BPF_CORE_TYPE_ID_LOCAL relos In case of malformed relocation record of kind BPF_CORE_TYPE_ID_LOCAL referencing a non-existing BTF type, function bpf_core_calc_relo_insn would cause a null pointer deference. Fix this by adding a proper check upper in call stack, as malformed relocation records could be passed from user space. Simplest reproducer is a program: r0 = 0 exit With a single relocation record: .insn_off = 0, /* patch first instruction */ .type_id = 100500, /* this type id does not exist */ .access_str_off = 6, /* offset of string \"0\" */ .kind = BPF_CORE_TYPE_ID_LOCAL, See the link for original reproducer or next commit for a test case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47702", "url": "https://ubuntu.com/security/CVE-2024-47702", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fail verification for sign-extension of packet data/data_end/data_meta syzbot reported a kernel crash due to commit 1f1e864b6555 (\"bpf: Handle sign-extenstin ctx member accesses\"). The reason is due to sign-extension of 32-bit load for packet data/data_end/data_meta uapi field. The original code looks like: r2 = *(s32 *)(r1 + 76) /* load __sk_buff->data */ r3 = *(u32 *)(r1 + 80) /* load __sk_buff->data_end */ r0 = r2 r0 += 8 if r3 > r0 goto +1 ... Note that __sk_buff->data load has 32-bit sign extension. After verification and convert_ctx_accesses(), the final asm code looks like: r2 = *(u64 *)(r1 +208) r2 = (s32)r2 r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 ... Note that 'r2 = (s32)r2' may make the kernel __sk_buff->data address invalid which may cause runtime failure. Currently, in C code, typically we have void *data = (void *)(long)skb->data; void *data_end = (void *)(long)skb->data_end; ... and it will generate r2 = *(u64 *)(r1 +208) r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 If we allow sign-extension, void *data = (void *)(long)(int)skb->data; void *data_end = (void *)(long)skb->data_end; ... the generated code looks like r2 = *(u64 *)(r1 +208) r2 <<= 32 r2 s>>= 32 r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 and this will cause verification failure since \"r2 <<= 32\" is not allowed as \"r2\" is a packet pointer. To fix this issue for case r2 = *(s32 *)(r1 + 76) /* load __sk_buff->data */ this patch added additional checking in is_valid_access() callback function for packet data/data_end/data_meta access. If those accesses are with sign-extenstion, the verification will fail. [1] https://lore.kernel.org/bpf/000000000000c90eee061d236d37@google.com/", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47703", "url": "https://ubuntu.com/security/CVE-2024-47703", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, lsm: Add check for BPF LSM return value A bpf prog returning a positive number attached to file_alloc_security hook makes kernel panic. This happens because file system can not filter out the positive number returned by the LSM prog using IS_ERR, and misinterprets this positive number as a file pointer. Given that hook file_alloc_security never returned positive number before the introduction of BPF LSM, and other BPF LSM hooks may encounter similar issues, this patch adds LSM return value check in verifier, to ensure no unexpected value is returned.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49851", "url": "https://ubuntu.com/security/CVE-2024-49851", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: Clean up TPM space after command failure tpm_dev_transmit prepares the TPM space before attempting command transmission. However if the command fails no rollback of this preparation is done. This can result in transient handles being leaked if the device is subsequently closed with no further commands performed. Fix this by flushing the space in the event of command transmission failure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47723", "url": "https://ubuntu.com/security/CVE-2024-47723", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: fix out-of-bounds in dbNextAG() and diAlloc() In dbNextAG() , there is no check for the case where bmp->db_numag is greater or same than MAXAG due to a polluted image, which causes an out-of-bounds. Therefore, a bounds check should be added in dbMount(). And in dbNextAG(), a check for the case where agpref is greater than bmp->db_numag should be added, so an out-of-bounds exception should be prevented. Additionally, a check for the case where agno is greater or same than MAXAG should be added in diAlloc() to prevent out-of-bounds.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49852", "url": "https://ubuntu.com/security/CVE-2024-49852", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: elx: libefc: Fix potential use after free in efc_nport_vport_del() The kref_put() function will call nport->release if the refcount drops to zero. The nport->release release function is _efc_nport_free() which frees \"nport\". But then we dereference \"nport\" on the next line which is a use after free. Re-order these lines to avoid the use after free.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47720", "url": "https://ubuntu.com/security/CVE-2024-47720", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for set_output_gamma in dcn30_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn30_set_output_transfer_func function. Previously, set_output_gamma was being checked for nullity at line 386, but then it was being dereferenced without any nullity check at line 401. This could potentially lead to a null pointer dereference error if set_output_gamma is indeed null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a nullity check for set_output_gamma before the call to set_output_gamma at line 401. If set_output_gamma is null, we log an error message and do not call the function. This fix prevents a potential null pointer dereference error. drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:401 dcn30_set_output_transfer_func() error: we previously assumed 'mpc->funcs->set_output_gamma' could be null (see line 386) drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c 373 bool dcn30_set_output_transfer_func(struct dc *dc, 374 struct pipe_ctx *pipe_ctx, 375 const struct dc_stream_state *stream) 376 { 377 int mpcc_id = pipe_ctx->plane_res.hubp->inst; 378 struct mpc *mpc = pipe_ctx->stream_res.opp->ctx->dc->res_pool->mpc; 379 const struct pwl_params *params = NULL; 380 bool ret = false; 381 382 /* program OGAM or 3DLUT only for the top pipe*/ 383 if (pipe_ctx->top_pipe == NULL) { 384 /*program rmu shaper and 3dlut in MPC*/ 385 ret = dcn30_set_mpc_shaper_3dlut(pipe_ctx, stream); 386 if (ret == false && mpc->funcs->set_output_gamma) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If this is NULL 387 if (stream->out_transfer_func.type == TF_TYPE_HWPWL) 388 params = &stream->out_transfer_func.pwl; 389 else if (pipe_ctx->stream->out_transfer_func.type == 390 TF_TYPE_DISTRIBUTED_POINTS && 391 cm3_helper_translate_curve_to_hw_format( 392 &stream->out_transfer_func, 393 &mpc->blender_params, false)) 394 params = &mpc->blender_params; 395 /* there are no ROM LUTs in OUTGAM */ 396 if (stream->out_transfer_func.type == TF_TYPE_PREDEFINED) 397 BREAK_TO_DEBUGGER(); 398 } 399 } 400 --> 401 mpc->funcs->set_output_gamma(mpc, mpcc_id, params); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Then it will crash 402 return ret; 403 }", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47704", "url": "https://ubuntu.com/security/CVE-2024-47704", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check link_res->hpo_dp_link_enc before using it [WHAT & HOW] Functions dp_enable_link_phy and dp_disable_link_phy can pass link_res without initializing hpo_dp_link_enc and it is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49853", "url": "https://ubuntu.com/security/CVE-2024-49853", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix double free in OPTEE transport Channels can be shared between protocols, avoid freeing the same channel descriptors twice when unloading the stack.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47705", "url": "https://ubuntu.com/security/CVE-2024-47705", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix potential invalid pointer dereference in blk_add_partition The blk_add_partition() function initially used a single if-condition (IS_ERR(part)) to check for errors when adding a partition. This was modified to handle the specific case of -ENXIO separately, allowing the function to proceed without logging the error in this case. However, this change unintentionally left a path where md_autodetect_dev() could be called without confirming that part is a valid pointer. This commit separates the error handling logic by splitting the initial if-condition, improving code readability and handling specific error scenarios explicitly. The function now distinguishes the general error case from -ENXIO without altering the existing behavior of md_autodetect_dev() calls.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47736", "url": "https://ubuntu.com/security/CVE-2024-47736", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: handle overlapped pclusters out of crafted images properly syzbot reported a task hang issue due to a deadlock case where it is waiting for the folio lock of a cached folio that will be used for cache I/Os. After looking into the crafted fuzzed image, I found it's formed with several overlapped big pclusters as below: Ext: logical offset | length : physical offset | length 0: 0.. 16384 | 16384 : 151552.. 167936 | 16384 1: 16384.. 32768 | 16384 : 155648.. 172032 | 16384 2: 32768.. 49152 | 16384 : 537223168.. 537239552 | 16384 ... Here, extent 0/1 are physically overlapped although it's entirely _impossible_ for normal filesystem images generated by mkfs. First, managed folios containing compressed data will be marked as up-to-date and then unlocked immediately (unlike in-place folios) when compressed I/Os are complete. If physical blocks are not submitted in the incremental order, there should be separate BIOs to avoid dependency issues. However, the current code mis-arranges z_erofs_fill_bio_vec() and BIO submission which causes unexpected BIO waits. Second, managed folios will be connected to their own pclusters for efficient inter-queries. However, this is somewhat hard to implement easily if overlapped big pclusters exist. Again, these only appear in fuzzed images so let's simply fall back to temporary short-lived pages for correctness. Additionally, it justifies that referenced managed folios cannot be truncated for now and reverts part of commit 2080ca1ed3e4 (\"erofs: tidy up `struct z_erofs_bvec`\") for simplicity although it shouldn't be any difference.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47706", "url": "https://ubuntu.com/security/CVE-2024-47706", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block, bfq: fix possible UAF for bfqq->bic with merge chain 1) initial state, three tasks: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t\t | ? | ?\t\t | ? \t\t | | | |\t\t | | \t\t V | V |\t\t V | \t\t bfqq1 bfqq2\t\t bfqq3 process ref:\t 1\t\t 1\t\t 1 2) bfqq1 merged to bfqq2: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t\t | |\t\t | ? \t\t \\--------------\\|\t\t | | \t\t V\t\t V | \t\t bfqq1--------->bfqq2\t\t bfqq3 process ref:\t 0\t\t 2\t\t 1 3) bfqq2 merged to bfqq3: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t here -> ? |\t\t | \t\t \\--------------\\ \\-------------\\| \t\t V\t\t V \t\t bfqq1--------->bfqq2---------->bfqq3 process ref:\t 0\t\t 1\t\t 3 In this case, IO from Process 1 will get bfqq2 from BIC1 first, and then get bfqq3 through merge chain, and finially handle IO by bfqq3. Howerver, current code will think bfqq2 is owned by BIC1, like initial state, and set bfqq2->bic to BIC1. bfq_insert_request -> by Process 1 bfqq = bfq_init_rq(rq) bfqq = bfq_get_bfqq_handle_split bfqq = bic_to_bfqq -> get bfqq2 from BIC1 bfqq->ref++ rq->elv.priv[0] = bic rq->elv.priv[1] = bfqq if (bfqq_process_refs(bfqq) == 1) bfqq->bic = bic -> record BIC1 to bfqq2 __bfq_insert_request new_bfqq = bfq_setup_cooperator -> get bfqq3 from bfqq2->new_bfqq bfqq_request_freed(bfqq) new_bfqq->ref++ rq->elv.priv[1] = new_bfqq -> handle IO by bfqq3 Fix the problem by checking bfqq is from merge chain fist. And this might fix a following problem reported by our syzkaller(unreproducible): ================================================================== BUG: KASAN: slab-use-after-free in bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] BUG: KASAN: slab-use-after-free in bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] BUG: KASAN: slab-use-after-free in bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 Write of size 1 at addr ffff888123839eb8 by task kworker/0:1H/18595 CPU: 0 PID: 18595 Comm: kworker/0:1H Tainted: G L 6.6.0-07439-gba2303cacfda #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Workqueue: kblockd blk_mq_requeue_work Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [inline] print_report+0x10d/0x610 mm/kasan/report.c:475 kasan_report+0x8e/0xc0 mm/kasan/report.c:588 bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 bfq_get_bfqq_handle_split+0x169/0x5d0 block/bfq-iosched.c:6757 bfq_init_rq block/bfq-iosched.c:6876 [inline] bfq_insert_request block/bfq-iosched.c:6254 [inline] bfq_insert_requests+0x1112/0x5cf0 block/bfq-iosched.c:6304 blk_mq_insert_request+0x290/0x8d0 block/blk-mq.c:2593 blk_mq_requeue_work+0x6bc/0xa70 block/blk-mq.c:1502 process_one_work kernel/workqueue.c:2627 [inline] process_scheduled_works+0x432/0x13f0 kernel/workqueue.c:2700 worker_thread+0x6f2/0x1160 kernel/workqueue.c:2781 kthread+0x33c/0x440 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:305 Allocated by task 20776: kasan_save_stack+0x20/0x40 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 __kasan_slab_alloc+0x87/0x90 mm/kasan/common.c:328 kasan_slab_alloc include/linux/kasan.h:188 [inline] slab_post_alloc_hook mm/slab.h:763 [inline] slab_alloc_node mm/slub.c:3458 [inline] kmem_cache_alloc_node+0x1a4/0x6f0 mm/slub.c:3503 ioc_create_icq block/blk-ioc.c:370 [inline] ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49855", "url": "https://ubuntu.com/security/CVE-2024-49855", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: fix race between timeout and normal completion If request timetout is handled by nbd_requeue_cmd(), normal completion has to be stopped for avoiding to complete this requeued request, other use-after-free can be triggered. Fix the race by clearing NBD_CMD_INFLIGHT in nbd_requeue_cmd(), meantime make sure that cmd->lock is grabbed for clearing the flag and the requeue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47707", "url": "https://ubuntu.com/security/CVE-2024-47707", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev() Blamed commit accidentally removed a check for rt->rt6i_idev being NULL, as spotted by syzbot: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 UID: 0 PID: 10998 Comm: syz-executor Not tainted 6.11.0-rc6-syzkaller-00208-g625403177711 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 RBP: ffffc900047375d0 R08: 0000000000000003 R09: fffff520008e6e8c R10: dffffc0000000000 R11: fffff520008e6e8c R12: 1ffff1100fdf8f18 R13: ffff88807efc7998 R14: 0000000000000000 R15: ffff88807efc7930 FS: 0000000000000000(0000) GS:ffff8880b8900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020002a80 CR3: 0000000022f62000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: addrconf_ifdown+0x15d/0x1bd0 net/ipv6/addrconf.c:3856 addrconf_notify+0x3cb/0x1020 notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93 call_netdevice_notifiers_extack net/core/dev.c:2032 [inline] call_netdevice_notifiers net/core/dev.c:2046 [inline] unregister_netdevice_many_notify+0xd81/0x1c40 net/core/dev.c:11352 unregister_netdevice_many net/core/dev.c:11414 [inline] unregister_netdevice_queue+0x303/0x370 net/core/dev.c:11289 unregister_netdevice include/linux/netdevice.h:3129 [inline] __tun_detach+0x6b9/0x1600 drivers/net/tun.c:685 tun_detach drivers/net/tun.c:701 [inline] tun_chr_close+0x108/0x1b0 drivers/net/tun.c:3510 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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:0x7f1acc77def9 Code: Unable to access opcode bytes at 0x7f1acc77decf. RSP: 002b:00007ffeb26fa738 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1acc77def9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000043 RBP: 00007f1acc7dd508 R08: 00007ffeb26f84d7 R09: 0000000000000003 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 0000000000000003 R14: 00000000ffffffff R15: 00007ffeb26fa8e0 Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 R ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47708", "url": "https://ubuntu.com/security/CVE-2024-47708", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netkit: Assign missing bpf_net_context During the introduction of struct bpf_net_context handling for XDP-redirect, the netkit driver has been missed, which also requires it because NETKIT_REDIRECT invokes skb_do_redirect() which is accessing the per-CPU variables. Otherwise we see the following crash: \tBUG: kernel NULL pointer dereference, address: 0000000000000038 \tbpf_redirect() \tnetkit_xmit() \tdev_hard_start_xmit() Set the bpf_net_context before invoking netkit_xmit() program within the netkit driver.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47709", "url": "https://ubuntu.com/security/CVE-2024-47709", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: Clear bo->bcm_proc_read after remove_proc_entry(). syzbot reported a warning in bcm_release(). [0] The blamed change fixed another warning that is triggered when connect() is issued again for a socket whose connect()ed device has been unregistered. However, if the socket is just close()d without the 2nd connect(), the remaining bo->bcm_proc_read triggers unnecessary remove_proc_entry() in bcm_release(). Let's clear bo->bcm_proc_read after remove_proc_entry() in bcm_notify(). [0] name '4986' WARNING: CPU: 0 PID: 5234 at fs/proc/generic.c:711 remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Modules linked in: CPU: 0 UID: 0 PID: 5234 Comm: syz-executor606 Not tainted 6.11.0-rc5-syzkaller-00178-g5517ae241919 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Code: ff eb 05 e8 cb 1e 5e ff 48 8b 5c 24 10 48 c7 c7 e0 f7 aa 8e e8 2a 38 8e 09 90 48 c7 c7 60 3a 1b 8c 48 89 de e8 da 42 20 ff 90 <0f> 0b 90 90 48 8b 44 24 18 48 c7 44 24 40 0e 36 e0 45 49 c7 04 07 RSP: 0018:ffffc9000345fa20 EFLAGS: 00010246 RAX: 2a2d0aee2eb64600 RBX: ffff888032f1f548 RCX: ffff888029431e00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000345fb08 R08: ffffffff8155b2f2 R09: 1ffff1101710519a R10: dffffc0000000000 R11: ffffed101710519b R12: ffff888011d38640 R13: 0000000000000004 R14: 0000000000000000 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8880b8800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcfb52722f0 CR3: 000000000e734000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: bcm_release+0x250/0x880 net/can/bcm.c:1578 __sock_release net/socket.c:659 [inline] sock_close+0xbc/0x240 net/socket.c:1421 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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:0x7fcfb51ee969 Code: Unable to access opcode bytes at 0x7fcfb51ee93f. RSP: 002b:00007ffce0109ca8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fcfb51ee969 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 00007fcfb526f3b0 R08: ffffffffffffffb8 R09: 0000555500000000 R10: 0000555500000000 R11: 0000000000000246 R12: 00007fcfb526f3b0 R13: 0000000000000000 R14: 00007fcfb5271ee0 R15: 00007fcfb51bf160 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47710", "url": "https://ubuntu.com/security/CVE-2024-47710", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sock_map: Add a cond_resched() in sock_hash_free() Several syzbot soft lockup reports all have in common sock_hash_free() If a map with a large number of buckets is destroyed, we need to yield the cpu when needed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47711", "url": "https://ubuntu.com/security/CVE-2024-47711", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Don't return OOB skb in manage_oob(). syzbot reported use-after-free in unix_stream_recv_urg(). [0] The scenario is 1. send(MSG_OOB) 2. recv(MSG_OOB) -> The consumed OOB remains in recv queue 3. send(MSG_OOB) 4. recv() -> manage_oob() returns the next skb of the consumed OOB -> This is also OOB, but unix_sk(sk)->oob_skb is not cleared 5. recv(MSG_OOB) -> unix_sk(sk)->oob_skb is used but already freed The recent commit 8594d9b85c07 (\"af_unix: Don't call skb_get() for OOB skb.\") uncovered the issue. If the OOB skb is consumed and the next skb is peeked in manage_oob(), we still need to check if the skb is OOB. Let's do so by falling back to the following checks in manage_oob() and add the test case in selftest. Note that we need to add a similar check for SIOCATMARK. [0]: BUG: KASAN: slab-use-after-free in unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959 Read of size 4 at addr ffff8880326abcc4 by task syz-executor178/5235 CPU: 0 UID: 0 PID: 5235 Comm: syz-executor178 Not tainted 6.11.0-rc5-syzkaller-00742-gfbdaffe41adc #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959 unix_stream_recv_urg+0x1df/0x320 net/unix/af_unix.c:2640 unix_stream_read_generic+0x2456/0x2520 net/unix/af_unix.c:2778 unix_stream_recvmsg+0x22b/0x2c0 net/unix/af_unix.c:2996 sock_recvmsg_nosec net/socket.c:1046 [inline] sock_recvmsg+0x22f/0x280 net/socket.c:1068 ____sys_recvmsg+0x1db/0x470 net/socket.c:2816 ___sys_recvmsg net/socket.c:2858 [inline] __sys_recvmsg+0x2f0/0x3e0 net/socket.c:2888 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:0x7f5360d6b4e9 Code: 48 83 c4 28 c3 e8 37 17 00 00 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff29b3a458 EFLAGS: 00000246 ORIG_RAX: 000000000000002f RAX: ffffffffffffffda RBX: 00007fff29b3a638 RCX: 00007f5360d6b4e9 RDX: 0000000000002001 RSI: 0000000020000640 RDI: 0000000000000003 RBP: 00007f5360dde610 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 00007fff29b3a628 R14: 0000000000000001 R15: 0000000000000001 Allocated by task 5235: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:312 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slub.c:3988 [inline] slab_alloc_node mm/slub.c:4037 [inline] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4080 __alloc_skb+0x1c3/0x440 net/core/skbuff.c:667 alloc_skb include/linux/skbuff.h:1320 [inline] alloc_skb_with_frags+0xc3/0x770 net/core/skbuff.c:6528 sock_alloc_send_pskb+0x91a/0xa60 net/core/sock.c:2815 sock_alloc_send_skb include/net/sock.h:1778 [inline] queue_oob+0x108/0x680 net/unix/af_unix.c:2198 unix_stream_sendmsg+0xd24/0xf80 net/unix/af_unix.c:2351 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2680 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 Freed by task 5235: kasan_save_stack mm/kasan/common.c:47 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47712", "url": "https://ubuntu.com/security/CVE-2024-47712", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: fix potential RCU dereference issue in wilc_parse_join_bss_param In the `wilc_parse_join_bss_param` function, the TSF field of the `ies` structure is accessed after the RCU read-side critical section is unlocked. According to RCU usage rules, this is illegal. Reusing this pointer can lead to unpredictable behavior, including accessing memory that has been updated or causing use-after-free issues. This possible bug was identified using a static analysis tool developed by myself, specifically designed to detect RCU-related issues. To address this, the TSF value is now stored in a local variable `ies_tsf` before the RCU lock is released. The `param->tsf_lo` field is then assigned using this local variable, ensuring that the TSF value is safely accessed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47713", "url": "https://ubuntu.com/security/CVE-2024-47713", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop() Since '__dev_queue_xmit()' should be called with interrupts enabled, the following backtrace: ieee80211_do_stop() ... spin_lock_irqsave(&local->queue_stop_reason_lock, flags) ... ieee80211_free_txskb() ieee80211_report_used_skb() ieee80211_report_ack_skb() cfg80211_mgmt_tx_status_ext() nl80211_frame_tx_status() genlmsg_multicast_netns() genlmsg_multicast_netns_filtered() nlmsg_multicast_filtered() \t netlink_broadcast_filtered() \t do_one_broadcast() \t netlink_broadcast_deliver() \t __netlink_sendskb() \t netlink_deliver_tap() \t __netlink_deliver_tap_skb() \t dev_queue_xmit() \t __dev_queue_xmit() ; with IRQS disabled ... spin_unlock_irqrestore(&local->queue_stop_reason_lock, flags) issues the warning (as reported by syzbot reproducer): WARNING: CPU: 2 PID: 5128 at kernel/softirq.c:362 __local_bh_enable_ip+0xc3/0x120 Fix this by implementing a two-phase skb reclamation in 'ieee80211_do_stop()', where actual work is performed outside of a section with interrupts disabled.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47730", "url": "https://ubuntu.com/security/CVE-2024-47730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/qm - inject error before stopping queue The master ooo cannot be completely closed when the accelerator core reports memory error. Therefore, the driver needs to inject the qm error to close the master ooo. Currently, the qm error is injected after stopping queue, memory may be released immediately after stopping queue, causing the device to access the released memory. Therefore, error is injected to close master ooo before stopping queue to ensure that the device does not access the released memory.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49856", "url": "https://ubuntu.com/security/CVE-2024-49856", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/sgx: Fix deadlock in SGX NUMA node search When the current node doesn't have an EPC section configured by firmware and all other EPC sections are used up, CPU can get stuck inside the while loop that looks for an available EPC page from remote nodes indefinitely, leading to a soft lockup. Note how nid_of_current will never be equal to nid in that while loop because nid_of_current is not set in sgx_numa_mask. Also worth mentioning is that it's perfectly fine for the firmware not to setup an EPC section on a node. While setting up an EPC section on each node can enhance performance, it is not a requirement for functionality. Rework the loop to start and end on *a* node that has SGX memory. This avoids the deadlock looking for the current SGX-lacking node to show up in the loop when it never will.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47714", "url": "https://ubuntu.com/security/CVE-2024-47714", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: use hweight16 to get correct tx antenna The chainmask is u16 so using hweight8 cannot get correct tx_ant. Without this patch, the tx_ant of band 2 would be -1 and lead to the following issue: BUG: KASAN: stack-out-of-bounds in mt7996_mcu_add_sta+0x12e0/0x16e0 [mt7996e]", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47715", "url": "https://ubuntu.com/security/CVE-2024-47715", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: fix oops on non-dbdc mt7986 mt7915_band_config() sets band_idx = 1 on the main phy for mt7986 with MT7975_ONE_ADIE or MT7976_ONE_ADIE. Commit 0335c034e726 (\"wifi: mt76: fix race condition related to checking tx queue fill status\") introduced a dereference of the phys array indirectly indexed by band_idx via wcid->phy_idx in mt76_wcid_cleanup(). This caused the following Oops on affected mt7986 devices: Unable to handle kernel read from unreadable memory at virtual address 0000000000000024 Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x00000005 CM = 0, WnR = 0 user pgtable: 4k pages, 39-bit VAs, pgdp=0000000042545000 [0000000000000024] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 Internal error: Oops: 0000000096000005 [#1] SMP Modules linked in: ... mt7915e mt76_connac_lib mt76 mac80211 cfg80211 ... CPU: 2 PID: 1631 Comm: hostapd Not tainted 5.15.150 #0 Hardware name: ZyXEL EX5700 (Telenor) (DT) pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mt76_wcid_cleanup+0x84/0x22c [mt76] lr : mt76_wcid_cleanup+0x64/0x22c [mt76] sp : ffffffc00a803700 x29: ffffffc00a803700 x28: ffffff80008f7300 x27: ffffff80003f3c00 x26: ffffff80000a7880 x25: ffffffc008c26e00 x24: 0000000000000001 x23: ffffffc000a68114 x22: 0000000000000000 x21: ffffff8004172cc8 x20: ffffffc00a803748 x19: ffffff8004152020 x18: 0000000000000000 x17: 00000000000017c0 x16: ffffffc008ef5000 x15: 0000000000000be0 x14: ffffff8004172e28 x13: ffffff8004172e28 x12: 0000000000000000 x11: 0000000000000000 x10: ffffff8004172e30 x9 : ffffff8004172e28 x8 : 0000000000000000 x7 : ffffff8004156020 x6 : 0000000000000000 x5 : 0000000000000031 x4 : 0000000000000000 x3 : 0000000000000001 x2 : 0000000000000000 x1 : ffffff80008f7300 x0 : 0000000000000024 Call trace: mt76_wcid_cleanup+0x84/0x22c [mt76] __mt76_sta_remove+0x70/0xbc [mt76] mt76_sta_state+0x8c/0x1a4 [mt76] mt7915_eeprom_get_power_delta+0x11e4/0x23a0 [mt7915e] drv_sta_state+0x144/0x274 [mac80211] sta_info_move_state+0x1cc/0x2a4 [mac80211] sta_set_sinfo+0xaf8/0xc24 [mac80211] sta_info_destroy_addr_bss+0x4c/0x6c [mac80211] ieee80211_color_change_finish+0x1c08/0x1e70 [mac80211] cfg80211_check_station_change+0x1360/0x4710 [cfg80211] genl_family_rcv_msg_doit+0xb4/0x110 genl_rcv_msg+0xd0/0x1bc netlink_rcv_skb+0x58/0x120 genl_rcv+0x34/0x50 netlink_unicast+0x1f0/0x2ec netlink_sendmsg+0x198/0x3d0 ____sys_sendmsg+0x1b0/0x210 ___sys_sendmsg+0x80/0xf0 __sys_sendmsg+0x44/0xa0 __arm64_sys_sendmsg+0x20/0x30 invoke_syscall.constprop.0+0x4c/0xe0 do_el0_svc+0x40/0xd0 el0_svc+0x14/0x4c el0t_64_sync_handler+0x100/0x110 el0t_64_sync+0x15c/0x160 Code: d2800002 910092c0 52800023 f9800011 (885f7c01) ---[ end trace 7e42dd9a39ed2281 ]--- Fix by using mt76_dev_phy() which will map band_idx to the correct phy for all hardware combinations.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49857", "url": "https://ubuntu.com/security/CVE-2024-49857", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: set the cipher for secured NDP ranging The cipher pointer is not set, but is derefereced trying to set its content, which leads to a NULL pointer dereference. Fix it by pointing to the cipher parameter before dereferencing.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47738", "url": "https://ubuntu.com/security/CVE-2024-47738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: don't use rate mask for offchannel TX either Like the commit ab9177d83c04 (\"wifi: mac80211: don't use rate mask for scanning\"), ignore incorrect settings to avoid no supported rate warning reported by syzbot. The syzbot did bisect and found cause is commit 9df66d5b9f45 (\"cfg80211: fix default HE tx bitrate mask in 2G band\"), which however corrects bitmask of HE MCS and recognizes correctly settings of empty legacy rate plus HE MCS rate instead of returning -EINVAL. As suggestions [1], follow the change of SCAN TX to consider this case of offchannel TX as well. [1] https://lore.kernel.org/linux-wireless/6ab2dc9c3afe753ca6fdcdd1421e7a1f47e87b84.camel@sipsolutions.net/T/#m2ac2a6d2be06a37c9c47a3d8a44b4f647ed4f024", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47731", "url": "https://ubuntu.com/security/CVE-2024-47731", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers/perf: Fix ali_drw_pmu driver interrupt status clearing The alibaba_uncore_pmu driver forgot to clear all interrupt status in the interrupt processing function. After the PMU counter overflow interrupt occurred, an interrupt storm occurred, causing the system to hang. Therefore, clear the correct interrupt status in the interrupt handling function to fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49862", "url": "https://ubuntu.com/security/CVE-2024-49862", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powercap: intel_rapl: Fix off by one in get_rpi() The rp->priv->rpi array is either rpi_msr or rpi_tpmi which have NR_RAPL_PRIMITIVES number of elements. Thus the > needs to be >= to prevent an off by one access.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47716", "url": "https://ubuntu.com/security/CVE-2024-47716", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: 9410/1: vfp: Use asm volatile in fmrx/fmxr macros Floating point instructions in userspace can crash some arm kernels built with clang/LLD 17.0.6: BUG: unsupported FP instruction in kernel mode FPEXC == 0xc0000780 Internal error: Oops - undefined instruction: 0 [#1] ARM CPU: 0 PID: 196 Comm: vfp-reproducer Not tainted 6.10.0 #1 Hardware name: BCM2835 PC is at vfp_support_entry+0xc8/0x2cc LR is at do_undefinstr+0xa8/0x250 pc : [] lr : [] psr: a0000013 sp : dc8d1f68 ip : 60000013 fp : bedea19c r10: ec532b17 r9 : 00000010 r8 : 0044766c r7 : c0000780 r6 : ec532b17 r5 : c1c13800 r4 : dc8d1fb0 r3 : c10072c4 r2 : c0101c88 r1 : ec532b17 r0 : 0044766c Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 00c5387d Table: 0251c008 DAC: 00000051 Register r0 information: non-paged memory Register r1 information: vmalloc memory Register r2 information: non-slab/vmalloc memory Register r3 information: non-slab/vmalloc memory Register r4 information: 2-page vmalloc region Register r5 information: slab kmalloc-cg-2k Register r6 information: vmalloc memory Register r7 information: non-slab/vmalloc memory Register r8 information: non-paged memory Register r9 information: zero-size pointer Register r10 information: vmalloc memory Register r11 information: non-paged memory Register r12 information: non-paged memory Process vfp-reproducer (pid: 196, stack limit = 0x61aaaf8b) Stack: (0xdc8d1f68 to 0xdc8d2000) 1f60: 0000081f b6f69300 0000000f c10073f4 c10072c4 dc8d1fb0 1f80: ec532b17 0c532b17 0044766c b6f9ccd8 00000000 c010a80c 00447670 60000010 1fa0: ffffffff c1c13800 00c5387d c0100f10 b6f68af8 00448fc0 00000000 bedea188 1fc0: bedea314 00000001 00448ebc b6f9d000 00447608 b6f9ccd8 00000000 bedea19c 1fe0: bede9198 bedea188 b6e1061c 0044766c 60000010 ffffffff 00000000 00000000 Call trace: [] (vfp_support_entry) from [] (do_undefinstr+0xa8/0x250) [] (do_undefinstr) from [] (__und_usr+0x70/0x80) Exception stack(0xdc8d1fb0 to 0xdc8d1ff8) 1fa0: b6f68af8 00448fc0 00000000 bedea188 1fc0: bedea314 00000001 00448ebc b6f9d000 00447608 b6f9ccd8 00000000 bedea19c 1fe0: bede9198 bedea188 b6e1061c 0044766c 60000010 ffffffff Code: 0a000061 e3877202 e594003c e3a09010 (eef16a10) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Fatal exception in interrupt ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]--- This is a minimal userspace reproducer on a Raspberry Pi Zero W: #include #include int main(void) { double v = 1.0; printf(\"%fn\", NAN + *(volatile double *)&v); return 0; } Another way to consistently trigger the oops is: calvin@raspberry-pi-zero-w ~$ python -c \"import json\" The bug reproduces only when the kernel is built with DYNAMIC_DEBUG=n, because the pr_debug() calls act as barriers even when not activated. This is the output from the same kernel source built with the same compiler and DYNAMIC_DEBUG=y, where the userspace reproducer works as expected: VFP: bounce: trigger ec532b17 fpexc c0000780 VFP: emulate: INST=0xee377b06 SCR=0x00000000 VFP: bounce: trigger eef1fa10 fpexc c0000780 VFP: emulate: INST=0xeeb40b40 SCR=0x00000000 VFP: raising exceptions 30000000 calvin@raspberry-pi-zero-w ~$ ./vfp-reproducer nan Crudely grepping for vmsr/vmrs instructions in the otherwise nearly idential text for vfp_support_entry() makes the problem obvious: vmlinux.llvm.good [0xc0101cb8] <+48>: vmrs r7, fpexc vmlinux.llvm.good [0xc0101cd8] <+80>: vmsr fpexc, r0 vmlinux.llvm.good [0xc0101d20 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47717", "url": "https://ubuntu.com/security/CVE-2024-47717", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RISC-V: KVM: Don't zero-out PMU snapshot area before freeing data With the latest Linux-6.11-rc3, the below NULL pointer crash is observed when SBI PMU snapshot is enabled for the guest and the guest is forcefully powered-off. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000508 Oops [#1] Modules linked in: kvm CPU: 0 UID: 0 PID: 61 Comm: term-poll Not tainted 6.11.0-rc3-00018-g44d7178dd77a #3 Hardware name: riscv-virtio,qemu (DT) epc : __kvm_write_guest_page+0x94/0xa6 [kvm] ra : __kvm_write_guest_page+0x54/0xa6 [kvm] epc : ffffffff01590e98 ra : ffffffff01590e58 sp : ffff8f80001f39b0 gp : ffffffff81512a60 tp : ffffaf80024872c0 t0 : ffffaf800247e000 t1 : 00000000000007e0 t2 : 0000000000000000 s0 : ffff8f80001f39f0 s1 : 00007fff89ac4000 a0 : ffffffff015dd7e8 a1 : 0000000000000086 a2 : 0000000000000000 a3 : ffffaf8000000000 a4 : ffffaf80024882c0 a5 : 0000000000000000 a6 : ffffaf800328d780 a7 : 00000000000001cc s2 : ffffaf800197bd00 s3 : 00000000000828c4 s4 : ffffaf800248c000 s5 : ffffaf800247d000 s6 : 0000000000001000 s7 : 0000000000001000 s8 : 0000000000000000 s9 : 00007fff861fd500 s10: 0000000000000001 s11: 0000000000800000 t3 : 00000000000004d3 t4 : 00000000000004d3 t5 : ffffffff814126e0 t6 : ffffffff81412700 status: 0000000200000120 badaddr: 0000000000000508 cause: 000000000000000d [] __kvm_write_guest_page+0x94/0xa6 [kvm] [] kvm_vcpu_write_guest+0x56/0x90 [kvm] [] kvm_pmu_clear_snapshot_area+0x42/0x7e [kvm] [] kvm_riscv_vcpu_pmu_deinit.part.0+0xe0/0x14e [kvm] [] kvm_riscv_vcpu_pmu_deinit+0x1a/0x24 [kvm] [] kvm_arch_vcpu_destroy+0x28/0x4c [kvm] [] kvm_destroy_vcpus+0x5a/0xda [kvm] [] kvm_arch_destroy_vm+0x14/0x28 [kvm] [] kvm_destroy_vm+0x168/0x2a0 [kvm] [] kvm_put_kvm+0x3c/0x58 [kvm] [] kvm_vm_release+0x22/0x2e [kvm] Clearly, the kvm_vcpu_write_guest() function is crashing because it is being called from kvm_pmu_clear_snapshot_area() upon guest tear down. To address the above issue, simplify the kvm_pmu_clear_snapshot_area() to not zero-out PMU snapshot area from kvm_pmu_clear_snapshot_area() because the guest is anyway being tore down. The kvm_pmu_clear_snapshot_area() is also called when guest changes PMU snapshot area of a VCPU but even in this case the previous PMU snaphsot area must not be zeroed-out because the guest might have reclaimed the pervious PMU snapshot area for some other purpose.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47721", "url": "https://ubuntu.com/security/CVE-2024-47721", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: remove unused C2H event ID RTW89_MAC_C2H_FUNC_READ_WOW_CAM to prevent out-of-bounds reading The handler of firmware C2H event RTW89_MAC_C2H_FUNC_READ_WOW_CAM isn't implemented, but driver expects number of handlers is NUM_OF_RTW89_MAC_C2H_FUNC_WOW causing out-of-bounds access. Fix it by removing ID. Addresses-Coverity-ID: 1598775 (\"Out-of-bounds read\")", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47732", "url": "https://ubuntu.com/security/CVE-2024-47732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: iaa - Fix potential use after free bug The free_device_compression_mode(iaa_device, device_mode) function frees \"device_mode\" but it iss passed to iaa_compression_modes[i]->free() a few lines later resulting in a use after free. The good news is that, so far as I can tell, nothing implements the ->free() function and the use after free happens in dead code. But, with this fix, when something does implement it, we'll be ready. :)", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47718", "url": "https://ubuntu.com/security/CVE-2024-47718", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: always wait for both firmware loading attempts In 'rtw_wait_firmware_completion()', always wait for both (regular and wowlan) firmware loading attempts. Otherwise if 'rtw_usb_intf_init()' has failed in 'rtw_usb_probe()', 'rtw_usb_disconnect()' may issue 'ieee80211_free_hw()' when one of 'rtw_load_firmware_cb()' (usually the wowlan one) is still in progress, causing UAF detected by KASAN.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47724", "url": "https://ubuntu.com/security/CVE-2024-47724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: use work queue to process beacon tx event Commit 3a415daa3e8b (\"wifi: ath11k: add P2P IE in beacon template\") from Feb 28, 2024 (linux-next), leads to the following Smatch static checker warning: drivers/net/wireless/ath/ath11k/wmi.c:1742 ath11k_wmi_p2p_go_bcn_ie() warn: sleeping in atomic context The reason is that ath11k_bcn_tx_status_event() will directly call might sleep function ath11k_wmi_cmd_send() during RCU read-side critical sections. The call trace is like: ath11k_bcn_tx_status_event() -> rcu_read_lock() -> ath11k_mac_bcn_tx_event() \t-> ath11k_mac_setup_bcn_tmpl() \t…… \t\t-> ath11k_wmi_bcn_tmpl() \t\t\t-> ath11k_wmi_cmd_send() -> rcu_read_unlock() Commit 886433a98425 (\"ath11k: add support for BSS color change\") added the ath11k_mac_bcn_tx_event(), commit 01e782c89108 (\"ath11k: fix warning of RCU usage for ath11k_mac_get_arvif_by_vdev_id()\") added the RCU lock to avoid warning but also introduced this BUG. Use work queue to avoid directly calling ath11k_mac_bcn_tx_event() during RCU critical sections. No need to worry about the deletion of vif because cancel_work_sync() will drop the work if it doesn't start or block vif deletion until the running work is done. 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": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47671", "url": "https://ubuntu.com/security/CVE-2024-47671", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: usbtmc: prevent kernel-usb-infoleak The syzbot reported a kernel-usb-infoleak in usbtmc_write, we need to clear the structure before filling fields.", "cve_priority": "medium", "cve_public_date": "2024-10-09 15:15:00 UTC" }, { "cve": "CVE-2024-46869", "url": "https://ubuntu.com/security/CVE-2024-46869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btintel_pcie: Allocate memory for driver private data Fix driver not allocating memory for struct btintel_data which is used to store internal data.", "cve_priority": "medium", "cve_public_date": "2024-09-30 16:15:00 UTC" }, { "cve": "CVE-2024-53164", "url": "https://ubuntu.com/security/CVE-2024-53164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: fix ordering of qlen adjustment Changes to sch->q.qlen around qdisc_tree_reduce_backlog() need to happen _before_ a call to said function because otherwise it may fail to notify parent qdiscs when the child is about to become empty.", "cve_priority": "medium", "cve_public_date": "2024-12-27 14:15:00 UTC" }, { "cve": "CVE-2024-53103", "url": "https://ubuntu.com/security/CVE-2024-53103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hv_sock: Initializing vsk->trans to NULL to prevent a dangling pointer When hvs is released, there is a possibility that vsk->trans may not be initialized to NULL, which could lead to a dangling pointer. This issue is resolved by initializing vsk->trans to NULL.", "cve_priority": "high", "cve_public_date": "2024-12-02 08:15:00 UTC" } ], "launchpad_bugs_fixed": [ 2093643, 1786013, 2091744, 2091184, 2093146, 2085406, 2089684, 2090932, 2085485, 2089357, 2089306, 2091655, 2091655, 2091655, 2091655, 2091655, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091386, 2091990, 2089327, 2089113, 2086587, 2086606, 2085950, 2085944, 2087853, 2087983, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089020, 2089020, 2089020 ], "changes": [ { "cves": [ { "cve": "CVE-2025-0927", "url": "https://ubuntu.com/security/CVE-2025-0927", "cve_description": "[fs: hfs/hfsplus: add key_len boundary check to hfs_bnode_read_key]", "cve_priority": "medium", "cve_public_date": "2025-02-13" } ], "log": [ "", " * CVE-2025-0927", " - SAUCE: fs: hfs/hfsplus: add key_len boundary check to hfs_bnode_read_key", "" ], "package": "linux", "version": "6.11.0-18.18", "urgency": "medium", "distributions": "oracular", "launchpad_bugs_fixed": [], "author": "Manuel Diewald ", "date": "Fri, 07 Feb 2025 18:44:32 +0100" }, { "cves": [ { "cve": "CVE-2024-53141", "url": "https://ubuntu.com/security/CVE-2024-53141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: add missing range check in bitmap_ip_uadt When tb[IPSET_ATTR_IP_TO] is not present but tb[IPSET_ATTR_CIDR] exists, the values of ip and ip_to are slightly swapped. Therefore, the range check for ip should be done later, but this part is missing and it seems that the vulnerability occurs. So we should add missing range checks and remove unnecessary range checks.", "cve_priority": "medium", "cve_public_date": "2024-12-06 10:15:00 UTC" }, { "cve": "CVE-2024-50010", "url": "https://ubuntu.com/security/CVE-2024-50010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exec: don't WARN for racy path_noexec check Both i_mode and noexec checks wrapped in WARN_ON stem from an artifact of the previous implementation. They used to legitimately check for the condition, but that got moved up in two commits: 633fb6ac3980 (\"exec: move S_ISREG() check earlier\") 0fd338b2d2cd (\"exec: move path_noexec() check earlier\") Instead of being removed said checks are WARN_ON'ed instead, which has some debug value. However, the spurious path_noexec check is racy, resulting in unwarranted warnings should someone race with setting the noexec flag. One can note there is more to perm-checking whether execve is allowed and none of the conditions are guaranteed to still hold after they were tested for. Additionally this does not validate whether the code path did any perm checking to begin with -- it will pass if the inode happens to be regular. Keep the redundant path_noexec() check even though it's mindless nonsense checking for guarantee that isn't given so drop the WARN. Reword the commentary and do small tidy ups while here. [brauner: keep redundant path_noexec() check]", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-53143", "url": "https://ubuntu.com/security/CVE-2024-53143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fsnotify: Fix ordering of iput() and watched_objects decrement Ensure the superblock is kept alive until we're done with iput(). Holding a reference to an inode is not allowed unless we ensure the superblock stays alive, which fsnotify does by keeping the watched_objects count elevated, so iput() must happen before the watched_objects decrement. This can lead to a UAF of something like sb->s_fs_info in tmpfs, but the UAF is hard to hit because race orderings that oops are more likely, thanks to the CHECK_DATA_CORRUPTION() block in generic_shutdown_super(). Also, ensure that fsnotify_put_sb_watched_objects() doesn't call fsnotify_sb_watched_objects() on a superblock that may have already been freed, which would cause a UAF read of sb->s_fsnotify_info.", "cve_priority": "medium", "cve_public_date": "2024-12-07 07:15:00 UTC" }, { "cve": "CVE-2024-53142", "url": "https://ubuntu.com/security/CVE-2024-53142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: initramfs: avoid filename buffer overrun The initramfs filename field is defined in Documentation/driver-api/early-userspace/buffer-format.rst as: 37 cpio_file := ALGN(4) + cpio_header + filename + \"\\0\" + ALGN(4) + data ... 55 ============= ================== ========================= 56 Field name Field size Meaning 57 ============= ================== ========================= ... 70 c_namesize 8 bytes Length of filename, including final \\0 When extracting an initramfs cpio archive, the kernel's do_name() path handler assumes a zero-terminated path at @collected, passing it directly to filp_open() / init_mkdir() / init_mknod(). If a specially crafted cpio entry carries a non-zero-terminated filename and is followed by uninitialized memory, then a file may be created with trailing characters that represent the uninitialized memory. The ability to create an initramfs entry would imply already having full control of the system, so the buffer overrun shouldn't be considered a security vulnerability. Append the output of the following bash script to an existing initramfs and observe any created /initramfs_test_fname_overrunAA* path. E.g. ./reproducer.sh | gzip >> /myinitramfs It's easiest to observe non-zero uninitialized memory when the output is gzipped, as it'll overflow the heap allocated @out_buf in __gunzip(), rather than the initrd_start+initrd_size block. ---- reproducer.sh ---- nilchar=\"A\"\t# change to \"\\0\" to properly zero terminate / pad magic=\"070701\" ino=1 mode=$(( 0100777 )) uid=0 gid=0 nlink=1 mtime=1 filesize=0 devmajor=0 devminor=1 rdevmajor=0 rdevminor=0 csum=0 fname=\"initramfs_test_fname_overrun\" namelen=$(( ${#fname} + 1 ))\t# plus one to account for terminator printf \"%s%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%s\" \\ \t$magic $ino $mode $uid $gid $nlink $mtime $filesize \\ \t$devmajor $devminor $rdevmajor $rdevminor $namelen $csum $fname termpadlen=$(( 1 + ((4 - ((110 + $namelen) & 3)) % 4) )) printf \"%.s${nilchar}\" $(seq 1 $termpadlen) ---- reproducer.sh ---- Symlink filename fields handled in do_symlink() won't overrun past the data segment, due to the explicit zero-termination of the symlink target. Fix filename buffer overrun by aborting the initramfs FSM if any cpio entry doesn't carry a zero-terminator at the expected (name_len - 1) offset.", "cve_priority": "medium", "cve_public_date": "2024-12-06 10:15:00 UTC" }, { "cve": "CVE-2024-53133", "url": "https://ubuntu.com/security/CVE-2024-53133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Handle dml allocation failure to avoid crash [Why] In the case where a dml allocation fails for any reason, the current state's dml contexts would no longer be valid. Then subsequent calls dc_state_copy_internal would shallow copy invalid memory and if the new state was released, a double free would occur. [How] Reset dml pointers in new_state to NULL and avoid invalid pointer (cherry picked from commit bcafdc61529a48f6f06355d78eb41b3aeda5296c)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53108", "url": "https://ubuntu.com/security/CVE-2024-53108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Adjust VSDB parser for replay feature At some point, the IEEE ID identification for the replay check in the AMD EDID was added. However, this check causes the following out-of-bounds issues when using KASAN: [ 27.804016] BUG: KASAN: slab-out-of-bounds in amdgpu_dm_update_freesync_caps+0xefa/0x17a0 [amdgpu] [ 27.804788] Read of size 1 at addr ffff8881647fdb00 by task systemd-udevd/383 ... [ 27.821207] Memory state around the buggy address: [ 27.821215] ffff8881647fda00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821224] ffff8881647fda80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821234] >ffff8881647fdb00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821243] ^ [ 27.821250] ffff8881647fdb80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821259] ffff8881647fdc00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821268] ================================================================== This is caused because the ID extraction happens outside of the range of the edid lenght. This commit addresses this issue by considering the amd_vsdb_block size. (cherry picked from commit b7e381b1ccd5e778e3d9c44c669ad38439a861d8)", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53134", "url": "https://ubuntu.com/security/CVE-2024-53134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pmdomain: imx93-blk-ctrl: correct remove path The check condition should be 'i < bc->onecell_data.num_domains', not 'bc->onecell_data.num_domains' which will make the look never finish and cause kernel panic. Also disable runtime to address \"imx93-blk-ctrl 4ac10000.system-controller: Unbalanced pm_runtime_enable!\"", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53132", "url": "https://ubuntu.com/security/CVE-2024-53132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/oa: Fix \"Missing outer runtime PM protection\" warning Fix the following drm_WARN: [953.586396] xe 0000:00:02.0: [drm] Missing outer runtime PM protection ... <4> [953.587090] ? xe_pm_runtime_get_noresume+0x8d/0xa0 [xe] <4> [953.587208] guc_exec_queue_add_msg+0x28/0x130 [xe] <4> [953.587319] guc_exec_queue_fini+0x3a/0x40 [xe] <4> [953.587425] xe_exec_queue_destroy+0xb3/0xf0 [xe] <4> [953.587515] xe_oa_release+0x9c/0xc0 [xe] (cherry picked from commit b107c63d2953907908fd0cafb0e543b3c3167b75)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53127", "url": "https://ubuntu.com/security/CVE-2024-53127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Revert \"mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K\" The commit 8396c793ffdf (\"mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K\") increased the max_req_size, even for 4K pages, causing various issues: - Panic booting the kernel/rootfs from an SD card on Rockchip RK3566 - Panic booting the kernel/rootfs from an SD card on StarFive JH7100 - \"swiotlb buffer is full\" and data corruption on StarFive JH7110 At this stage no fix have been found, so it's probably better to just revert the change. This reverts commit 8396c793ffdf28bb8aee7cfe0891080f8cab7890.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53130", "url": "https://ubuntu.com/security/CVE-2024-53130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint When using the \"block:block_dirty_buffer\" tracepoint, mark_buffer_dirty() may cause a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because, since the tracepoint was added in mark_buffer_dirty(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, nilfs_grab_buffer(), which grabs a buffer to read (or create) a block of metadata, including b-tree node blocks, does not set the block device, but instead does so only if the buffer is not in the \"uptodate\" state for each of its caller block reading functions. However, if the uptodate flag is set on a folio/page, and the buffer heads are detached from it by try_to_free_buffers(), and new buffer heads are then attached by create_empty_buffers(), the uptodate flag may be restored to each buffer without the block device being set to bh->b_bdev, and mark_buffer_dirty() may be called later in that state, resulting in the bug mentioned above. Fix this issue by making nilfs_grab_buffer() always set the block device of the super block structure to the buffer head, regardless of the state of the buffer's uptodate flag.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53105", "url": "https://ubuntu.com/security/CVE-2024-53105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: page_alloc: move mlocked flag clearance into free_pages_prepare() Syzbot reported a bad page state problem caused by a page being freed using free_page() still having a mlocked flag at free_pages_prepare() stage: BUG: Bad page state in process syz.5.504 pfn:61f45 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x61f45 flags: 0xfff00000080204(referenced|workingset|mlocked|node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000080204 0000000000000000 dead000000000122 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set page_owner tracks the page as allocated page last allocated via order 0, migratetype Unmovable, gfp_mask 0x400dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO), pid 8443, tgid 8442 (syz.5.504), ts 201884660643, free_ts 201499827394 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1537 prep_new_page mm/page_alloc.c:1545 [inline] get_page_from_freelist+0x303f/0x3190 mm/page_alloc.c:3457 __alloc_pages_noprof+0x292/0x710 mm/page_alloc.c:4733 alloc_pages_mpol_noprof+0x3e8/0x680 mm/mempolicy.c:2265 kvm_coalesced_mmio_init+0x1f/0xf0 virt/kvm/coalesced_mmio.c:99 kvm_create_vm virt/kvm/kvm_main.c:1235 [inline] kvm_dev_ioctl_create_vm virt/kvm/kvm_main.c:5488 [inline] kvm_dev_ioctl+0x12dc/0x2240 virt/kvm/kvm_main.c:5530 __do_compat_sys_ioctl fs/ioctl.c:1007 [inline] __se_compat_sys_ioctl+0x510/0xc90 fs/ioctl.c:950 do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline] __do_fast_syscall_32+0xb4/0x110 arch/x86/entry/common.c:386 do_fast_syscall_32+0x34/0x80 arch/x86/entry/common.c:411 entry_SYSENTER_compat_after_hwframe+0x84/0x8e page last free pid 8399 tgid 8399 stack trace: reset_page_owner include/linux/page_owner.h:25 [inline] free_pages_prepare mm/page_alloc.c:1108 [inline] free_unref_folios+0xf12/0x18d0 mm/page_alloc.c:2686 folios_put_refs+0x76c/0x860 mm/swap.c:1007 free_pages_and_swap_cache+0x5c8/0x690 mm/swap_state.c:335 __tlb_batch_free_encoded_pages mm/mmu_gather.c:136 [inline] tlb_batch_pages_flush mm/mmu_gather.c:149 [inline] tlb_flush_mmu_free mm/mmu_gather.c:366 [inline] tlb_flush_mmu+0x3a3/0x680 mm/mmu_gather.c:373 tlb_finish_mmu+0xd4/0x200 mm/mmu_gather.c:465 exit_mmap+0x496/0xc40 mm/mmap.c:1926 __mmput+0x115/0x390 kernel/fork.c:1348 exit_mm+0x220/0x310 kernel/exit.c:571 do_exit+0x9b2/0x28e0 kernel/exit.c:926 do_group_exit+0x207/0x2c0 kernel/exit.c:1088 __do_sys_exit_group kernel/exit.c:1099 [inline] __se_sys_exit_group kernel/exit.c:1097 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1097 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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 Modules linked in: CPU: 0 UID: 0 PID: 8442 Comm: syz.5.504 Not tainted 6.12.0-rc6-syzkaller #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 bad_page+0x176/0x1d0 mm/page_alloc.c:501 free_page_is_bad mm/page_alloc.c:918 [inline] free_pages_prepare mm/page_alloc.c:1100 [inline] free_unref_page+0xed0/0xf20 mm/page_alloc.c:2638 kvm_destroy_vm virt/kvm/kvm_main.c:1327 [inline] kvm_put_kvm+0xc75/0x1350 virt/kvm/kvm_main.c:1386 kvm_vcpu_release+0x54/0x60 virt/kvm/kvm_main.c:4143 __fput+0x23f/0x880 fs/file_table.c:431 task_work_run+0x24f/0x310 kernel/task_work.c:239 exit_task_work include/linux/task_work.h:43 [inline] do_exit+0xa2f/0x28e0 kernel/exit.c:939 do_group_exit+0x207/0x2c0 kernel/exit.c:1088 __do_sys_exit_group kernel/exit.c:1099 [in ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53109", "url": "https://ubuntu.com/security/CVE-2024-53109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nommu: pass NULL argument to vma_iter_prealloc() When deleting a vma entry from a maple tree, it has to pass NULL to vma_iter_prealloc() in order to calculate internal state of the tree, but it passed a wrong argument. As a result, nommu kernels crashed upon accessing a vma iterator, such as acct_collect() reading the size of vma entries after do_munmap(). This commit fixes this issue by passing a right argument to the preallocation call.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53131", "url": "https://ubuntu.com/security/CVE-2024-53131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint Patch series \"nilfs2: fix null-ptr-deref bugs on block tracepoints\". This series fixes null pointer dereference bugs that occur when using nilfs2 and two block-related tracepoints. This patch (of 2): It has been reported that when using \"block:block_touch_buffer\" tracepoint, touch_buffer() called from __nilfs_get_folio_block() causes a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because since the tracepoint was added in touch_buffer(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, the block_device structure is set after the function returns to the caller. Here, touch_buffer() is used to mark the folio/page that owns the buffer head as accessed, but the common search helper for folio/page used by the caller function was optimized to mark the folio/page as accessed when it was reimplemented a long time ago, eliminating the need to call touch_buffer() here in the first place. So this solves the issue by eliminating the touch_buffer() call itself.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53135", "url": "https://ubuntu.com/security/CVE-2024-53135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: VMX: Bury Intel PT virtualization (guest/host mode) behind CONFIG_BROKEN Hide KVM's pt_mode module param behind CONFIG_BROKEN, i.e. disable support for virtualizing Intel PT via guest/host mode unless BROKEN=y. There are myriad bugs in the implementation, some of which are fatal to the guest, and others which put the stability and health of the host at risk. For guest fatalities, the most glaring issue is that KVM fails to ensure tracing is disabled, and *stays* disabled prior to VM-Enter, which is necessary as hardware disallows loading (the guest's) RTIT_CTL if tracing is enabled (enforced via a VMX consistency check). Per the SDM: If the logical processor is operating with Intel PT enabled (if IA32_RTIT_CTL.TraceEn = 1) at the time of VM entry, the \"load IA32_RTIT_CTL\" VM-entry control must be 0. On the host side, KVM doesn't validate the guest CPUID configuration provided by userspace, and even worse, uses the guest configuration to decide what MSRs to save/load at VM-Enter and VM-Exit. E.g. configuring guest CPUID to enumerate more address ranges than are supported in hardware will result in KVM trying to passthrough, save, and load non-existent MSRs, which generates a variety of WARNs, ToPA ERRORs in the host, a potential deadlock, etc.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53106", "url": "https://ubuntu.com/security/CVE-2024-53106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: fix buffer overrun in ima_eventdigest_init_common Function ima_eventdigest_init() calls ima_eventdigest_init_common() with HASH_ALGO__LAST which is then used to access the array hash_digest_size[] leading to buffer overrun. Have a conditional statement to handle this.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53110", "url": "https://ubuntu.com/security/CVE-2024-53110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vp_vdpa: fix id_table array not null terminated error Allocate one extra virtio_device_id as null terminator, otherwise vdpa_mgmtdev_get_classes() may iterate multiple times and visit undefined memory.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53126", "url": "https://ubuntu.com/security/CVE-2024-53126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa: solidrun: Fix UB bug with devres In psnet_open_pf_bar() and snet_open_vf_bar() a string later passed to pcim_iomap_regions() is placed on the stack. Neither pcim_iomap_regions() nor the functions it calls copy that string. Should the string later ever be used, this, consequently, causes undefined behavior since the stack frame will by then have disappeared. Fix the bug by allocating the strings on the heap through devm_kasprintf().", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53111", "url": "https://ubuntu.com/security/CVE-2024-53111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mremap: fix address wraparound in move_page_tables() On 32-bit platforms, it is possible for the expression `len + old_addr < old_end` to be false-positive if `len + old_addr` wraps around. `old_addr` is the cursor in the old range up to which page table entries have been moved; so if the operation succeeded, `old_addr` is the *end* of the old region, and adding `len` to it can wrap. The overflow causes mremap() to mistakenly believe that PTEs have been copied; the consequence is that mremap() bails out, but doesn't move the PTEs back before the new VMA is unmapped, causing anonymous pages in the region to be lost. So basically if userspace tries to mremap() a private-anon region and hits this bug, mremap() will return an error and the private-anon region's contents appear to have been zeroed. The idea of this check is that `old_end - len` is the original start address, and writing the check that way also makes it easier to read; so fix the check by rearranging the comparison accordingly. (An alternate fix would be to refactor this function by introducing an \"orig_old_start\" variable or such.) Tested in a VM with a 32-bit X86 kernel; without the patch: ``` user@horn:~/big_mremap$ cat test.c #define _GNU_SOURCE #include #include #include #include #define ADDR1 ((void*)0x60000000) #define ADDR2 ((void*)0x10000000) #define SIZE 0x50000000uL int main(void) { unsigned char *p1 = mmap(ADDR1, SIZE, PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0); if (p1 == MAP_FAILED) err(1, \"mmap 1\"); unsigned char *p2 = mmap(ADDR2, SIZE, PROT_NONE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0); if (p2 == MAP_FAILED) err(1, \"mmap 2\"); *p1 = 0x41; printf(\"first char is 0x%02hhx\\n\", *p1); unsigned char *p3 = mremap(p1, SIZE, SIZE, MREMAP_MAYMOVE|MREMAP_FIXED, p2); if (p3 == MAP_FAILED) { printf(\"mremap() failed; first char is 0x%02hhx\\n\", *p1); } else { printf(\"mremap() succeeded; first char is 0x%02hhx\\n\", *p3); } } user@horn:~/big_mremap$ gcc -static -o test test.c user@horn:~/big_mremap$ setarch -R ./test first char is 0x41 mremap() failed; first char is 0x00 ``` With the patch: ``` user@horn:~/big_mremap$ setarch -R ./test first char is 0x41 mremap() succeeded; first char is 0x41 ```", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53107", "url": "https://ubuntu.com/security/CVE-2024-53107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: prevent integer overflow in pagemap_scan_get_args() The \"arg->vec_len\" variable is a u64 that comes from the user at the start of the function. The \"arg->vec_len * sizeof(struct page_region))\" multiplication can lead to integer wrapping. Use size_mul() to avoid that. Also the size_add/mul() functions work on unsigned long so for 32bit systems we need to ensure that \"arg->vec_len\" fits in an unsigned long.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53128", "url": "https://ubuntu.com/security/CVE-2024-53128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/task_stack: fix object_is_on_stack() for KASAN tagged pointers When CONFIG_KASAN_SW_TAGS and CONFIG_KASAN_STACK are enabled, the object_is_on_stack() function may produce incorrect results due to the presence of tags in the obj pointer, while the stack pointer does not have tags. This discrepancy can lead to incorrect stack object detection and subsequently trigger warnings if CONFIG_DEBUG_OBJECTS is also enabled. Example of the warning: ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at lib/debugobjects.c:557 __debug_object_init+0x330/0x364 Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5 #4 Hardware name: linux,dummy-virt (DT) pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __debug_object_init+0x330/0x364 lr : __debug_object_init+0x330/0x364 sp : ffff800082ea7b40 x29: ffff800082ea7b40 x28: 98ff0000c0164518 x27: 98ff0000c0164534 x26: ffff800082d93ec8 x25: 0000000000000001 x24: 1cff0000c00172a0 x23: 0000000000000000 x22: ffff800082d93ed0 x21: ffff800081a24418 x20: 3eff800082ea7bb0 x19: efff800000000000 x18: 0000000000000000 x17: 00000000000000ff x16: 0000000000000047 x15: 206b63617473206e x14: 0000000000000018 x13: ffff800082ea7780 x12: 0ffff800082ea78e x11: 0ffff800082ea790 x10: 0ffff800082ea79d x9 : 34d77febe173e800 x8 : 34d77febe173e800 x7 : 0000000000000001 x6 : 0000000000000001 x5 : feff800082ea74b8 x4 : ffff800082870a90 x3 : ffff80008018d3c4 x2 : 0000000000000001 x1 : ffff800082858810 x0 : 0000000000000050 Call trace: __debug_object_init+0x330/0x364 debug_object_init_on_stack+0x30/0x3c schedule_hrtimeout_range_clock+0xac/0x26c schedule_hrtimeout+0x1c/0x30 wait_task_inactive+0x1d4/0x25c kthread_bind_mask+0x28/0x98 init_rescuer+0x1e8/0x280 workqueue_init+0x1a0/0x3cc kernel_init_freeable+0x118/0x200 kernel_init+0x28/0x1f0 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53112", "url": "https://ubuntu.com/security/CVE-2024-53112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: uncache inode which has failed entering the group Syzbot has reported the following BUG: kernel BUG at fs/ocfs2/uptodate.c:509! ... Call Trace: ? __die_body+0x5f/0xb0 ? die+0x9e/0xc0 ? do_trap+0x15a/0x3a0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? do_error_trap+0x1dc/0x2c0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? __pfx_do_error_trap+0x10/0x10 ? handle_invalid_op+0x34/0x40 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? exc_invalid_op+0x38/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? ocfs2_set_new_buffer_uptodate+0x2e/0x160 ? ocfs2_set_new_buffer_uptodate+0x144/0x160 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ocfs2_group_add+0x39f/0x15a0 ? __pfx_ocfs2_group_add+0x10/0x10 ? __pfx_lock_acquire+0x10/0x10 ? mnt_get_write_access+0x68/0x2b0 ? __pfx_lock_release+0x10/0x10 ? rcu_read_lock_any_held+0xb7/0x160 ? __pfx_rcu_read_lock_any_held+0x10/0x10 ? smack_log+0x123/0x540 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x226/0x2b0 ocfs2_ioctl+0x65e/0x7d0 ? __pfx_ocfs2_ioctl+0x10/0x10 ? smack_file_ioctl+0x29e/0x3a0 ? __pfx_smack_file_ioctl+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x43d/0x780 ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10 ? __pfx_ocfs2_ioctl+0x10/0x10 __se_sys_ioctl+0xfb/0x170 do_syscall_64+0xf3/0x230 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... When 'ioctl(OCFS2_IOC_GROUP_ADD, ...)' has failed for the particular inode in 'ocfs2_verify_group_and_input()', corresponding buffer head remains cached and subsequent call to the same 'ioctl()' for the same inode issues the BUG() in 'ocfs2_set_new_buffer_uptodate()' (trying to cache the same buffer head of that inode). Fix this by uncaching the buffer head with 'ocfs2_remove_from_cache()' on error path in 'ocfs2_group_add()'.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53113", "url": "https://ubuntu.com/security/CVE-2024-53113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: fix NULL pointer dereference in alloc_pages_bulk_noprof We triggered a NULL pointer dereference for ac.preferred_zoneref->zone in alloc_pages_bulk_noprof() when the task is migrated between cpusets. When cpuset is enabled, in prepare_alloc_pages(), ac->nodemask may be ¤t->mems_allowed. when first_zones_zonelist() is called to find preferred_zoneref, the ac->nodemask may be modified concurrently if the task is migrated between different cpusets. Assuming we have 2 NUMA Node, when traversing Node1 in ac->zonelist, the nodemask is 2, and when traversing Node2 in ac->zonelist, the nodemask is 1. As a result, the ac->preferred_zoneref points to NULL zone. In alloc_pages_bulk_noprof(), for_each_zone_zonelist_nodemask() finds a allowable zone and calls zonelist_node_idx(ac.preferred_zoneref), leading to NULL pointer dereference. __alloc_pages_noprof() fixes this issue by checking NULL pointer in commit ea57485af8f4 (\"mm, page_alloc: fix check for NULL preferred_zone\") and commit df76cee6bbeb (\"mm, page_alloc: remove redundant checks from alloc fastpath\"). To fix it, check NULL pointer for preferred_zoneref->zone.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53114", "url": "https://ubuntu.com/security/CVE-2024-53114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 client A number of Zen4 client SoCs advertise the ability to use virtualized VMLOAD/VMSAVE, but using these instructions is reported to be a cause of a random host reboot. These instructions aren't intended to be advertised on Zen4 client so clear the capability.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53137", "url": "https://ubuntu.com/security/CVE-2024-53137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: fix cacheflush with PAN It seems that the cacheflush syscall got broken when PAN for LPAE was implemented. User access was not enabled around the cache maintenance instructions, causing them to fault.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53115", "url": "https://ubuntu.com/security/CVE-2024-53115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: avoid null_ptr_deref in vmw_framebuffer_surface_create_handle The 'vmw_user_object_buffer' function may return NULL with incorrect inputs. To avoid possible null pointer dereference, add a check whether the 'bo' is NULL in the vmw_framebuffer_surface_create_handle.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53116", "url": "https://ubuntu.com/security/CVE-2024-53116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix handling of partial GPU mapping of BOs This commit fixes the bug in the handling of partial mapping of the buffer objects to the GPU, which caused kernel warnings. Panthor didn't correctly handle the case where the partial mapping spanned multiple scatterlists and the mapping offset didn't point to the 1st page of starting scatterlist. The offset variable was not cleared after reaching the starting scatterlist. Following warning messages were seen. WARNING: CPU: 1 PID: 650 at drivers/iommu/io-pgtable-arm.c:659 __arm_lpae_unmap+0x254/0x5a0 pc : __arm_lpae_unmap+0x254/0x5a0 lr : __arm_lpae_unmap+0x2cc/0x5a0 Call trace: __arm_lpae_unmap+0x254/0x5a0 __arm_lpae_unmap+0x108/0x5a0 __arm_lpae_unmap+0x108/0x5a0 __arm_lpae_unmap+0x108/0x5a0 arm_lpae_unmap_pages+0x80/0xa0 panthor_vm_unmap_pages+0xac/0x1c8 [panthor] panthor_gpuva_sm_step_unmap+0x4c/0xc8 [panthor] op_unmap_cb.isra.23.constprop.30+0x54/0x80 __drm_gpuvm_sm_unmap+0x184/0x1c8 drm_gpuvm_sm_unmap+0x40/0x60 panthor_vm_exec_op+0xa8/0x120 [panthor] panthor_vm_bind_exec_sync_op+0xc4/0xe8 [panthor] panthor_ioctl_vm_bind+0x10c/0x170 [panthor] drm_ioctl_kernel+0xbc/0x138 drm_ioctl+0x210/0x4b0 __arm64_sys_ioctl+0xb0/0xf8 invoke_syscall+0x4c/0x110 el0_svc_common.constprop.1+0x98/0xf8 do_el0_svc+0x24/0x38 el0_svc+0x34/0xc8 el0t_64_sync_handler+0xa0/0xc8 el0t_64_sync+0x174/0x178 panthor : [drm] drm_WARN_ON(unmapped_sz != pgsize * pgcount) WARNING: CPU: 1 PID: 650 at drivers/gpu/drm/panthor/panthor_mmu.c:922 panthor_vm_unmap_pages+0x124/0x1c8 [panthor] pc : panthor_vm_unmap_pages+0x124/0x1c8 [panthor] lr : panthor_vm_unmap_pages+0x124/0x1c8 [panthor] panthor : [drm] *ERROR* failed to unmap range ffffa388f000-ffffa3890000 (requested range ffffa388c000-ffffa3890000)", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53117", "url": "https://ubuntu.com/security/CVE-2024-53117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio/vsock: Improve MSG_ZEROCOPY error handling Add a missing kfree_skb() to prevent memory leaks.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53118", "url": "https://ubuntu.com/security/CVE-2024-53118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Fix sk_error_queue memory leak Kernel queues MSG_ZEROCOPY completion notifications on the error queue. Where they remain, until explicitly recv()ed. To prevent memory leaks, clean up the queue when the socket is destroyed. unreferenced object 0xffff8881028beb00 (size 224): comm \"vsock_test\", pid 1218, jiffies 4294694897 hex dump (first 32 bytes): 90 b0 21 17 81 88 ff ff 90 b0 21 17 81 88 ff ff ..!.......!..... 00 00 00 00 00 00 00 00 00 b0 21 17 81 88 ff ff ..........!..... backtrace (crc 6c7031ca): [] kmem_cache_alloc_node_noprof+0x2f7/0x370 [] __alloc_skb+0x132/0x180 [] sock_omalloc+0x4b/0x80 [] msg_zerocopy_realloc+0x9e/0x240 [] virtio_transport_send_pkt_info+0x412/0x4c0 [] virtio_transport_stream_enqueue+0x43/0x50 [] vsock_connectible_sendmsg+0x373/0x450 [] ____sys_sendmsg+0x365/0x3a0 [] ___sys_sendmsg+0x84/0xd0 [] __sys_sendmsg+0x47/0x80 [] do_syscall_64+0x93/0x180 [] entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53119", "url": "https://ubuntu.com/security/CVE-2024-53119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio/vsock: Fix accept_queue memory leak As the final stages of socket destruction may be delayed, it is possible that virtio_transport_recv_listen() will be called after the accept_queue has been flushed, but before the SOCK_DONE flag has been set. As a result, sockets enqueued after the flush would remain unremoved, leading to a memory leak. vsock_release __vsock_release lock virtio_transport_release virtio_transport_close schedule_delayed_work(close_work) sk_shutdown = SHUTDOWN_MASK (!) flush accept_queue release virtio_transport_recv_pkt vsock_find_bound_socket lock if flag(SOCK_DONE) return virtio_transport_recv_listen child = vsock_create_connected (!) vsock_enqueue_accept(child) release close_work lock virtio_transport_do_close set_flag(SOCK_DONE) virtio_transport_remove_sock vsock_remove_sock vsock_remove_bound release Introduce a sk_shutdown check to disallow vsock_enqueue_accept() during socket destruction. unreferenced object 0xffff888109e3f800 (size 2040): comm \"kworker/5:2\", pid 371, jiffies 4294940105 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00 (..@............ backtrace (crc 9e5f4e84): [] kmem_cache_alloc_noprof+0x2c1/0x360 [] sk_prot_alloc+0x30/0x120 [] sk_alloc+0x2c/0x4b0 [] __vsock_create.constprop.0+0x2a/0x310 [] virtio_transport_recv_pkt+0x4dc/0x9a0 [] vsock_loopback_work+0xfd/0x140 [] process_one_work+0x20c/0x570 [] worker_thread+0x1bf/0x3a0 [] kthread+0xdd/0x110 [] ret_from_fork+0x2d/0x50 [] ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53120", "url": "https://ubuntu.com/security/CVE-2024-53120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: CT: Fix null-ptr-deref in add rule err flow In error flow of mlx5_tc_ct_entry_add_rule(), in case ct_rule_add() callback returns error, zone_rule->attr is used uninitiated. Fix it to use attr which has the needed pointer value. Kernel log: BUG: kernel NULL pointer dereference, address: 0000000000000110 RIP: 0010:mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core] … Call Trace: ? __die+0x20/0x70 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x140 ? asm_exc_page_fault+0x22/0x30 ? mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core] ? mlx5_tc_ct_entry_add_rule+0x1d5/0x2f0 [mlx5_core] mlx5_tc_ct_block_flow_offload+0xc6a/0xf90 [mlx5_core] ? nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] flow_offload_work_handler+0x142/0x320 [nf_flow_table] ? finish_task_switch.isra.0+0x15b/0x2b0 process_one_work+0x16c/0x320 worker_thread+0x28c/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xb8/0xf0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53138", "url": "https://ubuntu.com/security/CVE-2024-53138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: kTLS, Fix incorrect page refcounting The kTLS tx handling code is using a mix of get_page() and page_ref_inc() APIs to increment the page reference. But on the release path (mlx5e_ktls_tx_handle_resync_dump_comp()), only put_page() is used. This is an issue when using pages from large folios: the get_page() references are stored on the folio page while the page_ref_inc() references are stored directly in the given page. On release the folio page will be dereferenced too many times. This was found while doing kTLS testing with sendfile() + ZC when the served file was read from NFS on a kernel with NFS large folios support (commit 49b29a573da8 (\"nfs: add support for large folios\")).", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53121", "url": "https://ubuntu.com/security/CVE-2024-53121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: fs, lock FTE when checking if active The referenced commits introduced a two-step process for deleting FTEs: - Lock the FTE, delete it from hardware, set the hardware deletion function to NULL and unlock the FTE. - Lock the parent flow group, delete the software copy of the FTE, and remove it from the xarray. However, this approach encounters a race condition if a rule with the same match value is added simultaneously. In this scenario, fs_core may set the hardware deletion function to NULL prematurely, causing a panic during subsequent rule deletions. To prevent this, ensure the active flag of the FTE is checked under a lock, which will prevent the fs_core layer from attaching a new steering rule to an FTE that is in the process of deletion. [ 438.967589] MOSHE: 2496 mlx5_del_flow_rules del_hw_func [ 438.968205] ------------[ cut here ]------------ [ 438.968654] refcount_t: decrement hit 0; leaking memory. [ 438.969249] WARNING: CPU: 0 PID: 8957 at lib/refcount.c:31 refcount_warn_saturate+0xfb/0x110 [ 438.970054] Modules linked in: act_mirred cls_flower act_gact sch_ingress openvswitch nsh mlx5_vdpa vringh vhost_iotlb vdpa mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core zram zsmalloc fuse [last unloaded: cls_flower] [ 438.973288] CPU: 0 UID: 0 PID: 8957 Comm: tc Not tainted 6.12.0-rc1+ #8 [ 438.973888] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 438.974874] RIP: 0010:refcount_warn_saturate+0xfb/0x110 [ 438.975363] Code: 40 66 3b 82 c6 05 16 e9 4d 01 01 e8 1f 7c a0 ff 0f 0b c3 cc cc cc cc 48 c7 c7 10 66 3b 82 c6 05 fd e8 4d 01 01 e8 05 7c a0 ff <0f> 0b c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 90 [ 438.976947] RSP: 0018:ffff888124a53610 EFLAGS: 00010286 [ 438.977446] RAX: 0000000000000000 RBX: ffff888119d56de0 RCX: 0000000000000000 [ 438.978090] RDX: ffff88852c828700 RSI: ffff88852c81b3c0 RDI: ffff88852c81b3c0 [ 438.978721] RBP: ffff888120fa0e88 R08: 0000000000000000 R09: ffff888124a534b0 [ 438.979353] R10: 0000000000000001 R11: 0000000000000001 R12: ffff888119d56de0 [ 438.979979] R13: ffff888120fa0ec0 R14: ffff888120fa0ee8 R15: ffff888119d56de0 [ 438.980607] FS: 00007fe6dcc0f800(0000) GS:ffff88852c800000(0000) knlGS:0000000000000000 [ 438.983984] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 438.984544] CR2: 00000000004275e0 CR3: 0000000186982001 CR4: 0000000000372eb0 [ 438.985205] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 438.985842] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 438.986507] Call Trace: [ 438.986799] [ 438.987070] ? __warn+0x7d/0x110 [ 438.987426] ? refcount_warn_saturate+0xfb/0x110 [ 438.987877] ? report_bug+0x17d/0x190 [ 438.988261] ? prb_read_valid+0x17/0x20 [ 438.988659] ? handle_bug+0x53/0x90 [ 438.989054] ? exc_invalid_op+0x14/0x70 [ 438.989458] ? asm_exc_invalid_op+0x16/0x20 [ 438.989883] ? refcount_warn_saturate+0xfb/0x110 [ 438.990348] mlx5_del_flow_rules+0x2f7/0x340 [mlx5_core] [ 438.990932] __mlx5_eswitch_del_rule+0x49/0x170 [mlx5_core] [ 438.991519] ? mlx5_lag_is_sriov+0x3c/0x50 [mlx5_core] [ 438.992054] ? xas_load+0x9/0xb0 [ 438.992407] mlx5e_tc_rule_unoffload+0x45/0xe0 [mlx5_core] [ 438.993037] mlx5e_tc_del_fdb_flow+0x2a6/0x2e0 [mlx5_core] [ 438.993623] mlx5e_flow_put+0x29/0x60 [mlx5_core] [ 438.994161] mlx5e_delete_flower+0x261/0x390 [mlx5_core] [ 438.994728] tc_setup_cb_destroy+0xb9/0x190 [ 438.995150] fl_hw_destroy_filter+0x94/0xc0 [cls_flower] [ 438.995650] fl_change+0x11a4/0x13c0 [cls_flower] [ 438.996105] tc_new_tfilter+0x347/0xbc0 [ 438.996503] ? __ ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53122", "url": "https://ubuntu.com/security/CVE-2024-53122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: cope racing subflow creation in mptcp_rcv_space_adjust Additional active subflows - i.e. created by the in kernel path manager - are included into the subflow list before starting the 3whs. A racing recvmsg() spooling data received on an already established subflow would unconditionally call tcp_cleanup_rbuf() on all the current subflows, potentially hitting a divide by zero error on the newly created ones. Explicitly check that the subflow is in a suitable state before invoking tcp_cleanup_rbuf().", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53123", "url": "https://ubuntu.com/security/CVE-2024-53123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: error out earlier on disconnect Eric reported a division by zero splat in the MPTCP protocol: Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 6094 Comm: syz-executor317 Not tainted 6.12.0-rc5-syzkaller-00291-g05b92660cdfe #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:__tcp_select_window+0x5b4/0x1310 net/ipv4/tcp_output.c:3163 Code: f6 44 01 e3 89 df e8 9b 75 09 f8 44 39 f3 0f 8d 11 ff ff ff e8 0d 74 09 f8 45 89 f4 e9 04 ff ff ff e8 00 74 09 f8 44 89 f0 99 7c 24 14 41 29 d6 45 89 f4 e9 ec fe ff ff e8 e8 73 09 f8 48 89 RSP: 0018:ffffc900041f7930 EFLAGS: 00010293 RAX: 0000000000017e67 RBX: 0000000000017e67 RCX: ffffffff8983314b RDX: 0000000000000000 RSI: ffffffff898331b0 RDI: 0000000000000004 RBP: 00000000005d6000 R08: 0000000000000004 R09: 0000000000017e67 R10: 0000000000003e80 R11: 0000000000000000 R12: 0000000000003e80 R13: ffff888031d9b440 R14: 0000000000017e67 R15: 00000000002eb000 FS: 00007feb5d7f16c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007feb5d8adbb8 CR3: 0000000074e4c000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __tcp_cleanup_rbuf+0x3e7/0x4b0 net/ipv4/tcp.c:1493 mptcp_rcv_space_adjust net/mptcp/protocol.c:2085 [inline] mptcp_recvmsg+0x2156/0x2600 net/mptcp/protocol.c:2289 inet_recvmsg+0x469/0x6a0 net/ipv4/af_inet.c:885 sock_recvmsg_nosec net/socket.c:1051 [inline] sock_recvmsg+0x1b2/0x250 net/socket.c:1073 __sys_recvfrom+0x1a5/0x2e0 net/socket.c:2265 __do_sys_recvfrom net/socket.c:2283 [inline] __se_sys_recvfrom net/socket.c:2279 [inline] __x64_sys_recvfrom+0xe0/0x1c0 net/socket.c:2279 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 RIP: 0033:0x7feb5d857559 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:00007feb5d7f1208 EFLAGS: 00000246 ORIG_RAX: 000000000000002d RAX: ffffffffffffffda RBX: 00007feb5d8e1318 RCX: 00007feb5d857559 RDX: 000000800000000e RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007feb5d8e1310 R08: 0000000000000000 R09: ffffffff81000000 R10: 0000000000000100 R11: 0000000000000246 R12: 00007feb5d8e131c R13: 00007feb5d8ae074 R14: 000000800000000e R15: 00000000fffffdef and provided a nice reproducer. The root cause is the current bad handling of racing disconnect. After the blamed commit below, sk_wait_data() can return (with error) with the underlying socket disconnected and a zero rcv_mss. Catch the error and return without performing any additional operations on the current socket.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53124", "url": "https://ubuntu.com/security/CVE-2024-53124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix data-races around sk->sk_forward_alloc Syzkaller reported this warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 16 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x1c5/0x1e0 Modules linked in: CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:inet_sock_destruct+0x1c5/0x1e0 Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 <0f> 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00 RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206 RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007 RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00 RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007 R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00 R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78 FS: 0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn+0x88/0x130 ? inet_sock_destruct+0x1c5/0x1e0 ? report_bug+0x18e/0x1a0 ? handle_bug+0x53/0x90 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? inet_sock_destruct+0x1c5/0x1e0 __sk_destruct+0x2a/0x200 rcu_do_batch+0x1aa/0x530 ? rcu_do_batch+0x13b/0x530 rcu_core+0x159/0x2f0 handle_softirqs+0xd3/0x2b0 ? __pfx_smpboot_thread_fn+0x10/0x10 run_ksoftirqd+0x25/0x30 smpboot_thread_fn+0xdd/0x1d0 kthread+0xd3/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ---[ end trace 0000000000000000 ]--- Its possible that two threads call tcp_v6_do_rcv()/sk_forward_alloc_add() concurrently when sk->sk_state == TCP_LISTEN with sk->sk_lock unlocked, which triggers a data-race around sk->sk_forward_alloc: tcp_v6_rcv tcp_v6_do_rcv skb_clone_and_charge_r sk_rmem_schedule __sk_mem_schedule sk_forward_alloc_add() skb_set_owner_r sk_mem_charge sk_forward_alloc_add() __kfree_skb skb_release_all skb_release_head_state sock_rfree sk_mem_uncharge sk_forward_alloc_add() sk_mem_reclaim // set local var reclaimable __sk_mem_reclaim sk_forward_alloc_add() In this syzkaller testcase, two threads call tcp_v6_do_rcv() with skb->truesize=768, the sk_forward_alloc changes like this: (cpu 1) | (cpu 2) | sk_forward_alloc ... | ... | 0 __sk_mem_schedule() | | +4096 = 4096 | __sk_mem_schedule() | +4096 = 8192 sk_mem_charge() | | -768 = 7424 | sk_mem_charge() | -768 = 6656 ... | ... | sk_mem_uncharge() | | +768 = 7424 reclaimable=7424 | | | sk_mem_uncharge() | +768 = 8192 | reclaimable=8192 | __sk_mem_reclaim() | | -4096 = 4096 | __sk_mem_reclaim() | -8192 = -4096 != 0 The skb_clone_and_charge_r() should not be called in tcp_v6_do_rcv() when sk->sk_state is TCP_LISTEN, it happens later in tcp_v6_syn_recv_sock(). Fix the same issue in dccp_v6_do_rcv().", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53129", "url": "https://ubuntu.com/security/CVE-2024-53129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: vop: Fix a dereferenced before check warning The 'state' can't be NULL, we should check crtc_state. Fix warning: drivers/gpu/drm/rockchip/rockchip_drm_vop.c:1096 vop_plane_atomic_async_check() warn: variable dereferenced before check 'state' (see line 1077)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53139", "url": "https://ubuntu.com/security/CVE-2024-53139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix possible UAF in sctp_v6_available() A lockdep report [1] with CONFIG_PROVE_RCU_LIST=y hints that sctp_v6_available() is calling dev_get_by_index_rcu() and ipv6_chk_addr() without holding rcu. [1] ============================= WARNING: suspicious RCU usage 6.12.0-rc5-virtme #1216 Tainted: G W ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by sctp_hello/31495: #0: ffff9f1ebbdb7418 (sk_lock-AF_INET6){+.+.}-{0:0}, at: sctp_bind (./arch/x86/include/asm/jump_label.h:27 net/sctp/socket.c:315) sctp stack backtrace: CPU: 7 UID: 0 PID: 31495 Comm: sctp_hello Tainted: G W 6.12.0-rc5-virtme #1216 Tainted: [W]=WARN 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:123) lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822) dev_get_by_index_rcu (net/core/dev.c:876 (discriminator 7)) sctp_v6_available (net/sctp/ipv6.c:701) sctp sctp_do_bind (net/sctp/socket.c:400 (discriminator 1)) sctp sctp_bind (net/sctp/socket.c:320) sctp inet6_bind_sk (net/ipv6/af_inet6.c:465) ? security_socket_bind (security/security.c:4581 (discriminator 1)) __sys_bind (net/socket.c:1848 net/socket.c:1869) ? do_user_addr_fault (./include/linux/rcupdate.h:347 ./include/linux/rcupdate.h:880 ./include/linux/mm.h:729 arch/x86/mm/fault.c:1340) ? do_user_addr_fault (./arch/x86/include/asm/preempt.h:84 (discriminator 13) ./include/linux/rcupdate.h:98 (discriminator 13) ./include/linux/rcupdate.h:882 (discriminator 13) ./include/linux/mm.h:729 (discriminator 13) arch/x86/mm/fault.c:1340 (discriminator 13)) __x64_sys_bind (net/socket.c:1877 (discriminator 1) net/socket.c:1875 (discriminator 1) net/socket.c:1875 (discriminator 1)) do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f59b934a1e7 Code: 44 00 00 48 8b 15 39 8c 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 b8 31 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 09 8c 0c 00 f7 d8 64 89 01 48 All code ======== 0:\t44 00 00 \tadd %r8b,(%rax) 3:\t48 8b 15 39 8c 0c 00 \tmov 0xc8c39(%rip),%rdx # 0xc8c43 a:\tf7 d8 \tneg %eax c:\t64 89 02 \tmov %eax,%fs:(%rdx) f:\tb8 ff ff ff ff \tmov $0xffffffff,%eax 14:\teb bd \tjmp 0xffffffffffffffd3 16:\t66 2e 0f 1f 84 00 00 \tcs nopw 0x0(%rax,%rax,1) 1d:\t00 00 00 20:\t0f 1f 00 \tnopl (%rax) 23:\tb8 31 00 00 00 \tmov $0x31,%eax 28:\t0f 05 \tsyscall 2a:*\t48 3d 01 f0 ff ff \tcmp $0xfffffffffffff001,%rax\t\t<-- trapping instruction 30:\t73 01 \tjae 0x33 32:\tc3 \tret 33:\t48 8b 0d 09 8c 0c 00 \tmov 0xc8c09(%rip),%rcx # 0xc8c43 3a:\tf7 d8 \tneg %eax 3c:\t64 89 01 \tmov %eax,%fs:(%rcx) 3f:\t48 \trex.W Code starting with the faulting instruction =========================================== 0:\t48 3d 01 f0 ff ff \tcmp $0xfffffffffffff001,%rax 6:\t73 01 \tjae 0x9 8:\tc3 \tret 9:\t48 8b 0d 09 8c 0c 00 \tmov 0xc8c09(%rip),%rcx # 0xc8c19 10:\tf7 d8 \tneg %eax 12:\t64 89 01 \tmov %eax,%fs:(%rcx) 15:\t48 \trex.W RSP: 002b:00007ffe2d0ad398 EFLAGS: 00000202 ORIG_RAX: 0000000000000031 RAX: ffffffffffffffda RBX: 00007ffe2d0ad3d0 RCX: 00007f59b934a1e7 RDX: 000000000000001c RSI: 00007ffe2d0ad3d0 RDI: 0000000000000005 RBP: 0000000000000005 R08: 1999999999999999 R09: 0000000000000000 R10: 00007f59b9253298 R11: 000000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53140", "url": "https://ubuntu.com/security/CVE-2024-53140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netlink: terminate outstanding dump on socket close Netlink supports iterative dumping of data. It provides the families the following ops: - start - (optional) kicks off the dumping process - dump - actual dump helper, keeps getting called until it returns 0 - done - (optional) pairs with .start, can be used for cleanup The whole process is asynchronous and the repeated calls to .dump don't actually happen in a tight loop, but rather are triggered in response to recvmsg() on the socket. This gives the user full control over the dump, but also means that the user can close the socket without getting to the end of the dump. To make sure .start is always paired with .done we check if there is an ongoing dump before freeing the socket, and if so call .done. The complication is that sockets can get freed from BH and .done is allowed to sleep. So we use a workqueue to defer the call, when needed. Unfortunately this does not work correctly. What we defer is not the cleanup but rather releasing a reference on the socket. We have no guarantee that we own the last reference, if someone else holds the socket they may release it in BH and we're back to square one. The whole dance, however, appears to be unnecessary. Only the user can interact with dumps, so we can clean up when socket is closed. And close always happens in process context. Some async code may still access the socket after close, queue notification skbs to it etc. but no dumps can start, end or otherwise make progress. Delete the workqueue and flush the dump state directly from the release handler. Note that further cleanup is possible in -next, for instance we now always call .done before releasing the main module reference, so dump doesn't have to take a reference of its own.", "cve_priority": "high", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53098", "url": "https://ubuntu.com/security/CVE-2024-53098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/ufence: Prefetch ufence addr to catch bogus address access_ok() only checks for addr overflow so also try to read the addr to catch invalid addr sent from userspace. (cherry picked from commit 9408c4508483ffc60811e910a93d6425b8e63928)", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53099", "url": "https://ubuntu.com/security/CVE-2024-53099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check validity of link->type in bpf_link_show_fdinfo() If a newly-added link type doesn't invoke BPF_LINK_TYPE(), accessing bpf_link_type_strs[link->type] may result in an out-of-bounds access. To spot such missed invocations early in the future, checking the validity of link->type in bpf_link_show_fdinfo() and emitting a warning when such invocations are missed.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53089", "url": "https://ubuntu.com/security/CVE-2024-53089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: KVM: Mark hrtimer to expire in hard interrupt context Like commit 2c0d278f3293f (\"KVM: LAPIC: Mark hrtimer to expire in hard interrupt context\") and commit 9090825fa9974 (\"KVM: arm/arm64: Let the timer expire in hardirq context on RT\"), On PREEMPT_RT enabled kernels unmarked hrtimers are moved into soft interrupt expiry mode by default. Then the timers are canceled from an preempt-notifier which is invoked with disabled preemption which is not allowed on PREEMPT_RT. The timer callback is short so in could be invoked in hard-IRQ context. So let the timer expire on hard-IRQ context even on -RT. This fix a \"scheduling while atomic\" bug for PREEMPT_RT enabled kernels: BUG: scheduling while atomic: qemu-system-loo/1011/0x00000002 Modules linked in: amdgpu rfkill nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat ns CPU: 1 UID: 0 PID: 1011 Comm: qemu-system-loo Tainted: G W 6.12.0-rc2+ #1774 Tainted: [W]=WARN Hardware name: Loongson Loongson-3A5000-7A1000-1w-CRB/Loongson-LS3A5000-7A1000-1w-CRB, BIOS vUDK2018-LoongArch-V2.0.0-prebeta9 10/21/2022 Stack : ffffffffffffffff 0000000000000000 9000000004e3ea38 9000000116744000 90000001167475a0 0000000000000000 90000001167475a8 9000000005644830 90000000058dc000 90000000058dbff8 9000000116747420 0000000000000001 0000000000000001 6a613fc938313980 000000000790c000 90000001001c1140 00000000000003fe 0000000000000001 000000000000000d 0000000000000003 0000000000000030 00000000000003f3 000000000790c000 9000000116747830 90000000057ef000 0000000000000000 9000000005644830 0000000000000004 0000000000000000 90000000057f4b58 0000000000000001 9000000116747868 900000000451b600 9000000005644830 9000000003a13998 0000000010000020 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d ... Call Trace: [<9000000003a13998>] show_stack+0x38/0x180 [<9000000004e3ea34>] dump_stack_lvl+0x84/0xc0 [<9000000003a71708>] __schedule_bug+0x48/0x60 [<9000000004e45734>] __schedule+0x1114/0x1660 [<9000000004e46040>] schedule_rtlock+0x20/0x60 [<9000000004e4e330>] rtlock_slowlock_locked+0x3f0/0x10a0 [<9000000004e4f038>] rt_spin_lock+0x58/0x80 [<9000000003b02d68>] hrtimer_cancel_wait_running+0x68/0xc0 [<9000000003b02e30>] hrtimer_cancel+0x70/0x80 [] kvm_restore_timer+0x50/0x1a0 [kvm] [] kvm_arch_vcpu_load+0x68/0x2a0 [kvm] [] kvm_sched_in+0x34/0x60 [kvm] [<9000000003a749a0>] finish_task_switch.isra.0+0x140/0x2e0 [<9000000004e44a70>] __schedule+0x450/0x1660 [<9000000004e45cb0>] schedule+0x30/0x180 [] kvm_vcpu_block+0x70/0x120 [kvm] [] kvm_vcpu_halt+0x60/0x3e0 [kvm] [] kvm_handle_gspr+0x3f4/0x4e0 [kvm] [] kvm_handle_exit+0x1c8/0x260 [kvm]", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53090", "url": "https://ubuntu.com/security/CVE-2024-53090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix lock recursion afs_wake_up_async_call() can incur lock recursion. The problem is that it is called from AF_RXRPC whilst holding the ->notify_lock, but it tries to take a ref on the afs_call struct in order to pass it to a work queue - but if the afs_call is already queued, we then have an extraneous ref that must be put... calling afs_put_call() may call back down into AF_RXRPC through rxrpc_kernel_shutdown_call(), however, which might try taking the ->notify_lock again. This case isn't very common, however, so defer it to a workqueue. The oops looks something like: BUG: spinlock recursion on CPU#0, krxrpcio/7001/1646 lock: 0xffff888141399b30, .magic: dead4ead, .owner: krxrpcio/7001/1646, .owner_cpu: 0 CPU: 0 UID: 0 PID: 1646 Comm: krxrpcio/7001 Not tainted 6.12.0-rc2-build3+ #4351 Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014 Call Trace: dump_stack_lvl+0x47/0x70 do_raw_spin_lock+0x3c/0x90 rxrpc_kernel_shutdown_call+0x83/0xb0 afs_put_call+0xd7/0x180 rxrpc_notify_socket+0xa0/0x190 rxrpc_input_split_jumbo+0x198/0x1d0 rxrpc_input_data+0x14b/0x1e0 ? rxrpc_input_call_packet+0xc2/0x1f0 rxrpc_input_call_event+0xad/0x6b0 rxrpc_input_packet_on_conn+0x1e1/0x210 rxrpc_input_packet+0x3f2/0x4d0 rxrpc_io_thread+0x243/0x410 ? __pfx_rxrpc_io_thread+0x10/0x10 kthread+0xcf/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x24/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53101", "url": "https://ubuntu.com/security/CVE-2024-53101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized value issue in from_kuid and from_kgid ocfs2_setattr() uses attr->ia_mode, attr->ia_uid and attr->ia_gid in a trace point even though ATTR_MODE, ATTR_UID and ATTR_GID aren't set. Initialize all fields of newattrs to avoid uninitialized variables, by checking if ATTR_MODE, ATTR_UID, ATTR_GID are initialized, otherwise 0.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53091", "url": "https://ubuntu.com/security/CVE-2024-53091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Add sk_is_inet and IS_ICSK check in tls_sw_has_ctx_tx/rx As the introduction of the support for vsock and unix sockets in sockmap, tls_sw_has_ctx_tx/rx cannot presume the socket passed in must be IS_ICSK. vsock and af_unix sockets have vsock_sock and unix_sock instead of inet_connection_sock. For these sockets, tls_get_ctx may return an invalid pointer and cause page fault in function tls_sw_ctx_rx. BUG: unable to handle page fault for address: 0000000000040030 Workqueue: vsock-loopback vsock_loopback_work RIP: 0010:sk_psock_strp_data_ready+0x23/0x60 Call Trace: ? __die+0x81/0xc3 ? no_context+0x194/0x350 ? do_page_fault+0x30/0x110 ? async_page_fault+0x3e/0x50 ? sk_psock_strp_data_ready+0x23/0x60 virtio_transport_recv_pkt+0x750/0x800 ? update_load_avg+0x7e/0x620 vsock_loopback_work+0xd0/0x100 process_one_work+0x1a7/0x360 worker_thread+0x30/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x112/0x130 ? __kthread_cancel_work+0x40/0x40 ret_from_fork+0x1f/0x40 v2: - Add IS_ICSK check v3: - Update the commits in Fixes", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53092", "url": "https://ubuntu.com/security/CVE-2024-53092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_pci: Fix admin vq cleanup by using correct info pointer vp_modern_avq_cleanup() and vp_del_vqs() clean up admin vq resources by virtio_pci_vq_info pointer. The info pointer of admin vq is stored in vp_dev->admin_vq.info instead of vp_dev->vqs[]. Using the info pointer from vp_dev->vqs[] for admin vq causes a kernel NULL pointer dereference bug. In vp_modern_avq_cleanup() and vp_del_vqs(), get the info pointer from vp_dev->admin_vq.info for admin vq to clean up the resources. Also make info ptr as argument of vp_del_vq() to be symmetric with vp_setup_vq(). vp_reset calls vp_modern_avq_cleanup, and causes the Call Trace: ================================================================== BUG: kernel NULL pointer dereference, address:0000000000000000 ... CPU: 49 UID: 0 PID: 4439 Comm: modprobe Not tainted 6.11.0-rc5 #1 RIP: 0010:vp_reset+0x57/0x90 [virtio_pci] Call Trace: ... ? vp_reset+0x57/0x90 [virtio_pci] ? vp_reset+0x38/0x90 [virtio_pci] virtio_reset_device+0x1d/0x30 remove_vq_common+0x1c/0x1a0 [virtio_net] virtnet_remove+0xa1/0xc0 [virtio_net] virtio_dev_remove+0x46/0xa0 ... virtio_pci_driver_exit+0x14/0x810 [virtio_pci] ==================================================================", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53102", "url": "https://ubuntu.com/security/CVE-2024-53102", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53093", "url": "https://ubuntu.com/security/CVE-2024-53093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: defer partition scanning We need to suppress the partition scan from occuring within the controller's scan_work context. If a path error occurs here, the IO will wait until a path becomes available or all paths are torn down, but that action also occurs within scan_work, so it would deadlock. Defer the partion scan to a different context that does not block scan_work.", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53094", "url": "https://ubuntu.com/security/CVE-2024-53094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Add sendpage_ok() check to disable MSG_SPLICE_PAGES While running ISER over SIW, the initiator machine encounters a warning from skb_splice_from_iter() indicating that a slab page is being used in send_page. To address this, it is better to add a sendpage_ok() check within the driver itself, and if it returns 0, then MSG_SPLICE_PAGES flag should be disabled before entering the network stack. A similar issue has been discussed for NVMe in this thread: https://lore.kernel.org/all/20240530142417.146696-1-ofir.gal@volumez.com/ WARNING: CPU: 0 PID: 5342 at net/core/skbuff.c:7140 skb_splice_from_iter+0x173/0x320 Call Trace: tcp_sendmsg_locked+0x368/0xe40 siw_tx_hdt+0x695/0xa40 [siw] siw_qp_sq_process+0x102/0xb00 [siw] siw_sq_resume+0x39/0x110 [siw] siw_run_sq+0x74/0x160 [siw] kthread+0xd2/0x100 ret_from_fork+0x34/0x40 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53100", "url": "https://ubuntu.com/security/CVE-2024-53100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: tcp: avoid race between queue_lock lock and destroy Commit 76d54bf20cdc (\"nvme-tcp: don't access released socket during error recovery\") added a mutex_lock() call for the queue->queue_lock in nvme_tcp_get_address(). However, the mutex_lock() races with mutex_destroy() in nvme_tcp_free_queue(), and causes the WARN below. DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: CPU: 3 PID: 34077 at kernel/locking/mutex.c:587 __mutex_lock+0xcf0/0x1220 Modules linked in: nvmet_tcp nvmet nvme_tcp nvme_fabrics iw_cm ib_cm ib_core pktcdvd nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables qrtr sunrpc ppdev 9pnet_virtio 9pnet pcspkr netfs parport_pc parport e1000 i2c_piix4 i2c_smbus loop fuse nfnetlink zram bochs drm_vram_helper drm_ttm_helper ttm drm_kms_helper xfs drm sym53c8xx floppy nvme scsi_transport_spi nvme_core nvme_auth serio_raw ata_generic pata_acpi dm_multipath qemu_fw_cfg [last unloaded: ib_uverbs] CPU: 3 UID: 0 PID: 34077 Comm: udisksd Not tainted 6.11.0-rc7 #319 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:__mutex_lock+0xcf0/0x1220 Code: 08 84 d2 0f 85 c8 04 00 00 8b 15 ef b6 c8 01 85 d2 0f 85 78 f4 ff ff 48 c7 c6 20 93 ee af 48 c7 c7 60 91 ee af e8 f0 a7 6d fd <0f> 0b e9 5e f4 ff ff 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 RSP: 0018:ffff88811305f760 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff88812c652058 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000001 RBP: ffff88811305f8b0 R08: 0000000000000001 R09: ffffed1075c36341 R10: ffff8883ae1b1a0b R11: 0000000000010498 R12: 0000000000000000 R13: 0000000000000000 R14: dffffc0000000000 R15: ffff88812c652058 FS: 00007f9713ae4980(0000) GS:ffff8883ae180000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcd78483c7c CR3: 0000000122c38000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn.cold+0x5b/0x1af ? __mutex_lock+0xcf0/0x1220 ? report_bug+0x1ec/0x390 ? handle_bug+0x3c/0x80 ? exc_invalid_op+0x13/0x40 ? asm_exc_invalid_op+0x16/0x20 ? __mutex_lock+0xcf0/0x1220 ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] ? __pfx___mutex_lock+0x10/0x10 ? __lock_acquire+0xd6a/0x59e0 ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] ? __pfx_nvme_tcp_get_address+0x10/0x10 [nvme_tcp] nvme_sysfs_show_address+0x81/0xc0 [nvme_core] dev_attr_show+0x42/0x80 ? __asan_memset+0x1f/0x40 sysfs_kf_seq_show+0x1f0/0x370 seq_read_iter+0x2cb/0x1130 ? rw_verify_area+0x3b1/0x590 ? __mutex_lock+0x433/0x1220 vfs_read+0x6a6/0xa20 ? lockdep_hardirqs_on+0x78/0x100 ? __pfx_vfs_read+0x10/0x10 ksys_read+0xf7/0x1d0 ? __pfx_ksys_read+0x10/0x10 ? __x64_sys_openat+0x105/0x1d0 do_syscall_64+0x93/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? __pfx_ksys_read+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? do_syscall_64+0x9f/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f9713f55cfa Code: 55 48 89 e5 48 83 ec 20 48 89 55 e8 48 89 75 f0 89 7d f8 e8 e8 74 f8 ff 48 8b 55 e8 48 8b 75 f0 4 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53095", "url": "https://ubuntu.com/security/CVE-2024-53095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix use-after-free of network namespace. Recently, we got a customer report that CIFS triggers oops while reconnecting to a server. [0] The workload runs on Kubernetes, and some pods mount CIFS servers in non-root network namespaces. The problem rarely happened, but it was always while the pod was dying. The root cause is wrong reference counting for network namespace. CIFS uses kernel sockets, which do not hold refcnt of the netns that the socket belongs to. That means CIFS must ensure the socket is always freed before its netns; otherwise, use-after-free happens. The repro steps are roughly: 1. mount CIFS in a non-root netns 2. drop packets from the netns 3. destroy the netns 4. unmount CIFS We can reproduce the issue quickly with the script [1] below and see the splat [2] if CONFIG_NET_NS_REFCNT_TRACKER is enabled. When the socket is TCP, it is hard to guarantee the netns lifetime without holding refcnt due to async timers. Let's hold netns refcnt for each socket as done for SMC in commit 9744d2bf1976 (\"smc: Fix use-after-free in tcp_write_timer_handler().\"). Note that we need to move put_net() from cifs_put_tcp_session() to clean_demultiplex_info(); otherwise, __sock_create() still could touch a freed netns while cifsd tries to reconnect from cifs_demultiplex_thread(). Also, maybe_get_net() cannot be put just before __sock_create() because the code is not under RCU and there is a small chance that the same address happened to be reallocated to another netns. [0]: CIFS: VFS: \\\\XXXXXXXXXXX has not responded in 15 seconds. Reconnecting... CIFS: Serverclose failed 4 times, giving up Unable to handle kernel paging request at virtual address 14de99e461f84a07 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 CM = 0, WnR = 0 [14de99e461f84a07] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: cls_bpf sch_ingress nls_utf8 cifs cifs_arc4 cifs_md4 dns_resolver tcp_diag inet_diag veth xt_state xt_connmark nf_conntrack_netlink xt_nat xt_statistic xt_MASQUERADE xt_mark xt_addrtype ipt_REJECT nf_reject_ipv4 nft_chain_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment nft_compat nf_tables nfnetlink overlay nls_ascii nls_cp437 sunrpc vfat fat aes_ce_blk aes_ce_cipher ghash_ce sm4_ce_cipher sm4 sm3_ce sm3 sha3_ce sha512_ce sha512_arm64 sha1_ce ena button sch_fq_codel loop fuse configfs dmi_sysfs sha2_ce sha256_arm64 dm_mirror dm_region_hash dm_log dm_mod dax efivarfs CPU: 5 PID: 2690970 Comm: cifsd Not tainted 6.1.103-109.184.amzn2023.aarch64 #1 Hardware name: Amazon EC2 r7g.4xlarge/, BIOS 1.0 11/1/2018 pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : fib_rules_lookup+0x44/0x238 lr : __fib_lookup+0x64/0xbc sp : ffff8000265db790 x29: ffff8000265db790 x28: 0000000000000000 x27: 000000000000bd01 x26: 0000000000000000 x25: ffff000b4baf8000 x24: ffff00047b5e4580 x23: ffff8000265db7e0 x22: 0000000000000000 x21: ffff00047b5e4500 x20: ffff0010e3f694f8 x19: 14de99e461f849f7 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 3f92800abd010002 x11: 0000000000000001 x10: ffff0010e3f69420 x9 : ffff800008a6f294 x8 : 0000000000000000 x7 : 0000000000000006 x6 : 0000000000000000 x5 : 0000000000000001 x4 : ffff001924354280 x3 : ffff8000265db7e0 x2 : 0000000000000000 x1 : ffff0010e3f694f8 x0 : ffff00047b5e4500 Call trace: fib_rules_lookup+0x44/0x238 __fib_lookup+0x64/0xbc ip_route_output_key_hash_rcu+0x2c4/0x398 ip_route_output_key_hash+0x60/0x8c tcp_v4_connect+0x290/0x488 __inet_stream_connect+0x108/0x3d0 inet_stream_connect+0x50/0x78 kernel_connect+0x6c/0xac generic_ip_conne ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-50265", "url": "https://ubuntu.com/security/CVE-2024-50265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove() Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove(): [ 57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12 [ 57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry [ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004 [...] [ 57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [...] [ 57.331328] Call Trace: [ 57.331477] [...] [ 57.333511] ? do_user_addr_fault+0x3e5/0x740 [ 57.333778] ? exc_page_fault+0x70/0x170 [ 57.334016] ? asm_exc_page_fault+0x2b/0x30 [ 57.334263] ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10 [ 57.334596] ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [ 57.334913] ocfs2_xa_remove_entry+0x23/0xc0 [ 57.335164] ocfs2_xa_set+0x704/0xcf0 [ 57.335381] ? _raw_spin_unlock+0x1a/0x40 [ 57.335620] ? ocfs2_inode_cache_unlock+0x16/0x20 [ 57.335915] ? trace_preempt_on+0x1e/0x70 [ 57.336153] ? start_this_handle+0x16c/0x500 [ 57.336410] ? preempt_count_sub+0x50/0x80 [ 57.336656] ? _raw_read_unlock+0x20/0x40 [ 57.336906] ? start_this_handle+0x16c/0x500 [ 57.337162] ocfs2_xattr_block_set+0xa6/0x1e0 [ 57.337424] __ocfs2_xattr_set_handle+0x1fd/0x5d0 [ 57.337706] ? ocfs2_start_trans+0x13d/0x290 [ 57.337971] ocfs2_xattr_set+0xb13/0xfb0 [ 57.338207] ? dput+0x46/0x1c0 [ 57.338393] ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338665] ? ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338948] __vfs_removexattr+0x92/0xc0 [ 57.339182] __vfs_removexattr_locked+0xd5/0x190 [ 57.339456] ? preempt_count_sub+0x50/0x80 [ 57.339705] vfs_removexattr+0x5f/0x100 [...] Reproducer uses faultinject facility to fail ocfs2_xa_remove() -> ocfs2_xa_value_truncate() with -ENOMEM. In this case the comment mentions that we can return 0 if ocfs2_xa_cleanup_value_truncate() is going to wipe the entry anyway. But the following 'rc' check is wrong and execution flow do 'ocfs2_xa_remove_entry(loc);' twice: * 1st: in ocfs2_xa_cleanup_value_truncate(); * 2nd: returning back to ocfs2_xa_remove() instead of going to 'out'. Fix this by skipping the 2nd removal of the same entry and making syzkaller repro happy.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50266", "url": "https://ubuntu.com/security/CVE-2024-50266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: qcom: videocc-sm8350: use HW_CTRL_TRIGGER for vcodec GDSCs A recent change in the venus driver results in a stuck clock on the Lenovo ThinkPad X13s, for example, when streaming video in firefox: \tvideo_cc_mvs0_clk status stuck at 'off' \tWARNING: CPU: 6 PID: 2885 at drivers/clk/qcom/clk-branch.c:87 clk_branch_wait+0x144/0x15c \t... \tCall trace: \t clk_branch_wait+0x144/0x15c \t clk_branch2_enable+0x30/0x40 \t clk_core_enable+0xd8/0x29c \t clk_enable+0x2c/0x4c \t vcodec_clks_enable.isra.0+0x94/0xd8 [venus_core] \t coreid_power_v4+0x464/0x628 [venus_core] \t vdec_start_streaming+0xc4/0x510 [venus_dec] \t vb2_start_streaming+0x6c/0x180 [videobuf2_common] \t vb2_core_streamon+0x120/0x1dc [videobuf2_common] \t vb2_streamon+0x1c/0x6c [videobuf2_v4l2] \t v4l2_m2m_ioctl_streamon+0x30/0x80 [v4l2_mem2mem] \t v4l_streamon+0x24/0x30 [videodev] using the out-of-tree sm8350/sc8280xp venus support. [1] Update also the sm8350/sc8280xp GDSC definitions so that the hw control mode can be changed at runtime as the venus driver now requires.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50267", "url": "https://ubuntu.com/security/CVE-2024-50267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: fix use after free in debug printk The \"dev_dbg(&urb->dev->dev, ...\" which happens after usb_free_urb(urb) is a use after free of the \"urb\" pointer. Store the \"dev\" pointer at the start of the function to avoid this issue.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50268", "url": "https://ubuntu.com/security/CVE-2024-50268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: fix potential out of bounds in ucsi_ccg_update_set_new_cam_cmd() The \"*cmd\" variable can be controlled by the user via debugfs. That means \"new_cam\" can be as high as 255 while the size of the uc->updated[] array is UCSI_MAX_ALTMODES (30). The call tree is: ucsi_cmd() // val comes from simple_attr_write_xsigned() -> ucsi_send_command() -> ucsi_send_command_common() -> ucsi_run_command() // calls ucsi->ops->sync_control() -> ucsi_ccg_sync_control()", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53083", "url": "https://ubuntu.com/security/CVE-2024-53083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: qcom-pmic: init value of hdr_len/txbuf_len earlier If the read of USB_PDPHY_RX_ACKNOWLEDGE_REG failed, then hdr_len and txbuf_len are uninitialized. This commit stops to print uninitialized value and misleading/false data.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50269", "url": "https://ubuntu.com/security/CVE-2024-50269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: musb: sunxi: Fix accessing an released usb phy Commit 6ed05c68cbca (\"usb: musb: sunxi: Explicitly release USB PHY on exit\") will cause that usb phy @glue->xceiv is accessed after released. 1) register platform driver @sunxi_musb_driver // get the usb phy @glue->xceiv sunxi_musb_probe() -> devm_usb_get_phy(). 2) register and unregister platform driver @musb_driver musb_probe() -> sunxi_musb_init() use the phy here //the phy is released here musb_remove() -> sunxi_musb_exit() -> devm_usb_put_phy() 3) register @musb_driver again musb_probe() -> sunxi_musb_init() use the phy here but the phy has been released at 2). ... Fixed by reverting the commit, namely, removing devm_usb_put_phy() from sunxi_musb_exit().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53079", "url": "https://ubuntu.com/security/CVE-2024-53079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/thp: fix deferred split unqueue naming and locking Recent changes are putting more pressure on THP deferred split queues: under load revealing long-standing races, causing list_del corruptions, \"Bad page state\"s and worse (I keep BUGs in both of those, so usually don't get to see how badly they end up without). The relevant recent changes being 6.8's mTHP, 6.10's mTHP swapout, and 6.12's mTHP swapin, improved swap allocation, and underused THP splitting. Before fixing locking: rename misleading folio_undo_large_rmappable(), which does not undo large_rmappable, to folio_unqueue_deferred_split(), which is what it does. But that and its out-of-line __callee are mm internals of very limited usability: add comment and WARN_ON_ONCEs to check usage; and return a bool to say if a deferred split was unqueued, which can then be used in WARN_ON_ONCEs around safety checks (sparing callers the arcane conditionals in __folio_unqueue_deferred_split()). Just omit the folio_unqueue_deferred_split() from free_unref_folios(), all of whose callers now call it beforehand (and if any forget then bad_page() will tell) - except for its caller put_pages_list(), which itself no longer has any callers (and will be deleted separately). Swapout: mem_cgroup_swapout() has been resetting folio->memcg_data 0 without checking and unqueueing a THP folio from deferred split list; which is unfortunate, since the split_queue_lock depends on the memcg (when memcg is enabled); so swapout has been unqueueing such THPs later, when freeing the folio, using the pgdat's lock instead: potentially corrupting the memcg's list. __remove_mapping() has frozen refcount to 0 here, so no problem with calling folio_unqueue_deferred_split() before resetting memcg_data. That goes back to 5.4 commit 87eaceb3faa5 (\"mm: thp: make deferred split shrinker memcg aware\"): which included a check on swapcache before adding to deferred queue, but no check on deferred queue before adding THP to swapcache. That worked fine with the usual sequence of events in reclaim (though there were a couple of rare ways in which a THP on deferred queue could have been swapped out), but 6.12 commit dafff3f4c850 (\"mm: split underused THPs\") avoids splitting underused THPs in reclaim, which makes swapcache THPs on deferred queue commonplace. Keep the check on swapcache before adding to deferred queue? Yes: it is no longer essential, but preserves the existing behaviour, and is likely to be a worthwhile optimization (vmstat showed much more traffic on the queue under swapping load if the check was removed); update its comment. Memcg-v1 move (deprecated): mem_cgroup_move_account() has been changing folio->memcg_data without checking and unqueueing a THP folio from the deferred list, sometimes corrupting \"from\" memcg's list, like swapout. Refcount is non-zero here, so folio_unqueue_deferred_split() can only be used in a WARN_ON_ONCE to validate the fix, which must be done earlier: mem_cgroup_move_charge_pte_range() first try to split the THP (splitting of course unqueues), or skip it if that fails. Not ideal, but moving charge has been requested, and khugepaged should repair the THP later: nobody wants new custom unqueueing code just for this deprecated case. The 87eaceb3faa5 commit did have the code to move from one deferred list to another (but was not conscious of its unsafety while refcount non-0); but that was removed by 5.6 commit fac0516b5534 (\"mm: thp: don't need care deferred split queue in memcg charge move path\"), which argued that the existence of a PMD mapping guarantees that the THP cannot be on a deferred list. As above, false in rare cases, and now commonly false. Backport to 6.11 should be straightforward. Earlier backports must take care that other _deferred_list fixes and dependencies are included. There is not a strong case for backports, but they can fix cornercases.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50270", "url": "https://ubuntu.com/security/CVE-2024-50270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: avoid overflow in damon_feed_loop_next_input() damon_feed_loop_next_input() is inefficient and fragile to overflows. Specifically, 'score_goal_diff_bp' calculation can overflow when 'score' is high. The calculation is actually unnecessary at all because 'goal' is a constant of value 10,000. Calculation of 'compensation' is again fragile to overflow. Final calculation of return value for under-achiving case is again fragile to overflow when the current score is under-achieving the target. Add two corner cases handling at the beginning of the function to make the body easier to read, and rewrite the body of the function to avoid overflows and the unnecessary bp value calcuation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50271", "url": "https://ubuntu.com/security/CVE-2024-50271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: signal: restore the override_rlimit logic Prior to commit d64696905554 (\"Reimplement RLIMIT_SIGPENDING on top of ucounts\") UCOUNT_RLIMIT_SIGPENDING rlimit was not enforced for a class of signals. However now it's enforced unconditionally, even if override_rlimit is set. This behavior change caused production issues. For example, if the limit is reached and a process receives a SIGSEGV signal, sigqueue_alloc fails to allocate the necessary resources for the signal delivery, preventing the signal from being delivered with siginfo. This prevents the process from correctly identifying the fault address and handling the error. From the user-space perspective, applications are unaware that the limit has been reached and that the siginfo is effectively 'corrupted'. This can lead to unpredictable behavior and crashes, as we observed with java applications. Fix this by passing override_rlimit into inc_rlimit_get_ucounts() and skip the comparison to max there if override_rlimit is set. This effectively restores the old behavior.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50272", "url": "https://ubuntu.com/security/CVE-2024-50272", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: filemap: Fix bounds checking in filemap_read() If the caller supplies an iocb->ki_pos value that is close to the filesystem upper limit, and an iterator with a count that causes us to overflow that limit, then filemap_read() enters an infinite loop. This behaviour was discovered when testing xfstests generic/525 with the \"localio\" optimisation for loopback NFS mounts.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53104", "url": "https://ubuntu.com/security/CVE-2024-53104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_parse_format This can lead to out of bounds writes since frames of this type were not taken into account when calculating the size of the frames buffer in uvc_parse_streaming.", "cve_priority": "high", "cve_public_date": "2024-12-02 08:15:00 UTC" }, { "cve": "CVE-2024-50273", "url": "https://ubuntu.com/security/CVE-2024-50273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reinitialize delayed ref list after deleting it from the list At insert_delayed_ref() if we need to update the action of an existing ref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head's ref_add_list using list_del(), which leaves the ref's add_list member not reinitialized, as list_del() sets the next and prev members of the list to LIST_POISON1 and LIST_POISON2, respectively. If later we end up calling drop_delayed_ref() against the ref, which can happen during merging or when destroying delayed refs due to a transaction abort, we can trigger a crash since at drop_delayed_ref() we call list_empty() against the ref's add_list, which returns false since the list was not reinitialized after the list_del() and as a consequence we call list_del() again at drop_delayed_ref(). This results in an invalid list access since the next and prev members are set to poison pointers, resulting in a splat if CONFIG_LIST_HARDENED and CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences otherwise. So fix this by deleting from the list with list_del_init() instead.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53064", "url": "https://ubuntu.com/security/CVE-2024-53064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix idpf_vc_core_init error path In an event where the platform running the device control plane is rebooted, reset is detected on the driver. It releases all the resources and waits for the reset to complete. Once the reset is done, it tries to build the resources back. At this time if the device control plane is not yet started, then the driver timeouts on the virtchnl message and retries to establish the mailbox again. In the retry flow, mailbox is deinitialized but the mailbox workqueue is still alive and polling for the mailbox message. This results in accessing the released control queue leading to null-ptr-deref. Fix it by unrolling the work queue cancellation and mailbox deinitialization in the reverse order which they got initialized.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50274", "url": "https://ubuntu.com/security/CVE-2024-50274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: avoid vport access in idpf_get_link_ksettings When the device control plane is removed or the platform running device control plane is rebooted, a reset is detected on the driver. On driver reset, it releases the resources and waits for the reset to complete. If the reset fails, it takes the error path and releases the vport lock. At this time if the monitoring tools tries to access link settings, it call traces for accessing released vport pointer. To avoid it, move link_speed_mbps to netdev_priv structure which removes the dependency on vport pointer and the vport lock in idpf_get_link_ksettings. Also use netif_carrier_ok() to check the link status and adjust the offsetof to use link_up instead of link_speed_mbps.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53065", "url": "https://ubuntu.com/security/CVE-2024-53065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/slab: fix warning caused by duplicate kmem_cache creation in kmem_buckets_create Commit b035f5a6d852 (\"mm: slab: reduce the kmalloc() minimum alignment if DMA bouncing possible\") reduced ARCH_KMALLOC_MINALIGN to 8 on arm64. However, with KASAN_HW_TAGS enabled, arch_slab_minalign() becomes 16. This causes kmalloc_caches[*][8] to be aliased to kmalloc_caches[*][16], resulting in kmem_buckets_create() attempting to create a kmem_cache for size 16 twice. This duplication triggers warnings on boot: [ 2.325108] ------------[ cut here ]------------ [ 2.325135] kmem_cache of name 'memdup_user-16' already exists [ 2.325783] WARNING: CPU: 0 PID: 1 at mm/slab_common.c:107 __kmem_cache_create_args+0xb8/0x3b0 [ 2.327957] Modules linked in: [ 2.328550] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5mm-unstable-arm64+ #12 [ 2.328683] Hardware name: QEMU QEMU Virtual Machine, BIOS 2024.02-2 03/11/2024 [ 2.328790] pstate: 61000009 (nZCv daif -PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 2.328911] pc : __kmem_cache_create_args+0xb8/0x3b0 [ 2.328930] lr : __kmem_cache_create_args+0xb8/0x3b0 [ 2.328942] sp : ffff800083d6fc50 [ 2.328961] x29: ffff800083d6fc50 x28: f2ff0000c1674410 x27: ffff8000820b0598 [ 2.329061] x26: 000000007fffffff x25: 0000000000000010 x24: 0000000000002000 [ 2.329101] x23: ffff800083d6fce8 x22: ffff8000832222e8 x21: ffff800083222388 [ 2.329118] x20: f2ff0000c1674410 x19: f5ff0000c16364c0 x18: ffff800083d80030 [ 2.329135] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 2.329152] x14: 0000000000000000 x13: 0a73747369786520 x12: 79646165726c6120 [ 2.329169] x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : 0000000000000000 [ 2.329194] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 [ 2.329210] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 2.329226] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 2.329291] Call trace: [ 2.329407] __kmem_cache_create_args+0xb8/0x3b0 [ 2.329499] kmem_buckets_create+0xfc/0x320 [ 2.329526] init_user_buckets+0x34/0x78 [ 2.329540] do_one_initcall+0x64/0x3c8 [ 2.329550] kernel_init_freeable+0x26c/0x578 [ 2.329562] kernel_init+0x3c/0x258 [ 2.329574] ret_from_fork+0x10/0x20 [ 2.329698] ---[ end trace 0000000000000000 ]--- [ 2.403704] ------------[ cut here ]------------ [ 2.404716] kmem_cache of name 'msg_msg-16' already exists [ 2.404801] WARNING: CPU: 2 PID: 1 at mm/slab_common.c:107 __kmem_cache_create_args+0xb8/0x3b0 [ 2.404842] Modules linked in: [ 2.404971] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.12.0-rc5mm-unstable-arm64+ #12 [ 2.405026] Tainted: [W]=WARN [ 2.405043] Hardware name: QEMU QEMU Virtual Machine, BIOS 2024.02-2 03/11/2024 [ 2.405057] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2.405079] pc : __kmem_cache_create_args+0xb8/0x3b0 [ 2.405100] lr : __kmem_cache_create_args+0xb8/0x3b0 [ 2.405111] sp : ffff800083d6fc50 [ 2.405115] x29: ffff800083d6fc50 x28: fbff0000c1674410 x27: ffff8000820b0598 [ 2.405135] x26: 000000000000ffd0 x25: 0000000000000010 x24: 0000000000006000 [ 2.405153] x23: ffff800083d6fce8 x22: ffff8000832222e8 x21: ffff800083222388 [ 2.405169] x20: fbff0000c1674410 x19: fdff0000c163d6c0 x18: ffff800083d80030 [ 2.405185] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 2.405201] x14: 0000000000000000 x13: 0a73747369786520 x12: 79646165726c6120 [ 2.405217] x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : 0000000000000000 [ 2.405233] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 [ 2.405248] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 2.405271] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 2.405287] Call trace: [ 2 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50275", "url": "https://ubuntu.com/security/CVE-2024-50275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64/sve: Discard stale CPU state when handling SVE traps The logic for handling SVE traps manipulates saved FPSIMD/SVE state incorrectly, and a race with preemption can result in a task having TIF_SVE set and TIF_FOREIGN_FPSTATE clear even though the live CPU state is stale (e.g. with SVE traps enabled). This has been observed to result in warnings from do_sve_acc() where SVE traps are not expected while TIF_SVE is set: | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* SVE access shouldn't have trapped */ Warnings of this form have been reported intermittently, e.g. https://lore.kernel.org/linux-arm-kernel/CA+G9fYtEGe_DhY2Ms7+L7NKsLYUomGsgqpdBj+QwDLeSg=JhGg@mail.gmail.com/ https://lore.kernel.org/linux-arm-kernel/000000000000511e9a060ce5a45c@google.com/ The race can occur when the SVE trap handler is preempted before and after manipulating the saved FPSIMD/SVE state, starting and ending on the same CPU, e.g. | void do_sve_acc(unsigned long esr, struct pt_regs *regs) | { | // Trap on CPU 0 with TIF_SVE clear, SVE 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(); | | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* SVE access shouldn't have trapped */ | | sve_init_regs() { | if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) { | ... | } else { | fpsimd_to_sve(current); | current->thread.fp_type = FP_STATE_SVE; | } | } | | 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 SVE 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.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50276", "url": "https://ubuntu.com/security/CVE-2024-50276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: vertexcom: mse102x: Fix possible double free of TX skb The scope of the TX skb is wider than just mse102x_tx_frame_spi(), so in case the TX skb room needs to be expanded, we should free the the temporary skb instead of the original skb. Otherwise the original TX skb pointer would be freed again in mse102x_tx_work(), which leads to crashes: Internal error: Oops: 0000000096000004 [#2] PREEMPT SMP CPU: 0 PID: 712 Comm: kworker/0:1 Tainted: G D 6.6.23 Hardware name: chargebyte Charge SOM DC-ONE (DT) Workqueue: events mse102x_tx_work [mse102x] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_release_data+0xb8/0x1d8 lr : skb_release_data+0x1ac/0x1d8 sp : ffff8000819a3cc0 x29: ffff8000819a3cc0 x28: ffff0000046daa60 x27: ffff0000057f2dc0 x26: ffff000005386c00 x25: 0000000000000002 x24: 00000000ffffffff x23: 0000000000000000 x22: 0000000000000001 x21: ffff0000057f2e50 x20: 0000000000000006 x19: 0000000000000000 x18: ffff00003fdacfcc x17: e69ad452d0c49def x16: 84a005feff870102 x15: 0000000000000000 x14: 000000000000024a x13: 0000000000000002 x12: 0000000000000000 x11: 0000000000000400 x10: 0000000000000930 x9 : ffff00003fd913e8 x8 : fffffc00001bc008 x7 : 0000000000000000 x6 : 0000000000000008 x5 : ffff00003fd91340 x4 : 0000000000000000 x3 : 0000000000000009 x2 : 00000000fffffffe x1 : 0000000000000000 x0 : 0000000000000000 Call trace: skb_release_data+0xb8/0x1d8 kfree_skb_reason+0x48/0xb0 mse102x_tx_work+0x164/0x35c [mse102x] process_one_work+0x138/0x260 worker_thread+0x32c/0x438 kthread+0x118/0x11c ret_from_fork+0x10/0x20 Code: aa1303e0 97fffab6 72001c1f 54000141 (f9400660)", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53066", "url": "https://ubuntu.com/security/CVE-2024-53066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfs: Fix KMSAN warning in decode_getfattr_attrs() Fix the following KMSAN warning: CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G B Tainted: [B]=BAD_PAGE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) ===================================================== ===================================================== BUG: KMSAN: uninit-value in decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_generic+0x806/0xb00 nfs4_xdr_dec_getattr+0x1de/0x240 rpcauth_unwrap_resp_decode+0xab/0x100 rpcauth_unwrap_resp+0x95/0xc0 call_decode+0x4ff/0xb50 __rpc_execute+0x57b/0x19d0 rpc_execute+0x368/0x5e0 rpc_run_task+0xcfe/0xee0 nfs4_proc_getattr+0x5b5/0x990 __nfs_revalidate_inode+0x477/0xd00 nfs_access_get_cached+0x1021/0x1cc0 nfs_do_access+0x9f/0xae0 nfs_permission+0x1e4/0x8c0 inode_permission+0x356/0x6c0 link_path_walk+0x958/0x1330 path_lookupat+0xce/0x6b0 filename_lookup+0x23e/0x770 vfs_statx+0xe7/0x970 vfs_fstatat+0x1f2/0x2c0 __se_sys_newfstatat+0x67/0x880 __x64_sys_newfstatat+0xbd/0x120 x64_sys_call+0x1826/0x3cf0 do_syscall_64+0xd0/0x1b0 entry_SYSCALL_64_after_hwframe+0x77/0x7f The KMSAN warning is triggered in decode_getfattr_attrs(), when calling decode_attr_mdsthreshold(). It appears that fattr->mdsthreshold is not initialized. Fix the issue by initializing fattr->mdsthreshold to NULL in nfs_fattr_init().", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53067", "url": "https://ubuntu.com/security/CVE-2024-53067", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Start the RTC update work later The RTC update work involves runtime resuming the UFS controller. Hence, only start the RTC update work after runtime power management in the UFS driver has been fully initialized. This patch fixes the following kernel crash: Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP Workqueue: events ufshcd_rtc_work Call trace: _raw_spin_lock_irqsave+0x34/0x8c (P) pm_runtime_get_if_active+0x24/0x9c (L) pm_runtime_get_if_active+0x24/0x9c ufshcd_rtc_work+0x138/0x1b4 process_one_work+0x148/0x288 worker_thread+0x2cc/0x3d4 kthread+0x110/0x114 ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50277", "url": "https://ubuntu.com/security/CVE-2024-50277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: fix a crash if blk_alloc_disk fails If blk_alloc_disk fails, the variable md->disk is set to an error value. cleanup_mapped_device will see that md->disk is non-NULL and it will attempt to access it, causing a crash on this statement \"md->disk->private_data = NULL;\".", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50278", "url": "https://ubuntu.com/security/CVE-2024-50278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix potential out-of-bounds access on the first resume Out-of-bounds access occurs if the fast device is expanded unexpectedly before the first-time resume of the cache table. This happens because expanding the fast device requires reloading the cache table for cache_create to allocate new in-core data structures that fit the new size, and the check in cache_preresume is not performed during the first resume, leading to the issue. Reproduce steps: 1. prepare component devices: 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\" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct 2. load a cache table of 512 cache blocks, and deliberately expand the fast device before resuming the cache, making the in-core data structures inadequate. dmsetup create cache --notable dmsetup reload cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" dmsetup reload cdata --table \"0 131072 linear /dev/sdc 8192\" dmsetup resume cdata dmsetup resume cache 3. suspend the cache to write out the in-core dirty bitset and hint array, leading to out-of-bounds access to the dirty bitset at offset 0x40: dmsetup suspend cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80 Read of size 8 at addr ffffc90000085040 by task dmsetup/90 (...snip...) The buggy address belongs to the virtual mapping at [ffffc90000085000, ffffc90000087000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by checking the size change on the first resume.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50279", "url": "https://ubuntu.com/security/CVE-2024-50279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix out-of-bounds access to the dirty bitset when resizing dm-cache checks the dirty bits of the cache blocks to be dropped when shrinking the fast device, but an index bug in bitset iteration causes out-of-bounds access. Reproduce steps: 1. create a cache device of 1024 cache blocks (128 bytes dirty bitset) dmsetup create cmeta --table \"0 8192 linear /dev/sdc 0\" dmsetup create cdata --table \"0 131072 linear /dev/sdc 8192\" dmsetup create corig --table \"0 524288 linear /dev/sdc 262144\" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" 2. shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80) dmsetup suspend cache dmsetup reload cdata --table \"0 65536 linear /dev/sdc 8192\" dmsetup resume cdata dmsetup resume cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131 (...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by making the index post-incremented.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50280", "url": "https://ubuntu.com/security/CVE-2024-50280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix flushing uninitialized delayed_work on cache_ctr error An unexpected WARN_ON from flush_work() may occur when cache creation fails, caused by destroying the uninitialized delayed_work waker in the error path of cache_create(). For example, the warning appears on the superblock checksum error. Reproduce steps: 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\" dd if=/dev/urandom of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" Kernel logs: (snip) WARNING: CPU: 0 PID: 84 at kernel/workqueue.c:4178 __flush_work+0x5d4/0x890 Fix by pulling out the cancel_delayed_work_sync() from the constructor's error path. This patch doesn't affect the use-after-free fix for concurrent dm_resume and dm_destroy (commit 6a459d8edbdb (\"dm cache: Fix UAF in destroy()\")) as cache_dtr is not changed.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50281", "url": "https://ubuntu.com/security/CVE-2024-50281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: trusted: dcp: fix NULL dereference in AEAD crypto operation When sealing or unsealing a key blob we currently do not wait for the AEAD cipher operation to finish and simply return after submitting the request. If there is some load on the system we can exit before the cipher operation is done and the buffer we read from/write to is already removed from the stack. This will e.g. result in NULL pointer dereference errors in the DCP driver during blob creation. Fix this by waiting for the AEAD cipher operation to finish before resuming the seal and unseal calls.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50282", "url": "https://ubuntu.com/security/CVE-2024-50282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read() Avoid a possible buffer overflow if size is larger than 4K. (cherry picked from commit f5d873f5825b40d886d03bd2aede91d4cf002434)", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53071", "url": "https://ubuntu.com/security/CVE-2024-53071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Be stricter about IO mapping flags The current panthor_device_mmap_io() implementation has two issues: 1. For mapping DRM_PANTHOR_USER_FLUSH_ID_MMIO_OFFSET, panthor_device_mmap_io() bails if VM_WRITE is set, but does not clear VM_MAYWRITE. That means userspace can use mprotect() to make the mapping writable later on. This is a classic Linux driver gotcha. I don't think this actually has any impact in practice: When the GPU is powered, writes to the FLUSH_ID seem to be ignored; and when the GPU is not powered, the dummy_latest_flush page provided by the driver is deliberately designed to not do any flushes, so the only thing writing to the dummy_latest_flush could achieve would be to make *more* flushes happen. 2. panthor_device_mmap_io() does not block MAP_PRIVATE mappings (which are mappings without the VM_SHARED flag). MAP_PRIVATE in combination with VM_MAYWRITE indicates that the VMA has copy-on-write semantics, which for VM_PFNMAP are semi-supported but fairly cursed. In particular, in such a mapping, the driver can only install PTEs during mmap() by calling remap_pfn_range() (because remap_pfn_range() wants to **store the physical address of the mapped physical memory into the vm_pgoff of the VMA**); installing PTEs later on with a fault handler (as panthor does) is not supported in private mappings, and so if you try to fault in such a mapping, vmf_insert_pfn_prot() splats when it hits a BUG() check. Fix it by clearing the VM_MAYWRITE flag (userspace writing to the FLUSH_ID doesn't make sense) and requiring VM_SHARED (copy-on-write semantics for the FLUSH_ID don't make sense). Reproducers for both scenarios are in the notes of my patch on the mailing list; I tested that these bugs exist on a Rock 5B machine. Note that I only compile-tested the patch, I haven't tested it; I don't have a working kernel build setup for the test machine yet. Please test it before applying it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53080", "url": "https://ubuntu.com/security/CVE-2024-53080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Lock XArray when getting entries for the VM Similar to commit cac075706f29 (\"drm/panthor: Fix race when converting group handle to group object\") we need to use the XArray's internal locking when retrieving a vm pointer from there. v2: Removed part of the patch that was trying to protect fetching the heap pointer from XArray, as that operation is protected by the @pool->lock.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53084", "url": "https://ubuntu.com/security/CVE-2024-53084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Break an object reference loop When remaining resources are being cleaned up on driver close, outstanding VM mappings may result in resources being leaked, due to an object reference loop, as shown below, with each object (or set of objects) referencing the object below it: PVR GEM Object GPU scheduler \"finished\" fence GPU scheduler “scheduled” fence PVR driver “done” fence PVR Context PVR VM Context PVR VM Mappings PVR GEM Object The reference that the PVR VM Context has on the VM mappings is a soft one, in the sense that the freeing of outstanding VM mappings is done as part of VM context destruction; no reference counts are involved, as is the case for all the other references in the loop. To break the reference loop during cleanup, free the outstanding VM mappings before destroying the PVR Context associated with the VM context.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53085", "url": "https://ubuntu.com/security/CVE-2024-53085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: Lock TPM chip in tpm_pm_suspend() first Setting TPM_CHIP_FLAG_SUSPENDED in the end of tpm_pm_suspend() can be racy according, as this leaves window for tpm_hwrng_read() to be called while the operation is in progress. The recent bug report gives also evidence of this behaviour. Aadress this by locking the TPM chip before checking any chip->flags both in tpm_pm_suspend() and tpm_hwrng_read(). Move TPM_CHIP_FLAG_SUSPENDED check inside tpm_get_random() so that it will be always checked only when the lock is reserved.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53086", "url": "https://ubuntu.com/security/CVE-2024-53086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Drop VM dma-resv lock on xe_sync_in_fence_get failure in exec IOCTL Upon failure all locks need to be dropped before returning to the user. (cherry picked from commit 7d1a4258e602ffdce529f56686925034c1b3b095)", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53087", "url": "https://ubuntu.com/security/CVE-2024-53087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix possible exec queue leak in exec IOCTL In a couple of places after an exec queue is looked up the exec IOCTL returns on input errors without dropping the exec queue ref. Fix this ensuring the exec queue ref is dropped on input error. (cherry picked from commit 07064a200b40ac2195cb6b7b779897d9377e5e6f)", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50283", "url": "https://ubuntu.com/security/CVE-2024-50283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-use-after-free in smb3_preauth_hash_rsp ksmbd_user_session_put should be called under smb3_preauth_hash_rsp(). It will avoid freeing session before calling smb3_preauth_hash_rsp().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50284", "url": "https://ubuntu.com/security/CVE-2024-50284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix the missing xa_store error check xa_store() can fail, it return xa_err(-EINVAL) if the entry cannot be stored in an XArray, or xa_err(-ENOMEM) if memory allocation failed, so check error for xa_store() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50285", "url": "https://ubuntu.com/security/CVE-2024-50285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: check outstanding simultaneous SMB operations If Client send simultaneous SMB operations to ksmbd, It exhausts too much memory through the \"ksmbd_work_cache”. It will cause OOM issue. ksmbd has a credit mechanism but it can't handle this problem. This patch add the check if it exceeds max credits to prevent this problem by assuming that one smb request consumes at least one credit.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50286", "url": "https://ubuntu.com/security/CVE-2024-50286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-use-after-free in ksmbd_smb2_session_create There is a race condition between ksmbd_smb2_session_create and ksmbd_expire_session. This patch add missing sessions_table_lock while adding/deleting session from global session table.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50287", "url": "https://ubuntu.com/security/CVE-2024-50287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-tpg: prevent the risk of a division by zero As reported by Coverity, the logic at tpg_precalculate_line() blindly rescales the buffer even when scaled_witdh is equal to zero. If this ever happens, this will cause a division by zero. Instead, add a WARN_ON_ONCE() to trigger such cases and return without doing any precalculation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50288", "url": "https://ubuntu.com/security/CVE-2024-50288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: fix buffer overwrite when using > 32 buffers The maximum number of buffers that can be requested was increased to 64 for the video capture queue. But video capture used a must_blank array that was still sized for 32 (VIDEO_MAX_FRAME). This caused an out-of-bounds write when using buffer indices >= 32. Create a new define MAX_VID_CAP_BUFFERS that is used to access the must_blank array and set max_num_buffers for the video capture queue. This solves a crash reported by: \thttps://bugzilla.kernel.org/show_bug.cgi?id=219258", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50289", "url": "https://ubuntu.com/security/CVE-2024-50289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: av7110: fix a spectre vulnerability As warned by smatch: \tdrivers/staging/media/av7110/av7110_ca.c:270 dvb_ca_ioctl() warn: potential spectre issue 'av7110->ci_slot' [w] (local cap) There is a spectre-related vulnerability at the code. Fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50290", "url": "https://ubuntu.com/security/CVE-2024-50290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx24116: prevent overflows on SNR calculus as reported by Coverity, if reading SNR registers fail, a negative number will be returned, causing an underflow when reading SNR registers. Prevent that.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53061", "url": "https://ubuntu.com/security/CVE-2024-53061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: s5p-jpeg: prevent buffer overflows The current logic allows word to be less than 2. If this happens, there will be buffer overflows, as reported by smatch. Add extra checks to prevent it. While here, remove an unused word = 0 assignment.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53081", "url": "https://ubuntu.com/security/CVE-2024-53081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ar0521: don't overflow when checking PLL values The PLL checks are comparing 64 bit integers with 32 bit ones, as reported by Coverity. Depending on the values of the variables, this may underflow. Fix it ensuring that both sides of the expression are u64.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53062", "url": "https://ubuntu.com/security/CVE-2024-53062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mgb4: protect driver against spectre Frequency range is set from sysfs via frequency_range_store(), being vulnerable to spectre, as reported by smatch: \tdrivers/media/pci/mgb4/mgb4_cmt.c:231 mgb4_cmt_set_vin_freq_range() warn: potential spectre issue 'cmt_vals_in' [r] \tdrivers/media/pci/mgb4/mgb4_cmt.c:238 mgb4_cmt_set_vin_freq_range() warn: possible spectre second half. 'reg_set' Fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50291", "url": "https://ubuntu.com/security/CVE-2024-50291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvb-core: add missing buffer index check dvb_vb2_expbuf() didn't check if the given buffer index was for a valid buffer. Add this check.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50292", "url": "https://ubuntu.com/security/CVE-2024-50292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: stm32: spdifrx: fix dma channel release in stm32_spdifrx_remove In case of error when requesting ctrl_chan DMA channel, ctrl_chan is not null. So the release of the dma channel leads to the following issue: [ 4.879000] st,stm32-spdifrx 500d0000.audio-controller: dma_request_slave_channel error -19 [ 4.888975] Unable to handle kernel NULL pointer dereference at virtual address 000000000000003d [...] [ 5.096577] Call trace: [ 5.099099] dma_release_channel+0x24/0x100 [ 5.103235] stm32_spdifrx_remove+0x24/0x60 [snd_soc_stm32_spdifrx] [ 5.109494] stm32_spdifrx_probe+0x320/0x4c4 [snd_soc_stm32_spdifrx] To avoid this issue, release channel only if the pointer is valid.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53063", "url": "https://ubuntu.com/security/CVE-2024-53063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvbdev: prevent the risk of out of memory access The dvbdev contains a static variable used to store dvb minors. The behavior of it depends if CONFIG_DVB_DYNAMIC_MINORS is set or not. When not set, dvb_register_device() won't check for boundaries, as it will rely that a previous call to dvb_register_adapter() would already be enforcing it. On a similar way, dvb_device_open() uses the assumption that the register functions already did the needed checks. This can be fragile if some device ends using different calls. This also generate warnings on static check analysers like Coverity. So, add explicit guards to prevent potential risk of OOM issues.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50293", "url": "https://ubuntu.com/security/CVE-2024-50293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: do not leave a dangling sk pointer in __smc_create() Thanks to commit 4bbd360a5084 (\"socket: Print pf->create() when it does not clear sock->sk on failure.\"), syzbot found an issue with AF_SMC: smc_create must clear sock->sk on failure, family: 43, type: 1, protocol: 0 WARNING: CPU: 0 PID: 5827 at net/socket.c:1565 __sock_create+0x96f/0xa30 net/socket.c:1563 Modules linked in: CPU: 0 UID: 0 PID: 5827 Comm: syz-executor259 Not tainted 6.12.0-rc6-next-20241106-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:__sock_create+0x96f/0xa30 net/socket.c:1563 Code: 03 00 74 08 4c 89 e7 e8 4f 3b 85 f8 49 8b 34 24 48 c7 c7 40 89 0c 8d 8b 54 24 04 8b 4c 24 0c 44 8b 44 24 08 e8 32 78 db f7 90 <0f> 0b 90 90 e9 d3 fd ff ff 89 e9 80 e1 07 fe c1 38 c1 0f 8c ee f7 RSP: 0018:ffffc90003e4fda0 EFLAGS: 00010246 RAX: 099c6f938c7f4700 RBX: 1ffffffff1a595fd RCX: ffff888034823c00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 00000000ffffffe9 R08: ffffffff81567052 R09: 1ffff920007c9f50 R10: dffffc0000000000 R11: fffff520007c9f51 R12: ffffffff8d2cafe8 R13: 1ffffffff1a595fe R14: ffffffff9a789c40 R15: ffff8880764298c0 FS: 000055557b518380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa62ff43225 CR3: 0000000031628000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: sock_create net/socket.c:1616 [inline] __sys_socket_create net/socket.c:1653 [inline] __sys_socket+0x150/0x3c0 net/socket.c:1700 __do_sys_socket net/socket.c:1714 [inline] __se_sys_socket net/socket.c:1712 [inline] For reference, see commit 2d859aff775d (\"Merge branch 'do-not-leave-dangling-sk-pointers-in-pf-create-functions'\")", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50294", "url": "https://ubuntu.com/security/CVE-2024-50294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix missing locking causing hanging calls If a call gets aborted (e.g. because kafs saw a signal) between it being queued for connection and the I/O thread picking up the call, the abort will be prioritised over the connection and it will be removed from local->new_client_calls by rxrpc_disconnect_client_call() without a lock being held. This may cause other calls on the list to disappear if a race occurs. Fix this by taking the client_call_lock when removing a call from whatever list its ->wait_link happens to be on.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50295", "url": "https://ubuntu.com/security/CVE-2024-50295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: arc: fix the device for dma_map_single/dma_unmap_single The ndev->dev and pdev->dev aren't the same device, use ndev->dev.parent which has dma_mask, ndev->dev.parent is just pdev->dev. Or it would cause the following issue: [ 39.933526] ------------[ cut here ]------------ [ 39.938414] WARNING: CPU: 1 PID: 501 at kernel/dma/mapping.c:149 dma_map_page_attrs+0x90/0x1f8", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53082", "url": "https://ubuntu.com/security/CVE-2024-53082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_net: Add hash_key_length check Add hash_key_length check in virtnet_probe() to avoid possible out of bound errors when setting/reading the hash key.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50296", "url": "https://ubuntu.com/security/CVE-2024-50296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash when uninstalling driver When the driver is uninstalled and the VF is disabled concurrently, a kernel crash occurs. The reason is that the two actions call function pci_disable_sriov(). The num_VFs is checked to determine whether to release the corresponding resources. During the second calling, num_VFs is not 0 and the resource release function is called. However, the corresponding resource has been released during the first invoking. Therefore, the problem occurs: [15277.839633][T50670] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ... [15278.131557][T50670] Call trace: [15278.134686][T50670] klist_put+0x28/0x12c [15278.138682][T50670] klist_del+0x14/0x20 [15278.142592][T50670] device_del+0xbc/0x3c0 [15278.146676][T50670] pci_remove_bus_device+0x84/0x120 [15278.151714][T50670] pci_stop_and_remove_bus_device+0x6c/0x80 [15278.157447][T50670] pci_iov_remove_virtfn+0xb4/0x12c [15278.162485][T50670] sriov_disable+0x50/0x11c [15278.166829][T50670] pci_disable_sriov+0x24/0x30 [15278.171433][T50670] hnae3_unregister_ae_algo_prepare+0x60/0x90 [hnae3] [15278.178039][T50670] hclge_exit+0x28/0xd0 [hclge] [15278.182730][T50670] __se_sys_delete_module.isra.0+0x164/0x230 [15278.188550][T50670] __arm64_sys_delete_module+0x1c/0x30 [15278.193848][T50670] invoke_syscall+0x50/0x11c [15278.198278][T50670] el0_svc_common.constprop.0+0x158/0x164 [15278.203837][T50670] do_el0_svc+0x34/0xcc [15278.207834][T50670] el0_svc+0x20/0x30 For details, see the following figure. rmmod hclge disable VFs ---------------------------------------------------- hclge_exit() sriov_numvfs_store() ... device_lock() pci_disable_sriov() hns3_pci_sriov_configure() pci_disable_sriov() sriov_disable() sriov_disable() if !num_VFs : if !num_VFs : return; return; sriov_del_vfs() sriov_del_vfs() ... ... klist_put() klist_put() ... ... num_VFs = 0; num_VFs = 0; device_unlock(); In this patch, when driver is removing, we get the device_lock() to protect num_VFs, just like sriov_numvfs_store().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53088", "url": "https://ubuntu.com/security/CVE-2024-53088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: fix race condition by adding filter's intermediate sync state Fix a race condition in the i40e driver that leads to MAC/VLAN filters becoming corrupted and leaking. Address the issue that occurs under heavy load when multiple threads are concurrently modifying MAC/VLAN filters by setting mac and port VLAN. 1. Thread T0 allocates a filter in i40e_add_filter() within i40e_ndo_set_vf_port_vlan(). 2. Thread T1 concurrently frees the filter in __i40e_del_filter() within i40e_ndo_set_vf_mac(). 3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which refers to the already freed filter memory, causing corruption. Reproduction steps: 1. Spawn multiple VFs. 2. Apply a concurrent heavy load by running parallel operations to change MAC addresses on the VFs and change port VLANs on the host. 3. Observe errors in dmesg: \"Error I40E_AQ_RC_ENOSPC adding RX filters on VF XX, \tplease set promiscuous on manually for VF XX\". Exact code for stable reproduction Intel can't open-source now. The fix involves implementing a new intermediate filter state, I40E_FILTER_NEW_SYNC, for the time when a filter is on a tmp_add_list. These filters cannot be deleted from the hash list directly but must be removed using the full process.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50297", "url": "https://ubuntu.com/security/CVE-2024-50297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: xilinx: axienet: Enqueue Tx packets in dql before dmaengine starts Enqueue packets in dql after dma engine starts causes race condition. Tx transfer starts once dma engine is started and may execute dql dequeue in completion before it gets queued. It results in following kernel crash while running iperf stress test: kernel BUG at lib/dynamic_queue_limits.c:99! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP pc : dql_completed+0x238/0x248 lr : dql_completed+0x3c/0x248 Call trace: dql_completed+0x238/0x248 axienet_dma_tx_cb+0xa0/0x170 xilinx_dma_do_tasklet+0xdc/0x290 tasklet_action_common+0xf8/0x11c tasklet_action+0x30/0x3c handle_softirqs+0xf8/0x230 Start dmaengine after enqueue in dql fixes the crash.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50298", "url": "https://ubuntu.com/security/CVE-2024-50298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: enetc: allocate vf_state during PF probes In the previous implementation, vf_state is allocated memory only when VF is enabled. However, net_device_ops::ndo_set_vf_mac() may be called before VF is enabled to configure the MAC address of VF. If this is the case, enetc_pf_set_vf_mac() will access vf_state, resulting in access to a null pointer. The simplified error log is as follows. root@ls1028ardb:~# ip link set eno0 vf 1 mac 00:0c:e7:66:77:89 [ 173.543315] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 [ 173.637254] pc : enetc_pf_set_vf_mac+0x3c/0x80 Message from sy [ 173.641973] lr : do_setlink+0x4a8/0xec8 [ 173.732292] Call trace: [ 173.734740] enetc_pf_set_vf_mac+0x3c/0x80 [ 173.738847] __rtnl_newlink+0x530/0x89c [ 173.742692] rtnl_newlink+0x50/0x7c [ 173.746189] rtnetlink_rcv_msg+0x128/0x390 [ 173.750298] netlink_rcv_skb+0x60/0x130 [ 173.754145] rtnetlink_rcv+0x18/0x24 [ 173.757731] netlink_unicast+0x318/0x380 [ 173.761665] netlink_sendmsg+0x17c/0x3c8", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50299", "url": "https://ubuntu.com/security/CVE-2024-50299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: properly validate chunk size in sctp_sf_ootb() A size validation fix similar to that in Commit 50619dbf8db7 (\"sctp: add size validation when walking chunks\") is also required in sctp_sf_ootb() to address a crash reported by syzbot: BUG: KMSAN: uninit-value in sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_do_sm+0x181/0x93d0 net/sctp/sm_sideeffect.c:1166 sctp_endpoint_bh_rcv+0xc38/0xf90 net/sctp/endpointola.c:407 sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88 sctp_rcv+0x3831/0x3b20 net/sctp/input.c:243 sctp4_rcv+0x42/0x50 net/sctp/protocol.c:1159 ip_protocol_deliver_rcu+0xb51/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50300", "url": "https://ubuntu.com/security/CVE-2024-50300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: rtq2208: Fix uninitialized use of regulator_config Fix rtq2208 driver uninitialized use to cause kernel error.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50301", "url": "https://ubuntu.com/security/CVE-2024-50301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: security/keys: fix slab-out-of-bounds in key_task_permission KASAN reports an out of bounds read: BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline] BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362 CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0x107/0x167 lib/dump_stack.c:123 print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 __kuid_val include/linux/uidgid.h:36 [inline] uid_eq include/linux/uidgid.h:63 [inline] key_task_permission+0x394/0x410 security/keys/permission.c:54 search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793 This issue was also reported by syzbot. It can be reproduced by following these steps(more details [1]): 1. Obtain more than 32 inputs that have similar hashes, which ends with the pattern '0xxxxxxxe6'. 2. Reboot and add the keys obtained in step 1. The reproducer demonstrates how this issue happened: 1. In the search_nested_keyrings function, when it iterates through the slots in a node(below tag ascend_to_node), if the slot pointer is meta and node->back_pointer != NULL(it means a root), it will proceed to descend_to_node. However, there is an exception. If node is the root, and one of the slots points to a shortcut, it will be treated as a keyring. 2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function. However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as ASSOC_ARRAY_PTR_SUBTYPE_MASK. 3. When 32 keys with the similar hashes are added to the tree, the ROOT has keys with hashes that are not similar (e.g. slot 0) and it splits NODE A without using a shortcut. When NODE A is filled with keys that all hashes are xxe6, the keys are similar, NODE A will split with a shortcut. Finally, it forms the tree as shown below, where slot 6 points to a shortcut. NODE A +------>+---+ ROOT | | 0 | xxe6 +---+ | +---+ xxxx | 0 | shortcut : : xxe6 +---+ | +---+ xxe6 : : | | | xxe6 +---+ | +---+ | 6 |---+ : : xxe6 +---+ +---+ xxe6 : : | f | xxe6 +---+ +---+ xxe6 | f | +---+ 4. As mentioned above, If a slot(slot 6) of the root points to a shortcut, it may be mistakenly transferred to a key*, leading to a read out-of-bounds read. To fix this issue, one should jump to descend_to_node if the ptr is a shortcut, regardless of whether the node is root or not. [1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/ [jarkko: tweaked the commit message a bit to have an appropriate closes tag.]", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53072", "url": "https://ubuntu.com/security/CVE-2024-53072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/pmc: Detect when STB is not available Loading the amd_pmc module as: amd_pmc enable_stb=1 ...can result in the following messages in the kernel ring buffer: amd_pmc AMDI0009:00: SMU cmd failed. err: 0xff ioremap on RAM at 0x0000000000000000 - 0x0000000000ffffff WARNING: CPU: 10 PID: 2151 at arch/x86/mm/ioremap.c:217 __ioremap_caller+0x2cd/0x340 Further debugging reveals that this occurs when the requests for S2D_PHYS_ADDR_LOW and S2D_PHYS_ADDR_HIGH return a value of 0, indicating that the STB is inaccessible. To prevent the ioremap warning and provide clarity to the user, handle the invalid address and display an error message.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50302", "url": "https://ubuntu.com/security/CVE-2024-50302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: zero-initialize the report buffer Since the report buffer is used by all kinds of drivers in various ways, let's zero-initialize it during allocation to make sure that it can't be ever used to leak kernel memory via specially-crafted report.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53068", "url": "https://ubuntu.com/security/CVE-2024-53068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix slab-use-after-free in scmi_bus_notifier() The scmi_dev->name is released prematurely in __scmi_device_destroy(), which causes slab-use-after-free when accessing scmi_dev->name in scmi_bus_notifier(). So move the release of scmi_dev->name to scmi_device_release() to avoid slab-use-after-free. | BUG: KASAN: slab-use-after-free in strncmp+0xe4/0xec | Read of size 1 at addr ffffff80a482bcc0 by task swapper/0/1 | | CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.6.38-debug #1 | Hardware name: Qualcomm Technologies, Inc. SA8775P Ride (DT) | Call trace: | dump_backtrace+0x94/0x114 | show_stack+0x18/0x24 | dump_stack_lvl+0x48/0x60 | print_report+0xf4/0x5b0 | kasan_report+0xa4/0xec | __asan_report_load1_noabort+0x20/0x2c | strncmp+0xe4/0xec | scmi_bus_notifier+0x5c/0x54c | notifier_call_chain+0xb4/0x31c | blocking_notifier_call_chain+0x68/0x9c | bus_notify+0x54/0x78 | device_del+0x1bc/0x840 | device_unregister+0x20/0xb4 | __scmi_device_destroy+0xac/0x280 | scmi_device_destroy+0x94/0xd0 | scmi_chan_setup+0x524/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20 | | Allocated by task 1: | kasan_save_stack+0x2c/0x54 | kasan_set_track+0x2c/0x40 | kasan_save_alloc_info+0x24/0x34 | __kasan_kmalloc+0xa0/0xb8 | __kmalloc_node_track_caller+0x6c/0x104 | kstrdup+0x48/0x84 | kstrdup_const+0x34/0x40 | __scmi_device_create.part.0+0x8c/0x408 | scmi_device_create+0x104/0x370 | scmi_chan_setup+0x2a0/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20 | | Freed by task 1: | kasan_save_stack+0x2c/0x54 | kasan_set_track+0x2c/0x40 | kasan_save_free_info+0x38/0x5c | __kasan_slab_free+0xe8/0x164 | __kmem_cache_free+0x11c/0x230 | kfree+0x70/0x130 | kfree_const+0x20/0x40 | __scmi_device_destroy+0x70/0x280 | scmi_device_destroy+0x94/0xd0 | scmi_chan_setup+0x524/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53069", "url": "https://ubuntu.com/security/CVE-2024-53069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: qcom: scm: fix a NULL-pointer dereference Some SCM calls can be invoked with __scm being NULL (the driver may not have been and will not be probed as there's no SCM entry in device-tree). Make sure we don't dereference a NULL pointer.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50212", "url": "https://ubuntu.com/security/CVE-2024-50212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib: alloc_tag_module_unload must wait for pending kfree_rcu calls Ben Greear reports following splat: ------------[ cut here ]------------ net/netfilter/nf_nat_core.c:1114 module nf_nat func:nf_nat_register_fn has 256 allocated at module unload WARNING: CPU: 1 PID: 10421 at lib/alloc_tag.c:168 alloc_tag_module_unload+0x22b/0x3f0 Modules linked in: nf_nat(-) btrfs ufs qnx4 hfsplus hfs minix vfat msdos fat ... Hardware name: Default string Default string/SKYBAY, BIOS 5.12 08/04/2020 RIP: 0010:alloc_tag_module_unload+0x22b/0x3f0 codetag_unload_module+0x19b/0x2a0 ? codetag_load_module+0x80/0x80 nf_nat module exit calls kfree_rcu on those addresses, but the free operation is likely still pending by the time alloc_tag checks for leaks. Wait for outstanding kfree_rcu operations to complete before checking resolves this warning. Reproducer: unshare -n iptables-nft -t nat -A PREROUTING -p tcp grep nf_nat /proc/allocinfo # will list 4 allocations rmmod nft_chain_nat rmmod nf_nat # will WARN. [akpm@linux-foundation.org: add comment]", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53046", "url": "https://ubuntu.com/security/CVE-2024-53046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: dts: imx8ulp: correct the flexspi compatible string The flexspi on imx8ulp only has 16 LUTs, and imx8mm flexspi has 32 LUTs, so correct the compatible string here, otherwise will meet below error: [ 1.119072] ------------[ cut here ]------------ [ 1.123926] WARNING: CPU: 0 PID: 1 at drivers/spi/spi-nxp-fspi.c:855 nxp_fspi_exec_op+0xb04/0xb64 [ 1.133239] Modules linked in: [ 1.136448] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-rc6-next-20240902-00001-g131bf9439dd9 #69 [ 1.146821] Hardware name: NXP i.MX8ULP EVK (DT) [ 1.151647] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.158931] pc : nxp_fspi_exec_op+0xb04/0xb64 [ 1.163496] lr : nxp_fspi_exec_op+0xa34/0xb64 [ 1.168060] sp : ffff80008002b2a0 [ 1.171526] x29: ffff80008002b2d0 x28: 0000000000000000 x27: 0000000000000000 [ 1.179002] x26: ffff2eb645542580 x25: ffff800080610014 x24: ffff800080610000 [ 1.186480] x23: ffff2eb645548080 x22: 0000000000000006 x21: ffff2eb6455425e0 [ 1.193956] x20: 0000000000000000 x19: ffff80008002b5e0 x18: ffffffffffffffff [ 1.201432] x17: ffff2eb644467508 x16: 0000000000000138 x15: 0000000000000002 [ 1.208907] x14: 0000000000000000 x13: ffff2eb6400d8080 x12: 00000000ffffff00 [ 1.216378] x11: 0000000000000000 x10: ffff2eb6400d8080 x9 : ffff2eb697adca80 [ 1.223850] x8 : ffff2eb697ad3cc0 x7 : 0000000100000000 x6 : 0000000000000001 [ 1.231324] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000007a6 [ 1.238795] x2 : 0000000000000000 x1 : 00000000000001ce x0 : 00000000ffffff92 [ 1.246267] Call trace: [ 1.248824] nxp_fspi_exec_op+0xb04/0xb64 [ 1.253031] spi_mem_exec_op+0x3a0/0x430 [ 1.257139] spi_nor_read_id+0x80/0xcc [ 1.261065] spi_nor_scan+0x1ec/0xf10 [ 1.264901] spi_nor_probe+0x108/0x2fc [ 1.268828] spi_mem_probe+0x6c/0xbc [ 1.272574] spi_probe+0x84/0xe4 [ 1.275958] really_probe+0xbc/0x29c [ 1.279713] __driver_probe_device+0x78/0x12c [ 1.284277] driver_probe_device+0xd8/0x15c [ 1.288660] __device_attach_driver+0xb8/0x134 [ 1.293316] bus_for_each_drv+0x88/0xe8 [ 1.297337] __device_attach+0xa0/0x190 [ 1.301353] device_initial_probe+0x14/0x20 [ 1.305734] bus_probe_device+0xac/0xb0 [ 1.309752] device_add+0x5d0/0x790 [ 1.313408] __spi_add_device+0x134/0x204 [ 1.317606] of_register_spi_device+0x3b4/0x590 [ 1.322348] spi_register_controller+0x47c/0x754 [ 1.327181] devm_spi_register_controller+0x4c/0xa4 [ 1.332289] nxp_fspi_probe+0x1cc/0x2b0 [ 1.336307] platform_probe+0x68/0xc4 [ 1.340145] really_probe+0xbc/0x29c [ 1.343893] __driver_probe_device+0x78/0x12c [ 1.348457] driver_probe_device+0xd8/0x15c [ 1.352838] __driver_attach+0x90/0x19c [ 1.356857] bus_for_each_dev+0x7c/0xdc [ 1.360877] driver_attach+0x24/0x30 [ 1.364624] bus_add_driver+0xe4/0x208 [ 1.368552] driver_register+0x5c/0x124 [ 1.372573] __platform_driver_register+0x28/0x34 [ 1.377497] nxp_fspi_driver_init+0x1c/0x28 [ 1.381888] do_one_initcall+0x80/0x1c8 [ 1.385908] kernel_init_freeable+0x1c4/0x28c [ 1.390472] kernel_init+0x20/0x1d8 [ 1.394138] ret_from_fork+0x10/0x20 [ 1.397885] ---[ end trace 0000000000000000 ]--- [ 1.407908] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53052", "url": "https://ubuntu.com/security/CVE-2024-53052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/rw: fix missing NOWAIT check for O_DIRECT start write When io_uring starts a write, it'll call kiocb_start_write() to bump the super block rwsem, preventing any freezes from happening while that write is in-flight. The freeze side will grab that rwsem for writing, excluding any new writers from happening and waiting for existing writes to finish. But io_uring unconditionally uses kiocb_start_write(), which will block if someone is currently attempting to freeze the mount point. This causes a deadlock where freeze is waiting for previous writes to complete, but the previous writes cannot complete, as the task that is supposed to complete them is blocked waiting on starting a new write. This results in the following stuck trace showing that dependency with the write blocked starting a new write: task:fio state:D stack:0 pid:886 tgid:886 ppid:876 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_rwsem_wait+0x1e8/0x3f8 __percpu_down_read+0xe8/0x500 io_write+0xbb8/0xff8 io_issue_sqe+0x10c/0x1020 io_submit_sqes+0x614/0x2110 __arm64_sys_io_uring_enter+0x524/0x1038 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 INFO: task fsfreeze:7364 blocked for more than 15 seconds. Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963 with the attempting freezer stuck trying to grab the rwsem: task:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_down_write+0x2b0/0x680 freeze_super+0x248/0x8a8 do_vfs_ioctl+0x149c/0x1b18 __arm64_sys_ioctl+0xd0/0x1a0 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 Fix this by having the io_uring side honor IOCB_NOWAIT, and only attempt a blocking grab of the super block rwsem if it isn't set. For normal issue where IOCB_NOWAIT would always be set, this returns -EAGAIN which will have io_uring core issue a blocking attempt of the write. That will in turn also get completions run, ensuring forward progress. Since freezing requires CAP_SYS_ADMIN in the first place, this isn't something that can be triggered by a regular user.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50213", "url": "https://ubuntu.com/security/CVE-2024-50213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tests: hdmi: Fix memory leaks in drm_display_mode_from_cea_vic() modprobe drm_hdmi_state_helper_test and then rmmod it, the following memory leak occurs. The `mode` allocated in drm_mode_duplicate() called by drm_display_mode_from_cea_vic() is not freed, which cause the memory leak: \tunreferenced object 0xffffff80ccd18100 (size 128): \t comm \"kunit_try_catch\", pid 1851, jiffies 4295059695 \t hex dump (first 32 bytes): \t 57 62 00 00 80 02 90 02 f0 02 20 03 00 00 e0 01 Wb........ ..... \t ea 01 ec 01 0d 02 00 00 0a 00 00 00 00 00 00 00 ................ \t backtrace (crc c2f1aa95): \t [<000000000f10b11b>] kmemleak_alloc+0x34/0x40 \t [<000000001cd4cf73>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<00000000f1f3cffa>] drm_mode_duplicate+0x44/0x19c \t [<000000008cbeef13>] drm_display_mode_from_cea_vic+0x88/0x98 \t [<0000000019daaacf>] 0xffffffedc11ae69c \t [<000000000aad0f85>] kunit_try_run_case+0x13c/0x3ac \t [<00000000a9210bac>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<000000000a0b2e9e>] kthread+0x2e8/0x374 \t [<00000000bd668858>] ret_from_fork+0x10/0x20 \t...... Free `mode` by using drm_kunit_display_mode_from_cea_vic() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50214", "url": "https://ubuntu.com/security/CVE-2024-50214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/connector: hdmi: Fix memory leak in drm_display_mode_from_cea_vic() modprobe drm_connector_test and then rmmod drm_connector_test, the following memory leak occurs. The `mode` allocated in drm_mode_duplicate() called by drm_display_mode_from_cea_vic() is not freed, which cause the memory leak: \tunreferenced object 0xffffff80cb0ee400 (size 128): \t comm \"kunit_try_catch\", pid 1948, jiffies 4294950339 \t hex dump (first 32 bytes): \t 14 44 02 00 80 07 d8 07 04 08 98 08 00 00 38 04 .D............8. \t 3c 04 41 04 65 04 00 00 05 00 00 00 00 00 00 00 <.A.e........... \t backtrace (crc 90e9585c): \t [<00000000ec42e3d7>] kmemleak_alloc+0x34/0x40 \t [<00000000d0ef055a>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<00000000c2062161>] drm_mode_duplicate+0x44/0x19c \t [<00000000f96c74aa>] drm_display_mode_from_cea_vic+0x88/0x98 \t [<00000000d8f2c8b4>] 0xffffffdc982a4868 \t [<000000005d164dbc>] kunit_try_run_case+0x13c/0x3ac \t [<000000006fb23398>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<000000006ea56ca0>] kthread+0x2e8/0x374 \t [<000000000676063f>] ret_from_fork+0x10/0x20 \t...... Free `mode` by using drm_kunit_display_mode_from_cea_vic() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50215", "url": "https://ubuntu.com/security/CVE-2024-50215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: assign dh_key to NULL after kfree_sensitive ctrl->dh_key might be used across multiple calls to nvmet_setup_dhgroup() for the same controller. So it's better to nullify it after release on error path in order to avoid double free later in nvmet_destroy_auth(). Found by Linux Verification Center (linuxtesting.org) with Svace.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50216", "url": "https://ubuntu.com/security/CVE-2024-50216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix finding a last resort AG in xfs_filestream_pick_ag When the main loop in xfs_filestream_pick_ag fails to find a suitable AG it tries to just pick the online AG. But the loop for that uses args->pag as loop iterator while the later code expects pag to be set. Fix this by reusing the max_pag case for this last resort, and also add a check for impossible case of no AG just to make sure that the uninitialized pag doesn't even escape in theory.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50217", "url": "https://ubuntu.com/security/CVE-2024-50217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free of block device file in __btrfs_free_extra_devids() Mounting btrfs from two images (which have the same one fsid and two different dev_uuids) in certain executing order may trigger an UAF for variable 'device->bdev_file' in __btrfs_free_extra_devids(). And following are the details: 1. Attach image_1 to loop0, attach image_2 to loop1, and scan btrfs devices by ioctl(BTRFS_IOC_SCAN_DEV): / btrfs_device_1 ? loop0 fs_device \\ btrfs_device_2 ? loop1 2. mount /dev/loop0 /mnt btrfs_open_devices btrfs_device_1->bdev_file = btrfs_get_bdev_and_sb(loop0) btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree fail: btrfs_close_devices // -ENOMEM \t btrfs_close_bdev(btrfs_device_1) fput(btrfs_device_1->bdev_file) \t // btrfs_device_1->bdev_file is freed \t btrfs_close_bdev(btrfs_device_2) fput(btrfs_device_2->bdev_file) 3. mount /dev/loop1 /mnt btrfs_open_devices btrfs_get_bdev_and_sb(&bdev_file) // EIO, btrfs_device_1->bdev_file is not assigned, // which points to a freed memory area btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree btrfs_free_extra_devids if (btrfs_device_1->bdev_file) fput(btrfs_device_1->bdev_file) // UAF ! Fix it by setting 'device->bdev_file' as 'NULL' after closing the btrfs_device in btrfs_close_one_device().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53043", "url": "https://ubuntu.com/security/CVE-2024-53043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mctp i2c: handle NULL header address daddr can be NULL if there is no neighbour table entry present, in that case the tx packet should be dropped. saddr will usually be set by MCTP core, but check for NULL in case a packet is transmitted by a different protocol.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50303", "url": "https://ubuntu.com/security/CVE-2024-50303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: resource,kexec: walk_system_ram_res_rev must retain resource flags walk_system_ram_res_rev() erroneously discards resource flags when passing the information to the callback. This causes systems with IORESOURCE_SYSRAM_DRIVER_MANAGED memory to have these resources selected during kexec to store kexec buffers if that memory happens to be at placed above normal system ram. This leads to undefined behavior after reboot. If the kexec buffer is never touched, nothing happens. If the kexec buffer is touched, it could lead to a crash (like below) or undefined behavior. Tested on a system with CXL memory expanders with driver managed memory, TPM enabled, and CONFIG_IMA_KEXEC=y. Adding printk's showed the flags were being discarded and as a result the check for IORESOURCE_SYSRAM_DRIVER_MANAGED passes. find_next_iomem_res: name(System RAM (kmem)) \t\t start(10000000000) \t\t end(1034fffffff) \t\t flags(83000200) locate_mem_hole_top_down: start(10000000000) end(1034fffffff) flags(0) [.] BUG: unable to handle page fault for address: ffff89834ffff000 [.] #PF: supervisor read access in kernel mode [.] #PF: error_code(0x0000) - not-present page [.] PGD c04c8bf067 P4D c04c8bf067 PUD c04c8be067 PMD 0 [.] Oops: 0000 [#1] SMP [.] RIP: 0010:ima_restore_measurement_list+0x95/0x4b0 [.] RSP: 0018:ffffc900000d3a80 EFLAGS: 00010286 [.] RAX: 0000000000001000 RBX: 0000000000000000 RCX: ffff89834ffff000 [.] RDX: 0000000000000018 RSI: ffff89834ffff000 RDI: ffff89834ffff018 [.] RBP: ffffc900000d3ba0 R08: 0000000000000020 R09: ffff888132b8a900 [.] R10: 4000000000000000 R11: 000000003a616d69 R12: 0000000000000000 [.] R13: ffffffff8404ac28 R14: 0000000000000000 R15: ffff89834ffff000 [.] FS: 0000000000000000(0000) GS:ffff893d44640000(0000) knlGS:0000000000000000 [.] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [.] ata5: SATA link down (SStatus 0 SControl 300) [.] CR2: ffff89834ffff000 CR3: 000001034d00f001 CR4: 0000000000770ef0 [.] PKRU: 55555554 [.] Call Trace: [.] [.] ? __die+0x78/0xc0 [.] ? page_fault_oops+0x2a8/0x3a0 [.] ? exc_page_fault+0x84/0x130 [.] ? asm_exc_page_fault+0x22/0x30 [.] ? ima_restore_measurement_list+0x95/0x4b0 [.] ? template_desc_init_fields+0x317/0x410 [.] ? crypto_alloc_tfm_node+0x9c/0xc0 [.] ? init_ima_lsm+0x30/0x30 [.] ima_load_kexec_buffer+0x72/0xa0 [.] ima_init+0x44/0xa0 [.] __initstub__kmod_ima__373_1201_init_ima7+0x1e/0xb0 [.] ? init_ima_lsm+0x30/0x30 [.] do_one_initcall+0xad/0x200 [.] ? idr_alloc_cyclic+0xaa/0x110 [.] ? new_slab+0x12c/0x420 [.] ? new_slab+0x12c/0x420 [.] ? number+0x12a/0x430 [.] ? sysvec_apic_timer_interrupt+0xa/0x80 [.] ? asm_sysvec_apic_timer_interrupt+0x16/0x20 [.] ? parse_args+0xd4/0x380 [.] ? parse_args+0x14b/0x380 [.] kernel_init_freeable+0x1c1/0x2b0 [.] ? rest_init+0xb0/0xb0 [.] kernel_init+0x16/0x1a0 [.] ret_from_fork+0x2f/0x40 [.] ? rest_init+0xb0/0xb0 [.] ret_from_fork_asm+0x11/0x20 [.] ", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50218", "url": "https://ubuntu.com/security/CVE-2024-50218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow Syzbot reported a kernel BUG in ocfs2_truncate_inline. There are two reasons for this: first, the parameter value passed is greater than ocfs2_max_inline_data_with_xattr, second, the start and end parameters of ocfs2_truncate_inline are \"unsigned int\". So, we need to add a sanity check for byte_start and byte_len right before ocfs2_truncate_inline() in ocfs2_remove_inode_range(), if they are greater than ocfs2_max_inline_data_with_xattr return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50219", "url": "https://ubuntu.com/security/CVE-2024-50219", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50263", "url": "https://ubuntu.com/security/CVE-2024-50263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fork: only invoke khugepaged, ksm hooks if no error There is no reason to invoke these hooks early against an mm that is in an incomplete state. The change in commit d24062914837 (\"fork: use __mt_dup() to duplicate maple tree in dup_mmap()\") makes this more pertinent as we may be in a state where entries in the maple tree are not yet consistent. Their placement early in dup_mmap() only appears to have been meaningful for early error checking, and since functionally it'd require a very small allocation to fail (in practice 'too small to fail') that'd only occur in the most dire circumstances, meaning the fork would fail or be OOM'd in any case. Since both khugepaged and KSM tracking are there to provide optimisations to memory performance rather than critical functionality, it doesn't really matter all that much if, under such dire memory pressure, we fail to register an mm with these. As a result, we follow the example of commit d2081b2bf819 (\"mm: khugepaged: make khugepaged_enter() void function\") and make ksm_fork() a void function also. We only expose the mm to these functions once we are done with them and only if no error occurred in the fork operation.", "cve_priority": "medium", "cve_public_date": "2024-11-11 14:15:00 UTC" }, { "cve": "CVE-2024-50220", "url": "https://ubuntu.com/security/CVE-2024-50220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fork: do not invoke uffd on fork if error occurs Patch series \"fork: do not expose incomplete mm on fork\". During fork we may place the virtual memory address space into an inconsistent state before the fork operation is complete. In addition, we may encounter an error during the fork operation that indicates that the virtual memory address space is invalidated. As a result, we should not be exposing it in any way to external machinery that might interact with the mm or VMAs, machinery that is not designed to deal with incomplete state. We specifically update the fork logic to defer khugepaged and ksm to the end of the operation and only to be invoked if no error arose, and disallow uffd from observing fork events should an error have occurred. This patch (of 2): Currently on fork we expose the virtual address space of a process to userland unconditionally if uffd is registered in VMAs, regardless of whether an error arose in the fork. This is performed in dup_userfaultfd_complete() which is invoked unconditionally, and performs two duties - invoking registered handlers for the UFFD_EVENT_FORK event via dup_fctx(), and clearing down userfaultfd_fork_ctx objects established in dup_userfaultfd(). This is problematic, because the virtual address space may not yet be correctly initialised if an error arose. The change in commit d24062914837 (\"fork: use __mt_dup() to duplicate maple tree in dup_mmap()\") makes this more pertinent as we may be in a state where entries in the maple tree are not yet consistent. We address this by, on fork error, ensuring that we roll back state that we would otherwise expect to clean up through the event being handled by userland and perform the memory freeing duty otherwise performed by dup_userfaultfd_complete(). We do this by implementing a new function, dup_userfaultfd_fail(), which performs the same loop, only decrementing reference counts. Note that we perform mmgrab() on the parent and child mm's, however userfaultfd_ctx_put() will mmdrop() this once the reference count drops to zero, so we will avoid memory leaks correctly here.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53047", "url": "https://ubuntu.com/security/CVE-2024-53047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: init: protect sched with rcu_read_lock Enabling CONFIG_PROVE_RCU_LIST with its dependence CONFIG_RCU_EXPERT creates this splat when an MPTCP socket is created: ============================= WARNING: suspicious RCU usage 6.12.0-rc2+ #11 Not tainted ----------------------------- net/mptcp/sched.c:44 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 no locks held by mptcp_connect/176. stack backtrace: CPU: 0 UID: 0 PID: 176 Comm: mptcp_connect Not tainted 6.12.0-rc2+ #11 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl (lib/dump_stack.c:123) lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822) mptcp_sched_find (net/mptcp/sched.c:44 (discriminator 7)) mptcp_init_sock (net/mptcp/protocol.c:2867 (discriminator 1)) ? sock_init_data_uid (arch/x86/include/asm/atomic.h:28) inet_create.part.0.constprop.0 (net/ipv4/af_inet.c:386) ? __sock_create (include/linux/rcupdate.h:347 (discriminator 1)) __sock_create (net/socket.c:1576) __sys_socket (net/socket.c:1671) ? __pfx___sys_socket (net/socket.c:1712) ? do_user_addr_fault (arch/x86/mm/fault.c:1419 (discriminator 1)) __x64_sys_socket (net/socket.c:1728) do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) That's because when the socket is initialised, rcu_read_lock() is not used despite the explicit comment written above the declaration of mptcp_sched_find() in sched.c. Adding the missing lock/unlock avoids the warning.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50221", "url": "https://ubuntu.com/security/CVE-2024-50221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Vangogh: Fix kernel memory out of bounds write KASAN reports that the GPU metrics table allocated in vangogh_tables_init() is not large enough for the memset done in smu_cmn_init_soft_gpu_metrics(). Condensed report follows: [ 33.861314] BUG: KASAN: slab-out-of-bounds in smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu] [ 33.861799] Write of size 168 at addr ffff888129f59500 by task mangoapp/1067 ... [ 33.861808] CPU: 6 UID: 1000 PID: 1067 Comm: mangoapp Tainted: G W 6.12.0-rc4 #356 1a56f59a8b5182eeaf67eb7cb8b13594dd23b544 [ 33.861816] Tainted: [W]=WARN [ 33.861818] Hardware name: Valve Galileo/Galileo, BIOS F7G0107 12/01/2023 [ 33.861822] Call Trace: [ 33.861826] [ 33.861829] dump_stack_lvl+0x66/0x90 [ 33.861838] print_report+0xce/0x620 [ 33.861853] kasan_report+0xda/0x110 [ 33.862794] kasan_check_range+0xfd/0x1a0 [ 33.862799] __asan_memset+0x23/0x40 [ 33.862803] smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.863306] vangogh_get_gpu_metrics_v2_4+0x123/0xad0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.864257] vangogh_common_get_gpu_metrics+0xb0c/0xbc0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.865682] amdgpu_dpm_get_gpu_metrics+0xcc/0x110 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.866160] amdgpu_get_gpu_metrics+0x154/0x2d0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.867135] dev_attr_show+0x43/0xc0 [ 33.867147] sysfs_kf_seq_show+0x1f1/0x3b0 [ 33.867155] seq_read_iter+0x3f8/0x1140 [ 33.867173] vfs_read+0x76c/0xc50 [ 33.867198] ksys_read+0xfb/0x1d0 [ 33.867214] do_syscall_64+0x90/0x160 ... [ 33.867353] Allocated by task 378 on cpu 7 at 22.794876s: [ 33.867358] kasan_save_stack+0x33/0x50 [ 33.867364] kasan_save_track+0x17/0x60 [ 33.867367] __kasan_kmalloc+0x87/0x90 [ 33.867371] vangogh_init_smc_tables+0x3f9/0x840 [amdgpu] [ 33.867835] smu_sw_init+0xa32/0x1850 [amdgpu] [ 33.868299] amdgpu_device_init+0x467b/0x8d90 [amdgpu] [ 33.868733] amdgpu_driver_load_kms+0x19/0xf0 [amdgpu] [ 33.869167] amdgpu_pci_probe+0x2d6/0xcd0 [amdgpu] [ 33.869608] local_pci_probe+0xda/0x180 [ 33.869614] pci_device_probe+0x43f/0x6b0 Empirically we can confirm that the former allocates 152 bytes for the table, while the latter memsets the 168 large block. Root cause appears that when GPU metrics tables for v2_4 parts were added it was not considered to enlarge the table to fit. The fix in this patch is rather \"brute force\" and perhaps later should be done in a smarter way, by extracting and consolidating the part version to size logic to a common helper, instead of brute forcing the largest possible allocation. Nevertheless, for now this works and fixes the out of bounds write. v2: * Drop impossible v3_0 case. (Mario) (cherry picked from commit 0880f58f9609f0200483a49429af0f050d281703)", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50222", "url": "https://ubuntu.com/security/CVE-2024-50222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iov_iter: fix copy_page_from_iter_atomic() if KMAP_LOCAL_FORCE_MAP generic/077 on x86_32 CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP=y with highmem, on huge=always tmpfs, issues a warning and then hangs (interruptibly): WARNING: CPU: 5 PID: 3517 at mm/highmem.c:622 kunmap_local_indexed+0x62/0xc9 CPU: 5 UID: 0 PID: 3517 Comm: cp Not tainted 6.12.0-rc4 #2 ... copy_page_from_iter_atomic+0xa6/0x5ec generic_perform_write+0xf6/0x1b4 shmem_file_write_iter+0x54/0x67 Fix copy_page_from_iter_atomic() by limiting it in that case (include/linux/skbuff.h skb_frag_must_loop() does similar). But going forward, perhaps CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP is too surprising, has outlived its usefulness, and should just be removed?", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50223", "url": "https://ubuntu.com/security/CVE-2024-50223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/numa: Fix the potential null pointer dereference in task_numa_work() When running stress-ng-vm-segv test, we found a null pointer dereference error in task_numa_work(). Here is the backtrace: [323676.066985] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ...... [323676.067108] CPU: 35 PID: 2694524 Comm: stress-ng-vm-se ...... [323676.067113] pstate: 23401009 (nzCv daif +PAN -UAO +TCO +DIT +SSBS BTYPE=--) [323676.067115] pc : vma_migratable+0x1c/0xd0 [323676.067122] lr : task_numa_work+0x1ec/0x4e0 [323676.067127] sp : ffff8000ada73d20 [323676.067128] x29: ffff8000ada73d20 x28: 0000000000000000 x27: 000000003e89f010 [323676.067130] x26: 0000000000080000 x25: ffff800081b5c0d8 x24: ffff800081b27000 [323676.067133] x23: 0000000000010000 x22: 0000000104d18cc0 x21: ffff0009f7158000 [323676.067135] x20: 0000000000000000 x19: 0000000000000000 x18: ffff8000ada73db8 [323676.067138] x17: 0001400000000000 x16: ffff800080df40b0 x15: 0000000000000035 [323676.067140] x14: ffff8000ada73cc8 x13: 1fffe0017cc72001 x12: ffff8000ada73cc8 [323676.067142] x11: ffff80008001160c x10: ffff000be639000c x9 : ffff8000800f4ba4 [323676.067145] x8 : ffff000810375000 x7 : ffff8000ada73974 x6 : 0000000000000001 [323676.067147] x5 : 0068000b33e26707 x4 : 0000000000000001 x3 : ffff0009f7158000 [323676.067149] x2 : 0000000000000041 x1 : 0000000000004400 x0 : 0000000000000000 [323676.067152] Call trace: [323676.067153] vma_migratable+0x1c/0xd0 [323676.067155] task_numa_work+0x1ec/0x4e0 [323676.067157] task_work_run+0x78/0xd8 [323676.067161] do_notify_resume+0x1ec/0x290 [323676.067163] el0_svc+0x150/0x160 [323676.067167] el0t_64_sync_handler+0xf8/0x128 [323676.067170] el0t_64_sync+0x17c/0x180 [323676.067173] Code: d2888001 910003fd f9000bf3 aa0003f3 (f9401000) [323676.067177] SMP: stopping secondary CPUs [323676.070184] Starting crashdump kernel... stress-ng-vm-segv in stress-ng is used to stress test the SIGSEGV error handling function of the system, which tries to cause a SIGSEGV error on return from unmapping the whole address space of the child process. Normally this program will not cause kernel crashes. But before the munmap system call returns to user mode, a potential task_numa_work() for numa balancing could be added and executed. In this scenario, since the child process has no vma after munmap, the vma_next() in task_numa_work() will return a null pointer even if the vma iterator restarts from 0. Recheck the vma pointer before dereferencing it in task_numa_work().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53053", "url": "https://ubuntu.com/security/CVE-2024-53053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Fix another deadlock during RTC update If ufshcd_rtc_work calls ufshcd_rpm_put_sync() and the pm's usage_count is 0, we will enter the runtime suspend callback. However, the runtime suspend callback will wait to flush ufshcd_rtc_work, causing a deadlock. Replace ufshcd_rpm_put_sync() with ufshcd_rpm_put() to avoid the deadlock.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53075", "url": "https://ubuntu.com/security/CVE-2024-53075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv: Prevent a bad reference count on CPU nodes When populating cache leaves we previously fetched the CPU device node at the very beginning. But when ACPI is enabled we go through a specific branch which returns early and does not call 'of_node_put' for the node that was acquired. Since we are not using a CPU device node for the ACPI code anyways, we can simply move the initialization of it just passed the ACPI block, and we are guaranteed to have an 'of_node_put' call for the acquired node. This prevents a bad reference count of the CPU device node. Moreover, the previous function did not check for errors when acquiring the device node, so a return -ENOENT has been added for that case.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50224", "url": "https://ubuntu.com/security/CVE-2024-50224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: spi-fsl-dspi: Fix crash when not using GPIO chip select Add check for the return value of spi_get_csgpiod() to avoid passing a NULL pointer to gpiod_direction_output(), preventing a crash when GPIO chip select is not used. Fix below crash: [ 4.251960] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 4.260762] Mem abort info: [ 4.263556] ESR = 0x0000000096000004 [ 4.267308] EC = 0x25: DABT (current EL), IL = 32 bits [ 4.272624] SET = 0, FnV = 0 [ 4.275681] EA = 0, S1PTW = 0 [ 4.278822] FSC = 0x04: level 0 translation fault [ 4.283704] Data abort info: [ 4.286583] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 4.292074] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 4.297130] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 4.302445] [0000000000000000] user address but active_mm is swapper [ 4.308805] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 4.315072] Modules linked in: [ 4.318124] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc4-next-20241023-00008-ga20ec42c5fc1 #359 [ 4.328130] Hardware name: LS1046A QDS Board (DT) [ 4.332832] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 4.339794] pc : gpiod_direction_output+0x34/0x5c [ 4.344505] lr : gpiod_direction_output+0x18/0x5c [ 4.349208] sp : ffff80008003b8f0 [ 4.352517] x29: ffff80008003b8f0 x28: 0000000000000000 x27: ffffc96bcc7e9068 [ 4.359659] x26: ffffc96bcc6e00b0 x25: ffffc96bcc598398 x24: ffff447400132810 [ 4.366800] x23: 0000000000000000 x22: 0000000011e1a300 x21: 0000000000020002 [ 4.373940] x20: 0000000000000000 x19: 0000000000000000 x18: ffffffffffffffff [ 4.381081] x17: ffff44740016e600 x16: 0000000500000003 x15: 0000000000000007 [ 4.388221] x14: 0000000000989680 x13: 0000000000020000 x12: 000000000000001e [ 4.395362] x11: 0044b82fa09b5a53 x10: 0000000000000019 x9 : 0000000000000008 [ 4.402502] x8 : 0000000000000002 x7 : 0000000000000007 x6 : 0000000000000000 [ 4.409641] x5 : 0000000000000200 x4 : 0000000002000000 x3 : 0000000000000000 [ 4.416781] x2 : 0000000000022202 x1 : 0000000000000000 x0 : 0000000000000000 [ 4.423921] Call trace: [ 4.426362] gpiod_direction_output+0x34/0x5c (P) [ 4.431067] gpiod_direction_output+0x18/0x5c (L) [ 4.435771] dspi_setup+0x220/0x334", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50225", "url": "https://ubuntu.com/security/CVE-2024-50225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix error propagation of split bios The purpose of btrfs_bbio_propagate_error() shall be propagating an error of split bio to its original btrfs_bio, and tell the error to the upper layer. However, it's not working well on some cases. * Case 1. Immediate (or quick) end_bio with an error When btrfs sends btrfs_bio to mirrored devices, btrfs calls btrfs_bio_end_io() when all the mirroring bios are completed. If that btrfs_bio was split, it is from btrfs_clone_bioset and its end_io function is btrfs_orig_write_end_io. For this case, btrfs_bbio_propagate_error() accesses the orig_bbio's bio context to increase the error count. That works well in most cases. However, if the end_io is called enough fast, orig_bbio's (remaining part after split) bio context may not be properly set at that time. Since the bio context is set when the orig_bbio (the last btrfs_bio) is sent to devices, that might be too late for earlier split btrfs_bio's completion. That will result in NULL pointer dereference. That bug is easily reproducible by running btrfs/146 on zoned devices [1] and it shows the following trace. [1] You need raid-stripe-tree feature as it create \"-d raid0 -m raid1\" FS. BUG: kernel NULL pointer dereference, address: 0000000000000020 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 UID: 0 PID: 13 Comm: kworker/u32:1 Not tainted 6.11.0-rc7-BTRFS-ZNS+ #474 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Workqueue: writeback wb_workfn (flush-btrfs-5) RIP: 0010:btrfs_bio_end_io+0xae/0xc0 [btrfs] BTRFS error (device dm-0): bdev /dev/mapper/error-test errs: wr 2, rd 0, flush 0, corrupt 0, gen 0 RSP: 0018:ffffc9000006f248 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888005a7f080 RCX: ffffc9000006f1dc RDX: 0000000000000000 RSI: 000000000000000a RDI: ffff888005a7f080 RBP: ffff888011dfc540 R08: 0000000000000000 R09: 0000000000000001 R10: ffffffff82e508e0 R11: 0000000000000005 R12: ffff88800ddfbe58 R13: ffff888005a7f080 R14: ffff888005a7f158 R15: ffff888005a7f158 FS: 0000000000000000(0000) GS:ffff88803ea80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000020 CR3: 0000000002e22006 CR4: 0000000000370ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __die_body.cold+0x19/0x26 ? page_fault_oops+0x13e/0x2b0 ? _printk+0x58/0x73 ? do_user_addr_fault+0x5f/0x750 ? exc_page_fault+0x76/0x240 ? asm_exc_page_fault+0x22/0x30 ? btrfs_bio_end_io+0xae/0xc0 [btrfs] ? btrfs_log_dev_io_error+0x7f/0x90 [btrfs] btrfs_orig_write_end_io+0x51/0x90 [btrfs] dm_submit_bio+0x5c2/0xa50 [dm_mod] ? find_held_lock+0x2b/0x80 ? blk_try_enter_queue+0x90/0x1e0 __submit_bio+0xe0/0x130 ? ktime_get+0x10a/0x160 ? lockdep_hardirqs_on+0x74/0x100 submit_bio_noacct_nocheck+0x199/0x410 btrfs_submit_bio+0x7d/0x150 [btrfs] btrfs_submit_chunk+0x1a1/0x6d0 [btrfs] ? lockdep_hardirqs_on+0x74/0x100 ? __folio_start_writeback+0x10/0x2c0 btrfs_submit_bbio+0x1c/0x40 [btrfs] submit_one_bio+0x44/0x60 [btrfs] submit_extent_folio+0x13f/0x330 [btrfs] ? btrfs_set_range_writeback+0xa3/0xd0 [btrfs] extent_writepage_io+0x18b/0x360 [btrfs] extent_write_locked_range+0x17c/0x340 [btrfs] ? __pfx_end_bbio_data_write+0x10/0x10 [btrfs] run_delalloc_cow+0x71/0xd0 [btrfs] btrfs_run_delalloc_range+0x176/0x500 [btrfs] ? find_lock_delalloc_range+0x119/0x260 [btrfs] writepage_delalloc+0x2ab/0x480 [btrfs] extent_write_cache_pages+0x236/0x7d0 [btrfs] btrfs_writepages+0x72/0x130 [btrfs] do_writepages+0xd4/0x240 ? find_held_lock+0x2b/0x80 ? wbc_attach_and_unlock_inode+0x12c/0x290 ? wbc_attach_and_unlock_inode+0x12c/0x29 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53054", "url": "https://ubuntu.com/security/CVE-2024-53054", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50226", "url": "https://ubuntu.com/security/CVE-2024-50226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cxl/port: Fix use-after-free, permit out-of-order decoder shutdown In support of investigating an initialization failure report [1], cxl_test was updated to register mock memory-devices after the mock root-port/bus device had been registered. That led to cxl_test crashing with a use-after-free bug with the following signature: cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem0:decoder7.0 @ 0 next: cxl_switch_uport.0 nr_eps: 1 nr_targets: 1 cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem4:decoder14.0 @ 1 next: cxl_switch_uport.0 nr_eps: 2 nr_targets: 1 cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[0] = cxl_switch_dport.0 for mem0:decoder7.0 @ 0 1) cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[1] = cxl_switch_dport.4 for mem4:decoder14.0 @ 1 [..] cxld_unregister: cxl decoder14.0: cxl_region_decode_reset: cxl_region region3: mock_decoder_reset: cxl_port port3: decoder3.0 reset 2) mock_decoder_reset: cxl_port port3: decoder3.0: out of order reset, expected decoder3.1 cxl_endpoint_decoder_release: cxl decoder14.0: [..] cxld_unregister: cxl decoder7.0: 3) cxl_region_decode_reset: cxl_region region3: Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6bc3: 0000 [#1] PREEMPT SMP PTI [..] RIP: 0010:to_cxl_port+0x8/0x60 [cxl_core] [..] Call Trace: cxl_region_decode_reset+0x69/0x190 [cxl_core] cxl_region_detach+0xe8/0x210 [cxl_core] cxl_decoder_kill_region+0x27/0x40 [cxl_core] cxld_unregister+0x5d/0x60 [cxl_core] At 1) a region has been established with 2 endpoint decoders (7.0 and 14.0). Those endpoints share a common switch-decoder in the topology (3.0). At teardown, 2), decoder14.0 is the first to be removed and hits the \"out of order reset case\" in the switch decoder. The effect though is that region3 cleanup is aborted leaving it in-tact and referencing decoder14.0. At 3) the second attempt to teardown region3 trips over the stale decoder14.0 object which has long since been deleted. The fix here is to recognize that the CXL specification places no mandate on in-order shutdown of switch-decoders, the driver enforces in-order allocation, and hardware enforces in-order commit. So, rather than fail and leave objects dangling, always remove them. In support of making cxl_region_decode_reset() always succeed, cxl_region_invalidate_memregion() failures are turned into warnings. Crashing the kernel is ok there since system integrity is at risk if caches cannot be managed around physical address mutation events like CXL region destruction. A new device_for_each_child_reverse_from() is added to cleanup port->commit_end after all dependent decoders have been disabled. In other words if decoders are allocated 0->1->2 and disabled 1->2->0 then port->commit_end only decrements from 2 after 2 has been disabled, and it decrements all the way to zero since 1 was disabled previously.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50227", "url": "https://ubuntu.com/security/CVE-2024-50227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Fix KASAN reported stack out-of-bounds read in tb_retimer_scan() KASAN reported following issue: BUG: KASAN: stack-out-of-bounds in tb_retimer_scan+0xffe/0x1550 [thunderbolt] Read of size 4 at addr ffff88810111fc1c by task kworker/u56:0/11 CPU: 0 UID: 0 PID: 11 Comm: kworker/u56:0 Tainted: G U 6.11.0+ #1387 Tainted: [U]=USER Workqueue: thunderbolt0 tb_handle_hotplug [thunderbolt] Call Trace: dump_stack_lvl+0x6c/0x90 print_report+0xd1/0x630 kasan_report+0xdb/0x110 __asan_report_load4_noabort+0x14/0x20 tb_retimer_scan+0xffe/0x1550 [thunderbolt] tb_scan_port+0xa6f/0x2060 [thunderbolt] tb_handle_hotplug+0x17b1/0x3080 [thunderbolt] process_one_work+0x626/0x1100 worker_thread+0x6c8/0xfa0 kthread+0x2c8/0x3a0 ret_from_fork+0x3a/0x80 ret_from_fork_asm+0x1a/0x30 This happens because the loop variable still gets incremented by one so max becomes 3 instead of 2, and this makes the second loop read past the the array declared on the stack. Fix this by assigning to max directly in the loop body.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50228", "url": "https://ubuntu.com/security/CVE-2024-50228", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50229", "url": "https://ubuntu.com/security/CVE-2024-50229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential deadlock with newly created symlinks Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers memory reclamation involving the filesystem layer, which can result in circular lock dependencies among the reader/writer semaphore nilfs->ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the fs_reclaim pseudo lock. This is because after commit 21fc61c73c39 (\"don't put symlink bodies in pagecache into highmem\"), the gfp flags of the page cache for symbolic links are overwritten to GFP_KERNEL via inode_nohighmem(). This is not a problem for symlinks read from the backing device, because the __GFP_FS flag is dropped after inode_nohighmem() is called. However, when a new symlink is created with nilfs_symlink(), the gfp flags remain overwritten to GFP_KERNEL. Then, memory allocation called from page_symlink() etc. triggers memory reclamation including the FS layer, which may call nilfs_evict_inode() or nilfs_dirty_inode(). And these can cause a deadlock if they are called while nilfs->ns_segctor_sem is held: Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags of newly created symlinks in the same way that nilfs_new_inode() and __nilfs_read_inode() do, as a workaround until we adopt nofs allocation scope consistently or improve the locking constraints.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50230", "url": "https://ubuntu.com/security/CVE-2024-50230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug due to missing clearing of checked flag Syzbot reported that in directory operations after nilfs2 detects filesystem corruption and degrades to read-only, __block_write_begin_int(), which is called to prepare block writes, may fail the BUG_ON check for accesses exceeding the folio/page size, triggering a kernel bug. This was found to be because the \"checked\" flag of a page/folio was not cleared when it was discarded by nilfs2's own routine, which causes the sanity check of directory entries to be skipped when the directory page/folio is reloaded. So, fix that. This was necessary when the use of nilfs2's own page discard routine was applied to more than just metadata files.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50231", "url": "https://ubuntu.com/security/CVE-2024-50231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gts-helper: Fix memory leaks in iio_gts_build_avail_scale_table() modprobe iio-test-gts and rmmod it, then the following memory leak occurs: \tunreferenced object 0xffffff80c810be00 (size 64): \t comm \"kunit_try_catch\", pid 1654, jiffies 4294913981 \t hex dump (first 32 bytes): \t 02 00 00 00 08 00 00 00 20 00 00 00 40 00 00 00 ........ ...@... \t 80 00 00 00 00 02 00 00 00 04 00 00 00 08 00 00 ................ \t backtrace (crc a63d875e): \t [<0000000028c1b3c2>] kmemleak_alloc+0x34/0x40 \t [<000000001d6ecc87>] __kmalloc_noprof+0x2bc/0x3c0 \t [<00000000393795c1>] devm_iio_init_iio_gts+0x4b4/0x16f4 \t [<0000000071bb4b09>] 0xffffffdf052a62e0 \t [<000000000315bc18>] 0xffffffdf052a6488 \t [<00000000f9dc55b5>] kunit_try_run_case+0x13c/0x3ac \t [<00000000175a3fd4>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000f505065d>] kthread+0x2e8/0x374 \t [<00000000bbfb0e5d>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cbfe9e70 (size 16): \t comm \"kunit_try_catch\", pid 1658, jiffies 4294914015 \t hex dump (first 16 bytes): \t 10 00 00 00 40 00 00 00 80 00 00 00 00 00 00 00 ....@........... \t backtrace (crc 857f0cb4): \t [<0000000028c1b3c2>] kmemleak_alloc+0x34/0x40 \t [<000000001d6ecc87>] __kmalloc_noprof+0x2bc/0x3c0 \t [<00000000393795c1>] devm_iio_init_iio_gts+0x4b4/0x16f4 \t [<0000000071bb4b09>] 0xffffffdf052a62e0 \t [<000000007d089d45>] 0xffffffdf052a6864 \t [<00000000f9dc55b5>] kunit_try_run_case+0x13c/0x3ac \t [<00000000175a3fd4>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000f505065d>] kthread+0x2e8/0x374 \t [<00000000bbfb0e5d>] ret_from_fork+0x10/0x20 \t...... It includes 5*5 times \"size 64\" memory leaks, which correspond to 5 times test_init_iio_gain_scale() calls with gts_test_gains size 10 (10*size(int)) and gts_test_itimes size 5. It also includes 5*1 times \"size 16\" memory leak, which correspond to one time __test_init_iio_gain_scale() call with gts_test_gains_gain_low size 3 (3*size(int)) and gts_test_itimes size 5. The reason is that the per_time_gains[i] is not freed which is allocated in the \"gts->num_itime\" for loop in iio_gts_build_avail_scale_table().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53076", "url": "https://ubuntu.com/security/CVE-2024-53076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gts-helper: Fix memory leaks for the error path of iio_gts_build_avail_scale_table() If per_time_scales[i] or per_time_gains[i] kcalloc fails in the for loop of iio_gts_build_avail_scale_table(), the err_free_out will fail to call kfree() each time when i is reduced to 0, so all the per_time_scales[0] and per_time_gains[0] will not be freed, which will cause memory leaks. Fix it by checking if i >= 0.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50232", "url": "https://ubuntu.com/security/CVE-2024-50232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr() In the ad7124_write_raw() function, parameter val can potentially be zero. This may lead to a division by zero when DIV_ROUND_CLOSEST() is called within ad7124_set_channel_odr(). The ad7124_write_raw() function is invoked through the sequence: iio_write_channel_raw() -> iio_write_channel_attribute() -> iio_channel_write(), with no checks in place to ensure val is non-zero.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50233", "url": "https://ubuntu.com/security/CVE-2024-50233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: iio: frequency: ad9832: fix division by zero in ad9832_calc_freqreg() In the ad9832_write_frequency() function, clk_get_rate() might return 0. This can lead to a division by zero when calling ad9832_calc_freqreg(). The check if (fout > (clk_get_rate(st->mclk) / 2)) does not protect against the case when fout is 0. The ad9832_write_frequency() function is called from ad9832_write(), and fout is derived from a text buffer, which can contain any value.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53055", "url": "https://ubuntu.com/security/CVE-2024-53055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix 6 GHz scan construction If more than 255 colocated APs exist for the set of all APs found during 2.4/5 GHz scanning, then the 6 GHz scan construction will loop forever since the loop variable has type u8, which can never reach the number found when that's bigger than 255, and is stored in a u32 variable. Also move it into the loops to have a smaller scope. Using a u32 there is fine, we limit the number of APs in the scan list and each has a limit on the number of RNR entries due to the frame size. With a limit of 1000 scan results, a frame size upper bound of 4096 (really it's more like ~2300) and a TBTT entry size of at least 11, we get an upper bound for the number of ~372k, well in the bounds of a u32.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50234", "url": "https://ubuntu.com/security/CVE-2024-50234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlegacy: Clear stale interrupts before resuming device iwl4965 fails upon resume from hibernation on my laptop. The reason seems to be a stale interrupt which isn't being cleared out before interrupts are enabled. We end up with a race beween the resume trying to bring things back up, and the restart work (queued form the interrupt handler) trying to bring things down. Eventually the whole thing blows up. Fix the problem by clearing out any stale interrupts before interrupts get enabled during resume. Here's a debug log of the indicent: [ 12.042589] ieee80211 phy0: il_isr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000 [ 12.042625] ieee80211 phy0: il4965_irq_tasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000 [ 12.042651] iwl4965 0000:10:00.0: RF_KILL bit toggled to enable radio. [ 12.042653] iwl4965 0000:10:00.0: On demand firmware reload [ 12.042690] ieee80211 phy0: il4965_irq_tasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282 [ 12.052207] ieee80211 phy0: il4965_mac_start enter [ 12.052212] ieee80211 phy0: il_prep_station Add STA to driver ID 31: ff:ff:ff:ff:ff:ff [ 12.052244] ieee80211 phy0: il4965_set_hw_ready hardware ready [ 12.052324] ieee80211 phy0: il_apm_init Init card's basic functions [ 12.052348] ieee80211 phy0: il_apm_init L1 Enabled; Disabling L0S [ 12.055727] ieee80211 phy0: il4965_load_bsm Begin load bsm [ 12.056140] ieee80211 phy0: il4965_verify_bsm Begin verify bsm [ 12.058642] ieee80211 phy0: il4965_verify_bsm BSM bootstrap uCode image OK [ 12.058721] ieee80211 phy0: il4965_load_bsm BSM write complete, poll 1 iterations [ 12.058734] ieee80211 phy0: __il4965_up iwl4965 is coming up [ 12.058737] ieee80211 phy0: il4965_mac_start Start UP work done. [ 12.058757] ieee80211 phy0: __il4965_down iwl4965 is going down [ 12.058761] ieee80211 phy0: il_scan_cancel_timeout Scan cancel timeout [ 12.058762] ieee80211 phy0: il_do_scan_abort Not performing scan to abort [ 12.058765] ieee80211 phy0: il_clear_ucode_stations Clearing ucode stations in driver [ 12.058767] ieee80211 phy0: il_clear_ucode_stations No active stations found to be cleared [ 12.058819] ieee80211 phy0: _il_apm_stop Stop card, put in low power state [ 12.058827] ieee80211 phy0: _il_apm_stop_master stop master [ 12.058864] ieee80211 phy0: il4965_clear_free_frames 0 frames on pre-allocated heap on clear. [ 12.058869] ieee80211 phy0: Hardware restart was requested [ 16.132299] iwl4965 0000:10:00.0: START_ALIVE timeout after 4000ms. [ 16.132303] ------------[ cut here ]------------ [ 16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue. [ 16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132390] Modules linked in: ctr ccm sch_fq_codel xt_tcpudp xt_multiport xt_state iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables binfmt_misc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdh_generic ecc iTCO_wdt i2c_dev iwl4965 iwlegacy coretemp snd_hda_codec_analog pcspkr psmouse mac80211 snd_hda_codec_generic libarc4 sdhci_pci cqhci sha256_generic sdhci libsha256 firewire_ohci snd_hda_intel snd_intel_dspcfg mmc_core snd_hda_codec snd_hwdep firewire_core led_class iosf_mbi snd_hda_core uhci_hcd lpc_ich crc_itu_t cfg80211 ehci_pci ehci_hcd snd_pcm usbcore mfd_core rfkill snd_timer snd usb_common soundcore video parport_pc parport intel_agp wmi intel_gtt backlight e1000e agpgart evdev [ 16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143 [ 16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010 [ 16.132463] Workqueue: async async_run_entry_fn [ 16.132469] RIP: 0010:ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132501] Code: da 02 00 0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50235", "url": "https://ubuntu.com/security/CVE-2024-50235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: clear wdev->cqm_config pointer on free When we free wdev->cqm_config when unregistering, we also need to clear out the pointer since the same wdev/netdev may get re-registered in another network namespace, then destroyed later, running this code again, which results in a double-free.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50236", "url": "https://ubuntu.com/security/CVE-2024-50236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: Fix memory leak in management tx In the current logic, memory is allocated for storing the MSDU context during management packet TX but this memory is not being freed during management TX completion. Similar leaks are seen in the management TX cleanup logic. Kmemleak reports this problem as below, unreferenced object 0xffffff80b64ed250 (size 16): comm \"kworker/u16:7\", pid 148, jiffies 4294687130 (age 714.199s) hex dump (first 16 bytes): 00 2b d8 d8 80 ff ff ff c4 74 e9 fd 07 00 00 00 .+.......t...... backtrace: [] __kmem_cache_alloc_node+0x1e4/0x2d8 [] kmalloc_trace+0x48/0x110 [] ath10k_wmi_tlv_op_gen_mgmt_tx_send+0xd4/0x1d8 [ath10k_core] [] ath10k_mgmt_over_wmi_tx_work+0x134/0x298 [ath10k_core] [] process_scheduled_works+0x1ac/0x400 [] worker_thread+0x208/0x328 [] kthread+0x100/0x1c0 [] ret_from_fork+0x10/0x20 Free the memory during completion and cleanup to fix the leak. Protect the mgmt_pending_tx idr_remove() operation in ath10k_wmi_tlv_op_cleanup_mgmt_tx_send() using ar->data_lock similar to other instances. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50237", "url": "https://ubuntu.com/security/CVE-2024-50237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower Avoid potentially crashing in the driver because of uninitialized private data", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50238", "url": "https://ubuntu.com/security/CVE-2024-50238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usbc: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data from the qcom-qmp-usb driver, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. This bug was later reproduced when the driver was copied to create the qmp-usbc driver. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with these drivers.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50239", "url": "https://ubuntu.com/security/CVE-2024-50239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usb-legacy: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data from the qcom-qmp-usb driver, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. This bug was later reproduced when the driver was copied to create the qmp-usb-legacy driver. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with these drivers.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50240", "url": "https://ubuntu.com/security/CVE-2024-50240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usb: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with this driver.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53077", "url": "https://ubuntu.com/security/CVE-2024-53077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpcrdma: Always release the rpcrdma_device's xa_array Dai pointed out that the xa_init_flags() in rpcrdma_add_one() needs to have a matching xa_destroy() in rpcrdma_remove_one() to release underlying memory that the xarray might have accrued during operation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50242", "url": "https://ubuntu.com/security/CVE-2024-50242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ntfs_file_release", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50243", "url": "https://ubuntu.com/security/CVE-2024-50243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix general protection fault in run_is_mapped_full Fixed deleating of a non-resident attribute in ntfs_create_inode() rollback.", "cve_priority": "low", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50244", "url": "https://ubuntu.com/security/CVE-2024-50244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ni_clear() Checking of NTFS_FLAGS_LOG_REPLAYING added to prevent access to uninitialized bitmap during replay process.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50245", "url": "https://ubuntu.com/security/CVE-2024-50245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix possible deadlock in mi_read Mutex lock with another subclass used in ni_lock_dir().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50246", "url": "https://ubuntu.com/security/CVE-2024-50246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Add rough attr alloc_size check", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50247", "url": "https://ubuntu.com/security/CVE-2024-50247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Check if more than chunk-size bytes are written A incorrectly formatted chunk may decompress into more than LZNT_CHUNK_SIZE bytes and a index out of bounds will occur in s_max_off.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50248", "url": "https://ubuntu.com/security/CVE-2024-50248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Add bounds checking to mi_enum_attr() Added bounds checking to make sure that every attr don't stray beyond valid memory region.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53078", "url": "https://ubuntu.com/security/CVE-2024-53078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Fix NULL vs IS_ERR() check in probe() The iommu_paging_domain_alloc() function doesn't return NULL pointers, it returns error pointers. Update the check to match.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53056", "url": "https://ubuntu.com/security/CVE-2024-53056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Fix potential NULL dereference in mtk_crtc_destroy() In mtk_crtc_create(), if the call to mbox_request_channel() fails then we set the \"mtk_crtc->cmdq_client.chan\" pointer to NULL. In that situation, we do not call cmdq_pkt_create(). During the cleanup, we need to check if the \"mtk_crtc->cmdq_client.chan\" is NULL first before calling cmdq_pkt_destroy(). Calling cmdq_pkt_destroy() is unnecessary if we didn't call cmdq_pkt_create() and it will result in a NULL pointer dereference.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50249", "url": "https://ubuntu.com/security/CVE-2024-50249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Make rmw_lock a raw_spin_lock The following BUG was triggered: ============================= [ BUG: Invalid wait context ] 6.12.0-rc2-XXX #406 Not tainted ----------------------------- kworker/1:1/62 is trying to lock: ffffff8801593030 (&cpc_ptr->rmw_lock){+.+.}-{3:3}, at: cpc_write+0xcc/0x370 other info that might help us debug this: context-{5:5} 2 locks held by kworker/1:1/62: #0: ffffff897ef5ec98 (&rq->__lock){-.-.}-{2:2}, at: raw_spin_rq_lock_nested+0x2c/0x50 #1: ffffff880154e238 (&sg_policy->update_lock){....}-{2:2}, at: sugov_update_shared+0x3c/0x280 stack backtrace: CPU: 1 UID: 0 PID: 62 Comm: kworker/1:1 Not tainted 6.12.0-rc2-g9654bd3e8806 #406 Workqueue: 0x0 (events) Call trace: dump_backtrace+0xa4/0x130 show_stack+0x20/0x38 dump_stack_lvl+0x90/0xd0 dump_stack+0x18/0x28 __lock_acquire+0x480/0x1ad8 lock_acquire+0x114/0x310 _raw_spin_lock+0x50/0x70 cpc_write+0xcc/0x370 cppc_set_perf+0xa0/0x3a8 cppc_cpufreq_fast_switch+0x40/0xc0 cpufreq_driver_fast_switch+0x4c/0x218 sugov_update_shared+0x234/0x280 update_load_avg+0x6ec/0x7b8 dequeue_entities+0x108/0x830 dequeue_task_fair+0x58/0x408 __schedule+0x4f0/0x1070 schedule+0x54/0x130 worker_thread+0xc0/0x2e8 kthread+0x130/0x148 ret_from_fork+0x10/0x20 sugov_update_shared() locks a raw_spinlock while cpc_write() locks a spinlock. To have a correct wait-type order, update rmw_lock to a raw spinlock and ensure that interrupts will be disabled on the CPU holding it. [ rjw: Changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50250", "url": "https://ubuntu.com/security/CVE-2024-50250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fsdax: dax_unshare_iter needs to copy entire blocks The code that copies data from srcmap to iomap in dax_unshare_iter is very very broken, which bfoster's recent fsx changes have exposed. If the pos and len passed to dax_file_unshare are not aligned to an fsblock boundary, the iter pos and length in the _iter function will reflect this unalignment. dax_iomap_direct_access always returns a pointer to the start of the kmapped fsdax page, even if its pos argument is in the middle of that page. This is catastrophic for data integrity when iter->pos is not aligned to a page, because daddr/saddr do not point to the same byte in the file as iter->pos. Hence we corrupt user data by copying it to the wrong place. If iter->pos + iomap_length() in the _iter function not aligned to a page, then we fail to copy a full block, and only partially populate the destination block. This is catastrophic for data confidentiality because we expose stale pmem contents. Fix both of these issues by aligning copy_pos/copy_len to a page boundary (remember, this is fsdax so 1 fsblock == 1 base page) so that we always copy full blocks. We're not done yet -- there's no call to invalidate_inode_pages2_range, so programs that have the file range mmap'd will continue accessing the old memory mapping after the file metadata updates have completed. Be careful with the return value -- if the unshare succeeds, we still need to return the number of bytes that the iomap iter thinks we're operating on.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50251", "url": "https://ubuntu.com/security/CVE-2024-50251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_payload: sanitize offset and length before calling skb_checksum() If access to offset + length is larger than the skbuff length, then skb_checksum() triggers BUG_ON(). skb_checksum() internally subtracts the length parameter while iterating over skbuff, BUG_ON(len) at the end of it checks that the expected length to be included in the checksum calculation is fully consumed.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50252", "url": "https://ubuntu.com/security/CVE-2024-50252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_ipip: Fix memory leak when changing remote IPv6 address The device stores IPv6 addresses that are used for encapsulation in linear memory that is managed by the driver. Changing the remote address of an ip6gre net device never worked properly, but since cited commit the following reproducer [1] would result in a warning [2] and a memory leak [3]. The problem is that the new remote address is never added by the driver to its hash table (and therefore the device) and the old address is never removed from it. Fix by programming the new address when the configuration of the ip6gre net device changes and removing the old one. If the address did not change, then the above would result in increasing the reference count of the address and then decreasing it. [1] # ip link add name bla up type ip6gre local 2001:db8:1::1 remote 2001:db8:2::1 tos inherit ttl inherit # ip link set dev bla type ip6gre remote 2001:db8:3::1 # ip link del dev bla # devlink dev reload pci/0000:01:00.0 [2] WARNING: CPU: 0 PID: 1682 at drivers/net/ethernet/mellanox/mlxsw/spectrum.c:3002 mlxsw_sp_ipv6_addr_put+0x140/0x1d0 Modules linked in: CPU: 0 UID: 0 PID: 1682 Comm: ip Not tainted 6.12.0-rc3-custom-g86b5b55bc835 #151 Hardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023 RIP: 0010:mlxsw_sp_ipv6_addr_put+0x140/0x1d0 [...] Call Trace: mlxsw_sp_router_netdevice_event+0x55f/0x1240 notifier_call_chain+0x5a/0xd0 call_netdevice_notifiers_info+0x39/0x90 unregister_netdevice_many_notify+0x63e/0x9d0 rtnl_dellink+0x16b/0x3a0 rtnetlink_rcv_msg+0x142/0x3f0 netlink_rcv_skb+0x50/0x100 netlink_unicast+0x242/0x390 netlink_sendmsg+0x1de/0x420 ____sys_sendmsg+0x2bd/0x320 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xd0 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f [3] unreferenced object 0xffff898081f597a0 (size 32): comm \"ip\", pid 1626, jiffies 4294719324 hex dump (first 32 bytes): 20 01 0d b8 00 02 00 00 00 00 00 00 00 00 00 01 ............... 21 49 61 83 80 89 ff ff 00 00 00 00 01 00 00 00 !Ia............. backtrace (crc fd9be911): [<00000000df89c55d>] __kmalloc_cache_noprof+0x1da/0x260 [<00000000ff2a1ddb>] mlxsw_sp_ipv6_addr_kvdl_index_get+0x281/0x340 [<000000009ddd445d>] mlxsw_sp_router_netdevice_event+0x47b/0x1240 [<00000000743e7757>] notifier_call_chain+0x5a/0xd0 [<000000007c7b9e13>] call_netdevice_notifiers_info+0x39/0x90 [<000000002509645d>] register_netdevice+0x5f7/0x7a0 [<00000000c2e7d2a9>] ip6gre_newlink_common.isra.0+0x65/0x130 [<0000000087cd6d8d>] ip6gre_newlink+0x72/0x120 [<000000004df7c7cc>] rtnl_newlink+0x471/0xa20 [<0000000057ed632a>] rtnetlink_rcv_msg+0x142/0x3f0 [<0000000032e0d5b5>] netlink_rcv_skb+0x50/0x100 [<00000000908bca63>] netlink_unicast+0x242/0x390 [<00000000cdbe1c87>] netlink_sendmsg+0x1de/0x420 [<0000000011db153e>] ____sys_sendmsg+0x2bd/0x320 [<000000003b6d53eb>] ___sys_sendmsg+0x9a/0xe0 [<00000000cae27c62>] __sys_sendmsg+0x7a/0xd0", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50253", "url": "https://ubuntu.com/security/CVE-2024-50253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check the validity of nr_words in bpf_iter_bits_new() Check the validity of nr_words in bpf_iter_bits_new(). Without this check, when multiplication overflow occurs for nr_bits (e.g., when nr_words = 0x0400-0001, nr_bits becomes 64), stack corruption may occur due to bpf_probe_read_kernel_common(..., nr_bytes = 0x2000-0008). Fix it by limiting the maximum value of nr_words to 511. The value is derived from the current implementation of BPF memory allocator. To ensure compatibility if the BPF memory allocator's size limitation changes in the future, use the helper bpf_mem_alloc_check_size() to check whether nr_bytes is too larger. And return -E2BIG instead of -ENOMEM for oversized nr_bytes.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50254", "url": "https://ubuntu.com/security/CVE-2024-50254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free dynamically allocated bits in bpf_iter_bits_destroy() bpf_iter_bits_destroy() uses \"kit->nr_bits <= 64\" to check whether the bits are dynamically allocated. However, the check is incorrect and may cause a kmemleak as shown below: unreferenced object 0xffff88812628c8c0 (size 32): comm \"swapper/0\", pid 1, jiffies 4294727320 hex dump (first 32 bytes): \tb0 c1 55 f5 81 88 ff ff f0 f0 f0 f0 f0 f0 f0 f0 ..U........... \tf0 f0 f0 f0 f0 f0 f0 f0 00 00 00 00 00 00 00 00 .............. backtrace (crc 781e32cc): \t[<00000000c452b4ab>] kmemleak_alloc+0x4b/0x80 \t[<0000000004e09f80>] __kmalloc_node_noprof+0x480/0x5c0 \t[<00000000597124d6>] __alloc.isra.0+0x89/0xb0 \t[<000000004ebfffcd>] alloc_bulk+0x2af/0x720 \t[<00000000d9c10145>] prefill_mem_cache+0x7f/0xb0 \t[<00000000ff9738ff>] bpf_mem_alloc_init+0x3e2/0x610 \t[<000000008b616eac>] bpf_global_ma_init+0x19/0x30 \t[<00000000fc473efc>] do_one_initcall+0xd3/0x3c0 \t[<00000000ec81498c>] kernel_init_freeable+0x66a/0x940 \t[<00000000b119f72f>] kernel_init+0x20/0x160 \t[<00000000f11ac9a7>] ret_from_fork+0x3c/0x70 \t[<0000000004671da4>] ret_from_fork_asm+0x1a/0x30 That is because nr_bits will be set as zero in bpf_iter_bits_next() after all bits have been iterated. Fix the issue by setting kit->bit to kit->nr_bits instead of setting kit->nr_bits to zero when the iteration completes in bpf_iter_bits_next(). In addition, use \"!nr_bits || bits >= nr_bits\" to check whether the iteration is complete and still use \"nr_bits > 64\" to indicate whether bits are dynamically allocated. The \"!nr_bits\" check is necessary because bpf_iter_bits_new() may fail before setting kit->nr_bits, and this condition will stop the iteration early instead of accessing the zeroed or freed kit->bits. Considering the initial value of kit->bits is -1 and the type of kit->nr_bits is unsigned int, change the type of kit->nr_bits to int. The potential overflow problem will be handled in the following patch.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50255", "url": "https://ubuntu.com/security/CVE-2024-50255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci: fix null-ptr-deref in hci_read_supported_codecs Fix __hci_cmd_sync_sk() to return not NULL for unknown opcodes. __hci_cmd_sync_sk() returns NULL if a command returns a status event. However, it also returns NULL where an opcode doesn't exist in the hci_cc table because hci_cmd_complete_evt() assumes status = skb->data[0] for unknown opcodes. This leads to null-ptr-deref in cmd_sync for HCI_OP_READ_LOCAL_CODECS as there is no hci_cc for HCI_OP_READ_LOCAL_CODECS, which always assumes status = skb->data[0]. KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077] CPU: 1 PID: 2000 Comm: kworker/u9:5 Not tainted 6.9.0-ga6bcb805883c-dirty #10 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: hci7 hci_power_on RIP: 0010:hci_read_supported_codecs+0xb9/0x870 net/bluetooth/hci_codec.c:138 Code: 08 48 89 ef e8 b8 c1 8f fd 48 8b 75 00 e9 96 00 00 00 49 89 c6 48 ba 00 00 00 00 00 fc ff df 4c 8d 60 70 4c 89 e3 48 c1 eb 03 <0f> b6 04 13 84 c0 0f 85 82 06 00 00 41 83 3c 24 02 77 0a e8 bf 78 RSP: 0018:ffff888120bafac8 EFLAGS: 00010212 RAX: 0000000000000000 RBX: 000000000000000e RCX: ffff8881173f0040 RDX: dffffc0000000000 RSI: ffffffffa58496c0 RDI: ffff88810b9ad1e4 RBP: ffff88810b9ac000 R08: ffffffffa77882a7 R09: 1ffffffff4ef1054 R10: dffffc0000000000 R11: fffffbfff4ef1055 R12: 0000000000000070 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88810b9ac000 FS: 0000000000000000(0000) GS:ffff8881f6c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6ddaa3439e CR3: 0000000139764003 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: hci_read_local_codecs_sync net/bluetooth/hci_sync.c:4546 [inline] hci_init_stage_sync net/bluetooth/hci_sync.c:3441 [inline] hci_init4_sync net/bluetooth/hci_sync.c:4706 [inline] hci_init_sync net/bluetooth/hci_sync.c:4742 [inline] hci_dev_init_sync net/bluetooth/hci_sync.c:4912 [inline] hci_dev_open_sync+0x19a9/0x2d30 net/bluetooth/hci_sync.c:4994 hci_dev_do_open net/bluetooth/hci_core.c:483 [inline] hci_power_on+0x11e/0x560 net/bluetooth/hci_core.c:1015 process_one_work kernel/workqueue.c:3267 [inline] process_scheduled_works+0x8ef/0x14f0 kernel/workqueue.c:3348 worker_thread+0x91f/0xe50 kernel/workqueue.c:3429 kthread+0x2cb/0x360 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50256", "url": "https://ubuntu.com/security/CVE-2024-50256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6() I got a syzbot report without a repro [1] crashing in nf_send_reset6() I think the issue is that dev->hard_header_len is zero, and we attempt later to push an Ethernet header. Use LL_MAX_HEADER, as other functions in net/ipv6/netfilter/nf_reject_ipv6.c. [1] skbuff: skb_under_panic: text:ffffffff89b1d008 len:74 put:14 head:ffff88803123aa00 data:ffff88803123a9f2 tail:0x3c end:0x140 dev:syz_tun kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 UID: 0 PID: 7373 Comm: syz.1.568 Not tainted 6.12.0-rc2-syzkaller-00631-g6d858708d465 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:skb_panic net/core/skbuff.c:206 [inline] RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216 Code: 0d 8d 48 c7 c6 60 a6 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 ba 30 38 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP: 0018:ffffc900045269b0 EFLAGS: 00010282 RAX: 0000000000000088 RBX: dffffc0000000000 RCX: cd66dacdc5d8e800 RDX: 0000000000000000 RSI: 0000000000000200 RDI: 0000000000000000 RBP: ffff88802d39a3d0 R08: ffffffff8174afec R09: 1ffff920008a4ccc R10: dffffc0000000000 R11: fffff520008a4ccd R12: 0000000000000140 R13: ffff88803123aa00 R14: ffff88803123a9f2 R15: 000000000000003c FS: 00007fdbee5ff6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000005d322000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: skb_push+0xe5/0x100 net/core/skbuff.c:2636 eth_header+0x38/0x1f0 net/ethernet/eth.c:83 dev_hard_header include/linux/netdevice.h:3208 [inline] nf_send_reset6+0xce6/0x1270 net/ipv6/netfilter/nf_reject_ipv6.c:358 nft_reject_inet_eval+0x3b9/0x690 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x418/0x6b0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] br_nf_pre_routing_ipv6+0x63e/0x770 net/bridge/br_netfilter_ipv6.c:184 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_bridge_pre net/bridge/br_input.c:277 [inline] br_handle_frame+0x9fd/0x1530 net/bridge/br_input.c:424 __netif_receive_skb_core+0x13e8/0x4570 net/core/dev.c:5562 __netif_receive_skb_one_core net/core/dev.c:5666 [inline] __netif_receive_skb+0x12f/0x650 net/core/dev.c:5781 netif_receive_skb_internal net/core/dev.c:5867 [inline] netif_receive_skb+0x1e8/0x890 net/core/dev.c:5926 tun_rx_batched+0x1b7/0x8f0 drivers/net/tun.c:1550 tun_get_user+0x3056/0x47e0 drivers/net/tun.c:2007 tun_chr_write_iter+0x10d/0x1f0 drivers/net/tun.c:2053 new_sync_write fs/read_write.c:590 [inline] vfs_write+0xa6d/0xc90 fs/read_write.c:683 ksys_write+0x183/0x2b0 fs/read_write.c:736 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:0x7fdbeeb7d1ff Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 c9 8d 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 1c 8e 02 00 48 RSP: 002b:00007fdbee5ff000 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fdbeed36058 RCX: 00007fdbeeb7d1ff RDX: 000000000000008e RSI: 0000000020000040 RDI: 00000000000000c8 RBP: 00007fdbeebf12be R08: 0000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50257", "url": "https://ubuntu.com/security/CVE-2024-50257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: Fix use-after-free in get_info() ip6table_nat module unload has refcnt warning for UAF. call trace is: WARNING: CPU: 1 PID: 379 at kernel/module/main.c:853 module_put+0x6f/0x80 Modules linked in: ip6table_nat(-) CPU: 1 UID: 0 PID: 379 Comm: ip6tables Not tainted 6.12.0-rc4-00047-gc2ee9f594da8-dirty #205 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:module_put+0x6f/0x80 Call Trace: get_info+0x128/0x180 do_ip6t_get_ctl+0x6a/0x430 nf_getsockopt+0x46/0x80 ipv6_getsockopt+0xb9/0x100 rawv6_getsockopt+0x42/0x190 do_sock_getsockopt+0xaa/0x180 __sys_getsockopt+0x70/0xc0 __x64_sys_getsockopt+0x20/0x30 do_syscall_64+0xa2/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Concurrent execution of module unload and get_info() trigered the warning. The root cause is as follows: cpu0\t\t\t\t cpu1 module_exit //mod->state = MODULE_STATE_GOING ip6table_nat_exit xt_unregister_template \tkfree(t) \t//removed from templ_list \t\t\t\t getinfo() \t\t\t\t\t t = xt_find_table_lock \t\t\t\t\t\tlist_for_each_entry(tmpl, &xt_templates[af]...) \t\t\t\t\t\t\tif (strcmp(tmpl->name, name)) \t\t\t\t\t\t\t\tcontinue; //table not found \t\t\t\t\t\t\ttry_module_get \t\t\t\t\t\tlist_for_each_entry(t, &xt_net->tables[af]...) \t\t\t\t\t\t\treturn t; //not get refcnt \t\t\t\t\t module_put(t->me) //uaf unregister_pernet_subsys //remove table from xt_net list While xt_table module was going away and has been removed from xt_templates list, we couldnt get refcnt of xt_table->me. Check module in xt_net->tables list re-traversal to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50258", "url": "https://ubuntu.com/security/CVE-2024-50258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix crash when config small gso_max_size/gso_ipv4_max_size Config a small gso_max_size/gso_ipv4_max_size will lead to an underflow in sk_dst_gso_max_size(), which may trigger a BUG_ON crash, because sk->sk_gso_max_size would be much bigger than device limits. Call Trace: tcp_write_xmit tso_segs = tcp_init_tso_segs(skb, mss_now); tcp_set_skb_tso_segs tcp_skb_pcount_set // skb->len = 524288, mss_now = 8 // u16 tso_segs = 524288/8 = 65535 -> 0 tso_segs = DIV_ROUND_UP(skb->len, mss_now) BUG_ON(!tso_segs) Add check for the minimum value of gso_max_size and gso_ipv4_max_size.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50262", "url": "https://ubuntu.com/security/CVE-2024-50262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix out-of-bounds write in trie_get_next_key() trie_get_next_key() allocates a node stack with size trie->max_prefixlen, while it writes (trie->max_prefixlen + 1) nodes to the stack when it has full paths from the root to leaves. For example, consider a trie with max_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ... 0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with .prefixlen = 8 make 9 nodes be written on the node stack with size 8.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53044", "url": "https://ubuntu.com/security/CVE-2024-53044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_api: fix xa_insert() error path in tcf_block_get_ext() This command: $ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact Error: block dev insert failed: -EBUSY. fails because user space requests the same block index to be set for both ingress and egress. [ side note, I don't think it even failed prior to commit 913b47d3424e (\"net/sched: Introduce tc block netdev tracking infra\"), because this is a command from an old set of notes of mine which used to work, but alas, I did not scientifically bisect this ] The problem is not that it fails, but rather, that the second time around, it fails differently (and irrecoverably): $ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact Error: dsa_core: Flow block cb is busy. [ another note: the extack is added by me for illustration purposes. the context of the problem is that clsact_init() obtains the same &q->ingress_block pointer as &q->egress_block, and since we call tcf_block_get_ext() on both of them, \"dev\" will be added to the block->ports xarray twice, thus failing the operation: once through the ingress block pointer, and once again through the egress block pointer. the problem itself is that when xa_insert() fails, we have emitted a FLOW_BLOCK_BIND command through ndo_setup_tc(), but the offload never sees a corresponding FLOW_BLOCK_UNBIND. ] Even correcting the bad user input, we still cannot recover: $ tc qdisc replace dev swp3 ingress_block 1 egress_block 2 clsact Error: dsa_core: Flow block cb is busy. Basically the only way to recover is to reboot the system, or unbind and rebind the net device driver. To fix the bug, we need to fill the correct error teardown path which was missed during code movement, and call tcf_block_offload_unbind() when xa_insert() fails. [ last note, fundamentally I blame the label naming convention in tcf_block_get_ext() for the bug. The labels should be named after what they do, not after the error path that jumps to them. This way, it is obviously wrong that two labels pointing to the same code mean something is wrong, and checking the code correctness at the goto site is also easier ]", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50259", "url": "https://ubuntu.com/security/CVE-2024-50259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netdevsim: Add trailing zero to terminate the string in nsim_nexthop_bucket_activity_write() This was found by a static analyzer. We should not forget the trailing zero after copy_from_user() if we will further do some string operations, sscanf() in this case. Adding a trailing zero will ensure that the function performs properly.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50304", "url": "https://ubuntu.com/security/CVE-2024-50304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find() The per-netns IP tunnel hash table is protected by the RTNL mutex and ip_tunnel_find() is only called from the control path where the mutex is taken. Add a lockdep expression to hlist_for_each_entry_rcu() in ip_tunnel_find() in order to validate that the mutex is held and to silence the suspicious RCU usage warning [1]. [1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gd95d9a31aceb #139 Not tainted ----------------------------- net/ipv4/ip_tunnel.c:221 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/362: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60 stack backtrace: CPU: 12 UID: 0 PID: 362 Comm: ip Not tainted 6.12.0-rc3-custom-gd95d9a31aceb #139 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 ip_tunnel_find+0x435/0x4d0 ip_tunnel_newlink+0x517/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53042", "url": "https://ubuntu.com/security/CVE-2024-53042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_init_flow() There are code paths from which the function is called without holding the RCU read lock, resulting in a suspicious RCU usage warning [1]. Fix by using l3mdev_master_upper_ifindex_by_index() which will acquire the RCU read lock before calling l3mdev_master_upper_ifindex_by_index_rcu(). [1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gac8f72681cf2 #141 Not tainted ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/361: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60 stack backtrace: CPU: 3 UID: 0 PID: 361 Comm: ip Not tainted 6.12.0-rc3-custom-gac8f72681cf2 #141 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 dev_get_by_index_rcu+0x1d3/0x210 l3mdev_master_upper_ifindex_by_index_rcu+0x2b/0xf0 ip_tunnel_bind_dev+0x72f/0xa00 ip_tunnel_newlink+0x368/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53048", "url": "https://ubuntu.com/security/CVE-2024-53048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix crash on probe for DPLL enabled E810 LOM The E810 Lan On Motherboard (LOM) design is vendor specific. Intel provides the reference design, but it is up to vendor on the final product design. For some cases, like Linux DPLL support, the static values defined in the driver does not reflect the actual LOM design. Current implementation of dpll pins is causing the crash on probe of the ice driver for such DPLL enabled E810 LOM designs: WARNING: (...) at drivers/dpll/dpll_core.c:495 dpll_pin_get+0x2c4/0x330 ... Call Trace: ? __warn+0x83/0x130 ? dpll_pin_get+0x2c4/0x330 ? report_bug+0x1b7/0x1d0 ? handle_bug+0x42/0x70 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? dpll_pin_get+0x117/0x330 ? dpll_pin_get+0x2c4/0x330 ? dpll_pin_get+0x117/0x330 ice_dpll_get_pins.isra.0+0x52/0xe0 [ice] ... The number of dpll pins enabled by LOM vendor is greater than expected and defined in the driver for Intel designed NICs, which causes the crash. Prevent the crash and allow generic pin initialization within Linux DPLL subsystem for DPLL enabled E810 LOM designs. Newly designed solution for described issue will be based on \"per HW design\" pin initialization. It requires pin information dynamically acquired from the firmware and is already in progress, planned for next-tree only.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53058", "url": "https://ubuntu.com/security/CVE-2024-53058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data In case the non-paged data of a SKB carries protocol header and protocol payload to be transmitted on a certain platform that the DMA AXI address width is configured to 40-bit/48-bit, or the size of the non-paged data is bigger than TSO_MAX_BUFF_SIZE on a certain platform that the DMA AXI address width is configured to 32-bit, then this SKB requires at least two DMA transmit descriptors to serve it. For example, three descriptors are allocated to split one DMA buffer mapped from one piece of non-paged data: dma_desc[N + 0], dma_desc[N + 1], dma_desc[N + 2]. Then three elements of tx_q->tx_skbuff_dma[] will be allocated to hold extra information to be reused in stmmac_tx_clean(): tx_q->tx_skbuff_dma[N + 0], tx_q->tx_skbuff_dma[N + 1], tx_q->tx_skbuff_dma[N + 2]. Now we focus on tx_q->tx_skbuff_dma[entry].buf, which is the DMA buffer address returned by DMA mapping call. stmmac_tx_clean() will try to unmap the DMA buffer _ONLY_IF_ tx_q->tx_skbuff_dma[entry].buf is a valid buffer address. The expected behavior that saves DMA buffer address of this non-paged data to tx_q->tx_skbuff_dma[entry].buf is: tx_q->tx_skbuff_dma[N + 0].buf = NULL; tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = dma_map_single(); Unfortunately, the current code misbehaves like this: tx_q->tx_skbuff_dma[N + 0].buf = dma_map_single(); tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = NULL; On the stmmac_tx_clean() side, when dma_desc[N + 0] is closed by the DMA engine, tx_q->tx_skbuff_dma[N + 0].buf is a valid buffer address obviously, then the DMA buffer will be unmapped immediately. There may be a rare case that the DMA engine does not finish the pending dma_desc[N + 1], dma_desc[N + 2] yet. Now things will go horribly wrong, DMA is going to access a unmapped/unreferenced memory region, corrupted data will be transmited or iommu fault will be triggered :( In contrast, the for-loop that maps SKB fragments behaves perfectly as expected, and that is how the driver should do for both non-paged data and paged frags actually. This patch corrects DMA map/unmap sequences by fixing the array index for tx_q->tx_skbuff_dma[entry].buf when assigning DMA buffer address. Tested and verified on DWXGMAC CORE 3.20a", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50260", "url": "https://ubuntu.com/security/CVE-2024-50260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sock_map: fix a NULL pointer dereference in sock_map_link_update_prog() The following race condition could trigger a NULL pointer dereference: sock_map_link_detach():\t\tsock_map_link_update_prog(): mutex_lock(&sockmap_mutex); ... sockmap_link->map = NULL; mutex_unlock(&sockmap_mutex); \t\t\t\t mutex_lock(&sockmap_mutex); \t\t\t\t ... \t\t\t\t sock_map_prog_link_lookup(sockmap_link->map); \t\t\t\t mutex_unlock(&sockmap_mutex); Fix it by adding a NULL pointer check. In this specific case, it makes no sense to update a link which is being released.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53045", "url": "https://ubuntu.com/security/CVE-2024-53045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: dapm: fix bounds checker error in dapm_widget_list_create The widgets array in the snd_soc_dapm_widget_list has a __counted_by attribute attached to it, which points to the num_widgets variable. This attribute is used in bounds checking, and if it is not set before the array is filled, then the bounds sanitizer will issue a warning or a kernel panic if CONFIG_UBSAN_TRAP is set. This patch sets the size of the widgets list calculated with list_for_each as the initial value for num_widgets as it is used for allocating memory for the array. It is updated with the actual number of added elements after the array is filled.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50261", "url": "https://ubuntu.com/security/CVE-2024-50261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macsec: Fix use-after-free while sending the offloading packet KASAN reports the following UAF. The metadata_dst, which is used to store the SCI value for macsec offload, is already freed by metadata_dst_free() in macsec_free_netdev(), while driver still use it for sending the packet. To fix this issue, dst_release() is used instead to release metadata_dst. So it is not freed instantly in macsec_free_netdev() if still referenced by skb. BUG: KASAN: slab-use-after-free in mlx5e_xmit+0x1e8f/0x4190 [mlx5_core] Read of size 2 at addr ffff88813e42e038 by task kworker/7:2/714 [...] Workqueue: mld mld_ifc_work Call Trace: dump_stack_lvl+0x51/0x60 print_report+0xc1/0x600 kasan_report+0xab/0xe0 mlx5e_xmit+0x1e8f/0x4190 [mlx5_core] dev_hard_start_xmit+0x120/0x530 sch_direct_xmit+0x149/0x11e0 __qdisc_run+0x3ad/0x1730 __dev_queue_xmit+0x1196/0x2ed0 vlan_dev_hard_start_xmit+0x32e/0x510 [8021q] dev_hard_start_xmit+0x120/0x530 __dev_queue_xmit+0x14a7/0x2ed0 macsec_start_xmit+0x13e9/0x2340 dev_hard_start_xmit+0x120/0x530 __dev_queue_xmit+0x14a7/0x2ed0 ip6_finish_output2+0x923/0x1a70 ip6_finish_output+0x2d7/0x970 ip6_output+0x1ce/0x3a0 NF_HOOK.constprop.0+0x15f/0x190 mld_sendpack+0x59a/0xbd0 mld_ifc_work+0x48a/0xa80 process_one_work+0x5aa/0xe50 worker_thread+0x79c/0x1290 kthread+0x28f/0x350 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x11/0x20 Allocated by task 3922: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 __kasan_kmalloc+0x77/0x90 __kmalloc_noprof+0x188/0x400 metadata_dst_alloc+0x1f/0x4e0 macsec_newlink+0x914/0x1410 __rtnl_newlink+0xe08/0x15b0 rtnl_newlink+0x5f/0x90 rtnetlink_rcv_msg+0x667/0xa80 netlink_rcv_skb+0x12c/0x360 netlink_unicast+0x551/0x770 netlink_sendmsg+0x72d/0xbd0 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x52e/0x6a0 ___sys_sendmsg+0xeb/0x170 __sys_sendmsg+0xb5/0x140 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Freed by task 4011: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x50 poison_slab_object+0x10c/0x190 __kasan_slab_free+0x11/0x30 kfree+0xe0/0x290 macsec_free_netdev+0x3f/0x140 netdev_run_todo+0x450/0xc70 rtnetlink_rcv_msg+0x66f/0xa80 netlink_rcv_skb+0x12c/0x360 netlink_unicast+0x551/0x770 netlink_sendmsg+0x72d/0xbd0 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x52e/0x6a0 ___sys_sendmsg+0xeb/0x170 __sys_sendmsg+0xb5/0x140 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53059", "url": "https://ubuntu.com/security/CVE-2024-53059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd() 1. The size of the response packet is not validated. 2. The response buffer is not freed. Resolve these issues by switching to iwl_mvm_send_cmd_status(), which handles both size validation and frees the buffer.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53074", "url": "https://ubuntu.com/security/CVE-2024-53074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: don't leak a link on AP removal Release the link mapping resource in AP removal. This impacted devices that do not support the MLD API (9260 and down). On those devices, we couldn't start the AP again after the AP has been already started and stopped.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53049", "url": "https://ubuntu.com/security/CVE-2024-53049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slub/kunit: fix a WARNING due to unwrapped __kmalloc_cache_noprof 'modprobe slub_kunit' will have a warning as shown below. The root cause is that __kmalloc_cache_noprof was directly used, which resulted in no alloc_tag being allocated. This caused current->alloc_tag to be null, leading to a warning in alloc_tag_add_check. Let's add an alloc_hook layer to __kmalloc_cache_noprof specifically within lib/slub_kunit.c, which is the only user of this internal slub function outside kmalloc implementation itself. [58162.947016] WARNING: CPU: 2 PID: 6210 at ./include/linux/alloc_tag.h:125 alloc_tagging_slab_alloc_hook+0x268/0x27c [58162.957721] Call trace: [58162.957919] alloc_tagging_slab_alloc_hook+0x268/0x27c [58162.958286] __kmalloc_cache_noprof+0x14c/0x344 [58162.958615] test_kmalloc_redzone_access+0x50/0x10c [slub_kunit] [58162.959045] kunit_try_run_case+0x74/0x184 [kunit] [58162.959401] kunit_generic_run_threadfn_adapter+0x2c/0x4c [kunit] [58162.959841] kthread+0x10c/0x118 [58162.960093] ret_from_fork+0x10/0x20 [58162.960363] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50192", "url": "https://ubuntu.com/security/CVE-2024-50192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v4: Don't allow a VMOVP on a dying VPE Kunkun Jiang reported that there is a small window of opportunity for userspace to force a change of affinity for a VPE while the VPE has already been unmapped, but the corresponding doorbell interrupt still visible in /proc/irq/. Plug the race by checking the value of vmapp_count, which tracks whether the VPE is mapped ot not, and returning an error in this case. This involves making vmapp_count common to both GICv4.1 and its v4.0 ancestor.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50069", "url": "https://ubuntu.com/security/CVE-2024-50069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: apple: check devm_kasprintf() returned value devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked. Fix this lack and check the returned value. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50070", "url": "https://ubuntu.com/security/CVE-2024-50070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: stm32: check devm_kasprintf() returned value devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked. Fix this lack and check the returned value. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50196", "url": "https://ubuntu.com/security/CVE-2024-50196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: ocelot: fix system hang on level based interrupts The current implementation only calls chained_irq_enter() and chained_irq_exit() if it detects pending interrupts. ``` for (i = 0; i < info->stride; i++) { \turegmap_read(info->map, id_reg + 4 * i, ®); \tif (!reg) \t\tcontinue; \tchained_irq_enter(parent_chip, desc); ``` However, in case of GPIO pin configured in level mode and the parent controller configured in edge mode, GPIO interrupt might be lowered by the hardware. In the result, if the interrupt is short enough, the parent interrupt is still pending while the GPIO interrupt is cleared; chained_irq_enter() never gets called and the system hangs trying to service the parent interrupt. Moving chained_irq_enter() and chained_irq_exit() outside the for loop ensures that they are called even when GPIO interrupt is lowered by the hardware. The similar code with chained_irq_enter() / chained_irq_exit() functions wrapping interrupt checking loop may be found in many other drivers: ``` grep -r -A 10 chained_irq_enter drivers/pinctrl ```", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50197", "url": "https://ubuntu.com/security/CVE-2024-50197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: intel: platform: fix error path in device_for_each_child_node() The device_for_each_child_node() loop requires calls to fwnode_handle_put() upon early returns to decrement the refcount of the child node and avoid leaking memory if that error path is triggered. There is one early returns within that loop in intel_platform_pinctrl_prepare_community(), but fwnode_handle_put() is missing. Instead of adding the missing call, the scoped version of the loop can be used to simplify the code and avoid mistakes in the future if new early returns are added, as the child node is only used for parsing, and it is never assigned.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50071", "url": "https://ubuntu.com/security/CVE-2024-50071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: nuvoton: fix a double free in ma35_pinctrl_dt_node_to_map_func() 'new_map' is allocated using devm_* which takes care of freeing the allocated data on device removal, call to \t.dt_free_map = pinconf_generic_dt_free_map double frees the map as pinconf_generic_dt_free_map() calls pinctrl_utils_free_map(). Fix this by using kcalloc() instead of auto-managed devm_kcalloc().", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50072", "url": "https://ubuntu.com/security/CVE-2024-50072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/bugs: Use code segment selector for VERW operand Robert Gill reported below #GP in 32-bit mode when dosemu software was executing vm86() system call: general protection fault: 0000 [#1] PREEMPT SMP CPU: 4 PID: 4610 Comm: dosemu.bin Not tainted 6.6.21-gentoo-x86 #1 Hardware name: Dell Inc. PowerEdge 1950/0H723K, BIOS 2.7.0 10/30/2010 EIP: restore_all_switch_stack+0xbe/0xcf EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000 ESI: 00000000 EDI: 00000000 EBP: 00000000 ESP: ff8affdc DS: 0000 ES: 0000 FS: 0000 GS: 0033 SS: 0068 EFLAGS: 00010046 CR0: 80050033 CR2: 00c2101c CR3: 04b6d000 CR4: 000406d0 Call Trace: show_regs+0x70/0x78 die_addr+0x29/0x70 exc_general_protection+0x13c/0x348 exc_bounds+0x98/0x98 handle_exception+0x14d/0x14d exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf This only happens in 32-bit mode when VERW based mitigations like MDS/RFDS are enabled. This is because segment registers with an arbitrary user value can result in #GP when executing VERW. Intel SDM vol. 2C documents the following behavior for VERW instruction: #GP(0) - If a memory operand effective address is outside the CS, DS, ES, \t FS, or GS segment limit. CLEAR_CPU_BUFFERS macro executes VERW instruction before returning to user space. Use %cs selector to reference VERW operand. This ensures VERW will not #GP for an arbitrary user %ds. [ mingo: Fixed the SOB chain. ]", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50073", "url": "https://ubuntu.com/security/CVE-2024-50073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: Fix use-after-free in gsm_cleanup_mux BUG: KASAN: slab-use-after-free in gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] Read of size 8 at addr ffff88815fe99c00 by task poc/3379 CPU: 0 UID: 0 PID: 3379 Comm: poc Not tainted 6.11.0+ #56 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] __pfx_gsm_cleanup_mux+0x10/0x10 drivers/tty/n_gsm.c:3124 [n_gsm] __pfx_sched_clock_cpu+0x10/0x10 kernel/sched/clock.c:389 update_load_avg+0x1c1/0x27b0 kernel/sched/fair.c:4500 __pfx_min_vruntime_cb_rotate+0x10/0x10 kernel/sched/fair.c:846 __rb_insert_augmented+0x492/0xbf0 lib/rbtree.c:161 gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] _raw_spin_lock_irqsave+0x92/0xf0 arch/x86/include/asm/atomic.h:107 __pfx_gsmld_ioctl+0x10/0x10 drivers/tty/n_gsm.c:3822 [n_gsm] ktime_get+0x5e/0x140 kernel/time/timekeeping.c:195 ldsem_down_read+0x94/0x4e0 arch/x86/include/asm/atomic64_64.h:79 __pfx_ldsem_down_read+0x10/0x10 drivers/tty/tty_ldsem.c:338 __pfx_do_vfs_ioctl+0x10/0x10 fs/ioctl.c:805 tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 Allocated by task 65: gsm_data_alloc.constprop.0+0x27/0x190 drivers/tty/n_gsm.c:926 [n_gsm] gsm_send+0x2c/0x580 drivers/tty/n_gsm.c:819 [n_gsm] gsm1_receive+0x547/0xad0 drivers/tty/n_gsm.c:3038 [n_gsm] gsmld_receive_buf+0x176/0x280 drivers/tty/n_gsm.c:3609 [n_gsm] tty_ldisc_receive_buf+0x101/0x1e0 drivers/tty/tty_buffer.c:391 tty_port_default_receive_buf+0x61/0xa0 drivers/tty/tty_port.c:39 flush_to_ldisc+0x1b0/0x750 drivers/tty/tty_buffer.c:445 process_scheduled_works+0x2b0/0x10d0 kernel/workqueue.c:3229 worker_thread+0x3dc/0x950 kernel/workqueue.c:3391 kthread+0x2a3/0x370 kernel/kthread.c:389 ret_from_fork+0x2d/0x70 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:257 Freed by task 3367: kfree+0x126/0x420 mm/slub.c:4580 gsm_cleanup_mux+0x36c/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 [Analysis] gsm_msg on the tx_ctrl_list or tx_data_list of gsm_mux can be freed by multi threads through ioctl,which leads to the occurrence of uaf. Protect it by gsm tx lock.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50193", "url": "https://ubuntu.com/security/CVE-2024-50193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/entry_32: Clear CPU buffers after register restore in NMI return CPU buffers are currently cleared after call to exc_nmi, but before register state is restored. This may be okay for MDS mitigation but not for RDFS. Because RDFS mitigation requires CPU buffers to be cleared when registers don't have any sensitive data. Move CLEAR_CPU_BUFFERS after RESTORE_ALL_NMI.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50074", "url": "https://ubuntu.com/security/CVE-2024-50074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: parport: Proper fix for array out-of-bounds access The recent fix for array out-of-bounds accesses replaced sprintf() calls blindly with snprintf(). However, since snprintf() returns the would-be-printed size, not the actually output size, the length calculation can still go over the given limit. Use scnprintf() instead of snprintf(), which returns the actually output letters, for addressing the potential out-of-bounds access properly.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50100", "url": "https://ubuntu.com/security/CVE-2024-50100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: gadget: dummy-hcd: Fix \"task hung\" problem The syzbot fuzzer has been encountering \"task hung\" problems ever since the dummy-hcd driver was changed to use hrtimers instead of regular timers. It turns out that the problems are caused by a subtle difference between the timer_pending() and hrtimer_active() APIs. The changeover blindly replaced the first by the second. However, timer_pending() returns True when the timer is queued but not when its callback is running, whereas hrtimer_active() returns True when the hrtimer is queued _or_ its callback is running. This difference occasionally caused dummy_urb_enqueue() to think that the callback routine had not yet started when in fact it was almost finished. As a result the hrtimer was not restarted, which made it impossible for the driver to dequeue later the URB that was just enqueued. This caused usb_kill_urb() to hang, and things got worse from there. Since hrtimers have no API for telling when they are queued and the callback isn't running, the driver must keep track of this for itself. That's what this patch does, adding a new \"timer_pending\" flag and setting or clearing it at the appropriate times.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50075", "url": "https://ubuntu.com/security/CVE-2024-50075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xhci: tegra: fix checked USB2 port number If USB virtualizatoin is enabled, USB2 ports are shared between all Virtual Functions. The USB2 port number owned by an USB2 root hub in a Virtual Function may be less than total USB2 phy number supported by the Tegra XUSB controller. Using total USB2 phy number as port number to check all PORTSC values would cause invalid memory access. [ 116.923438] Unable to handle kernel paging request at virtual address 006c622f7665642f ... [ 117.213640] Call trace: [ 117.216783] tegra_xusb_enter_elpg+0x23c/0x658 [ 117.222021] tegra_xusb_runtime_suspend+0x40/0x68 [ 117.227260] pm_generic_runtime_suspend+0x30/0x50 [ 117.232847] __rpm_callback+0x84/0x3c0 [ 117.237038] rpm_suspend+0x2dc/0x740 [ 117.241229] pm_runtime_work+0xa0/0xb8 [ 117.245769] process_scheduled_works+0x24c/0x478 [ 117.251007] worker_thread+0x23c/0x328 [ 117.255547] kthread+0x104/0x1b0 [ 117.259389] ret_from_fork+0x10/0x20 [ 117.263582] Code: 54000222 f9461ae8 f8747908 b4ffff48 (f9400100)", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50076", "url": "https://ubuntu.com/security/CVE-2024-50076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vt: prevent kernel-infoleak in con_font_get() font.data may not initialize all memory spaces depending on the implementation of vc->vc_sw->con_font_get. This may cause info-leak, so to prevent this, it is safest to modify it to initialize the allocated memory space to 0, and it generally does not affect the overall performance of the system.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50077", "url": "https://ubuntu.com/security/CVE-2024-50077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix multiple init when debugfs is disabled If bt_debugfs is not created successfully, which happens if either CONFIG_DEBUG_FS or CONFIG_DEBUG_FS_ALLOW_ALL is unset, then iso_init() returns early and does not set iso_inited to true. This means that a subsequent call to iso_init() will result in duplicate calls to proto_register(), bt_sock_register(), etc. With CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, the duplicate call to proto_register() triggers this BUG(): list_add double add: new=ffffffffc0b280d0, prev=ffffffffbab56250, next=ffffffffc0b280d0. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:35! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 2 PID: 887 Comm: bluetoothd Not tainted 6.10.11-1-ao-desktop #1 RIP: 0010:__list_add_valid_or_report+0x9a/0xa0 ... __list_add_valid_or_report+0x9a/0xa0 proto_register+0x2b5/0x340 iso_init+0x23/0x150 [bluetooth] set_iso_socket_func+0x68/0x1b0 [bluetooth] kmem_cache_free+0x308/0x330 hci_sock_sendmsg+0x990/0x9e0 [bluetooth] __sock_sendmsg+0x7b/0x80 sock_write_iter+0x9a/0x110 do_iter_readv_writev+0x11d/0x220 vfs_writev+0x180/0x3e0 do_writev+0xca/0x100 ... This change removes the early return. The check for iso_debugfs being NULL was unnecessary, it is always NULL when iso_inited is false.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50078", "url": "https://ubuntu.com/security/CVE-2024-50078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Call iso_exit() on module unload If iso_init() has been called, iso_exit() must be called on module unload. Without that, the struct proto that iso_init() registered with proto_register() becomes invalid, which could cause unpredictable problems later. In my case, with CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, loading the module again usually triggers this BUG(): list_add corruption. next->prev should be prev (ffffffffb5355fd0), but was 0000000000000068. (next=ffffffffc0a010d0). ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:29! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 4159 Comm: modprobe Not tainted 6.10.11-4+bt2-ao-desktop #1 RIP: 0010:__list_add_valid_or_report+0x61/0xa0 ... __list_add_valid_or_report+0x61/0xa0 proto_register+0x299/0x320 hci_sock_init+0x16/0xc0 [bluetooth] bt_init+0x68/0xd0 [bluetooth] __pfx_bt_init+0x10/0x10 [bluetooth] do_one_initcall+0x80/0x2f0 do_init_module+0x8b/0x230 __do_sys_init_module+0x15f/0x190 do_syscall_64+0x68/0x110 ...", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50198", "url": "https://ubuntu.com/security/CVE-2024-50198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: veml6030: fix IIO device retrieval from embedded device The dev pointer that is received as an argument in the in_illuminance_period_available_show function references the device embedded in the IIO device, not in the i2c client. dev_to_iio_dev() must be used to accessthe right data. The current implementation leads to a segmentation fault on every attempt to read the attribute because indio_dev gets a NULL assignment. This bug has been present since the first appearance of the driver, apparently since the last version (V6) before getting applied. A constant attribute was used until then, and the last modifications might have not been tested again.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50201", "url": "https://ubuntu.com/security/CVE-2024-50201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: Fix encoder->possible_clones Include the encoder itself in its possible_clones bitmask. In the past nothing validated that drivers were populating possible_clones correctly, but that changed in commit 74d2aacbe840 (\"drm: Validate encoder->possible_clones\"). Looks like radeon never got the memo and is still not following the rules 100% correctly. This results in some warnings during driver initialization: Bogus possible_clones: [ENCODER:46:TV-46] possible_clones=0x4 (full encoder mask=0x7) WARNING: CPU: 0 PID: 170 at drivers/gpu/drm/drm_mode_config.c:615 drm_mode_config_validate+0x113/0x39c ... (cherry picked from commit 3b6e7d40649c0d75572039aff9d0911864c689db)", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50098", "url": "https://ubuntu.com/security/CVE-2024-50098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Set SDEV_OFFLINE when UFS is shut down There is a history of deadlock if reboot is performed at the beginning of booting. SDEV_QUIESCE was set for all LU's scsi_devices by UFS shutdown, and at that time the audio driver was waiting on blk_mq_submit_bio() holding a mutex_lock while reading the fw binary. After that, a deadlock issue occurred while audio driver shutdown was waiting for mutex_unlock of blk_mq_submit_bio(). To solve this, set SDEV_OFFLINE for all LUs except WLUN, so that any I/O that comes down after a UFS shutdown will return an error. [ 31.907781]I[0: swapper/0: 0] 1 130705007 1651079834 11289729804 0 D( 2) 3 ffffff882e208000 * init [device_shutdown] [ 31.907793]I[0: swapper/0: 0] Mutex: 0xffffff8849a2b8b0: owner[0xffffff882e28cb00 kworker/6:0 :49] [ 31.907806]I[0: swapper/0: 0] Call trace: [ 31.907810]I[0: swapper/0: 0] __switch_to+0x174/0x338 [ 31.907819]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc [ 31.907826]I[0: swapper/0: 0] schedule+0x7c/0xe8 [ 31.907834]I[0: swapper/0: 0] schedule_preempt_disabled+0x24/0x40 [ 31.907842]I[0: swapper/0: 0] __mutex_lock+0x408/0xdac [ 31.907849]I[0: swapper/0: 0] __mutex_lock_slowpath+0x14/0x24 [ 31.907858]I[0: swapper/0: 0] mutex_lock+0x40/0xec [ 31.907866]I[0: swapper/0: 0] device_shutdown+0x108/0x280 [ 31.907875]I[0: swapper/0: 0] kernel_restart+0x4c/0x11c [ 31.907883]I[0: swapper/0: 0] __arm64_sys_reboot+0x15c/0x280 [ 31.907890]I[0: swapper/0: 0] invoke_syscall+0x70/0x158 [ 31.907899]I[0: swapper/0: 0] el0_svc_common+0xb4/0xf4 [ 31.907909]I[0: swapper/0: 0] do_el0_svc+0x2c/0xb0 [ 31.907918]I[0: swapper/0: 0] el0_svc+0x34/0xe0 [ 31.907928]I[0: swapper/0: 0] el0t_64_sync_handler+0x68/0xb4 [ 31.907937]I[0: swapper/0: 0] el0t_64_sync+0x1a0/0x1a4 [ 31.908774]I[0: swapper/0: 0] 49 0 11960702 11236868007 0 D( 2) 6 ffffff882e28cb00 * kworker/6:0 [__bio_queue_enter] [ 31.908783]I[0: swapper/0: 0] Call trace: [ 31.908788]I[0: swapper/0: 0] __switch_to+0x174/0x338 [ 31.908796]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc [ 31.908803]I[0: swapper/0: 0] schedule+0x7c/0xe8 [ 31.908811]I[0: swapper/0: 0] __bio_queue_enter+0xb8/0x178 [ 31.908818]I[0: swapper/0: 0] blk_mq_submit_bio+0x194/0x67c [ 31.908827]I[0: swapper/0: 0] __submit_bio+0xb8/0x19c", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50079", "url": "https://ubuntu.com/security/CVE-2024-50079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/sqpoll: ensure task state is TASK_RUNNING when running task_work When the sqpoll is exiting and cancels pending work items, it may need to run task_work. If this happens from within io_uring_cancel_generic(), then it may be under waiting for the io_uring_task waitqueue. This results in the below splat from the scheduler, as the ring mutex may be attempted grabbed while in a TASK_INTERRUPTIBLE state. Ensure that the task state is set appropriately for that, just like what is done for the other cases in io_run_task_work(). do not call blocking ops when !TASK_RUNNING; state=1 set at [<0000000029387fd2>] prepare_to_wait+0x88/0x2fc WARNING: CPU: 6 PID: 59939 at kernel/sched/core.c:8561 __might_sleep+0xf4/0x140 Modules linked in: CPU: 6 UID: 0 PID: 59939 Comm: iou-sqp-59938 Not tainted 6.12.0-rc3-00113-g8d020023b155 #7456 Hardware name: linux,dummy-virt (DT) pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : __might_sleep+0xf4/0x140 lr : __might_sleep+0xf4/0x140 sp : ffff80008c5e7830 x29: ffff80008c5e7830 x28: ffff0000d93088c0 x27: ffff60001c2d7230 x26: dfff800000000000 x25: ffff0000e16b9180 x24: ffff80008c5e7a50 x23: 1ffff000118bcf4a x22: ffff0000e16b9180 x21: ffff0000e16b9180 x20: 000000000000011b x19: ffff80008310fac0 x18: 1ffff000118bcd90 x17: 30303c5b20746120 x16: 74657320313d6574 x15: 0720072007200720 x14: 0720072007200720 x13: 0720072007200720 x12: ffff600036c64f0b x11: 1fffe00036c64f0a x10: ffff600036c64f0a x9 : dfff800000000000 x8 : 00009fffc939b0f6 x7 : ffff0001b6327853 x6 : 0000000000000001 x5 : ffff0001b6327850 x4 : ffff600036c64f0b x3 : ffff8000803c35bc x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000e16b9180 Call trace: __might_sleep+0xf4/0x140 mutex_lock+0x84/0x124 io_handle_tw_list+0xf4/0x260 tctx_task_work_run+0x94/0x340 io_run_task_work+0x1ec/0x3c0 io_uring_cancel_generic+0x364/0x524 io_sq_thread+0x820/0x124c ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50080", "url": "https://ubuntu.com/security/CVE-2024-50080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: don't allow user copy for unprivileged device UBLK_F_USER_COPY requires userspace to call write() on ublk char device for filling request buffer, and unprivileged device can't be trusted. So don't allow user copy for unprivileged device.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50081", "url": "https://ubuntu.com/security/CVE-2024-50081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-mq: setup queue ->tag_set before initializing hctx Commit 7b815817aa58 (\"blk-mq: add helper for checking if one CPU is mapped to specified hctx\") needs to check queue mapping via tag set in hctx's cpuhp handler. However, q->tag_set may not be setup yet when the cpuhp handler is enabled, then kernel oops is triggered. Fix the issue by setup queue tag_set before initializing hctx.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50082", "url": "https://ubuntu.com/security/CVE-2024-50082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race We're seeing crashes from rq_qos_wake_function that look like this: BUG: unable to handle page fault for address: ffffafe180a40084 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 100000067 P4D 100000067 PUD 10027c067 PMD 10115d067 PTE 0 Oops: Oops: 0002 [#1] PREEMPT SMP PTI CPU: 17 UID: 0 PID: 0 Comm: swapper/17 Not tainted 6.12.0-rc3-00013-geca631b8fe80 #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:_raw_spin_lock_irqsave+0x1d/0x40 Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 9c 41 5c fa 65 ff 05 62 97 30 4c 31 c0 ba 01 00 00 00 0f b1 17 75 0a 4c 89 e0 41 5c c3 cc cc cc cc 89 c6 e8 2c 0b 00 RSP: 0018:ffffafe180580ca0 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffffafe180a3f7a8 RCX: 0000000000000011 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffffafe180a40084 RBP: 0000000000000000 R08: 00000000001e7240 R09: 0000000000000011 R10: 0000000000000028 R11: 0000000000000888 R12: 0000000000000002 R13: ffffafe180a40084 R14: 0000000000000000 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff9aaf1f280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffafe180a40084 CR3: 000000010e428002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: try_to_wake_up+0x5a/0x6a0 rq_qos_wake_function+0x71/0x80 __wake_up_common+0x75/0xa0 __wake_up+0x36/0x60 scale_up.part.0+0x50/0x110 wb_timer_fn+0x227/0x450 ... So rq_qos_wake_function() calls wake_up_process(data->task), which calls try_to_wake_up(), which faults in raw_spin_lock_irqsave(&p->pi_lock). p comes from data->task, and data comes from the waitqueue entry, which is stored on the waiter's stack in rq_qos_wait(). Analyzing the core dump with drgn, I found that the waiter had already woken up and moved on to a completely unrelated code path, clobbering what was previously data->task. Meanwhile, the waker was passing the clobbered garbage in data->task to wake_up_process(), leading to the crash. What's happening is that in between rq_qos_wake_function() deleting the waitqueue entry and calling wake_up_process(), rq_qos_wait() is finding that it already got a token and returning. The race looks like this: rq_qos_wait() rq_qos_wake_function() ============================================================== prepare_to_wait_exclusive() data->got_token = true; list_del_init(&curr->entry); if (data.got_token) break; finish_wait(&rqw->wait, &data.wq); ^- returns immediately because list_empty_careful(&wq_entry->entry) is true ... return, go do something else ... wake_up_process(data->task) (NO LONGER VALID!)-^ Normally, finish_wait() is supposed to synchronize against the waker. But, as noted above, it is returning immediately because the waitqueue entry has already been removed from the waitqueue. The bug is that rq_qos_wake_function() is accessing the waitqueue entry AFTER deleting it. Note that autoremove_wake_function() wakes the waiter and THEN deletes the waitqueue entry, which is the proper order. Fix it by swapping the order. We also need to use list_del_init_careful() to match the list_empty_careful() in finish_wait().", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50101", "url": "https://ubuntu.com/security/CVE-2024-50101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI devices Previously, the domain_context_clear() function incorrectly called pci_for_each_dma_alias() to set up context entries for non-PCI devices. This could lead to kernel hangs or other unexpected behavior. Add a check to only call pci_for_each_dma_alias() for PCI devices. For non-PCI devices, domain_context_clear_one() is called directly.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50083", "url": "https://ubuntu.com/security/CVE-2024-50083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix mptcp DSS corruption due to large pmtu xmit Syzkaller was able to trigger a DSS corruption: TCP: request_sock_subflow_v4: Possible SYN flooding on port [::]:20002. Sending cookies. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 5227 at net/mptcp/protocol.c:695 __mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695 Modules linked in: CPU: 0 UID: 0 PID: 5227 Comm: syz-executor350 Not tainted 6.11.0-syzkaller-08829-gaf9c191ac2a0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:__mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695 Code: 0f b6 dc 31 ff 89 de e8 b5 dd ea f5 89 d8 48 81 c4 50 01 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 98 da ea f5 90 <0f> 0b 90 e9 47 ff ff ff e8 8a da ea f5 90 0f 0b 90 e9 99 e0 ff ff RSP: 0018:ffffc90000006db8 EFLAGS: 00010246 RAX: ffffffff8ba9df18 RBX: 00000000000055f0 RCX: ffff888030023c00 RDX: 0000000000000100 RSI: 00000000000081e5 RDI: 00000000000055f0 RBP: 1ffff110062bf1ae R08: ffffffff8ba9cf12 R09: 1ffff110062bf1b8 R10: dffffc0000000000 R11: ffffed10062bf1b9 R12: 0000000000000000 R13: dffffc0000000000 R14: 00000000700cec61 R15: 00000000000081e5 FS: 000055556679c380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020287000 CR3: 0000000077892000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: move_skbs_to_msk net/mptcp/protocol.c:811 [inline] mptcp_data_ready+0x29c/0xa90 net/mptcp/protocol.c:854 subflow_data_ready+0x34a/0x920 net/mptcp/subflow.c:1490 tcp_data_queue+0x20fd/0x76c0 net/ipv4/tcp_input.c:5283 tcp_rcv_established+0xfba/0x2020 net/ipv4/tcp_input.c:6237 tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915 tcp_v4_rcv+0x2dc0/0x37f0 net/ipv4/tcp_ipv4.c:2350 ip_protocol_deliver_rcu+0x22e/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x341/0x5f0 net/ipv4/ip_input.c:233 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314 __netif_receive_skb_one_core net/core/dev.c:5662 [inline] __netif_receive_skb+0x2bf/0x650 net/core/dev.c:5775 process_backlog+0x662/0x15b0 net/core/dev.c:6107 __napi_poll+0xcb/0x490 net/core/dev.c:6771 napi_poll net/core/dev.c:6840 [inline] net_rx_action+0x89b/0x1240 net/core/dev.c:6962 handle_softirqs+0x2c5/0x980 kernel/softirq.c:554 do_softirq+0x11b/0x1e0 kernel/softirq.c:455 __local_bh_enable_ip+0x1bb/0x200 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0x1764/0x3e80 net/core/dev.c:4451 dev_queue_xmit include/linux/netdevice.h:3094 [inline] neigh_hh_output include/net/neighbour.h:526 [inline] neigh_output include/net/neighbour.h:540 [inline] ip_finish_output2+0xd41/0x1390 net/ipv4/ip_output.c:236 ip_local_out net/ipv4/ip_output.c:130 [inline] __ip_queue_xmit+0x118c/0x1b80 net/ipv4/ip_output.c:536 __tcp_transmit_skb+0x2544/0x3b30 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_mtu_probe net/ipv4/tcp_output.c:2547 [inline] tcp_write_xmit+0x641d/0x6bf0 net/ipv4/tcp_output.c:2752 __tcp_push_pending_frames+0x9b/0x360 net/ipv4/tcp_output.c:3015 tcp_push_pending_frames include/net/tcp.h:2107 [inline] tcp_data_snd_check net/ipv4/tcp_input.c:5714 [inline] tcp_rcv_established+0x1026/0x2020 net/ipv4/tcp_input.c:6239 tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915 sk_backlog_rcv include/net/sock.h:1113 [inline] __release_sock+0x214/0x350 net/core/sock.c:3072 release_sock+0x61/0x1f0 net/core/sock.c:3626 mptcp_push_ ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50068", "url": "https://ubuntu.com/security/CVE-2024-50068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/tests/sysfs-kunit.h: fix memory leak in damon_sysfs_test_add_targets() The sysfs_target->regions allocated in damon_sysfs_regions_alloc() is not freed in damon_sysfs_test_add_targets(), which cause the following memory leak, free it to fix it. \tunreferenced object 0xffffff80c2a8db80 (size 96): \t comm \"kunit_try_catch\", pid 187, jiffies 4294894363 \t hex dump (first 32 bytes): \t 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ \t 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ \t backtrace (crc 0): \t [<0000000001e3714d>] kmemleak_alloc+0x34/0x40 \t [<000000008e6835c1>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000001286d9f8>] damon_sysfs_test_add_targets+0x1cc/0x738 \t [<0000000032ef8f77>] kunit_try_run_case+0x13c/0x3ac \t [<00000000f3edea23>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000adf936cf>] kthread+0x2e8/0x374 \t [<0000000041bb1628>] ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50199", "url": "https://ubuntu.com/security/CVE-2024-50199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/swapfile: skip HugeTLB pages for unuse_vma I got a bad pud error and lost a 1GB HugeTLB when calling swapoff. The problem can be reproduced by the following steps: 1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory. 2. Swapout the above anonymous memory. 3. run swapoff and we will get a bad pud error in kernel message: mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7) We can tell that pud_clear_bad is called by pud_none_or_clear_bad in unuse_pud_range() by ftrace. And therefore the HugeTLB pages will never be freed because we lost it from page table. We can skip HugeTLB pages for unuse_vma to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50066", "url": "https://ubuntu.com/security/CVE-2024-50066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mremap: fix move_normal_pmd/retract_page_tables race In mremap(), move_page_tables() looks at the type of the PMD entry and the specified address range to figure out by which method the next chunk of page table entries should be moved. At that point, the mmap_lock is held in write mode, but no rmap locks are held yet. For PMD entries that point to page tables and are fully covered by the source address range, move_pgt_entry(NORMAL_PMD, ...) is called, which first takes rmap locks, then does move_normal_pmd(). move_normal_pmd() takes the necessary page table locks at source and destination, then moves an entire page table from the source to the destination. The problem is: The rmap locks, which protect against concurrent page table removal by retract_page_tables() in the THP code, are only taken after the PMD entry has been read and it has been decided how to move it. So we can race as follows (with two processes that have mappings of the same tmpfs file that is stored on a tmpfs mount with huge=advise); note that process A accesses page tables through the MM while process B does it through the file rmap: process A process B ========= ========= mremap mremap_to move_vma move_page_tables get_old_pmd alloc_new_pmd *** PREEMPT *** madvise(MADV_COLLAPSE) do_madvise madvise_walk_vmas madvise_vma_behavior madvise_collapse hpage_collapse_scan_file collapse_file retract_page_tables i_mmap_lock_read(mapping) pmdp_collapse_flush i_mmap_unlock_read(mapping) move_pgt_entry(NORMAL_PMD, ...) take_rmap_locks move_normal_pmd drop_rmap_locks When this happens, move_normal_pmd() can end up creating bogus PMD entries in the line `pmd_populate(mm, new_pmd, pmd_pgtable(pmd))`. The effect depends on arch-specific and machine-specific details; on x86, you can end up with physical page 0 mapped as a page table, which is likely exploitable for user->kernel privilege escalation. Fix the race by letting process B recheck that the PMD still points to a page table after the rmap locks have been taken. Otherwise, we bail and let the caller fall back to the PTE-level copying path, which will then bail immediately at the pmd_none() check. Bug reachability: Reaching this bug requires that you can create shmem/file THP mappings - anonymous THP uses different code that doesn't zap stuff under rmap locks. File THP is gated on an experimental config flag (CONFIG_READ_ONLY_THP_FOR_FS), so on normal distro kernels you need shmem THP to hit this bug. As far as I know, getting shmem THP normally requires that you can mount your own tmpfs with the right mount flags, which would require creating your own user+mount namespace; though I don't know if some distros maybe enable shmem THP by default or something like that. Bug impact: This issue can likely be used for user->kernel privilege escalation when it is reachable.", "cve_priority": "medium", "cve_public_date": "2024-10-23 06:15:00 UTC" }, { "cve": "CVE-2024-50202", "url": "https://ubuntu.com/security/CVE-2024-50202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: propagate directory read errors from nilfs_find_entry() Syzbot reported that a task hang occurs in vcs_open() during a fuzzing test for nilfs2. The root cause of this problem is that in nilfs_find_entry(), which searches for directory entries, ignores errors when loading a directory page/folio via nilfs_get_folio() fails. If the filesystem images is corrupted, and the i_size of the directory inode is large, and the directory page/folio is successfully read but fails the sanity check, for example when it is zero-filled, nilfs_check_folio() may continue to spit out error messages in bursts. Fix this issue by propagating the error to the callers when loading a page/folio fails in nilfs_find_entry(). The current interface of nilfs_find_entry() and its callers is outdated and cannot propagate error codes such as -EIO and -ENOMEM returned via nilfs_find_entry(), so fix it together.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50200", "url": "https://ubuntu.com/security/CVE-2024-50200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: maple_tree: correct tree corruption on spanning store Patch series \"maple_tree: correct tree corruption on spanning store\", v3. There has been a nasty yet subtle maple tree corruption bug that appears to have been in existence since the inception of the algorithm. This bug seems far more likely to happen since commit f8d112a4e657 (\"mm/mmap: avoid zeroing vma tree in mmap_region()\"), which is the point at which reports started to be submitted concerning this bug. We were made definitely aware of the bug thanks to the kind efforts of Bert Karwatzki who helped enormously in my being able to track this down and identify the cause of it. The bug arises when an attempt is made to perform a spanning store across two leaf nodes, where the right leaf node is the rightmost child of the shared parent, AND the store completely consumes the right-mode node. This results in mas_wr_spanning_store() mitakenly duplicating the new and existing entries at the maximum pivot within the range, and thus maple tree corruption. The fix patch corrects this by detecting this scenario and disallowing the mistaken duplicate copy. The fix patch commit message goes into great detail as to how this occurs. This series also includes a test which reliably reproduces the issue, and asserts that the fix works correctly. Bert has kindly tested the fix and confirmed it resolved his issues. Also Mikhail Gavrilov kindly reported what appears to be precisely the same bug, which this fix should also resolve. This patch (of 2): There has been a subtle bug present in the maple tree implementation from its inception. This arises from how stores are performed - when a store occurs, it will overwrite overlapping ranges and adjust the tree as necessary to accommodate this. A range may always ultimately span two leaf nodes. In this instance we walk the two leaf nodes, determine which elements are not overwritten to the left and to the right of the start and end of the ranges respectively and then rebalance the tree to contain these entries and the newly inserted one. This kind of store is dubbed a 'spanning store' and is implemented by mas_wr_spanning_store(). In order to reach this stage, mas_store_gfp() invokes mas_wr_preallocate(), mas_wr_store_type() and mas_wr_walk() in turn to walk the tree and update the object (mas) to traverse to the location where the write should be performed, determining its store type. When a spanning store is required, this function returns false stopping at the parent node which contains the target range, and mas_wr_store_type() marks the mas->store_type as wr_spanning_store to denote this fact. When we go to perform the store in mas_wr_spanning_store(), we first determine the elements AFTER the END of the range we wish to store (that is, to the right of the entry to be inserted) - we do this by walking to the NEXT pivot in the tree (i.e. r_mas.last + 1), starting at the node we have just determined contains the range over which we intend to write. We then turn our attention to the entries to the left of the entry we are inserting, whose state is represented by l_mas, and copy these into a 'big node', which is a special node which contains enough slots to contain two leaf node's worth of data. We then copy the entry we wish to store immediately after this - the copy and the insertion of the new entry is performed by mas_store_b_node(). After this we copy the elements to the right of the end of the range which we are inserting, if we have not exceeded the length of the node (i.e. r_mas.offset <= r_mas.end). Herein lies the bug - under very specific circumstances, this logic can break and corrupt the maple tree. Consider the following tree: Height 0 Root Node / \\ pivot = 0xffff / \\ pivot = ULONG_MAX / ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50084", "url": "https://ubuntu.com/security/CVE-2024-50084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: microchip: vcap api: Fix memory leaks in vcap_api_encode_rule_test() Commit a3c1e45156ad (\"net: microchip: vcap: Fix use-after-free error in kunit test\") fixed the use-after-free error, but introduced below memory leaks by removing necessary vcap_free_rule(), add it to fix it. \tunreferenced object 0xffffff80ca58b700 (size 192): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898264 \t hex dump (first 32 bytes): \t 00 12 7a 00 05 00 00 00 0a 00 00 00 64 00 00 00 ..z.........d... \t 00 00 00 00 00 00 00 00 00 04 0b cc 80 ff ff ff ................ \t backtrace (crc 9c09c3fe): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<0000000040a01b8d>] vcap_alloc_rule+0x3cc/0x9c4 \t [<000000003fe86110>] vcap_api_encode_rule_test+0x1ac/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0400 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898265 \t hex dump (first 32 bytes): \t 80 04 0b cc 80 ff ff ff 18 b7 58 ca 80 ff ff ff ..........X..... \t 39 00 00 00 02 00 00 00 06 05 04 03 02 01 ff ff 9............... \t backtrace (crc daf014e9): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<00000000dfdb1e81>] vcap_api_encode_rule_test+0x224/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0700 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898265 \t hex dump (first 32 bytes): \t 80 07 0b cc 80 ff ff ff 28 b7 58 ca 80 ff ff ff ........(.X..... \t 3c 00 00 00 00 00 00 00 01 2f 03 b3 ec ff ff ff <......../...... \t backtrace (crc 8d877792): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000006eadfab7>] vcap_rule_add_action+0x2d0/0x52c \t [<00000000323475d1>] vcap_api_encode_rule_test+0x4d4/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0900 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898266 \t hex dump (first 32 bytes): \t 80 09 0b cc 80 ff ff ff 80 06 0b cc 80 ff ff ff ................ \t 7d 00 00 00 01 00 00 00 00 00 00 00 ff 00 00 00 }............... \t backtrace (crc 34181e56): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<00000000991e3564>] vcap_val_rule+0xcf0/0x13e8 \t [<00000000fc9868e5>] vcap_api_encode_rule_test+0x678/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0980 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898266 \t hex dump (first 32 bytes): \t 18 b7 58 ca 80 ff ff ff 00 09 0b cc 80 ff ff ff ..X............. \t 67 00 00 00 00 00 00 00 01 01 74 88 c0 ff ff ff g.........t..... \t backtrace (crc 275fd9be): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<000000001396a1a2>] test_add_de ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50194", "url": "https://ubuntu.com/security/CVE-2024-50194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Fix uprobes for big-endian kernels The arm64 uprobes code is broken for big-endian kernels as it doesn't convert the in-memory instruction encoding (which is always little-endian) into the kernel's native endianness before analyzing and simulating instructions. This may result in a few distinct problems: * The kernel may may erroneously reject probing an instruction which can safely be probed. * The kernel may erroneously erroneously permit stepping an instruction out-of-line when that instruction cannot be stepped out-of-line safely. * The kernel may erroneously simulate instruction incorrectly dur to interpretting the byte-swapped encoding. The endianness mismatch isn't caught by the compiler or sparse because: * The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so the compiler and sparse have no idea these contain a little-endian 32-bit value. The core uprobes code populates these with a memcpy() which similarly does not handle endianness. * While the uprobe_opcode_t type is an alias for __le32, both arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[] to the similarly-named probe_opcode_t, which is an alias for u32. Hence there is no endianness conversion warning. Fix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and adding the appropriate __le32_to_cpu() conversions prior to consuming the instruction encoding. The core uprobes copies these fields as opaque ranges of bytes, and so is unaffected by this change. At the same time, remove MAX_UINSN_BYTES and consistently use AARCH64_INSN_SIZE for clarity. Tested with the following: | #include | #include | | #define noinline __attribute__((noinline)) | | static noinline void *adrp_self(void) | { | void *addr; | | asm volatile( | \" adrp %x0, adrp_self\\n\" | \" add %x0, %x0, :lo12:adrp_self\\n\" | : \"=r\" (addr)); | } | | | int main(int argc, char *argv) | { | void *ptr = adrp_self(); | bool equal = (ptr == adrp_self); | | printf(\"adrp_self => %p\\n\" | \"adrp_self() => %p\\n\" | \"%s\\n\", | adrp_self, ptr, equal ? \"EQUAL\" : \"NOT EQUAL\"); | | return 0; | } .... where the adrp_self() function was compiled to: | 00000000004007e0 : | 4007e0: 90000000 adrp x0, 400000 <__ehdr_start> | 4007e4: 911f8000 add x0, x0, #0x7e0 | 4007e8: d65f03c0 ret Before this patch, the ADRP is not recognized, and is assumed to be steppable, resulting in corruption of the result: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0xffffffffff7e0 | NOT EQUAL After this patch, the ADRP is correctly recognized and simulated: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50099", "url": "https://ubuntu.com/security/CVE-2024-50099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Remove broken LDR (literal) uprobe support The simulate_ldr_literal() and simulate_ldrsw_literal() functions are unsafe to use for uprobes. Both functions were originally written for use with kprobes, and access memory with plain C accesses. When uprobes was added, these were reused unmodified even though they cannot safely access user memory. There are three key problems: 1) The plain C accesses do not have corresponding extable entries, and thus if they encounter a fault the kernel will treat these as unintentional accesses to user memory, resulting in a BUG() which will kill the kernel thread, and likely lead to further issues (e.g. lockup or panic()). 2) The plain C accesses are subject to HW PAN and SW PAN, and so when either is in use, any attempt to simulate an access to user memory will fault. Thus neither simulate_ldr_literal() nor simulate_ldrsw_literal() can do anything useful when simulating a user instruction on any system with HW PAN or SW PAN. 3) The plain C accesses are privileged, as they run in kernel context, and in practice can access a small range of kernel virtual addresses. The instructions they simulate have a range of +/-1MiB, and since the simulated instructions must itself be a user instructions in the TTBR0 address range, these can address the final 1MiB of the TTBR1 acddress range by wrapping downwards from an address in the first 1MiB of the TTBR0 address range. In contemporary kernels the last 8MiB of TTBR1 address range is reserved, and accesses to this will always fault, meaning this is no worse than (1). Historically, it was theoretically possible for the linear map or vmemmap to spill into the final 8MiB of the TTBR1 address range, but in practice this is extremely unlikely to occur as this would require either: * Having enough physical memory to fill the entire linear map all the way to the final 1MiB of the TTBR1 address range. * Getting unlucky with KASLR randomization of the linear map such that the populated region happens to overlap with the last 1MiB of the TTBR address range. ... and in either case if we were to spill into the final page there would be larger problems as the final page would alias with error pointers. Practically speaking, (1) and (2) are the big issues. Given there have been no reports of problems since the broken code was introduced, it appears that no-one is relying on probing these instructions with uprobes. Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW (literal), limiting the use of simulate_ldr_literal() and simulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR (literal) and LDRSW (literal) will be rejected as arm_probe_decode_insn() will return INSN_REJECTED. In future we can consider introducing working uprobes support for these instructions, but this will require more significant work.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50195", "url": "https://ubuntu.com/security/CVE-2024-50195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-clock: Fix missing timespec64 check in pc_clock_settime() As Andrew pointed out, it will make sense that the PTP core checked timespec64 struct's tv_sec and tv_nsec range before calling ptp->info->settime64(). As the man manual of clock_settime() said, if tp.tv_sec is negative or tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL, which include dynamic clocks which handles PTP clock, and the condition is consistent with timespec64_valid(). As Thomas suggested, timespec64_valid() only check the timespec is valid, but not ensure that the time is in a valid range, so check it ahead using timespec64_valid_strict() in pc_clock_settime() and return -EINVAL if not valid. There are some drivers that use tp->tv_sec and tp->tv_nsec directly to write registers without validity checks and assume that the higher layer has checked it, which is dangerous and will benefit from this, such as hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(), and some drivers can remove the checks of itself.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50085", "url": "https://ubuntu.com/security/CVE-2024-50085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: fix UaF read in mptcp_pm_nl_rm_addr_or_subflow Syzkaller reported this splat: ================================================================== BUG: KASAN: slab-use-after-free in mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881 Read of size 4 at addr ffff8880569ac858 by task syz.1.2799/14662 CPU: 0 UID: 0 PID: 14662 Comm: syz.1.2799 Not tainted 6.12.0-rc2-syzkaller-00307-g36c254515dc6 #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+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881 mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:914 [inline] mptcp_nl_remove_id_zero_address+0x305/0x4a0 net/mptcp/pm_netlink.c:1572 mptcp_pm_nl_del_addr_doit+0x5c9/0x770 net/mptcp/pm_netlink.c:1603 genl_family_rcv_msg_doit+0x202/0x2f0 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x565/0x800 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x165/0x410 net/netlink/af_netlink.c:2551 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1331 [inline] netlink_unicast+0x53c/0x7f0 net/netlink/af_netlink.c:1357 netlink_sendmsg+0x8b8/0xd70 net/netlink/af_netlink.c:1901 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg net/socket.c:744 [inline] ____sys_sendmsg+0x9ae/0xb40 net/socket.c:2607 ___sys_sendmsg+0x135/0x1e0 net/socket.c:2661 __sys_sendmsg+0x117/0x1f0 net/socket.c:2690 do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline] __do_fast_syscall_32+0x73/0x120 arch/x86/entry/common.c:386 do_fast_syscall_32+0x32/0x80 arch/x86/entry/common.c:411 entry_SYSENTER_compat_after_hwframe+0x84/0x8e RIP: 0023:0xf7fe4579 Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00 RSP: 002b:00000000f574556c EFLAGS: 00000296 ORIG_RAX: 0000000000000172 RAX: ffffffffffffffda RBX: 000000000000000b RCX: 0000000020000140 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000296 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Allocated by task 5387: 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 kmalloc_noprof include/linux/slab.h:878 [inline] kzalloc_noprof include/linux/slab.h:1014 [inline] subflow_create_ctx+0x87/0x2a0 net/mptcp/subflow.c:1803 subflow_ulp_init+0xc3/0x4d0 net/mptcp/subflow.c:1956 __tcp_set_ulp net/ipv4/tcp_ulp.c:146 [inline] tcp_set_ulp+0x326/0x7f0 net/ipv4/tcp_ulp.c:167 mptcp_subflow_create_socket+0x4ae/0x10a0 net/mptcp/subflow.c:1764 __mptcp_subflow_connect+0x3cc/0x1490 net/mptcp/subflow.c:1592 mptcp_pm_create_subflow_or_signal_addr+0xbda/0x23a0 net/mptcp/pm_netlink.c:642 mptcp_pm_nl_fully_established net/mptcp/pm_netlink.c:650 [inline] mptcp_pm_nl_work+0x3a1/0x4f0 net/mptcp/pm_netlink.c:943 mptcp_worker+0x15a/0x1240 net/mptcp/protocol.c:2777 process_one_work+0x958/0x1b30 kernel/workqueue.c:3229 process_scheduled_works kernel/workqueue.c:3310 [inline] worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/ke ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50086", "url": "https://ubuntu.com/security/CVE-2024-50086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix user-after-free from session log off There is racy issue between smb2 session log off and smb2 session setup. It will cause user-after-free from session log off. This add session_lock when setting SMB2_SESSION_EXPIRED and referece count to session struct not to free session while it is being used.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50087", "url": "https://ubuntu.com/security/CVE-2024-50087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix uninitialized pointer free on read_alloc_one_name() error The function read_alloc_one_name() does not initialize the name field of the passed fscrypt_str struct if kmalloc fails to allocate the corresponding buffer. Thus, it is not guaranteed that fscrypt_str.name is initialized when freeing it. This is a follow-up to the linked patch that fixes the remaining instances of the bug introduced by commit e43eec81c516 (\"btrfs: use struct qstr instead of name and namelen pairs\").", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50088", "url": "https://ubuntu.com/security/CVE-2024-50088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix uninitialized pointer free in add_inode_ref() The add_inode_ref() function does not initialize the \"name\" struct when it is declared. If any of the following calls to \"read_one_inode() returns NULL, \tdir = read_one_inode(root, parent_objectid); \tif (!dir) { \t\tret = -ENOENT; \t\tgoto out; \t} \tinode = read_one_inode(root, inode_objectid); \tif (!inode) { \t\tret = -EIO; \t\tgoto out; \t} then \"name.name\" would be freed on \"out\" before being initialized. out: \t... \tkfree(name.name); This issue was reported by Coverity with CID 1526744.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50182", "url": "https://ubuntu.com/security/CVE-2024-50182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: secretmem: disable memfd_secret() if arch cannot set direct map Return -ENOSYS from memfd_secret() syscall if !can_set_direct_map(). This is the case for example on some arm64 configurations, where marking 4k PTEs in the direct map not present can only be done if the direct map is set up at 4k granularity in the first place (as ARM's break-before-make semantics do not easily allow breaking apart large/gigantic pages). More precisely, on arm64 systems with !can_set_direct_map(), set_direct_map_invalid_noflush() is a no-op, however it returns success (0) instead of an error. This means that memfd_secret will seemingly \"work\" (e.g. syscall succeeds, you can mmap the fd and fault in pages), but it does not actually achieve its goal of removing its memory from the direct map. Note that with this patch, memfd_secret() will start erroring on systems where can_set_direct_map() returns false (arm64 with CONFIG_RODATA_FULL_DEFAULT_ENABLED=n, CONFIG_DEBUG_PAGEALLOC=n and CONFIG_KFENCE=n), but that still seems better than the current silent failure. Since CONFIG_RODATA_FULL_DEFAULT_ENABLED defaults to 'y', most arm64 systems actually have a working memfd_secret() and aren't be affected. From going through the iterations of the original memfd_secret patch series, it seems that disabling the syscall in these scenarios was the intended behavior [1] (preferred over having set_direct_map_invalid_noflush return an error as that would result in SIGBUSes at page-fault time), however the check for it got dropped between v16 [2] and v17 [3], when secretmem moved away from CMA allocations. [1]: https://lore.kernel.org/lkml/20201124164930.GK8537@kernel.org/ [2]: https://lore.kernel.org/lkml/20210121122723.3446-11-rppt@kernel.org/#t [3]: https://lore.kernel.org/lkml/20201125092208.12544-10-rppt@kernel.org/", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50019", "url": "https://ubuntu.com/security/CVE-2024-50019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kthread: unpark only parked kthread Calling into kthread unparking unconditionally is mostly harmless when the kthread is already unparked. The wake up is then simply ignored because the target is not in TASK_PARKED state. However if the kthread is per CPU, the wake up is preceded by a call to kthread_bind() which expects the task to be inactive and in TASK_PARKED state, which obviously isn't the case if it is unparked. As a result, calling kthread_stop() on an unparked per-cpu kthread triggers such a warning: \tWARNING: CPU: 0 PID: 11 at kernel/kthread.c:525 __kthread_bind_mask kernel/kthread.c:525 \t \t kthread_stop+0x17a/0x630 kernel/kthread.c:707 \t destroy_workqueue+0x136/0xc40 kernel/workqueue.c:5810 \t wg_destruct+0x1e2/0x2e0 drivers/net/wireguard/device.c:257 \t netdev_run_todo+0xe1a/0x1000 net/core/dev.c:10693 \t default_device_exit_batch+0xa14/0xa90 net/core/dev.c:11769 \t ops_exit_list net/core/net_namespace.c:178 [inline] \t cleanup_net+0x89d/0xcc0 net/core/net_namespace.c:640 \t process_one_work kernel/workqueue.c:3231 [inline] \t process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 \t worker_thread+0x86d/0xd70 kernel/workqueue.c:3393 \t kthread+0x2f0/0x390 kernel/kthread.c:389 \t ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 \t ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 \t Fix this with skipping unecessary unparking while stopping a kthread.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50096", "url": "https://ubuntu.com/security/CVE-2024-50096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/dmem: Fix vulnerability in migrate_to_ram upon copy error The `nouveau_dmem_copy_one` function ensures that the copy push command is sent to the device firmware but does not track whether it was executed successfully. In the case of a copy error (e.g., firmware or hardware failure), the copy push command will be sent via the firmware channel, and `nouveau_dmem_copy_one` will likely report success, leading to the `migrate_to_ram` function returning a dirty HIGH_USER page to the user. This can result in a security vulnerability, as a HIGH_USER page that may contain sensitive or corrupted data could be returned to the user. To prevent this vulnerability, we allocate a zero page. Thus, in case of an error, a non-dirty (zero) page will be returned to the user.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50020", "url": "https://ubuntu.com/security/CVE-2024-50020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix improper handling of refcount in ice_sriov_set_msix_vec_count() This patch addresses an issue with improper reference count handling in the ice_sriov_set_msix_vec_count() function. First, the function calls ice_get_vf_by_id(), which increments the reference count of the vf pointer. If the subsequent call to ice_get_vf_vsi() fails, the function currently returns an error without decrementing the reference count of the vf pointer, leading to a reference count leak. The correct behavior, as implemented in this patch, is to decrement the reference count using ice_put_vf(vf) before returning an error when vsi is NULL. Second, the function calls ice_sriov_get_irqs(), which sets vf->first_vector_idx. If this call returns a negative value, indicating an error, the function returns an error without decrementing the reference count of the vf pointer, resulting in another reference count leak. The patch addresses this by adding a call to ice_put_vf(vf) before returning an error when vf->first_vector_idx < 0. This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and identifying potential mismanagement of reference counts. In this case, the tool flagged the missing decrement operation as a potential issue, leading to this patch.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50021", "url": "https://ubuntu.com/security/CVE-2024-50021", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix improper handling of refcount in ice_dpll_init_rclk_pins() This patch addresses a reference count handling issue in the ice_dpll_init_rclk_pins() function. The function calls ice_dpll_get_pins(), which increments the reference count of the relevant resources. However, if the condition WARN_ON((!vsi || !vsi->netdev)) is met, the function currently returns an error without properly releasing the resources acquired by ice_dpll_get_pins(), leading to a reference count leak. To resolve this, the check has been moved to the top of the function. This ensures that the function verifies the state before any resources are acquired, avoiding the need for additional resource management in the error path. This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and detecting potential issues where resources are not properly managed. In this case, the tool flagged the missing release operation as a potential problem, which led to the development of this patch.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50022", "url": "https://ubuntu.com/security/CVE-2024-50022", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: device-dax: correct pgoff align in dax_set_mapping() pgoff should be aligned using ALIGN_DOWN() instead of ALIGN(). Otherwise, vmf->address not aligned to fault_size will be aligned to the next alignment, that can result in memory failure getting the wrong address. It's a subtle situation that only can be observed in page_mapped_in_vma() after the page is page fault handled by dev_dax_huge_fault. Generally, there is little chance to perform page_mapped_in_vma in dev-dax's page unless in specific error injection to the dax device to trigger an MCE - memory-failure. In that case, page_mapped_in_vma() will be triggered to determine which task is accessing the failure address and kill that task in the end. We used self-developed dax device (which is 2M aligned mapping) , to perform error injection to random address. It turned out that error injected to non-2M-aligned address was causing endless MCE until panic. Because page_mapped_in_vma() kept resulting wrong address and the task accessing the failure address was never killed properly: [ 3783.719419] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.049006] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.049190] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.448042] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.448186] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.792026] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.792179] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.162502] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.162633] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.461116] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.461247] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.764730] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.764859] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.042128] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.042259] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.464293] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.464423] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.818090] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.818217] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3787.085297] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3787.085424] Memory failure: 0x200c9742: recovery action for dax page: Recovered It took us several weeks to pinpoint this problem,  but we eventually used bpftrace to trace the page fault and mce address and successfully identified the issue. Joao added: ; Likely we never reproduce in production because we always pin : device-dax regions in the region align they provide (Qemu does : similarly with prealloc in hugetlb/file backed memory). I think this : bug requires that we touch *unpinned* device-dax regions unaligned to : the device-dax selected alignment (page size i.e. 4K/2M/1G)", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50185", "url": "https://ubuntu.com/security/CVE-2024-50185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: handle consistently DSS corruption Bugged peer implementation can send corrupted DSS options, consistently hitting a few warning in the data path. Use DEBUG_NET assertions, to avoid the splat on some builds and handle consistently the error, dumping related MIBs and performing fallback and/or reset according to the subflow type.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50023", "url": "https://ubuntu.com/security/CVE-2024-50023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: Remove LED entry from LEDs list on unregister Commit c938ab4da0eb (\"net: phy: Manual remove LEDs to ensure correct ordering\") correctly fixed a problem with using devm_ but missed removing the LED entry from the LEDs list. This cause kernel panic on specific scenario where the port for the PHY is torn down and up and the kmod for the PHY is removed. On setting the port down the first time, the assosiacted LEDs are correctly unregistered. The associated kmod for the PHY is now removed. The kmod is now added again and the port is now put up, the associated LED are registered again. On putting the port down again for the second time after these step, the LED list now have 4 elements. With the first 2 already unregistered previously and the 2 new one registered again. This cause a kernel panic as the first 2 element should have been removed. Fix this by correctly removing the element when LED is unregistered.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50024", "url": "https://ubuntu.com/security/CVE-2024-50024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: Fix an unsafe loop on the list The kernel may crash when deleting a genetlink family if there are still listeners for that family: Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c000000000c080bc] netlink_update_socket_mc+0x3c/0xc0 LR [c000000000c0f764] __netlink_clear_multicast_users+0x74/0xc0 Call Trace: __netlink_clear_multicast_users+0x74/0xc0 genl_unregister_family+0xd4/0x2d0 Change the unsafe loop on the list to a safe one, because inside the loop there is an element removal from this list.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50186", "url": "https://ubuntu.com/security/CVE-2024-50186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: explicitly clear the sk pointer, when pf->create fails We have recently noticed the exact same KASAN splat as in commit 6cd4a78d962b (\"net: do not leave a dangling sk pointer, when socket creation fails\"). The problem is that commit did not fully address the problem, as some pf->create implementations do not use sk_common_release in their error paths. For example, we can use the same reproducer as in the above commit, but changing ping to arping. arping uses AF_PACKET socket and if packet_create fails, it will just sk_free the allocated sk object. While we could chase all the pf->create implementations and make sure they NULL the freed sk object on error from the socket, we can't guarantee future protocols will not make the same mistake. So it is easier to just explicitly NULL the sk pointer upon return from pf->create in __sock_create. We do know that pf->create always releases the allocated sk object on error, so if the pointer is not NULL, it is definitely dangling.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50025", "url": "https://ubuntu.com/security/CVE-2024-50025", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: fnic: Move flush_work initialization out of if block After commit 379a58caa199 (\"scsi: fnic: Move fnic_fnic_flush_tx() to a work queue\"), it can happen that a work item is sent to an uninitialized work queue. This may has the effect that the item being queued is never actually queued, and any further actions depending on it will not proceed. The following warning is observed while the fnic driver is loaded: kernel: WARNING: CPU: 11 PID: 0 at ../kernel/workqueue.c:1524 __queue_work+0x373/0x410 kernel: kernel: queue_work_on+0x3a/0x50 kernel: fnic_wq_copy_cmpl_handler+0x54a/0x730 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: fnic_isr_msix_wq_copy+0x2d/0x60 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: __handle_irq_event_percpu+0x36/0x1a0 kernel: handle_irq_event_percpu+0x30/0x70 kernel: handle_irq_event+0x34/0x60 kernel: handle_edge_irq+0x7e/0x1a0 kernel: __common_interrupt+0x3b/0xb0 kernel: common_interrupt+0x58/0xa0 kernel: It has been observed that this may break the rediscovery of Fibre Channel devices after a temporary fabric failure. This patch fixes it by moving the work queue initialization out of an if block in fnic_probe().", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50026", "url": "https://ubuntu.com/security/CVE-2024-50026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: wd33c93: Don't use stale scsi_pointer value A regression was introduced with commit dbb2da557a6a (\"scsi: wd33c93: Move the SCSI pointer to private command data\") which results in an oops in wd33c93_intr(). That commit added the scsi_pointer variable and initialized it from hostdata->connected. However, during selection, hostdata->connected is not yet valid. Fix this by getting the current scsi_pointer from hostdata->selecting.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50027", "url": "https://ubuntu.com/security/CVE-2024-50027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: core: Free tzp copy along with the thermal zone The object pointed to by tz->tzp may still be accessed after being freed in thermal_zone_device_unregister(), so move the freeing of it to the point after the removal completion has been completed at which it cannot be accessed any more.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50028", "url": "https://ubuntu.com/security/CVE-2024-50028", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: core: Reference count the zone in thermal_zone_get_by_id() There are places in the thermal netlink code where nothing prevents the thermal zone object from going away while being accessed after it has been returned by thermal_zone_get_by_id(). To address this, make thermal_zone_get_by_id() get a reference on the thermal zone device object to be returned with the help of get_device(), under thermal_list_lock, and adjust all of its callers to this change with the help of the cleanup.h infrastructure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50029", "url": "https://ubuntu.com/security/CVE-2024-50029", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_conn: Fix UAF in hci_enhanced_setup_sync This checks if the ACL connection remains valid as it could be destroyed while hci_enhanced_setup_sync is pending on cmd_sync leading to the following trace: BUG: KASAN: slab-use-after-free in hci_enhanced_setup_sync+0x91b/0xa60 Read of size 1 at addr ffff888002328ffd by task kworker/u5:2/37 CPU: 0 UID: 0 PID: 37 Comm: kworker/u5:2 Not tainted 6.11.0-rc6-01300-g810be445d8d6 #7099 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Workqueue: hci0 hci_cmd_sync_work Call Trace: dump_stack_lvl+0x5d/0x80 ? hci_enhanced_setup_sync+0x91b/0xa60 print_report+0x152/0x4c0 ? hci_enhanced_setup_sync+0x91b/0xa60 ? __virt_addr_valid+0x1fa/0x420 ? hci_enhanced_setup_sync+0x91b/0xa60 kasan_report+0xda/0x1b0 ? hci_enhanced_setup_sync+0x91b/0xa60 hci_enhanced_setup_sync+0x91b/0xa60 ? __pfx_hci_enhanced_setup_sync+0x10/0x10 ? __pfx___mutex_lock+0x10/0x10 hci_cmd_sync_work+0x1c2/0x330 process_one_work+0x7d9/0x1360 ? __pfx_lock_acquire+0x10/0x10 ? __pfx_process_one_work+0x10/0x10 ? assign_work+0x167/0x240 worker_thread+0x5b7/0xf60 ? __kthread_parkme+0xac/0x1c0 ? __pfx_worker_thread+0x10/0x10 ? __pfx_worker_thread+0x10/0x10 kthread+0x293/0x360 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2f/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 34: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __hci_conn_add+0x187/0x17d0 hci_connect_sco+0x2e1/0xb90 sco_sock_connect+0x2a2/0xb80 __sys_connect+0x227/0x2a0 __x64_sys_connect+0x6d/0xb0 do_syscall_64+0x71/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 37: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x101/0x160 kfree+0xd0/0x250 device_release+0x9a/0x210 kobject_put+0x151/0x280 hci_conn_del+0x448/0xbf0 hci_abort_conn_sync+0x46f/0x980 hci_cmd_sync_work+0x1c2/0x330 process_one_work+0x7d9/0x1360 worker_thread+0x5b7/0xf60 kthread+0x293/0x360 ret_from_fork+0x2f/0x70 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50030", "url": "https://ubuntu.com/security/CVE-2024-50030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/ct: prevent UAF in send_recv() Ensure we serialize with completion side to prevent UAF with fence going out of scope on the stack, since we have no clue if it will fire after the timeout before we can erase from the xa. Also we have some dependent loads and stores for which we need the correct ordering, and we lack the needed barriers. Fix this by grabbing the ct->lock after the wait, which is also held by the completion side. v2 (Badal): - Also print done after acquiring the lock and seeing timeout. (cherry picked from commit 52789ce35c55ccd30c4b67b9cc5b2af55e0122ea)", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50187", "url": "https://ubuntu.com/security/CVE-2024-50187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Stop the active perfmon before being destroyed Upon closing the file descriptor, the active performance monitor is not stopped. Although all perfmons are destroyed in `vc4_perfmon_close_file()`, the active performance monitor's pointer (`vc4->active_perfmon`) is still retained. If we open a new file descriptor and submit a few jobs with performance monitors, the driver will attempt to stop the active performance monitor using the stale pointer in `vc4->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50031", "url": "https://ubuntu.com/security/CVE-2024-50031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Stop the active perfmon before being destroyed When running `kmscube` with one or more performance monitors enabled via `GALLIUM_HUD`, the following kernel panic can occur: [ 55.008324] Unable to handle kernel paging request at virtual address 00000000052004a4 [ 55.008368] Mem abort info: [ 55.008377] ESR = 0x0000000096000005 [ 55.008387] EC = 0x25: DABT (current EL), IL = 32 bits [ 55.008402] SET = 0, FnV = 0 [ 55.008412] EA = 0, S1PTW = 0 [ 55.008421] FSC = 0x05: level 1 translation fault [ 55.008434] Data abort info: [ 55.008442] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 55.008455] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 55.008467] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 55.008481] user pgtable: 4k pages, 39-bit VAs, pgdp=00000001046c6000 [ 55.008497] [00000000052004a4] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 55.008525] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP [ 55.008542] Modules linked in: rfcomm [...] vc4 v3d snd_soc_hdmi_codec drm_display_helper gpu_sched drm_shmem_helper cec drm_dma_helper drm_kms_helper i2c_brcmstb drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight [ 55.008799] CPU: 2 PID: 166 Comm: v3d_bin Tainted: G C 6.6.47+rpt-rpi-v8 #1 Debian 1:6.6.47-1+rpt1 [ 55.008824] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [ 55.008838] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 55.008855] pc : __mutex_lock.constprop.0+0x90/0x608 [ 55.008879] lr : __mutex_lock.constprop.0+0x58/0x608 [ 55.008895] sp : ffffffc080673cf0 [ 55.008904] x29: ffffffc080673cf0 x28: 0000000000000000 x27: ffffff8106188a28 [ 55.008926] x26: ffffff8101e78040 x25: ffffff8101baa6c0 x24: ffffffd9d989f148 [ 55.008947] x23: ffffffda1c2a4008 x22: 0000000000000002 x21: ffffffc080673d38 [ 55.008968] x20: ffffff8101238000 x19: ffffff8104f83188 x18: 0000000000000000 [ 55.008988] x17: 0000000000000000 x16: ffffffda1bd04d18 x15: 00000055bb08bc90 [ 55.009715] x14: 0000000000000000 x13: 0000000000000000 x12: ffffffda1bd4cbb0 [ 55.010433] x11: 00000000fa83b2da x10: 0000000000001a40 x9 : ffffffda1bd04d04 [ 55.011162] x8 : ffffff8102097b80 x7 : 0000000000000000 x6 : 00000000030a5857 [ 55.011880] x5 : 00ffffffffffffff x4 : 0300000005200470 x3 : 0300000005200470 [ 55.012598] x2 : ffffff8101238000 x1 : 0000000000000021 x0 : 0300000005200470 [ 55.013292] Call trace: [ 55.013959] __mutex_lock.constprop.0+0x90/0x608 [ 55.014646] __mutex_lock_slowpath+0x1c/0x30 [ 55.015317] mutex_lock+0x50/0x68 [ 55.015961] v3d_perfmon_stop+0x40/0xe0 [v3d] [ 55.016627] v3d_bin_job_run+0x10c/0x2d8 [v3d] [ 55.017282] drm_sched_main+0x178/0x3f8 [gpu_sched] [ 55.017921] kthread+0x11c/0x128 [ 55.018554] ret_from_fork+0x10/0x20 [ 55.019168] Code: f9400260 f1001c1f 54001ea9 927df000 (b9403401) [ 55.019776] ---[ end trace 0000000000000000 ]--- [ 55.020411] note: v3d_bin[166] exited with preempt_count 1 This issue arises because, upon closing the file descriptor (which happens when we interrupt `kmscube`), the active performance monitor is not stopped. Although all perfmons are destroyed in `v3d_perfmon_close_file()`, the active performance monitor's pointer (`v3d->active_perfmon`) is still retained. If `kmscube` is run again, the driver will attempt to stop the active performance monitor using the stale pointer in `v3d->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50189", "url": "https://ubuntu.com/security/CVE-2024-50189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: amd_sfh: Switch to device-managed dmam_alloc_coherent() Using the device-managed version allows to simplify clean-up in probe() error path. Additionally, this device-managed ensures proper cleanup, which helps to resolve memory errors, page faults, btrfs going read-only, and btrfs disk corruption.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50033", "url": "https://ubuntu.com/security/CVE-2024-50033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slip: make slhc_remember() more robust against malicious packets syzbot found that slhc_remember() was missing checks against malicious packets [1]. slhc_remember() only checked the size of the packet was at least 20, which is not good enough. We need to make sure the packet includes the IPv4 and TCP header that are supposed to be carried. Add iph and th pointers to make the code more readable. [1] BUG: KMSAN: uninit-value in slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 ppp_receive_nonmp_frame+0xe45/0x35e0 drivers/net/ppp/ppp_generic.c:2455 ppp_receive_frame drivers/net/ppp/ppp_generic.c:2372 [inline] ppp_do_recv+0x65f/0x40d0 drivers/net/ppp/ppp_generic.c:2212 ppp_input+0x7dc/0xe60 drivers/net/ppp/ppp_generic.c:2327 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 Uninit was created at: slab_post_alloc_hook mm/slub.c:4091 [inline] slab_alloc_node mm/slub.c:4134 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 CPU: 0 UID: 0 PID: 5460 Comm: syz.2.33 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50034", "url": "https://ubuntu.com/security/CVE-2024-50034", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix lacks of icsk_syn_mss with IPPROTO_SMC Eric report a panic on IPPROTO_SMC, and give the facts that when INET_PROTOSW_ICSK was set, icsk->icsk_sync_mss must be set too. Bug: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000086000005 EC = 0x21: IABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault user pgtable: 4k pages, 48-bit VAs, pgdp=00000001195d1000 [0000000000000000] pgd=0800000109c46003, p4d=0800000109c46003, pud=0000000000000000 Internal error: Oops: 0000000086000005 [#1] PREEMPT SMP Modules linked in: CPU: 1 UID: 0 PID: 8037 Comm: syz.3.265 Not tainted 6.11.0-rc7-syzkaller-g5f5673607153 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0x0 lr : cipso_v4_sock_setattr+0x2a8/0x3c0 net/ipv4/cipso_ipv4.c:1910 sp : ffff80009b887a90 x29: ffff80009b887aa0 x28: ffff80008db94050 x27: 0000000000000000 x26: 1fffe0001aa6f5b3 x25: dfff800000000000 x24: ffff0000db75da00 x23: 0000000000000000 x22: ffff0000d8b78518 x21: 0000000000000000 x20: ffff0000d537ad80 x19: ffff0000d8b78000 x18: 1fffe000366d79ee x17: ffff8000800614a8 x16: ffff800080569b84 x15: 0000000000000001 x14: 000000008b336894 x13: 00000000cd96feaa x12: 0000000000000003 x11: 0000000000040000 x10: 00000000000020a3 x9 : 1fffe0001b16f0f1 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 000000000000003f x5 : 0000000000000040 x4 : 0000000000000001 x3 : 0000000000000000 x2 : 0000000000000002 x1 : 0000000000000000 x0 : ffff0000d8b78000 Call trace: 0x0 netlbl_sock_setattr+0x2e4/0x338 net/netlabel/netlabel_kapi.c:1000 smack_netlbl_add+0xa4/0x154 security/smack/smack_lsm.c:2593 smack_socket_post_create+0xa8/0x14c security/smack/smack_lsm.c:2973 security_socket_post_create+0x94/0xd4 security/security.c:4425 __sock_create+0x4c8/0x884 net/socket.c:1587 sock_create net/socket.c:1622 [inline] __sys_socket_create net/socket.c:1659 [inline] __sys_socket+0x134/0x340 net/socket.c:1706 __do_sys_socket net/socket.c:1720 [inline] __se_sys_socket net/socket.c:1718 [inline] __arm64_sys_socket+0x7c/0x94 net/socket.c:1718 __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:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 Code: ???????? ???????? ???????? ???????? (????????) ---[ end trace 0000000000000000 ]--- This patch add a toy implementation that performs a simple return to prevent such panic. This is because MSS can be set in sock_create_kern or smc_setsockopt, similar to how it's done in AF_SMC. However, for AF_SMC, there is currently no way to synchronize MSS within __sys_connect_file. This toy implementation lays the groundwork for us to support such feature for IPPROTO_SMC in the future.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50035", "url": "https://ubuntu.com/security/CVE-2024-50035", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: fix ppp_async_encode() illegal access syzbot reported an issue in ppp_async_encode() [1] In this case, pppoe_sendmsg() is called with a zero size. Then ppp_async_encode() is called with an empty skb. BUG: KMSAN: uninit-value in ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] BUG: KMSAN: uninit-value in ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_send+0x130/0x1b0 drivers/net/ppp/ppp_async.c:634 ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2280 [inline] ppp_input+0x1f1/0xe60 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 Uninit was created at: slab_post_alloc_hook mm/slub.c:4092 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4187 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 CPU: 1 UID: 0 PID: 5411 Comm: syz.1.14 Not tainted 6.12.0-rc1-syzkaller-00165-g360c1f1f24c6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50036", "url": "https://ubuntu.com/security/CVE-2024-50036", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: do not delay dst_entries_add() in dst_release() dst_entries_add() uses per-cpu data that might be freed at netns dismantle from ip6_route_net_exit() calling dst_entries_destroy() Before ip6_route_net_exit() can be called, we release all the dsts associated with this netns, via calls to dst_release(), which waits an rcu grace period before calling dst_destroy() dst_entries_add() use in dst_destroy() is racy, because dst_entries_destroy() could have been called already. Decrementing the number of dsts must happen sooner. Notes: 1) in CONFIG_XFRM case, dst_destroy() can call dst_release_immediate(child), this might also cause UAF if the child does not have DST_NOCOUNT set. IPSEC maintainers might take a look and see how to address this. 2) There is also discussion about removing this count of dst, which might happen in future kernels.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50037", "url": "https://ubuntu.com/security/CVE-2024-50037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/fbdev-dma: Only cleanup deferred I/O if necessary Commit 5a498d4d06d6 (\"drm/fbdev-dma: Only install deferred I/O if necessary\") initializes deferred I/O only if it is used. drm_fbdev_dma_fb_destroy() however calls fb_deferred_io_cleanup() unconditionally with struct fb_info.fbdefio == NULL. KASAN with the out-of-tree Apple silicon display driver posts following warning from __flush_work() of a random struct work_struct instead of the expected NULL pointer derefs. [ 22.053799] ------------[ cut here ]------------ [ 22.054832] WARNING: CPU: 2 PID: 1 at kernel/workqueue.c:4177 __flush_work+0x4d8/0x580 [ 22.056597] Modules linked in: uhid bnep uinput nls_ascii ip6_tables ip_tables i2c_dev loop fuse dm_multipath nfnetlink zram hid_magicmouse btrfs xor xor_neon brcmfmac_wcc raid6_pq hci_bcm4377 bluetooth brcmfmac hid_apple brcmutil nvmem_spmi_mfd simple_mfd_spmi dockchannel_hid cfg80211 joydev regmap_spmi nvme_apple ecdh_generic ecc macsmc_hid rfkill dwc3 appledrm snd_soc_macaudio macsmc_power nvme_core apple_isp phy_apple_atc apple_sart apple_rtkit_helper apple_dockchannel tps6598x macsmc_hwmon snd_soc_cs42l84 videobuf2_v4l2 spmi_apple_controller nvmem_apple_efuses videobuf2_dma_sg apple_z2 videobuf2_memops spi_nor panel_summit videobuf2_common asahi videodev pwm_apple apple_dcp snd_soc_apple_mca apple_admac spi_apple clk_apple_nco i2c_pasemi_platform snd_pcm_dmaengine mc i2c_pasemi_core mux_core ofpart adpdrm drm_dma_helper apple_dart apple_soc_cpufreq leds_pwm phram [ 22.073768] CPU: 2 UID: 0 PID: 1 Comm: systemd-shutdow Not tainted 6.11.2-asahi+ #asahi-dev [ 22.075612] Hardware name: Apple MacBook Pro (13-inch, M2, 2022) (DT) [ 22.077032] pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 22.078567] pc : __flush_work+0x4d8/0x580 [ 22.079471] lr : __flush_work+0x54/0x580 [ 22.080345] sp : ffffc000836ef820 [ 22.081089] x29: ffffc000836ef880 x28: 0000000000000000 x27: ffff80002ddb7128 [ 22.082678] x26: dfffc00000000000 x25: 1ffff000096f0c57 x24: ffffc00082d3e358 [ 22.084263] x23: ffff80004b7862b8 x22: dfffc00000000000 x21: ffff80005aa1d470 [ 22.085855] x20: ffff80004b786000 x19: ffff80004b7862a0 x18: 0000000000000000 [ 22.087439] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000005 [ 22.089030] x14: 1ffff800106ddf0a x13: 0000000000000000 x12: 0000000000000000 [ 22.090618] x11: ffffb800106ddf0f x10: dfffc00000000000 x9 : 1ffff800106ddf0e [ 22.092206] x8 : 0000000000000000 x7 : aaaaaaaaaaaaaaaa x6 : 0000000000000001 [ 22.093790] x5 : ffffc000836ef728 x4 : 0000000000000000 x3 : 0000000000000020 [ 22.095368] x2 : 0000000000000008 x1 : 00000000000000aa x0 : 0000000000000000 [ 22.096955] Call trace: [ 22.097505] __flush_work+0x4d8/0x580 [ 22.098330] flush_delayed_work+0x80/0xb8 [ 22.099231] fb_deferred_io_cleanup+0x3c/0x130 [ 22.100217] drm_fbdev_dma_fb_destroy+0x6c/0xe0 [drm_dma_helper] [ 22.101559] unregister_framebuffer+0x210/0x2f0 [ 22.102575] drm_fb_helper_unregister_info+0x48/0x60 [ 22.103683] drm_fbdev_dma_client_unregister+0x4c/0x80 [drm_dma_helper] [ 22.105147] drm_client_dev_unregister+0x1cc/0x230 [ 22.106217] drm_dev_unregister+0x58/0x570 [ 22.107125] apple_drm_unbind+0x50/0x98 [appledrm] [ 22.108199] component_del+0x1f8/0x3a8 [ 22.109042] dcp_platform_shutdown+0x24/0x38 [apple_dcp] [ 22.110357] platform_shutdown+0x70/0x90 [ 22.111219] device_shutdown+0x368/0x4d8 [ 22.112095] kernel_restart+0x6c/0x1d0 [ 22.112946] __arm64_sys_reboot+0x1c8/0x328 [ 22.113868] invoke_syscall+0x78/0x1a8 [ 22.114703] do_el0_svc+0x124/0x1a0 [ 22.115498] el0_svc+0x3c/0xe0 [ 22.116181] el0t_64_sync_handler+0x70/0xc0 [ 22.117110] el0t_64_sync+0x190/0x198 [ 22.117931] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50092", "url": "https://ubuntu.com/security/CVE-2024-50092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netconsole: fix wrong warning A warning is triggered when there is insufficient space in the buffer for userdata. However, this is not an issue since userdata will be sent in the next iteration. Current warning message: ------------[ cut here ]------------ WARNING: CPU: 13 PID: 3013042 at drivers/net/netconsole.c:1122 write_ext_msg+0x3b6/0x3d0 ? write_ext_msg+0x3b6/0x3d0 console_flush_all+0x1e9/0x330 The code incorrectly issues a warning when this_chunk is zero, which is a valid scenario. The warning should only be triggered when this_chunk is negative.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50038", "url": "https://ubuntu.com/security/CVE-2024-50038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xtables: avoid NFPROTO_UNSPEC where needed syzbot managed to call xt_cluster match via ebtables: WARNING: CPU: 0 PID: 11 at net/netfilter/xt_cluster.c:72 xt_cluster_mt+0x196/0x780 [..] ebt_do_table+0x174b/0x2a40 Module registers to NFPROTO_UNSPEC, but it assumes ipv4/ipv6 packet processing. As this is only useful to restrict locally terminating TCP/UDP traffic, register this for ipv4 and ipv6 family only. Pablo points out that this is a general issue, direct users of the set/getsockopt interface can call into targets/matches that were only intended for use with ip(6)tables. Check all UNSPEC matches and targets for similar issues: - matches and targets are fine except if they assume skb_network_header() is valid -- this is only true when called from inet layer: ip(6) stack pulls the ip/ipv6 header into linear data area. - targets that return XT_CONTINUE or other xtables verdicts must be restricted too, they are incompatbile with the ebtables traverser, e.g. EBT_CONTINUE is a completely different value than XT_CONTINUE. Most matches/targets are changed to register for NFPROTO_IPV4/IPV6, as they are provided for use by ip(6)tables. The MARK target is also used by arptables, so register for NFPROTO_ARP too. While at it, bail out if connbytes fails to enable the corresponding conntrack family. This change passes the selftests in iptables.git.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50039", "url": "https://ubuntu.com/security/CVE-2024-50039", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: accept TCA_STAB only for root qdisc Most qdiscs maintain their backlog using qdisc_pkt_len(skb) on the assumption it is invariant between the enqueue() and dequeue() handlers. Unfortunately syzbot can crash a host rather easily using a TBF + SFQ combination, with an STAB on SFQ [1] We can't support TCA_STAB on arbitrary level, this would require to maintain per-qdisc storage. [1] [ 88.796496] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 88.798611] #PF: supervisor read access in kernel mode [ 88.799014] #PF: error_code(0x0000) - not-present page [ 88.799506] PGD 0 P4D 0 [ 88.799829] Oops: Oops: 0000 [#1] SMP NOPTI [ 88.800569] CPU: 14 UID: 0 PID: 2053 Comm: b371744477 Not tainted 6.12.0-rc1-virtme #1117 [ 88.801107] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 88.801779] RIP: 0010:sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq [ 88.802544] Code: 0f b7 50 12 48 8d 04 d5 00 00 00 00 48 89 d6 48 29 d0 48 8b 91 c0 01 00 00 48 c1 e0 03 48 01 c2 66 83 7a 1a 00 7e c0 48 8b 3a <4c> 8b 07 4c 89 02 49 89 50 08 48 c7 47 08 00 00 00 00 48 c7 07 00 All code ======== 0:\t0f b7 50 12 \tmovzwl 0x12(%rax),%edx 4:\t48 8d 04 d5 00 00 00 \tlea 0x0(,%rdx,8),%rax b:\t00 c:\t48 89 d6 \tmov %rdx,%rsi f:\t48 29 d0 \tsub %rdx,%rax 12:\t48 8b 91 c0 01 00 00 \tmov 0x1c0(%rcx),%rdx 19:\t48 c1 e0 03 \tshl $0x3,%rax 1d:\t48 01 c2 \tadd %rax,%rdx 20:\t66 83 7a 1a 00 \tcmpw $0x0,0x1a(%rdx) 25:\t7e c0 \tjle 0xffffffffffffffe7 27:\t48 8b 3a \tmov (%rdx),%rdi 2a:*\t4c 8b 07 \tmov (%rdi),%r8\t\t<-- trapping instruction 2d:\t4c 89 02 \tmov %r8,(%rdx) 30:\t49 89 50 08 \tmov %rdx,0x8(%r8) 34:\t48 c7 47 08 00 00 00 \tmovq $0x0,0x8(%rdi) 3b:\t00 3c:\t48 \trex.W 3d:\tc7 \t.byte 0xc7 3e:\t07 \t(bad) \t... Code starting with the faulting instruction =========================================== 0:\t4c 8b 07 \tmov (%rdi),%r8 3:\t4c 89 02 \tmov %r8,(%rdx) 6:\t49 89 50 08 \tmov %rdx,0x8(%r8) a:\t48 c7 47 08 00 00 00 \tmovq $0x0,0x8(%rdi) 11:\t00 12:\t48 \trex.W 13:\tc7 \t.byte 0xc7 14:\t07 \t(bad) \t... [ 88.803721] RSP: 0018:ffff9a1f892b7d58 EFLAGS: 00000206 [ 88.804032] RAX: 0000000000000000 RBX: ffff9a1f8420c800 RCX: ffff9a1f8420c800 [ 88.804560] RDX: ffff9a1f81bc1440 RSI: 0000000000000000 RDI: 0000000000000000 [ 88.805056] RBP: ffffffffc04bb0e0 R08: 0000000000000001 R09: 00000000ff7f9a1f [ 88.805473] R10: 000000000001001b R11: 0000000000009a1f R12: 0000000000000140 [ 88.806194] R13: 0000000000000001 R14: ffff9a1f886df400 R15: ffff9a1f886df4ac [ 88.806734] FS: 00007f445601a740(0000) GS:ffff9a2e7fd80000(0000) knlGS:0000000000000000 [ 88.807225] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 88.807672] CR2: 0000000000000000 CR3: 000000050cc46000 CR4: 00000000000006f0 [ 88.808165] Call Trace: [ 88.808459] [ 88.808710] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434) [ 88.809261] ? page_fault_oops (arch/x86/mm/fault.c:715) [ 88.809561] ? exc_page_fault (./arch/x86/include/asm/irqflags.h:26 ./arch/x86/include/asm/irqflags.h:87 ./arch/x86/include/asm/irqflags.h:147 arch/x86/mm/fault.c:1489 arch/x86/mm/fault.c:1539) [ 88.809806] ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623) [ 88.810074] ? sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq [ 88.810411] sfq_reset (net/sched/sch_sfq.c:525) sch_sfq [ 88.810671] qdisc_reset (./include/linux/skbuff.h:2135 ./include/linux/skbuff.h:2441 ./include/linux/skbuff.h:3304 ./include/linux/skbuff.h:3310 net/sched/sch_g ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50040", "url": "https://ubuntu.com/security/CVE-2024-50040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: igb: Do not bring the device up after non-fatal error Commit 004d25060c78 (\"igb: Fix igb_down hung on surprise removal\") changed igb_io_error_detected() to ignore non-fatal pcie errors in order to avoid hung task that can happen when igb_down() is called multiple times. This caused an issue when processing transient non-fatal errors. igb_io_resume(), which is called after igb_io_error_detected(), assumes that device is brought down by igb_io_error_detected() if the interface is up. This resulted in panic with stacktrace below. [ T3256] igb 0000:09:00.0 haeth0: igb: haeth0 NIC Link is Down [ T292] pcieport 0000:00:1c.5: AER: Uncorrected (Non-Fatal) error received: 0000:09:00.0 [ T292] igb 0000:09:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, (Requester ID) [ T292] igb 0000:09:00.0: device [8086:1537] error status/mask=00004000/00000000 [ T292] igb 0000:09:00.0: [14] CmpltTO [ 200.105524,009][ T292] igb 0000:09:00.0: AER: TLP Header: 00000000 00000000 00000000 00000000 [ T292] pcieport 0000:00:1c.5: AER: broadcast error_detected message [ T292] igb 0000:09:00.0: Non-correctable non-fatal error reported. [ T292] pcieport 0000:00:1c.5: AER: broadcast mmio_enabled message [ T292] pcieport 0000:00:1c.5: AER: broadcast resume message [ T292] ------------[ cut here ]------------ [ T292] kernel BUG at net/core/dev.c:6539! [ T292] invalid opcode: 0000 [#1] PREEMPT SMP [ T292] RIP: 0010:napi_enable+0x37/0x40 [ T292] Call Trace: [ T292] [ T292] ? die+0x33/0x90 [ T292] ? do_trap+0xdc/0x110 [ T292] ? napi_enable+0x37/0x40 [ T292] ? do_error_trap+0x70/0xb0 [ T292] ? napi_enable+0x37/0x40 [ T292] ? napi_enable+0x37/0x40 [ T292] ? exc_invalid_op+0x4e/0x70 [ T292] ? napi_enable+0x37/0x40 [ T292] ? asm_exc_invalid_op+0x16/0x20 [ T292] ? napi_enable+0x37/0x40 [ T292] igb_up+0x41/0x150 [ T292] igb_io_resume+0x25/0x70 [ T292] report_resume+0x54/0x70 [ T292] ? report_frozen_detected+0x20/0x20 [ T292] pci_walk_bus+0x6c/0x90 [ T292] ? aer_print_port_info+0xa0/0xa0 [ T292] pcie_do_recovery+0x22f/0x380 [ T292] aer_process_err_devices+0x110/0x160 [ T292] aer_isr+0x1c1/0x1e0 [ T292] ? disable_irq_nosync+0x10/0x10 [ T292] irq_thread_fn+0x1a/0x60 [ T292] irq_thread+0xe3/0x1a0 [ T292] ? irq_set_affinity_notifier+0x120/0x120 [ T292] ? irq_affinity_notify+0x100/0x100 [ T292] kthread+0xe2/0x110 [ T292] ? kthread_complete_and_exit+0x20/0x20 [ T292] ret_from_fork+0x2d/0x50 [ T292] ? kthread_complete_and_exit+0x20/0x20 [ T292] ret_from_fork_asm+0x11/0x20 [ T292] To fix this issue igb_io_resume() checks if the interface is running and the device is not down this means igb_io_error_detected() did not bring the device down and there is no need to bring it up.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50041", "url": "https://ubuntu.com/security/CVE-2024-50041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: Fix macvlan leak by synchronizing access to mac_filter_hash This patch addresses a macvlan leak issue in the i40e driver caused by concurrent access to vsi->mac_filter_hash. The leak occurs when multiple threads attempt to modify the mac_filter_hash simultaneously, leading to inconsistent state and potential memory leaks. To fix this, we now wrap the calls to i40e_del_mac_filter() and zeroing vf->default_lan_addr.addr with spin_lock/unlock_bh(&vsi->mac_filter_hash_lock), ensuring atomic operations and preventing concurrent access. Additionally, we add lockdep_assert_held(&vsi->mac_filter_hash_lock) in i40e_add_mac_filter() to help catch similar issues in the future. Reproduction steps: 1. Spawn VFs and configure port vlan on them. 2. Trigger concurrent macvlan operations (e.g., adding and deleting \tportvlan and/or mac filters). 3. Observe the potential memory leak and inconsistent state in the \tmac_filter_hash. This synchronization ensures the integrity of the mac_filter_hash and prevents the described leak.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50042", "url": "https://ubuntu.com/security/CVE-2024-50042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix increasing MSI-X on VF Increasing MSI-X value on a VF leads to invalid memory operations. This is caused by not reallocating some arrays. Reproducer: modprobe ice echo 0 > /sys/bus/pci/devices/$PF_PCI/sriov_drivers_autoprobe echo 1 > /sys/bus/pci/devices/$PF_PCI/sriov_numvfs echo 17 > /sys/bus/pci/devices/$VF0_PCI/sriov_vf_msix_count Default MSI-X is 16, so 17 and above triggers this issue. KASAN reports: BUG: KASAN: slab-out-of-bounds in ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] Read of size 8 at addr ffff8888b937d180 by task bash/28433 (...) Call Trace: (...) ? ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] kasan_report+0xed/0x120 ? ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] ice_vsi_cfg_def+0x3360/0x4770 [ice] ? mutex_unlock+0x83/0xd0 ? __pfx_ice_vsi_cfg_def+0x10/0x10 [ice] ? __pfx_ice_remove_vsi_lkup_fltr+0x10/0x10 [ice] ice_vsi_cfg+0x7f/0x3b0 [ice] ice_vf_reconfig_vsi+0x114/0x210 [ice] ice_sriov_set_msix_vec_count+0x3d0/0x960 [ice] sriov_vf_msix_count_store+0x21c/0x300 (...) Allocated by task 28201: (...) ice_vsi_cfg_def+0x1c8e/0x4770 [ice] ice_vsi_cfg+0x7f/0x3b0 [ice] ice_vsi_setup+0x179/0xa30 [ice] ice_sriov_configure+0xcaa/0x1520 [ice] sriov_numvfs_store+0x212/0x390 (...) To fix it, use ice_vsi_rebuild() instead of ice_vf_reconfig_vsi(). This causes the required arrays to be reallocated taking the new queue count into account (ice_vsi_realloc_stat_arrays()). Set req_txq and req_rxq before ice_vsi_rebuild(), so that realloc uses the newly set queue count. Additionally, ice_vsi_rebuild() does not remove VSI filters (ice_fltr_remove_all()), so ice_vf_init_host_cfg() is no longer necessary.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50093", "url": "https://ubuntu.com/security/CVE-2024-50093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: intel: int340x: processor: Fix warning during module unload The processor_thermal driver uses pcim_device_enable() to enable a PCI device, which means the device will be automatically disabled on driver detach. Thus there is no need to call pci_disable_device() again on it. With recent PCI device resource management improvements, e.g. commit f748a07a0b64 (\"PCI: Remove legacy pcim_release()\"), this problem is exposed and triggers the warining below. [ 224.010735] proc_thermal_pci 0000:00:04.0: disabling already-disabled device [ 224.010747] WARNING: CPU: 8 PID: 4442 at drivers/pci/pci.c:2250 pci_disable_device+0xe5/0x100 ... [ 224.010844] Call Trace: [ 224.010845] [ 224.010847] ? show_regs+0x6d/0x80 [ 224.010851] ? __warn+0x8c/0x140 [ 224.010854] ? pci_disable_device+0xe5/0x100 [ 224.010856] ? report_bug+0x1c9/0x1e0 [ 224.010859] ? handle_bug+0x46/0x80 [ 224.010862] ? exc_invalid_op+0x1d/0x80 [ 224.010863] ? asm_exc_invalid_op+0x1f/0x30 [ 224.010867] ? pci_disable_device+0xe5/0x100 [ 224.010869] ? pci_disable_device+0xe5/0x100 [ 224.010871] ? kfree+0x21a/0x2b0 [ 224.010873] pcim_disable_device+0x20/0x30 [ 224.010875] devm_action_release+0x16/0x20 [ 224.010878] release_nodes+0x47/0xc0 [ 224.010880] devres_release_all+0x9f/0xe0 [ 224.010883] device_unbind_cleanup+0x12/0x80 [ 224.010885] device_release_driver_internal+0x1ca/0x210 [ 224.010887] driver_detach+0x4e/0xa0 [ 224.010889] bus_remove_driver+0x6f/0xf0 [ 224.010890] driver_unregister+0x35/0x60 [ 224.010892] pci_unregister_driver+0x44/0x90 [ 224.010894] proc_thermal_pci_driver_exit+0x14/0x5f0 [processor_thermal_device_pci] ... [ 224.010921] ---[ end trace 0000000000000000 ]--- Remove the excess pci_disable_device() calls. [ rjw: Subject and changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50043", "url": "https://ubuntu.com/security/CVE-2024-50043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix possible badness in FREE_STATEID When multiple FREE_STATEIDs are sent for the same delegation stateid, it can lead to a possible either use-after-free or counter refcount underflow errors. In nfsd4_free_stateid() under the client lock we find a delegation stateid, however the code drops the lock before calling nfs4_put_stid(), that allows another FREE_STATE to find the stateid again. The first one will proceed to then free the stateid which leads to either use-after-free or decrementing already zeroed counter.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50044", "url": "https://ubuntu.com/security/CVE-2024-50044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change rfcomm_sk_state_change attempts to use sock_lock so it must never be called with it locked but rfcomm_sock_ioctl always attempt to lock it causing the following trace: ====================================================== WARNING: possible circular locking dependency detected 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Not tainted ------------------------------------------------------ syz-executor386/5093 is trying to acquire lock: ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1671 [inline] ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73 but task is already holding lock: ffff88807badfd28 (&d->lock){+.+.}-{3:3}, at: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50045", "url": "https://ubuntu.com/security/CVE-2024-50045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: br_netfilter: fix panic with metadata_dst skb Fix a kernel panic in the br_netfilter module when sending untagged traffic via a VxLAN device. This happens during the check for fragmentation in br_nf_dev_queue_xmit. It is dependent on: 1) the br_netfilter module being loaded; 2) net.bridge.bridge-nf-call-iptables set to 1; 3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port; 4) untagged frames with size higher than the VxLAN MTU forwarded/flooded When forwarding the untagged packet to the VxLAN bridge port, before the netfilter hooks are called, br_handle_egress_vlan_tunnel is called and changes the skb_dst to the tunnel dst. The tunnel_dst is a metadata type of dst, i.e., skb_valid_dst(skb) is false, and metadata->dst.dev is NULL. Then in the br_netfilter hooks, in br_nf_dev_queue_xmit, there's a check for frames that needs to be fragmented: frames with higher MTU than the VxLAN device end up calling br_nf_ip_fragment, which in turns call ip_skb_dst_mtu. The ip_dst_mtu tries to use the skb_dst(skb) as if it was a valid dst with valid dst->dev, thus the crash. This case was never supported in the first place, so drop the packet instead. PING 10.0.0.2 (10.0.0.2) from 0.0.0.0 h1-eth0: 2000(2028) bytes of data. [ 176.291791] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000110 [ 176.292101] Mem abort info: [ 176.292184] ESR = 0x0000000096000004 [ 176.292322] EC = 0x25: DABT (current EL), IL = 32 bits [ 176.292530] SET = 0, FnV = 0 [ 176.292709] EA = 0, S1PTW = 0 [ 176.292862] FSC = 0x04: level 0 translation fault [ 176.293013] Data abort info: [ 176.293104] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 176.293488] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 176.293787] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 176.293995] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043ef5000 [ 176.294166] [0000000000000110] pgd=0000000000000000, p4d=0000000000000000 [ 176.294827] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 176.295252] Modules linked in: vxlan ip6_udp_tunnel udp_tunnel veth br_netfilter bridge stp llc ipv6 crct10dif_ce [ 176.295923] CPU: 0 PID: 188 Comm: ping Not tainted 6.8.0-rc3-g5b3fbd61b9d1 #2 [ 176.296314] Hardware name: linux,dummy-virt (DT) [ 176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 176.296808] pc : br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.297382] lr : br_nf_dev_queue_xmit+0x2ac/0x4ec [br_netfilter] [ 176.297636] sp : ffff800080003630 [ 176.297743] x29: ffff800080003630 x28: 0000000000000008 x27: ffff6828c49ad9f8 [ 176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24: 00000000000003e8 [ 176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21: ffff6828c3b16d28 [ 176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18: 0000000000000014 [ 176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15: 0000000095744632 [ 176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12: ffffb7e137926a70 [ 176.299574] x11: 0000000000000001 x10: ffff6828c3f1c898 x9 : 0000000000000000 [ 176.300049] x8 : ffff6828c49bf070 x7 : 0008460f18d5f20e x6 : f20e0100bebafeca [ 176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 : 0000000000000000 [ 176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 : ffff6828c7f918f0 [ 176.300889] Call trace: [ 176.301123] br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.301411] br_nf_post_routing+0x2a8/0x3e4 [br_netfilter] [ 176.301703] nf_hook_slow+0x48/0x124 [ 176.302060] br_forward_finish+0xc8/0xe8 [bridge] [ 176.302371] br_nf_hook_thresh+0x124/0x134 [br_netfilter] [ 176.302605] br_nf_forward_finish+0x118/0x22c [br_netfilter] [ 176.302824] br_nf_forward_ip.part.0+0x264/0x290 [br_netfilter] [ 176.303136] br_nf_forward+0x2b8/0x4e0 [br_netfilter] [ 176.303359] nf_hook_slow+0x48/0x124 [ 176.303 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50094", "url": "https://ubuntu.com/security/CVE-2024-50094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sfc: Don't invoke xdp_do_flush() from netpoll. Yury reported a crash in the sfc driver originated from netpoll_send_udp(). The netconsole sends a message and then netpoll invokes the driver's NAPI function with a budget of zero. It is dedicated to allow driver to free TX resources, that it may have used while sending the packet. In the netpoll case the driver invokes xdp_do_flush() unconditionally, leading to crash because bpf_net_context was never assigned. Invoke xdp_do_flush() only if budget is not zero.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50188", "url": "https://ubuntu.com/security/CVE-2024-50188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: dp83869: fix memory corruption when enabling fiber When configuring the fiber port, the DP83869 PHY driver incorrectly calls linkmode_set_bit() with a bit mask (1 << 10) rather than a bit number (10). This corrupts some other memory location -- in case of arm64 the priv pointer in the same structure. Since the advertising flags are updated from supported at the end of the function the incorrect line isn't needed at all and can be removed.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50046", "url": "https://ubuntu.com/security/CVE-2024-50046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies() On the node of an NFS client, some files saved in the mountpoint of the NFS server were copied to another location of the same NFS server. Accidentally, the nfs42_complete_copies() got a NULL-pointer dereference crash with the following syslog: [232064.838881] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232064.839360] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232066.588183] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 [232066.588586] Mem abort info: [232066.588701] ESR = 0x0000000096000007 [232066.588862] EC = 0x25: DABT (current EL), IL = 32 bits [232066.589084] SET = 0, FnV = 0 [232066.589216] EA = 0, S1PTW = 0 [232066.589340] FSC = 0x07: level 3 translation fault [232066.589559] Data abort info: [232066.589683] ISV = 0, ISS = 0x00000007 [232066.589842] CM = 0, WnR = 0 [232066.589967] user pgtable: 64k pages, 48-bit VAs, pgdp=00002000956ff400 [232066.590231] [0000000000000058] pgd=08001100ae100003, p4d=08001100ae100003, pud=08001100ae100003, pmd=08001100b3c00003, pte=0000000000000000 [232066.590757] Internal error: Oops: 96000007 [#1] SMP [232066.590958] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm vhost_net vhost vhost_iotlb tap tun ipt_rpfilter xt_multiport ip_set_hash_ip ip_set_hash_net xfrm_interface xfrm6_tunnel tunnel4 tunnel6 esp4 ah4 wireguard libcurve25519_generic veth xt_addrtype xt_set nf_conntrack_netlink ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_bitmap_port ip_set_hash_ipport dummy ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs iptable_filter sch_ingress nfnetlink_cttimeout vport_gre ip_gre ip_tunnel gre vport_geneve geneve vport_vxlan vxlan ip6_udp_tunnel udp_tunnel openvswitch nf_conncount dm_round_robin dm_service_time dm_multipath xt_nat xt_MASQUERADE nft_chain_nat nf_nat xt_mark xt_conntrack xt_comment nft_compat nft_counter nf_tables nfnetlink ocfs2 ocfs2_nodemanager ocfs2_stackglue iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_ssif nbd overlay 8021q garp mrp bonding tls rfkill sunrpc ext4 mbcache jbd2 [232066.591052] vfat fat cas_cache cas_disk ses enclosure scsi_transport_sas sg acpi_ipmi ipmi_si ipmi_devintf ipmi_msghandler ip_tables vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio dm_mirror dm_region_hash dm_log dm_mod nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc fuse xfs libcrc32c ast drm_vram_helper qla2xxx drm_kms_helper syscopyarea crct10dif_ce sysfillrect ghash_ce sysimgblt sha2_ce fb_sys_fops cec sha256_arm64 sha1_ce drm_ttm_helper ttm nvme_fc igb sbsa_gwdt nvme_fabrics drm nvme_core i2c_algo_bit i40e scsi_transport_fc megaraid_sas aes_neon_bs [232066.596953] CPU: 6 PID: 4124696 Comm: 10.253.166.125- Kdump: loaded Not tainted 5.15.131-9.cl9_ocfs2.aarch64 #1 [232066.597356] Hardware name: Great Wall .\\x93\\x8e...RF6260 V5/GWMSSE2GL1T, BIOS T656FBE_V3.0.18 2024-01-06 [232066.597721] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [232066.598034] pc : nfs4_reclaim_open_state+0x220/0x800 [nfsv4] [232066.598327] lr : nfs4_reclaim_open_state+0x12c/0x800 [nfsv4] [232066.598595] sp : ffff8000f568fc70 [232066.598731] x29: ffff8000f568fc70 x28: 0000000000001000 x27: ffff21003db33000 [232066.599030] x26: ffff800005521ae0 x25: ffff0100f98fa3f0 x24: 0000000000000001 [232066.599319] x23: ffff800009920008 x22: ffff21003db33040 x21: ffff21003db33050 [232066.599628] x20: ffff410172fe9e40 x19: ffff410172fe9e00 x18: 0000000000000000 [232066.599914] x17: 0000000000000000 x16: 0000000000000004 x15: 0000000000000000 [232066.600195] x14: 0000000000000000 x13: ffff800008e685a8 x12: 00000000eac0c6e6 [232066.600498] x11: 00000000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50190", "url": "https://ubuntu.com/security/CVE-2024-50190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix memleak in ice_init_tx_topology() Fix leak of the FW blob (DDP pkg). Make ice_cfg_tx_topo() const-correct, so ice_init_tx_topology() can avoid copying whole FW blob. Copy just the topology section, and only when needed. Reuse the buffer allocated for the read of the current topology. This was found by kmemleak, with the following trace for each PF: [] kmemdup_noprof+0x1d/0x50 [] ice_init_ddp_config+0x100/0x220 [ice] [] ice_init_dev+0x6f/0x200 [ice] [] ice_init+0x29/0x560 [ice] [] ice_probe+0x21d/0x310 [ice] Constify ice_cfg_tx_topo() @buf parameter. This cascades further down to few more functions.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50180", "url": "https://ubuntu.com/security/CVE-2024-50180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: sisfb: Fix strbuf array overflow The values of the variables xres and yres are placed in strbuf. These variables are obtained from strbuf1. The strbuf1 array contains digit characters and a space if the array contains non-digit characters. Then, when executing sprintf(strbuf, \"%ux%ux8\", xres, yres); more than 16 bytes will be written to strbuf. It is suggested to increase the size of the strbuf array to 24. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06: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": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50048", "url": "https://ubuntu.com/security/CVE-2024-50048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: Fix a NULL pointer dereference issue in fbcon_putcs syzbot has found a NULL pointer dereference bug in fbcon. Here is the simplified C reproducer: struct param { \tuint8_t type; \tstruct tiocl_selection ts; }; int main() { \tstruct fb_con2fbmap con2fb; \tstruct param param; \tint fd = open(\"/dev/fb1\", 0, 0); \tcon2fb.console = 0x19; \tcon2fb.framebuffer = 0; \tioctl(fd, FBIOPUT_CON2FBMAP, &con2fb); \tparam.type = 2; \tparam.ts.xs = 0; param.ts.ys = 0; \tparam.ts.xe = 0; param.ts.ye = 0; \tparam.ts.sel_mode = 0; \tint fd1 = open(\"/dev/tty1\", O_RDWR, 0); \tioctl(fd1, TIOCLINUX, ¶m); \tcon2fb.console = 1; \tcon2fb.framebuffer = 0; \tioctl(fd, FBIOPUT_CON2FBMAP, &con2fb); \treturn 0; } After calling ioctl(fd1, TIOCLINUX, ¶m), the subsequent ioctl(fd, FBIOPUT_CON2FBMAP, &con2fb) causes the kernel to follow a different execution path: set_con2fb_map -> con2fb_init_display -> fbcon_set_disp -> redraw_screen -> hide_cursor -> clear_selection -> highlight -> invert_screen -> do_update_region -> fbcon_putcs -> ops->putcs Since ops->putcs is a NULL pointer, this leads to a kernel panic. To prevent this, we need to call set_blitting_type() within set_con2fb_map() to properly initialize ops->putcs.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50049", "url": "https://ubuntu.com/security/CVE-2024-50049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before dereferencing se [WHAT & HOW] se is null checked previously in the same function, indicating it might be null; therefore, it must be checked when used again. This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50090", "url": "https://ubuntu.com/security/CVE-2024-50090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/oa: Fix overflow in oa batch buffer By default xe_bb_create_job() appends a MI_BATCH_BUFFER_END to batch buffer, this is not a problem if batch buffer is only used once but oa reuses the batch buffer for the same metric and at each call it appends a MI_BATCH_BUFFER_END, printing the warning below and then overflowing. [ 381.072016] ------------[ cut here ]------------ [ 381.072019] xe 0000:00:02.0: [drm] Assertion `bb->len * 4 + bb_prefetch(q->gt) <= size` failed! platform: LUNARLAKE subplatform: 1 graphics: Xe2_LPG / Xe2_HPG 20.04 step B0 media: Xe2_LPM / Xe2_HPM 20.00 step B0 tile: 0 VRAM 0 B GT: 0 type 1 So here checking if batch buffer already have MI_BATCH_BUFFER_END if not append it. v2: - simply fix, suggestion from Ashutosh (cherry picked from commit 9ba0e0f30ca42a98af3689460063edfb6315718a)", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50183", "url": "https://ubuntu.com/security/CVE-2024-50183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV instance Deleting an NPIV instance requires all fabric ndlps to be released before an NPIV's resources can be torn down. Failure to release fabric ndlps beforehand opens kref imbalance race conditions. Fix by forcing the DA_ID to complete synchronously with usage of wait_queue.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50055", "url": "https://ubuntu.com/security/CVE-2024-50055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: driver core: bus: Fix double free in driver API bus_register() For bus_register(), any error which happens after kset_register() will cause that @priv are freed twice, fixed by setting @priv with NULL after the first free.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50091", "url": "https://ubuntu.com/security/CVE-2024-50091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm vdo: don't refer to dedupe_context after releasing it Clear the dedupe_context pointer in a data_vio whenever ownership of the context is lost, so that vdo can't examine it accidentally.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50056", "url": "https://ubuntu.com/security/CVE-2024-50056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: Fix ERR_PTR dereference in uvc_v4l2.c Fix potential dereferencing of ERR_PTR() in find_format_by_pix() and uvc_v4l2_enum_format(). Fix the following smatch errors: drivers/usb/gadget/function/uvc_v4l2.c:124 find_format_by_pix() error: 'fmtdesc' dereferencing possible ERR_PTR() drivers/usb/gadget/function/uvc_v4l2.c:392 uvc_v4l2_enum_format() error: 'fmtdesc' dereferencing possible ERR_PTR() Also, fix similar issue in uvc_v4l2_try_format() for potential dereferencing of ERR_PTR().", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50184", "url": "https://ubuntu.com/security/CVE-2024-50184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_pmem: Check device status before requesting flush If a pmem device is in a bad status, the driver side could wait for host ack forever in virtio_pmem_flush(), causing the system to hang. So add a status check in the beginning of virtio_pmem_flush() to return early if the device is not activated.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50057", "url": "https://ubuntu.com/security/CVE-2024-50057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: tipd: Free IRQ only if it was requested before In polling mode, if no IRQ was requested there is no need to free it. Call devm_free_irq() only if client->irq is set. This fixes the warning caused by the tps6598x module removal: WARNING: CPU: 2 PID: 333 at kernel/irq/devres.c:144 devm_free_irq+0x80/0x8c ... ... Call trace: devm_free_irq+0x80/0x8c tps6598x_remove+0x28/0x88 [tps6598x] i2c_device_remove+0x2c/0x9c device_remove+0x4c/0x80 device_release_driver_internal+0x1cc/0x228 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 i2c_del_driver+0x54/0x64 tps6598x_i2c_driver_exit+0x18/0xc3c [tps6598x] __arm64_sys_delete_module+0x184/0x264 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc8/0xe8 do_el0_svc+0x20/0x2c el0_svc+0x28/0x98 el0t_64_sync_handler+0x13c/0x158 el0t_64_sync+0x190/0x194", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50058", "url": "https://ubuntu.com/security/CVE-2024-50058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: protect uart_port_dtr_rts() in uart_shutdown() too Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part 3) added few uport == NULL checks. It added one to uart_shutdown(), so the commit assumes, uport can be NULL in there. But right after that protection, there is an unprotected \"uart_port_dtr_rts(uport, false);\" call. That is invoked only if HUPCL is set, so I assume that is the reason why we do not see lots of these reports. Or it cannot be NULL at this point at all for some reason :P. Until the above is investigated, stay on the safe side and move this dereference to the if too. I got this inconsistency from Coverity under CID 1585130. Thanks.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50181", "url": "https://ubuntu.com/security/CVE-2024-50181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: imx: Remove CLK_SET_PARENT_GATE for DRAM mux for i.MX7D For i.MX7D DRAM related mux clock, the clock source change should ONLY be done done in low level asm code without accessing DRAM, and then calling clk API to sync the HW clock status with clk tree, it should never touch real clock source switch via clk API, so CLK_SET_PARENT_GATE flag should NOT be added, otherwise, DRAM's clock parent will be disabled when DRAM is active, and system will hang.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50059", "url": "https://ubuntu.com/security/CVE-2024-50059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntb: ntb_hw_switchtec: Fix use after free vulnerability in switchtec_ntb_remove due to race condition In the switchtec_ntb_add function, it can call switchtec_ntb_init_sndev function, then &sndev->check_link_status_work is bound with check_link_status_work. switchtec_ntb_link_notification may be called to start the work. If we remove the module which will call switchtec_ntb_remove to make cleanup, it will free sndev through kfree(sndev), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | check_link_status_work switchtec_ntb_remove | kfree(sndev); | | if (sndev->link_force_down) | // use sndev Fix it by ensuring that the work is canceled before proceeding with the cleanup in switchtec_ntb_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50060", "url": "https://ubuntu.com/security/CVE-2024-50060", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring: check if we need to reschedule during overflow flush In terms of normal application usage, this list will always be empty. And if an application does overflow a bit, it'll have a few entries. However, nothing obviously prevents syzbot from running a test case that generates a ton of overflow entries, and then flushing them can take quite a while. Check for needing to reschedule while flushing, and drop our locks and do so if necessary. There's no state to maintain here as overflows always prune from head-of-list, hence it's fine to drop and reacquire the locks at the end of the loop.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50061", "url": "https://ubuntu.com/security/CVE-2024-50061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: cdns: Fix use after free vulnerability in cdns_i3c_master Driver Due to Race Condition In the cdns_i3c_master_probe function, &master->hj_work is bound with cdns_i3c_master_hj. And cdns_i3c_master_interrupt can call cnds_i3c_master_demux_ibis function to start the work. If we remove the module which will call cdns_i3c_master_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | cdns_i3c_master_hj cdns_i3c_master_remove | i3c_master_unregister(&master->base) | device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in cdns_i3c_master_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50062", "url": "https://ubuntu.com/security/CVE-2024-50062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-srv: Avoid null pointer deref during path establishment For RTRS path establishment, RTRS client initiates and completes con_num of connections. After establishing all its connections, the information is exchanged between the client and server through the info_req message. During this exchange, it is essential that all connections have been established, and the state of the RTRS srv path is CONNECTED. So add these sanity checks, to make sure we detect and abort process in error scenarios to avoid null pointer deref.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50095", "url": "https://ubuntu.com/security/CVE-2024-50095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mad: Improve handling of timed out WRs of mad agent Current timeout handler of mad agent acquires/releases mad_agent_priv lock for every timed out WRs. This causes heavy locking contention when higher no. of WRs are to be handled inside timeout handler. This leads to softlockup with below trace in some use cases where rdma-cm path is used to establish connection between peer nodes Trace: ----- BUG: soft lockup - CPU#4 stuck for 26s! [kworker/u128:3:19767] CPU: 4 PID: 19767 Comm: kworker/u128:3 Kdump: loaded Tainted: G OE ------- --- 5.14.0-427.13.1.el9_4.x86_64 #1 Hardware name: Dell Inc. PowerEdge R740/01YM03, BIOS 2.4.8 11/26/2019 Workqueue: ib_mad1 timeout_sends [ib_core] RIP: 0010:__do_softirq+0x78/0x2ac RSP: 0018:ffffb253449e4f98 EFLAGS: 00000246 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 000000000000001f RDX: 000000000000001d RSI: 000000003d1879ab RDI: fff363b66fd3a86b RBP: ffffb253604cbcd8 R08: 0000009065635f3b R09: 0000000000000000 R10: 0000000000000040 R11: ffffb253449e4ff8 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000040 FS: 0000000000000000(0000) GS:ffff8caa1fc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd9ec9db900 CR3: 0000000891934006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? __irq_exit_rcu+0xa1/0xc0 ? watchdog_timer_fn+0x1b2/0x210 ? __pfx_watchdog_timer_fn+0x10/0x10 ? __hrtimer_run_queues+0x127/0x2c0 ? hrtimer_interrupt+0xfc/0x210 ? __sysvec_apic_timer_interrupt+0x5c/0x110 ? sysvec_apic_timer_interrupt+0x37/0x90 ? asm_sysvec_apic_timer_interrupt+0x16/0x20 ? __do_softirq+0x78/0x2ac ? __do_softirq+0x60/0x2ac __irq_exit_rcu+0xa1/0xc0 sysvec_call_function_single+0x72/0x90 asm_sysvec_call_function_single+0x16/0x20 RIP: 0010:_raw_spin_unlock_irq+0x14/0x30 RSP: 0018:ffffb253604cbd88 EFLAGS: 00000247 RAX: 000000000001960d RBX: 0000000000000002 RCX: ffff8cad2a064800 RDX: 000000008020001b RSI: 0000000000000001 RDI: ffff8cad5d39f66c RBP: ffff8cad5d39f600 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8caa443e0c00 R11: ffffb253604cbcd8 R12: ffff8cacb8682538 R13: 0000000000000005 R14: ffffb253604cbd90 R15: ffff8cad5d39f66c cm_process_send_error+0x122/0x1d0 [ib_cm] timeout_sends+0x1dd/0x270 [ib_core] process_one_work+0x1e2/0x3b0 ? __pfx_worker_thread+0x10/0x10 worker_thread+0x50/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xdd/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x50 Simplified timeout handler by creating local list of timed out WRs and invoke send handler post creating the list. The new method acquires/ releases lock once to fetch the list and hence helps to reduce locking contetiong when processing higher no. of WRs", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50063", "url": "https://ubuntu.com/security/CVE-2024-50063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Prevent tail call between progs attached to different hooks bpf progs can be attached to kernel functions, and the attached functions can take different parameters or return different return values. If prog attached to one kernel function tail calls prog attached to another kernel function, the ctx access or return value verification could be bypassed. For example, if prog1 is attached to func1 which takes only 1 parameter and prog2 is attached to func2 which takes two parameters. Since verifier assumes the bpf ctx passed to prog2 is constructed based on func2's prototype, verifier allows prog2 to access the second parameter from the bpf ctx passed to it. The problem is that verifier does not prevent prog1 from passing its bpf ctx to prog2 via tail call. In this case, the bpf ctx passed to prog2 is constructed from func1 instead of func2, that is, the assumption for ctx access verification is bypassed. Another example, if BPF LSM prog1 is attached to hook file_alloc_security, and BPF LSM prog2 is attached to hook bpf_lsm_audit_rule_known. Verifier knows the return value rules for these two hooks, e.g. it is legal for bpf_lsm_audit_rule_known to return positive number 1, and it is illegal for file_alloc_security to return positive number. So verifier allows prog2 to return positive number 1, but does not allow prog1 to return positive number. The problem is that verifier does not prevent prog1 from calling prog2 via tail call. In this case, prog2's return value 1 will be used as the return value for prog1's hook file_alloc_security. That is, the return value rule is bypassed. This patch adds restriction for tail call to prevent such bypasses.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50191", "url": "https://ubuntu.com/security/CVE-2024-50191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: don't set SB_RDONLY after filesystem errors When the filesystem is mounted with errors=remount-ro, we were setting SB_RDONLY flag to stop all filesystem modifications. We knew this misses proper locking (sb->s_umount) and does not go through proper filesystem remount procedure but it has been the way this worked since early ext2 days and it was good enough for catastrophic situation damage mitigation. Recently, syzbot has found a way (see link) to trigger warnings in filesystem freezing because the code got confused by SB_RDONLY changing under its hands. Since these days we set EXT4_FLAGS_SHUTDOWN on the superblock which is enough to stop all filesystem modifications, modifying SB_RDONLY shouldn't be needed. So stop doing that.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50064", "url": "https://ubuntu.com/security/CVE-2024-50064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: zram: free secondary algorithms names We need to kfree() secondary algorithms names when reset zram device that had multi-streams, otherwise we leak memory. [senozhatsky@chromium.org: kfree(NULL) is legal] Link: https://lkml.kernel.org/r/20240917013021.868769-1-senozhatsky@chromium.org", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50065", "url": "https://ubuntu.com/security/CVE-2024-50065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Change to non-blocking allocation in ntfs_d_hash d_hash is done while under \"rcu-walk\" and should not sleep. __get_name() allocates using GFP_KERNEL, having the possibility to sleep when under memory pressure. Change the allocation to GFP_NOWAIT.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50089", "url": "https://ubuntu.com/security/CVE-2024-50089", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-49863", "url": "https://ubuntu.com/security/CVE-2024-49863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost/scsi: null-ptr-dereference in vhost_scsi_get_req() Since commit 3f8ca2e115e5 (\"vhost/scsi: Extract common handling code from control queue handler\") a null pointer dereference bug can be triggered when guest sends an SCSI AN request. In vhost_scsi_ctl_handle_vq(), `vc.target` is assigned with `&v_req.tmf.lun[1]` within a switch-case block and is then passed to vhost_scsi_get_req() which extracts `vc->req` and `tpg`. However, for a `VIRTIO_SCSI_T_AN_*` request, tpg is not required, so `vc.target` is set to NULL in this branch. Later, in vhost_scsi_get_req(), `vc->target` is dereferenced without being checked, leading to a null pointer dereference bug. This bug can be triggered from guest. When this bug occurs, the vhost_worker process is killed while holding `vq->mutex` and the corresponding tpg will remain occupied indefinitely. Below is the KASAN report: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 PID: 840 Comm: poc Not tainted 6.10.0+ #1 Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:vhost_scsi_get_req+0x165/0x3a0 Code: 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 02 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 65 30 4c 89 e2 48 c1 ea 03 <0f> b6 04 02 4c 89 e2 83 e2 07 38 d0 7f 08 84 c0 0f 85 be 01 00 00 RSP: 0018:ffff888017affb50 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffff88801b000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888017affcb8 RBP: ffff888017affb80 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff888017affc88 R14: ffff888017affd1c R15: ffff888017993000 FS: 000055556e076500(0000) GS:ffff88806b100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200027c0 CR3: 0000000010ed0004 CR4: 0000000000370ef0 Call Trace: ? show_regs+0x86/0xa0 ? die_addr+0x4b/0xd0 ? exc_general_protection+0x163/0x260 ? asm_exc_general_protection+0x27/0x30 ? vhost_scsi_get_req+0x165/0x3a0 vhost_scsi_ctl_handle_vq+0x2a4/0xca0 ? __pfx_vhost_scsi_ctl_handle_vq+0x10/0x10 ? __switch_to+0x721/0xeb0 ? __schedule+0xda5/0x5710 ? __kasan_check_write+0x14/0x30 ? _raw_spin_lock+0x82/0xf0 vhost_scsi_ctl_handle_kick+0x52/0x90 vhost_run_work_list+0x134/0x1b0 vhost_task_fn+0x121/0x350 ... ---[ end trace 0000000000000000 ]--- Let's add a check in vhost_scsi_get_req. [whitespace fixes]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49864", "url": "https://ubuntu.com/security/CVE-2024-49864", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix a race between socket set up and I/O thread creation In rxrpc_open_socket(), it sets up the socket and then sets up the I/O thread that will handle it. This is a problem, however, as there's a gap between the two phases in which a packet may come into rxrpc_encap_rcv() from the UDP packet but we oops when trying to wake the not-yet created I/O thread. As a quick fix, just make rxrpc_encap_rcv() discard the packet if there's no I/O thread yet. A better, but more intrusive fix would perhaps be to rearrange things such that the socket creation is done by the I/O thread.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49865", "url": "https://ubuntu.com/security/CVE-2024-49865", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: move xa_alloc to prevent UAF Evil user can guess the next id of the vm before the ioctl completes and then call vm destroy ioctl to trigger UAF since create ioctl is still referencing the same vm. Move the xa_alloc all the way to the end to prevent this. v2: - Rebase (cherry picked from commit dcfd3971327f3ee92765154baebbaece833d3ca9)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49955", "url": "https://ubuntu.com/security/CVE-2024-49955", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: battery: Fix possible crash when unregistering a battery hook When a battery hook returns an error when adding a new battery, then the battery hook is automatically unregistered. However the battery hook provider cannot know that, so it will later call battery_hook_unregister() on the already unregistered battery hook, resulting in a crash. Fix this by using the list head to mark already unregistered battery hooks as already being unregistered so that they can be ignored by battery_hook_unregister().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49973", "url": "https://ubuntu.com/security/CVE-2024-49973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: r8169: add tally counter fields added with RTL8125 RTL8125 added fields to the tally counter, what may result in the chip dma'ing these new fields to unallocated memory. Therefore make sure that the allocated memory area is big enough to hold all of the tally counter values, even if we use only parts of it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49974", "url": "https://ubuntu.com/security/CVE-2024-49974", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Limit the number of concurrent async COPY operations Nothing appears to limit the number of concurrent async COPY operations that clients can start. In addition, AFAICT each async COPY can copy an unlimited number of 4MB chunks, so can run for a long time. Thus IMO async COPY can become a DoS vector. Add a restriction mechanism that bounds the number of concurrent background COPY operations. Start simple and try to be fair -- this patch implements a per-namespace limit. An async COPY request that occurs while this limit is exceeded gets NFS4ERR_DELAY. The requesting client can choose to send the request again after a delay or fall back to a traditional read/write style copy. If there is need to make the mechanism more sophisticated, we can visit that in future patches.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49975", "url": "https://ubuntu.com/security/CVE-2024-49975", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uprobes: fix kernel info leak via \"[uprobes]\" vma xol_add_vma() maps the uninitialized page allocated by __create_xol_area() into userspace. On some architectures (x86) this memory is readable even without VM_READ, VM_EXEC results in the same pgprot_t as VM_EXEC|VM_READ, although this doesn't really matter, debugger can read this memory anyway.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50003", "url": "https://ubuntu.com/security/CVE-2024-50003", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix system hang while resume with TBT monitor [Why] Connected with a Thunderbolt monitor and do the suspend and the system may hang while resume. The TBT monitor HPD will be triggered during the resume procedure and call the drm_client_modeset_probe() while struct drm_connector connector->dev->master is NULL. It will mess up the pipe topology after resume. [How] Skip the TBT monitor HPD during the resume procedure because we currently will probe the connectors after resume by default. (cherry picked from commit 453f86a26945207a16b8f66aaed5962dc2b95b85)", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50173", "url": "https://ubuntu.com/security/CVE-2024-50173", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix access to uninitialized variable in tick_ctx_cleanup() The group variable can't be used to retrieve ptdev in our second loop, because it points to the previously iterated list_head, not a valid group. Get the ptdev object from the scheduler instead.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49866", "url": "https://ubuntu.com/security/CVE-2024-49866", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Fix a race during cpuhp processing There is another found exception that the \"timerlat/1\" thread was scheduled on CPU0, and lead to timer corruption finally: ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ``` After tracing the scheduling event, it was discovered that the migration of the \"timerlat/1\" thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() | To fix this, skip online processing if the CPU is already offline.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49976", "url": "https://ubuntu.com/security/CVE-2024-49976", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Drop interface_lock in stop_kthread() stop_kthread() is the offline callback for \"trace/osnoise:online\", since commit 5bfbcd1ee57b (\"tracing/timerlat: Add interface_lock around clearing of kthread in stop_kthread()\"), the following ABBA deadlock scenario is introduced: T1 | T2 [BP] | T3 [AP] osnoise_hotplug_workfn() | work_for_cpu_fn() | cpuhp_thread_fun() | _cpu_down() | osnoise_cpu_die() mutex_lock(&interface_lock) | | stop_kthread() | cpus_write_lock() | mutex_lock(&interface_lock) cpus_read_lock() | cpuhp_kick_ap() | As the interface_lock here in just for protecting the \"kthread\" field of the osn_var, use xchg() instead to fix this issue. Also use for_each_online_cpu() back in stop_per_cpu_kthreads() as it can take cpu_read_lock() again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50005", "url": "https://ubuntu.com/security/CVE-2024-50005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: Fix potential RCU dereference issue in mac802154_scan_worker In the `mac802154_scan_worker` function, the `scan_req->type` field was accessed after the RCU read-side critical section was unlocked. According to RCU usage rules, this is illegal and can lead to unpredictable behavior, such as accessing memory that has been updated or causing use-after-free issues. This possible bug was identified using a static analysis tool developed by myself, specifically designed to detect RCU-related issues. To address this, the `scan_req->type` value is now stored in a local variable `scan_req_type` while still within the RCU read-side critical section. The `scan_req_type` is then used after the RCU lock is released, ensuring that the type value is safely accessed without violating RCU rules.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50012", "url": "https://ubuntu.com/security/CVE-2024-50012", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: Avoid a bad reference count on CPU node In the parse_perf_domain function, if the call to of_parse_phandle_with_args returns an error, then the reference to the CPU device node that was acquired at the start of the function would not be properly decremented. Address this by declaring the variable with the __free(device_node) cleanup attribute.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49867", "url": "https://ubuntu.com/security/CVE-2024-49867", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: wait for fixup workers before stopping cleaner kthread during umount During unmount, at close_ctree(), we have the following steps in this order: 1) Park the cleaner kthread - this doesn't destroy the kthread, it basically halts its execution (wake ups against it work but do nothing); 2) We stop the cleaner kthread - this results in freeing the respective struct task_struct; 3) We call btrfs_stop_all_workers() which waits for any jobs running in all the work queues and then free the work queues. Syzbot reported a case where a fixup worker resulted in a crash when doing a delayed iput on its inode while attempting to wake up the cleaner at btrfs_add_delayed_iput(), because the task_struct of the cleaner kthread was already freed. This can happen during unmount because we don't wait for any fixup workers still running before we call kthread_stop() against the cleaner kthread, which stops and free all its resources. Fix this by waiting for any fixup workers at close_ctree() before we call kthread_stop() against the cleaner and run pending delayed iputs. The stack traces reported by syzbot were the following: BUG: KASAN: slab-use-after-free in __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 Read of size 8 at addr ffff8880272a8a18 by task kworker/u8:3/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.12.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: btrfs-fixup btrfs_work_helper 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 __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline] try_to_wake_up+0xb0/0x1480 kernel/sched/core.c:4154 btrfs_writepage_fixup_worker+0xc16/0xdf0 fs/btrfs/inode.c:2842 btrfs_work_helper+0x390/0xc50 fs/btrfs/async-thread.c:314 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Allocated by task 2: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:319 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345 kasan_slab_alloc include/linux/kasan.h:247 [inline] slab_post_alloc_hook mm/slub.c:4086 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4187 alloc_task_struct_node kernel/fork.c:180 [inline] dup_task_struct+0x57/0x8c0 kernel/fork.c:1107 copy_process+0x5d1/0x3d50 kernel/fork.c:2206 kernel_clone+0x223/0x880 kernel/fork.c:2787 kernel_thread+0x1bc/0x240 kernel/fork.c:2849 create_kthread kernel/kthread.c:412 [inline] kthreadd+0x60d/0x810 kernel/kthread.c:765 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Freed by task 61: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:230 [inline] slab_free_h ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49868", "url": "https://ubuntu.com/security/CVE-2024-49868", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix a NULL pointer dereference when failed to start a new trasacntion [BUG] Syzbot reported a NULL pointer dereference with the following crash: FAULT_INJECTION: forcing a failure. start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676 prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642 relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678 ... BTRFS info (device loop0): balance: ended with status: -12 Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667] RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926 Call Trace: commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496 btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430 del_balance_item fs/btrfs/volumes.c:3678 [inline] reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742 btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574 btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673 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/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [CAUSE] The allocation failure happens at the start_transaction() inside prepare_to_relocate(), and during the error handling we call unset_reloc_control(), which makes fs_info->balance_ctl to be NULL. Then we continue the error path cleanup in btrfs_balance() by calling reset_balance_state() which will call del_balance_item() to fully delete the balance item in the root tree. However during the small window between set_reloc_contrl() and unset_reloc_control(), we can have a subvolume tree update and created a reloc_root for that subvolume. Then we go into the final btrfs_commit_transaction() of del_balance_item(), and into btrfs_update_reloc_root() inside commit_fs_roots(). That function checks if fs_info->reloc_ctl is in the merge_reloc_tree stage, but since fs_info->reloc_ctl is NULL, it results a NULL pointer dereference. [FIX] Just add extra check on fs_info->reloc_ctl inside btrfs_update_reloc_root(), before checking fs_info->reloc_ctl->merge_reloc_tree. That DEAD_RELOC_TREE handling is to prevent further modification to the reloc tree during merge stage, but since there is no reloc_ctl at all, we do not need to bother that.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49869", "url": "https://ubuntu.com/security/CVE-2024-49869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: send: fix buffer overflow detection when copying path to cache entry Starting with commit c0247d289e73 (\"btrfs: send: annotate struct name_cache_entry with __counted_by()\") we annotated the variable length array \"name\" from the name_cache_entry structure with __counted_by() to improve overflow detection. However that alone was not correct, because the length of that array does not match the \"name_len\" field - it matches that plus 1 to include the NUL string terminator, so that makes a fortified kernel think there's an overflow and report a splat like this: strcpy: detected buffer overflow: 20 byte write of buffer size 19 WARNING: CPU: 3 PID: 3310 at __fortify_report+0x45/0x50 CPU: 3 UID: 0 PID: 3310 Comm: btrfs Not tainted 6.11.0-prnet #1 Hardware name: CompuLab Ltd. sbc-ihsw/Intense-PC2 (IPC2), BIOS IPC2_3.330.7 X64 03/15/2018 RIP: 0010:__fortify_report+0x45/0x50 Code: 48 8b 34 (...) RSP: 0018:ffff97ebc0d6f650 EFLAGS: 00010246 RAX: 7749924ef60fa600 RBX: ffff8bf5446a521a RCX: 0000000000000027 RDX: 00000000ffffdfff RSI: ffff97ebc0d6f548 RDI: ffff8bf84e7a1cc8 RBP: ffff8bf548574080 R08: ffffffffa8c40e10 R09: 0000000000005ffd R10: 0000000000000004 R11: ffffffffa8c70e10 R12: ffff8bf551eef400 R13: 0000000000000000 R14: 0000000000000013 R15: 00000000000003a8 FS: 00007fae144de8c0(0000) GS:ffff8bf84e780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fae14691690 CR3: 00000001027a2003 CR4: 00000000001706f0 Call Trace: ? __warn+0x12a/0x1d0 ? __fortify_report+0x45/0x50 ? report_bug+0x154/0x1c0 ? handle_bug+0x42/0x70 ? exc_invalid_op+0x1a/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? __fortify_report+0x45/0x50 __fortify_panic+0x9/0x10 __get_cur_name_and_parent+0x3bc/0x3c0 get_cur_path+0x207/0x3b0 send_extent_data+0x709/0x10d0 ? find_parent_nodes+0x22df/0x25d0 ? mas_nomem+0x13/0x90 ? mtree_insert_range+0xa5/0x110 ? btrfs_lru_cache_store+0x5f/0x1e0 ? iterate_extent_inodes+0x52d/0x5a0 process_extent+0xa96/0x11a0 ? __pfx_lookup_backref_cache+0x10/0x10 ? __pfx_store_backref_cache+0x10/0x10 ? __pfx_iterate_backrefs+0x10/0x10 ? __pfx_check_extent_item+0x10/0x10 changed_cb+0x6fa/0x930 ? tree_advance+0x362/0x390 ? memcmp_extent_buffer+0xd7/0x160 send_subvol+0xf0a/0x1520 btrfs_ioctl_send+0x106b/0x11d0 ? __pfx___clone_root_cmp_sort+0x10/0x10 _btrfs_ioctl_send+0x1ac/0x240 btrfs_ioctl+0x75b/0x850 __se_sys_ioctl+0xca/0x150 do_syscall_64+0x85/0x160 ? __count_memcg_events+0x69/0x100 ? handle_mm_fault+0x1327/0x15c0 ? __se_sys_rt_sigprocmask+0xf1/0x180 ? syscall_exit_to_user_mode+0x75/0xa0 ? do_syscall_64+0x91/0x160 ? do_user_addr_fault+0x21d/0x630 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fae145eeb4f Code: 00 48 89 (...) RSP: 002b:00007ffdf1cb09b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fae145eeb4f RDX: 00007ffdf1cb0ad0 RSI: 0000000040489426 RDI: 0000000000000004 RBP: 00000000000078fe R08: 00007fae144006c0 R09: 00007ffdf1cb0927 R10: 0000000000000008 R11: 0000000000000246 R12: 00007ffdf1cb1ce8 R13: 0000000000000003 R14: 000055c499fab2e0 R15: 0000000000000004 Fix this by not storing the NUL string terminator since we don't actually need it for name cache entries, this way \"name_len\" corresponds to the actual size of the \"name\" array. This requires marking the \"name\" array field with __nonstring and using memcpy() instead of strcpy() as recommended by the guidelines at: https://github.com/KSPP/linux/issues/90", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49870", "url": "https://ubuntu.com/security/CVE-2024-49870", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cachefiles: fix dentry leak in cachefiles_open_file() A dentry leak may be caused when a lookup cookie and a cull are concurrent: P1 | P2 ----------------------------------------------------------- cachefiles_lookup_cookie cachefiles_look_up_object lookup_one_positive_unlocked // get dentry cachefiles_cull inode->i_flags |= S_KERNEL_FILE; cachefiles_open_file cachefiles_mark_inode_in_use __cachefiles_mark_inode_in_use can_use = false if (!(inode->i_flags & S_KERNEL_FILE)) can_use = true \t return false return false // Returns an error but doesn't put dentry After that the following WARNING will be triggered when the backend folder is umounted: ================================================================== BUG: Dentry 000000008ad87947{i=7a,n=Dx_1_1.img} still in use (1) [unmount of ext4 sda] WARNING: CPU: 4 PID: 359261 at fs/dcache.c:1767 umount_check+0x5d/0x70 CPU: 4 PID: 359261 Comm: umount Not tainted 6.6.0-dirty #25 RIP: 0010:umount_check+0x5d/0x70 Call Trace: d_walk+0xda/0x2b0 do_one_tree+0x20/0x40 shrink_dcache_for_umount+0x2c/0x90 generic_shutdown_super+0x20/0x160 kill_block_super+0x1a/0x40 ext4_kill_sb+0x22/0x40 deactivate_locked_super+0x35/0x80 cleanup_mnt+0x104/0x160 ================================================================== Whether cachefiles_open_file() returns true or false, the reference count obtained by lookup_positive_unlocked() in cachefiles_look_up_object() should be released. Therefore release that reference count in cachefiles_look_up_object() to fix the above issue and simplify the code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49871", "url": "https://ubuntu.com/security/CVE-2024-49871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: adp5589-keys - fix NULL pointer dereference We register a devm action to call adp5589_clear_config() and then pass the i2c client as argument so that we can call i2c_get_clientdata() in order to get our device object. However, i2c_set_clientdata() is only being set at the end of the probe function which means that we'll get a NULL pointer dereference in case the probe function fails early.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49872", "url": "https://ubuntu.com/security/CVE-2024-49872", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/gup: fix memfd_pin_folios alloc race panic If memfd_pin_folios tries to create a hugetlb page, but someone else already did, then folio gets the value -EEXIST here: folio = memfd_alloc_folio(memfd, start_idx); if (IS_ERR(folio)) { ret = PTR_ERR(folio); if (ret != -EEXIST) goto err; then on the next trip through the \"while start_idx\" loop we panic here: if (folio) { folio_put(folio); To fix, set the folio to NULL on error.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49964", "url": "https://ubuntu.com/security/CVE-2024-49964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix memfd_pin_folios free_huge_pages leak memfd_pin_folios followed by unpin_folios fails to restore free_huge_pages if the pages were not already faulted in, because the folio refcount for pages created by memfd_alloc_folio never goes to 0. memfd_pin_folios needs another folio_put to undo the folio_try_get below: memfd_alloc_folio() alloc_hugetlb_folio_nodemask() dequeue_hugetlb_folio_nodemask() dequeue_hugetlb_folio_node_exact() folio_ref_unfreeze(folio, 1); ; adds 1 refcount folio_try_get() ; adds 1 refcount hugetlb_add_to_page_cache() ; adds 512 refcount (on x86) With the fix, after memfd_pin_folios + unpin_folios, the refcount for the (unfaulted) page is 512, which is correct, as the refcount for a faulted unpinned page is 513.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49873", "url": "https://ubuntu.com/security/CVE-2024-49873", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/filemap: fix filemap_get_folios_contig THP panic Patch series \"memfd-pin huge page fixes\". Fix multiple bugs that occur when using memfd_pin_folios with hugetlb pages and THP. The hugetlb bugs only bite when the page is not yet faulted in when memfd_pin_folios is called. The THP bug bites when the starting offset passed to memfd_pin_folios is not huge page aligned. See the commit messages for details. This patch (of 5): memfd_pin_folios on memory backed by THP panics if the requested start offset is not huge page aligned: BUG: kernel NULL pointer dereference, address: 0000000000000036 RIP: 0010:filemap_get_folios_contig+0xdf/0x290 RSP: 0018:ffffc9002092fbe8 EFLAGS: 00010202 RAX: 0000000000000002 RBX: 0000000000000002 RCX: 0000000000000002 The fault occurs here, because xas_load returns a folio with value 2: filemap_get_folios_contig() for (folio = xas_load(&xas); folio && xas.xa_index <= end; folio = xas_next(&xas)) { ... if (!folio_try_get(folio)) <-- BOOM \"2\" is an xarray sibling entry. We get it because memfd_pin_folios does not round the indices passed to filemap_get_folios_contig to huge page boundaries for THP, so we load from the middle of a huge page range see a sibling. (It does round for hugetlbfs, at the is_file_hugepages test). To fix, if the folio is a sibling, then return the next index as the starting point for the next call to filemap_get_folios_contig.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49977", "url": "https://ubuntu.com/security/CVE-2024-49977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: Fix zero-division error when disabling tc cbs The commit b8c43360f6e4 (\"net: stmmac: No need to calculate speed divider when offload is disabled\") allows the \"port_transmit_rate_kbps\" to be set to a value of 0, which is then passed to the \"div_s64\" function when tc-cbs is disabled. This leads to a zero-division error. When tc-cbs is disabled, the idleslope, sendslope, and credit values the credit values are not required to be configured. Therefore, adding a return statement after setting the txQ mode to DCB when tc-cbs is disabled would prevent a zero-division error.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49978", "url": "https://ubuntu.com/security/CVE-2024-49978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gso: fix udp gso fraglist segmentation after pull from frag_list Detect gso fraglist skbs with corrupted geometry (see below) and pass these to skb_segment instead of skb_segment_list, as the first can segment them correctly. 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 these skbs, breaking these invariants. In extreme cases they pull all data into skb linear. For UDP, this causes a NULL ptr deref in __udpv4_gso_segment_list_csum at udp_hdr(seg->next)->dest. Detect invalid geometry due to pull, by checking head_skb size. Don't just drop, as this may blackhole a destination. Convert to be able to pass to regular skb_segment.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49979", "url": "https://ubuntu.com/security/CVE-2024-49979", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gso: fix tcp fraglist segmentation after pull from frag_list Detect tcp gso fraglist skbs with corrupted geometry (see below) and pass these to skb_segment instead of skb_segment_list, as the first can segment them correctly. 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 these skbs, breaking these invariants. In extreme cases they pull all data into skb linear. For TCP, this causes a NULL ptr deref in __tcpv4_gso_segment_list_csum at tcp_hdr(seg->next). Detect invalid geometry due to pull, by checking head_skb size. Don't just drop, as this may blackhole a destination. Convert to be able to pass to regular skb_segment. Approach and description based on a patch by Willem de Bruijn.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49980", "url": "https://ubuntu.com/security/CVE-2024-49980", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vrf: revert \"vrf: Remove unnecessary RCU-bh critical section\" This reverts commit 504fc6f4f7f681d2a03aa5f68aad549d90eab853. dev_queue_xmit_nit is expected to be called with BH disabled. __dev_queue_xmit has the following: /* Disable soft irqs for various locks below. Also * stops preemption for RCU. */ rcu_read_lock_bh(); VRF must follow this invariant. The referenced commit removed this protection. Which triggered a lockdep warning: \t================================ \tWARNING: inconsistent lock state \t6.11.0 #1 Tainted: G W \t-------------------------------- \tinconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage. \tbtserver/134819 [HC0[0]:SC0[0]:HE1:SE1] takes: \tffff8882da30c118 (rlock-AF_PACKET){+.?.}-{2:2}, at: tpacket_rcv+0x863/0x3b30 \t{IN-SOFTIRQ-W} state was registered at: \t lock_acquire+0x19a/0x4f0 \t _raw_spin_lock+0x27/0x40 \t packet_rcv+0xa33/0x1320 \t __netif_receive_skb_core.constprop.0+0xcb0/0x3a90 \t __netif_receive_skb_list_core+0x2c9/0x890 \t netif_receive_skb_list_internal+0x610/0xcc0 [...] \tother info that might help us debug this: \t Possible unsafe locking scenario: \t CPU0 \t ---- \t lock(rlock-AF_PACKET); \t \t lock(rlock-AF_PACKET); \t *** DEADLOCK *** \tCall Trace: \t \t dump_stack_lvl+0x73/0xa0 \t mark_lock+0x102e/0x16b0 \t __lock_acquire+0x9ae/0x6170 \t lock_acquire+0x19a/0x4f0 \t _raw_spin_lock+0x27/0x40 \t tpacket_rcv+0x863/0x3b30 \t dev_queue_xmit_nit+0x709/0xa40 \t vrf_finish_direct+0x26e/0x340 [vrf] \t vrf_l3_out+0x5f4/0xe80 [vrf] \t __ip_local_out+0x51e/0x7a0 [...]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49981", "url": "https://ubuntu.com/security/CVE-2024-49981", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: venus: fix use after free bug in venus_remove due to race condition in venus_probe, core->work is bound with venus_sys_error_handler, which is used to handle error. The code use core->sys_err_done to make sync work. The core->work is started in venus_event_notify. If we call venus_remove, there might be an unfished work. The possible sequence is as follows: CPU0 CPU1 |venus_sys_error_handler venus_remove | hfi_destroy\t \t\t | venus_hfi_destroy\t | kfree(hdev);\t | |hfi_reinit \t\t\t\t\t |venus_hfi_queues_reinit |//use hdev Fix it by canceling the work in venus_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49956", "url": "https://ubuntu.com/security/CVE-2024-49956", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: fix double destroy_workqueue error When gfs2_fill_super() fails, destroy_workqueue() is called within gfs2_gl_hash_clear(), and the subsequent code path calls destroy_workqueue() on the same work queue again. This issue can be fixed by setting the work queue pointer to NULL after the first destroy_workqueue() call and checking for a NULL pointer before attempting to destroy the work queue again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50176", "url": "https://ubuntu.com/security/CVE-2024-50176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: k3-r5: Fix error handling when power-up failed By simply bailing out, the driver was violating its rule and internal assumptions that either both or no rproc should be initialized. E.g., this could cause the first core to be available but not the second one, leading to crashes on its shutdown later on while trying to dereference that second instance.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49982", "url": "https://ubuntu.com/security/CVE-2024-49982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: aoe: fix the potential use-after-free problem in more places For fixing CVE-2023-6270, f98364e92662 (\"aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts\") makes tx() calling dev_put() instead of doing in aoecmd_cfg_pkts(). It avoids that the tx() runs into use-after-free. Then Nicolai Stange found more places in aoe have potential use-after-free problem with tx(). e.g. revalidate(), aoecmd_ata_rw(), resend(), probe() and aoecmd_cfg_rsp(). Those functions also use aoenet_xmit() to push packet to tx queue. So they should also use dev_hold() to increase the refcnt of skb->dev. On the other hand, moving dev_put() to tx() causes that the refcnt of skb->dev be reduced to a negative value, because corresponding dev_hold() are not called in revalidate(), aoecmd_ata_rw(), resend(), probe(), and aoecmd_cfg_rsp(). This patch fixed this issue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49874", "url": "https://ubuntu.com/security/CVE-2024-49874", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: svc: Fix use after free vulnerability in svc_i3c_master Driver Due to Race Condition In the svc_i3c_master_probe function, &master->hj_work is bound with svc_i3c_master_hj_work, &master->ibi_work is bound with svc_i3c_master_ibi_work. And svc_i3c_master_ibi_work can start the hj_work, svc_i3c_master_irq_handler can start the ibi_work. If we remove the module which will call svc_i3c_master_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | svc_i3c_master_hj_work svc_i3c_master_remove | i3c_master_unregister(&master->base)| device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in svc_i3c_master_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49875", "url": "https://ubuntu.com/security/CVE-2024-49875", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: map the EBADMSG to nfserr_io to avoid warning Ext4 will throw -EBADMSG through ext4_readdir when a checksum error occurs, resulting in the following WARNING. Fix it by mapping EBADMSG to nfserr_io. nfsd_buffered_readdir iterate_dir // -EBADMSG -74 ext4_readdir // .iterate_shared ext4_dx_readdir ext4_htree_fill_tree htree_dirblock_to_tree ext4_read_dirblock __ext4_read_dirblock ext4_dirblock_csum_verify warn_no_space_for_csum __warn_no_space_for_csum return ERR_PTR(-EFSBADCRC) // -EBADMSG -74 nfserrno // WARNING [ 161.115610] ------------[ cut here ]------------ [ 161.116465] nfsd: non-standard errno: -74 [ 161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0 [ 161.118596] Modules linked in: [ 161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138 [ 161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qe mu.org 04/01/2014 [ 161.123601] RIP: 0010:nfserrno+0x9d/0xd0 [ 161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6 05 ce 2b 61 03 01 e8 99 20 d8 00 <0f> 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33 [ 161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286 [ 161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a [ 161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827 [ 161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021 [ 161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8 [ 161.135244] FS: 0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000 [ 161.136695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0 [ 161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 161.141519] PKRU: 55555554 [ 161.142076] Call Trace: [ 161.142575] ? __warn+0x9b/0x140 [ 161.143229] ? nfserrno+0x9d/0xd0 [ 161.143872] ? report_bug+0x125/0x150 [ 161.144595] ? handle_bug+0x41/0x90 [ 161.145284] ? exc_invalid_op+0x14/0x70 [ 161.146009] ? asm_exc_invalid_op+0x12/0x20 [ 161.146816] ? nfserrno+0x9d/0xd0 [ 161.147487] nfsd_buffered_readdir+0x28b/0x2b0 [ 161.148333] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.149258] ? nfsd_buffered_filldir+0xf0/0xf0 [ 161.150093] ? wait_for_concurrent_writes+0x170/0x170 [ 161.151004] ? generic_file_llseek_size+0x48/0x160 [ 161.151895] nfsd_readdir+0x132/0x190 [ 161.152606] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.153516] ? nfsd_unlink+0x380/0x380 [ 161.154256] ? override_creds+0x45/0x60 [ 161.155006] nfsd4_encode_readdir+0x21a/0x3d0 [ 161.155850] ? nfsd4_encode_readlink+0x210/0x210 [ 161.156731] ? write_bytes_to_xdr_buf+0x97/0xe0 [ 161.157598] ? __write_bytes_to_xdr_buf+0xd0/0xd0 [ 161.158494] ? lock_downgrade+0x90/0x90 [ 161.159232] ? nfs4svc_decode_voidarg+0x10/0x10 [ 161.160092] nfsd4_encode_operation+0x15a/0x440 [ 161.160959] nfsd4_proc_compound+0x718/0xe90 [ 161.161818] nfsd_dispatch+0x18e/0x2c0 [ 161.162586] svc_process_common+0x786/0xc50 [ 161.163403] ? nfsd_svc+0x380/0x380 [ 161.164137] ? svc_printk+0x160/0x160 [ 161.164846] ? svc_xprt_do_enqueue.part.0+0x365/0x380 [ 161.165808] ? nfsd_svc+0x380/0x380 [ 161.166523] ? rcu_is_watching+0x23/0x40 [ 161.167309] svc_process+0x1a5/0x200 [ 161.168019] nfsd+0x1f5/0x380 [ 161.168663] ? nfsd_shutdown_threads+0x260/0x260 [ 161.169554] kthread+0x1c4/0x210 [ 161.170224] ? kthread_insert_work_sanity_check+0x80/0x80 [ 161.171246] ret_from_fork+0x1f/0x30", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50013", "url": "https://ubuntu.com/security/CVE-2024-50013", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix memory leak in exfat_load_bitmap() If the first directory entry in the root directory is not a bitmap directory entry, 'bh' will not be released and reassigned, which will cause a memory leak.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49876", "url": "https://ubuntu.com/security/CVE-2024-49876", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: fix UAF around queue destruction We currently do stuff like queuing the final destruction step on a random system wq, which will outlive the driver instance. With bad timing we can teardown the driver with one or more work workqueue still being alive leading to various UAF splats. Add a fini step to ensure user queues are properly torn down. At this point GuC should already be nuked so queue itself should no longer be referenced from hw pov. v2 (Matt B) - Looks much safer to use a waitqueue and then just wait for the xa_array to become empty before triggering the drain. (cherry picked from commit 861108666cc0e999cffeab6aff17b662e68774e3)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49877", "url": "https://ubuntu.com/security/CVE-2024-49877", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate When doing cleanup, if flags without OCFS2_BH_READAHEAD, it may trigger NULL pointer dereference in the following ocfs2_set_buffer_uptodate() if bh is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49957", "url": "https://ubuntu.com/security/CVE-2024-49957", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix null-ptr-deref when journal load failed. During the mounting process, if journal_reset() fails because of too short journal, then lead to jbd2_journal_load() fails with NULL j_sb_buffer. Subsequently, ocfs2_journal_shutdown() calls jbd2_journal_flush()->jbd2_cleanup_journal_tail()-> __jbd2_update_log_tail()->jbd2_journal_update_sb_log_tail() ->lock_buffer(journal->j_sb_buffer), resulting in a null-pointer dereference error. To resolve this issue, we should check the JBD2_LOADED flag to ensure the journal was properly loaded. Additionally, use journal instead of osb->journal directly to simplify the code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49965", "url": "https://ubuntu.com/security/CVE-2024-49965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove unreasonable unlock in ocfs2_read_blocks Patch series \"Misc fixes for ocfs2_read_blocks\", v5. This series contains 2 fixes for ocfs2_read_blocks(). The first patch fix the issue reported by syzbot, which detects bad unlock balance in ocfs2_read_blocks(). The second patch fixes an issue reported by Heming Zhao when reviewing above fix. This patch (of 2): There was a lock release before exiting, so remove the unreasonable unlock.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49966", "url": "https://ubuntu.com/security/CVE-2024-49966", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: cancel dqi_sync_work before freeing oinfo ocfs2_global_read_info() will initialize and schedule dqi_sync_work at the end, if error occurs after successfully reading global quota, it will trigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled: ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16c This reports that there is an active delayed work when freeing oinfo in error handling, so cancel dqi_sync_work first. BTW, return status instead of -1 when .read_file_info fails.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49958", "url": "https://ubuntu.com/security/CVE-2024-49958", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reserve space for inline xattr before attaching reflink tree One of our customers reported a crash and a corrupted ocfs2 filesystem. The crash was due to the detection of corruption. Upon troubleshooting, the fsck -fn output showed the below corruption [EXTENT_LIST_FREE] Extent list in owner 33080590 claims 230 as the next free chain record, but fsck believes the largest valid value is 227. Clamp the next record value? n The stat output from the debugfs.ocfs2 showed the following corruption where the \"Next Free Rec:\" had overshot the \"Count:\" in the root metadata block. Inode: 33080590 Mode: 0640 Generation: 2619713622 (0x9c25a856) FS Generation: 904309833 (0x35e6ac49) CRC32: 00000000 ECC: 0000 Type: Regular Attr: 0x0 Flags: Valid Dynamic Features: (0x16) HasXattr InlineXattr Refcounted Extended Attributes Block: 0 Extended Attributes Inline Size: 256 User: 0 (root) Group: 0 (root) Size: 281320357888 Links: 1 Clusters: 141738 ctime: 0x66911b56 0x316edcb8 -- Fri Jul 12 06:02:30.829349048 2024 atime: 0x66911d6b 0x7f7a28d -- Fri Jul 12 06:11:23.133669517 2024 mtime: 0x66911b56 0x12ed75d7 -- Fri Jul 12 06:02:30.317552087 2024 dtime: 0x0 -- Wed Dec 31 17:00:00 1969 Refcount Block: 2777346 Last Extblk: 2886943 Orphan Slot: 0 Sub Alloc Slot: 0 Sub Alloc Bit: 14 Tree Depth: 1 Count: 227 Next Free Rec: 230 ## Offset Clusters Block# 0 0 2310 2776351 1 2310 2139 2777375 2 4449 1221 2778399 3 5670 731 2779423 4 6401 566 2780447 ....... .... ....... ....... .... ....... The issue was in the reflink workfow while reserving space for inline xattr. The problematic function is ocfs2_reflink_xattr_inline(). By the time this function is called the reflink tree is already recreated at the destination inode from the source inode. At this point, this function reserves space for inline xattrs at the destination inode without even checking if there is space at the root metadata block. It simply reduces the l_count from 243 to 227 thereby making space of 256 bytes for inline xattr whereas the inode already has extents beyond this index (in this case up to 230), thereby causing corruption. The fix for this is to reserve space for inline metadata at the destination inode before the reflink tree gets recreated. The customer has verified the fix.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49959", "url": "https://ubuntu.com/security/CVE-2024-49959", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail() to recover some journal space. But if an error occurs while executing jbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for free space right away, we try other branches, and if j_committing_transaction is NULL (i.e., the tid is 0), we will get the following complain: ============================================ JBD2: I/O error when updating journal superblock for sdd-8. __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available __jbd2_log_wait_for_space: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Call Trace: add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70 [...] ============================================ So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways. Note that this fix relies on commit 6f6a6fda2945 (\"jbd2: fix ocfs2 corrupt when updating journal superblock fails\") to make jbd2_cleanup_journal_tail return the correct error code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49878", "url": "https://ubuntu.com/security/CVE-2024-49878", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: resource: fix region_intersects() vs add_memory_driver_managed() On a system with CXL memory, the resource tree (/proc/iomem) related to CXL memory may look like something as follows. 490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem) Because drivers/dax/kmem.c calls add_memory_driver_managed() during onlining CXL memory, which makes \"System RAM (kmem)\" a descendant of \"CXL Window X\". This confuses region_intersects(), which expects all \"System RAM\" resources to be at the top level of iomem_resource. This can lead to bugs. For example, when the following command line is executed to write some memory in CXL memory range via /dev/mem, $ dd if=data of=/dev/mem bs=$((1 << 10)) seek=$((0x490000000 >> 10)) count=1 dd: error writing '/dev/mem': Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/s the command fails as expected. However, the error code is wrong. It should be \"Operation not permitted\" instead of \"Bad address\". More seriously, the /dev/mem permission checking in devmem_is_allowed() passes incorrectly. Although the accessing is prevented later because ioremap() isn't allowed to map system RAM, it is a potential security issue. During command executing, the following warning is reported in the kernel log for calling ioremap() on system RAM. ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d Call Trace: memremap+0xcb/0x184 xlate_dev_mem_ptr+0x25/0x2f write_mem+0x94/0xfb vfs_write+0x128/0x26d ksys_write+0xac/0xfe do_syscall_64+0x9a/0xfd entry_SYSCALL_64_after_hwframe+0x4b/0x53 The details of command execution process are as follows. In the above resource tree, \"System RAM\" is a descendant of \"CXL Window 0\" instead of a top level resource. So, region_intersects() will report no System RAM resources in the CXL memory region incorrectly, because it only checks the top level resources. Consequently, devmem_is_allowed() will return 1 (allow access via /dev/mem) for CXL memory region incorrectly. Fortunately, ioremap() doesn't allow to map System RAM and reject the access. So, region_intersects() needs to be fixed to work correctly with the resource tree with \"System RAM\" not at top level as above. To fix it, if we found a unmatched resource in the top level, we will continue to search matched resources in its descendant resources. So, we will not miss any matched resources in resource tree anymore. In the new implementation, an example resource tree |------------- \"CXL Window 0\" ------------| |-- \"System RAM\" --| will behave similar as the following fake resource tree for region_intersects(, IORESOURCE_SYSTEM_RAM, ), |-- \"System RAM\" --||-- \"CXL Window 0a\" --| Where \"CXL Window 0a\" is part of the original \"CXL Window 0\" that isn't covered by \"System RAM\".", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49879", "url": "https://ubuntu.com/security/CVE-2024-49879", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm: omapdrm: Add missing check for alloc_ordered_workqueue As it may return NULL pointer and cause NULL pointer dereference. Add check for the return value of alloc_ordered_workqueue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49880", "url": "https://ubuntu.com/security/CVE-2024-49880", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix off by one issue in alloc_flex_gd() Wesley reported an issue: ================================================================== EXT4-fs (dm-5): resizing filesystem from 7168 to 786432 blocks ------------[ cut here ]------------ kernel BUG at fs/ext4/resize.c:324! CPU: 9 UID: 0 PID: 3576 Comm: resize2fs Not tainted 6.11.0+ #27 RIP: 0010:ext4_resize_fs+0x1212/0x12d0 Call Trace: __ext4_ioctl+0x4e0/0x1800 ext4_ioctl+0x12/0x20 __x64_sys_ioctl+0x99/0xd0 x64_sys_call+0x1206/0x20d0 do_syscall_64+0x72/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e ================================================================== While reviewing the patch, Honza found that when adjusting resize_bg in alloc_flex_gd(), it was possible for flex_gd->resize_bg to be bigger than flexbg_size. The reproduction of the problem requires the following: o_group = flexbg_size * 2 * n; o_size = (o_group + 1) * group_size; n_group: [o_group + flexbg_size, o_group + flexbg_size * 2) o_size = (n_group + 1) * group_size; Take n=0,flexbg_size=16 as an example: last:15 |o---------------|--------------n-| o_group:0 resize to n_group:30 The corresponding reproducer is: img=test.img rm -f $img truncate -s 600M $img mkfs.ext4 -F $img -b 1024 -G 16 8M dev=`losetup -f --show $img` mkdir -p /tmp/test mount $dev /tmp/test resize2fs $dev 248M Delete the problematic plus 1 to fix the issue, and add a WARN_ON_ONCE() to prevent the issue from happening again. [ Note: another reproucer which this commit fixes is: img=test.img rm -f $img truncate -s 25MiB $img mkfs.ext4 -b 4096 -E nodiscard,lazy_itable_init=0,lazy_journal_init=0 $img truncate -s 3GiB $img dev=`losetup -f --show $img` mkdir -p /tmp/test mount $dev /tmp/test resize2fs $dev 3G umount $dev losetup -d $dev -- TYT ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49881", "url": "https://ubuntu.com/security/CVE-2024-49881", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: update orig_path in ext4_find_extent() In ext4_find_extent(), if the path is not big enough, we free it and set *orig_path to NULL. But after reallocating and successfully initializing the path, we don't update *orig_path, in which case the caller gets a valid path but a NULL ppath, and this may cause a NULL pointer dereference or a path memory leak. For example: ext4_split_extent path = *ppath = 2000 ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path = 2000); *orig_path = path = NULL; path = kcalloc() = 3000 ext4_split_extent_at(*ppath = NULL) path = *ppath; ex = path[depth].p_ext; // NULL pointer dereference! ================================================================== BUG: kernel NULL pointer dereference, address: 0000000000000010 CPU: 6 UID: 0 PID: 576 Comm: fsstress Not tainted 6.11.0-rc2-dirty #847 RIP: 0010:ext4_split_extent_at+0x6d/0x560 Call Trace: ext4_split_extent.isra.0+0xcb/0x1b0 ext4_ext_convert_to_initialized+0x168/0x6c0 ext4_ext_handle_unwritten_extents+0x325/0x4d0 ext4_ext_map_blocks+0x520/0xdb0 ext4_map_blocks+0x2b0/0x690 ext4_iomap_begin+0x20e/0x2c0 [...] ================================================================== Therefore, *orig_path is updated when the extent lookup succeeds, so that the caller can safely use path or *ppath.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50014", "url": "https://ubuntu.com/security/CVE-2024-50014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix access to uninitialised lock in fc replay path The following kernel trace can be triggered with fstest generic/629 when executed against a filesystem with fast-commit feature enabled: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x66/0x90 register_lock_class+0x759/0x7d0 __lock_acquire+0x85/0x2630 ? __find_get_block+0xb4/0x380 lock_acquire+0xd1/0x2d0 ? __ext4_journal_get_write_access+0xd5/0x160 _raw_spin_lock+0x33/0x40 ? __ext4_journal_get_write_access+0xd5/0x160 __ext4_journal_get_write_access+0xd5/0x160 ext4_reserve_inode_write+0x61/0xb0 __ext4_mark_inode_dirty+0x79/0x270 ? ext4_ext_replay_set_iblocks+0x2f8/0x450 ext4_ext_replay_set_iblocks+0x330/0x450 ext4_fc_replay+0x14c8/0x1540 ? jread+0x88/0x2e0 ? rcu_is_watching+0x11/0x40 do_one_pass+0x447/0xd00 jbd2_journal_recover+0x139/0x1b0 jbd2_journal_load+0x96/0x390 ext4_load_and_init_journal+0x253/0xd40 ext4_fill_super+0x2cc6/0x3180 ... In the replay path there's an attempt to lock sbi->s_bdev_wb_lock in function ext4_check_bdev_write_error(). Unfortunately, at this point this spinlock has not been initialized yet. Moving it's initialization to an earlier point in __ext4_fill_super() fixes this splat.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49960", "url": "https://ubuntu.com/security/CVE-2024-49960", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix timer use-after-free on failed mount Syzbot has found an ODEBUG bug in ext4_fill_super The del_timer_sync function cancels the s_err_report timer, which reminds about filesystem errors daily. We should guarantee the timer is no longer active before kfree(sbi). When filesystem mounting fails, the flow goes to failed_mount3, where an error occurs when ext4_stop_mmpd is called, causing a read I/O failure. This triggers the ext4_handle_error function that ultimately re-arms the timer, leaving the s_err_report timer active before kfree(sbi) is called. Fix the issue by canceling the s_err_report timer after calling ext4_stop_mmpd.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49882", "url": "https://ubuntu.com/security/CVE-2024-49882", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix double brelse() the buffer of the extents path In ext4_ext_try_to_merge_up(), set path[1].p_bh to NULL after it has been released, otherwise it may be released twice. An example of what triggers this is as follows: split2 map split1 |--------|-------|--------| ext4_ext_map_blocks ext4_ext_handle_unwritten_extents ext4_split_convert_extents // path->p_depth == 0 ext4_split_extent // 1. do split1 ext4_split_extent_at |ext4_ext_insert_extent | ext4_ext_create_new_leaf | ext4_ext_grow_indepth | le16_add_cpu(&neh->eh_depth, 1) | ext4_find_extent | // return -ENOMEM |// get error and try zeroout |path = ext4_find_extent | path->p_depth = 1 |ext4_ext_try_to_merge | ext4_ext_try_to_merge_up | path->p_depth = 0 | brelse(path[1].p_bh) ---> not set to NULL here |// zeroout success // 2. update path ext4_find_extent // 3. do split2 ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth le16_add_cpu(&neh->eh_depth, 1) ext4_find_extent path[0].p_bh = NULL; path->p_depth = 1 read_extent_tree_block ---> return err // path[1].p_bh is still the old value ext4_free_ext_path ext4_ext_drop_refs // path->p_depth == 1 brelse(path[1].p_bh) ---> brelse a buffer twice Finally got the following WARRNING when removing the buffer from lru: ============================================ VFS: brelse: Trying to free free buffer WARNING: CPU: 2 PID: 72 at fs/buffer.c:1241 __brelse+0x58/0x90 CPU: 2 PID: 72 Comm: kworker/u19:1 Not tainted 6.9.0-dirty #716 RIP: 0010:__brelse+0x58/0x90 Call Trace: __find_get_block+0x6e7/0x810 bdev_getblk+0x2b/0x480 __ext4_get_inode_loc+0x48a/0x1240 ext4_get_inode_loc+0xb2/0x150 ext4_reserve_inode_write+0xb7/0x230 __ext4_mark_inode_dirty+0x144/0x6a0 ext4_ext_insert_extent+0x9c8/0x3230 ext4_ext_map_blocks+0xf45/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] ============================================", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49883", "url": "https://ubuntu.com/security/CVE-2024-49883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: aovid use-after-free in ext4_ext_insert_extent() As Ojaswin mentioned in Link, in ext4_ext_insert_extent(), if the path is reallocated in ext4_ext_create_new_leaf(), we'll use the stale path and cause UAF. Below is a sample trace with dummy values: ext4_ext_insert_extent path = *ppath = 2000 ext4_ext_create_new_leaf(ppath) ext4_find_extent(ppath) path = *ppath = 2000 if (depth > path[0].p_maxdepth) kfree(path = 2000); *ppath = path = NULL; path = kcalloc() = 3000 *ppath = 3000; return path; /* here path is still 2000, UAF! */ eh = path[depth].p_hdr ================================================================== BUG: KASAN: slab-use-after-free in ext4_ext_insert_extent+0x26d4/0x3330 Read of size 8 at addr ffff8881027bf7d0 by task kworker/u36:1/179 CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 Not tainted 6.11.0-rc2-dirty #866 Call Trace: ext4_ext_insert_extent+0x26d4/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 [...] Allocated by task 179: ext4_find_extent+0x81c/0x1f70 ext4_ext_map_blocks+0x146/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...] Freed by task 179: kfree+0xcb/0x240 ext4_find_extent+0x7c0/0x1f70 ext4_ext_insert_extent+0xa26/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...] ================================================================== So use *ppath to update the path to avoid the above problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49983", "url": "https://ubuntu.com/security/CVE-2024-49983", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-free When calling ext4_force_split_extent_at() in ext4_ext_replay_update_ex(), the 'ppath' is updated but it is the 'path' that is freed, thus potentially triggering a double-free in the following process: ext4_ext_replay_update_ex ppath = path ext4_force_split_extent_at(&ppath) ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path) ---> path First freed *orig_path = path = NULL ---> null ppath kfree(path) ---> path double-free !!! So drop the unnecessary ppath and use path directly to avoid this problem. And use ext4_find_extent() directly to update path, avoiding unnecessary memory allocation and freeing. Also, propagate the error returned by ext4_find_extent() instead of using strange error codes.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50015", "url": "https://ubuntu.com/security/CVE-2024-50015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: dax: fix overflowing extents beyond inode size when partially writing The dax_iomap_rw() does two things in each iteration: map written blocks and copy user data to blocks. If the process is killed by user(See signal handling in dax_iomap_iter()), the copied data will be returned and added on inode size, which means that the length of written extents may exceed the inode size, then fsck will fail. An example is given as: dd if=/dev/urandom of=file bs=4M count=1 dax_iomap_rw iomap_iter // round 1 ext4_iomap_begin ext4_iomap_alloc // allocate 0~2M extents(written flag) dax_iomap_iter // copy 2M data iomap_iter // round 2 iomap_iter_advance iter->pos += iter->processed // iter->pos = 2M ext4_iomap_begin ext4_iomap_alloc // allocate 2~4M extents(written flag) dax_iomap_iter fatal_signal_pending done = iter->pos - iocb->ki_pos // done = 2M ext4_handle_inode_extension ext4_update_inode_size // inode size = 2M fsck reports: Inode 13, i_size is 2097152, should be 4194304. Fix? Fix the problem by truncating extents if the written length is smaller than expected.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49884", "url": "https://ubuntu.com/security/CVE-2024-49884", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix slab-use-after-free in ext4_split_extent_at() We hit the following use-after-free: ================================================================== BUG: KASAN: slab-use-after-free in ext4_split_extent_at+0xba8/0xcc0 Read of size 2 at addr ffff88810548ed08 by task kworker/u20:0/40 CPU: 0 PID: 40 Comm: kworker/u20:0 Not tainted 6.9.0-dirty #724 Call Trace: kasan_report+0x93/0xc0 ext4_split_extent_at+0xba8/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] Allocated by task 40: __kmalloc_noprof+0x1ac/0x480 ext4_find_extent+0xf3b/0x1e70 ext4_ext_map_blocks+0x188/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] Freed by task 40: kfree+0xf1/0x2b0 ext4_find_extent+0xa71/0x1e70 ext4_ext_insert_extent+0xa22/0x3260 ext4_split_extent_at+0x3ef/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] ================================================================== The flow of issue triggering is as follows: ext4_split_extent_at path = *ppath ext4_ext_insert_extent(ppath) ext4_ext_create_new_leaf(ppath) ext4_find_extent(orig_path) path = *orig_path read_extent_tree_block // return -ENOMEM or -EIO ext4_free_ext_path(path) kfree(path) *orig_path = NULL a. If err is -ENOMEM: ext4_ext_dirty(path + path->p_depth) // path use-after-free !!! b. If err is -EIO and we have EXT_DEBUG defined: ext4_ext_show_leaf(path) eh = path[depth].p_hdr // path also use-after-free !!! So when trying to zeroout or fix the extent length, call ext4_find_extent() to update the path. In addition we use *ppath directly as an ext4_ext_show_leaf() input to avoid possible use-after-free when EXT_DEBUG is defined, and to avoid unnecessary path updates.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49885", "url": "https://ubuntu.com/security/CVE-2024-49885", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm, slub: avoid zeroing kmalloc redzone Since commit 946fa0dbf2d8 (\"mm/slub: extend redzone check to extra allocated kmalloc space than requested\"), setting orig_size treats the wasted space (object_size - orig_size) as a redzone. However with init_on_free=1 we clear the full object->size, including the redzone. Additionally we clear the object metadata, including the stored orig_size, making it zero, which makes check_object() treat the whole object as a redzone. These issues lead to the following BUG report with \"slub_debug=FUZ init_on_free=1\": [ 0.000000] ============================================================================= [ 0.000000] BUG kmalloc-8 (Not tainted): kmalloc Redzone overwritten [ 0.000000] ----------------------------------------------------------------------------- [ 0.000000] [ 0.000000] 0xffff000010032858-0xffff00001003285f @offset=2136. First byte 0x0 instead of 0xcc [ 0.000000] FIX kmalloc-8: Restoring kmalloc Redzone 0xffff000010032858-0xffff00001003285f=0xcc [ 0.000000] Slab 0xfffffdffc0400c80 objects=36 used=23 fp=0xffff000010032a18 flags=0x3fffe0000000200(workingset|node=0|zone=0|lastcpupid=0x1ffff) [ 0.000000] Object 0xffff000010032858 @offset=2136 fp=0xffff0000100328c8 [ 0.000000] [ 0.000000] Redzone ffff000010032850: cc cc cc cc cc cc cc cc ........ [ 0.000000] Object ffff000010032858: cc cc cc cc cc cc cc cc ........ [ 0.000000] Redzone ffff000010032860: cc cc cc cc cc cc cc cc ........ [ 0.000000] Padding ffff0000100328b4: 00 00 00 00 00 00 00 00 00 00 00 00 ............ [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.11.0-rc3-next-20240814-00004-g61844c55c3f4 #144 [ 0.000000] Hardware name: NXP i.MX95 19X19 board (DT) [ 0.000000] Call trace: [ 0.000000] dump_backtrace+0x90/0xe8 [ 0.000000] show_stack+0x18/0x24 [ 0.000000] dump_stack_lvl+0x74/0x8c [ 0.000000] dump_stack+0x18/0x24 [ 0.000000] print_trailer+0x150/0x218 [ 0.000000] check_object+0xe4/0x454 [ 0.000000] free_to_partial_list+0x2f8/0x5ec To address the issue, use orig_size to clear the used area. And restore the value of orig_size after clear the remaining area. When CONFIG_SLUB_DEBUG not defined, (get_orig_size()' directly returns s->object_size. So when using memset to init the area, the size can simply be orig_size, as orig_size returns object_size when CONFIG_SLUB_DEBUG not enabled. And orig_size can never be bigger than object_size.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49961", "url": "https://ubuntu.com/security/CVE-2024-49961", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: ar0521: Use cansleep version of gpiod_set_value() If we use GPIO reset from I2C port expander, we must use *_cansleep() variant of GPIO functions. This was not done in ar0521_power_on()/ar0521_power_off() functions. Let's fix that. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 11 at drivers/gpio/gpiolib.c:3496 gpiod_set_value+0x74/0x7c Modules linked in: CPU: 0 PID: 11 Comm: kworker/u16:0 Not tainted 6.10.0 #53 Hardware name: Diasom DS-RK3568-SOM-EVB (DT) Workqueue: events_unbound deferred_probe_work_func pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : gpiod_set_value+0x74/0x7c lr : ar0521_power_on+0xcc/0x290 sp : ffffff8001d7ab70 x29: ffffff8001d7ab70 x28: ffffff80027dcc90 x27: ffffff8003c82000 x26: ffffff8003ca9250 x25: ffffffc080a39c60 x24: ffffff8003ca9088 x23: ffffff8002402720 x22: ffffff8003ca9080 x21: ffffff8003ca9088 x20: 0000000000000000 x19: ffffff8001eb2a00 x18: ffffff80efeeac80 x17: 756d2d6332692f30 x16: 0000000000000000 x15: 0000000000000000 x14: ffffff8001d91d40 x13: 0000000000000016 x12: ffffffc080e98930 x11: ffffff8001eb2880 x10: 0000000000000890 x9 : ffffff8001d7a9f0 x8 : ffffff8001d92570 x7 : ffffff80efeeac80 x6 : 000000003fc6e780 x5 : ffffff8001d91c80 x4 : 0000000000000002 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000001 Call trace: gpiod_set_value+0x74/0x7c ar0521_power_on+0xcc/0x290 ...", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49985", "url": "https://ubuntu.com/security/CVE-2024-49985", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume In case there is any sort of clock controller attached to this I2C bus controller, for example Versaclock or even an AIC32x4 I2C codec, then an I2C transfer triggered from the clock controller clk_ops .prepare callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex. This is because the clock controller first grabs the prepare_lock mutex and then performs the prepare operation, including its I2C access. The I2C access resumes this I2C bus controller via .runtime_resume callback, which calls clk_prepare_enable(), which attempts to grab the prepare_lock mutex again and deadlocks. Since the clock are already prepared since probe() and unprepared in remove(), use simple clk_enable()/clk_disable() calls to enable and disable the clock on runtime suspend and resume, to avoid hitting the prepare_lock mutex.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49886", "url": "https://ubuntu.com/security/CVE-2024-49886", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bug Attaching SST PCI device to VM causes \"BUG: KASAN: slab-out-of-bounds\". kasan report: [ 19.411889] ================================================================== [ 19.413702] BUG: KASAN: slab-out-of-bounds in _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.415634] Read of size 8 at addr ffff888829e65200 by task cpuhp/16/113 [ 19.417368] [ 19.418627] CPU: 16 PID: 113 Comm: cpuhp/16 Tainted: G E 6.9.0 #10 [ 19.420435] Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.20192059.B64.2207280713 07/28/2022 [ 19.422687] Call Trace: [ 19.424091] [ 19.425448] dump_stack_lvl+0x5d/0x80 [ 19.426963] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.428694] print_report+0x19d/0x52e [ 19.430206] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 19.431837] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.433539] kasan_report+0xf0/0x170 [ 19.435019] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.436709] _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.438379] ? __pfx_sched_clock_cpu+0x10/0x10 [ 19.439910] isst_if_cpu_online+0x406/0x58f [isst_if_common] [ 19.441573] ? __pfx_isst_if_cpu_online+0x10/0x10 [isst_if_common] [ 19.443263] ? ttwu_queue_wakelist+0x2c1/0x360 [ 19.444797] cpuhp_invoke_callback+0x221/0xec0 [ 19.446337] cpuhp_thread_fun+0x21b/0x610 [ 19.447814] ? __pfx_cpuhp_thread_fun+0x10/0x10 [ 19.449354] smpboot_thread_fn+0x2e7/0x6e0 [ 19.450859] ? __pfx_smpboot_thread_fn+0x10/0x10 [ 19.452405] kthread+0x29c/0x350 [ 19.453817] ? __pfx_kthread+0x10/0x10 [ 19.455253] ret_from_fork+0x31/0x70 [ 19.456685] ? __pfx_kthread+0x10/0x10 [ 19.458114] ret_from_fork_asm+0x1a/0x30 [ 19.459573] [ 19.460853] [ 19.462055] Allocated by task 1198: [ 19.463410] kasan_save_stack+0x30/0x50 [ 19.464788] kasan_save_track+0x14/0x30 [ 19.466139] __kasan_kmalloc+0xaa/0xb0 [ 19.467465] __kmalloc+0x1cd/0x470 [ 19.468748] isst_if_cdev_register+0x1da/0x350 [isst_if_common] [ 19.470233] isst_if_mbox_init+0x108/0xff0 [isst_if_mbox_msr] [ 19.471670] do_one_initcall+0xa4/0x380 [ 19.472903] do_init_module+0x238/0x760 [ 19.474105] load_module+0x5239/0x6f00 [ 19.475285] init_module_from_file+0xd1/0x130 [ 19.476506] idempotent_init_module+0x23b/0x650 [ 19.477725] __x64_sys_finit_module+0xbe/0x130 [ 19.476506] idempotent_init_module+0x23b/0x650 [ 19.477725] __x64_sys_finit_module+0xbe/0x130 [ 19.478920] do_syscall_64+0x82/0x160 [ 19.480036] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 19.481292] [ 19.482205] The buggy address belongs to the object at ffff888829e65000 which belongs to the cache kmalloc-512 of size 512 [ 19.484818] The buggy address is located 0 bytes to the right of allocated 512-byte region [ffff888829e65000, ffff888829e65200) [ 19.487447] [ 19.488328] The buggy address belongs to the physical page: [ 19.489569] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888829e60c00 pfn:0x829e60 [ 19.491140] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [ 19.492466] anon flags: 0x57ffffc0000840(slab|head|node=1|zone=2|lastcpupid=0x1fffff) [ 19.493914] page_type: 0xffffffff() [ 19.494988] raw: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [ 19.496451] raw: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [ 19.497906] head: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [ 19.499379] head: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [ 19.500844] head: 0057ffffc0000003 ffffea0020a79801 ffffea0020a79848 00000000ffffffff [ 19.502316] head: 0000000800000000 0000000000000000 00000000ffffffff 0000000000000000 [ 19.503784] page dumped because: k ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49986", "url": "https://ubuntu.com/security/CVE-2024-49986", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: x86-android-tablets: Fix use after free on platform_device_register() errors x86_android_tablet_remove() frees the pdevs[] array, so it should not be used after calling x86_android_tablet_remove(). When platform_device_register() fails, store the pdevs[x] PTR_ERR() value into the local ret variable before calling x86_android_tablet_remove() to avoid using pdevs[] after it has been freed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49887", "url": "https://ubuntu.com/security/CVE-2024-49887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to don't panic system for no free segment fault injection f2fs: fix to don't panic system for no free segment fault injection syzbot reports a f2fs bug as below: F2FS-fs (loop0): inject no free segment in get_new_segment of __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3167 F2FS-fs (loop0): Stopped filesystem due to reason: 7 ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2748! CPU: 0 UID: 0 PID: 5109 Comm: syz-executor304 Not tainted 6.11.0-rc6-syzkaller-00363-g89f5e14d05b4 #0 RIP: 0010:get_new_segment fs/f2fs/segment.c:2748 [inline] RIP: 0010:new_curseg+0x1f61/0x1f70 fs/f2fs/segment.c:2836 Call Trace: __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3167 f2fs_allocate_new_section fs/f2fs/segment.c:3181 [inline] f2fs_allocate_pinning_section+0xfa/0x4e0 fs/f2fs/segment.c:3195 f2fs_expand_inode_data+0x5d6/0xbb0 fs/f2fs/file.c:1799 f2fs_fallocate+0x448/0x960 fs/f2fs/file.c:1903 vfs_fallocate+0x553/0x6c0 fs/open.c:334 do_vfs_ioctl+0x2592/0x2e50 fs/ioctl.c:886 __do_sys_ioctl fs/ioctl.c:905 [inline] __se_sys_ioctl+0x81/0x170 fs/ioctl.c:893 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: 0010:get_new_segment fs/f2fs/segment.c:2748 [inline] RIP: 0010:new_curseg+0x1f61/0x1f70 fs/f2fs/segment.c:2836 The root cause is when we inject no free segment fault into f2fs, we should not panic system, fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49888", "url": "https://ubuntu.com/security/CVE-2024-49888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix a sdiv overflow issue Zac Ecob reported a problem where a bpf program may cause kernel crash due to the following error: Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI The failure is due to the below signed divide: LLONG_MIN/-1 where LLONG_MIN equals to -9,223,372,036,854,775,808. LLONG_MIN/-1 is supposed to give a positive number 9,223,372,036,854,775,808, but it is impossible since for 64-bit system, the maximum positive number is 9,223,372,036,854,775,807. On x86_64, LLONG_MIN/-1 will cause a kernel exception. On arm64, the result for LLONG_MIN/-1 is LLONG_MIN. Further investigation found all the following sdiv/smod cases may trigger an exception when bpf program is running on x86_64 platform: - LLONG_MIN/-1 for 64bit operation - INT_MIN/-1 for 32bit operation - LLONG_MIN%-1 for 64bit operation - INT_MIN%-1 for 32bit operation where -1 can be an immediate or in a register. On arm64, there are no exceptions: - LLONG_MIN/-1 = LLONG_MIN - INT_MIN/-1 = INT_MIN - LLONG_MIN%-1 = 0 - INT_MIN%-1 = 0 where -1 can be an immediate or in a register. Insn patching is needed to handle the above cases and the patched codes produced results aligned with above arm64 result. The below are pseudo codes to handle sdiv/smod exceptions including both divisor -1 and divisor 0 and the divisor is stored in a register. sdiv: tmp = rX tmp += 1 /* [-1, 0] -> [0, 1] if tmp >(unsigned) 1 goto L2 if tmp == 0 goto L1 rY = 0 L1: rY = -rY; goto L3 L2: rY /= rX L3: smod: tmp = rX tmp += 1 /* [-1, 0] -> [0, 1] if tmp >(unsigned) 1 goto L1 if tmp == 1 (is64 ? goto L2 : goto L3) rY = 0; goto L2 L1: rY %= rX L2: goto L4 // only when !is64 L3: wY = wY // only when !is64 L4: [1] https://lore.kernel.org/bpf/tPJLTEh7S_DxFEqAI2Ji5MBSoZVg7_G-Py2iaZpAaWtM961fFTWtsnlzwvTbzBzaUzwQAoNATXKUlt0LZOFgnDcIyKCswAnAGdUF3LBrhGQ=@protonmail.com/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49987", "url": "https://ubuntu.com/security/CVE-2024-49987", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpftool: Fix undefined behavior in qsort(NULL, 0, ...) When netfilter has no entry to display, qsort is called with qsort(NULL, 0, ...). This results in undefined behavior, as UBSan reports: net.c:827:2: runtime error: null pointer passed as argument 1, which is declared to never be null Although the C standard does not explicitly state whether calling qsort with a NULL pointer when the size is 0 constitutes undefined behavior, Section 7.1.4 of the C standard (Use of library functions) mentions: \"Each of the following statements applies unless explicitly stated otherwise in the detailed descriptions that follow: If an argument to a function has an invalid value (such as a value outside the domain of the function, or a pointer outside the address space of the program, or a null pointer, or a pointer to non-modifiable storage when the corresponding parameter is not const-qualified) or a type (after promotion) not expected by a function with variable number of arguments, the behavior is undefined.\" To avoid this, add an early return when nf_link_info is NULL to prevent calling qsort with a NULL pointer.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50006", "url": "https://ubuntu.com/security/CVE-2024-50006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix i_data_sem unlock order in ext4_ind_migrate() Fuzzing reports a possible deadlock in jbd2_log_wait_commit. This issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to require synchronous updates because the file descriptor is opened with O_SYNC. This can lead to the jbd2_journal_stop() function calling jbd2_might_wait_for_commit(), potentially causing a deadlock if the EXT4_IOC_MIGRATE call races with a write(2) system call. This problem only arises when CONFIG_PROVE_LOCKING is enabled. In this case, the jbd2_might_wait_for_commit macro locks jbd2_handle in the jbd2_journal_stop function while i_data_sem is locked. This triggers lockdep because the jbd2_journal_start function might also lock the same jbd2_handle simultaneously. Found by Linux Verification Center (linuxtesting.org) with syzkaller. Rule: add", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49889", "url": "https://ubuntu.com/security/CVE-2024-49889", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid use-after-free in ext4_ext_show_leaf() In ext4_find_extent(), path may be freed by error or be reallocated, so using a previously saved *ppath may have been freed and thus may trigger use-after-free, as follows: ext4_split_extent path = *ppath; ext4_split_extent_at(ppath) path = ext4_find_extent(ppath) ext4_split_extent_at(ppath) // ext4_find_extent fails to free path // but zeroout succeeds ext4_ext_show_leaf(inode, path) eh = path[depth].p_hdr // path use-after-free !!! Similar to ext4_split_extent_at(), we use *ppath directly as an input to ext4_ext_show_leaf(). Fix a spelling error by the way. Same problem in ext4_ext_handle_unwritten_extents(). Since 'path' is only used in ext4_ext_show_leaf(), remove 'path' and use *ppath directly. This issue is triggered only when EXT_DEBUG is defined and therefore does not affect functionality.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49968", "url": "https://ubuntu.com/security/CVE-2024-49968", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: filesystems without casefold feature cannot be mounted with siphash When mounting the ext4 filesystem, if the default hash version is set to DX_HASH_SIPHASH but the casefold feature is not set, exit the mounting.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49988", "url": "https://ubuntu.com/security/CVE-2024-49988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: add refcnt to ksmbd_conn struct When sending an oplock break request, opinfo->conn is used, But freed ->conn can be used on multichannel. This patch add a reference count to the ksmbd_conn struct so that it can be freed when it is no longer used.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49890", "url": "https://ubuntu.com/security/CVE-2024-49890", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: ensure the fw_info is not null before using it This resolves the dereference null return value warning reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49891", "url": "https://ubuntu.com/security/CVE-2024-49891", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata paths When the HBA is undergoing a reset or is handling an errata event, NULL ptr dereference crashes may occur in routines such as lpfc_sli_flush_io_rings(), lpfc_dev_loss_tmo_callbk(), or lpfc_abort_handler(). Add NULL ptr checks before dereferencing hdwq pointers that may have been freed due to operations colliding with a reset or errata event handler.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49892", "url": "https://ubuntu.com/security/CVE-2024-49892", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize get_bytes_per_element's default to 1 Variables, used as denominators and maybe not assigned to other values, should not be 0. bytes_per_element_y & bytes_per_element_c are initialized by get_bytes_per_element() which should never return 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50016", "url": "https://ubuntu.com/security/CVE-2024-50016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Avoid overflow assignment in link_dp_cts sampling_rate is an uint8_t but is assigned an unsigned int, and thus it can overflow. As a result, sampling_rate is changed to uint32_t. Similarly, LINK_QUAL_PATTERN_SET has a size of 2 bits, and it should only be assigned to a value less or equal than 4. This fixes 2 INTEGER_OVERFLOW issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49893", "url": "https://ubuntu.com/security/CVE-2024-49893", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check stream_status before it is used [WHAT & HOW] dc_state_get_stream_status can return null, and therefore null must be checked before stream_status is used. This fixes 1 NULL_RETURNS issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49969", "url": "https://ubuntu.com/security/CVE-2024-49969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 color transformation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_hw_format` function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:180 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:181 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:182 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49970", "url": "https://ubuntu.com/security/CVE-2024-49970", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Implement bounds check for stream encoder creation in DCN401 'stream_enc_regs' array is an array of dcn10_stream_enc_registers structures. The array is initialized with four elements, corresponding to the four calls to stream_enc_regs() in the array initializer. This means that valid indices for this array are 0, 1, 2, and 3. The error message 'stream_enc_regs' 4 <= 5 below, is indicating that there is an attempt to access this array with an index of 5, which is out of bounds. This could lead to undefined behavior Here, eng_id is used as an index to access the stream_enc_regs array. If eng_id is 5, this would result in an out-of-bounds access on the stream_enc_regs array. Thus fixing Buffer overflow error in dcn401_stream_encoder_create Found by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn401/dcn401_resource.c:1209 dcn401_stream_encoder_create() error: buffer overflow 'stream_enc_regs' 4 <= 5", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49894", "url": "https://ubuntu.com/security/CVE-2024-49894", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in degamma hardware format translation Fixes index out of bounds issue in `cm_helper_translate_curve_to_degamma_hw_format` function. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49895", "url": "https://ubuntu.com/security/CVE-2024-49895", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format translation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_degamma_hw_format` function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:338 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:339 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:340 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49971", "url": "https://ubuntu.com/security/CVE-2024-49971", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Increase array size of dummy_boolean [WHY] dml2_core_shared_mode_support and dml_core_mode_support access the third element of dummy_boolean, i.e. hw_debug5 = &s->dummy_boolean[2], when dummy_boolean has size of 2. Any assignment to hw_debug5 causes an OVERRUN. [HOW] Increase dummy_boolean's array size to 3. This fixes 2 OVERRUN issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49972", "url": "https://ubuntu.com/security/CVE-2024-49972", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Deallocate DML memory if allocation fails [Why] When DC state create DML memory allocation fails, memory is not deallocated subsequently, resulting in uninitialized structure that is not NULL. [How] Deallocate memory if DML memory allocation fails.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49896", "url": "https://ubuntu.com/security/CVE-2024-49896", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check stream before comparing them [WHAT & HOW] amdgpu_dm can pass a null stream to dc_is_stream_unchanged. It is necessary to check for null before dereferencing them. This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49897", "url": "https://ubuntu.com/security/CVE-2024-49897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check phantom_stream before it is used dcn32_enable_phantom_stream can return null, so returned value must be checked before used. This fixes 1 NULL_RETURNS issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49898", "url": "https://ubuntu.com/security/CVE-2024-49898", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null-initialized variables [WHAT & HOW] drr_timing and subvp_pipe are initialized to null and they are not always assigned new values. It is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49899", "url": "https://ubuntu.com/security/CVE-2024-49899", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize denominators' default to 1 [WHAT & HOW] Variables used as denominators and maybe not assigned to other values, should not be 0. Change their default to 1 so they are never 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49900", "url": "https://ubuntu.com/security/CVE-2024-49900", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uninit-value access of new_ea in ea_buffer syzbot reports that lzo1x_1_do_compress is using uninit-value: ===================================================== BUG: KMSAN: uninit-value in lzo1x_1_do_compress+0x19f9/0x2510 lib/lzo/lzo1x_compress.c:178 ... Uninit was stored to memory at: ea_put fs/jfs/xattr.c:639 [inline] ... Local variable ea_buf created at: __jfs_setxattr+0x5d/0x1ae0 fs/jfs/xattr.c:662 __jfs_xattr_set+0xe6/0x1f0 fs/jfs/xattr.c:934 ===================================================== The reason is ea_buf->new_ea is not initialized properly. Fix this by using memset to empty its content at the beginning in ea_get().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49901", "url": "https://ubuntu.com/security/CVE-2024-49901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm/adreno: Assign msm_gpu->pdev earlier to avoid nullptrs There are some cases, such as the one uncovered by Commit 46d4efcccc68 (\"drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails\") where msm_gpu_cleanup() : platform_set_drvdata(gpu->pdev, NULL); is called on gpu->pdev == NULL, as the GPU device has not been fully initialized yet. Turns out that there's more than just the aforementioned path that causes this to happen (e.g. the case when there's speedbin data in the catalog, but opp-supported-hw is missing in DT). Assigning msm_gpu->pdev earlier seems like the least painful solution to this, therefore do so. Patchwork: https://patchwork.freedesktop.org/patch/602742/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49902", "url": "https://ubuntu.com/security/CVE-2024-49902", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: check if leafidx greater than num leaves per dmap tree syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf. Shaggy: Modified sanity check to apply to control pages as well as leaf pages.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49903", "url": "https://ubuntu.com/security/CVE-2024-49903", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uaf in dbFreeBits [syzbot reported] ================================================================== BUG: KASAN: slab-use-after-free in __mutex_lock_common kernel/locking/mutex.c:587 [inline] BUG: KASAN: slab-use-after-free in __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 Read of size 8 at addr ffff8880229254b0 by task syz-executor357/5216 CPU: 0 UID: 0 PID: 5216 Comm: syz-executor357 Not tainted 6.11.0-rc3-syzkaller-00156-gd7a5aa4b3c00 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 __mutex_lock_common kernel/locking/mutex.c:587 [inline] __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 dbFreeBits+0x7ea/0xd90 fs/jfs/jfs_dmap.c:2390 dbFreeDmap fs/jfs/jfs_dmap.c:2089 [inline] dbFree+0x35b/0x680 fs/jfs/jfs_dmap.c:409 dbDiscardAG+0x8a9/0xa20 fs/jfs/jfs_dmap.c:1650 jfs_ioc_trim+0x433/0x670 fs/jfs/jfs_discard.c:100 jfs_ioctl+0x2d0/0x3e0 fs/jfs/ioctl.c:131 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 Freed by task 5218: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object+0xe0/0x150 mm/kasan/common.c:240 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2252 [inline] slab_free mm/slub.c:4473 [inline] kfree+0x149/0x360 mm/slub.c:4594 dbUnmount+0x11d/0x190 fs/jfs/jfs_dmap.c:278 jfs_mount_rw+0x4ac/0x6a0 fs/jfs/jfs_mount.c:247 jfs_remount+0x3d1/0x6b0 fs/jfs/super.c:454 reconfigure_super+0x445/0x880 fs/super.c:1083 vfs_cmd_reconfigure fs/fsopen.c:263 [inline] vfs_fsconfig_locked fs/fsopen.c:292 [inline] __do_sys_fsconfig fs/fsopen.c:473 [inline] __se_sys_fsconfig+0xb6e/0xf80 fs/fsopen.c:345 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 [Analysis] There are two paths (dbUnmount and jfs_ioc_trim) that generate race condition when accessing bmap, which leads to the occurrence of uaf. Use the lock s_umount to synchronize them, in order to avoid uaf caused by race condition.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49904", "url": "https://ubuntu.com/security/CVE-2024-49904", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add list empty check to avoid null pointer issue Add list empty check to avoid null pointer issues in some corner cases. - list_for_each_entry_safe()", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49989", "url": "https://ubuntu.com/security/CVE-2024-49989", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix double free issue during amdgpu module unload Flexible endpoints use DIGs from available inflexible endpoints, so only the encoders of inflexible links need to be freed. Otherwise, a double free issue may occur when unloading the amdgpu module. [ 279.190523] RIP: 0010:__slab_free+0x152/0x2f0 [ 279.190577] Call Trace: [ 279.190580] [ 279.190582] ? show_regs+0x69/0x80 [ 279.190590] ? die+0x3b/0x90 [ 279.190595] ? do_trap+0xc8/0xe0 [ 279.190601] ? do_error_trap+0x73/0xa0 [ 279.190605] ? __slab_free+0x152/0x2f0 [ 279.190609] ? exc_invalid_op+0x56/0x70 [ 279.190616] ? __slab_free+0x152/0x2f0 [ 279.190642] ? asm_exc_invalid_op+0x1f/0x30 [ 279.190648] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191096] ? __slab_free+0x152/0x2f0 [ 279.191102] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191469] kfree+0x260/0x2b0 [ 279.191474] dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191821] link_destroy+0xd7/0x130 [amdgpu] [ 279.192248] dc_destruct+0x90/0x270 [amdgpu] [ 279.192666] dc_destroy+0x19/0x40 [amdgpu] [ 279.193020] amdgpu_dm_fini+0x16e/0x200 [amdgpu] [ 279.193432] dm_hw_fini+0x26/0x40 [amdgpu] [ 279.193795] amdgpu_device_fini_hw+0x24c/0x400 [amdgpu] [ 279.194108] amdgpu_driver_unload_kms+0x4f/0x70 [amdgpu] [ 279.194436] amdgpu_pci_remove+0x40/0x80 [amdgpu] [ 279.194632] pci_device_remove+0x3a/0xa0 [ 279.194638] device_remove+0x40/0x70 [ 279.194642] device_release_driver_internal+0x1ad/0x210 [ 279.194647] driver_detach+0x4e/0xa0 [ 279.194650] bus_remove_driver+0x6f/0xf0 [ 279.194653] driver_unregister+0x33/0x60 [ 279.194657] pci_unregister_driver+0x44/0x90 [ 279.194662] amdgpu_exit+0x19/0x1f0 [amdgpu] [ 279.194939] __do_sys_delete_module.isra.0+0x198/0x2f0 [ 279.194946] __x64_sys_delete_module+0x16/0x20 [ 279.194950] do_syscall_64+0x58/0x120 [ 279.194954] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 279.194980] ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49905", "url": "https://ubuntu.com/security/CVE-2024-49905", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for 'afb' in amdgpu_dm_plane_handle_cursor_update (v2) This commit adds a null check for the 'afb' variable in the amdgpu_dm_plane_handle_cursor_update function. Previously, 'afb' was assumed to be null, but was used later in the code without a null check. This could potentially lead to a null pointer dereference. Changes since v1: - Moved the null check for 'afb' to the line where 'afb' is used. (Alex) Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:1298 amdgpu_dm_plane_handle_cursor_update() error: we previously assumed 'afb' could be null (see line 1252)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49906", "url": "https://ubuntu.com/security/CVE-2024-49906", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before try to access it [why & how] Change the order of the pipe_ctx->plane_state check to ensure that plane_state is not null before accessing it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49907", "url": "https://ubuntu.com/security/CVE-2024-49907", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before using dc->clk_mgr [WHY & HOW] dc->clk_mgr is null checked previously in the same function, indicating it might be null. Passing \"dc\" to \"dc->hwss.apply_idle_power_optimizations\", which dereferences null \"dc->clk_mgr\". (The function pointer resolves to \"dcn35_apply_idle_power_optimizations\".) This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49908", "url": "https://ubuntu.com/security/CVE-2024-49908", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for 'afb' in amdgpu_dm_update_cursor (v2) This commit adds a null check for the 'afb' variable in the amdgpu_dm_update_cursor function. Previously, 'afb' was assumed to be null at line 8388, but was used later in the code without a null check. This could potentially lead to a null pointer dereference. Changes since v1: - Moved the null check for 'afb' to the line where 'afb' is used. (Alex) Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:8433 amdgpu_dm_update_cursor() \terror: we previously assumed 'afb' could be null (see line 8388)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50177", "url": "https://ubuntu.com/security/CVE-2024-50177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix a UBSAN warning in DML2.1 When programming phantom pipe, since cursor_width is explicity set to 0, this causes calculation logic to trigger overflow for an unsigned int triggering the kernel's UBSAN check as below: [ 40.962845] UBSAN: shift-out-of-bounds in /tmp/amd.EfpumTkO/amd/amdgpu/../display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c:3312:34 [ 40.962849] shift exponent 4294967170 is too large for 32-bit type 'unsigned int' [ 40.962852] CPU: 1 PID: 1670 Comm: gnome-shell Tainted: G W OE 6.5.0-41-generic #41~22.04.2-Ubuntu [ 40.962854] Hardware name: Gigabyte Technology Co., Ltd. X670E AORUS PRO X/X670E AORUS PRO X, BIOS F21 01/10/2024 [ 40.962856] Call Trace: [ 40.962857] [ 40.962860] dump_stack_lvl+0x48/0x70 [ 40.962870] dump_stack+0x10/0x20 [ 40.962872] __ubsan_handle_shift_out_of_bounds+0x1ac/0x360 [ 40.962878] calculate_cursor_req_attributes.cold+0x1b/0x28 [amdgpu] [ 40.963099] dml_core_mode_support+0x6b91/0x16bc0 [amdgpu] [ 40.963327] ? srso_alias_return_thunk+0x5/0x7f [ 40.963331] ? CalculateWatermarksMALLUseAndDRAMSpeedChangeSupport+0x18b8/0x2790 [amdgpu] [ 40.963534] ? srso_alias_return_thunk+0x5/0x7f [ 40.963536] ? dml_core_mode_support+0xb3db/0x16bc0 [amdgpu] [ 40.963730] dml2_core_calcs_mode_support_ex+0x2c/0x90 [amdgpu] [ 40.963906] ? srso_alias_return_thunk+0x5/0x7f [ 40.963909] ? dml2_core_calcs_mode_support_ex+0x2c/0x90 [amdgpu] [ 40.964078] core_dcn4_mode_support+0x72/0xbf0 [amdgpu] [ 40.964247] dml2_top_optimization_perform_optimization_phase+0x1d3/0x2a0 [amdgpu] [ 40.964420] dml2_build_mode_programming+0x23d/0x750 [amdgpu] [ 40.964587] dml21_validate+0x274/0x770 [amdgpu] [ 40.964761] ? srso_alias_return_thunk+0x5/0x7f [ 40.964763] ? resource_append_dpp_pipes_for_plane_composition+0x27c/0x3b0 [amdgpu] [ 40.964942] dml2_validate+0x504/0x750 [amdgpu] [ 40.965117] ? dml21_copy+0x95/0xb0 [amdgpu] [ 40.965291] ? srso_alias_return_thunk+0x5/0x7f [ 40.965295] dcn401_validate_bandwidth+0x4e/0x70 [amdgpu] [ 40.965491] update_planes_and_stream_state+0x38d/0x5c0 [amdgpu] [ 40.965672] update_planes_and_stream_v3+0x52/0x1e0 [amdgpu] [ 40.965845] ? srso_alias_return_thunk+0x5/0x7f [ 40.965849] dc_update_planes_and_stream+0x71/0xb0 [amdgpu] Fix this by adding a guard for checking cursor width before triggering the size calculation.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49909", "url": "https://ubuntu.com/security/CVE-2024-49909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn32_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn32_set_output_transfer_func function. Previously, set_output_gamma was being checked for null, but then it was being dereferenced without any null check. This could lead to a null pointer dereference if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49910", "url": "https://ubuntu.com/security/CVE-2024-49910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn401_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn401_set_output_transfer_func function. Previously, set_output_gamma was being checked for null, but then it was being dereferenced without any null check. This could lead to a null pointer dereference if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49911", "url": "https://ubuntu.com/security/CVE-2024-49911", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn20_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn20_set_output_transfer_func function. Previously, set_output_gamma was being checked for null at line 1030, but then it was being dereferenced without any null check at line 1048. This could potentially lead to a null pointer dereference error if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma at line 1048.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49912", "url": "https://ubuntu.com/security/CVE-2024-49912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Handle null 'stream_status' in 'planes_changed_for_existing_stream' This commit adds a null check for 'stream_status' in the function 'planes_changed_for_existing_stream'. Previously, the code assumed 'stream_status' could be null, but did not handle the case where it was actually null. This could lead to a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:3784 planes_changed_for_existing_stream() error: we previously assumed 'stream_status' could be null (see line 3774)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49913", "url": "https://ubuntu.com/security/CVE-2024-49913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for top_pipe_to_program in commit_planes_for_stream This commit addresses a null pointer dereference issue in the `commit_planes_for_stream` function at line 4140. The issue could occur when `top_pipe_to_program` is null. The fix adds a check to ensure `top_pipe_to_program` is not null before accessing its stream_res. This prevents a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:4140 commit_planes_for_stream() error: we previously assumed 'top_pipe_to_program' could be null (see line 3906)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49914", "url": "https://ubuntu.com/security/CVE-2024-49914", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for pipe_ctx->plane_state in dcn20_program_pipe This commit addresses a null pointer dereference issue in the `dcn20_program_pipe` function. The issue could occur when `pipe_ctx->plane_state` is null. The fix adds a check to ensure `pipe_ctx->plane_state` is not null before accessing. This prevents a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn20/dcn20_hwseq.c:1925 dcn20_program_pipe() error: we previously assumed 'pipe_ctx->plane_state' could be null (see line 1877)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49915", "url": "https://ubuntu.com/security/CVE-2024-49915", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr in dcn32_init_hw This commit addresses a potential null pointer dereference issue in the `dcn32_init_hw` function. The issue could occur when `dc->clk_mgr` is null. The fix adds a check to ensure `dc->clk_mgr` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn32/dcn32_hwseq.c:961 dcn32_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 782)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49916", "url": "https://ubuntu.com/security/CVE-2024-49916", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in dcn401_init_hw This commit addresses a potential null pointer dereference issue in the `dcn401_init_hw` function. The issue could occur when `dc->clk_mgr` or `dc->clk_mgr->funcs` is null. The fix adds a check to ensure `dc->clk_mgr` and `dc->clk_mgr->funcs` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn401/dcn401_hwseq.c:416 dcn401_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 225)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49917", "url": "https://ubuntu.com/security/CVE-2024-49917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in dcn30_init_hw This commit addresses a potential null pointer dereference issue in the `dcn30_init_hw` function. The issue could occur when `dc->clk_mgr` or `dc->clk_mgr->funcs` is null. The fix adds a check to ensure `dc->clk_mgr` and `dc->clk_mgr->funcs` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:789 dcn30_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 628)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49918", "url": "https://ubuntu.com/security/CVE-2024-49918", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for head_pipe in dcn32_acquire_idle_pipe_for_head_pipe_in_layer This commit addresses a potential null pointer dereference issue in the `dcn32_acquire_idle_pipe_for_head_pipe_in_layer` function. The issue could occur when `head_pipe` is null. The fix adds a check to ensure `head_pipe` is not null before asserting it. If `head_pipe` is null, the function returns NULL to prevent a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn32/dcn32_resource.c:2690 dcn32_acquire_idle_pipe_for_head_pipe_in_layer() error: we previously assumed 'head_pipe' could be null (see line 2681)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49919", "url": "https://ubuntu.com/security/CVE-2024-49919", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for head_pipe in dcn201_acquire_free_pipe_for_layer This commit addresses a potential null pointer dereference issue in the `dcn201_acquire_free_pipe_for_layer` function. The issue could occur when `head_pipe` is null. The fix adds a check to ensure `head_pipe` is not null before asserting it. If `head_pipe` is null, the function returns NULL to prevent a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn201/dcn201_resource.c:1016 dcn201_acquire_free_pipe_for_layer() error: we previously assumed 'head_pipe' could be null (see line 1010)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49991", "url": "https://ubuntu.com/security/CVE-2024-49991", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer Pass pointer reference to amdgpu_bo_unref to clear the correct pointer, otherwise amdgpu_bo_unref clear the local variable, the original pointer not set to NULL, this could cause use-after-free bug.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49920", "url": "https://ubuntu.com/security/CVE-2024-49920", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before multiple uses [WHAT & HOW] Poniters, such as stream_enc and dc->bw_vbios, are null checked previously in the same function, so Coverity warns \"implies that stream_enc and dc->bw_vbios might be null\". They are used multiple times in the subsequent code and need to be checked. This fixes 10 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49921", "url": "https://ubuntu.com/security/CVE-2024-49921", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before used [WHAT & HOW] Poniters, such as dc->clk_mgr, are null checked previously in the same function, so Coverity warns \"implies that \"dc->clk_mgr\" might be null\". As a result, these pointers need to be checked when used again. This fixes 10 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49922", "url": "https://ubuntu.com/security/CVE-2024-49922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before using them [WHAT & HOW] These pointers are null checked previously in the same function, indicating they might be null as reported by Coverity. As a result, they need to be checked when used again. This fixes 3 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49923", "url": "https://ubuntu.com/security/CVE-2024-49923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Pass non-null to dcn20_validate_apply_pipe_split_flags [WHAT & HOW] \"dcn20_validate_apply_pipe_split_flags\" dereferences merge, and thus it cannot be a null pointer. Let's pass a valid pointer to avoid null dereference. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49992", "url": "https://ubuntu.com/security/CVE-2024-49992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/stm: Avoid use-after-free issues with crtc and plane ltdc_load() calls functions drm_crtc_init_with_planes(), drm_universal_plane_init() and drm_encoder_init(). These functions should not be called with parameters allocated with devm_kzalloc() to avoid use-after-free issues [1]. Use allocations managed by the DRM framework. Found by Linux Verification Center (linuxtesting.org). [1] https://lore.kernel.org/lkml/u366i76e3qhh3ra5oxrtngjtm2u5lterkekcz6y2jkndhuxzli@diujon4h7qwb/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49993", "url": "https://ubuntu.com/security/CVE-2024-49993", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49924", "url": "https://ubuntu.com/security/CVE-2024-49924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: pxafb: Fix possible use after free in pxafb_task() In the pxafb_probe function, it calls the pxafb_init_fbinfo function, after which &fbi->task is associated with pxafb_task. Moreover, within this pxafb_init_fbinfo function, the pxafb_blank function within the &pxafb_ops struct is capable of scheduling work. If we remove the module which will call pxafb_remove to make cleanup, it will call unregister_framebuffer function which can call do_unregister_framebuffer to free fbi->fb through put_fb_info(fb_info), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | pxafb_task pxafb_remove | unregister_framebuffer(info) | do_unregister_framebuffer(fb_info) | put_fb_info(fb_info) | // free fbi->fb | set_ctrlr_state(fbi, state) | __pxafb_lcd_power(fbi, 0) | fbi->lcd_power(on, &fbi->fb.var) | //use fbi->fb Fix it by ensuring that the work is canceled before proceeding with the cleanup in pxafb_remove. Note that only root user can remove the driver at runtime.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49925", "url": "https://ubuntu.com/security/CVE-2024-49925", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: efifb: Register sysfs groups through driver core The driver core can register and cleanup sysfs groups already. Make use of that functionality to simplify the error handling and cleanup. Also avoid a UAF race during unregistering where the sysctl attributes were usable after the info struct was freed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49926", "url": "https://ubuntu.com/security/CVE-2024-49926", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rcu-tasks: Fix access non-existent percpu rtpcp variable in rcu_tasks_need_gpcb() For kernels built with CONFIG_FORCE_NR_CPUS=y, the nr_cpu_ids is defined as NR_CPUS instead of the number of possible cpus, this will cause the following system panic: smpboot: Allowing 4 CPUs, 0 hotplug CPUs ... setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:512 nr_node_ids:1 ... BUG: unable to handle page fault for address: ffffffff9911c8c8 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 15 Comm: rcu_tasks_trace Tainted: G W 6.6.21 #1 5dc7acf91a5e8e9ac9dcfc35bee0245691283ea6 RIP: 0010:rcu_tasks_need_gpcb+0x25d/0x2c0 RSP: 0018:ffffa371c00a3e60 EFLAGS: 00010082 CR2: ffffffff9911c8c8 CR3: 000000040fa20005 CR4: 00000000001706f0 Call Trace: ? __die+0x23/0x80 ? page_fault_oops+0xa4/0x180 ? exc_page_fault+0x152/0x180 ? asm_exc_page_fault+0x26/0x40 ? rcu_tasks_need_gpcb+0x25d/0x2c0 ? __pfx_rcu_tasks_kthread+0x40/0x40 rcu_tasks_one_gp+0x69/0x180 rcu_tasks_kthread+0x94/0xc0 kthread+0xe8/0x140 ? __pfx_kthread+0x40/0x40 ret_from_fork+0x34/0x80 ? __pfx_kthread+0x40/0x40 ret_from_fork_asm+0x1b/0x80 Considering that there may be holes in the CPU numbers, use the maximum possible cpu number, instead of nr_cpu_ids, for configuring enqueue and dequeue limits. [ neeraj.upadhyay: Fix htmldocs build error reported by Stephen Rothwell ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50007", "url": "https://ubuntu.com/security/CVE-2024-50007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: asihpi: Fix potential OOB array access ASIHPI driver stores some values in the static array upon a response from the driver, and its index depends on the firmware. We shouldn't trust it blindly. This patch adds a sanity check of the array index to fit in the array size.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50017", "url": "https://ubuntu.com/security/CVE-2024-50017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm/ident_map: Use gbpages only where full GB page should be mapped. When ident_pud_init() uses only GB pages to create identity maps, large ranges of addresses not actually requested can be included in the resulting table; a 4K request will map a full GB. This can include a lot of extra address space past that requested, including areas marked reserved by the BIOS. That allows processor speculation into reserved regions, that on UV systems can cause system halts. Only use GB pages when map creation requests include the full GB page of space. Fall back to using smaller 2M pages when only portions of a GB page are included in the request. No attempt is made to coalesce mapping requests. If a request requires a map entry at the 2M (pmd) level, subsequent mapping requests within the same 1G region will also be at the pmd level, even if adjacent or overlapping such requests could have been combined to map a full GB page. Existing usage starts with larger regions and then adds smaller regions, so this should not have any great consequence.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49927", "url": "https://ubuntu.com/security/CVE-2024-49927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/ioapic: Handle allocation failures gracefully Breno observed panics when using failslab under certain conditions during runtime: can not alloc irq_pin_list (-1,0,20) Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed panic+0x4e9/0x590 mp_irqdomain_alloc+0x9ab/0xa80 irq_domain_alloc_irqs_locked+0x25d/0x8d0 __irq_domain_alloc_irqs+0x80/0x110 mp_map_pin_to_irq+0x645/0x890 acpi_register_gsi_ioapic+0xe6/0x150 hpet_open+0x313/0x480 That's a pointless panic which is a leftover of the historic IO/APIC code which panic'ed during early boot when the interrupt allocation failed. The only place which might justify panic is the PIT/HPET timer_check() code which tries to figure out whether the timer interrupt is delivered through the IO/APIC. But that code does not require to handle interrupt allocation failures. If the interrupt cannot be allocated then timer delivery fails and it either panics due to that or falls back to legacy mode. Cure this by removing the panic wrapper around __add_pin_to_irq_node() and making mp_irqdomain_alloc() aware of the failure condition and handle it as any other failure in this function gracefully.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50008", "url": "https://ubuntu.com/security/CVE-2024-50008", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_cmd_802_11_scan_ext() Replace one-element array with a flexible-array member in `struct host_cmd_ds_802_11_scan_ext`. With this, fix the following warning: elo 16 17:51:58 surfacebook kernel: ------------[ cut here ]------------ elo 16 17:51:58 surfacebook kernel: memcpy: detected field-spanning write (size 243) of single field \"ext_scan->tlv_buffer\" at drivers/net/wireless/marvell/mwifiex/scan.c:2239 (size 1) elo 16 17:51:58 surfacebook kernel: WARNING: CPU: 0 PID: 498 at drivers/net/wireless/marvell/mwifiex/scan.c:2239 mwifiex_cmd_802_11_scan_ext+0x83/0x90 [mwifiex]", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50018", "url": "https://ubuntu.com/security/CVE-2024-50018", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49928", "url": "https://ubuntu.com/security/CVE-2024-49928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: avoid reading out of bounds when loading TX power FW elements Because the loop-expression will do one more time before getting false from cond-expression, the original code copied one more entry size beyond valid region. Fix it by moving the entry copy to loop-body.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50178", "url": "https://ubuntu.com/security/CVE-2024-50178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: loongson3: Use raw_smp_processor_id() in do_service_request() Use raw_smp_processor_id() instead of plain smp_processor_id() in do_service_request(), otherwise we may get some errors with the driver enabled: BUG: using smp_processor_id() in preemptible [00000000] code: (udev-worker)/208 caller is loongson3_cpufreq_probe+0x5c/0x250 [loongson3_cpufreq]", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50009", "url": "https://ubuntu.com/security/CVE-2024-50009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: amd-pstate: add check for cpufreq_cpu_get's return value cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it and return in case of error. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49994", "url": "https://ubuntu.com/security/CVE-2024-49994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix integer overflow in BLKSECDISCARD I independently rediscovered \tcommit 22d24a544b0d49bbcbd61c8c0eaf77d3c9297155 \tblock: fix overflow in blk_ioctl_discard() but for secure erase. Same problem: \tuint64_t r[2] = {512, 18446744073709551104ULL}; \tioctl(fd, BLKSECDISCARD, r); will enter near infinite loop inside blkdev_issue_secure_erase(): \ta.out: attempt to access beyond end of device \tloop0: rw=5, sector=3399043073, nr_sectors = 1024 limit=2048 \tbio_check_eod: 3286214 callbacks suppressed", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49929", "url": "https://ubuntu.com/security/CVE-2024-49929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: avoid NULL pointer dereference iwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta pointer is not NULL. It retrieves this pointer using iwl_mvm_sta_from_mac80211, which is dereferencing the ieee80211_sta pointer. If sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL pointer. Fix this by checking the sta pointer before retrieving the mvmsta from it. If sta is not NULL, then mvmsta isn't either.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49995", "url": "https://ubuntu.com/security/CVE-2024-49995", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: guard against string buffer overrun Smatch reports that copying media_name and if_name to name_parts may overwrite the destination. .../bearer.c:166 bearer_name_validate() error: strcpy() 'media_name' too large for 'name_parts->media_name' (32 vs 16) .../bearer.c:167 bearer_name_validate() error: strcpy() 'if_name' too large for 'name_parts->if_name' (1010102 vs 16) This does seem to be the case so guard against this possibility by using strscpy() and failing if truncation occurs. Introduced by commit b97bf3fd8f6a (\"[TIPC] Initial merge\") Compile tested only.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49962", "url": "https://ubuntu.com/security/CVE-2024-49962", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in acpi_db_convert_to_package() ACPICA commit 4d4547cf13cca820ff7e0f859ba83e1a610b9fd0 ACPI_ALLOCATE_ZEROED() may fail, elements might be NULL and will cause NULL pointer dereference later. [ rjw: Subject and changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49930", "url": "https://ubuntu.com/security/CVE-2024-49930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix array out-of-bound access in SoC stats Currently, the ath11k_soc_dp_stats::hal_reo_error array is defined with a maximum size of DP_REO_DST_RING_MAX. However, the ath11k_dp_process_rx() function access ath11k_soc_dp_stats::hal_reo_error using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath11k_dp_process_rx() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49931", "url": "https://ubuntu.com/security/CVE-2024-49931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix array out-of-bound access in SoC stats Currently, the ath12k_soc_dp_stats::hal_reo_error array is defined with a maximum size of DP_REO_DST_RING_MAX. However, the ath12k_dp_rx_process() function access ath12k_soc_dp_stats::hal_reo_error using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath12k_dp_rx_process() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49932", "url": "https://ubuntu.com/security/CVE-2024-49932", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: don't readahead the relocation inode on RST On relocation we're doing readahead on the relocation inode, but if the filesystem is backed by a RAID stripe tree we can get ENOENT (e.g. due to preallocated extents not being mapped in the RST) from the lookup. But readahead doesn't handle the error and submits invalid reads to the device, causing an assertion in the scatter-gather list code: BTRFS info (device nvme1n1): balance: start -d -m -s BTRFS info (device nvme1n1): relocating block group 6480920576 flags data|raid0 BTRFS error (device nvme1n1): cannot find raid-stripe for logical [6481928192, 6481969152] devid 2, profile raid0 ------------[ cut here ]------------ kernel BUG at include/linux/scatterlist.h:115! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 1012 Comm: btrfs Not tainted 6.10.0-rc7+ #567 RIP: 0010:__blk_rq_map_sg+0x339/0x4a0 RSP: 0018:ffffc90001a43820 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffea00045d4802 RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000 RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000001000 R12: ffff8881003d10b8 R13: ffffc90001a438f0 R14: 0000000000000000 R15: 0000000000003000 FS: 00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000002cd11000 CR3: 00000001109ea001 CR4: 0000000000370eb0 Call Trace: ? __die_body.cold+0x14/0x25 ? die+0x2e/0x50 ? do_trap+0xca/0x110 ? do_error_trap+0x65/0x80 ? __blk_rq_map_sg+0x339/0x4a0 ? exc_invalid_op+0x50/0x70 ? __blk_rq_map_sg+0x339/0x4a0 ? asm_exc_invalid_op+0x1a/0x20 ? __blk_rq_map_sg+0x339/0x4a0 nvme_prep_rq.part.0+0x9d/0x770 nvme_queue_rq+0x7d/0x1e0 __blk_mq_issue_directly+0x2a/0x90 ? blk_mq_get_budget_and_tag+0x61/0x90 blk_mq_try_issue_list_directly+0x56/0xf0 blk_mq_flush_plug_list.part.0+0x52b/0x5d0 __blk_flush_plug+0xc6/0x110 blk_finish_plug+0x28/0x40 read_pages+0x160/0x1c0 page_cache_ra_unbounded+0x109/0x180 relocate_file_extent_cluster+0x611/0x6a0 ? btrfs_search_slot+0xba4/0xd20 ? balance_dirty_pages_ratelimited_flags+0x26/0xb00 relocate_data_extent.constprop.0+0x134/0x160 relocate_block_group+0x3f2/0x500 btrfs_relocate_block_group+0x250/0x430 btrfs_relocate_chunk+0x3f/0x130 btrfs_balance+0x71b/0xef0 ? kmalloc_trace_noprof+0x13b/0x280 btrfs_ioctl+0x2c2e/0x3030 ? kvfree_call_rcu+0x1e6/0x340 ? list_lru_add_obj+0x66/0x80 ? mntput_no_expire+0x3a/0x220 __x64_sys_ioctl+0x96/0xc0 do_syscall_64+0x54/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fcc04514f9b Code: Unable to access opcode bytes at 0x7fcc04514f71. RSP: 002b:00007ffeba923370 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fcc04514f9b RDX: 00007ffeba923460 RSI: 00000000c4009420 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000013 R09: 0000000000000001 R10: 00007fcc043fbba8 R11: 0000000000000246 R12: 00007ffeba924fc5 R13: 00007ffeba923460 R14: 0000000000000002 R15: 00000000004d4bb0 Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:__blk_rq_map_sg+0x339/0x4a0 RSP: 0018:ffffc90001a43820 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffea00045d4802 RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000 RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000001000 R12: ffff8881003d10b8 R13: ffffc90001a438f0 R14: 0000000000000000 R15: 0000000000003000 FS: 00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcc04514f71 CR3: 00000001109ea001 CR4: 0000000000370eb0 Kernel p ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49933", "url": "https://ubuntu.com/security/CVE-2024-49933", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk_iocost: fix more out of bound shifts Recently running UBSAN caught few out of bound shifts in the ioc_forgive_debts() function: UBSAN: shift-out-of-bounds in block/blk-iocost.c:2142:38 shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long long') ... UBSAN: shift-out-of-bounds in block/blk-iocost.c:2144:30 shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long long') ... Call Trace: dump_stack_lvl+0xca/0x130 __ubsan_handle_shift_out_of_bounds+0x22c/0x280 ? __lock_acquire+0x6441/0x7c10 ioc_timer_fn+0x6cec/0x7750 ? blk_iocost_init+0x720/0x720 ? call_timer_fn+0x5d/0x470 call_timer_fn+0xfa/0x470 ? blk_iocost_init+0x720/0x720 __run_timer_base+0x519/0x700 ... Actual impact of this issue was not identified but I propose to fix the undefined behaviour. The proposed fix to prevent those out of bound shifts consist of precalculating exponent before using it the shift operations by taking min value from the actual exponent and maximum possible number of bits.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49934", "url": "https://ubuntu.com/security/CVE-2024-49934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/inode: Prevent dump_mapping() accessing invalid dentry.d_name.name It's observed that a crash occurs during hot-remove a memory device, in which user is accessing the hugetlb. See calltrace as following: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 14045 at arch/x86/mm/fault.c:1278 do_user_addr_fault+0x2a0/0x790 Modules linked in: kmem device_dax cxl_mem cxl_pmem cxl_port cxl_pci dax_hmem dax_pmem nd_pmem cxl_acpi nd_btt cxl_core crc32c_intel nvme virtiofs fuse nvme_core nfit libnvdimm dm_multipath scsi_dh_rdac scsi_dh_emc s mirror dm_region_hash dm_log dm_mod CPU: 1 PID: 14045 Comm: daxctl Not tainted 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:do_user_addr_fault+0x2a0/0x790 Code: 48 8b 00 a8 04 0f 84 b5 fe ff ff e9 1c ff ff ff 4c 89 e9 4c 89 e2 be 01 00 00 00 bf 02 00 00 00 e8 b5 ef 24 00 e9 42 fe ff ff <0f> 0b 48 83 c4 08 4c 89 ea 48 89 ee 4c 89 e7 5b 5d 41 5c 41 5d 41 RSP: 0000:ffffc90000a575f0 EFLAGS: 00010046 RAX: ffff88800c303600 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000001000 RSI: ffffffff82504162 RDI: ffffffff824b2c36 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffc90000a57658 R13: 0000000000001000 R14: ffff88800bc2e040 R15: 0000000000000000 FS: 00007f51cb57d880(0000) GS:ffff88807fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000001000 CR3: 00000000072e2004 CR4: 00000000001706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn+0x8d/0x190 ? do_user_addr_fault+0x2a0/0x790 ? report_bug+0x1c3/0x1d0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? do_user_addr_fault+0x2a0/0x790 ? exc_page_fault+0x31/0x200 exc_page_fault+0x68/0x200 <...snip...> BUG: unable to handle page fault for address: 0000000000001000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI ---[ end trace 0000000000000000 ]--- BUG: unable to handle page fault for address: 0000000000001000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 14045 Comm: daxctl Kdump: loaded Tainted: G W 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:dentry_name+0x1f4/0x440 <...snip...> ? dentry_name+0x2fa/0x440 vsnprintf+0x1f3/0x4f0 vprintk_store+0x23a/0x540 vprintk_emit+0x6d/0x330 _printk+0x58/0x80 dump_mapping+0x10b/0x1a0 ? __pfx_free_object_rcu+0x10/0x10 __dump_page+0x26b/0x3e0 ? vprintk_emit+0xe0/0x330 ? _printk+0x58/0x80 ? dump_page+0x17/0x50 dump_page+0x17/0x50 do_migrate_range+0x2f7/0x7f0 ? do_migrate_range+0x42/0x7f0 ? offline_pages+0x2f4/0x8c0 offline_pages+0x60a/0x8c0 memory_subsys_offline+0x9f/0x1c0 ? lockdep_hardirqs_on+0x77/0x100 ? _raw_spin_unlock_irqrestore+0x38/0x60 device_offline+0xe3/0x110 state_store+0x6e/0xc0 kernfs_fop_write_iter+0x143/0x200 vfs_write+0x39f/0x560 ksys_write+0x65/0xf0 do_syscall_64+0x62/0x130 Previously, some sanity check have been done in dump_mapping() before the print facility parsing '%pd' though, it's still possible to run into an invalid dentry.d_name.name. Since dump_mapping() only needs to dump the filename only, retrieve it by itself in a safer way to prevent an unnecessary crash. Note that either retrieving the filename with '%pd' or strncpy_from_kernel_nofault(), the filename could be unreliable.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49935", "url": "https://ubuntu.com/security/CVE-2024-49935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: PAD: fix crash in exit_round_robin() The kernel occasionally crashes in cpumask_clear_cpu(), which is called within exit_round_robin(), because when executing clear_bit(nr, addr) with nr set to 0xffffffff, the address calculation may cause misalignment within the memory, leading to access to an invalid memory address. ---------- BUG: unable to handle kernel paging request at ffffffffe0740618 ... CPU: 3 PID: 2919323 Comm: acpi_pad/14 Kdump: loaded Tainted: G OE X --------- - - 4.18.0-425.19.2.el8_7.x86_64 #1 ... RIP: 0010:power_saving_thread+0x313/0x411 [acpi_pad] Code: 89 cd 48 89 d3 eb d1 48 c7 c7 55 70 72 c0 e8 64 86 b0 e4 c6 05 0d a1 02 00 01 e9 bc fd ff ff 45 89 e4 42 8b 04 a5 20 82 72 c0 48 0f b3 05 f4 9c 01 00 42 c7 04 a5 20 82 72 c0 ff ff ff ff 31 RSP: 0018:ff72a5d51fa77ec8 EFLAGS: 00010202 RAX: 00000000ffffffff RBX: ff462981e5d8cb80 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246 RBP: ff46297556959d80 R08: 0000000000000382 R09: ff46297c8d0f38d8 R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000000e R13: 0000000000000000 R14: ffffffffffffffff R15: 000000000000000e FS: 0000000000000000(0000) GS:ff46297a800c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffe0740618 CR3: 0000007e20410004 CR4: 0000000000771ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? acpi_pad_add+0x120/0x120 [acpi_pad] kthread+0x10b/0x130 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x1f/0x40 ... CR2: ffffffffe0740618 crash> dis -lr ffffffffc0726923 ... /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 114 0xffffffffc0726918 :\tmov %r12d,%r12d /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 325 0xffffffffc072691b :\tmov -0x3f8d7de0(,%r12,4),%eax /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./arch/x86/include/asm/bitops.h: 80 0xffffffffc0726923 :\tlock btr %rax,0x19cf4(%rip) # 0xffffffffc0740620 crash> px tsk_in_cpu[14] $66 = 0xffffffff crash> px 0xffffffffc072692c+0x19cf4 $99 = 0xffffffffc0740620 crash> sym 0xffffffffc0740620 ffffffffc0740620 (b) pad_busy_cpus_bits [acpi_pad] crash> px pad_busy_cpus_bits[0] $42 = 0xfffc0 ---------- To fix this, ensure that tsk_in_cpu[tsk_index] != -1 before calling cpumask_clear_cpu() in exit_round_robin(), just as it is done in round_robin_cpu(). [ rjw: Subject edit, avoid updates to the same value ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49936", "url": "https://ubuntu.com/security/CVE-2024-49936", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/xen-netback: prevent UAF in xenvif_flush_hash() During the list_for_each_entry_rcu iteration call of xenvif_flush_hash, kfree_rcu does not exist inside the rcu read critical section, so if kfree_rcu is called when the rcu grace period ends during the iteration, UAF occurs when accessing head->next after the entry becomes free. Therefore, to solve this, you need to change it to list_for_each_entry_safe.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49937", "url": "https://ubuntu.com/security/CVE-2024-49937", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Set correct chandef when starting CAC When starting CAC in a mode other than AP mode, it return a \"WARNING: CPU: 0 PID: 63 at cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]\" caused by the chandef.chan being null at the end of CAC. Solution: Ensure the channel definition is set for the different modes when starting CAC to avoid getting a NULL 'chan' at the end of CAC. Call Trace: ? show_regs.part.0+0x14/0x16 ? __warn+0x67/0xc0 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? report_bug+0xa7/0x130 ? exc_overflow+0x30/0x30 ? handle_bug+0x27/0x50 ? exc_invalid_op+0x18/0x60 ? handle_exception+0xf6/0xf6 ? exc_overflow+0x30/0x30 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? exc_overflow+0x30/0x30 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? regulatory_propagate_dfs_state.cold+0x1b/0x4c [cfg80211] ? cfg80211_propagate_cac_done_wk+0x1a/0x30 [cfg80211] ? process_one_work+0x165/0x280 ? worker_thread+0x120/0x3f0 ? kthread+0xc2/0xf0 ? process_one_work+0x280/0x280 ? kthread_complete_and_exit+0x20/0x20 ? ret_from_fork+0x19/0x24 [shorten subject, remove OCB, reorder cases to match previous list]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49938", "url": "https://ubuntu.com/security/CVE-2024-49938", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmit Syzbot points out that skb_trim() has a sanity check on the existing length of the skb, which can be uninitialised in some error paths. The intent here is clearly just to reset the length to zero before resubmitting, so switch to calling __skb_set_length(skb, 0) directly. In addition, __skb_set_length() already contains a call to skb_reset_tail_pointer(), so remove the redundant call. The syzbot report came from ath9k_hif_usb_reg_in_cb(), but there's a similar usage of skb_trim() in ath9k_hif_usb_rx_cb(), change both while we're at it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49939", "url": "https://ubuntu.com/security/CVE-2024-49939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: avoid to add interface to list twice when SER If SER L2 occurs during the WoWLAN resume flow, the add interface flow is triggered by ieee80211_reconfig(). However, due to rtw89_wow_resume() return failure, it will cause the add interface flow to be executed again, resulting in a double add list and causing a kernel panic. Therefore, we have added a check to prevent double adding of the list. list_add double add: new=ffff99d6992e2010, prev=ffff99d6992e2010, next=ffff99d695302628. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:37! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G W O 6.6.30-02659-gc18865c4dfbd #1 770df2933251a0e3c888ba69d1053a817a6376a7 Hardware name: HP Grunt/Grunt, BIOS Google_Grunt.11031.169.0 06/24/2021 Workqueue: events_freezable ieee80211_restart_work [mac80211] RIP: 0010:__list_add_valid_or_report+0x5e/0xb0 Code: c7 74 18 48 39 ce 74 13 b0 01 59 5a 5e 5f 41 58 41 59 41 5a 5d e9 e2 d6 03 00 cc 48 c7 c7 8d 4f 17 83 48 89 c2 e8 02 c0 00 00 <0f> 0b 48 c7 c7 aa 8c 1c 83 e8 f4 bf 00 00 0f 0b 48 c7 c7 c8 bc 12 RSP: 0018:ffffa91b8007bc50 EFLAGS: 00010246 RAX: 0000000000000058 RBX: ffff99d6992e0900 RCX: a014d76c70ef3900 RDX: ffffa91b8007bae8 RSI: 00000000ffffdfff RDI: 0000000000000001 RBP: ffffa91b8007bc88 R08: 0000000000000000 R09: ffffa91b8007bae0 R10: 00000000ffffdfff R11: ffffffff83a79800 R12: ffff99d695302060 R13: ffff99d695300900 R14: ffff99d6992e1be0 R15: ffff99d6992e2010 FS: 0000000000000000(0000) GS:ffff99d6aac00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000078fbdba43480 CR3: 000000010e464000 CR4: 00000000001506f0 Call Trace: ? __die_body+0x1f/0x70 ? die+0x3d/0x60 ? do_trap+0xa4/0x110 ? __list_add_valid_or_report+0x5e/0xb0 ? do_error_trap+0x6d/0x90 ? __list_add_valid_or_report+0x5e/0xb0 ? handle_invalid_op+0x30/0x40 ? __list_add_valid_or_report+0x5e/0xb0 ? exc_invalid_op+0x3c/0x50 ? asm_exc_invalid_op+0x16/0x20 ? __list_add_valid_or_report+0x5e/0xb0 rtw89_ops_add_interface+0x309/0x310 [rtw89_core 7c32b1ee6854761c0321027c8a58c5160e41f48f] drv_add_interface+0x5c/0x130 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ieee80211_reconfig+0x241/0x13d0 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ? finish_wait+0x3e/0x90 ? synchronize_rcu_expedited+0x174/0x260 ? sync_rcu_exp_done_unlocked+0x50/0x50 ? wake_bit_function+0x40/0x40 ieee80211_restart_work+0xf0/0x140 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] process_scheduled_works+0x1e5/0x480 worker_thread+0xea/0x1e0 kthread+0xdb/0x110 ? move_linked_works+0x90/0x90 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork+0x3b/0x50 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork_asm+0x11/0x20 Modules linked in: dm_integrity async_xor xor async_tx lz4 lz4_compress zstd zstd_compress zram zsmalloc rfcomm cmac uinput algif_hash algif_skcipher af_alg btusb btrtl iio_trig_hrtimer industrialio_sw_trigger btmtk industrialio_configfs btbcm btintel uvcvideo videobuf2_vmalloc iio_trig_sysfs videobuf2_memops videobuf2_v4l2 videobuf2_common uvc snd_hda_codec_hdmi veth snd_hda_intel snd_intel_dspcfg acpi_als snd_hda_codec industrialio_triggered_buffer kfifo_buf snd_hwdep industrialio i2c_piix4 snd_hda_core designware_i2s ip6table_nat snd_soc_max98357a xt_MASQUERADE xt_cgroup snd_soc_acp_rt5682_mach fuse rtw89_8922ae(O) rtw89_8922a(O) rtw89_pci(O) rtw89_core(O) 8021q mac80211(O) bluetooth ecdh_generic ecc cfg80211 r8152 mii joydev gsmi: Log Shutdown Reason 0x03 ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49940", "url": "https://ubuntu.com/security/CVE-2024-49940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: prevent possible tunnel refcount underflow When a session is created, it sets a backpointer to its tunnel. When the session refcount drops to 0, l2tp_session_free drops the tunnel refcount if session->tunnel is non-NULL. However, session->tunnel is set in l2tp_session_create, before the tunnel refcount is incremented by l2tp_session_register, which leaves a small window where session->tunnel is non-NULL when the tunnel refcount hasn't been bumped. Moving the assignment to l2tp_session_register is trivial but l2tp_session_create calls l2tp_session_set_header_len which uses session->tunnel to get the tunnel's encap. Add an encap arg to l2tp_session_set_header_len to avoid using session->tunnel. If l2tpv3 sessions have colliding IDs, it is possible for l2tp_v3_session_get to race with l2tp_session_register and fetch a session which doesn't yet have session->tunnel set. Add a check for this case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49941", "url": "https://ubuntu.com/security/CVE-2024-49941", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpiolib: Fix potential NULL pointer dereference in gpiod_get_label() In `gpiod_get_label()`, it is possible that `srcu_dereference_check()` may return a NULL pointer, leading to a scenario where `label->str` is accessed without verifying if `label` itself is NULL. This patch adds a proper NULL check for `label` before accessing `label->str`. The check for `label->str != NULL` is removed because `label->str` can never be NULL if `label` is not NULL. This fixes the issue where the label name was being printed as `(efault)` when dumping the sysfs GPIO file when `label == NULL`.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49996", "url": "https://ubuntu.com/security/CVE-2024-49996", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: Fix buffer overflow when parsing NFS reparse points ReparseDataLength is sum of the InodeType size and DataBuffer size. So to get DataBuffer size it is needed to subtract InodeType's size from ReparseDataLength. Function cifs_strndup_from_utf16() is currentlly accessing buf->DataBuffer at position after the end of the buffer because it does not subtract InodeType size from the length. Fix this problem and correctly subtract variable len. Member InodeType is present only when reparse buffer is large enough. Check for ReparseDataLength before accessing InodeType to prevent another invalid memory access. Major and minor rdev values are present also only when reparse buffer is large enough. Check for reparse buffer size before calling reparse_mkdev().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49942", "url": "https://ubuntu.com/security/CVE-2024-49942", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Prevent null pointer access in xe_migrate_copy xe_migrate_copy designed to copy content of TTM resources. When source resource is null, it will trigger a NULL pointer dereference in xe_migrate_copy. To avoid this situation, update lacks source flag to true for this case, the flag will trigger xe_migrate_clear rather than xe_migrate_copy. Issue trace: <7> [317.089847] xe 0000:00:02.0: [drm:xe_migrate_copy [xe]] Pass 14, sizes: 4194304 & 4194304 <7> [317.089945] xe 0000:00:02.0: [drm:xe_migrate_copy [xe]] Pass 15, sizes: 4194304 & 4194304 <1> [317.128055] BUG: kernel NULL pointer dereference, address: 0000000000000010 <1> [317.128064] #PF: supervisor read access in kernel mode <1> [317.128066] #PF: error_code(0x0000) - not-present page <6> [317.128069] PGD 0 P4D 0 <4> [317.128071] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI <4> [317.128074] CPU: 1 UID: 0 PID: 1440 Comm: kunit_try_catch Tainted: G U N 6.11.0-rc7-xe #1 <4> [317.128078] Tainted: [U]=USER, [N]=TEST <4> [317.128080] Hardware name: Intel Corporation Lunar Lake Client Platform/LNL-M LP5 RVP1, BIOS LNLMFWI1.R00.3221.D80.2407291239 07/29/2024 <4> [317.128082] RIP: 0010:xe_migrate_copy+0x66/0x13e0 [xe] <4> [317.128158] Code: 00 00 48 89 8d e0 fe ff ff 48 8b 40 10 4c 89 85 c8 fe ff ff 44 88 8d bd fe ff ff 65 48 8b 3c 25 28 00 00 00 48 89 7d d0 31 ff <8b> 79 10 48 89 85 a0 fe ff ff 48 8b 00 48 89 b5 d8 fe ff ff 83 ff <4> [317.128162] RSP: 0018:ffffc9000167f9f0 EFLAGS: 00010246 <4> [317.128164] RAX: ffff8881120d8028 RBX: ffff88814d070428 RCX: 0000000000000000 <4> [317.128166] RDX: ffff88813cb99c00 RSI: 0000000004000000 RDI: 0000000000000000 <4> [317.128168] RBP: ffffc9000167fbb8 R08: ffff88814e7b1f08 R09: 0000000000000001 <4> [317.128170] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88814e7b1f08 <4> [317.128172] R13: ffff88814e7b1f08 R14: ffff88813cb99c00 R15: 0000000000000001 <4> [317.128174] FS: 0000000000000000(0000) GS:ffff88846f280000(0000) knlGS:0000000000000000 <4> [317.128176] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [317.128178] CR2: 0000000000000010 CR3: 000000011f676004 CR4: 0000000000770ef0 <4> [317.128180] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 <4> [317.128182] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400 <4> [317.128184] PKRU: 55555554 <4> [317.128185] Call Trace: <4> [317.128187] <4> [317.128189] ? show_regs+0x67/0x70 <4> [317.128194] ? __die_body+0x20/0x70 <4> [317.128196] ? __die+0x2b/0x40 <4> [317.128198] ? page_fault_oops+0x15f/0x4e0 <4> [317.128203] ? do_user_addr_fault+0x3fb/0x970 <4> [317.128205] ? lock_acquire+0xc7/0x2e0 <4> [317.128209] ? exc_page_fault+0x87/0x2b0 <4> [317.128212] ? asm_exc_page_fault+0x27/0x30 <4> [317.128216] ? xe_migrate_copy+0x66/0x13e0 [xe] <4> [317.128263] ? __lock_acquire+0xb9d/0x26f0 <4> [317.128265] ? __lock_acquire+0xb9d/0x26f0 <4> [317.128267] ? sg_free_append_table+0x20/0x80 <4> [317.128271] ? lock_acquire+0xc7/0x2e0 <4> [317.128273] ? mark_held_locks+0x4d/0x80 <4> [317.128275] ? trace_hardirqs_on+0x1e/0xd0 <4> [317.128278] ? _raw_spin_unlock_irqrestore+0x31/0x60 <4> [317.128281] ? __pm_runtime_resume+0x60/0xa0 <4> [317.128284] xe_bo_move+0x682/0xc50 [xe] <4> [317.128315] ? lock_is_held_type+0xaa/0x120 <4> [317.128318] ttm_bo_handle_move_mem+0xe5/0x1a0 [ttm] <4> [317.128324] ttm_bo_validate+0xd1/0x1a0 [ttm] <4> [317.128328] shrink_test_run_device+0x721/0xc10 [xe] <4> [317.128360] ? find_held_lock+0x31/0x90 <4> [317.128363] ? lock_release+0xd1/0x2a0 <4> [317.128365] ? __pfx_kunit_generic_run_threadfn_adapter+0x10/0x10 [kunit] <4> [317.128370] xe_bo_shrink_kunit+0x11/0x20 [xe] <4> [317.128397] kunit_try_run_case+0x6e/0x150 [kunit] <4> [317.128400] ? trace_hardirqs_on+0x1e/0xd0 <4> [317.128402] ? _raw_spin_unlock_irqrestore+0x31/0x60 <4> [317.128404] kunit_generic_run_threadfn_adapter+0x1e/0x40 [ku ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49943", "url": "https://ubuntu.com/security/CVE-2024-49943", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc_submit: add missing locking in wedged_fini Any non-wedged queue can have a zero refcount here and can be running concurrently with an async queue destroy, therefore dereferencing the queue ptr to check wedge status after the lookup can trigger UAF if queue is not wedged. Fix this by keeping the submission_state lock held around the check to postpone the free and make the check safe, before dropping again around the put() to avoid the deadlock. (cherry picked from commit d28af0b6b9580b9f90c265a7da0315b0ad20bbfd)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50011", "url": "https://ubuntu.com/security/CVE-2024-50011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: soc-acpi-intel-rpl-match: add missing empty item There is no links_num in struct snd_soc_acpi_mach {}, and we test !link->num_adr as a condition to end the loop in hda_sdw_machine_select(). So an empty item in struct snd_soc_acpi_link_adr array is required.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50174", "url": "https://ubuntu.com/security/CVE-2024-50174", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix race when converting group handle to group object XArray provides it's own internal lock which protects the internal array when entries are being simultaneously added and removed. However there is still a race between retrieving the pointer from the XArray and incrementing the reference count. To avoid this race simply hold the internal XArray lock when incrementing the reference count, this ensures there cannot be a racing call to xa_erase().", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49944", "url": "https://ubuntu.com/security/CVE-2024-49944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_start In sctp_listen_start() invoked by sctp_inet_listen(), it should set the sk_state back to CLOSED if sctp_autobind() fails due to whatever reason. Otherwise, next time when calling sctp_inet_listen(), if sctp_sk(sk)->reuse is already set via setsockopt(SCTP_REUSE_PORT), sctp_sk(sk)->bind_hash will be dereferenced as sk_state is LISTENING, which causes a crash as bind_hash is NULL. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:sctp_inet_listen+0x7f0/0xa20 net/sctp/socket.c:8617 Call Trace: __sys_listen_socket net/socket.c:1883 [inline] __sys_listen+0x1b7/0x230 net/socket.c:1894 __do_sys_listen net/socket.c:1902 [inline]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49945", "url": "https://ubuntu.com/security/CVE-2024-49945", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/ncsi: Disable the ncsi work before freeing the associated structure The work function can run after the ncsi device is freed, resulting in use-after-free bugs or kernel panic.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49946", "url": "https://ubuntu.com/security/CVE-2024-49946", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: do not assume bh is held in ppp_channel_bridge_input() Networking receive path is usually handled from BH handler. However, some protocols need to acquire the socket lock, and packets might be stored in the socket backlog is the socket was owned by a user process. In this case, release_sock(), __release_sock(), and sk_backlog_rcv() might call the sk->sk_backlog_rcv() handler in process context. sybot caught ppp was not considering this case in ppp_channel_bridge_input() : WARNING: inconsistent lock state 6.11.0-rc7-syzkaller-g5f5673607153 #0 Not tainted -------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. ksoftirqd/1/24 [HC0[0]:SC1[1]:HE1:SE0] takes: ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 {SOFTIRQ-ON-W} state was registered at: lock_acquire+0x240/0x728 kernel/locking/lockdep.c:5759 __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline] _raw_spin_lock+0x48/0x60 kernel/locking/spinlock.c:154 spin_lock include/linux/spinlock.h:351 [inline] ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline] ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0xfc/0x314 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv include/net/sock.h:1111 [inline] __release_sock+0x1a8/0x3d8 net/core/sock.c:3004 release_sock+0x68/0x1b8 net/core/sock.c:3558 pppoe_sendmsg+0xc8/0x5d8 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x374/0x4f4 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __arm64_sys_sendto+0xd8/0xf8 net/socket.c:2212 __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:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 irq event stamp: 282914 hardirqs last enabled at (282914): [] __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:151 [inline] hardirqs last enabled at (282914): [] _raw_spin_unlock_irqrestore+0x38/0x98 kernel/locking/spinlock.c:194 hardirqs last disabled at (282913): [] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline] hardirqs last disabled at (282913): [] _raw_spin_lock_irqsave+0x2c/0x7c kernel/locking/spinlock.c:162 softirqs last enabled at (282904): [] softirq_handle_end kernel/softirq.c:400 [inline] softirqs last enabled at (282904): [] handle_softirqs+0xa3c/0xbfc kernel/softirq.c:582 softirqs last disabled at (282909): [] run_ksoftirqd+0x70/0x158 kernel/softirq.c:928 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&pch->downl); lock(&pch->downl); *** DEADLOCK *** 1 lock held by ksoftirqd/1/24: #0: ffff80008f74dfa0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire+0x10/0x4c include/linux/rcupdate.h:325 stack backtrace: CPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 6.11.0-rc7-syzkaller-g5f5673607153 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call trace: dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:319 show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:326 __dump_sta ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49947", "url": "https://ubuntu.com/security/CVE-2024-49947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: test for not too small csum_start in virtio_net_hdr_to_skb() syzbot was able to trigger this warning [1], after injecting a malicious packet through af_packet, setting skb->csum_start and thus the transport header to an incorrect value. We can at least make sure the transport header is after the end of the network header (with a estimated minimal size). [1] [ 67.873027] skb len=4096 headroom=16 headlen=14 tailroom=0 mac=(-1,-1) mac_len=0 net=(16,-6) trans=10 shinfo(txflags=0 nr_frags=1 gso(size=0 type=0 segs=0)) csum(0xa start=10 offset=0 ip_summed=3 complete_sw=0 valid=0 level=0) hash(0x0 sw=0 l4=0) proto=0x0800 pkttype=0 iif=0 priority=0x0 mark=0x0 alloc_cpu=10 vlan_all=0x0 encapsulation=0 inner(proto=0x0000, mac=0, net=0, trans=0) [ 67.877172] dev name=veth0_vlan feat=0x000061164fdd09e9 [ 67.877764] sk family=17 type=3 proto=0 [ 67.878279] skb linear: 00000000: 00 00 10 00 00 00 00 00 0f 00 00 00 08 00 [ 67.879128] skb frag: 00000000: 0e 00 07 00 00 00 28 00 08 80 1c 00 04 00 00 02 [ 67.879877] skb frag: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.880647] skb frag: 00000020: 00 00 02 00 00 00 08 00 1b 00 00 00 00 00 00 00 [ 67.881156] skb frag: 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.881753] skb frag: 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.882173] skb frag: 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.882790] skb frag: 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.883171] skb frag: 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.883733] skb frag: 00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.884206] skb frag: 00000090: 00 00 00 00 00 00 00 00 00 00 69 70 76 6c 61 6e [ 67.884704] skb frag: 000000a0: 31 00 00 00 00 00 00 00 00 00 2b 00 00 00 00 00 [ 67.885139] skb frag: 000000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.885677] skb frag: 000000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.886042] skb frag: 000000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.886408] skb frag: 000000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.887020] skb frag: 000000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.887384] skb frag: 00000100: 00 00 [ 67.887878] ------------[ cut here ]------------ [ 67.887908] offset (-6) >= skb_headlen() (14) [ 67.888445] WARNING: CPU: 10 PID: 2088 at net/core/dev.c:3332 skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.889353] Modules linked in: macsec macvtap macvlan hsr wireguard curve25519_x86_64 libcurve25519_generic libchacha20poly1305 chacha_x86_64 libchacha poly1305_x86_64 dummy bridge sr_mod cdrom evdev pcspkr i2c_piix4 9pnet_virtio 9p 9pnet netfs [ 67.890111] CPU: 10 UID: 0 PID: 2088 Comm: b363492833 Not tainted 6.11.0-virtme #1011 [ 67.890183] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 67.890309] RIP: 0010:skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891043] Call Trace: [ 67.891173] [ 67.891274] ? __warn (kernel/panic.c:741) [ 67.891320] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891333] ? report_bug (lib/bug.c:180 lib/bug.c:219) [ 67.891348] ? handle_bug (arch/x86/kernel/traps.c:239) [ 67.891363] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) [ 67.891372] ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621) [ 67.891388] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891399] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891416] ip_do_fragment (net/ipv4/ip_output.c:777 (discriminator 1)) [ 67.891448] ? __ip_local_out (./include/linux/skbuff.h:1146 ./include/net/l3mdev.h:196 ./include/net/l3mdev.h:213 ne ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49948", "url": "https://ubuntu.com/security/CVE-2024-49948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: add more sanity checks to qdisc_pkt_len_init() One path takes care of SKB_GSO_DODGY, assuming skb->len is bigger than hdr_len. virtio_net_hdr_to_skb() does not fully dissect TCP headers, it only make sure it is at least 20 bytes. It is possible for an user to provide a malicious 'GSO' packet, total length of 80 bytes. - 20 bytes of IPv4 header - 60 bytes TCP header - a small gso_size like 8 virtio_net_hdr_to_skb() would declare this packet as a normal GSO packet, because it would see 40 bytes of payload, bigger than gso_size. We need to make detect this case to not underflow qdisc_skb_cb(skb)->pkt_len.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49949", "url": "https://ubuntu.com/security/CVE-2024-49949", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: avoid potential underflow in qdisc_pkt_len_init() with UFO After commit 7c6d2ecbda83 (\"net: be more gentle about silly gso requests coming from user\") virtio_net_hdr_to_skb() had sanity check to detect malicious attempts from user space to cook a bad GSO packet. Then commit cf9acc90c80ec (\"net: virtio_net_hdr_to_skb: count transport header in UFO\") while fixing one issue, allowed user space to cook a GSO packet with the following characteristic : IPv4 SKB_GSO_UDP, gso_size=3, skb->len = 28. When this packet arrives in qdisc_pkt_len_init(), we end up with hdr_len = 28 (IPv4 header + UDP header), matching skb->len Then the following sets gso_segs to 0 : gso_segs = DIV_ROUND_UP(skb->len - hdr_len, shinfo->gso_size); Then later we set qdisc_skb_cb(skb)->pkt_len to back to zero :/ qdisc_skb_cb(skb)->pkt_len += (gso_segs - 1) * hdr_len; This leads to the following crash in fq_codel [1] qdisc_pkt_len_init() is best effort, we only want an estimation of the bytes sent on the wire, not crashing the kernel. This patch is fixing this particular issue, a following one adds more sanity checks for another potential bug. [1] [ 70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 70.724561] #PF: supervisor read access in kernel mode [ 70.724561] #PF: error_code(0x0000) - not-present page [ 70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0 [ 70.724561] Oops: Oops: 0000 [#1] SMP NOPTI [ 70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991 [ 70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel [ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 <49> 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49 All code ======== 0:\t24 08 \tand $0x8,%al 2:\t49 c1 e1 06 \tshl $0x6,%r9 6:\t44 89 7c 24 18 \tmov %r15d,0x18(%rsp) b:\t45 31 ed \txor %r13d,%r13d e:\t45 31 c0 \txor %r8d,%r8d 11:\t31 ff \txor %edi,%edi 13:\t89 44 24 14 \tmov %eax,0x14(%rsp) 17:\t4c 03 8b 90 01 00 00 \tadd 0x190(%rbx),%r9 1e:\teb 04 \tjmp 0x24 20:\t39 ca \tcmp %ecx,%edx 22:\t73 37 \tjae 0x5b 24:\t4d 8b 39 \tmov (%r9),%r15 27:\t83 c7 01 \tadd $0x1,%edi 2a:*\t49 8b 17 \tmov (%r15),%rdx\t\t<-- trapping instruction 2d:\t49 89 11 \tmov %rdx,(%r9) 30:\t41 8b 57 28 \tmov 0x28(%r15),%edx 34:\t45 8b 5f 34 \tmov 0x34(%r15),%r11d 38:\t49 c7 07 00 00 00 00 \tmovq $0x0,(%r15) 3f:\t49 \trex.WB Code starting with the faulting instruction =========================================== 0:\t49 8b 17 \tmov (%r15),%rdx 3:\t49 89 11 \tmov %rdx,(%r9) 6:\t41 8b 57 28 \tmov 0x28(%r15),%edx a:\t45 8b 5f 34 \tmov 0x34(%r15),%r11d e:\t49 c7 07 00 00 00 00 \tmovq $0x0,(%r15) 15:\t49 \trex.WB [ 70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202 [ 70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000 [ 70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001 [ 70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000 [ 70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58 [ 70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000 [ 70.724561] FS: 000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000 [ 70.724561] CS: 0010 DS: 0000 ES: 0000 C ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49997", "url": "https://ubuntu.com/security/CVE-2024-49997", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: lantiq_etop: fix memory disclosure When applying padding, the buffer is not zeroed, which results in memory disclosure. The mentioned data is observed on the wire. This patch uses skb_put_padto() to pad Ethernet frames properly. The mentioned function zeroes the expanded buffer. In case the packet cannot be padded it is silently dropped. Statistics are also not incremented. This driver does not support statistics in the old 32-bit format or the new 64-bit format. These will be added in the future. In its current form, the patch should be easily backported to stable versions. Ethernet MACs on Amazon-SE and Danube cannot do padding of the packets in hardware, so software padding must be applied.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49998", "url": "https://ubuntu.com/security/CVE-2024-49998", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: improve shutdown sequence Alexander Sverdlin presents 2 problems during shutdown with the lan9303 driver. One is specific to lan9303 and the other just happens to reproduce there. The first problem is that lan9303 is unique among DSA drivers in that it calls dev_get_drvdata() at \"arbitrary runtime\" (not probe, not shutdown, not remove): phy_state_machine() -> ... -> dsa_user_phy_read() -> ds->ops->phy_read() -> lan9303_phy_read() -> chip->ops->phy_read() -> lan9303_mdio_phy_read() -> dev_get_drvdata() But we never stop the phy_state_machine(), so it may continue to run after dsa_switch_shutdown(). Our common pattern in all DSA drivers is to set drvdata to NULL to suppress the remove() method that may come afterwards. But in this case it will result in an NPD. The second problem is that the way in which we set dp->conduit->dsa_ptr = NULL; is concurrent with receive packet processing. dsa_switch_rcv() checks once whether dev->dsa_ptr is NULL, but afterwards, rather than continuing to use that non-NULL value, dev->dsa_ptr is dereferenced again and again without NULL checks: dsa_conduit_find_user() and many other places. In between dereferences, there is no locking to ensure that what was valid once continues to be valid. Both problems have the common aspect that closing the conduit interface solves them. In the first case, dev_close(conduit) triggers the NETDEV_GOING_DOWN event in dsa_user_netdevice_event() which closes user ports as well. dsa_port_disable_rt() calls phylink_stop(), which synchronously stops the phylink state machine, and ds->ops->phy_read() will thus no longer call into the driver after this point. In the second case, dev_close(conduit) should do this, as per Documentation/networking/driver.rst: | Quiescence | ---------- | | After the ndo_stop routine has been called, the hardware must | not receive or transmit any data. All in flight packets must | be aborted. If necessary, poll or wait for completion of | any reset commands. So it should be sufficient to ensure that later, when we zeroize conduit->dsa_ptr, there will be no concurrent dsa_switch_rcv() call on this conduit. The addition of the netif_device_detach() function is to ensure that ioctls, rtnetlinks and ethtool requests on the user ports no longer propagate down to the driver - we're no longer prepared to handle them. The race condition actually did not exist when commit 0650bf52b31f (\"net: dsa: be compatible with masters which unregister on shutdown\") first introduced dsa_switch_shutdown(). It was created later, when we stopped unregistering the user interfaces from a bad spot, and we just replaced that sequence with a racy zeroization of conduit->dsa_ptr (one which doesn't ensure that the interfaces aren't up).", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49999", "url": "https://ubuntu.com/security/CVE-2024-49999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix the setting of the server responding flag In afs_wait_for_operation(), we set transcribe the call responded flag to the server record that we used after doing the fileserver iteration loop - but it's possible to exit the loop having had a response from the server that we've discarded (e.g. it returned an abort or we started receiving data, but the call didn't complete). This means that op->server might be NULL, but we don't check that before attempting to set the server flag.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49950", "url": "https://ubuntu.com/security/CVE-2024-49950", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix uaf in l2cap_connect [Syzbot reported] BUG: KASAN: slab-use-after-free in l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 Read of size 8 at addr ffff8880241e9800 by task kworker/u9:0/54 CPU: 0 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-00268-g788220eee30d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Workqueue: hci2 hci_rx_work Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 l2cap_connect_req net/bluetooth/l2cap_core.c:4080 [inline] l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:4772 [inline] l2cap_sig_channel net/bluetooth/l2cap_core.c:5543 [inline] l2cap_recv_frame+0xf0b/0x8eb0 net/bluetooth/l2cap_core.c:6825 l2cap_recv_acldata+0x9b4/0xb70 net/bluetooth/l2cap_core.c:7514 hci_acldata_packet net/bluetooth/hci_core.c:3791 [inline] hci_rx_work+0xaab/0x1610 net/bluetooth/hci_core.c:4028 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 ... Freed by task 5245: 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:579 poison_slab_object+0xf7/0x160 mm/kasan/common.c:240 __kasan_slab_free+0x32/0x50 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2256 [inline] slab_free mm/slub.c:4477 [inline] kfree+0x12a/0x3b0 mm/slub.c:4598 l2cap_conn_free net/bluetooth/l2cap_core.c:1810 [inline] kref_put include/linux/kref.h:65 [inline] l2cap_conn_put net/bluetooth/l2cap_core.c:1822 [inline] l2cap_conn_del+0x59d/0x730 net/bluetooth/l2cap_core.c:1802 l2cap_connect_cfm+0x9e6/0xf80 net/bluetooth/l2cap_core.c:7241 hci_connect_cfm include/net/bluetooth/hci_core.h:1960 [inline] hci_conn_failed+0x1c3/0x370 net/bluetooth/hci_conn.c:1265 hci_abort_conn_sync+0x75a/0xb50 net/bluetooth/hci_sync.c:5583 abort_conn_sync+0x197/0x360 net/bluetooth/hci_conn.c:2917 hci_cmd_sync_work+0x1a4/0x410 net/bluetooth/hci_sync.c:328 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49951", "url": "https://ubuntu.com/security/CVE-2024-49951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Fix possible crash on mgmt_index_removed If mgmt_index_removed is called while there are commands queued on cmd_sync it could lead to crashes like the bellow trace: 0x0000053D: __list_del_entry_valid_or_report+0x98/0xdc 0x0000053D: mgmt_pending_remove+0x18/0x58 [bluetooth] 0x0000053E: mgmt_remove_adv_monitor_complete+0x80/0x108 [bluetooth] 0x0000053E: hci_cmd_sync_work+0xbc/0x164 [bluetooth] So while handling mgmt_index_removed this attempts to dequeue commands passed as user_data to cmd_sync.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49952", "url": "https://ubuntu.com/security/CVE-2024-49952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: prevent nf_skb_duplicated corruption syzbot found that nf_dup_ipv4() or nf_dup_ipv6() could write per-cpu variable nf_skb_duplicated in an unsafe way [1]. Disabling preemption as hinted by the splat is not enough, we have to disable soft interrupts as well. [1] BUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316 caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49 nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook+0x2c4/0x450 include/linux/netfilter.h:269 NF_HOOK_COND include/linux/netfilter.h:302 [inline] ip_output+0x185/0x230 net/ipv4/ip_output.c:433 ip_local_out net/ipv4/ip_output.c:129 [inline] ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495 udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981 udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737 __do_sys_sendmmsg net/socket.c:2766 [inline] __se_sys_sendmmsg net/socket.c:2763 [inline] __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763 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:0x7f4ce4f7def9 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:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9 RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006 RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49953", "url": "https://ubuntu.com/security/CVE-2024-49953", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix crash caused by calling __xfrm_state_delete() twice The km.state is not checked in driver's delayed work. When xfrm_state_check_expire() is called, the state can be reset to XFRM_STATE_EXPIRED, even if it is XFRM_STATE_DEAD already. This happens when xfrm state is deleted, but not freed yet. As __xfrm_state_delete() is called again in xfrm timer, the following crash occurs. To fix this issue, skip xfrm_state_check_expire() if km.state is not XFRM_STATE_VALID. Oops: general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] SMP CPU: 5 UID: 0 PID: 7448 Comm: kworker/u102:2 Not tainted 6.11.0-rc2+ #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5e_ipsec: eth%d mlx5e_ipsec_handle_sw_limits [mlx5_core] RIP: 0010:__xfrm_state_delete+0x3d/0x1b0 Code: 0f 84 8b 01 00 00 48 89 fd c6 87 c8 00 00 00 05 48 8d bb 40 10 00 00 e8 11 04 1a 00 48 8b 95 b8 00 00 00 48 8b 85 c0 00 00 00 <48> 89 42 08 48 89 10 48 8b 55 10 48 b8 00 01 00 00 00 00 ad de 48 RSP: 0018:ffff88885f945ec8 EFLAGS: 00010246 RAX: dead000000000122 RBX: ffffffff82afa940 RCX: 0000000000000036 RDX: dead000000000100 RSI: 0000000000000000 RDI: ffffffff82afb980 RBP: ffff888109a20340 R08: ffff88885f945ea0 R09: 0000000000000000 R10: 0000000000000000 R11: ffff88885f945ff8 R12: 0000000000000246 R13: ffff888109a20340 R14: ffff88885f95f420 R15: ffff88885f95f400 FS: 0000000000000000(0000) GS:ffff88885f940000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2163102430 CR3: 00000001128d6001 CR4: 0000000000370eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? die_addr+0x33/0x90 ? exc_general_protection+0x1a2/0x390 ? asm_exc_general_protection+0x22/0x30 ? __xfrm_state_delete+0x3d/0x1b0 ? __xfrm_state_delete+0x2f/0x1b0 xfrm_timer_handler+0x174/0x350 ? __xfrm_state_delete+0x1b0/0x1b0 __hrtimer_run_queues+0x121/0x270 hrtimer_run_softirq+0x88/0xd0 handle_softirqs+0xcc/0x270 do_softirq+0x3c/0x50 __local_bh_enable_ip+0x47/0x50 mlx5e_ipsec_handle_sw_limits+0x7d/0x90 [mlx5_core] process_one_work+0x137/0x2d0 worker_thread+0x28d/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50000", "url": "https://ubuntu.com/security/CVE-2024-50000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix NULL deref in mlx5e_tir_builder_alloc() In mlx5e_tir_builder_alloc() kvzalloc() may return NULL which is dereferenced on the next line in a reference to the modify field. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50001", "url": "https://ubuntu.com/security/CVE-2024-50001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix error path in multi-packet WQE transmit Remove the erroneous unmap in case no DMA mapping was established The multi-packet WQE transmit code attempts to obtain a DMA mapping for the skb. This could fail, e.g. under memory pressure, when the IOMMU driver just can't allocate more memory for page tables. While the code tries to handle this in the path below the err_unmap label it erroneously unmaps one entry from the sq's FIFO list of active mappings. Since the current map attempt failed this unmap is removing some random DMA mapping that might still be required. If the PCI function now presents that IOVA, the IOMMU may assumes a rogue DMA access and e.g. on s390 puts the PCI function in error state. The erroneous behavior was seen in a stress-test environment that created memory pressure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50179", "url": "https://ubuntu.com/security/CVE-2024-50179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: remove the incorrect Fw reference check when dirtying pages When doing the direct-io reads it will also try to mark pages dirty, but for the read path it won't hold the Fw caps and there is case will it get the Fw reference.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49963", "url": "https://ubuntu.com/security/CVE-2024-49963", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mailbox: bcm2835: Fix timeout during suspend mode During noirq suspend phase the Raspberry Pi power driver suffer of firmware property timeouts. The reason is that the IRQ of the underlying BCM2835 mailbox is disabled and rpi_firmware_property_list() will always run into a timeout [1]. Since the VideoCore side isn't consider as a wakeup source, set the IRQF_NO_SUSPEND flag for the mailbox IRQ in order to keep it enabled during suspend-resume cycle. [1] PM: late suspend of devices complete after 1.754 msecs WARNING: CPU: 0 PID: 438 at drivers/firmware/raspberrypi.c:128 rpi_firmware_property_list+0x204/0x22c Firmware transaction 0x00028001 timeout Modules linked in: CPU: 0 PID: 438 Comm: bash Tainted: G C 6.9.3-dirty #17 Hardware name: BCM2835 Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x44 dump_stack_lvl from __warn+0x88/0xec __warn from warn_slowpath_fmt+0x7c/0xb0 warn_slowpath_fmt from rpi_firmware_property_list+0x204/0x22c rpi_firmware_property_list from rpi_firmware_property+0x68/0x8c rpi_firmware_property from rpi_firmware_set_power+0x54/0xc0 rpi_firmware_set_power from _genpd_power_off+0xe4/0x148 _genpd_power_off from genpd_sync_power_off+0x7c/0x11c genpd_sync_power_off from genpd_finish_suspend+0xcc/0xe0 genpd_finish_suspend from dpm_run_callback+0x78/0xd0 dpm_run_callback from device_suspend_noirq+0xc0/0x238 device_suspend_noirq from dpm_suspend_noirq+0xb0/0x168 dpm_suspend_noirq from suspend_devices_and_enter+0x1b8/0x5ac suspend_devices_and_enter from pm_suspend+0x254/0x2e4 pm_suspend from state_store+0xa8/0xd4 state_store from kernfs_fop_write_iter+0x154/0x1a0 kernfs_fop_write_iter from vfs_write+0x12c/0x184 vfs_write from ksys_write+0x78/0xc0 ksys_write from ret_fast_syscall+0x0/0x54 Exception stack(0xcc93dfa8 to 0xcc93dff0) [...] PM: noirq suspend of devices complete after 3095.584 msecs", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49954", "url": "https://ubuntu.com/security/CVE-2024-49954", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: static_call: Replace pointless WARN_ON() in static_call_module_notify() static_call_module_notify() triggers a WARN_ON(), when memory allocation fails in __static_call_add_module(). That's not really justified, because the failure case must be correctly handled by the well known call chain and the error code is passed through to the initiating userspace application. A memory allocation fail is not a fatal problem, but the WARN_ON() takes the machine out when panic_on_warn is set. Replace it with a pr_warn().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50002", "url": "https://ubuntu.com/security/CVE-2024-50002", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: static_call: Handle module init failure correctly in static_call_del_module() Module insertion invokes static_call_add_module() to initialize the static calls in a module. static_call_add_module() invokes __static_call_init(), which allocates a struct static_call_mod to either encapsulate the built-in static call sites of the associated key into it so further modules can be added or to append the module to the module chain. If that allocation fails the function returns with an error code and the module core invokes static_call_del_module() to clean up eventually added static_call_mod entries. This works correctly, when all keys used by the module were converted over to a module chain before the failure. If not then static_call_del_module() causes a #GP as it blindly assumes that key::mods points to a valid struct static_call_mod. The problem is that key::mods is not a individual struct member of struct static_call_key, it's part of a union to save space: union { /* bit 0: 0 = mods, 1 = sites */ unsigned long type; struct static_call_mod *mods; struct static_call_site *sites; \t}; key::sites is a pointer to the list of built-in usage sites of the static call. The type of the pointer is differentiated by bit 0. A mods pointer has the bit clear, the sites pointer has the bit set. As static_call_del_module() blidly assumes that the pointer is a valid static_call_mod type, it fails to check for this failure case and dereferences the pointer to the list of built-in call sites, which is obviously bogus. Cure it by checking whether the key has a sites or a mods pointer. If it's a sites pointer then the key is not to be touched. As the sites are walked in the same order as in __static_call_init() the site walk can be terminated because all subsequent sites have not been touched by the init code due to the error exit. If it was converted before the allocation fail, then the inner loop which searches for a module match will find nothing. A fail in the second allocation in __static_call_init() is harmless and does not require special treatment. The first allocation succeeded and converted the key to a module chain. That first entry has mod::mod == NULL and mod::next == NULL, so the inner loop of static_call_del_module() will neither find a module match nor a module chain. The next site in the walk was either already converted, but can't match the module, or it will exit the outer loop because it has a static_call_site pointer and not a static_call_mod pointer.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-47675", "url": "https://ubuntu.com/security/CVE-2024-47675", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix use-after-free in bpf_uprobe_multi_link_attach() If bpf_link_prime() fails, bpf_uprobe_multi_link_attach() goes to the error_free label and frees the array of bpf_uprobe's without calling bpf_uprobe_unregister(). This leaks bpf_uprobe->uprobe and worse, this frees bpf_uprobe->consumer without removing it from the uprobe->consumers list.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47676", "url": "https://ubuntu.com/security/CVE-2024-47676", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb.c: fix UAF of vma in hugetlb fault pathway Syzbot reports a UAF in hugetlb_fault(). This happens because vmf_anon_prepare() could drop the per-VMA lock and allow the current VMA to be freed before hugetlb_vma_unlock_read() is called. We can fix this by using a modified version of vmf_anon_prepare() that doesn't release the VMA lock on failure, and then release it ourselves after hugetlb_vma_unlock_read().", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47677", "url": "https://ubuntu.com/security/CVE-2024-47677", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: resolve memory leak from exfat_create_upcase_table() If exfat_load_upcase_table reaches end and returns -EINVAL, allocated memory doesn't get freed and while exfat_load_default_upcase_table allocates more memory, leading to a memory leak. Here's link to syzkaller crash report illustrating this issue: https://syzkaller.appspot.com/text?tag=CrashReport&x=1406c201980000", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47725", "url": "https://ubuntu.com/security/CVE-2024-47725", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47739", "url": "https://ubuntu.com/security/CVE-2024-47739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: padata: use integer wrap around to prevent deadlock on seq_nr overflow When submitting more than 2^32 padata objects to padata_do_serial, the current sorting implementation incorrectly sorts padata objects with overflowed seq_nr, causing them to be placed before existing objects in the reorder list. This leads to a deadlock in the serialization process as padata_find_next cannot match padata->seq_nr and pd->processed because the padata instance with overflowed seq_nr will be selected next. To fix this, we use an unsigned integer wrap around to correctly sort padata objects in scenarios with integer overflow.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47678", "url": "https://ubuntu.com/security/CVE-2024-47678", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: icmp: change the order of rate limits ICMP messages are ratelimited : After the blamed commits, the two rate limiters are applied in this order: 1) host wide ratelimit (icmp_global_allow()) 2) Per destination ratelimit (inetpeer based) In order to avoid side-channels attacks, we need to apply the per destination check first. This patch makes the following change : 1) icmp_global_allow() checks if the host wide limit is reached. But credits are not yet consumed. This is deferred to 3) 2) The per destination limit is checked/updated. This might add a new node in inetpeer tree. 3) icmp_global_consume() consumes tokens if prior operations succeeded. This means that host wide ratelimit is still effective in keeping inetpeer tree small even under DDOS. As a bonus, I removed icmp_global.lock as the fast path can use a lock-free operation.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47733", "url": "https://ubuntu.com/security/CVE-2024-47733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfs: Delete subtree of 'fs/netfs' when netfs module exits In netfs_init() or fscache_proc_init(), we create dentry under 'fs/netfs', but in netfs_exit(), we only delete the proc entry of 'fs/netfs' without deleting its subtree. This triggers the following WARNING: ================================================================== remove_proc_entry: removing non-empty directory 'fs/netfs', leaking at least 'requests' WARNING: CPU: 4 PID: 566 at fs/proc/generic.c:717 remove_proc_entry+0x160/0x1c0 Modules linked in: netfs(-) CPU: 4 UID: 0 PID: 566 Comm: rmmod Not tainted 6.11.0-rc3 #860 RIP: 0010:remove_proc_entry+0x160/0x1c0 Call Trace: netfs_exit+0x12/0x620 [netfs] __do_sys_delete_module.isra.0+0x14c/0x2e0 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e ================================================================== Therefore use remove_proc_subtree() instead of remove_proc_entry() to fix the above problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47679", "url": "https://ubuntu.com/security/CVE-2024-47679", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfs: fix race between evice_inodes() and find_inode()&iput() Hi, all Recently I noticed a bug[1] in btrfs, after digged it into and I believe it'a race in vfs. Let's assume there's a inode (ie ino 261) with i_count 1 is called by iput(), and there's a concurrent thread calling generic_shutdown_super(). cpu0: cpu1: iput() // i_count is 1 ->spin_lock(inode) ->dec i_count to 0 ->iput_final() generic_shutdown_super() ->__inode_add_lru() ->evict_inodes() // cause some reason[2] ->if (atomic_read(inode->i_count)) continue; // return before // inode 261 passed the above check // list_lru_add_obj() // and then schedule out ->spin_unlock() // note here: the inode 261 // was still at sb list and hash list, // and I_FREEING|I_WILL_FREE was not been set btrfs_iget() // after some function calls ->find_inode() // found the above inode 261 ->spin_lock(inode) // check I_FREEING|I_WILL_FREE // and passed ->__iget() ->spin_unlock(inode) // schedule back ->spin_lock(inode) // check (I_NEW|I_FREEING|I_WILL_FREE) flags, // passed and set I_FREEING iput() ->spin_unlock(inode) ->spin_lock(inode)\t\t\t ->evict() // dec i_count to 0 ->iput_final() ->spin_unlock() ->evict() Now, we have two threads simultaneously evicting the same inode, which may trigger the BUG(inode->i_state & I_CLEAR) statement both within clear_inode() and iput(). To fix the bug, recheck the inode->i_count after holding i_lock. Because in the most scenarios, the first check is valid, and the overhead of spin_lock() can be reduced. If there is any misunderstanding, please let me know, thanks. [1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/ [2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable() return false when I reproduced the bug.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49859", "url": "https://ubuntu.com/security/CVE-2024-49859", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to check atomic_file in f2fs ioctl interfaces Some f2fs ioctl interfaces like f2fs_ioc_set_pin_file(), f2fs_move_file_range(), and f2fs_defragment_range() missed to check atomic_write status, which may cause potential race issue, fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47680", "url": "https://ubuntu.com/security/CVE-2024-47680", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: check discard support for conventional zones As the helper function f2fs_bdev_support_discard() shows, f2fs checks if the target block devices support discard by calling bdev_max_discard_sectors() and bdev_is_zoned(). This check works well for most cases, but it does not work for conventional zones on zoned block devices. F2fs assumes that zoned block devices support discard, and calls __submit_discard_cmd(). When __submit_discard_cmd() is called for sequential write required zones, it works fine since __submit_discard_cmd() issues zone reset commands instead of discard commands. However, when __submit_discard_cmd() is called for conventional zones, __blkdev_issue_discard() is called even when the devices do not support discard. The inappropriate __blkdev_issue_discard() call was not a problem before the commit 30f1e7241422 (\"block: move discard checks into the ioctl handler\") because __blkdev_issue_discard() checked if the target devices support discard or not. If not, it returned EOPNOTSUPP. After the commit, __blkdev_issue_discard() no longer checks it. It always returns zero and sets NULL to the given bio pointer. This NULL pointer triggers f2fs_bug_on() in __submit_discard_cmd(). The BUG is recreated with the commands below at the umount step, where /dev/nullb0 is a zoned null_blk with 5GB total size, 128MB zone size and 10 conventional zones. $ mkfs.f2fs -f -m /dev/nullb0 $ mount /dev/nullb0 /mnt $ for ((i=0;i<5;i++)); do dd if=/dev/zero of=/mnt/test bs=65536 count=1600 conv=fsync; done $ umount /mnt To fix the BUG, avoid the inappropriate __blkdev_issue_discard() call. When discard is requested for conventional zones, check if the device supports discard or not. If not, return EOPNOTSUPP.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47740", "url": "https://ubuntu.com/security/CVE-2024-47740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: Require FMODE_WRITE for atomic write ioctls The F2FS ioctls for starting and committing atomic writes check for inode_owner_or_capable(), but this does not give LSMs like SELinux or Landlock an opportunity to deny the write access - if the caller's FSUID matches the inode's UID, inode_owner_or_capable() immediately returns true. There are scenarios where LSMs want to deny a process the ability to write particular files, even files that the FSUID of the process owns; but this can currently partially be bypassed using atomic write ioctls in two ways: - F2FS_IOC_START_ATOMIC_REPLACE + F2FS_IOC_COMMIT_ATOMIC_WRITE can truncate an inode to size 0 - F2FS_IOC_START_ATOMIC_WRITE + F2FS_IOC_ABORT_ATOMIC_WRITE can revert changes another process concurrently made to a file Fix it by requiring FMODE_WRITE for these operations, just like for F2FS_IOC_MOVE_RANGE. Since any legitimate caller should only be using these ioctls when intending to write into the file, that seems unlikely to break anything.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47726", "url": "https://ubuntu.com/security/CVE-2024-47726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to wait dio completion It should wait all existing dio write IOs before block removal, otherwise, previous direct write IO may overwrite data in the block which may be reused by other inode.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47741", "url": "https://ubuntu.com/security/CVE-2024-47741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race setting file private on concurrent lseek using same fd When doing concurrent lseek(2) system calls against the same file descriptor, using multiple threads belonging to the same process, we have a short time window where a race happens and can result in a memory leak. The race happens like this: 1) A program opens a file descriptor for a file and then spawns two threads (with the pthreads library for example), lets call them task A and task B; 2) Task A calls lseek with SEEK_DATA or SEEK_HOLE and ends up at file.c:find_desired_extent() while holding a read lock on the inode; 3) At the start of find_desired_extent(), it extracts the file's private_data pointer into a local variable named 'private', which has a value of NULL; 4) Task B also calls lseek with SEEK_DATA or SEEK_HOLE, locks the inode in shared mode and enters file.c:find_desired_extent(), where it also extracts file->private_data into its local variable 'private', which has a NULL value; 5) Because it saw a NULL file private, task A allocates a private structure and assigns to the file structure; 6) Task B also saw a NULL file private so it also allocates its own file private and then assigns it to the same file structure, since both tasks are using the same file descriptor. At this point we leak the private structure allocated by task A. Besides the memory leak, there's also the detail that both tasks end up using the same cached state record in the private structure (struct btrfs_file_private::llseek_cached_state), which can result in a use-after-free problem since one task can free it while the other is still using it (only one task took a reference count on it). Also, sharing the cached state is not a good idea since it could result in incorrect results in the future - right now it should not be a problem because it end ups being used only in extent-io-tree.c:count_range_bits() where we do range validation before using the cached state. Fix this by protecting the private assignment and check of a file while holding the inode's spinlock and keep track of the task that allocated the private, so that it's used only by that task in order to prevent user-after-free issues with the cached state record as well as potentially using it incorrectly in the future.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47681", "url": "https://ubuntu.com/security/CVE-2024-47681", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix NULL pointer dereference in mt7996_mcu_sta_bfer_he Fix the NULL pointer dereference in mt7996_mcu_sta_bfer_he routine adding an sta interface to the mt7996 driver. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49858", "url": "https://ubuntu.com/security/CVE-2024-49858", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption The TPM event log table is a Linux specific construct, where the data produced by the GetEventLog() boot service is cached in memory, and passed on to the OS using an EFI configuration table. The use of EFI_LOADER_DATA here results in the region being left unreserved in the E820 memory map constructed by the EFI stub, and this is the memory description that is passed on to the incoming kernel by kexec, which is therefore unaware that the region should be reserved. Even though the utility of the TPM2 event log after a kexec is questionable, any corruption might send the parsing code off into the weeds and crash the kernel. So let's use EFI_ACPI_RECLAIM_MEMORY instead, which is always treated as reserved by the E820 conversion logic.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49860", "url": "https://ubuntu.com/security/CVE-2024-49860", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: sysfs: validate return type of _STR method Only buffer objects are valid return values of _STR. If something else is returned description_show() will access invalid memory.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47742", "url": "https://ubuntu.com/security/CVE-2024-47742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware_loader: Block path traversal Most firmware names are hardcoded strings, or are constructed from fairly constrained format strings where the dynamic parts are just some hex numbers or such. However, there are a couple codepaths in the kernel where firmware file names contain string components that are passed through from a device or semi-privileged userspace; the ones I could find (not counting interfaces that require root privileges) are: - lpfc_sli4_request_firmware_update() seems to construct the firmware filename from \"ModelName\", a string that was previously parsed out of some descriptor (\"Vital Product Data\") in lpfc_fill_vpd() - nfp_net_fw_find() seems to construct a firmware filename from a model name coming from nfp_hwinfo_lookup(pf->hwinfo, \"nffw.partno\"), which I think parses some descriptor that was read from the device. (But this case likely isn't exploitable because the format string looks like \"netronome/nic_%s\", and there shouldn't be any *folders* starting with \"netronome/nic_\". The previous case was different because there, the \"%s\" is *at the start* of the format string.) - module_flash_fw_schedule() is reachable from the ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is enough to pass the privilege check), and takes a userspace-provided firmware name. (But I think to reach this case, you need to have CAP_NET_ADMIN over a network namespace that a special kind of ethernet device is mapped into, so I think this is not a viable attack path in practice.) Fix it by rejecting any firmware names containing \"..\" path components. For what it's worth, I went looking and haven't found any USB device drivers that use the firmware loader dangerously.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47682", "url": "https://ubuntu.com/security/CVE-2024-47682", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sd: Fix off-by-one error in sd_read_block_characteristics() Ff the device returns page 0xb1 with length 8 (happens with qemu v2.x, for example), sd_read_block_characteristics() may attempt an out-of-bounds memory access when accessing the zoned field at offset 8.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47743", "url": "https://ubuntu.com/security/CVE-2024-47743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: prevent NULL pointer dereference in find_asymmetric_key() In find_asymmetric_key(), if all NULLs are passed in the id_{0,1,2} arguments, the kernel will first emit WARN but then have an oops because id_2 gets dereferenced anyway. Add the missing id_2 check and move WARN_ON() to the final else branch to avoid duplicate NULL checks. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47727", "url": "https://ubuntu.com/security/CVE-2024-47727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/tdx: Fix \"in-kernel MMIO\" check TDX only supports kernel-initiated MMIO operations. The handle_mmio() function checks if the #VE exception occurred in the kernel and rejects the operation if it did not. However, userspace can deceive the kernel into performing MMIO on its behalf. For example, if userspace can point a syscall to an MMIO address, syscall does get_user() or put_user() on it, triggering MMIO #VE. The kernel will treat the #VE as in-kernel MMIO. Ensure that the target MMIO address is within the kernel before decoding instruction.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47744", "url": "https://ubuntu.com/security/CVE-2024-47744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Use dedicated mutex to protect kvm_usage_count to avoid deadlock Use a dedicated mutex to guard kvm_usage_count to fix a potential deadlock on x86 due to a chain of locks and SRCU synchronizations. Translating the below lockdep splat, CPU1 #6 will wait on CPU0 #1, CPU0 #8 will wait on CPU2 #3, and CPU2 #7 will wait on CPU1 #4 (if there's a writer, due to the fairness of r/w semaphores). CPU0 CPU1 CPU2 1 lock(&kvm->slots_lock); 2 lock(&vcpu->mutex); 3 lock(&kvm->srcu); 4 lock(cpu_hotplug_lock); 5 lock(kvm_lock); 6 lock(&kvm->slots_lock); 7 lock(cpu_hotplug_lock); 8 sync(&kvm->srcu); Note, there are likely more potential deadlocks in KVM x86, e.g. the same pattern of taking cpu_hotplug_lock outside of kvm_lock likely exists with __kvmclock_cpufreq_notifier(): cpuhp_cpufreq_online() | -> cpufreq_online() | -> cpufreq_gov_performance_limits() | -> __cpufreq_driver_target() | -> __target_index() | -> cpufreq_freq_transition_begin() | -> cpufreq_notify_transition() | -> ... __kvmclock_cpufreq_notifier() But, actually triggering such deadlocks is beyond rare due to the combination of dependencies and timings involved. E.g. the cpufreq notifier is only used on older CPUs without a constant TSC, mucking with the NX hugepage mitigation while VMs are running is very uncommon, and doing so while also onlining/offlining a CPU (necessary to generate contention on cpu_hotplug_lock) would be even more unusual. The most robust solution to the general cpu_hotplug_lock issue is likely to switch vm_list to be an RCU-protected list, e.g. so that x86's cpufreq notifier doesn't to take kvm_lock. For now, settle for fixing the most blatant deadlock, as switching to an RCU-protected list is a much more involved change, but add a comment in locking.rst to call out that care needs to be taken when walking holding kvm_lock and walking vm_list. ====================================================== WARNING: possible circular locking dependency detected 6.10.0-smp--c257535a0c9d-pip #330 Tainted: G S O ------------------------------------------------------ tee/35048 is trying to acquire lock: ff6a80eced71e0a8 (&kvm->slots_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x179/0x1e0 [kvm] but task is already holding lock: ffffffffc07abb08 (kvm_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x14a/0x1e0 [kvm] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (kvm_lock){+.+.}-{3:3}: __mutex_lock+0x6a/0xb40 mutex_lock_nested+0x1f/0x30 kvm_dev_ioctl+0x4fb/0xe50 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #2 (cpu_hotplug_lock){++++}-{0:0}: cpus_read_lock+0x2e/0xb0 static_key_slow_inc+0x16/0x30 kvm_lapic_set_base+0x6a/0x1c0 [kvm] kvm_set_apic_base+0x8f/0xe0 [kvm] kvm_set_msr_common+0x9ae/0xf80 [kvm] vmx_set_msr+0xa54/0xbe0 [kvm_intel] __kvm_set_msr+0xb6/0x1a0 [kvm] kvm_arch_vcpu_ioctl+0xeca/0x10c0 [kvm] kvm_vcpu_ioctl+0x485/0x5b0 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (&kvm->srcu){.+.+}-{0:0}: __synchronize_srcu+0x44/0x1a0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47719", "url": "https://ubuntu.com/security/CVE-2024-47719", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommufd: Protect against overflow of ALIGN() during iova allocation Userspace can supply an iova and uptr such that the target iova alignment becomes really big and ALIGN() overflows which corrupts the selected area range during allocation. CONFIG_IOMMUFD_TEST can detect this: WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline] WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352 Modules linked in: CPU: 1 PID: 5092 Comm: syz-executor294 Not tainted 6.10.0-rc5-syzkaller-00294-g3ffea9a7a6f7 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024 RIP: 0010:iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline] RIP: 0010:iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352 Code: fc e9 a4 f3 ff ff e8 1a 8b 4c fc 41 be e4 ff ff ff e9 8a f3 ff ff e8 0a 8b 4c fc 90 0f 0b 90 e9 37 f5 ff ff e8 fc 8a 4c fc 90 <0f> 0b 90 e9 68 f3 ff ff 48 c7 c1 ec 82 ad 8f 80 e1 07 80 c1 03 38 RSP: 0018:ffffc90003ebf9e0 EFLAGS: 00010293 RAX: ffffffff85499fa4 RBX: 00000000ffffffef RCX: ffff888079b49e00 RDX: 0000000000000000 RSI: 00000000ffffffef RDI: 0000000000000000 RBP: ffffc90003ebfc50 R08: ffffffff85499b30 R09: ffffffff85499942 R10: 0000000000000002 R11: ffff888079b49e00 R12: ffff8880228e0010 R13: 0000000000000000 R14: 1ffff920007d7f68 R15: ffffc90003ebfd00 FS: 000055557d760380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000005fdeb8 CR3: 000000007404a000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: iommufd_ioas_copy+0x610/0x7b0 drivers/iommu/iommufd/ioas.c:274 iommufd_fops_ioctl+0x4d9/0x5a0 drivers/iommu/iommufd/main.c:421 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Cap the automatic alignment to the huge page size, which is probably a better idea overall. Huge automatic alignments can fragment and chew up the available IOVA space without any reason.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47745", "url": "https://ubuntu.com/security/CVE-2024-47745", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: call the security_mmap_file() LSM hook in remap_file_pages() The remap_file_pages syscall handler calls do_mmap() directly, which doesn't contain the LSM security check. And if the process has called personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for RW pages, this will actually result in remapping the pages to RWX, bypassing a W^X policy enforced by SELinux. So we should check prot by security_mmap_file LSM hook in the remap_file_pages syscall handler before do_mmap() is called. Otherwise, it potentially permits an attacker to bypass a W^X policy enforced by SELinux. The bypass is similar to CVE-2016-10044, which bypass the same thing via AIO and can be found in [1]. The PoC: $ cat > test.c int main(void) { \tsize_t pagesz = sysconf(_SC_PAGE_SIZE); \tint mfd = syscall(SYS_memfd_create, \"test\", 0); \tconst char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE, \t\tMAP_SHARED, mfd, 0); \tunsigned int old = syscall(SYS_personality, 0xffffffff); \tsyscall(SYS_personality, READ_IMPLIES_EXEC | old); \tsyscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0); \tsyscall(SYS_personality, old); \t// show the RWX page exists even if W^X policy is enforced \tint fd = open(\"/proc/self/maps\", O_RDONLY); \tunsigned char buf2[1024]; \twhile (1) { \t\tint ret = read(fd, buf2, 1024); \t\tif (ret <= 0) break; \t\twrite(1, buf2, ret); \t} \tclose(fd); } $ gcc test.c -o test $ ./test | grep rwx 7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted) [PM: subject line tweaks]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47746", "url": "https://ubuntu.com/security/CVE-2024-47746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: use exclusive lock when FUSE_I_CACHE_IO_MODE is set This may be a typo. The comment has said shared locks are not allowed when this bit is set. If using shared lock, the wait in `fuse_file_cached_io_open` may be forever.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47734", "url": "https://ubuntu.com/security/CVE-2024-47734", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: Fix unnecessary warnings and logs from bond_xdp_get_xmit_slave() syzbot reported a WARNING in bond_xdp_get_xmit_slave. To reproduce this[1], one bond device (bond1) has xdpdrv, which increases bpf_master_redirect_enabled_key. Another bond device (bond0) which is unsupported by XDP but its slave (veth3) has xdpgeneric that returns XDP_TX. This triggers WARN_ON_ONCE() from the xdp_master_redirect(). To reduce unnecessary warnings and improve log management, we need to delete the WARN_ON_ONCE() and add ratelimit to the netdev_err(). [1] Steps to reproduce: # Needs tx_xdp with return XDP_TX; ip l add veth0 type veth peer veth1 ip l add veth3 type veth peer veth4 ip l add bond0 type bond mode 6 # BOND_MODE_ALB, unsupported by XDP ip l add bond1 type bond # BOND_MODE_ROUNDROBIN by default ip l set veth0 master bond1 ip l set bond1 up # Increases bpf_master_redirect_enabled_key ip l set dev bond1 xdpdrv object tx_xdp.o section xdp_tx ip l set veth3 master bond0 ip l set bond0 up ip l set veth4 up # Triggers WARN_ON_ONCE() from the xdp_master_redirect() ip l set veth3 xdpgeneric object tx_xdp.o section xdp_tx", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47684", "url": "https://ubuntu.com/security/CVE-2024-47684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: check skb is non-NULL in tcp_rto_delta_us() We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic kernel that are running ceph and recently hit a null ptr dereference in tcp_rearm_rto(). Initially hitting it from the TLP path, but then later we also saw it getting hit from the RACK case as well. Here are examples of the oops messages we saw in each of those cases: Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020 Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode Jul 26 15:05:02 rx [11061395.792971] #PF: error_code(0x0000) - not-present page Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0 Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI Jul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu Jul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023 Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 <48> 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3 Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246 Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000 Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60 Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8 Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900 Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30 Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000 Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0 Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554 Jul 26 15:05:02 rx [11061395.916786] Call Trace: Jul 26 15:05:02 rx [11061395.919488] Jul 26 15:05:02 rx [11061395.921765] ? show_regs.cold+0x1a/0x1f Jul 26 15:05:02 rx [11061395.925859] ? __die+0x90/0xd9 Jul 26 15:05:02 rx [11061395.929169] ? no_context+0x196/0x380 Jul 26 15:05:02 rx [11061395.933088] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0 Jul 26 15:05:02 rx [11061395.938216] ? ip6_sublist_rcv_finish+0x3d/0x50 Jul 26 15:05:02 rx [11061395.943000] ? __bad_area_nosemaphore+0x50/0x1a0 Jul 26 15:05:02 rx [11061395.947873] ? bad_area_nosemaphore+0x16/0x20 Jul 26 15:05:02 rx [11061395.952486] ? do_user_addr_fault+0x267/0x450 Jul 26 15:05:02 rx [11061395.957104] ? ipv6_list_rcv+0x112/0x140 Jul 26 15:05:02 rx [11061395.961279] ? __do_page_fault+0x58/0x90 Jul 26 15:05:02 rx [11061395.965458] ? do_page_fault+0x2c/0xe0 Jul 26 15:05:02 rx [11061395.969465] ? page_fault+0x34/0x40 Jul 26 15:05:02 rx [11061395.973217] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.977313] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.981408] tcp_send_loss_probe+0x10b/0x220 Jul 26 15:05:02 rx [11061395.985937] tcp_write_timer_handler+0x1b4/0x240 Jul 26 15:05:02 rx [11061395.990809] tcp_write_timer+0x9e/0xe0 Jul 26 15:05:02 rx [11061395.994814] ? tcp_write_timer_handler+0x240/0x240 Jul 26 15:05:02 rx [11061395.999866] call_timer_fn+0x32/0x130 Jul 26 15:05:02 rx [11061396.003782] __run_timers.part.0+0x180/0x280 Jul 26 15:05:02 rx [11061396.008309] ? recalibrate_cpu_khz+0x10/0x10 Jul 26 15:05:02 rx [11061396.012841] ? native_x2apic_icr_write+0x30/0x30 Jul 26 15:05:02 rx [11061396.017718] ? lapic_next_even ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47747", "url": "https://ubuntu.com/security/CVE-2024-47747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race Condition In the ether3_probe function, a timer is initialized with a callback function ether3_ledoff, bound to &prev(dev)->timer. Once the timer is started, there is a risk of a race condition if the module or device is removed, triggering the ether3_remove function to perform cleanup. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | ether3_ledoff ether3_remove | free_netdev(dev); | put_devic | kfree(dev); | | ether3_outw(priv(dev)->regs.config2 |= CFG2_CTRLO, REG_CONFIG2); | // use dev Fix it by ensuring that the timer is canceled before proceeding with the cleanup in ether3_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47685", "url": "https://ubuntu.com/security/CVE-2024-47685", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put() syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending garbage on the four reserved tcp bits (th->res1) Use skb_put_zero() to clear the whole TCP header, as done in nf_reject_ip_tcphdr_put() BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5661 [inline] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775 process_backlog+0x4ad/0xa50 net/core/dev.c:6108 __napi_poll+0xe7/0x980 net/core/dev.c:6772 napi_poll net/core/dev.c:6841 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963 handle_softirqs+0x1ce/0x800 kernel/softirq.c:554 __do_softirq+0x14/0x1a kernel/softirq.c:588 do_softirq+0x9a/0x100 kernel/softirq.c:455 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline] __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450 dev_queue_xmit include/linux/netdevice.h:3105 [inline] neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366 inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135 __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143 tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333 __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679 inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750 __sys_connect_file net/socket.c:2061 [inline] __sys_connect+0x606/0x690 net/socket.c:2078 __do_sys_connect net/socket.c:2088 [inline] __se_sys_connect net/socket.c:2085 [inline] __x64_sys_connect+0x91/0xe0 net/socket.c:2085 x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43 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 Uninit was stored to memory at: nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47686", "url": "https://ubuntu.com/security/CVE-2024-47686", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ep93xx: clock: Fix off by one in ep93xx_div_recalc_rate() The psc->div[] array has psc->num_div elements. These values come from when we call clk_hw_register_div(). It's adc_divisors and ARRAY_SIZE(adc_divisors)) and so on. So this condition needs to be >= instead of > to prevent an out of bounds read.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47748", "url": "https://ubuntu.com/security/CVE-2024-47748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost_vdpa: assign irq bypass producer token correctly We used to call irq_bypass_unregister_producer() in vhost_vdpa_setup_vq_irq() which is problematic as we don't know if the token pointer is still valid or not. Actually, we use the eventfd_ctx as the token so the life cycle of the token should be bound to the VHOST_SET_VRING_CALL instead of vhost_vdpa_setup_vq_irq() which could be called by set_status(). Fixing this by setting up irq bypass producer's token when handling VHOST_SET_VRING_CALL and un-registering the producer before calling vhost_vring_ioctl() to prevent a possible use after free as eventfd could have been released in vhost_vring_ioctl(). And such registering and unregistering will only be done if DRIVER_OK is set.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47687", "url": "https://ubuntu.com/security/CVE-2024-47687", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa/mlx5: Fix invalid mr resource destroy Certain error paths from mlx5_vdpa_dev_add() can end up releasing mr resources which never got initialized in the first place. This patch adds the missing check in mlx5_vdpa_destroy_mr_resources() to block releasing non-initialized mr resources. Reference trace: mlx5_core 0000:08:00.2: mlx5_vdpa_dev_add:3274:(pid 2700) warning: No mac address provisioned? BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 140216067 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 8 PID: 2700 Comm: vdpa Kdump: loaded Not tainted 5.14.0-496.el9.x86_64 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:vhost_iotlb_del_range+0xf/0xe0 [vhost_iotlb] Code: [...] RSP: 0018:ff1c823ac23077f0 EFLAGS: 00010246 RAX: ffffffffc1a21a60 RBX: ffffffff899567a0 RCX: 0000000000000000 RDX: ffffffffffffffff RSI: 0000000000000000 RDI: 0000000000000000 RBP: ff1bda1f7c21e800 R08: 0000000000000000 R09: ff1c823ac2307670 R10: ff1c823ac2307668 R11: ffffffff8a9e7b68 R12: 0000000000000000 R13: 0000000000000000 R14: ff1bda1f43e341a0 R15: 00000000ffffffea FS: 00007f56eba7c740(0000) GS:ff1bda269f800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000104d90001 CR4: 0000000000771ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? mlx5_vdpa_free+0x3d/0x150 [mlx5_vdpa] ? __die_body.cold+0x8/0xd ? page_fault_oops+0x134/0x170 ? __irq_work_queue_local+0x2b/0xc0 ? irq_work_queue+0x2c/0x50 ? exc_page_fault+0x62/0x150 ? asm_exc_page_fault+0x22/0x30 ? __pfx_mlx5_vdpa_free+0x10/0x10 [mlx5_vdpa] ? vhost_iotlb_del_range+0xf/0xe0 [vhost_iotlb] mlx5_vdpa_free+0x3d/0x150 [mlx5_vdpa] vdpa_release_dev+0x1e/0x50 [vdpa] device_release+0x31/0x90 kobject_cleanup+0x37/0x130 mlx5_vdpa_dev_add+0x2d2/0x7a0 [mlx5_vdpa] vdpa_nl_cmd_dev_add_set_doit+0x277/0x4c0 [vdpa] genl_family_rcv_msg_doit+0xd9/0x130 genl_family_rcv_msg+0x14d/0x220 ? __pfx_vdpa_nl_cmd_dev_add_set_doit+0x10/0x10 [vdpa] ? _copy_to_user+0x1a/0x30 ? move_addr_to_user+0x4b/0xe0 genl_rcv_msg+0x47/0xa0 ? __import_iovec+0x46/0x150 ? __pfx_genl_rcv_msg+0x10/0x10 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x245/0x370 netlink_sendmsg+0x206/0x440 __sys_sendto+0x1dc/0x1f0 ? do_read_fault+0x10c/0x1d0 ? do_pte_missing+0x10d/0x190 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x5c/0xf0 ? __count_memcg_events+0x4f/0xb0 ? mm_account_fault+0x6c/0x100 ? handle_mm_fault+0x116/0x270 ? do_user_addr_fault+0x1d6/0x6a0 ? do_syscall_64+0x6b/0xf0 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 entry_SYSCALL_64_after_hwframe+0x78/0x80", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47688", "url": "https://ubuntu.com/security/CVE-2024-47688", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: driver core: Fix a potential null-ptr-deref in module_add_driver() Inject fault while probing of-fpga-region, if kasprintf() fails in module_add_driver(), the second sysfs_remove_link() in exit path will cause null-ptr-deref as below because kernfs_name_hash() will call strlen() with NULL driver_name. Fix it by releasing resources based on the exit path sequence. \t KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] \t Mem abort info: \t ESR = 0x0000000096000005 \t EC = 0x25: DABT (current EL), IL = 32 bits \t SET = 0, FnV = 0 \t EA = 0, S1PTW = 0 \t FSC = 0x05: level 1 translation fault \t Data abort info: \t ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 \t CM = 0, WnR = 0, TnD = 0, TagAccess = 0 \t GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 \t [dfffffc000000000] address between user and kernel address ranges \t Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP \t Dumping ftrace buffer: \t (ftrace buffer empty) \t Modules linked in: of_fpga_region(+) fpga_region fpga_bridge cfg80211 rfkill 8021q garp mrp stp llc ipv6 [last unloaded: of_fpga_region] \t CPU: 2 UID: 0 PID: 2036 Comm: modprobe Not tainted 6.11.0-rc2-g6a0e38264012 #295 \t Hardware name: linux,dummy-virt (DT) \t pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) \t pc : strlen+0x24/0xb0 \t lr : kernfs_name_hash+0x1c/0xc4 \t sp : ffffffc081f97380 \t x29: ffffffc081f97380 x28: ffffffc081f97b90 x27: ffffff80c821c2a0 \t x26: ffffffedac0be418 x25: 0000000000000000 x24: ffffff80c09d2000 \t x23: 0000000000000000 x22: 0000000000000000 x21: 0000000000000000 \t x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000001840 \t x17: 0000000000000000 x16: 0000000000000000 x15: 1ffffff8103f2e42 \t x14: 00000000f1f1f1f1 x13: 0000000000000004 x12: ffffffb01812d61d \t x11: 1ffffff01812d61c x10: ffffffb01812d61c x9 : dfffffc000000000 \t x8 : 0000004fe7ed29e4 x7 : ffffff80c096b0e7 x6 : 0000000000000001 \t x5 : ffffff80c096b0e0 x4 : 1ffffffdb990efa2 x3 : 0000000000000000 \t x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000000 \t Call trace: \t strlen+0x24/0xb0 \t kernfs_name_hash+0x1c/0xc4 \t kernfs_find_ns+0x118/0x2e8 \t kernfs_remove_by_name_ns+0x80/0x100 \t sysfs_remove_link+0x74/0xa8 \t module_add_driver+0x278/0x394 \t bus_add_driver+0x1f0/0x43c \t driver_register+0xf4/0x3c0 \t __platform_driver_register+0x60/0x88 \t of_fpga_region_init+0x20/0x1000 [of_fpga_region] \t do_one_initcall+0x110/0x788 \t do_init_module+0x1dc/0x5c8 \t load_module+0x3c38/0x4cac \t init_module_from_file+0xd4/0x128 \t idempotent_init_module+0x2cc/0x528 \t __arm64_sys_finit_module+0xac/0x100 \t invoke_syscall+0x6c/0x258 \t el0_svc_common.constprop.0+0x160/0x22c \t do_el0_svc+0x44/0x5c \t el0_svc+0x48/0xb8 \t el0t_64_sync_handler+0x13c/0x158 \t el0t_64_sync+0x190/0x194 \t Code: f2fbffe1 a90157f4 12000802 aa0003f5 (38e16861) \t ---[ end trace 0000000000000000 ]--- \t Kernel panic - not syncing: Oops: Fatal exception", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47689", "url": "https://ubuntu.com/security/CVE-2024-47689", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to don't set SB_RDONLY in f2fs_handle_critical_error() syzbot reports a f2fs bug as below: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 58 at kernel/rcu/sync.c:177 rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177 CPU: 1 UID: 0 PID: 58 Comm: kworker/1:2 Not tainted 6.10.0-syzkaller-12562-g1722389b0d86 #0 Workqueue: events destroy_super_work RIP: 0010:rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177 Call Trace: percpu_free_rwsem+0x41/0x80 kernel/locking/percpu-rwsem.c:42 destroy_super_work+0xec/0x130 fs/super.c:282 process_one_work kernel/workqueue.c:3231 [inline] process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 worker_thread+0x86d/0xd40 kernel/workqueue.c:3390 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 As Christian Brauner pointed out [1]: the root cause is f2fs sets SB_RDONLY flag in internal function, rather than setting the flag covered w/ sb->s_umount semaphore via remount procedure, then below race condition causes this bug: - freeze_super() - sb_wait_write(sb, SB_FREEZE_WRITE) - sb_wait_write(sb, SB_FREEZE_PAGEFAULT) - sb_wait_write(sb, SB_FREEZE_FS) \t\t\t\t\t- f2fs_handle_critical_error \t\t\t\t\t - sb->s_flags |= SB_RDONLY - thaw_super - thaw_super_locked - sb_rdonly() is true, so it skips sb_freeze_unlock(sb, SB_FREEZE_FS) - deactivate_locked_super Since f2fs has almost the same logic as ext4 [2] when handling critical error in filesystem if it mounts w/ errors=remount-ro option: - set CP_ERROR_FLAG flag which indicates filesystem is stopped - record errors to superblock - set SB_RDONLY falg Once we set CP_ERROR_FLAG flag, all writable interfaces can detect the flag and stop any further updates on filesystem. So, it is safe to not set SB_RDONLY flag, let's remove the logic and keep in line w/ ext4 [3]. [1] https://lore.kernel.org/all/20240729-himbeeren-funknetz-96e62f9c7aee@brauner [2] https://lore.kernel.org/all/20240729132721.hxih6ehigadqf7wx@quack3 [3] https://lore.kernel.org/linux-ext4/20240805201241.27286-1-jack@suse.cz", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47690", "url": "https://ubuntu.com/security/CVE-2024-47690", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: get rid of online repaire on corrupted directory syzbot reports a f2fs bug as below: kernel BUG at fs/f2fs/inode.c:896! RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Call Trace: evict+0x532/0x950 fs/inode.c:704 dispose_list fs/inode.c:747 [inline] evict_inodes+0x5f9/0x690 fs/inode.c:797 generic_shutdown_super+0x9d/0x2d0 fs/super.c:627 kill_block_super+0x44/0x90 fs/super.c:1696 kill_f2fs_super+0x344/0x690 fs/f2fs/super.c:4898 deactivate_locked_super+0xc4/0x130 fs/super.c:473 cleanup_mnt+0x41f/0x4b0 fs/namespace.c:1373 task_work_run+0x24f/0x310 kernel/task_work.c:228 ptrace_notify+0x2d2/0x380 kernel/signal.c:2402 ptrace_report_syscall include/linux/ptrace.h:415 [inline] ptrace_report_syscall_exit include/linux/ptrace.h:477 [inline] syscall_exit_work+0xc6/0x190 kernel/entry/common.c:173 syscall_exit_to_user_mode_prepare kernel/entry/common.c:200 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:205 [inline] syscall_exit_to_user_mode+0x279/0x370 kernel/entry/common.c:218 do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Online repaire on corrupted directory in f2fs_lookup() can generate dirty data/meta while racing w/ readonly remount, it may leave dirty inode after filesystem becomes readonly, however, checkpoint() will skips flushing dirty inode in a state of readonly mode, result in above panic. Let's get rid of online repaire in f2fs_lookup(), and leave the work to fsck.f2fs.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47691", "url": "https://ubuntu.com/security/CVE-2024-47691", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread() syzbot reports a f2fs bug as below: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_report+0xe8/0x550 mm/kasan/report.c:491 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 instrument_atomic_read_write include/linux/instrumented.h:96 [inline] atomic_fetch_add_relaxed include/linux/atomic/atomic-instrumented.h:252 [inline] __refcount_add include/linux/refcount.h:184 [inline] __refcount_inc include/linux/refcount.h:241 [inline] refcount_inc include/linux/refcount.h:258 [inline] get_task_struct include/linux/sched/task.h:118 [inline] kthread_stop+0xca/0x630 kernel/kthread.c:704 f2fs_stop_gc_thread+0x65/0xb0 fs/f2fs/gc.c:210 f2fs_do_shutdown+0x192/0x540 fs/f2fs/file.c:2283 f2fs_ioc_shutdown fs/f2fs/file.c:2325 [inline] __f2fs_ioctl+0x443a/0xbe60 fs/f2fs/file.c:4325 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f The root cause is below race condition, it may cause use-after-free issue in sbi->gc_th pointer. - remount - f2fs_remount - f2fs_stop_gc_thread - kfree(gc_th) \t\t\t\t- f2fs_ioc_shutdown \t\t\t\t - f2fs_do_shutdown \t\t\t\t - f2fs_stop_gc_thread \t\t\t\t - kthread_stop(gc_th->f2fs_gc_task) : sbi->gc_thread = NULL; We will call f2fs_do_shutdown() in two paths: - for f2fs_ioc_shutdown() path, we should grab sb->s_umount semaphore for fixing. - for f2fs_shutdown() path, it's safe since caller has already grabbed sb->s_umount semaphore.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47692", "url": "https://ubuntu.com/security/CVE-2024-47692", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: return -EINVAL when namelen is 0 When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may result in namelen being 0, which will cause memdup_user() to return ZERO_SIZE_PTR. When we access the name.data that has been assigned the value of ZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is triggered. [ T1205] ================================================================== [ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260 [ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205 [ T1205] [ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406 [ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ T1205] Call Trace: [ T1205] dump_stack+0x9a/0xd0 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] __kasan_report.cold+0x34/0x84 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] kasan_report+0x3a/0x50 [ T1205] nfs4_client_to_reclaim+0xe9/0x260 [ T1205] ? nfsd4_release_lockowner+0x410/0x410 [ T1205] cld_pipe_downcall+0x5ca/0x760 [ T1205] ? nfsd4_cld_tracking_exit+0x1d0/0x1d0 [ T1205] ? down_write_killable_nested+0x170/0x170 [ T1205] ? avc_policy_seqno+0x28/0x40 [ T1205] ? selinux_file_permission+0x1b4/0x1e0 [ T1205] rpc_pipe_write+0x84/0xb0 [ T1205] vfs_write+0x143/0x520 [ T1205] ksys_write+0xc9/0x170 [ T1205] ? __ia32_sys_read+0x50/0x50 [ T1205] ? ktime_get_coarse_real_ts64+0xfe/0x110 [ T1205] ? ktime_get_coarse_real_ts64+0xa2/0x110 [ T1205] do_syscall_64+0x33/0x40 [ T1205] entry_SYSCALL_64_after_hwframe+0x67/0xd1 [ T1205] RIP: 0033:0x7fdbdb761bc7 [ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 514 [ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7 [ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008 [ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001 [ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b [ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000 [ T1205] ================================================================== Fix it by checking namelen.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47737", "url": "https://ubuntu.com/security/CVE-2024-47737", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: call cache_put if xdr_reserve_space returns NULL If not enough buffer space available, but idmap_lookup has triggered lookup_fn which calls cache_get and returns successfully. Then we missed to call cache_put here which pairs with cache_get. Reviwed-by: Jeff Layton ", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2023-52917", "url": "https://ubuntu.com/security/CVE-2023-52917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir() The debugfs_create_dir() function returns error pointers. It never returns NULL. So use IS_ERR() to check it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47749", "url": "https://ubuntu.com/security/CVE-2024-47749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Added NULL check for lookup_atid The lookup_atid() function can return NULL if the ATID is invalid or does not exist in the identifier table, which could lead to dereferencing a null pointer without a check in the `act_establish()` and `act_open_rpl()` functions. Add a NULL check to prevent null pointer dereferencing. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47735", "url": "https://ubuntu.com/security/CVE-2024-47735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled Fix missuse of spin_lock_irq()/spin_unlock_irq() when spin_lock_irqsave()/spin_lock_irqrestore() was hold. This was discovered through the lock debugging, and the corresponding log is as follows: raw_local_irq_restore() called with IRQs enabled WARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40 ... Call trace: warn_bogus_irq_restore+0x30/0x40 _raw_spin_unlock_irqrestore+0x84/0xc8 add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2] hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2] hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2] create_qp+0x138/0x258 ib_create_qp_kernel+0x50/0xe8 create_mad_qp+0xa8/0x128 ib_mad_port_open+0x218/0x448 ib_mad_init_device+0x70/0x1f8 add_client_context+0xfc/0x220 enable_device_and_get+0xd0/0x140 ib_register_device.part.0+0xf4/0x1c8 ib_register_device+0x34/0x50 hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2] hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2] __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2] hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47750", "url": "https://ubuntu.com/security/CVE-2024-47750", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix Use-After-Free of rsv_qp on HIP08 Currently rsv_qp is freed before ib_unregister_device() is called on HIP08. During the time interval, users can still dereg MR and rsv_qp will be used in this process, leading to a UAF. Move the release of rsv_qp after calling ib_unregister_device() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47751", "url": "https://ubuntu.com/security/CVE-2024-47751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: kirin: Fix buffer overflow in kirin_pcie_parse_port() Within kirin_pcie_parse_port(), the pcie->num_slots is compared to pcie->gpio_id_reset size (MAX_PCI_SLOTS) which is correct and would lead to an overflow. Thus, fix condition to pcie->num_slots + 1 >= MAX_PCI_SLOTS and move pcie->num_slots increment below the if-statement to avoid out-of-bounds array access. Found by Linux Verification Center (linuxtesting.org) with SVACE. [kwilczynski: commit log]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47693", "url": "https://ubuntu.com/security/CVE-2024-47693", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/core: Fix ib_cache_setup_one error flow cleanup When ib_cache_update return an error, we exit ib_cache_setup_one instantly with no proper cleanup, even though before this we had already successfully done gid_table_setup_one, that results in the kernel WARN below. Do proper cleanup using gid_table_cleanup_one before returning the err in order to fix the issue. WARNING: CPU: 4 PID: 922 at drivers/infiniband/core/cache.c:806 gid_table_release_one+0x181/0x1a0 Modules linked in: CPU: 4 UID: 0 PID: 922 Comm: c_repro Not tainted 6.11.0-rc1+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:gid_table_release_one+0x181/0x1a0 Code: 44 8b 38 75 0c e8 2f cb 34 ff 4d 8b b5 28 05 00 00 e8 23 cb 34 ff 44 89 f9 89 da 4c 89 f6 48 c7 c7 d0 58 14 83 e8 4f de 21 ff <0f> 0b 4c 8b 75 30 e9 54 ff ff ff 48 8 3 c4 10 5b 5d 41 5c 41 5d 41 RSP: 0018:ffffc90002b835b0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c8527 RDX: 0000000000000000 RSI: ffffffff811c8534 RDI: 0000000000000001 RBP: ffff8881011b3d00 R08: ffff88810b3abe00 R09: 205d303839303631 R10: 666572207972746e R11: 72746e6520444947 R12: 0000000000000001 R13: ffff888106390000 R14: ffff8881011f2110 R15: 0000000000000001 FS: 00007fecc3b70800(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000340 CR3: 000000010435a001 CR4: 00000000003706b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? show_regs+0x94/0xa0 ? __warn+0x9e/0x1c0 ? gid_table_release_one+0x181/0x1a0 ? report_bug+0x1f9/0x340 ? gid_table_release_one+0x181/0x1a0 ? handle_bug+0xa2/0x110 ? exc_invalid_op+0x31/0xa0 ? asm_exc_invalid_op+0x16/0x20 ? __warn_printk+0xc7/0x180 ? __warn_printk+0xd4/0x180 ? gid_table_release_one+0x181/0x1a0 ib_device_release+0x71/0xe0 ? __pfx_ib_device_release+0x10/0x10 device_release+0x44/0xd0 kobject_put+0x135/0x3d0 put_device+0x20/0x30 rxe_net_add+0x7d/0xa0 rxe_newlink+0xd7/0x190 nldev_newlink+0x1b0/0x2a0 ? __pfx_nldev_newlink+0x10/0x10 rdma_nl_rcv_msg+0x1ad/0x2e0 rdma_nl_rcv_skb.constprop.0+0x176/0x210 netlink_unicast+0x2de/0x400 netlink_sendmsg+0x306/0x660 __sock_sendmsg+0x110/0x120 ____sys_sendmsg+0x30e/0x390 ___sys_sendmsg+0x9b/0xf0 ? kstrtouint+0x6e/0xa0 ? kstrtouint_from_user+0x7c/0xb0 ? get_pid_task+0xb0/0xd0 ? proc_fail_nth_write+0x5b/0x140 ? __fget_light+0x9a/0x200 ? preempt_count_add+0x47/0xa0 __sys_sendmsg+0x61/0xd0 do_syscall_64+0x50/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47694", "url": "https://ubuntu.com/security/CVE-2024-47694", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mlx5: Fix UMR pd cleanup on error flow of driver init The cited commit moves the pd allocation from function mlx5r_umr_resource_cleanup() to a new function mlx5r_umr_cleanup(). So the fix in commit [1] is broken. In error flow, will hit panic [2]. Fix it by checking pd pointer to avoid panic if it is NULL; [1] RDMA/mlx5: Fix UMR cleanup on error flow of driver init [2] [ 347.567063] infiniband mlx5_0: Couldn't register device with driver model [ 347.591382] BUG: kernel NULL pointer dereference, address: 0000000000000020 [ 347.593438] #PF: supervisor read access in kernel mode [ 347.595176] #PF: error_code(0x0000) - not-present page [ 347.596962] PGD 0 P4D 0 [ 347.601361] RIP: 0010:ib_dealloc_pd_user+0x12/0xc0 [ib_core] [ 347.604171] RSP: 0018:ffff888106293b10 EFLAGS: 00010282 [ 347.604834] RAX: 0000000000000000 RBX: 000000000000000e RCX: 0000000000000000 [ 347.605672] RDX: ffff888106293ad0 RSI: 0000000000000000 RDI: 0000000000000000 [ 347.606529] RBP: 0000000000000000 R08: ffff888106293ae0 R09: ffff888106293ae0 [ 347.607379] R10: 0000000000000a06 R11: 0000000000000000 R12: 0000000000000000 [ 347.608224] R13: ffffffffa0704dc0 R14: 0000000000000001 R15: 0000000000000001 [ 347.609067] FS: 00007fdc720cd9c0(0000) GS:ffff88852c880000(0000) knlGS:0000000000000000 [ 347.610094] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 347.610727] CR2: 0000000000000020 CR3: 0000000103012003 CR4: 0000000000370eb0 [ 347.611421] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 347.612113] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 347.612804] Call Trace: [ 347.613130] [ 347.613417] ? __die+0x20/0x60 [ 347.613793] ? page_fault_oops+0x150/0x3e0 [ 347.614243] ? free_msg+0x68/0x80 [mlx5_core] [ 347.614840] ? cmd_exec+0x48f/0x11d0 [mlx5_core] [ 347.615359] ? exc_page_fault+0x74/0x130 [ 347.615808] ? asm_exc_page_fault+0x22/0x30 [ 347.616273] ? ib_dealloc_pd_user+0x12/0xc0 [ib_core] [ 347.616801] mlx5r_umr_cleanup+0x23/0x90 [mlx5_ib] [ 347.617365] mlx5_ib_stage_pre_ib_reg_umr_cleanup+0x36/0x40 [mlx5_ib] [ 347.618025] __mlx5_ib_add+0x96/0xd0 [mlx5_ib] [ 347.618539] mlx5r_probe+0xe9/0x310 [mlx5_ib] [ 347.619032] ? kernfs_add_one+0x107/0x150 [ 347.619478] ? __mlx5_ib_add+0xd0/0xd0 [mlx5_ib] [ 347.619984] auxiliary_bus_probe+0x3e/0x90 [ 347.620448] really_probe+0xc5/0x3a0 [ 347.620857] __driver_probe_device+0x80/0x160 [ 347.621325] driver_probe_device+0x1e/0x90 [ 347.621770] __driver_attach+0xec/0x1c0 [ 347.622213] ? __device_attach_driver+0x100/0x100 [ 347.622724] bus_for_each_dev+0x71/0xc0 [ 347.623151] bus_add_driver+0xed/0x240 [ 347.623570] driver_register+0x58/0x100 [ 347.623998] __auxiliary_driver_register+0x6a/0xc0 [ 347.624499] ? driver_register+0xae/0x100 [ 347.624940] ? 0xffffffffa0893000 [ 347.625329] mlx5_ib_init+0x16a/0x1e0 [mlx5_ib] [ 347.625845] do_one_initcall+0x4a/0x2a0 [ 347.626273] ? gcov_event+0x2e2/0x3a0 [ 347.626706] do_init_module+0x8a/0x260 [ 347.627126] init_module_from_file+0x8b/0xd0 [ 347.627596] __x64_sys_finit_module+0x1ca/0x2f0 [ 347.628089] do_syscall_64+0x4c/0x100", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47695", "url": "https://ubuntu.com/security/CVE-2024-47695", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds In the function init_conns(), after the create_con() and create_cm() for loop if something fails. In the cleanup for loop after the destroy tag, we access out of bound memory because cid is set to clt_path->s.con_num. This commits resets the cid to clt_path->s.con_num - 1, to stay in bounds in the cleanup loop later.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47752", "url": "https://ubuntu.com/security/CVE-2024-47752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix H264 stateless decoder smatch warning Fix a smatch static checker warning on vdec_h264_req_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47753", "url": "https://ubuntu.com/security/CVE-2024-47753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix VP8 stateless decoder smatch warning Fix a smatch static checker warning on vdec_vp8_req_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47754", "url": "https://ubuntu.com/security/CVE-2024-47754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix H264 multi stateless decoder smatch warning Fix a smatch static checker warning on vdec_h264_req_multi_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47696", "url": "https://ubuntu.com/security/CVE-2024-47696", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency In the commit aee2424246f9 (\"RDMA/iwcm: Fix a use-after-free related to destroying CM IDs\"), the function flush_workqueue is invoked to flush the work queue iwcm_wq. But at that time, the work queue iwcm_wq was created via the function alloc_ordered_workqueue without the flag WQ_MEM_RECLAIM. Because the current process is trying to flush the whole iwcm_wq, if iwcm_wq doesn't have the flag WQ_MEM_RECLAIM, verify that the current process is not reclaiming memory or running on a workqueue which doesn't have the flag WQ_MEM_RECLAIM as that can break forward-progress guarantee leading to a deadlock. The call trace is as below: [ 125.350876][ T1430] Call Trace: [ 125.356281][ T1430] [ 125.361285][ T1430] ? __warn (kernel/panic.c:693) [ 125.367640][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.375689][ T1430] ? report_bug (lib/bug.c:180 lib/bug.c:219) [ 125.382505][ T1430] ? handle_bug (arch/x86/kernel/traps.c:239) [ 125.388987][ T1430] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) [ 125.395831][ T1430] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621) [ 125.403125][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.410984][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.418764][ T1430] __flush_workqueue (kernel/workqueue.c:3970) [ 125.426021][ T1430] ? __pfx___might_resched (kernel/sched/core.c:10151) [ 125.433431][ T1430] ? destroy_cm_id (drivers/infiniband/core/iwcm.c:375) iw_cm [ 125.441209][ T1430] ? __pfx___flush_workqueue (kernel/workqueue.c:3910) [ 125.473900][ T1430] ? _raw_spin_lock_irqsave (arch/x86/include/asm/atomic.h:107 include/linux/atomic/atomic-arch-fallback.h:2170 include/linux/atomic/atomic-instrumented.h:1302 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162) [ 125.473909][ T1430] ? __pfx__raw_spin_lock_irqsave (kernel/locking/spinlock.c:161) [ 125.482537][ T1430] _destroy_id (drivers/infiniband/core/cma.c:2044) rdma_cm [ 125.495072][ T1430] nvme_rdma_free_queue (drivers/nvme/host/rdma.c:656 drivers/nvme/host/rdma.c:650) nvme_rdma [ 125.505827][ T1430] nvme_rdma_reset_ctrl_work (drivers/nvme/host/rdma.c:2180) nvme_rdma [ 125.505831][ T1430] process_one_work (kernel/workqueue.c:3231) [ 125.515122][ T1430] worker_thread (kernel/workqueue.c:3306 kernel/workqueue.c:3393) [ 125.515127][ T1430] ? __pfx_worker_thread (kernel/workqueue.c:3339) [ 125.531837][ T1430] kthread (kernel/kthread.c:389) [ 125.539864][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.550628][ T1430] ret_from_fork (arch/x86/kernel/process.c:147) [ 125.558840][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.558844][ T1430] ret_from_fork_asm (arch/x86/entry/entry_64.S:257) [ 125.566487][ T1430] [ 125.566488][ T1430] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47755", "url": "https://ubuntu.com/security/CVE-2024-47755", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47756", "url": "https://ubuntu.com/security/CVE-2024-47756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: keystone: Fix if-statement expression in ks_pcie_quirk() This code accidentally uses && where || was intended. It potentially results in a NULL dereference. Thus, fix the if-statement expression to use the correct condition. [kwilczynski: commit log]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47697", "url": "https://ubuntu.com/security/CVE-2024-47697", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error Ensure index in rtl2830_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47698", "url": "https://ubuntu.com/security/CVE-2024-47698", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error Ensure index in rtl2832_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue. [hverkuil: added fixes tag, rtl2830_pid_filter -> rtl2832_pid_filter in logmsg]", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47728", "url": "https://ubuntu.com/security/CVE-2024-47728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error For all non-tracing helpers which formerly had ARG_PTR_TO_{LONG,INT} as input arguments, zero the value for the case of an error as otherwise it could leak memory. For tracing, it is not needed given CAP_PERFMON can already read all kernel memory anyway hence bpf_get_func_arg() and bpf_get_func_ret() is skipped in here. Also, the MTU helpers mtu_len pointer value is being written but also read. Technically, the MEM_UNINIT should not be there in order to always force init. Removing MEM_UNINIT needs more verifier rework though: MEM_UNINIT right now implies two things actually: i) write into memory, ii) memory does not have to be initialized. If we lift MEM_UNINIT, it then becomes: i) read into memory, ii) memory must be initialized. This means that for bpf_*_check_mtu() we're readding the issue we're trying to fix, that is, it would then be able to write back into things like .rodata BPF maps. Follow-up work will rework the MEM_UNINIT semantics such that the intent can be better expressed. For now just clear the *mtu_len on error path which can be lifted later again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49861", "url": "https://ubuntu.com/security/CVE-2024-49861", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix helper writes to read-only maps Lonial found an issue that despite user- and BPF-side frozen BPF map (like in case of .rodata), it was still possible to write into it from a BPF program side through specific helpers having ARG_PTR_TO_{LONG,INT} as arguments. In check_func_arg() when the argument is as mentioned, the meta->raw_mode is never set. Later, check_helper_mem_access(), under the case of PTR_TO_MAP_VALUE as register base type, it assumes BPF_READ for the subsequent call to check_map_access_type() and given the BPF map is read-only it succeeds. The helpers really need to be annotated as ARG_PTR_TO_{LONG,INT} | MEM_UNINIT when results are written into them as opposed to read out of them. The latter indicates that it's okay to pass a pointer to uninitialized memory as the memory is written to anyway. However, ARG_PTR_TO_{LONG,INT} is a special case of ARG_PTR_TO_FIXED_SIZE_MEM just with additional alignment requirement. So it is better to just get rid of the ARG_PTR_TO_{LONG,INT} special cases altogether and reuse the fixed size memory types. For this, add MEM_ALIGNED to additionally ensure alignment given these helpers write directly into the args via * = val. The .arg*_size has been initialized reflecting the actual sizeof(*). MEM_ALIGNED can only be used in combination with MEM_FIXED_SIZE annotated argument types, since in !MEM_FIXED_SIZE cases the verifier does not know the buffer size a priori and therefore cannot blindly write * = val.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47757", "url": "https://ubuntu.com/security/CVE-2024-47757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential oob read in nilfs_btree_check_delete() The function nilfs_btree_check_delete(), which checks whether degeneration to direct mapping occurs before deleting a b-tree entry, causes memory access outside the block buffer when retrieving the maximum key if the root node has no entries. This does not usually happen because b-tree mappings with 0 child nodes are never created by mkfs.nilfs2 or nilfs2 itself. However, it can happen if the b-tree root node read from a device is configured that way, so fix this potential issue by adding a check for that case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47699", "url": "https://ubuntu.com/security/CVE-2024-47699", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential null-ptr-deref in nilfs_btree_insert() Patch series \"nilfs2: fix potential issues with empty b-tree nodes\". This series addresses three potential issues with empty b-tree nodes that can occur with corrupted filesystem images, including one recently discovered by syzbot. This patch (of 3): If a b-tree is broken on the device, and the b-tree height is greater than 2 (the level of the root node is greater than 1) even if the number of child nodes of the b-tree root is 0, a NULL pointer dereference occurs in nilfs_btree_prepare_insert(), which is called from nilfs_btree_insert(). This is because, when the number of child nodes of the b-tree root is 0, nilfs_btree_do_lookup() does not set the block buffer head in any of path[x].bp_bh, leaving it as the initial value of NULL, but if the level of the b-tree root node is greater than 1, nilfs_btree_get_nonroot_node(), which accesses the buffer memory of path[x].bp_bh, is called. Fix this issue by adding a check to nilfs_btree_root_broken(), which performs sanity checks when reading the root node from the device, to detect this inconsistency. Thanks to Lizhi Xu for trying to solve the bug and clarifying the cause early on.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47700", "url": "https://ubuntu.com/security/CVE-2024-47700", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: check stripe size compatibility on remount as well We disable stripe size in __ext4_fill_super if it is not a multiple of the cluster ratio however this check is missed when trying to remount. This can leave us with cases where stripe < cluster_ratio after remount:set making EXT4_B2C(sbi->s_stripe) become 0 that can cause some unforeseen bugs like divide by 0. Fix that by adding the check in remount path as well.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47701", "url": "https://ubuntu.com/security/CVE-2024-47701", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid OOB when system.data xattr changes underneath the filesystem When looking up for an entry in an inlined directory, if e_value_offs is changed underneath the filesystem by some change in the block device, it will lead to an out-of-bounds access that KASAN detects as an UAF. EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none. loop0: detected capacity change from 2048 to 2047 ================================================================== BUG: KASAN: use-after-free in ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 Read of size 1 at addr ffff88803e91130f by task syz-executor269/5103 CPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 Not tainted 6.11.0-rc4-syzkaller #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:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 ext4_find_inline_entry+0x4be/0x5e0 fs/ext4/inline.c:1697 __ext4_find_entry+0x2b4/0x1b30 fs/ext4/namei.c:1573 ext4_lookup_entry fs/ext4/namei.c:1727 [inline] ext4_lookup+0x15f/0x750 fs/ext4/namei.c:1795 lookup_one_qstr_excl+0x11f/0x260 fs/namei.c:1633 filename_create+0x297/0x540 fs/namei.c:3980 do_symlinkat+0xf9/0x3a0 fs/namei.c:4587 __do_sys_symlinkat fs/namei.c:4610 [inline] __se_sys_symlinkat fs/namei.c:4607 [inline] __x64_sys_symlinkat+0x95/0xb0 fs/namei.c:4607 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:0x7f3e73ced469 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff4d40c258 EFLAGS: 00000246 ORIG_RAX: 000000000000010a RAX: ffffffffffffffda RBX: 0032656c69662f2e RCX: 00007f3e73ced469 RDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0 RBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290 R10: 0023706f6f6c2f76 R11: 0000000000000246 R12: 00007fff4d40c27c R13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0 Calling ext4_xattr_ibody_find right after reading the inode with ext4_get_inode_loc will lead to a check of the validity of the xattrs, avoiding this problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49850", "url": "https://ubuntu.com/security/CVE-2024-49850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: correctly handle malformed BPF_CORE_TYPE_ID_LOCAL relos In case of malformed relocation record of kind BPF_CORE_TYPE_ID_LOCAL referencing a non-existing BTF type, function bpf_core_calc_relo_insn would cause a null pointer deference. Fix this by adding a proper check upper in call stack, as malformed relocation records could be passed from user space. Simplest reproducer is a program: r0 = 0 exit With a single relocation record: .insn_off = 0, /* patch first instruction */ .type_id = 100500, /* this type id does not exist */ .access_str_off = 6, /* offset of string \"0\" */ .kind = BPF_CORE_TYPE_ID_LOCAL, See the link for original reproducer or next commit for a test case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47702", "url": "https://ubuntu.com/security/CVE-2024-47702", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fail verification for sign-extension of packet data/data_end/data_meta syzbot reported a kernel crash due to commit 1f1e864b6555 (\"bpf: Handle sign-extenstin ctx member accesses\"). The reason is due to sign-extension of 32-bit load for packet data/data_end/data_meta uapi field. The original code looks like: r2 = *(s32 *)(r1 + 76) /* load __sk_buff->data */ r3 = *(u32 *)(r1 + 80) /* load __sk_buff->data_end */ r0 = r2 r0 += 8 if r3 > r0 goto +1 ... Note that __sk_buff->data load has 32-bit sign extension. After verification and convert_ctx_accesses(), the final asm code looks like: r2 = *(u64 *)(r1 +208) r2 = (s32)r2 r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 ... Note that 'r2 = (s32)r2' may make the kernel __sk_buff->data address invalid which may cause runtime failure. Currently, in C code, typically we have void *data = (void *)(long)skb->data; void *data_end = (void *)(long)skb->data_end; ... and it will generate r2 = *(u64 *)(r1 +208) r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 If we allow sign-extension, void *data = (void *)(long)(int)skb->data; void *data_end = (void *)(long)skb->data_end; ... the generated code looks like r2 = *(u64 *)(r1 +208) r2 <<= 32 r2 s>>= 32 r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 and this will cause verification failure since \"r2 <<= 32\" is not allowed as \"r2\" is a packet pointer. To fix this issue for case r2 = *(s32 *)(r1 + 76) /* load __sk_buff->data */ this patch added additional checking in is_valid_access() callback function for packet data/data_end/data_meta access. If those accesses are with sign-extenstion, the verification will fail. [1] https://lore.kernel.org/bpf/000000000000c90eee061d236d37@google.com/", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47703", "url": "https://ubuntu.com/security/CVE-2024-47703", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, lsm: Add check for BPF LSM return value A bpf prog returning a positive number attached to file_alloc_security hook makes kernel panic. This happens because file system can not filter out the positive number returned by the LSM prog using IS_ERR, and misinterprets this positive number as a file pointer. Given that hook file_alloc_security never returned positive number before the introduction of BPF LSM, and other BPF LSM hooks may encounter similar issues, this patch adds LSM return value check in verifier, to ensure no unexpected value is returned.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49851", "url": "https://ubuntu.com/security/CVE-2024-49851", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: Clean up TPM space after command failure tpm_dev_transmit prepares the TPM space before attempting command transmission. However if the command fails no rollback of this preparation is done. This can result in transient handles being leaked if the device is subsequently closed with no further commands performed. Fix this by flushing the space in the event of command transmission failure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47723", "url": "https://ubuntu.com/security/CVE-2024-47723", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: fix out-of-bounds in dbNextAG() and diAlloc() In dbNextAG() , there is no check for the case where bmp->db_numag is greater or same than MAXAG due to a polluted image, which causes an out-of-bounds. Therefore, a bounds check should be added in dbMount(). And in dbNextAG(), a check for the case where agpref is greater than bmp->db_numag should be added, so an out-of-bounds exception should be prevented. Additionally, a check for the case where agno is greater or same than MAXAG should be added in diAlloc() to prevent out-of-bounds.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49852", "url": "https://ubuntu.com/security/CVE-2024-49852", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: elx: libefc: Fix potential use after free in efc_nport_vport_del() The kref_put() function will call nport->release if the refcount drops to zero. The nport->release release function is _efc_nport_free() which frees \"nport\". But then we dereference \"nport\" on the next line which is a use after free. Re-order these lines to avoid the use after free.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47720", "url": "https://ubuntu.com/security/CVE-2024-47720", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for set_output_gamma in dcn30_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn30_set_output_transfer_func function. Previously, set_output_gamma was being checked for nullity at line 386, but then it was being dereferenced without any nullity check at line 401. This could potentially lead to a null pointer dereference error if set_output_gamma is indeed null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a nullity check for set_output_gamma before the call to set_output_gamma at line 401. If set_output_gamma is null, we log an error message and do not call the function. This fix prevents a potential null pointer dereference error. drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:401 dcn30_set_output_transfer_func() error: we previously assumed 'mpc->funcs->set_output_gamma' could be null (see line 386) drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c 373 bool dcn30_set_output_transfer_func(struct dc *dc, 374 struct pipe_ctx *pipe_ctx, 375 const struct dc_stream_state *stream) 376 { 377 int mpcc_id = pipe_ctx->plane_res.hubp->inst; 378 struct mpc *mpc = pipe_ctx->stream_res.opp->ctx->dc->res_pool->mpc; 379 const struct pwl_params *params = NULL; 380 bool ret = false; 381 382 /* program OGAM or 3DLUT only for the top pipe*/ 383 if (pipe_ctx->top_pipe == NULL) { 384 /*program rmu shaper and 3dlut in MPC*/ 385 ret = dcn30_set_mpc_shaper_3dlut(pipe_ctx, stream); 386 if (ret == false && mpc->funcs->set_output_gamma) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If this is NULL 387 if (stream->out_transfer_func.type == TF_TYPE_HWPWL) 388 params = &stream->out_transfer_func.pwl; 389 else if (pipe_ctx->stream->out_transfer_func.type == 390 TF_TYPE_DISTRIBUTED_POINTS && 391 cm3_helper_translate_curve_to_hw_format( 392 &stream->out_transfer_func, 393 &mpc->blender_params, false)) 394 params = &mpc->blender_params; 395 /* there are no ROM LUTs in OUTGAM */ 396 if (stream->out_transfer_func.type == TF_TYPE_PREDEFINED) 397 BREAK_TO_DEBUGGER(); 398 } 399 } 400 --> 401 mpc->funcs->set_output_gamma(mpc, mpcc_id, params); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Then it will crash 402 return ret; 403 }", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47704", "url": "https://ubuntu.com/security/CVE-2024-47704", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check link_res->hpo_dp_link_enc before using it [WHAT & HOW] Functions dp_enable_link_phy and dp_disable_link_phy can pass link_res without initializing hpo_dp_link_enc and it is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49853", "url": "https://ubuntu.com/security/CVE-2024-49853", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix double free in OPTEE transport Channels can be shared between protocols, avoid freeing the same channel descriptors twice when unloading the stack.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47705", "url": "https://ubuntu.com/security/CVE-2024-47705", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix potential invalid pointer dereference in blk_add_partition The blk_add_partition() function initially used a single if-condition (IS_ERR(part)) to check for errors when adding a partition. This was modified to handle the specific case of -ENXIO separately, allowing the function to proceed without logging the error in this case. However, this change unintentionally left a path where md_autodetect_dev() could be called without confirming that part is a valid pointer. This commit separates the error handling logic by splitting the initial if-condition, improving code readability and handling specific error scenarios explicitly. The function now distinguishes the general error case from -ENXIO without altering the existing behavior of md_autodetect_dev() calls.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47736", "url": "https://ubuntu.com/security/CVE-2024-47736", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: handle overlapped pclusters out of crafted images properly syzbot reported a task hang issue due to a deadlock case where it is waiting for the folio lock of a cached folio that will be used for cache I/Os. After looking into the crafted fuzzed image, I found it's formed with several overlapped big pclusters as below: Ext: logical offset | length : physical offset | length 0: 0.. 16384 | 16384 : 151552.. 167936 | 16384 1: 16384.. 32768 | 16384 : 155648.. 172032 | 16384 2: 32768.. 49152 | 16384 : 537223168.. 537239552 | 16384 ... Here, extent 0/1 are physically overlapped although it's entirely _impossible_ for normal filesystem images generated by mkfs. First, managed folios containing compressed data will be marked as up-to-date and then unlocked immediately (unlike in-place folios) when compressed I/Os are complete. If physical blocks are not submitted in the incremental order, there should be separate BIOs to avoid dependency issues. However, the current code mis-arranges z_erofs_fill_bio_vec() and BIO submission which causes unexpected BIO waits. Second, managed folios will be connected to their own pclusters for efficient inter-queries. However, this is somewhat hard to implement easily if overlapped big pclusters exist. Again, these only appear in fuzzed images so let's simply fall back to temporary short-lived pages for correctness. Additionally, it justifies that referenced managed folios cannot be truncated for now and reverts part of commit 2080ca1ed3e4 (\"erofs: tidy up `struct z_erofs_bvec`\") for simplicity although it shouldn't be any difference.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47706", "url": "https://ubuntu.com/security/CVE-2024-47706", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block, bfq: fix possible UAF for bfqq->bic with merge chain 1) initial state, three tasks: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t\t | ? | ?\t\t | ? \t\t | | | |\t\t | | \t\t V | V |\t\t V | \t\t bfqq1 bfqq2\t\t bfqq3 process ref:\t 1\t\t 1\t\t 1 2) bfqq1 merged to bfqq2: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t\t | |\t\t | ? \t\t \\--------------\\|\t\t | | \t\t V\t\t V | \t\t bfqq1--------->bfqq2\t\t bfqq3 process ref:\t 0\t\t 2\t\t 1 3) bfqq2 merged to bfqq3: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t here -> ? |\t\t | \t\t \\--------------\\ \\-------------\\| \t\t V\t\t V \t\t bfqq1--------->bfqq2---------->bfqq3 process ref:\t 0\t\t 1\t\t 3 In this case, IO from Process 1 will get bfqq2 from BIC1 first, and then get bfqq3 through merge chain, and finially handle IO by bfqq3. Howerver, current code will think bfqq2 is owned by BIC1, like initial state, and set bfqq2->bic to BIC1. bfq_insert_request -> by Process 1 bfqq = bfq_init_rq(rq) bfqq = bfq_get_bfqq_handle_split bfqq = bic_to_bfqq -> get bfqq2 from BIC1 bfqq->ref++ rq->elv.priv[0] = bic rq->elv.priv[1] = bfqq if (bfqq_process_refs(bfqq) == 1) bfqq->bic = bic -> record BIC1 to bfqq2 __bfq_insert_request new_bfqq = bfq_setup_cooperator -> get bfqq3 from bfqq2->new_bfqq bfqq_request_freed(bfqq) new_bfqq->ref++ rq->elv.priv[1] = new_bfqq -> handle IO by bfqq3 Fix the problem by checking bfqq is from merge chain fist. And this might fix a following problem reported by our syzkaller(unreproducible): ================================================================== BUG: KASAN: slab-use-after-free in bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] BUG: KASAN: slab-use-after-free in bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] BUG: KASAN: slab-use-after-free in bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 Write of size 1 at addr ffff888123839eb8 by task kworker/0:1H/18595 CPU: 0 PID: 18595 Comm: kworker/0:1H Tainted: G L 6.6.0-07439-gba2303cacfda #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Workqueue: kblockd blk_mq_requeue_work Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [inline] print_report+0x10d/0x610 mm/kasan/report.c:475 kasan_report+0x8e/0xc0 mm/kasan/report.c:588 bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 bfq_get_bfqq_handle_split+0x169/0x5d0 block/bfq-iosched.c:6757 bfq_init_rq block/bfq-iosched.c:6876 [inline] bfq_insert_request block/bfq-iosched.c:6254 [inline] bfq_insert_requests+0x1112/0x5cf0 block/bfq-iosched.c:6304 blk_mq_insert_request+0x290/0x8d0 block/blk-mq.c:2593 blk_mq_requeue_work+0x6bc/0xa70 block/blk-mq.c:1502 process_one_work kernel/workqueue.c:2627 [inline] process_scheduled_works+0x432/0x13f0 kernel/workqueue.c:2700 worker_thread+0x6f2/0x1160 kernel/workqueue.c:2781 kthread+0x33c/0x440 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:305 Allocated by task 20776: kasan_save_stack+0x20/0x40 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 __kasan_slab_alloc+0x87/0x90 mm/kasan/common.c:328 kasan_slab_alloc include/linux/kasan.h:188 [inline] slab_post_alloc_hook mm/slab.h:763 [inline] slab_alloc_node mm/slub.c:3458 [inline] kmem_cache_alloc_node+0x1a4/0x6f0 mm/slub.c:3503 ioc_create_icq block/blk-ioc.c:370 [inline] ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49855", "url": "https://ubuntu.com/security/CVE-2024-49855", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: fix race between timeout and normal completion If request timetout is handled by nbd_requeue_cmd(), normal completion has to be stopped for avoiding to complete this requeued request, other use-after-free can be triggered. Fix the race by clearing NBD_CMD_INFLIGHT in nbd_requeue_cmd(), meantime make sure that cmd->lock is grabbed for clearing the flag and the requeue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47707", "url": "https://ubuntu.com/security/CVE-2024-47707", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev() Blamed commit accidentally removed a check for rt->rt6i_idev being NULL, as spotted by syzbot: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 UID: 0 PID: 10998 Comm: syz-executor Not tainted 6.11.0-rc6-syzkaller-00208-g625403177711 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 RBP: ffffc900047375d0 R08: 0000000000000003 R09: fffff520008e6e8c R10: dffffc0000000000 R11: fffff520008e6e8c R12: 1ffff1100fdf8f18 R13: ffff88807efc7998 R14: 0000000000000000 R15: ffff88807efc7930 FS: 0000000000000000(0000) GS:ffff8880b8900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020002a80 CR3: 0000000022f62000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: addrconf_ifdown+0x15d/0x1bd0 net/ipv6/addrconf.c:3856 addrconf_notify+0x3cb/0x1020 notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93 call_netdevice_notifiers_extack net/core/dev.c:2032 [inline] call_netdevice_notifiers net/core/dev.c:2046 [inline] unregister_netdevice_many_notify+0xd81/0x1c40 net/core/dev.c:11352 unregister_netdevice_many net/core/dev.c:11414 [inline] unregister_netdevice_queue+0x303/0x370 net/core/dev.c:11289 unregister_netdevice include/linux/netdevice.h:3129 [inline] __tun_detach+0x6b9/0x1600 drivers/net/tun.c:685 tun_detach drivers/net/tun.c:701 [inline] tun_chr_close+0x108/0x1b0 drivers/net/tun.c:3510 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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:0x7f1acc77def9 Code: Unable to access opcode bytes at 0x7f1acc77decf. RSP: 002b:00007ffeb26fa738 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1acc77def9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000043 RBP: 00007f1acc7dd508 R08: 00007ffeb26f84d7 R09: 0000000000000003 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 0000000000000003 R14: 00000000ffffffff R15: 00007ffeb26fa8e0 Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 R ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47708", "url": "https://ubuntu.com/security/CVE-2024-47708", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netkit: Assign missing bpf_net_context During the introduction of struct bpf_net_context handling for XDP-redirect, the netkit driver has been missed, which also requires it because NETKIT_REDIRECT invokes skb_do_redirect() which is accessing the per-CPU variables. Otherwise we see the following crash: \tBUG: kernel NULL pointer dereference, address: 0000000000000038 \tbpf_redirect() \tnetkit_xmit() \tdev_hard_start_xmit() Set the bpf_net_context before invoking netkit_xmit() program within the netkit driver.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47709", "url": "https://ubuntu.com/security/CVE-2024-47709", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: Clear bo->bcm_proc_read after remove_proc_entry(). syzbot reported a warning in bcm_release(). [0] The blamed change fixed another warning that is triggered when connect() is issued again for a socket whose connect()ed device has been unregistered. However, if the socket is just close()d without the 2nd connect(), the remaining bo->bcm_proc_read triggers unnecessary remove_proc_entry() in bcm_release(). Let's clear bo->bcm_proc_read after remove_proc_entry() in bcm_notify(). [0] name '4986' WARNING: CPU: 0 PID: 5234 at fs/proc/generic.c:711 remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Modules linked in: CPU: 0 UID: 0 PID: 5234 Comm: syz-executor606 Not tainted 6.11.0-rc5-syzkaller-00178-g5517ae241919 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Code: ff eb 05 e8 cb 1e 5e ff 48 8b 5c 24 10 48 c7 c7 e0 f7 aa 8e e8 2a 38 8e 09 90 48 c7 c7 60 3a 1b 8c 48 89 de e8 da 42 20 ff 90 <0f> 0b 90 90 48 8b 44 24 18 48 c7 44 24 40 0e 36 e0 45 49 c7 04 07 RSP: 0018:ffffc9000345fa20 EFLAGS: 00010246 RAX: 2a2d0aee2eb64600 RBX: ffff888032f1f548 RCX: ffff888029431e00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000345fb08 R08: ffffffff8155b2f2 R09: 1ffff1101710519a R10: dffffc0000000000 R11: ffffed101710519b R12: ffff888011d38640 R13: 0000000000000004 R14: 0000000000000000 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8880b8800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcfb52722f0 CR3: 000000000e734000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: bcm_release+0x250/0x880 net/can/bcm.c:1578 __sock_release net/socket.c:659 [inline] sock_close+0xbc/0x240 net/socket.c:1421 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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:0x7fcfb51ee969 Code: Unable to access opcode bytes at 0x7fcfb51ee93f. RSP: 002b:00007ffce0109ca8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fcfb51ee969 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 00007fcfb526f3b0 R08: ffffffffffffffb8 R09: 0000555500000000 R10: 0000555500000000 R11: 0000000000000246 R12: 00007fcfb526f3b0 R13: 0000000000000000 R14: 00007fcfb5271ee0 R15: 00007fcfb51bf160 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47710", "url": "https://ubuntu.com/security/CVE-2024-47710", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sock_map: Add a cond_resched() in sock_hash_free() Several syzbot soft lockup reports all have in common sock_hash_free() If a map with a large number of buckets is destroyed, we need to yield the cpu when needed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47711", "url": "https://ubuntu.com/security/CVE-2024-47711", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Don't return OOB skb in manage_oob(). syzbot reported use-after-free in unix_stream_recv_urg(). [0] The scenario is 1. send(MSG_OOB) 2. recv(MSG_OOB) -> The consumed OOB remains in recv queue 3. send(MSG_OOB) 4. recv() -> manage_oob() returns the next skb of the consumed OOB -> This is also OOB, but unix_sk(sk)->oob_skb is not cleared 5. recv(MSG_OOB) -> unix_sk(sk)->oob_skb is used but already freed The recent commit 8594d9b85c07 (\"af_unix: Don't call skb_get() for OOB skb.\") uncovered the issue. If the OOB skb is consumed and the next skb is peeked in manage_oob(), we still need to check if the skb is OOB. Let's do so by falling back to the following checks in manage_oob() and add the test case in selftest. Note that we need to add a similar check for SIOCATMARK. [0]: BUG: KASAN: slab-use-after-free in unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959 Read of size 4 at addr ffff8880326abcc4 by task syz-executor178/5235 CPU: 0 UID: 0 PID: 5235 Comm: syz-executor178 Not tainted 6.11.0-rc5-syzkaller-00742-gfbdaffe41adc #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959 unix_stream_recv_urg+0x1df/0x320 net/unix/af_unix.c:2640 unix_stream_read_generic+0x2456/0x2520 net/unix/af_unix.c:2778 unix_stream_recvmsg+0x22b/0x2c0 net/unix/af_unix.c:2996 sock_recvmsg_nosec net/socket.c:1046 [inline] sock_recvmsg+0x22f/0x280 net/socket.c:1068 ____sys_recvmsg+0x1db/0x470 net/socket.c:2816 ___sys_recvmsg net/socket.c:2858 [inline] __sys_recvmsg+0x2f0/0x3e0 net/socket.c:2888 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:0x7f5360d6b4e9 Code: 48 83 c4 28 c3 e8 37 17 00 00 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff29b3a458 EFLAGS: 00000246 ORIG_RAX: 000000000000002f RAX: ffffffffffffffda RBX: 00007fff29b3a638 RCX: 00007f5360d6b4e9 RDX: 0000000000002001 RSI: 0000000020000640 RDI: 0000000000000003 RBP: 00007f5360dde610 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 00007fff29b3a628 R14: 0000000000000001 R15: 0000000000000001 Allocated by task 5235: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:312 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slub.c:3988 [inline] slab_alloc_node mm/slub.c:4037 [inline] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4080 __alloc_skb+0x1c3/0x440 net/core/skbuff.c:667 alloc_skb include/linux/skbuff.h:1320 [inline] alloc_skb_with_frags+0xc3/0x770 net/core/skbuff.c:6528 sock_alloc_send_pskb+0x91a/0xa60 net/core/sock.c:2815 sock_alloc_send_skb include/net/sock.h:1778 [inline] queue_oob+0x108/0x680 net/unix/af_unix.c:2198 unix_stream_sendmsg+0xd24/0xf80 net/unix/af_unix.c:2351 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2680 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 Freed by task 5235: kasan_save_stack mm/kasan/common.c:47 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47712", "url": "https://ubuntu.com/security/CVE-2024-47712", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: fix potential RCU dereference issue in wilc_parse_join_bss_param In the `wilc_parse_join_bss_param` function, the TSF field of the `ies` structure is accessed after the RCU read-side critical section is unlocked. According to RCU usage rules, this is illegal. Reusing this pointer can lead to unpredictable behavior, including accessing memory that has been updated or causing use-after-free issues. This possible bug was identified using a static analysis tool developed by myself, specifically designed to detect RCU-related issues. To address this, the TSF value is now stored in a local variable `ies_tsf` before the RCU lock is released. The `param->tsf_lo` field is then assigned using this local variable, ensuring that the TSF value is safely accessed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47713", "url": "https://ubuntu.com/security/CVE-2024-47713", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop() Since '__dev_queue_xmit()' should be called with interrupts enabled, the following backtrace: ieee80211_do_stop() ... spin_lock_irqsave(&local->queue_stop_reason_lock, flags) ... ieee80211_free_txskb() ieee80211_report_used_skb() ieee80211_report_ack_skb() cfg80211_mgmt_tx_status_ext() nl80211_frame_tx_status() genlmsg_multicast_netns() genlmsg_multicast_netns_filtered() nlmsg_multicast_filtered() \t netlink_broadcast_filtered() \t do_one_broadcast() \t netlink_broadcast_deliver() \t __netlink_sendskb() \t netlink_deliver_tap() \t __netlink_deliver_tap_skb() \t dev_queue_xmit() \t __dev_queue_xmit() ; with IRQS disabled ... spin_unlock_irqrestore(&local->queue_stop_reason_lock, flags) issues the warning (as reported by syzbot reproducer): WARNING: CPU: 2 PID: 5128 at kernel/softirq.c:362 __local_bh_enable_ip+0xc3/0x120 Fix this by implementing a two-phase skb reclamation in 'ieee80211_do_stop()', where actual work is performed outside of a section with interrupts disabled.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47730", "url": "https://ubuntu.com/security/CVE-2024-47730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/qm - inject error before stopping queue The master ooo cannot be completely closed when the accelerator core reports memory error. Therefore, the driver needs to inject the qm error to close the master ooo. Currently, the qm error is injected after stopping queue, memory may be released immediately after stopping queue, causing the device to access the released memory. Therefore, error is injected to close master ooo before stopping queue to ensure that the device does not access the released memory.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49856", "url": "https://ubuntu.com/security/CVE-2024-49856", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/sgx: Fix deadlock in SGX NUMA node search When the current node doesn't have an EPC section configured by firmware and all other EPC sections are used up, CPU can get stuck inside the while loop that looks for an available EPC page from remote nodes indefinitely, leading to a soft lockup. Note how nid_of_current will never be equal to nid in that while loop because nid_of_current is not set in sgx_numa_mask. Also worth mentioning is that it's perfectly fine for the firmware not to setup an EPC section on a node. While setting up an EPC section on each node can enhance performance, it is not a requirement for functionality. Rework the loop to start and end on *a* node that has SGX memory. This avoids the deadlock looking for the current SGX-lacking node to show up in the loop when it never will.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47714", "url": "https://ubuntu.com/security/CVE-2024-47714", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: use hweight16 to get correct tx antenna The chainmask is u16 so using hweight8 cannot get correct tx_ant. Without this patch, the tx_ant of band 2 would be -1 and lead to the following issue: BUG: KASAN: stack-out-of-bounds in mt7996_mcu_add_sta+0x12e0/0x16e0 [mt7996e]", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47715", "url": "https://ubuntu.com/security/CVE-2024-47715", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: fix oops on non-dbdc mt7986 mt7915_band_config() sets band_idx = 1 on the main phy for mt7986 with MT7975_ONE_ADIE or MT7976_ONE_ADIE. Commit 0335c034e726 (\"wifi: mt76: fix race condition related to checking tx queue fill status\") introduced a dereference of the phys array indirectly indexed by band_idx via wcid->phy_idx in mt76_wcid_cleanup(). This caused the following Oops on affected mt7986 devices: Unable to handle kernel read from unreadable memory at virtual address 0000000000000024 Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x00000005 CM = 0, WnR = 0 user pgtable: 4k pages, 39-bit VAs, pgdp=0000000042545000 [0000000000000024] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 Internal error: Oops: 0000000096000005 [#1] SMP Modules linked in: ... mt7915e mt76_connac_lib mt76 mac80211 cfg80211 ... CPU: 2 PID: 1631 Comm: hostapd Not tainted 5.15.150 #0 Hardware name: ZyXEL EX5700 (Telenor) (DT) pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mt76_wcid_cleanup+0x84/0x22c [mt76] lr : mt76_wcid_cleanup+0x64/0x22c [mt76] sp : ffffffc00a803700 x29: ffffffc00a803700 x28: ffffff80008f7300 x27: ffffff80003f3c00 x26: ffffff80000a7880 x25: ffffffc008c26e00 x24: 0000000000000001 x23: ffffffc000a68114 x22: 0000000000000000 x21: ffffff8004172cc8 x20: ffffffc00a803748 x19: ffffff8004152020 x18: 0000000000000000 x17: 00000000000017c0 x16: ffffffc008ef5000 x15: 0000000000000be0 x14: ffffff8004172e28 x13: ffffff8004172e28 x12: 0000000000000000 x11: 0000000000000000 x10: ffffff8004172e30 x9 : ffffff8004172e28 x8 : 0000000000000000 x7 : ffffff8004156020 x6 : 0000000000000000 x5 : 0000000000000031 x4 : 0000000000000000 x3 : 0000000000000001 x2 : 0000000000000000 x1 : ffffff80008f7300 x0 : 0000000000000024 Call trace: mt76_wcid_cleanup+0x84/0x22c [mt76] __mt76_sta_remove+0x70/0xbc [mt76] mt76_sta_state+0x8c/0x1a4 [mt76] mt7915_eeprom_get_power_delta+0x11e4/0x23a0 [mt7915e] drv_sta_state+0x144/0x274 [mac80211] sta_info_move_state+0x1cc/0x2a4 [mac80211] sta_set_sinfo+0xaf8/0xc24 [mac80211] sta_info_destroy_addr_bss+0x4c/0x6c [mac80211] ieee80211_color_change_finish+0x1c08/0x1e70 [mac80211] cfg80211_check_station_change+0x1360/0x4710 [cfg80211] genl_family_rcv_msg_doit+0xb4/0x110 genl_rcv_msg+0xd0/0x1bc netlink_rcv_skb+0x58/0x120 genl_rcv+0x34/0x50 netlink_unicast+0x1f0/0x2ec netlink_sendmsg+0x198/0x3d0 ____sys_sendmsg+0x1b0/0x210 ___sys_sendmsg+0x80/0xf0 __sys_sendmsg+0x44/0xa0 __arm64_sys_sendmsg+0x20/0x30 invoke_syscall.constprop.0+0x4c/0xe0 do_el0_svc+0x40/0xd0 el0_svc+0x14/0x4c el0t_64_sync_handler+0x100/0x110 el0t_64_sync+0x15c/0x160 Code: d2800002 910092c0 52800023 f9800011 (885f7c01) ---[ end trace 7e42dd9a39ed2281 ]--- Fix by using mt76_dev_phy() which will map band_idx to the correct phy for all hardware combinations.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49857", "url": "https://ubuntu.com/security/CVE-2024-49857", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: set the cipher for secured NDP ranging The cipher pointer is not set, but is derefereced trying to set its content, which leads to a NULL pointer dereference. Fix it by pointing to the cipher parameter before dereferencing.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47738", "url": "https://ubuntu.com/security/CVE-2024-47738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: don't use rate mask for offchannel TX either Like the commit ab9177d83c04 (\"wifi: mac80211: don't use rate mask for scanning\"), ignore incorrect settings to avoid no supported rate warning reported by syzbot. The syzbot did bisect and found cause is commit 9df66d5b9f45 (\"cfg80211: fix default HE tx bitrate mask in 2G band\"), which however corrects bitmask of HE MCS and recognizes correctly settings of empty legacy rate plus HE MCS rate instead of returning -EINVAL. As suggestions [1], follow the change of SCAN TX to consider this case of offchannel TX as well. [1] https://lore.kernel.org/linux-wireless/6ab2dc9c3afe753ca6fdcdd1421e7a1f47e87b84.camel@sipsolutions.net/T/#m2ac2a6d2be06a37c9c47a3d8a44b4f647ed4f024", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47731", "url": "https://ubuntu.com/security/CVE-2024-47731", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers/perf: Fix ali_drw_pmu driver interrupt status clearing The alibaba_uncore_pmu driver forgot to clear all interrupt status in the interrupt processing function. After the PMU counter overflow interrupt occurred, an interrupt storm occurred, causing the system to hang. Therefore, clear the correct interrupt status in the interrupt handling function to fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49862", "url": "https://ubuntu.com/security/CVE-2024-49862", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powercap: intel_rapl: Fix off by one in get_rpi() The rp->priv->rpi array is either rpi_msr or rpi_tpmi which have NR_RAPL_PRIMITIVES number of elements. Thus the > needs to be >= to prevent an off by one access.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47716", "url": "https://ubuntu.com/security/CVE-2024-47716", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: 9410/1: vfp: Use asm volatile in fmrx/fmxr macros Floating point instructions in userspace can crash some arm kernels built with clang/LLD 17.0.6: BUG: unsupported FP instruction in kernel mode FPEXC == 0xc0000780 Internal error: Oops - undefined instruction: 0 [#1] ARM CPU: 0 PID: 196 Comm: vfp-reproducer Not tainted 6.10.0 #1 Hardware name: BCM2835 PC is at vfp_support_entry+0xc8/0x2cc LR is at do_undefinstr+0xa8/0x250 pc : [] lr : [] psr: a0000013 sp : dc8d1f68 ip : 60000013 fp : bedea19c r10: ec532b17 r9 : 00000010 r8 : 0044766c r7 : c0000780 r6 : ec532b17 r5 : c1c13800 r4 : dc8d1fb0 r3 : c10072c4 r2 : c0101c88 r1 : ec532b17 r0 : 0044766c Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 00c5387d Table: 0251c008 DAC: 00000051 Register r0 information: non-paged memory Register r1 information: vmalloc memory Register r2 information: non-slab/vmalloc memory Register r3 information: non-slab/vmalloc memory Register r4 information: 2-page vmalloc region Register r5 information: slab kmalloc-cg-2k Register r6 information: vmalloc memory Register r7 information: non-slab/vmalloc memory Register r8 information: non-paged memory Register r9 information: zero-size pointer Register r10 information: vmalloc memory Register r11 information: non-paged memory Register r12 information: non-paged memory Process vfp-reproducer (pid: 196, stack limit = 0x61aaaf8b) Stack: (0xdc8d1f68 to 0xdc8d2000) 1f60: 0000081f b6f69300 0000000f c10073f4 c10072c4 dc8d1fb0 1f80: ec532b17 0c532b17 0044766c b6f9ccd8 00000000 c010a80c 00447670 60000010 1fa0: ffffffff c1c13800 00c5387d c0100f10 b6f68af8 00448fc0 00000000 bedea188 1fc0: bedea314 00000001 00448ebc b6f9d000 00447608 b6f9ccd8 00000000 bedea19c 1fe0: bede9198 bedea188 b6e1061c 0044766c 60000010 ffffffff 00000000 00000000 Call trace: [] (vfp_support_entry) from [] (do_undefinstr+0xa8/0x250) [] (do_undefinstr) from [] (__und_usr+0x70/0x80) Exception stack(0xdc8d1fb0 to 0xdc8d1ff8) 1fa0: b6f68af8 00448fc0 00000000 bedea188 1fc0: bedea314 00000001 00448ebc b6f9d000 00447608 b6f9ccd8 00000000 bedea19c 1fe0: bede9198 bedea188 b6e1061c 0044766c 60000010 ffffffff Code: 0a000061 e3877202 e594003c e3a09010 (eef16a10) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Fatal exception in interrupt ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]--- This is a minimal userspace reproducer on a Raspberry Pi Zero W: #include #include int main(void) { double v = 1.0; printf(\"%fn\", NAN + *(volatile double *)&v); return 0; } Another way to consistently trigger the oops is: calvin@raspberry-pi-zero-w ~$ python -c \"import json\" The bug reproduces only when the kernel is built with DYNAMIC_DEBUG=n, because the pr_debug() calls act as barriers even when not activated. This is the output from the same kernel source built with the same compiler and DYNAMIC_DEBUG=y, where the userspace reproducer works as expected: VFP: bounce: trigger ec532b17 fpexc c0000780 VFP: emulate: INST=0xee377b06 SCR=0x00000000 VFP: bounce: trigger eef1fa10 fpexc c0000780 VFP: emulate: INST=0xeeb40b40 SCR=0x00000000 VFP: raising exceptions 30000000 calvin@raspberry-pi-zero-w ~$ ./vfp-reproducer nan Crudely grepping for vmsr/vmrs instructions in the otherwise nearly idential text for vfp_support_entry() makes the problem obvious: vmlinux.llvm.good [0xc0101cb8] <+48>: vmrs r7, fpexc vmlinux.llvm.good [0xc0101cd8] <+80>: vmsr fpexc, r0 vmlinux.llvm.good [0xc0101d20 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47717", "url": "https://ubuntu.com/security/CVE-2024-47717", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RISC-V: KVM: Don't zero-out PMU snapshot area before freeing data With the latest Linux-6.11-rc3, the below NULL pointer crash is observed when SBI PMU snapshot is enabled for the guest and the guest is forcefully powered-off. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000508 Oops [#1] Modules linked in: kvm CPU: 0 UID: 0 PID: 61 Comm: term-poll Not tainted 6.11.0-rc3-00018-g44d7178dd77a #3 Hardware name: riscv-virtio,qemu (DT) epc : __kvm_write_guest_page+0x94/0xa6 [kvm] ra : __kvm_write_guest_page+0x54/0xa6 [kvm] epc : ffffffff01590e98 ra : ffffffff01590e58 sp : ffff8f80001f39b0 gp : ffffffff81512a60 tp : ffffaf80024872c0 t0 : ffffaf800247e000 t1 : 00000000000007e0 t2 : 0000000000000000 s0 : ffff8f80001f39f0 s1 : 00007fff89ac4000 a0 : ffffffff015dd7e8 a1 : 0000000000000086 a2 : 0000000000000000 a3 : ffffaf8000000000 a4 : ffffaf80024882c0 a5 : 0000000000000000 a6 : ffffaf800328d780 a7 : 00000000000001cc s2 : ffffaf800197bd00 s3 : 00000000000828c4 s4 : ffffaf800248c000 s5 : ffffaf800247d000 s6 : 0000000000001000 s7 : 0000000000001000 s8 : 0000000000000000 s9 : 00007fff861fd500 s10: 0000000000000001 s11: 0000000000800000 t3 : 00000000000004d3 t4 : 00000000000004d3 t5 : ffffffff814126e0 t6 : ffffffff81412700 status: 0000000200000120 badaddr: 0000000000000508 cause: 000000000000000d [] __kvm_write_guest_page+0x94/0xa6 [kvm] [] kvm_vcpu_write_guest+0x56/0x90 [kvm] [] kvm_pmu_clear_snapshot_area+0x42/0x7e [kvm] [] kvm_riscv_vcpu_pmu_deinit.part.0+0xe0/0x14e [kvm] [] kvm_riscv_vcpu_pmu_deinit+0x1a/0x24 [kvm] [] kvm_arch_vcpu_destroy+0x28/0x4c [kvm] [] kvm_destroy_vcpus+0x5a/0xda [kvm] [] kvm_arch_destroy_vm+0x14/0x28 [kvm] [] kvm_destroy_vm+0x168/0x2a0 [kvm] [] kvm_put_kvm+0x3c/0x58 [kvm] [] kvm_vm_release+0x22/0x2e [kvm] Clearly, the kvm_vcpu_write_guest() function is crashing because it is being called from kvm_pmu_clear_snapshot_area() upon guest tear down. To address the above issue, simplify the kvm_pmu_clear_snapshot_area() to not zero-out PMU snapshot area from kvm_pmu_clear_snapshot_area() because the guest is anyway being tore down. The kvm_pmu_clear_snapshot_area() is also called when guest changes PMU snapshot area of a VCPU but even in this case the previous PMU snaphsot area must not be zeroed-out because the guest might have reclaimed the pervious PMU snapshot area for some other purpose.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47721", "url": "https://ubuntu.com/security/CVE-2024-47721", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: remove unused C2H event ID RTW89_MAC_C2H_FUNC_READ_WOW_CAM to prevent out-of-bounds reading The handler of firmware C2H event RTW89_MAC_C2H_FUNC_READ_WOW_CAM isn't implemented, but driver expects number of handlers is NUM_OF_RTW89_MAC_C2H_FUNC_WOW causing out-of-bounds access. Fix it by removing ID. Addresses-Coverity-ID: 1598775 (\"Out-of-bounds read\")", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47732", "url": "https://ubuntu.com/security/CVE-2024-47732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: iaa - Fix potential use after free bug The free_device_compression_mode(iaa_device, device_mode) function frees \"device_mode\" but it iss passed to iaa_compression_modes[i]->free() a few lines later resulting in a use after free. The good news is that, so far as I can tell, nothing implements the ->free() function and the use after free happens in dead code. But, with this fix, when something does implement it, we'll be ready. :)", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47718", "url": "https://ubuntu.com/security/CVE-2024-47718", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: always wait for both firmware loading attempts In 'rtw_wait_firmware_completion()', always wait for both (regular and wowlan) firmware loading attempts. Otherwise if 'rtw_usb_intf_init()' has failed in 'rtw_usb_probe()', 'rtw_usb_disconnect()' may issue 'ieee80211_free_hw()' when one of 'rtw_load_firmware_cb()' (usually the wowlan one) is still in progress, causing UAF detected by KASAN.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47724", "url": "https://ubuntu.com/security/CVE-2024-47724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: use work queue to process beacon tx event Commit 3a415daa3e8b (\"wifi: ath11k: add P2P IE in beacon template\") from Feb 28, 2024 (linux-next), leads to the following Smatch static checker warning: drivers/net/wireless/ath/ath11k/wmi.c:1742 ath11k_wmi_p2p_go_bcn_ie() warn: sleeping in atomic context The reason is that ath11k_bcn_tx_status_event() will directly call might sleep function ath11k_wmi_cmd_send() during RCU read-side critical sections. The call trace is like: ath11k_bcn_tx_status_event() -> rcu_read_lock() -> ath11k_mac_bcn_tx_event() \t-> ath11k_mac_setup_bcn_tmpl() \t…… \t\t-> ath11k_wmi_bcn_tmpl() \t\t\t-> ath11k_wmi_cmd_send() -> rcu_read_unlock() Commit 886433a98425 (\"ath11k: add support for BSS color change\") added the ath11k_mac_bcn_tx_event(), commit 01e782c89108 (\"ath11k: fix warning of RCU usage for ath11k_mac_get_arvif_by_vdev_id()\") added the RCU lock to avoid warning but also introduced this BUG. Use work queue to avoid directly calling ath11k_mac_bcn_tx_event() during RCU critical sections. No need to worry about the deletion of vif because cancel_work_sync() will drop the work if it doesn't start or block vif deletion until the running work is done. 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": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47671", "url": "https://ubuntu.com/security/CVE-2024-47671", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: usbtmc: prevent kernel-usb-infoleak The syzbot reported a kernel-usb-infoleak in usbtmc_write, we need to clear the structure before filling fields.", "cve_priority": "medium", "cve_public_date": "2024-10-09 15:15:00 UTC" }, { "cve": "CVE-2024-46869", "url": "https://ubuntu.com/security/CVE-2024-46869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btintel_pcie: Allocate memory for driver private data Fix driver not allocating memory for struct btintel_data which is used to store internal data.", "cve_priority": "medium", "cve_public_date": "2024-09-30 16:15:00 UTC" }, { "cve": "CVE-2024-53164", "url": "https://ubuntu.com/security/CVE-2024-53164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: fix ordering of qlen adjustment Changes to sch->q.qlen around qdisc_tree_reduce_backlog() need to happen _before_ a call to said function because otherwise it may fail to notify parent qdiscs when the child is about to become empty.", "cve_priority": "medium", "cve_public_date": "2024-12-27 14:15:00 UTC" }, { "cve": "CVE-2024-53103", "url": "https://ubuntu.com/security/CVE-2024-53103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hv_sock: Initializing vsk->trans to NULL to prevent a dangling pointer When hvs is released, there is a possibility that vsk->trans may not be initialized to NULL, which could lead to a dangling pointer. This issue is resolved by initializing vsk->trans to NULL.", "cve_priority": "high", "cve_public_date": "2024-12-02 08:15:00 UTC" } ], "log": [ "", " * oracular/linux: 6.11.0-17.17 -proposed tracker (LP: #2093643)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/2025.01.13)", "", " * When /dev/vmbus/hv_kvp is not present, disable hv-kvp-daemon (LP: #2091744)", " - [Packaging] disable hv-kvp-daemon if needed", "", " * Backport \"netkit: Add option for scrubbing skb meta data\" to 6.8", " (LP: #2091184)", " - netkit: Add option for scrubbing skb meta data", "", " * KVM: Cache CPUID at KVM.ko module init to reduce latency of VM-Enter and VM-", " Exit (LP: #2093146)", " - KVM: x86: Cache CPUID.0xD XSTATE offsets+sizes during module init", "", " * [SRU] add support of QCA BT 0489:e0fc (LP: #2085406)", " - Bluetooth: btusb: add Foxconn 0xe0fc for Qualcomm WCN785x", "", " * oracular: ubuntu_boot lib/dynamic_queue_limits.c:99! (LP: #2089684)", " - virtio_net: correct netdev_tx_reset_queue() invocation point", " - virtio_ring: add a func argument 'recycle_done' to virtqueue_resize()", " - virtio_net: ensure netdev_tx_reset_queue is called on tx ring resize", "", " * Failed to probe for OVTI02C1: chip id mismatch: 560243!=0 (LP: #2090932)", " - SAUCE: ACPI: scan: Update HID for new platform", "", " * Bluetooth[8086:a876] crash with \"hci0: Failed to read MSFT supported", " features (-110)\" (LP: #2085485)", " - Bluetooth: btintel_pcie: Add recovery mechanism", "", " * Poor bluetooth performance on Lenovo X13s (LP: #2089357)", " - SAUCE: Bluetooth: qca: Support downloading board ID specific NVM for WCN6855", "", " * vfio_pci soft lockup on VM start while using PCIe passthrough (LP: #2089306)", " - SAUCE: Revert \"mm: use rwsem assertion macros for mmap_lock\"", " - SAUCE: Revert \"vfio/pci: Insert full vma on mmap'd MMIO fault\"", " - SAUCE: Revert \"vfio/pci: Use unmap_mapping_range()\"", "", " * Oracular update: v6.11.11 upstream stable release (LP: #2091655)", " - wifi: mac80211: Fix setting txpower with emulate_chanctx", " - wifi: cfg80211: Add wiphy_delayed_work_pending()", " - wifi: mac80211: Convert color collision detection to wiphy work", " - wifi: radiotap: Avoid -Wflex-array-member-not-at-end warnings", " - spi: stm32: fix missing device mode capability in stm32mp25", " - ASoC: codecs: rt5640: Always disable IRQs from rt5640_cancel_work()", " - ASoC: Intel: bytcr_rt5640: Add support for non ACPI instantiated codec", " - ASoC: Intel: bytcr_rt5640: Add DMI quirk for Vexia Edu Atla 10 tablet", " - ASoC: Intel: sst: Support LPE0F28 ACPI HID", " - wifi: iwlwifi: mvm: Use the sync timepoint API in suspend", " - wifi: iwlwifi: mvm: SAR table alignment", " - mac80211: fix user-power when emulating chanctx", " - usb: add support for new USB device ID 0x17EF:0x3098 for the r8152 driver", " - usb: typec: use cleanup facility for 'altmodes_node'", " - selftests/watchdog-test: Fix system accidentally reset after watchdog-test", " - ALSA: hda/realtek: Add subwoofer quirk for Infinix ZERO BOOK 13", " - ASoC: codecs: wcd937x: add missing LO Switch control", " - ASoC: codecs: wcd937x: relax the AUX PDM watchdog", " - x86/amd_nb: Fix compile-testing without CONFIG_AMD_NB", " - bpf: fix filed access without lock", " - net: usb: qmi_wwan: add Quectel RG650V", " - soc: qcom: Add check devm_kasprintf() returned value", " - firmware: arm_scmi: Reject clear channel request on A2P", " - regulator: rk808: Add apply_bit for BUCK3 on RK809", " - platform/x86: dell-smbios-base: Extends support to Alienware products", " - platform/x86: dell-wmi-base: Handle META key Lock/Unlock events", " - platform/x86: ideapad-laptop: add missing Ideapad Pro 5 fn keys", " - ASoC: tas2781: Add new driver version for tas2563 & tas2781 qfn chip", " - tools/lib/thermal: Remove the thermal.h soft link when doing make clean", " - can: j1939: fix error in J1939 documentation.", " - platform/x86: thinkpad_acpi: Fix for ThinkPad's with ECFW showing incorrect", " fan speed", " - ASoC: amd: yc: Support dmic on another model of Lenovo Thinkpad E14 Gen 6", " - ASoC: stm: Prevent potential division by zero in stm32_sai_mclk_round_rate()", " - ASoC: stm: Prevent potential division by zero in stm32_sai_get_clk_div()", " - drm: panel-orientation-quirks: Make Lenovo Yoga Tab 3 X90F DMI match less", " strict", " - proc/softirqs: replace seq_printf with seq_put_decimal_ull_width", " - integrity: Use static_assert() to check struct sizes", " - ASoC: audio-graph-card2: Purge absent supplies for device tree nodes", " - LoongArch: For all possible CPUs setup logical-physical CPU mapping", " - LoongArch: Define a default value for VM_DATA_DEFAULT_FLAGS", " - ASoC: max9768: Fix event generation for playback mute", " - ALSA: usb-audio: Fix Yamaha P-125 Quirk Entry", " - ARM: 9420/1: smp: Fix SMP for xip kernels", " - ARM: 9434/1: cfi: Fix compilation corner case", " - ipmr: Fix access to mfc_cache_list without lock held", " - f2fs: fix fiemap failure issue when page size is 16KB", " - drm/amd/display: Skip Invalid Streams from DSC Policy", " - drm/amd/display: Fix incorrect DSC recompute trigger", " - s390/facilities: Fix warning about shadow of global variable", " - efs: fix the efs new mount api implementation", " - arm64: probes: Disable kprobes/uprobes on MOPS instructions", " - kselftest/arm64: hwcap: fix f8dp2 cpuinfo name", " - kselftest/arm64: mte: fix printf type warnings about __u64", " - kselftest/arm64: mte: fix printf type warnings about longs", " - block/fs: Pass an iocb to generic_atomic_write_valid()", " - fs/block: Check for IOCB_DIRECT in generic_atomic_write_valid()", " - s390/cio: Do not unregister the subchannel based on DNV", " - s390/pageattr: Implement missing kernel_page_present()", " - x86/pvh: Set phys_base when calling xen_prepare_pvh()", " - x86/pvh: Call C code via the kernel virtual mapping", " - brd: defer automatic disk creation until module initialization succeeds", " - ext4: avoid remount errors with 'abort' mount option", " - mips: asm: fix warning when disabling MIPS_FP_SUPPORT", " - arm64: Expose ID_AA64ISAR1_EL1.XS to sanitised feature consumers", " - kselftest/arm64: Fix encoding for SVE B16B16 test", " - nvme-pci: fix freeing of the HMB descriptor table", " - m68k: mvme147: Fix SCSI controller IRQ numbers", " - m68k: mvme147: Reinstate early console", " - arm64: fix .data.rel.ro size assertion when CONFIG_LTO_CLANG", " - acpi/arm64: Adjust error handling procedure in gtdt_parse_timer_block()", " - loop: fix type of block size", " - cachefiles: Fix incorrect length return value in", " cachefiles_ondemand_fd_write_iter()", " - cachefiles: Fix missing pos updates in cachefiles_ondemand_fd_write_iter()", " - cachefiles: Fix NULL pointer dereference in object->file", " - netfs/fscache: Add a memory barrier for FSCACHE_VOLUME_CREATING", " - block: constify the lim argument to queue_limits_max_zone_append_sectors", " - block: properly handle REQ_OP_ZONE_APPEND in __bio_split_to_limits", " - block: take chunk_sectors into account in bio_split_write_zeroes", " - block: fix bio_split_rw_at to take zone_write_granularity into account", " - s390/syscalls: Avoid creation of arch/arch/ directory", " - hfsplus: don't query the device logical block size multiple times", " - ext4: pipeline buffer reads in mext_page_mkuptodate()", " - ext4: remove array of buffer_heads from mext_page_mkuptodate()", " - ext4: fix race in buffer_head read fault injection", " - nvme-pci: reverse request order in nvme_queue_rqs", " - virtio_blk: reverse request order in virtio_queue_rqs", " - crypto: mxs-dcp - Fix AES-CBC with hardware-bound keys", " - crypto: caam - Fix the pointer passed to caam_qi_shutdown()", " - crypto: qat - remove check after debugfs_create_dir()", " - crypto: qat/qat_420xx - fix off by one in uof_get_name()", " - crypto: qat/qat_4xxx - fix off by one in uof_get_name()", " - firmware: google: Unregister driver_info on failure", " - EDAC/bluefield: Fix potential integer overflow", " - crypto: qat - remove faulty arbiter config reset", " - thermal: core: Initialize thermal zones before registering them", " - thermal: core: Drop thermal_zone_device_is_enabled()", " - thermal: core: Rearrange PM notification code", " - thermal: core: Represent suspend-related thermal zone flags as bits", " - thermal: core: Mark thermal zones as initializing to start with", " - thermal: core: Fix race between zone registration and system suspend", " - EDAC/fsl_ddr: Fix bad bit shift operations", " - EDAC/skx_common: Differentiate memory error sources", " - EDAC/{skx_common,i10nm}: Fix incorrect far-memory error source indicator", " - crypto: pcrypt - Call crypto layer directly when padata_do_parallel() return", " -EBUSY", " - crypto: cavium - Fix the if condition to exit loop after timeout", " - cpufreq/amd-pstate: Don't update CPPC request in", " amd_pstate_cpu_boost_update()", " - amd-pstate: Set min_perf to nominal_perf for active mode performance gov", " - crypto: hisilicon/qm - disable same error report before resetting", " - EDAC/igen6: Avoid segmentation fault on module unload", " - crypto: qat - Fix missing destroy_workqueue in adf_init_aer()", " - crypto: inside-secure - Fix the return value of safexcel_xcbcmac_cra_init()", " - sched/cpufreq: Ensure sd is rebuilt for EAS check", " - doc: rcu: update printed dynticks counter bits", " - rcu/srcutiny: don't return before reenabling preemption", " - rcu/kvfree: Fix data-race in __mod_timer / kvfree_call_rcu", " - hwmon: (pmbus/core) clear faults after setting smbalert mask", " - hwmon: (nct6775-core) Fix overflows seen when writing limit attributes", " - ACPI: CPPC: Fix _CPC register setting issue", " - crypto: caam - add error check to caam_rsa_set_priv_key_form", " - crypto: bcm - add error check in the ahash_hmac_init function", " - crypto: cavium - Fix an error handling path in cpt_ucode_load_fw()", " - rcuscale: Do a proper cleanup if kfree_scale_init() fails", " - tools/lib/thermal: Make more generic the command encoding function", " - thermal/lib: Fix memory leak on error in thermal_genl_auto()", " - x86/unwind/orc: Fix unwind for newly forked tasks", " - Revert \"scripts/faddr2line: Check only two symbols when calculating symbol", " size\"", " - cleanup: Remove address space of returned pointer", " - time: Partially revert cleanup on msecs_to_jiffies() documentation", " - time: Fix references to _msecs_to_jiffies() handling of values", " - locking/atomic/x86: Use ALT_OUTPUT_SP() for __alternative_atomic64()", " - locking/atomic/x86: Use ALT_OUTPUT_SP() for __arch_{,try_}cmpxchg64_emu()", " - kcsan, seqlock: Support seqcount_latch_t", " - kcsan, seqlock: Fix incorrect assumption in read_seqbegin()", " - clocksource/drivers:sp804: Make user selectable", " - clocksource/drivers/timer-ti-dm: Fix child node refcount handling", " - regulator: qcom-smd: make smd_vreg_rpm static", " - spi: spi-fsl-lpspi: Use IRQF_NO_AUTOEN flag in request_irq()", " - arm64: dts: qcom: qcs6390-rb3gen2: use modem.mbn for modem DSP", " - ARM: dts: renesas: genmai: Fix partition size for QSPI NOR Flash", " - drivers: soc: xilinx: add the missing kfree in xlnx_add_cb_for_suspend()", " - microblaze: Export xmb_manager functions", " - arm64: dts: mediatek: mt8188: Fix wrong clock provider in MFG1 power domain", " - arm64: dts: mediatek: mt8395-genio-1200-evk: Fix dtbs_check error for phy", " - arm64: dts: mt8195: Fix dtbs_check error for mutex node", " - arm64: dts: mt8195: Fix dtbs_check error for infracfg_ao node", " - soc: ti: smartreflex: Use IRQF_NO_AUTOEN flag in request_irq()", " - soc: qcom: geni-se: fix array underflow in geni_se_clk_tbl_get()", " - arm64: dts: qcom: sm6350: Fix GPU frequencies missing on some speedbins", " - arm64: dts: qcom: sda660-ifc6560: fix l10a voltage ranges", " - ARM: dts: microchip: sam9x60: Add missing property atmel,usart-mode", " - mmc: mmc_spi: drop buggy snprintf()", " - scripts/kernel-doc: Do not track section counter across processed files", " - arm64: dts: qcom: x1e80100-slim7x: Drop orientation-switch from USB SS[0-1]", " QMP PHYs", " - arm64: dts: qcom: x1e80100-vivobook-s15: Drop orientation-switch from USB", " SS[0-1] QMP PHYs", " - openrisc: Implement fixmap to fix earlycon", " - efi/libstub: fix efi_parse_options() ignoring the default command line", " - tpm: fix signed/unsigned bug when checking event logs", " - media: i2c: vgxy61: Fix an error handling path in vgxy61_detect()", " - media: i2c: ds90ub960: Fix missing return check on ub960_rxport_read call", " - arm64: dts: mt8183: krane: Fix the address of eeprom at i2c4", " - arm64: dts: mt8183: kukui: Fix the address of eeprom at i2c4", " - arm64: dts: qcom: x1e80100: Resize GIC Redistributor register region", " - kernel-doc: allow object-like macros in ReST output", " - arm64: dts: ti: k3-am62x-phyboard-lyra: Drop unnecessary McASP AFIFOs", " - arm64: dts: mediatek: mt8173-elm-hana: Add vdd-supply to second source", " trackpad", " - arm64: dts: mediatek: mt8188: Fix USB3 PHY port default status", " - arm64: dts: mediatek: mt8195-cherry: Use correct audio codec DAI", " - Revert \"cgroup: Fix memory leak caused by missing cgroup_bpf_offline\"", " - cgroup/bpf: only cgroup v2 can be attached by bpf programs", " - regulator: rk808: Restrict DVS GPIOs to the RK808 variant only", " - power: sequencing: make the QCom PMU pwrseq driver depend on CONFIG_OF", " - [Config] updateconfigs for POWER_SEQUENCING_QCOM_WCN", " - arm64: dts: rockchip: Remove 'enable-active-low' from two boards", " - arm64: dts: mt8183: fennel: add i2c2's i2c-scl-internal-delay-ns", " - arm64: dts: mt8183: burnet: add i2c2's i2c-scl-internal-delay-ns", " - arm64: dts: mt8183: cozmo: add i2c2's i2c-scl-internal-delay-ns", " - arm64: dts: mt8183: Damu: add i2c2's i2c-scl-internal-delay-ns", " - pwm: imx27: Workaround of the pwm output bug when decrease the duty cycle", " - ARM: dts: cubieboard4: Fix DCDC5 regulator constraints", " - arm64: dts: ti: k3-j7200: Fix register map for main domain pmx", " - arm64: dts: ti: k3-j7200: Fix clock ids for MCSPI instances", " - arm64: dts: ti: k3-j721e: Fix clock IDs for MCSPI instances", " - arm64: dts: ti: k3-j721s2: Fix clock IDs for MCSPI instances", " - watchdog: Add HAS_IOPORT dependency for SBC8360 and SBC7240", " - arm64: dts: qcom: x1e80100: Update C4/C5 residency/exit numbers", " - dt-bindings: cache: qcom,llcc: Fix X1E80100 reg entries", " - of/fdt: add dt_phys arg to early_init_dt_scan and early_init_dt_verify", " - pmdomain: ti-sci: Add missing of_node_put() for args.np", " - spi: tegra210-quad: Avoid shift-out-of-bounds", " - spi: zynqmp-gqspi: Undo runtime PM changes at driver exit time​", " - regmap: irq: Set lockdep class for hierarchical IRQ domains", " - arm64: dts: renesas: hihope: Drop #sound-dai-cells", " - arm64: dts: imx8mn-tqma8mqnl-mba8mx-usbot: fix coexistence of output-low and", " output-high in GPIO", " - arm64: dts: mediatek: Add ADC node on MT6357, MT6358, MT6359 PMICs", " - arm64: dts: mediatek: mt6358: fix dtbs_check error", " - arm64: dts: mediatek: mt8183-kukui-jacuzzi: Fix DP bridge supply names", " - arm64: dts: mediatek: mt8183-kukui-jacuzzi: Add supplies for fixed", " regulators", " - selftests/resctrl: Print accurate buffer size as part of MBM results", " - selftests/resctrl: Fix memory overflow due to unhandled wraparound", " - selftests/resctrl: Protect against array overrun during iMC config parsing", " - firmware: arm_scpi: Check the DVFS OPP count returned by the firmware", " - media: ipu6: Fix DMA and physical address debugging messages for 32-bit", " - media: ipu6: not override the dma_ops of device in driver", " - pwm: Assume a disabled PWM to emit a constant inactive output", " - media: atomisp: Add check for rgby_data memory allocation failure", " - arm64: dts: rockchip: correct analog audio name on Indiedroid Nova", " - HID: hyperv: streamline driver probe to avoid devres issues", " - platform/x86: panasonic-laptop: Return errno correctly in show callback", " - drm/imagination: Convert to use time_before macro", " - drm/imagination: Use pvr_vm_context_get()", " - drm/mm: Mark drm_mm_interval_tree*() functions with __maybe_unused", " - drm/vc4: hvs: Don't write gamma luts on 2711", " - drm/vc4: hdmi: Avoid hang with debug registers when suspended", " - drm/vc4: hvs: Fix dlist debug not resetting the next entry pointer", " - drm/vc4: hvs: Remove incorrect limit from hvs_dlist debugfs function", " - drm/vc4: hvs: Correct logic on stopping an HVS channel", " - wifi: ath9k: add range check for conn_rsp_epid in htc_connect_service()", " - drm/omap: Fix possible NULL dereference", " - drm/omap: Fix locking in omap_gem_new_dmabuf()", " - drm/v3d: Appease lockdep while updating GPU stats", " - wifi: p54: Use IRQF_NO_AUTOEN flag in request_irq()", " - wifi: mwifiex: Use IRQF_NO_AUTOEN flag in request_irq()", " - udmabuf: change folios array from kmalloc to kvmalloc", " - udmabuf: fix vmap_udmabuf error page set", " - [Config] updateconfigs for VMAP_PFN", " - drm/imx/dcss: Use IRQF_NO_AUTOEN flag in request_irq()", " - drm/imx/ipuv3: Use IRQF_NO_AUTOEN flag in request_irq()", " - drm/panel: nt35510: Make new commands optional", " - drm/v3d: Address race-condition in MMU flush", " - drm/v3d: Flush the MMU before we supply more memory to the binner", " - drm/amdgpu: Fix JPEG v4.0.3 register write", " - wifi: ath10k: fix invalid VHT parameters in supported_vht_mcs_rate_nss1", " - wifi: ath10k: fix invalid VHT parameters in supported_vht_mcs_rate_nss2", " - wifi: ath12k: Skip Rx TID cleanup for self peer", " - dt-bindings: vendor-prefixes: Add NeoFidelity, Inc", " - ASoC: fsl_micfil: fix regmap_write_bits usage", " - ASoC: dt-bindings: mt6359: Update generic node name and dmic-mode", " - ASoC: fsl-asoc-card: Add missing handling of {hp,mic}-dt-gpios", " - drm/bridge: anx7625: Drop EDID cache on bridge power off", " - drm/bridge: it6505: Drop EDID cache on bridge power off", " - libbpf: Fix expected_attach_type set handling in program load callback", " - libbpf: Fix output .symtab byte-order during linking", " - dlm: fix swapped args sb_flags vs sb_status", " - wifi: rtl8xxxu: Perform update_beacon_work when beaconing is enabled", " - drm/amd/display: fix a memleak issue when driver is removed", " - wifi: ath12k: fix use-after-free in ath12k_dp_cc_cleanup()", " - wifi: ath12k: fix one more memcpy size error", " - bpf: Fix the xdp_adjust_tail sample prog issue", " - selftests/bpf: netns_new() and netns_free() helpers.", " - selftests/bpf: Fix backtrace printing for selftests crashes", " - wifi: ath11k: Fix CE offset address calculation for WCN6750 in SSR", " - selftests/bpf: add missing header include for htons", " - wifi: cfg80211: check radio iface combination for multi radio per wiphy", " - ice: consistently use q_idx in ice_vc_cfg_qs_msg()", " - drm/vc4: hdmi: Increase audio MAI fifo dreq threshold", " - drm/vc4: Introduce generation number enum", " - drm/vc4: Match drm_dev_enter and exit calls in vc4_hvs_lut_load", " - drm/vc4: Match drm_dev_enter and exit calls in vc4_hvs_atomic_flush", " - drm/vc4: Correct generation check in vc4_hvs_lut_load", " - libbpf: fix sym_is_subprog() logic for weak global subprogs", " - accel/ivpu: Prevent recovery invocation during probe and resume", " - ASoC: rt722-sdca: Remove logically deadcode in rt722-sdca.c", " - libbpf: never interpret subprogs in .text as entry programs", " - netdevsim: copy addresses for both in and out paths", " - drm/bridge: tc358767: Fix link properties discovery", " - selftests/bpf: Fix msg_verify_data in test_sockmap", " - selftests/bpf: Fix txmsg_redir of test_txmsg_pull in test_sockmap", " - wifi: wilc1000: Set MAC after operation mode", " - wifi: mwifiex: Fix memcpy() field-spanning write warning in", " mwifiex_config_scan()", " - drm: fsl-dcu: enable PIXCLK on LS1021A", " - drm: panel: nv3052c: correct spi_device_id for RG35XX panel", " - drm/msm/dpu: on SDM845 move DSPP_3 to LM_5 block", " - drm/msm/dpu: drop LM_3 / LM_4 on SDM845", " - drm/msm/dpu: drop LM_3 / LM_4 on MSM8998", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_common.c", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_ethtool.c", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_flows.c", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in cn10k.c", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dmac_flt.c", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dcbnl.c", " - selftests/bpf: fix test_spin_lock_fail.c's global vars usage", " - libbpf: move global data mmap()'ing into bpf_object__load()", " - drm/panfrost: Remove unused id_mask from struct panfrost_model", " - bpf, arm64: Remove garbage frame for struct_ops trampoline", " - drm/msm/adreno: Use IRQF_NO_AUTOEN flag in request_irq()", " - drm/msm/gpu: Check the status of registration to PM QoS", " - drm/xe/hdcp: Fix gsc structure check in fw check status", " - drm/etnaviv: Request pages from DMA32 zone on addressing_limited", " - drm/etnaviv: hold GPU lock across perfmon sampling", " - drm/amd/display: Increase idle worker HPD detection time", " - drm/amd/display: Reduce HPD Detection Interval for IPS", " - drm/nouveau/gr/gf100: Fix missing unlock in gf100_gr_chan_new()", " - drm: zynqmp_kms: Unplug DRM device before removal", " - drm: xlnx: zynqmp_disp: layer may be null while releasing", " - wifi: wfx: Fix error handling in wfx_core_init()", " - wifi: cw1200: Fix potential NULL dereference", " - drm/msm/dpu: cast crtc_clk calculation to u64 in _dpu_core_perf_calc_clk()", " - bpf, bpftool: Fix incorrect disasm pc", " - bpf: Tighten tail call checks for lingering locks, RCU, preempt_disable", " - drm/vkms: Drop unnecessary call to drm_crtc_cleanup()", " - drm/amdgpu: Fix the memory allocation issue in", " amdgpu_discovery_get_nps_info()", " - bpf: Support __nullable argument suffix for tp_btf", " - selftests/bpf: Add test for __nullable suffix in tp_btf", " - bpf: Mark raw_tp arguments with PTR_MAYBE_NULL", " - drm: use ATOMIC64_INIT() for atomic64_t", " - netfilter: nf_tables: avoid false-positive lockdep splat on rule deletion", " - netfilter: nf_tables: must hold rcu read lock while iterating expression", " type list", " - netfilter: nf_tables: must hold rcu read lock while iterating object type", " list", " - netlink: typographical error in nlmsg_type constants definition", " - wifi: rtw89: coex: check NULL return of kmalloc in btc_fw_set_monreg()", " - drm/panfrost: Add missing OPP table refcnt decremental", " - drm/panthor: introduce job cycle and timestamp accounting", " - drm/panthor: record current and maximum device clock frequencies", " - drm/panthor: Fix OPP refcnt leaks in devfreq initialisation", " - isofs: avoid memory leak in iocharset", " - selftests/bpf: Add txmsg_pass to pull/push/pop in test_sockmap", " - selftests/bpf: Fix SENDPAGE data logic in test_sockmap", " - selftests/bpf: Fix total_bytes in msg_loop_rx in test_sockmap", " - selftests/bpf: Add push/pop checking for msg_verify_data in test_sockmap", " - bpf, sockmap: Several fixes to bpf_msg_push_data", " - bpf, sockmap: Several fixes to bpf_msg_pop_data", " - bpf, sockmap: Fix sk_msg_reset_curr", " - ipv6: release nexthop on device removal", " - selftests: net: really check for bg process completion", " - wifi: cfg80211: Remove the Medium Synchronization Delay validity check", " - wifi: iwlwifi: allow fast resume on ax200", " - wifi: iwlwifi: mvm: tell iwlmei when we finished suspending", " - drm/amdgpu: fix ACA bank count boundary check error", " - drm/amdgpu: Fix map/unmap queue logic", " - drm/amdkfd: Fix wrong usage of INIT_WORK()", " - bpf: Allow return values 0 and 1 for kprobe session", " - bpf: Force uprobe bpf program to always return 0", " - selftests/bpf: skip the timer_lockup test for single-CPU nodes", " - ipv6: Fix soft lockups in fib6_select_path under high next hop churn", " - net: rfkill: gpio: Add check for clk_enable()", " - Revert \"wifi: iwlegacy: do not skip frames with bad FCS\"", " - bpf: Use function pointers count as struct_ops links count", " - bpf: Add kernel symbol for struct_ops trampoline", " - ALSA: usx2y: Use snd_card_free_when_closed() at disconnection", " - ALSA: us122l: Use snd_card_free_when_closed() at disconnection", " - ALSA: caiaq: Use snd_card_free_when_closed() at disconnection", " - ALSA: 6fire: Release resources at card release", " - i2c: dev: Fix memory leak when underlying adapter does not support I2C", " - selftests: netfilter: Fix missing return values in conntrack_dump_flush", " - Bluetooth: btintel_pcie: Add handshake between driver and firmware", " - Bluetooth: btintel: Do no pass vendor events to stack", " - Bluetooth: btmtk: adjust the position to init iso data anchor", " - Bluetooth: btbcm: fix missing of_node_put() in btbcm_get_board_name()", " - Bluetooth: ISO: Use kref to track lifetime of iso_conn", " - Bluetooth: ISO: Do not emit LE PA Create Sync if previous is pending", " - Bluetooth: ISO: Do not emit LE BIG Create Sync if previous is pending", " - Bluetooth: ISO: Send BIG Create Sync via hci_sync", " - Bluetooth: fix use-after-free in device_for_each_child()", " - xsk: Free skb when TX metadata options are invalid", " - erofs: handle NONHEAD !delta[1] lclusters gracefully", " - dlm: fix dlm_recover_members refcount on error", " - eth: fbnic: don't disable the PCI device twice", " - net: txgbe: remove GPIO interrupt controller", " - net: txgbe: fix null pointer to pcs", " - netpoll: Use rcu_access_pointer() in netpoll_poll_lock", " - wireguard: selftests: load nf_conntrack if not present", " - bpf: fix recursive lock when verdict program return SK_PASS", " - unicode: Fix utf8_load() error path", " - cppc_cpufreq: Use desired perf if feedback ctrs are 0 or unchanged", " - RDMA/core: Provide rdma_user_mmap_disassociate() to disassociate mmap pages", " - RDMA/hns: Disassociate mmap pages for all uctx when HW is being reset", " - clk: mediatek: drop two dead config options", " - [Config] drop COMMON_CLK_MT8195_{AUDSYS,MSDC}", " - trace/trace_event_perf: remove duplicate samples on the first tracepoint", " event", " - pinctrl: zynqmp: drop excess struct member description", " - pinctrl: renesas: Select PINCTRL_RZG2L for RZ/V2H(P) SoC", " - clk: qcom: videocc-sm8550: depend on either gcc-sm8550 or gcc-sm8650", " - iommu/s390: Implement blocking domain", " - scsi: hisi_sas: Enable all PHYs that are not disabled by user during", " controller reset", " - powerpc/vdso: Flag VDSO64 entry points as functions", " - mfd: tps65010: Use IRQF_NO_AUTOEN flag in request_irq() to fix race", " - mfd: da9052-spi: Change read-mask to write-mask", " - mfd: intel_soc_pmic_bxtwc: Use IRQ domain for USB Type-C device", " - mfd: intel_soc_pmic_bxtwc: Use IRQ domain for TMU device", " - mfd: intel_soc_pmic_bxtwc: Use IRQ domain for PMIC devices", " - irqdomain: Simplify simple and legacy domain creation", " - irqdomain: Cleanup domain name allocation", " - irqdomain: Allow giving name suffix for domain", " - regmap: Allow setting IRQ domain name suffix", " - mfd: intel_soc_pmic_bxtwc: Fix IRQ domain names duplication", " - cpufreq: loongson2: Unregister platform_driver on failure", " - powerpc/fadump: Refactor and prepare fadump_cma_init for late init", " - powerpc/fadump: Move fadump_cma_init to setup_arch() after initmem_init()", " - mtd: hyperbus: rpc-if: Add missing MODULE_DEVICE_TABLE", " - mtd: rawnand: atmel: Fix possible memory leak", " - powerpc/mm/fault: Fix kfence page fault reporting", " - clk: sophgo: avoid integer overflow in sg2042_pll_recalc_rate()", " - mtd: spi-nor: spansion: Use nor->addr_nbytes in octal DTR mode in", " RD_ANY_REG_OP", " - powerpc/pseries: Fix dtl_access_lock to be a rw_semaphore", " - cpufreq: CPPC: Fix possible null-ptr-deref for cpufreq_cpu_get_raw()", " - cpufreq: CPPC: Fix possible null-ptr-deref for cppc_get_cpu_cost()", " - iommu/amd: Remove amd_iommu_domain_update() from page table freeing", " - iommu/amd: Remove the amd_iommu_domain_set_pt_root() and related", " - iommu/amd: Rename struct amd_io_pgtable iopt to pgtbl", " - iommu/amd: Store the nid in io_pgtable_cfg instead of the domain", " - iommu/amd: Narrow the use of struct protection_domain to invalidation", " - iommu/amd/pgtbl_v2: Take protection domain lock before invalidating TLB", " - RDMA/hns: Fix an AEQE overflow error caused by untimely update of eq_db_ci", " - RDMA/hns: Fix flush cqe error when racing with destroy qp", " - RDMA/hns: Modify debugfs name", " - RDMA/hns: Use dev_* printings in hem code instead of ibdev_*", " - RDMA/hns: Fix cpu stuck caused by printings during reset", " - RDMA/rxe: Fix the qp flush warnings in req", " - RDMA/bnxt_re: Check cqe flags to know imm_data vs inv_irkey", " - clk: sunxi-ng: d1: Fix PLL_AUDIO0 preset", " - clk: renesas: rzg2l: Fix FOUTPOSTDIV clk", " - RDMA/rxe: Set queue pair cur_qp_state when being queried", " - RISC-V: KVM: Fix APLIC in_clrip and clripnum write emulation", " - riscv: kvm: Fix out-of-bounds array access", " - clk: imx: lpcg-scu: SW workaround for errata (e10858)", " - clk: imx: fracn-gppll: correct PLL initialization flow", " - clk: imx: fracn-gppll: fix pll power up", " - clk: imx: clk-scu: fix clk enable state save and restore", " - clk: imx: imx8-acm: Fix return value check in", " clk_imx_acm_attach_pm_domains()", " - iommu/vt-d: Fix checks and print in dmar_fault_dump_ptes()", " - iommu/vt-d: Fix checks and print in pgtable_walk()", " - checkpatch: always parse orig_commit in fixes tag", " - mfd: rt5033: Fix missing regmap_del_irq_chip()", " - leds: max5970: Fix unreleased fwnode_handle in probe function", " - leds: ktd2692: Set missing timing properties", " - fs/proc/kcore.c: fix coccinelle reported ERROR instances", " - scsi: target: Fix incorrect function name in pscsi_create_type_disk()", " - scsi: bfa: Fix use-after-free in bfad_im_module_exit()", " - scsi: fusion: Remove unused variable 'rc'", " - scsi: qedf: Fix a possible memory leak in qedf_alloc_and_init_sb()", " - scsi: qedi: Fix a possible memory leak in qedi_alloc_and_init_sb()", " - scsi: sg: Enable runtime power management", " - x86/tdx: Introduce wrappers to read and write TD metadata", " - x86/tdx: Rename tdx_parse_tdinfo() to tdx_setup()", " - x86/tdx: Dynamically disable SEPT violations from causing #VEs", " - powerpc/fadump: allocate memory for additional parameters early", " - fadump: reserve param area if below boot_mem_top", " - RDMA/hns: Fix out-of-order issue of requester when setting FENCE", " - RDMA/hns: Fix NULL pointer derefernce in hns_roce_map_mr_sg()", " - cpufreq: loongson3: Check for error code from devm_mutex_init() call", " - cpufreq: CPPC: Fix wrong return value in cppc_get_cpu_cost()", " - cpufreq: CPPC: Fix wrong return value in cppc_get_cpu_power()", " - kasan: move checks to do_strncpy_from_user", " - kunit: skb: use \"gfp\" variable instead of hardcoding GFP_KERNEL", " - ocfs2: fix uninitialized value in ocfs2_file_read_iter()", " - dax: delete a stale directory pmem", " - KVM: PPC: Book3S HV: Stop using vc->dpdes for nested KVM guests", " - KVM: PPC: Book3S HV: Avoid returning to nested hypervisor on pending", " doorbells", " - powerpc/sstep: make emulate_vsx_load and emulate_vsx_store static", " - RDMA/hns: Fix different dgids mapping to the same dip_idx", " - KVM: PPC: Book3S HV: Fix kmv -> kvm typo", " - powerpc/kexec: Fix return of uninitialized variable", " - fbdev: sh7760fb: Fix a possible memory leak in sh7760fb_alloc_mem()", " - RDMA/mlx5: Move events notifier registration to be after device registration", " - clk: clk-apple-nco: Add NULL check in applnco_probe", " - clk: ralink: mtmips: fix clock plan for Ralink SoC RT3883", " - clk: ralink: mtmips: fix clocks probe order in oldest ralink SoCs", " - clk: en7523: remove REG_PCIE*_{MEM,MEM_MASK} configuration", " - clk: en7523: move clock_register in hw_init callback", " - clk: en7523: introduce chip_scu regmap", " - clk: en7523: fix estimation of fixed rate for EN7581", " - dt-bindings: clock: axi-clkgen: include AXI clk", " - clk: clk-axi-clkgen: make sure to enable the AXI bus clock", " - arm64: dts: qcom: sc8180x: Add a SoC-specific compatible to cpufreq-hw", " - pinctrl: k210: Undef K210_PC_DEFAULT", " - rtla/timerlat: Do not set params->user_workload with -U", " - smb: cached directories can be more than root file handle", " - mailbox: mtk-cmdq: fix wrong use of sizeof in cmdq_get_clocks()", " - mailbox: arm_mhuv2: clean up loop in get_irq_chan_comb()", " - x86: fix off-by-one in access_ok()", " - perf cs-etm: Don't flush when packet_queue fills up", " - gfs2: Rename GLF_VERIFY_EVICT to GLF_VERIFY_DELETE", " - gfs2: Allow immediate GLF_VERIFY_DELETE work", " - gfs2: Fix unlinked inode cleanup", " - perf test: Add test for Intel TPEBS counting mode", " - perf mem: Fix printing PERF_MEM_LVLNUM_{L2_MHB|MSC}", " - PCI: Fix reset_method_store() memory leak", " - perf stat: Close cork_fd when create_perf_stat_counter() failed", " - perf stat: Fix affinity memory leaks on error path", " - perf trace: Keep exited threads for summary", " - perf test attr: Add back missing topdown events", " - f2fs: compress: fix inconsistent update of i_blocks in", " release_compress_blocks and reserve_compress_blocks", " - f2fs: fix null-ptr-deref in f2fs_submit_page_bio()", " - f2fs: fix to account dirty data in __get_secs_required()", " - perf dso: Fix symtab_type for kmod compression", " - perf probe: Fix libdw memory leak", " - perf probe: Correct demangled symbols in C++ program", " - rust: kernel: fix THIS_MODULE header path in ThisModule doc comment", " - rust: macros: fix documentation of the paste! macro", " - PCI: cpqphp: Use PCI_POSSIBLE_ERROR() to check config reads", " - PCI: cpqphp: Fix PCIBIOS_* return value confusion", " - rust: block: fix formatting of `kernel::block::mq::request` module", " - perf disasm: Use disasm_line__free() to properly free disasm_line", " - virtiofs: use pages instead of pointer for kernel direct IO", " - perf ftrace latency: Fix unit on histogram first entry when using --use-nsec", " - i3c: master: Remove i3c_dev_disable_ibi_locked(olddev) on device hotjoin", " - f2fs: fix the wrong f2fs_bug_on condition in f2fs_do_replace_block", " - f2fs: check curseg->inited before write_sum_page in change_curseg", " - f2fs: Fix not used variable 'index'", " - f2fs: fix to avoid potential deadlock in f2fs_record_stop_reason()", " - f2fs: fix to avoid use GC_AT when setting gc_mode as GC_URGENT_LOW or", " GC_URGENT_MID", " - PCI: qcom-ep: Move controller cleanups to qcom_pcie_perst_deassert()", " - PCI: tegra194: Move controller cleanups to pex_ep_event_pex_rst_deassert()", " - PCI: cadence: Extract link setup sequence from cdns_pcie_host_setup()", " - PCI: cadence: Set cdns_pcie_host_init() global", " - PCI: j721e: Add reset GPIO to struct j721e_pcie", " - PCI: j721e: Use T_PERST_CLK_US macro", " - PCI: j721e: Add suspend and resume support", " - PCI: j721e: Deassert PERST# after a delay of PCIE_T_PVPERL_MS milliseconds", " - perf build: Add missing cflags when building with custom libtraceevent", " - f2fs: fix race in concurrent f2fs_stop_gc_thread", " - f2fs: fix to map blocks correctly for direct write", " - f2fs: fix to avoid forcing direct write to use buffered IO on inline_data", " inode", " - perf trace: avoid garbage when not printing a trace event's arguments", " - m68k: mcfgpio: Fix incorrect register offset for CONFIG_M5441x", " - m68k: coldfire/device.c: only build FEC when HW macros are defined", " - svcrdma: Address an integer overflow", " - nfsd: drop inode parameter from nfsd4_change_attribute()", " - perf list: Fix topic and pmu_name argument order", " - perf trace: Fix tracing itself, creating feedback loops", " - perf trace: Do not lose last events in a race", " - perf trace: Avoid garbage when not printing a syscall's arguments", " - remoteproc: qcom: pas: Remove subdevs on the error path of adsp_probe()", " - remoteproc: qcom: adsp: Remove subdevs on the error path of adsp_probe()", " - remoteproc: qcom: pas: add minidump_id to SM8350 resources", " - rpmsg: glink: use only lower 16-bits of param2 for CMD_OPEN name length", " - remoteproc: qcom_q6v5_mss: Re-order writes to the IMEM region", " - PCI: endpoint: epf-mhi: Avoid NULL dereference if DT lacks 'mmio'", " - NFSD: Prevent NULL dereference in nfsd4_process_cb_update()", " - NFSD: Cap the number of bytes copied by nfs4_reset_recoverydir()", " - nfsd: release svc_expkey/svc_export with rcu_work", " - svcrdma: fix miss destroy percpu_counter in svc_rdma_proc_init()", " - NFSD: Fix nfsd4_shutdown_copy()", " - f2fs: clean up val{>>,<<}F2FS_BLKSIZE_BITS", " - f2fs: fix to do cast in F2FS_{BLK_TO_BYTES, BTYES_TO_BLK} to avoid overflow", " - hwmon: (tps23861) Fix reporting of negative temperatures", " - hwmon: (aquacomputer_d5next) Fix length of speed_input array", " - phy: airoha: Fix REG_CSR_2L_PLL_CMN_RESERVE0 config in", " airoha_pcie_phy_init_clk_out()", " - phy: airoha: Fix REG_PCIE_PMA_TX_RESET config in", " airoha_pcie_phy_init_csr_2l()", " - phy: airoha: Fix REG_CSR_2L_JCPLL_SDM_HREN config in", " airoha_pcie_phy_init_ssc_jcpll()", " - phy: airoha: Fix REG_CSR_2L_RX{0,1}_REV0 definitions", " - vdpa/mlx5: Fix suboptimal range on iotlb iteration", " - vfio/mlx5: Fix an unwind issue in mlx5vf_add_migration_pages()", " - vfio/mlx5: Fix unwind flows in mlx5vf_pci_save/resume_device_data()", " - selftests/mount_setattr: Fix failures on 64K PAGE_SIZE kernels", " - gpio: zevio: Add missed label initialisation", " - vfio/pci: Properly hide first-in-list PCIe extended capability", " - fs_parser: update mount_api doc to match function signature", " - LoongArch: Fix build failure with GCC 15 (-std=gnu23)", " - LoongArch: BPF: Sign-extend return values", " - power: supply: core: Remove might_sleep() from power_supply_put()", " - power: supply: bq27xxx: Fix registers of bq27426", " - power: supply: rt9471: Fix wrong WDT function regfield declaration", " - power: supply: rt9471: Use IC status regfield to report real charger status", " - net: usb: lan78xx: Fix double free issue with interrupt buffer allocation", " - net: usb: lan78xx: Fix memory leak on device unplug by freeing PHY device", " - tg3: Set coherent DMA mask bits to 31 for BCM57766 chipsets", " - net: usb: lan78xx: Fix refcounting and autosuspend on invalid WoL", " configuration", " - net: microchip: vcap: Add typegroup table terminators in kunit tests", " - netlink: fix false positive warning in extack during dumps", " - exfat: fix file being changed by unaligned direct write", " - s390/iucv: MSG_PEEK causes memory leak in iucv_sock_destruct()", " - net/ipv6: delete temporary address if mngtmpaddr is removed or unmanaged", " - net: mdio-ipq4019: add missing error check", " - marvell: pxa168_eth: fix call balance of pep->clk handling routines", " - net: stmmac: dwmac-socfpga: Set RX watchdog interrupt as broken", " - octeontx2-af: RPM: Fix mismatch in lmac type", " - octeontx2-af: RPM: Fix low network performance", " - octeontx2-af: RPM: fix stale RSFEC counters", " - octeontx2-af: RPM: fix stale FCFEC counters", " - octeontx2-af: Quiesce traffic before NIX block reset", " - spi: atmel-quadspi: Fix register name in verbose logging function", " - net: hsr: fix hsr_init_sk() vs network/transport headers.", " - bnxt_en: Reserve rings after PCIe AER recovery if NIC interface is down", " - bnxt_en: Set backplane link modes correctly for ethtool", " - bnxt_en: Fix receive ring space parameters when XDP is active", " - bnxt_en: Refactor bnxt_ptp_init()", " - bnxt_en: Unregister PTP during PCI shutdown and suspend", " - Bluetooth: MGMT: Fix slab-use-after-free Read in set_powered_sync", " - Bluetooth: MGMT: Fix possible deadlocks", " - llc: Improve setsockopt() handling of malformed user input", " - rxrpc: Improve setsockopt() handling of malformed user input", " - tcp: Fix use-after-free of nreq in reqsk_timer_handler().", " - ip6mr: fix tables suspicious RCU usage", " - ipmr: fix tables suspicious RCU usage", " - iio: light: al3010: Fix an error handling path in al3010_probe()", " - usb: using mutex lock and supporting O_NONBLOCK flag in iowarrior_read()", " - usb: yurex: make waiting on yurex_write interruptible", " - USB: chaoskey: fail open after removal", " - USB: chaoskey: Fix possible deadlock chaoskey_list_lock", " - misc: apds990x: Fix missing pm_runtime_disable()", " - devres: Fix page faults when tracing devres from unloaded modules", " - usb: gadget: uvc: wake pump everytime we update the free list", " - interconnect: qcom: icc-rpmh: probe defer incase of missing QoS clock", " dependency", " - phy: realtek: usb: fix NULL deref in rtk_usb2phy_probe", " - phy: realtek: usb: fix NULL deref in rtk_usb3phy_probe", " - counter: stm32-timer-cnt: Add check for clk_enable()", " - counter: ti-ecap-capture: Add check for clk_enable()", " - bus: mhi: host: Switch trace_mhi_gen_tre fields to native endian", " - usb: typec: fix potential array underflow in ucsi_ccg_sync_control()", " - firmware_loader: Fix possible resource leak in fw_log_firmware_info()", " - ALSA: hda/realtek: Update ALC256 depop procedure", " - drm/radeon: add helper rdev_to_drm(rdev)", " - drm/radeon: change rdev->ddev to rdev_to_drm(rdev)", " - drm/radeon: Fix spurious unplug event on radeon HDMI", " - drm/amd/display: Fix null check for pipe_ctx->plane_state in", " dcn20_program_pipe", " - drm/amd/display: Fix null check for pipe_ctx->plane_state in hwss_setup_dpp", " - ASoC: imx-audmix: Add NULL check in imx_audmix_probe", " - drm/xe/ufence: Wake up waiters after setting ufence->signalled", " - apparmor: fix 'Do simple duplicate message elimination'", " - ALSA: core: Fix possible NULL dereference caused by kunit_kzalloc()", " - ASoC: amd: yc: Fix for enabling DMIC on acp6x via _DSD entry", " - ASoC: mediatek: Check num_codecs is not zero to avoid panic during probe", " - s390/pci: Fix potential double remove of hotplug slot", " - net_sched: sch_fq: don't follow the fast path if Tx is behind now", " - xen: Fix the issue of resource not being properly released in", " xenbus_dev_probe()", " - ALSA: usb-audio: Fix potential out-of-bound accesses for Extigy and Mbox", " devices", " - ALSA: usb-audio: Fix out of bounds reads when finding clock sources", " - usb: ehci-spear: fix call balance of sehci clk handling routines", " - usb: typec: ucsi: glink: fix off-by-one in connector_status", " - dm-cache: fix warnings about duplicate slab caches", " - dm-bufio: fix warnings about duplicate slab caches", " - ASoC: Intel: sst: Fix used of uninitialized ctx to log an error", " - soc: qcom: socinfo: fix revision check in qcom_socinfo_probe()", " - irqdomain: Always associate interrupts for legacy domains", " - ext4: supress data-race warnings in ext4_free_inodes_{count,set}()", " - ext4: fix FS_IOC_GETFSMAP handling", " - jfs: xattr: check invalid xattr size more strictly", " - ASoC: amd: yc: Add a quirk for microfone on Lenovo ThinkPad P14s Gen 5", " 21MES00B00", " - ASoC: codecs: Fix atomicity violation in snd_soc_component_get_drvdata()", " - ASoC: da7213: Populate max_register to regmap_config", " - perf/x86/intel/pt: Fix buffer full but size is 0 case", " - crypto: x86/aegis128 - access 32-bit arguments as 32-bit", " - KVM: x86: switch hugepage recovery thread to vhost_task", " - KVM: x86/mmu: Skip the \"try unsync\" path iff the old SPTE was a leaf SPTE", " - powerpc/pseries: Fix KVM guest detection for disabling hardlockup detector", " - KVM: arm64: vgic-v3: Sanitise guest writes to GICR_INVLPIR", " - KVM: arm64: Ignore PMCNTENSET_EL0 while checking for overflow status", " - KVM: arm64: Don't retire aborted MMIO instruction", " - KVM: arm64: vgic-its: Clear ITE when DISCARD frees an ITE", " - KVM: arm64: Get rid of userspace_irqchip_in_use", " - KVM: arm64: vgic-its: Add a data length check in vgic_its_save_*", " - KVM: arm64: vgic-its: Clear DTE when MAPD unmaps a device", " - Compiler Attributes: disable __counted_by for clang < 19.1.3", " - PCI: Fix use-after-free of slot->bus on hot remove", " - LoongArch: Explicitly specify code model in Makefile", " - clk: clk-loongson2: Fix memory corruption bug in struct", " loongson2_clk_provider", " - clk: clk-loongson2: Fix potential buffer overflow in flexible-array member", " access", " - fsnotify: fix sending inotify event with unexpected filename", " - comedi: Flush partial mappings in error case", " - apparmor: test: Fix memory leak for aa_unpack_strdup()", " - iio: dac: adi-axi-dac: fix wrong register bitfield", " - tty: ldsic: fix tty_ldisc_autoload sysctl's proc_handler", " - locking/lockdep: Avoid creating new name string literals in", " lockdep_set_subclass()", " - tools/nolibc: s390: include std.h", " - pinctrl: qcom: spmi: fix debugfs drive strength", " - dt-bindings: pinctrl: samsung: Fix interrupt constraint for variants with", " fallbacks", " - dt-bindings: iio: dac: ad3552r: fix maximum spi speed", " - exfat: fix uninit-value in __exfat_get_dentry_set", " - exfat: fix out-of-bounds access of directory entries", " - xhci: Fix control transfer error on Etron xHCI host", " - xhci: Combine two if statements for Etron xHCI host", " - xhci: Don't perform Soft Retry for Etron xHCI host", " - xhci: Don't issue Reset Device command to Etron xHCI host", " - Bluetooth: Fix type of len in rfcomm_sock_getsockopt{,_old}()", " - usb: xhci: Limit Stop Endpoint retries", " - usb: xhci: Fix TD invalidation under pending Set TR Dequeue", " - usb: xhci: Avoid queuing redundant Stop Endpoint commands", " - ARM: dts: omap36xx: declare 1GHz OPP as turbo again", " - wifi: ath12k: fix warning when unbinding", " - wifi: rtlwifi: Drastically reduce the attempts to read efuse in case of", " failures", " - wifi: nl80211: fix bounds checker error in nl80211_parse_sched_scan", " - wifi: ath12k: fix crash when unbinding", " - wifi: brcmfmac: release 'root' node in all execution paths", " - Revert \"fs: don't block i_writecount during exec\"", " - Revert \"f2fs: remove unreachable lazytime mount option parsing\"", " - Revert \"usb: gadget: composite: fix OS descriptors w_value logic\"", " - serial: sh-sci: Clean sci_ports[0] after at earlycon exit", " - Revert \"serial: sh-sci: Clean sci_ports[0] after at earlycon exit\"", " - io_uring: fix corner case forgetting to vunmap", " - io_uring: check for overflows in io_pin_pages", " - blk-settings: round down io_opt to physical_block_size", " - gpio: exar: set value when external pull-up or pull-down is present", " - spi: Fix acpi deferred irq probe", " - mtd: spi-nor: core: replace dummy buswidth from addr to data", " - cpufreq: mediatek-hw: Fix wrong return value in mtk_cpufreq_get_cpu_power()", " - cifs: support mounting with alternate password to allow password rotation", " - parisc/ftrace: Fix function graph tracing disablement", " - RISC-V: Scalar unaligned access emulated on hotplug CPUs", " - RISC-V: Check scalar unaligned access on all CPUs", " - ksmbd: fix use-after-free in SMB request handling", " - smb: client: fix NULL ptr deref in crypto_aead_setkey()", " - platform/chrome: cros_ec_typec: fix missing fwnode reference decrement", " - irqchip/irq-mvebu-sei: Move misplaced select() callback to SEI CP domain", " - x86/CPU/AMD: Terminate the erratum_1386_microcode array", " - ubi: wl: Put source PEB into correct list if trying locking LEB failed", " - um: ubd: Do not use drvdata in release", " - um: net: Do not use drvdata in release", " - dt-bindings: serial: rs485: Fix rs485-rts-delay property", " - serial: 8250_fintek: Add support for F81216E", " - serial: 8250: omap: Move pm_runtime_get_sync", " - serial: amba-pl011: Fix RX stall when DMA is used", " - serial: amba-pl011: fix build regression", " - mtd: ubi: fix unreleased fwnode_handle in find_volume_fwnode()", " - block: Prevent potential deadlock in blk_revalidate_disk_zones()", " - um: vector: Do not use drvdata in release", " - sh: cpuinfo: Fix a warning for CONFIG_CPUMASK_OFFSTACK", " - iio: gts: Fix uninitialized symbol 'ret'", " - ublk: fix ublk_ch_mmap() for 64K page size", " - arm64: tls: Fix context-switching of tpidrro_el0 when kpti is enabled", " - block: fix missing dispatching request when queue is started or unquiesced", " - block: fix ordering between checking QUEUE_FLAG_QUIESCED request adding", " - block: fix ordering between checking BLK_MQ_S_STOPPED request adding", " - blk-mq: Make blk_mq_quiesce_tagset() hold the tag list mutex less long", " - gve: Flow steering trigger reset only for timeout error", " - HID: wacom: Interpret tilt data from Intuos Pro BT as signed values", " - i40e: Fix handling changed priv flags", " - media: wl128x: Fix atomicity violation in fmc_send_cmd()", " - media: intel/ipu6: do not handle interrupts when device is disabled", " - arm64: dts: mediatek: mt8186-corsola-voltorb: Merge speaker codec nodes", " - netdev-genl: Hold rcu_read_lock in napi_get", " - soc: fsl: rcpm: fix missing of_node_put() in copy_ippdexpcr1_setting()", " - media: v4l2-core: v4l2-dv-timings: check cvt/gtf result", " - ALSA: rawmidi: Fix kvfree() call in spinlock", " - ALSA: ump: Fix evaluation of MIDI 1.0 FB info", " - ALSA: pcm: Add sanity NULL check for the default mmap fault handler", " - ALSA: hda/realtek: Update ALC225 depop procedure", " - ALSA: hda/realtek: Set PCBeep to default value for ALC274", " - ALSA: hda/realtek: Fix Internal Speaker and Mic boost of Infinix Y4 Max", " - ALSA: hda/realtek: Apply quirk for Medion E15433", " - smb3: request handle caching when caching directories", " - smb: client: handle max length for SMB symlinks", " - smb: Don't leak cfid when reconnect races with open_cached_dir", " - smb: prevent use-after-free due to open_cached_dir error paths", " - smb: During unmount, ensure all cached dir instances drop their dentry", " - usb: misc: ljca: set small runtime autosuspend delay", " - usb: misc: ljca: move usb_autopm_put_interface() after wait for response", " - usb: dwc3: ep0: Don't clear ep0 DWC3_EP_TRANSFER_STARTED", " - usb: musb: Fix hardware lockup on first Rx endpoint request", " - usb: dwc3: gadget: Fix checking for number of TRBs left", " - usb: dwc3: gadget: Fix looping of queued SG entries", " - staging: vchiq_arm: Fix missing refcount decrement in error path for fw_node", " - counter: stm32-timer-cnt: fix device_node handling in probe_encoder()", " - ublk: fix error code for unsupported command", " - lib: string_helpers: silence snprintf() output truncation warning", " - f2fs: fix to do sanity check on node blkaddr in truncate_node()", " - ipc: fix memleak if msg_init_ns failed in create_ipc_ns", " - Input: cs40l50 - fix wrong usage of INIT_WORK()", " - NFSD: Prevent a potential integer overflow", " - SUNRPC: make sure cache entry active before cache_show", " - um: Fix potential integer overflow during physmem setup", " - um: Fix the return value of elf_core_copy_task_fpregs", " - kfifo: don't include dma-mapping.h in kfifo.h", " - um: ubd: Initialize ubd's disk pointer in ubd_add", " - um: Always dump trace for specified task in show_stack", " - NFSv4.0: Fix a use-after-free problem in the asynchronous open()", " - rtc: st-lpc: Use IRQF_NO_AUTOEN flag in request_irq()", " - rtc: abx80x: Fix WDT bit position of the status register", " - rtc: check if __rtc_read_time was successful in rtc_timer_do_work()", " - ubi: fastmap: wl: Schedule fm_work if wear-leveling pool is empty", " - ubifs: Correct the total block count by deducting journal reservation", " - ubi: fastmap: Fix duplicate slab cache names while attaching", " - ubifs: authentication: Fix use-after-free in ubifs_tnc_end_commit", " - jffs2: fix use of uninitialized variable", " - rtc: rzn1: fix BCD to rtc_time conversion errors", " - Revert \"nfs: don't reuse partially completed requests in", " nfs_lock_and_join_requests\"", " - nvme-multipath: avoid hang on inaccessible namespaces", " - nvme/multipath: Fix RCU list traversal to use SRCU primitive", " - blk-mq: add non_owner variant of start_freeze/unfreeze queue APIs", " - block: model freeze & enter queue as lock for supporting lockdep", " - block: fix uaf for flush rq while iterating tags", " - block: return unsigned int from bdev_io_min", " - nvme-fabrics: fix kernel crash while shutting down controller", " - 9p/xen: fix init sequence", " - 9p/xen: fix release of IRQ", " - perf/arm-smmuv3: Fix lockdep assert in ->event_init()", " - perf/arm-cmn: Ensure port and device id bits are set properly", " - smb: client: disable directory caching when dir_cache_timeout is zero", " - x86/Documentation: Update algo in init_size description of boot protocol", " - cifs: Fix parsing native symlinks relative to the export", " - cifs: Fix parsing reparse point with native symlink in SMB1 non-UNICODE", " session", " - rtc: ab-eoz9: don't fail temperature reads on undervoltage notification", " - Rename .data.unlikely to .data..unlikely", " - Rename .data.once to .data..once to fix resetting WARN*_ONCE", " - kbuild: deb-pkg: Don't fail if modules.order is missing", " - smb: Initialize cfid->tcon before performing network ops", " - block: Don't allow an atomic write be truncated in blkdev_write_iter()", " - modpost: remove incorrect code in do_eisa_entry()", " - cifs: during remount, make sure passwords are in sync", " - cifs: unlock on error in smb3_reconfigure()", " - nfs: ignore SB_RDONLY when mounting nfs", " - sunrpc: clear XPRT_SOCK_UPD_TIMEOUT when reset transport", " - SUNRPC: timeout and cancel TLS handshake with -ETIMEDOUT", " - sunrpc: fix one UAF issue caused by sunrpc kernel tcp socket", " - nfs/blocklayout: Don't attempt unregister for invalid block device", " - nfs/blocklayout: Limit repeat device registration on failure", " - block, bfq: fix bfqq uaf in bfq_limit_depth()", " - brd: decrease the number of allocated pages which discarded", " - sh: intc: Fix use-after-free bug in register_intc_controller()", " - tools/power turbostat: Fix trailing '\\n' parsing", " - tools/power turbostat: Fix child's argument forwarding", " - block: always verify unfreeze lock on the owner task", " - block: don't verify IO lock for freeze/unfreeze in elevator_init_mq()", " - Linux 6.11.11", "", " * Oracular update: v6.11.11 upstream stable release (LP: #2091655) //", " CVE-2024-53141", " - netfilter: ipset: add missing range check in bitmap_ip_uadt", "", " * Oracular update: v6.11.11 upstream stable release (LP: #2091655) //", " CVE-2024-50010", " - Revert \"exec: don't WARN for racy path_noexec check\"", "", " * Oracular update: v6.11.11 upstream stable release (LP: #2091655) //", " CVE-2024-53143", " - fsnotify: Fix ordering of iput() and watched_objects decrement", "", " * Oracular update: v6.11.11 upstream stable release (LP: #2091655) //", " CVE-2024-53142", " - initramfs: avoid filename buffer overrun", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650)", " - net: vertexcom: mse102x: Fix tx_bytes calculation", " - net/mlx5: Fix msix vectors to respect platform limit", " - net/mlx5e: clear xdp features on non-uplink representors", " - net/mlx5e: Disable loopback self-test on multi-PF netdev", " - drm/i915/gsc: ARL-H and ARL-U need a newer GSC FW.", " - drivers: perf: Fix wrong put_cpu() placement", " - Bluetooth: hci_core: Fix calling mgmt_device_connected", " - Bluetooth: btintel: Direct exception event to bluetooth stack", " - net: sched: cls_u32: Fix u32's systematic failure to free IDR entries for", " hnodes.", " - net: phylink: ensure PHY momentary link-fails are handled", " - samples: pktgen: correct dev to DEV", " - net: stmmac: dwmac-mediatek: Fix inverted handling of mediatek,mac-wol", " - net: Make copy_safe_from_sockptr() match documentation", " - stmmac: dwmac-intel-plat: fix call balance of tx_clk handling routines", " - net: ti: icssg-prueth: Fix 1 PPS sync", " - bonding: add ns target multicast address to slave device", " - ARM: 9419/1: mm: Fix kernel memory mapping for xip kernels", " - tools/mm: fix compile error", " - drm/amd/display: Run idle optimizations at end of vblank handler", " - drm/amd/display: Change some variable name of psr", " - drm/amd/display: Fix Panel Replay not update screen correctly", " - x86/mm: Fix a kdump kernel failure on SME system when CONFIG_IMA_KEXEC=y", " - x86/stackprotector: Work around strict Clang TLS symbol requirements", " - crash, powerpc: default to CRASH_DUMP=n on PPC_BOOK3S_32", " - [Config] enable ARCH_DEFAULT_CRASH_DUMP", " - mm: revert \"mm: shmem: fix data-race in shmem_getattr()\"", " - vdpa/mlx5: Fix PA offset with unaligned starting iotlb map", " - evm: stop avoidably reading i_writecount in evm_file_release", " - KVM: selftests: Disable strict aliasing", " - KVM: nVMX: Treat vpid01 as current if L2 is active, but with VPID disabled", " - KVM: x86: Unconditionally set irr_pending when updating APICv state", " - tpm: Disable TPM on tpm2_create_primary() failure", " - ALSA: hda/realtek - Fixed Clevo platform headset Mic issue", " - ALSA: hda/realtek - update set GPIO3 to default for Thinkpad with ALC1318", " - mptcp: update local address flags when setting it", " - mptcp: hold pm lock when deleting entry", " - mptcp: pm: use _rcu variant under rcu_read_lock", " - ocfs2: fix UBSAN warning in ocfs2_verify_volume()", " - LoongArch: Fix early_numa_add_cpu() usage for FDT systems", " - LoongArch: Disable KASAN if PGDIR_SIZE is too large for cpu_vabits", " - LoongArch: Add WriteCombine shadow mapping in KASAN", " - LoongArch: Fix AP booting issue in VM mode", " - LoongArch: Make KASAN work with 5-level page-tables", " - selftests: hugetlb_dio: fixup check for initial conditions to skip in the", " start", " - btrfs: fix incorrect comparison for delayed refs", " - mailbox: qcom-cpucp: Mark the irq with IRQF_NO_SUSPEND flag", " - firmware: arm_scmi: Skip opp duplicates", " - firmware: arm_scmi: Report duplicate opps as firmware bugs", " - mmc: sunxi-mmc: Fix A100 compatible description", " - drm/bridge: tc358768: Fix DSI command tx", " - drm/xe: handle flat ccs during hibernation on igpu", " - pmdomain: arm: Use FLAG_DEV_NAME_FW to ensure unique names", " - pmdomain: core: Add GENPD_FLAG_DEV_NAME_FW flag", " - nouveau: fw: sync dma after setup is called.", " - nouveau: handle EBUSY and EAGAIN for GSP aux errors.", " - nouveau/dp: handle retries for AUX CH transfers with GSP.", " - drm/amd: Fix initialization mistake for NBIO 7.7.0", " - drm/amdgpu: fix check in gmc_v9_0_get_vm_pte()", " - drm/amdgpu: Fix video caps for H264 and HEVC encode maximum size", " - drm/amd/pm: print pp_dpm_mclk in ascending order on SMU v14.0.0", " - drm/amdgpu: enable GTT fallback handling for dGPUs only", " - drm/amdgpu/mes12: correct kiq unmap latency", " - drm/amd/display: Require minimum VBlank size for stutter optimization", " - drm/amd/display: Fix failure to read vram info due to static BP_RESULT", " - mm: refactor arch_calc_vm_flag_bits() and arm64 MTE handling", " - drm/xe: Restore system memory GGTT mappings", " - drm/xe: improve hibernation on igpu", " - lib/buildid: Fix build ID parsing logic", " - net: sched: u32: Add test case for systematic hnode IDR leaks", " - media: dvbdev: fix the logic when DVB_DYNAMIC_MINORS is not set", " - Linux 6.11.10", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53133", " - drm/amd/display: Handle dml allocation failure to avoid crash", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53108", " - drm/amd/display: Adjust VSDB parser for replay feature", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53134", " - pmdomain: imx93-blk-ctrl: correct remove path", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53132", " - drm/xe/oa: Fix \"Missing outer runtime PM protection\" warning", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53127", " - Revert \"mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K\"", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53130", " - nilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53105", " - mm: page_alloc: move mlocked flag clearance into free_pages_prepare()", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53109", " - nommu: pass NULL argument to vma_iter_prealloc()", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53131", " - nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53135", " - KVM: VMX: Bury Intel PT virtualization (guest/host mode) behind", " CONFIG_BROKEN", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53106", " - ima: fix buffer overrun in ima_eventdigest_init_common", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53110", " - vp_vdpa: fix id_table array not null terminated error", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53126", " - vdpa: solidrun: Fix UB bug with devres", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53111", " - mm/mremap: fix address wraparound in move_page_tables()", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53107", " - fs/proc/task_mmu: prevent integer overflow in pagemap_scan_get_args()", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53128", " - sched/task_stack: fix object_is_on_stack() for KASAN tagged pointers", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53112", " - ocfs2: uncache inode which has failed entering the group", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53113", " - mm: fix NULL pointer dereference in alloc_pages_bulk_noprof", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53114", " - x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 client", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53137", " - ARM: fix cacheflush with PAN", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53115", " - drm/vmwgfx: avoid null_ptr_deref in vmw_framebuffer_surface_create_handle", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53116", " - drm/panthor: Fix handling of partial GPU mapping of BOs", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53117", " - virtio/vsock: Improve MSG_ZEROCOPY error handling", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53118", " - vsock: Fix sk_error_queue memory leak", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53119", " - virtio/vsock: Fix accept_queue memory leak", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53120", " - net/mlx5e: CT: Fix null-ptr-deref in add rule err flow", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53138", " - net/mlx5e: kTLS, Fix incorrect page refcounting", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53121", " - net/mlx5: fs, lock FTE when checking if active", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53122", " - mptcp: cope racing subflow creation in mptcp_rcv_space_adjust", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53123", " - mptcp: error out earlier on disconnect", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53124", " - net: fix data-races around sk->sk_forward_alloc", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53129", " - drm/rockchip: vop: Fix a dereferenced before check warning", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53139", " - sctp: fix possible UAF in sctp_v6_available()", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53140", " - netlink: terminate outstanding dump on socket close", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649)", " - nvme/host: Fix RCU list traversal to use SRCU primitive", " - 9p: v9fs_fid_find: also lookup by inode if not found dentry", " - 9p: Avoid creating multiple slab caches with the same name", " - selftests/bpf: Verify that sync_linked_regs preserves subreg_def", " - nvmet-passthru: clear EUID/NGUID/UUID while using loop target", " - irqchip/ocelot: Fix trigger register address", " - pinctrl: aw9523: add missing mutex_destroy", " - pinctrl: intel: platform: Add Panther Lake to the list of supported", " - block: Fix elevator_get_default() checking for NULL q->tag_set", " - HID: multitouch: Add support for B2402FVA track point", " - HID: multitouch: Add quirk for HONOR MagicBook Art 14 touchpad", " - iommu/arm-smmu: Clarify MMU-500 CPRE workaround", " - nvme: disable CC.CRIME (NVME_CC_CRIME)", " - bpf: use kvzmalloc to allocate BPF verifier environment", " - crypto: api - Fix liveliness check in crypto_alg_tested", " - crypto: marvell/cesa - Disable hash algorithms", " - s390/ap: Fix CCA crypto card behavior within protected execution environment", " - sound: Make CONFIG_SND depend on INDIRECT_IOMEM instead of UML", " - drm/vmwgfx: Limit display layout ioctl array size to", " VMWGFX_NUM_DISPLAY_UNITS", " - selftests/bpf: Assert link info uprobe_multi count & path_size if unset", " - ALSA: hda/tas2781: Add new quirk for Lenovo, ASUS, Dell projects", " - drm/amdkfd: Accounting pdd vram_usage for svm", " - powerpc/powernv: Free name on error in opal_event_init()", " - net: phy: mdio-bcm-unimac: Add BCM6846 support", " - drm/xe/query: Increase timestamp width", " - nvme-loop: flush off pending I/O while shutting down loop controller", " - samples/landlock: Fix port parsing in sandboxer", " - vDPA/ifcvf: Fix pci_read_config_byte() return code handling", " - bpf: Fix mismatched RCU unlock flavour in bpf_out_neigh_v6", " - ASoC: Intel: avs: Update stream status in a separate thread", " - ASoC: codecs: Fix error handling in aw_dev_get_dsp_status function", " - ASoC: amd: yc: Add quirk for ASUS Vivobook S15 M3502RA", " - ASoC: amd: yc: Fix non-functional mic on ASUS E1404FA", " - ASoC: Intel: soc-acpi: lnl: Add match entry for TM2 laptops", " - netfs: Downgrade i_rwsem for a buffered write", " - HID: i2c-hid: Delayed i2c resume wakeup for 0x0d42 Goodix touchpad", " - HID: multitouch: Add quirk for Logitech Bolt receiver w/ Casa touchpad", " - HID: lenovo: Add support for Thinkpad X1 Tablet Gen 3 keyboard", " - ASoC: codecs: lpass-rx-macro: fix RXn(rx,n) macro for DSM_CTL and SEC7 regs", " - RISCV: KVM: use raw_spinlock for critical section in imsic", " - ASoC: rt722-sdca: increase clk_stop_timeout to fix clock stop issue", " - LoongArch: Use \"Exception return address\" to comment ERA", " - ASoC: fsl_micfil: Add sample rate constraint", " - net: usb: qmi_wwan: add Fibocom FG132 0x0112 composition", " - drm/xe: Enlarge the invalidation timeout from 150 to 500", " - drm/xe/guc/ct: Flush g2h worker in case of g2h response timeout", " - drm/xe: Handle unreliable MMIO reads during forcewake", " - drm/xe: Don't restart parallel queues multiple times on GT reset", " - mm: krealloc: Fix MTE false alarm in __do_krealloc", " - 9p: fix slab cache name creation for real", " - Linux 6.11.9", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53098", " - drm/xe/ufence: Prefetch ufence addr to catch bogus address", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53099", " - bpf: Check validity of link->type in bpf_link_show_fdinfo()", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53089", " - LoongArch: KVM: Mark hrtimer to expire in hard interrupt context", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53090", " - afs: Fix lock recursion", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53101", " - fs: Fix uninitialized value issue in from_kuid and from_kgid", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53091", " - bpf: Add sk_is_inet and IS_ICSK check in tls_sw_has_ctx_tx/rx", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53092", " - virtio_pci: Fix admin vq cleanup by using correct info pointer", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53102", " - nvme: make keep-alive synchronous operation", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53093", " - nvme-multipath: defer partition scanning", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53094", " - RDMA/siw: Add sendpage_ok() check to disable MSG_SPLICE_PAGES", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53100", " - nvme: tcp: avoid race between queue_lock lock and destroy", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53095", " - smb: client: Fix use-after-free of network namespace.", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645)", " - arm64: dts: rockchip: Fix rt5651 compatible value on rk3399-eaidk-610", " - arm64: dts: rockchip: Fix rt5651 compatible value on rk3399-sapphire-", " excavator", " - arm64: dts: rockchip: Move L3 cache outside CPUs in RK3588(S) SoC dtsi", " - arm64: dts: rockchip: Start cooling maps numbering from zero on ROCK 5B", " - arm64: dts: rockchip: Designate Turing RK1's system power controller", " - EDAC/qcom: Make irq configuration optional", " - arm64: dts: rockchip: Remove hdmi's 2nd interrupt on rk3328", " - arm64: dts: rockchip: Fix wakeup prop names on PineNote BT node", " - arm64: dts: rockchip: Fix reset-gpios property on brcm BT nodes", " - arm64: dts: rockchip: fix i2c2 pinctrl-names property on anbernic-rg353p/v", " - arm64: dts: rockchip: Drop regulator-init-microvolt from two boards", " - arm64: dts: rockchip: Fix bluetooth properties on rk3566 box demo", " - arm64: dts: rockchip: Fix bluetooth properties on Rock960 boards", " - arm64: dts: rockchip: Add DTS for FriendlyARM NanoPi R2S Plus", " - arm64: dts: rockchip: Remove undocumented supports-emmc property", " - arm64: dts: rockchip: Remove #cooling-cells from fan on Theobroma lion", " - arm64: dts: rockchip: Fix LED triggers on rk3308-roc-cc", " - arm64: dts: rockchip: remove num-slots property from rk3328-nanopi-r2s-plus", " - arm64: dts: qcom: sm8450 fix PIPE clock specification for pcie1", " - arm64: dts: imx8-ss-vpu: Fix imx8qm VPU IRQs", " - arm64: dts: imx8mp: correct sdhc ipg clk", " - arm64: dts: imx8mp-phyboard-pollux: Set Video PLL1 frequency to 506.8 MHz", " - firmware: qcom: scm: Return -EOPNOTSUPP for unsupported SHM bridge enabling", " - arm64: dts: rockchip: remove orphaned pinctrl-names from pinephone pro", " - ARM: dts: rockchip: fix rk3036 acodec node", " - ARM: dts: rockchip: drop grf reference from rk3036 hdmi", " - ARM: dts: rockchip: Fix the spi controller on rk3036", " - ARM: dts: rockchip: Fix the realtek audio codec on rk3036-kylin", " - arm64: dts: rockchip: Correct GPIO polarity on brcm BT nodes", " - sunrpc: handle -ENOTCONN in xs_tcp_setup_socket()", " - NFSv3: only use NFS timeout for MOUNT when protocols are compatible", " - NFS: Fix attribute delegation behaviour on exclusive create", " - NFS: Further fixes to attribute delegation a/mtime changes", " - nfs: avoid i_lock contention in nfs_clear_invalid_mapping", " - net: enetc: set MAC address to the VF net_device", " - net: dpaa_eth: print FD status in CPU endianness in dpaa_eth_fd tracepoint", " - dt-bindings: net: xlnx,axi-ethernet: Correct phy-mode property value", " - can: c_can: fix {rx,tx}_errors statistics", " - ice: change q_index variable type to s16 to store -1 value", " - e1000e: Remove Meteor Lake SMBUS workarounds", " - net: phy: ti: add PHY_RST_AFTER_CLK_EN flag", " - net: stmmac: Fix unbalanced IRQ wake disable warning on single irq case", " - netfilter: nf_tables: wait for rcu grace period on net_device removal", " - virtio_net: Support dynamic rss indirection table size", " - virtio_net: Sync rss config to device when virtnet_probe", " - virtio_net: Update rss when set queue", " - net: arc: rockchip: fix emac mdio node support", " - drivers: net: ionic: add missed debugfs cleanup to ionic_probe() error path", " - Revert \"ALSA: hda/conexant: Mute speakers at suspend / shutdown\"", " - media: stb0899_algo: initialize cfr before using it", " - media: dvb_frontend: don't play tricks with underflow values", " - media: adv7604: prevent underflow condition when reporting colorspace", " - scsi: sd_zbc: Use kvzalloc() to allocate REPORT ZONES buffer", " - ALSA: firewire-lib: fix return value on fail in amdtp_tscm_init()", " - tools/lib/thermal: Fix sampling handler context ptr", " - thermal/of: support thermal zones w/o trips subnode", " - ASoC: SOF: sof-client-probes-ipc4: Set param_size extension bits", " - media: pulse8-cec: fix data timestamp at pulse8_setup()", " - media: v4l2-ctrls-api: fix error handling for v4l2_g_ctrl()", " - can: m_can: m_can_close(): don't call free_irq() for IRQ-less devices", " - can: mcp251xfd: mcp251xfd_get_tef_len(): fix length calculation", " - can: mcp251xfd: mcp251xfd_ring_alloc(): fix coalescing configuration when", " switching CAN modes", " - can: {cc770,sja1000}_isa: allow building on x86_64", " - [Config] updateconfigs for CAN_{CC770,SJA1000}_ISA", " - drm/xe: Set mask bits for CCS_MODE register", " - pwm: imx-tpm: Use correct MODULO value for EPWM mode", " - rpmsg: glink: Handle rejected intent request better", " - drm/amd/pm: always pick the pptable from IFWI", " - drm/amd/display: Fix brightness level not retained over reboot", " - drm/imagination: Add a per-file PVR context list", " - drm/amdgpu: Adjust debugfs eviction and IB access permissions", " - drm/amdgpu: Adjust debugfs register access permissions", " - drm/amdgpu: Fix DPX valid mode check on GC 9.4.3", " - drm/amdgpu: prevent NULL pointer dereference if ATIF is not supported", " - thermal/drivers/qcom/lmh: Remove false lockdep backtrace", " - dm cache: correct the number of origin blocks to match the target length", " - dm cache: optimize dirty bit checking with find_next_bit when resizing", " - dm-unstriped: cast an operand to sector_t to prevent potential uint32_t", " overflow", " - mptcp: no admin perm to list endpoints", " - ALSA: usb-audio: Add quirk for HP 320 FHD Webcam", " - tracing: Fix tracefs mount options", " - net: wwan: t7xx: Fix off-by-one error in t7xx_dpmaif_rx_buf_alloc()", " - mptcp: use sock_kfree_s instead of kfree", " - arm64: Kconfig: Make SME depend on BROKEN for now", " - [Config] updateconfigs for ARM64_SME", " - arm64: smccc: Remove broken support for SMCCCv1.3 SVE discard hint", " - KVM: PPC: Book3S HV: Mask off LPCR_MER for a vCPU before running it to avoid", " spurious interrupts", " - btrfs: fix the length of reserved qgroup to free", " - btrfs: fix per-subvolume RO/RW flags with new mount API", " - platform/x86/amd/pmf: Relocate CPU ID macros to the PMF header", " - platform/x86/amd/pmf: Update SMU metrics table for 1AH family series", " - platform/x86/amd/pmf: Add SMU metrics table support for 1Ah family 60h model", " - i2c: designware: do not hold SCL low when I2C_DYNAMIC_TAR_UPDATE is not set", " - clk: qcom: gcc-x1e80100: Fix USB MP SS1 PHY GDSC pwrsts flags", " - clk: qcom: clk-alpha-pll: Fix pll post div mask when width is not set", " - fs/proc: fix compile warning about variable 'vmcore_mmap_ops'", " - objpool: fix to make percpu slot allocation more robust", " - mm/damon/core: handle zero {aggregation,ops_update} intervals", " - mm/damon/core: handle zero schemes apply interval", " - mm/mlock: set the correct prev on failure", " - thunderbolt: Add only on-board retimers when !CONFIG_USB4_DEBUGFS_MARGINING", " - usb: dwc3: fix fault at system suspend if device was already runtime", " suspended", " - USB: serial: qcserial: add support for Sierra Wireless EM86xx", " - USB: serial: option: add Fibocom FG132 0x0112 composition", " - USB: serial: option: add Quectel RG650V", " - clk: qcom: gcc-x1e80100: Fix halt_check for pipediv2 clocks", " - thunderbolt: Fix connection issue with Pluggable UD-4VPD dock", " - staging: vchiq_arm: Use devm_kzalloc() for drv_mgmt allocation", " - staging: vchiq_arm: Use devm_kzalloc() for vchiq_arm_state allocation", " - irqchip/gic-v3: Force propagation of the active state with a read-back", " - ucounts: fix counter leak in inc_rlimit_get_ucounts()", " - selftests: hugetlb_dio: check for initial conditions to skip in the start", " - firmware: qcom: scm: Refactor code to support multiple dload mode", " - [Config] updateconfigs for QCOM_SCM_DOWNLOAD_MODE_DEFAULT", " - firmware: qcom: scm: suppress download mode error", " - block: rework bio splitting", " - block: fix queue limits checks in blk_rq_map_user_bvec for real", " - drm/xe: Move LNL scheduling WA to xe_device.h", " - drm/xe/ufence: Flush xe ordered_wq in case of ufence timeout", " - drm/xe/guc/tlb: Flush g2h worker in case of tlb timeout", " - ASoC: amd: yc: fix internal mic on Xiaomi Book Pro 14 2022", " - xtensa: Emulate one-byte cmpxchg", " - Linux 6.11.8", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50265", " - ocfs2: remove entry once instead of null-ptr-dereference in", " ocfs2_xa_remove()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50266", " - clk: qcom: videocc-sm8350: use HW_CTRL_TRIGGER for vcodec GDSCs", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50267", " - USB: serial: io_edgeport: fix use after free in debug printk", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50268", " - usb: typec: fix potential out of bounds in ucsi_ccg_update_set_new_cam_cmd()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53083", " - usb: typec: qcom-pmic: init value of hdr_len/txbuf_len earlier", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50269", " - usb: musb: sunxi: Fix accessing an released usb phy", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53079", " - mm/thp: fix deferred split unqueue naming and locking", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50270", " - mm/damon/core: avoid overflow in damon_feed_loop_next_input()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50271", " - signal: restore the override_rlimit logic", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50272", " - filemap: Fix bounds checking in filemap_read()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53104", " - media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in", " uvc_parse_format", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50273", " - btrfs: reinitialize delayed ref list after deleting it from the list", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53064", " - idpf: fix idpf_vc_core_init error path", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50274", " - idpf: avoid vport access in idpf_get_link_ksettings", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53065", " - mm/slab: fix warning caused by duplicate kmem_cache creation in", " kmem_buckets_create", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50275", " - arm64/sve: Discard stale CPU state when handling SVE traps", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50276", " - net: vertexcom: mse102x: Fix possible double free of TX skb", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53066", " - nfs: Fix KMSAN warning in decode_getfattr_attrs()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53067", " - scsi: ufs: core: Start the RTC update work later", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50277", " - dm: fix a crash if blk_alloc_disk fails", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50278", " - dm cache: fix potential out-of-bounds access on the first resume", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50279", " - dm cache: fix out-of-bounds access to the dirty bitset when resizing", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50280", " - dm cache: fix flushing uninitialized delayed_work on cache_ctr error", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50281", " - KEYS: trusted: dcp: fix NULL dereference in AEAD crypto operation", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50282", " - drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53071", " - drm/panthor: Be stricter about IO mapping flags", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53080", " - drm/panthor: Lock XArray when getting entries for the VM", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53084", " - drm/imagination: Break an object reference loop", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53085", " - tpm: Lock TPM chip in tpm_pm_suspend() first", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53086", " - drm/xe: Drop VM dma-resv lock on xe_sync_in_fence_get failure in exec IOCTL", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53087", " - drm/xe: Fix possible exec queue leak in exec IOCTL", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50283", " - ksmbd: fix slab-use-after-free in smb3_preauth_hash_rsp", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50284", " - ksmbd: Fix the missing xa_store error check", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50285", " - ksmbd: check outstanding simultaneous SMB operations", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50286", " - ksmbd: fix slab-use-after-free in ksmbd_smb2_session_create", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50287", " - media: v4l2-tpg: prevent the risk of a division by zero", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50288", " - media: vivid: fix buffer overwrite when using > 32 buffers", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50289", " - media: av7110: fix a spectre vulnerability", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50290", " - media: cx24116: prevent overflows on SNR calculus", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53061", " - media: s5p-jpeg: prevent buffer overflows", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53081", " - media: ar0521: don't overflow when checking PLL values", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53062", " - media: mgb4: protect driver against spectre", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50291", " - media: dvb-core: add missing buffer index check", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50292", " - ASoC: stm32: spdifrx: fix dma channel release in stm32_spdifrx_remove", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53063", " - media: dvbdev: prevent the risk of out of memory access", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50293", " - net/smc: do not leave a dangling sk pointer in __smc_create()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50294", " - rxrpc: Fix missing locking causing hanging calls", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50295", " - net: arc: fix the device for dma_map_single/dma_unmap_single", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53082", " - virtio_net: Add hash_key_length check", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50296", " - net: hns3: fix kernel crash when uninstalling driver", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53088", " - i40e: fix race condition by adding filter's intermediate sync state", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50297", " - net: xilinx: axienet: Enqueue Tx packets in dql before dmaengine starts", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50298", " - net: enetc: allocate vf_state during PF probes", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50299", " - sctp: properly validate chunk size in sctp_sf_ootb()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50300", " - regulator: rtq2208: Fix uninitialized use of regulator_config", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50301", " - security/keys: fix slab-out-of-bounds in key_task_permission", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53072", " - platform/x86/amd/pmc: Detect when STB is not available", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50302", " - HID: core: zero-initialize the report buffer", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53068", " - firmware: arm_scmi: Fix slab-use-after-free in scmi_bus_notifier()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53069", " - firmware: qcom: scm: fix a NULL-pointer dereference", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629)", " - drm/amdgpu: fix random data corruption for sdma 7", " - cgroup: Fix potential overflow issue when checking max_depth", " - spi: geni-qcom: Fix boot warning related to pm_runtime and devres", " - perf trace: Fix non-listed archs in the syscalltbl routines", " - perf python: Fix up the build on architectures without HAVE_KVM_STAT_SUPPORT", " - scsi: scsi_debug: Fix do_device_access() handling of unexpected SG copy", " length", " - wifi: iwlegacy: Fix \"field-spanning write\" warning in il_enqueue_hcmd()", " - mac80211: MAC80211_MESSAGE_TRACING should depend on TRACING", " - wifi: mac80211: skip non-uploaded keys in ieee80211_iter_keys", " - wifi: ath11k: Fix invalid ring usage in full monitor mode", " - wifi: rtw89: pci: early chips only enable 36-bit DMA on specific PCI hosts", " - wifi: brcm80211: BRCM_TRACING should depend on TRACING", " - RDMA/cxgb4: Dump vendor specific QP details", " - RDMA/mlx5: Round max_rd_atomic/max_dest_rd_atomic up instead of down", " - RDMA/bnxt_re: Fix the usage of control path spin locks", " - RDMA/bnxt_re: synchronize the qp-handle table array", " - wifi: iwlwifi: mvm: really send iwl_txpower_constraints_cmd", " - wifi: iwlwifi: mvm: don't add default link in fw restart flow", " - Revert \"wifi: iwlwifi: remove retry loops in start\"", " - ASoC: cs42l51: Fix some error handling paths in cs42l51_probe()", " - net: stmmac: dwmac4: Fix high address display by updating reg_space[] from", " register values", " - dpll: add Embedded SYNC feature for a pin", " - ice: add callbacks for Embedded SYNC enablement on dpll pins", " - gtp: allow -1 to be specified as file description from userspace", " - bpf: Force checkpoint when jmp history is too long", " - bpf: Add bpf_mem_alloc_check_size() helper", " - net: skip offload for NETIF_F_IPV6_CSUM if ipv6 header contains extension", " - mlxsw: spectrum_ptp: Add missing verification before pushing Tx header", " - mlxsw: pci: Sync Rx buffers for CPU", " - mlxsw: pci: Sync Rx buffers for device", " - net: ethernet: mtk_wed: fix path of MT7988 WO firmware", " - bpf, test_run: Fix LIVE_FRAME frame update after a page has been recycled", " - iomap: improve shared block detection in iomap_unshare_iter", " - iomap: don't bother unsharing delalloc extents", " - iomap: share iomap_unshare_iter predicate code with fsdax", " - fsdax: remove zeroing code from dax_unshare_iter", " - iomap: turn iomap_want_unshare_iter into an inline function", " - kasan: Fix Software Tag-Based KASAN with GCC", " - firmware: arm_sdei: Fix the input parameter of cpuhp_remove_state()", " - afs: Fix missing subdir edit when renamed between parent dirs", " - gpio: sloppy-logic-analyzer: Check for error code from devm_mutex_init()", " call", " - smb: client: fix parsing of device numbers", " - smb: client: set correct device number on nfs reparse points", " - drm/mediatek: ovl: Remove the color format comment for ovl_fmt_convert()", " - drm/mediatek: Fix color format MACROs in OVL", " - drm/mediatek: Fix get efuse issue for MT8188 DPTX", " - drm/mediatek: Use cmdq_pkt_create() and cmdq_pkt_destroy()", " - cxl/events: Fix Trace DRAM Event Record", " - PCI: Fix pci_enable_acs() support for the ACS quirks", " - nvme: module parameter to disable pi with offsets", " - drm/panthor: Fix firmware initialization on systems with a page size > 4k", " - drm/panthor: Fail job creation when the group is dead", " - drm/panthor: Report group as timedout when we fail to properly suspend", " - fs/ntfs3: Fix warning possible deadlock in ntfs_set_state", " - fs/ntfs3: Stale inode instead of bad", " - rust: device: change the from_raw() function", " - scsi: scsi_transport_fc: Allow setting rport state to current state", " - cifs: Improve creating native symlinks pointing to directory", " - cifs: Fix creating native symlinks pointing to current or parent directory", " - ACPI: resource: Fold Asus Vivobook Pro N6506M* DMI quirks together", " - powercap: intel_rapl_msr: Add PL4 support for Arrowlake-U", " - thermal: intel: int340x: processor: Remove MMIO RAPL CPU hotplug support", " - thermal: intel: int340x: processor: Add MMIO RAPL PL4 support", " - net: amd: mvme147: Fix probe banner message", " - NFS: remove revoked delegation from server's delegation list", " - misc: sgi-gru: Don't disable preemption in GRU driver", " - NFSD: Initialize struct nfsd4_copy earlier", " - NFSD: Never decrement pending_async_copies on error", " - ALSA: usb-audio: Add quirks for Dell WD19 dock", " - wifi: rtlwifi: rtl8192du: Don't claim USB ID 0bda:8171", " - usbip: tools: Fix detach_port() invalid port error path", " - usb: phy: Fix API devm_usb_put_phy() can not release the phy", " - usb: typec: fix unreleased fwnode_handle in typec_port_register_altmodes()", " - usb: typec: tcpm: restrict SNK_WAIT_CAPABILITIES_TIMEOUT transitions to non", " self-powered devices", " - usb: typec: qcom-pmic-typec: use fwnode_handle_put() to release fwnodes", " - usb: typec: qcom-pmic-typec: fix missing fwnode removal in error path", " - xhci: Fix Link TRB DMA in command ring stopped completion event", " - xhci: Use pm_runtime_get to prevent RPM on unsupported systems", " - Revert \"driver core: Fix uevent_show() vs driver detach race\"", " - dt-bindings: iio: adc: ad7380: fix ad7380-4 reference supply", " - iio: light: veml6030: fix microlux value calculation", " - RISC-V: ACPI: fix early_ioremap to early_memremap", " - tools/mm: -Werror fixes in page-types/slabinfo", " - mm: shrinker: avoid memleak in alloc_shrinker_info", " - firmware: microchip: auto-update: fix poll_complete() to not report spurious", " timeout errors", " - thunderbolt: Honor TMU requirements in the domain when setting TMU mode", " - soc: qcom: pmic_glink: Handle GLINK intent allocation rejections", " - cxl/port: Fix CXL port initialization order when the subsystem is built-in", " - mmc: sdhci-pci-gli: GL9767: Fix low power mode on the set clock function", " - mmc: sdhci-pci-gli: GL9767: Fix low power mode in the SD Express process", " - block: fix sanity checks in blk_rq_map_user_bvec", " - phy: freescale: imx8m-pcie: Do CMN_RST just before PHY PLL lock check", " - btrfs: merge btrfs_orig_bbio_end_io() into btrfs_bio_end_io()", " - riscv: vdso: Prevent the compiler from inserting calls to memset()", " - Input: edt-ft5x06 - fix regmap leak when probe fails", " - ALSA: hda/realtek: Limit internal Mic boost on Dell platform", " - riscv: efi: Set NX compat flag in PE/COFF header", " - riscv: Use '%u' to format the output of 'cpu'", " - riscv: Remove unused GENERATING_ASM_OFFSETS", " - riscv: Remove duplicated GET_RM", " - cxl/port: Fix cxl_bus_rescan() vs bus_rescan_devices()", " - cxl/acpi: Ensure ports ready at cxl_acpi_probe() return", " - posix-cpu-timers: Clear TICK_DEP_BIT_POSIX_TIMER on clone", " - tpm: Return tpm2_sessions_init() when null key creation fails", " - tpm: Rollback tpm2_load_null()", " - drm/amdgpu/smu13: fix profile reporting", " - tpm: Lazily flush the auth session", " - mei: use kvmalloc for read buffer", " - x86/traps: Enable UBSAN traps on x86", " - x86/traps: move kmsan check after instrumentation_begin", " - accel/ivpu: Fix NOC firewall interrupt handling", " - ALSA: hda/realtek: Fix headset mic on TUXEDO Gemini 17 Gen3", " - ALSA: hda/realtek: Fix headset mic on TUXEDO Stellaris 16 Gen6 mb1", " - nvme: re-fix error-handling for io_uring nvme-passthrough", " - kasan: remove vmalloc_percpu test", " - drm/tests: helpers: Add helper for drm_display_mode_from_cea_vic()", " - drm/xe: Fix register definition order in xe_regs.h", " - drm/xe: Kill regs/xe_sriov_regs.h", " - drm/xe: Add mmio read before GGTT invalidate", " - drm/xe: Don't short circuit TDR on jobs not started", " - btrfs: fix extent map merging not happening for adjacent extents", " - btrfs: fix defrag not merging contiguous extents due to merged extent maps", " - gpiolib: fix debugfs newline separators", " - gpiolib: fix debugfs dangling chip separator", " - vmscan,migrate: fix page count imbalance on node stats when demoting pages", " - mm, mmap: limit THP alignment of anonymous mappings to PMD-aligned sizes", " - Input: fix regression when re-registering input handlers", " - mm: multi-gen LRU: ignore non-leaf pmd_young for force_scan=true", " - mm: multi-gen LRU: remove MM_LEAF_OLD and MM_NONLEAF_TOTAL stats", " - mm: shrink skip folio mapped by an exiting process", " - mm: multi-gen LRU: use {ptep,pmdp}_clear_young_notify()", " - riscv: dts: starfive: Update ethernet phy0 delay parameter values for Star64", " - riscv: dts: starfive: disable unused csi/camss nodes", " - arm64: dts: qcom: msm8939: revert use of APCS mbox for RPM", " - arm64: dts: qcom: x1e80100-yoga-slim7x: fix nvme regulator boot glitch", " - arm64: dts: qcom: x1e80100: Fix up BAR spaces", " - arm64: dts: qcom: x1e80100-vivobook-s15: fix nvme regulator boot glitch", " - arm64: dts: qcom: x1e80100: fix PCIe4 interconnect", " - arm64: dts: qcom: x1e80100-qcp: fix nvme regulator boot glitch", " - arm64: dts: qcom: x1e80100-crd: fix nvme regulator boot glitch", " - arm64: dts: qcom: x1e80100: Add Broadcast_AND region in LLCC block", " - arm64: dts: qcom: x1e80100: fix PCIe4 and PCIe6a PHY clocks", " - drm/xe/xe2hpg: Add Wa_15016589081", " - drm/amdgpu/swsmu: fix ordering for setting workload_mask", " - drm/amdgpu/swsmu: default to fullscreen 3D profile for dGPUs", " - fs/ntfs3: Sequential field availability check in mi_enum_attr()", " - drm/amdgpu: handle default profile on on devices without fullscreen 3D", " - MIPS: export __cmpxchg_small()", " - RISC-V: disallow gcc + rust builds", " - [Config] updateconfigs after disabling rust with gcc on riscv", " - rcu/kvfree: Add kvfree_rcu_barrier() API", " - rcu/kvfree: Refactor kvfree_rcu_queue_batch()", " - Linux 6.11.7", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50212", " - lib: alloc_tag_module_unload must wait for pending kfree_rcu calls", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53046", " - arm64: dts: imx8ulp: correct the flexspi compatible string", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53052", " - io_uring/rw: fix missing NOWAIT check for O_DIRECT start write", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50213", " - drm/tests: hdmi: Fix memory leaks in drm_display_mode_from_cea_vic()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50214", " - drm/connector: hdmi: Fix memory leak in drm_display_mode_from_cea_vic()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50215", " - nvmet-auth: assign dh_key to NULL after kfree_sensitive", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50216", " - xfs: fix finding a last resort AG in xfs_filestream_pick_ag", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50217", " - btrfs: fix use-after-free of block device file in", " __btrfs_free_extra_devids()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53043", " - mctp i2c: handle NULL header address", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50303", " - resource,kexec: walk_system_ram_res_rev must retain resource flags", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50218", " - ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50219", " - mm/page_alloc: let GFP_ATOMIC order-0 allocs access highatomic reserves", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50263", " - fork: only invoke khugepaged, ksm hooks if no error", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50220", " - fork: do not invoke uffd on fork if error occurs", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53047", " - mptcp: init: protect sched with rcu_read_lock", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50221", " - drm/amd/pm: Vangogh: Fix kernel memory out of bounds write", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50222", " - iov_iter: fix copy_page_from_iter_atomic() if KMAP_LOCAL_FORCE_MAP", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50223", " - sched/numa: Fix the potential null pointer dereference in task_numa_work()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53053", " - scsi: ufs: core: Fix another deadlock during RTC update", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53075", " - riscv: Prevent a bad reference count on CPU nodes", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50224", " - spi: spi-fsl-dspi: Fix crash when not using GPIO chip select", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50225", " - btrfs: fix error propagation of split bios", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53054", " - cgroup/bpf: use a dedicated workqueue for cgroup bpf destruction", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50226", " - cxl/port: Fix use-after-free, permit out-of-order decoder shutdown", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50227", " - thunderbolt: Fix KASAN reported stack out-of-bounds read in", " tb_retimer_scan()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50228", " - mm: shmem: fix data-race in shmem_getattr()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50229", " - nilfs2: fix potential deadlock with newly created symlinks", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50230", " - nilfs2: fix kernel bug due to missing clearing of checked flag", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50231", " - iio: gts-helper: Fix memory leaks in iio_gts_build_avail_scale_table()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53076", " - iio: gts-helper: Fix memory leaks for the error path of", " iio_gts_build_avail_scale_table()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50232", " - iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50233", " - staging: iio: frequency: ad9832: fix division by zero in", " ad9832_calc_freqreg()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53055", " - wifi: iwlwifi: mvm: fix 6 GHz scan construction", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50234", " - wifi: iwlegacy: Clear stale interrupts before resuming device", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50235", " - wifi: cfg80211: clear wdev->cqm_config pointer on free", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50236", " - wifi: ath10k: Fix memory leak in management tx", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50237", " - wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50238", " - phy: qcom: qmp-usbc: fix NULL-deref on runtime suspend", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50239", " - phy: qcom: qmp-usb-legacy: fix NULL-deref on runtime suspend", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50240", " - phy: qcom: qmp-usb: fix NULL-deref on runtime suspend", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53077", " - rpcrdma: Always release the rpcrdma_device's xa_array", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50242", " - fs/ntfs3: Additional check in ntfs_file_release", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50243", " - fs/ntfs3: Fix general protection fault in run_is_mapped_full", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50244", " - fs/ntfs3: Additional check in ni_clear()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50245", " - fs/ntfs3: Fix possible deadlock in mi_read", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50246", " - fs/ntfs3: Add rough attr alloc_size check", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50247", " - fs/ntfs3: Check if more than chunk-size bytes are written", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50248", " - ntfs3: Add bounds checking to mi_enum_attr()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53078", " - drm/tegra: Fix NULL vs IS_ERR() check in probe()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53056", " - drm/mediatek: Fix potential NULL dereference in mtk_crtc_destroy()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50249", " - ACPI: CPPC: Make rmw_lock a raw_spin_lock", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50250", " - fsdax: dax_unshare_iter needs to copy entire blocks", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50251", " - netfilter: nft_payload: sanitize offset and length before calling", " skb_checksum()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50252", " - mlxsw: spectrum_ipip: Fix memory leak when changing remote IPv6 address", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50253", " - bpf: Check the validity of nr_words in bpf_iter_bits_new()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50254", " - bpf: Free dynamically allocated bits in bpf_iter_bits_destroy()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50255", " - Bluetooth: hci: fix null-ptr-deref in hci_read_supported_codecs", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50256", " - netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50257", " - netfilter: Fix use-after-free in get_info()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50258", " - net: fix crash when config small gso_max_size/gso_ipv4_max_size", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50262", " - bpf: Fix out-of-bounds write in trie_get_next_key()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53044", " - net/sched: sch_api: fix xa_insert() error path in tcf_block_get_ext()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50259", " - netdevsim: Add trailing zero to terminate the string in", " nsim_nexthop_bucket_activity_write()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50304", " - ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53042", " - ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_init_flow()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53048", " - ice: fix crash on probe for DPLL enabled E810 LOM", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53058", " - net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50260", " - sock_map: fix a NULL pointer dereference in sock_map_link_update_prog()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53045", " - ASoC: dapm: fix bounds checker error in dapm_widget_list_create", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50261", " - macsec: Fix use-after-free while sending the offloading packet", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53059", " - wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53074", " - wifi: iwlwifi: mvm: don't leak a link on AP removal", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53049", " - slub/kunit: fix a WARNING due to unwrapped __kmalloc_cache_noprof", "", " * Oracular update: v6.11.6 upstream stable release (LP: #2091386)", " - bpf: Use raw_spinlock_t in ringbuf", " - iio: accel: bma400: Fix uninitialized variable field_value in tap event", " handling.", " - reset: starfive: jh71x0: Fix accessing the empty member on JH7110 SoC", " - bpf: sync_linked_regs() must preserve subreg_def", " - bpf: Make sure internal and UAPI bpf_redirect flags don't overlap", " - irqchip/riscv-imsic: Fix output text of base address", " - bpf: devmap: provide rxq after redirect", " - cpufreq/amd-pstate: Fix amd_pstate mode switch on shared memory systems", " - lib/Kconfig.debug: fix grammar in RUST_BUILD_ASSERT_ALLOW", " - bpf: Fix memory leak in bpf_core_apply", " - RDMA/bnxt_re: Fix a possible memory leak", " - RDMA/bnxt_re: Fix incorrect AVID type in WQE structure", " - RDMA/bnxt_re: Add a check for memory allocation", " - x86/resctrl: Avoid overflow in MB settings in bw_validate()", " - ARM: dts: bcm2837-rpi-cm3-io3: Fix HDMI hpd-gpio pin", " - clk: rockchip: fix finding of maximum clock ID", " - bpf: Check the remaining info_cnt before repeating btf fields", " - bpf: fix unpopulated name_len field in perf_event link info", " - selftests/bpf: fix perf_event link info name_len assertion", " - riscv, bpf: Fix possible infinite tailcall when CONFIG_CFI_CLANG is enabled", " - s390/pci: Handle PCI error codes other than 0x3a", " - bpf: fix kfunc btf caching for modules", " - iio: frequency: {admv4420,adrf6780}: format Kconfig entries", " - iio: frequency: admv4420: fix missing select REMAP_SPI in Kconfig", " - drm/vmwgfx: Handle possible ENOMEM in vmw_stdu_connector_atomic_check", " - selftests/bpf: Fix cross-compiling urandom_read", " - bpf: Fix unpopulated path_size when uprobe_multi fields unset", " - sched/core: Disable page allocation in task_tick_mm_cid()", " - ALSA: hda/cs8409: Fix possible NULL dereference", " - firmware: arm_scmi: Fix the double free in scmi_debugfs_common_setup()", " - RDMA/cxgb4: Fix RDMA_CM_EVENT_UNREACHABLE error for iWARP", " - RDMA/irdma: Fix misspelling of \"accept*\"", " - RDMA/srpt: Make slab cache names unique", " - elevator: do not request_module if elevator exists", " - elevator: Remove argument from elevator_find_get", " - ipv4: give an IPv4 dev to blackhole_netdev", " - net: sparx5: fix source port register when mirroring", " - RDMA/bnxt_re: Fix the max CQ WQEs for older adapters", " - RDMA/bnxt_re: Fix out of bound check", " - RDMA/bnxt_re: Fix incorrect dereference of srq in async event", " - RDMA/bnxt_re: Return more meaningful error", " - RDMA/bnxt_re: Avoid CPU lockups due fifo occupancy check loop", " - RDMA/bnxt_re: Get the toggle bits from SRQ events", " - RDMA/bnxt_re: Change the sequence of updating the CQ toggle value", " - RDMA/bnxt_re: Fix a bug while setting up Level-2 PBL pages", " - RDMA/bnxt_re: Fix the GID table length", " - accel/qaic: Fix the for loop used to walk SG table", " - drm/panel: himax-hx83102: Adjust power and gamma to optimize brightness", " - drm/msm/dpu: make sure phys resources are properly initialized", " - drm/msm/dpu: move CRTC resource assignment to dpu_encoder_virt_atomic_check", " - drm/msm/dpu: check for overflow in _dpu_crtc_setup_lm_bounds()", " - drm/msm/dsi: improve/fix dsc pclk calculation", " - drm/msm/dsi: fix 32-bit signed integer extension in pclk_rate calculation", " - drm/msm: Avoid NULL dereference in msm_disp_state_print_regs()", " - drm/msm: Allocate memory for disp snapshot with kvzalloc()", " - firmware: arm_scmi: Queue in scmi layer for mailbox implementation", " - net/smc: Fix memory leak when using percpu refs", " - [PATCH} hwmon: (jc42) Properly detect TSE2004-compliant devices again", " - net: usb: usbnet: fix race in probe failure", " - net: stmmac: dwmac-tegra: Fix link bring-up sequence", " - octeontx2-af: Fix potential integer overflows on integer shifts", " - ring-buffer: Fix reader locking when changing the sub buffer order", " - drm/amd/amdgpu: Fix double unlock in amdgpu_mes_add_ring", " - macsec: don't increment counters for an unrelated SA", " - netdevsim: use cond_resched() in nsim_dev_trap_report_work()", " - net: ethernet: aeroflex: fix potential memory leak in", " greth_start_xmit_gbit()", " - net/smc: Fix searching in list of known pnetids in smc_pnet_add_pnetid", " - net: xilinx: axienet: fix potential memory leak in axienet_start_xmit()", " - net: ethernet: rtsn: fix potential memory leak in rtsn_start_xmit()", " - bpf: Fix truncation bug in coerce_reg_to_size_sx()", " - net: systemport: fix potential memory leak in bcm_sysport_xmit()", " - irqchip/renesas-rzg2l: Fix missing put_device", " - drm/msm/dpu: Don't always set merge_3d pending flush", " - drm/msm/dpu: don't always program merge_3d block", " - net: bcmasp: fix potential memory leak in bcmasp_xmit()", " - drm/msm/a6xx+: Insert a fence wait before SMMU table update", " - tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink().", " - net: dsa: mv88e6xxx: Fix the max_vid definition for the MV88E6361", " - genetlink: hold RCU in genlmsg_mcast()", " - ravb: Remove setting of RX software timestamp", " - net: ravb: Only advertise Rx/Tx timestamps if hardware supports it", " - net: dsa: vsc73xx: fix reception from VLAN-unaware bridges", " - scsi: target: core: Fix null-ptr-deref in target_alloc_device()", " - smb: client: fix possible double free in smb2_set_ea()", " - smb: client: fix OOBs when building SMB2_IOCTL request", " - usb: typec: altmode should keep reference to parent", " - s390: Initialize psw mask in perf_arch_fetch_caller_regs()", " - drm/xe: fix unbalanced rpm put() with fence_fini()", " - drm/xe: fix unbalanced rpm put() with declare_wedged()", " - drm/xe: Take job list lock in xe_sched_add_pending_job", " - drm/xe: Don't free job in TDR", " - drm/xe: Use bookkeep slots for external BO's in exec IOCTL", " - bpf: Fix link info netfilter flags to populate defrag flag", " - Bluetooth: bnep: fix wild-memory-access in proto_unregister", " - vmxnet3: Fix packet corruption in vmxnet3_xdp_xmit_frame", " - net: ethernet: mtk_eth_soc: fix memory corruption during fq dma init", " - net/mlx5: Check for invalid vector index on EQ creation", " - net/mlx5: Fix command bitmask initialization", " - net/mlx5: Unregister notifier on eswitch init failure", " - net/mlx5e: Don't call cleanup on profile rollback failure", " - bpf, sockmap: SK_DROP on attempted redirects of unsupported af_vsock", " - vsock: Update rx_bytes on read_skb()", " - vsock: Update msg_count on read_skb()", " - bpf, vsock: Drop static vsock_bpf_prot initialization", " - riscv, bpf: Make BPF_CMPXCHG fully ordered", " - nvme-pci: fix race condition between reset and nvme_dev_disable()", " - bpf: Fix iter/task tid filtering", " - bpf: Fix incorrect delta propagation between linked registers", " - bpf: Fix print_reg_state's constant scalar dump", " - cdrom: Avoid barrier_nospec() in cdrom_ioctl_media_changed()", " - fgraph: Allocate ret_stack_list with proper size", " - mm: shmem: rename shmem_is_huge() to shmem_huge_global_enabled()", " - mm: shmem: move shmem_huge_global_enabled() into", " shmem_allowable_huge_orders()", " - mm: huge_memory: add vma_thp_disabled() and thp_disabled_by_hw()", " - mm: don't install PMD mappings when THPs are disabled by the hw/process/vma", " - iio: adc: ti-lmp92064: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - xhci: dbgtty: remove kfifo_out() wrapper", " - xhci: dbgtty: use kfifo from tty_port struct", " - xhci: dbc: honor usb transfer size boundaries.", " - uprobe: avoid out-of-bounds memory access of fetching args", " - drm/vboxvideo: Replace fake VLA at end of vbva_mouse_pointer_shape with real", " VLA", " - ASoC: amd: yc: Add quirk for HP Dragonfly pro one", " - ASoC: codecs: lpass-rx-macro: add missing CDC_RX_BCL_VBAT_RF_PROC2 to", " default regs values", " - ASoC: fsl_sai: Enable 'FIFO continue on error' FCONT bit", " - arm64: Force position-independent veneers", " - udf: refactor udf_current_aext() to handle error", " - udf: refactor udf_next_aext() to handle error", " - udf: refactor inode_bmap() to handle error", " - udf: fix uninit-value use in udf_get_fileshortad", " - ASoC: qcom: sm8250: add qrb4210-rb2-sndcard compatible string", " - fsnotify: Avoid data race between fsnotify_recalc_mask() and", " fsnotify_object_watched()", " - drm/xe/mcr: Use Xe2_LPM steering tables for Xe2_HPM", " - cifs: Validate content of NFS reparse point buffer", " - LoongArch: Don't crash in stack_top() for tasks without vDSO", " - objpool: fix choosing allocation for percpu slots", " - jfs: Fix sanity check in dbMount", " - tracing/probes: Fix MAX_TRACE_ARGS limit handling", " - tracing: Consider the NULL character when validating the event length", " - xfrm: extract dst lookup parameters into a struct", " - xfrm: respect ip protocols rules criteria when performing dst lookups", " - xfrm: validate new SA's prefixlen using SA family when sel.family is unset", " - netfilter: bpf: must hold reference on net namespace", " - net: pse-pd: Fix out of bound for loop", " - net/sun3_82586: fix potential memory leak in sun3_82586_send_packet()", " - be2net: fix potential memory leak in be_xmit()", " - net: plip: fix break; causing plip to never transmit", " - bnxt_en: replace ptp_lock with irqsave variant", " - octeon_ep: Implement helper for iterating packets in Rx queue", " - octeon_ep: Add SKB allocation failures handling in __octep_oq_process_rx()", " - net: dsa: mv88e6xxx: Fix error when setting port policy on mv88e6393x", " - bpf, arm64: Fix address emission with tag-based KASAN enabled", " - fsl/fman: Save device references taken in mac_probe()", " - fsl/fman: Fix refcount handling of fman-related devices", " - net: wwan: fix global oob in wwan_rtnl_policy", " - net: fix races in netdev_tx_sent_queue()/dev_watchdog()", " - virtio_net: fix integer overflow in stats", " - mlxsw: spectrum_router: fix xa_store() error checking", " - net: usb: usbnet: fix name regression", " - bpf: Preserve param->string when parsing mount options", " - bpf: Add MEM_WRITE attribute", " - bpf: Fix overloading of MEM_UNINIT's meaning", " - bpf: Remove MEM_UNINIT from skb/xdp MTU helpers", " - net/sched: act_api: deny mismatched skip_sw/skip_hw flags for actions", " created by classifiers", " - net: sched: fix use-after-free in taprio_change()", " - net: sched: use RCU read-side critical section in taprio_dump()", " - r8169: avoid unsolicited interrupts", " - posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime()", " - Bluetooth: hci_core: Disable works on hci_unregister_dev", " - Bluetooth: SCO: Fix UAF on sco_sock_timeout", " - Bluetooth: ISO: Fix UAF on iso_sock_timeout", " - bpf,perf: Fix perf_event_detach_bpf_prog error handling", " - bpf: fix do_misc_fixups() for bpf_get_branch_snapshot()", " - net: dsa: microchip: disable EEE for KSZ879x/KSZ877x/KSZ876x", " - net: dsa: mv88e6xxx: group cycle counter coefficients", " - net: dsa: mv88e6xxx: read cycle counter period from hardware", " - net: dsa: mv88e6xxx: support 4000ps cycle counter period", " - bpf: Add the missing BPF_LINK_TYPE invocation for sockmap", " - ASoC: dt-bindings: davinci-mcasp: Fix interrupts property", " - ASoC: dt-bindings: davinci-mcasp: Fix interrupt properties", " - ASoC: loongson: Fix component check failed on FDT systems", " - ASoC: topology: Bump minimal topology ABI version", " - ASoC: max98388: Fix missing increment of variable slot_found", " - ASoC: rsnd: Fix probe failure on HiHope boards due to endpoint parsing", " - PCI: Hold rescan lock while adding devices during host probe", " - fs: pass offset and result to backing_file end_write() callback", " - fuse: update inode size after extending passthrough write", " - ASoC: fsl_micfil: Add a flag to distinguish with different volume control", " types", " - ALSA: firewire-lib: Avoid division by zero in apply_constraint_to_size()", " - fbdev: wm8505fb: select CONFIG_FB_IOMEM_FOPS", " - powercap: dtpm_devfreq: Fix error check against dev_pm_qos_add_request()", " - nfsd: cancel nfsd_shrinker_work using sync mode in nfs4_state_shutdown_net", " - ALSA: hda/realtek: Update default depop procedure", " - smb: client: Handle kstrdup failures for passwords", " - cifs: fix warning when destroy 'cifs_io_request_pool'", " - PCI/pwrctl: Add WCN6855 support", " - PCI/pwrctl: Abandon QCom WCN probe on pre-pwrseq device-trees", " - cpufreq: CPPC: fix perf_to_khz/khz_to_perf conversion exception", " - btrfs: qgroup: set a more sane default value for subtree drop threshold", " - btrfs: clear force-compress on remount when compress mount option is given", " - btrfs: fix passing 0 to ERR_PTR in btrfs_search_dir_index_item()", " - perf/x86/rapl: Fix the energy-pkg event for AMD CPUs", " - btrfs: reject ro->rw reconfiguration if there are hard ro requirements", " - btrfs: zoned: fix zone unusable accounting for freed reserved extent", " - btrfs: fix read corruption due to race with extent map merging", " - drm/amd: Guard against bad data for ATIF ACPI method", " - ACPI: resource: Add LG 16T90SP to irq1_level_low_skip_override[]", " - ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context", " - ACPI: button: Add DMI quirk for Samsung Galaxy Book2 to fix initial lid", " detection issue", " - nilfs2: fix kernel bug due to missing clearing of buffer delay flag", " - fs: don't try and remove empty rbtree node", " - xfs: don't fail repairs on metadata files with no attr fork", " - openat2: explicitly return -E2BIG for (usize > PAGE_SIZE)", " - KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory", " - KVM: arm64: Unregister redistributor for failed vCPU creation", " - KVM: arm64: Fix shift-out-of-bounds bug", " - KVM: arm64: Don't eagerly teardown the vgic on init error", " - firewire: core: fix invalid port index for parent device", " - x86/lam: Disable ADDRESS_MASKING in most cases", " - [Config] updateconfigs to disable ADDRESS_MASKING", " - x86/sev: Ensure that RMP table fixups are reserved", " - ALSA: hda/tas2781: select CRC32 instead of CRC32_SARWATE", " - ALSA: hda/realtek: Add subwoofer quirk for Acer Predator G9-593", " - LoongArch: Get correct cores_per_package for SMT systems", " - LoongArch: Enable IRQ if do_ale() triggered in irq-enabled context", " - LoongArch: Make KASAN usable for variable cpu_vabits", " - xfrm: fix one more kernel-infoleak in algo dumping", " - hv_netvsc: Fix VF namespace also in synthetic NIC NETDEV_REGISTER event", " - md/raid10: fix null ptr dereference in raid10_size()", " - drm/bridge: Fix assignment of the of_node of the parent to aux bridge", " - drm/amd/display: Disable PSR-SU on Parade 08-01 TCON too", " - platform/x86/intel/pmc: Fix pmc_core_iounmap to call iounmap for valid", " addresses", " - fgraph: Fix missing unlock in register_ftrace_graph()", " - fgraph: Change the name of cpuhp state to \"fgraph:online\"", " - net: phy: dp83822: Fix reset pin definitions", " - nfsd: fix race between laundromat and free_stateid", " - drm/amd/display: temp w/a for DP Link Layer compliance", " - ata: libata: Set DID_TIME_OUT for commands that actually timed out", " - ASoC: SOF: Intel: hda-loader: do not wait for HDaudio IOC", " - ASoC: SOF: Intel: hda: Handle prepare without close for non-HDA DAI's", " - ASoC: SOF: Intel: hda: Always clean up link DMA during stop", " - ASoC: SOF: ipc4-topology: Do not set ALH node_id for aggregated DAIs", " - ASoC: dapm: avoid container_of() to get component", " - ASoC: qcom: sc7280: Fix missing Soundwire runtime stream alloc", " - ASoC: qcom: sdm845: add missing soundwire runtime stream alloc", " - ASoC: qcom: Fix NULL Dereference in asoc_qcom_lpass_cpu_platform_probe()", " - Revert \" fs/9p: mitigate inode collisions\"", " - Revert \"fs/9p: remove redundant pointer v9ses\"", " - Revert \"fs/9p: fix uaf in in v9fs_stat2inode_dotl\"", " - Revert \"fs/9p: simplify iget to remove unnecessary paths\"", " - soundwire: intel_ace2x: Send PDI stream number during prepare", " - x86: support user address masking instead of non-speculative conditional", " - x86: fix whitespace in runtime-const assembler output", " - x86: fix user address masking non-canonical speculation issue", " - platform/x86: dell-wmi: Ignore suspend notifications", " - ACPI: PRM: Clean up guid type in struct prm_handler_info", " - ASoC: qcom: Select missing common Soundwire module code on SDM845", " - Linux 6.11.6", "", " * ovs/linuxbridge jobs running on ubuntu jammy broken with latest kernel", " 5.15.0-127.137 (LP: #2091990)", " - netfilter: xtables: fix typo causing some targets not to load on IPv6", "", " * By always inlining _compound_head(), clone() sees 3%+ performance increase", " (LP: #2089327)", " - mm: always inline _compound_head() with", " CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP=y", "", " * Keyboard backlight controls do not work on Asus ROG Zephyrus GA503RM in", " Oracular (LP: #2089113)", " - hid-asus: use hid for brightness control on keyboard", "", " * Random flickering with Intel i915 (Comet Lake and Kaby Lake) on Linux 6.8+", " (LP: #2086587)", " - SAUCE: iommu/intel: disable DMAR for KBL and CML integrated gfx", "", " * Add list of source files to linux-buildinfo (LP: #2086606)", " - [Packaging] Sort build dependencies alphabetically", " - [Packaging] Add list of used source files to buildinfo package", "", " * asus: Fix thermal profile initialization on Lunar Lake (LP: #2085950)", " - platform/x86: asus-wmi: Fix thermal profile initialization", "", " * drm/xe: Fix LNL getting wedged after idling (LP: #2085944)", " - drm/xe/guc/ct: Flush g2h worker in case of g2h response timeout", "", " * UFS: uspi->s_3apb UBSAN: shift-out-of-bounds (LP: #2087853)", " - ufs: ufs_sb_private_info: remove unused s_{2, 3}apb fields", "", " * Mute/mic LEDs don't function on HP EliteBook 645 G10 (LP: #2087983)", " - ALSA: hda/realtek: fix mute/micmute LEDs for a HP EliteBook 645 G10", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152)", " - ALSA: scarlett2: Add error check after retrieving PEQ filter values", " - ALSA: hda/conexant - Fix audio routing for HP EliteOne 1000 G2", " - net: enetc: remove xdp_drops statistic from enetc_xdp_drop()", " - net: enetc: block concurrent XDP transmissions during ring reconfiguration", " - net: enetc: disable Tx BD rings after they are empty", " - net: enetc: disable NAPI after all rings are disabled", " - net: enetc: add missing static descriptor and inline keyword", " - udp: Compute L4 checksum as usual when not segmenting the skb", " - arm64: dts: marvell: cn9130-sr-som: fix cp0 mdio pin numbers", " - arm64: probes: Fix simulate_ldr*_literal()", " - net: macb: Avoid 20s boot delay by skipping MDIO bus registration for fixed-", " link PHY", " - selftests: mptcp: join: test for prohibited MPC to port-based endp", " - fat: fix uninitialized variable", " - mm: khugepaged: fix the arguments order in khugepaged_collapse_file trace", " point", " - net: fec: Move `fec_ptp_read()` to the top of the file", " - net: fec: Remove duplicated code", " - mptcp: prevent MPC handshake on port-based signal endpoints", " - s390/sclp: Deactivate sclp after all its users", " - s390/sclp_vt220: Convert newlines to CRLF instead of LFCR", " - KVM: s390: gaccess: Check if guest address is in memslot", " - KVM: s390: Change virtual to physical address access in diag 0x258 handler", " - x86/cpufeatures: Define X86_FEATURE_AMD_IBPB_RET", " - x86/cpufeatures: Add a IBPB_NO_RET BUG flag", " - x86/entry: Have entry_ibpb() invalidate return predictions", " - x86/bugs: Skip RSB fill at VMEXIT", " - x86/bugs: Do not use UNTRAIN_RET with IBPB on entry", " - fgraph: Use CPU hotplug mechanism to initialize idle shadow stacks", " - Input: xpad - add support for 8BitDo Ultimate 2C Wireless Controller", " - io_uring/sqpoll: close race on waiting for sqring entries", " - selftest: hid: add the missing tests directory", " - Input: xpad - add support for MSI Claw A1M", " - scsi: mpi3mr: Validate SAS port assignments", " - scsi: ufs: core: Fix the issue of ICU failure", " - scsi: ufs: core: Requeue aborted request", " - drm/i915/dp_mst: Handle error during DSC BW overhead/slice calculation", " - drm/i915/dp_mst: Don't require DSC hblank quirk for a non-DSC compatible", " mode", " - drm/xe/xe_sync: initialise ufence.signalled", " - drm/xe/ufence: ufence can be signaled right after wait_woken", " - drm/vmwgfx: Cleanup kms setup without 3d", " - drm/vmwgfx: Handle surface check failure correctly", " - drm/amdgpu/mes: fix issue of writing to the same log buffer from 2 MES pipes", " - drm/amdgpu/smu13: always apply the powersave optimization", " - drm/amdgpu/swsmu: Only force workload setup on init", " - drm/amdgpu: prevent BO_HANDLES error from being overwritten", " - iio: dac: ad5770r: add missing select REGMAP_SPI in Kconfig", " - iio: dac: ltc1660: add missing select REGMAP_SPI in Kconfig", " - iio: dac: stm32-dac-core: add missing select REGMAP_MMIO in Kconfig", " - iio: adc: ti-ads8688: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: hid-sensors: Fix an error handling path in", " _hid_sensor_set_report_latency()", " - iio: light: veml6030: fix ALS sensor resolution", " - iio: light: opt3001: add missing full-scale range value", " - iio: amplifiers: ada4250: add missing select REGMAP_SPI in Kconfig", " - iio: frequency: adf4377: add missing select REMAP_SPI in Kconfig", " - iio: chemical: ens160: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: light: bu27008: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: magnetometer: af8133j: add missing select IIO_(TRIGGERED_)BUFFER in", " Kconfig", " - iio: resolver: ad2s1210 add missing select REGMAP in Kconfig", " - iio: pressure: bm1390: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: dac: ad5766: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: proximity: mb1232: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: dac: ad3552r: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: adc: ti-lmp92064: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: adc: ti-lmp92064: add missing select REGMAP_SPI in Kconfig", " - iio: adc: ti-ads124s08: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: resolver: ad2s1210: add missing select (TRIGGERED_)BUFFER in Kconfig", " - iio: adc: ad7944: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: accel: kx022a: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - Bluetooth: Remove debugfs directory on module init failure", " - Bluetooth: btusb: Fix not being able to reconnect after suspend", " - Bluetooth: btusb: Fix regression with fake CSR controllers 0a12:0001", " - xhci: Fix incorrect stream context type macro", " - xhci: Mitigate failed set dequeue pointer commands", " - USB: serial: option: add support for Quectel EG916Q-GL", " - USB: serial: option: add Telit FN920C04 MBIM compositions", " - usb: typec: qcom-pmic-typec: fix sink status being overwritten with RP_DEF", " - usb: gadget: f_uac2: fix return value for UAC2_ATTRIBUTE_STRING store", " - usb: dwc3: Wait for EndXfer completion before restoring GUSB2PHYCFG", " - usb: dwc3: core: Fix system suspend on TI AM62 platforms", " - misc: microchip: pci1xxxx: add support for NVMEM_DEVID_AUTO for EEPROM", " device", " - misc: microchip: pci1xxxx: add support for NVMEM_DEVID_AUTO for OTP device", " - serial: imx: Update mctrl old_status on RTSD interrupt", " - x86/resctrl: Annotate get_mem_config() functions as __init", " - x86/CPU/AMD: Only apply Zenbleed fix for Zen2 during late microcode load", " - x86/entry_32: Do not clobber user EFLAGS.ZF", " - irqchip/sifive-plic: Unmask interrupt in plic_irq_enable()", " - irqchip/sifive-plic: Return error code on failure", " - serial: qcom-geni: fix polled console initialisation", " - serial: qcom-geni: revert broken hibernation support", " - serial: qcom-geni: fix shutdown race", " - serial: qcom-geni: fix dma rx cancellation", " - serial: qcom-geni: fix receiver enable", " - mm: vmscan.c: fix OOM on swap stress test", " - ALSA: hda/conexant - Use cached pin control for Node 0x1d on HP EliteOne", " 1000 G2", " - Linux 6.11.5", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50192", " - irqchip/gic-v4: Don't allow a VMOVP on a dying VPE", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50069", " - pinctrl: apple: check devm_kasprintf() returned value", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50070", " - pinctrl: stm32: check devm_kasprintf() returned value", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50196", " - pinctrl: ocelot: fix system hang on level based interrupts", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50197", " - pinctrl: intel: platform: fix error path in device_for_each_child_node()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50071", " - pinctrl: nuvoton: fix a double free in ma35_pinctrl_dt_node_to_map_func()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50072", " - x86/bugs: Use code segment selector for VERW operand", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50073", " - tty: n_gsm: Fix use-after-free in gsm_cleanup_mux", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50193", " - x86/entry_32: Clear CPU buffers after register restore in NMI return", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50074", " - parport: Proper fix for array out-of-bounds access", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50100", " - USB: gadget: dummy-hcd: Fix \"task hung\" problem", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50075", " - xhci: tegra: fix checked USB2 port number", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50076", " - vt: prevent kernel-infoleak in con_font_get()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50077", " - Bluetooth: ISO: Fix multiple init when debugfs is disabled", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50078", " - Bluetooth: Call iso_exit() on module unload", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50198", " - iio: light: veml6030: fix IIO device retrieval from embedded device", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50201", " - drm/radeon: Fix encoder->possible_clones", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50098", " - scsi: ufs: core: Set SDEV_OFFLINE when UFS is shut down", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50079", " - io_uring/sqpoll: ensure task state is TASK_RUNNING when running task_work", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50080", " - ublk: don't allow user copy for unprivileged device", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50081", " - blk-mq: setup queue ->tag_set before initializing hctx", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50082", " - blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50101", " - iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI devices", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50083", " - tcp: fix mptcp DSS corruption due to large pmtu xmit", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50068", " - mm/damon/tests/sysfs-kunit.h: fix memory leak in", " damon_sysfs_test_add_targets()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50199", " - mm/swapfile: skip HugeTLB pages for unuse_vma", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50066", " - mm/mremap: fix move_normal_pmd/retract_page_tables race", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50202", " - nilfs2: propagate directory read errors from nilfs_find_entry()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50200", " - maple_tree: correct tree corruption on spanning store", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50084", " - net: microchip: vcap api: Fix memory leaks in vcap_api_encode_rule_test()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50194", " - arm64: probes: Fix uprobes for big-endian kernels", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50099", " - arm64: probes: Remove broken LDR (literal) uprobe support", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50195", " - posix-clock: Fix missing timespec64 check in pc_clock_settime()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50085", " - mptcp: pm: fix UaF read in mptcp_pm_nl_rm_addr_or_subflow", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50086", " - ksmbd: fix user-after-free from session log off", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50087", " - btrfs: fix uninitialized pointer free on read_alloc_one_name() error", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50088", " - btrfs: fix uninitialized pointer free in add_inode_ref()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068)", " - net: fec: don't save PTP state if PTP is unsupported", " - fs/ntfs3: Do not call file_modified if collapse range failed", " - fs/ntfs3: Optimize large writes into sparse file", " - fs/ntfs3: Fix sparse warning for bigendian", " - fs/ntfs3: Fix sparse warning in ni_fiemap", " - fs/ntfs3: Refactor enum_rstbl to suppress static checker", " - vdpa/octeon_ep: Fix format specifier for pointers in debug messages", " - virtio_console: fix misc probe bugs", " - perf vdso: Missed put on 32-bit dsos", " - perf build: Fix static compilation error when libdw is not installed", " - perf build: Fix build feature-dwarf_getlocations fail for old libdw", " - zram: don't free statically defined names", " - bpf: Call the missed btf_record_free() when map creation fails", " - selftests/bpf: Fix ARG_PTR_TO_LONG {half-,}uninitialized test", " - bpf: Check percpu map value size first", " - s390/facility: Disable compile time optimization for decompressor code", " - s390/mm: Add cond_resched() to cmm_alloc/free_pages()", " - bpf, x64: Fix a jit convergence issue", " - ext4: nested locking for xattr inode", " - s390/cpum_sf: Remove WARN_ON_ONCE statements", " - s390/traps: Handle early warnings gracefully", " - ktest.pl: Avoid false positives with grub2 skip regex", " - soundwire: intel_bus_common: enable interrupts before exiting reset", " - PCI: Add function 0 DMA alias quirk for Glenfly Arise chip", " - clk: bcm: bcm53573: fix OF node leak in init", " - PCI: Add ACS quirk for Qualcomm SA8775P", " - i2c: i801: Use a different adapter-name for IDF adapters", " - PCI: Mark Creative Labs EMU20k2 INTx masking as broken", " - RISC-V: Don't have MAX_PHYSMEM_BITS exceed phys_addr_t", " - mfd: intel_soc_pmic_chtwc: Make Lenovo Yoga Tab 3 X90F DMI match less strict", " - mfd: intel-lpss: Add Intel Panther Lake LPSS PCI IDs", " - riscv: Omit optimized string routines when using KASAN", " - riscv: avoid Imbalance in RAS", " - RDMA/mlx5: Enforce umem boundaries for explicit ODP page faults", " - PCI: qcom: Disable mirroring of DBI and iATU register space in BAR region", " - PCI: endpoint: Assign PCI domain number for endpoint controllers", " - soundwire: cadence: re-check Peripheral status with delayed_work", " - riscv/kexec_file: Fix relocation type R_RISCV_ADD16 and R_RISCV_SUB16", " unknown", " - media: videobuf2-core: clear memory related fields in", " __vb2_plane_dmabuf_put()", " - remoteproc: imx_rproc: Use imx specific hook for find_loaded_rsc_table", " - usb: chipidea: udc: enable suspend interrupt after usb reset", " - usb: dwc2: Adjust the timing of USB Driver Interrupt Registration in the", " Crashkernel Scenario", " - xhci: dbc: Fix STALL transfer event handling", " - usb: host: xhci-plat: Parse xhci-missing_cas_quirk and apply quirk", " - comedi: ni_routing: tools: Check when the file could not be opened", " - LoongArch: Fix memleak in pci_acpi_scan_root()", " - netfilter: nf_nat: don't try nat source port reallocation for reverse dir", " clash", " - netfilter: nf_reject: Fix build warning when CONFIG_BRIDGE_NETFILTER=n", " - tools/iio: Add memory allocation failure check for trigger_name", " - staging: vme_user: added bound check to geoid", " - driver core: bus: Return -EIO instead of 0 when show/store invalid bus", " attribute", " - scsi: lpfc: Add ELS_RSP cmd to the list of WQEs to flush in", " lpfc_els_flush_cmd()", " - scsi: lpfc: Revise TRACE_EVENT log flag severities from KERN_ERR to", " KERN_WARNING", " - NFSD: Mark filecache \"down\" if init fails", " - nfsd: nfsd_destroy_serv() must call svc_destroy() even if nfsd_startup_net()", " failed", " - ice: set correct dst VSI in only LAN filters", " - ice: clear port vlan config during reset", " - ice: disallow DPLL_PIN_STATE_SELECTABLE for dpll output pins", " - ice: fix VLAN replay after reset", " - SUNRPC: Fix integer overflow in decode_rc_list()", " - net: phy: aquantia: AQR115c fix up PMA capabilities", " - net: phy: aquantia: remove usage of phy_set_max_speed", " - tcp: fix to allow timestamp undo if no retransmits were sent", " - tcp: fix tcp_enter_recovery() to zero retrans_stamp when it's safe", " - tcp: fix TFO SYN_RECV to not zero retrans_stamp with retransmits out", " - rxrpc: Fix uninitialised variable in rxrpc_send_data()", " - net: dsa: sja1105: fix reception from VLAN-unaware bridges", " - selftests: net: no_forwarding: fix VID for $swp2 in one_bridge_two_pvids()", " test", " - net: pse-pd: Fix enabled status mismatch", " - Bluetooth: btusb: Don't fail external suspend requests", " - net: phy: bcm84881: Fix some error handling paths", " - net: ethernet: adi: adin1110: Fix some error handling path in", " adin1110_read_fifo()", " - net: dsa: b53: fix jumbo frame mtu check", " - net: dsa: b53: fix max MTU for 1g switches", " - net: dsa: b53: fix max MTU for BCM5325/BCM5365", " - net: dsa: b53: allow lower MTUs on BCM5325/5365", " - net: dsa: b53: fix jumbo frames on 10/100 ports", " - drm/nouveau: pass cli to nouveau_channel_new() instead of drm+device", " - nouveau/dmem: Fix privileged error in copy engine channel", " - gpio: aspeed: Add the flush write to ensure the write complete.", " - gpio: aspeed: Use devm_clk api to manage clock source", " - x86/xen: mark boot CPU of PV guest in MSR_IA32_APICBASE", " - powercap: intel_rapl_tpmi: Ignore minor version change", " - ice: Fix entering Safe Mode", " - ice: Fix netif_is_ice() in Safe Mode", " - ice: Flush FDB entries before reset", " - drm/xe: Restore GT freq on GSC load error", " - drm/xe: Make wedged_mode debugfs writable", " - net: ibm: emac: mal: fix wrong goto", " - net: ti: icssg-prueth: Fix race condition for VLAN table access", " - btrfs: zoned: fix missing RCU locking in error message when loading zone", " info", " - sctp: ensure sk_state is set to CLOSED if hashing fails in sctp_listen_start", " - netfilter: fib: check correct rtable in vrf setups", " - net: ibm: emac: mal: add dcr_unmap to _remove", " - net: dsa: refuse cross-chip mirroring operations", " - rtnetlink: Add bulk registration helpers for rtnetlink message handlers.", " - vxlan: Handle error of rtnl_register_module().", " - bridge: Handle error of rtnl_register_module().", " - mctp: Handle error of rtnl_register_module().", " - mpls: Handle error of rtnl_register_module().", " - phonet: Handle error of rtnl_register_module().", " - rcu/nocb: Fix rcuog wake-up from offline softirq", " - HID: multitouch: Add support for lenovo Y9000P Touchpad", " - hwmon: intel-m10-bmc-hwmon: relabel Columbiaville to CVL Die Temperature", " - hwmon: (tmp513) Add missing dependency on REGMAP_I2C", " - hwmon: (mc34vr500) Add missing dependency on REGMAP_I2C", " - hwmon: (adm9240) Add missing dependency on REGMAP_I2C", " - hwmon: (adt7470) Add missing dependency on REGMAP_I2C", " - hwmon: (ltc2991) Add missing dependency on REGMAP_I2C", " - HID: plantronics: Workaround for an unexcepted opposite volume key", " - HID: wacom: Hardcode (non-inverted) AES pens as BTN_TOOL_PEN", " - Revert \"usb: yurex: Replace snprintf() with the safer scnprintf() variant\"", " - usb: dwc3: core: Stop processing of pending events if controller is halted", " - usb: xhci: Fix problem with xhci resume from suspend", " - usb: storage: ignore bogus device raised by JieLi BR21 USB sound chip", " - usb: dwc3: re-enable runtime PM after failed resume", " - usb: gadget: core: force synchronous registration", " - hid: intel-ish-hid: Fix uninitialized variable 'rv' in", " ish_fw_xfer_direct_dma", " - ACPI: resource: Make Asus ExpertBook B2402 matches cover more models", " - ACPI: resource: Make Asus ExpertBook B2502 matches cover more models", " - drm/amdgpu: partially revert powerplay `__counted_by` changes", " - drm/amd/display: Clear update flags after update has been applied", " - drm/amdkfd: Fix an eviction fence leak", " - drm/amd/display: fix hibernate entry for DCN35+", " - drm/xe/guc_submit: fix xa_store() error checking", " - drm/i915/hdcp: fix connector refcounting", " - drm/xe/ct: fix xa_store() error checking", " - scsi: ufs: Use pre-calculated offsets in ufshcd_init_lrb()", " - Revert \"mmc: mvsdio: Use sg_miter for PIO\"", " - mmc: sdhci-of-dwcmshc: Prevent stale command interrupt handling", " - mptcp: fallback when MPTCP opts are dropped after 1st data", " - ata: libata: avoid superfluous disk spin down + spin up during hibernation", " - OPP: fix error code in dev_pm_opp_set_config()", " - net: dsa: lan9303: ensure chip reset and wait for READY status", " - net: phy: realtek: Fix MMD access on RTL8126A-integrated PHY", " - mptcp: pm: do not remove closing subflows", " - powercap: intel_rapl_tpmi: Fix bogus register reading", " - selftests/mm: fix incorrect buffer->mirror size in hmm2 double_map test", " - selftests/rseq: Fix mm_cid test failure", " - btrfs: split remaining space to discard in chunks", " - btrfs: add cancellation points to trim loops", " - PM: domains: Fix alloc/free in dev_pm_domain_attach|detach_list()", " - idpf: use actual mbx receive payload length", " - fs/proc/kcore.c: allow translation of physical memory addresses", " - PCI: Pass domain number to pci_bus_release_domain_nr() explicitly", " - io_uring/rw: fix cflags posting for single issue multishot read", " - Linux 6.11.4", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50182", " - secretmem: disable memfd_secret() if arch cannot set direct map", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50019", " - kthread: unpark only parked kthread", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50096", " - nouveau/dmem: Fix vulnerability in migrate_to_ram upon copy error", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50020", " - ice: Fix improper handling of refcount in ice_sriov_set_msix_vec_count()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50021", " - ice: Fix improper handling of refcount in ice_dpll_init_rclk_pins()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50022", " - device-dax: correct pgoff align in dax_set_mapping()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50185", " - mptcp: handle consistently DSS corruption", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50023", " - net: phy: Remove LED entry from LEDs list on unregister", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50024", " - net: Fix an unsafe loop on the list", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50186", " - net: explicitly clear the sk pointer, when pf->create fails", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50025", " - scsi: fnic: Move flush_work initialization out of if block", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50026", " - scsi: wd33c93: Don't use stale scsi_pointer value", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50027", " - thermal: core: Free tzp copy along with the thermal zone", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50028", " - thermal: core: Reference count the zone in thermal_zone_get_by_id()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50029", " - Bluetooth: hci_conn: Fix UAF in hci_enhanced_setup_sync", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50030", " - drm/xe/ct: prevent UAF in send_recv()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50187", " - drm/vc4: Stop the active perfmon before being destroyed", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50031", " - drm/v3d: Stop the active perfmon before being destroyed", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50189", " - HID: amd_sfh: Switch to device-managed dmam_alloc_coherent()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50033", " - slip: make slhc_remember() more robust against malicious packets", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50034", " - net/smc: fix lacks of icsk_syn_mss with IPPROTO_SMC", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50035", " - ppp: fix ppp_async_encode() illegal access", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50036", " - net: do not delay dst_entries_add() in dst_release()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50037", " - drm/fbdev-dma: Only cleanup deferred I/O if necessary", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50092", " - net: netconsole: fix wrong warning", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50038", " - netfilter: xtables: avoid NFPROTO_UNSPEC where needed", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50039", " - net/sched: accept TCA_STAB only for root qdisc", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50040", " - igb: Do not bring the device up after non-fatal error", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50041", " - i40e: Fix macvlan leak by synchronizing access to mac_filter_hash", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50042", " - ice: Fix increasing MSI-X on VF", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50093", " - thermal: intel: int340x: processor: Fix warning during module unload", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50043", " - nfsd: fix possible badness in FREE_STATEID", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50044", " - Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50045", " - netfilter: br_netfilter: fix panic with metadata_dst skb", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50094", " - sfc: Don't invoke xdp_do_flush() from netpoll.", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50188", " - net: phy: dp83869: fix memory corruption when enabling fiber", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50046", " - NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50190", " - ice: fix memleak in ice_init_tx_topology()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50180", " - fbdev: sisfb: Fix strbuf array overflow", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50047", " - smb: client: fix UAF in async decryption", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50048", " - fbcon: Fix a NULL pointer dereference issue in fbcon_putcs", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50049", " - drm/amd/display: Check null pointer before dereferencing se", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50090", " - drm/xe/oa: Fix overflow in oa batch buffer", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50183", " - scsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV", " instance", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50055", " - driver core: bus: Fix double free in driver API bus_register()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50091", " - dm vdo: don't refer to dedupe_context after releasing it", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50056", " - usb: gadget: uvc: Fix ERR_PTR dereference in uvc_v4l2.c", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50184", " - virtio_pmem: Check device status before requesting flush", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50057", " - usb: typec: tipd: Free IRQ only if it was requested before", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50058", " - serial: protect uart_port_dtr_rts() in uart_shutdown() too", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50181", " - clk: imx: Remove CLK_SET_PARENT_GATE for DRAM mux for i.MX7D", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50059", " - ntb: ntb_hw_switchtec: Fix use after free vulnerability in", " switchtec_ntb_remove due to race condition", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50060", " - io_uring: check if we need to reschedule during overflow flush", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50061", " - i3c: master: cdns: Fix use after free vulnerability in cdns_i3c_master", " Driver Due to Race Condition", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50062", " - RDMA/rtrs-srv: Avoid null pointer deref during path establishment", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50095", " - RDMA/mad: Improve handling of timed out WRs of mad agent", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50063", " - bpf: Prevent tail call between progs attached to different hooks", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50191", " - ext4: don't set SB_RDONLY after filesystem errors", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50064", " - zram: free secondary algorithms names", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50065", " - ntfs3: Change to non-blocking allocation in ntfs_d_hash", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50089", " - unicode: Don't special case ignorable code points", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052)", " - jump_label: Fix static_key_slow_dec() yet again", " - scsi: st: Fix input/output error on empty drive reset", " - scsi: pm8001: Do not overwrite PCI queue mapping", " - drm/i915/psr: Do not wait for PSR being idle on on Panel Replay", " - drm/i915/display: BMG supports UHBR13.5", " - drm/i915/dp: Fix AUX IO power enabling for eDP PSR", " - drm/amdgpu: Fix get each xcp macro", " - drm/amd/display: handle nulled pipe context in DCE110's set_drr()", " - ksmbd: fix warning: comparison of distinct pointer types lacks a cast", " - mailbox: ARM_MHU_V3 should depend on ARM64", " - [Config] updateconfigs for ARM_MHU_V3", " - mailbox: rockchip: fix a typo in module autoloading", " - ceph: fix a memory leak on cap_auths in MDS client", " - drm/i915/dp: Fix colorimetry detection", " - ieee802154: Fix build error", " - net: sparx5: Fix invalid timestamps", " - net/mlx5: Added cond_resched() to crdump collection", " - net/mlx5e: SHAMPO, Fix overflow of hd_per_wq", " - netfilter: uapi: NFTA_FLOWTABLE_HOOK is NLA_NESTED", " - net: ieee802154: mcr20a: Use IRQF_NO_AUTOEN flag in request_irq()", " - net: wwan: qcom_bam_dmux: Fix missing pm_runtime_disable()", " - selftests: netfilter: Fix nft_audit.sh for newer nft binaries", " - selftests: netfilter: Add missing return value", " - Bluetooth: btmrvl: Use IRQF_NO_AUTOEN flag in request_irq()", " - afs: Fix missing wire-up of afs_retry_request()", " - net: Add netif_get_gro_max_size helper for GRO", " - net: Fix gso_features_check to check for both dev->gso_{ipv4_,}max_size", " - net: fec: Restart PPS after link state change", " - net: fec: Reload PTP registers after link-state change", " - net: stmmac: dwmac4: extend timeout for VLAN Tag register busy bit check", " - ipv4: ip_gre: Fix drops of small packets in ipgre_xmit", " - netfs: Fix missing wakeup after issuing writes", " - net: phy: realtek: Check the index value in led_hw_control_get", " - bridge: mcast: Fail MDB get request on empty entry", " - iomap: constrain the file range passed to iomap_file_unshare", " - dt-bindings: net: xlnx,axi-ethernet: Add missing reg minItems", " - ASoC: topology: Fix incorrect addressing assignments", " - ASoC: atmel: mchp-pdmc: Skip ALSA restoration if substream runtime is", " uninitialized", " - drm/connector: hdmi: Fix writing Dynamic Range Mastering infoframes", " - io_uring: fix memory leak when cache init fail", " - rust: kbuild: split up helpers.c", " - rust: kbuild: auto generate helper exports", " - rust: mutex: fix __mutex_init() usage in case of PREEMPT_RT", " - ALSA: mixer_oss: Remove some incorrect kfree_const() usages", " - ALSA: hda/realtek: Fix the push button function for the ALC257", " - cifs: Remove intermediate object of failed create reparse call", " - drm/panthor: Lock the VM resv before calling drm_gpuvm_bo_obtain_prealloc()", " - ALSA: hda/generic: Unconditionally prefer preferred_dacs pairs", " - ASoC: imx-card: Set card.owner to avoid a warning calltrace if SND=m", " - drm/xe: Restore pci state upon resume", " - drm/xe: Resume TDR after GT reset", " - cifs: Do not convert delimiter when parsing NFS-style symlinks", " - tools/rtla: Fix installation from out-of-tree build", " - ALSA: gus: Fix some error handling paths related to get_bpos() usage", " - ALSA: hda/conexant: Fix conflicting quirk for System76 Pangolin", " - drm/amd/display: Disable replay if VRR capability is false", " - drm/amd/display: Fix VRR cannot enable", " - drm/amd/display: Re-enable panel replay feature", " - e1000e: avoid failing the system during pm_suspend", " - wifi: ath9k: fix possible integer overflow in ath9k_get_et_stats()", " - crypto: x86/sha256 - Add parentheses around macros' single arguments", " - crypto: octeontx - Fix authenc setkey", " - crypto: octeontx2 - Fix authenc setkey", " - ice: Adjust over allocation of memory in ice_sched_add_root_node() and", " ice_sched_add_node()", " - wifi: iwlwifi: mvm: Fix a race in scan abort flow", " - wifi: iwlwifi: mvm: drop wrong STA selection in TX", " - net: hisilicon: hip04: fix OF node leak in probe()", " - net: hisilicon: hns_dsaf_mac: fix OF node leak in hns_mac_get_info()", " - net: hisilicon: hns_mdio: fix OF node leak in probe()", " - ACPICA: Fix memory leak if acpi_ps_get_next_namepath() fails", " - ACPICA: Fix memory leak if acpi_ps_get_next_field() fails", " - ACPI: resource: Skip IRQ override on Asus Vivobook Go E1404GAB", " - wifi: mt76: mt7915: disable tx worker during tx BA session enable/disable", " - net: sched: consistently use rcu_replace_pointer() in taprio_change()", " - Bluetooth: btusb: Add Realtek RTL8852C support ID 0x0489:0xe122", " - Bluetooth: btrtl: Set msft ext address filter quirk for RTL8852B", " - ACPI: video: Add force_vendor quirk for Panasonic Toughbook CF-18", " - ACPI: CPPC: Add support for setting EPP register in FFH", " - wifi: rtw88: select WANT_DEV_COREDUMP", " - l2tp: free sessions using rcu", " - l2tp: use rcu list add/del when updating lists", " - ACPI: EC: Do not release locks during operation region accesses", " - net: skbuff: sprinkle more __GFP_NOWARN on ingress allocs", " - net: mvpp2: Increase size of queue_name buffer", " - bnxt_en: Extend maximum length of version string by 1 byte", " - ipv4: Check !in_dev earlier for ioctl(SIOCSIFADDR).", " - wifi: rtw89: correct base HT rate mask for firmware", " - netfilter: nf_tables: do not remove elements if set backend implements", " .abort", " - ipv4: Mask upper DSCP bits and ECN bits in NETLINK_FIB_LOOKUP family", " - nvme-keyring: restrict match length for version '1' identifiers", " - nvme-tcp: sanitize TLS key handling", " - nvme-tcp: check for invalidated or revoked key", " - net: atlantic: Avoid warning about potential string truncation", " - crypto: simd - Do not call crypto_alloc_tfm during registration", " - netpoll: Ensure clean state on setup failures", " - tcp: avoid reusing FIN_WAIT2 when trying to find port in connect() process", " - wifi: iwlwifi: mvm: use correct key iteration", " - wifi: iwlwifi: allow only CN mcc from WRDD", " - virt: sev-guest: Ensure the SNP guest messages do not exceed a page", " - wifi: mac80211: fix RCU list iterations", " - ACPICA: iasl: handle empty connection_node", " - proc: add config & param to block forcing mem writes", " - [Config] updateconfigs to select PROC_MEM_ALWAYS_FORCE", " - vfs: use RCU in ilookup", " - drivers/perf: arm_spe: Use perf_allow_kernel() for permissions", " - nvme: fix metadata handling in nvme-passthrough", " - can: netlink: avoid call to do_set_data_bittiming callback with stale", " can_priv::ctrlmode", " - netdev-genl: Set extack and fix error on napi-get", " - wifi: wilc1000: Do not operate uninitialized hardware during suspend/resume", " - arm64: trans_pgd: mark PTEs entries as valid to avoid dead kexec()", " - net: phy: Check for read errors in SIOCGMIIREG", " - x86/bugs: Add missing NO_SSB flag", " - x86/bugs: Fix handling when SRSO mitigation is disabled", " - crypto: hisilicon - fix missed error branch", " - wifi: mt76: mt7915: add dummy HW offload of IEEE 802.11 fragmentation", " - wifi: mt76: mt7915: hold dev->mt76.mutex while disabling tx worker", " - netfs: Cancel dirty folios that have no storage destination", " - nfp: Use IRQF_NO_AUTOEN flag in request_irq()", " - ALSA: usb-audio: Add input value sanity checks for standard types", " - x86/apic: Remove logical destination mode for 64-bit", " - ALSA: usb-audio: Define macros for quirk table entries", " - ALSA: usb-audio: Replace complex quirk lines with macros", " - ALSA: usb-audio: Add quirk for RME Digiface USB", " - ALSA: usb-audio: Add mixer quirk for RME Digiface USB", " - ALSA: hda/realtek: Refactor and simplify Samsung Galaxy Book init", " - ALSA: usb-audio: Add logitech Audio profile quirk", " - ASoC: codecs: wsa883x: Handle reading version failure", " - ALSA: control: Take power_ref lock primarily", " - tools/x86/kcpuid: Protect against faulty \"max subleaf\" values", " - x86/pkeys: Add PKRU as a parameter in signal handling functions", " - x86/pkeys: Restore altstack access in sigreturn()", " - x86/kexec: Add EFI config table identity mapping for kexec kernel", " - ALSA: hdsp: Break infinite MIDI input flush loop", " - tools/nolibc: powerpc: limit stack-protector workaround to GCC", " - selftests/nolibc: avoid passing NULL to printf(\"%s\")", " - x86/syscall: Avoid memcpy() for ia32 syscall_get_arguments()", " - ASoC: Intel: boards: always check the result of", " acpi_dev_get_first_match_dev()", " - hwmon: (nct6775) add G15CF to ASUS WMI monitoring list", " - pmdomain: core: Don't hold the genpd-lock when calling dev_pm_domain_set()", " - pmdomain: core: Use dev_name() instead of kobject_get_path() in debugfs", " - rcuscale: Provide clear error when async specified without primitives", " - power: reset: brcmstb: Do not go into infinite loop if reset fails", " - iommu/arm-smmu-v3: Match Stall behaviour for S2", " - iommu/vt-d: Always reserve a domain ID for identity setup", " - iommu/vt-d: Unconditionally flush device TLB for pasid table updates", " - iommu/arm-smmu-v3: Do not use devm for the cd table allocations", " - drm/amdgpu: disallow multiple BO_HANDLES chunks in one submit", " - drm/amd/display: Use gpuvm_min_page_size_kbytes for DML2 surfaces", " - ata: pata_serverworks: Do not use the term blacklist", " - ata: sata_sil: Rename sil_blacklist to sil_quirks", " - selftests/bpf: fix uprobe.path leak in bpf_testmod", " - scsi: smartpqi: Add new controller PCI IDs", " - HID: Ignore battery for all ELAN I2C-HID devices", " - drm/amd/display: Underflow Seen on DCN401 eGPU", " - drm/xe: Name and document Wa_14019789679", " - jfs: UBSAN: shift-out-of-bounds in dbFindBits", " - scsi: smartpqi: correct stream detection", " - scsi: smartpqi: add new controller PCI IDs", " - drm/amdgpu: add raven1 gfxoff quirk", " - drm/amdgpu: enable gfxoff quirk on HP 705G4", " - drm/amdkfd: Fix resource leak in criu restore queue", " - HID: multitouch: Add support for Thinkpad X12 Gen 2 Kbd Portfolio", " - platform/x86: touchscreen_dmi: add nanote-next quirk", " - platform/x86/amd: pmf: Add quirk for TUF Gaming A14", " - drm/stm: ltdc: reset plane transparency after plane disable", " - drm/amdgpu/gfx12: properly handle error ints on all pipes", " - drm/amdgpu/gfx9: properly handle error ints on all pipes", " - drm/amd/display: Fix possible overflow in integer multiplication", " - drm/printer: Allow NULL data in devcoredump printer", " - perf,x86: avoid missing caller address in stack traces captured in uprobe", " - scsi: aacraid: Rearrange order of struct aac_srb_unit", " - scsi: lpfc: Fix unsolicited FLOGI kref imbalance when in direct attached", " topology", " - scsi: lpfc: Update PRLO handling in direct attached topology", " - drm/amd/display: Force enable 3DLUT DMA check for dcn401 in DML", " - drm/amdgpu: fix unchecked return value warning for amdgpu_gfx", " - drm/amdgpu: fix unchecked return value warning for amdgpu_atombios", " - perf: Fix event_function_call() locking", " - scsi: NCR5380: Initialize buffer for MSG IN and STATUS transfers", " - drm/radeon/r100: Handle unknown family in r100_cp_init_microcode()", " - drm/amd/display: Unlock Pipes Based On DET Allocation", " - drm/amdgpu: fix ptr check warning in gfx9 ip_dump", " - drm/amdgpu: fix ptr check warning in gfx10 ip_dump", " - drm/amdgpu: fix ptr check warning in gfx11 ip_dump", " - drm/amdgpu: Block MMR_READ IOCTL in reset", " - drm/amdgpu/gfx9: use rlc safe mode for soft recovery", " - drm/amdgpu/gfx11: enter safe mode before touching CP_INT_CNTL", " - drm/xe: Use topology to determine page fault queue size", " - drm/amdkfd: Check int source id for utcl2 poison event", " - of/irq: Refer to actual buffer size in of_irq_parse_one()", " - drm/amd/display: guard write a 0 post_divider value to HW", " - powerpc/pseries: Use correct data types from pseries_hp_errorlog struct", " - ovl: fsync after metadata copy-up", " - drm/amdgpu/gfx12: use rlc safe mode for soft recovery", " - drm/amdgpu/gfx11: use rlc safe mode for soft recovery", " - drm/amdgpu/gfx10: use rlc safe mode for soft recovery", " - platform/x86: lenovo-ymc: Ignore the 0x0 state", " - tools/hv: Add memory allocation check in hv_fcopy_start", " - HID: i2c-hid: ensure various commands do not interfere with each other", " - platform/mellanox: mlxbf-pmc: fix lockdep warning", " - platform/x86: x86-android-tablets: Adjust Xiaomi Pad 2 bottom bezel touch", " buttons LED", " - bpf: Make the pointer returned by iter next method valid", " - ext4: ext4_search_dir should return a proper error", " - bpftool: Fix undefined behavior caused by shifting into the sign bit", " - iomap: handle a post-direct I/O invalidate race in", " iomap_write_delalloc_release", " - EINJ, CXL: Fix CXL device SBDF calculation", " - spi: spi-imx: Fix pm_runtime_set_suspended() with runtime pm enabled", " - spi: spi-cadence: Fix pm_runtime_set_suspended() with runtime pm enabled", " - spi: spi-cadence: Fix missing spi_controller_is_target() check", " - selftest: hid: add missing run-hid-tools-tests.sh", " - spi: s3c64xx: fix timeout counters in flush_fifo", " - kselftest/devices/probe: Fix SyntaxWarning in regex strings for Python3", " - selftests: breakpoints: use remaining time to check if suspend succeed", " - accel/ivpu: Add missing MODULE_FIRMWARE metadata", " - spi: rpc-if: Add missing MODULE_DEVICE_TABLE", " - ALSA: control: Fix power_ref lock order for compat code, too", " - perf callchain: Fix stitch LBR memory leaks", " - perf: Really fix event_function_call() locking", " - drm/xe: fixup xe_alloc_pf_queue", " - drm/xe: Fix memory leak on xe_alloc_pf_queue failure", " - selftests: vDSO: fix vDSO name for powerpc", " - selftests: vDSO: fix vdso_config for powerpc", " - selftests: vDSO: fix vDSO symbols lookup for powerpc64", " - ext4: fix error message when rejecting the default hash", " - selftests/mm: fix charge_reserved_hugetlb.sh test", " - nvme-tcp: fix link failure for TCP auth", " - f2fs: add write priority option based on zone UFS", " - powerpc/vdso: Fix VDSO data access when running in a non-root time namespace", " - selftests: vDSO: fix ELF hash table entry size for s390x", " - selftests: vDSO: fix vdso_config for s390", " - f2fs: make BG GC more aggressive for zoned devices", " - f2fs: introduce migration_window_granularity", " - f2fs: increase BG GC migration window granularity when boosted for zoned", " devices", " - f2fs: do FG_GC when GC boosting is required for zoned devices", " - f2fs: forcibly migrate to secure space for zoned device file pinning", " - Revert \"ALSA: hda: Conditionally use snooping for AMD HDMI\"", " - KVM: arm64: Fix kvm_has_feat*() handling of negative features", " - i2c: qcom-geni: Use IRQF_NO_AUTOEN flag in request_irq()", " - i2c: xiic: Wait for TX empty to avoid missed TX NAKs", " - i2c: core: Lock address during client device instantiation", " - i2c: xiic: Fix pm_runtime_set_suspended() with runtime pm enabled", " - i2c: designware: fix controller is holding SCL low while ENABLE bit is", " disabled", " - i2c: synquacer: Deal with optional PCLK correctly", " - rust: sync: require `T: Sync` for `LockedBy::access`", " - ovl: fail if trusted xattrs are needed but caller lacks permission", " - firmware: tegra: bpmp: Drop unused mbox_client_to_bpmp()", " - memory: tegra186-emc: drop unused to_tegra186_emc()", " - dt-bindings: clock: exynos7885: Fix duplicated binding", " - spi: bcm63xx: Fix module autoloading", " - spi: bcm63xx: Fix missing pm_runtime_disable()", " - power: supply: hwmon: Fix missing temp1_max_alarm attribute", " - power: supply: Drop use_cnt check from power_supply_property_is_writeable()", " - perf/core: Fix small negative period being ignored", " - drm/v3d: Prevent out of bounds access in performance query extensions", " - parisc: Fix itlb miss handler for 64-bit programs", " - drm/mediatek: ovl_adaptor: Add missing of_node_put()", " - drm: Consistently use struct drm_mode_rect for FB_DAMAGE_CLIPS", " - ALSA: hda/tas2781: Add new quirk for Lenovo Y990 Laptop", " - ALSA: core: add isascii() check to card ID generator", " - ALSA: usb-audio: Add delay quirk for VIVO USB-C HEADSET", " - ALSA: usb-audio: Add native DSD support for Luxman D-08u", " - ALSA: line6: add hw monitor volume control to POD HD500X", " - ALSA: hda/realtek: fix mute/micmute LED for HP mt645 G8", " - ALSA: hda/realtek: Add quirk for Huawei MateBook 13 KLV-WX9", " - ALSA: hda/realtek: Add a quirk for HP Pavilion 15z-ec200", " - ext4: correct encrypted dentry name hash when not casefolded", " - ext4: propagate errors from ext4_find_extent() in ext4_insert_range()", " - ext4: fix incorrect tid assumption in ext4_fc_mark_ineligible()", " - ext4: fix incorrect tid assumption in __jbd2_log_wait_for_space()", " - ext4: fix incorrect tid assumption in ext4_wait_for_tail_page_commit()", " - ext4: fix incorrect tid assumption in jbd2_journal_shrink_checkpoint_list()", " - ext4: fix fast commit inode enqueueing during a full journal commit", " - ext4: use handle to mark fc as ineligible in __track_dentry_update()", " - ext4: mark fc as ineligible using an handle in ext4_xattr_set()", " - parisc: Fix 64-bit userspace syscall path", " - parisc: Allow mmap(MAP_STACK) memory to automatically expand upwards", " - parisc: Fix stack start for ADDR_NO_RANDOMIZE personality", " - drm/rockchip: vop: clear DMA stop bit on RK3066", " - of: address: Report error on resource bounds overflow", " - of/irq: Support #msi-cells=<0> in of_msi_get_domain", " - lib/buildid: harden build ID parsing logic", " - jbd2: correctly compare tids with tid_geq function in jbd2_fc_begin_commit", " - mm: krealloc: consider spare memory for __GFP_ZERO", " - ocfs2: fix the la space leak when unmounting an ocfs2 volume", " - ocfs2: fix uninit-value in ocfs2_get_block()", " - scripts/gdb: fix timerlist parsing issue", " - scripts/gdb: add iteration function for rbtree", " - scripts/gdb: fix lx-mounts command error", " - arm64: fix selection of HAVE_DYNAMIC_FTRACE_WITH_ARGS", " - arm64: Subscribe Microsoft Azure Cobalt 100 to erratum 3194386", " - drm/xe/oa: Don't reset OAC_CONTEXT_ENABLE on OA stream close", " - sched/deadline: Comment sched_dl_entity::dl_server variable", " - sched/core: Add clearing of ->dl_server in put_prev_task_balance()", " - sched/core: Clear prev->dl_server in CFS pick fast path", " - sched: psi: fix bogus pressure spikes from aggregation race", " - riscv: define ILLEGAL_POINTER_VALUE for 64bit", " - [Config] updateconfigs for ILLEGAL_POINTER_VALUE on riscv", " - perf python: Disable -Wno-cast-function-type-mismatch if present on clang", " - perf hist: Update hist symbol when updating maps", " - nfsd: fix delegation_blocked() to block correctly for at least 30 seconds", " - NFSD: Fix NFSv4's PUTPUBFH operation", " - sysctl: avoid spurious permanent empty tables", " - RDMA/mana_ib: use the correct page table index based on hardware page size", " - RDMA/mana_ib: use the correct page size for mapping user-mode doorbell page", " - drivers/perf: riscv: Align errno for unsupported perf event", " - riscv: Fix kernel stack size when KASAN is enabled", " - media: imx335: Fix reset-gpio handling", " - clk: rockchip: fix error for unknown clocks", " - leds: pca9532: Remove irrelevant blink configuration error message", " - media: videobuf2: Drop minimum allocation requirement of 2 buffers", " - clk: qcom: dispcc-sm8250: use CLK_SET_RATE_PARENT for branch clocks", " - media: sun4i_csi: Implement link validate for sun4i_csi subdev", " - clk: qcom: gcc-sm8450: Do not turn off PCIe GDSCs during gdsc_disable()", " - media: uapi/linux/cec.h: cec_msg_set_reply_to: zero flags", " - dt-bindings: clock: qcom: Add GPLL9 support on gcc-sc8180x", " - clk: qcom: gcc-sc8180x: Register QUPv3 RCGs for DFS on sc8180x", " - clk: qcom: clk-rpmh: Fix overflow in BCM vote", " - clk: samsung: exynos7885: Update CLKS_NR_FSYS after bindings fix", " - clk: qcom: gcc-sm8150: De-register gcc_cpuss_ahb_clk_src", " - clk: qcom: gcc-sm8250: Do not turn off PCIe GDSCs during gdsc_disable()", " - clk: qcom: gcc-sc8180x: Add GPLL9 support", " - clk: qcom: gcc-sc8180x: Fix the sdcc2 and sdcc4 clocks freq table", " - clk: qcom: clk-alpha-pll: Fix CAL_L_VAL override for LUCID EVO PLL", " - drm/amd/display: avoid set dispclk to 0", " - smb: client: use actual path when queryfs", " - smb3: fix incorrect mode displayed for read-only files", " - iio: magnetometer: ak8975: Fix reading for ak099xx sensors", " - iio: pressure: bmp280: Fix regmap for BMP280 device", " - iio: pressure: bmp280: Fix waiting time for BMP3xx configuration", " - tomoyo: fallback to realpath if symlink's pathname does not exist", " - kselftests: mm: fix wrong __NR_userfaultfd value", " - rtc: at91sam9: fix OF node leak in probe() error path", " - mm/hugetlb: fix memfd_pin_folios resv_huge_pages leak", " - mm/gup: fix memfd_pin_folios hugetlb page allocation", " - mm/hugetlb: simplify refs in memfd_alloc_folio", " - Input: adp5589-keys - fix adp5589_gpio_get_value()", " - HID: bpf: fix cfi stubs for hid_bpf_ops", " - pidfs: check for valid pid namespace", " - ACPI: video: Add backlight=native quirk for Dell OptiPlex 5480 AIO", " - ACPI: resource: Remove duplicate Asus E1504GAB IRQ override", " - ACPI: resource: Loosen the Asus E1404GAB DMI match to also cover the E1404GA", " - ACPI: resource: Add Asus Vivobook X1704VAP to irq1_level_low_skip_override[]", " - ACPI: resource: Add Asus ExpertBook B2502CVA to", " irq1_level_low_skip_override[]", " - btrfs: drop the backref cache during relocation if we commit", " - btrfs: send: fix invalid clone operation for file that got its size", " decreased", " - cpufreq: intel_pstate: Make hwp_notify_lock a raw spinlock", " - gpio: davinci: fix lazy disable", " - net: pcs: xpcs: fix the wrong register that was written back", " - Bluetooth: hci_event: Align BR/EDR JUST_WORKS paring with LE", " - io_uring/net: harden multishot termination case for recv", " - ceph: fix cap ref leak via netfs init_request", " - tracing/hwlat: Fix a race during cpuhp processing", " - tracing/timerlat: Fix duplicated kthread creation due to CPU online/offline", " - rtla: Fix the help text in osnoise and timerlat top tools", " - firmware/sysfb: Disable sysfb for firmware buffers with unknown parent", " - close_range(): fix the logics in descriptor table trimming", " - drm/i915/gem: fix bitwise and logical AND mixup", " - drm/panthor: Don't add write fences to the shared BOs", " - drm/panthor: Don't declare a queue blocked if deferred operations are", " pending", " - drm/sched: Fix dynamic job-flow control race", " - drm/sched: Add locking to drm_sched_entity_modify_sched", " - drm/sched: Always wake up correct scheduler in drm_sched_entity_push_job", " - drm/sched: Always increment correct scheduler score", " - drm/amd/display: Restore Optimized pbn Value if Failed to Disable DSC", " - drm/amd/display: Add HDR workaround for specific eDP", " - drm/amd/display: Enable idle workqueue for more IPS modes", " - kconfig: fix infinite loop in sym_calc_choice()", " - kconfig: qconf: move conf_read() before drawing tree pain", " - kconfig: qconf: fix buffer overflow in debug links", " - arm64: cputype: Add Neoverse-N3 definitions", " - arm64: errata: Expand speculative SSBS workaround once more", " - mm: z3fold: deprecate CONFIG_Z3FOLD", " - [Config] updateconfigs after deprecating Z3FOLD", " - drm/amd/display: Allow backlight to go below", " `AMDGPU_DM_DEFAULT_MIN_BACKLIGHT`", " - sunrpc: change sp_nrthreads from atomic_t to unsigned int.", " - NFSD: Async COPY result needs to return a write verifier", " - remoteproc: k3-r5: Acquire mailbox handle during probe routine", " - remoteproc: k3-r5: Delay notification of wakeup event", " - r8169: Fix spelling mistake: \"tx_underun\" -> \"tx_underrun\"", " - ACPI: battery: Simplify battery hook locking", " - drm/xe: Clean up VM / exec queue file lock usage.", " - drm/rockchip: vop: enable VOP_FEATURE_INTERNAL_RGB on RK3066", " - drm/xe/vram: fix ccs offset calculation", " - drm/sched: revert \"Always increment correct scheduler score\"", " - ALSA: control: Fix leftover snd_power_unref()", " - crypto: octeontx* - Select CRYPTO_AUTHENC", " - drm/amd/display: Revert Avoid overflow assignment", " - perf report: Fix segfault when 'sym' sort key is not used", " - pmdomain: core: Reduce debug summary table width", " - perf python: Allow checking for the existence of warning options in clang", " - Linux 6.11.3", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49863", " - vhost/scsi: null-ptr-dereference in vhost_scsi_get_req()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49864", " - rxrpc: Fix a race between socket set up and I/O thread creation", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49865", " - drm/xe/vm: move xa_alloc to prevent UAF", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49955", " - ACPI: battery: Fix possible crash when unregistering a battery hook", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49973", " - r8169: add tally counter fields added with RTL8125", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49974", " - NFSD: Limit the number of concurrent async COPY operations", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49975", " - uprobes: fix kernel info leak via \"[uprobes]\" vma", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50003", " - drm/amd/display: Fix system hang while resume with TBT monitor", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50173", " - drm/panthor: Fix access to uninitialized variable in tick_ctx_cleanup()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49866", " - tracing/timerlat: Fix a race during cpuhp processing", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49976", " - tracing/timerlat: Drop interface_lock in stop_kthread()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50005", " - mac802154: Fix potential RCU dereference issue in mac802154_scan_worker", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50012", " - cpufreq: Avoid a bad reference count on CPU node", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49867", " - btrfs: wait for fixup workers before stopping cleaner kthread during umount", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49868", " - btrfs: fix a NULL pointer dereference when failed to start a new trasacntion", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49869", " - btrfs: send: fix buffer overflow detection when copying path to cache entry", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49870", " - cachefiles: fix dentry leak in cachefiles_open_file()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49871", " - Input: adp5589-keys - fix NULL pointer dereference", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49872", " - mm/gup: fix memfd_pin_folios alloc race panic", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49964", " - mm/hugetlb: fix memfd_pin_folios free_huge_pages leak", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49873", " - mm/filemap: fix filemap_get_folios_contig THP panic", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49977", " - net: stmmac: Fix zero-division error when disabling tc cbs", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49978", " - gso: fix udp gso fraglist segmentation after pull from frag_list", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49979", " - net: gso: fix tcp fraglist segmentation after pull from frag_list", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49980", " - vrf: revert \"vrf: Remove unnecessary RCU-bh critical section\"", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49981", " - media: venus: fix use after free bug in venus_remove due to race condition", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49956", " - gfs2: fix double destroy_workqueue error", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50176", " - remoteproc: k3-r5: Fix error handling when power-up failed", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49982", " - aoe: fix the potential use-after-free problem in more places", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49874", " - i3c: master: svc: Fix use after free vulnerability in svc_i3c_master Driver", " Due to Race Condition", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49875", " - nfsd: map the EBADMSG to nfserr_io to avoid warning", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50013", " - exfat: fix memory leak in exfat_load_bitmap()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49876", " - drm/xe: fix UAF around queue destruction", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49877", " - ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49957", " - ocfs2: fix null-ptr-deref when journal load failed.", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49965", " - ocfs2: remove unreasonable unlock in ocfs2_read_blocks", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49966", " - ocfs2: cancel dqi_sync_work before freeing oinfo", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49958", " - ocfs2: reserve space for inline xattr before attaching reflink tree", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49959", " - jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49878", " - resource: fix region_intersects() vs add_memory_driver_managed()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49879", " - drm: omapdrm: Add missing check for alloc_ordered_workqueue", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49880", " - ext4: fix off by one issue in alloc_flex_gd()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49881", " - ext4: update orig_path in ext4_find_extent()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50014", " - ext4: fix access to uninitialised lock in fc replay path", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49960", " - ext4: fix timer use-after-free on failed mount", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49882", " - ext4: fix double brelse() the buffer of the extents path", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49883", " - ext4: aovid use-after-free in ext4_ext_insert_extent()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49983", " - ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-free", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50015", " - ext4: dax: fix overflowing extents beyond inode size when partially writing", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49884", " - ext4: fix slab-use-after-free in ext4_split_extent_at()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49885", " - mm, slub: avoid zeroing kmalloc redzone", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49961", " - media: i2c: ar0521: Use cansleep version of gpiod_set_value()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49985", " - i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49886", " - platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bug", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49986", " - platform/x86: x86-android-tablets: Fix use after free on", " platform_device_register() errors", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49887", " - f2fs: fix to don't panic system for no free segment fault injection", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49888", " - bpf: Fix a sdiv overflow issue", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49987", " - bpftool: Fix undefined behavior in qsort(NULL, 0, ...)", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50006", " - ext4: fix i_data_sem unlock order in ext4_ind_migrate()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49889", " - ext4: avoid use-after-free in ext4_ext_show_leaf()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49968", " - ext4: filesystems without casefold feature cannot be mounted with siphash", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49988", " - ksmbd: add refcnt to ksmbd_conn struct", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49890", " - drm/amd/pm: ensure the fw_info is not null before using it", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49891", " - scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata", " paths", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49892", " - drm/amd/display: Initialize get_bytes_per_element's default to 1", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50016", " - drm/amd/display: Avoid overflow assignment in link_dp_cts", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49893", " - drm/amd/display: Check stream_status before it is used", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49969", " - drm/amd/display: Fix index out of bounds in DCN30 color transformation", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49970", " - drm/amd/display: Implement bounds check for stream encoder creation in", " DCN401", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49894", " - drm/amd/display: Fix index out of bounds in degamma hardware format", " translation", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49895", " - drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format", " translation", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49971", " - drm/amd/display: Increase array size of dummy_boolean", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49972", " - drm/amd/display: Deallocate DML memory if allocation fails", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49896", " - drm/amd/display: Check stream before comparing them", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49897", " - drm/amd/display: Check phantom_stream before it is used", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49898", " - drm/amd/display: Check null-initialized variables", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49899", " - drm/amd/display: Initialize denominators' default to 1", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49900", " - jfs: Fix uninit-value access of new_ea in ea_buffer", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49901", " - drm/msm/adreno: Assign msm_gpu->pdev earlier to avoid nullptrs", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49902", " - jfs: check if leafidx greater than num leaves per dmap tree", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49903", " - jfs: Fix uaf in dbFreeBits", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49904", " - drm/amdgpu: add list empty check to avoid null pointer issue", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49989", " - drm/amd/display: fix double free issue during amdgpu module unload", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49905", " - drm/amd/display: Add null check for 'afb' in", " amdgpu_dm_plane_handle_cursor_update (v2)", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49906", " - drm/amd/display: Check null pointer before try to access it", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49907", " - drm/amd/display: Check null pointers before using dc->clk_mgr", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49908", " - drm/amd/display: Add null check for 'afb' in amdgpu_dm_update_cursor (v2)", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50177", " - drm/amd/display: fix a UBSAN warning in DML2.1", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49909", " - drm/amd/display: Add NULL check for function pointer in", " dcn32_set_output_transfer_func", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49910", " - drm/amd/display: Add NULL check for function pointer in", " dcn401_set_output_transfer_func", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49911", " - drm/amd/display: Add NULL check for function pointer in", " dcn20_set_output_transfer_func", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49912", " - drm/amd/display: Handle null 'stream_status' in", " 'planes_changed_for_existing_stream'", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49913", " - drm/amd/display: Add null check for top_pipe_to_program in", " commit_planes_for_stream", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49914", " - drm/amd/display: Add null check for pipe_ctx->plane_state in", " dcn20_program_pipe", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49915", " - drm/amd/display: Add NULL check for clk_mgr in dcn32_init_hw", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49916", " - drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in", " dcn401_init_hw", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49917", " - drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in", " dcn30_init_hw", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49918", " - drm/amd/display: Add null check for head_pipe in", " dcn32_acquire_idle_pipe_for_head_pipe_in_layer", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49919", " - drm/amd/display: Add null check for head_pipe in", " dcn201_acquire_free_pipe_for_layer", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49991", " - drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49920", " - drm/amd/display: Check null pointers before multiple uses", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49921", " - drm/amd/display: Check null pointers before used", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49922", " - drm/amd/display: Check null pointers before using them", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49923", " - drm/amd/display: Pass non-null to dcn20_validate_apply_pipe_split_flags", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49992", " - drm/stm: Avoid use-after-free issues with crtc and plane", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49993", " - iommu/vt-d: Fix potential lockup if qi_submit_sync called with 0 count", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49924", " - fbdev: pxafb: Fix possible use after free in pxafb_task()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49925", " - fbdev: efifb: Register sysfs groups through driver core", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49926", " - rcu-tasks: Fix access non-existent percpu rtpcp variable in", " rcu_tasks_need_gpcb()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50007", " - ALSA: asihpi: Fix potential OOB array access", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50017", " - x86/mm/ident_map: Use gbpages only where full GB page should be mapped.", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49927", " - x86/ioapic: Handle allocation failures gracefully", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50008", " - wifi: mwifiex: Fix memcpy() field-spanning write warning in", " mwifiex_cmd_802_11_scan_ext()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50018", " - net: napi: Prevent overflow of napi_defer_hard_irqs", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49928", " - wifi: rtw89: avoid reading out of bounds when loading TX power FW elements", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50178", " - cpufreq: loongson3: Use raw_smp_processor_id() in do_service_request()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50009", " - cpufreq: amd-pstate: add check for cpufreq_cpu_get's return value", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49994", " - block: fix integer overflow in BLKSECDISCARD", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49929", " - wifi: iwlwifi: mvm: avoid NULL pointer dereference", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49995", " - tipc: guard against string buffer overrun", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49962", " - ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in", " acpi_db_convert_to_package()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49930", " - wifi: ath11k: fix array out-of-bound access in SoC stats", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49931", " - wifi: ath12k: fix array out-of-bound access in SoC stats", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49932", " - btrfs: don't readahead the relocation inode on RST", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49933", " - blk_iocost: fix more out of bound shifts", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49934", " - fs/inode: Prevent dump_mapping() accessing invalid dentry.d_name.name", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50010", " - exec: don't WARN for racy path_noexec check", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49935", " - ACPI: PAD: fix crash in exit_round_robin()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49936", " - net/xen-netback: prevent UAF in xenvif_flush_hash()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49937", " - wifi: cfg80211: Set correct chandef when starting CAC", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49938", " - wifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmit", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49939", " - wifi: rtw89: avoid to add interface to list twice when SER", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49940", " - l2tp: prevent possible tunnel refcount underflow", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49941", " - gpiolib: Fix potential NULL pointer dereference in gpiod_get_label()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49996", " - cifs: Fix buffer overflow when parsing NFS reparse points", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49942", " - drm/xe: Prevent null pointer access in xe_migrate_copy", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49943", " - drm/xe/guc_submit: add missing locking in wedged_fini", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50011", " - ASoC: Intel: soc-acpi-intel-rpl-match: add missing empty item", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50174", " - drm/panthor: Fix race when converting group handle to group object", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49944", " - sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_start", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49945", " - net/ncsi: Disable the ncsi work before freeing the associated structure", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49946", " - ppp: do not assume bh is held in ppp_channel_bridge_input()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49947", " - net: test for not too small csum_start in virtio_net_hdr_to_skb()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49948", " - net: add more sanity checks to qdisc_pkt_len_init()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49949", " - net: avoid potential underflow in qdisc_pkt_len_init() with UFO", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49997", " - net: ethernet: lantiq_etop: fix memory disclosure", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49998", " - net: dsa: improve shutdown sequence", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49999", " - afs: Fix the setting of the server responding flag", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49950", " - Bluetooth: L2CAP: Fix uaf in l2cap_connect", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49951", " - Bluetooth: MGMT: Fix possible crash on mgmt_index_removed", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49952", " - netfilter: nf_tables: prevent nf_skb_duplicated corruption", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49953", " - net/mlx5e: Fix crash caused by calling __xfrm_state_delete() twice", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50000", " - net/mlx5e: Fix NULL deref in mlx5e_tir_builder_alloc()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50001", " - net/mlx5: Fix error path in multi-packet WQE transmit", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50179", " - ceph: remove the incorrect Fw reference check when dirtying pages", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49963", " - mailbox: bcm2835: Fix timeout during suspend mode", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49954", " - static_call: Replace pointless WARN_ON() in static_call_module_notify()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50002", " - static_call: Handle module init failure correctly in", " static_call_del_module()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033)", " - EDAC/synopsys: Fix error injection on Zynq UltraScale+", " - crypto: xor - fix template benchmarking", " - crypto: qat - disable IOV in adf_dev_stop()", " - crypto: qat - fix recovery flow for VFs", " - crypto: qat - ensure correct order in VF restarting handler", " - ACPI: PMIC: Remove unneeded check in tps68470_pmic_opregion_probe()", " - eth: fbnic: select DEVLINK and PAGE_POOL", " - wifi: brcmfmac: introducing fwil query functions", " - wifi: ath9k: Remove error checks when creating debugfs entries", " - wifi: ath12k: fix BSS chan info request WMI command", " - wifi: ath12k: match WMI BSS chan info structure with firmware definition", " - wifi: ath12k: fix invalid AMPDU factor calculation in", " ath12k_peer_assoc_h_he()", " - hwrng: cn10k - Enable by default CN10K driver if Thunder SoC is enabled", " - crypto: x86/aes-gcm - fix PREEMPT_RT issue in gcm_crypt()", " - net: stmmac: dwmac-loongson: Init ref and PTP clocks rate", " - virtio: rename virtio_config_enabled to virtio_config_core_enabled", " - virtio: allow driver to disable the configure change notification", " - virtio-net: synchronize operstate with admin state on up/down", " - virtio-net: synchronize probe with ndo_set_features", " - arm64: signal: Fix some under-bracketed UAPI macros", " - wifi: rtw88: remove CPT execution branch never used", " - RISC-V: KVM: Fix sbiret init before forwarding to userspace", " - RISC-V: KVM: Allow legacy PMU access from guest", " - RISC-V: KVM: Fix to allow hpmcounter31 from the guest", " - mount: handle OOM on mnt_warn_timestamp_expiry", " - autofs: fix missing fput for FSCONFIG_SET_FD", " - netfilter: nf_tables: store new sets in dedicated list", " - wifi: rtw89: limit the PPDU length for VHT rate to 0x40000", " - kselftest/arm64: signal: fix/refactor SVE vector length enumeration", " - arm64: smp: smp_send_stop() and crash_smp_send_stop() should try non-NMI", " first", " - thermal: core: Fold two functions into their respective callers", " - thermal: core: Fix rounding of delay jiffies", " - perf/dwc_pcie: Fix registration issue in multi PCIe controller instances", " - perf/dwc_pcie: Always register for PCIe bus notifier", " - crypto: qat - fix \"Full Going True\" macro definition", " - ACPI: video: force native for Apple MacbookPro9,2", " - wifi: mac80211_hwsim: correct MODULE_PARM_DESC of multi_radio", " - wifi: iwlwifi: config: label 'gl' devices as discrete", " - wifi: iwlwifi: mvm: increase the time between ranging measurements", " - wifi: cfg80211: fix bug of mapping AF3x to incorrect User Priority", " - wifi: mac80211: fix the comeback long retry times", " - wifi: iwlwifi: mvm: allow ESR when we the ROC expires", " - wifi: mac80211: Check for missing VHT elements only for 5 GHz", " - ACPICA: Implement ACPI_WARNING_ONCE and ACPI_ERROR_ONCE", " - ACPICA: executer/exsystem: Don't nag user about every Stall() violating the", " spec", " - padata: Honor the caller's alignment in case of chunk_size 0", " - drivers/perf: hisi_pcie: Record hardware counts correctly", " - drivers/perf: hisi_pcie: Fix TLP headers bandwidth counting", " - kselftest/arm64: Actually test SME vector length changes via sigreturn", " - can: j1939: use correct function name in comment", " - wifi: rtw89: wow: fix wait condition for AOAC report request", " - ACPI: CPPC: Fix MASK_VAL() usage", " - netfilter: nf_tables: elements with timeout below CONFIG_HZ never expire", " - netfilter: nf_tables: reject element expiration with no timeout", " - netfilter: nf_tables: reject expiration higher than timeout", " - netfilter: nf_tables: remove annotation to access set timeout while holding", " lock", " - netfilter: nft_dynset: annotate data-races around set timeout", " - perf/arm-cmn: Refactor node ID handling. Again.", " - perf/arm-cmn: Fix CCLA register offset", " - perf/arm-cmn: Ensure dtm_idx is big enough", " - cpufreq: ti-cpufreq: Introduce quirks to handle syscon fails appropriately", " - thermal: gov_bang_bang: Adjust states of all uninitialized instances", " - wifi: mt76: mt7921: fix wrong UNII-4 freq range check for the channel usage", " - wifi: mt76: mt7996: fix traffic delay when switching back to working channel", " - wifi: mt76: mt7996: fix wmm set of station interface to 3", " - wifi: mt76: mt7996: fix HE and EHT beamforming capabilities", " - wifi: mt76: mt7996: fix EHT beamforming capability check", " - pm:cpupower: Add missing powercap_set_enabled() stub function", " - crypto: ccp - do not request interrupt on cmd completion when irqs disabled", " - crypto: hisilicon/hpre - mask cluster timeout error", " - crypto: hisilicon/qm - reset device before enabling it", " - wifi: mt76: mt7996: fix handling mbss enable/disable", " - wifi: mt76: connac: fix checksum offload fields of connac3 RXD", " - wifi: mt76: mt7603: fix mixed declarations and code", " - wifi: cfg80211: fix UBSAN noise in cfg80211_wext_siwscan()", " - wifi: mt76: mt7915: fix rx filter setting for bfee functionality", " - wifi: mt76: mt7996: fix uninitialized TLV data", " - wifi: cfg80211: fix two more possible UBSAN-detected off-by-one errors", " - af_unix: Don't call skb_get() for OOB skb.", " - af_unix: Remove single nest in manage_oob().", " - af_unix: Rename unlinked_skb in manage_oob().", " - af_unix: Move spin_lock() in manage_oob().", " - Bluetooth: hci_core: Fix sending MGMT_EV_CONNECT_FAILED", " - Bluetooth: hci_sync: Ignore errors from HCI_OP_REMOTE_NAME_REQ_CANCEL", " - can: m_can: enable NAPI before enabling interrupts", " - can: m_can: m_can_close(): stop clocks after device has been shut down", " - Bluetooth: btusb: Fix not handling ZPL/short-transfer", " - bareudp: Pull inner IP header in bareudp_udp_encap_recv().", " - bareudp: Pull inner IP header on xmit.", " - net: enetc: Use IRQF_NO_AUTOEN flag in request_irq()", " - crypto: n2 - Set err to EINVAL if snprintf fails for hmac", " - xsk: fix batch alloc API on non-coherent systems", " - net: ipv6: rpl_iptunnel: Fix memory leak in rpl_input", " - fbnic: Set napi irq value after calling netif_napi_add", " - net: tipc: avoid possible garbage value", " - ublk: move zone report data out of request pdu", " - block, bfq: choose the last bfqq from merge chain in bfq_setup_cooperator()", " - block, bfq: don't break merge chain in bfq_split_bfqq()", " - cachefiles: Fix non-taking of sb_writers around set/removexattr", " - nbd: correct the maximum value for discard sectors", " - erofs: fix incorrect symlink detection in fast symlink", " - erofs: fix error handling in z_erofs_init_decompressor", " - block, bfq: fix uaf for accessing waker_bfqq after splitting", " - block, bfq: fix procress reference leakage for bfqq in merge chain", " - io_uring/io-wq: do not allow pinning outside of cpuset", " - io_uring/io-wq: inherit cpuset of cgroup in io worker", " - spi: ppc4xx: handle irq_of_parse_and_map() errors", " - arm64: dts: exynos: exynos7885-jackpotlte: Correct RAM amount to 4GB", " - arm64: dts: mediatek: mt8186: Fix supported-hw mask for GPU OPPs", " - spi: ppc4xx: Avoid returning 0 when failed to parse and map IRQ", " - firmware: qcom: scm: Disable SDI and write no dump to dump mode", " - regulator: Return actual error in of_regulator_bulk_get_all()", " - arm64: dts: renesas: r9a08g045: Correct GICD and GICR sizes", " - arm64: dts: renesas: r9a07g043u: Correct GICD and GICR sizes", " - arm64: dts: renesas: r9a07g054: Correct GICD and GICR sizes", " - arm64: dts: renesas: r9a07g044: Correct GICD and GICR sizes", " - ARM: dts: microchip: sam9x60: Fix rtc/rtt clocks", " - arm64: tegra: Correct location of power-sensors for IGX Orin", " - arm64: dts: rockchip: Correct vendor prefix for Hardkernel ODROID-M1", " - arm64: dts: ti: k3-j721e-sk: Fix reversed C6x carveout locations", " - arm64: dts: ti: k3-j721e-beagleboneai64: Fix reversed C6x carveout locations", " - spi: bcmbca-hsspi: Fix missing pm_runtime_disable()", " - arm64: dts: qcom: x1e80100: Fix PHY for DP2", " - ARM: dts: microchip: sama7g5: Fix RTT clock", " - ARM: dts: imx7d-zii-rmu2: fix Ethernet PHY pinctrl property", " - arm64: dts: ti: k3-am654-idk: Fix dtbs_check warning in ICSSG dmas", " - ARM: versatile: fix OF node leak in CPUs prepare", " - reset: berlin: fix OF node leak in probe() error path", " - reset: k210: fix OF node leak in probe() error path", " - platform: cznic: turris-omnia-mcu: Fix error check in", " omnia_mcu_register_trng()", " - clocksource/drivers/qcom: Add missing iounmap() on errors in", " msm_dt_timer_init()", " - arm64: dts: mediatek: mt8195: Correct clock order for dp_intf*", " - x86/mm: Use IPIs to synchronize LAM enablement", " - ASoC: rt5682s: Return devm_of_clk_add_hw_provider to transfer the error", " - ASoC: tas2781: Fix a compiling warning reported by robot kernel test due to", " adding tas2563_dvc_table", " - ASoC: tas2781-i2c: Drop weird GPIO code", " - ASoC: tas2781-i2c: Get the right GPIO line", " - selftests/ftrace: Add required dependency for kprobe tests", " - ALSA: hda: cs35l41: fix module autoloading", " - selftests/ftrace: Fix test to handle both old and new kernels", " - x86/boot/64: Strip percpu address space when setting up GDT descriptors", " - m68k: Fix kernel_clone_args.flags in m68k_clone()", " - ASoC: loongson: fix error release", " - selftests/ftrace: Fix eventfs ownership testcase to find mount point", " - selftests:resctrl: Fix build failure on archs without __cpuid_count()", " - cgroup/pids: Avoid spurious event notification", " - hwmon: (max16065) Fix overflows seen when writing limits", " - hwmon: (max16065) Fix alarm attributes", " - iommu/arm-smmu: Un-demote unhandled-fault msg", " - iommu/arm-smmu-v3: Fix a NULL vs IS_ERR() check", " - mtd: slram: insert break after errors in parsing the map", " - hwmon: (ntc_thermistor) fix module autoloading", " - power: supply: axp20x_battery: Remove design from min and max voltage", " - power: supply: max17042_battery: Fix SOC threshold calc w/ no current sense", " - fbdev: hpfb: Fix an error handling path in hpfb_dio_probe()", " - iommu/amd: Handle error path in amd_iommu_probe_device()", " - iommu/amd: Allocate the page table root using GFP_KERNEL", " - iommu/amd: Move allocation of the top table into v1_alloc_pgtable", " - iommu/amd: Set the pgsize_bitmap correctly", " - iommu/amd: Do not set the D bit on AMD v2 table entries", " - mtd: powernv: Add check devm_kasprintf() returned value", " - rcu/nocb: Fix RT throttling hrtimer armed from offline CPU", " - mtd: rawnand: mtk: Use for_each_child_of_node_scoped()", " - mtd: rawnand: mtk: Factorize out the logic cleaning mtk chips", " - mtd: rawnand: mtk: Fix init error path", " - iommu/arm-smmu-qcom: hide last LPASS SMMU context bank from linux", " - iommu/arm-smmu-qcom: Work around SDM845 Adreno SMMU w/ 16K pages", " - iommu/arm-smmu-qcom: apply num_context_bank fixes for SDM630 / SDM660", " - pmdomain: core: Harden inter-column space in debug summary", " - pmdomain: core: Fix \"managed by\" alignment in debug summary", " - drm/stm: Fix an error handling path in stm_drm_platform_probe()", " - drm/stm: ltdc: check memory returned by devm_kzalloc()", " - drm/amd/display: free bo used for dmub bounding box", " - drm/amdgpu: properly handle vbios fake edid sizing", " - drm/radeon: properly handle vbios fake edid sizing", " - drm/amd/display: Reset VRR config during resume", " - scsi: smartpqi: revert propagate-the-multipath-failure-to-SML-quickly", " - scsi: sd: Don't check if a write for REQ_ATOMIC", " - scsi: block: Don't check REQ_ATOMIC for reads", " - scsi: NCR5380: Check for phase match during PDMA fixup", " - drm/amd/amdgpu: Properly tune the size of struct", " - drm/amd/display: Improve FAM control for DCN401", " - drm/rockchip: vop: Allow 4096px width scaling", " - drm/rockchip: dw_hdmi: Fix reading EDID when using a forced mode", " - drm/radeon/evergreen_cs: fix int overflow errors in cs track offsets", " - drm/bridge: lontium-lt8912b: Validate mode in drm_bridge_funcs::mode_valid()", " - drm/vc4: hdmi: Handle error case of pm_runtime_resume_and_get", " - drm/mediatek: Fix missing configuration flags in mtk_crtc_ddp_config()", " - drm/mediatek: Use spin_lock_irqsave() for CRTC event lock", " - powerpc/8xx: Fix initial memory mapping", " - powerpc/8xx: Fix kernel vs user address comparison", " - powerpc/vdso: Inconditionally use CFUNC macro", " - drm/msm: Use a7xx family directly in gpu_state", " - drm/msm: Dump correct dbgahb clusters on a750", " - drm/msm: Fix CP_BV_DRAW_STATE_ADDR name", " - drm/msm: Fix incorrect file name output in adreno_request_fw()", " - drm/msm/a5xx: disable preemption in submits by default", " - drm/msm/a5xx: properly clear preemption records on resume", " - drm/msm/a5xx: fix races in preemption evaluation stage", " - drm/msm/a5xx: workaround early ring-buffer emptiness check", " - ipmi: docs: don't advertise deprecated sysfs entries", " - drm/msm/dp: enable widebus on all relevant chipsets", " - drm/msm/dsi: correct programming sequence for SM8350 / SM8450", " - drm/msm: fix %s null argument error", " - platform/x86: ideapad-laptop: Make the scope_guard() clear of its scope", " - kselftest: dt: Ignore nodes that have ancestors disabled", " - drivers:drm:exynos_drm_gsc:Fix wrong assignment in gsc_bind()", " - drm/amdgpu: fix invalid fence handling in amdgpu_vm_tlb_flush", " - xen: use correct end address of kernel for conflict checking", " - HID: wacom: Support sequence numbers smaller than 16-bit", " - HID: wacom: Do not warn about dropped packets for first packet", " - ata: libata: Clear DID_TIME_OUT for ATA PT commands with sense data", " - xen: introduce generic helper checking for memory map conflicts", " - xen: move max_pfn in xen_memory_setup() out of function scope", " - xen: add capability to remap non-RAM pages to different PFNs", " - xen: tolerate ACPI NVS memory overlapping with Xen allocated memory", " - drm/xe: fix missing 'xe_vm_put'", " - xen/swiotlb: add alignment check for dma buffers", " - xen/swiotlb: fix allocated size", " - sched/fair: Make SCHED_IDLE entity be preempted in strict hierarchy", " - bpf, x64: Fix tailcall hierarchy", " - bpf, arm64: Fix tailcall hierarchy", " - bpf: Fix compare error in function retval_range_within", " - selftests/bpf: Workaround strict bpf_lsm return value check.", " - selftests/bpf: Fix error linking uprobe_multi on mips", " - selftests/bpf: Fix wrong binary in Makefile log output", " - tools/runqslower: Fix LDFLAGS and add LDLIBS support", " - selftests/bpf: Use pid_t consistently in test_progs.c", " - selftests/bpf: Fix compile error from rlim_t in sk_storage_map.c", " - selftests/bpf: Fix error compiling bpf_iter_setsockopt.c with musl libc", " - selftests/bpf: Drop unneeded error.h includes", " - selftests/bpf: Fix missing ARRAY_SIZE() definition in bench.c", " - selftests/bpf: Fix missing UINT_MAX definitions in benchmarks", " - selftests/bpf: Fix missing BUILD_BUG_ON() declaration", " - selftests/bpf: Fix include of ", " - selftests/bpf: Fix compiling parse_tcp_hdr_opt.c with musl-libc", " - selftests/bpf: Fix compiling kfree_skb.c with musl-libc", " - selftests/bpf: Fix compiling flow_dissector.c with musl-libc", " - selftests/bpf: Fix compiling tcp_rtt.c with musl-libc", " - selftests/bpf: Fix compiling core_reloc.c with musl-libc", " - selftests/bpf: Fix errors compiling lwt_redirect.c with musl libc", " - selftests/bpf: Fix errors compiling decap_sanity.c with musl libc", " - selftests/bpf: Fix errors compiling crypto_sanity.c with musl libc", " - selftests/bpf: Fix errors compiling cg_storage_multi.h with musl libc", " - libbpf: Don't take direct pointers into BTF data from st_ops", " - selftests/bpf: Fix arg parsing in veristat, test_progs", " - selftests/bpf: Fix error compiling test_lru_map.c", " - selftests/bpf: Fix C++ compile error from missing _Bool type", " - selftests/bpf: Fix redefinition errors compiling lwt_reroute.c", " - selftests/bpf: Fix compile if backtrace support missing in libc", " - selftests/bpf: Fix error compiling tc_redirect.c with musl libc", " - s390/entry: Move early program check handler to entry.S", " - s390/entry: Make early program check handler relocated lowcore aware", " - libbpf: Fix license for btf_relocate.c", " - samples/bpf: Fix compilation errors with cf-protection option", " - selftests/bpf: no need to track next_match_pos in struct test_loader", " - selftests/bpf: extract test_loader->expect_msgs as a data structure", " - selftests/bpf: allow checking xlated programs in verifier_* tests", " - selftests/bpf: __arch_* macro to limit test cases to specific archs", " - selftests/bpf: fix to avoid __msg tag de-duplication by clang", " - selftests/bpf: Fix incorrect parameters in NULL pointer checking", " - libbpf: Fix bpf_object__open_skeleton()'s mishandling of options", " - s390/ap: Fix deadlock caused by recursive lock of the AP bus scan mutex", " - libbpf: Ensure new BTF objects inherit input endianness", " - xz: cleanup CRC32 edits from 2018", " - kthread: fix task state in kthread worker if being frozen", " - ext4: clear EXT4_GROUP_INFO_WAS_TRIMMED_BIT even mount with discard", " - bpftool: Fix handling enum64 in btf dump sorting", " - sched/deadline: Fix schedstats vs deadline servers", " - smackfs: Use rcu_assign_pointer() to ensure safe assignment in smk_set_cipso", " - ext4: avoid buffer_head leak in ext4_mark_inode_used()", " - ext4: avoid potential buffer_head leak in __ext4_new_inode()", " - ext4: avoid negative min_clusters in find_group_orlov()", " - ext4: return error on ext4_find_inline_entry", " - sched/numa: Fix the vma scan starving issue", " - nilfs2: determine empty node blocks as corrupted", " - sched/pelt: Use rq_clock_task() for hw_pressure", " - bpf: Fix bpf_strtol and bpf_strtoul helpers for 32bit", " - bpf: Improve check_raw_mode_ok test for MEM_UNINIT-tagged types", " - perf scripts python cs-etm: Restore first sample log in verbose mode", " - perf bpf: Move BPF disassembly routines to separate file to avoid clash with", " capstone bpf headers", " - perf mem: Free the allocated sort string, fixing a leak", " - perf lock contention: Change stack_id type to s32", " - perf vendor events: SKX, CLX, SNR uncore cache event fixes", " - perf inject: Fix leader sampling inserting additional samples", " - perf report: Fix --total-cycles --stdio output error", " - perf build: Fix up broken capstone feature detection fast path", " - perf sched timehist: Fix missing free of session in perf_sched__timehist()", " - perf stat: Display iostat headers correctly", " - perf dwarf-aux: Check allowed location expressions when collecting variables", " - perf annotate-data: Fix off-by-one in location range check", " - perf dwarf-aux: Handle bitfield members from pointer access", " - perf hist: Don't set hpp_fmt_value for members in --no-group", " - perf sched timehist: Fixed timestamp error when unable to confirm event", " sched_in time", " - perf time-utils: Fix 32-bit nsec parsing", " - perf mem: Check mem_events for all eligible PMUs", " - perf mem: Fix missed p-core mem events on ADL and RPL", " - clk: imx: clk-audiomix: Correct parent clock for earc_phy and audpll", " - clk: imx: imx6ul: fix default parent for enet*_ref_sel", " - clk: imx: composite-8m: Enable gate clk with mcore_booted", " - clk: imx: composite-93: keep root clock on when mcore enabled", " - clk: imx: composite-7ulp: Check the PCC present bit", " - clk: imx: fracn-gppll: fix fractional part of PLL getting lost", " - clk: imx: imx8mp: fix clock tree update of TF-A managed clocks", " - clk: imx: imx8qxp: Register dc0_bypass0_clk before disp clk", " - clk: imx: imx8qxp: Parent should be initialized earlier than the clock", " - quota: avoid missing put_quota_format when DQUOT_SUSPENDED is passed", " - remoteproc: imx_rproc: Correct ddr alias for i.MX8M", " - remoteproc: imx_rproc: Initialize workqueue earlier", " - clk: rockchip: Set parent rate for DCLK_VOP clock on RK3228", " - clk: qcom: dispcc-sm8550: fix several supposed typos", " - clk: qcom: dispcc-sm8550: use rcg2_ops for mdss_dptx1_aux_clk_src", " - clk: qcom: dispcc-sm8650: Update the GDSC flags", " - clk: qcom: dispcc-sm8550: use rcg2_shared_ops for ESC RCGs", " - leds: bd2606mvv: Fix device child node usage in bd2606mvv_probe()", " - pinctrl: renesas: rzg2l: Return -EINVAL if the pin doesn't support", " PIN_CFG_OEN", " - pinctrl: ti: ti-iodelay: Fix some error handling paths", " - phy: phy-rockchip-samsung-hdptx: Explicitly include pm_runtime.h", " - Input: ilitek_ts_i2c - avoid wrong input subsystem sync", " - Input: ilitek_ts_i2c - add report id message validation", " - media: raspberrypi: VIDEO_RASPBERRYPI_PISP_BE should depend on ARCH_BCM2835", " - [Config] updateconfigs for VIDEO_RASPBERRYPI_PISP_BE", " - PCI: Wait for Link before restoring Downstream Buses", " - firewire: core: correct range of block for case of switch statement", " - media: staging: media: starfive: camss: Drop obsolete return value", " documentation", " - clk: qcom: ipq5332: Register gcc_qdss_tsctr_clk_src", " - clk: qcom: dispcc-sm8250: use special function for Lucid 5LPE PLL", " - leds: pca995x: Use device_for_each_child_node() to access device child nodes", " - leds: pca995x: Fix device child node usage in pca995x_probe()", " - x86/PCI: Check pcie_find_root_port() return for NULL", " - PCI: xilinx-nwl: Fix register misspelling", " - PCI: xilinx-nwl: Clean up clock on probe failure/removal", " - leds: gpio: Set num_leds after allocation", " - media: platform: rzg2l-cru: rzg2l-csi2: Add missing MODULE_DEVICE_TABLE", " - pinctrl: single: fix missing error code in pcs_probe()", " - clk: at91: sama7g5: Allocate only the needed amount of memory for PLLs", " - iommufd/selftest: Fix buffer read overrrun in the dirty test", " - RDMA/bnxt_re: Fix the table size for PSN/MSN entries", " - media: imagination: VIDEO_E5010_JPEG_ENC should depend on ARCH_K3", " - [Config] updateconfigs for VIDEO_E5010_JPEG_ENC", " - RDMA/rtrs: Reset hb_missed_cnt after receiving other traffic from peer", " - clk: ti: dra7-atl: Fix leak of of_nodes", " - clk: starfive: Use pm_runtime_resume_and_get to fix pm_runtime_get_sync()", " usage", " - clk: rockchip: rk3588: Fix 32k clock name for pmu_24m_32k_100m_src_p", " - nfsd: remove unneeded EEXIST error check in nfsd_do_file_acquire", " - nfsd: fix refcount leak when file is unhashed after being found", " - pinctrl: mvebu: Fix devinit_dove_pinctrl_probe function", " - dt-bindings: PCI: layerscape-pci: Replace fsl,lx2160a-pcie with", " fsl,lx2160ar2-pcie", " - iommufd: Check the domain owner of the parent before creating a nesting", " domain", " - RDMA/erdma: Return QP state in erdma_query_qp", " - RDMA/mlx5: Fix counter update on MR cache mkey creation", " - RDMA/mlx5: Limit usage of over-sized mkeys from the MR cache", " - RDMA/mlx5: Drop redundant work canceling from clean_keys()", " - RDMA/mlx5: Fix MR cache temp entries cleanup", " - watchdog: imx_sc_wdt: Don't disable WDT in suspend", " - RDMA/hns: Don't modify rq next block addr in HIP09 QPC", " - RDMA/hns: Fix the overflow risk of hem_list_calc_ba_range()", " - RDMA/hns: Fix VF triggering PF reset in abnormal interrupt handler", " - RDMA/hns: Fix 1bit-ECC recovery address in non-4K OS", " - RDMA/hns: Optimize hem allocation performance", " - RDMA/hns: Fix restricted __le16 degrades to integer issue", " - Input: ims-pcu - fix calling interruptible mutex", " - RDMA/mlx5: Obtain upper net device only when needed", " - PCI: qcom-ep: Enable controller resources like PHY only after refclk is", " available", " - riscv: Fix fp alignment bug in perf_callchain_user()", " - RDMA/hns: Fix ah error counter in sw stat not increasing", " - RDMA/irdma: fix error message in irdma_modify_qp_roce()", " - ntb_perf: Fix printk format", " - ntb: Force physically contiguous allocation of rx ring buffers", " - nfsd: untangle code in nfsd4_deleg_getattr_conflict()", " - nfsd: fix initial getattr on write delegation", " - crypto: caam - Pad SG length when allocating hash edesc", " - crypto: powerpc/p10-aes-gcm - Disable CRYPTO_AES_GCM_P10", " - [Config] disable CRYPTO_AES_GCM_P10", " - f2fs: atomic: fix to avoid racing w/ GC", " - f2fs: reduce expensive checkpoint trigger frequency", " - f2fs: fix to avoid racing in between read and OPU dio write", " - f2fs: Create COW inode from parent dentry for atomic write", " - f2fs: fix to wait page writeback before setting gcing flag", " - f2fs: atomic: fix to truncate pagecache before on-disk metadata truncation", " - f2fs: compress: don't redirty sparse cluster during {,de}compress", " - f2fs: prevent atomic file from being dirtied before commit", " - spi: airoha: fix dirmap_{read,write} operations", " - spi: airoha: fix airoha_snand_{write,read}_data data_len estimation", " - spi: atmel-quadspi: Undo runtime PM changes at driver exit time", " - spi: spi-fsl-lpspi: Undo runtime PM changes at driver exit time", " - lib/sbitmap: define swap_lock as raw_spinlock_t", " - spi: airoha: remove read cache in airoha_snand_dirmap_read()", " - spi: atmel-quadspi: Avoid overwriting delay register settings", " - NFSv4.2: Fix detection of \"Proxying of Times\" server support", " - nvme-multipath: system fails to create generic nvme device", " - iio: adc: ad7606: fix oversampling gpio array", " - iio: adc: ad7606: fix standby gpio state to match the documentation", " - driver core: Fix error handling in driver API device_rename()", " - ABI: testing: fix admv8818 attr description", " - iio: chemical: bme680: Fix read/write ops to device by adding mutexes", " - iio: magnetometer: ak8975: drop incorrect AK09116 compatible", " - dt-bindings: iio: asahi-kasei,ak8975: drop incorrect AK09116 compatible", " - serial: 8250: omap: Cleanup on error in request_irq", " - Coresight: Set correct cs_mode for TPDM to fix disable issue", " - Coresight: Set correct cs_mode for dummy source to fix disable issue", " - coresight: tmc: sg: Do not leak sg_table", " - interconnect: icc-clk: Add missed num_nodes initialization", " - interconnect: qcom: sm8250: Enable sync_state", " - dm integrity: fix gcc 5 warning", " - cxl/pci: Fix to record only non-zero ranges", " - um: remove ARCH_NO_PREEMPT_DYNAMIC", " - Revert \"dm: requeue IO if mapping table not yet available\"", " - net: phy: aquantia: fix -ETIMEDOUT PHY probe failure when firmware not", " present", " - net: xilinx: axienet: Schedule NAPI in two steps", " - net: xilinx: axienet: Fix packet counting", " - net: ipv6: select DST_CACHE from IPV6_RPL_LWTUNNEL", " - net: qrtr: Update packets cloning when broadcasting", " - net: phy: aquantia: fix setting active_low bit", " - net: phy: aquantia: fix applying active_low bit after reset", " - net: ravb: Fix maximum TX frame size for GbEth devices", " - net: ravb: Fix R-Car RX frame size limit", " - virtio_net: Fix mismatched buf address when unmapping for small packets", " - netfilter: nf_tables: Keep deleted flowtable hooks until after RCU", " - netfilter: ctnetlink: compile ctnetlink_label_size with", " CONFIG_NF_CONNTRACK_EVENTS", " - netfilter: nf_tables: use rcu chain hook list iterator from netlink dump", " path", " - netfilter: nf_tables: missing objects with no memcg accounting", " - selftests: netfilter: Avoid hanging ipvs.sh", " - io_uring/sqpoll: do not allow pinning outside of cpuset", " - io_uring/rw: treat -EOPNOTSUPP for IOCB_NOWAIT like -EAGAIN", " - io_uring: check for presence of task_work rather than TIF_NOTIFY_SIGNAL", " - mm: migrate: annotate data-race in migrate_folio_unmap()", " - drm/amd/display: Fix Synaptics Cascaded Panamera DSC Determination", " - drm/amd/display: Add DSC Debug Log", " - drm/amdgpu/display: Fix a mistake in revert commit", " - xen: move checks for e820 conflicts further up", " - xen: allow mapping ACPI data using a different physical address", " - io_uring/sqpoll: retain test for whether the CPU is valid", " - drm/amd/display: disable_hpo_dp_link_output: Check link_res->hpo_dp_link_enc", " before using it", " - io_uring/sqpoll: do not put cpumask on stack", " - selftests/bpf: correctly move 'log' upon successful match", " - Remove *.orig pattern from .gitignore", " - PCI: Revert to the original speed after PCIe failed link retraining", " - PCI: Clear the LBMS bit after a link retrain", " - PCI: dra7xx: Fix threaded IRQ request for \"dra7xx-pcie-main\" IRQ", " - PCI: imx6: Fix missing call to phy_power_off() in error handling", " - PCI: imx6: Fix establish link failure in EP mode for i.MX8MM and i.MX8MP", " - PCI: imx6: Fix i.MX8MP PCIe EP's occasional failure to trigger MSI", " - PCI: Correct error reporting with PCIe failed link retraining", " - PCI: Use an error code with PCIe failed link retraining", " - PCI: xilinx-nwl: Fix off-by-one in INTx IRQ handler", " - PCI: dra7xx: Fix error handling when IRQ request fails in probe", " - Revert \"soc: qcom: smd-rpm: Match rpmsg channel instead of compatible\"", " - ASoC: rt5682: Return devm_of_clk_add_hw_provider to transfer the error", " - soc: fsl: cpm1: qmc: Update TRNSYNC only in transparent mode", " - soc: fsl: cpm1: tsa: Fix tsa_write8()", " - soc: versatile: integrator: fix OF node leak in probe() error path", " - Revert \"media: tuners: fix error return code of", " hybrid_tuner_request_state()\"", " - iommu/amd: Fix argument order in amd_iommu_dev_flush_pasid_all()", " - Input: adp5588-keys - fix check on return code", " - Input: i8042 - add TUXEDO Stellaris 16 Gen5 AMD to i8042 quirk table", " - Input: i8042 - add TUXEDO Stellaris 15 Slim Gen6 AMD to i8042 quirk table", " - Input: i8042 - add another board name for TUXEDO Stellaris Gen5 AMD line", " - KVM: arm64: Add memory length checks and remove inline in do_ffa_mem_xfer", " - KVM: x86: Enforce x2APIC's must-be-zero reserved ICR bits", " - KVM: x86: Move x2APIC ICR helper above kvm_apic_write_nodecode()", " - KVM: x86: Re-split x2APIC ICR into ICR+ICR2 for AMD (x2AVIC)", " - drm/amdgpu/mes12: reduce timeout", " - drm/amdgpu/mes11: reduce timeout", " - drm/amdkfd: Add SDMA queue quantum support for GFX12", " - drm/amdgpu: update golden regs for gfx12", " - drm/amdgpu/mes12: set enable_level_process_quantum_check", " - drm/amdgpu/vcn: enable AV1 on both instances", " - drm/amd/pm: update workload mask after the setting", " - drm/amdgpu: fix PTE copy corruption for sdma 7", " - drm/amdgpu: bump driver version for cleared VRAM", " - drm/amdgpu/mes12: switch SET_SHADER_DEBUGGER pkt to mes schq pipe", " - drm/amdgpu: Fix selfring initialization sequence on soc24", " - drm/amd/display: Add HDMI DSC native YCbCr422 support", " - drm/amd/display: Round calculated vtotal", " - drm/amd/display: Clean up dsc blocks in accelerated mode", " - drm/amd/display: Block timing sync for different output formats in pmo", " - drm/amd/display: Validate backlight caps are sane", " - drm/amd/display: Disable SYMCLK32_LE root clock gating", " - drm/amd/display: Block dynamic IPS2 on DCN35 for incompatible FW versions", " - drm/amd/display: Enable DML2 override_det_buffer_size_kbytes", " - drm/amd/display: Skip to enable dsc if it has been off", " - drm/amd/display: Fix underflow when setting underscan on DCN401", " - drm/amd/display: Update IPS default mode for DCN35/DCN351", " - objtool: Handle frame pointer related instructions", " - powerpc/atomic: Use YZ constraints for DS-form instructions", " - ksmbd: make __dir_empty() compatible with POSIX", " - ksmbd: allow write with FILE_APPEND_DATA", " - ksmbd: handle caseless file creation", " - ata: libata-scsi: Fix ata_msense_control() CDL page reporting", " - scsi: ufs: qcom: Update MODE_MAX cfg_bw value", " - scsi: lpfc: Restrict support for 32 byte CDBs to specific HBAs", " - scsi: mac_scsi: Revise printk(KERN_DEBUG ...) messages", " - scsi: mac_scsi: Refactor polling loop", " - scsi: mac_scsi: Disallow bus errors during PDMA send", " - can: esd_usb: Remove CAN_CTRLMODE_3_SAMPLES for CAN-USB/3-FD", " - wifi: rtw88: Fix USB/SDIO devices not transmitting beacons", " - usbnet: fix cyclical race on disconnect with work queue", " - arm64: dts: mediatek: mt8195-cherry: Mark USB 3.0 on xhci1 as disabled", " - arm64: dts: mediatek: mt8395-nio-12l: Mark USB 3.0 on xhci1 as disabled", " - USB: appledisplay: close race between probe and completion handler", " - USB: misc: cypress_cy7c63: check for short transfer", " - USB: class: CDC-ACM: fix race between get_serial and set_serial", " - USB: misc: yurex: fix race between read and write", " - usb: xhci: fix loss of data on Cadence xHC", " - usb: cdnsp: Fix incorrect usb_request status", " - usb: xHCI: add XHCI_RESET_ON_RESUME quirk for Phytium xHCI host", " - usb: gadget: dummy_hcd: execute hrtimer callback in softirq context", " - usb: dwc2: drd: fix clock gating on USB role switch", " - bus: integrator-lm: fix OF node leak in probe()", " - bus: mhi: host: pci_generic: Update EDL firmware path for Foxconn modems", " - bus: mhi: host: pci_generic: Fix the name for the Telit FE990A", " - tty: rp2: Fix reset with non forgiving PCIe host bridges", " - pps: add an error check in parport_attach", " - serial: don't use uninitialized value in uart_poll_init()", " - xhci: Set quirky xHC PCI hosts to D3 _after_ stopping and freeing them.", " - serial: qcom-geni: fix fifo polling timeout", " - serial: qcom-geni: fix false console tx restart", " - crypto: qcom-rng - fix support for ACPI-based systems", " - crypto: ccp - Properly unregister /dev/sev on sev PLATFORM_STATUS failure", " - drbd: Fix atomicity violation in drbd_uuid_set_bm()", " - drbd: Add NULL check for net_conf to prevent dereference in state validation", " - ACPI: resource: Do IRQ override on MECHREV GM7XG0M", " - ACPI: resource: Add another DMI match for the TongFang GMxXGxx", " - intel_idle: add Granite Rapids Xeon support", " - intel_idle: fix ACPI _CST matching for newer Xeon platforms", " - x86/entry: Remove unwanted instrumentation in common_interrupt()", " - perf/x86/intel: Allow to setup LBR for counting event for BPF", " - perf/x86/intel/pt: Fix sampling synchronization", " - btrfs: subpage: fix the bitmap dump which can cause bitmap corruption", " - wifi: mt76: mt7921: Check devm_kasprintf() returned value", " - wifi: mt76: mt7915: check devm_kasprintf() returned value", " - idpf: fix netdev Tx queue stop/wake", " - wifi: rtw88: 8821cu: Remove VID/PID 0bda:c82c", " - wifi: rtw88: 8822c: Fix reported RX band width", " - wifi: rtw88: 8703b: Fix reported RX band width", " - wifi: mt76: mt7615: check devm_kasprintf() returned value", " - wifi: mt76: mt7925: fix a potential association failure upon resuming", " - debugfs show actual source in /proc/mounts", " - debugobjects: Fix conditions in fill_pool()", " - btrfs: tree-checker: fix the wrong output of data backref objectid", " - btrfs: always update fstrim_range on failure in FITRIM ioctl", " - f2fs: fix several potential integer overflows in file offsets", " - f2fs: prevent possible int overflow in dir_block_index()", " - f2fs: avoid potential int overflow in sanity_check_area_boundary()", " - hwrng: mtk - Use devm_pm_runtime_enable", " - hwrng: bcm2835 - Add missing clk_disable_unprepare in bcm2835_rng_init", " - hwrng: cctrng - Add missing clk_disable_unprepare in cctrng_resume", " - arm64: esr: Define ESR_ELx_EC_* constants as UL", " - arm64: errata: Enable the AC03_CPU_38 workaround for ampere1a", " - arm64: dts: mediatek: mt8186-corsola: Disable DPI display interface", " - arm64: dts: rockchip: Raise Pinebook Pro's panel backlight PWM frequency", " - arm64: dts: qcom: sa8775p: Mark APPS and PCIe SMMUs as DMA coherent", " - arm64: dts: rockchip: Correct the Pinebook Pro battery design capacity", " - fs: Fix file_set_fowner LSM hook inconsistencies", " - nfs: fix memory leak in error path of nfs4_do_reclaim", " - EDAC/igen6: Fix conversion of system address to physical memory address", " - eventpoll: Annotate data-race of busy_poll_usecs", " - md: Don't flush sync_work in md_write_start()", " - cpuidle: riscv-sbi: Use scoped device node handling to fix missing", " of_node_put", " - lsm: add the inode_free_security_rcu() LSM implementation hook", " - spi: fspi: involve lut_num for struct nxp_fspi_devtype_data", " - dt-bindings: spi: nxp-fspi: add imx8ulp support", " - ARM: dts: imx6ul-geam: fix fsl,pins property in tscgrp pinctrl", " - ARM: dts: imx6ull-seeed-npi: fix fsl,pins property in tscgrp pinctrl", " - tools/nolibc: include arch.h from string.h", " - soc: versatile: realview: fix memory leak during device remove", " - soc: versatile: realview: fix soc_dev leak during device remove", " - usb: typec: ucsi: Call CANCEL from single location", " - usb: typec: ucsi: Fix busy loop on ASUS VivoBooks", " - soc: qcom: geni-se: add GP_LENGTH/IRQ_EN_SET/IRQ_EN_CLEAR registers", " - serial: qcom-geni: fix arg types for qcom_geni_serial_poll_bit()", " - serial: qcom-geni: introduce qcom_geni_serial_poll_bitfield()", " - serial: qcom-geni: fix console corruption", " - thermal: core: Store trip sysfs attributes in thermal_trip_desc", " - thermal: sysfs: Get to trips via attribute pointers", " - thermal: sysfs: Refine the handling of trip hysteresis changes", " - thermal: sysfs: Add sanity checks for trip temperature and hysteresis", " - bpf: lsm: Set bpf_lsm_blob_sizes.lbs_task to 0", " - compiler.h: specify correct attribute for .rodata..c_jump_table", " - lockdep: fix deadlock issue between lockdep and rcu", " - mm/hugetlb_vmemmap: batch HVO work when demoting", " - s390/ftrace: Avoid calling unwinder in ftrace_return_address()", " - selftest mm/mseal: fix test_seal_mremap_move_dontunmap_anyaddr", " - mm: only enforce minimum stack gap size if it's sensible", " - spi: fspi: add support for imx8ulp", " - module: Fix KCOV-ignored file name", " - fbdev: xen-fbfront: Assign fb_info->device", " - tpm: export tpm2_sessions_init() to fix ibmvtpm building", " - mm/huge_memory: ensure huge_zero_folio won't have large_rmappable flag set", " - mm: change vmf_anon_prepare() to __vmf_anon_prepare()", " - mm/damon/vaddr: protect vma traversal in __damon_va_thre_regions() with rcu", " read lock", " - i2c: aspeed: Update the stop sw state when the bus recovery occurs", " - i2c: isch: Add missed 'else'", " - i2c: xiic: Try re-initialization on bus busy timeout", " - Documentation: KVM: fix warning in \"make htmldocs\"", " - spi: atmel-quadspi: Fix wrong register value written to MR", " - Revert: \"dm-verity: restart or panic on an I/O error\"", " - Linux 6.11.2", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47675", " - bpf: Fix use-after-free in bpf_uprobe_multi_link_attach()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47676", " - mm/hugetlb.c: fix UAF of vma in hugetlb fault pathway", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47677", " - exfat: resolve memory leak from exfat_create_upcase_table()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47725", " - dm-verity: restart or panic on an I/O error", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47739", " - padata: use integer wrap around to prevent deadlock on seq_nr overflow", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47678", " - icmp: change the order of rate limits", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47733", " - netfs: Delete subtree of 'fs/netfs' when netfs module exits", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47679", " - vfs: fix race between evice_inodes() and find_inode()&iput()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49859", " - f2fs: fix to check atomic_file in f2fs ioctl interfaces", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47680", " - f2fs: check discard support for conventional zones", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47740", " - f2fs: Require FMODE_WRITE for atomic write ioctls", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47726", " - f2fs: fix to wait dio completion", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47741", " - btrfs: fix race setting file private on concurrent lseek using same fd", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47681", " - wifi: mt76: mt7996: fix NULL pointer dereference in mt7996_mcu_sta_bfer_he", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49858", " - efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49860", " - ACPI: sysfs: validate return type of _STR method", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47742", " - firmware_loader: Block path traversal", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47682", " - scsi: sd: Fix off-by-one error in sd_read_block_characteristics()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47743", " - KEYS: prevent NULL pointer dereference in find_asymmetric_key()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47727", " - x86/tdx: Fix \"in-kernel MMIO\" check", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47744", " - KVM: Use dedicated mutex to protect kvm_usage_count to avoid deadlock", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47719", " - iommufd: Protect against overflow of ALIGN() during iova allocation", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47745", " - mm: call the security_mmap_file() LSM hook in remap_file_pages()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47746", " - fuse: use exclusive lock when FUSE_I_CACHE_IO_MODE is set", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47734", " - bonding: Fix unnecessary warnings and logs from bond_xdp_get_xmit_slave()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47684", " - tcp: check skb is non-NULL in tcp_rto_delta_us()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47747", " - net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race", " Condition", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47685", " - netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47686", " - ep93xx: clock: Fix off by one in ep93xx_div_recalc_rate()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47748", " - vhost_vdpa: assign irq bypass producer token correctly", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47687", " - vdpa/mlx5: Fix invalid mr resource destroy", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47688", " - driver core: Fix a potential null-ptr-deref in module_add_driver()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47689", " - f2fs: fix to don't set SB_RDONLY in f2fs_handle_critical_error()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47690", " - f2fs: get rid of online repaire on corrupted directory", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47691", " - f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47692", " - nfsd: return -EINVAL when namelen is 0", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47737", " - nfsd: call cache_put if xdr_reserve_space returns NULL", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2023-52917", " - ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47749", " - RDMA/cxgb4: Added NULL check for lookup_atid", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47735", " - RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47750", " - RDMA/hns: Fix Use-After-Free of rsv_qp on HIP08", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47751", " - PCI: kirin: Fix buffer overflow in kirin_pcie_parse_port()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47693", " - IB/core: Fix ib_cache_setup_one error flow cleanup", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47694", " - IB/mlx5: Fix UMR pd cleanup on error flow of driver init", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47695", " - RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47752", " - media: mediatek: vcodec: Fix H264 stateless decoder smatch warning", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47753", " - media: mediatek: vcodec: Fix VP8 stateless decoder smatch warning", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47754", " - media: mediatek: vcodec: Fix H264 multi stateless decoder smatch warning", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47696", " - RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47755", " - nvdimm: Fix devs leaks in scan_labels()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47756", " - PCI: keystone: Fix if-statement expression in ks_pcie_quirk()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47697", " - drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47698", " - drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47728", " - bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49861", " - bpf: Fix helper writes to read-only maps", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47757", " - nilfs2: fix potential oob read in nilfs_btree_check_delete()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47699", " - nilfs2: fix potential null-ptr-deref in nilfs_btree_insert()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47700", " - ext4: check stripe size compatibility on remount as well", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47701", " - ext4: avoid OOB when system.data xattr changes underneath the filesystem", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49850", " - bpf: correctly handle malformed BPF_CORE_TYPE_ID_LOCAL relos", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47702", " - bpf: Fail verification for sign-extension of packet data/data_end/data_meta", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47703", " - bpf, lsm: Add check for BPF LSM return value", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49851", " - tpm: Clean up TPM space after command failure", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47723", " - jfs: fix out-of-bounds in dbNextAG() and diAlloc()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49852", " - scsi: elx: libefc: Fix potential use after free in efc_nport_vport_del()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47720", " - drm/amd/display: Add null check for set_output_gamma in", " dcn30_set_output_transfer_func", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47704", " - drm/amd/display: Check link_res->hpo_dp_link_enc before using it", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49853", " - firmware: arm_scmi: Fix double free in OPTEE transport", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47705", " - block: fix potential invalid pointer dereference in blk_add_partition", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47736", " - erofs: handle overlapped pclusters out of crafted images properly", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47706", " - block, bfq: fix possible UAF for bfqq->bic with merge chain", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49855", " - nbd: fix race between timeout and normal completion", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47707", " - ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47708", " - netkit: Assign missing bpf_net_context", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47709", " - can: bcm: Clear bo->bcm_proc_read after remove_proc_entry().", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47710", " - sock_map: Add a cond_resched() in sock_hash_free()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47711", " - af_unix: Don't return OOB skb in manage_oob().", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47712", " - wifi: wilc1000: fix potential RCU dereference issue in", " wilc_parse_join_bss_param", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47713", " - wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47730", " - crypto: hisilicon/qm - inject error before stopping queue", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49856", " - x86/sgx: Fix deadlock in SGX NUMA node search", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47714", " - wifi: mt76: mt7996: use hweight16 to get correct tx antenna", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47715", " - wifi: mt76: mt7915: fix oops on non-dbdc mt7986", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49857", " - wifi: iwlwifi: mvm: set the cipher for secured NDP ranging", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47738", " - wifi: mac80211: don't use rate mask for offchannel TX either", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47731", " - drivers/perf: Fix ali_drw_pmu driver interrupt status clearing", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49862", " - powercap: intel_rapl: Fix off by one in get_rpi()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47716", " - ARM: 9410/1: vfp: Use asm volatile in fmrx/fmxr macros", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47717", " - RISC-V: KVM: Don't zero-out PMU snapshot area before freeing data", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47721", " - wifi: rtw89: remove unused C2H event ID RTW89_MAC_C2H_FUNC_READ_WOW_CAM to", " prevent out-of-bounds reading", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47732", " - crypto: iaa - Fix potential use after free bug", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47718", " - wifi: rtw88: always wait for both firmware loading attempts", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47724", " - wifi: ath11k: use work queue to process beacon tx event", "", " * Oracular update: v6.11.1 upstream stable release (LP: #2089020)", " - powercap/intel_rapl: Add support for AMD family 1Ah", " - powercap/intel_rapl: Fix the energy-pkg event for AMD CPUs", " - cpufreq/amd-pstate: Add the missing cpufreq_cpu_put()", " - netfilter: nft_socket: Fix a NULL vs IS_ERR() bug in", " nft_socket_cgroup_subtree_level()", " - ASoC: amd: acp: add ZSC control register programming sequence", " - nvme-pci: qdepth 1 quirk", " - USB: serial: pl2303: add device id for Macrosilicon MS3020", " - powercap: intel_rapl: Change an error pointer to NULL", " - Linux 6.11.1", "", " * Oracular update: v6.11.1 upstream stable release (LP: #2089020) //", " CVE-2024-47671", " - USB: usbtmc: prevent kernel-usb-infoleak", "", " * Oracular update: v6.11.1 upstream stable release (LP: #2089020) //", " CVE-2024-46869", " - Bluetooth: btintel_pcie: Allocate memory for driver private data", "", " * CVE-2024-53164", " - net: sched: fix ordering of qlen adjustment", "", " * CVE-2024-53103", " - hv_sock: Initializing vsk->trans to NULL to prevent a dangling pointer", "" ], "package": "linux", "version": "6.11.0-17.17", "urgency": "medium", "distributions": "oracular", "launchpad_bugs_fixed": [ 2093643, 1786013, 2091744, 2091184, 2093146, 2085406, 2089684, 2090932, 2085485, 2089357, 2089306, 2091655, 2091655, 2091655, 2091655, 2091655, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091386, 2091990, 2089327, 2089113, 2086587, 2086606, 2085950, 2085944, 2087853, 2087983, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089020, 2089020, 2089020 ], "author": "Stefan Bader ", "date": "Thu, 16 Jan 2025 22:38:59 +0100" } ], "notes": "linux-headers-6.11.0-18 version '6.11.0-18.18' (source package linux version '6.11.0-18.18') was added. linux-headers-6.11.0-18 version '6.11.0-18.18' has the same source package name, linux, as removed package linux-headers-6.11.0-14. As such we can use the source package version of the removed package, '6.11.0-14.15', 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." }, { "name": "linux-headers-6.11.0-18-generic", "from_version": { "source_package_name": "linux", "source_package_version": "6.11.0-14.15", "version": null }, "to_version": { "source_package_name": "linux", "source_package_version": "6.11.0-18.18", "version": "6.11.0-18.18" }, "cves": [ { "cve": "CVE-2025-0927", "url": "https://ubuntu.com/security/CVE-2025-0927", "cve_description": "[fs: hfs/hfsplus: add key_len boundary check to hfs_bnode_read_key]", "cve_priority": "medium", "cve_public_date": "2025-02-13" }, { "cve": "CVE-2024-53141", "url": "https://ubuntu.com/security/CVE-2024-53141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: add missing range check in bitmap_ip_uadt When tb[IPSET_ATTR_IP_TO] is not present but tb[IPSET_ATTR_CIDR] exists, the values of ip and ip_to are slightly swapped. Therefore, the range check for ip should be done later, but this part is missing and it seems that the vulnerability occurs. So we should add missing range checks and remove unnecessary range checks.", "cve_priority": "medium", "cve_public_date": "2024-12-06 10:15:00 UTC" }, { "cve": "CVE-2024-50010", "url": "https://ubuntu.com/security/CVE-2024-50010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exec: don't WARN for racy path_noexec check Both i_mode and noexec checks wrapped in WARN_ON stem from an artifact of the previous implementation. They used to legitimately check for the condition, but that got moved up in two commits: 633fb6ac3980 (\"exec: move S_ISREG() check earlier\") 0fd338b2d2cd (\"exec: move path_noexec() check earlier\") Instead of being removed said checks are WARN_ON'ed instead, which has some debug value. However, the spurious path_noexec check is racy, resulting in unwarranted warnings should someone race with setting the noexec flag. One can note there is more to perm-checking whether execve is allowed and none of the conditions are guaranteed to still hold after they were tested for. Additionally this does not validate whether the code path did any perm checking to begin with -- it will pass if the inode happens to be regular. Keep the redundant path_noexec() check even though it's mindless nonsense checking for guarantee that isn't given so drop the WARN. Reword the commentary and do small tidy ups while here. [brauner: keep redundant path_noexec() check]", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-53143", "url": "https://ubuntu.com/security/CVE-2024-53143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fsnotify: Fix ordering of iput() and watched_objects decrement Ensure the superblock is kept alive until we're done with iput(). Holding a reference to an inode is not allowed unless we ensure the superblock stays alive, which fsnotify does by keeping the watched_objects count elevated, so iput() must happen before the watched_objects decrement. This can lead to a UAF of something like sb->s_fs_info in tmpfs, but the UAF is hard to hit because race orderings that oops are more likely, thanks to the CHECK_DATA_CORRUPTION() block in generic_shutdown_super(). Also, ensure that fsnotify_put_sb_watched_objects() doesn't call fsnotify_sb_watched_objects() on a superblock that may have already been freed, which would cause a UAF read of sb->s_fsnotify_info.", "cve_priority": "medium", "cve_public_date": "2024-12-07 07:15:00 UTC" }, { "cve": "CVE-2024-53142", "url": "https://ubuntu.com/security/CVE-2024-53142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: initramfs: avoid filename buffer overrun The initramfs filename field is defined in Documentation/driver-api/early-userspace/buffer-format.rst as: 37 cpio_file := ALGN(4) + cpio_header + filename + \"\\0\" + ALGN(4) + data ... 55 ============= ================== ========================= 56 Field name Field size Meaning 57 ============= ================== ========================= ... 70 c_namesize 8 bytes Length of filename, including final \\0 When extracting an initramfs cpio archive, the kernel's do_name() path handler assumes a zero-terminated path at @collected, passing it directly to filp_open() / init_mkdir() / init_mknod(). If a specially crafted cpio entry carries a non-zero-terminated filename and is followed by uninitialized memory, then a file may be created with trailing characters that represent the uninitialized memory. The ability to create an initramfs entry would imply already having full control of the system, so the buffer overrun shouldn't be considered a security vulnerability. Append the output of the following bash script to an existing initramfs and observe any created /initramfs_test_fname_overrunAA* path. E.g. ./reproducer.sh | gzip >> /myinitramfs It's easiest to observe non-zero uninitialized memory when the output is gzipped, as it'll overflow the heap allocated @out_buf in __gunzip(), rather than the initrd_start+initrd_size block. ---- reproducer.sh ---- nilchar=\"A\"\t# change to \"\\0\" to properly zero terminate / pad magic=\"070701\" ino=1 mode=$(( 0100777 )) uid=0 gid=0 nlink=1 mtime=1 filesize=0 devmajor=0 devminor=1 rdevmajor=0 rdevminor=0 csum=0 fname=\"initramfs_test_fname_overrun\" namelen=$(( ${#fname} + 1 ))\t# plus one to account for terminator printf \"%s%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%s\" \\ \t$magic $ino $mode $uid $gid $nlink $mtime $filesize \\ \t$devmajor $devminor $rdevmajor $rdevminor $namelen $csum $fname termpadlen=$(( 1 + ((4 - ((110 + $namelen) & 3)) % 4) )) printf \"%.s${nilchar}\" $(seq 1 $termpadlen) ---- reproducer.sh ---- Symlink filename fields handled in do_symlink() won't overrun past the data segment, due to the explicit zero-termination of the symlink target. Fix filename buffer overrun by aborting the initramfs FSM if any cpio entry doesn't carry a zero-terminator at the expected (name_len - 1) offset.", "cve_priority": "medium", "cve_public_date": "2024-12-06 10:15:00 UTC" }, { "cve": "CVE-2024-53133", "url": "https://ubuntu.com/security/CVE-2024-53133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Handle dml allocation failure to avoid crash [Why] In the case where a dml allocation fails for any reason, the current state's dml contexts would no longer be valid. Then subsequent calls dc_state_copy_internal would shallow copy invalid memory and if the new state was released, a double free would occur. [How] Reset dml pointers in new_state to NULL and avoid invalid pointer (cherry picked from commit bcafdc61529a48f6f06355d78eb41b3aeda5296c)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53108", "url": "https://ubuntu.com/security/CVE-2024-53108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Adjust VSDB parser for replay feature At some point, the IEEE ID identification for the replay check in the AMD EDID was added. However, this check causes the following out-of-bounds issues when using KASAN: [ 27.804016] BUG: KASAN: slab-out-of-bounds in amdgpu_dm_update_freesync_caps+0xefa/0x17a0 [amdgpu] [ 27.804788] Read of size 1 at addr ffff8881647fdb00 by task systemd-udevd/383 ... [ 27.821207] Memory state around the buggy address: [ 27.821215] ffff8881647fda00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821224] ffff8881647fda80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821234] >ffff8881647fdb00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821243] ^ [ 27.821250] ffff8881647fdb80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821259] ffff8881647fdc00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821268] ================================================================== This is caused because the ID extraction happens outside of the range of the edid lenght. This commit addresses this issue by considering the amd_vsdb_block size. (cherry picked from commit b7e381b1ccd5e778e3d9c44c669ad38439a861d8)", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53134", "url": "https://ubuntu.com/security/CVE-2024-53134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pmdomain: imx93-blk-ctrl: correct remove path The check condition should be 'i < bc->onecell_data.num_domains', not 'bc->onecell_data.num_domains' which will make the look never finish and cause kernel panic. Also disable runtime to address \"imx93-blk-ctrl 4ac10000.system-controller: Unbalanced pm_runtime_enable!\"", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53132", "url": "https://ubuntu.com/security/CVE-2024-53132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/oa: Fix \"Missing outer runtime PM protection\" warning Fix the following drm_WARN: [953.586396] xe 0000:00:02.0: [drm] Missing outer runtime PM protection ... <4> [953.587090] ? xe_pm_runtime_get_noresume+0x8d/0xa0 [xe] <4> [953.587208] guc_exec_queue_add_msg+0x28/0x130 [xe] <4> [953.587319] guc_exec_queue_fini+0x3a/0x40 [xe] <4> [953.587425] xe_exec_queue_destroy+0xb3/0xf0 [xe] <4> [953.587515] xe_oa_release+0x9c/0xc0 [xe] (cherry picked from commit b107c63d2953907908fd0cafb0e543b3c3167b75)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53127", "url": "https://ubuntu.com/security/CVE-2024-53127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Revert \"mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K\" The commit 8396c793ffdf (\"mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K\") increased the max_req_size, even for 4K pages, causing various issues: - Panic booting the kernel/rootfs from an SD card on Rockchip RK3566 - Panic booting the kernel/rootfs from an SD card on StarFive JH7100 - \"swiotlb buffer is full\" and data corruption on StarFive JH7110 At this stage no fix have been found, so it's probably better to just revert the change. This reverts commit 8396c793ffdf28bb8aee7cfe0891080f8cab7890.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53130", "url": "https://ubuntu.com/security/CVE-2024-53130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint When using the \"block:block_dirty_buffer\" tracepoint, mark_buffer_dirty() may cause a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because, since the tracepoint was added in mark_buffer_dirty(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, nilfs_grab_buffer(), which grabs a buffer to read (or create) a block of metadata, including b-tree node blocks, does not set the block device, but instead does so only if the buffer is not in the \"uptodate\" state for each of its caller block reading functions. However, if the uptodate flag is set on a folio/page, and the buffer heads are detached from it by try_to_free_buffers(), and new buffer heads are then attached by create_empty_buffers(), the uptodate flag may be restored to each buffer without the block device being set to bh->b_bdev, and mark_buffer_dirty() may be called later in that state, resulting in the bug mentioned above. Fix this issue by making nilfs_grab_buffer() always set the block device of the super block structure to the buffer head, regardless of the state of the buffer's uptodate flag.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53105", "url": "https://ubuntu.com/security/CVE-2024-53105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: page_alloc: move mlocked flag clearance into free_pages_prepare() Syzbot reported a bad page state problem caused by a page being freed using free_page() still having a mlocked flag at free_pages_prepare() stage: BUG: Bad page state in process syz.5.504 pfn:61f45 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x61f45 flags: 0xfff00000080204(referenced|workingset|mlocked|node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000080204 0000000000000000 dead000000000122 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set page_owner tracks the page as allocated page last allocated via order 0, migratetype Unmovable, gfp_mask 0x400dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO), pid 8443, tgid 8442 (syz.5.504), ts 201884660643, free_ts 201499827394 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1537 prep_new_page mm/page_alloc.c:1545 [inline] get_page_from_freelist+0x303f/0x3190 mm/page_alloc.c:3457 __alloc_pages_noprof+0x292/0x710 mm/page_alloc.c:4733 alloc_pages_mpol_noprof+0x3e8/0x680 mm/mempolicy.c:2265 kvm_coalesced_mmio_init+0x1f/0xf0 virt/kvm/coalesced_mmio.c:99 kvm_create_vm virt/kvm/kvm_main.c:1235 [inline] kvm_dev_ioctl_create_vm virt/kvm/kvm_main.c:5488 [inline] kvm_dev_ioctl+0x12dc/0x2240 virt/kvm/kvm_main.c:5530 __do_compat_sys_ioctl fs/ioctl.c:1007 [inline] __se_compat_sys_ioctl+0x510/0xc90 fs/ioctl.c:950 do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline] __do_fast_syscall_32+0xb4/0x110 arch/x86/entry/common.c:386 do_fast_syscall_32+0x34/0x80 arch/x86/entry/common.c:411 entry_SYSENTER_compat_after_hwframe+0x84/0x8e page last free pid 8399 tgid 8399 stack trace: reset_page_owner include/linux/page_owner.h:25 [inline] free_pages_prepare mm/page_alloc.c:1108 [inline] free_unref_folios+0xf12/0x18d0 mm/page_alloc.c:2686 folios_put_refs+0x76c/0x860 mm/swap.c:1007 free_pages_and_swap_cache+0x5c8/0x690 mm/swap_state.c:335 __tlb_batch_free_encoded_pages mm/mmu_gather.c:136 [inline] tlb_batch_pages_flush mm/mmu_gather.c:149 [inline] tlb_flush_mmu_free mm/mmu_gather.c:366 [inline] tlb_flush_mmu+0x3a3/0x680 mm/mmu_gather.c:373 tlb_finish_mmu+0xd4/0x200 mm/mmu_gather.c:465 exit_mmap+0x496/0xc40 mm/mmap.c:1926 __mmput+0x115/0x390 kernel/fork.c:1348 exit_mm+0x220/0x310 kernel/exit.c:571 do_exit+0x9b2/0x28e0 kernel/exit.c:926 do_group_exit+0x207/0x2c0 kernel/exit.c:1088 __do_sys_exit_group kernel/exit.c:1099 [inline] __se_sys_exit_group kernel/exit.c:1097 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1097 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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 Modules linked in: CPU: 0 UID: 0 PID: 8442 Comm: syz.5.504 Not tainted 6.12.0-rc6-syzkaller #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 bad_page+0x176/0x1d0 mm/page_alloc.c:501 free_page_is_bad mm/page_alloc.c:918 [inline] free_pages_prepare mm/page_alloc.c:1100 [inline] free_unref_page+0xed0/0xf20 mm/page_alloc.c:2638 kvm_destroy_vm virt/kvm/kvm_main.c:1327 [inline] kvm_put_kvm+0xc75/0x1350 virt/kvm/kvm_main.c:1386 kvm_vcpu_release+0x54/0x60 virt/kvm/kvm_main.c:4143 __fput+0x23f/0x880 fs/file_table.c:431 task_work_run+0x24f/0x310 kernel/task_work.c:239 exit_task_work include/linux/task_work.h:43 [inline] do_exit+0xa2f/0x28e0 kernel/exit.c:939 do_group_exit+0x207/0x2c0 kernel/exit.c:1088 __do_sys_exit_group kernel/exit.c:1099 [in ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53109", "url": "https://ubuntu.com/security/CVE-2024-53109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nommu: pass NULL argument to vma_iter_prealloc() When deleting a vma entry from a maple tree, it has to pass NULL to vma_iter_prealloc() in order to calculate internal state of the tree, but it passed a wrong argument. As a result, nommu kernels crashed upon accessing a vma iterator, such as acct_collect() reading the size of vma entries after do_munmap(). This commit fixes this issue by passing a right argument to the preallocation call.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53131", "url": "https://ubuntu.com/security/CVE-2024-53131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint Patch series \"nilfs2: fix null-ptr-deref bugs on block tracepoints\". This series fixes null pointer dereference bugs that occur when using nilfs2 and two block-related tracepoints. This patch (of 2): It has been reported that when using \"block:block_touch_buffer\" tracepoint, touch_buffer() called from __nilfs_get_folio_block() causes a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because since the tracepoint was added in touch_buffer(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, the block_device structure is set after the function returns to the caller. Here, touch_buffer() is used to mark the folio/page that owns the buffer head as accessed, but the common search helper for folio/page used by the caller function was optimized to mark the folio/page as accessed when it was reimplemented a long time ago, eliminating the need to call touch_buffer() here in the first place. So this solves the issue by eliminating the touch_buffer() call itself.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53135", "url": "https://ubuntu.com/security/CVE-2024-53135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: VMX: Bury Intel PT virtualization (guest/host mode) behind CONFIG_BROKEN Hide KVM's pt_mode module param behind CONFIG_BROKEN, i.e. disable support for virtualizing Intel PT via guest/host mode unless BROKEN=y. There are myriad bugs in the implementation, some of which are fatal to the guest, and others which put the stability and health of the host at risk. For guest fatalities, the most glaring issue is that KVM fails to ensure tracing is disabled, and *stays* disabled prior to VM-Enter, which is necessary as hardware disallows loading (the guest's) RTIT_CTL if tracing is enabled (enforced via a VMX consistency check). Per the SDM: If the logical processor is operating with Intel PT enabled (if IA32_RTIT_CTL.TraceEn = 1) at the time of VM entry, the \"load IA32_RTIT_CTL\" VM-entry control must be 0. On the host side, KVM doesn't validate the guest CPUID configuration provided by userspace, and even worse, uses the guest configuration to decide what MSRs to save/load at VM-Enter and VM-Exit. E.g. configuring guest CPUID to enumerate more address ranges than are supported in hardware will result in KVM trying to passthrough, save, and load non-existent MSRs, which generates a variety of WARNs, ToPA ERRORs in the host, a potential deadlock, etc.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53106", "url": "https://ubuntu.com/security/CVE-2024-53106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: fix buffer overrun in ima_eventdigest_init_common Function ima_eventdigest_init() calls ima_eventdigest_init_common() with HASH_ALGO__LAST which is then used to access the array hash_digest_size[] leading to buffer overrun. Have a conditional statement to handle this.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53110", "url": "https://ubuntu.com/security/CVE-2024-53110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vp_vdpa: fix id_table array not null terminated error Allocate one extra virtio_device_id as null terminator, otherwise vdpa_mgmtdev_get_classes() may iterate multiple times and visit undefined memory.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53126", "url": "https://ubuntu.com/security/CVE-2024-53126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa: solidrun: Fix UB bug with devres In psnet_open_pf_bar() and snet_open_vf_bar() a string later passed to pcim_iomap_regions() is placed on the stack. Neither pcim_iomap_regions() nor the functions it calls copy that string. Should the string later ever be used, this, consequently, causes undefined behavior since the stack frame will by then have disappeared. Fix the bug by allocating the strings on the heap through devm_kasprintf().", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53111", "url": "https://ubuntu.com/security/CVE-2024-53111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mremap: fix address wraparound in move_page_tables() On 32-bit platforms, it is possible for the expression `len + old_addr < old_end` to be false-positive if `len + old_addr` wraps around. `old_addr` is the cursor in the old range up to which page table entries have been moved; so if the operation succeeded, `old_addr` is the *end* of the old region, and adding `len` to it can wrap. The overflow causes mremap() to mistakenly believe that PTEs have been copied; the consequence is that mremap() bails out, but doesn't move the PTEs back before the new VMA is unmapped, causing anonymous pages in the region to be lost. So basically if userspace tries to mremap() a private-anon region and hits this bug, mremap() will return an error and the private-anon region's contents appear to have been zeroed. The idea of this check is that `old_end - len` is the original start address, and writing the check that way also makes it easier to read; so fix the check by rearranging the comparison accordingly. (An alternate fix would be to refactor this function by introducing an \"orig_old_start\" variable or such.) Tested in a VM with a 32-bit X86 kernel; without the patch: ``` user@horn:~/big_mremap$ cat test.c #define _GNU_SOURCE #include #include #include #include #define ADDR1 ((void*)0x60000000) #define ADDR2 ((void*)0x10000000) #define SIZE 0x50000000uL int main(void) { unsigned char *p1 = mmap(ADDR1, SIZE, PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0); if (p1 == MAP_FAILED) err(1, \"mmap 1\"); unsigned char *p2 = mmap(ADDR2, SIZE, PROT_NONE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0); if (p2 == MAP_FAILED) err(1, \"mmap 2\"); *p1 = 0x41; printf(\"first char is 0x%02hhx\\n\", *p1); unsigned char *p3 = mremap(p1, SIZE, SIZE, MREMAP_MAYMOVE|MREMAP_FIXED, p2); if (p3 == MAP_FAILED) { printf(\"mremap() failed; first char is 0x%02hhx\\n\", *p1); } else { printf(\"mremap() succeeded; first char is 0x%02hhx\\n\", *p3); } } user@horn:~/big_mremap$ gcc -static -o test test.c user@horn:~/big_mremap$ setarch -R ./test first char is 0x41 mremap() failed; first char is 0x00 ``` With the patch: ``` user@horn:~/big_mremap$ setarch -R ./test first char is 0x41 mremap() succeeded; first char is 0x41 ```", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53107", "url": "https://ubuntu.com/security/CVE-2024-53107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: prevent integer overflow in pagemap_scan_get_args() The \"arg->vec_len\" variable is a u64 that comes from the user at the start of the function. The \"arg->vec_len * sizeof(struct page_region))\" multiplication can lead to integer wrapping. Use size_mul() to avoid that. Also the size_add/mul() functions work on unsigned long so for 32bit systems we need to ensure that \"arg->vec_len\" fits in an unsigned long.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53128", "url": "https://ubuntu.com/security/CVE-2024-53128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/task_stack: fix object_is_on_stack() for KASAN tagged pointers When CONFIG_KASAN_SW_TAGS and CONFIG_KASAN_STACK are enabled, the object_is_on_stack() function may produce incorrect results due to the presence of tags in the obj pointer, while the stack pointer does not have tags. This discrepancy can lead to incorrect stack object detection and subsequently trigger warnings if CONFIG_DEBUG_OBJECTS is also enabled. Example of the warning: ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at lib/debugobjects.c:557 __debug_object_init+0x330/0x364 Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5 #4 Hardware name: linux,dummy-virt (DT) pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __debug_object_init+0x330/0x364 lr : __debug_object_init+0x330/0x364 sp : ffff800082ea7b40 x29: ffff800082ea7b40 x28: 98ff0000c0164518 x27: 98ff0000c0164534 x26: ffff800082d93ec8 x25: 0000000000000001 x24: 1cff0000c00172a0 x23: 0000000000000000 x22: ffff800082d93ed0 x21: ffff800081a24418 x20: 3eff800082ea7bb0 x19: efff800000000000 x18: 0000000000000000 x17: 00000000000000ff x16: 0000000000000047 x15: 206b63617473206e x14: 0000000000000018 x13: ffff800082ea7780 x12: 0ffff800082ea78e x11: 0ffff800082ea790 x10: 0ffff800082ea79d x9 : 34d77febe173e800 x8 : 34d77febe173e800 x7 : 0000000000000001 x6 : 0000000000000001 x5 : feff800082ea74b8 x4 : ffff800082870a90 x3 : ffff80008018d3c4 x2 : 0000000000000001 x1 : ffff800082858810 x0 : 0000000000000050 Call trace: __debug_object_init+0x330/0x364 debug_object_init_on_stack+0x30/0x3c schedule_hrtimeout_range_clock+0xac/0x26c schedule_hrtimeout+0x1c/0x30 wait_task_inactive+0x1d4/0x25c kthread_bind_mask+0x28/0x98 init_rescuer+0x1e8/0x280 workqueue_init+0x1a0/0x3cc kernel_init_freeable+0x118/0x200 kernel_init+0x28/0x1f0 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53112", "url": "https://ubuntu.com/security/CVE-2024-53112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: uncache inode which has failed entering the group Syzbot has reported the following BUG: kernel BUG at fs/ocfs2/uptodate.c:509! ... Call Trace: ? __die_body+0x5f/0xb0 ? die+0x9e/0xc0 ? do_trap+0x15a/0x3a0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? do_error_trap+0x1dc/0x2c0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? __pfx_do_error_trap+0x10/0x10 ? handle_invalid_op+0x34/0x40 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? exc_invalid_op+0x38/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? ocfs2_set_new_buffer_uptodate+0x2e/0x160 ? ocfs2_set_new_buffer_uptodate+0x144/0x160 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ocfs2_group_add+0x39f/0x15a0 ? __pfx_ocfs2_group_add+0x10/0x10 ? __pfx_lock_acquire+0x10/0x10 ? mnt_get_write_access+0x68/0x2b0 ? __pfx_lock_release+0x10/0x10 ? rcu_read_lock_any_held+0xb7/0x160 ? __pfx_rcu_read_lock_any_held+0x10/0x10 ? smack_log+0x123/0x540 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x226/0x2b0 ocfs2_ioctl+0x65e/0x7d0 ? __pfx_ocfs2_ioctl+0x10/0x10 ? smack_file_ioctl+0x29e/0x3a0 ? __pfx_smack_file_ioctl+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x43d/0x780 ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10 ? __pfx_ocfs2_ioctl+0x10/0x10 __se_sys_ioctl+0xfb/0x170 do_syscall_64+0xf3/0x230 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... When 'ioctl(OCFS2_IOC_GROUP_ADD, ...)' has failed for the particular inode in 'ocfs2_verify_group_and_input()', corresponding buffer head remains cached and subsequent call to the same 'ioctl()' for the same inode issues the BUG() in 'ocfs2_set_new_buffer_uptodate()' (trying to cache the same buffer head of that inode). Fix this by uncaching the buffer head with 'ocfs2_remove_from_cache()' on error path in 'ocfs2_group_add()'.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53113", "url": "https://ubuntu.com/security/CVE-2024-53113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: fix NULL pointer dereference in alloc_pages_bulk_noprof We triggered a NULL pointer dereference for ac.preferred_zoneref->zone in alloc_pages_bulk_noprof() when the task is migrated between cpusets. When cpuset is enabled, in prepare_alloc_pages(), ac->nodemask may be ¤t->mems_allowed. when first_zones_zonelist() is called to find preferred_zoneref, the ac->nodemask may be modified concurrently if the task is migrated between different cpusets. Assuming we have 2 NUMA Node, when traversing Node1 in ac->zonelist, the nodemask is 2, and when traversing Node2 in ac->zonelist, the nodemask is 1. As a result, the ac->preferred_zoneref points to NULL zone. In alloc_pages_bulk_noprof(), for_each_zone_zonelist_nodemask() finds a allowable zone and calls zonelist_node_idx(ac.preferred_zoneref), leading to NULL pointer dereference. __alloc_pages_noprof() fixes this issue by checking NULL pointer in commit ea57485af8f4 (\"mm, page_alloc: fix check for NULL preferred_zone\") and commit df76cee6bbeb (\"mm, page_alloc: remove redundant checks from alloc fastpath\"). To fix it, check NULL pointer for preferred_zoneref->zone.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53114", "url": "https://ubuntu.com/security/CVE-2024-53114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 client A number of Zen4 client SoCs advertise the ability to use virtualized VMLOAD/VMSAVE, but using these instructions is reported to be a cause of a random host reboot. These instructions aren't intended to be advertised on Zen4 client so clear the capability.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53137", "url": "https://ubuntu.com/security/CVE-2024-53137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: fix cacheflush with PAN It seems that the cacheflush syscall got broken when PAN for LPAE was implemented. User access was not enabled around the cache maintenance instructions, causing them to fault.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53115", "url": "https://ubuntu.com/security/CVE-2024-53115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: avoid null_ptr_deref in vmw_framebuffer_surface_create_handle The 'vmw_user_object_buffer' function may return NULL with incorrect inputs. To avoid possible null pointer dereference, add a check whether the 'bo' is NULL in the vmw_framebuffer_surface_create_handle.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53116", "url": "https://ubuntu.com/security/CVE-2024-53116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix handling of partial GPU mapping of BOs This commit fixes the bug in the handling of partial mapping of the buffer objects to the GPU, which caused kernel warnings. Panthor didn't correctly handle the case where the partial mapping spanned multiple scatterlists and the mapping offset didn't point to the 1st page of starting scatterlist. The offset variable was not cleared after reaching the starting scatterlist. Following warning messages were seen. WARNING: CPU: 1 PID: 650 at drivers/iommu/io-pgtable-arm.c:659 __arm_lpae_unmap+0x254/0x5a0 pc : __arm_lpae_unmap+0x254/0x5a0 lr : __arm_lpae_unmap+0x2cc/0x5a0 Call trace: __arm_lpae_unmap+0x254/0x5a0 __arm_lpae_unmap+0x108/0x5a0 __arm_lpae_unmap+0x108/0x5a0 __arm_lpae_unmap+0x108/0x5a0 arm_lpae_unmap_pages+0x80/0xa0 panthor_vm_unmap_pages+0xac/0x1c8 [panthor] panthor_gpuva_sm_step_unmap+0x4c/0xc8 [panthor] op_unmap_cb.isra.23.constprop.30+0x54/0x80 __drm_gpuvm_sm_unmap+0x184/0x1c8 drm_gpuvm_sm_unmap+0x40/0x60 panthor_vm_exec_op+0xa8/0x120 [panthor] panthor_vm_bind_exec_sync_op+0xc4/0xe8 [panthor] panthor_ioctl_vm_bind+0x10c/0x170 [panthor] drm_ioctl_kernel+0xbc/0x138 drm_ioctl+0x210/0x4b0 __arm64_sys_ioctl+0xb0/0xf8 invoke_syscall+0x4c/0x110 el0_svc_common.constprop.1+0x98/0xf8 do_el0_svc+0x24/0x38 el0_svc+0x34/0xc8 el0t_64_sync_handler+0xa0/0xc8 el0t_64_sync+0x174/0x178 panthor : [drm] drm_WARN_ON(unmapped_sz != pgsize * pgcount) WARNING: CPU: 1 PID: 650 at drivers/gpu/drm/panthor/panthor_mmu.c:922 panthor_vm_unmap_pages+0x124/0x1c8 [panthor] pc : panthor_vm_unmap_pages+0x124/0x1c8 [panthor] lr : panthor_vm_unmap_pages+0x124/0x1c8 [panthor] panthor : [drm] *ERROR* failed to unmap range ffffa388f000-ffffa3890000 (requested range ffffa388c000-ffffa3890000)", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53117", "url": "https://ubuntu.com/security/CVE-2024-53117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio/vsock: Improve MSG_ZEROCOPY error handling Add a missing kfree_skb() to prevent memory leaks.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53118", "url": "https://ubuntu.com/security/CVE-2024-53118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Fix sk_error_queue memory leak Kernel queues MSG_ZEROCOPY completion notifications on the error queue. Where they remain, until explicitly recv()ed. To prevent memory leaks, clean up the queue when the socket is destroyed. unreferenced object 0xffff8881028beb00 (size 224): comm \"vsock_test\", pid 1218, jiffies 4294694897 hex dump (first 32 bytes): 90 b0 21 17 81 88 ff ff 90 b0 21 17 81 88 ff ff ..!.......!..... 00 00 00 00 00 00 00 00 00 b0 21 17 81 88 ff ff ..........!..... backtrace (crc 6c7031ca): [] kmem_cache_alloc_node_noprof+0x2f7/0x370 [] __alloc_skb+0x132/0x180 [] sock_omalloc+0x4b/0x80 [] msg_zerocopy_realloc+0x9e/0x240 [] virtio_transport_send_pkt_info+0x412/0x4c0 [] virtio_transport_stream_enqueue+0x43/0x50 [] vsock_connectible_sendmsg+0x373/0x450 [] ____sys_sendmsg+0x365/0x3a0 [] ___sys_sendmsg+0x84/0xd0 [] __sys_sendmsg+0x47/0x80 [] do_syscall_64+0x93/0x180 [] entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53119", "url": "https://ubuntu.com/security/CVE-2024-53119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio/vsock: Fix accept_queue memory leak As the final stages of socket destruction may be delayed, it is possible that virtio_transport_recv_listen() will be called after the accept_queue has been flushed, but before the SOCK_DONE flag has been set. As a result, sockets enqueued after the flush would remain unremoved, leading to a memory leak. vsock_release __vsock_release lock virtio_transport_release virtio_transport_close schedule_delayed_work(close_work) sk_shutdown = SHUTDOWN_MASK (!) flush accept_queue release virtio_transport_recv_pkt vsock_find_bound_socket lock if flag(SOCK_DONE) return virtio_transport_recv_listen child = vsock_create_connected (!) vsock_enqueue_accept(child) release close_work lock virtio_transport_do_close set_flag(SOCK_DONE) virtio_transport_remove_sock vsock_remove_sock vsock_remove_bound release Introduce a sk_shutdown check to disallow vsock_enqueue_accept() during socket destruction. unreferenced object 0xffff888109e3f800 (size 2040): comm \"kworker/5:2\", pid 371, jiffies 4294940105 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00 (..@............ backtrace (crc 9e5f4e84): [] kmem_cache_alloc_noprof+0x2c1/0x360 [] sk_prot_alloc+0x30/0x120 [] sk_alloc+0x2c/0x4b0 [] __vsock_create.constprop.0+0x2a/0x310 [] virtio_transport_recv_pkt+0x4dc/0x9a0 [] vsock_loopback_work+0xfd/0x140 [] process_one_work+0x20c/0x570 [] worker_thread+0x1bf/0x3a0 [] kthread+0xdd/0x110 [] ret_from_fork+0x2d/0x50 [] ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53120", "url": "https://ubuntu.com/security/CVE-2024-53120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: CT: Fix null-ptr-deref in add rule err flow In error flow of mlx5_tc_ct_entry_add_rule(), in case ct_rule_add() callback returns error, zone_rule->attr is used uninitiated. Fix it to use attr which has the needed pointer value. Kernel log: BUG: kernel NULL pointer dereference, address: 0000000000000110 RIP: 0010:mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core] … Call Trace: ? __die+0x20/0x70 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x140 ? asm_exc_page_fault+0x22/0x30 ? mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core] ? mlx5_tc_ct_entry_add_rule+0x1d5/0x2f0 [mlx5_core] mlx5_tc_ct_block_flow_offload+0xc6a/0xf90 [mlx5_core] ? nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] flow_offload_work_handler+0x142/0x320 [nf_flow_table] ? finish_task_switch.isra.0+0x15b/0x2b0 process_one_work+0x16c/0x320 worker_thread+0x28c/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xb8/0xf0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53138", "url": "https://ubuntu.com/security/CVE-2024-53138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: kTLS, Fix incorrect page refcounting The kTLS tx handling code is using a mix of get_page() and page_ref_inc() APIs to increment the page reference. But on the release path (mlx5e_ktls_tx_handle_resync_dump_comp()), only put_page() is used. This is an issue when using pages from large folios: the get_page() references are stored on the folio page while the page_ref_inc() references are stored directly in the given page. On release the folio page will be dereferenced too many times. This was found while doing kTLS testing with sendfile() + ZC when the served file was read from NFS on a kernel with NFS large folios support (commit 49b29a573da8 (\"nfs: add support for large folios\")).", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53121", "url": "https://ubuntu.com/security/CVE-2024-53121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: fs, lock FTE when checking if active The referenced commits introduced a two-step process for deleting FTEs: - Lock the FTE, delete it from hardware, set the hardware deletion function to NULL and unlock the FTE. - Lock the parent flow group, delete the software copy of the FTE, and remove it from the xarray. However, this approach encounters a race condition if a rule with the same match value is added simultaneously. In this scenario, fs_core may set the hardware deletion function to NULL prematurely, causing a panic during subsequent rule deletions. To prevent this, ensure the active flag of the FTE is checked under a lock, which will prevent the fs_core layer from attaching a new steering rule to an FTE that is in the process of deletion. [ 438.967589] MOSHE: 2496 mlx5_del_flow_rules del_hw_func [ 438.968205] ------------[ cut here ]------------ [ 438.968654] refcount_t: decrement hit 0; leaking memory. [ 438.969249] WARNING: CPU: 0 PID: 8957 at lib/refcount.c:31 refcount_warn_saturate+0xfb/0x110 [ 438.970054] Modules linked in: act_mirred cls_flower act_gact sch_ingress openvswitch nsh mlx5_vdpa vringh vhost_iotlb vdpa mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core zram zsmalloc fuse [last unloaded: cls_flower] [ 438.973288] CPU: 0 UID: 0 PID: 8957 Comm: tc Not tainted 6.12.0-rc1+ #8 [ 438.973888] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 438.974874] RIP: 0010:refcount_warn_saturate+0xfb/0x110 [ 438.975363] Code: 40 66 3b 82 c6 05 16 e9 4d 01 01 e8 1f 7c a0 ff 0f 0b c3 cc cc cc cc 48 c7 c7 10 66 3b 82 c6 05 fd e8 4d 01 01 e8 05 7c a0 ff <0f> 0b c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 90 [ 438.976947] RSP: 0018:ffff888124a53610 EFLAGS: 00010286 [ 438.977446] RAX: 0000000000000000 RBX: ffff888119d56de0 RCX: 0000000000000000 [ 438.978090] RDX: ffff88852c828700 RSI: ffff88852c81b3c0 RDI: ffff88852c81b3c0 [ 438.978721] RBP: ffff888120fa0e88 R08: 0000000000000000 R09: ffff888124a534b0 [ 438.979353] R10: 0000000000000001 R11: 0000000000000001 R12: ffff888119d56de0 [ 438.979979] R13: ffff888120fa0ec0 R14: ffff888120fa0ee8 R15: ffff888119d56de0 [ 438.980607] FS: 00007fe6dcc0f800(0000) GS:ffff88852c800000(0000) knlGS:0000000000000000 [ 438.983984] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 438.984544] CR2: 00000000004275e0 CR3: 0000000186982001 CR4: 0000000000372eb0 [ 438.985205] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 438.985842] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 438.986507] Call Trace: [ 438.986799] [ 438.987070] ? __warn+0x7d/0x110 [ 438.987426] ? refcount_warn_saturate+0xfb/0x110 [ 438.987877] ? report_bug+0x17d/0x190 [ 438.988261] ? prb_read_valid+0x17/0x20 [ 438.988659] ? handle_bug+0x53/0x90 [ 438.989054] ? exc_invalid_op+0x14/0x70 [ 438.989458] ? asm_exc_invalid_op+0x16/0x20 [ 438.989883] ? refcount_warn_saturate+0xfb/0x110 [ 438.990348] mlx5_del_flow_rules+0x2f7/0x340 [mlx5_core] [ 438.990932] __mlx5_eswitch_del_rule+0x49/0x170 [mlx5_core] [ 438.991519] ? mlx5_lag_is_sriov+0x3c/0x50 [mlx5_core] [ 438.992054] ? xas_load+0x9/0xb0 [ 438.992407] mlx5e_tc_rule_unoffload+0x45/0xe0 [mlx5_core] [ 438.993037] mlx5e_tc_del_fdb_flow+0x2a6/0x2e0 [mlx5_core] [ 438.993623] mlx5e_flow_put+0x29/0x60 [mlx5_core] [ 438.994161] mlx5e_delete_flower+0x261/0x390 [mlx5_core] [ 438.994728] tc_setup_cb_destroy+0xb9/0x190 [ 438.995150] fl_hw_destroy_filter+0x94/0xc0 [cls_flower] [ 438.995650] fl_change+0x11a4/0x13c0 [cls_flower] [ 438.996105] tc_new_tfilter+0x347/0xbc0 [ 438.996503] ? __ ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53122", "url": "https://ubuntu.com/security/CVE-2024-53122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: cope racing subflow creation in mptcp_rcv_space_adjust Additional active subflows - i.e. created by the in kernel path manager - are included into the subflow list before starting the 3whs. A racing recvmsg() spooling data received on an already established subflow would unconditionally call tcp_cleanup_rbuf() on all the current subflows, potentially hitting a divide by zero error on the newly created ones. Explicitly check that the subflow is in a suitable state before invoking tcp_cleanup_rbuf().", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53123", "url": "https://ubuntu.com/security/CVE-2024-53123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: error out earlier on disconnect Eric reported a division by zero splat in the MPTCP protocol: Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 6094 Comm: syz-executor317 Not tainted 6.12.0-rc5-syzkaller-00291-g05b92660cdfe #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:__tcp_select_window+0x5b4/0x1310 net/ipv4/tcp_output.c:3163 Code: f6 44 01 e3 89 df e8 9b 75 09 f8 44 39 f3 0f 8d 11 ff ff ff e8 0d 74 09 f8 45 89 f4 e9 04 ff ff ff e8 00 74 09 f8 44 89 f0 99 7c 24 14 41 29 d6 45 89 f4 e9 ec fe ff ff e8 e8 73 09 f8 48 89 RSP: 0018:ffffc900041f7930 EFLAGS: 00010293 RAX: 0000000000017e67 RBX: 0000000000017e67 RCX: ffffffff8983314b RDX: 0000000000000000 RSI: ffffffff898331b0 RDI: 0000000000000004 RBP: 00000000005d6000 R08: 0000000000000004 R09: 0000000000017e67 R10: 0000000000003e80 R11: 0000000000000000 R12: 0000000000003e80 R13: ffff888031d9b440 R14: 0000000000017e67 R15: 00000000002eb000 FS: 00007feb5d7f16c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007feb5d8adbb8 CR3: 0000000074e4c000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __tcp_cleanup_rbuf+0x3e7/0x4b0 net/ipv4/tcp.c:1493 mptcp_rcv_space_adjust net/mptcp/protocol.c:2085 [inline] mptcp_recvmsg+0x2156/0x2600 net/mptcp/protocol.c:2289 inet_recvmsg+0x469/0x6a0 net/ipv4/af_inet.c:885 sock_recvmsg_nosec net/socket.c:1051 [inline] sock_recvmsg+0x1b2/0x250 net/socket.c:1073 __sys_recvfrom+0x1a5/0x2e0 net/socket.c:2265 __do_sys_recvfrom net/socket.c:2283 [inline] __se_sys_recvfrom net/socket.c:2279 [inline] __x64_sys_recvfrom+0xe0/0x1c0 net/socket.c:2279 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 RIP: 0033:0x7feb5d857559 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:00007feb5d7f1208 EFLAGS: 00000246 ORIG_RAX: 000000000000002d RAX: ffffffffffffffda RBX: 00007feb5d8e1318 RCX: 00007feb5d857559 RDX: 000000800000000e RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007feb5d8e1310 R08: 0000000000000000 R09: ffffffff81000000 R10: 0000000000000100 R11: 0000000000000246 R12: 00007feb5d8e131c R13: 00007feb5d8ae074 R14: 000000800000000e R15: 00000000fffffdef and provided a nice reproducer. The root cause is the current bad handling of racing disconnect. After the blamed commit below, sk_wait_data() can return (with error) with the underlying socket disconnected and a zero rcv_mss. Catch the error and return without performing any additional operations on the current socket.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53124", "url": "https://ubuntu.com/security/CVE-2024-53124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix data-races around sk->sk_forward_alloc Syzkaller reported this warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 16 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x1c5/0x1e0 Modules linked in: CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:inet_sock_destruct+0x1c5/0x1e0 Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 <0f> 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00 RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206 RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007 RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00 RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007 R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00 R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78 FS: 0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn+0x88/0x130 ? inet_sock_destruct+0x1c5/0x1e0 ? report_bug+0x18e/0x1a0 ? handle_bug+0x53/0x90 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? inet_sock_destruct+0x1c5/0x1e0 __sk_destruct+0x2a/0x200 rcu_do_batch+0x1aa/0x530 ? rcu_do_batch+0x13b/0x530 rcu_core+0x159/0x2f0 handle_softirqs+0xd3/0x2b0 ? __pfx_smpboot_thread_fn+0x10/0x10 run_ksoftirqd+0x25/0x30 smpboot_thread_fn+0xdd/0x1d0 kthread+0xd3/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ---[ end trace 0000000000000000 ]--- Its possible that two threads call tcp_v6_do_rcv()/sk_forward_alloc_add() concurrently when sk->sk_state == TCP_LISTEN with sk->sk_lock unlocked, which triggers a data-race around sk->sk_forward_alloc: tcp_v6_rcv tcp_v6_do_rcv skb_clone_and_charge_r sk_rmem_schedule __sk_mem_schedule sk_forward_alloc_add() skb_set_owner_r sk_mem_charge sk_forward_alloc_add() __kfree_skb skb_release_all skb_release_head_state sock_rfree sk_mem_uncharge sk_forward_alloc_add() sk_mem_reclaim // set local var reclaimable __sk_mem_reclaim sk_forward_alloc_add() In this syzkaller testcase, two threads call tcp_v6_do_rcv() with skb->truesize=768, the sk_forward_alloc changes like this: (cpu 1) | (cpu 2) | sk_forward_alloc ... | ... | 0 __sk_mem_schedule() | | +4096 = 4096 | __sk_mem_schedule() | +4096 = 8192 sk_mem_charge() | | -768 = 7424 | sk_mem_charge() | -768 = 6656 ... | ... | sk_mem_uncharge() | | +768 = 7424 reclaimable=7424 | | | sk_mem_uncharge() | +768 = 8192 | reclaimable=8192 | __sk_mem_reclaim() | | -4096 = 4096 | __sk_mem_reclaim() | -8192 = -4096 != 0 The skb_clone_and_charge_r() should not be called in tcp_v6_do_rcv() when sk->sk_state is TCP_LISTEN, it happens later in tcp_v6_syn_recv_sock(). Fix the same issue in dccp_v6_do_rcv().", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53129", "url": "https://ubuntu.com/security/CVE-2024-53129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: vop: Fix a dereferenced before check warning The 'state' can't be NULL, we should check crtc_state. Fix warning: drivers/gpu/drm/rockchip/rockchip_drm_vop.c:1096 vop_plane_atomic_async_check() warn: variable dereferenced before check 'state' (see line 1077)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53139", "url": "https://ubuntu.com/security/CVE-2024-53139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix possible UAF in sctp_v6_available() A lockdep report [1] with CONFIG_PROVE_RCU_LIST=y hints that sctp_v6_available() is calling dev_get_by_index_rcu() and ipv6_chk_addr() without holding rcu. [1] ============================= WARNING: suspicious RCU usage 6.12.0-rc5-virtme #1216 Tainted: G W ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by sctp_hello/31495: #0: ffff9f1ebbdb7418 (sk_lock-AF_INET6){+.+.}-{0:0}, at: sctp_bind (./arch/x86/include/asm/jump_label.h:27 net/sctp/socket.c:315) sctp stack backtrace: CPU: 7 UID: 0 PID: 31495 Comm: sctp_hello Tainted: G W 6.12.0-rc5-virtme #1216 Tainted: [W]=WARN 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:123) lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822) dev_get_by_index_rcu (net/core/dev.c:876 (discriminator 7)) sctp_v6_available (net/sctp/ipv6.c:701) sctp sctp_do_bind (net/sctp/socket.c:400 (discriminator 1)) sctp sctp_bind (net/sctp/socket.c:320) sctp inet6_bind_sk (net/ipv6/af_inet6.c:465) ? security_socket_bind (security/security.c:4581 (discriminator 1)) __sys_bind (net/socket.c:1848 net/socket.c:1869) ? do_user_addr_fault (./include/linux/rcupdate.h:347 ./include/linux/rcupdate.h:880 ./include/linux/mm.h:729 arch/x86/mm/fault.c:1340) ? do_user_addr_fault (./arch/x86/include/asm/preempt.h:84 (discriminator 13) ./include/linux/rcupdate.h:98 (discriminator 13) ./include/linux/rcupdate.h:882 (discriminator 13) ./include/linux/mm.h:729 (discriminator 13) arch/x86/mm/fault.c:1340 (discriminator 13)) __x64_sys_bind (net/socket.c:1877 (discriminator 1) net/socket.c:1875 (discriminator 1) net/socket.c:1875 (discriminator 1)) do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f59b934a1e7 Code: 44 00 00 48 8b 15 39 8c 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 b8 31 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 09 8c 0c 00 f7 d8 64 89 01 48 All code ======== 0:\t44 00 00 \tadd %r8b,(%rax) 3:\t48 8b 15 39 8c 0c 00 \tmov 0xc8c39(%rip),%rdx # 0xc8c43 a:\tf7 d8 \tneg %eax c:\t64 89 02 \tmov %eax,%fs:(%rdx) f:\tb8 ff ff ff ff \tmov $0xffffffff,%eax 14:\teb bd \tjmp 0xffffffffffffffd3 16:\t66 2e 0f 1f 84 00 00 \tcs nopw 0x0(%rax,%rax,1) 1d:\t00 00 00 20:\t0f 1f 00 \tnopl (%rax) 23:\tb8 31 00 00 00 \tmov $0x31,%eax 28:\t0f 05 \tsyscall 2a:*\t48 3d 01 f0 ff ff \tcmp $0xfffffffffffff001,%rax\t\t<-- trapping instruction 30:\t73 01 \tjae 0x33 32:\tc3 \tret 33:\t48 8b 0d 09 8c 0c 00 \tmov 0xc8c09(%rip),%rcx # 0xc8c43 3a:\tf7 d8 \tneg %eax 3c:\t64 89 01 \tmov %eax,%fs:(%rcx) 3f:\t48 \trex.W Code starting with the faulting instruction =========================================== 0:\t48 3d 01 f0 ff ff \tcmp $0xfffffffffffff001,%rax 6:\t73 01 \tjae 0x9 8:\tc3 \tret 9:\t48 8b 0d 09 8c 0c 00 \tmov 0xc8c09(%rip),%rcx # 0xc8c19 10:\tf7 d8 \tneg %eax 12:\t64 89 01 \tmov %eax,%fs:(%rcx) 15:\t48 \trex.W RSP: 002b:00007ffe2d0ad398 EFLAGS: 00000202 ORIG_RAX: 0000000000000031 RAX: ffffffffffffffda RBX: 00007ffe2d0ad3d0 RCX: 00007f59b934a1e7 RDX: 000000000000001c RSI: 00007ffe2d0ad3d0 RDI: 0000000000000005 RBP: 0000000000000005 R08: 1999999999999999 R09: 0000000000000000 R10: 00007f59b9253298 R11: 000000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53140", "url": "https://ubuntu.com/security/CVE-2024-53140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netlink: terminate outstanding dump on socket close Netlink supports iterative dumping of data. It provides the families the following ops: - start - (optional) kicks off the dumping process - dump - actual dump helper, keeps getting called until it returns 0 - done - (optional) pairs with .start, can be used for cleanup The whole process is asynchronous and the repeated calls to .dump don't actually happen in a tight loop, but rather are triggered in response to recvmsg() on the socket. This gives the user full control over the dump, but also means that the user can close the socket without getting to the end of the dump. To make sure .start is always paired with .done we check if there is an ongoing dump before freeing the socket, and if so call .done. The complication is that sockets can get freed from BH and .done is allowed to sleep. So we use a workqueue to defer the call, when needed. Unfortunately this does not work correctly. What we defer is not the cleanup but rather releasing a reference on the socket. We have no guarantee that we own the last reference, if someone else holds the socket they may release it in BH and we're back to square one. The whole dance, however, appears to be unnecessary. Only the user can interact with dumps, so we can clean up when socket is closed. And close always happens in process context. Some async code may still access the socket after close, queue notification skbs to it etc. but no dumps can start, end or otherwise make progress. Delete the workqueue and flush the dump state directly from the release handler. Note that further cleanup is possible in -next, for instance we now always call .done before releasing the main module reference, so dump doesn't have to take a reference of its own.", "cve_priority": "high", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53098", "url": "https://ubuntu.com/security/CVE-2024-53098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/ufence: Prefetch ufence addr to catch bogus address access_ok() only checks for addr overflow so also try to read the addr to catch invalid addr sent from userspace. (cherry picked from commit 9408c4508483ffc60811e910a93d6425b8e63928)", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53099", "url": "https://ubuntu.com/security/CVE-2024-53099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check validity of link->type in bpf_link_show_fdinfo() If a newly-added link type doesn't invoke BPF_LINK_TYPE(), accessing bpf_link_type_strs[link->type] may result in an out-of-bounds access. To spot such missed invocations early in the future, checking the validity of link->type in bpf_link_show_fdinfo() and emitting a warning when such invocations are missed.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53089", "url": "https://ubuntu.com/security/CVE-2024-53089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: KVM: Mark hrtimer to expire in hard interrupt context Like commit 2c0d278f3293f (\"KVM: LAPIC: Mark hrtimer to expire in hard interrupt context\") and commit 9090825fa9974 (\"KVM: arm/arm64: Let the timer expire in hardirq context on RT\"), On PREEMPT_RT enabled kernels unmarked hrtimers are moved into soft interrupt expiry mode by default. Then the timers are canceled from an preempt-notifier which is invoked with disabled preemption which is not allowed on PREEMPT_RT. The timer callback is short so in could be invoked in hard-IRQ context. So let the timer expire on hard-IRQ context even on -RT. This fix a \"scheduling while atomic\" bug for PREEMPT_RT enabled kernels: BUG: scheduling while atomic: qemu-system-loo/1011/0x00000002 Modules linked in: amdgpu rfkill nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat ns CPU: 1 UID: 0 PID: 1011 Comm: qemu-system-loo Tainted: G W 6.12.0-rc2+ #1774 Tainted: [W]=WARN Hardware name: Loongson Loongson-3A5000-7A1000-1w-CRB/Loongson-LS3A5000-7A1000-1w-CRB, BIOS vUDK2018-LoongArch-V2.0.0-prebeta9 10/21/2022 Stack : ffffffffffffffff 0000000000000000 9000000004e3ea38 9000000116744000 90000001167475a0 0000000000000000 90000001167475a8 9000000005644830 90000000058dc000 90000000058dbff8 9000000116747420 0000000000000001 0000000000000001 6a613fc938313980 000000000790c000 90000001001c1140 00000000000003fe 0000000000000001 000000000000000d 0000000000000003 0000000000000030 00000000000003f3 000000000790c000 9000000116747830 90000000057ef000 0000000000000000 9000000005644830 0000000000000004 0000000000000000 90000000057f4b58 0000000000000001 9000000116747868 900000000451b600 9000000005644830 9000000003a13998 0000000010000020 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d ... Call Trace: [<9000000003a13998>] show_stack+0x38/0x180 [<9000000004e3ea34>] dump_stack_lvl+0x84/0xc0 [<9000000003a71708>] __schedule_bug+0x48/0x60 [<9000000004e45734>] __schedule+0x1114/0x1660 [<9000000004e46040>] schedule_rtlock+0x20/0x60 [<9000000004e4e330>] rtlock_slowlock_locked+0x3f0/0x10a0 [<9000000004e4f038>] rt_spin_lock+0x58/0x80 [<9000000003b02d68>] hrtimer_cancel_wait_running+0x68/0xc0 [<9000000003b02e30>] hrtimer_cancel+0x70/0x80 [] kvm_restore_timer+0x50/0x1a0 [kvm] [] kvm_arch_vcpu_load+0x68/0x2a0 [kvm] [] kvm_sched_in+0x34/0x60 [kvm] [<9000000003a749a0>] finish_task_switch.isra.0+0x140/0x2e0 [<9000000004e44a70>] __schedule+0x450/0x1660 [<9000000004e45cb0>] schedule+0x30/0x180 [] kvm_vcpu_block+0x70/0x120 [kvm] [] kvm_vcpu_halt+0x60/0x3e0 [kvm] [] kvm_handle_gspr+0x3f4/0x4e0 [kvm] [] kvm_handle_exit+0x1c8/0x260 [kvm]", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53090", "url": "https://ubuntu.com/security/CVE-2024-53090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix lock recursion afs_wake_up_async_call() can incur lock recursion. The problem is that it is called from AF_RXRPC whilst holding the ->notify_lock, but it tries to take a ref on the afs_call struct in order to pass it to a work queue - but if the afs_call is already queued, we then have an extraneous ref that must be put... calling afs_put_call() may call back down into AF_RXRPC through rxrpc_kernel_shutdown_call(), however, which might try taking the ->notify_lock again. This case isn't very common, however, so defer it to a workqueue. The oops looks something like: BUG: spinlock recursion on CPU#0, krxrpcio/7001/1646 lock: 0xffff888141399b30, .magic: dead4ead, .owner: krxrpcio/7001/1646, .owner_cpu: 0 CPU: 0 UID: 0 PID: 1646 Comm: krxrpcio/7001 Not tainted 6.12.0-rc2-build3+ #4351 Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014 Call Trace: dump_stack_lvl+0x47/0x70 do_raw_spin_lock+0x3c/0x90 rxrpc_kernel_shutdown_call+0x83/0xb0 afs_put_call+0xd7/0x180 rxrpc_notify_socket+0xa0/0x190 rxrpc_input_split_jumbo+0x198/0x1d0 rxrpc_input_data+0x14b/0x1e0 ? rxrpc_input_call_packet+0xc2/0x1f0 rxrpc_input_call_event+0xad/0x6b0 rxrpc_input_packet_on_conn+0x1e1/0x210 rxrpc_input_packet+0x3f2/0x4d0 rxrpc_io_thread+0x243/0x410 ? __pfx_rxrpc_io_thread+0x10/0x10 kthread+0xcf/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x24/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53101", "url": "https://ubuntu.com/security/CVE-2024-53101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized value issue in from_kuid and from_kgid ocfs2_setattr() uses attr->ia_mode, attr->ia_uid and attr->ia_gid in a trace point even though ATTR_MODE, ATTR_UID and ATTR_GID aren't set. Initialize all fields of newattrs to avoid uninitialized variables, by checking if ATTR_MODE, ATTR_UID, ATTR_GID are initialized, otherwise 0.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53091", "url": "https://ubuntu.com/security/CVE-2024-53091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Add sk_is_inet and IS_ICSK check in tls_sw_has_ctx_tx/rx As the introduction of the support for vsock and unix sockets in sockmap, tls_sw_has_ctx_tx/rx cannot presume the socket passed in must be IS_ICSK. vsock and af_unix sockets have vsock_sock and unix_sock instead of inet_connection_sock. For these sockets, tls_get_ctx may return an invalid pointer and cause page fault in function tls_sw_ctx_rx. BUG: unable to handle page fault for address: 0000000000040030 Workqueue: vsock-loopback vsock_loopback_work RIP: 0010:sk_psock_strp_data_ready+0x23/0x60 Call Trace: ? __die+0x81/0xc3 ? no_context+0x194/0x350 ? do_page_fault+0x30/0x110 ? async_page_fault+0x3e/0x50 ? sk_psock_strp_data_ready+0x23/0x60 virtio_transport_recv_pkt+0x750/0x800 ? update_load_avg+0x7e/0x620 vsock_loopback_work+0xd0/0x100 process_one_work+0x1a7/0x360 worker_thread+0x30/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x112/0x130 ? __kthread_cancel_work+0x40/0x40 ret_from_fork+0x1f/0x40 v2: - Add IS_ICSK check v3: - Update the commits in Fixes", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53092", "url": "https://ubuntu.com/security/CVE-2024-53092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_pci: Fix admin vq cleanup by using correct info pointer vp_modern_avq_cleanup() and vp_del_vqs() clean up admin vq resources by virtio_pci_vq_info pointer. The info pointer of admin vq is stored in vp_dev->admin_vq.info instead of vp_dev->vqs[]. Using the info pointer from vp_dev->vqs[] for admin vq causes a kernel NULL pointer dereference bug. In vp_modern_avq_cleanup() and vp_del_vqs(), get the info pointer from vp_dev->admin_vq.info for admin vq to clean up the resources. Also make info ptr as argument of vp_del_vq() to be symmetric with vp_setup_vq(). vp_reset calls vp_modern_avq_cleanup, and causes the Call Trace: ================================================================== BUG: kernel NULL pointer dereference, address:0000000000000000 ... CPU: 49 UID: 0 PID: 4439 Comm: modprobe Not tainted 6.11.0-rc5 #1 RIP: 0010:vp_reset+0x57/0x90 [virtio_pci] Call Trace: ... ? vp_reset+0x57/0x90 [virtio_pci] ? vp_reset+0x38/0x90 [virtio_pci] virtio_reset_device+0x1d/0x30 remove_vq_common+0x1c/0x1a0 [virtio_net] virtnet_remove+0xa1/0xc0 [virtio_net] virtio_dev_remove+0x46/0xa0 ... virtio_pci_driver_exit+0x14/0x810 [virtio_pci] ==================================================================", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53102", "url": "https://ubuntu.com/security/CVE-2024-53102", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53093", "url": "https://ubuntu.com/security/CVE-2024-53093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: defer partition scanning We need to suppress the partition scan from occuring within the controller's scan_work context. If a path error occurs here, the IO will wait until a path becomes available or all paths are torn down, but that action also occurs within scan_work, so it would deadlock. Defer the partion scan to a different context that does not block scan_work.", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53094", "url": "https://ubuntu.com/security/CVE-2024-53094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Add sendpage_ok() check to disable MSG_SPLICE_PAGES While running ISER over SIW, the initiator machine encounters a warning from skb_splice_from_iter() indicating that a slab page is being used in send_page. To address this, it is better to add a sendpage_ok() check within the driver itself, and if it returns 0, then MSG_SPLICE_PAGES flag should be disabled before entering the network stack. A similar issue has been discussed for NVMe in this thread: https://lore.kernel.org/all/20240530142417.146696-1-ofir.gal@volumez.com/ WARNING: CPU: 0 PID: 5342 at net/core/skbuff.c:7140 skb_splice_from_iter+0x173/0x320 Call Trace: tcp_sendmsg_locked+0x368/0xe40 siw_tx_hdt+0x695/0xa40 [siw] siw_qp_sq_process+0x102/0xb00 [siw] siw_sq_resume+0x39/0x110 [siw] siw_run_sq+0x74/0x160 [siw] kthread+0xd2/0x100 ret_from_fork+0x34/0x40 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53100", "url": "https://ubuntu.com/security/CVE-2024-53100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: tcp: avoid race between queue_lock lock and destroy Commit 76d54bf20cdc (\"nvme-tcp: don't access released socket during error recovery\") added a mutex_lock() call for the queue->queue_lock in nvme_tcp_get_address(). However, the mutex_lock() races with mutex_destroy() in nvme_tcp_free_queue(), and causes the WARN below. DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: CPU: 3 PID: 34077 at kernel/locking/mutex.c:587 __mutex_lock+0xcf0/0x1220 Modules linked in: nvmet_tcp nvmet nvme_tcp nvme_fabrics iw_cm ib_cm ib_core pktcdvd nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables qrtr sunrpc ppdev 9pnet_virtio 9pnet pcspkr netfs parport_pc parport e1000 i2c_piix4 i2c_smbus loop fuse nfnetlink zram bochs drm_vram_helper drm_ttm_helper ttm drm_kms_helper xfs drm sym53c8xx floppy nvme scsi_transport_spi nvme_core nvme_auth serio_raw ata_generic pata_acpi dm_multipath qemu_fw_cfg [last unloaded: ib_uverbs] CPU: 3 UID: 0 PID: 34077 Comm: udisksd Not tainted 6.11.0-rc7 #319 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:__mutex_lock+0xcf0/0x1220 Code: 08 84 d2 0f 85 c8 04 00 00 8b 15 ef b6 c8 01 85 d2 0f 85 78 f4 ff ff 48 c7 c6 20 93 ee af 48 c7 c7 60 91 ee af e8 f0 a7 6d fd <0f> 0b e9 5e f4 ff ff 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 RSP: 0018:ffff88811305f760 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff88812c652058 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000001 RBP: ffff88811305f8b0 R08: 0000000000000001 R09: ffffed1075c36341 R10: ffff8883ae1b1a0b R11: 0000000000010498 R12: 0000000000000000 R13: 0000000000000000 R14: dffffc0000000000 R15: ffff88812c652058 FS: 00007f9713ae4980(0000) GS:ffff8883ae180000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcd78483c7c CR3: 0000000122c38000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn.cold+0x5b/0x1af ? __mutex_lock+0xcf0/0x1220 ? report_bug+0x1ec/0x390 ? handle_bug+0x3c/0x80 ? exc_invalid_op+0x13/0x40 ? asm_exc_invalid_op+0x16/0x20 ? __mutex_lock+0xcf0/0x1220 ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] ? __pfx___mutex_lock+0x10/0x10 ? __lock_acquire+0xd6a/0x59e0 ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] ? __pfx_nvme_tcp_get_address+0x10/0x10 [nvme_tcp] nvme_sysfs_show_address+0x81/0xc0 [nvme_core] dev_attr_show+0x42/0x80 ? __asan_memset+0x1f/0x40 sysfs_kf_seq_show+0x1f0/0x370 seq_read_iter+0x2cb/0x1130 ? rw_verify_area+0x3b1/0x590 ? __mutex_lock+0x433/0x1220 vfs_read+0x6a6/0xa20 ? lockdep_hardirqs_on+0x78/0x100 ? __pfx_vfs_read+0x10/0x10 ksys_read+0xf7/0x1d0 ? __pfx_ksys_read+0x10/0x10 ? __x64_sys_openat+0x105/0x1d0 do_syscall_64+0x93/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? __pfx_ksys_read+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? do_syscall_64+0x9f/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f9713f55cfa Code: 55 48 89 e5 48 83 ec 20 48 89 55 e8 48 89 75 f0 89 7d f8 e8 e8 74 f8 ff 48 8b 55 e8 48 8b 75 f0 4 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53095", "url": "https://ubuntu.com/security/CVE-2024-53095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix use-after-free of network namespace. Recently, we got a customer report that CIFS triggers oops while reconnecting to a server. [0] The workload runs on Kubernetes, and some pods mount CIFS servers in non-root network namespaces. The problem rarely happened, but it was always while the pod was dying. The root cause is wrong reference counting for network namespace. CIFS uses kernel sockets, which do not hold refcnt of the netns that the socket belongs to. That means CIFS must ensure the socket is always freed before its netns; otherwise, use-after-free happens. The repro steps are roughly: 1. mount CIFS in a non-root netns 2. drop packets from the netns 3. destroy the netns 4. unmount CIFS We can reproduce the issue quickly with the script [1] below and see the splat [2] if CONFIG_NET_NS_REFCNT_TRACKER is enabled. When the socket is TCP, it is hard to guarantee the netns lifetime without holding refcnt due to async timers. Let's hold netns refcnt for each socket as done for SMC in commit 9744d2bf1976 (\"smc: Fix use-after-free in tcp_write_timer_handler().\"). Note that we need to move put_net() from cifs_put_tcp_session() to clean_demultiplex_info(); otherwise, __sock_create() still could touch a freed netns while cifsd tries to reconnect from cifs_demultiplex_thread(). Also, maybe_get_net() cannot be put just before __sock_create() because the code is not under RCU and there is a small chance that the same address happened to be reallocated to another netns. [0]: CIFS: VFS: \\\\XXXXXXXXXXX has not responded in 15 seconds. Reconnecting... CIFS: Serverclose failed 4 times, giving up Unable to handle kernel paging request at virtual address 14de99e461f84a07 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 CM = 0, WnR = 0 [14de99e461f84a07] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: cls_bpf sch_ingress nls_utf8 cifs cifs_arc4 cifs_md4 dns_resolver tcp_diag inet_diag veth xt_state xt_connmark nf_conntrack_netlink xt_nat xt_statistic xt_MASQUERADE xt_mark xt_addrtype ipt_REJECT nf_reject_ipv4 nft_chain_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment nft_compat nf_tables nfnetlink overlay nls_ascii nls_cp437 sunrpc vfat fat aes_ce_blk aes_ce_cipher ghash_ce sm4_ce_cipher sm4 sm3_ce sm3 sha3_ce sha512_ce sha512_arm64 sha1_ce ena button sch_fq_codel loop fuse configfs dmi_sysfs sha2_ce sha256_arm64 dm_mirror dm_region_hash dm_log dm_mod dax efivarfs CPU: 5 PID: 2690970 Comm: cifsd Not tainted 6.1.103-109.184.amzn2023.aarch64 #1 Hardware name: Amazon EC2 r7g.4xlarge/, BIOS 1.0 11/1/2018 pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : fib_rules_lookup+0x44/0x238 lr : __fib_lookup+0x64/0xbc sp : ffff8000265db790 x29: ffff8000265db790 x28: 0000000000000000 x27: 000000000000bd01 x26: 0000000000000000 x25: ffff000b4baf8000 x24: ffff00047b5e4580 x23: ffff8000265db7e0 x22: 0000000000000000 x21: ffff00047b5e4500 x20: ffff0010e3f694f8 x19: 14de99e461f849f7 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 3f92800abd010002 x11: 0000000000000001 x10: ffff0010e3f69420 x9 : ffff800008a6f294 x8 : 0000000000000000 x7 : 0000000000000006 x6 : 0000000000000000 x5 : 0000000000000001 x4 : ffff001924354280 x3 : ffff8000265db7e0 x2 : 0000000000000000 x1 : ffff0010e3f694f8 x0 : ffff00047b5e4500 Call trace: fib_rules_lookup+0x44/0x238 __fib_lookup+0x64/0xbc ip_route_output_key_hash_rcu+0x2c4/0x398 ip_route_output_key_hash+0x60/0x8c tcp_v4_connect+0x290/0x488 __inet_stream_connect+0x108/0x3d0 inet_stream_connect+0x50/0x78 kernel_connect+0x6c/0xac generic_ip_conne ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-50265", "url": "https://ubuntu.com/security/CVE-2024-50265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove() Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove(): [ 57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12 [ 57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry [ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004 [...] [ 57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [...] [ 57.331328] Call Trace: [ 57.331477] [...] [ 57.333511] ? do_user_addr_fault+0x3e5/0x740 [ 57.333778] ? exc_page_fault+0x70/0x170 [ 57.334016] ? asm_exc_page_fault+0x2b/0x30 [ 57.334263] ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10 [ 57.334596] ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [ 57.334913] ocfs2_xa_remove_entry+0x23/0xc0 [ 57.335164] ocfs2_xa_set+0x704/0xcf0 [ 57.335381] ? _raw_spin_unlock+0x1a/0x40 [ 57.335620] ? ocfs2_inode_cache_unlock+0x16/0x20 [ 57.335915] ? trace_preempt_on+0x1e/0x70 [ 57.336153] ? start_this_handle+0x16c/0x500 [ 57.336410] ? preempt_count_sub+0x50/0x80 [ 57.336656] ? _raw_read_unlock+0x20/0x40 [ 57.336906] ? start_this_handle+0x16c/0x500 [ 57.337162] ocfs2_xattr_block_set+0xa6/0x1e0 [ 57.337424] __ocfs2_xattr_set_handle+0x1fd/0x5d0 [ 57.337706] ? ocfs2_start_trans+0x13d/0x290 [ 57.337971] ocfs2_xattr_set+0xb13/0xfb0 [ 57.338207] ? dput+0x46/0x1c0 [ 57.338393] ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338665] ? ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338948] __vfs_removexattr+0x92/0xc0 [ 57.339182] __vfs_removexattr_locked+0xd5/0x190 [ 57.339456] ? preempt_count_sub+0x50/0x80 [ 57.339705] vfs_removexattr+0x5f/0x100 [...] Reproducer uses faultinject facility to fail ocfs2_xa_remove() -> ocfs2_xa_value_truncate() with -ENOMEM. In this case the comment mentions that we can return 0 if ocfs2_xa_cleanup_value_truncate() is going to wipe the entry anyway. But the following 'rc' check is wrong and execution flow do 'ocfs2_xa_remove_entry(loc);' twice: * 1st: in ocfs2_xa_cleanup_value_truncate(); * 2nd: returning back to ocfs2_xa_remove() instead of going to 'out'. Fix this by skipping the 2nd removal of the same entry and making syzkaller repro happy.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50266", "url": "https://ubuntu.com/security/CVE-2024-50266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: qcom: videocc-sm8350: use HW_CTRL_TRIGGER for vcodec GDSCs A recent change in the venus driver results in a stuck clock on the Lenovo ThinkPad X13s, for example, when streaming video in firefox: \tvideo_cc_mvs0_clk status stuck at 'off' \tWARNING: CPU: 6 PID: 2885 at drivers/clk/qcom/clk-branch.c:87 clk_branch_wait+0x144/0x15c \t... \tCall trace: \t clk_branch_wait+0x144/0x15c \t clk_branch2_enable+0x30/0x40 \t clk_core_enable+0xd8/0x29c \t clk_enable+0x2c/0x4c \t vcodec_clks_enable.isra.0+0x94/0xd8 [venus_core] \t coreid_power_v4+0x464/0x628 [venus_core] \t vdec_start_streaming+0xc4/0x510 [venus_dec] \t vb2_start_streaming+0x6c/0x180 [videobuf2_common] \t vb2_core_streamon+0x120/0x1dc [videobuf2_common] \t vb2_streamon+0x1c/0x6c [videobuf2_v4l2] \t v4l2_m2m_ioctl_streamon+0x30/0x80 [v4l2_mem2mem] \t v4l_streamon+0x24/0x30 [videodev] using the out-of-tree sm8350/sc8280xp venus support. [1] Update also the sm8350/sc8280xp GDSC definitions so that the hw control mode can be changed at runtime as the venus driver now requires.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50267", "url": "https://ubuntu.com/security/CVE-2024-50267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: fix use after free in debug printk The \"dev_dbg(&urb->dev->dev, ...\" which happens after usb_free_urb(urb) is a use after free of the \"urb\" pointer. Store the \"dev\" pointer at the start of the function to avoid this issue.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50268", "url": "https://ubuntu.com/security/CVE-2024-50268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: fix potential out of bounds in ucsi_ccg_update_set_new_cam_cmd() The \"*cmd\" variable can be controlled by the user via debugfs. That means \"new_cam\" can be as high as 255 while the size of the uc->updated[] array is UCSI_MAX_ALTMODES (30). The call tree is: ucsi_cmd() // val comes from simple_attr_write_xsigned() -> ucsi_send_command() -> ucsi_send_command_common() -> ucsi_run_command() // calls ucsi->ops->sync_control() -> ucsi_ccg_sync_control()", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53083", "url": "https://ubuntu.com/security/CVE-2024-53083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: qcom-pmic: init value of hdr_len/txbuf_len earlier If the read of USB_PDPHY_RX_ACKNOWLEDGE_REG failed, then hdr_len and txbuf_len are uninitialized. This commit stops to print uninitialized value and misleading/false data.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50269", "url": "https://ubuntu.com/security/CVE-2024-50269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: musb: sunxi: Fix accessing an released usb phy Commit 6ed05c68cbca (\"usb: musb: sunxi: Explicitly release USB PHY on exit\") will cause that usb phy @glue->xceiv is accessed after released. 1) register platform driver @sunxi_musb_driver // get the usb phy @glue->xceiv sunxi_musb_probe() -> devm_usb_get_phy(). 2) register and unregister platform driver @musb_driver musb_probe() -> sunxi_musb_init() use the phy here //the phy is released here musb_remove() -> sunxi_musb_exit() -> devm_usb_put_phy() 3) register @musb_driver again musb_probe() -> sunxi_musb_init() use the phy here but the phy has been released at 2). ... Fixed by reverting the commit, namely, removing devm_usb_put_phy() from sunxi_musb_exit().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53079", "url": "https://ubuntu.com/security/CVE-2024-53079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/thp: fix deferred split unqueue naming and locking Recent changes are putting more pressure on THP deferred split queues: under load revealing long-standing races, causing list_del corruptions, \"Bad page state\"s and worse (I keep BUGs in both of those, so usually don't get to see how badly they end up without). The relevant recent changes being 6.8's mTHP, 6.10's mTHP swapout, and 6.12's mTHP swapin, improved swap allocation, and underused THP splitting. Before fixing locking: rename misleading folio_undo_large_rmappable(), which does not undo large_rmappable, to folio_unqueue_deferred_split(), which is what it does. But that and its out-of-line __callee are mm internals of very limited usability: add comment and WARN_ON_ONCEs to check usage; and return a bool to say if a deferred split was unqueued, which can then be used in WARN_ON_ONCEs around safety checks (sparing callers the arcane conditionals in __folio_unqueue_deferred_split()). Just omit the folio_unqueue_deferred_split() from free_unref_folios(), all of whose callers now call it beforehand (and if any forget then bad_page() will tell) - except for its caller put_pages_list(), which itself no longer has any callers (and will be deleted separately). Swapout: mem_cgroup_swapout() has been resetting folio->memcg_data 0 without checking and unqueueing a THP folio from deferred split list; which is unfortunate, since the split_queue_lock depends on the memcg (when memcg is enabled); so swapout has been unqueueing such THPs later, when freeing the folio, using the pgdat's lock instead: potentially corrupting the memcg's list. __remove_mapping() has frozen refcount to 0 here, so no problem with calling folio_unqueue_deferred_split() before resetting memcg_data. That goes back to 5.4 commit 87eaceb3faa5 (\"mm: thp: make deferred split shrinker memcg aware\"): which included a check on swapcache before adding to deferred queue, but no check on deferred queue before adding THP to swapcache. That worked fine with the usual sequence of events in reclaim (though there were a couple of rare ways in which a THP on deferred queue could have been swapped out), but 6.12 commit dafff3f4c850 (\"mm: split underused THPs\") avoids splitting underused THPs in reclaim, which makes swapcache THPs on deferred queue commonplace. Keep the check on swapcache before adding to deferred queue? Yes: it is no longer essential, but preserves the existing behaviour, and is likely to be a worthwhile optimization (vmstat showed much more traffic on the queue under swapping load if the check was removed); update its comment. Memcg-v1 move (deprecated): mem_cgroup_move_account() has been changing folio->memcg_data without checking and unqueueing a THP folio from the deferred list, sometimes corrupting \"from\" memcg's list, like swapout. Refcount is non-zero here, so folio_unqueue_deferred_split() can only be used in a WARN_ON_ONCE to validate the fix, which must be done earlier: mem_cgroup_move_charge_pte_range() first try to split the THP (splitting of course unqueues), or skip it if that fails. Not ideal, but moving charge has been requested, and khugepaged should repair the THP later: nobody wants new custom unqueueing code just for this deprecated case. The 87eaceb3faa5 commit did have the code to move from one deferred list to another (but was not conscious of its unsafety while refcount non-0); but that was removed by 5.6 commit fac0516b5534 (\"mm: thp: don't need care deferred split queue in memcg charge move path\"), which argued that the existence of a PMD mapping guarantees that the THP cannot be on a deferred list. As above, false in rare cases, and now commonly false. Backport to 6.11 should be straightforward. Earlier backports must take care that other _deferred_list fixes and dependencies are included. There is not a strong case for backports, but they can fix cornercases.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50270", "url": "https://ubuntu.com/security/CVE-2024-50270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: avoid overflow in damon_feed_loop_next_input() damon_feed_loop_next_input() is inefficient and fragile to overflows. Specifically, 'score_goal_diff_bp' calculation can overflow when 'score' is high. The calculation is actually unnecessary at all because 'goal' is a constant of value 10,000. Calculation of 'compensation' is again fragile to overflow. Final calculation of return value for under-achiving case is again fragile to overflow when the current score is under-achieving the target. Add two corner cases handling at the beginning of the function to make the body easier to read, and rewrite the body of the function to avoid overflows and the unnecessary bp value calcuation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50271", "url": "https://ubuntu.com/security/CVE-2024-50271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: signal: restore the override_rlimit logic Prior to commit d64696905554 (\"Reimplement RLIMIT_SIGPENDING on top of ucounts\") UCOUNT_RLIMIT_SIGPENDING rlimit was not enforced for a class of signals. However now it's enforced unconditionally, even if override_rlimit is set. This behavior change caused production issues. For example, if the limit is reached and a process receives a SIGSEGV signal, sigqueue_alloc fails to allocate the necessary resources for the signal delivery, preventing the signal from being delivered with siginfo. This prevents the process from correctly identifying the fault address and handling the error. From the user-space perspective, applications are unaware that the limit has been reached and that the siginfo is effectively 'corrupted'. This can lead to unpredictable behavior and crashes, as we observed with java applications. Fix this by passing override_rlimit into inc_rlimit_get_ucounts() and skip the comparison to max there if override_rlimit is set. This effectively restores the old behavior.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50272", "url": "https://ubuntu.com/security/CVE-2024-50272", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: filemap: Fix bounds checking in filemap_read() If the caller supplies an iocb->ki_pos value that is close to the filesystem upper limit, and an iterator with a count that causes us to overflow that limit, then filemap_read() enters an infinite loop. This behaviour was discovered when testing xfstests generic/525 with the \"localio\" optimisation for loopback NFS mounts.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53104", "url": "https://ubuntu.com/security/CVE-2024-53104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_parse_format This can lead to out of bounds writes since frames of this type were not taken into account when calculating the size of the frames buffer in uvc_parse_streaming.", "cve_priority": "high", "cve_public_date": "2024-12-02 08:15:00 UTC" }, { "cve": "CVE-2024-50273", "url": "https://ubuntu.com/security/CVE-2024-50273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reinitialize delayed ref list after deleting it from the list At insert_delayed_ref() if we need to update the action of an existing ref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head's ref_add_list using list_del(), which leaves the ref's add_list member not reinitialized, as list_del() sets the next and prev members of the list to LIST_POISON1 and LIST_POISON2, respectively. If later we end up calling drop_delayed_ref() against the ref, which can happen during merging or when destroying delayed refs due to a transaction abort, we can trigger a crash since at drop_delayed_ref() we call list_empty() against the ref's add_list, which returns false since the list was not reinitialized after the list_del() and as a consequence we call list_del() again at drop_delayed_ref(). This results in an invalid list access since the next and prev members are set to poison pointers, resulting in a splat if CONFIG_LIST_HARDENED and CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences otherwise. So fix this by deleting from the list with list_del_init() instead.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53064", "url": "https://ubuntu.com/security/CVE-2024-53064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix idpf_vc_core_init error path In an event where the platform running the device control plane is rebooted, reset is detected on the driver. It releases all the resources and waits for the reset to complete. Once the reset is done, it tries to build the resources back. At this time if the device control plane is not yet started, then the driver timeouts on the virtchnl message and retries to establish the mailbox again. In the retry flow, mailbox is deinitialized but the mailbox workqueue is still alive and polling for the mailbox message. This results in accessing the released control queue leading to null-ptr-deref. Fix it by unrolling the work queue cancellation and mailbox deinitialization in the reverse order which they got initialized.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50274", "url": "https://ubuntu.com/security/CVE-2024-50274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: avoid vport access in idpf_get_link_ksettings When the device control plane is removed or the platform running device control plane is rebooted, a reset is detected on the driver. On driver reset, it releases the resources and waits for the reset to complete. If the reset fails, it takes the error path and releases the vport lock. At this time if the monitoring tools tries to access link settings, it call traces for accessing released vport pointer. To avoid it, move link_speed_mbps to netdev_priv structure which removes the dependency on vport pointer and the vport lock in idpf_get_link_ksettings. Also use netif_carrier_ok() to check the link status and adjust the offsetof to use link_up instead of link_speed_mbps.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53065", "url": "https://ubuntu.com/security/CVE-2024-53065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/slab: fix warning caused by duplicate kmem_cache creation in kmem_buckets_create Commit b035f5a6d852 (\"mm: slab: reduce the kmalloc() minimum alignment if DMA bouncing possible\") reduced ARCH_KMALLOC_MINALIGN to 8 on arm64. However, with KASAN_HW_TAGS enabled, arch_slab_minalign() becomes 16. This causes kmalloc_caches[*][8] to be aliased to kmalloc_caches[*][16], resulting in kmem_buckets_create() attempting to create a kmem_cache for size 16 twice. This duplication triggers warnings on boot: [ 2.325108] ------------[ cut here ]------------ [ 2.325135] kmem_cache of name 'memdup_user-16' already exists [ 2.325783] WARNING: CPU: 0 PID: 1 at mm/slab_common.c:107 __kmem_cache_create_args+0xb8/0x3b0 [ 2.327957] Modules linked in: [ 2.328550] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5mm-unstable-arm64+ #12 [ 2.328683] Hardware name: QEMU QEMU Virtual Machine, BIOS 2024.02-2 03/11/2024 [ 2.328790] pstate: 61000009 (nZCv daif -PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 2.328911] pc : __kmem_cache_create_args+0xb8/0x3b0 [ 2.328930] lr : __kmem_cache_create_args+0xb8/0x3b0 [ 2.328942] sp : ffff800083d6fc50 [ 2.328961] x29: ffff800083d6fc50 x28: f2ff0000c1674410 x27: ffff8000820b0598 [ 2.329061] x26: 000000007fffffff x25: 0000000000000010 x24: 0000000000002000 [ 2.329101] x23: ffff800083d6fce8 x22: ffff8000832222e8 x21: ffff800083222388 [ 2.329118] x20: f2ff0000c1674410 x19: f5ff0000c16364c0 x18: ffff800083d80030 [ 2.329135] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 2.329152] x14: 0000000000000000 x13: 0a73747369786520 x12: 79646165726c6120 [ 2.329169] x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : 0000000000000000 [ 2.329194] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 [ 2.329210] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 2.329226] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 2.329291] Call trace: [ 2.329407] __kmem_cache_create_args+0xb8/0x3b0 [ 2.329499] kmem_buckets_create+0xfc/0x320 [ 2.329526] init_user_buckets+0x34/0x78 [ 2.329540] do_one_initcall+0x64/0x3c8 [ 2.329550] kernel_init_freeable+0x26c/0x578 [ 2.329562] kernel_init+0x3c/0x258 [ 2.329574] ret_from_fork+0x10/0x20 [ 2.329698] ---[ end trace 0000000000000000 ]--- [ 2.403704] ------------[ cut here ]------------ [ 2.404716] kmem_cache of name 'msg_msg-16' already exists [ 2.404801] WARNING: CPU: 2 PID: 1 at mm/slab_common.c:107 __kmem_cache_create_args+0xb8/0x3b0 [ 2.404842] Modules linked in: [ 2.404971] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.12.0-rc5mm-unstable-arm64+ #12 [ 2.405026] Tainted: [W]=WARN [ 2.405043] Hardware name: QEMU QEMU Virtual Machine, BIOS 2024.02-2 03/11/2024 [ 2.405057] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2.405079] pc : __kmem_cache_create_args+0xb8/0x3b0 [ 2.405100] lr : __kmem_cache_create_args+0xb8/0x3b0 [ 2.405111] sp : ffff800083d6fc50 [ 2.405115] x29: ffff800083d6fc50 x28: fbff0000c1674410 x27: ffff8000820b0598 [ 2.405135] x26: 000000000000ffd0 x25: 0000000000000010 x24: 0000000000006000 [ 2.405153] x23: ffff800083d6fce8 x22: ffff8000832222e8 x21: ffff800083222388 [ 2.405169] x20: fbff0000c1674410 x19: fdff0000c163d6c0 x18: ffff800083d80030 [ 2.405185] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 2.405201] x14: 0000000000000000 x13: 0a73747369786520 x12: 79646165726c6120 [ 2.405217] x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : 0000000000000000 [ 2.405233] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 [ 2.405248] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 2.405271] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 2.405287] Call trace: [ 2 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50275", "url": "https://ubuntu.com/security/CVE-2024-50275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64/sve: Discard stale CPU state when handling SVE traps The logic for handling SVE traps manipulates saved FPSIMD/SVE state incorrectly, and a race with preemption can result in a task having TIF_SVE set and TIF_FOREIGN_FPSTATE clear even though the live CPU state is stale (e.g. with SVE traps enabled). This has been observed to result in warnings from do_sve_acc() where SVE traps are not expected while TIF_SVE is set: | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* SVE access shouldn't have trapped */ Warnings of this form have been reported intermittently, e.g. https://lore.kernel.org/linux-arm-kernel/CA+G9fYtEGe_DhY2Ms7+L7NKsLYUomGsgqpdBj+QwDLeSg=JhGg@mail.gmail.com/ https://lore.kernel.org/linux-arm-kernel/000000000000511e9a060ce5a45c@google.com/ The race can occur when the SVE trap handler is preempted before and after manipulating the saved FPSIMD/SVE state, starting and ending on the same CPU, e.g. | void do_sve_acc(unsigned long esr, struct pt_regs *regs) | { | // Trap on CPU 0 with TIF_SVE clear, SVE 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(); | | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* SVE access shouldn't have trapped */ | | sve_init_regs() { | if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) { | ... | } else { | fpsimd_to_sve(current); | current->thread.fp_type = FP_STATE_SVE; | } | } | | 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 SVE 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.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50276", "url": "https://ubuntu.com/security/CVE-2024-50276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: vertexcom: mse102x: Fix possible double free of TX skb The scope of the TX skb is wider than just mse102x_tx_frame_spi(), so in case the TX skb room needs to be expanded, we should free the the temporary skb instead of the original skb. Otherwise the original TX skb pointer would be freed again in mse102x_tx_work(), which leads to crashes: Internal error: Oops: 0000000096000004 [#2] PREEMPT SMP CPU: 0 PID: 712 Comm: kworker/0:1 Tainted: G D 6.6.23 Hardware name: chargebyte Charge SOM DC-ONE (DT) Workqueue: events mse102x_tx_work [mse102x] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_release_data+0xb8/0x1d8 lr : skb_release_data+0x1ac/0x1d8 sp : ffff8000819a3cc0 x29: ffff8000819a3cc0 x28: ffff0000046daa60 x27: ffff0000057f2dc0 x26: ffff000005386c00 x25: 0000000000000002 x24: 00000000ffffffff x23: 0000000000000000 x22: 0000000000000001 x21: ffff0000057f2e50 x20: 0000000000000006 x19: 0000000000000000 x18: ffff00003fdacfcc x17: e69ad452d0c49def x16: 84a005feff870102 x15: 0000000000000000 x14: 000000000000024a x13: 0000000000000002 x12: 0000000000000000 x11: 0000000000000400 x10: 0000000000000930 x9 : ffff00003fd913e8 x8 : fffffc00001bc008 x7 : 0000000000000000 x6 : 0000000000000008 x5 : ffff00003fd91340 x4 : 0000000000000000 x3 : 0000000000000009 x2 : 00000000fffffffe x1 : 0000000000000000 x0 : 0000000000000000 Call trace: skb_release_data+0xb8/0x1d8 kfree_skb_reason+0x48/0xb0 mse102x_tx_work+0x164/0x35c [mse102x] process_one_work+0x138/0x260 worker_thread+0x32c/0x438 kthread+0x118/0x11c ret_from_fork+0x10/0x20 Code: aa1303e0 97fffab6 72001c1f 54000141 (f9400660)", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53066", "url": "https://ubuntu.com/security/CVE-2024-53066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfs: Fix KMSAN warning in decode_getfattr_attrs() Fix the following KMSAN warning: CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G B Tainted: [B]=BAD_PAGE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) ===================================================== ===================================================== BUG: KMSAN: uninit-value in decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_generic+0x806/0xb00 nfs4_xdr_dec_getattr+0x1de/0x240 rpcauth_unwrap_resp_decode+0xab/0x100 rpcauth_unwrap_resp+0x95/0xc0 call_decode+0x4ff/0xb50 __rpc_execute+0x57b/0x19d0 rpc_execute+0x368/0x5e0 rpc_run_task+0xcfe/0xee0 nfs4_proc_getattr+0x5b5/0x990 __nfs_revalidate_inode+0x477/0xd00 nfs_access_get_cached+0x1021/0x1cc0 nfs_do_access+0x9f/0xae0 nfs_permission+0x1e4/0x8c0 inode_permission+0x356/0x6c0 link_path_walk+0x958/0x1330 path_lookupat+0xce/0x6b0 filename_lookup+0x23e/0x770 vfs_statx+0xe7/0x970 vfs_fstatat+0x1f2/0x2c0 __se_sys_newfstatat+0x67/0x880 __x64_sys_newfstatat+0xbd/0x120 x64_sys_call+0x1826/0x3cf0 do_syscall_64+0xd0/0x1b0 entry_SYSCALL_64_after_hwframe+0x77/0x7f The KMSAN warning is triggered in decode_getfattr_attrs(), when calling decode_attr_mdsthreshold(). It appears that fattr->mdsthreshold is not initialized. Fix the issue by initializing fattr->mdsthreshold to NULL in nfs_fattr_init().", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53067", "url": "https://ubuntu.com/security/CVE-2024-53067", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Start the RTC update work later The RTC update work involves runtime resuming the UFS controller. Hence, only start the RTC update work after runtime power management in the UFS driver has been fully initialized. This patch fixes the following kernel crash: Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP Workqueue: events ufshcd_rtc_work Call trace: _raw_spin_lock_irqsave+0x34/0x8c (P) pm_runtime_get_if_active+0x24/0x9c (L) pm_runtime_get_if_active+0x24/0x9c ufshcd_rtc_work+0x138/0x1b4 process_one_work+0x148/0x288 worker_thread+0x2cc/0x3d4 kthread+0x110/0x114 ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50277", "url": "https://ubuntu.com/security/CVE-2024-50277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: fix a crash if blk_alloc_disk fails If blk_alloc_disk fails, the variable md->disk is set to an error value. cleanup_mapped_device will see that md->disk is non-NULL and it will attempt to access it, causing a crash on this statement \"md->disk->private_data = NULL;\".", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50278", "url": "https://ubuntu.com/security/CVE-2024-50278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix potential out-of-bounds access on the first resume Out-of-bounds access occurs if the fast device is expanded unexpectedly before the first-time resume of the cache table. This happens because expanding the fast device requires reloading the cache table for cache_create to allocate new in-core data structures that fit the new size, and the check in cache_preresume is not performed during the first resume, leading to the issue. Reproduce steps: 1. prepare component devices: 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\" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct 2. load a cache table of 512 cache blocks, and deliberately expand the fast device before resuming the cache, making the in-core data structures inadequate. dmsetup create cache --notable dmsetup reload cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" dmsetup reload cdata --table \"0 131072 linear /dev/sdc 8192\" dmsetup resume cdata dmsetup resume cache 3. suspend the cache to write out the in-core dirty bitset and hint array, leading to out-of-bounds access to the dirty bitset at offset 0x40: dmsetup suspend cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80 Read of size 8 at addr ffffc90000085040 by task dmsetup/90 (...snip...) The buggy address belongs to the virtual mapping at [ffffc90000085000, ffffc90000087000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by checking the size change on the first resume.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50279", "url": "https://ubuntu.com/security/CVE-2024-50279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix out-of-bounds access to the dirty bitset when resizing dm-cache checks the dirty bits of the cache blocks to be dropped when shrinking the fast device, but an index bug in bitset iteration causes out-of-bounds access. Reproduce steps: 1. create a cache device of 1024 cache blocks (128 bytes dirty bitset) dmsetup create cmeta --table \"0 8192 linear /dev/sdc 0\" dmsetup create cdata --table \"0 131072 linear /dev/sdc 8192\" dmsetup create corig --table \"0 524288 linear /dev/sdc 262144\" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" 2. shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80) dmsetup suspend cache dmsetup reload cdata --table \"0 65536 linear /dev/sdc 8192\" dmsetup resume cdata dmsetup resume cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131 (...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by making the index post-incremented.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50280", "url": "https://ubuntu.com/security/CVE-2024-50280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix flushing uninitialized delayed_work on cache_ctr error An unexpected WARN_ON from flush_work() may occur when cache creation fails, caused by destroying the uninitialized delayed_work waker in the error path of cache_create(). For example, the warning appears on the superblock checksum error. Reproduce steps: 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\" dd if=/dev/urandom of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" Kernel logs: (snip) WARNING: CPU: 0 PID: 84 at kernel/workqueue.c:4178 __flush_work+0x5d4/0x890 Fix by pulling out the cancel_delayed_work_sync() from the constructor's error path. This patch doesn't affect the use-after-free fix for concurrent dm_resume and dm_destroy (commit 6a459d8edbdb (\"dm cache: Fix UAF in destroy()\")) as cache_dtr is not changed.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50281", "url": "https://ubuntu.com/security/CVE-2024-50281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: trusted: dcp: fix NULL dereference in AEAD crypto operation When sealing or unsealing a key blob we currently do not wait for the AEAD cipher operation to finish and simply return after submitting the request. If there is some load on the system we can exit before the cipher operation is done and the buffer we read from/write to is already removed from the stack. This will e.g. result in NULL pointer dereference errors in the DCP driver during blob creation. Fix this by waiting for the AEAD cipher operation to finish before resuming the seal and unseal calls.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50282", "url": "https://ubuntu.com/security/CVE-2024-50282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read() Avoid a possible buffer overflow if size is larger than 4K. (cherry picked from commit f5d873f5825b40d886d03bd2aede91d4cf002434)", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53071", "url": "https://ubuntu.com/security/CVE-2024-53071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Be stricter about IO mapping flags The current panthor_device_mmap_io() implementation has two issues: 1. For mapping DRM_PANTHOR_USER_FLUSH_ID_MMIO_OFFSET, panthor_device_mmap_io() bails if VM_WRITE is set, but does not clear VM_MAYWRITE. That means userspace can use mprotect() to make the mapping writable later on. This is a classic Linux driver gotcha. I don't think this actually has any impact in practice: When the GPU is powered, writes to the FLUSH_ID seem to be ignored; and when the GPU is not powered, the dummy_latest_flush page provided by the driver is deliberately designed to not do any flushes, so the only thing writing to the dummy_latest_flush could achieve would be to make *more* flushes happen. 2. panthor_device_mmap_io() does not block MAP_PRIVATE mappings (which are mappings without the VM_SHARED flag). MAP_PRIVATE in combination with VM_MAYWRITE indicates that the VMA has copy-on-write semantics, which for VM_PFNMAP are semi-supported but fairly cursed. In particular, in such a mapping, the driver can only install PTEs during mmap() by calling remap_pfn_range() (because remap_pfn_range() wants to **store the physical address of the mapped physical memory into the vm_pgoff of the VMA**); installing PTEs later on with a fault handler (as panthor does) is not supported in private mappings, and so if you try to fault in such a mapping, vmf_insert_pfn_prot() splats when it hits a BUG() check. Fix it by clearing the VM_MAYWRITE flag (userspace writing to the FLUSH_ID doesn't make sense) and requiring VM_SHARED (copy-on-write semantics for the FLUSH_ID don't make sense). Reproducers for both scenarios are in the notes of my patch on the mailing list; I tested that these bugs exist on a Rock 5B machine. Note that I only compile-tested the patch, I haven't tested it; I don't have a working kernel build setup for the test machine yet. Please test it before applying it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53080", "url": "https://ubuntu.com/security/CVE-2024-53080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Lock XArray when getting entries for the VM Similar to commit cac075706f29 (\"drm/panthor: Fix race when converting group handle to group object\") we need to use the XArray's internal locking when retrieving a vm pointer from there. v2: Removed part of the patch that was trying to protect fetching the heap pointer from XArray, as that operation is protected by the @pool->lock.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53084", "url": "https://ubuntu.com/security/CVE-2024-53084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Break an object reference loop When remaining resources are being cleaned up on driver close, outstanding VM mappings may result in resources being leaked, due to an object reference loop, as shown below, with each object (or set of objects) referencing the object below it: PVR GEM Object GPU scheduler \"finished\" fence GPU scheduler “scheduled” fence PVR driver “done” fence PVR Context PVR VM Context PVR VM Mappings PVR GEM Object The reference that the PVR VM Context has on the VM mappings is a soft one, in the sense that the freeing of outstanding VM mappings is done as part of VM context destruction; no reference counts are involved, as is the case for all the other references in the loop. To break the reference loop during cleanup, free the outstanding VM mappings before destroying the PVR Context associated with the VM context.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53085", "url": "https://ubuntu.com/security/CVE-2024-53085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: Lock TPM chip in tpm_pm_suspend() first Setting TPM_CHIP_FLAG_SUSPENDED in the end of tpm_pm_suspend() can be racy according, as this leaves window for tpm_hwrng_read() to be called while the operation is in progress. The recent bug report gives also evidence of this behaviour. Aadress this by locking the TPM chip before checking any chip->flags both in tpm_pm_suspend() and tpm_hwrng_read(). Move TPM_CHIP_FLAG_SUSPENDED check inside tpm_get_random() so that it will be always checked only when the lock is reserved.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53086", "url": "https://ubuntu.com/security/CVE-2024-53086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Drop VM dma-resv lock on xe_sync_in_fence_get failure in exec IOCTL Upon failure all locks need to be dropped before returning to the user. (cherry picked from commit 7d1a4258e602ffdce529f56686925034c1b3b095)", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53087", "url": "https://ubuntu.com/security/CVE-2024-53087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix possible exec queue leak in exec IOCTL In a couple of places after an exec queue is looked up the exec IOCTL returns on input errors without dropping the exec queue ref. Fix this ensuring the exec queue ref is dropped on input error. (cherry picked from commit 07064a200b40ac2195cb6b7b779897d9377e5e6f)", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50283", "url": "https://ubuntu.com/security/CVE-2024-50283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-use-after-free in smb3_preauth_hash_rsp ksmbd_user_session_put should be called under smb3_preauth_hash_rsp(). It will avoid freeing session before calling smb3_preauth_hash_rsp().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50284", "url": "https://ubuntu.com/security/CVE-2024-50284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix the missing xa_store error check xa_store() can fail, it return xa_err(-EINVAL) if the entry cannot be stored in an XArray, or xa_err(-ENOMEM) if memory allocation failed, so check error for xa_store() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50285", "url": "https://ubuntu.com/security/CVE-2024-50285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: check outstanding simultaneous SMB operations If Client send simultaneous SMB operations to ksmbd, It exhausts too much memory through the \"ksmbd_work_cache”. It will cause OOM issue. ksmbd has a credit mechanism but it can't handle this problem. This patch add the check if it exceeds max credits to prevent this problem by assuming that one smb request consumes at least one credit.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50286", "url": "https://ubuntu.com/security/CVE-2024-50286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-use-after-free in ksmbd_smb2_session_create There is a race condition between ksmbd_smb2_session_create and ksmbd_expire_session. This patch add missing sessions_table_lock while adding/deleting session from global session table.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50287", "url": "https://ubuntu.com/security/CVE-2024-50287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-tpg: prevent the risk of a division by zero As reported by Coverity, the logic at tpg_precalculate_line() blindly rescales the buffer even when scaled_witdh is equal to zero. If this ever happens, this will cause a division by zero. Instead, add a WARN_ON_ONCE() to trigger such cases and return without doing any precalculation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50288", "url": "https://ubuntu.com/security/CVE-2024-50288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: fix buffer overwrite when using > 32 buffers The maximum number of buffers that can be requested was increased to 64 for the video capture queue. But video capture used a must_blank array that was still sized for 32 (VIDEO_MAX_FRAME). This caused an out-of-bounds write when using buffer indices >= 32. Create a new define MAX_VID_CAP_BUFFERS that is used to access the must_blank array and set max_num_buffers for the video capture queue. This solves a crash reported by: \thttps://bugzilla.kernel.org/show_bug.cgi?id=219258", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50289", "url": "https://ubuntu.com/security/CVE-2024-50289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: av7110: fix a spectre vulnerability As warned by smatch: \tdrivers/staging/media/av7110/av7110_ca.c:270 dvb_ca_ioctl() warn: potential spectre issue 'av7110->ci_slot' [w] (local cap) There is a spectre-related vulnerability at the code. Fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50290", "url": "https://ubuntu.com/security/CVE-2024-50290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx24116: prevent overflows on SNR calculus as reported by Coverity, if reading SNR registers fail, a negative number will be returned, causing an underflow when reading SNR registers. Prevent that.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53061", "url": "https://ubuntu.com/security/CVE-2024-53061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: s5p-jpeg: prevent buffer overflows The current logic allows word to be less than 2. If this happens, there will be buffer overflows, as reported by smatch. Add extra checks to prevent it. While here, remove an unused word = 0 assignment.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53081", "url": "https://ubuntu.com/security/CVE-2024-53081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ar0521: don't overflow when checking PLL values The PLL checks are comparing 64 bit integers with 32 bit ones, as reported by Coverity. Depending on the values of the variables, this may underflow. Fix it ensuring that both sides of the expression are u64.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53062", "url": "https://ubuntu.com/security/CVE-2024-53062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mgb4: protect driver against spectre Frequency range is set from sysfs via frequency_range_store(), being vulnerable to spectre, as reported by smatch: \tdrivers/media/pci/mgb4/mgb4_cmt.c:231 mgb4_cmt_set_vin_freq_range() warn: potential spectre issue 'cmt_vals_in' [r] \tdrivers/media/pci/mgb4/mgb4_cmt.c:238 mgb4_cmt_set_vin_freq_range() warn: possible spectre second half. 'reg_set' Fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50291", "url": "https://ubuntu.com/security/CVE-2024-50291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvb-core: add missing buffer index check dvb_vb2_expbuf() didn't check if the given buffer index was for a valid buffer. Add this check.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50292", "url": "https://ubuntu.com/security/CVE-2024-50292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: stm32: spdifrx: fix dma channel release in stm32_spdifrx_remove In case of error when requesting ctrl_chan DMA channel, ctrl_chan is not null. So the release of the dma channel leads to the following issue: [ 4.879000] st,stm32-spdifrx 500d0000.audio-controller: dma_request_slave_channel error -19 [ 4.888975] Unable to handle kernel NULL pointer dereference at virtual address 000000000000003d [...] [ 5.096577] Call trace: [ 5.099099] dma_release_channel+0x24/0x100 [ 5.103235] stm32_spdifrx_remove+0x24/0x60 [snd_soc_stm32_spdifrx] [ 5.109494] stm32_spdifrx_probe+0x320/0x4c4 [snd_soc_stm32_spdifrx] To avoid this issue, release channel only if the pointer is valid.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53063", "url": "https://ubuntu.com/security/CVE-2024-53063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvbdev: prevent the risk of out of memory access The dvbdev contains a static variable used to store dvb minors. The behavior of it depends if CONFIG_DVB_DYNAMIC_MINORS is set or not. When not set, dvb_register_device() won't check for boundaries, as it will rely that a previous call to dvb_register_adapter() would already be enforcing it. On a similar way, dvb_device_open() uses the assumption that the register functions already did the needed checks. This can be fragile if some device ends using different calls. This also generate warnings on static check analysers like Coverity. So, add explicit guards to prevent potential risk of OOM issues.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50293", "url": "https://ubuntu.com/security/CVE-2024-50293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: do not leave a dangling sk pointer in __smc_create() Thanks to commit 4bbd360a5084 (\"socket: Print pf->create() when it does not clear sock->sk on failure.\"), syzbot found an issue with AF_SMC: smc_create must clear sock->sk on failure, family: 43, type: 1, protocol: 0 WARNING: CPU: 0 PID: 5827 at net/socket.c:1565 __sock_create+0x96f/0xa30 net/socket.c:1563 Modules linked in: CPU: 0 UID: 0 PID: 5827 Comm: syz-executor259 Not tainted 6.12.0-rc6-next-20241106-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:__sock_create+0x96f/0xa30 net/socket.c:1563 Code: 03 00 74 08 4c 89 e7 e8 4f 3b 85 f8 49 8b 34 24 48 c7 c7 40 89 0c 8d 8b 54 24 04 8b 4c 24 0c 44 8b 44 24 08 e8 32 78 db f7 90 <0f> 0b 90 90 e9 d3 fd ff ff 89 e9 80 e1 07 fe c1 38 c1 0f 8c ee f7 RSP: 0018:ffffc90003e4fda0 EFLAGS: 00010246 RAX: 099c6f938c7f4700 RBX: 1ffffffff1a595fd RCX: ffff888034823c00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 00000000ffffffe9 R08: ffffffff81567052 R09: 1ffff920007c9f50 R10: dffffc0000000000 R11: fffff520007c9f51 R12: ffffffff8d2cafe8 R13: 1ffffffff1a595fe R14: ffffffff9a789c40 R15: ffff8880764298c0 FS: 000055557b518380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa62ff43225 CR3: 0000000031628000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: sock_create net/socket.c:1616 [inline] __sys_socket_create net/socket.c:1653 [inline] __sys_socket+0x150/0x3c0 net/socket.c:1700 __do_sys_socket net/socket.c:1714 [inline] __se_sys_socket net/socket.c:1712 [inline] For reference, see commit 2d859aff775d (\"Merge branch 'do-not-leave-dangling-sk-pointers-in-pf-create-functions'\")", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50294", "url": "https://ubuntu.com/security/CVE-2024-50294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix missing locking causing hanging calls If a call gets aborted (e.g. because kafs saw a signal) between it being queued for connection and the I/O thread picking up the call, the abort will be prioritised over the connection and it will be removed from local->new_client_calls by rxrpc_disconnect_client_call() without a lock being held. This may cause other calls on the list to disappear if a race occurs. Fix this by taking the client_call_lock when removing a call from whatever list its ->wait_link happens to be on.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50295", "url": "https://ubuntu.com/security/CVE-2024-50295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: arc: fix the device for dma_map_single/dma_unmap_single The ndev->dev and pdev->dev aren't the same device, use ndev->dev.parent which has dma_mask, ndev->dev.parent is just pdev->dev. Or it would cause the following issue: [ 39.933526] ------------[ cut here ]------------ [ 39.938414] WARNING: CPU: 1 PID: 501 at kernel/dma/mapping.c:149 dma_map_page_attrs+0x90/0x1f8", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53082", "url": "https://ubuntu.com/security/CVE-2024-53082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_net: Add hash_key_length check Add hash_key_length check in virtnet_probe() to avoid possible out of bound errors when setting/reading the hash key.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50296", "url": "https://ubuntu.com/security/CVE-2024-50296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash when uninstalling driver When the driver is uninstalled and the VF is disabled concurrently, a kernel crash occurs. The reason is that the two actions call function pci_disable_sriov(). The num_VFs is checked to determine whether to release the corresponding resources. During the second calling, num_VFs is not 0 and the resource release function is called. However, the corresponding resource has been released during the first invoking. Therefore, the problem occurs: [15277.839633][T50670] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ... [15278.131557][T50670] Call trace: [15278.134686][T50670] klist_put+0x28/0x12c [15278.138682][T50670] klist_del+0x14/0x20 [15278.142592][T50670] device_del+0xbc/0x3c0 [15278.146676][T50670] pci_remove_bus_device+0x84/0x120 [15278.151714][T50670] pci_stop_and_remove_bus_device+0x6c/0x80 [15278.157447][T50670] pci_iov_remove_virtfn+0xb4/0x12c [15278.162485][T50670] sriov_disable+0x50/0x11c [15278.166829][T50670] pci_disable_sriov+0x24/0x30 [15278.171433][T50670] hnae3_unregister_ae_algo_prepare+0x60/0x90 [hnae3] [15278.178039][T50670] hclge_exit+0x28/0xd0 [hclge] [15278.182730][T50670] __se_sys_delete_module.isra.0+0x164/0x230 [15278.188550][T50670] __arm64_sys_delete_module+0x1c/0x30 [15278.193848][T50670] invoke_syscall+0x50/0x11c [15278.198278][T50670] el0_svc_common.constprop.0+0x158/0x164 [15278.203837][T50670] do_el0_svc+0x34/0xcc [15278.207834][T50670] el0_svc+0x20/0x30 For details, see the following figure. rmmod hclge disable VFs ---------------------------------------------------- hclge_exit() sriov_numvfs_store() ... device_lock() pci_disable_sriov() hns3_pci_sriov_configure() pci_disable_sriov() sriov_disable() sriov_disable() if !num_VFs : if !num_VFs : return; return; sriov_del_vfs() sriov_del_vfs() ... ... klist_put() klist_put() ... ... num_VFs = 0; num_VFs = 0; device_unlock(); In this patch, when driver is removing, we get the device_lock() to protect num_VFs, just like sriov_numvfs_store().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53088", "url": "https://ubuntu.com/security/CVE-2024-53088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: fix race condition by adding filter's intermediate sync state Fix a race condition in the i40e driver that leads to MAC/VLAN filters becoming corrupted and leaking. Address the issue that occurs under heavy load when multiple threads are concurrently modifying MAC/VLAN filters by setting mac and port VLAN. 1. Thread T0 allocates a filter in i40e_add_filter() within i40e_ndo_set_vf_port_vlan(). 2. Thread T1 concurrently frees the filter in __i40e_del_filter() within i40e_ndo_set_vf_mac(). 3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which refers to the already freed filter memory, causing corruption. Reproduction steps: 1. Spawn multiple VFs. 2. Apply a concurrent heavy load by running parallel operations to change MAC addresses on the VFs and change port VLANs on the host. 3. Observe errors in dmesg: \"Error I40E_AQ_RC_ENOSPC adding RX filters on VF XX, \tplease set promiscuous on manually for VF XX\". Exact code for stable reproduction Intel can't open-source now. The fix involves implementing a new intermediate filter state, I40E_FILTER_NEW_SYNC, for the time when a filter is on a tmp_add_list. These filters cannot be deleted from the hash list directly but must be removed using the full process.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50297", "url": "https://ubuntu.com/security/CVE-2024-50297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: xilinx: axienet: Enqueue Tx packets in dql before dmaengine starts Enqueue packets in dql after dma engine starts causes race condition. Tx transfer starts once dma engine is started and may execute dql dequeue in completion before it gets queued. It results in following kernel crash while running iperf stress test: kernel BUG at lib/dynamic_queue_limits.c:99! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP pc : dql_completed+0x238/0x248 lr : dql_completed+0x3c/0x248 Call trace: dql_completed+0x238/0x248 axienet_dma_tx_cb+0xa0/0x170 xilinx_dma_do_tasklet+0xdc/0x290 tasklet_action_common+0xf8/0x11c tasklet_action+0x30/0x3c handle_softirqs+0xf8/0x230 Start dmaengine after enqueue in dql fixes the crash.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50298", "url": "https://ubuntu.com/security/CVE-2024-50298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: enetc: allocate vf_state during PF probes In the previous implementation, vf_state is allocated memory only when VF is enabled. However, net_device_ops::ndo_set_vf_mac() may be called before VF is enabled to configure the MAC address of VF. If this is the case, enetc_pf_set_vf_mac() will access vf_state, resulting in access to a null pointer. The simplified error log is as follows. root@ls1028ardb:~# ip link set eno0 vf 1 mac 00:0c:e7:66:77:89 [ 173.543315] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 [ 173.637254] pc : enetc_pf_set_vf_mac+0x3c/0x80 Message from sy [ 173.641973] lr : do_setlink+0x4a8/0xec8 [ 173.732292] Call trace: [ 173.734740] enetc_pf_set_vf_mac+0x3c/0x80 [ 173.738847] __rtnl_newlink+0x530/0x89c [ 173.742692] rtnl_newlink+0x50/0x7c [ 173.746189] rtnetlink_rcv_msg+0x128/0x390 [ 173.750298] netlink_rcv_skb+0x60/0x130 [ 173.754145] rtnetlink_rcv+0x18/0x24 [ 173.757731] netlink_unicast+0x318/0x380 [ 173.761665] netlink_sendmsg+0x17c/0x3c8", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50299", "url": "https://ubuntu.com/security/CVE-2024-50299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: properly validate chunk size in sctp_sf_ootb() A size validation fix similar to that in Commit 50619dbf8db7 (\"sctp: add size validation when walking chunks\") is also required in sctp_sf_ootb() to address a crash reported by syzbot: BUG: KMSAN: uninit-value in sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_do_sm+0x181/0x93d0 net/sctp/sm_sideeffect.c:1166 sctp_endpoint_bh_rcv+0xc38/0xf90 net/sctp/endpointola.c:407 sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88 sctp_rcv+0x3831/0x3b20 net/sctp/input.c:243 sctp4_rcv+0x42/0x50 net/sctp/protocol.c:1159 ip_protocol_deliver_rcu+0xb51/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50300", "url": "https://ubuntu.com/security/CVE-2024-50300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: rtq2208: Fix uninitialized use of regulator_config Fix rtq2208 driver uninitialized use to cause kernel error.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50301", "url": "https://ubuntu.com/security/CVE-2024-50301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: security/keys: fix slab-out-of-bounds in key_task_permission KASAN reports an out of bounds read: BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline] BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362 CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0x107/0x167 lib/dump_stack.c:123 print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 __kuid_val include/linux/uidgid.h:36 [inline] uid_eq include/linux/uidgid.h:63 [inline] key_task_permission+0x394/0x410 security/keys/permission.c:54 search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793 This issue was also reported by syzbot. It can be reproduced by following these steps(more details [1]): 1. Obtain more than 32 inputs that have similar hashes, which ends with the pattern '0xxxxxxxe6'. 2. Reboot and add the keys obtained in step 1. The reproducer demonstrates how this issue happened: 1. In the search_nested_keyrings function, when it iterates through the slots in a node(below tag ascend_to_node), if the slot pointer is meta and node->back_pointer != NULL(it means a root), it will proceed to descend_to_node. However, there is an exception. If node is the root, and one of the slots points to a shortcut, it will be treated as a keyring. 2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function. However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as ASSOC_ARRAY_PTR_SUBTYPE_MASK. 3. When 32 keys with the similar hashes are added to the tree, the ROOT has keys with hashes that are not similar (e.g. slot 0) and it splits NODE A without using a shortcut. When NODE A is filled with keys that all hashes are xxe6, the keys are similar, NODE A will split with a shortcut. Finally, it forms the tree as shown below, where slot 6 points to a shortcut. NODE A +------>+---+ ROOT | | 0 | xxe6 +---+ | +---+ xxxx | 0 | shortcut : : xxe6 +---+ | +---+ xxe6 : : | | | xxe6 +---+ | +---+ | 6 |---+ : : xxe6 +---+ +---+ xxe6 : : | f | xxe6 +---+ +---+ xxe6 | f | +---+ 4. As mentioned above, If a slot(slot 6) of the root points to a shortcut, it may be mistakenly transferred to a key*, leading to a read out-of-bounds read. To fix this issue, one should jump to descend_to_node if the ptr is a shortcut, regardless of whether the node is root or not. [1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/ [jarkko: tweaked the commit message a bit to have an appropriate closes tag.]", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53072", "url": "https://ubuntu.com/security/CVE-2024-53072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/pmc: Detect when STB is not available Loading the amd_pmc module as: amd_pmc enable_stb=1 ...can result in the following messages in the kernel ring buffer: amd_pmc AMDI0009:00: SMU cmd failed. err: 0xff ioremap on RAM at 0x0000000000000000 - 0x0000000000ffffff WARNING: CPU: 10 PID: 2151 at arch/x86/mm/ioremap.c:217 __ioremap_caller+0x2cd/0x340 Further debugging reveals that this occurs when the requests for S2D_PHYS_ADDR_LOW and S2D_PHYS_ADDR_HIGH return a value of 0, indicating that the STB is inaccessible. To prevent the ioremap warning and provide clarity to the user, handle the invalid address and display an error message.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50302", "url": "https://ubuntu.com/security/CVE-2024-50302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: zero-initialize the report buffer Since the report buffer is used by all kinds of drivers in various ways, let's zero-initialize it during allocation to make sure that it can't be ever used to leak kernel memory via specially-crafted report.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53068", "url": "https://ubuntu.com/security/CVE-2024-53068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix slab-use-after-free in scmi_bus_notifier() The scmi_dev->name is released prematurely in __scmi_device_destroy(), which causes slab-use-after-free when accessing scmi_dev->name in scmi_bus_notifier(). So move the release of scmi_dev->name to scmi_device_release() to avoid slab-use-after-free. | BUG: KASAN: slab-use-after-free in strncmp+0xe4/0xec | Read of size 1 at addr ffffff80a482bcc0 by task swapper/0/1 | | CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.6.38-debug #1 | Hardware name: Qualcomm Technologies, Inc. SA8775P Ride (DT) | Call trace: | dump_backtrace+0x94/0x114 | show_stack+0x18/0x24 | dump_stack_lvl+0x48/0x60 | print_report+0xf4/0x5b0 | kasan_report+0xa4/0xec | __asan_report_load1_noabort+0x20/0x2c | strncmp+0xe4/0xec | scmi_bus_notifier+0x5c/0x54c | notifier_call_chain+0xb4/0x31c | blocking_notifier_call_chain+0x68/0x9c | bus_notify+0x54/0x78 | device_del+0x1bc/0x840 | device_unregister+0x20/0xb4 | __scmi_device_destroy+0xac/0x280 | scmi_device_destroy+0x94/0xd0 | scmi_chan_setup+0x524/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20 | | Allocated by task 1: | kasan_save_stack+0x2c/0x54 | kasan_set_track+0x2c/0x40 | kasan_save_alloc_info+0x24/0x34 | __kasan_kmalloc+0xa0/0xb8 | __kmalloc_node_track_caller+0x6c/0x104 | kstrdup+0x48/0x84 | kstrdup_const+0x34/0x40 | __scmi_device_create.part.0+0x8c/0x408 | scmi_device_create+0x104/0x370 | scmi_chan_setup+0x2a0/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20 | | Freed by task 1: | kasan_save_stack+0x2c/0x54 | kasan_set_track+0x2c/0x40 | kasan_save_free_info+0x38/0x5c | __kasan_slab_free+0xe8/0x164 | __kmem_cache_free+0x11c/0x230 | kfree+0x70/0x130 | kfree_const+0x20/0x40 | __scmi_device_destroy+0x70/0x280 | scmi_device_destroy+0x94/0xd0 | scmi_chan_setup+0x524/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53069", "url": "https://ubuntu.com/security/CVE-2024-53069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: qcom: scm: fix a NULL-pointer dereference Some SCM calls can be invoked with __scm being NULL (the driver may not have been and will not be probed as there's no SCM entry in device-tree). Make sure we don't dereference a NULL pointer.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50212", "url": "https://ubuntu.com/security/CVE-2024-50212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib: alloc_tag_module_unload must wait for pending kfree_rcu calls Ben Greear reports following splat: ------------[ cut here ]------------ net/netfilter/nf_nat_core.c:1114 module nf_nat func:nf_nat_register_fn has 256 allocated at module unload WARNING: CPU: 1 PID: 10421 at lib/alloc_tag.c:168 alloc_tag_module_unload+0x22b/0x3f0 Modules linked in: nf_nat(-) btrfs ufs qnx4 hfsplus hfs minix vfat msdos fat ... Hardware name: Default string Default string/SKYBAY, BIOS 5.12 08/04/2020 RIP: 0010:alloc_tag_module_unload+0x22b/0x3f0 codetag_unload_module+0x19b/0x2a0 ? codetag_load_module+0x80/0x80 nf_nat module exit calls kfree_rcu on those addresses, but the free operation is likely still pending by the time alloc_tag checks for leaks. Wait for outstanding kfree_rcu operations to complete before checking resolves this warning. Reproducer: unshare -n iptables-nft -t nat -A PREROUTING -p tcp grep nf_nat /proc/allocinfo # will list 4 allocations rmmod nft_chain_nat rmmod nf_nat # will WARN. [akpm@linux-foundation.org: add comment]", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53046", "url": "https://ubuntu.com/security/CVE-2024-53046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: dts: imx8ulp: correct the flexspi compatible string The flexspi on imx8ulp only has 16 LUTs, and imx8mm flexspi has 32 LUTs, so correct the compatible string here, otherwise will meet below error: [ 1.119072] ------------[ cut here ]------------ [ 1.123926] WARNING: CPU: 0 PID: 1 at drivers/spi/spi-nxp-fspi.c:855 nxp_fspi_exec_op+0xb04/0xb64 [ 1.133239] Modules linked in: [ 1.136448] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-rc6-next-20240902-00001-g131bf9439dd9 #69 [ 1.146821] Hardware name: NXP i.MX8ULP EVK (DT) [ 1.151647] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.158931] pc : nxp_fspi_exec_op+0xb04/0xb64 [ 1.163496] lr : nxp_fspi_exec_op+0xa34/0xb64 [ 1.168060] sp : ffff80008002b2a0 [ 1.171526] x29: ffff80008002b2d0 x28: 0000000000000000 x27: 0000000000000000 [ 1.179002] x26: ffff2eb645542580 x25: ffff800080610014 x24: ffff800080610000 [ 1.186480] x23: ffff2eb645548080 x22: 0000000000000006 x21: ffff2eb6455425e0 [ 1.193956] x20: 0000000000000000 x19: ffff80008002b5e0 x18: ffffffffffffffff [ 1.201432] x17: ffff2eb644467508 x16: 0000000000000138 x15: 0000000000000002 [ 1.208907] x14: 0000000000000000 x13: ffff2eb6400d8080 x12: 00000000ffffff00 [ 1.216378] x11: 0000000000000000 x10: ffff2eb6400d8080 x9 : ffff2eb697adca80 [ 1.223850] x8 : ffff2eb697ad3cc0 x7 : 0000000100000000 x6 : 0000000000000001 [ 1.231324] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000007a6 [ 1.238795] x2 : 0000000000000000 x1 : 00000000000001ce x0 : 00000000ffffff92 [ 1.246267] Call trace: [ 1.248824] nxp_fspi_exec_op+0xb04/0xb64 [ 1.253031] spi_mem_exec_op+0x3a0/0x430 [ 1.257139] spi_nor_read_id+0x80/0xcc [ 1.261065] spi_nor_scan+0x1ec/0xf10 [ 1.264901] spi_nor_probe+0x108/0x2fc [ 1.268828] spi_mem_probe+0x6c/0xbc [ 1.272574] spi_probe+0x84/0xe4 [ 1.275958] really_probe+0xbc/0x29c [ 1.279713] __driver_probe_device+0x78/0x12c [ 1.284277] driver_probe_device+0xd8/0x15c [ 1.288660] __device_attach_driver+0xb8/0x134 [ 1.293316] bus_for_each_drv+0x88/0xe8 [ 1.297337] __device_attach+0xa0/0x190 [ 1.301353] device_initial_probe+0x14/0x20 [ 1.305734] bus_probe_device+0xac/0xb0 [ 1.309752] device_add+0x5d0/0x790 [ 1.313408] __spi_add_device+0x134/0x204 [ 1.317606] of_register_spi_device+0x3b4/0x590 [ 1.322348] spi_register_controller+0x47c/0x754 [ 1.327181] devm_spi_register_controller+0x4c/0xa4 [ 1.332289] nxp_fspi_probe+0x1cc/0x2b0 [ 1.336307] platform_probe+0x68/0xc4 [ 1.340145] really_probe+0xbc/0x29c [ 1.343893] __driver_probe_device+0x78/0x12c [ 1.348457] driver_probe_device+0xd8/0x15c [ 1.352838] __driver_attach+0x90/0x19c [ 1.356857] bus_for_each_dev+0x7c/0xdc [ 1.360877] driver_attach+0x24/0x30 [ 1.364624] bus_add_driver+0xe4/0x208 [ 1.368552] driver_register+0x5c/0x124 [ 1.372573] __platform_driver_register+0x28/0x34 [ 1.377497] nxp_fspi_driver_init+0x1c/0x28 [ 1.381888] do_one_initcall+0x80/0x1c8 [ 1.385908] kernel_init_freeable+0x1c4/0x28c [ 1.390472] kernel_init+0x20/0x1d8 [ 1.394138] ret_from_fork+0x10/0x20 [ 1.397885] ---[ end trace 0000000000000000 ]--- [ 1.407908] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53052", "url": "https://ubuntu.com/security/CVE-2024-53052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/rw: fix missing NOWAIT check for O_DIRECT start write When io_uring starts a write, it'll call kiocb_start_write() to bump the super block rwsem, preventing any freezes from happening while that write is in-flight. The freeze side will grab that rwsem for writing, excluding any new writers from happening and waiting for existing writes to finish. But io_uring unconditionally uses kiocb_start_write(), which will block if someone is currently attempting to freeze the mount point. This causes a deadlock where freeze is waiting for previous writes to complete, but the previous writes cannot complete, as the task that is supposed to complete them is blocked waiting on starting a new write. This results in the following stuck trace showing that dependency with the write blocked starting a new write: task:fio state:D stack:0 pid:886 tgid:886 ppid:876 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_rwsem_wait+0x1e8/0x3f8 __percpu_down_read+0xe8/0x500 io_write+0xbb8/0xff8 io_issue_sqe+0x10c/0x1020 io_submit_sqes+0x614/0x2110 __arm64_sys_io_uring_enter+0x524/0x1038 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 INFO: task fsfreeze:7364 blocked for more than 15 seconds. Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963 with the attempting freezer stuck trying to grab the rwsem: task:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_down_write+0x2b0/0x680 freeze_super+0x248/0x8a8 do_vfs_ioctl+0x149c/0x1b18 __arm64_sys_ioctl+0xd0/0x1a0 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 Fix this by having the io_uring side honor IOCB_NOWAIT, and only attempt a blocking grab of the super block rwsem if it isn't set. For normal issue where IOCB_NOWAIT would always be set, this returns -EAGAIN which will have io_uring core issue a blocking attempt of the write. That will in turn also get completions run, ensuring forward progress. Since freezing requires CAP_SYS_ADMIN in the first place, this isn't something that can be triggered by a regular user.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50213", "url": "https://ubuntu.com/security/CVE-2024-50213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tests: hdmi: Fix memory leaks in drm_display_mode_from_cea_vic() modprobe drm_hdmi_state_helper_test and then rmmod it, the following memory leak occurs. The `mode` allocated in drm_mode_duplicate() called by drm_display_mode_from_cea_vic() is not freed, which cause the memory leak: \tunreferenced object 0xffffff80ccd18100 (size 128): \t comm \"kunit_try_catch\", pid 1851, jiffies 4295059695 \t hex dump (first 32 bytes): \t 57 62 00 00 80 02 90 02 f0 02 20 03 00 00 e0 01 Wb........ ..... \t ea 01 ec 01 0d 02 00 00 0a 00 00 00 00 00 00 00 ................ \t backtrace (crc c2f1aa95): \t [<000000000f10b11b>] kmemleak_alloc+0x34/0x40 \t [<000000001cd4cf73>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<00000000f1f3cffa>] drm_mode_duplicate+0x44/0x19c \t [<000000008cbeef13>] drm_display_mode_from_cea_vic+0x88/0x98 \t [<0000000019daaacf>] 0xffffffedc11ae69c \t [<000000000aad0f85>] kunit_try_run_case+0x13c/0x3ac \t [<00000000a9210bac>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<000000000a0b2e9e>] kthread+0x2e8/0x374 \t [<00000000bd668858>] ret_from_fork+0x10/0x20 \t...... Free `mode` by using drm_kunit_display_mode_from_cea_vic() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50214", "url": "https://ubuntu.com/security/CVE-2024-50214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/connector: hdmi: Fix memory leak in drm_display_mode_from_cea_vic() modprobe drm_connector_test and then rmmod drm_connector_test, the following memory leak occurs. The `mode` allocated in drm_mode_duplicate() called by drm_display_mode_from_cea_vic() is not freed, which cause the memory leak: \tunreferenced object 0xffffff80cb0ee400 (size 128): \t comm \"kunit_try_catch\", pid 1948, jiffies 4294950339 \t hex dump (first 32 bytes): \t 14 44 02 00 80 07 d8 07 04 08 98 08 00 00 38 04 .D............8. \t 3c 04 41 04 65 04 00 00 05 00 00 00 00 00 00 00 <.A.e........... \t backtrace (crc 90e9585c): \t [<00000000ec42e3d7>] kmemleak_alloc+0x34/0x40 \t [<00000000d0ef055a>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<00000000c2062161>] drm_mode_duplicate+0x44/0x19c \t [<00000000f96c74aa>] drm_display_mode_from_cea_vic+0x88/0x98 \t [<00000000d8f2c8b4>] 0xffffffdc982a4868 \t [<000000005d164dbc>] kunit_try_run_case+0x13c/0x3ac \t [<000000006fb23398>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<000000006ea56ca0>] kthread+0x2e8/0x374 \t [<000000000676063f>] ret_from_fork+0x10/0x20 \t...... Free `mode` by using drm_kunit_display_mode_from_cea_vic() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50215", "url": "https://ubuntu.com/security/CVE-2024-50215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: assign dh_key to NULL after kfree_sensitive ctrl->dh_key might be used across multiple calls to nvmet_setup_dhgroup() for the same controller. So it's better to nullify it after release on error path in order to avoid double free later in nvmet_destroy_auth(). Found by Linux Verification Center (linuxtesting.org) with Svace.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50216", "url": "https://ubuntu.com/security/CVE-2024-50216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix finding a last resort AG in xfs_filestream_pick_ag When the main loop in xfs_filestream_pick_ag fails to find a suitable AG it tries to just pick the online AG. But the loop for that uses args->pag as loop iterator while the later code expects pag to be set. Fix this by reusing the max_pag case for this last resort, and also add a check for impossible case of no AG just to make sure that the uninitialized pag doesn't even escape in theory.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50217", "url": "https://ubuntu.com/security/CVE-2024-50217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free of block device file in __btrfs_free_extra_devids() Mounting btrfs from two images (which have the same one fsid and two different dev_uuids) in certain executing order may trigger an UAF for variable 'device->bdev_file' in __btrfs_free_extra_devids(). And following are the details: 1. Attach image_1 to loop0, attach image_2 to loop1, and scan btrfs devices by ioctl(BTRFS_IOC_SCAN_DEV): / btrfs_device_1 ? loop0 fs_device \\ btrfs_device_2 ? loop1 2. mount /dev/loop0 /mnt btrfs_open_devices btrfs_device_1->bdev_file = btrfs_get_bdev_and_sb(loop0) btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree fail: btrfs_close_devices // -ENOMEM \t btrfs_close_bdev(btrfs_device_1) fput(btrfs_device_1->bdev_file) \t // btrfs_device_1->bdev_file is freed \t btrfs_close_bdev(btrfs_device_2) fput(btrfs_device_2->bdev_file) 3. mount /dev/loop1 /mnt btrfs_open_devices btrfs_get_bdev_and_sb(&bdev_file) // EIO, btrfs_device_1->bdev_file is not assigned, // which points to a freed memory area btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree btrfs_free_extra_devids if (btrfs_device_1->bdev_file) fput(btrfs_device_1->bdev_file) // UAF ! Fix it by setting 'device->bdev_file' as 'NULL' after closing the btrfs_device in btrfs_close_one_device().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53043", "url": "https://ubuntu.com/security/CVE-2024-53043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mctp i2c: handle NULL header address daddr can be NULL if there is no neighbour table entry present, in that case the tx packet should be dropped. saddr will usually be set by MCTP core, but check for NULL in case a packet is transmitted by a different protocol.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50303", "url": "https://ubuntu.com/security/CVE-2024-50303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: resource,kexec: walk_system_ram_res_rev must retain resource flags walk_system_ram_res_rev() erroneously discards resource flags when passing the information to the callback. This causes systems with IORESOURCE_SYSRAM_DRIVER_MANAGED memory to have these resources selected during kexec to store kexec buffers if that memory happens to be at placed above normal system ram. This leads to undefined behavior after reboot. If the kexec buffer is never touched, nothing happens. If the kexec buffer is touched, it could lead to a crash (like below) or undefined behavior. Tested on a system with CXL memory expanders with driver managed memory, TPM enabled, and CONFIG_IMA_KEXEC=y. Adding printk's showed the flags were being discarded and as a result the check for IORESOURCE_SYSRAM_DRIVER_MANAGED passes. find_next_iomem_res: name(System RAM (kmem)) \t\t start(10000000000) \t\t end(1034fffffff) \t\t flags(83000200) locate_mem_hole_top_down: start(10000000000) end(1034fffffff) flags(0) [.] BUG: unable to handle page fault for address: ffff89834ffff000 [.] #PF: supervisor read access in kernel mode [.] #PF: error_code(0x0000) - not-present page [.] PGD c04c8bf067 P4D c04c8bf067 PUD c04c8be067 PMD 0 [.] Oops: 0000 [#1] SMP [.] RIP: 0010:ima_restore_measurement_list+0x95/0x4b0 [.] RSP: 0018:ffffc900000d3a80 EFLAGS: 00010286 [.] RAX: 0000000000001000 RBX: 0000000000000000 RCX: ffff89834ffff000 [.] RDX: 0000000000000018 RSI: ffff89834ffff000 RDI: ffff89834ffff018 [.] RBP: ffffc900000d3ba0 R08: 0000000000000020 R09: ffff888132b8a900 [.] R10: 4000000000000000 R11: 000000003a616d69 R12: 0000000000000000 [.] R13: ffffffff8404ac28 R14: 0000000000000000 R15: ffff89834ffff000 [.] FS: 0000000000000000(0000) GS:ffff893d44640000(0000) knlGS:0000000000000000 [.] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [.] ata5: SATA link down (SStatus 0 SControl 300) [.] CR2: ffff89834ffff000 CR3: 000001034d00f001 CR4: 0000000000770ef0 [.] PKRU: 55555554 [.] Call Trace: [.] [.] ? __die+0x78/0xc0 [.] ? page_fault_oops+0x2a8/0x3a0 [.] ? exc_page_fault+0x84/0x130 [.] ? asm_exc_page_fault+0x22/0x30 [.] ? ima_restore_measurement_list+0x95/0x4b0 [.] ? template_desc_init_fields+0x317/0x410 [.] ? crypto_alloc_tfm_node+0x9c/0xc0 [.] ? init_ima_lsm+0x30/0x30 [.] ima_load_kexec_buffer+0x72/0xa0 [.] ima_init+0x44/0xa0 [.] __initstub__kmod_ima__373_1201_init_ima7+0x1e/0xb0 [.] ? init_ima_lsm+0x30/0x30 [.] do_one_initcall+0xad/0x200 [.] ? idr_alloc_cyclic+0xaa/0x110 [.] ? new_slab+0x12c/0x420 [.] ? new_slab+0x12c/0x420 [.] ? number+0x12a/0x430 [.] ? sysvec_apic_timer_interrupt+0xa/0x80 [.] ? asm_sysvec_apic_timer_interrupt+0x16/0x20 [.] ? parse_args+0xd4/0x380 [.] ? parse_args+0x14b/0x380 [.] kernel_init_freeable+0x1c1/0x2b0 [.] ? rest_init+0xb0/0xb0 [.] kernel_init+0x16/0x1a0 [.] ret_from_fork+0x2f/0x40 [.] ? rest_init+0xb0/0xb0 [.] ret_from_fork_asm+0x11/0x20 [.] ", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50218", "url": "https://ubuntu.com/security/CVE-2024-50218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow Syzbot reported a kernel BUG in ocfs2_truncate_inline. There are two reasons for this: first, the parameter value passed is greater than ocfs2_max_inline_data_with_xattr, second, the start and end parameters of ocfs2_truncate_inline are \"unsigned int\". So, we need to add a sanity check for byte_start and byte_len right before ocfs2_truncate_inline() in ocfs2_remove_inode_range(), if they are greater than ocfs2_max_inline_data_with_xattr return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50219", "url": "https://ubuntu.com/security/CVE-2024-50219", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50263", "url": "https://ubuntu.com/security/CVE-2024-50263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fork: only invoke khugepaged, ksm hooks if no error There is no reason to invoke these hooks early against an mm that is in an incomplete state. The change in commit d24062914837 (\"fork: use __mt_dup() to duplicate maple tree in dup_mmap()\") makes this more pertinent as we may be in a state where entries in the maple tree are not yet consistent. Their placement early in dup_mmap() only appears to have been meaningful for early error checking, and since functionally it'd require a very small allocation to fail (in practice 'too small to fail') that'd only occur in the most dire circumstances, meaning the fork would fail or be OOM'd in any case. Since both khugepaged and KSM tracking are there to provide optimisations to memory performance rather than critical functionality, it doesn't really matter all that much if, under such dire memory pressure, we fail to register an mm with these. As a result, we follow the example of commit d2081b2bf819 (\"mm: khugepaged: make khugepaged_enter() void function\") and make ksm_fork() a void function also. We only expose the mm to these functions once we are done with them and only if no error occurred in the fork operation.", "cve_priority": "medium", "cve_public_date": "2024-11-11 14:15:00 UTC" }, { "cve": "CVE-2024-50220", "url": "https://ubuntu.com/security/CVE-2024-50220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fork: do not invoke uffd on fork if error occurs Patch series \"fork: do not expose incomplete mm on fork\". During fork we may place the virtual memory address space into an inconsistent state before the fork operation is complete. In addition, we may encounter an error during the fork operation that indicates that the virtual memory address space is invalidated. As a result, we should not be exposing it in any way to external machinery that might interact with the mm or VMAs, machinery that is not designed to deal with incomplete state. We specifically update the fork logic to defer khugepaged and ksm to the end of the operation and only to be invoked if no error arose, and disallow uffd from observing fork events should an error have occurred. This patch (of 2): Currently on fork we expose the virtual address space of a process to userland unconditionally if uffd is registered in VMAs, regardless of whether an error arose in the fork. This is performed in dup_userfaultfd_complete() which is invoked unconditionally, and performs two duties - invoking registered handlers for the UFFD_EVENT_FORK event via dup_fctx(), and clearing down userfaultfd_fork_ctx objects established in dup_userfaultfd(). This is problematic, because the virtual address space may not yet be correctly initialised if an error arose. The change in commit d24062914837 (\"fork: use __mt_dup() to duplicate maple tree in dup_mmap()\") makes this more pertinent as we may be in a state where entries in the maple tree are not yet consistent. We address this by, on fork error, ensuring that we roll back state that we would otherwise expect to clean up through the event being handled by userland and perform the memory freeing duty otherwise performed by dup_userfaultfd_complete(). We do this by implementing a new function, dup_userfaultfd_fail(), which performs the same loop, only decrementing reference counts. Note that we perform mmgrab() on the parent and child mm's, however userfaultfd_ctx_put() will mmdrop() this once the reference count drops to zero, so we will avoid memory leaks correctly here.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53047", "url": "https://ubuntu.com/security/CVE-2024-53047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: init: protect sched with rcu_read_lock Enabling CONFIG_PROVE_RCU_LIST with its dependence CONFIG_RCU_EXPERT creates this splat when an MPTCP socket is created: ============================= WARNING: suspicious RCU usage 6.12.0-rc2+ #11 Not tainted ----------------------------- net/mptcp/sched.c:44 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 no locks held by mptcp_connect/176. stack backtrace: CPU: 0 UID: 0 PID: 176 Comm: mptcp_connect Not tainted 6.12.0-rc2+ #11 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl (lib/dump_stack.c:123) lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822) mptcp_sched_find (net/mptcp/sched.c:44 (discriminator 7)) mptcp_init_sock (net/mptcp/protocol.c:2867 (discriminator 1)) ? sock_init_data_uid (arch/x86/include/asm/atomic.h:28) inet_create.part.0.constprop.0 (net/ipv4/af_inet.c:386) ? __sock_create (include/linux/rcupdate.h:347 (discriminator 1)) __sock_create (net/socket.c:1576) __sys_socket (net/socket.c:1671) ? __pfx___sys_socket (net/socket.c:1712) ? do_user_addr_fault (arch/x86/mm/fault.c:1419 (discriminator 1)) __x64_sys_socket (net/socket.c:1728) do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) That's because when the socket is initialised, rcu_read_lock() is not used despite the explicit comment written above the declaration of mptcp_sched_find() in sched.c. Adding the missing lock/unlock avoids the warning.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50221", "url": "https://ubuntu.com/security/CVE-2024-50221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Vangogh: Fix kernel memory out of bounds write KASAN reports that the GPU metrics table allocated in vangogh_tables_init() is not large enough for the memset done in smu_cmn_init_soft_gpu_metrics(). Condensed report follows: [ 33.861314] BUG: KASAN: slab-out-of-bounds in smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu] [ 33.861799] Write of size 168 at addr ffff888129f59500 by task mangoapp/1067 ... [ 33.861808] CPU: 6 UID: 1000 PID: 1067 Comm: mangoapp Tainted: G W 6.12.0-rc4 #356 1a56f59a8b5182eeaf67eb7cb8b13594dd23b544 [ 33.861816] Tainted: [W]=WARN [ 33.861818] Hardware name: Valve Galileo/Galileo, BIOS F7G0107 12/01/2023 [ 33.861822] Call Trace: [ 33.861826] [ 33.861829] dump_stack_lvl+0x66/0x90 [ 33.861838] print_report+0xce/0x620 [ 33.861853] kasan_report+0xda/0x110 [ 33.862794] kasan_check_range+0xfd/0x1a0 [ 33.862799] __asan_memset+0x23/0x40 [ 33.862803] smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.863306] vangogh_get_gpu_metrics_v2_4+0x123/0xad0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.864257] vangogh_common_get_gpu_metrics+0xb0c/0xbc0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.865682] amdgpu_dpm_get_gpu_metrics+0xcc/0x110 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.866160] amdgpu_get_gpu_metrics+0x154/0x2d0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.867135] dev_attr_show+0x43/0xc0 [ 33.867147] sysfs_kf_seq_show+0x1f1/0x3b0 [ 33.867155] seq_read_iter+0x3f8/0x1140 [ 33.867173] vfs_read+0x76c/0xc50 [ 33.867198] ksys_read+0xfb/0x1d0 [ 33.867214] do_syscall_64+0x90/0x160 ... [ 33.867353] Allocated by task 378 on cpu 7 at 22.794876s: [ 33.867358] kasan_save_stack+0x33/0x50 [ 33.867364] kasan_save_track+0x17/0x60 [ 33.867367] __kasan_kmalloc+0x87/0x90 [ 33.867371] vangogh_init_smc_tables+0x3f9/0x840 [amdgpu] [ 33.867835] smu_sw_init+0xa32/0x1850 [amdgpu] [ 33.868299] amdgpu_device_init+0x467b/0x8d90 [amdgpu] [ 33.868733] amdgpu_driver_load_kms+0x19/0xf0 [amdgpu] [ 33.869167] amdgpu_pci_probe+0x2d6/0xcd0 [amdgpu] [ 33.869608] local_pci_probe+0xda/0x180 [ 33.869614] pci_device_probe+0x43f/0x6b0 Empirically we can confirm that the former allocates 152 bytes for the table, while the latter memsets the 168 large block. Root cause appears that when GPU metrics tables for v2_4 parts were added it was not considered to enlarge the table to fit. The fix in this patch is rather \"brute force\" and perhaps later should be done in a smarter way, by extracting and consolidating the part version to size logic to a common helper, instead of brute forcing the largest possible allocation. Nevertheless, for now this works and fixes the out of bounds write. v2: * Drop impossible v3_0 case. (Mario) (cherry picked from commit 0880f58f9609f0200483a49429af0f050d281703)", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50222", "url": "https://ubuntu.com/security/CVE-2024-50222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iov_iter: fix copy_page_from_iter_atomic() if KMAP_LOCAL_FORCE_MAP generic/077 on x86_32 CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP=y with highmem, on huge=always tmpfs, issues a warning and then hangs (interruptibly): WARNING: CPU: 5 PID: 3517 at mm/highmem.c:622 kunmap_local_indexed+0x62/0xc9 CPU: 5 UID: 0 PID: 3517 Comm: cp Not tainted 6.12.0-rc4 #2 ... copy_page_from_iter_atomic+0xa6/0x5ec generic_perform_write+0xf6/0x1b4 shmem_file_write_iter+0x54/0x67 Fix copy_page_from_iter_atomic() by limiting it in that case (include/linux/skbuff.h skb_frag_must_loop() does similar). But going forward, perhaps CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP is too surprising, has outlived its usefulness, and should just be removed?", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50223", "url": "https://ubuntu.com/security/CVE-2024-50223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/numa: Fix the potential null pointer dereference in task_numa_work() When running stress-ng-vm-segv test, we found a null pointer dereference error in task_numa_work(). Here is the backtrace: [323676.066985] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ...... [323676.067108] CPU: 35 PID: 2694524 Comm: stress-ng-vm-se ...... [323676.067113] pstate: 23401009 (nzCv daif +PAN -UAO +TCO +DIT +SSBS BTYPE=--) [323676.067115] pc : vma_migratable+0x1c/0xd0 [323676.067122] lr : task_numa_work+0x1ec/0x4e0 [323676.067127] sp : ffff8000ada73d20 [323676.067128] x29: ffff8000ada73d20 x28: 0000000000000000 x27: 000000003e89f010 [323676.067130] x26: 0000000000080000 x25: ffff800081b5c0d8 x24: ffff800081b27000 [323676.067133] x23: 0000000000010000 x22: 0000000104d18cc0 x21: ffff0009f7158000 [323676.067135] x20: 0000000000000000 x19: 0000000000000000 x18: ffff8000ada73db8 [323676.067138] x17: 0001400000000000 x16: ffff800080df40b0 x15: 0000000000000035 [323676.067140] x14: ffff8000ada73cc8 x13: 1fffe0017cc72001 x12: ffff8000ada73cc8 [323676.067142] x11: ffff80008001160c x10: ffff000be639000c x9 : ffff8000800f4ba4 [323676.067145] x8 : ffff000810375000 x7 : ffff8000ada73974 x6 : 0000000000000001 [323676.067147] x5 : 0068000b33e26707 x4 : 0000000000000001 x3 : ffff0009f7158000 [323676.067149] x2 : 0000000000000041 x1 : 0000000000004400 x0 : 0000000000000000 [323676.067152] Call trace: [323676.067153] vma_migratable+0x1c/0xd0 [323676.067155] task_numa_work+0x1ec/0x4e0 [323676.067157] task_work_run+0x78/0xd8 [323676.067161] do_notify_resume+0x1ec/0x290 [323676.067163] el0_svc+0x150/0x160 [323676.067167] el0t_64_sync_handler+0xf8/0x128 [323676.067170] el0t_64_sync+0x17c/0x180 [323676.067173] Code: d2888001 910003fd f9000bf3 aa0003f3 (f9401000) [323676.067177] SMP: stopping secondary CPUs [323676.070184] Starting crashdump kernel... stress-ng-vm-segv in stress-ng is used to stress test the SIGSEGV error handling function of the system, which tries to cause a SIGSEGV error on return from unmapping the whole address space of the child process. Normally this program will not cause kernel crashes. But before the munmap system call returns to user mode, a potential task_numa_work() for numa balancing could be added and executed. In this scenario, since the child process has no vma after munmap, the vma_next() in task_numa_work() will return a null pointer even if the vma iterator restarts from 0. Recheck the vma pointer before dereferencing it in task_numa_work().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53053", "url": "https://ubuntu.com/security/CVE-2024-53053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Fix another deadlock during RTC update If ufshcd_rtc_work calls ufshcd_rpm_put_sync() and the pm's usage_count is 0, we will enter the runtime suspend callback. However, the runtime suspend callback will wait to flush ufshcd_rtc_work, causing a deadlock. Replace ufshcd_rpm_put_sync() with ufshcd_rpm_put() to avoid the deadlock.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53075", "url": "https://ubuntu.com/security/CVE-2024-53075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv: Prevent a bad reference count on CPU nodes When populating cache leaves we previously fetched the CPU device node at the very beginning. But when ACPI is enabled we go through a specific branch which returns early and does not call 'of_node_put' for the node that was acquired. Since we are not using a CPU device node for the ACPI code anyways, we can simply move the initialization of it just passed the ACPI block, and we are guaranteed to have an 'of_node_put' call for the acquired node. This prevents a bad reference count of the CPU device node. Moreover, the previous function did not check for errors when acquiring the device node, so a return -ENOENT has been added for that case.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50224", "url": "https://ubuntu.com/security/CVE-2024-50224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: spi-fsl-dspi: Fix crash when not using GPIO chip select Add check for the return value of spi_get_csgpiod() to avoid passing a NULL pointer to gpiod_direction_output(), preventing a crash when GPIO chip select is not used. Fix below crash: [ 4.251960] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 4.260762] Mem abort info: [ 4.263556] ESR = 0x0000000096000004 [ 4.267308] EC = 0x25: DABT (current EL), IL = 32 bits [ 4.272624] SET = 0, FnV = 0 [ 4.275681] EA = 0, S1PTW = 0 [ 4.278822] FSC = 0x04: level 0 translation fault [ 4.283704] Data abort info: [ 4.286583] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 4.292074] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 4.297130] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 4.302445] [0000000000000000] user address but active_mm is swapper [ 4.308805] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 4.315072] Modules linked in: [ 4.318124] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc4-next-20241023-00008-ga20ec42c5fc1 #359 [ 4.328130] Hardware name: LS1046A QDS Board (DT) [ 4.332832] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 4.339794] pc : gpiod_direction_output+0x34/0x5c [ 4.344505] lr : gpiod_direction_output+0x18/0x5c [ 4.349208] sp : ffff80008003b8f0 [ 4.352517] x29: ffff80008003b8f0 x28: 0000000000000000 x27: ffffc96bcc7e9068 [ 4.359659] x26: ffffc96bcc6e00b0 x25: ffffc96bcc598398 x24: ffff447400132810 [ 4.366800] x23: 0000000000000000 x22: 0000000011e1a300 x21: 0000000000020002 [ 4.373940] x20: 0000000000000000 x19: 0000000000000000 x18: ffffffffffffffff [ 4.381081] x17: ffff44740016e600 x16: 0000000500000003 x15: 0000000000000007 [ 4.388221] x14: 0000000000989680 x13: 0000000000020000 x12: 000000000000001e [ 4.395362] x11: 0044b82fa09b5a53 x10: 0000000000000019 x9 : 0000000000000008 [ 4.402502] x8 : 0000000000000002 x7 : 0000000000000007 x6 : 0000000000000000 [ 4.409641] x5 : 0000000000000200 x4 : 0000000002000000 x3 : 0000000000000000 [ 4.416781] x2 : 0000000000022202 x1 : 0000000000000000 x0 : 0000000000000000 [ 4.423921] Call trace: [ 4.426362] gpiod_direction_output+0x34/0x5c (P) [ 4.431067] gpiod_direction_output+0x18/0x5c (L) [ 4.435771] dspi_setup+0x220/0x334", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50225", "url": "https://ubuntu.com/security/CVE-2024-50225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix error propagation of split bios The purpose of btrfs_bbio_propagate_error() shall be propagating an error of split bio to its original btrfs_bio, and tell the error to the upper layer. However, it's not working well on some cases. * Case 1. Immediate (or quick) end_bio with an error When btrfs sends btrfs_bio to mirrored devices, btrfs calls btrfs_bio_end_io() when all the mirroring bios are completed. If that btrfs_bio was split, it is from btrfs_clone_bioset and its end_io function is btrfs_orig_write_end_io. For this case, btrfs_bbio_propagate_error() accesses the orig_bbio's bio context to increase the error count. That works well in most cases. However, if the end_io is called enough fast, orig_bbio's (remaining part after split) bio context may not be properly set at that time. Since the bio context is set when the orig_bbio (the last btrfs_bio) is sent to devices, that might be too late for earlier split btrfs_bio's completion. That will result in NULL pointer dereference. That bug is easily reproducible by running btrfs/146 on zoned devices [1] and it shows the following trace. [1] You need raid-stripe-tree feature as it create \"-d raid0 -m raid1\" FS. BUG: kernel NULL pointer dereference, address: 0000000000000020 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 UID: 0 PID: 13 Comm: kworker/u32:1 Not tainted 6.11.0-rc7-BTRFS-ZNS+ #474 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Workqueue: writeback wb_workfn (flush-btrfs-5) RIP: 0010:btrfs_bio_end_io+0xae/0xc0 [btrfs] BTRFS error (device dm-0): bdev /dev/mapper/error-test errs: wr 2, rd 0, flush 0, corrupt 0, gen 0 RSP: 0018:ffffc9000006f248 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888005a7f080 RCX: ffffc9000006f1dc RDX: 0000000000000000 RSI: 000000000000000a RDI: ffff888005a7f080 RBP: ffff888011dfc540 R08: 0000000000000000 R09: 0000000000000001 R10: ffffffff82e508e0 R11: 0000000000000005 R12: ffff88800ddfbe58 R13: ffff888005a7f080 R14: ffff888005a7f158 R15: ffff888005a7f158 FS: 0000000000000000(0000) GS:ffff88803ea80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000020 CR3: 0000000002e22006 CR4: 0000000000370ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __die_body.cold+0x19/0x26 ? page_fault_oops+0x13e/0x2b0 ? _printk+0x58/0x73 ? do_user_addr_fault+0x5f/0x750 ? exc_page_fault+0x76/0x240 ? asm_exc_page_fault+0x22/0x30 ? btrfs_bio_end_io+0xae/0xc0 [btrfs] ? btrfs_log_dev_io_error+0x7f/0x90 [btrfs] btrfs_orig_write_end_io+0x51/0x90 [btrfs] dm_submit_bio+0x5c2/0xa50 [dm_mod] ? find_held_lock+0x2b/0x80 ? blk_try_enter_queue+0x90/0x1e0 __submit_bio+0xe0/0x130 ? ktime_get+0x10a/0x160 ? lockdep_hardirqs_on+0x74/0x100 submit_bio_noacct_nocheck+0x199/0x410 btrfs_submit_bio+0x7d/0x150 [btrfs] btrfs_submit_chunk+0x1a1/0x6d0 [btrfs] ? lockdep_hardirqs_on+0x74/0x100 ? __folio_start_writeback+0x10/0x2c0 btrfs_submit_bbio+0x1c/0x40 [btrfs] submit_one_bio+0x44/0x60 [btrfs] submit_extent_folio+0x13f/0x330 [btrfs] ? btrfs_set_range_writeback+0xa3/0xd0 [btrfs] extent_writepage_io+0x18b/0x360 [btrfs] extent_write_locked_range+0x17c/0x340 [btrfs] ? __pfx_end_bbio_data_write+0x10/0x10 [btrfs] run_delalloc_cow+0x71/0xd0 [btrfs] btrfs_run_delalloc_range+0x176/0x500 [btrfs] ? find_lock_delalloc_range+0x119/0x260 [btrfs] writepage_delalloc+0x2ab/0x480 [btrfs] extent_write_cache_pages+0x236/0x7d0 [btrfs] btrfs_writepages+0x72/0x130 [btrfs] do_writepages+0xd4/0x240 ? find_held_lock+0x2b/0x80 ? wbc_attach_and_unlock_inode+0x12c/0x290 ? wbc_attach_and_unlock_inode+0x12c/0x29 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53054", "url": "https://ubuntu.com/security/CVE-2024-53054", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50226", "url": "https://ubuntu.com/security/CVE-2024-50226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cxl/port: Fix use-after-free, permit out-of-order decoder shutdown In support of investigating an initialization failure report [1], cxl_test was updated to register mock memory-devices after the mock root-port/bus device had been registered. That led to cxl_test crashing with a use-after-free bug with the following signature: cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem0:decoder7.0 @ 0 next: cxl_switch_uport.0 nr_eps: 1 nr_targets: 1 cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem4:decoder14.0 @ 1 next: cxl_switch_uport.0 nr_eps: 2 nr_targets: 1 cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[0] = cxl_switch_dport.0 for mem0:decoder7.0 @ 0 1) cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[1] = cxl_switch_dport.4 for mem4:decoder14.0 @ 1 [..] cxld_unregister: cxl decoder14.0: cxl_region_decode_reset: cxl_region region3: mock_decoder_reset: cxl_port port3: decoder3.0 reset 2) mock_decoder_reset: cxl_port port3: decoder3.0: out of order reset, expected decoder3.1 cxl_endpoint_decoder_release: cxl decoder14.0: [..] cxld_unregister: cxl decoder7.0: 3) cxl_region_decode_reset: cxl_region region3: Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6bc3: 0000 [#1] PREEMPT SMP PTI [..] RIP: 0010:to_cxl_port+0x8/0x60 [cxl_core] [..] Call Trace: cxl_region_decode_reset+0x69/0x190 [cxl_core] cxl_region_detach+0xe8/0x210 [cxl_core] cxl_decoder_kill_region+0x27/0x40 [cxl_core] cxld_unregister+0x5d/0x60 [cxl_core] At 1) a region has been established with 2 endpoint decoders (7.0 and 14.0). Those endpoints share a common switch-decoder in the topology (3.0). At teardown, 2), decoder14.0 is the first to be removed and hits the \"out of order reset case\" in the switch decoder. The effect though is that region3 cleanup is aborted leaving it in-tact and referencing decoder14.0. At 3) the second attempt to teardown region3 trips over the stale decoder14.0 object which has long since been deleted. The fix here is to recognize that the CXL specification places no mandate on in-order shutdown of switch-decoders, the driver enforces in-order allocation, and hardware enforces in-order commit. So, rather than fail and leave objects dangling, always remove them. In support of making cxl_region_decode_reset() always succeed, cxl_region_invalidate_memregion() failures are turned into warnings. Crashing the kernel is ok there since system integrity is at risk if caches cannot be managed around physical address mutation events like CXL region destruction. A new device_for_each_child_reverse_from() is added to cleanup port->commit_end after all dependent decoders have been disabled. In other words if decoders are allocated 0->1->2 and disabled 1->2->0 then port->commit_end only decrements from 2 after 2 has been disabled, and it decrements all the way to zero since 1 was disabled previously.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50227", "url": "https://ubuntu.com/security/CVE-2024-50227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Fix KASAN reported stack out-of-bounds read in tb_retimer_scan() KASAN reported following issue: BUG: KASAN: stack-out-of-bounds in tb_retimer_scan+0xffe/0x1550 [thunderbolt] Read of size 4 at addr ffff88810111fc1c by task kworker/u56:0/11 CPU: 0 UID: 0 PID: 11 Comm: kworker/u56:0 Tainted: G U 6.11.0+ #1387 Tainted: [U]=USER Workqueue: thunderbolt0 tb_handle_hotplug [thunderbolt] Call Trace: dump_stack_lvl+0x6c/0x90 print_report+0xd1/0x630 kasan_report+0xdb/0x110 __asan_report_load4_noabort+0x14/0x20 tb_retimer_scan+0xffe/0x1550 [thunderbolt] tb_scan_port+0xa6f/0x2060 [thunderbolt] tb_handle_hotplug+0x17b1/0x3080 [thunderbolt] process_one_work+0x626/0x1100 worker_thread+0x6c8/0xfa0 kthread+0x2c8/0x3a0 ret_from_fork+0x3a/0x80 ret_from_fork_asm+0x1a/0x30 This happens because the loop variable still gets incremented by one so max becomes 3 instead of 2, and this makes the second loop read past the the array declared on the stack. Fix this by assigning to max directly in the loop body.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50228", "url": "https://ubuntu.com/security/CVE-2024-50228", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50229", "url": "https://ubuntu.com/security/CVE-2024-50229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential deadlock with newly created symlinks Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers memory reclamation involving the filesystem layer, which can result in circular lock dependencies among the reader/writer semaphore nilfs->ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the fs_reclaim pseudo lock. This is because after commit 21fc61c73c39 (\"don't put symlink bodies in pagecache into highmem\"), the gfp flags of the page cache for symbolic links are overwritten to GFP_KERNEL via inode_nohighmem(). This is not a problem for symlinks read from the backing device, because the __GFP_FS flag is dropped after inode_nohighmem() is called. However, when a new symlink is created with nilfs_symlink(), the gfp flags remain overwritten to GFP_KERNEL. Then, memory allocation called from page_symlink() etc. triggers memory reclamation including the FS layer, which may call nilfs_evict_inode() or nilfs_dirty_inode(). And these can cause a deadlock if they are called while nilfs->ns_segctor_sem is held: Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags of newly created symlinks in the same way that nilfs_new_inode() and __nilfs_read_inode() do, as a workaround until we adopt nofs allocation scope consistently or improve the locking constraints.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50230", "url": "https://ubuntu.com/security/CVE-2024-50230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug due to missing clearing of checked flag Syzbot reported that in directory operations after nilfs2 detects filesystem corruption and degrades to read-only, __block_write_begin_int(), which is called to prepare block writes, may fail the BUG_ON check for accesses exceeding the folio/page size, triggering a kernel bug. This was found to be because the \"checked\" flag of a page/folio was not cleared when it was discarded by nilfs2's own routine, which causes the sanity check of directory entries to be skipped when the directory page/folio is reloaded. So, fix that. This was necessary when the use of nilfs2's own page discard routine was applied to more than just metadata files.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50231", "url": "https://ubuntu.com/security/CVE-2024-50231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gts-helper: Fix memory leaks in iio_gts_build_avail_scale_table() modprobe iio-test-gts and rmmod it, then the following memory leak occurs: \tunreferenced object 0xffffff80c810be00 (size 64): \t comm \"kunit_try_catch\", pid 1654, jiffies 4294913981 \t hex dump (first 32 bytes): \t 02 00 00 00 08 00 00 00 20 00 00 00 40 00 00 00 ........ ...@... \t 80 00 00 00 00 02 00 00 00 04 00 00 00 08 00 00 ................ \t backtrace (crc a63d875e): \t [<0000000028c1b3c2>] kmemleak_alloc+0x34/0x40 \t [<000000001d6ecc87>] __kmalloc_noprof+0x2bc/0x3c0 \t [<00000000393795c1>] devm_iio_init_iio_gts+0x4b4/0x16f4 \t [<0000000071bb4b09>] 0xffffffdf052a62e0 \t [<000000000315bc18>] 0xffffffdf052a6488 \t [<00000000f9dc55b5>] kunit_try_run_case+0x13c/0x3ac \t [<00000000175a3fd4>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000f505065d>] kthread+0x2e8/0x374 \t [<00000000bbfb0e5d>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cbfe9e70 (size 16): \t comm \"kunit_try_catch\", pid 1658, jiffies 4294914015 \t hex dump (first 16 bytes): \t 10 00 00 00 40 00 00 00 80 00 00 00 00 00 00 00 ....@........... \t backtrace (crc 857f0cb4): \t [<0000000028c1b3c2>] kmemleak_alloc+0x34/0x40 \t [<000000001d6ecc87>] __kmalloc_noprof+0x2bc/0x3c0 \t [<00000000393795c1>] devm_iio_init_iio_gts+0x4b4/0x16f4 \t [<0000000071bb4b09>] 0xffffffdf052a62e0 \t [<000000007d089d45>] 0xffffffdf052a6864 \t [<00000000f9dc55b5>] kunit_try_run_case+0x13c/0x3ac \t [<00000000175a3fd4>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000f505065d>] kthread+0x2e8/0x374 \t [<00000000bbfb0e5d>] ret_from_fork+0x10/0x20 \t...... It includes 5*5 times \"size 64\" memory leaks, which correspond to 5 times test_init_iio_gain_scale() calls with gts_test_gains size 10 (10*size(int)) and gts_test_itimes size 5. It also includes 5*1 times \"size 16\" memory leak, which correspond to one time __test_init_iio_gain_scale() call with gts_test_gains_gain_low size 3 (3*size(int)) and gts_test_itimes size 5. The reason is that the per_time_gains[i] is not freed which is allocated in the \"gts->num_itime\" for loop in iio_gts_build_avail_scale_table().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53076", "url": "https://ubuntu.com/security/CVE-2024-53076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gts-helper: Fix memory leaks for the error path of iio_gts_build_avail_scale_table() If per_time_scales[i] or per_time_gains[i] kcalloc fails in the for loop of iio_gts_build_avail_scale_table(), the err_free_out will fail to call kfree() each time when i is reduced to 0, so all the per_time_scales[0] and per_time_gains[0] will not be freed, which will cause memory leaks. Fix it by checking if i >= 0.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50232", "url": "https://ubuntu.com/security/CVE-2024-50232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr() In the ad7124_write_raw() function, parameter val can potentially be zero. This may lead to a division by zero when DIV_ROUND_CLOSEST() is called within ad7124_set_channel_odr(). The ad7124_write_raw() function is invoked through the sequence: iio_write_channel_raw() -> iio_write_channel_attribute() -> iio_channel_write(), with no checks in place to ensure val is non-zero.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50233", "url": "https://ubuntu.com/security/CVE-2024-50233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: iio: frequency: ad9832: fix division by zero in ad9832_calc_freqreg() In the ad9832_write_frequency() function, clk_get_rate() might return 0. This can lead to a division by zero when calling ad9832_calc_freqreg(). The check if (fout > (clk_get_rate(st->mclk) / 2)) does not protect against the case when fout is 0. The ad9832_write_frequency() function is called from ad9832_write(), and fout is derived from a text buffer, which can contain any value.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53055", "url": "https://ubuntu.com/security/CVE-2024-53055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix 6 GHz scan construction If more than 255 colocated APs exist for the set of all APs found during 2.4/5 GHz scanning, then the 6 GHz scan construction will loop forever since the loop variable has type u8, which can never reach the number found when that's bigger than 255, and is stored in a u32 variable. Also move it into the loops to have a smaller scope. Using a u32 there is fine, we limit the number of APs in the scan list and each has a limit on the number of RNR entries due to the frame size. With a limit of 1000 scan results, a frame size upper bound of 4096 (really it's more like ~2300) and a TBTT entry size of at least 11, we get an upper bound for the number of ~372k, well in the bounds of a u32.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50234", "url": "https://ubuntu.com/security/CVE-2024-50234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlegacy: Clear stale interrupts before resuming device iwl4965 fails upon resume from hibernation on my laptop. The reason seems to be a stale interrupt which isn't being cleared out before interrupts are enabled. We end up with a race beween the resume trying to bring things back up, and the restart work (queued form the interrupt handler) trying to bring things down. Eventually the whole thing blows up. Fix the problem by clearing out any stale interrupts before interrupts get enabled during resume. Here's a debug log of the indicent: [ 12.042589] ieee80211 phy0: il_isr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000 [ 12.042625] ieee80211 phy0: il4965_irq_tasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000 [ 12.042651] iwl4965 0000:10:00.0: RF_KILL bit toggled to enable radio. [ 12.042653] iwl4965 0000:10:00.0: On demand firmware reload [ 12.042690] ieee80211 phy0: il4965_irq_tasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282 [ 12.052207] ieee80211 phy0: il4965_mac_start enter [ 12.052212] ieee80211 phy0: il_prep_station Add STA to driver ID 31: ff:ff:ff:ff:ff:ff [ 12.052244] ieee80211 phy0: il4965_set_hw_ready hardware ready [ 12.052324] ieee80211 phy0: il_apm_init Init card's basic functions [ 12.052348] ieee80211 phy0: il_apm_init L1 Enabled; Disabling L0S [ 12.055727] ieee80211 phy0: il4965_load_bsm Begin load bsm [ 12.056140] ieee80211 phy0: il4965_verify_bsm Begin verify bsm [ 12.058642] ieee80211 phy0: il4965_verify_bsm BSM bootstrap uCode image OK [ 12.058721] ieee80211 phy0: il4965_load_bsm BSM write complete, poll 1 iterations [ 12.058734] ieee80211 phy0: __il4965_up iwl4965 is coming up [ 12.058737] ieee80211 phy0: il4965_mac_start Start UP work done. [ 12.058757] ieee80211 phy0: __il4965_down iwl4965 is going down [ 12.058761] ieee80211 phy0: il_scan_cancel_timeout Scan cancel timeout [ 12.058762] ieee80211 phy0: il_do_scan_abort Not performing scan to abort [ 12.058765] ieee80211 phy0: il_clear_ucode_stations Clearing ucode stations in driver [ 12.058767] ieee80211 phy0: il_clear_ucode_stations No active stations found to be cleared [ 12.058819] ieee80211 phy0: _il_apm_stop Stop card, put in low power state [ 12.058827] ieee80211 phy0: _il_apm_stop_master stop master [ 12.058864] ieee80211 phy0: il4965_clear_free_frames 0 frames on pre-allocated heap on clear. [ 12.058869] ieee80211 phy0: Hardware restart was requested [ 16.132299] iwl4965 0000:10:00.0: START_ALIVE timeout after 4000ms. [ 16.132303] ------------[ cut here ]------------ [ 16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue. [ 16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132390] Modules linked in: ctr ccm sch_fq_codel xt_tcpudp xt_multiport xt_state iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables binfmt_misc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdh_generic ecc iTCO_wdt i2c_dev iwl4965 iwlegacy coretemp snd_hda_codec_analog pcspkr psmouse mac80211 snd_hda_codec_generic libarc4 sdhci_pci cqhci sha256_generic sdhci libsha256 firewire_ohci snd_hda_intel snd_intel_dspcfg mmc_core snd_hda_codec snd_hwdep firewire_core led_class iosf_mbi snd_hda_core uhci_hcd lpc_ich crc_itu_t cfg80211 ehci_pci ehci_hcd snd_pcm usbcore mfd_core rfkill snd_timer snd usb_common soundcore video parport_pc parport intel_agp wmi intel_gtt backlight e1000e agpgart evdev [ 16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143 [ 16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010 [ 16.132463] Workqueue: async async_run_entry_fn [ 16.132469] RIP: 0010:ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132501] Code: da 02 00 0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50235", "url": "https://ubuntu.com/security/CVE-2024-50235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: clear wdev->cqm_config pointer on free When we free wdev->cqm_config when unregistering, we also need to clear out the pointer since the same wdev/netdev may get re-registered in another network namespace, then destroyed later, running this code again, which results in a double-free.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50236", "url": "https://ubuntu.com/security/CVE-2024-50236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: Fix memory leak in management tx In the current logic, memory is allocated for storing the MSDU context during management packet TX but this memory is not being freed during management TX completion. Similar leaks are seen in the management TX cleanup logic. Kmemleak reports this problem as below, unreferenced object 0xffffff80b64ed250 (size 16): comm \"kworker/u16:7\", pid 148, jiffies 4294687130 (age 714.199s) hex dump (first 16 bytes): 00 2b d8 d8 80 ff ff ff c4 74 e9 fd 07 00 00 00 .+.......t...... backtrace: [] __kmem_cache_alloc_node+0x1e4/0x2d8 [] kmalloc_trace+0x48/0x110 [] ath10k_wmi_tlv_op_gen_mgmt_tx_send+0xd4/0x1d8 [ath10k_core] [] ath10k_mgmt_over_wmi_tx_work+0x134/0x298 [ath10k_core] [] process_scheduled_works+0x1ac/0x400 [] worker_thread+0x208/0x328 [] kthread+0x100/0x1c0 [] ret_from_fork+0x10/0x20 Free the memory during completion and cleanup to fix the leak. Protect the mgmt_pending_tx idr_remove() operation in ath10k_wmi_tlv_op_cleanup_mgmt_tx_send() using ar->data_lock similar to other instances. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50237", "url": "https://ubuntu.com/security/CVE-2024-50237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower Avoid potentially crashing in the driver because of uninitialized private data", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50238", "url": "https://ubuntu.com/security/CVE-2024-50238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usbc: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data from the qcom-qmp-usb driver, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. This bug was later reproduced when the driver was copied to create the qmp-usbc driver. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with these drivers.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50239", "url": "https://ubuntu.com/security/CVE-2024-50239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usb-legacy: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data from the qcom-qmp-usb driver, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. This bug was later reproduced when the driver was copied to create the qmp-usb-legacy driver. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with these drivers.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50240", "url": "https://ubuntu.com/security/CVE-2024-50240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usb: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with this driver.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53077", "url": "https://ubuntu.com/security/CVE-2024-53077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpcrdma: Always release the rpcrdma_device's xa_array Dai pointed out that the xa_init_flags() in rpcrdma_add_one() needs to have a matching xa_destroy() in rpcrdma_remove_one() to release underlying memory that the xarray might have accrued during operation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50242", "url": "https://ubuntu.com/security/CVE-2024-50242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ntfs_file_release", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50243", "url": "https://ubuntu.com/security/CVE-2024-50243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix general protection fault in run_is_mapped_full Fixed deleating of a non-resident attribute in ntfs_create_inode() rollback.", "cve_priority": "low", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50244", "url": "https://ubuntu.com/security/CVE-2024-50244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ni_clear() Checking of NTFS_FLAGS_LOG_REPLAYING added to prevent access to uninitialized bitmap during replay process.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50245", "url": "https://ubuntu.com/security/CVE-2024-50245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix possible deadlock in mi_read Mutex lock with another subclass used in ni_lock_dir().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50246", "url": "https://ubuntu.com/security/CVE-2024-50246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Add rough attr alloc_size check", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50247", "url": "https://ubuntu.com/security/CVE-2024-50247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Check if more than chunk-size bytes are written A incorrectly formatted chunk may decompress into more than LZNT_CHUNK_SIZE bytes and a index out of bounds will occur in s_max_off.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50248", "url": "https://ubuntu.com/security/CVE-2024-50248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Add bounds checking to mi_enum_attr() Added bounds checking to make sure that every attr don't stray beyond valid memory region.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53078", "url": "https://ubuntu.com/security/CVE-2024-53078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Fix NULL vs IS_ERR() check in probe() The iommu_paging_domain_alloc() function doesn't return NULL pointers, it returns error pointers. Update the check to match.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53056", "url": "https://ubuntu.com/security/CVE-2024-53056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Fix potential NULL dereference in mtk_crtc_destroy() In mtk_crtc_create(), if the call to mbox_request_channel() fails then we set the \"mtk_crtc->cmdq_client.chan\" pointer to NULL. In that situation, we do not call cmdq_pkt_create(). During the cleanup, we need to check if the \"mtk_crtc->cmdq_client.chan\" is NULL first before calling cmdq_pkt_destroy(). Calling cmdq_pkt_destroy() is unnecessary if we didn't call cmdq_pkt_create() and it will result in a NULL pointer dereference.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50249", "url": "https://ubuntu.com/security/CVE-2024-50249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Make rmw_lock a raw_spin_lock The following BUG was triggered: ============================= [ BUG: Invalid wait context ] 6.12.0-rc2-XXX #406 Not tainted ----------------------------- kworker/1:1/62 is trying to lock: ffffff8801593030 (&cpc_ptr->rmw_lock){+.+.}-{3:3}, at: cpc_write+0xcc/0x370 other info that might help us debug this: context-{5:5} 2 locks held by kworker/1:1/62: #0: ffffff897ef5ec98 (&rq->__lock){-.-.}-{2:2}, at: raw_spin_rq_lock_nested+0x2c/0x50 #1: ffffff880154e238 (&sg_policy->update_lock){....}-{2:2}, at: sugov_update_shared+0x3c/0x280 stack backtrace: CPU: 1 UID: 0 PID: 62 Comm: kworker/1:1 Not tainted 6.12.0-rc2-g9654bd3e8806 #406 Workqueue: 0x0 (events) Call trace: dump_backtrace+0xa4/0x130 show_stack+0x20/0x38 dump_stack_lvl+0x90/0xd0 dump_stack+0x18/0x28 __lock_acquire+0x480/0x1ad8 lock_acquire+0x114/0x310 _raw_spin_lock+0x50/0x70 cpc_write+0xcc/0x370 cppc_set_perf+0xa0/0x3a8 cppc_cpufreq_fast_switch+0x40/0xc0 cpufreq_driver_fast_switch+0x4c/0x218 sugov_update_shared+0x234/0x280 update_load_avg+0x6ec/0x7b8 dequeue_entities+0x108/0x830 dequeue_task_fair+0x58/0x408 __schedule+0x4f0/0x1070 schedule+0x54/0x130 worker_thread+0xc0/0x2e8 kthread+0x130/0x148 ret_from_fork+0x10/0x20 sugov_update_shared() locks a raw_spinlock while cpc_write() locks a spinlock. To have a correct wait-type order, update rmw_lock to a raw spinlock and ensure that interrupts will be disabled on the CPU holding it. [ rjw: Changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50250", "url": "https://ubuntu.com/security/CVE-2024-50250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fsdax: dax_unshare_iter needs to copy entire blocks The code that copies data from srcmap to iomap in dax_unshare_iter is very very broken, which bfoster's recent fsx changes have exposed. If the pos and len passed to dax_file_unshare are not aligned to an fsblock boundary, the iter pos and length in the _iter function will reflect this unalignment. dax_iomap_direct_access always returns a pointer to the start of the kmapped fsdax page, even if its pos argument is in the middle of that page. This is catastrophic for data integrity when iter->pos is not aligned to a page, because daddr/saddr do not point to the same byte in the file as iter->pos. Hence we corrupt user data by copying it to the wrong place. If iter->pos + iomap_length() in the _iter function not aligned to a page, then we fail to copy a full block, and only partially populate the destination block. This is catastrophic for data confidentiality because we expose stale pmem contents. Fix both of these issues by aligning copy_pos/copy_len to a page boundary (remember, this is fsdax so 1 fsblock == 1 base page) so that we always copy full blocks. We're not done yet -- there's no call to invalidate_inode_pages2_range, so programs that have the file range mmap'd will continue accessing the old memory mapping after the file metadata updates have completed. Be careful with the return value -- if the unshare succeeds, we still need to return the number of bytes that the iomap iter thinks we're operating on.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50251", "url": "https://ubuntu.com/security/CVE-2024-50251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_payload: sanitize offset and length before calling skb_checksum() If access to offset + length is larger than the skbuff length, then skb_checksum() triggers BUG_ON(). skb_checksum() internally subtracts the length parameter while iterating over skbuff, BUG_ON(len) at the end of it checks that the expected length to be included in the checksum calculation is fully consumed.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50252", "url": "https://ubuntu.com/security/CVE-2024-50252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_ipip: Fix memory leak when changing remote IPv6 address The device stores IPv6 addresses that are used for encapsulation in linear memory that is managed by the driver. Changing the remote address of an ip6gre net device never worked properly, but since cited commit the following reproducer [1] would result in a warning [2] and a memory leak [3]. The problem is that the new remote address is never added by the driver to its hash table (and therefore the device) and the old address is never removed from it. Fix by programming the new address when the configuration of the ip6gre net device changes and removing the old one. If the address did not change, then the above would result in increasing the reference count of the address and then decreasing it. [1] # ip link add name bla up type ip6gre local 2001:db8:1::1 remote 2001:db8:2::1 tos inherit ttl inherit # ip link set dev bla type ip6gre remote 2001:db8:3::1 # ip link del dev bla # devlink dev reload pci/0000:01:00.0 [2] WARNING: CPU: 0 PID: 1682 at drivers/net/ethernet/mellanox/mlxsw/spectrum.c:3002 mlxsw_sp_ipv6_addr_put+0x140/0x1d0 Modules linked in: CPU: 0 UID: 0 PID: 1682 Comm: ip Not tainted 6.12.0-rc3-custom-g86b5b55bc835 #151 Hardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023 RIP: 0010:mlxsw_sp_ipv6_addr_put+0x140/0x1d0 [...] Call Trace: mlxsw_sp_router_netdevice_event+0x55f/0x1240 notifier_call_chain+0x5a/0xd0 call_netdevice_notifiers_info+0x39/0x90 unregister_netdevice_many_notify+0x63e/0x9d0 rtnl_dellink+0x16b/0x3a0 rtnetlink_rcv_msg+0x142/0x3f0 netlink_rcv_skb+0x50/0x100 netlink_unicast+0x242/0x390 netlink_sendmsg+0x1de/0x420 ____sys_sendmsg+0x2bd/0x320 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xd0 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f [3] unreferenced object 0xffff898081f597a0 (size 32): comm \"ip\", pid 1626, jiffies 4294719324 hex dump (first 32 bytes): 20 01 0d b8 00 02 00 00 00 00 00 00 00 00 00 01 ............... 21 49 61 83 80 89 ff ff 00 00 00 00 01 00 00 00 !Ia............. backtrace (crc fd9be911): [<00000000df89c55d>] __kmalloc_cache_noprof+0x1da/0x260 [<00000000ff2a1ddb>] mlxsw_sp_ipv6_addr_kvdl_index_get+0x281/0x340 [<000000009ddd445d>] mlxsw_sp_router_netdevice_event+0x47b/0x1240 [<00000000743e7757>] notifier_call_chain+0x5a/0xd0 [<000000007c7b9e13>] call_netdevice_notifiers_info+0x39/0x90 [<000000002509645d>] register_netdevice+0x5f7/0x7a0 [<00000000c2e7d2a9>] ip6gre_newlink_common.isra.0+0x65/0x130 [<0000000087cd6d8d>] ip6gre_newlink+0x72/0x120 [<000000004df7c7cc>] rtnl_newlink+0x471/0xa20 [<0000000057ed632a>] rtnetlink_rcv_msg+0x142/0x3f0 [<0000000032e0d5b5>] netlink_rcv_skb+0x50/0x100 [<00000000908bca63>] netlink_unicast+0x242/0x390 [<00000000cdbe1c87>] netlink_sendmsg+0x1de/0x420 [<0000000011db153e>] ____sys_sendmsg+0x2bd/0x320 [<000000003b6d53eb>] ___sys_sendmsg+0x9a/0xe0 [<00000000cae27c62>] __sys_sendmsg+0x7a/0xd0", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50253", "url": "https://ubuntu.com/security/CVE-2024-50253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check the validity of nr_words in bpf_iter_bits_new() Check the validity of nr_words in bpf_iter_bits_new(). Without this check, when multiplication overflow occurs for nr_bits (e.g., when nr_words = 0x0400-0001, nr_bits becomes 64), stack corruption may occur due to bpf_probe_read_kernel_common(..., nr_bytes = 0x2000-0008). Fix it by limiting the maximum value of nr_words to 511. The value is derived from the current implementation of BPF memory allocator. To ensure compatibility if the BPF memory allocator's size limitation changes in the future, use the helper bpf_mem_alloc_check_size() to check whether nr_bytes is too larger. And return -E2BIG instead of -ENOMEM for oversized nr_bytes.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50254", "url": "https://ubuntu.com/security/CVE-2024-50254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free dynamically allocated bits in bpf_iter_bits_destroy() bpf_iter_bits_destroy() uses \"kit->nr_bits <= 64\" to check whether the bits are dynamically allocated. However, the check is incorrect and may cause a kmemleak as shown below: unreferenced object 0xffff88812628c8c0 (size 32): comm \"swapper/0\", pid 1, jiffies 4294727320 hex dump (first 32 bytes): \tb0 c1 55 f5 81 88 ff ff f0 f0 f0 f0 f0 f0 f0 f0 ..U........... \tf0 f0 f0 f0 f0 f0 f0 f0 00 00 00 00 00 00 00 00 .............. backtrace (crc 781e32cc): \t[<00000000c452b4ab>] kmemleak_alloc+0x4b/0x80 \t[<0000000004e09f80>] __kmalloc_node_noprof+0x480/0x5c0 \t[<00000000597124d6>] __alloc.isra.0+0x89/0xb0 \t[<000000004ebfffcd>] alloc_bulk+0x2af/0x720 \t[<00000000d9c10145>] prefill_mem_cache+0x7f/0xb0 \t[<00000000ff9738ff>] bpf_mem_alloc_init+0x3e2/0x610 \t[<000000008b616eac>] bpf_global_ma_init+0x19/0x30 \t[<00000000fc473efc>] do_one_initcall+0xd3/0x3c0 \t[<00000000ec81498c>] kernel_init_freeable+0x66a/0x940 \t[<00000000b119f72f>] kernel_init+0x20/0x160 \t[<00000000f11ac9a7>] ret_from_fork+0x3c/0x70 \t[<0000000004671da4>] ret_from_fork_asm+0x1a/0x30 That is because nr_bits will be set as zero in bpf_iter_bits_next() after all bits have been iterated. Fix the issue by setting kit->bit to kit->nr_bits instead of setting kit->nr_bits to zero when the iteration completes in bpf_iter_bits_next(). In addition, use \"!nr_bits || bits >= nr_bits\" to check whether the iteration is complete and still use \"nr_bits > 64\" to indicate whether bits are dynamically allocated. The \"!nr_bits\" check is necessary because bpf_iter_bits_new() may fail before setting kit->nr_bits, and this condition will stop the iteration early instead of accessing the zeroed or freed kit->bits. Considering the initial value of kit->bits is -1 and the type of kit->nr_bits is unsigned int, change the type of kit->nr_bits to int. The potential overflow problem will be handled in the following patch.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50255", "url": "https://ubuntu.com/security/CVE-2024-50255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci: fix null-ptr-deref in hci_read_supported_codecs Fix __hci_cmd_sync_sk() to return not NULL for unknown opcodes. __hci_cmd_sync_sk() returns NULL if a command returns a status event. However, it also returns NULL where an opcode doesn't exist in the hci_cc table because hci_cmd_complete_evt() assumes status = skb->data[0] for unknown opcodes. This leads to null-ptr-deref in cmd_sync for HCI_OP_READ_LOCAL_CODECS as there is no hci_cc for HCI_OP_READ_LOCAL_CODECS, which always assumes status = skb->data[0]. KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077] CPU: 1 PID: 2000 Comm: kworker/u9:5 Not tainted 6.9.0-ga6bcb805883c-dirty #10 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: hci7 hci_power_on RIP: 0010:hci_read_supported_codecs+0xb9/0x870 net/bluetooth/hci_codec.c:138 Code: 08 48 89 ef e8 b8 c1 8f fd 48 8b 75 00 e9 96 00 00 00 49 89 c6 48 ba 00 00 00 00 00 fc ff df 4c 8d 60 70 4c 89 e3 48 c1 eb 03 <0f> b6 04 13 84 c0 0f 85 82 06 00 00 41 83 3c 24 02 77 0a e8 bf 78 RSP: 0018:ffff888120bafac8 EFLAGS: 00010212 RAX: 0000000000000000 RBX: 000000000000000e RCX: ffff8881173f0040 RDX: dffffc0000000000 RSI: ffffffffa58496c0 RDI: ffff88810b9ad1e4 RBP: ffff88810b9ac000 R08: ffffffffa77882a7 R09: 1ffffffff4ef1054 R10: dffffc0000000000 R11: fffffbfff4ef1055 R12: 0000000000000070 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88810b9ac000 FS: 0000000000000000(0000) GS:ffff8881f6c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6ddaa3439e CR3: 0000000139764003 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: hci_read_local_codecs_sync net/bluetooth/hci_sync.c:4546 [inline] hci_init_stage_sync net/bluetooth/hci_sync.c:3441 [inline] hci_init4_sync net/bluetooth/hci_sync.c:4706 [inline] hci_init_sync net/bluetooth/hci_sync.c:4742 [inline] hci_dev_init_sync net/bluetooth/hci_sync.c:4912 [inline] hci_dev_open_sync+0x19a9/0x2d30 net/bluetooth/hci_sync.c:4994 hci_dev_do_open net/bluetooth/hci_core.c:483 [inline] hci_power_on+0x11e/0x560 net/bluetooth/hci_core.c:1015 process_one_work kernel/workqueue.c:3267 [inline] process_scheduled_works+0x8ef/0x14f0 kernel/workqueue.c:3348 worker_thread+0x91f/0xe50 kernel/workqueue.c:3429 kthread+0x2cb/0x360 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50256", "url": "https://ubuntu.com/security/CVE-2024-50256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6() I got a syzbot report without a repro [1] crashing in nf_send_reset6() I think the issue is that dev->hard_header_len is zero, and we attempt later to push an Ethernet header. Use LL_MAX_HEADER, as other functions in net/ipv6/netfilter/nf_reject_ipv6.c. [1] skbuff: skb_under_panic: text:ffffffff89b1d008 len:74 put:14 head:ffff88803123aa00 data:ffff88803123a9f2 tail:0x3c end:0x140 dev:syz_tun kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 UID: 0 PID: 7373 Comm: syz.1.568 Not tainted 6.12.0-rc2-syzkaller-00631-g6d858708d465 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:skb_panic net/core/skbuff.c:206 [inline] RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216 Code: 0d 8d 48 c7 c6 60 a6 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 ba 30 38 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP: 0018:ffffc900045269b0 EFLAGS: 00010282 RAX: 0000000000000088 RBX: dffffc0000000000 RCX: cd66dacdc5d8e800 RDX: 0000000000000000 RSI: 0000000000000200 RDI: 0000000000000000 RBP: ffff88802d39a3d0 R08: ffffffff8174afec R09: 1ffff920008a4ccc R10: dffffc0000000000 R11: fffff520008a4ccd R12: 0000000000000140 R13: ffff88803123aa00 R14: ffff88803123a9f2 R15: 000000000000003c FS: 00007fdbee5ff6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000005d322000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: skb_push+0xe5/0x100 net/core/skbuff.c:2636 eth_header+0x38/0x1f0 net/ethernet/eth.c:83 dev_hard_header include/linux/netdevice.h:3208 [inline] nf_send_reset6+0xce6/0x1270 net/ipv6/netfilter/nf_reject_ipv6.c:358 nft_reject_inet_eval+0x3b9/0x690 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x418/0x6b0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] br_nf_pre_routing_ipv6+0x63e/0x770 net/bridge/br_netfilter_ipv6.c:184 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_bridge_pre net/bridge/br_input.c:277 [inline] br_handle_frame+0x9fd/0x1530 net/bridge/br_input.c:424 __netif_receive_skb_core+0x13e8/0x4570 net/core/dev.c:5562 __netif_receive_skb_one_core net/core/dev.c:5666 [inline] __netif_receive_skb+0x12f/0x650 net/core/dev.c:5781 netif_receive_skb_internal net/core/dev.c:5867 [inline] netif_receive_skb+0x1e8/0x890 net/core/dev.c:5926 tun_rx_batched+0x1b7/0x8f0 drivers/net/tun.c:1550 tun_get_user+0x3056/0x47e0 drivers/net/tun.c:2007 tun_chr_write_iter+0x10d/0x1f0 drivers/net/tun.c:2053 new_sync_write fs/read_write.c:590 [inline] vfs_write+0xa6d/0xc90 fs/read_write.c:683 ksys_write+0x183/0x2b0 fs/read_write.c:736 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:0x7fdbeeb7d1ff Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 c9 8d 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 1c 8e 02 00 48 RSP: 002b:00007fdbee5ff000 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fdbeed36058 RCX: 00007fdbeeb7d1ff RDX: 000000000000008e RSI: 0000000020000040 RDI: 00000000000000c8 RBP: 00007fdbeebf12be R08: 0000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50257", "url": "https://ubuntu.com/security/CVE-2024-50257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: Fix use-after-free in get_info() ip6table_nat module unload has refcnt warning for UAF. call trace is: WARNING: CPU: 1 PID: 379 at kernel/module/main.c:853 module_put+0x6f/0x80 Modules linked in: ip6table_nat(-) CPU: 1 UID: 0 PID: 379 Comm: ip6tables Not tainted 6.12.0-rc4-00047-gc2ee9f594da8-dirty #205 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:module_put+0x6f/0x80 Call Trace: get_info+0x128/0x180 do_ip6t_get_ctl+0x6a/0x430 nf_getsockopt+0x46/0x80 ipv6_getsockopt+0xb9/0x100 rawv6_getsockopt+0x42/0x190 do_sock_getsockopt+0xaa/0x180 __sys_getsockopt+0x70/0xc0 __x64_sys_getsockopt+0x20/0x30 do_syscall_64+0xa2/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Concurrent execution of module unload and get_info() trigered the warning. The root cause is as follows: cpu0\t\t\t\t cpu1 module_exit //mod->state = MODULE_STATE_GOING ip6table_nat_exit xt_unregister_template \tkfree(t) \t//removed from templ_list \t\t\t\t getinfo() \t\t\t\t\t t = xt_find_table_lock \t\t\t\t\t\tlist_for_each_entry(tmpl, &xt_templates[af]...) \t\t\t\t\t\t\tif (strcmp(tmpl->name, name)) \t\t\t\t\t\t\t\tcontinue; //table not found \t\t\t\t\t\t\ttry_module_get \t\t\t\t\t\tlist_for_each_entry(t, &xt_net->tables[af]...) \t\t\t\t\t\t\treturn t; //not get refcnt \t\t\t\t\t module_put(t->me) //uaf unregister_pernet_subsys //remove table from xt_net list While xt_table module was going away and has been removed from xt_templates list, we couldnt get refcnt of xt_table->me. Check module in xt_net->tables list re-traversal to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50258", "url": "https://ubuntu.com/security/CVE-2024-50258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix crash when config small gso_max_size/gso_ipv4_max_size Config a small gso_max_size/gso_ipv4_max_size will lead to an underflow in sk_dst_gso_max_size(), which may trigger a BUG_ON crash, because sk->sk_gso_max_size would be much bigger than device limits. Call Trace: tcp_write_xmit tso_segs = tcp_init_tso_segs(skb, mss_now); tcp_set_skb_tso_segs tcp_skb_pcount_set // skb->len = 524288, mss_now = 8 // u16 tso_segs = 524288/8 = 65535 -> 0 tso_segs = DIV_ROUND_UP(skb->len, mss_now) BUG_ON(!tso_segs) Add check for the minimum value of gso_max_size and gso_ipv4_max_size.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50262", "url": "https://ubuntu.com/security/CVE-2024-50262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix out-of-bounds write in trie_get_next_key() trie_get_next_key() allocates a node stack with size trie->max_prefixlen, while it writes (trie->max_prefixlen + 1) nodes to the stack when it has full paths from the root to leaves. For example, consider a trie with max_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ... 0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with .prefixlen = 8 make 9 nodes be written on the node stack with size 8.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53044", "url": "https://ubuntu.com/security/CVE-2024-53044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_api: fix xa_insert() error path in tcf_block_get_ext() This command: $ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact Error: block dev insert failed: -EBUSY. fails because user space requests the same block index to be set for both ingress and egress. [ side note, I don't think it even failed prior to commit 913b47d3424e (\"net/sched: Introduce tc block netdev tracking infra\"), because this is a command from an old set of notes of mine which used to work, but alas, I did not scientifically bisect this ] The problem is not that it fails, but rather, that the second time around, it fails differently (and irrecoverably): $ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact Error: dsa_core: Flow block cb is busy. [ another note: the extack is added by me for illustration purposes. the context of the problem is that clsact_init() obtains the same &q->ingress_block pointer as &q->egress_block, and since we call tcf_block_get_ext() on both of them, \"dev\" will be added to the block->ports xarray twice, thus failing the operation: once through the ingress block pointer, and once again through the egress block pointer. the problem itself is that when xa_insert() fails, we have emitted a FLOW_BLOCK_BIND command through ndo_setup_tc(), but the offload never sees a corresponding FLOW_BLOCK_UNBIND. ] Even correcting the bad user input, we still cannot recover: $ tc qdisc replace dev swp3 ingress_block 1 egress_block 2 clsact Error: dsa_core: Flow block cb is busy. Basically the only way to recover is to reboot the system, or unbind and rebind the net device driver. To fix the bug, we need to fill the correct error teardown path which was missed during code movement, and call tcf_block_offload_unbind() when xa_insert() fails. [ last note, fundamentally I blame the label naming convention in tcf_block_get_ext() for the bug. The labels should be named after what they do, not after the error path that jumps to them. This way, it is obviously wrong that two labels pointing to the same code mean something is wrong, and checking the code correctness at the goto site is also easier ]", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50259", "url": "https://ubuntu.com/security/CVE-2024-50259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netdevsim: Add trailing zero to terminate the string in nsim_nexthop_bucket_activity_write() This was found by a static analyzer. We should not forget the trailing zero after copy_from_user() if we will further do some string operations, sscanf() in this case. Adding a trailing zero will ensure that the function performs properly.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50304", "url": "https://ubuntu.com/security/CVE-2024-50304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find() The per-netns IP tunnel hash table is protected by the RTNL mutex and ip_tunnel_find() is only called from the control path where the mutex is taken. Add a lockdep expression to hlist_for_each_entry_rcu() in ip_tunnel_find() in order to validate that the mutex is held and to silence the suspicious RCU usage warning [1]. [1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gd95d9a31aceb #139 Not tainted ----------------------------- net/ipv4/ip_tunnel.c:221 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/362: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60 stack backtrace: CPU: 12 UID: 0 PID: 362 Comm: ip Not tainted 6.12.0-rc3-custom-gd95d9a31aceb #139 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 ip_tunnel_find+0x435/0x4d0 ip_tunnel_newlink+0x517/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53042", "url": "https://ubuntu.com/security/CVE-2024-53042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_init_flow() There are code paths from which the function is called without holding the RCU read lock, resulting in a suspicious RCU usage warning [1]. Fix by using l3mdev_master_upper_ifindex_by_index() which will acquire the RCU read lock before calling l3mdev_master_upper_ifindex_by_index_rcu(). [1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gac8f72681cf2 #141 Not tainted ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/361: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60 stack backtrace: CPU: 3 UID: 0 PID: 361 Comm: ip Not tainted 6.12.0-rc3-custom-gac8f72681cf2 #141 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 dev_get_by_index_rcu+0x1d3/0x210 l3mdev_master_upper_ifindex_by_index_rcu+0x2b/0xf0 ip_tunnel_bind_dev+0x72f/0xa00 ip_tunnel_newlink+0x368/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53048", "url": "https://ubuntu.com/security/CVE-2024-53048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix crash on probe for DPLL enabled E810 LOM The E810 Lan On Motherboard (LOM) design is vendor specific. Intel provides the reference design, but it is up to vendor on the final product design. For some cases, like Linux DPLL support, the static values defined in the driver does not reflect the actual LOM design. Current implementation of dpll pins is causing the crash on probe of the ice driver for such DPLL enabled E810 LOM designs: WARNING: (...) at drivers/dpll/dpll_core.c:495 dpll_pin_get+0x2c4/0x330 ... Call Trace: ? __warn+0x83/0x130 ? dpll_pin_get+0x2c4/0x330 ? report_bug+0x1b7/0x1d0 ? handle_bug+0x42/0x70 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? dpll_pin_get+0x117/0x330 ? dpll_pin_get+0x2c4/0x330 ? dpll_pin_get+0x117/0x330 ice_dpll_get_pins.isra.0+0x52/0xe0 [ice] ... The number of dpll pins enabled by LOM vendor is greater than expected and defined in the driver for Intel designed NICs, which causes the crash. Prevent the crash and allow generic pin initialization within Linux DPLL subsystem for DPLL enabled E810 LOM designs. Newly designed solution for described issue will be based on \"per HW design\" pin initialization. It requires pin information dynamically acquired from the firmware and is already in progress, planned for next-tree only.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53058", "url": "https://ubuntu.com/security/CVE-2024-53058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data In case the non-paged data of a SKB carries protocol header and protocol payload to be transmitted on a certain platform that the DMA AXI address width is configured to 40-bit/48-bit, or the size of the non-paged data is bigger than TSO_MAX_BUFF_SIZE on a certain platform that the DMA AXI address width is configured to 32-bit, then this SKB requires at least two DMA transmit descriptors to serve it. For example, three descriptors are allocated to split one DMA buffer mapped from one piece of non-paged data: dma_desc[N + 0], dma_desc[N + 1], dma_desc[N + 2]. Then three elements of tx_q->tx_skbuff_dma[] will be allocated to hold extra information to be reused in stmmac_tx_clean(): tx_q->tx_skbuff_dma[N + 0], tx_q->tx_skbuff_dma[N + 1], tx_q->tx_skbuff_dma[N + 2]. Now we focus on tx_q->tx_skbuff_dma[entry].buf, which is the DMA buffer address returned by DMA mapping call. stmmac_tx_clean() will try to unmap the DMA buffer _ONLY_IF_ tx_q->tx_skbuff_dma[entry].buf is a valid buffer address. The expected behavior that saves DMA buffer address of this non-paged data to tx_q->tx_skbuff_dma[entry].buf is: tx_q->tx_skbuff_dma[N + 0].buf = NULL; tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = dma_map_single(); Unfortunately, the current code misbehaves like this: tx_q->tx_skbuff_dma[N + 0].buf = dma_map_single(); tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = NULL; On the stmmac_tx_clean() side, when dma_desc[N + 0] is closed by the DMA engine, tx_q->tx_skbuff_dma[N + 0].buf is a valid buffer address obviously, then the DMA buffer will be unmapped immediately. There may be a rare case that the DMA engine does not finish the pending dma_desc[N + 1], dma_desc[N + 2] yet. Now things will go horribly wrong, DMA is going to access a unmapped/unreferenced memory region, corrupted data will be transmited or iommu fault will be triggered :( In contrast, the for-loop that maps SKB fragments behaves perfectly as expected, and that is how the driver should do for both non-paged data and paged frags actually. This patch corrects DMA map/unmap sequences by fixing the array index for tx_q->tx_skbuff_dma[entry].buf when assigning DMA buffer address. Tested and verified on DWXGMAC CORE 3.20a", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50260", "url": "https://ubuntu.com/security/CVE-2024-50260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sock_map: fix a NULL pointer dereference in sock_map_link_update_prog() The following race condition could trigger a NULL pointer dereference: sock_map_link_detach():\t\tsock_map_link_update_prog(): mutex_lock(&sockmap_mutex); ... sockmap_link->map = NULL; mutex_unlock(&sockmap_mutex); \t\t\t\t mutex_lock(&sockmap_mutex); \t\t\t\t ... \t\t\t\t sock_map_prog_link_lookup(sockmap_link->map); \t\t\t\t mutex_unlock(&sockmap_mutex); Fix it by adding a NULL pointer check. In this specific case, it makes no sense to update a link which is being released.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53045", "url": "https://ubuntu.com/security/CVE-2024-53045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: dapm: fix bounds checker error in dapm_widget_list_create The widgets array in the snd_soc_dapm_widget_list has a __counted_by attribute attached to it, which points to the num_widgets variable. This attribute is used in bounds checking, and if it is not set before the array is filled, then the bounds sanitizer will issue a warning or a kernel panic if CONFIG_UBSAN_TRAP is set. This patch sets the size of the widgets list calculated with list_for_each as the initial value for num_widgets as it is used for allocating memory for the array. It is updated with the actual number of added elements after the array is filled.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50261", "url": "https://ubuntu.com/security/CVE-2024-50261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macsec: Fix use-after-free while sending the offloading packet KASAN reports the following UAF. The metadata_dst, which is used to store the SCI value for macsec offload, is already freed by metadata_dst_free() in macsec_free_netdev(), while driver still use it for sending the packet. To fix this issue, dst_release() is used instead to release metadata_dst. So it is not freed instantly in macsec_free_netdev() if still referenced by skb. BUG: KASAN: slab-use-after-free in mlx5e_xmit+0x1e8f/0x4190 [mlx5_core] Read of size 2 at addr ffff88813e42e038 by task kworker/7:2/714 [...] Workqueue: mld mld_ifc_work Call Trace: dump_stack_lvl+0x51/0x60 print_report+0xc1/0x600 kasan_report+0xab/0xe0 mlx5e_xmit+0x1e8f/0x4190 [mlx5_core] dev_hard_start_xmit+0x120/0x530 sch_direct_xmit+0x149/0x11e0 __qdisc_run+0x3ad/0x1730 __dev_queue_xmit+0x1196/0x2ed0 vlan_dev_hard_start_xmit+0x32e/0x510 [8021q] dev_hard_start_xmit+0x120/0x530 __dev_queue_xmit+0x14a7/0x2ed0 macsec_start_xmit+0x13e9/0x2340 dev_hard_start_xmit+0x120/0x530 __dev_queue_xmit+0x14a7/0x2ed0 ip6_finish_output2+0x923/0x1a70 ip6_finish_output+0x2d7/0x970 ip6_output+0x1ce/0x3a0 NF_HOOK.constprop.0+0x15f/0x190 mld_sendpack+0x59a/0xbd0 mld_ifc_work+0x48a/0xa80 process_one_work+0x5aa/0xe50 worker_thread+0x79c/0x1290 kthread+0x28f/0x350 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x11/0x20 Allocated by task 3922: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 __kasan_kmalloc+0x77/0x90 __kmalloc_noprof+0x188/0x400 metadata_dst_alloc+0x1f/0x4e0 macsec_newlink+0x914/0x1410 __rtnl_newlink+0xe08/0x15b0 rtnl_newlink+0x5f/0x90 rtnetlink_rcv_msg+0x667/0xa80 netlink_rcv_skb+0x12c/0x360 netlink_unicast+0x551/0x770 netlink_sendmsg+0x72d/0xbd0 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x52e/0x6a0 ___sys_sendmsg+0xeb/0x170 __sys_sendmsg+0xb5/0x140 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Freed by task 4011: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x50 poison_slab_object+0x10c/0x190 __kasan_slab_free+0x11/0x30 kfree+0xe0/0x290 macsec_free_netdev+0x3f/0x140 netdev_run_todo+0x450/0xc70 rtnetlink_rcv_msg+0x66f/0xa80 netlink_rcv_skb+0x12c/0x360 netlink_unicast+0x551/0x770 netlink_sendmsg+0x72d/0xbd0 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x52e/0x6a0 ___sys_sendmsg+0xeb/0x170 __sys_sendmsg+0xb5/0x140 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53059", "url": "https://ubuntu.com/security/CVE-2024-53059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd() 1. The size of the response packet is not validated. 2. The response buffer is not freed. Resolve these issues by switching to iwl_mvm_send_cmd_status(), which handles both size validation and frees the buffer.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53074", "url": "https://ubuntu.com/security/CVE-2024-53074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: don't leak a link on AP removal Release the link mapping resource in AP removal. This impacted devices that do not support the MLD API (9260 and down). On those devices, we couldn't start the AP again after the AP has been already started and stopped.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53049", "url": "https://ubuntu.com/security/CVE-2024-53049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slub/kunit: fix a WARNING due to unwrapped __kmalloc_cache_noprof 'modprobe slub_kunit' will have a warning as shown below. The root cause is that __kmalloc_cache_noprof was directly used, which resulted in no alloc_tag being allocated. This caused current->alloc_tag to be null, leading to a warning in alloc_tag_add_check. Let's add an alloc_hook layer to __kmalloc_cache_noprof specifically within lib/slub_kunit.c, which is the only user of this internal slub function outside kmalloc implementation itself. [58162.947016] WARNING: CPU: 2 PID: 6210 at ./include/linux/alloc_tag.h:125 alloc_tagging_slab_alloc_hook+0x268/0x27c [58162.957721] Call trace: [58162.957919] alloc_tagging_slab_alloc_hook+0x268/0x27c [58162.958286] __kmalloc_cache_noprof+0x14c/0x344 [58162.958615] test_kmalloc_redzone_access+0x50/0x10c [slub_kunit] [58162.959045] kunit_try_run_case+0x74/0x184 [kunit] [58162.959401] kunit_generic_run_threadfn_adapter+0x2c/0x4c [kunit] [58162.959841] kthread+0x10c/0x118 [58162.960093] ret_from_fork+0x10/0x20 [58162.960363] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50192", "url": "https://ubuntu.com/security/CVE-2024-50192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v4: Don't allow a VMOVP on a dying VPE Kunkun Jiang reported that there is a small window of opportunity for userspace to force a change of affinity for a VPE while the VPE has already been unmapped, but the corresponding doorbell interrupt still visible in /proc/irq/. Plug the race by checking the value of vmapp_count, which tracks whether the VPE is mapped ot not, and returning an error in this case. This involves making vmapp_count common to both GICv4.1 and its v4.0 ancestor.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50069", "url": "https://ubuntu.com/security/CVE-2024-50069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: apple: check devm_kasprintf() returned value devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked. Fix this lack and check the returned value. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50070", "url": "https://ubuntu.com/security/CVE-2024-50070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: stm32: check devm_kasprintf() returned value devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked. Fix this lack and check the returned value. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50196", "url": "https://ubuntu.com/security/CVE-2024-50196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: ocelot: fix system hang on level based interrupts The current implementation only calls chained_irq_enter() and chained_irq_exit() if it detects pending interrupts. ``` for (i = 0; i < info->stride; i++) { \turegmap_read(info->map, id_reg + 4 * i, ®); \tif (!reg) \t\tcontinue; \tchained_irq_enter(parent_chip, desc); ``` However, in case of GPIO pin configured in level mode and the parent controller configured in edge mode, GPIO interrupt might be lowered by the hardware. In the result, if the interrupt is short enough, the parent interrupt is still pending while the GPIO interrupt is cleared; chained_irq_enter() never gets called and the system hangs trying to service the parent interrupt. Moving chained_irq_enter() and chained_irq_exit() outside the for loop ensures that they are called even when GPIO interrupt is lowered by the hardware. The similar code with chained_irq_enter() / chained_irq_exit() functions wrapping interrupt checking loop may be found in many other drivers: ``` grep -r -A 10 chained_irq_enter drivers/pinctrl ```", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50197", "url": "https://ubuntu.com/security/CVE-2024-50197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: intel: platform: fix error path in device_for_each_child_node() The device_for_each_child_node() loop requires calls to fwnode_handle_put() upon early returns to decrement the refcount of the child node and avoid leaking memory if that error path is triggered. There is one early returns within that loop in intel_platform_pinctrl_prepare_community(), but fwnode_handle_put() is missing. Instead of adding the missing call, the scoped version of the loop can be used to simplify the code and avoid mistakes in the future if new early returns are added, as the child node is only used for parsing, and it is never assigned.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50071", "url": "https://ubuntu.com/security/CVE-2024-50071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: nuvoton: fix a double free in ma35_pinctrl_dt_node_to_map_func() 'new_map' is allocated using devm_* which takes care of freeing the allocated data on device removal, call to \t.dt_free_map = pinconf_generic_dt_free_map double frees the map as pinconf_generic_dt_free_map() calls pinctrl_utils_free_map(). Fix this by using kcalloc() instead of auto-managed devm_kcalloc().", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50072", "url": "https://ubuntu.com/security/CVE-2024-50072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/bugs: Use code segment selector for VERW operand Robert Gill reported below #GP in 32-bit mode when dosemu software was executing vm86() system call: general protection fault: 0000 [#1] PREEMPT SMP CPU: 4 PID: 4610 Comm: dosemu.bin Not tainted 6.6.21-gentoo-x86 #1 Hardware name: Dell Inc. PowerEdge 1950/0H723K, BIOS 2.7.0 10/30/2010 EIP: restore_all_switch_stack+0xbe/0xcf EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000 ESI: 00000000 EDI: 00000000 EBP: 00000000 ESP: ff8affdc DS: 0000 ES: 0000 FS: 0000 GS: 0033 SS: 0068 EFLAGS: 00010046 CR0: 80050033 CR2: 00c2101c CR3: 04b6d000 CR4: 000406d0 Call Trace: show_regs+0x70/0x78 die_addr+0x29/0x70 exc_general_protection+0x13c/0x348 exc_bounds+0x98/0x98 handle_exception+0x14d/0x14d exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf This only happens in 32-bit mode when VERW based mitigations like MDS/RFDS are enabled. This is because segment registers with an arbitrary user value can result in #GP when executing VERW. Intel SDM vol. 2C documents the following behavior for VERW instruction: #GP(0) - If a memory operand effective address is outside the CS, DS, ES, \t FS, or GS segment limit. CLEAR_CPU_BUFFERS macro executes VERW instruction before returning to user space. Use %cs selector to reference VERW operand. This ensures VERW will not #GP for an arbitrary user %ds. [ mingo: Fixed the SOB chain. ]", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50073", "url": "https://ubuntu.com/security/CVE-2024-50073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: Fix use-after-free in gsm_cleanup_mux BUG: KASAN: slab-use-after-free in gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] Read of size 8 at addr ffff88815fe99c00 by task poc/3379 CPU: 0 UID: 0 PID: 3379 Comm: poc Not tainted 6.11.0+ #56 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] __pfx_gsm_cleanup_mux+0x10/0x10 drivers/tty/n_gsm.c:3124 [n_gsm] __pfx_sched_clock_cpu+0x10/0x10 kernel/sched/clock.c:389 update_load_avg+0x1c1/0x27b0 kernel/sched/fair.c:4500 __pfx_min_vruntime_cb_rotate+0x10/0x10 kernel/sched/fair.c:846 __rb_insert_augmented+0x492/0xbf0 lib/rbtree.c:161 gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] _raw_spin_lock_irqsave+0x92/0xf0 arch/x86/include/asm/atomic.h:107 __pfx_gsmld_ioctl+0x10/0x10 drivers/tty/n_gsm.c:3822 [n_gsm] ktime_get+0x5e/0x140 kernel/time/timekeeping.c:195 ldsem_down_read+0x94/0x4e0 arch/x86/include/asm/atomic64_64.h:79 __pfx_ldsem_down_read+0x10/0x10 drivers/tty/tty_ldsem.c:338 __pfx_do_vfs_ioctl+0x10/0x10 fs/ioctl.c:805 tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 Allocated by task 65: gsm_data_alloc.constprop.0+0x27/0x190 drivers/tty/n_gsm.c:926 [n_gsm] gsm_send+0x2c/0x580 drivers/tty/n_gsm.c:819 [n_gsm] gsm1_receive+0x547/0xad0 drivers/tty/n_gsm.c:3038 [n_gsm] gsmld_receive_buf+0x176/0x280 drivers/tty/n_gsm.c:3609 [n_gsm] tty_ldisc_receive_buf+0x101/0x1e0 drivers/tty/tty_buffer.c:391 tty_port_default_receive_buf+0x61/0xa0 drivers/tty/tty_port.c:39 flush_to_ldisc+0x1b0/0x750 drivers/tty/tty_buffer.c:445 process_scheduled_works+0x2b0/0x10d0 kernel/workqueue.c:3229 worker_thread+0x3dc/0x950 kernel/workqueue.c:3391 kthread+0x2a3/0x370 kernel/kthread.c:389 ret_from_fork+0x2d/0x70 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:257 Freed by task 3367: kfree+0x126/0x420 mm/slub.c:4580 gsm_cleanup_mux+0x36c/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 [Analysis] gsm_msg on the tx_ctrl_list or tx_data_list of gsm_mux can be freed by multi threads through ioctl,which leads to the occurrence of uaf. Protect it by gsm tx lock.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50193", "url": "https://ubuntu.com/security/CVE-2024-50193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/entry_32: Clear CPU buffers after register restore in NMI return CPU buffers are currently cleared after call to exc_nmi, but before register state is restored. This may be okay for MDS mitigation but not for RDFS. Because RDFS mitigation requires CPU buffers to be cleared when registers don't have any sensitive data. Move CLEAR_CPU_BUFFERS after RESTORE_ALL_NMI.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50074", "url": "https://ubuntu.com/security/CVE-2024-50074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: parport: Proper fix for array out-of-bounds access The recent fix for array out-of-bounds accesses replaced sprintf() calls blindly with snprintf(). However, since snprintf() returns the would-be-printed size, not the actually output size, the length calculation can still go over the given limit. Use scnprintf() instead of snprintf(), which returns the actually output letters, for addressing the potential out-of-bounds access properly.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50100", "url": "https://ubuntu.com/security/CVE-2024-50100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: gadget: dummy-hcd: Fix \"task hung\" problem The syzbot fuzzer has been encountering \"task hung\" problems ever since the dummy-hcd driver was changed to use hrtimers instead of regular timers. It turns out that the problems are caused by a subtle difference between the timer_pending() and hrtimer_active() APIs. The changeover blindly replaced the first by the second. However, timer_pending() returns True when the timer is queued but not when its callback is running, whereas hrtimer_active() returns True when the hrtimer is queued _or_ its callback is running. This difference occasionally caused dummy_urb_enqueue() to think that the callback routine had not yet started when in fact it was almost finished. As a result the hrtimer was not restarted, which made it impossible for the driver to dequeue later the URB that was just enqueued. This caused usb_kill_urb() to hang, and things got worse from there. Since hrtimers have no API for telling when they are queued and the callback isn't running, the driver must keep track of this for itself. That's what this patch does, adding a new \"timer_pending\" flag and setting or clearing it at the appropriate times.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50075", "url": "https://ubuntu.com/security/CVE-2024-50075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xhci: tegra: fix checked USB2 port number If USB virtualizatoin is enabled, USB2 ports are shared between all Virtual Functions. The USB2 port number owned by an USB2 root hub in a Virtual Function may be less than total USB2 phy number supported by the Tegra XUSB controller. Using total USB2 phy number as port number to check all PORTSC values would cause invalid memory access. [ 116.923438] Unable to handle kernel paging request at virtual address 006c622f7665642f ... [ 117.213640] Call trace: [ 117.216783] tegra_xusb_enter_elpg+0x23c/0x658 [ 117.222021] tegra_xusb_runtime_suspend+0x40/0x68 [ 117.227260] pm_generic_runtime_suspend+0x30/0x50 [ 117.232847] __rpm_callback+0x84/0x3c0 [ 117.237038] rpm_suspend+0x2dc/0x740 [ 117.241229] pm_runtime_work+0xa0/0xb8 [ 117.245769] process_scheduled_works+0x24c/0x478 [ 117.251007] worker_thread+0x23c/0x328 [ 117.255547] kthread+0x104/0x1b0 [ 117.259389] ret_from_fork+0x10/0x20 [ 117.263582] Code: 54000222 f9461ae8 f8747908 b4ffff48 (f9400100)", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50076", "url": "https://ubuntu.com/security/CVE-2024-50076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vt: prevent kernel-infoleak in con_font_get() font.data may not initialize all memory spaces depending on the implementation of vc->vc_sw->con_font_get. This may cause info-leak, so to prevent this, it is safest to modify it to initialize the allocated memory space to 0, and it generally does not affect the overall performance of the system.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50077", "url": "https://ubuntu.com/security/CVE-2024-50077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix multiple init when debugfs is disabled If bt_debugfs is not created successfully, which happens if either CONFIG_DEBUG_FS or CONFIG_DEBUG_FS_ALLOW_ALL is unset, then iso_init() returns early and does not set iso_inited to true. This means that a subsequent call to iso_init() will result in duplicate calls to proto_register(), bt_sock_register(), etc. With CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, the duplicate call to proto_register() triggers this BUG(): list_add double add: new=ffffffffc0b280d0, prev=ffffffffbab56250, next=ffffffffc0b280d0. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:35! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 2 PID: 887 Comm: bluetoothd Not tainted 6.10.11-1-ao-desktop #1 RIP: 0010:__list_add_valid_or_report+0x9a/0xa0 ... __list_add_valid_or_report+0x9a/0xa0 proto_register+0x2b5/0x340 iso_init+0x23/0x150 [bluetooth] set_iso_socket_func+0x68/0x1b0 [bluetooth] kmem_cache_free+0x308/0x330 hci_sock_sendmsg+0x990/0x9e0 [bluetooth] __sock_sendmsg+0x7b/0x80 sock_write_iter+0x9a/0x110 do_iter_readv_writev+0x11d/0x220 vfs_writev+0x180/0x3e0 do_writev+0xca/0x100 ... This change removes the early return. The check for iso_debugfs being NULL was unnecessary, it is always NULL when iso_inited is false.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50078", "url": "https://ubuntu.com/security/CVE-2024-50078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Call iso_exit() on module unload If iso_init() has been called, iso_exit() must be called on module unload. Without that, the struct proto that iso_init() registered with proto_register() becomes invalid, which could cause unpredictable problems later. In my case, with CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, loading the module again usually triggers this BUG(): list_add corruption. next->prev should be prev (ffffffffb5355fd0), but was 0000000000000068. (next=ffffffffc0a010d0). ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:29! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 4159 Comm: modprobe Not tainted 6.10.11-4+bt2-ao-desktop #1 RIP: 0010:__list_add_valid_or_report+0x61/0xa0 ... __list_add_valid_or_report+0x61/0xa0 proto_register+0x299/0x320 hci_sock_init+0x16/0xc0 [bluetooth] bt_init+0x68/0xd0 [bluetooth] __pfx_bt_init+0x10/0x10 [bluetooth] do_one_initcall+0x80/0x2f0 do_init_module+0x8b/0x230 __do_sys_init_module+0x15f/0x190 do_syscall_64+0x68/0x110 ...", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50198", "url": "https://ubuntu.com/security/CVE-2024-50198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: veml6030: fix IIO device retrieval from embedded device The dev pointer that is received as an argument in the in_illuminance_period_available_show function references the device embedded in the IIO device, not in the i2c client. dev_to_iio_dev() must be used to accessthe right data. The current implementation leads to a segmentation fault on every attempt to read the attribute because indio_dev gets a NULL assignment. This bug has been present since the first appearance of the driver, apparently since the last version (V6) before getting applied. A constant attribute was used until then, and the last modifications might have not been tested again.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50201", "url": "https://ubuntu.com/security/CVE-2024-50201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: Fix encoder->possible_clones Include the encoder itself in its possible_clones bitmask. In the past nothing validated that drivers were populating possible_clones correctly, but that changed in commit 74d2aacbe840 (\"drm: Validate encoder->possible_clones\"). Looks like radeon never got the memo and is still not following the rules 100% correctly. This results in some warnings during driver initialization: Bogus possible_clones: [ENCODER:46:TV-46] possible_clones=0x4 (full encoder mask=0x7) WARNING: CPU: 0 PID: 170 at drivers/gpu/drm/drm_mode_config.c:615 drm_mode_config_validate+0x113/0x39c ... (cherry picked from commit 3b6e7d40649c0d75572039aff9d0911864c689db)", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50098", "url": "https://ubuntu.com/security/CVE-2024-50098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Set SDEV_OFFLINE when UFS is shut down There is a history of deadlock if reboot is performed at the beginning of booting. SDEV_QUIESCE was set for all LU's scsi_devices by UFS shutdown, and at that time the audio driver was waiting on blk_mq_submit_bio() holding a mutex_lock while reading the fw binary. After that, a deadlock issue occurred while audio driver shutdown was waiting for mutex_unlock of blk_mq_submit_bio(). To solve this, set SDEV_OFFLINE for all LUs except WLUN, so that any I/O that comes down after a UFS shutdown will return an error. [ 31.907781]I[0: swapper/0: 0] 1 130705007 1651079834 11289729804 0 D( 2) 3 ffffff882e208000 * init [device_shutdown] [ 31.907793]I[0: swapper/0: 0] Mutex: 0xffffff8849a2b8b0: owner[0xffffff882e28cb00 kworker/6:0 :49] [ 31.907806]I[0: swapper/0: 0] Call trace: [ 31.907810]I[0: swapper/0: 0] __switch_to+0x174/0x338 [ 31.907819]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc [ 31.907826]I[0: swapper/0: 0] schedule+0x7c/0xe8 [ 31.907834]I[0: swapper/0: 0] schedule_preempt_disabled+0x24/0x40 [ 31.907842]I[0: swapper/0: 0] __mutex_lock+0x408/0xdac [ 31.907849]I[0: swapper/0: 0] __mutex_lock_slowpath+0x14/0x24 [ 31.907858]I[0: swapper/0: 0] mutex_lock+0x40/0xec [ 31.907866]I[0: swapper/0: 0] device_shutdown+0x108/0x280 [ 31.907875]I[0: swapper/0: 0] kernel_restart+0x4c/0x11c [ 31.907883]I[0: swapper/0: 0] __arm64_sys_reboot+0x15c/0x280 [ 31.907890]I[0: swapper/0: 0] invoke_syscall+0x70/0x158 [ 31.907899]I[0: swapper/0: 0] el0_svc_common+0xb4/0xf4 [ 31.907909]I[0: swapper/0: 0] do_el0_svc+0x2c/0xb0 [ 31.907918]I[0: swapper/0: 0] el0_svc+0x34/0xe0 [ 31.907928]I[0: swapper/0: 0] el0t_64_sync_handler+0x68/0xb4 [ 31.907937]I[0: swapper/0: 0] el0t_64_sync+0x1a0/0x1a4 [ 31.908774]I[0: swapper/0: 0] 49 0 11960702 11236868007 0 D( 2) 6 ffffff882e28cb00 * kworker/6:0 [__bio_queue_enter] [ 31.908783]I[0: swapper/0: 0] Call trace: [ 31.908788]I[0: swapper/0: 0] __switch_to+0x174/0x338 [ 31.908796]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc [ 31.908803]I[0: swapper/0: 0] schedule+0x7c/0xe8 [ 31.908811]I[0: swapper/0: 0] __bio_queue_enter+0xb8/0x178 [ 31.908818]I[0: swapper/0: 0] blk_mq_submit_bio+0x194/0x67c [ 31.908827]I[0: swapper/0: 0] __submit_bio+0xb8/0x19c", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50079", "url": "https://ubuntu.com/security/CVE-2024-50079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/sqpoll: ensure task state is TASK_RUNNING when running task_work When the sqpoll is exiting and cancels pending work items, it may need to run task_work. If this happens from within io_uring_cancel_generic(), then it may be under waiting for the io_uring_task waitqueue. This results in the below splat from the scheduler, as the ring mutex may be attempted grabbed while in a TASK_INTERRUPTIBLE state. Ensure that the task state is set appropriately for that, just like what is done for the other cases in io_run_task_work(). do not call blocking ops when !TASK_RUNNING; state=1 set at [<0000000029387fd2>] prepare_to_wait+0x88/0x2fc WARNING: CPU: 6 PID: 59939 at kernel/sched/core.c:8561 __might_sleep+0xf4/0x140 Modules linked in: CPU: 6 UID: 0 PID: 59939 Comm: iou-sqp-59938 Not tainted 6.12.0-rc3-00113-g8d020023b155 #7456 Hardware name: linux,dummy-virt (DT) pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : __might_sleep+0xf4/0x140 lr : __might_sleep+0xf4/0x140 sp : ffff80008c5e7830 x29: ffff80008c5e7830 x28: ffff0000d93088c0 x27: ffff60001c2d7230 x26: dfff800000000000 x25: ffff0000e16b9180 x24: ffff80008c5e7a50 x23: 1ffff000118bcf4a x22: ffff0000e16b9180 x21: ffff0000e16b9180 x20: 000000000000011b x19: ffff80008310fac0 x18: 1ffff000118bcd90 x17: 30303c5b20746120 x16: 74657320313d6574 x15: 0720072007200720 x14: 0720072007200720 x13: 0720072007200720 x12: ffff600036c64f0b x11: 1fffe00036c64f0a x10: ffff600036c64f0a x9 : dfff800000000000 x8 : 00009fffc939b0f6 x7 : ffff0001b6327853 x6 : 0000000000000001 x5 : ffff0001b6327850 x4 : ffff600036c64f0b x3 : ffff8000803c35bc x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000e16b9180 Call trace: __might_sleep+0xf4/0x140 mutex_lock+0x84/0x124 io_handle_tw_list+0xf4/0x260 tctx_task_work_run+0x94/0x340 io_run_task_work+0x1ec/0x3c0 io_uring_cancel_generic+0x364/0x524 io_sq_thread+0x820/0x124c ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50080", "url": "https://ubuntu.com/security/CVE-2024-50080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: don't allow user copy for unprivileged device UBLK_F_USER_COPY requires userspace to call write() on ublk char device for filling request buffer, and unprivileged device can't be trusted. So don't allow user copy for unprivileged device.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50081", "url": "https://ubuntu.com/security/CVE-2024-50081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-mq: setup queue ->tag_set before initializing hctx Commit 7b815817aa58 (\"blk-mq: add helper for checking if one CPU is mapped to specified hctx\") needs to check queue mapping via tag set in hctx's cpuhp handler. However, q->tag_set may not be setup yet when the cpuhp handler is enabled, then kernel oops is triggered. Fix the issue by setup queue tag_set before initializing hctx.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50082", "url": "https://ubuntu.com/security/CVE-2024-50082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race We're seeing crashes from rq_qos_wake_function that look like this: BUG: unable to handle page fault for address: ffffafe180a40084 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 100000067 P4D 100000067 PUD 10027c067 PMD 10115d067 PTE 0 Oops: Oops: 0002 [#1] PREEMPT SMP PTI CPU: 17 UID: 0 PID: 0 Comm: swapper/17 Not tainted 6.12.0-rc3-00013-geca631b8fe80 #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:_raw_spin_lock_irqsave+0x1d/0x40 Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 9c 41 5c fa 65 ff 05 62 97 30 4c 31 c0 ba 01 00 00 00 0f b1 17 75 0a 4c 89 e0 41 5c c3 cc cc cc cc 89 c6 e8 2c 0b 00 RSP: 0018:ffffafe180580ca0 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffffafe180a3f7a8 RCX: 0000000000000011 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffffafe180a40084 RBP: 0000000000000000 R08: 00000000001e7240 R09: 0000000000000011 R10: 0000000000000028 R11: 0000000000000888 R12: 0000000000000002 R13: ffffafe180a40084 R14: 0000000000000000 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff9aaf1f280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffafe180a40084 CR3: 000000010e428002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: try_to_wake_up+0x5a/0x6a0 rq_qos_wake_function+0x71/0x80 __wake_up_common+0x75/0xa0 __wake_up+0x36/0x60 scale_up.part.0+0x50/0x110 wb_timer_fn+0x227/0x450 ... So rq_qos_wake_function() calls wake_up_process(data->task), which calls try_to_wake_up(), which faults in raw_spin_lock_irqsave(&p->pi_lock). p comes from data->task, and data comes from the waitqueue entry, which is stored on the waiter's stack in rq_qos_wait(). Analyzing the core dump with drgn, I found that the waiter had already woken up and moved on to a completely unrelated code path, clobbering what was previously data->task. Meanwhile, the waker was passing the clobbered garbage in data->task to wake_up_process(), leading to the crash. What's happening is that in between rq_qos_wake_function() deleting the waitqueue entry and calling wake_up_process(), rq_qos_wait() is finding that it already got a token and returning. The race looks like this: rq_qos_wait() rq_qos_wake_function() ============================================================== prepare_to_wait_exclusive() data->got_token = true; list_del_init(&curr->entry); if (data.got_token) break; finish_wait(&rqw->wait, &data.wq); ^- returns immediately because list_empty_careful(&wq_entry->entry) is true ... return, go do something else ... wake_up_process(data->task) (NO LONGER VALID!)-^ Normally, finish_wait() is supposed to synchronize against the waker. But, as noted above, it is returning immediately because the waitqueue entry has already been removed from the waitqueue. The bug is that rq_qos_wake_function() is accessing the waitqueue entry AFTER deleting it. Note that autoremove_wake_function() wakes the waiter and THEN deletes the waitqueue entry, which is the proper order. Fix it by swapping the order. We also need to use list_del_init_careful() to match the list_empty_careful() in finish_wait().", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50101", "url": "https://ubuntu.com/security/CVE-2024-50101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI devices Previously, the domain_context_clear() function incorrectly called pci_for_each_dma_alias() to set up context entries for non-PCI devices. This could lead to kernel hangs or other unexpected behavior. Add a check to only call pci_for_each_dma_alias() for PCI devices. For non-PCI devices, domain_context_clear_one() is called directly.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50083", "url": "https://ubuntu.com/security/CVE-2024-50083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix mptcp DSS corruption due to large pmtu xmit Syzkaller was able to trigger a DSS corruption: TCP: request_sock_subflow_v4: Possible SYN flooding on port [::]:20002. Sending cookies. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 5227 at net/mptcp/protocol.c:695 __mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695 Modules linked in: CPU: 0 UID: 0 PID: 5227 Comm: syz-executor350 Not tainted 6.11.0-syzkaller-08829-gaf9c191ac2a0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:__mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695 Code: 0f b6 dc 31 ff 89 de e8 b5 dd ea f5 89 d8 48 81 c4 50 01 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 98 da ea f5 90 <0f> 0b 90 e9 47 ff ff ff e8 8a da ea f5 90 0f 0b 90 e9 99 e0 ff ff RSP: 0018:ffffc90000006db8 EFLAGS: 00010246 RAX: ffffffff8ba9df18 RBX: 00000000000055f0 RCX: ffff888030023c00 RDX: 0000000000000100 RSI: 00000000000081e5 RDI: 00000000000055f0 RBP: 1ffff110062bf1ae R08: ffffffff8ba9cf12 R09: 1ffff110062bf1b8 R10: dffffc0000000000 R11: ffffed10062bf1b9 R12: 0000000000000000 R13: dffffc0000000000 R14: 00000000700cec61 R15: 00000000000081e5 FS: 000055556679c380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020287000 CR3: 0000000077892000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: move_skbs_to_msk net/mptcp/protocol.c:811 [inline] mptcp_data_ready+0x29c/0xa90 net/mptcp/protocol.c:854 subflow_data_ready+0x34a/0x920 net/mptcp/subflow.c:1490 tcp_data_queue+0x20fd/0x76c0 net/ipv4/tcp_input.c:5283 tcp_rcv_established+0xfba/0x2020 net/ipv4/tcp_input.c:6237 tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915 tcp_v4_rcv+0x2dc0/0x37f0 net/ipv4/tcp_ipv4.c:2350 ip_protocol_deliver_rcu+0x22e/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x341/0x5f0 net/ipv4/ip_input.c:233 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314 __netif_receive_skb_one_core net/core/dev.c:5662 [inline] __netif_receive_skb+0x2bf/0x650 net/core/dev.c:5775 process_backlog+0x662/0x15b0 net/core/dev.c:6107 __napi_poll+0xcb/0x490 net/core/dev.c:6771 napi_poll net/core/dev.c:6840 [inline] net_rx_action+0x89b/0x1240 net/core/dev.c:6962 handle_softirqs+0x2c5/0x980 kernel/softirq.c:554 do_softirq+0x11b/0x1e0 kernel/softirq.c:455 __local_bh_enable_ip+0x1bb/0x200 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0x1764/0x3e80 net/core/dev.c:4451 dev_queue_xmit include/linux/netdevice.h:3094 [inline] neigh_hh_output include/net/neighbour.h:526 [inline] neigh_output include/net/neighbour.h:540 [inline] ip_finish_output2+0xd41/0x1390 net/ipv4/ip_output.c:236 ip_local_out net/ipv4/ip_output.c:130 [inline] __ip_queue_xmit+0x118c/0x1b80 net/ipv4/ip_output.c:536 __tcp_transmit_skb+0x2544/0x3b30 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_mtu_probe net/ipv4/tcp_output.c:2547 [inline] tcp_write_xmit+0x641d/0x6bf0 net/ipv4/tcp_output.c:2752 __tcp_push_pending_frames+0x9b/0x360 net/ipv4/tcp_output.c:3015 tcp_push_pending_frames include/net/tcp.h:2107 [inline] tcp_data_snd_check net/ipv4/tcp_input.c:5714 [inline] tcp_rcv_established+0x1026/0x2020 net/ipv4/tcp_input.c:6239 tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915 sk_backlog_rcv include/net/sock.h:1113 [inline] __release_sock+0x214/0x350 net/core/sock.c:3072 release_sock+0x61/0x1f0 net/core/sock.c:3626 mptcp_push_ ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50068", "url": "https://ubuntu.com/security/CVE-2024-50068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/tests/sysfs-kunit.h: fix memory leak in damon_sysfs_test_add_targets() The sysfs_target->regions allocated in damon_sysfs_regions_alloc() is not freed in damon_sysfs_test_add_targets(), which cause the following memory leak, free it to fix it. \tunreferenced object 0xffffff80c2a8db80 (size 96): \t comm \"kunit_try_catch\", pid 187, jiffies 4294894363 \t hex dump (first 32 bytes): \t 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ \t 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ \t backtrace (crc 0): \t [<0000000001e3714d>] kmemleak_alloc+0x34/0x40 \t [<000000008e6835c1>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000001286d9f8>] damon_sysfs_test_add_targets+0x1cc/0x738 \t [<0000000032ef8f77>] kunit_try_run_case+0x13c/0x3ac \t [<00000000f3edea23>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000adf936cf>] kthread+0x2e8/0x374 \t [<0000000041bb1628>] ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50199", "url": "https://ubuntu.com/security/CVE-2024-50199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/swapfile: skip HugeTLB pages for unuse_vma I got a bad pud error and lost a 1GB HugeTLB when calling swapoff. The problem can be reproduced by the following steps: 1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory. 2. Swapout the above anonymous memory. 3. run swapoff and we will get a bad pud error in kernel message: mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7) We can tell that pud_clear_bad is called by pud_none_or_clear_bad in unuse_pud_range() by ftrace. And therefore the HugeTLB pages will never be freed because we lost it from page table. We can skip HugeTLB pages for unuse_vma to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50066", "url": "https://ubuntu.com/security/CVE-2024-50066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mremap: fix move_normal_pmd/retract_page_tables race In mremap(), move_page_tables() looks at the type of the PMD entry and the specified address range to figure out by which method the next chunk of page table entries should be moved. At that point, the mmap_lock is held in write mode, but no rmap locks are held yet. For PMD entries that point to page tables and are fully covered by the source address range, move_pgt_entry(NORMAL_PMD, ...) is called, which first takes rmap locks, then does move_normal_pmd(). move_normal_pmd() takes the necessary page table locks at source and destination, then moves an entire page table from the source to the destination. The problem is: The rmap locks, which protect against concurrent page table removal by retract_page_tables() in the THP code, are only taken after the PMD entry has been read and it has been decided how to move it. So we can race as follows (with two processes that have mappings of the same tmpfs file that is stored on a tmpfs mount with huge=advise); note that process A accesses page tables through the MM while process B does it through the file rmap: process A process B ========= ========= mremap mremap_to move_vma move_page_tables get_old_pmd alloc_new_pmd *** PREEMPT *** madvise(MADV_COLLAPSE) do_madvise madvise_walk_vmas madvise_vma_behavior madvise_collapse hpage_collapse_scan_file collapse_file retract_page_tables i_mmap_lock_read(mapping) pmdp_collapse_flush i_mmap_unlock_read(mapping) move_pgt_entry(NORMAL_PMD, ...) take_rmap_locks move_normal_pmd drop_rmap_locks When this happens, move_normal_pmd() can end up creating bogus PMD entries in the line `pmd_populate(mm, new_pmd, pmd_pgtable(pmd))`. The effect depends on arch-specific and machine-specific details; on x86, you can end up with physical page 0 mapped as a page table, which is likely exploitable for user->kernel privilege escalation. Fix the race by letting process B recheck that the PMD still points to a page table after the rmap locks have been taken. Otherwise, we bail and let the caller fall back to the PTE-level copying path, which will then bail immediately at the pmd_none() check. Bug reachability: Reaching this bug requires that you can create shmem/file THP mappings - anonymous THP uses different code that doesn't zap stuff under rmap locks. File THP is gated on an experimental config flag (CONFIG_READ_ONLY_THP_FOR_FS), so on normal distro kernels you need shmem THP to hit this bug. As far as I know, getting shmem THP normally requires that you can mount your own tmpfs with the right mount flags, which would require creating your own user+mount namespace; though I don't know if some distros maybe enable shmem THP by default or something like that. Bug impact: This issue can likely be used for user->kernel privilege escalation when it is reachable.", "cve_priority": "medium", "cve_public_date": "2024-10-23 06:15:00 UTC" }, { "cve": "CVE-2024-50202", "url": "https://ubuntu.com/security/CVE-2024-50202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: propagate directory read errors from nilfs_find_entry() Syzbot reported that a task hang occurs in vcs_open() during a fuzzing test for nilfs2. The root cause of this problem is that in nilfs_find_entry(), which searches for directory entries, ignores errors when loading a directory page/folio via nilfs_get_folio() fails. If the filesystem images is corrupted, and the i_size of the directory inode is large, and the directory page/folio is successfully read but fails the sanity check, for example when it is zero-filled, nilfs_check_folio() may continue to spit out error messages in bursts. Fix this issue by propagating the error to the callers when loading a page/folio fails in nilfs_find_entry(). The current interface of nilfs_find_entry() and its callers is outdated and cannot propagate error codes such as -EIO and -ENOMEM returned via nilfs_find_entry(), so fix it together.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50200", "url": "https://ubuntu.com/security/CVE-2024-50200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: maple_tree: correct tree corruption on spanning store Patch series \"maple_tree: correct tree corruption on spanning store\", v3. There has been a nasty yet subtle maple tree corruption bug that appears to have been in existence since the inception of the algorithm. This bug seems far more likely to happen since commit f8d112a4e657 (\"mm/mmap: avoid zeroing vma tree in mmap_region()\"), which is the point at which reports started to be submitted concerning this bug. We were made definitely aware of the bug thanks to the kind efforts of Bert Karwatzki who helped enormously in my being able to track this down and identify the cause of it. The bug arises when an attempt is made to perform a spanning store across two leaf nodes, where the right leaf node is the rightmost child of the shared parent, AND the store completely consumes the right-mode node. This results in mas_wr_spanning_store() mitakenly duplicating the new and existing entries at the maximum pivot within the range, and thus maple tree corruption. The fix patch corrects this by detecting this scenario and disallowing the mistaken duplicate copy. The fix patch commit message goes into great detail as to how this occurs. This series also includes a test which reliably reproduces the issue, and asserts that the fix works correctly. Bert has kindly tested the fix and confirmed it resolved his issues. Also Mikhail Gavrilov kindly reported what appears to be precisely the same bug, which this fix should also resolve. This patch (of 2): There has been a subtle bug present in the maple tree implementation from its inception. This arises from how stores are performed - when a store occurs, it will overwrite overlapping ranges and adjust the tree as necessary to accommodate this. A range may always ultimately span two leaf nodes. In this instance we walk the two leaf nodes, determine which elements are not overwritten to the left and to the right of the start and end of the ranges respectively and then rebalance the tree to contain these entries and the newly inserted one. This kind of store is dubbed a 'spanning store' and is implemented by mas_wr_spanning_store(). In order to reach this stage, mas_store_gfp() invokes mas_wr_preallocate(), mas_wr_store_type() and mas_wr_walk() in turn to walk the tree and update the object (mas) to traverse to the location where the write should be performed, determining its store type. When a spanning store is required, this function returns false stopping at the parent node which contains the target range, and mas_wr_store_type() marks the mas->store_type as wr_spanning_store to denote this fact. When we go to perform the store in mas_wr_spanning_store(), we first determine the elements AFTER the END of the range we wish to store (that is, to the right of the entry to be inserted) - we do this by walking to the NEXT pivot in the tree (i.e. r_mas.last + 1), starting at the node we have just determined contains the range over which we intend to write. We then turn our attention to the entries to the left of the entry we are inserting, whose state is represented by l_mas, and copy these into a 'big node', which is a special node which contains enough slots to contain two leaf node's worth of data. We then copy the entry we wish to store immediately after this - the copy and the insertion of the new entry is performed by mas_store_b_node(). After this we copy the elements to the right of the end of the range which we are inserting, if we have not exceeded the length of the node (i.e. r_mas.offset <= r_mas.end). Herein lies the bug - under very specific circumstances, this logic can break and corrupt the maple tree. Consider the following tree: Height 0 Root Node / \\ pivot = 0xffff / \\ pivot = ULONG_MAX / ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50084", "url": "https://ubuntu.com/security/CVE-2024-50084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: microchip: vcap api: Fix memory leaks in vcap_api_encode_rule_test() Commit a3c1e45156ad (\"net: microchip: vcap: Fix use-after-free error in kunit test\") fixed the use-after-free error, but introduced below memory leaks by removing necessary vcap_free_rule(), add it to fix it. \tunreferenced object 0xffffff80ca58b700 (size 192): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898264 \t hex dump (first 32 bytes): \t 00 12 7a 00 05 00 00 00 0a 00 00 00 64 00 00 00 ..z.........d... \t 00 00 00 00 00 00 00 00 00 04 0b cc 80 ff ff ff ................ \t backtrace (crc 9c09c3fe): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<0000000040a01b8d>] vcap_alloc_rule+0x3cc/0x9c4 \t [<000000003fe86110>] vcap_api_encode_rule_test+0x1ac/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0400 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898265 \t hex dump (first 32 bytes): \t 80 04 0b cc 80 ff ff ff 18 b7 58 ca 80 ff ff ff ..........X..... \t 39 00 00 00 02 00 00 00 06 05 04 03 02 01 ff ff 9............... \t backtrace (crc daf014e9): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<00000000dfdb1e81>] vcap_api_encode_rule_test+0x224/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0700 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898265 \t hex dump (first 32 bytes): \t 80 07 0b cc 80 ff ff ff 28 b7 58 ca 80 ff ff ff ........(.X..... \t 3c 00 00 00 00 00 00 00 01 2f 03 b3 ec ff ff ff <......../...... \t backtrace (crc 8d877792): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000006eadfab7>] vcap_rule_add_action+0x2d0/0x52c \t [<00000000323475d1>] vcap_api_encode_rule_test+0x4d4/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0900 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898266 \t hex dump (first 32 bytes): \t 80 09 0b cc 80 ff ff ff 80 06 0b cc 80 ff ff ff ................ \t 7d 00 00 00 01 00 00 00 00 00 00 00 ff 00 00 00 }............... \t backtrace (crc 34181e56): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<00000000991e3564>] vcap_val_rule+0xcf0/0x13e8 \t [<00000000fc9868e5>] vcap_api_encode_rule_test+0x678/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0980 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898266 \t hex dump (first 32 bytes): \t 18 b7 58 ca 80 ff ff ff 00 09 0b cc 80 ff ff ff ..X............. \t 67 00 00 00 00 00 00 00 01 01 74 88 c0 ff ff ff g.........t..... \t backtrace (crc 275fd9be): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<000000001396a1a2>] test_add_de ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50194", "url": "https://ubuntu.com/security/CVE-2024-50194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Fix uprobes for big-endian kernels The arm64 uprobes code is broken for big-endian kernels as it doesn't convert the in-memory instruction encoding (which is always little-endian) into the kernel's native endianness before analyzing and simulating instructions. This may result in a few distinct problems: * The kernel may may erroneously reject probing an instruction which can safely be probed. * The kernel may erroneously erroneously permit stepping an instruction out-of-line when that instruction cannot be stepped out-of-line safely. * The kernel may erroneously simulate instruction incorrectly dur to interpretting the byte-swapped encoding. The endianness mismatch isn't caught by the compiler or sparse because: * The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so the compiler and sparse have no idea these contain a little-endian 32-bit value. The core uprobes code populates these with a memcpy() which similarly does not handle endianness. * While the uprobe_opcode_t type is an alias for __le32, both arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[] to the similarly-named probe_opcode_t, which is an alias for u32. Hence there is no endianness conversion warning. Fix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and adding the appropriate __le32_to_cpu() conversions prior to consuming the instruction encoding. The core uprobes copies these fields as opaque ranges of bytes, and so is unaffected by this change. At the same time, remove MAX_UINSN_BYTES and consistently use AARCH64_INSN_SIZE for clarity. Tested with the following: | #include | #include | | #define noinline __attribute__((noinline)) | | static noinline void *adrp_self(void) | { | void *addr; | | asm volatile( | \" adrp %x0, adrp_self\\n\" | \" add %x0, %x0, :lo12:adrp_self\\n\" | : \"=r\" (addr)); | } | | | int main(int argc, char *argv) | { | void *ptr = adrp_self(); | bool equal = (ptr == adrp_self); | | printf(\"adrp_self => %p\\n\" | \"adrp_self() => %p\\n\" | \"%s\\n\", | adrp_self, ptr, equal ? \"EQUAL\" : \"NOT EQUAL\"); | | return 0; | } .... where the adrp_self() function was compiled to: | 00000000004007e0 : | 4007e0: 90000000 adrp x0, 400000 <__ehdr_start> | 4007e4: 911f8000 add x0, x0, #0x7e0 | 4007e8: d65f03c0 ret Before this patch, the ADRP is not recognized, and is assumed to be steppable, resulting in corruption of the result: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0xffffffffff7e0 | NOT EQUAL After this patch, the ADRP is correctly recognized and simulated: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50099", "url": "https://ubuntu.com/security/CVE-2024-50099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Remove broken LDR (literal) uprobe support The simulate_ldr_literal() and simulate_ldrsw_literal() functions are unsafe to use for uprobes. Both functions were originally written for use with kprobes, and access memory with plain C accesses. When uprobes was added, these were reused unmodified even though they cannot safely access user memory. There are three key problems: 1) The plain C accesses do not have corresponding extable entries, and thus if they encounter a fault the kernel will treat these as unintentional accesses to user memory, resulting in a BUG() which will kill the kernel thread, and likely lead to further issues (e.g. lockup or panic()). 2) The plain C accesses are subject to HW PAN and SW PAN, and so when either is in use, any attempt to simulate an access to user memory will fault. Thus neither simulate_ldr_literal() nor simulate_ldrsw_literal() can do anything useful when simulating a user instruction on any system with HW PAN or SW PAN. 3) The plain C accesses are privileged, as they run in kernel context, and in practice can access a small range of kernel virtual addresses. The instructions they simulate have a range of +/-1MiB, and since the simulated instructions must itself be a user instructions in the TTBR0 address range, these can address the final 1MiB of the TTBR1 acddress range by wrapping downwards from an address in the first 1MiB of the TTBR0 address range. In contemporary kernels the last 8MiB of TTBR1 address range is reserved, and accesses to this will always fault, meaning this is no worse than (1). Historically, it was theoretically possible for the linear map or vmemmap to spill into the final 8MiB of the TTBR1 address range, but in practice this is extremely unlikely to occur as this would require either: * Having enough physical memory to fill the entire linear map all the way to the final 1MiB of the TTBR1 address range. * Getting unlucky with KASLR randomization of the linear map such that the populated region happens to overlap with the last 1MiB of the TTBR address range. ... and in either case if we were to spill into the final page there would be larger problems as the final page would alias with error pointers. Practically speaking, (1) and (2) are the big issues. Given there have been no reports of problems since the broken code was introduced, it appears that no-one is relying on probing these instructions with uprobes. Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW (literal), limiting the use of simulate_ldr_literal() and simulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR (literal) and LDRSW (literal) will be rejected as arm_probe_decode_insn() will return INSN_REJECTED. In future we can consider introducing working uprobes support for these instructions, but this will require more significant work.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50195", "url": "https://ubuntu.com/security/CVE-2024-50195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-clock: Fix missing timespec64 check in pc_clock_settime() As Andrew pointed out, it will make sense that the PTP core checked timespec64 struct's tv_sec and tv_nsec range before calling ptp->info->settime64(). As the man manual of clock_settime() said, if tp.tv_sec is negative or tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL, which include dynamic clocks which handles PTP clock, and the condition is consistent with timespec64_valid(). As Thomas suggested, timespec64_valid() only check the timespec is valid, but not ensure that the time is in a valid range, so check it ahead using timespec64_valid_strict() in pc_clock_settime() and return -EINVAL if not valid. There are some drivers that use tp->tv_sec and tp->tv_nsec directly to write registers without validity checks and assume that the higher layer has checked it, which is dangerous and will benefit from this, such as hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(), and some drivers can remove the checks of itself.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50085", "url": "https://ubuntu.com/security/CVE-2024-50085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: fix UaF read in mptcp_pm_nl_rm_addr_or_subflow Syzkaller reported this splat: ================================================================== BUG: KASAN: slab-use-after-free in mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881 Read of size 4 at addr ffff8880569ac858 by task syz.1.2799/14662 CPU: 0 UID: 0 PID: 14662 Comm: syz.1.2799 Not tainted 6.12.0-rc2-syzkaller-00307-g36c254515dc6 #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+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881 mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:914 [inline] mptcp_nl_remove_id_zero_address+0x305/0x4a0 net/mptcp/pm_netlink.c:1572 mptcp_pm_nl_del_addr_doit+0x5c9/0x770 net/mptcp/pm_netlink.c:1603 genl_family_rcv_msg_doit+0x202/0x2f0 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x565/0x800 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x165/0x410 net/netlink/af_netlink.c:2551 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1331 [inline] netlink_unicast+0x53c/0x7f0 net/netlink/af_netlink.c:1357 netlink_sendmsg+0x8b8/0xd70 net/netlink/af_netlink.c:1901 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg net/socket.c:744 [inline] ____sys_sendmsg+0x9ae/0xb40 net/socket.c:2607 ___sys_sendmsg+0x135/0x1e0 net/socket.c:2661 __sys_sendmsg+0x117/0x1f0 net/socket.c:2690 do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline] __do_fast_syscall_32+0x73/0x120 arch/x86/entry/common.c:386 do_fast_syscall_32+0x32/0x80 arch/x86/entry/common.c:411 entry_SYSENTER_compat_after_hwframe+0x84/0x8e RIP: 0023:0xf7fe4579 Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00 RSP: 002b:00000000f574556c EFLAGS: 00000296 ORIG_RAX: 0000000000000172 RAX: ffffffffffffffda RBX: 000000000000000b RCX: 0000000020000140 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000296 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Allocated by task 5387: 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 kmalloc_noprof include/linux/slab.h:878 [inline] kzalloc_noprof include/linux/slab.h:1014 [inline] subflow_create_ctx+0x87/0x2a0 net/mptcp/subflow.c:1803 subflow_ulp_init+0xc3/0x4d0 net/mptcp/subflow.c:1956 __tcp_set_ulp net/ipv4/tcp_ulp.c:146 [inline] tcp_set_ulp+0x326/0x7f0 net/ipv4/tcp_ulp.c:167 mptcp_subflow_create_socket+0x4ae/0x10a0 net/mptcp/subflow.c:1764 __mptcp_subflow_connect+0x3cc/0x1490 net/mptcp/subflow.c:1592 mptcp_pm_create_subflow_or_signal_addr+0xbda/0x23a0 net/mptcp/pm_netlink.c:642 mptcp_pm_nl_fully_established net/mptcp/pm_netlink.c:650 [inline] mptcp_pm_nl_work+0x3a1/0x4f0 net/mptcp/pm_netlink.c:943 mptcp_worker+0x15a/0x1240 net/mptcp/protocol.c:2777 process_one_work+0x958/0x1b30 kernel/workqueue.c:3229 process_scheduled_works kernel/workqueue.c:3310 [inline] worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/ke ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50086", "url": "https://ubuntu.com/security/CVE-2024-50086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix user-after-free from session log off There is racy issue between smb2 session log off and smb2 session setup. It will cause user-after-free from session log off. This add session_lock when setting SMB2_SESSION_EXPIRED and referece count to session struct not to free session while it is being used.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50087", "url": "https://ubuntu.com/security/CVE-2024-50087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix uninitialized pointer free on read_alloc_one_name() error The function read_alloc_one_name() does not initialize the name field of the passed fscrypt_str struct if kmalloc fails to allocate the corresponding buffer. Thus, it is not guaranteed that fscrypt_str.name is initialized when freeing it. This is a follow-up to the linked patch that fixes the remaining instances of the bug introduced by commit e43eec81c516 (\"btrfs: use struct qstr instead of name and namelen pairs\").", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50088", "url": "https://ubuntu.com/security/CVE-2024-50088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix uninitialized pointer free in add_inode_ref() The add_inode_ref() function does not initialize the \"name\" struct when it is declared. If any of the following calls to \"read_one_inode() returns NULL, \tdir = read_one_inode(root, parent_objectid); \tif (!dir) { \t\tret = -ENOENT; \t\tgoto out; \t} \tinode = read_one_inode(root, inode_objectid); \tif (!inode) { \t\tret = -EIO; \t\tgoto out; \t} then \"name.name\" would be freed on \"out\" before being initialized. out: \t... \tkfree(name.name); This issue was reported by Coverity with CID 1526744.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50182", "url": "https://ubuntu.com/security/CVE-2024-50182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: secretmem: disable memfd_secret() if arch cannot set direct map Return -ENOSYS from memfd_secret() syscall if !can_set_direct_map(). This is the case for example on some arm64 configurations, where marking 4k PTEs in the direct map not present can only be done if the direct map is set up at 4k granularity in the first place (as ARM's break-before-make semantics do not easily allow breaking apart large/gigantic pages). More precisely, on arm64 systems with !can_set_direct_map(), set_direct_map_invalid_noflush() is a no-op, however it returns success (0) instead of an error. This means that memfd_secret will seemingly \"work\" (e.g. syscall succeeds, you can mmap the fd and fault in pages), but it does not actually achieve its goal of removing its memory from the direct map. Note that with this patch, memfd_secret() will start erroring on systems where can_set_direct_map() returns false (arm64 with CONFIG_RODATA_FULL_DEFAULT_ENABLED=n, CONFIG_DEBUG_PAGEALLOC=n and CONFIG_KFENCE=n), but that still seems better than the current silent failure. Since CONFIG_RODATA_FULL_DEFAULT_ENABLED defaults to 'y', most arm64 systems actually have a working memfd_secret() and aren't be affected. From going through the iterations of the original memfd_secret patch series, it seems that disabling the syscall in these scenarios was the intended behavior [1] (preferred over having set_direct_map_invalid_noflush return an error as that would result in SIGBUSes at page-fault time), however the check for it got dropped between v16 [2] and v17 [3], when secretmem moved away from CMA allocations. [1]: https://lore.kernel.org/lkml/20201124164930.GK8537@kernel.org/ [2]: https://lore.kernel.org/lkml/20210121122723.3446-11-rppt@kernel.org/#t [3]: https://lore.kernel.org/lkml/20201125092208.12544-10-rppt@kernel.org/", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50019", "url": "https://ubuntu.com/security/CVE-2024-50019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kthread: unpark only parked kthread Calling into kthread unparking unconditionally is mostly harmless when the kthread is already unparked. The wake up is then simply ignored because the target is not in TASK_PARKED state. However if the kthread is per CPU, the wake up is preceded by a call to kthread_bind() which expects the task to be inactive and in TASK_PARKED state, which obviously isn't the case if it is unparked. As a result, calling kthread_stop() on an unparked per-cpu kthread triggers such a warning: \tWARNING: CPU: 0 PID: 11 at kernel/kthread.c:525 __kthread_bind_mask kernel/kthread.c:525 \t \t kthread_stop+0x17a/0x630 kernel/kthread.c:707 \t destroy_workqueue+0x136/0xc40 kernel/workqueue.c:5810 \t wg_destruct+0x1e2/0x2e0 drivers/net/wireguard/device.c:257 \t netdev_run_todo+0xe1a/0x1000 net/core/dev.c:10693 \t default_device_exit_batch+0xa14/0xa90 net/core/dev.c:11769 \t ops_exit_list net/core/net_namespace.c:178 [inline] \t cleanup_net+0x89d/0xcc0 net/core/net_namespace.c:640 \t process_one_work kernel/workqueue.c:3231 [inline] \t process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 \t worker_thread+0x86d/0xd70 kernel/workqueue.c:3393 \t kthread+0x2f0/0x390 kernel/kthread.c:389 \t ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 \t ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 \t Fix this with skipping unecessary unparking while stopping a kthread.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50096", "url": "https://ubuntu.com/security/CVE-2024-50096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/dmem: Fix vulnerability in migrate_to_ram upon copy error The `nouveau_dmem_copy_one` function ensures that the copy push command is sent to the device firmware but does not track whether it was executed successfully. In the case of a copy error (e.g., firmware or hardware failure), the copy push command will be sent via the firmware channel, and `nouveau_dmem_copy_one` will likely report success, leading to the `migrate_to_ram` function returning a dirty HIGH_USER page to the user. This can result in a security vulnerability, as a HIGH_USER page that may contain sensitive or corrupted data could be returned to the user. To prevent this vulnerability, we allocate a zero page. Thus, in case of an error, a non-dirty (zero) page will be returned to the user.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50020", "url": "https://ubuntu.com/security/CVE-2024-50020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix improper handling of refcount in ice_sriov_set_msix_vec_count() This patch addresses an issue with improper reference count handling in the ice_sriov_set_msix_vec_count() function. First, the function calls ice_get_vf_by_id(), which increments the reference count of the vf pointer. If the subsequent call to ice_get_vf_vsi() fails, the function currently returns an error without decrementing the reference count of the vf pointer, leading to a reference count leak. The correct behavior, as implemented in this patch, is to decrement the reference count using ice_put_vf(vf) before returning an error when vsi is NULL. Second, the function calls ice_sriov_get_irqs(), which sets vf->first_vector_idx. If this call returns a negative value, indicating an error, the function returns an error without decrementing the reference count of the vf pointer, resulting in another reference count leak. The patch addresses this by adding a call to ice_put_vf(vf) before returning an error when vf->first_vector_idx < 0. This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and identifying potential mismanagement of reference counts. In this case, the tool flagged the missing decrement operation as a potential issue, leading to this patch.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50021", "url": "https://ubuntu.com/security/CVE-2024-50021", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix improper handling of refcount in ice_dpll_init_rclk_pins() This patch addresses a reference count handling issue in the ice_dpll_init_rclk_pins() function. The function calls ice_dpll_get_pins(), which increments the reference count of the relevant resources. However, if the condition WARN_ON((!vsi || !vsi->netdev)) is met, the function currently returns an error without properly releasing the resources acquired by ice_dpll_get_pins(), leading to a reference count leak. To resolve this, the check has been moved to the top of the function. This ensures that the function verifies the state before any resources are acquired, avoiding the need for additional resource management in the error path. This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and detecting potential issues where resources are not properly managed. In this case, the tool flagged the missing release operation as a potential problem, which led to the development of this patch.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50022", "url": "https://ubuntu.com/security/CVE-2024-50022", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: device-dax: correct pgoff align in dax_set_mapping() pgoff should be aligned using ALIGN_DOWN() instead of ALIGN(). Otherwise, vmf->address not aligned to fault_size will be aligned to the next alignment, that can result in memory failure getting the wrong address. It's a subtle situation that only can be observed in page_mapped_in_vma() after the page is page fault handled by dev_dax_huge_fault. Generally, there is little chance to perform page_mapped_in_vma in dev-dax's page unless in specific error injection to the dax device to trigger an MCE - memory-failure. In that case, page_mapped_in_vma() will be triggered to determine which task is accessing the failure address and kill that task in the end. We used self-developed dax device (which is 2M aligned mapping) , to perform error injection to random address. It turned out that error injected to non-2M-aligned address was causing endless MCE until panic. Because page_mapped_in_vma() kept resulting wrong address and the task accessing the failure address was never killed properly: [ 3783.719419] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.049006] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.049190] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.448042] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.448186] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.792026] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.792179] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.162502] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.162633] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.461116] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.461247] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.764730] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.764859] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.042128] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.042259] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.464293] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.464423] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.818090] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.818217] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3787.085297] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3787.085424] Memory failure: 0x200c9742: recovery action for dax page: Recovered It took us several weeks to pinpoint this problem,  but we eventually used bpftrace to trace the page fault and mce address and successfully identified the issue. Joao added: ; Likely we never reproduce in production because we always pin : device-dax regions in the region align they provide (Qemu does : similarly with prealloc in hugetlb/file backed memory). I think this : bug requires that we touch *unpinned* device-dax regions unaligned to : the device-dax selected alignment (page size i.e. 4K/2M/1G)", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50185", "url": "https://ubuntu.com/security/CVE-2024-50185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: handle consistently DSS corruption Bugged peer implementation can send corrupted DSS options, consistently hitting a few warning in the data path. Use DEBUG_NET assertions, to avoid the splat on some builds and handle consistently the error, dumping related MIBs and performing fallback and/or reset according to the subflow type.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50023", "url": "https://ubuntu.com/security/CVE-2024-50023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: Remove LED entry from LEDs list on unregister Commit c938ab4da0eb (\"net: phy: Manual remove LEDs to ensure correct ordering\") correctly fixed a problem with using devm_ but missed removing the LED entry from the LEDs list. This cause kernel panic on specific scenario where the port for the PHY is torn down and up and the kmod for the PHY is removed. On setting the port down the first time, the assosiacted LEDs are correctly unregistered. The associated kmod for the PHY is now removed. The kmod is now added again and the port is now put up, the associated LED are registered again. On putting the port down again for the second time after these step, the LED list now have 4 elements. With the first 2 already unregistered previously and the 2 new one registered again. This cause a kernel panic as the first 2 element should have been removed. Fix this by correctly removing the element when LED is unregistered.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50024", "url": "https://ubuntu.com/security/CVE-2024-50024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: Fix an unsafe loop on the list The kernel may crash when deleting a genetlink family if there are still listeners for that family: Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c000000000c080bc] netlink_update_socket_mc+0x3c/0xc0 LR [c000000000c0f764] __netlink_clear_multicast_users+0x74/0xc0 Call Trace: __netlink_clear_multicast_users+0x74/0xc0 genl_unregister_family+0xd4/0x2d0 Change the unsafe loop on the list to a safe one, because inside the loop there is an element removal from this list.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50186", "url": "https://ubuntu.com/security/CVE-2024-50186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: explicitly clear the sk pointer, when pf->create fails We have recently noticed the exact same KASAN splat as in commit 6cd4a78d962b (\"net: do not leave a dangling sk pointer, when socket creation fails\"). The problem is that commit did not fully address the problem, as some pf->create implementations do not use sk_common_release in their error paths. For example, we can use the same reproducer as in the above commit, but changing ping to arping. arping uses AF_PACKET socket and if packet_create fails, it will just sk_free the allocated sk object. While we could chase all the pf->create implementations and make sure they NULL the freed sk object on error from the socket, we can't guarantee future protocols will not make the same mistake. So it is easier to just explicitly NULL the sk pointer upon return from pf->create in __sock_create. We do know that pf->create always releases the allocated sk object on error, so if the pointer is not NULL, it is definitely dangling.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50025", "url": "https://ubuntu.com/security/CVE-2024-50025", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: fnic: Move flush_work initialization out of if block After commit 379a58caa199 (\"scsi: fnic: Move fnic_fnic_flush_tx() to a work queue\"), it can happen that a work item is sent to an uninitialized work queue. This may has the effect that the item being queued is never actually queued, and any further actions depending on it will not proceed. The following warning is observed while the fnic driver is loaded: kernel: WARNING: CPU: 11 PID: 0 at ../kernel/workqueue.c:1524 __queue_work+0x373/0x410 kernel: kernel: queue_work_on+0x3a/0x50 kernel: fnic_wq_copy_cmpl_handler+0x54a/0x730 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: fnic_isr_msix_wq_copy+0x2d/0x60 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: __handle_irq_event_percpu+0x36/0x1a0 kernel: handle_irq_event_percpu+0x30/0x70 kernel: handle_irq_event+0x34/0x60 kernel: handle_edge_irq+0x7e/0x1a0 kernel: __common_interrupt+0x3b/0xb0 kernel: common_interrupt+0x58/0xa0 kernel: It has been observed that this may break the rediscovery of Fibre Channel devices after a temporary fabric failure. This patch fixes it by moving the work queue initialization out of an if block in fnic_probe().", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50026", "url": "https://ubuntu.com/security/CVE-2024-50026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: wd33c93: Don't use stale scsi_pointer value A regression was introduced with commit dbb2da557a6a (\"scsi: wd33c93: Move the SCSI pointer to private command data\") which results in an oops in wd33c93_intr(). That commit added the scsi_pointer variable and initialized it from hostdata->connected. However, during selection, hostdata->connected is not yet valid. Fix this by getting the current scsi_pointer from hostdata->selecting.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50027", "url": "https://ubuntu.com/security/CVE-2024-50027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: core: Free tzp copy along with the thermal zone The object pointed to by tz->tzp may still be accessed after being freed in thermal_zone_device_unregister(), so move the freeing of it to the point after the removal completion has been completed at which it cannot be accessed any more.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50028", "url": "https://ubuntu.com/security/CVE-2024-50028", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: core: Reference count the zone in thermal_zone_get_by_id() There are places in the thermal netlink code where nothing prevents the thermal zone object from going away while being accessed after it has been returned by thermal_zone_get_by_id(). To address this, make thermal_zone_get_by_id() get a reference on the thermal zone device object to be returned with the help of get_device(), under thermal_list_lock, and adjust all of its callers to this change with the help of the cleanup.h infrastructure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50029", "url": "https://ubuntu.com/security/CVE-2024-50029", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_conn: Fix UAF in hci_enhanced_setup_sync This checks if the ACL connection remains valid as it could be destroyed while hci_enhanced_setup_sync is pending on cmd_sync leading to the following trace: BUG: KASAN: slab-use-after-free in hci_enhanced_setup_sync+0x91b/0xa60 Read of size 1 at addr ffff888002328ffd by task kworker/u5:2/37 CPU: 0 UID: 0 PID: 37 Comm: kworker/u5:2 Not tainted 6.11.0-rc6-01300-g810be445d8d6 #7099 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Workqueue: hci0 hci_cmd_sync_work Call Trace: dump_stack_lvl+0x5d/0x80 ? hci_enhanced_setup_sync+0x91b/0xa60 print_report+0x152/0x4c0 ? hci_enhanced_setup_sync+0x91b/0xa60 ? __virt_addr_valid+0x1fa/0x420 ? hci_enhanced_setup_sync+0x91b/0xa60 kasan_report+0xda/0x1b0 ? hci_enhanced_setup_sync+0x91b/0xa60 hci_enhanced_setup_sync+0x91b/0xa60 ? __pfx_hci_enhanced_setup_sync+0x10/0x10 ? __pfx___mutex_lock+0x10/0x10 hci_cmd_sync_work+0x1c2/0x330 process_one_work+0x7d9/0x1360 ? __pfx_lock_acquire+0x10/0x10 ? __pfx_process_one_work+0x10/0x10 ? assign_work+0x167/0x240 worker_thread+0x5b7/0xf60 ? __kthread_parkme+0xac/0x1c0 ? __pfx_worker_thread+0x10/0x10 ? __pfx_worker_thread+0x10/0x10 kthread+0x293/0x360 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2f/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 34: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __hci_conn_add+0x187/0x17d0 hci_connect_sco+0x2e1/0xb90 sco_sock_connect+0x2a2/0xb80 __sys_connect+0x227/0x2a0 __x64_sys_connect+0x6d/0xb0 do_syscall_64+0x71/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 37: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x101/0x160 kfree+0xd0/0x250 device_release+0x9a/0x210 kobject_put+0x151/0x280 hci_conn_del+0x448/0xbf0 hci_abort_conn_sync+0x46f/0x980 hci_cmd_sync_work+0x1c2/0x330 process_one_work+0x7d9/0x1360 worker_thread+0x5b7/0xf60 kthread+0x293/0x360 ret_from_fork+0x2f/0x70 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50030", "url": "https://ubuntu.com/security/CVE-2024-50030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/ct: prevent UAF in send_recv() Ensure we serialize with completion side to prevent UAF with fence going out of scope on the stack, since we have no clue if it will fire after the timeout before we can erase from the xa. Also we have some dependent loads and stores for which we need the correct ordering, and we lack the needed barriers. Fix this by grabbing the ct->lock after the wait, which is also held by the completion side. v2 (Badal): - Also print done after acquiring the lock and seeing timeout. (cherry picked from commit 52789ce35c55ccd30c4b67b9cc5b2af55e0122ea)", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50187", "url": "https://ubuntu.com/security/CVE-2024-50187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Stop the active perfmon before being destroyed Upon closing the file descriptor, the active performance monitor is not stopped. Although all perfmons are destroyed in `vc4_perfmon_close_file()`, the active performance monitor's pointer (`vc4->active_perfmon`) is still retained. If we open a new file descriptor and submit a few jobs with performance monitors, the driver will attempt to stop the active performance monitor using the stale pointer in `vc4->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50031", "url": "https://ubuntu.com/security/CVE-2024-50031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Stop the active perfmon before being destroyed When running `kmscube` with one or more performance monitors enabled via `GALLIUM_HUD`, the following kernel panic can occur: [ 55.008324] Unable to handle kernel paging request at virtual address 00000000052004a4 [ 55.008368] Mem abort info: [ 55.008377] ESR = 0x0000000096000005 [ 55.008387] EC = 0x25: DABT (current EL), IL = 32 bits [ 55.008402] SET = 0, FnV = 0 [ 55.008412] EA = 0, S1PTW = 0 [ 55.008421] FSC = 0x05: level 1 translation fault [ 55.008434] Data abort info: [ 55.008442] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 55.008455] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 55.008467] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 55.008481] user pgtable: 4k pages, 39-bit VAs, pgdp=00000001046c6000 [ 55.008497] [00000000052004a4] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 55.008525] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP [ 55.008542] Modules linked in: rfcomm [...] vc4 v3d snd_soc_hdmi_codec drm_display_helper gpu_sched drm_shmem_helper cec drm_dma_helper drm_kms_helper i2c_brcmstb drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight [ 55.008799] CPU: 2 PID: 166 Comm: v3d_bin Tainted: G C 6.6.47+rpt-rpi-v8 #1 Debian 1:6.6.47-1+rpt1 [ 55.008824] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [ 55.008838] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 55.008855] pc : __mutex_lock.constprop.0+0x90/0x608 [ 55.008879] lr : __mutex_lock.constprop.0+0x58/0x608 [ 55.008895] sp : ffffffc080673cf0 [ 55.008904] x29: ffffffc080673cf0 x28: 0000000000000000 x27: ffffff8106188a28 [ 55.008926] x26: ffffff8101e78040 x25: ffffff8101baa6c0 x24: ffffffd9d989f148 [ 55.008947] x23: ffffffda1c2a4008 x22: 0000000000000002 x21: ffffffc080673d38 [ 55.008968] x20: ffffff8101238000 x19: ffffff8104f83188 x18: 0000000000000000 [ 55.008988] x17: 0000000000000000 x16: ffffffda1bd04d18 x15: 00000055bb08bc90 [ 55.009715] x14: 0000000000000000 x13: 0000000000000000 x12: ffffffda1bd4cbb0 [ 55.010433] x11: 00000000fa83b2da x10: 0000000000001a40 x9 : ffffffda1bd04d04 [ 55.011162] x8 : ffffff8102097b80 x7 : 0000000000000000 x6 : 00000000030a5857 [ 55.011880] x5 : 00ffffffffffffff x4 : 0300000005200470 x3 : 0300000005200470 [ 55.012598] x2 : ffffff8101238000 x1 : 0000000000000021 x0 : 0300000005200470 [ 55.013292] Call trace: [ 55.013959] __mutex_lock.constprop.0+0x90/0x608 [ 55.014646] __mutex_lock_slowpath+0x1c/0x30 [ 55.015317] mutex_lock+0x50/0x68 [ 55.015961] v3d_perfmon_stop+0x40/0xe0 [v3d] [ 55.016627] v3d_bin_job_run+0x10c/0x2d8 [v3d] [ 55.017282] drm_sched_main+0x178/0x3f8 [gpu_sched] [ 55.017921] kthread+0x11c/0x128 [ 55.018554] ret_from_fork+0x10/0x20 [ 55.019168] Code: f9400260 f1001c1f 54001ea9 927df000 (b9403401) [ 55.019776] ---[ end trace 0000000000000000 ]--- [ 55.020411] note: v3d_bin[166] exited with preempt_count 1 This issue arises because, upon closing the file descriptor (which happens when we interrupt `kmscube`), the active performance monitor is not stopped. Although all perfmons are destroyed in `v3d_perfmon_close_file()`, the active performance monitor's pointer (`v3d->active_perfmon`) is still retained. If `kmscube` is run again, the driver will attempt to stop the active performance monitor using the stale pointer in `v3d->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50189", "url": "https://ubuntu.com/security/CVE-2024-50189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: amd_sfh: Switch to device-managed dmam_alloc_coherent() Using the device-managed version allows to simplify clean-up in probe() error path. Additionally, this device-managed ensures proper cleanup, which helps to resolve memory errors, page faults, btrfs going read-only, and btrfs disk corruption.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50033", "url": "https://ubuntu.com/security/CVE-2024-50033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slip: make slhc_remember() more robust against malicious packets syzbot found that slhc_remember() was missing checks against malicious packets [1]. slhc_remember() only checked the size of the packet was at least 20, which is not good enough. We need to make sure the packet includes the IPv4 and TCP header that are supposed to be carried. Add iph and th pointers to make the code more readable. [1] BUG: KMSAN: uninit-value in slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 ppp_receive_nonmp_frame+0xe45/0x35e0 drivers/net/ppp/ppp_generic.c:2455 ppp_receive_frame drivers/net/ppp/ppp_generic.c:2372 [inline] ppp_do_recv+0x65f/0x40d0 drivers/net/ppp/ppp_generic.c:2212 ppp_input+0x7dc/0xe60 drivers/net/ppp/ppp_generic.c:2327 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 Uninit was created at: slab_post_alloc_hook mm/slub.c:4091 [inline] slab_alloc_node mm/slub.c:4134 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 CPU: 0 UID: 0 PID: 5460 Comm: syz.2.33 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50034", "url": "https://ubuntu.com/security/CVE-2024-50034", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix lacks of icsk_syn_mss with IPPROTO_SMC Eric report a panic on IPPROTO_SMC, and give the facts that when INET_PROTOSW_ICSK was set, icsk->icsk_sync_mss must be set too. Bug: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000086000005 EC = 0x21: IABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault user pgtable: 4k pages, 48-bit VAs, pgdp=00000001195d1000 [0000000000000000] pgd=0800000109c46003, p4d=0800000109c46003, pud=0000000000000000 Internal error: Oops: 0000000086000005 [#1] PREEMPT SMP Modules linked in: CPU: 1 UID: 0 PID: 8037 Comm: syz.3.265 Not tainted 6.11.0-rc7-syzkaller-g5f5673607153 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0x0 lr : cipso_v4_sock_setattr+0x2a8/0x3c0 net/ipv4/cipso_ipv4.c:1910 sp : ffff80009b887a90 x29: ffff80009b887aa0 x28: ffff80008db94050 x27: 0000000000000000 x26: 1fffe0001aa6f5b3 x25: dfff800000000000 x24: ffff0000db75da00 x23: 0000000000000000 x22: ffff0000d8b78518 x21: 0000000000000000 x20: ffff0000d537ad80 x19: ffff0000d8b78000 x18: 1fffe000366d79ee x17: ffff8000800614a8 x16: ffff800080569b84 x15: 0000000000000001 x14: 000000008b336894 x13: 00000000cd96feaa x12: 0000000000000003 x11: 0000000000040000 x10: 00000000000020a3 x9 : 1fffe0001b16f0f1 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 000000000000003f x5 : 0000000000000040 x4 : 0000000000000001 x3 : 0000000000000000 x2 : 0000000000000002 x1 : 0000000000000000 x0 : ffff0000d8b78000 Call trace: 0x0 netlbl_sock_setattr+0x2e4/0x338 net/netlabel/netlabel_kapi.c:1000 smack_netlbl_add+0xa4/0x154 security/smack/smack_lsm.c:2593 smack_socket_post_create+0xa8/0x14c security/smack/smack_lsm.c:2973 security_socket_post_create+0x94/0xd4 security/security.c:4425 __sock_create+0x4c8/0x884 net/socket.c:1587 sock_create net/socket.c:1622 [inline] __sys_socket_create net/socket.c:1659 [inline] __sys_socket+0x134/0x340 net/socket.c:1706 __do_sys_socket net/socket.c:1720 [inline] __se_sys_socket net/socket.c:1718 [inline] __arm64_sys_socket+0x7c/0x94 net/socket.c:1718 __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:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 Code: ???????? ???????? ???????? ???????? (????????) ---[ end trace 0000000000000000 ]--- This patch add a toy implementation that performs a simple return to prevent such panic. This is because MSS can be set in sock_create_kern or smc_setsockopt, similar to how it's done in AF_SMC. However, for AF_SMC, there is currently no way to synchronize MSS within __sys_connect_file. This toy implementation lays the groundwork for us to support such feature for IPPROTO_SMC in the future.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50035", "url": "https://ubuntu.com/security/CVE-2024-50035", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: fix ppp_async_encode() illegal access syzbot reported an issue in ppp_async_encode() [1] In this case, pppoe_sendmsg() is called with a zero size. Then ppp_async_encode() is called with an empty skb. BUG: KMSAN: uninit-value in ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] BUG: KMSAN: uninit-value in ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_send+0x130/0x1b0 drivers/net/ppp/ppp_async.c:634 ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2280 [inline] ppp_input+0x1f1/0xe60 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 Uninit was created at: slab_post_alloc_hook mm/slub.c:4092 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4187 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 CPU: 1 UID: 0 PID: 5411 Comm: syz.1.14 Not tainted 6.12.0-rc1-syzkaller-00165-g360c1f1f24c6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50036", "url": "https://ubuntu.com/security/CVE-2024-50036", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: do not delay dst_entries_add() in dst_release() dst_entries_add() uses per-cpu data that might be freed at netns dismantle from ip6_route_net_exit() calling dst_entries_destroy() Before ip6_route_net_exit() can be called, we release all the dsts associated with this netns, via calls to dst_release(), which waits an rcu grace period before calling dst_destroy() dst_entries_add() use in dst_destroy() is racy, because dst_entries_destroy() could have been called already. Decrementing the number of dsts must happen sooner. Notes: 1) in CONFIG_XFRM case, dst_destroy() can call dst_release_immediate(child), this might also cause UAF if the child does not have DST_NOCOUNT set. IPSEC maintainers might take a look and see how to address this. 2) There is also discussion about removing this count of dst, which might happen in future kernels.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50037", "url": "https://ubuntu.com/security/CVE-2024-50037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/fbdev-dma: Only cleanup deferred I/O if necessary Commit 5a498d4d06d6 (\"drm/fbdev-dma: Only install deferred I/O if necessary\") initializes deferred I/O only if it is used. drm_fbdev_dma_fb_destroy() however calls fb_deferred_io_cleanup() unconditionally with struct fb_info.fbdefio == NULL. KASAN with the out-of-tree Apple silicon display driver posts following warning from __flush_work() of a random struct work_struct instead of the expected NULL pointer derefs. [ 22.053799] ------------[ cut here ]------------ [ 22.054832] WARNING: CPU: 2 PID: 1 at kernel/workqueue.c:4177 __flush_work+0x4d8/0x580 [ 22.056597] Modules linked in: uhid bnep uinput nls_ascii ip6_tables ip_tables i2c_dev loop fuse dm_multipath nfnetlink zram hid_magicmouse btrfs xor xor_neon brcmfmac_wcc raid6_pq hci_bcm4377 bluetooth brcmfmac hid_apple brcmutil nvmem_spmi_mfd simple_mfd_spmi dockchannel_hid cfg80211 joydev regmap_spmi nvme_apple ecdh_generic ecc macsmc_hid rfkill dwc3 appledrm snd_soc_macaudio macsmc_power nvme_core apple_isp phy_apple_atc apple_sart apple_rtkit_helper apple_dockchannel tps6598x macsmc_hwmon snd_soc_cs42l84 videobuf2_v4l2 spmi_apple_controller nvmem_apple_efuses videobuf2_dma_sg apple_z2 videobuf2_memops spi_nor panel_summit videobuf2_common asahi videodev pwm_apple apple_dcp snd_soc_apple_mca apple_admac spi_apple clk_apple_nco i2c_pasemi_platform snd_pcm_dmaengine mc i2c_pasemi_core mux_core ofpart adpdrm drm_dma_helper apple_dart apple_soc_cpufreq leds_pwm phram [ 22.073768] CPU: 2 UID: 0 PID: 1 Comm: systemd-shutdow Not tainted 6.11.2-asahi+ #asahi-dev [ 22.075612] Hardware name: Apple MacBook Pro (13-inch, M2, 2022) (DT) [ 22.077032] pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 22.078567] pc : __flush_work+0x4d8/0x580 [ 22.079471] lr : __flush_work+0x54/0x580 [ 22.080345] sp : ffffc000836ef820 [ 22.081089] x29: ffffc000836ef880 x28: 0000000000000000 x27: ffff80002ddb7128 [ 22.082678] x26: dfffc00000000000 x25: 1ffff000096f0c57 x24: ffffc00082d3e358 [ 22.084263] x23: ffff80004b7862b8 x22: dfffc00000000000 x21: ffff80005aa1d470 [ 22.085855] x20: ffff80004b786000 x19: ffff80004b7862a0 x18: 0000000000000000 [ 22.087439] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000005 [ 22.089030] x14: 1ffff800106ddf0a x13: 0000000000000000 x12: 0000000000000000 [ 22.090618] x11: ffffb800106ddf0f x10: dfffc00000000000 x9 : 1ffff800106ddf0e [ 22.092206] x8 : 0000000000000000 x7 : aaaaaaaaaaaaaaaa x6 : 0000000000000001 [ 22.093790] x5 : ffffc000836ef728 x4 : 0000000000000000 x3 : 0000000000000020 [ 22.095368] x2 : 0000000000000008 x1 : 00000000000000aa x0 : 0000000000000000 [ 22.096955] Call trace: [ 22.097505] __flush_work+0x4d8/0x580 [ 22.098330] flush_delayed_work+0x80/0xb8 [ 22.099231] fb_deferred_io_cleanup+0x3c/0x130 [ 22.100217] drm_fbdev_dma_fb_destroy+0x6c/0xe0 [drm_dma_helper] [ 22.101559] unregister_framebuffer+0x210/0x2f0 [ 22.102575] drm_fb_helper_unregister_info+0x48/0x60 [ 22.103683] drm_fbdev_dma_client_unregister+0x4c/0x80 [drm_dma_helper] [ 22.105147] drm_client_dev_unregister+0x1cc/0x230 [ 22.106217] drm_dev_unregister+0x58/0x570 [ 22.107125] apple_drm_unbind+0x50/0x98 [appledrm] [ 22.108199] component_del+0x1f8/0x3a8 [ 22.109042] dcp_platform_shutdown+0x24/0x38 [apple_dcp] [ 22.110357] platform_shutdown+0x70/0x90 [ 22.111219] device_shutdown+0x368/0x4d8 [ 22.112095] kernel_restart+0x6c/0x1d0 [ 22.112946] __arm64_sys_reboot+0x1c8/0x328 [ 22.113868] invoke_syscall+0x78/0x1a8 [ 22.114703] do_el0_svc+0x124/0x1a0 [ 22.115498] el0_svc+0x3c/0xe0 [ 22.116181] el0t_64_sync_handler+0x70/0xc0 [ 22.117110] el0t_64_sync+0x190/0x198 [ 22.117931] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50092", "url": "https://ubuntu.com/security/CVE-2024-50092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netconsole: fix wrong warning A warning is triggered when there is insufficient space in the buffer for userdata. However, this is not an issue since userdata will be sent in the next iteration. Current warning message: ------------[ cut here ]------------ WARNING: CPU: 13 PID: 3013042 at drivers/net/netconsole.c:1122 write_ext_msg+0x3b6/0x3d0 ? write_ext_msg+0x3b6/0x3d0 console_flush_all+0x1e9/0x330 The code incorrectly issues a warning when this_chunk is zero, which is a valid scenario. The warning should only be triggered when this_chunk is negative.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50038", "url": "https://ubuntu.com/security/CVE-2024-50038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xtables: avoid NFPROTO_UNSPEC where needed syzbot managed to call xt_cluster match via ebtables: WARNING: CPU: 0 PID: 11 at net/netfilter/xt_cluster.c:72 xt_cluster_mt+0x196/0x780 [..] ebt_do_table+0x174b/0x2a40 Module registers to NFPROTO_UNSPEC, but it assumes ipv4/ipv6 packet processing. As this is only useful to restrict locally terminating TCP/UDP traffic, register this for ipv4 and ipv6 family only. Pablo points out that this is a general issue, direct users of the set/getsockopt interface can call into targets/matches that were only intended for use with ip(6)tables. Check all UNSPEC matches and targets for similar issues: - matches and targets are fine except if they assume skb_network_header() is valid -- this is only true when called from inet layer: ip(6) stack pulls the ip/ipv6 header into linear data area. - targets that return XT_CONTINUE or other xtables verdicts must be restricted too, they are incompatbile with the ebtables traverser, e.g. EBT_CONTINUE is a completely different value than XT_CONTINUE. Most matches/targets are changed to register for NFPROTO_IPV4/IPV6, as they are provided for use by ip(6)tables. The MARK target is also used by arptables, so register for NFPROTO_ARP too. While at it, bail out if connbytes fails to enable the corresponding conntrack family. This change passes the selftests in iptables.git.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50039", "url": "https://ubuntu.com/security/CVE-2024-50039", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: accept TCA_STAB only for root qdisc Most qdiscs maintain their backlog using qdisc_pkt_len(skb) on the assumption it is invariant between the enqueue() and dequeue() handlers. Unfortunately syzbot can crash a host rather easily using a TBF + SFQ combination, with an STAB on SFQ [1] We can't support TCA_STAB on arbitrary level, this would require to maintain per-qdisc storage. [1] [ 88.796496] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 88.798611] #PF: supervisor read access in kernel mode [ 88.799014] #PF: error_code(0x0000) - not-present page [ 88.799506] PGD 0 P4D 0 [ 88.799829] Oops: Oops: 0000 [#1] SMP NOPTI [ 88.800569] CPU: 14 UID: 0 PID: 2053 Comm: b371744477 Not tainted 6.12.0-rc1-virtme #1117 [ 88.801107] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 88.801779] RIP: 0010:sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq [ 88.802544] Code: 0f b7 50 12 48 8d 04 d5 00 00 00 00 48 89 d6 48 29 d0 48 8b 91 c0 01 00 00 48 c1 e0 03 48 01 c2 66 83 7a 1a 00 7e c0 48 8b 3a <4c> 8b 07 4c 89 02 49 89 50 08 48 c7 47 08 00 00 00 00 48 c7 07 00 All code ======== 0:\t0f b7 50 12 \tmovzwl 0x12(%rax),%edx 4:\t48 8d 04 d5 00 00 00 \tlea 0x0(,%rdx,8),%rax b:\t00 c:\t48 89 d6 \tmov %rdx,%rsi f:\t48 29 d0 \tsub %rdx,%rax 12:\t48 8b 91 c0 01 00 00 \tmov 0x1c0(%rcx),%rdx 19:\t48 c1 e0 03 \tshl $0x3,%rax 1d:\t48 01 c2 \tadd %rax,%rdx 20:\t66 83 7a 1a 00 \tcmpw $0x0,0x1a(%rdx) 25:\t7e c0 \tjle 0xffffffffffffffe7 27:\t48 8b 3a \tmov (%rdx),%rdi 2a:*\t4c 8b 07 \tmov (%rdi),%r8\t\t<-- trapping instruction 2d:\t4c 89 02 \tmov %r8,(%rdx) 30:\t49 89 50 08 \tmov %rdx,0x8(%r8) 34:\t48 c7 47 08 00 00 00 \tmovq $0x0,0x8(%rdi) 3b:\t00 3c:\t48 \trex.W 3d:\tc7 \t.byte 0xc7 3e:\t07 \t(bad) \t... Code starting with the faulting instruction =========================================== 0:\t4c 8b 07 \tmov (%rdi),%r8 3:\t4c 89 02 \tmov %r8,(%rdx) 6:\t49 89 50 08 \tmov %rdx,0x8(%r8) a:\t48 c7 47 08 00 00 00 \tmovq $0x0,0x8(%rdi) 11:\t00 12:\t48 \trex.W 13:\tc7 \t.byte 0xc7 14:\t07 \t(bad) \t... [ 88.803721] RSP: 0018:ffff9a1f892b7d58 EFLAGS: 00000206 [ 88.804032] RAX: 0000000000000000 RBX: ffff9a1f8420c800 RCX: ffff9a1f8420c800 [ 88.804560] RDX: ffff9a1f81bc1440 RSI: 0000000000000000 RDI: 0000000000000000 [ 88.805056] RBP: ffffffffc04bb0e0 R08: 0000000000000001 R09: 00000000ff7f9a1f [ 88.805473] R10: 000000000001001b R11: 0000000000009a1f R12: 0000000000000140 [ 88.806194] R13: 0000000000000001 R14: ffff9a1f886df400 R15: ffff9a1f886df4ac [ 88.806734] FS: 00007f445601a740(0000) GS:ffff9a2e7fd80000(0000) knlGS:0000000000000000 [ 88.807225] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 88.807672] CR2: 0000000000000000 CR3: 000000050cc46000 CR4: 00000000000006f0 [ 88.808165] Call Trace: [ 88.808459] [ 88.808710] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434) [ 88.809261] ? page_fault_oops (arch/x86/mm/fault.c:715) [ 88.809561] ? exc_page_fault (./arch/x86/include/asm/irqflags.h:26 ./arch/x86/include/asm/irqflags.h:87 ./arch/x86/include/asm/irqflags.h:147 arch/x86/mm/fault.c:1489 arch/x86/mm/fault.c:1539) [ 88.809806] ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623) [ 88.810074] ? sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq [ 88.810411] sfq_reset (net/sched/sch_sfq.c:525) sch_sfq [ 88.810671] qdisc_reset (./include/linux/skbuff.h:2135 ./include/linux/skbuff.h:2441 ./include/linux/skbuff.h:3304 ./include/linux/skbuff.h:3310 net/sched/sch_g ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50040", "url": "https://ubuntu.com/security/CVE-2024-50040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: igb: Do not bring the device up after non-fatal error Commit 004d25060c78 (\"igb: Fix igb_down hung on surprise removal\") changed igb_io_error_detected() to ignore non-fatal pcie errors in order to avoid hung task that can happen when igb_down() is called multiple times. This caused an issue when processing transient non-fatal errors. igb_io_resume(), which is called after igb_io_error_detected(), assumes that device is brought down by igb_io_error_detected() if the interface is up. This resulted in panic with stacktrace below. [ T3256] igb 0000:09:00.0 haeth0: igb: haeth0 NIC Link is Down [ T292] pcieport 0000:00:1c.5: AER: Uncorrected (Non-Fatal) error received: 0000:09:00.0 [ T292] igb 0000:09:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, (Requester ID) [ T292] igb 0000:09:00.0: device [8086:1537] error status/mask=00004000/00000000 [ T292] igb 0000:09:00.0: [14] CmpltTO [ 200.105524,009][ T292] igb 0000:09:00.0: AER: TLP Header: 00000000 00000000 00000000 00000000 [ T292] pcieport 0000:00:1c.5: AER: broadcast error_detected message [ T292] igb 0000:09:00.0: Non-correctable non-fatal error reported. [ T292] pcieport 0000:00:1c.5: AER: broadcast mmio_enabled message [ T292] pcieport 0000:00:1c.5: AER: broadcast resume message [ T292] ------------[ cut here ]------------ [ T292] kernel BUG at net/core/dev.c:6539! [ T292] invalid opcode: 0000 [#1] PREEMPT SMP [ T292] RIP: 0010:napi_enable+0x37/0x40 [ T292] Call Trace: [ T292] [ T292] ? die+0x33/0x90 [ T292] ? do_trap+0xdc/0x110 [ T292] ? napi_enable+0x37/0x40 [ T292] ? do_error_trap+0x70/0xb0 [ T292] ? napi_enable+0x37/0x40 [ T292] ? napi_enable+0x37/0x40 [ T292] ? exc_invalid_op+0x4e/0x70 [ T292] ? napi_enable+0x37/0x40 [ T292] ? asm_exc_invalid_op+0x16/0x20 [ T292] ? napi_enable+0x37/0x40 [ T292] igb_up+0x41/0x150 [ T292] igb_io_resume+0x25/0x70 [ T292] report_resume+0x54/0x70 [ T292] ? report_frozen_detected+0x20/0x20 [ T292] pci_walk_bus+0x6c/0x90 [ T292] ? aer_print_port_info+0xa0/0xa0 [ T292] pcie_do_recovery+0x22f/0x380 [ T292] aer_process_err_devices+0x110/0x160 [ T292] aer_isr+0x1c1/0x1e0 [ T292] ? disable_irq_nosync+0x10/0x10 [ T292] irq_thread_fn+0x1a/0x60 [ T292] irq_thread+0xe3/0x1a0 [ T292] ? irq_set_affinity_notifier+0x120/0x120 [ T292] ? irq_affinity_notify+0x100/0x100 [ T292] kthread+0xe2/0x110 [ T292] ? kthread_complete_and_exit+0x20/0x20 [ T292] ret_from_fork+0x2d/0x50 [ T292] ? kthread_complete_and_exit+0x20/0x20 [ T292] ret_from_fork_asm+0x11/0x20 [ T292] To fix this issue igb_io_resume() checks if the interface is running and the device is not down this means igb_io_error_detected() did not bring the device down and there is no need to bring it up.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50041", "url": "https://ubuntu.com/security/CVE-2024-50041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: Fix macvlan leak by synchronizing access to mac_filter_hash This patch addresses a macvlan leak issue in the i40e driver caused by concurrent access to vsi->mac_filter_hash. The leak occurs when multiple threads attempt to modify the mac_filter_hash simultaneously, leading to inconsistent state and potential memory leaks. To fix this, we now wrap the calls to i40e_del_mac_filter() and zeroing vf->default_lan_addr.addr with spin_lock/unlock_bh(&vsi->mac_filter_hash_lock), ensuring atomic operations and preventing concurrent access. Additionally, we add lockdep_assert_held(&vsi->mac_filter_hash_lock) in i40e_add_mac_filter() to help catch similar issues in the future. Reproduction steps: 1. Spawn VFs and configure port vlan on them. 2. Trigger concurrent macvlan operations (e.g., adding and deleting \tportvlan and/or mac filters). 3. Observe the potential memory leak and inconsistent state in the \tmac_filter_hash. This synchronization ensures the integrity of the mac_filter_hash and prevents the described leak.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50042", "url": "https://ubuntu.com/security/CVE-2024-50042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix increasing MSI-X on VF Increasing MSI-X value on a VF leads to invalid memory operations. This is caused by not reallocating some arrays. Reproducer: modprobe ice echo 0 > /sys/bus/pci/devices/$PF_PCI/sriov_drivers_autoprobe echo 1 > /sys/bus/pci/devices/$PF_PCI/sriov_numvfs echo 17 > /sys/bus/pci/devices/$VF0_PCI/sriov_vf_msix_count Default MSI-X is 16, so 17 and above triggers this issue. KASAN reports: BUG: KASAN: slab-out-of-bounds in ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] Read of size 8 at addr ffff8888b937d180 by task bash/28433 (...) Call Trace: (...) ? ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] kasan_report+0xed/0x120 ? ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] ice_vsi_cfg_def+0x3360/0x4770 [ice] ? mutex_unlock+0x83/0xd0 ? __pfx_ice_vsi_cfg_def+0x10/0x10 [ice] ? __pfx_ice_remove_vsi_lkup_fltr+0x10/0x10 [ice] ice_vsi_cfg+0x7f/0x3b0 [ice] ice_vf_reconfig_vsi+0x114/0x210 [ice] ice_sriov_set_msix_vec_count+0x3d0/0x960 [ice] sriov_vf_msix_count_store+0x21c/0x300 (...) Allocated by task 28201: (...) ice_vsi_cfg_def+0x1c8e/0x4770 [ice] ice_vsi_cfg+0x7f/0x3b0 [ice] ice_vsi_setup+0x179/0xa30 [ice] ice_sriov_configure+0xcaa/0x1520 [ice] sriov_numvfs_store+0x212/0x390 (...) To fix it, use ice_vsi_rebuild() instead of ice_vf_reconfig_vsi(). This causes the required arrays to be reallocated taking the new queue count into account (ice_vsi_realloc_stat_arrays()). Set req_txq and req_rxq before ice_vsi_rebuild(), so that realloc uses the newly set queue count. Additionally, ice_vsi_rebuild() does not remove VSI filters (ice_fltr_remove_all()), so ice_vf_init_host_cfg() is no longer necessary.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50093", "url": "https://ubuntu.com/security/CVE-2024-50093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: intel: int340x: processor: Fix warning during module unload The processor_thermal driver uses pcim_device_enable() to enable a PCI device, which means the device will be automatically disabled on driver detach. Thus there is no need to call pci_disable_device() again on it. With recent PCI device resource management improvements, e.g. commit f748a07a0b64 (\"PCI: Remove legacy pcim_release()\"), this problem is exposed and triggers the warining below. [ 224.010735] proc_thermal_pci 0000:00:04.0: disabling already-disabled device [ 224.010747] WARNING: CPU: 8 PID: 4442 at drivers/pci/pci.c:2250 pci_disable_device+0xe5/0x100 ... [ 224.010844] Call Trace: [ 224.010845] [ 224.010847] ? show_regs+0x6d/0x80 [ 224.010851] ? __warn+0x8c/0x140 [ 224.010854] ? pci_disable_device+0xe5/0x100 [ 224.010856] ? report_bug+0x1c9/0x1e0 [ 224.010859] ? handle_bug+0x46/0x80 [ 224.010862] ? exc_invalid_op+0x1d/0x80 [ 224.010863] ? asm_exc_invalid_op+0x1f/0x30 [ 224.010867] ? pci_disable_device+0xe5/0x100 [ 224.010869] ? pci_disable_device+0xe5/0x100 [ 224.010871] ? kfree+0x21a/0x2b0 [ 224.010873] pcim_disable_device+0x20/0x30 [ 224.010875] devm_action_release+0x16/0x20 [ 224.010878] release_nodes+0x47/0xc0 [ 224.010880] devres_release_all+0x9f/0xe0 [ 224.010883] device_unbind_cleanup+0x12/0x80 [ 224.010885] device_release_driver_internal+0x1ca/0x210 [ 224.010887] driver_detach+0x4e/0xa0 [ 224.010889] bus_remove_driver+0x6f/0xf0 [ 224.010890] driver_unregister+0x35/0x60 [ 224.010892] pci_unregister_driver+0x44/0x90 [ 224.010894] proc_thermal_pci_driver_exit+0x14/0x5f0 [processor_thermal_device_pci] ... [ 224.010921] ---[ end trace 0000000000000000 ]--- Remove the excess pci_disable_device() calls. [ rjw: Subject and changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50043", "url": "https://ubuntu.com/security/CVE-2024-50043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix possible badness in FREE_STATEID When multiple FREE_STATEIDs are sent for the same delegation stateid, it can lead to a possible either use-after-free or counter refcount underflow errors. In nfsd4_free_stateid() under the client lock we find a delegation stateid, however the code drops the lock before calling nfs4_put_stid(), that allows another FREE_STATE to find the stateid again. The first one will proceed to then free the stateid which leads to either use-after-free or decrementing already zeroed counter.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50044", "url": "https://ubuntu.com/security/CVE-2024-50044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change rfcomm_sk_state_change attempts to use sock_lock so it must never be called with it locked but rfcomm_sock_ioctl always attempt to lock it causing the following trace: ====================================================== WARNING: possible circular locking dependency detected 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Not tainted ------------------------------------------------------ syz-executor386/5093 is trying to acquire lock: ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1671 [inline] ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73 but task is already holding lock: ffff88807badfd28 (&d->lock){+.+.}-{3:3}, at: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50045", "url": "https://ubuntu.com/security/CVE-2024-50045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: br_netfilter: fix panic with metadata_dst skb Fix a kernel panic in the br_netfilter module when sending untagged traffic via a VxLAN device. This happens during the check for fragmentation in br_nf_dev_queue_xmit. It is dependent on: 1) the br_netfilter module being loaded; 2) net.bridge.bridge-nf-call-iptables set to 1; 3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port; 4) untagged frames with size higher than the VxLAN MTU forwarded/flooded When forwarding the untagged packet to the VxLAN bridge port, before the netfilter hooks are called, br_handle_egress_vlan_tunnel is called and changes the skb_dst to the tunnel dst. The tunnel_dst is a metadata type of dst, i.e., skb_valid_dst(skb) is false, and metadata->dst.dev is NULL. Then in the br_netfilter hooks, in br_nf_dev_queue_xmit, there's a check for frames that needs to be fragmented: frames with higher MTU than the VxLAN device end up calling br_nf_ip_fragment, which in turns call ip_skb_dst_mtu. The ip_dst_mtu tries to use the skb_dst(skb) as if it was a valid dst with valid dst->dev, thus the crash. This case was never supported in the first place, so drop the packet instead. PING 10.0.0.2 (10.0.0.2) from 0.0.0.0 h1-eth0: 2000(2028) bytes of data. [ 176.291791] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000110 [ 176.292101] Mem abort info: [ 176.292184] ESR = 0x0000000096000004 [ 176.292322] EC = 0x25: DABT (current EL), IL = 32 bits [ 176.292530] SET = 0, FnV = 0 [ 176.292709] EA = 0, S1PTW = 0 [ 176.292862] FSC = 0x04: level 0 translation fault [ 176.293013] Data abort info: [ 176.293104] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 176.293488] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 176.293787] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 176.293995] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043ef5000 [ 176.294166] [0000000000000110] pgd=0000000000000000, p4d=0000000000000000 [ 176.294827] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 176.295252] Modules linked in: vxlan ip6_udp_tunnel udp_tunnel veth br_netfilter bridge stp llc ipv6 crct10dif_ce [ 176.295923] CPU: 0 PID: 188 Comm: ping Not tainted 6.8.0-rc3-g5b3fbd61b9d1 #2 [ 176.296314] Hardware name: linux,dummy-virt (DT) [ 176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 176.296808] pc : br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.297382] lr : br_nf_dev_queue_xmit+0x2ac/0x4ec [br_netfilter] [ 176.297636] sp : ffff800080003630 [ 176.297743] x29: ffff800080003630 x28: 0000000000000008 x27: ffff6828c49ad9f8 [ 176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24: 00000000000003e8 [ 176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21: ffff6828c3b16d28 [ 176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18: 0000000000000014 [ 176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15: 0000000095744632 [ 176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12: ffffb7e137926a70 [ 176.299574] x11: 0000000000000001 x10: ffff6828c3f1c898 x9 : 0000000000000000 [ 176.300049] x8 : ffff6828c49bf070 x7 : 0008460f18d5f20e x6 : f20e0100bebafeca [ 176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 : 0000000000000000 [ 176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 : ffff6828c7f918f0 [ 176.300889] Call trace: [ 176.301123] br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.301411] br_nf_post_routing+0x2a8/0x3e4 [br_netfilter] [ 176.301703] nf_hook_slow+0x48/0x124 [ 176.302060] br_forward_finish+0xc8/0xe8 [bridge] [ 176.302371] br_nf_hook_thresh+0x124/0x134 [br_netfilter] [ 176.302605] br_nf_forward_finish+0x118/0x22c [br_netfilter] [ 176.302824] br_nf_forward_ip.part.0+0x264/0x290 [br_netfilter] [ 176.303136] br_nf_forward+0x2b8/0x4e0 [br_netfilter] [ 176.303359] nf_hook_slow+0x48/0x124 [ 176.303 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50094", "url": "https://ubuntu.com/security/CVE-2024-50094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sfc: Don't invoke xdp_do_flush() from netpoll. Yury reported a crash in the sfc driver originated from netpoll_send_udp(). The netconsole sends a message and then netpoll invokes the driver's NAPI function with a budget of zero. It is dedicated to allow driver to free TX resources, that it may have used while sending the packet. In the netpoll case the driver invokes xdp_do_flush() unconditionally, leading to crash because bpf_net_context was never assigned. Invoke xdp_do_flush() only if budget is not zero.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50188", "url": "https://ubuntu.com/security/CVE-2024-50188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: dp83869: fix memory corruption when enabling fiber When configuring the fiber port, the DP83869 PHY driver incorrectly calls linkmode_set_bit() with a bit mask (1 << 10) rather than a bit number (10). This corrupts some other memory location -- in case of arm64 the priv pointer in the same structure. Since the advertising flags are updated from supported at the end of the function the incorrect line isn't needed at all and can be removed.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50046", "url": "https://ubuntu.com/security/CVE-2024-50046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies() On the node of an NFS client, some files saved in the mountpoint of the NFS server were copied to another location of the same NFS server. Accidentally, the nfs42_complete_copies() got a NULL-pointer dereference crash with the following syslog: [232064.838881] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232064.839360] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232066.588183] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 [232066.588586] Mem abort info: [232066.588701] ESR = 0x0000000096000007 [232066.588862] EC = 0x25: DABT (current EL), IL = 32 bits [232066.589084] SET = 0, FnV = 0 [232066.589216] EA = 0, S1PTW = 0 [232066.589340] FSC = 0x07: level 3 translation fault [232066.589559] Data abort info: [232066.589683] ISV = 0, ISS = 0x00000007 [232066.589842] CM = 0, WnR = 0 [232066.589967] user pgtable: 64k pages, 48-bit VAs, pgdp=00002000956ff400 [232066.590231] [0000000000000058] pgd=08001100ae100003, p4d=08001100ae100003, pud=08001100ae100003, pmd=08001100b3c00003, pte=0000000000000000 [232066.590757] Internal error: Oops: 96000007 [#1] SMP [232066.590958] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm vhost_net vhost vhost_iotlb tap tun ipt_rpfilter xt_multiport ip_set_hash_ip ip_set_hash_net xfrm_interface xfrm6_tunnel tunnel4 tunnel6 esp4 ah4 wireguard libcurve25519_generic veth xt_addrtype xt_set nf_conntrack_netlink ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_bitmap_port ip_set_hash_ipport dummy ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs iptable_filter sch_ingress nfnetlink_cttimeout vport_gre ip_gre ip_tunnel gre vport_geneve geneve vport_vxlan vxlan ip6_udp_tunnel udp_tunnel openvswitch nf_conncount dm_round_robin dm_service_time dm_multipath xt_nat xt_MASQUERADE nft_chain_nat nf_nat xt_mark xt_conntrack xt_comment nft_compat nft_counter nf_tables nfnetlink ocfs2 ocfs2_nodemanager ocfs2_stackglue iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_ssif nbd overlay 8021q garp mrp bonding tls rfkill sunrpc ext4 mbcache jbd2 [232066.591052] vfat fat cas_cache cas_disk ses enclosure scsi_transport_sas sg acpi_ipmi ipmi_si ipmi_devintf ipmi_msghandler ip_tables vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio dm_mirror dm_region_hash dm_log dm_mod nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc fuse xfs libcrc32c ast drm_vram_helper qla2xxx drm_kms_helper syscopyarea crct10dif_ce sysfillrect ghash_ce sysimgblt sha2_ce fb_sys_fops cec sha256_arm64 sha1_ce drm_ttm_helper ttm nvme_fc igb sbsa_gwdt nvme_fabrics drm nvme_core i2c_algo_bit i40e scsi_transport_fc megaraid_sas aes_neon_bs [232066.596953] CPU: 6 PID: 4124696 Comm: 10.253.166.125- Kdump: loaded Not tainted 5.15.131-9.cl9_ocfs2.aarch64 #1 [232066.597356] Hardware name: Great Wall .\\x93\\x8e...RF6260 V5/GWMSSE2GL1T, BIOS T656FBE_V3.0.18 2024-01-06 [232066.597721] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [232066.598034] pc : nfs4_reclaim_open_state+0x220/0x800 [nfsv4] [232066.598327] lr : nfs4_reclaim_open_state+0x12c/0x800 [nfsv4] [232066.598595] sp : ffff8000f568fc70 [232066.598731] x29: ffff8000f568fc70 x28: 0000000000001000 x27: ffff21003db33000 [232066.599030] x26: ffff800005521ae0 x25: ffff0100f98fa3f0 x24: 0000000000000001 [232066.599319] x23: ffff800009920008 x22: ffff21003db33040 x21: ffff21003db33050 [232066.599628] x20: ffff410172fe9e40 x19: ffff410172fe9e00 x18: 0000000000000000 [232066.599914] x17: 0000000000000000 x16: 0000000000000004 x15: 0000000000000000 [232066.600195] x14: 0000000000000000 x13: ffff800008e685a8 x12: 00000000eac0c6e6 [232066.600498] x11: 00000000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50190", "url": "https://ubuntu.com/security/CVE-2024-50190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix memleak in ice_init_tx_topology() Fix leak of the FW blob (DDP pkg). Make ice_cfg_tx_topo() const-correct, so ice_init_tx_topology() can avoid copying whole FW blob. Copy just the topology section, and only when needed. Reuse the buffer allocated for the read of the current topology. This was found by kmemleak, with the following trace for each PF: [] kmemdup_noprof+0x1d/0x50 [] ice_init_ddp_config+0x100/0x220 [ice] [] ice_init_dev+0x6f/0x200 [ice] [] ice_init+0x29/0x560 [ice] [] ice_probe+0x21d/0x310 [ice] Constify ice_cfg_tx_topo() @buf parameter. This cascades further down to few more functions.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50180", "url": "https://ubuntu.com/security/CVE-2024-50180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: sisfb: Fix strbuf array overflow The values of the variables xres and yres are placed in strbuf. These variables are obtained from strbuf1. The strbuf1 array contains digit characters and a space if the array contains non-digit characters. Then, when executing sprintf(strbuf, \"%ux%ux8\", xres, yres); more than 16 bytes will be written to strbuf. It is suggested to increase the size of the strbuf array to 24. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06: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": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50048", "url": "https://ubuntu.com/security/CVE-2024-50048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: Fix a NULL pointer dereference issue in fbcon_putcs syzbot has found a NULL pointer dereference bug in fbcon. Here is the simplified C reproducer: struct param { \tuint8_t type; \tstruct tiocl_selection ts; }; int main() { \tstruct fb_con2fbmap con2fb; \tstruct param param; \tint fd = open(\"/dev/fb1\", 0, 0); \tcon2fb.console = 0x19; \tcon2fb.framebuffer = 0; \tioctl(fd, FBIOPUT_CON2FBMAP, &con2fb); \tparam.type = 2; \tparam.ts.xs = 0; param.ts.ys = 0; \tparam.ts.xe = 0; param.ts.ye = 0; \tparam.ts.sel_mode = 0; \tint fd1 = open(\"/dev/tty1\", O_RDWR, 0); \tioctl(fd1, TIOCLINUX, ¶m); \tcon2fb.console = 1; \tcon2fb.framebuffer = 0; \tioctl(fd, FBIOPUT_CON2FBMAP, &con2fb); \treturn 0; } After calling ioctl(fd1, TIOCLINUX, ¶m), the subsequent ioctl(fd, FBIOPUT_CON2FBMAP, &con2fb) causes the kernel to follow a different execution path: set_con2fb_map -> con2fb_init_display -> fbcon_set_disp -> redraw_screen -> hide_cursor -> clear_selection -> highlight -> invert_screen -> do_update_region -> fbcon_putcs -> ops->putcs Since ops->putcs is a NULL pointer, this leads to a kernel panic. To prevent this, we need to call set_blitting_type() within set_con2fb_map() to properly initialize ops->putcs.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50049", "url": "https://ubuntu.com/security/CVE-2024-50049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before dereferencing se [WHAT & HOW] se is null checked previously in the same function, indicating it might be null; therefore, it must be checked when used again. This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50090", "url": "https://ubuntu.com/security/CVE-2024-50090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/oa: Fix overflow in oa batch buffer By default xe_bb_create_job() appends a MI_BATCH_BUFFER_END to batch buffer, this is not a problem if batch buffer is only used once but oa reuses the batch buffer for the same metric and at each call it appends a MI_BATCH_BUFFER_END, printing the warning below and then overflowing. [ 381.072016] ------------[ cut here ]------------ [ 381.072019] xe 0000:00:02.0: [drm] Assertion `bb->len * 4 + bb_prefetch(q->gt) <= size` failed! platform: LUNARLAKE subplatform: 1 graphics: Xe2_LPG / Xe2_HPG 20.04 step B0 media: Xe2_LPM / Xe2_HPM 20.00 step B0 tile: 0 VRAM 0 B GT: 0 type 1 So here checking if batch buffer already have MI_BATCH_BUFFER_END if not append it. v2: - simply fix, suggestion from Ashutosh (cherry picked from commit 9ba0e0f30ca42a98af3689460063edfb6315718a)", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50183", "url": "https://ubuntu.com/security/CVE-2024-50183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV instance Deleting an NPIV instance requires all fabric ndlps to be released before an NPIV's resources can be torn down. Failure to release fabric ndlps beforehand opens kref imbalance race conditions. Fix by forcing the DA_ID to complete synchronously with usage of wait_queue.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50055", "url": "https://ubuntu.com/security/CVE-2024-50055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: driver core: bus: Fix double free in driver API bus_register() For bus_register(), any error which happens after kset_register() will cause that @priv are freed twice, fixed by setting @priv with NULL after the first free.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50091", "url": "https://ubuntu.com/security/CVE-2024-50091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm vdo: don't refer to dedupe_context after releasing it Clear the dedupe_context pointer in a data_vio whenever ownership of the context is lost, so that vdo can't examine it accidentally.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50056", "url": "https://ubuntu.com/security/CVE-2024-50056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: Fix ERR_PTR dereference in uvc_v4l2.c Fix potential dereferencing of ERR_PTR() in find_format_by_pix() and uvc_v4l2_enum_format(). Fix the following smatch errors: drivers/usb/gadget/function/uvc_v4l2.c:124 find_format_by_pix() error: 'fmtdesc' dereferencing possible ERR_PTR() drivers/usb/gadget/function/uvc_v4l2.c:392 uvc_v4l2_enum_format() error: 'fmtdesc' dereferencing possible ERR_PTR() Also, fix similar issue in uvc_v4l2_try_format() for potential dereferencing of ERR_PTR().", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50184", "url": "https://ubuntu.com/security/CVE-2024-50184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_pmem: Check device status before requesting flush If a pmem device is in a bad status, the driver side could wait for host ack forever in virtio_pmem_flush(), causing the system to hang. So add a status check in the beginning of virtio_pmem_flush() to return early if the device is not activated.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50057", "url": "https://ubuntu.com/security/CVE-2024-50057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: tipd: Free IRQ only if it was requested before In polling mode, if no IRQ was requested there is no need to free it. Call devm_free_irq() only if client->irq is set. This fixes the warning caused by the tps6598x module removal: WARNING: CPU: 2 PID: 333 at kernel/irq/devres.c:144 devm_free_irq+0x80/0x8c ... ... Call trace: devm_free_irq+0x80/0x8c tps6598x_remove+0x28/0x88 [tps6598x] i2c_device_remove+0x2c/0x9c device_remove+0x4c/0x80 device_release_driver_internal+0x1cc/0x228 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 i2c_del_driver+0x54/0x64 tps6598x_i2c_driver_exit+0x18/0xc3c [tps6598x] __arm64_sys_delete_module+0x184/0x264 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc8/0xe8 do_el0_svc+0x20/0x2c el0_svc+0x28/0x98 el0t_64_sync_handler+0x13c/0x158 el0t_64_sync+0x190/0x194", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50058", "url": "https://ubuntu.com/security/CVE-2024-50058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: protect uart_port_dtr_rts() in uart_shutdown() too Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part 3) added few uport == NULL checks. It added one to uart_shutdown(), so the commit assumes, uport can be NULL in there. But right after that protection, there is an unprotected \"uart_port_dtr_rts(uport, false);\" call. That is invoked only if HUPCL is set, so I assume that is the reason why we do not see lots of these reports. Or it cannot be NULL at this point at all for some reason :P. Until the above is investigated, stay on the safe side and move this dereference to the if too. I got this inconsistency from Coverity under CID 1585130. Thanks.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50181", "url": "https://ubuntu.com/security/CVE-2024-50181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: imx: Remove CLK_SET_PARENT_GATE for DRAM mux for i.MX7D For i.MX7D DRAM related mux clock, the clock source change should ONLY be done done in low level asm code without accessing DRAM, and then calling clk API to sync the HW clock status with clk tree, it should never touch real clock source switch via clk API, so CLK_SET_PARENT_GATE flag should NOT be added, otherwise, DRAM's clock parent will be disabled when DRAM is active, and system will hang.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50059", "url": "https://ubuntu.com/security/CVE-2024-50059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntb: ntb_hw_switchtec: Fix use after free vulnerability in switchtec_ntb_remove due to race condition In the switchtec_ntb_add function, it can call switchtec_ntb_init_sndev function, then &sndev->check_link_status_work is bound with check_link_status_work. switchtec_ntb_link_notification may be called to start the work. If we remove the module which will call switchtec_ntb_remove to make cleanup, it will free sndev through kfree(sndev), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | check_link_status_work switchtec_ntb_remove | kfree(sndev); | | if (sndev->link_force_down) | // use sndev Fix it by ensuring that the work is canceled before proceeding with the cleanup in switchtec_ntb_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50060", "url": "https://ubuntu.com/security/CVE-2024-50060", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring: check if we need to reschedule during overflow flush In terms of normal application usage, this list will always be empty. And if an application does overflow a bit, it'll have a few entries. However, nothing obviously prevents syzbot from running a test case that generates a ton of overflow entries, and then flushing them can take quite a while. Check for needing to reschedule while flushing, and drop our locks and do so if necessary. There's no state to maintain here as overflows always prune from head-of-list, hence it's fine to drop and reacquire the locks at the end of the loop.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50061", "url": "https://ubuntu.com/security/CVE-2024-50061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: cdns: Fix use after free vulnerability in cdns_i3c_master Driver Due to Race Condition In the cdns_i3c_master_probe function, &master->hj_work is bound with cdns_i3c_master_hj. And cdns_i3c_master_interrupt can call cnds_i3c_master_demux_ibis function to start the work. If we remove the module which will call cdns_i3c_master_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | cdns_i3c_master_hj cdns_i3c_master_remove | i3c_master_unregister(&master->base) | device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in cdns_i3c_master_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50062", "url": "https://ubuntu.com/security/CVE-2024-50062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-srv: Avoid null pointer deref during path establishment For RTRS path establishment, RTRS client initiates and completes con_num of connections. After establishing all its connections, the information is exchanged between the client and server through the info_req message. During this exchange, it is essential that all connections have been established, and the state of the RTRS srv path is CONNECTED. So add these sanity checks, to make sure we detect and abort process in error scenarios to avoid null pointer deref.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50095", "url": "https://ubuntu.com/security/CVE-2024-50095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mad: Improve handling of timed out WRs of mad agent Current timeout handler of mad agent acquires/releases mad_agent_priv lock for every timed out WRs. This causes heavy locking contention when higher no. of WRs are to be handled inside timeout handler. This leads to softlockup with below trace in some use cases where rdma-cm path is used to establish connection between peer nodes Trace: ----- BUG: soft lockup - CPU#4 stuck for 26s! [kworker/u128:3:19767] CPU: 4 PID: 19767 Comm: kworker/u128:3 Kdump: loaded Tainted: G OE ------- --- 5.14.0-427.13.1.el9_4.x86_64 #1 Hardware name: Dell Inc. PowerEdge R740/01YM03, BIOS 2.4.8 11/26/2019 Workqueue: ib_mad1 timeout_sends [ib_core] RIP: 0010:__do_softirq+0x78/0x2ac RSP: 0018:ffffb253449e4f98 EFLAGS: 00000246 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 000000000000001f RDX: 000000000000001d RSI: 000000003d1879ab RDI: fff363b66fd3a86b RBP: ffffb253604cbcd8 R08: 0000009065635f3b R09: 0000000000000000 R10: 0000000000000040 R11: ffffb253449e4ff8 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000040 FS: 0000000000000000(0000) GS:ffff8caa1fc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd9ec9db900 CR3: 0000000891934006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? __irq_exit_rcu+0xa1/0xc0 ? watchdog_timer_fn+0x1b2/0x210 ? __pfx_watchdog_timer_fn+0x10/0x10 ? __hrtimer_run_queues+0x127/0x2c0 ? hrtimer_interrupt+0xfc/0x210 ? __sysvec_apic_timer_interrupt+0x5c/0x110 ? sysvec_apic_timer_interrupt+0x37/0x90 ? asm_sysvec_apic_timer_interrupt+0x16/0x20 ? __do_softirq+0x78/0x2ac ? __do_softirq+0x60/0x2ac __irq_exit_rcu+0xa1/0xc0 sysvec_call_function_single+0x72/0x90 asm_sysvec_call_function_single+0x16/0x20 RIP: 0010:_raw_spin_unlock_irq+0x14/0x30 RSP: 0018:ffffb253604cbd88 EFLAGS: 00000247 RAX: 000000000001960d RBX: 0000000000000002 RCX: ffff8cad2a064800 RDX: 000000008020001b RSI: 0000000000000001 RDI: ffff8cad5d39f66c RBP: ffff8cad5d39f600 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8caa443e0c00 R11: ffffb253604cbcd8 R12: ffff8cacb8682538 R13: 0000000000000005 R14: ffffb253604cbd90 R15: ffff8cad5d39f66c cm_process_send_error+0x122/0x1d0 [ib_cm] timeout_sends+0x1dd/0x270 [ib_core] process_one_work+0x1e2/0x3b0 ? __pfx_worker_thread+0x10/0x10 worker_thread+0x50/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xdd/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x50 Simplified timeout handler by creating local list of timed out WRs and invoke send handler post creating the list. The new method acquires/ releases lock once to fetch the list and hence helps to reduce locking contetiong when processing higher no. of WRs", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50063", "url": "https://ubuntu.com/security/CVE-2024-50063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Prevent tail call between progs attached to different hooks bpf progs can be attached to kernel functions, and the attached functions can take different parameters or return different return values. If prog attached to one kernel function tail calls prog attached to another kernel function, the ctx access or return value verification could be bypassed. For example, if prog1 is attached to func1 which takes only 1 parameter and prog2 is attached to func2 which takes two parameters. Since verifier assumes the bpf ctx passed to prog2 is constructed based on func2's prototype, verifier allows prog2 to access the second parameter from the bpf ctx passed to it. The problem is that verifier does not prevent prog1 from passing its bpf ctx to prog2 via tail call. In this case, the bpf ctx passed to prog2 is constructed from func1 instead of func2, that is, the assumption for ctx access verification is bypassed. Another example, if BPF LSM prog1 is attached to hook file_alloc_security, and BPF LSM prog2 is attached to hook bpf_lsm_audit_rule_known. Verifier knows the return value rules for these two hooks, e.g. it is legal for bpf_lsm_audit_rule_known to return positive number 1, and it is illegal for file_alloc_security to return positive number. So verifier allows prog2 to return positive number 1, but does not allow prog1 to return positive number. The problem is that verifier does not prevent prog1 from calling prog2 via tail call. In this case, prog2's return value 1 will be used as the return value for prog1's hook file_alloc_security. That is, the return value rule is bypassed. This patch adds restriction for tail call to prevent such bypasses.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50191", "url": "https://ubuntu.com/security/CVE-2024-50191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: don't set SB_RDONLY after filesystem errors When the filesystem is mounted with errors=remount-ro, we were setting SB_RDONLY flag to stop all filesystem modifications. We knew this misses proper locking (sb->s_umount) and does not go through proper filesystem remount procedure but it has been the way this worked since early ext2 days and it was good enough for catastrophic situation damage mitigation. Recently, syzbot has found a way (see link) to trigger warnings in filesystem freezing because the code got confused by SB_RDONLY changing under its hands. Since these days we set EXT4_FLAGS_SHUTDOWN on the superblock which is enough to stop all filesystem modifications, modifying SB_RDONLY shouldn't be needed. So stop doing that.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50064", "url": "https://ubuntu.com/security/CVE-2024-50064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: zram: free secondary algorithms names We need to kfree() secondary algorithms names when reset zram device that had multi-streams, otherwise we leak memory. [senozhatsky@chromium.org: kfree(NULL) is legal] Link: https://lkml.kernel.org/r/20240917013021.868769-1-senozhatsky@chromium.org", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50065", "url": "https://ubuntu.com/security/CVE-2024-50065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Change to non-blocking allocation in ntfs_d_hash d_hash is done while under \"rcu-walk\" and should not sleep. __get_name() allocates using GFP_KERNEL, having the possibility to sleep when under memory pressure. Change the allocation to GFP_NOWAIT.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50089", "url": "https://ubuntu.com/security/CVE-2024-50089", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-49863", "url": "https://ubuntu.com/security/CVE-2024-49863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost/scsi: null-ptr-dereference in vhost_scsi_get_req() Since commit 3f8ca2e115e5 (\"vhost/scsi: Extract common handling code from control queue handler\") a null pointer dereference bug can be triggered when guest sends an SCSI AN request. In vhost_scsi_ctl_handle_vq(), `vc.target` is assigned with `&v_req.tmf.lun[1]` within a switch-case block and is then passed to vhost_scsi_get_req() which extracts `vc->req` and `tpg`. However, for a `VIRTIO_SCSI_T_AN_*` request, tpg is not required, so `vc.target` is set to NULL in this branch. Later, in vhost_scsi_get_req(), `vc->target` is dereferenced without being checked, leading to a null pointer dereference bug. This bug can be triggered from guest. When this bug occurs, the vhost_worker process is killed while holding `vq->mutex` and the corresponding tpg will remain occupied indefinitely. Below is the KASAN report: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 PID: 840 Comm: poc Not tainted 6.10.0+ #1 Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:vhost_scsi_get_req+0x165/0x3a0 Code: 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 02 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 65 30 4c 89 e2 48 c1 ea 03 <0f> b6 04 02 4c 89 e2 83 e2 07 38 d0 7f 08 84 c0 0f 85 be 01 00 00 RSP: 0018:ffff888017affb50 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffff88801b000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888017affcb8 RBP: ffff888017affb80 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff888017affc88 R14: ffff888017affd1c R15: ffff888017993000 FS: 000055556e076500(0000) GS:ffff88806b100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200027c0 CR3: 0000000010ed0004 CR4: 0000000000370ef0 Call Trace: ? show_regs+0x86/0xa0 ? die_addr+0x4b/0xd0 ? exc_general_protection+0x163/0x260 ? asm_exc_general_protection+0x27/0x30 ? vhost_scsi_get_req+0x165/0x3a0 vhost_scsi_ctl_handle_vq+0x2a4/0xca0 ? __pfx_vhost_scsi_ctl_handle_vq+0x10/0x10 ? __switch_to+0x721/0xeb0 ? __schedule+0xda5/0x5710 ? __kasan_check_write+0x14/0x30 ? _raw_spin_lock+0x82/0xf0 vhost_scsi_ctl_handle_kick+0x52/0x90 vhost_run_work_list+0x134/0x1b0 vhost_task_fn+0x121/0x350 ... ---[ end trace 0000000000000000 ]--- Let's add a check in vhost_scsi_get_req. [whitespace fixes]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49864", "url": "https://ubuntu.com/security/CVE-2024-49864", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix a race between socket set up and I/O thread creation In rxrpc_open_socket(), it sets up the socket and then sets up the I/O thread that will handle it. This is a problem, however, as there's a gap between the two phases in which a packet may come into rxrpc_encap_rcv() from the UDP packet but we oops when trying to wake the not-yet created I/O thread. As a quick fix, just make rxrpc_encap_rcv() discard the packet if there's no I/O thread yet. A better, but more intrusive fix would perhaps be to rearrange things such that the socket creation is done by the I/O thread.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49865", "url": "https://ubuntu.com/security/CVE-2024-49865", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: move xa_alloc to prevent UAF Evil user can guess the next id of the vm before the ioctl completes and then call vm destroy ioctl to trigger UAF since create ioctl is still referencing the same vm. Move the xa_alloc all the way to the end to prevent this. v2: - Rebase (cherry picked from commit dcfd3971327f3ee92765154baebbaece833d3ca9)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49955", "url": "https://ubuntu.com/security/CVE-2024-49955", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: battery: Fix possible crash when unregistering a battery hook When a battery hook returns an error when adding a new battery, then the battery hook is automatically unregistered. However the battery hook provider cannot know that, so it will later call battery_hook_unregister() on the already unregistered battery hook, resulting in a crash. Fix this by using the list head to mark already unregistered battery hooks as already being unregistered so that they can be ignored by battery_hook_unregister().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49973", "url": "https://ubuntu.com/security/CVE-2024-49973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: r8169: add tally counter fields added with RTL8125 RTL8125 added fields to the tally counter, what may result in the chip dma'ing these new fields to unallocated memory. Therefore make sure that the allocated memory area is big enough to hold all of the tally counter values, even if we use only parts of it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49974", "url": "https://ubuntu.com/security/CVE-2024-49974", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Limit the number of concurrent async COPY operations Nothing appears to limit the number of concurrent async COPY operations that clients can start. In addition, AFAICT each async COPY can copy an unlimited number of 4MB chunks, so can run for a long time. Thus IMO async COPY can become a DoS vector. Add a restriction mechanism that bounds the number of concurrent background COPY operations. Start simple and try to be fair -- this patch implements a per-namespace limit. An async COPY request that occurs while this limit is exceeded gets NFS4ERR_DELAY. The requesting client can choose to send the request again after a delay or fall back to a traditional read/write style copy. If there is need to make the mechanism more sophisticated, we can visit that in future patches.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49975", "url": "https://ubuntu.com/security/CVE-2024-49975", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uprobes: fix kernel info leak via \"[uprobes]\" vma xol_add_vma() maps the uninitialized page allocated by __create_xol_area() into userspace. On some architectures (x86) this memory is readable even without VM_READ, VM_EXEC results in the same pgprot_t as VM_EXEC|VM_READ, although this doesn't really matter, debugger can read this memory anyway.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50003", "url": "https://ubuntu.com/security/CVE-2024-50003", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix system hang while resume with TBT monitor [Why] Connected with a Thunderbolt monitor and do the suspend and the system may hang while resume. The TBT monitor HPD will be triggered during the resume procedure and call the drm_client_modeset_probe() while struct drm_connector connector->dev->master is NULL. It will mess up the pipe topology after resume. [How] Skip the TBT monitor HPD during the resume procedure because we currently will probe the connectors after resume by default. (cherry picked from commit 453f86a26945207a16b8f66aaed5962dc2b95b85)", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50173", "url": "https://ubuntu.com/security/CVE-2024-50173", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix access to uninitialized variable in tick_ctx_cleanup() The group variable can't be used to retrieve ptdev in our second loop, because it points to the previously iterated list_head, not a valid group. Get the ptdev object from the scheduler instead.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49866", "url": "https://ubuntu.com/security/CVE-2024-49866", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Fix a race during cpuhp processing There is another found exception that the \"timerlat/1\" thread was scheduled on CPU0, and lead to timer corruption finally: ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ``` After tracing the scheduling event, it was discovered that the migration of the \"timerlat/1\" thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() | To fix this, skip online processing if the CPU is already offline.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49976", "url": "https://ubuntu.com/security/CVE-2024-49976", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Drop interface_lock in stop_kthread() stop_kthread() is the offline callback for \"trace/osnoise:online\", since commit 5bfbcd1ee57b (\"tracing/timerlat: Add interface_lock around clearing of kthread in stop_kthread()\"), the following ABBA deadlock scenario is introduced: T1 | T2 [BP] | T3 [AP] osnoise_hotplug_workfn() | work_for_cpu_fn() | cpuhp_thread_fun() | _cpu_down() | osnoise_cpu_die() mutex_lock(&interface_lock) | | stop_kthread() | cpus_write_lock() | mutex_lock(&interface_lock) cpus_read_lock() | cpuhp_kick_ap() | As the interface_lock here in just for protecting the \"kthread\" field of the osn_var, use xchg() instead to fix this issue. Also use for_each_online_cpu() back in stop_per_cpu_kthreads() as it can take cpu_read_lock() again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50005", "url": "https://ubuntu.com/security/CVE-2024-50005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: Fix potential RCU dereference issue in mac802154_scan_worker In the `mac802154_scan_worker` function, the `scan_req->type` field was accessed after the RCU read-side critical section was unlocked. According to RCU usage rules, this is illegal and can lead to unpredictable behavior, such as accessing memory that has been updated or causing use-after-free issues. This possible bug was identified using a static analysis tool developed by myself, specifically designed to detect RCU-related issues. To address this, the `scan_req->type` value is now stored in a local variable `scan_req_type` while still within the RCU read-side critical section. The `scan_req_type` is then used after the RCU lock is released, ensuring that the type value is safely accessed without violating RCU rules.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50012", "url": "https://ubuntu.com/security/CVE-2024-50012", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: Avoid a bad reference count on CPU node In the parse_perf_domain function, if the call to of_parse_phandle_with_args returns an error, then the reference to the CPU device node that was acquired at the start of the function would not be properly decremented. Address this by declaring the variable with the __free(device_node) cleanup attribute.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49867", "url": "https://ubuntu.com/security/CVE-2024-49867", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: wait for fixup workers before stopping cleaner kthread during umount During unmount, at close_ctree(), we have the following steps in this order: 1) Park the cleaner kthread - this doesn't destroy the kthread, it basically halts its execution (wake ups against it work but do nothing); 2) We stop the cleaner kthread - this results in freeing the respective struct task_struct; 3) We call btrfs_stop_all_workers() which waits for any jobs running in all the work queues and then free the work queues. Syzbot reported a case where a fixup worker resulted in a crash when doing a delayed iput on its inode while attempting to wake up the cleaner at btrfs_add_delayed_iput(), because the task_struct of the cleaner kthread was already freed. This can happen during unmount because we don't wait for any fixup workers still running before we call kthread_stop() against the cleaner kthread, which stops and free all its resources. Fix this by waiting for any fixup workers at close_ctree() before we call kthread_stop() against the cleaner and run pending delayed iputs. The stack traces reported by syzbot were the following: BUG: KASAN: slab-use-after-free in __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 Read of size 8 at addr ffff8880272a8a18 by task kworker/u8:3/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.12.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: btrfs-fixup btrfs_work_helper 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 __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline] try_to_wake_up+0xb0/0x1480 kernel/sched/core.c:4154 btrfs_writepage_fixup_worker+0xc16/0xdf0 fs/btrfs/inode.c:2842 btrfs_work_helper+0x390/0xc50 fs/btrfs/async-thread.c:314 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Allocated by task 2: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:319 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345 kasan_slab_alloc include/linux/kasan.h:247 [inline] slab_post_alloc_hook mm/slub.c:4086 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4187 alloc_task_struct_node kernel/fork.c:180 [inline] dup_task_struct+0x57/0x8c0 kernel/fork.c:1107 copy_process+0x5d1/0x3d50 kernel/fork.c:2206 kernel_clone+0x223/0x880 kernel/fork.c:2787 kernel_thread+0x1bc/0x240 kernel/fork.c:2849 create_kthread kernel/kthread.c:412 [inline] kthreadd+0x60d/0x810 kernel/kthread.c:765 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Freed by task 61: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:230 [inline] slab_free_h ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49868", "url": "https://ubuntu.com/security/CVE-2024-49868", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix a NULL pointer dereference when failed to start a new trasacntion [BUG] Syzbot reported a NULL pointer dereference with the following crash: FAULT_INJECTION: forcing a failure. start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676 prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642 relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678 ... BTRFS info (device loop0): balance: ended with status: -12 Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667] RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926 Call Trace: commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496 btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430 del_balance_item fs/btrfs/volumes.c:3678 [inline] reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742 btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574 btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673 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/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [CAUSE] The allocation failure happens at the start_transaction() inside prepare_to_relocate(), and during the error handling we call unset_reloc_control(), which makes fs_info->balance_ctl to be NULL. Then we continue the error path cleanup in btrfs_balance() by calling reset_balance_state() which will call del_balance_item() to fully delete the balance item in the root tree. However during the small window between set_reloc_contrl() and unset_reloc_control(), we can have a subvolume tree update and created a reloc_root for that subvolume. Then we go into the final btrfs_commit_transaction() of del_balance_item(), and into btrfs_update_reloc_root() inside commit_fs_roots(). That function checks if fs_info->reloc_ctl is in the merge_reloc_tree stage, but since fs_info->reloc_ctl is NULL, it results a NULL pointer dereference. [FIX] Just add extra check on fs_info->reloc_ctl inside btrfs_update_reloc_root(), before checking fs_info->reloc_ctl->merge_reloc_tree. That DEAD_RELOC_TREE handling is to prevent further modification to the reloc tree during merge stage, but since there is no reloc_ctl at all, we do not need to bother that.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49869", "url": "https://ubuntu.com/security/CVE-2024-49869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: send: fix buffer overflow detection when copying path to cache entry Starting with commit c0247d289e73 (\"btrfs: send: annotate struct name_cache_entry with __counted_by()\") we annotated the variable length array \"name\" from the name_cache_entry structure with __counted_by() to improve overflow detection. However that alone was not correct, because the length of that array does not match the \"name_len\" field - it matches that plus 1 to include the NUL string terminator, so that makes a fortified kernel think there's an overflow and report a splat like this: strcpy: detected buffer overflow: 20 byte write of buffer size 19 WARNING: CPU: 3 PID: 3310 at __fortify_report+0x45/0x50 CPU: 3 UID: 0 PID: 3310 Comm: btrfs Not tainted 6.11.0-prnet #1 Hardware name: CompuLab Ltd. sbc-ihsw/Intense-PC2 (IPC2), BIOS IPC2_3.330.7 X64 03/15/2018 RIP: 0010:__fortify_report+0x45/0x50 Code: 48 8b 34 (...) RSP: 0018:ffff97ebc0d6f650 EFLAGS: 00010246 RAX: 7749924ef60fa600 RBX: ffff8bf5446a521a RCX: 0000000000000027 RDX: 00000000ffffdfff RSI: ffff97ebc0d6f548 RDI: ffff8bf84e7a1cc8 RBP: ffff8bf548574080 R08: ffffffffa8c40e10 R09: 0000000000005ffd R10: 0000000000000004 R11: ffffffffa8c70e10 R12: ffff8bf551eef400 R13: 0000000000000000 R14: 0000000000000013 R15: 00000000000003a8 FS: 00007fae144de8c0(0000) GS:ffff8bf84e780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fae14691690 CR3: 00000001027a2003 CR4: 00000000001706f0 Call Trace: ? __warn+0x12a/0x1d0 ? __fortify_report+0x45/0x50 ? report_bug+0x154/0x1c0 ? handle_bug+0x42/0x70 ? exc_invalid_op+0x1a/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? __fortify_report+0x45/0x50 __fortify_panic+0x9/0x10 __get_cur_name_and_parent+0x3bc/0x3c0 get_cur_path+0x207/0x3b0 send_extent_data+0x709/0x10d0 ? find_parent_nodes+0x22df/0x25d0 ? mas_nomem+0x13/0x90 ? mtree_insert_range+0xa5/0x110 ? btrfs_lru_cache_store+0x5f/0x1e0 ? iterate_extent_inodes+0x52d/0x5a0 process_extent+0xa96/0x11a0 ? __pfx_lookup_backref_cache+0x10/0x10 ? __pfx_store_backref_cache+0x10/0x10 ? __pfx_iterate_backrefs+0x10/0x10 ? __pfx_check_extent_item+0x10/0x10 changed_cb+0x6fa/0x930 ? tree_advance+0x362/0x390 ? memcmp_extent_buffer+0xd7/0x160 send_subvol+0xf0a/0x1520 btrfs_ioctl_send+0x106b/0x11d0 ? __pfx___clone_root_cmp_sort+0x10/0x10 _btrfs_ioctl_send+0x1ac/0x240 btrfs_ioctl+0x75b/0x850 __se_sys_ioctl+0xca/0x150 do_syscall_64+0x85/0x160 ? __count_memcg_events+0x69/0x100 ? handle_mm_fault+0x1327/0x15c0 ? __se_sys_rt_sigprocmask+0xf1/0x180 ? syscall_exit_to_user_mode+0x75/0xa0 ? do_syscall_64+0x91/0x160 ? do_user_addr_fault+0x21d/0x630 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fae145eeb4f Code: 00 48 89 (...) RSP: 002b:00007ffdf1cb09b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fae145eeb4f RDX: 00007ffdf1cb0ad0 RSI: 0000000040489426 RDI: 0000000000000004 RBP: 00000000000078fe R08: 00007fae144006c0 R09: 00007ffdf1cb0927 R10: 0000000000000008 R11: 0000000000000246 R12: 00007ffdf1cb1ce8 R13: 0000000000000003 R14: 000055c499fab2e0 R15: 0000000000000004 Fix this by not storing the NUL string terminator since we don't actually need it for name cache entries, this way \"name_len\" corresponds to the actual size of the \"name\" array. This requires marking the \"name\" array field with __nonstring and using memcpy() instead of strcpy() as recommended by the guidelines at: https://github.com/KSPP/linux/issues/90", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49870", "url": "https://ubuntu.com/security/CVE-2024-49870", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cachefiles: fix dentry leak in cachefiles_open_file() A dentry leak may be caused when a lookup cookie and a cull are concurrent: P1 | P2 ----------------------------------------------------------- cachefiles_lookup_cookie cachefiles_look_up_object lookup_one_positive_unlocked // get dentry cachefiles_cull inode->i_flags |= S_KERNEL_FILE; cachefiles_open_file cachefiles_mark_inode_in_use __cachefiles_mark_inode_in_use can_use = false if (!(inode->i_flags & S_KERNEL_FILE)) can_use = true \t return false return false // Returns an error but doesn't put dentry After that the following WARNING will be triggered when the backend folder is umounted: ================================================================== BUG: Dentry 000000008ad87947{i=7a,n=Dx_1_1.img} still in use (1) [unmount of ext4 sda] WARNING: CPU: 4 PID: 359261 at fs/dcache.c:1767 umount_check+0x5d/0x70 CPU: 4 PID: 359261 Comm: umount Not tainted 6.6.0-dirty #25 RIP: 0010:umount_check+0x5d/0x70 Call Trace: d_walk+0xda/0x2b0 do_one_tree+0x20/0x40 shrink_dcache_for_umount+0x2c/0x90 generic_shutdown_super+0x20/0x160 kill_block_super+0x1a/0x40 ext4_kill_sb+0x22/0x40 deactivate_locked_super+0x35/0x80 cleanup_mnt+0x104/0x160 ================================================================== Whether cachefiles_open_file() returns true or false, the reference count obtained by lookup_positive_unlocked() in cachefiles_look_up_object() should be released. Therefore release that reference count in cachefiles_look_up_object() to fix the above issue and simplify the code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49871", "url": "https://ubuntu.com/security/CVE-2024-49871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: adp5589-keys - fix NULL pointer dereference We register a devm action to call adp5589_clear_config() and then pass the i2c client as argument so that we can call i2c_get_clientdata() in order to get our device object. However, i2c_set_clientdata() is only being set at the end of the probe function which means that we'll get a NULL pointer dereference in case the probe function fails early.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49872", "url": "https://ubuntu.com/security/CVE-2024-49872", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/gup: fix memfd_pin_folios alloc race panic If memfd_pin_folios tries to create a hugetlb page, but someone else already did, then folio gets the value -EEXIST here: folio = memfd_alloc_folio(memfd, start_idx); if (IS_ERR(folio)) { ret = PTR_ERR(folio); if (ret != -EEXIST) goto err; then on the next trip through the \"while start_idx\" loop we panic here: if (folio) { folio_put(folio); To fix, set the folio to NULL on error.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49964", "url": "https://ubuntu.com/security/CVE-2024-49964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix memfd_pin_folios free_huge_pages leak memfd_pin_folios followed by unpin_folios fails to restore free_huge_pages if the pages were not already faulted in, because the folio refcount for pages created by memfd_alloc_folio never goes to 0. memfd_pin_folios needs another folio_put to undo the folio_try_get below: memfd_alloc_folio() alloc_hugetlb_folio_nodemask() dequeue_hugetlb_folio_nodemask() dequeue_hugetlb_folio_node_exact() folio_ref_unfreeze(folio, 1); ; adds 1 refcount folio_try_get() ; adds 1 refcount hugetlb_add_to_page_cache() ; adds 512 refcount (on x86) With the fix, after memfd_pin_folios + unpin_folios, the refcount for the (unfaulted) page is 512, which is correct, as the refcount for a faulted unpinned page is 513.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49873", "url": "https://ubuntu.com/security/CVE-2024-49873", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/filemap: fix filemap_get_folios_contig THP panic Patch series \"memfd-pin huge page fixes\". Fix multiple bugs that occur when using memfd_pin_folios with hugetlb pages and THP. The hugetlb bugs only bite when the page is not yet faulted in when memfd_pin_folios is called. The THP bug bites when the starting offset passed to memfd_pin_folios is not huge page aligned. See the commit messages for details. This patch (of 5): memfd_pin_folios on memory backed by THP panics if the requested start offset is not huge page aligned: BUG: kernel NULL pointer dereference, address: 0000000000000036 RIP: 0010:filemap_get_folios_contig+0xdf/0x290 RSP: 0018:ffffc9002092fbe8 EFLAGS: 00010202 RAX: 0000000000000002 RBX: 0000000000000002 RCX: 0000000000000002 The fault occurs here, because xas_load returns a folio with value 2: filemap_get_folios_contig() for (folio = xas_load(&xas); folio && xas.xa_index <= end; folio = xas_next(&xas)) { ... if (!folio_try_get(folio)) <-- BOOM \"2\" is an xarray sibling entry. We get it because memfd_pin_folios does not round the indices passed to filemap_get_folios_contig to huge page boundaries for THP, so we load from the middle of a huge page range see a sibling. (It does round for hugetlbfs, at the is_file_hugepages test). To fix, if the folio is a sibling, then return the next index as the starting point for the next call to filemap_get_folios_contig.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49977", "url": "https://ubuntu.com/security/CVE-2024-49977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: Fix zero-division error when disabling tc cbs The commit b8c43360f6e4 (\"net: stmmac: No need to calculate speed divider when offload is disabled\") allows the \"port_transmit_rate_kbps\" to be set to a value of 0, which is then passed to the \"div_s64\" function when tc-cbs is disabled. This leads to a zero-division error. When tc-cbs is disabled, the idleslope, sendslope, and credit values the credit values are not required to be configured. Therefore, adding a return statement after setting the txQ mode to DCB when tc-cbs is disabled would prevent a zero-division error.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49978", "url": "https://ubuntu.com/security/CVE-2024-49978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gso: fix udp gso fraglist segmentation after pull from frag_list Detect gso fraglist skbs with corrupted geometry (see below) and pass these to skb_segment instead of skb_segment_list, as the first can segment them correctly. 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 these skbs, breaking these invariants. In extreme cases they pull all data into skb linear. For UDP, this causes a NULL ptr deref in __udpv4_gso_segment_list_csum at udp_hdr(seg->next)->dest. Detect invalid geometry due to pull, by checking head_skb size. Don't just drop, as this may blackhole a destination. Convert to be able to pass to regular skb_segment.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49979", "url": "https://ubuntu.com/security/CVE-2024-49979", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gso: fix tcp fraglist segmentation after pull from frag_list Detect tcp gso fraglist skbs with corrupted geometry (see below) and pass these to skb_segment instead of skb_segment_list, as the first can segment them correctly. 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 these skbs, breaking these invariants. In extreme cases they pull all data into skb linear. For TCP, this causes a NULL ptr deref in __tcpv4_gso_segment_list_csum at tcp_hdr(seg->next). Detect invalid geometry due to pull, by checking head_skb size. Don't just drop, as this may blackhole a destination. Convert to be able to pass to regular skb_segment. Approach and description based on a patch by Willem de Bruijn.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49980", "url": "https://ubuntu.com/security/CVE-2024-49980", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vrf: revert \"vrf: Remove unnecessary RCU-bh critical section\" This reverts commit 504fc6f4f7f681d2a03aa5f68aad549d90eab853. dev_queue_xmit_nit is expected to be called with BH disabled. __dev_queue_xmit has the following: /* Disable soft irqs for various locks below. Also * stops preemption for RCU. */ rcu_read_lock_bh(); VRF must follow this invariant. The referenced commit removed this protection. Which triggered a lockdep warning: \t================================ \tWARNING: inconsistent lock state \t6.11.0 #1 Tainted: G W \t-------------------------------- \tinconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage. \tbtserver/134819 [HC0[0]:SC0[0]:HE1:SE1] takes: \tffff8882da30c118 (rlock-AF_PACKET){+.?.}-{2:2}, at: tpacket_rcv+0x863/0x3b30 \t{IN-SOFTIRQ-W} state was registered at: \t lock_acquire+0x19a/0x4f0 \t _raw_spin_lock+0x27/0x40 \t packet_rcv+0xa33/0x1320 \t __netif_receive_skb_core.constprop.0+0xcb0/0x3a90 \t __netif_receive_skb_list_core+0x2c9/0x890 \t netif_receive_skb_list_internal+0x610/0xcc0 [...] \tother info that might help us debug this: \t Possible unsafe locking scenario: \t CPU0 \t ---- \t lock(rlock-AF_PACKET); \t \t lock(rlock-AF_PACKET); \t *** DEADLOCK *** \tCall Trace: \t \t dump_stack_lvl+0x73/0xa0 \t mark_lock+0x102e/0x16b0 \t __lock_acquire+0x9ae/0x6170 \t lock_acquire+0x19a/0x4f0 \t _raw_spin_lock+0x27/0x40 \t tpacket_rcv+0x863/0x3b30 \t dev_queue_xmit_nit+0x709/0xa40 \t vrf_finish_direct+0x26e/0x340 [vrf] \t vrf_l3_out+0x5f4/0xe80 [vrf] \t __ip_local_out+0x51e/0x7a0 [...]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49981", "url": "https://ubuntu.com/security/CVE-2024-49981", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: venus: fix use after free bug in venus_remove due to race condition in venus_probe, core->work is bound with venus_sys_error_handler, which is used to handle error. The code use core->sys_err_done to make sync work. The core->work is started in venus_event_notify. If we call venus_remove, there might be an unfished work. The possible sequence is as follows: CPU0 CPU1 |venus_sys_error_handler venus_remove | hfi_destroy\t \t\t | venus_hfi_destroy\t | kfree(hdev);\t | |hfi_reinit \t\t\t\t\t |venus_hfi_queues_reinit |//use hdev Fix it by canceling the work in venus_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49956", "url": "https://ubuntu.com/security/CVE-2024-49956", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: fix double destroy_workqueue error When gfs2_fill_super() fails, destroy_workqueue() is called within gfs2_gl_hash_clear(), and the subsequent code path calls destroy_workqueue() on the same work queue again. This issue can be fixed by setting the work queue pointer to NULL after the first destroy_workqueue() call and checking for a NULL pointer before attempting to destroy the work queue again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50176", "url": "https://ubuntu.com/security/CVE-2024-50176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: k3-r5: Fix error handling when power-up failed By simply bailing out, the driver was violating its rule and internal assumptions that either both or no rproc should be initialized. E.g., this could cause the first core to be available but not the second one, leading to crashes on its shutdown later on while trying to dereference that second instance.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49982", "url": "https://ubuntu.com/security/CVE-2024-49982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: aoe: fix the potential use-after-free problem in more places For fixing CVE-2023-6270, f98364e92662 (\"aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts\") makes tx() calling dev_put() instead of doing in aoecmd_cfg_pkts(). It avoids that the tx() runs into use-after-free. Then Nicolai Stange found more places in aoe have potential use-after-free problem with tx(). e.g. revalidate(), aoecmd_ata_rw(), resend(), probe() and aoecmd_cfg_rsp(). Those functions also use aoenet_xmit() to push packet to tx queue. So they should also use dev_hold() to increase the refcnt of skb->dev. On the other hand, moving dev_put() to tx() causes that the refcnt of skb->dev be reduced to a negative value, because corresponding dev_hold() are not called in revalidate(), aoecmd_ata_rw(), resend(), probe(), and aoecmd_cfg_rsp(). This patch fixed this issue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49874", "url": "https://ubuntu.com/security/CVE-2024-49874", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: svc: Fix use after free vulnerability in svc_i3c_master Driver Due to Race Condition In the svc_i3c_master_probe function, &master->hj_work is bound with svc_i3c_master_hj_work, &master->ibi_work is bound with svc_i3c_master_ibi_work. And svc_i3c_master_ibi_work can start the hj_work, svc_i3c_master_irq_handler can start the ibi_work. If we remove the module which will call svc_i3c_master_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | svc_i3c_master_hj_work svc_i3c_master_remove | i3c_master_unregister(&master->base)| device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in svc_i3c_master_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49875", "url": "https://ubuntu.com/security/CVE-2024-49875", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: map the EBADMSG to nfserr_io to avoid warning Ext4 will throw -EBADMSG through ext4_readdir when a checksum error occurs, resulting in the following WARNING. Fix it by mapping EBADMSG to nfserr_io. nfsd_buffered_readdir iterate_dir // -EBADMSG -74 ext4_readdir // .iterate_shared ext4_dx_readdir ext4_htree_fill_tree htree_dirblock_to_tree ext4_read_dirblock __ext4_read_dirblock ext4_dirblock_csum_verify warn_no_space_for_csum __warn_no_space_for_csum return ERR_PTR(-EFSBADCRC) // -EBADMSG -74 nfserrno // WARNING [ 161.115610] ------------[ cut here ]------------ [ 161.116465] nfsd: non-standard errno: -74 [ 161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0 [ 161.118596] Modules linked in: [ 161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138 [ 161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qe mu.org 04/01/2014 [ 161.123601] RIP: 0010:nfserrno+0x9d/0xd0 [ 161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6 05 ce 2b 61 03 01 e8 99 20 d8 00 <0f> 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33 [ 161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286 [ 161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a [ 161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827 [ 161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021 [ 161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8 [ 161.135244] FS: 0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000 [ 161.136695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0 [ 161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 161.141519] PKRU: 55555554 [ 161.142076] Call Trace: [ 161.142575] ? __warn+0x9b/0x140 [ 161.143229] ? nfserrno+0x9d/0xd0 [ 161.143872] ? report_bug+0x125/0x150 [ 161.144595] ? handle_bug+0x41/0x90 [ 161.145284] ? exc_invalid_op+0x14/0x70 [ 161.146009] ? asm_exc_invalid_op+0x12/0x20 [ 161.146816] ? nfserrno+0x9d/0xd0 [ 161.147487] nfsd_buffered_readdir+0x28b/0x2b0 [ 161.148333] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.149258] ? nfsd_buffered_filldir+0xf0/0xf0 [ 161.150093] ? wait_for_concurrent_writes+0x170/0x170 [ 161.151004] ? generic_file_llseek_size+0x48/0x160 [ 161.151895] nfsd_readdir+0x132/0x190 [ 161.152606] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.153516] ? nfsd_unlink+0x380/0x380 [ 161.154256] ? override_creds+0x45/0x60 [ 161.155006] nfsd4_encode_readdir+0x21a/0x3d0 [ 161.155850] ? nfsd4_encode_readlink+0x210/0x210 [ 161.156731] ? write_bytes_to_xdr_buf+0x97/0xe0 [ 161.157598] ? __write_bytes_to_xdr_buf+0xd0/0xd0 [ 161.158494] ? lock_downgrade+0x90/0x90 [ 161.159232] ? nfs4svc_decode_voidarg+0x10/0x10 [ 161.160092] nfsd4_encode_operation+0x15a/0x440 [ 161.160959] nfsd4_proc_compound+0x718/0xe90 [ 161.161818] nfsd_dispatch+0x18e/0x2c0 [ 161.162586] svc_process_common+0x786/0xc50 [ 161.163403] ? nfsd_svc+0x380/0x380 [ 161.164137] ? svc_printk+0x160/0x160 [ 161.164846] ? svc_xprt_do_enqueue.part.0+0x365/0x380 [ 161.165808] ? nfsd_svc+0x380/0x380 [ 161.166523] ? rcu_is_watching+0x23/0x40 [ 161.167309] svc_process+0x1a5/0x200 [ 161.168019] nfsd+0x1f5/0x380 [ 161.168663] ? nfsd_shutdown_threads+0x260/0x260 [ 161.169554] kthread+0x1c4/0x210 [ 161.170224] ? kthread_insert_work_sanity_check+0x80/0x80 [ 161.171246] ret_from_fork+0x1f/0x30", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50013", "url": "https://ubuntu.com/security/CVE-2024-50013", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix memory leak in exfat_load_bitmap() If the first directory entry in the root directory is not a bitmap directory entry, 'bh' will not be released and reassigned, which will cause a memory leak.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49876", "url": "https://ubuntu.com/security/CVE-2024-49876", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: fix UAF around queue destruction We currently do stuff like queuing the final destruction step on a random system wq, which will outlive the driver instance. With bad timing we can teardown the driver with one or more work workqueue still being alive leading to various UAF splats. Add a fini step to ensure user queues are properly torn down. At this point GuC should already be nuked so queue itself should no longer be referenced from hw pov. v2 (Matt B) - Looks much safer to use a waitqueue and then just wait for the xa_array to become empty before triggering the drain. (cherry picked from commit 861108666cc0e999cffeab6aff17b662e68774e3)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49877", "url": "https://ubuntu.com/security/CVE-2024-49877", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate When doing cleanup, if flags without OCFS2_BH_READAHEAD, it may trigger NULL pointer dereference in the following ocfs2_set_buffer_uptodate() if bh is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49957", "url": "https://ubuntu.com/security/CVE-2024-49957", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix null-ptr-deref when journal load failed. During the mounting process, if journal_reset() fails because of too short journal, then lead to jbd2_journal_load() fails with NULL j_sb_buffer. Subsequently, ocfs2_journal_shutdown() calls jbd2_journal_flush()->jbd2_cleanup_journal_tail()-> __jbd2_update_log_tail()->jbd2_journal_update_sb_log_tail() ->lock_buffer(journal->j_sb_buffer), resulting in a null-pointer dereference error. To resolve this issue, we should check the JBD2_LOADED flag to ensure the journal was properly loaded. Additionally, use journal instead of osb->journal directly to simplify the code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49965", "url": "https://ubuntu.com/security/CVE-2024-49965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove unreasonable unlock in ocfs2_read_blocks Patch series \"Misc fixes for ocfs2_read_blocks\", v5. This series contains 2 fixes for ocfs2_read_blocks(). The first patch fix the issue reported by syzbot, which detects bad unlock balance in ocfs2_read_blocks(). The second patch fixes an issue reported by Heming Zhao when reviewing above fix. This patch (of 2): There was a lock release before exiting, so remove the unreasonable unlock.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49966", "url": "https://ubuntu.com/security/CVE-2024-49966", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: cancel dqi_sync_work before freeing oinfo ocfs2_global_read_info() will initialize and schedule dqi_sync_work at the end, if error occurs after successfully reading global quota, it will trigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled: ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16c This reports that there is an active delayed work when freeing oinfo in error handling, so cancel dqi_sync_work first. BTW, return status instead of -1 when .read_file_info fails.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49958", "url": "https://ubuntu.com/security/CVE-2024-49958", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reserve space for inline xattr before attaching reflink tree One of our customers reported a crash and a corrupted ocfs2 filesystem. The crash was due to the detection of corruption. Upon troubleshooting, the fsck -fn output showed the below corruption [EXTENT_LIST_FREE] Extent list in owner 33080590 claims 230 as the next free chain record, but fsck believes the largest valid value is 227. Clamp the next record value? n The stat output from the debugfs.ocfs2 showed the following corruption where the \"Next Free Rec:\" had overshot the \"Count:\" in the root metadata block. Inode: 33080590 Mode: 0640 Generation: 2619713622 (0x9c25a856) FS Generation: 904309833 (0x35e6ac49) CRC32: 00000000 ECC: 0000 Type: Regular Attr: 0x0 Flags: Valid Dynamic Features: (0x16) HasXattr InlineXattr Refcounted Extended Attributes Block: 0 Extended Attributes Inline Size: 256 User: 0 (root) Group: 0 (root) Size: 281320357888 Links: 1 Clusters: 141738 ctime: 0x66911b56 0x316edcb8 -- Fri Jul 12 06:02:30.829349048 2024 atime: 0x66911d6b 0x7f7a28d -- Fri Jul 12 06:11:23.133669517 2024 mtime: 0x66911b56 0x12ed75d7 -- Fri Jul 12 06:02:30.317552087 2024 dtime: 0x0 -- Wed Dec 31 17:00:00 1969 Refcount Block: 2777346 Last Extblk: 2886943 Orphan Slot: 0 Sub Alloc Slot: 0 Sub Alloc Bit: 14 Tree Depth: 1 Count: 227 Next Free Rec: 230 ## Offset Clusters Block# 0 0 2310 2776351 1 2310 2139 2777375 2 4449 1221 2778399 3 5670 731 2779423 4 6401 566 2780447 ....... .... ....... ....... .... ....... The issue was in the reflink workfow while reserving space for inline xattr. The problematic function is ocfs2_reflink_xattr_inline(). By the time this function is called the reflink tree is already recreated at the destination inode from the source inode. At this point, this function reserves space for inline xattrs at the destination inode without even checking if there is space at the root metadata block. It simply reduces the l_count from 243 to 227 thereby making space of 256 bytes for inline xattr whereas the inode already has extents beyond this index (in this case up to 230), thereby causing corruption. The fix for this is to reserve space for inline metadata at the destination inode before the reflink tree gets recreated. The customer has verified the fix.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49959", "url": "https://ubuntu.com/security/CVE-2024-49959", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail() to recover some journal space. But if an error occurs while executing jbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for free space right away, we try other branches, and if j_committing_transaction is NULL (i.e., the tid is 0), we will get the following complain: ============================================ JBD2: I/O error when updating journal superblock for sdd-8. __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available __jbd2_log_wait_for_space: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Call Trace: add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70 [...] ============================================ So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways. Note that this fix relies on commit 6f6a6fda2945 (\"jbd2: fix ocfs2 corrupt when updating journal superblock fails\") to make jbd2_cleanup_journal_tail return the correct error code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49878", "url": "https://ubuntu.com/security/CVE-2024-49878", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: resource: fix region_intersects() vs add_memory_driver_managed() On a system with CXL memory, the resource tree (/proc/iomem) related to CXL memory may look like something as follows. 490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem) Because drivers/dax/kmem.c calls add_memory_driver_managed() during onlining CXL memory, which makes \"System RAM (kmem)\" a descendant of \"CXL Window X\". This confuses region_intersects(), which expects all \"System RAM\" resources to be at the top level of iomem_resource. This can lead to bugs. For example, when the following command line is executed to write some memory in CXL memory range via /dev/mem, $ dd if=data of=/dev/mem bs=$((1 << 10)) seek=$((0x490000000 >> 10)) count=1 dd: error writing '/dev/mem': Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/s the command fails as expected. However, the error code is wrong. It should be \"Operation not permitted\" instead of \"Bad address\". More seriously, the /dev/mem permission checking in devmem_is_allowed() passes incorrectly. Although the accessing is prevented later because ioremap() isn't allowed to map system RAM, it is a potential security issue. During command executing, the following warning is reported in the kernel log for calling ioremap() on system RAM. ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d Call Trace: memremap+0xcb/0x184 xlate_dev_mem_ptr+0x25/0x2f write_mem+0x94/0xfb vfs_write+0x128/0x26d ksys_write+0xac/0xfe do_syscall_64+0x9a/0xfd entry_SYSCALL_64_after_hwframe+0x4b/0x53 The details of command execution process are as follows. In the above resource tree, \"System RAM\" is a descendant of \"CXL Window 0\" instead of a top level resource. So, region_intersects() will report no System RAM resources in the CXL memory region incorrectly, because it only checks the top level resources. Consequently, devmem_is_allowed() will return 1 (allow access via /dev/mem) for CXL memory region incorrectly. Fortunately, ioremap() doesn't allow to map System RAM and reject the access. So, region_intersects() needs to be fixed to work correctly with the resource tree with \"System RAM\" not at top level as above. To fix it, if we found a unmatched resource in the top level, we will continue to search matched resources in its descendant resources. So, we will not miss any matched resources in resource tree anymore. In the new implementation, an example resource tree |------------- \"CXL Window 0\" ------------| |-- \"System RAM\" --| will behave similar as the following fake resource tree for region_intersects(, IORESOURCE_SYSTEM_RAM, ), |-- \"System RAM\" --||-- \"CXL Window 0a\" --| Where \"CXL Window 0a\" is part of the original \"CXL Window 0\" that isn't covered by \"System RAM\".", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49879", "url": "https://ubuntu.com/security/CVE-2024-49879", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm: omapdrm: Add missing check for alloc_ordered_workqueue As it may return NULL pointer and cause NULL pointer dereference. Add check for the return value of alloc_ordered_workqueue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49880", "url": "https://ubuntu.com/security/CVE-2024-49880", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix off by one issue in alloc_flex_gd() Wesley reported an issue: ================================================================== EXT4-fs (dm-5): resizing filesystem from 7168 to 786432 blocks ------------[ cut here ]------------ kernel BUG at fs/ext4/resize.c:324! CPU: 9 UID: 0 PID: 3576 Comm: resize2fs Not tainted 6.11.0+ #27 RIP: 0010:ext4_resize_fs+0x1212/0x12d0 Call Trace: __ext4_ioctl+0x4e0/0x1800 ext4_ioctl+0x12/0x20 __x64_sys_ioctl+0x99/0xd0 x64_sys_call+0x1206/0x20d0 do_syscall_64+0x72/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e ================================================================== While reviewing the patch, Honza found that when adjusting resize_bg in alloc_flex_gd(), it was possible for flex_gd->resize_bg to be bigger than flexbg_size. The reproduction of the problem requires the following: o_group = flexbg_size * 2 * n; o_size = (o_group + 1) * group_size; n_group: [o_group + flexbg_size, o_group + flexbg_size * 2) o_size = (n_group + 1) * group_size; Take n=0,flexbg_size=16 as an example: last:15 |o---------------|--------------n-| o_group:0 resize to n_group:30 The corresponding reproducer is: img=test.img rm -f $img truncate -s 600M $img mkfs.ext4 -F $img -b 1024 -G 16 8M dev=`losetup -f --show $img` mkdir -p /tmp/test mount $dev /tmp/test resize2fs $dev 248M Delete the problematic plus 1 to fix the issue, and add a WARN_ON_ONCE() to prevent the issue from happening again. [ Note: another reproucer which this commit fixes is: img=test.img rm -f $img truncate -s 25MiB $img mkfs.ext4 -b 4096 -E nodiscard,lazy_itable_init=0,lazy_journal_init=0 $img truncate -s 3GiB $img dev=`losetup -f --show $img` mkdir -p /tmp/test mount $dev /tmp/test resize2fs $dev 3G umount $dev losetup -d $dev -- TYT ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49881", "url": "https://ubuntu.com/security/CVE-2024-49881", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: update orig_path in ext4_find_extent() In ext4_find_extent(), if the path is not big enough, we free it and set *orig_path to NULL. But after reallocating and successfully initializing the path, we don't update *orig_path, in which case the caller gets a valid path but a NULL ppath, and this may cause a NULL pointer dereference or a path memory leak. For example: ext4_split_extent path = *ppath = 2000 ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path = 2000); *orig_path = path = NULL; path = kcalloc() = 3000 ext4_split_extent_at(*ppath = NULL) path = *ppath; ex = path[depth].p_ext; // NULL pointer dereference! ================================================================== BUG: kernel NULL pointer dereference, address: 0000000000000010 CPU: 6 UID: 0 PID: 576 Comm: fsstress Not tainted 6.11.0-rc2-dirty #847 RIP: 0010:ext4_split_extent_at+0x6d/0x560 Call Trace: ext4_split_extent.isra.0+0xcb/0x1b0 ext4_ext_convert_to_initialized+0x168/0x6c0 ext4_ext_handle_unwritten_extents+0x325/0x4d0 ext4_ext_map_blocks+0x520/0xdb0 ext4_map_blocks+0x2b0/0x690 ext4_iomap_begin+0x20e/0x2c0 [...] ================================================================== Therefore, *orig_path is updated when the extent lookup succeeds, so that the caller can safely use path or *ppath.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50014", "url": "https://ubuntu.com/security/CVE-2024-50014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix access to uninitialised lock in fc replay path The following kernel trace can be triggered with fstest generic/629 when executed against a filesystem with fast-commit feature enabled: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x66/0x90 register_lock_class+0x759/0x7d0 __lock_acquire+0x85/0x2630 ? __find_get_block+0xb4/0x380 lock_acquire+0xd1/0x2d0 ? __ext4_journal_get_write_access+0xd5/0x160 _raw_spin_lock+0x33/0x40 ? __ext4_journal_get_write_access+0xd5/0x160 __ext4_journal_get_write_access+0xd5/0x160 ext4_reserve_inode_write+0x61/0xb0 __ext4_mark_inode_dirty+0x79/0x270 ? ext4_ext_replay_set_iblocks+0x2f8/0x450 ext4_ext_replay_set_iblocks+0x330/0x450 ext4_fc_replay+0x14c8/0x1540 ? jread+0x88/0x2e0 ? rcu_is_watching+0x11/0x40 do_one_pass+0x447/0xd00 jbd2_journal_recover+0x139/0x1b0 jbd2_journal_load+0x96/0x390 ext4_load_and_init_journal+0x253/0xd40 ext4_fill_super+0x2cc6/0x3180 ... In the replay path there's an attempt to lock sbi->s_bdev_wb_lock in function ext4_check_bdev_write_error(). Unfortunately, at this point this spinlock has not been initialized yet. Moving it's initialization to an earlier point in __ext4_fill_super() fixes this splat.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49960", "url": "https://ubuntu.com/security/CVE-2024-49960", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix timer use-after-free on failed mount Syzbot has found an ODEBUG bug in ext4_fill_super The del_timer_sync function cancels the s_err_report timer, which reminds about filesystem errors daily. We should guarantee the timer is no longer active before kfree(sbi). When filesystem mounting fails, the flow goes to failed_mount3, where an error occurs when ext4_stop_mmpd is called, causing a read I/O failure. This triggers the ext4_handle_error function that ultimately re-arms the timer, leaving the s_err_report timer active before kfree(sbi) is called. Fix the issue by canceling the s_err_report timer after calling ext4_stop_mmpd.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49882", "url": "https://ubuntu.com/security/CVE-2024-49882", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix double brelse() the buffer of the extents path In ext4_ext_try_to_merge_up(), set path[1].p_bh to NULL after it has been released, otherwise it may be released twice. An example of what triggers this is as follows: split2 map split1 |--------|-------|--------| ext4_ext_map_blocks ext4_ext_handle_unwritten_extents ext4_split_convert_extents // path->p_depth == 0 ext4_split_extent // 1. do split1 ext4_split_extent_at |ext4_ext_insert_extent | ext4_ext_create_new_leaf | ext4_ext_grow_indepth | le16_add_cpu(&neh->eh_depth, 1) | ext4_find_extent | // return -ENOMEM |// get error and try zeroout |path = ext4_find_extent | path->p_depth = 1 |ext4_ext_try_to_merge | ext4_ext_try_to_merge_up | path->p_depth = 0 | brelse(path[1].p_bh) ---> not set to NULL here |// zeroout success // 2. update path ext4_find_extent // 3. do split2 ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth le16_add_cpu(&neh->eh_depth, 1) ext4_find_extent path[0].p_bh = NULL; path->p_depth = 1 read_extent_tree_block ---> return err // path[1].p_bh is still the old value ext4_free_ext_path ext4_ext_drop_refs // path->p_depth == 1 brelse(path[1].p_bh) ---> brelse a buffer twice Finally got the following WARRNING when removing the buffer from lru: ============================================ VFS: brelse: Trying to free free buffer WARNING: CPU: 2 PID: 72 at fs/buffer.c:1241 __brelse+0x58/0x90 CPU: 2 PID: 72 Comm: kworker/u19:1 Not tainted 6.9.0-dirty #716 RIP: 0010:__brelse+0x58/0x90 Call Trace: __find_get_block+0x6e7/0x810 bdev_getblk+0x2b/0x480 __ext4_get_inode_loc+0x48a/0x1240 ext4_get_inode_loc+0xb2/0x150 ext4_reserve_inode_write+0xb7/0x230 __ext4_mark_inode_dirty+0x144/0x6a0 ext4_ext_insert_extent+0x9c8/0x3230 ext4_ext_map_blocks+0xf45/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] ============================================", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49883", "url": "https://ubuntu.com/security/CVE-2024-49883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: aovid use-after-free in ext4_ext_insert_extent() As Ojaswin mentioned in Link, in ext4_ext_insert_extent(), if the path is reallocated in ext4_ext_create_new_leaf(), we'll use the stale path and cause UAF. Below is a sample trace with dummy values: ext4_ext_insert_extent path = *ppath = 2000 ext4_ext_create_new_leaf(ppath) ext4_find_extent(ppath) path = *ppath = 2000 if (depth > path[0].p_maxdepth) kfree(path = 2000); *ppath = path = NULL; path = kcalloc() = 3000 *ppath = 3000; return path; /* here path is still 2000, UAF! */ eh = path[depth].p_hdr ================================================================== BUG: KASAN: slab-use-after-free in ext4_ext_insert_extent+0x26d4/0x3330 Read of size 8 at addr ffff8881027bf7d0 by task kworker/u36:1/179 CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 Not tainted 6.11.0-rc2-dirty #866 Call Trace: ext4_ext_insert_extent+0x26d4/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 [...] Allocated by task 179: ext4_find_extent+0x81c/0x1f70 ext4_ext_map_blocks+0x146/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...] Freed by task 179: kfree+0xcb/0x240 ext4_find_extent+0x7c0/0x1f70 ext4_ext_insert_extent+0xa26/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...] ================================================================== So use *ppath to update the path to avoid the above problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49983", "url": "https://ubuntu.com/security/CVE-2024-49983", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-free When calling ext4_force_split_extent_at() in ext4_ext_replay_update_ex(), the 'ppath' is updated but it is the 'path' that is freed, thus potentially triggering a double-free in the following process: ext4_ext_replay_update_ex ppath = path ext4_force_split_extent_at(&ppath) ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path) ---> path First freed *orig_path = path = NULL ---> null ppath kfree(path) ---> path double-free !!! So drop the unnecessary ppath and use path directly to avoid this problem. And use ext4_find_extent() directly to update path, avoiding unnecessary memory allocation and freeing. Also, propagate the error returned by ext4_find_extent() instead of using strange error codes.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50015", "url": "https://ubuntu.com/security/CVE-2024-50015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: dax: fix overflowing extents beyond inode size when partially writing The dax_iomap_rw() does two things in each iteration: map written blocks and copy user data to blocks. If the process is killed by user(See signal handling in dax_iomap_iter()), the copied data will be returned and added on inode size, which means that the length of written extents may exceed the inode size, then fsck will fail. An example is given as: dd if=/dev/urandom of=file bs=4M count=1 dax_iomap_rw iomap_iter // round 1 ext4_iomap_begin ext4_iomap_alloc // allocate 0~2M extents(written flag) dax_iomap_iter // copy 2M data iomap_iter // round 2 iomap_iter_advance iter->pos += iter->processed // iter->pos = 2M ext4_iomap_begin ext4_iomap_alloc // allocate 2~4M extents(written flag) dax_iomap_iter fatal_signal_pending done = iter->pos - iocb->ki_pos // done = 2M ext4_handle_inode_extension ext4_update_inode_size // inode size = 2M fsck reports: Inode 13, i_size is 2097152, should be 4194304. Fix? Fix the problem by truncating extents if the written length is smaller than expected.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49884", "url": "https://ubuntu.com/security/CVE-2024-49884", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix slab-use-after-free in ext4_split_extent_at() We hit the following use-after-free: ================================================================== BUG: KASAN: slab-use-after-free in ext4_split_extent_at+0xba8/0xcc0 Read of size 2 at addr ffff88810548ed08 by task kworker/u20:0/40 CPU: 0 PID: 40 Comm: kworker/u20:0 Not tainted 6.9.0-dirty #724 Call Trace: kasan_report+0x93/0xc0 ext4_split_extent_at+0xba8/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] Allocated by task 40: __kmalloc_noprof+0x1ac/0x480 ext4_find_extent+0xf3b/0x1e70 ext4_ext_map_blocks+0x188/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] Freed by task 40: kfree+0xf1/0x2b0 ext4_find_extent+0xa71/0x1e70 ext4_ext_insert_extent+0xa22/0x3260 ext4_split_extent_at+0x3ef/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] ================================================================== The flow of issue triggering is as follows: ext4_split_extent_at path = *ppath ext4_ext_insert_extent(ppath) ext4_ext_create_new_leaf(ppath) ext4_find_extent(orig_path) path = *orig_path read_extent_tree_block // return -ENOMEM or -EIO ext4_free_ext_path(path) kfree(path) *orig_path = NULL a. If err is -ENOMEM: ext4_ext_dirty(path + path->p_depth) // path use-after-free !!! b. If err is -EIO and we have EXT_DEBUG defined: ext4_ext_show_leaf(path) eh = path[depth].p_hdr // path also use-after-free !!! So when trying to zeroout or fix the extent length, call ext4_find_extent() to update the path. In addition we use *ppath directly as an ext4_ext_show_leaf() input to avoid possible use-after-free when EXT_DEBUG is defined, and to avoid unnecessary path updates.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49885", "url": "https://ubuntu.com/security/CVE-2024-49885", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm, slub: avoid zeroing kmalloc redzone Since commit 946fa0dbf2d8 (\"mm/slub: extend redzone check to extra allocated kmalloc space than requested\"), setting orig_size treats the wasted space (object_size - orig_size) as a redzone. However with init_on_free=1 we clear the full object->size, including the redzone. Additionally we clear the object metadata, including the stored orig_size, making it zero, which makes check_object() treat the whole object as a redzone. These issues lead to the following BUG report with \"slub_debug=FUZ init_on_free=1\": [ 0.000000] ============================================================================= [ 0.000000] BUG kmalloc-8 (Not tainted): kmalloc Redzone overwritten [ 0.000000] ----------------------------------------------------------------------------- [ 0.000000] [ 0.000000] 0xffff000010032858-0xffff00001003285f @offset=2136. First byte 0x0 instead of 0xcc [ 0.000000] FIX kmalloc-8: Restoring kmalloc Redzone 0xffff000010032858-0xffff00001003285f=0xcc [ 0.000000] Slab 0xfffffdffc0400c80 objects=36 used=23 fp=0xffff000010032a18 flags=0x3fffe0000000200(workingset|node=0|zone=0|lastcpupid=0x1ffff) [ 0.000000] Object 0xffff000010032858 @offset=2136 fp=0xffff0000100328c8 [ 0.000000] [ 0.000000] Redzone ffff000010032850: cc cc cc cc cc cc cc cc ........ [ 0.000000] Object ffff000010032858: cc cc cc cc cc cc cc cc ........ [ 0.000000] Redzone ffff000010032860: cc cc cc cc cc cc cc cc ........ [ 0.000000] Padding ffff0000100328b4: 00 00 00 00 00 00 00 00 00 00 00 00 ............ [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.11.0-rc3-next-20240814-00004-g61844c55c3f4 #144 [ 0.000000] Hardware name: NXP i.MX95 19X19 board (DT) [ 0.000000] Call trace: [ 0.000000] dump_backtrace+0x90/0xe8 [ 0.000000] show_stack+0x18/0x24 [ 0.000000] dump_stack_lvl+0x74/0x8c [ 0.000000] dump_stack+0x18/0x24 [ 0.000000] print_trailer+0x150/0x218 [ 0.000000] check_object+0xe4/0x454 [ 0.000000] free_to_partial_list+0x2f8/0x5ec To address the issue, use orig_size to clear the used area. And restore the value of orig_size after clear the remaining area. When CONFIG_SLUB_DEBUG not defined, (get_orig_size()' directly returns s->object_size. So when using memset to init the area, the size can simply be orig_size, as orig_size returns object_size when CONFIG_SLUB_DEBUG not enabled. And orig_size can never be bigger than object_size.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49961", "url": "https://ubuntu.com/security/CVE-2024-49961", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: ar0521: Use cansleep version of gpiod_set_value() If we use GPIO reset from I2C port expander, we must use *_cansleep() variant of GPIO functions. This was not done in ar0521_power_on()/ar0521_power_off() functions. Let's fix that. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 11 at drivers/gpio/gpiolib.c:3496 gpiod_set_value+0x74/0x7c Modules linked in: CPU: 0 PID: 11 Comm: kworker/u16:0 Not tainted 6.10.0 #53 Hardware name: Diasom DS-RK3568-SOM-EVB (DT) Workqueue: events_unbound deferred_probe_work_func pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : gpiod_set_value+0x74/0x7c lr : ar0521_power_on+0xcc/0x290 sp : ffffff8001d7ab70 x29: ffffff8001d7ab70 x28: ffffff80027dcc90 x27: ffffff8003c82000 x26: ffffff8003ca9250 x25: ffffffc080a39c60 x24: ffffff8003ca9088 x23: ffffff8002402720 x22: ffffff8003ca9080 x21: ffffff8003ca9088 x20: 0000000000000000 x19: ffffff8001eb2a00 x18: ffffff80efeeac80 x17: 756d2d6332692f30 x16: 0000000000000000 x15: 0000000000000000 x14: ffffff8001d91d40 x13: 0000000000000016 x12: ffffffc080e98930 x11: ffffff8001eb2880 x10: 0000000000000890 x9 : ffffff8001d7a9f0 x8 : ffffff8001d92570 x7 : ffffff80efeeac80 x6 : 000000003fc6e780 x5 : ffffff8001d91c80 x4 : 0000000000000002 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000001 Call trace: gpiod_set_value+0x74/0x7c ar0521_power_on+0xcc/0x290 ...", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49985", "url": "https://ubuntu.com/security/CVE-2024-49985", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume In case there is any sort of clock controller attached to this I2C bus controller, for example Versaclock or even an AIC32x4 I2C codec, then an I2C transfer triggered from the clock controller clk_ops .prepare callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex. This is because the clock controller first grabs the prepare_lock mutex and then performs the prepare operation, including its I2C access. The I2C access resumes this I2C bus controller via .runtime_resume callback, which calls clk_prepare_enable(), which attempts to grab the prepare_lock mutex again and deadlocks. Since the clock are already prepared since probe() and unprepared in remove(), use simple clk_enable()/clk_disable() calls to enable and disable the clock on runtime suspend and resume, to avoid hitting the prepare_lock mutex.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49886", "url": "https://ubuntu.com/security/CVE-2024-49886", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bug Attaching SST PCI device to VM causes \"BUG: KASAN: slab-out-of-bounds\". kasan report: [ 19.411889] ================================================================== [ 19.413702] BUG: KASAN: slab-out-of-bounds in _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.415634] Read of size 8 at addr ffff888829e65200 by task cpuhp/16/113 [ 19.417368] [ 19.418627] CPU: 16 PID: 113 Comm: cpuhp/16 Tainted: G E 6.9.0 #10 [ 19.420435] Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.20192059.B64.2207280713 07/28/2022 [ 19.422687] Call Trace: [ 19.424091] [ 19.425448] dump_stack_lvl+0x5d/0x80 [ 19.426963] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.428694] print_report+0x19d/0x52e [ 19.430206] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 19.431837] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.433539] kasan_report+0xf0/0x170 [ 19.435019] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.436709] _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.438379] ? __pfx_sched_clock_cpu+0x10/0x10 [ 19.439910] isst_if_cpu_online+0x406/0x58f [isst_if_common] [ 19.441573] ? __pfx_isst_if_cpu_online+0x10/0x10 [isst_if_common] [ 19.443263] ? ttwu_queue_wakelist+0x2c1/0x360 [ 19.444797] cpuhp_invoke_callback+0x221/0xec0 [ 19.446337] cpuhp_thread_fun+0x21b/0x610 [ 19.447814] ? __pfx_cpuhp_thread_fun+0x10/0x10 [ 19.449354] smpboot_thread_fn+0x2e7/0x6e0 [ 19.450859] ? __pfx_smpboot_thread_fn+0x10/0x10 [ 19.452405] kthread+0x29c/0x350 [ 19.453817] ? __pfx_kthread+0x10/0x10 [ 19.455253] ret_from_fork+0x31/0x70 [ 19.456685] ? __pfx_kthread+0x10/0x10 [ 19.458114] ret_from_fork_asm+0x1a/0x30 [ 19.459573] [ 19.460853] [ 19.462055] Allocated by task 1198: [ 19.463410] kasan_save_stack+0x30/0x50 [ 19.464788] kasan_save_track+0x14/0x30 [ 19.466139] __kasan_kmalloc+0xaa/0xb0 [ 19.467465] __kmalloc+0x1cd/0x470 [ 19.468748] isst_if_cdev_register+0x1da/0x350 [isst_if_common] [ 19.470233] isst_if_mbox_init+0x108/0xff0 [isst_if_mbox_msr] [ 19.471670] do_one_initcall+0xa4/0x380 [ 19.472903] do_init_module+0x238/0x760 [ 19.474105] load_module+0x5239/0x6f00 [ 19.475285] init_module_from_file+0xd1/0x130 [ 19.476506] idempotent_init_module+0x23b/0x650 [ 19.477725] __x64_sys_finit_module+0xbe/0x130 [ 19.476506] idempotent_init_module+0x23b/0x650 [ 19.477725] __x64_sys_finit_module+0xbe/0x130 [ 19.478920] do_syscall_64+0x82/0x160 [ 19.480036] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 19.481292] [ 19.482205] The buggy address belongs to the object at ffff888829e65000 which belongs to the cache kmalloc-512 of size 512 [ 19.484818] The buggy address is located 0 bytes to the right of allocated 512-byte region [ffff888829e65000, ffff888829e65200) [ 19.487447] [ 19.488328] The buggy address belongs to the physical page: [ 19.489569] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888829e60c00 pfn:0x829e60 [ 19.491140] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [ 19.492466] anon flags: 0x57ffffc0000840(slab|head|node=1|zone=2|lastcpupid=0x1fffff) [ 19.493914] page_type: 0xffffffff() [ 19.494988] raw: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [ 19.496451] raw: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [ 19.497906] head: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [ 19.499379] head: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [ 19.500844] head: 0057ffffc0000003 ffffea0020a79801 ffffea0020a79848 00000000ffffffff [ 19.502316] head: 0000000800000000 0000000000000000 00000000ffffffff 0000000000000000 [ 19.503784] page dumped because: k ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49986", "url": "https://ubuntu.com/security/CVE-2024-49986", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: x86-android-tablets: Fix use after free on platform_device_register() errors x86_android_tablet_remove() frees the pdevs[] array, so it should not be used after calling x86_android_tablet_remove(). When platform_device_register() fails, store the pdevs[x] PTR_ERR() value into the local ret variable before calling x86_android_tablet_remove() to avoid using pdevs[] after it has been freed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49887", "url": "https://ubuntu.com/security/CVE-2024-49887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to don't panic system for no free segment fault injection f2fs: fix to don't panic system for no free segment fault injection syzbot reports a f2fs bug as below: F2FS-fs (loop0): inject no free segment in get_new_segment of __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3167 F2FS-fs (loop0): Stopped filesystem due to reason: 7 ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2748! CPU: 0 UID: 0 PID: 5109 Comm: syz-executor304 Not tainted 6.11.0-rc6-syzkaller-00363-g89f5e14d05b4 #0 RIP: 0010:get_new_segment fs/f2fs/segment.c:2748 [inline] RIP: 0010:new_curseg+0x1f61/0x1f70 fs/f2fs/segment.c:2836 Call Trace: __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3167 f2fs_allocate_new_section fs/f2fs/segment.c:3181 [inline] f2fs_allocate_pinning_section+0xfa/0x4e0 fs/f2fs/segment.c:3195 f2fs_expand_inode_data+0x5d6/0xbb0 fs/f2fs/file.c:1799 f2fs_fallocate+0x448/0x960 fs/f2fs/file.c:1903 vfs_fallocate+0x553/0x6c0 fs/open.c:334 do_vfs_ioctl+0x2592/0x2e50 fs/ioctl.c:886 __do_sys_ioctl fs/ioctl.c:905 [inline] __se_sys_ioctl+0x81/0x170 fs/ioctl.c:893 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: 0010:get_new_segment fs/f2fs/segment.c:2748 [inline] RIP: 0010:new_curseg+0x1f61/0x1f70 fs/f2fs/segment.c:2836 The root cause is when we inject no free segment fault into f2fs, we should not panic system, fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49888", "url": "https://ubuntu.com/security/CVE-2024-49888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix a sdiv overflow issue Zac Ecob reported a problem where a bpf program may cause kernel crash due to the following error: Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI The failure is due to the below signed divide: LLONG_MIN/-1 where LLONG_MIN equals to -9,223,372,036,854,775,808. LLONG_MIN/-1 is supposed to give a positive number 9,223,372,036,854,775,808, but it is impossible since for 64-bit system, the maximum positive number is 9,223,372,036,854,775,807. On x86_64, LLONG_MIN/-1 will cause a kernel exception. On arm64, the result for LLONG_MIN/-1 is LLONG_MIN. Further investigation found all the following sdiv/smod cases may trigger an exception when bpf program is running on x86_64 platform: - LLONG_MIN/-1 for 64bit operation - INT_MIN/-1 for 32bit operation - LLONG_MIN%-1 for 64bit operation - INT_MIN%-1 for 32bit operation where -1 can be an immediate or in a register. On arm64, there are no exceptions: - LLONG_MIN/-1 = LLONG_MIN - INT_MIN/-1 = INT_MIN - LLONG_MIN%-1 = 0 - INT_MIN%-1 = 0 where -1 can be an immediate or in a register. Insn patching is needed to handle the above cases and the patched codes produced results aligned with above arm64 result. The below are pseudo codes to handle sdiv/smod exceptions including both divisor -1 and divisor 0 and the divisor is stored in a register. sdiv: tmp = rX tmp += 1 /* [-1, 0] -> [0, 1] if tmp >(unsigned) 1 goto L2 if tmp == 0 goto L1 rY = 0 L1: rY = -rY; goto L3 L2: rY /= rX L3: smod: tmp = rX tmp += 1 /* [-1, 0] -> [0, 1] if tmp >(unsigned) 1 goto L1 if tmp == 1 (is64 ? goto L2 : goto L3) rY = 0; goto L2 L1: rY %= rX L2: goto L4 // only when !is64 L3: wY = wY // only when !is64 L4: [1] https://lore.kernel.org/bpf/tPJLTEh7S_DxFEqAI2Ji5MBSoZVg7_G-Py2iaZpAaWtM961fFTWtsnlzwvTbzBzaUzwQAoNATXKUlt0LZOFgnDcIyKCswAnAGdUF3LBrhGQ=@protonmail.com/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49987", "url": "https://ubuntu.com/security/CVE-2024-49987", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpftool: Fix undefined behavior in qsort(NULL, 0, ...) When netfilter has no entry to display, qsort is called with qsort(NULL, 0, ...). This results in undefined behavior, as UBSan reports: net.c:827:2: runtime error: null pointer passed as argument 1, which is declared to never be null Although the C standard does not explicitly state whether calling qsort with a NULL pointer when the size is 0 constitutes undefined behavior, Section 7.1.4 of the C standard (Use of library functions) mentions: \"Each of the following statements applies unless explicitly stated otherwise in the detailed descriptions that follow: If an argument to a function has an invalid value (such as a value outside the domain of the function, or a pointer outside the address space of the program, or a null pointer, or a pointer to non-modifiable storage when the corresponding parameter is not const-qualified) or a type (after promotion) not expected by a function with variable number of arguments, the behavior is undefined.\" To avoid this, add an early return when nf_link_info is NULL to prevent calling qsort with a NULL pointer.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50006", "url": "https://ubuntu.com/security/CVE-2024-50006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix i_data_sem unlock order in ext4_ind_migrate() Fuzzing reports a possible deadlock in jbd2_log_wait_commit. This issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to require synchronous updates because the file descriptor is opened with O_SYNC. This can lead to the jbd2_journal_stop() function calling jbd2_might_wait_for_commit(), potentially causing a deadlock if the EXT4_IOC_MIGRATE call races with a write(2) system call. This problem only arises when CONFIG_PROVE_LOCKING is enabled. In this case, the jbd2_might_wait_for_commit macro locks jbd2_handle in the jbd2_journal_stop function while i_data_sem is locked. This triggers lockdep because the jbd2_journal_start function might also lock the same jbd2_handle simultaneously. Found by Linux Verification Center (linuxtesting.org) with syzkaller. Rule: add", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49889", "url": "https://ubuntu.com/security/CVE-2024-49889", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid use-after-free in ext4_ext_show_leaf() In ext4_find_extent(), path may be freed by error or be reallocated, so using a previously saved *ppath may have been freed and thus may trigger use-after-free, as follows: ext4_split_extent path = *ppath; ext4_split_extent_at(ppath) path = ext4_find_extent(ppath) ext4_split_extent_at(ppath) // ext4_find_extent fails to free path // but zeroout succeeds ext4_ext_show_leaf(inode, path) eh = path[depth].p_hdr // path use-after-free !!! Similar to ext4_split_extent_at(), we use *ppath directly as an input to ext4_ext_show_leaf(). Fix a spelling error by the way. Same problem in ext4_ext_handle_unwritten_extents(). Since 'path' is only used in ext4_ext_show_leaf(), remove 'path' and use *ppath directly. This issue is triggered only when EXT_DEBUG is defined and therefore does not affect functionality.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49968", "url": "https://ubuntu.com/security/CVE-2024-49968", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: filesystems without casefold feature cannot be mounted with siphash When mounting the ext4 filesystem, if the default hash version is set to DX_HASH_SIPHASH but the casefold feature is not set, exit the mounting.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49988", "url": "https://ubuntu.com/security/CVE-2024-49988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: add refcnt to ksmbd_conn struct When sending an oplock break request, opinfo->conn is used, But freed ->conn can be used on multichannel. This patch add a reference count to the ksmbd_conn struct so that it can be freed when it is no longer used.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49890", "url": "https://ubuntu.com/security/CVE-2024-49890", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: ensure the fw_info is not null before using it This resolves the dereference null return value warning reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49891", "url": "https://ubuntu.com/security/CVE-2024-49891", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata paths When the HBA is undergoing a reset or is handling an errata event, NULL ptr dereference crashes may occur in routines such as lpfc_sli_flush_io_rings(), lpfc_dev_loss_tmo_callbk(), or lpfc_abort_handler(). Add NULL ptr checks before dereferencing hdwq pointers that may have been freed due to operations colliding with a reset or errata event handler.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49892", "url": "https://ubuntu.com/security/CVE-2024-49892", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize get_bytes_per_element's default to 1 Variables, used as denominators and maybe not assigned to other values, should not be 0. bytes_per_element_y & bytes_per_element_c are initialized by get_bytes_per_element() which should never return 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50016", "url": "https://ubuntu.com/security/CVE-2024-50016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Avoid overflow assignment in link_dp_cts sampling_rate is an uint8_t but is assigned an unsigned int, and thus it can overflow. As a result, sampling_rate is changed to uint32_t. Similarly, LINK_QUAL_PATTERN_SET has a size of 2 bits, and it should only be assigned to a value less or equal than 4. This fixes 2 INTEGER_OVERFLOW issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49893", "url": "https://ubuntu.com/security/CVE-2024-49893", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check stream_status before it is used [WHAT & HOW] dc_state_get_stream_status can return null, and therefore null must be checked before stream_status is used. This fixes 1 NULL_RETURNS issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49969", "url": "https://ubuntu.com/security/CVE-2024-49969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 color transformation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_hw_format` function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:180 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:181 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:182 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49970", "url": "https://ubuntu.com/security/CVE-2024-49970", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Implement bounds check for stream encoder creation in DCN401 'stream_enc_regs' array is an array of dcn10_stream_enc_registers structures. The array is initialized with four elements, corresponding to the four calls to stream_enc_regs() in the array initializer. This means that valid indices for this array are 0, 1, 2, and 3. The error message 'stream_enc_regs' 4 <= 5 below, is indicating that there is an attempt to access this array with an index of 5, which is out of bounds. This could lead to undefined behavior Here, eng_id is used as an index to access the stream_enc_regs array. If eng_id is 5, this would result in an out-of-bounds access on the stream_enc_regs array. Thus fixing Buffer overflow error in dcn401_stream_encoder_create Found by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn401/dcn401_resource.c:1209 dcn401_stream_encoder_create() error: buffer overflow 'stream_enc_regs' 4 <= 5", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49894", "url": "https://ubuntu.com/security/CVE-2024-49894", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in degamma hardware format translation Fixes index out of bounds issue in `cm_helper_translate_curve_to_degamma_hw_format` function. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49895", "url": "https://ubuntu.com/security/CVE-2024-49895", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format translation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_degamma_hw_format` function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:338 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:339 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:340 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49971", "url": "https://ubuntu.com/security/CVE-2024-49971", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Increase array size of dummy_boolean [WHY] dml2_core_shared_mode_support and dml_core_mode_support access the third element of dummy_boolean, i.e. hw_debug5 = &s->dummy_boolean[2], when dummy_boolean has size of 2. Any assignment to hw_debug5 causes an OVERRUN. [HOW] Increase dummy_boolean's array size to 3. This fixes 2 OVERRUN issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49972", "url": "https://ubuntu.com/security/CVE-2024-49972", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Deallocate DML memory if allocation fails [Why] When DC state create DML memory allocation fails, memory is not deallocated subsequently, resulting in uninitialized structure that is not NULL. [How] Deallocate memory if DML memory allocation fails.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49896", "url": "https://ubuntu.com/security/CVE-2024-49896", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check stream before comparing them [WHAT & HOW] amdgpu_dm can pass a null stream to dc_is_stream_unchanged. It is necessary to check for null before dereferencing them. This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49897", "url": "https://ubuntu.com/security/CVE-2024-49897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check phantom_stream before it is used dcn32_enable_phantom_stream can return null, so returned value must be checked before used. This fixes 1 NULL_RETURNS issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49898", "url": "https://ubuntu.com/security/CVE-2024-49898", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null-initialized variables [WHAT & HOW] drr_timing and subvp_pipe are initialized to null and they are not always assigned new values. It is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49899", "url": "https://ubuntu.com/security/CVE-2024-49899", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize denominators' default to 1 [WHAT & HOW] Variables used as denominators and maybe not assigned to other values, should not be 0. Change their default to 1 so they are never 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49900", "url": "https://ubuntu.com/security/CVE-2024-49900", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uninit-value access of new_ea in ea_buffer syzbot reports that lzo1x_1_do_compress is using uninit-value: ===================================================== BUG: KMSAN: uninit-value in lzo1x_1_do_compress+0x19f9/0x2510 lib/lzo/lzo1x_compress.c:178 ... Uninit was stored to memory at: ea_put fs/jfs/xattr.c:639 [inline] ... Local variable ea_buf created at: __jfs_setxattr+0x5d/0x1ae0 fs/jfs/xattr.c:662 __jfs_xattr_set+0xe6/0x1f0 fs/jfs/xattr.c:934 ===================================================== The reason is ea_buf->new_ea is not initialized properly. Fix this by using memset to empty its content at the beginning in ea_get().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49901", "url": "https://ubuntu.com/security/CVE-2024-49901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm/adreno: Assign msm_gpu->pdev earlier to avoid nullptrs There are some cases, such as the one uncovered by Commit 46d4efcccc68 (\"drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails\") where msm_gpu_cleanup() : platform_set_drvdata(gpu->pdev, NULL); is called on gpu->pdev == NULL, as the GPU device has not been fully initialized yet. Turns out that there's more than just the aforementioned path that causes this to happen (e.g. the case when there's speedbin data in the catalog, but opp-supported-hw is missing in DT). Assigning msm_gpu->pdev earlier seems like the least painful solution to this, therefore do so. Patchwork: https://patchwork.freedesktop.org/patch/602742/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49902", "url": "https://ubuntu.com/security/CVE-2024-49902", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: check if leafidx greater than num leaves per dmap tree syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf. Shaggy: Modified sanity check to apply to control pages as well as leaf pages.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49903", "url": "https://ubuntu.com/security/CVE-2024-49903", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uaf in dbFreeBits [syzbot reported] ================================================================== BUG: KASAN: slab-use-after-free in __mutex_lock_common kernel/locking/mutex.c:587 [inline] BUG: KASAN: slab-use-after-free in __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 Read of size 8 at addr ffff8880229254b0 by task syz-executor357/5216 CPU: 0 UID: 0 PID: 5216 Comm: syz-executor357 Not tainted 6.11.0-rc3-syzkaller-00156-gd7a5aa4b3c00 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 __mutex_lock_common kernel/locking/mutex.c:587 [inline] __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 dbFreeBits+0x7ea/0xd90 fs/jfs/jfs_dmap.c:2390 dbFreeDmap fs/jfs/jfs_dmap.c:2089 [inline] dbFree+0x35b/0x680 fs/jfs/jfs_dmap.c:409 dbDiscardAG+0x8a9/0xa20 fs/jfs/jfs_dmap.c:1650 jfs_ioc_trim+0x433/0x670 fs/jfs/jfs_discard.c:100 jfs_ioctl+0x2d0/0x3e0 fs/jfs/ioctl.c:131 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 Freed by task 5218: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object+0xe0/0x150 mm/kasan/common.c:240 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2252 [inline] slab_free mm/slub.c:4473 [inline] kfree+0x149/0x360 mm/slub.c:4594 dbUnmount+0x11d/0x190 fs/jfs/jfs_dmap.c:278 jfs_mount_rw+0x4ac/0x6a0 fs/jfs/jfs_mount.c:247 jfs_remount+0x3d1/0x6b0 fs/jfs/super.c:454 reconfigure_super+0x445/0x880 fs/super.c:1083 vfs_cmd_reconfigure fs/fsopen.c:263 [inline] vfs_fsconfig_locked fs/fsopen.c:292 [inline] __do_sys_fsconfig fs/fsopen.c:473 [inline] __se_sys_fsconfig+0xb6e/0xf80 fs/fsopen.c:345 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 [Analysis] There are two paths (dbUnmount and jfs_ioc_trim) that generate race condition when accessing bmap, which leads to the occurrence of uaf. Use the lock s_umount to synchronize them, in order to avoid uaf caused by race condition.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49904", "url": "https://ubuntu.com/security/CVE-2024-49904", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add list empty check to avoid null pointer issue Add list empty check to avoid null pointer issues in some corner cases. - list_for_each_entry_safe()", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49989", "url": "https://ubuntu.com/security/CVE-2024-49989", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix double free issue during amdgpu module unload Flexible endpoints use DIGs from available inflexible endpoints, so only the encoders of inflexible links need to be freed. Otherwise, a double free issue may occur when unloading the amdgpu module. [ 279.190523] RIP: 0010:__slab_free+0x152/0x2f0 [ 279.190577] Call Trace: [ 279.190580] [ 279.190582] ? show_regs+0x69/0x80 [ 279.190590] ? die+0x3b/0x90 [ 279.190595] ? do_trap+0xc8/0xe0 [ 279.190601] ? do_error_trap+0x73/0xa0 [ 279.190605] ? __slab_free+0x152/0x2f0 [ 279.190609] ? exc_invalid_op+0x56/0x70 [ 279.190616] ? __slab_free+0x152/0x2f0 [ 279.190642] ? asm_exc_invalid_op+0x1f/0x30 [ 279.190648] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191096] ? __slab_free+0x152/0x2f0 [ 279.191102] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191469] kfree+0x260/0x2b0 [ 279.191474] dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191821] link_destroy+0xd7/0x130 [amdgpu] [ 279.192248] dc_destruct+0x90/0x270 [amdgpu] [ 279.192666] dc_destroy+0x19/0x40 [amdgpu] [ 279.193020] amdgpu_dm_fini+0x16e/0x200 [amdgpu] [ 279.193432] dm_hw_fini+0x26/0x40 [amdgpu] [ 279.193795] amdgpu_device_fini_hw+0x24c/0x400 [amdgpu] [ 279.194108] amdgpu_driver_unload_kms+0x4f/0x70 [amdgpu] [ 279.194436] amdgpu_pci_remove+0x40/0x80 [amdgpu] [ 279.194632] pci_device_remove+0x3a/0xa0 [ 279.194638] device_remove+0x40/0x70 [ 279.194642] device_release_driver_internal+0x1ad/0x210 [ 279.194647] driver_detach+0x4e/0xa0 [ 279.194650] bus_remove_driver+0x6f/0xf0 [ 279.194653] driver_unregister+0x33/0x60 [ 279.194657] pci_unregister_driver+0x44/0x90 [ 279.194662] amdgpu_exit+0x19/0x1f0 [amdgpu] [ 279.194939] __do_sys_delete_module.isra.0+0x198/0x2f0 [ 279.194946] __x64_sys_delete_module+0x16/0x20 [ 279.194950] do_syscall_64+0x58/0x120 [ 279.194954] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 279.194980] ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49905", "url": "https://ubuntu.com/security/CVE-2024-49905", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for 'afb' in amdgpu_dm_plane_handle_cursor_update (v2) This commit adds a null check for the 'afb' variable in the amdgpu_dm_plane_handle_cursor_update function. Previously, 'afb' was assumed to be null, but was used later in the code without a null check. This could potentially lead to a null pointer dereference. Changes since v1: - Moved the null check for 'afb' to the line where 'afb' is used. (Alex) Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:1298 amdgpu_dm_plane_handle_cursor_update() error: we previously assumed 'afb' could be null (see line 1252)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49906", "url": "https://ubuntu.com/security/CVE-2024-49906", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before try to access it [why & how] Change the order of the pipe_ctx->plane_state check to ensure that plane_state is not null before accessing it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49907", "url": "https://ubuntu.com/security/CVE-2024-49907", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before using dc->clk_mgr [WHY & HOW] dc->clk_mgr is null checked previously in the same function, indicating it might be null. Passing \"dc\" to \"dc->hwss.apply_idle_power_optimizations\", which dereferences null \"dc->clk_mgr\". (The function pointer resolves to \"dcn35_apply_idle_power_optimizations\".) This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49908", "url": "https://ubuntu.com/security/CVE-2024-49908", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for 'afb' in amdgpu_dm_update_cursor (v2) This commit adds a null check for the 'afb' variable in the amdgpu_dm_update_cursor function. Previously, 'afb' was assumed to be null at line 8388, but was used later in the code without a null check. This could potentially lead to a null pointer dereference. Changes since v1: - Moved the null check for 'afb' to the line where 'afb' is used. (Alex) Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:8433 amdgpu_dm_update_cursor() \terror: we previously assumed 'afb' could be null (see line 8388)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50177", "url": "https://ubuntu.com/security/CVE-2024-50177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix a UBSAN warning in DML2.1 When programming phantom pipe, since cursor_width is explicity set to 0, this causes calculation logic to trigger overflow for an unsigned int triggering the kernel's UBSAN check as below: [ 40.962845] UBSAN: shift-out-of-bounds in /tmp/amd.EfpumTkO/amd/amdgpu/../display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c:3312:34 [ 40.962849] shift exponent 4294967170 is too large for 32-bit type 'unsigned int' [ 40.962852] CPU: 1 PID: 1670 Comm: gnome-shell Tainted: G W OE 6.5.0-41-generic #41~22.04.2-Ubuntu [ 40.962854] Hardware name: Gigabyte Technology Co., Ltd. X670E AORUS PRO X/X670E AORUS PRO X, BIOS F21 01/10/2024 [ 40.962856] Call Trace: [ 40.962857] [ 40.962860] dump_stack_lvl+0x48/0x70 [ 40.962870] dump_stack+0x10/0x20 [ 40.962872] __ubsan_handle_shift_out_of_bounds+0x1ac/0x360 [ 40.962878] calculate_cursor_req_attributes.cold+0x1b/0x28 [amdgpu] [ 40.963099] dml_core_mode_support+0x6b91/0x16bc0 [amdgpu] [ 40.963327] ? srso_alias_return_thunk+0x5/0x7f [ 40.963331] ? CalculateWatermarksMALLUseAndDRAMSpeedChangeSupport+0x18b8/0x2790 [amdgpu] [ 40.963534] ? srso_alias_return_thunk+0x5/0x7f [ 40.963536] ? dml_core_mode_support+0xb3db/0x16bc0 [amdgpu] [ 40.963730] dml2_core_calcs_mode_support_ex+0x2c/0x90 [amdgpu] [ 40.963906] ? srso_alias_return_thunk+0x5/0x7f [ 40.963909] ? dml2_core_calcs_mode_support_ex+0x2c/0x90 [amdgpu] [ 40.964078] core_dcn4_mode_support+0x72/0xbf0 [amdgpu] [ 40.964247] dml2_top_optimization_perform_optimization_phase+0x1d3/0x2a0 [amdgpu] [ 40.964420] dml2_build_mode_programming+0x23d/0x750 [amdgpu] [ 40.964587] dml21_validate+0x274/0x770 [amdgpu] [ 40.964761] ? srso_alias_return_thunk+0x5/0x7f [ 40.964763] ? resource_append_dpp_pipes_for_plane_composition+0x27c/0x3b0 [amdgpu] [ 40.964942] dml2_validate+0x504/0x750 [amdgpu] [ 40.965117] ? dml21_copy+0x95/0xb0 [amdgpu] [ 40.965291] ? srso_alias_return_thunk+0x5/0x7f [ 40.965295] dcn401_validate_bandwidth+0x4e/0x70 [amdgpu] [ 40.965491] update_planes_and_stream_state+0x38d/0x5c0 [amdgpu] [ 40.965672] update_planes_and_stream_v3+0x52/0x1e0 [amdgpu] [ 40.965845] ? srso_alias_return_thunk+0x5/0x7f [ 40.965849] dc_update_planes_and_stream+0x71/0xb0 [amdgpu] Fix this by adding a guard for checking cursor width before triggering the size calculation.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49909", "url": "https://ubuntu.com/security/CVE-2024-49909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn32_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn32_set_output_transfer_func function. Previously, set_output_gamma was being checked for null, but then it was being dereferenced without any null check. This could lead to a null pointer dereference if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49910", "url": "https://ubuntu.com/security/CVE-2024-49910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn401_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn401_set_output_transfer_func function. Previously, set_output_gamma was being checked for null, but then it was being dereferenced without any null check. This could lead to a null pointer dereference if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49911", "url": "https://ubuntu.com/security/CVE-2024-49911", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn20_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn20_set_output_transfer_func function. Previously, set_output_gamma was being checked for null at line 1030, but then it was being dereferenced without any null check at line 1048. This could potentially lead to a null pointer dereference error if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma at line 1048.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49912", "url": "https://ubuntu.com/security/CVE-2024-49912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Handle null 'stream_status' in 'planes_changed_for_existing_stream' This commit adds a null check for 'stream_status' in the function 'planes_changed_for_existing_stream'. Previously, the code assumed 'stream_status' could be null, but did not handle the case where it was actually null. This could lead to a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:3784 planes_changed_for_existing_stream() error: we previously assumed 'stream_status' could be null (see line 3774)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49913", "url": "https://ubuntu.com/security/CVE-2024-49913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for top_pipe_to_program in commit_planes_for_stream This commit addresses a null pointer dereference issue in the `commit_planes_for_stream` function at line 4140. The issue could occur when `top_pipe_to_program` is null. The fix adds a check to ensure `top_pipe_to_program` is not null before accessing its stream_res. This prevents a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:4140 commit_planes_for_stream() error: we previously assumed 'top_pipe_to_program' could be null (see line 3906)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49914", "url": "https://ubuntu.com/security/CVE-2024-49914", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for pipe_ctx->plane_state in dcn20_program_pipe This commit addresses a null pointer dereference issue in the `dcn20_program_pipe` function. The issue could occur when `pipe_ctx->plane_state` is null. The fix adds a check to ensure `pipe_ctx->plane_state` is not null before accessing. This prevents a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn20/dcn20_hwseq.c:1925 dcn20_program_pipe() error: we previously assumed 'pipe_ctx->plane_state' could be null (see line 1877)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49915", "url": "https://ubuntu.com/security/CVE-2024-49915", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr in dcn32_init_hw This commit addresses a potential null pointer dereference issue in the `dcn32_init_hw` function. The issue could occur when `dc->clk_mgr` is null. The fix adds a check to ensure `dc->clk_mgr` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn32/dcn32_hwseq.c:961 dcn32_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 782)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49916", "url": "https://ubuntu.com/security/CVE-2024-49916", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in dcn401_init_hw This commit addresses a potential null pointer dereference issue in the `dcn401_init_hw` function. The issue could occur when `dc->clk_mgr` or `dc->clk_mgr->funcs` is null. The fix adds a check to ensure `dc->clk_mgr` and `dc->clk_mgr->funcs` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn401/dcn401_hwseq.c:416 dcn401_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 225)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49917", "url": "https://ubuntu.com/security/CVE-2024-49917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in dcn30_init_hw This commit addresses a potential null pointer dereference issue in the `dcn30_init_hw` function. The issue could occur when `dc->clk_mgr` or `dc->clk_mgr->funcs` is null. The fix adds a check to ensure `dc->clk_mgr` and `dc->clk_mgr->funcs` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:789 dcn30_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 628)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49918", "url": "https://ubuntu.com/security/CVE-2024-49918", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for head_pipe in dcn32_acquire_idle_pipe_for_head_pipe_in_layer This commit addresses a potential null pointer dereference issue in the `dcn32_acquire_idle_pipe_for_head_pipe_in_layer` function. The issue could occur when `head_pipe` is null. The fix adds a check to ensure `head_pipe` is not null before asserting it. If `head_pipe` is null, the function returns NULL to prevent a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn32/dcn32_resource.c:2690 dcn32_acquire_idle_pipe_for_head_pipe_in_layer() error: we previously assumed 'head_pipe' could be null (see line 2681)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49919", "url": "https://ubuntu.com/security/CVE-2024-49919", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for head_pipe in dcn201_acquire_free_pipe_for_layer This commit addresses a potential null pointer dereference issue in the `dcn201_acquire_free_pipe_for_layer` function. The issue could occur when `head_pipe` is null. The fix adds a check to ensure `head_pipe` is not null before asserting it. If `head_pipe` is null, the function returns NULL to prevent a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn201/dcn201_resource.c:1016 dcn201_acquire_free_pipe_for_layer() error: we previously assumed 'head_pipe' could be null (see line 1010)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49991", "url": "https://ubuntu.com/security/CVE-2024-49991", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer Pass pointer reference to amdgpu_bo_unref to clear the correct pointer, otherwise amdgpu_bo_unref clear the local variable, the original pointer not set to NULL, this could cause use-after-free bug.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49920", "url": "https://ubuntu.com/security/CVE-2024-49920", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before multiple uses [WHAT & HOW] Poniters, such as stream_enc and dc->bw_vbios, are null checked previously in the same function, so Coverity warns \"implies that stream_enc and dc->bw_vbios might be null\". They are used multiple times in the subsequent code and need to be checked. This fixes 10 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49921", "url": "https://ubuntu.com/security/CVE-2024-49921", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before used [WHAT & HOW] Poniters, such as dc->clk_mgr, are null checked previously in the same function, so Coverity warns \"implies that \"dc->clk_mgr\" might be null\". As a result, these pointers need to be checked when used again. This fixes 10 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49922", "url": "https://ubuntu.com/security/CVE-2024-49922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before using them [WHAT & HOW] These pointers are null checked previously in the same function, indicating they might be null as reported by Coverity. As a result, they need to be checked when used again. This fixes 3 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49923", "url": "https://ubuntu.com/security/CVE-2024-49923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Pass non-null to dcn20_validate_apply_pipe_split_flags [WHAT & HOW] \"dcn20_validate_apply_pipe_split_flags\" dereferences merge, and thus it cannot be a null pointer. Let's pass a valid pointer to avoid null dereference. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49992", "url": "https://ubuntu.com/security/CVE-2024-49992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/stm: Avoid use-after-free issues with crtc and plane ltdc_load() calls functions drm_crtc_init_with_planes(), drm_universal_plane_init() and drm_encoder_init(). These functions should not be called with parameters allocated with devm_kzalloc() to avoid use-after-free issues [1]. Use allocations managed by the DRM framework. Found by Linux Verification Center (linuxtesting.org). [1] https://lore.kernel.org/lkml/u366i76e3qhh3ra5oxrtngjtm2u5lterkekcz6y2jkndhuxzli@diujon4h7qwb/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49993", "url": "https://ubuntu.com/security/CVE-2024-49993", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49924", "url": "https://ubuntu.com/security/CVE-2024-49924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: pxafb: Fix possible use after free in pxafb_task() In the pxafb_probe function, it calls the pxafb_init_fbinfo function, after which &fbi->task is associated with pxafb_task. Moreover, within this pxafb_init_fbinfo function, the pxafb_blank function within the &pxafb_ops struct is capable of scheduling work. If we remove the module which will call pxafb_remove to make cleanup, it will call unregister_framebuffer function which can call do_unregister_framebuffer to free fbi->fb through put_fb_info(fb_info), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | pxafb_task pxafb_remove | unregister_framebuffer(info) | do_unregister_framebuffer(fb_info) | put_fb_info(fb_info) | // free fbi->fb | set_ctrlr_state(fbi, state) | __pxafb_lcd_power(fbi, 0) | fbi->lcd_power(on, &fbi->fb.var) | //use fbi->fb Fix it by ensuring that the work is canceled before proceeding with the cleanup in pxafb_remove. Note that only root user can remove the driver at runtime.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49925", "url": "https://ubuntu.com/security/CVE-2024-49925", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: efifb: Register sysfs groups through driver core The driver core can register and cleanup sysfs groups already. Make use of that functionality to simplify the error handling and cleanup. Also avoid a UAF race during unregistering where the sysctl attributes were usable after the info struct was freed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49926", "url": "https://ubuntu.com/security/CVE-2024-49926", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rcu-tasks: Fix access non-existent percpu rtpcp variable in rcu_tasks_need_gpcb() For kernels built with CONFIG_FORCE_NR_CPUS=y, the nr_cpu_ids is defined as NR_CPUS instead of the number of possible cpus, this will cause the following system panic: smpboot: Allowing 4 CPUs, 0 hotplug CPUs ... setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:512 nr_node_ids:1 ... BUG: unable to handle page fault for address: ffffffff9911c8c8 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 15 Comm: rcu_tasks_trace Tainted: G W 6.6.21 #1 5dc7acf91a5e8e9ac9dcfc35bee0245691283ea6 RIP: 0010:rcu_tasks_need_gpcb+0x25d/0x2c0 RSP: 0018:ffffa371c00a3e60 EFLAGS: 00010082 CR2: ffffffff9911c8c8 CR3: 000000040fa20005 CR4: 00000000001706f0 Call Trace: ? __die+0x23/0x80 ? page_fault_oops+0xa4/0x180 ? exc_page_fault+0x152/0x180 ? asm_exc_page_fault+0x26/0x40 ? rcu_tasks_need_gpcb+0x25d/0x2c0 ? __pfx_rcu_tasks_kthread+0x40/0x40 rcu_tasks_one_gp+0x69/0x180 rcu_tasks_kthread+0x94/0xc0 kthread+0xe8/0x140 ? __pfx_kthread+0x40/0x40 ret_from_fork+0x34/0x80 ? __pfx_kthread+0x40/0x40 ret_from_fork_asm+0x1b/0x80 Considering that there may be holes in the CPU numbers, use the maximum possible cpu number, instead of nr_cpu_ids, for configuring enqueue and dequeue limits. [ neeraj.upadhyay: Fix htmldocs build error reported by Stephen Rothwell ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50007", "url": "https://ubuntu.com/security/CVE-2024-50007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: asihpi: Fix potential OOB array access ASIHPI driver stores some values in the static array upon a response from the driver, and its index depends on the firmware. We shouldn't trust it blindly. This patch adds a sanity check of the array index to fit in the array size.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50017", "url": "https://ubuntu.com/security/CVE-2024-50017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm/ident_map: Use gbpages only where full GB page should be mapped. When ident_pud_init() uses only GB pages to create identity maps, large ranges of addresses not actually requested can be included in the resulting table; a 4K request will map a full GB. This can include a lot of extra address space past that requested, including areas marked reserved by the BIOS. That allows processor speculation into reserved regions, that on UV systems can cause system halts. Only use GB pages when map creation requests include the full GB page of space. Fall back to using smaller 2M pages when only portions of a GB page are included in the request. No attempt is made to coalesce mapping requests. If a request requires a map entry at the 2M (pmd) level, subsequent mapping requests within the same 1G region will also be at the pmd level, even if adjacent or overlapping such requests could have been combined to map a full GB page. Existing usage starts with larger regions and then adds smaller regions, so this should not have any great consequence.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49927", "url": "https://ubuntu.com/security/CVE-2024-49927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/ioapic: Handle allocation failures gracefully Breno observed panics when using failslab under certain conditions during runtime: can not alloc irq_pin_list (-1,0,20) Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed panic+0x4e9/0x590 mp_irqdomain_alloc+0x9ab/0xa80 irq_domain_alloc_irqs_locked+0x25d/0x8d0 __irq_domain_alloc_irqs+0x80/0x110 mp_map_pin_to_irq+0x645/0x890 acpi_register_gsi_ioapic+0xe6/0x150 hpet_open+0x313/0x480 That's a pointless panic which is a leftover of the historic IO/APIC code which panic'ed during early boot when the interrupt allocation failed. The only place which might justify panic is the PIT/HPET timer_check() code which tries to figure out whether the timer interrupt is delivered through the IO/APIC. But that code does not require to handle interrupt allocation failures. If the interrupt cannot be allocated then timer delivery fails and it either panics due to that or falls back to legacy mode. Cure this by removing the panic wrapper around __add_pin_to_irq_node() and making mp_irqdomain_alloc() aware of the failure condition and handle it as any other failure in this function gracefully.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50008", "url": "https://ubuntu.com/security/CVE-2024-50008", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_cmd_802_11_scan_ext() Replace one-element array with a flexible-array member in `struct host_cmd_ds_802_11_scan_ext`. With this, fix the following warning: elo 16 17:51:58 surfacebook kernel: ------------[ cut here ]------------ elo 16 17:51:58 surfacebook kernel: memcpy: detected field-spanning write (size 243) of single field \"ext_scan->tlv_buffer\" at drivers/net/wireless/marvell/mwifiex/scan.c:2239 (size 1) elo 16 17:51:58 surfacebook kernel: WARNING: CPU: 0 PID: 498 at drivers/net/wireless/marvell/mwifiex/scan.c:2239 mwifiex_cmd_802_11_scan_ext+0x83/0x90 [mwifiex]", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50018", "url": "https://ubuntu.com/security/CVE-2024-50018", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49928", "url": "https://ubuntu.com/security/CVE-2024-49928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: avoid reading out of bounds when loading TX power FW elements Because the loop-expression will do one more time before getting false from cond-expression, the original code copied one more entry size beyond valid region. Fix it by moving the entry copy to loop-body.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50178", "url": "https://ubuntu.com/security/CVE-2024-50178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: loongson3: Use raw_smp_processor_id() in do_service_request() Use raw_smp_processor_id() instead of plain smp_processor_id() in do_service_request(), otherwise we may get some errors with the driver enabled: BUG: using smp_processor_id() in preemptible [00000000] code: (udev-worker)/208 caller is loongson3_cpufreq_probe+0x5c/0x250 [loongson3_cpufreq]", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50009", "url": "https://ubuntu.com/security/CVE-2024-50009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: amd-pstate: add check for cpufreq_cpu_get's return value cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it and return in case of error. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49994", "url": "https://ubuntu.com/security/CVE-2024-49994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix integer overflow in BLKSECDISCARD I independently rediscovered \tcommit 22d24a544b0d49bbcbd61c8c0eaf77d3c9297155 \tblock: fix overflow in blk_ioctl_discard() but for secure erase. Same problem: \tuint64_t r[2] = {512, 18446744073709551104ULL}; \tioctl(fd, BLKSECDISCARD, r); will enter near infinite loop inside blkdev_issue_secure_erase(): \ta.out: attempt to access beyond end of device \tloop0: rw=5, sector=3399043073, nr_sectors = 1024 limit=2048 \tbio_check_eod: 3286214 callbacks suppressed", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49929", "url": "https://ubuntu.com/security/CVE-2024-49929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: avoid NULL pointer dereference iwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta pointer is not NULL. It retrieves this pointer using iwl_mvm_sta_from_mac80211, which is dereferencing the ieee80211_sta pointer. If sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL pointer. Fix this by checking the sta pointer before retrieving the mvmsta from it. If sta is not NULL, then mvmsta isn't either.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49995", "url": "https://ubuntu.com/security/CVE-2024-49995", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: guard against string buffer overrun Smatch reports that copying media_name and if_name to name_parts may overwrite the destination. .../bearer.c:166 bearer_name_validate() error: strcpy() 'media_name' too large for 'name_parts->media_name' (32 vs 16) .../bearer.c:167 bearer_name_validate() error: strcpy() 'if_name' too large for 'name_parts->if_name' (1010102 vs 16) This does seem to be the case so guard against this possibility by using strscpy() and failing if truncation occurs. Introduced by commit b97bf3fd8f6a (\"[TIPC] Initial merge\") Compile tested only.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49962", "url": "https://ubuntu.com/security/CVE-2024-49962", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in acpi_db_convert_to_package() ACPICA commit 4d4547cf13cca820ff7e0f859ba83e1a610b9fd0 ACPI_ALLOCATE_ZEROED() may fail, elements might be NULL and will cause NULL pointer dereference later. [ rjw: Subject and changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49930", "url": "https://ubuntu.com/security/CVE-2024-49930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix array out-of-bound access in SoC stats Currently, the ath11k_soc_dp_stats::hal_reo_error array is defined with a maximum size of DP_REO_DST_RING_MAX. However, the ath11k_dp_process_rx() function access ath11k_soc_dp_stats::hal_reo_error using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath11k_dp_process_rx() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49931", "url": "https://ubuntu.com/security/CVE-2024-49931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix array out-of-bound access in SoC stats Currently, the ath12k_soc_dp_stats::hal_reo_error array is defined with a maximum size of DP_REO_DST_RING_MAX. However, the ath12k_dp_rx_process() function access ath12k_soc_dp_stats::hal_reo_error using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath12k_dp_rx_process() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49932", "url": "https://ubuntu.com/security/CVE-2024-49932", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: don't readahead the relocation inode on RST On relocation we're doing readahead on the relocation inode, but if the filesystem is backed by a RAID stripe tree we can get ENOENT (e.g. due to preallocated extents not being mapped in the RST) from the lookup. But readahead doesn't handle the error and submits invalid reads to the device, causing an assertion in the scatter-gather list code: BTRFS info (device nvme1n1): balance: start -d -m -s BTRFS info (device nvme1n1): relocating block group 6480920576 flags data|raid0 BTRFS error (device nvme1n1): cannot find raid-stripe for logical [6481928192, 6481969152] devid 2, profile raid0 ------------[ cut here ]------------ kernel BUG at include/linux/scatterlist.h:115! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 1012 Comm: btrfs Not tainted 6.10.0-rc7+ #567 RIP: 0010:__blk_rq_map_sg+0x339/0x4a0 RSP: 0018:ffffc90001a43820 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffea00045d4802 RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000 RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000001000 R12: ffff8881003d10b8 R13: ffffc90001a438f0 R14: 0000000000000000 R15: 0000000000003000 FS: 00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000002cd11000 CR3: 00000001109ea001 CR4: 0000000000370eb0 Call Trace: ? __die_body.cold+0x14/0x25 ? die+0x2e/0x50 ? do_trap+0xca/0x110 ? do_error_trap+0x65/0x80 ? __blk_rq_map_sg+0x339/0x4a0 ? exc_invalid_op+0x50/0x70 ? __blk_rq_map_sg+0x339/0x4a0 ? asm_exc_invalid_op+0x1a/0x20 ? __blk_rq_map_sg+0x339/0x4a0 nvme_prep_rq.part.0+0x9d/0x770 nvme_queue_rq+0x7d/0x1e0 __blk_mq_issue_directly+0x2a/0x90 ? blk_mq_get_budget_and_tag+0x61/0x90 blk_mq_try_issue_list_directly+0x56/0xf0 blk_mq_flush_plug_list.part.0+0x52b/0x5d0 __blk_flush_plug+0xc6/0x110 blk_finish_plug+0x28/0x40 read_pages+0x160/0x1c0 page_cache_ra_unbounded+0x109/0x180 relocate_file_extent_cluster+0x611/0x6a0 ? btrfs_search_slot+0xba4/0xd20 ? balance_dirty_pages_ratelimited_flags+0x26/0xb00 relocate_data_extent.constprop.0+0x134/0x160 relocate_block_group+0x3f2/0x500 btrfs_relocate_block_group+0x250/0x430 btrfs_relocate_chunk+0x3f/0x130 btrfs_balance+0x71b/0xef0 ? kmalloc_trace_noprof+0x13b/0x280 btrfs_ioctl+0x2c2e/0x3030 ? kvfree_call_rcu+0x1e6/0x340 ? list_lru_add_obj+0x66/0x80 ? mntput_no_expire+0x3a/0x220 __x64_sys_ioctl+0x96/0xc0 do_syscall_64+0x54/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fcc04514f9b Code: Unable to access opcode bytes at 0x7fcc04514f71. RSP: 002b:00007ffeba923370 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fcc04514f9b RDX: 00007ffeba923460 RSI: 00000000c4009420 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000013 R09: 0000000000000001 R10: 00007fcc043fbba8 R11: 0000000000000246 R12: 00007ffeba924fc5 R13: 00007ffeba923460 R14: 0000000000000002 R15: 00000000004d4bb0 Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:__blk_rq_map_sg+0x339/0x4a0 RSP: 0018:ffffc90001a43820 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffea00045d4802 RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000 RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000001000 R12: ffff8881003d10b8 R13: ffffc90001a438f0 R14: 0000000000000000 R15: 0000000000003000 FS: 00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcc04514f71 CR3: 00000001109ea001 CR4: 0000000000370eb0 Kernel p ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49933", "url": "https://ubuntu.com/security/CVE-2024-49933", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk_iocost: fix more out of bound shifts Recently running UBSAN caught few out of bound shifts in the ioc_forgive_debts() function: UBSAN: shift-out-of-bounds in block/blk-iocost.c:2142:38 shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long long') ... UBSAN: shift-out-of-bounds in block/blk-iocost.c:2144:30 shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long long') ... Call Trace: dump_stack_lvl+0xca/0x130 __ubsan_handle_shift_out_of_bounds+0x22c/0x280 ? __lock_acquire+0x6441/0x7c10 ioc_timer_fn+0x6cec/0x7750 ? blk_iocost_init+0x720/0x720 ? call_timer_fn+0x5d/0x470 call_timer_fn+0xfa/0x470 ? blk_iocost_init+0x720/0x720 __run_timer_base+0x519/0x700 ... Actual impact of this issue was not identified but I propose to fix the undefined behaviour. The proposed fix to prevent those out of bound shifts consist of precalculating exponent before using it the shift operations by taking min value from the actual exponent and maximum possible number of bits.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49934", "url": "https://ubuntu.com/security/CVE-2024-49934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/inode: Prevent dump_mapping() accessing invalid dentry.d_name.name It's observed that a crash occurs during hot-remove a memory device, in which user is accessing the hugetlb. See calltrace as following: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 14045 at arch/x86/mm/fault.c:1278 do_user_addr_fault+0x2a0/0x790 Modules linked in: kmem device_dax cxl_mem cxl_pmem cxl_port cxl_pci dax_hmem dax_pmem nd_pmem cxl_acpi nd_btt cxl_core crc32c_intel nvme virtiofs fuse nvme_core nfit libnvdimm dm_multipath scsi_dh_rdac scsi_dh_emc s mirror dm_region_hash dm_log dm_mod CPU: 1 PID: 14045 Comm: daxctl Not tainted 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:do_user_addr_fault+0x2a0/0x790 Code: 48 8b 00 a8 04 0f 84 b5 fe ff ff e9 1c ff ff ff 4c 89 e9 4c 89 e2 be 01 00 00 00 bf 02 00 00 00 e8 b5 ef 24 00 e9 42 fe ff ff <0f> 0b 48 83 c4 08 4c 89 ea 48 89 ee 4c 89 e7 5b 5d 41 5c 41 5d 41 RSP: 0000:ffffc90000a575f0 EFLAGS: 00010046 RAX: ffff88800c303600 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000001000 RSI: ffffffff82504162 RDI: ffffffff824b2c36 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffc90000a57658 R13: 0000000000001000 R14: ffff88800bc2e040 R15: 0000000000000000 FS: 00007f51cb57d880(0000) GS:ffff88807fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000001000 CR3: 00000000072e2004 CR4: 00000000001706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn+0x8d/0x190 ? do_user_addr_fault+0x2a0/0x790 ? report_bug+0x1c3/0x1d0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? do_user_addr_fault+0x2a0/0x790 ? exc_page_fault+0x31/0x200 exc_page_fault+0x68/0x200 <...snip...> BUG: unable to handle page fault for address: 0000000000001000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI ---[ end trace 0000000000000000 ]--- BUG: unable to handle page fault for address: 0000000000001000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 14045 Comm: daxctl Kdump: loaded Tainted: G W 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:dentry_name+0x1f4/0x440 <...snip...> ? dentry_name+0x2fa/0x440 vsnprintf+0x1f3/0x4f0 vprintk_store+0x23a/0x540 vprintk_emit+0x6d/0x330 _printk+0x58/0x80 dump_mapping+0x10b/0x1a0 ? __pfx_free_object_rcu+0x10/0x10 __dump_page+0x26b/0x3e0 ? vprintk_emit+0xe0/0x330 ? _printk+0x58/0x80 ? dump_page+0x17/0x50 dump_page+0x17/0x50 do_migrate_range+0x2f7/0x7f0 ? do_migrate_range+0x42/0x7f0 ? offline_pages+0x2f4/0x8c0 offline_pages+0x60a/0x8c0 memory_subsys_offline+0x9f/0x1c0 ? lockdep_hardirqs_on+0x77/0x100 ? _raw_spin_unlock_irqrestore+0x38/0x60 device_offline+0xe3/0x110 state_store+0x6e/0xc0 kernfs_fop_write_iter+0x143/0x200 vfs_write+0x39f/0x560 ksys_write+0x65/0xf0 do_syscall_64+0x62/0x130 Previously, some sanity check have been done in dump_mapping() before the print facility parsing '%pd' though, it's still possible to run into an invalid dentry.d_name.name. Since dump_mapping() only needs to dump the filename only, retrieve it by itself in a safer way to prevent an unnecessary crash. Note that either retrieving the filename with '%pd' or strncpy_from_kernel_nofault(), the filename could be unreliable.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49935", "url": "https://ubuntu.com/security/CVE-2024-49935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: PAD: fix crash in exit_round_robin() The kernel occasionally crashes in cpumask_clear_cpu(), which is called within exit_round_robin(), because when executing clear_bit(nr, addr) with nr set to 0xffffffff, the address calculation may cause misalignment within the memory, leading to access to an invalid memory address. ---------- BUG: unable to handle kernel paging request at ffffffffe0740618 ... CPU: 3 PID: 2919323 Comm: acpi_pad/14 Kdump: loaded Tainted: G OE X --------- - - 4.18.0-425.19.2.el8_7.x86_64 #1 ... RIP: 0010:power_saving_thread+0x313/0x411 [acpi_pad] Code: 89 cd 48 89 d3 eb d1 48 c7 c7 55 70 72 c0 e8 64 86 b0 e4 c6 05 0d a1 02 00 01 e9 bc fd ff ff 45 89 e4 42 8b 04 a5 20 82 72 c0 48 0f b3 05 f4 9c 01 00 42 c7 04 a5 20 82 72 c0 ff ff ff ff 31 RSP: 0018:ff72a5d51fa77ec8 EFLAGS: 00010202 RAX: 00000000ffffffff RBX: ff462981e5d8cb80 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246 RBP: ff46297556959d80 R08: 0000000000000382 R09: ff46297c8d0f38d8 R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000000e R13: 0000000000000000 R14: ffffffffffffffff R15: 000000000000000e FS: 0000000000000000(0000) GS:ff46297a800c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffe0740618 CR3: 0000007e20410004 CR4: 0000000000771ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? acpi_pad_add+0x120/0x120 [acpi_pad] kthread+0x10b/0x130 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x1f/0x40 ... CR2: ffffffffe0740618 crash> dis -lr ffffffffc0726923 ... /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 114 0xffffffffc0726918 :\tmov %r12d,%r12d /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 325 0xffffffffc072691b :\tmov -0x3f8d7de0(,%r12,4),%eax /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./arch/x86/include/asm/bitops.h: 80 0xffffffffc0726923 :\tlock btr %rax,0x19cf4(%rip) # 0xffffffffc0740620 crash> px tsk_in_cpu[14] $66 = 0xffffffff crash> px 0xffffffffc072692c+0x19cf4 $99 = 0xffffffffc0740620 crash> sym 0xffffffffc0740620 ffffffffc0740620 (b) pad_busy_cpus_bits [acpi_pad] crash> px pad_busy_cpus_bits[0] $42 = 0xfffc0 ---------- To fix this, ensure that tsk_in_cpu[tsk_index] != -1 before calling cpumask_clear_cpu() in exit_round_robin(), just as it is done in round_robin_cpu(). [ rjw: Subject edit, avoid updates to the same value ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49936", "url": "https://ubuntu.com/security/CVE-2024-49936", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/xen-netback: prevent UAF in xenvif_flush_hash() During the list_for_each_entry_rcu iteration call of xenvif_flush_hash, kfree_rcu does not exist inside the rcu read critical section, so if kfree_rcu is called when the rcu grace period ends during the iteration, UAF occurs when accessing head->next after the entry becomes free. Therefore, to solve this, you need to change it to list_for_each_entry_safe.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49937", "url": "https://ubuntu.com/security/CVE-2024-49937", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Set correct chandef when starting CAC When starting CAC in a mode other than AP mode, it return a \"WARNING: CPU: 0 PID: 63 at cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]\" caused by the chandef.chan being null at the end of CAC. Solution: Ensure the channel definition is set for the different modes when starting CAC to avoid getting a NULL 'chan' at the end of CAC. Call Trace: ? show_regs.part.0+0x14/0x16 ? __warn+0x67/0xc0 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? report_bug+0xa7/0x130 ? exc_overflow+0x30/0x30 ? handle_bug+0x27/0x50 ? exc_invalid_op+0x18/0x60 ? handle_exception+0xf6/0xf6 ? exc_overflow+0x30/0x30 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? exc_overflow+0x30/0x30 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? regulatory_propagate_dfs_state.cold+0x1b/0x4c [cfg80211] ? cfg80211_propagate_cac_done_wk+0x1a/0x30 [cfg80211] ? process_one_work+0x165/0x280 ? worker_thread+0x120/0x3f0 ? kthread+0xc2/0xf0 ? process_one_work+0x280/0x280 ? kthread_complete_and_exit+0x20/0x20 ? ret_from_fork+0x19/0x24 [shorten subject, remove OCB, reorder cases to match previous list]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49938", "url": "https://ubuntu.com/security/CVE-2024-49938", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmit Syzbot points out that skb_trim() has a sanity check on the existing length of the skb, which can be uninitialised in some error paths. The intent here is clearly just to reset the length to zero before resubmitting, so switch to calling __skb_set_length(skb, 0) directly. In addition, __skb_set_length() already contains a call to skb_reset_tail_pointer(), so remove the redundant call. The syzbot report came from ath9k_hif_usb_reg_in_cb(), but there's a similar usage of skb_trim() in ath9k_hif_usb_rx_cb(), change both while we're at it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49939", "url": "https://ubuntu.com/security/CVE-2024-49939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: avoid to add interface to list twice when SER If SER L2 occurs during the WoWLAN resume flow, the add interface flow is triggered by ieee80211_reconfig(). However, due to rtw89_wow_resume() return failure, it will cause the add interface flow to be executed again, resulting in a double add list and causing a kernel panic. Therefore, we have added a check to prevent double adding of the list. list_add double add: new=ffff99d6992e2010, prev=ffff99d6992e2010, next=ffff99d695302628. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:37! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G W O 6.6.30-02659-gc18865c4dfbd #1 770df2933251a0e3c888ba69d1053a817a6376a7 Hardware name: HP Grunt/Grunt, BIOS Google_Grunt.11031.169.0 06/24/2021 Workqueue: events_freezable ieee80211_restart_work [mac80211] RIP: 0010:__list_add_valid_or_report+0x5e/0xb0 Code: c7 74 18 48 39 ce 74 13 b0 01 59 5a 5e 5f 41 58 41 59 41 5a 5d e9 e2 d6 03 00 cc 48 c7 c7 8d 4f 17 83 48 89 c2 e8 02 c0 00 00 <0f> 0b 48 c7 c7 aa 8c 1c 83 e8 f4 bf 00 00 0f 0b 48 c7 c7 c8 bc 12 RSP: 0018:ffffa91b8007bc50 EFLAGS: 00010246 RAX: 0000000000000058 RBX: ffff99d6992e0900 RCX: a014d76c70ef3900 RDX: ffffa91b8007bae8 RSI: 00000000ffffdfff RDI: 0000000000000001 RBP: ffffa91b8007bc88 R08: 0000000000000000 R09: ffffa91b8007bae0 R10: 00000000ffffdfff R11: ffffffff83a79800 R12: ffff99d695302060 R13: ffff99d695300900 R14: ffff99d6992e1be0 R15: ffff99d6992e2010 FS: 0000000000000000(0000) GS:ffff99d6aac00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000078fbdba43480 CR3: 000000010e464000 CR4: 00000000001506f0 Call Trace: ? __die_body+0x1f/0x70 ? die+0x3d/0x60 ? do_trap+0xa4/0x110 ? __list_add_valid_or_report+0x5e/0xb0 ? do_error_trap+0x6d/0x90 ? __list_add_valid_or_report+0x5e/0xb0 ? handle_invalid_op+0x30/0x40 ? __list_add_valid_or_report+0x5e/0xb0 ? exc_invalid_op+0x3c/0x50 ? asm_exc_invalid_op+0x16/0x20 ? __list_add_valid_or_report+0x5e/0xb0 rtw89_ops_add_interface+0x309/0x310 [rtw89_core 7c32b1ee6854761c0321027c8a58c5160e41f48f] drv_add_interface+0x5c/0x130 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ieee80211_reconfig+0x241/0x13d0 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ? finish_wait+0x3e/0x90 ? synchronize_rcu_expedited+0x174/0x260 ? sync_rcu_exp_done_unlocked+0x50/0x50 ? wake_bit_function+0x40/0x40 ieee80211_restart_work+0xf0/0x140 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] process_scheduled_works+0x1e5/0x480 worker_thread+0xea/0x1e0 kthread+0xdb/0x110 ? move_linked_works+0x90/0x90 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork+0x3b/0x50 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork_asm+0x11/0x20 Modules linked in: dm_integrity async_xor xor async_tx lz4 lz4_compress zstd zstd_compress zram zsmalloc rfcomm cmac uinput algif_hash algif_skcipher af_alg btusb btrtl iio_trig_hrtimer industrialio_sw_trigger btmtk industrialio_configfs btbcm btintel uvcvideo videobuf2_vmalloc iio_trig_sysfs videobuf2_memops videobuf2_v4l2 videobuf2_common uvc snd_hda_codec_hdmi veth snd_hda_intel snd_intel_dspcfg acpi_als snd_hda_codec industrialio_triggered_buffer kfifo_buf snd_hwdep industrialio i2c_piix4 snd_hda_core designware_i2s ip6table_nat snd_soc_max98357a xt_MASQUERADE xt_cgroup snd_soc_acp_rt5682_mach fuse rtw89_8922ae(O) rtw89_8922a(O) rtw89_pci(O) rtw89_core(O) 8021q mac80211(O) bluetooth ecdh_generic ecc cfg80211 r8152 mii joydev gsmi: Log Shutdown Reason 0x03 ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49940", "url": "https://ubuntu.com/security/CVE-2024-49940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: prevent possible tunnel refcount underflow When a session is created, it sets a backpointer to its tunnel. When the session refcount drops to 0, l2tp_session_free drops the tunnel refcount if session->tunnel is non-NULL. However, session->tunnel is set in l2tp_session_create, before the tunnel refcount is incremented by l2tp_session_register, which leaves a small window where session->tunnel is non-NULL when the tunnel refcount hasn't been bumped. Moving the assignment to l2tp_session_register is trivial but l2tp_session_create calls l2tp_session_set_header_len which uses session->tunnel to get the tunnel's encap. Add an encap arg to l2tp_session_set_header_len to avoid using session->tunnel. If l2tpv3 sessions have colliding IDs, it is possible for l2tp_v3_session_get to race with l2tp_session_register and fetch a session which doesn't yet have session->tunnel set. Add a check for this case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49941", "url": "https://ubuntu.com/security/CVE-2024-49941", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpiolib: Fix potential NULL pointer dereference in gpiod_get_label() In `gpiod_get_label()`, it is possible that `srcu_dereference_check()` may return a NULL pointer, leading to a scenario where `label->str` is accessed without verifying if `label` itself is NULL. This patch adds a proper NULL check for `label` before accessing `label->str`. The check for `label->str != NULL` is removed because `label->str` can never be NULL if `label` is not NULL. This fixes the issue where the label name was being printed as `(efault)` when dumping the sysfs GPIO file when `label == NULL`.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49996", "url": "https://ubuntu.com/security/CVE-2024-49996", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: Fix buffer overflow when parsing NFS reparse points ReparseDataLength is sum of the InodeType size and DataBuffer size. So to get DataBuffer size it is needed to subtract InodeType's size from ReparseDataLength. Function cifs_strndup_from_utf16() is currentlly accessing buf->DataBuffer at position after the end of the buffer because it does not subtract InodeType size from the length. Fix this problem and correctly subtract variable len. Member InodeType is present only when reparse buffer is large enough. Check for ReparseDataLength before accessing InodeType to prevent another invalid memory access. Major and minor rdev values are present also only when reparse buffer is large enough. Check for reparse buffer size before calling reparse_mkdev().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49942", "url": "https://ubuntu.com/security/CVE-2024-49942", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Prevent null pointer access in xe_migrate_copy xe_migrate_copy designed to copy content of TTM resources. When source resource is null, it will trigger a NULL pointer dereference in xe_migrate_copy. To avoid this situation, update lacks source flag to true for this case, the flag will trigger xe_migrate_clear rather than xe_migrate_copy. Issue trace: <7> [317.089847] xe 0000:00:02.0: [drm:xe_migrate_copy [xe]] Pass 14, sizes: 4194304 & 4194304 <7> [317.089945] xe 0000:00:02.0: [drm:xe_migrate_copy [xe]] Pass 15, sizes: 4194304 & 4194304 <1> [317.128055] BUG: kernel NULL pointer dereference, address: 0000000000000010 <1> [317.128064] #PF: supervisor read access in kernel mode <1> [317.128066] #PF: error_code(0x0000) - not-present page <6> [317.128069] PGD 0 P4D 0 <4> [317.128071] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI <4> [317.128074] CPU: 1 UID: 0 PID: 1440 Comm: kunit_try_catch Tainted: G U N 6.11.0-rc7-xe #1 <4> [317.128078] Tainted: [U]=USER, [N]=TEST <4> [317.128080] Hardware name: Intel Corporation Lunar Lake Client Platform/LNL-M LP5 RVP1, BIOS LNLMFWI1.R00.3221.D80.2407291239 07/29/2024 <4> [317.128082] RIP: 0010:xe_migrate_copy+0x66/0x13e0 [xe] <4> [317.128158] Code: 00 00 48 89 8d e0 fe ff ff 48 8b 40 10 4c 89 85 c8 fe ff ff 44 88 8d bd fe ff ff 65 48 8b 3c 25 28 00 00 00 48 89 7d d0 31 ff <8b> 79 10 48 89 85 a0 fe ff ff 48 8b 00 48 89 b5 d8 fe ff ff 83 ff <4> [317.128162] RSP: 0018:ffffc9000167f9f0 EFLAGS: 00010246 <4> [317.128164] RAX: ffff8881120d8028 RBX: ffff88814d070428 RCX: 0000000000000000 <4> [317.128166] RDX: ffff88813cb99c00 RSI: 0000000004000000 RDI: 0000000000000000 <4> [317.128168] RBP: ffffc9000167fbb8 R08: ffff88814e7b1f08 R09: 0000000000000001 <4> [317.128170] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88814e7b1f08 <4> [317.128172] R13: ffff88814e7b1f08 R14: ffff88813cb99c00 R15: 0000000000000001 <4> [317.128174] FS: 0000000000000000(0000) GS:ffff88846f280000(0000) knlGS:0000000000000000 <4> [317.128176] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [317.128178] CR2: 0000000000000010 CR3: 000000011f676004 CR4: 0000000000770ef0 <4> [317.128180] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 <4> [317.128182] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400 <4> [317.128184] PKRU: 55555554 <4> [317.128185] Call Trace: <4> [317.128187] <4> [317.128189] ? show_regs+0x67/0x70 <4> [317.128194] ? __die_body+0x20/0x70 <4> [317.128196] ? __die+0x2b/0x40 <4> [317.128198] ? page_fault_oops+0x15f/0x4e0 <4> [317.128203] ? do_user_addr_fault+0x3fb/0x970 <4> [317.128205] ? lock_acquire+0xc7/0x2e0 <4> [317.128209] ? exc_page_fault+0x87/0x2b0 <4> [317.128212] ? asm_exc_page_fault+0x27/0x30 <4> [317.128216] ? xe_migrate_copy+0x66/0x13e0 [xe] <4> [317.128263] ? __lock_acquire+0xb9d/0x26f0 <4> [317.128265] ? __lock_acquire+0xb9d/0x26f0 <4> [317.128267] ? sg_free_append_table+0x20/0x80 <4> [317.128271] ? lock_acquire+0xc7/0x2e0 <4> [317.128273] ? mark_held_locks+0x4d/0x80 <4> [317.128275] ? trace_hardirqs_on+0x1e/0xd0 <4> [317.128278] ? _raw_spin_unlock_irqrestore+0x31/0x60 <4> [317.128281] ? __pm_runtime_resume+0x60/0xa0 <4> [317.128284] xe_bo_move+0x682/0xc50 [xe] <4> [317.128315] ? lock_is_held_type+0xaa/0x120 <4> [317.128318] ttm_bo_handle_move_mem+0xe5/0x1a0 [ttm] <4> [317.128324] ttm_bo_validate+0xd1/0x1a0 [ttm] <4> [317.128328] shrink_test_run_device+0x721/0xc10 [xe] <4> [317.128360] ? find_held_lock+0x31/0x90 <4> [317.128363] ? lock_release+0xd1/0x2a0 <4> [317.128365] ? __pfx_kunit_generic_run_threadfn_adapter+0x10/0x10 [kunit] <4> [317.128370] xe_bo_shrink_kunit+0x11/0x20 [xe] <4> [317.128397] kunit_try_run_case+0x6e/0x150 [kunit] <4> [317.128400] ? trace_hardirqs_on+0x1e/0xd0 <4> [317.128402] ? _raw_spin_unlock_irqrestore+0x31/0x60 <4> [317.128404] kunit_generic_run_threadfn_adapter+0x1e/0x40 [ku ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49943", "url": "https://ubuntu.com/security/CVE-2024-49943", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc_submit: add missing locking in wedged_fini Any non-wedged queue can have a zero refcount here and can be running concurrently with an async queue destroy, therefore dereferencing the queue ptr to check wedge status after the lookup can trigger UAF if queue is not wedged. Fix this by keeping the submission_state lock held around the check to postpone the free and make the check safe, before dropping again around the put() to avoid the deadlock. (cherry picked from commit d28af0b6b9580b9f90c265a7da0315b0ad20bbfd)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50011", "url": "https://ubuntu.com/security/CVE-2024-50011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: soc-acpi-intel-rpl-match: add missing empty item There is no links_num in struct snd_soc_acpi_mach {}, and we test !link->num_adr as a condition to end the loop in hda_sdw_machine_select(). So an empty item in struct snd_soc_acpi_link_adr array is required.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50174", "url": "https://ubuntu.com/security/CVE-2024-50174", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix race when converting group handle to group object XArray provides it's own internal lock which protects the internal array when entries are being simultaneously added and removed. However there is still a race between retrieving the pointer from the XArray and incrementing the reference count. To avoid this race simply hold the internal XArray lock when incrementing the reference count, this ensures there cannot be a racing call to xa_erase().", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49944", "url": "https://ubuntu.com/security/CVE-2024-49944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_start In sctp_listen_start() invoked by sctp_inet_listen(), it should set the sk_state back to CLOSED if sctp_autobind() fails due to whatever reason. Otherwise, next time when calling sctp_inet_listen(), if sctp_sk(sk)->reuse is already set via setsockopt(SCTP_REUSE_PORT), sctp_sk(sk)->bind_hash will be dereferenced as sk_state is LISTENING, which causes a crash as bind_hash is NULL. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:sctp_inet_listen+0x7f0/0xa20 net/sctp/socket.c:8617 Call Trace: __sys_listen_socket net/socket.c:1883 [inline] __sys_listen+0x1b7/0x230 net/socket.c:1894 __do_sys_listen net/socket.c:1902 [inline]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49945", "url": "https://ubuntu.com/security/CVE-2024-49945", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/ncsi: Disable the ncsi work before freeing the associated structure The work function can run after the ncsi device is freed, resulting in use-after-free bugs or kernel panic.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49946", "url": "https://ubuntu.com/security/CVE-2024-49946", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: do not assume bh is held in ppp_channel_bridge_input() Networking receive path is usually handled from BH handler. However, some protocols need to acquire the socket lock, and packets might be stored in the socket backlog is the socket was owned by a user process. In this case, release_sock(), __release_sock(), and sk_backlog_rcv() might call the sk->sk_backlog_rcv() handler in process context. sybot caught ppp was not considering this case in ppp_channel_bridge_input() : WARNING: inconsistent lock state 6.11.0-rc7-syzkaller-g5f5673607153 #0 Not tainted -------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. ksoftirqd/1/24 [HC0[0]:SC1[1]:HE1:SE0] takes: ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 {SOFTIRQ-ON-W} state was registered at: lock_acquire+0x240/0x728 kernel/locking/lockdep.c:5759 __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline] _raw_spin_lock+0x48/0x60 kernel/locking/spinlock.c:154 spin_lock include/linux/spinlock.h:351 [inline] ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline] ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0xfc/0x314 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv include/net/sock.h:1111 [inline] __release_sock+0x1a8/0x3d8 net/core/sock.c:3004 release_sock+0x68/0x1b8 net/core/sock.c:3558 pppoe_sendmsg+0xc8/0x5d8 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x374/0x4f4 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __arm64_sys_sendto+0xd8/0xf8 net/socket.c:2212 __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:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 irq event stamp: 282914 hardirqs last enabled at (282914): [] __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:151 [inline] hardirqs last enabled at (282914): [] _raw_spin_unlock_irqrestore+0x38/0x98 kernel/locking/spinlock.c:194 hardirqs last disabled at (282913): [] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline] hardirqs last disabled at (282913): [] _raw_spin_lock_irqsave+0x2c/0x7c kernel/locking/spinlock.c:162 softirqs last enabled at (282904): [] softirq_handle_end kernel/softirq.c:400 [inline] softirqs last enabled at (282904): [] handle_softirqs+0xa3c/0xbfc kernel/softirq.c:582 softirqs last disabled at (282909): [] run_ksoftirqd+0x70/0x158 kernel/softirq.c:928 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&pch->downl); lock(&pch->downl); *** DEADLOCK *** 1 lock held by ksoftirqd/1/24: #0: ffff80008f74dfa0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire+0x10/0x4c include/linux/rcupdate.h:325 stack backtrace: CPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 6.11.0-rc7-syzkaller-g5f5673607153 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call trace: dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:319 show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:326 __dump_sta ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49947", "url": "https://ubuntu.com/security/CVE-2024-49947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: test for not too small csum_start in virtio_net_hdr_to_skb() syzbot was able to trigger this warning [1], after injecting a malicious packet through af_packet, setting skb->csum_start and thus the transport header to an incorrect value. We can at least make sure the transport header is after the end of the network header (with a estimated minimal size). [1] [ 67.873027] skb len=4096 headroom=16 headlen=14 tailroom=0 mac=(-1,-1) mac_len=0 net=(16,-6) trans=10 shinfo(txflags=0 nr_frags=1 gso(size=0 type=0 segs=0)) csum(0xa start=10 offset=0 ip_summed=3 complete_sw=0 valid=0 level=0) hash(0x0 sw=0 l4=0) proto=0x0800 pkttype=0 iif=0 priority=0x0 mark=0x0 alloc_cpu=10 vlan_all=0x0 encapsulation=0 inner(proto=0x0000, mac=0, net=0, trans=0) [ 67.877172] dev name=veth0_vlan feat=0x000061164fdd09e9 [ 67.877764] sk family=17 type=3 proto=0 [ 67.878279] skb linear: 00000000: 00 00 10 00 00 00 00 00 0f 00 00 00 08 00 [ 67.879128] skb frag: 00000000: 0e 00 07 00 00 00 28 00 08 80 1c 00 04 00 00 02 [ 67.879877] skb frag: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.880647] skb frag: 00000020: 00 00 02 00 00 00 08 00 1b 00 00 00 00 00 00 00 [ 67.881156] skb frag: 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.881753] skb frag: 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.882173] skb frag: 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.882790] skb frag: 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.883171] skb frag: 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.883733] skb frag: 00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.884206] skb frag: 00000090: 00 00 00 00 00 00 00 00 00 00 69 70 76 6c 61 6e [ 67.884704] skb frag: 000000a0: 31 00 00 00 00 00 00 00 00 00 2b 00 00 00 00 00 [ 67.885139] skb frag: 000000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.885677] skb frag: 000000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.886042] skb frag: 000000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.886408] skb frag: 000000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.887020] skb frag: 000000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.887384] skb frag: 00000100: 00 00 [ 67.887878] ------------[ cut here ]------------ [ 67.887908] offset (-6) >= skb_headlen() (14) [ 67.888445] WARNING: CPU: 10 PID: 2088 at net/core/dev.c:3332 skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.889353] Modules linked in: macsec macvtap macvlan hsr wireguard curve25519_x86_64 libcurve25519_generic libchacha20poly1305 chacha_x86_64 libchacha poly1305_x86_64 dummy bridge sr_mod cdrom evdev pcspkr i2c_piix4 9pnet_virtio 9p 9pnet netfs [ 67.890111] CPU: 10 UID: 0 PID: 2088 Comm: b363492833 Not tainted 6.11.0-virtme #1011 [ 67.890183] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 67.890309] RIP: 0010:skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891043] Call Trace: [ 67.891173] [ 67.891274] ? __warn (kernel/panic.c:741) [ 67.891320] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891333] ? report_bug (lib/bug.c:180 lib/bug.c:219) [ 67.891348] ? handle_bug (arch/x86/kernel/traps.c:239) [ 67.891363] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) [ 67.891372] ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621) [ 67.891388] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891399] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891416] ip_do_fragment (net/ipv4/ip_output.c:777 (discriminator 1)) [ 67.891448] ? __ip_local_out (./include/linux/skbuff.h:1146 ./include/net/l3mdev.h:196 ./include/net/l3mdev.h:213 ne ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49948", "url": "https://ubuntu.com/security/CVE-2024-49948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: add more sanity checks to qdisc_pkt_len_init() One path takes care of SKB_GSO_DODGY, assuming skb->len is bigger than hdr_len. virtio_net_hdr_to_skb() does not fully dissect TCP headers, it only make sure it is at least 20 bytes. It is possible for an user to provide a malicious 'GSO' packet, total length of 80 bytes. - 20 bytes of IPv4 header - 60 bytes TCP header - a small gso_size like 8 virtio_net_hdr_to_skb() would declare this packet as a normal GSO packet, because it would see 40 bytes of payload, bigger than gso_size. We need to make detect this case to not underflow qdisc_skb_cb(skb)->pkt_len.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49949", "url": "https://ubuntu.com/security/CVE-2024-49949", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: avoid potential underflow in qdisc_pkt_len_init() with UFO After commit 7c6d2ecbda83 (\"net: be more gentle about silly gso requests coming from user\") virtio_net_hdr_to_skb() had sanity check to detect malicious attempts from user space to cook a bad GSO packet. Then commit cf9acc90c80ec (\"net: virtio_net_hdr_to_skb: count transport header in UFO\") while fixing one issue, allowed user space to cook a GSO packet with the following characteristic : IPv4 SKB_GSO_UDP, gso_size=3, skb->len = 28. When this packet arrives in qdisc_pkt_len_init(), we end up with hdr_len = 28 (IPv4 header + UDP header), matching skb->len Then the following sets gso_segs to 0 : gso_segs = DIV_ROUND_UP(skb->len - hdr_len, shinfo->gso_size); Then later we set qdisc_skb_cb(skb)->pkt_len to back to zero :/ qdisc_skb_cb(skb)->pkt_len += (gso_segs - 1) * hdr_len; This leads to the following crash in fq_codel [1] qdisc_pkt_len_init() is best effort, we only want an estimation of the bytes sent on the wire, not crashing the kernel. This patch is fixing this particular issue, a following one adds more sanity checks for another potential bug. [1] [ 70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 70.724561] #PF: supervisor read access in kernel mode [ 70.724561] #PF: error_code(0x0000) - not-present page [ 70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0 [ 70.724561] Oops: Oops: 0000 [#1] SMP NOPTI [ 70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991 [ 70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel [ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 <49> 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49 All code ======== 0:\t24 08 \tand $0x8,%al 2:\t49 c1 e1 06 \tshl $0x6,%r9 6:\t44 89 7c 24 18 \tmov %r15d,0x18(%rsp) b:\t45 31 ed \txor %r13d,%r13d e:\t45 31 c0 \txor %r8d,%r8d 11:\t31 ff \txor %edi,%edi 13:\t89 44 24 14 \tmov %eax,0x14(%rsp) 17:\t4c 03 8b 90 01 00 00 \tadd 0x190(%rbx),%r9 1e:\teb 04 \tjmp 0x24 20:\t39 ca \tcmp %ecx,%edx 22:\t73 37 \tjae 0x5b 24:\t4d 8b 39 \tmov (%r9),%r15 27:\t83 c7 01 \tadd $0x1,%edi 2a:*\t49 8b 17 \tmov (%r15),%rdx\t\t<-- trapping instruction 2d:\t49 89 11 \tmov %rdx,(%r9) 30:\t41 8b 57 28 \tmov 0x28(%r15),%edx 34:\t45 8b 5f 34 \tmov 0x34(%r15),%r11d 38:\t49 c7 07 00 00 00 00 \tmovq $0x0,(%r15) 3f:\t49 \trex.WB Code starting with the faulting instruction =========================================== 0:\t49 8b 17 \tmov (%r15),%rdx 3:\t49 89 11 \tmov %rdx,(%r9) 6:\t41 8b 57 28 \tmov 0x28(%r15),%edx a:\t45 8b 5f 34 \tmov 0x34(%r15),%r11d e:\t49 c7 07 00 00 00 00 \tmovq $0x0,(%r15) 15:\t49 \trex.WB [ 70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202 [ 70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000 [ 70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001 [ 70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000 [ 70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58 [ 70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000 [ 70.724561] FS: 000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000 [ 70.724561] CS: 0010 DS: 0000 ES: 0000 C ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49997", "url": "https://ubuntu.com/security/CVE-2024-49997", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: lantiq_etop: fix memory disclosure When applying padding, the buffer is not zeroed, which results in memory disclosure. The mentioned data is observed on the wire. This patch uses skb_put_padto() to pad Ethernet frames properly. The mentioned function zeroes the expanded buffer. In case the packet cannot be padded it is silently dropped. Statistics are also not incremented. This driver does not support statistics in the old 32-bit format or the new 64-bit format. These will be added in the future. In its current form, the patch should be easily backported to stable versions. Ethernet MACs on Amazon-SE and Danube cannot do padding of the packets in hardware, so software padding must be applied.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49998", "url": "https://ubuntu.com/security/CVE-2024-49998", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: improve shutdown sequence Alexander Sverdlin presents 2 problems during shutdown with the lan9303 driver. One is specific to lan9303 and the other just happens to reproduce there. The first problem is that lan9303 is unique among DSA drivers in that it calls dev_get_drvdata() at \"arbitrary runtime\" (not probe, not shutdown, not remove): phy_state_machine() -> ... -> dsa_user_phy_read() -> ds->ops->phy_read() -> lan9303_phy_read() -> chip->ops->phy_read() -> lan9303_mdio_phy_read() -> dev_get_drvdata() But we never stop the phy_state_machine(), so it may continue to run after dsa_switch_shutdown(). Our common pattern in all DSA drivers is to set drvdata to NULL to suppress the remove() method that may come afterwards. But in this case it will result in an NPD. The second problem is that the way in which we set dp->conduit->dsa_ptr = NULL; is concurrent with receive packet processing. dsa_switch_rcv() checks once whether dev->dsa_ptr is NULL, but afterwards, rather than continuing to use that non-NULL value, dev->dsa_ptr is dereferenced again and again without NULL checks: dsa_conduit_find_user() and many other places. In between dereferences, there is no locking to ensure that what was valid once continues to be valid. Both problems have the common aspect that closing the conduit interface solves them. In the first case, dev_close(conduit) triggers the NETDEV_GOING_DOWN event in dsa_user_netdevice_event() which closes user ports as well. dsa_port_disable_rt() calls phylink_stop(), which synchronously stops the phylink state machine, and ds->ops->phy_read() will thus no longer call into the driver after this point. In the second case, dev_close(conduit) should do this, as per Documentation/networking/driver.rst: | Quiescence | ---------- | | After the ndo_stop routine has been called, the hardware must | not receive or transmit any data. All in flight packets must | be aborted. If necessary, poll or wait for completion of | any reset commands. So it should be sufficient to ensure that later, when we zeroize conduit->dsa_ptr, there will be no concurrent dsa_switch_rcv() call on this conduit. The addition of the netif_device_detach() function is to ensure that ioctls, rtnetlinks and ethtool requests on the user ports no longer propagate down to the driver - we're no longer prepared to handle them. The race condition actually did not exist when commit 0650bf52b31f (\"net: dsa: be compatible with masters which unregister on shutdown\") first introduced dsa_switch_shutdown(). It was created later, when we stopped unregistering the user interfaces from a bad spot, and we just replaced that sequence with a racy zeroization of conduit->dsa_ptr (one which doesn't ensure that the interfaces aren't up).", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49999", "url": "https://ubuntu.com/security/CVE-2024-49999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix the setting of the server responding flag In afs_wait_for_operation(), we set transcribe the call responded flag to the server record that we used after doing the fileserver iteration loop - but it's possible to exit the loop having had a response from the server that we've discarded (e.g. it returned an abort or we started receiving data, but the call didn't complete). This means that op->server might be NULL, but we don't check that before attempting to set the server flag.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49950", "url": "https://ubuntu.com/security/CVE-2024-49950", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix uaf in l2cap_connect [Syzbot reported] BUG: KASAN: slab-use-after-free in l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 Read of size 8 at addr ffff8880241e9800 by task kworker/u9:0/54 CPU: 0 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-00268-g788220eee30d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Workqueue: hci2 hci_rx_work Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 l2cap_connect_req net/bluetooth/l2cap_core.c:4080 [inline] l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:4772 [inline] l2cap_sig_channel net/bluetooth/l2cap_core.c:5543 [inline] l2cap_recv_frame+0xf0b/0x8eb0 net/bluetooth/l2cap_core.c:6825 l2cap_recv_acldata+0x9b4/0xb70 net/bluetooth/l2cap_core.c:7514 hci_acldata_packet net/bluetooth/hci_core.c:3791 [inline] hci_rx_work+0xaab/0x1610 net/bluetooth/hci_core.c:4028 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 ... Freed by task 5245: 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:579 poison_slab_object+0xf7/0x160 mm/kasan/common.c:240 __kasan_slab_free+0x32/0x50 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2256 [inline] slab_free mm/slub.c:4477 [inline] kfree+0x12a/0x3b0 mm/slub.c:4598 l2cap_conn_free net/bluetooth/l2cap_core.c:1810 [inline] kref_put include/linux/kref.h:65 [inline] l2cap_conn_put net/bluetooth/l2cap_core.c:1822 [inline] l2cap_conn_del+0x59d/0x730 net/bluetooth/l2cap_core.c:1802 l2cap_connect_cfm+0x9e6/0xf80 net/bluetooth/l2cap_core.c:7241 hci_connect_cfm include/net/bluetooth/hci_core.h:1960 [inline] hci_conn_failed+0x1c3/0x370 net/bluetooth/hci_conn.c:1265 hci_abort_conn_sync+0x75a/0xb50 net/bluetooth/hci_sync.c:5583 abort_conn_sync+0x197/0x360 net/bluetooth/hci_conn.c:2917 hci_cmd_sync_work+0x1a4/0x410 net/bluetooth/hci_sync.c:328 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49951", "url": "https://ubuntu.com/security/CVE-2024-49951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Fix possible crash on mgmt_index_removed If mgmt_index_removed is called while there are commands queued on cmd_sync it could lead to crashes like the bellow trace: 0x0000053D: __list_del_entry_valid_or_report+0x98/0xdc 0x0000053D: mgmt_pending_remove+0x18/0x58 [bluetooth] 0x0000053E: mgmt_remove_adv_monitor_complete+0x80/0x108 [bluetooth] 0x0000053E: hci_cmd_sync_work+0xbc/0x164 [bluetooth] So while handling mgmt_index_removed this attempts to dequeue commands passed as user_data to cmd_sync.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49952", "url": "https://ubuntu.com/security/CVE-2024-49952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: prevent nf_skb_duplicated corruption syzbot found that nf_dup_ipv4() or nf_dup_ipv6() could write per-cpu variable nf_skb_duplicated in an unsafe way [1]. Disabling preemption as hinted by the splat is not enough, we have to disable soft interrupts as well. [1] BUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316 caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49 nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook+0x2c4/0x450 include/linux/netfilter.h:269 NF_HOOK_COND include/linux/netfilter.h:302 [inline] ip_output+0x185/0x230 net/ipv4/ip_output.c:433 ip_local_out net/ipv4/ip_output.c:129 [inline] ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495 udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981 udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737 __do_sys_sendmmsg net/socket.c:2766 [inline] __se_sys_sendmmsg net/socket.c:2763 [inline] __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763 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:0x7f4ce4f7def9 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:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9 RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006 RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49953", "url": "https://ubuntu.com/security/CVE-2024-49953", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix crash caused by calling __xfrm_state_delete() twice The km.state is not checked in driver's delayed work. When xfrm_state_check_expire() is called, the state can be reset to XFRM_STATE_EXPIRED, even if it is XFRM_STATE_DEAD already. This happens when xfrm state is deleted, but not freed yet. As __xfrm_state_delete() is called again in xfrm timer, the following crash occurs. To fix this issue, skip xfrm_state_check_expire() if km.state is not XFRM_STATE_VALID. Oops: general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] SMP CPU: 5 UID: 0 PID: 7448 Comm: kworker/u102:2 Not tainted 6.11.0-rc2+ #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5e_ipsec: eth%d mlx5e_ipsec_handle_sw_limits [mlx5_core] RIP: 0010:__xfrm_state_delete+0x3d/0x1b0 Code: 0f 84 8b 01 00 00 48 89 fd c6 87 c8 00 00 00 05 48 8d bb 40 10 00 00 e8 11 04 1a 00 48 8b 95 b8 00 00 00 48 8b 85 c0 00 00 00 <48> 89 42 08 48 89 10 48 8b 55 10 48 b8 00 01 00 00 00 00 ad de 48 RSP: 0018:ffff88885f945ec8 EFLAGS: 00010246 RAX: dead000000000122 RBX: ffffffff82afa940 RCX: 0000000000000036 RDX: dead000000000100 RSI: 0000000000000000 RDI: ffffffff82afb980 RBP: ffff888109a20340 R08: ffff88885f945ea0 R09: 0000000000000000 R10: 0000000000000000 R11: ffff88885f945ff8 R12: 0000000000000246 R13: ffff888109a20340 R14: ffff88885f95f420 R15: ffff88885f95f400 FS: 0000000000000000(0000) GS:ffff88885f940000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2163102430 CR3: 00000001128d6001 CR4: 0000000000370eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? die_addr+0x33/0x90 ? exc_general_protection+0x1a2/0x390 ? asm_exc_general_protection+0x22/0x30 ? __xfrm_state_delete+0x3d/0x1b0 ? __xfrm_state_delete+0x2f/0x1b0 xfrm_timer_handler+0x174/0x350 ? __xfrm_state_delete+0x1b0/0x1b0 __hrtimer_run_queues+0x121/0x270 hrtimer_run_softirq+0x88/0xd0 handle_softirqs+0xcc/0x270 do_softirq+0x3c/0x50 __local_bh_enable_ip+0x47/0x50 mlx5e_ipsec_handle_sw_limits+0x7d/0x90 [mlx5_core] process_one_work+0x137/0x2d0 worker_thread+0x28d/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50000", "url": "https://ubuntu.com/security/CVE-2024-50000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix NULL deref in mlx5e_tir_builder_alloc() In mlx5e_tir_builder_alloc() kvzalloc() may return NULL which is dereferenced on the next line in a reference to the modify field. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50001", "url": "https://ubuntu.com/security/CVE-2024-50001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix error path in multi-packet WQE transmit Remove the erroneous unmap in case no DMA mapping was established The multi-packet WQE transmit code attempts to obtain a DMA mapping for the skb. This could fail, e.g. under memory pressure, when the IOMMU driver just can't allocate more memory for page tables. While the code tries to handle this in the path below the err_unmap label it erroneously unmaps one entry from the sq's FIFO list of active mappings. Since the current map attempt failed this unmap is removing some random DMA mapping that might still be required. If the PCI function now presents that IOVA, the IOMMU may assumes a rogue DMA access and e.g. on s390 puts the PCI function in error state. The erroneous behavior was seen in a stress-test environment that created memory pressure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50179", "url": "https://ubuntu.com/security/CVE-2024-50179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: remove the incorrect Fw reference check when dirtying pages When doing the direct-io reads it will also try to mark pages dirty, but for the read path it won't hold the Fw caps and there is case will it get the Fw reference.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49963", "url": "https://ubuntu.com/security/CVE-2024-49963", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mailbox: bcm2835: Fix timeout during suspend mode During noirq suspend phase the Raspberry Pi power driver suffer of firmware property timeouts. The reason is that the IRQ of the underlying BCM2835 mailbox is disabled and rpi_firmware_property_list() will always run into a timeout [1]. Since the VideoCore side isn't consider as a wakeup source, set the IRQF_NO_SUSPEND flag for the mailbox IRQ in order to keep it enabled during suspend-resume cycle. [1] PM: late suspend of devices complete after 1.754 msecs WARNING: CPU: 0 PID: 438 at drivers/firmware/raspberrypi.c:128 rpi_firmware_property_list+0x204/0x22c Firmware transaction 0x00028001 timeout Modules linked in: CPU: 0 PID: 438 Comm: bash Tainted: G C 6.9.3-dirty #17 Hardware name: BCM2835 Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x44 dump_stack_lvl from __warn+0x88/0xec __warn from warn_slowpath_fmt+0x7c/0xb0 warn_slowpath_fmt from rpi_firmware_property_list+0x204/0x22c rpi_firmware_property_list from rpi_firmware_property+0x68/0x8c rpi_firmware_property from rpi_firmware_set_power+0x54/0xc0 rpi_firmware_set_power from _genpd_power_off+0xe4/0x148 _genpd_power_off from genpd_sync_power_off+0x7c/0x11c genpd_sync_power_off from genpd_finish_suspend+0xcc/0xe0 genpd_finish_suspend from dpm_run_callback+0x78/0xd0 dpm_run_callback from device_suspend_noirq+0xc0/0x238 device_suspend_noirq from dpm_suspend_noirq+0xb0/0x168 dpm_suspend_noirq from suspend_devices_and_enter+0x1b8/0x5ac suspend_devices_and_enter from pm_suspend+0x254/0x2e4 pm_suspend from state_store+0xa8/0xd4 state_store from kernfs_fop_write_iter+0x154/0x1a0 kernfs_fop_write_iter from vfs_write+0x12c/0x184 vfs_write from ksys_write+0x78/0xc0 ksys_write from ret_fast_syscall+0x0/0x54 Exception stack(0xcc93dfa8 to 0xcc93dff0) [...] PM: noirq suspend of devices complete after 3095.584 msecs", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49954", "url": "https://ubuntu.com/security/CVE-2024-49954", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: static_call: Replace pointless WARN_ON() in static_call_module_notify() static_call_module_notify() triggers a WARN_ON(), when memory allocation fails in __static_call_add_module(). That's not really justified, because the failure case must be correctly handled by the well known call chain and the error code is passed through to the initiating userspace application. A memory allocation fail is not a fatal problem, but the WARN_ON() takes the machine out when panic_on_warn is set. Replace it with a pr_warn().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50002", "url": "https://ubuntu.com/security/CVE-2024-50002", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: static_call: Handle module init failure correctly in static_call_del_module() Module insertion invokes static_call_add_module() to initialize the static calls in a module. static_call_add_module() invokes __static_call_init(), which allocates a struct static_call_mod to either encapsulate the built-in static call sites of the associated key into it so further modules can be added or to append the module to the module chain. If that allocation fails the function returns with an error code and the module core invokes static_call_del_module() to clean up eventually added static_call_mod entries. This works correctly, when all keys used by the module were converted over to a module chain before the failure. If not then static_call_del_module() causes a #GP as it blindly assumes that key::mods points to a valid struct static_call_mod. The problem is that key::mods is not a individual struct member of struct static_call_key, it's part of a union to save space: union { /* bit 0: 0 = mods, 1 = sites */ unsigned long type; struct static_call_mod *mods; struct static_call_site *sites; \t}; key::sites is a pointer to the list of built-in usage sites of the static call. The type of the pointer is differentiated by bit 0. A mods pointer has the bit clear, the sites pointer has the bit set. As static_call_del_module() blidly assumes that the pointer is a valid static_call_mod type, it fails to check for this failure case and dereferences the pointer to the list of built-in call sites, which is obviously bogus. Cure it by checking whether the key has a sites or a mods pointer. If it's a sites pointer then the key is not to be touched. As the sites are walked in the same order as in __static_call_init() the site walk can be terminated because all subsequent sites have not been touched by the init code due to the error exit. If it was converted before the allocation fail, then the inner loop which searches for a module match will find nothing. A fail in the second allocation in __static_call_init() is harmless and does not require special treatment. The first allocation succeeded and converted the key to a module chain. That first entry has mod::mod == NULL and mod::next == NULL, so the inner loop of static_call_del_module() will neither find a module match nor a module chain. The next site in the walk was either already converted, but can't match the module, or it will exit the outer loop because it has a static_call_site pointer and not a static_call_mod pointer.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-47675", "url": "https://ubuntu.com/security/CVE-2024-47675", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix use-after-free in bpf_uprobe_multi_link_attach() If bpf_link_prime() fails, bpf_uprobe_multi_link_attach() goes to the error_free label and frees the array of bpf_uprobe's without calling bpf_uprobe_unregister(). This leaks bpf_uprobe->uprobe and worse, this frees bpf_uprobe->consumer without removing it from the uprobe->consumers list.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47676", "url": "https://ubuntu.com/security/CVE-2024-47676", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb.c: fix UAF of vma in hugetlb fault pathway Syzbot reports a UAF in hugetlb_fault(). This happens because vmf_anon_prepare() could drop the per-VMA lock and allow the current VMA to be freed before hugetlb_vma_unlock_read() is called. We can fix this by using a modified version of vmf_anon_prepare() that doesn't release the VMA lock on failure, and then release it ourselves after hugetlb_vma_unlock_read().", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47677", "url": "https://ubuntu.com/security/CVE-2024-47677", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: resolve memory leak from exfat_create_upcase_table() If exfat_load_upcase_table reaches end and returns -EINVAL, allocated memory doesn't get freed and while exfat_load_default_upcase_table allocates more memory, leading to a memory leak. Here's link to syzkaller crash report illustrating this issue: https://syzkaller.appspot.com/text?tag=CrashReport&x=1406c201980000", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47725", "url": "https://ubuntu.com/security/CVE-2024-47725", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47739", "url": "https://ubuntu.com/security/CVE-2024-47739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: padata: use integer wrap around to prevent deadlock on seq_nr overflow When submitting more than 2^32 padata objects to padata_do_serial, the current sorting implementation incorrectly sorts padata objects with overflowed seq_nr, causing them to be placed before existing objects in the reorder list. This leads to a deadlock in the serialization process as padata_find_next cannot match padata->seq_nr and pd->processed because the padata instance with overflowed seq_nr will be selected next. To fix this, we use an unsigned integer wrap around to correctly sort padata objects in scenarios with integer overflow.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47678", "url": "https://ubuntu.com/security/CVE-2024-47678", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: icmp: change the order of rate limits ICMP messages are ratelimited : After the blamed commits, the two rate limiters are applied in this order: 1) host wide ratelimit (icmp_global_allow()) 2) Per destination ratelimit (inetpeer based) In order to avoid side-channels attacks, we need to apply the per destination check first. This patch makes the following change : 1) icmp_global_allow() checks if the host wide limit is reached. But credits are not yet consumed. This is deferred to 3) 2) The per destination limit is checked/updated. This might add a new node in inetpeer tree. 3) icmp_global_consume() consumes tokens if prior operations succeeded. This means that host wide ratelimit is still effective in keeping inetpeer tree small even under DDOS. As a bonus, I removed icmp_global.lock as the fast path can use a lock-free operation.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47733", "url": "https://ubuntu.com/security/CVE-2024-47733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfs: Delete subtree of 'fs/netfs' when netfs module exits In netfs_init() or fscache_proc_init(), we create dentry under 'fs/netfs', but in netfs_exit(), we only delete the proc entry of 'fs/netfs' without deleting its subtree. This triggers the following WARNING: ================================================================== remove_proc_entry: removing non-empty directory 'fs/netfs', leaking at least 'requests' WARNING: CPU: 4 PID: 566 at fs/proc/generic.c:717 remove_proc_entry+0x160/0x1c0 Modules linked in: netfs(-) CPU: 4 UID: 0 PID: 566 Comm: rmmod Not tainted 6.11.0-rc3 #860 RIP: 0010:remove_proc_entry+0x160/0x1c0 Call Trace: netfs_exit+0x12/0x620 [netfs] __do_sys_delete_module.isra.0+0x14c/0x2e0 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e ================================================================== Therefore use remove_proc_subtree() instead of remove_proc_entry() to fix the above problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47679", "url": "https://ubuntu.com/security/CVE-2024-47679", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfs: fix race between evice_inodes() and find_inode()&iput() Hi, all Recently I noticed a bug[1] in btrfs, after digged it into and I believe it'a race in vfs. Let's assume there's a inode (ie ino 261) with i_count 1 is called by iput(), and there's a concurrent thread calling generic_shutdown_super(). cpu0: cpu1: iput() // i_count is 1 ->spin_lock(inode) ->dec i_count to 0 ->iput_final() generic_shutdown_super() ->__inode_add_lru() ->evict_inodes() // cause some reason[2] ->if (atomic_read(inode->i_count)) continue; // return before // inode 261 passed the above check // list_lru_add_obj() // and then schedule out ->spin_unlock() // note here: the inode 261 // was still at sb list and hash list, // and I_FREEING|I_WILL_FREE was not been set btrfs_iget() // after some function calls ->find_inode() // found the above inode 261 ->spin_lock(inode) // check I_FREEING|I_WILL_FREE // and passed ->__iget() ->spin_unlock(inode) // schedule back ->spin_lock(inode) // check (I_NEW|I_FREEING|I_WILL_FREE) flags, // passed and set I_FREEING iput() ->spin_unlock(inode) ->spin_lock(inode)\t\t\t ->evict() // dec i_count to 0 ->iput_final() ->spin_unlock() ->evict() Now, we have two threads simultaneously evicting the same inode, which may trigger the BUG(inode->i_state & I_CLEAR) statement both within clear_inode() and iput(). To fix the bug, recheck the inode->i_count after holding i_lock. Because in the most scenarios, the first check is valid, and the overhead of spin_lock() can be reduced. If there is any misunderstanding, please let me know, thanks. [1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/ [2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable() return false when I reproduced the bug.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49859", "url": "https://ubuntu.com/security/CVE-2024-49859", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to check atomic_file in f2fs ioctl interfaces Some f2fs ioctl interfaces like f2fs_ioc_set_pin_file(), f2fs_move_file_range(), and f2fs_defragment_range() missed to check atomic_write status, which may cause potential race issue, fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47680", "url": "https://ubuntu.com/security/CVE-2024-47680", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: check discard support for conventional zones As the helper function f2fs_bdev_support_discard() shows, f2fs checks if the target block devices support discard by calling bdev_max_discard_sectors() and bdev_is_zoned(). This check works well for most cases, but it does not work for conventional zones on zoned block devices. F2fs assumes that zoned block devices support discard, and calls __submit_discard_cmd(). When __submit_discard_cmd() is called for sequential write required zones, it works fine since __submit_discard_cmd() issues zone reset commands instead of discard commands. However, when __submit_discard_cmd() is called for conventional zones, __blkdev_issue_discard() is called even when the devices do not support discard. The inappropriate __blkdev_issue_discard() call was not a problem before the commit 30f1e7241422 (\"block: move discard checks into the ioctl handler\") because __blkdev_issue_discard() checked if the target devices support discard or not. If not, it returned EOPNOTSUPP. After the commit, __blkdev_issue_discard() no longer checks it. It always returns zero and sets NULL to the given bio pointer. This NULL pointer triggers f2fs_bug_on() in __submit_discard_cmd(). The BUG is recreated with the commands below at the umount step, where /dev/nullb0 is a zoned null_blk with 5GB total size, 128MB zone size and 10 conventional zones. $ mkfs.f2fs -f -m /dev/nullb0 $ mount /dev/nullb0 /mnt $ for ((i=0;i<5;i++)); do dd if=/dev/zero of=/mnt/test bs=65536 count=1600 conv=fsync; done $ umount /mnt To fix the BUG, avoid the inappropriate __blkdev_issue_discard() call. When discard is requested for conventional zones, check if the device supports discard or not. If not, return EOPNOTSUPP.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47740", "url": "https://ubuntu.com/security/CVE-2024-47740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: Require FMODE_WRITE for atomic write ioctls The F2FS ioctls for starting and committing atomic writes check for inode_owner_or_capable(), but this does not give LSMs like SELinux or Landlock an opportunity to deny the write access - if the caller's FSUID matches the inode's UID, inode_owner_or_capable() immediately returns true. There are scenarios where LSMs want to deny a process the ability to write particular files, even files that the FSUID of the process owns; but this can currently partially be bypassed using atomic write ioctls in two ways: - F2FS_IOC_START_ATOMIC_REPLACE + F2FS_IOC_COMMIT_ATOMIC_WRITE can truncate an inode to size 0 - F2FS_IOC_START_ATOMIC_WRITE + F2FS_IOC_ABORT_ATOMIC_WRITE can revert changes another process concurrently made to a file Fix it by requiring FMODE_WRITE for these operations, just like for F2FS_IOC_MOVE_RANGE. Since any legitimate caller should only be using these ioctls when intending to write into the file, that seems unlikely to break anything.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47726", "url": "https://ubuntu.com/security/CVE-2024-47726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to wait dio completion It should wait all existing dio write IOs before block removal, otherwise, previous direct write IO may overwrite data in the block which may be reused by other inode.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47741", "url": "https://ubuntu.com/security/CVE-2024-47741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race setting file private on concurrent lseek using same fd When doing concurrent lseek(2) system calls against the same file descriptor, using multiple threads belonging to the same process, we have a short time window where a race happens and can result in a memory leak. The race happens like this: 1) A program opens a file descriptor for a file and then spawns two threads (with the pthreads library for example), lets call them task A and task B; 2) Task A calls lseek with SEEK_DATA or SEEK_HOLE and ends up at file.c:find_desired_extent() while holding a read lock on the inode; 3) At the start of find_desired_extent(), it extracts the file's private_data pointer into a local variable named 'private', which has a value of NULL; 4) Task B also calls lseek with SEEK_DATA or SEEK_HOLE, locks the inode in shared mode and enters file.c:find_desired_extent(), where it also extracts file->private_data into its local variable 'private', which has a NULL value; 5) Because it saw a NULL file private, task A allocates a private structure and assigns to the file structure; 6) Task B also saw a NULL file private so it also allocates its own file private and then assigns it to the same file structure, since both tasks are using the same file descriptor. At this point we leak the private structure allocated by task A. Besides the memory leak, there's also the detail that both tasks end up using the same cached state record in the private structure (struct btrfs_file_private::llseek_cached_state), which can result in a use-after-free problem since one task can free it while the other is still using it (only one task took a reference count on it). Also, sharing the cached state is not a good idea since it could result in incorrect results in the future - right now it should not be a problem because it end ups being used only in extent-io-tree.c:count_range_bits() where we do range validation before using the cached state. Fix this by protecting the private assignment and check of a file while holding the inode's spinlock and keep track of the task that allocated the private, so that it's used only by that task in order to prevent user-after-free issues with the cached state record as well as potentially using it incorrectly in the future.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47681", "url": "https://ubuntu.com/security/CVE-2024-47681", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix NULL pointer dereference in mt7996_mcu_sta_bfer_he Fix the NULL pointer dereference in mt7996_mcu_sta_bfer_he routine adding an sta interface to the mt7996 driver. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49858", "url": "https://ubuntu.com/security/CVE-2024-49858", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption The TPM event log table is a Linux specific construct, where the data produced by the GetEventLog() boot service is cached in memory, and passed on to the OS using an EFI configuration table. The use of EFI_LOADER_DATA here results in the region being left unreserved in the E820 memory map constructed by the EFI stub, and this is the memory description that is passed on to the incoming kernel by kexec, which is therefore unaware that the region should be reserved. Even though the utility of the TPM2 event log after a kexec is questionable, any corruption might send the parsing code off into the weeds and crash the kernel. So let's use EFI_ACPI_RECLAIM_MEMORY instead, which is always treated as reserved by the E820 conversion logic.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49860", "url": "https://ubuntu.com/security/CVE-2024-49860", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: sysfs: validate return type of _STR method Only buffer objects are valid return values of _STR. If something else is returned description_show() will access invalid memory.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47742", "url": "https://ubuntu.com/security/CVE-2024-47742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware_loader: Block path traversal Most firmware names are hardcoded strings, or are constructed from fairly constrained format strings where the dynamic parts are just some hex numbers or such. However, there are a couple codepaths in the kernel where firmware file names contain string components that are passed through from a device or semi-privileged userspace; the ones I could find (not counting interfaces that require root privileges) are: - lpfc_sli4_request_firmware_update() seems to construct the firmware filename from \"ModelName\", a string that was previously parsed out of some descriptor (\"Vital Product Data\") in lpfc_fill_vpd() - nfp_net_fw_find() seems to construct a firmware filename from a model name coming from nfp_hwinfo_lookup(pf->hwinfo, \"nffw.partno\"), which I think parses some descriptor that was read from the device. (But this case likely isn't exploitable because the format string looks like \"netronome/nic_%s\", and there shouldn't be any *folders* starting with \"netronome/nic_\". The previous case was different because there, the \"%s\" is *at the start* of the format string.) - module_flash_fw_schedule() is reachable from the ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is enough to pass the privilege check), and takes a userspace-provided firmware name. (But I think to reach this case, you need to have CAP_NET_ADMIN over a network namespace that a special kind of ethernet device is mapped into, so I think this is not a viable attack path in practice.) Fix it by rejecting any firmware names containing \"..\" path components. For what it's worth, I went looking and haven't found any USB device drivers that use the firmware loader dangerously.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47682", "url": "https://ubuntu.com/security/CVE-2024-47682", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sd: Fix off-by-one error in sd_read_block_characteristics() Ff the device returns page 0xb1 with length 8 (happens with qemu v2.x, for example), sd_read_block_characteristics() may attempt an out-of-bounds memory access when accessing the zoned field at offset 8.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47743", "url": "https://ubuntu.com/security/CVE-2024-47743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: prevent NULL pointer dereference in find_asymmetric_key() In find_asymmetric_key(), if all NULLs are passed in the id_{0,1,2} arguments, the kernel will first emit WARN but then have an oops because id_2 gets dereferenced anyway. Add the missing id_2 check and move WARN_ON() to the final else branch to avoid duplicate NULL checks. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47727", "url": "https://ubuntu.com/security/CVE-2024-47727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/tdx: Fix \"in-kernel MMIO\" check TDX only supports kernel-initiated MMIO operations. The handle_mmio() function checks if the #VE exception occurred in the kernel and rejects the operation if it did not. However, userspace can deceive the kernel into performing MMIO on its behalf. For example, if userspace can point a syscall to an MMIO address, syscall does get_user() or put_user() on it, triggering MMIO #VE. The kernel will treat the #VE as in-kernel MMIO. Ensure that the target MMIO address is within the kernel before decoding instruction.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47744", "url": "https://ubuntu.com/security/CVE-2024-47744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Use dedicated mutex to protect kvm_usage_count to avoid deadlock Use a dedicated mutex to guard kvm_usage_count to fix a potential deadlock on x86 due to a chain of locks and SRCU synchronizations. Translating the below lockdep splat, CPU1 #6 will wait on CPU0 #1, CPU0 #8 will wait on CPU2 #3, and CPU2 #7 will wait on CPU1 #4 (if there's a writer, due to the fairness of r/w semaphores). CPU0 CPU1 CPU2 1 lock(&kvm->slots_lock); 2 lock(&vcpu->mutex); 3 lock(&kvm->srcu); 4 lock(cpu_hotplug_lock); 5 lock(kvm_lock); 6 lock(&kvm->slots_lock); 7 lock(cpu_hotplug_lock); 8 sync(&kvm->srcu); Note, there are likely more potential deadlocks in KVM x86, e.g. the same pattern of taking cpu_hotplug_lock outside of kvm_lock likely exists with __kvmclock_cpufreq_notifier(): cpuhp_cpufreq_online() | -> cpufreq_online() | -> cpufreq_gov_performance_limits() | -> __cpufreq_driver_target() | -> __target_index() | -> cpufreq_freq_transition_begin() | -> cpufreq_notify_transition() | -> ... __kvmclock_cpufreq_notifier() But, actually triggering such deadlocks is beyond rare due to the combination of dependencies and timings involved. E.g. the cpufreq notifier is only used on older CPUs without a constant TSC, mucking with the NX hugepage mitigation while VMs are running is very uncommon, and doing so while also onlining/offlining a CPU (necessary to generate contention on cpu_hotplug_lock) would be even more unusual. The most robust solution to the general cpu_hotplug_lock issue is likely to switch vm_list to be an RCU-protected list, e.g. so that x86's cpufreq notifier doesn't to take kvm_lock. For now, settle for fixing the most blatant deadlock, as switching to an RCU-protected list is a much more involved change, but add a comment in locking.rst to call out that care needs to be taken when walking holding kvm_lock and walking vm_list. ====================================================== WARNING: possible circular locking dependency detected 6.10.0-smp--c257535a0c9d-pip #330 Tainted: G S O ------------------------------------------------------ tee/35048 is trying to acquire lock: ff6a80eced71e0a8 (&kvm->slots_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x179/0x1e0 [kvm] but task is already holding lock: ffffffffc07abb08 (kvm_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x14a/0x1e0 [kvm] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (kvm_lock){+.+.}-{3:3}: __mutex_lock+0x6a/0xb40 mutex_lock_nested+0x1f/0x30 kvm_dev_ioctl+0x4fb/0xe50 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #2 (cpu_hotplug_lock){++++}-{0:0}: cpus_read_lock+0x2e/0xb0 static_key_slow_inc+0x16/0x30 kvm_lapic_set_base+0x6a/0x1c0 [kvm] kvm_set_apic_base+0x8f/0xe0 [kvm] kvm_set_msr_common+0x9ae/0xf80 [kvm] vmx_set_msr+0xa54/0xbe0 [kvm_intel] __kvm_set_msr+0xb6/0x1a0 [kvm] kvm_arch_vcpu_ioctl+0xeca/0x10c0 [kvm] kvm_vcpu_ioctl+0x485/0x5b0 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (&kvm->srcu){.+.+}-{0:0}: __synchronize_srcu+0x44/0x1a0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47719", "url": "https://ubuntu.com/security/CVE-2024-47719", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommufd: Protect against overflow of ALIGN() during iova allocation Userspace can supply an iova and uptr such that the target iova alignment becomes really big and ALIGN() overflows which corrupts the selected area range during allocation. CONFIG_IOMMUFD_TEST can detect this: WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline] WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352 Modules linked in: CPU: 1 PID: 5092 Comm: syz-executor294 Not tainted 6.10.0-rc5-syzkaller-00294-g3ffea9a7a6f7 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024 RIP: 0010:iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline] RIP: 0010:iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352 Code: fc e9 a4 f3 ff ff e8 1a 8b 4c fc 41 be e4 ff ff ff e9 8a f3 ff ff e8 0a 8b 4c fc 90 0f 0b 90 e9 37 f5 ff ff e8 fc 8a 4c fc 90 <0f> 0b 90 e9 68 f3 ff ff 48 c7 c1 ec 82 ad 8f 80 e1 07 80 c1 03 38 RSP: 0018:ffffc90003ebf9e0 EFLAGS: 00010293 RAX: ffffffff85499fa4 RBX: 00000000ffffffef RCX: ffff888079b49e00 RDX: 0000000000000000 RSI: 00000000ffffffef RDI: 0000000000000000 RBP: ffffc90003ebfc50 R08: ffffffff85499b30 R09: ffffffff85499942 R10: 0000000000000002 R11: ffff888079b49e00 R12: ffff8880228e0010 R13: 0000000000000000 R14: 1ffff920007d7f68 R15: ffffc90003ebfd00 FS: 000055557d760380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000005fdeb8 CR3: 000000007404a000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: iommufd_ioas_copy+0x610/0x7b0 drivers/iommu/iommufd/ioas.c:274 iommufd_fops_ioctl+0x4d9/0x5a0 drivers/iommu/iommufd/main.c:421 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Cap the automatic alignment to the huge page size, which is probably a better idea overall. Huge automatic alignments can fragment and chew up the available IOVA space without any reason.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47745", "url": "https://ubuntu.com/security/CVE-2024-47745", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: call the security_mmap_file() LSM hook in remap_file_pages() The remap_file_pages syscall handler calls do_mmap() directly, which doesn't contain the LSM security check. And if the process has called personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for RW pages, this will actually result in remapping the pages to RWX, bypassing a W^X policy enforced by SELinux. So we should check prot by security_mmap_file LSM hook in the remap_file_pages syscall handler before do_mmap() is called. Otherwise, it potentially permits an attacker to bypass a W^X policy enforced by SELinux. The bypass is similar to CVE-2016-10044, which bypass the same thing via AIO and can be found in [1]. The PoC: $ cat > test.c int main(void) { \tsize_t pagesz = sysconf(_SC_PAGE_SIZE); \tint mfd = syscall(SYS_memfd_create, \"test\", 0); \tconst char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE, \t\tMAP_SHARED, mfd, 0); \tunsigned int old = syscall(SYS_personality, 0xffffffff); \tsyscall(SYS_personality, READ_IMPLIES_EXEC | old); \tsyscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0); \tsyscall(SYS_personality, old); \t// show the RWX page exists even if W^X policy is enforced \tint fd = open(\"/proc/self/maps\", O_RDONLY); \tunsigned char buf2[1024]; \twhile (1) { \t\tint ret = read(fd, buf2, 1024); \t\tif (ret <= 0) break; \t\twrite(1, buf2, ret); \t} \tclose(fd); } $ gcc test.c -o test $ ./test | grep rwx 7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted) [PM: subject line tweaks]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47746", "url": "https://ubuntu.com/security/CVE-2024-47746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: use exclusive lock when FUSE_I_CACHE_IO_MODE is set This may be a typo. The comment has said shared locks are not allowed when this bit is set. If using shared lock, the wait in `fuse_file_cached_io_open` may be forever.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47734", "url": "https://ubuntu.com/security/CVE-2024-47734", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: Fix unnecessary warnings and logs from bond_xdp_get_xmit_slave() syzbot reported a WARNING in bond_xdp_get_xmit_slave. To reproduce this[1], one bond device (bond1) has xdpdrv, which increases bpf_master_redirect_enabled_key. Another bond device (bond0) which is unsupported by XDP but its slave (veth3) has xdpgeneric that returns XDP_TX. This triggers WARN_ON_ONCE() from the xdp_master_redirect(). To reduce unnecessary warnings and improve log management, we need to delete the WARN_ON_ONCE() and add ratelimit to the netdev_err(). [1] Steps to reproduce: # Needs tx_xdp with return XDP_TX; ip l add veth0 type veth peer veth1 ip l add veth3 type veth peer veth4 ip l add bond0 type bond mode 6 # BOND_MODE_ALB, unsupported by XDP ip l add bond1 type bond # BOND_MODE_ROUNDROBIN by default ip l set veth0 master bond1 ip l set bond1 up # Increases bpf_master_redirect_enabled_key ip l set dev bond1 xdpdrv object tx_xdp.o section xdp_tx ip l set veth3 master bond0 ip l set bond0 up ip l set veth4 up # Triggers WARN_ON_ONCE() from the xdp_master_redirect() ip l set veth3 xdpgeneric object tx_xdp.o section xdp_tx", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47684", "url": "https://ubuntu.com/security/CVE-2024-47684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: check skb is non-NULL in tcp_rto_delta_us() We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic kernel that are running ceph and recently hit a null ptr dereference in tcp_rearm_rto(). Initially hitting it from the TLP path, but then later we also saw it getting hit from the RACK case as well. Here are examples of the oops messages we saw in each of those cases: Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020 Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode Jul 26 15:05:02 rx [11061395.792971] #PF: error_code(0x0000) - not-present page Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0 Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI Jul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu Jul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023 Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 <48> 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3 Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246 Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000 Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60 Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8 Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900 Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30 Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000 Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0 Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554 Jul 26 15:05:02 rx [11061395.916786] Call Trace: Jul 26 15:05:02 rx [11061395.919488] Jul 26 15:05:02 rx [11061395.921765] ? show_regs.cold+0x1a/0x1f Jul 26 15:05:02 rx [11061395.925859] ? __die+0x90/0xd9 Jul 26 15:05:02 rx [11061395.929169] ? no_context+0x196/0x380 Jul 26 15:05:02 rx [11061395.933088] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0 Jul 26 15:05:02 rx [11061395.938216] ? ip6_sublist_rcv_finish+0x3d/0x50 Jul 26 15:05:02 rx [11061395.943000] ? __bad_area_nosemaphore+0x50/0x1a0 Jul 26 15:05:02 rx [11061395.947873] ? bad_area_nosemaphore+0x16/0x20 Jul 26 15:05:02 rx [11061395.952486] ? do_user_addr_fault+0x267/0x450 Jul 26 15:05:02 rx [11061395.957104] ? ipv6_list_rcv+0x112/0x140 Jul 26 15:05:02 rx [11061395.961279] ? __do_page_fault+0x58/0x90 Jul 26 15:05:02 rx [11061395.965458] ? do_page_fault+0x2c/0xe0 Jul 26 15:05:02 rx [11061395.969465] ? page_fault+0x34/0x40 Jul 26 15:05:02 rx [11061395.973217] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.977313] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.981408] tcp_send_loss_probe+0x10b/0x220 Jul 26 15:05:02 rx [11061395.985937] tcp_write_timer_handler+0x1b4/0x240 Jul 26 15:05:02 rx [11061395.990809] tcp_write_timer+0x9e/0xe0 Jul 26 15:05:02 rx [11061395.994814] ? tcp_write_timer_handler+0x240/0x240 Jul 26 15:05:02 rx [11061395.999866] call_timer_fn+0x32/0x130 Jul 26 15:05:02 rx [11061396.003782] __run_timers.part.0+0x180/0x280 Jul 26 15:05:02 rx [11061396.008309] ? recalibrate_cpu_khz+0x10/0x10 Jul 26 15:05:02 rx [11061396.012841] ? native_x2apic_icr_write+0x30/0x30 Jul 26 15:05:02 rx [11061396.017718] ? lapic_next_even ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47747", "url": "https://ubuntu.com/security/CVE-2024-47747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race Condition In the ether3_probe function, a timer is initialized with a callback function ether3_ledoff, bound to &prev(dev)->timer. Once the timer is started, there is a risk of a race condition if the module or device is removed, triggering the ether3_remove function to perform cleanup. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | ether3_ledoff ether3_remove | free_netdev(dev); | put_devic | kfree(dev); | | ether3_outw(priv(dev)->regs.config2 |= CFG2_CTRLO, REG_CONFIG2); | // use dev Fix it by ensuring that the timer is canceled before proceeding with the cleanup in ether3_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47685", "url": "https://ubuntu.com/security/CVE-2024-47685", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put() syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending garbage on the four reserved tcp bits (th->res1) Use skb_put_zero() to clear the whole TCP header, as done in nf_reject_ip_tcphdr_put() BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5661 [inline] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775 process_backlog+0x4ad/0xa50 net/core/dev.c:6108 __napi_poll+0xe7/0x980 net/core/dev.c:6772 napi_poll net/core/dev.c:6841 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963 handle_softirqs+0x1ce/0x800 kernel/softirq.c:554 __do_softirq+0x14/0x1a kernel/softirq.c:588 do_softirq+0x9a/0x100 kernel/softirq.c:455 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline] __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450 dev_queue_xmit include/linux/netdevice.h:3105 [inline] neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366 inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135 __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143 tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333 __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679 inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750 __sys_connect_file net/socket.c:2061 [inline] __sys_connect+0x606/0x690 net/socket.c:2078 __do_sys_connect net/socket.c:2088 [inline] __se_sys_connect net/socket.c:2085 [inline] __x64_sys_connect+0x91/0xe0 net/socket.c:2085 x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43 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 Uninit was stored to memory at: nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47686", "url": "https://ubuntu.com/security/CVE-2024-47686", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ep93xx: clock: Fix off by one in ep93xx_div_recalc_rate() The psc->div[] array has psc->num_div elements. These values come from when we call clk_hw_register_div(). It's adc_divisors and ARRAY_SIZE(adc_divisors)) and so on. So this condition needs to be >= instead of > to prevent an out of bounds read.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47748", "url": "https://ubuntu.com/security/CVE-2024-47748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost_vdpa: assign irq bypass producer token correctly We used to call irq_bypass_unregister_producer() in vhost_vdpa_setup_vq_irq() which is problematic as we don't know if the token pointer is still valid or not. Actually, we use the eventfd_ctx as the token so the life cycle of the token should be bound to the VHOST_SET_VRING_CALL instead of vhost_vdpa_setup_vq_irq() which could be called by set_status(). Fixing this by setting up irq bypass producer's token when handling VHOST_SET_VRING_CALL and un-registering the producer before calling vhost_vring_ioctl() to prevent a possible use after free as eventfd could have been released in vhost_vring_ioctl(). And such registering and unregistering will only be done if DRIVER_OK is set.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47687", "url": "https://ubuntu.com/security/CVE-2024-47687", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa/mlx5: Fix invalid mr resource destroy Certain error paths from mlx5_vdpa_dev_add() can end up releasing mr resources which never got initialized in the first place. This patch adds the missing check in mlx5_vdpa_destroy_mr_resources() to block releasing non-initialized mr resources. Reference trace: mlx5_core 0000:08:00.2: mlx5_vdpa_dev_add:3274:(pid 2700) warning: No mac address provisioned? BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 140216067 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 8 PID: 2700 Comm: vdpa Kdump: loaded Not tainted 5.14.0-496.el9.x86_64 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:vhost_iotlb_del_range+0xf/0xe0 [vhost_iotlb] Code: [...] RSP: 0018:ff1c823ac23077f0 EFLAGS: 00010246 RAX: ffffffffc1a21a60 RBX: ffffffff899567a0 RCX: 0000000000000000 RDX: ffffffffffffffff RSI: 0000000000000000 RDI: 0000000000000000 RBP: ff1bda1f7c21e800 R08: 0000000000000000 R09: ff1c823ac2307670 R10: ff1c823ac2307668 R11: ffffffff8a9e7b68 R12: 0000000000000000 R13: 0000000000000000 R14: ff1bda1f43e341a0 R15: 00000000ffffffea FS: 00007f56eba7c740(0000) GS:ff1bda269f800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000104d90001 CR4: 0000000000771ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? mlx5_vdpa_free+0x3d/0x150 [mlx5_vdpa] ? __die_body.cold+0x8/0xd ? page_fault_oops+0x134/0x170 ? __irq_work_queue_local+0x2b/0xc0 ? irq_work_queue+0x2c/0x50 ? exc_page_fault+0x62/0x150 ? asm_exc_page_fault+0x22/0x30 ? __pfx_mlx5_vdpa_free+0x10/0x10 [mlx5_vdpa] ? vhost_iotlb_del_range+0xf/0xe0 [vhost_iotlb] mlx5_vdpa_free+0x3d/0x150 [mlx5_vdpa] vdpa_release_dev+0x1e/0x50 [vdpa] device_release+0x31/0x90 kobject_cleanup+0x37/0x130 mlx5_vdpa_dev_add+0x2d2/0x7a0 [mlx5_vdpa] vdpa_nl_cmd_dev_add_set_doit+0x277/0x4c0 [vdpa] genl_family_rcv_msg_doit+0xd9/0x130 genl_family_rcv_msg+0x14d/0x220 ? __pfx_vdpa_nl_cmd_dev_add_set_doit+0x10/0x10 [vdpa] ? _copy_to_user+0x1a/0x30 ? move_addr_to_user+0x4b/0xe0 genl_rcv_msg+0x47/0xa0 ? __import_iovec+0x46/0x150 ? __pfx_genl_rcv_msg+0x10/0x10 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x245/0x370 netlink_sendmsg+0x206/0x440 __sys_sendto+0x1dc/0x1f0 ? do_read_fault+0x10c/0x1d0 ? do_pte_missing+0x10d/0x190 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x5c/0xf0 ? __count_memcg_events+0x4f/0xb0 ? mm_account_fault+0x6c/0x100 ? handle_mm_fault+0x116/0x270 ? do_user_addr_fault+0x1d6/0x6a0 ? do_syscall_64+0x6b/0xf0 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 entry_SYSCALL_64_after_hwframe+0x78/0x80", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47688", "url": "https://ubuntu.com/security/CVE-2024-47688", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: driver core: Fix a potential null-ptr-deref in module_add_driver() Inject fault while probing of-fpga-region, if kasprintf() fails in module_add_driver(), the second sysfs_remove_link() in exit path will cause null-ptr-deref as below because kernfs_name_hash() will call strlen() with NULL driver_name. Fix it by releasing resources based on the exit path sequence. \t KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] \t Mem abort info: \t ESR = 0x0000000096000005 \t EC = 0x25: DABT (current EL), IL = 32 bits \t SET = 0, FnV = 0 \t EA = 0, S1PTW = 0 \t FSC = 0x05: level 1 translation fault \t Data abort info: \t ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 \t CM = 0, WnR = 0, TnD = 0, TagAccess = 0 \t GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 \t [dfffffc000000000] address between user and kernel address ranges \t Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP \t Dumping ftrace buffer: \t (ftrace buffer empty) \t Modules linked in: of_fpga_region(+) fpga_region fpga_bridge cfg80211 rfkill 8021q garp mrp stp llc ipv6 [last unloaded: of_fpga_region] \t CPU: 2 UID: 0 PID: 2036 Comm: modprobe Not tainted 6.11.0-rc2-g6a0e38264012 #295 \t Hardware name: linux,dummy-virt (DT) \t pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) \t pc : strlen+0x24/0xb0 \t lr : kernfs_name_hash+0x1c/0xc4 \t sp : ffffffc081f97380 \t x29: ffffffc081f97380 x28: ffffffc081f97b90 x27: ffffff80c821c2a0 \t x26: ffffffedac0be418 x25: 0000000000000000 x24: ffffff80c09d2000 \t x23: 0000000000000000 x22: 0000000000000000 x21: 0000000000000000 \t x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000001840 \t x17: 0000000000000000 x16: 0000000000000000 x15: 1ffffff8103f2e42 \t x14: 00000000f1f1f1f1 x13: 0000000000000004 x12: ffffffb01812d61d \t x11: 1ffffff01812d61c x10: ffffffb01812d61c x9 : dfffffc000000000 \t x8 : 0000004fe7ed29e4 x7 : ffffff80c096b0e7 x6 : 0000000000000001 \t x5 : ffffff80c096b0e0 x4 : 1ffffffdb990efa2 x3 : 0000000000000000 \t x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000000 \t Call trace: \t strlen+0x24/0xb0 \t kernfs_name_hash+0x1c/0xc4 \t kernfs_find_ns+0x118/0x2e8 \t kernfs_remove_by_name_ns+0x80/0x100 \t sysfs_remove_link+0x74/0xa8 \t module_add_driver+0x278/0x394 \t bus_add_driver+0x1f0/0x43c \t driver_register+0xf4/0x3c0 \t __platform_driver_register+0x60/0x88 \t of_fpga_region_init+0x20/0x1000 [of_fpga_region] \t do_one_initcall+0x110/0x788 \t do_init_module+0x1dc/0x5c8 \t load_module+0x3c38/0x4cac \t init_module_from_file+0xd4/0x128 \t idempotent_init_module+0x2cc/0x528 \t __arm64_sys_finit_module+0xac/0x100 \t invoke_syscall+0x6c/0x258 \t el0_svc_common.constprop.0+0x160/0x22c \t do_el0_svc+0x44/0x5c \t el0_svc+0x48/0xb8 \t el0t_64_sync_handler+0x13c/0x158 \t el0t_64_sync+0x190/0x194 \t Code: f2fbffe1 a90157f4 12000802 aa0003f5 (38e16861) \t ---[ end trace 0000000000000000 ]--- \t Kernel panic - not syncing: Oops: Fatal exception", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47689", "url": "https://ubuntu.com/security/CVE-2024-47689", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to don't set SB_RDONLY in f2fs_handle_critical_error() syzbot reports a f2fs bug as below: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 58 at kernel/rcu/sync.c:177 rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177 CPU: 1 UID: 0 PID: 58 Comm: kworker/1:2 Not tainted 6.10.0-syzkaller-12562-g1722389b0d86 #0 Workqueue: events destroy_super_work RIP: 0010:rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177 Call Trace: percpu_free_rwsem+0x41/0x80 kernel/locking/percpu-rwsem.c:42 destroy_super_work+0xec/0x130 fs/super.c:282 process_one_work kernel/workqueue.c:3231 [inline] process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 worker_thread+0x86d/0xd40 kernel/workqueue.c:3390 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 As Christian Brauner pointed out [1]: the root cause is f2fs sets SB_RDONLY flag in internal function, rather than setting the flag covered w/ sb->s_umount semaphore via remount procedure, then below race condition causes this bug: - freeze_super() - sb_wait_write(sb, SB_FREEZE_WRITE) - sb_wait_write(sb, SB_FREEZE_PAGEFAULT) - sb_wait_write(sb, SB_FREEZE_FS) \t\t\t\t\t- f2fs_handle_critical_error \t\t\t\t\t - sb->s_flags |= SB_RDONLY - thaw_super - thaw_super_locked - sb_rdonly() is true, so it skips sb_freeze_unlock(sb, SB_FREEZE_FS) - deactivate_locked_super Since f2fs has almost the same logic as ext4 [2] when handling critical error in filesystem if it mounts w/ errors=remount-ro option: - set CP_ERROR_FLAG flag which indicates filesystem is stopped - record errors to superblock - set SB_RDONLY falg Once we set CP_ERROR_FLAG flag, all writable interfaces can detect the flag and stop any further updates on filesystem. So, it is safe to not set SB_RDONLY flag, let's remove the logic and keep in line w/ ext4 [3]. [1] https://lore.kernel.org/all/20240729-himbeeren-funknetz-96e62f9c7aee@brauner [2] https://lore.kernel.org/all/20240729132721.hxih6ehigadqf7wx@quack3 [3] https://lore.kernel.org/linux-ext4/20240805201241.27286-1-jack@suse.cz", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47690", "url": "https://ubuntu.com/security/CVE-2024-47690", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: get rid of online repaire on corrupted directory syzbot reports a f2fs bug as below: kernel BUG at fs/f2fs/inode.c:896! RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Call Trace: evict+0x532/0x950 fs/inode.c:704 dispose_list fs/inode.c:747 [inline] evict_inodes+0x5f9/0x690 fs/inode.c:797 generic_shutdown_super+0x9d/0x2d0 fs/super.c:627 kill_block_super+0x44/0x90 fs/super.c:1696 kill_f2fs_super+0x344/0x690 fs/f2fs/super.c:4898 deactivate_locked_super+0xc4/0x130 fs/super.c:473 cleanup_mnt+0x41f/0x4b0 fs/namespace.c:1373 task_work_run+0x24f/0x310 kernel/task_work.c:228 ptrace_notify+0x2d2/0x380 kernel/signal.c:2402 ptrace_report_syscall include/linux/ptrace.h:415 [inline] ptrace_report_syscall_exit include/linux/ptrace.h:477 [inline] syscall_exit_work+0xc6/0x190 kernel/entry/common.c:173 syscall_exit_to_user_mode_prepare kernel/entry/common.c:200 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:205 [inline] syscall_exit_to_user_mode+0x279/0x370 kernel/entry/common.c:218 do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Online repaire on corrupted directory in f2fs_lookup() can generate dirty data/meta while racing w/ readonly remount, it may leave dirty inode after filesystem becomes readonly, however, checkpoint() will skips flushing dirty inode in a state of readonly mode, result in above panic. Let's get rid of online repaire in f2fs_lookup(), and leave the work to fsck.f2fs.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47691", "url": "https://ubuntu.com/security/CVE-2024-47691", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread() syzbot reports a f2fs bug as below: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_report+0xe8/0x550 mm/kasan/report.c:491 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 instrument_atomic_read_write include/linux/instrumented.h:96 [inline] atomic_fetch_add_relaxed include/linux/atomic/atomic-instrumented.h:252 [inline] __refcount_add include/linux/refcount.h:184 [inline] __refcount_inc include/linux/refcount.h:241 [inline] refcount_inc include/linux/refcount.h:258 [inline] get_task_struct include/linux/sched/task.h:118 [inline] kthread_stop+0xca/0x630 kernel/kthread.c:704 f2fs_stop_gc_thread+0x65/0xb0 fs/f2fs/gc.c:210 f2fs_do_shutdown+0x192/0x540 fs/f2fs/file.c:2283 f2fs_ioc_shutdown fs/f2fs/file.c:2325 [inline] __f2fs_ioctl+0x443a/0xbe60 fs/f2fs/file.c:4325 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f The root cause is below race condition, it may cause use-after-free issue in sbi->gc_th pointer. - remount - f2fs_remount - f2fs_stop_gc_thread - kfree(gc_th) \t\t\t\t- f2fs_ioc_shutdown \t\t\t\t - f2fs_do_shutdown \t\t\t\t - f2fs_stop_gc_thread \t\t\t\t - kthread_stop(gc_th->f2fs_gc_task) : sbi->gc_thread = NULL; We will call f2fs_do_shutdown() in two paths: - for f2fs_ioc_shutdown() path, we should grab sb->s_umount semaphore for fixing. - for f2fs_shutdown() path, it's safe since caller has already grabbed sb->s_umount semaphore.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47692", "url": "https://ubuntu.com/security/CVE-2024-47692", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: return -EINVAL when namelen is 0 When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may result in namelen being 0, which will cause memdup_user() to return ZERO_SIZE_PTR. When we access the name.data that has been assigned the value of ZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is triggered. [ T1205] ================================================================== [ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260 [ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205 [ T1205] [ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406 [ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ T1205] Call Trace: [ T1205] dump_stack+0x9a/0xd0 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] __kasan_report.cold+0x34/0x84 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] kasan_report+0x3a/0x50 [ T1205] nfs4_client_to_reclaim+0xe9/0x260 [ T1205] ? nfsd4_release_lockowner+0x410/0x410 [ T1205] cld_pipe_downcall+0x5ca/0x760 [ T1205] ? nfsd4_cld_tracking_exit+0x1d0/0x1d0 [ T1205] ? down_write_killable_nested+0x170/0x170 [ T1205] ? avc_policy_seqno+0x28/0x40 [ T1205] ? selinux_file_permission+0x1b4/0x1e0 [ T1205] rpc_pipe_write+0x84/0xb0 [ T1205] vfs_write+0x143/0x520 [ T1205] ksys_write+0xc9/0x170 [ T1205] ? __ia32_sys_read+0x50/0x50 [ T1205] ? ktime_get_coarse_real_ts64+0xfe/0x110 [ T1205] ? ktime_get_coarse_real_ts64+0xa2/0x110 [ T1205] do_syscall_64+0x33/0x40 [ T1205] entry_SYSCALL_64_after_hwframe+0x67/0xd1 [ T1205] RIP: 0033:0x7fdbdb761bc7 [ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 514 [ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7 [ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008 [ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001 [ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b [ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000 [ T1205] ================================================================== Fix it by checking namelen.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47737", "url": "https://ubuntu.com/security/CVE-2024-47737", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: call cache_put if xdr_reserve_space returns NULL If not enough buffer space available, but idmap_lookup has triggered lookup_fn which calls cache_get and returns successfully. Then we missed to call cache_put here which pairs with cache_get. Reviwed-by: Jeff Layton ", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2023-52917", "url": "https://ubuntu.com/security/CVE-2023-52917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir() The debugfs_create_dir() function returns error pointers. It never returns NULL. So use IS_ERR() to check it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47749", "url": "https://ubuntu.com/security/CVE-2024-47749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Added NULL check for lookup_atid The lookup_atid() function can return NULL if the ATID is invalid or does not exist in the identifier table, which could lead to dereferencing a null pointer without a check in the `act_establish()` and `act_open_rpl()` functions. Add a NULL check to prevent null pointer dereferencing. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47735", "url": "https://ubuntu.com/security/CVE-2024-47735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled Fix missuse of spin_lock_irq()/spin_unlock_irq() when spin_lock_irqsave()/spin_lock_irqrestore() was hold. This was discovered through the lock debugging, and the corresponding log is as follows: raw_local_irq_restore() called with IRQs enabled WARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40 ... Call trace: warn_bogus_irq_restore+0x30/0x40 _raw_spin_unlock_irqrestore+0x84/0xc8 add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2] hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2] hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2] create_qp+0x138/0x258 ib_create_qp_kernel+0x50/0xe8 create_mad_qp+0xa8/0x128 ib_mad_port_open+0x218/0x448 ib_mad_init_device+0x70/0x1f8 add_client_context+0xfc/0x220 enable_device_and_get+0xd0/0x140 ib_register_device.part.0+0xf4/0x1c8 ib_register_device+0x34/0x50 hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2] hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2] __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2] hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47750", "url": "https://ubuntu.com/security/CVE-2024-47750", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix Use-After-Free of rsv_qp on HIP08 Currently rsv_qp is freed before ib_unregister_device() is called on HIP08. During the time interval, users can still dereg MR and rsv_qp will be used in this process, leading to a UAF. Move the release of rsv_qp after calling ib_unregister_device() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47751", "url": "https://ubuntu.com/security/CVE-2024-47751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: kirin: Fix buffer overflow in kirin_pcie_parse_port() Within kirin_pcie_parse_port(), the pcie->num_slots is compared to pcie->gpio_id_reset size (MAX_PCI_SLOTS) which is correct and would lead to an overflow. Thus, fix condition to pcie->num_slots + 1 >= MAX_PCI_SLOTS and move pcie->num_slots increment below the if-statement to avoid out-of-bounds array access. Found by Linux Verification Center (linuxtesting.org) with SVACE. [kwilczynski: commit log]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47693", "url": "https://ubuntu.com/security/CVE-2024-47693", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/core: Fix ib_cache_setup_one error flow cleanup When ib_cache_update return an error, we exit ib_cache_setup_one instantly with no proper cleanup, even though before this we had already successfully done gid_table_setup_one, that results in the kernel WARN below. Do proper cleanup using gid_table_cleanup_one before returning the err in order to fix the issue. WARNING: CPU: 4 PID: 922 at drivers/infiniband/core/cache.c:806 gid_table_release_one+0x181/0x1a0 Modules linked in: CPU: 4 UID: 0 PID: 922 Comm: c_repro Not tainted 6.11.0-rc1+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:gid_table_release_one+0x181/0x1a0 Code: 44 8b 38 75 0c e8 2f cb 34 ff 4d 8b b5 28 05 00 00 e8 23 cb 34 ff 44 89 f9 89 da 4c 89 f6 48 c7 c7 d0 58 14 83 e8 4f de 21 ff <0f> 0b 4c 8b 75 30 e9 54 ff ff ff 48 8 3 c4 10 5b 5d 41 5c 41 5d 41 RSP: 0018:ffffc90002b835b0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c8527 RDX: 0000000000000000 RSI: ffffffff811c8534 RDI: 0000000000000001 RBP: ffff8881011b3d00 R08: ffff88810b3abe00 R09: 205d303839303631 R10: 666572207972746e R11: 72746e6520444947 R12: 0000000000000001 R13: ffff888106390000 R14: ffff8881011f2110 R15: 0000000000000001 FS: 00007fecc3b70800(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000340 CR3: 000000010435a001 CR4: 00000000003706b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? show_regs+0x94/0xa0 ? __warn+0x9e/0x1c0 ? gid_table_release_one+0x181/0x1a0 ? report_bug+0x1f9/0x340 ? gid_table_release_one+0x181/0x1a0 ? handle_bug+0xa2/0x110 ? exc_invalid_op+0x31/0xa0 ? asm_exc_invalid_op+0x16/0x20 ? __warn_printk+0xc7/0x180 ? __warn_printk+0xd4/0x180 ? gid_table_release_one+0x181/0x1a0 ib_device_release+0x71/0xe0 ? __pfx_ib_device_release+0x10/0x10 device_release+0x44/0xd0 kobject_put+0x135/0x3d0 put_device+0x20/0x30 rxe_net_add+0x7d/0xa0 rxe_newlink+0xd7/0x190 nldev_newlink+0x1b0/0x2a0 ? __pfx_nldev_newlink+0x10/0x10 rdma_nl_rcv_msg+0x1ad/0x2e0 rdma_nl_rcv_skb.constprop.0+0x176/0x210 netlink_unicast+0x2de/0x400 netlink_sendmsg+0x306/0x660 __sock_sendmsg+0x110/0x120 ____sys_sendmsg+0x30e/0x390 ___sys_sendmsg+0x9b/0xf0 ? kstrtouint+0x6e/0xa0 ? kstrtouint_from_user+0x7c/0xb0 ? get_pid_task+0xb0/0xd0 ? proc_fail_nth_write+0x5b/0x140 ? __fget_light+0x9a/0x200 ? preempt_count_add+0x47/0xa0 __sys_sendmsg+0x61/0xd0 do_syscall_64+0x50/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47694", "url": "https://ubuntu.com/security/CVE-2024-47694", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mlx5: Fix UMR pd cleanup on error flow of driver init The cited commit moves the pd allocation from function mlx5r_umr_resource_cleanup() to a new function mlx5r_umr_cleanup(). So the fix in commit [1] is broken. In error flow, will hit panic [2]. Fix it by checking pd pointer to avoid panic if it is NULL; [1] RDMA/mlx5: Fix UMR cleanup on error flow of driver init [2] [ 347.567063] infiniband mlx5_0: Couldn't register device with driver model [ 347.591382] BUG: kernel NULL pointer dereference, address: 0000000000000020 [ 347.593438] #PF: supervisor read access in kernel mode [ 347.595176] #PF: error_code(0x0000) - not-present page [ 347.596962] PGD 0 P4D 0 [ 347.601361] RIP: 0010:ib_dealloc_pd_user+0x12/0xc0 [ib_core] [ 347.604171] RSP: 0018:ffff888106293b10 EFLAGS: 00010282 [ 347.604834] RAX: 0000000000000000 RBX: 000000000000000e RCX: 0000000000000000 [ 347.605672] RDX: ffff888106293ad0 RSI: 0000000000000000 RDI: 0000000000000000 [ 347.606529] RBP: 0000000000000000 R08: ffff888106293ae0 R09: ffff888106293ae0 [ 347.607379] R10: 0000000000000a06 R11: 0000000000000000 R12: 0000000000000000 [ 347.608224] R13: ffffffffa0704dc0 R14: 0000000000000001 R15: 0000000000000001 [ 347.609067] FS: 00007fdc720cd9c0(0000) GS:ffff88852c880000(0000) knlGS:0000000000000000 [ 347.610094] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 347.610727] CR2: 0000000000000020 CR3: 0000000103012003 CR4: 0000000000370eb0 [ 347.611421] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 347.612113] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 347.612804] Call Trace: [ 347.613130] [ 347.613417] ? __die+0x20/0x60 [ 347.613793] ? page_fault_oops+0x150/0x3e0 [ 347.614243] ? free_msg+0x68/0x80 [mlx5_core] [ 347.614840] ? cmd_exec+0x48f/0x11d0 [mlx5_core] [ 347.615359] ? exc_page_fault+0x74/0x130 [ 347.615808] ? asm_exc_page_fault+0x22/0x30 [ 347.616273] ? ib_dealloc_pd_user+0x12/0xc0 [ib_core] [ 347.616801] mlx5r_umr_cleanup+0x23/0x90 [mlx5_ib] [ 347.617365] mlx5_ib_stage_pre_ib_reg_umr_cleanup+0x36/0x40 [mlx5_ib] [ 347.618025] __mlx5_ib_add+0x96/0xd0 [mlx5_ib] [ 347.618539] mlx5r_probe+0xe9/0x310 [mlx5_ib] [ 347.619032] ? kernfs_add_one+0x107/0x150 [ 347.619478] ? __mlx5_ib_add+0xd0/0xd0 [mlx5_ib] [ 347.619984] auxiliary_bus_probe+0x3e/0x90 [ 347.620448] really_probe+0xc5/0x3a0 [ 347.620857] __driver_probe_device+0x80/0x160 [ 347.621325] driver_probe_device+0x1e/0x90 [ 347.621770] __driver_attach+0xec/0x1c0 [ 347.622213] ? __device_attach_driver+0x100/0x100 [ 347.622724] bus_for_each_dev+0x71/0xc0 [ 347.623151] bus_add_driver+0xed/0x240 [ 347.623570] driver_register+0x58/0x100 [ 347.623998] __auxiliary_driver_register+0x6a/0xc0 [ 347.624499] ? driver_register+0xae/0x100 [ 347.624940] ? 0xffffffffa0893000 [ 347.625329] mlx5_ib_init+0x16a/0x1e0 [mlx5_ib] [ 347.625845] do_one_initcall+0x4a/0x2a0 [ 347.626273] ? gcov_event+0x2e2/0x3a0 [ 347.626706] do_init_module+0x8a/0x260 [ 347.627126] init_module_from_file+0x8b/0xd0 [ 347.627596] __x64_sys_finit_module+0x1ca/0x2f0 [ 347.628089] do_syscall_64+0x4c/0x100", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47695", "url": "https://ubuntu.com/security/CVE-2024-47695", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds In the function init_conns(), after the create_con() and create_cm() for loop if something fails. In the cleanup for loop after the destroy tag, we access out of bound memory because cid is set to clt_path->s.con_num. This commits resets the cid to clt_path->s.con_num - 1, to stay in bounds in the cleanup loop later.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47752", "url": "https://ubuntu.com/security/CVE-2024-47752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix H264 stateless decoder smatch warning Fix a smatch static checker warning on vdec_h264_req_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47753", "url": "https://ubuntu.com/security/CVE-2024-47753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix VP8 stateless decoder smatch warning Fix a smatch static checker warning on vdec_vp8_req_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47754", "url": "https://ubuntu.com/security/CVE-2024-47754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix H264 multi stateless decoder smatch warning Fix a smatch static checker warning on vdec_h264_req_multi_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47696", "url": "https://ubuntu.com/security/CVE-2024-47696", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency In the commit aee2424246f9 (\"RDMA/iwcm: Fix a use-after-free related to destroying CM IDs\"), the function flush_workqueue is invoked to flush the work queue iwcm_wq. But at that time, the work queue iwcm_wq was created via the function alloc_ordered_workqueue without the flag WQ_MEM_RECLAIM. Because the current process is trying to flush the whole iwcm_wq, if iwcm_wq doesn't have the flag WQ_MEM_RECLAIM, verify that the current process is not reclaiming memory or running on a workqueue which doesn't have the flag WQ_MEM_RECLAIM as that can break forward-progress guarantee leading to a deadlock. The call trace is as below: [ 125.350876][ T1430] Call Trace: [ 125.356281][ T1430] [ 125.361285][ T1430] ? __warn (kernel/panic.c:693) [ 125.367640][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.375689][ T1430] ? report_bug (lib/bug.c:180 lib/bug.c:219) [ 125.382505][ T1430] ? handle_bug (arch/x86/kernel/traps.c:239) [ 125.388987][ T1430] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) [ 125.395831][ T1430] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621) [ 125.403125][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.410984][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.418764][ T1430] __flush_workqueue (kernel/workqueue.c:3970) [ 125.426021][ T1430] ? __pfx___might_resched (kernel/sched/core.c:10151) [ 125.433431][ T1430] ? destroy_cm_id (drivers/infiniband/core/iwcm.c:375) iw_cm [ 125.441209][ T1430] ? __pfx___flush_workqueue (kernel/workqueue.c:3910) [ 125.473900][ T1430] ? _raw_spin_lock_irqsave (arch/x86/include/asm/atomic.h:107 include/linux/atomic/atomic-arch-fallback.h:2170 include/linux/atomic/atomic-instrumented.h:1302 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162) [ 125.473909][ T1430] ? __pfx__raw_spin_lock_irqsave (kernel/locking/spinlock.c:161) [ 125.482537][ T1430] _destroy_id (drivers/infiniband/core/cma.c:2044) rdma_cm [ 125.495072][ T1430] nvme_rdma_free_queue (drivers/nvme/host/rdma.c:656 drivers/nvme/host/rdma.c:650) nvme_rdma [ 125.505827][ T1430] nvme_rdma_reset_ctrl_work (drivers/nvme/host/rdma.c:2180) nvme_rdma [ 125.505831][ T1430] process_one_work (kernel/workqueue.c:3231) [ 125.515122][ T1430] worker_thread (kernel/workqueue.c:3306 kernel/workqueue.c:3393) [ 125.515127][ T1430] ? __pfx_worker_thread (kernel/workqueue.c:3339) [ 125.531837][ T1430] kthread (kernel/kthread.c:389) [ 125.539864][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.550628][ T1430] ret_from_fork (arch/x86/kernel/process.c:147) [ 125.558840][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.558844][ T1430] ret_from_fork_asm (arch/x86/entry/entry_64.S:257) [ 125.566487][ T1430] [ 125.566488][ T1430] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47755", "url": "https://ubuntu.com/security/CVE-2024-47755", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47756", "url": "https://ubuntu.com/security/CVE-2024-47756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: keystone: Fix if-statement expression in ks_pcie_quirk() This code accidentally uses && where || was intended. It potentially results in a NULL dereference. Thus, fix the if-statement expression to use the correct condition. [kwilczynski: commit log]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47697", "url": "https://ubuntu.com/security/CVE-2024-47697", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error Ensure index in rtl2830_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47698", "url": "https://ubuntu.com/security/CVE-2024-47698", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error Ensure index in rtl2832_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue. [hverkuil: added fixes tag, rtl2830_pid_filter -> rtl2832_pid_filter in logmsg]", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47728", "url": "https://ubuntu.com/security/CVE-2024-47728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error For all non-tracing helpers which formerly had ARG_PTR_TO_{LONG,INT} as input arguments, zero the value for the case of an error as otherwise it could leak memory. For tracing, it is not needed given CAP_PERFMON can already read all kernel memory anyway hence bpf_get_func_arg() and bpf_get_func_ret() is skipped in here. Also, the MTU helpers mtu_len pointer value is being written but also read. Technically, the MEM_UNINIT should not be there in order to always force init. Removing MEM_UNINIT needs more verifier rework though: MEM_UNINIT right now implies two things actually: i) write into memory, ii) memory does not have to be initialized. If we lift MEM_UNINIT, it then becomes: i) read into memory, ii) memory must be initialized. This means that for bpf_*_check_mtu() we're readding the issue we're trying to fix, that is, it would then be able to write back into things like .rodata BPF maps. Follow-up work will rework the MEM_UNINIT semantics such that the intent can be better expressed. For now just clear the *mtu_len on error path which can be lifted later again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49861", "url": "https://ubuntu.com/security/CVE-2024-49861", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix helper writes to read-only maps Lonial found an issue that despite user- and BPF-side frozen BPF map (like in case of .rodata), it was still possible to write into it from a BPF program side through specific helpers having ARG_PTR_TO_{LONG,INT} as arguments. In check_func_arg() when the argument is as mentioned, the meta->raw_mode is never set. Later, check_helper_mem_access(), under the case of PTR_TO_MAP_VALUE as register base type, it assumes BPF_READ for the subsequent call to check_map_access_type() and given the BPF map is read-only it succeeds. The helpers really need to be annotated as ARG_PTR_TO_{LONG,INT} | MEM_UNINIT when results are written into them as opposed to read out of them. The latter indicates that it's okay to pass a pointer to uninitialized memory as the memory is written to anyway. However, ARG_PTR_TO_{LONG,INT} is a special case of ARG_PTR_TO_FIXED_SIZE_MEM just with additional alignment requirement. So it is better to just get rid of the ARG_PTR_TO_{LONG,INT} special cases altogether and reuse the fixed size memory types. For this, add MEM_ALIGNED to additionally ensure alignment given these helpers write directly into the args via * = val. The .arg*_size has been initialized reflecting the actual sizeof(*). MEM_ALIGNED can only be used in combination with MEM_FIXED_SIZE annotated argument types, since in !MEM_FIXED_SIZE cases the verifier does not know the buffer size a priori and therefore cannot blindly write * = val.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47757", "url": "https://ubuntu.com/security/CVE-2024-47757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential oob read in nilfs_btree_check_delete() The function nilfs_btree_check_delete(), which checks whether degeneration to direct mapping occurs before deleting a b-tree entry, causes memory access outside the block buffer when retrieving the maximum key if the root node has no entries. This does not usually happen because b-tree mappings with 0 child nodes are never created by mkfs.nilfs2 or nilfs2 itself. However, it can happen if the b-tree root node read from a device is configured that way, so fix this potential issue by adding a check for that case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47699", "url": "https://ubuntu.com/security/CVE-2024-47699", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential null-ptr-deref in nilfs_btree_insert() Patch series \"nilfs2: fix potential issues with empty b-tree nodes\". This series addresses three potential issues with empty b-tree nodes that can occur with corrupted filesystem images, including one recently discovered by syzbot. This patch (of 3): If a b-tree is broken on the device, and the b-tree height is greater than 2 (the level of the root node is greater than 1) even if the number of child nodes of the b-tree root is 0, a NULL pointer dereference occurs in nilfs_btree_prepare_insert(), which is called from nilfs_btree_insert(). This is because, when the number of child nodes of the b-tree root is 0, nilfs_btree_do_lookup() does not set the block buffer head in any of path[x].bp_bh, leaving it as the initial value of NULL, but if the level of the b-tree root node is greater than 1, nilfs_btree_get_nonroot_node(), which accesses the buffer memory of path[x].bp_bh, is called. Fix this issue by adding a check to nilfs_btree_root_broken(), which performs sanity checks when reading the root node from the device, to detect this inconsistency. Thanks to Lizhi Xu for trying to solve the bug and clarifying the cause early on.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47700", "url": "https://ubuntu.com/security/CVE-2024-47700", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: check stripe size compatibility on remount as well We disable stripe size in __ext4_fill_super if it is not a multiple of the cluster ratio however this check is missed when trying to remount. This can leave us with cases where stripe < cluster_ratio after remount:set making EXT4_B2C(sbi->s_stripe) become 0 that can cause some unforeseen bugs like divide by 0. Fix that by adding the check in remount path as well.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47701", "url": "https://ubuntu.com/security/CVE-2024-47701", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid OOB when system.data xattr changes underneath the filesystem When looking up for an entry in an inlined directory, if e_value_offs is changed underneath the filesystem by some change in the block device, it will lead to an out-of-bounds access that KASAN detects as an UAF. EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none. loop0: detected capacity change from 2048 to 2047 ================================================================== BUG: KASAN: use-after-free in ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 Read of size 1 at addr ffff88803e91130f by task syz-executor269/5103 CPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 Not tainted 6.11.0-rc4-syzkaller #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:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 ext4_find_inline_entry+0x4be/0x5e0 fs/ext4/inline.c:1697 __ext4_find_entry+0x2b4/0x1b30 fs/ext4/namei.c:1573 ext4_lookup_entry fs/ext4/namei.c:1727 [inline] ext4_lookup+0x15f/0x750 fs/ext4/namei.c:1795 lookup_one_qstr_excl+0x11f/0x260 fs/namei.c:1633 filename_create+0x297/0x540 fs/namei.c:3980 do_symlinkat+0xf9/0x3a0 fs/namei.c:4587 __do_sys_symlinkat fs/namei.c:4610 [inline] __se_sys_symlinkat fs/namei.c:4607 [inline] __x64_sys_symlinkat+0x95/0xb0 fs/namei.c:4607 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:0x7f3e73ced469 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff4d40c258 EFLAGS: 00000246 ORIG_RAX: 000000000000010a RAX: ffffffffffffffda RBX: 0032656c69662f2e RCX: 00007f3e73ced469 RDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0 RBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290 R10: 0023706f6f6c2f76 R11: 0000000000000246 R12: 00007fff4d40c27c R13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0 Calling ext4_xattr_ibody_find right after reading the inode with ext4_get_inode_loc will lead to a check of the validity of the xattrs, avoiding this problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49850", "url": "https://ubuntu.com/security/CVE-2024-49850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: correctly handle malformed BPF_CORE_TYPE_ID_LOCAL relos In case of malformed relocation record of kind BPF_CORE_TYPE_ID_LOCAL referencing a non-existing BTF type, function bpf_core_calc_relo_insn would cause a null pointer deference. Fix this by adding a proper check upper in call stack, as malformed relocation records could be passed from user space. Simplest reproducer is a program: r0 = 0 exit With a single relocation record: .insn_off = 0, /* patch first instruction */ .type_id = 100500, /* this type id does not exist */ .access_str_off = 6, /* offset of string \"0\" */ .kind = BPF_CORE_TYPE_ID_LOCAL, See the link for original reproducer or next commit for a test case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47702", "url": "https://ubuntu.com/security/CVE-2024-47702", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fail verification for sign-extension of packet data/data_end/data_meta syzbot reported a kernel crash due to commit 1f1e864b6555 (\"bpf: Handle sign-extenstin ctx member accesses\"). The reason is due to sign-extension of 32-bit load for packet data/data_end/data_meta uapi field. The original code looks like: r2 = *(s32 *)(r1 + 76) /* load __sk_buff->data */ r3 = *(u32 *)(r1 + 80) /* load __sk_buff->data_end */ r0 = r2 r0 += 8 if r3 > r0 goto +1 ... Note that __sk_buff->data load has 32-bit sign extension. After verification and convert_ctx_accesses(), the final asm code looks like: r2 = *(u64 *)(r1 +208) r2 = (s32)r2 r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 ... Note that 'r2 = (s32)r2' may make the kernel __sk_buff->data address invalid which may cause runtime failure. Currently, in C code, typically we have void *data = (void *)(long)skb->data; void *data_end = (void *)(long)skb->data_end; ... and it will generate r2 = *(u64 *)(r1 +208) r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 If we allow sign-extension, void *data = (void *)(long)(int)skb->data; void *data_end = (void *)(long)skb->data_end; ... the generated code looks like r2 = *(u64 *)(r1 +208) r2 <<= 32 r2 s>>= 32 r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 and this will cause verification failure since \"r2 <<= 32\" is not allowed as \"r2\" is a packet pointer. To fix this issue for case r2 = *(s32 *)(r1 + 76) /* load __sk_buff->data */ this patch added additional checking in is_valid_access() callback function for packet data/data_end/data_meta access. If those accesses are with sign-extenstion, the verification will fail. [1] https://lore.kernel.org/bpf/000000000000c90eee061d236d37@google.com/", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47703", "url": "https://ubuntu.com/security/CVE-2024-47703", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, lsm: Add check for BPF LSM return value A bpf prog returning a positive number attached to file_alloc_security hook makes kernel panic. This happens because file system can not filter out the positive number returned by the LSM prog using IS_ERR, and misinterprets this positive number as a file pointer. Given that hook file_alloc_security never returned positive number before the introduction of BPF LSM, and other BPF LSM hooks may encounter similar issues, this patch adds LSM return value check in verifier, to ensure no unexpected value is returned.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49851", "url": "https://ubuntu.com/security/CVE-2024-49851", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: Clean up TPM space after command failure tpm_dev_transmit prepares the TPM space before attempting command transmission. However if the command fails no rollback of this preparation is done. This can result in transient handles being leaked if the device is subsequently closed with no further commands performed. Fix this by flushing the space in the event of command transmission failure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47723", "url": "https://ubuntu.com/security/CVE-2024-47723", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: fix out-of-bounds in dbNextAG() and diAlloc() In dbNextAG() , there is no check for the case where bmp->db_numag is greater or same than MAXAG due to a polluted image, which causes an out-of-bounds. Therefore, a bounds check should be added in dbMount(). And in dbNextAG(), a check for the case where agpref is greater than bmp->db_numag should be added, so an out-of-bounds exception should be prevented. Additionally, a check for the case where agno is greater or same than MAXAG should be added in diAlloc() to prevent out-of-bounds.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49852", "url": "https://ubuntu.com/security/CVE-2024-49852", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: elx: libefc: Fix potential use after free in efc_nport_vport_del() The kref_put() function will call nport->release if the refcount drops to zero. The nport->release release function is _efc_nport_free() which frees \"nport\". But then we dereference \"nport\" on the next line which is a use after free. Re-order these lines to avoid the use after free.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47720", "url": "https://ubuntu.com/security/CVE-2024-47720", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for set_output_gamma in dcn30_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn30_set_output_transfer_func function. Previously, set_output_gamma was being checked for nullity at line 386, but then it was being dereferenced without any nullity check at line 401. This could potentially lead to a null pointer dereference error if set_output_gamma is indeed null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a nullity check for set_output_gamma before the call to set_output_gamma at line 401. If set_output_gamma is null, we log an error message and do not call the function. This fix prevents a potential null pointer dereference error. drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:401 dcn30_set_output_transfer_func() error: we previously assumed 'mpc->funcs->set_output_gamma' could be null (see line 386) drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c 373 bool dcn30_set_output_transfer_func(struct dc *dc, 374 struct pipe_ctx *pipe_ctx, 375 const struct dc_stream_state *stream) 376 { 377 int mpcc_id = pipe_ctx->plane_res.hubp->inst; 378 struct mpc *mpc = pipe_ctx->stream_res.opp->ctx->dc->res_pool->mpc; 379 const struct pwl_params *params = NULL; 380 bool ret = false; 381 382 /* program OGAM or 3DLUT only for the top pipe*/ 383 if (pipe_ctx->top_pipe == NULL) { 384 /*program rmu shaper and 3dlut in MPC*/ 385 ret = dcn30_set_mpc_shaper_3dlut(pipe_ctx, stream); 386 if (ret == false && mpc->funcs->set_output_gamma) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If this is NULL 387 if (stream->out_transfer_func.type == TF_TYPE_HWPWL) 388 params = &stream->out_transfer_func.pwl; 389 else if (pipe_ctx->stream->out_transfer_func.type == 390 TF_TYPE_DISTRIBUTED_POINTS && 391 cm3_helper_translate_curve_to_hw_format( 392 &stream->out_transfer_func, 393 &mpc->blender_params, false)) 394 params = &mpc->blender_params; 395 /* there are no ROM LUTs in OUTGAM */ 396 if (stream->out_transfer_func.type == TF_TYPE_PREDEFINED) 397 BREAK_TO_DEBUGGER(); 398 } 399 } 400 --> 401 mpc->funcs->set_output_gamma(mpc, mpcc_id, params); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Then it will crash 402 return ret; 403 }", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47704", "url": "https://ubuntu.com/security/CVE-2024-47704", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check link_res->hpo_dp_link_enc before using it [WHAT & HOW] Functions dp_enable_link_phy and dp_disable_link_phy can pass link_res without initializing hpo_dp_link_enc and it is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49853", "url": "https://ubuntu.com/security/CVE-2024-49853", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix double free in OPTEE transport Channels can be shared between protocols, avoid freeing the same channel descriptors twice when unloading the stack.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47705", "url": "https://ubuntu.com/security/CVE-2024-47705", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix potential invalid pointer dereference in blk_add_partition The blk_add_partition() function initially used a single if-condition (IS_ERR(part)) to check for errors when adding a partition. This was modified to handle the specific case of -ENXIO separately, allowing the function to proceed without logging the error in this case. However, this change unintentionally left a path where md_autodetect_dev() could be called without confirming that part is a valid pointer. This commit separates the error handling logic by splitting the initial if-condition, improving code readability and handling specific error scenarios explicitly. The function now distinguishes the general error case from -ENXIO without altering the existing behavior of md_autodetect_dev() calls.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47736", "url": "https://ubuntu.com/security/CVE-2024-47736", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: handle overlapped pclusters out of crafted images properly syzbot reported a task hang issue due to a deadlock case where it is waiting for the folio lock of a cached folio that will be used for cache I/Os. After looking into the crafted fuzzed image, I found it's formed with several overlapped big pclusters as below: Ext: logical offset | length : physical offset | length 0: 0.. 16384 | 16384 : 151552.. 167936 | 16384 1: 16384.. 32768 | 16384 : 155648.. 172032 | 16384 2: 32768.. 49152 | 16384 : 537223168.. 537239552 | 16384 ... Here, extent 0/1 are physically overlapped although it's entirely _impossible_ for normal filesystem images generated by mkfs. First, managed folios containing compressed data will be marked as up-to-date and then unlocked immediately (unlike in-place folios) when compressed I/Os are complete. If physical blocks are not submitted in the incremental order, there should be separate BIOs to avoid dependency issues. However, the current code mis-arranges z_erofs_fill_bio_vec() and BIO submission which causes unexpected BIO waits. Second, managed folios will be connected to their own pclusters for efficient inter-queries. However, this is somewhat hard to implement easily if overlapped big pclusters exist. Again, these only appear in fuzzed images so let's simply fall back to temporary short-lived pages for correctness. Additionally, it justifies that referenced managed folios cannot be truncated for now and reverts part of commit 2080ca1ed3e4 (\"erofs: tidy up `struct z_erofs_bvec`\") for simplicity although it shouldn't be any difference.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47706", "url": "https://ubuntu.com/security/CVE-2024-47706", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block, bfq: fix possible UAF for bfqq->bic with merge chain 1) initial state, three tasks: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t\t | ? | ?\t\t | ? \t\t | | | |\t\t | | \t\t V | V |\t\t V | \t\t bfqq1 bfqq2\t\t bfqq3 process ref:\t 1\t\t 1\t\t 1 2) bfqq1 merged to bfqq2: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t\t | |\t\t | ? \t\t \\--------------\\|\t\t | | \t\t V\t\t V | \t\t bfqq1--------->bfqq2\t\t bfqq3 process ref:\t 0\t\t 2\t\t 1 3) bfqq2 merged to bfqq3: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t here -> ? |\t\t | \t\t \\--------------\\ \\-------------\\| \t\t V\t\t V \t\t bfqq1--------->bfqq2---------->bfqq3 process ref:\t 0\t\t 1\t\t 3 In this case, IO from Process 1 will get bfqq2 from BIC1 first, and then get bfqq3 through merge chain, and finially handle IO by bfqq3. Howerver, current code will think bfqq2 is owned by BIC1, like initial state, and set bfqq2->bic to BIC1. bfq_insert_request -> by Process 1 bfqq = bfq_init_rq(rq) bfqq = bfq_get_bfqq_handle_split bfqq = bic_to_bfqq -> get bfqq2 from BIC1 bfqq->ref++ rq->elv.priv[0] = bic rq->elv.priv[1] = bfqq if (bfqq_process_refs(bfqq) == 1) bfqq->bic = bic -> record BIC1 to bfqq2 __bfq_insert_request new_bfqq = bfq_setup_cooperator -> get bfqq3 from bfqq2->new_bfqq bfqq_request_freed(bfqq) new_bfqq->ref++ rq->elv.priv[1] = new_bfqq -> handle IO by bfqq3 Fix the problem by checking bfqq is from merge chain fist. And this might fix a following problem reported by our syzkaller(unreproducible): ================================================================== BUG: KASAN: slab-use-after-free in bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] BUG: KASAN: slab-use-after-free in bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] BUG: KASAN: slab-use-after-free in bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 Write of size 1 at addr ffff888123839eb8 by task kworker/0:1H/18595 CPU: 0 PID: 18595 Comm: kworker/0:1H Tainted: G L 6.6.0-07439-gba2303cacfda #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Workqueue: kblockd blk_mq_requeue_work Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [inline] print_report+0x10d/0x610 mm/kasan/report.c:475 kasan_report+0x8e/0xc0 mm/kasan/report.c:588 bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 bfq_get_bfqq_handle_split+0x169/0x5d0 block/bfq-iosched.c:6757 bfq_init_rq block/bfq-iosched.c:6876 [inline] bfq_insert_request block/bfq-iosched.c:6254 [inline] bfq_insert_requests+0x1112/0x5cf0 block/bfq-iosched.c:6304 blk_mq_insert_request+0x290/0x8d0 block/blk-mq.c:2593 blk_mq_requeue_work+0x6bc/0xa70 block/blk-mq.c:1502 process_one_work kernel/workqueue.c:2627 [inline] process_scheduled_works+0x432/0x13f0 kernel/workqueue.c:2700 worker_thread+0x6f2/0x1160 kernel/workqueue.c:2781 kthread+0x33c/0x440 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:305 Allocated by task 20776: kasan_save_stack+0x20/0x40 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 __kasan_slab_alloc+0x87/0x90 mm/kasan/common.c:328 kasan_slab_alloc include/linux/kasan.h:188 [inline] slab_post_alloc_hook mm/slab.h:763 [inline] slab_alloc_node mm/slub.c:3458 [inline] kmem_cache_alloc_node+0x1a4/0x6f0 mm/slub.c:3503 ioc_create_icq block/blk-ioc.c:370 [inline] ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49855", "url": "https://ubuntu.com/security/CVE-2024-49855", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: fix race between timeout and normal completion If request timetout is handled by nbd_requeue_cmd(), normal completion has to be stopped for avoiding to complete this requeued request, other use-after-free can be triggered. Fix the race by clearing NBD_CMD_INFLIGHT in nbd_requeue_cmd(), meantime make sure that cmd->lock is grabbed for clearing the flag and the requeue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47707", "url": "https://ubuntu.com/security/CVE-2024-47707", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev() Blamed commit accidentally removed a check for rt->rt6i_idev being NULL, as spotted by syzbot: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 UID: 0 PID: 10998 Comm: syz-executor Not tainted 6.11.0-rc6-syzkaller-00208-g625403177711 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 RBP: ffffc900047375d0 R08: 0000000000000003 R09: fffff520008e6e8c R10: dffffc0000000000 R11: fffff520008e6e8c R12: 1ffff1100fdf8f18 R13: ffff88807efc7998 R14: 0000000000000000 R15: ffff88807efc7930 FS: 0000000000000000(0000) GS:ffff8880b8900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020002a80 CR3: 0000000022f62000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: addrconf_ifdown+0x15d/0x1bd0 net/ipv6/addrconf.c:3856 addrconf_notify+0x3cb/0x1020 notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93 call_netdevice_notifiers_extack net/core/dev.c:2032 [inline] call_netdevice_notifiers net/core/dev.c:2046 [inline] unregister_netdevice_many_notify+0xd81/0x1c40 net/core/dev.c:11352 unregister_netdevice_many net/core/dev.c:11414 [inline] unregister_netdevice_queue+0x303/0x370 net/core/dev.c:11289 unregister_netdevice include/linux/netdevice.h:3129 [inline] __tun_detach+0x6b9/0x1600 drivers/net/tun.c:685 tun_detach drivers/net/tun.c:701 [inline] tun_chr_close+0x108/0x1b0 drivers/net/tun.c:3510 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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:0x7f1acc77def9 Code: Unable to access opcode bytes at 0x7f1acc77decf. RSP: 002b:00007ffeb26fa738 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1acc77def9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000043 RBP: 00007f1acc7dd508 R08: 00007ffeb26f84d7 R09: 0000000000000003 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 0000000000000003 R14: 00000000ffffffff R15: 00007ffeb26fa8e0 Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 R ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47708", "url": "https://ubuntu.com/security/CVE-2024-47708", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netkit: Assign missing bpf_net_context During the introduction of struct bpf_net_context handling for XDP-redirect, the netkit driver has been missed, which also requires it because NETKIT_REDIRECT invokes skb_do_redirect() which is accessing the per-CPU variables. Otherwise we see the following crash: \tBUG: kernel NULL pointer dereference, address: 0000000000000038 \tbpf_redirect() \tnetkit_xmit() \tdev_hard_start_xmit() Set the bpf_net_context before invoking netkit_xmit() program within the netkit driver.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47709", "url": "https://ubuntu.com/security/CVE-2024-47709", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: Clear bo->bcm_proc_read after remove_proc_entry(). syzbot reported a warning in bcm_release(). [0] The blamed change fixed another warning that is triggered when connect() is issued again for a socket whose connect()ed device has been unregistered. However, if the socket is just close()d without the 2nd connect(), the remaining bo->bcm_proc_read triggers unnecessary remove_proc_entry() in bcm_release(). Let's clear bo->bcm_proc_read after remove_proc_entry() in bcm_notify(). [0] name '4986' WARNING: CPU: 0 PID: 5234 at fs/proc/generic.c:711 remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Modules linked in: CPU: 0 UID: 0 PID: 5234 Comm: syz-executor606 Not tainted 6.11.0-rc5-syzkaller-00178-g5517ae241919 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Code: ff eb 05 e8 cb 1e 5e ff 48 8b 5c 24 10 48 c7 c7 e0 f7 aa 8e e8 2a 38 8e 09 90 48 c7 c7 60 3a 1b 8c 48 89 de e8 da 42 20 ff 90 <0f> 0b 90 90 48 8b 44 24 18 48 c7 44 24 40 0e 36 e0 45 49 c7 04 07 RSP: 0018:ffffc9000345fa20 EFLAGS: 00010246 RAX: 2a2d0aee2eb64600 RBX: ffff888032f1f548 RCX: ffff888029431e00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000345fb08 R08: ffffffff8155b2f2 R09: 1ffff1101710519a R10: dffffc0000000000 R11: ffffed101710519b R12: ffff888011d38640 R13: 0000000000000004 R14: 0000000000000000 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8880b8800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcfb52722f0 CR3: 000000000e734000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: bcm_release+0x250/0x880 net/can/bcm.c:1578 __sock_release net/socket.c:659 [inline] sock_close+0xbc/0x240 net/socket.c:1421 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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:0x7fcfb51ee969 Code: Unable to access opcode bytes at 0x7fcfb51ee93f. RSP: 002b:00007ffce0109ca8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fcfb51ee969 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 00007fcfb526f3b0 R08: ffffffffffffffb8 R09: 0000555500000000 R10: 0000555500000000 R11: 0000000000000246 R12: 00007fcfb526f3b0 R13: 0000000000000000 R14: 00007fcfb5271ee0 R15: 00007fcfb51bf160 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47710", "url": "https://ubuntu.com/security/CVE-2024-47710", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sock_map: Add a cond_resched() in sock_hash_free() Several syzbot soft lockup reports all have in common sock_hash_free() If a map with a large number of buckets is destroyed, we need to yield the cpu when needed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47711", "url": "https://ubuntu.com/security/CVE-2024-47711", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Don't return OOB skb in manage_oob(). syzbot reported use-after-free in unix_stream_recv_urg(). [0] The scenario is 1. send(MSG_OOB) 2. recv(MSG_OOB) -> The consumed OOB remains in recv queue 3. send(MSG_OOB) 4. recv() -> manage_oob() returns the next skb of the consumed OOB -> This is also OOB, but unix_sk(sk)->oob_skb is not cleared 5. recv(MSG_OOB) -> unix_sk(sk)->oob_skb is used but already freed The recent commit 8594d9b85c07 (\"af_unix: Don't call skb_get() for OOB skb.\") uncovered the issue. If the OOB skb is consumed and the next skb is peeked in manage_oob(), we still need to check if the skb is OOB. Let's do so by falling back to the following checks in manage_oob() and add the test case in selftest. Note that we need to add a similar check for SIOCATMARK. [0]: BUG: KASAN: slab-use-after-free in unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959 Read of size 4 at addr ffff8880326abcc4 by task syz-executor178/5235 CPU: 0 UID: 0 PID: 5235 Comm: syz-executor178 Not tainted 6.11.0-rc5-syzkaller-00742-gfbdaffe41adc #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959 unix_stream_recv_urg+0x1df/0x320 net/unix/af_unix.c:2640 unix_stream_read_generic+0x2456/0x2520 net/unix/af_unix.c:2778 unix_stream_recvmsg+0x22b/0x2c0 net/unix/af_unix.c:2996 sock_recvmsg_nosec net/socket.c:1046 [inline] sock_recvmsg+0x22f/0x280 net/socket.c:1068 ____sys_recvmsg+0x1db/0x470 net/socket.c:2816 ___sys_recvmsg net/socket.c:2858 [inline] __sys_recvmsg+0x2f0/0x3e0 net/socket.c:2888 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:0x7f5360d6b4e9 Code: 48 83 c4 28 c3 e8 37 17 00 00 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff29b3a458 EFLAGS: 00000246 ORIG_RAX: 000000000000002f RAX: ffffffffffffffda RBX: 00007fff29b3a638 RCX: 00007f5360d6b4e9 RDX: 0000000000002001 RSI: 0000000020000640 RDI: 0000000000000003 RBP: 00007f5360dde610 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 00007fff29b3a628 R14: 0000000000000001 R15: 0000000000000001 Allocated by task 5235: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:312 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slub.c:3988 [inline] slab_alloc_node mm/slub.c:4037 [inline] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4080 __alloc_skb+0x1c3/0x440 net/core/skbuff.c:667 alloc_skb include/linux/skbuff.h:1320 [inline] alloc_skb_with_frags+0xc3/0x770 net/core/skbuff.c:6528 sock_alloc_send_pskb+0x91a/0xa60 net/core/sock.c:2815 sock_alloc_send_skb include/net/sock.h:1778 [inline] queue_oob+0x108/0x680 net/unix/af_unix.c:2198 unix_stream_sendmsg+0xd24/0xf80 net/unix/af_unix.c:2351 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2680 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 Freed by task 5235: kasan_save_stack mm/kasan/common.c:47 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47712", "url": "https://ubuntu.com/security/CVE-2024-47712", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: fix potential RCU dereference issue in wilc_parse_join_bss_param In the `wilc_parse_join_bss_param` function, the TSF field of the `ies` structure is accessed after the RCU read-side critical section is unlocked. According to RCU usage rules, this is illegal. Reusing this pointer can lead to unpredictable behavior, including accessing memory that has been updated or causing use-after-free issues. This possible bug was identified using a static analysis tool developed by myself, specifically designed to detect RCU-related issues. To address this, the TSF value is now stored in a local variable `ies_tsf` before the RCU lock is released. The `param->tsf_lo` field is then assigned using this local variable, ensuring that the TSF value is safely accessed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47713", "url": "https://ubuntu.com/security/CVE-2024-47713", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop() Since '__dev_queue_xmit()' should be called with interrupts enabled, the following backtrace: ieee80211_do_stop() ... spin_lock_irqsave(&local->queue_stop_reason_lock, flags) ... ieee80211_free_txskb() ieee80211_report_used_skb() ieee80211_report_ack_skb() cfg80211_mgmt_tx_status_ext() nl80211_frame_tx_status() genlmsg_multicast_netns() genlmsg_multicast_netns_filtered() nlmsg_multicast_filtered() \t netlink_broadcast_filtered() \t do_one_broadcast() \t netlink_broadcast_deliver() \t __netlink_sendskb() \t netlink_deliver_tap() \t __netlink_deliver_tap_skb() \t dev_queue_xmit() \t __dev_queue_xmit() ; with IRQS disabled ... spin_unlock_irqrestore(&local->queue_stop_reason_lock, flags) issues the warning (as reported by syzbot reproducer): WARNING: CPU: 2 PID: 5128 at kernel/softirq.c:362 __local_bh_enable_ip+0xc3/0x120 Fix this by implementing a two-phase skb reclamation in 'ieee80211_do_stop()', where actual work is performed outside of a section with interrupts disabled.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47730", "url": "https://ubuntu.com/security/CVE-2024-47730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/qm - inject error before stopping queue The master ooo cannot be completely closed when the accelerator core reports memory error. Therefore, the driver needs to inject the qm error to close the master ooo. Currently, the qm error is injected after stopping queue, memory may be released immediately after stopping queue, causing the device to access the released memory. Therefore, error is injected to close master ooo before stopping queue to ensure that the device does not access the released memory.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49856", "url": "https://ubuntu.com/security/CVE-2024-49856", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/sgx: Fix deadlock in SGX NUMA node search When the current node doesn't have an EPC section configured by firmware and all other EPC sections are used up, CPU can get stuck inside the while loop that looks for an available EPC page from remote nodes indefinitely, leading to a soft lockup. Note how nid_of_current will never be equal to nid in that while loop because nid_of_current is not set in sgx_numa_mask. Also worth mentioning is that it's perfectly fine for the firmware not to setup an EPC section on a node. While setting up an EPC section on each node can enhance performance, it is not a requirement for functionality. Rework the loop to start and end on *a* node that has SGX memory. This avoids the deadlock looking for the current SGX-lacking node to show up in the loop when it never will.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47714", "url": "https://ubuntu.com/security/CVE-2024-47714", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: use hweight16 to get correct tx antenna The chainmask is u16 so using hweight8 cannot get correct tx_ant. Without this patch, the tx_ant of band 2 would be -1 and lead to the following issue: BUG: KASAN: stack-out-of-bounds in mt7996_mcu_add_sta+0x12e0/0x16e0 [mt7996e]", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47715", "url": "https://ubuntu.com/security/CVE-2024-47715", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: fix oops on non-dbdc mt7986 mt7915_band_config() sets band_idx = 1 on the main phy for mt7986 with MT7975_ONE_ADIE or MT7976_ONE_ADIE. Commit 0335c034e726 (\"wifi: mt76: fix race condition related to checking tx queue fill status\") introduced a dereference of the phys array indirectly indexed by band_idx via wcid->phy_idx in mt76_wcid_cleanup(). This caused the following Oops on affected mt7986 devices: Unable to handle kernel read from unreadable memory at virtual address 0000000000000024 Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x00000005 CM = 0, WnR = 0 user pgtable: 4k pages, 39-bit VAs, pgdp=0000000042545000 [0000000000000024] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 Internal error: Oops: 0000000096000005 [#1] SMP Modules linked in: ... mt7915e mt76_connac_lib mt76 mac80211 cfg80211 ... CPU: 2 PID: 1631 Comm: hostapd Not tainted 5.15.150 #0 Hardware name: ZyXEL EX5700 (Telenor) (DT) pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mt76_wcid_cleanup+0x84/0x22c [mt76] lr : mt76_wcid_cleanup+0x64/0x22c [mt76] sp : ffffffc00a803700 x29: ffffffc00a803700 x28: ffffff80008f7300 x27: ffffff80003f3c00 x26: ffffff80000a7880 x25: ffffffc008c26e00 x24: 0000000000000001 x23: ffffffc000a68114 x22: 0000000000000000 x21: ffffff8004172cc8 x20: ffffffc00a803748 x19: ffffff8004152020 x18: 0000000000000000 x17: 00000000000017c0 x16: ffffffc008ef5000 x15: 0000000000000be0 x14: ffffff8004172e28 x13: ffffff8004172e28 x12: 0000000000000000 x11: 0000000000000000 x10: ffffff8004172e30 x9 : ffffff8004172e28 x8 : 0000000000000000 x7 : ffffff8004156020 x6 : 0000000000000000 x5 : 0000000000000031 x4 : 0000000000000000 x3 : 0000000000000001 x2 : 0000000000000000 x1 : ffffff80008f7300 x0 : 0000000000000024 Call trace: mt76_wcid_cleanup+0x84/0x22c [mt76] __mt76_sta_remove+0x70/0xbc [mt76] mt76_sta_state+0x8c/0x1a4 [mt76] mt7915_eeprom_get_power_delta+0x11e4/0x23a0 [mt7915e] drv_sta_state+0x144/0x274 [mac80211] sta_info_move_state+0x1cc/0x2a4 [mac80211] sta_set_sinfo+0xaf8/0xc24 [mac80211] sta_info_destroy_addr_bss+0x4c/0x6c [mac80211] ieee80211_color_change_finish+0x1c08/0x1e70 [mac80211] cfg80211_check_station_change+0x1360/0x4710 [cfg80211] genl_family_rcv_msg_doit+0xb4/0x110 genl_rcv_msg+0xd0/0x1bc netlink_rcv_skb+0x58/0x120 genl_rcv+0x34/0x50 netlink_unicast+0x1f0/0x2ec netlink_sendmsg+0x198/0x3d0 ____sys_sendmsg+0x1b0/0x210 ___sys_sendmsg+0x80/0xf0 __sys_sendmsg+0x44/0xa0 __arm64_sys_sendmsg+0x20/0x30 invoke_syscall.constprop.0+0x4c/0xe0 do_el0_svc+0x40/0xd0 el0_svc+0x14/0x4c el0t_64_sync_handler+0x100/0x110 el0t_64_sync+0x15c/0x160 Code: d2800002 910092c0 52800023 f9800011 (885f7c01) ---[ end trace 7e42dd9a39ed2281 ]--- Fix by using mt76_dev_phy() which will map band_idx to the correct phy for all hardware combinations.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49857", "url": "https://ubuntu.com/security/CVE-2024-49857", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: set the cipher for secured NDP ranging The cipher pointer is not set, but is derefereced trying to set its content, which leads to a NULL pointer dereference. Fix it by pointing to the cipher parameter before dereferencing.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47738", "url": "https://ubuntu.com/security/CVE-2024-47738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: don't use rate mask for offchannel TX either Like the commit ab9177d83c04 (\"wifi: mac80211: don't use rate mask for scanning\"), ignore incorrect settings to avoid no supported rate warning reported by syzbot. The syzbot did bisect and found cause is commit 9df66d5b9f45 (\"cfg80211: fix default HE tx bitrate mask in 2G band\"), which however corrects bitmask of HE MCS and recognizes correctly settings of empty legacy rate plus HE MCS rate instead of returning -EINVAL. As suggestions [1], follow the change of SCAN TX to consider this case of offchannel TX as well. [1] https://lore.kernel.org/linux-wireless/6ab2dc9c3afe753ca6fdcdd1421e7a1f47e87b84.camel@sipsolutions.net/T/#m2ac2a6d2be06a37c9c47a3d8a44b4f647ed4f024", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47731", "url": "https://ubuntu.com/security/CVE-2024-47731", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers/perf: Fix ali_drw_pmu driver interrupt status clearing The alibaba_uncore_pmu driver forgot to clear all interrupt status in the interrupt processing function. After the PMU counter overflow interrupt occurred, an interrupt storm occurred, causing the system to hang. Therefore, clear the correct interrupt status in the interrupt handling function to fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49862", "url": "https://ubuntu.com/security/CVE-2024-49862", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powercap: intel_rapl: Fix off by one in get_rpi() The rp->priv->rpi array is either rpi_msr or rpi_tpmi which have NR_RAPL_PRIMITIVES number of elements. Thus the > needs to be >= to prevent an off by one access.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47716", "url": "https://ubuntu.com/security/CVE-2024-47716", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: 9410/1: vfp: Use asm volatile in fmrx/fmxr macros Floating point instructions in userspace can crash some arm kernels built with clang/LLD 17.0.6: BUG: unsupported FP instruction in kernel mode FPEXC == 0xc0000780 Internal error: Oops - undefined instruction: 0 [#1] ARM CPU: 0 PID: 196 Comm: vfp-reproducer Not tainted 6.10.0 #1 Hardware name: BCM2835 PC is at vfp_support_entry+0xc8/0x2cc LR is at do_undefinstr+0xa8/0x250 pc : [] lr : [] psr: a0000013 sp : dc8d1f68 ip : 60000013 fp : bedea19c r10: ec532b17 r9 : 00000010 r8 : 0044766c r7 : c0000780 r6 : ec532b17 r5 : c1c13800 r4 : dc8d1fb0 r3 : c10072c4 r2 : c0101c88 r1 : ec532b17 r0 : 0044766c Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 00c5387d Table: 0251c008 DAC: 00000051 Register r0 information: non-paged memory Register r1 information: vmalloc memory Register r2 information: non-slab/vmalloc memory Register r3 information: non-slab/vmalloc memory Register r4 information: 2-page vmalloc region Register r5 information: slab kmalloc-cg-2k Register r6 information: vmalloc memory Register r7 information: non-slab/vmalloc memory Register r8 information: non-paged memory Register r9 information: zero-size pointer Register r10 information: vmalloc memory Register r11 information: non-paged memory Register r12 information: non-paged memory Process vfp-reproducer (pid: 196, stack limit = 0x61aaaf8b) Stack: (0xdc8d1f68 to 0xdc8d2000) 1f60: 0000081f b6f69300 0000000f c10073f4 c10072c4 dc8d1fb0 1f80: ec532b17 0c532b17 0044766c b6f9ccd8 00000000 c010a80c 00447670 60000010 1fa0: ffffffff c1c13800 00c5387d c0100f10 b6f68af8 00448fc0 00000000 bedea188 1fc0: bedea314 00000001 00448ebc b6f9d000 00447608 b6f9ccd8 00000000 bedea19c 1fe0: bede9198 bedea188 b6e1061c 0044766c 60000010 ffffffff 00000000 00000000 Call trace: [] (vfp_support_entry) from [] (do_undefinstr+0xa8/0x250) [] (do_undefinstr) from [] (__und_usr+0x70/0x80) Exception stack(0xdc8d1fb0 to 0xdc8d1ff8) 1fa0: b6f68af8 00448fc0 00000000 bedea188 1fc0: bedea314 00000001 00448ebc b6f9d000 00447608 b6f9ccd8 00000000 bedea19c 1fe0: bede9198 bedea188 b6e1061c 0044766c 60000010 ffffffff Code: 0a000061 e3877202 e594003c e3a09010 (eef16a10) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Fatal exception in interrupt ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]--- This is a minimal userspace reproducer on a Raspberry Pi Zero W: #include #include int main(void) { double v = 1.0; printf(\"%fn\", NAN + *(volatile double *)&v); return 0; } Another way to consistently trigger the oops is: calvin@raspberry-pi-zero-w ~$ python -c \"import json\" The bug reproduces only when the kernel is built with DYNAMIC_DEBUG=n, because the pr_debug() calls act as barriers even when not activated. This is the output from the same kernel source built with the same compiler and DYNAMIC_DEBUG=y, where the userspace reproducer works as expected: VFP: bounce: trigger ec532b17 fpexc c0000780 VFP: emulate: INST=0xee377b06 SCR=0x00000000 VFP: bounce: trigger eef1fa10 fpexc c0000780 VFP: emulate: INST=0xeeb40b40 SCR=0x00000000 VFP: raising exceptions 30000000 calvin@raspberry-pi-zero-w ~$ ./vfp-reproducer nan Crudely grepping for vmsr/vmrs instructions in the otherwise nearly idential text for vfp_support_entry() makes the problem obvious: vmlinux.llvm.good [0xc0101cb8] <+48>: vmrs r7, fpexc vmlinux.llvm.good [0xc0101cd8] <+80>: vmsr fpexc, r0 vmlinux.llvm.good [0xc0101d20 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47717", "url": "https://ubuntu.com/security/CVE-2024-47717", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RISC-V: KVM: Don't zero-out PMU snapshot area before freeing data With the latest Linux-6.11-rc3, the below NULL pointer crash is observed when SBI PMU snapshot is enabled for the guest and the guest is forcefully powered-off. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000508 Oops [#1] Modules linked in: kvm CPU: 0 UID: 0 PID: 61 Comm: term-poll Not tainted 6.11.0-rc3-00018-g44d7178dd77a #3 Hardware name: riscv-virtio,qemu (DT) epc : __kvm_write_guest_page+0x94/0xa6 [kvm] ra : __kvm_write_guest_page+0x54/0xa6 [kvm] epc : ffffffff01590e98 ra : ffffffff01590e58 sp : ffff8f80001f39b0 gp : ffffffff81512a60 tp : ffffaf80024872c0 t0 : ffffaf800247e000 t1 : 00000000000007e0 t2 : 0000000000000000 s0 : ffff8f80001f39f0 s1 : 00007fff89ac4000 a0 : ffffffff015dd7e8 a1 : 0000000000000086 a2 : 0000000000000000 a3 : ffffaf8000000000 a4 : ffffaf80024882c0 a5 : 0000000000000000 a6 : ffffaf800328d780 a7 : 00000000000001cc s2 : ffffaf800197bd00 s3 : 00000000000828c4 s4 : ffffaf800248c000 s5 : ffffaf800247d000 s6 : 0000000000001000 s7 : 0000000000001000 s8 : 0000000000000000 s9 : 00007fff861fd500 s10: 0000000000000001 s11: 0000000000800000 t3 : 00000000000004d3 t4 : 00000000000004d3 t5 : ffffffff814126e0 t6 : ffffffff81412700 status: 0000000200000120 badaddr: 0000000000000508 cause: 000000000000000d [] __kvm_write_guest_page+0x94/0xa6 [kvm] [] kvm_vcpu_write_guest+0x56/0x90 [kvm] [] kvm_pmu_clear_snapshot_area+0x42/0x7e [kvm] [] kvm_riscv_vcpu_pmu_deinit.part.0+0xe0/0x14e [kvm] [] kvm_riscv_vcpu_pmu_deinit+0x1a/0x24 [kvm] [] kvm_arch_vcpu_destroy+0x28/0x4c [kvm] [] kvm_destroy_vcpus+0x5a/0xda [kvm] [] kvm_arch_destroy_vm+0x14/0x28 [kvm] [] kvm_destroy_vm+0x168/0x2a0 [kvm] [] kvm_put_kvm+0x3c/0x58 [kvm] [] kvm_vm_release+0x22/0x2e [kvm] Clearly, the kvm_vcpu_write_guest() function is crashing because it is being called from kvm_pmu_clear_snapshot_area() upon guest tear down. To address the above issue, simplify the kvm_pmu_clear_snapshot_area() to not zero-out PMU snapshot area from kvm_pmu_clear_snapshot_area() because the guest is anyway being tore down. The kvm_pmu_clear_snapshot_area() is also called when guest changes PMU snapshot area of a VCPU but even in this case the previous PMU snaphsot area must not be zeroed-out because the guest might have reclaimed the pervious PMU snapshot area for some other purpose.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47721", "url": "https://ubuntu.com/security/CVE-2024-47721", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: remove unused C2H event ID RTW89_MAC_C2H_FUNC_READ_WOW_CAM to prevent out-of-bounds reading The handler of firmware C2H event RTW89_MAC_C2H_FUNC_READ_WOW_CAM isn't implemented, but driver expects number of handlers is NUM_OF_RTW89_MAC_C2H_FUNC_WOW causing out-of-bounds access. Fix it by removing ID. Addresses-Coverity-ID: 1598775 (\"Out-of-bounds read\")", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47732", "url": "https://ubuntu.com/security/CVE-2024-47732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: iaa - Fix potential use after free bug The free_device_compression_mode(iaa_device, device_mode) function frees \"device_mode\" but it iss passed to iaa_compression_modes[i]->free() a few lines later resulting in a use after free. The good news is that, so far as I can tell, nothing implements the ->free() function and the use after free happens in dead code. But, with this fix, when something does implement it, we'll be ready. :)", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47718", "url": "https://ubuntu.com/security/CVE-2024-47718", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: always wait for both firmware loading attempts In 'rtw_wait_firmware_completion()', always wait for both (regular and wowlan) firmware loading attempts. Otherwise if 'rtw_usb_intf_init()' has failed in 'rtw_usb_probe()', 'rtw_usb_disconnect()' may issue 'ieee80211_free_hw()' when one of 'rtw_load_firmware_cb()' (usually the wowlan one) is still in progress, causing UAF detected by KASAN.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47724", "url": "https://ubuntu.com/security/CVE-2024-47724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: use work queue to process beacon tx event Commit 3a415daa3e8b (\"wifi: ath11k: add P2P IE in beacon template\") from Feb 28, 2024 (linux-next), leads to the following Smatch static checker warning: drivers/net/wireless/ath/ath11k/wmi.c:1742 ath11k_wmi_p2p_go_bcn_ie() warn: sleeping in atomic context The reason is that ath11k_bcn_tx_status_event() will directly call might sleep function ath11k_wmi_cmd_send() during RCU read-side critical sections. The call trace is like: ath11k_bcn_tx_status_event() -> rcu_read_lock() -> ath11k_mac_bcn_tx_event() \t-> ath11k_mac_setup_bcn_tmpl() \t…… \t\t-> ath11k_wmi_bcn_tmpl() \t\t\t-> ath11k_wmi_cmd_send() -> rcu_read_unlock() Commit 886433a98425 (\"ath11k: add support for BSS color change\") added the ath11k_mac_bcn_tx_event(), commit 01e782c89108 (\"ath11k: fix warning of RCU usage for ath11k_mac_get_arvif_by_vdev_id()\") added the RCU lock to avoid warning but also introduced this BUG. Use work queue to avoid directly calling ath11k_mac_bcn_tx_event() during RCU critical sections. No need to worry about the deletion of vif because cancel_work_sync() will drop the work if it doesn't start or block vif deletion until the running work is done. 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": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47671", "url": "https://ubuntu.com/security/CVE-2024-47671", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: usbtmc: prevent kernel-usb-infoleak The syzbot reported a kernel-usb-infoleak in usbtmc_write, we need to clear the structure before filling fields.", "cve_priority": "medium", "cve_public_date": "2024-10-09 15:15:00 UTC" }, { "cve": "CVE-2024-46869", "url": "https://ubuntu.com/security/CVE-2024-46869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btintel_pcie: Allocate memory for driver private data Fix driver not allocating memory for struct btintel_data which is used to store internal data.", "cve_priority": "medium", "cve_public_date": "2024-09-30 16:15:00 UTC" }, { "cve": "CVE-2024-53164", "url": "https://ubuntu.com/security/CVE-2024-53164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: fix ordering of qlen adjustment Changes to sch->q.qlen around qdisc_tree_reduce_backlog() need to happen _before_ a call to said function because otherwise it may fail to notify parent qdiscs when the child is about to become empty.", "cve_priority": "medium", "cve_public_date": "2024-12-27 14:15:00 UTC" }, { "cve": "CVE-2024-53103", "url": "https://ubuntu.com/security/CVE-2024-53103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hv_sock: Initializing vsk->trans to NULL to prevent a dangling pointer When hvs is released, there is a possibility that vsk->trans may not be initialized to NULL, which could lead to a dangling pointer. This issue is resolved by initializing vsk->trans to NULL.", "cve_priority": "high", "cve_public_date": "2024-12-02 08:15:00 UTC" } ], "launchpad_bugs_fixed": [ 2093643, 1786013, 2091744, 2091184, 2093146, 2085406, 2089684, 2090932, 2085485, 2089357, 2089306, 2091655, 2091655, 2091655, 2091655, 2091655, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091386, 2091990, 2089327, 2089113, 2086587, 2086606, 2085950, 2085944, 2087853, 2087983, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089020, 2089020, 2089020 ], "changes": [ { "cves": [ { "cve": "CVE-2025-0927", "url": "https://ubuntu.com/security/CVE-2025-0927", "cve_description": "[fs: hfs/hfsplus: add key_len boundary check to hfs_bnode_read_key]", "cve_priority": "medium", "cve_public_date": "2025-02-13" } ], "log": [ "", " * CVE-2025-0927", " - SAUCE: fs: hfs/hfsplus: add key_len boundary check to hfs_bnode_read_key", "" ], "package": "linux", "version": "6.11.0-18.18", "urgency": "medium", "distributions": "oracular", "launchpad_bugs_fixed": [], "author": "Manuel Diewald ", "date": "Fri, 07 Feb 2025 18:44:32 +0100" }, { "cves": [ { "cve": "CVE-2024-53141", "url": "https://ubuntu.com/security/CVE-2024-53141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: add missing range check in bitmap_ip_uadt When tb[IPSET_ATTR_IP_TO] is not present but tb[IPSET_ATTR_CIDR] exists, the values of ip and ip_to are slightly swapped. Therefore, the range check for ip should be done later, but this part is missing and it seems that the vulnerability occurs. So we should add missing range checks and remove unnecessary range checks.", "cve_priority": "medium", "cve_public_date": "2024-12-06 10:15:00 UTC" }, { "cve": "CVE-2024-50010", "url": "https://ubuntu.com/security/CVE-2024-50010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exec: don't WARN for racy path_noexec check Both i_mode and noexec checks wrapped in WARN_ON stem from an artifact of the previous implementation. They used to legitimately check for the condition, but that got moved up in two commits: 633fb6ac3980 (\"exec: move S_ISREG() check earlier\") 0fd338b2d2cd (\"exec: move path_noexec() check earlier\") Instead of being removed said checks are WARN_ON'ed instead, which has some debug value. However, the spurious path_noexec check is racy, resulting in unwarranted warnings should someone race with setting the noexec flag. One can note there is more to perm-checking whether execve is allowed and none of the conditions are guaranteed to still hold after they were tested for. Additionally this does not validate whether the code path did any perm checking to begin with -- it will pass if the inode happens to be regular. Keep the redundant path_noexec() check even though it's mindless nonsense checking for guarantee that isn't given so drop the WARN. Reword the commentary and do small tidy ups while here. [brauner: keep redundant path_noexec() check]", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-53143", "url": "https://ubuntu.com/security/CVE-2024-53143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fsnotify: Fix ordering of iput() and watched_objects decrement Ensure the superblock is kept alive until we're done with iput(). Holding a reference to an inode is not allowed unless we ensure the superblock stays alive, which fsnotify does by keeping the watched_objects count elevated, so iput() must happen before the watched_objects decrement. This can lead to a UAF of something like sb->s_fs_info in tmpfs, but the UAF is hard to hit because race orderings that oops are more likely, thanks to the CHECK_DATA_CORRUPTION() block in generic_shutdown_super(). Also, ensure that fsnotify_put_sb_watched_objects() doesn't call fsnotify_sb_watched_objects() on a superblock that may have already been freed, which would cause a UAF read of sb->s_fsnotify_info.", "cve_priority": "medium", "cve_public_date": "2024-12-07 07:15:00 UTC" }, { "cve": "CVE-2024-53142", "url": "https://ubuntu.com/security/CVE-2024-53142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: initramfs: avoid filename buffer overrun The initramfs filename field is defined in Documentation/driver-api/early-userspace/buffer-format.rst as: 37 cpio_file := ALGN(4) + cpio_header + filename + \"\\0\" + ALGN(4) + data ... 55 ============= ================== ========================= 56 Field name Field size Meaning 57 ============= ================== ========================= ... 70 c_namesize 8 bytes Length of filename, including final \\0 When extracting an initramfs cpio archive, the kernel's do_name() path handler assumes a zero-terminated path at @collected, passing it directly to filp_open() / init_mkdir() / init_mknod(). If a specially crafted cpio entry carries a non-zero-terminated filename and is followed by uninitialized memory, then a file may be created with trailing characters that represent the uninitialized memory. The ability to create an initramfs entry would imply already having full control of the system, so the buffer overrun shouldn't be considered a security vulnerability. Append the output of the following bash script to an existing initramfs and observe any created /initramfs_test_fname_overrunAA* path. E.g. ./reproducer.sh | gzip >> /myinitramfs It's easiest to observe non-zero uninitialized memory when the output is gzipped, as it'll overflow the heap allocated @out_buf in __gunzip(), rather than the initrd_start+initrd_size block. ---- reproducer.sh ---- nilchar=\"A\"\t# change to \"\\0\" to properly zero terminate / pad magic=\"070701\" ino=1 mode=$(( 0100777 )) uid=0 gid=0 nlink=1 mtime=1 filesize=0 devmajor=0 devminor=1 rdevmajor=0 rdevminor=0 csum=0 fname=\"initramfs_test_fname_overrun\" namelen=$(( ${#fname} + 1 ))\t# plus one to account for terminator printf \"%s%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%s\" \\ \t$magic $ino $mode $uid $gid $nlink $mtime $filesize \\ \t$devmajor $devminor $rdevmajor $rdevminor $namelen $csum $fname termpadlen=$(( 1 + ((4 - ((110 + $namelen) & 3)) % 4) )) printf \"%.s${nilchar}\" $(seq 1 $termpadlen) ---- reproducer.sh ---- Symlink filename fields handled in do_symlink() won't overrun past the data segment, due to the explicit zero-termination of the symlink target. Fix filename buffer overrun by aborting the initramfs FSM if any cpio entry doesn't carry a zero-terminator at the expected (name_len - 1) offset.", "cve_priority": "medium", "cve_public_date": "2024-12-06 10:15:00 UTC" }, { "cve": "CVE-2024-53133", "url": "https://ubuntu.com/security/CVE-2024-53133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Handle dml allocation failure to avoid crash [Why] In the case where a dml allocation fails for any reason, the current state's dml contexts would no longer be valid. Then subsequent calls dc_state_copy_internal would shallow copy invalid memory and if the new state was released, a double free would occur. [How] Reset dml pointers in new_state to NULL and avoid invalid pointer (cherry picked from commit bcafdc61529a48f6f06355d78eb41b3aeda5296c)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53108", "url": "https://ubuntu.com/security/CVE-2024-53108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Adjust VSDB parser for replay feature At some point, the IEEE ID identification for the replay check in the AMD EDID was added. However, this check causes the following out-of-bounds issues when using KASAN: [ 27.804016] BUG: KASAN: slab-out-of-bounds in amdgpu_dm_update_freesync_caps+0xefa/0x17a0 [amdgpu] [ 27.804788] Read of size 1 at addr ffff8881647fdb00 by task systemd-udevd/383 ... [ 27.821207] Memory state around the buggy address: [ 27.821215] ffff8881647fda00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821224] ffff8881647fda80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821234] >ffff8881647fdb00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821243] ^ [ 27.821250] ffff8881647fdb80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821259] ffff8881647fdc00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821268] ================================================================== This is caused because the ID extraction happens outside of the range of the edid lenght. This commit addresses this issue by considering the amd_vsdb_block size. (cherry picked from commit b7e381b1ccd5e778e3d9c44c669ad38439a861d8)", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53134", "url": "https://ubuntu.com/security/CVE-2024-53134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pmdomain: imx93-blk-ctrl: correct remove path The check condition should be 'i < bc->onecell_data.num_domains', not 'bc->onecell_data.num_domains' which will make the look never finish and cause kernel panic. Also disable runtime to address \"imx93-blk-ctrl 4ac10000.system-controller: Unbalanced pm_runtime_enable!\"", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53132", "url": "https://ubuntu.com/security/CVE-2024-53132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/oa: Fix \"Missing outer runtime PM protection\" warning Fix the following drm_WARN: [953.586396] xe 0000:00:02.0: [drm] Missing outer runtime PM protection ... <4> [953.587090] ? xe_pm_runtime_get_noresume+0x8d/0xa0 [xe] <4> [953.587208] guc_exec_queue_add_msg+0x28/0x130 [xe] <4> [953.587319] guc_exec_queue_fini+0x3a/0x40 [xe] <4> [953.587425] xe_exec_queue_destroy+0xb3/0xf0 [xe] <4> [953.587515] xe_oa_release+0x9c/0xc0 [xe] (cherry picked from commit b107c63d2953907908fd0cafb0e543b3c3167b75)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53127", "url": "https://ubuntu.com/security/CVE-2024-53127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Revert \"mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K\" The commit 8396c793ffdf (\"mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K\") increased the max_req_size, even for 4K pages, causing various issues: - Panic booting the kernel/rootfs from an SD card on Rockchip RK3566 - Panic booting the kernel/rootfs from an SD card on StarFive JH7100 - \"swiotlb buffer is full\" and data corruption on StarFive JH7110 At this stage no fix have been found, so it's probably better to just revert the change. This reverts commit 8396c793ffdf28bb8aee7cfe0891080f8cab7890.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53130", "url": "https://ubuntu.com/security/CVE-2024-53130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint When using the \"block:block_dirty_buffer\" tracepoint, mark_buffer_dirty() may cause a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because, since the tracepoint was added in mark_buffer_dirty(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, nilfs_grab_buffer(), which grabs a buffer to read (or create) a block of metadata, including b-tree node blocks, does not set the block device, but instead does so only if the buffer is not in the \"uptodate\" state for each of its caller block reading functions. However, if the uptodate flag is set on a folio/page, and the buffer heads are detached from it by try_to_free_buffers(), and new buffer heads are then attached by create_empty_buffers(), the uptodate flag may be restored to each buffer without the block device being set to bh->b_bdev, and mark_buffer_dirty() may be called later in that state, resulting in the bug mentioned above. Fix this issue by making nilfs_grab_buffer() always set the block device of the super block structure to the buffer head, regardless of the state of the buffer's uptodate flag.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53105", "url": "https://ubuntu.com/security/CVE-2024-53105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: page_alloc: move mlocked flag clearance into free_pages_prepare() Syzbot reported a bad page state problem caused by a page being freed using free_page() still having a mlocked flag at free_pages_prepare() stage: BUG: Bad page state in process syz.5.504 pfn:61f45 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x61f45 flags: 0xfff00000080204(referenced|workingset|mlocked|node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000080204 0000000000000000 dead000000000122 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set page_owner tracks the page as allocated page last allocated via order 0, migratetype Unmovable, gfp_mask 0x400dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO), pid 8443, tgid 8442 (syz.5.504), ts 201884660643, free_ts 201499827394 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1537 prep_new_page mm/page_alloc.c:1545 [inline] get_page_from_freelist+0x303f/0x3190 mm/page_alloc.c:3457 __alloc_pages_noprof+0x292/0x710 mm/page_alloc.c:4733 alloc_pages_mpol_noprof+0x3e8/0x680 mm/mempolicy.c:2265 kvm_coalesced_mmio_init+0x1f/0xf0 virt/kvm/coalesced_mmio.c:99 kvm_create_vm virt/kvm/kvm_main.c:1235 [inline] kvm_dev_ioctl_create_vm virt/kvm/kvm_main.c:5488 [inline] kvm_dev_ioctl+0x12dc/0x2240 virt/kvm/kvm_main.c:5530 __do_compat_sys_ioctl fs/ioctl.c:1007 [inline] __se_compat_sys_ioctl+0x510/0xc90 fs/ioctl.c:950 do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline] __do_fast_syscall_32+0xb4/0x110 arch/x86/entry/common.c:386 do_fast_syscall_32+0x34/0x80 arch/x86/entry/common.c:411 entry_SYSENTER_compat_after_hwframe+0x84/0x8e page last free pid 8399 tgid 8399 stack trace: reset_page_owner include/linux/page_owner.h:25 [inline] free_pages_prepare mm/page_alloc.c:1108 [inline] free_unref_folios+0xf12/0x18d0 mm/page_alloc.c:2686 folios_put_refs+0x76c/0x860 mm/swap.c:1007 free_pages_and_swap_cache+0x5c8/0x690 mm/swap_state.c:335 __tlb_batch_free_encoded_pages mm/mmu_gather.c:136 [inline] tlb_batch_pages_flush mm/mmu_gather.c:149 [inline] tlb_flush_mmu_free mm/mmu_gather.c:366 [inline] tlb_flush_mmu+0x3a3/0x680 mm/mmu_gather.c:373 tlb_finish_mmu+0xd4/0x200 mm/mmu_gather.c:465 exit_mmap+0x496/0xc40 mm/mmap.c:1926 __mmput+0x115/0x390 kernel/fork.c:1348 exit_mm+0x220/0x310 kernel/exit.c:571 do_exit+0x9b2/0x28e0 kernel/exit.c:926 do_group_exit+0x207/0x2c0 kernel/exit.c:1088 __do_sys_exit_group kernel/exit.c:1099 [inline] __se_sys_exit_group kernel/exit.c:1097 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1097 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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 Modules linked in: CPU: 0 UID: 0 PID: 8442 Comm: syz.5.504 Not tainted 6.12.0-rc6-syzkaller #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 bad_page+0x176/0x1d0 mm/page_alloc.c:501 free_page_is_bad mm/page_alloc.c:918 [inline] free_pages_prepare mm/page_alloc.c:1100 [inline] free_unref_page+0xed0/0xf20 mm/page_alloc.c:2638 kvm_destroy_vm virt/kvm/kvm_main.c:1327 [inline] kvm_put_kvm+0xc75/0x1350 virt/kvm/kvm_main.c:1386 kvm_vcpu_release+0x54/0x60 virt/kvm/kvm_main.c:4143 __fput+0x23f/0x880 fs/file_table.c:431 task_work_run+0x24f/0x310 kernel/task_work.c:239 exit_task_work include/linux/task_work.h:43 [inline] do_exit+0xa2f/0x28e0 kernel/exit.c:939 do_group_exit+0x207/0x2c0 kernel/exit.c:1088 __do_sys_exit_group kernel/exit.c:1099 [in ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53109", "url": "https://ubuntu.com/security/CVE-2024-53109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nommu: pass NULL argument to vma_iter_prealloc() When deleting a vma entry from a maple tree, it has to pass NULL to vma_iter_prealloc() in order to calculate internal state of the tree, but it passed a wrong argument. As a result, nommu kernels crashed upon accessing a vma iterator, such as acct_collect() reading the size of vma entries after do_munmap(). This commit fixes this issue by passing a right argument to the preallocation call.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53131", "url": "https://ubuntu.com/security/CVE-2024-53131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint Patch series \"nilfs2: fix null-ptr-deref bugs on block tracepoints\". This series fixes null pointer dereference bugs that occur when using nilfs2 and two block-related tracepoints. This patch (of 2): It has been reported that when using \"block:block_touch_buffer\" tracepoint, touch_buffer() called from __nilfs_get_folio_block() causes a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because since the tracepoint was added in touch_buffer(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, the block_device structure is set after the function returns to the caller. Here, touch_buffer() is used to mark the folio/page that owns the buffer head as accessed, but the common search helper for folio/page used by the caller function was optimized to mark the folio/page as accessed when it was reimplemented a long time ago, eliminating the need to call touch_buffer() here in the first place. So this solves the issue by eliminating the touch_buffer() call itself.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53135", "url": "https://ubuntu.com/security/CVE-2024-53135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: VMX: Bury Intel PT virtualization (guest/host mode) behind CONFIG_BROKEN Hide KVM's pt_mode module param behind CONFIG_BROKEN, i.e. disable support for virtualizing Intel PT via guest/host mode unless BROKEN=y. There are myriad bugs in the implementation, some of which are fatal to the guest, and others which put the stability and health of the host at risk. For guest fatalities, the most glaring issue is that KVM fails to ensure tracing is disabled, and *stays* disabled prior to VM-Enter, which is necessary as hardware disallows loading (the guest's) RTIT_CTL if tracing is enabled (enforced via a VMX consistency check). Per the SDM: If the logical processor is operating with Intel PT enabled (if IA32_RTIT_CTL.TraceEn = 1) at the time of VM entry, the \"load IA32_RTIT_CTL\" VM-entry control must be 0. On the host side, KVM doesn't validate the guest CPUID configuration provided by userspace, and even worse, uses the guest configuration to decide what MSRs to save/load at VM-Enter and VM-Exit. E.g. configuring guest CPUID to enumerate more address ranges than are supported in hardware will result in KVM trying to passthrough, save, and load non-existent MSRs, which generates a variety of WARNs, ToPA ERRORs in the host, a potential deadlock, etc.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53106", "url": "https://ubuntu.com/security/CVE-2024-53106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: fix buffer overrun in ima_eventdigest_init_common Function ima_eventdigest_init() calls ima_eventdigest_init_common() with HASH_ALGO__LAST which is then used to access the array hash_digest_size[] leading to buffer overrun. Have a conditional statement to handle this.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53110", "url": "https://ubuntu.com/security/CVE-2024-53110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vp_vdpa: fix id_table array not null terminated error Allocate one extra virtio_device_id as null terminator, otherwise vdpa_mgmtdev_get_classes() may iterate multiple times and visit undefined memory.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53126", "url": "https://ubuntu.com/security/CVE-2024-53126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa: solidrun: Fix UB bug with devres In psnet_open_pf_bar() and snet_open_vf_bar() a string later passed to pcim_iomap_regions() is placed on the stack. Neither pcim_iomap_regions() nor the functions it calls copy that string. Should the string later ever be used, this, consequently, causes undefined behavior since the stack frame will by then have disappeared. Fix the bug by allocating the strings on the heap through devm_kasprintf().", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53111", "url": "https://ubuntu.com/security/CVE-2024-53111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mremap: fix address wraparound in move_page_tables() On 32-bit platforms, it is possible for the expression `len + old_addr < old_end` to be false-positive if `len + old_addr` wraps around. `old_addr` is the cursor in the old range up to which page table entries have been moved; so if the operation succeeded, `old_addr` is the *end* of the old region, and adding `len` to it can wrap. The overflow causes mremap() to mistakenly believe that PTEs have been copied; the consequence is that mremap() bails out, but doesn't move the PTEs back before the new VMA is unmapped, causing anonymous pages in the region to be lost. So basically if userspace tries to mremap() a private-anon region and hits this bug, mremap() will return an error and the private-anon region's contents appear to have been zeroed. The idea of this check is that `old_end - len` is the original start address, and writing the check that way also makes it easier to read; so fix the check by rearranging the comparison accordingly. (An alternate fix would be to refactor this function by introducing an \"orig_old_start\" variable or such.) Tested in a VM with a 32-bit X86 kernel; without the patch: ``` user@horn:~/big_mremap$ cat test.c #define _GNU_SOURCE #include #include #include #include #define ADDR1 ((void*)0x60000000) #define ADDR2 ((void*)0x10000000) #define SIZE 0x50000000uL int main(void) { unsigned char *p1 = mmap(ADDR1, SIZE, PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0); if (p1 == MAP_FAILED) err(1, \"mmap 1\"); unsigned char *p2 = mmap(ADDR2, SIZE, PROT_NONE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0); if (p2 == MAP_FAILED) err(1, \"mmap 2\"); *p1 = 0x41; printf(\"first char is 0x%02hhx\\n\", *p1); unsigned char *p3 = mremap(p1, SIZE, SIZE, MREMAP_MAYMOVE|MREMAP_FIXED, p2); if (p3 == MAP_FAILED) { printf(\"mremap() failed; first char is 0x%02hhx\\n\", *p1); } else { printf(\"mremap() succeeded; first char is 0x%02hhx\\n\", *p3); } } user@horn:~/big_mremap$ gcc -static -o test test.c user@horn:~/big_mremap$ setarch -R ./test first char is 0x41 mremap() failed; first char is 0x00 ``` With the patch: ``` user@horn:~/big_mremap$ setarch -R ./test first char is 0x41 mremap() succeeded; first char is 0x41 ```", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53107", "url": "https://ubuntu.com/security/CVE-2024-53107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: prevent integer overflow in pagemap_scan_get_args() The \"arg->vec_len\" variable is a u64 that comes from the user at the start of the function. The \"arg->vec_len * sizeof(struct page_region))\" multiplication can lead to integer wrapping. Use size_mul() to avoid that. Also the size_add/mul() functions work on unsigned long so for 32bit systems we need to ensure that \"arg->vec_len\" fits in an unsigned long.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53128", "url": "https://ubuntu.com/security/CVE-2024-53128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/task_stack: fix object_is_on_stack() for KASAN tagged pointers When CONFIG_KASAN_SW_TAGS and CONFIG_KASAN_STACK are enabled, the object_is_on_stack() function may produce incorrect results due to the presence of tags in the obj pointer, while the stack pointer does not have tags. This discrepancy can lead to incorrect stack object detection and subsequently trigger warnings if CONFIG_DEBUG_OBJECTS is also enabled. Example of the warning: ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at lib/debugobjects.c:557 __debug_object_init+0x330/0x364 Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5 #4 Hardware name: linux,dummy-virt (DT) pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __debug_object_init+0x330/0x364 lr : __debug_object_init+0x330/0x364 sp : ffff800082ea7b40 x29: ffff800082ea7b40 x28: 98ff0000c0164518 x27: 98ff0000c0164534 x26: ffff800082d93ec8 x25: 0000000000000001 x24: 1cff0000c00172a0 x23: 0000000000000000 x22: ffff800082d93ed0 x21: ffff800081a24418 x20: 3eff800082ea7bb0 x19: efff800000000000 x18: 0000000000000000 x17: 00000000000000ff x16: 0000000000000047 x15: 206b63617473206e x14: 0000000000000018 x13: ffff800082ea7780 x12: 0ffff800082ea78e x11: 0ffff800082ea790 x10: 0ffff800082ea79d x9 : 34d77febe173e800 x8 : 34d77febe173e800 x7 : 0000000000000001 x6 : 0000000000000001 x5 : feff800082ea74b8 x4 : ffff800082870a90 x3 : ffff80008018d3c4 x2 : 0000000000000001 x1 : ffff800082858810 x0 : 0000000000000050 Call trace: __debug_object_init+0x330/0x364 debug_object_init_on_stack+0x30/0x3c schedule_hrtimeout_range_clock+0xac/0x26c schedule_hrtimeout+0x1c/0x30 wait_task_inactive+0x1d4/0x25c kthread_bind_mask+0x28/0x98 init_rescuer+0x1e8/0x280 workqueue_init+0x1a0/0x3cc kernel_init_freeable+0x118/0x200 kernel_init+0x28/0x1f0 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53112", "url": "https://ubuntu.com/security/CVE-2024-53112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: uncache inode which has failed entering the group Syzbot has reported the following BUG: kernel BUG at fs/ocfs2/uptodate.c:509! ... Call Trace: ? __die_body+0x5f/0xb0 ? die+0x9e/0xc0 ? do_trap+0x15a/0x3a0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? do_error_trap+0x1dc/0x2c0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? __pfx_do_error_trap+0x10/0x10 ? handle_invalid_op+0x34/0x40 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? exc_invalid_op+0x38/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? ocfs2_set_new_buffer_uptodate+0x2e/0x160 ? ocfs2_set_new_buffer_uptodate+0x144/0x160 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ocfs2_group_add+0x39f/0x15a0 ? __pfx_ocfs2_group_add+0x10/0x10 ? __pfx_lock_acquire+0x10/0x10 ? mnt_get_write_access+0x68/0x2b0 ? __pfx_lock_release+0x10/0x10 ? rcu_read_lock_any_held+0xb7/0x160 ? __pfx_rcu_read_lock_any_held+0x10/0x10 ? smack_log+0x123/0x540 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x226/0x2b0 ocfs2_ioctl+0x65e/0x7d0 ? __pfx_ocfs2_ioctl+0x10/0x10 ? smack_file_ioctl+0x29e/0x3a0 ? __pfx_smack_file_ioctl+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x43d/0x780 ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10 ? __pfx_ocfs2_ioctl+0x10/0x10 __se_sys_ioctl+0xfb/0x170 do_syscall_64+0xf3/0x230 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... When 'ioctl(OCFS2_IOC_GROUP_ADD, ...)' has failed for the particular inode in 'ocfs2_verify_group_and_input()', corresponding buffer head remains cached and subsequent call to the same 'ioctl()' for the same inode issues the BUG() in 'ocfs2_set_new_buffer_uptodate()' (trying to cache the same buffer head of that inode). Fix this by uncaching the buffer head with 'ocfs2_remove_from_cache()' on error path in 'ocfs2_group_add()'.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53113", "url": "https://ubuntu.com/security/CVE-2024-53113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: fix NULL pointer dereference in alloc_pages_bulk_noprof We triggered a NULL pointer dereference for ac.preferred_zoneref->zone in alloc_pages_bulk_noprof() when the task is migrated between cpusets. When cpuset is enabled, in prepare_alloc_pages(), ac->nodemask may be ¤t->mems_allowed. when first_zones_zonelist() is called to find preferred_zoneref, the ac->nodemask may be modified concurrently if the task is migrated between different cpusets. Assuming we have 2 NUMA Node, when traversing Node1 in ac->zonelist, the nodemask is 2, and when traversing Node2 in ac->zonelist, the nodemask is 1. As a result, the ac->preferred_zoneref points to NULL zone. In alloc_pages_bulk_noprof(), for_each_zone_zonelist_nodemask() finds a allowable zone and calls zonelist_node_idx(ac.preferred_zoneref), leading to NULL pointer dereference. __alloc_pages_noprof() fixes this issue by checking NULL pointer in commit ea57485af8f4 (\"mm, page_alloc: fix check for NULL preferred_zone\") and commit df76cee6bbeb (\"mm, page_alloc: remove redundant checks from alloc fastpath\"). To fix it, check NULL pointer for preferred_zoneref->zone.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53114", "url": "https://ubuntu.com/security/CVE-2024-53114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 client A number of Zen4 client SoCs advertise the ability to use virtualized VMLOAD/VMSAVE, but using these instructions is reported to be a cause of a random host reboot. These instructions aren't intended to be advertised on Zen4 client so clear the capability.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53137", "url": "https://ubuntu.com/security/CVE-2024-53137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: fix cacheflush with PAN It seems that the cacheflush syscall got broken when PAN for LPAE was implemented. User access was not enabled around the cache maintenance instructions, causing them to fault.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53115", "url": "https://ubuntu.com/security/CVE-2024-53115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: avoid null_ptr_deref in vmw_framebuffer_surface_create_handle The 'vmw_user_object_buffer' function may return NULL with incorrect inputs. To avoid possible null pointer dereference, add a check whether the 'bo' is NULL in the vmw_framebuffer_surface_create_handle.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53116", "url": "https://ubuntu.com/security/CVE-2024-53116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix handling of partial GPU mapping of BOs This commit fixes the bug in the handling of partial mapping of the buffer objects to the GPU, which caused kernel warnings. Panthor didn't correctly handle the case where the partial mapping spanned multiple scatterlists and the mapping offset didn't point to the 1st page of starting scatterlist. The offset variable was not cleared after reaching the starting scatterlist. Following warning messages were seen. WARNING: CPU: 1 PID: 650 at drivers/iommu/io-pgtable-arm.c:659 __arm_lpae_unmap+0x254/0x5a0 pc : __arm_lpae_unmap+0x254/0x5a0 lr : __arm_lpae_unmap+0x2cc/0x5a0 Call trace: __arm_lpae_unmap+0x254/0x5a0 __arm_lpae_unmap+0x108/0x5a0 __arm_lpae_unmap+0x108/0x5a0 __arm_lpae_unmap+0x108/0x5a0 arm_lpae_unmap_pages+0x80/0xa0 panthor_vm_unmap_pages+0xac/0x1c8 [panthor] panthor_gpuva_sm_step_unmap+0x4c/0xc8 [panthor] op_unmap_cb.isra.23.constprop.30+0x54/0x80 __drm_gpuvm_sm_unmap+0x184/0x1c8 drm_gpuvm_sm_unmap+0x40/0x60 panthor_vm_exec_op+0xa8/0x120 [panthor] panthor_vm_bind_exec_sync_op+0xc4/0xe8 [panthor] panthor_ioctl_vm_bind+0x10c/0x170 [panthor] drm_ioctl_kernel+0xbc/0x138 drm_ioctl+0x210/0x4b0 __arm64_sys_ioctl+0xb0/0xf8 invoke_syscall+0x4c/0x110 el0_svc_common.constprop.1+0x98/0xf8 do_el0_svc+0x24/0x38 el0_svc+0x34/0xc8 el0t_64_sync_handler+0xa0/0xc8 el0t_64_sync+0x174/0x178 panthor : [drm] drm_WARN_ON(unmapped_sz != pgsize * pgcount) WARNING: CPU: 1 PID: 650 at drivers/gpu/drm/panthor/panthor_mmu.c:922 panthor_vm_unmap_pages+0x124/0x1c8 [panthor] pc : panthor_vm_unmap_pages+0x124/0x1c8 [panthor] lr : panthor_vm_unmap_pages+0x124/0x1c8 [panthor] panthor : [drm] *ERROR* failed to unmap range ffffa388f000-ffffa3890000 (requested range ffffa388c000-ffffa3890000)", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53117", "url": "https://ubuntu.com/security/CVE-2024-53117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio/vsock: Improve MSG_ZEROCOPY error handling Add a missing kfree_skb() to prevent memory leaks.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53118", "url": "https://ubuntu.com/security/CVE-2024-53118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Fix sk_error_queue memory leak Kernel queues MSG_ZEROCOPY completion notifications on the error queue. Where they remain, until explicitly recv()ed. To prevent memory leaks, clean up the queue when the socket is destroyed. unreferenced object 0xffff8881028beb00 (size 224): comm \"vsock_test\", pid 1218, jiffies 4294694897 hex dump (first 32 bytes): 90 b0 21 17 81 88 ff ff 90 b0 21 17 81 88 ff ff ..!.......!..... 00 00 00 00 00 00 00 00 00 b0 21 17 81 88 ff ff ..........!..... backtrace (crc 6c7031ca): [] kmem_cache_alloc_node_noprof+0x2f7/0x370 [] __alloc_skb+0x132/0x180 [] sock_omalloc+0x4b/0x80 [] msg_zerocopy_realloc+0x9e/0x240 [] virtio_transport_send_pkt_info+0x412/0x4c0 [] virtio_transport_stream_enqueue+0x43/0x50 [] vsock_connectible_sendmsg+0x373/0x450 [] ____sys_sendmsg+0x365/0x3a0 [] ___sys_sendmsg+0x84/0xd0 [] __sys_sendmsg+0x47/0x80 [] do_syscall_64+0x93/0x180 [] entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53119", "url": "https://ubuntu.com/security/CVE-2024-53119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio/vsock: Fix accept_queue memory leak As the final stages of socket destruction may be delayed, it is possible that virtio_transport_recv_listen() will be called after the accept_queue has been flushed, but before the SOCK_DONE flag has been set. As a result, sockets enqueued after the flush would remain unremoved, leading to a memory leak. vsock_release __vsock_release lock virtio_transport_release virtio_transport_close schedule_delayed_work(close_work) sk_shutdown = SHUTDOWN_MASK (!) flush accept_queue release virtio_transport_recv_pkt vsock_find_bound_socket lock if flag(SOCK_DONE) return virtio_transport_recv_listen child = vsock_create_connected (!) vsock_enqueue_accept(child) release close_work lock virtio_transport_do_close set_flag(SOCK_DONE) virtio_transport_remove_sock vsock_remove_sock vsock_remove_bound release Introduce a sk_shutdown check to disallow vsock_enqueue_accept() during socket destruction. unreferenced object 0xffff888109e3f800 (size 2040): comm \"kworker/5:2\", pid 371, jiffies 4294940105 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00 (..@............ backtrace (crc 9e5f4e84): [] kmem_cache_alloc_noprof+0x2c1/0x360 [] sk_prot_alloc+0x30/0x120 [] sk_alloc+0x2c/0x4b0 [] __vsock_create.constprop.0+0x2a/0x310 [] virtio_transport_recv_pkt+0x4dc/0x9a0 [] vsock_loopback_work+0xfd/0x140 [] process_one_work+0x20c/0x570 [] worker_thread+0x1bf/0x3a0 [] kthread+0xdd/0x110 [] ret_from_fork+0x2d/0x50 [] ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53120", "url": "https://ubuntu.com/security/CVE-2024-53120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: CT: Fix null-ptr-deref in add rule err flow In error flow of mlx5_tc_ct_entry_add_rule(), in case ct_rule_add() callback returns error, zone_rule->attr is used uninitiated. Fix it to use attr which has the needed pointer value. Kernel log: BUG: kernel NULL pointer dereference, address: 0000000000000110 RIP: 0010:mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core] … Call Trace: ? __die+0x20/0x70 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x140 ? asm_exc_page_fault+0x22/0x30 ? mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core] ? mlx5_tc_ct_entry_add_rule+0x1d5/0x2f0 [mlx5_core] mlx5_tc_ct_block_flow_offload+0xc6a/0xf90 [mlx5_core] ? nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] flow_offload_work_handler+0x142/0x320 [nf_flow_table] ? finish_task_switch.isra.0+0x15b/0x2b0 process_one_work+0x16c/0x320 worker_thread+0x28c/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xb8/0xf0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53138", "url": "https://ubuntu.com/security/CVE-2024-53138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: kTLS, Fix incorrect page refcounting The kTLS tx handling code is using a mix of get_page() and page_ref_inc() APIs to increment the page reference. But on the release path (mlx5e_ktls_tx_handle_resync_dump_comp()), only put_page() is used. This is an issue when using pages from large folios: the get_page() references are stored on the folio page while the page_ref_inc() references are stored directly in the given page. On release the folio page will be dereferenced too many times. This was found while doing kTLS testing with sendfile() + ZC when the served file was read from NFS on a kernel with NFS large folios support (commit 49b29a573da8 (\"nfs: add support for large folios\")).", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53121", "url": "https://ubuntu.com/security/CVE-2024-53121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: fs, lock FTE when checking if active The referenced commits introduced a two-step process for deleting FTEs: - Lock the FTE, delete it from hardware, set the hardware deletion function to NULL and unlock the FTE. - Lock the parent flow group, delete the software copy of the FTE, and remove it from the xarray. However, this approach encounters a race condition if a rule with the same match value is added simultaneously. In this scenario, fs_core may set the hardware deletion function to NULL prematurely, causing a panic during subsequent rule deletions. To prevent this, ensure the active flag of the FTE is checked under a lock, which will prevent the fs_core layer from attaching a new steering rule to an FTE that is in the process of deletion. [ 438.967589] MOSHE: 2496 mlx5_del_flow_rules del_hw_func [ 438.968205] ------------[ cut here ]------------ [ 438.968654] refcount_t: decrement hit 0; leaking memory. [ 438.969249] WARNING: CPU: 0 PID: 8957 at lib/refcount.c:31 refcount_warn_saturate+0xfb/0x110 [ 438.970054] Modules linked in: act_mirred cls_flower act_gact sch_ingress openvswitch nsh mlx5_vdpa vringh vhost_iotlb vdpa mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core zram zsmalloc fuse [last unloaded: cls_flower] [ 438.973288] CPU: 0 UID: 0 PID: 8957 Comm: tc Not tainted 6.12.0-rc1+ #8 [ 438.973888] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 438.974874] RIP: 0010:refcount_warn_saturate+0xfb/0x110 [ 438.975363] Code: 40 66 3b 82 c6 05 16 e9 4d 01 01 e8 1f 7c a0 ff 0f 0b c3 cc cc cc cc 48 c7 c7 10 66 3b 82 c6 05 fd e8 4d 01 01 e8 05 7c a0 ff <0f> 0b c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 90 [ 438.976947] RSP: 0018:ffff888124a53610 EFLAGS: 00010286 [ 438.977446] RAX: 0000000000000000 RBX: ffff888119d56de0 RCX: 0000000000000000 [ 438.978090] RDX: ffff88852c828700 RSI: ffff88852c81b3c0 RDI: ffff88852c81b3c0 [ 438.978721] RBP: ffff888120fa0e88 R08: 0000000000000000 R09: ffff888124a534b0 [ 438.979353] R10: 0000000000000001 R11: 0000000000000001 R12: ffff888119d56de0 [ 438.979979] R13: ffff888120fa0ec0 R14: ffff888120fa0ee8 R15: ffff888119d56de0 [ 438.980607] FS: 00007fe6dcc0f800(0000) GS:ffff88852c800000(0000) knlGS:0000000000000000 [ 438.983984] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 438.984544] CR2: 00000000004275e0 CR3: 0000000186982001 CR4: 0000000000372eb0 [ 438.985205] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 438.985842] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 438.986507] Call Trace: [ 438.986799] [ 438.987070] ? __warn+0x7d/0x110 [ 438.987426] ? refcount_warn_saturate+0xfb/0x110 [ 438.987877] ? report_bug+0x17d/0x190 [ 438.988261] ? prb_read_valid+0x17/0x20 [ 438.988659] ? handle_bug+0x53/0x90 [ 438.989054] ? exc_invalid_op+0x14/0x70 [ 438.989458] ? asm_exc_invalid_op+0x16/0x20 [ 438.989883] ? refcount_warn_saturate+0xfb/0x110 [ 438.990348] mlx5_del_flow_rules+0x2f7/0x340 [mlx5_core] [ 438.990932] __mlx5_eswitch_del_rule+0x49/0x170 [mlx5_core] [ 438.991519] ? mlx5_lag_is_sriov+0x3c/0x50 [mlx5_core] [ 438.992054] ? xas_load+0x9/0xb0 [ 438.992407] mlx5e_tc_rule_unoffload+0x45/0xe0 [mlx5_core] [ 438.993037] mlx5e_tc_del_fdb_flow+0x2a6/0x2e0 [mlx5_core] [ 438.993623] mlx5e_flow_put+0x29/0x60 [mlx5_core] [ 438.994161] mlx5e_delete_flower+0x261/0x390 [mlx5_core] [ 438.994728] tc_setup_cb_destroy+0xb9/0x190 [ 438.995150] fl_hw_destroy_filter+0x94/0xc0 [cls_flower] [ 438.995650] fl_change+0x11a4/0x13c0 [cls_flower] [ 438.996105] tc_new_tfilter+0x347/0xbc0 [ 438.996503] ? __ ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53122", "url": "https://ubuntu.com/security/CVE-2024-53122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: cope racing subflow creation in mptcp_rcv_space_adjust Additional active subflows - i.e. created by the in kernel path manager - are included into the subflow list before starting the 3whs. A racing recvmsg() spooling data received on an already established subflow would unconditionally call tcp_cleanup_rbuf() on all the current subflows, potentially hitting a divide by zero error on the newly created ones. Explicitly check that the subflow is in a suitable state before invoking tcp_cleanup_rbuf().", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53123", "url": "https://ubuntu.com/security/CVE-2024-53123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: error out earlier on disconnect Eric reported a division by zero splat in the MPTCP protocol: Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 6094 Comm: syz-executor317 Not tainted 6.12.0-rc5-syzkaller-00291-g05b92660cdfe #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:__tcp_select_window+0x5b4/0x1310 net/ipv4/tcp_output.c:3163 Code: f6 44 01 e3 89 df e8 9b 75 09 f8 44 39 f3 0f 8d 11 ff ff ff e8 0d 74 09 f8 45 89 f4 e9 04 ff ff ff e8 00 74 09 f8 44 89 f0 99 7c 24 14 41 29 d6 45 89 f4 e9 ec fe ff ff e8 e8 73 09 f8 48 89 RSP: 0018:ffffc900041f7930 EFLAGS: 00010293 RAX: 0000000000017e67 RBX: 0000000000017e67 RCX: ffffffff8983314b RDX: 0000000000000000 RSI: ffffffff898331b0 RDI: 0000000000000004 RBP: 00000000005d6000 R08: 0000000000000004 R09: 0000000000017e67 R10: 0000000000003e80 R11: 0000000000000000 R12: 0000000000003e80 R13: ffff888031d9b440 R14: 0000000000017e67 R15: 00000000002eb000 FS: 00007feb5d7f16c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007feb5d8adbb8 CR3: 0000000074e4c000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __tcp_cleanup_rbuf+0x3e7/0x4b0 net/ipv4/tcp.c:1493 mptcp_rcv_space_adjust net/mptcp/protocol.c:2085 [inline] mptcp_recvmsg+0x2156/0x2600 net/mptcp/protocol.c:2289 inet_recvmsg+0x469/0x6a0 net/ipv4/af_inet.c:885 sock_recvmsg_nosec net/socket.c:1051 [inline] sock_recvmsg+0x1b2/0x250 net/socket.c:1073 __sys_recvfrom+0x1a5/0x2e0 net/socket.c:2265 __do_sys_recvfrom net/socket.c:2283 [inline] __se_sys_recvfrom net/socket.c:2279 [inline] __x64_sys_recvfrom+0xe0/0x1c0 net/socket.c:2279 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 RIP: 0033:0x7feb5d857559 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:00007feb5d7f1208 EFLAGS: 00000246 ORIG_RAX: 000000000000002d RAX: ffffffffffffffda RBX: 00007feb5d8e1318 RCX: 00007feb5d857559 RDX: 000000800000000e RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007feb5d8e1310 R08: 0000000000000000 R09: ffffffff81000000 R10: 0000000000000100 R11: 0000000000000246 R12: 00007feb5d8e131c R13: 00007feb5d8ae074 R14: 000000800000000e R15: 00000000fffffdef and provided a nice reproducer. The root cause is the current bad handling of racing disconnect. After the blamed commit below, sk_wait_data() can return (with error) with the underlying socket disconnected and a zero rcv_mss. Catch the error and return without performing any additional operations on the current socket.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53124", "url": "https://ubuntu.com/security/CVE-2024-53124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix data-races around sk->sk_forward_alloc Syzkaller reported this warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 16 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x1c5/0x1e0 Modules linked in: CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:inet_sock_destruct+0x1c5/0x1e0 Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 <0f> 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00 RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206 RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007 RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00 RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007 R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00 R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78 FS: 0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn+0x88/0x130 ? inet_sock_destruct+0x1c5/0x1e0 ? report_bug+0x18e/0x1a0 ? handle_bug+0x53/0x90 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? inet_sock_destruct+0x1c5/0x1e0 __sk_destruct+0x2a/0x200 rcu_do_batch+0x1aa/0x530 ? rcu_do_batch+0x13b/0x530 rcu_core+0x159/0x2f0 handle_softirqs+0xd3/0x2b0 ? __pfx_smpboot_thread_fn+0x10/0x10 run_ksoftirqd+0x25/0x30 smpboot_thread_fn+0xdd/0x1d0 kthread+0xd3/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ---[ end trace 0000000000000000 ]--- Its possible that two threads call tcp_v6_do_rcv()/sk_forward_alloc_add() concurrently when sk->sk_state == TCP_LISTEN with sk->sk_lock unlocked, which triggers a data-race around sk->sk_forward_alloc: tcp_v6_rcv tcp_v6_do_rcv skb_clone_and_charge_r sk_rmem_schedule __sk_mem_schedule sk_forward_alloc_add() skb_set_owner_r sk_mem_charge sk_forward_alloc_add() __kfree_skb skb_release_all skb_release_head_state sock_rfree sk_mem_uncharge sk_forward_alloc_add() sk_mem_reclaim // set local var reclaimable __sk_mem_reclaim sk_forward_alloc_add() In this syzkaller testcase, two threads call tcp_v6_do_rcv() with skb->truesize=768, the sk_forward_alloc changes like this: (cpu 1) | (cpu 2) | sk_forward_alloc ... | ... | 0 __sk_mem_schedule() | | +4096 = 4096 | __sk_mem_schedule() | +4096 = 8192 sk_mem_charge() | | -768 = 7424 | sk_mem_charge() | -768 = 6656 ... | ... | sk_mem_uncharge() | | +768 = 7424 reclaimable=7424 | | | sk_mem_uncharge() | +768 = 8192 | reclaimable=8192 | __sk_mem_reclaim() | | -4096 = 4096 | __sk_mem_reclaim() | -8192 = -4096 != 0 The skb_clone_and_charge_r() should not be called in tcp_v6_do_rcv() when sk->sk_state is TCP_LISTEN, it happens later in tcp_v6_syn_recv_sock(). Fix the same issue in dccp_v6_do_rcv().", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53129", "url": "https://ubuntu.com/security/CVE-2024-53129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: vop: Fix a dereferenced before check warning The 'state' can't be NULL, we should check crtc_state. Fix warning: drivers/gpu/drm/rockchip/rockchip_drm_vop.c:1096 vop_plane_atomic_async_check() warn: variable dereferenced before check 'state' (see line 1077)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53139", "url": "https://ubuntu.com/security/CVE-2024-53139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix possible UAF in sctp_v6_available() A lockdep report [1] with CONFIG_PROVE_RCU_LIST=y hints that sctp_v6_available() is calling dev_get_by_index_rcu() and ipv6_chk_addr() without holding rcu. [1] ============================= WARNING: suspicious RCU usage 6.12.0-rc5-virtme #1216 Tainted: G W ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by sctp_hello/31495: #0: ffff9f1ebbdb7418 (sk_lock-AF_INET6){+.+.}-{0:0}, at: sctp_bind (./arch/x86/include/asm/jump_label.h:27 net/sctp/socket.c:315) sctp stack backtrace: CPU: 7 UID: 0 PID: 31495 Comm: sctp_hello Tainted: G W 6.12.0-rc5-virtme #1216 Tainted: [W]=WARN 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:123) lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822) dev_get_by_index_rcu (net/core/dev.c:876 (discriminator 7)) sctp_v6_available (net/sctp/ipv6.c:701) sctp sctp_do_bind (net/sctp/socket.c:400 (discriminator 1)) sctp sctp_bind (net/sctp/socket.c:320) sctp inet6_bind_sk (net/ipv6/af_inet6.c:465) ? security_socket_bind (security/security.c:4581 (discriminator 1)) __sys_bind (net/socket.c:1848 net/socket.c:1869) ? do_user_addr_fault (./include/linux/rcupdate.h:347 ./include/linux/rcupdate.h:880 ./include/linux/mm.h:729 arch/x86/mm/fault.c:1340) ? do_user_addr_fault (./arch/x86/include/asm/preempt.h:84 (discriminator 13) ./include/linux/rcupdate.h:98 (discriminator 13) ./include/linux/rcupdate.h:882 (discriminator 13) ./include/linux/mm.h:729 (discriminator 13) arch/x86/mm/fault.c:1340 (discriminator 13)) __x64_sys_bind (net/socket.c:1877 (discriminator 1) net/socket.c:1875 (discriminator 1) net/socket.c:1875 (discriminator 1)) do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f59b934a1e7 Code: 44 00 00 48 8b 15 39 8c 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 b8 31 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 09 8c 0c 00 f7 d8 64 89 01 48 All code ======== 0:\t44 00 00 \tadd %r8b,(%rax) 3:\t48 8b 15 39 8c 0c 00 \tmov 0xc8c39(%rip),%rdx # 0xc8c43 a:\tf7 d8 \tneg %eax c:\t64 89 02 \tmov %eax,%fs:(%rdx) f:\tb8 ff ff ff ff \tmov $0xffffffff,%eax 14:\teb bd \tjmp 0xffffffffffffffd3 16:\t66 2e 0f 1f 84 00 00 \tcs nopw 0x0(%rax,%rax,1) 1d:\t00 00 00 20:\t0f 1f 00 \tnopl (%rax) 23:\tb8 31 00 00 00 \tmov $0x31,%eax 28:\t0f 05 \tsyscall 2a:*\t48 3d 01 f0 ff ff \tcmp $0xfffffffffffff001,%rax\t\t<-- trapping instruction 30:\t73 01 \tjae 0x33 32:\tc3 \tret 33:\t48 8b 0d 09 8c 0c 00 \tmov 0xc8c09(%rip),%rcx # 0xc8c43 3a:\tf7 d8 \tneg %eax 3c:\t64 89 01 \tmov %eax,%fs:(%rcx) 3f:\t48 \trex.W Code starting with the faulting instruction =========================================== 0:\t48 3d 01 f0 ff ff \tcmp $0xfffffffffffff001,%rax 6:\t73 01 \tjae 0x9 8:\tc3 \tret 9:\t48 8b 0d 09 8c 0c 00 \tmov 0xc8c09(%rip),%rcx # 0xc8c19 10:\tf7 d8 \tneg %eax 12:\t64 89 01 \tmov %eax,%fs:(%rcx) 15:\t48 \trex.W RSP: 002b:00007ffe2d0ad398 EFLAGS: 00000202 ORIG_RAX: 0000000000000031 RAX: ffffffffffffffda RBX: 00007ffe2d0ad3d0 RCX: 00007f59b934a1e7 RDX: 000000000000001c RSI: 00007ffe2d0ad3d0 RDI: 0000000000000005 RBP: 0000000000000005 R08: 1999999999999999 R09: 0000000000000000 R10: 00007f59b9253298 R11: 000000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53140", "url": "https://ubuntu.com/security/CVE-2024-53140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netlink: terminate outstanding dump on socket close Netlink supports iterative dumping of data. It provides the families the following ops: - start - (optional) kicks off the dumping process - dump - actual dump helper, keeps getting called until it returns 0 - done - (optional) pairs with .start, can be used for cleanup The whole process is asynchronous and the repeated calls to .dump don't actually happen in a tight loop, but rather are triggered in response to recvmsg() on the socket. This gives the user full control over the dump, but also means that the user can close the socket without getting to the end of the dump. To make sure .start is always paired with .done we check if there is an ongoing dump before freeing the socket, and if so call .done. The complication is that sockets can get freed from BH and .done is allowed to sleep. So we use a workqueue to defer the call, when needed. Unfortunately this does not work correctly. What we defer is not the cleanup but rather releasing a reference on the socket. We have no guarantee that we own the last reference, if someone else holds the socket they may release it in BH and we're back to square one. The whole dance, however, appears to be unnecessary. Only the user can interact with dumps, so we can clean up when socket is closed. And close always happens in process context. Some async code may still access the socket after close, queue notification skbs to it etc. but no dumps can start, end or otherwise make progress. Delete the workqueue and flush the dump state directly from the release handler. Note that further cleanup is possible in -next, for instance we now always call .done before releasing the main module reference, so dump doesn't have to take a reference of its own.", "cve_priority": "high", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53098", "url": "https://ubuntu.com/security/CVE-2024-53098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/ufence: Prefetch ufence addr to catch bogus address access_ok() only checks for addr overflow so also try to read the addr to catch invalid addr sent from userspace. (cherry picked from commit 9408c4508483ffc60811e910a93d6425b8e63928)", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53099", "url": "https://ubuntu.com/security/CVE-2024-53099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check validity of link->type in bpf_link_show_fdinfo() If a newly-added link type doesn't invoke BPF_LINK_TYPE(), accessing bpf_link_type_strs[link->type] may result in an out-of-bounds access. To spot such missed invocations early in the future, checking the validity of link->type in bpf_link_show_fdinfo() and emitting a warning when such invocations are missed.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53089", "url": "https://ubuntu.com/security/CVE-2024-53089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: KVM: Mark hrtimer to expire in hard interrupt context Like commit 2c0d278f3293f (\"KVM: LAPIC: Mark hrtimer to expire in hard interrupt context\") and commit 9090825fa9974 (\"KVM: arm/arm64: Let the timer expire in hardirq context on RT\"), On PREEMPT_RT enabled kernels unmarked hrtimers are moved into soft interrupt expiry mode by default. Then the timers are canceled from an preempt-notifier which is invoked with disabled preemption which is not allowed on PREEMPT_RT. The timer callback is short so in could be invoked in hard-IRQ context. So let the timer expire on hard-IRQ context even on -RT. This fix a \"scheduling while atomic\" bug for PREEMPT_RT enabled kernels: BUG: scheduling while atomic: qemu-system-loo/1011/0x00000002 Modules linked in: amdgpu rfkill nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat ns CPU: 1 UID: 0 PID: 1011 Comm: qemu-system-loo Tainted: G W 6.12.0-rc2+ #1774 Tainted: [W]=WARN Hardware name: Loongson Loongson-3A5000-7A1000-1w-CRB/Loongson-LS3A5000-7A1000-1w-CRB, BIOS vUDK2018-LoongArch-V2.0.0-prebeta9 10/21/2022 Stack : ffffffffffffffff 0000000000000000 9000000004e3ea38 9000000116744000 90000001167475a0 0000000000000000 90000001167475a8 9000000005644830 90000000058dc000 90000000058dbff8 9000000116747420 0000000000000001 0000000000000001 6a613fc938313980 000000000790c000 90000001001c1140 00000000000003fe 0000000000000001 000000000000000d 0000000000000003 0000000000000030 00000000000003f3 000000000790c000 9000000116747830 90000000057ef000 0000000000000000 9000000005644830 0000000000000004 0000000000000000 90000000057f4b58 0000000000000001 9000000116747868 900000000451b600 9000000005644830 9000000003a13998 0000000010000020 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d ... Call Trace: [<9000000003a13998>] show_stack+0x38/0x180 [<9000000004e3ea34>] dump_stack_lvl+0x84/0xc0 [<9000000003a71708>] __schedule_bug+0x48/0x60 [<9000000004e45734>] __schedule+0x1114/0x1660 [<9000000004e46040>] schedule_rtlock+0x20/0x60 [<9000000004e4e330>] rtlock_slowlock_locked+0x3f0/0x10a0 [<9000000004e4f038>] rt_spin_lock+0x58/0x80 [<9000000003b02d68>] hrtimer_cancel_wait_running+0x68/0xc0 [<9000000003b02e30>] hrtimer_cancel+0x70/0x80 [] kvm_restore_timer+0x50/0x1a0 [kvm] [] kvm_arch_vcpu_load+0x68/0x2a0 [kvm] [] kvm_sched_in+0x34/0x60 [kvm] [<9000000003a749a0>] finish_task_switch.isra.0+0x140/0x2e0 [<9000000004e44a70>] __schedule+0x450/0x1660 [<9000000004e45cb0>] schedule+0x30/0x180 [] kvm_vcpu_block+0x70/0x120 [kvm] [] kvm_vcpu_halt+0x60/0x3e0 [kvm] [] kvm_handle_gspr+0x3f4/0x4e0 [kvm] [] kvm_handle_exit+0x1c8/0x260 [kvm]", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53090", "url": "https://ubuntu.com/security/CVE-2024-53090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix lock recursion afs_wake_up_async_call() can incur lock recursion. The problem is that it is called from AF_RXRPC whilst holding the ->notify_lock, but it tries to take a ref on the afs_call struct in order to pass it to a work queue - but if the afs_call is already queued, we then have an extraneous ref that must be put... calling afs_put_call() may call back down into AF_RXRPC through rxrpc_kernel_shutdown_call(), however, which might try taking the ->notify_lock again. This case isn't very common, however, so defer it to a workqueue. The oops looks something like: BUG: spinlock recursion on CPU#0, krxrpcio/7001/1646 lock: 0xffff888141399b30, .magic: dead4ead, .owner: krxrpcio/7001/1646, .owner_cpu: 0 CPU: 0 UID: 0 PID: 1646 Comm: krxrpcio/7001 Not tainted 6.12.0-rc2-build3+ #4351 Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014 Call Trace: dump_stack_lvl+0x47/0x70 do_raw_spin_lock+0x3c/0x90 rxrpc_kernel_shutdown_call+0x83/0xb0 afs_put_call+0xd7/0x180 rxrpc_notify_socket+0xa0/0x190 rxrpc_input_split_jumbo+0x198/0x1d0 rxrpc_input_data+0x14b/0x1e0 ? rxrpc_input_call_packet+0xc2/0x1f0 rxrpc_input_call_event+0xad/0x6b0 rxrpc_input_packet_on_conn+0x1e1/0x210 rxrpc_input_packet+0x3f2/0x4d0 rxrpc_io_thread+0x243/0x410 ? __pfx_rxrpc_io_thread+0x10/0x10 kthread+0xcf/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x24/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53101", "url": "https://ubuntu.com/security/CVE-2024-53101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized value issue in from_kuid and from_kgid ocfs2_setattr() uses attr->ia_mode, attr->ia_uid and attr->ia_gid in a trace point even though ATTR_MODE, ATTR_UID and ATTR_GID aren't set. Initialize all fields of newattrs to avoid uninitialized variables, by checking if ATTR_MODE, ATTR_UID, ATTR_GID are initialized, otherwise 0.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53091", "url": "https://ubuntu.com/security/CVE-2024-53091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Add sk_is_inet and IS_ICSK check in tls_sw_has_ctx_tx/rx As the introduction of the support for vsock and unix sockets in sockmap, tls_sw_has_ctx_tx/rx cannot presume the socket passed in must be IS_ICSK. vsock and af_unix sockets have vsock_sock and unix_sock instead of inet_connection_sock. For these sockets, tls_get_ctx may return an invalid pointer and cause page fault in function tls_sw_ctx_rx. BUG: unable to handle page fault for address: 0000000000040030 Workqueue: vsock-loopback vsock_loopback_work RIP: 0010:sk_psock_strp_data_ready+0x23/0x60 Call Trace: ? __die+0x81/0xc3 ? no_context+0x194/0x350 ? do_page_fault+0x30/0x110 ? async_page_fault+0x3e/0x50 ? sk_psock_strp_data_ready+0x23/0x60 virtio_transport_recv_pkt+0x750/0x800 ? update_load_avg+0x7e/0x620 vsock_loopback_work+0xd0/0x100 process_one_work+0x1a7/0x360 worker_thread+0x30/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x112/0x130 ? __kthread_cancel_work+0x40/0x40 ret_from_fork+0x1f/0x40 v2: - Add IS_ICSK check v3: - Update the commits in Fixes", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53092", "url": "https://ubuntu.com/security/CVE-2024-53092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_pci: Fix admin vq cleanup by using correct info pointer vp_modern_avq_cleanup() and vp_del_vqs() clean up admin vq resources by virtio_pci_vq_info pointer. The info pointer of admin vq is stored in vp_dev->admin_vq.info instead of vp_dev->vqs[]. Using the info pointer from vp_dev->vqs[] for admin vq causes a kernel NULL pointer dereference bug. In vp_modern_avq_cleanup() and vp_del_vqs(), get the info pointer from vp_dev->admin_vq.info for admin vq to clean up the resources. Also make info ptr as argument of vp_del_vq() to be symmetric with vp_setup_vq(). vp_reset calls vp_modern_avq_cleanup, and causes the Call Trace: ================================================================== BUG: kernel NULL pointer dereference, address:0000000000000000 ... CPU: 49 UID: 0 PID: 4439 Comm: modprobe Not tainted 6.11.0-rc5 #1 RIP: 0010:vp_reset+0x57/0x90 [virtio_pci] Call Trace: ... ? vp_reset+0x57/0x90 [virtio_pci] ? vp_reset+0x38/0x90 [virtio_pci] virtio_reset_device+0x1d/0x30 remove_vq_common+0x1c/0x1a0 [virtio_net] virtnet_remove+0xa1/0xc0 [virtio_net] virtio_dev_remove+0x46/0xa0 ... virtio_pci_driver_exit+0x14/0x810 [virtio_pci] ==================================================================", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53102", "url": "https://ubuntu.com/security/CVE-2024-53102", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53093", "url": "https://ubuntu.com/security/CVE-2024-53093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: defer partition scanning We need to suppress the partition scan from occuring within the controller's scan_work context. If a path error occurs here, the IO will wait until a path becomes available or all paths are torn down, but that action also occurs within scan_work, so it would deadlock. Defer the partion scan to a different context that does not block scan_work.", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53094", "url": "https://ubuntu.com/security/CVE-2024-53094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Add sendpage_ok() check to disable MSG_SPLICE_PAGES While running ISER over SIW, the initiator machine encounters a warning from skb_splice_from_iter() indicating that a slab page is being used in send_page. To address this, it is better to add a sendpage_ok() check within the driver itself, and if it returns 0, then MSG_SPLICE_PAGES flag should be disabled before entering the network stack. A similar issue has been discussed for NVMe in this thread: https://lore.kernel.org/all/20240530142417.146696-1-ofir.gal@volumez.com/ WARNING: CPU: 0 PID: 5342 at net/core/skbuff.c:7140 skb_splice_from_iter+0x173/0x320 Call Trace: tcp_sendmsg_locked+0x368/0xe40 siw_tx_hdt+0x695/0xa40 [siw] siw_qp_sq_process+0x102/0xb00 [siw] siw_sq_resume+0x39/0x110 [siw] siw_run_sq+0x74/0x160 [siw] kthread+0xd2/0x100 ret_from_fork+0x34/0x40 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53100", "url": "https://ubuntu.com/security/CVE-2024-53100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: tcp: avoid race between queue_lock lock and destroy Commit 76d54bf20cdc (\"nvme-tcp: don't access released socket during error recovery\") added a mutex_lock() call for the queue->queue_lock in nvme_tcp_get_address(). However, the mutex_lock() races with mutex_destroy() in nvme_tcp_free_queue(), and causes the WARN below. DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: CPU: 3 PID: 34077 at kernel/locking/mutex.c:587 __mutex_lock+0xcf0/0x1220 Modules linked in: nvmet_tcp nvmet nvme_tcp nvme_fabrics iw_cm ib_cm ib_core pktcdvd nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables qrtr sunrpc ppdev 9pnet_virtio 9pnet pcspkr netfs parport_pc parport e1000 i2c_piix4 i2c_smbus loop fuse nfnetlink zram bochs drm_vram_helper drm_ttm_helper ttm drm_kms_helper xfs drm sym53c8xx floppy nvme scsi_transport_spi nvme_core nvme_auth serio_raw ata_generic pata_acpi dm_multipath qemu_fw_cfg [last unloaded: ib_uverbs] CPU: 3 UID: 0 PID: 34077 Comm: udisksd Not tainted 6.11.0-rc7 #319 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:__mutex_lock+0xcf0/0x1220 Code: 08 84 d2 0f 85 c8 04 00 00 8b 15 ef b6 c8 01 85 d2 0f 85 78 f4 ff ff 48 c7 c6 20 93 ee af 48 c7 c7 60 91 ee af e8 f0 a7 6d fd <0f> 0b e9 5e f4 ff ff 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 RSP: 0018:ffff88811305f760 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff88812c652058 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000001 RBP: ffff88811305f8b0 R08: 0000000000000001 R09: ffffed1075c36341 R10: ffff8883ae1b1a0b R11: 0000000000010498 R12: 0000000000000000 R13: 0000000000000000 R14: dffffc0000000000 R15: ffff88812c652058 FS: 00007f9713ae4980(0000) GS:ffff8883ae180000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcd78483c7c CR3: 0000000122c38000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn.cold+0x5b/0x1af ? __mutex_lock+0xcf0/0x1220 ? report_bug+0x1ec/0x390 ? handle_bug+0x3c/0x80 ? exc_invalid_op+0x13/0x40 ? asm_exc_invalid_op+0x16/0x20 ? __mutex_lock+0xcf0/0x1220 ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] ? __pfx___mutex_lock+0x10/0x10 ? __lock_acquire+0xd6a/0x59e0 ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] ? __pfx_nvme_tcp_get_address+0x10/0x10 [nvme_tcp] nvme_sysfs_show_address+0x81/0xc0 [nvme_core] dev_attr_show+0x42/0x80 ? __asan_memset+0x1f/0x40 sysfs_kf_seq_show+0x1f0/0x370 seq_read_iter+0x2cb/0x1130 ? rw_verify_area+0x3b1/0x590 ? __mutex_lock+0x433/0x1220 vfs_read+0x6a6/0xa20 ? lockdep_hardirqs_on+0x78/0x100 ? __pfx_vfs_read+0x10/0x10 ksys_read+0xf7/0x1d0 ? __pfx_ksys_read+0x10/0x10 ? __x64_sys_openat+0x105/0x1d0 do_syscall_64+0x93/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? __pfx_ksys_read+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? do_syscall_64+0x9f/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f9713f55cfa Code: 55 48 89 e5 48 83 ec 20 48 89 55 e8 48 89 75 f0 89 7d f8 e8 e8 74 f8 ff 48 8b 55 e8 48 8b 75 f0 4 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53095", "url": "https://ubuntu.com/security/CVE-2024-53095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix use-after-free of network namespace. Recently, we got a customer report that CIFS triggers oops while reconnecting to a server. [0] The workload runs on Kubernetes, and some pods mount CIFS servers in non-root network namespaces. The problem rarely happened, but it was always while the pod was dying. The root cause is wrong reference counting for network namespace. CIFS uses kernel sockets, which do not hold refcnt of the netns that the socket belongs to. That means CIFS must ensure the socket is always freed before its netns; otherwise, use-after-free happens. The repro steps are roughly: 1. mount CIFS in a non-root netns 2. drop packets from the netns 3. destroy the netns 4. unmount CIFS We can reproduce the issue quickly with the script [1] below and see the splat [2] if CONFIG_NET_NS_REFCNT_TRACKER is enabled. When the socket is TCP, it is hard to guarantee the netns lifetime without holding refcnt due to async timers. Let's hold netns refcnt for each socket as done for SMC in commit 9744d2bf1976 (\"smc: Fix use-after-free in tcp_write_timer_handler().\"). Note that we need to move put_net() from cifs_put_tcp_session() to clean_demultiplex_info(); otherwise, __sock_create() still could touch a freed netns while cifsd tries to reconnect from cifs_demultiplex_thread(). Also, maybe_get_net() cannot be put just before __sock_create() because the code is not under RCU and there is a small chance that the same address happened to be reallocated to another netns. [0]: CIFS: VFS: \\\\XXXXXXXXXXX has not responded in 15 seconds. Reconnecting... CIFS: Serverclose failed 4 times, giving up Unable to handle kernel paging request at virtual address 14de99e461f84a07 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 CM = 0, WnR = 0 [14de99e461f84a07] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: cls_bpf sch_ingress nls_utf8 cifs cifs_arc4 cifs_md4 dns_resolver tcp_diag inet_diag veth xt_state xt_connmark nf_conntrack_netlink xt_nat xt_statistic xt_MASQUERADE xt_mark xt_addrtype ipt_REJECT nf_reject_ipv4 nft_chain_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment nft_compat nf_tables nfnetlink overlay nls_ascii nls_cp437 sunrpc vfat fat aes_ce_blk aes_ce_cipher ghash_ce sm4_ce_cipher sm4 sm3_ce sm3 sha3_ce sha512_ce sha512_arm64 sha1_ce ena button sch_fq_codel loop fuse configfs dmi_sysfs sha2_ce sha256_arm64 dm_mirror dm_region_hash dm_log dm_mod dax efivarfs CPU: 5 PID: 2690970 Comm: cifsd Not tainted 6.1.103-109.184.amzn2023.aarch64 #1 Hardware name: Amazon EC2 r7g.4xlarge/, BIOS 1.0 11/1/2018 pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : fib_rules_lookup+0x44/0x238 lr : __fib_lookup+0x64/0xbc sp : ffff8000265db790 x29: ffff8000265db790 x28: 0000000000000000 x27: 000000000000bd01 x26: 0000000000000000 x25: ffff000b4baf8000 x24: ffff00047b5e4580 x23: ffff8000265db7e0 x22: 0000000000000000 x21: ffff00047b5e4500 x20: ffff0010e3f694f8 x19: 14de99e461f849f7 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 3f92800abd010002 x11: 0000000000000001 x10: ffff0010e3f69420 x9 : ffff800008a6f294 x8 : 0000000000000000 x7 : 0000000000000006 x6 : 0000000000000000 x5 : 0000000000000001 x4 : ffff001924354280 x3 : ffff8000265db7e0 x2 : 0000000000000000 x1 : ffff0010e3f694f8 x0 : ffff00047b5e4500 Call trace: fib_rules_lookup+0x44/0x238 __fib_lookup+0x64/0xbc ip_route_output_key_hash_rcu+0x2c4/0x398 ip_route_output_key_hash+0x60/0x8c tcp_v4_connect+0x290/0x488 __inet_stream_connect+0x108/0x3d0 inet_stream_connect+0x50/0x78 kernel_connect+0x6c/0xac generic_ip_conne ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-50265", "url": "https://ubuntu.com/security/CVE-2024-50265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove() Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove(): [ 57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12 [ 57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry [ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004 [...] [ 57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [...] [ 57.331328] Call Trace: [ 57.331477] [...] [ 57.333511] ? do_user_addr_fault+0x3e5/0x740 [ 57.333778] ? exc_page_fault+0x70/0x170 [ 57.334016] ? asm_exc_page_fault+0x2b/0x30 [ 57.334263] ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10 [ 57.334596] ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [ 57.334913] ocfs2_xa_remove_entry+0x23/0xc0 [ 57.335164] ocfs2_xa_set+0x704/0xcf0 [ 57.335381] ? _raw_spin_unlock+0x1a/0x40 [ 57.335620] ? ocfs2_inode_cache_unlock+0x16/0x20 [ 57.335915] ? trace_preempt_on+0x1e/0x70 [ 57.336153] ? start_this_handle+0x16c/0x500 [ 57.336410] ? preempt_count_sub+0x50/0x80 [ 57.336656] ? _raw_read_unlock+0x20/0x40 [ 57.336906] ? start_this_handle+0x16c/0x500 [ 57.337162] ocfs2_xattr_block_set+0xa6/0x1e0 [ 57.337424] __ocfs2_xattr_set_handle+0x1fd/0x5d0 [ 57.337706] ? ocfs2_start_trans+0x13d/0x290 [ 57.337971] ocfs2_xattr_set+0xb13/0xfb0 [ 57.338207] ? dput+0x46/0x1c0 [ 57.338393] ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338665] ? ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338948] __vfs_removexattr+0x92/0xc0 [ 57.339182] __vfs_removexattr_locked+0xd5/0x190 [ 57.339456] ? preempt_count_sub+0x50/0x80 [ 57.339705] vfs_removexattr+0x5f/0x100 [...] Reproducer uses faultinject facility to fail ocfs2_xa_remove() -> ocfs2_xa_value_truncate() with -ENOMEM. In this case the comment mentions that we can return 0 if ocfs2_xa_cleanup_value_truncate() is going to wipe the entry anyway. But the following 'rc' check is wrong and execution flow do 'ocfs2_xa_remove_entry(loc);' twice: * 1st: in ocfs2_xa_cleanup_value_truncate(); * 2nd: returning back to ocfs2_xa_remove() instead of going to 'out'. Fix this by skipping the 2nd removal of the same entry and making syzkaller repro happy.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50266", "url": "https://ubuntu.com/security/CVE-2024-50266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: qcom: videocc-sm8350: use HW_CTRL_TRIGGER for vcodec GDSCs A recent change in the venus driver results in a stuck clock on the Lenovo ThinkPad X13s, for example, when streaming video in firefox: \tvideo_cc_mvs0_clk status stuck at 'off' \tWARNING: CPU: 6 PID: 2885 at drivers/clk/qcom/clk-branch.c:87 clk_branch_wait+0x144/0x15c \t... \tCall trace: \t clk_branch_wait+0x144/0x15c \t clk_branch2_enable+0x30/0x40 \t clk_core_enable+0xd8/0x29c \t clk_enable+0x2c/0x4c \t vcodec_clks_enable.isra.0+0x94/0xd8 [venus_core] \t coreid_power_v4+0x464/0x628 [venus_core] \t vdec_start_streaming+0xc4/0x510 [venus_dec] \t vb2_start_streaming+0x6c/0x180 [videobuf2_common] \t vb2_core_streamon+0x120/0x1dc [videobuf2_common] \t vb2_streamon+0x1c/0x6c [videobuf2_v4l2] \t v4l2_m2m_ioctl_streamon+0x30/0x80 [v4l2_mem2mem] \t v4l_streamon+0x24/0x30 [videodev] using the out-of-tree sm8350/sc8280xp venus support. [1] Update also the sm8350/sc8280xp GDSC definitions so that the hw control mode can be changed at runtime as the venus driver now requires.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50267", "url": "https://ubuntu.com/security/CVE-2024-50267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: fix use after free in debug printk The \"dev_dbg(&urb->dev->dev, ...\" which happens after usb_free_urb(urb) is a use after free of the \"urb\" pointer. Store the \"dev\" pointer at the start of the function to avoid this issue.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50268", "url": "https://ubuntu.com/security/CVE-2024-50268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: fix potential out of bounds in ucsi_ccg_update_set_new_cam_cmd() The \"*cmd\" variable can be controlled by the user via debugfs. That means \"new_cam\" can be as high as 255 while the size of the uc->updated[] array is UCSI_MAX_ALTMODES (30). The call tree is: ucsi_cmd() // val comes from simple_attr_write_xsigned() -> ucsi_send_command() -> ucsi_send_command_common() -> ucsi_run_command() // calls ucsi->ops->sync_control() -> ucsi_ccg_sync_control()", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53083", "url": "https://ubuntu.com/security/CVE-2024-53083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: qcom-pmic: init value of hdr_len/txbuf_len earlier If the read of USB_PDPHY_RX_ACKNOWLEDGE_REG failed, then hdr_len and txbuf_len are uninitialized. This commit stops to print uninitialized value and misleading/false data.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50269", "url": "https://ubuntu.com/security/CVE-2024-50269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: musb: sunxi: Fix accessing an released usb phy Commit 6ed05c68cbca (\"usb: musb: sunxi: Explicitly release USB PHY on exit\") will cause that usb phy @glue->xceiv is accessed after released. 1) register platform driver @sunxi_musb_driver // get the usb phy @glue->xceiv sunxi_musb_probe() -> devm_usb_get_phy(). 2) register and unregister platform driver @musb_driver musb_probe() -> sunxi_musb_init() use the phy here //the phy is released here musb_remove() -> sunxi_musb_exit() -> devm_usb_put_phy() 3) register @musb_driver again musb_probe() -> sunxi_musb_init() use the phy here but the phy has been released at 2). ... Fixed by reverting the commit, namely, removing devm_usb_put_phy() from sunxi_musb_exit().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53079", "url": "https://ubuntu.com/security/CVE-2024-53079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/thp: fix deferred split unqueue naming and locking Recent changes are putting more pressure on THP deferred split queues: under load revealing long-standing races, causing list_del corruptions, \"Bad page state\"s and worse (I keep BUGs in both of those, so usually don't get to see how badly they end up without). The relevant recent changes being 6.8's mTHP, 6.10's mTHP swapout, and 6.12's mTHP swapin, improved swap allocation, and underused THP splitting. Before fixing locking: rename misleading folio_undo_large_rmappable(), which does not undo large_rmappable, to folio_unqueue_deferred_split(), which is what it does. But that and its out-of-line __callee are mm internals of very limited usability: add comment and WARN_ON_ONCEs to check usage; and return a bool to say if a deferred split was unqueued, which can then be used in WARN_ON_ONCEs around safety checks (sparing callers the arcane conditionals in __folio_unqueue_deferred_split()). Just omit the folio_unqueue_deferred_split() from free_unref_folios(), all of whose callers now call it beforehand (and if any forget then bad_page() will tell) - except for its caller put_pages_list(), which itself no longer has any callers (and will be deleted separately). Swapout: mem_cgroup_swapout() has been resetting folio->memcg_data 0 without checking and unqueueing a THP folio from deferred split list; which is unfortunate, since the split_queue_lock depends on the memcg (when memcg is enabled); so swapout has been unqueueing such THPs later, when freeing the folio, using the pgdat's lock instead: potentially corrupting the memcg's list. __remove_mapping() has frozen refcount to 0 here, so no problem with calling folio_unqueue_deferred_split() before resetting memcg_data. That goes back to 5.4 commit 87eaceb3faa5 (\"mm: thp: make deferred split shrinker memcg aware\"): which included a check on swapcache before adding to deferred queue, but no check on deferred queue before adding THP to swapcache. That worked fine with the usual sequence of events in reclaim (though there were a couple of rare ways in which a THP on deferred queue could have been swapped out), but 6.12 commit dafff3f4c850 (\"mm: split underused THPs\") avoids splitting underused THPs in reclaim, which makes swapcache THPs on deferred queue commonplace. Keep the check on swapcache before adding to deferred queue? Yes: it is no longer essential, but preserves the existing behaviour, and is likely to be a worthwhile optimization (vmstat showed much more traffic on the queue under swapping load if the check was removed); update its comment. Memcg-v1 move (deprecated): mem_cgroup_move_account() has been changing folio->memcg_data without checking and unqueueing a THP folio from the deferred list, sometimes corrupting \"from\" memcg's list, like swapout. Refcount is non-zero here, so folio_unqueue_deferred_split() can only be used in a WARN_ON_ONCE to validate the fix, which must be done earlier: mem_cgroup_move_charge_pte_range() first try to split the THP (splitting of course unqueues), or skip it if that fails. Not ideal, but moving charge has been requested, and khugepaged should repair the THP later: nobody wants new custom unqueueing code just for this deprecated case. The 87eaceb3faa5 commit did have the code to move from one deferred list to another (but was not conscious of its unsafety while refcount non-0); but that was removed by 5.6 commit fac0516b5534 (\"mm: thp: don't need care deferred split queue in memcg charge move path\"), which argued that the existence of a PMD mapping guarantees that the THP cannot be on a deferred list. As above, false in rare cases, and now commonly false. Backport to 6.11 should be straightforward. Earlier backports must take care that other _deferred_list fixes and dependencies are included. There is not a strong case for backports, but they can fix cornercases.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50270", "url": "https://ubuntu.com/security/CVE-2024-50270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: avoid overflow in damon_feed_loop_next_input() damon_feed_loop_next_input() is inefficient and fragile to overflows. Specifically, 'score_goal_diff_bp' calculation can overflow when 'score' is high. The calculation is actually unnecessary at all because 'goal' is a constant of value 10,000. Calculation of 'compensation' is again fragile to overflow. Final calculation of return value for under-achiving case is again fragile to overflow when the current score is under-achieving the target. Add two corner cases handling at the beginning of the function to make the body easier to read, and rewrite the body of the function to avoid overflows and the unnecessary bp value calcuation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50271", "url": "https://ubuntu.com/security/CVE-2024-50271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: signal: restore the override_rlimit logic Prior to commit d64696905554 (\"Reimplement RLIMIT_SIGPENDING on top of ucounts\") UCOUNT_RLIMIT_SIGPENDING rlimit was not enforced for a class of signals. However now it's enforced unconditionally, even if override_rlimit is set. This behavior change caused production issues. For example, if the limit is reached and a process receives a SIGSEGV signal, sigqueue_alloc fails to allocate the necessary resources for the signal delivery, preventing the signal from being delivered with siginfo. This prevents the process from correctly identifying the fault address and handling the error. From the user-space perspective, applications are unaware that the limit has been reached and that the siginfo is effectively 'corrupted'. This can lead to unpredictable behavior and crashes, as we observed with java applications. Fix this by passing override_rlimit into inc_rlimit_get_ucounts() and skip the comparison to max there if override_rlimit is set. This effectively restores the old behavior.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50272", "url": "https://ubuntu.com/security/CVE-2024-50272", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: filemap: Fix bounds checking in filemap_read() If the caller supplies an iocb->ki_pos value that is close to the filesystem upper limit, and an iterator with a count that causes us to overflow that limit, then filemap_read() enters an infinite loop. This behaviour was discovered when testing xfstests generic/525 with the \"localio\" optimisation for loopback NFS mounts.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53104", "url": "https://ubuntu.com/security/CVE-2024-53104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_parse_format This can lead to out of bounds writes since frames of this type were not taken into account when calculating the size of the frames buffer in uvc_parse_streaming.", "cve_priority": "high", "cve_public_date": "2024-12-02 08:15:00 UTC" }, { "cve": "CVE-2024-50273", "url": "https://ubuntu.com/security/CVE-2024-50273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reinitialize delayed ref list after deleting it from the list At insert_delayed_ref() if we need to update the action of an existing ref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head's ref_add_list using list_del(), which leaves the ref's add_list member not reinitialized, as list_del() sets the next and prev members of the list to LIST_POISON1 and LIST_POISON2, respectively. If later we end up calling drop_delayed_ref() against the ref, which can happen during merging or when destroying delayed refs due to a transaction abort, we can trigger a crash since at drop_delayed_ref() we call list_empty() against the ref's add_list, which returns false since the list was not reinitialized after the list_del() and as a consequence we call list_del() again at drop_delayed_ref(). This results in an invalid list access since the next and prev members are set to poison pointers, resulting in a splat if CONFIG_LIST_HARDENED and CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences otherwise. So fix this by deleting from the list with list_del_init() instead.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53064", "url": "https://ubuntu.com/security/CVE-2024-53064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix idpf_vc_core_init error path In an event where the platform running the device control plane is rebooted, reset is detected on the driver. It releases all the resources and waits for the reset to complete. Once the reset is done, it tries to build the resources back. At this time if the device control plane is not yet started, then the driver timeouts on the virtchnl message and retries to establish the mailbox again. In the retry flow, mailbox is deinitialized but the mailbox workqueue is still alive and polling for the mailbox message. This results in accessing the released control queue leading to null-ptr-deref. Fix it by unrolling the work queue cancellation and mailbox deinitialization in the reverse order which they got initialized.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50274", "url": "https://ubuntu.com/security/CVE-2024-50274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: avoid vport access in idpf_get_link_ksettings When the device control plane is removed or the platform running device control plane is rebooted, a reset is detected on the driver. On driver reset, it releases the resources and waits for the reset to complete. If the reset fails, it takes the error path and releases the vport lock. At this time if the monitoring tools tries to access link settings, it call traces for accessing released vport pointer. To avoid it, move link_speed_mbps to netdev_priv structure which removes the dependency on vport pointer and the vport lock in idpf_get_link_ksettings. Also use netif_carrier_ok() to check the link status and adjust the offsetof to use link_up instead of link_speed_mbps.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53065", "url": "https://ubuntu.com/security/CVE-2024-53065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/slab: fix warning caused by duplicate kmem_cache creation in kmem_buckets_create Commit b035f5a6d852 (\"mm: slab: reduce the kmalloc() minimum alignment if DMA bouncing possible\") reduced ARCH_KMALLOC_MINALIGN to 8 on arm64. However, with KASAN_HW_TAGS enabled, arch_slab_minalign() becomes 16. This causes kmalloc_caches[*][8] to be aliased to kmalloc_caches[*][16], resulting in kmem_buckets_create() attempting to create a kmem_cache for size 16 twice. This duplication triggers warnings on boot: [ 2.325108] ------------[ cut here ]------------ [ 2.325135] kmem_cache of name 'memdup_user-16' already exists [ 2.325783] WARNING: CPU: 0 PID: 1 at mm/slab_common.c:107 __kmem_cache_create_args+0xb8/0x3b0 [ 2.327957] Modules linked in: [ 2.328550] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5mm-unstable-arm64+ #12 [ 2.328683] Hardware name: QEMU QEMU Virtual Machine, BIOS 2024.02-2 03/11/2024 [ 2.328790] pstate: 61000009 (nZCv daif -PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 2.328911] pc : __kmem_cache_create_args+0xb8/0x3b0 [ 2.328930] lr : __kmem_cache_create_args+0xb8/0x3b0 [ 2.328942] sp : ffff800083d6fc50 [ 2.328961] x29: ffff800083d6fc50 x28: f2ff0000c1674410 x27: ffff8000820b0598 [ 2.329061] x26: 000000007fffffff x25: 0000000000000010 x24: 0000000000002000 [ 2.329101] x23: ffff800083d6fce8 x22: ffff8000832222e8 x21: ffff800083222388 [ 2.329118] x20: f2ff0000c1674410 x19: f5ff0000c16364c0 x18: ffff800083d80030 [ 2.329135] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 2.329152] x14: 0000000000000000 x13: 0a73747369786520 x12: 79646165726c6120 [ 2.329169] x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : 0000000000000000 [ 2.329194] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 [ 2.329210] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 2.329226] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 2.329291] Call trace: [ 2.329407] __kmem_cache_create_args+0xb8/0x3b0 [ 2.329499] kmem_buckets_create+0xfc/0x320 [ 2.329526] init_user_buckets+0x34/0x78 [ 2.329540] do_one_initcall+0x64/0x3c8 [ 2.329550] kernel_init_freeable+0x26c/0x578 [ 2.329562] kernel_init+0x3c/0x258 [ 2.329574] ret_from_fork+0x10/0x20 [ 2.329698] ---[ end trace 0000000000000000 ]--- [ 2.403704] ------------[ cut here ]------------ [ 2.404716] kmem_cache of name 'msg_msg-16' already exists [ 2.404801] WARNING: CPU: 2 PID: 1 at mm/slab_common.c:107 __kmem_cache_create_args+0xb8/0x3b0 [ 2.404842] Modules linked in: [ 2.404971] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.12.0-rc5mm-unstable-arm64+ #12 [ 2.405026] Tainted: [W]=WARN [ 2.405043] Hardware name: QEMU QEMU Virtual Machine, BIOS 2024.02-2 03/11/2024 [ 2.405057] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2.405079] pc : __kmem_cache_create_args+0xb8/0x3b0 [ 2.405100] lr : __kmem_cache_create_args+0xb8/0x3b0 [ 2.405111] sp : ffff800083d6fc50 [ 2.405115] x29: ffff800083d6fc50 x28: fbff0000c1674410 x27: ffff8000820b0598 [ 2.405135] x26: 000000000000ffd0 x25: 0000000000000010 x24: 0000000000006000 [ 2.405153] x23: ffff800083d6fce8 x22: ffff8000832222e8 x21: ffff800083222388 [ 2.405169] x20: fbff0000c1674410 x19: fdff0000c163d6c0 x18: ffff800083d80030 [ 2.405185] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 2.405201] x14: 0000000000000000 x13: 0a73747369786520 x12: 79646165726c6120 [ 2.405217] x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : 0000000000000000 [ 2.405233] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 [ 2.405248] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 2.405271] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 2.405287] Call trace: [ 2 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50275", "url": "https://ubuntu.com/security/CVE-2024-50275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64/sve: Discard stale CPU state when handling SVE traps The logic for handling SVE traps manipulates saved FPSIMD/SVE state incorrectly, and a race with preemption can result in a task having TIF_SVE set and TIF_FOREIGN_FPSTATE clear even though the live CPU state is stale (e.g. with SVE traps enabled). This has been observed to result in warnings from do_sve_acc() where SVE traps are not expected while TIF_SVE is set: | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* SVE access shouldn't have trapped */ Warnings of this form have been reported intermittently, e.g. https://lore.kernel.org/linux-arm-kernel/CA+G9fYtEGe_DhY2Ms7+L7NKsLYUomGsgqpdBj+QwDLeSg=JhGg@mail.gmail.com/ https://lore.kernel.org/linux-arm-kernel/000000000000511e9a060ce5a45c@google.com/ The race can occur when the SVE trap handler is preempted before and after manipulating the saved FPSIMD/SVE state, starting and ending on the same CPU, e.g. | void do_sve_acc(unsigned long esr, struct pt_regs *regs) | { | // Trap on CPU 0 with TIF_SVE clear, SVE 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(); | | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* SVE access shouldn't have trapped */ | | sve_init_regs() { | if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) { | ... | } else { | fpsimd_to_sve(current); | current->thread.fp_type = FP_STATE_SVE; | } | } | | 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 SVE 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.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50276", "url": "https://ubuntu.com/security/CVE-2024-50276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: vertexcom: mse102x: Fix possible double free of TX skb The scope of the TX skb is wider than just mse102x_tx_frame_spi(), so in case the TX skb room needs to be expanded, we should free the the temporary skb instead of the original skb. Otherwise the original TX skb pointer would be freed again in mse102x_tx_work(), which leads to crashes: Internal error: Oops: 0000000096000004 [#2] PREEMPT SMP CPU: 0 PID: 712 Comm: kworker/0:1 Tainted: G D 6.6.23 Hardware name: chargebyte Charge SOM DC-ONE (DT) Workqueue: events mse102x_tx_work [mse102x] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_release_data+0xb8/0x1d8 lr : skb_release_data+0x1ac/0x1d8 sp : ffff8000819a3cc0 x29: ffff8000819a3cc0 x28: ffff0000046daa60 x27: ffff0000057f2dc0 x26: ffff000005386c00 x25: 0000000000000002 x24: 00000000ffffffff x23: 0000000000000000 x22: 0000000000000001 x21: ffff0000057f2e50 x20: 0000000000000006 x19: 0000000000000000 x18: ffff00003fdacfcc x17: e69ad452d0c49def x16: 84a005feff870102 x15: 0000000000000000 x14: 000000000000024a x13: 0000000000000002 x12: 0000000000000000 x11: 0000000000000400 x10: 0000000000000930 x9 : ffff00003fd913e8 x8 : fffffc00001bc008 x7 : 0000000000000000 x6 : 0000000000000008 x5 : ffff00003fd91340 x4 : 0000000000000000 x3 : 0000000000000009 x2 : 00000000fffffffe x1 : 0000000000000000 x0 : 0000000000000000 Call trace: skb_release_data+0xb8/0x1d8 kfree_skb_reason+0x48/0xb0 mse102x_tx_work+0x164/0x35c [mse102x] process_one_work+0x138/0x260 worker_thread+0x32c/0x438 kthread+0x118/0x11c ret_from_fork+0x10/0x20 Code: aa1303e0 97fffab6 72001c1f 54000141 (f9400660)", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53066", "url": "https://ubuntu.com/security/CVE-2024-53066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfs: Fix KMSAN warning in decode_getfattr_attrs() Fix the following KMSAN warning: CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G B Tainted: [B]=BAD_PAGE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) ===================================================== ===================================================== BUG: KMSAN: uninit-value in decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_generic+0x806/0xb00 nfs4_xdr_dec_getattr+0x1de/0x240 rpcauth_unwrap_resp_decode+0xab/0x100 rpcauth_unwrap_resp+0x95/0xc0 call_decode+0x4ff/0xb50 __rpc_execute+0x57b/0x19d0 rpc_execute+0x368/0x5e0 rpc_run_task+0xcfe/0xee0 nfs4_proc_getattr+0x5b5/0x990 __nfs_revalidate_inode+0x477/0xd00 nfs_access_get_cached+0x1021/0x1cc0 nfs_do_access+0x9f/0xae0 nfs_permission+0x1e4/0x8c0 inode_permission+0x356/0x6c0 link_path_walk+0x958/0x1330 path_lookupat+0xce/0x6b0 filename_lookup+0x23e/0x770 vfs_statx+0xe7/0x970 vfs_fstatat+0x1f2/0x2c0 __se_sys_newfstatat+0x67/0x880 __x64_sys_newfstatat+0xbd/0x120 x64_sys_call+0x1826/0x3cf0 do_syscall_64+0xd0/0x1b0 entry_SYSCALL_64_after_hwframe+0x77/0x7f The KMSAN warning is triggered in decode_getfattr_attrs(), when calling decode_attr_mdsthreshold(). It appears that fattr->mdsthreshold is not initialized. Fix the issue by initializing fattr->mdsthreshold to NULL in nfs_fattr_init().", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53067", "url": "https://ubuntu.com/security/CVE-2024-53067", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Start the RTC update work later The RTC update work involves runtime resuming the UFS controller. Hence, only start the RTC update work after runtime power management in the UFS driver has been fully initialized. This patch fixes the following kernel crash: Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP Workqueue: events ufshcd_rtc_work Call trace: _raw_spin_lock_irqsave+0x34/0x8c (P) pm_runtime_get_if_active+0x24/0x9c (L) pm_runtime_get_if_active+0x24/0x9c ufshcd_rtc_work+0x138/0x1b4 process_one_work+0x148/0x288 worker_thread+0x2cc/0x3d4 kthread+0x110/0x114 ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50277", "url": "https://ubuntu.com/security/CVE-2024-50277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: fix a crash if blk_alloc_disk fails If blk_alloc_disk fails, the variable md->disk is set to an error value. cleanup_mapped_device will see that md->disk is non-NULL and it will attempt to access it, causing a crash on this statement \"md->disk->private_data = NULL;\".", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50278", "url": "https://ubuntu.com/security/CVE-2024-50278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix potential out-of-bounds access on the first resume Out-of-bounds access occurs if the fast device is expanded unexpectedly before the first-time resume of the cache table. This happens because expanding the fast device requires reloading the cache table for cache_create to allocate new in-core data structures that fit the new size, and the check in cache_preresume is not performed during the first resume, leading to the issue. Reproduce steps: 1. prepare component devices: 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\" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct 2. load a cache table of 512 cache blocks, and deliberately expand the fast device before resuming the cache, making the in-core data structures inadequate. dmsetup create cache --notable dmsetup reload cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" dmsetup reload cdata --table \"0 131072 linear /dev/sdc 8192\" dmsetup resume cdata dmsetup resume cache 3. suspend the cache to write out the in-core dirty bitset and hint array, leading to out-of-bounds access to the dirty bitset at offset 0x40: dmsetup suspend cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80 Read of size 8 at addr ffffc90000085040 by task dmsetup/90 (...snip...) The buggy address belongs to the virtual mapping at [ffffc90000085000, ffffc90000087000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by checking the size change on the first resume.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50279", "url": "https://ubuntu.com/security/CVE-2024-50279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix out-of-bounds access to the dirty bitset when resizing dm-cache checks the dirty bits of the cache blocks to be dropped when shrinking the fast device, but an index bug in bitset iteration causes out-of-bounds access. Reproduce steps: 1. create a cache device of 1024 cache blocks (128 bytes dirty bitset) dmsetup create cmeta --table \"0 8192 linear /dev/sdc 0\" dmsetup create cdata --table \"0 131072 linear /dev/sdc 8192\" dmsetup create corig --table \"0 524288 linear /dev/sdc 262144\" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" 2. shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80) dmsetup suspend cache dmsetup reload cdata --table \"0 65536 linear /dev/sdc 8192\" dmsetup resume cdata dmsetup resume cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131 (...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by making the index post-incremented.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50280", "url": "https://ubuntu.com/security/CVE-2024-50280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix flushing uninitialized delayed_work on cache_ctr error An unexpected WARN_ON from flush_work() may occur when cache creation fails, caused by destroying the uninitialized delayed_work waker in the error path of cache_create(). For example, the warning appears on the superblock checksum error. Reproduce steps: 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\" dd if=/dev/urandom of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" Kernel logs: (snip) WARNING: CPU: 0 PID: 84 at kernel/workqueue.c:4178 __flush_work+0x5d4/0x890 Fix by pulling out the cancel_delayed_work_sync() from the constructor's error path. This patch doesn't affect the use-after-free fix for concurrent dm_resume and dm_destroy (commit 6a459d8edbdb (\"dm cache: Fix UAF in destroy()\")) as cache_dtr is not changed.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50281", "url": "https://ubuntu.com/security/CVE-2024-50281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: trusted: dcp: fix NULL dereference in AEAD crypto operation When sealing or unsealing a key blob we currently do not wait for the AEAD cipher operation to finish and simply return after submitting the request. If there is some load on the system we can exit before the cipher operation is done and the buffer we read from/write to is already removed from the stack. This will e.g. result in NULL pointer dereference errors in the DCP driver during blob creation. Fix this by waiting for the AEAD cipher operation to finish before resuming the seal and unseal calls.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50282", "url": "https://ubuntu.com/security/CVE-2024-50282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read() Avoid a possible buffer overflow if size is larger than 4K. (cherry picked from commit f5d873f5825b40d886d03bd2aede91d4cf002434)", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53071", "url": "https://ubuntu.com/security/CVE-2024-53071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Be stricter about IO mapping flags The current panthor_device_mmap_io() implementation has two issues: 1. For mapping DRM_PANTHOR_USER_FLUSH_ID_MMIO_OFFSET, panthor_device_mmap_io() bails if VM_WRITE is set, but does not clear VM_MAYWRITE. That means userspace can use mprotect() to make the mapping writable later on. This is a classic Linux driver gotcha. I don't think this actually has any impact in practice: When the GPU is powered, writes to the FLUSH_ID seem to be ignored; and when the GPU is not powered, the dummy_latest_flush page provided by the driver is deliberately designed to not do any flushes, so the only thing writing to the dummy_latest_flush could achieve would be to make *more* flushes happen. 2. panthor_device_mmap_io() does not block MAP_PRIVATE mappings (which are mappings without the VM_SHARED flag). MAP_PRIVATE in combination with VM_MAYWRITE indicates that the VMA has copy-on-write semantics, which for VM_PFNMAP are semi-supported but fairly cursed. In particular, in such a mapping, the driver can only install PTEs during mmap() by calling remap_pfn_range() (because remap_pfn_range() wants to **store the physical address of the mapped physical memory into the vm_pgoff of the VMA**); installing PTEs later on with a fault handler (as panthor does) is not supported in private mappings, and so if you try to fault in such a mapping, vmf_insert_pfn_prot() splats when it hits a BUG() check. Fix it by clearing the VM_MAYWRITE flag (userspace writing to the FLUSH_ID doesn't make sense) and requiring VM_SHARED (copy-on-write semantics for the FLUSH_ID don't make sense). Reproducers for both scenarios are in the notes of my patch on the mailing list; I tested that these bugs exist on a Rock 5B machine. Note that I only compile-tested the patch, I haven't tested it; I don't have a working kernel build setup for the test machine yet. Please test it before applying it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53080", "url": "https://ubuntu.com/security/CVE-2024-53080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Lock XArray when getting entries for the VM Similar to commit cac075706f29 (\"drm/panthor: Fix race when converting group handle to group object\") we need to use the XArray's internal locking when retrieving a vm pointer from there. v2: Removed part of the patch that was trying to protect fetching the heap pointer from XArray, as that operation is protected by the @pool->lock.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53084", "url": "https://ubuntu.com/security/CVE-2024-53084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Break an object reference loop When remaining resources are being cleaned up on driver close, outstanding VM mappings may result in resources being leaked, due to an object reference loop, as shown below, with each object (or set of objects) referencing the object below it: PVR GEM Object GPU scheduler \"finished\" fence GPU scheduler “scheduled” fence PVR driver “done” fence PVR Context PVR VM Context PVR VM Mappings PVR GEM Object The reference that the PVR VM Context has on the VM mappings is a soft one, in the sense that the freeing of outstanding VM mappings is done as part of VM context destruction; no reference counts are involved, as is the case for all the other references in the loop. To break the reference loop during cleanup, free the outstanding VM mappings before destroying the PVR Context associated with the VM context.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53085", "url": "https://ubuntu.com/security/CVE-2024-53085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: Lock TPM chip in tpm_pm_suspend() first Setting TPM_CHIP_FLAG_SUSPENDED in the end of tpm_pm_suspend() can be racy according, as this leaves window for tpm_hwrng_read() to be called while the operation is in progress. The recent bug report gives also evidence of this behaviour. Aadress this by locking the TPM chip before checking any chip->flags both in tpm_pm_suspend() and tpm_hwrng_read(). Move TPM_CHIP_FLAG_SUSPENDED check inside tpm_get_random() so that it will be always checked only when the lock is reserved.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53086", "url": "https://ubuntu.com/security/CVE-2024-53086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Drop VM dma-resv lock on xe_sync_in_fence_get failure in exec IOCTL Upon failure all locks need to be dropped before returning to the user. (cherry picked from commit 7d1a4258e602ffdce529f56686925034c1b3b095)", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53087", "url": "https://ubuntu.com/security/CVE-2024-53087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix possible exec queue leak in exec IOCTL In a couple of places after an exec queue is looked up the exec IOCTL returns on input errors without dropping the exec queue ref. Fix this ensuring the exec queue ref is dropped on input error. (cherry picked from commit 07064a200b40ac2195cb6b7b779897d9377e5e6f)", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50283", "url": "https://ubuntu.com/security/CVE-2024-50283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-use-after-free in smb3_preauth_hash_rsp ksmbd_user_session_put should be called under smb3_preauth_hash_rsp(). It will avoid freeing session before calling smb3_preauth_hash_rsp().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50284", "url": "https://ubuntu.com/security/CVE-2024-50284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix the missing xa_store error check xa_store() can fail, it return xa_err(-EINVAL) if the entry cannot be stored in an XArray, or xa_err(-ENOMEM) if memory allocation failed, so check error for xa_store() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50285", "url": "https://ubuntu.com/security/CVE-2024-50285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: check outstanding simultaneous SMB operations If Client send simultaneous SMB operations to ksmbd, It exhausts too much memory through the \"ksmbd_work_cache”. It will cause OOM issue. ksmbd has a credit mechanism but it can't handle this problem. This patch add the check if it exceeds max credits to prevent this problem by assuming that one smb request consumes at least one credit.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50286", "url": "https://ubuntu.com/security/CVE-2024-50286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-use-after-free in ksmbd_smb2_session_create There is a race condition between ksmbd_smb2_session_create and ksmbd_expire_session. This patch add missing sessions_table_lock while adding/deleting session from global session table.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50287", "url": "https://ubuntu.com/security/CVE-2024-50287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-tpg: prevent the risk of a division by zero As reported by Coverity, the logic at tpg_precalculate_line() blindly rescales the buffer even when scaled_witdh is equal to zero. If this ever happens, this will cause a division by zero. Instead, add a WARN_ON_ONCE() to trigger such cases and return without doing any precalculation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50288", "url": "https://ubuntu.com/security/CVE-2024-50288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: fix buffer overwrite when using > 32 buffers The maximum number of buffers that can be requested was increased to 64 for the video capture queue. But video capture used a must_blank array that was still sized for 32 (VIDEO_MAX_FRAME). This caused an out-of-bounds write when using buffer indices >= 32. Create a new define MAX_VID_CAP_BUFFERS that is used to access the must_blank array and set max_num_buffers for the video capture queue. This solves a crash reported by: \thttps://bugzilla.kernel.org/show_bug.cgi?id=219258", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50289", "url": "https://ubuntu.com/security/CVE-2024-50289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: av7110: fix a spectre vulnerability As warned by smatch: \tdrivers/staging/media/av7110/av7110_ca.c:270 dvb_ca_ioctl() warn: potential spectre issue 'av7110->ci_slot' [w] (local cap) There is a spectre-related vulnerability at the code. Fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50290", "url": "https://ubuntu.com/security/CVE-2024-50290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx24116: prevent overflows on SNR calculus as reported by Coverity, if reading SNR registers fail, a negative number will be returned, causing an underflow when reading SNR registers. Prevent that.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53061", "url": "https://ubuntu.com/security/CVE-2024-53061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: s5p-jpeg: prevent buffer overflows The current logic allows word to be less than 2. If this happens, there will be buffer overflows, as reported by smatch. Add extra checks to prevent it. While here, remove an unused word = 0 assignment.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53081", "url": "https://ubuntu.com/security/CVE-2024-53081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ar0521: don't overflow when checking PLL values The PLL checks are comparing 64 bit integers with 32 bit ones, as reported by Coverity. Depending on the values of the variables, this may underflow. Fix it ensuring that both sides of the expression are u64.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53062", "url": "https://ubuntu.com/security/CVE-2024-53062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mgb4: protect driver against spectre Frequency range is set from sysfs via frequency_range_store(), being vulnerable to spectre, as reported by smatch: \tdrivers/media/pci/mgb4/mgb4_cmt.c:231 mgb4_cmt_set_vin_freq_range() warn: potential spectre issue 'cmt_vals_in' [r] \tdrivers/media/pci/mgb4/mgb4_cmt.c:238 mgb4_cmt_set_vin_freq_range() warn: possible spectre second half. 'reg_set' Fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50291", "url": "https://ubuntu.com/security/CVE-2024-50291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvb-core: add missing buffer index check dvb_vb2_expbuf() didn't check if the given buffer index was for a valid buffer. Add this check.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50292", "url": "https://ubuntu.com/security/CVE-2024-50292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: stm32: spdifrx: fix dma channel release in stm32_spdifrx_remove In case of error when requesting ctrl_chan DMA channel, ctrl_chan is not null. So the release of the dma channel leads to the following issue: [ 4.879000] st,stm32-spdifrx 500d0000.audio-controller: dma_request_slave_channel error -19 [ 4.888975] Unable to handle kernel NULL pointer dereference at virtual address 000000000000003d [...] [ 5.096577] Call trace: [ 5.099099] dma_release_channel+0x24/0x100 [ 5.103235] stm32_spdifrx_remove+0x24/0x60 [snd_soc_stm32_spdifrx] [ 5.109494] stm32_spdifrx_probe+0x320/0x4c4 [snd_soc_stm32_spdifrx] To avoid this issue, release channel only if the pointer is valid.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53063", "url": "https://ubuntu.com/security/CVE-2024-53063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvbdev: prevent the risk of out of memory access The dvbdev contains a static variable used to store dvb minors. The behavior of it depends if CONFIG_DVB_DYNAMIC_MINORS is set or not. When not set, dvb_register_device() won't check for boundaries, as it will rely that a previous call to dvb_register_adapter() would already be enforcing it. On a similar way, dvb_device_open() uses the assumption that the register functions already did the needed checks. This can be fragile if some device ends using different calls. This also generate warnings on static check analysers like Coverity. So, add explicit guards to prevent potential risk of OOM issues.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50293", "url": "https://ubuntu.com/security/CVE-2024-50293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: do not leave a dangling sk pointer in __smc_create() Thanks to commit 4bbd360a5084 (\"socket: Print pf->create() when it does not clear sock->sk on failure.\"), syzbot found an issue with AF_SMC: smc_create must clear sock->sk on failure, family: 43, type: 1, protocol: 0 WARNING: CPU: 0 PID: 5827 at net/socket.c:1565 __sock_create+0x96f/0xa30 net/socket.c:1563 Modules linked in: CPU: 0 UID: 0 PID: 5827 Comm: syz-executor259 Not tainted 6.12.0-rc6-next-20241106-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:__sock_create+0x96f/0xa30 net/socket.c:1563 Code: 03 00 74 08 4c 89 e7 e8 4f 3b 85 f8 49 8b 34 24 48 c7 c7 40 89 0c 8d 8b 54 24 04 8b 4c 24 0c 44 8b 44 24 08 e8 32 78 db f7 90 <0f> 0b 90 90 e9 d3 fd ff ff 89 e9 80 e1 07 fe c1 38 c1 0f 8c ee f7 RSP: 0018:ffffc90003e4fda0 EFLAGS: 00010246 RAX: 099c6f938c7f4700 RBX: 1ffffffff1a595fd RCX: ffff888034823c00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 00000000ffffffe9 R08: ffffffff81567052 R09: 1ffff920007c9f50 R10: dffffc0000000000 R11: fffff520007c9f51 R12: ffffffff8d2cafe8 R13: 1ffffffff1a595fe R14: ffffffff9a789c40 R15: ffff8880764298c0 FS: 000055557b518380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa62ff43225 CR3: 0000000031628000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: sock_create net/socket.c:1616 [inline] __sys_socket_create net/socket.c:1653 [inline] __sys_socket+0x150/0x3c0 net/socket.c:1700 __do_sys_socket net/socket.c:1714 [inline] __se_sys_socket net/socket.c:1712 [inline] For reference, see commit 2d859aff775d (\"Merge branch 'do-not-leave-dangling-sk-pointers-in-pf-create-functions'\")", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50294", "url": "https://ubuntu.com/security/CVE-2024-50294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix missing locking causing hanging calls If a call gets aborted (e.g. because kafs saw a signal) between it being queued for connection and the I/O thread picking up the call, the abort will be prioritised over the connection and it will be removed from local->new_client_calls by rxrpc_disconnect_client_call() without a lock being held. This may cause other calls on the list to disappear if a race occurs. Fix this by taking the client_call_lock when removing a call from whatever list its ->wait_link happens to be on.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50295", "url": "https://ubuntu.com/security/CVE-2024-50295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: arc: fix the device for dma_map_single/dma_unmap_single The ndev->dev and pdev->dev aren't the same device, use ndev->dev.parent which has dma_mask, ndev->dev.parent is just pdev->dev. Or it would cause the following issue: [ 39.933526] ------------[ cut here ]------------ [ 39.938414] WARNING: CPU: 1 PID: 501 at kernel/dma/mapping.c:149 dma_map_page_attrs+0x90/0x1f8", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53082", "url": "https://ubuntu.com/security/CVE-2024-53082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_net: Add hash_key_length check Add hash_key_length check in virtnet_probe() to avoid possible out of bound errors when setting/reading the hash key.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50296", "url": "https://ubuntu.com/security/CVE-2024-50296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash when uninstalling driver When the driver is uninstalled and the VF is disabled concurrently, a kernel crash occurs. The reason is that the two actions call function pci_disable_sriov(). The num_VFs is checked to determine whether to release the corresponding resources. During the second calling, num_VFs is not 0 and the resource release function is called. However, the corresponding resource has been released during the first invoking. Therefore, the problem occurs: [15277.839633][T50670] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ... [15278.131557][T50670] Call trace: [15278.134686][T50670] klist_put+0x28/0x12c [15278.138682][T50670] klist_del+0x14/0x20 [15278.142592][T50670] device_del+0xbc/0x3c0 [15278.146676][T50670] pci_remove_bus_device+0x84/0x120 [15278.151714][T50670] pci_stop_and_remove_bus_device+0x6c/0x80 [15278.157447][T50670] pci_iov_remove_virtfn+0xb4/0x12c [15278.162485][T50670] sriov_disable+0x50/0x11c [15278.166829][T50670] pci_disable_sriov+0x24/0x30 [15278.171433][T50670] hnae3_unregister_ae_algo_prepare+0x60/0x90 [hnae3] [15278.178039][T50670] hclge_exit+0x28/0xd0 [hclge] [15278.182730][T50670] __se_sys_delete_module.isra.0+0x164/0x230 [15278.188550][T50670] __arm64_sys_delete_module+0x1c/0x30 [15278.193848][T50670] invoke_syscall+0x50/0x11c [15278.198278][T50670] el0_svc_common.constprop.0+0x158/0x164 [15278.203837][T50670] do_el0_svc+0x34/0xcc [15278.207834][T50670] el0_svc+0x20/0x30 For details, see the following figure. rmmod hclge disable VFs ---------------------------------------------------- hclge_exit() sriov_numvfs_store() ... device_lock() pci_disable_sriov() hns3_pci_sriov_configure() pci_disable_sriov() sriov_disable() sriov_disable() if !num_VFs : if !num_VFs : return; return; sriov_del_vfs() sriov_del_vfs() ... ... klist_put() klist_put() ... ... num_VFs = 0; num_VFs = 0; device_unlock(); In this patch, when driver is removing, we get the device_lock() to protect num_VFs, just like sriov_numvfs_store().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53088", "url": "https://ubuntu.com/security/CVE-2024-53088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: fix race condition by adding filter's intermediate sync state Fix a race condition in the i40e driver that leads to MAC/VLAN filters becoming corrupted and leaking. Address the issue that occurs under heavy load when multiple threads are concurrently modifying MAC/VLAN filters by setting mac and port VLAN. 1. Thread T0 allocates a filter in i40e_add_filter() within i40e_ndo_set_vf_port_vlan(). 2. Thread T1 concurrently frees the filter in __i40e_del_filter() within i40e_ndo_set_vf_mac(). 3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which refers to the already freed filter memory, causing corruption. Reproduction steps: 1. Spawn multiple VFs. 2. Apply a concurrent heavy load by running parallel operations to change MAC addresses on the VFs and change port VLANs on the host. 3. Observe errors in dmesg: \"Error I40E_AQ_RC_ENOSPC adding RX filters on VF XX, \tplease set promiscuous on manually for VF XX\". Exact code for stable reproduction Intel can't open-source now. The fix involves implementing a new intermediate filter state, I40E_FILTER_NEW_SYNC, for the time when a filter is on a tmp_add_list. These filters cannot be deleted from the hash list directly but must be removed using the full process.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50297", "url": "https://ubuntu.com/security/CVE-2024-50297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: xilinx: axienet: Enqueue Tx packets in dql before dmaengine starts Enqueue packets in dql after dma engine starts causes race condition. Tx transfer starts once dma engine is started and may execute dql dequeue in completion before it gets queued. It results in following kernel crash while running iperf stress test: kernel BUG at lib/dynamic_queue_limits.c:99! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP pc : dql_completed+0x238/0x248 lr : dql_completed+0x3c/0x248 Call trace: dql_completed+0x238/0x248 axienet_dma_tx_cb+0xa0/0x170 xilinx_dma_do_tasklet+0xdc/0x290 tasklet_action_common+0xf8/0x11c tasklet_action+0x30/0x3c handle_softirqs+0xf8/0x230 Start dmaengine after enqueue in dql fixes the crash.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50298", "url": "https://ubuntu.com/security/CVE-2024-50298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: enetc: allocate vf_state during PF probes In the previous implementation, vf_state is allocated memory only when VF is enabled. However, net_device_ops::ndo_set_vf_mac() may be called before VF is enabled to configure the MAC address of VF. If this is the case, enetc_pf_set_vf_mac() will access vf_state, resulting in access to a null pointer. The simplified error log is as follows. root@ls1028ardb:~# ip link set eno0 vf 1 mac 00:0c:e7:66:77:89 [ 173.543315] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 [ 173.637254] pc : enetc_pf_set_vf_mac+0x3c/0x80 Message from sy [ 173.641973] lr : do_setlink+0x4a8/0xec8 [ 173.732292] Call trace: [ 173.734740] enetc_pf_set_vf_mac+0x3c/0x80 [ 173.738847] __rtnl_newlink+0x530/0x89c [ 173.742692] rtnl_newlink+0x50/0x7c [ 173.746189] rtnetlink_rcv_msg+0x128/0x390 [ 173.750298] netlink_rcv_skb+0x60/0x130 [ 173.754145] rtnetlink_rcv+0x18/0x24 [ 173.757731] netlink_unicast+0x318/0x380 [ 173.761665] netlink_sendmsg+0x17c/0x3c8", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50299", "url": "https://ubuntu.com/security/CVE-2024-50299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: properly validate chunk size in sctp_sf_ootb() A size validation fix similar to that in Commit 50619dbf8db7 (\"sctp: add size validation when walking chunks\") is also required in sctp_sf_ootb() to address a crash reported by syzbot: BUG: KMSAN: uninit-value in sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_do_sm+0x181/0x93d0 net/sctp/sm_sideeffect.c:1166 sctp_endpoint_bh_rcv+0xc38/0xf90 net/sctp/endpointola.c:407 sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88 sctp_rcv+0x3831/0x3b20 net/sctp/input.c:243 sctp4_rcv+0x42/0x50 net/sctp/protocol.c:1159 ip_protocol_deliver_rcu+0xb51/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50300", "url": "https://ubuntu.com/security/CVE-2024-50300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: rtq2208: Fix uninitialized use of regulator_config Fix rtq2208 driver uninitialized use to cause kernel error.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50301", "url": "https://ubuntu.com/security/CVE-2024-50301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: security/keys: fix slab-out-of-bounds in key_task_permission KASAN reports an out of bounds read: BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline] BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362 CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0x107/0x167 lib/dump_stack.c:123 print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 __kuid_val include/linux/uidgid.h:36 [inline] uid_eq include/linux/uidgid.h:63 [inline] key_task_permission+0x394/0x410 security/keys/permission.c:54 search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793 This issue was also reported by syzbot. It can be reproduced by following these steps(more details [1]): 1. Obtain more than 32 inputs that have similar hashes, which ends with the pattern '0xxxxxxxe6'. 2. Reboot and add the keys obtained in step 1. The reproducer demonstrates how this issue happened: 1. In the search_nested_keyrings function, when it iterates through the slots in a node(below tag ascend_to_node), if the slot pointer is meta and node->back_pointer != NULL(it means a root), it will proceed to descend_to_node. However, there is an exception. If node is the root, and one of the slots points to a shortcut, it will be treated as a keyring. 2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function. However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as ASSOC_ARRAY_PTR_SUBTYPE_MASK. 3. When 32 keys with the similar hashes are added to the tree, the ROOT has keys with hashes that are not similar (e.g. slot 0) and it splits NODE A without using a shortcut. When NODE A is filled with keys that all hashes are xxe6, the keys are similar, NODE A will split with a shortcut. Finally, it forms the tree as shown below, where slot 6 points to a shortcut. NODE A +------>+---+ ROOT | | 0 | xxe6 +---+ | +---+ xxxx | 0 | shortcut : : xxe6 +---+ | +---+ xxe6 : : | | | xxe6 +---+ | +---+ | 6 |---+ : : xxe6 +---+ +---+ xxe6 : : | f | xxe6 +---+ +---+ xxe6 | f | +---+ 4. As mentioned above, If a slot(slot 6) of the root points to a shortcut, it may be mistakenly transferred to a key*, leading to a read out-of-bounds read. To fix this issue, one should jump to descend_to_node if the ptr is a shortcut, regardless of whether the node is root or not. [1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/ [jarkko: tweaked the commit message a bit to have an appropriate closes tag.]", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53072", "url": "https://ubuntu.com/security/CVE-2024-53072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/pmc: Detect when STB is not available Loading the amd_pmc module as: amd_pmc enable_stb=1 ...can result in the following messages in the kernel ring buffer: amd_pmc AMDI0009:00: SMU cmd failed. err: 0xff ioremap on RAM at 0x0000000000000000 - 0x0000000000ffffff WARNING: CPU: 10 PID: 2151 at arch/x86/mm/ioremap.c:217 __ioremap_caller+0x2cd/0x340 Further debugging reveals that this occurs when the requests for S2D_PHYS_ADDR_LOW and S2D_PHYS_ADDR_HIGH return a value of 0, indicating that the STB is inaccessible. To prevent the ioremap warning and provide clarity to the user, handle the invalid address and display an error message.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50302", "url": "https://ubuntu.com/security/CVE-2024-50302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: zero-initialize the report buffer Since the report buffer is used by all kinds of drivers in various ways, let's zero-initialize it during allocation to make sure that it can't be ever used to leak kernel memory via specially-crafted report.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53068", "url": "https://ubuntu.com/security/CVE-2024-53068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix slab-use-after-free in scmi_bus_notifier() The scmi_dev->name is released prematurely in __scmi_device_destroy(), which causes slab-use-after-free when accessing scmi_dev->name in scmi_bus_notifier(). So move the release of scmi_dev->name to scmi_device_release() to avoid slab-use-after-free. | BUG: KASAN: slab-use-after-free in strncmp+0xe4/0xec | Read of size 1 at addr ffffff80a482bcc0 by task swapper/0/1 | | CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.6.38-debug #1 | Hardware name: Qualcomm Technologies, Inc. SA8775P Ride (DT) | Call trace: | dump_backtrace+0x94/0x114 | show_stack+0x18/0x24 | dump_stack_lvl+0x48/0x60 | print_report+0xf4/0x5b0 | kasan_report+0xa4/0xec | __asan_report_load1_noabort+0x20/0x2c | strncmp+0xe4/0xec | scmi_bus_notifier+0x5c/0x54c | notifier_call_chain+0xb4/0x31c | blocking_notifier_call_chain+0x68/0x9c | bus_notify+0x54/0x78 | device_del+0x1bc/0x840 | device_unregister+0x20/0xb4 | __scmi_device_destroy+0xac/0x280 | scmi_device_destroy+0x94/0xd0 | scmi_chan_setup+0x524/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20 | | Allocated by task 1: | kasan_save_stack+0x2c/0x54 | kasan_set_track+0x2c/0x40 | kasan_save_alloc_info+0x24/0x34 | __kasan_kmalloc+0xa0/0xb8 | __kmalloc_node_track_caller+0x6c/0x104 | kstrdup+0x48/0x84 | kstrdup_const+0x34/0x40 | __scmi_device_create.part.0+0x8c/0x408 | scmi_device_create+0x104/0x370 | scmi_chan_setup+0x2a0/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20 | | Freed by task 1: | kasan_save_stack+0x2c/0x54 | kasan_set_track+0x2c/0x40 | kasan_save_free_info+0x38/0x5c | __kasan_slab_free+0xe8/0x164 | __kmem_cache_free+0x11c/0x230 | kfree+0x70/0x130 | kfree_const+0x20/0x40 | __scmi_device_destroy+0x70/0x280 | scmi_device_destroy+0x94/0xd0 | scmi_chan_setup+0x524/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53069", "url": "https://ubuntu.com/security/CVE-2024-53069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: qcom: scm: fix a NULL-pointer dereference Some SCM calls can be invoked with __scm being NULL (the driver may not have been and will not be probed as there's no SCM entry in device-tree). Make sure we don't dereference a NULL pointer.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50212", "url": "https://ubuntu.com/security/CVE-2024-50212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib: alloc_tag_module_unload must wait for pending kfree_rcu calls Ben Greear reports following splat: ------------[ cut here ]------------ net/netfilter/nf_nat_core.c:1114 module nf_nat func:nf_nat_register_fn has 256 allocated at module unload WARNING: CPU: 1 PID: 10421 at lib/alloc_tag.c:168 alloc_tag_module_unload+0x22b/0x3f0 Modules linked in: nf_nat(-) btrfs ufs qnx4 hfsplus hfs minix vfat msdos fat ... Hardware name: Default string Default string/SKYBAY, BIOS 5.12 08/04/2020 RIP: 0010:alloc_tag_module_unload+0x22b/0x3f0 codetag_unload_module+0x19b/0x2a0 ? codetag_load_module+0x80/0x80 nf_nat module exit calls kfree_rcu on those addresses, but the free operation is likely still pending by the time alloc_tag checks for leaks. Wait for outstanding kfree_rcu operations to complete before checking resolves this warning. Reproducer: unshare -n iptables-nft -t nat -A PREROUTING -p tcp grep nf_nat /proc/allocinfo # will list 4 allocations rmmod nft_chain_nat rmmod nf_nat # will WARN. [akpm@linux-foundation.org: add comment]", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53046", "url": "https://ubuntu.com/security/CVE-2024-53046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: dts: imx8ulp: correct the flexspi compatible string The flexspi on imx8ulp only has 16 LUTs, and imx8mm flexspi has 32 LUTs, so correct the compatible string here, otherwise will meet below error: [ 1.119072] ------------[ cut here ]------------ [ 1.123926] WARNING: CPU: 0 PID: 1 at drivers/spi/spi-nxp-fspi.c:855 nxp_fspi_exec_op+0xb04/0xb64 [ 1.133239] Modules linked in: [ 1.136448] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-rc6-next-20240902-00001-g131bf9439dd9 #69 [ 1.146821] Hardware name: NXP i.MX8ULP EVK (DT) [ 1.151647] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.158931] pc : nxp_fspi_exec_op+0xb04/0xb64 [ 1.163496] lr : nxp_fspi_exec_op+0xa34/0xb64 [ 1.168060] sp : ffff80008002b2a0 [ 1.171526] x29: ffff80008002b2d0 x28: 0000000000000000 x27: 0000000000000000 [ 1.179002] x26: ffff2eb645542580 x25: ffff800080610014 x24: ffff800080610000 [ 1.186480] x23: ffff2eb645548080 x22: 0000000000000006 x21: ffff2eb6455425e0 [ 1.193956] x20: 0000000000000000 x19: ffff80008002b5e0 x18: ffffffffffffffff [ 1.201432] x17: ffff2eb644467508 x16: 0000000000000138 x15: 0000000000000002 [ 1.208907] x14: 0000000000000000 x13: ffff2eb6400d8080 x12: 00000000ffffff00 [ 1.216378] x11: 0000000000000000 x10: ffff2eb6400d8080 x9 : ffff2eb697adca80 [ 1.223850] x8 : ffff2eb697ad3cc0 x7 : 0000000100000000 x6 : 0000000000000001 [ 1.231324] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000007a6 [ 1.238795] x2 : 0000000000000000 x1 : 00000000000001ce x0 : 00000000ffffff92 [ 1.246267] Call trace: [ 1.248824] nxp_fspi_exec_op+0xb04/0xb64 [ 1.253031] spi_mem_exec_op+0x3a0/0x430 [ 1.257139] spi_nor_read_id+0x80/0xcc [ 1.261065] spi_nor_scan+0x1ec/0xf10 [ 1.264901] spi_nor_probe+0x108/0x2fc [ 1.268828] spi_mem_probe+0x6c/0xbc [ 1.272574] spi_probe+0x84/0xe4 [ 1.275958] really_probe+0xbc/0x29c [ 1.279713] __driver_probe_device+0x78/0x12c [ 1.284277] driver_probe_device+0xd8/0x15c [ 1.288660] __device_attach_driver+0xb8/0x134 [ 1.293316] bus_for_each_drv+0x88/0xe8 [ 1.297337] __device_attach+0xa0/0x190 [ 1.301353] device_initial_probe+0x14/0x20 [ 1.305734] bus_probe_device+0xac/0xb0 [ 1.309752] device_add+0x5d0/0x790 [ 1.313408] __spi_add_device+0x134/0x204 [ 1.317606] of_register_spi_device+0x3b4/0x590 [ 1.322348] spi_register_controller+0x47c/0x754 [ 1.327181] devm_spi_register_controller+0x4c/0xa4 [ 1.332289] nxp_fspi_probe+0x1cc/0x2b0 [ 1.336307] platform_probe+0x68/0xc4 [ 1.340145] really_probe+0xbc/0x29c [ 1.343893] __driver_probe_device+0x78/0x12c [ 1.348457] driver_probe_device+0xd8/0x15c [ 1.352838] __driver_attach+0x90/0x19c [ 1.356857] bus_for_each_dev+0x7c/0xdc [ 1.360877] driver_attach+0x24/0x30 [ 1.364624] bus_add_driver+0xe4/0x208 [ 1.368552] driver_register+0x5c/0x124 [ 1.372573] __platform_driver_register+0x28/0x34 [ 1.377497] nxp_fspi_driver_init+0x1c/0x28 [ 1.381888] do_one_initcall+0x80/0x1c8 [ 1.385908] kernel_init_freeable+0x1c4/0x28c [ 1.390472] kernel_init+0x20/0x1d8 [ 1.394138] ret_from_fork+0x10/0x20 [ 1.397885] ---[ end trace 0000000000000000 ]--- [ 1.407908] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53052", "url": "https://ubuntu.com/security/CVE-2024-53052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/rw: fix missing NOWAIT check for O_DIRECT start write When io_uring starts a write, it'll call kiocb_start_write() to bump the super block rwsem, preventing any freezes from happening while that write is in-flight. The freeze side will grab that rwsem for writing, excluding any new writers from happening and waiting for existing writes to finish. But io_uring unconditionally uses kiocb_start_write(), which will block if someone is currently attempting to freeze the mount point. This causes a deadlock where freeze is waiting for previous writes to complete, but the previous writes cannot complete, as the task that is supposed to complete them is blocked waiting on starting a new write. This results in the following stuck trace showing that dependency with the write blocked starting a new write: task:fio state:D stack:0 pid:886 tgid:886 ppid:876 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_rwsem_wait+0x1e8/0x3f8 __percpu_down_read+0xe8/0x500 io_write+0xbb8/0xff8 io_issue_sqe+0x10c/0x1020 io_submit_sqes+0x614/0x2110 __arm64_sys_io_uring_enter+0x524/0x1038 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 INFO: task fsfreeze:7364 blocked for more than 15 seconds. Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963 with the attempting freezer stuck trying to grab the rwsem: task:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_down_write+0x2b0/0x680 freeze_super+0x248/0x8a8 do_vfs_ioctl+0x149c/0x1b18 __arm64_sys_ioctl+0xd0/0x1a0 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 Fix this by having the io_uring side honor IOCB_NOWAIT, and only attempt a blocking grab of the super block rwsem if it isn't set. For normal issue where IOCB_NOWAIT would always be set, this returns -EAGAIN which will have io_uring core issue a blocking attempt of the write. That will in turn also get completions run, ensuring forward progress. Since freezing requires CAP_SYS_ADMIN in the first place, this isn't something that can be triggered by a regular user.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50213", "url": "https://ubuntu.com/security/CVE-2024-50213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tests: hdmi: Fix memory leaks in drm_display_mode_from_cea_vic() modprobe drm_hdmi_state_helper_test and then rmmod it, the following memory leak occurs. The `mode` allocated in drm_mode_duplicate() called by drm_display_mode_from_cea_vic() is not freed, which cause the memory leak: \tunreferenced object 0xffffff80ccd18100 (size 128): \t comm \"kunit_try_catch\", pid 1851, jiffies 4295059695 \t hex dump (first 32 bytes): \t 57 62 00 00 80 02 90 02 f0 02 20 03 00 00 e0 01 Wb........ ..... \t ea 01 ec 01 0d 02 00 00 0a 00 00 00 00 00 00 00 ................ \t backtrace (crc c2f1aa95): \t [<000000000f10b11b>] kmemleak_alloc+0x34/0x40 \t [<000000001cd4cf73>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<00000000f1f3cffa>] drm_mode_duplicate+0x44/0x19c \t [<000000008cbeef13>] drm_display_mode_from_cea_vic+0x88/0x98 \t [<0000000019daaacf>] 0xffffffedc11ae69c \t [<000000000aad0f85>] kunit_try_run_case+0x13c/0x3ac \t [<00000000a9210bac>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<000000000a0b2e9e>] kthread+0x2e8/0x374 \t [<00000000bd668858>] ret_from_fork+0x10/0x20 \t...... Free `mode` by using drm_kunit_display_mode_from_cea_vic() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50214", "url": "https://ubuntu.com/security/CVE-2024-50214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/connector: hdmi: Fix memory leak in drm_display_mode_from_cea_vic() modprobe drm_connector_test and then rmmod drm_connector_test, the following memory leak occurs. The `mode` allocated in drm_mode_duplicate() called by drm_display_mode_from_cea_vic() is not freed, which cause the memory leak: \tunreferenced object 0xffffff80cb0ee400 (size 128): \t comm \"kunit_try_catch\", pid 1948, jiffies 4294950339 \t hex dump (first 32 bytes): \t 14 44 02 00 80 07 d8 07 04 08 98 08 00 00 38 04 .D............8. \t 3c 04 41 04 65 04 00 00 05 00 00 00 00 00 00 00 <.A.e........... \t backtrace (crc 90e9585c): \t [<00000000ec42e3d7>] kmemleak_alloc+0x34/0x40 \t [<00000000d0ef055a>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<00000000c2062161>] drm_mode_duplicate+0x44/0x19c \t [<00000000f96c74aa>] drm_display_mode_from_cea_vic+0x88/0x98 \t [<00000000d8f2c8b4>] 0xffffffdc982a4868 \t [<000000005d164dbc>] kunit_try_run_case+0x13c/0x3ac \t [<000000006fb23398>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<000000006ea56ca0>] kthread+0x2e8/0x374 \t [<000000000676063f>] ret_from_fork+0x10/0x20 \t...... Free `mode` by using drm_kunit_display_mode_from_cea_vic() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50215", "url": "https://ubuntu.com/security/CVE-2024-50215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: assign dh_key to NULL after kfree_sensitive ctrl->dh_key might be used across multiple calls to nvmet_setup_dhgroup() for the same controller. So it's better to nullify it after release on error path in order to avoid double free later in nvmet_destroy_auth(). Found by Linux Verification Center (linuxtesting.org) with Svace.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50216", "url": "https://ubuntu.com/security/CVE-2024-50216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix finding a last resort AG in xfs_filestream_pick_ag When the main loop in xfs_filestream_pick_ag fails to find a suitable AG it tries to just pick the online AG. But the loop for that uses args->pag as loop iterator while the later code expects pag to be set. Fix this by reusing the max_pag case for this last resort, and also add a check for impossible case of no AG just to make sure that the uninitialized pag doesn't even escape in theory.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50217", "url": "https://ubuntu.com/security/CVE-2024-50217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free of block device file in __btrfs_free_extra_devids() Mounting btrfs from two images (which have the same one fsid and two different dev_uuids) in certain executing order may trigger an UAF for variable 'device->bdev_file' in __btrfs_free_extra_devids(). And following are the details: 1. Attach image_1 to loop0, attach image_2 to loop1, and scan btrfs devices by ioctl(BTRFS_IOC_SCAN_DEV): / btrfs_device_1 ? loop0 fs_device \\ btrfs_device_2 ? loop1 2. mount /dev/loop0 /mnt btrfs_open_devices btrfs_device_1->bdev_file = btrfs_get_bdev_and_sb(loop0) btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree fail: btrfs_close_devices // -ENOMEM \t btrfs_close_bdev(btrfs_device_1) fput(btrfs_device_1->bdev_file) \t // btrfs_device_1->bdev_file is freed \t btrfs_close_bdev(btrfs_device_2) fput(btrfs_device_2->bdev_file) 3. mount /dev/loop1 /mnt btrfs_open_devices btrfs_get_bdev_and_sb(&bdev_file) // EIO, btrfs_device_1->bdev_file is not assigned, // which points to a freed memory area btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree btrfs_free_extra_devids if (btrfs_device_1->bdev_file) fput(btrfs_device_1->bdev_file) // UAF ! Fix it by setting 'device->bdev_file' as 'NULL' after closing the btrfs_device in btrfs_close_one_device().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53043", "url": "https://ubuntu.com/security/CVE-2024-53043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mctp i2c: handle NULL header address daddr can be NULL if there is no neighbour table entry present, in that case the tx packet should be dropped. saddr will usually be set by MCTP core, but check for NULL in case a packet is transmitted by a different protocol.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50303", "url": "https://ubuntu.com/security/CVE-2024-50303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: resource,kexec: walk_system_ram_res_rev must retain resource flags walk_system_ram_res_rev() erroneously discards resource flags when passing the information to the callback. This causes systems with IORESOURCE_SYSRAM_DRIVER_MANAGED memory to have these resources selected during kexec to store kexec buffers if that memory happens to be at placed above normal system ram. This leads to undefined behavior after reboot. If the kexec buffer is never touched, nothing happens. If the kexec buffer is touched, it could lead to a crash (like below) or undefined behavior. Tested on a system with CXL memory expanders with driver managed memory, TPM enabled, and CONFIG_IMA_KEXEC=y. Adding printk's showed the flags were being discarded and as a result the check for IORESOURCE_SYSRAM_DRIVER_MANAGED passes. find_next_iomem_res: name(System RAM (kmem)) \t\t start(10000000000) \t\t end(1034fffffff) \t\t flags(83000200) locate_mem_hole_top_down: start(10000000000) end(1034fffffff) flags(0) [.] BUG: unable to handle page fault for address: ffff89834ffff000 [.] #PF: supervisor read access in kernel mode [.] #PF: error_code(0x0000) - not-present page [.] PGD c04c8bf067 P4D c04c8bf067 PUD c04c8be067 PMD 0 [.] Oops: 0000 [#1] SMP [.] RIP: 0010:ima_restore_measurement_list+0x95/0x4b0 [.] RSP: 0018:ffffc900000d3a80 EFLAGS: 00010286 [.] RAX: 0000000000001000 RBX: 0000000000000000 RCX: ffff89834ffff000 [.] RDX: 0000000000000018 RSI: ffff89834ffff000 RDI: ffff89834ffff018 [.] RBP: ffffc900000d3ba0 R08: 0000000000000020 R09: ffff888132b8a900 [.] R10: 4000000000000000 R11: 000000003a616d69 R12: 0000000000000000 [.] R13: ffffffff8404ac28 R14: 0000000000000000 R15: ffff89834ffff000 [.] FS: 0000000000000000(0000) GS:ffff893d44640000(0000) knlGS:0000000000000000 [.] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [.] ata5: SATA link down (SStatus 0 SControl 300) [.] CR2: ffff89834ffff000 CR3: 000001034d00f001 CR4: 0000000000770ef0 [.] PKRU: 55555554 [.] Call Trace: [.] [.] ? __die+0x78/0xc0 [.] ? page_fault_oops+0x2a8/0x3a0 [.] ? exc_page_fault+0x84/0x130 [.] ? asm_exc_page_fault+0x22/0x30 [.] ? ima_restore_measurement_list+0x95/0x4b0 [.] ? template_desc_init_fields+0x317/0x410 [.] ? crypto_alloc_tfm_node+0x9c/0xc0 [.] ? init_ima_lsm+0x30/0x30 [.] ima_load_kexec_buffer+0x72/0xa0 [.] ima_init+0x44/0xa0 [.] __initstub__kmod_ima__373_1201_init_ima7+0x1e/0xb0 [.] ? init_ima_lsm+0x30/0x30 [.] do_one_initcall+0xad/0x200 [.] ? idr_alloc_cyclic+0xaa/0x110 [.] ? new_slab+0x12c/0x420 [.] ? new_slab+0x12c/0x420 [.] ? number+0x12a/0x430 [.] ? sysvec_apic_timer_interrupt+0xa/0x80 [.] ? asm_sysvec_apic_timer_interrupt+0x16/0x20 [.] ? parse_args+0xd4/0x380 [.] ? parse_args+0x14b/0x380 [.] kernel_init_freeable+0x1c1/0x2b0 [.] ? rest_init+0xb0/0xb0 [.] kernel_init+0x16/0x1a0 [.] ret_from_fork+0x2f/0x40 [.] ? rest_init+0xb0/0xb0 [.] ret_from_fork_asm+0x11/0x20 [.] ", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50218", "url": "https://ubuntu.com/security/CVE-2024-50218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow Syzbot reported a kernel BUG in ocfs2_truncate_inline. There are two reasons for this: first, the parameter value passed is greater than ocfs2_max_inline_data_with_xattr, second, the start and end parameters of ocfs2_truncate_inline are \"unsigned int\". So, we need to add a sanity check for byte_start and byte_len right before ocfs2_truncate_inline() in ocfs2_remove_inode_range(), if they are greater than ocfs2_max_inline_data_with_xattr return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50219", "url": "https://ubuntu.com/security/CVE-2024-50219", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50263", "url": "https://ubuntu.com/security/CVE-2024-50263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fork: only invoke khugepaged, ksm hooks if no error There is no reason to invoke these hooks early against an mm that is in an incomplete state. The change in commit d24062914837 (\"fork: use __mt_dup() to duplicate maple tree in dup_mmap()\") makes this more pertinent as we may be in a state where entries in the maple tree are not yet consistent. Their placement early in dup_mmap() only appears to have been meaningful for early error checking, and since functionally it'd require a very small allocation to fail (in practice 'too small to fail') that'd only occur in the most dire circumstances, meaning the fork would fail or be OOM'd in any case. Since both khugepaged and KSM tracking are there to provide optimisations to memory performance rather than critical functionality, it doesn't really matter all that much if, under such dire memory pressure, we fail to register an mm with these. As a result, we follow the example of commit d2081b2bf819 (\"mm: khugepaged: make khugepaged_enter() void function\") and make ksm_fork() a void function also. We only expose the mm to these functions once we are done with them and only if no error occurred in the fork operation.", "cve_priority": "medium", "cve_public_date": "2024-11-11 14:15:00 UTC" }, { "cve": "CVE-2024-50220", "url": "https://ubuntu.com/security/CVE-2024-50220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fork: do not invoke uffd on fork if error occurs Patch series \"fork: do not expose incomplete mm on fork\". During fork we may place the virtual memory address space into an inconsistent state before the fork operation is complete. In addition, we may encounter an error during the fork operation that indicates that the virtual memory address space is invalidated. As a result, we should not be exposing it in any way to external machinery that might interact with the mm or VMAs, machinery that is not designed to deal with incomplete state. We specifically update the fork logic to defer khugepaged and ksm to the end of the operation and only to be invoked if no error arose, and disallow uffd from observing fork events should an error have occurred. This patch (of 2): Currently on fork we expose the virtual address space of a process to userland unconditionally if uffd is registered in VMAs, regardless of whether an error arose in the fork. This is performed in dup_userfaultfd_complete() which is invoked unconditionally, and performs two duties - invoking registered handlers for the UFFD_EVENT_FORK event via dup_fctx(), and clearing down userfaultfd_fork_ctx objects established in dup_userfaultfd(). This is problematic, because the virtual address space may not yet be correctly initialised if an error arose. The change in commit d24062914837 (\"fork: use __mt_dup() to duplicate maple tree in dup_mmap()\") makes this more pertinent as we may be in a state where entries in the maple tree are not yet consistent. We address this by, on fork error, ensuring that we roll back state that we would otherwise expect to clean up through the event being handled by userland and perform the memory freeing duty otherwise performed by dup_userfaultfd_complete(). We do this by implementing a new function, dup_userfaultfd_fail(), which performs the same loop, only decrementing reference counts. Note that we perform mmgrab() on the parent and child mm's, however userfaultfd_ctx_put() will mmdrop() this once the reference count drops to zero, so we will avoid memory leaks correctly here.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53047", "url": "https://ubuntu.com/security/CVE-2024-53047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: init: protect sched with rcu_read_lock Enabling CONFIG_PROVE_RCU_LIST with its dependence CONFIG_RCU_EXPERT creates this splat when an MPTCP socket is created: ============================= WARNING: suspicious RCU usage 6.12.0-rc2+ #11 Not tainted ----------------------------- net/mptcp/sched.c:44 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 no locks held by mptcp_connect/176. stack backtrace: CPU: 0 UID: 0 PID: 176 Comm: mptcp_connect Not tainted 6.12.0-rc2+ #11 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl (lib/dump_stack.c:123) lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822) mptcp_sched_find (net/mptcp/sched.c:44 (discriminator 7)) mptcp_init_sock (net/mptcp/protocol.c:2867 (discriminator 1)) ? sock_init_data_uid (arch/x86/include/asm/atomic.h:28) inet_create.part.0.constprop.0 (net/ipv4/af_inet.c:386) ? __sock_create (include/linux/rcupdate.h:347 (discriminator 1)) __sock_create (net/socket.c:1576) __sys_socket (net/socket.c:1671) ? __pfx___sys_socket (net/socket.c:1712) ? do_user_addr_fault (arch/x86/mm/fault.c:1419 (discriminator 1)) __x64_sys_socket (net/socket.c:1728) do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) That's because when the socket is initialised, rcu_read_lock() is not used despite the explicit comment written above the declaration of mptcp_sched_find() in sched.c. Adding the missing lock/unlock avoids the warning.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50221", "url": "https://ubuntu.com/security/CVE-2024-50221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Vangogh: Fix kernel memory out of bounds write KASAN reports that the GPU metrics table allocated in vangogh_tables_init() is not large enough for the memset done in smu_cmn_init_soft_gpu_metrics(). Condensed report follows: [ 33.861314] BUG: KASAN: slab-out-of-bounds in smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu] [ 33.861799] Write of size 168 at addr ffff888129f59500 by task mangoapp/1067 ... [ 33.861808] CPU: 6 UID: 1000 PID: 1067 Comm: mangoapp Tainted: G W 6.12.0-rc4 #356 1a56f59a8b5182eeaf67eb7cb8b13594dd23b544 [ 33.861816] Tainted: [W]=WARN [ 33.861818] Hardware name: Valve Galileo/Galileo, BIOS F7G0107 12/01/2023 [ 33.861822] Call Trace: [ 33.861826] [ 33.861829] dump_stack_lvl+0x66/0x90 [ 33.861838] print_report+0xce/0x620 [ 33.861853] kasan_report+0xda/0x110 [ 33.862794] kasan_check_range+0xfd/0x1a0 [ 33.862799] __asan_memset+0x23/0x40 [ 33.862803] smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.863306] vangogh_get_gpu_metrics_v2_4+0x123/0xad0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.864257] vangogh_common_get_gpu_metrics+0xb0c/0xbc0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.865682] amdgpu_dpm_get_gpu_metrics+0xcc/0x110 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.866160] amdgpu_get_gpu_metrics+0x154/0x2d0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.867135] dev_attr_show+0x43/0xc0 [ 33.867147] sysfs_kf_seq_show+0x1f1/0x3b0 [ 33.867155] seq_read_iter+0x3f8/0x1140 [ 33.867173] vfs_read+0x76c/0xc50 [ 33.867198] ksys_read+0xfb/0x1d0 [ 33.867214] do_syscall_64+0x90/0x160 ... [ 33.867353] Allocated by task 378 on cpu 7 at 22.794876s: [ 33.867358] kasan_save_stack+0x33/0x50 [ 33.867364] kasan_save_track+0x17/0x60 [ 33.867367] __kasan_kmalloc+0x87/0x90 [ 33.867371] vangogh_init_smc_tables+0x3f9/0x840 [amdgpu] [ 33.867835] smu_sw_init+0xa32/0x1850 [amdgpu] [ 33.868299] amdgpu_device_init+0x467b/0x8d90 [amdgpu] [ 33.868733] amdgpu_driver_load_kms+0x19/0xf0 [amdgpu] [ 33.869167] amdgpu_pci_probe+0x2d6/0xcd0 [amdgpu] [ 33.869608] local_pci_probe+0xda/0x180 [ 33.869614] pci_device_probe+0x43f/0x6b0 Empirically we can confirm that the former allocates 152 bytes for the table, while the latter memsets the 168 large block. Root cause appears that when GPU metrics tables for v2_4 parts were added it was not considered to enlarge the table to fit. The fix in this patch is rather \"brute force\" and perhaps later should be done in a smarter way, by extracting and consolidating the part version to size logic to a common helper, instead of brute forcing the largest possible allocation. Nevertheless, for now this works and fixes the out of bounds write. v2: * Drop impossible v3_0 case. (Mario) (cherry picked from commit 0880f58f9609f0200483a49429af0f050d281703)", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50222", "url": "https://ubuntu.com/security/CVE-2024-50222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iov_iter: fix copy_page_from_iter_atomic() if KMAP_LOCAL_FORCE_MAP generic/077 on x86_32 CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP=y with highmem, on huge=always tmpfs, issues a warning and then hangs (interruptibly): WARNING: CPU: 5 PID: 3517 at mm/highmem.c:622 kunmap_local_indexed+0x62/0xc9 CPU: 5 UID: 0 PID: 3517 Comm: cp Not tainted 6.12.0-rc4 #2 ... copy_page_from_iter_atomic+0xa6/0x5ec generic_perform_write+0xf6/0x1b4 shmem_file_write_iter+0x54/0x67 Fix copy_page_from_iter_atomic() by limiting it in that case (include/linux/skbuff.h skb_frag_must_loop() does similar). But going forward, perhaps CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP is too surprising, has outlived its usefulness, and should just be removed?", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50223", "url": "https://ubuntu.com/security/CVE-2024-50223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/numa: Fix the potential null pointer dereference in task_numa_work() When running stress-ng-vm-segv test, we found a null pointer dereference error in task_numa_work(). Here is the backtrace: [323676.066985] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ...... [323676.067108] CPU: 35 PID: 2694524 Comm: stress-ng-vm-se ...... [323676.067113] pstate: 23401009 (nzCv daif +PAN -UAO +TCO +DIT +SSBS BTYPE=--) [323676.067115] pc : vma_migratable+0x1c/0xd0 [323676.067122] lr : task_numa_work+0x1ec/0x4e0 [323676.067127] sp : ffff8000ada73d20 [323676.067128] x29: ffff8000ada73d20 x28: 0000000000000000 x27: 000000003e89f010 [323676.067130] x26: 0000000000080000 x25: ffff800081b5c0d8 x24: ffff800081b27000 [323676.067133] x23: 0000000000010000 x22: 0000000104d18cc0 x21: ffff0009f7158000 [323676.067135] x20: 0000000000000000 x19: 0000000000000000 x18: ffff8000ada73db8 [323676.067138] x17: 0001400000000000 x16: ffff800080df40b0 x15: 0000000000000035 [323676.067140] x14: ffff8000ada73cc8 x13: 1fffe0017cc72001 x12: ffff8000ada73cc8 [323676.067142] x11: ffff80008001160c x10: ffff000be639000c x9 : ffff8000800f4ba4 [323676.067145] x8 : ffff000810375000 x7 : ffff8000ada73974 x6 : 0000000000000001 [323676.067147] x5 : 0068000b33e26707 x4 : 0000000000000001 x3 : ffff0009f7158000 [323676.067149] x2 : 0000000000000041 x1 : 0000000000004400 x0 : 0000000000000000 [323676.067152] Call trace: [323676.067153] vma_migratable+0x1c/0xd0 [323676.067155] task_numa_work+0x1ec/0x4e0 [323676.067157] task_work_run+0x78/0xd8 [323676.067161] do_notify_resume+0x1ec/0x290 [323676.067163] el0_svc+0x150/0x160 [323676.067167] el0t_64_sync_handler+0xf8/0x128 [323676.067170] el0t_64_sync+0x17c/0x180 [323676.067173] Code: d2888001 910003fd f9000bf3 aa0003f3 (f9401000) [323676.067177] SMP: stopping secondary CPUs [323676.070184] Starting crashdump kernel... stress-ng-vm-segv in stress-ng is used to stress test the SIGSEGV error handling function of the system, which tries to cause a SIGSEGV error on return from unmapping the whole address space of the child process. Normally this program will not cause kernel crashes. But before the munmap system call returns to user mode, a potential task_numa_work() for numa balancing could be added and executed. In this scenario, since the child process has no vma after munmap, the vma_next() in task_numa_work() will return a null pointer even if the vma iterator restarts from 0. Recheck the vma pointer before dereferencing it in task_numa_work().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53053", "url": "https://ubuntu.com/security/CVE-2024-53053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Fix another deadlock during RTC update If ufshcd_rtc_work calls ufshcd_rpm_put_sync() and the pm's usage_count is 0, we will enter the runtime suspend callback. However, the runtime suspend callback will wait to flush ufshcd_rtc_work, causing a deadlock. Replace ufshcd_rpm_put_sync() with ufshcd_rpm_put() to avoid the deadlock.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53075", "url": "https://ubuntu.com/security/CVE-2024-53075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv: Prevent a bad reference count on CPU nodes When populating cache leaves we previously fetched the CPU device node at the very beginning. But when ACPI is enabled we go through a specific branch which returns early and does not call 'of_node_put' for the node that was acquired. Since we are not using a CPU device node for the ACPI code anyways, we can simply move the initialization of it just passed the ACPI block, and we are guaranteed to have an 'of_node_put' call for the acquired node. This prevents a bad reference count of the CPU device node. Moreover, the previous function did not check for errors when acquiring the device node, so a return -ENOENT has been added for that case.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50224", "url": "https://ubuntu.com/security/CVE-2024-50224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: spi-fsl-dspi: Fix crash when not using GPIO chip select Add check for the return value of spi_get_csgpiod() to avoid passing a NULL pointer to gpiod_direction_output(), preventing a crash when GPIO chip select is not used. Fix below crash: [ 4.251960] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 4.260762] Mem abort info: [ 4.263556] ESR = 0x0000000096000004 [ 4.267308] EC = 0x25: DABT (current EL), IL = 32 bits [ 4.272624] SET = 0, FnV = 0 [ 4.275681] EA = 0, S1PTW = 0 [ 4.278822] FSC = 0x04: level 0 translation fault [ 4.283704] Data abort info: [ 4.286583] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 4.292074] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 4.297130] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 4.302445] [0000000000000000] user address but active_mm is swapper [ 4.308805] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 4.315072] Modules linked in: [ 4.318124] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc4-next-20241023-00008-ga20ec42c5fc1 #359 [ 4.328130] Hardware name: LS1046A QDS Board (DT) [ 4.332832] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 4.339794] pc : gpiod_direction_output+0x34/0x5c [ 4.344505] lr : gpiod_direction_output+0x18/0x5c [ 4.349208] sp : ffff80008003b8f0 [ 4.352517] x29: ffff80008003b8f0 x28: 0000000000000000 x27: ffffc96bcc7e9068 [ 4.359659] x26: ffffc96bcc6e00b0 x25: ffffc96bcc598398 x24: ffff447400132810 [ 4.366800] x23: 0000000000000000 x22: 0000000011e1a300 x21: 0000000000020002 [ 4.373940] x20: 0000000000000000 x19: 0000000000000000 x18: ffffffffffffffff [ 4.381081] x17: ffff44740016e600 x16: 0000000500000003 x15: 0000000000000007 [ 4.388221] x14: 0000000000989680 x13: 0000000000020000 x12: 000000000000001e [ 4.395362] x11: 0044b82fa09b5a53 x10: 0000000000000019 x9 : 0000000000000008 [ 4.402502] x8 : 0000000000000002 x7 : 0000000000000007 x6 : 0000000000000000 [ 4.409641] x5 : 0000000000000200 x4 : 0000000002000000 x3 : 0000000000000000 [ 4.416781] x2 : 0000000000022202 x1 : 0000000000000000 x0 : 0000000000000000 [ 4.423921] Call trace: [ 4.426362] gpiod_direction_output+0x34/0x5c (P) [ 4.431067] gpiod_direction_output+0x18/0x5c (L) [ 4.435771] dspi_setup+0x220/0x334", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50225", "url": "https://ubuntu.com/security/CVE-2024-50225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix error propagation of split bios The purpose of btrfs_bbio_propagate_error() shall be propagating an error of split bio to its original btrfs_bio, and tell the error to the upper layer. However, it's not working well on some cases. * Case 1. Immediate (or quick) end_bio with an error When btrfs sends btrfs_bio to mirrored devices, btrfs calls btrfs_bio_end_io() when all the mirroring bios are completed. If that btrfs_bio was split, it is from btrfs_clone_bioset and its end_io function is btrfs_orig_write_end_io. For this case, btrfs_bbio_propagate_error() accesses the orig_bbio's bio context to increase the error count. That works well in most cases. However, if the end_io is called enough fast, orig_bbio's (remaining part after split) bio context may not be properly set at that time. Since the bio context is set when the orig_bbio (the last btrfs_bio) is sent to devices, that might be too late for earlier split btrfs_bio's completion. That will result in NULL pointer dereference. That bug is easily reproducible by running btrfs/146 on zoned devices [1] and it shows the following trace. [1] You need raid-stripe-tree feature as it create \"-d raid0 -m raid1\" FS. BUG: kernel NULL pointer dereference, address: 0000000000000020 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 UID: 0 PID: 13 Comm: kworker/u32:1 Not tainted 6.11.0-rc7-BTRFS-ZNS+ #474 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Workqueue: writeback wb_workfn (flush-btrfs-5) RIP: 0010:btrfs_bio_end_io+0xae/0xc0 [btrfs] BTRFS error (device dm-0): bdev /dev/mapper/error-test errs: wr 2, rd 0, flush 0, corrupt 0, gen 0 RSP: 0018:ffffc9000006f248 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888005a7f080 RCX: ffffc9000006f1dc RDX: 0000000000000000 RSI: 000000000000000a RDI: ffff888005a7f080 RBP: ffff888011dfc540 R08: 0000000000000000 R09: 0000000000000001 R10: ffffffff82e508e0 R11: 0000000000000005 R12: ffff88800ddfbe58 R13: ffff888005a7f080 R14: ffff888005a7f158 R15: ffff888005a7f158 FS: 0000000000000000(0000) GS:ffff88803ea80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000020 CR3: 0000000002e22006 CR4: 0000000000370ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __die_body.cold+0x19/0x26 ? page_fault_oops+0x13e/0x2b0 ? _printk+0x58/0x73 ? do_user_addr_fault+0x5f/0x750 ? exc_page_fault+0x76/0x240 ? asm_exc_page_fault+0x22/0x30 ? btrfs_bio_end_io+0xae/0xc0 [btrfs] ? btrfs_log_dev_io_error+0x7f/0x90 [btrfs] btrfs_orig_write_end_io+0x51/0x90 [btrfs] dm_submit_bio+0x5c2/0xa50 [dm_mod] ? find_held_lock+0x2b/0x80 ? blk_try_enter_queue+0x90/0x1e0 __submit_bio+0xe0/0x130 ? ktime_get+0x10a/0x160 ? lockdep_hardirqs_on+0x74/0x100 submit_bio_noacct_nocheck+0x199/0x410 btrfs_submit_bio+0x7d/0x150 [btrfs] btrfs_submit_chunk+0x1a1/0x6d0 [btrfs] ? lockdep_hardirqs_on+0x74/0x100 ? __folio_start_writeback+0x10/0x2c0 btrfs_submit_bbio+0x1c/0x40 [btrfs] submit_one_bio+0x44/0x60 [btrfs] submit_extent_folio+0x13f/0x330 [btrfs] ? btrfs_set_range_writeback+0xa3/0xd0 [btrfs] extent_writepage_io+0x18b/0x360 [btrfs] extent_write_locked_range+0x17c/0x340 [btrfs] ? __pfx_end_bbio_data_write+0x10/0x10 [btrfs] run_delalloc_cow+0x71/0xd0 [btrfs] btrfs_run_delalloc_range+0x176/0x500 [btrfs] ? find_lock_delalloc_range+0x119/0x260 [btrfs] writepage_delalloc+0x2ab/0x480 [btrfs] extent_write_cache_pages+0x236/0x7d0 [btrfs] btrfs_writepages+0x72/0x130 [btrfs] do_writepages+0xd4/0x240 ? find_held_lock+0x2b/0x80 ? wbc_attach_and_unlock_inode+0x12c/0x290 ? wbc_attach_and_unlock_inode+0x12c/0x29 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53054", "url": "https://ubuntu.com/security/CVE-2024-53054", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50226", "url": "https://ubuntu.com/security/CVE-2024-50226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cxl/port: Fix use-after-free, permit out-of-order decoder shutdown In support of investigating an initialization failure report [1], cxl_test was updated to register mock memory-devices after the mock root-port/bus device had been registered. That led to cxl_test crashing with a use-after-free bug with the following signature: cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem0:decoder7.0 @ 0 next: cxl_switch_uport.0 nr_eps: 1 nr_targets: 1 cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem4:decoder14.0 @ 1 next: cxl_switch_uport.0 nr_eps: 2 nr_targets: 1 cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[0] = cxl_switch_dport.0 for mem0:decoder7.0 @ 0 1) cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[1] = cxl_switch_dport.4 for mem4:decoder14.0 @ 1 [..] cxld_unregister: cxl decoder14.0: cxl_region_decode_reset: cxl_region region3: mock_decoder_reset: cxl_port port3: decoder3.0 reset 2) mock_decoder_reset: cxl_port port3: decoder3.0: out of order reset, expected decoder3.1 cxl_endpoint_decoder_release: cxl decoder14.0: [..] cxld_unregister: cxl decoder7.0: 3) cxl_region_decode_reset: cxl_region region3: Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6bc3: 0000 [#1] PREEMPT SMP PTI [..] RIP: 0010:to_cxl_port+0x8/0x60 [cxl_core] [..] Call Trace: cxl_region_decode_reset+0x69/0x190 [cxl_core] cxl_region_detach+0xe8/0x210 [cxl_core] cxl_decoder_kill_region+0x27/0x40 [cxl_core] cxld_unregister+0x5d/0x60 [cxl_core] At 1) a region has been established with 2 endpoint decoders (7.0 and 14.0). Those endpoints share a common switch-decoder in the topology (3.0). At teardown, 2), decoder14.0 is the first to be removed and hits the \"out of order reset case\" in the switch decoder. The effect though is that region3 cleanup is aborted leaving it in-tact and referencing decoder14.0. At 3) the second attempt to teardown region3 trips over the stale decoder14.0 object which has long since been deleted. The fix here is to recognize that the CXL specification places no mandate on in-order shutdown of switch-decoders, the driver enforces in-order allocation, and hardware enforces in-order commit. So, rather than fail and leave objects dangling, always remove them. In support of making cxl_region_decode_reset() always succeed, cxl_region_invalidate_memregion() failures are turned into warnings. Crashing the kernel is ok there since system integrity is at risk if caches cannot be managed around physical address mutation events like CXL region destruction. A new device_for_each_child_reverse_from() is added to cleanup port->commit_end after all dependent decoders have been disabled. In other words if decoders are allocated 0->1->2 and disabled 1->2->0 then port->commit_end only decrements from 2 after 2 has been disabled, and it decrements all the way to zero since 1 was disabled previously.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50227", "url": "https://ubuntu.com/security/CVE-2024-50227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Fix KASAN reported stack out-of-bounds read in tb_retimer_scan() KASAN reported following issue: BUG: KASAN: stack-out-of-bounds in tb_retimer_scan+0xffe/0x1550 [thunderbolt] Read of size 4 at addr ffff88810111fc1c by task kworker/u56:0/11 CPU: 0 UID: 0 PID: 11 Comm: kworker/u56:0 Tainted: G U 6.11.0+ #1387 Tainted: [U]=USER Workqueue: thunderbolt0 tb_handle_hotplug [thunderbolt] Call Trace: dump_stack_lvl+0x6c/0x90 print_report+0xd1/0x630 kasan_report+0xdb/0x110 __asan_report_load4_noabort+0x14/0x20 tb_retimer_scan+0xffe/0x1550 [thunderbolt] tb_scan_port+0xa6f/0x2060 [thunderbolt] tb_handle_hotplug+0x17b1/0x3080 [thunderbolt] process_one_work+0x626/0x1100 worker_thread+0x6c8/0xfa0 kthread+0x2c8/0x3a0 ret_from_fork+0x3a/0x80 ret_from_fork_asm+0x1a/0x30 This happens because the loop variable still gets incremented by one so max becomes 3 instead of 2, and this makes the second loop read past the the array declared on the stack. Fix this by assigning to max directly in the loop body.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50228", "url": "https://ubuntu.com/security/CVE-2024-50228", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50229", "url": "https://ubuntu.com/security/CVE-2024-50229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential deadlock with newly created symlinks Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers memory reclamation involving the filesystem layer, which can result in circular lock dependencies among the reader/writer semaphore nilfs->ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the fs_reclaim pseudo lock. This is because after commit 21fc61c73c39 (\"don't put symlink bodies in pagecache into highmem\"), the gfp flags of the page cache for symbolic links are overwritten to GFP_KERNEL via inode_nohighmem(). This is not a problem for symlinks read from the backing device, because the __GFP_FS flag is dropped after inode_nohighmem() is called. However, when a new symlink is created with nilfs_symlink(), the gfp flags remain overwritten to GFP_KERNEL. Then, memory allocation called from page_symlink() etc. triggers memory reclamation including the FS layer, which may call nilfs_evict_inode() or nilfs_dirty_inode(). And these can cause a deadlock if they are called while nilfs->ns_segctor_sem is held: Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags of newly created symlinks in the same way that nilfs_new_inode() and __nilfs_read_inode() do, as a workaround until we adopt nofs allocation scope consistently or improve the locking constraints.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50230", "url": "https://ubuntu.com/security/CVE-2024-50230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug due to missing clearing of checked flag Syzbot reported that in directory operations after nilfs2 detects filesystem corruption and degrades to read-only, __block_write_begin_int(), which is called to prepare block writes, may fail the BUG_ON check for accesses exceeding the folio/page size, triggering a kernel bug. This was found to be because the \"checked\" flag of a page/folio was not cleared when it was discarded by nilfs2's own routine, which causes the sanity check of directory entries to be skipped when the directory page/folio is reloaded. So, fix that. This was necessary when the use of nilfs2's own page discard routine was applied to more than just metadata files.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50231", "url": "https://ubuntu.com/security/CVE-2024-50231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gts-helper: Fix memory leaks in iio_gts_build_avail_scale_table() modprobe iio-test-gts and rmmod it, then the following memory leak occurs: \tunreferenced object 0xffffff80c810be00 (size 64): \t comm \"kunit_try_catch\", pid 1654, jiffies 4294913981 \t hex dump (first 32 bytes): \t 02 00 00 00 08 00 00 00 20 00 00 00 40 00 00 00 ........ ...@... \t 80 00 00 00 00 02 00 00 00 04 00 00 00 08 00 00 ................ \t backtrace (crc a63d875e): \t [<0000000028c1b3c2>] kmemleak_alloc+0x34/0x40 \t [<000000001d6ecc87>] __kmalloc_noprof+0x2bc/0x3c0 \t [<00000000393795c1>] devm_iio_init_iio_gts+0x4b4/0x16f4 \t [<0000000071bb4b09>] 0xffffffdf052a62e0 \t [<000000000315bc18>] 0xffffffdf052a6488 \t [<00000000f9dc55b5>] kunit_try_run_case+0x13c/0x3ac \t [<00000000175a3fd4>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000f505065d>] kthread+0x2e8/0x374 \t [<00000000bbfb0e5d>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cbfe9e70 (size 16): \t comm \"kunit_try_catch\", pid 1658, jiffies 4294914015 \t hex dump (first 16 bytes): \t 10 00 00 00 40 00 00 00 80 00 00 00 00 00 00 00 ....@........... \t backtrace (crc 857f0cb4): \t [<0000000028c1b3c2>] kmemleak_alloc+0x34/0x40 \t [<000000001d6ecc87>] __kmalloc_noprof+0x2bc/0x3c0 \t [<00000000393795c1>] devm_iio_init_iio_gts+0x4b4/0x16f4 \t [<0000000071bb4b09>] 0xffffffdf052a62e0 \t [<000000007d089d45>] 0xffffffdf052a6864 \t [<00000000f9dc55b5>] kunit_try_run_case+0x13c/0x3ac \t [<00000000175a3fd4>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000f505065d>] kthread+0x2e8/0x374 \t [<00000000bbfb0e5d>] ret_from_fork+0x10/0x20 \t...... It includes 5*5 times \"size 64\" memory leaks, which correspond to 5 times test_init_iio_gain_scale() calls with gts_test_gains size 10 (10*size(int)) and gts_test_itimes size 5. It also includes 5*1 times \"size 16\" memory leak, which correspond to one time __test_init_iio_gain_scale() call with gts_test_gains_gain_low size 3 (3*size(int)) and gts_test_itimes size 5. The reason is that the per_time_gains[i] is not freed which is allocated in the \"gts->num_itime\" for loop in iio_gts_build_avail_scale_table().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53076", "url": "https://ubuntu.com/security/CVE-2024-53076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gts-helper: Fix memory leaks for the error path of iio_gts_build_avail_scale_table() If per_time_scales[i] or per_time_gains[i] kcalloc fails in the for loop of iio_gts_build_avail_scale_table(), the err_free_out will fail to call kfree() each time when i is reduced to 0, so all the per_time_scales[0] and per_time_gains[0] will not be freed, which will cause memory leaks. Fix it by checking if i >= 0.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50232", "url": "https://ubuntu.com/security/CVE-2024-50232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr() In the ad7124_write_raw() function, parameter val can potentially be zero. This may lead to a division by zero when DIV_ROUND_CLOSEST() is called within ad7124_set_channel_odr(). The ad7124_write_raw() function is invoked through the sequence: iio_write_channel_raw() -> iio_write_channel_attribute() -> iio_channel_write(), with no checks in place to ensure val is non-zero.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50233", "url": "https://ubuntu.com/security/CVE-2024-50233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: iio: frequency: ad9832: fix division by zero in ad9832_calc_freqreg() In the ad9832_write_frequency() function, clk_get_rate() might return 0. This can lead to a division by zero when calling ad9832_calc_freqreg(). The check if (fout > (clk_get_rate(st->mclk) / 2)) does not protect against the case when fout is 0. The ad9832_write_frequency() function is called from ad9832_write(), and fout is derived from a text buffer, which can contain any value.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53055", "url": "https://ubuntu.com/security/CVE-2024-53055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix 6 GHz scan construction If more than 255 colocated APs exist for the set of all APs found during 2.4/5 GHz scanning, then the 6 GHz scan construction will loop forever since the loop variable has type u8, which can never reach the number found when that's bigger than 255, and is stored in a u32 variable. Also move it into the loops to have a smaller scope. Using a u32 there is fine, we limit the number of APs in the scan list and each has a limit on the number of RNR entries due to the frame size. With a limit of 1000 scan results, a frame size upper bound of 4096 (really it's more like ~2300) and a TBTT entry size of at least 11, we get an upper bound for the number of ~372k, well in the bounds of a u32.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50234", "url": "https://ubuntu.com/security/CVE-2024-50234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlegacy: Clear stale interrupts before resuming device iwl4965 fails upon resume from hibernation on my laptop. The reason seems to be a stale interrupt which isn't being cleared out before interrupts are enabled. We end up with a race beween the resume trying to bring things back up, and the restart work (queued form the interrupt handler) trying to bring things down. Eventually the whole thing blows up. Fix the problem by clearing out any stale interrupts before interrupts get enabled during resume. Here's a debug log of the indicent: [ 12.042589] ieee80211 phy0: il_isr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000 [ 12.042625] ieee80211 phy0: il4965_irq_tasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000 [ 12.042651] iwl4965 0000:10:00.0: RF_KILL bit toggled to enable radio. [ 12.042653] iwl4965 0000:10:00.0: On demand firmware reload [ 12.042690] ieee80211 phy0: il4965_irq_tasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282 [ 12.052207] ieee80211 phy0: il4965_mac_start enter [ 12.052212] ieee80211 phy0: il_prep_station Add STA to driver ID 31: ff:ff:ff:ff:ff:ff [ 12.052244] ieee80211 phy0: il4965_set_hw_ready hardware ready [ 12.052324] ieee80211 phy0: il_apm_init Init card's basic functions [ 12.052348] ieee80211 phy0: il_apm_init L1 Enabled; Disabling L0S [ 12.055727] ieee80211 phy0: il4965_load_bsm Begin load bsm [ 12.056140] ieee80211 phy0: il4965_verify_bsm Begin verify bsm [ 12.058642] ieee80211 phy0: il4965_verify_bsm BSM bootstrap uCode image OK [ 12.058721] ieee80211 phy0: il4965_load_bsm BSM write complete, poll 1 iterations [ 12.058734] ieee80211 phy0: __il4965_up iwl4965 is coming up [ 12.058737] ieee80211 phy0: il4965_mac_start Start UP work done. [ 12.058757] ieee80211 phy0: __il4965_down iwl4965 is going down [ 12.058761] ieee80211 phy0: il_scan_cancel_timeout Scan cancel timeout [ 12.058762] ieee80211 phy0: il_do_scan_abort Not performing scan to abort [ 12.058765] ieee80211 phy0: il_clear_ucode_stations Clearing ucode stations in driver [ 12.058767] ieee80211 phy0: il_clear_ucode_stations No active stations found to be cleared [ 12.058819] ieee80211 phy0: _il_apm_stop Stop card, put in low power state [ 12.058827] ieee80211 phy0: _il_apm_stop_master stop master [ 12.058864] ieee80211 phy0: il4965_clear_free_frames 0 frames on pre-allocated heap on clear. [ 12.058869] ieee80211 phy0: Hardware restart was requested [ 16.132299] iwl4965 0000:10:00.0: START_ALIVE timeout after 4000ms. [ 16.132303] ------------[ cut here ]------------ [ 16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue. [ 16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132390] Modules linked in: ctr ccm sch_fq_codel xt_tcpudp xt_multiport xt_state iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables binfmt_misc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdh_generic ecc iTCO_wdt i2c_dev iwl4965 iwlegacy coretemp snd_hda_codec_analog pcspkr psmouse mac80211 snd_hda_codec_generic libarc4 sdhci_pci cqhci sha256_generic sdhci libsha256 firewire_ohci snd_hda_intel snd_intel_dspcfg mmc_core snd_hda_codec snd_hwdep firewire_core led_class iosf_mbi snd_hda_core uhci_hcd lpc_ich crc_itu_t cfg80211 ehci_pci ehci_hcd snd_pcm usbcore mfd_core rfkill snd_timer snd usb_common soundcore video parport_pc parport intel_agp wmi intel_gtt backlight e1000e agpgart evdev [ 16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143 [ 16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010 [ 16.132463] Workqueue: async async_run_entry_fn [ 16.132469] RIP: 0010:ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132501] Code: da 02 00 0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50235", "url": "https://ubuntu.com/security/CVE-2024-50235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: clear wdev->cqm_config pointer on free When we free wdev->cqm_config when unregistering, we also need to clear out the pointer since the same wdev/netdev may get re-registered in another network namespace, then destroyed later, running this code again, which results in a double-free.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50236", "url": "https://ubuntu.com/security/CVE-2024-50236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: Fix memory leak in management tx In the current logic, memory is allocated for storing the MSDU context during management packet TX but this memory is not being freed during management TX completion. Similar leaks are seen in the management TX cleanup logic. Kmemleak reports this problem as below, unreferenced object 0xffffff80b64ed250 (size 16): comm \"kworker/u16:7\", pid 148, jiffies 4294687130 (age 714.199s) hex dump (first 16 bytes): 00 2b d8 d8 80 ff ff ff c4 74 e9 fd 07 00 00 00 .+.......t...... backtrace: [] __kmem_cache_alloc_node+0x1e4/0x2d8 [] kmalloc_trace+0x48/0x110 [] ath10k_wmi_tlv_op_gen_mgmt_tx_send+0xd4/0x1d8 [ath10k_core] [] ath10k_mgmt_over_wmi_tx_work+0x134/0x298 [ath10k_core] [] process_scheduled_works+0x1ac/0x400 [] worker_thread+0x208/0x328 [] kthread+0x100/0x1c0 [] ret_from_fork+0x10/0x20 Free the memory during completion and cleanup to fix the leak. Protect the mgmt_pending_tx idr_remove() operation in ath10k_wmi_tlv_op_cleanup_mgmt_tx_send() using ar->data_lock similar to other instances. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50237", "url": "https://ubuntu.com/security/CVE-2024-50237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower Avoid potentially crashing in the driver because of uninitialized private data", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50238", "url": "https://ubuntu.com/security/CVE-2024-50238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usbc: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data from the qcom-qmp-usb driver, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. This bug was later reproduced when the driver was copied to create the qmp-usbc driver. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with these drivers.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50239", "url": "https://ubuntu.com/security/CVE-2024-50239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usb-legacy: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data from the qcom-qmp-usb driver, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. This bug was later reproduced when the driver was copied to create the qmp-usb-legacy driver. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with these drivers.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50240", "url": "https://ubuntu.com/security/CVE-2024-50240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usb: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with this driver.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53077", "url": "https://ubuntu.com/security/CVE-2024-53077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpcrdma: Always release the rpcrdma_device's xa_array Dai pointed out that the xa_init_flags() in rpcrdma_add_one() needs to have a matching xa_destroy() in rpcrdma_remove_one() to release underlying memory that the xarray might have accrued during operation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50242", "url": "https://ubuntu.com/security/CVE-2024-50242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ntfs_file_release", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50243", "url": "https://ubuntu.com/security/CVE-2024-50243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix general protection fault in run_is_mapped_full Fixed deleating of a non-resident attribute in ntfs_create_inode() rollback.", "cve_priority": "low", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50244", "url": "https://ubuntu.com/security/CVE-2024-50244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ni_clear() Checking of NTFS_FLAGS_LOG_REPLAYING added to prevent access to uninitialized bitmap during replay process.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50245", "url": "https://ubuntu.com/security/CVE-2024-50245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix possible deadlock in mi_read Mutex lock with another subclass used in ni_lock_dir().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50246", "url": "https://ubuntu.com/security/CVE-2024-50246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Add rough attr alloc_size check", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50247", "url": "https://ubuntu.com/security/CVE-2024-50247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Check if more than chunk-size bytes are written A incorrectly formatted chunk may decompress into more than LZNT_CHUNK_SIZE bytes and a index out of bounds will occur in s_max_off.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50248", "url": "https://ubuntu.com/security/CVE-2024-50248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Add bounds checking to mi_enum_attr() Added bounds checking to make sure that every attr don't stray beyond valid memory region.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53078", "url": "https://ubuntu.com/security/CVE-2024-53078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Fix NULL vs IS_ERR() check in probe() The iommu_paging_domain_alloc() function doesn't return NULL pointers, it returns error pointers. Update the check to match.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53056", "url": "https://ubuntu.com/security/CVE-2024-53056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Fix potential NULL dereference in mtk_crtc_destroy() In mtk_crtc_create(), if the call to mbox_request_channel() fails then we set the \"mtk_crtc->cmdq_client.chan\" pointer to NULL. In that situation, we do not call cmdq_pkt_create(). During the cleanup, we need to check if the \"mtk_crtc->cmdq_client.chan\" is NULL first before calling cmdq_pkt_destroy(). Calling cmdq_pkt_destroy() is unnecessary if we didn't call cmdq_pkt_create() and it will result in a NULL pointer dereference.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50249", "url": "https://ubuntu.com/security/CVE-2024-50249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Make rmw_lock a raw_spin_lock The following BUG was triggered: ============================= [ BUG: Invalid wait context ] 6.12.0-rc2-XXX #406 Not tainted ----------------------------- kworker/1:1/62 is trying to lock: ffffff8801593030 (&cpc_ptr->rmw_lock){+.+.}-{3:3}, at: cpc_write+0xcc/0x370 other info that might help us debug this: context-{5:5} 2 locks held by kworker/1:1/62: #0: ffffff897ef5ec98 (&rq->__lock){-.-.}-{2:2}, at: raw_spin_rq_lock_nested+0x2c/0x50 #1: ffffff880154e238 (&sg_policy->update_lock){....}-{2:2}, at: sugov_update_shared+0x3c/0x280 stack backtrace: CPU: 1 UID: 0 PID: 62 Comm: kworker/1:1 Not tainted 6.12.0-rc2-g9654bd3e8806 #406 Workqueue: 0x0 (events) Call trace: dump_backtrace+0xa4/0x130 show_stack+0x20/0x38 dump_stack_lvl+0x90/0xd0 dump_stack+0x18/0x28 __lock_acquire+0x480/0x1ad8 lock_acquire+0x114/0x310 _raw_spin_lock+0x50/0x70 cpc_write+0xcc/0x370 cppc_set_perf+0xa0/0x3a8 cppc_cpufreq_fast_switch+0x40/0xc0 cpufreq_driver_fast_switch+0x4c/0x218 sugov_update_shared+0x234/0x280 update_load_avg+0x6ec/0x7b8 dequeue_entities+0x108/0x830 dequeue_task_fair+0x58/0x408 __schedule+0x4f0/0x1070 schedule+0x54/0x130 worker_thread+0xc0/0x2e8 kthread+0x130/0x148 ret_from_fork+0x10/0x20 sugov_update_shared() locks a raw_spinlock while cpc_write() locks a spinlock. To have a correct wait-type order, update rmw_lock to a raw spinlock and ensure that interrupts will be disabled on the CPU holding it. [ rjw: Changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50250", "url": "https://ubuntu.com/security/CVE-2024-50250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fsdax: dax_unshare_iter needs to copy entire blocks The code that copies data from srcmap to iomap in dax_unshare_iter is very very broken, which bfoster's recent fsx changes have exposed. If the pos and len passed to dax_file_unshare are not aligned to an fsblock boundary, the iter pos and length in the _iter function will reflect this unalignment. dax_iomap_direct_access always returns a pointer to the start of the kmapped fsdax page, even if its pos argument is in the middle of that page. This is catastrophic for data integrity when iter->pos is not aligned to a page, because daddr/saddr do not point to the same byte in the file as iter->pos. Hence we corrupt user data by copying it to the wrong place. If iter->pos + iomap_length() in the _iter function not aligned to a page, then we fail to copy a full block, and only partially populate the destination block. This is catastrophic for data confidentiality because we expose stale pmem contents. Fix both of these issues by aligning copy_pos/copy_len to a page boundary (remember, this is fsdax so 1 fsblock == 1 base page) so that we always copy full blocks. We're not done yet -- there's no call to invalidate_inode_pages2_range, so programs that have the file range mmap'd will continue accessing the old memory mapping after the file metadata updates have completed. Be careful with the return value -- if the unshare succeeds, we still need to return the number of bytes that the iomap iter thinks we're operating on.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50251", "url": "https://ubuntu.com/security/CVE-2024-50251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_payload: sanitize offset and length before calling skb_checksum() If access to offset + length is larger than the skbuff length, then skb_checksum() triggers BUG_ON(). skb_checksum() internally subtracts the length parameter while iterating over skbuff, BUG_ON(len) at the end of it checks that the expected length to be included in the checksum calculation is fully consumed.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50252", "url": "https://ubuntu.com/security/CVE-2024-50252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_ipip: Fix memory leak when changing remote IPv6 address The device stores IPv6 addresses that are used for encapsulation in linear memory that is managed by the driver. Changing the remote address of an ip6gre net device never worked properly, but since cited commit the following reproducer [1] would result in a warning [2] and a memory leak [3]. The problem is that the new remote address is never added by the driver to its hash table (and therefore the device) and the old address is never removed from it. Fix by programming the new address when the configuration of the ip6gre net device changes and removing the old one. If the address did not change, then the above would result in increasing the reference count of the address and then decreasing it. [1] # ip link add name bla up type ip6gre local 2001:db8:1::1 remote 2001:db8:2::1 tos inherit ttl inherit # ip link set dev bla type ip6gre remote 2001:db8:3::1 # ip link del dev bla # devlink dev reload pci/0000:01:00.0 [2] WARNING: CPU: 0 PID: 1682 at drivers/net/ethernet/mellanox/mlxsw/spectrum.c:3002 mlxsw_sp_ipv6_addr_put+0x140/0x1d0 Modules linked in: CPU: 0 UID: 0 PID: 1682 Comm: ip Not tainted 6.12.0-rc3-custom-g86b5b55bc835 #151 Hardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023 RIP: 0010:mlxsw_sp_ipv6_addr_put+0x140/0x1d0 [...] Call Trace: mlxsw_sp_router_netdevice_event+0x55f/0x1240 notifier_call_chain+0x5a/0xd0 call_netdevice_notifiers_info+0x39/0x90 unregister_netdevice_many_notify+0x63e/0x9d0 rtnl_dellink+0x16b/0x3a0 rtnetlink_rcv_msg+0x142/0x3f0 netlink_rcv_skb+0x50/0x100 netlink_unicast+0x242/0x390 netlink_sendmsg+0x1de/0x420 ____sys_sendmsg+0x2bd/0x320 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xd0 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f [3] unreferenced object 0xffff898081f597a0 (size 32): comm \"ip\", pid 1626, jiffies 4294719324 hex dump (first 32 bytes): 20 01 0d b8 00 02 00 00 00 00 00 00 00 00 00 01 ............... 21 49 61 83 80 89 ff ff 00 00 00 00 01 00 00 00 !Ia............. backtrace (crc fd9be911): [<00000000df89c55d>] __kmalloc_cache_noprof+0x1da/0x260 [<00000000ff2a1ddb>] mlxsw_sp_ipv6_addr_kvdl_index_get+0x281/0x340 [<000000009ddd445d>] mlxsw_sp_router_netdevice_event+0x47b/0x1240 [<00000000743e7757>] notifier_call_chain+0x5a/0xd0 [<000000007c7b9e13>] call_netdevice_notifiers_info+0x39/0x90 [<000000002509645d>] register_netdevice+0x5f7/0x7a0 [<00000000c2e7d2a9>] ip6gre_newlink_common.isra.0+0x65/0x130 [<0000000087cd6d8d>] ip6gre_newlink+0x72/0x120 [<000000004df7c7cc>] rtnl_newlink+0x471/0xa20 [<0000000057ed632a>] rtnetlink_rcv_msg+0x142/0x3f0 [<0000000032e0d5b5>] netlink_rcv_skb+0x50/0x100 [<00000000908bca63>] netlink_unicast+0x242/0x390 [<00000000cdbe1c87>] netlink_sendmsg+0x1de/0x420 [<0000000011db153e>] ____sys_sendmsg+0x2bd/0x320 [<000000003b6d53eb>] ___sys_sendmsg+0x9a/0xe0 [<00000000cae27c62>] __sys_sendmsg+0x7a/0xd0", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50253", "url": "https://ubuntu.com/security/CVE-2024-50253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check the validity of nr_words in bpf_iter_bits_new() Check the validity of nr_words in bpf_iter_bits_new(). Without this check, when multiplication overflow occurs for nr_bits (e.g., when nr_words = 0x0400-0001, nr_bits becomes 64), stack corruption may occur due to bpf_probe_read_kernel_common(..., nr_bytes = 0x2000-0008). Fix it by limiting the maximum value of nr_words to 511. The value is derived from the current implementation of BPF memory allocator. To ensure compatibility if the BPF memory allocator's size limitation changes in the future, use the helper bpf_mem_alloc_check_size() to check whether nr_bytes is too larger. And return -E2BIG instead of -ENOMEM for oversized nr_bytes.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50254", "url": "https://ubuntu.com/security/CVE-2024-50254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free dynamically allocated bits in bpf_iter_bits_destroy() bpf_iter_bits_destroy() uses \"kit->nr_bits <= 64\" to check whether the bits are dynamically allocated. However, the check is incorrect and may cause a kmemleak as shown below: unreferenced object 0xffff88812628c8c0 (size 32): comm \"swapper/0\", pid 1, jiffies 4294727320 hex dump (first 32 bytes): \tb0 c1 55 f5 81 88 ff ff f0 f0 f0 f0 f0 f0 f0 f0 ..U........... \tf0 f0 f0 f0 f0 f0 f0 f0 00 00 00 00 00 00 00 00 .............. backtrace (crc 781e32cc): \t[<00000000c452b4ab>] kmemleak_alloc+0x4b/0x80 \t[<0000000004e09f80>] __kmalloc_node_noprof+0x480/0x5c0 \t[<00000000597124d6>] __alloc.isra.0+0x89/0xb0 \t[<000000004ebfffcd>] alloc_bulk+0x2af/0x720 \t[<00000000d9c10145>] prefill_mem_cache+0x7f/0xb0 \t[<00000000ff9738ff>] bpf_mem_alloc_init+0x3e2/0x610 \t[<000000008b616eac>] bpf_global_ma_init+0x19/0x30 \t[<00000000fc473efc>] do_one_initcall+0xd3/0x3c0 \t[<00000000ec81498c>] kernel_init_freeable+0x66a/0x940 \t[<00000000b119f72f>] kernel_init+0x20/0x160 \t[<00000000f11ac9a7>] ret_from_fork+0x3c/0x70 \t[<0000000004671da4>] ret_from_fork_asm+0x1a/0x30 That is because nr_bits will be set as zero in bpf_iter_bits_next() after all bits have been iterated. Fix the issue by setting kit->bit to kit->nr_bits instead of setting kit->nr_bits to zero when the iteration completes in bpf_iter_bits_next(). In addition, use \"!nr_bits || bits >= nr_bits\" to check whether the iteration is complete and still use \"nr_bits > 64\" to indicate whether bits are dynamically allocated. The \"!nr_bits\" check is necessary because bpf_iter_bits_new() may fail before setting kit->nr_bits, and this condition will stop the iteration early instead of accessing the zeroed or freed kit->bits. Considering the initial value of kit->bits is -1 and the type of kit->nr_bits is unsigned int, change the type of kit->nr_bits to int. The potential overflow problem will be handled in the following patch.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50255", "url": "https://ubuntu.com/security/CVE-2024-50255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci: fix null-ptr-deref in hci_read_supported_codecs Fix __hci_cmd_sync_sk() to return not NULL for unknown opcodes. __hci_cmd_sync_sk() returns NULL if a command returns a status event. However, it also returns NULL where an opcode doesn't exist in the hci_cc table because hci_cmd_complete_evt() assumes status = skb->data[0] for unknown opcodes. This leads to null-ptr-deref in cmd_sync for HCI_OP_READ_LOCAL_CODECS as there is no hci_cc for HCI_OP_READ_LOCAL_CODECS, which always assumes status = skb->data[0]. KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077] CPU: 1 PID: 2000 Comm: kworker/u9:5 Not tainted 6.9.0-ga6bcb805883c-dirty #10 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: hci7 hci_power_on RIP: 0010:hci_read_supported_codecs+0xb9/0x870 net/bluetooth/hci_codec.c:138 Code: 08 48 89 ef e8 b8 c1 8f fd 48 8b 75 00 e9 96 00 00 00 49 89 c6 48 ba 00 00 00 00 00 fc ff df 4c 8d 60 70 4c 89 e3 48 c1 eb 03 <0f> b6 04 13 84 c0 0f 85 82 06 00 00 41 83 3c 24 02 77 0a e8 bf 78 RSP: 0018:ffff888120bafac8 EFLAGS: 00010212 RAX: 0000000000000000 RBX: 000000000000000e RCX: ffff8881173f0040 RDX: dffffc0000000000 RSI: ffffffffa58496c0 RDI: ffff88810b9ad1e4 RBP: ffff88810b9ac000 R08: ffffffffa77882a7 R09: 1ffffffff4ef1054 R10: dffffc0000000000 R11: fffffbfff4ef1055 R12: 0000000000000070 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88810b9ac000 FS: 0000000000000000(0000) GS:ffff8881f6c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6ddaa3439e CR3: 0000000139764003 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: hci_read_local_codecs_sync net/bluetooth/hci_sync.c:4546 [inline] hci_init_stage_sync net/bluetooth/hci_sync.c:3441 [inline] hci_init4_sync net/bluetooth/hci_sync.c:4706 [inline] hci_init_sync net/bluetooth/hci_sync.c:4742 [inline] hci_dev_init_sync net/bluetooth/hci_sync.c:4912 [inline] hci_dev_open_sync+0x19a9/0x2d30 net/bluetooth/hci_sync.c:4994 hci_dev_do_open net/bluetooth/hci_core.c:483 [inline] hci_power_on+0x11e/0x560 net/bluetooth/hci_core.c:1015 process_one_work kernel/workqueue.c:3267 [inline] process_scheduled_works+0x8ef/0x14f0 kernel/workqueue.c:3348 worker_thread+0x91f/0xe50 kernel/workqueue.c:3429 kthread+0x2cb/0x360 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50256", "url": "https://ubuntu.com/security/CVE-2024-50256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6() I got a syzbot report without a repro [1] crashing in nf_send_reset6() I think the issue is that dev->hard_header_len is zero, and we attempt later to push an Ethernet header. Use LL_MAX_HEADER, as other functions in net/ipv6/netfilter/nf_reject_ipv6.c. [1] skbuff: skb_under_panic: text:ffffffff89b1d008 len:74 put:14 head:ffff88803123aa00 data:ffff88803123a9f2 tail:0x3c end:0x140 dev:syz_tun kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 UID: 0 PID: 7373 Comm: syz.1.568 Not tainted 6.12.0-rc2-syzkaller-00631-g6d858708d465 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:skb_panic net/core/skbuff.c:206 [inline] RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216 Code: 0d 8d 48 c7 c6 60 a6 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 ba 30 38 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP: 0018:ffffc900045269b0 EFLAGS: 00010282 RAX: 0000000000000088 RBX: dffffc0000000000 RCX: cd66dacdc5d8e800 RDX: 0000000000000000 RSI: 0000000000000200 RDI: 0000000000000000 RBP: ffff88802d39a3d0 R08: ffffffff8174afec R09: 1ffff920008a4ccc R10: dffffc0000000000 R11: fffff520008a4ccd R12: 0000000000000140 R13: ffff88803123aa00 R14: ffff88803123a9f2 R15: 000000000000003c FS: 00007fdbee5ff6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000005d322000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: skb_push+0xe5/0x100 net/core/skbuff.c:2636 eth_header+0x38/0x1f0 net/ethernet/eth.c:83 dev_hard_header include/linux/netdevice.h:3208 [inline] nf_send_reset6+0xce6/0x1270 net/ipv6/netfilter/nf_reject_ipv6.c:358 nft_reject_inet_eval+0x3b9/0x690 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x418/0x6b0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] br_nf_pre_routing_ipv6+0x63e/0x770 net/bridge/br_netfilter_ipv6.c:184 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_bridge_pre net/bridge/br_input.c:277 [inline] br_handle_frame+0x9fd/0x1530 net/bridge/br_input.c:424 __netif_receive_skb_core+0x13e8/0x4570 net/core/dev.c:5562 __netif_receive_skb_one_core net/core/dev.c:5666 [inline] __netif_receive_skb+0x12f/0x650 net/core/dev.c:5781 netif_receive_skb_internal net/core/dev.c:5867 [inline] netif_receive_skb+0x1e8/0x890 net/core/dev.c:5926 tun_rx_batched+0x1b7/0x8f0 drivers/net/tun.c:1550 tun_get_user+0x3056/0x47e0 drivers/net/tun.c:2007 tun_chr_write_iter+0x10d/0x1f0 drivers/net/tun.c:2053 new_sync_write fs/read_write.c:590 [inline] vfs_write+0xa6d/0xc90 fs/read_write.c:683 ksys_write+0x183/0x2b0 fs/read_write.c:736 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:0x7fdbeeb7d1ff Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 c9 8d 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 1c 8e 02 00 48 RSP: 002b:00007fdbee5ff000 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fdbeed36058 RCX: 00007fdbeeb7d1ff RDX: 000000000000008e RSI: 0000000020000040 RDI: 00000000000000c8 RBP: 00007fdbeebf12be R08: 0000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50257", "url": "https://ubuntu.com/security/CVE-2024-50257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: Fix use-after-free in get_info() ip6table_nat module unload has refcnt warning for UAF. call trace is: WARNING: CPU: 1 PID: 379 at kernel/module/main.c:853 module_put+0x6f/0x80 Modules linked in: ip6table_nat(-) CPU: 1 UID: 0 PID: 379 Comm: ip6tables Not tainted 6.12.0-rc4-00047-gc2ee9f594da8-dirty #205 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:module_put+0x6f/0x80 Call Trace: get_info+0x128/0x180 do_ip6t_get_ctl+0x6a/0x430 nf_getsockopt+0x46/0x80 ipv6_getsockopt+0xb9/0x100 rawv6_getsockopt+0x42/0x190 do_sock_getsockopt+0xaa/0x180 __sys_getsockopt+0x70/0xc0 __x64_sys_getsockopt+0x20/0x30 do_syscall_64+0xa2/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Concurrent execution of module unload and get_info() trigered the warning. The root cause is as follows: cpu0\t\t\t\t cpu1 module_exit //mod->state = MODULE_STATE_GOING ip6table_nat_exit xt_unregister_template \tkfree(t) \t//removed from templ_list \t\t\t\t getinfo() \t\t\t\t\t t = xt_find_table_lock \t\t\t\t\t\tlist_for_each_entry(tmpl, &xt_templates[af]...) \t\t\t\t\t\t\tif (strcmp(tmpl->name, name)) \t\t\t\t\t\t\t\tcontinue; //table not found \t\t\t\t\t\t\ttry_module_get \t\t\t\t\t\tlist_for_each_entry(t, &xt_net->tables[af]...) \t\t\t\t\t\t\treturn t; //not get refcnt \t\t\t\t\t module_put(t->me) //uaf unregister_pernet_subsys //remove table from xt_net list While xt_table module was going away and has been removed from xt_templates list, we couldnt get refcnt of xt_table->me. Check module in xt_net->tables list re-traversal to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50258", "url": "https://ubuntu.com/security/CVE-2024-50258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix crash when config small gso_max_size/gso_ipv4_max_size Config a small gso_max_size/gso_ipv4_max_size will lead to an underflow in sk_dst_gso_max_size(), which may trigger a BUG_ON crash, because sk->sk_gso_max_size would be much bigger than device limits. Call Trace: tcp_write_xmit tso_segs = tcp_init_tso_segs(skb, mss_now); tcp_set_skb_tso_segs tcp_skb_pcount_set // skb->len = 524288, mss_now = 8 // u16 tso_segs = 524288/8 = 65535 -> 0 tso_segs = DIV_ROUND_UP(skb->len, mss_now) BUG_ON(!tso_segs) Add check for the minimum value of gso_max_size and gso_ipv4_max_size.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50262", "url": "https://ubuntu.com/security/CVE-2024-50262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix out-of-bounds write in trie_get_next_key() trie_get_next_key() allocates a node stack with size trie->max_prefixlen, while it writes (trie->max_prefixlen + 1) nodes to the stack when it has full paths from the root to leaves. For example, consider a trie with max_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ... 0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with .prefixlen = 8 make 9 nodes be written on the node stack with size 8.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53044", "url": "https://ubuntu.com/security/CVE-2024-53044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_api: fix xa_insert() error path in tcf_block_get_ext() This command: $ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact Error: block dev insert failed: -EBUSY. fails because user space requests the same block index to be set for both ingress and egress. [ side note, I don't think it even failed prior to commit 913b47d3424e (\"net/sched: Introduce tc block netdev tracking infra\"), because this is a command from an old set of notes of mine which used to work, but alas, I did not scientifically bisect this ] The problem is not that it fails, but rather, that the second time around, it fails differently (and irrecoverably): $ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact Error: dsa_core: Flow block cb is busy. [ another note: the extack is added by me for illustration purposes. the context of the problem is that clsact_init() obtains the same &q->ingress_block pointer as &q->egress_block, and since we call tcf_block_get_ext() on both of them, \"dev\" will be added to the block->ports xarray twice, thus failing the operation: once through the ingress block pointer, and once again through the egress block pointer. the problem itself is that when xa_insert() fails, we have emitted a FLOW_BLOCK_BIND command through ndo_setup_tc(), but the offload never sees a corresponding FLOW_BLOCK_UNBIND. ] Even correcting the bad user input, we still cannot recover: $ tc qdisc replace dev swp3 ingress_block 1 egress_block 2 clsact Error: dsa_core: Flow block cb is busy. Basically the only way to recover is to reboot the system, or unbind and rebind the net device driver. To fix the bug, we need to fill the correct error teardown path which was missed during code movement, and call tcf_block_offload_unbind() when xa_insert() fails. [ last note, fundamentally I blame the label naming convention in tcf_block_get_ext() for the bug. The labels should be named after what they do, not after the error path that jumps to them. This way, it is obviously wrong that two labels pointing to the same code mean something is wrong, and checking the code correctness at the goto site is also easier ]", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50259", "url": "https://ubuntu.com/security/CVE-2024-50259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netdevsim: Add trailing zero to terminate the string in nsim_nexthop_bucket_activity_write() This was found by a static analyzer. We should not forget the trailing zero after copy_from_user() if we will further do some string operations, sscanf() in this case. Adding a trailing zero will ensure that the function performs properly.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50304", "url": "https://ubuntu.com/security/CVE-2024-50304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find() The per-netns IP tunnel hash table is protected by the RTNL mutex and ip_tunnel_find() is only called from the control path where the mutex is taken. Add a lockdep expression to hlist_for_each_entry_rcu() in ip_tunnel_find() in order to validate that the mutex is held and to silence the suspicious RCU usage warning [1]. [1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gd95d9a31aceb #139 Not tainted ----------------------------- net/ipv4/ip_tunnel.c:221 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/362: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60 stack backtrace: CPU: 12 UID: 0 PID: 362 Comm: ip Not tainted 6.12.0-rc3-custom-gd95d9a31aceb #139 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 ip_tunnel_find+0x435/0x4d0 ip_tunnel_newlink+0x517/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53042", "url": "https://ubuntu.com/security/CVE-2024-53042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_init_flow() There are code paths from which the function is called without holding the RCU read lock, resulting in a suspicious RCU usage warning [1]. Fix by using l3mdev_master_upper_ifindex_by_index() which will acquire the RCU read lock before calling l3mdev_master_upper_ifindex_by_index_rcu(). [1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gac8f72681cf2 #141 Not tainted ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/361: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60 stack backtrace: CPU: 3 UID: 0 PID: 361 Comm: ip Not tainted 6.12.0-rc3-custom-gac8f72681cf2 #141 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 dev_get_by_index_rcu+0x1d3/0x210 l3mdev_master_upper_ifindex_by_index_rcu+0x2b/0xf0 ip_tunnel_bind_dev+0x72f/0xa00 ip_tunnel_newlink+0x368/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53048", "url": "https://ubuntu.com/security/CVE-2024-53048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix crash on probe for DPLL enabled E810 LOM The E810 Lan On Motherboard (LOM) design is vendor specific. Intel provides the reference design, but it is up to vendor on the final product design. For some cases, like Linux DPLL support, the static values defined in the driver does not reflect the actual LOM design. Current implementation of dpll pins is causing the crash on probe of the ice driver for such DPLL enabled E810 LOM designs: WARNING: (...) at drivers/dpll/dpll_core.c:495 dpll_pin_get+0x2c4/0x330 ... Call Trace: ? __warn+0x83/0x130 ? dpll_pin_get+0x2c4/0x330 ? report_bug+0x1b7/0x1d0 ? handle_bug+0x42/0x70 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? dpll_pin_get+0x117/0x330 ? dpll_pin_get+0x2c4/0x330 ? dpll_pin_get+0x117/0x330 ice_dpll_get_pins.isra.0+0x52/0xe0 [ice] ... The number of dpll pins enabled by LOM vendor is greater than expected and defined in the driver for Intel designed NICs, which causes the crash. Prevent the crash and allow generic pin initialization within Linux DPLL subsystem for DPLL enabled E810 LOM designs. Newly designed solution for described issue will be based on \"per HW design\" pin initialization. It requires pin information dynamically acquired from the firmware and is already in progress, planned for next-tree only.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53058", "url": "https://ubuntu.com/security/CVE-2024-53058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data In case the non-paged data of a SKB carries protocol header and protocol payload to be transmitted on a certain platform that the DMA AXI address width is configured to 40-bit/48-bit, or the size of the non-paged data is bigger than TSO_MAX_BUFF_SIZE on a certain platform that the DMA AXI address width is configured to 32-bit, then this SKB requires at least two DMA transmit descriptors to serve it. For example, three descriptors are allocated to split one DMA buffer mapped from one piece of non-paged data: dma_desc[N + 0], dma_desc[N + 1], dma_desc[N + 2]. Then three elements of tx_q->tx_skbuff_dma[] will be allocated to hold extra information to be reused in stmmac_tx_clean(): tx_q->tx_skbuff_dma[N + 0], tx_q->tx_skbuff_dma[N + 1], tx_q->tx_skbuff_dma[N + 2]. Now we focus on tx_q->tx_skbuff_dma[entry].buf, which is the DMA buffer address returned by DMA mapping call. stmmac_tx_clean() will try to unmap the DMA buffer _ONLY_IF_ tx_q->tx_skbuff_dma[entry].buf is a valid buffer address. The expected behavior that saves DMA buffer address of this non-paged data to tx_q->tx_skbuff_dma[entry].buf is: tx_q->tx_skbuff_dma[N + 0].buf = NULL; tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = dma_map_single(); Unfortunately, the current code misbehaves like this: tx_q->tx_skbuff_dma[N + 0].buf = dma_map_single(); tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = NULL; On the stmmac_tx_clean() side, when dma_desc[N + 0] is closed by the DMA engine, tx_q->tx_skbuff_dma[N + 0].buf is a valid buffer address obviously, then the DMA buffer will be unmapped immediately. There may be a rare case that the DMA engine does not finish the pending dma_desc[N + 1], dma_desc[N + 2] yet. Now things will go horribly wrong, DMA is going to access a unmapped/unreferenced memory region, corrupted data will be transmited or iommu fault will be triggered :( In contrast, the for-loop that maps SKB fragments behaves perfectly as expected, and that is how the driver should do for both non-paged data and paged frags actually. This patch corrects DMA map/unmap sequences by fixing the array index for tx_q->tx_skbuff_dma[entry].buf when assigning DMA buffer address. Tested and verified on DWXGMAC CORE 3.20a", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50260", "url": "https://ubuntu.com/security/CVE-2024-50260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sock_map: fix a NULL pointer dereference in sock_map_link_update_prog() The following race condition could trigger a NULL pointer dereference: sock_map_link_detach():\t\tsock_map_link_update_prog(): mutex_lock(&sockmap_mutex); ... sockmap_link->map = NULL; mutex_unlock(&sockmap_mutex); \t\t\t\t mutex_lock(&sockmap_mutex); \t\t\t\t ... \t\t\t\t sock_map_prog_link_lookup(sockmap_link->map); \t\t\t\t mutex_unlock(&sockmap_mutex); Fix it by adding a NULL pointer check. In this specific case, it makes no sense to update a link which is being released.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53045", "url": "https://ubuntu.com/security/CVE-2024-53045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: dapm: fix bounds checker error in dapm_widget_list_create The widgets array in the snd_soc_dapm_widget_list has a __counted_by attribute attached to it, which points to the num_widgets variable. This attribute is used in bounds checking, and if it is not set before the array is filled, then the bounds sanitizer will issue a warning or a kernel panic if CONFIG_UBSAN_TRAP is set. This patch sets the size of the widgets list calculated with list_for_each as the initial value for num_widgets as it is used for allocating memory for the array. It is updated with the actual number of added elements after the array is filled.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50261", "url": "https://ubuntu.com/security/CVE-2024-50261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macsec: Fix use-after-free while sending the offloading packet KASAN reports the following UAF. The metadata_dst, which is used to store the SCI value for macsec offload, is already freed by metadata_dst_free() in macsec_free_netdev(), while driver still use it for sending the packet. To fix this issue, dst_release() is used instead to release metadata_dst. So it is not freed instantly in macsec_free_netdev() if still referenced by skb. BUG: KASAN: slab-use-after-free in mlx5e_xmit+0x1e8f/0x4190 [mlx5_core] Read of size 2 at addr ffff88813e42e038 by task kworker/7:2/714 [...] Workqueue: mld mld_ifc_work Call Trace: dump_stack_lvl+0x51/0x60 print_report+0xc1/0x600 kasan_report+0xab/0xe0 mlx5e_xmit+0x1e8f/0x4190 [mlx5_core] dev_hard_start_xmit+0x120/0x530 sch_direct_xmit+0x149/0x11e0 __qdisc_run+0x3ad/0x1730 __dev_queue_xmit+0x1196/0x2ed0 vlan_dev_hard_start_xmit+0x32e/0x510 [8021q] dev_hard_start_xmit+0x120/0x530 __dev_queue_xmit+0x14a7/0x2ed0 macsec_start_xmit+0x13e9/0x2340 dev_hard_start_xmit+0x120/0x530 __dev_queue_xmit+0x14a7/0x2ed0 ip6_finish_output2+0x923/0x1a70 ip6_finish_output+0x2d7/0x970 ip6_output+0x1ce/0x3a0 NF_HOOK.constprop.0+0x15f/0x190 mld_sendpack+0x59a/0xbd0 mld_ifc_work+0x48a/0xa80 process_one_work+0x5aa/0xe50 worker_thread+0x79c/0x1290 kthread+0x28f/0x350 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x11/0x20 Allocated by task 3922: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 __kasan_kmalloc+0x77/0x90 __kmalloc_noprof+0x188/0x400 metadata_dst_alloc+0x1f/0x4e0 macsec_newlink+0x914/0x1410 __rtnl_newlink+0xe08/0x15b0 rtnl_newlink+0x5f/0x90 rtnetlink_rcv_msg+0x667/0xa80 netlink_rcv_skb+0x12c/0x360 netlink_unicast+0x551/0x770 netlink_sendmsg+0x72d/0xbd0 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x52e/0x6a0 ___sys_sendmsg+0xeb/0x170 __sys_sendmsg+0xb5/0x140 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Freed by task 4011: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x50 poison_slab_object+0x10c/0x190 __kasan_slab_free+0x11/0x30 kfree+0xe0/0x290 macsec_free_netdev+0x3f/0x140 netdev_run_todo+0x450/0xc70 rtnetlink_rcv_msg+0x66f/0xa80 netlink_rcv_skb+0x12c/0x360 netlink_unicast+0x551/0x770 netlink_sendmsg+0x72d/0xbd0 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x52e/0x6a0 ___sys_sendmsg+0xeb/0x170 __sys_sendmsg+0xb5/0x140 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53059", "url": "https://ubuntu.com/security/CVE-2024-53059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd() 1. The size of the response packet is not validated. 2. The response buffer is not freed. Resolve these issues by switching to iwl_mvm_send_cmd_status(), which handles both size validation and frees the buffer.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53074", "url": "https://ubuntu.com/security/CVE-2024-53074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: don't leak a link on AP removal Release the link mapping resource in AP removal. This impacted devices that do not support the MLD API (9260 and down). On those devices, we couldn't start the AP again after the AP has been already started and stopped.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53049", "url": "https://ubuntu.com/security/CVE-2024-53049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slub/kunit: fix a WARNING due to unwrapped __kmalloc_cache_noprof 'modprobe slub_kunit' will have a warning as shown below. The root cause is that __kmalloc_cache_noprof was directly used, which resulted in no alloc_tag being allocated. This caused current->alloc_tag to be null, leading to a warning in alloc_tag_add_check. Let's add an alloc_hook layer to __kmalloc_cache_noprof specifically within lib/slub_kunit.c, which is the only user of this internal slub function outside kmalloc implementation itself. [58162.947016] WARNING: CPU: 2 PID: 6210 at ./include/linux/alloc_tag.h:125 alloc_tagging_slab_alloc_hook+0x268/0x27c [58162.957721] Call trace: [58162.957919] alloc_tagging_slab_alloc_hook+0x268/0x27c [58162.958286] __kmalloc_cache_noprof+0x14c/0x344 [58162.958615] test_kmalloc_redzone_access+0x50/0x10c [slub_kunit] [58162.959045] kunit_try_run_case+0x74/0x184 [kunit] [58162.959401] kunit_generic_run_threadfn_adapter+0x2c/0x4c [kunit] [58162.959841] kthread+0x10c/0x118 [58162.960093] ret_from_fork+0x10/0x20 [58162.960363] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50192", "url": "https://ubuntu.com/security/CVE-2024-50192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v4: Don't allow a VMOVP on a dying VPE Kunkun Jiang reported that there is a small window of opportunity for userspace to force a change of affinity for a VPE while the VPE has already been unmapped, but the corresponding doorbell interrupt still visible in /proc/irq/. Plug the race by checking the value of vmapp_count, which tracks whether the VPE is mapped ot not, and returning an error in this case. This involves making vmapp_count common to both GICv4.1 and its v4.0 ancestor.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50069", "url": "https://ubuntu.com/security/CVE-2024-50069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: apple: check devm_kasprintf() returned value devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked. Fix this lack and check the returned value. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50070", "url": "https://ubuntu.com/security/CVE-2024-50070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: stm32: check devm_kasprintf() returned value devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked. Fix this lack and check the returned value. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50196", "url": "https://ubuntu.com/security/CVE-2024-50196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: ocelot: fix system hang on level based interrupts The current implementation only calls chained_irq_enter() and chained_irq_exit() if it detects pending interrupts. ``` for (i = 0; i < info->stride; i++) { \turegmap_read(info->map, id_reg + 4 * i, ®); \tif (!reg) \t\tcontinue; \tchained_irq_enter(parent_chip, desc); ``` However, in case of GPIO pin configured in level mode and the parent controller configured in edge mode, GPIO interrupt might be lowered by the hardware. In the result, if the interrupt is short enough, the parent interrupt is still pending while the GPIO interrupt is cleared; chained_irq_enter() never gets called and the system hangs trying to service the parent interrupt. Moving chained_irq_enter() and chained_irq_exit() outside the for loop ensures that they are called even when GPIO interrupt is lowered by the hardware. The similar code with chained_irq_enter() / chained_irq_exit() functions wrapping interrupt checking loop may be found in many other drivers: ``` grep -r -A 10 chained_irq_enter drivers/pinctrl ```", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50197", "url": "https://ubuntu.com/security/CVE-2024-50197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: intel: platform: fix error path in device_for_each_child_node() The device_for_each_child_node() loop requires calls to fwnode_handle_put() upon early returns to decrement the refcount of the child node and avoid leaking memory if that error path is triggered. There is one early returns within that loop in intel_platform_pinctrl_prepare_community(), but fwnode_handle_put() is missing. Instead of adding the missing call, the scoped version of the loop can be used to simplify the code and avoid mistakes in the future if new early returns are added, as the child node is only used for parsing, and it is never assigned.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50071", "url": "https://ubuntu.com/security/CVE-2024-50071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: nuvoton: fix a double free in ma35_pinctrl_dt_node_to_map_func() 'new_map' is allocated using devm_* which takes care of freeing the allocated data on device removal, call to \t.dt_free_map = pinconf_generic_dt_free_map double frees the map as pinconf_generic_dt_free_map() calls pinctrl_utils_free_map(). Fix this by using kcalloc() instead of auto-managed devm_kcalloc().", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50072", "url": "https://ubuntu.com/security/CVE-2024-50072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/bugs: Use code segment selector for VERW operand Robert Gill reported below #GP in 32-bit mode when dosemu software was executing vm86() system call: general protection fault: 0000 [#1] PREEMPT SMP CPU: 4 PID: 4610 Comm: dosemu.bin Not tainted 6.6.21-gentoo-x86 #1 Hardware name: Dell Inc. PowerEdge 1950/0H723K, BIOS 2.7.0 10/30/2010 EIP: restore_all_switch_stack+0xbe/0xcf EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000 ESI: 00000000 EDI: 00000000 EBP: 00000000 ESP: ff8affdc DS: 0000 ES: 0000 FS: 0000 GS: 0033 SS: 0068 EFLAGS: 00010046 CR0: 80050033 CR2: 00c2101c CR3: 04b6d000 CR4: 000406d0 Call Trace: show_regs+0x70/0x78 die_addr+0x29/0x70 exc_general_protection+0x13c/0x348 exc_bounds+0x98/0x98 handle_exception+0x14d/0x14d exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf This only happens in 32-bit mode when VERW based mitigations like MDS/RFDS are enabled. This is because segment registers with an arbitrary user value can result in #GP when executing VERW. Intel SDM vol. 2C documents the following behavior for VERW instruction: #GP(0) - If a memory operand effective address is outside the CS, DS, ES, \t FS, or GS segment limit. CLEAR_CPU_BUFFERS macro executes VERW instruction before returning to user space. Use %cs selector to reference VERW operand. This ensures VERW will not #GP for an arbitrary user %ds. [ mingo: Fixed the SOB chain. ]", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50073", "url": "https://ubuntu.com/security/CVE-2024-50073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: Fix use-after-free in gsm_cleanup_mux BUG: KASAN: slab-use-after-free in gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] Read of size 8 at addr ffff88815fe99c00 by task poc/3379 CPU: 0 UID: 0 PID: 3379 Comm: poc Not tainted 6.11.0+ #56 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] __pfx_gsm_cleanup_mux+0x10/0x10 drivers/tty/n_gsm.c:3124 [n_gsm] __pfx_sched_clock_cpu+0x10/0x10 kernel/sched/clock.c:389 update_load_avg+0x1c1/0x27b0 kernel/sched/fair.c:4500 __pfx_min_vruntime_cb_rotate+0x10/0x10 kernel/sched/fair.c:846 __rb_insert_augmented+0x492/0xbf0 lib/rbtree.c:161 gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] _raw_spin_lock_irqsave+0x92/0xf0 arch/x86/include/asm/atomic.h:107 __pfx_gsmld_ioctl+0x10/0x10 drivers/tty/n_gsm.c:3822 [n_gsm] ktime_get+0x5e/0x140 kernel/time/timekeeping.c:195 ldsem_down_read+0x94/0x4e0 arch/x86/include/asm/atomic64_64.h:79 __pfx_ldsem_down_read+0x10/0x10 drivers/tty/tty_ldsem.c:338 __pfx_do_vfs_ioctl+0x10/0x10 fs/ioctl.c:805 tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 Allocated by task 65: gsm_data_alloc.constprop.0+0x27/0x190 drivers/tty/n_gsm.c:926 [n_gsm] gsm_send+0x2c/0x580 drivers/tty/n_gsm.c:819 [n_gsm] gsm1_receive+0x547/0xad0 drivers/tty/n_gsm.c:3038 [n_gsm] gsmld_receive_buf+0x176/0x280 drivers/tty/n_gsm.c:3609 [n_gsm] tty_ldisc_receive_buf+0x101/0x1e0 drivers/tty/tty_buffer.c:391 tty_port_default_receive_buf+0x61/0xa0 drivers/tty/tty_port.c:39 flush_to_ldisc+0x1b0/0x750 drivers/tty/tty_buffer.c:445 process_scheduled_works+0x2b0/0x10d0 kernel/workqueue.c:3229 worker_thread+0x3dc/0x950 kernel/workqueue.c:3391 kthread+0x2a3/0x370 kernel/kthread.c:389 ret_from_fork+0x2d/0x70 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:257 Freed by task 3367: kfree+0x126/0x420 mm/slub.c:4580 gsm_cleanup_mux+0x36c/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 [Analysis] gsm_msg on the tx_ctrl_list or tx_data_list of gsm_mux can be freed by multi threads through ioctl,which leads to the occurrence of uaf. Protect it by gsm tx lock.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50193", "url": "https://ubuntu.com/security/CVE-2024-50193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/entry_32: Clear CPU buffers after register restore in NMI return CPU buffers are currently cleared after call to exc_nmi, but before register state is restored. This may be okay for MDS mitigation but not for RDFS. Because RDFS mitigation requires CPU buffers to be cleared when registers don't have any sensitive data. Move CLEAR_CPU_BUFFERS after RESTORE_ALL_NMI.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50074", "url": "https://ubuntu.com/security/CVE-2024-50074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: parport: Proper fix for array out-of-bounds access The recent fix for array out-of-bounds accesses replaced sprintf() calls blindly with snprintf(). However, since snprintf() returns the would-be-printed size, not the actually output size, the length calculation can still go over the given limit. Use scnprintf() instead of snprintf(), which returns the actually output letters, for addressing the potential out-of-bounds access properly.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50100", "url": "https://ubuntu.com/security/CVE-2024-50100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: gadget: dummy-hcd: Fix \"task hung\" problem The syzbot fuzzer has been encountering \"task hung\" problems ever since the dummy-hcd driver was changed to use hrtimers instead of regular timers. It turns out that the problems are caused by a subtle difference between the timer_pending() and hrtimer_active() APIs. The changeover blindly replaced the first by the second. However, timer_pending() returns True when the timer is queued but not when its callback is running, whereas hrtimer_active() returns True when the hrtimer is queued _or_ its callback is running. This difference occasionally caused dummy_urb_enqueue() to think that the callback routine had not yet started when in fact it was almost finished. As a result the hrtimer was not restarted, which made it impossible for the driver to dequeue later the URB that was just enqueued. This caused usb_kill_urb() to hang, and things got worse from there. Since hrtimers have no API for telling when they are queued and the callback isn't running, the driver must keep track of this for itself. That's what this patch does, adding a new \"timer_pending\" flag and setting or clearing it at the appropriate times.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50075", "url": "https://ubuntu.com/security/CVE-2024-50075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xhci: tegra: fix checked USB2 port number If USB virtualizatoin is enabled, USB2 ports are shared between all Virtual Functions. The USB2 port number owned by an USB2 root hub in a Virtual Function may be less than total USB2 phy number supported by the Tegra XUSB controller. Using total USB2 phy number as port number to check all PORTSC values would cause invalid memory access. [ 116.923438] Unable to handle kernel paging request at virtual address 006c622f7665642f ... [ 117.213640] Call trace: [ 117.216783] tegra_xusb_enter_elpg+0x23c/0x658 [ 117.222021] tegra_xusb_runtime_suspend+0x40/0x68 [ 117.227260] pm_generic_runtime_suspend+0x30/0x50 [ 117.232847] __rpm_callback+0x84/0x3c0 [ 117.237038] rpm_suspend+0x2dc/0x740 [ 117.241229] pm_runtime_work+0xa0/0xb8 [ 117.245769] process_scheduled_works+0x24c/0x478 [ 117.251007] worker_thread+0x23c/0x328 [ 117.255547] kthread+0x104/0x1b0 [ 117.259389] ret_from_fork+0x10/0x20 [ 117.263582] Code: 54000222 f9461ae8 f8747908 b4ffff48 (f9400100)", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50076", "url": "https://ubuntu.com/security/CVE-2024-50076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vt: prevent kernel-infoleak in con_font_get() font.data may not initialize all memory spaces depending on the implementation of vc->vc_sw->con_font_get. This may cause info-leak, so to prevent this, it is safest to modify it to initialize the allocated memory space to 0, and it generally does not affect the overall performance of the system.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50077", "url": "https://ubuntu.com/security/CVE-2024-50077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix multiple init when debugfs is disabled If bt_debugfs is not created successfully, which happens if either CONFIG_DEBUG_FS or CONFIG_DEBUG_FS_ALLOW_ALL is unset, then iso_init() returns early and does not set iso_inited to true. This means that a subsequent call to iso_init() will result in duplicate calls to proto_register(), bt_sock_register(), etc. With CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, the duplicate call to proto_register() triggers this BUG(): list_add double add: new=ffffffffc0b280d0, prev=ffffffffbab56250, next=ffffffffc0b280d0. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:35! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 2 PID: 887 Comm: bluetoothd Not tainted 6.10.11-1-ao-desktop #1 RIP: 0010:__list_add_valid_or_report+0x9a/0xa0 ... __list_add_valid_or_report+0x9a/0xa0 proto_register+0x2b5/0x340 iso_init+0x23/0x150 [bluetooth] set_iso_socket_func+0x68/0x1b0 [bluetooth] kmem_cache_free+0x308/0x330 hci_sock_sendmsg+0x990/0x9e0 [bluetooth] __sock_sendmsg+0x7b/0x80 sock_write_iter+0x9a/0x110 do_iter_readv_writev+0x11d/0x220 vfs_writev+0x180/0x3e0 do_writev+0xca/0x100 ... This change removes the early return. The check for iso_debugfs being NULL was unnecessary, it is always NULL when iso_inited is false.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50078", "url": "https://ubuntu.com/security/CVE-2024-50078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Call iso_exit() on module unload If iso_init() has been called, iso_exit() must be called on module unload. Without that, the struct proto that iso_init() registered with proto_register() becomes invalid, which could cause unpredictable problems later. In my case, with CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, loading the module again usually triggers this BUG(): list_add corruption. next->prev should be prev (ffffffffb5355fd0), but was 0000000000000068. (next=ffffffffc0a010d0). ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:29! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 4159 Comm: modprobe Not tainted 6.10.11-4+bt2-ao-desktop #1 RIP: 0010:__list_add_valid_or_report+0x61/0xa0 ... __list_add_valid_or_report+0x61/0xa0 proto_register+0x299/0x320 hci_sock_init+0x16/0xc0 [bluetooth] bt_init+0x68/0xd0 [bluetooth] __pfx_bt_init+0x10/0x10 [bluetooth] do_one_initcall+0x80/0x2f0 do_init_module+0x8b/0x230 __do_sys_init_module+0x15f/0x190 do_syscall_64+0x68/0x110 ...", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50198", "url": "https://ubuntu.com/security/CVE-2024-50198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: veml6030: fix IIO device retrieval from embedded device The dev pointer that is received as an argument in the in_illuminance_period_available_show function references the device embedded in the IIO device, not in the i2c client. dev_to_iio_dev() must be used to accessthe right data. The current implementation leads to a segmentation fault on every attempt to read the attribute because indio_dev gets a NULL assignment. This bug has been present since the first appearance of the driver, apparently since the last version (V6) before getting applied. A constant attribute was used until then, and the last modifications might have not been tested again.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50201", "url": "https://ubuntu.com/security/CVE-2024-50201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: Fix encoder->possible_clones Include the encoder itself in its possible_clones bitmask. In the past nothing validated that drivers were populating possible_clones correctly, but that changed in commit 74d2aacbe840 (\"drm: Validate encoder->possible_clones\"). Looks like radeon never got the memo and is still not following the rules 100% correctly. This results in some warnings during driver initialization: Bogus possible_clones: [ENCODER:46:TV-46] possible_clones=0x4 (full encoder mask=0x7) WARNING: CPU: 0 PID: 170 at drivers/gpu/drm/drm_mode_config.c:615 drm_mode_config_validate+0x113/0x39c ... (cherry picked from commit 3b6e7d40649c0d75572039aff9d0911864c689db)", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50098", "url": "https://ubuntu.com/security/CVE-2024-50098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Set SDEV_OFFLINE when UFS is shut down There is a history of deadlock if reboot is performed at the beginning of booting. SDEV_QUIESCE was set for all LU's scsi_devices by UFS shutdown, and at that time the audio driver was waiting on blk_mq_submit_bio() holding a mutex_lock while reading the fw binary. After that, a deadlock issue occurred while audio driver shutdown was waiting for mutex_unlock of blk_mq_submit_bio(). To solve this, set SDEV_OFFLINE for all LUs except WLUN, so that any I/O that comes down after a UFS shutdown will return an error. [ 31.907781]I[0: swapper/0: 0] 1 130705007 1651079834 11289729804 0 D( 2) 3 ffffff882e208000 * init [device_shutdown] [ 31.907793]I[0: swapper/0: 0] Mutex: 0xffffff8849a2b8b0: owner[0xffffff882e28cb00 kworker/6:0 :49] [ 31.907806]I[0: swapper/0: 0] Call trace: [ 31.907810]I[0: swapper/0: 0] __switch_to+0x174/0x338 [ 31.907819]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc [ 31.907826]I[0: swapper/0: 0] schedule+0x7c/0xe8 [ 31.907834]I[0: swapper/0: 0] schedule_preempt_disabled+0x24/0x40 [ 31.907842]I[0: swapper/0: 0] __mutex_lock+0x408/0xdac [ 31.907849]I[0: swapper/0: 0] __mutex_lock_slowpath+0x14/0x24 [ 31.907858]I[0: swapper/0: 0] mutex_lock+0x40/0xec [ 31.907866]I[0: swapper/0: 0] device_shutdown+0x108/0x280 [ 31.907875]I[0: swapper/0: 0] kernel_restart+0x4c/0x11c [ 31.907883]I[0: swapper/0: 0] __arm64_sys_reboot+0x15c/0x280 [ 31.907890]I[0: swapper/0: 0] invoke_syscall+0x70/0x158 [ 31.907899]I[0: swapper/0: 0] el0_svc_common+0xb4/0xf4 [ 31.907909]I[0: swapper/0: 0] do_el0_svc+0x2c/0xb0 [ 31.907918]I[0: swapper/0: 0] el0_svc+0x34/0xe0 [ 31.907928]I[0: swapper/0: 0] el0t_64_sync_handler+0x68/0xb4 [ 31.907937]I[0: swapper/0: 0] el0t_64_sync+0x1a0/0x1a4 [ 31.908774]I[0: swapper/0: 0] 49 0 11960702 11236868007 0 D( 2) 6 ffffff882e28cb00 * kworker/6:0 [__bio_queue_enter] [ 31.908783]I[0: swapper/0: 0] Call trace: [ 31.908788]I[0: swapper/0: 0] __switch_to+0x174/0x338 [ 31.908796]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc [ 31.908803]I[0: swapper/0: 0] schedule+0x7c/0xe8 [ 31.908811]I[0: swapper/0: 0] __bio_queue_enter+0xb8/0x178 [ 31.908818]I[0: swapper/0: 0] blk_mq_submit_bio+0x194/0x67c [ 31.908827]I[0: swapper/0: 0] __submit_bio+0xb8/0x19c", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50079", "url": "https://ubuntu.com/security/CVE-2024-50079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/sqpoll: ensure task state is TASK_RUNNING when running task_work When the sqpoll is exiting and cancels pending work items, it may need to run task_work. If this happens from within io_uring_cancel_generic(), then it may be under waiting for the io_uring_task waitqueue. This results in the below splat from the scheduler, as the ring mutex may be attempted grabbed while in a TASK_INTERRUPTIBLE state. Ensure that the task state is set appropriately for that, just like what is done for the other cases in io_run_task_work(). do not call blocking ops when !TASK_RUNNING; state=1 set at [<0000000029387fd2>] prepare_to_wait+0x88/0x2fc WARNING: CPU: 6 PID: 59939 at kernel/sched/core.c:8561 __might_sleep+0xf4/0x140 Modules linked in: CPU: 6 UID: 0 PID: 59939 Comm: iou-sqp-59938 Not tainted 6.12.0-rc3-00113-g8d020023b155 #7456 Hardware name: linux,dummy-virt (DT) pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : __might_sleep+0xf4/0x140 lr : __might_sleep+0xf4/0x140 sp : ffff80008c5e7830 x29: ffff80008c5e7830 x28: ffff0000d93088c0 x27: ffff60001c2d7230 x26: dfff800000000000 x25: ffff0000e16b9180 x24: ffff80008c5e7a50 x23: 1ffff000118bcf4a x22: ffff0000e16b9180 x21: ffff0000e16b9180 x20: 000000000000011b x19: ffff80008310fac0 x18: 1ffff000118bcd90 x17: 30303c5b20746120 x16: 74657320313d6574 x15: 0720072007200720 x14: 0720072007200720 x13: 0720072007200720 x12: ffff600036c64f0b x11: 1fffe00036c64f0a x10: ffff600036c64f0a x9 : dfff800000000000 x8 : 00009fffc939b0f6 x7 : ffff0001b6327853 x6 : 0000000000000001 x5 : ffff0001b6327850 x4 : ffff600036c64f0b x3 : ffff8000803c35bc x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000e16b9180 Call trace: __might_sleep+0xf4/0x140 mutex_lock+0x84/0x124 io_handle_tw_list+0xf4/0x260 tctx_task_work_run+0x94/0x340 io_run_task_work+0x1ec/0x3c0 io_uring_cancel_generic+0x364/0x524 io_sq_thread+0x820/0x124c ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50080", "url": "https://ubuntu.com/security/CVE-2024-50080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: don't allow user copy for unprivileged device UBLK_F_USER_COPY requires userspace to call write() on ublk char device for filling request buffer, and unprivileged device can't be trusted. So don't allow user copy for unprivileged device.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50081", "url": "https://ubuntu.com/security/CVE-2024-50081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-mq: setup queue ->tag_set before initializing hctx Commit 7b815817aa58 (\"blk-mq: add helper for checking if one CPU is mapped to specified hctx\") needs to check queue mapping via tag set in hctx's cpuhp handler. However, q->tag_set may not be setup yet when the cpuhp handler is enabled, then kernel oops is triggered. Fix the issue by setup queue tag_set before initializing hctx.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50082", "url": "https://ubuntu.com/security/CVE-2024-50082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race We're seeing crashes from rq_qos_wake_function that look like this: BUG: unable to handle page fault for address: ffffafe180a40084 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 100000067 P4D 100000067 PUD 10027c067 PMD 10115d067 PTE 0 Oops: Oops: 0002 [#1] PREEMPT SMP PTI CPU: 17 UID: 0 PID: 0 Comm: swapper/17 Not tainted 6.12.0-rc3-00013-geca631b8fe80 #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:_raw_spin_lock_irqsave+0x1d/0x40 Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 9c 41 5c fa 65 ff 05 62 97 30 4c 31 c0 ba 01 00 00 00 0f b1 17 75 0a 4c 89 e0 41 5c c3 cc cc cc cc 89 c6 e8 2c 0b 00 RSP: 0018:ffffafe180580ca0 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffffafe180a3f7a8 RCX: 0000000000000011 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffffafe180a40084 RBP: 0000000000000000 R08: 00000000001e7240 R09: 0000000000000011 R10: 0000000000000028 R11: 0000000000000888 R12: 0000000000000002 R13: ffffafe180a40084 R14: 0000000000000000 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff9aaf1f280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffafe180a40084 CR3: 000000010e428002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: try_to_wake_up+0x5a/0x6a0 rq_qos_wake_function+0x71/0x80 __wake_up_common+0x75/0xa0 __wake_up+0x36/0x60 scale_up.part.0+0x50/0x110 wb_timer_fn+0x227/0x450 ... So rq_qos_wake_function() calls wake_up_process(data->task), which calls try_to_wake_up(), which faults in raw_spin_lock_irqsave(&p->pi_lock). p comes from data->task, and data comes from the waitqueue entry, which is stored on the waiter's stack in rq_qos_wait(). Analyzing the core dump with drgn, I found that the waiter had already woken up and moved on to a completely unrelated code path, clobbering what was previously data->task. Meanwhile, the waker was passing the clobbered garbage in data->task to wake_up_process(), leading to the crash. What's happening is that in between rq_qos_wake_function() deleting the waitqueue entry and calling wake_up_process(), rq_qos_wait() is finding that it already got a token and returning. The race looks like this: rq_qos_wait() rq_qos_wake_function() ============================================================== prepare_to_wait_exclusive() data->got_token = true; list_del_init(&curr->entry); if (data.got_token) break; finish_wait(&rqw->wait, &data.wq); ^- returns immediately because list_empty_careful(&wq_entry->entry) is true ... return, go do something else ... wake_up_process(data->task) (NO LONGER VALID!)-^ Normally, finish_wait() is supposed to synchronize against the waker. But, as noted above, it is returning immediately because the waitqueue entry has already been removed from the waitqueue. The bug is that rq_qos_wake_function() is accessing the waitqueue entry AFTER deleting it. Note that autoremove_wake_function() wakes the waiter and THEN deletes the waitqueue entry, which is the proper order. Fix it by swapping the order. We also need to use list_del_init_careful() to match the list_empty_careful() in finish_wait().", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50101", "url": "https://ubuntu.com/security/CVE-2024-50101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI devices Previously, the domain_context_clear() function incorrectly called pci_for_each_dma_alias() to set up context entries for non-PCI devices. This could lead to kernel hangs or other unexpected behavior. Add a check to only call pci_for_each_dma_alias() for PCI devices. For non-PCI devices, domain_context_clear_one() is called directly.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50083", "url": "https://ubuntu.com/security/CVE-2024-50083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix mptcp DSS corruption due to large pmtu xmit Syzkaller was able to trigger a DSS corruption: TCP: request_sock_subflow_v4: Possible SYN flooding on port [::]:20002. Sending cookies. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 5227 at net/mptcp/protocol.c:695 __mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695 Modules linked in: CPU: 0 UID: 0 PID: 5227 Comm: syz-executor350 Not tainted 6.11.0-syzkaller-08829-gaf9c191ac2a0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:__mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695 Code: 0f b6 dc 31 ff 89 de e8 b5 dd ea f5 89 d8 48 81 c4 50 01 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 98 da ea f5 90 <0f> 0b 90 e9 47 ff ff ff e8 8a da ea f5 90 0f 0b 90 e9 99 e0 ff ff RSP: 0018:ffffc90000006db8 EFLAGS: 00010246 RAX: ffffffff8ba9df18 RBX: 00000000000055f0 RCX: ffff888030023c00 RDX: 0000000000000100 RSI: 00000000000081e5 RDI: 00000000000055f0 RBP: 1ffff110062bf1ae R08: ffffffff8ba9cf12 R09: 1ffff110062bf1b8 R10: dffffc0000000000 R11: ffffed10062bf1b9 R12: 0000000000000000 R13: dffffc0000000000 R14: 00000000700cec61 R15: 00000000000081e5 FS: 000055556679c380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020287000 CR3: 0000000077892000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: move_skbs_to_msk net/mptcp/protocol.c:811 [inline] mptcp_data_ready+0x29c/0xa90 net/mptcp/protocol.c:854 subflow_data_ready+0x34a/0x920 net/mptcp/subflow.c:1490 tcp_data_queue+0x20fd/0x76c0 net/ipv4/tcp_input.c:5283 tcp_rcv_established+0xfba/0x2020 net/ipv4/tcp_input.c:6237 tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915 tcp_v4_rcv+0x2dc0/0x37f0 net/ipv4/tcp_ipv4.c:2350 ip_protocol_deliver_rcu+0x22e/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x341/0x5f0 net/ipv4/ip_input.c:233 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314 __netif_receive_skb_one_core net/core/dev.c:5662 [inline] __netif_receive_skb+0x2bf/0x650 net/core/dev.c:5775 process_backlog+0x662/0x15b0 net/core/dev.c:6107 __napi_poll+0xcb/0x490 net/core/dev.c:6771 napi_poll net/core/dev.c:6840 [inline] net_rx_action+0x89b/0x1240 net/core/dev.c:6962 handle_softirqs+0x2c5/0x980 kernel/softirq.c:554 do_softirq+0x11b/0x1e0 kernel/softirq.c:455 __local_bh_enable_ip+0x1bb/0x200 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0x1764/0x3e80 net/core/dev.c:4451 dev_queue_xmit include/linux/netdevice.h:3094 [inline] neigh_hh_output include/net/neighbour.h:526 [inline] neigh_output include/net/neighbour.h:540 [inline] ip_finish_output2+0xd41/0x1390 net/ipv4/ip_output.c:236 ip_local_out net/ipv4/ip_output.c:130 [inline] __ip_queue_xmit+0x118c/0x1b80 net/ipv4/ip_output.c:536 __tcp_transmit_skb+0x2544/0x3b30 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_mtu_probe net/ipv4/tcp_output.c:2547 [inline] tcp_write_xmit+0x641d/0x6bf0 net/ipv4/tcp_output.c:2752 __tcp_push_pending_frames+0x9b/0x360 net/ipv4/tcp_output.c:3015 tcp_push_pending_frames include/net/tcp.h:2107 [inline] tcp_data_snd_check net/ipv4/tcp_input.c:5714 [inline] tcp_rcv_established+0x1026/0x2020 net/ipv4/tcp_input.c:6239 tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915 sk_backlog_rcv include/net/sock.h:1113 [inline] __release_sock+0x214/0x350 net/core/sock.c:3072 release_sock+0x61/0x1f0 net/core/sock.c:3626 mptcp_push_ ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50068", "url": "https://ubuntu.com/security/CVE-2024-50068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/tests/sysfs-kunit.h: fix memory leak in damon_sysfs_test_add_targets() The sysfs_target->regions allocated in damon_sysfs_regions_alloc() is not freed in damon_sysfs_test_add_targets(), which cause the following memory leak, free it to fix it. \tunreferenced object 0xffffff80c2a8db80 (size 96): \t comm \"kunit_try_catch\", pid 187, jiffies 4294894363 \t hex dump (first 32 bytes): \t 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ \t 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ \t backtrace (crc 0): \t [<0000000001e3714d>] kmemleak_alloc+0x34/0x40 \t [<000000008e6835c1>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000001286d9f8>] damon_sysfs_test_add_targets+0x1cc/0x738 \t [<0000000032ef8f77>] kunit_try_run_case+0x13c/0x3ac \t [<00000000f3edea23>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000adf936cf>] kthread+0x2e8/0x374 \t [<0000000041bb1628>] ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50199", "url": "https://ubuntu.com/security/CVE-2024-50199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/swapfile: skip HugeTLB pages for unuse_vma I got a bad pud error and lost a 1GB HugeTLB when calling swapoff. The problem can be reproduced by the following steps: 1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory. 2. Swapout the above anonymous memory. 3. run swapoff and we will get a bad pud error in kernel message: mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7) We can tell that pud_clear_bad is called by pud_none_or_clear_bad in unuse_pud_range() by ftrace. And therefore the HugeTLB pages will never be freed because we lost it from page table. We can skip HugeTLB pages for unuse_vma to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50066", "url": "https://ubuntu.com/security/CVE-2024-50066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mremap: fix move_normal_pmd/retract_page_tables race In mremap(), move_page_tables() looks at the type of the PMD entry and the specified address range to figure out by which method the next chunk of page table entries should be moved. At that point, the mmap_lock is held in write mode, but no rmap locks are held yet. For PMD entries that point to page tables and are fully covered by the source address range, move_pgt_entry(NORMAL_PMD, ...) is called, which first takes rmap locks, then does move_normal_pmd(). move_normal_pmd() takes the necessary page table locks at source and destination, then moves an entire page table from the source to the destination. The problem is: The rmap locks, which protect against concurrent page table removal by retract_page_tables() in the THP code, are only taken after the PMD entry has been read and it has been decided how to move it. So we can race as follows (with two processes that have mappings of the same tmpfs file that is stored on a tmpfs mount with huge=advise); note that process A accesses page tables through the MM while process B does it through the file rmap: process A process B ========= ========= mremap mremap_to move_vma move_page_tables get_old_pmd alloc_new_pmd *** PREEMPT *** madvise(MADV_COLLAPSE) do_madvise madvise_walk_vmas madvise_vma_behavior madvise_collapse hpage_collapse_scan_file collapse_file retract_page_tables i_mmap_lock_read(mapping) pmdp_collapse_flush i_mmap_unlock_read(mapping) move_pgt_entry(NORMAL_PMD, ...) take_rmap_locks move_normal_pmd drop_rmap_locks When this happens, move_normal_pmd() can end up creating bogus PMD entries in the line `pmd_populate(mm, new_pmd, pmd_pgtable(pmd))`. The effect depends on arch-specific and machine-specific details; on x86, you can end up with physical page 0 mapped as a page table, which is likely exploitable for user->kernel privilege escalation. Fix the race by letting process B recheck that the PMD still points to a page table after the rmap locks have been taken. Otherwise, we bail and let the caller fall back to the PTE-level copying path, which will then bail immediately at the pmd_none() check. Bug reachability: Reaching this bug requires that you can create shmem/file THP mappings - anonymous THP uses different code that doesn't zap stuff under rmap locks. File THP is gated on an experimental config flag (CONFIG_READ_ONLY_THP_FOR_FS), so on normal distro kernels you need shmem THP to hit this bug. As far as I know, getting shmem THP normally requires that you can mount your own tmpfs with the right mount flags, which would require creating your own user+mount namespace; though I don't know if some distros maybe enable shmem THP by default or something like that. Bug impact: This issue can likely be used for user->kernel privilege escalation when it is reachable.", "cve_priority": "medium", "cve_public_date": "2024-10-23 06:15:00 UTC" }, { "cve": "CVE-2024-50202", "url": "https://ubuntu.com/security/CVE-2024-50202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: propagate directory read errors from nilfs_find_entry() Syzbot reported that a task hang occurs in vcs_open() during a fuzzing test for nilfs2. The root cause of this problem is that in nilfs_find_entry(), which searches for directory entries, ignores errors when loading a directory page/folio via nilfs_get_folio() fails. If the filesystem images is corrupted, and the i_size of the directory inode is large, and the directory page/folio is successfully read but fails the sanity check, for example when it is zero-filled, nilfs_check_folio() may continue to spit out error messages in bursts. Fix this issue by propagating the error to the callers when loading a page/folio fails in nilfs_find_entry(). The current interface of nilfs_find_entry() and its callers is outdated and cannot propagate error codes such as -EIO and -ENOMEM returned via nilfs_find_entry(), so fix it together.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50200", "url": "https://ubuntu.com/security/CVE-2024-50200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: maple_tree: correct tree corruption on spanning store Patch series \"maple_tree: correct tree corruption on spanning store\", v3. There has been a nasty yet subtle maple tree corruption bug that appears to have been in existence since the inception of the algorithm. This bug seems far more likely to happen since commit f8d112a4e657 (\"mm/mmap: avoid zeroing vma tree in mmap_region()\"), which is the point at which reports started to be submitted concerning this bug. We were made definitely aware of the bug thanks to the kind efforts of Bert Karwatzki who helped enormously in my being able to track this down and identify the cause of it. The bug arises when an attempt is made to perform a spanning store across two leaf nodes, where the right leaf node is the rightmost child of the shared parent, AND the store completely consumes the right-mode node. This results in mas_wr_spanning_store() mitakenly duplicating the new and existing entries at the maximum pivot within the range, and thus maple tree corruption. The fix patch corrects this by detecting this scenario and disallowing the mistaken duplicate copy. The fix patch commit message goes into great detail as to how this occurs. This series also includes a test which reliably reproduces the issue, and asserts that the fix works correctly. Bert has kindly tested the fix and confirmed it resolved his issues. Also Mikhail Gavrilov kindly reported what appears to be precisely the same bug, which this fix should also resolve. This patch (of 2): There has been a subtle bug present in the maple tree implementation from its inception. This arises from how stores are performed - when a store occurs, it will overwrite overlapping ranges and adjust the tree as necessary to accommodate this. A range may always ultimately span two leaf nodes. In this instance we walk the two leaf nodes, determine which elements are not overwritten to the left and to the right of the start and end of the ranges respectively and then rebalance the tree to contain these entries and the newly inserted one. This kind of store is dubbed a 'spanning store' and is implemented by mas_wr_spanning_store(). In order to reach this stage, mas_store_gfp() invokes mas_wr_preallocate(), mas_wr_store_type() and mas_wr_walk() in turn to walk the tree and update the object (mas) to traverse to the location where the write should be performed, determining its store type. When a spanning store is required, this function returns false stopping at the parent node which contains the target range, and mas_wr_store_type() marks the mas->store_type as wr_spanning_store to denote this fact. When we go to perform the store in mas_wr_spanning_store(), we first determine the elements AFTER the END of the range we wish to store (that is, to the right of the entry to be inserted) - we do this by walking to the NEXT pivot in the tree (i.e. r_mas.last + 1), starting at the node we have just determined contains the range over which we intend to write. We then turn our attention to the entries to the left of the entry we are inserting, whose state is represented by l_mas, and copy these into a 'big node', which is a special node which contains enough slots to contain two leaf node's worth of data. We then copy the entry we wish to store immediately after this - the copy and the insertion of the new entry is performed by mas_store_b_node(). After this we copy the elements to the right of the end of the range which we are inserting, if we have not exceeded the length of the node (i.e. r_mas.offset <= r_mas.end). Herein lies the bug - under very specific circumstances, this logic can break and corrupt the maple tree. Consider the following tree: Height 0 Root Node / \\ pivot = 0xffff / \\ pivot = ULONG_MAX / ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50084", "url": "https://ubuntu.com/security/CVE-2024-50084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: microchip: vcap api: Fix memory leaks in vcap_api_encode_rule_test() Commit a3c1e45156ad (\"net: microchip: vcap: Fix use-after-free error in kunit test\") fixed the use-after-free error, but introduced below memory leaks by removing necessary vcap_free_rule(), add it to fix it. \tunreferenced object 0xffffff80ca58b700 (size 192): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898264 \t hex dump (first 32 bytes): \t 00 12 7a 00 05 00 00 00 0a 00 00 00 64 00 00 00 ..z.........d... \t 00 00 00 00 00 00 00 00 00 04 0b cc 80 ff ff ff ................ \t backtrace (crc 9c09c3fe): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<0000000040a01b8d>] vcap_alloc_rule+0x3cc/0x9c4 \t [<000000003fe86110>] vcap_api_encode_rule_test+0x1ac/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0400 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898265 \t hex dump (first 32 bytes): \t 80 04 0b cc 80 ff ff ff 18 b7 58 ca 80 ff ff ff ..........X..... \t 39 00 00 00 02 00 00 00 06 05 04 03 02 01 ff ff 9............... \t backtrace (crc daf014e9): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<00000000dfdb1e81>] vcap_api_encode_rule_test+0x224/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0700 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898265 \t hex dump (first 32 bytes): \t 80 07 0b cc 80 ff ff ff 28 b7 58 ca 80 ff ff ff ........(.X..... \t 3c 00 00 00 00 00 00 00 01 2f 03 b3 ec ff ff ff <......../...... \t backtrace (crc 8d877792): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000006eadfab7>] vcap_rule_add_action+0x2d0/0x52c \t [<00000000323475d1>] vcap_api_encode_rule_test+0x4d4/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0900 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898266 \t hex dump (first 32 bytes): \t 80 09 0b cc 80 ff ff ff 80 06 0b cc 80 ff ff ff ................ \t 7d 00 00 00 01 00 00 00 00 00 00 00 ff 00 00 00 }............... \t backtrace (crc 34181e56): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<00000000991e3564>] vcap_val_rule+0xcf0/0x13e8 \t [<00000000fc9868e5>] vcap_api_encode_rule_test+0x678/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0980 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898266 \t hex dump (first 32 bytes): \t 18 b7 58 ca 80 ff ff ff 00 09 0b cc 80 ff ff ff ..X............. \t 67 00 00 00 00 00 00 00 01 01 74 88 c0 ff ff ff g.........t..... \t backtrace (crc 275fd9be): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<000000001396a1a2>] test_add_de ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50194", "url": "https://ubuntu.com/security/CVE-2024-50194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Fix uprobes for big-endian kernels The arm64 uprobes code is broken for big-endian kernels as it doesn't convert the in-memory instruction encoding (which is always little-endian) into the kernel's native endianness before analyzing and simulating instructions. This may result in a few distinct problems: * The kernel may may erroneously reject probing an instruction which can safely be probed. * The kernel may erroneously erroneously permit stepping an instruction out-of-line when that instruction cannot be stepped out-of-line safely. * The kernel may erroneously simulate instruction incorrectly dur to interpretting the byte-swapped encoding. The endianness mismatch isn't caught by the compiler or sparse because: * The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so the compiler and sparse have no idea these contain a little-endian 32-bit value. The core uprobes code populates these with a memcpy() which similarly does not handle endianness. * While the uprobe_opcode_t type is an alias for __le32, both arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[] to the similarly-named probe_opcode_t, which is an alias for u32. Hence there is no endianness conversion warning. Fix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and adding the appropriate __le32_to_cpu() conversions prior to consuming the instruction encoding. The core uprobes copies these fields as opaque ranges of bytes, and so is unaffected by this change. At the same time, remove MAX_UINSN_BYTES and consistently use AARCH64_INSN_SIZE for clarity. Tested with the following: | #include | #include | | #define noinline __attribute__((noinline)) | | static noinline void *adrp_self(void) | { | void *addr; | | asm volatile( | \" adrp %x0, adrp_self\\n\" | \" add %x0, %x0, :lo12:adrp_self\\n\" | : \"=r\" (addr)); | } | | | int main(int argc, char *argv) | { | void *ptr = adrp_self(); | bool equal = (ptr == adrp_self); | | printf(\"adrp_self => %p\\n\" | \"adrp_self() => %p\\n\" | \"%s\\n\", | adrp_self, ptr, equal ? \"EQUAL\" : \"NOT EQUAL\"); | | return 0; | } .... where the adrp_self() function was compiled to: | 00000000004007e0 : | 4007e0: 90000000 adrp x0, 400000 <__ehdr_start> | 4007e4: 911f8000 add x0, x0, #0x7e0 | 4007e8: d65f03c0 ret Before this patch, the ADRP is not recognized, and is assumed to be steppable, resulting in corruption of the result: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0xffffffffff7e0 | NOT EQUAL After this patch, the ADRP is correctly recognized and simulated: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50099", "url": "https://ubuntu.com/security/CVE-2024-50099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Remove broken LDR (literal) uprobe support The simulate_ldr_literal() and simulate_ldrsw_literal() functions are unsafe to use for uprobes. Both functions were originally written for use with kprobes, and access memory with plain C accesses. When uprobes was added, these were reused unmodified even though they cannot safely access user memory. There are three key problems: 1) The plain C accesses do not have corresponding extable entries, and thus if they encounter a fault the kernel will treat these as unintentional accesses to user memory, resulting in a BUG() which will kill the kernel thread, and likely lead to further issues (e.g. lockup or panic()). 2) The plain C accesses are subject to HW PAN and SW PAN, and so when either is in use, any attempt to simulate an access to user memory will fault. Thus neither simulate_ldr_literal() nor simulate_ldrsw_literal() can do anything useful when simulating a user instruction on any system with HW PAN or SW PAN. 3) The plain C accesses are privileged, as they run in kernel context, and in practice can access a small range of kernel virtual addresses. The instructions they simulate have a range of +/-1MiB, and since the simulated instructions must itself be a user instructions in the TTBR0 address range, these can address the final 1MiB of the TTBR1 acddress range by wrapping downwards from an address in the first 1MiB of the TTBR0 address range. In contemporary kernels the last 8MiB of TTBR1 address range is reserved, and accesses to this will always fault, meaning this is no worse than (1). Historically, it was theoretically possible for the linear map or vmemmap to spill into the final 8MiB of the TTBR1 address range, but in practice this is extremely unlikely to occur as this would require either: * Having enough physical memory to fill the entire linear map all the way to the final 1MiB of the TTBR1 address range. * Getting unlucky with KASLR randomization of the linear map such that the populated region happens to overlap with the last 1MiB of the TTBR address range. ... and in either case if we were to spill into the final page there would be larger problems as the final page would alias with error pointers. Practically speaking, (1) and (2) are the big issues. Given there have been no reports of problems since the broken code was introduced, it appears that no-one is relying on probing these instructions with uprobes. Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW (literal), limiting the use of simulate_ldr_literal() and simulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR (literal) and LDRSW (literal) will be rejected as arm_probe_decode_insn() will return INSN_REJECTED. In future we can consider introducing working uprobes support for these instructions, but this will require more significant work.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50195", "url": "https://ubuntu.com/security/CVE-2024-50195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-clock: Fix missing timespec64 check in pc_clock_settime() As Andrew pointed out, it will make sense that the PTP core checked timespec64 struct's tv_sec and tv_nsec range before calling ptp->info->settime64(). As the man manual of clock_settime() said, if tp.tv_sec is negative or tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL, which include dynamic clocks which handles PTP clock, and the condition is consistent with timespec64_valid(). As Thomas suggested, timespec64_valid() only check the timespec is valid, but not ensure that the time is in a valid range, so check it ahead using timespec64_valid_strict() in pc_clock_settime() and return -EINVAL if not valid. There are some drivers that use tp->tv_sec and tp->tv_nsec directly to write registers without validity checks and assume that the higher layer has checked it, which is dangerous and will benefit from this, such as hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(), and some drivers can remove the checks of itself.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50085", "url": "https://ubuntu.com/security/CVE-2024-50085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: fix UaF read in mptcp_pm_nl_rm_addr_or_subflow Syzkaller reported this splat: ================================================================== BUG: KASAN: slab-use-after-free in mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881 Read of size 4 at addr ffff8880569ac858 by task syz.1.2799/14662 CPU: 0 UID: 0 PID: 14662 Comm: syz.1.2799 Not tainted 6.12.0-rc2-syzkaller-00307-g36c254515dc6 #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+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881 mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:914 [inline] mptcp_nl_remove_id_zero_address+0x305/0x4a0 net/mptcp/pm_netlink.c:1572 mptcp_pm_nl_del_addr_doit+0x5c9/0x770 net/mptcp/pm_netlink.c:1603 genl_family_rcv_msg_doit+0x202/0x2f0 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x565/0x800 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x165/0x410 net/netlink/af_netlink.c:2551 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1331 [inline] netlink_unicast+0x53c/0x7f0 net/netlink/af_netlink.c:1357 netlink_sendmsg+0x8b8/0xd70 net/netlink/af_netlink.c:1901 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg net/socket.c:744 [inline] ____sys_sendmsg+0x9ae/0xb40 net/socket.c:2607 ___sys_sendmsg+0x135/0x1e0 net/socket.c:2661 __sys_sendmsg+0x117/0x1f0 net/socket.c:2690 do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline] __do_fast_syscall_32+0x73/0x120 arch/x86/entry/common.c:386 do_fast_syscall_32+0x32/0x80 arch/x86/entry/common.c:411 entry_SYSENTER_compat_after_hwframe+0x84/0x8e RIP: 0023:0xf7fe4579 Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00 RSP: 002b:00000000f574556c EFLAGS: 00000296 ORIG_RAX: 0000000000000172 RAX: ffffffffffffffda RBX: 000000000000000b RCX: 0000000020000140 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000296 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Allocated by task 5387: 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 kmalloc_noprof include/linux/slab.h:878 [inline] kzalloc_noprof include/linux/slab.h:1014 [inline] subflow_create_ctx+0x87/0x2a0 net/mptcp/subflow.c:1803 subflow_ulp_init+0xc3/0x4d0 net/mptcp/subflow.c:1956 __tcp_set_ulp net/ipv4/tcp_ulp.c:146 [inline] tcp_set_ulp+0x326/0x7f0 net/ipv4/tcp_ulp.c:167 mptcp_subflow_create_socket+0x4ae/0x10a0 net/mptcp/subflow.c:1764 __mptcp_subflow_connect+0x3cc/0x1490 net/mptcp/subflow.c:1592 mptcp_pm_create_subflow_or_signal_addr+0xbda/0x23a0 net/mptcp/pm_netlink.c:642 mptcp_pm_nl_fully_established net/mptcp/pm_netlink.c:650 [inline] mptcp_pm_nl_work+0x3a1/0x4f0 net/mptcp/pm_netlink.c:943 mptcp_worker+0x15a/0x1240 net/mptcp/protocol.c:2777 process_one_work+0x958/0x1b30 kernel/workqueue.c:3229 process_scheduled_works kernel/workqueue.c:3310 [inline] worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/ke ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50086", "url": "https://ubuntu.com/security/CVE-2024-50086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix user-after-free from session log off There is racy issue between smb2 session log off and smb2 session setup. It will cause user-after-free from session log off. This add session_lock when setting SMB2_SESSION_EXPIRED and referece count to session struct not to free session while it is being used.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50087", "url": "https://ubuntu.com/security/CVE-2024-50087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix uninitialized pointer free on read_alloc_one_name() error The function read_alloc_one_name() does not initialize the name field of the passed fscrypt_str struct if kmalloc fails to allocate the corresponding buffer. Thus, it is not guaranteed that fscrypt_str.name is initialized when freeing it. This is a follow-up to the linked patch that fixes the remaining instances of the bug introduced by commit e43eec81c516 (\"btrfs: use struct qstr instead of name and namelen pairs\").", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50088", "url": "https://ubuntu.com/security/CVE-2024-50088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix uninitialized pointer free in add_inode_ref() The add_inode_ref() function does not initialize the \"name\" struct when it is declared. If any of the following calls to \"read_one_inode() returns NULL, \tdir = read_one_inode(root, parent_objectid); \tif (!dir) { \t\tret = -ENOENT; \t\tgoto out; \t} \tinode = read_one_inode(root, inode_objectid); \tif (!inode) { \t\tret = -EIO; \t\tgoto out; \t} then \"name.name\" would be freed on \"out\" before being initialized. out: \t... \tkfree(name.name); This issue was reported by Coverity with CID 1526744.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50182", "url": "https://ubuntu.com/security/CVE-2024-50182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: secretmem: disable memfd_secret() if arch cannot set direct map Return -ENOSYS from memfd_secret() syscall if !can_set_direct_map(). This is the case for example on some arm64 configurations, where marking 4k PTEs in the direct map not present can only be done if the direct map is set up at 4k granularity in the first place (as ARM's break-before-make semantics do not easily allow breaking apart large/gigantic pages). More precisely, on arm64 systems with !can_set_direct_map(), set_direct_map_invalid_noflush() is a no-op, however it returns success (0) instead of an error. This means that memfd_secret will seemingly \"work\" (e.g. syscall succeeds, you can mmap the fd and fault in pages), but it does not actually achieve its goal of removing its memory from the direct map. Note that with this patch, memfd_secret() will start erroring on systems where can_set_direct_map() returns false (arm64 with CONFIG_RODATA_FULL_DEFAULT_ENABLED=n, CONFIG_DEBUG_PAGEALLOC=n and CONFIG_KFENCE=n), but that still seems better than the current silent failure. Since CONFIG_RODATA_FULL_DEFAULT_ENABLED defaults to 'y', most arm64 systems actually have a working memfd_secret() and aren't be affected. From going through the iterations of the original memfd_secret patch series, it seems that disabling the syscall in these scenarios was the intended behavior [1] (preferred over having set_direct_map_invalid_noflush return an error as that would result in SIGBUSes at page-fault time), however the check for it got dropped between v16 [2] and v17 [3], when secretmem moved away from CMA allocations. [1]: https://lore.kernel.org/lkml/20201124164930.GK8537@kernel.org/ [2]: https://lore.kernel.org/lkml/20210121122723.3446-11-rppt@kernel.org/#t [3]: https://lore.kernel.org/lkml/20201125092208.12544-10-rppt@kernel.org/", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50019", "url": "https://ubuntu.com/security/CVE-2024-50019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kthread: unpark only parked kthread Calling into kthread unparking unconditionally is mostly harmless when the kthread is already unparked. The wake up is then simply ignored because the target is not in TASK_PARKED state. However if the kthread is per CPU, the wake up is preceded by a call to kthread_bind() which expects the task to be inactive and in TASK_PARKED state, which obviously isn't the case if it is unparked. As a result, calling kthread_stop() on an unparked per-cpu kthread triggers such a warning: \tWARNING: CPU: 0 PID: 11 at kernel/kthread.c:525 __kthread_bind_mask kernel/kthread.c:525 \t \t kthread_stop+0x17a/0x630 kernel/kthread.c:707 \t destroy_workqueue+0x136/0xc40 kernel/workqueue.c:5810 \t wg_destruct+0x1e2/0x2e0 drivers/net/wireguard/device.c:257 \t netdev_run_todo+0xe1a/0x1000 net/core/dev.c:10693 \t default_device_exit_batch+0xa14/0xa90 net/core/dev.c:11769 \t ops_exit_list net/core/net_namespace.c:178 [inline] \t cleanup_net+0x89d/0xcc0 net/core/net_namespace.c:640 \t process_one_work kernel/workqueue.c:3231 [inline] \t process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 \t worker_thread+0x86d/0xd70 kernel/workqueue.c:3393 \t kthread+0x2f0/0x390 kernel/kthread.c:389 \t ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 \t ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 \t Fix this with skipping unecessary unparking while stopping a kthread.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50096", "url": "https://ubuntu.com/security/CVE-2024-50096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/dmem: Fix vulnerability in migrate_to_ram upon copy error The `nouveau_dmem_copy_one` function ensures that the copy push command is sent to the device firmware but does not track whether it was executed successfully. In the case of a copy error (e.g., firmware or hardware failure), the copy push command will be sent via the firmware channel, and `nouveau_dmem_copy_one` will likely report success, leading to the `migrate_to_ram` function returning a dirty HIGH_USER page to the user. This can result in a security vulnerability, as a HIGH_USER page that may contain sensitive or corrupted data could be returned to the user. To prevent this vulnerability, we allocate a zero page. Thus, in case of an error, a non-dirty (zero) page will be returned to the user.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50020", "url": "https://ubuntu.com/security/CVE-2024-50020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix improper handling of refcount in ice_sriov_set_msix_vec_count() This patch addresses an issue with improper reference count handling in the ice_sriov_set_msix_vec_count() function. First, the function calls ice_get_vf_by_id(), which increments the reference count of the vf pointer. If the subsequent call to ice_get_vf_vsi() fails, the function currently returns an error without decrementing the reference count of the vf pointer, leading to a reference count leak. The correct behavior, as implemented in this patch, is to decrement the reference count using ice_put_vf(vf) before returning an error when vsi is NULL. Second, the function calls ice_sriov_get_irqs(), which sets vf->first_vector_idx. If this call returns a negative value, indicating an error, the function returns an error without decrementing the reference count of the vf pointer, resulting in another reference count leak. The patch addresses this by adding a call to ice_put_vf(vf) before returning an error when vf->first_vector_idx < 0. This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and identifying potential mismanagement of reference counts. In this case, the tool flagged the missing decrement operation as a potential issue, leading to this patch.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50021", "url": "https://ubuntu.com/security/CVE-2024-50021", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix improper handling of refcount in ice_dpll_init_rclk_pins() This patch addresses a reference count handling issue in the ice_dpll_init_rclk_pins() function. The function calls ice_dpll_get_pins(), which increments the reference count of the relevant resources. However, if the condition WARN_ON((!vsi || !vsi->netdev)) is met, the function currently returns an error without properly releasing the resources acquired by ice_dpll_get_pins(), leading to a reference count leak. To resolve this, the check has been moved to the top of the function. This ensures that the function verifies the state before any resources are acquired, avoiding the need for additional resource management in the error path. This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and detecting potential issues where resources are not properly managed. In this case, the tool flagged the missing release operation as a potential problem, which led to the development of this patch.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50022", "url": "https://ubuntu.com/security/CVE-2024-50022", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: device-dax: correct pgoff align in dax_set_mapping() pgoff should be aligned using ALIGN_DOWN() instead of ALIGN(). Otherwise, vmf->address not aligned to fault_size will be aligned to the next alignment, that can result in memory failure getting the wrong address. It's a subtle situation that only can be observed in page_mapped_in_vma() after the page is page fault handled by dev_dax_huge_fault. Generally, there is little chance to perform page_mapped_in_vma in dev-dax's page unless in specific error injection to the dax device to trigger an MCE - memory-failure. In that case, page_mapped_in_vma() will be triggered to determine which task is accessing the failure address and kill that task in the end. We used self-developed dax device (which is 2M aligned mapping) , to perform error injection to random address. It turned out that error injected to non-2M-aligned address was causing endless MCE until panic. Because page_mapped_in_vma() kept resulting wrong address and the task accessing the failure address was never killed properly: [ 3783.719419] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.049006] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.049190] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.448042] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.448186] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.792026] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.792179] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.162502] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.162633] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.461116] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.461247] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.764730] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.764859] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.042128] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.042259] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.464293] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.464423] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.818090] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.818217] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3787.085297] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3787.085424] Memory failure: 0x200c9742: recovery action for dax page: Recovered It took us several weeks to pinpoint this problem,  but we eventually used bpftrace to trace the page fault and mce address and successfully identified the issue. Joao added: ; Likely we never reproduce in production because we always pin : device-dax regions in the region align they provide (Qemu does : similarly with prealloc in hugetlb/file backed memory). I think this : bug requires that we touch *unpinned* device-dax regions unaligned to : the device-dax selected alignment (page size i.e. 4K/2M/1G)", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50185", "url": "https://ubuntu.com/security/CVE-2024-50185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: handle consistently DSS corruption Bugged peer implementation can send corrupted DSS options, consistently hitting a few warning in the data path. Use DEBUG_NET assertions, to avoid the splat on some builds and handle consistently the error, dumping related MIBs and performing fallback and/or reset according to the subflow type.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50023", "url": "https://ubuntu.com/security/CVE-2024-50023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: Remove LED entry from LEDs list on unregister Commit c938ab4da0eb (\"net: phy: Manual remove LEDs to ensure correct ordering\") correctly fixed a problem with using devm_ but missed removing the LED entry from the LEDs list. This cause kernel panic on specific scenario where the port for the PHY is torn down and up and the kmod for the PHY is removed. On setting the port down the first time, the assosiacted LEDs are correctly unregistered. The associated kmod for the PHY is now removed. The kmod is now added again and the port is now put up, the associated LED are registered again. On putting the port down again for the second time after these step, the LED list now have 4 elements. With the first 2 already unregistered previously and the 2 new one registered again. This cause a kernel panic as the first 2 element should have been removed. Fix this by correctly removing the element when LED is unregistered.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50024", "url": "https://ubuntu.com/security/CVE-2024-50024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: Fix an unsafe loop on the list The kernel may crash when deleting a genetlink family if there are still listeners for that family: Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c000000000c080bc] netlink_update_socket_mc+0x3c/0xc0 LR [c000000000c0f764] __netlink_clear_multicast_users+0x74/0xc0 Call Trace: __netlink_clear_multicast_users+0x74/0xc0 genl_unregister_family+0xd4/0x2d0 Change the unsafe loop on the list to a safe one, because inside the loop there is an element removal from this list.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50186", "url": "https://ubuntu.com/security/CVE-2024-50186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: explicitly clear the sk pointer, when pf->create fails We have recently noticed the exact same KASAN splat as in commit 6cd4a78d962b (\"net: do not leave a dangling sk pointer, when socket creation fails\"). The problem is that commit did not fully address the problem, as some pf->create implementations do not use sk_common_release in their error paths. For example, we can use the same reproducer as in the above commit, but changing ping to arping. arping uses AF_PACKET socket and if packet_create fails, it will just sk_free the allocated sk object. While we could chase all the pf->create implementations and make sure they NULL the freed sk object on error from the socket, we can't guarantee future protocols will not make the same mistake. So it is easier to just explicitly NULL the sk pointer upon return from pf->create in __sock_create. We do know that pf->create always releases the allocated sk object on error, so if the pointer is not NULL, it is definitely dangling.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50025", "url": "https://ubuntu.com/security/CVE-2024-50025", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: fnic: Move flush_work initialization out of if block After commit 379a58caa199 (\"scsi: fnic: Move fnic_fnic_flush_tx() to a work queue\"), it can happen that a work item is sent to an uninitialized work queue. This may has the effect that the item being queued is never actually queued, and any further actions depending on it will not proceed. The following warning is observed while the fnic driver is loaded: kernel: WARNING: CPU: 11 PID: 0 at ../kernel/workqueue.c:1524 __queue_work+0x373/0x410 kernel: kernel: queue_work_on+0x3a/0x50 kernel: fnic_wq_copy_cmpl_handler+0x54a/0x730 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: fnic_isr_msix_wq_copy+0x2d/0x60 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: __handle_irq_event_percpu+0x36/0x1a0 kernel: handle_irq_event_percpu+0x30/0x70 kernel: handle_irq_event+0x34/0x60 kernel: handle_edge_irq+0x7e/0x1a0 kernel: __common_interrupt+0x3b/0xb0 kernel: common_interrupt+0x58/0xa0 kernel: It has been observed that this may break the rediscovery of Fibre Channel devices after a temporary fabric failure. This patch fixes it by moving the work queue initialization out of an if block in fnic_probe().", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50026", "url": "https://ubuntu.com/security/CVE-2024-50026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: wd33c93: Don't use stale scsi_pointer value A regression was introduced with commit dbb2da557a6a (\"scsi: wd33c93: Move the SCSI pointer to private command data\") which results in an oops in wd33c93_intr(). That commit added the scsi_pointer variable and initialized it from hostdata->connected. However, during selection, hostdata->connected is not yet valid. Fix this by getting the current scsi_pointer from hostdata->selecting.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50027", "url": "https://ubuntu.com/security/CVE-2024-50027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: core: Free tzp copy along with the thermal zone The object pointed to by tz->tzp may still be accessed after being freed in thermal_zone_device_unregister(), so move the freeing of it to the point after the removal completion has been completed at which it cannot be accessed any more.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50028", "url": "https://ubuntu.com/security/CVE-2024-50028", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: core: Reference count the zone in thermal_zone_get_by_id() There are places in the thermal netlink code where nothing prevents the thermal zone object from going away while being accessed after it has been returned by thermal_zone_get_by_id(). To address this, make thermal_zone_get_by_id() get a reference on the thermal zone device object to be returned with the help of get_device(), under thermal_list_lock, and adjust all of its callers to this change with the help of the cleanup.h infrastructure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50029", "url": "https://ubuntu.com/security/CVE-2024-50029", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_conn: Fix UAF in hci_enhanced_setup_sync This checks if the ACL connection remains valid as it could be destroyed while hci_enhanced_setup_sync is pending on cmd_sync leading to the following trace: BUG: KASAN: slab-use-after-free in hci_enhanced_setup_sync+0x91b/0xa60 Read of size 1 at addr ffff888002328ffd by task kworker/u5:2/37 CPU: 0 UID: 0 PID: 37 Comm: kworker/u5:2 Not tainted 6.11.0-rc6-01300-g810be445d8d6 #7099 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Workqueue: hci0 hci_cmd_sync_work Call Trace: dump_stack_lvl+0x5d/0x80 ? hci_enhanced_setup_sync+0x91b/0xa60 print_report+0x152/0x4c0 ? hci_enhanced_setup_sync+0x91b/0xa60 ? __virt_addr_valid+0x1fa/0x420 ? hci_enhanced_setup_sync+0x91b/0xa60 kasan_report+0xda/0x1b0 ? hci_enhanced_setup_sync+0x91b/0xa60 hci_enhanced_setup_sync+0x91b/0xa60 ? __pfx_hci_enhanced_setup_sync+0x10/0x10 ? __pfx___mutex_lock+0x10/0x10 hci_cmd_sync_work+0x1c2/0x330 process_one_work+0x7d9/0x1360 ? __pfx_lock_acquire+0x10/0x10 ? __pfx_process_one_work+0x10/0x10 ? assign_work+0x167/0x240 worker_thread+0x5b7/0xf60 ? __kthread_parkme+0xac/0x1c0 ? __pfx_worker_thread+0x10/0x10 ? __pfx_worker_thread+0x10/0x10 kthread+0x293/0x360 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2f/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 34: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __hci_conn_add+0x187/0x17d0 hci_connect_sco+0x2e1/0xb90 sco_sock_connect+0x2a2/0xb80 __sys_connect+0x227/0x2a0 __x64_sys_connect+0x6d/0xb0 do_syscall_64+0x71/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 37: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x101/0x160 kfree+0xd0/0x250 device_release+0x9a/0x210 kobject_put+0x151/0x280 hci_conn_del+0x448/0xbf0 hci_abort_conn_sync+0x46f/0x980 hci_cmd_sync_work+0x1c2/0x330 process_one_work+0x7d9/0x1360 worker_thread+0x5b7/0xf60 kthread+0x293/0x360 ret_from_fork+0x2f/0x70 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50030", "url": "https://ubuntu.com/security/CVE-2024-50030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/ct: prevent UAF in send_recv() Ensure we serialize with completion side to prevent UAF with fence going out of scope on the stack, since we have no clue if it will fire after the timeout before we can erase from the xa. Also we have some dependent loads and stores for which we need the correct ordering, and we lack the needed barriers. Fix this by grabbing the ct->lock after the wait, which is also held by the completion side. v2 (Badal): - Also print done after acquiring the lock and seeing timeout. (cherry picked from commit 52789ce35c55ccd30c4b67b9cc5b2af55e0122ea)", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50187", "url": "https://ubuntu.com/security/CVE-2024-50187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Stop the active perfmon before being destroyed Upon closing the file descriptor, the active performance monitor is not stopped. Although all perfmons are destroyed in `vc4_perfmon_close_file()`, the active performance monitor's pointer (`vc4->active_perfmon`) is still retained. If we open a new file descriptor and submit a few jobs with performance monitors, the driver will attempt to stop the active performance monitor using the stale pointer in `vc4->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50031", "url": "https://ubuntu.com/security/CVE-2024-50031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Stop the active perfmon before being destroyed When running `kmscube` with one or more performance monitors enabled via `GALLIUM_HUD`, the following kernel panic can occur: [ 55.008324] Unable to handle kernel paging request at virtual address 00000000052004a4 [ 55.008368] Mem abort info: [ 55.008377] ESR = 0x0000000096000005 [ 55.008387] EC = 0x25: DABT (current EL), IL = 32 bits [ 55.008402] SET = 0, FnV = 0 [ 55.008412] EA = 0, S1PTW = 0 [ 55.008421] FSC = 0x05: level 1 translation fault [ 55.008434] Data abort info: [ 55.008442] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 55.008455] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 55.008467] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 55.008481] user pgtable: 4k pages, 39-bit VAs, pgdp=00000001046c6000 [ 55.008497] [00000000052004a4] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 55.008525] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP [ 55.008542] Modules linked in: rfcomm [...] vc4 v3d snd_soc_hdmi_codec drm_display_helper gpu_sched drm_shmem_helper cec drm_dma_helper drm_kms_helper i2c_brcmstb drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight [ 55.008799] CPU: 2 PID: 166 Comm: v3d_bin Tainted: G C 6.6.47+rpt-rpi-v8 #1 Debian 1:6.6.47-1+rpt1 [ 55.008824] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [ 55.008838] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 55.008855] pc : __mutex_lock.constprop.0+0x90/0x608 [ 55.008879] lr : __mutex_lock.constprop.0+0x58/0x608 [ 55.008895] sp : ffffffc080673cf0 [ 55.008904] x29: ffffffc080673cf0 x28: 0000000000000000 x27: ffffff8106188a28 [ 55.008926] x26: ffffff8101e78040 x25: ffffff8101baa6c0 x24: ffffffd9d989f148 [ 55.008947] x23: ffffffda1c2a4008 x22: 0000000000000002 x21: ffffffc080673d38 [ 55.008968] x20: ffffff8101238000 x19: ffffff8104f83188 x18: 0000000000000000 [ 55.008988] x17: 0000000000000000 x16: ffffffda1bd04d18 x15: 00000055bb08bc90 [ 55.009715] x14: 0000000000000000 x13: 0000000000000000 x12: ffffffda1bd4cbb0 [ 55.010433] x11: 00000000fa83b2da x10: 0000000000001a40 x9 : ffffffda1bd04d04 [ 55.011162] x8 : ffffff8102097b80 x7 : 0000000000000000 x6 : 00000000030a5857 [ 55.011880] x5 : 00ffffffffffffff x4 : 0300000005200470 x3 : 0300000005200470 [ 55.012598] x2 : ffffff8101238000 x1 : 0000000000000021 x0 : 0300000005200470 [ 55.013292] Call trace: [ 55.013959] __mutex_lock.constprop.0+0x90/0x608 [ 55.014646] __mutex_lock_slowpath+0x1c/0x30 [ 55.015317] mutex_lock+0x50/0x68 [ 55.015961] v3d_perfmon_stop+0x40/0xe0 [v3d] [ 55.016627] v3d_bin_job_run+0x10c/0x2d8 [v3d] [ 55.017282] drm_sched_main+0x178/0x3f8 [gpu_sched] [ 55.017921] kthread+0x11c/0x128 [ 55.018554] ret_from_fork+0x10/0x20 [ 55.019168] Code: f9400260 f1001c1f 54001ea9 927df000 (b9403401) [ 55.019776] ---[ end trace 0000000000000000 ]--- [ 55.020411] note: v3d_bin[166] exited with preempt_count 1 This issue arises because, upon closing the file descriptor (which happens when we interrupt `kmscube`), the active performance monitor is not stopped. Although all perfmons are destroyed in `v3d_perfmon_close_file()`, the active performance monitor's pointer (`v3d->active_perfmon`) is still retained. If `kmscube` is run again, the driver will attempt to stop the active performance monitor using the stale pointer in `v3d->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50189", "url": "https://ubuntu.com/security/CVE-2024-50189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: amd_sfh: Switch to device-managed dmam_alloc_coherent() Using the device-managed version allows to simplify clean-up in probe() error path. Additionally, this device-managed ensures proper cleanup, which helps to resolve memory errors, page faults, btrfs going read-only, and btrfs disk corruption.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50033", "url": "https://ubuntu.com/security/CVE-2024-50033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slip: make slhc_remember() more robust against malicious packets syzbot found that slhc_remember() was missing checks against malicious packets [1]. slhc_remember() only checked the size of the packet was at least 20, which is not good enough. We need to make sure the packet includes the IPv4 and TCP header that are supposed to be carried. Add iph and th pointers to make the code more readable. [1] BUG: KMSAN: uninit-value in slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 ppp_receive_nonmp_frame+0xe45/0x35e0 drivers/net/ppp/ppp_generic.c:2455 ppp_receive_frame drivers/net/ppp/ppp_generic.c:2372 [inline] ppp_do_recv+0x65f/0x40d0 drivers/net/ppp/ppp_generic.c:2212 ppp_input+0x7dc/0xe60 drivers/net/ppp/ppp_generic.c:2327 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 Uninit was created at: slab_post_alloc_hook mm/slub.c:4091 [inline] slab_alloc_node mm/slub.c:4134 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 CPU: 0 UID: 0 PID: 5460 Comm: syz.2.33 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50034", "url": "https://ubuntu.com/security/CVE-2024-50034", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix lacks of icsk_syn_mss with IPPROTO_SMC Eric report a panic on IPPROTO_SMC, and give the facts that when INET_PROTOSW_ICSK was set, icsk->icsk_sync_mss must be set too. Bug: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000086000005 EC = 0x21: IABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault user pgtable: 4k pages, 48-bit VAs, pgdp=00000001195d1000 [0000000000000000] pgd=0800000109c46003, p4d=0800000109c46003, pud=0000000000000000 Internal error: Oops: 0000000086000005 [#1] PREEMPT SMP Modules linked in: CPU: 1 UID: 0 PID: 8037 Comm: syz.3.265 Not tainted 6.11.0-rc7-syzkaller-g5f5673607153 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0x0 lr : cipso_v4_sock_setattr+0x2a8/0x3c0 net/ipv4/cipso_ipv4.c:1910 sp : ffff80009b887a90 x29: ffff80009b887aa0 x28: ffff80008db94050 x27: 0000000000000000 x26: 1fffe0001aa6f5b3 x25: dfff800000000000 x24: ffff0000db75da00 x23: 0000000000000000 x22: ffff0000d8b78518 x21: 0000000000000000 x20: ffff0000d537ad80 x19: ffff0000d8b78000 x18: 1fffe000366d79ee x17: ffff8000800614a8 x16: ffff800080569b84 x15: 0000000000000001 x14: 000000008b336894 x13: 00000000cd96feaa x12: 0000000000000003 x11: 0000000000040000 x10: 00000000000020a3 x9 : 1fffe0001b16f0f1 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 000000000000003f x5 : 0000000000000040 x4 : 0000000000000001 x3 : 0000000000000000 x2 : 0000000000000002 x1 : 0000000000000000 x0 : ffff0000d8b78000 Call trace: 0x0 netlbl_sock_setattr+0x2e4/0x338 net/netlabel/netlabel_kapi.c:1000 smack_netlbl_add+0xa4/0x154 security/smack/smack_lsm.c:2593 smack_socket_post_create+0xa8/0x14c security/smack/smack_lsm.c:2973 security_socket_post_create+0x94/0xd4 security/security.c:4425 __sock_create+0x4c8/0x884 net/socket.c:1587 sock_create net/socket.c:1622 [inline] __sys_socket_create net/socket.c:1659 [inline] __sys_socket+0x134/0x340 net/socket.c:1706 __do_sys_socket net/socket.c:1720 [inline] __se_sys_socket net/socket.c:1718 [inline] __arm64_sys_socket+0x7c/0x94 net/socket.c:1718 __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:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 Code: ???????? ???????? ???????? ???????? (????????) ---[ end trace 0000000000000000 ]--- This patch add a toy implementation that performs a simple return to prevent such panic. This is because MSS can be set in sock_create_kern or smc_setsockopt, similar to how it's done in AF_SMC. However, for AF_SMC, there is currently no way to synchronize MSS within __sys_connect_file. This toy implementation lays the groundwork for us to support such feature for IPPROTO_SMC in the future.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50035", "url": "https://ubuntu.com/security/CVE-2024-50035", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: fix ppp_async_encode() illegal access syzbot reported an issue in ppp_async_encode() [1] In this case, pppoe_sendmsg() is called with a zero size. Then ppp_async_encode() is called with an empty skb. BUG: KMSAN: uninit-value in ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] BUG: KMSAN: uninit-value in ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_send+0x130/0x1b0 drivers/net/ppp/ppp_async.c:634 ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2280 [inline] ppp_input+0x1f1/0xe60 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 Uninit was created at: slab_post_alloc_hook mm/slub.c:4092 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4187 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 CPU: 1 UID: 0 PID: 5411 Comm: syz.1.14 Not tainted 6.12.0-rc1-syzkaller-00165-g360c1f1f24c6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50036", "url": "https://ubuntu.com/security/CVE-2024-50036", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: do not delay dst_entries_add() in dst_release() dst_entries_add() uses per-cpu data that might be freed at netns dismantle from ip6_route_net_exit() calling dst_entries_destroy() Before ip6_route_net_exit() can be called, we release all the dsts associated with this netns, via calls to dst_release(), which waits an rcu grace period before calling dst_destroy() dst_entries_add() use in dst_destroy() is racy, because dst_entries_destroy() could have been called already. Decrementing the number of dsts must happen sooner. Notes: 1) in CONFIG_XFRM case, dst_destroy() can call dst_release_immediate(child), this might also cause UAF if the child does not have DST_NOCOUNT set. IPSEC maintainers might take a look and see how to address this. 2) There is also discussion about removing this count of dst, which might happen in future kernels.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50037", "url": "https://ubuntu.com/security/CVE-2024-50037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/fbdev-dma: Only cleanup deferred I/O if necessary Commit 5a498d4d06d6 (\"drm/fbdev-dma: Only install deferred I/O if necessary\") initializes deferred I/O only if it is used. drm_fbdev_dma_fb_destroy() however calls fb_deferred_io_cleanup() unconditionally with struct fb_info.fbdefio == NULL. KASAN with the out-of-tree Apple silicon display driver posts following warning from __flush_work() of a random struct work_struct instead of the expected NULL pointer derefs. [ 22.053799] ------------[ cut here ]------------ [ 22.054832] WARNING: CPU: 2 PID: 1 at kernel/workqueue.c:4177 __flush_work+0x4d8/0x580 [ 22.056597] Modules linked in: uhid bnep uinput nls_ascii ip6_tables ip_tables i2c_dev loop fuse dm_multipath nfnetlink zram hid_magicmouse btrfs xor xor_neon brcmfmac_wcc raid6_pq hci_bcm4377 bluetooth brcmfmac hid_apple brcmutil nvmem_spmi_mfd simple_mfd_spmi dockchannel_hid cfg80211 joydev regmap_spmi nvme_apple ecdh_generic ecc macsmc_hid rfkill dwc3 appledrm snd_soc_macaudio macsmc_power nvme_core apple_isp phy_apple_atc apple_sart apple_rtkit_helper apple_dockchannel tps6598x macsmc_hwmon snd_soc_cs42l84 videobuf2_v4l2 spmi_apple_controller nvmem_apple_efuses videobuf2_dma_sg apple_z2 videobuf2_memops spi_nor panel_summit videobuf2_common asahi videodev pwm_apple apple_dcp snd_soc_apple_mca apple_admac spi_apple clk_apple_nco i2c_pasemi_platform snd_pcm_dmaengine mc i2c_pasemi_core mux_core ofpart adpdrm drm_dma_helper apple_dart apple_soc_cpufreq leds_pwm phram [ 22.073768] CPU: 2 UID: 0 PID: 1 Comm: systemd-shutdow Not tainted 6.11.2-asahi+ #asahi-dev [ 22.075612] Hardware name: Apple MacBook Pro (13-inch, M2, 2022) (DT) [ 22.077032] pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 22.078567] pc : __flush_work+0x4d8/0x580 [ 22.079471] lr : __flush_work+0x54/0x580 [ 22.080345] sp : ffffc000836ef820 [ 22.081089] x29: ffffc000836ef880 x28: 0000000000000000 x27: ffff80002ddb7128 [ 22.082678] x26: dfffc00000000000 x25: 1ffff000096f0c57 x24: ffffc00082d3e358 [ 22.084263] x23: ffff80004b7862b8 x22: dfffc00000000000 x21: ffff80005aa1d470 [ 22.085855] x20: ffff80004b786000 x19: ffff80004b7862a0 x18: 0000000000000000 [ 22.087439] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000005 [ 22.089030] x14: 1ffff800106ddf0a x13: 0000000000000000 x12: 0000000000000000 [ 22.090618] x11: ffffb800106ddf0f x10: dfffc00000000000 x9 : 1ffff800106ddf0e [ 22.092206] x8 : 0000000000000000 x7 : aaaaaaaaaaaaaaaa x6 : 0000000000000001 [ 22.093790] x5 : ffffc000836ef728 x4 : 0000000000000000 x3 : 0000000000000020 [ 22.095368] x2 : 0000000000000008 x1 : 00000000000000aa x0 : 0000000000000000 [ 22.096955] Call trace: [ 22.097505] __flush_work+0x4d8/0x580 [ 22.098330] flush_delayed_work+0x80/0xb8 [ 22.099231] fb_deferred_io_cleanup+0x3c/0x130 [ 22.100217] drm_fbdev_dma_fb_destroy+0x6c/0xe0 [drm_dma_helper] [ 22.101559] unregister_framebuffer+0x210/0x2f0 [ 22.102575] drm_fb_helper_unregister_info+0x48/0x60 [ 22.103683] drm_fbdev_dma_client_unregister+0x4c/0x80 [drm_dma_helper] [ 22.105147] drm_client_dev_unregister+0x1cc/0x230 [ 22.106217] drm_dev_unregister+0x58/0x570 [ 22.107125] apple_drm_unbind+0x50/0x98 [appledrm] [ 22.108199] component_del+0x1f8/0x3a8 [ 22.109042] dcp_platform_shutdown+0x24/0x38 [apple_dcp] [ 22.110357] platform_shutdown+0x70/0x90 [ 22.111219] device_shutdown+0x368/0x4d8 [ 22.112095] kernel_restart+0x6c/0x1d0 [ 22.112946] __arm64_sys_reboot+0x1c8/0x328 [ 22.113868] invoke_syscall+0x78/0x1a8 [ 22.114703] do_el0_svc+0x124/0x1a0 [ 22.115498] el0_svc+0x3c/0xe0 [ 22.116181] el0t_64_sync_handler+0x70/0xc0 [ 22.117110] el0t_64_sync+0x190/0x198 [ 22.117931] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50092", "url": "https://ubuntu.com/security/CVE-2024-50092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netconsole: fix wrong warning A warning is triggered when there is insufficient space in the buffer for userdata. However, this is not an issue since userdata will be sent in the next iteration. Current warning message: ------------[ cut here ]------------ WARNING: CPU: 13 PID: 3013042 at drivers/net/netconsole.c:1122 write_ext_msg+0x3b6/0x3d0 ? write_ext_msg+0x3b6/0x3d0 console_flush_all+0x1e9/0x330 The code incorrectly issues a warning when this_chunk is zero, which is a valid scenario. The warning should only be triggered when this_chunk is negative.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50038", "url": "https://ubuntu.com/security/CVE-2024-50038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xtables: avoid NFPROTO_UNSPEC where needed syzbot managed to call xt_cluster match via ebtables: WARNING: CPU: 0 PID: 11 at net/netfilter/xt_cluster.c:72 xt_cluster_mt+0x196/0x780 [..] ebt_do_table+0x174b/0x2a40 Module registers to NFPROTO_UNSPEC, but it assumes ipv4/ipv6 packet processing. As this is only useful to restrict locally terminating TCP/UDP traffic, register this for ipv4 and ipv6 family only. Pablo points out that this is a general issue, direct users of the set/getsockopt interface can call into targets/matches that were only intended for use with ip(6)tables. Check all UNSPEC matches and targets for similar issues: - matches and targets are fine except if they assume skb_network_header() is valid -- this is only true when called from inet layer: ip(6) stack pulls the ip/ipv6 header into linear data area. - targets that return XT_CONTINUE or other xtables verdicts must be restricted too, they are incompatbile with the ebtables traverser, e.g. EBT_CONTINUE is a completely different value than XT_CONTINUE. Most matches/targets are changed to register for NFPROTO_IPV4/IPV6, as they are provided for use by ip(6)tables. The MARK target is also used by arptables, so register for NFPROTO_ARP too. While at it, bail out if connbytes fails to enable the corresponding conntrack family. This change passes the selftests in iptables.git.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50039", "url": "https://ubuntu.com/security/CVE-2024-50039", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: accept TCA_STAB only for root qdisc Most qdiscs maintain their backlog using qdisc_pkt_len(skb) on the assumption it is invariant between the enqueue() and dequeue() handlers. Unfortunately syzbot can crash a host rather easily using a TBF + SFQ combination, with an STAB on SFQ [1] We can't support TCA_STAB on arbitrary level, this would require to maintain per-qdisc storage. [1] [ 88.796496] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 88.798611] #PF: supervisor read access in kernel mode [ 88.799014] #PF: error_code(0x0000) - not-present page [ 88.799506] PGD 0 P4D 0 [ 88.799829] Oops: Oops: 0000 [#1] SMP NOPTI [ 88.800569] CPU: 14 UID: 0 PID: 2053 Comm: b371744477 Not tainted 6.12.0-rc1-virtme #1117 [ 88.801107] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 88.801779] RIP: 0010:sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq [ 88.802544] Code: 0f b7 50 12 48 8d 04 d5 00 00 00 00 48 89 d6 48 29 d0 48 8b 91 c0 01 00 00 48 c1 e0 03 48 01 c2 66 83 7a 1a 00 7e c0 48 8b 3a <4c> 8b 07 4c 89 02 49 89 50 08 48 c7 47 08 00 00 00 00 48 c7 07 00 All code ======== 0:\t0f b7 50 12 \tmovzwl 0x12(%rax),%edx 4:\t48 8d 04 d5 00 00 00 \tlea 0x0(,%rdx,8),%rax b:\t00 c:\t48 89 d6 \tmov %rdx,%rsi f:\t48 29 d0 \tsub %rdx,%rax 12:\t48 8b 91 c0 01 00 00 \tmov 0x1c0(%rcx),%rdx 19:\t48 c1 e0 03 \tshl $0x3,%rax 1d:\t48 01 c2 \tadd %rax,%rdx 20:\t66 83 7a 1a 00 \tcmpw $0x0,0x1a(%rdx) 25:\t7e c0 \tjle 0xffffffffffffffe7 27:\t48 8b 3a \tmov (%rdx),%rdi 2a:*\t4c 8b 07 \tmov (%rdi),%r8\t\t<-- trapping instruction 2d:\t4c 89 02 \tmov %r8,(%rdx) 30:\t49 89 50 08 \tmov %rdx,0x8(%r8) 34:\t48 c7 47 08 00 00 00 \tmovq $0x0,0x8(%rdi) 3b:\t00 3c:\t48 \trex.W 3d:\tc7 \t.byte 0xc7 3e:\t07 \t(bad) \t... Code starting with the faulting instruction =========================================== 0:\t4c 8b 07 \tmov (%rdi),%r8 3:\t4c 89 02 \tmov %r8,(%rdx) 6:\t49 89 50 08 \tmov %rdx,0x8(%r8) a:\t48 c7 47 08 00 00 00 \tmovq $0x0,0x8(%rdi) 11:\t00 12:\t48 \trex.W 13:\tc7 \t.byte 0xc7 14:\t07 \t(bad) \t... [ 88.803721] RSP: 0018:ffff9a1f892b7d58 EFLAGS: 00000206 [ 88.804032] RAX: 0000000000000000 RBX: ffff9a1f8420c800 RCX: ffff9a1f8420c800 [ 88.804560] RDX: ffff9a1f81bc1440 RSI: 0000000000000000 RDI: 0000000000000000 [ 88.805056] RBP: ffffffffc04bb0e0 R08: 0000000000000001 R09: 00000000ff7f9a1f [ 88.805473] R10: 000000000001001b R11: 0000000000009a1f R12: 0000000000000140 [ 88.806194] R13: 0000000000000001 R14: ffff9a1f886df400 R15: ffff9a1f886df4ac [ 88.806734] FS: 00007f445601a740(0000) GS:ffff9a2e7fd80000(0000) knlGS:0000000000000000 [ 88.807225] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 88.807672] CR2: 0000000000000000 CR3: 000000050cc46000 CR4: 00000000000006f0 [ 88.808165] Call Trace: [ 88.808459] [ 88.808710] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434) [ 88.809261] ? page_fault_oops (arch/x86/mm/fault.c:715) [ 88.809561] ? exc_page_fault (./arch/x86/include/asm/irqflags.h:26 ./arch/x86/include/asm/irqflags.h:87 ./arch/x86/include/asm/irqflags.h:147 arch/x86/mm/fault.c:1489 arch/x86/mm/fault.c:1539) [ 88.809806] ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623) [ 88.810074] ? sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq [ 88.810411] sfq_reset (net/sched/sch_sfq.c:525) sch_sfq [ 88.810671] qdisc_reset (./include/linux/skbuff.h:2135 ./include/linux/skbuff.h:2441 ./include/linux/skbuff.h:3304 ./include/linux/skbuff.h:3310 net/sched/sch_g ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50040", "url": "https://ubuntu.com/security/CVE-2024-50040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: igb: Do not bring the device up after non-fatal error Commit 004d25060c78 (\"igb: Fix igb_down hung on surprise removal\") changed igb_io_error_detected() to ignore non-fatal pcie errors in order to avoid hung task that can happen when igb_down() is called multiple times. This caused an issue when processing transient non-fatal errors. igb_io_resume(), which is called after igb_io_error_detected(), assumes that device is brought down by igb_io_error_detected() if the interface is up. This resulted in panic with stacktrace below. [ T3256] igb 0000:09:00.0 haeth0: igb: haeth0 NIC Link is Down [ T292] pcieport 0000:00:1c.5: AER: Uncorrected (Non-Fatal) error received: 0000:09:00.0 [ T292] igb 0000:09:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, (Requester ID) [ T292] igb 0000:09:00.0: device [8086:1537] error status/mask=00004000/00000000 [ T292] igb 0000:09:00.0: [14] CmpltTO [ 200.105524,009][ T292] igb 0000:09:00.0: AER: TLP Header: 00000000 00000000 00000000 00000000 [ T292] pcieport 0000:00:1c.5: AER: broadcast error_detected message [ T292] igb 0000:09:00.0: Non-correctable non-fatal error reported. [ T292] pcieport 0000:00:1c.5: AER: broadcast mmio_enabled message [ T292] pcieport 0000:00:1c.5: AER: broadcast resume message [ T292] ------------[ cut here ]------------ [ T292] kernel BUG at net/core/dev.c:6539! [ T292] invalid opcode: 0000 [#1] PREEMPT SMP [ T292] RIP: 0010:napi_enable+0x37/0x40 [ T292] Call Trace: [ T292] [ T292] ? die+0x33/0x90 [ T292] ? do_trap+0xdc/0x110 [ T292] ? napi_enable+0x37/0x40 [ T292] ? do_error_trap+0x70/0xb0 [ T292] ? napi_enable+0x37/0x40 [ T292] ? napi_enable+0x37/0x40 [ T292] ? exc_invalid_op+0x4e/0x70 [ T292] ? napi_enable+0x37/0x40 [ T292] ? asm_exc_invalid_op+0x16/0x20 [ T292] ? napi_enable+0x37/0x40 [ T292] igb_up+0x41/0x150 [ T292] igb_io_resume+0x25/0x70 [ T292] report_resume+0x54/0x70 [ T292] ? report_frozen_detected+0x20/0x20 [ T292] pci_walk_bus+0x6c/0x90 [ T292] ? aer_print_port_info+0xa0/0xa0 [ T292] pcie_do_recovery+0x22f/0x380 [ T292] aer_process_err_devices+0x110/0x160 [ T292] aer_isr+0x1c1/0x1e0 [ T292] ? disable_irq_nosync+0x10/0x10 [ T292] irq_thread_fn+0x1a/0x60 [ T292] irq_thread+0xe3/0x1a0 [ T292] ? irq_set_affinity_notifier+0x120/0x120 [ T292] ? irq_affinity_notify+0x100/0x100 [ T292] kthread+0xe2/0x110 [ T292] ? kthread_complete_and_exit+0x20/0x20 [ T292] ret_from_fork+0x2d/0x50 [ T292] ? kthread_complete_and_exit+0x20/0x20 [ T292] ret_from_fork_asm+0x11/0x20 [ T292] To fix this issue igb_io_resume() checks if the interface is running and the device is not down this means igb_io_error_detected() did not bring the device down and there is no need to bring it up.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50041", "url": "https://ubuntu.com/security/CVE-2024-50041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: Fix macvlan leak by synchronizing access to mac_filter_hash This patch addresses a macvlan leak issue in the i40e driver caused by concurrent access to vsi->mac_filter_hash. The leak occurs when multiple threads attempt to modify the mac_filter_hash simultaneously, leading to inconsistent state and potential memory leaks. To fix this, we now wrap the calls to i40e_del_mac_filter() and zeroing vf->default_lan_addr.addr with spin_lock/unlock_bh(&vsi->mac_filter_hash_lock), ensuring atomic operations and preventing concurrent access. Additionally, we add lockdep_assert_held(&vsi->mac_filter_hash_lock) in i40e_add_mac_filter() to help catch similar issues in the future. Reproduction steps: 1. Spawn VFs and configure port vlan on them. 2. Trigger concurrent macvlan operations (e.g., adding and deleting \tportvlan and/or mac filters). 3. Observe the potential memory leak and inconsistent state in the \tmac_filter_hash. This synchronization ensures the integrity of the mac_filter_hash and prevents the described leak.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50042", "url": "https://ubuntu.com/security/CVE-2024-50042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix increasing MSI-X on VF Increasing MSI-X value on a VF leads to invalid memory operations. This is caused by not reallocating some arrays. Reproducer: modprobe ice echo 0 > /sys/bus/pci/devices/$PF_PCI/sriov_drivers_autoprobe echo 1 > /sys/bus/pci/devices/$PF_PCI/sriov_numvfs echo 17 > /sys/bus/pci/devices/$VF0_PCI/sriov_vf_msix_count Default MSI-X is 16, so 17 and above triggers this issue. KASAN reports: BUG: KASAN: slab-out-of-bounds in ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] Read of size 8 at addr ffff8888b937d180 by task bash/28433 (...) Call Trace: (...) ? ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] kasan_report+0xed/0x120 ? ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] ice_vsi_cfg_def+0x3360/0x4770 [ice] ? mutex_unlock+0x83/0xd0 ? __pfx_ice_vsi_cfg_def+0x10/0x10 [ice] ? __pfx_ice_remove_vsi_lkup_fltr+0x10/0x10 [ice] ice_vsi_cfg+0x7f/0x3b0 [ice] ice_vf_reconfig_vsi+0x114/0x210 [ice] ice_sriov_set_msix_vec_count+0x3d0/0x960 [ice] sriov_vf_msix_count_store+0x21c/0x300 (...) Allocated by task 28201: (...) ice_vsi_cfg_def+0x1c8e/0x4770 [ice] ice_vsi_cfg+0x7f/0x3b0 [ice] ice_vsi_setup+0x179/0xa30 [ice] ice_sriov_configure+0xcaa/0x1520 [ice] sriov_numvfs_store+0x212/0x390 (...) To fix it, use ice_vsi_rebuild() instead of ice_vf_reconfig_vsi(). This causes the required arrays to be reallocated taking the new queue count into account (ice_vsi_realloc_stat_arrays()). Set req_txq and req_rxq before ice_vsi_rebuild(), so that realloc uses the newly set queue count. Additionally, ice_vsi_rebuild() does not remove VSI filters (ice_fltr_remove_all()), so ice_vf_init_host_cfg() is no longer necessary.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50093", "url": "https://ubuntu.com/security/CVE-2024-50093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: intel: int340x: processor: Fix warning during module unload The processor_thermal driver uses pcim_device_enable() to enable a PCI device, which means the device will be automatically disabled on driver detach. Thus there is no need to call pci_disable_device() again on it. With recent PCI device resource management improvements, e.g. commit f748a07a0b64 (\"PCI: Remove legacy pcim_release()\"), this problem is exposed and triggers the warining below. [ 224.010735] proc_thermal_pci 0000:00:04.0: disabling already-disabled device [ 224.010747] WARNING: CPU: 8 PID: 4442 at drivers/pci/pci.c:2250 pci_disable_device+0xe5/0x100 ... [ 224.010844] Call Trace: [ 224.010845] [ 224.010847] ? show_regs+0x6d/0x80 [ 224.010851] ? __warn+0x8c/0x140 [ 224.010854] ? pci_disable_device+0xe5/0x100 [ 224.010856] ? report_bug+0x1c9/0x1e0 [ 224.010859] ? handle_bug+0x46/0x80 [ 224.010862] ? exc_invalid_op+0x1d/0x80 [ 224.010863] ? asm_exc_invalid_op+0x1f/0x30 [ 224.010867] ? pci_disable_device+0xe5/0x100 [ 224.010869] ? pci_disable_device+0xe5/0x100 [ 224.010871] ? kfree+0x21a/0x2b0 [ 224.010873] pcim_disable_device+0x20/0x30 [ 224.010875] devm_action_release+0x16/0x20 [ 224.010878] release_nodes+0x47/0xc0 [ 224.010880] devres_release_all+0x9f/0xe0 [ 224.010883] device_unbind_cleanup+0x12/0x80 [ 224.010885] device_release_driver_internal+0x1ca/0x210 [ 224.010887] driver_detach+0x4e/0xa0 [ 224.010889] bus_remove_driver+0x6f/0xf0 [ 224.010890] driver_unregister+0x35/0x60 [ 224.010892] pci_unregister_driver+0x44/0x90 [ 224.010894] proc_thermal_pci_driver_exit+0x14/0x5f0 [processor_thermal_device_pci] ... [ 224.010921] ---[ end trace 0000000000000000 ]--- Remove the excess pci_disable_device() calls. [ rjw: Subject and changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50043", "url": "https://ubuntu.com/security/CVE-2024-50043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix possible badness in FREE_STATEID When multiple FREE_STATEIDs are sent for the same delegation stateid, it can lead to a possible either use-after-free or counter refcount underflow errors. In nfsd4_free_stateid() under the client lock we find a delegation stateid, however the code drops the lock before calling nfs4_put_stid(), that allows another FREE_STATE to find the stateid again. The first one will proceed to then free the stateid which leads to either use-after-free or decrementing already zeroed counter.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50044", "url": "https://ubuntu.com/security/CVE-2024-50044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change rfcomm_sk_state_change attempts to use sock_lock so it must never be called with it locked but rfcomm_sock_ioctl always attempt to lock it causing the following trace: ====================================================== WARNING: possible circular locking dependency detected 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Not tainted ------------------------------------------------------ syz-executor386/5093 is trying to acquire lock: ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1671 [inline] ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73 but task is already holding lock: ffff88807badfd28 (&d->lock){+.+.}-{3:3}, at: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50045", "url": "https://ubuntu.com/security/CVE-2024-50045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: br_netfilter: fix panic with metadata_dst skb Fix a kernel panic in the br_netfilter module when sending untagged traffic via a VxLAN device. This happens during the check for fragmentation in br_nf_dev_queue_xmit. It is dependent on: 1) the br_netfilter module being loaded; 2) net.bridge.bridge-nf-call-iptables set to 1; 3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port; 4) untagged frames with size higher than the VxLAN MTU forwarded/flooded When forwarding the untagged packet to the VxLAN bridge port, before the netfilter hooks are called, br_handle_egress_vlan_tunnel is called and changes the skb_dst to the tunnel dst. The tunnel_dst is a metadata type of dst, i.e., skb_valid_dst(skb) is false, and metadata->dst.dev is NULL. Then in the br_netfilter hooks, in br_nf_dev_queue_xmit, there's a check for frames that needs to be fragmented: frames with higher MTU than the VxLAN device end up calling br_nf_ip_fragment, which in turns call ip_skb_dst_mtu. The ip_dst_mtu tries to use the skb_dst(skb) as if it was a valid dst with valid dst->dev, thus the crash. This case was never supported in the first place, so drop the packet instead. PING 10.0.0.2 (10.0.0.2) from 0.0.0.0 h1-eth0: 2000(2028) bytes of data. [ 176.291791] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000110 [ 176.292101] Mem abort info: [ 176.292184] ESR = 0x0000000096000004 [ 176.292322] EC = 0x25: DABT (current EL), IL = 32 bits [ 176.292530] SET = 0, FnV = 0 [ 176.292709] EA = 0, S1PTW = 0 [ 176.292862] FSC = 0x04: level 0 translation fault [ 176.293013] Data abort info: [ 176.293104] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 176.293488] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 176.293787] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 176.293995] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043ef5000 [ 176.294166] [0000000000000110] pgd=0000000000000000, p4d=0000000000000000 [ 176.294827] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 176.295252] Modules linked in: vxlan ip6_udp_tunnel udp_tunnel veth br_netfilter bridge stp llc ipv6 crct10dif_ce [ 176.295923] CPU: 0 PID: 188 Comm: ping Not tainted 6.8.0-rc3-g5b3fbd61b9d1 #2 [ 176.296314] Hardware name: linux,dummy-virt (DT) [ 176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 176.296808] pc : br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.297382] lr : br_nf_dev_queue_xmit+0x2ac/0x4ec [br_netfilter] [ 176.297636] sp : ffff800080003630 [ 176.297743] x29: ffff800080003630 x28: 0000000000000008 x27: ffff6828c49ad9f8 [ 176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24: 00000000000003e8 [ 176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21: ffff6828c3b16d28 [ 176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18: 0000000000000014 [ 176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15: 0000000095744632 [ 176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12: ffffb7e137926a70 [ 176.299574] x11: 0000000000000001 x10: ffff6828c3f1c898 x9 : 0000000000000000 [ 176.300049] x8 : ffff6828c49bf070 x7 : 0008460f18d5f20e x6 : f20e0100bebafeca [ 176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 : 0000000000000000 [ 176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 : ffff6828c7f918f0 [ 176.300889] Call trace: [ 176.301123] br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.301411] br_nf_post_routing+0x2a8/0x3e4 [br_netfilter] [ 176.301703] nf_hook_slow+0x48/0x124 [ 176.302060] br_forward_finish+0xc8/0xe8 [bridge] [ 176.302371] br_nf_hook_thresh+0x124/0x134 [br_netfilter] [ 176.302605] br_nf_forward_finish+0x118/0x22c [br_netfilter] [ 176.302824] br_nf_forward_ip.part.0+0x264/0x290 [br_netfilter] [ 176.303136] br_nf_forward+0x2b8/0x4e0 [br_netfilter] [ 176.303359] nf_hook_slow+0x48/0x124 [ 176.303 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50094", "url": "https://ubuntu.com/security/CVE-2024-50094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sfc: Don't invoke xdp_do_flush() from netpoll. Yury reported a crash in the sfc driver originated from netpoll_send_udp(). The netconsole sends a message and then netpoll invokes the driver's NAPI function with a budget of zero. It is dedicated to allow driver to free TX resources, that it may have used while sending the packet. In the netpoll case the driver invokes xdp_do_flush() unconditionally, leading to crash because bpf_net_context was never assigned. Invoke xdp_do_flush() only if budget is not zero.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50188", "url": "https://ubuntu.com/security/CVE-2024-50188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: dp83869: fix memory corruption when enabling fiber When configuring the fiber port, the DP83869 PHY driver incorrectly calls linkmode_set_bit() with a bit mask (1 << 10) rather than a bit number (10). This corrupts some other memory location -- in case of arm64 the priv pointer in the same structure. Since the advertising flags are updated from supported at the end of the function the incorrect line isn't needed at all and can be removed.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50046", "url": "https://ubuntu.com/security/CVE-2024-50046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies() On the node of an NFS client, some files saved in the mountpoint of the NFS server were copied to another location of the same NFS server. Accidentally, the nfs42_complete_copies() got a NULL-pointer dereference crash with the following syslog: [232064.838881] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232064.839360] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232066.588183] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 [232066.588586] Mem abort info: [232066.588701] ESR = 0x0000000096000007 [232066.588862] EC = 0x25: DABT (current EL), IL = 32 bits [232066.589084] SET = 0, FnV = 0 [232066.589216] EA = 0, S1PTW = 0 [232066.589340] FSC = 0x07: level 3 translation fault [232066.589559] Data abort info: [232066.589683] ISV = 0, ISS = 0x00000007 [232066.589842] CM = 0, WnR = 0 [232066.589967] user pgtable: 64k pages, 48-bit VAs, pgdp=00002000956ff400 [232066.590231] [0000000000000058] pgd=08001100ae100003, p4d=08001100ae100003, pud=08001100ae100003, pmd=08001100b3c00003, pte=0000000000000000 [232066.590757] Internal error: Oops: 96000007 [#1] SMP [232066.590958] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm vhost_net vhost vhost_iotlb tap tun ipt_rpfilter xt_multiport ip_set_hash_ip ip_set_hash_net xfrm_interface xfrm6_tunnel tunnel4 tunnel6 esp4 ah4 wireguard libcurve25519_generic veth xt_addrtype xt_set nf_conntrack_netlink ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_bitmap_port ip_set_hash_ipport dummy ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs iptable_filter sch_ingress nfnetlink_cttimeout vport_gre ip_gre ip_tunnel gre vport_geneve geneve vport_vxlan vxlan ip6_udp_tunnel udp_tunnel openvswitch nf_conncount dm_round_robin dm_service_time dm_multipath xt_nat xt_MASQUERADE nft_chain_nat nf_nat xt_mark xt_conntrack xt_comment nft_compat nft_counter nf_tables nfnetlink ocfs2 ocfs2_nodemanager ocfs2_stackglue iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_ssif nbd overlay 8021q garp mrp bonding tls rfkill sunrpc ext4 mbcache jbd2 [232066.591052] vfat fat cas_cache cas_disk ses enclosure scsi_transport_sas sg acpi_ipmi ipmi_si ipmi_devintf ipmi_msghandler ip_tables vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio dm_mirror dm_region_hash dm_log dm_mod nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc fuse xfs libcrc32c ast drm_vram_helper qla2xxx drm_kms_helper syscopyarea crct10dif_ce sysfillrect ghash_ce sysimgblt sha2_ce fb_sys_fops cec sha256_arm64 sha1_ce drm_ttm_helper ttm nvme_fc igb sbsa_gwdt nvme_fabrics drm nvme_core i2c_algo_bit i40e scsi_transport_fc megaraid_sas aes_neon_bs [232066.596953] CPU: 6 PID: 4124696 Comm: 10.253.166.125- Kdump: loaded Not tainted 5.15.131-9.cl9_ocfs2.aarch64 #1 [232066.597356] Hardware name: Great Wall .\\x93\\x8e...RF6260 V5/GWMSSE2GL1T, BIOS T656FBE_V3.0.18 2024-01-06 [232066.597721] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [232066.598034] pc : nfs4_reclaim_open_state+0x220/0x800 [nfsv4] [232066.598327] lr : nfs4_reclaim_open_state+0x12c/0x800 [nfsv4] [232066.598595] sp : ffff8000f568fc70 [232066.598731] x29: ffff8000f568fc70 x28: 0000000000001000 x27: ffff21003db33000 [232066.599030] x26: ffff800005521ae0 x25: ffff0100f98fa3f0 x24: 0000000000000001 [232066.599319] x23: ffff800009920008 x22: ffff21003db33040 x21: ffff21003db33050 [232066.599628] x20: ffff410172fe9e40 x19: ffff410172fe9e00 x18: 0000000000000000 [232066.599914] x17: 0000000000000000 x16: 0000000000000004 x15: 0000000000000000 [232066.600195] x14: 0000000000000000 x13: ffff800008e685a8 x12: 00000000eac0c6e6 [232066.600498] x11: 00000000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50190", "url": "https://ubuntu.com/security/CVE-2024-50190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix memleak in ice_init_tx_topology() Fix leak of the FW blob (DDP pkg). Make ice_cfg_tx_topo() const-correct, so ice_init_tx_topology() can avoid copying whole FW blob. Copy just the topology section, and only when needed. Reuse the buffer allocated for the read of the current topology. This was found by kmemleak, with the following trace for each PF: [] kmemdup_noprof+0x1d/0x50 [] ice_init_ddp_config+0x100/0x220 [ice] [] ice_init_dev+0x6f/0x200 [ice] [] ice_init+0x29/0x560 [ice] [] ice_probe+0x21d/0x310 [ice] Constify ice_cfg_tx_topo() @buf parameter. This cascades further down to few more functions.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50180", "url": "https://ubuntu.com/security/CVE-2024-50180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: sisfb: Fix strbuf array overflow The values of the variables xres and yres are placed in strbuf. These variables are obtained from strbuf1. The strbuf1 array contains digit characters and a space if the array contains non-digit characters. Then, when executing sprintf(strbuf, \"%ux%ux8\", xres, yres); more than 16 bytes will be written to strbuf. It is suggested to increase the size of the strbuf array to 24. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06: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": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50048", "url": "https://ubuntu.com/security/CVE-2024-50048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: Fix a NULL pointer dereference issue in fbcon_putcs syzbot has found a NULL pointer dereference bug in fbcon. Here is the simplified C reproducer: struct param { \tuint8_t type; \tstruct tiocl_selection ts; }; int main() { \tstruct fb_con2fbmap con2fb; \tstruct param param; \tint fd = open(\"/dev/fb1\", 0, 0); \tcon2fb.console = 0x19; \tcon2fb.framebuffer = 0; \tioctl(fd, FBIOPUT_CON2FBMAP, &con2fb); \tparam.type = 2; \tparam.ts.xs = 0; param.ts.ys = 0; \tparam.ts.xe = 0; param.ts.ye = 0; \tparam.ts.sel_mode = 0; \tint fd1 = open(\"/dev/tty1\", O_RDWR, 0); \tioctl(fd1, TIOCLINUX, ¶m); \tcon2fb.console = 1; \tcon2fb.framebuffer = 0; \tioctl(fd, FBIOPUT_CON2FBMAP, &con2fb); \treturn 0; } After calling ioctl(fd1, TIOCLINUX, ¶m), the subsequent ioctl(fd, FBIOPUT_CON2FBMAP, &con2fb) causes the kernel to follow a different execution path: set_con2fb_map -> con2fb_init_display -> fbcon_set_disp -> redraw_screen -> hide_cursor -> clear_selection -> highlight -> invert_screen -> do_update_region -> fbcon_putcs -> ops->putcs Since ops->putcs is a NULL pointer, this leads to a kernel panic. To prevent this, we need to call set_blitting_type() within set_con2fb_map() to properly initialize ops->putcs.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50049", "url": "https://ubuntu.com/security/CVE-2024-50049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before dereferencing se [WHAT & HOW] se is null checked previously in the same function, indicating it might be null; therefore, it must be checked when used again. This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50090", "url": "https://ubuntu.com/security/CVE-2024-50090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/oa: Fix overflow in oa batch buffer By default xe_bb_create_job() appends a MI_BATCH_BUFFER_END to batch buffer, this is not a problem if batch buffer is only used once but oa reuses the batch buffer for the same metric and at each call it appends a MI_BATCH_BUFFER_END, printing the warning below and then overflowing. [ 381.072016] ------------[ cut here ]------------ [ 381.072019] xe 0000:00:02.0: [drm] Assertion `bb->len * 4 + bb_prefetch(q->gt) <= size` failed! platform: LUNARLAKE subplatform: 1 graphics: Xe2_LPG / Xe2_HPG 20.04 step B0 media: Xe2_LPM / Xe2_HPM 20.00 step B0 tile: 0 VRAM 0 B GT: 0 type 1 So here checking if batch buffer already have MI_BATCH_BUFFER_END if not append it. v2: - simply fix, suggestion from Ashutosh (cherry picked from commit 9ba0e0f30ca42a98af3689460063edfb6315718a)", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50183", "url": "https://ubuntu.com/security/CVE-2024-50183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV instance Deleting an NPIV instance requires all fabric ndlps to be released before an NPIV's resources can be torn down. Failure to release fabric ndlps beforehand opens kref imbalance race conditions. Fix by forcing the DA_ID to complete synchronously with usage of wait_queue.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50055", "url": "https://ubuntu.com/security/CVE-2024-50055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: driver core: bus: Fix double free in driver API bus_register() For bus_register(), any error which happens after kset_register() will cause that @priv are freed twice, fixed by setting @priv with NULL after the first free.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50091", "url": "https://ubuntu.com/security/CVE-2024-50091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm vdo: don't refer to dedupe_context after releasing it Clear the dedupe_context pointer in a data_vio whenever ownership of the context is lost, so that vdo can't examine it accidentally.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50056", "url": "https://ubuntu.com/security/CVE-2024-50056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: Fix ERR_PTR dereference in uvc_v4l2.c Fix potential dereferencing of ERR_PTR() in find_format_by_pix() and uvc_v4l2_enum_format(). Fix the following smatch errors: drivers/usb/gadget/function/uvc_v4l2.c:124 find_format_by_pix() error: 'fmtdesc' dereferencing possible ERR_PTR() drivers/usb/gadget/function/uvc_v4l2.c:392 uvc_v4l2_enum_format() error: 'fmtdesc' dereferencing possible ERR_PTR() Also, fix similar issue in uvc_v4l2_try_format() for potential dereferencing of ERR_PTR().", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50184", "url": "https://ubuntu.com/security/CVE-2024-50184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_pmem: Check device status before requesting flush If a pmem device is in a bad status, the driver side could wait for host ack forever in virtio_pmem_flush(), causing the system to hang. So add a status check in the beginning of virtio_pmem_flush() to return early if the device is not activated.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50057", "url": "https://ubuntu.com/security/CVE-2024-50057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: tipd: Free IRQ only if it was requested before In polling mode, if no IRQ was requested there is no need to free it. Call devm_free_irq() only if client->irq is set. This fixes the warning caused by the tps6598x module removal: WARNING: CPU: 2 PID: 333 at kernel/irq/devres.c:144 devm_free_irq+0x80/0x8c ... ... Call trace: devm_free_irq+0x80/0x8c tps6598x_remove+0x28/0x88 [tps6598x] i2c_device_remove+0x2c/0x9c device_remove+0x4c/0x80 device_release_driver_internal+0x1cc/0x228 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 i2c_del_driver+0x54/0x64 tps6598x_i2c_driver_exit+0x18/0xc3c [tps6598x] __arm64_sys_delete_module+0x184/0x264 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc8/0xe8 do_el0_svc+0x20/0x2c el0_svc+0x28/0x98 el0t_64_sync_handler+0x13c/0x158 el0t_64_sync+0x190/0x194", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50058", "url": "https://ubuntu.com/security/CVE-2024-50058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: protect uart_port_dtr_rts() in uart_shutdown() too Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part 3) added few uport == NULL checks. It added one to uart_shutdown(), so the commit assumes, uport can be NULL in there. But right after that protection, there is an unprotected \"uart_port_dtr_rts(uport, false);\" call. That is invoked only if HUPCL is set, so I assume that is the reason why we do not see lots of these reports. Or it cannot be NULL at this point at all for some reason :P. Until the above is investigated, stay on the safe side and move this dereference to the if too. I got this inconsistency from Coverity under CID 1585130. Thanks.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50181", "url": "https://ubuntu.com/security/CVE-2024-50181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: imx: Remove CLK_SET_PARENT_GATE for DRAM mux for i.MX7D For i.MX7D DRAM related mux clock, the clock source change should ONLY be done done in low level asm code without accessing DRAM, and then calling clk API to sync the HW clock status with clk tree, it should never touch real clock source switch via clk API, so CLK_SET_PARENT_GATE flag should NOT be added, otherwise, DRAM's clock parent will be disabled when DRAM is active, and system will hang.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50059", "url": "https://ubuntu.com/security/CVE-2024-50059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntb: ntb_hw_switchtec: Fix use after free vulnerability in switchtec_ntb_remove due to race condition In the switchtec_ntb_add function, it can call switchtec_ntb_init_sndev function, then &sndev->check_link_status_work is bound with check_link_status_work. switchtec_ntb_link_notification may be called to start the work. If we remove the module which will call switchtec_ntb_remove to make cleanup, it will free sndev through kfree(sndev), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | check_link_status_work switchtec_ntb_remove | kfree(sndev); | | if (sndev->link_force_down) | // use sndev Fix it by ensuring that the work is canceled before proceeding with the cleanup in switchtec_ntb_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50060", "url": "https://ubuntu.com/security/CVE-2024-50060", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring: check if we need to reschedule during overflow flush In terms of normal application usage, this list will always be empty. And if an application does overflow a bit, it'll have a few entries. However, nothing obviously prevents syzbot from running a test case that generates a ton of overflow entries, and then flushing them can take quite a while. Check for needing to reschedule while flushing, and drop our locks and do so if necessary. There's no state to maintain here as overflows always prune from head-of-list, hence it's fine to drop and reacquire the locks at the end of the loop.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50061", "url": "https://ubuntu.com/security/CVE-2024-50061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: cdns: Fix use after free vulnerability in cdns_i3c_master Driver Due to Race Condition In the cdns_i3c_master_probe function, &master->hj_work is bound with cdns_i3c_master_hj. And cdns_i3c_master_interrupt can call cnds_i3c_master_demux_ibis function to start the work. If we remove the module which will call cdns_i3c_master_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | cdns_i3c_master_hj cdns_i3c_master_remove | i3c_master_unregister(&master->base) | device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in cdns_i3c_master_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50062", "url": "https://ubuntu.com/security/CVE-2024-50062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-srv: Avoid null pointer deref during path establishment For RTRS path establishment, RTRS client initiates and completes con_num of connections. After establishing all its connections, the information is exchanged between the client and server through the info_req message. During this exchange, it is essential that all connections have been established, and the state of the RTRS srv path is CONNECTED. So add these sanity checks, to make sure we detect and abort process in error scenarios to avoid null pointer deref.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50095", "url": "https://ubuntu.com/security/CVE-2024-50095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mad: Improve handling of timed out WRs of mad agent Current timeout handler of mad agent acquires/releases mad_agent_priv lock for every timed out WRs. This causes heavy locking contention when higher no. of WRs are to be handled inside timeout handler. This leads to softlockup with below trace in some use cases where rdma-cm path is used to establish connection between peer nodes Trace: ----- BUG: soft lockup - CPU#4 stuck for 26s! [kworker/u128:3:19767] CPU: 4 PID: 19767 Comm: kworker/u128:3 Kdump: loaded Tainted: G OE ------- --- 5.14.0-427.13.1.el9_4.x86_64 #1 Hardware name: Dell Inc. PowerEdge R740/01YM03, BIOS 2.4.8 11/26/2019 Workqueue: ib_mad1 timeout_sends [ib_core] RIP: 0010:__do_softirq+0x78/0x2ac RSP: 0018:ffffb253449e4f98 EFLAGS: 00000246 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 000000000000001f RDX: 000000000000001d RSI: 000000003d1879ab RDI: fff363b66fd3a86b RBP: ffffb253604cbcd8 R08: 0000009065635f3b R09: 0000000000000000 R10: 0000000000000040 R11: ffffb253449e4ff8 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000040 FS: 0000000000000000(0000) GS:ffff8caa1fc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd9ec9db900 CR3: 0000000891934006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? __irq_exit_rcu+0xa1/0xc0 ? watchdog_timer_fn+0x1b2/0x210 ? __pfx_watchdog_timer_fn+0x10/0x10 ? __hrtimer_run_queues+0x127/0x2c0 ? hrtimer_interrupt+0xfc/0x210 ? __sysvec_apic_timer_interrupt+0x5c/0x110 ? sysvec_apic_timer_interrupt+0x37/0x90 ? asm_sysvec_apic_timer_interrupt+0x16/0x20 ? __do_softirq+0x78/0x2ac ? __do_softirq+0x60/0x2ac __irq_exit_rcu+0xa1/0xc0 sysvec_call_function_single+0x72/0x90 asm_sysvec_call_function_single+0x16/0x20 RIP: 0010:_raw_spin_unlock_irq+0x14/0x30 RSP: 0018:ffffb253604cbd88 EFLAGS: 00000247 RAX: 000000000001960d RBX: 0000000000000002 RCX: ffff8cad2a064800 RDX: 000000008020001b RSI: 0000000000000001 RDI: ffff8cad5d39f66c RBP: ffff8cad5d39f600 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8caa443e0c00 R11: ffffb253604cbcd8 R12: ffff8cacb8682538 R13: 0000000000000005 R14: ffffb253604cbd90 R15: ffff8cad5d39f66c cm_process_send_error+0x122/0x1d0 [ib_cm] timeout_sends+0x1dd/0x270 [ib_core] process_one_work+0x1e2/0x3b0 ? __pfx_worker_thread+0x10/0x10 worker_thread+0x50/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xdd/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x50 Simplified timeout handler by creating local list of timed out WRs and invoke send handler post creating the list. The new method acquires/ releases lock once to fetch the list and hence helps to reduce locking contetiong when processing higher no. of WRs", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50063", "url": "https://ubuntu.com/security/CVE-2024-50063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Prevent tail call between progs attached to different hooks bpf progs can be attached to kernel functions, and the attached functions can take different parameters or return different return values. If prog attached to one kernel function tail calls prog attached to another kernel function, the ctx access or return value verification could be bypassed. For example, if prog1 is attached to func1 which takes only 1 parameter and prog2 is attached to func2 which takes two parameters. Since verifier assumes the bpf ctx passed to prog2 is constructed based on func2's prototype, verifier allows prog2 to access the second parameter from the bpf ctx passed to it. The problem is that verifier does not prevent prog1 from passing its bpf ctx to prog2 via tail call. In this case, the bpf ctx passed to prog2 is constructed from func1 instead of func2, that is, the assumption for ctx access verification is bypassed. Another example, if BPF LSM prog1 is attached to hook file_alloc_security, and BPF LSM prog2 is attached to hook bpf_lsm_audit_rule_known. Verifier knows the return value rules for these two hooks, e.g. it is legal for bpf_lsm_audit_rule_known to return positive number 1, and it is illegal for file_alloc_security to return positive number. So verifier allows prog2 to return positive number 1, but does not allow prog1 to return positive number. The problem is that verifier does not prevent prog1 from calling prog2 via tail call. In this case, prog2's return value 1 will be used as the return value for prog1's hook file_alloc_security. That is, the return value rule is bypassed. This patch adds restriction for tail call to prevent such bypasses.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50191", "url": "https://ubuntu.com/security/CVE-2024-50191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: don't set SB_RDONLY after filesystem errors When the filesystem is mounted with errors=remount-ro, we were setting SB_RDONLY flag to stop all filesystem modifications. We knew this misses proper locking (sb->s_umount) and does not go through proper filesystem remount procedure but it has been the way this worked since early ext2 days and it was good enough for catastrophic situation damage mitigation. Recently, syzbot has found a way (see link) to trigger warnings in filesystem freezing because the code got confused by SB_RDONLY changing under its hands. Since these days we set EXT4_FLAGS_SHUTDOWN on the superblock which is enough to stop all filesystem modifications, modifying SB_RDONLY shouldn't be needed. So stop doing that.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50064", "url": "https://ubuntu.com/security/CVE-2024-50064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: zram: free secondary algorithms names We need to kfree() secondary algorithms names when reset zram device that had multi-streams, otherwise we leak memory. [senozhatsky@chromium.org: kfree(NULL) is legal] Link: https://lkml.kernel.org/r/20240917013021.868769-1-senozhatsky@chromium.org", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50065", "url": "https://ubuntu.com/security/CVE-2024-50065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Change to non-blocking allocation in ntfs_d_hash d_hash is done while under \"rcu-walk\" and should not sleep. __get_name() allocates using GFP_KERNEL, having the possibility to sleep when under memory pressure. Change the allocation to GFP_NOWAIT.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50089", "url": "https://ubuntu.com/security/CVE-2024-50089", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-49863", "url": "https://ubuntu.com/security/CVE-2024-49863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost/scsi: null-ptr-dereference in vhost_scsi_get_req() Since commit 3f8ca2e115e5 (\"vhost/scsi: Extract common handling code from control queue handler\") a null pointer dereference bug can be triggered when guest sends an SCSI AN request. In vhost_scsi_ctl_handle_vq(), `vc.target` is assigned with `&v_req.tmf.lun[1]` within a switch-case block and is then passed to vhost_scsi_get_req() which extracts `vc->req` and `tpg`. However, for a `VIRTIO_SCSI_T_AN_*` request, tpg is not required, so `vc.target` is set to NULL in this branch. Later, in vhost_scsi_get_req(), `vc->target` is dereferenced without being checked, leading to a null pointer dereference bug. This bug can be triggered from guest. When this bug occurs, the vhost_worker process is killed while holding `vq->mutex` and the corresponding tpg will remain occupied indefinitely. Below is the KASAN report: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 PID: 840 Comm: poc Not tainted 6.10.0+ #1 Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:vhost_scsi_get_req+0x165/0x3a0 Code: 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 02 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 65 30 4c 89 e2 48 c1 ea 03 <0f> b6 04 02 4c 89 e2 83 e2 07 38 d0 7f 08 84 c0 0f 85 be 01 00 00 RSP: 0018:ffff888017affb50 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffff88801b000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888017affcb8 RBP: ffff888017affb80 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff888017affc88 R14: ffff888017affd1c R15: ffff888017993000 FS: 000055556e076500(0000) GS:ffff88806b100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200027c0 CR3: 0000000010ed0004 CR4: 0000000000370ef0 Call Trace: ? show_regs+0x86/0xa0 ? die_addr+0x4b/0xd0 ? exc_general_protection+0x163/0x260 ? asm_exc_general_protection+0x27/0x30 ? vhost_scsi_get_req+0x165/0x3a0 vhost_scsi_ctl_handle_vq+0x2a4/0xca0 ? __pfx_vhost_scsi_ctl_handle_vq+0x10/0x10 ? __switch_to+0x721/0xeb0 ? __schedule+0xda5/0x5710 ? __kasan_check_write+0x14/0x30 ? _raw_spin_lock+0x82/0xf0 vhost_scsi_ctl_handle_kick+0x52/0x90 vhost_run_work_list+0x134/0x1b0 vhost_task_fn+0x121/0x350 ... ---[ end trace 0000000000000000 ]--- Let's add a check in vhost_scsi_get_req. [whitespace fixes]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49864", "url": "https://ubuntu.com/security/CVE-2024-49864", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix a race between socket set up and I/O thread creation In rxrpc_open_socket(), it sets up the socket and then sets up the I/O thread that will handle it. This is a problem, however, as there's a gap between the two phases in which a packet may come into rxrpc_encap_rcv() from the UDP packet but we oops when trying to wake the not-yet created I/O thread. As a quick fix, just make rxrpc_encap_rcv() discard the packet if there's no I/O thread yet. A better, but more intrusive fix would perhaps be to rearrange things such that the socket creation is done by the I/O thread.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49865", "url": "https://ubuntu.com/security/CVE-2024-49865", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: move xa_alloc to prevent UAF Evil user can guess the next id of the vm before the ioctl completes and then call vm destroy ioctl to trigger UAF since create ioctl is still referencing the same vm. Move the xa_alloc all the way to the end to prevent this. v2: - Rebase (cherry picked from commit dcfd3971327f3ee92765154baebbaece833d3ca9)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49955", "url": "https://ubuntu.com/security/CVE-2024-49955", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: battery: Fix possible crash when unregistering a battery hook When a battery hook returns an error when adding a new battery, then the battery hook is automatically unregistered. However the battery hook provider cannot know that, so it will later call battery_hook_unregister() on the already unregistered battery hook, resulting in a crash. Fix this by using the list head to mark already unregistered battery hooks as already being unregistered so that they can be ignored by battery_hook_unregister().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49973", "url": "https://ubuntu.com/security/CVE-2024-49973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: r8169: add tally counter fields added with RTL8125 RTL8125 added fields to the tally counter, what may result in the chip dma'ing these new fields to unallocated memory. Therefore make sure that the allocated memory area is big enough to hold all of the tally counter values, even if we use only parts of it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49974", "url": "https://ubuntu.com/security/CVE-2024-49974", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Limit the number of concurrent async COPY operations Nothing appears to limit the number of concurrent async COPY operations that clients can start. In addition, AFAICT each async COPY can copy an unlimited number of 4MB chunks, so can run for a long time. Thus IMO async COPY can become a DoS vector. Add a restriction mechanism that bounds the number of concurrent background COPY operations. Start simple and try to be fair -- this patch implements a per-namespace limit. An async COPY request that occurs while this limit is exceeded gets NFS4ERR_DELAY. The requesting client can choose to send the request again after a delay or fall back to a traditional read/write style copy. If there is need to make the mechanism more sophisticated, we can visit that in future patches.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49975", "url": "https://ubuntu.com/security/CVE-2024-49975", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uprobes: fix kernel info leak via \"[uprobes]\" vma xol_add_vma() maps the uninitialized page allocated by __create_xol_area() into userspace. On some architectures (x86) this memory is readable even without VM_READ, VM_EXEC results in the same pgprot_t as VM_EXEC|VM_READ, although this doesn't really matter, debugger can read this memory anyway.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50003", "url": "https://ubuntu.com/security/CVE-2024-50003", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix system hang while resume with TBT monitor [Why] Connected with a Thunderbolt monitor and do the suspend and the system may hang while resume. The TBT monitor HPD will be triggered during the resume procedure and call the drm_client_modeset_probe() while struct drm_connector connector->dev->master is NULL. It will mess up the pipe topology after resume. [How] Skip the TBT monitor HPD during the resume procedure because we currently will probe the connectors after resume by default. (cherry picked from commit 453f86a26945207a16b8f66aaed5962dc2b95b85)", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50173", "url": "https://ubuntu.com/security/CVE-2024-50173", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix access to uninitialized variable in tick_ctx_cleanup() The group variable can't be used to retrieve ptdev in our second loop, because it points to the previously iterated list_head, not a valid group. Get the ptdev object from the scheduler instead.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49866", "url": "https://ubuntu.com/security/CVE-2024-49866", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Fix a race during cpuhp processing There is another found exception that the \"timerlat/1\" thread was scheduled on CPU0, and lead to timer corruption finally: ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ``` After tracing the scheduling event, it was discovered that the migration of the \"timerlat/1\" thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() | To fix this, skip online processing if the CPU is already offline.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49976", "url": "https://ubuntu.com/security/CVE-2024-49976", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Drop interface_lock in stop_kthread() stop_kthread() is the offline callback for \"trace/osnoise:online\", since commit 5bfbcd1ee57b (\"tracing/timerlat: Add interface_lock around clearing of kthread in stop_kthread()\"), the following ABBA deadlock scenario is introduced: T1 | T2 [BP] | T3 [AP] osnoise_hotplug_workfn() | work_for_cpu_fn() | cpuhp_thread_fun() | _cpu_down() | osnoise_cpu_die() mutex_lock(&interface_lock) | | stop_kthread() | cpus_write_lock() | mutex_lock(&interface_lock) cpus_read_lock() | cpuhp_kick_ap() | As the interface_lock here in just for protecting the \"kthread\" field of the osn_var, use xchg() instead to fix this issue. Also use for_each_online_cpu() back in stop_per_cpu_kthreads() as it can take cpu_read_lock() again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50005", "url": "https://ubuntu.com/security/CVE-2024-50005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: Fix potential RCU dereference issue in mac802154_scan_worker In the `mac802154_scan_worker` function, the `scan_req->type` field was accessed after the RCU read-side critical section was unlocked. According to RCU usage rules, this is illegal and can lead to unpredictable behavior, such as accessing memory that has been updated or causing use-after-free issues. This possible bug was identified using a static analysis tool developed by myself, specifically designed to detect RCU-related issues. To address this, the `scan_req->type` value is now stored in a local variable `scan_req_type` while still within the RCU read-side critical section. The `scan_req_type` is then used after the RCU lock is released, ensuring that the type value is safely accessed without violating RCU rules.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50012", "url": "https://ubuntu.com/security/CVE-2024-50012", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: Avoid a bad reference count on CPU node In the parse_perf_domain function, if the call to of_parse_phandle_with_args returns an error, then the reference to the CPU device node that was acquired at the start of the function would not be properly decremented. Address this by declaring the variable with the __free(device_node) cleanup attribute.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49867", "url": "https://ubuntu.com/security/CVE-2024-49867", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: wait for fixup workers before stopping cleaner kthread during umount During unmount, at close_ctree(), we have the following steps in this order: 1) Park the cleaner kthread - this doesn't destroy the kthread, it basically halts its execution (wake ups against it work but do nothing); 2) We stop the cleaner kthread - this results in freeing the respective struct task_struct; 3) We call btrfs_stop_all_workers() which waits for any jobs running in all the work queues and then free the work queues. Syzbot reported a case where a fixup worker resulted in a crash when doing a delayed iput on its inode while attempting to wake up the cleaner at btrfs_add_delayed_iput(), because the task_struct of the cleaner kthread was already freed. This can happen during unmount because we don't wait for any fixup workers still running before we call kthread_stop() against the cleaner kthread, which stops and free all its resources. Fix this by waiting for any fixup workers at close_ctree() before we call kthread_stop() against the cleaner and run pending delayed iputs. The stack traces reported by syzbot were the following: BUG: KASAN: slab-use-after-free in __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 Read of size 8 at addr ffff8880272a8a18 by task kworker/u8:3/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.12.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: btrfs-fixup btrfs_work_helper 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 __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline] try_to_wake_up+0xb0/0x1480 kernel/sched/core.c:4154 btrfs_writepage_fixup_worker+0xc16/0xdf0 fs/btrfs/inode.c:2842 btrfs_work_helper+0x390/0xc50 fs/btrfs/async-thread.c:314 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Allocated by task 2: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:319 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345 kasan_slab_alloc include/linux/kasan.h:247 [inline] slab_post_alloc_hook mm/slub.c:4086 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4187 alloc_task_struct_node kernel/fork.c:180 [inline] dup_task_struct+0x57/0x8c0 kernel/fork.c:1107 copy_process+0x5d1/0x3d50 kernel/fork.c:2206 kernel_clone+0x223/0x880 kernel/fork.c:2787 kernel_thread+0x1bc/0x240 kernel/fork.c:2849 create_kthread kernel/kthread.c:412 [inline] kthreadd+0x60d/0x810 kernel/kthread.c:765 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Freed by task 61: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:230 [inline] slab_free_h ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49868", "url": "https://ubuntu.com/security/CVE-2024-49868", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix a NULL pointer dereference when failed to start a new trasacntion [BUG] Syzbot reported a NULL pointer dereference with the following crash: FAULT_INJECTION: forcing a failure. start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676 prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642 relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678 ... BTRFS info (device loop0): balance: ended with status: -12 Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667] RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926 Call Trace: commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496 btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430 del_balance_item fs/btrfs/volumes.c:3678 [inline] reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742 btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574 btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673 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/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [CAUSE] The allocation failure happens at the start_transaction() inside prepare_to_relocate(), and during the error handling we call unset_reloc_control(), which makes fs_info->balance_ctl to be NULL. Then we continue the error path cleanup in btrfs_balance() by calling reset_balance_state() which will call del_balance_item() to fully delete the balance item in the root tree. However during the small window between set_reloc_contrl() and unset_reloc_control(), we can have a subvolume tree update and created a reloc_root for that subvolume. Then we go into the final btrfs_commit_transaction() of del_balance_item(), and into btrfs_update_reloc_root() inside commit_fs_roots(). That function checks if fs_info->reloc_ctl is in the merge_reloc_tree stage, but since fs_info->reloc_ctl is NULL, it results a NULL pointer dereference. [FIX] Just add extra check on fs_info->reloc_ctl inside btrfs_update_reloc_root(), before checking fs_info->reloc_ctl->merge_reloc_tree. That DEAD_RELOC_TREE handling is to prevent further modification to the reloc tree during merge stage, but since there is no reloc_ctl at all, we do not need to bother that.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49869", "url": "https://ubuntu.com/security/CVE-2024-49869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: send: fix buffer overflow detection when copying path to cache entry Starting with commit c0247d289e73 (\"btrfs: send: annotate struct name_cache_entry with __counted_by()\") we annotated the variable length array \"name\" from the name_cache_entry structure with __counted_by() to improve overflow detection. However that alone was not correct, because the length of that array does not match the \"name_len\" field - it matches that plus 1 to include the NUL string terminator, so that makes a fortified kernel think there's an overflow and report a splat like this: strcpy: detected buffer overflow: 20 byte write of buffer size 19 WARNING: CPU: 3 PID: 3310 at __fortify_report+0x45/0x50 CPU: 3 UID: 0 PID: 3310 Comm: btrfs Not tainted 6.11.0-prnet #1 Hardware name: CompuLab Ltd. sbc-ihsw/Intense-PC2 (IPC2), BIOS IPC2_3.330.7 X64 03/15/2018 RIP: 0010:__fortify_report+0x45/0x50 Code: 48 8b 34 (...) RSP: 0018:ffff97ebc0d6f650 EFLAGS: 00010246 RAX: 7749924ef60fa600 RBX: ffff8bf5446a521a RCX: 0000000000000027 RDX: 00000000ffffdfff RSI: ffff97ebc0d6f548 RDI: ffff8bf84e7a1cc8 RBP: ffff8bf548574080 R08: ffffffffa8c40e10 R09: 0000000000005ffd R10: 0000000000000004 R11: ffffffffa8c70e10 R12: ffff8bf551eef400 R13: 0000000000000000 R14: 0000000000000013 R15: 00000000000003a8 FS: 00007fae144de8c0(0000) GS:ffff8bf84e780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fae14691690 CR3: 00000001027a2003 CR4: 00000000001706f0 Call Trace: ? __warn+0x12a/0x1d0 ? __fortify_report+0x45/0x50 ? report_bug+0x154/0x1c0 ? handle_bug+0x42/0x70 ? exc_invalid_op+0x1a/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? __fortify_report+0x45/0x50 __fortify_panic+0x9/0x10 __get_cur_name_and_parent+0x3bc/0x3c0 get_cur_path+0x207/0x3b0 send_extent_data+0x709/0x10d0 ? find_parent_nodes+0x22df/0x25d0 ? mas_nomem+0x13/0x90 ? mtree_insert_range+0xa5/0x110 ? btrfs_lru_cache_store+0x5f/0x1e0 ? iterate_extent_inodes+0x52d/0x5a0 process_extent+0xa96/0x11a0 ? __pfx_lookup_backref_cache+0x10/0x10 ? __pfx_store_backref_cache+0x10/0x10 ? __pfx_iterate_backrefs+0x10/0x10 ? __pfx_check_extent_item+0x10/0x10 changed_cb+0x6fa/0x930 ? tree_advance+0x362/0x390 ? memcmp_extent_buffer+0xd7/0x160 send_subvol+0xf0a/0x1520 btrfs_ioctl_send+0x106b/0x11d0 ? __pfx___clone_root_cmp_sort+0x10/0x10 _btrfs_ioctl_send+0x1ac/0x240 btrfs_ioctl+0x75b/0x850 __se_sys_ioctl+0xca/0x150 do_syscall_64+0x85/0x160 ? __count_memcg_events+0x69/0x100 ? handle_mm_fault+0x1327/0x15c0 ? __se_sys_rt_sigprocmask+0xf1/0x180 ? syscall_exit_to_user_mode+0x75/0xa0 ? do_syscall_64+0x91/0x160 ? do_user_addr_fault+0x21d/0x630 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fae145eeb4f Code: 00 48 89 (...) RSP: 002b:00007ffdf1cb09b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fae145eeb4f RDX: 00007ffdf1cb0ad0 RSI: 0000000040489426 RDI: 0000000000000004 RBP: 00000000000078fe R08: 00007fae144006c0 R09: 00007ffdf1cb0927 R10: 0000000000000008 R11: 0000000000000246 R12: 00007ffdf1cb1ce8 R13: 0000000000000003 R14: 000055c499fab2e0 R15: 0000000000000004 Fix this by not storing the NUL string terminator since we don't actually need it for name cache entries, this way \"name_len\" corresponds to the actual size of the \"name\" array. This requires marking the \"name\" array field with __nonstring and using memcpy() instead of strcpy() as recommended by the guidelines at: https://github.com/KSPP/linux/issues/90", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49870", "url": "https://ubuntu.com/security/CVE-2024-49870", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cachefiles: fix dentry leak in cachefiles_open_file() A dentry leak may be caused when a lookup cookie and a cull are concurrent: P1 | P2 ----------------------------------------------------------- cachefiles_lookup_cookie cachefiles_look_up_object lookup_one_positive_unlocked // get dentry cachefiles_cull inode->i_flags |= S_KERNEL_FILE; cachefiles_open_file cachefiles_mark_inode_in_use __cachefiles_mark_inode_in_use can_use = false if (!(inode->i_flags & S_KERNEL_FILE)) can_use = true \t return false return false // Returns an error but doesn't put dentry After that the following WARNING will be triggered when the backend folder is umounted: ================================================================== BUG: Dentry 000000008ad87947{i=7a,n=Dx_1_1.img} still in use (1) [unmount of ext4 sda] WARNING: CPU: 4 PID: 359261 at fs/dcache.c:1767 umount_check+0x5d/0x70 CPU: 4 PID: 359261 Comm: umount Not tainted 6.6.0-dirty #25 RIP: 0010:umount_check+0x5d/0x70 Call Trace: d_walk+0xda/0x2b0 do_one_tree+0x20/0x40 shrink_dcache_for_umount+0x2c/0x90 generic_shutdown_super+0x20/0x160 kill_block_super+0x1a/0x40 ext4_kill_sb+0x22/0x40 deactivate_locked_super+0x35/0x80 cleanup_mnt+0x104/0x160 ================================================================== Whether cachefiles_open_file() returns true or false, the reference count obtained by lookup_positive_unlocked() in cachefiles_look_up_object() should be released. Therefore release that reference count in cachefiles_look_up_object() to fix the above issue and simplify the code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49871", "url": "https://ubuntu.com/security/CVE-2024-49871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: adp5589-keys - fix NULL pointer dereference We register a devm action to call adp5589_clear_config() and then pass the i2c client as argument so that we can call i2c_get_clientdata() in order to get our device object. However, i2c_set_clientdata() is only being set at the end of the probe function which means that we'll get a NULL pointer dereference in case the probe function fails early.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49872", "url": "https://ubuntu.com/security/CVE-2024-49872", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/gup: fix memfd_pin_folios alloc race panic If memfd_pin_folios tries to create a hugetlb page, but someone else already did, then folio gets the value -EEXIST here: folio = memfd_alloc_folio(memfd, start_idx); if (IS_ERR(folio)) { ret = PTR_ERR(folio); if (ret != -EEXIST) goto err; then on the next trip through the \"while start_idx\" loop we panic here: if (folio) { folio_put(folio); To fix, set the folio to NULL on error.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49964", "url": "https://ubuntu.com/security/CVE-2024-49964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix memfd_pin_folios free_huge_pages leak memfd_pin_folios followed by unpin_folios fails to restore free_huge_pages if the pages were not already faulted in, because the folio refcount for pages created by memfd_alloc_folio never goes to 0. memfd_pin_folios needs another folio_put to undo the folio_try_get below: memfd_alloc_folio() alloc_hugetlb_folio_nodemask() dequeue_hugetlb_folio_nodemask() dequeue_hugetlb_folio_node_exact() folio_ref_unfreeze(folio, 1); ; adds 1 refcount folio_try_get() ; adds 1 refcount hugetlb_add_to_page_cache() ; adds 512 refcount (on x86) With the fix, after memfd_pin_folios + unpin_folios, the refcount for the (unfaulted) page is 512, which is correct, as the refcount for a faulted unpinned page is 513.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49873", "url": "https://ubuntu.com/security/CVE-2024-49873", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/filemap: fix filemap_get_folios_contig THP panic Patch series \"memfd-pin huge page fixes\". Fix multiple bugs that occur when using memfd_pin_folios with hugetlb pages and THP. The hugetlb bugs only bite when the page is not yet faulted in when memfd_pin_folios is called. The THP bug bites when the starting offset passed to memfd_pin_folios is not huge page aligned. See the commit messages for details. This patch (of 5): memfd_pin_folios on memory backed by THP panics if the requested start offset is not huge page aligned: BUG: kernel NULL pointer dereference, address: 0000000000000036 RIP: 0010:filemap_get_folios_contig+0xdf/0x290 RSP: 0018:ffffc9002092fbe8 EFLAGS: 00010202 RAX: 0000000000000002 RBX: 0000000000000002 RCX: 0000000000000002 The fault occurs here, because xas_load returns a folio with value 2: filemap_get_folios_contig() for (folio = xas_load(&xas); folio && xas.xa_index <= end; folio = xas_next(&xas)) { ... if (!folio_try_get(folio)) <-- BOOM \"2\" is an xarray sibling entry. We get it because memfd_pin_folios does not round the indices passed to filemap_get_folios_contig to huge page boundaries for THP, so we load from the middle of a huge page range see a sibling. (It does round for hugetlbfs, at the is_file_hugepages test). To fix, if the folio is a sibling, then return the next index as the starting point for the next call to filemap_get_folios_contig.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49977", "url": "https://ubuntu.com/security/CVE-2024-49977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: Fix zero-division error when disabling tc cbs The commit b8c43360f6e4 (\"net: stmmac: No need to calculate speed divider when offload is disabled\") allows the \"port_transmit_rate_kbps\" to be set to a value of 0, which is then passed to the \"div_s64\" function when tc-cbs is disabled. This leads to a zero-division error. When tc-cbs is disabled, the idleslope, sendslope, and credit values the credit values are not required to be configured. Therefore, adding a return statement after setting the txQ mode to DCB when tc-cbs is disabled would prevent a zero-division error.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49978", "url": "https://ubuntu.com/security/CVE-2024-49978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gso: fix udp gso fraglist segmentation after pull from frag_list Detect gso fraglist skbs with corrupted geometry (see below) and pass these to skb_segment instead of skb_segment_list, as the first can segment them correctly. 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 these skbs, breaking these invariants. In extreme cases they pull all data into skb linear. For UDP, this causes a NULL ptr deref in __udpv4_gso_segment_list_csum at udp_hdr(seg->next)->dest. Detect invalid geometry due to pull, by checking head_skb size. Don't just drop, as this may blackhole a destination. Convert to be able to pass to regular skb_segment.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49979", "url": "https://ubuntu.com/security/CVE-2024-49979", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gso: fix tcp fraglist segmentation after pull from frag_list Detect tcp gso fraglist skbs with corrupted geometry (see below) and pass these to skb_segment instead of skb_segment_list, as the first can segment them correctly. 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 these skbs, breaking these invariants. In extreme cases they pull all data into skb linear. For TCP, this causes a NULL ptr deref in __tcpv4_gso_segment_list_csum at tcp_hdr(seg->next). Detect invalid geometry due to pull, by checking head_skb size. Don't just drop, as this may blackhole a destination. Convert to be able to pass to regular skb_segment. Approach and description based on a patch by Willem de Bruijn.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49980", "url": "https://ubuntu.com/security/CVE-2024-49980", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vrf: revert \"vrf: Remove unnecessary RCU-bh critical section\" This reverts commit 504fc6f4f7f681d2a03aa5f68aad549d90eab853. dev_queue_xmit_nit is expected to be called with BH disabled. __dev_queue_xmit has the following: /* Disable soft irqs for various locks below. Also * stops preemption for RCU. */ rcu_read_lock_bh(); VRF must follow this invariant. The referenced commit removed this protection. Which triggered a lockdep warning: \t================================ \tWARNING: inconsistent lock state \t6.11.0 #1 Tainted: G W \t-------------------------------- \tinconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage. \tbtserver/134819 [HC0[0]:SC0[0]:HE1:SE1] takes: \tffff8882da30c118 (rlock-AF_PACKET){+.?.}-{2:2}, at: tpacket_rcv+0x863/0x3b30 \t{IN-SOFTIRQ-W} state was registered at: \t lock_acquire+0x19a/0x4f0 \t _raw_spin_lock+0x27/0x40 \t packet_rcv+0xa33/0x1320 \t __netif_receive_skb_core.constprop.0+0xcb0/0x3a90 \t __netif_receive_skb_list_core+0x2c9/0x890 \t netif_receive_skb_list_internal+0x610/0xcc0 [...] \tother info that might help us debug this: \t Possible unsafe locking scenario: \t CPU0 \t ---- \t lock(rlock-AF_PACKET); \t \t lock(rlock-AF_PACKET); \t *** DEADLOCK *** \tCall Trace: \t \t dump_stack_lvl+0x73/0xa0 \t mark_lock+0x102e/0x16b0 \t __lock_acquire+0x9ae/0x6170 \t lock_acquire+0x19a/0x4f0 \t _raw_spin_lock+0x27/0x40 \t tpacket_rcv+0x863/0x3b30 \t dev_queue_xmit_nit+0x709/0xa40 \t vrf_finish_direct+0x26e/0x340 [vrf] \t vrf_l3_out+0x5f4/0xe80 [vrf] \t __ip_local_out+0x51e/0x7a0 [...]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49981", "url": "https://ubuntu.com/security/CVE-2024-49981", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: venus: fix use after free bug in venus_remove due to race condition in venus_probe, core->work is bound with venus_sys_error_handler, which is used to handle error. The code use core->sys_err_done to make sync work. The core->work is started in venus_event_notify. If we call venus_remove, there might be an unfished work. The possible sequence is as follows: CPU0 CPU1 |venus_sys_error_handler venus_remove | hfi_destroy\t \t\t | venus_hfi_destroy\t | kfree(hdev);\t | |hfi_reinit \t\t\t\t\t |venus_hfi_queues_reinit |//use hdev Fix it by canceling the work in venus_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49956", "url": "https://ubuntu.com/security/CVE-2024-49956", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: fix double destroy_workqueue error When gfs2_fill_super() fails, destroy_workqueue() is called within gfs2_gl_hash_clear(), and the subsequent code path calls destroy_workqueue() on the same work queue again. This issue can be fixed by setting the work queue pointer to NULL after the first destroy_workqueue() call and checking for a NULL pointer before attempting to destroy the work queue again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50176", "url": "https://ubuntu.com/security/CVE-2024-50176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: k3-r5: Fix error handling when power-up failed By simply bailing out, the driver was violating its rule and internal assumptions that either both or no rproc should be initialized. E.g., this could cause the first core to be available but not the second one, leading to crashes on its shutdown later on while trying to dereference that second instance.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49982", "url": "https://ubuntu.com/security/CVE-2024-49982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: aoe: fix the potential use-after-free problem in more places For fixing CVE-2023-6270, f98364e92662 (\"aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts\") makes tx() calling dev_put() instead of doing in aoecmd_cfg_pkts(). It avoids that the tx() runs into use-after-free. Then Nicolai Stange found more places in aoe have potential use-after-free problem with tx(). e.g. revalidate(), aoecmd_ata_rw(), resend(), probe() and aoecmd_cfg_rsp(). Those functions also use aoenet_xmit() to push packet to tx queue. So they should also use dev_hold() to increase the refcnt of skb->dev. On the other hand, moving dev_put() to tx() causes that the refcnt of skb->dev be reduced to a negative value, because corresponding dev_hold() are not called in revalidate(), aoecmd_ata_rw(), resend(), probe(), and aoecmd_cfg_rsp(). This patch fixed this issue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49874", "url": "https://ubuntu.com/security/CVE-2024-49874", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: svc: Fix use after free vulnerability in svc_i3c_master Driver Due to Race Condition In the svc_i3c_master_probe function, &master->hj_work is bound with svc_i3c_master_hj_work, &master->ibi_work is bound with svc_i3c_master_ibi_work. And svc_i3c_master_ibi_work can start the hj_work, svc_i3c_master_irq_handler can start the ibi_work. If we remove the module which will call svc_i3c_master_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | svc_i3c_master_hj_work svc_i3c_master_remove | i3c_master_unregister(&master->base)| device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in svc_i3c_master_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49875", "url": "https://ubuntu.com/security/CVE-2024-49875", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: map the EBADMSG to nfserr_io to avoid warning Ext4 will throw -EBADMSG through ext4_readdir when a checksum error occurs, resulting in the following WARNING. Fix it by mapping EBADMSG to nfserr_io. nfsd_buffered_readdir iterate_dir // -EBADMSG -74 ext4_readdir // .iterate_shared ext4_dx_readdir ext4_htree_fill_tree htree_dirblock_to_tree ext4_read_dirblock __ext4_read_dirblock ext4_dirblock_csum_verify warn_no_space_for_csum __warn_no_space_for_csum return ERR_PTR(-EFSBADCRC) // -EBADMSG -74 nfserrno // WARNING [ 161.115610] ------------[ cut here ]------------ [ 161.116465] nfsd: non-standard errno: -74 [ 161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0 [ 161.118596] Modules linked in: [ 161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138 [ 161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qe mu.org 04/01/2014 [ 161.123601] RIP: 0010:nfserrno+0x9d/0xd0 [ 161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6 05 ce 2b 61 03 01 e8 99 20 d8 00 <0f> 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33 [ 161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286 [ 161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a [ 161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827 [ 161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021 [ 161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8 [ 161.135244] FS: 0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000 [ 161.136695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0 [ 161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 161.141519] PKRU: 55555554 [ 161.142076] Call Trace: [ 161.142575] ? __warn+0x9b/0x140 [ 161.143229] ? nfserrno+0x9d/0xd0 [ 161.143872] ? report_bug+0x125/0x150 [ 161.144595] ? handle_bug+0x41/0x90 [ 161.145284] ? exc_invalid_op+0x14/0x70 [ 161.146009] ? asm_exc_invalid_op+0x12/0x20 [ 161.146816] ? nfserrno+0x9d/0xd0 [ 161.147487] nfsd_buffered_readdir+0x28b/0x2b0 [ 161.148333] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.149258] ? nfsd_buffered_filldir+0xf0/0xf0 [ 161.150093] ? wait_for_concurrent_writes+0x170/0x170 [ 161.151004] ? generic_file_llseek_size+0x48/0x160 [ 161.151895] nfsd_readdir+0x132/0x190 [ 161.152606] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.153516] ? nfsd_unlink+0x380/0x380 [ 161.154256] ? override_creds+0x45/0x60 [ 161.155006] nfsd4_encode_readdir+0x21a/0x3d0 [ 161.155850] ? nfsd4_encode_readlink+0x210/0x210 [ 161.156731] ? write_bytes_to_xdr_buf+0x97/0xe0 [ 161.157598] ? __write_bytes_to_xdr_buf+0xd0/0xd0 [ 161.158494] ? lock_downgrade+0x90/0x90 [ 161.159232] ? nfs4svc_decode_voidarg+0x10/0x10 [ 161.160092] nfsd4_encode_operation+0x15a/0x440 [ 161.160959] nfsd4_proc_compound+0x718/0xe90 [ 161.161818] nfsd_dispatch+0x18e/0x2c0 [ 161.162586] svc_process_common+0x786/0xc50 [ 161.163403] ? nfsd_svc+0x380/0x380 [ 161.164137] ? svc_printk+0x160/0x160 [ 161.164846] ? svc_xprt_do_enqueue.part.0+0x365/0x380 [ 161.165808] ? nfsd_svc+0x380/0x380 [ 161.166523] ? rcu_is_watching+0x23/0x40 [ 161.167309] svc_process+0x1a5/0x200 [ 161.168019] nfsd+0x1f5/0x380 [ 161.168663] ? nfsd_shutdown_threads+0x260/0x260 [ 161.169554] kthread+0x1c4/0x210 [ 161.170224] ? kthread_insert_work_sanity_check+0x80/0x80 [ 161.171246] ret_from_fork+0x1f/0x30", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50013", "url": "https://ubuntu.com/security/CVE-2024-50013", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix memory leak in exfat_load_bitmap() If the first directory entry in the root directory is not a bitmap directory entry, 'bh' will not be released and reassigned, which will cause a memory leak.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49876", "url": "https://ubuntu.com/security/CVE-2024-49876", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: fix UAF around queue destruction We currently do stuff like queuing the final destruction step on a random system wq, which will outlive the driver instance. With bad timing we can teardown the driver with one or more work workqueue still being alive leading to various UAF splats. Add a fini step to ensure user queues are properly torn down. At this point GuC should already be nuked so queue itself should no longer be referenced from hw pov. v2 (Matt B) - Looks much safer to use a waitqueue and then just wait for the xa_array to become empty before triggering the drain. (cherry picked from commit 861108666cc0e999cffeab6aff17b662e68774e3)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49877", "url": "https://ubuntu.com/security/CVE-2024-49877", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate When doing cleanup, if flags without OCFS2_BH_READAHEAD, it may trigger NULL pointer dereference in the following ocfs2_set_buffer_uptodate() if bh is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49957", "url": "https://ubuntu.com/security/CVE-2024-49957", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix null-ptr-deref when journal load failed. During the mounting process, if journal_reset() fails because of too short journal, then lead to jbd2_journal_load() fails with NULL j_sb_buffer. Subsequently, ocfs2_journal_shutdown() calls jbd2_journal_flush()->jbd2_cleanup_journal_tail()-> __jbd2_update_log_tail()->jbd2_journal_update_sb_log_tail() ->lock_buffer(journal->j_sb_buffer), resulting in a null-pointer dereference error. To resolve this issue, we should check the JBD2_LOADED flag to ensure the journal was properly loaded. Additionally, use journal instead of osb->journal directly to simplify the code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49965", "url": "https://ubuntu.com/security/CVE-2024-49965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove unreasonable unlock in ocfs2_read_blocks Patch series \"Misc fixes for ocfs2_read_blocks\", v5. This series contains 2 fixes for ocfs2_read_blocks(). The first patch fix the issue reported by syzbot, which detects bad unlock balance in ocfs2_read_blocks(). The second patch fixes an issue reported by Heming Zhao when reviewing above fix. This patch (of 2): There was a lock release before exiting, so remove the unreasonable unlock.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49966", "url": "https://ubuntu.com/security/CVE-2024-49966", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: cancel dqi_sync_work before freeing oinfo ocfs2_global_read_info() will initialize and schedule dqi_sync_work at the end, if error occurs after successfully reading global quota, it will trigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled: ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16c This reports that there is an active delayed work when freeing oinfo in error handling, so cancel dqi_sync_work first. BTW, return status instead of -1 when .read_file_info fails.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49958", "url": "https://ubuntu.com/security/CVE-2024-49958", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reserve space for inline xattr before attaching reflink tree One of our customers reported a crash and a corrupted ocfs2 filesystem. The crash was due to the detection of corruption. Upon troubleshooting, the fsck -fn output showed the below corruption [EXTENT_LIST_FREE] Extent list in owner 33080590 claims 230 as the next free chain record, but fsck believes the largest valid value is 227. Clamp the next record value? n The stat output from the debugfs.ocfs2 showed the following corruption where the \"Next Free Rec:\" had overshot the \"Count:\" in the root metadata block. Inode: 33080590 Mode: 0640 Generation: 2619713622 (0x9c25a856) FS Generation: 904309833 (0x35e6ac49) CRC32: 00000000 ECC: 0000 Type: Regular Attr: 0x0 Flags: Valid Dynamic Features: (0x16) HasXattr InlineXattr Refcounted Extended Attributes Block: 0 Extended Attributes Inline Size: 256 User: 0 (root) Group: 0 (root) Size: 281320357888 Links: 1 Clusters: 141738 ctime: 0x66911b56 0x316edcb8 -- Fri Jul 12 06:02:30.829349048 2024 atime: 0x66911d6b 0x7f7a28d -- Fri Jul 12 06:11:23.133669517 2024 mtime: 0x66911b56 0x12ed75d7 -- Fri Jul 12 06:02:30.317552087 2024 dtime: 0x0 -- Wed Dec 31 17:00:00 1969 Refcount Block: 2777346 Last Extblk: 2886943 Orphan Slot: 0 Sub Alloc Slot: 0 Sub Alloc Bit: 14 Tree Depth: 1 Count: 227 Next Free Rec: 230 ## Offset Clusters Block# 0 0 2310 2776351 1 2310 2139 2777375 2 4449 1221 2778399 3 5670 731 2779423 4 6401 566 2780447 ....... .... ....... ....... .... ....... The issue was in the reflink workfow while reserving space for inline xattr. The problematic function is ocfs2_reflink_xattr_inline(). By the time this function is called the reflink tree is already recreated at the destination inode from the source inode. At this point, this function reserves space for inline xattrs at the destination inode without even checking if there is space at the root metadata block. It simply reduces the l_count from 243 to 227 thereby making space of 256 bytes for inline xattr whereas the inode already has extents beyond this index (in this case up to 230), thereby causing corruption. The fix for this is to reserve space for inline metadata at the destination inode before the reflink tree gets recreated. The customer has verified the fix.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49959", "url": "https://ubuntu.com/security/CVE-2024-49959", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail() to recover some journal space. But if an error occurs while executing jbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for free space right away, we try other branches, and if j_committing_transaction is NULL (i.e., the tid is 0), we will get the following complain: ============================================ JBD2: I/O error when updating journal superblock for sdd-8. __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available __jbd2_log_wait_for_space: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Call Trace: add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70 [...] ============================================ So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways. Note that this fix relies on commit 6f6a6fda2945 (\"jbd2: fix ocfs2 corrupt when updating journal superblock fails\") to make jbd2_cleanup_journal_tail return the correct error code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49878", "url": "https://ubuntu.com/security/CVE-2024-49878", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: resource: fix region_intersects() vs add_memory_driver_managed() On a system with CXL memory, the resource tree (/proc/iomem) related to CXL memory may look like something as follows. 490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem) Because drivers/dax/kmem.c calls add_memory_driver_managed() during onlining CXL memory, which makes \"System RAM (kmem)\" a descendant of \"CXL Window X\". This confuses region_intersects(), which expects all \"System RAM\" resources to be at the top level of iomem_resource. This can lead to bugs. For example, when the following command line is executed to write some memory in CXL memory range via /dev/mem, $ dd if=data of=/dev/mem bs=$((1 << 10)) seek=$((0x490000000 >> 10)) count=1 dd: error writing '/dev/mem': Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/s the command fails as expected. However, the error code is wrong. It should be \"Operation not permitted\" instead of \"Bad address\". More seriously, the /dev/mem permission checking in devmem_is_allowed() passes incorrectly. Although the accessing is prevented later because ioremap() isn't allowed to map system RAM, it is a potential security issue. During command executing, the following warning is reported in the kernel log for calling ioremap() on system RAM. ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d Call Trace: memremap+0xcb/0x184 xlate_dev_mem_ptr+0x25/0x2f write_mem+0x94/0xfb vfs_write+0x128/0x26d ksys_write+0xac/0xfe do_syscall_64+0x9a/0xfd entry_SYSCALL_64_after_hwframe+0x4b/0x53 The details of command execution process are as follows. In the above resource tree, \"System RAM\" is a descendant of \"CXL Window 0\" instead of a top level resource. So, region_intersects() will report no System RAM resources in the CXL memory region incorrectly, because it only checks the top level resources. Consequently, devmem_is_allowed() will return 1 (allow access via /dev/mem) for CXL memory region incorrectly. Fortunately, ioremap() doesn't allow to map System RAM and reject the access. So, region_intersects() needs to be fixed to work correctly with the resource tree with \"System RAM\" not at top level as above. To fix it, if we found a unmatched resource in the top level, we will continue to search matched resources in its descendant resources. So, we will not miss any matched resources in resource tree anymore. In the new implementation, an example resource tree |------------- \"CXL Window 0\" ------------| |-- \"System RAM\" --| will behave similar as the following fake resource tree for region_intersects(, IORESOURCE_SYSTEM_RAM, ), |-- \"System RAM\" --||-- \"CXL Window 0a\" --| Where \"CXL Window 0a\" is part of the original \"CXL Window 0\" that isn't covered by \"System RAM\".", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49879", "url": "https://ubuntu.com/security/CVE-2024-49879", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm: omapdrm: Add missing check for alloc_ordered_workqueue As it may return NULL pointer and cause NULL pointer dereference. Add check for the return value of alloc_ordered_workqueue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49880", "url": "https://ubuntu.com/security/CVE-2024-49880", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix off by one issue in alloc_flex_gd() Wesley reported an issue: ================================================================== EXT4-fs (dm-5): resizing filesystem from 7168 to 786432 blocks ------------[ cut here ]------------ kernel BUG at fs/ext4/resize.c:324! CPU: 9 UID: 0 PID: 3576 Comm: resize2fs Not tainted 6.11.0+ #27 RIP: 0010:ext4_resize_fs+0x1212/0x12d0 Call Trace: __ext4_ioctl+0x4e0/0x1800 ext4_ioctl+0x12/0x20 __x64_sys_ioctl+0x99/0xd0 x64_sys_call+0x1206/0x20d0 do_syscall_64+0x72/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e ================================================================== While reviewing the patch, Honza found that when adjusting resize_bg in alloc_flex_gd(), it was possible for flex_gd->resize_bg to be bigger than flexbg_size. The reproduction of the problem requires the following: o_group = flexbg_size * 2 * n; o_size = (o_group + 1) * group_size; n_group: [o_group + flexbg_size, o_group + flexbg_size * 2) o_size = (n_group + 1) * group_size; Take n=0,flexbg_size=16 as an example: last:15 |o---------------|--------------n-| o_group:0 resize to n_group:30 The corresponding reproducer is: img=test.img rm -f $img truncate -s 600M $img mkfs.ext4 -F $img -b 1024 -G 16 8M dev=`losetup -f --show $img` mkdir -p /tmp/test mount $dev /tmp/test resize2fs $dev 248M Delete the problematic plus 1 to fix the issue, and add a WARN_ON_ONCE() to prevent the issue from happening again. [ Note: another reproucer which this commit fixes is: img=test.img rm -f $img truncate -s 25MiB $img mkfs.ext4 -b 4096 -E nodiscard,lazy_itable_init=0,lazy_journal_init=0 $img truncate -s 3GiB $img dev=`losetup -f --show $img` mkdir -p /tmp/test mount $dev /tmp/test resize2fs $dev 3G umount $dev losetup -d $dev -- TYT ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49881", "url": "https://ubuntu.com/security/CVE-2024-49881", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: update orig_path in ext4_find_extent() In ext4_find_extent(), if the path is not big enough, we free it and set *orig_path to NULL. But after reallocating and successfully initializing the path, we don't update *orig_path, in which case the caller gets a valid path but a NULL ppath, and this may cause a NULL pointer dereference or a path memory leak. For example: ext4_split_extent path = *ppath = 2000 ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path = 2000); *orig_path = path = NULL; path = kcalloc() = 3000 ext4_split_extent_at(*ppath = NULL) path = *ppath; ex = path[depth].p_ext; // NULL pointer dereference! ================================================================== BUG: kernel NULL pointer dereference, address: 0000000000000010 CPU: 6 UID: 0 PID: 576 Comm: fsstress Not tainted 6.11.0-rc2-dirty #847 RIP: 0010:ext4_split_extent_at+0x6d/0x560 Call Trace: ext4_split_extent.isra.0+0xcb/0x1b0 ext4_ext_convert_to_initialized+0x168/0x6c0 ext4_ext_handle_unwritten_extents+0x325/0x4d0 ext4_ext_map_blocks+0x520/0xdb0 ext4_map_blocks+0x2b0/0x690 ext4_iomap_begin+0x20e/0x2c0 [...] ================================================================== Therefore, *orig_path is updated when the extent lookup succeeds, so that the caller can safely use path or *ppath.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50014", "url": "https://ubuntu.com/security/CVE-2024-50014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix access to uninitialised lock in fc replay path The following kernel trace can be triggered with fstest generic/629 when executed against a filesystem with fast-commit feature enabled: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x66/0x90 register_lock_class+0x759/0x7d0 __lock_acquire+0x85/0x2630 ? __find_get_block+0xb4/0x380 lock_acquire+0xd1/0x2d0 ? __ext4_journal_get_write_access+0xd5/0x160 _raw_spin_lock+0x33/0x40 ? __ext4_journal_get_write_access+0xd5/0x160 __ext4_journal_get_write_access+0xd5/0x160 ext4_reserve_inode_write+0x61/0xb0 __ext4_mark_inode_dirty+0x79/0x270 ? ext4_ext_replay_set_iblocks+0x2f8/0x450 ext4_ext_replay_set_iblocks+0x330/0x450 ext4_fc_replay+0x14c8/0x1540 ? jread+0x88/0x2e0 ? rcu_is_watching+0x11/0x40 do_one_pass+0x447/0xd00 jbd2_journal_recover+0x139/0x1b0 jbd2_journal_load+0x96/0x390 ext4_load_and_init_journal+0x253/0xd40 ext4_fill_super+0x2cc6/0x3180 ... In the replay path there's an attempt to lock sbi->s_bdev_wb_lock in function ext4_check_bdev_write_error(). Unfortunately, at this point this spinlock has not been initialized yet. Moving it's initialization to an earlier point in __ext4_fill_super() fixes this splat.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49960", "url": "https://ubuntu.com/security/CVE-2024-49960", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix timer use-after-free on failed mount Syzbot has found an ODEBUG bug in ext4_fill_super The del_timer_sync function cancels the s_err_report timer, which reminds about filesystem errors daily. We should guarantee the timer is no longer active before kfree(sbi). When filesystem mounting fails, the flow goes to failed_mount3, where an error occurs when ext4_stop_mmpd is called, causing a read I/O failure. This triggers the ext4_handle_error function that ultimately re-arms the timer, leaving the s_err_report timer active before kfree(sbi) is called. Fix the issue by canceling the s_err_report timer after calling ext4_stop_mmpd.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49882", "url": "https://ubuntu.com/security/CVE-2024-49882", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix double brelse() the buffer of the extents path In ext4_ext_try_to_merge_up(), set path[1].p_bh to NULL after it has been released, otherwise it may be released twice. An example of what triggers this is as follows: split2 map split1 |--------|-------|--------| ext4_ext_map_blocks ext4_ext_handle_unwritten_extents ext4_split_convert_extents // path->p_depth == 0 ext4_split_extent // 1. do split1 ext4_split_extent_at |ext4_ext_insert_extent | ext4_ext_create_new_leaf | ext4_ext_grow_indepth | le16_add_cpu(&neh->eh_depth, 1) | ext4_find_extent | // return -ENOMEM |// get error and try zeroout |path = ext4_find_extent | path->p_depth = 1 |ext4_ext_try_to_merge | ext4_ext_try_to_merge_up | path->p_depth = 0 | brelse(path[1].p_bh) ---> not set to NULL here |// zeroout success // 2. update path ext4_find_extent // 3. do split2 ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth le16_add_cpu(&neh->eh_depth, 1) ext4_find_extent path[0].p_bh = NULL; path->p_depth = 1 read_extent_tree_block ---> return err // path[1].p_bh is still the old value ext4_free_ext_path ext4_ext_drop_refs // path->p_depth == 1 brelse(path[1].p_bh) ---> brelse a buffer twice Finally got the following WARRNING when removing the buffer from lru: ============================================ VFS: brelse: Trying to free free buffer WARNING: CPU: 2 PID: 72 at fs/buffer.c:1241 __brelse+0x58/0x90 CPU: 2 PID: 72 Comm: kworker/u19:1 Not tainted 6.9.0-dirty #716 RIP: 0010:__brelse+0x58/0x90 Call Trace: __find_get_block+0x6e7/0x810 bdev_getblk+0x2b/0x480 __ext4_get_inode_loc+0x48a/0x1240 ext4_get_inode_loc+0xb2/0x150 ext4_reserve_inode_write+0xb7/0x230 __ext4_mark_inode_dirty+0x144/0x6a0 ext4_ext_insert_extent+0x9c8/0x3230 ext4_ext_map_blocks+0xf45/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] ============================================", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49883", "url": "https://ubuntu.com/security/CVE-2024-49883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: aovid use-after-free in ext4_ext_insert_extent() As Ojaswin mentioned in Link, in ext4_ext_insert_extent(), if the path is reallocated in ext4_ext_create_new_leaf(), we'll use the stale path and cause UAF. Below is a sample trace with dummy values: ext4_ext_insert_extent path = *ppath = 2000 ext4_ext_create_new_leaf(ppath) ext4_find_extent(ppath) path = *ppath = 2000 if (depth > path[0].p_maxdepth) kfree(path = 2000); *ppath = path = NULL; path = kcalloc() = 3000 *ppath = 3000; return path; /* here path is still 2000, UAF! */ eh = path[depth].p_hdr ================================================================== BUG: KASAN: slab-use-after-free in ext4_ext_insert_extent+0x26d4/0x3330 Read of size 8 at addr ffff8881027bf7d0 by task kworker/u36:1/179 CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 Not tainted 6.11.0-rc2-dirty #866 Call Trace: ext4_ext_insert_extent+0x26d4/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 [...] Allocated by task 179: ext4_find_extent+0x81c/0x1f70 ext4_ext_map_blocks+0x146/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...] Freed by task 179: kfree+0xcb/0x240 ext4_find_extent+0x7c0/0x1f70 ext4_ext_insert_extent+0xa26/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...] ================================================================== So use *ppath to update the path to avoid the above problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49983", "url": "https://ubuntu.com/security/CVE-2024-49983", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-free When calling ext4_force_split_extent_at() in ext4_ext_replay_update_ex(), the 'ppath' is updated but it is the 'path' that is freed, thus potentially triggering a double-free in the following process: ext4_ext_replay_update_ex ppath = path ext4_force_split_extent_at(&ppath) ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path) ---> path First freed *orig_path = path = NULL ---> null ppath kfree(path) ---> path double-free !!! So drop the unnecessary ppath and use path directly to avoid this problem. And use ext4_find_extent() directly to update path, avoiding unnecessary memory allocation and freeing. Also, propagate the error returned by ext4_find_extent() instead of using strange error codes.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50015", "url": "https://ubuntu.com/security/CVE-2024-50015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: dax: fix overflowing extents beyond inode size when partially writing The dax_iomap_rw() does two things in each iteration: map written blocks and copy user data to blocks. If the process is killed by user(See signal handling in dax_iomap_iter()), the copied data will be returned and added on inode size, which means that the length of written extents may exceed the inode size, then fsck will fail. An example is given as: dd if=/dev/urandom of=file bs=4M count=1 dax_iomap_rw iomap_iter // round 1 ext4_iomap_begin ext4_iomap_alloc // allocate 0~2M extents(written flag) dax_iomap_iter // copy 2M data iomap_iter // round 2 iomap_iter_advance iter->pos += iter->processed // iter->pos = 2M ext4_iomap_begin ext4_iomap_alloc // allocate 2~4M extents(written flag) dax_iomap_iter fatal_signal_pending done = iter->pos - iocb->ki_pos // done = 2M ext4_handle_inode_extension ext4_update_inode_size // inode size = 2M fsck reports: Inode 13, i_size is 2097152, should be 4194304. Fix? Fix the problem by truncating extents if the written length is smaller than expected.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49884", "url": "https://ubuntu.com/security/CVE-2024-49884", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix slab-use-after-free in ext4_split_extent_at() We hit the following use-after-free: ================================================================== BUG: KASAN: slab-use-after-free in ext4_split_extent_at+0xba8/0xcc0 Read of size 2 at addr ffff88810548ed08 by task kworker/u20:0/40 CPU: 0 PID: 40 Comm: kworker/u20:0 Not tainted 6.9.0-dirty #724 Call Trace: kasan_report+0x93/0xc0 ext4_split_extent_at+0xba8/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] Allocated by task 40: __kmalloc_noprof+0x1ac/0x480 ext4_find_extent+0xf3b/0x1e70 ext4_ext_map_blocks+0x188/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] Freed by task 40: kfree+0xf1/0x2b0 ext4_find_extent+0xa71/0x1e70 ext4_ext_insert_extent+0xa22/0x3260 ext4_split_extent_at+0x3ef/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] ================================================================== The flow of issue triggering is as follows: ext4_split_extent_at path = *ppath ext4_ext_insert_extent(ppath) ext4_ext_create_new_leaf(ppath) ext4_find_extent(orig_path) path = *orig_path read_extent_tree_block // return -ENOMEM or -EIO ext4_free_ext_path(path) kfree(path) *orig_path = NULL a. If err is -ENOMEM: ext4_ext_dirty(path + path->p_depth) // path use-after-free !!! b. If err is -EIO and we have EXT_DEBUG defined: ext4_ext_show_leaf(path) eh = path[depth].p_hdr // path also use-after-free !!! So when trying to zeroout or fix the extent length, call ext4_find_extent() to update the path. In addition we use *ppath directly as an ext4_ext_show_leaf() input to avoid possible use-after-free when EXT_DEBUG is defined, and to avoid unnecessary path updates.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49885", "url": "https://ubuntu.com/security/CVE-2024-49885", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm, slub: avoid zeroing kmalloc redzone Since commit 946fa0dbf2d8 (\"mm/slub: extend redzone check to extra allocated kmalloc space than requested\"), setting orig_size treats the wasted space (object_size - orig_size) as a redzone. However with init_on_free=1 we clear the full object->size, including the redzone. Additionally we clear the object metadata, including the stored orig_size, making it zero, which makes check_object() treat the whole object as a redzone. These issues lead to the following BUG report with \"slub_debug=FUZ init_on_free=1\": [ 0.000000] ============================================================================= [ 0.000000] BUG kmalloc-8 (Not tainted): kmalloc Redzone overwritten [ 0.000000] ----------------------------------------------------------------------------- [ 0.000000] [ 0.000000] 0xffff000010032858-0xffff00001003285f @offset=2136. First byte 0x0 instead of 0xcc [ 0.000000] FIX kmalloc-8: Restoring kmalloc Redzone 0xffff000010032858-0xffff00001003285f=0xcc [ 0.000000] Slab 0xfffffdffc0400c80 objects=36 used=23 fp=0xffff000010032a18 flags=0x3fffe0000000200(workingset|node=0|zone=0|lastcpupid=0x1ffff) [ 0.000000] Object 0xffff000010032858 @offset=2136 fp=0xffff0000100328c8 [ 0.000000] [ 0.000000] Redzone ffff000010032850: cc cc cc cc cc cc cc cc ........ [ 0.000000] Object ffff000010032858: cc cc cc cc cc cc cc cc ........ [ 0.000000] Redzone ffff000010032860: cc cc cc cc cc cc cc cc ........ [ 0.000000] Padding ffff0000100328b4: 00 00 00 00 00 00 00 00 00 00 00 00 ............ [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.11.0-rc3-next-20240814-00004-g61844c55c3f4 #144 [ 0.000000] Hardware name: NXP i.MX95 19X19 board (DT) [ 0.000000] Call trace: [ 0.000000] dump_backtrace+0x90/0xe8 [ 0.000000] show_stack+0x18/0x24 [ 0.000000] dump_stack_lvl+0x74/0x8c [ 0.000000] dump_stack+0x18/0x24 [ 0.000000] print_trailer+0x150/0x218 [ 0.000000] check_object+0xe4/0x454 [ 0.000000] free_to_partial_list+0x2f8/0x5ec To address the issue, use orig_size to clear the used area. And restore the value of orig_size after clear the remaining area. When CONFIG_SLUB_DEBUG not defined, (get_orig_size()' directly returns s->object_size. So when using memset to init the area, the size can simply be orig_size, as orig_size returns object_size when CONFIG_SLUB_DEBUG not enabled. And orig_size can never be bigger than object_size.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49961", "url": "https://ubuntu.com/security/CVE-2024-49961", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: ar0521: Use cansleep version of gpiod_set_value() If we use GPIO reset from I2C port expander, we must use *_cansleep() variant of GPIO functions. This was not done in ar0521_power_on()/ar0521_power_off() functions. Let's fix that. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 11 at drivers/gpio/gpiolib.c:3496 gpiod_set_value+0x74/0x7c Modules linked in: CPU: 0 PID: 11 Comm: kworker/u16:0 Not tainted 6.10.0 #53 Hardware name: Diasom DS-RK3568-SOM-EVB (DT) Workqueue: events_unbound deferred_probe_work_func pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : gpiod_set_value+0x74/0x7c lr : ar0521_power_on+0xcc/0x290 sp : ffffff8001d7ab70 x29: ffffff8001d7ab70 x28: ffffff80027dcc90 x27: ffffff8003c82000 x26: ffffff8003ca9250 x25: ffffffc080a39c60 x24: ffffff8003ca9088 x23: ffffff8002402720 x22: ffffff8003ca9080 x21: ffffff8003ca9088 x20: 0000000000000000 x19: ffffff8001eb2a00 x18: ffffff80efeeac80 x17: 756d2d6332692f30 x16: 0000000000000000 x15: 0000000000000000 x14: ffffff8001d91d40 x13: 0000000000000016 x12: ffffffc080e98930 x11: ffffff8001eb2880 x10: 0000000000000890 x9 : ffffff8001d7a9f0 x8 : ffffff8001d92570 x7 : ffffff80efeeac80 x6 : 000000003fc6e780 x5 : ffffff8001d91c80 x4 : 0000000000000002 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000001 Call trace: gpiod_set_value+0x74/0x7c ar0521_power_on+0xcc/0x290 ...", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49985", "url": "https://ubuntu.com/security/CVE-2024-49985", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume In case there is any sort of clock controller attached to this I2C bus controller, for example Versaclock or even an AIC32x4 I2C codec, then an I2C transfer triggered from the clock controller clk_ops .prepare callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex. This is because the clock controller first grabs the prepare_lock mutex and then performs the prepare operation, including its I2C access. The I2C access resumes this I2C bus controller via .runtime_resume callback, which calls clk_prepare_enable(), which attempts to grab the prepare_lock mutex again and deadlocks. Since the clock are already prepared since probe() and unprepared in remove(), use simple clk_enable()/clk_disable() calls to enable and disable the clock on runtime suspend and resume, to avoid hitting the prepare_lock mutex.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49886", "url": "https://ubuntu.com/security/CVE-2024-49886", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bug Attaching SST PCI device to VM causes \"BUG: KASAN: slab-out-of-bounds\". kasan report: [ 19.411889] ================================================================== [ 19.413702] BUG: KASAN: slab-out-of-bounds in _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.415634] Read of size 8 at addr ffff888829e65200 by task cpuhp/16/113 [ 19.417368] [ 19.418627] CPU: 16 PID: 113 Comm: cpuhp/16 Tainted: G E 6.9.0 #10 [ 19.420435] Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.20192059.B64.2207280713 07/28/2022 [ 19.422687] Call Trace: [ 19.424091] [ 19.425448] dump_stack_lvl+0x5d/0x80 [ 19.426963] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.428694] print_report+0x19d/0x52e [ 19.430206] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 19.431837] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.433539] kasan_report+0xf0/0x170 [ 19.435019] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.436709] _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.438379] ? __pfx_sched_clock_cpu+0x10/0x10 [ 19.439910] isst_if_cpu_online+0x406/0x58f [isst_if_common] [ 19.441573] ? __pfx_isst_if_cpu_online+0x10/0x10 [isst_if_common] [ 19.443263] ? ttwu_queue_wakelist+0x2c1/0x360 [ 19.444797] cpuhp_invoke_callback+0x221/0xec0 [ 19.446337] cpuhp_thread_fun+0x21b/0x610 [ 19.447814] ? __pfx_cpuhp_thread_fun+0x10/0x10 [ 19.449354] smpboot_thread_fn+0x2e7/0x6e0 [ 19.450859] ? __pfx_smpboot_thread_fn+0x10/0x10 [ 19.452405] kthread+0x29c/0x350 [ 19.453817] ? __pfx_kthread+0x10/0x10 [ 19.455253] ret_from_fork+0x31/0x70 [ 19.456685] ? __pfx_kthread+0x10/0x10 [ 19.458114] ret_from_fork_asm+0x1a/0x30 [ 19.459573] [ 19.460853] [ 19.462055] Allocated by task 1198: [ 19.463410] kasan_save_stack+0x30/0x50 [ 19.464788] kasan_save_track+0x14/0x30 [ 19.466139] __kasan_kmalloc+0xaa/0xb0 [ 19.467465] __kmalloc+0x1cd/0x470 [ 19.468748] isst_if_cdev_register+0x1da/0x350 [isst_if_common] [ 19.470233] isst_if_mbox_init+0x108/0xff0 [isst_if_mbox_msr] [ 19.471670] do_one_initcall+0xa4/0x380 [ 19.472903] do_init_module+0x238/0x760 [ 19.474105] load_module+0x5239/0x6f00 [ 19.475285] init_module_from_file+0xd1/0x130 [ 19.476506] idempotent_init_module+0x23b/0x650 [ 19.477725] __x64_sys_finit_module+0xbe/0x130 [ 19.476506] idempotent_init_module+0x23b/0x650 [ 19.477725] __x64_sys_finit_module+0xbe/0x130 [ 19.478920] do_syscall_64+0x82/0x160 [ 19.480036] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 19.481292] [ 19.482205] The buggy address belongs to the object at ffff888829e65000 which belongs to the cache kmalloc-512 of size 512 [ 19.484818] The buggy address is located 0 bytes to the right of allocated 512-byte region [ffff888829e65000, ffff888829e65200) [ 19.487447] [ 19.488328] The buggy address belongs to the physical page: [ 19.489569] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888829e60c00 pfn:0x829e60 [ 19.491140] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [ 19.492466] anon flags: 0x57ffffc0000840(slab|head|node=1|zone=2|lastcpupid=0x1fffff) [ 19.493914] page_type: 0xffffffff() [ 19.494988] raw: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [ 19.496451] raw: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [ 19.497906] head: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [ 19.499379] head: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [ 19.500844] head: 0057ffffc0000003 ffffea0020a79801 ffffea0020a79848 00000000ffffffff [ 19.502316] head: 0000000800000000 0000000000000000 00000000ffffffff 0000000000000000 [ 19.503784] page dumped because: k ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49986", "url": "https://ubuntu.com/security/CVE-2024-49986", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: x86-android-tablets: Fix use after free on platform_device_register() errors x86_android_tablet_remove() frees the pdevs[] array, so it should not be used after calling x86_android_tablet_remove(). When platform_device_register() fails, store the pdevs[x] PTR_ERR() value into the local ret variable before calling x86_android_tablet_remove() to avoid using pdevs[] after it has been freed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49887", "url": "https://ubuntu.com/security/CVE-2024-49887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to don't panic system for no free segment fault injection f2fs: fix to don't panic system for no free segment fault injection syzbot reports a f2fs bug as below: F2FS-fs (loop0): inject no free segment in get_new_segment of __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3167 F2FS-fs (loop0): Stopped filesystem due to reason: 7 ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2748! CPU: 0 UID: 0 PID: 5109 Comm: syz-executor304 Not tainted 6.11.0-rc6-syzkaller-00363-g89f5e14d05b4 #0 RIP: 0010:get_new_segment fs/f2fs/segment.c:2748 [inline] RIP: 0010:new_curseg+0x1f61/0x1f70 fs/f2fs/segment.c:2836 Call Trace: __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3167 f2fs_allocate_new_section fs/f2fs/segment.c:3181 [inline] f2fs_allocate_pinning_section+0xfa/0x4e0 fs/f2fs/segment.c:3195 f2fs_expand_inode_data+0x5d6/0xbb0 fs/f2fs/file.c:1799 f2fs_fallocate+0x448/0x960 fs/f2fs/file.c:1903 vfs_fallocate+0x553/0x6c0 fs/open.c:334 do_vfs_ioctl+0x2592/0x2e50 fs/ioctl.c:886 __do_sys_ioctl fs/ioctl.c:905 [inline] __se_sys_ioctl+0x81/0x170 fs/ioctl.c:893 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: 0010:get_new_segment fs/f2fs/segment.c:2748 [inline] RIP: 0010:new_curseg+0x1f61/0x1f70 fs/f2fs/segment.c:2836 The root cause is when we inject no free segment fault into f2fs, we should not panic system, fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49888", "url": "https://ubuntu.com/security/CVE-2024-49888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix a sdiv overflow issue Zac Ecob reported a problem where a bpf program may cause kernel crash due to the following error: Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI The failure is due to the below signed divide: LLONG_MIN/-1 where LLONG_MIN equals to -9,223,372,036,854,775,808. LLONG_MIN/-1 is supposed to give a positive number 9,223,372,036,854,775,808, but it is impossible since for 64-bit system, the maximum positive number is 9,223,372,036,854,775,807. On x86_64, LLONG_MIN/-1 will cause a kernel exception. On arm64, the result for LLONG_MIN/-1 is LLONG_MIN. Further investigation found all the following sdiv/smod cases may trigger an exception when bpf program is running on x86_64 platform: - LLONG_MIN/-1 for 64bit operation - INT_MIN/-1 for 32bit operation - LLONG_MIN%-1 for 64bit operation - INT_MIN%-1 for 32bit operation where -1 can be an immediate or in a register. On arm64, there are no exceptions: - LLONG_MIN/-1 = LLONG_MIN - INT_MIN/-1 = INT_MIN - LLONG_MIN%-1 = 0 - INT_MIN%-1 = 0 where -1 can be an immediate or in a register. Insn patching is needed to handle the above cases and the patched codes produced results aligned with above arm64 result. The below are pseudo codes to handle sdiv/smod exceptions including both divisor -1 and divisor 0 and the divisor is stored in a register. sdiv: tmp = rX tmp += 1 /* [-1, 0] -> [0, 1] if tmp >(unsigned) 1 goto L2 if tmp == 0 goto L1 rY = 0 L1: rY = -rY; goto L3 L2: rY /= rX L3: smod: tmp = rX tmp += 1 /* [-1, 0] -> [0, 1] if tmp >(unsigned) 1 goto L1 if tmp == 1 (is64 ? goto L2 : goto L3) rY = 0; goto L2 L1: rY %= rX L2: goto L4 // only when !is64 L3: wY = wY // only when !is64 L4: [1] https://lore.kernel.org/bpf/tPJLTEh7S_DxFEqAI2Ji5MBSoZVg7_G-Py2iaZpAaWtM961fFTWtsnlzwvTbzBzaUzwQAoNATXKUlt0LZOFgnDcIyKCswAnAGdUF3LBrhGQ=@protonmail.com/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49987", "url": "https://ubuntu.com/security/CVE-2024-49987", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpftool: Fix undefined behavior in qsort(NULL, 0, ...) When netfilter has no entry to display, qsort is called with qsort(NULL, 0, ...). This results in undefined behavior, as UBSan reports: net.c:827:2: runtime error: null pointer passed as argument 1, which is declared to never be null Although the C standard does not explicitly state whether calling qsort with a NULL pointer when the size is 0 constitutes undefined behavior, Section 7.1.4 of the C standard (Use of library functions) mentions: \"Each of the following statements applies unless explicitly stated otherwise in the detailed descriptions that follow: If an argument to a function has an invalid value (such as a value outside the domain of the function, or a pointer outside the address space of the program, or a null pointer, or a pointer to non-modifiable storage when the corresponding parameter is not const-qualified) or a type (after promotion) not expected by a function with variable number of arguments, the behavior is undefined.\" To avoid this, add an early return when nf_link_info is NULL to prevent calling qsort with a NULL pointer.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50006", "url": "https://ubuntu.com/security/CVE-2024-50006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix i_data_sem unlock order in ext4_ind_migrate() Fuzzing reports a possible deadlock in jbd2_log_wait_commit. This issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to require synchronous updates because the file descriptor is opened with O_SYNC. This can lead to the jbd2_journal_stop() function calling jbd2_might_wait_for_commit(), potentially causing a deadlock if the EXT4_IOC_MIGRATE call races with a write(2) system call. This problem only arises when CONFIG_PROVE_LOCKING is enabled. In this case, the jbd2_might_wait_for_commit macro locks jbd2_handle in the jbd2_journal_stop function while i_data_sem is locked. This triggers lockdep because the jbd2_journal_start function might also lock the same jbd2_handle simultaneously. Found by Linux Verification Center (linuxtesting.org) with syzkaller. Rule: add", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49889", "url": "https://ubuntu.com/security/CVE-2024-49889", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid use-after-free in ext4_ext_show_leaf() In ext4_find_extent(), path may be freed by error or be reallocated, so using a previously saved *ppath may have been freed and thus may trigger use-after-free, as follows: ext4_split_extent path = *ppath; ext4_split_extent_at(ppath) path = ext4_find_extent(ppath) ext4_split_extent_at(ppath) // ext4_find_extent fails to free path // but zeroout succeeds ext4_ext_show_leaf(inode, path) eh = path[depth].p_hdr // path use-after-free !!! Similar to ext4_split_extent_at(), we use *ppath directly as an input to ext4_ext_show_leaf(). Fix a spelling error by the way. Same problem in ext4_ext_handle_unwritten_extents(). Since 'path' is only used in ext4_ext_show_leaf(), remove 'path' and use *ppath directly. This issue is triggered only when EXT_DEBUG is defined and therefore does not affect functionality.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49968", "url": "https://ubuntu.com/security/CVE-2024-49968", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: filesystems without casefold feature cannot be mounted with siphash When mounting the ext4 filesystem, if the default hash version is set to DX_HASH_SIPHASH but the casefold feature is not set, exit the mounting.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49988", "url": "https://ubuntu.com/security/CVE-2024-49988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: add refcnt to ksmbd_conn struct When sending an oplock break request, opinfo->conn is used, But freed ->conn can be used on multichannel. This patch add a reference count to the ksmbd_conn struct so that it can be freed when it is no longer used.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49890", "url": "https://ubuntu.com/security/CVE-2024-49890", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: ensure the fw_info is not null before using it This resolves the dereference null return value warning reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49891", "url": "https://ubuntu.com/security/CVE-2024-49891", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata paths When the HBA is undergoing a reset or is handling an errata event, NULL ptr dereference crashes may occur in routines such as lpfc_sli_flush_io_rings(), lpfc_dev_loss_tmo_callbk(), or lpfc_abort_handler(). Add NULL ptr checks before dereferencing hdwq pointers that may have been freed due to operations colliding with a reset or errata event handler.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49892", "url": "https://ubuntu.com/security/CVE-2024-49892", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize get_bytes_per_element's default to 1 Variables, used as denominators and maybe not assigned to other values, should not be 0. bytes_per_element_y & bytes_per_element_c are initialized by get_bytes_per_element() which should never return 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50016", "url": "https://ubuntu.com/security/CVE-2024-50016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Avoid overflow assignment in link_dp_cts sampling_rate is an uint8_t but is assigned an unsigned int, and thus it can overflow. As a result, sampling_rate is changed to uint32_t. Similarly, LINK_QUAL_PATTERN_SET has a size of 2 bits, and it should only be assigned to a value less or equal than 4. This fixes 2 INTEGER_OVERFLOW issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49893", "url": "https://ubuntu.com/security/CVE-2024-49893", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check stream_status before it is used [WHAT & HOW] dc_state_get_stream_status can return null, and therefore null must be checked before stream_status is used. This fixes 1 NULL_RETURNS issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49969", "url": "https://ubuntu.com/security/CVE-2024-49969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 color transformation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_hw_format` function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:180 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:181 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:182 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49970", "url": "https://ubuntu.com/security/CVE-2024-49970", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Implement bounds check for stream encoder creation in DCN401 'stream_enc_regs' array is an array of dcn10_stream_enc_registers structures. The array is initialized with four elements, corresponding to the four calls to stream_enc_regs() in the array initializer. This means that valid indices for this array are 0, 1, 2, and 3. The error message 'stream_enc_regs' 4 <= 5 below, is indicating that there is an attempt to access this array with an index of 5, which is out of bounds. This could lead to undefined behavior Here, eng_id is used as an index to access the stream_enc_regs array. If eng_id is 5, this would result in an out-of-bounds access on the stream_enc_regs array. Thus fixing Buffer overflow error in dcn401_stream_encoder_create Found by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn401/dcn401_resource.c:1209 dcn401_stream_encoder_create() error: buffer overflow 'stream_enc_regs' 4 <= 5", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49894", "url": "https://ubuntu.com/security/CVE-2024-49894", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in degamma hardware format translation Fixes index out of bounds issue in `cm_helper_translate_curve_to_degamma_hw_format` function. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49895", "url": "https://ubuntu.com/security/CVE-2024-49895", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format translation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_degamma_hw_format` function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:338 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:339 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:340 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49971", "url": "https://ubuntu.com/security/CVE-2024-49971", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Increase array size of dummy_boolean [WHY] dml2_core_shared_mode_support and dml_core_mode_support access the third element of dummy_boolean, i.e. hw_debug5 = &s->dummy_boolean[2], when dummy_boolean has size of 2. Any assignment to hw_debug5 causes an OVERRUN. [HOW] Increase dummy_boolean's array size to 3. This fixes 2 OVERRUN issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49972", "url": "https://ubuntu.com/security/CVE-2024-49972", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Deallocate DML memory if allocation fails [Why] When DC state create DML memory allocation fails, memory is not deallocated subsequently, resulting in uninitialized structure that is not NULL. [How] Deallocate memory if DML memory allocation fails.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49896", "url": "https://ubuntu.com/security/CVE-2024-49896", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check stream before comparing them [WHAT & HOW] amdgpu_dm can pass a null stream to dc_is_stream_unchanged. It is necessary to check for null before dereferencing them. This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49897", "url": "https://ubuntu.com/security/CVE-2024-49897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check phantom_stream before it is used dcn32_enable_phantom_stream can return null, so returned value must be checked before used. This fixes 1 NULL_RETURNS issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49898", "url": "https://ubuntu.com/security/CVE-2024-49898", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null-initialized variables [WHAT & HOW] drr_timing and subvp_pipe are initialized to null and they are not always assigned new values. It is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49899", "url": "https://ubuntu.com/security/CVE-2024-49899", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize denominators' default to 1 [WHAT & HOW] Variables used as denominators and maybe not assigned to other values, should not be 0. Change their default to 1 so they are never 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49900", "url": "https://ubuntu.com/security/CVE-2024-49900", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uninit-value access of new_ea in ea_buffer syzbot reports that lzo1x_1_do_compress is using uninit-value: ===================================================== BUG: KMSAN: uninit-value in lzo1x_1_do_compress+0x19f9/0x2510 lib/lzo/lzo1x_compress.c:178 ... Uninit was stored to memory at: ea_put fs/jfs/xattr.c:639 [inline] ... Local variable ea_buf created at: __jfs_setxattr+0x5d/0x1ae0 fs/jfs/xattr.c:662 __jfs_xattr_set+0xe6/0x1f0 fs/jfs/xattr.c:934 ===================================================== The reason is ea_buf->new_ea is not initialized properly. Fix this by using memset to empty its content at the beginning in ea_get().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49901", "url": "https://ubuntu.com/security/CVE-2024-49901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm/adreno: Assign msm_gpu->pdev earlier to avoid nullptrs There are some cases, such as the one uncovered by Commit 46d4efcccc68 (\"drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails\") where msm_gpu_cleanup() : platform_set_drvdata(gpu->pdev, NULL); is called on gpu->pdev == NULL, as the GPU device has not been fully initialized yet. Turns out that there's more than just the aforementioned path that causes this to happen (e.g. the case when there's speedbin data in the catalog, but opp-supported-hw is missing in DT). Assigning msm_gpu->pdev earlier seems like the least painful solution to this, therefore do so. Patchwork: https://patchwork.freedesktop.org/patch/602742/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49902", "url": "https://ubuntu.com/security/CVE-2024-49902", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: check if leafidx greater than num leaves per dmap tree syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf. Shaggy: Modified sanity check to apply to control pages as well as leaf pages.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49903", "url": "https://ubuntu.com/security/CVE-2024-49903", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uaf in dbFreeBits [syzbot reported] ================================================================== BUG: KASAN: slab-use-after-free in __mutex_lock_common kernel/locking/mutex.c:587 [inline] BUG: KASAN: slab-use-after-free in __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 Read of size 8 at addr ffff8880229254b0 by task syz-executor357/5216 CPU: 0 UID: 0 PID: 5216 Comm: syz-executor357 Not tainted 6.11.0-rc3-syzkaller-00156-gd7a5aa4b3c00 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 __mutex_lock_common kernel/locking/mutex.c:587 [inline] __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 dbFreeBits+0x7ea/0xd90 fs/jfs/jfs_dmap.c:2390 dbFreeDmap fs/jfs/jfs_dmap.c:2089 [inline] dbFree+0x35b/0x680 fs/jfs/jfs_dmap.c:409 dbDiscardAG+0x8a9/0xa20 fs/jfs/jfs_dmap.c:1650 jfs_ioc_trim+0x433/0x670 fs/jfs/jfs_discard.c:100 jfs_ioctl+0x2d0/0x3e0 fs/jfs/ioctl.c:131 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 Freed by task 5218: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object+0xe0/0x150 mm/kasan/common.c:240 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2252 [inline] slab_free mm/slub.c:4473 [inline] kfree+0x149/0x360 mm/slub.c:4594 dbUnmount+0x11d/0x190 fs/jfs/jfs_dmap.c:278 jfs_mount_rw+0x4ac/0x6a0 fs/jfs/jfs_mount.c:247 jfs_remount+0x3d1/0x6b0 fs/jfs/super.c:454 reconfigure_super+0x445/0x880 fs/super.c:1083 vfs_cmd_reconfigure fs/fsopen.c:263 [inline] vfs_fsconfig_locked fs/fsopen.c:292 [inline] __do_sys_fsconfig fs/fsopen.c:473 [inline] __se_sys_fsconfig+0xb6e/0xf80 fs/fsopen.c:345 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 [Analysis] There are two paths (dbUnmount and jfs_ioc_trim) that generate race condition when accessing bmap, which leads to the occurrence of uaf. Use the lock s_umount to synchronize them, in order to avoid uaf caused by race condition.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49904", "url": "https://ubuntu.com/security/CVE-2024-49904", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add list empty check to avoid null pointer issue Add list empty check to avoid null pointer issues in some corner cases. - list_for_each_entry_safe()", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49989", "url": "https://ubuntu.com/security/CVE-2024-49989", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix double free issue during amdgpu module unload Flexible endpoints use DIGs from available inflexible endpoints, so only the encoders of inflexible links need to be freed. Otherwise, a double free issue may occur when unloading the amdgpu module. [ 279.190523] RIP: 0010:__slab_free+0x152/0x2f0 [ 279.190577] Call Trace: [ 279.190580] [ 279.190582] ? show_regs+0x69/0x80 [ 279.190590] ? die+0x3b/0x90 [ 279.190595] ? do_trap+0xc8/0xe0 [ 279.190601] ? do_error_trap+0x73/0xa0 [ 279.190605] ? __slab_free+0x152/0x2f0 [ 279.190609] ? exc_invalid_op+0x56/0x70 [ 279.190616] ? __slab_free+0x152/0x2f0 [ 279.190642] ? asm_exc_invalid_op+0x1f/0x30 [ 279.190648] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191096] ? __slab_free+0x152/0x2f0 [ 279.191102] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191469] kfree+0x260/0x2b0 [ 279.191474] dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191821] link_destroy+0xd7/0x130 [amdgpu] [ 279.192248] dc_destruct+0x90/0x270 [amdgpu] [ 279.192666] dc_destroy+0x19/0x40 [amdgpu] [ 279.193020] amdgpu_dm_fini+0x16e/0x200 [amdgpu] [ 279.193432] dm_hw_fini+0x26/0x40 [amdgpu] [ 279.193795] amdgpu_device_fini_hw+0x24c/0x400 [amdgpu] [ 279.194108] amdgpu_driver_unload_kms+0x4f/0x70 [amdgpu] [ 279.194436] amdgpu_pci_remove+0x40/0x80 [amdgpu] [ 279.194632] pci_device_remove+0x3a/0xa0 [ 279.194638] device_remove+0x40/0x70 [ 279.194642] device_release_driver_internal+0x1ad/0x210 [ 279.194647] driver_detach+0x4e/0xa0 [ 279.194650] bus_remove_driver+0x6f/0xf0 [ 279.194653] driver_unregister+0x33/0x60 [ 279.194657] pci_unregister_driver+0x44/0x90 [ 279.194662] amdgpu_exit+0x19/0x1f0 [amdgpu] [ 279.194939] __do_sys_delete_module.isra.0+0x198/0x2f0 [ 279.194946] __x64_sys_delete_module+0x16/0x20 [ 279.194950] do_syscall_64+0x58/0x120 [ 279.194954] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 279.194980] ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49905", "url": "https://ubuntu.com/security/CVE-2024-49905", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for 'afb' in amdgpu_dm_plane_handle_cursor_update (v2) This commit adds a null check for the 'afb' variable in the amdgpu_dm_plane_handle_cursor_update function. Previously, 'afb' was assumed to be null, but was used later in the code without a null check. This could potentially lead to a null pointer dereference. Changes since v1: - Moved the null check for 'afb' to the line where 'afb' is used. (Alex) Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:1298 amdgpu_dm_plane_handle_cursor_update() error: we previously assumed 'afb' could be null (see line 1252)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49906", "url": "https://ubuntu.com/security/CVE-2024-49906", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before try to access it [why & how] Change the order of the pipe_ctx->plane_state check to ensure that plane_state is not null before accessing it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49907", "url": "https://ubuntu.com/security/CVE-2024-49907", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before using dc->clk_mgr [WHY & HOW] dc->clk_mgr is null checked previously in the same function, indicating it might be null. Passing \"dc\" to \"dc->hwss.apply_idle_power_optimizations\", which dereferences null \"dc->clk_mgr\". (The function pointer resolves to \"dcn35_apply_idle_power_optimizations\".) This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49908", "url": "https://ubuntu.com/security/CVE-2024-49908", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for 'afb' in amdgpu_dm_update_cursor (v2) This commit adds a null check for the 'afb' variable in the amdgpu_dm_update_cursor function. Previously, 'afb' was assumed to be null at line 8388, but was used later in the code without a null check. This could potentially lead to a null pointer dereference. Changes since v1: - Moved the null check for 'afb' to the line where 'afb' is used. (Alex) Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:8433 amdgpu_dm_update_cursor() \terror: we previously assumed 'afb' could be null (see line 8388)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50177", "url": "https://ubuntu.com/security/CVE-2024-50177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix a UBSAN warning in DML2.1 When programming phantom pipe, since cursor_width is explicity set to 0, this causes calculation logic to trigger overflow for an unsigned int triggering the kernel's UBSAN check as below: [ 40.962845] UBSAN: shift-out-of-bounds in /tmp/amd.EfpumTkO/amd/amdgpu/../display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c:3312:34 [ 40.962849] shift exponent 4294967170 is too large for 32-bit type 'unsigned int' [ 40.962852] CPU: 1 PID: 1670 Comm: gnome-shell Tainted: G W OE 6.5.0-41-generic #41~22.04.2-Ubuntu [ 40.962854] Hardware name: Gigabyte Technology Co., Ltd. X670E AORUS PRO X/X670E AORUS PRO X, BIOS F21 01/10/2024 [ 40.962856] Call Trace: [ 40.962857] [ 40.962860] dump_stack_lvl+0x48/0x70 [ 40.962870] dump_stack+0x10/0x20 [ 40.962872] __ubsan_handle_shift_out_of_bounds+0x1ac/0x360 [ 40.962878] calculate_cursor_req_attributes.cold+0x1b/0x28 [amdgpu] [ 40.963099] dml_core_mode_support+0x6b91/0x16bc0 [amdgpu] [ 40.963327] ? srso_alias_return_thunk+0x5/0x7f [ 40.963331] ? CalculateWatermarksMALLUseAndDRAMSpeedChangeSupport+0x18b8/0x2790 [amdgpu] [ 40.963534] ? srso_alias_return_thunk+0x5/0x7f [ 40.963536] ? dml_core_mode_support+0xb3db/0x16bc0 [amdgpu] [ 40.963730] dml2_core_calcs_mode_support_ex+0x2c/0x90 [amdgpu] [ 40.963906] ? srso_alias_return_thunk+0x5/0x7f [ 40.963909] ? dml2_core_calcs_mode_support_ex+0x2c/0x90 [amdgpu] [ 40.964078] core_dcn4_mode_support+0x72/0xbf0 [amdgpu] [ 40.964247] dml2_top_optimization_perform_optimization_phase+0x1d3/0x2a0 [amdgpu] [ 40.964420] dml2_build_mode_programming+0x23d/0x750 [amdgpu] [ 40.964587] dml21_validate+0x274/0x770 [amdgpu] [ 40.964761] ? srso_alias_return_thunk+0x5/0x7f [ 40.964763] ? resource_append_dpp_pipes_for_plane_composition+0x27c/0x3b0 [amdgpu] [ 40.964942] dml2_validate+0x504/0x750 [amdgpu] [ 40.965117] ? dml21_copy+0x95/0xb0 [amdgpu] [ 40.965291] ? srso_alias_return_thunk+0x5/0x7f [ 40.965295] dcn401_validate_bandwidth+0x4e/0x70 [amdgpu] [ 40.965491] update_planes_and_stream_state+0x38d/0x5c0 [amdgpu] [ 40.965672] update_planes_and_stream_v3+0x52/0x1e0 [amdgpu] [ 40.965845] ? srso_alias_return_thunk+0x5/0x7f [ 40.965849] dc_update_planes_and_stream+0x71/0xb0 [amdgpu] Fix this by adding a guard for checking cursor width before triggering the size calculation.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49909", "url": "https://ubuntu.com/security/CVE-2024-49909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn32_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn32_set_output_transfer_func function. Previously, set_output_gamma was being checked for null, but then it was being dereferenced without any null check. This could lead to a null pointer dereference if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49910", "url": "https://ubuntu.com/security/CVE-2024-49910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn401_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn401_set_output_transfer_func function. Previously, set_output_gamma was being checked for null, but then it was being dereferenced without any null check. This could lead to a null pointer dereference if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49911", "url": "https://ubuntu.com/security/CVE-2024-49911", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn20_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn20_set_output_transfer_func function. Previously, set_output_gamma was being checked for null at line 1030, but then it was being dereferenced without any null check at line 1048. This could potentially lead to a null pointer dereference error if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma at line 1048.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49912", "url": "https://ubuntu.com/security/CVE-2024-49912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Handle null 'stream_status' in 'planes_changed_for_existing_stream' This commit adds a null check for 'stream_status' in the function 'planes_changed_for_existing_stream'. Previously, the code assumed 'stream_status' could be null, but did not handle the case where it was actually null. This could lead to a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:3784 planes_changed_for_existing_stream() error: we previously assumed 'stream_status' could be null (see line 3774)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49913", "url": "https://ubuntu.com/security/CVE-2024-49913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for top_pipe_to_program in commit_planes_for_stream This commit addresses a null pointer dereference issue in the `commit_planes_for_stream` function at line 4140. The issue could occur when `top_pipe_to_program` is null. The fix adds a check to ensure `top_pipe_to_program` is not null before accessing its stream_res. This prevents a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:4140 commit_planes_for_stream() error: we previously assumed 'top_pipe_to_program' could be null (see line 3906)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49914", "url": "https://ubuntu.com/security/CVE-2024-49914", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for pipe_ctx->plane_state in dcn20_program_pipe This commit addresses a null pointer dereference issue in the `dcn20_program_pipe` function. The issue could occur when `pipe_ctx->plane_state` is null. The fix adds a check to ensure `pipe_ctx->plane_state` is not null before accessing. This prevents a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn20/dcn20_hwseq.c:1925 dcn20_program_pipe() error: we previously assumed 'pipe_ctx->plane_state' could be null (see line 1877)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49915", "url": "https://ubuntu.com/security/CVE-2024-49915", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr in dcn32_init_hw This commit addresses a potential null pointer dereference issue in the `dcn32_init_hw` function. The issue could occur when `dc->clk_mgr` is null. The fix adds a check to ensure `dc->clk_mgr` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn32/dcn32_hwseq.c:961 dcn32_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 782)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49916", "url": "https://ubuntu.com/security/CVE-2024-49916", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in dcn401_init_hw This commit addresses a potential null pointer dereference issue in the `dcn401_init_hw` function. The issue could occur when `dc->clk_mgr` or `dc->clk_mgr->funcs` is null. The fix adds a check to ensure `dc->clk_mgr` and `dc->clk_mgr->funcs` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn401/dcn401_hwseq.c:416 dcn401_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 225)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49917", "url": "https://ubuntu.com/security/CVE-2024-49917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in dcn30_init_hw This commit addresses a potential null pointer dereference issue in the `dcn30_init_hw` function. The issue could occur when `dc->clk_mgr` or `dc->clk_mgr->funcs` is null. The fix adds a check to ensure `dc->clk_mgr` and `dc->clk_mgr->funcs` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:789 dcn30_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 628)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49918", "url": "https://ubuntu.com/security/CVE-2024-49918", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for head_pipe in dcn32_acquire_idle_pipe_for_head_pipe_in_layer This commit addresses a potential null pointer dereference issue in the `dcn32_acquire_idle_pipe_for_head_pipe_in_layer` function. The issue could occur when `head_pipe` is null. The fix adds a check to ensure `head_pipe` is not null before asserting it. If `head_pipe` is null, the function returns NULL to prevent a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn32/dcn32_resource.c:2690 dcn32_acquire_idle_pipe_for_head_pipe_in_layer() error: we previously assumed 'head_pipe' could be null (see line 2681)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49919", "url": "https://ubuntu.com/security/CVE-2024-49919", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for head_pipe in dcn201_acquire_free_pipe_for_layer This commit addresses a potential null pointer dereference issue in the `dcn201_acquire_free_pipe_for_layer` function. The issue could occur when `head_pipe` is null. The fix adds a check to ensure `head_pipe` is not null before asserting it. If `head_pipe` is null, the function returns NULL to prevent a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn201/dcn201_resource.c:1016 dcn201_acquire_free_pipe_for_layer() error: we previously assumed 'head_pipe' could be null (see line 1010)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49991", "url": "https://ubuntu.com/security/CVE-2024-49991", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer Pass pointer reference to amdgpu_bo_unref to clear the correct pointer, otherwise amdgpu_bo_unref clear the local variable, the original pointer not set to NULL, this could cause use-after-free bug.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49920", "url": "https://ubuntu.com/security/CVE-2024-49920", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before multiple uses [WHAT & HOW] Poniters, such as stream_enc and dc->bw_vbios, are null checked previously in the same function, so Coverity warns \"implies that stream_enc and dc->bw_vbios might be null\". They are used multiple times in the subsequent code and need to be checked. This fixes 10 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49921", "url": "https://ubuntu.com/security/CVE-2024-49921", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before used [WHAT & HOW] Poniters, such as dc->clk_mgr, are null checked previously in the same function, so Coverity warns \"implies that \"dc->clk_mgr\" might be null\". As a result, these pointers need to be checked when used again. This fixes 10 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49922", "url": "https://ubuntu.com/security/CVE-2024-49922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before using them [WHAT & HOW] These pointers are null checked previously in the same function, indicating they might be null as reported by Coverity. As a result, they need to be checked when used again. This fixes 3 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49923", "url": "https://ubuntu.com/security/CVE-2024-49923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Pass non-null to dcn20_validate_apply_pipe_split_flags [WHAT & HOW] \"dcn20_validate_apply_pipe_split_flags\" dereferences merge, and thus it cannot be a null pointer. Let's pass a valid pointer to avoid null dereference. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49992", "url": "https://ubuntu.com/security/CVE-2024-49992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/stm: Avoid use-after-free issues with crtc and plane ltdc_load() calls functions drm_crtc_init_with_planes(), drm_universal_plane_init() and drm_encoder_init(). These functions should not be called with parameters allocated with devm_kzalloc() to avoid use-after-free issues [1]. Use allocations managed by the DRM framework. Found by Linux Verification Center (linuxtesting.org). [1] https://lore.kernel.org/lkml/u366i76e3qhh3ra5oxrtngjtm2u5lterkekcz6y2jkndhuxzli@diujon4h7qwb/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49993", "url": "https://ubuntu.com/security/CVE-2024-49993", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49924", "url": "https://ubuntu.com/security/CVE-2024-49924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: pxafb: Fix possible use after free in pxafb_task() In the pxafb_probe function, it calls the pxafb_init_fbinfo function, after which &fbi->task is associated with pxafb_task. Moreover, within this pxafb_init_fbinfo function, the pxafb_blank function within the &pxafb_ops struct is capable of scheduling work. If we remove the module which will call pxafb_remove to make cleanup, it will call unregister_framebuffer function which can call do_unregister_framebuffer to free fbi->fb through put_fb_info(fb_info), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | pxafb_task pxafb_remove | unregister_framebuffer(info) | do_unregister_framebuffer(fb_info) | put_fb_info(fb_info) | // free fbi->fb | set_ctrlr_state(fbi, state) | __pxafb_lcd_power(fbi, 0) | fbi->lcd_power(on, &fbi->fb.var) | //use fbi->fb Fix it by ensuring that the work is canceled before proceeding with the cleanup in pxafb_remove. Note that only root user can remove the driver at runtime.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49925", "url": "https://ubuntu.com/security/CVE-2024-49925", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: efifb: Register sysfs groups through driver core The driver core can register and cleanup sysfs groups already. Make use of that functionality to simplify the error handling and cleanup. Also avoid a UAF race during unregistering where the sysctl attributes were usable after the info struct was freed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49926", "url": "https://ubuntu.com/security/CVE-2024-49926", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rcu-tasks: Fix access non-existent percpu rtpcp variable in rcu_tasks_need_gpcb() For kernels built with CONFIG_FORCE_NR_CPUS=y, the nr_cpu_ids is defined as NR_CPUS instead of the number of possible cpus, this will cause the following system panic: smpboot: Allowing 4 CPUs, 0 hotplug CPUs ... setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:512 nr_node_ids:1 ... BUG: unable to handle page fault for address: ffffffff9911c8c8 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 15 Comm: rcu_tasks_trace Tainted: G W 6.6.21 #1 5dc7acf91a5e8e9ac9dcfc35bee0245691283ea6 RIP: 0010:rcu_tasks_need_gpcb+0x25d/0x2c0 RSP: 0018:ffffa371c00a3e60 EFLAGS: 00010082 CR2: ffffffff9911c8c8 CR3: 000000040fa20005 CR4: 00000000001706f0 Call Trace: ? __die+0x23/0x80 ? page_fault_oops+0xa4/0x180 ? exc_page_fault+0x152/0x180 ? asm_exc_page_fault+0x26/0x40 ? rcu_tasks_need_gpcb+0x25d/0x2c0 ? __pfx_rcu_tasks_kthread+0x40/0x40 rcu_tasks_one_gp+0x69/0x180 rcu_tasks_kthread+0x94/0xc0 kthread+0xe8/0x140 ? __pfx_kthread+0x40/0x40 ret_from_fork+0x34/0x80 ? __pfx_kthread+0x40/0x40 ret_from_fork_asm+0x1b/0x80 Considering that there may be holes in the CPU numbers, use the maximum possible cpu number, instead of nr_cpu_ids, for configuring enqueue and dequeue limits. [ neeraj.upadhyay: Fix htmldocs build error reported by Stephen Rothwell ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50007", "url": "https://ubuntu.com/security/CVE-2024-50007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: asihpi: Fix potential OOB array access ASIHPI driver stores some values in the static array upon a response from the driver, and its index depends on the firmware. We shouldn't trust it blindly. This patch adds a sanity check of the array index to fit in the array size.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50017", "url": "https://ubuntu.com/security/CVE-2024-50017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm/ident_map: Use gbpages only where full GB page should be mapped. When ident_pud_init() uses only GB pages to create identity maps, large ranges of addresses not actually requested can be included in the resulting table; a 4K request will map a full GB. This can include a lot of extra address space past that requested, including areas marked reserved by the BIOS. That allows processor speculation into reserved regions, that on UV systems can cause system halts. Only use GB pages when map creation requests include the full GB page of space. Fall back to using smaller 2M pages when only portions of a GB page are included in the request. No attempt is made to coalesce mapping requests. If a request requires a map entry at the 2M (pmd) level, subsequent mapping requests within the same 1G region will also be at the pmd level, even if adjacent or overlapping such requests could have been combined to map a full GB page. Existing usage starts with larger regions and then adds smaller regions, so this should not have any great consequence.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49927", "url": "https://ubuntu.com/security/CVE-2024-49927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/ioapic: Handle allocation failures gracefully Breno observed panics when using failslab under certain conditions during runtime: can not alloc irq_pin_list (-1,0,20) Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed panic+0x4e9/0x590 mp_irqdomain_alloc+0x9ab/0xa80 irq_domain_alloc_irqs_locked+0x25d/0x8d0 __irq_domain_alloc_irqs+0x80/0x110 mp_map_pin_to_irq+0x645/0x890 acpi_register_gsi_ioapic+0xe6/0x150 hpet_open+0x313/0x480 That's a pointless panic which is a leftover of the historic IO/APIC code which panic'ed during early boot when the interrupt allocation failed. The only place which might justify panic is the PIT/HPET timer_check() code which tries to figure out whether the timer interrupt is delivered through the IO/APIC. But that code does not require to handle interrupt allocation failures. If the interrupt cannot be allocated then timer delivery fails and it either panics due to that or falls back to legacy mode. Cure this by removing the panic wrapper around __add_pin_to_irq_node() and making mp_irqdomain_alloc() aware of the failure condition and handle it as any other failure in this function gracefully.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50008", "url": "https://ubuntu.com/security/CVE-2024-50008", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_cmd_802_11_scan_ext() Replace one-element array with a flexible-array member in `struct host_cmd_ds_802_11_scan_ext`. With this, fix the following warning: elo 16 17:51:58 surfacebook kernel: ------------[ cut here ]------------ elo 16 17:51:58 surfacebook kernel: memcpy: detected field-spanning write (size 243) of single field \"ext_scan->tlv_buffer\" at drivers/net/wireless/marvell/mwifiex/scan.c:2239 (size 1) elo 16 17:51:58 surfacebook kernel: WARNING: CPU: 0 PID: 498 at drivers/net/wireless/marvell/mwifiex/scan.c:2239 mwifiex_cmd_802_11_scan_ext+0x83/0x90 [mwifiex]", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50018", "url": "https://ubuntu.com/security/CVE-2024-50018", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49928", "url": "https://ubuntu.com/security/CVE-2024-49928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: avoid reading out of bounds when loading TX power FW elements Because the loop-expression will do one more time before getting false from cond-expression, the original code copied one more entry size beyond valid region. Fix it by moving the entry copy to loop-body.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50178", "url": "https://ubuntu.com/security/CVE-2024-50178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: loongson3: Use raw_smp_processor_id() in do_service_request() Use raw_smp_processor_id() instead of plain smp_processor_id() in do_service_request(), otherwise we may get some errors with the driver enabled: BUG: using smp_processor_id() in preemptible [00000000] code: (udev-worker)/208 caller is loongson3_cpufreq_probe+0x5c/0x250 [loongson3_cpufreq]", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50009", "url": "https://ubuntu.com/security/CVE-2024-50009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: amd-pstate: add check for cpufreq_cpu_get's return value cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it and return in case of error. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49994", "url": "https://ubuntu.com/security/CVE-2024-49994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix integer overflow in BLKSECDISCARD I independently rediscovered \tcommit 22d24a544b0d49bbcbd61c8c0eaf77d3c9297155 \tblock: fix overflow in blk_ioctl_discard() but for secure erase. Same problem: \tuint64_t r[2] = {512, 18446744073709551104ULL}; \tioctl(fd, BLKSECDISCARD, r); will enter near infinite loop inside blkdev_issue_secure_erase(): \ta.out: attempt to access beyond end of device \tloop0: rw=5, sector=3399043073, nr_sectors = 1024 limit=2048 \tbio_check_eod: 3286214 callbacks suppressed", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49929", "url": "https://ubuntu.com/security/CVE-2024-49929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: avoid NULL pointer dereference iwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta pointer is not NULL. It retrieves this pointer using iwl_mvm_sta_from_mac80211, which is dereferencing the ieee80211_sta pointer. If sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL pointer. Fix this by checking the sta pointer before retrieving the mvmsta from it. If sta is not NULL, then mvmsta isn't either.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49995", "url": "https://ubuntu.com/security/CVE-2024-49995", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: guard against string buffer overrun Smatch reports that copying media_name and if_name to name_parts may overwrite the destination. .../bearer.c:166 bearer_name_validate() error: strcpy() 'media_name' too large for 'name_parts->media_name' (32 vs 16) .../bearer.c:167 bearer_name_validate() error: strcpy() 'if_name' too large for 'name_parts->if_name' (1010102 vs 16) This does seem to be the case so guard against this possibility by using strscpy() and failing if truncation occurs. Introduced by commit b97bf3fd8f6a (\"[TIPC] Initial merge\") Compile tested only.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49962", "url": "https://ubuntu.com/security/CVE-2024-49962", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in acpi_db_convert_to_package() ACPICA commit 4d4547cf13cca820ff7e0f859ba83e1a610b9fd0 ACPI_ALLOCATE_ZEROED() may fail, elements might be NULL and will cause NULL pointer dereference later. [ rjw: Subject and changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49930", "url": "https://ubuntu.com/security/CVE-2024-49930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix array out-of-bound access in SoC stats Currently, the ath11k_soc_dp_stats::hal_reo_error array is defined with a maximum size of DP_REO_DST_RING_MAX. However, the ath11k_dp_process_rx() function access ath11k_soc_dp_stats::hal_reo_error using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath11k_dp_process_rx() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49931", "url": "https://ubuntu.com/security/CVE-2024-49931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix array out-of-bound access in SoC stats Currently, the ath12k_soc_dp_stats::hal_reo_error array is defined with a maximum size of DP_REO_DST_RING_MAX. However, the ath12k_dp_rx_process() function access ath12k_soc_dp_stats::hal_reo_error using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath12k_dp_rx_process() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49932", "url": "https://ubuntu.com/security/CVE-2024-49932", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: don't readahead the relocation inode on RST On relocation we're doing readahead on the relocation inode, but if the filesystem is backed by a RAID stripe tree we can get ENOENT (e.g. due to preallocated extents not being mapped in the RST) from the lookup. But readahead doesn't handle the error and submits invalid reads to the device, causing an assertion in the scatter-gather list code: BTRFS info (device nvme1n1): balance: start -d -m -s BTRFS info (device nvme1n1): relocating block group 6480920576 flags data|raid0 BTRFS error (device nvme1n1): cannot find raid-stripe for logical [6481928192, 6481969152] devid 2, profile raid0 ------------[ cut here ]------------ kernel BUG at include/linux/scatterlist.h:115! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 1012 Comm: btrfs Not tainted 6.10.0-rc7+ #567 RIP: 0010:__blk_rq_map_sg+0x339/0x4a0 RSP: 0018:ffffc90001a43820 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffea00045d4802 RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000 RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000001000 R12: ffff8881003d10b8 R13: ffffc90001a438f0 R14: 0000000000000000 R15: 0000000000003000 FS: 00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000002cd11000 CR3: 00000001109ea001 CR4: 0000000000370eb0 Call Trace: ? __die_body.cold+0x14/0x25 ? die+0x2e/0x50 ? do_trap+0xca/0x110 ? do_error_trap+0x65/0x80 ? __blk_rq_map_sg+0x339/0x4a0 ? exc_invalid_op+0x50/0x70 ? __blk_rq_map_sg+0x339/0x4a0 ? asm_exc_invalid_op+0x1a/0x20 ? __blk_rq_map_sg+0x339/0x4a0 nvme_prep_rq.part.0+0x9d/0x770 nvme_queue_rq+0x7d/0x1e0 __blk_mq_issue_directly+0x2a/0x90 ? blk_mq_get_budget_and_tag+0x61/0x90 blk_mq_try_issue_list_directly+0x56/0xf0 blk_mq_flush_plug_list.part.0+0x52b/0x5d0 __blk_flush_plug+0xc6/0x110 blk_finish_plug+0x28/0x40 read_pages+0x160/0x1c0 page_cache_ra_unbounded+0x109/0x180 relocate_file_extent_cluster+0x611/0x6a0 ? btrfs_search_slot+0xba4/0xd20 ? balance_dirty_pages_ratelimited_flags+0x26/0xb00 relocate_data_extent.constprop.0+0x134/0x160 relocate_block_group+0x3f2/0x500 btrfs_relocate_block_group+0x250/0x430 btrfs_relocate_chunk+0x3f/0x130 btrfs_balance+0x71b/0xef0 ? kmalloc_trace_noprof+0x13b/0x280 btrfs_ioctl+0x2c2e/0x3030 ? kvfree_call_rcu+0x1e6/0x340 ? list_lru_add_obj+0x66/0x80 ? mntput_no_expire+0x3a/0x220 __x64_sys_ioctl+0x96/0xc0 do_syscall_64+0x54/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fcc04514f9b Code: Unable to access opcode bytes at 0x7fcc04514f71. RSP: 002b:00007ffeba923370 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fcc04514f9b RDX: 00007ffeba923460 RSI: 00000000c4009420 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000013 R09: 0000000000000001 R10: 00007fcc043fbba8 R11: 0000000000000246 R12: 00007ffeba924fc5 R13: 00007ffeba923460 R14: 0000000000000002 R15: 00000000004d4bb0 Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:__blk_rq_map_sg+0x339/0x4a0 RSP: 0018:ffffc90001a43820 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffea00045d4802 RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000 RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000001000 R12: ffff8881003d10b8 R13: ffffc90001a438f0 R14: 0000000000000000 R15: 0000000000003000 FS: 00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcc04514f71 CR3: 00000001109ea001 CR4: 0000000000370eb0 Kernel p ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49933", "url": "https://ubuntu.com/security/CVE-2024-49933", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk_iocost: fix more out of bound shifts Recently running UBSAN caught few out of bound shifts in the ioc_forgive_debts() function: UBSAN: shift-out-of-bounds in block/blk-iocost.c:2142:38 shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long long') ... UBSAN: shift-out-of-bounds in block/blk-iocost.c:2144:30 shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long long') ... Call Trace: dump_stack_lvl+0xca/0x130 __ubsan_handle_shift_out_of_bounds+0x22c/0x280 ? __lock_acquire+0x6441/0x7c10 ioc_timer_fn+0x6cec/0x7750 ? blk_iocost_init+0x720/0x720 ? call_timer_fn+0x5d/0x470 call_timer_fn+0xfa/0x470 ? blk_iocost_init+0x720/0x720 __run_timer_base+0x519/0x700 ... Actual impact of this issue was not identified but I propose to fix the undefined behaviour. The proposed fix to prevent those out of bound shifts consist of precalculating exponent before using it the shift operations by taking min value from the actual exponent and maximum possible number of bits.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49934", "url": "https://ubuntu.com/security/CVE-2024-49934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/inode: Prevent dump_mapping() accessing invalid dentry.d_name.name It's observed that a crash occurs during hot-remove a memory device, in which user is accessing the hugetlb. See calltrace as following: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 14045 at arch/x86/mm/fault.c:1278 do_user_addr_fault+0x2a0/0x790 Modules linked in: kmem device_dax cxl_mem cxl_pmem cxl_port cxl_pci dax_hmem dax_pmem nd_pmem cxl_acpi nd_btt cxl_core crc32c_intel nvme virtiofs fuse nvme_core nfit libnvdimm dm_multipath scsi_dh_rdac scsi_dh_emc s mirror dm_region_hash dm_log dm_mod CPU: 1 PID: 14045 Comm: daxctl Not tainted 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:do_user_addr_fault+0x2a0/0x790 Code: 48 8b 00 a8 04 0f 84 b5 fe ff ff e9 1c ff ff ff 4c 89 e9 4c 89 e2 be 01 00 00 00 bf 02 00 00 00 e8 b5 ef 24 00 e9 42 fe ff ff <0f> 0b 48 83 c4 08 4c 89 ea 48 89 ee 4c 89 e7 5b 5d 41 5c 41 5d 41 RSP: 0000:ffffc90000a575f0 EFLAGS: 00010046 RAX: ffff88800c303600 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000001000 RSI: ffffffff82504162 RDI: ffffffff824b2c36 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffc90000a57658 R13: 0000000000001000 R14: ffff88800bc2e040 R15: 0000000000000000 FS: 00007f51cb57d880(0000) GS:ffff88807fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000001000 CR3: 00000000072e2004 CR4: 00000000001706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn+0x8d/0x190 ? do_user_addr_fault+0x2a0/0x790 ? report_bug+0x1c3/0x1d0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? do_user_addr_fault+0x2a0/0x790 ? exc_page_fault+0x31/0x200 exc_page_fault+0x68/0x200 <...snip...> BUG: unable to handle page fault for address: 0000000000001000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI ---[ end trace 0000000000000000 ]--- BUG: unable to handle page fault for address: 0000000000001000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 14045 Comm: daxctl Kdump: loaded Tainted: G W 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:dentry_name+0x1f4/0x440 <...snip...> ? dentry_name+0x2fa/0x440 vsnprintf+0x1f3/0x4f0 vprintk_store+0x23a/0x540 vprintk_emit+0x6d/0x330 _printk+0x58/0x80 dump_mapping+0x10b/0x1a0 ? __pfx_free_object_rcu+0x10/0x10 __dump_page+0x26b/0x3e0 ? vprintk_emit+0xe0/0x330 ? _printk+0x58/0x80 ? dump_page+0x17/0x50 dump_page+0x17/0x50 do_migrate_range+0x2f7/0x7f0 ? do_migrate_range+0x42/0x7f0 ? offline_pages+0x2f4/0x8c0 offline_pages+0x60a/0x8c0 memory_subsys_offline+0x9f/0x1c0 ? lockdep_hardirqs_on+0x77/0x100 ? _raw_spin_unlock_irqrestore+0x38/0x60 device_offline+0xe3/0x110 state_store+0x6e/0xc0 kernfs_fop_write_iter+0x143/0x200 vfs_write+0x39f/0x560 ksys_write+0x65/0xf0 do_syscall_64+0x62/0x130 Previously, some sanity check have been done in dump_mapping() before the print facility parsing '%pd' though, it's still possible to run into an invalid dentry.d_name.name. Since dump_mapping() only needs to dump the filename only, retrieve it by itself in a safer way to prevent an unnecessary crash. Note that either retrieving the filename with '%pd' or strncpy_from_kernel_nofault(), the filename could be unreliable.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49935", "url": "https://ubuntu.com/security/CVE-2024-49935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: PAD: fix crash in exit_round_robin() The kernel occasionally crashes in cpumask_clear_cpu(), which is called within exit_round_robin(), because when executing clear_bit(nr, addr) with nr set to 0xffffffff, the address calculation may cause misalignment within the memory, leading to access to an invalid memory address. ---------- BUG: unable to handle kernel paging request at ffffffffe0740618 ... CPU: 3 PID: 2919323 Comm: acpi_pad/14 Kdump: loaded Tainted: G OE X --------- - - 4.18.0-425.19.2.el8_7.x86_64 #1 ... RIP: 0010:power_saving_thread+0x313/0x411 [acpi_pad] Code: 89 cd 48 89 d3 eb d1 48 c7 c7 55 70 72 c0 e8 64 86 b0 e4 c6 05 0d a1 02 00 01 e9 bc fd ff ff 45 89 e4 42 8b 04 a5 20 82 72 c0 48 0f b3 05 f4 9c 01 00 42 c7 04 a5 20 82 72 c0 ff ff ff ff 31 RSP: 0018:ff72a5d51fa77ec8 EFLAGS: 00010202 RAX: 00000000ffffffff RBX: ff462981e5d8cb80 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246 RBP: ff46297556959d80 R08: 0000000000000382 R09: ff46297c8d0f38d8 R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000000e R13: 0000000000000000 R14: ffffffffffffffff R15: 000000000000000e FS: 0000000000000000(0000) GS:ff46297a800c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffe0740618 CR3: 0000007e20410004 CR4: 0000000000771ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? acpi_pad_add+0x120/0x120 [acpi_pad] kthread+0x10b/0x130 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x1f/0x40 ... CR2: ffffffffe0740618 crash> dis -lr ffffffffc0726923 ... /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 114 0xffffffffc0726918 :\tmov %r12d,%r12d /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 325 0xffffffffc072691b :\tmov -0x3f8d7de0(,%r12,4),%eax /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./arch/x86/include/asm/bitops.h: 80 0xffffffffc0726923 :\tlock btr %rax,0x19cf4(%rip) # 0xffffffffc0740620 crash> px tsk_in_cpu[14] $66 = 0xffffffff crash> px 0xffffffffc072692c+0x19cf4 $99 = 0xffffffffc0740620 crash> sym 0xffffffffc0740620 ffffffffc0740620 (b) pad_busy_cpus_bits [acpi_pad] crash> px pad_busy_cpus_bits[0] $42 = 0xfffc0 ---------- To fix this, ensure that tsk_in_cpu[tsk_index] != -1 before calling cpumask_clear_cpu() in exit_round_robin(), just as it is done in round_robin_cpu(). [ rjw: Subject edit, avoid updates to the same value ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49936", "url": "https://ubuntu.com/security/CVE-2024-49936", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/xen-netback: prevent UAF in xenvif_flush_hash() During the list_for_each_entry_rcu iteration call of xenvif_flush_hash, kfree_rcu does not exist inside the rcu read critical section, so if kfree_rcu is called when the rcu grace period ends during the iteration, UAF occurs when accessing head->next after the entry becomes free. Therefore, to solve this, you need to change it to list_for_each_entry_safe.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49937", "url": "https://ubuntu.com/security/CVE-2024-49937", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Set correct chandef when starting CAC When starting CAC in a mode other than AP mode, it return a \"WARNING: CPU: 0 PID: 63 at cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]\" caused by the chandef.chan being null at the end of CAC. Solution: Ensure the channel definition is set for the different modes when starting CAC to avoid getting a NULL 'chan' at the end of CAC. Call Trace: ? show_regs.part.0+0x14/0x16 ? __warn+0x67/0xc0 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? report_bug+0xa7/0x130 ? exc_overflow+0x30/0x30 ? handle_bug+0x27/0x50 ? exc_invalid_op+0x18/0x60 ? handle_exception+0xf6/0xf6 ? exc_overflow+0x30/0x30 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? exc_overflow+0x30/0x30 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? regulatory_propagate_dfs_state.cold+0x1b/0x4c [cfg80211] ? cfg80211_propagate_cac_done_wk+0x1a/0x30 [cfg80211] ? process_one_work+0x165/0x280 ? worker_thread+0x120/0x3f0 ? kthread+0xc2/0xf0 ? process_one_work+0x280/0x280 ? kthread_complete_and_exit+0x20/0x20 ? ret_from_fork+0x19/0x24 [shorten subject, remove OCB, reorder cases to match previous list]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49938", "url": "https://ubuntu.com/security/CVE-2024-49938", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmit Syzbot points out that skb_trim() has a sanity check on the existing length of the skb, which can be uninitialised in some error paths. The intent here is clearly just to reset the length to zero before resubmitting, so switch to calling __skb_set_length(skb, 0) directly. In addition, __skb_set_length() already contains a call to skb_reset_tail_pointer(), so remove the redundant call. The syzbot report came from ath9k_hif_usb_reg_in_cb(), but there's a similar usage of skb_trim() in ath9k_hif_usb_rx_cb(), change both while we're at it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49939", "url": "https://ubuntu.com/security/CVE-2024-49939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: avoid to add interface to list twice when SER If SER L2 occurs during the WoWLAN resume flow, the add interface flow is triggered by ieee80211_reconfig(). However, due to rtw89_wow_resume() return failure, it will cause the add interface flow to be executed again, resulting in a double add list and causing a kernel panic. Therefore, we have added a check to prevent double adding of the list. list_add double add: new=ffff99d6992e2010, prev=ffff99d6992e2010, next=ffff99d695302628. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:37! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G W O 6.6.30-02659-gc18865c4dfbd #1 770df2933251a0e3c888ba69d1053a817a6376a7 Hardware name: HP Grunt/Grunt, BIOS Google_Grunt.11031.169.0 06/24/2021 Workqueue: events_freezable ieee80211_restart_work [mac80211] RIP: 0010:__list_add_valid_or_report+0x5e/0xb0 Code: c7 74 18 48 39 ce 74 13 b0 01 59 5a 5e 5f 41 58 41 59 41 5a 5d e9 e2 d6 03 00 cc 48 c7 c7 8d 4f 17 83 48 89 c2 e8 02 c0 00 00 <0f> 0b 48 c7 c7 aa 8c 1c 83 e8 f4 bf 00 00 0f 0b 48 c7 c7 c8 bc 12 RSP: 0018:ffffa91b8007bc50 EFLAGS: 00010246 RAX: 0000000000000058 RBX: ffff99d6992e0900 RCX: a014d76c70ef3900 RDX: ffffa91b8007bae8 RSI: 00000000ffffdfff RDI: 0000000000000001 RBP: ffffa91b8007bc88 R08: 0000000000000000 R09: ffffa91b8007bae0 R10: 00000000ffffdfff R11: ffffffff83a79800 R12: ffff99d695302060 R13: ffff99d695300900 R14: ffff99d6992e1be0 R15: ffff99d6992e2010 FS: 0000000000000000(0000) GS:ffff99d6aac00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000078fbdba43480 CR3: 000000010e464000 CR4: 00000000001506f0 Call Trace: ? __die_body+0x1f/0x70 ? die+0x3d/0x60 ? do_trap+0xa4/0x110 ? __list_add_valid_or_report+0x5e/0xb0 ? do_error_trap+0x6d/0x90 ? __list_add_valid_or_report+0x5e/0xb0 ? handle_invalid_op+0x30/0x40 ? __list_add_valid_or_report+0x5e/0xb0 ? exc_invalid_op+0x3c/0x50 ? asm_exc_invalid_op+0x16/0x20 ? __list_add_valid_or_report+0x5e/0xb0 rtw89_ops_add_interface+0x309/0x310 [rtw89_core 7c32b1ee6854761c0321027c8a58c5160e41f48f] drv_add_interface+0x5c/0x130 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ieee80211_reconfig+0x241/0x13d0 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ? finish_wait+0x3e/0x90 ? synchronize_rcu_expedited+0x174/0x260 ? sync_rcu_exp_done_unlocked+0x50/0x50 ? wake_bit_function+0x40/0x40 ieee80211_restart_work+0xf0/0x140 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] process_scheduled_works+0x1e5/0x480 worker_thread+0xea/0x1e0 kthread+0xdb/0x110 ? move_linked_works+0x90/0x90 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork+0x3b/0x50 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork_asm+0x11/0x20 Modules linked in: dm_integrity async_xor xor async_tx lz4 lz4_compress zstd zstd_compress zram zsmalloc rfcomm cmac uinput algif_hash algif_skcipher af_alg btusb btrtl iio_trig_hrtimer industrialio_sw_trigger btmtk industrialio_configfs btbcm btintel uvcvideo videobuf2_vmalloc iio_trig_sysfs videobuf2_memops videobuf2_v4l2 videobuf2_common uvc snd_hda_codec_hdmi veth snd_hda_intel snd_intel_dspcfg acpi_als snd_hda_codec industrialio_triggered_buffer kfifo_buf snd_hwdep industrialio i2c_piix4 snd_hda_core designware_i2s ip6table_nat snd_soc_max98357a xt_MASQUERADE xt_cgroup snd_soc_acp_rt5682_mach fuse rtw89_8922ae(O) rtw89_8922a(O) rtw89_pci(O) rtw89_core(O) 8021q mac80211(O) bluetooth ecdh_generic ecc cfg80211 r8152 mii joydev gsmi: Log Shutdown Reason 0x03 ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49940", "url": "https://ubuntu.com/security/CVE-2024-49940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: prevent possible tunnel refcount underflow When a session is created, it sets a backpointer to its tunnel. When the session refcount drops to 0, l2tp_session_free drops the tunnel refcount if session->tunnel is non-NULL. However, session->tunnel is set in l2tp_session_create, before the tunnel refcount is incremented by l2tp_session_register, which leaves a small window where session->tunnel is non-NULL when the tunnel refcount hasn't been bumped. Moving the assignment to l2tp_session_register is trivial but l2tp_session_create calls l2tp_session_set_header_len which uses session->tunnel to get the tunnel's encap. Add an encap arg to l2tp_session_set_header_len to avoid using session->tunnel. If l2tpv3 sessions have colliding IDs, it is possible for l2tp_v3_session_get to race with l2tp_session_register and fetch a session which doesn't yet have session->tunnel set. Add a check for this case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49941", "url": "https://ubuntu.com/security/CVE-2024-49941", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpiolib: Fix potential NULL pointer dereference in gpiod_get_label() In `gpiod_get_label()`, it is possible that `srcu_dereference_check()` may return a NULL pointer, leading to a scenario where `label->str` is accessed without verifying if `label` itself is NULL. This patch adds a proper NULL check for `label` before accessing `label->str`. The check for `label->str != NULL` is removed because `label->str` can never be NULL if `label` is not NULL. This fixes the issue where the label name was being printed as `(efault)` when dumping the sysfs GPIO file when `label == NULL`.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49996", "url": "https://ubuntu.com/security/CVE-2024-49996", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: Fix buffer overflow when parsing NFS reparse points ReparseDataLength is sum of the InodeType size and DataBuffer size. So to get DataBuffer size it is needed to subtract InodeType's size from ReparseDataLength. Function cifs_strndup_from_utf16() is currentlly accessing buf->DataBuffer at position after the end of the buffer because it does not subtract InodeType size from the length. Fix this problem and correctly subtract variable len. Member InodeType is present only when reparse buffer is large enough. Check for ReparseDataLength before accessing InodeType to prevent another invalid memory access. Major and minor rdev values are present also only when reparse buffer is large enough. Check for reparse buffer size before calling reparse_mkdev().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49942", "url": "https://ubuntu.com/security/CVE-2024-49942", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Prevent null pointer access in xe_migrate_copy xe_migrate_copy designed to copy content of TTM resources. When source resource is null, it will trigger a NULL pointer dereference in xe_migrate_copy. To avoid this situation, update lacks source flag to true for this case, the flag will trigger xe_migrate_clear rather than xe_migrate_copy. Issue trace: <7> [317.089847] xe 0000:00:02.0: [drm:xe_migrate_copy [xe]] Pass 14, sizes: 4194304 & 4194304 <7> [317.089945] xe 0000:00:02.0: [drm:xe_migrate_copy [xe]] Pass 15, sizes: 4194304 & 4194304 <1> [317.128055] BUG: kernel NULL pointer dereference, address: 0000000000000010 <1> [317.128064] #PF: supervisor read access in kernel mode <1> [317.128066] #PF: error_code(0x0000) - not-present page <6> [317.128069] PGD 0 P4D 0 <4> [317.128071] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI <4> [317.128074] CPU: 1 UID: 0 PID: 1440 Comm: kunit_try_catch Tainted: G U N 6.11.0-rc7-xe #1 <4> [317.128078] Tainted: [U]=USER, [N]=TEST <4> [317.128080] Hardware name: Intel Corporation Lunar Lake Client Platform/LNL-M LP5 RVP1, BIOS LNLMFWI1.R00.3221.D80.2407291239 07/29/2024 <4> [317.128082] RIP: 0010:xe_migrate_copy+0x66/0x13e0 [xe] <4> [317.128158] Code: 00 00 48 89 8d e0 fe ff ff 48 8b 40 10 4c 89 85 c8 fe ff ff 44 88 8d bd fe ff ff 65 48 8b 3c 25 28 00 00 00 48 89 7d d0 31 ff <8b> 79 10 48 89 85 a0 fe ff ff 48 8b 00 48 89 b5 d8 fe ff ff 83 ff <4> [317.128162] RSP: 0018:ffffc9000167f9f0 EFLAGS: 00010246 <4> [317.128164] RAX: ffff8881120d8028 RBX: ffff88814d070428 RCX: 0000000000000000 <4> [317.128166] RDX: ffff88813cb99c00 RSI: 0000000004000000 RDI: 0000000000000000 <4> [317.128168] RBP: ffffc9000167fbb8 R08: ffff88814e7b1f08 R09: 0000000000000001 <4> [317.128170] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88814e7b1f08 <4> [317.128172] R13: ffff88814e7b1f08 R14: ffff88813cb99c00 R15: 0000000000000001 <4> [317.128174] FS: 0000000000000000(0000) GS:ffff88846f280000(0000) knlGS:0000000000000000 <4> [317.128176] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [317.128178] CR2: 0000000000000010 CR3: 000000011f676004 CR4: 0000000000770ef0 <4> [317.128180] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 <4> [317.128182] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400 <4> [317.128184] PKRU: 55555554 <4> [317.128185] Call Trace: <4> [317.128187] <4> [317.128189] ? show_regs+0x67/0x70 <4> [317.128194] ? __die_body+0x20/0x70 <4> [317.128196] ? __die+0x2b/0x40 <4> [317.128198] ? page_fault_oops+0x15f/0x4e0 <4> [317.128203] ? do_user_addr_fault+0x3fb/0x970 <4> [317.128205] ? lock_acquire+0xc7/0x2e0 <4> [317.128209] ? exc_page_fault+0x87/0x2b0 <4> [317.128212] ? asm_exc_page_fault+0x27/0x30 <4> [317.128216] ? xe_migrate_copy+0x66/0x13e0 [xe] <4> [317.128263] ? __lock_acquire+0xb9d/0x26f0 <4> [317.128265] ? __lock_acquire+0xb9d/0x26f0 <4> [317.128267] ? sg_free_append_table+0x20/0x80 <4> [317.128271] ? lock_acquire+0xc7/0x2e0 <4> [317.128273] ? mark_held_locks+0x4d/0x80 <4> [317.128275] ? trace_hardirqs_on+0x1e/0xd0 <4> [317.128278] ? _raw_spin_unlock_irqrestore+0x31/0x60 <4> [317.128281] ? __pm_runtime_resume+0x60/0xa0 <4> [317.128284] xe_bo_move+0x682/0xc50 [xe] <4> [317.128315] ? lock_is_held_type+0xaa/0x120 <4> [317.128318] ttm_bo_handle_move_mem+0xe5/0x1a0 [ttm] <4> [317.128324] ttm_bo_validate+0xd1/0x1a0 [ttm] <4> [317.128328] shrink_test_run_device+0x721/0xc10 [xe] <4> [317.128360] ? find_held_lock+0x31/0x90 <4> [317.128363] ? lock_release+0xd1/0x2a0 <4> [317.128365] ? __pfx_kunit_generic_run_threadfn_adapter+0x10/0x10 [kunit] <4> [317.128370] xe_bo_shrink_kunit+0x11/0x20 [xe] <4> [317.128397] kunit_try_run_case+0x6e/0x150 [kunit] <4> [317.128400] ? trace_hardirqs_on+0x1e/0xd0 <4> [317.128402] ? _raw_spin_unlock_irqrestore+0x31/0x60 <4> [317.128404] kunit_generic_run_threadfn_adapter+0x1e/0x40 [ku ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49943", "url": "https://ubuntu.com/security/CVE-2024-49943", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc_submit: add missing locking in wedged_fini Any non-wedged queue can have a zero refcount here and can be running concurrently with an async queue destroy, therefore dereferencing the queue ptr to check wedge status after the lookup can trigger UAF if queue is not wedged. Fix this by keeping the submission_state lock held around the check to postpone the free and make the check safe, before dropping again around the put() to avoid the deadlock. (cherry picked from commit d28af0b6b9580b9f90c265a7da0315b0ad20bbfd)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50011", "url": "https://ubuntu.com/security/CVE-2024-50011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: soc-acpi-intel-rpl-match: add missing empty item There is no links_num in struct snd_soc_acpi_mach {}, and we test !link->num_adr as a condition to end the loop in hda_sdw_machine_select(). So an empty item in struct snd_soc_acpi_link_adr array is required.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50174", "url": "https://ubuntu.com/security/CVE-2024-50174", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix race when converting group handle to group object XArray provides it's own internal lock which protects the internal array when entries are being simultaneously added and removed. However there is still a race between retrieving the pointer from the XArray and incrementing the reference count. To avoid this race simply hold the internal XArray lock when incrementing the reference count, this ensures there cannot be a racing call to xa_erase().", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49944", "url": "https://ubuntu.com/security/CVE-2024-49944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_start In sctp_listen_start() invoked by sctp_inet_listen(), it should set the sk_state back to CLOSED if sctp_autobind() fails due to whatever reason. Otherwise, next time when calling sctp_inet_listen(), if sctp_sk(sk)->reuse is already set via setsockopt(SCTP_REUSE_PORT), sctp_sk(sk)->bind_hash will be dereferenced as sk_state is LISTENING, which causes a crash as bind_hash is NULL. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:sctp_inet_listen+0x7f0/0xa20 net/sctp/socket.c:8617 Call Trace: __sys_listen_socket net/socket.c:1883 [inline] __sys_listen+0x1b7/0x230 net/socket.c:1894 __do_sys_listen net/socket.c:1902 [inline]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49945", "url": "https://ubuntu.com/security/CVE-2024-49945", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/ncsi: Disable the ncsi work before freeing the associated structure The work function can run after the ncsi device is freed, resulting in use-after-free bugs or kernel panic.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49946", "url": "https://ubuntu.com/security/CVE-2024-49946", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: do not assume bh is held in ppp_channel_bridge_input() Networking receive path is usually handled from BH handler. However, some protocols need to acquire the socket lock, and packets might be stored in the socket backlog is the socket was owned by a user process. In this case, release_sock(), __release_sock(), and sk_backlog_rcv() might call the sk->sk_backlog_rcv() handler in process context. sybot caught ppp was not considering this case in ppp_channel_bridge_input() : WARNING: inconsistent lock state 6.11.0-rc7-syzkaller-g5f5673607153 #0 Not tainted -------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. ksoftirqd/1/24 [HC0[0]:SC1[1]:HE1:SE0] takes: ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 {SOFTIRQ-ON-W} state was registered at: lock_acquire+0x240/0x728 kernel/locking/lockdep.c:5759 __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline] _raw_spin_lock+0x48/0x60 kernel/locking/spinlock.c:154 spin_lock include/linux/spinlock.h:351 [inline] ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline] ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0xfc/0x314 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv include/net/sock.h:1111 [inline] __release_sock+0x1a8/0x3d8 net/core/sock.c:3004 release_sock+0x68/0x1b8 net/core/sock.c:3558 pppoe_sendmsg+0xc8/0x5d8 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x374/0x4f4 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __arm64_sys_sendto+0xd8/0xf8 net/socket.c:2212 __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:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 irq event stamp: 282914 hardirqs last enabled at (282914): [] __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:151 [inline] hardirqs last enabled at (282914): [] _raw_spin_unlock_irqrestore+0x38/0x98 kernel/locking/spinlock.c:194 hardirqs last disabled at (282913): [] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline] hardirqs last disabled at (282913): [] _raw_spin_lock_irqsave+0x2c/0x7c kernel/locking/spinlock.c:162 softirqs last enabled at (282904): [] softirq_handle_end kernel/softirq.c:400 [inline] softirqs last enabled at (282904): [] handle_softirqs+0xa3c/0xbfc kernel/softirq.c:582 softirqs last disabled at (282909): [] run_ksoftirqd+0x70/0x158 kernel/softirq.c:928 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&pch->downl); lock(&pch->downl); *** DEADLOCK *** 1 lock held by ksoftirqd/1/24: #0: ffff80008f74dfa0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire+0x10/0x4c include/linux/rcupdate.h:325 stack backtrace: CPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 6.11.0-rc7-syzkaller-g5f5673607153 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call trace: dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:319 show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:326 __dump_sta ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49947", "url": "https://ubuntu.com/security/CVE-2024-49947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: test for not too small csum_start in virtio_net_hdr_to_skb() syzbot was able to trigger this warning [1], after injecting a malicious packet through af_packet, setting skb->csum_start and thus the transport header to an incorrect value. We can at least make sure the transport header is after the end of the network header (with a estimated minimal size). [1] [ 67.873027] skb len=4096 headroom=16 headlen=14 tailroom=0 mac=(-1,-1) mac_len=0 net=(16,-6) trans=10 shinfo(txflags=0 nr_frags=1 gso(size=0 type=0 segs=0)) csum(0xa start=10 offset=0 ip_summed=3 complete_sw=0 valid=0 level=0) hash(0x0 sw=0 l4=0) proto=0x0800 pkttype=0 iif=0 priority=0x0 mark=0x0 alloc_cpu=10 vlan_all=0x0 encapsulation=0 inner(proto=0x0000, mac=0, net=0, trans=0) [ 67.877172] dev name=veth0_vlan feat=0x000061164fdd09e9 [ 67.877764] sk family=17 type=3 proto=0 [ 67.878279] skb linear: 00000000: 00 00 10 00 00 00 00 00 0f 00 00 00 08 00 [ 67.879128] skb frag: 00000000: 0e 00 07 00 00 00 28 00 08 80 1c 00 04 00 00 02 [ 67.879877] skb frag: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.880647] skb frag: 00000020: 00 00 02 00 00 00 08 00 1b 00 00 00 00 00 00 00 [ 67.881156] skb frag: 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.881753] skb frag: 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.882173] skb frag: 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.882790] skb frag: 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.883171] skb frag: 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.883733] skb frag: 00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.884206] skb frag: 00000090: 00 00 00 00 00 00 00 00 00 00 69 70 76 6c 61 6e [ 67.884704] skb frag: 000000a0: 31 00 00 00 00 00 00 00 00 00 2b 00 00 00 00 00 [ 67.885139] skb frag: 000000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.885677] skb frag: 000000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.886042] skb frag: 000000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.886408] skb frag: 000000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.887020] skb frag: 000000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.887384] skb frag: 00000100: 00 00 [ 67.887878] ------------[ cut here ]------------ [ 67.887908] offset (-6) >= skb_headlen() (14) [ 67.888445] WARNING: CPU: 10 PID: 2088 at net/core/dev.c:3332 skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.889353] Modules linked in: macsec macvtap macvlan hsr wireguard curve25519_x86_64 libcurve25519_generic libchacha20poly1305 chacha_x86_64 libchacha poly1305_x86_64 dummy bridge sr_mod cdrom evdev pcspkr i2c_piix4 9pnet_virtio 9p 9pnet netfs [ 67.890111] CPU: 10 UID: 0 PID: 2088 Comm: b363492833 Not tainted 6.11.0-virtme #1011 [ 67.890183] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 67.890309] RIP: 0010:skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891043] Call Trace: [ 67.891173] [ 67.891274] ? __warn (kernel/panic.c:741) [ 67.891320] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891333] ? report_bug (lib/bug.c:180 lib/bug.c:219) [ 67.891348] ? handle_bug (arch/x86/kernel/traps.c:239) [ 67.891363] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) [ 67.891372] ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621) [ 67.891388] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891399] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891416] ip_do_fragment (net/ipv4/ip_output.c:777 (discriminator 1)) [ 67.891448] ? __ip_local_out (./include/linux/skbuff.h:1146 ./include/net/l3mdev.h:196 ./include/net/l3mdev.h:213 ne ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49948", "url": "https://ubuntu.com/security/CVE-2024-49948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: add more sanity checks to qdisc_pkt_len_init() One path takes care of SKB_GSO_DODGY, assuming skb->len is bigger than hdr_len. virtio_net_hdr_to_skb() does not fully dissect TCP headers, it only make sure it is at least 20 bytes. It is possible for an user to provide a malicious 'GSO' packet, total length of 80 bytes. - 20 bytes of IPv4 header - 60 bytes TCP header - a small gso_size like 8 virtio_net_hdr_to_skb() would declare this packet as a normal GSO packet, because it would see 40 bytes of payload, bigger than gso_size. We need to make detect this case to not underflow qdisc_skb_cb(skb)->pkt_len.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49949", "url": "https://ubuntu.com/security/CVE-2024-49949", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: avoid potential underflow in qdisc_pkt_len_init() with UFO After commit 7c6d2ecbda83 (\"net: be more gentle about silly gso requests coming from user\") virtio_net_hdr_to_skb() had sanity check to detect malicious attempts from user space to cook a bad GSO packet. Then commit cf9acc90c80ec (\"net: virtio_net_hdr_to_skb: count transport header in UFO\") while fixing one issue, allowed user space to cook a GSO packet with the following characteristic : IPv4 SKB_GSO_UDP, gso_size=3, skb->len = 28. When this packet arrives in qdisc_pkt_len_init(), we end up with hdr_len = 28 (IPv4 header + UDP header), matching skb->len Then the following sets gso_segs to 0 : gso_segs = DIV_ROUND_UP(skb->len - hdr_len, shinfo->gso_size); Then later we set qdisc_skb_cb(skb)->pkt_len to back to zero :/ qdisc_skb_cb(skb)->pkt_len += (gso_segs - 1) * hdr_len; This leads to the following crash in fq_codel [1] qdisc_pkt_len_init() is best effort, we only want an estimation of the bytes sent on the wire, not crashing the kernel. This patch is fixing this particular issue, a following one adds more sanity checks for another potential bug. [1] [ 70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 70.724561] #PF: supervisor read access in kernel mode [ 70.724561] #PF: error_code(0x0000) - not-present page [ 70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0 [ 70.724561] Oops: Oops: 0000 [#1] SMP NOPTI [ 70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991 [ 70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel [ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 <49> 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49 All code ======== 0:\t24 08 \tand $0x8,%al 2:\t49 c1 e1 06 \tshl $0x6,%r9 6:\t44 89 7c 24 18 \tmov %r15d,0x18(%rsp) b:\t45 31 ed \txor %r13d,%r13d e:\t45 31 c0 \txor %r8d,%r8d 11:\t31 ff \txor %edi,%edi 13:\t89 44 24 14 \tmov %eax,0x14(%rsp) 17:\t4c 03 8b 90 01 00 00 \tadd 0x190(%rbx),%r9 1e:\teb 04 \tjmp 0x24 20:\t39 ca \tcmp %ecx,%edx 22:\t73 37 \tjae 0x5b 24:\t4d 8b 39 \tmov (%r9),%r15 27:\t83 c7 01 \tadd $0x1,%edi 2a:*\t49 8b 17 \tmov (%r15),%rdx\t\t<-- trapping instruction 2d:\t49 89 11 \tmov %rdx,(%r9) 30:\t41 8b 57 28 \tmov 0x28(%r15),%edx 34:\t45 8b 5f 34 \tmov 0x34(%r15),%r11d 38:\t49 c7 07 00 00 00 00 \tmovq $0x0,(%r15) 3f:\t49 \trex.WB Code starting with the faulting instruction =========================================== 0:\t49 8b 17 \tmov (%r15),%rdx 3:\t49 89 11 \tmov %rdx,(%r9) 6:\t41 8b 57 28 \tmov 0x28(%r15),%edx a:\t45 8b 5f 34 \tmov 0x34(%r15),%r11d e:\t49 c7 07 00 00 00 00 \tmovq $0x0,(%r15) 15:\t49 \trex.WB [ 70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202 [ 70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000 [ 70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001 [ 70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000 [ 70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58 [ 70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000 [ 70.724561] FS: 000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000 [ 70.724561] CS: 0010 DS: 0000 ES: 0000 C ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49997", "url": "https://ubuntu.com/security/CVE-2024-49997", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: lantiq_etop: fix memory disclosure When applying padding, the buffer is not zeroed, which results in memory disclosure. The mentioned data is observed on the wire. This patch uses skb_put_padto() to pad Ethernet frames properly. The mentioned function zeroes the expanded buffer. In case the packet cannot be padded it is silently dropped. Statistics are also not incremented. This driver does not support statistics in the old 32-bit format or the new 64-bit format. These will be added in the future. In its current form, the patch should be easily backported to stable versions. Ethernet MACs on Amazon-SE and Danube cannot do padding of the packets in hardware, so software padding must be applied.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49998", "url": "https://ubuntu.com/security/CVE-2024-49998", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: improve shutdown sequence Alexander Sverdlin presents 2 problems during shutdown with the lan9303 driver. One is specific to lan9303 and the other just happens to reproduce there. The first problem is that lan9303 is unique among DSA drivers in that it calls dev_get_drvdata() at \"arbitrary runtime\" (not probe, not shutdown, not remove): phy_state_machine() -> ... -> dsa_user_phy_read() -> ds->ops->phy_read() -> lan9303_phy_read() -> chip->ops->phy_read() -> lan9303_mdio_phy_read() -> dev_get_drvdata() But we never stop the phy_state_machine(), so it may continue to run after dsa_switch_shutdown(). Our common pattern in all DSA drivers is to set drvdata to NULL to suppress the remove() method that may come afterwards. But in this case it will result in an NPD. The second problem is that the way in which we set dp->conduit->dsa_ptr = NULL; is concurrent with receive packet processing. dsa_switch_rcv() checks once whether dev->dsa_ptr is NULL, but afterwards, rather than continuing to use that non-NULL value, dev->dsa_ptr is dereferenced again and again without NULL checks: dsa_conduit_find_user() and many other places. In between dereferences, there is no locking to ensure that what was valid once continues to be valid. Both problems have the common aspect that closing the conduit interface solves them. In the first case, dev_close(conduit) triggers the NETDEV_GOING_DOWN event in dsa_user_netdevice_event() which closes user ports as well. dsa_port_disable_rt() calls phylink_stop(), which synchronously stops the phylink state machine, and ds->ops->phy_read() will thus no longer call into the driver after this point. In the second case, dev_close(conduit) should do this, as per Documentation/networking/driver.rst: | Quiescence | ---------- | | After the ndo_stop routine has been called, the hardware must | not receive or transmit any data. All in flight packets must | be aborted. If necessary, poll or wait for completion of | any reset commands. So it should be sufficient to ensure that later, when we zeroize conduit->dsa_ptr, there will be no concurrent dsa_switch_rcv() call on this conduit. The addition of the netif_device_detach() function is to ensure that ioctls, rtnetlinks and ethtool requests on the user ports no longer propagate down to the driver - we're no longer prepared to handle them. The race condition actually did not exist when commit 0650bf52b31f (\"net: dsa: be compatible with masters which unregister on shutdown\") first introduced dsa_switch_shutdown(). It was created later, when we stopped unregistering the user interfaces from a bad spot, and we just replaced that sequence with a racy zeroization of conduit->dsa_ptr (one which doesn't ensure that the interfaces aren't up).", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49999", "url": "https://ubuntu.com/security/CVE-2024-49999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix the setting of the server responding flag In afs_wait_for_operation(), we set transcribe the call responded flag to the server record that we used after doing the fileserver iteration loop - but it's possible to exit the loop having had a response from the server that we've discarded (e.g. it returned an abort or we started receiving data, but the call didn't complete). This means that op->server might be NULL, but we don't check that before attempting to set the server flag.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49950", "url": "https://ubuntu.com/security/CVE-2024-49950", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix uaf in l2cap_connect [Syzbot reported] BUG: KASAN: slab-use-after-free in l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 Read of size 8 at addr ffff8880241e9800 by task kworker/u9:0/54 CPU: 0 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-00268-g788220eee30d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Workqueue: hci2 hci_rx_work Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 l2cap_connect_req net/bluetooth/l2cap_core.c:4080 [inline] l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:4772 [inline] l2cap_sig_channel net/bluetooth/l2cap_core.c:5543 [inline] l2cap_recv_frame+0xf0b/0x8eb0 net/bluetooth/l2cap_core.c:6825 l2cap_recv_acldata+0x9b4/0xb70 net/bluetooth/l2cap_core.c:7514 hci_acldata_packet net/bluetooth/hci_core.c:3791 [inline] hci_rx_work+0xaab/0x1610 net/bluetooth/hci_core.c:4028 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 ... Freed by task 5245: 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:579 poison_slab_object+0xf7/0x160 mm/kasan/common.c:240 __kasan_slab_free+0x32/0x50 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2256 [inline] slab_free mm/slub.c:4477 [inline] kfree+0x12a/0x3b0 mm/slub.c:4598 l2cap_conn_free net/bluetooth/l2cap_core.c:1810 [inline] kref_put include/linux/kref.h:65 [inline] l2cap_conn_put net/bluetooth/l2cap_core.c:1822 [inline] l2cap_conn_del+0x59d/0x730 net/bluetooth/l2cap_core.c:1802 l2cap_connect_cfm+0x9e6/0xf80 net/bluetooth/l2cap_core.c:7241 hci_connect_cfm include/net/bluetooth/hci_core.h:1960 [inline] hci_conn_failed+0x1c3/0x370 net/bluetooth/hci_conn.c:1265 hci_abort_conn_sync+0x75a/0xb50 net/bluetooth/hci_sync.c:5583 abort_conn_sync+0x197/0x360 net/bluetooth/hci_conn.c:2917 hci_cmd_sync_work+0x1a4/0x410 net/bluetooth/hci_sync.c:328 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49951", "url": "https://ubuntu.com/security/CVE-2024-49951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Fix possible crash on mgmt_index_removed If mgmt_index_removed is called while there are commands queued on cmd_sync it could lead to crashes like the bellow trace: 0x0000053D: __list_del_entry_valid_or_report+0x98/0xdc 0x0000053D: mgmt_pending_remove+0x18/0x58 [bluetooth] 0x0000053E: mgmt_remove_adv_monitor_complete+0x80/0x108 [bluetooth] 0x0000053E: hci_cmd_sync_work+0xbc/0x164 [bluetooth] So while handling mgmt_index_removed this attempts to dequeue commands passed as user_data to cmd_sync.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49952", "url": "https://ubuntu.com/security/CVE-2024-49952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: prevent nf_skb_duplicated corruption syzbot found that nf_dup_ipv4() or nf_dup_ipv6() could write per-cpu variable nf_skb_duplicated in an unsafe way [1]. Disabling preemption as hinted by the splat is not enough, we have to disable soft interrupts as well. [1] BUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316 caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49 nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook+0x2c4/0x450 include/linux/netfilter.h:269 NF_HOOK_COND include/linux/netfilter.h:302 [inline] ip_output+0x185/0x230 net/ipv4/ip_output.c:433 ip_local_out net/ipv4/ip_output.c:129 [inline] ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495 udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981 udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737 __do_sys_sendmmsg net/socket.c:2766 [inline] __se_sys_sendmmsg net/socket.c:2763 [inline] __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763 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:0x7f4ce4f7def9 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:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9 RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006 RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49953", "url": "https://ubuntu.com/security/CVE-2024-49953", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix crash caused by calling __xfrm_state_delete() twice The km.state is not checked in driver's delayed work. When xfrm_state_check_expire() is called, the state can be reset to XFRM_STATE_EXPIRED, even if it is XFRM_STATE_DEAD already. This happens when xfrm state is deleted, but not freed yet. As __xfrm_state_delete() is called again in xfrm timer, the following crash occurs. To fix this issue, skip xfrm_state_check_expire() if km.state is not XFRM_STATE_VALID. Oops: general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] SMP CPU: 5 UID: 0 PID: 7448 Comm: kworker/u102:2 Not tainted 6.11.0-rc2+ #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5e_ipsec: eth%d mlx5e_ipsec_handle_sw_limits [mlx5_core] RIP: 0010:__xfrm_state_delete+0x3d/0x1b0 Code: 0f 84 8b 01 00 00 48 89 fd c6 87 c8 00 00 00 05 48 8d bb 40 10 00 00 e8 11 04 1a 00 48 8b 95 b8 00 00 00 48 8b 85 c0 00 00 00 <48> 89 42 08 48 89 10 48 8b 55 10 48 b8 00 01 00 00 00 00 ad de 48 RSP: 0018:ffff88885f945ec8 EFLAGS: 00010246 RAX: dead000000000122 RBX: ffffffff82afa940 RCX: 0000000000000036 RDX: dead000000000100 RSI: 0000000000000000 RDI: ffffffff82afb980 RBP: ffff888109a20340 R08: ffff88885f945ea0 R09: 0000000000000000 R10: 0000000000000000 R11: ffff88885f945ff8 R12: 0000000000000246 R13: ffff888109a20340 R14: ffff88885f95f420 R15: ffff88885f95f400 FS: 0000000000000000(0000) GS:ffff88885f940000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2163102430 CR3: 00000001128d6001 CR4: 0000000000370eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? die_addr+0x33/0x90 ? exc_general_protection+0x1a2/0x390 ? asm_exc_general_protection+0x22/0x30 ? __xfrm_state_delete+0x3d/0x1b0 ? __xfrm_state_delete+0x2f/0x1b0 xfrm_timer_handler+0x174/0x350 ? __xfrm_state_delete+0x1b0/0x1b0 __hrtimer_run_queues+0x121/0x270 hrtimer_run_softirq+0x88/0xd0 handle_softirqs+0xcc/0x270 do_softirq+0x3c/0x50 __local_bh_enable_ip+0x47/0x50 mlx5e_ipsec_handle_sw_limits+0x7d/0x90 [mlx5_core] process_one_work+0x137/0x2d0 worker_thread+0x28d/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50000", "url": "https://ubuntu.com/security/CVE-2024-50000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix NULL deref in mlx5e_tir_builder_alloc() In mlx5e_tir_builder_alloc() kvzalloc() may return NULL which is dereferenced on the next line in a reference to the modify field. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50001", "url": "https://ubuntu.com/security/CVE-2024-50001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix error path in multi-packet WQE transmit Remove the erroneous unmap in case no DMA mapping was established The multi-packet WQE transmit code attempts to obtain a DMA mapping for the skb. This could fail, e.g. under memory pressure, when the IOMMU driver just can't allocate more memory for page tables. While the code tries to handle this in the path below the err_unmap label it erroneously unmaps one entry from the sq's FIFO list of active mappings. Since the current map attempt failed this unmap is removing some random DMA mapping that might still be required. If the PCI function now presents that IOVA, the IOMMU may assumes a rogue DMA access and e.g. on s390 puts the PCI function in error state. The erroneous behavior was seen in a stress-test environment that created memory pressure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50179", "url": "https://ubuntu.com/security/CVE-2024-50179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: remove the incorrect Fw reference check when dirtying pages When doing the direct-io reads it will also try to mark pages dirty, but for the read path it won't hold the Fw caps and there is case will it get the Fw reference.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49963", "url": "https://ubuntu.com/security/CVE-2024-49963", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mailbox: bcm2835: Fix timeout during suspend mode During noirq suspend phase the Raspberry Pi power driver suffer of firmware property timeouts. The reason is that the IRQ of the underlying BCM2835 mailbox is disabled and rpi_firmware_property_list() will always run into a timeout [1]. Since the VideoCore side isn't consider as a wakeup source, set the IRQF_NO_SUSPEND flag for the mailbox IRQ in order to keep it enabled during suspend-resume cycle. [1] PM: late suspend of devices complete after 1.754 msecs WARNING: CPU: 0 PID: 438 at drivers/firmware/raspberrypi.c:128 rpi_firmware_property_list+0x204/0x22c Firmware transaction 0x00028001 timeout Modules linked in: CPU: 0 PID: 438 Comm: bash Tainted: G C 6.9.3-dirty #17 Hardware name: BCM2835 Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x44 dump_stack_lvl from __warn+0x88/0xec __warn from warn_slowpath_fmt+0x7c/0xb0 warn_slowpath_fmt from rpi_firmware_property_list+0x204/0x22c rpi_firmware_property_list from rpi_firmware_property+0x68/0x8c rpi_firmware_property from rpi_firmware_set_power+0x54/0xc0 rpi_firmware_set_power from _genpd_power_off+0xe4/0x148 _genpd_power_off from genpd_sync_power_off+0x7c/0x11c genpd_sync_power_off from genpd_finish_suspend+0xcc/0xe0 genpd_finish_suspend from dpm_run_callback+0x78/0xd0 dpm_run_callback from device_suspend_noirq+0xc0/0x238 device_suspend_noirq from dpm_suspend_noirq+0xb0/0x168 dpm_suspend_noirq from suspend_devices_and_enter+0x1b8/0x5ac suspend_devices_and_enter from pm_suspend+0x254/0x2e4 pm_suspend from state_store+0xa8/0xd4 state_store from kernfs_fop_write_iter+0x154/0x1a0 kernfs_fop_write_iter from vfs_write+0x12c/0x184 vfs_write from ksys_write+0x78/0xc0 ksys_write from ret_fast_syscall+0x0/0x54 Exception stack(0xcc93dfa8 to 0xcc93dff0) [...] PM: noirq suspend of devices complete after 3095.584 msecs", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49954", "url": "https://ubuntu.com/security/CVE-2024-49954", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: static_call: Replace pointless WARN_ON() in static_call_module_notify() static_call_module_notify() triggers a WARN_ON(), when memory allocation fails in __static_call_add_module(). That's not really justified, because the failure case must be correctly handled by the well known call chain and the error code is passed through to the initiating userspace application. A memory allocation fail is not a fatal problem, but the WARN_ON() takes the machine out when panic_on_warn is set. Replace it with a pr_warn().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50002", "url": "https://ubuntu.com/security/CVE-2024-50002", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: static_call: Handle module init failure correctly in static_call_del_module() Module insertion invokes static_call_add_module() to initialize the static calls in a module. static_call_add_module() invokes __static_call_init(), which allocates a struct static_call_mod to either encapsulate the built-in static call sites of the associated key into it so further modules can be added or to append the module to the module chain. If that allocation fails the function returns with an error code and the module core invokes static_call_del_module() to clean up eventually added static_call_mod entries. This works correctly, when all keys used by the module were converted over to a module chain before the failure. If not then static_call_del_module() causes a #GP as it blindly assumes that key::mods points to a valid struct static_call_mod. The problem is that key::mods is not a individual struct member of struct static_call_key, it's part of a union to save space: union { /* bit 0: 0 = mods, 1 = sites */ unsigned long type; struct static_call_mod *mods; struct static_call_site *sites; \t}; key::sites is a pointer to the list of built-in usage sites of the static call. The type of the pointer is differentiated by bit 0. A mods pointer has the bit clear, the sites pointer has the bit set. As static_call_del_module() blidly assumes that the pointer is a valid static_call_mod type, it fails to check for this failure case and dereferences the pointer to the list of built-in call sites, which is obviously bogus. Cure it by checking whether the key has a sites or a mods pointer. If it's a sites pointer then the key is not to be touched. As the sites are walked in the same order as in __static_call_init() the site walk can be terminated because all subsequent sites have not been touched by the init code due to the error exit. If it was converted before the allocation fail, then the inner loop which searches for a module match will find nothing. A fail in the second allocation in __static_call_init() is harmless and does not require special treatment. The first allocation succeeded and converted the key to a module chain. That first entry has mod::mod == NULL and mod::next == NULL, so the inner loop of static_call_del_module() will neither find a module match nor a module chain. The next site in the walk was either already converted, but can't match the module, or it will exit the outer loop because it has a static_call_site pointer and not a static_call_mod pointer.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-47675", "url": "https://ubuntu.com/security/CVE-2024-47675", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix use-after-free in bpf_uprobe_multi_link_attach() If bpf_link_prime() fails, bpf_uprobe_multi_link_attach() goes to the error_free label and frees the array of bpf_uprobe's without calling bpf_uprobe_unregister(). This leaks bpf_uprobe->uprobe and worse, this frees bpf_uprobe->consumer without removing it from the uprobe->consumers list.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47676", "url": "https://ubuntu.com/security/CVE-2024-47676", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb.c: fix UAF of vma in hugetlb fault pathway Syzbot reports a UAF in hugetlb_fault(). This happens because vmf_anon_prepare() could drop the per-VMA lock and allow the current VMA to be freed before hugetlb_vma_unlock_read() is called. We can fix this by using a modified version of vmf_anon_prepare() that doesn't release the VMA lock on failure, and then release it ourselves after hugetlb_vma_unlock_read().", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47677", "url": "https://ubuntu.com/security/CVE-2024-47677", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: resolve memory leak from exfat_create_upcase_table() If exfat_load_upcase_table reaches end and returns -EINVAL, allocated memory doesn't get freed and while exfat_load_default_upcase_table allocates more memory, leading to a memory leak. Here's link to syzkaller crash report illustrating this issue: https://syzkaller.appspot.com/text?tag=CrashReport&x=1406c201980000", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47725", "url": "https://ubuntu.com/security/CVE-2024-47725", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47739", "url": "https://ubuntu.com/security/CVE-2024-47739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: padata: use integer wrap around to prevent deadlock on seq_nr overflow When submitting more than 2^32 padata objects to padata_do_serial, the current sorting implementation incorrectly sorts padata objects with overflowed seq_nr, causing them to be placed before existing objects in the reorder list. This leads to a deadlock in the serialization process as padata_find_next cannot match padata->seq_nr and pd->processed because the padata instance with overflowed seq_nr will be selected next. To fix this, we use an unsigned integer wrap around to correctly sort padata objects in scenarios with integer overflow.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47678", "url": "https://ubuntu.com/security/CVE-2024-47678", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: icmp: change the order of rate limits ICMP messages are ratelimited : After the blamed commits, the two rate limiters are applied in this order: 1) host wide ratelimit (icmp_global_allow()) 2) Per destination ratelimit (inetpeer based) In order to avoid side-channels attacks, we need to apply the per destination check first. This patch makes the following change : 1) icmp_global_allow() checks if the host wide limit is reached. But credits are not yet consumed. This is deferred to 3) 2) The per destination limit is checked/updated. This might add a new node in inetpeer tree. 3) icmp_global_consume() consumes tokens if prior operations succeeded. This means that host wide ratelimit is still effective in keeping inetpeer tree small even under DDOS. As a bonus, I removed icmp_global.lock as the fast path can use a lock-free operation.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47733", "url": "https://ubuntu.com/security/CVE-2024-47733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfs: Delete subtree of 'fs/netfs' when netfs module exits In netfs_init() or fscache_proc_init(), we create dentry under 'fs/netfs', but in netfs_exit(), we only delete the proc entry of 'fs/netfs' without deleting its subtree. This triggers the following WARNING: ================================================================== remove_proc_entry: removing non-empty directory 'fs/netfs', leaking at least 'requests' WARNING: CPU: 4 PID: 566 at fs/proc/generic.c:717 remove_proc_entry+0x160/0x1c0 Modules linked in: netfs(-) CPU: 4 UID: 0 PID: 566 Comm: rmmod Not tainted 6.11.0-rc3 #860 RIP: 0010:remove_proc_entry+0x160/0x1c0 Call Trace: netfs_exit+0x12/0x620 [netfs] __do_sys_delete_module.isra.0+0x14c/0x2e0 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e ================================================================== Therefore use remove_proc_subtree() instead of remove_proc_entry() to fix the above problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47679", "url": "https://ubuntu.com/security/CVE-2024-47679", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfs: fix race between evice_inodes() and find_inode()&iput() Hi, all Recently I noticed a bug[1] in btrfs, after digged it into and I believe it'a race in vfs. Let's assume there's a inode (ie ino 261) with i_count 1 is called by iput(), and there's a concurrent thread calling generic_shutdown_super(). cpu0: cpu1: iput() // i_count is 1 ->spin_lock(inode) ->dec i_count to 0 ->iput_final() generic_shutdown_super() ->__inode_add_lru() ->evict_inodes() // cause some reason[2] ->if (atomic_read(inode->i_count)) continue; // return before // inode 261 passed the above check // list_lru_add_obj() // and then schedule out ->spin_unlock() // note here: the inode 261 // was still at sb list and hash list, // and I_FREEING|I_WILL_FREE was not been set btrfs_iget() // after some function calls ->find_inode() // found the above inode 261 ->spin_lock(inode) // check I_FREEING|I_WILL_FREE // and passed ->__iget() ->spin_unlock(inode) // schedule back ->spin_lock(inode) // check (I_NEW|I_FREEING|I_WILL_FREE) flags, // passed and set I_FREEING iput() ->spin_unlock(inode) ->spin_lock(inode)\t\t\t ->evict() // dec i_count to 0 ->iput_final() ->spin_unlock() ->evict() Now, we have two threads simultaneously evicting the same inode, which may trigger the BUG(inode->i_state & I_CLEAR) statement both within clear_inode() and iput(). To fix the bug, recheck the inode->i_count after holding i_lock. Because in the most scenarios, the first check is valid, and the overhead of spin_lock() can be reduced. If there is any misunderstanding, please let me know, thanks. [1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/ [2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable() return false when I reproduced the bug.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49859", "url": "https://ubuntu.com/security/CVE-2024-49859", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to check atomic_file in f2fs ioctl interfaces Some f2fs ioctl interfaces like f2fs_ioc_set_pin_file(), f2fs_move_file_range(), and f2fs_defragment_range() missed to check atomic_write status, which may cause potential race issue, fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47680", "url": "https://ubuntu.com/security/CVE-2024-47680", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: check discard support for conventional zones As the helper function f2fs_bdev_support_discard() shows, f2fs checks if the target block devices support discard by calling bdev_max_discard_sectors() and bdev_is_zoned(). This check works well for most cases, but it does not work for conventional zones on zoned block devices. F2fs assumes that zoned block devices support discard, and calls __submit_discard_cmd(). When __submit_discard_cmd() is called for sequential write required zones, it works fine since __submit_discard_cmd() issues zone reset commands instead of discard commands. However, when __submit_discard_cmd() is called for conventional zones, __blkdev_issue_discard() is called even when the devices do not support discard. The inappropriate __blkdev_issue_discard() call was not a problem before the commit 30f1e7241422 (\"block: move discard checks into the ioctl handler\") because __blkdev_issue_discard() checked if the target devices support discard or not. If not, it returned EOPNOTSUPP. After the commit, __blkdev_issue_discard() no longer checks it. It always returns zero and sets NULL to the given bio pointer. This NULL pointer triggers f2fs_bug_on() in __submit_discard_cmd(). The BUG is recreated with the commands below at the umount step, where /dev/nullb0 is a zoned null_blk with 5GB total size, 128MB zone size and 10 conventional zones. $ mkfs.f2fs -f -m /dev/nullb0 $ mount /dev/nullb0 /mnt $ for ((i=0;i<5;i++)); do dd if=/dev/zero of=/mnt/test bs=65536 count=1600 conv=fsync; done $ umount /mnt To fix the BUG, avoid the inappropriate __blkdev_issue_discard() call. When discard is requested for conventional zones, check if the device supports discard or not. If not, return EOPNOTSUPP.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47740", "url": "https://ubuntu.com/security/CVE-2024-47740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: Require FMODE_WRITE for atomic write ioctls The F2FS ioctls for starting and committing atomic writes check for inode_owner_or_capable(), but this does not give LSMs like SELinux or Landlock an opportunity to deny the write access - if the caller's FSUID matches the inode's UID, inode_owner_or_capable() immediately returns true. There are scenarios where LSMs want to deny a process the ability to write particular files, even files that the FSUID of the process owns; but this can currently partially be bypassed using atomic write ioctls in two ways: - F2FS_IOC_START_ATOMIC_REPLACE + F2FS_IOC_COMMIT_ATOMIC_WRITE can truncate an inode to size 0 - F2FS_IOC_START_ATOMIC_WRITE + F2FS_IOC_ABORT_ATOMIC_WRITE can revert changes another process concurrently made to a file Fix it by requiring FMODE_WRITE for these operations, just like for F2FS_IOC_MOVE_RANGE. Since any legitimate caller should only be using these ioctls when intending to write into the file, that seems unlikely to break anything.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47726", "url": "https://ubuntu.com/security/CVE-2024-47726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to wait dio completion It should wait all existing dio write IOs before block removal, otherwise, previous direct write IO may overwrite data in the block which may be reused by other inode.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47741", "url": "https://ubuntu.com/security/CVE-2024-47741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race setting file private on concurrent lseek using same fd When doing concurrent lseek(2) system calls against the same file descriptor, using multiple threads belonging to the same process, we have a short time window where a race happens and can result in a memory leak. The race happens like this: 1) A program opens a file descriptor for a file and then spawns two threads (with the pthreads library for example), lets call them task A and task B; 2) Task A calls lseek with SEEK_DATA or SEEK_HOLE and ends up at file.c:find_desired_extent() while holding a read lock on the inode; 3) At the start of find_desired_extent(), it extracts the file's private_data pointer into a local variable named 'private', which has a value of NULL; 4) Task B also calls lseek with SEEK_DATA or SEEK_HOLE, locks the inode in shared mode and enters file.c:find_desired_extent(), where it also extracts file->private_data into its local variable 'private', which has a NULL value; 5) Because it saw a NULL file private, task A allocates a private structure and assigns to the file structure; 6) Task B also saw a NULL file private so it also allocates its own file private and then assigns it to the same file structure, since both tasks are using the same file descriptor. At this point we leak the private structure allocated by task A. Besides the memory leak, there's also the detail that both tasks end up using the same cached state record in the private structure (struct btrfs_file_private::llseek_cached_state), which can result in a use-after-free problem since one task can free it while the other is still using it (only one task took a reference count on it). Also, sharing the cached state is not a good idea since it could result in incorrect results in the future - right now it should not be a problem because it end ups being used only in extent-io-tree.c:count_range_bits() where we do range validation before using the cached state. Fix this by protecting the private assignment and check of a file while holding the inode's spinlock and keep track of the task that allocated the private, so that it's used only by that task in order to prevent user-after-free issues with the cached state record as well as potentially using it incorrectly in the future.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47681", "url": "https://ubuntu.com/security/CVE-2024-47681", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix NULL pointer dereference in mt7996_mcu_sta_bfer_he Fix the NULL pointer dereference in mt7996_mcu_sta_bfer_he routine adding an sta interface to the mt7996 driver. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49858", "url": "https://ubuntu.com/security/CVE-2024-49858", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption The TPM event log table is a Linux specific construct, where the data produced by the GetEventLog() boot service is cached in memory, and passed on to the OS using an EFI configuration table. The use of EFI_LOADER_DATA here results in the region being left unreserved in the E820 memory map constructed by the EFI stub, and this is the memory description that is passed on to the incoming kernel by kexec, which is therefore unaware that the region should be reserved. Even though the utility of the TPM2 event log after a kexec is questionable, any corruption might send the parsing code off into the weeds and crash the kernel. So let's use EFI_ACPI_RECLAIM_MEMORY instead, which is always treated as reserved by the E820 conversion logic.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49860", "url": "https://ubuntu.com/security/CVE-2024-49860", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: sysfs: validate return type of _STR method Only buffer objects are valid return values of _STR. If something else is returned description_show() will access invalid memory.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47742", "url": "https://ubuntu.com/security/CVE-2024-47742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware_loader: Block path traversal Most firmware names are hardcoded strings, or are constructed from fairly constrained format strings where the dynamic parts are just some hex numbers or such. However, there are a couple codepaths in the kernel where firmware file names contain string components that are passed through from a device or semi-privileged userspace; the ones I could find (not counting interfaces that require root privileges) are: - lpfc_sli4_request_firmware_update() seems to construct the firmware filename from \"ModelName\", a string that was previously parsed out of some descriptor (\"Vital Product Data\") in lpfc_fill_vpd() - nfp_net_fw_find() seems to construct a firmware filename from a model name coming from nfp_hwinfo_lookup(pf->hwinfo, \"nffw.partno\"), which I think parses some descriptor that was read from the device. (But this case likely isn't exploitable because the format string looks like \"netronome/nic_%s\", and there shouldn't be any *folders* starting with \"netronome/nic_\". The previous case was different because there, the \"%s\" is *at the start* of the format string.) - module_flash_fw_schedule() is reachable from the ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is enough to pass the privilege check), and takes a userspace-provided firmware name. (But I think to reach this case, you need to have CAP_NET_ADMIN over a network namespace that a special kind of ethernet device is mapped into, so I think this is not a viable attack path in practice.) Fix it by rejecting any firmware names containing \"..\" path components. For what it's worth, I went looking and haven't found any USB device drivers that use the firmware loader dangerously.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47682", "url": "https://ubuntu.com/security/CVE-2024-47682", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sd: Fix off-by-one error in sd_read_block_characteristics() Ff the device returns page 0xb1 with length 8 (happens with qemu v2.x, for example), sd_read_block_characteristics() may attempt an out-of-bounds memory access when accessing the zoned field at offset 8.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47743", "url": "https://ubuntu.com/security/CVE-2024-47743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: prevent NULL pointer dereference in find_asymmetric_key() In find_asymmetric_key(), if all NULLs are passed in the id_{0,1,2} arguments, the kernel will first emit WARN but then have an oops because id_2 gets dereferenced anyway. Add the missing id_2 check and move WARN_ON() to the final else branch to avoid duplicate NULL checks. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47727", "url": "https://ubuntu.com/security/CVE-2024-47727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/tdx: Fix \"in-kernel MMIO\" check TDX only supports kernel-initiated MMIO operations. The handle_mmio() function checks if the #VE exception occurred in the kernel and rejects the operation if it did not. However, userspace can deceive the kernel into performing MMIO on its behalf. For example, if userspace can point a syscall to an MMIO address, syscall does get_user() or put_user() on it, triggering MMIO #VE. The kernel will treat the #VE as in-kernel MMIO. Ensure that the target MMIO address is within the kernel before decoding instruction.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47744", "url": "https://ubuntu.com/security/CVE-2024-47744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Use dedicated mutex to protect kvm_usage_count to avoid deadlock Use a dedicated mutex to guard kvm_usage_count to fix a potential deadlock on x86 due to a chain of locks and SRCU synchronizations. Translating the below lockdep splat, CPU1 #6 will wait on CPU0 #1, CPU0 #8 will wait on CPU2 #3, and CPU2 #7 will wait on CPU1 #4 (if there's a writer, due to the fairness of r/w semaphores). CPU0 CPU1 CPU2 1 lock(&kvm->slots_lock); 2 lock(&vcpu->mutex); 3 lock(&kvm->srcu); 4 lock(cpu_hotplug_lock); 5 lock(kvm_lock); 6 lock(&kvm->slots_lock); 7 lock(cpu_hotplug_lock); 8 sync(&kvm->srcu); Note, there are likely more potential deadlocks in KVM x86, e.g. the same pattern of taking cpu_hotplug_lock outside of kvm_lock likely exists with __kvmclock_cpufreq_notifier(): cpuhp_cpufreq_online() | -> cpufreq_online() | -> cpufreq_gov_performance_limits() | -> __cpufreq_driver_target() | -> __target_index() | -> cpufreq_freq_transition_begin() | -> cpufreq_notify_transition() | -> ... __kvmclock_cpufreq_notifier() But, actually triggering such deadlocks is beyond rare due to the combination of dependencies and timings involved. E.g. the cpufreq notifier is only used on older CPUs without a constant TSC, mucking with the NX hugepage mitigation while VMs are running is very uncommon, and doing so while also onlining/offlining a CPU (necessary to generate contention on cpu_hotplug_lock) would be even more unusual. The most robust solution to the general cpu_hotplug_lock issue is likely to switch vm_list to be an RCU-protected list, e.g. so that x86's cpufreq notifier doesn't to take kvm_lock. For now, settle for fixing the most blatant deadlock, as switching to an RCU-protected list is a much more involved change, but add a comment in locking.rst to call out that care needs to be taken when walking holding kvm_lock and walking vm_list. ====================================================== WARNING: possible circular locking dependency detected 6.10.0-smp--c257535a0c9d-pip #330 Tainted: G S O ------------------------------------------------------ tee/35048 is trying to acquire lock: ff6a80eced71e0a8 (&kvm->slots_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x179/0x1e0 [kvm] but task is already holding lock: ffffffffc07abb08 (kvm_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x14a/0x1e0 [kvm] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (kvm_lock){+.+.}-{3:3}: __mutex_lock+0x6a/0xb40 mutex_lock_nested+0x1f/0x30 kvm_dev_ioctl+0x4fb/0xe50 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #2 (cpu_hotplug_lock){++++}-{0:0}: cpus_read_lock+0x2e/0xb0 static_key_slow_inc+0x16/0x30 kvm_lapic_set_base+0x6a/0x1c0 [kvm] kvm_set_apic_base+0x8f/0xe0 [kvm] kvm_set_msr_common+0x9ae/0xf80 [kvm] vmx_set_msr+0xa54/0xbe0 [kvm_intel] __kvm_set_msr+0xb6/0x1a0 [kvm] kvm_arch_vcpu_ioctl+0xeca/0x10c0 [kvm] kvm_vcpu_ioctl+0x485/0x5b0 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (&kvm->srcu){.+.+}-{0:0}: __synchronize_srcu+0x44/0x1a0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47719", "url": "https://ubuntu.com/security/CVE-2024-47719", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommufd: Protect against overflow of ALIGN() during iova allocation Userspace can supply an iova and uptr such that the target iova alignment becomes really big and ALIGN() overflows which corrupts the selected area range during allocation. CONFIG_IOMMUFD_TEST can detect this: WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline] WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352 Modules linked in: CPU: 1 PID: 5092 Comm: syz-executor294 Not tainted 6.10.0-rc5-syzkaller-00294-g3ffea9a7a6f7 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024 RIP: 0010:iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline] RIP: 0010:iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352 Code: fc e9 a4 f3 ff ff e8 1a 8b 4c fc 41 be e4 ff ff ff e9 8a f3 ff ff e8 0a 8b 4c fc 90 0f 0b 90 e9 37 f5 ff ff e8 fc 8a 4c fc 90 <0f> 0b 90 e9 68 f3 ff ff 48 c7 c1 ec 82 ad 8f 80 e1 07 80 c1 03 38 RSP: 0018:ffffc90003ebf9e0 EFLAGS: 00010293 RAX: ffffffff85499fa4 RBX: 00000000ffffffef RCX: ffff888079b49e00 RDX: 0000000000000000 RSI: 00000000ffffffef RDI: 0000000000000000 RBP: ffffc90003ebfc50 R08: ffffffff85499b30 R09: ffffffff85499942 R10: 0000000000000002 R11: ffff888079b49e00 R12: ffff8880228e0010 R13: 0000000000000000 R14: 1ffff920007d7f68 R15: ffffc90003ebfd00 FS: 000055557d760380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000005fdeb8 CR3: 000000007404a000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: iommufd_ioas_copy+0x610/0x7b0 drivers/iommu/iommufd/ioas.c:274 iommufd_fops_ioctl+0x4d9/0x5a0 drivers/iommu/iommufd/main.c:421 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Cap the automatic alignment to the huge page size, which is probably a better idea overall. Huge automatic alignments can fragment and chew up the available IOVA space without any reason.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47745", "url": "https://ubuntu.com/security/CVE-2024-47745", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: call the security_mmap_file() LSM hook in remap_file_pages() The remap_file_pages syscall handler calls do_mmap() directly, which doesn't contain the LSM security check. And if the process has called personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for RW pages, this will actually result in remapping the pages to RWX, bypassing a W^X policy enforced by SELinux. So we should check prot by security_mmap_file LSM hook in the remap_file_pages syscall handler before do_mmap() is called. Otherwise, it potentially permits an attacker to bypass a W^X policy enforced by SELinux. The bypass is similar to CVE-2016-10044, which bypass the same thing via AIO and can be found in [1]. The PoC: $ cat > test.c int main(void) { \tsize_t pagesz = sysconf(_SC_PAGE_SIZE); \tint mfd = syscall(SYS_memfd_create, \"test\", 0); \tconst char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE, \t\tMAP_SHARED, mfd, 0); \tunsigned int old = syscall(SYS_personality, 0xffffffff); \tsyscall(SYS_personality, READ_IMPLIES_EXEC | old); \tsyscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0); \tsyscall(SYS_personality, old); \t// show the RWX page exists even if W^X policy is enforced \tint fd = open(\"/proc/self/maps\", O_RDONLY); \tunsigned char buf2[1024]; \twhile (1) { \t\tint ret = read(fd, buf2, 1024); \t\tif (ret <= 0) break; \t\twrite(1, buf2, ret); \t} \tclose(fd); } $ gcc test.c -o test $ ./test | grep rwx 7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted) [PM: subject line tweaks]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47746", "url": "https://ubuntu.com/security/CVE-2024-47746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: use exclusive lock when FUSE_I_CACHE_IO_MODE is set This may be a typo. The comment has said shared locks are not allowed when this bit is set. If using shared lock, the wait in `fuse_file_cached_io_open` may be forever.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47734", "url": "https://ubuntu.com/security/CVE-2024-47734", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: Fix unnecessary warnings and logs from bond_xdp_get_xmit_slave() syzbot reported a WARNING in bond_xdp_get_xmit_slave. To reproduce this[1], one bond device (bond1) has xdpdrv, which increases bpf_master_redirect_enabled_key. Another bond device (bond0) which is unsupported by XDP but its slave (veth3) has xdpgeneric that returns XDP_TX. This triggers WARN_ON_ONCE() from the xdp_master_redirect(). To reduce unnecessary warnings and improve log management, we need to delete the WARN_ON_ONCE() and add ratelimit to the netdev_err(). [1] Steps to reproduce: # Needs tx_xdp with return XDP_TX; ip l add veth0 type veth peer veth1 ip l add veth3 type veth peer veth4 ip l add bond0 type bond mode 6 # BOND_MODE_ALB, unsupported by XDP ip l add bond1 type bond # BOND_MODE_ROUNDROBIN by default ip l set veth0 master bond1 ip l set bond1 up # Increases bpf_master_redirect_enabled_key ip l set dev bond1 xdpdrv object tx_xdp.o section xdp_tx ip l set veth3 master bond0 ip l set bond0 up ip l set veth4 up # Triggers WARN_ON_ONCE() from the xdp_master_redirect() ip l set veth3 xdpgeneric object tx_xdp.o section xdp_tx", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47684", "url": "https://ubuntu.com/security/CVE-2024-47684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: check skb is non-NULL in tcp_rto_delta_us() We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic kernel that are running ceph and recently hit a null ptr dereference in tcp_rearm_rto(). Initially hitting it from the TLP path, but then later we also saw it getting hit from the RACK case as well. Here are examples of the oops messages we saw in each of those cases: Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020 Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode Jul 26 15:05:02 rx [11061395.792971] #PF: error_code(0x0000) - not-present page Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0 Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI Jul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu Jul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023 Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 <48> 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3 Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246 Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000 Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60 Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8 Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900 Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30 Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000 Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0 Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554 Jul 26 15:05:02 rx [11061395.916786] Call Trace: Jul 26 15:05:02 rx [11061395.919488] Jul 26 15:05:02 rx [11061395.921765] ? show_regs.cold+0x1a/0x1f Jul 26 15:05:02 rx [11061395.925859] ? __die+0x90/0xd9 Jul 26 15:05:02 rx [11061395.929169] ? no_context+0x196/0x380 Jul 26 15:05:02 rx [11061395.933088] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0 Jul 26 15:05:02 rx [11061395.938216] ? ip6_sublist_rcv_finish+0x3d/0x50 Jul 26 15:05:02 rx [11061395.943000] ? __bad_area_nosemaphore+0x50/0x1a0 Jul 26 15:05:02 rx [11061395.947873] ? bad_area_nosemaphore+0x16/0x20 Jul 26 15:05:02 rx [11061395.952486] ? do_user_addr_fault+0x267/0x450 Jul 26 15:05:02 rx [11061395.957104] ? ipv6_list_rcv+0x112/0x140 Jul 26 15:05:02 rx [11061395.961279] ? __do_page_fault+0x58/0x90 Jul 26 15:05:02 rx [11061395.965458] ? do_page_fault+0x2c/0xe0 Jul 26 15:05:02 rx [11061395.969465] ? page_fault+0x34/0x40 Jul 26 15:05:02 rx [11061395.973217] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.977313] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.981408] tcp_send_loss_probe+0x10b/0x220 Jul 26 15:05:02 rx [11061395.985937] tcp_write_timer_handler+0x1b4/0x240 Jul 26 15:05:02 rx [11061395.990809] tcp_write_timer+0x9e/0xe0 Jul 26 15:05:02 rx [11061395.994814] ? tcp_write_timer_handler+0x240/0x240 Jul 26 15:05:02 rx [11061395.999866] call_timer_fn+0x32/0x130 Jul 26 15:05:02 rx [11061396.003782] __run_timers.part.0+0x180/0x280 Jul 26 15:05:02 rx [11061396.008309] ? recalibrate_cpu_khz+0x10/0x10 Jul 26 15:05:02 rx [11061396.012841] ? native_x2apic_icr_write+0x30/0x30 Jul 26 15:05:02 rx [11061396.017718] ? lapic_next_even ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47747", "url": "https://ubuntu.com/security/CVE-2024-47747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race Condition In the ether3_probe function, a timer is initialized with a callback function ether3_ledoff, bound to &prev(dev)->timer. Once the timer is started, there is a risk of a race condition if the module or device is removed, triggering the ether3_remove function to perform cleanup. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | ether3_ledoff ether3_remove | free_netdev(dev); | put_devic | kfree(dev); | | ether3_outw(priv(dev)->regs.config2 |= CFG2_CTRLO, REG_CONFIG2); | // use dev Fix it by ensuring that the timer is canceled before proceeding with the cleanup in ether3_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47685", "url": "https://ubuntu.com/security/CVE-2024-47685", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put() syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending garbage on the four reserved tcp bits (th->res1) Use skb_put_zero() to clear the whole TCP header, as done in nf_reject_ip_tcphdr_put() BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5661 [inline] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775 process_backlog+0x4ad/0xa50 net/core/dev.c:6108 __napi_poll+0xe7/0x980 net/core/dev.c:6772 napi_poll net/core/dev.c:6841 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963 handle_softirqs+0x1ce/0x800 kernel/softirq.c:554 __do_softirq+0x14/0x1a kernel/softirq.c:588 do_softirq+0x9a/0x100 kernel/softirq.c:455 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline] __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450 dev_queue_xmit include/linux/netdevice.h:3105 [inline] neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366 inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135 __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143 tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333 __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679 inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750 __sys_connect_file net/socket.c:2061 [inline] __sys_connect+0x606/0x690 net/socket.c:2078 __do_sys_connect net/socket.c:2088 [inline] __se_sys_connect net/socket.c:2085 [inline] __x64_sys_connect+0x91/0xe0 net/socket.c:2085 x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43 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 Uninit was stored to memory at: nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47686", "url": "https://ubuntu.com/security/CVE-2024-47686", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ep93xx: clock: Fix off by one in ep93xx_div_recalc_rate() The psc->div[] array has psc->num_div elements. These values come from when we call clk_hw_register_div(). It's adc_divisors and ARRAY_SIZE(adc_divisors)) and so on. So this condition needs to be >= instead of > to prevent an out of bounds read.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47748", "url": "https://ubuntu.com/security/CVE-2024-47748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost_vdpa: assign irq bypass producer token correctly We used to call irq_bypass_unregister_producer() in vhost_vdpa_setup_vq_irq() which is problematic as we don't know if the token pointer is still valid or not. Actually, we use the eventfd_ctx as the token so the life cycle of the token should be bound to the VHOST_SET_VRING_CALL instead of vhost_vdpa_setup_vq_irq() which could be called by set_status(). Fixing this by setting up irq bypass producer's token when handling VHOST_SET_VRING_CALL and un-registering the producer before calling vhost_vring_ioctl() to prevent a possible use after free as eventfd could have been released in vhost_vring_ioctl(). And such registering and unregistering will only be done if DRIVER_OK is set.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47687", "url": "https://ubuntu.com/security/CVE-2024-47687", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa/mlx5: Fix invalid mr resource destroy Certain error paths from mlx5_vdpa_dev_add() can end up releasing mr resources which never got initialized in the first place. This patch adds the missing check in mlx5_vdpa_destroy_mr_resources() to block releasing non-initialized mr resources. Reference trace: mlx5_core 0000:08:00.2: mlx5_vdpa_dev_add:3274:(pid 2700) warning: No mac address provisioned? BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 140216067 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 8 PID: 2700 Comm: vdpa Kdump: loaded Not tainted 5.14.0-496.el9.x86_64 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:vhost_iotlb_del_range+0xf/0xe0 [vhost_iotlb] Code: [...] RSP: 0018:ff1c823ac23077f0 EFLAGS: 00010246 RAX: ffffffffc1a21a60 RBX: ffffffff899567a0 RCX: 0000000000000000 RDX: ffffffffffffffff RSI: 0000000000000000 RDI: 0000000000000000 RBP: ff1bda1f7c21e800 R08: 0000000000000000 R09: ff1c823ac2307670 R10: ff1c823ac2307668 R11: ffffffff8a9e7b68 R12: 0000000000000000 R13: 0000000000000000 R14: ff1bda1f43e341a0 R15: 00000000ffffffea FS: 00007f56eba7c740(0000) GS:ff1bda269f800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000104d90001 CR4: 0000000000771ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? mlx5_vdpa_free+0x3d/0x150 [mlx5_vdpa] ? __die_body.cold+0x8/0xd ? page_fault_oops+0x134/0x170 ? __irq_work_queue_local+0x2b/0xc0 ? irq_work_queue+0x2c/0x50 ? exc_page_fault+0x62/0x150 ? asm_exc_page_fault+0x22/0x30 ? __pfx_mlx5_vdpa_free+0x10/0x10 [mlx5_vdpa] ? vhost_iotlb_del_range+0xf/0xe0 [vhost_iotlb] mlx5_vdpa_free+0x3d/0x150 [mlx5_vdpa] vdpa_release_dev+0x1e/0x50 [vdpa] device_release+0x31/0x90 kobject_cleanup+0x37/0x130 mlx5_vdpa_dev_add+0x2d2/0x7a0 [mlx5_vdpa] vdpa_nl_cmd_dev_add_set_doit+0x277/0x4c0 [vdpa] genl_family_rcv_msg_doit+0xd9/0x130 genl_family_rcv_msg+0x14d/0x220 ? __pfx_vdpa_nl_cmd_dev_add_set_doit+0x10/0x10 [vdpa] ? _copy_to_user+0x1a/0x30 ? move_addr_to_user+0x4b/0xe0 genl_rcv_msg+0x47/0xa0 ? __import_iovec+0x46/0x150 ? __pfx_genl_rcv_msg+0x10/0x10 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x245/0x370 netlink_sendmsg+0x206/0x440 __sys_sendto+0x1dc/0x1f0 ? do_read_fault+0x10c/0x1d0 ? do_pte_missing+0x10d/0x190 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x5c/0xf0 ? __count_memcg_events+0x4f/0xb0 ? mm_account_fault+0x6c/0x100 ? handle_mm_fault+0x116/0x270 ? do_user_addr_fault+0x1d6/0x6a0 ? do_syscall_64+0x6b/0xf0 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 entry_SYSCALL_64_after_hwframe+0x78/0x80", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47688", "url": "https://ubuntu.com/security/CVE-2024-47688", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: driver core: Fix a potential null-ptr-deref in module_add_driver() Inject fault while probing of-fpga-region, if kasprintf() fails in module_add_driver(), the second sysfs_remove_link() in exit path will cause null-ptr-deref as below because kernfs_name_hash() will call strlen() with NULL driver_name. Fix it by releasing resources based on the exit path sequence. \t KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] \t Mem abort info: \t ESR = 0x0000000096000005 \t EC = 0x25: DABT (current EL), IL = 32 bits \t SET = 0, FnV = 0 \t EA = 0, S1PTW = 0 \t FSC = 0x05: level 1 translation fault \t Data abort info: \t ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 \t CM = 0, WnR = 0, TnD = 0, TagAccess = 0 \t GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 \t [dfffffc000000000] address between user and kernel address ranges \t Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP \t Dumping ftrace buffer: \t (ftrace buffer empty) \t Modules linked in: of_fpga_region(+) fpga_region fpga_bridge cfg80211 rfkill 8021q garp mrp stp llc ipv6 [last unloaded: of_fpga_region] \t CPU: 2 UID: 0 PID: 2036 Comm: modprobe Not tainted 6.11.0-rc2-g6a0e38264012 #295 \t Hardware name: linux,dummy-virt (DT) \t pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) \t pc : strlen+0x24/0xb0 \t lr : kernfs_name_hash+0x1c/0xc4 \t sp : ffffffc081f97380 \t x29: ffffffc081f97380 x28: ffffffc081f97b90 x27: ffffff80c821c2a0 \t x26: ffffffedac0be418 x25: 0000000000000000 x24: ffffff80c09d2000 \t x23: 0000000000000000 x22: 0000000000000000 x21: 0000000000000000 \t x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000001840 \t x17: 0000000000000000 x16: 0000000000000000 x15: 1ffffff8103f2e42 \t x14: 00000000f1f1f1f1 x13: 0000000000000004 x12: ffffffb01812d61d \t x11: 1ffffff01812d61c x10: ffffffb01812d61c x9 : dfffffc000000000 \t x8 : 0000004fe7ed29e4 x7 : ffffff80c096b0e7 x6 : 0000000000000001 \t x5 : ffffff80c096b0e0 x4 : 1ffffffdb990efa2 x3 : 0000000000000000 \t x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000000 \t Call trace: \t strlen+0x24/0xb0 \t kernfs_name_hash+0x1c/0xc4 \t kernfs_find_ns+0x118/0x2e8 \t kernfs_remove_by_name_ns+0x80/0x100 \t sysfs_remove_link+0x74/0xa8 \t module_add_driver+0x278/0x394 \t bus_add_driver+0x1f0/0x43c \t driver_register+0xf4/0x3c0 \t __platform_driver_register+0x60/0x88 \t of_fpga_region_init+0x20/0x1000 [of_fpga_region] \t do_one_initcall+0x110/0x788 \t do_init_module+0x1dc/0x5c8 \t load_module+0x3c38/0x4cac \t init_module_from_file+0xd4/0x128 \t idempotent_init_module+0x2cc/0x528 \t __arm64_sys_finit_module+0xac/0x100 \t invoke_syscall+0x6c/0x258 \t el0_svc_common.constprop.0+0x160/0x22c \t do_el0_svc+0x44/0x5c \t el0_svc+0x48/0xb8 \t el0t_64_sync_handler+0x13c/0x158 \t el0t_64_sync+0x190/0x194 \t Code: f2fbffe1 a90157f4 12000802 aa0003f5 (38e16861) \t ---[ end trace 0000000000000000 ]--- \t Kernel panic - not syncing: Oops: Fatal exception", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47689", "url": "https://ubuntu.com/security/CVE-2024-47689", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to don't set SB_RDONLY in f2fs_handle_critical_error() syzbot reports a f2fs bug as below: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 58 at kernel/rcu/sync.c:177 rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177 CPU: 1 UID: 0 PID: 58 Comm: kworker/1:2 Not tainted 6.10.0-syzkaller-12562-g1722389b0d86 #0 Workqueue: events destroy_super_work RIP: 0010:rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177 Call Trace: percpu_free_rwsem+0x41/0x80 kernel/locking/percpu-rwsem.c:42 destroy_super_work+0xec/0x130 fs/super.c:282 process_one_work kernel/workqueue.c:3231 [inline] process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 worker_thread+0x86d/0xd40 kernel/workqueue.c:3390 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 As Christian Brauner pointed out [1]: the root cause is f2fs sets SB_RDONLY flag in internal function, rather than setting the flag covered w/ sb->s_umount semaphore via remount procedure, then below race condition causes this bug: - freeze_super() - sb_wait_write(sb, SB_FREEZE_WRITE) - sb_wait_write(sb, SB_FREEZE_PAGEFAULT) - sb_wait_write(sb, SB_FREEZE_FS) \t\t\t\t\t- f2fs_handle_critical_error \t\t\t\t\t - sb->s_flags |= SB_RDONLY - thaw_super - thaw_super_locked - sb_rdonly() is true, so it skips sb_freeze_unlock(sb, SB_FREEZE_FS) - deactivate_locked_super Since f2fs has almost the same logic as ext4 [2] when handling critical error in filesystem if it mounts w/ errors=remount-ro option: - set CP_ERROR_FLAG flag which indicates filesystem is stopped - record errors to superblock - set SB_RDONLY falg Once we set CP_ERROR_FLAG flag, all writable interfaces can detect the flag and stop any further updates on filesystem. So, it is safe to not set SB_RDONLY flag, let's remove the logic and keep in line w/ ext4 [3]. [1] https://lore.kernel.org/all/20240729-himbeeren-funknetz-96e62f9c7aee@brauner [2] https://lore.kernel.org/all/20240729132721.hxih6ehigadqf7wx@quack3 [3] https://lore.kernel.org/linux-ext4/20240805201241.27286-1-jack@suse.cz", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47690", "url": "https://ubuntu.com/security/CVE-2024-47690", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: get rid of online repaire on corrupted directory syzbot reports a f2fs bug as below: kernel BUG at fs/f2fs/inode.c:896! RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Call Trace: evict+0x532/0x950 fs/inode.c:704 dispose_list fs/inode.c:747 [inline] evict_inodes+0x5f9/0x690 fs/inode.c:797 generic_shutdown_super+0x9d/0x2d0 fs/super.c:627 kill_block_super+0x44/0x90 fs/super.c:1696 kill_f2fs_super+0x344/0x690 fs/f2fs/super.c:4898 deactivate_locked_super+0xc4/0x130 fs/super.c:473 cleanup_mnt+0x41f/0x4b0 fs/namespace.c:1373 task_work_run+0x24f/0x310 kernel/task_work.c:228 ptrace_notify+0x2d2/0x380 kernel/signal.c:2402 ptrace_report_syscall include/linux/ptrace.h:415 [inline] ptrace_report_syscall_exit include/linux/ptrace.h:477 [inline] syscall_exit_work+0xc6/0x190 kernel/entry/common.c:173 syscall_exit_to_user_mode_prepare kernel/entry/common.c:200 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:205 [inline] syscall_exit_to_user_mode+0x279/0x370 kernel/entry/common.c:218 do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Online repaire on corrupted directory in f2fs_lookup() can generate dirty data/meta while racing w/ readonly remount, it may leave dirty inode after filesystem becomes readonly, however, checkpoint() will skips flushing dirty inode in a state of readonly mode, result in above panic. Let's get rid of online repaire in f2fs_lookup(), and leave the work to fsck.f2fs.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47691", "url": "https://ubuntu.com/security/CVE-2024-47691", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread() syzbot reports a f2fs bug as below: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_report+0xe8/0x550 mm/kasan/report.c:491 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 instrument_atomic_read_write include/linux/instrumented.h:96 [inline] atomic_fetch_add_relaxed include/linux/atomic/atomic-instrumented.h:252 [inline] __refcount_add include/linux/refcount.h:184 [inline] __refcount_inc include/linux/refcount.h:241 [inline] refcount_inc include/linux/refcount.h:258 [inline] get_task_struct include/linux/sched/task.h:118 [inline] kthread_stop+0xca/0x630 kernel/kthread.c:704 f2fs_stop_gc_thread+0x65/0xb0 fs/f2fs/gc.c:210 f2fs_do_shutdown+0x192/0x540 fs/f2fs/file.c:2283 f2fs_ioc_shutdown fs/f2fs/file.c:2325 [inline] __f2fs_ioctl+0x443a/0xbe60 fs/f2fs/file.c:4325 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f The root cause is below race condition, it may cause use-after-free issue in sbi->gc_th pointer. - remount - f2fs_remount - f2fs_stop_gc_thread - kfree(gc_th) \t\t\t\t- f2fs_ioc_shutdown \t\t\t\t - f2fs_do_shutdown \t\t\t\t - f2fs_stop_gc_thread \t\t\t\t - kthread_stop(gc_th->f2fs_gc_task) : sbi->gc_thread = NULL; We will call f2fs_do_shutdown() in two paths: - for f2fs_ioc_shutdown() path, we should grab sb->s_umount semaphore for fixing. - for f2fs_shutdown() path, it's safe since caller has already grabbed sb->s_umount semaphore.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47692", "url": "https://ubuntu.com/security/CVE-2024-47692", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: return -EINVAL when namelen is 0 When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may result in namelen being 0, which will cause memdup_user() to return ZERO_SIZE_PTR. When we access the name.data that has been assigned the value of ZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is triggered. [ T1205] ================================================================== [ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260 [ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205 [ T1205] [ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406 [ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ T1205] Call Trace: [ T1205] dump_stack+0x9a/0xd0 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] __kasan_report.cold+0x34/0x84 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] kasan_report+0x3a/0x50 [ T1205] nfs4_client_to_reclaim+0xe9/0x260 [ T1205] ? nfsd4_release_lockowner+0x410/0x410 [ T1205] cld_pipe_downcall+0x5ca/0x760 [ T1205] ? nfsd4_cld_tracking_exit+0x1d0/0x1d0 [ T1205] ? down_write_killable_nested+0x170/0x170 [ T1205] ? avc_policy_seqno+0x28/0x40 [ T1205] ? selinux_file_permission+0x1b4/0x1e0 [ T1205] rpc_pipe_write+0x84/0xb0 [ T1205] vfs_write+0x143/0x520 [ T1205] ksys_write+0xc9/0x170 [ T1205] ? __ia32_sys_read+0x50/0x50 [ T1205] ? ktime_get_coarse_real_ts64+0xfe/0x110 [ T1205] ? ktime_get_coarse_real_ts64+0xa2/0x110 [ T1205] do_syscall_64+0x33/0x40 [ T1205] entry_SYSCALL_64_after_hwframe+0x67/0xd1 [ T1205] RIP: 0033:0x7fdbdb761bc7 [ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 514 [ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7 [ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008 [ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001 [ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b [ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000 [ T1205] ================================================================== Fix it by checking namelen.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47737", "url": "https://ubuntu.com/security/CVE-2024-47737", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: call cache_put if xdr_reserve_space returns NULL If not enough buffer space available, but idmap_lookup has triggered lookup_fn which calls cache_get and returns successfully. Then we missed to call cache_put here which pairs with cache_get. Reviwed-by: Jeff Layton ", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2023-52917", "url": "https://ubuntu.com/security/CVE-2023-52917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir() The debugfs_create_dir() function returns error pointers. It never returns NULL. So use IS_ERR() to check it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47749", "url": "https://ubuntu.com/security/CVE-2024-47749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Added NULL check for lookup_atid The lookup_atid() function can return NULL if the ATID is invalid or does not exist in the identifier table, which could lead to dereferencing a null pointer without a check in the `act_establish()` and `act_open_rpl()` functions. Add a NULL check to prevent null pointer dereferencing. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47735", "url": "https://ubuntu.com/security/CVE-2024-47735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled Fix missuse of spin_lock_irq()/spin_unlock_irq() when spin_lock_irqsave()/spin_lock_irqrestore() was hold. This was discovered through the lock debugging, and the corresponding log is as follows: raw_local_irq_restore() called with IRQs enabled WARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40 ... Call trace: warn_bogus_irq_restore+0x30/0x40 _raw_spin_unlock_irqrestore+0x84/0xc8 add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2] hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2] hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2] create_qp+0x138/0x258 ib_create_qp_kernel+0x50/0xe8 create_mad_qp+0xa8/0x128 ib_mad_port_open+0x218/0x448 ib_mad_init_device+0x70/0x1f8 add_client_context+0xfc/0x220 enable_device_and_get+0xd0/0x140 ib_register_device.part.0+0xf4/0x1c8 ib_register_device+0x34/0x50 hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2] hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2] __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2] hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47750", "url": "https://ubuntu.com/security/CVE-2024-47750", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix Use-After-Free of rsv_qp on HIP08 Currently rsv_qp is freed before ib_unregister_device() is called on HIP08. During the time interval, users can still dereg MR and rsv_qp will be used in this process, leading to a UAF. Move the release of rsv_qp after calling ib_unregister_device() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47751", "url": "https://ubuntu.com/security/CVE-2024-47751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: kirin: Fix buffer overflow in kirin_pcie_parse_port() Within kirin_pcie_parse_port(), the pcie->num_slots is compared to pcie->gpio_id_reset size (MAX_PCI_SLOTS) which is correct and would lead to an overflow. Thus, fix condition to pcie->num_slots + 1 >= MAX_PCI_SLOTS and move pcie->num_slots increment below the if-statement to avoid out-of-bounds array access. Found by Linux Verification Center (linuxtesting.org) with SVACE. [kwilczynski: commit log]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47693", "url": "https://ubuntu.com/security/CVE-2024-47693", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/core: Fix ib_cache_setup_one error flow cleanup When ib_cache_update return an error, we exit ib_cache_setup_one instantly with no proper cleanup, even though before this we had already successfully done gid_table_setup_one, that results in the kernel WARN below. Do proper cleanup using gid_table_cleanup_one before returning the err in order to fix the issue. WARNING: CPU: 4 PID: 922 at drivers/infiniband/core/cache.c:806 gid_table_release_one+0x181/0x1a0 Modules linked in: CPU: 4 UID: 0 PID: 922 Comm: c_repro Not tainted 6.11.0-rc1+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:gid_table_release_one+0x181/0x1a0 Code: 44 8b 38 75 0c e8 2f cb 34 ff 4d 8b b5 28 05 00 00 e8 23 cb 34 ff 44 89 f9 89 da 4c 89 f6 48 c7 c7 d0 58 14 83 e8 4f de 21 ff <0f> 0b 4c 8b 75 30 e9 54 ff ff ff 48 8 3 c4 10 5b 5d 41 5c 41 5d 41 RSP: 0018:ffffc90002b835b0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c8527 RDX: 0000000000000000 RSI: ffffffff811c8534 RDI: 0000000000000001 RBP: ffff8881011b3d00 R08: ffff88810b3abe00 R09: 205d303839303631 R10: 666572207972746e R11: 72746e6520444947 R12: 0000000000000001 R13: ffff888106390000 R14: ffff8881011f2110 R15: 0000000000000001 FS: 00007fecc3b70800(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000340 CR3: 000000010435a001 CR4: 00000000003706b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? show_regs+0x94/0xa0 ? __warn+0x9e/0x1c0 ? gid_table_release_one+0x181/0x1a0 ? report_bug+0x1f9/0x340 ? gid_table_release_one+0x181/0x1a0 ? handle_bug+0xa2/0x110 ? exc_invalid_op+0x31/0xa0 ? asm_exc_invalid_op+0x16/0x20 ? __warn_printk+0xc7/0x180 ? __warn_printk+0xd4/0x180 ? gid_table_release_one+0x181/0x1a0 ib_device_release+0x71/0xe0 ? __pfx_ib_device_release+0x10/0x10 device_release+0x44/0xd0 kobject_put+0x135/0x3d0 put_device+0x20/0x30 rxe_net_add+0x7d/0xa0 rxe_newlink+0xd7/0x190 nldev_newlink+0x1b0/0x2a0 ? __pfx_nldev_newlink+0x10/0x10 rdma_nl_rcv_msg+0x1ad/0x2e0 rdma_nl_rcv_skb.constprop.0+0x176/0x210 netlink_unicast+0x2de/0x400 netlink_sendmsg+0x306/0x660 __sock_sendmsg+0x110/0x120 ____sys_sendmsg+0x30e/0x390 ___sys_sendmsg+0x9b/0xf0 ? kstrtouint+0x6e/0xa0 ? kstrtouint_from_user+0x7c/0xb0 ? get_pid_task+0xb0/0xd0 ? proc_fail_nth_write+0x5b/0x140 ? __fget_light+0x9a/0x200 ? preempt_count_add+0x47/0xa0 __sys_sendmsg+0x61/0xd0 do_syscall_64+0x50/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47694", "url": "https://ubuntu.com/security/CVE-2024-47694", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mlx5: Fix UMR pd cleanup on error flow of driver init The cited commit moves the pd allocation from function mlx5r_umr_resource_cleanup() to a new function mlx5r_umr_cleanup(). So the fix in commit [1] is broken. In error flow, will hit panic [2]. Fix it by checking pd pointer to avoid panic if it is NULL; [1] RDMA/mlx5: Fix UMR cleanup on error flow of driver init [2] [ 347.567063] infiniband mlx5_0: Couldn't register device with driver model [ 347.591382] BUG: kernel NULL pointer dereference, address: 0000000000000020 [ 347.593438] #PF: supervisor read access in kernel mode [ 347.595176] #PF: error_code(0x0000) - not-present page [ 347.596962] PGD 0 P4D 0 [ 347.601361] RIP: 0010:ib_dealloc_pd_user+0x12/0xc0 [ib_core] [ 347.604171] RSP: 0018:ffff888106293b10 EFLAGS: 00010282 [ 347.604834] RAX: 0000000000000000 RBX: 000000000000000e RCX: 0000000000000000 [ 347.605672] RDX: ffff888106293ad0 RSI: 0000000000000000 RDI: 0000000000000000 [ 347.606529] RBP: 0000000000000000 R08: ffff888106293ae0 R09: ffff888106293ae0 [ 347.607379] R10: 0000000000000a06 R11: 0000000000000000 R12: 0000000000000000 [ 347.608224] R13: ffffffffa0704dc0 R14: 0000000000000001 R15: 0000000000000001 [ 347.609067] FS: 00007fdc720cd9c0(0000) GS:ffff88852c880000(0000) knlGS:0000000000000000 [ 347.610094] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 347.610727] CR2: 0000000000000020 CR3: 0000000103012003 CR4: 0000000000370eb0 [ 347.611421] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 347.612113] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 347.612804] Call Trace: [ 347.613130] [ 347.613417] ? __die+0x20/0x60 [ 347.613793] ? page_fault_oops+0x150/0x3e0 [ 347.614243] ? free_msg+0x68/0x80 [mlx5_core] [ 347.614840] ? cmd_exec+0x48f/0x11d0 [mlx5_core] [ 347.615359] ? exc_page_fault+0x74/0x130 [ 347.615808] ? asm_exc_page_fault+0x22/0x30 [ 347.616273] ? ib_dealloc_pd_user+0x12/0xc0 [ib_core] [ 347.616801] mlx5r_umr_cleanup+0x23/0x90 [mlx5_ib] [ 347.617365] mlx5_ib_stage_pre_ib_reg_umr_cleanup+0x36/0x40 [mlx5_ib] [ 347.618025] __mlx5_ib_add+0x96/0xd0 [mlx5_ib] [ 347.618539] mlx5r_probe+0xe9/0x310 [mlx5_ib] [ 347.619032] ? kernfs_add_one+0x107/0x150 [ 347.619478] ? __mlx5_ib_add+0xd0/0xd0 [mlx5_ib] [ 347.619984] auxiliary_bus_probe+0x3e/0x90 [ 347.620448] really_probe+0xc5/0x3a0 [ 347.620857] __driver_probe_device+0x80/0x160 [ 347.621325] driver_probe_device+0x1e/0x90 [ 347.621770] __driver_attach+0xec/0x1c0 [ 347.622213] ? __device_attach_driver+0x100/0x100 [ 347.622724] bus_for_each_dev+0x71/0xc0 [ 347.623151] bus_add_driver+0xed/0x240 [ 347.623570] driver_register+0x58/0x100 [ 347.623998] __auxiliary_driver_register+0x6a/0xc0 [ 347.624499] ? driver_register+0xae/0x100 [ 347.624940] ? 0xffffffffa0893000 [ 347.625329] mlx5_ib_init+0x16a/0x1e0 [mlx5_ib] [ 347.625845] do_one_initcall+0x4a/0x2a0 [ 347.626273] ? gcov_event+0x2e2/0x3a0 [ 347.626706] do_init_module+0x8a/0x260 [ 347.627126] init_module_from_file+0x8b/0xd0 [ 347.627596] __x64_sys_finit_module+0x1ca/0x2f0 [ 347.628089] do_syscall_64+0x4c/0x100", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47695", "url": "https://ubuntu.com/security/CVE-2024-47695", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds In the function init_conns(), after the create_con() and create_cm() for loop if something fails. In the cleanup for loop after the destroy tag, we access out of bound memory because cid is set to clt_path->s.con_num. This commits resets the cid to clt_path->s.con_num - 1, to stay in bounds in the cleanup loop later.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47752", "url": "https://ubuntu.com/security/CVE-2024-47752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix H264 stateless decoder smatch warning Fix a smatch static checker warning on vdec_h264_req_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47753", "url": "https://ubuntu.com/security/CVE-2024-47753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix VP8 stateless decoder smatch warning Fix a smatch static checker warning on vdec_vp8_req_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47754", "url": "https://ubuntu.com/security/CVE-2024-47754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix H264 multi stateless decoder smatch warning Fix a smatch static checker warning on vdec_h264_req_multi_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47696", "url": "https://ubuntu.com/security/CVE-2024-47696", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency In the commit aee2424246f9 (\"RDMA/iwcm: Fix a use-after-free related to destroying CM IDs\"), the function flush_workqueue is invoked to flush the work queue iwcm_wq. But at that time, the work queue iwcm_wq was created via the function alloc_ordered_workqueue without the flag WQ_MEM_RECLAIM. Because the current process is trying to flush the whole iwcm_wq, if iwcm_wq doesn't have the flag WQ_MEM_RECLAIM, verify that the current process is not reclaiming memory or running on a workqueue which doesn't have the flag WQ_MEM_RECLAIM as that can break forward-progress guarantee leading to a deadlock. The call trace is as below: [ 125.350876][ T1430] Call Trace: [ 125.356281][ T1430] [ 125.361285][ T1430] ? __warn (kernel/panic.c:693) [ 125.367640][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.375689][ T1430] ? report_bug (lib/bug.c:180 lib/bug.c:219) [ 125.382505][ T1430] ? handle_bug (arch/x86/kernel/traps.c:239) [ 125.388987][ T1430] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) [ 125.395831][ T1430] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621) [ 125.403125][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.410984][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.418764][ T1430] __flush_workqueue (kernel/workqueue.c:3970) [ 125.426021][ T1430] ? __pfx___might_resched (kernel/sched/core.c:10151) [ 125.433431][ T1430] ? destroy_cm_id (drivers/infiniband/core/iwcm.c:375) iw_cm [ 125.441209][ T1430] ? __pfx___flush_workqueue (kernel/workqueue.c:3910) [ 125.473900][ T1430] ? _raw_spin_lock_irqsave (arch/x86/include/asm/atomic.h:107 include/linux/atomic/atomic-arch-fallback.h:2170 include/linux/atomic/atomic-instrumented.h:1302 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162) [ 125.473909][ T1430] ? __pfx__raw_spin_lock_irqsave (kernel/locking/spinlock.c:161) [ 125.482537][ T1430] _destroy_id (drivers/infiniband/core/cma.c:2044) rdma_cm [ 125.495072][ T1430] nvme_rdma_free_queue (drivers/nvme/host/rdma.c:656 drivers/nvme/host/rdma.c:650) nvme_rdma [ 125.505827][ T1430] nvme_rdma_reset_ctrl_work (drivers/nvme/host/rdma.c:2180) nvme_rdma [ 125.505831][ T1430] process_one_work (kernel/workqueue.c:3231) [ 125.515122][ T1430] worker_thread (kernel/workqueue.c:3306 kernel/workqueue.c:3393) [ 125.515127][ T1430] ? __pfx_worker_thread (kernel/workqueue.c:3339) [ 125.531837][ T1430] kthread (kernel/kthread.c:389) [ 125.539864][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.550628][ T1430] ret_from_fork (arch/x86/kernel/process.c:147) [ 125.558840][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.558844][ T1430] ret_from_fork_asm (arch/x86/entry/entry_64.S:257) [ 125.566487][ T1430] [ 125.566488][ T1430] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47755", "url": "https://ubuntu.com/security/CVE-2024-47755", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47756", "url": "https://ubuntu.com/security/CVE-2024-47756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: keystone: Fix if-statement expression in ks_pcie_quirk() This code accidentally uses && where || was intended. It potentially results in a NULL dereference. Thus, fix the if-statement expression to use the correct condition. [kwilczynski: commit log]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47697", "url": "https://ubuntu.com/security/CVE-2024-47697", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error Ensure index in rtl2830_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47698", "url": "https://ubuntu.com/security/CVE-2024-47698", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error Ensure index in rtl2832_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue. [hverkuil: added fixes tag, rtl2830_pid_filter -> rtl2832_pid_filter in logmsg]", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47728", "url": "https://ubuntu.com/security/CVE-2024-47728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error For all non-tracing helpers which formerly had ARG_PTR_TO_{LONG,INT} as input arguments, zero the value for the case of an error as otherwise it could leak memory. For tracing, it is not needed given CAP_PERFMON can already read all kernel memory anyway hence bpf_get_func_arg() and bpf_get_func_ret() is skipped in here. Also, the MTU helpers mtu_len pointer value is being written but also read. Technically, the MEM_UNINIT should not be there in order to always force init. Removing MEM_UNINIT needs more verifier rework though: MEM_UNINIT right now implies two things actually: i) write into memory, ii) memory does not have to be initialized. If we lift MEM_UNINIT, it then becomes: i) read into memory, ii) memory must be initialized. This means that for bpf_*_check_mtu() we're readding the issue we're trying to fix, that is, it would then be able to write back into things like .rodata BPF maps. Follow-up work will rework the MEM_UNINIT semantics such that the intent can be better expressed. For now just clear the *mtu_len on error path which can be lifted later again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49861", "url": "https://ubuntu.com/security/CVE-2024-49861", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix helper writes to read-only maps Lonial found an issue that despite user- and BPF-side frozen BPF map (like in case of .rodata), it was still possible to write into it from a BPF program side through specific helpers having ARG_PTR_TO_{LONG,INT} as arguments. In check_func_arg() when the argument is as mentioned, the meta->raw_mode is never set. Later, check_helper_mem_access(), under the case of PTR_TO_MAP_VALUE as register base type, it assumes BPF_READ for the subsequent call to check_map_access_type() and given the BPF map is read-only it succeeds. The helpers really need to be annotated as ARG_PTR_TO_{LONG,INT} | MEM_UNINIT when results are written into them as opposed to read out of them. The latter indicates that it's okay to pass a pointer to uninitialized memory as the memory is written to anyway. However, ARG_PTR_TO_{LONG,INT} is a special case of ARG_PTR_TO_FIXED_SIZE_MEM just with additional alignment requirement. So it is better to just get rid of the ARG_PTR_TO_{LONG,INT} special cases altogether and reuse the fixed size memory types. For this, add MEM_ALIGNED to additionally ensure alignment given these helpers write directly into the args via * = val. The .arg*_size has been initialized reflecting the actual sizeof(*). MEM_ALIGNED can only be used in combination with MEM_FIXED_SIZE annotated argument types, since in !MEM_FIXED_SIZE cases the verifier does not know the buffer size a priori and therefore cannot blindly write * = val.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47757", "url": "https://ubuntu.com/security/CVE-2024-47757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential oob read in nilfs_btree_check_delete() The function nilfs_btree_check_delete(), which checks whether degeneration to direct mapping occurs before deleting a b-tree entry, causes memory access outside the block buffer when retrieving the maximum key if the root node has no entries. This does not usually happen because b-tree mappings with 0 child nodes are never created by mkfs.nilfs2 or nilfs2 itself. However, it can happen if the b-tree root node read from a device is configured that way, so fix this potential issue by adding a check for that case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47699", "url": "https://ubuntu.com/security/CVE-2024-47699", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential null-ptr-deref in nilfs_btree_insert() Patch series \"nilfs2: fix potential issues with empty b-tree nodes\". This series addresses three potential issues with empty b-tree nodes that can occur with corrupted filesystem images, including one recently discovered by syzbot. This patch (of 3): If a b-tree is broken on the device, and the b-tree height is greater than 2 (the level of the root node is greater than 1) even if the number of child nodes of the b-tree root is 0, a NULL pointer dereference occurs in nilfs_btree_prepare_insert(), which is called from nilfs_btree_insert(). This is because, when the number of child nodes of the b-tree root is 0, nilfs_btree_do_lookup() does not set the block buffer head in any of path[x].bp_bh, leaving it as the initial value of NULL, but if the level of the b-tree root node is greater than 1, nilfs_btree_get_nonroot_node(), which accesses the buffer memory of path[x].bp_bh, is called. Fix this issue by adding a check to nilfs_btree_root_broken(), which performs sanity checks when reading the root node from the device, to detect this inconsistency. Thanks to Lizhi Xu for trying to solve the bug and clarifying the cause early on.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47700", "url": "https://ubuntu.com/security/CVE-2024-47700", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: check stripe size compatibility on remount as well We disable stripe size in __ext4_fill_super if it is not a multiple of the cluster ratio however this check is missed when trying to remount. This can leave us with cases where stripe < cluster_ratio after remount:set making EXT4_B2C(sbi->s_stripe) become 0 that can cause some unforeseen bugs like divide by 0. Fix that by adding the check in remount path as well.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47701", "url": "https://ubuntu.com/security/CVE-2024-47701", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid OOB when system.data xattr changes underneath the filesystem When looking up for an entry in an inlined directory, if e_value_offs is changed underneath the filesystem by some change in the block device, it will lead to an out-of-bounds access that KASAN detects as an UAF. EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none. loop0: detected capacity change from 2048 to 2047 ================================================================== BUG: KASAN: use-after-free in ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 Read of size 1 at addr ffff88803e91130f by task syz-executor269/5103 CPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 Not tainted 6.11.0-rc4-syzkaller #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:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 ext4_find_inline_entry+0x4be/0x5e0 fs/ext4/inline.c:1697 __ext4_find_entry+0x2b4/0x1b30 fs/ext4/namei.c:1573 ext4_lookup_entry fs/ext4/namei.c:1727 [inline] ext4_lookup+0x15f/0x750 fs/ext4/namei.c:1795 lookup_one_qstr_excl+0x11f/0x260 fs/namei.c:1633 filename_create+0x297/0x540 fs/namei.c:3980 do_symlinkat+0xf9/0x3a0 fs/namei.c:4587 __do_sys_symlinkat fs/namei.c:4610 [inline] __se_sys_symlinkat fs/namei.c:4607 [inline] __x64_sys_symlinkat+0x95/0xb0 fs/namei.c:4607 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:0x7f3e73ced469 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff4d40c258 EFLAGS: 00000246 ORIG_RAX: 000000000000010a RAX: ffffffffffffffda RBX: 0032656c69662f2e RCX: 00007f3e73ced469 RDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0 RBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290 R10: 0023706f6f6c2f76 R11: 0000000000000246 R12: 00007fff4d40c27c R13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0 Calling ext4_xattr_ibody_find right after reading the inode with ext4_get_inode_loc will lead to a check of the validity of the xattrs, avoiding this problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49850", "url": "https://ubuntu.com/security/CVE-2024-49850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: correctly handle malformed BPF_CORE_TYPE_ID_LOCAL relos In case of malformed relocation record of kind BPF_CORE_TYPE_ID_LOCAL referencing a non-existing BTF type, function bpf_core_calc_relo_insn would cause a null pointer deference. Fix this by adding a proper check upper in call stack, as malformed relocation records could be passed from user space. Simplest reproducer is a program: r0 = 0 exit With a single relocation record: .insn_off = 0, /* patch first instruction */ .type_id = 100500, /* this type id does not exist */ .access_str_off = 6, /* offset of string \"0\" */ .kind = BPF_CORE_TYPE_ID_LOCAL, See the link for original reproducer or next commit for a test case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47702", "url": "https://ubuntu.com/security/CVE-2024-47702", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fail verification for sign-extension of packet data/data_end/data_meta syzbot reported a kernel crash due to commit 1f1e864b6555 (\"bpf: Handle sign-extenstin ctx member accesses\"). The reason is due to sign-extension of 32-bit load for packet data/data_end/data_meta uapi field. The original code looks like: r2 = *(s32 *)(r1 + 76) /* load __sk_buff->data */ r3 = *(u32 *)(r1 + 80) /* load __sk_buff->data_end */ r0 = r2 r0 += 8 if r3 > r0 goto +1 ... Note that __sk_buff->data load has 32-bit sign extension. After verification and convert_ctx_accesses(), the final asm code looks like: r2 = *(u64 *)(r1 +208) r2 = (s32)r2 r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 ... Note that 'r2 = (s32)r2' may make the kernel __sk_buff->data address invalid which may cause runtime failure. Currently, in C code, typically we have void *data = (void *)(long)skb->data; void *data_end = (void *)(long)skb->data_end; ... and it will generate r2 = *(u64 *)(r1 +208) r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 If we allow sign-extension, void *data = (void *)(long)(int)skb->data; void *data_end = (void *)(long)skb->data_end; ... the generated code looks like r2 = *(u64 *)(r1 +208) r2 <<= 32 r2 s>>= 32 r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 and this will cause verification failure since \"r2 <<= 32\" is not allowed as \"r2\" is a packet pointer. To fix this issue for case r2 = *(s32 *)(r1 + 76) /* load __sk_buff->data */ this patch added additional checking in is_valid_access() callback function for packet data/data_end/data_meta access. If those accesses are with sign-extenstion, the verification will fail. [1] https://lore.kernel.org/bpf/000000000000c90eee061d236d37@google.com/", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47703", "url": "https://ubuntu.com/security/CVE-2024-47703", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, lsm: Add check for BPF LSM return value A bpf prog returning a positive number attached to file_alloc_security hook makes kernel panic. This happens because file system can not filter out the positive number returned by the LSM prog using IS_ERR, and misinterprets this positive number as a file pointer. Given that hook file_alloc_security never returned positive number before the introduction of BPF LSM, and other BPF LSM hooks may encounter similar issues, this patch adds LSM return value check in verifier, to ensure no unexpected value is returned.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49851", "url": "https://ubuntu.com/security/CVE-2024-49851", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: Clean up TPM space after command failure tpm_dev_transmit prepares the TPM space before attempting command transmission. However if the command fails no rollback of this preparation is done. This can result in transient handles being leaked if the device is subsequently closed with no further commands performed. Fix this by flushing the space in the event of command transmission failure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47723", "url": "https://ubuntu.com/security/CVE-2024-47723", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: fix out-of-bounds in dbNextAG() and diAlloc() In dbNextAG() , there is no check for the case where bmp->db_numag is greater or same than MAXAG due to a polluted image, which causes an out-of-bounds. Therefore, a bounds check should be added in dbMount(). And in dbNextAG(), a check for the case where agpref is greater than bmp->db_numag should be added, so an out-of-bounds exception should be prevented. Additionally, a check for the case where agno is greater or same than MAXAG should be added in diAlloc() to prevent out-of-bounds.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49852", "url": "https://ubuntu.com/security/CVE-2024-49852", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: elx: libefc: Fix potential use after free in efc_nport_vport_del() The kref_put() function will call nport->release if the refcount drops to zero. The nport->release release function is _efc_nport_free() which frees \"nport\". But then we dereference \"nport\" on the next line which is a use after free. Re-order these lines to avoid the use after free.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47720", "url": "https://ubuntu.com/security/CVE-2024-47720", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for set_output_gamma in dcn30_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn30_set_output_transfer_func function. Previously, set_output_gamma was being checked for nullity at line 386, but then it was being dereferenced without any nullity check at line 401. This could potentially lead to a null pointer dereference error if set_output_gamma is indeed null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a nullity check for set_output_gamma before the call to set_output_gamma at line 401. If set_output_gamma is null, we log an error message and do not call the function. This fix prevents a potential null pointer dereference error. drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:401 dcn30_set_output_transfer_func() error: we previously assumed 'mpc->funcs->set_output_gamma' could be null (see line 386) drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c 373 bool dcn30_set_output_transfer_func(struct dc *dc, 374 struct pipe_ctx *pipe_ctx, 375 const struct dc_stream_state *stream) 376 { 377 int mpcc_id = pipe_ctx->plane_res.hubp->inst; 378 struct mpc *mpc = pipe_ctx->stream_res.opp->ctx->dc->res_pool->mpc; 379 const struct pwl_params *params = NULL; 380 bool ret = false; 381 382 /* program OGAM or 3DLUT only for the top pipe*/ 383 if (pipe_ctx->top_pipe == NULL) { 384 /*program rmu shaper and 3dlut in MPC*/ 385 ret = dcn30_set_mpc_shaper_3dlut(pipe_ctx, stream); 386 if (ret == false && mpc->funcs->set_output_gamma) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If this is NULL 387 if (stream->out_transfer_func.type == TF_TYPE_HWPWL) 388 params = &stream->out_transfer_func.pwl; 389 else if (pipe_ctx->stream->out_transfer_func.type == 390 TF_TYPE_DISTRIBUTED_POINTS && 391 cm3_helper_translate_curve_to_hw_format( 392 &stream->out_transfer_func, 393 &mpc->blender_params, false)) 394 params = &mpc->blender_params; 395 /* there are no ROM LUTs in OUTGAM */ 396 if (stream->out_transfer_func.type == TF_TYPE_PREDEFINED) 397 BREAK_TO_DEBUGGER(); 398 } 399 } 400 --> 401 mpc->funcs->set_output_gamma(mpc, mpcc_id, params); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Then it will crash 402 return ret; 403 }", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47704", "url": "https://ubuntu.com/security/CVE-2024-47704", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check link_res->hpo_dp_link_enc before using it [WHAT & HOW] Functions dp_enable_link_phy and dp_disable_link_phy can pass link_res without initializing hpo_dp_link_enc and it is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49853", "url": "https://ubuntu.com/security/CVE-2024-49853", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix double free in OPTEE transport Channels can be shared between protocols, avoid freeing the same channel descriptors twice when unloading the stack.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47705", "url": "https://ubuntu.com/security/CVE-2024-47705", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix potential invalid pointer dereference in blk_add_partition The blk_add_partition() function initially used a single if-condition (IS_ERR(part)) to check for errors when adding a partition. This was modified to handle the specific case of -ENXIO separately, allowing the function to proceed without logging the error in this case. However, this change unintentionally left a path where md_autodetect_dev() could be called without confirming that part is a valid pointer. This commit separates the error handling logic by splitting the initial if-condition, improving code readability and handling specific error scenarios explicitly. The function now distinguishes the general error case from -ENXIO without altering the existing behavior of md_autodetect_dev() calls.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47736", "url": "https://ubuntu.com/security/CVE-2024-47736", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: handle overlapped pclusters out of crafted images properly syzbot reported a task hang issue due to a deadlock case where it is waiting for the folio lock of a cached folio that will be used for cache I/Os. After looking into the crafted fuzzed image, I found it's formed with several overlapped big pclusters as below: Ext: logical offset | length : physical offset | length 0: 0.. 16384 | 16384 : 151552.. 167936 | 16384 1: 16384.. 32768 | 16384 : 155648.. 172032 | 16384 2: 32768.. 49152 | 16384 : 537223168.. 537239552 | 16384 ... Here, extent 0/1 are physically overlapped although it's entirely _impossible_ for normal filesystem images generated by mkfs. First, managed folios containing compressed data will be marked as up-to-date and then unlocked immediately (unlike in-place folios) when compressed I/Os are complete. If physical blocks are not submitted in the incremental order, there should be separate BIOs to avoid dependency issues. However, the current code mis-arranges z_erofs_fill_bio_vec() and BIO submission which causes unexpected BIO waits. Second, managed folios will be connected to their own pclusters for efficient inter-queries. However, this is somewhat hard to implement easily if overlapped big pclusters exist. Again, these only appear in fuzzed images so let's simply fall back to temporary short-lived pages for correctness. Additionally, it justifies that referenced managed folios cannot be truncated for now and reverts part of commit 2080ca1ed3e4 (\"erofs: tidy up `struct z_erofs_bvec`\") for simplicity although it shouldn't be any difference.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47706", "url": "https://ubuntu.com/security/CVE-2024-47706", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block, bfq: fix possible UAF for bfqq->bic with merge chain 1) initial state, three tasks: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t\t | ? | ?\t\t | ? \t\t | | | |\t\t | | \t\t V | V |\t\t V | \t\t bfqq1 bfqq2\t\t bfqq3 process ref:\t 1\t\t 1\t\t 1 2) bfqq1 merged to bfqq2: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t\t | |\t\t | ? \t\t \\--------------\\|\t\t | | \t\t V\t\t V | \t\t bfqq1--------->bfqq2\t\t bfqq3 process ref:\t 0\t\t 2\t\t 1 3) bfqq2 merged to bfqq3: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t here -> ? |\t\t | \t\t \\--------------\\ \\-------------\\| \t\t V\t\t V \t\t bfqq1--------->bfqq2---------->bfqq3 process ref:\t 0\t\t 1\t\t 3 In this case, IO from Process 1 will get bfqq2 from BIC1 first, and then get bfqq3 through merge chain, and finially handle IO by bfqq3. Howerver, current code will think bfqq2 is owned by BIC1, like initial state, and set bfqq2->bic to BIC1. bfq_insert_request -> by Process 1 bfqq = bfq_init_rq(rq) bfqq = bfq_get_bfqq_handle_split bfqq = bic_to_bfqq -> get bfqq2 from BIC1 bfqq->ref++ rq->elv.priv[0] = bic rq->elv.priv[1] = bfqq if (bfqq_process_refs(bfqq) == 1) bfqq->bic = bic -> record BIC1 to bfqq2 __bfq_insert_request new_bfqq = bfq_setup_cooperator -> get bfqq3 from bfqq2->new_bfqq bfqq_request_freed(bfqq) new_bfqq->ref++ rq->elv.priv[1] = new_bfqq -> handle IO by bfqq3 Fix the problem by checking bfqq is from merge chain fist. And this might fix a following problem reported by our syzkaller(unreproducible): ================================================================== BUG: KASAN: slab-use-after-free in bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] BUG: KASAN: slab-use-after-free in bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] BUG: KASAN: slab-use-after-free in bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 Write of size 1 at addr ffff888123839eb8 by task kworker/0:1H/18595 CPU: 0 PID: 18595 Comm: kworker/0:1H Tainted: G L 6.6.0-07439-gba2303cacfda #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Workqueue: kblockd blk_mq_requeue_work Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [inline] print_report+0x10d/0x610 mm/kasan/report.c:475 kasan_report+0x8e/0xc0 mm/kasan/report.c:588 bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 bfq_get_bfqq_handle_split+0x169/0x5d0 block/bfq-iosched.c:6757 bfq_init_rq block/bfq-iosched.c:6876 [inline] bfq_insert_request block/bfq-iosched.c:6254 [inline] bfq_insert_requests+0x1112/0x5cf0 block/bfq-iosched.c:6304 blk_mq_insert_request+0x290/0x8d0 block/blk-mq.c:2593 blk_mq_requeue_work+0x6bc/0xa70 block/blk-mq.c:1502 process_one_work kernel/workqueue.c:2627 [inline] process_scheduled_works+0x432/0x13f0 kernel/workqueue.c:2700 worker_thread+0x6f2/0x1160 kernel/workqueue.c:2781 kthread+0x33c/0x440 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:305 Allocated by task 20776: kasan_save_stack+0x20/0x40 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 __kasan_slab_alloc+0x87/0x90 mm/kasan/common.c:328 kasan_slab_alloc include/linux/kasan.h:188 [inline] slab_post_alloc_hook mm/slab.h:763 [inline] slab_alloc_node mm/slub.c:3458 [inline] kmem_cache_alloc_node+0x1a4/0x6f0 mm/slub.c:3503 ioc_create_icq block/blk-ioc.c:370 [inline] ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49855", "url": "https://ubuntu.com/security/CVE-2024-49855", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: fix race between timeout and normal completion If request timetout is handled by nbd_requeue_cmd(), normal completion has to be stopped for avoiding to complete this requeued request, other use-after-free can be triggered. Fix the race by clearing NBD_CMD_INFLIGHT in nbd_requeue_cmd(), meantime make sure that cmd->lock is grabbed for clearing the flag and the requeue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47707", "url": "https://ubuntu.com/security/CVE-2024-47707", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev() Blamed commit accidentally removed a check for rt->rt6i_idev being NULL, as spotted by syzbot: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 UID: 0 PID: 10998 Comm: syz-executor Not tainted 6.11.0-rc6-syzkaller-00208-g625403177711 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 RBP: ffffc900047375d0 R08: 0000000000000003 R09: fffff520008e6e8c R10: dffffc0000000000 R11: fffff520008e6e8c R12: 1ffff1100fdf8f18 R13: ffff88807efc7998 R14: 0000000000000000 R15: ffff88807efc7930 FS: 0000000000000000(0000) GS:ffff8880b8900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020002a80 CR3: 0000000022f62000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: addrconf_ifdown+0x15d/0x1bd0 net/ipv6/addrconf.c:3856 addrconf_notify+0x3cb/0x1020 notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93 call_netdevice_notifiers_extack net/core/dev.c:2032 [inline] call_netdevice_notifiers net/core/dev.c:2046 [inline] unregister_netdevice_many_notify+0xd81/0x1c40 net/core/dev.c:11352 unregister_netdevice_many net/core/dev.c:11414 [inline] unregister_netdevice_queue+0x303/0x370 net/core/dev.c:11289 unregister_netdevice include/linux/netdevice.h:3129 [inline] __tun_detach+0x6b9/0x1600 drivers/net/tun.c:685 tun_detach drivers/net/tun.c:701 [inline] tun_chr_close+0x108/0x1b0 drivers/net/tun.c:3510 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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:0x7f1acc77def9 Code: Unable to access opcode bytes at 0x7f1acc77decf. RSP: 002b:00007ffeb26fa738 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1acc77def9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000043 RBP: 00007f1acc7dd508 R08: 00007ffeb26f84d7 R09: 0000000000000003 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 0000000000000003 R14: 00000000ffffffff R15: 00007ffeb26fa8e0 Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 R ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47708", "url": "https://ubuntu.com/security/CVE-2024-47708", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netkit: Assign missing bpf_net_context During the introduction of struct bpf_net_context handling for XDP-redirect, the netkit driver has been missed, which also requires it because NETKIT_REDIRECT invokes skb_do_redirect() which is accessing the per-CPU variables. Otherwise we see the following crash: \tBUG: kernel NULL pointer dereference, address: 0000000000000038 \tbpf_redirect() \tnetkit_xmit() \tdev_hard_start_xmit() Set the bpf_net_context before invoking netkit_xmit() program within the netkit driver.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47709", "url": "https://ubuntu.com/security/CVE-2024-47709", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: Clear bo->bcm_proc_read after remove_proc_entry(). syzbot reported a warning in bcm_release(). [0] The blamed change fixed another warning that is triggered when connect() is issued again for a socket whose connect()ed device has been unregistered. However, if the socket is just close()d without the 2nd connect(), the remaining bo->bcm_proc_read triggers unnecessary remove_proc_entry() in bcm_release(). Let's clear bo->bcm_proc_read after remove_proc_entry() in bcm_notify(). [0] name '4986' WARNING: CPU: 0 PID: 5234 at fs/proc/generic.c:711 remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Modules linked in: CPU: 0 UID: 0 PID: 5234 Comm: syz-executor606 Not tainted 6.11.0-rc5-syzkaller-00178-g5517ae241919 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Code: ff eb 05 e8 cb 1e 5e ff 48 8b 5c 24 10 48 c7 c7 e0 f7 aa 8e e8 2a 38 8e 09 90 48 c7 c7 60 3a 1b 8c 48 89 de e8 da 42 20 ff 90 <0f> 0b 90 90 48 8b 44 24 18 48 c7 44 24 40 0e 36 e0 45 49 c7 04 07 RSP: 0018:ffffc9000345fa20 EFLAGS: 00010246 RAX: 2a2d0aee2eb64600 RBX: ffff888032f1f548 RCX: ffff888029431e00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000345fb08 R08: ffffffff8155b2f2 R09: 1ffff1101710519a R10: dffffc0000000000 R11: ffffed101710519b R12: ffff888011d38640 R13: 0000000000000004 R14: 0000000000000000 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8880b8800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcfb52722f0 CR3: 000000000e734000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: bcm_release+0x250/0x880 net/can/bcm.c:1578 __sock_release net/socket.c:659 [inline] sock_close+0xbc/0x240 net/socket.c:1421 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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:0x7fcfb51ee969 Code: Unable to access opcode bytes at 0x7fcfb51ee93f. RSP: 002b:00007ffce0109ca8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fcfb51ee969 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 00007fcfb526f3b0 R08: ffffffffffffffb8 R09: 0000555500000000 R10: 0000555500000000 R11: 0000000000000246 R12: 00007fcfb526f3b0 R13: 0000000000000000 R14: 00007fcfb5271ee0 R15: 00007fcfb51bf160 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47710", "url": "https://ubuntu.com/security/CVE-2024-47710", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sock_map: Add a cond_resched() in sock_hash_free() Several syzbot soft lockup reports all have in common sock_hash_free() If a map with a large number of buckets is destroyed, we need to yield the cpu when needed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47711", "url": "https://ubuntu.com/security/CVE-2024-47711", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Don't return OOB skb in manage_oob(). syzbot reported use-after-free in unix_stream_recv_urg(). [0] The scenario is 1. send(MSG_OOB) 2. recv(MSG_OOB) -> The consumed OOB remains in recv queue 3. send(MSG_OOB) 4. recv() -> manage_oob() returns the next skb of the consumed OOB -> This is also OOB, but unix_sk(sk)->oob_skb is not cleared 5. recv(MSG_OOB) -> unix_sk(sk)->oob_skb is used but already freed The recent commit 8594d9b85c07 (\"af_unix: Don't call skb_get() for OOB skb.\") uncovered the issue. If the OOB skb is consumed and the next skb is peeked in manage_oob(), we still need to check if the skb is OOB. Let's do so by falling back to the following checks in manage_oob() and add the test case in selftest. Note that we need to add a similar check for SIOCATMARK. [0]: BUG: KASAN: slab-use-after-free in unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959 Read of size 4 at addr ffff8880326abcc4 by task syz-executor178/5235 CPU: 0 UID: 0 PID: 5235 Comm: syz-executor178 Not tainted 6.11.0-rc5-syzkaller-00742-gfbdaffe41adc #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959 unix_stream_recv_urg+0x1df/0x320 net/unix/af_unix.c:2640 unix_stream_read_generic+0x2456/0x2520 net/unix/af_unix.c:2778 unix_stream_recvmsg+0x22b/0x2c0 net/unix/af_unix.c:2996 sock_recvmsg_nosec net/socket.c:1046 [inline] sock_recvmsg+0x22f/0x280 net/socket.c:1068 ____sys_recvmsg+0x1db/0x470 net/socket.c:2816 ___sys_recvmsg net/socket.c:2858 [inline] __sys_recvmsg+0x2f0/0x3e0 net/socket.c:2888 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:0x7f5360d6b4e9 Code: 48 83 c4 28 c3 e8 37 17 00 00 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff29b3a458 EFLAGS: 00000246 ORIG_RAX: 000000000000002f RAX: ffffffffffffffda RBX: 00007fff29b3a638 RCX: 00007f5360d6b4e9 RDX: 0000000000002001 RSI: 0000000020000640 RDI: 0000000000000003 RBP: 00007f5360dde610 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 00007fff29b3a628 R14: 0000000000000001 R15: 0000000000000001 Allocated by task 5235: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:312 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slub.c:3988 [inline] slab_alloc_node mm/slub.c:4037 [inline] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4080 __alloc_skb+0x1c3/0x440 net/core/skbuff.c:667 alloc_skb include/linux/skbuff.h:1320 [inline] alloc_skb_with_frags+0xc3/0x770 net/core/skbuff.c:6528 sock_alloc_send_pskb+0x91a/0xa60 net/core/sock.c:2815 sock_alloc_send_skb include/net/sock.h:1778 [inline] queue_oob+0x108/0x680 net/unix/af_unix.c:2198 unix_stream_sendmsg+0xd24/0xf80 net/unix/af_unix.c:2351 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2680 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 Freed by task 5235: kasan_save_stack mm/kasan/common.c:47 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47712", "url": "https://ubuntu.com/security/CVE-2024-47712", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: fix potential RCU dereference issue in wilc_parse_join_bss_param In the `wilc_parse_join_bss_param` function, the TSF field of the `ies` structure is accessed after the RCU read-side critical section is unlocked. According to RCU usage rules, this is illegal. Reusing this pointer can lead to unpredictable behavior, including accessing memory that has been updated or causing use-after-free issues. This possible bug was identified using a static analysis tool developed by myself, specifically designed to detect RCU-related issues. To address this, the TSF value is now stored in a local variable `ies_tsf` before the RCU lock is released. The `param->tsf_lo` field is then assigned using this local variable, ensuring that the TSF value is safely accessed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47713", "url": "https://ubuntu.com/security/CVE-2024-47713", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop() Since '__dev_queue_xmit()' should be called with interrupts enabled, the following backtrace: ieee80211_do_stop() ... spin_lock_irqsave(&local->queue_stop_reason_lock, flags) ... ieee80211_free_txskb() ieee80211_report_used_skb() ieee80211_report_ack_skb() cfg80211_mgmt_tx_status_ext() nl80211_frame_tx_status() genlmsg_multicast_netns() genlmsg_multicast_netns_filtered() nlmsg_multicast_filtered() \t netlink_broadcast_filtered() \t do_one_broadcast() \t netlink_broadcast_deliver() \t __netlink_sendskb() \t netlink_deliver_tap() \t __netlink_deliver_tap_skb() \t dev_queue_xmit() \t __dev_queue_xmit() ; with IRQS disabled ... spin_unlock_irqrestore(&local->queue_stop_reason_lock, flags) issues the warning (as reported by syzbot reproducer): WARNING: CPU: 2 PID: 5128 at kernel/softirq.c:362 __local_bh_enable_ip+0xc3/0x120 Fix this by implementing a two-phase skb reclamation in 'ieee80211_do_stop()', where actual work is performed outside of a section with interrupts disabled.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47730", "url": "https://ubuntu.com/security/CVE-2024-47730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/qm - inject error before stopping queue The master ooo cannot be completely closed when the accelerator core reports memory error. Therefore, the driver needs to inject the qm error to close the master ooo. Currently, the qm error is injected after stopping queue, memory may be released immediately after stopping queue, causing the device to access the released memory. Therefore, error is injected to close master ooo before stopping queue to ensure that the device does not access the released memory.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49856", "url": "https://ubuntu.com/security/CVE-2024-49856", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/sgx: Fix deadlock in SGX NUMA node search When the current node doesn't have an EPC section configured by firmware and all other EPC sections are used up, CPU can get stuck inside the while loop that looks for an available EPC page from remote nodes indefinitely, leading to a soft lockup. Note how nid_of_current will never be equal to nid in that while loop because nid_of_current is not set in sgx_numa_mask. Also worth mentioning is that it's perfectly fine for the firmware not to setup an EPC section on a node. While setting up an EPC section on each node can enhance performance, it is not a requirement for functionality. Rework the loop to start and end on *a* node that has SGX memory. This avoids the deadlock looking for the current SGX-lacking node to show up in the loop when it never will.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47714", "url": "https://ubuntu.com/security/CVE-2024-47714", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: use hweight16 to get correct tx antenna The chainmask is u16 so using hweight8 cannot get correct tx_ant. Without this patch, the tx_ant of band 2 would be -1 and lead to the following issue: BUG: KASAN: stack-out-of-bounds in mt7996_mcu_add_sta+0x12e0/0x16e0 [mt7996e]", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47715", "url": "https://ubuntu.com/security/CVE-2024-47715", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: fix oops on non-dbdc mt7986 mt7915_band_config() sets band_idx = 1 on the main phy for mt7986 with MT7975_ONE_ADIE or MT7976_ONE_ADIE. Commit 0335c034e726 (\"wifi: mt76: fix race condition related to checking tx queue fill status\") introduced a dereference of the phys array indirectly indexed by band_idx via wcid->phy_idx in mt76_wcid_cleanup(). This caused the following Oops on affected mt7986 devices: Unable to handle kernel read from unreadable memory at virtual address 0000000000000024 Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x00000005 CM = 0, WnR = 0 user pgtable: 4k pages, 39-bit VAs, pgdp=0000000042545000 [0000000000000024] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 Internal error: Oops: 0000000096000005 [#1] SMP Modules linked in: ... mt7915e mt76_connac_lib mt76 mac80211 cfg80211 ... CPU: 2 PID: 1631 Comm: hostapd Not tainted 5.15.150 #0 Hardware name: ZyXEL EX5700 (Telenor) (DT) pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mt76_wcid_cleanup+0x84/0x22c [mt76] lr : mt76_wcid_cleanup+0x64/0x22c [mt76] sp : ffffffc00a803700 x29: ffffffc00a803700 x28: ffffff80008f7300 x27: ffffff80003f3c00 x26: ffffff80000a7880 x25: ffffffc008c26e00 x24: 0000000000000001 x23: ffffffc000a68114 x22: 0000000000000000 x21: ffffff8004172cc8 x20: ffffffc00a803748 x19: ffffff8004152020 x18: 0000000000000000 x17: 00000000000017c0 x16: ffffffc008ef5000 x15: 0000000000000be0 x14: ffffff8004172e28 x13: ffffff8004172e28 x12: 0000000000000000 x11: 0000000000000000 x10: ffffff8004172e30 x9 : ffffff8004172e28 x8 : 0000000000000000 x7 : ffffff8004156020 x6 : 0000000000000000 x5 : 0000000000000031 x4 : 0000000000000000 x3 : 0000000000000001 x2 : 0000000000000000 x1 : ffffff80008f7300 x0 : 0000000000000024 Call trace: mt76_wcid_cleanup+0x84/0x22c [mt76] __mt76_sta_remove+0x70/0xbc [mt76] mt76_sta_state+0x8c/0x1a4 [mt76] mt7915_eeprom_get_power_delta+0x11e4/0x23a0 [mt7915e] drv_sta_state+0x144/0x274 [mac80211] sta_info_move_state+0x1cc/0x2a4 [mac80211] sta_set_sinfo+0xaf8/0xc24 [mac80211] sta_info_destroy_addr_bss+0x4c/0x6c [mac80211] ieee80211_color_change_finish+0x1c08/0x1e70 [mac80211] cfg80211_check_station_change+0x1360/0x4710 [cfg80211] genl_family_rcv_msg_doit+0xb4/0x110 genl_rcv_msg+0xd0/0x1bc netlink_rcv_skb+0x58/0x120 genl_rcv+0x34/0x50 netlink_unicast+0x1f0/0x2ec netlink_sendmsg+0x198/0x3d0 ____sys_sendmsg+0x1b0/0x210 ___sys_sendmsg+0x80/0xf0 __sys_sendmsg+0x44/0xa0 __arm64_sys_sendmsg+0x20/0x30 invoke_syscall.constprop.0+0x4c/0xe0 do_el0_svc+0x40/0xd0 el0_svc+0x14/0x4c el0t_64_sync_handler+0x100/0x110 el0t_64_sync+0x15c/0x160 Code: d2800002 910092c0 52800023 f9800011 (885f7c01) ---[ end trace 7e42dd9a39ed2281 ]--- Fix by using mt76_dev_phy() which will map band_idx to the correct phy for all hardware combinations.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49857", "url": "https://ubuntu.com/security/CVE-2024-49857", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: set the cipher for secured NDP ranging The cipher pointer is not set, but is derefereced trying to set its content, which leads to a NULL pointer dereference. Fix it by pointing to the cipher parameter before dereferencing.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47738", "url": "https://ubuntu.com/security/CVE-2024-47738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: don't use rate mask for offchannel TX either Like the commit ab9177d83c04 (\"wifi: mac80211: don't use rate mask for scanning\"), ignore incorrect settings to avoid no supported rate warning reported by syzbot. The syzbot did bisect and found cause is commit 9df66d5b9f45 (\"cfg80211: fix default HE tx bitrate mask in 2G band\"), which however corrects bitmask of HE MCS and recognizes correctly settings of empty legacy rate plus HE MCS rate instead of returning -EINVAL. As suggestions [1], follow the change of SCAN TX to consider this case of offchannel TX as well. [1] https://lore.kernel.org/linux-wireless/6ab2dc9c3afe753ca6fdcdd1421e7a1f47e87b84.camel@sipsolutions.net/T/#m2ac2a6d2be06a37c9c47a3d8a44b4f647ed4f024", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47731", "url": "https://ubuntu.com/security/CVE-2024-47731", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers/perf: Fix ali_drw_pmu driver interrupt status clearing The alibaba_uncore_pmu driver forgot to clear all interrupt status in the interrupt processing function. After the PMU counter overflow interrupt occurred, an interrupt storm occurred, causing the system to hang. Therefore, clear the correct interrupt status in the interrupt handling function to fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49862", "url": "https://ubuntu.com/security/CVE-2024-49862", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powercap: intel_rapl: Fix off by one in get_rpi() The rp->priv->rpi array is either rpi_msr or rpi_tpmi which have NR_RAPL_PRIMITIVES number of elements. Thus the > needs to be >= to prevent an off by one access.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47716", "url": "https://ubuntu.com/security/CVE-2024-47716", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: 9410/1: vfp: Use asm volatile in fmrx/fmxr macros Floating point instructions in userspace can crash some arm kernels built with clang/LLD 17.0.6: BUG: unsupported FP instruction in kernel mode FPEXC == 0xc0000780 Internal error: Oops - undefined instruction: 0 [#1] ARM CPU: 0 PID: 196 Comm: vfp-reproducer Not tainted 6.10.0 #1 Hardware name: BCM2835 PC is at vfp_support_entry+0xc8/0x2cc LR is at do_undefinstr+0xa8/0x250 pc : [] lr : [] psr: a0000013 sp : dc8d1f68 ip : 60000013 fp : bedea19c r10: ec532b17 r9 : 00000010 r8 : 0044766c r7 : c0000780 r6 : ec532b17 r5 : c1c13800 r4 : dc8d1fb0 r3 : c10072c4 r2 : c0101c88 r1 : ec532b17 r0 : 0044766c Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 00c5387d Table: 0251c008 DAC: 00000051 Register r0 information: non-paged memory Register r1 information: vmalloc memory Register r2 information: non-slab/vmalloc memory Register r3 information: non-slab/vmalloc memory Register r4 information: 2-page vmalloc region Register r5 information: slab kmalloc-cg-2k Register r6 information: vmalloc memory Register r7 information: non-slab/vmalloc memory Register r8 information: non-paged memory Register r9 information: zero-size pointer Register r10 information: vmalloc memory Register r11 information: non-paged memory Register r12 information: non-paged memory Process vfp-reproducer (pid: 196, stack limit = 0x61aaaf8b) Stack: (0xdc8d1f68 to 0xdc8d2000) 1f60: 0000081f b6f69300 0000000f c10073f4 c10072c4 dc8d1fb0 1f80: ec532b17 0c532b17 0044766c b6f9ccd8 00000000 c010a80c 00447670 60000010 1fa0: ffffffff c1c13800 00c5387d c0100f10 b6f68af8 00448fc0 00000000 bedea188 1fc0: bedea314 00000001 00448ebc b6f9d000 00447608 b6f9ccd8 00000000 bedea19c 1fe0: bede9198 bedea188 b6e1061c 0044766c 60000010 ffffffff 00000000 00000000 Call trace: [] (vfp_support_entry) from [] (do_undefinstr+0xa8/0x250) [] (do_undefinstr) from [] (__und_usr+0x70/0x80) Exception stack(0xdc8d1fb0 to 0xdc8d1ff8) 1fa0: b6f68af8 00448fc0 00000000 bedea188 1fc0: bedea314 00000001 00448ebc b6f9d000 00447608 b6f9ccd8 00000000 bedea19c 1fe0: bede9198 bedea188 b6e1061c 0044766c 60000010 ffffffff Code: 0a000061 e3877202 e594003c e3a09010 (eef16a10) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Fatal exception in interrupt ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]--- This is a minimal userspace reproducer on a Raspberry Pi Zero W: #include #include int main(void) { double v = 1.0; printf(\"%fn\", NAN + *(volatile double *)&v); return 0; } Another way to consistently trigger the oops is: calvin@raspberry-pi-zero-w ~$ python -c \"import json\" The bug reproduces only when the kernel is built with DYNAMIC_DEBUG=n, because the pr_debug() calls act as barriers even when not activated. This is the output from the same kernel source built with the same compiler and DYNAMIC_DEBUG=y, where the userspace reproducer works as expected: VFP: bounce: trigger ec532b17 fpexc c0000780 VFP: emulate: INST=0xee377b06 SCR=0x00000000 VFP: bounce: trigger eef1fa10 fpexc c0000780 VFP: emulate: INST=0xeeb40b40 SCR=0x00000000 VFP: raising exceptions 30000000 calvin@raspberry-pi-zero-w ~$ ./vfp-reproducer nan Crudely grepping for vmsr/vmrs instructions in the otherwise nearly idential text for vfp_support_entry() makes the problem obvious: vmlinux.llvm.good [0xc0101cb8] <+48>: vmrs r7, fpexc vmlinux.llvm.good [0xc0101cd8] <+80>: vmsr fpexc, r0 vmlinux.llvm.good [0xc0101d20 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47717", "url": "https://ubuntu.com/security/CVE-2024-47717", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RISC-V: KVM: Don't zero-out PMU snapshot area before freeing data With the latest Linux-6.11-rc3, the below NULL pointer crash is observed when SBI PMU snapshot is enabled for the guest and the guest is forcefully powered-off. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000508 Oops [#1] Modules linked in: kvm CPU: 0 UID: 0 PID: 61 Comm: term-poll Not tainted 6.11.0-rc3-00018-g44d7178dd77a #3 Hardware name: riscv-virtio,qemu (DT) epc : __kvm_write_guest_page+0x94/0xa6 [kvm] ra : __kvm_write_guest_page+0x54/0xa6 [kvm] epc : ffffffff01590e98 ra : ffffffff01590e58 sp : ffff8f80001f39b0 gp : ffffffff81512a60 tp : ffffaf80024872c0 t0 : ffffaf800247e000 t1 : 00000000000007e0 t2 : 0000000000000000 s0 : ffff8f80001f39f0 s1 : 00007fff89ac4000 a0 : ffffffff015dd7e8 a1 : 0000000000000086 a2 : 0000000000000000 a3 : ffffaf8000000000 a4 : ffffaf80024882c0 a5 : 0000000000000000 a6 : ffffaf800328d780 a7 : 00000000000001cc s2 : ffffaf800197bd00 s3 : 00000000000828c4 s4 : ffffaf800248c000 s5 : ffffaf800247d000 s6 : 0000000000001000 s7 : 0000000000001000 s8 : 0000000000000000 s9 : 00007fff861fd500 s10: 0000000000000001 s11: 0000000000800000 t3 : 00000000000004d3 t4 : 00000000000004d3 t5 : ffffffff814126e0 t6 : ffffffff81412700 status: 0000000200000120 badaddr: 0000000000000508 cause: 000000000000000d [] __kvm_write_guest_page+0x94/0xa6 [kvm] [] kvm_vcpu_write_guest+0x56/0x90 [kvm] [] kvm_pmu_clear_snapshot_area+0x42/0x7e [kvm] [] kvm_riscv_vcpu_pmu_deinit.part.0+0xe0/0x14e [kvm] [] kvm_riscv_vcpu_pmu_deinit+0x1a/0x24 [kvm] [] kvm_arch_vcpu_destroy+0x28/0x4c [kvm] [] kvm_destroy_vcpus+0x5a/0xda [kvm] [] kvm_arch_destroy_vm+0x14/0x28 [kvm] [] kvm_destroy_vm+0x168/0x2a0 [kvm] [] kvm_put_kvm+0x3c/0x58 [kvm] [] kvm_vm_release+0x22/0x2e [kvm] Clearly, the kvm_vcpu_write_guest() function is crashing because it is being called from kvm_pmu_clear_snapshot_area() upon guest tear down. To address the above issue, simplify the kvm_pmu_clear_snapshot_area() to not zero-out PMU snapshot area from kvm_pmu_clear_snapshot_area() because the guest is anyway being tore down. The kvm_pmu_clear_snapshot_area() is also called when guest changes PMU snapshot area of a VCPU but even in this case the previous PMU snaphsot area must not be zeroed-out because the guest might have reclaimed the pervious PMU snapshot area for some other purpose.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47721", "url": "https://ubuntu.com/security/CVE-2024-47721", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: remove unused C2H event ID RTW89_MAC_C2H_FUNC_READ_WOW_CAM to prevent out-of-bounds reading The handler of firmware C2H event RTW89_MAC_C2H_FUNC_READ_WOW_CAM isn't implemented, but driver expects number of handlers is NUM_OF_RTW89_MAC_C2H_FUNC_WOW causing out-of-bounds access. Fix it by removing ID. Addresses-Coverity-ID: 1598775 (\"Out-of-bounds read\")", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47732", "url": "https://ubuntu.com/security/CVE-2024-47732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: iaa - Fix potential use after free bug The free_device_compression_mode(iaa_device, device_mode) function frees \"device_mode\" but it iss passed to iaa_compression_modes[i]->free() a few lines later resulting in a use after free. The good news is that, so far as I can tell, nothing implements the ->free() function and the use after free happens in dead code. But, with this fix, when something does implement it, we'll be ready. :)", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47718", "url": "https://ubuntu.com/security/CVE-2024-47718", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: always wait for both firmware loading attempts In 'rtw_wait_firmware_completion()', always wait for both (regular and wowlan) firmware loading attempts. Otherwise if 'rtw_usb_intf_init()' has failed in 'rtw_usb_probe()', 'rtw_usb_disconnect()' may issue 'ieee80211_free_hw()' when one of 'rtw_load_firmware_cb()' (usually the wowlan one) is still in progress, causing UAF detected by KASAN.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47724", "url": "https://ubuntu.com/security/CVE-2024-47724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: use work queue to process beacon tx event Commit 3a415daa3e8b (\"wifi: ath11k: add P2P IE in beacon template\") from Feb 28, 2024 (linux-next), leads to the following Smatch static checker warning: drivers/net/wireless/ath/ath11k/wmi.c:1742 ath11k_wmi_p2p_go_bcn_ie() warn: sleeping in atomic context The reason is that ath11k_bcn_tx_status_event() will directly call might sleep function ath11k_wmi_cmd_send() during RCU read-side critical sections. The call trace is like: ath11k_bcn_tx_status_event() -> rcu_read_lock() -> ath11k_mac_bcn_tx_event() \t-> ath11k_mac_setup_bcn_tmpl() \t…… \t\t-> ath11k_wmi_bcn_tmpl() \t\t\t-> ath11k_wmi_cmd_send() -> rcu_read_unlock() Commit 886433a98425 (\"ath11k: add support for BSS color change\") added the ath11k_mac_bcn_tx_event(), commit 01e782c89108 (\"ath11k: fix warning of RCU usage for ath11k_mac_get_arvif_by_vdev_id()\") added the RCU lock to avoid warning but also introduced this BUG. Use work queue to avoid directly calling ath11k_mac_bcn_tx_event() during RCU critical sections. No need to worry about the deletion of vif because cancel_work_sync() will drop the work if it doesn't start or block vif deletion until the running work is done. 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": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47671", "url": "https://ubuntu.com/security/CVE-2024-47671", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: usbtmc: prevent kernel-usb-infoleak The syzbot reported a kernel-usb-infoleak in usbtmc_write, we need to clear the structure before filling fields.", "cve_priority": "medium", "cve_public_date": "2024-10-09 15:15:00 UTC" }, { "cve": "CVE-2024-46869", "url": "https://ubuntu.com/security/CVE-2024-46869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btintel_pcie: Allocate memory for driver private data Fix driver not allocating memory for struct btintel_data which is used to store internal data.", "cve_priority": "medium", "cve_public_date": "2024-09-30 16:15:00 UTC" }, { "cve": "CVE-2024-53164", "url": "https://ubuntu.com/security/CVE-2024-53164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: fix ordering of qlen adjustment Changes to sch->q.qlen around qdisc_tree_reduce_backlog() need to happen _before_ a call to said function because otherwise it may fail to notify parent qdiscs when the child is about to become empty.", "cve_priority": "medium", "cve_public_date": "2024-12-27 14:15:00 UTC" }, { "cve": "CVE-2024-53103", "url": "https://ubuntu.com/security/CVE-2024-53103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hv_sock: Initializing vsk->trans to NULL to prevent a dangling pointer When hvs is released, there is a possibility that vsk->trans may not be initialized to NULL, which could lead to a dangling pointer. This issue is resolved by initializing vsk->trans to NULL.", "cve_priority": "high", "cve_public_date": "2024-12-02 08:15:00 UTC" } ], "log": [ "", " * oracular/linux: 6.11.0-17.17 -proposed tracker (LP: #2093643)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/2025.01.13)", "", " * When /dev/vmbus/hv_kvp is not present, disable hv-kvp-daemon (LP: #2091744)", " - [Packaging] disable hv-kvp-daemon if needed", "", " * Backport \"netkit: Add option for scrubbing skb meta data\" to 6.8", " (LP: #2091184)", " - netkit: Add option for scrubbing skb meta data", "", " * KVM: Cache CPUID at KVM.ko module init to reduce latency of VM-Enter and VM-", " Exit (LP: #2093146)", " - KVM: x86: Cache CPUID.0xD XSTATE offsets+sizes during module init", "", " * [SRU] add support of QCA BT 0489:e0fc (LP: #2085406)", " - Bluetooth: btusb: add Foxconn 0xe0fc for Qualcomm WCN785x", "", " * oracular: ubuntu_boot lib/dynamic_queue_limits.c:99! (LP: #2089684)", " - virtio_net: correct netdev_tx_reset_queue() invocation point", " - virtio_ring: add a func argument 'recycle_done' to virtqueue_resize()", " - virtio_net: ensure netdev_tx_reset_queue is called on tx ring resize", "", " * Failed to probe for OVTI02C1: chip id mismatch: 560243!=0 (LP: #2090932)", " - SAUCE: ACPI: scan: Update HID for new platform", "", " * Bluetooth[8086:a876] crash with \"hci0: Failed to read MSFT supported", " features (-110)\" (LP: #2085485)", " - Bluetooth: btintel_pcie: Add recovery mechanism", "", " * Poor bluetooth performance on Lenovo X13s (LP: #2089357)", " - SAUCE: Bluetooth: qca: Support downloading board ID specific NVM for WCN6855", "", " * vfio_pci soft lockup on VM start while using PCIe passthrough (LP: #2089306)", " - SAUCE: Revert \"mm: use rwsem assertion macros for mmap_lock\"", " - SAUCE: Revert \"vfio/pci: Insert full vma on mmap'd MMIO fault\"", " - SAUCE: Revert \"vfio/pci: Use unmap_mapping_range()\"", "", " * Oracular update: v6.11.11 upstream stable release (LP: #2091655)", " - wifi: mac80211: Fix setting txpower with emulate_chanctx", " - wifi: cfg80211: Add wiphy_delayed_work_pending()", " - wifi: mac80211: Convert color collision detection to wiphy work", " - wifi: radiotap: Avoid -Wflex-array-member-not-at-end warnings", " - spi: stm32: fix missing device mode capability in stm32mp25", " - ASoC: codecs: rt5640: Always disable IRQs from rt5640_cancel_work()", " - ASoC: Intel: bytcr_rt5640: Add support for non ACPI instantiated codec", " - ASoC: Intel: bytcr_rt5640: Add DMI quirk for Vexia Edu Atla 10 tablet", " - ASoC: Intel: sst: Support LPE0F28 ACPI HID", " - wifi: iwlwifi: mvm: Use the sync timepoint API in suspend", " - wifi: iwlwifi: mvm: SAR table alignment", " - mac80211: fix user-power when emulating chanctx", " - usb: add support for new USB device ID 0x17EF:0x3098 for the r8152 driver", " - usb: typec: use cleanup facility for 'altmodes_node'", " - selftests/watchdog-test: Fix system accidentally reset after watchdog-test", " - ALSA: hda/realtek: Add subwoofer quirk for Infinix ZERO BOOK 13", " - ASoC: codecs: wcd937x: add missing LO Switch control", " - ASoC: codecs: wcd937x: relax the AUX PDM watchdog", " - x86/amd_nb: Fix compile-testing without CONFIG_AMD_NB", " - bpf: fix filed access without lock", " - net: usb: qmi_wwan: add Quectel RG650V", " - soc: qcom: Add check devm_kasprintf() returned value", " - firmware: arm_scmi: Reject clear channel request on A2P", " - regulator: rk808: Add apply_bit for BUCK3 on RK809", " - platform/x86: dell-smbios-base: Extends support to Alienware products", " - platform/x86: dell-wmi-base: Handle META key Lock/Unlock events", " - platform/x86: ideapad-laptop: add missing Ideapad Pro 5 fn keys", " - ASoC: tas2781: Add new driver version for tas2563 & tas2781 qfn chip", " - tools/lib/thermal: Remove the thermal.h soft link when doing make clean", " - can: j1939: fix error in J1939 documentation.", " - platform/x86: thinkpad_acpi: Fix for ThinkPad's with ECFW showing incorrect", " fan speed", " - ASoC: amd: yc: Support dmic on another model of Lenovo Thinkpad E14 Gen 6", " - ASoC: stm: Prevent potential division by zero in stm32_sai_mclk_round_rate()", " - ASoC: stm: Prevent potential division by zero in stm32_sai_get_clk_div()", " - drm: panel-orientation-quirks: Make Lenovo Yoga Tab 3 X90F DMI match less", " strict", " - proc/softirqs: replace seq_printf with seq_put_decimal_ull_width", " - integrity: Use static_assert() to check struct sizes", " - ASoC: audio-graph-card2: Purge absent supplies for device tree nodes", " - LoongArch: For all possible CPUs setup logical-physical CPU mapping", " - LoongArch: Define a default value for VM_DATA_DEFAULT_FLAGS", " - ASoC: max9768: Fix event generation for playback mute", " - ALSA: usb-audio: Fix Yamaha P-125 Quirk Entry", " - ARM: 9420/1: smp: Fix SMP for xip kernels", " - ARM: 9434/1: cfi: Fix compilation corner case", " - ipmr: Fix access to mfc_cache_list without lock held", " - f2fs: fix fiemap failure issue when page size is 16KB", " - drm/amd/display: Skip Invalid Streams from DSC Policy", " - drm/amd/display: Fix incorrect DSC recompute trigger", " - s390/facilities: Fix warning about shadow of global variable", " - efs: fix the efs new mount api implementation", " - arm64: probes: Disable kprobes/uprobes on MOPS instructions", " - kselftest/arm64: hwcap: fix f8dp2 cpuinfo name", " - kselftest/arm64: mte: fix printf type warnings about __u64", " - kselftest/arm64: mte: fix printf type warnings about longs", " - block/fs: Pass an iocb to generic_atomic_write_valid()", " - fs/block: Check for IOCB_DIRECT in generic_atomic_write_valid()", " - s390/cio: Do not unregister the subchannel based on DNV", " - s390/pageattr: Implement missing kernel_page_present()", " - x86/pvh: Set phys_base when calling xen_prepare_pvh()", " - x86/pvh: Call C code via the kernel virtual mapping", " - brd: defer automatic disk creation until module initialization succeeds", " - ext4: avoid remount errors with 'abort' mount option", " - mips: asm: fix warning when disabling MIPS_FP_SUPPORT", " - arm64: Expose ID_AA64ISAR1_EL1.XS to sanitised feature consumers", " - kselftest/arm64: Fix encoding for SVE B16B16 test", " - nvme-pci: fix freeing of the HMB descriptor table", " - m68k: mvme147: Fix SCSI controller IRQ numbers", " - m68k: mvme147: Reinstate early console", " - arm64: fix .data.rel.ro size assertion when CONFIG_LTO_CLANG", " - acpi/arm64: Adjust error handling procedure in gtdt_parse_timer_block()", " - loop: fix type of block size", " - cachefiles: Fix incorrect length return value in", " cachefiles_ondemand_fd_write_iter()", " - cachefiles: Fix missing pos updates in cachefiles_ondemand_fd_write_iter()", " - cachefiles: Fix NULL pointer dereference in object->file", " - netfs/fscache: Add a memory barrier for FSCACHE_VOLUME_CREATING", " - block: constify the lim argument to queue_limits_max_zone_append_sectors", " - block: properly handle REQ_OP_ZONE_APPEND in __bio_split_to_limits", " - block: take chunk_sectors into account in bio_split_write_zeroes", " - block: fix bio_split_rw_at to take zone_write_granularity into account", " - s390/syscalls: Avoid creation of arch/arch/ directory", " - hfsplus: don't query the device logical block size multiple times", " - ext4: pipeline buffer reads in mext_page_mkuptodate()", " - ext4: remove array of buffer_heads from mext_page_mkuptodate()", " - ext4: fix race in buffer_head read fault injection", " - nvme-pci: reverse request order in nvme_queue_rqs", " - virtio_blk: reverse request order in virtio_queue_rqs", " - crypto: mxs-dcp - Fix AES-CBC with hardware-bound keys", " - crypto: caam - Fix the pointer passed to caam_qi_shutdown()", " - crypto: qat - remove check after debugfs_create_dir()", " - crypto: qat/qat_420xx - fix off by one in uof_get_name()", " - crypto: qat/qat_4xxx - fix off by one in uof_get_name()", " - firmware: google: Unregister driver_info on failure", " - EDAC/bluefield: Fix potential integer overflow", " - crypto: qat - remove faulty arbiter config reset", " - thermal: core: Initialize thermal zones before registering them", " - thermal: core: Drop thermal_zone_device_is_enabled()", " - thermal: core: Rearrange PM notification code", " - thermal: core: Represent suspend-related thermal zone flags as bits", " - thermal: core: Mark thermal zones as initializing to start with", " - thermal: core: Fix race between zone registration and system suspend", " - EDAC/fsl_ddr: Fix bad bit shift operations", " - EDAC/skx_common: Differentiate memory error sources", " - EDAC/{skx_common,i10nm}: Fix incorrect far-memory error source indicator", " - crypto: pcrypt - Call crypto layer directly when padata_do_parallel() return", " -EBUSY", " - crypto: cavium - Fix the if condition to exit loop after timeout", " - cpufreq/amd-pstate: Don't update CPPC request in", " amd_pstate_cpu_boost_update()", " - amd-pstate: Set min_perf to nominal_perf for active mode performance gov", " - crypto: hisilicon/qm - disable same error report before resetting", " - EDAC/igen6: Avoid segmentation fault on module unload", " - crypto: qat - Fix missing destroy_workqueue in adf_init_aer()", " - crypto: inside-secure - Fix the return value of safexcel_xcbcmac_cra_init()", " - sched/cpufreq: Ensure sd is rebuilt for EAS check", " - doc: rcu: update printed dynticks counter bits", " - rcu/srcutiny: don't return before reenabling preemption", " - rcu/kvfree: Fix data-race in __mod_timer / kvfree_call_rcu", " - hwmon: (pmbus/core) clear faults after setting smbalert mask", " - hwmon: (nct6775-core) Fix overflows seen when writing limit attributes", " - ACPI: CPPC: Fix _CPC register setting issue", " - crypto: caam - add error check to caam_rsa_set_priv_key_form", " - crypto: bcm - add error check in the ahash_hmac_init function", " - crypto: cavium - Fix an error handling path in cpt_ucode_load_fw()", " - rcuscale: Do a proper cleanup if kfree_scale_init() fails", " - tools/lib/thermal: Make more generic the command encoding function", " - thermal/lib: Fix memory leak on error in thermal_genl_auto()", " - x86/unwind/orc: Fix unwind for newly forked tasks", " - Revert \"scripts/faddr2line: Check only two symbols when calculating symbol", " size\"", " - cleanup: Remove address space of returned pointer", " - time: Partially revert cleanup on msecs_to_jiffies() documentation", " - time: Fix references to _msecs_to_jiffies() handling of values", " - locking/atomic/x86: Use ALT_OUTPUT_SP() for __alternative_atomic64()", " - locking/atomic/x86: Use ALT_OUTPUT_SP() for __arch_{,try_}cmpxchg64_emu()", " - kcsan, seqlock: Support seqcount_latch_t", " - kcsan, seqlock: Fix incorrect assumption in read_seqbegin()", " - clocksource/drivers:sp804: Make user selectable", " - clocksource/drivers/timer-ti-dm: Fix child node refcount handling", " - regulator: qcom-smd: make smd_vreg_rpm static", " - spi: spi-fsl-lpspi: Use IRQF_NO_AUTOEN flag in request_irq()", " - arm64: dts: qcom: qcs6390-rb3gen2: use modem.mbn for modem DSP", " - ARM: dts: renesas: genmai: Fix partition size for QSPI NOR Flash", " - drivers: soc: xilinx: add the missing kfree in xlnx_add_cb_for_suspend()", " - microblaze: Export xmb_manager functions", " - arm64: dts: mediatek: mt8188: Fix wrong clock provider in MFG1 power domain", " - arm64: dts: mediatek: mt8395-genio-1200-evk: Fix dtbs_check error for phy", " - arm64: dts: mt8195: Fix dtbs_check error for mutex node", " - arm64: dts: mt8195: Fix dtbs_check error for infracfg_ao node", " - soc: ti: smartreflex: Use IRQF_NO_AUTOEN flag in request_irq()", " - soc: qcom: geni-se: fix array underflow in geni_se_clk_tbl_get()", " - arm64: dts: qcom: sm6350: Fix GPU frequencies missing on some speedbins", " - arm64: dts: qcom: sda660-ifc6560: fix l10a voltage ranges", " - ARM: dts: microchip: sam9x60: Add missing property atmel,usart-mode", " - mmc: mmc_spi: drop buggy snprintf()", " - scripts/kernel-doc: Do not track section counter across processed files", " - arm64: dts: qcom: x1e80100-slim7x: Drop orientation-switch from USB SS[0-1]", " QMP PHYs", " - arm64: dts: qcom: x1e80100-vivobook-s15: Drop orientation-switch from USB", " SS[0-1] QMP PHYs", " - openrisc: Implement fixmap to fix earlycon", " - efi/libstub: fix efi_parse_options() ignoring the default command line", " - tpm: fix signed/unsigned bug when checking event logs", " - media: i2c: vgxy61: Fix an error handling path in vgxy61_detect()", " - media: i2c: ds90ub960: Fix missing return check on ub960_rxport_read call", " - arm64: dts: mt8183: krane: Fix the address of eeprom at i2c4", " - arm64: dts: mt8183: kukui: Fix the address of eeprom at i2c4", " - arm64: dts: qcom: x1e80100: Resize GIC Redistributor register region", " - kernel-doc: allow object-like macros in ReST output", " - arm64: dts: ti: k3-am62x-phyboard-lyra: Drop unnecessary McASP AFIFOs", " - arm64: dts: mediatek: mt8173-elm-hana: Add vdd-supply to second source", " trackpad", " - arm64: dts: mediatek: mt8188: Fix USB3 PHY port default status", " - arm64: dts: mediatek: mt8195-cherry: Use correct audio codec DAI", " - Revert \"cgroup: Fix memory leak caused by missing cgroup_bpf_offline\"", " - cgroup/bpf: only cgroup v2 can be attached by bpf programs", " - regulator: rk808: Restrict DVS GPIOs to the RK808 variant only", " - power: sequencing: make the QCom PMU pwrseq driver depend on CONFIG_OF", " - [Config] updateconfigs for POWER_SEQUENCING_QCOM_WCN", " - arm64: dts: rockchip: Remove 'enable-active-low' from two boards", " - arm64: dts: mt8183: fennel: add i2c2's i2c-scl-internal-delay-ns", " - arm64: dts: mt8183: burnet: add i2c2's i2c-scl-internal-delay-ns", " - arm64: dts: mt8183: cozmo: add i2c2's i2c-scl-internal-delay-ns", " - arm64: dts: mt8183: Damu: add i2c2's i2c-scl-internal-delay-ns", " - pwm: imx27: Workaround of the pwm output bug when decrease the duty cycle", " - ARM: dts: cubieboard4: Fix DCDC5 regulator constraints", " - arm64: dts: ti: k3-j7200: Fix register map for main domain pmx", " - arm64: dts: ti: k3-j7200: Fix clock ids for MCSPI instances", " - arm64: dts: ti: k3-j721e: Fix clock IDs for MCSPI instances", " - arm64: dts: ti: k3-j721s2: Fix clock IDs for MCSPI instances", " - watchdog: Add HAS_IOPORT dependency for SBC8360 and SBC7240", " - arm64: dts: qcom: x1e80100: Update C4/C5 residency/exit numbers", " - dt-bindings: cache: qcom,llcc: Fix X1E80100 reg entries", " - of/fdt: add dt_phys arg to early_init_dt_scan and early_init_dt_verify", " - pmdomain: ti-sci: Add missing of_node_put() for args.np", " - spi: tegra210-quad: Avoid shift-out-of-bounds", " - spi: zynqmp-gqspi: Undo runtime PM changes at driver exit time​", " - regmap: irq: Set lockdep class for hierarchical IRQ domains", " - arm64: dts: renesas: hihope: Drop #sound-dai-cells", " - arm64: dts: imx8mn-tqma8mqnl-mba8mx-usbot: fix coexistence of output-low and", " output-high in GPIO", " - arm64: dts: mediatek: Add ADC node on MT6357, MT6358, MT6359 PMICs", " - arm64: dts: mediatek: mt6358: fix dtbs_check error", " - arm64: dts: mediatek: mt8183-kukui-jacuzzi: Fix DP bridge supply names", " - arm64: dts: mediatek: mt8183-kukui-jacuzzi: Add supplies for fixed", " regulators", " - selftests/resctrl: Print accurate buffer size as part of MBM results", " - selftests/resctrl: Fix memory overflow due to unhandled wraparound", " - selftests/resctrl: Protect against array overrun during iMC config parsing", " - firmware: arm_scpi: Check the DVFS OPP count returned by the firmware", " - media: ipu6: Fix DMA and physical address debugging messages for 32-bit", " - media: ipu6: not override the dma_ops of device in driver", " - pwm: Assume a disabled PWM to emit a constant inactive output", " - media: atomisp: Add check for rgby_data memory allocation failure", " - arm64: dts: rockchip: correct analog audio name on Indiedroid Nova", " - HID: hyperv: streamline driver probe to avoid devres issues", " - platform/x86: panasonic-laptop: Return errno correctly in show callback", " - drm/imagination: Convert to use time_before macro", " - drm/imagination: Use pvr_vm_context_get()", " - drm/mm: Mark drm_mm_interval_tree*() functions with __maybe_unused", " - drm/vc4: hvs: Don't write gamma luts on 2711", " - drm/vc4: hdmi: Avoid hang with debug registers when suspended", " - drm/vc4: hvs: Fix dlist debug not resetting the next entry pointer", " - drm/vc4: hvs: Remove incorrect limit from hvs_dlist debugfs function", " - drm/vc4: hvs: Correct logic on stopping an HVS channel", " - wifi: ath9k: add range check for conn_rsp_epid in htc_connect_service()", " - drm/omap: Fix possible NULL dereference", " - drm/omap: Fix locking in omap_gem_new_dmabuf()", " - drm/v3d: Appease lockdep while updating GPU stats", " - wifi: p54: Use IRQF_NO_AUTOEN flag in request_irq()", " - wifi: mwifiex: Use IRQF_NO_AUTOEN flag in request_irq()", " - udmabuf: change folios array from kmalloc to kvmalloc", " - udmabuf: fix vmap_udmabuf error page set", " - [Config] updateconfigs for VMAP_PFN", " - drm/imx/dcss: Use IRQF_NO_AUTOEN flag in request_irq()", " - drm/imx/ipuv3: Use IRQF_NO_AUTOEN flag in request_irq()", " - drm/panel: nt35510: Make new commands optional", " - drm/v3d: Address race-condition in MMU flush", " - drm/v3d: Flush the MMU before we supply more memory to the binner", " - drm/amdgpu: Fix JPEG v4.0.3 register write", " - wifi: ath10k: fix invalid VHT parameters in supported_vht_mcs_rate_nss1", " - wifi: ath10k: fix invalid VHT parameters in supported_vht_mcs_rate_nss2", " - wifi: ath12k: Skip Rx TID cleanup for self peer", " - dt-bindings: vendor-prefixes: Add NeoFidelity, Inc", " - ASoC: fsl_micfil: fix regmap_write_bits usage", " - ASoC: dt-bindings: mt6359: Update generic node name and dmic-mode", " - ASoC: fsl-asoc-card: Add missing handling of {hp,mic}-dt-gpios", " - drm/bridge: anx7625: Drop EDID cache on bridge power off", " - drm/bridge: it6505: Drop EDID cache on bridge power off", " - libbpf: Fix expected_attach_type set handling in program load callback", " - libbpf: Fix output .symtab byte-order during linking", " - dlm: fix swapped args sb_flags vs sb_status", " - wifi: rtl8xxxu: Perform update_beacon_work when beaconing is enabled", " - drm/amd/display: fix a memleak issue when driver is removed", " - wifi: ath12k: fix use-after-free in ath12k_dp_cc_cleanup()", " - wifi: ath12k: fix one more memcpy size error", " - bpf: Fix the xdp_adjust_tail sample prog issue", " - selftests/bpf: netns_new() and netns_free() helpers.", " - selftests/bpf: Fix backtrace printing for selftests crashes", " - wifi: ath11k: Fix CE offset address calculation for WCN6750 in SSR", " - selftests/bpf: add missing header include for htons", " - wifi: cfg80211: check radio iface combination for multi radio per wiphy", " - ice: consistently use q_idx in ice_vc_cfg_qs_msg()", " - drm/vc4: hdmi: Increase audio MAI fifo dreq threshold", " - drm/vc4: Introduce generation number enum", " - drm/vc4: Match drm_dev_enter and exit calls in vc4_hvs_lut_load", " - drm/vc4: Match drm_dev_enter and exit calls in vc4_hvs_atomic_flush", " - drm/vc4: Correct generation check in vc4_hvs_lut_load", " - libbpf: fix sym_is_subprog() logic for weak global subprogs", " - accel/ivpu: Prevent recovery invocation during probe and resume", " - ASoC: rt722-sdca: Remove logically deadcode in rt722-sdca.c", " - libbpf: never interpret subprogs in .text as entry programs", " - netdevsim: copy addresses for both in and out paths", " - drm/bridge: tc358767: Fix link properties discovery", " - selftests/bpf: Fix msg_verify_data in test_sockmap", " - selftests/bpf: Fix txmsg_redir of test_txmsg_pull in test_sockmap", " - wifi: wilc1000: Set MAC after operation mode", " - wifi: mwifiex: Fix memcpy() field-spanning write warning in", " mwifiex_config_scan()", " - drm: fsl-dcu: enable PIXCLK on LS1021A", " - drm: panel: nv3052c: correct spi_device_id for RG35XX panel", " - drm/msm/dpu: on SDM845 move DSPP_3 to LM_5 block", " - drm/msm/dpu: drop LM_3 / LM_4 on SDM845", " - drm/msm/dpu: drop LM_3 / LM_4 on MSM8998", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_common.c", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_ethtool.c", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_flows.c", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in cn10k.c", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dmac_flt.c", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dcbnl.c", " - selftests/bpf: fix test_spin_lock_fail.c's global vars usage", " - libbpf: move global data mmap()'ing into bpf_object__load()", " - drm/panfrost: Remove unused id_mask from struct panfrost_model", " - bpf, arm64: Remove garbage frame for struct_ops trampoline", " - drm/msm/adreno: Use IRQF_NO_AUTOEN flag in request_irq()", " - drm/msm/gpu: Check the status of registration to PM QoS", " - drm/xe/hdcp: Fix gsc structure check in fw check status", " - drm/etnaviv: Request pages from DMA32 zone on addressing_limited", " - drm/etnaviv: hold GPU lock across perfmon sampling", " - drm/amd/display: Increase idle worker HPD detection time", " - drm/amd/display: Reduce HPD Detection Interval for IPS", " - drm/nouveau/gr/gf100: Fix missing unlock in gf100_gr_chan_new()", " - drm: zynqmp_kms: Unplug DRM device before removal", " - drm: xlnx: zynqmp_disp: layer may be null while releasing", " - wifi: wfx: Fix error handling in wfx_core_init()", " - wifi: cw1200: Fix potential NULL dereference", " - drm/msm/dpu: cast crtc_clk calculation to u64 in _dpu_core_perf_calc_clk()", " - bpf, bpftool: Fix incorrect disasm pc", " - bpf: Tighten tail call checks for lingering locks, RCU, preempt_disable", " - drm/vkms: Drop unnecessary call to drm_crtc_cleanup()", " - drm/amdgpu: Fix the memory allocation issue in", " amdgpu_discovery_get_nps_info()", " - bpf: Support __nullable argument suffix for tp_btf", " - selftests/bpf: Add test for __nullable suffix in tp_btf", " - bpf: Mark raw_tp arguments with PTR_MAYBE_NULL", " - drm: use ATOMIC64_INIT() for atomic64_t", " - netfilter: nf_tables: avoid false-positive lockdep splat on rule deletion", " - netfilter: nf_tables: must hold rcu read lock while iterating expression", " type list", " - netfilter: nf_tables: must hold rcu read lock while iterating object type", " list", " - netlink: typographical error in nlmsg_type constants definition", " - wifi: rtw89: coex: check NULL return of kmalloc in btc_fw_set_monreg()", " - drm/panfrost: Add missing OPP table refcnt decremental", " - drm/panthor: introduce job cycle and timestamp accounting", " - drm/panthor: record current and maximum device clock frequencies", " - drm/panthor: Fix OPP refcnt leaks in devfreq initialisation", " - isofs: avoid memory leak in iocharset", " - selftests/bpf: Add txmsg_pass to pull/push/pop in test_sockmap", " - selftests/bpf: Fix SENDPAGE data logic in test_sockmap", " - selftests/bpf: Fix total_bytes in msg_loop_rx in test_sockmap", " - selftests/bpf: Add push/pop checking for msg_verify_data in test_sockmap", " - bpf, sockmap: Several fixes to bpf_msg_push_data", " - bpf, sockmap: Several fixes to bpf_msg_pop_data", " - bpf, sockmap: Fix sk_msg_reset_curr", " - ipv6: release nexthop on device removal", " - selftests: net: really check for bg process completion", " - wifi: cfg80211: Remove the Medium Synchronization Delay validity check", " - wifi: iwlwifi: allow fast resume on ax200", " - wifi: iwlwifi: mvm: tell iwlmei when we finished suspending", " - drm/amdgpu: fix ACA bank count boundary check error", " - drm/amdgpu: Fix map/unmap queue logic", " - drm/amdkfd: Fix wrong usage of INIT_WORK()", " - bpf: Allow return values 0 and 1 for kprobe session", " - bpf: Force uprobe bpf program to always return 0", " - selftests/bpf: skip the timer_lockup test for single-CPU nodes", " - ipv6: Fix soft lockups in fib6_select_path under high next hop churn", " - net: rfkill: gpio: Add check for clk_enable()", " - Revert \"wifi: iwlegacy: do not skip frames with bad FCS\"", " - bpf: Use function pointers count as struct_ops links count", " - bpf: Add kernel symbol for struct_ops trampoline", " - ALSA: usx2y: Use snd_card_free_when_closed() at disconnection", " - ALSA: us122l: Use snd_card_free_when_closed() at disconnection", " - ALSA: caiaq: Use snd_card_free_when_closed() at disconnection", " - ALSA: 6fire: Release resources at card release", " - i2c: dev: Fix memory leak when underlying adapter does not support I2C", " - selftests: netfilter: Fix missing return values in conntrack_dump_flush", " - Bluetooth: btintel_pcie: Add handshake between driver and firmware", " - Bluetooth: btintel: Do no pass vendor events to stack", " - Bluetooth: btmtk: adjust the position to init iso data anchor", " - Bluetooth: btbcm: fix missing of_node_put() in btbcm_get_board_name()", " - Bluetooth: ISO: Use kref to track lifetime of iso_conn", " - Bluetooth: ISO: Do not emit LE PA Create Sync if previous is pending", " - Bluetooth: ISO: Do not emit LE BIG Create Sync if previous is pending", " - Bluetooth: ISO: Send BIG Create Sync via hci_sync", " - Bluetooth: fix use-after-free in device_for_each_child()", " - xsk: Free skb when TX metadata options are invalid", " - erofs: handle NONHEAD !delta[1] lclusters gracefully", " - dlm: fix dlm_recover_members refcount on error", " - eth: fbnic: don't disable the PCI device twice", " - net: txgbe: remove GPIO interrupt controller", " - net: txgbe: fix null pointer to pcs", " - netpoll: Use rcu_access_pointer() in netpoll_poll_lock", " - wireguard: selftests: load nf_conntrack if not present", " - bpf: fix recursive lock when verdict program return SK_PASS", " - unicode: Fix utf8_load() error path", " - cppc_cpufreq: Use desired perf if feedback ctrs are 0 or unchanged", " - RDMA/core: Provide rdma_user_mmap_disassociate() to disassociate mmap pages", " - RDMA/hns: Disassociate mmap pages for all uctx when HW is being reset", " - clk: mediatek: drop two dead config options", " - [Config] drop COMMON_CLK_MT8195_{AUDSYS,MSDC}", " - trace/trace_event_perf: remove duplicate samples on the first tracepoint", " event", " - pinctrl: zynqmp: drop excess struct member description", " - pinctrl: renesas: Select PINCTRL_RZG2L for RZ/V2H(P) SoC", " - clk: qcom: videocc-sm8550: depend on either gcc-sm8550 or gcc-sm8650", " - iommu/s390: Implement blocking domain", " - scsi: hisi_sas: Enable all PHYs that are not disabled by user during", " controller reset", " - powerpc/vdso: Flag VDSO64 entry points as functions", " - mfd: tps65010: Use IRQF_NO_AUTOEN flag in request_irq() to fix race", " - mfd: da9052-spi: Change read-mask to write-mask", " - mfd: intel_soc_pmic_bxtwc: Use IRQ domain for USB Type-C device", " - mfd: intel_soc_pmic_bxtwc: Use IRQ domain for TMU device", " - mfd: intel_soc_pmic_bxtwc: Use IRQ domain for PMIC devices", " - irqdomain: Simplify simple and legacy domain creation", " - irqdomain: Cleanup domain name allocation", " - irqdomain: Allow giving name suffix for domain", " - regmap: Allow setting IRQ domain name suffix", " - mfd: intel_soc_pmic_bxtwc: Fix IRQ domain names duplication", " - cpufreq: loongson2: Unregister platform_driver on failure", " - powerpc/fadump: Refactor and prepare fadump_cma_init for late init", " - powerpc/fadump: Move fadump_cma_init to setup_arch() after initmem_init()", " - mtd: hyperbus: rpc-if: Add missing MODULE_DEVICE_TABLE", " - mtd: rawnand: atmel: Fix possible memory leak", " - powerpc/mm/fault: Fix kfence page fault reporting", " - clk: sophgo: avoid integer overflow in sg2042_pll_recalc_rate()", " - mtd: spi-nor: spansion: Use nor->addr_nbytes in octal DTR mode in", " RD_ANY_REG_OP", " - powerpc/pseries: Fix dtl_access_lock to be a rw_semaphore", " - cpufreq: CPPC: Fix possible null-ptr-deref for cpufreq_cpu_get_raw()", " - cpufreq: CPPC: Fix possible null-ptr-deref for cppc_get_cpu_cost()", " - iommu/amd: Remove amd_iommu_domain_update() from page table freeing", " - iommu/amd: Remove the amd_iommu_domain_set_pt_root() and related", " - iommu/amd: Rename struct amd_io_pgtable iopt to pgtbl", " - iommu/amd: Store the nid in io_pgtable_cfg instead of the domain", " - iommu/amd: Narrow the use of struct protection_domain to invalidation", " - iommu/amd/pgtbl_v2: Take protection domain lock before invalidating TLB", " - RDMA/hns: Fix an AEQE overflow error caused by untimely update of eq_db_ci", " - RDMA/hns: Fix flush cqe error when racing with destroy qp", " - RDMA/hns: Modify debugfs name", " - RDMA/hns: Use dev_* printings in hem code instead of ibdev_*", " - RDMA/hns: Fix cpu stuck caused by printings during reset", " - RDMA/rxe: Fix the qp flush warnings in req", " - RDMA/bnxt_re: Check cqe flags to know imm_data vs inv_irkey", " - clk: sunxi-ng: d1: Fix PLL_AUDIO0 preset", " - clk: renesas: rzg2l: Fix FOUTPOSTDIV clk", " - RDMA/rxe: Set queue pair cur_qp_state when being queried", " - RISC-V: KVM: Fix APLIC in_clrip and clripnum write emulation", " - riscv: kvm: Fix out-of-bounds array access", " - clk: imx: lpcg-scu: SW workaround for errata (e10858)", " - clk: imx: fracn-gppll: correct PLL initialization flow", " - clk: imx: fracn-gppll: fix pll power up", " - clk: imx: clk-scu: fix clk enable state save and restore", " - clk: imx: imx8-acm: Fix return value check in", " clk_imx_acm_attach_pm_domains()", " - iommu/vt-d: Fix checks and print in dmar_fault_dump_ptes()", " - iommu/vt-d: Fix checks and print in pgtable_walk()", " - checkpatch: always parse orig_commit in fixes tag", " - mfd: rt5033: Fix missing regmap_del_irq_chip()", " - leds: max5970: Fix unreleased fwnode_handle in probe function", " - leds: ktd2692: Set missing timing properties", " - fs/proc/kcore.c: fix coccinelle reported ERROR instances", " - scsi: target: Fix incorrect function name in pscsi_create_type_disk()", " - scsi: bfa: Fix use-after-free in bfad_im_module_exit()", " - scsi: fusion: Remove unused variable 'rc'", " - scsi: qedf: Fix a possible memory leak in qedf_alloc_and_init_sb()", " - scsi: qedi: Fix a possible memory leak in qedi_alloc_and_init_sb()", " - scsi: sg: Enable runtime power management", " - x86/tdx: Introduce wrappers to read and write TD metadata", " - x86/tdx: Rename tdx_parse_tdinfo() to tdx_setup()", " - x86/tdx: Dynamically disable SEPT violations from causing #VEs", " - powerpc/fadump: allocate memory for additional parameters early", " - fadump: reserve param area if below boot_mem_top", " - RDMA/hns: Fix out-of-order issue of requester when setting FENCE", " - RDMA/hns: Fix NULL pointer derefernce in hns_roce_map_mr_sg()", " - cpufreq: loongson3: Check for error code from devm_mutex_init() call", " - cpufreq: CPPC: Fix wrong return value in cppc_get_cpu_cost()", " - cpufreq: CPPC: Fix wrong return value in cppc_get_cpu_power()", " - kasan: move checks to do_strncpy_from_user", " - kunit: skb: use \"gfp\" variable instead of hardcoding GFP_KERNEL", " - ocfs2: fix uninitialized value in ocfs2_file_read_iter()", " - dax: delete a stale directory pmem", " - KVM: PPC: Book3S HV: Stop using vc->dpdes for nested KVM guests", " - KVM: PPC: Book3S HV: Avoid returning to nested hypervisor on pending", " doorbells", " - powerpc/sstep: make emulate_vsx_load and emulate_vsx_store static", " - RDMA/hns: Fix different dgids mapping to the same dip_idx", " - KVM: PPC: Book3S HV: Fix kmv -> kvm typo", " - powerpc/kexec: Fix return of uninitialized variable", " - fbdev: sh7760fb: Fix a possible memory leak in sh7760fb_alloc_mem()", " - RDMA/mlx5: Move events notifier registration to be after device registration", " - clk: clk-apple-nco: Add NULL check in applnco_probe", " - clk: ralink: mtmips: fix clock plan for Ralink SoC RT3883", " - clk: ralink: mtmips: fix clocks probe order in oldest ralink SoCs", " - clk: en7523: remove REG_PCIE*_{MEM,MEM_MASK} configuration", " - clk: en7523: move clock_register in hw_init callback", " - clk: en7523: introduce chip_scu regmap", " - clk: en7523: fix estimation of fixed rate for EN7581", " - dt-bindings: clock: axi-clkgen: include AXI clk", " - clk: clk-axi-clkgen: make sure to enable the AXI bus clock", " - arm64: dts: qcom: sc8180x: Add a SoC-specific compatible to cpufreq-hw", " - pinctrl: k210: Undef K210_PC_DEFAULT", " - rtla/timerlat: Do not set params->user_workload with -U", " - smb: cached directories can be more than root file handle", " - mailbox: mtk-cmdq: fix wrong use of sizeof in cmdq_get_clocks()", " - mailbox: arm_mhuv2: clean up loop in get_irq_chan_comb()", " - x86: fix off-by-one in access_ok()", " - perf cs-etm: Don't flush when packet_queue fills up", " - gfs2: Rename GLF_VERIFY_EVICT to GLF_VERIFY_DELETE", " - gfs2: Allow immediate GLF_VERIFY_DELETE work", " - gfs2: Fix unlinked inode cleanup", " - perf test: Add test for Intel TPEBS counting mode", " - perf mem: Fix printing PERF_MEM_LVLNUM_{L2_MHB|MSC}", " - PCI: Fix reset_method_store() memory leak", " - perf stat: Close cork_fd when create_perf_stat_counter() failed", " - perf stat: Fix affinity memory leaks on error path", " - perf trace: Keep exited threads for summary", " - perf test attr: Add back missing topdown events", " - f2fs: compress: fix inconsistent update of i_blocks in", " release_compress_blocks and reserve_compress_blocks", " - f2fs: fix null-ptr-deref in f2fs_submit_page_bio()", " - f2fs: fix to account dirty data in __get_secs_required()", " - perf dso: Fix symtab_type for kmod compression", " - perf probe: Fix libdw memory leak", " - perf probe: Correct demangled symbols in C++ program", " - rust: kernel: fix THIS_MODULE header path in ThisModule doc comment", " - rust: macros: fix documentation of the paste! macro", " - PCI: cpqphp: Use PCI_POSSIBLE_ERROR() to check config reads", " - PCI: cpqphp: Fix PCIBIOS_* return value confusion", " - rust: block: fix formatting of `kernel::block::mq::request` module", " - perf disasm: Use disasm_line__free() to properly free disasm_line", " - virtiofs: use pages instead of pointer for kernel direct IO", " - perf ftrace latency: Fix unit on histogram first entry when using --use-nsec", " - i3c: master: Remove i3c_dev_disable_ibi_locked(olddev) on device hotjoin", " - f2fs: fix the wrong f2fs_bug_on condition in f2fs_do_replace_block", " - f2fs: check curseg->inited before write_sum_page in change_curseg", " - f2fs: Fix not used variable 'index'", " - f2fs: fix to avoid potential deadlock in f2fs_record_stop_reason()", " - f2fs: fix to avoid use GC_AT when setting gc_mode as GC_URGENT_LOW or", " GC_URGENT_MID", " - PCI: qcom-ep: Move controller cleanups to qcom_pcie_perst_deassert()", " - PCI: tegra194: Move controller cleanups to pex_ep_event_pex_rst_deassert()", " - PCI: cadence: Extract link setup sequence from cdns_pcie_host_setup()", " - PCI: cadence: Set cdns_pcie_host_init() global", " - PCI: j721e: Add reset GPIO to struct j721e_pcie", " - PCI: j721e: Use T_PERST_CLK_US macro", " - PCI: j721e: Add suspend and resume support", " - PCI: j721e: Deassert PERST# after a delay of PCIE_T_PVPERL_MS milliseconds", " - perf build: Add missing cflags when building with custom libtraceevent", " - f2fs: fix race in concurrent f2fs_stop_gc_thread", " - f2fs: fix to map blocks correctly for direct write", " - f2fs: fix to avoid forcing direct write to use buffered IO on inline_data", " inode", " - perf trace: avoid garbage when not printing a trace event's arguments", " - m68k: mcfgpio: Fix incorrect register offset for CONFIG_M5441x", " - m68k: coldfire/device.c: only build FEC when HW macros are defined", " - svcrdma: Address an integer overflow", " - nfsd: drop inode parameter from nfsd4_change_attribute()", " - perf list: Fix topic and pmu_name argument order", " - perf trace: Fix tracing itself, creating feedback loops", " - perf trace: Do not lose last events in a race", " - perf trace: Avoid garbage when not printing a syscall's arguments", " - remoteproc: qcom: pas: Remove subdevs on the error path of adsp_probe()", " - remoteproc: qcom: adsp: Remove subdevs on the error path of adsp_probe()", " - remoteproc: qcom: pas: add minidump_id to SM8350 resources", " - rpmsg: glink: use only lower 16-bits of param2 for CMD_OPEN name length", " - remoteproc: qcom_q6v5_mss: Re-order writes to the IMEM region", " - PCI: endpoint: epf-mhi: Avoid NULL dereference if DT lacks 'mmio'", " - NFSD: Prevent NULL dereference in nfsd4_process_cb_update()", " - NFSD: Cap the number of bytes copied by nfs4_reset_recoverydir()", " - nfsd: release svc_expkey/svc_export with rcu_work", " - svcrdma: fix miss destroy percpu_counter in svc_rdma_proc_init()", " - NFSD: Fix nfsd4_shutdown_copy()", " - f2fs: clean up val{>>,<<}F2FS_BLKSIZE_BITS", " - f2fs: fix to do cast in F2FS_{BLK_TO_BYTES, BTYES_TO_BLK} to avoid overflow", " - hwmon: (tps23861) Fix reporting of negative temperatures", " - hwmon: (aquacomputer_d5next) Fix length of speed_input array", " - phy: airoha: Fix REG_CSR_2L_PLL_CMN_RESERVE0 config in", " airoha_pcie_phy_init_clk_out()", " - phy: airoha: Fix REG_PCIE_PMA_TX_RESET config in", " airoha_pcie_phy_init_csr_2l()", " - phy: airoha: Fix REG_CSR_2L_JCPLL_SDM_HREN config in", " airoha_pcie_phy_init_ssc_jcpll()", " - phy: airoha: Fix REG_CSR_2L_RX{0,1}_REV0 definitions", " - vdpa/mlx5: Fix suboptimal range on iotlb iteration", " - vfio/mlx5: Fix an unwind issue in mlx5vf_add_migration_pages()", " - vfio/mlx5: Fix unwind flows in mlx5vf_pci_save/resume_device_data()", " - selftests/mount_setattr: Fix failures on 64K PAGE_SIZE kernels", " - gpio: zevio: Add missed label initialisation", " - vfio/pci: Properly hide first-in-list PCIe extended capability", " - fs_parser: update mount_api doc to match function signature", " - LoongArch: Fix build failure with GCC 15 (-std=gnu23)", " - LoongArch: BPF: Sign-extend return values", " - power: supply: core: Remove might_sleep() from power_supply_put()", " - power: supply: bq27xxx: Fix registers of bq27426", " - power: supply: rt9471: Fix wrong WDT function regfield declaration", " - power: supply: rt9471: Use IC status regfield to report real charger status", " - net: usb: lan78xx: Fix double free issue with interrupt buffer allocation", " - net: usb: lan78xx: Fix memory leak on device unplug by freeing PHY device", " - tg3: Set coherent DMA mask bits to 31 for BCM57766 chipsets", " - net: usb: lan78xx: Fix refcounting and autosuspend on invalid WoL", " configuration", " - net: microchip: vcap: Add typegroup table terminators in kunit tests", " - netlink: fix false positive warning in extack during dumps", " - exfat: fix file being changed by unaligned direct write", " - s390/iucv: MSG_PEEK causes memory leak in iucv_sock_destruct()", " - net/ipv6: delete temporary address if mngtmpaddr is removed or unmanaged", " - net: mdio-ipq4019: add missing error check", " - marvell: pxa168_eth: fix call balance of pep->clk handling routines", " - net: stmmac: dwmac-socfpga: Set RX watchdog interrupt as broken", " - octeontx2-af: RPM: Fix mismatch in lmac type", " - octeontx2-af: RPM: Fix low network performance", " - octeontx2-af: RPM: fix stale RSFEC counters", " - octeontx2-af: RPM: fix stale FCFEC counters", " - octeontx2-af: Quiesce traffic before NIX block reset", " - spi: atmel-quadspi: Fix register name in verbose logging function", " - net: hsr: fix hsr_init_sk() vs network/transport headers.", " - bnxt_en: Reserve rings after PCIe AER recovery if NIC interface is down", " - bnxt_en: Set backplane link modes correctly for ethtool", " - bnxt_en: Fix receive ring space parameters when XDP is active", " - bnxt_en: Refactor bnxt_ptp_init()", " - bnxt_en: Unregister PTP during PCI shutdown and suspend", " - Bluetooth: MGMT: Fix slab-use-after-free Read in set_powered_sync", " - Bluetooth: MGMT: Fix possible deadlocks", " - llc: Improve setsockopt() handling of malformed user input", " - rxrpc: Improve setsockopt() handling of malformed user input", " - tcp: Fix use-after-free of nreq in reqsk_timer_handler().", " - ip6mr: fix tables suspicious RCU usage", " - ipmr: fix tables suspicious RCU usage", " - iio: light: al3010: Fix an error handling path in al3010_probe()", " - usb: using mutex lock and supporting O_NONBLOCK flag in iowarrior_read()", " - usb: yurex: make waiting on yurex_write interruptible", " - USB: chaoskey: fail open after removal", " - USB: chaoskey: Fix possible deadlock chaoskey_list_lock", " - misc: apds990x: Fix missing pm_runtime_disable()", " - devres: Fix page faults when tracing devres from unloaded modules", " - usb: gadget: uvc: wake pump everytime we update the free list", " - interconnect: qcom: icc-rpmh: probe defer incase of missing QoS clock", " dependency", " - phy: realtek: usb: fix NULL deref in rtk_usb2phy_probe", " - phy: realtek: usb: fix NULL deref in rtk_usb3phy_probe", " - counter: stm32-timer-cnt: Add check for clk_enable()", " - counter: ti-ecap-capture: Add check for clk_enable()", " - bus: mhi: host: Switch trace_mhi_gen_tre fields to native endian", " - usb: typec: fix potential array underflow in ucsi_ccg_sync_control()", " - firmware_loader: Fix possible resource leak in fw_log_firmware_info()", " - ALSA: hda/realtek: Update ALC256 depop procedure", " - drm/radeon: add helper rdev_to_drm(rdev)", " - drm/radeon: change rdev->ddev to rdev_to_drm(rdev)", " - drm/radeon: Fix spurious unplug event on radeon HDMI", " - drm/amd/display: Fix null check for pipe_ctx->plane_state in", " dcn20_program_pipe", " - drm/amd/display: Fix null check for pipe_ctx->plane_state in hwss_setup_dpp", " - ASoC: imx-audmix: Add NULL check in imx_audmix_probe", " - drm/xe/ufence: Wake up waiters after setting ufence->signalled", " - apparmor: fix 'Do simple duplicate message elimination'", " - ALSA: core: Fix possible NULL dereference caused by kunit_kzalloc()", " - ASoC: amd: yc: Fix for enabling DMIC on acp6x via _DSD entry", " - ASoC: mediatek: Check num_codecs is not zero to avoid panic during probe", " - s390/pci: Fix potential double remove of hotplug slot", " - net_sched: sch_fq: don't follow the fast path if Tx is behind now", " - xen: Fix the issue of resource not being properly released in", " xenbus_dev_probe()", " - ALSA: usb-audio: Fix potential out-of-bound accesses for Extigy and Mbox", " devices", " - ALSA: usb-audio: Fix out of bounds reads when finding clock sources", " - usb: ehci-spear: fix call balance of sehci clk handling routines", " - usb: typec: ucsi: glink: fix off-by-one in connector_status", " - dm-cache: fix warnings about duplicate slab caches", " - dm-bufio: fix warnings about duplicate slab caches", " - ASoC: Intel: sst: Fix used of uninitialized ctx to log an error", " - soc: qcom: socinfo: fix revision check in qcom_socinfo_probe()", " - irqdomain: Always associate interrupts for legacy domains", " - ext4: supress data-race warnings in ext4_free_inodes_{count,set}()", " - ext4: fix FS_IOC_GETFSMAP handling", " - jfs: xattr: check invalid xattr size more strictly", " - ASoC: amd: yc: Add a quirk for microfone on Lenovo ThinkPad P14s Gen 5", " 21MES00B00", " - ASoC: codecs: Fix atomicity violation in snd_soc_component_get_drvdata()", " - ASoC: da7213: Populate max_register to regmap_config", " - perf/x86/intel/pt: Fix buffer full but size is 0 case", " - crypto: x86/aegis128 - access 32-bit arguments as 32-bit", " - KVM: x86: switch hugepage recovery thread to vhost_task", " - KVM: x86/mmu: Skip the \"try unsync\" path iff the old SPTE was a leaf SPTE", " - powerpc/pseries: Fix KVM guest detection for disabling hardlockup detector", " - KVM: arm64: vgic-v3: Sanitise guest writes to GICR_INVLPIR", " - KVM: arm64: Ignore PMCNTENSET_EL0 while checking for overflow status", " - KVM: arm64: Don't retire aborted MMIO instruction", " - KVM: arm64: vgic-its: Clear ITE when DISCARD frees an ITE", " - KVM: arm64: Get rid of userspace_irqchip_in_use", " - KVM: arm64: vgic-its: Add a data length check in vgic_its_save_*", " - KVM: arm64: vgic-its: Clear DTE when MAPD unmaps a device", " - Compiler Attributes: disable __counted_by for clang < 19.1.3", " - PCI: Fix use-after-free of slot->bus on hot remove", " - LoongArch: Explicitly specify code model in Makefile", " - clk: clk-loongson2: Fix memory corruption bug in struct", " loongson2_clk_provider", " - clk: clk-loongson2: Fix potential buffer overflow in flexible-array member", " access", " - fsnotify: fix sending inotify event with unexpected filename", " - comedi: Flush partial mappings in error case", " - apparmor: test: Fix memory leak for aa_unpack_strdup()", " - iio: dac: adi-axi-dac: fix wrong register bitfield", " - tty: ldsic: fix tty_ldisc_autoload sysctl's proc_handler", " - locking/lockdep: Avoid creating new name string literals in", " lockdep_set_subclass()", " - tools/nolibc: s390: include std.h", " - pinctrl: qcom: spmi: fix debugfs drive strength", " - dt-bindings: pinctrl: samsung: Fix interrupt constraint for variants with", " fallbacks", " - dt-bindings: iio: dac: ad3552r: fix maximum spi speed", " - exfat: fix uninit-value in __exfat_get_dentry_set", " - exfat: fix out-of-bounds access of directory entries", " - xhci: Fix control transfer error on Etron xHCI host", " - xhci: Combine two if statements for Etron xHCI host", " - xhci: Don't perform Soft Retry for Etron xHCI host", " - xhci: Don't issue Reset Device command to Etron xHCI host", " - Bluetooth: Fix type of len in rfcomm_sock_getsockopt{,_old}()", " - usb: xhci: Limit Stop Endpoint retries", " - usb: xhci: Fix TD invalidation under pending Set TR Dequeue", " - usb: xhci: Avoid queuing redundant Stop Endpoint commands", " - ARM: dts: omap36xx: declare 1GHz OPP as turbo again", " - wifi: ath12k: fix warning when unbinding", " - wifi: rtlwifi: Drastically reduce the attempts to read efuse in case of", " failures", " - wifi: nl80211: fix bounds checker error in nl80211_parse_sched_scan", " - wifi: ath12k: fix crash when unbinding", " - wifi: brcmfmac: release 'root' node in all execution paths", " - Revert \"fs: don't block i_writecount during exec\"", " - Revert \"f2fs: remove unreachable lazytime mount option parsing\"", " - Revert \"usb: gadget: composite: fix OS descriptors w_value logic\"", " - serial: sh-sci: Clean sci_ports[0] after at earlycon exit", " - Revert \"serial: sh-sci: Clean sci_ports[0] after at earlycon exit\"", " - io_uring: fix corner case forgetting to vunmap", " - io_uring: check for overflows in io_pin_pages", " - blk-settings: round down io_opt to physical_block_size", " - gpio: exar: set value when external pull-up or pull-down is present", " - spi: Fix acpi deferred irq probe", " - mtd: spi-nor: core: replace dummy buswidth from addr to data", " - cpufreq: mediatek-hw: Fix wrong return value in mtk_cpufreq_get_cpu_power()", " - cifs: support mounting with alternate password to allow password rotation", " - parisc/ftrace: Fix function graph tracing disablement", " - RISC-V: Scalar unaligned access emulated on hotplug CPUs", " - RISC-V: Check scalar unaligned access on all CPUs", " - ksmbd: fix use-after-free in SMB request handling", " - smb: client: fix NULL ptr deref in crypto_aead_setkey()", " - platform/chrome: cros_ec_typec: fix missing fwnode reference decrement", " - irqchip/irq-mvebu-sei: Move misplaced select() callback to SEI CP domain", " - x86/CPU/AMD: Terminate the erratum_1386_microcode array", " - ubi: wl: Put source PEB into correct list if trying locking LEB failed", " - um: ubd: Do not use drvdata in release", " - um: net: Do not use drvdata in release", " - dt-bindings: serial: rs485: Fix rs485-rts-delay property", " - serial: 8250_fintek: Add support for F81216E", " - serial: 8250: omap: Move pm_runtime_get_sync", " - serial: amba-pl011: Fix RX stall when DMA is used", " - serial: amba-pl011: fix build regression", " - mtd: ubi: fix unreleased fwnode_handle in find_volume_fwnode()", " - block: Prevent potential deadlock in blk_revalidate_disk_zones()", " - um: vector: Do not use drvdata in release", " - sh: cpuinfo: Fix a warning for CONFIG_CPUMASK_OFFSTACK", " - iio: gts: Fix uninitialized symbol 'ret'", " - ublk: fix ublk_ch_mmap() for 64K page size", " - arm64: tls: Fix context-switching of tpidrro_el0 when kpti is enabled", " - block: fix missing dispatching request when queue is started or unquiesced", " - block: fix ordering between checking QUEUE_FLAG_QUIESCED request adding", " - block: fix ordering between checking BLK_MQ_S_STOPPED request adding", " - blk-mq: Make blk_mq_quiesce_tagset() hold the tag list mutex less long", " - gve: Flow steering trigger reset only for timeout error", " - HID: wacom: Interpret tilt data from Intuos Pro BT as signed values", " - i40e: Fix handling changed priv flags", " - media: wl128x: Fix atomicity violation in fmc_send_cmd()", " - media: intel/ipu6: do not handle interrupts when device is disabled", " - arm64: dts: mediatek: mt8186-corsola-voltorb: Merge speaker codec nodes", " - netdev-genl: Hold rcu_read_lock in napi_get", " - soc: fsl: rcpm: fix missing of_node_put() in copy_ippdexpcr1_setting()", " - media: v4l2-core: v4l2-dv-timings: check cvt/gtf result", " - ALSA: rawmidi: Fix kvfree() call in spinlock", " - ALSA: ump: Fix evaluation of MIDI 1.0 FB info", " - ALSA: pcm: Add sanity NULL check for the default mmap fault handler", " - ALSA: hda/realtek: Update ALC225 depop procedure", " - ALSA: hda/realtek: Set PCBeep to default value for ALC274", " - ALSA: hda/realtek: Fix Internal Speaker and Mic boost of Infinix Y4 Max", " - ALSA: hda/realtek: Apply quirk for Medion E15433", " - smb3: request handle caching when caching directories", " - smb: client: handle max length for SMB symlinks", " - smb: Don't leak cfid when reconnect races with open_cached_dir", " - smb: prevent use-after-free due to open_cached_dir error paths", " - smb: During unmount, ensure all cached dir instances drop their dentry", " - usb: misc: ljca: set small runtime autosuspend delay", " - usb: misc: ljca: move usb_autopm_put_interface() after wait for response", " - usb: dwc3: ep0: Don't clear ep0 DWC3_EP_TRANSFER_STARTED", " - usb: musb: Fix hardware lockup on first Rx endpoint request", " - usb: dwc3: gadget: Fix checking for number of TRBs left", " - usb: dwc3: gadget: Fix looping of queued SG entries", " - staging: vchiq_arm: Fix missing refcount decrement in error path for fw_node", " - counter: stm32-timer-cnt: fix device_node handling in probe_encoder()", " - ublk: fix error code for unsupported command", " - lib: string_helpers: silence snprintf() output truncation warning", " - f2fs: fix to do sanity check on node blkaddr in truncate_node()", " - ipc: fix memleak if msg_init_ns failed in create_ipc_ns", " - Input: cs40l50 - fix wrong usage of INIT_WORK()", " - NFSD: Prevent a potential integer overflow", " - SUNRPC: make sure cache entry active before cache_show", " - um: Fix potential integer overflow during physmem setup", " - um: Fix the return value of elf_core_copy_task_fpregs", " - kfifo: don't include dma-mapping.h in kfifo.h", " - um: ubd: Initialize ubd's disk pointer in ubd_add", " - um: Always dump trace for specified task in show_stack", " - NFSv4.0: Fix a use-after-free problem in the asynchronous open()", " - rtc: st-lpc: Use IRQF_NO_AUTOEN flag in request_irq()", " - rtc: abx80x: Fix WDT bit position of the status register", " - rtc: check if __rtc_read_time was successful in rtc_timer_do_work()", " - ubi: fastmap: wl: Schedule fm_work if wear-leveling pool is empty", " - ubifs: Correct the total block count by deducting journal reservation", " - ubi: fastmap: Fix duplicate slab cache names while attaching", " - ubifs: authentication: Fix use-after-free in ubifs_tnc_end_commit", " - jffs2: fix use of uninitialized variable", " - rtc: rzn1: fix BCD to rtc_time conversion errors", " - Revert \"nfs: don't reuse partially completed requests in", " nfs_lock_and_join_requests\"", " - nvme-multipath: avoid hang on inaccessible namespaces", " - nvme/multipath: Fix RCU list traversal to use SRCU primitive", " - blk-mq: add non_owner variant of start_freeze/unfreeze queue APIs", " - block: model freeze & enter queue as lock for supporting lockdep", " - block: fix uaf for flush rq while iterating tags", " - block: return unsigned int from bdev_io_min", " - nvme-fabrics: fix kernel crash while shutting down controller", " - 9p/xen: fix init sequence", " - 9p/xen: fix release of IRQ", " - perf/arm-smmuv3: Fix lockdep assert in ->event_init()", " - perf/arm-cmn: Ensure port and device id bits are set properly", " - smb: client: disable directory caching when dir_cache_timeout is zero", " - x86/Documentation: Update algo in init_size description of boot protocol", " - cifs: Fix parsing native symlinks relative to the export", " - cifs: Fix parsing reparse point with native symlink in SMB1 non-UNICODE", " session", " - rtc: ab-eoz9: don't fail temperature reads on undervoltage notification", " - Rename .data.unlikely to .data..unlikely", " - Rename .data.once to .data..once to fix resetting WARN*_ONCE", " - kbuild: deb-pkg: Don't fail if modules.order is missing", " - smb: Initialize cfid->tcon before performing network ops", " - block: Don't allow an atomic write be truncated in blkdev_write_iter()", " - modpost: remove incorrect code in do_eisa_entry()", " - cifs: during remount, make sure passwords are in sync", " - cifs: unlock on error in smb3_reconfigure()", " - nfs: ignore SB_RDONLY when mounting nfs", " - sunrpc: clear XPRT_SOCK_UPD_TIMEOUT when reset transport", " - SUNRPC: timeout and cancel TLS handshake with -ETIMEDOUT", " - sunrpc: fix one UAF issue caused by sunrpc kernel tcp socket", " - nfs/blocklayout: Don't attempt unregister for invalid block device", " - nfs/blocklayout: Limit repeat device registration on failure", " - block, bfq: fix bfqq uaf in bfq_limit_depth()", " - brd: decrease the number of allocated pages which discarded", " - sh: intc: Fix use-after-free bug in register_intc_controller()", " - tools/power turbostat: Fix trailing '\\n' parsing", " - tools/power turbostat: Fix child's argument forwarding", " - block: always verify unfreeze lock on the owner task", " - block: don't verify IO lock for freeze/unfreeze in elevator_init_mq()", " - Linux 6.11.11", "", " * Oracular update: v6.11.11 upstream stable release (LP: #2091655) //", " CVE-2024-53141", " - netfilter: ipset: add missing range check in bitmap_ip_uadt", "", " * Oracular update: v6.11.11 upstream stable release (LP: #2091655) //", " CVE-2024-50010", " - Revert \"exec: don't WARN for racy path_noexec check\"", "", " * Oracular update: v6.11.11 upstream stable release (LP: #2091655) //", " CVE-2024-53143", " - fsnotify: Fix ordering of iput() and watched_objects decrement", "", " * Oracular update: v6.11.11 upstream stable release (LP: #2091655) //", " CVE-2024-53142", " - initramfs: avoid filename buffer overrun", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650)", " - net: vertexcom: mse102x: Fix tx_bytes calculation", " - net/mlx5: Fix msix vectors to respect platform limit", " - net/mlx5e: clear xdp features on non-uplink representors", " - net/mlx5e: Disable loopback self-test on multi-PF netdev", " - drm/i915/gsc: ARL-H and ARL-U need a newer GSC FW.", " - drivers: perf: Fix wrong put_cpu() placement", " - Bluetooth: hci_core: Fix calling mgmt_device_connected", " - Bluetooth: btintel: Direct exception event to bluetooth stack", " - net: sched: cls_u32: Fix u32's systematic failure to free IDR entries for", " hnodes.", " - net: phylink: ensure PHY momentary link-fails are handled", " - samples: pktgen: correct dev to DEV", " - net: stmmac: dwmac-mediatek: Fix inverted handling of mediatek,mac-wol", " - net: Make copy_safe_from_sockptr() match documentation", " - stmmac: dwmac-intel-plat: fix call balance of tx_clk handling routines", " - net: ti: icssg-prueth: Fix 1 PPS sync", " - bonding: add ns target multicast address to slave device", " - ARM: 9419/1: mm: Fix kernel memory mapping for xip kernels", " - tools/mm: fix compile error", " - drm/amd/display: Run idle optimizations at end of vblank handler", " - drm/amd/display: Change some variable name of psr", " - drm/amd/display: Fix Panel Replay not update screen correctly", " - x86/mm: Fix a kdump kernel failure on SME system when CONFIG_IMA_KEXEC=y", " - x86/stackprotector: Work around strict Clang TLS symbol requirements", " - crash, powerpc: default to CRASH_DUMP=n on PPC_BOOK3S_32", " - [Config] enable ARCH_DEFAULT_CRASH_DUMP", " - mm: revert \"mm: shmem: fix data-race in shmem_getattr()\"", " - vdpa/mlx5: Fix PA offset with unaligned starting iotlb map", " - evm: stop avoidably reading i_writecount in evm_file_release", " - KVM: selftests: Disable strict aliasing", " - KVM: nVMX: Treat vpid01 as current if L2 is active, but with VPID disabled", " - KVM: x86: Unconditionally set irr_pending when updating APICv state", " - tpm: Disable TPM on tpm2_create_primary() failure", " - ALSA: hda/realtek - Fixed Clevo platform headset Mic issue", " - ALSA: hda/realtek - update set GPIO3 to default for Thinkpad with ALC1318", " - mptcp: update local address flags when setting it", " - mptcp: hold pm lock when deleting entry", " - mptcp: pm: use _rcu variant under rcu_read_lock", " - ocfs2: fix UBSAN warning in ocfs2_verify_volume()", " - LoongArch: Fix early_numa_add_cpu() usage for FDT systems", " - LoongArch: Disable KASAN if PGDIR_SIZE is too large for cpu_vabits", " - LoongArch: Add WriteCombine shadow mapping in KASAN", " - LoongArch: Fix AP booting issue in VM mode", " - LoongArch: Make KASAN work with 5-level page-tables", " - selftests: hugetlb_dio: fixup check for initial conditions to skip in the", " start", " - btrfs: fix incorrect comparison for delayed refs", " - mailbox: qcom-cpucp: Mark the irq with IRQF_NO_SUSPEND flag", " - firmware: arm_scmi: Skip opp duplicates", " - firmware: arm_scmi: Report duplicate opps as firmware bugs", " - mmc: sunxi-mmc: Fix A100 compatible description", " - drm/bridge: tc358768: Fix DSI command tx", " - drm/xe: handle flat ccs during hibernation on igpu", " - pmdomain: arm: Use FLAG_DEV_NAME_FW to ensure unique names", " - pmdomain: core: Add GENPD_FLAG_DEV_NAME_FW flag", " - nouveau: fw: sync dma after setup is called.", " - nouveau: handle EBUSY and EAGAIN for GSP aux errors.", " - nouveau/dp: handle retries for AUX CH transfers with GSP.", " - drm/amd: Fix initialization mistake for NBIO 7.7.0", " - drm/amdgpu: fix check in gmc_v9_0_get_vm_pte()", " - drm/amdgpu: Fix video caps for H264 and HEVC encode maximum size", " - drm/amd/pm: print pp_dpm_mclk in ascending order on SMU v14.0.0", " - drm/amdgpu: enable GTT fallback handling for dGPUs only", " - drm/amdgpu/mes12: correct kiq unmap latency", " - drm/amd/display: Require minimum VBlank size for stutter optimization", " - drm/amd/display: Fix failure to read vram info due to static BP_RESULT", " - mm: refactor arch_calc_vm_flag_bits() and arm64 MTE handling", " - drm/xe: Restore system memory GGTT mappings", " - drm/xe: improve hibernation on igpu", " - lib/buildid: Fix build ID parsing logic", " - net: sched: u32: Add test case for systematic hnode IDR leaks", " - media: dvbdev: fix the logic when DVB_DYNAMIC_MINORS is not set", " - Linux 6.11.10", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53133", " - drm/amd/display: Handle dml allocation failure to avoid crash", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53108", " - drm/amd/display: Adjust VSDB parser for replay feature", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53134", " - pmdomain: imx93-blk-ctrl: correct remove path", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53132", " - drm/xe/oa: Fix \"Missing outer runtime PM protection\" warning", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53127", " - Revert \"mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K\"", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53130", " - nilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53105", " - mm: page_alloc: move mlocked flag clearance into free_pages_prepare()", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53109", " - nommu: pass NULL argument to vma_iter_prealloc()", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53131", " - nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53135", " - KVM: VMX: Bury Intel PT virtualization (guest/host mode) behind", " CONFIG_BROKEN", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53106", " - ima: fix buffer overrun in ima_eventdigest_init_common", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53110", " - vp_vdpa: fix id_table array not null terminated error", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53126", " - vdpa: solidrun: Fix UB bug with devres", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53111", " - mm/mremap: fix address wraparound in move_page_tables()", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53107", " - fs/proc/task_mmu: prevent integer overflow in pagemap_scan_get_args()", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53128", " - sched/task_stack: fix object_is_on_stack() for KASAN tagged pointers", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53112", " - ocfs2: uncache inode which has failed entering the group", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53113", " - mm: fix NULL pointer dereference in alloc_pages_bulk_noprof", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53114", " - x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 client", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53137", " - ARM: fix cacheflush with PAN", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53115", " - drm/vmwgfx: avoid null_ptr_deref in vmw_framebuffer_surface_create_handle", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53116", " - drm/panthor: Fix handling of partial GPU mapping of BOs", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53117", " - virtio/vsock: Improve MSG_ZEROCOPY error handling", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53118", " - vsock: Fix sk_error_queue memory leak", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53119", " - virtio/vsock: Fix accept_queue memory leak", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53120", " - net/mlx5e: CT: Fix null-ptr-deref in add rule err flow", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53138", " - net/mlx5e: kTLS, Fix incorrect page refcounting", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53121", " - net/mlx5: fs, lock FTE when checking if active", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53122", " - mptcp: cope racing subflow creation in mptcp_rcv_space_adjust", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53123", " - mptcp: error out earlier on disconnect", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53124", " - net: fix data-races around sk->sk_forward_alloc", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53129", " - drm/rockchip: vop: Fix a dereferenced before check warning", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53139", " - sctp: fix possible UAF in sctp_v6_available()", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53140", " - netlink: terminate outstanding dump on socket close", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649)", " - nvme/host: Fix RCU list traversal to use SRCU primitive", " - 9p: v9fs_fid_find: also lookup by inode if not found dentry", " - 9p: Avoid creating multiple slab caches with the same name", " - selftests/bpf: Verify that sync_linked_regs preserves subreg_def", " - nvmet-passthru: clear EUID/NGUID/UUID while using loop target", " - irqchip/ocelot: Fix trigger register address", " - pinctrl: aw9523: add missing mutex_destroy", " - pinctrl: intel: platform: Add Panther Lake to the list of supported", " - block: Fix elevator_get_default() checking for NULL q->tag_set", " - HID: multitouch: Add support for B2402FVA track point", " - HID: multitouch: Add quirk for HONOR MagicBook Art 14 touchpad", " - iommu/arm-smmu: Clarify MMU-500 CPRE workaround", " - nvme: disable CC.CRIME (NVME_CC_CRIME)", " - bpf: use kvzmalloc to allocate BPF verifier environment", " - crypto: api - Fix liveliness check in crypto_alg_tested", " - crypto: marvell/cesa - Disable hash algorithms", " - s390/ap: Fix CCA crypto card behavior within protected execution environment", " - sound: Make CONFIG_SND depend on INDIRECT_IOMEM instead of UML", " - drm/vmwgfx: Limit display layout ioctl array size to", " VMWGFX_NUM_DISPLAY_UNITS", " - selftests/bpf: Assert link info uprobe_multi count & path_size if unset", " - ALSA: hda/tas2781: Add new quirk for Lenovo, ASUS, Dell projects", " - drm/amdkfd: Accounting pdd vram_usage for svm", " - powerpc/powernv: Free name on error in opal_event_init()", " - net: phy: mdio-bcm-unimac: Add BCM6846 support", " - drm/xe/query: Increase timestamp width", " - nvme-loop: flush off pending I/O while shutting down loop controller", " - samples/landlock: Fix port parsing in sandboxer", " - vDPA/ifcvf: Fix pci_read_config_byte() return code handling", " - bpf: Fix mismatched RCU unlock flavour in bpf_out_neigh_v6", " - ASoC: Intel: avs: Update stream status in a separate thread", " - ASoC: codecs: Fix error handling in aw_dev_get_dsp_status function", " - ASoC: amd: yc: Add quirk for ASUS Vivobook S15 M3502RA", " - ASoC: amd: yc: Fix non-functional mic on ASUS E1404FA", " - ASoC: Intel: soc-acpi: lnl: Add match entry for TM2 laptops", " - netfs: Downgrade i_rwsem for a buffered write", " - HID: i2c-hid: Delayed i2c resume wakeup for 0x0d42 Goodix touchpad", " - HID: multitouch: Add quirk for Logitech Bolt receiver w/ Casa touchpad", " - HID: lenovo: Add support for Thinkpad X1 Tablet Gen 3 keyboard", " - ASoC: codecs: lpass-rx-macro: fix RXn(rx,n) macro for DSM_CTL and SEC7 regs", " - RISCV: KVM: use raw_spinlock for critical section in imsic", " - ASoC: rt722-sdca: increase clk_stop_timeout to fix clock stop issue", " - LoongArch: Use \"Exception return address\" to comment ERA", " - ASoC: fsl_micfil: Add sample rate constraint", " - net: usb: qmi_wwan: add Fibocom FG132 0x0112 composition", " - drm/xe: Enlarge the invalidation timeout from 150 to 500", " - drm/xe/guc/ct: Flush g2h worker in case of g2h response timeout", " - drm/xe: Handle unreliable MMIO reads during forcewake", " - drm/xe: Don't restart parallel queues multiple times on GT reset", " - mm: krealloc: Fix MTE false alarm in __do_krealloc", " - 9p: fix slab cache name creation for real", " - Linux 6.11.9", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53098", " - drm/xe/ufence: Prefetch ufence addr to catch bogus address", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53099", " - bpf: Check validity of link->type in bpf_link_show_fdinfo()", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53089", " - LoongArch: KVM: Mark hrtimer to expire in hard interrupt context", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53090", " - afs: Fix lock recursion", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53101", " - fs: Fix uninitialized value issue in from_kuid and from_kgid", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53091", " - bpf: Add sk_is_inet and IS_ICSK check in tls_sw_has_ctx_tx/rx", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53092", " - virtio_pci: Fix admin vq cleanup by using correct info pointer", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53102", " - nvme: make keep-alive synchronous operation", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53093", " - nvme-multipath: defer partition scanning", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53094", " - RDMA/siw: Add sendpage_ok() check to disable MSG_SPLICE_PAGES", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53100", " - nvme: tcp: avoid race between queue_lock lock and destroy", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53095", " - smb: client: Fix use-after-free of network namespace.", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645)", " - arm64: dts: rockchip: Fix rt5651 compatible value on rk3399-eaidk-610", " - arm64: dts: rockchip: Fix rt5651 compatible value on rk3399-sapphire-", " excavator", " - arm64: dts: rockchip: Move L3 cache outside CPUs in RK3588(S) SoC dtsi", " - arm64: dts: rockchip: Start cooling maps numbering from zero on ROCK 5B", " - arm64: dts: rockchip: Designate Turing RK1's system power controller", " - EDAC/qcom: Make irq configuration optional", " - arm64: dts: rockchip: Remove hdmi's 2nd interrupt on rk3328", " - arm64: dts: rockchip: Fix wakeup prop names on PineNote BT node", " - arm64: dts: rockchip: Fix reset-gpios property on brcm BT nodes", " - arm64: dts: rockchip: fix i2c2 pinctrl-names property on anbernic-rg353p/v", " - arm64: dts: rockchip: Drop regulator-init-microvolt from two boards", " - arm64: dts: rockchip: Fix bluetooth properties on rk3566 box demo", " - arm64: dts: rockchip: Fix bluetooth properties on Rock960 boards", " - arm64: dts: rockchip: Add DTS for FriendlyARM NanoPi R2S Plus", " - arm64: dts: rockchip: Remove undocumented supports-emmc property", " - arm64: dts: rockchip: Remove #cooling-cells from fan on Theobroma lion", " - arm64: dts: rockchip: Fix LED triggers on rk3308-roc-cc", " - arm64: dts: rockchip: remove num-slots property from rk3328-nanopi-r2s-plus", " - arm64: dts: qcom: sm8450 fix PIPE clock specification for pcie1", " - arm64: dts: imx8-ss-vpu: Fix imx8qm VPU IRQs", " - arm64: dts: imx8mp: correct sdhc ipg clk", " - arm64: dts: imx8mp-phyboard-pollux: Set Video PLL1 frequency to 506.8 MHz", " - firmware: qcom: scm: Return -EOPNOTSUPP for unsupported SHM bridge enabling", " - arm64: dts: rockchip: remove orphaned pinctrl-names from pinephone pro", " - ARM: dts: rockchip: fix rk3036 acodec node", " - ARM: dts: rockchip: drop grf reference from rk3036 hdmi", " - ARM: dts: rockchip: Fix the spi controller on rk3036", " - ARM: dts: rockchip: Fix the realtek audio codec on rk3036-kylin", " - arm64: dts: rockchip: Correct GPIO polarity on brcm BT nodes", " - sunrpc: handle -ENOTCONN in xs_tcp_setup_socket()", " - NFSv3: only use NFS timeout for MOUNT when protocols are compatible", " - NFS: Fix attribute delegation behaviour on exclusive create", " - NFS: Further fixes to attribute delegation a/mtime changes", " - nfs: avoid i_lock contention in nfs_clear_invalid_mapping", " - net: enetc: set MAC address to the VF net_device", " - net: dpaa_eth: print FD status in CPU endianness in dpaa_eth_fd tracepoint", " - dt-bindings: net: xlnx,axi-ethernet: Correct phy-mode property value", " - can: c_can: fix {rx,tx}_errors statistics", " - ice: change q_index variable type to s16 to store -1 value", " - e1000e: Remove Meteor Lake SMBUS workarounds", " - net: phy: ti: add PHY_RST_AFTER_CLK_EN flag", " - net: stmmac: Fix unbalanced IRQ wake disable warning on single irq case", " - netfilter: nf_tables: wait for rcu grace period on net_device removal", " - virtio_net: Support dynamic rss indirection table size", " - virtio_net: Sync rss config to device when virtnet_probe", " - virtio_net: Update rss when set queue", " - net: arc: rockchip: fix emac mdio node support", " - drivers: net: ionic: add missed debugfs cleanup to ionic_probe() error path", " - Revert \"ALSA: hda/conexant: Mute speakers at suspend / shutdown\"", " - media: stb0899_algo: initialize cfr before using it", " - media: dvb_frontend: don't play tricks with underflow values", " - media: adv7604: prevent underflow condition when reporting colorspace", " - scsi: sd_zbc: Use kvzalloc() to allocate REPORT ZONES buffer", " - ALSA: firewire-lib: fix return value on fail in amdtp_tscm_init()", " - tools/lib/thermal: Fix sampling handler context ptr", " - thermal/of: support thermal zones w/o trips subnode", " - ASoC: SOF: sof-client-probes-ipc4: Set param_size extension bits", " - media: pulse8-cec: fix data timestamp at pulse8_setup()", " - media: v4l2-ctrls-api: fix error handling for v4l2_g_ctrl()", " - can: m_can: m_can_close(): don't call free_irq() for IRQ-less devices", " - can: mcp251xfd: mcp251xfd_get_tef_len(): fix length calculation", " - can: mcp251xfd: mcp251xfd_ring_alloc(): fix coalescing configuration when", " switching CAN modes", " - can: {cc770,sja1000}_isa: allow building on x86_64", " - [Config] updateconfigs for CAN_{CC770,SJA1000}_ISA", " - drm/xe: Set mask bits for CCS_MODE register", " - pwm: imx-tpm: Use correct MODULO value for EPWM mode", " - rpmsg: glink: Handle rejected intent request better", " - drm/amd/pm: always pick the pptable from IFWI", " - drm/amd/display: Fix brightness level not retained over reboot", " - drm/imagination: Add a per-file PVR context list", " - drm/amdgpu: Adjust debugfs eviction and IB access permissions", " - drm/amdgpu: Adjust debugfs register access permissions", " - drm/amdgpu: Fix DPX valid mode check on GC 9.4.3", " - drm/amdgpu: prevent NULL pointer dereference if ATIF is not supported", " - thermal/drivers/qcom/lmh: Remove false lockdep backtrace", " - dm cache: correct the number of origin blocks to match the target length", " - dm cache: optimize dirty bit checking with find_next_bit when resizing", " - dm-unstriped: cast an operand to sector_t to prevent potential uint32_t", " overflow", " - mptcp: no admin perm to list endpoints", " - ALSA: usb-audio: Add quirk for HP 320 FHD Webcam", " - tracing: Fix tracefs mount options", " - net: wwan: t7xx: Fix off-by-one error in t7xx_dpmaif_rx_buf_alloc()", " - mptcp: use sock_kfree_s instead of kfree", " - arm64: Kconfig: Make SME depend on BROKEN for now", " - [Config] updateconfigs for ARM64_SME", " - arm64: smccc: Remove broken support for SMCCCv1.3 SVE discard hint", " - KVM: PPC: Book3S HV: Mask off LPCR_MER for a vCPU before running it to avoid", " spurious interrupts", " - btrfs: fix the length of reserved qgroup to free", " - btrfs: fix per-subvolume RO/RW flags with new mount API", " - platform/x86/amd/pmf: Relocate CPU ID macros to the PMF header", " - platform/x86/amd/pmf: Update SMU metrics table for 1AH family series", " - platform/x86/amd/pmf: Add SMU metrics table support for 1Ah family 60h model", " - i2c: designware: do not hold SCL low when I2C_DYNAMIC_TAR_UPDATE is not set", " - clk: qcom: gcc-x1e80100: Fix USB MP SS1 PHY GDSC pwrsts flags", " - clk: qcom: clk-alpha-pll: Fix pll post div mask when width is not set", " - fs/proc: fix compile warning about variable 'vmcore_mmap_ops'", " - objpool: fix to make percpu slot allocation more robust", " - mm/damon/core: handle zero {aggregation,ops_update} intervals", " - mm/damon/core: handle zero schemes apply interval", " - mm/mlock: set the correct prev on failure", " - thunderbolt: Add only on-board retimers when !CONFIG_USB4_DEBUGFS_MARGINING", " - usb: dwc3: fix fault at system suspend if device was already runtime", " suspended", " - USB: serial: qcserial: add support for Sierra Wireless EM86xx", " - USB: serial: option: add Fibocom FG132 0x0112 composition", " - USB: serial: option: add Quectel RG650V", " - clk: qcom: gcc-x1e80100: Fix halt_check for pipediv2 clocks", " - thunderbolt: Fix connection issue with Pluggable UD-4VPD dock", " - staging: vchiq_arm: Use devm_kzalloc() for drv_mgmt allocation", " - staging: vchiq_arm: Use devm_kzalloc() for vchiq_arm_state allocation", " - irqchip/gic-v3: Force propagation of the active state with a read-back", " - ucounts: fix counter leak in inc_rlimit_get_ucounts()", " - selftests: hugetlb_dio: check for initial conditions to skip in the start", " - firmware: qcom: scm: Refactor code to support multiple dload mode", " - [Config] updateconfigs for QCOM_SCM_DOWNLOAD_MODE_DEFAULT", " - firmware: qcom: scm: suppress download mode error", " - block: rework bio splitting", " - block: fix queue limits checks in blk_rq_map_user_bvec for real", " - drm/xe: Move LNL scheduling WA to xe_device.h", " - drm/xe/ufence: Flush xe ordered_wq in case of ufence timeout", " - drm/xe/guc/tlb: Flush g2h worker in case of tlb timeout", " - ASoC: amd: yc: fix internal mic on Xiaomi Book Pro 14 2022", " - xtensa: Emulate one-byte cmpxchg", " - Linux 6.11.8", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50265", " - ocfs2: remove entry once instead of null-ptr-dereference in", " ocfs2_xa_remove()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50266", " - clk: qcom: videocc-sm8350: use HW_CTRL_TRIGGER for vcodec GDSCs", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50267", " - USB: serial: io_edgeport: fix use after free in debug printk", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50268", " - usb: typec: fix potential out of bounds in ucsi_ccg_update_set_new_cam_cmd()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53083", " - usb: typec: qcom-pmic: init value of hdr_len/txbuf_len earlier", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50269", " - usb: musb: sunxi: Fix accessing an released usb phy", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53079", " - mm/thp: fix deferred split unqueue naming and locking", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50270", " - mm/damon/core: avoid overflow in damon_feed_loop_next_input()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50271", " - signal: restore the override_rlimit logic", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50272", " - filemap: Fix bounds checking in filemap_read()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53104", " - media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in", " uvc_parse_format", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50273", " - btrfs: reinitialize delayed ref list after deleting it from the list", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53064", " - idpf: fix idpf_vc_core_init error path", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50274", " - idpf: avoid vport access in idpf_get_link_ksettings", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53065", " - mm/slab: fix warning caused by duplicate kmem_cache creation in", " kmem_buckets_create", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50275", " - arm64/sve: Discard stale CPU state when handling SVE traps", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50276", " - net: vertexcom: mse102x: Fix possible double free of TX skb", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53066", " - nfs: Fix KMSAN warning in decode_getfattr_attrs()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53067", " - scsi: ufs: core: Start the RTC update work later", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50277", " - dm: fix a crash if blk_alloc_disk fails", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50278", " - dm cache: fix potential out-of-bounds access on the first resume", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50279", " - dm cache: fix out-of-bounds access to the dirty bitset when resizing", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50280", " - dm cache: fix flushing uninitialized delayed_work on cache_ctr error", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50281", " - KEYS: trusted: dcp: fix NULL dereference in AEAD crypto operation", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50282", " - drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53071", " - drm/panthor: Be stricter about IO mapping flags", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53080", " - drm/panthor: Lock XArray when getting entries for the VM", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53084", " - drm/imagination: Break an object reference loop", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53085", " - tpm: Lock TPM chip in tpm_pm_suspend() first", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53086", " - drm/xe: Drop VM dma-resv lock on xe_sync_in_fence_get failure in exec IOCTL", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53087", " - drm/xe: Fix possible exec queue leak in exec IOCTL", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50283", " - ksmbd: fix slab-use-after-free in smb3_preauth_hash_rsp", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50284", " - ksmbd: Fix the missing xa_store error check", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50285", " - ksmbd: check outstanding simultaneous SMB operations", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50286", " - ksmbd: fix slab-use-after-free in ksmbd_smb2_session_create", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50287", " - media: v4l2-tpg: prevent the risk of a division by zero", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50288", " - media: vivid: fix buffer overwrite when using > 32 buffers", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50289", " - media: av7110: fix a spectre vulnerability", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50290", " - media: cx24116: prevent overflows on SNR calculus", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53061", " - media: s5p-jpeg: prevent buffer overflows", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53081", " - media: ar0521: don't overflow when checking PLL values", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53062", " - media: mgb4: protect driver against spectre", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50291", " - media: dvb-core: add missing buffer index check", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50292", " - ASoC: stm32: spdifrx: fix dma channel release in stm32_spdifrx_remove", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53063", " - media: dvbdev: prevent the risk of out of memory access", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50293", " - net/smc: do not leave a dangling sk pointer in __smc_create()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50294", " - rxrpc: Fix missing locking causing hanging calls", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50295", " - net: arc: fix the device for dma_map_single/dma_unmap_single", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53082", " - virtio_net: Add hash_key_length check", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50296", " - net: hns3: fix kernel crash when uninstalling driver", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53088", " - i40e: fix race condition by adding filter's intermediate sync state", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50297", " - net: xilinx: axienet: Enqueue Tx packets in dql before dmaengine starts", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50298", " - net: enetc: allocate vf_state during PF probes", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50299", " - sctp: properly validate chunk size in sctp_sf_ootb()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50300", " - regulator: rtq2208: Fix uninitialized use of regulator_config", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50301", " - security/keys: fix slab-out-of-bounds in key_task_permission", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53072", " - platform/x86/amd/pmc: Detect when STB is not available", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50302", " - HID: core: zero-initialize the report buffer", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53068", " - firmware: arm_scmi: Fix slab-use-after-free in scmi_bus_notifier()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53069", " - firmware: qcom: scm: fix a NULL-pointer dereference", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629)", " - drm/amdgpu: fix random data corruption for sdma 7", " - cgroup: Fix potential overflow issue when checking max_depth", " - spi: geni-qcom: Fix boot warning related to pm_runtime and devres", " - perf trace: Fix non-listed archs in the syscalltbl routines", " - perf python: Fix up the build on architectures without HAVE_KVM_STAT_SUPPORT", " - scsi: scsi_debug: Fix do_device_access() handling of unexpected SG copy", " length", " - wifi: iwlegacy: Fix \"field-spanning write\" warning in il_enqueue_hcmd()", " - mac80211: MAC80211_MESSAGE_TRACING should depend on TRACING", " - wifi: mac80211: skip non-uploaded keys in ieee80211_iter_keys", " - wifi: ath11k: Fix invalid ring usage in full monitor mode", " - wifi: rtw89: pci: early chips only enable 36-bit DMA on specific PCI hosts", " - wifi: brcm80211: BRCM_TRACING should depend on TRACING", " - RDMA/cxgb4: Dump vendor specific QP details", " - RDMA/mlx5: Round max_rd_atomic/max_dest_rd_atomic up instead of down", " - RDMA/bnxt_re: Fix the usage of control path spin locks", " - RDMA/bnxt_re: synchronize the qp-handle table array", " - wifi: iwlwifi: mvm: really send iwl_txpower_constraints_cmd", " - wifi: iwlwifi: mvm: don't add default link in fw restart flow", " - Revert \"wifi: iwlwifi: remove retry loops in start\"", " - ASoC: cs42l51: Fix some error handling paths in cs42l51_probe()", " - net: stmmac: dwmac4: Fix high address display by updating reg_space[] from", " register values", " - dpll: add Embedded SYNC feature for a pin", " - ice: add callbacks for Embedded SYNC enablement on dpll pins", " - gtp: allow -1 to be specified as file description from userspace", " - bpf: Force checkpoint when jmp history is too long", " - bpf: Add bpf_mem_alloc_check_size() helper", " - net: skip offload for NETIF_F_IPV6_CSUM if ipv6 header contains extension", " - mlxsw: spectrum_ptp: Add missing verification before pushing Tx header", " - mlxsw: pci: Sync Rx buffers for CPU", " - mlxsw: pci: Sync Rx buffers for device", " - net: ethernet: mtk_wed: fix path of MT7988 WO firmware", " - bpf, test_run: Fix LIVE_FRAME frame update after a page has been recycled", " - iomap: improve shared block detection in iomap_unshare_iter", " - iomap: don't bother unsharing delalloc extents", " - iomap: share iomap_unshare_iter predicate code with fsdax", " - fsdax: remove zeroing code from dax_unshare_iter", " - iomap: turn iomap_want_unshare_iter into an inline function", " - kasan: Fix Software Tag-Based KASAN with GCC", " - firmware: arm_sdei: Fix the input parameter of cpuhp_remove_state()", " - afs: Fix missing subdir edit when renamed between parent dirs", " - gpio: sloppy-logic-analyzer: Check for error code from devm_mutex_init()", " call", " - smb: client: fix parsing of device numbers", " - smb: client: set correct device number on nfs reparse points", " - drm/mediatek: ovl: Remove the color format comment for ovl_fmt_convert()", " - drm/mediatek: Fix color format MACROs in OVL", " - drm/mediatek: Fix get efuse issue for MT8188 DPTX", " - drm/mediatek: Use cmdq_pkt_create() and cmdq_pkt_destroy()", " - cxl/events: Fix Trace DRAM Event Record", " - PCI: Fix pci_enable_acs() support for the ACS quirks", " - nvme: module parameter to disable pi with offsets", " - drm/panthor: Fix firmware initialization on systems with a page size > 4k", " - drm/panthor: Fail job creation when the group is dead", " - drm/panthor: Report group as timedout when we fail to properly suspend", " - fs/ntfs3: Fix warning possible deadlock in ntfs_set_state", " - fs/ntfs3: Stale inode instead of bad", " - rust: device: change the from_raw() function", " - scsi: scsi_transport_fc: Allow setting rport state to current state", " - cifs: Improve creating native symlinks pointing to directory", " - cifs: Fix creating native symlinks pointing to current or parent directory", " - ACPI: resource: Fold Asus Vivobook Pro N6506M* DMI quirks together", " - powercap: intel_rapl_msr: Add PL4 support for Arrowlake-U", " - thermal: intel: int340x: processor: Remove MMIO RAPL CPU hotplug support", " - thermal: intel: int340x: processor: Add MMIO RAPL PL4 support", " - net: amd: mvme147: Fix probe banner message", " - NFS: remove revoked delegation from server's delegation list", " - misc: sgi-gru: Don't disable preemption in GRU driver", " - NFSD: Initialize struct nfsd4_copy earlier", " - NFSD: Never decrement pending_async_copies on error", " - ALSA: usb-audio: Add quirks for Dell WD19 dock", " - wifi: rtlwifi: rtl8192du: Don't claim USB ID 0bda:8171", " - usbip: tools: Fix detach_port() invalid port error path", " - usb: phy: Fix API devm_usb_put_phy() can not release the phy", " - usb: typec: fix unreleased fwnode_handle in typec_port_register_altmodes()", " - usb: typec: tcpm: restrict SNK_WAIT_CAPABILITIES_TIMEOUT transitions to non", " self-powered devices", " - usb: typec: qcom-pmic-typec: use fwnode_handle_put() to release fwnodes", " - usb: typec: qcom-pmic-typec: fix missing fwnode removal in error path", " - xhci: Fix Link TRB DMA in command ring stopped completion event", " - xhci: Use pm_runtime_get to prevent RPM on unsupported systems", " - Revert \"driver core: Fix uevent_show() vs driver detach race\"", " - dt-bindings: iio: adc: ad7380: fix ad7380-4 reference supply", " - iio: light: veml6030: fix microlux value calculation", " - RISC-V: ACPI: fix early_ioremap to early_memremap", " - tools/mm: -Werror fixes in page-types/slabinfo", " - mm: shrinker: avoid memleak in alloc_shrinker_info", " - firmware: microchip: auto-update: fix poll_complete() to not report spurious", " timeout errors", " - thunderbolt: Honor TMU requirements in the domain when setting TMU mode", " - soc: qcom: pmic_glink: Handle GLINK intent allocation rejections", " - cxl/port: Fix CXL port initialization order when the subsystem is built-in", " - mmc: sdhci-pci-gli: GL9767: Fix low power mode on the set clock function", " - mmc: sdhci-pci-gli: GL9767: Fix low power mode in the SD Express process", " - block: fix sanity checks in blk_rq_map_user_bvec", " - phy: freescale: imx8m-pcie: Do CMN_RST just before PHY PLL lock check", " - btrfs: merge btrfs_orig_bbio_end_io() into btrfs_bio_end_io()", " - riscv: vdso: Prevent the compiler from inserting calls to memset()", " - Input: edt-ft5x06 - fix regmap leak when probe fails", " - ALSA: hda/realtek: Limit internal Mic boost on Dell platform", " - riscv: efi: Set NX compat flag in PE/COFF header", " - riscv: Use '%u' to format the output of 'cpu'", " - riscv: Remove unused GENERATING_ASM_OFFSETS", " - riscv: Remove duplicated GET_RM", " - cxl/port: Fix cxl_bus_rescan() vs bus_rescan_devices()", " - cxl/acpi: Ensure ports ready at cxl_acpi_probe() return", " - posix-cpu-timers: Clear TICK_DEP_BIT_POSIX_TIMER on clone", " - tpm: Return tpm2_sessions_init() when null key creation fails", " - tpm: Rollback tpm2_load_null()", " - drm/amdgpu/smu13: fix profile reporting", " - tpm: Lazily flush the auth session", " - mei: use kvmalloc for read buffer", " - x86/traps: Enable UBSAN traps on x86", " - x86/traps: move kmsan check after instrumentation_begin", " - accel/ivpu: Fix NOC firewall interrupt handling", " - ALSA: hda/realtek: Fix headset mic on TUXEDO Gemini 17 Gen3", " - ALSA: hda/realtek: Fix headset mic on TUXEDO Stellaris 16 Gen6 mb1", " - nvme: re-fix error-handling for io_uring nvme-passthrough", " - kasan: remove vmalloc_percpu test", " - drm/tests: helpers: Add helper for drm_display_mode_from_cea_vic()", " - drm/xe: Fix register definition order in xe_regs.h", " - drm/xe: Kill regs/xe_sriov_regs.h", " - drm/xe: Add mmio read before GGTT invalidate", " - drm/xe: Don't short circuit TDR on jobs not started", " - btrfs: fix extent map merging not happening for adjacent extents", " - btrfs: fix defrag not merging contiguous extents due to merged extent maps", " - gpiolib: fix debugfs newline separators", " - gpiolib: fix debugfs dangling chip separator", " - vmscan,migrate: fix page count imbalance on node stats when demoting pages", " - mm, mmap: limit THP alignment of anonymous mappings to PMD-aligned sizes", " - Input: fix regression when re-registering input handlers", " - mm: multi-gen LRU: ignore non-leaf pmd_young for force_scan=true", " - mm: multi-gen LRU: remove MM_LEAF_OLD and MM_NONLEAF_TOTAL stats", " - mm: shrink skip folio mapped by an exiting process", " - mm: multi-gen LRU: use {ptep,pmdp}_clear_young_notify()", " - riscv: dts: starfive: Update ethernet phy0 delay parameter values for Star64", " - riscv: dts: starfive: disable unused csi/camss nodes", " - arm64: dts: qcom: msm8939: revert use of APCS mbox for RPM", " - arm64: dts: qcom: x1e80100-yoga-slim7x: fix nvme regulator boot glitch", " - arm64: dts: qcom: x1e80100: Fix up BAR spaces", " - arm64: dts: qcom: x1e80100-vivobook-s15: fix nvme regulator boot glitch", " - arm64: dts: qcom: x1e80100: fix PCIe4 interconnect", " - arm64: dts: qcom: x1e80100-qcp: fix nvme regulator boot glitch", " - arm64: dts: qcom: x1e80100-crd: fix nvme regulator boot glitch", " - arm64: dts: qcom: x1e80100: Add Broadcast_AND region in LLCC block", " - arm64: dts: qcom: x1e80100: fix PCIe4 and PCIe6a PHY clocks", " - drm/xe/xe2hpg: Add Wa_15016589081", " - drm/amdgpu/swsmu: fix ordering for setting workload_mask", " - drm/amdgpu/swsmu: default to fullscreen 3D profile for dGPUs", " - fs/ntfs3: Sequential field availability check in mi_enum_attr()", " - drm/amdgpu: handle default profile on on devices without fullscreen 3D", " - MIPS: export __cmpxchg_small()", " - RISC-V: disallow gcc + rust builds", " - [Config] updateconfigs after disabling rust with gcc on riscv", " - rcu/kvfree: Add kvfree_rcu_barrier() API", " - rcu/kvfree: Refactor kvfree_rcu_queue_batch()", " - Linux 6.11.7", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50212", " - lib: alloc_tag_module_unload must wait for pending kfree_rcu calls", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53046", " - arm64: dts: imx8ulp: correct the flexspi compatible string", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53052", " - io_uring/rw: fix missing NOWAIT check for O_DIRECT start write", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50213", " - drm/tests: hdmi: Fix memory leaks in drm_display_mode_from_cea_vic()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50214", " - drm/connector: hdmi: Fix memory leak in drm_display_mode_from_cea_vic()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50215", " - nvmet-auth: assign dh_key to NULL after kfree_sensitive", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50216", " - xfs: fix finding a last resort AG in xfs_filestream_pick_ag", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50217", " - btrfs: fix use-after-free of block device file in", " __btrfs_free_extra_devids()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53043", " - mctp i2c: handle NULL header address", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50303", " - resource,kexec: walk_system_ram_res_rev must retain resource flags", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50218", " - ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50219", " - mm/page_alloc: let GFP_ATOMIC order-0 allocs access highatomic reserves", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50263", " - fork: only invoke khugepaged, ksm hooks if no error", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50220", " - fork: do not invoke uffd on fork if error occurs", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53047", " - mptcp: init: protect sched with rcu_read_lock", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50221", " - drm/amd/pm: Vangogh: Fix kernel memory out of bounds write", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50222", " - iov_iter: fix copy_page_from_iter_atomic() if KMAP_LOCAL_FORCE_MAP", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50223", " - sched/numa: Fix the potential null pointer dereference in task_numa_work()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53053", " - scsi: ufs: core: Fix another deadlock during RTC update", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53075", " - riscv: Prevent a bad reference count on CPU nodes", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50224", " - spi: spi-fsl-dspi: Fix crash when not using GPIO chip select", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50225", " - btrfs: fix error propagation of split bios", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53054", " - cgroup/bpf: use a dedicated workqueue for cgroup bpf destruction", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50226", " - cxl/port: Fix use-after-free, permit out-of-order decoder shutdown", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50227", " - thunderbolt: Fix KASAN reported stack out-of-bounds read in", " tb_retimer_scan()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50228", " - mm: shmem: fix data-race in shmem_getattr()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50229", " - nilfs2: fix potential deadlock with newly created symlinks", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50230", " - nilfs2: fix kernel bug due to missing clearing of checked flag", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50231", " - iio: gts-helper: Fix memory leaks in iio_gts_build_avail_scale_table()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53076", " - iio: gts-helper: Fix memory leaks for the error path of", " iio_gts_build_avail_scale_table()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50232", " - iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50233", " - staging: iio: frequency: ad9832: fix division by zero in", " ad9832_calc_freqreg()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53055", " - wifi: iwlwifi: mvm: fix 6 GHz scan construction", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50234", " - wifi: iwlegacy: Clear stale interrupts before resuming device", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50235", " - wifi: cfg80211: clear wdev->cqm_config pointer on free", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50236", " - wifi: ath10k: Fix memory leak in management tx", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50237", " - wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50238", " - phy: qcom: qmp-usbc: fix NULL-deref on runtime suspend", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50239", " - phy: qcom: qmp-usb-legacy: fix NULL-deref on runtime suspend", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50240", " - phy: qcom: qmp-usb: fix NULL-deref on runtime suspend", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53077", " - rpcrdma: Always release the rpcrdma_device's xa_array", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50242", " - fs/ntfs3: Additional check in ntfs_file_release", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50243", " - fs/ntfs3: Fix general protection fault in run_is_mapped_full", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50244", " - fs/ntfs3: Additional check in ni_clear()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50245", " - fs/ntfs3: Fix possible deadlock in mi_read", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50246", " - fs/ntfs3: Add rough attr alloc_size check", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50247", " - fs/ntfs3: Check if more than chunk-size bytes are written", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50248", " - ntfs3: Add bounds checking to mi_enum_attr()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53078", " - drm/tegra: Fix NULL vs IS_ERR() check in probe()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53056", " - drm/mediatek: Fix potential NULL dereference in mtk_crtc_destroy()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50249", " - ACPI: CPPC: Make rmw_lock a raw_spin_lock", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50250", " - fsdax: dax_unshare_iter needs to copy entire blocks", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50251", " - netfilter: nft_payload: sanitize offset and length before calling", " skb_checksum()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50252", " - mlxsw: spectrum_ipip: Fix memory leak when changing remote IPv6 address", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50253", " - bpf: Check the validity of nr_words in bpf_iter_bits_new()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50254", " - bpf: Free dynamically allocated bits in bpf_iter_bits_destroy()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50255", " - Bluetooth: hci: fix null-ptr-deref in hci_read_supported_codecs", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50256", " - netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50257", " - netfilter: Fix use-after-free in get_info()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50258", " - net: fix crash when config small gso_max_size/gso_ipv4_max_size", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50262", " - bpf: Fix out-of-bounds write in trie_get_next_key()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53044", " - net/sched: sch_api: fix xa_insert() error path in tcf_block_get_ext()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50259", " - netdevsim: Add trailing zero to terminate the string in", " nsim_nexthop_bucket_activity_write()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50304", " - ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53042", " - ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_init_flow()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53048", " - ice: fix crash on probe for DPLL enabled E810 LOM", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53058", " - net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50260", " - sock_map: fix a NULL pointer dereference in sock_map_link_update_prog()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53045", " - ASoC: dapm: fix bounds checker error in dapm_widget_list_create", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50261", " - macsec: Fix use-after-free while sending the offloading packet", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53059", " - wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53074", " - wifi: iwlwifi: mvm: don't leak a link on AP removal", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53049", " - slub/kunit: fix a WARNING due to unwrapped __kmalloc_cache_noprof", "", " * Oracular update: v6.11.6 upstream stable release (LP: #2091386)", " - bpf: Use raw_spinlock_t in ringbuf", " - iio: accel: bma400: Fix uninitialized variable field_value in tap event", " handling.", " - reset: starfive: jh71x0: Fix accessing the empty member on JH7110 SoC", " - bpf: sync_linked_regs() must preserve subreg_def", " - bpf: Make sure internal and UAPI bpf_redirect flags don't overlap", " - irqchip/riscv-imsic: Fix output text of base address", " - bpf: devmap: provide rxq after redirect", " - cpufreq/amd-pstate: Fix amd_pstate mode switch on shared memory systems", " - lib/Kconfig.debug: fix grammar in RUST_BUILD_ASSERT_ALLOW", " - bpf: Fix memory leak in bpf_core_apply", " - RDMA/bnxt_re: Fix a possible memory leak", " - RDMA/bnxt_re: Fix incorrect AVID type in WQE structure", " - RDMA/bnxt_re: Add a check for memory allocation", " - x86/resctrl: Avoid overflow in MB settings in bw_validate()", " - ARM: dts: bcm2837-rpi-cm3-io3: Fix HDMI hpd-gpio pin", " - clk: rockchip: fix finding of maximum clock ID", " - bpf: Check the remaining info_cnt before repeating btf fields", " - bpf: fix unpopulated name_len field in perf_event link info", " - selftests/bpf: fix perf_event link info name_len assertion", " - riscv, bpf: Fix possible infinite tailcall when CONFIG_CFI_CLANG is enabled", " - s390/pci: Handle PCI error codes other than 0x3a", " - bpf: fix kfunc btf caching for modules", " - iio: frequency: {admv4420,adrf6780}: format Kconfig entries", " - iio: frequency: admv4420: fix missing select REMAP_SPI in Kconfig", " - drm/vmwgfx: Handle possible ENOMEM in vmw_stdu_connector_atomic_check", " - selftests/bpf: Fix cross-compiling urandom_read", " - bpf: Fix unpopulated path_size when uprobe_multi fields unset", " - sched/core: Disable page allocation in task_tick_mm_cid()", " - ALSA: hda/cs8409: Fix possible NULL dereference", " - firmware: arm_scmi: Fix the double free in scmi_debugfs_common_setup()", " - RDMA/cxgb4: Fix RDMA_CM_EVENT_UNREACHABLE error for iWARP", " - RDMA/irdma: Fix misspelling of \"accept*\"", " - RDMA/srpt: Make slab cache names unique", " - elevator: do not request_module if elevator exists", " - elevator: Remove argument from elevator_find_get", " - ipv4: give an IPv4 dev to blackhole_netdev", " - net: sparx5: fix source port register when mirroring", " - RDMA/bnxt_re: Fix the max CQ WQEs for older adapters", " - RDMA/bnxt_re: Fix out of bound check", " - RDMA/bnxt_re: Fix incorrect dereference of srq in async event", " - RDMA/bnxt_re: Return more meaningful error", " - RDMA/bnxt_re: Avoid CPU lockups due fifo occupancy check loop", " - RDMA/bnxt_re: Get the toggle bits from SRQ events", " - RDMA/bnxt_re: Change the sequence of updating the CQ toggle value", " - RDMA/bnxt_re: Fix a bug while setting up Level-2 PBL pages", " - RDMA/bnxt_re: Fix the GID table length", " - accel/qaic: Fix the for loop used to walk SG table", " - drm/panel: himax-hx83102: Adjust power and gamma to optimize brightness", " - drm/msm/dpu: make sure phys resources are properly initialized", " - drm/msm/dpu: move CRTC resource assignment to dpu_encoder_virt_atomic_check", " - drm/msm/dpu: check for overflow in _dpu_crtc_setup_lm_bounds()", " - drm/msm/dsi: improve/fix dsc pclk calculation", " - drm/msm/dsi: fix 32-bit signed integer extension in pclk_rate calculation", " - drm/msm: Avoid NULL dereference in msm_disp_state_print_regs()", " - drm/msm: Allocate memory for disp snapshot with kvzalloc()", " - firmware: arm_scmi: Queue in scmi layer for mailbox implementation", " - net/smc: Fix memory leak when using percpu refs", " - [PATCH} hwmon: (jc42) Properly detect TSE2004-compliant devices again", " - net: usb: usbnet: fix race in probe failure", " - net: stmmac: dwmac-tegra: Fix link bring-up sequence", " - octeontx2-af: Fix potential integer overflows on integer shifts", " - ring-buffer: Fix reader locking when changing the sub buffer order", " - drm/amd/amdgpu: Fix double unlock in amdgpu_mes_add_ring", " - macsec: don't increment counters for an unrelated SA", " - netdevsim: use cond_resched() in nsim_dev_trap_report_work()", " - net: ethernet: aeroflex: fix potential memory leak in", " greth_start_xmit_gbit()", " - net/smc: Fix searching in list of known pnetids in smc_pnet_add_pnetid", " - net: xilinx: axienet: fix potential memory leak in axienet_start_xmit()", " - net: ethernet: rtsn: fix potential memory leak in rtsn_start_xmit()", " - bpf: Fix truncation bug in coerce_reg_to_size_sx()", " - net: systemport: fix potential memory leak in bcm_sysport_xmit()", " - irqchip/renesas-rzg2l: Fix missing put_device", " - drm/msm/dpu: Don't always set merge_3d pending flush", " - drm/msm/dpu: don't always program merge_3d block", " - net: bcmasp: fix potential memory leak in bcmasp_xmit()", " - drm/msm/a6xx+: Insert a fence wait before SMMU table update", " - tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink().", " - net: dsa: mv88e6xxx: Fix the max_vid definition for the MV88E6361", " - genetlink: hold RCU in genlmsg_mcast()", " - ravb: Remove setting of RX software timestamp", " - net: ravb: Only advertise Rx/Tx timestamps if hardware supports it", " - net: dsa: vsc73xx: fix reception from VLAN-unaware bridges", " - scsi: target: core: Fix null-ptr-deref in target_alloc_device()", " - smb: client: fix possible double free in smb2_set_ea()", " - smb: client: fix OOBs when building SMB2_IOCTL request", " - usb: typec: altmode should keep reference to parent", " - s390: Initialize psw mask in perf_arch_fetch_caller_regs()", " - drm/xe: fix unbalanced rpm put() with fence_fini()", " - drm/xe: fix unbalanced rpm put() with declare_wedged()", " - drm/xe: Take job list lock in xe_sched_add_pending_job", " - drm/xe: Don't free job in TDR", " - drm/xe: Use bookkeep slots for external BO's in exec IOCTL", " - bpf: Fix link info netfilter flags to populate defrag flag", " - Bluetooth: bnep: fix wild-memory-access in proto_unregister", " - vmxnet3: Fix packet corruption in vmxnet3_xdp_xmit_frame", " - net: ethernet: mtk_eth_soc: fix memory corruption during fq dma init", " - net/mlx5: Check for invalid vector index on EQ creation", " - net/mlx5: Fix command bitmask initialization", " - net/mlx5: Unregister notifier on eswitch init failure", " - net/mlx5e: Don't call cleanup on profile rollback failure", " - bpf, sockmap: SK_DROP on attempted redirects of unsupported af_vsock", " - vsock: Update rx_bytes on read_skb()", " - vsock: Update msg_count on read_skb()", " - bpf, vsock: Drop static vsock_bpf_prot initialization", " - riscv, bpf: Make BPF_CMPXCHG fully ordered", " - nvme-pci: fix race condition between reset and nvme_dev_disable()", " - bpf: Fix iter/task tid filtering", " - bpf: Fix incorrect delta propagation between linked registers", " - bpf: Fix print_reg_state's constant scalar dump", " - cdrom: Avoid barrier_nospec() in cdrom_ioctl_media_changed()", " - fgraph: Allocate ret_stack_list with proper size", " - mm: shmem: rename shmem_is_huge() to shmem_huge_global_enabled()", " - mm: shmem: move shmem_huge_global_enabled() into", " shmem_allowable_huge_orders()", " - mm: huge_memory: add vma_thp_disabled() and thp_disabled_by_hw()", " - mm: don't install PMD mappings when THPs are disabled by the hw/process/vma", " - iio: adc: ti-lmp92064: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - xhci: dbgtty: remove kfifo_out() wrapper", " - xhci: dbgtty: use kfifo from tty_port struct", " - xhci: dbc: honor usb transfer size boundaries.", " - uprobe: avoid out-of-bounds memory access of fetching args", " - drm/vboxvideo: Replace fake VLA at end of vbva_mouse_pointer_shape with real", " VLA", " - ASoC: amd: yc: Add quirk for HP Dragonfly pro one", " - ASoC: codecs: lpass-rx-macro: add missing CDC_RX_BCL_VBAT_RF_PROC2 to", " default regs values", " - ASoC: fsl_sai: Enable 'FIFO continue on error' FCONT bit", " - arm64: Force position-independent veneers", " - udf: refactor udf_current_aext() to handle error", " - udf: refactor udf_next_aext() to handle error", " - udf: refactor inode_bmap() to handle error", " - udf: fix uninit-value use in udf_get_fileshortad", " - ASoC: qcom: sm8250: add qrb4210-rb2-sndcard compatible string", " - fsnotify: Avoid data race between fsnotify_recalc_mask() and", " fsnotify_object_watched()", " - drm/xe/mcr: Use Xe2_LPM steering tables for Xe2_HPM", " - cifs: Validate content of NFS reparse point buffer", " - LoongArch: Don't crash in stack_top() for tasks without vDSO", " - objpool: fix choosing allocation for percpu slots", " - jfs: Fix sanity check in dbMount", " - tracing/probes: Fix MAX_TRACE_ARGS limit handling", " - tracing: Consider the NULL character when validating the event length", " - xfrm: extract dst lookup parameters into a struct", " - xfrm: respect ip protocols rules criteria when performing dst lookups", " - xfrm: validate new SA's prefixlen using SA family when sel.family is unset", " - netfilter: bpf: must hold reference on net namespace", " - net: pse-pd: Fix out of bound for loop", " - net/sun3_82586: fix potential memory leak in sun3_82586_send_packet()", " - be2net: fix potential memory leak in be_xmit()", " - net: plip: fix break; causing plip to never transmit", " - bnxt_en: replace ptp_lock with irqsave variant", " - octeon_ep: Implement helper for iterating packets in Rx queue", " - octeon_ep: Add SKB allocation failures handling in __octep_oq_process_rx()", " - net: dsa: mv88e6xxx: Fix error when setting port policy on mv88e6393x", " - bpf, arm64: Fix address emission with tag-based KASAN enabled", " - fsl/fman: Save device references taken in mac_probe()", " - fsl/fman: Fix refcount handling of fman-related devices", " - net: wwan: fix global oob in wwan_rtnl_policy", " - net: fix races in netdev_tx_sent_queue()/dev_watchdog()", " - virtio_net: fix integer overflow in stats", " - mlxsw: spectrum_router: fix xa_store() error checking", " - net: usb: usbnet: fix name regression", " - bpf: Preserve param->string when parsing mount options", " - bpf: Add MEM_WRITE attribute", " - bpf: Fix overloading of MEM_UNINIT's meaning", " - bpf: Remove MEM_UNINIT from skb/xdp MTU helpers", " - net/sched: act_api: deny mismatched skip_sw/skip_hw flags for actions", " created by classifiers", " - net: sched: fix use-after-free in taprio_change()", " - net: sched: use RCU read-side critical section in taprio_dump()", " - r8169: avoid unsolicited interrupts", " - posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime()", " - Bluetooth: hci_core: Disable works on hci_unregister_dev", " - Bluetooth: SCO: Fix UAF on sco_sock_timeout", " - Bluetooth: ISO: Fix UAF on iso_sock_timeout", " - bpf,perf: Fix perf_event_detach_bpf_prog error handling", " - bpf: fix do_misc_fixups() for bpf_get_branch_snapshot()", " - net: dsa: microchip: disable EEE for KSZ879x/KSZ877x/KSZ876x", " - net: dsa: mv88e6xxx: group cycle counter coefficients", " - net: dsa: mv88e6xxx: read cycle counter period from hardware", " - net: dsa: mv88e6xxx: support 4000ps cycle counter period", " - bpf: Add the missing BPF_LINK_TYPE invocation for sockmap", " - ASoC: dt-bindings: davinci-mcasp: Fix interrupts property", " - ASoC: dt-bindings: davinci-mcasp: Fix interrupt properties", " - ASoC: loongson: Fix component check failed on FDT systems", " - ASoC: topology: Bump minimal topology ABI version", " - ASoC: max98388: Fix missing increment of variable slot_found", " - ASoC: rsnd: Fix probe failure on HiHope boards due to endpoint parsing", " - PCI: Hold rescan lock while adding devices during host probe", " - fs: pass offset and result to backing_file end_write() callback", " - fuse: update inode size after extending passthrough write", " - ASoC: fsl_micfil: Add a flag to distinguish with different volume control", " types", " - ALSA: firewire-lib: Avoid division by zero in apply_constraint_to_size()", " - fbdev: wm8505fb: select CONFIG_FB_IOMEM_FOPS", " - powercap: dtpm_devfreq: Fix error check against dev_pm_qos_add_request()", " - nfsd: cancel nfsd_shrinker_work using sync mode in nfs4_state_shutdown_net", " - ALSA: hda/realtek: Update default depop procedure", " - smb: client: Handle kstrdup failures for passwords", " - cifs: fix warning when destroy 'cifs_io_request_pool'", " - PCI/pwrctl: Add WCN6855 support", " - PCI/pwrctl: Abandon QCom WCN probe on pre-pwrseq device-trees", " - cpufreq: CPPC: fix perf_to_khz/khz_to_perf conversion exception", " - btrfs: qgroup: set a more sane default value for subtree drop threshold", " - btrfs: clear force-compress on remount when compress mount option is given", " - btrfs: fix passing 0 to ERR_PTR in btrfs_search_dir_index_item()", " - perf/x86/rapl: Fix the energy-pkg event for AMD CPUs", " - btrfs: reject ro->rw reconfiguration if there are hard ro requirements", " - btrfs: zoned: fix zone unusable accounting for freed reserved extent", " - btrfs: fix read corruption due to race with extent map merging", " - drm/amd: Guard against bad data for ATIF ACPI method", " - ACPI: resource: Add LG 16T90SP to irq1_level_low_skip_override[]", " - ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context", " - ACPI: button: Add DMI quirk for Samsung Galaxy Book2 to fix initial lid", " detection issue", " - nilfs2: fix kernel bug due to missing clearing of buffer delay flag", " - fs: don't try and remove empty rbtree node", " - xfs: don't fail repairs on metadata files with no attr fork", " - openat2: explicitly return -E2BIG for (usize > PAGE_SIZE)", " - KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory", " - KVM: arm64: Unregister redistributor for failed vCPU creation", " - KVM: arm64: Fix shift-out-of-bounds bug", " - KVM: arm64: Don't eagerly teardown the vgic on init error", " - firewire: core: fix invalid port index for parent device", " - x86/lam: Disable ADDRESS_MASKING in most cases", " - [Config] updateconfigs to disable ADDRESS_MASKING", " - x86/sev: Ensure that RMP table fixups are reserved", " - ALSA: hda/tas2781: select CRC32 instead of CRC32_SARWATE", " - ALSA: hda/realtek: Add subwoofer quirk for Acer Predator G9-593", " - LoongArch: Get correct cores_per_package for SMT systems", " - LoongArch: Enable IRQ if do_ale() triggered in irq-enabled context", " - LoongArch: Make KASAN usable for variable cpu_vabits", " - xfrm: fix one more kernel-infoleak in algo dumping", " - hv_netvsc: Fix VF namespace also in synthetic NIC NETDEV_REGISTER event", " - md/raid10: fix null ptr dereference in raid10_size()", " - drm/bridge: Fix assignment of the of_node of the parent to aux bridge", " - drm/amd/display: Disable PSR-SU on Parade 08-01 TCON too", " - platform/x86/intel/pmc: Fix pmc_core_iounmap to call iounmap for valid", " addresses", " - fgraph: Fix missing unlock in register_ftrace_graph()", " - fgraph: Change the name of cpuhp state to \"fgraph:online\"", " - net: phy: dp83822: Fix reset pin definitions", " - nfsd: fix race between laundromat and free_stateid", " - drm/amd/display: temp w/a for DP Link Layer compliance", " - ata: libata: Set DID_TIME_OUT for commands that actually timed out", " - ASoC: SOF: Intel: hda-loader: do not wait for HDaudio IOC", " - ASoC: SOF: Intel: hda: Handle prepare without close for non-HDA DAI's", " - ASoC: SOF: Intel: hda: Always clean up link DMA during stop", " - ASoC: SOF: ipc4-topology: Do not set ALH node_id for aggregated DAIs", " - ASoC: dapm: avoid container_of() to get component", " - ASoC: qcom: sc7280: Fix missing Soundwire runtime stream alloc", " - ASoC: qcom: sdm845: add missing soundwire runtime stream alloc", " - ASoC: qcom: Fix NULL Dereference in asoc_qcom_lpass_cpu_platform_probe()", " - Revert \" fs/9p: mitigate inode collisions\"", " - Revert \"fs/9p: remove redundant pointer v9ses\"", " - Revert \"fs/9p: fix uaf in in v9fs_stat2inode_dotl\"", " - Revert \"fs/9p: simplify iget to remove unnecessary paths\"", " - soundwire: intel_ace2x: Send PDI stream number during prepare", " - x86: support user address masking instead of non-speculative conditional", " - x86: fix whitespace in runtime-const assembler output", " - x86: fix user address masking non-canonical speculation issue", " - platform/x86: dell-wmi: Ignore suspend notifications", " - ACPI: PRM: Clean up guid type in struct prm_handler_info", " - ASoC: qcom: Select missing common Soundwire module code on SDM845", " - Linux 6.11.6", "", " * ovs/linuxbridge jobs running on ubuntu jammy broken with latest kernel", " 5.15.0-127.137 (LP: #2091990)", " - netfilter: xtables: fix typo causing some targets not to load on IPv6", "", " * By always inlining _compound_head(), clone() sees 3%+ performance increase", " (LP: #2089327)", " - mm: always inline _compound_head() with", " CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP=y", "", " * Keyboard backlight controls do not work on Asus ROG Zephyrus GA503RM in", " Oracular (LP: #2089113)", " - hid-asus: use hid for brightness control on keyboard", "", " * Random flickering with Intel i915 (Comet Lake and Kaby Lake) on Linux 6.8+", " (LP: #2086587)", " - SAUCE: iommu/intel: disable DMAR for KBL and CML integrated gfx", "", " * Add list of source files to linux-buildinfo (LP: #2086606)", " - [Packaging] Sort build dependencies alphabetically", " - [Packaging] Add list of used source files to buildinfo package", "", " * asus: Fix thermal profile initialization on Lunar Lake (LP: #2085950)", " - platform/x86: asus-wmi: Fix thermal profile initialization", "", " * drm/xe: Fix LNL getting wedged after idling (LP: #2085944)", " - drm/xe/guc/ct: Flush g2h worker in case of g2h response timeout", "", " * UFS: uspi->s_3apb UBSAN: shift-out-of-bounds (LP: #2087853)", " - ufs: ufs_sb_private_info: remove unused s_{2, 3}apb fields", "", " * Mute/mic LEDs don't function on HP EliteBook 645 G10 (LP: #2087983)", " - ALSA: hda/realtek: fix mute/micmute LEDs for a HP EliteBook 645 G10", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152)", " - ALSA: scarlett2: Add error check after retrieving PEQ filter values", " - ALSA: hda/conexant - Fix audio routing for HP EliteOne 1000 G2", " - net: enetc: remove xdp_drops statistic from enetc_xdp_drop()", " - net: enetc: block concurrent XDP transmissions during ring reconfiguration", " - net: enetc: disable Tx BD rings after they are empty", " - net: enetc: disable NAPI after all rings are disabled", " - net: enetc: add missing static descriptor and inline keyword", " - udp: Compute L4 checksum as usual when not segmenting the skb", " - arm64: dts: marvell: cn9130-sr-som: fix cp0 mdio pin numbers", " - arm64: probes: Fix simulate_ldr*_literal()", " - net: macb: Avoid 20s boot delay by skipping MDIO bus registration for fixed-", " link PHY", " - selftests: mptcp: join: test for prohibited MPC to port-based endp", " - fat: fix uninitialized variable", " - mm: khugepaged: fix the arguments order in khugepaged_collapse_file trace", " point", " - net: fec: Move `fec_ptp_read()` to the top of the file", " - net: fec: Remove duplicated code", " - mptcp: prevent MPC handshake on port-based signal endpoints", " - s390/sclp: Deactivate sclp after all its users", " - s390/sclp_vt220: Convert newlines to CRLF instead of LFCR", " - KVM: s390: gaccess: Check if guest address is in memslot", " - KVM: s390: Change virtual to physical address access in diag 0x258 handler", " - x86/cpufeatures: Define X86_FEATURE_AMD_IBPB_RET", " - x86/cpufeatures: Add a IBPB_NO_RET BUG flag", " - x86/entry: Have entry_ibpb() invalidate return predictions", " - x86/bugs: Skip RSB fill at VMEXIT", " - x86/bugs: Do not use UNTRAIN_RET with IBPB on entry", " - fgraph: Use CPU hotplug mechanism to initialize idle shadow stacks", " - Input: xpad - add support for 8BitDo Ultimate 2C Wireless Controller", " - io_uring/sqpoll: close race on waiting for sqring entries", " - selftest: hid: add the missing tests directory", " - Input: xpad - add support for MSI Claw A1M", " - scsi: mpi3mr: Validate SAS port assignments", " - scsi: ufs: core: Fix the issue of ICU failure", " - scsi: ufs: core: Requeue aborted request", " - drm/i915/dp_mst: Handle error during DSC BW overhead/slice calculation", " - drm/i915/dp_mst: Don't require DSC hblank quirk for a non-DSC compatible", " mode", " - drm/xe/xe_sync: initialise ufence.signalled", " - drm/xe/ufence: ufence can be signaled right after wait_woken", " - drm/vmwgfx: Cleanup kms setup without 3d", " - drm/vmwgfx: Handle surface check failure correctly", " - drm/amdgpu/mes: fix issue of writing to the same log buffer from 2 MES pipes", " - drm/amdgpu/smu13: always apply the powersave optimization", " - drm/amdgpu/swsmu: Only force workload setup on init", " - drm/amdgpu: prevent BO_HANDLES error from being overwritten", " - iio: dac: ad5770r: add missing select REGMAP_SPI in Kconfig", " - iio: dac: ltc1660: add missing select REGMAP_SPI in Kconfig", " - iio: dac: stm32-dac-core: add missing select REGMAP_MMIO in Kconfig", " - iio: adc: ti-ads8688: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: hid-sensors: Fix an error handling path in", " _hid_sensor_set_report_latency()", " - iio: light: veml6030: fix ALS sensor resolution", " - iio: light: opt3001: add missing full-scale range value", " - iio: amplifiers: ada4250: add missing select REGMAP_SPI in Kconfig", " - iio: frequency: adf4377: add missing select REMAP_SPI in Kconfig", " - iio: chemical: ens160: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: light: bu27008: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: magnetometer: af8133j: add missing select IIO_(TRIGGERED_)BUFFER in", " Kconfig", " - iio: resolver: ad2s1210 add missing select REGMAP in Kconfig", " - iio: pressure: bm1390: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: dac: ad5766: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: proximity: mb1232: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: dac: ad3552r: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: adc: ti-lmp92064: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: adc: ti-lmp92064: add missing select REGMAP_SPI in Kconfig", " - iio: adc: ti-ads124s08: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: resolver: ad2s1210: add missing select (TRIGGERED_)BUFFER in Kconfig", " - iio: adc: ad7944: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: accel: kx022a: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - Bluetooth: Remove debugfs directory on module init failure", " - Bluetooth: btusb: Fix not being able to reconnect after suspend", " - Bluetooth: btusb: Fix regression with fake CSR controllers 0a12:0001", " - xhci: Fix incorrect stream context type macro", " - xhci: Mitigate failed set dequeue pointer commands", " - USB: serial: option: add support for Quectel EG916Q-GL", " - USB: serial: option: add Telit FN920C04 MBIM compositions", " - usb: typec: qcom-pmic-typec: fix sink status being overwritten with RP_DEF", " - usb: gadget: f_uac2: fix return value for UAC2_ATTRIBUTE_STRING store", " - usb: dwc3: Wait for EndXfer completion before restoring GUSB2PHYCFG", " - usb: dwc3: core: Fix system suspend on TI AM62 platforms", " - misc: microchip: pci1xxxx: add support for NVMEM_DEVID_AUTO for EEPROM", " device", " - misc: microchip: pci1xxxx: add support for NVMEM_DEVID_AUTO for OTP device", " - serial: imx: Update mctrl old_status on RTSD interrupt", " - x86/resctrl: Annotate get_mem_config() functions as __init", " - x86/CPU/AMD: Only apply Zenbleed fix for Zen2 during late microcode load", " - x86/entry_32: Do not clobber user EFLAGS.ZF", " - irqchip/sifive-plic: Unmask interrupt in plic_irq_enable()", " - irqchip/sifive-plic: Return error code on failure", " - serial: qcom-geni: fix polled console initialisation", " - serial: qcom-geni: revert broken hibernation support", " - serial: qcom-geni: fix shutdown race", " - serial: qcom-geni: fix dma rx cancellation", " - serial: qcom-geni: fix receiver enable", " - mm: vmscan.c: fix OOM on swap stress test", " - ALSA: hda/conexant - Use cached pin control for Node 0x1d on HP EliteOne", " 1000 G2", " - Linux 6.11.5", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50192", " - irqchip/gic-v4: Don't allow a VMOVP on a dying VPE", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50069", " - pinctrl: apple: check devm_kasprintf() returned value", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50070", " - pinctrl: stm32: check devm_kasprintf() returned value", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50196", " - pinctrl: ocelot: fix system hang on level based interrupts", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50197", " - pinctrl: intel: platform: fix error path in device_for_each_child_node()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50071", " - pinctrl: nuvoton: fix a double free in ma35_pinctrl_dt_node_to_map_func()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50072", " - x86/bugs: Use code segment selector for VERW operand", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50073", " - tty: n_gsm: Fix use-after-free in gsm_cleanup_mux", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50193", " - x86/entry_32: Clear CPU buffers after register restore in NMI return", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50074", " - parport: Proper fix for array out-of-bounds access", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50100", " - USB: gadget: dummy-hcd: Fix \"task hung\" problem", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50075", " - xhci: tegra: fix checked USB2 port number", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50076", " - vt: prevent kernel-infoleak in con_font_get()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50077", " - Bluetooth: ISO: Fix multiple init when debugfs is disabled", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50078", " - Bluetooth: Call iso_exit() on module unload", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50198", " - iio: light: veml6030: fix IIO device retrieval from embedded device", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50201", " - drm/radeon: Fix encoder->possible_clones", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50098", " - scsi: ufs: core: Set SDEV_OFFLINE when UFS is shut down", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50079", " - io_uring/sqpoll: ensure task state is TASK_RUNNING when running task_work", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50080", " - ublk: don't allow user copy for unprivileged device", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50081", " - blk-mq: setup queue ->tag_set before initializing hctx", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50082", " - blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50101", " - iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI devices", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50083", " - tcp: fix mptcp DSS corruption due to large pmtu xmit", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50068", " - mm/damon/tests/sysfs-kunit.h: fix memory leak in", " damon_sysfs_test_add_targets()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50199", " - mm/swapfile: skip HugeTLB pages for unuse_vma", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50066", " - mm/mremap: fix move_normal_pmd/retract_page_tables race", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50202", " - nilfs2: propagate directory read errors from nilfs_find_entry()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50200", " - maple_tree: correct tree corruption on spanning store", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50084", " - net: microchip: vcap api: Fix memory leaks in vcap_api_encode_rule_test()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50194", " - arm64: probes: Fix uprobes for big-endian kernels", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50099", " - arm64: probes: Remove broken LDR (literal) uprobe support", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50195", " - posix-clock: Fix missing timespec64 check in pc_clock_settime()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50085", " - mptcp: pm: fix UaF read in mptcp_pm_nl_rm_addr_or_subflow", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50086", " - ksmbd: fix user-after-free from session log off", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50087", " - btrfs: fix uninitialized pointer free on read_alloc_one_name() error", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50088", " - btrfs: fix uninitialized pointer free in add_inode_ref()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068)", " - net: fec: don't save PTP state if PTP is unsupported", " - fs/ntfs3: Do not call file_modified if collapse range failed", " - fs/ntfs3: Optimize large writes into sparse file", " - fs/ntfs3: Fix sparse warning for bigendian", " - fs/ntfs3: Fix sparse warning in ni_fiemap", " - fs/ntfs3: Refactor enum_rstbl to suppress static checker", " - vdpa/octeon_ep: Fix format specifier for pointers in debug messages", " - virtio_console: fix misc probe bugs", " - perf vdso: Missed put on 32-bit dsos", " - perf build: Fix static compilation error when libdw is not installed", " - perf build: Fix build feature-dwarf_getlocations fail for old libdw", " - zram: don't free statically defined names", " - bpf: Call the missed btf_record_free() when map creation fails", " - selftests/bpf: Fix ARG_PTR_TO_LONG {half-,}uninitialized test", " - bpf: Check percpu map value size first", " - s390/facility: Disable compile time optimization for decompressor code", " - s390/mm: Add cond_resched() to cmm_alloc/free_pages()", " - bpf, x64: Fix a jit convergence issue", " - ext4: nested locking for xattr inode", " - s390/cpum_sf: Remove WARN_ON_ONCE statements", " - s390/traps: Handle early warnings gracefully", " - ktest.pl: Avoid false positives with grub2 skip regex", " - soundwire: intel_bus_common: enable interrupts before exiting reset", " - PCI: Add function 0 DMA alias quirk for Glenfly Arise chip", " - clk: bcm: bcm53573: fix OF node leak in init", " - PCI: Add ACS quirk for Qualcomm SA8775P", " - i2c: i801: Use a different adapter-name for IDF adapters", " - PCI: Mark Creative Labs EMU20k2 INTx masking as broken", " - RISC-V: Don't have MAX_PHYSMEM_BITS exceed phys_addr_t", " - mfd: intel_soc_pmic_chtwc: Make Lenovo Yoga Tab 3 X90F DMI match less strict", " - mfd: intel-lpss: Add Intel Panther Lake LPSS PCI IDs", " - riscv: Omit optimized string routines when using KASAN", " - riscv: avoid Imbalance in RAS", " - RDMA/mlx5: Enforce umem boundaries for explicit ODP page faults", " - PCI: qcom: Disable mirroring of DBI and iATU register space in BAR region", " - PCI: endpoint: Assign PCI domain number for endpoint controllers", " - soundwire: cadence: re-check Peripheral status with delayed_work", " - riscv/kexec_file: Fix relocation type R_RISCV_ADD16 and R_RISCV_SUB16", " unknown", " - media: videobuf2-core: clear memory related fields in", " __vb2_plane_dmabuf_put()", " - remoteproc: imx_rproc: Use imx specific hook for find_loaded_rsc_table", " - usb: chipidea: udc: enable suspend interrupt after usb reset", " - usb: dwc2: Adjust the timing of USB Driver Interrupt Registration in the", " Crashkernel Scenario", " - xhci: dbc: Fix STALL transfer event handling", " - usb: host: xhci-plat: Parse xhci-missing_cas_quirk and apply quirk", " - comedi: ni_routing: tools: Check when the file could not be opened", " - LoongArch: Fix memleak in pci_acpi_scan_root()", " - netfilter: nf_nat: don't try nat source port reallocation for reverse dir", " clash", " - netfilter: nf_reject: Fix build warning when CONFIG_BRIDGE_NETFILTER=n", " - tools/iio: Add memory allocation failure check for trigger_name", " - staging: vme_user: added bound check to geoid", " - driver core: bus: Return -EIO instead of 0 when show/store invalid bus", " attribute", " - scsi: lpfc: Add ELS_RSP cmd to the list of WQEs to flush in", " lpfc_els_flush_cmd()", " - scsi: lpfc: Revise TRACE_EVENT log flag severities from KERN_ERR to", " KERN_WARNING", " - NFSD: Mark filecache \"down\" if init fails", " - nfsd: nfsd_destroy_serv() must call svc_destroy() even if nfsd_startup_net()", " failed", " - ice: set correct dst VSI in only LAN filters", " - ice: clear port vlan config during reset", " - ice: disallow DPLL_PIN_STATE_SELECTABLE for dpll output pins", " - ice: fix VLAN replay after reset", " - SUNRPC: Fix integer overflow in decode_rc_list()", " - net: phy: aquantia: AQR115c fix up PMA capabilities", " - net: phy: aquantia: remove usage of phy_set_max_speed", " - tcp: fix to allow timestamp undo if no retransmits were sent", " - tcp: fix tcp_enter_recovery() to zero retrans_stamp when it's safe", " - tcp: fix TFO SYN_RECV to not zero retrans_stamp with retransmits out", " - rxrpc: Fix uninitialised variable in rxrpc_send_data()", " - net: dsa: sja1105: fix reception from VLAN-unaware bridges", " - selftests: net: no_forwarding: fix VID for $swp2 in one_bridge_two_pvids()", " test", " - net: pse-pd: Fix enabled status mismatch", " - Bluetooth: btusb: Don't fail external suspend requests", " - net: phy: bcm84881: Fix some error handling paths", " - net: ethernet: adi: adin1110: Fix some error handling path in", " adin1110_read_fifo()", " - net: dsa: b53: fix jumbo frame mtu check", " - net: dsa: b53: fix max MTU for 1g switches", " - net: dsa: b53: fix max MTU for BCM5325/BCM5365", " - net: dsa: b53: allow lower MTUs on BCM5325/5365", " - net: dsa: b53: fix jumbo frames on 10/100 ports", " - drm/nouveau: pass cli to nouveau_channel_new() instead of drm+device", " - nouveau/dmem: Fix privileged error in copy engine channel", " - gpio: aspeed: Add the flush write to ensure the write complete.", " - gpio: aspeed: Use devm_clk api to manage clock source", " - x86/xen: mark boot CPU of PV guest in MSR_IA32_APICBASE", " - powercap: intel_rapl_tpmi: Ignore minor version change", " - ice: Fix entering Safe Mode", " - ice: Fix netif_is_ice() in Safe Mode", " - ice: Flush FDB entries before reset", " - drm/xe: Restore GT freq on GSC load error", " - drm/xe: Make wedged_mode debugfs writable", " - net: ibm: emac: mal: fix wrong goto", " - net: ti: icssg-prueth: Fix race condition for VLAN table access", " - btrfs: zoned: fix missing RCU locking in error message when loading zone", " info", " - sctp: ensure sk_state is set to CLOSED if hashing fails in sctp_listen_start", " - netfilter: fib: check correct rtable in vrf setups", " - net: ibm: emac: mal: add dcr_unmap to _remove", " - net: dsa: refuse cross-chip mirroring operations", " - rtnetlink: Add bulk registration helpers for rtnetlink message handlers.", " - vxlan: Handle error of rtnl_register_module().", " - bridge: Handle error of rtnl_register_module().", " - mctp: Handle error of rtnl_register_module().", " - mpls: Handle error of rtnl_register_module().", " - phonet: Handle error of rtnl_register_module().", " - rcu/nocb: Fix rcuog wake-up from offline softirq", " - HID: multitouch: Add support for lenovo Y9000P Touchpad", " - hwmon: intel-m10-bmc-hwmon: relabel Columbiaville to CVL Die Temperature", " - hwmon: (tmp513) Add missing dependency on REGMAP_I2C", " - hwmon: (mc34vr500) Add missing dependency on REGMAP_I2C", " - hwmon: (adm9240) Add missing dependency on REGMAP_I2C", " - hwmon: (adt7470) Add missing dependency on REGMAP_I2C", " - hwmon: (ltc2991) Add missing dependency on REGMAP_I2C", " - HID: plantronics: Workaround for an unexcepted opposite volume key", " - HID: wacom: Hardcode (non-inverted) AES pens as BTN_TOOL_PEN", " - Revert \"usb: yurex: Replace snprintf() with the safer scnprintf() variant\"", " - usb: dwc3: core: Stop processing of pending events if controller is halted", " - usb: xhci: Fix problem with xhci resume from suspend", " - usb: storage: ignore bogus device raised by JieLi BR21 USB sound chip", " - usb: dwc3: re-enable runtime PM after failed resume", " - usb: gadget: core: force synchronous registration", " - hid: intel-ish-hid: Fix uninitialized variable 'rv' in", " ish_fw_xfer_direct_dma", " - ACPI: resource: Make Asus ExpertBook B2402 matches cover more models", " - ACPI: resource: Make Asus ExpertBook B2502 matches cover more models", " - drm/amdgpu: partially revert powerplay `__counted_by` changes", " - drm/amd/display: Clear update flags after update has been applied", " - drm/amdkfd: Fix an eviction fence leak", " - drm/amd/display: fix hibernate entry for DCN35+", " - drm/xe/guc_submit: fix xa_store() error checking", " - drm/i915/hdcp: fix connector refcounting", " - drm/xe/ct: fix xa_store() error checking", " - scsi: ufs: Use pre-calculated offsets in ufshcd_init_lrb()", " - Revert \"mmc: mvsdio: Use sg_miter for PIO\"", " - mmc: sdhci-of-dwcmshc: Prevent stale command interrupt handling", " - mptcp: fallback when MPTCP opts are dropped after 1st data", " - ata: libata: avoid superfluous disk spin down + spin up during hibernation", " - OPP: fix error code in dev_pm_opp_set_config()", " - net: dsa: lan9303: ensure chip reset and wait for READY status", " - net: phy: realtek: Fix MMD access on RTL8126A-integrated PHY", " - mptcp: pm: do not remove closing subflows", " - powercap: intel_rapl_tpmi: Fix bogus register reading", " - selftests/mm: fix incorrect buffer->mirror size in hmm2 double_map test", " - selftests/rseq: Fix mm_cid test failure", " - btrfs: split remaining space to discard in chunks", " - btrfs: add cancellation points to trim loops", " - PM: domains: Fix alloc/free in dev_pm_domain_attach|detach_list()", " - idpf: use actual mbx receive payload length", " - fs/proc/kcore.c: allow translation of physical memory addresses", " - PCI: Pass domain number to pci_bus_release_domain_nr() explicitly", " - io_uring/rw: fix cflags posting for single issue multishot read", " - Linux 6.11.4", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50182", " - secretmem: disable memfd_secret() if arch cannot set direct map", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50019", " - kthread: unpark only parked kthread", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50096", " - nouveau/dmem: Fix vulnerability in migrate_to_ram upon copy error", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50020", " - ice: Fix improper handling of refcount in ice_sriov_set_msix_vec_count()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50021", " - ice: Fix improper handling of refcount in ice_dpll_init_rclk_pins()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50022", " - device-dax: correct pgoff align in dax_set_mapping()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50185", " - mptcp: handle consistently DSS corruption", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50023", " - net: phy: Remove LED entry from LEDs list on unregister", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50024", " - net: Fix an unsafe loop on the list", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50186", " - net: explicitly clear the sk pointer, when pf->create fails", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50025", " - scsi: fnic: Move flush_work initialization out of if block", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50026", " - scsi: wd33c93: Don't use stale scsi_pointer value", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50027", " - thermal: core: Free tzp copy along with the thermal zone", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50028", " - thermal: core: Reference count the zone in thermal_zone_get_by_id()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50029", " - Bluetooth: hci_conn: Fix UAF in hci_enhanced_setup_sync", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50030", " - drm/xe/ct: prevent UAF in send_recv()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50187", " - drm/vc4: Stop the active perfmon before being destroyed", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50031", " - drm/v3d: Stop the active perfmon before being destroyed", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50189", " - HID: amd_sfh: Switch to device-managed dmam_alloc_coherent()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50033", " - slip: make slhc_remember() more robust against malicious packets", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50034", " - net/smc: fix lacks of icsk_syn_mss with IPPROTO_SMC", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50035", " - ppp: fix ppp_async_encode() illegal access", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50036", " - net: do not delay dst_entries_add() in dst_release()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50037", " - drm/fbdev-dma: Only cleanup deferred I/O if necessary", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50092", " - net: netconsole: fix wrong warning", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50038", " - netfilter: xtables: avoid NFPROTO_UNSPEC where needed", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50039", " - net/sched: accept TCA_STAB only for root qdisc", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50040", " - igb: Do not bring the device up after non-fatal error", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50041", " - i40e: Fix macvlan leak by synchronizing access to mac_filter_hash", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50042", " - ice: Fix increasing MSI-X on VF", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50093", " - thermal: intel: int340x: processor: Fix warning during module unload", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50043", " - nfsd: fix possible badness in FREE_STATEID", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50044", " - Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50045", " - netfilter: br_netfilter: fix panic with metadata_dst skb", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50094", " - sfc: Don't invoke xdp_do_flush() from netpoll.", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50188", " - net: phy: dp83869: fix memory corruption when enabling fiber", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50046", " - NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50190", " - ice: fix memleak in ice_init_tx_topology()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50180", " - fbdev: sisfb: Fix strbuf array overflow", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50047", " - smb: client: fix UAF in async decryption", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50048", " - fbcon: Fix a NULL pointer dereference issue in fbcon_putcs", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50049", " - drm/amd/display: Check null pointer before dereferencing se", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50090", " - drm/xe/oa: Fix overflow in oa batch buffer", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50183", " - scsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV", " instance", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50055", " - driver core: bus: Fix double free in driver API bus_register()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50091", " - dm vdo: don't refer to dedupe_context after releasing it", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50056", " - usb: gadget: uvc: Fix ERR_PTR dereference in uvc_v4l2.c", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50184", " - virtio_pmem: Check device status before requesting flush", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50057", " - usb: typec: tipd: Free IRQ only if it was requested before", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50058", " - serial: protect uart_port_dtr_rts() in uart_shutdown() too", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50181", " - clk: imx: Remove CLK_SET_PARENT_GATE for DRAM mux for i.MX7D", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50059", " - ntb: ntb_hw_switchtec: Fix use after free vulnerability in", " switchtec_ntb_remove due to race condition", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50060", " - io_uring: check if we need to reschedule during overflow flush", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50061", " - i3c: master: cdns: Fix use after free vulnerability in cdns_i3c_master", " Driver Due to Race Condition", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50062", " - RDMA/rtrs-srv: Avoid null pointer deref during path establishment", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50095", " - RDMA/mad: Improve handling of timed out WRs of mad agent", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50063", " - bpf: Prevent tail call between progs attached to different hooks", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50191", " - ext4: don't set SB_RDONLY after filesystem errors", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50064", " - zram: free secondary algorithms names", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50065", " - ntfs3: Change to non-blocking allocation in ntfs_d_hash", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50089", " - unicode: Don't special case ignorable code points", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052)", " - jump_label: Fix static_key_slow_dec() yet again", " - scsi: st: Fix input/output error on empty drive reset", " - scsi: pm8001: Do not overwrite PCI queue mapping", " - drm/i915/psr: Do not wait for PSR being idle on on Panel Replay", " - drm/i915/display: BMG supports UHBR13.5", " - drm/i915/dp: Fix AUX IO power enabling for eDP PSR", " - drm/amdgpu: Fix get each xcp macro", " - drm/amd/display: handle nulled pipe context in DCE110's set_drr()", " - ksmbd: fix warning: comparison of distinct pointer types lacks a cast", " - mailbox: ARM_MHU_V3 should depend on ARM64", " - [Config] updateconfigs for ARM_MHU_V3", " - mailbox: rockchip: fix a typo in module autoloading", " - ceph: fix a memory leak on cap_auths in MDS client", " - drm/i915/dp: Fix colorimetry detection", " - ieee802154: Fix build error", " - net: sparx5: Fix invalid timestamps", " - net/mlx5: Added cond_resched() to crdump collection", " - net/mlx5e: SHAMPO, Fix overflow of hd_per_wq", " - netfilter: uapi: NFTA_FLOWTABLE_HOOK is NLA_NESTED", " - net: ieee802154: mcr20a: Use IRQF_NO_AUTOEN flag in request_irq()", " - net: wwan: qcom_bam_dmux: Fix missing pm_runtime_disable()", " - selftests: netfilter: Fix nft_audit.sh for newer nft binaries", " - selftests: netfilter: Add missing return value", " - Bluetooth: btmrvl: Use IRQF_NO_AUTOEN flag in request_irq()", " - afs: Fix missing wire-up of afs_retry_request()", " - net: Add netif_get_gro_max_size helper for GRO", " - net: Fix gso_features_check to check for both dev->gso_{ipv4_,}max_size", " - net: fec: Restart PPS after link state change", " - net: fec: Reload PTP registers after link-state change", " - net: stmmac: dwmac4: extend timeout for VLAN Tag register busy bit check", " - ipv4: ip_gre: Fix drops of small packets in ipgre_xmit", " - netfs: Fix missing wakeup after issuing writes", " - net: phy: realtek: Check the index value in led_hw_control_get", " - bridge: mcast: Fail MDB get request on empty entry", " - iomap: constrain the file range passed to iomap_file_unshare", " - dt-bindings: net: xlnx,axi-ethernet: Add missing reg minItems", " - ASoC: topology: Fix incorrect addressing assignments", " - ASoC: atmel: mchp-pdmc: Skip ALSA restoration if substream runtime is", " uninitialized", " - drm/connector: hdmi: Fix writing Dynamic Range Mastering infoframes", " - io_uring: fix memory leak when cache init fail", " - rust: kbuild: split up helpers.c", " - rust: kbuild: auto generate helper exports", " - rust: mutex: fix __mutex_init() usage in case of PREEMPT_RT", " - ALSA: mixer_oss: Remove some incorrect kfree_const() usages", " - ALSA: hda/realtek: Fix the push button function for the ALC257", " - cifs: Remove intermediate object of failed create reparse call", " - drm/panthor: Lock the VM resv before calling drm_gpuvm_bo_obtain_prealloc()", " - ALSA: hda/generic: Unconditionally prefer preferred_dacs pairs", " - ASoC: imx-card: Set card.owner to avoid a warning calltrace if SND=m", " - drm/xe: Restore pci state upon resume", " - drm/xe: Resume TDR after GT reset", " - cifs: Do not convert delimiter when parsing NFS-style symlinks", " - tools/rtla: Fix installation from out-of-tree build", " - ALSA: gus: Fix some error handling paths related to get_bpos() usage", " - ALSA: hda/conexant: Fix conflicting quirk for System76 Pangolin", " - drm/amd/display: Disable replay if VRR capability is false", " - drm/amd/display: Fix VRR cannot enable", " - drm/amd/display: Re-enable panel replay feature", " - e1000e: avoid failing the system during pm_suspend", " - wifi: ath9k: fix possible integer overflow in ath9k_get_et_stats()", " - crypto: x86/sha256 - Add parentheses around macros' single arguments", " - crypto: octeontx - Fix authenc setkey", " - crypto: octeontx2 - Fix authenc setkey", " - ice: Adjust over allocation of memory in ice_sched_add_root_node() and", " ice_sched_add_node()", " - wifi: iwlwifi: mvm: Fix a race in scan abort flow", " - wifi: iwlwifi: mvm: drop wrong STA selection in TX", " - net: hisilicon: hip04: fix OF node leak in probe()", " - net: hisilicon: hns_dsaf_mac: fix OF node leak in hns_mac_get_info()", " - net: hisilicon: hns_mdio: fix OF node leak in probe()", " - ACPICA: Fix memory leak if acpi_ps_get_next_namepath() fails", " - ACPICA: Fix memory leak if acpi_ps_get_next_field() fails", " - ACPI: resource: Skip IRQ override on Asus Vivobook Go E1404GAB", " - wifi: mt76: mt7915: disable tx worker during tx BA session enable/disable", " - net: sched: consistently use rcu_replace_pointer() in taprio_change()", " - Bluetooth: btusb: Add Realtek RTL8852C support ID 0x0489:0xe122", " - Bluetooth: btrtl: Set msft ext address filter quirk for RTL8852B", " - ACPI: video: Add force_vendor quirk for Panasonic Toughbook CF-18", " - ACPI: CPPC: Add support for setting EPP register in FFH", " - wifi: rtw88: select WANT_DEV_COREDUMP", " - l2tp: free sessions using rcu", " - l2tp: use rcu list add/del when updating lists", " - ACPI: EC: Do not release locks during operation region accesses", " - net: skbuff: sprinkle more __GFP_NOWARN on ingress allocs", " - net: mvpp2: Increase size of queue_name buffer", " - bnxt_en: Extend maximum length of version string by 1 byte", " - ipv4: Check !in_dev earlier for ioctl(SIOCSIFADDR).", " - wifi: rtw89: correct base HT rate mask for firmware", " - netfilter: nf_tables: do not remove elements if set backend implements", " .abort", " - ipv4: Mask upper DSCP bits and ECN bits in NETLINK_FIB_LOOKUP family", " - nvme-keyring: restrict match length for version '1' identifiers", " - nvme-tcp: sanitize TLS key handling", " - nvme-tcp: check for invalidated or revoked key", " - net: atlantic: Avoid warning about potential string truncation", " - crypto: simd - Do not call crypto_alloc_tfm during registration", " - netpoll: Ensure clean state on setup failures", " - tcp: avoid reusing FIN_WAIT2 when trying to find port in connect() process", " - wifi: iwlwifi: mvm: use correct key iteration", " - wifi: iwlwifi: allow only CN mcc from WRDD", " - virt: sev-guest: Ensure the SNP guest messages do not exceed a page", " - wifi: mac80211: fix RCU list iterations", " - ACPICA: iasl: handle empty connection_node", " - proc: add config & param to block forcing mem writes", " - [Config] updateconfigs to select PROC_MEM_ALWAYS_FORCE", " - vfs: use RCU in ilookup", " - drivers/perf: arm_spe: Use perf_allow_kernel() for permissions", " - nvme: fix metadata handling in nvme-passthrough", " - can: netlink: avoid call to do_set_data_bittiming callback with stale", " can_priv::ctrlmode", " - netdev-genl: Set extack and fix error on napi-get", " - wifi: wilc1000: Do not operate uninitialized hardware during suspend/resume", " - arm64: trans_pgd: mark PTEs entries as valid to avoid dead kexec()", " - net: phy: Check for read errors in SIOCGMIIREG", " - x86/bugs: Add missing NO_SSB flag", " - x86/bugs: Fix handling when SRSO mitigation is disabled", " - crypto: hisilicon - fix missed error branch", " - wifi: mt76: mt7915: add dummy HW offload of IEEE 802.11 fragmentation", " - wifi: mt76: mt7915: hold dev->mt76.mutex while disabling tx worker", " - netfs: Cancel dirty folios that have no storage destination", " - nfp: Use IRQF_NO_AUTOEN flag in request_irq()", " - ALSA: usb-audio: Add input value sanity checks for standard types", " - x86/apic: Remove logical destination mode for 64-bit", " - ALSA: usb-audio: Define macros for quirk table entries", " - ALSA: usb-audio: Replace complex quirk lines with macros", " - ALSA: usb-audio: Add quirk for RME Digiface USB", " - ALSA: usb-audio: Add mixer quirk for RME Digiface USB", " - ALSA: hda/realtek: Refactor and simplify Samsung Galaxy Book init", " - ALSA: usb-audio: Add logitech Audio profile quirk", " - ASoC: codecs: wsa883x: Handle reading version failure", " - ALSA: control: Take power_ref lock primarily", " - tools/x86/kcpuid: Protect against faulty \"max subleaf\" values", " - x86/pkeys: Add PKRU as a parameter in signal handling functions", " - x86/pkeys: Restore altstack access in sigreturn()", " - x86/kexec: Add EFI config table identity mapping for kexec kernel", " - ALSA: hdsp: Break infinite MIDI input flush loop", " - tools/nolibc: powerpc: limit stack-protector workaround to GCC", " - selftests/nolibc: avoid passing NULL to printf(\"%s\")", " - x86/syscall: Avoid memcpy() for ia32 syscall_get_arguments()", " - ASoC: Intel: boards: always check the result of", " acpi_dev_get_first_match_dev()", " - hwmon: (nct6775) add G15CF to ASUS WMI monitoring list", " - pmdomain: core: Don't hold the genpd-lock when calling dev_pm_domain_set()", " - pmdomain: core: Use dev_name() instead of kobject_get_path() in debugfs", " - rcuscale: Provide clear error when async specified without primitives", " - power: reset: brcmstb: Do not go into infinite loop if reset fails", " - iommu/arm-smmu-v3: Match Stall behaviour for S2", " - iommu/vt-d: Always reserve a domain ID for identity setup", " - iommu/vt-d: Unconditionally flush device TLB for pasid table updates", " - iommu/arm-smmu-v3: Do not use devm for the cd table allocations", " - drm/amdgpu: disallow multiple BO_HANDLES chunks in one submit", " - drm/amd/display: Use gpuvm_min_page_size_kbytes for DML2 surfaces", " - ata: pata_serverworks: Do not use the term blacklist", " - ata: sata_sil: Rename sil_blacklist to sil_quirks", " - selftests/bpf: fix uprobe.path leak in bpf_testmod", " - scsi: smartpqi: Add new controller PCI IDs", " - HID: Ignore battery for all ELAN I2C-HID devices", " - drm/amd/display: Underflow Seen on DCN401 eGPU", " - drm/xe: Name and document Wa_14019789679", " - jfs: UBSAN: shift-out-of-bounds in dbFindBits", " - scsi: smartpqi: correct stream detection", " - scsi: smartpqi: add new controller PCI IDs", " - drm/amdgpu: add raven1 gfxoff quirk", " - drm/amdgpu: enable gfxoff quirk on HP 705G4", " - drm/amdkfd: Fix resource leak in criu restore queue", " - HID: multitouch: Add support for Thinkpad X12 Gen 2 Kbd Portfolio", " - platform/x86: touchscreen_dmi: add nanote-next quirk", " - platform/x86/amd: pmf: Add quirk for TUF Gaming A14", " - drm/stm: ltdc: reset plane transparency after plane disable", " - drm/amdgpu/gfx12: properly handle error ints on all pipes", " - drm/amdgpu/gfx9: properly handle error ints on all pipes", " - drm/amd/display: Fix possible overflow in integer multiplication", " - drm/printer: Allow NULL data in devcoredump printer", " - perf,x86: avoid missing caller address in stack traces captured in uprobe", " - scsi: aacraid: Rearrange order of struct aac_srb_unit", " - scsi: lpfc: Fix unsolicited FLOGI kref imbalance when in direct attached", " topology", " - scsi: lpfc: Update PRLO handling in direct attached topology", " - drm/amd/display: Force enable 3DLUT DMA check for dcn401 in DML", " - drm/amdgpu: fix unchecked return value warning for amdgpu_gfx", " - drm/amdgpu: fix unchecked return value warning for amdgpu_atombios", " - perf: Fix event_function_call() locking", " - scsi: NCR5380: Initialize buffer for MSG IN and STATUS transfers", " - drm/radeon/r100: Handle unknown family in r100_cp_init_microcode()", " - drm/amd/display: Unlock Pipes Based On DET Allocation", " - drm/amdgpu: fix ptr check warning in gfx9 ip_dump", " - drm/amdgpu: fix ptr check warning in gfx10 ip_dump", " - drm/amdgpu: fix ptr check warning in gfx11 ip_dump", " - drm/amdgpu: Block MMR_READ IOCTL in reset", " - drm/amdgpu/gfx9: use rlc safe mode for soft recovery", " - drm/amdgpu/gfx11: enter safe mode before touching CP_INT_CNTL", " - drm/xe: Use topology to determine page fault queue size", " - drm/amdkfd: Check int source id for utcl2 poison event", " - of/irq: Refer to actual buffer size in of_irq_parse_one()", " - drm/amd/display: guard write a 0 post_divider value to HW", " - powerpc/pseries: Use correct data types from pseries_hp_errorlog struct", " - ovl: fsync after metadata copy-up", " - drm/amdgpu/gfx12: use rlc safe mode for soft recovery", " - drm/amdgpu/gfx11: use rlc safe mode for soft recovery", " - drm/amdgpu/gfx10: use rlc safe mode for soft recovery", " - platform/x86: lenovo-ymc: Ignore the 0x0 state", " - tools/hv: Add memory allocation check in hv_fcopy_start", " - HID: i2c-hid: ensure various commands do not interfere with each other", " - platform/mellanox: mlxbf-pmc: fix lockdep warning", " - platform/x86: x86-android-tablets: Adjust Xiaomi Pad 2 bottom bezel touch", " buttons LED", " - bpf: Make the pointer returned by iter next method valid", " - ext4: ext4_search_dir should return a proper error", " - bpftool: Fix undefined behavior caused by shifting into the sign bit", " - iomap: handle a post-direct I/O invalidate race in", " iomap_write_delalloc_release", " - EINJ, CXL: Fix CXL device SBDF calculation", " - spi: spi-imx: Fix pm_runtime_set_suspended() with runtime pm enabled", " - spi: spi-cadence: Fix pm_runtime_set_suspended() with runtime pm enabled", " - spi: spi-cadence: Fix missing spi_controller_is_target() check", " - selftest: hid: add missing run-hid-tools-tests.sh", " - spi: s3c64xx: fix timeout counters in flush_fifo", " - kselftest/devices/probe: Fix SyntaxWarning in regex strings for Python3", " - selftests: breakpoints: use remaining time to check if suspend succeed", " - accel/ivpu: Add missing MODULE_FIRMWARE metadata", " - spi: rpc-if: Add missing MODULE_DEVICE_TABLE", " - ALSA: control: Fix power_ref lock order for compat code, too", " - perf callchain: Fix stitch LBR memory leaks", " - perf: Really fix event_function_call() locking", " - drm/xe: fixup xe_alloc_pf_queue", " - drm/xe: Fix memory leak on xe_alloc_pf_queue failure", " - selftests: vDSO: fix vDSO name for powerpc", " - selftests: vDSO: fix vdso_config for powerpc", " - selftests: vDSO: fix vDSO symbols lookup for powerpc64", " - ext4: fix error message when rejecting the default hash", " - selftests/mm: fix charge_reserved_hugetlb.sh test", " - nvme-tcp: fix link failure for TCP auth", " - f2fs: add write priority option based on zone UFS", " - powerpc/vdso: Fix VDSO data access when running in a non-root time namespace", " - selftests: vDSO: fix ELF hash table entry size for s390x", " - selftests: vDSO: fix vdso_config for s390", " - f2fs: make BG GC more aggressive for zoned devices", " - f2fs: introduce migration_window_granularity", " - f2fs: increase BG GC migration window granularity when boosted for zoned", " devices", " - f2fs: do FG_GC when GC boosting is required for zoned devices", " - f2fs: forcibly migrate to secure space for zoned device file pinning", " - Revert \"ALSA: hda: Conditionally use snooping for AMD HDMI\"", " - KVM: arm64: Fix kvm_has_feat*() handling of negative features", " - i2c: qcom-geni: Use IRQF_NO_AUTOEN flag in request_irq()", " - i2c: xiic: Wait for TX empty to avoid missed TX NAKs", " - i2c: core: Lock address during client device instantiation", " - i2c: xiic: Fix pm_runtime_set_suspended() with runtime pm enabled", " - i2c: designware: fix controller is holding SCL low while ENABLE bit is", " disabled", " - i2c: synquacer: Deal with optional PCLK correctly", " - rust: sync: require `T: Sync` for `LockedBy::access`", " - ovl: fail if trusted xattrs are needed but caller lacks permission", " - firmware: tegra: bpmp: Drop unused mbox_client_to_bpmp()", " - memory: tegra186-emc: drop unused to_tegra186_emc()", " - dt-bindings: clock: exynos7885: Fix duplicated binding", " - spi: bcm63xx: Fix module autoloading", " - spi: bcm63xx: Fix missing pm_runtime_disable()", " - power: supply: hwmon: Fix missing temp1_max_alarm attribute", " - power: supply: Drop use_cnt check from power_supply_property_is_writeable()", " - perf/core: Fix small negative period being ignored", " - drm/v3d: Prevent out of bounds access in performance query extensions", " - parisc: Fix itlb miss handler for 64-bit programs", " - drm/mediatek: ovl_adaptor: Add missing of_node_put()", " - drm: Consistently use struct drm_mode_rect for FB_DAMAGE_CLIPS", " - ALSA: hda/tas2781: Add new quirk for Lenovo Y990 Laptop", " - ALSA: core: add isascii() check to card ID generator", " - ALSA: usb-audio: Add delay quirk for VIVO USB-C HEADSET", " - ALSA: usb-audio: Add native DSD support for Luxman D-08u", " - ALSA: line6: add hw monitor volume control to POD HD500X", " - ALSA: hda/realtek: fix mute/micmute LED for HP mt645 G8", " - ALSA: hda/realtek: Add quirk for Huawei MateBook 13 KLV-WX9", " - ALSA: hda/realtek: Add a quirk for HP Pavilion 15z-ec200", " - ext4: correct encrypted dentry name hash when not casefolded", " - ext4: propagate errors from ext4_find_extent() in ext4_insert_range()", " - ext4: fix incorrect tid assumption in ext4_fc_mark_ineligible()", " - ext4: fix incorrect tid assumption in __jbd2_log_wait_for_space()", " - ext4: fix incorrect tid assumption in ext4_wait_for_tail_page_commit()", " - ext4: fix incorrect tid assumption in jbd2_journal_shrink_checkpoint_list()", " - ext4: fix fast commit inode enqueueing during a full journal commit", " - ext4: use handle to mark fc as ineligible in __track_dentry_update()", " - ext4: mark fc as ineligible using an handle in ext4_xattr_set()", " - parisc: Fix 64-bit userspace syscall path", " - parisc: Allow mmap(MAP_STACK) memory to automatically expand upwards", " - parisc: Fix stack start for ADDR_NO_RANDOMIZE personality", " - drm/rockchip: vop: clear DMA stop bit on RK3066", " - of: address: Report error on resource bounds overflow", " - of/irq: Support #msi-cells=<0> in of_msi_get_domain", " - lib/buildid: harden build ID parsing logic", " - jbd2: correctly compare tids with tid_geq function in jbd2_fc_begin_commit", " - mm: krealloc: consider spare memory for __GFP_ZERO", " - ocfs2: fix the la space leak when unmounting an ocfs2 volume", " - ocfs2: fix uninit-value in ocfs2_get_block()", " - scripts/gdb: fix timerlist parsing issue", " - scripts/gdb: add iteration function for rbtree", " - scripts/gdb: fix lx-mounts command error", " - arm64: fix selection of HAVE_DYNAMIC_FTRACE_WITH_ARGS", " - arm64: Subscribe Microsoft Azure Cobalt 100 to erratum 3194386", " - drm/xe/oa: Don't reset OAC_CONTEXT_ENABLE on OA stream close", " - sched/deadline: Comment sched_dl_entity::dl_server variable", " - sched/core: Add clearing of ->dl_server in put_prev_task_balance()", " - sched/core: Clear prev->dl_server in CFS pick fast path", " - sched: psi: fix bogus pressure spikes from aggregation race", " - riscv: define ILLEGAL_POINTER_VALUE for 64bit", " - [Config] updateconfigs for ILLEGAL_POINTER_VALUE on riscv", " - perf python: Disable -Wno-cast-function-type-mismatch if present on clang", " - perf hist: Update hist symbol when updating maps", " - nfsd: fix delegation_blocked() to block correctly for at least 30 seconds", " - NFSD: Fix NFSv4's PUTPUBFH operation", " - sysctl: avoid spurious permanent empty tables", " - RDMA/mana_ib: use the correct page table index based on hardware page size", " - RDMA/mana_ib: use the correct page size for mapping user-mode doorbell page", " - drivers/perf: riscv: Align errno for unsupported perf event", " - riscv: Fix kernel stack size when KASAN is enabled", " - media: imx335: Fix reset-gpio handling", " - clk: rockchip: fix error for unknown clocks", " - leds: pca9532: Remove irrelevant blink configuration error message", " - media: videobuf2: Drop minimum allocation requirement of 2 buffers", " - clk: qcom: dispcc-sm8250: use CLK_SET_RATE_PARENT for branch clocks", " - media: sun4i_csi: Implement link validate for sun4i_csi subdev", " - clk: qcom: gcc-sm8450: Do not turn off PCIe GDSCs during gdsc_disable()", " - media: uapi/linux/cec.h: cec_msg_set_reply_to: zero flags", " - dt-bindings: clock: qcom: Add GPLL9 support on gcc-sc8180x", " - clk: qcom: gcc-sc8180x: Register QUPv3 RCGs for DFS on sc8180x", " - clk: qcom: clk-rpmh: Fix overflow in BCM vote", " - clk: samsung: exynos7885: Update CLKS_NR_FSYS after bindings fix", " - clk: qcom: gcc-sm8150: De-register gcc_cpuss_ahb_clk_src", " - clk: qcom: gcc-sm8250: Do not turn off PCIe GDSCs during gdsc_disable()", " - clk: qcom: gcc-sc8180x: Add GPLL9 support", " - clk: qcom: gcc-sc8180x: Fix the sdcc2 and sdcc4 clocks freq table", " - clk: qcom: clk-alpha-pll: Fix CAL_L_VAL override for LUCID EVO PLL", " - drm/amd/display: avoid set dispclk to 0", " - smb: client: use actual path when queryfs", " - smb3: fix incorrect mode displayed for read-only files", " - iio: magnetometer: ak8975: Fix reading for ak099xx sensors", " - iio: pressure: bmp280: Fix regmap for BMP280 device", " - iio: pressure: bmp280: Fix waiting time for BMP3xx configuration", " - tomoyo: fallback to realpath if symlink's pathname does not exist", " - kselftests: mm: fix wrong __NR_userfaultfd value", " - rtc: at91sam9: fix OF node leak in probe() error path", " - mm/hugetlb: fix memfd_pin_folios resv_huge_pages leak", " - mm/gup: fix memfd_pin_folios hugetlb page allocation", " - mm/hugetlb: simplify refs in memfd_alloc_folio", " - Input: adp5589-keys - fix adp5589_gpio_get_value()", " - HID: bpf: fix cfi stubs for hid_bpf_ops", " - pidfs: check for valid pid namespace", " - ACPI: video: Add backlight=native quirk for Dell OptiPlex 5480 AIO", " - ACPI: resource: Remove duplicate Asus E1504GAB IRQ override", " - ACPI: resource: Loosen the Asus E1404GAB DMI match to also cover the E1404GA", " - ACPI: resource: Add Asus Vivobook X1704VAP to irq1_level_low_skip_override[]", " - ACPI: resource: Add Asus ExpertBook B2502CVA to", " irq1_level_low_skip_override[]", " - btrfs: drop the backref cache during relocation if we commit", " - btrfs: send: fix invalid clone operation for file that got its size", " decreased", " - cpufreq: intel_pstate: Make hwp_notify_lock a raw spinlock", " - gpio: davinci: fix lazy disable", " - net: pcs: xpcs: fix the wrong register that was written back", " - Bluetooth: hci_event: Align BR/EDR JUST_WORKS paring with LE", " - io_uring/net: harden multishot termination case for recv", " - ceph: fix cap ref leak via netfs init_request", " - tracing/hwlat: Fix a race during cpuhp processing", " - tracing/timerlat: Fix duplicated kthread creation due to CPU online/offline", " - rtla: Fix the help text in osnoise and timerlat top tools", " - firmware/sysfb: Disable sysfb for firmware buffers with unknown parent", " - close_range(): fix the logics in descriptor table trimming", " - drm/i915/gem: fix bitwise and logical AND mixup", " - drm/panthor: Don't add write fences to the shared BOs", " - drm/panthor: Don't declare a queue blocked if deferred operations are", " pending", " - drm/sched: Fix dynamic job-flow control race", " - drm/sched: Add locking to drm_sched_entity_modify_sched", " - drm/sched: Always wake up correct scheduler in drm_sched_entity_push_job", " - drm/sched: Always increment correct scheduler score", " - drm/amd/display: Restore Optimized pbn Value if Failed to Disable DSC", " - drm/amd/display: Add HDR workaround for specific eDP", " - drm/amd/display: Enable idle workqueue for more IPS modes", " - kconfig: fix infinite loop in sym_calc_choice()", " - kconfig: qconf: move conf_read() before drawing tree pain", " - kconfig: qconf: fix buffer overflow in debug links", " - arm64: cputype: Add Neoverse-N3 definitions", " - arm64: errata: Expand speculative SSBS workaround once more", " - mm: z3fold: deprecate CONFIG_Z3FOLD", " - [Config] updateconfigs after deprecating Z3FOLD", " - drm/amd/display: Allow backlight to go below", " `AMDGPU_DM_DEFAULT_MIN_BACKLIGHT`", " - sunrpc: change sp_nrthreads from atomic_t to unsigned int.", " - NFSD: Async COPY result needs to return a write verifier", " - remoteproc: k3-r5: Acquire mailbox handle during probe routine", " - remoteproc: k3-r5: Delay notification of wakeup event", " - r8169: Fix spelling mistake: \"tx_underun\" -> \"tx_underrun\"", " - ACPI: battery: Simplify battery hook locking", " - drm/xe: Clean up VM / exec queue file lock usage.", " - drm/rockchip: vop: enable VOP_FEATURE_INTERNAL_RGB on RK3066", " - drm/xe/vram: fix ccs offset calculation", " - drm/sched: revert \"Always increment correct scheduler score\"", " - ALSA: control: Fix leftover snd_power_unref()", " - crypto: octeontx* - Select CRYPTO_AUTHENC", " - drm/amd/display: Revert Avoid overflow assignment", " - perf report: Fix segfault when 'sym' sort key is not used", " - pmdomain: core: Reduce debug summary table width", " - perf python: Allow checking for the existence of warning options in clang", " - Linux 6.11.3", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49863", " - vhost/scsi: null-ptr-dereference in vhost_scsi_get_req()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49864", " - rxrpc: Fix a race between socket set up and I/O thread creation", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49865", " - drm/xe/vm: move xa_alloc to prevent UAF", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49955", " - ACPI: battery: Fix possible crash when unregistering a battery hook", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49973", " - r8169: add tally counter fields added with RTL8125", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49974", " - NFSD: Limit the number of concurrent async COPY operations", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49975", " - uprobes: fix kernel info leak via \"[uprobes]\" vma", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50003", " - drm/amd/display: Fix system hang while resume with TBT monitor", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50173", " - drm/panthor: Fix access to uninitialized variable in tick_ctx_cleanup()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49866", " - tracing/timerlat: Fix a race during cpuhp processing", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49976", " - tracing/timerlat: Drop interface_lock in stop_kthread()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50005", " - mac802154: Fix potential RCU dereference issue in mac802154_scan_worker", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50012", " - cpufreq: Avoid a bad reference count on CPU node", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49867", " - btrfs: wait for fixup workers before stopping cleaner kthread during umount", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49868", " - btrfs: fix a NULL pointer dereference when failed to start a new trasacntion", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49869", " - btrfs: send: fix buffer overflow detection when copying path to cache entry", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49870", " - cachefiles: fix dentry leak in cachefiles_open_file()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49871", " - Input: adp5589-keys - fix NULL pointer dereference", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49872", " - mm/gup: fix memfd_pin_folios alloc race panic", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49964", " - mm/hugetlb: fix memfd_pin_folios free_huge_pages leak", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49873", " - mm/filemap: fix filemap_get_folios_contig THP panic", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49977", " - net: stmmac: Fix zero-division error when disabling tc cbs", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49978", " - gso: fix udp gso fraglist segmentation after pull from frag_list", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49979", " - net: gso: fix tcp fraglist segmentation after pull from frag_list", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49980", " - vrf: revert \"vrf: Remove unnecessary RCU-bh critical section\"", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49981", " - media: venus: fix use after free bug in venus_remove due to race condition", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49956", " - gfs2: fix double destroy_workqueue error", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50176", " - remoteproc: k3-r5: Fix error handling when power-up failed", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49982", " - aoe: fix the potential use-after-free problem in more places", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49874", " - i3c: master: svc: Fix use after free vulnerability in svc_i3c_master Driver", " Due to Race Condition", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49875", " - nfsd: map the EBADMSG to nfserr_io to avoid warning", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50013", " - exfat: fix memory leak in exfat_load_bitmap()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49876", " - drm/xe: fix UAF around queue destruction", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49877", " - ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49957", " - ocfs2: fix null-ptr-deref when journal load failed.", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49965", " - ocfs2: remove unreasonable unlock in ocfs2_read_blocks", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49966", " - ocfs2: cancel dqi_sync_work before freeing oinfo", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49958", " - ocfs2: reserve space for inline xattr before attaching reflink tree", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49959", " - jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49878", " - resource: fix region_intersects() vs add_memory_driver_managed()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49879", " - drm: omapdrm: Add missing check for alloc_ordered_workqueue", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49880", " - ext4: fix off by one issue in alloc_flex_gd()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49881", " - ext4: update orig_path in ext4_find_extent()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50014", " - ext4: fix access to uninitialised lock in fc replay path", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49960", " - ext4: fix timer use-after-free on failed mount", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49882", " - ext4: fix double brelse() the buffer of the extents path", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49883", " - ext4: aovid use-after-free in ext4_ext_insert_extent()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49983", " - ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-free", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50015", " - ext4: dax: fix overflowing extents beyond inode size when partially writing", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49884", " - ext4: fix slab-use-after-free in ext4_split_extent_at()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49885", " - mm, slub: avoid zeroing kmalloc redzone", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49961", " - media: i2c: ar0521: Use cansleep version of gpiod_set_value()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49985", " - i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49886", " - platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bug", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49986", " - platform/x86: x86-android-tablets: Fix use after free on", " platform_device_register() errors", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49887", " - f2fs: fix to don't panic system for no free segment fault injection", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49888", " - bpf: Fix a sdiv overflow issue", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49987", " - bpftool: Fix undefined behavior in qsort(NULL, 0, ...)", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50006", " - ext4: fix i_data_sem unlock order in ext4_ind_migrate()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49889", " - ext4: avoid use-after-free in ext4_ext_show_leaf()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49968", " - ext4: filesystems without casefold feature cannot be mounted with siphash", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49988", " - ksmbd: add refcnt to ksmbd_conn struct", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49890", " - drm/amd/pm: ensure the fw_info is not null before using it", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49891", " - scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata", " paths", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49892", " - drm/amd/display: Initialize get_bytes_per_element's default to 1", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50016", " - drm/amd/display: Avoid overflow assignment in link_dp_cts", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49893", " - drm/amd/display: Check stream_status before it is used", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49969", " - drm/amd/display: Fix index out of bounds in DCN30 color transformation", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49970", " - drm/amd/display: Implement bounds check for stream encoder creation in", " DCN401", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49894", " - drm/amd/display: Fix index out of bounds in degamma hardware format", " translation", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49895", " - drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format", " translation", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49971", " - drm/amd/display: Increase array size of dummy_boolean", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49972", " - drm/amd/display: Deallocate DML memory if allocation fails", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49896", " - drm/amd/display: Check stream before comparing them", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49897", " - drm/amd/display: Check phantom_stream before it is used", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49898", " - drm/amd/display: Check null-initialized variables", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49899", " - drm/amd/display: Initialize denominators' default to 1", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49900", " - jfs: Fix uninit-value access of new_ea in ea_buffer", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49901", " - drm/msm/adreno: Assign msm_gpu->pdev earlier to avoid nullptrs", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49902", " - jfs: check if leafidx greater than num leaves per dmap tree", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49903", " - jfs: Fix uaf in dbFreeBits", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49904", " - drm/amdgpu: add list empty check to avoid null pointer issue", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49989", " - drm/amd/display: fix double free issue during amdgpu module unload", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49905", " - drm/amd/display: Add null check for 'afb' in", " amdgpu_dm_plane_handle_cursor_update (v2)", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49906", " - drm/amd/display: Check null pointer before try to access it", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49907", " - drm/amd/display: Check null pointers before using dc->clk_mgr", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49908", " - drm/amd/display: Add null check for 'afb' in amdgpu_dm_update_cursor (v2)", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50177", " - drm/amd/display: fix a UBSAN warning in DML2.1", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49909", " - drm/amd/display: Add NULL check for function pointer in", " dcn32_set_output_transfer_func", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49910", " - drm/amd/display: Add NULL check for function pointer in", " dcn401_set_output_transfer_func", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49911", " - drm/amd/display: Add NULL check for function pointer in", " dcn20_set_output_transfer_func", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49912", " - drm/amd/display: Handle null 'stream_status' in", " 'planes_changed_for_existing_stream'", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49913", " - drm/amd/display: Add null check for top_pipe_to_program in", " commit_planes_for_stream", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49914", " - drm/amd/display: Add null check for pipe_ctx->plane_state in", " dcn20_program_pipe", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49915", " - drm/amd/display: Add NULL check for clk_mgr in dcn32_init_hw", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49916", " - drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in", " dcn401_init_hw", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49917", " - drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in", " dcn30_init_hw", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49918", " - drm/amd/display: Add null check for head_pipe in", " dcn32_acquire_idle_pipe_for_head_pipe_in_layer", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49919", " - drm/amd/display: Add null check for head_pipe in", " dcn201_acquire_free_pipe_for_layer", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49991", " - drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49920", " - drm/amd/display: Check null pointers before multiple uses", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49921", " - drm/amd/display: Check null pointers before used", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49922", " - drm/amd/display: Check null pointers before using them", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49923", " - drm/amd/display: Pass non-null to dcn20_validate_apply_pipe_split_flags", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49992", " - drm/stm: Avoid use-after-free issues with crtc and plane", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49993", " - iommu/vt-d: Fix potential lockup if qi_submit_sync called with 0 count", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49924", " - fbdev: pxafb: Fix possible use after free in pxafb_task()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49925", " - fbdev: efifb: Register sysfs groups through driver core", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49926", " - rcu-tasks: Fix access non-existent percpu rtpcp variable in", " rcu_tasks_need_gpcb()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50007", " - ALSA: asihpi: Fix potential OOB array access", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50017", " - x86/mm/ident_map: Use gbpages only where full GB page should be mapped.", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49927", " - x86/ioapic: Handle allocation failures gracefully", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50008", " - wifi: mwifiex: Fix memcpy() field-spanning write warning in", " mwifiex_cmd_802_11_scan_ext()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50018", " - net: napi: Prevent overflow of napi_defer_hard_irqs", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49928", " - wifi: rtw89: avoid reading out of bounds when loading TX power FW elements", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50178", " - cpufreq: loongson3: Use raw_smp_processor_id() in do_service_request()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50009", " - cpufreq: amd-pstate: add check for cpufreq_cpu_get's return value", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49994", " - block: fix integer overflow in BLKSECDISCARD", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49929", " - wifi: iwlwifi: mvm: avoid NULL pointer dereference", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49995", " - tipc: guard against string buffer overrun", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49962", " - ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in", " acpi_db_convert_to_package()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49930", " - wifi: ath11k: fix array out-of-bound access in SoC stats", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49931", " - wifi: ath12k: fix array out-of-bound access in SoC stats", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49932", " - btrfs: don't readahead the relocation inode on RST", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49933", " - blk_iocost: fix more out of bound shifts", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49934", " - fs/inode: Prevent dump_mapping() accessing invalid dentry.d_name.name", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50010", " - exec: don't WARN for racy path_noexec check", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49935", " - ACPI: PAD: fix crash in exit_round_robin()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49936", " - net/xen-netback: prevent UAF in xenvif_flush_hash()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49937", " - wifi: cfg80211: Set correct chandef when starting CAC", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49938", " - wifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmit", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49939", " - wifi: rtw89: avoid to add interface to list twice when SER", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49940", " - l2tp: prevent possible tunnel refcount underflow", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49941", " - gpiolib: Fix potential NULL pointer dereference in gpiod_get_label()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49996", " - cifs: Fix buffer overflow when parsing NFS reparse points", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49942", " - drm/xe: Prevent null pointer access in xe_migrate_copy", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49943", " - drm/xe/guc_submit: add missing locking in wedged_fini", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50011", " - ASoC: Intel: soc-acpi-intel-rpl-match: add missing empty item", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50174", " - drm/panthor: Fix race when converting group handle to group object", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49944", " - sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_start", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49945", " - net/ncsi: Disable the ncsi work before freeing the associated structure", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49946", " - ppp: do not assume bh is held in ppp_channel_bridge_input()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49947", " - net: test for not too small csum_start in virtio_net_hdr_to_skb()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49948", " - net: add more sanity checks to qdisc_pkt_len_init()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49949", " - net: avoid potential underflow in qdisc_pkt_len_init() with UFO", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49997", " - net: ethernet: lantiq_etop: fix memory disclosure", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49998", " - net: dsa: improve shutdown sequence", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49999", " - afs: Fix the setting of the server responding flag", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49950", " - Bluetooth: L2CAP: Fix uaf in l2cap_connect", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49951", " - Bluetooth: MGMT: Fix possible crash on mgmt_index_removed", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49952", " - netfilter: nf_tables: prevent nf_skb_duplicated corruption", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49953", " - net/mlx5e: Fix crash caused by calling __xfrm_state_delete() twice", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50000", " - net/mlx5e: Fix NULL deref in mlx5e_tir_builder_alloc()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50001", " - net/mlx5: Fix error path in multi-packet WQE transmit", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50179", " - ceph: remove the incorrect Fw reference check when dirtying pages", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49963", " - mailbox: bcm2835: Fix timeout during suspend mode", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49954", " - static_call: Replace pointless WARN_ON() in static_call_module_notify()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50002", " - static_call: Handle module init failure correctly in", " static_call_del_module()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033)", " - EDAC/synopsys: Fix error injection on Zynq UltraScale+", " - crypto: xor - fix template benchmarking", " - crypto: qat - disable IOV in adf_dev_stop()", " - crypto: qat - fix recovery flow for VFs", " - crypto: qat - ensure correct order in VF restarting handler", " - ACPI: PMIC: Remove unneeded check in tps68470_pmic_opregion_probe()", " - eth: fbnic: select DEVLINK and PAGE_POOL", " - wifi: brcmfmac: introducing fwil query functions", " - wifi: ath9k: Remove error checks when creating debugfs entries", " - wifi: ath12k: fix BSS chan info request WMI command", " - wifi: ath12k: match WMI BSS chan info structure with firmware definition", " - wifi: ath12k: fix invalid AMPDU factor calculation in", " ath12k_peer_assoc_h_he()", " - hwrng: cn10k - Enable by default CN10K driver if Thunder SoC is enabled", " - crypto: x86/aes-gcm - fix PREEMPT_RT issue in gcm_crypt()", " - net: stmmac: dwmac-loongson: Init ref and PTP clocks rate", " - virtio: rename virtio_config_enabled to virtio_config_core_enabled", " - virtio: allow driver to disable the configure change notification", " - virtio-net: synchronize operstate with admin state on up/down", " - virtio-net: synchronize probe with ndo_set_features", " - arm64: signal: Fix some under-bracketed UAPI macros", " - wifi: rtw88: remove CPT execution branch never used", " - RISC-V: KVM: Fix sbiret init before forwarding to userspace", " - RISC-V: KVM: Allow legacy PMU access from guest", " - RISC-V: KVM: Fix to allow hpmcounter31 from the guest", " - mount: handle OOM on mnt_warn_timestamp_expiry", " - autofs: fix missing fput for FSCONFIG_SET_FD", " - netfilter: nf_tables: store new sets in dedicated list", " - wifi: rtw89: limit the PPDU length for VHT rate to 0x40000", " - kselftest/arm64: signal: fix/refactor SVE vector length enumeration", " - arm64: smp: smp_send_stop() and crash_smp_send_stop() should try non-NMI", " first", " - thermal: core: Fold two functions into their respective callers", " - thermal: core: Fix rounding of delay jiffies", " - perf/dwc_pcie: Fix registration issue in multi PCIe controller instances", " - perf/dwc_pcie: Always register for PCIe bus notifier", " - crypto: qat - fix \"Full Going True\" macro definition", " - ACPI: video: force native for Apple MacbookPro9,2", " - wifi: mac80211_hwsim: correct MODULE_PARM_DESC of multi_radio", " - wifi: iwlwifi: config: label 'gl' devices as discrete", " - wifi: iwlwifi: mvm: increase the time between ranging measurements", " - wifi: cfg80211: fix bug of mapping AF3x to incorrect User Priority", " - wifi: mac80211: fix the comeback long retry times", " - wifi: iwlwifi: mvm: allow ESR when we the ROC expires", " - wifi: mac80211: Check for missing VHT elements only for 5 GHz", " - ACPICA: Implement ACPI_WARNING_ONCE and ACPI_ERROR_ONCE", " - ACPICA: executer/exsystem: Don't nag user about every Stall() violating the", " spec", " - padata: Honor the caller's alignment in case of chunk_size 0", " - drivers/perf: hisi_pcie: Record hardware counts correctly", " - drivers/perf: hisi_pcie: Fix TLP headers bandwidth counting", " - kselftest/arm64: Actually test SME vector length changes via sigreturn", " - can: j1939: use correct function name in comment", " - wifi: rtw89: wow: fix wait condition for AOAC report request", " - ACPI: CPPC: Fix MASK_VAL() usage", " - netfilter: nf_tables: elements with timeout below CONFIG_HZ never expire", " - netfilter: nf_tables: reject element expiration with no timeout", " - netfilter: nf_tables: reject expiration higher than timeout", " - netfilter: nf_tables: remove annotation to access set timeout while holding", " lock", " - netfilter: nft_dynset: annotate data-races around set timeout", " - perf/arm-cmn: Refactor node ID handling. Again.", " - perf/arm-cmn: Fix CCLA register offset", " - perf/arm-cmn: Ensure dtm_idx is big enough", " - cpufreq: ti-cpufreq: Introduce quirks to handle syscon fails appropriately", " - thermal: gov_bang_bang: Adjust states of all uninitialized instances", " - wifi: mt76: mt7921: fix wrong UNII-4 freq range check for the channel usage", " - wifi: mt76: mt7996: fix traffic delay when switching back to working channel", " - wifi: mt76: mt7996: fix wmm set of station interface to 3", " - wifi: mt76: mt7996: fix HE and EHT beamforming capabilities", " - wifi: mt76: mt7996: fix EHT beamforming capability check", " - pm:cpupower: Add missing powercap_set_enabled() stub function", " - crypto: ccp - do not request interrupt on cmd completion when irqs disabled", " - crypto: hisilicon/hpre - mask cluster timeout error", " - crypto: hisilicon/qm - reset device before enabling it", " - wifi: mt76: mt7996: fix handling mbss enable/disable", " - wifi: mt76: connac: fix checksum offload fields of connac3 RXD", " - wifi: mt76: mt7603: fix mixed declarations and code", " - wifi: cfg80211: fix UBSAN noise in cfg80211_wext_siwscan()", " - wifi: mt76: mt7915: fix rx filter setting for bfee functionality", " - wifi: mt76: mt7996: fix uninitialized TLV data", " - wifi: cfg80211: fix two more possible UBSAN-detected off-by-one errors", " - af_unix: Don't call skb_get() for OOB skb.", " - af_unix: Remove single nest in manage_oob().", " - af_unix: Rename unlinked_skb in manage_oob().", " - af_unix: Move spin_lock() in manage_oob().", " - Bluetooth: hci_core: Fix sending MGMT_EV_CONNECT_FAILED", " - Bluetooth: hci_sync: Ignore errors from HCI_OP_REMOTE_NAME_REQ_CANCEL", " - can: m_can: enable NAPI before enabling interrupts", " - can: m_can: m_can_close(): stop clocks after device has been shut down", " - Bluetooth: btusb: Fix not handling ZPL/short-transfer", " - bareudp: Pull inner IP header in bareudp_udp_encap_recv().", " - bareudp: Pull inner IP header on xmit.", " - net: enetc: Use IRQF_NO_AUTOEN flag in request_irq()", " - crypto: n2 - Set err to EINVAL if snprintf fails for hmac", " - xsk: fix batch alloc API on non-coherent systems", " - net: ipv6: rpl_iptunnel: Fix memory leak in rpl_input", " - fbnic: Set napi irq value after calling netif_napi_add", " - net: tipc: avoid possible garbage value", " - ublk: move zone report data out of request pdu", " - block, bfq: choose the last bfqq from merge chain in bfq_setup_cooperator()", " - block, bfq: don't break merge chain in bfq_split_bfqq()", " - cachefiles: Fix non-taking of sb_writers around set/removexattr", " - nbd: correct the maximum value for discard sectors", " - erofs: fix incorrect symlink detection in fast symlink", " - erofs: fix error handling in z_erofs_init_decompressor", " - block, bfq: fix uaf for accessing waker_bfqq after splitting", " - block, bfq: fix procress reference leakage for bfqq in merge chain", " - io_uring/io-wq: do not allow pinning outside of cpuset", " - io_uring/io-wq: inherit cpuset of cgroup in io worker", " - spi: ppc4xx: handle irq_of_parse_and_map() errors", " - arm64: dts: exynos: exynos7885-jackpotlte: Correct RAM amount to 4GB", " - arm64: dts: mediatek: mt8186: Fix supported-hw mask for GPU OPPs", " - spi: ppc4xx: Avoid returning 0 when failed to parse and map IRQ", " - firmware: qcom: scm: Disable SDI and write no dump to dump mode", " - regulator: Return actual error in of_regulator_bulk_get_all()", " - arm64: dts: renesas: r9a08g045: Correct GICD and GICR sizes", " - arm64: dts: renesas: r9a07g043u: Correct GICD and GICR sizes", " - arm64: dts: renesas: r9a07g054: Correct GICD and GICR sizes", " - arm64: dts: renesas: r9a07g044: Correct GICD and GICR sizes", " - ARM: dts: microchip: sam9x60: Fix rtc/rtt clocks", " - arm64: tegra: Correct location of power-sensors for IGX Orin", " - arm64: dts: rockchip: Correct vendor prefix for Hardkernel ODROID-M1", " - arm64: dts: ti: k3-j721e-sk: Fix reversed C6x carveout locations", " - arm64: dts: ti: k3-j721e-beagleboneai64: Fix reversed C6x carveout locations", " - spi: bcmbca-hsspi: Fix missing pm_runtime_disable()", " - arm64: dts: qcom: x1e80100: Fix PHY for DP2", " - ARM: dts: microchip: sama7g5: Fix RTT clock", " - ARM: dts: imx7d-zii-rmu2: fix Ethernet PHY pinctrl property", " - arm64: dts: ti: k3-am654-idk: Fix dtbs_check warning in ICSSG dmas", " - ARM: versatile: fix OF node leak in CPUs prepare", " - reset: berlin: fix OF node leak in probe() error path", " - reset: k210: fix OF node leak in probe() error path", " - platform: cznic: turris-omnia-mcu: Fix error check in", " omnia_mcu_register_trng()", " - clocksource/drivers/qcom: Add missing iounmap() on errors in", " msm_dt_timer_init()", " - arm64: dts: mediatek: mt8195: Correct clock order for dp_intf*", " - x86/mm: Use IPIs to synchronize LAM enablement", " - ASoC: rt5682s: Return devm_of_clk_add_hw_provider to transfer the error", " - ASoC: tas2781: Fix a compiling warning reported by robot kernel test due to", " adding tas2563_dvc_table", " - ASoC: tas2781-i2c: Drop weird GPIO code", " - ASoC: tas2781-i2c: Get the right GPIO line", " - selftests/ftrace: Add required dependency for kprobe tests", " - ALSA: hda: cs35l41: fix module autoloading", " - selftests/ftrace: Fix test to handle both old and new kernels", " - x86/boot/64: Strip percpu address space when setting up GDT descriptors", " - m68k: Fix kernel_clone_args.flags in m68k_clone()", " - ASoC: loongson: fix error release", " - selftests/ftrace: Fix eventfs ownership testcase to find mount point", " - selftests:resctrl: Fix build failure on archs without __cpuid_count()", " - cgroup/pids: Avoid spurious event notification", " - hwmon: (max16065) Fix overflows seen when writing limits", " - hwmon: (max16065) Fix alarm attributes", " - iommu/arm-smmu: Un-demote unhandled-fault msg", " - iommu/arm-smmu-v3: Fix a NULL vs IS_ERR() check", " - mtd: slram: insert break after errors in parsing the map", " - hwmon: (ntc_thermistor) fix module autoloading", " - power: supply: axp20x_battery: Remove design from min and max voltage", " - power: supply: max17042_battery: Fix SOC threshold calc w/ no current sense", " - fbdev: hpfb: Fix an error handling path in hpfb_dio_probe()", " - iommu/amd: Handle error path in amd_iommu_probe_device()", " - iommu/amd: Allocate the page table root using GFP_KERNEL", " - iommu/amd: Move allocation of the top table into v1_alloc_pgtable", " - iommu/amd: Set the pgsize_bitmap correctly", " - iommu/amd: Do not set the D bit on AMD v2 table entries", " - mtd: powernv: Add check devm_kasprintf() returned value", " - rcu/nocb: Fix RT throttling hrtimer armed from offline CPU", " - mtd: rawnand: mtk: Use for_each_child_of_node_scoped()", " - mtd: rawnand: mtk: Factorize out the logic cleaning mtk chips", " - mtd: rawnand: mtk: Fix init error path", " - iommu/arm-smmu-qcom: hide last LPASS SMMU context bank from linux", " - iommu/arm-smmu-qcom: Work around SDM845 Adreno SMMU w/ 16K pages", " - iommu/arm-smmu-qcom: apply num_context_bank fixes for SDM630 / SDM660", " - pmdomain: core: Harden inter-column space in debug summary", " - pmdomain: core: Fix \"managed by\" alignment in debug summary", " - drm/stm: Fix an error handling path in stm_drm_platform_probe()", " - drm/stm: ltdc: check memory returned by devm_kzalloc()", " - drm/amd/display: free bo used for dmub bounding box", " - drm/amdgpu: properly handle vbios fake edid sizing", " - drm/radeon: properly handle vbios fake edid sizing", " - drm/amd/display: Reset VRR config during resume", " - scsi: smartpqi: revert propagate-the-multipath-failure-to-SML-quickly", " - scsi: sd: Don't check if a write for REQ_ATOMIC", " - scsi: block: Don't check REQ_ATOMIC for reads", " - scsi: NCR5380: Check for phase match during PDMA fixup", " - drm/amd/amdgpu: Properly tune the size of struct", " - drm/amd/display: Improve FAM control for DCN401", " - drm/rockchip: vop: Allow 4096px width scaling", " - drm/rockchip: dw_hdmi: Fix reading EDID when using a forced mode", " - drm/radeon/evergreen_cs: fix int overflow errors in cs track offsets", " - drm/bridge: lontium-lt8912b: Validate mode in drm_bridge_funcs::mode_valid()", " - drm/vc4: hdmi: Handle error case of pm_runtime_resume_and_get", " - drm/mediatek: Fix missing configuration flags in mtk_crtc_ddp_config()", " - drm/mediatek: Use spin_lock_irqsave() for CRTC event lock", " - powerpc/8xx: Fix initial memory mapping", " - powerpc/8xx: Fix kernel vs user address comparison", " - powerpc/vdso: Inconditionally use CFUNC macro", " - drm/msm: Use a7xx family directly in gpu_state", " - drm/msm: Dump correct dbgahb clusters on a750", " - drm/msm: Fix CP_BV_DRAW_STATE_ADDR name", " - drm/msm: Fix incorrect file name output in adreno_request_fw()", " - drm/msm/a5xx: disable preemption in submits by default", " - drm/msm/a5xx: properly clear preemption records on resume", " - drm/msm/a5xx: fix races in preemption evaluation stage", " - drm/msm/a5xx: workaround early ring-buffer emptiness check", " - ipmi: docs: don't advertise deprecated sysfs entries", " - drm/msm/dp: enable widebus on all relevant chipsets", " - drm/msm/dsi: correct programming sequence for SM8350 / SM8450", " - drm/msm: fix %s null argument error", " - platform/x86: ideapad-laptop: Make the scope_guard() clear of its scope", " - kselftest: dt: Ignore nodes that have ancestors disabled", " - drivers:drm:exynos_drm_gsc:Fix wrong assignment in gsc_bind()", " - drm/amdgpu: fix invalid fence handling in amdgpu_vm_tlb_flush", " - xen: use correct end address of kernel for conflict checking", " - HID: wacom: Support sequence numbers smaller than 16-bit", " - HID: wacom: Do not warn about dropped packets for first packet", " - ata: libata: Clear DID_TIME_OUT for ATA PT commands with sense data", " - xen: introduce generic helper checking for memory map conflicts", " - xen: move max_pfn in xen_memory_setup() out of function scope", " - xen: add capability to remap non-RAM pages to different PFNs", " - xen: tolerate ACPI NVS memory overlapping with Xen allocated memory", " - drm/xe: fix missing 'xe_vm_put'", " - xen/swiotlb: add alignment check for dma buffers", " - xen/swiotlb: fix allocated size", " - sched/fair: Make SCHED_IDLE entity be preempted in strict hierarchy", " - bpf, x64: Fix tailcall hierarchy", " - bpf, arm64: Fix tailcall hierarchy", " - bpf: Fix compare error in function retval_range_within", " - selftests/bpf: Workaround strict bpf_lsm return value check.", " - selftests/bpf: Fix error linking uprobe_multi on mips", " - selftests/bpf: Fix wrong binary in Makefile log output", " - tools/runqslower: Fix LDFLAGS and add LDLIBS support", " - selftests/bpf: Use pid_t consistently in test_progs.c", " - selftests/bpf: Fix compile error from rlim_t in sk_storage_map.c", " - selftests/bpf: Fix error compiling bpf_iter_setsockopt.c with musl libc", " - selftests/bpf: Drop unneeded error.h includes", " - selftests/bpf: Fix missing ARRAY_SIZE() definition in bench.c", " - selftests/bpf: Fix missing UINT_MAX definitions in benchmarks", " - selftests/bpf: Fix missing BUILD_BUG_ON() declaration", " - selftests/bpf: Fix include of ", " - selftests/bpf: Fix compiling parse_tcp_hdr_opt.c with musl-libc", " - selftests/bpf: Fix compiling kfree_skb.c with musl-libc", " - selftests/bpf: Fix compiling flow_dissector.c with musl-libc", " - selftests/bpf: Fix compiling tcp_rtt.c with musl-libc", " - selftests/bpf: Fix compiling core_reloc.c with musl-libc", " - selftests/bpf: Fix errors compiling lwt_redirect.c with musl libc", " - selftests/bpf: Fix errors compiling decap_sanity.c with musl libc", " - selftests/bpf: Fix errors compiling crypto_sanity.c with musl libc", " - selftests/bpf: Fix errors compiling cg_storage_multi.h with musl libc", " - libbpf: Don't take direct pointers into BTF data from st_ops", " - selftests/bpf: Fix arg parsing in veristat, test_progs", " - selftests/bpf: Fix error compiling test_lru_map.c", " - selftests/bpf: Fix C++ compile error from missing _Bool type", " - selftests/bpf: Fix redefinition errors compiling lwt_reroute.c", " - selftests/bpf: Fix compile if backtrace support missing in libc", " - selftests/bpf: Fix error compiling tc_redirect.c with musl libc", " - s390/entry: Move early program check handler to entry.S", " - s390/entry: Make early program check handler relocated lowcore aware", " - libbpf: Fix license for btf_relocate.c", " - samples/bpf: Fix compilation errors with cf-protection option", " - selftests/bpf: no need to track next_match_pos in struct test_loader", " - selftests/bpf: extract test_loader->expect_msgs as a data structure", " - selftests/bpf: allow checking xlated programs in verifier_* tests", " - selftests/bpf: __arch_* macro to limit test cases to specific archs", " - selftests/bpf: fix to avoid __msg tag de-duplication by clang", " - selftests/bpf: Fix incorrect parameters in NULL pointer checking", " - libbpf: Fix bpf_object__open_skeleton()'s mishandling of options", " - s390/ap: Fix deadlock caused by recursive lock of the AP bus scan mutex", " - libbpf: Ensure new BTF objects inherit input endianness", " - xz: cleanup CRC32 edits from 2018", " - kthread: fix task state in kthread worker if being frozen", " - ext4: clear EXT4_GROUP_INFO_WAS_TRIMMED_BIT even mount with discard", " - bpftool: Fix handling enum64 in btf dump sorting", " - sched/deadline: Fix schedstats vs deadline servers", " - smackfs: Use rcu_assign_pointer() to ensure safe assignment in smk_set_cipso", " - ext4: avoid buffer_head leak in ext4_mark_inode_used()", " - ext4: avoid potential buffer_head leak in __ext4_new_inode()", " - ext4: avoid negative min_clusters in find_group_orlov()", " - ext4: return error on ext4_find_inline_entry", " - sched/numa: Fix the vma scan starving issue", " - nilfs2: determine empty node blocks as corrupted", " - sched/pelt: Use rq_clock_task() for hw_pressure", " - bpf: Fix bpf_strtol and bpf_strtoul helpers for 32bit", " - bpf: Improve check_raw_mode_ok test for MEM_UNINIT-tagged types", " - perf scripts python cs-etm: Restore first sample log in verbose mode", " - perf bpf: Move BPF disassembly routines to separate file to avoid clash with", " capstone bpf headers", " - perf mem: Free the allocated sort string, fixing a leak", " - perf lock contention: Change stack_id type to s32", " - perf vendor events: SKX, CLX, SNR uncore cache event fixes", " - perf inject: Fix leader sampling inserting additional samples", " - perf report: Fix --total-cycles --stdio output error", " - perf build: Fix up broken capstone feature detection fast path", " - perf sched timehist: Fix missing free of session in perf_sched__timehist()", " - perf stat: Display iostat headers correctly", " - perf dwarf-aux: Check allowed location expressions when collecting variables", " - perf annotate-data: Fix off-by-one in location range check", " - perf dwarf-aux: Handle bitfield members from pointer access", " - perf hist: Don't set hpp_fmt_value for members in --no-group", " - perf sched timehist: Fixed timestamp error when unable to confirm event", " sched_in time", " - perf time-utils: Fix 32-bit nsec parsing", " - perf mem: Check mem_events for all eligible PMUs", " - perf mem: Fix missed p-core mem events on ADL and RPL", " - clk: imx: clk-audiomix: Correct parent clock for earc_phy and audpll", " - clk: imx: imx6ul: fix default parent for enet*_ref_sel", " - clk: imx: composite-8m: Enable gate clk with mcore_booted", " - clk: imx: composite-93: keep root clock on when mcore enabled", " - clk: imx: composite-7ulp: Check the PCC present bit", " - clk: imx: fracn-gppll: fix fractional part of PLL getting lost", " - clk: imx: imx8mp: fix clock tree update of TF-A managed clocks", " - clk: imx: imx8qxp: Register dc0_bypass0_clk before disp clk", " - clk: imx: imx8qxp: Parent should be initialized earlier than the clock", " - quota: avoid missing put_quota_format when DQUOT_SUSPENDED is passed", " - remoteproc: imx_rproc: Correct ddr alias for i.MX8M", " - remoteproc: imx_rproc: Initialize workqueue earlier", " - clk: rockchip: Set parent rate for DCLK_VOP clock on RK3228", " - clk: qcom: dispcc-sm8550: fix several supposed typos", " - clk: qcom: dispcc-sm8550: use rcg2_ops for mdss_dptx1_aux_clk_src", " - clk: qcom: dispcc-sm8650: Update the GDSC flags", " - clk: qcom: dispcc-sm8550: use rcg2_shared_ops for ESC RCGs", " - leds: bd2606mvv: Fix device child node usage in bd2606mvv_probe()", " - pinctrl: renesas: rzg2l: Return -EINVAL if the pin doesn't support", " PIN_CFG_OEN", " - pinctrl: ti: ti-iodelay: Fix some error handling paths", " - phy: phy-rockchip-samsung-hdptx: Explicitly include pm_runtime.h", " - Input: ilitek_ts_i2c - avoid wrong input subsystem sync", " - Input: ilitek_ts_i2c - add report id message validation", " - media: raspberrypi: VIDEO_RASPBERRYPI_PISP_BE should depend on ARCH_BCM2835", " - [Config] updateconfigs for VIDEO_RASPBERRYPI_PISP_BE", " - PCI: Wait for Link before restoring Downstream Buses", " - firewire: core: correct range of block for case of switch statement", " - media: staging: media: starfive: camss: Drop obsolete return value", " documentation", " - clk: qcom: ipq5332: Register gcc_qdss_tsctr_clk_src", " - clk: qcom: dispcc-sm8250: use special function for Lucid 5LPE PLL", " - leds: pca995x: Use device_for_each_child_node() to access device child nodes", " - leds: pca995x: Fix device child node usage in pca995x_probe()", " - x86/PCI: Check pcie_find_root_port() return for NULL", " - PCI: xilinx-nwl: Fix register misspelling", " - PCI: xilinx-nwl: Clean up clock on probe failure/removal", " - leds: gpio: Set num_leds after allocation", " - media: platform: rzg2l-cru: rzg2l-csi2: Add missing MODULE_DEVICE_TABLE", " - pinctrl: single: fix missing error code in pcs_probe()", " - clk: at91: sama7g5: Allocate only the needed amount of memory for PLLs", " - iommufd/selftest: Fix buffer read overrrun in the dirty test", " - RDMA/bnxt_re: Fix the table size for PSN/MSN entries", " - media: imagination: VIDEO_E5010_JPEG_ENC should depend on ARCH_K3", " - [Config] updateconfigs for VIDEO_E5010_JPEG_ENC", " - RDMA/rtrs: Reset hb_missed_cnt after receiving other traffic from peer", " - clk: ti: dra7-atl: Fix leak of of_nodes", " - clk: starfive: Use pm_runtime_resume_and_get to fix pm_runtime_get_sync()", " usage", " - clk: rockchip: rk3588: Fix 32k clock name for pmu_24m_32k_100m_src_p", " - nfsd: remove unneeded EEXIST error check in nfsd_do_file_acquire", " - nfsd: fix refcount leak when file is unhashed after being found", " - pinctrl: mvebu: Fix devinit_dove_pinctrl_probe function", " - dt-bindings: PCI: layerscape-pci: Replace fsl,lx2160a-pcie with", " fsl,lx2160ar2-pcie", " - iommufd: Check the domain owner of the parent before creating a nesting", " domain", " - RDMA/erdma: Return QP state in erdma_query_qp", " - RDMA/mlx5: Fix counter update on MR cache mkey creation", " - RDMA/mlx5: Limit usage of over-sized mkeys from the MR cache", " - RDMA/mlx5: Drop redundant work canceling from clean_keys()", " - RDMA/mlx5: Fix MR cache temp entries cleanup", " - watchdog: imx_sc_wdt: Don't disable WDT in suspend", " - RDMA/hns: Don't modify rq next block addr in HIP09 QPC", " - RDMA/hns: Fix the overflow risk of hem_list_calc_ba_range()", " - RDMA/hns: Fix VF triggering PF reset in abnormal interrupt handler", " - RDMA/hns: Fix 1bit-ECC recovery address in non-4K OS", " - RDMA/hns: Optimize hem allocation performance", " - RDMA/hns: Fix restricted __le16 degrades to integer issue", " - Input: ims-pcu - fix calling interruptible mutex", " - RDMA/mlx5: Obtain upper net device only when needed", " - PCI: qcom-ep: Enable controller resources like PHY only after refclk is", " available", " - riscv: Fix fp alignment bug in perf_callchain_user()", " - RDMA/hns: Fix ah error counter in sw stat not increasing", " - RDMA/irdma: fix error message in irdma_modify_qp_roce()", " - ntb_perf: Fix printk format", " - ntb: Force physically contiguous allocation of rx ring buffers", " - nfsd: untangle code in nfsd4_deleg_getattr_conflict()", " - nfsd: fix initial getattr on write delegation", " - crypto: caam - Pad SG length when allocating hash edesc", " - crypto: powerpc/p10-aes-gcm - Disable CRYPTO_AES_GCM_P10", " - [Config] disable CRYPTO_AES_GCM_P10", " - f2fs: atomic: fix to avoid racing w/ GC", " - f2fs: reduce expensive checkpoint trigger frequency", " - f2fs: fix to avoid racing in between read and OPU dio write", " - f2fs: Create COW inode from parent dentry for atomic write", " - f2fs: fix to wait page writeback before setting gcing flag", " - f2fs: atomic: fix to truncate pagecache before on-disk metadata truncation", " - f2fs: compress: don't redirty sparse cluster during {,de}compress", " - f2fs: prevent atomic file from being dirtied before commit", " - spi: airoha: fix dirmap_{read,write} operations", " - spi: airoha: fix airoha_snand_{write,read}_data data_len estimation", " - spi: atmel-quadspi: Undo runtime PM changes at driver exit time", " - spi: spi-fsl-lpspi: Undo runtime PM changes at driver exit time", " - lib/sbitmap: define swap_lock as raw_spinlock_t", " - spi: airoha: remove read cache in airoha_snand_dirmap_read()", " - spi: atmel-quadspi: Avoid overwriting delay register settings", " - NFSv4.2: Fix detection of \"Proxying of Times\" server support", " - nvme-multipath: system fails to create generic nvme device", " - iio: adc: ad7606: fix oversampling gpio array", " - iio: adc: ad7606: fix standby gpio state to match the documentation", " - driver core: Fix error handling in driver API device_rename()", " - ABI: testing: fix admv8818 attr description", " - iio: chemical: bme680: Fix read/write ops to device by adding mutexes", " - iio: magnetometer: ak8975: drop incorrect AK09116 compatible", " - dt-bindings: iio: asahi-kasei,ak8975: drop incorrect AK09116 compatible", " - serial: 8250: omap: Cleanup on error in request_irq", " - Coresight: Set correct cs_mode for TPDM to fix disable issue", " - Coresight: Set correct cs_mode for dummy source to fix disable issue", " - coresight: tmc: sg: Do not leak sg_table", " - interconnect: icc-clk: Add missed num_nodes initialization", " - interconnect: qcom: sm8250: Enable sync_state", " - dm integrity: fix gcc 5 warning", " - cxl/pci: Fix to record only non-zero ranges", " - um: remove ARCH_NO_PREEMPT_DYNAMIC", " - Revert \"dm: requeue IO if mapping table not yet available\"", " - net: phy: aquantia: fix -ETIMEDOUT PHY probe failure when firmware not", " present", " - net: xilinx: axienet: Schedule NAPI in two steps", " - net: xilinx: axienet: Fix packet counting", " - net: ipv6: select DST_CACHE from IPV6_RPL_LWTUNNEL", " - net: qrtr: Update packets cloning when broadcasting", " - net: phy: aquantia: fix setting active_low bit", " - net: phy: aquantia: fix applying active_low bit after reset", " - net: ravb: Fix maximum TX frame size for GbEth devices", " - net: ravb: Fix R-Car RX frame size limit", " - virtio_net: Fix mismatched buf address when unmapping for small packets", " - netfilter: nf_tables: Keep deleted flowtable hooks until after RCU", " - netfilter: ctnetlink: compile ctnetlink_label_size with", " CONFIG_NF_CONNTRACK_EVENTS", " - netfilter: nf_tables: use rcu chain hook list iterator from netlink dump", " path", " - netfilter: nf_tables: missing objects with no memcg accounting", " - selftests: netfilter: Avoid hanging ipvs.sh", " - io_uring/sqpoll: do not allow pinning outside of cpuset", " - io_uring/rw: treat -EOPNOTSUPP for IOCB_NOWAIT like -EAGAIN", " - io_uring: check for presence of task_work rather than TIF_NOTIFY_SIGNAL", " - mm: migrate: annotate data-race in migrate_folio_unmap()", " - drm/amd/display: Fix Synaptics Cascaded Panamera DSC Determination", " - drm/amd/display: Add DSC Debug Log", " - drm/amdgpu/display: Fix a mistake in revert commit", " - xen: move checks for e820 conflicts further up", " - xen: allow mapping ACPI data using a different physical address", " - io_uring/sqpoll: retain test for whether the CPU is valid", " - drm/amd/display: disable_hpo_dp_link_output: Check link_res->hpo_dp_link_enc", " before using it", " - io_uring/sqpoll: do not put cpumask on stack", " - selftests/bpf: correctly move 'log' upon successful match", " - Remove *.orig pattern from .gitignore", " - PCI: Revert to the original speed after PCIe failed link retraining", " - PCI: Clear the LBMS bit after a link retrain", " - PCI: dra7xx: Fix threaded IRQ request for \"dra7xx-pcie-main\" IRQ", " - PCI: imx6: Fix missing call to phy_power_off() in error handling", " - PCI: imx6: Fix establish link failure in EP mode for i.MX8MM and i.MX8MP", " - PCI: imx6: Fix i.MX8MP PCIe EP's occasional failure to trigger MSI", " - PCI: Correct error reporting with PCIe failed link retraining", " - PCI: Use an error code with PCIe failed link retraining", " - PCI: xilinx-nwl: Fix off-by-one in INTx IRQ handler", " - PCI: dra7xx: Fix error handling when IRQ request fails in probe", " - Revert \"soc: qcom: smd-rpm: Match rpmsg channel instead of compatible\"", " - ASoC: rt5682: Return devm_of_clk_add_hw_provider to transfer the error", " - soc: fsl: cpm1: qmc: Update TRNSYNC only in transparent mode", " - soc: fsl: cpm1: tsa: Fix tsa_write8()", " - soc: versatile: integrator: fix OF node leak in probe() error path", " - Revert \"media: tuners: fix error return code of", " hybrid_tuner_request_state()\"", " - iommu/amd: Fix argument order in amd_iommu_dev_flush_pasid_all()", " - Input: adp5588-keys - fix check on return code", " - Input: i8042 - add TUXEDO Stellaris 16 Gen5 AMD to i8042 quirk table", " - Input: i8042 - add TUXEDO Stellaris 15 Slim Gen6 AMD to i8042 quirk table", " - Input: i8042 - add another board name for TUXEDO Stellaris Gen5 AMD line", " - KVM: arm64: Add memory length checks and remove inline in do_ffa_mem_xfer", " - KVM: x86: Enforce x2APIC's must-be-zero reserved ICR bits", " - KVM: x86: Move x2APIC ICR helper above kvm_apic_write_nodecode()", " - KVM: x86: Re-split x2APIC ICR into ICR+ICR2 for AMD (x2AVIC)", " - drm/amdgpu/mes12: reduce timeout", " - drm/amdgpu/mes11: reduce timeout", " - drm/amdkfd: Add SDMA queue quantum support for GFX12", " - drm/amdgpu: update golden regs for gfx12", " - drm/amdgpu/mes12: set enable_level_process_quantum_check", " - drm/amdgpu/vcn: enable AV1 on both instances", " - drm/amd/pm: update workload mask after the setting", " - drm/amdgpu: fix PTE copy corruption for sdma 7", " - drm/amdgpu: bump driver version for cleared VRAM", " - drm/amdgpu/mes12: switch SET_SHADER_DEBUGGER pkt to mes schq pipe", " - drm/amdgpu: Fix selfring initialization sequence on soc24", " - drm/amd/display: Add HDMI DSC native YCbCr422 support", " - drm/amd/display: Round calculated vtotal", " - drm/amd/display: Clean up dsc blocks in accelerated mode", " - drm/amd/display: Block timing sync for different output formats in pmo", " - drm/amd/display: Validate backlight caps are sane", " - drm/amd/display: Disable SYMCLK32_LE root clock gating", " - drm/amd/display: Block dynamic IPS2 on DCN35 for incompatible FW versions", " - drm/amd/display: Enable DML2 override_det_buffer_size_kbytes", " - drm/amd/display: Skip to enable dsc if it has been off", " - drm/amd/display: Fix underflow when setting underscan on DCN401", " - drm/amd/display: Update IPS default mode for DCN35/DCN351", " - objtool: Handle frame pointer related instructions", " - powerpc/atomic: Use YZ constraints for DS-form instructions", " - ksmbd: make __dir_empty() compatible with POSIX", " - ksmbd: allow write with FILE_APPEND_DATA", " - ksmbd: handle caseless file creation", " - ata: libata-scsi: Fix ata_msense_control() CDL page reporting", " - scsi: ufs: qcom: Update MODE_MAX cfg_bw value", " - scsi: lpfc: Restrict support for 32 byte CDBs to specific HBAs", " - scsi: mac_scsi: Revise printk(KERN_DEBUG ...) messages", " - scsi: mac_scsi: Refactor polling loop", " - scsi: mac_scsi: Disallow bus errors during PDMA send", " - can: esd_usb: Remove CAN_CTRLMODE_3_SAMPLES for CAN-USB/3-FD", " - wifi: rtw88: Fix USB/SDIO devices not transmitting beacons", " - usbnet: fix cyclical race on disconnect with work queue", " - arm64: dts: mediatek: mt8195-cherry: Mark USB 3.0 on xhci1 as disabled", " - arm64: dts: mediatek: mt8395-nio-12l: Mark USB 3.0 on xhci1 as disabled", " - USB: appledisplay: close race between probe and completion handler", " - USB: misc: cypress_cy7c63: check for short transfer", " - USB: class: CDC-ACM: fix race between get_serial and set_serial", " - USB: misc: yurex: fix race between read and write", " - usb: xhci: fix loss of data on Cadence xHC", " - usb: cdnsp: Fix incorrect usb_request status", " - usb: xHCI: add XHCI_RESET_ON_RESUME quirk for Phytium xHCI host", " - usb: gadget: dummy_hcd: execute hrtimer callback in softirq context", " - usb: dwc2: drd: fix clock gating on USB role switch", " - bus: integrator-lm: fix OF node leak in probe()", " - bus: mhi: host: pci_generic: Update EDL firmware path for Foxconn modems", " - bus: mhi: host: pci_generic: Fix the name for the Telit FE990A", " - tty: rp2: Fix reset with non forgiving PCIe host bridges", " - pps: add an error check in parport_attach", " - serial: don't use uninitialized value in uart_poll_init()", " - xhci: Set quirky xHC PCI hosts to D3 _after_ stopping and freeing them.", " - serial: qcom-geni: fix fifo polling timeout", " - serial: qcom-geni: fix false console tx restart", " - crypto: qcom-rng - fix support for ACPI-based systems", " - crypto: ccp - Properly unregister /dev/sev on sev PLATFORM_STATUS failure", " - drbd: Fix atomicity violation in drbd_uuid_set_bm()", " - drbd: Add NULL check for net_conf to prevent dereference in state validation", " - ACPI: resource: Do IRQ override on MECHREV GM7XG0M", " - ACPI: resource: Add another DMI match for the TongFang GMxXGxx", " - intel_idle: add Granite Rapids Xeon support", " - intel_idle: fix ACPI _CST matching for newer Xeon platforms", " - x86/entry: Remove unwanted instrumentation in common_interrupt()", " - perf/x86/intel: Allow to setup LBR for counting event for BPF", " - perf/x86/intel/pt: Fix sampling synchronization", " - btrfs: subpage: fix the bitmap dump which can cause bitmap corruption", " - wifi: mt76: mt7921: Check devm_kasprintf() returned value", " - wifi: mt76: mt7915: check devm_kasprintf() returned value", " - idpf: fix netdev Tx queue stop/wake", " - wifi: rtw88: 8821cu: Remove VID/PID 0bda:c82c", " - wifi: rtw88: 8822c: Fix reported RX band width", " - wifi: rtw88: 8703b: Fix reported RX band width", " - wifi: mt76: mt7615: check devm_kasprintf() returned value", " - wifi: mt76: mt7925: fix a potential association failure upon resuming", " - debugfs show actual source in /proc/mounts", " - debugobjects: Fix conditions in fill_pool()", " - btrfs: tree-checker: fix the wrong output of data backref objectid", " - btrfs: always update fstrim_range on failure in FITRIM ioctl", " - f2fs: fix several potential integer overflows in file offsets", " - f2fs: prevent possible int overflow in dir_block_index()", " - f2fs: avoid potential int overflow in sanity_check_area_boundary()", " - hwrng: mtk - Use devm_pm_runtime_enable", " - hwrng: bcm2835 - Add missing clk_disable_unprepare in bcm2835_rng_init", " - hwrng: cctrng - Add missing clk_disable_unprepare in cctrng_resume", " - arm64: esr: Define ESR_ELx_EC_* constants as UL", " - arm64: errata: Enable the AC03_CPU_38 workaround for ampere1a", " - arm64: dts: mediatek: mt8186-corsola: Disable DPI display interface", " - arm64: dts: rockchip: Raise Pinebook Pro's panel backlight PWM frequency", " - arm64: dts: qcom: sa8775p: Mark APPS and PCIe SMMUs as DMA coherent", " - arm64: dts: rockchip: Correct the Pinebook Pro battery design capacity", " - fs: Fix file_set_fowner LSM hook inconsistencies", " - nfs: fix memory leak in error path of nfs4_do_reclaim", " - EDAC/igen6: Fix conversion of system address to physical memory address", " - eventpoll: Annotate data-race of busy_poll_usecs", " - md: Don't flush sync_work in md_write_start()", " - cpuidle: riscv-sbi: Use scoped device node handling to fix missing", " of_node_put", " - lsm: add the inode_free_security_rcu() LSM implementation hook", " - spi: fspi: involve lut_num for struct nxp_fspi_devtype_data", " - dt-bindings: spi: nxp-fspi: add imx8ulp support", " - ARM: dts: imx6ul-geam: fix fsl,pins property in tscgrp pinctrl", " - ARM: dts: imx6ull-seeed-npi: fix fsl,pins property in tscgrp pinctrl", " - tools/nolibc: include arch.h from string.h", " - soc: versatile: realview: fix memory leak during device remove", " - soc: versatile: realview: fix soc_dev leak during device remove", " - usb: typec: ucsi: Call CANCEL from single location", " - usb: typec: ucsi: Fix busy loop on ASUS VivoBooks", " - soc: qcom: geni-se: add GP_LENGTH/IRQ_EN_SET/IRQ_EN_CLEAR registers", " - serial: qcom-geni: fix arg types for qcom_geni_serial_poll_bit()", " - serial: qcom-geni: introduce qcom_geni_serial_poll_bitfield()", " - serial: qcom-geni: fix console corruption", " - thermal: core: Store trip sysfs attributes in thermal_trip_desc", " - thermal: sysfs: Get to trips via attribute pointers", " - thermal: sysfs: Refine the handling of trip hysteresis changes", " - thermal: sysfs: Add sanity checks for trip temperature and hysteresis", " - bpf: lsm: Set bpf_lsm_blob_sizes.lbs_task to 0", " - compiler.h: specify correct attribute for .rodata..c_jump_table", " - lockdep: fix deadlock issue between lockdep and rcu", " - mm/hugetlb_vmemmap: batch HVO work when demoting", " - s390/ftrace: Avoid calling unwinder in ftrace_return_address()", " - selftest mm/mseal: fix test_seal_mremap_move_dontunmap_anyaddr", " - mm: only enforce minimum stack gap size if it's sensible", " - spi: fspi: add support for imx8ulp", " - module: Fix KCOV-ignored file name", " - fbdev: xen-fbfront: Assign fb_info->device", " - tpm: export tpm2_sessions_init() to fix ibmvtpm building", " - mm/huge_memory: ensure huge_zero_folio won't have large_rmappable flag set", " - mm: change vmf_anon_prepare() to __vmf_anon_prepare()", " - mm/damon/vaddr: protect vma traversal in __damon_va_thre_regions() with rcu", " read lock", " - i2c: aspeed: Update the stop sw state when the bus recovery occurs", " - i2c: isch: Add missed 'else'", " - i2c: xiic: Try re-initialization on bus busy timeout", " - Documentation: KVM: fix warning in \"make htmldocs\"", " - spi: atmel-quadspi: Fix wrong register value written to MR", " - Revert: \"dm-verity: restart or panic on an I/O error\"", " - Linux 6.11.2", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47675", " - bpf: Fix use-after-free in bpf_uprobe_multi_link_attach()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47676", " - mm/hugetlb.c: fix UAF of vma in hugetlb fault pathway", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47677", " - exfat: resolve memory leak from exfat_create_upcase_table()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47725", " - dm-verity: restart or panic on an I/O error", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47739", " - padata: use integer wrap around to prevent deadlock on seq_nr overflow", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47678", " - icmp: change the order of rate limits", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47733", " - netfs: Delete subtree of 'fs/netfs' when netfs module exits", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47679", " - vfs: fix race between evice_inodes() and find_inode()&iput()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49859", " - f2fs: fix to check atomic_file in f2fs ioctl interfaces", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47680", " - f2fs: check discard support for conventional zones", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47740", " - f2fs: Require FMODE_WRITE for atomic write ioctls", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47726", " - f2fs: fix to wait dio completion", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47741", " - btrfs: fix race setting file private on concurrent lseek using same fd", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47681", " - wifi: mt76: mt7996: fix NULL pointer dereference in mt7996_mcu_sta_bfer_he", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49858", " - efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49860", " - ACPI: sysfs: validate return type of _STR method", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47742", " - firmware_loader: Block path traversal", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47682", " - scsi: sd: Fix off-by-one error in sd_read_block_characteristics()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47743", " - KEYS: prevent NULL pointer dereference in find_asymmetric_key()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47727", " - x86/tdx: Fix \"in-kernel MMIO\" check", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47744", " - KVM: Use dedicated mutex to protect kvm_usage_count to avoid deadlock", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47719", " - iommufd: Protect against overflow of ALIGN() during iova allocation", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47745", " - mm: call the security_mmap_file() LSM hook in remap_file_pages()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47746", " - fuse: use exclusive lock when FUSE_I_CACHE_IO_MODE is set", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47734", " - bonding: Fix unnecessary warnings and logs from bond_xdp_get_xmit_slave()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47684", " - tcp: check skb is non-NULL in tcp_rto_delta_us()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47747", " - net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race", " Condition", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47685", " - netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47686", " - ep93xx: clock: Fix off by one in ep93xx_div_recalc_rate()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47748", " - vhost_vdpa: assign irq bypass producer token correctly", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47687", " - vdpa/mlx5: Fix invalid mr resource destroy", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47688", " - driver core: Fix a potential null-ptr-deref in module_add_driver()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47689", " - f2fs: fix to don't set SB_RDONLY in f2fs_handle_critical_error()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47690", " - f2fs: get rid of online repaire on corrupted directory", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47691", " - f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47692", " - nfsd: return -EINVAL when namelen is 0", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47737", " - nfsd: call cache_put if xdr_reserve_space returns NULL", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2023-52917", " - ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47749", " - RDMA/cxgb4: Added NULL check for lookup_atid", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47735", " - RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47750", " - RDMA/hns: Fix Use-After-Free of rsv_qp on HIP08", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47751", " - PCI: kirin: Fix buffer overflow in kirin_pcie_parse_port()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47693", " - IB/core: Fix ib_cache_setup_one error flow cleanup", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47694", " - IB/mlx5: Fix UMR pd cleanup on error flow of driver init", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47695", " - RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47752", " - media: mediatek: vcodec: Fix H264 stateless decoder smatch warning", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47753", " - media: mediatek: vcodec: Fix VP8 stateless decoder smatch warning", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47754", " - media: mediatek: vcodec: Fix H264 multi stateless decoder smatch warning", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47696", " - RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47755", " - nvdimm: Fix devs leaks in scan_labels()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47756", " - PCI: keystone: Fix if-statement expression in ks_pcie_quirk()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47697", " - drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47698", " - drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47728", " - bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49861", " - bpf: Fix helper writes to read-only maps", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47757", " - nilfs2: fix potential oob read in nilfs_btree_check_delete()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47699", " - nilfs2: fix potential null-ptr-deref in nilfs_btree_insert()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47700", " - ext4: check stripe size compatibility on remount as well", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47701", " - ext4: avoid OOB when system.data xattr changes underneath the filesystem", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49850", " - bpf: correctly handle malformed BPF_CORE_TYPE_ID_LOCAL relos", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47702", " - bpf: Fail verification for sign-extension of packet data/data_end/data_meta", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47703", " - bpf, lsm: Add check for BPF LSM return value", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49851", " - tpm: Clean up TPM space after command failure", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47723", " - jfs: fix out-of-bounds in dbNextAG() and diAlloc()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49852", " - scsi: elx: libefc: Fix potential use after free in efc_nport_vport_del()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47720", " - drm/amd/display: Add null check for set_output_gamma in", " dcn30_set_output_transfer_func", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47704", " - drm/amd/display: Check link_res->hpo_dp_link_enc before using it", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49853", " - firmware: arm_scmi: Fix double free in OPTEE transport", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47705", " - block: fix potential invalid pointer dereference in blk_add_partition", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47736", " - erofs: handle overlapped pclusters out of crafted images properly", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47706", " - block, bfq: fix possible UAF for bfqq->bic with merge chain", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49855", " - nbd: fix race between timeout and normal completion", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47707", " - ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47708", " - netkit: Assign missing bpf_net_context", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47709", " - can: bcm: Clear bo->bcm_proc_read after remove_proc_entry().", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47710", " - sock_map: Add a cond_resched() in sock_hash_free()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47711", " - af_unix: Don't return OOB skb in manage_oob().", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47712", " - wifi: wilc1000: fix potential RCU dereference issue in", " wilc_parse_join_bss_param", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47713", " - wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47730", " - crypto: hisilicon/qm - inject error before stopping queue", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49856", " - x86/sgx: Fix deadlock in SGX NUMA node search", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47714", " - wifi: mt76: mt7996: use hweight16 to get correct tx antenna", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47715", " - wifi: mt76: mt7915: fix oops on non-dbdc mt7986", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49857", " - wifi: iwlwifi: mvm: set the cipher for secured NDP ranging", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47738", " - wifi: mac80211: don't use rate mask for offchannel TX either", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47731", " - drivers/perf: Fix ali_drw_pmu driver interrupt status clearing", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49862", " - powercap: intel_rapl: Fix off by one in get_rpi()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47716", " - ARM: 9410/1: vfp: Use asm volatile in fmrx/fmxr macros", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47717", " - RISC-V: KVM: Don't zero-out PMU snapshot area before freeing data", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47721", " - wifi: rtw89: remove unused C2H event ID RTW89_MAC_C2H_FUNC_READ_WOW_CAM to", " prevent out-of-bounds reading", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47732", " - crypto: iaa - Fix potential use after free bug", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47718", " - wifi: rtw88: always wait for both firmware loading attempts", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47724", " - wifi: ath11k: use work queue to process beacon tx event", "", " * Oracular update: v6.11.1 upstream stable release (LP: #2089020)", " - powercap/intel_rapl: Add support for AMD family 1Ah", " - powercap/intel_rapl: Fix the energy-pkg event for AMD CPUs", " - cpufreq/amd-pstate: Add the missing cpufreq_cpu_put()", " - netfilter: nft_socket: Fix a NULL vs IS_ERR() bug in", " nft_socket_cgroup_subtree_level()", " - ASoC: amd: acp: add ZSC control register programming sequence", " - nvme-pci: qdepth 1 quirk", " - USB: serial: pl2303: add device id for Macrosilicon MS3020", " - powercap: intel_rapl: Change an error pointer to NULL", " - Linux 6.11.1", "", " * Oracular update: v6.11.1 upstream stable release (LP: #2089020) //", " CVE-2024-47671", " - USB: usbtmc: prevent kernel-usb-infoleak", "", " * Oracular update: v6.11.1 upstream stable release (LP: #2089020) //", " CVE-2024-46869", " - Bluetooth: btintel_pcie: Allocate memory for driver private data", "", " * CVE-2024-53164", " - net: sched: fix ordering of qlen adjustment", "", " * CVE-2024-53103", " - hv_sock: Initializing vsk->trans to NULL to prevent a dangling pointer", "" ], "package": "linux", "version": "6.11.0-17.17", "urgency": "medium", "distributions": "oracular", "launchpad_bugs_fixed": [ 2093643, 1786013, 2091744, 2091184, 2093146, 2085406, 2089684, 2090932, 2085485, 2089357, 2089306, 2091655, 2091655, 2091655, 2091655, 2091655, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091386, 2091990, 2089327, 2089113, 2086587, 2086606, 2085950, 2085944, 2087853, 2087983, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089020, 2089020, 2089020 ], "author": "Stefan Bader ", "date": "Thu, 16 Jan 2025 22:38:59 +0100" } ], "notes": "linux-headers-6.11.0-18-generic version '6.11.0-18.18' (source package linux version '6.11.0-18.18') was added. linux-headers-6.11.0-18-generic version '6.11.0-18.18' has the same source package name, linux, as removed package linux-headers-6.11.0-14. As such we can use the source package version of the removed package, '6.11.0-14.15', 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." }, { "name": "linux-image-6.11.0-18-generic", "from_version": { "source_package_name": "linux", "source_package_version": "6.11.0-14.15", "version": null }, "to_version": { "source_package_name": "linux", "source_package_version": "6.11.0-18.18", "version": "6.11.0-18.18" }, "cves": [ { "cve": "CVE-2025-0927", "url": "https://ubuntu.com/security/CVE-2025-0927", "cve_description": "[fs: hfs/hfsplus: add key_len boundary check to hfs_bnode_read_key]", "cve_priority": "medium", "cve_public_date": "2025-02-13" }, { "cve": "CVE-2024-53141", "url": "https://ubuntu.com/security/CVE-2024-53141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: add missing range check in bitmap_ip_uadt When tb[IPSET_ATTR_IP_TO] is not present but tb[IPSET_ATTR_CIDR] exists, the values of ip and ip_to are slightly swapped. Therefore, the range check for ip should be done later, but this part is missing and it seems that the vulnerability occurs. So we should add missing range checks and remove unnecessary range checks.", "cve_priority": "medium", "cve_public_date": "2024-12-06 10:15:00 UTC" }, { "cve": "CVE-2024-50010", "url": "https://ubuntu.com/security/CVE-2024-50010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exec: don't WARN for racy path_noexec check Both i_mode and noexec checks wrapped in WARN_ON stem from an artifact of the previous implementation. They used to legitimately check for the condition, but that got moved up in two commits: 633fb6ac3980 (\"exec: move S_ISREG() check earlier\") 0fd338b2d2cd (\"exec: move path_noexec() check earlier\") Instead of being removed said checks are WARN_ON'ed instead, which has some debug value. However, the spurious path_noexec check is racy, resulting in unwarranted warnings should someone race with setting the noexec flag. One can note there is more to perm-checking whether execve is allowed and none of the conditions are guaranteed to still hold after they were tested for. Additionally this does not validate whether the code path did any perm checking to begin with -- it will pass if the inode happens to be regular. Keep the redundant path_noexec() check even though it's mindless nonsense checking for guarantee that isn't given so drop the WARN. Reword the commentary and do small tidy ups while here. [brauner: keep redundant path_noexec() check]", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-53143", "url": "https://ubuntu.com/security/CVE-2024-53143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fsnotify: Fix ordering of iput() and watched_objects decrement Ensure the superblock is kept alive until we're done with iput(). Holding a reference to an inode is not allowed unless we ensure the superblock stays alive, which fsnotify does by keeping the watched_objects count elevated, so iput() must happen before the watched_objects decrement. This can lead to a UAF of something like sb->s_fs_info in tmpfs, but the UAF is hard to hit because race orderings that oops are more likely, thanks to the CHECK_DATA_CORRUPTION() block in generic_shutdown_super(). Also, ensure that fsnotify_put_sb_watched_objects() doesn't call fsnotify_sb_watched_objects() on a superblock that may have already been freed, which would cause a UAF read of sb->s_fsnotify_info.", "cve_priority": "medium", "cve_public_date": "2024-12-07 07:15:00 UTC" }, { "cve": "CVE-2024-53142", "url": "https://ubuntu.com/security/CVE-2024-53142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: initramfs: avoid filename buffer overrun The initramfs filename field is defined in Documentation/driver-api/early-userspace/buffer-format.rst as: 37 cpio_file := ALGN(4) + cpio_header + filename + \"\\0\" + ALGN(4) + data ... 55 ============= ================== ========================= 56 Field name Field size Meaning 57 ============= ================== ========================= ... 70 c_namesize 8 bytes Length of filename, including final \\0 When extracting an initramfs cpio archive, the kernel's do_name() path handler assumes a zero-terminated path at @collected, passing it directly to filp_open() / init_mkdir() / init_mknod(). If a specially crafted cpio entry carries a non-zero-terminated filename and is followed by uninitialized memory, then a file may be created with trailing characters that represent the uninitialized memory. The ability to create an initramfs entry would imply already having full control of the system, so the buffer overrun shouldn't be considered a security vulnerability. Append the output of the following bash script to an existing initramfs and observe any created /initramfs_test_fname_overrunAA* path. E.g. ./reproducer.sh | gzip >> /myinitramfs It's easiest to observe non-zero uninitialized memory when the output is gzipped, as it'll overflow the heap allocated @out_buf in __gunzip(), rather than the initrd_start+initrd_size block. ---- reproducer.sh ---- nilchar=\"A\"\t# change to \"\\0\" to properly zero terminate / pad magic=\"070701\" ino=1 mode=$(( 0100777 )) uid=0 gid=0 nlink=1 mtime=1 filesize=0 devmajor=0 devminor=1 rdevmajor=0 rdevminor=0 csum=0 fname=\"initramfs_test_fname_overrun\" namelen=$(( ${#fname} + 1 ))\t# plus one to account for terminator printf \"%s%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%s\" \\ \t$magic $ino $mode $uid $gid $nlink $mtime $filesize \\ \t$devmajor $devminor $rdevmajor $rdevminor $namelen $csum $fname termpadlen=$(( 1 + ((4 - ((110 + $namelen) & 3)) % 4) )) printf \"%.s${nilchar}\" $(seq 1 $termpadlen) ---- reproducer.sh ---- Symlink filename fields handled in do_symlink() won't overrun past the data segment, due to the explicit zero-termination of the symlink target. Fix filename buffer overrun by aborting the initramfs FSM if any cpio entry doesn't carry a zero-terminator at the expected (name_len - 1) offset.", "cve_priority": "medium", "cve_public_date": "2024-12-06 10:15:00 UTC" }, { "cve": "CVE-2024-53133", "url": "https://ubuntu.com/security/CVE-2024-53133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Handle dml allocation failure to avoid crash [Why] In the case where a dml allocation fails for any reason, the current state's dml contexts would no longer be valid. Then subsequent calls dc_state_copy_internal would shallow copy invalid memory and if the new state was released, a double free would occur. [How] Reset dml pointers in new_state to NULL and avoid invalid pointer (cherry picked from commit bcafdc61529a48f6f06355d78eb41b3aeda5296c)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53108", "url": "https://ubuntu.com/security/CVE-2024-53108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Adjust VSDB parser for replay feature At some point, the IEEE ID identification for the replay check in the AMD EDID was added. However, this check causes the following out-of-bounds issues when using KASAN: [ 27.804016] BUG: KASAN: slab-out-of-bounds in amdgpu_dm_update_freesync_caps+0xefa/0x17a0 [amdgpu] [ 27.804788] Read of size 1 at addr ffff8881647fdb00 by task systemd-udevd/383 ... [ 27.821207] Memory state around the buggy address: [ 27.821215] ffff8881647fda00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821224] ffff8881647fda80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821234] >ffff8881647fdb00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821243] ^ [ 27.821250] ffff8881647fdb80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821259] ffff8881647fdc00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821268] ================================================================== This is caused because the ID extraction happens outside of the range of the edid lenght. This commit addresses this issue by considering the amd_vsdb_block size. (cherry picked from commit b7e381b1ccd5e778e3d9c44c669ad38439a861d8)", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53134", "url": "https://ubuntu.com/security/CVE-2024-53134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pmdomain: imx93-blk-ctrl: correct remove path The check condition should be 'i < bc->onecell_data.num_domains', not 'bc->onecell_data.num_domains' which will make the look never finish and cause kernel panic. Also disable runtime to address \"imx93-blk-ctrl 4ac10000.system-controller: Unbalanced pm_runtime_enable!\"", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53132", "url": "https://ubuntu.com/security/CVE-2024-53132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/oa: Fix \"Missing outer runtime PM protection\" warning Fix the following drm_WARN: [953.586396] xe 0000:00:02.0: [drm] Missing outer runtime PM protection ... <4> [953.587090] ? xe_pm_runtime_get_noresume+0x8d/0xa0 [xe] <4> [953.587208] guc_exec_queue_add_msg+0x28/0x130 [xe] <4> [953.587319] guc_exec_queue_fini+0x3a/0x40 [xe] <4> [953.587425] xe_exec_queue_destroy+0xb3/0xf0 [xe] <4> [953.587515] xe_oa_release+0x9c/0xc0 [xe] (cherry picked from commit b107c63d2953907908fd0cafb0e543b3c3167b75)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53127", "url": "https://ubuntu.com/security/CVE-2024-53127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Revert \"mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K\" The commit 8396c793ffdf (\"mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K\") increased the max_req_size, even for 4K pages, causing various issues: - Panic booting the kernel/rootfs from an SD card on Rockchip RK3566 - Panic booting the kernel/rootfs from an SD card on StarFive JH7100 - \"swiotlb buffer is full\" and data corruption on StarFive JH7110 At this stage no fix have been found, so it's probably better to just revert the change. This reverts commit 8396c793ffdf28bb8aee7cfe0891080f8cab7890.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53130", "url": "https://ubuntu.com/security/CVE-2024-53130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint When using the \"block:block_dirty_buffer\" tracepoint, mark_buffer_dirty() may cause a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because, since the tracepoint was added in mark_buffer_dirty(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, nilfs_grab_buffer(), which grabs a buffer to read (or create) a block of metadata, including b-tree node blocks, does not set the block device, but instead does so only if the buffer is not in the \"uptodate\" state for each of its caller block reading functions. However, if the uptodate flag is set on a folio/page, and the buffer heads are detached from it by try_to_free_buffers(), and new buffer heads are then attached by create_empty_buffers(), the uptodate flag may be restored to each buffer without the block device being set to bh->b_bdev, and mark_buffer_dirty() may be called later in that state, resulting in the bug mentioned above. Fix this issue by making nilfs_grab_buffer() always set the block device of the super block structure to the buffer head, regardless of the state of the buffer's uptodate flag.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53105", "url": "https://ubuntu.com/security/CVE-2024-53105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: page_alloc: move mlocked flag clearance into free_pages_prepare() Syzbot reported a bad page state problem caused by a page being freed using free_page() still having a mlocked flag at free_pages_prepare() stage: BUG: Bad page state in process syz.5.504 pfn:61f45 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x61f45 flags: 0xfff00000080204(referenced|workingset|mlocked|node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000080204 0000000000000000 dead000000000122 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set page_owner tracks the page as allocated page last allocated via order 0, migratetype Unmovable, gfp_mask 0x400dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO), pid 8443, tgid 8442 (syz.5.504), ts 201884660643, free_ts 201499827394 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1537 prep_new_page mm/page_alloc.c:1545 [inline] get_page_from_freelist+0x303f/0x3190 mm/page_alloc.c:3457 __alloc_pages_noprof+0x292/0x710 mm/page_alloc.c:4733 alloc_pages_mpol_noprof+0x3e8/0x680 mm/mempolicy.c:2265 kvm_coalesced_mmio_init+0x1f/0xf0 virt/kvm/coalesced_mmio.c:99 kvm_create_vm virt/kvm/kvm_main.c:1235 [inline] kvm_dev_ioctl_create_vm virt/kvm/kvm_main.c:5488 [inline] kvm_dev_ioctl+0x12dc/0x2240 virt/kvm/kvm_main.c:5530 __do_compat_sys_ioctl fs/ioctl.c:1007 [inline] __se_compat_sys_ioctl+0x510/0xc90 fs/ioctl.c:950 do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline] __do_fast_syscall_32+0xb4/0x110 arch/x86/entry/common.c:386 do_fast_syscall_32+0x34/0x80 arch/x86/entry/common.c:411 entry_SYSENTER_compat_after_hwframe+0x84/0x8e page last free pid 8399 tgid 8399 stack trace: reset_page_owner include/linux/page_owner.h:25 [inline] free_pages_prepare mm/page_alloc.c:1108 [inline] free_unref_folios+0xf12/0x18d0 mm/page_alloc.c:2686 folios_put_refs+0x76c/0x860 mm/swap.c:1007 free_pages_and_swap_cache+0x5c8/0x690 mm/swap_state.c:335 __tlb_batch_free_encoded_pages mm/mmu_gather.c:136 [inline] tlb_batch_pages_flush mm/mmu_gather.c:149 [inline] tlb_flush_mmu_free mm/mmu_gather.c:366 [inline] tlb_flush_mmu+0x3a3/0x680 mm/mmu_gather.c:373 tlb_finish_mmu+0xd4/0x200 mm/mmu_gather.c:465 exit_mmap+0x496/0xc40 mm/mmap.c:1926 __mmput+0x115/0x390 kernel/fork.c:1348 exit_mm+0x220/0x310 kernel/exit.c:571 do_exit+0x9b2/0x28e0 kernel/exit.c:926 do_group_exit+0x207/0x2c0 kernel/exit.c:1088 __do_sys_exit_group kernel/exit.c:1099 [inline] __se_sys_exit_group kernel/exit.c:1097 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1097 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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 Modules linked in: CPU: 0 UID: 0 PID: 8442 Comm: syz.5.504 Not tainted 6.12.0-rc6-syzkaller #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 bad_page+0x176/0x1d0 mm/page_alloc.c:501 free_page_is_bad mm/page_alloc.c:918 [inline] free_pages_prepare mm/page_alloc.c:1100 [inline] free_unref_page+0xed0/0xf20 mm/page_alloc.c:2638 kvm_destroy_vm virt/kvm/kvm_main.c:1327 [inline] kvm_put_kvm+0xc75/0x1350 virt/kvm/kvm_main.c:1386 kvm_vcpu_release+0x54/0x60 virt/kvm/kvm_main.c:4143 __fput+0x23f/0x880 fs/file_table.c:431 task_work_run+0x24f/0x310 kernel/task_work.c:239 exit_task_work include/linux/task_work.h:43 [inline] do_exit+0xa2f/0x28e0 kernel/exit.c:939 do_group_exit+0x207/0x2c0 kernel/exit.c:1088 __do_sys_exit_group kernel/exit.c:1099 [in ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53109", "url": "https://ubuntu.com/security/CVE-2024-53109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nommu: pass NULL argument to vma_iter_prealloc() When deleting a vma entry from a maple tree, it has to pass NULL to vma_iter_prealloc() in order to calculate internal state of the tree, but it passed a wrong argument. As a result, nommu kernels crashed upon accessing a vma iterator, such as acct_collect() reading the size of vma entries after do_munmap(). This commit fixes this issue by passing a right argument to the preallocation call.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53131", "url": "https://ubuntu.com/security/CVE-2024-53131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint Patch series \"nilfs2: fix null-ptr-deref bugs on block tracepoints\". This series fixes null pointer dereference bugs that occur when using nilfs2 and two block-related tracepoints. This patch (of 2): It has been reported that when using \"block:block_touch_buffer\" tracepoint, touch_buffer() called from __nilfs_get_folio_block() causes a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because since the tracepoint was added in touch_buffer(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, the block_device structure is set after the function returns to the caller. Here, touch_buffer() is used to mark the folio/page that owns the buffer head as accessed, but the common search helper for folio/page used by the caller function was optimized to mark the folio/page as accessed when it was reimplemented a long time ago, eliminating the need to call touch_buffer() here in the first place. So this solves the issue by eliminating the touch_buffer() call itself.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53135", "url": "https://ubuntu.com/security/CVE-2024-53135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: VMX: Bury Intel PT virtualization (guest/host mode) behind CONFIG_BROKEN Hide KVM's pt_mode module param behind CONFIG_BROKEN, i.e. disable support for virtualizing Intel PT via guest/host mode unless BROKEN=y. There are myriad bugs in the implementation, some of which are fatal to the guest, and others which put the stability and health of the host at risk. For guest fatalities, the most glaring issue is that KVM fails to ensure tracing is disabled, and *stays* disabled prior to VM-Enter, which is necessary as hardware disallows loading (the guest's) RTIT_CTL if tracing is enabled (enforced via a VMX consistency check). Per the SDM: If the logical processor is operating with Intel PT enabled (if IA32_RTIT_CTL.TraceEn = 1) at the time of VM entry, the \"load IA32_RTIT_CTL\" VM-entry control must be 0. On the host side, KVM doesn't validate the guest CPUID configuration provided by userspace, and even worse, uses the guest configuration to decide what MSRs to save/load at VM-Enter and VM-Exit. E.g. configuring guest CPUID to enumerate more address ranges than are supported in hardware will result in KVM trying to passthrough, save, and load non-existent MSRs, which generates a variety of WARNs, ToPA ERRORs in the host, a potential deadlock, etc.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53106", "url": "https://ubuntu.com/security/CVE-2024-53106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: fix buffer overrun in ima_eventdigest_init_common Function ima_eventdigest_init() calls ima_eventdigest_init_common() with HASH_ALGO__LAST which is then used to access the array hash_digest_size[] leading to buffer overrun. Have a conditional statement to handle this.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53110", "url": "https://ubuntu.com/security/CVE-2024-53110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vp_vdpa: fix id_table array not null terminated error Allocate one extra virtio_device_id as null terminator, otherwise vdpa_mgmtdev_get_classes() may iterate multiple times and visit undefined memory.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53126", "url": "https://ubuntu.com/security/CVE-2024-53126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa: solidrun: Fix UB bug with devres In psnet_open_pf_bar() and snet_open_vf_bar() a string later passed to pcim_iomap_regions() is placed on the stack. Neither pcim_iomap_regions() nor the functions it calls copy that string. Should the string later ever be used, this, consequently, causes undefined behavior since the stack frame will by then have disappeared. Fix the bug by allocating the strings on the heap through devm_kasprintf().", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53111", "url": "https://ubuntu.com/security/CVE-2024-53111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mremap: fix address wraparound in move_page_tables() On 32-bit platforms, it is possible for the expression `len + old_addr < old_end` to be false-positive if `len + old_addr` wraps around. `old_addr` is the cursor in the old range up to which page table entries have been moved; so if the operation succeeded, `old_addr` is the *end* of the old region, and adding `len` to it can wrap. The overflow causes mremap() to mistakenly believe that PTEs have been copied; the consequence is that mremap() bails out, but doesn't move the PTEs back before the new VMA is unmapped, causing anonymous pages in the region to be lost. So basically if userspace tries to mremap() a private-anon region and hits this bug, mremap() will return an error and the private-anon region's contents appear to have been zeroed. The idea of this check is that `old_end - len` is the original start address, and writing the check that way also makes it easier to read; so fix the check by rearranging the comparison accordingly. (An alternate fix would be to refactor this function by introducing an \"orig_old_start\" variable or such.) Tested in a VM with a 32-bit X86 kernel; without the patch: ``` user@horn:~/big_mremap$ cat test.c #define _GNU_SOURCE #include #include #include #include #define ADDR1 ((void*)0x60000000) #define ADDR2 ((void*)0x10000000) #define SIZE 0x50000000uL int main(void) { unsigned char *p1 = mmap(ADDR1, SIZE, PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0); if (p1 == MAP_FAILED) err(1, \"mmap 1\"); unsigned char *p2 = mmap(ADDR2, SIZE, PROT_NONE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0); if (p2 == MAP_FAILED) err(1, \"mmap 2\"); *p1 = 0x41; printf(\"first char is 0x%02hhx\\n\", *p1); unsigned char *p3 = mremap(p1, SIZE, SIZE, MREMAP_MAYMOVE|MREMAP_FIXED, p2); if (p3 == MAP_FAILED) { printf(\"mremap() failed; first char is 0x%02hhx\\n\", *p1); } else { printf(\"mremap() succeeded; first char is 0x%02hhx\\n\", *p3); } } user@horn:~/big_mremap$ gcc -static -o test test.c user@horn:~/big_mremap$ setarch -R ./test first char is 0x41 mremap() failed; first char is 0x00 ``` With the patch: ``` user@horn:~/big_mremap$ setarch -R ./test first char is 0x41 mremap() succeeded; first char is 0x41 ```", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53107", "url": "https://ubuntu.com/security/CVE-2024-53107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: prevent integer overflow in pagemap_scan_get_args() The \"arg->vec_len\" variable is a u64 that comes from the user at the start of the function. The \"arg->vec_len * sizeof(struct page_region))\" multiplication can lead to integer wrapping. Use size_mul() to avoid that. Also the size_add/mul() functions work on unsigned long so for 32bit systems we need to ensure that \"arg->vec_len\" fits in an unsigned long.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53128", "url": "https://ubuntu.com/security/CVE-2024-53128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/task_stack: fix object_is_on_stack() for KASAN tagged pointers When CONFIG_KASAN_SW_TAGS and CONFIG_KASAN_STACK are enabled, the object_is_on_stack() function may produce incorrect results due to the presence of tags in the obj pointer, while the stack pointer does not have tags. This discrepancy can lead to incorrect stack object detection and subsequently trigger warnings if CONFIG_DEBUG_OBJECTS is also enabled. Example of the warning: ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at lib/debugobjects.c:557 __debug_object_init+0x330/0x364 Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5 #4 Hardware name: linux,dummy-virt (DT) pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __debug_object_init+0x330/0x364 lr : __debug_object_init+0x330/0x364 sp : ffff800082ea7b40 x29: ffff800082ea7b40 x28: 98ff0000c0164518 x27: 98ff0000c0164534 x26: ffff800082d93ec8 x25: 0000000000000001 x24: 1cff0000c00172a0 x23: 0000000000000000 x22: ffff800082d93ed0 x21: ffff800081a24418 x20: 3eff800082ea7bb0 x19: efff800000000000 x18: 0000000000000000 x17: 00000000000000ff x16: 0000000000000047 x15: 206b63617473206e x14: 0000000000000018 x13: ffff800082ea7780 x12: 0ffff800082ea78e x11: 0ffff800082ea790 x10: 0ffff800082ea79d x9 : 34d77febe173e800 x8 : 34d77febe173e800 x7 : 0000000000000001 x6 : 0000000000000001 x5 : feff800082ea74b8 x4 : ffff800082870a90 x3 : ffff80008018d3c4 x2 : 0000000000000001 x1 : ffff800082858810 x0 : 0000000000000050 Call trace: __debug_object_init+0x330/0x364 debug_object_init_on_stack+0x30/0x3c schedule_hrtimeout_range_clock+0xac/0x26c schedule_hrtimeout+0x1c/0x30 wait_task_inactive+0x1d4/0x25c kthread_bind_mask+0x28/0x98 init_rescuer+0x1e8/0x280 workqueue_init+0x1a0/0x3cc kernel_init_freeable+0x118/0x200 kernel_init+0x28/0x1f0 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53112", "url": "https://ubuntu.com/security/CVE-2024-53112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: uncache inode which has failed entering the group Syzbot has reported the following BUG: kernel BUG at fs/ocfs2/uptodate.c:509! ... Call Trace: ? __die_body+0x5f/0xb0 ? die+0x9e/0xc0 ? do_trap+0x15a/0x3a0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? do_error_trap+0x1dc/0x2c0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? __pfx_do_error_trap+0x10/0x10 ? handle_invalid_op+0x34/0x40 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? exc_invalid_op+0x38/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? ocfs2_set_new_buffer_uptodate+0x2e/0x160 ? ocfs2_set_new_buffer_uptodate+0x144/0x160 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ocfs2_group_add+0x39f/0x15a0 ? __pfx_ocfs2_group_add+0x10/0x10 ? __pfx_lock_acquire+0x10/0x10 ? mnt_get_write_access+0x68/0x2b0 ? __pfx_lock_release+0x10/0x10 ? rcu_read_lock_any_held+0xb7/0x160 ? __pfx_rcu_read_lock_any_held+0x10/0x10 ? smack_log+0x123/0x540 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x226/0x2b0 ocfs2_ioctl+0x65e/0x7d0 ? __pfx_ocfs2_ioctl+0x10/0x10 ? smack_file_ioctl+0x29e/0x3a0 ? __pfx_smack_file_ioctl+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x43d/0x780 ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10 ? __pfx_ocfs2_ioctl+0x10/0x10 __se_sys_ioctl+0xfb/0x170 do_syscall_64+0xf3/0x230 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... When 'ioctl(OCFS2_IOC_GROUP_ADD, ...)' has failed for the particular inode in 'ocfs2_verify_group_and_input()', corresponding buffer head remains cached and subsequent call to the same 'ioctl()' for the same inode issues the BUG() in 'ocfs2_set_new_buffer_uptodate()' (trying to cache the same buffer head of that inode). Fix this by uncaching the buffer head with 'ocfs2_remove_from_cache()' on error path in 'ocfs2_group_add()'.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53113", "url": "https://ubuntu.com/security/CVE-2024-53113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: fix NULL pointer dereference in alloc_pages_bulk_noprof We triggered a NULL pointer dereference for ac.preferred_zoneref->zone in alloc_pages_bulk_noprof() when the task is migrated between cpusets. When cpuset is enabled, in prepare_alloc_pages(), ac->nodemask may be ¤t->mems_allowed. when first_zones_zonelist() is called to find preferred_zoneref, the ac->nodemask may be modified concurrently if the task is migrated between different cpusets. Assuming we have 2 NUMA Node, when traversing Node1 in ac->zonelist, the nodemask is 2, and when traversing Node2 in ac->zonelist, the nodemask is 1. As a result, the ac->preferred_zoneref points to NULL zone. In alloc_pages_bulk_noprof(), for_each_zone_zonelist_nodemask() finds a allowable zone and calls zonelist_node_idx(ac.preferred_zoneref), leading to NULL pointer dereference. __alloc_pages_noprof() fixes this issue by checking NULL pointer in commit ea57485af8f4 (\"mm, page_alloc: fix check for NULL preferred_zone\") and commit df76cee6bbeb (\"mm, page_alloc: remove redundant checks from alloc fastpath\"). To fix it, check NULL pointer for preferred_zoneref->zone.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53114", "url": "https://ubuntu.com/security/CVE-2024-53114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 client A number of Zen4 client SoCs advertise the ability to use virtualized VMLOAD/VMSAVE, but using these instructions is reported to be a cause of a random host reboot. These instructions aren't intended to be advertised on Zen4 client so clear the capability.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53137", "url": "https://ubuntu.com/security/CVE-2024-53137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: fix cacheflush with PAN It seems that the cacheflush syscall got broken when PAN for LPAE was implemented. User access was not enabled around the cache maintenance instructions, causing them to fault.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53115", "url": "https://ubuntu.com/security/CVE-2024-53115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: avoid null_ptr_deref in vmw_framebuffer_surface_create_handle The 'vmw_user_object_buffer' function may return NULL with incorrect inputs. To avoid possible null pointer dereference, add a check whether the 'bo' is NULL in the vmw_framebuffer_surface_create_handle.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53116", "url": "https://ubuntu.com/security/CVE-2024-53116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix handling of partial GPU mapping of BOs This commit fixes the bug in the handling of partial mapping of the buffer objects to the GPU, which caused kernel warnings. Panthor didn't correctly handle the case where the partial mapping spanned multiple scatterlists and the mapping offset didn't point to the 1st page of starting scatterlist. The offset variable was not cleared after reaching the starting scatterlist. Following warning messages were seen. WARNING: CPU: 1 PID: 650 at drivers/iommu/io-pgtable-arm.c:659 __arm_lpae_unmap+0x254/0x5a0 pc : __arm_lpae_unmap+0x254/0x5a0 lr : __arm_lpae_unmap+0x2cc/0x5a0 Call trace: __arm_lpae_unmap+0x254/0x5a0 __arm_lpae_unmap+0x108/0x5a0 __arm_lpae_unmap+0x108/0x5a0 __arm_lpae_unmap+0x108/0x5a0 arm_lpae_unmap_pages+0x80/0xa0 panthor_vm_unmap_pages+0xac/0x1c8 [panthor] panthor_gpuva_sm_step_unmap+0x4c/0xc8 [panthor] op_unmap_cb.isra.23.constprop.30+0x54/0x80 __drm_gpuvm_sm_unmap+0x184/0x1c8 drm_gpuvm_sm_unmap+0x40/0x60 panthor_vm_exec_op+0xa8/0x120 [panthor] panthor_vm_bind_exec_sync_op+0xc4/0xe8 [panthor] panthor_ioctl_vm_bind+0x10c/0x170 [panthor] drm_ioctl_kernel+0xbc/0x138 drm_ioctl+0x210/0x4b0 __arm64_sys_ioctl+0xb0/0xf8 invoke_syscall+0x4c/0x110 el0_svc_common.constprop.1+0x98/0xf8 do_el0_svc+0x24/0x38 el0_svc+0x34/0xc8 el0t_64_sync_handler+0xa0/0xc8 el0t_64_sync+0x174/0x178 panthor : [drm] drm_WARN_ON(unmapped_sz != pgsize * pgcount) WARNING: CPU: 1 PID: 650 at drivers/gpu/drm/panthor/panthor_mmu.c:922 panthor_vm_unmap_pages+0x124/0x1c8 [panthor] pc : panthor_vm_unmap_pages+0x124/0x1c8 [panthor] lr : panthor_vm_unmap_pages+0x124/0x1c8 [panthor] panthor : [drm] *ERROR* failed to unmap range ffffa388f000-ffffa3890000 (requested range ffffa388c000-ffffa3890000)", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53117", "url": "https://ubuntu.com/security/CVE-2024-53117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio/vsock: Improve MSG_ZEROCOPY error handling Add a missing kfree_skb() to prevent memory leaks.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53118", "url": "https://ubuntu.com/security/CVE-2024-53118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Fix sk_error_queue memory leak Kernel queues MSG_ZEROCOPY completion notifications on the error queue. Where they remain, until explicitly recv()ed. To prevent memory leaks, clean up the queue when the socket is destroyed. unreferenced object 0xffff8881028beb00 (size 224): comm \"vsock_test\", pid 1218, jiffies 4294694897 hex dump (first 32 bytes): 90 b0 21 17 81 88 ff ff 90 b0 21 17 81 88 ff ff ..!.......!..... 00 00 00 00 00 00 00 00 00 b0 21 17 81 88 ff ff ..........!..... backtrace (crc 6c7031ca): [] kmem_cache_alloc_node_noprof+0x2f7/0x370 [] __alloc_skb+0x132/0x180 [] sock_omalloc+0x4b/0x80 [] msg_zerocopy_realloc+0x9e/0x240 [] virtio_transport_send_pkt_info+0x412/0x4c0 [] virtio_transport_stream_enqueue+0x43/0x50 [] vsock_connectible_sendmsg+0x373/0x450 [] ____sys_sendmsg+0x365/0x3a0 [] ___sys_sendmsg+0x84/0xd0 [] __sys_sendmsg+0x47/0x80 [] do_syscall_64+0x93/0x180 [] entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53119", "url": "https://ubuntu.com/security/CVE-2024-53119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio/vsock: Fix accept_queue memory leak As the final stages of socket destruction may be delayed, it is possible that virtio_transport_recv_listen() will be called after the accept_queue has been flushed, but before the SOCK_DONE flag has been set. As a result, sockets enqueued after the flush would remain unremoved, leading to a memory leak. vsock_release __vsock_release lock virtio_transport_release virtio_transport_close schedule_delayed_work(close_work) sk_shutdown = SHUTDOWN_MASK (!) flush accept_queue release virtio_transport_recv_pkt vsock_find_bound_socket lock if flag(SOCK_DONE) return virtio_transport_recv_listen child = vsock_create_connected (!) vsock_enqueue_accept(child) release close_work lock virtio_transport_do_close set_flag(SOCK_DONE) virtio_transport_remove_sock vsock_remove_sock vsock_remove_bound release Introduce a sk_shutdown check to disallow vsock_enqueue_accept() during socket destruction. unreferenced object 0xffff888109e3f800 (size 2040): comm \"kworker/5:2\", pid 371, jiffies 4294940105 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00 (..@............ backtrace (crc 9e5f4e84): [] kmem_cache_alloc_noprof+0x2c1/0x360 [] sk_prot_alloc+0x30/0x120 [] sk_alloc+0x2c/0x4b0 [] __vsock_create.constprop.0+0x2a/0x310 [] virtio_transport_recv_pkt+0x4dc/0x9a0 [] vsock_loopback_work+0xfd/0x140 [] process_one_work+0x20c/0x570 [] worker_thread+0x1bf/0x3a0 [] kthread+0xdd/0x110 [] ret_from_fork+0x2d/0x50 [] ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53120", "url": "https://ubuntu.com/security/CVE-2024-53120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: CT: Fix null-ptr-deref in add rule err flow In error flow of mlx5_tc_ct_entry_add_rule(), in case ct_rule_add() callback returns error, zone_rule->attr is used uninitiated. Fix it to use attr which has the needed pointer value. Kernel log: BUG: kernel NULL pointer dereference, address: 0000000000000110 RIP: 0010:mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core] … Call Trace: ? __die+0x20/0x70 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x140 ? asm_exc_page_fault+0x22/0x30 ? mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core] ? mlx5_tc_ct_entry_add_rule+0x1d5/0x2f0 [mlx5_core] mlx5_tc_ct_block_flow_offload+0xc6a/0xf90 [mlx5_core] ? nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] flow_offload_work_handler+0x142/0x320 [nf_flow_table] ? finish_task_switch.isra.0+0x15b/0x2b0 process_one_work+0x16c/0x320 worker_thread+0x28c/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xb8/0xf0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53138", "url": "https://ubuntu.com/security/CVE-2024-53138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: kTLS, Fix incorrect page refcounting The kTLS tx handling code is using a mix of get_page() and page_ref_inc() APIs to increment the page reference. But on the release path (mlx5e_ktls_tx_handle_resync_dump_comp()), only put_page() is used. This is an issue when using pages from large folios: the get_page() references are stored on the folio page while the page_ref_inc() references are stored directly in the given page. On release the folio page will be dereferenced too many times. This was found while doing kTLS testing with sendfile() + ZC when the served file was read from NFS on a kernel with NFS large folios support (commit 49b29a573da8 (\"nfs: add support for large folios\")).", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53121", "url": "https://ubuntu.com/security/CVE-2024-53121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: fs, lock FTE when checking if active The referenced commits introduced a two-step process for deleting FTEs: - Lock the FTE, delete it from hardware, set the hardware deletion function to NULL and unlock the FTE. - Lock the parent flow group, delete the software copy of the FTE, and remove it from the xarray. However, this approach encounters a race condition if a rule with the same match value is added simultaneously. In this scenario, fs_core may set the hardware deletion function to NULL prematurely, causing a panic during subsequent rule deletions. To prevent this, ensure the active flag of the FTE is checked under a lock, which will prevent the fs_core layer from attaching a new steering rule to an FTE that is in the process of deletion. [ 438.967589] MOSHE: 2496 mlx5_del_flow_rules del_hw_func [ 438.968205] ------------[ cut here ]------------ [ 438.968654] refcount_t: decrement hit 0; leaking memory. [ 438.969249] WARNING: CPU: 0 PID: 8957 at lib/refcount.c:31 refcount_warn_saturate+0xfb/0x110 [ 438.970054] Modules linked in: act_mirred cls_flower act_gact sch_ingress openvswitch nsh mlx5_vdpa vringh vhost_iotlb vdpa mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core zram zsmalloc fuse [last unloaded: cls_flower] [ 438.973288] CPU: 0 UID: 0 PID: 8957 Comm: tc Not tainted 6.12.0-rc1+ #8 [ 438.973888] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 438.974874] RIP: 0010:refcount_warn_saturate+0xfb/0x110 [ 438.975363] Code: 40 66 3b 82 c6 05 16 e9 4d 01 01 e8 1f 7c a0 ff 0f 0b c3 cc cc cc cc 48 c7 c7 10 66 3b 82 c6 05 fd e8 4d 01 01 e8 05 7c a0 ff <0f> 0b c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 90 [ 438.976947] RSP: 0018:ffff888124a53610 EFLAGS: 00010286 [ 438.977446] RAX: 0000000000000000 RBX: ffff888119d56de0 RCX: 0000000000000000 [ 438.978090] RDX: ffff88852c828700 RSI: ffff88852c81b3c0 RDI: ffff88852c81b3c0 [ 438.978721] RBP: ffff888120fa0e88 R08: 0000000000000000 R09: ffff888124a534b0 [ 438.979353] R10: 0000000000000001 R11: 0000000000000001 R12: ffff888119d56de0 [ 438.979979] R13: ffff888120fa0ec0 R14: ffff888120fa0ee8 R15: ffff888119d56de0 [ 438.980607] FS: 00007fe6dcc0f800(0000) GS:ffff88852c800000(0000) knlGS:0000000000000000 [ 438.983984] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 438.984544] CR2: 00000000004275e0 CR3: 0000000186982001 CR4: 0000000000372eb0 [ 438.985205] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 438.985842] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 438.986507] Call Trace: [ 438.986799] [ 438.987070] ? __warn+0x7d/0x110 [ 438.987426] ? refcount_warn_saturate+0xfb/0x110 [ 438.987877] ? report_bug+0x17d/0x190 [ 438.988261] ? prb_read_valid+0x17/0x20 [ 438.988659] ? handle_bug+0x53/0x90 [ 438.989054] ? exc_invalid_op+0x14/0x70 [ 438.989458] ? asm_exc_invalid_op+0x16/0x20 [ 438.989883] ? refcount_warn_saturate+0xfb/0x110 [ 438.990348] mlx5_del_flow_rules+0x2f7/0x340 [mlx5_core] [ 438.990932] __mlx5_eswitch_del_rule+0x49/0x170 [mlx5_core] [ 438.991519] ? mlx5_lag_is_sriov+0x3c/0x50 [mlx5_core] [ 438.992054] ? xas_load+0x9/0xb0 [ 438.992407] mlx5e_tc_rule_unoffload+0x45/0xe0 [mlx5_core] [ 438.993037] mlx5e_tc_del_fdb_flow+0x2a6/0x2e0 [mlx5_core] [ 438.993623] mlx5e_flow_put+0x29/0x60 [mlx5_core] [ 438.994161] mlx5e_delete_flower+0x261/0x390 [mlx5_core] [ 438.994728] tc_setup_cb_destroy+0xb9/0x190 [ 438.995150] fl_hw_destroy_filter+0x94/0xc0 [cls_flower] [ 438.995650] fl_change+0x11a4/0x13c0 [cls_flower] [ 438.996105] tc_new_tfilter+0x347/0xbc0 [ 438.996503] ? __ ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53122", "url": "https://ubuntu.com/security/CVE-2024-53122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: cope racing subflow creation in mptcp_rcv_space_adjust Additional active subflows - i.e. created by the in kernel path manager - are included into the subflow list before starting the 3whs. A racing recvmsg() spooling data received on an already established subflow would unconditionally call tcp_cleanup_rbuf() on all the current subflows, potentially hitting a divide by zero error on the newly created ones. Explicitly check that the subflow is in a suitable state before invoking tcp_cleanup_rbuf().", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53123", "url": "https://ubuntu.com/security/CVE-2024-53123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: error out earlier on disconnect Eric reported a division by zero splat in the MPTCP protocol: Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 6094 Comm: syz-executor317 Not tainted 6.12.0-rc5-syzkaller-00291-g05b92660cdfe #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:__tcp_select_window+0x5b4/0x1310 net/ipv4/tcp_output.c:3163 Code: f6 44 01 e3 89 df e8 9b 75 09 f8 44 39 f3 0f 8d 11 ff ff ff e8 0d 74 09 f8 45 89 f4 e9 04 ff ff ff e8 00 74 09 f8 44 89 f0 99 7c 24 14 41 29 d6 45 89 f4 e9 ec fe ff ff e8 e8 73 09 f8 48 89 RSP: 0018:ffffc900041f7930 EFLAGS: 00010293 RAX: 0000000000017e67 RBX: 0000000000017e67 RCX: ffffffff8983314b RDX: 0000000000000000 RSI: ffffffff898331b0 RDI: 0000000000000004 RBP: 00000000005d6000 R08: 0000000000000004 R09: 0000000000017e67 R10: 0000000000003e80 R11: 0000000000000000 R12: 0000000000003e80 R13: ffff888031d9b440 R14: 0000000000017e67 R15: 00000000002eb000 FS: 00007feb5d7f16c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007feb5d8adbb8 CR3: 0000000074e4c000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __tcp_cleanup_rbuf+0x3e7/0x4b0 net/ipv4/tcp.c:1493 mptcp_rcv_space_adjust net/mptcp/protocol.c:2085 [inline] mptcp_recvmsg+0x2156/0x2600 net/mptcp/protocol.c:2289 inet_recvmsg+0x469/0x6a0 net/ipv4/af_inet.c:885 sock_recvmsg_nosec net/socket.c:1051 [inline] sock_recvmsg+0x1b2/0x250 net/socket.c:1073 __sys_recvfrom+0x1a5/0x2e0 net/socket.c:2265 __do_sys_recvfrom net/socket.c:2283 [inline] __se_sys_recvfrom net/socket.c:2279 [inline] __x64_sys_recvfrom+0xe0/0x1c0 net/socket.c:2279 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 RIP: 0033:0x7feb5d857559 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:00007feb5d7f1208 EFLAGS: 00000246 ORIG_RAX: 000000000000002d RAX: ffffffffffffffda RBX: 00007feb5d8e1318 RCX: 00007feb5d857559 RDX: 000000800000000e RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007feb5d8e1310 R08: 0000000000000000 R09: ffffffff81000000 R10: 0000000000000100 R11: 0000000000000246 R12: 00007feb5d8e131c R13: 00007feb5d8ae074 R14: 000000800000000e R15: 00000000fffffdef and provided a nice reproducer. The root cause is the current bad handling of racing disconnect. After the blamed commit below, sk_wait_data() can return (with error) with the underlying socket disconnected and a zero rcv_mss. Catch the error and return without performing any additional operations on the current socket.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53124", "url": "https://ubuntu.com/security/CVE-2024-53124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix data-races around sk->sk_forward_alloc Syzkaller reported this warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 16 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x1c5/0x1e0 Modules linked in: CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:inet_sock_destruct+0x1c5/0x1e0 Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 <0f> 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00 RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206 RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007 RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00 RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007 R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00 R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78 FS: 0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn+0x88/0x130 ? inet_sock_destruct+0x1c5/0x1e0 ? report_bug+0x18e/0x1a0 ? handle_bug+0x53/0x90 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? inet_sock_destruct+0x1c5/0x1e0 __sk_destruct+0x2a/0x200 rcu_do_batch+0x1aa/0x530 ? rcu_do_batch+0x13b/0x530 rcu_core+0x159/0x2f0 handle_softirqs+0xd3/0x2b0 ? __pfx_smpboot_thread_fn+0x10/0x10 run_ksoftirqd+0x25/0x30 smpboot_thread_fn+0xdd/0x1d0 kthread+0xd3/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ---[ end trace 0000000000000000 ]--- Its possible that two threads call tcp_v6_do_rcv()/sk_forward_alloc_add() concurrently when sk->sk_state == TCP_LISTEN with sk->sk_lock unlocked, which triggers a data-race around sk->sk_forward_alloc: tcp_v6_rcv tcp_v6_do_rcv skb_clone_and_charge_r sk_rmem_schedule __sk_mem_schedule sk_forward_alloc_add() skb_set_owner_r sk_mem_charge sk_forward_alloc_add() __kfree_skb skb_release_all skb_release_head_state sock_rfree sk_mem_uncharge sk_forward_alloc_add() sk_mem_reclaim // set local var reclaimable __sk_mem_reclaim sk_forward_alloc_add() In this syzkaller testcase, two threads call tcp_v6_do_rcv() with skb->truesize=768, the sk_forward_alloc changes like this: (cpu 1) | (cpu 2) | sk_forward_alloc ... | ... | 0 __sk_mem_schedule() | | +4096 = 4096 | __sk_mem_schedule() | +4096 = 8192 sk_mem_charge() | | -768 = 7424 | sk_mem_charge() | -768 = 6656 ... | ... | sk_mem_uncharge() | | +768 = 7424 reclaimable=7424 | | | sk_mem_uncharge() | +768 = 8192 | reclaimable=8192 | __sk_mem_reclaim() | | -4096 = 4096 | __sk_mem_reclaim() | -8192 = -4096 != 0 The skb_clone_and_charge_r() should not be called in tcp_v6_do_rcv() when sk->sk_state is TCP_LISTEN, it happens later in tcp_v6_syn_recv_sock(). Fix the same issue in dccp_v6_do_rcv().", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53129", "url": "https://ubuntu.com/security/CVE-2024-53129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: vop: Fix a dereferenced before check warning The 'state' can't be NULL, we should check crtc_state. Fix warning: drivers/gpu/drm/rockchip/rockchip_drm_vop.c:1096 vop_plane_atomic_async_check() warn: variable dereferenced before check 'state' (see line 1077)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53139", "url": "https://ubuntu.com/security/CVE-2024-53139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix possible UAF in sctp_v6_available() A lockdep report [1] with CONFIG_PROVE_RCU_LIST=y hints that sctp_v6_available() is calling dev_get_by_index_rcu() and ipv6_chk_addr() without holding rcu. [1] ============================= WARNING: suspicious RCU usage 6.12.0-rc5-virtme #1216 Tainted: G W ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by sctp_hello/31495: #0: ffff9f1ebbdb7418 (sk_lock-AF_INET6){+.+.}-{0:0}, at: sctp_bind (./arch/x86/include/asm/jump_label.h:27 net/sctp/socket.c:315) sctp stack backtrace: CPU: 7 UID: 0 PID: 31495 Comm: sctp_hello Tainted: G W 6.12.0-rc5-virtme #1216 Tainted: [W]=WARN 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:123) lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822) dev_get_by_index_rcu (net/core/dev.c:876 (discriminator 7)) sctp_v6_available (net/sctp/ipv6.c:701) sctp sctp_do_bind (net/sctp/socket.c:400 (discriminator 1)) sctp sctp_bind (net/sctp/socket.c:320) sctp inet6_bind_sk (net/ipv6/af_inet6.c:465) ? security_socket_bind (security/security.c:4581 (discriminator 1)) __sys_bind (net/socket.c:1848 net/socket.c:1869) ? do_user_addr_fault (./include/linux/rcupdate.h:347 ./include/linux/rcupdate.h:880 ./include/linux/mm.h:729 arch/x86/mm/fault.c:1340) ? do_user_addr_fault (./arch/x86/include/asm/preempt.h:84 (discriminator 13) ./include/linux/rcupdate.h:98 (discriminator 13) ./include/linux/rcupdate.h:882 (discriminator 13) ./include/linux/mm.h:729 (discriminator 13) arch/x86/mm/fault.c:1340 (discriminator 13)) __x64_sys_bind (net/socket.c:1877 (discriminator 1) net/socket.c:1875 (discriminator 1) net/socket.c:1875 (discriminator 1)) do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f59b934a1e7 Code: 44 00 00 48 8b 15 39 8c 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 b8 31 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 09 8c 0c 00 f7 d8 64 89 01 48 All code ======== 0:\t44 00 00 \tadd %r8b,(%rax) 3:\t48 8b 15 39 8c 0c 00 \tmov 0xc8c39(%rip),%rdx # 0xc8c43 a:\tf7 d8 \tneg %eax c:\t64 89 02 \tmov %eax,%fs:(%rdx) f:\tb8 ff ff ff ff \tmov $0xffffffff,%eax 14:\teb bd \tjmp 0xffffffffffffffd3 16:\t66 2e 0f 1f 84 00 00 \tcs nopw 0x0(%rax,%rax,1) 1d:\t00 00 00 20:\t0f 1f 00 \tnopl (%rax) 23:\tb8 31 00 00 00 \tmov $0x31,%eax 28:\t0f 05 \tsyscall 2a:*\t48 3d 01 f0 ff ff \tcmp $0xfffffffffffff001,%rax\t\t<-- trapping instruction 30:\t73 01 \tjae 0x33 32:\tc3 \tret 33:\t48 8b 0d 09 8c 0c 00 \tmov 0xc8c09(%rip),%rcx # 0xc8c43 3a:\tf7 d8 \tneg %eax 3c:\t64 89 01 \tmov %eax,%fs:(%rcx) 3f:\t48 \trex.W Code starting with the faulting instruction =========================================== 0:\t48 3d 01 f0 ff ff \tcmp $0xfffffffffffff001,%rax 6:\t73 01 \tjae 0x9 8:\tc3 \tret 9:\t48 8b 0d 09 8c 0c 00 \tmov 0xc8c09(%rip),%rcx # 0xc8c19 10:\tf7 d8 \tneg %eax 12:\t64 89 01 \tmov %eax,%fs:(%rcx) 15:\t48 \trex.W RSP: 002b:00007ffe2d0ad398 EFLAGS: 00000202 ORIG_RAX: 0000000000000031 RAX: ffffffffffffffda RBX: 00007ffe2d0ad3d0 RCX: 00007f59b934a1e7 RDX: 000000000000001c RSI: 00007ffe2d0ad3d0 RDI: 0000000000000005 RBP: 0000000000000005 R08: 1999999999999999 R09: 0000000000000000 R10: 00007f59b9253298 R11: 000000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53140", "url": "https://ubuntu.com/security/CVE-2024-53140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netlink: terminate outstanding dump on socket close Netlink supports iterative dumping of data. It provides the families the following ops: - start - (optional) kicks off the dumping process - dump - actual dump helper, keeps getting called until it returns 0 - done - (optional) pairs with .start, can be used for cleanup The whole process is asynchronous and the repeated calls to .dump don't actually happen in a tight loop, but rather are triggered in response to recvmsg() on the socket. This gives the user full control over the dump, but also means that the user can close the socket without getting to the end of the dump. To make sure .start is always paired with .done we check if there is an ongoing dump before freeing the socket, and if so call .done. The complication is that sockets can get freed from BH and .done is allowed to sleep. So we use a workqueue to defer the call, when needed. Unfortunately this does not work correctly. What we defer is not the cleanup but rather releasing a reference on the socket. We have no guarantee that we own the last reference, if someone else holds the socket they may release it in BH and we're back to square one. The whole dance, however, appears to be unnecessary. Only the user can interact with dumps, so we can clean up when socket is closed. And close always happens in process context. Some async code may still access the socket after close, queue notification skbs to it etc. but no dumps can start, end or otherwise make progress. Delete the workqueue and flush the dump state directly from the release handler. Note that further cleanup is possible in -next, for instance we now always call .done before releasing the main module reference, so dump doesn't have to take a reference of its own.", "cve_priority": "high", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53098", "url": "https://ubuntu.com/security/CVE-2024-53098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/ufence: Prefetch ufence addr to catch bogus address access_ok() only checks for addr overflow so also try to read the addr to catch invalid addr sent from userspace. (cherry picked from commit 9408c4508483ffc60811e910a93d6425b8e63928)", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53099", "url": "https://ubuntu.com/security/CVE-2024-53099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check validity of link->type in bpf_link_show_fdinfo() If a newly-added link type doesn't invoke BPF_LINK_TYPE(), accessing bpf_link_type_strs[link->type] may result in an out-of-bounds access. To spot such missed invocations early in the future, checking the validity of link->type in bpf_link_show_fdinfo() and emitting a warning when such invocations are missed.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53089", "url": "https://ubuntu.com/security/CVE-2024-53089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: KVM: Mark hrtimer to expire in hard interrupt context Like commit 2c0d278f3293f (\"KVM: LAPIC: Mark hrtimer to expire in hard interrupt context\") and commit 9090825fa9974 (\"KVM: arm/arm64: Let the timer expire in hardirq context on RT\"), On PREEMPT_RT enabled kernels unmarked hrtimers are moved into soft interrupt expiry mode by default. Then the timers are canceled from an preempt-notifier which is invoked with disabled preemption which is not allowed on PREEMPT_RT. The timer callback is short so in could be invoked in hard-IRQ context. So let the timer expire on hard-IRQ context even on -RT. This fix a \"scheduling while atomic\" bug for PREEMPT_RT enabled kernels: BUG: scheduling while atomic: qemu-system-loo/1011/0x00000002 Modules linked in: amdgpu rfkill nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat ns CPU: 1 UID: 0 PID: 1011 Comm: qemu-system-loo Tainted: G W 6.12.0-rc2+ #1774 Tainted: [W]=WARN Hardware name: Loongson Loongson-3A5000-7A1000-1w-CRB/Loongson-LS3A5000-7A1000-1w-CRB, BIOS vUDK2018-LoongArch-V2.0.0-prebeta9 10/21/2022 Stack : ffffffffffffffff 0000000000000000 9000000004e3ea38 9000000116744000 90000001167475a0 0000000000000000 90000001167475a8 9000000005644830 90000000058dc000 90000000058dbff8 9000000116747420 0000000000000001 0000000000000001 6a613fc938313980 000000000790c000 90000001001c1140 00000000000003fe 0000000000000001 000000000000000d 0000000000000003 0000000000000030 00000000000003f3 000000000790c000 9000000116747830 90000000057ef000 0000000000000000 9000000005644830 0000000000000004 0000000000000000 90000000057f4b58 0000000000000001 9000000116747868 900000000451b600 9000000005644830 9000000003a13998 0000000010000020 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d ... Call Trace: [<9000000003a13998>] show_stack+0x38/0x180 [<9000000004e3ea34>] dump_stack_lvl+0x84/0xc0 [<9000000003a71708>] __schedule_bug+0x48/0x60 [<9000000004e45734>] __schedule+0x1114/0x1660 [<9000000004e46040>] schedule_rtlock+0x20/0x60 [<9000000004e4e330>] rtlock_slowlock_locked+0x3f0/0x10a0 [<9000000004e4f038>] rt_spin_lock+0x58/0x80 [<9000000003b02d68>] hrtimer_cancel_wait_running+0x68/0xc0 [<9000000003b02e30>] hrtimer_cancel+0x70/0x80 [] kvm_restore_timer+0x50/0x1a0 [kvm] [] kvm_arch_vcpu_load+0x68/0x2a0 [kvm] [] kvm_sched_in+0x34/0x60 [kvm] [<9000000003a749a0>] finish_task_switch.isra.0+0x140/0x2e0 [<9000000004e44a70>] __schedule+0x450/0x1660 [<9000000004e45cb0>] schedule+0x30/0x180 [] kvm_vcpu_block+0x70/0x120 [kvm] [] kvm_vcpu_halt+0x60/0x3e0 [kvm] [] kvm_handle_gspr+0x3f4/0x4e0 [kvm] [] kvm_handle_exit+0x1c8/0x260 [kvm]", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53090", "url": "https://ubuntu.com/security/CVE-2024-53090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix lock recursion afs_wake_up_async_call() can incur lock recursion. The problem is that it is called from AF_RXRPC whilst holding the ->notify_lock, but it tries to take a ref on the afs_call struct in order to pass it to a work queue - but if the afs_call is already queued, we then have an extraneous ref that must be put... calling afs_put_call() may call back down into AF_RXRPC through rxrpc_kernel_shutdown_call(), however, which might try taking the ->notify_lock again. This case isn't very common, however, so defer it to a workqueue. The oops looks something like: BUG: spinlock recursion on CPU#0, krxrpcio/7001/1646 lock: 0xffff888141399b30, .magic: dead4ead, .owner: krxrpcio/7001/1646, .owner_cpu: 0 CPU: 0 UID: 0 PID: 1646 Comm: krxrpcio/7001 Not tainted 6.12.0-rc2-build3+ #4351 Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014 Call Trace: dump_stack_lvl+0x47/0x70 do_raw_spin_lock+0x3c/0x90 rxrpc_kernel_shutdown_call+0x83/0xb0 afs_put_call+0xd7/0x180 rxrpc_notify_socket+0xa0/0x190 rxrpc_input_split_jumbo+0x198/0x1d0 rxrpc_input_data+0x14b/0x1e0 ? rxrpc_input_call_packet+0xc2/0x1f0 rxrpc_input_call_event+0xad/0x6b0 rxrpc_input_packet_on_conn+0x1e1/0x210 rxrpc_input_packet+0x3f2/0x4d0 rxrpc_io_thread+0x243/0x410 ? __pfx_rxrpc_io_thread+0x10/0x10 kthread+0xcf/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x24/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53101", "url": "https://ubuntu.com/security/CVE-2024-53101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized value issue in from_kuid and from_kgid ocfs2_setattr() uses attr->ia_mode, attr->ia_uid and attr->ia_gid in a trace point even though ATTR_MODE, ATTR_UID and ATTR_GID aren't set. Initialize all fields of newattrs to avoid uninitialized variables, by checking if ATTR_MODE, ATTR_UID, ATTR_GID are initialized, otherwise 0.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53091", "url": "https://ubuntu.com/security/CVE-2024-53091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Add sk_is_inet and IS_ICSK check in tls_sw_has_ctx_tx/rx As the introduction of the support for vsock and unix sockets in sockmap, tls_sw_has_ctx_tx/rx cannot presume the socket passed in must be IS_ICSK. vsock and af_unix sockets have vsock_sock and unix_sock instead of inet_connection_sock. For these sockets, tls_get_ctx may return an invalid pointer and cause page fault in function tls_sw_ctx_rx. BUG: unable to handle page fault for address: 0000000000040030 Workqueue: vsock-loopback vsock_loopback_work RIP: 0010:sk_psock_strp_data_ready+0x23/0x60 Call Trace: ? __die+0x81/0xc3 ? no_context+0x194/0x350 ? do_page_fault+0x30/0x110 ? async_page_fault+0x3e/0x50 ? sk_psock_strp_data_ready+0x23/0x60 virtio_transport_recv_pkt+0x750/0x800 ? update_load_avg+0x7e/0x620 vsock_loopback_work+0xd0/0x100 process_one_work+0x1a7/0x360 worker_thread+0x30/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x112/0x130 ? __kthread_cancel_work+0x40/0x40 ret_from_fork+0x1f/0x40 v2: - Add IS_ICSK check v3: - Update the commits in Fixes", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53092", "url": "https://ubuntu.com/security/CVE-2024-53092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_pci: Fix admin vq cleanup by using correct info pointer vp_modern_avq_cleanup() and vp_del_vqs() clean up admin vq resources by virtio_pci_vq_info pointer. The info pointer of admin vq is stored in vp_dev->admin_vq.info instead of vp_dev->vqs[]. Using the info pointer from vp_dev->vqs[] for admin vq causes a kernel NULL pointer dereference bug. In vp_modern_avq_cleanup() and vp_del_vqs(), get the info pointer from vp_dev->admin_vq.info for admin vq to clean up the resources. Also make info ptr as argument of vp_del_vq() to be symmetric with vp_setup_vq(). vp_reset calls vp_modern_avq_cleanup, and causes the Call Trace: ================================================================== BUG: kernel NULL pointer dereference, address:0000000000000000 ... CPU: 49 UID: 0 PID: 4439 Comm: modprobe Not tainted 6.11.0-rc5 #1 RIP: 0010:vp_reset+0x57/0x90 [virtio_pci] Call Trace: ... ? vp_reset+0x57/0x90 [virtio_pci] ? vp_reset+0x38/0x90 [virtio_pci] virtio_reset_device+0x1d/0x30 remove_vq_common+0x1c/0x1a0 [virtio_net] virtnet_remove+0xa1/0xc0 [virtio_net] virtio_dev_remove+0x46/0xa0 ... virtio_pci_driver_exit+0x14/0x810 [virtio_pci] ==================================================================", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53102", "url": "https://ubuntu.com/security/CVE-2024-53102", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53093", "url": "https://ubuntu.com/security/CVE-2024-53093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: defer partition scanning We need to suppress the partition scan from occuring within the controller's scan_work context. If a path error occurs here, the IO will wait until a path becomes available or all paths are torn down, but that action also occurs within scan_work, so it would deadlock. Defer the partion scan to a different context that does not block scan_work.", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53094", "url": "https://ubuntu.com/security/CVE-2024-53094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Add sendpage_ok() check to disable MSG_SPLICE_PAGES While running ISER over SIW, the initiator machine encounters a warning from skb_splice_from_iter() indicating that a slab page is being used in send_page. To address this, it is better to add a sendpage_ok() check within the driver itself, and if it returns 0, then MSG_SPLICE_PAGES flag should be disabled before entering the network stack. A similar issue has been discussed for NVMe in this thread: https://lore.kernel.org/all/20240530142417.146696-1-ofir.gal@volumez.com/ WARNING: CPU: 0 PID: 5342 at net/core/skbuff.c:7140 skb_splice_from_iter+0x173/0x320 Call Trace: tcp_sendmsg_locked+0x368/0xe40 siw_tx_hdt+0x695/0xa40 [siw] siw_qp_sq_process+0x102/0xb00 [siw] siw_sq_resume+0x39/0x110 [siw] siw_run_sq+0x74/0x160 [siw] kthread+0xd2/0x100 ret_from_fork+0x34/0x40 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53100", "url": "https://ubuntu.com/security/CVE-2024-53100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: tcp: avoid race between queue_lock lock and destroy Commit 76d54bf20cdc (\"nvme-tcp: don't access released socket during error recovery\") added a mutex_lock() call for the queue->queue_lock in nvme_tcp_get_address(). However, the mutex_lock() races with mutex_destroy() in nvme_tcp_free_queue(), and causes the WARN below. DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: CPU: 3 PID: 34077 at kernel/locking/mutex.c:587 __mutex_lock+0xcf0/0x1220 Modules linked in: nvmet_tcp nvmet nvme_tcp nvme_fabrics iw_cm ib_cm ib_core pktcdvd nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables qrtr sunrpc ppdev 9pnet_virtio 9pnet pcspkr netfs parport_pc parport e1000 i2c_piix4 i2c_smbus loop fuse nfnetlink zram bochs drm_vram_helper drm_ttm_helper ttm drm_kms_helper xfs drm sym53c8xx floppy nvme scsi_transport_spi nvme_core nvme_auth serio_raw ata_generic pata_acpi dm_multipath qemu_fw_cfg [last unloaded: ib_uverbs] CPU: 3 UID: 0 PID: 34077 Comm: udisksd Not tainted 6.11.0-rc7 #319 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:__mutex_lock+0xcf0/0x1220 Code: 08 84 d2 0f 85 c8 04 00 00 8b 15 ef b6 c8 01 85 d2 0f 85 78 f4 ff ff 48 c7 c6 20 93 ee af 48 c7 c7 60 91 ee af e8 f0 a7 6d fd <0f> 0b e9 5e f4 ff ff 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 RSP: 0018:ffff88811305f760 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff88812c652058 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000001 RBP: ffff88811305f8b0 R08: 0000000000000001 R09: ffffed1075c36341 R10: ffff8883ae1b1a0b R11: 0000000000010498 R12: 0000000000000000 R13: 0000000000000000 R14: dffffc0000000000 R15: ffff88812c652058 FS: 00007f9713ae4980(0000) GS:ffff8883ae180000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcd78483c7c CR3: 0000000122c38000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn.cold+0x5b/0x1af ? __mutex_lock+0xcf0/0x1220 ? report_bug+0x1ec/0x390 ? handle_bug+0x3c/0x80 ? exc_invalid_op+0x13/0x40 ? asm_exc_invalid_op+0x16/0x20 ? __mutex_lock+0xcf0/0x1220 ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] ? __pfx___mutex_lock+0x10/0x10 ? __lock_acquire+0xd6a/0x59e0 ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] ? __pfx_nvme_tcp_get_address+0x10/0x10 [nvme_tcp] nvme_sysfs_show_address+0x81/0xc0 [nvme_core] dev_attr_show+0x42/0x80 ? __asan_memset+0x1f/0x40 sysfs_kf_seq_show+0x1f0/0x370 seq_read_iter+0x2cb/0x1130 ? rw_verify_area+0x3b1/0x590 ? __mutex_lock+0x433/0x1220 vfs_read+0x6a6/0xa20 ? lockdep_hardirqs_on+0x78/0x100 ? __pfx_vfs_read+0x10/0x10 ksys_read+0xf7/0x1d0 ? __pfx_ksys_read+0x10/0x10 ? __x64_sys_openat+0x105/0x1d0 do_syscall_64+0x93/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? __pfx_ksys_read+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? do_syscall_64+0x9f/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f9713f55cfa Code: 55 48 89 e5 48 83 ec 20 48 89 55 e8 48 89 75 f0 89 7d f8 e8 e8 74 f8 ff 48 8b 55 e8 48 8b 75 f0 4 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53095", "url": "https://ubuntu.com/security/CVE-2024-53095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix use-after-free of network namespace. Recently, we got a customer report that CIFS triggers oops while reconnecting to a server. [0] The workload runs on Kubernetes, and some pods mount CIFS servers in non-root network namespaces. The problem rarely happened, but it was always while the pod was dying. The root cause is wrong reference counting for network namespace. CIFS uses kernel sockets, which do not hold refcnt of the netns that the socket belongs to. That means CIFS must ensure the socket is always freed before its netns; otherwise, use-after-free happens. The repro steps are roughly: 1. mount CIFS in a non-root netns 2. drop packets from the netns 3. destroy the netns 4. unmount CIFS We can reproduce the issue quickly with the script [1] below and see the splat [2] if CONFIG_NET_NS_REFCNT_TRACKER is enabled. When the socket is TCP, it is hard to guarantee the netns lifetime without holding refcnt due to async timers. Let's hold netns refcnt for each socket as done for SMC in commit 9744d2bf1976 (\"smc: Fix use-after-free in tcp_write_timer_handler().\"). Note that we need to move put_net() from cifs_put_tcp_session() to clean_demultiplex_info(); otherwise, __sock_create() still could touch a freed netns while cifsd tries to reconnect from cifs_demultiplex_thread(). Also, maybe_get_net() cannot be put just before __sock_create() because the code is not under RCU and there is a small chance that the same address happened to be reallocated to another netns. [0]: CIFS: VFS: \\\\XXXXXXXXXXX has not responded in 15 seconds. Reconnecting... CIFS: Serverclose failed 4 times, giving up Unable to handle kernel paging request at virtual address 14de99e461f84a07 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 CM = 0, WnR = 0 [14de99e461f84a07] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: cls_bpf sch_ingress nls_utf8 cifs cifs_arc4 cifs_md4 dns_resolver tcp_diag inet_diag veth xt_state xt_connmark nf_conntrack_netlink xt_nat xt_statistic xt_MASQUERADE xt_mark xt_addrtype ipt_REJECT nf_reject_ipv4 nft_chain_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment nft_compat nf_tables nfnetlink overlay nls_ascii nls_cp437 sunrpc vfat fat aes_ce_blk aes_ce_cipher ghash_ce sm4_ce_cipher sm4 sm3_ce sm3 sha3_ce sha512_ce sha512_arm64 sha1_ce ena button sch_fq_codel loop fuse configfs dmi_sysfs sha2_ce sha256_arm64 dm_mirror dm_region_hash dm_log dm_mod dax efivarfs CPU: 5 PID: 2690970 Comm: cifsd Not tainted 6.1.103-109.184.amzn2023.aarch64 #1 Hardware name: Amazon EC2 r7g.4xlarge/, BIOS 1.0 11/1/2018 pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : fib_rules_lookup+0x44/0x238 lr : __fib_lookup+0x64/0xbc sp : ffff8000265db790 x29: ffff8000265db790 x28: 0000000000000000 x27: 000000000000bd01 x26: 0000000000000000 x25: ffff000b4baf8000 x24: ffff00047b5e4580 x23: ffff8000265db7e0 x22: 0000000000000000 x21: ffff00047b5e4500 x20: ffff0010e3f694f8 x19: 14de99e461f849f7 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 3f92800abd010002 x11: 0000000000000001 x10: ffff0010e3f69420 x9 : ffff800008a6f294 x8 : 0000000000000000 x7 : 0000000000000006 x6 : 0000000000000000 x5 : 0000000000000001 x4 : ffff001924354280 x3 : ffff8000265db7e0 x2 : 0000000000000000 x1 : ffff0010e3f694f8 x0 : ffff00047b5e4500 Call trace: fib_rules_lookup+0x44/0x238 __fib_lookup+0x64/0xbc ip_route_output_key_hash_rcu+0x2c4/0x398 ip_route_output_key_hash+0x60/0x8c tcp_v4_connect+0x290/0x488 __inet_stream_connect+0x108/0x3d0 inet_stream_connect+0x50/0x78 kernel_connect+0x6c/0xac generic_ip_conne ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-50265", "url": "https://ubuntu.com/security/CVE-2024-50265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove() Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove(): [ 57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12 [ 57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry [ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004 [...] [ 57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [...] [ 57.331328] Call Trace: [ 57.331477] [...] [ 57.333511] ? do_user_addr_fault+0x3e5/0x740 [ 57.333778] ? exc_page_fault+0x70/0x170 [ 57.334016] ? asm_exc_page_fault+0x2b/0x30 [ 57.334263] ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10 [ 57.334596] ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [ 57.334913] ocfs2_xa_remove_entry+0x23/0xc0 [ 57.335164] ocfs2_xa_set+0x704/0xcf0 [ 57.335381] ? _raw_spin_unlock+0x1a/0x40 [ 57.335620] ? ocfs2_inode_cache_unlock+0x16/0x20 [ 57.335915] ? trace_preempt_on+0x1e/0x70 [ 57.336153] ? start_this_handle+0x16c/0x500 [ 57.336410] ? preempt_count_sub+0x50/0x80 [ 57.336656] ? _raw_read_unlock+0x20/0x40 [ 57.336906] ? start_this_handle+0x16c/0x500 [ 57.337162] ocfs2_xattr_block_set+0xa6/0x1e0 [ 57.337424] __ocfs2_xattr_set_handle+0x1fd/0x5d0 [ 57.337706] ? ocfs2_start_trans+0x13d/0x290 [ 57.337971] ocfs2_xattr_set+0xb13/0xfb0 [ 57.338207] ? dput+0x46/0x1c0 [ 57.338393] ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338665] ? ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338948] __vfs_removexattr+0x92/0xc0 [ 57.339182] __vfs_removexattr_locked+0xd5/0x190 [ 57.339456] ? preempt_count_sub+0x50/0x80 [ 57.339705] vfs_removexattr+0x5f/0x100 [...] Reproducer uses faultinject facility to fail ocfs2_xa_remove() -> ocfs2_xa_value_truncate() with -ENOMEM. In this case the comment mentions that we can return 0 if ocfs2_xa_cleanup_value_truncate() is going to wipe the entry anyway. But the following 'rc' check is wrong and execution flow do 'ocfs2_xa_remove_entry(loc);' twice: * 1st: in ocfs2_xa_cleanup_value_truncate(); * 2nd: returning back to ocfs2_xa_remove() instead of going to 'out'. Fix this by skipping the 2nd removal of the same entry and making syzkaller repro happy.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50266", "url": "https://ubuntu.com/security/CVE-2024-50266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: qcom: videocc-sm8350: use HW_CTRL_TRIGGER for vcodec GDSCs A recent change in the venus driver results in a stuck clock on the Lenovo ThinkPad X13s, for example, when streaming video in firefox: \tvideo_cc_mvs0_clk status stuck at 'off' \tWARNING: CPU: 6 PID: 2885 at drivers/clk/qcom/clk-branch.c:87 clk_branch_wait+0x144/0x15c \t... \tCall trace: \t clk_branch_wait+0x144/0x15c \t clk_branch2_enable+0x30/0x40 \t clk_core_enable+0xd8/0x29c \t clk_enable+0x2c/0x4c \t vcodec_clks_enable.isra.0+0x94/0xd8 [venus_core] \t coreid_power_v4+0x464/0x628 [venus_core] \t vdec_start_streaming+0xc4/0x510 [venus_dec] \t vb2_start_streaming+0x6c/0x180 [videobuf2_common] \t vb2_core_streamon+0x120/0x1dc [videobuf2_common] \t vb2_streamon+0x1c/0x6c [videobuf2_v4l2] \t v4l2_m2m_ioctl_streamon+0x30/0x80 [v4l2_mem2mem] \t v4l_streamon+0x24/0x30 [videodev] using the out-of-tree sm8350/sc8280xp venus support. [1] Update also the sm8350/sc8280xp GDSC definitions so that the hw control mode can be changed at runtime as the venus driver now requires.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50267", "url": "https://ubuntu.com/security/CVE-2024-50267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: fix use after free in debug printk The \"dev_dbg(&urb->dev->dev, ...\" which happens after usb_free_urb(urb) is a use after free of the \"urb\" pointer. Store the \"dev\" pointer at the start of the function to avoid this issue.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50268", "url": "https://ubuntu.com/security/CVE-2024-50268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: fix potential out of bounds in ucsi_ccg_update_set_new_cam_cmd() The \"*cmd\" variable can be controlled by the user via debugfs. That means \"new_cam\" can be as high as 255 while the size of the uc->updated[] array is UCSI_MAX_ALTMODES (30). The call tree is: ucsi_cmd() // val comes from simple_attr_write_xsigned() -> ucsi_send_command() -> ucsi_send_command_common() -> ucsi_run_command() // calls ucsi->ops->sync_control() -> ucsi_ccg_sync_control()", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53083", "url": "https://ubuntu.com/security/CVE-2024-53083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: qcom-pmic: init value of hdr_len/txbuf_len earlier If the read of USB_PDPHY_RX_ACKNOWLEDGE_REG failed, then hdr_len and txbuf_len are uninitialized. This commit stops to print uninitialized value and misleading/false data.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50269", "url": "https://ubuntu.com/security/CVE-2024-50269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: musb: sunxi: Fix accessing an released usb phy Commit 6ed05c68cbca (\"usb: musb: sunxi: Explicitly release USB PHY on exit\") will cause that usb phy @glue->xceiv is accessed after released. 1) register platform driver @sunxi_musb_driver // get the usb phy @glue->xceiv sunxi_musb_probe() -> devm_usb_get_phy(). 2) register and unregister platform driver @musb_driver musb_probe() -> sunxi_musb_init() use the phy here //the phy is released here musb_remove() -> sunxi_musb_exit() -> devm_usb_put_phy() 3) register @musb_driver again musb_probe() -> sunxi_musb_init() use the phy here but the phy has been released at 2). ... Fixed by reverting the commit, namely, removing devm_usb_put_phy() from sunxi_musb_exit().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53079", "url": "https://ubuntu.com/security/CVE-2024-53079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/thp: fix deferred split unqueue naming and locking Recent changes are putting more pressure on THP deferred split queues: under load revealing long-standing races, causing list_del corruptions, \"Bad page state\"s and worse (I keep BUGs in both of those, so usually don't get to see how badly they end up without). The relevant recent changes being 6.8's mTHP, 6.10's mTHP swapout, and 6.12's mTHP swapin, improved swap allocation, and underused THP splitting. Before fixing locking: rename misleading folio_undo_large_rmappable(), which does not undo large_rmappable, to folio_unqueue_deferred_split(), which is what it does. But that and its out-of-line __callee are mm internals of very limited usability: add comment and WARN_ON_ONCEs to check usage; and return a bool to say if a deferred split was unqueued, which can then be used in WARN_ON_ONCEs around safety checks (sparing callers the arcane conditionals in __folio_unqueue_deferred_split()). Just omit the folio_unqueue_deferred_split() from free_unref_folios(), all of whose callers now call it beforehand (and if any forget then bad_page() will tell) - except for its caller put_pages_list(), which itself no longer has any callers (and will be deleted separately). Swapout: mem_cgroup_swapout() has been resetting folio->memcg_data 0 without checking and unqueueing a THP folio from deferred split list; which is unfortunate, since the split_queue_lock depends on the memcg (when memcg is enabled); so swapout has been unqueueing such THPs later, when freeing the folio, using the pgdat's lock instead: potentially corrupting the memcg's list. __remove_mapping() has frozen refcount to 0 here, so no problem with calling folio_unqueue_deferred_split() before resetting memcg_data. That goes back to 5.4 commit 87eaceb3faa5 (\"mm: thp: make deferred split shrinker memcg aware\"): which included a check on swapcache before adding to deferred queue, but no check on deferred queue before adding THP to swapcache. That worked fine with the usual sequence of events in reclaim (though there were a couple of rare ways in which a THP on deferred queue could have been swapped out), but 6.12 commit dafff3f4c850 (\"mm: split underused THPs\") avoids splitting underused THPs in reclaim, which makes swapcache THPs on deferred queue commonplace. Keep the check on swapcache before adding to deferred queue? Yes: it is no longer essential, but preserves the existing behaviour, and is likely to be a worthwhile optimization (vmstat showed much more traffic on the queue under swapping load if the check was removed); update its comment. Memcg-v1 move (deprecated): mem_cgroup_move_account() has been changing folio->memcg_data without checking and unqueueing a THP folio from the deferred list, sometimes corrupting \"from\" memcg's list, like swapout. Refcount is non-zero here, so folio_unqueue_deferred_split() can only be used in a WARN_ON_ONCE to validate the fix, which must be done earlier: mem_cgroup_move_charge_pte_range() first try to split the THP (splitting of course unqueues), or skip it if that fails. Not ideal, but moving charge has been requested, and khugepaged should repair the THP later: nobody wants new custom unqueueing code just for this deprecated case. The 87eaceb3faa5 commit did have the code to move from one deferred list to another (but was not conscious of its unsafety while refcount non-0); but that was removed by 5.6 commit fac0516b5534 (\"mm: thp: don't need care deferred split queue in memcg charge move path\"), which argued that the existence of a PMD mapping guarantees that the THP cannot be on a deferred list. As above, false in rare cases, and now commonly false. Backport to 6.11 should be straightforward. Earlier backports must take care that other _deferred_list fixes and dependencies are included. There is not a strong case for backports, but they can fix cornercases.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50270", "url": "https://ubuntu.com/security/CVE-2024-50270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: avoid overflow in damon_feed_loop_next_input() damon_feed_loop_next_input() is inefficient and fragile to overflows. Specifically, 'score_goal_diff_bp' calculation can overflow when 'score' is high. The calculation is actually unnecessary at all because 'goal' is a constant of value 10,000. Calculation of 'compensation' is again fragile to overflow. Final calculation of return value for under-achiving case is again fragile to overflow when the current score is under-achieving the target. Add two corner cases handling at the beginning of the function to make the body easier to read, and rewrite the body of the function to avoid overflows and the unnecessary bp value calcuation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50271", "url": "https://ubuntu.com/security/CVE-2024-50271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: signal: restore the override_rlimit logic Prior to commit d64696905554 (\"Reimplement RLIMIT_SIGPENDING on top of ucounts\") UCOUNT_RLIMIT_SIGPENDING rlimit was not enforced for a class of signals. However now it's enforced unconditionally, even if override_rlimit is set. This behavior change caused production issues. For example, if the limit is reached and a process receives a SIGSEGV signal, sigqueue_alloc fails to allocate the necessary resources for the signal delivery, preventing the signal from being delivered with siginfo. This prevents the process from correctly identifying the fault address and handling the error. From the user-space perspective, applications are unaware that the limit has been reached and that the siginfo is effectively 'corrupted'. This can lead to unpredictable behavior and crashes, as we observed with java applications. Fix this by passing override_rlimit into inc_rlimit_get_ucounts() and skip the comparison to max there if override_rlimit is set. This effectively restores the old behavior.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50272", "url": "https://ubuntu.com/security/CVE-2024-50272", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: filemap: Fix bounds checking in filemap_read() If the caller supplies an iocb->ki_pos value that is close to the filesystem upper limit, and an iterator with a count that causes us to overflow that limit, then filemap_read() enters an infinite loop. This behaviour was discovered when testing xfstests generic/525 with the \"localio\" optimisation for loopback NFS mounts.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53104", "url": "https://ubuntu.com/security/CVE-2024-53104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_parse_format This can lead to out of bounds writes since frames of this type were not taken into account when calculating the size of the frames buffer in uvc_parse_streaming.", "cve_priority": "high", "cve_public_date": "2024-12-02 08:15:00 UTC" }, { "cve": "CVE-2024-50273", "url": "https://ubuntu.com/security/CVE-2024-50273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reinitialize delayed ref list after deleting it from the list At insert_delayed_ref() if we need to update the action of an existing ref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head's ref_add_list using list_del(), which leaves the ref's add_list member not reinitialized, as list_del() sets the next and prev members of the list to LIST_POISON1 and LIST_POISON2, respectively. If later we end up calling drop_delayed_ref() against the ref, which can happen during merging or when destroying delayed refs due to a transaction abort, we can trigger a crash since at drop_delayed_ref() we call list_empty() against the ref's add_list, which returns false since the list was not reinitialized after the list_del() and as a consequence we call list_del() again at drop_delayed_ref(). This results in an invalid list access since the next and prev members are set to poison pointers, resulting in a splat if CONFIG_LIST_HARDENED and CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences otherwise. So fix this by deleting from the list with list_del_init() instead.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53064", "url": "https://ubuntu.com/security/CVE-2024-53064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix idpf_vc_core_init error path In an event where the platform running the device control plane is rebooted, reset is detected on the driver. It releases all the resources and waits for the reset to complete. Once the reset is done, it tries to build the resources back. At this time if the device control plane is not yet started, then the driver timeouts on the virtchnl message and retries to establish the mailbox again. In the retry flow, mailbox is deinitialized but the mailbox workqueue is still alive and polling for the mailbox message. This results in accessing the released control queue leading to null-ptr-deref. Fix it by unrolling the work queue cancellation and mailbox deinitialization in the reverse order which they got initialized.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50274", "url": "https://ubuntu.com/security/CVE-2024-50274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: avoid vport access in idpf_get_link_ksettings When the device control plane is removed or the platform running device control plane is rebooted, a reset is detected on the driver. On driver reset, it releases the resources and waits for the reset to complete. If the reset fails, it takes the error path and releases the vport lock. At this time if the monitoring tools tries to access link settings, it call traces for accessing released vport pointer. To avoid it, move link_speed_mbps to netdev_priv structure which removes the dependency on vport pointer and the vport lock in idpf_get_link_ksettings. Also use netif_carrier_ok() to check the link status and adjust the offsetof to use link_up instead of link_speed_mbps.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53065", "url": "https://ubuntu.com/security/CVE-2024-53065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/slab: fix warning caused by duplicate kmem_cache creation in kmem_buckets_create Commit b035f5a6d852 (\"mm: slab: reduce the kmalloc() minimum alignment if DMA bouncing possible\") reduced ARCH_KMALLOC_MINALIGN to 8 on arm64. However, with KASAN_HW_TAGS enabled, arch_slab_minalign() becomes 16. This causes kmalloc_caches[*][8] to be aliased to kmalloc_caches[*][16], resulting in kmem_buckets_create() attempting to create a kmem_cache for size 16 twice. This duplication triggers warnings on boot: [ 2.325108] ------------[ cut here ]------------ [ 2.325135] kmem_cache of name 'memdup_user-16' already exists [ 2.325783] WARNING: CPU: 0 PID: 1 at mm/slab_common.c:107 __kmem_cache_create_args+0xb8/0x3b0 [ 2.327957] Modules linked in: [ 2.328550] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5mm-unstable-arm64+ #12 [ 2.328683] Hardware name: QEMU QEMU Virtual Machine, BIOS 2024.02-2 03/11/2024 [ 2.328790] pstate: 61000009 (nZCv daif -PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 2.328911] pc : __kmem_cache_create_args+0xb8/0x3b0 [ 2.328930] lr : __kmem_cache_create_args+0xb8/0x3b0 [ 2.328942] sp : ffff800083d6fc50 [ 2.328961] x29: ffff800083d6fc50 x28: f2ff0000c1674410 x27: ffff8000820b0598 [ 2.329061] x26: 000000007fffffff x25: 0000000000000010 x24: 0000000000002000 [ 2.329101] x23: ffff800083d6fce8 x22: ffff8000832222e8 x21: ffff800083222388 [ 2.329118] x20: f2ff0000c1674410 x19: f5ff0000c16364c0 x18: ffff800083d80030 [ 2.329135] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 2.329152] x14: 0000000000000000 x13: 0a73747369786520 x12: 79646165726c6120 [ 2.329169] x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : 0000000000000000 [ 2.329194] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 [ 2.329210] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 2.329226] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 2.329291] Call trace: [ 2.329407] __kmem_cache_create_args+0xb8/0x3b0 [ 2.329499] kmem_buckets_create+0xfc/0x320 [ 2.329526] init_user_buckets+0x34/0x78 [ 2.329540] do_one_initcall+0x64/0x3c8 [ 2.329550] kernel_init_freeable+0x26c/0x578 [ 2.329562] kernel_init+0x3c/0x258 [ 2.329574] ret_from_fork+0x10/0x20 [ 2.329698] ---[ end trace 0000000000000000 ]--- [ 2.403704] ------------[ cut here ]------------ [ 2.404716] kmem_cache of name 'msg_msg-16' already exists [ 2.404801] WARNING: CPU: 2 PID: 1 at mm/slab_common.c:107 __kmem_cache_create_args+0xb8/0x3b0 [ 2.404842] Modules linked in: [ 2.404971] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.12.0-rc5mm-unstable-arm64+ #12 [ 2.405026] Tainted: [W]=WARN [ 2.405043] Hardware name: QEMU QEMU Virtual Machine, BIOS 2024.02-2 03/11/2024 [ 2.405057] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2.405079] pc : __kmem_cache_create_args+0xb8/0x3b0 [ 2.405100] lr : __kmem_cache_create_args+0xb8/0x3b0 [ 2.405111] sp : ffff800083d6fc50 [ 2.405115] x29: ffff800083d6fc50 x28: fbff0000c1674410 x27: ffff8000820b0598 [ 2.405135] x26: 000000000000ffd0 x25: 0000000000000010 x24: 0000000000006000 [ 2.405153] x23: ffff800083d6fce8 x22: ffff8000832222e8 x21: ffff800083222388 [ 2.405169] x20: fbff0000c1674410 x19: fdff0000c163d6c0 x18: ffff800083d80030 [ 2.405185] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 2.405201] x14: 0000000000000000 x13: 0a73747369786520 x12: 79646165726c6120 [ 2.405217] x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : 0000000000000000 [ 2.405233] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 [ 2.405248] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 2.405271] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 2.405287] Call trace: [ 2 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50275", "url": "https://ubuntu.com/security/CVE-2024-50275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64/sve: Discard stale CPU state when handling SVE traps The logic for handling SVE traps manipulates saved FPSIMD/SVE state incorrectly, and a race with preemption can result in a task having TIF_SVE set and TIF_FOREIGN_FPSTATE clear even though the live CPU state is stale (e.g. with SVE traps enabled). This has been observed to result in warnings from do_sve_acc() where SVE traps are not expected while TIF_SVE is set: | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* SVE access shouldn't have trapped */ Warnings of this form have been reported intermittently, e.g. https://lore.kernel.org/linux-arm-kernel/CA+G9fYtEGe_DhY2Ms7+L7NKsLYUomGsgqpdBj+QwDLeSg=JhGg@mail.gmail.com/ https://lore.kernel.org/linux-arm-kernel/000000000000511e9a060ce5a45c@google.com/ The race can occur when the SVE trap handler is preempted before and after manipulating the saved FPSIMD/SVE state, starting and ending on the same CPU, e.g. | void do_sve_acc(unsigned long esr, struct pt_regs *regs) | { | // Trap on CPU 0 with TIF_SVE clear, SVE 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(); | | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* SVE access shouldn't have trapped */ | | sve_init_regs() { | if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) { | ... | } else { | fpsimd_to_sve(current); | current->thread.fp_type = FP_STATE_SVE; | } | } | | 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 SVE 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.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50276", "url": "https://ubuntu.com/security/CVE-2024-50276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: vertexcom: mse102x: Fix possible double free of TX skb The scope of the TX skb is wider than just mse102x_tx_frame_spi(), so in case the TX skb room needs to be expanded, we should free the the temporary skb instead of the original skb. Otherwise the original TX skb pointer would be freed again in mse102x_tx_work(), which leads to crashes: Internal error: Oops: 0000000096000004 [#2] PREEMPT SMP CPU: 0 PID: 712 Comm: kworker/0:1 Tainted: G D 6.6.23 Hardware name: chargebyte Charge SOM DC-ONE (DT) Workqueue: events mse102x_tx_work [mse102x] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_release_data+0xb8/0x1d8 lr : skb_release_data+0x1ac/0x1d8 sp : ffff8000819a3cc0 x29: ffff8000819a3cc0 x28: ffff0000046daa60 x27: ffff0000057f2dc0 x26: ffff000005386c00 x25: 0000000000000002 x24: 00000000ffffffff x23: 0000000000000000 x22: 0000000000000001 x21: ffff0000057f2e50 x20: 0000000000000006 x19: 0000000000000000 x18: ffff00003fdacfcc x17: e69ad452d0c49def x16: 84a005feff870102 x15: 0000000000000000 x14: 000000000000024a x13: 0000000000000002 x12: 0000000000000000 x11: 0000000000000400 x10: 0000000000000930 x9 : ffff00003fd913e8 x8 : fffffc00001bc008 x7 : 0000000000000000 x6 : 0000000000000008 x5 : ffff00003fd91340 x4 : 0000000000000000 x3 : 0000000000000009 x2 : 00000000fffffffe x1 : 0000000000000000 x0 : 0000000000000000 Call trace: skb_release_data+0xb8/0x1d8 kfree_skb_reason+0x48/0xb0 mse102x_tx_work+0x164/0x35c [mse102x] process_one_work+0x138/0x260 worker_thread+0x32c/0x438 kthread+0x118/0x11c ret_from_fork+0x10/0x20 Code: aa1303e0 97fffab6 72001c1f 54000141 (f9400660)", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53066", "url": "https://ubuntu.com/security/CVE-2024-53066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfs: Fix KMSAN warning in decode_getfattr_attrs() Fix the following KMSAN warning: CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G B Tainted: [B]=BAD_PAGE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) ===================================================== ===================================================== BUG: KMSAN: uninit-value in decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_generic+0x806/0xb00 nfs4_xdr_dec_getattr+0x1de/0x240 rpcauth_unwrap_resp_decode+0xab/0x100 rpcauth_unwrap_resp+0x95/0xc0 call_decode+0x4ff/0xb50 __rpc_execute+0x57b/0x19d0 rpc_execute+0x368/0x5e0 rpc_run_task+0xcfe/0xee0 nfs4_proc_getattr+0x5b5/0x990 __nfs_revalidate_inode+0x477/0xd00 nfs_access_get_cached+0x1021/0x1cc0 nfs_do_access+0x9f/0xae0 nfs_permission+0x1e4/0x8c0 inode_permission+0x356/0x6c0 link_path_walk+0x958/0x1330 path_lookupat+0xce/0x6b0 filename_lookup+0x23e/0x770 vfs_statx+0xe7/0x970 vfs_fstatat+0x1f2/0x2c0 __se_sys_newfstatat+0x67/0x880 __x64_sys_newfstatat+0xbd/0x120 x64_sys_call+0x1826/0x3cf0 do_syscall_64+0xd0/0x1b0 entry_SYSCALL_64_after_hwframe+0x77/0x7f The KMSAN warning is triggered in decode_getfattr_attrs(), when calling decode_attr_mdsthreshold(). It appears that fattr->mdsthreshold is not initialized. Fix the issue by initializing fattr->mdsthreshold to NULL in nfs_fattr_init().", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53067", "url": "https://ubuntu.com/security/CVE-2024-53067", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Start the RTC update work later The RTC update work involves runtime resuming the UFS controller. Hence, only start the RTC update work after runtime power management in the UFS driver has been fully initialized. This patch fixes the following kernel crash: Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP Workqueue: events ufshcd_rtc_work Call trace: _raw_spin_lock_irqsave+0x34/0x8c (P) pm_runtime_get_if_active+0x24/0x9c (L) pm_runtime_get_if_active+0x24/0x9c ufshcd_rtc_work+0x138/0x1b4 process_one_work+0x148/0x288 worker_thread+0x2cc/0x3d4 kthread+0x110/0x114 ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50277", "url": "https://ubuntu.com/security/CVE-2024-50277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: fix a crash if blk_alloc_disk fails If blk_alloc_disk fails, the variable md->disk is set to an error value. cleanup_mapped_device will see that md->disk is non-NULL and it will attempt to access it, causing a crash on this statement \"md->disk->private_data = NULL;\".", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50278", "url": "https://ubuntu.com/security/CVE-2024-50278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix potential out-of-bounds access on the first resume Out-of-bounds access occurs if the fast device is expanded unexpectedly before the first-time resume of the cache table. This happens because expanding the fast device requires reloading the cache table for cache_create to allocate new in-core data structures that fit the new size, and the check in cache_preresume is not performed during the first resume, leading to the issue. Reproduce steps: 1. prepare component devices: 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\" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct 2. load a cache table of 512 cache blocks, and deliberately expand the fast device before resuming the cache, making the in-core data structures inadequate. dmsetup create cache --notable dmsetup reload cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" dmsetup reload cdata --table \"0 131072 linear /dev/sdc 8192\" dmsetup resume cdata dmsetup resume cache 3. suspend the cache to write out the in-core dirty bitset and hint array, leading to out-of-bounds access to the dirty bitset at offset 0x40: dmsetup suspend cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80 Read of size 8 at addr ffffc90000085040 by task dmsetup/90 (...snip...) The buggy address belongs to the virtual mapping at [ffffc90000085000, ffffc90000087000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by checking the size change on the first resume.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50279", "url": "https://ubuntu.com/security/CVE-2024-50279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix out-of-bounds access to the dirty bitset when resizing dm-cache checks the dirty bits of the cache blocks to be dropped when shrinking the fast device, but an index bug in bitset iteration causes out-of-bounds access. Reproduce steps: 1. create a cache device of 1024 cache blocks (128 bytes dirty bitset) dmsetup create cmeta --table \"0 8192 linear /dev/sdc 0\" dmsetup create cdata --table \"0 131072 linear /dev/sdc 8192\" dmsetup create corig --table \"0 524288 linear /dev/sdc 262144\" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" 2. shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80) dmsetup suspend cache dmsetup reload cdata --table \"0 65536 linear /dev/sdc 8192\" dmsetup resume cdata dmsetup resume cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131 (...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by making the index post-incremented.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50280", "url": "https://ubuntu.com/security/CVE-2024-50280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix flushing uninitialized delayed_work on cache_ctr error An unexpected WARN_ON from flush_work() may occur when cache creation fails, caused by destroying the uninitialized delayed_work waker in the error path of cache_create(). For example, the warning appears on the superblock checksum error. Reproduce steps: 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\" dd if=/dev/urandom of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" Kernel logs: (snip) WARNING: CPU: 0 PID: 84 at kernel/workqueue.c:4178 __flush_work+0x5d4/0x890 Fix by pulling out the cancel_delayed_work_sync() from the constructor's error path. This patch doesn't affect the use-after-free fix for concurrent dm_resume and dm_destroy (commit 6a459d8edbdb (\"dm cache: Fix UAF in destroy()\")) as cache_dtr is not changed.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50281", "url": "https://ubuntu.com/security/CVE-2024-50281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: trusted: dcp: fix NULL dereference in AEAD crypto operation When sealing or unsealing a key blob we currently do not wait for the AEAD cipher operation to finish and simply return after submitting the request. If there is some load on the system we can exit before the cipher operation is done and the buffer we read from/write to is already removed from the stack. This will e.g. result in NULL pointer dereference errors in the DCP driver during blob creation. Fix this by waiting for the AEAD cipher operation to finish before resuming the seal and unseal calls.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50282", "url": "https://ubuntu.com/security/CVE-2024-50282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read() Avoid a possible buffer overflow if size is larger than 4K. (cherry picked from commit f5d873f5825b40d886d03bd2aede91d4cf002434)", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53071", "url": "https://ubuntu.com/security/CVE-2024-53071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Be stricter about IO mapping flags The current panthor_device_mmap_io() implementation has two issues: 1. For mapping DRM_PANTHOR_USER_FLUSH_ID_MMIO_OFFSET, panthor_device_mmap_io() bails if VM_WRITE is set, but does not clear VM_MAYWRITE. That means userspace can use mprotect() to make the mapping writable later on. This is a classic Linux driver gotcha. I don't think this actually has any impact in practice: When the GPU is powered, writes to the FLUSH_ID seem to be ignored; and when the GPU is not powered, the dummy_latest_flush page provided by the driver is deliberately designed to not do any flushes, so the only thing writing to the dummy_latest_flush could achieve would be to make *more* flushes happen. 2. panthor_device_mmap_io() does not block MAP_PRIVATE mappings (which are mappings without the VM_SHARED flag). MAP_PRIVATE in combination with VM_MAYWRITE indicates that the VMA has copy-on-write semantics, which for VM_PFNMAP are semi-supported but fairly cursed. In particular, in such a mapping, the driver can only install PTEs during mmap() by calling remap_pfn_range() (because remap_pfn_range() wants to **store the physical address of the mapped physical memory into the vm_pgoff of the VMA**); installing PTEs later on with a fault handler (as panthor does) is not supported in private mappings, and so if you try to fault in such a mapping, vmf_insert_pfn_prot() splats when it hits a BUG() check. Fix it by clearing the VM_MAYWRITE flag (userspace writing to the FLUSH_ID doesn't make sense) and requiring VM_SHARED (copy-on-write semantics for the FLUSH_ID don't make sense). Reproducers for both scenarios are in the notes of my patch on the mailing list; I tested that these bugs exist on a Rock 5B machine. Note that I only compile-tested the patch, I haven't tested it; I don't have a working kernel build setup for the test machine yet. Please test it before applying it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53080", "url": "https://ubuntu.com/security/CVE-2024-53080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Lock XArray when getting entries for the VM Similar to commit cac075706f29 (\"drm/panthor: Fix race when converting group handle to group object\") we need to use the XArray's internal locking when retrieving a vm pointer from there. v2: Removed part of the patch that was trying to protect fetching the heap pointer from XArray, as that operation is protected by the @pool->lock.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53084", "url": "https://ubuntu.com/security/CVE-2024-53084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Break an object reference loop When remaining resources are being cleaned up on driver close, outstanding VM mappings may result in resources being leaked, due to an object reference loop, as shown below, with each object (or set of objects) referencing the object below it: PVR GEM Object GPU scheduler \"finished\" fence GPU scheduler “scheduled” fence PVR driver “done” fence PVR Context PVR VM Context PVR VM Mappings PVR GEM Object The reference that the PVR VM Context has on the VM mappings is a soft one, in the sense that the freeing of outstanding VM mappings is done as part of VM context destruction; no reference counts are involved, as is the case for all the other references in the loop. To break the reference loop during cleanup, free the outstanding VM mappings before destroying the PVR Context associated with the VM context.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53085", "url": "https://ubuntu.com/security/CVE-2024-53085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: Lock TPM chip in tpm_pm_suspend() first Setting TPM_CHIP_FLAG_SUSPENDED in the end of tpm_pm_suspend() can be racy according, as this leaves window for tpm_hwrng_read() to be called while the operation is in progress. The recent bug report gives also evidence of this behaviour. Aadress this by locking the TPM chip before checking any chip->flags both in tpm_pm_suspend() and tpm_hwrng_read(). Move TPM_CHIP_FLAG_SUSPENDED check inside tpm_get_random() so that it will be always checked only when the lock is reserved.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53086", "url": "https://ubuntu.com/security/CVE-2024-53086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Drop VM dma-resv lock on xe_sync_in_fence_get failure in exec IOCTL Upon failure all locks need to be dropped before returning to the user. (cherry picked from commit 7d1a4258e602ffdce529f56686925034c1b3b095)", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53087", "url": "https://ubuntu.com/security/CVE-2024-53087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix possible exec queue leak in exec IOCTL In a couple of places after an exec queue is looked up the exec IOCTL returns on input errors without dropping the exec queue ref. Fix this ensuring the exec queue ref is dropped on input error. (cherry picked from commit 07064a200b40ac2195cb6b7b779897d9377e5e6f)", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50283", "url": "https://ubuntu.com/security/CVE-2024-50283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-use-after-free in smb3_preauth_hash_rsp ksmbd_user_session_put should be called under smb3_preauth_hash_rsp(). It will avoid freeing session before calling smb3_preauth_hash_rsp().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50284", "url": "https://ubuntu.com/security/CVE-2024-50284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix the missing xa_store error check xa_store() can fail, it return xa_err(-EINVAL) if the entry cannot be stored in an XArray, or xa_err(-ENOMEM) if memory allocation failed, so check error for xa_store() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50285", "url": "https://ubuntu.com/security/CVE-2024-50285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: check outstanding simultaneous SMB operations If Client send simultaneous SMB operations to ksmbd, It exhausts too much memory through the \"ksmbd_work_cache”. It will cause OOM issue. ksmbd has a credit mechanism but it can't handle this problem. This patch add the check if it exceeds max credits to prevent this problem by assuming that one smb request consumes at least one credit.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50286", "url": "https://ubuntu.com/security/CVE-2024-50286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-use-after-free in ksmbd_smb2_session_create There is a race condition between ksmbd_smb2_session_create and ksmbd_expire_session. This patch add missing sessions_table_lock while adding/deleting session from global session table.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50287", "url": "https://ubuntu.com/security/CVE-2024-50287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-tpg: prevent the risk of a division by zero As reported by Coverity, the logic at tpg_precalculate_line() blindly rescales the buffer even when scaled_witdh is equal to zero. If this ever happens, this will cause a division by zero. Instead, add a WARN_ON_ONCE() to trigger such cases and return without doing any precalculation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50288", "url": "https://ubuntu.com/security/CVE-2024-50288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: fix buffer overwrite when using > 32 buffers The maximum number of buffers that can be requested was increased to 64 for the video capture queue. But video capture used a must_blank array that was still sized for 32 (VIDEO_MAX_FRAME). This caused an out-of-bounds write when using buffer indices >= 32. Create a new define MAX_VID_CAP_BUFFERS that is used to access the must_blank array and set max_num_buffers for the video capture queue. This solves a crash reported by: \thttps://bugzilla.kernel.org/show_bug.cgi?id=219258", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50289", "url": "https://ubuntu.com/security/CVE-2024-50289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: av7110: fix a spectre vulnerability As warned by smatch: \tdrivers/staging/media/av7110/av7110_ca.c:270 dvb_ca_ioctl() warn: potential spectre issue 'av7110->ci_slot' [w] (local cap) There is a spectre-related vulnerability at the code. Fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50290", "url": "https://ubuntu.com/security/CVE-2024-50290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx24116: prevent overflows on SNR calculus as reported by Coverity, if reading SNR registers fail, a negative number will be returned, causing an underflow when reading SNR registers. Prevent that.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53061", "url": "https://ubuntu.com/security/CVE-2024-53061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: s5p-jpeg: prevent buffer overflows The current logic allows word to be less than 2. If this happens, there will be buffer overflows, as reported by smatch. Add extra checks to prevent it. While here, remove an unused word = 0 assignment.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53081", "url": "https://ubuntu.com/security/CVE-2024-53081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ar0521: don't overflow when checking PLL values The PLL checks are comparing 64 bit integers with 32 bit ones, as reported by Coverity. Depending on the values of the variables, this may underflow. Fix it ensuring that both sides of the expression are u64.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53062", "url": "https://ubuntu.com/security/CVE-2024-53062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mgb4: protect driver against spectre Frequency range is set from sysfs via frequency_range_store(), being vulnerable to spectre, as reported by smatch: \tdrivers/media/pci/mgb4/mgb4_cmt.c:231 mgb4_cmt_set_vin_freq_range() warn: potential spectre issue 'cmt_vals_in' [r] \tdrivers/media/pci/mgb4/mgb4_cmt.c:238 mgb4_cmt_set_vin_freq_range() warn: possible spectre second half. 'reg_set' Fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50291", "url": "https://ubuntu.com/security/CVE-2024-50291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvb-core: add missing buffer index check dvb_vb2_expbuf() didn't check if the given buffer index was for a valid buffer. Add this check.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50292", "url": "https://ubuntu.com/security/CVE-2024-50292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: stm32: spdifrx: fix dma channel release in stm32_spdifrx_remove In case of error when requesting ctrl_chan DMA channel, ctrl_chan is not null. So the release of the dma channel leads to the following issue: [ 4.879000] st,stm32-spdifrx 500d0000.audio-controller: dma_request_slave_channel error -19 [ 4.888975] Unable to handle kernel NULL pointer dereference at virtual address 000000000000003d [...] [ 5.096577] Call trace: [ 5.099099] dma_release_channel+0x24/0x100 [ 5.103235] stm32_spdifrx_remove+0x24/0x60 [snd_soc_stm32_spdifrx] [ 5.109494] stm32_spdifrx_probe+0x320/0x4c4 [snd_soc_stm32_spdifrx] To avoid this issue, release channel only if the pointer is valid.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53063", "url": "https://ubuntu.com/security/CVE-2024-53063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvbdev: prevent the risk of out of memory access The dvbdev contains a static variable used to store dvb minors. The behavior of it depends if CONFIG_DVB_DYNAMIC_MINORS is set or not. When not set, dvb_register_device() won't check for boundaries, as it will rely that a previous call to dvb_register_adapter() would already be enforcing it. On a similar way, dvb_device_open() uses the assumption that the register functions already did the needed checks. This can be fragile if some device ends using different calls. This also generate warnings on static check analysers like Coverity. So, add explicit guards to prevent potential risk of OOM issues.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50293", "url": "https://ubuntu.com/security/CVE-2024-50293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: do not leave a dangling sk pointer in __smc_create() Thanks to commit 4bbd360a5084 (\"socket: Print pf->create() when it does not clear sock->sk on failure.\"), syzbot found an issue with AF_SMC: smc_create must clear sock->sk on failure, family: 43, type: 1, protocol: 0 WARNING: CPU: 0 PID: 5827 at net/socket.c:1565 __sock_create+0x96f/0xa30 net/socket.c:1563 Modules linked in: CPU: 0 UID: 0 PID: 5827 Comm: syz-executor259 Not tainted 6.12.0-rc6-next-20241106-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:__sock_create+0x96f/0xa30 net/socket.c:1563 Code: 03 00 74 08 4c 89 e7 e8 4f 3b 85 f8 49 8b 34 24 48 c7 c7 40 89 0c 8d 8b 54 24 04 8b 4c 24 0c 44 8b 44 24 08 e8 32 78 db f7 90 <0f> 0b 90 90 e9 d3 fd ff ff 89 e9 80 e1 07 fe c1 38 c1 0f 8c ee f7 RSP: 0018:ffffc90003e4fda0 EFLAGS: 00010246 RAX: 099c6f938c7f4700 RBX: 1ffffffff1a595fd RCX: ffff888034823c00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 00000000ffffffe9 R08: ffffffff81567052 R09: 1ffff920007c9f50 R10: dffffc0000000000 R11: fffff520007c9f51 R12: ffffffff8d2cafe8 R13: 1ffffffff1a595fe R14: ffffffff9a789c40 R15: ffff8880764298c0 FS: 000055557b518380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa62ff43225 CR3: 0000000031628000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: sock_create net/socket.c:1616 [inline] __sys_socket_create net/socket.c:1653 [inline] __sys_socket+0x150/0x3c0 net/socket.c:1700 __do_sys_socket net/socket.c:1714 [inline] __se_sys_socket net/socket.c:1712 [inline] For reference, see commit 2d859aff775d (\"Merge branch 'do-not-leave-dangling-sk-pointers-in-pf-create-functions'\")", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50294", "url": "https://ubuntu.com/security/CVE-2024-50294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix missing locking causing hanging calls If a call gets aborted (e.g. because kafs saw a signal) between it being queued for connection and the I/O thread picking up the call, the abort will be prioritised over the connection and it will be removed from local->new_client_calls by rxrpc_disconnect_client_call() without a lock being held. This may cause other calls on the list to disappear if a race occurs. Fix this by taking the client_call_lock when removing a call from whatever list its ->wait_link happens to be on.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50295", "url": "https://ubuntu.com/security/CVE-2024-50295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: arc: fix the device for dma_map_single/dma_unmap_single The ndev->dev and pdev->dev aren't the same device, use ndev->dev.parent which has dma_mask, ndev->dev.parent is just pdev->dev. Or it would cause the following issue: [ 39.933526] ------------[ cut here ]------------ [ 39.938414] WARNING: CPU: 1 PID: 501 at kernel/dma/mapping.c:149 dma_map_page_attrs+0x90/0x1f8", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53082", "url": "https://ubuntu.com/security/CVE-2024-53082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_net: Add hash_key_length check Add hash_key_length check in virtnet_probe() to avoid possible out of bound errors when setting/reading the hash key.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50296", "url": "https://ubuntu.com/security/CVE-2024-50296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash when uninstalling driver When the driver is uninstalled and the VF is disabled concurrently, a kernel crash occurs. The reason is that the two actions call function pci_disable_sriov(). The num_VFs is checked to determine whether to release the corresponding resources. During the second calling, num_VFs is not 0 and the resource release function is called. However, the corresponding resource has been released during the first invoking. Therefore, the problem occurs: [15277.839633][T50670] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ... [15278.131557][T50670] Call trace: [15278.134686][T50670] klist_put+0x28/0x12c [15278.138682][T50670] klist_del+0x14/0x20 [15278.142592][T50670] device_del+0xbc/0x3c0 [15278.146676][T50670] pci_remove_bus_device+0x84/0x120 [15278.151714][T50670] pci_stop_and_remove_bus_device+0x6c/0x80 [15278.157447][T50670] pci_iov_remove_virtfn+0xb4/0x12c [15278.162485][T50670] sriov_disable+0x50/0x11c [15278.166829][T50670] pci_disable_sriov+0x24/0x30 [15278.171433][T50670] hnae3_unregister_ae_algo_prepare+0x60/0x90 [hnae3] [15278.178039][T50670] hclge_exit+0x28/0xd0 [hclge] [15278.182730][T50670] __se_sys_delete_module.isra.0+0x164/0x230 [15278.188550][T50670] __arm64_sys_delete_module+0x1c/0x30 [15278.193848][T50670] invoke_syscall+0x50/0x11c [15278.198278][T50670] el0_svc_common.constprop.0+0x158/0x164 [15278.203837][T50670] do_el0_svc+0x34/0xcc [15278.207834][T50670] el0_svc+0x20/0x30 For details, see the following figure. rmmod hclge disable VFs ---------------------------------------------------- hclge_exit() sriov_numvfs_store() ... device_lock() pci_disable_sriov() hns3_pci_sriov_configure() pci_disable_sriov() sriov_disable() sriov_disable() if !num_VFs : if !num_VFs : return; return; sriov_del_vfs() sriov_del_vfs() ... ... klist_put() klist_put() ... ... num_VFs = 0; num_VFs = 0; device_unlock(); In this patch, when driver is removing, we get the device_lock() to protect num_VFs, just like sriov_numvfs_store().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53088", "url": "https://ubuntu.com/security/CVE-2024-53088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: fix race condition by adding filter's intermediate sync state Fix a race condition in the i40e driver that leads to MAC/VLAN filters becoming corrupted and leaking. Address the issue that occurs under heavy load when multiple threads are concurrently modifying MAC/VLAN filters by setting mac and port VLAN. 1. Thread T0 allocates a filter in i40e_add_filter() within i40e_ndo_set_vf_port_vlan(). 2. Thread T1 concurrently frees the filter in __i40e_del_filter() within i40e_ndo_set_vf_mac(). 3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which refers to the already freed filter memory, causing corruption. Reproduction steps: 1. Spawn multiple VFs. 2. Apply a concurrent heavy load by running parallel operations to change MAC addresses on the VFs and change port VLANs on the host. 3. Observe errors in dmesg: \"Error I40E_AQ_RC_ENOSPC adding RX filters on VF XX, \tplease set promiscuous on manually for VF XX\". Exact code for stable reproduction Intel can't open-source now. The fix involves implementing a new intermediate filter state, I40E_FILTER_NEW_SYNC, for the time when a filter is on a tmp_add_list. These filters cannot be deleted from the hash list directly but must be removed using the full process.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50297", "url": "https://ubuntu.com/security/CVE-2024-50297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: xilinx: axienet: Enqueue Tx packets in dql before dmaengine starts Enqueue packets in dql after dma engine starts causes race condition. Tx transfer starts once dma engine is started and may execute dql dequeue in completion before it gets queued. It results in following kernel crash while running iperf stress test: kernel BUG at lib/dynamic_queue_limits.c:99! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP pc : dql_completed+0x238/0x248 lr : dql_completed+0x3c/0x248 Call trace: dql_completed+0x238/0x248 axienet_dma_tx_cb+0xa0/0x170 xilinx_dma_do_tasklet+0xdc/0x290 tasklet_action_common+0xf8/0x11c tasklet_action+0x30/0x3c handle_softirqs+0xf8/0x230 Start dmaengine after enqueue in dql fixes the crash.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50298", "url": "https://ubuntu.com/security/CVE-2024-50298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: enetc: allocate vf_state during PF probes In the previous implementation, vf_state is allocated memory only when VF is enabled. However, net_device_ops::ndo_set_vf_mac() may be called before VF is enabled to configure the MAC address of VF. If this is the case, enetc_pf_set_vf_mac() will access vf_state, resulting in access to a null pointer. The simplified error log is as follows. root@ls1028ardb:~# ip link set eno0 vf 1 mac 00:0c:e7:66:77:89 [ 173.543315] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 [ 173.637254] pc : enetc_pf_set_vf_mac+0x3c/0x80 Message from sy [ 173.641973] lr : do_setlink+0x4a8/0xec8 [ 173.732292] Call trace: [ 173.734740] enetc_pf_set_vf_mac+0x3c/0x80 [ 173.738847] __rtnl_newlink+0x530/0x89c [ 173.742692] rtnl_newlink+0x50/0x7c [ 173.746189] rtnetlink_rcv_msg+0x128/0x390 [ 173.750298] netlink_rcv_skb+0x60/0x130 [ 173.754145] rtnetlink_rcv+0x18/0x24 [ 173.757731] netlink_unicast+0x318/0x380 [ 173.761665] netlink_sendmsg+0x17c/0x3c8", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50299", "url": "https://ubuntu.com/security/CVE-2024-50299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: properly validate chunk size in sctp_sf_ootb() A size validation fix similar to that in Commit 50619dbf8db7 (\"sctp: add size validation when walking chunks\") is also required in sctp_sf_ootb() to address a crash reported by syzbot: BUG: KMSAN: uninit-value in sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_do_sm+0x181/0x93d0 net/sctp/sm_sideeffect.c:1166 sctp_endpoint_bh_rcv+0xc38/0xf90 net/sctp/endpointola.c:407 sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88 sctp_rcv+0x3831/0x3b20 net/sctp/input.c:243 sctp4_rcv+0x42/0x50 net/sctp/protocol.c:1159 ip_protocol_deliver_rcu+0xb51/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50300", "url": "https://ubuntu.com/security/CVE-2024-50300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: rtq2208: Fix uninitialized use of regulator_config Fix rtq2208 driver uninitialized use to cause kernel error.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50301", "url": "https://ubuntu.com/security/CVE-2024-50301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: security/keys: fix slab-out-of-bounds in key_task_permission KASAN reports an out of bounds read: BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline] BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362 CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0x107/0x167 lib/dump_stack.c:123 print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 __kuid_val include/linux/uidgid.h:36 [inline] uid_eq include/linux/uidgid.h:63 [inline] key_task_permission+0x394/0x410 security/keys/permission.c:54 search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793 This issue was also reported by syzbot. It can be reproduced by following these steps(more details [1]): 1. Obtain more than 32 inputs that have similar hashes, which ends with the pattern '0xxxxxxxe6'. 2. Reboot and add the keys obtained in step 1. The reproducer demonstrates how this issue happened: 1. In the search_nested_keyrings function, when it iterates through the slots in a node(below tag ascend_to_node), if the slot pointer is meta and node->back_pointer != NULL(it means a root), it will proceed to descend_to_node. However, there is an exception. If node is the root, and one of the slots points to a shortcut, it will be treated as a keyring. 2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function. However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as ASSOC_ARRAY_PTR_SUBTYPE_MASK. 3. When 32 keys with the similar hashes are added to the tree, the ROOT has keys with hashes that are not similar (e.g. slot 0) and it splits NODE A without using a shortcut. When NODE A is filled with keys that all hashes are xxe6, the keys are similar, NODE A will split with a shortcut. Finally, it forms the tree as shown below, where slot 6 points to a shortcut. NODE A +------>+---+ ROOT | | 0 | xxe6 +---+ | +---+ xxxx | 0 | shortcut : : xxe6 +---+ | +---+ xxe6 : : | | | xxe6 +---+ | +---+ | 6 |---+ : : xxe6 +---+ +---+ xxe6 : : | f | xxe6 +---+ +---+ xxe6 | f | +---+ 4. As mentioned above, If a slot(slot 6) of the root points to a shortcut, it may be mistakenly transferred to a key*, leading to a read out-of-bounds read. To fix this issue, one should jump to descend_to_node if the ptr is a shortcut, regardless of whether the node is root or not. [1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/ [jarkko: tweaked the commit message a bit to have an appropriate closes tag.]", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53072", "url": "https://ubuntu.com/security/CVE-2024-53072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/pmc: Detect when STB is not available Loading the amd_pmc module as: amd_pmc enable_stb=1 ...can result in the following messages in the kernel ring buffer: amd_pmc AMDI0009:00: SMU cmd failed. err: 0xff ioremap on RAM at 0x0000000000000000 - 0x0000000000ffffff WARNING: CPU: 10 PID: 2151 at arch/x86/mm/ioremap.c:217 __ioremap_caller+0x2cd/0x340 Further debugging reveals that this occurs when the requests for S2D_PHYS_ADDR_LOW and S2D_PHYS_ADDR_HIGH return a value of 0, indicating that the STB is inaccessible. To prevent the ioremap warning and provide clarity to the user, handle the invalid address and display an error message.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50302", "url": "https://ubuntu.com/security/CVE-2024-50302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: zero-initialize the report buffer Since the report buffer is used by all kinds of drivers in various ways, let's zero-initialize it during allocation to make sure that it can't be ever used to leak kernel memory via specially-crafted report.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53068", "url": "https://ubuntu.com/security/CVE-2024-53068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix slab-use-after-free in scmi_bus_notifier() The scmi_dev->name is released prematurely in __scmi_device_destroy(), which causes slab-use-after-free when accessing scmi_dev->name in scmi_bus_notifier(). So move the release of scmi_dev->name to scmi_device_release() to avoid slab-use-after-free. | BUG: KASAN: slab-use-after-free in strncmp+0xe4/0xec | Read of size 1 at addr ffffff80a482bcc0 by task swapper/0/1 | | CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.6.38-debug #1 | Hardware name: Qualcomm Technologies, Inc. SA8775P Ride (DT) | Call trace: | dump_backtrace+0x94/0x114 | show_stack+0x18/0x24 | dump_stack_lvl+0x48/0x60 | print_report+0xf4/0x5b0 | kasan_report+0xa4/0xec | __asan_report_load1_noabort+0x20/0x2c | strncmp+0xe4/0xec | scmi_bus_notifier+0x5c/0x54c | notifier_call_chain+0xb4/0x31c | blocking_notifier_call_chain+0x68/0x9c | bus_notify+0x54/0x78 | device_del+0x1bc/0x840 | device_unregister+0x20/0xb4 | __scmi_device_destroy+0xac/0x280 | scmi_device_destroy+0x94/0xd0 | scmi_chan_setup+0x524/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20 | | Allocated by task 1: | kasan_save_stack+0x2c/0x54 | kasan_set_track+0x2c/0x40 | kasan_save_alloc_info+0x24/0x34 | __kasan_kmalloc+0xa0/0xb8 | __kmalloc_node_track_caller+0x6c/0x104 | kstrdup+0x48/0x84 | kstrdup_const+0x34/0x40 | __scmi_device_create.part.0+0x8c/0x408 | scmi_device_create+0x104/0x370 | scmi_chan_setup+0x2a0/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20 | | Freed by task 1: | kasan_save_stack+0x2c/0x54 | kasan_set_track+0x2c/0x40 | kasan_save_free_info+0x38/0x5c | __kasan_slab_free+0xe8/0x164 | __kmem_cache_free+0x11c/0x230 | kfree+0x70/0x130 | kfree_const+0x20/0x40 | __scmi_device_destroy+0x70/0x280 | scmi_device_destroy+0x94/0xd0 | scmi_chan_setup+0x524/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53069", "url": "https://ubuntu.com/security/CVE-2024-53069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: qcom: scm: fix a NULL-pointer dereference Some SCM calls can be invoked with __scm being NULL (the driver may not have been and will not be probed as there's no SCM entry in device-tree). Make sure we don't dereference a NULL pointer.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50212", "url": "https://ubuntu.com/security/CVE-2024-50212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib: alloc_tag_module_unload must wait for pending kfree_rcu calls Ben Greear reports following splat: ------------[ cut here ]------------ net/netfilter/nf_nat_core.c:1114 module nf_nat func:nf_nat_register_fn has 256 allocated at module unload WARNING: CPU: 1 PID: 10421 at lib/alloc_tag.c:168 alloc_tag_module_unload+0x22b/0x3f0 Modules linked in: nf_nat(-) btrfs ufs qnx4 hfsplus hfs minix vfat msdos fat ... Hardware name: Default string Default string/SKYBAY, BIOS 5.12 08/04/2020 RIP: 0010:alloc_tag_module_unload+0x22b/0x3f0 codetag_unload_module+0x19b/0x2a0 ? codetag_load_module+0x80/0x80 nf_nat module exit calls kfree_rcu on those addresses, but the free operation is likely still pending by the time alloc_tag checks for leaks. Wait for outstanding kfree_rcu operations to complete before checking resolves this warning. Reproducer: unshare -n iptables-nft -t nat -A PREROUTING -p tcp grep nf_nat /proc/allocinfo # will list 4 allocations rmmod nft_chain_nat rmmod nf_nat # will WARN. [akpm@linux-foundation.org: add comment]", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53046", "url": "https://ubuntu.com/security/CVE-2024-53046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: dts: imx8ulp: correct the flexspi compatible string The flexspi on imx8ulp only has 16 LUTs, and imx8mm flexspi has 32 LUTs, so correct the compatible string here, otherwise will meet below error: [ 1.119072] ------------[ cut here ]------------ [ 1.123926] WARNING: CPU: 0 PID: 1 at drivers/spi/spi-nxp-fspi.c:855 nxp_fspi_exec_op+0xb04/0xb64 [ 1.133239] Modules linked in: [ 1.136448] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-rc6-next-20240902-00001-g131bf9439dd9 #69 [ 1.146821] Hardware name: NXP i.MX8ULP EVK (DT) [ 1.151647] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.158931] pc : nxp_fspi_exec_op+0xb04/0xb64 [ 1.163496] lr : nxp_fspi_exec_op+0xa34/0xb64 [ 1.168060] sp : ffff80008002b2a0 [ 1.171526] x29: ffff80008002b2d0 x28: 0000000000000000 x27: 0000000000000000 [ 1.179002] x26: ffff2eb645542580 x25: ffff800080610014 x24: ffff800080610000 [ 1.186480] x23: ffff2eb645548080 x22: 0000000000000006 x21: ffff2eb6455425e0 [ 1.193956] x20: 0000000000000000 x19: ffff80008002b5e0 x18: ffffffffffffffff [ 1.201432] x17: ffff2eb644467508 x16: 0000000000000138 x15: 0000000000000002 [ 1.208907] x14: 0000000000000000 x13: ffff2eb6400d8080 x12: 00000000ffffff00 [ 1.216378] x11: 0000000000000000 x10: ffff2eb6400d8080 x9 : ffff2eb697adca80 [ 1.223850] x8 : ffff2eb697ad3cc0 x7 : 0000000100000000 x6 : 0000000000000001 [ 1.231324] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000007a6 [ 1.238795] x2 : 0000000000000000 x1 : 00000000000001ce x0 : 00000000ffffff92 [ 1.246267] Call trace: [ 1.248824] nxp_fspi_exec_op+0xb04/0xb64 [ 1.253031] spi_mem_exec_op+0x3a0/0x430 [ 1.257139] spi_nor_read_id+0x80/0xcc [ 1.261065] spi_nor_scan+0x1ec/0xf10 [ 1.264901] spi_nor_probe+0x108/0x2fc [ 1.268828] spi_mem_probe+0x6c/0xbc [ 1.272574] spi_probe+0x84/0xe4 [ 1.275958] really_probe+0xbc/0x29c [ 1.279713] __driver_probe_device+0x78/0x12c [ 1.284277] driver_probe_device+0xd8/0x15c [ 1.288660] __device_attach_driver+0xb8/0x134 [ 1.293316] bus_for_each_drv+0x88/0xe8 [ 1.297337] __device_attach+0xa0/0x190 [ 1.301353] device_initial_probe+0x14/0x20 [ 1.305734] bus_probe_device+0xac/0xb0 [ 1.309752] device_add+0x5d0/0x790 [ 1.313408] __spi_add_device+0x134/0x204 [ 1.317606] of_register_spi_device+0x3b4/0x590 [ 1.322348] spi_register_controller+0x47c/0x754 [ 1.327181] devm_spi_register_controller+0x4c/0xa4 [ 1.332289] nxp_fspi_probe+0x1cc/0x2b0 [ 1.336307] platform_probe+0x68/0xc4 [ 1.340145] really_probe+0xbc/0x29c [ 1.343893] __driver_probe_device+0x78/0x12c [ 1.348457] driver_probe_device+0xd8/0x15c [ 1.352838] __driver_attach+0x90/0x19c [ 1.356857] bus_for_each_dev+0x7c/0xdc [ 1.360877] driver_attach+0x24/0x30 [ 1.364624] bus_add_driver+0xe4/0x208 [ 1.368552] driver_register+0x5c/0x124 [ 1.372573] __platform_driver_register+0x28/0x34 [ 1.377497] nxp_fspi_driver_init+0x1c/0x28 [ 1.381888] do_one_initcall+0x80/0x1c8 [ 1.385908] kernel_init_freeable+0x1c4/0x28c [ 1.390472] kernel_init+0x20/0x1d8 [ 1.394138] ret_from_fork+0x10/0x20 [ 1.397885] ---[ end trace 0000000000000000 ]--- [ 1.407908] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53052", "url": "https://ubuntu.com/security/CVE-2024-53052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/rw: fix missing NOWAIT check for O_DIRECT start write When io_uring starts a write, it'll call kiocb_start_write() to bump the super block rwsem, preventing any freezes from happening while that write is in-flight. The freeze side will grab that rwsem for writing, excluding any new writers from happening and waiting for existing writes to finish. But io_uring unconditionally uses kiocb_start_write(), which will block if someone is currently attempting to freeze the mount point. This causes a deadlock where freeze is waiting for previous writes to complete, but the previous writes cannot complete, as the task that is supposed to complete them is blocked waiting on starting a new write. This results in the following stuck trace showing that dependency with the write blocked starting a new write: task:fio state:D stack:0 pid:886 tgid:886 ppid:876 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_rwsem_wait+0x1e8/0x3f8 __percpu_down_read+0xe8/0x500 io_write+0xbb8/0xff8 io_issue_sqe+0x10c/0x1020 io_submit_sqes+0x614/0x2110 __arm64_sys_io_uring_enter+0x524/0x1038 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 INFO: task fsfreeze:7364 blocked for more than 15 seconds. Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963 with the attempting freezer stuck trying to grab the rwsem: task:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_down_write+0x2b0/0x680 freeze_super+0x248/0x8a8 do_vfs_ioctl+0x149c/0x1b18 __arm64_sys_ioctl+0xd0/0x1a0 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 Fix this by having the io_uring side honor IOCB_NOWAIT, and only attempt a blocking grab of the super block rwsem if it isn't set. For normal issue where IOCB_NOWAIT would always be set, this returns -EAGAIN which will have io_uring core issue a blocking attempt of the write. That will in turn also get completions run, ensuring forward progress. Since freezing requires CAP_SYS_ADMIN in the first place, this isn't something that can be triggered by a regular user.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50213", "url": "https://ubuntu.com/security/CVE-2024-50213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tests: hdmi: Fix memory leaks in drm_display_mode_from_cea_vic() modprobe drm_hdmi_state_helper_test and then rmmod it, the following memory leak occurs. The `mode` allocated in drm_mode_duplicate() called by drm_display_mode_from_cea_vic() is not freed, which cause the memory leak: \tunreferenced object 0xffffff80ccd18100 (size 128): \t comm \"kunit_try_catch\", pid 1851, jiffies 4295059695 \t hex dump (first 32 bytes): \t 57 62 00 00 80 02 90 02 f0 02 20 03 00 00 e0 01 Wb........ ..... \t ea 01 ec 01 0d 02 00 00 0a 00 00 00 00 00 00 00 ................ \t backtrace (crc c2f1aa95): \t [<000000000f10b11b>] kmemleak_alloc+0x34/0x40 \t [<000000001cd4cf73>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<00000000f1f3cffa>] drm_mode_duplicate+0x44/0x19c \t [<000000008cbeef13>] drm_display_mode_from_cea_vic+0x88/0x98 \t [<0000000019daaacf>] 0xffffffedc11ae69c \t [<000000000aad0f85>] kunit_try_run_case+0x13c/0x3ac \t [<00000000a9210bac>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<000000000a0b2e9e>] kthread+0x2e8/0x374 \t [<00000000bd668858>] ret_from_fork+0x10/0x20 \t...... Free `mode` by using drm_kunit_display_mode_from_cea_vic() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50214", "url": "https://ubuntu.com/security/CVE-2024-50214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/connector: hdmi: Fix memory leak in drm_display_mode_from_cea_vic() modprobe drm_connector_test and then rmmod drm_connector_test, the following memory leak occurs. The `mode` allocated in drm_mode_duplicate() called by drm_display_mode_from_cea_vic() is not freed, which cause the memory leak: \tunreferenced object 0xffffff80cb0ee400 (size 128): \t comm \"kunit_try_catch\", pid 1948, jiffies 4294950339 \t hex dump (first 32 bytes): \t 14 44 02 00 80 07 d8 07 04 08 98 08 00 00 38 04 .D............8. \t 3c 04 41 04 65 04 00 00 05 00 00 00 00 00 00 00 <.A.e........... \t backtrace (crc 90e9585c): \t [<00000000ec42e3d7>] kmemleak_alloc+0x34/0x40 \t [<00000000d0ef055a>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<00000000c2062161>] drm_mode_duplicate+0x44/0x19c \t [<00000000f96c74aa>] drm_display_mode_from_cea_vic+0x88/0x98 \t [<00000000d8f2c8b4>] 0xffffffdc982a4868 \t [<000000005d164dbc>] kunit_try_run_case+0x13c/0x3ac \t [<000000006fb23398>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<000000006ea56ca0>] kthread+0x2e8/0x374 \t [<000000000676063f>] ret_from_fork+0x10/0x20 \t...... Free `mode` by using drm_kunit_display_mode_from_cea_vic() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50215", "url": "https://ubuntu.com/security/CVE-2024-50215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: assign dh_key to NULL after kfree_sensitive ctrl->dh_key might be used across multiple calls to nvmet_setup_dhgroup() for the same controller. So it's better to nullify it after release on error path in order to avoid double free later in nvmet_destroy_auth(). Found by Linux Verification Center (linuxtesting.org) with Svace.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50216", "url": "https://ubuntu.com/security/CVE-2024-50216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix finding a last resort AG in xfs_filestream_pick_ag When the main loop in xfs_filestream_pick_ag fails to find a suitable AG it tries to just pick the online AG. But the loop for that uses args->pag as loop iterator while the later code expects pag to be set. Fix this by reusing the max_pag case for this last resort, and also add a check for impossible case of no AG just to make sure that the uninitialized pag doesn't even escape in theory.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50217", "url": "https://ubuntu.com/security/CVE-2024-50217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free of block device file in __btrfs_free_extra_devids() Mounting btrfs from two images (which have the same one fsid and two different dev_uuids) in certain executing order may trigger an UAF for variable 'device->bdev_file' in __btrfs_free_extra_devids(). And following are the details: 1. Attach image_1 to loop0, attach image_2 to loop1, and scan btrfs devices by ioctl(BTRFS_IOC_SCAN_DEV): / btrfs_device_1 ? loop0 fs_device \\ btrfs_device_2 ? loop1 2. mount /dev/loop0 /mnt btrfs_open_devices btrfs_device_1->bdev_file = btrfs_get_bdev_and_sb(loop0) btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree fail: btrfs_close_devices // -ENOMEM \t btrfs_close_bdev(btrfs_device_1) fput(btrfs_device_1->bdev_file) \t // btrfs_device_1->bdev_file is freed \t btrfs_close_bdev(btrfs_device_2) fput(btrfs_device_2->bdev_file) 3. mount /dev/loop1 /mnt btrfs_open_devices btrfs_get_bdev_and_sb(&bdev_file) // EIO, btrfs_device_1->bdev_file is not assigned, // which points to a freed memory area btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree btrfs_free_extra_devids if (btrfs_device_1->bdev_file) fput(btrfs_device_1->bdev_file) // UAF ! Fix it by setting 'device->bdev_file' as 'NULL' after closing the btrfs_device in btrfs_close_one_device().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53043", "url": "https://ubuntu.com/security/CVE-2024-53043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mctp i2c: handle NULL header address daddr can be NULL if there is no neighbour table entry present, in that case the tx packet should be dropped. saddr will usually be set by MCTP core, but check for NULL in case a packet is transmitted by a different protocol.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50303", "url": "https://ubuntu.com/security/CVE-2024-50303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: resource,kexec: walk_system_ram_res_rev must retain resource flags walk_system_ram_res_rev() erroneously discards resource flags when passing the information to the callback. This causes systems with IORESOURCE_SYSRAM_DRIVER_MANAGED memory to have these resources selected during kexec to store kexec buffers if that memory happens to be at placed above normal system ram. This leads to undefined behavior after reboot. If the kexec buffer is never touched, nothing happens. If the kexec buffer is touched, it could lead to a crash (like below) or undefined behavior. Tested on a system with CXL memory expanders with driver managed memory, TPM enabled, and CONFIG_IMA_KEXEC=y. Adding printk's showed the flags were being discarded and as a result the check for IORESOURCE_SYSRAM_DRIVER_MANAGED passes. find_next_iomem_res: name(System RAM (kmem)) \t\t start(10000000000) \t\t end(1034fffffff) \t\t flags(83000200) locate_mem_hole_top_down: start(10000000000) end(1034fffffff) flags(0) [.] BUG: unable to handle page fault for address: ffff89834ffff000 [.] #PF: supervisor read access in kernel mode [.] #PF: error_code(0x0000) - not-present page [.] PGD c04c8bf067 P4D c04c8bf067 PUD c04c8be067 PMD 0 [.] Oops: 0000 [#1] SMP [.] RIP: 0010:ima_restore_measurement_list+0x95/0x4b0 [.] RSP: 0018:ffffc900000d3a80 EFLAGS: 00010286 [.] RAX: 0000000000001000 RBX: 0000000000000000 RCX: ffff89834ffff000 [.] RDX: 0000000000000018 RSI: ffff89834ffff000 RDI: ffff89834ffff018 [.] RBP: ffffc900000d3ba0 R08: 0000000000000020 R09: ffff888132b8a900 [.] R10: 4000000000000000 R11: 000000003a616d69 R12: 0000000000000000 [.] R13: ffffffff8404ac28 R14: 0000000000000000 R15: ffff89834ffff000 [.] FS: 0000000000000000(0000) GS:ffff893d44640000(0000) knlGS:0000000000000000 [.] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [.] ata5: SATA link down (SStatus 0 SControl 300) [.] CR2: ffff89834ffff000 CR3: 000001034d00f001 CR4: 0000000000770ef0 [.] PKRU: 55555554 [.] Call Trace: [.] [.] ? __die+0x78/0xc0 [.] ? page_fault_oops+0x2a8/0x3a0 [.] ? exc_page_fault+0x84/0x130 [.] ? asm_exc_page_fault+0x22/0x30 [.] ? ima_restore_measurement_list+0x95/0x4b0 [.] ? template_desc_init_fields+0x317/0x410 [.] ? crypto_alloc_tfm_node+0x9c/0xc0 [.] ? init_ima_lsm+0x30/0x30 [.] ima_load_kexec_buffer+0x72/0xa0 [.] ima_init+0x44/0xa0 [.] __initstub__kmod_ima__373_1201_init_ima7+0x1e/0xb0 [.] ? init_ima_lsm+0x30/0x30 [.] do_one_initcall+0xad/0x200 [.] ? idr_alloc_cyclic+0xaa/0x110 [.] ? new_slab+0x12c/0x420 [.] ? new_slab+0x12c/0x420 [.] ? number+0x12a/0x430 [.] ? sysvec_apic_timer_interrupt+0xa/0x80 [.] ? asm_sysvec_apic_timer_interrupt+0x16/0x20 [.] ? parse_args+0xd4/0x380 [.] ? parse_args+0x14b/0x380 [.] kernel_init_freeable+0x1c1/0x2b0 [.] ? rest_init+0xb0/0xb0 [.] kernel_init+0x16/0x1a0 [.] ret_from_fork+0x2f/0x40 [.] ? rest_init+0xb0/0xb0 [.] ret_from_fork_asm+0x11/0x20 [.] ", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50218", "url": "https://ubuntu.com/security/CVE-2024-50218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow Syzbot reported a kernel BUG in ocfs2_truncate_inline. There are two reasons for this: first, the parameter value passed is greater than ocfs2_max_inline_data_with_xattr, second, the start and end parameters of ocfs2_truncate_inline are \"unsigned int\". So, we need to add a sanity check for byte_start and byte_len right before ocfs2_truncate_inline() in ocfs2_remove_inode_range(), if they are greater than ocfs2_max_inline_data_with_xattr return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50219", "url": "https://ubuntu.com/security/CVE-2024-50219", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50263", "url": "https://ubuntu.com/security/CVE-2024-50263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fork: only invoke khugepaged, ksm hooks if no error There is no reason to invoke these hooks early against an mm that is in an incomplete state. The change in commit d24062914837 (\"fork: use __mt_dup() to duplicate maple tree in dup_mmap()\") makes this more pertinent as we may be in a state where entries in the maple tree are not yet consistent. Their placement early in dup_mmap() only appears to have been meaningful for early error checking, and since functionally it'd require a very small allocation to fail (in practice 'too small to fail') that'd only occur in the most dire circumstances, meaning the fork would fail or be OOM'd in any case. Since both khugepaged and KSM tracking are there to provide optimisations to memory performance rather than critical functionality, it doesn't really matter all that much if, under such dire memory pressure, we fail to register an mm with these. As a result, we follow the example of commit d2081b2bf819 (\"mm: khugepaged: make khugepaged_enter() void function\") and make ksm_fork() a void function also. We only expose the mm to these functions once we are done with them and only if no error occurred in the fork operation.", "cve_priority": "medium", "cve_public_date": "2024-11-11 14:15:00 UTC" }, { "cve": "CVE-2024-50220", "url": "https://ubuntu.com/security/CVE-2024-50220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fork: do not invoke uffd on fork if error occurs Patch series \"fork: do not expose incomplete mm on fork\". During fork we may place the virtual memory address space into an inconsistent state before the fork operation is complete. In addition, we may encounter an error during the fork operation that indicates that the virtual memory address space is invalidated. As a result, we should not be exposing it in any way to external machinery that might interact with the mm or VMAs, machinery that is not designed to deal with incomplete state. We specifically update the fork logic to defer khugepaged and ksm to the end of the operation and only to be invoked if no error arose, and disallow uffd from observing fork events should an error have occurred. This patch (of 2): Currently on fork we expose the virtual address space of a process to userland unconditionally if uffd is registered in VMAs, regardless of whether an error arose in the fork. This is performed in dup_userfaultfd_complete() which is invoked unconditionally, and performs two duties - invoking registered handlers for the UFFD_EVENT_FORK event via dup_fctx(), and clearing down userfaultfd_fork_ctx objects established in dup_userfaultfd(). This is problematic, because the virtual address space may not yet be correctly initialised if an error arose. The change in commit d24062914837 (\"fork: use __mt_dup() to duplicate maple tree in dup_mmap()\") makes this more pertinent as we may be in a state where entries in the maple tree are not yet consistent. We address this by, on fork error, ensuring that we roll back state that we would otherwise expect to clean up through the event being handled by userland and perform the memory freeing duty otherwise performed by dup_userfaultfd_complete(). We do this by implementing a new function, dup_userfaultfd_fail(), which performs the same loop, only decrementing reference counts. Note that we perform mmgrab() on the parent and child mm's, however userfaultfd_ctx_put() will mmdrop() this once the reference count drops to zero, so we will avoid memory leaks correctly here.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53047", "url": "https://ubuntu.com/security/CVE-2024-53047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: init: protect sched with rcu_read_lock Enabling CONFIG_PROVE_RCU_LIST with its dependence CONFIG_RCU_EXPERT creates this splat when an MPTCP socket is created: ============================= WARNING: suspicious RCU usage 6.12.0-rc2+ #11 Not tainted ----------------------------- net/mptcp/sched.c:44 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 no locks held by mptcp_connect/176. stack backtrace: CPU: 0 UID: 0 PID: 176 Comm: mptcp_connect Not tainted 6.12.0-rc2+ #11 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl (lib/dump_stack.c:123) lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822) mptcp_sched_find (net/mptcp/sched.c:44 (discriminator 7)) mptcp_init_sock (net/mptcp/protocol.c:2867 (discriminator 1)) ? sock_init_data_uid (arch/x86/include/asm/atomic.h:28) inet_create.part.0.constprop.0 (net/ipv4/af_inet.c:386) ? __sock_create (include/linux/rcupdate.h:347 (discriminator 1)) __sock_create (net/socket.c:1576) __sys_socket (net/socket.c:1671) ? __pfx___sys_socket (net/socket.c:1712) ? do_user_addr_fault (arch/x86/mm/fault.c:1419 (discriminator 1)) __x64_sys_socket (net/socket.c:1728) do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) That's because when the socket is initialised, rcu_read_lock() is not used despite the explicit comment written above the declaration of mptcp_sched_find() in sched.c. Adding the missing lock/unlock avoids the warning.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50221", "url": "https://ubuntu.com/security/CVE-2024-50221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Vangogh: Fix kernel memory out of bounds write KASAN reports that the GPU metrics table allocated in vangogh_tables_init() is not large enough for the memset done in smu_cmn_init_soft_gpu_metrics(). Condensed report follows: [ 33.861314] BUG: KASAN: slab-out-of-bounds in smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu] [ 33.861799] Write of size 168 at addr ffff888129f59500 by task mangoapp/1067 ... [ 33.861808] CPU: 6 UID: 1000 PID: 1067 Comm: mangoapp Tainted: G W 6.12.0-rc4 #356 1a56f59a8b5182eeaf67eb7cb8b13594dd23b544 [ 33.861816] Tainted: [W]=WARN [ 33.861818] Hardware name: Valve Galileo/Galileo, BIOS F7G0107 12/01/2023 [ 33.861822] Call Trace: [ 33.861826] [ 33.861829] dump_stack_lvl+0x66/0x90 [ 33.861838] print_report+0xce/0x620 [ 33.861853] kasan_report+0xda/0x110 [ 33.862794] kasan_check_range+0xfd/0x1a0 [ 33.862799] __asan_memset+0x23/0x40 [ 33.862803] smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.863306] vangogh_get_gpu_metrics_v2_4+0x123/0xad0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.864257] vangogh_common_get_gpu_metrics+0xb0c/0xbc0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.865682] amdgpu_dpm_get_gpu_metrics+0xcc/0x110 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.866160] amdgpu_get_gpu_metrics+0x154/0x2d0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.867135] dev_attr_show+0x43/0xc0 [ 33.867147] sysfs_kf_seq_show+0x1f1/0x3b0 [ 33.867155] seq_read_iter+0x3f8/0x1140 [ 33.867173] vfs_read+0x76c/0xc50 [ 33.867198] ksys_read+0xfb/0x1d0 [ 33.867214] do_syscall_64+0x90/0x160 ... [ 33.867353] Allocated by task 378 on cpu 7 at 22.794876s: [ 33.867358] kasan_save_stack+0x33/0x50 [ 33.867364] kasan_save_track+0x17/0x60 [ 33.867367] __kasan_kmalloc+0x87/0x90 [ 33.867371] vangogh_init_smc_tables+0x3f9/0x840 [amdgpu] [ 33.867835] smu_sw_init+0xa32/0x1850 [amdgpu] [ 33.868299] amdgpu_device_init+0x467b/0x8d90 [amdgpu] [ 33.868733] amdgpu_driver_load_kms+0x19/0xf0 [amdgpu] [ 33.869167] amdgpu_pci_probe+0x2d6/0xcd0 [amdgpu] [ 33.869608] local_pci_probe+0xda/0x180 [ 33.869614] pci_device_probe+0x43f/0x6b0 Empirically we can confirm that the former allocates 152 bytes for the table, while the latter memsets the 168 large block. Root cause appears that when GPU metrics tables for v2_4 parts were added it was not considered to enlarge the table to fit. The fix in this patch is rather \"brute force\" and perhaps later should be done in a smarter way, by extracting and consolidating the part version to size logic to a common helper, instead of brute forcing the largest possible allocation. Nevertheless, for now this works and fixes the out of bounds write. v2: * Drop impossible v3_0 case. (Mario) (cherry picked from commit 0880f58f9609f0200483a49429af0f050d281703)", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50222", "url": "https://ubuntu.com/security/CVE-2024-50222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iov_iter: fix copy_page_from_iter_atomic() if KMAP_LOCAL_FORCE_MAP generic/077 on x86_32 CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP=y with highmem, on huge=always tmpfs, issues a warning and then hangs (interruptibly): WARNING: CPU: 5 PID: 3517 at mm/highmem.c:622 kunmap_local_indexed+0x62/0xc9 CPU: 5 UID: 0 PID: 3517 Comm: cp Not tainted 6.12.0-rc4 #2 ... copy_page_from_iter_atomic+0xa6/0x5ec generic_perform_write+0xf6/0x1b4 shmem_file_write_iter+0x54/0x67 Fix copy_page_from_iter_atomic() by limiting it in that case (include/linux/skbuff.h skb_frag_must_loop() does similar). But going forward, perhaps CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP is too surprising, has outlived its usefulness, and should just be removed?", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50223", "url": "https://ubuntu.com/security/CVE-2024-50223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/numa: Fix the potential null pointer dereference in task_numa_work() When running stress-ng-vm-segv test, we found a null pointer dereference error in task_numa_work(). Here is the backtrace: [323676.066985] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ...... [323676.067108] CPU: 35 PID: 2694524 Comm: stress-ng-vm-se ...... [323676.067113] pstate: 23401009 (nzCv daif +PAN -UAO +TCO +DIT +SSBS BTYPE=--) [323676.067115] pc : vma_migratable+0x1c/0xd0 [323676.067122] lr : task_numa_work+0x1ec/0x4e0 [323676.067127] sp : ffff8000ada73d20 [323676.067128] x29: ffff8000ada73d20 x28: 0000000000000000 x27: 000000003e89f010 [323676.067130] x26: 0000000000080000 x25: ffff800081b5c0d8 x24: ffff800081b27000 [323676.067133] x23: 0000000000010000 x22: 0000000104d18cc0 x21: ffff0009f7158000 [323676.067135] x20: 0000000000000000 x19: 0000000000000000 x18: ffff8000ada73db8 [323676.067138] x17: 0001400000000000 x16: ffff800080df40b0 x15: 0000000000000035 [323676.067140] x14: ffff8000ada73cc8 x13: 1fffe0017cc72001 x12: ffff8000ada73cc8 [323676.067142] x11: ffff80008001160c x10: ffff000be639000c x9 : ffff8000800f4ba4 [323676.067145] x8 : ffff000810375000 x7 : ffff8000ada73974 x6 : 0000000000000001 [323676.067147] x5 : 0068000b33e26707 x4 : 0000000000000001 x3 : ffff0009f7158000 [323676.067149] x2 : 0000000000000041 x1 : 0000000000004400 x0 : 0000000000000000 [323676.067152] Call trace: [323676.067153] vma_migratable+0x1c/0xd0 [323676.067155] task_numa_work+0x1ec/0x4e0 [323676.067157] task_work_run+0x78/0xd8 [323676.067161] do_notify_resume+0x1ec/0x290 [323676.067163] el0_svc+0x150/0x160 [323676.067167] el0t_64_sync_handler+0xf8/0x128 [323676.067170] el0t_64_sync+0x17c/0x180 [323676.067173] Code: d2888001 910003fd f9000bf3 aa0003f3 (f9401000) [323676.067177] SMP: stopping secondary CPUs [323676.070184] Starting crashdump kernel... stress-ng-vm-segv in stress-ng is used to stress test the SIGSEGV error handling function of the system, which tries to cause a SIGSEGV error on return from unmapping the whole address space of the child process. Normally this program will not cause kernel crashes. But before the munmap system call returns to user mode, a potential task_numa_work() for numa balancing could be added and executed. In this scenario, since the child process has no vma after munmap, the vma_next() in task_numa_work() will return a null pointer even if the vma iterator restarts from 0. Recheck the vma pointer before dereferencing it in task_numa_work().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53053", "url": "https://ubuntu.com/security/CVE-2024-53053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Fix another deadlock during RTC update If ufshcd_rtc_work calls ufshcd_rpm_put_sync() and the pm's usage_count is 0, we will enter the runtime suspend callback. However, the runtime suspend callback will wait to flush ufshcd_rtc_work, causing a deadlock. Replace ufshcd_rpm_put_sync() with ufshcd_rpm_put() to avoid the deadlock.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53075", "url": "https://ubuntu.com/security/CVE-2024-53075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv: Prevent a bad reference count on CPU nodes When populating cache leaves we previously fetched the CPU device node at the very beginning. But when ACPI is enabled we go through a specific branch which returns early and does not call 'of_node_put' for the node that was acquired. Since we are not using a CPU device node for the ACPI code anyways, we can simply move the initialization of it just passed the ACPI block, and we are guaranteed to have an 'of_node_put' call for the acquired node. This prevents a bad reference count of the CPU device node. Moreover, the previous function did not check for errors when acquiring the device node, so a return -ENOENT has been added for that case.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50224", "url": "https://ubuntu.com/security/CVE-2024-50224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: spi-fsl-dspi: Fix crash when not using GPIO chip select Add check for the return value of spi_get_csgpiod() to avoid passing a NULL pointer to gpiod_direction_output(), preventing a crash when GPIO chip select is not used. Fix below crash: [ 4.251960] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 4.260762] Mem abort info: [ 4.263556] ESR = 0x0000000096000004 [ 4.267308] EC = 0x25: DABT (current EL), IL = 32 bits [ 4.272624] SET = 0, FnV = 0 [ 4.275681] EA = 0, S1PTW = 0 [ 4.278822] FSC = 0x04: level 0 translation fault [ 4.283704] Data abort info: [ 4.286583] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 4.292074] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 4.297130] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 4.302445] [0000000000000000] user address but active_mm is swapper [ 4.308805] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 4.315072] Modules linked in: [ 4.318124] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc4-next-20241023-00008-ga20ec42c5fc1 #359 [ 4.328130] Hardware name: LS1046A QDS Board (DT) [ 4.332832] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 4.339794] pc : gpiod_direction_output+0x34/0x5c [ 4.344505] lr : gpiod_direction_output+0x18/0x5c [ 4.349208] sp : ffff80008003b8f0 [ 4.352517] x29: ffff80008003b8f0 x28: 0000000000000000 x27: ffffc96bcc7e9068 [ 4.359659] x26: ffffc96bcc6e00b0 x25: ffffc96bcc598398 x24: ffff447400132810 [ 4.366800] x23: 0000000000000000 x22: 0000000011e1a300 x21: 0000000000020002 [ 4.373940] x20: 0000000000000000 x19: 0000000000000000 x18: ffffffffffffffff [ 4.381081] x17: ffff44740016e600 x16: 0000000500000003 x15: 0000000000000007 [ 4.388221] x14: 0000000000989680 x13: 0000000000020000 x12: 000000000000001e [ 4.395362] x11: 0044b82fa09b5a53 x10: 0000000000000019 x9 : 0000000000000008 [ 4.402502] x8 : 0000000000000002 x7 : 0000000000000007 x6 : 0000000000000000 [ 4.409641] x5 : 0000000000000200 x4 : 0000000002000000 x3 : 0000000000000000 [ 4.416781] x2 : 0000000000022202 x1 : 0000000000000000 x0 : 0000000000000000 [ 4.423921] Call trace: [ 4.426362] gpiod_direction_output+0x34/0x5c (P) [ 4.431067] gpiod_direction_output+0x18/0x5c (L) [ 4.435771] dspi_setup+0x220/0x334", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50225", "url": "https://ubuntu.com/security/CVE-2024-50225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix error propagation of split bios The purpose of btrfs_bbio_propagate_error() shall be propagating an error of split bio to its original btrfs_bio, and tell the error to the upper layer. However, it's not working well on some cases. * Case 1. Immediate (or quick) end_bio with an error When btrfs sends btrfs_bio to mirrored devices, btrfs calls btrfs_bio_end_io() when all the mirroring bios are completed. If that btrfs_bio was split, it is from btrfs_clone_bioset and its end_io function is btrfs_orig_write_end_io. For this case, btrfs_bbio_propagate_error() accesses the orig_bbio's bio context to increase the error count. That works well in most cases. However, if the end_io is called enough fast, orig_bbio's (remaining part after split) bio context may not be properly set at that time. Since the bio context is set when the orig_bbio (the last btrfs_bio) is sent to devices, that might be too late for earlier split btrfs_bio's completion. That will result in NULL pointer dereference. That bug is easily reproducible by running btrfs/146 on zoned devices [1] and it shows the following trace. [1] You need raid-stripe-tree feature as it create \"-d raid0 -m raid1\" FS. BUG: kernel NULL pointer dereference, address: 0000000000000020 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 UID: 0 PID: 13 Comm: kworker/u32:1 Not tainted 6.11.0-rc7-BTRFS-ZNS+ #474 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Workqueue: writeback wb_workfn (flush-btrfs-5) RIP: 0010:btrfs_bio_end_io+0xae/0xc0 [btrfs] BTRFS error (device dm-0): bdev /dev/mapper/error-test errs: wr 2, rd 0, flush 0, corrupt 0, gen 0 RSP: 0018:ffffc9000006f248 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888005a7f080 RCX: ffffc9000006f1dc RDX: 0000000000000000 RSI: 000000000000000a RDI: ffff888005a7f080 RBP: ffff888011dfc540 R08: 0000000000000000 R09: 0000000000000001 R10: ffffffff82e508e0 R11: 0000000000000005 R12: ffff88800ddfbe58 R13: ffff888005a7f080 R14: ffff888005a7f158 R15: ffff888005a7f158 FS: 0000000000000000(0000) GS:ffff88803ea80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000020 CR3: 0000000002e22006 CR4: 0000000000370ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __die_body.cold+0x19/0x26 ? page_fault_oops+0x13e/0x2b0 ? _printk+0x58/0x73 ? do_user_addr_fault+0x5f/0x750 ? exc_page_fault+0x76/0x240 ? asm_exc_page_fault+0x22/0x30 ? btrfs_bio_end_io+0xae/0xc0 [btrfs] ? btrfs_log_dev_io_error+0x7f/0x90 [btrfs] btrfs_orig_write_end_io+0x51/0x90 [btrfs] dm_submit_bio+0x5c2/0xa50 [dm_mod] ? find_held_lock+0x2b/0x80 ? blk_try_enter_queue+0x90/0x1e0 __submit_bio+0xe0/0x130 ? ktime_get+0x10a/0x160 ? lockdep_hardirqs_on+0x74/0x100 submit_bio_noacct_nocheck+0x199/0x410 btrfs_submit_bio+0x7d/0x150 [btrfs] btrfs_submit_chunk+0x1a1/0x6d0 [btrfs] ? lockdep_hardirqs_on+0x74/0x100 ? __folio_start_writeback+0x10/0x2c0 btrfs_submit_bbio+0x1c/0x40 [btrfs] submit_one_bio+0x44/0x60 [btrfs] submit_extent_folio+0x13f/0x330 [btrfs] ? btrfs_set_range_writeback+0xa3/0xd0 [btrfs] extent_writepage_io+0x18b/0x360 [btrfs] extent_write_locked_range+0x17c/0x340 [btrfs] ? __pfx_end_bbio_data_write+0x10/0x10 [btrfs] run_delalloc_cow+0x71/0xd0 [btrfs] btrfs_run_delalloc_range+0x176/0x500 [btrfs] ? find_lock_delalloc_range+0x119/0x260 [btrfs] writepage_delalloc+0x2ab/0x480 [btrfs] extent_write_cache_pages+0x236/0x7d0 [btrfs] btrfs_writepages+0x72/0x130 [btrfs] do_writepages+0xd4/0x240 ? find_held_lock+0x2b/0x80 ? wbc_attach_and_unlock_inode+0x12c/0x290 ? wbc_attach_and_unlock_inode+0x12c/0x29 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53054", "url": "https://ubuntu.com/security/CVE-2024-53054", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50226", "url": "https://ubuntu.com/security/CVE-2024-50226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cxl/port: Fix use-after-free, permit out-of-order decoder shutdown In support of investigating an initialization failure report [1], cxl_test was updated to register mock memory-devices after the mock root-port/bus device had been registered. That led to cxl_test crashing with a use-after-free bug with the following signature: cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem0:decoder7.0 @ 0 next: cxl_switch_uport.0 nr_eps: 1 nr_targets: 1 cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem4:decoder14.0 @ 1 next: cxl_switch_uport.0 nr_eps: 2 nr_targets: 1 cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[0] = cxl_switch_dport.0 for mem0:decoder7.0 @ 0 1) cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[1] = cxl_switch_dport.4 for mem4:decoder14.0 @ 1 [..] cxld_unregister: cxl decoder14.0: cxl_region_decode_reset: cxl_region region3: mock_decoder_reset: cxl_port port3: decoder3.0 reset 2) mock_decoder_reset: cxl_port port3: decoder3.0: out of order reset, expected decoder3.1 cxl_endpoint_decoder_release: cxl decoder14.0: [..] cxld_unregister: cxl decoder7.0: 3) cxl_region_decode_reset: cxl_region region3: Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6bc3: 0000 [#1] PREEMPT SMP PTI [..] RIP: 0010:to_cxl_port+0x8/0x60 [cxl_core] [..] Call Trace: cxl_region_decode_reset+0x69/0x190 [cxl_core] cxl_region_detach+0xe8/0x210 [cxl_core] cxl_decoder_kill_region+0x27/0x40 [cxl_core] cxld_unregister+0x5d/0x60 [cxl_core] At 1) a region has been established with 2 endpoint decoders (7.0 and 14.0). Those endpoints share a common switch-decoder in the topology (3.0). At teardown, 2), decoder14.0 is the first to be removed and hits the \"out of order reset case\" in the switch decoder. The effect though is that region3 cleanup is aborted leaving it in-tact and referencing decoder14.0. At 3) the second attempt to teardown region3 trips over the stale decoder14.0 object which has long since been deleted. The fix here is to recognize that the CXL specification places no mandate on in-order shutdown of switch-decoders, the driver enforces in-order allocation, and hardware enforces in-order commit. So, rather than fail and leave objects dangling, always remove them. In support of making cxl_region_decode_reset() always succeed, cxl_region_invalidate_memregion() failures are turned into warnings. Crashing the kernel is ok there since system integrity is at risk if caches cannot be managed around physical address mutation events like CXL region destruction. A new device_for_each_child_reverse_from() is added to cleanup port->commit_end after all dependent decoders have been disabled. In other words if decoders are allocated 0->1->2 and disabled 1->2->0 then port->commit_end only decrements from 2 after 2 has been disabled, and it decrements all the way to zero since 1 was disabled previously.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50227", "url": "https://ubuntu.com/security/CVE-2024-50227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Fix KASAN reported stack out-of-bounds read in tb_retimer_scan() KASAN reported following issue: BUG: KASAN: stack-out-of-bounds in tb_retimer_scan+0xffe/0x1550 [thunderbolt] Read of size 4 at addr ffff88810111fc1c by task kworker/u56:0/11 CPU: 0 UID: 0 PID: 11 Comm: kworker/u56:0 Tainted: G U 6.11.0+ #1387 Tainted: [U]=USER Workqueue: thunderbolt0 tb_handle_hotplug [thunderbolt] Call Trace: dump_stack_lvl+0x6c/0x90 print_report+0xd1/0x630 kasan_report+0xdb/0x110 __asan_report_load4_noabort+0x14/0x20 tb_retimer_scan+0xffe/0x1550 [thunderbolt] tb_scan_port+0xa6f/0x2060 [thunderbolt] tb_handle_hotplug+0x17b1/0x3080 [thunderbolt] process_one_work+0x626/0x1100 worker_thread+0x6c8/0xfa0 kthread+0x2c8/0x3a0 ret_from_fork+0x3a/0x80 ret_from_fork_asm+0x1a/0x30 This happens because the loop variable still gets incremented by one so max becomes 3 instead of 2, and this makes the second loop read past the the array declared on the stack. Fix this by assigning to max directly in the loop body.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50228", "url": "https://ubuntu.com/security/CVE-2024-50228", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50229", "url": "https://ubuntu.com/security/CVE-2024-50229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential deadlock with newly created symlinks Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers memory reclamation involving the filesystem layer, which can result in circular lock dependencies among the reader/writer semaphore nilfs->ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the fs_reclaim pseudo lock. This is because after commit 21fc61c73c39 (\"don't put symlink bodies in pagecache into highmem\"), the gfp flags of the page cache for symbolic links are overwritten to GFP_KERNEL via inode_nohighmem(). This is not a problem for symlinks read from the backing device, because the __GFP_FS flag is dropped after inode_nohighmem() is called. However, when a new symlink is created with nilfs_symlink(), the gfp flags remain overwritten to GFP_KERNEL. Then, memory allocation called from page_symlink() etc. triggers memory reclamation including the FS layer, which may call nilfs_evict_inode() or nilfs_dirty_inode(). And these can cause a deadlock if they are called while nilfs->ns_segctor_sem is held: Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags of newly created symlinks in the same way that nilfs_new_inode() and __nilfs_read_inode() do, as a workaround until we adopt nofs allocation scope consistently or improve the locking constraints.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50230", "url": "https://ubuntu.com/security/CVE-2024-50230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug due to missing clearing of checked flag Syzbot reported that in directory operations after nilfs2 detects filesystem corruption and degrades to read-only, __block_write_begin_int(), which is called to prepare block writes, may fail the BUG_ON check for accesses exceeding the folio/page size, triggering a kernel bug. This was found to be because the \"checked\" flag of a page/folio was not cleared when it was discarded by nilfs2's own routine, which causes the sanity check of directory entries to be skipped when the directory page/folio is reloaded. So, fix that. This was necessary when the use of nilfs2's own page discard routine was applied to more than just metadata files.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50231", "url": "https://ubuntu.com/security/CVE-2024-50231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gts-helper: Fix memory leaks in iio_gts_build_avail_scale_table() modprobe iio-test-gts and rmmod it, then the following memory leak occurs: \tunreferenced object 0xffffff80c810be00 (size 64): \t comm \"kunit_try_catch\", pid 1654, jiffies 4294913981 \t hex dump (first 32 bytes): \t 02 00 00 00 08 00 00 00 20 00 00 00 40 00 00 00 ........ ...@... \t 80 00 00 00 00 02 00 00 00 04 00 00 00 08 00 00 ................ \t backtrace (crc a63d875e): \t [<0000000028c1b3c2>] kmemleak_alloc+0x34/0x40 \t [<000000001d6ecc87>] __kmalloc_noprof+0x2bc/0x3c0 \t [<00000000393795c1>] devm_iio_init_iio_gts+0x4b4/0x16f4 \t [<0000000071bb4b09>] 0xffffffdf052a62e0 \t [<000000000315bc18>] 0xffffffdf052a6488 \t [<00000000f9dc55b5>] kunit_try_run_case+0x13c/0x3ac \t [<00000000175a3fd4>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000f505065d>] kthread+0x2e8/0x374 \t [<00000000bbfb0e5d>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cbfe9e70 (size 16): \t comm \"kunit_try_catch\", pid 1658, jiffies 4294914015 \t hex dump (first 16 bytes): \t 10 00 00 00 40 00 00 00 80 00 00 00 00 00 00 00 ....@........... \t backtrace (crc 857f0cb4): \t [<0000000028c1b3c2>] kmemleak_alloc+0x34/0x40 \t [<000000001d6ecc87>] __kmalloc_noprof+0x2bc/0x3c0 \t [<00000000393795c1>] devm_iio_init_iio_gts+0x4b4/0x16f4 \t [<0000000071bb4b09>] 0xffffffdf052a62e0 \t [<000000007d089d45>] 0xffffffdf052a6864 \t [<00000000f9dc55b5>] kunit_try_run_case+0x13c/0x3ac \t [<00000000175a3fd4>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000f505065d>] kthread+0x2e8/0x374 \t [<00000000bbfb0e5d>] ret_from_fork+0x10/0x20 \t...... It includes 5*5 times \"size 64\" memory leaks, which correspond to 5 times test_init_iio_gain_scale() calls with gts_test_gains size 10 (10*size(int)) and gts_test_itimes size 5. It also includes 5*1 times \"size 16\" memory leak, which correspond to one time __test_init_iio_gain_scale() call with gts_test_gains_gain_low size 3 (3*size(int)) and gts_test_itimes size 5. The reason is that the per_time_gains[i] is not freed which is allocated in the \"gts->num_itime\" for loop in iio_gts_build_avail_scale_table().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53076", "url": "https://ubuntu.com/security/CVE-2024-53076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gts-helper: Fix memory leaks for the error path of iio_gts_build_avail_scale_table() If per_time_scales[i] or per_time_gains[i] kcalloc fails in the for loop of iio_gts_build_avail_scale_table(), the err_free_out will fail to call kfree() each time when i is reduced to 0, so all the per_time_scales[0] and per_time_gains[0] will not be freed, which will cause memory leaks. Fix it by checking if i >= 0.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50232", "url": "https://ubuntu.com/security/CVE-2024-50232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr() In the ad7124_write_raw() function, parameter val can potentially be zero. This may lead to a division by zero when DIV_ROUND_CLOSEST() is called within ad7124_set_channel_odr(). The ad7124_write_raw() function is invoked through the sequence: iio_write_channel_raw() -> iio_write_channel_attribute() -> iio_channel_write(), with no checks in place to ensure val is non-zero.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50233", "url": "https://ubuntu.com/security/CVE-2024-50233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: iio: frequency: ad9832: fix division by zero in ad9832_calc_freqreg() In the ad9832_write_frequency() function, clk_get_rate() might return 0. This can lead to a division by zero when calling ad9832_calc_freqreg(). The check if (fout > (clk_get_rate(st->mclk) / 2)) does not protect against the case when fout is 0. The ad9832_write_frequency() function is called from ad9832_write(), and fout is derived from a text buffer, which can contain any value.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53055", "url": "https://ubuntu.com/security/CVE-2024-53055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix 6 GHz scan construction If more than 255 colocated APs exist for the set of all APs found during 2.4/5 GHz scanning, then the 6 GHz scan construction will loop forever since the loop variable has type u8, which can never reach the number found when that's bigger than 255, and is stored in a u32 variable. Also move it into the loops to have a smaller scope. Using a u32 there is fine, we limit the number of APs in the scan list and each has a limit on the number of RNR entries due to the frame size. With a limit of 1000 scan results, a frame size upper bound of 4096 (really it's more like ~2300) and a TBTT entry size of at least 11, we get an upper bound for the number of ~372k, well in the bounds of a u32.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50234", "url": "https://ubuntu.com/security/CVE-2024-50234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlegacy: Clear stale interrupts before resuming device iwl4965 fails upon resume from hibernation on my laptop. The reason seems to be a stale interrupt which isn't being cleared out before interrupts are enabled. We end up with a race beween the resume trying to bring things back up, and the restart work (queued form the interrupt handler) trying to bring things down. Eventually the whole thing blows up. Fix the problem by clearing out any stale interrupts before interrupts get enabled during resume. Here's a debug log of the indicent: [ 12.042589] ieee80211 phy0: il_isr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000 [ 12.042625] ieee80211 phy0: il4965_irq_tasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000 [ 12.042651] iwl4965 0000:10:00.0: RF_KILL bit toggled to enable radio. [ 12.042653] iwl4965 0000:10:00.0: On demand firmware reload [ 12.042690] ieee80211 phy0: il4965_irq_tasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282 [ 12.052207] ieee80211 phy0: il4965_mac_start enter [ 12.052212] ieee80211 phy0: il_prep_station Add STA to driver ID 31: ff:ff:ff:ff:ff:ff [ 12.052244] ieee80211 phy0: il4965_set_hw_ready hardware ready [ 12.052324] ieee80211 phy0: il_apm_init Init card's basic functions [ 12.052348] ieee80211 phy0: il_apm_init L1 Enabled; Disabling L0S [ 12.055727] ieee80211 phy0: il4965_load_bsm Begin load bsm [ 12.056140] ieee80211 phy0: il4965_verify_bsm Begin verify bsm [ 12.058642] ieee80211 phy0: il4965_verify_bsm BSM bootstrap uCode image OK [ 12.058721] ieee80211 phy0: il4965_load_bsm BSM write complete, poll 1 iterations [ 12.058734] ieee80211 phy0: __il4965_up iwl4965 is coming up [ 12.058737] ieee80211 phy0: il4965_mac_start Start UP work done. [ 12.058757] ieee80211 phy0: __il4965_down iwl4965 is going down [ 12.058761] ieee80211 phy0: il_scan_cancel_timeout Scan cancel timeout [ 12.058762] ieee80211 phy0: il_do_scan_abort Not performing scan to abort [ 12.058765] ieee80211 phy0: il_clear_ucode_stations Clearing ucode stations in driver [ 12.058767] ieee80211 phy0: il_clear_ucode_stations No active stations found to be cleared [ 12.058819] ieee80211 phy0: _il_apm_stop Stop card, put in low power state [ 12.058827] ieee80211 phy0: _il_apm_stop_master stop master [ 12.058864] ieee80211 phy0: il4965_clear_free_frames 0 frames on pre-allocated heap on clear. [ 12.058869] ieee80211 phy0: Hardware restart was requested [ 16.132299] iwl4965 0000:10:00.0: START_ALIVE timeout after 4000ms. [ 16.132303] ------------[ cut here ]------------ [ 16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue. [ 16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132390] Modules linked in: ctr ccm sch_fq_codel xt_tcpudp xt_multiport xt_state iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables binfmt_misc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdh_generic ecc iTCO_wdt i2c_dev iwl4965 iwlegacy coretemp snd_hda_codec_analog pcspkr psmouse mac80211 snd_hda_codec_generic libarc4 sdhci_pci cqhci sha256_generic sdhci libsha256 firewire_ohci snd_hda_intel snd_intel_dspcfg mmc_core snd_hda_codec snd_hwdep firewire_core led_class iosf_mbi snd_hda_core uhci_hcd lpc_ich crc_itu_t cfg80211 ehci_pci ehci_hcd snd_pcm usbcore mfd_core rfkill snd_timer snd usb_common soundcore video parport_pc parport intel_agp wmi intel_gtt backlight e1000e agpgart evdev [ 16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143 [ 16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010 [ 16.132463] Workqueue: async async_run_entry_fn [ 16.132469] RIP: 0010:ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132501] Code: da 02 00 0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50235", "url": "https://ubuntu.com/security/CVE-2024-50235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: clear wdev->cqm_config pointer on free When we free wdev->cqm_config when unregistering, we also need to clear out the pointer since the same wdev/netdev may get re-registered in another network namespace, then destroyed later, running this code again, which results in a double-free.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50236", "url": "https://ubuntu.com/security/CVE-2024-50236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: Fix memory leak in management tx In the current logic, memory is allocated for storing the MSDU context during management packet TX but this memory is not being freed during management TX completion. Similar leaks are seen in the management TX cleanup logic. Kmemleak reports this problem as below, unreferenced object 0xffffff80b64ed250 (size 16): comm \"kworker/u16:7\", pid 148, jiffies 4294687130 (age 714.199s) hex dump (first 16 bytes): 00 2b d8 d8 80 ff ff ff c4 74 e9 fd 07 00 00 00 .+.......t...... backtrace: [] __kmem_cache_alloc_node+0x1e4/0x2d8 [] kmalloc_trace+0x48/0x110 [] ath10k_wmi_tlv_op_gen_mgmt_tx_send+0xd4/0x1d8 [ath10k_core] [] ath10k_mgmt_over_wmi_tx_work+0x134/0x298 [ath10k_core] [] process_scheduled_works+0x1ac/0x400 [] worker_thread+0x208/0x328 [] kthread+0x100/0x1c0 [] ret_from_fork+0x10/0x20 Free the memory during completion and cleanup to fix the leak. Protect the mgmt_pending_tx idr_remove() operation in ath10k_wmi_tlv_op_cleanup_mgmt_tx_send() using ar->data_lock similar to other instances. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50237", "url": "https://ubuntu.com/security/CVE-2024-50237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower Avoid potentially crashing in the driver because of uninitialized private data", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50238", "url": "https://ubuntu.com/security/CVE-2024-50238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usbc: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data from the qcom-qmp-usb driver, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. This bug was later reproduced when the driver was copied to create the qmp-usbc driver. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with these drivers.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50239", "url": "https://ubuntu.com/security/CVE-2024-50239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usb-legacy: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data from the qcom-qmp-usb driver, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. This bug was later reproduced when the driver was copied to create the qmp-usb-legacy driver. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with these drivers.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50240", "url": "https://ubuntu.com/security/CVE-2024-50240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usb: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with this driver.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53077", "url": "https://ubuntu.com/security/CVE-2024-53077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpcrdma: Always release the rpcrdma_device's xa_array Dai pointed out that the xa_init_flags() in rpcrdma_add_one() needs to have a matching xa_destroy() in rpcrdma_remove_one() to release underlying memory that the xarray might have accrued during operation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50242", "url": "https://ubuntu.com/security/CVE-2024-50242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ntfs_file_release", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50243", "url": "https://ubuntu.com/security/CVE-2024-50243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix general protection fault in run_is_mapped_full Fixed deleating of a non-resident attribute in ntfs_create_inode() rollback.", "cve_priority": "low", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50244", "url": "https://ubuntu.com/security/CVE-2024-50244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ni_clear() Checking of NTFS_FLAGS_LOG_REPLAYING added to prevent access to uninitialized bitmap during replay process.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50245", "url": "https://ubuntu.com/security/CVE-2024-50245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix possible deadlock in mi_read Mutex lock with another subclass used in ni_lock_dir().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50246", "url": "https://ubuntu.com/security/CVE-2024-50246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Add rough attr alloc_size check", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50247", "url": "https://ubuntu.com/security/CVE-2024-50247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Check if more than chunk-size bytes are written A incorrectly formatted chunk may decompress into more than LZNT_CHUNK_SIZE bytes and a index out of bounds will occur in s_max_off.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50248", "url": "https://ubuntu.com/security/CVE-2024-50248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Add bounds checking to mi_enum_attr() Added bounds checking to make sure that every attr don't stray beyond valid memory region.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53078", "url": "https://ubuntu.com/security/CVE-2024-53078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Fix NULL vs IS_ERR() check in probe() The iommu_paging_domain_alloc() function doesn't return NULL pointers, it returns error pointers. Update the check to match.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53056", "url": "https://ubuntu.com/security/CVE-2024-53056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Fix potential NULL dereference in mtk_crtc_destroy() In mtk_crtc_create(), if the call to mbox_request_channel() fails then we set the \"mtk_crtc->cmdq_client.chan\" pointer to NULL. In that situation, we do not call cmdq_pkt_create(). During the cleanup, we need to check if the \"mtk_crtc->cmdq_client.chan\" is NULL first before calling cmdq_pkt_destroy(). Calling cmdq_pkt_destroy() is unnecessary if we didn't call cmdq_pkt_create() and it will result in a NULL pointer dereference.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50249", "url": "https://ubuntu.com/security/CVE-2024-50249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Make rmw_lock a raw_spin_lock The following BUG was triggered: ============================= [ BUG: Invalid wait context ] 6.12.0-rc2-XXX #406 Not tainted ----------------------------- kworker/1:1/62 is trying to lock: ffffff8801593030 (&cpc_ptr->rmw_lock){+.+.}-{3:3}, at: cpc_write+0xcc/0x370 other info that might help us debug this: context-{5:5} 2 locks held by kworker/1:1/62: #0: ffffff897ef5ec98 (&rq->__lock){-.-.}-{2:2}, at: raw_spin_rq_lock_nested+0x2c/0x50 #1: ffffff880154e238 (&sg_policy->update_lock){....}-{2:2}, at: sugov_update_shared+0x3c/0x280 stack backtrace: CPU: 1 UID: 0 PID: 62 Comm: kworker/1:1 Not tainted 6.12.0-rc2-g9654bd3e8806 #406 Workqueue: 0x0 (events) Call trace: dump_backtrace+0xa4/0x130 show_stack+0x20/0x38 dump_stack_lvl+0x90/0xd0 dump_stack+0x18/0x28 __lock_acquire+0x480/0x1ad8 lock_acquire+0x114/0x310 _raw_spin_lock+0x50/0x70 cpc_write+0xcc/0x370 cppc_set_perf+0xa0/0x3a8 cppc_cpufreq_fast_switch+0x40/0xc0 cpufreq_driver_fast_switch+0x4c/0x218 sugov_update_shared+0x234/0x280 update_load_avg+0x6ec/0x7b8 dequeue_entities+0x108/0x830 dequeue_task_fair+0x58/0x408 __schedule+0x4f0/0x1070 schedule+0x54/0x130 worker_thread+0xc0/0x2e8 kthread+0x130/0x148 ret_from_fork+0x10/0x20 sugov_update_shared() locks a raw_spinlock while cpc_write() locks a spinlock. To have a correct wait-type order, update rmw_lock to a raw spinlock and ensure that interrupts will be disabled on the CPU holding it. [ rjw: Changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50250", "url": "https://ubuntu.com/security/CVE-2024-50250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fsdax: dax_unshare_iter needs to copy entire blocks The code that copies data from srcmap to iomap in dax_unshare_iter is very very broken, which bfoster's recent fsx changes have exposed. If the pos and len passed to dax_file_unshare are not aligned to an fsblock boundary, the iter pos and length in the _iter function will reflect this unalignment. dax_iomap_direct_access always returns a pointer to the start of the kmapped fsdax page, even if its pos argument is in the middle of that page. This is catastrophic for data integrity when iter->pos is not aligned to a page, because daddr/saddr do not point to the same byte in the file as iter->pos. Hence we corrupt user data by copying it to the wrong place. If iter->pos + iomap_length() in the _iter function not aligned to a page, then we fail to copy a full block, and only partially populate the destination block. This is catastrophic for data confidentiality because we expose stale pmem contents. Fix both of these issues by aligning copy_pos/copy_len to a page boundary (remember, this is fsdax so 1 fsblock == 1 base page) so that we always copy full blocks. We're not done yet -- there's no call to invalidate_inode_pages2_range, so programs that have the file range mmap'd will continue accessing the old memory mapping after the file metadata updates have completed. Be careful with the return value -- if the unshare succeeds, we still need to return the number of bytes that the iomap iter thinks we're operating on.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50251", "url": "https://ubuntu.com/security/CVE-2024-50251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_payload: sanitize offset and length before calling skb_checksum() If access to offset + length is larger than the skbuff length, then skb_checksum() triggers BUG_ON(). skb_checksum() internally subtracts the length parameter while iterating over skbuff, BUG_ON(len) at the end of it checks that the expected length to be included in the checksum calculation is fully consumed.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50252", "url": "https://ubuntu.com/security/CVE-2024-50252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_ipip: Fix memory leak when changing remote IPv6 address The device stores IPv6 addresses that are used for encapsulation in linear memory that is managed by the driver. Changing the remote address of an ip6gre net device never worked properly, but since cited commit the following reproducer [1] would result in a warning [2] and a memory leak [3]. The problem is that the new remote address is never added by the driver to its hash table (and therefore the device) and the old address is never removed from it. Fix by programming the new address when the configuration of the ip6gre net device changes and removing the old one. If the address did not change, then the above would result in increasing the reference count of the address and then decreasing it. [1] # ip link add name bla up type ip6gre local 2001:db8:1::1 remote 2001:db8:2::1 tos inherit ttl inherit # ip link set dev bla type ip6gre remote 2001:db8:3::1 # ip link del dev bla # devlink dev reload pci/0000:01:00.0 [2] WARNING: CPU: 0 PID: 1682 at drivers/net/ethernet/mellanox/mlxsw/spectrum.c:3002 mlxsw_sp_ipv6_addr_put+0x140/0x1d0 Modules linked in: CPU: 0 UID: 0 PID: 1682 Comm: ip Not tainted 6.12.0-rc3-custom-g86b5b55bc835 #151 Hardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023 RIP: 0010:mlxsw_sp_ipv6_addr_put+0x140/0x1d0 [...] Call Trace: mlxsw_sp_router_netdevice_event+0x55f/0x1240 notifier_call_chain+0x5a/0xd0 call_netdevice_notifiers_info+0x39/0x90 unregister_netdevice_many_notify+0x63e/0x9d0 rtnl_dellink+0x16b/0x3a0 rtnetlink_rcv_msg+0x142/0x3f0 netlink_rcv_skb+0x50/0x100 netlink_unicast+0x242/0x390 netlink_sendmsg+0x1de/0x420 ____sys_sendmsg+0x2bd/0x320 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xd0 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f [3] unreferenced object 0xffff898081f597a0 (size 32): comm \"ip\", pid 1626, jiffies 4294719324 hex dump (first 32 bytes): 20 01 0d b8 00 02 00 00 00 00 00 00 00 00 00 01 ............... 21 49 61 83 80 89 ff ff 00 00 00 00 01 00 00 00 !Ia............. backtrace (crc fd9be911): [<00000000df89c55d>] __kmalloc_cache_noprof+0x1da/0x260 [<00000000ff2a1ddb>] mlxsw_sp_ipv6_addr_kvdl_index_get+0x281/0x340 [<000000009ddd445d>] mlxsw_sp_router_netdevice_event+0x47b/0x1240 [<00000000743e7757>] notifier_call_chain+0x5a/0xd0 [<000000007c7b9e13>] call_netdevice_notifiers_info+0x39/0x90 [<000000002509645d>] register_netdevice+0x5f7/0x7a0 [<00000000c2e7d2a9>] ip6gre_newlink_common.isra.0+0x65/0x130 [<0000000087cd6d8d>] ip6gre_newlink+0x72/0x120 [<000000004df7c7cc>] rtnl_newlink+0x471/0xa20 [<0000000057ed632a>] rtnetlink_rcv_msg+0x142/0x3f0 [<0000000032e0d5b5>] netlink_rcv_skb+0x50/0x100 [<00000000908bca63>] netlink_unicast+0x242/0x390 [<00000000cdbe1c87>] netlink_sendmsg+0x1de/0x420 [<0000000011db153e>] ____sys_sendmsg+0x2bd/0x320 [<000000003b6d53eb>] ___sys_sendmsg+0x9a/0xe0 [<00000000cae27c62>] __sys_sendmsg+0x7a/0xd0", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50253", "url": "https://ubuntu.com/security/CVE-2024-50253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check the validity of nr_words in bpf_iter_bits_new() Check the validity of nr_words in bpf_iter_bits_new(). Without this check, when multiplication overflow occurs for nr_bits (e.g., when nr_words = 0x0400-0001, nr_bits becomes 64), stack corruption may occur due to bpf_probe_read_kernel_common(..., nr_bytes = 0x2000-0008). Fix it by limiting the maximum value of nr_words to 511. The value is derived from the current implementation of BPF memory allocator. To ensure compatibility if the BPF memory allocator's size limitation changes in the future, use the helper bpf_mem_alloc_check_size() to check whether nr_bytes is too larger. And return -E2BIG instead of -ENOMEM for oversized nr_bytes.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50254", "url": "https://ubuntu.com/security/CVE-2024-50254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free dynamically allocated bits in bpf_iter_bits_destroy() bpf_iter_bits_destroy() uses \"kit->nr_bits <= 64\" to check whether the bits are dynamically allocated. However, the check is incorrect and may cause a kmemleak as shown below: unreferenced object 0xffff88812628c8c0 (size 32): comm \"swapper/0\", pid 1, jiffies 4294727320 hex dump (first 32 bytes): \tb0 c1 55 f5 81 88 ff ff f0 f0 f0 f0 f0 f0 f0 f0 ..U........... \tf0 f0 f0 f0 f0 f0 f0 f0 00 00 00 00 00 00 00 00 .............. backtrace (crc 781e32cc): \t[<00000000c452b4ab>] kmemleak_alloc+0x4b/0x80 \t[<0000000004e09f80>] __kmalloc_node_noprof+0x480/0x5c0 \t[<00000000597124d6>] __alloc.isra.0+0x89/0xb0 \t[<000000004ebfffcd>] alloc_bulk+0x2af/0x720 \t[<00000000d9c10145>] prefill_mem_cache+0x7f/0xb0 \t[<00000000ff9738ff>] bpf_mem_alloc_init+0x3e2/0x610 \t[<000000008b616eac>] bpf_global_ma_init+0x19/0x30 \t[<00000000fc473efc>] do_one_initcall+0xd3/0x3c0 \t[<00000000ec81498c>] kernel_init_freeable+0x66a/0x940 \t[<00000000b119f72f>] kernel_init+0x20/0x160 \t[<00000000f11ac9a7>] ret_from_fork+0x3c/0x70 \t[<0000000004671da4>] ret_from_fork_asm+0x1a/0x30 That is because nr_bits will be set as zero in bpf_iter_bits_next() after all bits have been iterated. Fix the issue by setting kit->bit to kit->nr_bits instead of setting kit->nr_bits to zero when the iteration completes in bpf_iter_bits_next(). In addition, use \"!nr_bits || bits >= nr_bits\" to check whether the iteration is complete and still use \"nr_bits > 64\" to indicate whether bits are dynamically allocated. The \"!nr_bits\" check is necessary because bpf_iter_bits_new() may fail before setting kit->nr_bits, and this condition will stop the iteration early instead of accessing the zeroed or freed kit->bits. Considering the initial value of kit->bits is -1 and the type of kit->nr_bits is unsigned int, change the type of kit->nr_bits to int. The potential overflow problem will be handled in the following patch.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50255", "url": "https://ubuntu.com/security/CVE-2024-50255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci: fix null-ptr-deref in hci_read_supported_codecs Fix __hci_cmd_sync_sk() to return not NULL for unknown opcodes. __hci_cmd_sync_sk() returns NULL if a command returns a status event. However, it also returns NULL where an opcode doesn't exist in the hci_cc table because hci_cmd_complete_evt() assumes status = skb->data[0] for unknown opcodes. This leads to null-ptr-deref in cmd_sync for HCI_OP_READ_LOCAL_CODECS as there is no hci_cc for HCI_OP_READ_LOCAL_CODECS, which always assumes status = skb->data[0]. KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077] CPU: 1 PID: 2000 Comm: kworker/u9:5 Not tainted 6.9.0-ga6bcb805883c-dirty #10 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: hci7 hci_power_on RIP: 0010:hci_read_supported_codecs+0xb9/0x870 net/bluetooth/hci_codec.c:138 Code: 08 48 89 ef e8 b8 c1 8f fd 48 8b 75 00 e9 96 00 00 00 49 89 c6 48 ba 00 00 00 00 00 fc ff df 4c 8d 60 70 4c 89 e3 48 c1 eb 03 <0f> b6 04 13 84 c0 0f 85 82 06 00 00 41 83 3c 24 02 77 0a e8 bf 78 RSP: 0018:ffff888120bafac8 EFLAGS: 00010212 RAX: 0000000000000000 RBX: 000000000000000e RCX: ffff8881173f0040 RDX: dffffc0000000000 RSI: ffffffffa58496c0 RDI: ffff88810b9ad1e4 RBP: ffff88810b9ac000 R08: ffffffffa77882a7 R09: 1ffffffff4ef1054 R10: dffffc0000000000 R11: fffffbfff4ef1055 R12: 0000000000000070 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88810b9ac000 FS: 0000000000000000(0000) GS:ffff8881f6c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6ddaa3439e CR3: 0000000139764003 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: hci_read_local_codecs_sync net/bluetooth/hci_sync.c:4546 [inline] hci_init_stage_sync net/bluetooth/hci_sync.c:3441 [inline] hci_init4_sync net/bluetooth/hci_sync.c:4706 [inline] hci_init_sync net/bluetooth/hci_sync.c:4742 [inline] hci_dev_init_sync net/bluetooth/hci_sync.c:4912 [inline] hci_dev_open_sync+0x19a9/0x2d30 net/bluetooth/hci_sync.c:4994 hci_dev_do_open net/bluetooth/hci_core.c:483 [inline] hci_power_on+0x11e/0x560 net/bluetooth/hci_core.c:1015 process_one_work kernel/workqueue.c:3267 [inline] process_scheduled_works+0x8ef/0x14f0 kernel/workqueue.c:3348 worker_thread+0x91f/0xe50 kernel/workqueue.c:3429 kthread+0x2cb/0x360 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50256", "url": "https://ubuntu.com/security/CVE-2024-50256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6() I got a syzbot report without a repro [1] crashing in nf_send_reset6() I think the issue is that dev->hard_header_len is zero, and we attempt later to push an Ethernet header. Use LL_MAX_HEADER, as other functions in net/ipv6/netfilter/nf_reject_ipv6.c. [1] skbuff: skb_under_panic: text:ffffffff89b1d008 len:74 put:14 head:ffff88803123aa00 data:ffff88803123a9f2 tail:0x3c end:0x140 dev:syz_tun kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 UID: 0 PID: 7373 Comm: syz.1.568 Not tainted 6.12.0-rc2-syzkaller-00631-g6d858708d465 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:skb_panic net/core/skbuff.c:206 [inline] RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216 Code: 0d 8d 48 c7 c6 60 a6 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 ba 30 38 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP: 0018:ffffc900045269b0 EFLAGS: 00010282 RAX: 0000000000000088 RBX: dffffc0000000000 RCX: cd66dacdc5d8e800 RDX: 0000000000000000 RSI: 0000000000000200 RDI: 0000000000000000 RBP: ffff88802d39a3d0 R08: ffffffff8174afec R09: 1ffff920008a4ccc R10: dffffc0000000000 R11: fffff520008a4ccd R12: 0000000000000140 R13: ffff88803123aa00 R14: ffff88803123a9f2 R15: 000000000000003c FS: 00007fdbee5ff6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000005d322000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: skb_push+0xe5/0x100 net/core/skbuff.c:2636 eth_header+0x38/0x1f0 net/ethernet/eth.c:83 dev_hard_header include/linux/netdevice.h:3208 [inline] nf_send_reset6+0xce6/0x1270 net/ipv6/netfilter/nf_reject_ipv6.c:358 nft_reject_inet_eval+0x3b9/0x690 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x418/0x6b0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] br_nf_pre_routing_ipv6+0x63e/0x770 net/bridge/br_netfilter_ipv6.c:184 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_bridge_pre net/bridge/br_input.c:277 [inline] br_handle_frame+0x9fd/0x1530 net/bridge/br_input.c:424 __netif_receive_skb_core+0x13e8/0x4570 net/core/dev.c:5562 __netif_receive_skb_one_core net/core/dev.c:5666 [inline] __netif_receive_skb+0x12f/0x650 net/core/dev.c:5781 netif_receive_skb_internal net/core/dev.c:5867 [inline] netif_receive_skb+0x1e8/0x890 net/core/dev.c:5926 tun_rx_batched+0x1b7/0x8f0 drivers/net/tun.c:1550 tun_get_user+0x3056/0x47e0 drivers/net/tun.c:2007 tun_chr_write_iter+0x10d/0x1f0 drivers/net/tun.c:2053 new_sync_write fs/read_write.c:590 [inline] vfs_write+0xa6d/0xc90 fs/read_write.c:683 ksys_write+0x183/0x2b0 fs/read_write.c:736 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:0x7fdbeeb7d1ff Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 c9 8d 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 1c 8e 02 00 48 RSP: 002b:00007fdbee5ff000 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fdbeed36058 RCX: 00007fdbeeb7d1ff RDX: 000000000000008e RSI: 0000000020000040 RDI: 00000000000000c8 RBP: 00007fdbeebf12be R08: 0000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50257", "url": "https://ubuntu.com/security/CVE-2024-50257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: Fix use-after-free in get_info() ip6table_nat module unload has refcnt warning for UAF. call trace is: WARNING: CPU: 1 PID: 379 at kernel/module/main.c:853 module_put+0x6f/0x80 Modules linked in: ip6table_nat(-) CPU: 1 UID: 0 PID: 379 Comm: ip6tables Not tainted 6.12.0-rc4-00047-gc2ee9f594da8-dirty #205 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:module_put+0x6f/0x80 Call Trace: get_info+0x128/0x180 do_ip6t_get_ctl+0x6a/0x430 nf_getsockopt+0x46/0x80 ipv6_getsockopt+0xb9/0x100 rawv6_getsockopt+0x42/0x190 do_sock_getsockopt+0xaa/0x180 __sys_getsockopt+0x70/0xc0 __x64_sys_getsockopt+0x20/0x30 do_syscall_64+0xa2/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Concurrent execution of module unload and get_info() trigered the warning. The root cause is as follows: cpu0\t\t\t\t cpu1 module_exit //mod->state = MODULE_STATE_GOING ip6table_nat_exit xt_unregister_template \tkfree(t) \t//removed from templ_list \t\t\t\t getinfo() \t\t\t\t\t t = xt_find_table_lock \t\t\t\t\t\tlist_for_each_entry(tmpl, &xt_templates[af]...) \t\t\t\t\t\t\tif (strcmp(tmpl->name, name)) \t\t\t\t\t\t\t\tcontinue; //table not found \t\t\t\t\t\t\ttry_module_get \t\t\t\t\t\tlist_for_each_entry(t, &xt_net->tables[af]...) \t\t\t\t\t\t\treturn t; //not get refcnt \t\t\t\t\t module_put(t->me) //uaf unregister_pernet_subsys //remove table from xt_net list While xt_table module was going away and has been removed from xt_templates list, we couldnt get refcnt of xt_table->me. Check module in xt_net->tables list re-traversal to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50258", "url": "https://ubuntu.com/security/CVE-2024-50258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix crash when config small gso_max_size/gso_ipv4_max_size Config a small gso_max_size/gso_ipv4_max_size will lead to an underflow in sk_dst_gso_max_size(), which may trigger a BUG_ON crash, because sk->sk_gso_max_size would be much bigger than device limits. Call Trace: tcp_write_xmit tso_segs = tcp_init_tso_segs(skb, mss_now); tcp_set_skb_tso_segs tcp_skb_pcount_set // skb->len = 524288, mss_now = 8 // u16 tso_segs = 524288/8 = 65535 -> 0 tso_segs = DIV_ROUND_UP(skb->len, mss_now) BUG_ON(!tso_segs) Add check for the minimum value of gso_max_size and gso_ipv4_max_size.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50262", "url": "https://ubuntu.com/security/CVE-2024-50262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix out-of-bounds write in trie_get_next_key() trie_get_next_key() allocates a node stack with size trie->max_prefixlen, while it writes (trie->max_prefixlen + 1) nodes to the stack when it has full paths from the root to leaves. For example, consider a trie with max_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ... 0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with .prefixlen = 8 make 9 nodes be written on the node stack with size 8.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53044", "url": "https://ubuntu.com/security/CVE-2024-53044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_api: fix xa_insert() error path in tcf_block_get_ext() This command: $ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact Error: block dev insert failed: -EBUSY. fails because user space requests the same block index to be set for both ingress and egress. [ side note, I don't think it even failed prior to commit 913b47d3424e (\"net/sched: Introduce tc block netdev tracking infra\"), because this is a command from an old set of notes of mine which used to work, but alas, I did not scientifically bisect this ] The problem is not that it fails, but rather, that the second time around, it fails differently (and irrecoverably): $ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact Error: dsa_core: Flow block cb is busy. [ another note: the extack is added by me for illustration purposes. the context of the problem is that clsact_init() obtains the same &q->ingress_block pointer as &q->egress_block, and since we call tcf_block_get_ext() on both of them, \"dev\" will be added to the block->ports xarray twice, thus failing the operation: once through the ingress block pointer, and once again through the egress block pointer. the problem itself is that when xa_insert() fails, we have emitted a FLOW_BLOCK_BIND command through ndo_setup_tc(), but the offload never sees a corresponding FLOW_BLOCK_UNBIND. ] Even correcting the bad user input, we still cannot recover: $ tc qdisc replace dev swp3 ingress_block 1 egress_block 2 clsact Error: dsa_core: Flow block cb is busy. Basically the only way to recover is to reboot the system, or unbind and rebind the net device driver. To fix the bug, we need to fill the correct error teardown path which was missed during code movement, and call tcf_block_offload_unbind() when xa_insert() fails. [ last note, fundamentally I blame the label naming convention in tcf_block_get_ext() for the bug. The labels should be named after what they do, not after the error path that jumps to them. This way, it is obviously wrong that two labels pointing to the same code mean something is wrong, and checking the code correctness at the goto site is also easier ]", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50259", "url": "https://ubuntu.com/security/CVE-2024-50259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netdevsim: Add trailing zero to terminate the string in nsim_nexthop_bucket_activity_write() This was found by a static analyzer. We should not forget the trailing zero after copy_from_user() if we will further do some string operations, sscanf() in this case. Adding a trailing zero will ensure that the function performs properly.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50304", "url": "https://ubuntu.com/security/CVE-2024-50304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find() The per-netns IP tunnel hash table is protected by the RTNL mutex and ip_tunnel_find() is only called from the control path where the mutex is taken. Add a lockdep expression to hlist_for_each_entry_rcu() in ip_tunnel_find() in order to validate that the mutex is held and to silence the suspicious RCU usage warning [1]. [1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gd95d9a31aceb #139 Not tainted ----------------------------- net/ipv4/ip_tunnel.c:221 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/362: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60 stack backtrace: CPU: 12 UID: 0 PID: 362 Comm: ip Not tainted 6.12.0-rc3-custom-gd95d9a31aceb #139 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 ip_tunnel_find+0x435/0x4d0 ip_tunnel_newlink+0x517/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53042", "url": "https://ubuntu.com/security/CVE-2024-53042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_init_flow() There are code paths from which the function is called without holding the RCU read lock, resulting in a suspicious RCU usage warning [1]. Fix by using l3mdev_master_upper_ifindex_by_index() which will acquire the RCU read lock before calling l3mdev_master_upper_ifindex_by_index_rcu(). [1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gac8f72681cf2 #141 Not tainted ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/361: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60 stack backtrace: CPU: 3 UID: 0 PID: 361 Comm: ip Not tainted 6.12.0-rc3-custom-gac8f72681cf2 #141 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 dev_get_by_index_rcu+0x1d3/0x210 l3mdev_master_upper_ifindex_by_index_rcu+0x2b/0xf0 ip_tunnel_bind_dev+0x72f/0xa00 ip_tunnel_newlink+0x368/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53048", "url": "https://ubuntu.com/security/CVE-2024-53048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix crash on probe for DPLL enabled E810 LOM The E810 Lan On Motherboard (LOM) design is vendor specific. Intel provides the reference design, but it is up to vendor on the final product design. For some cases, like Linux DPLL support, the static values defined in the driver does not reflect the actual LOM design. Current implementation of dpll pins is causing the crash on probe of the ice driver for such DPLL enabled E810 LOM designs: WARNING: (...) at drivers/dpll/dpll_core.c:495 dpll_pin_get+0x2c4/0x330 ... Call Trace: ? __warn+0x83/0x130 ? dpll_pin_get+0x2c4/0x330 ? report_bug+0x1b7/0x1d0 ? handle_bug+0x42/0x70 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? dpll_pin_get+0x117/0x330 ? dpll_pin_get+0x2c4/0x330 ? dpll_pin_get+0x117/0x330 ice_dpll_get_pins.isra.0+0x52/0xe0 [ice] ... The number of dpll pins enabled by LOM vendor is greater than expected and defined in the driver for Intel designed NICs, which causes the crash. Prevent the crash and allow generic pin initialization within Linux DPLL subsystem for DPLL enabled E810 LOM designs. Newly designed solution for described issue will be based on \"per HW design\" pin initialization. It requires pin information dynamically acquired from the firmware and is already in progress, planned for next-tree only.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53058", "url": "https://ubuntu.com/security/CVE-2024-53058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data In case the non-paged data of a SKB carries protocol header and protocol payload to be transmitted on a certain platform that the DMA AXI address width is configured to 40-bit/48-bit, or the size of the non-paged data is bigger than TSO_MAX_BUFF_SIZE on a certain platform that the DMA AXI address width is configured to 32-bit, then this SKB requires at least two DMA transmit descriptors to serve it. For example, three descriptors are allocated to split one DMA buffer mapped from one piece of non-paged data: dma_desc[N + 0], dma_desc[N + 1], dma_desc[N + 2]. Then three elements of tx_q->tx_skbuff_dma[] will be allocated to hold extra information to be reused in stmmac_tx_clean(): tx_q->tx_skbuff_dma[N + 0], tx_q->tx_skbuff_dma[N + 1], tx_q->tx_skbuff_dma[N + 2]. Now we focus on tx_q->tx_skbuff_dma[entry].buf, which is the DMA buffer address returned by DMA mapping call. stmmac_tx_clean() will try to unmap the DMA buffer _ONLY_IF_ tx_q->tx_skbuff_dma[entry].buf is a valid buffer address. The expected behavior that saves DMA buffer address of this non-paged data to tx_q->tx_skbuff_dma[entry].buf is: tx_q->tx_skbuff_dma[N + 0].buf = NULL; tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = dma_map_single(); Unfortunately, the current code misbehaves like this: tx_q->tx_skbuff_dma[N + 0].buf = dma_map_single(); tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = NULL; On the stmmac_tx_clean() side, when dma_desc[N + 0] is closed by the DMA engine, tx_q->tx_skbuff_dma[N + 0].buf is a valid buffer address obviously, then the DMA buffer will be unmapped immediately. There may be a rare case that the DMA engine does not finish the pending dma_desc[N + 1], dma_desc[N + 2] yet. Now things will go horribly wrong, DMA is going to access a unmapped/unreferenced memory region, corrupted data will be transmited or iommu fault will be triggered :( In contrast, the for-loop that maps SKB fragments behaves perfectly as expected, and that is how the driver should do for both non-paged data and paged frags actually. This patch corrects DMA map/unmap sequences by fixing the array index for tx_q->tx_skbuff_dma[entry].buf when assigning DMA buffer address. Tested and verified on DWXGMAC CORE 3.20a", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50260", "url": "https://ubuntu.com/security/CVE-2024-50260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sock_map: fix a NULL pointer dereference in sock_map_link_update_prog() The following race condition could trigger a NULL pointer dereference: sock_map_link_detach():\t\tsock_map_link_update_prog(): mutex_lock(&sockmap_mutex); ... sockmap_link->map = NULL; mutex_unlock(&sockmap_mutex); \t\t\t\t mutex_lock(&sockmap_mutex); \t\t\t\t ... \t\t\t\t sock_map_prog_link_lookup(sockmap_link->map); \t\t\t\t mutex_unlock(&sockmap_mutex); Fix it by adding a NULL pointer check. In this specific case, it makes no sense to update a link which is being released.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53045", "url": "https://ubuntu.com/security/CVE-2024-53045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: dapm: fix bounds checker error in dapm_widget_list_create The widgets array in the snd_soc_dapm_widget_list has a __counted_by attribute attached to it, which points to the num_widgets variable. This attribute is used in bounds checking, and if it is not set before the array is filled, then the bounds sanitizer will issue a warning or a kernel panic if CONFIG_UBSAN_TRAP is set. This patch sets the size of the widgets list calculated with list_for_each as the initial value for num_widgets as it is used for allocating memory for the array. It is updated with the actual number of added elements after the array is filled.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50261", "url": "https://ubuntu.com/security/CVE-2024-50261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macsec: Fix use-after-free while sending the offloading packet KASAN reports the following UAF. The metadata_dst, which is used to store the SCI value for macsec offload, is already freed by metadata_dst_free() in macsec_free_netdev(), while driver still use it for sending the packet. To fix this issue, dst_release() is used instead to release metadata_dst. So it is not freed instantly in macsec_free_netdev() if still referenced by skb. BUG: KASAN: slab-use-after-free in mlx5e_xmit+0x1e8f/0x4190 [mlx5_core] Read of size 2 at addr ffff88813e42e038 by task kworker/7:2/714 [...] Workqueue: mld mld_ifc_work Call Trace: dump_stack_lvl+0x51/0x60 print_report+0xc1/0x600 kasan_report+0xab/0xe0 mlx5e_xmit+0x1e8f/0x4190 [mlx5_core] dev_hard_start_xmit+0x120/0x530 sch_direct_xmit+0x149/0x11e0 __qdisc_run+0x3ad/0x1730 __dev_queue_xmit+0x1196/0x2ed0 vlan_dev_hard_start_xmit+0x32e/0x510 [8021q] dev_hard_start_xmit+0x120/0x530 __dev_queue_xmit+0x14a7/0x2ed0 macsec_start_xmit+0x13e9/0x2340 dev_hard_start_xmit+0x120/0x530 __dev_queue_xmit+0x14a7/0x2ed0 ip6_finish_output2+0x923/0x1a70 ip6_finish_output+0x2d7/0x970 ip6_output+0x1ce/0x3a0 NF_HOOK.constprop.0+0x15f/0x190 mld_sendpack+0x59a/0xbd0 mld_ifc_work+0x48a/0xa80 process_one_work+0x5aa/0xe50 worker_thread+0x79c/0x1290 kthread+0x28f/0x350 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x11/0x20 Allocated by task 3922: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 __kasan_kmalloc+0x77/0x90 __kmalloc_noprof+0x188/0x400 metadata_dst_alloc+0x1f/0x4e0 macsec_newlink+0x914/0x1410 __rtnl_newlink+0xe08/0x15b0 rtnl_newlink+0x5f/0x90 rtnetlink_rcv_msg+0x667/0xa80 netlink_rcv_skb+0x12c/0x360 netlink_unicast+0x551/0x770 netlink_sendmsg+0x72d/0xbd0 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x52e/0x6a0 ___sys_sendmsg+0xeb/0x170 __sys_sendmsg+0xb5/0x140 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Freed by task 4011: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x50 poison_slab_object+0x10c/0x190 __kasan_slab_free+0x11/0x30 kfree+0xe0/0x290 macsec_free_netdev+0x3f/0x140 netdev_run_todo+0x450/0xc70 rtnetlink_rcv_msg+0x66f/0xa80 netlink_rcv_skb+0x12c/0x360 netlink_unicast+0x551/0x770 netlink_sendmsg+0x72d/0xbd0 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x52e/0x6a0 ___sys_sendmsg+0xeb/0x170 __sys_sendmsg+0xb5/0x140 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53059", "url": "https://ubuntu.com/security/CVE-2024-53059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd() 1. The size of the response packet is not validated. 2. The response buffer is not freed. Resolve these issues by switching to iwl_mvm_send_cmd_status(), which handles both size validation and frees the buffer.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53074", "url": "https://ubuntu.com/security/CVE-2024-53074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: don't leak a link on AP removal Release the link mapping resource in AP removal. This impacted devices that do not support the MLD API (9260 and down). On those devices, we couldn't start the AP again after the AP has been already started and stopped.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53049", "url": "https://ubuntu.com/security/CVE-2024-53049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slub/kunit: fix a WARNING due to unwrapped __kmalloc_cache_noprof 'modprobe slub_kunit' will have a warning as shown below. The root cause is that __kmalloc_cache_noprof was directly used, which resulted in no alloc_tag being allocated. This caused current->alloc_tag to be null, leading to a warning in alloc_tag_add_check. Let's add an alloc_hook layer to __kmalloc_cache_noprof specifically within lib/slub_kunit.c, which is the only user of this internal slub function outside kmalloc implementation itself. [58162.947016] WARNING: CPU: 2 PID: 6210 at ./include/linux/alloc_tag.h:125 alloc_tagging_slab_alloc_hook+0x268/0x27c [58162.957721] Call trace: [58162.957919] alloc_tagging_slab_alloc_hook+0x268/0x27c [58162.958286] __kmalloc_cache_noprof+0x14c/0x344 [58162.958615] test_kmalloc_redzone_access+0x50/0x10c [slub_kunit] [58162.959045] kunit_try_run_case+0x74/0x184 [kunit] [58162.959401] kunit_generic_run_threadfn_adapter+0x2c/0x4c [kunit] [58162.959841] kthread+0x10c/0x118 [58162.960093] ret_from_fork+0x10/0x20 [58162.960363] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50192", "url": "https://ubuntu.com/security/CVE-2024-50192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v4: Don't allow a VMOVP on a dying VPE Kunkun Jiang reported that there is a small window of opportunity for userspace to force a change of affinity for a VPE while the VPE has already been unmapped, but the corresponding doorbell interrupt still visible in /proc/irq/. Plug the race by checking the value of vmapp_count, which tracks whether the VPE is mapped ot not, and returning an error in this case. This involves making vmapp_count common to both GICv4.1 and its v4.0 ancestor.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50069", "url": "https://ubuntu.com/security/CVE-2024-50069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: apple: check devm_kasprintf() returned value devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked. Fix this lack and check the returned value. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50070", "url": "https://ubuntu.com/security/CVE-2024-50070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: stm32: check devm_kasprintf() returned value devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked. Fix this lack and check the returned value. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50196", "url": "https://ubuntu.com/security/CVE-2024-50196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: ocelot: fix system hang on level based interrupts The current implementation only calls chained_irq_enter() and chained_irq_exit() if it detects pending interrupts. ``` for (i = 0; i < info->stride; i++) { \turegmap_read(info->map, id_reg + 4 * i, ®); \tif (!reg) \t\tcontinue; \tchained_irq_enter(parent_chip, desc); ``` However, in case of GPIO pin configured in level mode and the parent controller configured in edge mode, GPIO interrupt might be lowered by the hardware. In the result, if the interrupt is short enough, the parent interrupt is still pending while the GPIO interrupt is cleared; chained_irq_enter() never gets called and the system hangs trying to service the parent interrupt. Moving chained_irq_enter() and chained_irq_exit() outside the for loop ensures that they are called even when GPIO interrupt is lowered by the hardware. The similar code with chained_irq_enter() / chained_irq_exit() functions wrapping interrupt checking loop may be found in many other drivers: ``` grep -r -A 10 chained_irq_enter drivers/pinctrl ```", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50197", "url": "https://ubuntu.com/security/CVE-2024-50197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: intel: platform: fix error path in device_for_each_child_node() The device_for_each_child_node() loop requires calls to fwnode_handle_put() upon early returns to decrement the refcount of the child node and avoid leaking memory if that error path is triggered. There is one early returns within that loop in intel_platform_pinctrl_prepare_community(), but fwnode_handle_put() is missing. Instead of adding the missing call, the scoped version of the loop can be used to simplify the code and avoid mistakes in the future if new early returns are added, as the child node is only used for parsing, and it is never assigned.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50071", "url": "https://ubuntu.com/security/CVE-2024-50071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: nuvoton: fix a double free in ma35_pinctrl_dt_node_to_map_func() 'new_map' is allocated using devm_* which takes care of freeing the allocated data on device removal, call to \t.dt_free_map = pinconf_generic_dt_free_map double frees the map as pinconf_generic_dt_free_map() calls pinctrl_utils_free_map(). Fix this by using kcalloc() instead of auto-managed devm_kcalloc().", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50072", "url": "https://ubuntu.com/security/CVE-2024-50072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/bugs: Use code segment selector for VERW operand Robert Gill reported below #GP in 32-bit mode when dosemu software was executing vm86() system call: general protection fault: 0000 [#1] PREEMPT SMP CPU: 4 PID: 4610 Comm: dosemu.bin Not tainted 6.6.21-gentoo-x86 #1 Hardware name: Dell Inc. PowerEdge 1950/0H723K, BIOS 2.7.0 10/30/2010 EIP: restore_all_switch_stack+0xbe/0xcf EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000 ESI: 00000000 EDI: 00000000 EBP: 00000000 ESP: ff8affdc DS: 0000 ES: 0000 FS: 0000 GS: 0033 SS: 0068 EFLAGS: 00010046 CR0: 80050033 CR2: 00c2101c CR3: 04b6d000 CR4: 000406d0 Call Trace: show_regs+0x70/0x78 die_addr+0x29/0x70 exc_general_protection+0x13c/0x348 exc_bounds+0x98/0x98 handle_exception+0x14d/0x14d exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf This only happens in 32-bit mode when VERW based mitigations like MDS/RFDS are enabled. This is because segment registers with an arbitrary user value can result in #GP when executing VERW. Intel SDM vol. 2C documents the following behavior for VERW instruction: #GP(0) - If a memory operand effective address is outside the CS, DS, ES, \t FS, or GS segment limit. CLEAR_CPU_BUFFERS macro executes VERW instruction before returning to user space. Use %cs selector to reference VERW operand. This ensures VERW will not #GP for an arbitrary user %ds. [ mingo: Fixed the SOB chain. ]", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50073", "url": "https://ubuntu.com/security/CVE-2024-50073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: Fix use-after-free in gsm_cleanup_mux BUG: KASAN: slab-use-after-free in gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] Read of size 8 at addr ffff88815fe99c00 by task poc/3379 CPU: 0 UID: 0 PID: 3379 Comm: poc Not tainted 6.11.0+ #56 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] __pfx_gsm_cleanup_mux+0x10/0x10 drivers/tty/n_gsm.c:3124 [n_gsm] __pfx_sched_clock_cpu+0x10/0x10 kernel/sched/clock.c:389 update_load_avg+0x1c1/0x27b0 kernel/sched/fair.c:4500 __pfx_min_vruntime_cb_rotate+0x10/0x10 kernel/sched/fair.c:846 __rb_insert_augmented+0x492/0xbf0 lib/rbtree.c:161 gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] _raw_spin_lock_irqsave+0x92/0xf0 arch/x86/include/asm/atomic.h:107 __pfx_gsmld_ioctl+0x10/0x10 drivers/tty/n_gsm.c:3822 [n_gsm] ktime_get+0x5e/0x140 kernel/time/timekeeping.c:195 ldsem_down_read+0x94/0x4e0 arch/x86/include/asm/atomic64_64.h:79 __pfx_ldsem_down_read+0x10/0x10 drivers/tty/tty_ldsem.c:338 __pfx_do_vfs_ioctl+0x10/0x10 fs/ioctl.c:805 tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 Allocated by task 65: gsm_data_alloc.constprop.0+0x27/0x190 drivers/tty/n_gsm.c:926 [n_gsm] gsm_send+0x2c/0x580 drivers/tty/n_gsm.c:819 [n_gsm] gsm1_receive+0x547/0xad0 drivers/tty/n_gsm.c:3038 [n_gsm] gsmld_receive_buf+0x176/0x280 drivers/tty/n_gsm.c:3609 [n_gsm] tty_ldisc_receive_buf+0x101/0x1e0 drivers/tty/tty_buffer.c:391 tty_port_default_receive_buf+0x61/0xa0 drivers/tty/tty_port.c:39 flush_to_ldisc+0x1b0/0x750 drivers/tty/tty_buffer.c:445 process_scheduled_works+0x2b0/0x10d0 kernel/workqueue.c:3229 worker_thread+0x3dc/0x950 kernel/workqueue.c:3391 kthread+0x2a3/0x370 kernel/kthread.c:389 ret_from_fork+0x2d/0x70 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:257 Freed by task 3367: kfree+0x126/0x420 mm/slub.c:4580 gsm_cleanup_mux+0x36c/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 [Analysis] gsm_msg on the tx_ctrl_list or tx_data_list of gsm_mux can be freed by multi threads through ioctl,which leads to the occurrence of uaf. Protect it by gsm tx lock.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50193", "url": "https://ubuntu.com/security/CVE-2024-50193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/entry_32: Clear CPU buffers after register restore in NMI return CPU buffers are currently cleared after call to exc_nmi, but before register state is restored. This may be okay for MDS mitigation but not for RDFS. Because RDFS mitigation requires CPU buffers to be cleared when registers don't have any sensitive data. Move CLEAR_CPU_BUFFERS after RESTORE_ALL_NMI.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50074", "url": "https://ubuntu.com/security/CVE-2024-50074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: parport: Proper fix for array out-of-bounds access The recent fix for array out-of-bounds accesses replaced sprintf() calls blindly with snprintf(). However, since snprintf() returns the would-be-printed size, not the actually output size, the length calculation can still go over the given limit. Use scnprintf() instead of snprintf(), which returns the actually output letters, for addressing the potential out-of-bounds access properly.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50100", "url": "https://ubuntu.com/security/CVE-2024-50100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: gadget: dummy-hcd: Fix \"task hung\" problem The syzbot fuzzer has been encountering \"task hung\" problems ever since the dummy-hcd driver was changed to use hrtimers instead of regular timers. It turns out that the problems are caused by a subtle difference between the timer_pending() and hrtimer_active() APIs. The changeover blindly replaced the first by the second. However, timer_pending() returns True when the timer is queued but not when its callback is running, whereas hrtimer_active() returns True when the hrtimer is queued _or_ its callback is running. This difference occasionally caused dummy_urb_enqueue() to think that the callback routine had not yet started when in fact it was almost finished. As a result the hrtimer was not restarted, which made it impossible for the driver to dequeue later the URB that was just enqueued. This caused usb_kill_urb() to hang, and things got worse from there. Since hrtimers have no API for telling when they are queued and the callback isn't running, the driver must keep track of this for itself. That's what this patch does, adding a new \"timer_pending\" flag and setting or clearing it at the appropriate times.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50075", "url": "https://ubuntu.com/security/CVE-2024-50075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xhci: tegra: fix checked USB2 port number If USB virtualizatoin is enabled, USB2 ports are shared between all Virtual Functions. The USB2 port number owned by an USB2 root hub in a Virtual Function may be less than total USB2 phy number supported by the Tegra XUSB controller. Using total USB2 phy number as port number to check all PORTSC values would cause invalid memory access. [ 116.923438] Unable to handle kernel paging request at virtual address 006c622f7665642f ... [ 117.213640] Call trace: [ 117.216783] tegra_xusb_enter_elpg+0x23c/0x658 [ 117.222021] tegra_xusb_runtime_suspend+0x40/0x68 [ 117.227260] pm_generic_runtime_suspend+0x30/0x50 [ 117.232847] __rpm_callback+0x84/0x3c0 [ 117.237038] rpm_suspend+0x2dc/0x740 [ 117.241229] pm_runtime_work+0xa0/0xb8 [ 117.245769] process_scheduled_works+0x24c/0x478 [ 117.251007] worker_thread+0x23c/0x328 [ 117.255547] kthread+0x104/0x1b0 [ 117.259389] ret_from_fork+0x10/0x20 [ 117.263582] Code: 54000222 f9461ae8 f8747908 b4ffff48 (f9400100)", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50076", "url": "https://ubuntu.com/security/CVE-2024-50076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vt: prevent kernel-infoleak in con_font_get() font.data may not initialize all memory spaces depending on the implementation of vc->vc_sw->con_font_get. This may cause info-leak, so to prevent this, it is safest to modify it to initialize the allocated memory space to 0, and it generally does not affect the overall performance of the system.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50077", "url": "https://ubuntu.com/security/CVE-2024-50077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix multiple init when debugfs is disabled If bt_debugfs is not created successfully, which happens if either CONFIG_DEBUG_FS or CONFIG_DEBUG_FS_ALLOW_ALL is unset, then iso_init() returns early and does not set iso_inited to true. This means that a subsequent call to iso_init() will result in duplicate calls to proto_register(), bt_sock_register(), etc. With CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, the duplicate call to proto_register() triggers this BUG(): list_add double add: new=ffffffffc0b280d0, prev=ffffffffbab56250, next=ffffffffc0b280d0. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:35! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 2 PID: 887 Comm: bluetoothd Not tainted 6.10.11-1-ao-desktop #1 RIP: 0010:__list_add_valid_or_report+0x9a/0xa0 ... __list_add_valid_or_report+0x9a/0xa0 proto_register+0x2b5/0x340 iso_init+0x23/0x150 [bluetooth] set_iso_socket_func+0x68/0x1b0 [bluetooth] kmem_cache_free+0x308/0x330 hci_sock_sendmsg+0x990/0x9e0 [bluetooth] __sock_sendmsg+0x7b/0x80 sock_write_iter+0x9a/0x110 do_iter_readv_writev+0x11d/0x220 vfs_writev+0x180/0x3e0 do_writev+0xca/0x100 ... This change removes the early return. The check for iso_debugfs being NULL was unnecessary, it is always NULL when iso_inited is false.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50078", "url": "https://ubuntu.com/security/CVE-2024-50078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Call iso_exit() on module unload If iso_init() has been called, iso_exit() must be called on module unload. Without that, the struct proto that iso_init() registered with proto_register() becomes invalid, which could cause unpredictable problems later. In my case, with CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, loading the module again usually triggers this BUG(): list_add corruption. next->prev should be prev (ffffffffb5355fd0), but was 0000000000000068. (next=ffffffffc0a010d0). ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:29! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 4159 Comm: modprobe Not tainted 6.10.11-4+bt2-ao-desktop #1 RIP: 0010:__list_add_valid_or_report+0x61/0xa0 ... __list_add_valid_or_report+0x61/0xa0 proto_register+0x299/0x320 hci_sock_init+0x16/0xc0 [bluetooth] bt_init+0x68/0xd0 [bluetooth] __pfx_bt_init+0x10/0x10 [bluetooth] do_one_initcall+0x80/0x2f0 do_init_module+0x8b/0x230 __do_sys_init_module+0x15f/0x190 do_syscall_64+0x68/0x110 ...", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50198", "url": "https://ubuntu.com/security/CVE-2024-50198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: veml6030: fix IIO device retrieval from embedded device The dev pointer that is received as an argument in the in_illuminance_period_available_show function references the device embedded in the IIO device, not in the i2c client. dev_to_iio_dev() must be used to accessthe right data. The current implementation leads to a segmentation fault on every attempt to read the attribute because indio_dev gets a NULL assignment. This bug has been present since the first appearance of the driver, apparently since the last version (V6) before getting applied. A constant attribute was used until then, and the last modifications might have not been tested again.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50201", "url": "https://ubuntu.com/security/CVE-2024-50201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: Fix encoder->possible_clones Include the encoder itself in its possible_clones bitmask. In the past nothing validated that drivers were populating possible_clones correctly, but that changed in commit 74d2aacbe840 (\"drm: Validate encoder->possible_clones\"). Looks like radeon never got the memo and is still not following the rules 100% correctly. This results in some warnings during driver initialization: Bogus possible_clones: [ENCODER:46:TV-46] possible_clones=0x4 (full encoder mask=0x7) WARNING: CPU: 0 PID: 170 at drivers/gpu/drm/drm_mode_config.c:615 drm_mode_config_validate+0x113/0x39c ... (cherry picked from commit 3b6e7d40649c0d75572039aff9d0911864c689db)", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50098", "url": "https://ubuntu.com/security/CVE-2024-50098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Set SDEV_OFFLINE when UFS is shut down There is a history of deadlock if reboot is performed at the beginning of booting. SDEV_QUIESCE was set for all LU's scsi_devices by UFS shutdown, and at that time the audio driver was waiting on blk_mq_submit_bio() holding a mutex_lock while reading the fw binary. After that, a deadlock issue occurred while audio driver shutdown was waiting for mutex_unlock of blk_mq_submit_bio(). To solve this, set SDEV_OFFLINE for all LUs except WLUN, so that any I/O that comes down after a UFS shutdown will return an error. [ 31.907781]I[0: swapper/0: 0] 1 130705007 1651079834 11289729804 0 D( 2) 3 ffffff882e208000 * init [device_shutdown] [ 31.907793]I[0: swapper/0: 0] Mutex: 0xffffff8849a2b8b0: owner[0xffffff882e28cb00 kworker/6:0 :49] [ 31.907806]I[0: swapper/0: 0] Call trace: [ 31.907810]I[0: swapper/0: 0] __switch_to+0x174/0x338 [ 31.907819]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc [ 31.907826]I[0: swapper/0: 0] schedule+0x7c/0xe8 [ 31.907834]I[0: swapper/0: 0] schedule_preempt_disabled+0x24/0x40 [ 31.907842]I[0: swapper/0: 0] __mutex_lock+0x408/0xdac [ 31.907849]I[0: swapper/0: 0] __mutex_lock_slowpath+0x14/0x24 [ 31.907858]I[0: swapper/0: 0] mutex_lock+0x40/0xec [ 31.907866]I[0: swapper/0: 0] device_shutdown+0x108/0x280 [ 31.907875]I[0: swapper/0: 0] kernel_restart+0x4c/0x11c [ 31.907883]I[0: swapper/0: 0] __arm64_sys_reboot+0x15c/0x280 [ 31.907890]I[0: swapper/0: 0] invoke_syscall+0x70/0x158 [ 31.907899]I[0: swapper/0: 0] el0_svc_common+0xb4/0xf4 [ 31.907909]I[0: swapper/0: 0] do_el0_svc+0x2c/0xb0 [ 31.907918]I[0: swapper/0: 0] el0_svc+0x34/0xe0 [ 31.907928]I[0: swapper/0: 0] el0t_64_sync_handler+0x68/0xb4 [ 31.907937]I[0: swapper/0: 0] el0t_64_sync+0x1a0/0x1a4 [ 31.908774]I[0: swapper/0: 0] 49 0 11960702 11236868007 0 D( 2) 6 ffffff882e28cb00 * kworker/6:0 [__bio_queue_enter] [ 31.908783]I[0: swapper/0: 0] Call trace: [ 31.908788]I[0: swapper/0: 0] __switch_to+0x174/0x338 [ 31.908796]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc [ 31.908803]I[0: swapper/0: 0] schedule+0x7c/0xe8 [ 31.908811]I[0: swapper/0: 0] __bio_queue_enter+0xb8/0x178 [ 31.908818]I[0: swapper/0: 0] blk_mq_submit_bio+0x194/0x67c [ 31.908827]I[0: swapper/0: 0] __submit_bio+0xb8/0x19c", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50079", "url": "https://ubuntu.com/security/CVE-2024-50079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/sqpoll: ensure task state is TASK_RUNNING when running task_work When the sqpoll is exiting and cancels pending work items, it may need to run task_work. If this happens from within io_uring_cancel_generic(), then it may be under waiting for the io_uring_task waitqueue. This results in the below splat from the scheduler, as the ring mutex may be attempted grabbed while in a TASK_INTERRUPTIBLE state. Ensure that the task state is set appropriately for that, just like what is done for the other cases in io_run_task_work(). do not call blocking ops when !TASK_RUNNING; state=1 set at [<0000000029387fd2>] prepare_to_wait+0x88/0x2fc WARNING: CPU: 6 PID: 59939 at kernel/sched/core.c:8561 __might_sleep+0xf4/0x140 Modules linked in: CPU: 6 UID: 0 PID: 59939 Comm: iou-sqp-59938 Not tainted 6.12.0-rc3-00113-g8d020023b155 #7456 Hardware name: linux,dummy-virt (DT) pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : __might_sleep+0xf4/0x140 lr : __might_sleep+0xf4/0x140 sp : ffff80008c5e7830 x29: ffff80008c5e7830 x28: ffff0000d93088c0 x27: ffff60001c2d7230 x26: dfff800000000000 x25: ffff0000e16b9180 x24: ffff80008c5e7a50 x23: 1ffff000118bcf4a x22: ffff0000e16b9180 x21: ffff0000e16b9180 x20: 000000000000011b x19: ffff80008310fac0 x18: 1ffff000118bcd90 x17: 30303c5b20746120 x16: 74657320313d6574 x15: 0720072007200720 x14: 0720072007200720 x13: 0720072007200720 x12: ffff600036c64f0b x11: 1fffe00036c64f0a x10: ffff600036c64f0a x9 : dfff800000000000 x8 : 00009fffc939b0f6 x7 : ffff0001b6327853 x6 : 0000000000000001 x5 : ffff0001b6327850 x4 : ffff600036c64f0b x3 : ffff8000803c35bc x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000e16b9180 Call trace: __might_sleep+0xf4/0x140 mutex_lock+0x84/0x124 io_handle_tw_list+0xf4/0x260 tctx_task_work_run+0x94/0x340 io_run_task_work+0x1ec/0x3c0 io_uring_cancel_generic+0x364/0x524 io_sq_thread+0x820/0x124c ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50080", "url": "https://ubuntu.com/security/CVE-2024-50080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: don't allow user copy for unprivileged device UBLK_F_USER_COPY requires userspace to call write() on ublk char device for filling request buffer, and unprivileged device can't be trusted. So don't allow user copy for unprivileged device.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50081", "url": "https://ubuntu.com/security/CVE-2024-50081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-mq: setup queue ->tag_set before initializing hctx Commit 7b815817aa58 (\"blk-mq: add helper for checking if one CPU is mapped to specified hctx\") needs to check queue mapping via tag set in hctx's cpuhp handler. However, q->tag_set may not be setup yet when the cpuhp handler is enabled, then kernel oops is triggered. Fix the issue by setup queue tag_set before initializing hctx.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50082", "url": "https://ubuntu.com/security/CVE-2024-50082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race We're seeing crashes from rq_qos_wake_function that look like this: BUG: unable to handle page fault for address: ffffafe180a40084 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 100000067 P4D 100000067 PUD 10027c067 PMD 10115d067 PTE 0 Oops: Oops: 0002 [#1] PREEMPT SMP PTI CPU: 17 UID: 0 PID: 0 Comm: swapper/17 Not tainted 6.12.0-rc3-00013-geca631b8fe80 #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:_raw_spin_lock_irqsave+0x1d/0x40 Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 9c 41 5c fa 65 ff 05 62 97 30 4c 31 c0 ba 01 00 00 00 0f b1 17 75 0a 4c 89 e0 41 5c c3 cc cc cc cc 89 c6 e8 2c 0b 00 RSP: 0018:ffffafe180580ca0 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffffafe180a3f7a8 RCX: 0000000000000011 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffffafe180a40084 RBP: 0000000000000000 R08: 00000000001e7240 R09: 0000000000000011 R10: 0000000000000028 R11: 0000000000000888 R12: 0000000000000002 R13: ffffafe180a40084 R14: 0000000000000000 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff9aaf1f280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffafe180a40084 CR3: 000000010e428002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: try_to_wake_up+0x5a/0x6a0 rq_qos_wake_function+0x71/0x80 __wake_up_common+0x75/0xa0 __wake_up+0x36/0x60 scale_up.part.0+0x50/0x110 wb_timer_fn+0x227/0x450 ... So rq_qos_wake_function() calls wake_up_process(data->task), which calls try_to_wake_up(), which faults in raw_spin_lock_irqsave(&p->pi_lock). p comes from data->task, and data comes from the waitqueue entry, which is stored on the waiter's stack in rq_qos_wait(). Analyzing the core dump with drgn, I found that the waiter had already woken up and moved on to a completely unrelated code path, clobbering what was previously data->task. Meanwhile, the waker was passing the clobbered garbage in data->task to wake_up_process(), leading to the crash. What's happening is that in between rq_qos_wake_function() deleting the waitqueue entry and calling wake_up_process(), rq_qos_wait() is finding that it already got a token and returning. The race looks like this: rq_qos_wait() rq_qos_wake_function() ============================================================== prepare_to_wait_exclusive() data->got_token = true; list_del_init(&curr->entry); if (data.got_token) break; finish_wait(&rqw->wait, &data.wq); ^- returns immediately because list_empty_careful(&wq_entry->entry) is true ... return, go do something else ... wake_up_process(data->task) (NO LONGER VALID!)-^ Normally, finish_wait() is supposed to synchronize against the waker. But, as noted above, it is returning immediately because the waitqueue entry has already been removed from the waitqueue. The bug is that rq_qos_wake_function() is accessing the waitqueue entry AFTER deleting it. Note that autoremove_wake_function() wakes the waiter and THEN deletes the waitqueue entry, which is the proper order. Fix it by swapping the order. We also need to use list_del_init_careful() to match the list_empty_careful() in finish_wait().", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50101", "url": "https://ubuntu.com/security/CVE-2024-50101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI devices Previously, the domain_context_clear() function incorrectly called pci_for_each_dma_alias() to set up context entries for non-PCI devices. This could lead to kernel hangs or other unexpected behavior. Add a check to only call pci_for_each_dma_alias() for PCI devices. For non-PCI devices, domain_context_clear_one() is called directly.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50083", "url": "https://ubuntu.com/security/CVE-2024-50083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix mptcp DSS corruption due to large pmtu xmit Syzkaller was able to trigger a DSS corruption: TCP: request_sock_subflow_v4: Possible SYN flooding on port [::]:20002. Sending cookies. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 5227 at net/mptcp/protocol.c:695 __mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695 Modules linked in: CPU: 0 UID: 0 PID: 5227 Comm: syz-executor350 Not tainted 6.11.0-syzkaller-08829-gaf9c191ac2a0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:__mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695 Code: 0f b6 dc 31 ff 89 de e8 b5 dd ea f5 89 d8 48 81 c4 50 01 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 98 da ea f5 90 <0f> 0b 90 e9 47 ff ff ff e8 8a da ea f5 90 0f 0b 90 e9 99 e0 ff ff RSP: 0018:ffffc90000006db8 EFLAGS: 00010246 RAX: ffffffff8ba9df18 RBX: 00000000000055f0 RCX: ffff888030023c00 RDX: 0000000000000100 RSI: 00000000000081e5 RDI: 00000000000055f0 RBP: 1ffff110062bf1ae R08: ffffffff8ba9cf12 R09: 1ffff110062bf1b8 R10: dffffc0000000000 R11: ffffed10062bf1b9 R12: 0000000000000000 R13: dffffc0000000000 R14: 00000000700cec61 R15: 00000000000081e5 FS: 000055556679c380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020287000 CR3: 0000000077892000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: move_skbs_to_msk net/mptcp/protocol.c:811 [inline] mptcp_data_ready+0x29c/0xa90 net/mptcp/protocol.c:854 subflow_data_ready+0x34a/0x920 net/mptcp/subflow.c:1490 tcp_data_queue+0x20fd/0x76c0 net/ipv4/tcp_input.c:5283 tcp_rcv_established+0xfba/0x2020 net/ipv4/tcp_input.c:6237 tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915 tcp_v4_rcv+0x2dc0/0x37f0 net/ipv4/tcp_ipv4.c:2350 ip_protocol_deliver_rcu+0x22e/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x341/0x5f0 net/ipv4/ip_input.c:233 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314 __netif_receive_skb_one_core net/core/dev.c:5662 [inline] __netif_receive_skb+0x2bf/0x650 net/core/dev.c:5775 process_backlog+0x662/0x15b0 net/core/dev.c:6107 __napi_poll+0xcb/0x490 net/core/dev.c:6771 napi_poll net/core/dev.c:6840 [inline] net_rx_action+0x89b/0x1240 net/core/dev.c:6962 handle_softirqs+0x2c5/0x980 kernel/softirq.c:554 do_softirq+0x11b/0x1e0 kernel/softirq.c:455 __local_bh_enable_ip+0x1bb/0x200 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0x1764/0x3e80 net/core/dev.c:4451 dev_queue_xmit include/linux/netdevice.h:3094 [inline] neigh_hh_output include/net/neighbour.h:526 [inline] neigh_output include/net/neighbour.h:540 [inline] ip_finish_output2+0xd41/0x1390 net/ipv4/ip_output.c:236 ip_local_out net/ipv4/ip_output.c:130 [inline] __ip_queue_xmit+0x118c/0x1b80 net/ipv4/ip_output.c:536 __tcp_transmit_skb+0x2544/0x3b30 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_mtu_probe net/ipv4/tcp_output.c:2547 [inline] tcp_write_xmit+0x641d/0x6bf0 net/ipv4/tcp_output.c:2752 __tcp_push_pending_frames+0x9b/0x360 net/ipv4/tcp_output.c:3015 tcp_push_pending_frames include/net/tcp.h:2107 [inline] tcp_data_snd_check net/ipv4/tcp_input.c:5714 [inline] tcp_rcv_established+0x1026/0x2020 net/ipv4/tcp_input.c:6239 tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915 sk_backlog_rcv include/net/sock.h:1113 [inline] __release_sock+0x214/0x350 net/core/sock.c:3072 release_sock+0x61/0x1f0 net/core/sock.c:3626 mptcp_push_ ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50068", "url": "https://ubuntu.com/security/CVE-2024-50068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/tests/sysfs-kunit.h: fix memory leak in damon_sysfs_test_add_targets() The sysfs_target->regions allocated in damon_sysfs_regions_alloc() is not freed in damon_sysfs_test_add_targets(), which cause the following memory leak, free it to fix it. \tunreferenced object 0xffffff80c2a8db80 (size 96): \t comm \"kunit_try_catch\", pid 187, jiffies 4294894363 \t hex dump (first 32 bytes): \t 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ \t 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ \t backtrace (crc 0): \t [<0000000001e3714d>] kmemleak_alloc+0x34/0x40 \t [<000000008e6835c1>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000001286d9f8>] damon_sysfs_test_add_targets+0x1cc/0x738 \t [<0000000032ef8f77>] kunit_try_run_case+0x13c/0x3ac \t [<00000000f3edea23>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000adf936cf>] kthread+0x2e8/0x374 \t [<0000000041bb1628>] ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50199", "url": "https://ubuntu.com/security/CVE-2024-50199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/swapfile: skip HugeTLB pages for unuse_vma I got a bad pud error and lost a 1GB HugeTLB when calling swapoff. The problem can be reproduced by the following steps: 1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory. 2. Swapout the above anonymous memory. 3. run swapoff and we will get a bad pud error in kernel message: mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7) We can tell that pud_clear_bad is called by pud_none_or_clear_bad in unuse_pud_range() by ftrace. And therefore the HugeTLB pages will never be freed because we lost it from page table. We can skip HugeTLB pages for unuse_vma to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50066", "url": "https://ubuntu.com/security/CVE-2024-50066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mremap: fix move_normal_pmd/retract_page_tables race In mremap(), move_page_tables() looks at the type of the PMD entry and the specified address range to figure out by which method the next chunk of page table entries should be moved. At that point, the mmap_lock is held in write mode, but no rmap locks are held yet. For PMD entries that point to page tables and are fully covered by the source address range, move_pgt_entry(NORMAL_PMD, ...) is called, which first takes rmap locks, then does move_normal_pmd(). move_normal_pmd() takes the necessary page table locks at source and destination, then moves an entire page table from the source to the destination. The problem is: The rmap locks, which protect against concurrent page table removal by retract_page_tables() in the THP code, are only taken after the PMD entry has been read and it has been decided how to move it. So we can race as follows (with two processes that have mappings of the same tmpfs file that is stored on a tmpfs mount with huge=advise); note that process A accesses page tables through the MM while process B does it through the file rmap: process A process B ========= ========= mremap mremap_to move_vma move_page_tables get_old_pmd alloc_new_pmd *** PREEMPT *** madvise(MADV_COLLAPSE) do_madvise madvise_walk_vmas madvise_vma_behavior madvise_collapse hpage_collapse_scan_file collapse_file retract_page_tables i_mmap_lock_read(mapping) pmdp_collapse_flush i_mmap_unlock_read(mapping) move_pgt_entry(NORMAL_PMD, ...) take_rmap_locks move_normal_pmd drop_rmap_locks When this happens, move_normal_pmd() can end up creating bogus PMD entries in the line `pmd_populate(mm, new_pmd, pmd_pgtable(pmd))`. The effect depends on arch-specific and machine-specific details; on x86, you can end up with physical page 0 mapped as a page table, which is likely exploitable for user->kernel privilege escalation. Fix the race by letting process B recheck that the PMD still points to a page table after the rmap locks have been taken. Otherwise, we bail and let the caller fall back to the PTE-level copying path, which will then bail immediately at the pmd_none() check. Bug reachability: Reaching this bug requires that you can create shmem/file THP mappings - anonymous THP uses different code that doesn't zap stuff under rmap locks. File THP is gated on an experimental config flag (CONFIG_READ_ONLY_THP_FOR_FS), so on normal distro kernels you need shmem THP to hit this bug. As far as I know, getting shmem THP normally requires that you can mount your own tmpfs with the right mount flags, which would require creating your own user+mount namespace; though I don't know if some distros maybe enable shmem THP by default or something like that. Bug impact: This issue can likely be used for user->kernel privilege escalation when it is reachable.", "cve_priority": "medium", "cve_public_date": "2024-10-23 06:15:00 UTC" }, { "cve": "CVE-2024-50202", "url": "https://ubuntu.com/security/CVE-2024-50202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: propagate directory read errors from nilfs_find_entry() Syzbot reported that a task hang occurs in vcs_open() during a fuzzing test for nilfs2. The root cause of this problem is that in nilfs_find_entry(), which searches for directory entries, ignores errors when loading a directory page/folio via nilfs_get_folio() fails. If the filesystem images is corrupted, and the i_size of the directory inode is large, and the directory page/folio is successfully read but fails the sanity check, for example when it is zero-filled, nilfs_check_folio() may continue to spit out error messages in bursts. Fix this issue by propagating the error to the callers when loading a page/folio fails in nilfs_find_entry(). The current interface of nilfs_find_entry() and its callers is outdated and cannot propagate error codes such as -EIO and -ENOMEM returned via nilfs_find_entry(), so fix it together.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50200", "url": "https://ubuntu.com/security/CVE-2024-50200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: maple_tree: correct tree corruption on spanning store Patch series \"maple_tree: correct tree corruption on spanning store\", v3. There has been a nasty yet subtle maple tree corruption bug that appears to have been in existence since the inception of the algorithm. This bug seems far more likely to happen since commit f8d112a4e657 (\"mm/mmap: avoid zeroing vma tree in mmap_region()\"), which is the point at which reports started to be submitted concerning this bug. We were made definitely aware of the bug thanks to the kind efforts of Bert Karwatzki who helped enormously in my being able to track this down and identify the cause of it. The bug arises when an attempt is made to perform a spanning store across two leaf nodes, where the right leaf node is the rightmost child of the shared parent, AND the store completely consumes the right-mode node. This results in mas_wr_spanning_store() mitakenly duplicating the new and existing entries at the maximum pivot within the range, and thus maple tree corruption. The fix patch corrects this by detecting this scenario and disallowing the mistaken duplicate copy. The fix patch commit message goes into great detail as to how this occurs. This series also includes a test which reliably reproduces the issue, and asserts that the fix works correctly. Bert has kindly tested the fix and confirmed it resolved his issues. Also Mikhail Gavrilov kindly reported what appears to be precisely the same bug, which this fix should also resolve. This patch (of 2): There has been a subtle bug present in the maple tree implementation from its inception. This arises from how stores are performed - when a store occurs, it will overwrite overlapping ranges and adjust the tree as necessary to accommodate this. A range may always ultimately span two leaf nodes. In this instance we walk the two leaf nodes, determine which elements are not overwritten to the left and to the right of the start and end of the ranges respectively and then rebalance the tree to contain these entries and the newly inserted one. This kind of store is dubbed a 'spanning store' and is implemented by mas_wr_spanning_store(). In order to reach this stage, mas_store_gfp() invokes mas_wr_preallocate(), mas_wr_store_type() and mas_wr_walk() in turn to walk the tree and update the object (mas) to traverse to the location where the write should be performed, determining its store type. When a spanning store is required, this function returns false stopping at the parent node which contains the target range, and mas_wr_store_type() marks the mas->store_type as wr_spanning_store to denote this fact. When we go to perform the store in mas_wr_spanning_store(), we first determine the elements AFTER the END of the range we wish to store (that is, to the right of the entry to be inserted) - we do this by walking to the NEXT pivot in the tree (i.e. r_mas.last + 1), starting at the node we have just determined contains the range over which we intend to write. We then turn our attention to the entries to the left of the entry we are inserting, whose state is represented by l_mas, and copy these into a 'big node', which is a special node which contains enough slots to contain two leaf node's worth of data. We then copy the entry we wish to store immediately after this - the copy and the insertion of the new entry is performed by mas_store_b_node(). After this we copy the elements to the right of the end of the range which we are inserting, if we have not exceeded the length of the node (i.e. r_mas.offset <= r_mas.end). Herein lies the bug - under very specific circumstances, this logic can break and corrupt the maple tree. Consider the following tree: Height 0 Root Node / \\ pivot = 0xffff / \\ pivot = ULONG_MAX / ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50084", "url": "https://ubuntu.com/security/CVE-2024-50084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: microchip: vcap api: Fix memory leaks in vcap_api_encode_rule_test() Commit a3c1e45156ad (\"net: microchip: vcap: Fix use-after-free error in kunit test\") fixed the use-after-free error, but introduced below memory leaks by removing necessary vcap_free_rule(), add it to fix it. \tunreferenced object 0xffffff80ca58b700 (size 192): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898264 \t hex dump (first 32 bytes): \t 00 12 7a 00 05 00 00 00 0a 00 00 00 64 00 00 00 ..z.........d... \t 00 00 00 00 00 00 00 00 00 04 0b cc 80 ff ff ff ................ \t backtrace (crc 9c09c3fe): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<0000000040a01b8d>] vcap_alloc_rule+0x3cc/0x9c4 \t [<000000003fe86110>] vcap_api_encode_rule_test+0x1ac/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0400 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898265 \t hex dump (first 32 bytes): \t 80 04 0b cc 80 ff ff ff 18 b7 58 ca 80 ff ff ff ..........X..... \t 39 00 00 00 02 00 00 00 06 05 04 03 02 01 ff ff 9............... \t backtrace (crc daf014e9): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<00000000dfdb1e81>] vcap_api_encode_rule_test+0x224/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0700 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898265 \t hex dump (first 32 bytes): \t 80 07 0b cc 80 ff ff ff 28 b7 58 ca 80 ff ff ff ........(.X..... \t 3c 00 00 00 00 00 00 00 01 2f 03 b3 ec ff ff ff <......../...... \t backtrace (crc 8d877792): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000006eadfab7>] vcap_rule_add_action+0x2d0/0x52c \t [<00000000323475d1>] vcap_api_encode_rule_test+0x4d4/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0900 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898266 \t hex dump (first 32 bytes): \t 80 09 0b cc 80 ff ff ff 80 06 0b cc 80 ff ff ff ................ \t 7d 00 00 00 01 00 00 00 00 00 00 00 ff 00 00 00 }............... \t backtrace (crc 34181e56): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<00000000991e3564>] vcap_val_rule+0xcf0/0x13e8 \t [<00000000fc9868e5>] vcap_api_encode_rule_test+0x678/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0980 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898266 \t hex dump (first 32 bytes): \t 18 b7 58 ca 80 ff ff ff 00 09 0b cc 80 ff ff ff ..X............. \t 67 00 00 00 00 00 00 00 01 01 74 88 c0 ff ff ff g.........t..... \t backtrace (crc 275fd9be): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<000000001396a1a2>] test_add_de ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50194", "url": "https://ubuntu.com/security/CVE-2024-50194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Fix uprobes for big-endian kernels The arm64 uprobes code is broken for big-endian kernels as it doesn't convert the in-memory instruction encoding (which is always little-endian) into the kernel's native endianness before analyzing and simulating instructions. This may result in a few distinct problems: * The kernel may may erroneously reject probing an instruction which can safely be probed. * The kernel may erroneously erroneously permit stepping an instruction out-of-line when that instruction cannot be stepped out-of-line safely. * The kernel may erroneously simulate instruction incorrectly dur to interpretting the byte-swapped encoding. The endianness mismatch isn't caught by the compiler or sparse because: * The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so the compiler and sparse have no idea these contain a little-endian 32-bit value. The core uprobes code populates these with a memcpy() which similarly does not handle endianness. * While the uprobe_opcode_t type is an alias for __le32, both arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[] to the similarly-named probe_opcode_t, which is an alias for u32. Hence there is no endianness conversion warning. Fix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and adding the appropriate __le32_to_cpu() conversions prior to consuming the instruction encoding. The core uprobes copies these fields as opaque ranges of bytes, and so is unaffected by this change. At the same time, remove MAX_UINSN_BYTES and consistently use AARCH64_INSN_SIZE for clarity. Tested with the following: | #include | #include | | #define noinline __attribute__((noinline)) | | static noinline void *adrp_self(void) | { | void *addr; | | asm volatile( | \" adrp %x0, adrp_self\\n\" | \" add %x0, %x0, :lo12:adrp_self\\n\" | : \"=r\" (addr)); | } | | | int main(int argc, char *argv) | { | void *ptr = adrp_self(); | bool equal = (ptr == adrp_self); | | printf(\"adrp_self => %p\\n\" | \"adrp_self() => %p\\n\" | \"%s\\n\", | adrp_self, ptr, equal ? \"EQUAL\" : \"NOT EQUAL\"); | | return 0; | } .... where the adrp_self() function was compiled to: | 00000000004007e0 : | 4007e0: 90000000 adrp x0, 400000 <__ehdr_start> | 4007e4: 911f8000 add x0, x0, #0x7e0 | 4007e8: d65f03c0 ret Before this patch, the ADRP is not recognized, and is assumed to be steppable, resulting in corruption of the result: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0xffffffffff7e0 | NOT EQUAL After this patch, the ADRP is correctly recognized and simulated: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50099", "url": "https://ubuntu.com/security/CVE-2024-50099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Remove broken LDR (literal) uprobe support The simulate_ldr_literal() and simulate_ldrsw_literal() functions are unsafe to use for uprobes. Both functions were originally written for use with kprobes, and access memory with plain C accesses. When uprobes was added, these were reused unmodified even though they cannot safely access user memory. There are three key problems: 1) The plain C accesses do not have corresponding extable entries, and thus if they encounter a fault the kernel will treat these as unintentional accesses to user memory, resulting in a BUG() which will kill the kernel thread, and likely lead to further issues (e.g. lockup or panic()). 2) The plain C accesses are subject to HW PAN and SW PAN, and so when either is in use, any attempt to simulate an access to user memory will fault. Thus neither simulate_ldr_literal() nor simulate_ldrsw_literal() can do anything useful when simulating a user instruction on any system with HW PAN or SW PAN. 3) The plain C accesses are privileged, as they run in kernel context, and in practice can access a small range of kernel virtual addresses. The instructions they simulate have a range of +/-1MiB, and since the simulated instructions must itself be a user instructions in the TTBR0 address range, these can address the final 1MiB of the TTBR1 acddress range by wrapping downwards from an address in the first 1MiB of the TTBR0 address range. In contemporary kernels the last 8MiB of TTBR1 address range is reserved, and accesses to this will always fault, meaning this is no worse than (1). Historically, it was theoretically possible for the linear map or vmemmap to spill into the final 8MiB of the TTBR1 address range, but in practice this is extremely unlikely to occur as this would require either: * Having enough physical memory to fill the entire linear map all the way to the final 1MiB of the TTBR1 address range. * Getting unlucky with KASLR randomization of the linear map such that the populated region happens to overlap with the last 1MiB of the TTBR address range. ... and in either case if we were to spill into the final page there would be larger problems as the final page would alias with error pointers. Practically speaking, (1) and (2) are the big issues. Given there have been no reports of problems since the broken code was introduced, it appears that no-one is relying on probing these instructions with uprobes. Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW (literal), limiting the use of simulate_ldr_literal() and simulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR (literal) and LDRSW (literal) will be rejected as arm_probe_decode_insn() will return INSN_REJECTED. In future we can consider introducing working uprobes support for these instructions, but this will require more significant work.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50195", "url": "https://ubuntu.com/security/CVE-2024-50195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-clock: Fix missing timespec64 check in pc_clock_settime() As Andrew pointed out, it will make sense that the PTP core checked timespec64 struct's tv_sec and tv_nsec range before calling ptp->info->settime64(). As the man manual of clock_settime() said, if tp.tv_sec is negative or tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL, which include dynamic clocks which handles PTP clock, and the condition is consistent with timespec64_valid(). As Thomas suggested, timespec64_valid() only check the timespec is valid, but not ensure that the time is in a valid range, so check it ahead using timespec64_valid_strict() in pc_clock_settime() and return -EINVAL if not valid. There are some drivers that use tp->tv_sec and tp->tv_nsec directly to write registers without validity checks and assume that the higher layer has checked it, which is dangerous and will benefit from this, such as hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(), and some drivers can remove the checks of itself.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50085", "url": "https://ubuntu.com/security/CVE-2024-50085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: fix UaF read in mptcp_pm_nl_rm_addr_or_subflow Syzkaller reported this splat: ================================================================== BUG: KASAN: slab-use-after-free in mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881 Read of size 4 at addr ffff8880569ac858 by task syz.1.2799/14662 CPU: 0 UID: 0 PID: 14662 Comm: syz.1.2799 Not tainted 6.12.0-rc2-syzkaller-00307-g36c254515dc6 #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+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881 mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:914 [inline] mptcp_nl_remove_id_zero_address+0x305/0x4a0 net/mptcp/pm_netlink.c:1572 mptcp_pm_nl_del_addr_doit+0x5c9/0x770 net/mptcp/pm_netlink.c:1603 genl_family_rcv_msg_doit+0x202/0x2f0 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x565/0x800 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x165/0x410 net/netlink/af_netlink.c:2551 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1331 [inline] netlink_unicast+0x53c/0x7f0 net/netlink/af_netlink.c:1357 netlink_sendmsg+0x8b8/0xd70 net/netlink/af_netlink.c:1901 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg net/socket.c:744 [inline] ____sys_sendmsg+0x9ae/0xb40 net/socket.c:2607 ___sys_sendmsg+0x135/0x1e0 net/socket.c:2661 __sys_sendmsg+0x117/0x1f0 net/socket.c:2690 do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline] __do_fast_syscall_32+0x73/0x120 arch/x86/entry/common.c:386 do_fast_syscall_32+0x32/0x80 arch/x86/entry/common.c:411 entry_SYSENTER_compat_after_hwframe+0x84/0x8e RIP: 0023:0xf7fe4579 Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00 RSP: 002b:00000000f574556c EFLAGS: 00000296 ORIG_RAX: 0000000000000172 RAX: ffffffffffffffda RBX: 000000000000000b RCX: 0000000020000140 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000296 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Allocated by task 5387: 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 kmalloc_noprof include/linux/slab.h:878 [inline] kzalloc_noprof include/linux/slab.h:1014 [inline] subflow_create_ctx+0x87/0x2a0 net/mptcp/subflow.c:1803 subflow_ulp_init+0xc3/0x4d0 net/mptcp/subflow.c:1956 __tcp_set_ulp net/ipv4/tcp_ulp.c:146 [inline] tcp_set_ulp+0x326/0x7f0 net/ipv4/tcp_ulp.c:167 mptcp_subflow_create_socket+0x4ae/0x10a0 net/mptcp/subflow.c:1764 __mptcp_subflow_connect+0x3cc/0x1490 net/mptcp/subflow.c:1592 mptcp_pm_create_subflow_or_signal_addr+0xbda/0x23a0 net/mptcp/pm_netlink.c:642 mptcp_pm_nl_fully_established net/mptcp/pm_netlink.c:650 [inline] mptcp_pm_nl_work+0x3a1/0x4f0 net/mptcp/pm_netlink.c:943 mptcp_worker+0x15a/0x1240 net/mptcp/protocol.c:2777 process_one_work+0x958/0x1b30 kernel/workqueue.c:3229 process_scheduled_works kernel/workqueue.c:3310 [inline] worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/ke ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50086", "url": "https://ubuntu.com/security/CVE-2024-50086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix user-after-free from session log off There is racy issue between smb2 session log off and smb2 session setup. It will cause user-after-free from session log off. This add session_lock when setting SMB2_SESSION_EXPIRED and referece count to session struct not to free session while it is being used.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50087", "url": "https://ubuntu.com/security/CVE-2024-50087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix uninitialized pointer free on read_alloc_one_name() error The function read_alloc_one_name() does not initialize the name field of the passed fscrypt_str struct if kmalloc fails to allocate the corresponding buffer. Thus, it is not guaranteed that fscrypt_str.name is initialized when freeing it. This is a follow-up to the linked patch that fixes the remaining instances of the bug introduced by commit e43eec81c516 (\"btrfs: use struct qstr instead of name and namelen pairs\").", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50088", "url": "https://ubuntu.com/security/CVE-2024-50088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix uninitialized pointer free in add_inode_ref() The add_inode_ref() function does not initialize the \"name\" struct when it is declared. If any of the following calls to \"read_one_inode() returns NULL, \tdir = read_one_inode(root, parent_objectid); \tif (!dir) { \t\tret = -ENOENT; \t\tgoto out; \t} \tinode = read_one_inode(root, inode_objectid); \tif (!inode) { \t\tret = -EIO; \t\tgoto out; \t} then \"name.name\" would be freed on \"out\" before being initialized. out: \t... \tkfree(name.name); This issue was reported by Coverity with CID 1526744.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50182", "url": "https://ubuntu.com/security/CVE-2024-50182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: secretmem: disable memfd_secret() if arch cannot set direct map Return -ENOSYS from memfd_secret() syscall if !can_set_direct_map(). This is the case for example on some arm64 configurations, where marking 4k PTEs in the direct map not present can only be done if the direct map is set up at 4k granularity in the first place (as ARM's break-before-make semantics do not easily allow breaking apart large/gigantic pages). More precisely, on arm64 systems with !can_set_direct_map(), set_direct_map_invalid_noflush() is a no-op, however it returns success (0) instead of an error. This means that memfd_secret will seemingly \"work\" (e.g. syscall succeeds, you can mmap the fd and fault in pages), but it does not actually achieve its goal of removing its memory from the direct map. Note that with this patch, memfd_secret() will start erroring on systems where can_set_direct_map() returns false (arm64 with CONFIG_RODATA_FULL_DEFAULT_ENABLED=n, CONFIG_DEBUG_PAGEALLOC=n and CONFIG_KFENCE=n), but that still seems better than the current silent failure. Since CONFIG_RODATA_FULL_DEFAULT_ENABLED defaults to 'y', most arm64 systems actually have a working memfd_secret() and aren't be affected. From going through the iterations of the original memfd_secret patch series, it seems that disabling the syscall in these scenarios was the intended behavior [1] (preferred over having set_direct_map_invalid_noflush return an error as that would result in SIGBUSes at page-fault time), however the check for it got dropped between v16 [2] and v17 [3], when secretmem moved away from CMA allocations. [1]: https://lore.kernel.org/lkml/20201124164930.GK8537@kernel.org/ [2]: https://lore.kernel.org/lkml/20210121122723.3446-11-rppt@kernel.org/#t [3]: https://lore.kernel.org/lkml/20201125092208.12544-10-rppt@kernel.org/", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50019", "url": "https://ubuntu.com/security/CVE-2024-50019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kthread: unpark only parked kthread Calling into kthread unparking unconditionally is mostly harmless when the kthread is already unparked. The wake up is then simply ignored because the target is not in TASK_PARKED state. However if the kthread is per CPU, the wake up is preceded by a call to kthread_bind() which expects the task to be inactive and in TASK_PARKED state, which obviously isn't the case if it is unparked. As a result, calling kthread_stop() on an unparked per-cpu kthread triggers such a warning: \tWARNING: CPU: 0 PID: 11 at kernel/kthread.c:525 __kthread_bind_mask kernel/kthread.c:525 \t \t kthread_stop+0x17a/0x630 kernel/kthread.c:707 \t destroy_workqueue+0x136/0xc40 kernel/workqueue.c:5810 \t wg_destruct+0x1e2/0x2e0 drivers/net/wireguard/device.c:257 \t netdev_run_todo+0xe1a/0x1000 net/core/dev.c:10693 \t default_device_exit_batch+0xa14/0xa90 net/core/dev.c:11769 \t ops_exit_list net/core/net_namespace.c:178 [inline] \t cleanup_net+0x89d/0xcc0 net/core/net_namespace.c:640 \t process_one_work kernel/workqueue.c:3231 [inline] \t process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 \t worker_thread+0x86d/0xd70 kernel/workqueue.c:3393 \t kthread+0x2f0/0x390 kernel/kthread.c:389 \t ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 \t ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 \t Fix this with skipping unecessary unparking while stopping a kthread.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50096", "url": "https://ubuntu.com/security/CVE-2024-50096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/dmem: Fix vulnerability in migrate_to_ram upon copy error The `nouveau_dmem_copy_one` function ensures that the copy push command is sent to the device firmware but does not track whether it was executed successfully. In the case of a copy error (e.g., firmware or hardware failure), the copy push command will be sent via the firmware channel, and `nouveau_dmem_copy_one` will likely report success, leading to the `migrate_to_ram` function returning a dirty HIGH_USER page to the user. This can result in a security vulnerability, as a HIGH_USER page that may contain sensitive or corrupted data could be returned to the user. To prevent this vulnerability, we allocate a zero page. Thus, in case of an error, a non-dirty (zero) page will be returned to the user.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50020", "url": "https://ubuntu.com/security/CVE-2024-50020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix improper handling of refcount in ice_sriov_set_msix_vec_count() This patch addresses an issue with improper reference count handling in the ice_sriov_set_msix_vec_count() function. First, the function calls ice_get_vf_by_id(), which increments the reference count of the vf pointer. If the subsequent call to ice_get_vf_vsi() fails, the function currently returns an error without decrementing the reference count of the vf pointer, leading to a reference count leak. The correct behavior, as implemented in this patch, is to decrement the reference count using ice_put_vf(vf) before returning an error when vsi is NULL. Second, the function calls ice_sriov_get_irqs(), which sets vf->first_vector_idx. If this call returns a negative value, indicating an error, the function returns an error without decrementing the reference count of the vf pointer, resulting in another reference count leak. The patch addresses this by adding a call to ice_put_vf(vf) before returning an error when vf->first_vector_idx < 0. This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and identifying potential mismanagement of reference counts. In this case, the tool flagged the missing decrement operation as a potential issue, leading to this patch.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50021", "url": "https://ubuntu.com/security/CVE-2024-50021", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix improper handling of refcount in ice_dpll_init_rclk_pins() This patch addresses a reference count handling issue in the ice_dpll_init_rclk_pins() function. The function calls ice_dpll_get_pins(), which increments the reference count of the relevant resources. However, if the condition WARN_ON((!vsi || !vsi->netdev)) is met, the function currently returns an error without properly releasing the resources acquired by ice_dpll_get_pins(), leading to a reference count leak. To resolve this, the check has been moved to the top of the function. This ensures that the function verifies the state before any resources are acquired, avoiding the need for additional resource management in the error path. This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and detecting potential issues where resources are not properly managed. In this case, the tool flagged the missing release operation as a potential problem, which led to the development of this patch.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50022", "url": "https://ubuntu.com/security/CVE-2024-50022", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: device-dax: correct pgoff align in dax_set_mapping() pgoff should be aligned using ALIGN_DOWN() instead of ALIGN(). Otherwise, vmf->address not aligned to fault_size will be aligned to the next alignment, that can result in memory failure getting the wrong address. It's a subtle situation that only can be observed in page_mapped_in_vma() after the page is page fault handled by dev_dax_huge_fault. Generally, there is little chance to perform page_mapped_in_vma in dev-dax's page unless in specific error injection to the dax device to trigger an MCE - memory-failure. In that case, page_mapped_in_vma() will be triggered to determine which task is accessing the failure address and kill that task in the end. We used self-developed dax device (which is 2M aligned mapping) , to perform error injection to random address. It turned out that error injected to non-2M-aligned address was causing endless MCE until panic. Because page_mapped_in_vma() kept resulting wrong address and the task accessing the failure address was never killed properly: [ 3783.719419] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.049006] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.049190] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.448042] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.448186] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.792026] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.792179] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.162502] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.162633] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.461116] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.461247] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.764730] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.764859] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.042128] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.042259] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.464293] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.464423] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.818090] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.818217] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3787.085297] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3787.085424] Memory failure: 0x200c9742: recovery action for dax page: Recovered It took us several weeks to pinpoint this problem,  but we eventually used bpftrace to trace the page fault and mce address and successfully identified the issue. Joao added: ; Likely we never reproduce in production because we always pin : device-dax regions in the region align they provide (Qemu does : similarly with prealloc in hugetlb/file backed memory). I think this : bug requires that we touch *unpinned* device-dax regions unaligned to : the device-dax selected alignment (page size i.e. 4K/2M/1G)", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50185", "url": "https://ubuntu.com/security/CVE-2024-50185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: handle consistently DSS corruption Bugged peer implementation can send corrupted DSS options, consistently hitting a few warning in the data path. Use DEBUG_NET assertions, to avoid the splat on some builds and handle consistently the error, dumping related MIBs and performing fallback and/or reset according to the subflow type.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50023", "url": "https://ubuntu.com/security/CVE-2024-50023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: Remove LED entry from LEDs list on unregister Commit c938ab4da0eb (\"net: phy: Manual remove LEDs to ensure correct ordering\") correctly fixed a problem with using devm_ but missed removing the LED entry from the LEDs list. This cause kernel panic on specific scenario where the port for the PHY is torn down and up and the kmod for the PHY is removed. On setting the port down the first time, the assosiacted LEDs are correctly unregistered. The associated kmod for the PHY is now removed. The kmod is now added again and the port is now put up, the associated LED are registered again. On putting the port down again for the second time after these step, the LED list now have 4 elements. With the first 2 already unregistered previously and the 2 new one registered again. This cause a kernel panic as the first 2 element should have been removed. Fix this by correctly removing the element when LED is unregistered.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50024", "url": "https://ubuntu.com/security/CVE-2024-50024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: Fix an unsafe loop on the list The kernel may crash when deleting a genetlink family if there are still listeners for that family: Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c000000000c080bc] netlink_update_socket_mc+0x3c/0xc0 LR [c000000000c0f764] __netlink_clear_multicast_users+0x74/0xc0 Call Trace: __netlink_clear_multicast_users+0x74/0xc0 genl_unregister_family+0xd4/0x2d0 Change the unsafe loop on the list to a safe one, because inside the loop there is an element removal from this list.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50186", "url": "https://ubuntu.com/security/CVE-2024-50186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: explicitly clear the sk pointer, when pf->create fails We have recently noticed the exact same KASAN splat as in commit 6cd4a78d962b (\"net: do not leave a dangling sk pointer, when socket creation fails\"). The problem is that commit did not fully address the problem, as some pf->create implementations do not use sk_common_release in their error paths. For example, we can use the same reproducer as in the above commit, but changing ping to arping. arping uses AF_PACKET socket and if packet_create fails, it will just sk_free the allocated sk object. While we could chase all the pf->create implementations and make sure they NULL the freed sk object on error from the socket, we can't guarantee future protocols will not make the same mistake. So it is easier to just explicitly NULL the sk pointer upon return from pf->create in __sock_create. We do know that pf->create always releases the allocated sk object on error, so if the pointer is not NULL, it is definitely dangling.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50025", "url": "https://ubuntu.com/security/CVE-2024-50025", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: fnic: Move flush_work initialization out of if block After commit 379a58caa199 (\"scsi: fnic: Move fnic_fnic_flush_tx() to a work queue\"), it can happen that a work item is sent to an uninitialized work queue. This may has the effect that the item being queued is never actually queued, and any further actions depending on it will not proceed. The following warning is observed while the fnic driver is loaded: kernel: WARNING: CPU: 11 PID: 0 at ../kernel/workqueue.c:1524 __queue_work+0x373/0x410 kernel: kernel: queue_work_on+0x3a/0x50 kernel: fnic_wq_copy_cmpl_handler+0x54a/0x730 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: fnic_isr_msix_wq_copy+0x2d/0x60 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: __handle_irq_event_percpu+0x36/0x1a0 kernel: handle_irq_event_percpu+0x30/0x70 kernel: handle_irq_event+0x34/0x60 kernel: handle_edge_irq+0x7e/0x1a0 kernel: __common_interrupt+0x3b/0xb0 kernel: common_interrupt+0x58/0xa0 kernel: It has been observed that this may break the rediscovery of Fibre Channel devices after a temporary fabric failure. This patch fixes it by moving the work queue initialization out of an if block in fnic_probe().", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50026", "url": "https://ubuntu.com/security/CVE-2024-50026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: wd33c93: Don't use stale scsi_pointer value A regression was introduced with commit dbb2da557a6a (\"scsi: wd33c93: Move the SCSI pointer to private command data\") which results in an oops in wd33c93_intr(). That commit added the scsi_pointer variable and initialized it from hostdata->connected. However, during selection, hostdata->connected is not yet valid. Fix this by getting the current scsi_pointer from hostdata->selecting.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50027", "url": "https://ubuntu.com/security/CVE-2024-50027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: core: Free tzp copy along with the thermal zone The object pointed to by tz->tzp may still be accessed after being freed in thermal_zone_device_unregister(), so move the freeing of it to the point after the removal completion has been completed at which it cannot be accessed any more.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50028", "url": "https://ubuntu.com/security/CVE-2024-50028", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: core: Reference count the zone in thermal_zone_get_by_id() There are places in the thermal netlink code where nothing prevents the thermal zone object from going away while being accessed after it has been returned by thermal_zone_get_by_id(). To address this, make thermal_zone_get_by_id() get a reference on the thermal zone device object to be returned with the help of get_device(), under thermal_list_lock, and adjust all of its callers to this change with the help of the cleanup.h infrastructure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50029", "url": "https://ubuntu.com/security/CVE-2024-50029", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_conn: Fix UAF in hci_enhanced_setup_sync This checks if the ACL connection remains valid as it could be destroyed while hci_enhanced_setup_sync is pending on cmd_sync leading to the following trace: BUG: KASAN: slab-use-after-free in hci_enhanced_setup_sync+0x91b/0xa60 Read of size 1 at addr ffff888002328ffd by task kworker/u5:2/37 CPU: 0 UID: 0 PID: 37 Comm: kworker/u5:2 Not tainted 6.11.0-rc6-01300-g810be445d8d6 #7099 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Workqueue: hci0 hci_cmd_sync_work Call Trace: dump_stack_lvl+0x5d/0x80 ? hci_enhanced_setup_sync+0x91b/0xa60 print_report+0x152/0x4c0 ? hci_enhanced_setup_sync+0x91b/0xa60 ? __virt_addr_valid+0x1fa/0x420 ? hci_enhanced_setup_sync+0x91b/0xa60 kasan_report+0xda/0x1b0 ? hci_enhanced_setup_sync+0x91b/0xa60 hci_enhanced_setup_sync+0x91b/0xa60 ? __pfx_hci_enhanced_setup_sync+0x10/0x10 ? __pfx___mutex_lock+0x10/0x10 hci_cmd_sync_work+0x1c2/0x330 process_one_work+0x7d9/0x1360 ? __pfx_lock_acquire+0x10/0x10 ? __pfx_process_one_work+0x10/0x10 ? assign_work+0x167/0x240 worker_thread+0x5b7/0xf60 ? __kthread_parkme+0xac/0x1c0 ? __pfx_worker_thread+0x10/0x10 ? __pfx_worker_thread+0x10/0x10 kthread+0x293/0x360 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2f/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 34: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __hci_conn_add+0x187/0x17d0 hci_connect_sco+0x2e1/0xb90 sco_sock_connect+0x2a2/0xb80 __sys_connect+0x227/0x2a0 __x64_sys_connect+0x6d/0xb0 do_syscall_64+0x71/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 37: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x101/0x160 kfree+0xd0/0x250 device_release+0x9a/0x210 kobject_put+0x151/0x280 hci_conn_del+0x448/0xbf0 hci_abort_conn_sync+0x46f/0x980 hci_cmd_sync_work+0x1c2/0x330 process_one_work+0x7d9/0x1360 worker_thread+0x5b7/0xf60 kthread+0x293/0x360 ret_from_fork+0x2f/0x70 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50030", "url": "https://ubuntu.com/security/CVE-2024-50030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/ct: prevent UAF in send_recv() Ensure we serialize with completion side to prevent UAF with fence going out of scope on the stack, since we have no clue if it will fire after the timeout before we can erase from the xa. Also we have some dependent loads and stores for which we need the correct ordering, and we lack the needed barriers. Fix this by grabbing the ct->lock after the wait, which is also held by the completion side. v2 (Badal): - Also print done after acquiring the lock and seeing timeout. (cherry picked from commit 52789ce35c55ccd30c4b67b9cc5b2af55e0122ea)", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50187", "url": "https://ubuntu.com/security/CVE-2024-50187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Stop the active perfmon before being destroyed Upon closing the file descriptor, the active performance monitor is not stopped. Although all perfmons are destroyed in `vc4_perfmon_close_file()`, the active performance monitor's pointer (`vc4->active_perfmon`) is still retained. If we open a new file descriptor and submit a few jobs with performance monitors, the driver will attempt to stop the active performance monitor using the stale pointer in `vc4->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50031", "url": "https://ubuntu.com/security/CVE-2024-50031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Stop the active perfmon before being destroyed When running `kmscube` with one or more performance monitors enabled via `GALLIUM_HUD`, the following kernel panic can occur: [ 55.008324] Unable to handle kernel paging request at virtual address 00000000052004a4 [ 55.008368] Mem abort info: [ 55.008377] ESR = 0x0000000096000005 [ 55.008387] EC = 0x25: DABT (current EL), IL = 32 bits [ 55.008402] SET = 0, FnV = 0 [ 55.008412] EA = 0, S1PTW = 0 [ 55.008421] FSC = 0x05: level 1 translation fault [ 55.008434] Data abort info: [ 55.008442] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 55.008455] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 55.008467] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 55.008481] user pgtable: 4k pages, 39-bit VAs, pgdp=00000001046c6000 [ 55.008497] [00000000052004a4] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 55.008525] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP [ 55.008542] Modules linked in: rfcomm [...] vc4 v3d snd_soc_hdmi_codec drm_display_helper gpu_sched drm_shmem_helper cec drm_dma_helper drm_kms_helper i2c_brcmstb drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight [ 55.008799] CPU: 2 PID: 166 Comm: v3d_bin Tainted: G C 6.6.47+rpt-rpi-v8 #1 Debian 1:6.6.47-1+rpt1 [ 55.008824] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [ 55.008838] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 55.008855] pc : __mutex_lock.constprop.0+0x90/0x608 [ 55.008879] lr : __mutex_lock.constprop.0+0x58/0x608 [ 55.008895] sp : ffffffc080673cf0 [ 55.008904] x29: ffffffc080673cf0 x28: 0000000000000000 x27: ffffff8106188a28 [ 55.008926] x26: ffffff8101e78040 x25: ffffff8101baa6c0 x24: ffffffd9d989f148 [ 55.008947] x23: ffffffda1c2a4008 x22: 0000000000000002 x21: ffffffc080673d38 [ 55.008968] x20: ffffff8101238000 x19: ffffff8104f83188 x18: 0000000000000000 [ 55.008988] x17: 0000000000000000 x16: ffffffda1bd04d18 x15: 00000055bb08bc90 [ 55.009715] x14: 0000000000000000 x13: 0000000000000000 x12: ffffffda1bd4cbb0 [ 55.010433] x11: 00000000fa83b2da x10: 0000000000001a40 x9 : ffffffda1bd04d04 [ 55.011162] x8 : ffffff8102097b80 x7 : 0000000000000000 x6 : 00000000030a5857 [ 55.011880] x5 : 00ffffffffffffff x4 : 0300000005200470 x3 : 0300000005200470 [ 55.012598] x2 : ffffff8101238000 x1 : 0000000000000021 x0 : 0300000005200470 [ 55.013292] Call trace: [ 55.013959] __mutex_lock.constprop.0+0x90/0x608 [ 55.014646] __mutex_lock_slowpath+0x1c/0x30 [ 55.015317] mutex_lock+0x50/0x68 [ 55.015961] v3d_perfmon_stop+0x40/0xe0 [v3d] [ 55.016627] v3d_bin_job_run+0x10c/0x2d8 [v3d] [ 55.017282] drm_sched_main+0x178/0x3f8 [gpu_sched] [ 55.017921] kthread+0x11c/0x128 [ 55.018554] ret_from_fork+0x10/0x20 [ 55.019168] Code: f9400260 f1001c1f 54001ea9 927df000 (b9403401) [ 55.019776] ---[ end trace 0000000000000000 ]--- [ 55.020411] note: v3d_bin[166] exited with preempt_count 1 This issue arises because, upon closing the file descriptor (which happens when we interrupt `kmscube`), the active performance monitor is not stopped. Although all perfmons are destroyed in `v3d_perfmon_close_file()`, the active performance monitor's pointer (`v3d->active_perfmon`) is still retained. If `kmscube` is run again, the driver will attempt to stop the active performance monitor using the stale pointer in `v3d->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50189", "url": "https://ubuntu.com/security/CVE-2024-50189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: amd_sfh: Switch to device-managed dmam_alloc_coherent() Using the device-managed version allows to simplify clean-up in probe() error path. Additionally, this device-managed ensures proper cleanup, which helps to resolve memory errors, page faults, btrfs going read-only, and btrfs disk corruption.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50033", "url": "https://ubuntu.com/security/CVE-2024-50033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slip: make slhc_remember() more robust against malicious packets syzbot found that slhc_remember() was missing checks against malicious packets [1]. slhc_remember() only checked the size of the packet was at least 20, which is not good enough. We need to make sure the packet includes the IPv4 and TCP header that are supposed to be carried. Add iph and th pointers to make the code more readable. [1] BUG: KMSAN: uninit-value in slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 ppp_receive_nonmp_frame+0xe45/0x35e0 drivers/net/ppp/ppp_generic.c:2455 ppp_receive_frame drivers/net/ppp/ppp_generic.c:2372 [inline] ppp_do_recv+0x65f/0x40d0 drivers/net/ppp/ppp_generic.c:2212 ppp_input+0x7dc/0xe60 drivers/net/ppp/ppp_generic.c:2327 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 Uninit was created at: slab_post_alloc_hook mm/slub.c:4091 [inline] slab_alloc_node mm/slub.c:4134 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 CPU: 0 UID: 0 PID: 5460 Comm: syz.2.33 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50034", "url": "https://ubuntu.com/security/CVE-2024-50034", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix lacks of icsk_syn_mss with IPPROTO_SMC Eric report a panic on IPPROTO_SMC, and give the facts that when INET_PROTOSW_ICSK was set, icsk->icsk_sync_mss must be set too. Bug: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000086000005 EC = 0x21: IABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault user pgtable: 4k pages, 48-bit VAs, pgdp=00000001195d1000 [0000000000000000] pgd=0800000109c46003, p4d=0800000109c46003, pud=0000000000000000 Internal error: Oops: 0000000086000005 [#1] PREEMPT SMP Modules linked in: CPU: 1 UID: 0 PID: 8037 Comm: syz.3.265 Not tainted 6.11.0-rc7-syzkaller-g5f5673607153 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0x0 lr : cipso_v4_sock_setattr+0x2a8/0x3c0 net/ipv4/cipso_ipv4.c:1910 sp : ffff80009b887a90 x29: ffff80009b887aa0 x28: ffff80008db94050 x27: 0000000000000000 x26: 1fffe0001aa6f5b3 x25: dfff800000000000 x24: ffff0000db75da00 x23: 0000000000000000 x22: ffff0000d8b78518 x21: 0000000000000000 x20: ffff0000d537ad80 x19: ffff0000d8b78000 x18: 1fffe000366d79ee x17: ffff8000800614a8 x16: ffff800080569b84 x15: 0000000000000001 x14: 000000008b336894 x13: 00000000cd96feaa x12: 0000000000000003 x11: 0000000000040000 x10: 00000000000020a3 x9 : 1fffe0001b16f0f1 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 000000000000003f x5 : 0000000000000040 x4 : 0000000000000001 x3 : 0000000000000000 x2 : 0000000000000002 x1 : 0000000000000000 x0 : ffff0000d8b78000 Call trace: 0x0 netlbl_sock_setattr+0x2e4/0x338 net/netlabel/netlabel_kapi.c:1000 smack_netlbl_add+0xa4/0x154 security/smack/smack_lsm.c:2593 smack_socket_post_create+0xa8/0x14c security/smack/smack_lsm.c:2973 security_socket_post_create+0x94/0xd4 security/security.c:4425 __sock_create+0x4c8/0x884 net/socket.c:1587 sock_create net/socket.c:1622 [inline] __sys_socket_create net/socket.c:1659 [inline] __sys_socket+0x134/0x340 net/socket.c:1706 __do_sys_socket net/socket.c:1720 [inline] __se_sys_socket net/socket.c:1718 [inline] __arm64_sys_socket+0x7c/0x94 net/socket.c:1718 __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:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 Code: ???????? ???????? ???????? ???????? (????????) ---[ end trace 0000000000000000 ]--- This patch add a toy implementation that performs a simple return to prevent such panic. This is because MSS can be set in sock_create_kern or smc_setsockopt, similar to how it's done in AF_SMC. However, for AF_SMC, there is currently no way to synchronize MSS within __sys_connect_file. This toy implementation lays the groundwork for us to support such feature for IPPROTO_SMC in the future.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50035", "url": "https://ubuntu.com/security/CVE-2024-50035", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: fix ppp_async_encode() illegal access syzbot reported an issue in ppp_async_encode() [1] In this case, pppoe_sendmsg() is called with a zero size. Then ppp_async_encode() is called with an empty skb. BUG: KMSAN: uninit-value in ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] BUG: KMSAN: uninit-value in ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_send+0x130/0x1b0 drivers/net/ppp/ppp_async.c:634 ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2280 [inline] ppp_input+0x1f1/0xe60 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 Uninit was created at: slab_post_alloc_hook mm/slub.c:4092 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4187 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 CPU: 1 UID: 0 PID: 5411 Comm: syz.1.14 Not tainted 6.12.0-rc1-syzkaller-00165-g360c1f1f24c6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50036", "url": "https://ubuntu.com/security/CVE-2024-50036", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: do not delay dst_entries_add() in dst_release() dst_entries_add() uses per-cpu data that might be freed at netns dismantle from ip6_route_net_exit() calling dst_entries_destroy() Before ip6_route_net_exit() can be called, we release all the dsts associated with this netns, via calls to dst_release(), which waits an rcu grace period before calling dst_destroy() dst_entries_add() use in dst_destroy() is racy, because dst_entries_destroy() could have been called already. Decrementing the number of dsts must happen sooner. Notes: 1) in CONFIG_XFRM case, dst_destroy() can call dst_release_immediate(child), this might also cause UAF if the child does not have DST_NOCOUNT set. IPSEC maintainers might take a look and see how to address this. 2) There is also discussion about removing this count of dst, which might happen in future kernels.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50037", "url": "https://ubuntu.com/security/CVE-2024-50037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/fbdev-dma: Only cleanup deferred I/O if necessary Commit 5a498d4d06d6 (\"drm/fbdev-dma: Only install deferred I/O if necessary\") initializes deferred I/O only if it is used. drm_fbdev_dma_fb_destroy() however calls fb_deferred_io_cleanup() unconditionally with struct fb_info.fbdefio == NULL. KASAN with the out-of-tree Apple silicon display driver posts following warning from __flush_work() of a random struct work_struct instead of the expected NULL pointer derefs. [ 22.053799] ------------[ cut here ]------------ [ 22.054832] WARNING: CPU: 2 PID: 1 at kernel/workqueue.c:4177 __flush_work+0x4d8/0x580 [ 22.056597] Modules linked in: uhid bnep uinput nls_ascii ip6_tables ip_tables i2c_dev loop fuse dm_multipath nfnetlink zram hid_magicmouse btrfs xor xor_neon brcmfmac_wcc raid6_pq hci_bcm4377 bluetooth brcmfmac hid_apple brcmutil nvmem_spmi_mfd simple_mfd_spmi dockchannel_hid cfg80211 joydev regmap_spmi nvme_apple ecdh_generic ecc macsmc_hid rfkill dwc3 appledrm snd_soc_macaudio macsmc_power nvme_core apple_isp phy_apple_atc apple_sart apple_rtkit_helper apple_dockchannel tps6598x macsmc_hwmon snd_soc_cs42l84 videobuf2_v4l2 spmi_apple_controller nvmem_apple_efuses videobuf2_dma_sg apple_z2 videobuf2_memops spi_nor panel_summit videobuf2_common asahi videodev pwm_apple apple_dcp snd_soc_apple_mca apple_admac spi_apple clk_apple_nco i2c_pasemi_platform snd_pcm_dmaengine mc i2c_pasemi_core mux_core ofpart adpdrm drm_dma_helper apple_dart apple_soc_cpufreq leds_pwm phram [ 22.073768] CPU: 2 UID: 0 PID: 1 Comm: systemd-shutdow Not tainted 6.11.2-asahi+ #asahi-dev [ 22.075612] Hardware name: Apple MacBook Pro (13-inch, M2, 2022) (DT) [ 22.077032] pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 22.078567] pc : __flush_work+0x4d8/0x580 [ 22.079471] lr : __flush_work+0x54/0x580 [ 22.080345] sp : ffffc000836ef820 [ 22.081089] x29: ffffc000836ef880 x28: 0000000000000000 x27: ffff80002ddb7128 [ 22.082678] x26: dfffc00000000000 x25: 1ffff000096f0c57 x24: ffffc00082d3e358 [ 22.084263] x23: ffff80004b7862b8 x22: dfffc00000000000 x21: ffff80005aa1d470 [ 22.085855] x20: ffff80004b786000 x19: ffff80004b7862a0 x18: 0000000000000000 [ 22.087439] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000005 [ 22.089030] x14: 1ffff800106ddf0a x13: 0000000000000000 x12: 0000000000000000 [ 22.090618] x11: ffffb800106ddf0f x10: dfffc00000000000 x9 : 1ffff800106ddf0e [ 22.092206] x8 : 0000000000000000 x7 : aaaaaaaaaaaaaaaa x6 : 0000000000000001 [ 22.093790] x5 : ffffc000836ef728 x4 : 0000000000000000 x3 : 0000000000000020 [ 22.095368] x2 : 0000000000000008 x1 : 00000000000000aa x0 : 0000000000000000 [ 22.096955] Call trace: [ 22.097505] __flush_work+0x4d8/0x580 [ 22.098330] flush_delayed_work+0x80/0xb8 [ 22.099231] fb_deferred_io_cleanup+0x3c/0x130 [ 22.100217] drm_fbdev_dma_fb_destroy+0x6c/0xe0 [drm_dma_helper] [ 22.101559] unregister_framebuffer+0x210/0x2f0 [ 22.102575] drm_fb_helper_unregister_info+0x48/0x60 [ 22.103683] drm_fbdev_dma_client_unregister+0x4c/0x80 [drm_dma_helper] [ 22.105147] drm_client_dev_unregister+0x1cc/0x230 [ 22.106217] drm_dev_unregister+0x58/0x570 [ 22.107125] apple_drm_unbind+0x50/0x98 [appledrm] [ 22.108199] component_del+0x1f8/0x3a8 [ 22.109042] dcp_platform_shutdown+0x24/0x38 [apple_dcp] [ 22.110357] platform_shutdown+0x70/0x90 [ 22.111219] device_shutdown+0x368/0x4d8 [ 22.112095] kernel_restart+0x6c/0x1d0 [ 22.112946] __arm64_sys_reboot+0x1c8/0x328 [ 22.113868] invoke_syscall+0x78/0x1a8 [ 22.114703] do_el0_svc+0x124/0x1a0 [ 22.115498] el0_svc+0x3c/0xe0 [ 22.116181] el0t_64_sync_handler+0x70/0xc0 [ 22.117110] el0t_64_sync+0x190/0x198 [ 22.117931] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50092", "url": "https://ubuntu.com/security/CVE-2024-50092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netconsole: fix wrong warning A warning is triggered when there is insufficient space in the buffer for userdata. However, this is not an issue since userdata will be sent in the next iteration. Current warning message: ------------[ cut here ]------------ WARNING: CPU: 13 PID: 3013042 at drivers/net/netconsole.c:1122 write_ext_msg+0x3b6/0x3d0 ? write_ext_msg+0x3b6/0x3d0 console_flush_all+0x1e9/0x330 The code incorrectly issues a warning when this_chunk is zero, which is a valid scenario. The warning should only be triggered when this_chunk is negative.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50038", "url": "https://ubuntu.com/security/CVE-2024-50038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xtables: avoid NFPROTO_UNSPEC where needed syzbot managed to call xt_cluster match via ebtables: WARNING: CPU: 0 PID: 11 at net/netfilter/xt_cluster.c:72 xt_cluster_mt+0x196/0x780 [..] ebt_do_table+0x174b/0x2a40 Module registers to NFPROTO_UNSPEC, but it assumes ipv4/ipv6 packet processing. As this is only useful to restrict locally terminating TCP/UDP traffic, register this for ipv4 and ipv6 family only. Pablo points out that this is a general issue, direct users of the set/getsockopt interface can call into targets/matches that were only intended for use with ip(6)tables. Check all UNSPEC matches and targets for similar issues: - matches and targets are fine except if they assume skb_network_header() is valid -- this is only true when called from inet layer: ip(6) stack pulls the ip/ipv6 header into linear data area. - targets that return XT_CONTINUE or other xtables verdicts must be restricted too, they are incompatbile with the ebtables traverser, e.g. EBT_CONTINUE is a completely different value than XT_CONTINUE. Most matches/targets are changed to register for NFPROTO_IPV4/IPV6, as they are provided for use by ip(6)tables. The MARK target is also used by arptables, so register for NFPROTO_ARP too. While at it, bail out if connbytes fails to enable the corresponding conntrack family. This change passes the selftests in iptables.git.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50039", "url": "https://ubuntu.com/security/CVE-2024-50039", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: accept TCA_STAB only for root qdisc Most qdiscs maintain their backlog using qdisc_pkt_len(skb) on the assumption it is invariant between the enqueue() and dequeue() handlers. Unfortunately syzbot can crash a host rather easily using a TBF + SFQ combination, with an STAB on SFQ [1] We can't support TCA_STAB on arbitrary level, this would require to maintain per-qdisc storage. [1] [ 88.796496] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 88.798611] #PF: supervisor read access in kernel mode [ 88.799014] #PF: error_code(0x0000) - not-present page [ 88.799506] PGD 0 P4D 0 [ 88.799829] Oops: Oops: 0000 [#1] SMP NOPTI [ 88.800569] CPU: 14 UID: 0 PID: 2053 Comm: b371744477 Not tainted 6.12.0-rc1-virtme #1117 [ 88.801107] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 88.801779] RIP: 0010:sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq [ 88.802544] Code: 0f b7 50 12 48 8d 04 d5 00 00 00 00 48 89 d6 48 29 d0 48 8b 91 c0 01 00 00 48 c1 e0 03 48 01 c2 66 83 7a 1a 00 7e c0 48 8b 3a <4c> 8b 07 4c 89 02 49 89 50 08 48 c7 47 08 00 00 00 00 48 c7 07 00 All code ======== 0:\t0f b7 50 12 \tmovzwl 0x12(%rax),%edx 4:\t48 8d 04 d5 00 00 00 \tlea 0x0(,%rdx,8),%rax b:\t00 c:\t48 89 d6 \tmov %rdx,%rsi f:\t48 29 d0 \tsub %rdx,%rax 12:\t48 8b 91 c0 01 00 00 \tmov 0x1c0(%rcx),%rdx 19:\t48 c1 e0 03 \tshl $0x3,%rax 1d:\t48 01 c2 \tadd %rax,%rdx 20:\t66 83 7a 1a 00 \tcmpw $0x0,0x1a(%rdx) 25:\t7e c0 \tjle 0xffffffffffffffe7 27:\t48 8b 3a \tmov (%rdx),%rdi 2a:*\t4c 8b 07 \tmov (%rdi),%r8\t\t<-- trapping instruction 2d:\t4c 89 02 \tmov %r8,(%rdx) 30:\t49 89 50 08 \tmov %rdx,0x8(%r8) 34:\t48 c7 47 08 00 00 00 \tmovq $0x0,0x8(%rdi) 3b:\t00 3c:\t48 \trex.W 3d:\tc7 \t.byte 0xc7 3e:\t07 \t(bad) \t... Code starting with the faulting instruction =========================================== 0:\t4c 8b 07 \tmov (%rdi),%r8 3:\t4c 89 02 \tmov %r8,(%rdx) 6:\t49 89 50 08 \tmov %rdx,0x8(%r8) a:\t48 c7 47 08 00 00 00 \tmovq $0x0,0x8(%rdi) 11:\t00 12:\t48 \trex.W 13:\tc7 \t.byte 0xc7 14:\t07 \t(bad) \t... [ 88.803721] RSP: 0018:ffff9a1f892b7d58 EFLAGS: 00000206 [ 88.804032] RAX: 0000000000000000 RBX: ffff9a1f8420c800 RCX: ffff9a1f8420c800 [ 88.804560] RDX: ffff9a1f81bc1440 RSI: 0000000000000000 RDI: 0000000000000000 [ 88.805056] RBP: ffffffffc04bb0e0 R08: 0000000000000001 R09: 00000000ff7f9a1f [ 88.805473] R10: 000000000001001b R11: 0000000000009a1f R12: 0000000000000140 [ 88.806194] R13: 0000000000000001 R14: ffff9a1f886df400 R15: ffff9a1f886df4ac [ 88.806734] FS: 00007f445601a740(0000) GS:ffff9a2e7fd80000(0000) knlGS:0000000000000000 [ 88.807225] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 88.807672] CR2: 0000000000000000 CR3: 000000050cc46000 CR4: 00000000000006f0 [ 88.808165] Call Trace: [ 88.808459] [ 88.808710] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434) [ 88.809261] ? page_fault_oops (arch/x86/mm/fault.c:715) [ 88.809561] ? exc_page_fault (./arch/x86/include/asm/irqflags.h:26 ./arch/x86/include/asm/irqflags.h:87 ./arch/x86/include/asm/irqflags.h:147 arch/x86/mm/fault.c:1489 arch/x86/mm/fault.c:1539) [ 88.809806] ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623) [ 88.810074] ? sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq [ 88.810411] sfq_reset (net/sched/sch_sfq.c:525) sch_sfq [ 88.810671] qdisc_reset (./include/linux/skbuff.h:2135 ./include/linux/skbuff.h:2441 ./include/linux/skbuff.h:3304 ./include/linux/skbuff.h:3310 net/sched/sch_g ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50040", "url": "https://ubuntu.com/security/CVE-2024-50040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: igb: Do not bring the device up after non-fatal error Commit 004d25060c78 (\"igb: Fix igb_down hung on surprise removal\") changed igb_io_error_detected() to ignore non-fatal pcie errors in order to avoid hung task that can happen when igb_down() is called multiple times. This caused an issue when processing transient non-fatal errors. igb_io_resume(), which is called after igb_io_error_detected(), assumes that device is brought down by igb_io_error_detected() if the interface is up. This resulted in panic with stacktrace below. [ T3256] igb 0000:09:00.0 haeth0: igb: haeth0 NIC Link is Down [ T292] pcieport 0000:00:1c.5: AER: Uncorrected (Non-Fatal) error received: 0000:09:00.0 [ T292] igb 0000:09:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, (Requester ID) [ T292] igb 0000:09:00.0: device [8086:1537] error status/mask=00004000/00000000 [ T292] igb 0000:09:00.0: [14] CmpltTO [ 200.105524,009][ T292] igb 0000:09:00.0: AER: TLP Header: 00000000 00000000 00000000 00000000 [ T292] pcieport 0000:00:1c.5: AER: broadcast error_detected message [ T292] igb 0000:09:00.0: Non-correctable non-fatal error reported. [ T292] pcieport 0000:00:1c.5: AER: broadcast mmio_enabled message [ T292] pcieport 0000:00:1c.5: AER: broadcast resume message [ T292] ------------[ cut here ]------------ [ T292] kernel BUG at net/core/dev.c:6539! [ T292] invalid opcode: 0000 [#1] PREEMPT SMP [ T292] RIP: 0010:napi_enable+0x37/0x40 [ T292] Call Trace: [ T292] [ T292] ? die+0x33/0x90 [ T292] ? do_trap+0xdc/0x110 [ T292] ? napi_enable+0x37/0x40 [ T292] ? do_error_trap+0x70/0xb0 [ T292] ? napi_enable+0x37/0x40 [ T292] ? napi_enable+0x37/0x40 [ T292] ? exc_invalid_op+0x4e/0x70 [ T292] ? napi_enable+0x37/0x40 [ T292] ? asm_exc_invalid_op+0x16/0x20 [ T292] ? napi_enable+0x37/0x40 [ T292] igb_up+0x41/0x150 [ T292] igb_io_resume+0x25/0x70 [ T292] report_resume+0x54/0x70 [ T292] ? report_frozen_detected+0x20/0x20 [ T292] pci_walk_bus+0x6c/0x90 [ T292] ? aer_print_port_info+0xa0/0xa0 [ T292] pcie_do_recovery+0x22f/0x380 [ T292] aer_process_err_devices+0x110/0x160 [ T292] aer_isr+0x1c1/0x1e0 [ T292] ? disable_irq_nosync+0x10/0x10 [ T292] irq_thread_fn+0x1a/0x60 [ T292] irq_thread+0xe3/0x1a0 [ T292] ? irq_set_affinity_notifier+0x120/0x120 [ T292] ? irq_affinity_notify+0x100/0x100 [ T292] kthread+0xe2/0x110 [ T292] ? kthread_complete_and_exit+0x20/0x20 [ T292] ret_from_fork+0x2d/0x50 [ T292] ? kthread_complete_and_exit+0x20/0x20 [ T292] ret_from_fork_asm+0x11/0x20 [ T292] To fix this issue igb_io_resume() checks if the interface is running and the device is not down this means igb_io_error_detected() did not bring the device down and there is no need to bring it up.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50041", "url": "https://ubuntu.com/security/CVE-2024-50041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: Fix macvlan leak by synchronizing access to mac_filter_hash This patch addresses a macvlan leak issue in the i40e driver caused by concurrent access to vsi->mac_filter_hash. The leak occurs when multiple threads attempt to modify the mac_filter_hash simultaneously, leading to inconsistent state and potential memory leaks. To fix this, we now wrap the calls to i40e_del_mac_filter() and zeroing vf->default_lan_addr.addr with spin_lock/unlock_bh(&vsi->mac_filter_hash_lock), ensuring atomic operations and preventing concurrent access. Additionally, we add lockdep_assert_held(&vsi->mac_filter_hash_lock) in i40e_add_mac_filter() to help catch similar issues in the future. Reproduction steps: 1. Spawn VFs and configure port vlan on them. 2. Trigger concurrent macvlan operations (e.g., adding and deleting \tportvlan and/or mac filters). 3. Observe the potential memory leak and inconsistent state in the \tmac_filter_hash. This synchronization ensures the integrity of the mac_filter_hash and prevents the described leak.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50042", "url": "https://ubuntu.com/security/CVE-2024-50042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix increasing MSI-X on VF Increasing MSI-X value on a VF leads to invalid memory operations. This is caused by not reallocating some arrays. Reproducer: modprobe ice echo 0 > /sys/bus/pci/devices/$PF_PCI/sriov_drivers_autoprobe echo 1 > /sys/bus/pci/devices/$PF_PCI/sriov_numvfs echo 17 > /sys/bus/pci/devices/$VF0_PCI/sriov_vf_msix_count Default MSI-X is 16, so 17 and above triggers this issue. KASAN reports: BUG: KASAN: slab-out-of-bounds in ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] Read of size 8 at addr ffff8888b937d180 by task bash/28433 (...) Call Trace: (...) ? ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] kasan_report+0xed/0x120 ? ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] ice_vsi_cfg_def+0x3360/0x4770 [ice] ? mutex_unlock+0x83/0xd0 ? __pfx_ice_vsi_cfg_def+0x10/0x10 [ice] ? __pfx_ice_remove_vsi_lkup_fltr+0x10/0x10 [ice] ice_vsi_cfg+0x7f/0x3b0 [ice] ice_vf_reconfig_vsi+0x114/0x210 [ice] ice_sriov_set_msix_vec_count+0x3d0/0x960 [ice] sriov_vf_msix_count_store+0x21c/0x300 (...) Allocated by task 28201: (...) ice_vsi_cfg_def+0x1c8e/0x4770 [ice] ice_vsi_cfg+0x7f/0x3b0 [ice] ice_vsi_setup+0x179/0xa30 [ice] ice_sriov_configure+0xcaa/0x1520 [ice] sriov_numvfs_store+0x212/0x390 (...) To fix it, use ice_vsi_rebuild() instead of ice_vf_reconfig_vsi(). This causes the required arrays to be reallocated taking the new queue count into account (ice_vsi_realloc_stat_arrays()). Set req_txq and req_rxq before ice_vsi_rebuild(), so that realloc uses the newly set queue count. Additionally, ice_vsi_rebuild() does not remove VSI filters (ice_fltr_remove_all()), so ice_vf_init_host_cfg() is no longer necessary.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50093", "url": "https://ubuntu.com/security/CVE-2024-50093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: intel: int340x: processor: Fix warning during module unload The processor_thermal driver uses pcim_device_enable() to enable a PCI device, which means the device will be automatically disabled on driver detach. Thus there is no need to call pci_disable_device() again on it. With recent PCI device resource management improvements, e.g. commit f748a07a0b64 (\"PCI: Remove legacy pcim_release()\"), this problem is exposed and triggers the warining below. [ 224.010735] proc_thermal_pci 0000:00:04.0: disabling already-disabled device [ 224.010747] WARNING: CPU: 8 PID: 4442 at drivers/pci/pci.c:2250 pci_disable_device+0xe5/0x100 ... [ 224.010844] Call Trace: [ 224.010845] [ 224.010847] ? show_regs+0x6d/0x80 [ 224.010851] ? __warn+0x8c/0x140 [ 224.010854] ? pci_disable_device+0xe5/0x100 [ 224.010856] ? report_bug+0x1c9/0x1e0 [ 224.010859] ? handle_bug+0x46/0x80 [ 224.010862] ? exc_invalid_op+0x1d/0x80 [ 224.010863] ? asm_exc_invalid_op+0x1f/0x30 [ 224.010867] ? pci_disable_device+0xe5/0x100 [ 224.010869] ? pci_disable_device+0xe5/0x100 [ 224.010871] ? kfree+0x21a/0x2b0 [ 224.010873] pcim_disable_device+0x20/0x30 [ 224.010875] devm_action_release+0x16/0x20 [ 224.010878] release_nodes+0x47/0xc0 [ 224.010880] devres_release_all+0x9f/0xe0 [ 224.010883] device_unbind_cleanup+0x12/0x80 [ 224.010885] device_release_driver_internal+0x1ca/0x210 [ 224.010887] driver_detach+0x4e/0xa0 [ 224.010889] bus_remove_driver+0x6f/0xf0 [ 224.010890] driver_unregister+0x35/0x60 [ 224.010892] pci_unregister_driver+0x44/0x90 [ 224.010894] proc_thermal_pci_driver_exit+0x14/0x5f0 [processor_thermal_device_pci] ... [ 224.010921] ---[ end trace 0000000000000000 ]--- Remove the excess pci_disable_device() calls. [ rjw: Subject and changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50043", "url": "https://ubuntu.com/security/CVE-2024-50043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix possible badness in FREE_STATEID When multiple FREE_STATEIDs are sent for the same delegation stateid, it can lead to a possible either use-after-free or counter refcount underflow errors. In nfsd4_free_stateid() under the client lock we find a delegation stateid, however the code drops the lock before calling nfs4_put_stid(), that allows another FREE_STATE to find the stateid again. The first one will proceed to then free the stateid which leads to either use-after-free or decrementing already zeroed counter.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50044", "url": "https://ubuntu.com/security/CVE-2024-50044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change rfcomm_sk_state_change attempts to use sock_lock so it must never be called with it locked but rfcomm_sock_ioctl always attempt to lock it causing the following trace: ====================================================== WARNING: possible circular locking dependency detected 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Not tainted ------------------------------------------------------ syz-executor386/5093 is trying to acquire lock: ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1671 [inline] ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73 but task is already holding lock: ffff88807badfd28 (&d->lock){+.+.}-{3:3}, at: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50045", "url": "https://ubuntu.com/security/CVE-2024-50045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: br_netfilter: fix panic with metadata_dst skb Fix a kernel panic in the br_netfilter module when sending untagged traffic via a VxLAN device. This happens during the check for fragmentation in br_nf_dev_queue_xmit. It is dependent on: 1) the br_netfilter module being loaded; 2) net.bridge.bridge-nf-call-iptables set to 1; 3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port; 4) untagged frames with size higher than the VxLAN MTU forwarded/flooded When forwarding the untagged packet to the VxLAN bridge port, before the netfilter hooks are called, br_handle_egress_vlan_tunnel is called and changes the skb_dst to the tunnel dst. The tunnel_dst is a metadata type of dst, i.e., skb_valid_dst(skb) is false, and metadata->dst.dev is NULL. Then in the br_netfilter hooks, in br_nf_dev_queue_xmit, there's a check for frames that needs to be fragmented: frames with higher MTU than the VxLAN device end up calling br_nf_ip_fragment, which in turns call ip_skb_dst_mtu. The ip_dst_mtu tries to use the skb_dst(skb) as if it was a valid dst with valid dst->dev, thus the crash. This case was never supported in the first place, so drop the packet instead. PING 10.0.0.2 (10.0.0.2) from 0.0.0.0 h1-eth0: 2000(2028) bytes of data. [ 176.291791] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000110 [ 176.292101] Mem abort info: [ 176.292184] ESR = 0x0000000096000004 [ 176.292322] EC = 0x25: DABT (current EL), IL = 32 bits [ 176.292530] SET = 0, FnV = 0 [ 176.292709] EA = 0, S1PTW = 0 [ 176.292862] FSC = 0x04: level 0 translation fault [ 176.293013] Data abort info: [ 176.293104] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 176.293488] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 176.293787] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 176.293995] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043ef5000 [ 176.294166] [0000000000000110] pgd=0000000000000000, p4d=0000000000000000 [ 176.294827] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 176.295252] Modules linked in: vxlan ip6_udp_tunnel udp_tunnel veth br_netfilter bridge stp llc ipv6 crct10dif_ce [ 176.295923] CPU: 0 PID: 188 Comm: ping Not tainted 6.8.0-rc3-g5b3fbd61b9d1 #2 [ 176.296314] Hardware name: linux,dummy-virt (DT) [ 176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 176.296808] pc : br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.297382] lr : br_nf_dev_queue_xmit+0x2ac/0x4ec [br_netfilter] [ 176.297636] sp : ffff800080003630 [ 176.297743] x29: ffff800080003630 x28: 0000000000000008 x27: ffff6828c49ad9f8 [ 176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24: 00000000000003e8 [ 176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21: ffff6828c3b16d28 [ 176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18: 0000000000000014 [ 176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15: 0000000095744632 [ 176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12: ffffb7e137926a70 [ 176.299574] x11: 0000000000000001 x10: ffff6828c3f1c898 x9 : 0000000000000000 [ 176.300049] x8 : ffff6828c49bf070 x7 : 0008460f18d5f20e x6 : f20e0100bebafeca [ 176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 : 0000000000000000 [ 176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 : ffff6828c7f918f0 [ 176.300889] Call trace: [ 176.301123] br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.301411] br_nf_post_routing+0x2a8/0x3e4 [br_netfilter] [ 176.301703] nf_hook_slow+0x48/0x124 [ 176.302060] br_forward_finish+0xc8/0xe8 [bridge] [ 176.302371] br_nf_hook_thresh+0x124/0x134 [br_netfilter] [ 176.302605] br_nf_forward_finish+0x118/0x22c [br_netfilter] [ 176.302824] br_nf_forward_ip.part.0+0x264/0x290 [br_netfilter] [ 176.303136] br_nf_forward+0x2b8/0x4e0 [br_netfilter] [ 176.303359] nf_hook_slow+0x48/0x124 [ 176.303 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50094", "url": "https://ubuntu.com/security/CVE-2024-50094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sfc: Don't invoke xdp_do_flush() from netpoll. Yury reported a crash in the sfc driver originated from netpoll_send_udp(). The netconsole sends a message and then netpoll invokes the driver's NAPI function with a budget of zero. It is dedicated to allow driver to free TX resources, that it may have used while sending the packet. In the netpoll case the driver invokes xdp_do_flush() unconditionally, leading to crash because bpf_net_context was never assigned. Invoke xdp_do_flush() only if budget is not zero.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50188", "url": "https://ubuntu.com/security/CVE-2024-50188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: dp83869: fix memory corruption when enabling fiber When configuring the fiber port, the DP83869 PHY driver incorrectly calls linkmode_set_bit() with a bit mask (1 << 10) rather than a bit number (10). This corrupts some other memory location -- in case of arm64 the priv pointer in the same structure. Since the advertising flags are updated from supported at the end of the function the incorrect line isn't needed at all and can be removed.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50046", "url": "https://ubuntu.com/security/CVE-2024-50046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies() On the node of an NFS client, some files saved in the mountpoint of the NFS server were copied to another location of the same NFS server. Accidentally, the nfs42_complete_copies() got a NULL-pointer dereference crash with the following syslog: [232064.838881] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232064.839360] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232066.588183] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 [232066.588586] Mem abort info: [232066.588701] ESR = 0x0000000096000007 [232066.588862] EC = 0x25: DABT (current EL), IL = 32 bits [232066.589084] SET = 0, FnV = 0 [232066.589216] EA = 0, S1PTW = 0 [232066.589340] FSC = 0x07: level 3 translation fault [232066.589559] Data abort info: [232066.589683] ISV = 0, ISS = 0x00000007 [232066.589842] CM = 0, WnR = 0 [232066.589967] user pgtable: 64k pages, 48-bit VAs, pgdp=00002000956ff400 [232066.590231] [0000000000000058] pgd=08001100ae100003, p4d=08001100ae100003, pud=08001100ae100003, pmd=08001100b3c00003, pte=0000000000000000 [232066.590757] Internal error: Oops: 96000007 [#1] SMP [232066.590958] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm vhost_net vhost vhost_iotlb tap tun ipt_rpfilter xt_multiport ip_set_hash_ip ip_set_hash_net xfrm_interface xfrm6_tunnel tunnel4 tunnel6 esp4 ah4 wireguard libcurve25519_generic veth xt_addrtype xt_set nf_conntrack_netlink ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_bitmap_port ip_set_hash_ipport dummy ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs iptable_filter sch_ingress nfnetlink_cttimeout vport_gre ip_gre ip_tunnel gre vport_geneve geneve vport_vxlan vxlan ip6_udp_tunnel udp_tunnel openvswitch nf_conncount dm_round_robin dm_service_time dm_multipath xt_nat xt_MASQUERADE nft_chain_nat nf_nat xt_mark xt_conntrack xt_comment nft_compat nft_counter nf_tables nfnetlink ocfs2 ocfs2_nodemanager ocfs2_stackglue iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_ssif nbd overlay 8021q garp mrp bonding tls rfkill sunrpc ext4 mbcache jbd2 [232066.591052] vfat fat cas_cache cas_disk ses enclosure scsi_transport_sas sg acpi_ipmi ipmi_si ipmi_devintf ipmi_msghandler ip_tables vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio dm_mirror dm_region_hash dm_log dm_mod nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc fuse xfs libcrc32c ast drm_vram_helper qla2xxx drm_kms_helper syscopyarea crct10dif_ce sysfillrect ghash_ce sysimgblt sha2_ce fb_sys_fops cec sha256_arm64 sha1_ce drm_ttm_helper ttm nvme_fc igb sbsa_gwdt nvme_fabrics drm nvme_core i2c_algo_bit i40e scsi_transport_fc megaraid_sas aes_neon_bs [232066.596953] CPU: 6 PID: 4124696 Comm: 10.253.166.125- Kdump: loaded Not tainted 5.15.131-9.cl9_ocfs2.aarch64 #1 [232066.597356] Hardware name: Great Wall .\\x93\\x8e...RF6260 V5/GWMSSE2GL1T, BIOS T656FBE_V3.0.18 2024-01-06 [232066.597721] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [232066.598034] pc : nfs4_reclaim_open_state+0x220/0x800 [nfsv4] [232066.598327] lr : nfs4_reclaim_open_state+0x12c/0x800 [nfsv4] [232066.598595] sp : ffff8000f568fc70 [232066.598731] x29: ffff8000f568fc70 x28: 0000000000001000 x27: ffff21003db33000 [232066.599030] x26: ffff800005521ae0 x25: ffff0100f98fa3f0 x24: 0000000000000001 [232066.599319] x23: ffff800009920008 x22: ffff21003db33040 x21: ffff21003db33050 [232066.599628] x20: ffff410172fe9e40 x19: ffff410172fe9e00 x18: 0000000000000000 [232066.599914] x17: 0000000000000000 x16: 0000000000000004 x15: 0000000000000000 [232066.600195] x14: 0000000000000000 x13: ffff800008e685a8 x12: 00000000eac0c6e6 [232066.600498] x11: 00000000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50190", "url": "https://ubuntu.com/security/CVE-2024-50190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix memleak in ice_init_tx_topology() Fix leak of the FW blob (DDP pkg). Make ice_cfg_tx_topo() const-correct, so ice_init_tx_topology() can avoid copying whole FW blob. Copy just the topology section, and only when needed. Reuse the buffer allocated for the read of the current topology. This was found by kmemleak, with the following trace for each PF: [] kmemdup_noprof+0x1d/0x50 [] ice_init_ddp_config+0x100/0x220 [ice] [] ice_init_dev+0x6f/0x200 [ice] [] ice_init+0x29/0x560 [ice] [] ice_probe+0x21d/0x310 [ice] Constify ice_cfg_tx_topo() @buf parameter. This cascades further down to few more functions.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50180", "url": "https://ubuntu.com/security/CVE-2024-50180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: sisfb: Fix strbuf array overflow The values of the variables xres and yres are placed in strbuf. These variables are obtained from strbuf1. The strbuf1 array contains digit characters and a space if the array contains non-digit characters. Then, when executing sprintf(strbuf, \"%ux%ux8\", xres, yres); more than 16 bytes will be written to strbuf. It is suggested to increase the size of the strbuf array to 24. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06: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": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50048", "url": "https://ubuntu.com/security/CVE-2024-50048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: Fix a NULL pointer dereference issue in fbcon_putcs syzbot has found a NULL pointer dereference bug in fbcon. Here is the simplified C reproducer: struct param { \tuint8_t type; \tstruct tiocl_selection ts; }; int main() { \tstruct fb_con2fbmap con2fb; \tstruct param param; \tint fd = open(\"/dev/fb1\", 0, 0); \tcon2fb.console = 0x19; \tcon2fb.framebuffer = 0; \tioctl(fd, FBIOPUT_CON2FBMAP, &con2fb); \tparam.type = 2; \tparam.ts.xs = 0; param.ts.ys = 0; \tparam.ts.xe = 0; param.ts.ye = 0; \tparam.ts.sel_mode = 0; \tint fd1 = open(\"/dev/tty1\", O_RDWR, 0); \tioctl(fd1, TIOCLINUX, ¶m); \tcon2fb.console = 1; \tcon2fb.framebuffer = 0; \tioctl(fd, FBIOPUT_CON2FBMAP, &con2fb); \treturn 0; } After calling ioctl(fd1, TIOCLINUX, ¶m), the subsequent ioctl(fd, FBIOPUT_CON2FBMAP, &con2fb) causes the kernel to follow a different execution path: set_con2fb_map -> con2fb_init_display -> fbcon_set_disp -> redraw_screen -> hide_cursor -> clear_selection -> highlight -> invert_screen -> do_update_region -> fbcon_putcs -> ops->putcs Since ops->putcs is a NULL pointer, this leads to a kernel panic. To prevent this, we need to call set_blitting_type() within set_con2fb_map() to properly initialize ops->putcs.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50049", "url": "https://ubuntu.com/security/CVE-2024-50049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before dereferencing se [WHAT & HOW] se is null checked previously in the same function, indicating it might be null; therefore, it must be checked when used again. This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50090", "url": "https://ubuntu.com/security/CVE-2024-50090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/oa: Fix overflow in oa batch buffer By default xe_bb_create_job() appends a MI_BATCH_BUFFER_END to batch buffer, this is not a problem if batch buffer is only used once but oa reuses the batch buffer for the same metric and at each call it appends a MI_BATCH_BUFFER_END, printing the warning below and then overflowing. [ 381.072016] ------------[ cut here ]------------ [ 381.072019] xe 0000:00:02.0: [drm] Assertion `bb->len * 4 + bb_prefetch(q->gt) <= size` failed! platform: LUNARLAKE subplatform: 1 graphics: Xe2_LPG / Xe2_HPG 20.04 step B0 media: Xe2_LPM / Xe2_HPM 20.00 step B0 tile: 0 VRAM 0 B GT: 0 type 1 So here checking if batch buffer already have MI_BATCH_BUFFER_END if not append it. v2: - simply fix, suggestion from Ashutosh (cherry picked from commit 9ba0e0f30ca42a98af3689460063edfb6315718a)", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50183", "url": "https://ubuntu.com/security/CVE-2024-50183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV instance Deleting an NPIV instance requires all fabric ndlps to be released before an NPIV's resources can be torn down. Failure to release fabric ndlps beforehand opens kref imbalance race conditions. Fix by forcing the DA_ID to complete synchronously with usage of wait_queue.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50055", "url": "https://ubuntu.com/security/CVE-2024-50055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: driver core: bus: Fix double free in driver API bus_register() For bus_register(), any error which happens after kset_register() will cause that @priv are freed twice, fixed by setting @priv with NULL after the first free.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50091", "url": "https://ubuntu.com/security/CVE-2024-50091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm vdo: don't refer to dedupe_context after releasing it Clear the dedupe_context pointer in a data_vio whenever ownership of the context is lost, so that vdo can't examine it accidentally.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50056", "url": "https://ubuntu.com/security/CVE-2024-50056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: Fix ERR_PTR dereference in uvc_v4l2.c Fix potential dereferencing of ERR_PTR() in find_format_by_pix() and uvc_v4l2_enum_format(). Fix the following smatch errors: drivers/usb/gadget/function/uvc_v4l2.c:124 find_format_by_pix() error: 'fmtdesc' dereferencing possible ERR_PTR() drivers/usb/gadget/function/uvc_v4l2.c:392 uvc_v4l2_enum_format() error: 'fmtdesc' dereferencing possible ERR_PTR() Also, fix similar issue in uvc_v4l2_try_format() for potential dereferencing of ERR_PTR().", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50184", "url": "https://ubuntu.com/security/CVE-2024-50184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_pmem: Check device status before requesting flush If a pmem device is in a bad status, the driver side could wait for host ack forever in virtio_pmem_flush(), causing the system to hang. So add a status check in the beginning of virtio_pmem_flush() to return early if the device is not activated.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50057", "url": "https://ubuntu.com/security/CVE-2024-50057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: tipd: Free IRQ only if it was requested before In polling mode, if no IRQ was requested there is no need to free it. Call devm_free_irq() only if client->irq is set. This fixes the warning caused by the tps6598x module removal: WARNING: CPU: 2 PID: 333 at kernel/irq/devres.c:144 devm_free_irq+0x80/0x8c ... ... Call trace: devm_free_irq+0x80/0x8c tps6598x_remove+0x28/0x88 [tps6598x] i2c_device_remove+0x2c/0x9c device_remove+0x4c/0x80 device_release_driver_internal+0x1cc/0x228 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 i2c_del_driver+0x54/0x64 tps6598x_i2c_driver_exit+0x18/0xc3c [tps6598x] __arm64_sys_delete_module+0x184/0x264 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc8/0xe8 do_el0_svc+0x20/0x2c el0_svc+0x28/0x98 el0t_64_sync_handler+0x13c/0x158 el0t_64_sync+0x190/0x194", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50058", "url": "https://ubuntu.com/security/CVE-2024-50058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: protect uart_port_dtr_rts() in uart_shutdown() too Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part 3) added few uport == NULL checks. It added one to uart_shutdown(), so the commit assumes, uport can be NULL in there. But right after that protection, there is an unprotected \"uart_port_dtr_rts(uport, false);\" call. That is invoked only if HUPCL is set, so I assume that is the reason why we do not see lots of these reports. Or it cannot be NULL at this point at all for some reason :P. Until the above is investigated, stay on the safe side and move this dereference to the if too. I got this inconsistency from Coverity under CID 1585130. Thanks.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50181", "url": "https://ubuntu.com/security/CVE-2024-50181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: imx: Remove CLK_SET_PARENT_GATE for DRAM mux for i.MX7D For i.MX7D DRAM related mux clock, the clock source change should ONLY be done done in low level asm code without accessing DRAM, and then calling clk API to sync the HW clock status with clk tree, it should never touch real clock source switch via clk API, so CLK_SET_PARENT_GATE flag should NOT be added, otherwise, DRAM's clock parent will be disabled when DRAM is active, and system will hang.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50059", "url": "https://ubuntu.com/security/CVE-2024-50059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntb: ntb_hw_switchtec: Fix use after free vulnerability in switchtec_ntb_remove due to race condition In the switchtec_ntb_add function, it can call switchtec_ntb_init_sndev function, then &sndev->check_link_status_work is bound with check_link_status_work. switchtec_ntb_link_notification may be called to start the work. If we remove the module which will call switchtec_ntb_remove to make cleanup, it will free sndev through kfree(sndev), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | check_link_status_work switchtec_ntb_remove | kfree(sndev); | | if (sndev->link_force_down) | // use sndev Fix it by ensuring that the work is canceled before proceeding with the cleanup in switchtec_ntb_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50060", "url": "https://ubuntu.com/security/CVE-2024-50060", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring: check if we need to reschedule during overflow flush In terms of normal application usage, this list will always be empty. And if an application does overflow a bit, it'll have a few entries. However, nothing obviously prevents syzbot from running a test case that generates a ton of overflow entries, and then flushing them can take quite a while. Check for needing to reschedule while flushing, and drop our locks and do so if necessary. There's no state to maintain here as overflows always prune from head-of-list, hence it's fine to drop and reacquire the locks at the end of the loop.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50061", "url": "https://ubuntu.com/security/CVE-2024-50061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: cdns: Fix use after free vulnerability in cdns_i3c_master Driver Due to Race Condition In the cdns_i3c_master_probe function, &master->hj_work is bound with cdns_i3c_master_hj. And cdns_i3c_master_interrupt can call cnds_i3c_master_demux_ibis function to start the work. If we remove the module which will call cdns_i3c_master_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | cdns_i3c_master_hj cdns_i3c_master_remove | i3c_master_unregister(&master->base) | device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in cdns_i3c_master_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50062", "url": "https://ubuntu.com/security/CVE-2024-50062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-srv: Avoid null pointer deref during path establishment For RTRS path establishment, RTRS client initiates and completes con_num of connections. After establishing all its connections, the information is exchanged between the client and server through the info_req message. During this exchange, it is essential that all connections have been established, and the state of the RTRS srv path is CONNECTED. So add these sanity checks, to make sure we detect and abort process in error scenarios to avoid null pointer deref.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50095", "url": "https://ubuntu.com/security/CVE-2024-50095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mad: Improve handling of timed out WRs of mad agent Current timeout handler of mad agent acquires/releases mad_agent_priv lock for every timed out WRs. This causes heavy locking contention when higher no. of WRs are to be handled inside timeout handler. This leads to softlockup with below trace in some use cases where rdma-cm path is used to establish connection between peer nodes Trace: ----- BUG: soft lockup - CPU#4 stuck for 26s! [kworker/u128:3:19767] CPU: 4 PID: 19767 Comm: kworker/u128:3 Kdump: loaded Tainted: G OE ------- --- 5.14.0-427.13.1.el9_4.x86_64 #1 Hardware name: Dell Inc. PowerEdge R740/01YM03, BIOS 2.4.8 11/26/2019 Workqueue: ib_mad1 timeout_sends [ib_core] RIP: 0010:__do_softirq+0x78/0x2ac RSP: 0018:ffffb253449e4f98 EFLAGS: 00000246 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 000000000000001f RDX: 000000000000001d RSI: 000000003d1879ab RDI: fff363b66fd3a86b RBP: ffffb253604cbcd8 R08: 0000009065635f3b R09: 0000000000000000 R10: 0000000000000040 R11: ffffb253449e4ff8 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000040 FS: 0000000000000000(0000) GS:ffff8caa1fc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd9ec9db900 CR3: 0000000891934006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? __irq_exit_rcu+0xa1/0xc0 ? watchdog_timer_fn+0x1b2/0x210 ? __pfx_watchdog_timer_fn+0x10/0x10 ? __hrtimer_run_queues+0x127/0x2c0 ? hrtimer_interrupt+0xfc/0x210 ? __sysvec_apic_timer_interrupt+0x5c/0x110 ? sysvec_apic_timer_interrupt+0x37/0x90 ? asm_sysvec_apic_timer_interrupt+0x16/0x20 ? __do_softirq+0x78/0x2ac ? __do_softirq+0x60/0x2ac __irq_exit_rcu+0xa1/0xc0 sysvec_call_function_single+0x72/0x90 asm_sysvec_call_function_single+0x16/0x20 RIP: 0010:_raw_spin_unlock_irq+0x14/0x30 RSP: 0018:ffffb253604cbd88 EFLAGS: 00000247 RAX: 000000000001960d RBX: 0000000000000002 RCX: ffff8cad2a064800 RDX: 000000008020001b RSI: 0000000000000001 RDI: ffff8cad5d39f66c RBP: ffff8cad5d39f600 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8caa443e0c00 R11: ffffb253604cbcd8 R12: ffff8cacb8682538 R13: 0000000000000005 R14: ffffb253604cbd90 R15: ffff8cad5d39f66c cm_process_send_error+0x122/0x1d0 [ib_cm] timeout_sends+0x1dd/0x270 [ib_core] process_one_work+0x1e2/0x3b0 ? __pfx_worker_thread+0x10/0x10 worker_thread+0x50/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xdd/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x50 Simplified timeout handler by creating local list of timed out WRs and invoke send handler post creating the list. The new method acquires/ releases lock once to fetch the list and hence helps to reduce locking contetiong when processing higher no. of WRs", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50063", "url": "https://ubuntu.com/security/CVE-2024-50063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Prevent tail call between progs attached to different hooks bpf progs can be attached to kernel functions, and the attached functions can take different parameters or return different return values. If prog attached to one kernel function tail calls prog attached to another kernel function, the ctx access or return value verification could be bypassed. For example, if prog1 is attached to func1 which takes only 1 parameter and prog2 is attached to func2 which takes two parameters. Since verifier assumes the bpf ctx passed to prog2 is constructed based on func2's prototype, verifier allows prog2 to access the second parameter from the bpf ctx passed to it. The problem is that verifier does not prevent prog1 from passing its bpf ctx to prog2 via tail call. In this case, the bpf ctx passed to prog2 is constructed from func1 instead of func2, that is, the assumption for ctx access verification is bypassed. Another example, if BPF LSM prog1 is attached to hook file_alloc_security, and BPF LSM prog2 is attached to hook bpf_lsm_audit_rule_known. Verifier knows the return value rules for these two hooks, e.g. it is legal for bpf_lsm_audit_rule_known to return positive number 1, and it is illegal for file_alloc_security to return positive number. So verifier allows prog2 to return positive number 1, but does not allow prog1 to return positive number. The problem is that verifier does not prevent prog1 from calling prog2 via tail call. In this case, prog2's return value 1 will be used as the return value for prog1's hook file_alloc_security. That is, the return value rule is bypassed. This patch adds restriction for tail call to prevent such bypasses.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50191", "url": "https://ubuntu.com/security/CVE-2024-50191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: don't set SB_RDONLY after filesystem errors When the filesystem is mounted with errors=remount-ro, we were setting SB_RDONLY flag to stop all filesystem modifications. We knew this misses proper locking (sb->s_umount) and does not go through proper filesystem remount procedure but it has been the way this worked since early ext2 days and it was good enough for catastrophic situation damage mitigation. Recently, syzbot has found a way (see link) to trigger warnings in filesystem freezing because the code got confused by SB_RDONLY changing under its hands. Since these days we set EXT4_FLAGS_SHUTDOWN on the superblock which is enough to stop all filesystem modifications, modifying SB_RDONLY shouldn't be needed. So stop doing that.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50064", "url": "https://ubuntu.com/security/CVE-2024-50064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: zram: free secondary algorithms names We need to kfree() secondary algorithms names when reset zram device that had multi-streams, otherwise we leak memory. [senozhatsky@chromium.org: kfree(NULL) is legal] Link: https://lkml.kernel.org/r/20240917013021.868769-1-senozhatsky@chromium.org", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50065", "url": "https://ubuntu.com/security/CVE-2024-50065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Change to non-blocking allocation in ntfs_d_hash d_hash is done while under \"rcu-walk\" and should not sleep. __get_name() allocates using GFP_KERNEL, having the possibility to sleep when under memory pressure. Change the allocation to GFP_NOWAIT.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50089", "url": "https://ubuntu.com/security/CVE-2024-50089", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-49863", "url": "https://ubuntu.com/security/CVE-2024-49863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost/scsi: null-ptr-dereference in vhost_scsi_get_req() Since commit 3f8ca2e115e5 (\"vhost/scsi: Extract common handling code from control queue handler\") a null pointer dereference bug can be triggered when guest sends an SCSI AN request. In vhost_scsi_ctl_handle_vq(), `vc.target` is assigned with `&v_req.tmf.lun[1]` within a switch-case block and is then passed to vhost_scsi_get_req() which extracts `vc->req` and `tpg`. However, for a `VIRTIO_SCSI_T_AN_*` request, tpg is not required, so `vc.target` is set to NULL in this branch. Later, in vhost_scsi_get_req(), `vc->target` is dereferenced without being checked, leading to a null pointer dereference bug. This bug can be triggered from guest. When this bug occurs, the vhost_worker process is killed while holding `vq->mutex` and the corresponding tpg will remain occupied indefinitely. Below is the KASAN report: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 PID: 840 Comm: poc Not tainted 6.10.0+ #1 Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:vhost_scsi_get_req+0x165/0x3a0 Code: 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 02 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 65 30 4c 89 e2 48 c1 ea 03 <0f> b6 04 02 4c 89 e2 83 e2 07 38 d0 7f 08 84 c0 0f 85 be 01 00 00 RSP: 0018:ffff888017affb50 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffff88801b000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888017affcb8 RBP: ffff888017affb80 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff888017affc88 R14: ffff888017affd1c R15: ffff888017993000 FS: 000055556e076500(0000) GS:ffff88806b100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200027c0 CR3: 0000000010ed0004 CR4: 0000000000370ef0 Call Trace: ? show_regs+0x86/0xa0 ? die_addr+0x4b/0xd0 ? exc_general_protection+0x163/0x260 ? asm_exc_general_protection+0x27/0x30 ? vhost_scsi_get_req+0x165/0x3a0 vhost_scsi_ctl_handle_vq+0x2a4/0xca0 ? __pfx_vhost_scsi_ctl_handle_vq+0x10/0x10 ? __switch_to+0x721/0xeb0 ? __schedule+0xda5/0x5710 ? __kasan_check_write+0x14/0x30 ? _raw_spin_lock+0x82/0xf0 vhost_scsi_ctl_handle_kick+0x52/0x90 vhost_run_work_list+0x134/0x1b0 vhost_task_fn+0x121/0x350 ... ---[ end trace 0000000000000000 ]--- Let's add a check in vhost_scsi_get_req. [whitespace fixes]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49864", "url": "https://ubuntu.com/security/CVE-2024-49864", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix a race between socket set up and I/O thread creation In rxrpc_open_socket(), it sets up the socket and then sets up the I/O thread that will handle it. This is a problem, however, as there's a gap between the two phases in which a packet may come into rxrpc_encap_rcv() from the UDP packet but we oops when trying to wake the not-yet created I/O thread. As a quick fix, just make rxrpc_encap_rcv() discard the packet if there's no I/O thread yet. A better, but more intrusive fix would perhaps be to rearrange things such that the socket creation is done by the I/O thread.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49865", "url": "https://ubuntu.com/security/CVE-2024-49865", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: move xa_alloc to prevent UAF Evil user can guess the next id of the vm before the ioctl completes and then call vm destroy ioctl to trigger UAF since create ioctl is still referencing the same vm. Move the xa_alloc all the way to the end to prevent this. v2: - Rebase (cherry picked from commit dcfd3971327f3ee92765154baebbaece833d3ca9)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49955", "url": "https://ubuntu.com/security/CVE-2024-49955", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: battery: Fix possible crash when unregistering a battery hook When a battery hook returns an error when adding a new battery, then the battery hook is automatically unregistered. However the battery hook provider cannot know that, so it will later call battery_hook_unregister() on the already unregistered battery hook, resulting in a crash. Fix this by using the list head to mark already unregistered battery hooks as already being unregistered so that they can be ignored by battery_hook_unregister().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49973", "url": "https://ubuntu.com/security/CVE-2024-49973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: r8169: add tally counter fields added with RTL8125 RTL8125 added fields to the tally counter, what may result in the chip dma'ing these new fields to unallocated memory. Therefore make sure that the allocated memory area is big enough to hold all of the tally counter values, even if we use only parts of it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49974", "url": "https://ubuntu.com/security/CVE-2024-49974", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Limit the number of concurrent async COPY operations Nothing appears to limit the number of concurrent async COPY operations that clients can start. In addition, AFAICT each async COPY can copy an unlimited number of 4MB chunks, so can run for a long time. Thus IMO async COPY can become a DoS vector. Add a restriction mechanism that bounds the number of concurrent background COPY operations. Start simple and try to be fair -- this patch implements a per-namespace limit. An async COPY request that occurs while this limit is exceeded gets NFS4ERR_DELAY. The requesting client can choose to send the request again after a delay or fall back to a traditional read/write style copy. If there is need to make the mechanism more sophisticated, we can visit that in future patches.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49975", "url": "https://ubuntu.com/security/CVE-2024-49975", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uprobes: fix kernel info leak via \"[uprobes]\" vma xol_add_vma() maps the uninitialized page allocated by __create_xol_area() into userspace. On some architectures (x86) this memory is readable even without VM_READ, VM_EXEC results in the same pgprot_t as VM_EXEC|VM_READ, although this doesn't really matter, debugger can read this memory anyway.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50003", "url": "https://ubuntu.com/security/CVE-2024-50003", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix system hang while resume with TBT monitor [Why] Connected with a Thunderbolt monitor and do the suspend and the system may hang while resume. The TBT monitor HPD will be triggered during the resume procedure and call the drm_client_modeset_probe() while struct drm_connector connector->dev->master is NULL. It will mess up the pipe topology after resume. [How] Skip the TBT monitor HPD during the resume procedure because we currently will probe the connectors after resume by default. (cherry picked from commit 453f86a26945207a16b8f66aaed5962dc2b95b85)", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50173", "url": "https://ubuntu.com/security/CVE-2024-50173", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix access to uninitialized variable in tick_ctx_cleanup() The group variable can't be used to retrieve ptdev in our second loop, because it points to the previously iterated list_head, not a valid group. Get the ptdev object from the scheduler instead.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49866", "url": "https://ubuntu.com/security/CVE-2024-49866", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Fix a race during cpuhp processing There is another found exception that the \"timerlat/1\" thread was scheduled on CPU0, and lead to timer corruption finally: ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ``` After tracing the scheduling event, it was discovered that the migration of the \"timerlat/1\" thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() | To fix this, skip online processing if the CPU is already offline.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49976", "url": "https://ubuntu.com/security/CVE-2024-49976", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Drop interface_lock in stop_kthread() stop_kthread() is the offline callback for \"trace/osnoise:online\", since commit 5bfbcd1ee57b (\"tracing/timerlat: Add interface_lock around clearing of kthread in stop_kthread()\"), the following ABBA deadlock scenario is introduced: T1 | T2 [BP] | T3 [AP] osnoise_hotplug_workfn() | work_for_cpu_fn() | cpuhp_thread_fun() | _cpu_down() | osnoise_cpu_die() mutex_lock(&interface_lock) | | stop_kthread() | cpus_write_lock() | mutex_lock(&interface_lock) cpus_read_lock() | cpuhp_kick_ap() | As the interface_lock here in just for protecting the \"kthread\" field of the osn_var, use xchg() instead to fix this issue. Also use for_each_online_cpu() back in stop_per_cpu_kthreads() as it can take cpu_read_lock() again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50005", "url": "https://ubuntu.com/security/CVE-2024-50005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: Fix potential RCU dereference issue in mac802154_scan_worker In the `mac802154_scan_worker` function, the `scan_req->type` field was accessed after the RCU read-side critical section was unlocked. According to RCU usage rules, this is illegal and can lead to unpredictable behavior, such as accessing memory that has been updated or causing use-after-free issues. This possible bug was identified using a static analysis tool developed by myself, specifically designed to detect RCU-related issues. To address this, the `scan_req->type` value is now stored in a local variable `scan_req_type` while still within the RCU read-side critical section. The `scan_req_type` is then used after the RCU lock is released, ensuring that the type value is safely accessed without violating RCU rules.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50012", "url": "https://ubuntu.com/security/CVE-2024-50012", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: Avoid a bad reference count on CPU node In the parse_perf_domain function, if the call to of_parse_phandle_with_args returns an error, then the reference to the CPU device node that was acquired at the start of the function would not be properly decremented. Address this by declaring the variable with the __free(device_node) cleanup attribute.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49867", "url": "https://ubuntu.com/security/CVE-2024-49867", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: wait for fixup workers before stopping cleaner kthread during umount During unmount, at close_ctree(), we have the following steps in this order: 1) Park the cleaner kthread - this doesn't destroy the kthread, it basically halts its execution (wake ups against it work but do nothing); 2) We stop the cleaner kthread - this results in freeing the respective struct task_struct; 3) We call btrfs_stop_all_workers() which waits for any jobs running in all the work queues and then free the work queues. Syzbot reported a case where a fixup worker resulted in a crash when doing a delayed iput on its inode while attempting to wake up the cleaner at btrfs_add_delayed_iput(), because the task_struct of the cleaner kthread was already freed. This can happen during unmount because we don't wait for any fixup workers still running before we call kthread_stop() against the cleaner kthread, which stops and free all its resources. Fix this by waiting for any fixup workers at close_ctree() before we call kthread_stop() against the cleaner and run pending delayed iputs. The stack traces reported by syzbot were the following: BUG: KASAN: slab-use-after-free in __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 Read of size 8 at addr ffff8880272a8a18 by task kworker/u8:3/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.12.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: btrfs-fixup btrfs_work_helper 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 __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline] try_to_wake_up+0xb0/0x1480 kernel/sched/core.c:4154 btrfs_writepage_fixup_worker+0xc16/0xdf0 fs/btrfs/inode.c:2842 btrfs_work_helper+0x390/0xc50 fs/btrfs/async-thread.c:314 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Allocated by task 2: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:319 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345 kasan_slab_alloc include/linux/kasan.h:247 [inline] slab_post_alloc_hook mm/slub.c:4086 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4187 alloc_task_struct_node kernel/fork.c:180 [inline] dup_task_struct+0x57/0x8c0 kernel/fork.c:1107 copy_process+0x5d1/0x3d50 kernel/fork.c:2206 kernel_clone+0x223/0x880 kernel/fork.c:2787 kernel_thread+0x1bc/0x240 kernel/fork.c:2849 create_kthread kernel/kthread.c:412 [inline] kthreadd+0x60d/0x810 kernel/kthread.c:765 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Freed by task 61: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:230 [inline] slab_free_h ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49868", "url": "https://ubuntu.com/security/CVE-2024-49868", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix a NULL pointer dereference when failed to start a new trasacntion [BUG] Syzbot reported a NULL pointer dereference with the following crash: FAULT_INJECTION: forcing a failure. start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676 prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642 relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678 ... BTRFS info (device loop0): balance: ended with status: -12 Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667] RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926 Call Trace: commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496 btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430 del_balance_item fs/btrfs/volumes.c:3678 [inline] reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742 btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574 btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673 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/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [CAUSE] The allocation failure happens at the start_transaction() inside prepare_to_relocate(), and during the error handling we call unset_reloc_control(), which makes fs_info->balance_ctl to be NULL. Then we continue the error path cleanup in btrfs_balance() by calling reset_balance_state() which will call del_balance_item() to fully delete the balance item in the root tree. However during the small window between set_reloc_contrl() and unset_reloc_control(), we can have a subvolume tree update and created a reloc_root for that subvolume. Then we go into the final btrfs_commit_transaction() of del_balance_item(), and into btrfs_update_reloc_root() inside commit_fs_roots(). That function checks if fs_info->reloc_ctl is in the merge_reloc_tree stage, but since fs_info->reloc_ctl is NULL, it results a NULL pointer dereference. [FIX] Just add extra check on fs_info->reloc_ctl inside btrfs_update_reloc_root(), before checking fs_info->reloc_ctl->merge_reloc_tree. That DEAD_RELOC_TREE handling is to prevent further modification to the reloc tree during merge stage, but since there is no reloc_ctl at all, we do not need to bother that.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49869", "url": "https://ubuntu.com/security/CVE-2024-49869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: send: fix buffer overflow detection when copying path to cache entry Starting with commit c0247d289e73 (\"btrfs: send: annotate struct name_cache_entry with __counted_by()\") we annotated the variable length array \"name\" from the name_cache_entry structure with __counted_by() to improve overflow detection. However that alone was not correct, because the length of that array does not match the \"name_len\" field - it matches that plus 1 to include the NUL string terminator, so that makes a fortified kernel think there's an overflow and report a splat like this: strcpy: detected buffer overflow: 20 byte write of buffer size 19 WARNING: CPU: 3 PID: 3310 at __fortify_report+0x45/0x50 CPU: 3 UID: 0 PID: 3310 Comm: btrfs Not tainted 6.11.0-prnet #1 Hardware name: CompuLab Ltd. sbc-ihsw/Intense-PC2 (IPC2), BIOS IPC2_3.330.7 X64 03/15/2018 RIP: 0010:__fortify_report+0x45/0x50 Code: 48 8b 34 (...) RSP: 0018:ffff97ebc0d6f650 EFLAGS: 00010246 RAX: 7749924ef60fa600 RBX: ffff8bf5446a521a RCX: 0000000000000027 RDX: 00000000ffffdfff RSI: ffff97ebc0d6f548 RDI: ffff8bf84e7a1cc8 RBP: ffff8bf548574080 R08: ffffffffa8c40e10 R09: 0000000000005ffd R10: 0000000000000004 R11: ffffffffa8c70e10 R12: ffff8bf551eef400 R13: 0000000000000000 R14: 0000000000000013 R15: 00000000000003a8 FS: 00007fae144de8c0(0000) GS:ffff8bf84e780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fae14691690 CR3: 00000001027a2003 CR4: 00000000001706f0 Call Trace: ? __warn+0x12a/0x1d0 ? __fortify_report+0x45/0x50 ? report_bug+0x154/0x1c0 ? handle_bug+0x42/0x70 ? exc_invalid_op+0x1a/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? __fortify_report+0x45/0x50 __fortify_panic+0x9/0x10 __get_cur_name_and_parent+0x3bc/0x3c0 get_cur_path+0x207/0x3b0 send_extent_data+0x709/0x10d0 ? find_parent_nodes+0x22df/0x25d0 ? mas_nomem+0x13/0x90 ? mtree_insert_range+0xa5/0x110 ? btrfs_lru_cache_store+0x5f/0x1e0 ? iterate_extent_inodes+0x52d/0x5a0 process_extent+0xa96/0x11a0 ? __pfx_lookup_backref_cache+0x10/0x10 ? __pfx_store_backref_cache+0x10/0x10 ? __pfx_iterate_backrefs+0x10/0x10 ? __pfx_check_extent_item+0x10/0x10 changed_cb+0x6fa/0x930 ? tree_advance+0x362/0x390 ? memcmp_extent_buffer+0xd7/0x160 send_subvol+0xf0a/0x1520 btrfs_ioctl_send+0x106b/0x11d0 ? __pfx___clone_root_cmp_sort+0x10/0x10 _btrfs_ioctl_send+0x1ac/0x240 btrfs_ioctl+0x75b/0x850 __se_sys_ioctl+0xca/0x150 do_syscall_64+0x85/0x160 ? __count_memcg_events+0x69/0x100 ? handle_mm_fault+0x1327/0x15c0 ? __se_sys_rt_sigprocmask+0xf1/0x180 ? syscall_exit_to_user_mode+0x75/0xa0 ? do_syscall_64+0x91/0x160 ? do_user_addr_fault+0x21d/0x630 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fae145eeb4f Code: 00 48 89 (...) RSP: 002b:00007ffdf1cb09b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fae145eeb4f RDX: 00007ffdf1cb0ad0 RSI: 0000000040489426 RDI: 0000000000000004 RBP: 00000000000078fe R08: 00007fae144006c0 R09: 00007ffdf1cb0927 R10: 0000000000000008 R11: 0000000000000246 R12: 00007ffdf1cb1ce8 R13: 0000000000000003 R14: 000055c499fab2e0 R15: 0000000000000004 Fix this by not storing the NUL string terminator since we don't actually need it for name cache entries, this way \"name_len\" corresponds to the actual size of the \"name\" array. This requires marking the \"name\" array field with __nonstring and using memcpy() instead of strcpy() as recommended by the guidelines at: https://github.com/KSPP/linux/issues/90", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49870", "url": "https://ubuntu.com/security/CVE-2024-49870", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cachefiles: fix dentry leak in cachefiles_open_file() A dentry leak may be caused when a lookup cookie and a cull are concurrent: P1 | P2 ----------------------------------------------------------- cachefiles_lookup_cookie cachefiles_look_up_object lookup_one_positive_unlocked // get dentry cachefiles_cull inode->i_flags |= S_KERNEL_FILE; cachefiles_open_file cachefiles_mark_inode_in_use __cachefiles_mark_inode_in_use can_use = false if (!(inode->i_flags & S_KERNEL_FILE)) can_use = true \t return false return false // Returns an error but doesn't put dentry After that the following WARNING will be triggered when the backend folder is umounted: ================================================================== BUG: Dentry 000000008ad87947{i=7a,n=Dx_1_1.img} still in use (1) [unmount of ext4 sda] WARNING: CPU: 4 PID: 359261 at fs/dcache.c:1767 umount_check+0x5d/0x70 CPU: 4 PID: 359261 Comm: umount Not tainted 6.6.0-dirty #25 RIP: 0010:umount_check+0x5d/0x70 Call Trace: d_walk+0xda/0x2b0 do_one_tree+0x20/0x40 shrink_dcache_for_umount+0x2c/0x90 generic_shutdown_super+0x20/0x160 kill_block_super+0x1a/0x40 ext4_kill_sb+0x22/0x40 deactivate_locked_super+0x35/0x80 cleanup_mnt+0x104/0x160 ================================================================== Whether cachefiles_open_file() returns true or false, the reference count obtained by lookup_positive_unlocked() in cachefiles_look_up_object() should be released. Therefore release that reference count in cachefiles_look_up_object() to fix the above issue and simplify the code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49871", "url": "https://ubuntu.com/security/CVE-2024-49871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: adp5589-keys - fix NULL pointer dereference We register a devm action to call adp5589_clear_config() and then pass the i2c client as argument so that we can call i2c_get_clientdata() in order to get our device object. However, i2c_set_clientdata() is only being set at the end of the probe function which means that we'll get a NULL pointer dereference in case the probe function fails early.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49872", "url": "https://ubuntu.com/security/CVE-2024-49872", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/gup: fix memfd_pin_folios alloc race panic If memfd_pin_folios tries to create a hugetlb page, but someone else already did, then folio gets the value -EEXIST here: folio = memfd_alloc_folio(memfd, start_idx); if (IS_ERR(folio)) { ret = PTR_ERR(folio); if (ret != -EEXIST) goto err; then on the next trip through the \"while start_idx\" loop we panic here: if (folio) { folio_put(folio); To fix, set the folio to NULL on error.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49964", "url": "https://ubuntu.com/security/CVE-2024-49964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix memfd_pin_folios free_huge_pages leak memfd_pin_folios followed by unpin_folios fails to restore free_huge_pages if the pages were not already faulted in, because the folio refcount for pages created by memfd_alloc_folio never goes to 0. memfd_pin_folios needs another folio_put to undo the folio_try_get below: memfd_alloc_folio() alloc_hugetlb_folio_nodemask() dequeue_hugetlb_folio_nodemask() dequeue_hugetlb_folio_node_exact() folio_ref_unfreeze(folio, 1); ; adds 1 refcount folio_try_get() ; adds 1 refcount hugetlb_add_to_page_cache() ; adds 512 refcount (on x86) With the fix, after memfd_pin_folios + unpin_folios, the refcount for the (unfaulted) page is 512, which is correct, as the refcount for a faulted unpinned page is 513.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49873", "url": "https://ubuntu.com/security/CVE-2024-49873", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/filemap: fix filemap_get_folios_contig THP panic Patch series \"memfd-pin huge page fixes\". Fix multiple bugs that occur when using memfd_pin_folios with hugetlb pages and THP. The hugetlb bugs only bite when the page is not yet faulted in when memfd_pin_folios is called. The THP bug bites when the starting offset passed to memfd_pin_folios is not huge page aligned. See the commit messages for details. This patch (of 5): memfd_pin_folios on memory backed by THP panics if the requested start offset is not huge page aligned: BUG: kernel NULL pointer dereference, address: 0000000000000036 RIP: 0010:filemap_get_folios_contig+0xdf/0x290 RSP: 0018:ffffc9002092fbe8 EFLAGS: 00010202 RAX: 0000000000000002 RBX: 0000000000000002 RCX: 0000000000000002 The fault occurs here, because xas_load returns a folio with value 2: filemap_get_folios_contig() for (folio = xas_load(&xas); folio && xas.xa_index <= end; folio = xas_next(&xas)) { ... if (!folio_try_get(folio)) <-- BOOM \"2\" is an xarray sibling entry. We get it because memfd_pin_folios does not round the indices passed to filemap_get_folios_contig to huge page boundaries for THP, so we load from the middle of a huge page range see a sibling. (It does round for hugetlbfs, at the is_file_hugepages test). To fix, if the folio is a sibling, then return the next index as the starting point for the next call to filemap_get_folios_contig.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49977", "url": "https://ubuntu.com/security/CVE-2024-49977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: Fix zero-division error when disabling tc cbs The commit b8c43360f6e4 (\"net: stmmac: No need to calculate speed divider when offload is disabled\") allows the \"port_transmit_rate_kbps\" to be set to a value of 0, which is then passed to the \"div_s64\" function when tc-cbs is disabled. This leads to a zero-division error. When tc-cbs is disabled, the idleslope, sendslope, and credit values the credit values are not required to be configured. Therefore, adding a return statement after setting the txQ mode to DCB when tc-cbs is disabled would prevent a zero-division error.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49978", "url": "https://ubuntu.com/security/CVE-2024-49978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gso: fix udp gso fraglist segmentation after pull from frag_list Detect gso fraglist skbs with corrupted geometry (see below) and pass these to skb_segment instead of skb_segment_list, as the first can segment them correctly. 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 these skbs, breaking these invariants. In extreme cases they pull all data into skb linear. For UDP, this causes a NULL ptr deref in __udpv4_gso_segment_list_csum at udp_hdr(seg->next)->dest. Detect invalid geometry due to pull, by checking head_skb size. Don't just drop, as this may blackhole a destination. Convert to be able to pass to regular skb_segment.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49979", "url": "https://ubuntu.com/security/CVE-2024-49979", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gso: fix tcp fraglist segmentation after pull from frag_list Detect tcp gso fraglist skbs with corrupted geometry (see below) and pass these to skb_segment instead of skb_segment_list, as the first can segment them correctly. 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 these skbs, breaking these invariants. In extreme cases they pull all data into skb linear. For TCP, this causes a NULL ptr deref in __tcpv4_gso_segment_list_csum at tcp_hdr(seg->next). Detect invalid geometry due to pull, by checking head_skb size. Don't just drop, as this may blackhole a destination. Convert to be able to pass to regular skb_segment. Approach and description based on a patch by Willem de Bruijn.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49980", "url": "https://ubuntu.com/security/CVE-2024-49980", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vrf: revert \"vrf: Remove unnecessary RCU-bh critical section\" This reverts commit 504fc6f4f7f681d2a03aa5f68aad549d90eab853. dev_queue_xmit_nit is expected to be called with BH disabled. __dev_queue_xmit has the following: /* Disable soft irqs for various locks below. Also * stops preemption for RCU. */ rcu_read_lock_bh(); VRF must follow this invariant. The referenced commit removed this protection. Which triggered a lockdep warning: \t================================ \tWARNING: inconsistent lock state \t6.11.0 #1 Tainted: G W \t-------------------------------- \tinconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage. \tbtserver/134819 [HC0[0]:SC0[0]:HE1:SE1] takes: \tffff8882da30c118 (rlock-AF_PACKET){+.?.}-{2:2}, at: tpacket_rcv+0x863/0x3b30 \t{IN-SOFTIRQ-W} state was registered at: \t lock_acquire+0x19a/0x4f0 \t _raw_spin_lock+0x27/0x40 \t packet_rcv+0xa33/0x1320 \t __netif_receive_skb_core.constprop.0+0xcb0/0x3a90 \t __netif_receive_skb_list_core+0x2c9/0x890 \t netif_receive_skb_list_internal+0x610/0xcc0 [...] \tother info that might help us debug this: \t Possible unsafe locking scenario: \t CPU0 \t ---- \t lock(rlock-AF_PACKET); \t \t lock(rlock-AF_PACKET); \t *** DEADLOCK *** \tCall Trace: \t \t dump_stack_lvl+0x73/0xa0 \t mark_lock+0x102e/0x16b0 \t __lock_acquire+0x9ae/0x6170 \t lock_acquire+0x19a/0x4f0 \t _raw_spin_lock+0x27/0x40 \t tpacket_rcv+0x863/0x3b30 \t dev_queue_xmit_nit+0x709/0xa40 \t vrf_finish_direct+0x26e/0x340 [vrf] \t vrf_l3_out+0x5f4/0xe80 [vrf] \t __ip_local_out+0x51e/0x7a0 [...]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49981", "url": "https://ubuntu.com/security/CVE-2024-49981", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: venus: fix use after free bug in venus_remove due to race condition in venus_probe, core->work is bound with venus_sys_error_handler, which is used to handle error. The code use core->sys_err_done to make sync work. The core->work is started in venus_event_notify. If we call venus_remove, there might be an unfished work. The possible sequence is as follows: CPU0 CPU1 |venus_sys_error_handler venus_remove | hfi_destroy\t \t\t | venus_hfi_destroy\t | kfree(hdev);\t | |hfi_reinit \t\t\t\t\t |venus_hfi_queues_reinit |//use hdev Fix it by canceling the work in venus_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49956", "url": "https://ubuntu.com/security/CVE-2024-49956", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: fix double destroy_workqueue error When gfs2_fill_super() fails, destroy_workqueue() is called within gfs2_gl_hash_clear(), and the subsequent code path calls destroy_workqueue() on the same work queue again. This issue can be fixed by setting the work queue pointer to NULL after the first destroy_workqueue() call and checking for a NULL pointer before attempting to destroy the work queue again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50176", "url": "https://ubuntu.com/security/CVE-2024-50176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: k3-r5: Fix error handling when power-up failed By simply bailing out, the driver was violating its rule and internal assumptions that either both or no rproc should be initialized. E.g., this could cause the first core to be available but not the second one, leading to crashes on its shutdown later on while trying to dereference that second instance.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49982", "url": "https://ubuntu.com/security/CVE-2024-49982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: aoe: fix the potential use-after-free problem in more places For fixing CVE-2023-6270, f98364e92662 (\"aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts\") makes tx() calling dev_put() instead of doing in aoecmd_cfg_pkts(). It avoids that the tx() runs into use-after-free. Then Nicolai Stange found more places in aoe have potential use-after-free problem with tx(). e.g. revalidate(), aoecmd_ata_rw(), resend(), probe() and aoecmd_cfg_rsp(). Those functions also use aoenet_xmit() to push packet to tx queue. So they should also use dev_hold() to increase the refcnt of skb->dev. On the other hand, moving dev_put() to tx() causes that the refcnt of skb->dev be reduced to a negative value, because corresponding dev_hold() are not called in revalidate(), aoecmd_ata_rw(), resend(), probe(), and aoecmd_cfg_rsp(). This patch fixed this issue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49874", "url": "https://ubuntu.com/security/CVE-2024-49874", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: svc: Fix use after free vulnerability in svc_i3c_master Driver Due to Race Condition In the svc_i3c_master_probe function, &master->hj_work is bound with svc_i3c_master_hj_work, &master->ibi_work is bound with svc_i3c_master_ibi_work. And svc_i3c_master_ibi_work can start the hj_work, svc_i3c_master_irq_handler can start the ibi_work. If we remove the module which will call svc_i3c_master_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | svc_i3c_master_hj_work svc_i3c_master_remove | i3c_master_unregister(&master->base)| device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in svc_i3c_master_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49875", "url": "https://ubuntu.com/security/CVE-2024-49875", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: map the EBADMSG to nfserr_io to avoid warning Ext4 will throw -EBADMSG through ext4_readdir when a checksum error occurs, resulting in the following WARNING. Fix it by mapping EBADMSG to nfserr_io. nfsd_buffered_readdir iterate_dir // -EBADMSG -74 ext4_readdir // .iterate_shared ext4_dx_readdir ext4_htree_fill_tree htree_dirblock_to_tree ext4_read_dirblock __ext4_read_dirblock ext4_dirblock_csum_verify warn_no_space_for_csum __warn_no_space_for_csum return ERR_PTR(-EFSBADCRC) // -EBADMSG -74 nfserrno // WARNING [ 161.115610] ------------[ cut here ]------------ [ 161.116465] nfsd: non-standard errno: -74 [ 161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0 [ 161.118596] Modules linked in: [ 161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138 [ 161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qe mu.org 04/01/2014 [ 161.123601] RIP: 0010:nfserrno+0x9d/0xd0 [ 161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6 05 ce 2b 61 03 01 e8 99 20 d8 00 <0f> 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33 [ 161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286 [ 161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a [ 161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827 [ 161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021 [ 161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8 [ 161.135244] FS: 0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000 [ 161.136695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0 [ 161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 161.141519] PKRU: 55555554 [ 161.142076] Call Trace: [ 161.142575] ? __warn+0x9b/0x140 [ 161.143229] ? nfserrno+0x9d/0xd0 [ 161.143872] ? report_bug+0x125/0x150 [ 161.144595] ? handle_bug+0x41/0x90 [ 161.145284] ? exc_invalid_op+0x14/0x70 [ 161.146009] ? asm_exc_invalid_op+0x12/0x20 [ 161.146816] ? nfserrno+0x9d/0xd0 [ 161.147487] nfsd_buffered_readdir+0x28b/0x2b0 [ 161.148333] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.149258] ? nfsd_buffered_filldir+0xf0/0xf0 [ 161.150093] ? wait_for_concurrent_writes+0x170/0x170 [ 161.151004] ? generic_file_llseek_size+0x48/0x160 [ 161.151895] nfsd_readdir+0x132/0x190 [ 161.152606] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.153516] ? nfsd_unlink+0x380/0x380 [ 161.154256] ? override_creds+0x45/0x60 [ 161.155006] nfsd4_encode_readdir+0x21a/0x3d0 [ 161.155850] ? nfsd4_encode_readlink+0x210/0x210 [ 161.156731] ? write_bytes_to_xdr_buf+0x97/0xe0 [ 161.157598] ? __write_bytes_to_xdr_buf+0xd0/0xd0 [ 161.158494] ? lock_downgrade+0x90/0x90 [ 161.159232] ? nfs4svc_decode_voidarg+0x10/0x10 [ 161.160092] nfsd4_encode_operation+0x15a/0x440 [ 161.160959] nfsd4_proc_compound+0x718/0xe90 [ 161.161818] nfsd_dispatch+0x18e/0x2c0 [ 161.162586] svc_process_common+0x786/0xc50 [ 161.163403] ? nfsd_svc+0x380/0x380 [ 161.164137] ? svc_printk+0x160/0x160 [ 161.164846] ? svc_xprt_do_enqueue.part.0+0x365/0x380 [ 161.165808] ? nfsd_svc+0x380/0x380 [ 161.166523] ? rcu_is_watching+0x23/0x40 [ 161.167309] svc_process+0x1a5/0x200 [ 161.168019] nfsd+0x1f5/0x380 [ 161.168663] ? nfsd_shutdown_threads+0x260/0x260 [ 161.169554] kthread+0x1c4/0x210 [ 161.170224] ? kthread_insert_work_sanity_check+0x80/0x80 [ 161.171246] ret_from_fork+0x1f/0x30", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50013", "url": "https://ubuntu.com/security/CVE-2024-50013", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix memory leak in exfat_load_bitmap() If the first directory entry in the root directory is not a bitmap directory entry, 'bh' will not be released and reassigned, which will cause a memory leak.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49876", "url": "https://ubuntu.com/security/CVE-2024-49876", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: fix UAF around queue destruction We currently do stuff like queuing the final destruction step on a random system wq, which will outlive the driver instance. With bad timing we can teardown the driver with one or more work workqueue still being alive leading to various UAF splats. Add a fini step to ensure user queues are properly torn down. At this point GuC should already be nuked so queue itself should no longer be referenced from hw pov. v2 (Matt B) - Looks much safer to use a waitqueue and then just wait for the xa_array to become empty before triggering the drain. (cherry picked from commit 861108666cc0e999cffeab6aff17b662e68774e3)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49877", "url": "https://ubuntu.com/security/CVE-2024-49877", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate When doing cleanup, if flags without OCFS2_BH_READAHEAD, it may trigger NULL pointer dereference in the following ocfs2_set_buffer_uptodate() if bh is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49957", "url": "https://ubuntu.com/security/CVE-2024-49957", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix null-ptr-deref when journal load failed. During the mounting process, if journal_reset() fails because of too short journal, then lead to jbd2_journal_load() fails with NULL j_sb_buffer. Subsequently, ocfs2_journal_shutdown() calls jbd2_journal_flush()->jbd2_cleanup_journal_tail()-> __jbd2_update_log_tail()->jbd2_journal_update_sb_log_tail() ->lock_buffer(journal->j_sb_buffer), resulting in a null-pointer dereference error. To resolve this issue, we should check the JBD2_LOADED flag to ensure the journal was properly loaded. Additionally, use journal instead of osb->journal directly to simplify the code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49965", "url": "https://ubuntu.com/security/CVE-2024-49965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove unreasonable unlock in ocfs2_read_blocks Patch series \"Misc fixes for ocfs2_read_blocks\", v5. This series contains 2 fixes for ocfs2_read_blocks(). The first patch fix the issue reported by syzbot, which detects bad unlock balance in ocfs2_read_blocks(). The second patch fixes an issue reported by Heming Zhao when reviewing above fix. This patch (of 2): There was a lock release before exiting, so remove the unreasonable unlock.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49966", "url": "https://ubuntu.com/security/CVE-2024-49966", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: cancel dqi_sync_work before freeing oinfo ocfs2_global_read_info() will initialize and schedule dqi_sync_work at the end, if error occurs after successfully reading global quota, it will trigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled: ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16c This reports that there is an active delayed work when freeing oinfo in error handling, so cancel dqi_sync_work first. BTW, return status instead of -1 when .read_file_info fails.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49958", "url": "https://ubuntu.com/security/CVE-2024-49958", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reserve space for inline xattr before attaching reflink tree One of our customers reported a crash and a corrupted ocfs2 filesystem. The crash was due to the detection of corruption. Upon troubleshooting, the fsck -fn output showed the below corruption [EXTENT_LIST_FREE] Extent list in owner 33080590 claims 230 as the next free chain record, but fsck believes the largest valid value is 227. Clamp the next record value? n The stat output from the debugfs.ocfs2 showed the following corruption where the \"Next Free Rec:\" had overshot the \"Count:\" in the root metadata block. Inode: 33080590 Mode: 0640 Generation: 2619713622 (0x9c25a856) FS Generation: 904309833 (0x35e6ac49) CRC32: 00000000 ECC: 0000 Type: Regular Attr: 0x0 Flags: Valid Dynamic Features: (0x16) HasXattr InlineXattr Refcounted Extended Attributes Block: 0 Extended Attributes Inline Size: 256 User: 0 (root) Group: 0 (root) Size: 281320357888 Links: 1 Clusters: 141738 ctime: 0x66911b56 0x316edcb8 -- Fri Jul 12 06:02:30.829349048 2024 atime: 0x66911d6b 0x7f7a28d -- Fri Jul 12 06:11:23.133669517 2024 mtime: 0x66911b56 0x12ed75d7 -- Fri Jul 12 06:02:30.317552087 2024 dtime: 0x0 -- Wed Dec 31 17:00:00 1969 Refcount Block: 2777346 Last Extblk: 2886943 Orphan Slot: 0 Sub Alloc Slot: 0 Sub Alloc Bit: 14 Tree Depth: 1 Count: 227 Next Free Rec: 230 ## Offset Clusters Block# 0 0 2310 2776351 1 2310 2139 2777375 2 4449 1221 2778399 3 5670 731 2779423 4 6401 566 2780447 ....... .... ....... ....... .... ....... The issue was in the reflink workfow while reserving space for inline xattr. The problematic function is ocfs2_reflink_xattr_inline(). By the time this function is called the reflink tree is already recreated at the destination inode from the source inode. At this point, this function reserves space for inline xattrs at the destination inode without even checking if there is space at the root metadata block. It simply reduces the l_count from 243 to 227 thereby making space of 256 bytes for inline xattr whereas the inode already has extents beyond this index (in this case up to 230), thereby causing corruption. The fix for this is to reserve space for inline metadata at the destination inode before the reflink tree gets recreated. The customer has verified the fix.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49959", "url": "https://ubuntu.com/security/CVE-2024-49959", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail() to recover some journal space. But if an error occurs while executing jbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for free space right away, we try other branches, and if j_committing_transaction is NULL (i.e., the tid is 0), we will get the following complain: ============================================ JBD2: I/O error when updating journal superblock for sdd-8. __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available __jbd2_log_wait_for_space: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Call Trace: add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70 [...] ============================================ So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways. Note that this fix relies on commit 6f6a6fda2945 (\"jbd2: fix ocfs2 corrupt when updating journal superblock fails\") to make jbd2_cleanup_journal_tail return the correct error code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49878", "url": "https://ubuntu.com/security/CVE-2024-49878", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: resource: fix region_intersects() vs add_memory_driver_managed() On a system with CXL memory, the resource tree (/proc/iomem) related to CXL memory may look like something as follows. 490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem) Because drivers/dax/kmem.c calls add_memory_driver_managed() during onlining CXL memory, which makes \"System RAM (kmem)\" a descendant of \"CXL Window X\". This confuses region_intersects(), which expects all \"System RAM\" resources to be at the top level of iomem_resource. This can lead to bugs. For example, when the following command line is executed to write some memory in CXL memory range via /dev/mem, $ dd if=data of=/dev/mem bs=$((1 << 10)) seek=$((0x490000000 >> 10)) count=1 dd: error writing '/dev/mem': Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/s the command fails as expected. However, the error code is wrong. It should be \"Operation not permitted\" instead of \"Bad address\". More seriously, the /dev/mem permission checking in devmem_is_allowed() passes incorrectly. Although the accessing is prevented later because ioremap() isn't allowed to map system RAM, it is a potential security issue. During command executing, the following warning is reported in the kernel log for calling ioremap() on system RAM. ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d Call Trace: memremap+0xcb/0x184 xlate_dev_mem_ptr+0x25/0x2f write_mem+0x94/0xfb vfs_write+0x128/0x26d ksys_write+0xac/0xfe do_syscall_64+0x9a/0xfd entry_SYSCALL_64_after_hwframe+0x4b/0x53 The details of command execution process are as follows. In the above resource tree, \"System RAM\" is a descendant of \"CXL Window 0\" instead of a top level resource. So, region_intersects() will report no System RAM resources in the CXL memory region incorrectly, because it only checks the top level resources. Consequently, devmem_is_allowed() will return 1 (allow access via /dev/mem) for CXL memory region incorrectly. Fortunately, ioremap() doesn't allow to map System RAM and reject the access. So, region_intersects() needs to be fixed to work correctly with the resource tree with \"System RAM\" not at top level as above. To fix it, if we found a unmatched resource in the top level, we will continue to search matched resources in its descendant resources. So, we will not miss any matched resources in resource tree anymore. In the new implementation, an example resource tree |------------- \"CXL Window 0\" ------------| |-- \"System RAM\" --| will behave similar as the following fake resource tree for region_intersects(, IORESOURCE_SYSTEM_RAM, ), |-- \"System RAM\" --||-- \"CXL Window 0a\" --| Where \"CXL Window 0a\" is part of the original \"CXL Window 0\" that isn't covered by \"System RAM\".", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49879", "url": "https://ubuntu.com/security/CVE-2024-49879", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm: omapdrm: Add missing check for alloc_ordered_workqueue As it may return NULL pointer and cause NULL pointer dereference. Add check for the return value of alloc_ordered_workqueue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49880", "url": "https://ubuntu.com/security/CVE-2024-49880", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix off by one issue in alloc_flex_gd() Wesley reported an issue: ================================================================== EXT4-fs (dm-5): resizing filesystem from 7168 to 786432 blocks ------------[ cut here ]------------ kernel BUG at fs/ext4/resize.c:324! CPU: 9 UID: 0 PID: 3576 Comm: resize2fs Not tainted 6.11.0+ #27 RIP: 0010:ext4_resize_fs+0x1212/0x12d0 Call Trace: __ext4_ioctl+0x4e0/0x1800 ext4_ioctl+0x12/0x20 __x64_sys_ioctl+0x99/0xd0 x64_sys_call+0x1206/0x20d0 do_syscall_64+0x72/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e ================================================================== While reviewing the patch, Honza found that when adjusting resize_bg in alloc_flex_gd(), it was possible for flex_gd->resize_bg to be bigger than flexbg_size. The reproduction of the problem requires the following: o_group = flexbg_size * 2 * n; o_size = (o_group + 1) * group_size; n_group: [o_group + flexbg_size, o_group + flexbg_size * 2) o_size = (n_group + 1) * group_size; Take n=0,flexbg_size=16 as an example: last:15 |o---------------|--------------n-| o_group:0 resize to n_group:30 The corresponding reproducer is: img=test.img rm -f $img truncate -s 600M $img mkfs.ext4 -F $img -b 1024 -G 16 8M dev=`losetup -f --show $img` mkdir -p /tmp/test mount $dev /tmp/test resize2fs $dev 248M Delete the problematic plus 1 to fix the issue, and add a WARN_ON_ONCE() to prevent the issue from happening again. [ Note: another reproucer which this commit fixes is: img=test.img rm -f $img truncate -s 25MiB $img mkfs.ext4 -b 4096 -E nodiscard,lazy_itable_init=0,lazy_journal_init=0 $img truncate -s 3GiB $img dev=`losetup -f --show $img` mkdir -p /tmp/test mount $dev /tmp/test resize2fs $dev 3G umount $dev losetup -d $dev -- TYT ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49881", "url": "https://ubuntu.com/security/CVE-2024-49881", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: update orig_path in ext4_find_extent() In ext4_find_extent(), if the path is not big enough, we free it and set *orig_path to NULL. But after reallocating and successfully initializing the path, we don't update *orig_path, in which case the caller gets a valid path but a NULL ppath, and this may cause a NULL pointer dereference or a path memory leak. For example: ext4_split_extent path = *ppath = 2000 ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path = 2000); *orig_path = path = NULL; path = kcalloc() = 3000 ext4_split_extent_at(*ppath = NULL) path = *ppath; ex = path[depth].p_ext; // NULL pointer dereference! ================================================================== BUG: kernel NULL pointer dereference, address: 0000000000000010 CPU: 6 UID: 0 PID: 576 Comm: fsstress Not tainted 6.11.0-rc2-dirty #847 RIP: 0010:ext4_split_extent_at+0x6d/0x560 Call Trace: ext4_split_extent.isra.0+0xcb/0x1b0 ext4_ext_convert_to_initialized+0x168/0x6c0 ext4_ext_handle_unwritten_extents+0x325/0x4d0 ext4_ext_map_blocks+0x520/0xdb0 ext4_map_blocks+0x2b0/0x690 ext4_iomap_begin+0x20e/0x2c0 [...] ================================================================== Therefore, *orig_path is updated when the extent lookup succeeds, so that the caller can safely use path or *ppath.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50014", "url": "https://ubuntu.com/security/CVE-2024-50014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix access to uninitialised lock in fc replay path The following kernel trace can be triggered with fstest generic/629 when executed against a filesystem with fast-commit feature enabled: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x66/0x90 register_lock_class+0x759/0x7d0 __lock_acquire+0x85/0x2630 ? __find_get_block+0xb4/0x380 lock_acquire+0xd1/0x2d0 ? __ext4_journal_get_write_access+0xd5/0x160 _raw_spin_lock+0x33/0x40 ? __ext4_journal_get_write_access+0xd5/0x160 __ext4_journal_get_write_access+0xd5/0x160 ext4_reserve_inode_write+0x61/0xb0 __ext4_mark_inode_dirty+0x79/0x270 ? ext4_ext_replay_set_iblocks+0x2f8/0x450 ext4_ext_replay_set_iblocks+0x330/0x450 ext4_fc_replay+0x14c8/0x1540 ? jread+0x88/0x2e0 ? rcu_is_watching+0x11/0x40 do_one_pass+0x447/0xd00 jbd2_journal_recover+0x139/0x1b0 jbd2_journal_load+0x96/0x390 ext4_load_and_init_journal+0x253/0xd40 ext4_fill_super+0x2cc6/0x3180 ... In the replay path there's an attempt to lock sbi->s_bdev_wb_lock in function ext4_check_bdev_write_error(). Unfortunately, at this point this spinlock has not been initialized yet. Moving it's initialization to an earlier point in __ext4_fill_super() fixes this splat.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49960", "url": "https://ubuntu.com/security/CVE-2024-49960", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix timer use-after-free on failed mount Syzbot has found an ODEBUG bug in ext4_fill_super The del_timer_sync function cancels the s_err_report timer, which reminds about filesystem errors daily. We should guarantee the timer is no longer active before kfree(sbi). When filesystem mounting fails, the flow goes to failed_mount3, where an error occurs when ext4_stop_mmpd is called, causing a read I/O failure. This triggers the ext4_handle_error function that ultimately re-arms the timer, leaving the s_err_report timer active before kfree(sbi) is called. Fix the issue by canceling the s_err_report timer after calling ext4_stop_mmpd.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49882", "url": "https://ubuntu.com/security/CVE-2024-49882", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix double brelse() the buffer of the extents path In ext4_ext_try_to_merge_up(), set path[1].p_bh to NULL after it has been released, otherwise it may be released twice. An example of what triggers this is as follows: split2 map split1 |--------|-------|--------| ext4_ext_map_blocks ext4_ext_handle_unwritten_extents ext4_split_convert_extents // path->p_depth == 0 ext4_split_extent // 1. do split1 ext4_split_extent_at |ext4_ext_insert_extent | ext4_ext_create_new_leaf | ext4_ext_grow_indepth | le16_add_cpu(&neh->eh_depth, 1) | ext4_find_extent | // return -ENOMEM |// get error and try zeroout |path = ext4_find_extent | path->p_depth = 1 |ext4_ext_try_to_merge | ext4_ext_try_to_merge_up | path->p_depth = 0 | brelse(path[1].p_bh) ---> not set to NULL here |// zeroout success // 2. update path ext4_find_extent // 3. do split2 ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth le16_add_cpu(&neh->eh_depth, 1) ext4_find_extent path[0].p_bh = NULL; path->p_depth = 1 read_extent_tree_block ---> return err // path[1].p_bh is still the old value ext4_free_ext_path ext4_ext_drop_refs // path->p_depth == 1 brelse(path[1].p_bh) ---> brelse a buffer twice Finally got the following WARRNING when removing the buffer from lru: ============================================ VFS: brelse: Trying to free free buffer WARNING: CPU: 2 PID: 72 at fs/buffer.c:1241 __brelse+0x58/0x90 CPU: 2 PID: 72 Comm: kworker/u19:1 Not tainted 6.9.0-dirty #716 RIP: 0010:__brelse+0x58/0x90 Call Trace: __find_get_block+0x6e7/0x810 bdev_getblk+0x2b/0x480 __ext4_get_inode_loc+0x48a/0x1240 ext4_get_inode_loc+0xb2/0x150 ext4_reserve_inode_write+0xb7/0x230 __ext4_mark_inode_dirty+0x144/0x6a0 ext4_ext_insert_extent+0x9c8/0x3230 ext4_ext_map_blocks+0xf45/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] ============================================", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49883", "url": "https://ubuntu.com/security/CVE-2024-49883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: aovid use-after-free in ext4_ext_insert_extent() As Ojaswin mentioned in Link, in ext4_ext_insert_extent(), if the path is reallocated in ext4_ext_create_new_leaf(), we'll use the stale path and cause UAF. Below is a sample trace with dummy values: ext4_ext_insert_extent path = *ppath = 2000 ext4_ext_create_new_leaf(ppath) ext4_find_extent(ppath) path = *ppath = 2000 if (depth > path[0].p_maxdepth) kfree(path = 2000); *ppath = path = NULL; path = kcalloc() = 3000 *ppath = 3000; return path; /* here path is still 2000, UAF! */ eh = path[depth].p_hdr ================================================================== BUG: KASAN: slab-use-after-free in ext4_ext_insert_extent+0x26d4/0x3330 Read of size 8 at addr ffff8881027bf7d0 by task kworker/u36:1/179 CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 Not tainted 6.11.0-rc2-dirty #866 Call Trace: ext4_ext_insert_extent+0x26d4/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 [...] Allocated by task 179: ext4_find_extent+0x81c/0x1f70 ext4_ext_map_blocks+0x146/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...] Freed by task 179: kfree+0xcb/0x240 ext4_find_extent+0x7c0/0x1f70 ext4_ext_insert_extent+0xa26/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...] ================================================================== So use *ppath to update the path to avoid the above problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49983", "url": "https://ubuntu.com/security/CVE-2024-49983", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-free When calling ext4_force_split_extent_at() in ext4_ext_replay_update_ex(), the 'ppath' is updated but it is the 'path' that is freed, thus potentially triggering a double-free in the following process: ext4_ext_replay_update_ex ppath = path ext4_force_split_extent_at(&ppath) ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path) ---> path First freed *orig_path = path = NULL ---> null ppath kfree(path) ---> path double-free !!! So drop the unnecessary ppath and use path directly to avoid this problem. And use ext4_find_extent() directly to update path, avoiding unnecessary memory allocation and freeing. Also, propagate the error returned by ext4_find_extent() instead of using strange error codes.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50015", "url": "https://ubuntu.com/security/CVE-2024-50015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: dax: fix overflowing extents beyond inode size when partially writing The dax_iomap_rw() does two things in each iteration: map written blocks and copy user data to blocks. If the process is killed by user(See signal handling in dax_iomap_iter()), the copied data will be returned and added on inode size, which means that the length of written extents may exceed the inode size, then fsck will fail. An example is given as: dd if=/dev/urandom of=file bs=4M count=1 dax_iomap_rw iomap_iter // round 1 ext4_iomap_begin ext4_iomap_alloc // allocate 0~2M extents(written flag) dax_iomap_iter // copy 2M data iomap_iter // round 2 iomap_iter_advance iter->pos += iter->processed // iter->pos = 2M ext4_iomap_begin ext4_iomap_alloc // allocate 2~4M extents(written flag) dax_iomap_iter fatal_signal_pending done = iter->pos - iocb->ki_pos // done = 2M ext4_handle_inode_extension ext4_update_inode_size // inode size = 2M fsck reports: Inode 13, i_size is 2097152, should be 4194304. Fix? Fix the problem by truncating extents if the written length is smaller than expected.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49884", "url": "https://ubuntu.com/security/CVE-2024-49884", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix slab-use-after-free in ext4_split_extent_at() We hit the following use-after-free: ================================================================== BUG: KASAN: slab-use-after-free in ext4_split_extent_at+0xba8/0xcc0 Read of size 2 at addr ffff88810548ed08 by task kworker/u20:0/40 CPU: 0 PID: 40 Comm: kworker/u20:0 Not tainted 6.9.0-dirty #724 Call Trace: kasan_report+0x93/0xc0 ext4_split_extent_at+0xba8/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] Allocated by task 40: __kmalloc_noprof+0x1ac/0x480 ext4_find_extent+0xf3b/0x1e70 ext4_ext_map_blocks+0x188/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] Freed by task 40: kfree+0xf1/0x2b0 ext4_find_extent+0xa71/0x1e70 ext4_ext_insert_extent+0xa22/0x3260 ext4_split_extent_at+0x3ef/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] ================================================================== The flow of issue triggering is as follows: ext4_split_extent_at path = *ppath ext4_ext_insert_extent(ppath) ext4_ext_create_new_leaf(ppath) ext4_find_extent(orig_path) path = *orig_path read_extent_tree_block // return -ENOMEM or -EIO ext4_free_ext_path(path) kfree(path) *orig_path = NULL a. If err is -ENOMEM: ext4_ext_dirty(path + path->p_depth) // path use-after-free !!! b. If err is -EIO and we have EXT_DEBUG defined: ext4_ext_show_leaf(path) eh = path[depth].p_hdr // path also use-after-free !!! So when trying to zeroout or fix the extent length, call ext4_find_extent() to update the path. In addition we use *ppath directly as an ext4_ext_show_leaf() input to avoid possible use-after-free when EXT_DEBUG is defined, and to avoid unnecessary path updates.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49885", "url": "https://ubuntu.com/security/CVE-2024-49885", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm, slub: avoid zeroing kmalloc redzone Since commit 946fa0dbf2d8 (\"mm/slub: extend redzone check to extra allocated kmalloc space than requested\"), setting orig_size treats the wasted space (object_size - orig_size) as a redzone. However with init_on_free=1 we clear the full object->size, including the redzone. Additionally we clear the object metadata, including the stored orig_size, making it zero, which makes check_object() treat the whole object as a redzone. These issues lead to the following BUG report with \"slub_debug=FUZ init_on_free=1\": [ 0.000000] ============================================================================= [ 0.000000] BUG kmalloc-8 (Not tainted): kmalloc Redzone overwritten [ 0.000000] ----------------------------------------------------------------------------- [ 0.000000] [ 0.000000] 0xffff000010032858-0xffff00001003285f @offset=2136. First byte 0x0 instead of 0xcc [ 0.000000] FIX kmalloc-8: Restoring kmalloc Redzone 0xffff000010032858-0xffff00001003285f=0xcc [ 0.000000] Slab 0xfffffdffc0400c80 objects=36 used=23 fp=0xffff000010032a18 flags=0x3fffe0000000200(workingset|node=0|zone=0|lastcpupid=0x1ffff) [ 0.000000] Object 0xffff000010032858 @offset=2136 fp=0xffff0000100328c8 [ 0.000000] [ 0.000000] Redzone ffff000010032850: cc cc cc cc cc cc cc cc ........ [ 0.000000] Object ffff000010032858: cc cc cc cc cc cc cc cc ........ [ 0.000000] Redzone ffff000010032860: cc cc cc cc cc cc cc cc ........ [ 0.000000] Padding ffff0000100328b4: 00 00 00 00 00 00 00 00 00 00 00 00 ............ [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.11.0-rc3-next-20240814-00004-g61844c55c3f4 #144 [ 0.000000] Hardware name: NXP i.MX95 19X19 board (DT) [ 0.000000] Call trace: [ 0.000000] dump_backtrace+0x90/0xe8 [ 0.000000] show_stack+0x18/0x24 [ 0.000000] dump_stack_lvl+0x74/0x8c [ 0.000000] dump_stack+0x18/0x24 [ 0.000000] print_trailer+0x150/0x218 [ 0.000000] check_object+0xe4/0x454 [ 0.000000] free_to_partial_list+0x2f8/0x5ec To address the issue, use orig_size to clear the used area. And restore the value of orig_size after clear the remaining area. When CONFIG_SLUB_DEBUG not defined, (get_orig_size()' directly returns s->object_size. So when using memset to init the area, the size can simply be orig_size, as orig_size returns object_size when CONFIG_SLUB_DEBUG not enabled. And orig_size can never be bigger than object_size.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49961", "url": "https://ubuntu.com/security/CVE-2024-49961", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: ar0521: Use cansleep version of gpiod_set_value() If we use GPIO reset from I2C port expander, we must use *_cansleep() variant of GPIO functions. This was not done in ar0521_power_on()/ar0521_power_off() functions. Let's fix that. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 11 at drivers/gpio/gpiolib.c:3496 gpiod_set_value+0x74/0x7c Modules linked in: CPU: 0 PID: 11 Comm: kworker/u16:0 Not tainted 6.10.0 #53 Hardware name: Diasom DS-RK3568-SOM-EVB (DT) Workqueue: events_unbound deferred_probe_work_func pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : gpiod_set_value+0x74/0x7c lr : ar0521_power_on+0xcc/0x290 sp : ffffff8001d7ab70 x29: ffffff8001d7ab70 x28: ffffff80027dcc90 x27: ffffff8003c82000 x26: ffffff8003ca9250 x25: ffffffc080a39c60 x24: ffffff8003ca9088 x23: ffffff8002402720 x22: ffffff8003ca9080 x21: ffffff8003ca9088 x20: 0000000000000000 x19: ffffff8001eb2a00 x18: ffffff80efeeac80 x17: 756d2d6332692f30 x16: 0000000000000000 x15: 0000000000000000 x14: ffffff8001d91d40 x13: 0000000000000016 x12: ffffffc080e98930 x11: ffffff8001eb2880 x10: 0000000000000890 x9 : ffffff8001d7a9f0 x8 : ffffff8001d92570 x7 : ffffff80efeeac80 x6 : 000000003fc6e780 x5 : ffffff8001d91c80 x4 : 0000000000000002 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000001 Call trace: gpiod_set_value+0x74/0x7c ar0521_power_on+0xcc/0x290 ...", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49985", "url": "https://ubuntu.com/security/CVE-2024-49985", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume In case there is any sort of clock controller attached to this I2C bus controller, for example Versaclock or even an AIC32x4 I2C codec, then an I2C transfer triggered from the clock controller clk_ops .prepare callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex. This is because the clock controller first grabs the prepare_lock mutex and then performs the prepare operation, including its I2C access. The I2C access resumes this I2C bus controller via .runtime_resume callback, which calls clk_prepare_enable(), which attempts to grab the prepare_lock mutex again and deadlocks. Since the clock are already prepared since probe() and unprepared in remove(), use simple clk_enable()/clk_disable() calls to enable and disable the clock on runtime suspend and resume, to avoid hitting the prepare_lock mutex.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49886", "url": "https://ubuntu.com/security/CVE-2024-49886", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bug Attaching SST PCI device to VM causes \"BUG: KASAN: slab-out-of-bounds\". kasan report: [ 19.411889] ================================================================== [ 19.413702] BUG: KASAN: slab-out-of-bounds in _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.415634] Read of size 8 at addr ffff888829e65200 by task cpuhp/16/113 [ 19.417368] [ 19.418627] CPU: 16 PID: 113 Comm: cpuhp/16 Tainted: G E 6.9.0 #10 [ 19.420435] Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.20192059.B64.2207280713 07/28/2022 [ 19.422687] Call Trace: [ 19.424091] [ 19.425448] dump_stack_lvl+0x5d/0x80 [ 19.426963] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.428694] print_report+0x19d/0x52e [ 19.430206] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 19.431837] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.433539] kasan_report+0xf0/0x170 [ 19.435019] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.436709] _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.438379] ? __pfx_sched_clock_cpu+0x10/0x10 [ 19.439910] isst_if_cpu_online+0x406/0x58f [isst_if_common] [ 19.441573] ? __pfx_isst_if_cpu_online+0x10/0x10 [isst_if_common] [ 19.443263] ? ttwu_queue_wakelist+0x2c1/0x360 [ 19.444797] cpuhp_invoke_callback+0x221/0xec0 [ 19.446337] cpuhp_thread_fun+0x21b/0x610 [ 19.447814] ? __pfx_cpuhp_thread_fun+0x10/0x10 [ 19.449354] smpboot_thread_fn+0x2e7/0x6e0 [ 19.450859] ? __pfx_smpboot_thread_fn+0x10/0x10 [ 19.452405] kthread+0x29c/0x350 [ 19.453817] ? __pfx_kthread+0x10/0x10 [ 19.455253] ret_from_fork+0x31/0x70 [ 19.456685] ? __pfx_kthread+0x10/0x10 [ 19.458114] ret_from_fork_asm+0x1a/0x30 [ 19.459573] [ 19.460853] [ 19.462055] Allocated by task 1198: [ 19.463410] kasan_save_stack+0x30/0x50 [ 19.464788] kasan_save_track+0x14/0x30 [ 19.466139] __kasan_kmalloc+0xaa/0xb0 [ 19.467465] __kmalloc+0x1cd/0x470 [ 19.468748] isst_if_cdev_register+0x1da/0x350 [isst_if_common] [ 19.470233] isst_if_mbox_init+0x108/0xff0 [isst_if_mbox_msr] [ 19.471670] do_one_initcall+0xa4/0x380 [ 19.472903] do_init_module+0x238/0x760 [ 19.474105] load_module+0x5239/0x6f00 [ 19.475285] init_module_from_file+0xd1/0x130 [ 19.476506] idempotent_init_module+0x23b/0x650 [ 19.477725] __x64_sys_finit_module+0xbe/0x130 [ 19.476506] idempotent_init_module+0x23b/0x650 [ 19.477725] __x64_sys_finit_module+0xbe/0x130 [ 19.478920] do_syscall_64+0x82/0x160 [ 19.480036] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 19.481292] [ 19.482205] The buggy address belongs to the object at ffff888829e65000 which belongs to the cache kmalloc-512 of size 512 [ 19.484818] The buggy address is located 0 bytes to the right of allocated 512-byte region [ffff888829e65000, ffff888829e65200) [ 19.487447] [ 19.488328] The buggy address belongs to the physical page: [ 19.489569] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888829e60c00 pfn:0x829e60 [ 19.491140] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [ 19.492466] anon flags: 0x57ffffc0000840(slab|head|node=1|zone=2|lastcpupid=0x1fffff) [ 19.493914] page_type: 0xffffffff() [ 19.494988] raw: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [ 19.496451] raw: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [ 19.497906] head: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [ 19.499379] head: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [ 19.500844] head: 0057ffffc0000003 ffffea0020a79801 ffffea0020a79848 00000000ffffffff [ 19.502316] head: 0000000800000000 0000000000000000 00000000ffffffff 0000000000000000 [ 19.503784] page dumped because: k ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49986", "url": "https://ubuntu.com/security/CVE-2024-49986", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: x86-android-tablets: Fix use after free on platform_device_register() errors x86_android_tablet_remove() frees the pdevs[] array, so it should not be used after calling x86_android_tablet_remove(). When platform_device_register() fails, store the pdevs[x] PTR_ERR() value into the local ret variable before calling x86_android_tablet_remove() to avoid using pdevs[] after it has been freed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49887", "url": "https://ubuntu.com/security/CVE-2024-49887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to don't panic system for no free segment fault injection f2fs: fix to don't panic system for no free segment fault injection syzbot reports a f2fs bug as below: F2FS-fs (loop0): inject no free segment in get_new_segment of __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3167 F2FS-fs (loop0): Stopped filesystem due to reason: 7 ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2748! CPU: 0 UID: 0 PID: 5109 Comm: syz-executor304 Not tainted 6.11.0-rc6-syzkaller-00363-g89f5e14d05b4 #0 RIP: 0010:get_new_segment fs/f2fs/segment.c:2748 [inline] RIP: 0010:new_curseg+0x1f61/0x1f70 fs/f2fs/segment.c:2836 Call Trace: __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3167 f2fs_allocate_new_section fs/f2fs/segment.c:3181 [inline] f2fs_allocate_pinning_section+0xfa/0x4e0 fs/f2fs/segment.c:3195 f2fs_expand_inode_data+0x5d6/0xbb0 fs/f2fs/file.c:1799 f2fs_fallocate+0x448/0x960 fs/f2fs/file.c:1903 vfs_fallocate+0x553/0x6c0 fs/open.c:334 do_vfs_ioctl+0x2592/0x2e50 fs/ioctl.c:886 __do_sys_ioctl fs/ioctl.c:905 [inline] __se_sys_ioctl+0x81/0x170 fs/ioctl.c:893 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: 0010:get_new_segment fs/f2fs/segment.c:2748 [inline] RIP: 0010:new_curseg+0x1f61/0x1f70 fs/f2fs/segment.c:2836 The root cause is when we inject no free segment fault into f2fs, we should not panic system, fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49888", "url": "https://ubuntu.com/security/CVE-2024-49888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix a sdiv overflow issue Zac Ecob reported a problem where a bpf program may cause kernel crash due to the following error: Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI The failure is due to the below signed divide: LLONG_MIN/-1 where LLONG_MIN equals to -9,223,372,036,854,775,808. LLONG_MIN/-1 is supposed to give a positive number 9,223,372,036,854,775,808, but it is impossible since for 64-bit system, the maximum positive number is 9,223,372,036,854,775,807. On x86_64, LLONG_MIN/-1 will cause a kernel exception. On arm64, the result for LLONG_MIN/-1 is LLONG_MIN. Further investigation found all the following sdiv/smod cases may trigger an exception when bpf program is running on x86_64 platform: - LLONG_MIN/-1 for 64bit operation - INT_MIN/-1 for 32bit operation - LLONG_MIN%-1 for 64bit operation - INT_MIN%-1 for 32bit operation where -1 can be an immediate or in a register. On arm64, there are no exceptions: - LLONG_MIN/-1 = LLONG_MIN - INT_MIN/-1 = INT_MIN - LLONG_MIN%-1 = 0 - INT_MIN%-1 = 0 where -1 can be an immediate or in a register. Insn patching is needed to handle the above cases and the patched codes produced results aligned with above arm64 result. The below are pseudo codes to handle sdiv/smod exceptions including both divisor -1 and divisor 0 and the divisor is stored in a register. sdiv: tmp = rX tmp += 1 /* [-1, 0] -> [0, 1] if tmp >(unsigned) 1 goto L2 if tmp == 0 goto L1 rY = 0 L1: rY = -rY; goto L3 L2: rY /= rX L3: smod: tmp = rX tmp += 1 /* [-1, 0] -> [0, 1] if tmp >(unsigned) 1 goto L1 if tmp == 1 (is64 ? goto L2 : goto L3) rY = 0; goto L2 L1: rY %= rX L2: goto L4 // only when !is64 L3: wY = wY // only when !is64 L4: [1] https://lore.kernel.org/bpf/tPJLTEh7S_DxFEqAI2Ji5MBSoZVg7_G-Py2iaZpAaWtM961fFTWtsnlzwvTbzBzaUzwQAoNATXKUlt0LZOFgnDcIyKCswAnAGdUF3LBrhGQ=@protonmail.com/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49987", "url": "https://ubuntu.com/security/CVE-2024-49987", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpftool: Fix undefined behavior in qsort(NULL, 0, ...) When netfilter has no entry to display, qsort is called with qsort(NULL, 0, ...). This results in undefined behavior, as UBSan reports: net.c:827:2: runtime error: null pointer passed as argument 1, which is declared to never be null Although the C standard does not explicitly state whether calling qsort with a NULL pointer when the size is 0 constitutes undefined behavior, Section 7.1.4 of the C standard (Use of library functions) mentions: \"Each of the following statements applies unless explicitly stated otherwise in the detailed descriptions that follow: If an argument to a function has an invalid value (such as a value outside the domain of the function, or a pointer outside the address space of the program, or a null pointer, or a pointer to non-modifiable storage when the corresponding parameter is not const-qualified) or a type (after promotion) not expected by a function with variable number of arguments, the behavior is undefined.\" To avoid this, add an early return when nf_link_info is NULL to prevent calling qsort with a NULL pointer.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50006", "url": "https://ubuntu.com/security/CVE-2024-50006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix i_data_sem unlock order in ext4_ind_migrate() Fuzzing reports a possible deadlock in jbd2_log_wait_commit. This issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to require synchronous updates because the file descriptor is opened with O_SYNC. This can lead to the jbd2_journal_stop() function calling jbd2_might_wait_for_commit(), potentially causing a deadlock if the EXT4_IOC_MIGRATE call races with a write(2) system call. This problem only arises when CONFIG_PROVE_LOCKING is enabled. In this case, the jbd2_might_wait_for_commit macro locks jbd2_handle in the jbd2_journal_stop function while i_data_sem is locked. This triggers lockdep because the jbd2_journal_start function might also lock the same jbd2_handle simultaneously. Found by Linux Verification Center (linuxtesting.org) with syzkaller. Rule: add", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49889", "url": "https://ubuntu.com/security/CVE-2024-49889", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid use-after-free in ext4_ext_show_leaf() In ext4_find_extent(), path may be freed by error or be reallocated, so using a previously saved *ppath may have been freed and thus may trigger use-after-free, as follows: ext4_split_extent path = *ppath; ext4_split_extent_at(ppath) path = ext4_find_extent(ppath) ext4_split_extent_at(ppath) // ext4_find_extent fails to free path // but zeroout succeeds ext4_ext_show_leaf(inode, path) eh = path[depth].p_hdr // path use-after-free !!! Similar to ext4_split_extent_at(), we use *ppath directly as an input to ext4_ext_show_leaf(). Fix a spelling error by the way. Same problem in ext4_ext_handle_unwritten_extents(). Since 'path' is only used in ext4_ext_show_leaf(), remove 'path' and use *ppath directly. This issue is triggered only when EXT_DEBUG is defined and therefore does not affect functionality.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49968", "url": "https://ubuntu.com/security/CVE-2024-49968", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: filesystems without casefold feature cannot be mounted with siphash When mounting the ext4 filesystem, if the default hash version is set to DX_HASH_SIPHASH but the casefold feature is not set, exit the mounting.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49988", "url": "https://ubuntu.com/security/CVE-2024-49988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: add refcnt to ksmbd_conn struct When sending an oplock break request, opinfo->conn is used, But freed ->conn can be used on multichannel. This patch add a reference count to the ksmbd_conn struct so that it can be freed when it is no longer used.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49890", "url": "https://ubuntu.com/security/CVE-2024-49890", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: ensure the fw_info is not null before using it This resolves the dereference null return value warning reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49891", "url": "https://ubuntu.com/security/CVE-2024-49891", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata paths When the HBA is undergoing a reset or is handling an errata event, NULL ptr dereference crashes may occur in routines such as lpfc_sli_flush_io_rings(), lpfc_dev_loss_tmo_callbk(), or lpfc_abort_handler(). Add NULL ptr checks before dereferencing hdwq pointers that may have been freed due to operations colliding with a reset or errata event handler.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49892", "url": "https://ubuntu.com/security/CVE-2024-49892", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize get_bytes_per_element's default to 1 Variables, used as denominators and maybe not assigned to other values, should not be 0. bytes_per_element_y & bytes_per_element_c are initialized by get_bytes_per_element() which should never return 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50016", "url": "https://ubuntu.com/security/CVE-2024-50016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Avoid overflow assignment in link_dp_cts sampling_rate is an uint8_t but is assigned an unsigned int, and thus it can overflow. As a result, sampling_rate is changed to uint32_t. Similarly, LINK_QUAL_PATTERN_SET has a size of 2 bits, and it should only be assigned to a value less or equal than 4. This fixes 2 INTEGER_OVERFLOW issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49893", "url": "https://ubuntu.com/security/CVE-2024-49893", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check stream_status before it is used [WHAT & HOW] dc_state_get_stream_status can return null, and therefore null must be checked before stream_status is used. This fixes 1 NULL_RETURNS issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49969", "url": "https://ubuntu.com/security/CVE-2024-49969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 color transformation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_hw_format` function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:180 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:181 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:182 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49970", "url": "https://ubuntu.com/security/CVE-2024-49970", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Implement bounds check for stream encoder creation in DCN401 'stream_enc_regs' array is an array of dcn10_stream_enc_registers structures. The array is initialized with four elements, corresponding to the four calls to stream_enc_regs() in the array initializer. This means that valid indices for this array are 0, 1, 2, and 3. The error message 'stream_enc_regs' 4 <= 5 below, is indicating that there is an attempt to access this array with an index of 5, which is out of bounds. This could lead to undefined behavior Here, eng_id is used as an index to access the stream_enc_regs array. If eng_id is 5, this would result in an out-of-bounds access on the stream_enc_regs array. Thus fixing Buffer overflow error in dcn401_stream_encoder_create Found by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn401/dcn401_resource.c:1209 dcn401_stream_encoder_create() error: buffer overflow 'stream_enc_regs' 4 <= 5", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49894", "url": "https://ubuntu.com/security/CVE-2024-49894", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in degamma hardware format translation Fixes index out of bounds issue in `cm_helper_translate_curve_to_degamma_hw_format` function. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49895", "url": "https://ubuntu.com/security/CVE-2024-49895", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format translation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_degamma_hw_format` function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:338 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:339 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:340 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49971", "url": "https://ubuntu.com/security/CVE-2024-49971", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Increase array size of dummy_boolean [WHY] dml2_core_shared_mode_support and dml_core_mode_support access the third element of dummy_boolean, i.e. hw_debug5 = &s->dummy_boolean[2], when dummy_boolean has size of 2. Any assignment to hw_debug5 causes an OVERRUN. [HOW] Increase dummy_boolean's array size to 3. This fixes 2 OVERRUN issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49972", "url": "https://ubuntu.com/security/CVE-2024-49972", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Deallocate DML memory if allocation fails [Why] When DC state create DML memory allocation fails, memory is not deallocated subsequently, resulting in uninitialized structure that is not NULL. [How] Deallocate memory if DML memory allocation fails.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49896", "url": "https://ubuntu.com/security/CVE-2024-49896", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check stream before comparing them [WHAT & HOW] amdgpu_dm can pass a null stream to dc_is_stream_unchanged. It is necessary to check for null before dereferencing them. This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49897", "url": "https://ubuntu.com/security/CVE-2024-49897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check phantom_stream before it is used dcn32_enable_phantom_stream can return null, so returned value must be checked before used. This fixes 1 NULL_RETURNS issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49898", "url": "https://ubuntu.com/security/CVE-2024-49898", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null-initialized variables [WHAT & HOW] drr_timing and subvp_pipe are initialized to null and they are not always assigned new values. It is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49899", "url": "https://ubuntu.com/security/CVE-2024-49899", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize denominators' default to 1 [WHAT & HOW] Variables used as denominators and maybe not assigned to other values, should not be 0. Change their default to 1 so they are never 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49900", "url": "https://ubuntu.com/security/CVE-2024-49900", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uninit-value access of new_ea in ea_buffer syzbot reports that lzo1x_1_do_compress is using uninit-value: ===================================================== BUG: KMSAN: uninit-value in lzo1x_1_do_compress+0x19f9/0x2510 lib/lzo/lzo1x_compress.c:178 ... Uninit was stored to memory at: ea_put fs/jfs/xattr.c:639 [inline] ... Local variable ea_buf created at: __jfs_setxattr+0x5d/0x1ae0 fs/jfs/xattr.c:662 __jfs_xattr_set+0xe6/0x1f0 fs/jfs/xattr.c:934 ===================================================== The reason is ea_buf->new_ea is not initialized properly. Fix this by using memset to empty its content at the beginning in ea_get().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49901", "url": "https://ubuntu.com/security/CVE-2024-49901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm/adreno: Assign msm_gpu->pdev earlier to avoid nullptrs There are some cases, such as the one uncovered by Commit 46d4efcccc68 (\"drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails\") where msm_gpu_cleanup() : platform_set_drvdata(gpu->pdev, NULL); is called on gpu->pdev == NULL, as the GPU device has not been fully initialized yet. Turns out that there's more than just the aforementioned path that causes this to happen (e.g. the case when there's speedbin data in the catalog, but opp-supported-hw is missing in DT). Assigning msm_gpu->pdev earlier seems like the least painful solution to this, therefore do so. Patchwork: https://patchwork.freedesktop.org/patch/602742/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49902", "url": "https://ubuntu.com/security/CVE-2024-49902", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: check if leafidx greater than num leaves per dmap tree syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf. Shaggy: Modified sanity check to apply to control pages as well as leaf pages.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49903", "url": "https://ubuntu.com/security/CVE-2024-49903", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uaf in dbFreeBits [syzbot reported] ================================================================== BUG: KASAN: slab-use-after-free in __mutex_lock_common kernel/locking/mutex.c:587 [inline] BUG: KASAN: slab-use-after-free in __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 Read of size 8 at addr ffff8880229254b0 by task syz-executor357/5216 CPU: 0 UID: 0 PID: 5216 Comm: syz-executor357 Not tainted 6.11.0-rc3-syzkaller-00156-gd7a5aa4b3c00 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 __mutex_lock_common kernel/locking/mutex.c:587 [inline] __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 dbFreeBits+0x7ea/0xd90 fs/jfs/jfs_dmap.c:2390 dbFreeDmap fs/jfs/jfs_dmap.c:2089 [inline] dbFree+0x35b/0x680 fs/jfs/jfs_dmap.c:409 dbDiscardAG+0x8a9/0xa20 fs/jfs/jfs_dmap.c:1650 jfs_ioc_trim+0x433/0x670 fs/jfs/jfs_discard.c:100 jfs_ioctl+0x2d0/0x3e0 fs/jfs/ioctl.c:131 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 Freed by task 5218: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object+0xe0/0x150 mm/kasan/common.c:240 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2252 [inline] slab_free mm/slub.c:4473 [inline] kfree+0x149/0x360 mm/slub.c:4594 dbUnmount+0x11d/0x190 fs/jfs/jfs_dmap.c:278 jfs_mount_rw+0x4ac/0x6a0 fs/jfs/jfs_mount.c:247 jfs_remount+0x3d1/0x6b0 fs/jfs/super.c:454 reconfigure_super+0x445/0x880 fs/super.c:1083 vfs_cmd_reconfigure fs/fsopen.c:263 [inline] vfs_fsconfig_locked fs/fsopen.c:292 [inline] __do_sys_fsconfig fs/fsopen.c:473 [inline] __se_sys_fsconfig+0xb6e/0xf80 fs/fsopen.c:345 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 [Analysis] There are two paths (dbUnmount and jfs_ioc_trim) that generate race condition when accessing bmap, which leads to the occurrence of uaf. Use the lock s_umount to synchronize them, in order to avoid uaf caused by race condition.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49904", "url": "https://ubuntu.com/security/CVE-2024-49904", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add list empty check to avoid null pointer issue Add list empty check to avoid null pointer issues in some corner cases. - list_for_each_entry_safe()", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49989", "url": "https://ubuntu.com/security/CVE-2024-49989", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix double free issue during amdgpu module unload Flexible endpoints use DIGs from available inflexible endpoints, so only the encoders of inflexible links need to be freed. Otherwise, a double free issue may occur when unloading the amdgpu module. [ 279.190523] RIP: 0010:__slab_free+0x152/0x2f0 [ 279.190577] Call Trace: [ 279.190580] [ 279.190582] ? show_regs+0x69/0x80 [ 279.190590] ? die+0x3b/0x90 [ 279.190595] ? do_trap+0xc8/0xe0 [ 279.190601] ? do_error_trap+0x73/0xa0 [ 279.190605] ? __slab_free+0x152/0x2f0 [ 279.190609] ? exc_invalid_op+0x56/0x70 [ 279.190616] ? __slab_free+0x152/0x2f0 [ 279.190642] ? asm_exc_invalid_op+0x1f/0x30 [ 279.190648] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191096] ? __slab_free+0x152/0x2f0 [ 279.191102] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191469] kfree+0x260/0x2b0 [ 279.191474] dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191821] link_destroy+0xd7/0x130 [amdgpu] [ 279.192248] dc_destruct+0x90/0x270 [amdgpu] [ 279.192666] dc_destroy+0x19/0x40 [amdgpu] [ 279.193020] amdgpu_dm_fini+0x16e/0x200 [amdgpu] [ 279.193432] dm_hw_fini+0x26/0x40 [amdgpu] [ 279.193795] amdgpu_device_fini_hw+0x24c/0x400 [amdgpu] [ 279.194108] amdgpu_driver_unload_kms+0x4f/0x70 [amdgpu] [ 279.194436] amdgpu_pci_remove+0x40/0x80 [amdgpu] [ 279.194632] pci_device_remove+0x3a/0xa0 [ 279.194638] device_remove+0x40/0x70 [ 279.194642] device_release_driver_internal+0x1ad/0x210 [ 279.194647] driver_detach+0x4e/0xa0 [ 279.194650] bus_remove_driver+0x6f/0xf0 [ 279.194653] driver_unregister+0x33/0x60 [ 279.194657] pci_unregister_driver+0x44/0x90 [ 279.194662] amdgpu_exit+0x19/0x1f0 [amdgpu] [ 279.194939] __do_sys_delete_module.isra.0+0x198/0x2f0 [ 279.194946] __x64_sys_delete_module+0x16/0x20 [ 279.194950] do_syscall_64+0x58/0x120 [ 279.194954] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 279.194980] ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49905", "url": "https://ubuntu.com/security/CVE-2024-49905", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for 'afb' in amdgpu_dm_plane_handle_cursor_update (v2) This commit adds a null check for the 'afb' variable in the amdgpu_dm_plane_handle_cursor_update function. Previously, 'afb' was assumed to be null, but was used later in the code without a null check. This could potentially lead to a null pointer dereference. Changes since v1: - Moved the null check for 'afb' to the line where 'afb' is used. (Alex) Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:1298 amdgpu_dm_plane_handle_cursor_update() error: we previously assumed 'afb' could be null (see line 1252)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49906", "url": "https://ubuntu.com/security/CVE-2024-49906", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before try to access it [why & how] Change the order of the pipe_ctx->plane_state check to ensure that plane_state is not null before accessing it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49907", "url": "https://ubuntu.com/security/CVE-2024-49907", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before using dc->clk_mgr [WHY & HOW] dc->clk_mgr is null checked previously in the same function, indicating it might be null. Passing \"dc\" to \"dc->hwss.apply_idle_power_optimizations\", which dereferences null \"dc->clk_mgr\". (The function pointer resolves to \"dcn35_apply_idle_power_optimizations\".) This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49908", "url": "https://ubuntu.com/security/CVE-2024-49908", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for 'afb' in amdgpu_dm_update_cursor (v2) This commit adds a null check for the 'afb' variable in the amdgpu_dm_update_cursor function. Previously, 'afb' was assumed to be null at line 8388, but was used later in the code without a null check. This could potentially lead to a null pointer dereference. Changes since v1: - Moved the null check for 'afb' to the line where 'afb' is used. (Alex) Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:8433 amdgpu_dm_update_cursor() \terror: we previously assumed 'afb' could be null (see line 8388)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50177", "url": "https://ubuntu.com/security/CVE-2024-50177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix a UBSAN warning in DML2.1 When programming phantom pipe, since cursor_width is explicity set to 0, this causes calculation logic to trigger overflow for an unsigned int triggering the kernel's UBSAN check as below: [ 40.962845] UBSAN: shift-out-of-bounds in /tmp/amd.EfpumTkO/amd/amdgpu/../display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c:3312:34 [ 40.962849] shift exponent 4294967170 is too large for 32-bit type 'unsigned int' [ 40.962852] CPU: 1 PID: 1670 Comm: gnome-shell Tainted: G W OE 6.5.0-41-generic #41~22.04.2-Ubuntu [ 40.962854] Hardware name: Gigabyte Technology Co., Ltd. X670E AORUS PRO X/X670E AORUS PRO X, BIOS F21 01/10/2024 [ 40.962856] Call Trace: [ 40.962857] [ 40.962860] dump_stack_lvl+0x48/0x70 [ 40.962870] dump_stack+0x10/0x20 [ 40.962872] __ubsan_handle_shift_out_of_bounds+0x1ac/0x360 [ 40.962878] calculate_cursor_req_attributes.cold+0x1b/0x28 [amdgpu] [ 40.963099] dml_core_mode_support+0x6b91/0x16bc0 [amdgpu] [ 40.963327] ? srso_alias_return_thunk+0x5/0x7f [ 40.963331] ? CalculateWatermarksMALLUseAndDRAMSpeedChangeSupport+0x18b8/0x2790 [amdgpu] [ 40.963534] ? srso_alias_return_thunk+0x5/0x7f [ 40.963536] ? dml_core_mode_support+0xb3db/0x16bc0 [amdgpu] [ 40.963730] dml2_core_calcs_mode_support_ex+0x2c/0x90 [amdgpu] [ 40.963906] ? srso_alias_return_thunk+0x5/0x7f [ 40.963909] ? dml2_core_calcs_mode_support_ex+0x2c/0x90 [amdgpu] [ 40.964078] core_dcn4_mode_support+0x72/0xbf0 [amdgpu] [ 40.964247] dml2_top_optimization_perform_optimization_phase+0x1d3/0x2a0 [amdgpu] [ 40.964420] dml2_build_mode_programming+0x23d/0x750 [amdgpu] [ 40.964587] dml21_validate+0x274/0x770 [amdgpu] [ 40.964761] ? srso_alias_return_thunk+0x5/0x7f [ 40.964763] ? resource_append_dpp_pipes_for_plane_composition+0x27c/0x3b0 [amdgpu] [ 40.964942] dml2_validate+0x504/0x750 [amdgpu] [ 40.965117] ? dml21_copy+0x95/0xb0 [amdgpu] [ 40.965291] ? srso_alias_return_thunk+0x5/0x7f [ 40.965295] dcn401_validate_bandwidth+0x4e/0x70 [amdgpu] [ 40.965491] update_planes_and_stream_state+0x38d/0x5c0 [amdgpu] [ 40.965672] update_planes_and_stream_v3+0x52/0x1e0 [amdgpu] [ 40.965845] ? srso_alias_return_thunk+0x5/0x7f [ 40.965849] dc_update_planes_and_stream+0x71/0xb0 [amdgpu] Fix this by adding a guard for checking cursor width before triggering the size calculation.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49909", "url": "https://ubuntu.com/security/CVE-2024-49909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn32_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn32_set_output_transfer_func function. Previously, set_output_gamma was being checked for null, but then it was being dereferenced without any null check. This could lead to a null pointer dereference if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49910", "url": "https://ubuntu.com/security/CVE-2024-49910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn401_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn401_set_output_transfer_func function. Previously, set_output_gamma was being checked for null, but then it was being dereferenced without any null check. This could lead to a null pointer dereference if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49911", "url": "https://ubuntu.com/security/CVE-2024-49911", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn20_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn20_set_output_transfer_func function. Previously, set_output_gamma was being checked for null at line 1030, but then it was being dereferenced without any null check at line 1048. This could potentially lead to a null pointer dereference error if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma at line 1048.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49912", "url": "https://ubuntu.com/security/CVE-2024-49912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Handle null 'stream_status' in 'planes_changed_for_existing_stream' This commit adds a null check for 'stream_status' in the function 'planes_changed_for_existing_stream'. Previously, the code assumed 'stream_status' could be null, but did not handle the case where it was actually null. This could lead to a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:3784 planes_changed_for_existing_stream() error: we previously assumed 'stream_status' could be null (see line 3774)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49913", "url": "https://ubuntu.com/security/CVE-2024-49913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for top_pipe_to_program in commit_planes_for_stream This commit addresses a null pointer dereference issue in the `commit_planes_for_stream` function at line 4140. The issue could occur when `top_pipe_to_program` is null. The fix adds a check to ensure `top_pipe_to_program` is not null before accessing its stream_res. This prevents a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:4140 commit_planes_for_stream() error: we previously assumed 'top_pipe_to_program' could be null (see line 3906)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49914", "url": "https://ubuntu.com/security/CVE-2024-49914", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for pipe_ctx->plane_state in dcn20_program_pipe This commit addresses a null pointer dereference issue in the `dcn20_program_pipe` function. The issue could occur when `pipe_ctx->plane_state` is null. The fix adds a check to ensure `pipe_ctx->plane_state` is not null before accessing. This prevents a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn20/dcn20_hwseq.c:1925 dcn20_program_pipe() error: we previously assumed 'pipe_ctx->plane_state' could be null (see line 1877)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49915", "url": "https://ubuntu.com/security/CVE-2024-49915", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr in dcn32_init_hw This commit addresses a potential null pointer dereference issue in the `dcn32_init_hw` function. The issue could occur when `dc->clk_mgr` is null. The fix adds a check to ensure `dc->clk_mgr` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn32/dcn32_hwseq.c:961 dcn32_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 782)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49916", "url": "https://ubuntu.com/security/CVE-2024-49916", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in dcn401_init_hw This commit addresses a potential null pointer dereference issue in the `dcn401_init_hw` function. The issue could occur when `dc->clk_mgr` or `dc->clk_mgr->funcs` is null. The fix adds a check to ensure `dc->clk_mgr` and `dc->clk_mgr->funcs` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn401/dcn401_hwseq.c:416 dcn401_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 225)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49917", "url": "https://ubuntu.com/security/CVE-2024-49917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in dcn30_init_hw This commit addresses a potential null pointer dereference issue in the `dcn30_init_hw` function. The issue could occur when `dc->clk_mgr` or `dc->clk_mgr->funcs` is null. The fix adds a check to ensure `dc->clk_mgr` and `dc->clk_mgr->funcs` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:789 dcn30_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 628)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49918", "url": "https://ubuntu.com/security/CVE-2024-49918", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for head_pipe in dcn32_acquire_idle_pipe_for_head_pipe_in_layer This commit addresses a potential null pointer dereference issue in the `dcn32_acquire_idle_pipe_for_head_pipe_in_layer` function. The issue could occur when `head_pipe` is null. The fix adds a check to ensure `head_pipe` is not null before asserting it. If `head_pipe` is null, the function returns NULL to prevent a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn32/dcn32_resource.c:2690 dcn32_acquire_idle_pipe_for_head_pipe_in_layer() error: we previously assumed 'head_pipe' could be null (see line 2681)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49919", "url": "https://ubuntu.com/security/CVE-2024-49919", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for head_pipe in dcn201_acquire_free_pipe_for_layer This commit addresses a potential null pointer dereference issue in the `dcn201_acquire_free_pipe_for_layer` function. The issue could occur when `head_pipe` is null. The fix adds a check to ensure `head_pipe` is not null before asserting it. If `head_pipe` is null, the function returns NULL to prevent a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn201/dcn201_resource.c:1016 dcn201_acquire_free_pipe_for_layer() error: we previously assumed 'head_pipe' could be null (see line 1010)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49991", "url": "https://ubuntu.com/security/CVE-2024-49991", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer Pass pointer reference to amdgpu_bo_unref to clear the correct pointer, otherwise amdgpu_bo_unref clear the local variable, the original pointer not set to NULL, this could cause use-after-free bug.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49920", "url": "https://ubuntu.com/security/CVE-2024-49920", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before multiple uses [WHAT & HOW] Poniters, such as stream_enc and dc->bw_vbios, are null checked previously in the same function, so Coverity warns \"implies that stream_enc and dc->bw_vbios might be null\". They are used multiple times in the subsequent code and need to be checked. This fixes 10 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49921", "url": "https://ubuntu.com/security/CVE-2024-49921", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before used [WHAT & HOW] Poniters, such as dc->clk_mgr, are null checked previously in the same function, so Coverity warns \"implies that \"dc->clk_mgr\" might be null\". As a result, these pointers need to be checked when used again. This fixes 10 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49922", "url": "https://ubuntu.com/security/CVE-2024-49922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before using them [WHAT & HOW] These pointers are null checked previously in the same function, indicating they might be null as reported by Coverity. As a result, they need to be checked when used again. This fixes 3 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49923", "url": "https://ubuntu.com/security/CVE-2024-49923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Pass non-null to dcn20_validate_apply_pipe_split_flags [WHAT & HOW] \"dcn20_validate_apply_pipe_split_flags\" dereferences merge, and thus it cannot be a null pointer. Let's pass a valid pointer to avoid null dereference. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49992", "url": "https://ubuntu.com/security/CVE-2024-49992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/stm: Avoid use-after-free issues with crtc and plane ltdc_load() calls functions drm_crtc_init_with_planes(), drm_universal_plane_init() and drm_encoder_init(). These functions should not be called with parameters allocated with devm_kzalloc() to avoid use-after-free issues [1]. Use allocations managed by the DRM framework. Found by Linux Verification Center (linuxtesting.org). [1] https://lore.kernel.org/lkml/u366i76e3qhh3ra5oxrtngjtm2u5lterkekcz6y2jkndhuxzli@diujon4h7qwb/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49993", "url": "https://ubuntu.com/security/CVE-2024-49993", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49924", "url": "https://ubuntu.com/security/CVE-2024-49924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: pxafb: Fix possible use after free in pxafb_task() In the pxafb_probe function, it calls the pxafb_init_fbinfo function, after which &fbi->task is associated with pxafb_task. Moreover, within this pxafb_init_fbinfo function, the pxafb_blank function within the &pxafb_ops struct is capable of scheduling work. If we remove the module which will call pxafb_remove to make cleanup, it will call unregister_framebuffer function which can call do_unregister_framebuffer to free fbi->fb through put_fb_info(fb_info), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | pxafb_task pxafb_remove | unregister_framebuffer(info) | do_unregister_framebuffer(fb_info) | put_fb_info(fb_info) | // free fbi->fb | set_ctrlr_state(fbi, state) | __pxafb_lcd_power(fbi, 0) | fbi->lcd_power(on, &fbi->fb.var) | //use fbi->fb Fix it by ensuring that the work is canceled before proceeding with the cleanup in pxafb_remove. Note that only root user can remove the driver at runtime.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49925", "url": "https://ubuntu.com/security/CVE-2024-49925", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: efifb: Register sysfs groups through driver core The driver core can register and cleanup sysfs groups already. Make use of that functionality to simplify the error handling and cleanup. Also avoid a UAF race during unregistering where the sysctl attributes were usable after the info struct was freed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49926", "url": "https://ubuntu.com/security/CVE-2024-49926", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rcu-tasks: Fix access non-existent percpu rtpcp variable in rcu_tasks_need_gpcb() For kernels built with CONFIG_FORCE_NR_CPUS=y, the nr_cpu_ids is defined as NR_CPUS instead of the number of possible cpus, this will cause the following system panic: smpboot: Allowing 4 CPUs, 0 hotplug CPUs ... setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:512 nr_node_ids:1 ... BUG: unable to handle page fault for address: ffffffff9911c8c8 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 15 Comm: rcu_tasks_trace Tainted: G W 6.6.21 #1 5dc7acf91a5e8e9ac9dcfc35bee0245691283ea6 RIP: 0010:rcu_tasks_need_gpcb+0x25d/0x2c0 RSP: 0018:ffffa371c00a3e60 EFLAGS: 00010082 CR2: ffffffff9911c8c8 CR3: 000000040fa20005 CR4: 00000000001706f0 Call Trace: ? __die+0x23/0x80 ? page_fault_oops+0xa4/0x180 ? exc_page_fault+0x152/0x180 ? asm_exc_page_fault+0x26/0x40 ? rcu_tasks_need_gpcb+0x25d/0x2c0 ? __pfx_rcu_tasks_kthread+0x40/0x40 rcu_tasks_one_gp+0x69/0x180 rcu_tasks_kthread+0x94/0xc0 kthread+0xe8/0x140 ? __pfx_kthread+0x40/0x40 ret_from_fork+0x34/0x80 ? __pfx_kthread+0x40/0x40 ret_from_fork_asm+0x1b/0x80 Considering that there may be holes in the CPU numbers, use the maximum possible cpu number, instead of nr_cpu_ids, for configuring enqueue and dequeue limits. [ neeraj.upadhyay: Fix htmldocs build error reported by Stephen Rothwell ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50007", "url": "https://ubuntu.com/security/CVE-2024-50007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: asihpi: Fix potential OOB array access ASIHPI driver stores some values in the static array upon a response from the driver, and its index depends on the firmware. We shouldn't trust it blindly. This patch adds a sanity check of the array index to fit in the array size.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50017", "url": "https://ubuntu.com/security/CVE-2024-50017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm/ident_map: Use gbpages only where full GB page should be mapped. When ident_pud_init() uses only GB pages to create identity maps, large ranges of addresses not actually requested can be included in the resulting table; a 4K request will map a full GB. This can include a lot of extra address space past that requested, including areas marked reserved by the BIOS. That allows processor speculation into reserved regions, that on UV systems can cause system halts. Only use GB pages when map creation requests include the full GB page of space. Fall back to using smaller 2M pages when only portions of a GB page are included in the request. No attempt is made to coalesce mapping requests. If a request requires a map entry at the 2M (pmd) level, subsequent mapping requests within the same 1G region will also be at the pmd level, even if adjacent or overlapping such requests could have been combined to map a full GB page. Existing usage starts with larger regions and then adds smaller regions, so this should not have any great consequence.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49927", "url": "https://ubuntu.com/security/CVE-2024-49927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/ioapic: Handle allocation failures gracefully Breno observed panics when using failslab under certain conditions during runtime: can not alloc irq_pin_list (-1,0,20) Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed panic+0x4e9/0x590 mp_irqdomain_alloc+0x9ab/0xa80 irq_domain_alloc_irqs_locked+0x25d/0x8d0 __irq_domain_alloc_irqs+0x80/0x110 mp_map_pin_to_irq+0x645/0x890 acpi_register_gsi_ioapic+0xe6/0x150 hpet_open+0x313/0x480 That's a pointless panic which is a leftover of the historic IO/APIC code which panic'ed during early boot when the interrupt allocation failed. The only place which might justify panic is the PIT/HPET timer_check() code which tries to figure out whether the timer interrupt is delivered through the IO/APIC. But that code does not require to handle interrupt allocation failures. If the interrupt cannot be allocated then timer delivery fails and it either panics due to that or falls back to legacy mode. Cure this by removing the panic wrapper around __add_pin_to_irq_node() and making mp_irqdomain_alloc() aware of the failure condition and handle it as any other failure in this function gracefully.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50008", "url": "https://ubuntu.com/security/CVE-2024-50008", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_cmd_802_11_scan_ext() Replace one-element array with a flexible-array member in `struct host_cmd_ds_802_11_scan_ext`. With this, fix the following warning: elo 16 17:51:58 surfacebook kernel: ------------[ cut here ]------------ elo 16 17:51:58 surfacebook kernel: memcpy: detected field-spanning write (size 243) of single field \"ext_scan->tlv_buffer\" at drivers/net/wireless/marvell/mwifiex/scan.c:2239 (size 1) elo 16 17:51:58 surfacebook kernel: WARNING: CPU: 0 PID: 498 at drivers/net/wireless/marvell/mwifiex/scan.c:2239 mwifiex_cmd_802_11_scan_ext+0x83/0x90 [mwifiex]", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50018", "url": "https://ubuntu.com/security/CVE-2024-50018", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49928", "url": "https://ubuntu.com/security/CVE-2024-49928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: avoid reading out of bounds when loading TX power FW elements Because the loop-expression will do one more time before getting false from cond-expression, the original code copied one more entry size beyond valid region. Fix it by moving the entry copy to loop-body.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50178", "url": "https://ubuntu.com/security/CVE-2024-50178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: loongson3: Use raw_smp_processor_id() in do_service_request() Use raw_smp_processor_id() instead of plain smp_processor_id() in do_service_request(), otherwise we may get some errors with the driver enabled: BUG: using smp_processor_id() in preemptible [00000000] code: (udev-worker)/208 caller is loongson3_cpufreq_probe+0x5c/0x250 [loongson3_cpufreq]", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50009", "url": "https://ubuntu.com/security/CVE-2024-50009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: amd-pstate: add check for cpufreq_cpu_get's return value cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it and return in case of error. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49994", "url": "https://ubuntu.com/security/CVE-2024-49994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix integer overflow in BLKSECDISCARD I independently rediscovered \tcommit 22d24a544b0d49bbcbd61c8c0eaf77d3c9297155 \tblock: fix overflow in blk_ioctl_discard() but for secure erase. Same problem: \tuint64_t r[2] = {512, 18446744073709551104ULL}; \tioctl(fd, BLKSECDISCARD, r); will enter near infinite loop inside blkdev_issue_secure_erase(): \ta.out: attempt to access beyond end of device \tloop0: rw=5, sector=3399043073, nr_sectors = 1024 limit=2048 \tbio_check_eod: 3286214 callbacks suppressed", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49929", "url": "https://ubuntu.com/security/CVE-2024-49929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: avoid NULL pointer dereference iwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta pointer is not NULL. It retrieves this pointer using iwl_mvm_sta_from_mac80211, which is dereferencing the ieee80211_sta pointer. If sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL pointer. Fix this by checking the sta pointer before retrieving the mvmsta from it. If sta is not NULL, then mvmsta isn't either.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49995", "url": "https://ubuntu.com/security/CVE-2024-49995", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: guard against string buffer overrun Smatch reports that copying media_name and if_name to name_parts may overwrite the destination. .../bearer.c:166 bearer_name_validate() error: strcpy() 'media_name' too large for 'name_parts->media_name' (32 vs 16) .../bearer.c:167 bearer_name_validate() error: strcpy() 'if_name' too large for 'name_parts->if_name' (1010102 vs 16) This does seem to be the case so guard against this possibility by using strscpy() and failing if truncation occurs. Introduced by commit b97bf3fd8f6a (\"[TIPC] Initial merge\") Compile tested only.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49962", "url": "https://ubuntu.com/security/CVE-2024-49962", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in acpi_db_convert_to_package() ACPICA commit 4d4547cf13cca820ff7e0f859ba83e1a610b9fd0 ACPI_ALLOCATE_ZEROED() may fail, elements might be NULL and will cause NULL pointer dereference later. [ rjw: Subject and changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49930", "url": "https://ubuntu.com/security/CVE-2024-49930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix array out-of-bound access in SoC stats Currently, the ath11k_soc_dp_stats::hal_reo_error array is defined with a maximum size of DP_REO_DST_RING_MAX. However, the ath11k_dp_process_rx() function access ath11k_soc_dp_stats::hal_reo_error using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath11k_dp_process_rx() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49931", "url": "https://ubuntu.com/security/CVE-2024-49931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix array out-of-bound access in SoC stats Currently, the ath12k_soc_dp_stats::hal_reo_error array is defined with a maximum size of DP_REO_DST_RING_MAX. However, the ath12k_dp_rx_process() function access ath12k_soc_dp_stats::hal_reo_error using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath12k_dp_rx_process() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49932", "url": "https://ubuntu.com/security/CVE-2024-49932", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: don't readahead the relocation inode on RST On relocation we're doing readahead on the relocation inode, but if the filesystem is backed by a RAID stripe tree we can get ENOENT (e.g. due to preallocated extents not being mapped in the RST) from the lookup. But readahead doesn't handle the error and submits invalid reads to the device, causing an assertion in the scatter-gather list code: BTRFS info (device nvme1n1): balance: start -d -m -s BTRFS info (device nvme1n1): relocating block group 6480920576 flags data|raid0 BTRFS error (device nvme1n1): cannot find raid-stripe for logical [6481928192, 6481969152] devid 2, profile raid0 ------------[ cut here ]------------ kernel BUG at include/linux/scatterlist.h:115! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 1012 Comm: btrfs Not tainted 6.10.0-rc7+ #567 RIP: 0010:__blk_rq_map_sg+0x339/0x4a0 RSP: 0018:ffffc90001a43820 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffea00045d4802 RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000 RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000001000 R12: ffff8881003d10b8 R13: ffffc90001a438f0 R14: 0000000000000000 R15: 0000000000003000 FS: 00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000002cd11000 CR3: 00000001109ea001 CR4: 0000000000370eb0 Call Trace: ? __die_body.cold+0x14/0x25 ? die+0x2e/0x50 ? do_trap+0xca/0x110 ? do_error_trap+0x65/0x80 ? __blk_rq_map_sg+0x339/0x4a0 ? exc_invalid_op+0x50/0x70 ? __blk_rq_map_sg+0x339/0x4a0 ? asm_exc_invalid_op+0x1a/0x20 ? __blk_rq_map_sg+0x339/0x4a0 nvme_prep_rq.part.0+0x9d/0x770 nvme_queue_rq+0x7d/0x1e0 __blk_mq_issue_directly+0x2a/0x90 ? blk_mq_get_budget_and_tag+0x61/0x90 blk_mq_try_issue_list_directly+0x56/0xf0 blk_mq_flush_plug_list.part.0+0x52b/0x5d0 __blk_flush_plug+0xc6/0x110 blk_finish_plug+0x28/0x40 read_pages+0x160/0x1c0 page_cache_ra_unbounded+0x109/0x180 relocate_file_extent_cluster+0x611/0x6a0 ? btrfs_search_slot+0xba4/0xd20 ? balance_dirty_pages_ratelimited_flags+0x26/0xb00 relocate_data_extent.constprop.0+0x134/0x160 relocate_block_group+0x3f2/0x500 btrfs_relocate_block_group+0x250/0x430 btrfs_relocate_chunk+0x3f/0x130 btrfs_balance+0x71b/0xef0 ? kmalloc_trace_noprof+0x13b/0x280 btrfs_ioctl+0x2c2e/0x3030 ? kvfree_call_rcu+0x1e6/0x340 ? list_lru_add_obj+0x66/0x80 ? mntput_no_expire+0x3a/0x220 __x64_sys_ioctl+0x96/0xc0 do_syscall_64+0x54/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fcc04514f9b Code: Unable to access opcode bytes at 0x7fcc04514f71. RSP: 002b:00007ffeba923370 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fcc04514f9b RDX: 00007ffeba923460 RSI: 00000000c4009420 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000013 R09: 0000000000000001 R10: 00007fcc043fbba8 R11: 0000000000000246 R12: 00007ffeba924fc5 R13: 00007ffeba923460 R14: 0000000000000002 R15: 00000000004d4bb0 Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:__blk_rq_map_sg+0x339/0x4a0 RSP: 0018:ffffc90001a43820 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffea00045d4802 RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000 RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000001000 R12: ffff8881003d10b8 R13: ffffc90001a438f0 R14: 0000000000000000 R15: 0000000000003000 FS: 00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcc04514f71 CR3: 00000001109ea001 CR4: 0000000000370eb0 Kernel p ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49933", "url": "https://ubuntu.com/security/CVE-2024-49933", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk_iocost: fix more out of bound shifts Recently running UBSAN caught few out of bound shifts in the ioc_forgive_debts() function: UBSAN: shift-out-of-bounds in block/blk-iocost.c:2142:38 shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long long') ... UBSAN: shift-out-of-bounds in block/blk-iocost.c:2144:30 shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long long') ... Call Trace: dump_stack_lvl+0xca/0x130 __ubsan_handle_shift_out_of_bounds+0x22c/0x280 ? __lock_acquire+0x6441/0x7c10 ioc_timer_fn+0x6cec/0x7750 ? blk_iocost_init+0x720/0x720 ? call_timer_fn+0x5d/0x470 call_timer_fn+0xfa/0x470 ? blk_iocost_init+0x720/0x720 __run_timer_base+0x519/0x700 ... Actual impact of this issue was not identified but I propose to fix the undefined behaviour. The proposed fix to prevent those out of bound shifts consist of precalculating exponent before using it the shift operations by taking min value from the actual exponent and maximum possible number of bits.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49934", "url": "https://ubuntu.com/security/CVE-2024-49934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/inode: Prevent dump_mapping() accessing invalid dentry.d_name.name It's observed that a crash occurs during hot-remove a memory device, in which user is accessing the hugetlb. See calltrace as following: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 14045 at arch/x86/mm/fault.c:1278 do_user_addr_fault+0x2a0/0x790 Modules linked in: kmem device_dax cxl_mem cxl_pmem cxl_port cxl_pci dax_hmem dax_pmem nd_pmem cxl_acpi nd_btt cxl_core crc32c_intel nvme virtiofs fuse nvme_core nfit libnvdimm dm_multipath scsi_dh_rdac scsi_dh_emc s mirror dm_region_hash dm_log dm_mod CPU: 1 PID: 14045 Comm: daxctl Not tainted 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:do_user_addr_fault+0x2a0/0x790 Code: 48 8b 00 a8 04 0f 84 b5 fe ff ff e9 1c ff ff ff 4c 89 e9 4c 89 e2 be 01 00 00 00 bf 02 00 00 00 e8 b5 ef 24 00 e9 42 fe ff ff <0f> 0b 48 83 c4 08 4c 89 ea 48 89 ee 4c 89 e7 5b 5d 41 5c 41 5d 41 RSP: 0000:ffffc90000a575f0 EFLAGS: 00010046 RAX: ffff88800c303600 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000001000 RSI: ffffffff82504162 RDI: ffffffff824b2c36 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffc90000a57658 R13: 0000000000001000 R14: ffff88800bc2e040 R15: 0000000000000000 FS: 00007f51cb57d880(0000) GS:ffff88807fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000001000 CR3: 00000000072e2004 CR4: 00000000001706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn+0x8d/0x190 ? do_user_addr_fault+0x2a0/0x790 ? report_bug+0x1c3/0x1d0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? do_user_addr_fault+0x2a0/0x790 ? exc_page_fault+0x31/0x200 exc_page_fault+0x68/0x200 <...snip...> BUG: unable to handle page fault for address: 0000000000001000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI ---[ end trace 0000000000000000 ]--- BUG: unable to handle page fault for address: 0000000000001000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 14045 Comm: daxctl Kdump: loaded Tainted: G W 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:dentry_name+0x1f4/0x440 <...snip...> ? dentry_name+0x2fa/0x440 vsnprintf+0x1f3/0x4f0 vprintk_store+0x23a/0x540 vprintk_emit+0x6d/0x330 _printk+0x58/0x80 dump_mapping+0x10b/0x1a0 ? __pfx_free_object_rcu+0x10/0x10 __dump_page+0x26b/0x3e0 ? vprintk_emit+0xe0/0x330 ? _printk+0x58/0x80 ? dump_page+0x17/0x50 dump_page+0x17/0x50 do_migrate_range+0x2f7/0x7f0 ? do_migrate_range+0x42/0x7f0 ? offline_pages+0x2f4/0x8c0 offline_pages+0x60a/0x8c0 memory_subsys_offline+0x9f/0x1c0 ? lockdep_hardirqs_on+0x77/0x100 ? _raw_spin_unlock_irqrestore+0x38/0x60 device_offline+0xe3/0x110 state_store+0x6e/0xc0 kernfs_fop_write_iter+0x143/0x200 vfs_write+0x39f/0x560 ksys_write+0x65/0xf0 do_syscall_64+0x62/0x130 Previously, some sanity check have been done in dump_mapping() before the print facility parsing '%pd' though, it's still possible to run into an invalid dentry.d_name.name. Since dump_mapping() only needs to dump the filename only, retrieve it by itself in a safer way to prevent an unnecessary crash. Note that either retrieving the filename with '%pd' or strncpy_from_kernel_nofault(), the filename could be unreliable.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49935", "url": "https://ubuntu.com/security/CVE-2024-49935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: PAD: fix crash in exit_round_robin() The kernel occasionally crashes in cpumask_clear_cpu(), which is called within exit_round_robin(), because when executing clear_bit(nr, addr) with nr set to 0xffffffff, the address calculation may cause misalignment within the memory, leading to access to an invalid memory address. ---------- BUG: unable to handle kernel paging request at ffffffffe0740618 ... CPU: 3 PID: 2919323 Comm: acpi_pad/14 Kdump: loaded Tainted: G OE X --------- - - 4.18.0-425.19.2.el8_7.x86_64 #1 ... RIP: 0010:power_saving_thread+0x313/0x411 [acpi_pad] Code: 89 cd 48 89 d3 eb d1 48 c7 c7 55 70 72 c0 e8 64 86 b0 e4 c6 05 0d a1 02 00 01 e9 bc fd ff ff 45 89 e4 42 8b 04 a5 20 82 72 c0 48 0f b3 05 f4 9c 01 00 42 c7 04 a5 20 82 72 c0 ff ff ff ff 31 RSP: 0018:ff72a5d51fa77ec8 EFLAGS: 00010202 RAX: 00000000ffffffff RBX: ff462981e5d8cb80 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246 RBP: ff46297556959d80 R08: 0000000000000382 R09: ff46297c8d0f38d8 R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000000e R13: 0000000000000000 R14: ffffffffffffffff R15: 000000000000000e FS: 0000000000000000(0000) GS:ff46297a800c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffe0740618 CR3: 0000007e20410004 CR4: 0000000000771ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? acpi_pad_add+0x120/0x120 [acpi_pad] kthread+0x10b/0x130 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x1f/0x40 ... CR2: ffffffffe0740618 crash> dis -lr ffffffffc0726923 ... /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 114 0xffffffffc0726918 :\tmov %r12d,%r12d /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 325 0xffffffffc072691b :\tmov -0x3f8d7de0(,%r12,4),%eax /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./arch/x86/include/asm/bitops.h: 80 0xffffffffc0726923 :\tlock btr %rax,0x19cf4(%rip) # 0xffffffffc0740620 crash> px tsk_in_cpu[14] $66 = 0xffffffff crash> px 0xffffffffc072692c+0x19cf4 $99 = 0xffffffffc0740620 crash> sym 0xffffffffc0740620 ffffffffc0740620 (b) pad_busy_cpus_bits [acpi_pad] crash> px pad_busy_cpus_bits[0] $42 = 0xfffc0 ---------- To fix this, ensure that tsk_in_cpu[tsk_index] != -1 before calling cpumask_clear_cpu() in exit_round_robin(), just as it is done in round_robin_cpu(). [ rjw: Subject edit, avoid updates to the same value ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49936", "url": "https://ubuntu.com/security/CVE-2024-49936", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/xen-netback: prevent UAF in xenvif_flush_hash() During the list_for_each_entry_rcu iteration call of xenvif_flush_hash, kfree_rcu does not exist inside the rcu read critical section, so if kfree_rcu is called when the rcu grace period ends during the iteration, UAF occurs when accessing head->next after the entry becomes free. Therefore, to solve this, you need to change it to list_for_each_entry_safe.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49937", "url": "https://ubuntu.com/security/CVE-2024-49937", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Set correct chandef when starting CAC When starting CAC in a mode other than AP mode, it return a \"WARNING: CPU: 0 PID: 63 at cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]\" caused by the chandef.chan being null at the end of CAC. Solution: Ensure the channel definition is set for the different modes when starting CAC to avoid getting a NULL 'chan' at the end of CAC. Call Trace: ? show_regs.part.0+0x14/0x16 ? __warn+0x67/0xc0 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? report_bug+0xa7/0x130 ? exc_overflow+0x30/0x30 ? handle_bug+0x27/0x50 ? exc_invalid_op+0x18/0x60 ? handle_exception+0xf6/0xf6 ? exc_overflow+0x30/0x30 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? exc_overflow+0x30/0x30 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? regulatory_propagate_dfs_state.cold+0x1b/0x4c [cfg80211] ? cfg80211_propagate_cac_done_wk+0x1a/0x30 [cfg80211] ? process_one_work+0x165/0x280 ? worker_thread+0x120/0x3f0 ? kthread+0xc2/0xf0 ? process_one_work+0x280/0x280 ? kthread_complete_and_exit+0x20/0x20 ? ret_from_fork+0x19/0x24 [shorten subject, remove OCB, reorder cases to match previous list]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49938", "url": "https://ubuntu.com/security/CVE-2024-49938", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmit Syzbot points out that skb_trim() has a sanity check on the existing length of the skb, which can be uninitialised in some error paths. The intent here is clearly just to reset the length to zero before resubmitting, so switch to calling __skb_set_length(skb, 0) directly. In addition, __skb_set_length() already contains a call to skb_reset_tail_pointer(), so remove the redundant call. The syzbot report came from ath9k_hif_usb_reg_in_cb(), but there's a similar usage of skb_trim() in ath9k_hif_usb_rx_cb(), change both while we're at it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49939", "url": "https://ubuntu.com/security/CVE-2024-49939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: avoid to add interface to list twice when SER If SER L2 occurs during the WoWLAN resume flow, the add interface flow is triggered by ieee80211_reconfig(). However, due to rtw89_wow_resume() return failure, it will cause the add interface flow to be executed again, resulting in a double add list and causing a kernel panic. Therefore, we have added a check to prevent double adding of the list. list_add double add: new=ffff99d6992e2010, prev=ffff99d6992e2010, next=ffff99d695302628. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:37! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G W O 6.6.30-02659-gc18865c4dfbd #1 770df2933251a0e3c888ba69d1053a817a6376a7 Hardware name: HP Grunt/Grunt, BIOS Google_Grunt.11031.169.0 06/24/2021 Workqueue: events_freezable ieee80211_restart_work [mac80211] RIP: 0010:__list_add_valid_or_report+0x5e/0xb0 Code: c7 74 18 48 39 ce 74 13 b0 01 59 5a 5e 5f 41 58 41 59 41 5a 5d e9 e2 d6 03 00 cc 48 c7 c7 8d 4f 17 83 48 89 c2 e8 02 c0 00 00 <0f> 0b 48 c7 c7 aa 8c 1c 83 e8 f4 bf 00 00 0f 0b 48 c7 c7 c8 bc 12 RSP: 0018:ffffa91b8007bc50 EFLAGS: 00010246 RAX: 0000000000000058 RBX: ffff99d6992e0900 RCX: a014d76c70ef3900 RDX: ffffa91b8007bae8 RSI: 00000000ffffdfff RDI: 0000000000000001 RBP: ffffa91b8007bc88 R08: 0000000000000000 R09: ffffa91b8007bae0 R10: 00000000ffffdfff R11: ffffffff83a79800 R12: ffff99d695302060 R13: ffff99d695300900 R14: ffff99d6992e1be0 R15: ffff99d6992e2010 FS: 0000000000000000(0000) GS:ffff99d6aac00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000078fbdba43480 CR3: 000000010e464000 CR4: 00000000001506f0 Call Trace: ? __die_body+0x1f/0x70 ? die+0x3d/0x60 ? do_trap+0xa4/0x110 ? __list_add_valid_or_report+0x5e/0xb0 ? do_error_trap+0x6d/0x90 ? __list_add_valid_or_report+0x5e/0xb0 ? handle_invalid_op+0x30/0x40 ? __list_add_valid_or_report+0x5e/0xb0 ? exc_invalid_op+0x3c/0x50 ? asm_exc_invalid_op+0x16/0x20 ? __list_add_valid_or_report+0x5e/0xb0 rtw89_ops_add_interface+0x309/0x310 [rtw89_core 7c32b1ee6854761c0321027c8a58c5160e41f48f] drv_add_interface+0x5c/0x130 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ieee80211_reconfig+0x241/0x13d0 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ? finish_wait+0x3e/0x90 ? synchronize_rcu_expedited+0x174/0x260 ? sync_rcu_exp_done_unlocked+0x50/0x50 ? wake_bit_function+0x40/0x40 ieee80211_restart_work+0xf0/0x140 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] process_scheduled_works+0x1e5/0x480 worker_thread+0xea/0x1e0 kthread+0xdb/0x110 ? move_linked_works+0x90/0x90 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork+0x3b/0x50 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork_asm+0x11/0x20 Modules linked in: dm_integrity async_xor xor async_tx lz4 lz4_compress zstd zstd_compress zram zsmalloc rfcomm cmac uinput algif_hash algif_skcipher af_alg btusb btrtl iio_trig_hrtimer industrialio_sw_trigger btmtk industrialio_configfs btbcm btintel uvcvideo videobuf2_vmalloc iio_trig_sysfs videobuf2_memops videobuf2_v4l2 videobuf2_common uvc snd_hda_codec_hdmi veth snd_hda_intel snd_intel_dspcfg acpi_als snd_hda_codec industrialio_triggered_buffer kfifo_buf snd_hwdep industrialio i2c_piix4 snd_hda_core designware_i2s ip6table_nat snd_soc_max98357a xt_MASQUERADE xt_cgroup snd_soc_acp_rt5682_mach fuse rtw89_8922ae(O) rtw89_8922a(O) rtw89_pci(O) rtw89_core(O) 8021q mac80211(O) bluetooth ecdh_generic ecc cfg80211 r8152 mii joydev gsmi: Log Shutdown Reason 0x03 ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49940", "url": "https://ubuntu.com/security/CVE-2024-49940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: prevent possible tunnel refcount underflow When a session is created, it sets a backpointer to its tunnel. When the session refcount drops to 0, l2tp_session_free drops the tunnel refcount if session->tunnel is non-NULL. However, session->tunnel is set in l2tp_session_create, before the tunnel refcount is incremented by l2tp_session_register, which leaves a small window where session->tunnel is non-NULL when the tunnel refcount hasn't been bumped. Moving the assignment to l2tp_session_register is trivial but l2tp_session_create calls l2tp_session_set_header_len which uses session->tunnel to get the tunnel's encap. Add an encap arg to l2tp_session_set_header_len to avoid using session->tunnel. If l2tpv3 sessions have colliding IDs, it is possible for l2tp_v3_session_get to race with l2tp_session_register and fetch a session which doesn't yet have session->tunnel set. Add a check for this case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49941", "url": "https://ubuntu.com/security/CVE-2024-49941", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpiolib: Fix potential NULL pointer dereference in gpiod_get_label() In `gpiod_get_label()`, it is possible that `srcu_dereference_check()` may return a NULL pointer, leading to a scenario where `label->str` is accessed without verifying if `label` itself is NULL. This patch adds a proper NULL check for `label` before accessing `label->str`. The check for `label->str != NULL` is removed because `label->str` can never be NULL if `label` is not NULL. This fixes the issue where the label name was being printed as `(efault)` when dumping the sysfs GPIO file when `label == NULL`.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49996", "url": "https://ubuntu.com/security/CVE-2024-49996", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: Fix buffer overflow when parsing NFS reparse points ReparseDataLength is sum of the InodeType size and DataBuffer size. So to get DataBuffer size it is needed to subtract InodeType's size from ReparseDataLength. Function cifs_strndup_from_utf16() is currentlly accessing buf->DataBuffer at position after the end of the buffer because it does not subtract InodeType size from the length. Fix this problem and correctly subtract variable len. Member InodeType is present only when reparse buffer is large enough. Check for ReparseDataLength before accessing InodeType to prevent another invalid memory access. Major and minor rdev values are present also only when reparse buffer is large enough. Check for reparse buffer size before calling reparse_mkdev().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49942", "url": "https://ubuntu.com/security/CVE-2024-49942", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Prevent null pointer access in xe_migrate_copy xe_migrate_copy designed to copy content of TTM resources. When source resource is null, it will trigger a NULL pointer dereference in xe_migrate_copy. To avoid this situation, update lacks source flag to true for this case, the flag will trigger xe_migrate_clear rather than xe_migrate_copy. Issue trace: <7> [317.089847] xe 0000:00:02.0: [drm:xe_migrate_copy [xe]] Pass 14, sizes: 4194304 & 4194304 <7> [317.089945] xe 0000:00:02.0: [drm:xe_migrate_copy [xe]] Pass 15, sizes: 4194304 & 4194304 <1> [317.128055] BUG: kernel NULL pointer dereference, address: 0000000000000010 <1> [317.128064] #PF: supervisor read access in kernel mode <1> [317.128066] #PF: error_code(0x0000) - not-present page <6> [317.128069] PGD 0 P4D 0 <4> [317.128071] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI <4> [317.128074] CPU: 1 UID: 0 PID: 1440 Comm: kunit_try_catch Tainted: G U N 6.11.0-rc7-xe #1 <4> [317.128078] Tainted: [U]=USER, [N]=TEST <4> [317.128080] Hardware name: Intel Corporation Lunar Lake Client Platform/LNL-M LP5 RVP1, BIOS LNLMFWI1.R00.3221.D80.2407291239 07/29/2024 <4> [317.128082] RIP: 0010:xe_migrate_copy+0x66/0x13e0 [xe] <4> [317.128158] Code: 00 00 48 89 8d e0 fe ff ff 48 8b 40 10 4c 89 85 c8 fe ff ff 44 88 8d bd fe ff ff 65 48 8b 3c 25 28 00 00 00 48 89 7d d0 31 ff <8b> 79 10 48 89 85 a0 fe ff ff 48 8b 00 48 89 b5 d8 fe ff ff 83 ff <4> [317.128162] RSP: 0018:ffffc9000167f9f0 EFLAGS: 00010246 <4> [317.128164] RAX: ffff8881120d8028 RBX: ffff88814d070428 RCX: 0000000000000000 <4> [317.128166] RDX: ffff88813cb99c00 RSI: 0000000004000000 RDI: 0000000000000000 <4> [317.128168] RBP: ffffc9000167fbb8 R08: ffff88814e7b1f08 R09: 0000000000000001 <4> [317.128170] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88814e7b1f08 <4> [317.128172] R13: ffff88814e7b1f08 R14: ffff88813cb99c00 R15: 0000000000000001 <4> [317.128174] FS: 0000000000000000(0000) GS:ffff88846f280000(0000) knlGS:0000000000000000 <4> [317.128176] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [317.128178] CR2: 0000000000000010 CR3: 000000011f676004 CR4: 0000000000770ef0 <4> [317.128180] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 <4> [317.128182] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400 <4> [317.128184] PKRU: 55555554 <4> [317.128185] Call Trace: <4> [317.128187] <4> [317.128189] ? show_regs+0x67/0x70 <4> [317.128194] ? __die_body+0x20/0x70 <4> [317.128196] ? __die+0x2b/0x40 <4> [317.128198] ? page_fault_oops+0x15f/0x4e0 <4> [317.128203] ? do_user_addr_fault+0x3fb/0x970 <4> [317.128205] ? lock_acquire+0xc7/0x2e0 <4> [317.128209] ? exc_page_fault+0x87/0x2b0 <4> [317.128212] ? asm_exc_page_fault+0x27/0x30 <4> [317.128216] ? xe_migrate_copy+0x66/0x13e0 [xe] <4> [317.128263] ? __lock_acquire+0xb9d/0x26f0 <4> [317.128265] ? __lock_acquire+0xb9d/0x26f0 <4> [317.128267] ? sg_free_append_table+0x20/0x80 <4> [317.128271] ? lock_acquire+0xc7/0x2e0 <4> [317.128273] ? mark_held_locks+0x4d/0x80 <4> [317.128275] ? trace_hardirqs_on+0x1e/0xd0 <4> [317.128278] ? _raw_spin_unlock_irqrestore+0x31/0x60 <4> [317.128281] ? __pm_runtime_resume+0x60/0xa0 <4> [317.128284] xe_bo_move+0x682/0xc50 [xe] <4> [317.128315] ? lock_is_held_type+0xaa/0x120 <4> [317.128318] ttm_bo_handle_move_mem+0xe5/0x1a0 [ttm] <4> [317.128324] ttm_bo_validate+0xd1/0x1a0 [ttm] <4> [317.128328] shrink_test_run_device+0x721/0xc10 [xe] <4> [317.128360] ? find_held_lock+0x31/0x90 <4> [317.128363] ? lock_release+0xd1/0x2a0 <4> [317.128365] ? __pfx_kunit_generic_run_threadfn_adapter+0x10/0x10 [kunit] <4> [317.128370] xe_bo_shrink_kunit+0x11/0x20 [xe] <4> [317.128397] kunit_try_run_case+0x6e/0x150 [kunit] <4> [317.128400] ? trace_hardirqs_on+0x1e/0xd0 <4> [317.128402] ? _raw_spin_unlock_irqrestore+0x31/0x60 <4> [317.128404] kunit_generic_run_threadfn_adapter+0x1e/0x40 [ku ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49943", "url": "https://ubuntu.com/security/CVE-2024-49943", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc_submit: add missing locking in wedged_fini Any non-wedged queue can have a zero refcount here and can be running concurrently with an async queue destroy, therefore dereferencing the queue ptr to check wedge status after the lookup can trigger UAF if queue is not wedged. Fix this by keeping the submission_state lock held around the check to postpone the free and make the check safe, before dropping again around the put() to avoid the deadlock. (cherry picked from commit d28af0b6b9580b9f90c265a7da0315b0ad20bbfd)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50011", "url": "https://ubuntu.com/security/CVE-2024-50011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: soc-acpi-intel-rpl-match: add missing empty item There is no links_num in struct snd_soc_acpi_mach {}, and we test !link->num_adr as a condition to end the loop in hda_sdw_machine_select(). So an empty item in struct snd_soc_acpi_link_adr array is required.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50174", "url": "https://ubuntu.com/security/CVE-2024-50174", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix race when converting group handle to group object XArray provides it's own internal lock which protects the internal array when entries are being simultaneously added and removed. However there is still a race between retrieving the pointer from the XArray and incrementing the reference count. To avoid this race simply hold the internal XArray lock when incrementing the reference count, this ensures there cannot be a racing call to xa_erase().", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49944", "url": "https://ubuntu.com/security/CVE-2024-49944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_start In sctp_listen_start() invoked by sctp_inet_listen(), it should set the sk_state back to CLOSED if sctp_autobind() fails due to whatever reason. Otherwise, next time when calling sctp_inet_listen(), if sctp_sk(sk)->reuse is already set via setsockopt(SCTP_REUSE_PORT), sctp_sk(sk)->bind_hash will be dereferenced as sk_state is LISTENING, which causes a crash as bind_hash is NULL. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:sctp_inet_listen+0x7f0/0xa20 net/sctp/socket.c:8617 Call Trace: __sys_listen_socket net/socket.c:1883 [inline] __sys_listen+0x1b7/0x230 net/socket.c:1894 __do_sys_listen net/socket.c:1902 [inline]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49945", "url": "https://ubuntu.com/security/CVE-2024-49945", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/ncsi: Disable the ncsi work before freeing the associated structure The work function can run after the ncsi device is freed, resulting in use-after-free bugs or kernel panic.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49946", "url": "https://ubuntu.com/security/CVE-2024-49946", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: do not assume bh is held in ppp_channel_bridge_input() Networking receive path is usually handled from BH handler. However, some protocols need to acquire the socket lock, and packets might be stored in the socket backlog is the socket was owned by a user process. In this case, release_sock(), __release_sock(), and sk_backlog_rcv() might call the sk->sk_backlog_rcv() handler in process context. sybot caught ppp was not considering this case in ppp_channel_bridge_input() : WARNING: inconsistent lock state 6.11.0-rc7-syzkaller-g5f5673607153 #0 Not tainted -------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. ksoftirqd/1/24 [HC0[0]:SC1[1]:HE1:SE0] takes: ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 {SOFTIRQ-ON-W} state was registered at: lock_acquire+0x240/0x728 kernel/locking/lockdep.c:5759 __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline] _raw_spin_lock+0x48/0x60 kernel/locking/spinlock.c:154 spin_lock include/linux/spinlock.h:351 [inline] ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline] ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0xfc/0x314 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv include/net/sock.h:1111 [inline] __release_sock+0x1a8/0x3d8 net/core/sock.c:3004 release_sock+0x68/0x1b8 net/core/sock.c:3558 pppoe_sendmsg+0xc8/0x5d8 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x374/0x4f4 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __arm64_sys_sendto+0xd8/0xf8 net/socket.c:2212 __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:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 irq event stamp: 282914 hardirqs last enabled at (282914): [] __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:151 [inline] hardirqs last enabled at (282914): [] _raw_spin_unlock_irqrestore+0x38/0x98 kernel/locking/spinlock.c:194 hardirqs last disabled at (282913): [] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline] hardirqs last disabled at (282913): [] _raw_spin_lock_irqsave+0x2c/0x7c kernel/locking/spinlock.c:162 softirqs last enabled at (282904): [] softirq_handle_end kernel/softirq.c:400 [inline] softirqs last enabled at (282904): [] handle_softirqs+0xa3c/0xbfc kernel/softirq.c:582 softirqs last disabled at (282909): [] run_ksoftirqd+0x70/0x158 kernel/softirq.c:928 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&pch->downl); lock(&pch->downl); *** DEADLOCK *** 1 lock held by ksoftirqd/1/24: #0: ffff80008f74dfa0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire+0x10/0x4c include/linux/rcupdate.h:325 stack backtrace: CPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 6.11.0-rc7-syzkaller-g5f5673607153 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call trace: dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:319 show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:326 __dump_sta ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49947", "url": "https://ubuntu.com/security/CVE-2024-49947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: test for not too small csum_start in virtio_net_hdr_to_skb() syzbot was able to trigger this warning [1], after injecting a malicious packet through af_packet, setting skb->csum_start and thus the transport header to an incorrect value. We can at least make sure the transport header is after the end of the network header (with a estimated minimal size). [1] [ 67.873027] skb len=4096 headroom=16 headlen=14 tailroom=0 mac=(-1,-1) mac_len=0 net=(16,-6) trans=10 shinfo(txflags=0 nr_frags=1 gso(size=0 type=0 segs=0)) csum(0xa start=10 offset=0 ip_summed=3 complete_sw=0 valid=0 level=0) hash(0x0 sw=0 l4=0) proto=0x0800 pkttype=0 iif=0 priority=0x0 mark=0x0 alloc_cpu=10 vlan_all=0x0 encapsulation=0 inner(proto=0x0000, mac=0, net=0, trans=0) [ 67.877172] dev name=veth0_vlan feat=0x000061164fdd09e9 [ 67.877764] sk family=17 type=3 proto=0 [ 67.878279] skb linear: 00000000: 00 00 10 00 00 00 00 00 0f 00 00 00 08 00 [ 67.879128] skb frag: 00000000: 0e 00 07 00 00 00 28 00 08 80 1c 00 04 00 00 02 [ 67.879877] skb frag: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.880647] skb frag: 00000020: 00 00 02 00 00 00 08 00 1b 00 00 00 00 00 00 00 [ 67.881156] skb frag: 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.881753] skb frag: 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.882173] skb frag: 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.882790] skb frag: 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.883171] skb frag: 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.883733] skb frag: 00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.884206] skb frag: 00000090: 00 00 00 00 00 00 00 00 00 00 69 70 76 6c 61 6e [ 67.884704] skb frag: 000000a0: 31 00 00 00 00 00 00 00 00 00 2b 00 00 00 00 00 [ 67.885139] skb frag: 000000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.885677] skb frag: 000000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.886042] skb frag: 000000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.886408] skb frag: 000000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.887020] skb frag: 000000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.887384] skb frag: 00000100: 00 00 [ 67.887878] ------------[ cut here ]------------ [ 67.887908] offset (-6) >= skb_headlen() (14) [ 67.888445] WARNING: CPU: 10 PID: 2088 at net/core/dev.c:3332 skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.889353] Modules linked in: macsec macvtap macvlan hsr wireguard curve25519_x86_64 libcurve25519_generic libchacha20poly1305 chacha_x86_64 libchacha poly1305_x86_64 dummy bridge sr_mod cdrom evdev pcspkr i2c_piix4 9pnet_virtio 9p 9pnet netfs [ 67.890111] CPU: 10 UID: 0 PID: 2088 Comm: b363492833 Not tainted 6.11.0-virtme #1011 [ 67.890183] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 67.890309] RIP: 0010:skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891043] Call Trace: [ 67.891173] [ 67.891274] ? __warn (kernel/panic.c:741) [ 67.891320] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891333] ? report_bug (lib/bug.c:180 lib/bug.c:219) [ 67.891348] ? handle_bug (arch/x86/kernel/traps.c:239) [ 67.891363] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) [ 67.891372] ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621) [ 67.891388] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891399] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891416] ip_do_fragment (net/ipv4/ip_output.c:777 (discriminator 1)) [ 67.891448] ? __ip_local_out (./include/linux/skbuff.h:1146 ./include/net/l3mdev.h:196 ./include/net/l3mdev.h:213 ne ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49948", "url": "https://ubuntu.com/security/CVE-2024-49948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: add more sanity checks to qdisc_pkt_len_init() One path takes care of SKB_GSO_DODGY, assuming skb->len is bigger than hdr_len. virtio_net_hdr_to_skb() does not fully dissect TCP headers, it only make sure it is at least 20 bytes. It is possible for an user to provide a malicious 'GSO' packet, total length of 80 bytes. - 20 bytes of IPv4 header - 60 bytes TCP header - a small gso_size like 8 virtio_net_hdr_to_skb() would declare this packet as a normal GSO packet, because it would see 40 bytes of payload, bigger than gso_size. We need to make detect this case to not underflow qdisc_skb_cb(skb)->pkt_len.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49949", "url": "https://ubuntu.com/security/CVE-2024-49949", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: avoid potential underflow in qdisc_pkt_len_init() with UFO After commit 7c6d2ecbda83 (\"net: be more gentle about silly gso requests coming from user\") virtio_net_hdr_to_skb() had sanity check to detect malicious attempts from user space to cook a bad GSO packet. Then commit cf9acc90c80ec (\"net: virtio_net_hdr_to_skb: count transport header in UFO\") while fixing one issue, allowed user space to cook a GSO packet with the following characteristic : IPv4 SKB_GSO_UDP, gso_size=3, skb->len = 28. When this packet arrives in qdisc_pkt_len_init(), we end up with hdr_len = 28 (IPv4 header + UDP header), matching skb->len Then the following sets gso_segs to 0 : gso_segs = DIV_ROUND_UP(skb->len - hdr_len, shinfo->gso_size); Then later we set qdisc_skb_cb(skb)->pkt_len to back to zero :/ qdisc_skb_cb(skb)->pkt_len += (gso_segs - 1) * hdr_len; This leads to the following crash in fq_codel [1] qdisc_pkt_len_init() is best effort, we only want an estimation of the bytes sent on the wire, not crashing the kernel. This patch is fixing this particular issue, a following one adds more sanity checks for another potential bug. [1] [ 70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 70.724561] #PF: supervisor read access in kernel mode [ 70.724561] #PF: error_code(0x0000) - not-present page [ 70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0 [ 70.724561] Oops: Oops: 0000 [#1] SMP NOPTI [ 70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991 [ 70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel [ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 <49> 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49 All code ======== 0:\t24 08 \tand $0x8,%al 2:\t49 c1 e1 06 \tshl $0x6,%r9 6:\t44 89 7c 24 18 \tmov %r15d,0x18(%rsp) b:\t45 31 ed \txor %r13d,%r13d e:\t45 31 c0 \txor %r8d,%r8d 11:\t31 ff \txor %edi,%edi 13:\t89 44 24 14 \tmov %eax,0x14(%rsp) 17:\t4c 03 8b 90 01 00 00 \tadd 0x190(%rbx),%r9 1e:\teb 04 \tjmp 0x24 20:\t39 ca \tcmp %ecx,%edx 22:\t73 37 \tjae 0x5b 24:\t4d 8b 39 \tmov (%r9),%r15 27:\t83 c7 01 \tadd $0x1,%edi 2a:*\t49 8b 17 \tmov (%r15),%rdx\t\t<-- trapping instruction 2d:\t49 89 11 \tmov %rdx,(%r9) 30:\t41 8b 57 28 \tmov 0x28(%r15),%edx 34:\t45 8b 5f 34 \tmov 0x34(%r15),%r11d 38:\t49 c7 07 00 00 00 00 \tmovq $0x0,(%r15) 3f:\t49 \trex.WB Code starting with the faulting instruction =========================================== 0:\t49 8b 17 \tmov (%r15),%rdx 3:\t49 89 11 \tmov %rdx,(%r9) 6:\t41 8b 57 28 \tmov 0x28(%r15),%edx a:\t45 8b 5f 34 \tmov 0x34(%r15),%r11d e:\t49 c7 07 00 00 00 00 \tmovq $0x0,(%r15) 15:\t49 \trex.WB [ 70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202 [ 70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000 [ 70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001 [ 70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000 [ 70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58 [ 70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000 [ 70.724561] FS: 000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000 [ 70.724561] CS: 0010 DS: 0000 ES: 0000 C ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49997", "url": "https://ubuntu.com/security/CVE-2024-49997", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: lantiq_etop: fix memory disclosure When applying padding, the buffer is not zeroed, which results in memory disclosure. The mentioned data is observed on the wire. This patch uses skb_put_padto() to pad Ethernet frames properly. The mentioned function zeroes the expanded buffer. In case the packet cannot be padded it is silently dropped. Statistics are also not incremented. This driver does not support statistics in the old 32-bit format or the new 64-bit format. These will be added in the future. In its current form, the patch should be easily backported to stable versions. Ethernet MACs on Amazon-SE and Danube cannot do padding of the packets in hardware, so software padding must be applied.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49998", "url": "https://ubuntu.com/security/CVE-2024-49998", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: improve shutdown sequence Alexander Sverdlin presents 2 problems during shutdown with the lan9303 driver. One is specific to lan9303 and the other just happens to reproduce there. The first problem is that lan9303 is unique among DSA drivers in that it calls dev_get_drvdata() at \"arbitrary runtime\" (not probe, not shutdown, not remove): phy_state_machine() -> ... -> dsa_user_phy_read() -> ds->ops->phy_read() -> lan9303_phy_read() -> chip->ops->phy_read() -> lan9303_mdio_phy_read() -> dev_get_drvdata() But we never stop the phy_state_machine(), so it may continue to run after dsa_switch_shutdown(). Our common pattern in all DSA drivers is to set drvdata to NULL to suppress the remove() method that may come afterwards. But in this case it will result in an NPD. The second problem is that the way in which we set dp->conduit->dsa_ptr = NULL; is concurrent with receive packet processing. dsa_switch_rcv() checks once whether dev->dsa_ptr is NULL, but afterwards, rather than continuing to use that non-NULL value, dev->dsa_ptr is dereferenced again and again without NULL checks: dsa_conduit_find_user() and many other places. In between dereferences, there is no locking to ensure that what was valid once continues to be valid. Both problems have the common aspect that closing the conduit interface solves them. In the first case, dev_close(conduit) triggers the NETDEV_GOING_DOWN event in dsa_user_netdevice_event() which closes user ports as well. dsa_port_disable_rt() calls phylink_stop(), which synchronously stops the phylink state machine, and ds->ops->phy_read() will thus no longer call into the driver after this point. In the second case, dev_close(conduit) should do this, as per Documentation/networking/driver.rst: | Quiescence | ---------- | | After the ndo_stop routine has been called, the hardware must | not receive or transmit any data. All in flight packets must | be aborted. If necessary, poll or wait for completion of | any reset commands. So it should be sufficient to ensure that later, when we zeroize conduit->dsa_ptr, there will be no concurrent dsa_switch_rcv() call on this conduit. The addition of the netif_device_detach() function is to ensure that ioctls, rtnetlinks and ethtool requests on the user ports no longer propagate down to the driver - we're no longer prepared to handle them. The race condition actually did not exist when commit 0650bf52b31f (\"net: dsa: be compatible with masters which unregister on shutdown\") first introduced dsa_switch_shutdown(). It was created later, when we stopped unregistering the user interfaces from a bad spot, and we just replaced that sequence with a racy zeroization of conduit->dsa_ptr (one which doesn't ensure that the interfaces aren't up).", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49999", "url": "https://ubuntu.com/security/CVE-2024-49999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix the setting of the server responding flag In afs_wait_for_operation(), we set transcribe the call responded flag to the server record that we used after doing the fileserver iteration loop - but it's possible to exit the loop having had a response from the server that we've discarded (e.g. it returned an abort or we started receiving data, but the call didn't complete). This means that op->server might be NULL, but we don't check that before attempting to set the server flag.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49950", "url": "https://ubuntu.com/security/CVE-2024-49950", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix uaf in l2cap_connect [Syzbot reported] BUG: KASAN: slab-use-after-free in l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 Read of size 8 at addr ffff8880241e9800 by task kworker/u9:0/54 CPU: 0 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-00268-g788220eee30d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Workqueue: hci2 hci_rx_work Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 l2cap_connect_req net/bluetooth/l2cap_core.c:4080 [inline] l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:4772 [inline] l2cap_sig_channel net/bluetooth/l2cap_core.c:5543 [inline] l2cap_recv_frame+0xf0b/0x8eb0 net/bluetooth/l2cap_core.c:6825 l2cap_recv_acldata+0x9b4/0xb70 net/bluetooth/l2cap_core.c:7514 hci_acldata_packet net/bluetooth/hci_core.c:3791 [inline] hci_rx_work+0xaab/0x1610 net/bluetooth/hci_core.c:4028 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 ... Freed by task 5245: 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:579 poison_slab_object+0xf7/0x160 mm/kasan/common.c:240 __kasan_slab_free+0x32/0x50 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2256 [inline] slab_free mm/slub.c:4477 [inline] kfree+0x12a/0x3b0 mm/slub.c:4598 l2cap_conn_free net/bluetooth/l2cap_core.c:1810 [inline] kref_put include/linux/kref.h:65 [inline] l2cap_conn_put net/bluetooth/l2cap_core.c:1822 [inline] l2cap_conn_del+0x59d/0x730 net/bluetooth/l2cap_core.c:1802 l2cap_connect_cfm+0x9e6/0xf80 net/bluetooth/l2cap_core.c:7241 hci_connect_cfm include/net/bluetooth/hci_core.h:1960 [inline] hci_conn_failed+0x1c3/0x370 net/bluetooth/hci_conn.c:1265 hci_abort_conn_sync+0x75a/0xb50 net/bluetooth/hci_sync.c:5583 abort_conn_sync+0x197/0x360 net/bluetooth/hci_conn.c:2917 hci_cmd_sync_work+0x1a4/0x410 net/bluetooth/hci_sync.c:328 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49951", "url": "https://ubuntu.com/security/CVE-2024-49951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Fix possible crash on mgmt_index_removed If mgmt_index_removed is called while there are commands queued on cmd_sync it could lead to crashes like the bellow trace: 0x0000053D: __list_del_entry_valid_or_report+0x98/0xdc 0x0000053D: mgmt_pending_remove+0x18/0x58 [bluetooth] 0x0000053E: mgmt_remove_adv_monitor_complete+0x80/0x108 [bluetooth] 0x0000053E: hci_cmd_sync_work+0xbc/0x164 [bluetooth] So while handling mgmt_index_removed this attempts to dequeue commands passed as user_data to cmd_sync.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49952", "url": "https://ubuntu.com/security/CVE-2024-49952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: prevent nf_skb_duplicated corruption syzbot found that nf_dup_ipv4() or nf_dup_ipv6() could write per-cpu variable nf_skb_duplicated in an unsafe way [1]. Disabling preemption as hinted by the splat is not enough, we have to disable soft interrupts as well. [1] BUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316 caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49 nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook+0x2c4/0x450 include/linux/netfilter.h:269 NF_HOOK_COND include/linux/netfilter.h:302 [inline] ip_output+0x185/0x230 net/ipv4/ip_output.c:433 ip_local_out net/ipv4/ip_output.c:129 [inline] ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495 udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981 udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737 __do_sys_sendmmsg net/socket.c:2766 [inline] __se_sys_sendmmsg net/socket.c:2763 [inline] __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763 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:0x7f4ce4f7def9 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:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9 RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006 RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49953", "url": "https://ubuntu.com/security/CVE-2024-49953", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix crash caused by calling __xfrm_state_delete() twice The km.state is not checked in driver's delayed work. When xfrm_state_check_expire() is called, the state can be reset to XFRM_STATE_EXPIRED, even if it is XFRM_STATE_DEAD already. This happens when xfrm state is deleted, but not freed yet. As __xfrm_state_delete() is called again in xfrm timer, the following crash occurs. To fix this issue, skip xfrm_state_check_expire() if km.state is not XFRM_STATE_VALID. Oops: general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] SMP CPU: 5 UID: 0 PID: 7448 Comm: kworker/u102:2 Not tainted 6.11.0-rc2+ #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5e_ipsec: eth%d mlx5e_ipsec_handle_sw_limits [mlx5_core] RIP: 0010:__xfrm_state_delete+0x3d/0x1b0 Code: 0f 84 8b 01 00 00 48 89 fd c6 87 c8 00 00 00 05 48 8d bb 40 10 00 00 e8 11 04 1a 00 48 8b 95 b8 00 00 00 48 8b 85 c0 00 00 00 <48> 89 42 08 48 89 10 48 8b 55 10 48 b8 00 01 00 00 00 00 ad de 48 RSP: 0018:ffff88885f945ec8 EFLAGS: 00010246 RAX: dead000000000122 RBX: ffffffff82afa940 RCX: 0000000000000036 RDX: dead000000000100 RSI: 0000000000000000 RDI: ffffffff82afb980 RBP: ffff888109a20340 R08: ffff88885f945ea0 R09: 0000000000000000 R10: 0000000000000000 R11: ffff88885f945ff8 R12: 0000000000000246 R13: ffff888109a20340 R14: ffff88885f95f420 R15: ffff88885f95f400 FS: 0000000000000000(0000) GS:ffff88885f940000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2163102430 CR3: 00000001128d6001 CR4: 0000000000370eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? die_addr+0x33/0x90 ? exc_general_protection+0x1a2/0x390 ? asm_exc_general_protection+0x22/0x30 ? __xfrm_state_delete+0x3d/0x1b0 ? __xfrm_state_delete+0x2f/0x1b0 xfrm_timer_handler+0x174/0x350 ? __xfrm_state_delete+0x1b0/0x1b0 __hrtimer_run_queues+0x121/0x270 hrtimer_run_softirq+0x88/0xd0 handle_softirqs+0xcc/0x270 do_softirq+0x3c/0x50 __local_bh_enable_ip+0x47/0x50 mlx5e_ipsec_handle_sw_limits+0x7d/0x90 [mlx5_core] process_one_work+0x137/0x2d0 worker_thread+0x28d/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50000", "url": "https://ubuntu.com/security/CVE-2024-50000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix NULL deref in mlx5e_tir_builder_alloc() In mlx5e_tir_builder_alloc() kvzalloc() may return NULL which is dereferenced on the next line in a reference to the modify field. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50001", "url": "https://ubuntu.com/security/CVE-2024-50001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix error path in multi-packet WQE transmit Remove the erroneous unmap in case no DMA mapping was established The multi-packet WQE transmit code attempts to obtain a DMA mapping for the skb. This could fail, e.g. under memory pressure, when the IOMMU driver just can't allocate more memory for page tables. While the code tries to handle this in the path below the err_unmap label it erroneously unmaps one entry from the sq's FIFO list of active mappings. Since the current map attempt failed this unmap is removing some random DMA mapping that might still be required. If the PCI function now presents that IOVA, the IOMMU may assumes a rogue DMA access and e.g. on s390 puts the PCI function in error state. The erroneous behavior was seen in a stress-test environment that created memory pressure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50179", "url": "https://ubuntu.com/security/CVE-2024-50179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: remove the incorrect Fw reference check when dirtying pages When doing the direct-io reads it will also try to mark pages dirty, but for the read path it won't hold the Fw caps and there is case will it get the Fw reference.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49963", "url": "https://ubuntu.com/security/CVE-2024-49963", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mailbox: bcm2835: Fix timeout during suspend mode During noirq suspend phase the Raspberry Pi power driver suffer of firmware property timeouts. The reason is that the IRQ of the underlying BCM2835 mailbox is disabled and rpi_firmware_property_list() will always run into a timeout [1]. Since the VideoCore side isn't consider as a wakeup source, set the IRQF_NO_SUSPEND flag for the mailbox IRQ in order to keep it enabled during suspend-resume cycle. [1] PM: late suspend of devices complete after 1.754 msecs WARNING: CPU: 0 PID: 438 at drivers/firmware/raspberrypi.c:128 rpi_firmware_property_list+0x204/0x22c Firmware transaction 0x00028001 timeout Modules linked in: CPU: 0 PID: 438 Comm: bash Tainted: G C 6.9.3-dirty #17 Hardware name: BCM2835 Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x44 dump_stack_lvl from __warn+0x88/0xec __warn from warn_slowpath_fmt+0x7c/0xb0 warn_slowpath_fmt from rpi_firmware_property_list+0x204/0x22c rpi_firmware_property_list from rpi_firmware_property+0x68/0x8c rpi_firmware_property from rpi_firmware_set_power+0x54/0xc0 rpi_firmware_set_power from _genpd_power_off+0xe4/0x148 _genpd_power_off from genpd_sync_power_off+0x7c/0x11c genpd_sync_power_off from genpd_finish_suspend+0xcc/0xe0 genpd_finish_suspend from dpm_run_callback+0x78/0xd0 dpm_run_callback from device_suspend_noirq+0xc0/0x238 device_suspend_noirq from dpm_suspend_noirq+0xb0/0x168 dpm_suspend_noirq from suspend_devices_and_enter+0x1b8/0x5ac suspend_devices_and_enter from pm_suspend+0x254/0x2e4 pm_suspend from state_store+0xa8/0xd4 state_store from kernfs_fop_write_iter+0x154/0x1a0 kernfs_fop_write_iter from vfs_write+0x12c/0x184 vfs_write from ksys_write+0x78/0xc0 ksys_write from ret_fast_syscall+0x0/0x54 Exception stack(0xcc93dfa8 to 0xcc93dff0) [...] PM: noirq suspend of devices complete after 3095.584 msecs", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49954", "url": "https://ubuntu.com/security/CVE-2024-49954", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: static_call: Replace pointless WARN_ON() in static_call_module_notify() static_call_module_notify() triggers a WARN_ON(), when memory allocation fails in __static_call_add_module(). That's not really justified, because the failure case must be correctly handled by the well known call chain and the error code is passed through to the initiating userspace application. A memory allocation fail is not a fatal problem, but the WARN_ON() takes the machine out when panic_on_warn is set. Replace it with a pr_warn().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50002", "url": "https://ubuntu.com/security/CVE-2024-50002", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: static_call: Handle module init failure correctly in static_call_del_module() Module insertion invokes static_call_add_module() to initialize the static calls in a module. static_call_add_module() invokes __static_call_init(), which allocates a struct static_call_mod to either encapsulate the built-in static call sites of the associated key into it so further modules can be added or to append the module to the module chain. If that allocation fails the function returns with an error code and the module core invokes static_call_del_module() to clean up eventually added static_call_mod entries. This works correctly, when all keys used by the module were converted over to a module chain before the failure. If not then static_call_del_module() causes a #GP as it blindly assumes that key::mods points to a valid struct static_call_mod. The problem is that key::mods is not a individual struct member of struct static_call_key, it's part of a union to save space: union { /* bit 0: 0 = mods, 1 = sites */ unsigned long type; struct static_call_mod *mods; struct static_call_site *sites; \t}; key::sites is a pointer to the list of built-in usage sites of the static call. The type of the pointer is differentiated by bit 0. A mods pointer has the bit clear, the sites pointer has the bit set. As static_call_del_module() blidly assumes that the pointer is a valid static_call_mod type, it fails to check for this failure case and dereferences the pointer to the list of built-in call sites, which is obviously bogus. Cure it by checking whether the key has a sites or a mods pointer. If it's a sites pointer then the key is not to be touched. As the sites are walked in the same order as in __static_call_init() the site walk can be terminated because all subsequent sites have not been touched by the init code due to the error exit. If it was converted before the allocation fail, then the inner loop which searches for a module match will find nothing. A fail in the second allocation in __static_call_init() is harmless and does not require special treatment. The first allocation succeeded and converted the key to a module chain. That first entry has mod::mod == NULL and mod::next == NULL, so the inner loop of static_call_del_module() will neither find a module match nor a module chain. The next site in the walk was either already converted, but can't match the module, or it will exit the outer loop because it has a static_call_site pointer and not a static_call_mod pointer.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-47675", "url": "https://ubuntu.com/security/CVE-2024-47675", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix use-after-free in bpf_uprobe_multi_link_attach() If bpf_link_prime() fails, bpf_uprobe_multi_link_attach() goes to the error_free label and frees the array of bpf_uprobe's without calling bpf_uprobe_unregister(). This leaks bpf_uprobe->uprobe and worse, this frees bpf_uprobe->consumer without removing it from the uprobe->consumers list.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47676", "url": "https://ubuntu.com/security/CVE-2024-47676", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb.c: fix UAF of vma in hugetlb fault pathway Syzbot reports a UAF in hugetlb_fault(). This happens because vmf_anon_prepare() could drop the per-VMA lock and allow the current VMA to be freed before hugetlb_vma_unlock_read() is called. We can fix this by using a modified version of vmf_anon_prepare() that doesn't release the VMA lock on failure, and then release it ourselves after hugetlb_vma_unlock_read().", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47677", "url": "https://ubuntu.com/security/CVE-2024-47677", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: resolve memory leak from exfat_create_upcase_table() If exfat_load_upcase_table reaches end and returns -EINVAL, allocated memory doesn't get freed and while exfat_load_default_upcase_table allocates more memory, leading to a memory leak. Here's link to syzkaller crash report illustrating this issue: https://syzkaller.appspot.com/text?tag=CrashReport&x=1406c201980000", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47725", "url": "https://ubuntu.com/security/CVE-2024-47725", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47739", "url": "https://ubuntu.com/security/CVE-2024-47739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: padata: use integer wrap around to prevent deadlock on seq_nr overflow When submitting more than 2^32 padata objects to padata_do_serial, the current sorting implementation incorrectly sorts padata objects with overflowed seq_nr, causing them to be placed before existing objects in the reorder list. This leads to a deadlock in the serialization process as padata_find_next cannot match padata->seq_nr and pd->processed because the padata instance with overflowed seq_nr will be selected next. To fix this, we use an unsigned integer wrap around to correctly sort padata objects in scenarios with integer overflow.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47678", "url": "https://ubuntu.com/security/CVE-2024-47678", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: icmp: change the order of rate limits ICMP messages are ratelimited : After the blamed commits, the two rate limiters are applied in this order: 1) host wide ratelimit (icmp_global_allow()) 2) Per destination ratelimit (inetpeer based) In order to avoid side-channels attacks, we need to apply the per destination check first. This patch makes the following change : 1) icmp_global_allow() checks if the host wide limit is reached. But credits are not yet consumed. This is deferred to 3) 2) The per destination limit is checked/updated. This might add a new node in inetpeer tree. 3) icmp_global_consume() consumes tokens if prior operations succeeded. This means that host wide ratelimit is still effective in keeping inetpeer tree small even under DDOS. As a bonus, I removed icmp_global.lock as the fast path can use a lock-free operation.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47733", "url": "https://ubuntu.com/security/CVE-2024-47733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfs: Delete subtree of 'fs/netfs' when netfs module exits In netfs_init() or fscache_proc_init(), we create dentry under 'fs/netfs', but in netfs_exit(), we only delete the proc entry of 'fs/netfs' without deleting its subtree. This triggers the following WARNING: ================================================================== remove_proc_entry: removing non-empty directory 'fs/netfs', leaking at least 'requests' WARNING: CPU: 4 PID: 566 at fs/proc/generic.c:717 remove_proc_entry+0x160/0x1c0 Modules linked in: netfs(-) CPU: 4 UID: 0 PID: 566 Comm: rmmod Not tainted 6.11.0-rc3 #860 RIP: 0010:remove_proc_entry+0x160/0x1c0 Call Trace: netfs_exit+0x12/0x620 [netfs] __do_sys_delete_module.isra.0+0x14c/0x2e0 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e ================================================================== Therefore use remove_proc_subtree() instead of remove_proc_entry() to fix the above problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47679", "url": "https://ubuntu.com/security/CVE-2024-47679", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfs: fix race between evice_inodes() and find_inode()&iput() Hi, all Recently I noticed a bug[1] in btrfs, after digged it into and I believe it'a race in vfs. Let's assume there's a inode (ie ino 261) with i_count 1 is called by iput(), and there's a concurrent thread calling generic_shutdown_super(). cpu0: cpu1: iput() // i_count is 1 ->spin_lock(inode) ->dec i_count to 0 ->iput_final() generic_shutdown_super() ->__inode_add_lru() ->evict_inodes() // cause some reason[2] ->if (atomic_read(inode->i_count)) continue; // return before // inode 261 passed the above check // list_lru_add_obj() // and then schedule out ->spin_unlock() // note here: the inode 261 // was still at sb list and hash list, // and I_FREEING|I_WILL_FREE was not been set btrfs_iget() // after some function calls ->find_inode() // found the above inode 261 ->spin_lock(inode) // check I_FREEING|I_WILL_FREE // and passed ->__iget() ->spin_unlock(inode) // schedule back ->spin_lock(inode) // check (I_NEW|I_FREEING|I_WILL_FREE) flags, // passed and set I_FREEING iput() ->spin_unlock(inode) ->spin_lock(inode)\t\t\t ->evict() // dec i_count to 0 ->iput_final() ->spin_unlock() ->evict() Now, we have two threads simultaneously evicting the same inode, which may trigger the BUG(inode->i_state & I_CLEAR) statement both within clear_inode() and iput(). To fix the bug, recheck the inode->i_count after holding i_lock. Because in the most scenarios, the first check is valid, and the overhead of spin_lock() can be reduced. If there is any misunderstanding, please let me know, thanks. [1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/ [2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable() return false when I reproduced the bug.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49859", "url": "https://ubuntu.com/security/CVE-2024-49859", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to check atomic_file in f2fs ioctl interfaces Some f2fs ioctl interfaces like f2fs_ioc_set_pin_file(), f2fs_move_file_range(), and f2fs_defragment_range() missed to check atomic_write status, which may cause potential race issue, fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47680", "url": "https://ubuntu.com/security/CVE-2024-47680", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: check discard support for conventional zones As the helper function f2fs_bdev_support_discard() shows, f2fs checks if the target block devices support discard by calling bdev_max_discard_sectors() and bdev_is_zoned(). This check works well for most cases, but it does not work for conventional zones on zoned block devices. F2fs assumes that zoned block devices support discard, and calls __submit_discard_cmd(). When __submit_discard_cmd() is called for sequential write required zones, it works fine since __submit_discard_cmd() issues zone reset commands instead of discard commands. However, when __submit_discard_cmd() is called for conventional zones, __blkdev_issue_discard() is called even when the devices do not support discard. The inappropriate __blkdev_issue_discard() call was not a problem before the commit 30f1e7241422 (\"block: move discard checks into the ioctl handler\") because __blkdev_issue_discard() checked if the target devices support discard or not. If not, it returned EOPNOTSUPP. After the commit, __blkdev_issue_discard() no longer checks it. It always returns zero and sets NULL to the given bio pointer. This NULL pointer triggers f2fs_bug_on() in __submit_discard_cmd(). The BUG is recreated with the commands below at the umount step, where /dev/nullb0 is a zoned null_blk with 5GB total size, 128MB zone size and 10 conventional zones. $ mkfs.f2fs -f -m /dev/nullb0 $ mount /dev/nullb0 /mnt $ for ((i=0;i<5;i++)); do dd if=/dev/zero of=/mnt/test bs=65536 count=1600 conv=fsync; done $ umount /mnt To fix the BUG, avoid the inappropriate __blkdev_issue_discard() call. When discard is requested for conventional zones, check if the device supports discard or not. If not, return EOPNOTSUPP.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47740", "url": "https://ubuntu.com/security/CVE-2024-47740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: Require FMODE_WRITE for atomic write ioctls The F2FS ioctls for starting and committing atomic writes check for inode_owner_or_capable(), but this does not give LSMs like SELinux or Landlock an opportunity to deny the write access - if the caller's FSUID matches the inode's UID, inode_owner_or_capable() immediately returns true. There are scenarios where LSMs want to deny a process the ability to write particular files, even files that the FSUID of the process owns; but this can currently partially be bypassed using atomic write ioctls in two ways: - F2FS_IOC_START_ATOMIC_REPLACE + F2FS_IOC_COMMIT_ATOMIC_WRITE can truncate an inode to size 0 - F2FS_IOC_START_ATOMIC_WRITE + F2FS_IOC_ABORT_ATOMIC_WRITE can revert changes another process concurrently made to a file Fix it by requiring FMODE_WRITE for these operations, just like for F2FS_IOC_MOVE_RANGE. Since any legitimate caller should only be using these ioctls when intending to write into the file, that seems unlikely to break anything.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47726", "url": "https://ubuntu.com/security/CVE-2024-47726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to wait dio completion It should wait all existing dio write IOs before block removal, otherwise, previous direct write IO may overwrite data in the block which may be reused by other inode.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47741", "url": "https://ubuntu.com/security/CVE-2024-47741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race setting file private on concurrent lseek using same fd When doing concurrent lseek(2) system calls against the same file descriptor, using multiple threads belonging to the same process, we have a short time window where a race happens and can result in a memory leak. The race happens like this: 1) A program opens a file descriptor for a file and then spawns two threads (with the pthreads library for example), lets call them task A and task B; 2) Task A calls lseek with SEEK_DATA or SEEK_HOLE and ends up at file.c:find_desired_extent() while holding a read lock on the inode; 3) At the start of find_desired_extent(), it extracts the file's private_data pointer into a local variable named 'private', which has a value of NULL; 4) Task B also calls lseek with SEEK_DATA or SEEK_HOLE, locks the inode in shared mode and enters file.c:find_desired_extent(), where it also extracts file->private_data into its local variable 'private', which has a NULL value; 5) Because it saw a NULL file private, task A allocates a private structure and assigns to the file structure; 6) Task B also saw a NULL file private so it also allocates its own file private and then assigns it to the same file structure, since both tasks are using the same file descriptor. At this point we leak the private structure allocated by task A. Besides the memory leak, there's also the detail that both tasks end up using the same cached state record in the private structure (struct btrfs_file_private::llseek_cached_state), which can result in a use-after-free problem since one task can free it while the other is still using it (only one task took a reference count on it). Also, sharing the cached state is not a good idea since it could result in incorrect results in the future - right now it should not be a problem because it end ups being used only in extent-io-tree.c:count_range_bits() where we do range validation before using the cached state. Fix this by protecting the private assignment and check of a file while holding the inode's spinlock and keep track of the task that allocated the private, so that it's used only by that task in order to prevent user-after-free issues with the cached state record as well as potentially using it incorrectly in the future.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47681", "url": "https://ubuntu.com/security/CVE-2024-47681", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix NULL pointer dereference in mt7996_mcu_sta_bfer_he Fix the NULL pointer dereference in mt7996_mcu_sta_bfer_he routine adding an sta interface to the mt7996 driver. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49858", "url": "https://ubuntu.com/security/CVE-2024-49858", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption The TPM event log table is a Linux specific construct, where the data produced by the GetEventLog() boot service is cached in memory, and passed on to the OS using an EFI configuration table. The use of EFI_LOADER_DATA here results in the region being left unreserved in the E820 memory map constructed by the EFI stub, and this is the memory description that is passed on to the incoming kernel by kexec, which is therefore unaware that the region should be reserved. Even though the utility of the TPM2 event log after a kexec is questionable, any corruption might send the parsing code off into the weeds and crash the kernel. So let's use EFI_ACPI_RECLAIM_MEMORY instead, which is always treated as reserved by the E820 conversion logic.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49860", "url": "https://ubuntu.com/security/CVE-2024-49860", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: sysfs: validate return type of _STR method Only buffer objects are valid return values of _STR. If something else is returned description_show() will access invalid memory.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47742", "url": "https://ubuntu.com/security/CVE-2024-47742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware_loader: Block path traversal Most firmware names are hardcoded strings, or are constructed from fairly constrained format strings where the dynamic parts are just some hex numbers or such. However, there are a couple codepaths in the kernel where firmware file names contain string components that are passed through from a device or semi-privileged userspace; the ones I could find (not counting interfaces that require root privileges) are: - lpfc_sli4_request_firmware_update() seems to construct the firmware filename from \"ModelName\", a string that was previously parsed out of some descriptor (\"Vital Product Data\") in lpfc_fill_vpd() - nfp_net_fw_find() seems to construct a firmware filename from a model name coming from nfp_hwinfo_lookup(pf->hwinfo, \"nffw.partno\"), which I think parses some descriptor that was read from the device. (But this case likely isn't exploitable because the format string looks like \"netronome/nic_%s\", and there shouldn't be any *folders* starting with \"netronome/nic_\". The previous case was different because there, the \"%s\" is *at the start* of the format string.) - module_flash_fw_schedule() is reachable from the ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is enough to pass the privilege check), and takes a userspace-provided firmware name. (But I think to reach this case, you need to have CAP_NET_ADMIN over a network namespace that a special kind of ethernet device is mapped into, so I think this is not a viable attack path in practice.) Fix it by rejecting any firmware names containing \"..\" path components. For what it's worth, I went looking and haven't found any USB device drivers that use the firmware loader dangerously.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47682", "url": "https://ubuntu.com/security/CVE-2024-47682", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sd: Fix off-by-one error in sd_read_block_characteristics() Ff the device returns page 0xb1 with length 8 (happens with qemu v2.x, for example), sd_read_block_characteristics() may attempt an out-of-bounds memory access when accessing the zoned field at offset 8.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47743", "url": "https://ubuntu.com/security/CVE-2024-47743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: prevent NULL pointer dereference in find_asymmetric_key() In find_asymmetric_key(), if all NULLs are passed in the id_{0,1,2} arguments, the kernel will first emit WARN but then have an oops because id_2 gets dereferenced anyway. Add the missing id_2 check and move WARN_ON() to the final else branch to avoid duplicate NULL checks. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47727", "url": "https://ubuntu.com/security/CVE-2024-47727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/tdx: Fix \"in-kernel MMIO\" check TDX only supports kernel-initiated MMIO operations. The handle_mmio() function checks if the #VE exception occurred in the kernel and rejects the operation if it did not. However, userspace can deceive the kernel into performing MMIO on its behalf. For example, if userspace can point a syscall to an MMIO address, syscall does get_user() or put_user() on it, triggering MMIO #VE. The kernel will treat the #VE as in-kernel MMIO. Ensure that the target MMIO address is within the kernel before decoding instruction.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47744", "url": "https://ubuntu.com/security/CVE-2024-47744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Use dedicated mutex to protect kvm_usage_count to avoid deadlock Use a dedicated mutex to guard kvm_usage_count to fix a potential deadlock on x86 due to a chain of locks and SRCU synchronizations. Translating the below lockdep splat, CPU1 #6 will wait on CPU0 #1, CPU0 #8 will wait on CPU2 #3, and CPU2 #7 will wait on CPU1 #4 (if there's a writer, due to the fairness of r/w semaphores). CPU0 CPU1 CPU2 1 lock(&kvm->slots_lock); 2 lock(&vcpu->mutex); 3 lock(&kvm->srcu); 4 lock(cpu_hotplug_lock); 5 lock(kvm_lock); 6 lock(&kvm->slots_lock); 7 lock(cpu_hotplug_lock); 8 sync(&kvm->srcu); Note, there are likely more potential deadlocks in KVM x86, e.g. the same pattern of taking cpu_hotplug_lock outside of kvm_lock likely exists with __kvmclock_cpufreq_notifier(): cpuhp_cpufreq_online() | -> cpufreq_online() | -> cpufreq_gov_performance_limits() | -> __cpufreq_driver_target() | -> __target_index() | -> cpufreq_freq_transition_begin() | -> cpufreq_notify_transition() | -> ... __kvmclock_cpufreq_notifier() But, actually triggering such deadlocks is beyond rare due to the combination of dependencies and timings involved. E.g. the cpufreq notifier is only used on older CPUs without a constant TSC, mucking with the NX hugepage mitigation while VMs are running is very uncommon, and doing so while also onlining/offlining a CPU (necessary to generate contention on cpu_hotplug_lock) would be even more unusual. The most robust solution to the general cpu_hotplug_lock issue is likely to switch vm_list to be an RCU-protected list, e.g. so that x86's cpufreq notifier doesn't to take kvm_lock. For now, settle for fixing the most blatant deadlock, as switching to an RCU-protected list is a much more involved change, but add a comment in locking.rst to call out that care needs to be taken when walking holding kvm_lock and walking vm_list. ====================================================== WARNING: possible circular locking dependency detected 6.10.0-smp--c257535a0c9d-pip #330 Tainted: G S O ------------------------------------------------------ tee/35048 is trying to acquire lock: ff6a80eced71e0a8 (&kvm->slots_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x179/0x1e0 [kvm] but task is already holding lock: ffffffffc07abb08 (kvm_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x14a/0x1e0 [kvm] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (kvm_lock){+.+.}-{3:3}: __mutex_lock+0x6a/0xb40 mutex_lock_nested+0x1f/0x30 kvm_dev_ioctl+0x4fb/0xe50 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #2 (cpu_hotplug_lock){++++}-{0:0}: cpus_read_lock+0x2e/0xb0 static_key_slow_inc+0x16/0x30 kvm_lapic_set_base+0x6a/0x1c0 [kvm] kvm_set_apic_base+0x8f/0xe0 [kvm] kvm_set_msr_common+0x9ae/0xf80 [kvm] vmx_set_msr+0xa54/0xbe0 [kvm_intel] __kvm_set_msr+0xb6/0x1a0 [kvm] kvm_arch_vcpu_ioctl+0xeca/0x10c0 [kvm] kvm_vcpu_ioctl+0x485/0x5b0 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (&kvm->srcu){.+.+}-{0:0}: __synchronize_srcu+0x44/0x1a0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47719", "url": "https://ubuntu.com/security/CVE-2024-47719", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommufd: Protect against overflow of ALIGN() during iova allocation Userspace can supply an iova and uptr such that the target iova alignment becomes really big and ALIGN() overflows which corrupts the selected area range during allocation. CONFIG_IOMMUFD_TEST can detect this: WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline] WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352 Modules linked in: CPU: 1 PID: 5092 Comm: syz-executor294 Not tainted 6.10.0-rc5-syzkaller-00294-g3ffea9a7a6f7 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024 RIP: 0010:iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline] RIP: 0010:iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352 Code: fc e9 a4 f3 ff ff e8 1a 8b 4c fc 41 be e4 ff ff ff e9 8a f3 ff ff e8 0a 8b 4c fc 90 0f 0b 90 e9 37 f5 ff ff e8 fc 8a 4c fc 90 <0f> 0b 90 e9 68 f3 ff ff 48 c7 c1 ec 82 ad 8f 80 e1 07 80 c1 03 38 RSP: 0018:ffffc90003ebf9e0 EFLAGS: 00010293 RAX: ffffffff85499fa4 RBX: 00000000ffffffef RCX: ffff888079b49e00 RDX: 0000000000000000 RSI: 00000000ffffffef RDI: 0000000000000000 RBP: ffffc90003ebfc50 R08: ffffffff85499b30 R09: ffffffff85499942 R10: 0000000000000002 R11: ffff888079b49e00 R12: ffff8880228e0010 R13: 0000000000000000 R14: 1ffff920007d7f68 R15: ffffc90003ebfd00 FS: 000055557d760380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000005fdeb8 CR3: 000000007404a000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: iommufd_ioas_copy+0x610/0x7b0 drivers/iommu/iommufd/ioas.c:274 iommufd_fops_ioctl+0x4d9/0x5a0 drivers/iommu/iommufd/main.c:421 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Cap the automatic alignment to the huge page size, which is probably a better idea overall. Huge automatic alignments can fragment and chew up the available IOVA space without any reason.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47745", "url": "https://ubuntu.com/security/CVE-2024-47745", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: call the security_mmap_file() LSM hook in remap_file_pages() The remap_file_pages syscall handler calls do_mmap() directly, which doesn't contain the LSM security check. And if the process has called personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for RW pages, this will actually result in remapping the pages to RWX, bypassing a W^X policy enforced by SELinux. So we should check prot by security_mmap_file LSM hook in the remap_file_pages syscall handler before do_mmap() is called. Otherwise, it potentially permits an attacker to bypass a W^X policy enforced by SELinux. The bypass is similar to CVE-2016-10044, which bypass the same thing via AIO and can be found in [1]. The PoC: $ cat > test.c int main(void) { \tsize_t pagesz = sysconf(_SC_PAGE_SIZE); \tint mfd = syscall(SYS_memfd_create, \"test\", 0); \tconst char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE, \t\tMAP_SHARED, mfd, 0); \tunsigned int old = syscall(SYS_personality, 0xffffffff); \tsyscall(SYS_personality, READ_IMPLIES_EXEC | old); \tsyscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0); \tsyscall(SYS_personality, old); \t// show the RWX page exists even if W^X policy is enforced \tint fd = open(\"/proc/self/maps\", O_RDONLY); \tunsigned char buf2[1024]; \twhile (1) { \t\tint ret = read(fd, buf2, 1024); \t\tif (ret <= 0) break; \t\twrite(1, buf2, ret); \t} \tclose(fd); } $ gcc test.c -o test $ ./test | grep rwx 7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted) [PM: subject line tweaks]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47746", "url": "https://ubuntu.com/security/CVE-2024-47746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: use exclusive lock when FUSE_I_CACHE_IO_MODE is set This may be a typo. The comment has said shared locks are not allowed when this bit is set. If using shared lock, the wait in `fuse_file_cached_io_open` may be forever.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47734", "url": "https://ubuntu.com/security/CVE-2024-47734", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: Fix unnecessary warnings and logs from bond_xdp_get_xmit_slave() syzbot reported a WARNING in bond_xdp_get_xmit_slave. To reproduce this[1], one bond device (bond1) has xdpdrv, which increases bpf_master_redirect_enabled_key. Another bond device (bond0) which is unsupported by XDP but its slave (veth3) has xdpgeneric that returns XDP_TX. This triggers WARN_ON_ONCE() from the xdp_master_redirect(). To reduce unnecessary warnings and improve log management, we need to delete the WARN_ON_ONCE() and add ratelimit to the netdev_err(). [1] Steps to reproduce: # Needs tx_xdp with return XDP_TX; ip l add veth0 type veth peer veth1 ip l add veth3 type veth peer veth4 ip l add bond0 type bond mode 6 # BOND_MODE_ALB, unsupported by XDP ip l add bond1 type bond # BOND_MODE_ROUNDROBIN by default ip l set veth0 master bond1 ip l set bond1 up # Increases bpf_master_redirect_enabled_key ip l set dev bond1 xdpdrv object tx_xdp.o section xdp_tx ip l set veth3 master bond0 ip l set bond0 up ip l set veth4 up # Triggers WARN_ON_ONCE() from the xdp_master_redirect() ip l set veth3 xdpgeneric object tx_xdp.o section xdp_tx", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47684", "url": "https://ubuntu.com/security/CVE-2024-47684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: check skb is non-NULL in tcp_rto_delta_us() We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic kernel that are running ceph and recently hit a null ptr dereference in tcp_rearm_rto(). Initially hitting it from the TLP path, but then later we also saw it getting hit from the RACK case as well. Here are examples of the oops messages we saw in each of those cases: Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020 Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode Jul 26 15:05:02 rx [11061395.792971] #PF: error_code(0x0000) - not-present page Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0 Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI Jul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu Jul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023 Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 <48> 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3 Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246 Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000 Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60 Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8 Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900 Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30 Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000 Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0 Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554 Jul 26 15:05:02 rx [11061395.916786] Call Trace: Jul 26 15:05:02 rx [11061395.919488] Jul 26 15:05:02 rx [11061395.921765] ? show_regs.cold+0x1a/0x1f Jul 26 15:05:02 rx [11061395.925859] ? __die+0x90/0xd9 Jul 26 15:05:02 rx [11061395.929169] ? no_context+0x196/0x380 Jul 26 15:05:02 rx [11061395.933088] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0 Jul 26 15:05:02 rx [11061395.938216] ? ip6_sublist_rcv_finish+0x3d/0x50 Jul 26 15:05:02 rx [11061395.943000] ? __bad_area_nosemaphore+0x50/0x1a0 Jul 26 15:05:02 rx [11061395.947873] ? bad_area_nosemaphore+0x16/0x20 Jul 26 15:05:02 rx [11061395.952486] ? do_user_addr_fault+0x267/0x450 Jul 26 15:05:02 rx [11061395.957104] ? ipv6_list_rcv+0x112/0x140 Jul 26 15:05:02 rx [11061395.961279] ? __do_page_fault+0x58/0x90 Jul 26 15:05:02 rx [11061395.965458] ? do_page_fault+0x2c/0xe0 Jul 26 15:05:02 rx [11061395.969465] ? page_fault+0x34/0x40 Jul 26 15:05:02 rx [11061395.973217] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.977313] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.981408] tcp_send_loss_probe+0x10b/0x220 Jul 26 15:05:02 rx [11061395.985937] tcp_write_timer_handler+0x1b4/0x240 Jul 26 15:05:02 rx [11061395.990809] tcp_write_timer+0x9e/0xe0 Jul 26 15:05:02 rx [11061395.994814] ? tcp_write_timer_handler+0x240/0x240 Jul 26 15:05:02 rx [11061395.999866] call_timer_fn+0x32/0x130 Jul 26 15:05:02 rx [11061396.003782] __run_timers.part.0+0x180/0x280 Jul 26 15:05:02 rx [11061396.008309] ? recalibrate_cpu_khz+0x10/0x10 Jul 26 15:05:02 rx [11061396.012841] ? native_x2apic_icr_write+0x30/0x30 Jul 26 15:05:02 rx [11061396.017718] ? lapic_next_even ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47747", "url": "https://ubuntu.com/security/CVE-2024-47747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race Condition In the ether3_probe function, a timer is initialized with a callback function ether3_ledoff, bound to &prev(dev)->timer. Once the timer is started, there is a risk of a race condition if the module or device is removed, triggering the ether3_remove function to perform cleanup. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | ether3_ledoff ether3_remove | free_netdev(dev); | put_devic | kfree(dev); | | ether3_outw(priv(dev)->regs.config2 |= CFG2_CTRLO, REG_CONFIG2); | // use dev Fix it by ensuring that the timer is canceled before proceeding with the cleanup in ether3_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47685", "url": "https://ubuntu.com/security/CVE-2024-47685", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put() syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending garbage on the four reserved tcp bits (th->res1) Use skb_put_zero() to clear the whole TCP header, as done in nf_reject_ip_tcphdr_put() BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5661 [inline] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775 process_backlog+0x4ad/0xa50 net/core/dev.c:6108 __napi_poll+0xe7/0x980 net/core/dev.c:6772 napi_poll net/core/dev.c:6841 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963 handle_softirqs+0x1ce/0x800 kernel/softirq.c:554 __do_softirq+0x14/0x1a kernel/softirq.c:588 do_softirq+0x9a/0x100 kernel/softirq.c:455 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline] __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450 dev_queue_xmit include/linux/netdevice.h:3105 [inline] neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366 inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135 __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143 tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333 __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679 inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750 __sys_connect_file net/socket.c:2061 [inline] __sys_connect+0x606/0x690 net/socket.c:2078 __do_sys_connect net/socket.c:2088 [inline] __se_sys_connect net/socket.c:2085 [inline] __x64_sys_connect+0x91/0xe0 net/socket.c:2085 x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43 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 Uninit was stored to memory at: nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47686", "url": "https://ubuntu.com/security/CVE-2024-47686", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ep93xx: clock: Fix off by one in ep93xx_div_recalc_rate() The psc->div[] array has psc->num_div elements. These values come from when we call clk_hw_register_div(). It's adc_divisors and ARRAY_SIZE(adc_divisors)) and so on. So this condition needs to be >= instead of > to prevent an out of bounds read.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47748", "url": "https://ubuntu.com/security/CVE-2024-47748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost_vdpa: assign irq bypass producer token correctly We used to call irq_bypass_unregister_producer() in vhost_vdpa_setup_vq_irq() which is problematic as we don't know if the token pointer is still valid or not. Actually, we use the eventfd_ctx as the token so the life cycle of the token should be bound to the VHOST_SET_VRING_CALL instead of vhost_vdpa_setup_vq_irq() which could be called by set_status(). Fixing this by setting up irq bypass producer's token when handling VHOST_SET_VRING_CALL and un-registering the producer before calling vhost_vring_ioctl() to prevent a possible use after free as eventfd could have been released in vhost_vring_ioctl(). And such registering and unregistering will only be done if DRIVER_OK is set.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47687", "url": "https://ubuntu.com/security/CVE-2024-47687", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa/mlx5: Fix invalid mr resource destroy Certain error paths from mlx5_vdpa_dev_add() can end up releasing mr resources which never got initialized in the first place. This patch adds the missing check in mlx5_vdpa_destroy_mr_resources() to block releasing non-initialized mr resources. Reference trace: mlx5_core 0000:08:00.2: mlx5_vdpa_dev_add:3274:(pid 2700) warning: No mac address provisioned? BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 140216067 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 8 PID: 2700 Comm: vdpa Kdump: loaded Not tainted 5.14.0-496.el9.x86_64 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:vhost_iotlb_del_range+0xf/0xe0 [vhost_iotlb] Code: [...] RSP: 0018:ff1c823ac23077f0 EFLAGS: 00010246 RAX: ffffffffc1a21a60 RBX: ffffffff899567a0 RCX: 0000000000000000 RDX: ffffffffffffffff RSI: 0000000000000000 RDI: 0000000000000000 RBP: ff1bda1f7c21e800 R08: 0000000000000000 R09: ff1c823ac2307670 R10: ff1c823ac2307668 R11: ffffffff8a9e7b68 R12: 0000000000000000 R13: 0000000000000000 R14: ff1bda1f43e341a0 R15: 00000000ffffffea FS: 00007f56eba7c740(0000) GS:ff1bda269f800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000104d90001 CR4: 0000000000771ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? mlx5_vdpa_free+0x3d/0x150 [mlx5_vdpa] ? __die_body.cold+0x8/0xd ? page_fault_oops+0x134/0x170 ? __irq_work_queue_local+0x2b/0xc0 ? irq_work_queue+0x2c/0x50 ? exc_page_fault+0x62/0x150 ? asm_exc_page_fault+0x22/0x30 ? __pfx_mlx5_vdpa_free+0x10/0x10 [mlx5_vdpa] ? vhost_iotlb_del_range+0xf/0xe0 [vhost_iotlb] mlx5_vdpa_free+0x3d/0x150 [mlx5_vdpa] vdpa_release_dev+0x1e/0x50 [vdpa] device_release+0x31/0x90 kobject_cleanup+0x37/0x130 mlx5_vdpa_dev_add+0x2d2/0x7a0 [mlx5_vdpa] vdpa_nl_cmd_dev_add_set_doit+0x277/0x4c0 [vdpa] genl_family_rcv_msg_doit+0xd9/0x130 genl_family_rcv_msg+0x14d/0x220 ? __pfx_vdpa_nl_cmd_dev_add_set_doit+0x10/0x10 [vdpa] ? _copy_to_user+0x1a/0x30 ? move_addr_to_user+0x4b/0xe0 genl_rcv_msg+0x47/0xa0 ? __import_iovec+0x46/0x150 ? __pfx_genl_rcv_msg+0x10/0x10 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x245/0x370 netlink_sendmsg+0x206/0x440 __sys_sendto+0x1dc/0x1f0 ? do_read_fault+0x10c/0x1d0 ? do_pte_missing+0x10d/0x190 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x5c/0xf0 ? __count_memcg_events+0x4f/0xb0 ? mm_account_fault+0x6c/0x100 ? handle_mm_fault+0x116/0x270 ? do_user_addr_fault+0x1d6/0x6a0 ? do_syscall_64+0x6b/0xf0 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 entry_SYSCALL_64_after_hwframe+0x78/0x80", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47688", "url": "https://ubuntu.com/security/CVE-2024-47688", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: driver core: Fix a potential null-ptr-deref in module_add_driver() Inject fault while probing of-fpga-region, if kasprintf() fails in module_add_driver(), the second sysfs_remove_link() in exit path will cause null-ptr-deref as below because kernfs_name_hash() will call strlen() with NULL driver_name. Fix it by releasing resources based on the exit path sequence. \t KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] \t Mem abort info: \t ESR = 0x0000000096000005 \t EC = 0x25: DABT (current EL), IL = 32 bits \t SET = 0, FnV = 0 \t EA = 0, S1PTW = 0 \t FSC = 0x05: level 1 translation fault \t Data abort info: \t ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 \t CM = 0, WnR = 0, TnD = 0, TagAccess = 0 \t GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 \t [dfffffc000000000] address between user and kernel address ranges \t Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP \t Dumping ftrace buffer: \t (ftrace buffer empty) \t Modules linked in: of_fpga_region(+) fpga_region fpga_bridge cfg80211 rfkill 8021q garp mrp stp llc ipv6 [last unloaded: of_fpga_region] \t CPU: 2 UID: 0 PID: 2036 Comm: modprobe Not tainted 6.11.0-rc2-g6a0e38264012 #295 \t Hardware name: linux,dummy-virt (DT) \t pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) \t pc : strlen+0x24/0xb0 \t lr : kernfs_name_hash+0x1c/0xc4 \t sp : ffffffc081f97380 \t x29: ffffffc081f97380 x28: ffffffc081f97b90 x27: ffffff80c821c2a0 \t x26: ffffffedac0be418 x25: 0000000000000000 x24: ffffff80c09d2000 \t x23: 0000000000000000 x22: 0000000000000000 x21: 0000000000000000 \t x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000001840 \t x17: 0000000000000000 x16: 0000000000000000 x15: 1ffffff8103f2e42 \t x14: 00000000f1f1f1f1 x13: 0000000000000004 x12: ffffffb01812d61d \t x11: 1ffffff01812d61c x10: ffffffb01812d61c x9 : dfffffc000000000 \t x8 : 0000004fe7ed29e4 x7 : ffffff80c096b0e7 x6 : 0000000000000001 \t x5 : ffffff80c096b0e0 x4 : 1ffffffdb990efa2 x3 : 0000000000000000 \t x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000000 \t Call trace: \t strlen+0x24/0xb0 \t kernfs_name_hash+0x1c/0xc4 \t kernfs_find_ns+0x118/0x2e8 \t kernfs_remove_by_name_ns+0x80/0x100 \t sysfs_remove_link+0x74/0xa8 \t module_add_driver+0x278/0x394 \t bus_add_driver+0x1f0/0x43c \t driver_register+0xf4/0x3c0 \t __platform_driver_register+0x60/0x88 \t of_fpga_region_init+0x20/0x1000 [of_fpga_region] \t do_one_initcall+0x110/0x788 \t do_init_module+0x1dc/0x5c8 \t load_module+0x3c38/0x4cac \t init_module_from_file+0xd4/0x128 \t idempotent_init_module+0x2cc/0x528 \t __arm64_sys_finit_module+0xac/0x100 \t invoke_syscall+0x6c/0x258 \t el0_svc_common.constprop.0+0x160/0x22c \t do_el0_svc+0x44/0x5c \t el0_svc+0x48/0xb8 \t el0t_64_sync_handler+0x13c/0x158 \t el0t_64_sync+0x190/0x194 \t Code: f2fbffe1 a90157f4 12000802 aa0003f5 (38e16861) \t ---[ end trace 0000000000000000 ]--- \t Kernel panic - not syncing: Oops: Fatal exception", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47689", "url": "https://ubuntu.com/security/CVE-2024-47689", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to don't set SB_RDONLY in f2fs_handle_critical_error() syzbot reports a f2fs bug as below: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 58 at kernel/rcu/sync.c:177 rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177 CPU: 1 UID: 0 PID: 58 Comm: kworker/1:2 Not tainted 6.10.0-syzkaller-12562-g1722389b0d86 #0 Workqueue: events destroy_super_work RIP: 0010:rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177 Call Trace: percpu_free_rwsem+0x41/0x80 kernel/locking/percpu-rwsem.c:42 destroy_super_work+0xec/0x130 fs/super.c:282 process_one_work kernel/workqueue.c:3231 [inline] process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 worker_thread+0x86d/0xd40 kernel/workqueue.c:3390 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 As Christian Brauner pointed out [1]: the root cause is f2fs sets SB_RDONLY flag in internal function, rather than setting the flag covered w/ sb->s_umount semaphore via remount procedure, then below race condition causes this bug: - freeze_super() - sb_wait_write(sb, SB_FREEZE_WRITE) - sb_wait_write(sb, SB_FREEZE_PAGEFAULT) - sb_wait_write(sb, SB_FREEZE_FS) \t\t\t\t\t- f2fs_handle_critical_error \t\t\t\t\t - sb->s_flags |= SB_RDONLY - thaw_super - thaw_super_locked - sb_rdonly() is true, so it skips sb_freeze_unlock(sb, SB_FREEZE_FS) - deactivate_locked_super Since f2fs has almost the same logic as ext4 [2] when handling critical error in filesystem if it mounts w/ errors=remount-ro option: - set CP_ERROR_FLAG flag which indicates filesystem is stopped - record errors to superblock - set SB_RDONLY falg Once we set CP_ERROR_FLAG flag, all writable interfaces can detect the flag and stop any further updates on filesystem. So, it is safe to not set SB_RDONLY flag, let's remove the logic and keep in line w/ ext4 [3]. [1] https://lore.kernel.org/all/20240729-himbeeren-funknetz-96e62f9c7aee@brauner [2] https://lore.kernel.org/all/20240729132721.hxih6ehigadqf7wx@quack3 [3] https://lore.kernel.org/linux-ext4/20240805201241.27286-1-jack@suse.cz", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47690", "url": "https://ubuntu.com/security/CVE-2024-47690", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: get rid of online repaire on corrupted directory syzbot reports a f2fs bug as below: kernel BUG at fs/f2fs/inode.c:896! RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Call Trace: evict+0x532/0x950 fs/inode.c:704 dispose_list fs/inode.c:747 [inline] evict_inodes+0x5f9/0x690 fs/inode.c:797 generic_shutdown_super+0x9d/0x2d0 fs/super.c:627 kill_block_super+0x44/0x90 fs/super.c:1696 kill_f2fs_super+0x344/0x690 fs/f2fs/super.c:4898 deactivate_locked_super+0xc4/0x130 fs/super.c:473 cleanup_mnt+0x41f/0x4b0 fs/namespace.c:1373 task_work_run+0x24f/0x310 kernel/task_work.c:228 ptrace_notify+0x2d2/0x380 kernel/signal.c:2402 ptrace_report_syscall include/linux/ptrace.h:415 [inline] ptrace_report_syscall_exit include/linux/ptrace.h:477 [inline] syscall_exit_work+0xc6/0x190 kernel/entry/common.c:173 syscall_exit_to_user_mode_prepare kernel/entry/common.c:200 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:205 [inline] syscall_exit_to_user_mode+0x279/0x370 kernel/entry/common.c:218 do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Online repaire on corrupted directory in f2fs_lookup() can generate dirty data/meta while racing w/ readonly remount, it may leave dirty inode after filesystem becomes readonly, however, checkpoint() will skips flushing dirty inode in a state of readonly mode, result in above panic. Let's get rid of online repaire in f2fs_lookup(), and leave the work to fsck.f2fs.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47691", "url": "https://ubuntu.com/security/CVE-2024-47691", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread() syzbot reports a f2fs bug as below: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_report+0xe8/0x550 mm/kasan/report.c:491 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 instrument_atomic_read_write include/linux/instrumented.h:96 [inline] atomic_fetch_add_relaxed include/linux/atomic/atomic-instrumented.h:252 [inline] __refcount_add include/linux/refcount.h:184 [inline] __refcount_inc include/linux/refcount.h:241 [inline] refcount_inc include/linux/refcount.h:258 [inline] get_task_struct include/linux/sched/task.h:118 [inline] kthread_stop+0xca/0x630 kernel/kthread.c:704 f2fs_stop_gc_thread+0x65/0xb0 fs/f2fs/gc.c:210 f2fs_do_shutdown+0x192/0x540 fs/f2fs/file.c:2283 f2fs_ioc_shutdown fs/f2fs/file.c:2325 [inline] __f2fs_ioctl+0x443a/0xbe60 fs/f2fs/file.c:4325 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f The root cause is below race condition, it may cause use-after-free issue in sbi->gc_th pointer. - remount - f2fs_remount - f2fs_stop_gc_thread - kfree(gc_th) \t\t\t\t- f2fs_ioc_shutdown \t\t\t\t - f2fs_do_shutdown \t\t\t\t - f2fs_stop_gc_thread \t\t\t\t - kthread_stop(gc_th->f2fs_gc_task) : sbi->gc_thread = NULL; We will call f2fs_do_shutdown() in two paths: - for f2fs_ioc_shutdown() path, we should grab sb->s_umount semaphore for fixing. - for f2fs_shutdown() path, it's safe since caller has already grabbed sb->s_umount semaphore.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47692", "url": "https://ubuntu.com/security/CVE-2024-47692", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: return -EINVAL when namelen is 0 When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may result in namelen being 0, which will cause memdup_user() to return ZERO_SIZE_PTR. When we access the name.data that has been assigned the value of ZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is triggered. [ T1205] ================================================================== [ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260 [ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205 [ T1205] [ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406 [ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ T1205] Call Trace: [ T1205] dump_stack+0x9a/0xd0 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] __kasan_report.cold+0x34/0x84 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] kasan_report+0x3a/0x50 [ T1205] nfs4_client_to_reclaim+0xe9/0x260 [ T1205] ? nfsd4_release_lockowner+0x410/0x410 [ T1205] cld_pipe_downcall+0x5ca/0x760 [ T1205] ? nfsd4_cld_tracking_exit+0x1d0/0x1d0 [ T1205] ? down_write_killable_nested+0x170/0x170 [ T1205] ? avc_policy_seqno+0x28/0x40 [ T1205] ? selinux_file_permission+0x1b4/0x1e0 [ T1205] rpc_pipe_write+0x84/0xb0 [ T1205] vfs_write+0x143/0x520 [ T1205] ksys_write+0xc9/0x170 [ T1205] ? __ia32_sys_read+0x50/0x50 [ T1205] ? ktime_get_coarse_real_ts64+0xfe/0x110 [ T1205] ? ktime_get_coarse_real_ts64+0xa2/0x110 [ T1205] do_syscall_64+0x33/0x40 [ T1205] entry_SYSCALL_64_after_hwframe+0x67/0xd1 [ T1205] RIP: 0033:0x7fdbdb761bc7 [ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 514 [ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7 [ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008 [ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001 [ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b [ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000 [ T1205] ================================================================== Fix it by checking namelen.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47737", "url": "https://ubuntu.com/security/CVE-2024-47737", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: call cache_put if xdr_reserve_space returns NULL If not enough buffer space available, but idmap_lookup has triggered lookup_fn which calls cache_get and returns successfully. Then we missed to call cache_put here which pairs with cache_get. Reviwed-by: Jeff Layton ", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2023-52917", "url": "https://ubuntu.com/security/CVE-2023-52917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir() The debugfs_create_dir() function returns error pointers. It never returns NULL. So use IS_ERR() to check it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47749", "url": "https://ubuntu.com/security/CVE-2024-47749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Added NULL check for lookup_atid The lookup_atid() function can return NULL if the ATID is invalid or does not exist in the identifier table, which could lead to dereferencing a null pointer without a check in the `act_establish()` and `act_open_rpl()` functions. Add a NULL check to prevent null pointer dereferencing. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47735", "url": "https://ubuntu.com/security/CVE-2024-47735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled Fix missuse of spin_lock_irq()/spin_unlock_irq() when spin_lock_irqsave()/spin_lock_irqrestore() was hold. This was discovered through the lock debugging, and the corresponding log is as follows: raw_local_irq_restore() called with IRQs enabled WARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40 ... Call trace: warn_bogus_irq_restore+0x30/0x40 _raw_spin_unlock_irqrestore+0x84/0xc8 add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2] hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2] hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2] create_qp+0x138/0x258 ib_create_qp_kernel+0x50/0xe8 create_mad_qp+0xa8/0x128 ib_mad_port_open+0x218/0x448 ib_mad_init_device+0x70/0x1f8 add_client_context+0xfc/0x220 enable_device_and_get+0xd0/0x140 ib_register_device.part.0+0xf4/0x1c8 ib_register_device+0x34/0x50 hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2] hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2] __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2] hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47750", "url": "https://ubuntu.com/security/CVE-2024-47750", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix Use-After-Free of rsv_qp on HIP08 Currently rsv_qp is freed before ib_unregister_device() is called on HIP08. During the time interval, users can still dereg MR and rsv_qp will be used in this process, leading to a UAF. Move the release of rsv_qp after calling ib_unregister_device() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47751", "url": "https://ubuntu.com/security/CVE-2024-47751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: kirin: Fix buffer overflow in kirin_pcie_parse_port() Within kirin_pcie_parse_port(), the pcie->num_slots is compared to pcie->gpio_id_reset size (MAX_PCI_SLOTS) which is correct and would lead to an overflow. Thus, fix condition to pcie->num_slots + 1 >= MAX_PCI_SLOTS and move pcie->num_slots increment below the if-statement to avoid out-of-bounds array access. Found by Linux Verification Center (linuxtesting.org) with SVACE. [kwilczynski: commit log]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47693", "url": "https://ubuntu.com/security/CVE-2024-47693", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/core: Fix ib_cache_setup_one error flow cleanup When ib_cache_update return an error, we exit ib_cache_setup_one instantly with no proper cleanup, even though before this we had already successfully done gid_table_setup_one, that results in the kernel WARN below. Do proper cleanup using gid_table_cleanup_one before returning the err in order to fix the issue. WARNING: CPU: 4 PID: 922 at drivers/infiniband/core/cache.c:806 gid_table_release_one+0x181/0x1a0 Modules linked in: CPU: 4 UID: 0 PID: 922 Comm: c_repro Not tainted 6.11.0-rc1+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:gid_table_release_one+0x181/0x1a0 Code: 44 8b 38 75 0c e8 2f cb 34 ff 4d 8b b5 28 05 00 00 e8 23 cb 34 ff 44 89 f9 89 da 4c 89 f6 48 c7 c7 d0 58 14 83 e8 4f de 21 ff <0f> 0b 4c 8b 75 30 e9 54 ff ff ff 48 8 3 c4 10 5b 5d 41 5c 41 5d 41 RSP: 0018:ffffc90002b835b0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c8527 RDX: 0000000000000000 RSI: ffffffff811c8534 RDI: 0000000000000001 RBP: ffff8881011b3d00 R08: ffff88810b3abe00 R09: 205d303839303631 R10: 666572207972746e R11: 72746e6520444947 R12: 0000000000000001 R13: ffff888106390000 R14: ffff8881011f2110 R15: 0000000000000001 FS: 00007fecc3b70800(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000340 CR3: 000000010435a001 CR4: 00000000003706b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? show_regs+0x94/0xa0 ? __warn+0x9e/0x1c0 ? gid_table_release_one+0x181/0x1a0 ? report_bug+0x1f9/0x340 ? gid_table_release_one+0x181/0x1a0 ? handle_bug+0xa2/0x110 ? exc_invalid_op+0x31/0xa0 ? asm_exc_invalid_op+0x16/0x20 ? __warn_printk+0xc7/0x180 ? __warn_printk+0xd4/0x180 ? gid_table_release_one+0x181/0x1a0 ib_device_release+0x71/0xe0 ? __pfx_ib_device_release+0x10/0x10 device_release+0x44/0xd0 kobject_put+0x135/0x3d0 put_device+0x20/0x30 rxe_net_add+0x7d/0xa0 rxe_newlink+0xd7/0x190 nldev_newlink+0x1b0/0x2a0 ? __pfx_nldev_newlink+0x10/0x10 rdma_nl_rcv_msg+0x1ad/0x2e0 rdma_nl_rcv_skb.constprop.0+0x176/0x210 netlink_unicast+0x2de/0x400 netlink_sendmsg+0x306/0x660 __sock_sendmsg+0x110/0x120 ____sys_sendmsg+0x30e/0x390 ___sys_sendmsg+0x9b/0xf0 ? kstrtouint+0x6e/0xa0 ? kstrtouint_from_user+0x7c/0xb0 ? get_pid_task+0xb0/0xd0 ? proc_fail_nth_write+0x5b/0x140 ? __fget_light+0x9a/0x200 ? preempt_count_add+0x47/0xa0 __sys_sendmsg+0x61/0xd0 do_syscall_64+0x50/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47694", "url": "https://ubuntu.com/security/CVE-2024-47694", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mlx5: Fix UMR pd cleanup on error flow of driver init The cited commit moves the pd allocation from function mlx5r_umr_resource_cleanup() to a new function mlx5r_umr_cleanup(). So the fix in commit [1] is broken. In error flow, will hit panic [2]. Fix it by checking pd pointer to avoid panic if it is NULL; [1] RDMA/mlx5: Fix UMR cleanup on error flow of driver init [2] [ 347.567063] infiniband mlx5_0: Couldn't register device with driver model [ 347.591382] BUG: kernel NULL pointer dereference, address: 0000000000000020 [ 347.593438] #PF: supervisor read access in kernel mode [ 347.595176] #PF: error_code(0x0000) - not-present page [ 347.596962] PGD 0 P4D 0 [ 347.601361] RIP: 0010:ib_dealloc_pd_user+0x12/0xc0 [ib_core] [ 347.604171] RSP: 0018:ffff888106293b10 EFLAGS: 00010282 [ 347.604834] RAX: 0000000000000000 RBX: 000000000000000e RCX: 0000000000000000 [ 347.605672] RDX: ffff888106293ad0 RSI: 0000000000000000 RDI: 0000000000000000 [ 347.606529] RBP: 0000000000000000 R08: ffff888106293ae0 R09: ffff888106293ae0 [ 347.607379] R10: 0000000000000a06 R11: 0000000000000000 R12: 0000000000000000 [ 347.608224] R13: ffffffffa0704dc0 R14: 0000000000000001 R15: 0000000000000001 [ 347.609067] FS: 00007fdc720cd9c0(0000) GS:ffff88852c880000(0000) knlGS:0000000000000000 [ 347.610094] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 347.610727] CR2: 0000000000000020 CR3: 0000000103012003 CR4: 0000000000370eb0 [ 347.611421] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 347.612113] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 347.612804] Call Trace: [ 347.613130] [ 347.613417] ? __die+0x20/0x60 [ 347.613793] ? page_fault_oops+0x150/0x3e0 [ 347.614243] ? free_msg+0x68/0x80 [mlx5_core] [ 347.614840] ? cmd_exec+0x48f/0x11d0 [mlx5_core] [ 347.615359] ? exc_page_fault+0x74/0x130 [ 347.615808] ? asm_exc_page_fault+0x22/0x30 [ 347.616273] ? ib_dealloc_pd_user+0x12/0xc0 [ib_core] [ 347.616801] mlx5r_umr_cleanup+0x23/0x90 [mlx5_ib] [ 347.617365] mlx5_ib_stage_pre_ib_reg_umr_cleanup+0x36/0x40 [mlx5_ib] [ 347.618025] __mlx5_ib_add+0x96/0xd0 [mlx5_ib] [ 347.618539] mlx5r_probe+0xe9/0x310 [mlx5_ib] [ 347.619032] ? kernfs_add_one+0x107/0x150 [ 347.619478] ? __mlx5_ib_add+0xd0/0xd0 [mlx5_ib] [ 347.619984] auxiliary_bus_probe+0x3e/0x90 [ 347.620448] really_probe+0xc5/0x3a0 [ 347.620857] __driver_probe_device+0x80/0x160 [ 347.621325] driver_probe_device+0x1e/0x90 [ 347.621770] __driver_attach+0xec/0x1c0 [ 347.622213] ? __device_attach_driver+0x100/0x100 [ 347.622724] bus_for_each_dev+0x71/0xc0 [ 347.623151] bus_add_driver+0xed/0x240 [ 347.623570] driver_register+0x58/0x100 [ 347.623998] __auxiliary_driver_register+0x6a/0xc0 [ 347.624499] ? driver_register+0xae/0x100 [ 347.624940] ? 0xffffffffa0893000 [ 347.625329] mlx5_ib_init+0x16a/0x1e0 [mlx5_ib] [ 347.625845] do_one_initcall+0x4a/0x2a0 [ 347.626273] ? gcov_event+0x2e2/0x3a0 [ 347.626706] do_init_module+0x8a/0x260 [ 347.627126] init_module_from_file+0x8b/0xd0 [ 347.627596] __x64_sys_finit_module+0x1ca/0x2f0 [ 347.628089] do_syscall_64+0x4c/0x100", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47695", "url": "https://ubuntu.com/security/CVE-2024-47695", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds In the function init_conns(), after the create_con() and create_cm() for loop if something fails. In the cleanup for loop after the destroy tag, we access out of bound memory because cid is set to clt_path->s.con_num. This commits resets the cid to clt_path->s.con_num - 1, to stay in bounds in the cleanup loop later.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47752", "url": "https://ubuntu.com/security/CVE-2024-47752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix H264 stateless decoder smatch warning Fix a smatch static checker warning on vdec_h264_req_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47753", "url": "https://ubuntu.com/security/CVE-2024-47753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix VP8 stateless decoder smatch warning Fix a smatch static checker warning on vdec_vp8_req_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47754", "url": "https://ubuntu.com/security/CVE-2024-47754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix H264 multi stateless decoder smatch warning Fix a smatch static checker warning on vdec_h264_req_multi_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47696", "url": "https://ubuntu.com/security/CVE-2024-47696", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency In the commit aee2424246f9 (\"RDMA/iwcm: Fix a use-after-free related to destroying CM IDs\"), the function flush_workqueue is invoked to flush the work queue iwcm_wq. But at that time, the work queue iwcm_wq was created via the function alloc_ordered_workqueue without the flag WQ_MEM_RECLAIM. Because the current process is trying to flush the whole iwcm_wq, if iwcm_wq doesn't have the flag WQ_MEM_RECLAIM, verify that the current process is not reclaiming memory or running on a workqueue which doesn't have the flag WQ_MEM_RECLAIM as that can break forward-progress guarantee leading to a deadlock. The call trace is as below: [ 125.350876][ T1430] Call Trace: [ 125.356281][ T1430] [ 125.361285][ T1430] ? __warn (kernel/panic.c:693) [ 125.367640][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.375689][ T1430] ? report_bug (lib/bug.c:180 lib/bug.c:219) [ 125.382505][ T1430] ? handle_bug (arch/x86/kernel/traps.c:239) [ 125.388987][ T1430] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) [ 125.395831][ T1430] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621) [ 125.403125][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.410984][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.418764][ T1430] __flush_workqueue (kernel/workqueue.c:3970) [ 125.426021][ T1430] ? __pfx___might_resched (kernel/sched/core.c:10151) [ 125.433431][ T1430] ? destroy_cm_id (drivers/infiniband/core/iwcm.c:375) iw_cm [ 125.441209][ T1430] ? __pfx___flush_workqueue (kernel/workqueue.c:3910) [ 125.473900][ T1430] ? _raw_spin_lock_irqsave (arch/x86/include/asm/atomic.h:107 include/linux/atomic/atomic-arch-fallback.h:2170 include/linux/atomic/atomic-instrumented.h:1302 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162) [ 125.473909][ T1430] ? __pfx__raw_spin_lock_irqsave (kernel/locking/spinlock.c:161) [ 125.482537][ T1430] _destroy_id (drivers/infiniband/core/cma.c:2044) rdma_cm [ 125.495072][ T1430] nvme_rdma_free_queue (drivers/nvme/host/rdma.c:656 drivers/nvme/host/rdma.c:650) nvme_rdma [ 125.505827][ T1430] nvme_rdma_reset_ctrl_work (drivers/nvme/host/rdma.c:2180) nvme_rdma [ 125.505831][ T1430] process_one_work (kernel/workqueue.c:3231) [ 125.515122][ T1430] worker_thread (kernel/workqueue.c:3306 kernel/workqueue.c:3393) [ 125.515127][ T1430] ? __pfx_worker_thread (kernel/workqueue.c:3339) [ 125.531837][ T1430] kthread (kernel/kthread.c:389) [ 125.539864][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.550628][ T1430] ret_from_fork (arch/x86/kernel/process.c:147) [ 125.558840][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.558844][ T1430] ret_from_fork_asm (arch/x86/entry/entry_64.S:257) [ 125.566487][ T1430] [ 125.566488][ T1430] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47755", "url": "https://ubuntu.com/security/CVE-2024-47755", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47756", "url": "https://ubuntu.com/security/CVE-2024-47756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: keystone: Fix if-statement expression in ks_pcie_quirk() This code accidentally uses && where || was intended. It potentially results in a NULL dereference. Thus, fix the if-statement expression to use the correct condition. [kwilczynski: commit log]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47697", "url": "https://ubuntu.com/security/CVE-2024-47697", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error Ensure index in rtl2830_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47698", "url": "https://ubuntu.com/security/CVE-2024-47698", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error Ensure index in rtl2832_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue. [hverkuil: added fixes tag, rtl2830_pid_filter -> rtl2832_pid_filter in logmsg]", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47728", "url": "https://ubuntu.com/security/CVE-2024-47728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error For all non-tracing helpers which formerly had ARG_PTR_TO_{LONG,INT} as input arguments, zero the value for the case of an error as otherwise it could leak memory. For tracing, it is not needed given CAP_PERFMON can already read all kernel memory anyway hence bpf_get_func_arg() and bpf_get_func_ret() is skipped in here. Also, the MTU helpers mtu_len pointer value is being written but also read. Technically, the MEM_UNINIT should not be there in order to always force init. Removing MEM_UNINIT needs more verifier rework though: MEM_UNINIT right now implies two things actually: i) write into memory, ii) memory does not have to be initialized. If we lift MEM_UNINIT, it then becomes: i) read into memory, ii) memory must be initialized. This means that for bpf_*_check_mtu() we're readding the issue we're trying to fix, that is, it would then be able to write back into things like .rodata BPF maps. Follow-up work will rework the MEM_UNINIT semantics such that the intent can be better expressed. For now just clear the *mtu_len on error path which can be lifted later again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49861", "url": "https://ubuntu.com/security/CVE-2024-49861", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix helper writes to read-only maps Lonial found an issue that despite user- and BPF-side frozen BPF map (like in case of .rodata), it was still possible to write into it from a BPF program side through specific helpers having ARG_PTR_TO_{LONG,INT} as arguments. In check_func_arg() when the argument is as mentioned, the meta->raw_mode is never set. Later, check_helper_mem_access(), under the case of PTR_TO_MAP_VALUE as register base type, it assumes BPF_READ for the subsequent call to check_map_access_type() and given the BPF map is read-only it succeeds. The helpers really need to be annotated as ARG_PTR_TO_{LONG,INT} | MEM_UNINIT when results are written into them as opposed to read out of them. The latter indicates that it's okay to pass a pointer to uninitialized memory as the memory is written to anyway. However, ARG_PTR_TO_{LONG,INT} is a special case of ARG_PTR_TO_FIXED_SIZE_MEM just with additional alignment requirement. So it is better to just get rid of the ARG_PTR_TO_{LONG,INT} special cases altogether and reuse the fixed size memory types. For this, add MEM_ALIGNED to additionally ensure alignment given these helpers write directly into the args via * = val. The .arg*_size has been initialized reflecting the actual sizeof(*). MEM_ALIGNED can only be used in combination with MEM_FIXED_SIZE annotated argument types, since in !MEM_FIXED_SIZE cases the verifier does not know the buffer size a priori and therefore cannot blindly write * = val.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47757", "url": "https://ubuntu.com/security/CVE-2024-47757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential oob read in nilfs_btree_check_delete() The function nilfs_btree_check_delete(), which checks whether degeneration to direct mapping occurs before deleting a b-tree entry, causes memory access outside the block buffer when retrieving the maximum key if the root node has no entries. This does not usually happen because b-tree mappings with 0 child nodes are never created by mkfs.nilfs2 or nilfs2 itself. However, it can happen if the b-tree root node read from a device is configured that way, so fix this potential issue by adding a check for that case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47699", "url": "https://ubuntu.com/security/CVE-2024-47699", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential null-ptr-deref in nilfs_btree_insert() Patch series \"nilfs2: fix potential issues with empty b-tree nodes\". This series addresses three potential issues with empty b-tree nodes that can occur with corrupted filesystem images, including one recently discovered by syzbot. This patch (of 3): If a b-tree is broken on the device, and the b-tree height is greater than 2 (the level of the root node is greater than 1) even if the number of child nodes of the b-tree root is 0, a NULL pointer dereference occurs in nilfs_btree_prepare_insert(), which is called from nilfs_btree_insert(). This is because, when the number of child nodes of the b-tree root is 0, nilfs_btree_do_lookup() does not set the block buffer head in any of path[x].bp_bh, leaving it as the initial value of NULL, but if the level of the b-tree root node is greater than 1, nilfs_btree_get_nonroot_node(), which accesses the buffer memory of path[x].bp_bh, is called. Fix this issue by adding a check to nilfs_btree_root_broken(), which performs sanity checks when reading the root node from the device, to detect this inconsistency. Thanks to Lizhi Xu for trying to solve the bug and clarifying the cause early on.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47700", "url": "https://ubuntu.com/security/CVE-2024-47700", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: check stripe size compatibility on remount as well We disable stripe size in __ext4_fill_super if it is not a multiple of the cluster ratio however this check is missed when trying to remount. This can leave us with cases where stripe < cluster_ratio after remount:set making EXT4_B2C(sbi->s_stripe) become 0 that can cause some unforeseen bugs like divide by 0. Fix that by adding the check in remount path as well.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47701", "url": "https://ubuntu.com/security/CVE-2024-47701", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid OOB when system.data xattr changes underneath the filesystem When looking up for an entry in an inlined directory, if e_value_offs is changed underneath the filesystem by some change in the block device, it will lead to an out-of-bounds access that KASAN detects as an UAF. EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none. loop0: detected capacity change from 2048 to 2047 ================================================================== BUG: KASAN: use-after-free in ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 Read of size 1 at addr ffff88803e91130f by task syz-executor269/5103 CPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 Not tainted 6.11.0-rc4-syzkaller #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:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 ext4_find_inline_entry+0x4be/0x5e0 fs/ext4/inline.c:1697 __ext4_find_entry+0x2b4/0x1b30 fs/ext4/namei.c:1573 ext4_lookup_entry fs/ext4/namei.c:1727 [inline] ext4_lookup+0x15f/0x750 fs/ext4/namei.c:1795 lookup_one_qstr_excl+0x11f/0x260 fs/namei.c:1633 filename_create+0x297/0x540 fs/namei.c:3980 do_symlinkat+0xf9/0x3a0 fs/namei.c:4587 __do_sys_symlinkat fs/namei.c:4610 [inline] __se_sys_symlinkat fs/namei.c:4607 [inline] __x64_sys_symlinkat+0x95/0xb0 fs/namei.c:4607 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:0x7f3e73ced469 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff4d40c258 EFLAGS: 00000246 ORIG_RAX: 000000000000010a RAX: ffffffffffffffda RBX: 0032656c69662f2e RCX: 00007f3e73ced469 RDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0 RBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290 R10: 0023706f6f6c2f76 R11: 0000000000000246 R12: 00007fff4d40c27c R13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0 Calling ext4_xattr_ibody_find right after reading the inode with ext4_get_inode_loc will lead to a check of the validity of the xattrs, avoiding this problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49850", "url": "https://ubuntu.com/security/CVE-2024-49850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: correctly handle malformed BPF_CORE_TYPE_ID_LOCAL relos In case of malformed relocation record of kind BPF_CORE_TYPE_ID_LOCAL referencing a non-existing BTF type, function bpf_core_calc_relo_insn would cause a null pointer deference. Fix this by adding a proper check upper in call stack, as malformed relocation records could be passed from user space. Simplest reproducer is a program: r0 = 0 exit With a single relocation record: .insn_off = 0, /* patch first instruction */ .type_id = 100500, /* this type id does not exist */ .access_str_off = 6, /* offset of string \"0\" */ .kind = BPF_CORE_TYPE_ID_LOCAL, See the link for original reproducer or next commit for a test case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47702", "url": "https://ubuntu.com/security/CVE-2024-47702", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fail verification for sign-extension of packet data/data_end/data_meta syzbot reported a kernel crash due to commit 1f1e864b6555 (\"bpf: Handle sign-extenstin ctx member accesses\"). The reason is due to sign-extension of 32-bit load for packet data/data_end/data_meta uapi field. The original code looks like: r2 = *(s32 *)(r1 + 76) /* load __sk_buff->data */ r3 = *(u32 *)(r1 + 80) /* load __sk_buff->data_end */ r0 = r2 r0 += 8 if r3 > r0 goto +1 ... Note that __sk_buff->data load has 32-bit sign extension. After verification and convert_ctx_accesses(), the final asm code looks like: r2 = *(u64 *)(r1 +208) r2 = (s32)r2 r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 ... Note that 'r2 = (s32)r2' may make the kernel __sk_buff->data address invalid which may cause runtime failure. Currently, in C code, typically we have void *data = (void *)(long)skb->data; void *data_end = (void *)(long)skb->data_end; ... and it will generate r2 = *(u64 *)(r1 +208) r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 If we allow sign-extension, void *data = (void *)(long)(int)skb->data; void *data_end = (void *)(long)skb->data_end; ... the generated code looks like r2 = *(u64 *)(r1 +208) r2 <<= 32 r2 s>>= 32 r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 and this will cause verification failure since \"r2 <<= 32\" is not allowed as \"r2\" is a packet pointer. To fix this issue for case r2 = *(s32 *)(r1 + 76) /* load __sk_buff->data */ this patch added additional checking in is_valid_access() callback function for packet data/data_end/data_meta access. If those accesses are with sign-extenstion, the verification will fail. [1] https://lore.kernel.org/bpf/000000000000c90eee061d236d37@google.com/", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47703", "url": "https://ubuntu.com/security/CVE-2024-47703", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, lsm: Add check for BPF LSM return value A bpf prog returning a positive number attached to file_alloc_security hook makes kernel panic. This happens because file system can not filter out the positive number returned by the LSM prog using IS_ERR, and misinterprets this positive number as a file pointer. Given that hook file_alloc_security never returned positive number before the introduction of BPF LSM, and other BPF LSM hooks may encounter similar issues, this patch adds LSM return value check in verifier, to ensure no unexpected value is returned.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49851", "url": "https://ubuntu.com/security/CVE-2024-49851", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: Clean up TPM space after command failure tpm_dev_transmit prepares the TPM space before attempting command transmission. However if the command fails no rollback of this preparation is done. This can result in transient handles being leaked if the device is subsequently closed with no further commands performed. Fix this by flushing the space in the event of command transmission failure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47723", "url": "https://ubuntu.com/security/CVE-2024-47723", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: fix out-of-bounds in dbNextAG() and diAlloc() In dbNextAG() , there is no check for the case where bmp->db_numag is greater or same than MAXAG due to a polluted image, which causes an out-of-bounds. Therefore, a bounds check should be added in dbMount(). And in dbNextAG(), a check for the case where agpref is greater than bmp->db_numag should be added, so an out-of-bounds exception should be prevented. Additionally, a check for the case where agno is greater or same than MAXAG should be added in diAlloc() to prevent out-of-bounds.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49852", "url": "https://ubuntu.com/security/CVE-2024-49852", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: elx: libefc: Fix potential use after free in efc_nport_vport_del() The kref_put() function will call nport->release if the refcount drops to zero. The nport->release release function is _efc_nport_free() which frees \"nport\". But then we dereference \"nport\" on the next line which is a use after free. Re-order these lines to avoid the use after free.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47720", "url": "https://ubuntu.com/security/CVE-2024-47720", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for set_output_gamma in dcn30_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn30_set_output_transfer_func function. Previously, set_output_gamma was being checked for nullity at line 386, but then it was being dereferenced without any nullity check at line 401. This could potentially lead to a null pointer dereference error if set_output_gamma is indeed null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a nullity check for set_output_gamma before the call to set_output_gamma at line 401. If set_output_gamma is null, we log an error message and do not call the function. This fix prevents a potential null pointer dereference error. drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:401 dcn30_set_output_transfer_func() error: we previously assumed 'mpc->funcs->set_output_gamma' could be null (see line 386) drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c 373 bool dcn30_set_output_transfer_func(struct dc *dc, 374 struct pipe_ctx *pipe_ctx, 375 const struct dc_stream_state *stream) 376 { 377 int mpcc_id = pipe_ctx->plane_res.hubp->inst; 378 struct mpc *mpc = pipe_ctx->stream_res.opp->ctx->dc->res_pool->mpc; 379 const struct pwl_params *params = NULL; 380 bool ret = false; 381 382 /* program OGAM or 3DLUT only for the top pipe*/ 383 if (pipe_ctx->top_pipe == NULL) { 384 /*program rmu shaper and 3dlut in MPC*/ 385 ret = dcn30_set_mpc_shaper_3dlut(pipe_ctx, stream); 386 if (ret == false && mpc->funcs->set_output_gamma) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If this is NULL 387 if (stream->out_transfer_func.type == TF_TYPE_HWPWL) 388 params = &stream->out_transfer_func.pwl; 389 else if (pipe_ctx->stream->out_transfer_func.type == 390 TF_TYPE_DISTRIBUTED_POINTS && 391 cm3_helper_translate_curve_to_hw_format( 392 &stream->out_transfer_func, 393 &mpc->blender_params, false)) 394 params = &mpc->blender_params; 395 /* there are no ROM LUTs in OUTGAM */ 396 if (stream->out_transfer_func.type == TF_TYPE_PREDEFINED) 397 BREAK_TO_DEBUGGER(); 398 } 399 } 400 --> 401 mpc->funcs->set_output_gamma(mpc, mpcc_id, params); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Then it will crash 402 return ret; 403 }", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47704", "url": "https://ubuntu.com/security/CVE-2024-47704", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check link_res->hpo_dp_link_enc before using it [WHAT & HOW] Functions dp_enable_link_phy and dp_disable_link_phy can pass link_res without initializing hpo_dp_link_enc and it is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49853", "url": "https://ubuntu.com/security/CVE-2024-49853", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix double free in OPTEE transport Channels can be shared between protocols, avoid freeing the same channel descriptors twice when unloading the stack.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47705", "url": "https://ubuntu.com/security/CVE-2024-47705", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix potential invalid pointer dereference in blk_add_partition The blk_add_partition() function initially used a single if-condition (IS_ERR(part)) to check for errors when adding a partition. This was modified to handle the specific case of -ENXIO separately, allowing the function to proceed without logging the error in this case. However, this change unintentionally left a path where md_autodetect_dev() could be called without confirming that part is a valid pointer. This commit separates the error handling logic by splitting the initial if-condition, improving code readability and handling specific error scenarios explicitly. The function now distinguishes the general error case from -ENXIO without altering the existing behavior of md_autodetect_dev() calls.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47736", "url": "https://ubuntu.com/security/CVE-2024-47736", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: handle overlapped pclusters out of crafted images properly syzbot reported a task hang issue due to a deadlock case where it is waiting for the folio lock of a cached folio that will be used for cache I/Os. After looking into the crafted fuzzed image, I found it's formed with several overlapped big pclusters as below: Ext: logical offset | length : physical offset | length 0: 0.. 16384 | 16384 : 151552.. 167936 | 16384 1: 16384.. 32768 | 16384 : 155648.. 172032 | 16384 2: 32768.. 49152 | 16384 : 537223168.. 537239552 | 16384 ... Here, extent 0/1 are physically overlapped although it's entirely _impossible_ for normal filesystem images generated by mkfs. First, managed folios containing compressed data will be marked as up-to-date and then unlocked immediately (unlike in-place folios) when compressed I/Os are complete. If physical blocks are not submitted in the incremental order, there should be separate BIOs to avoid dependency issues. However, the current code mis-arranges z_erofs_fill_bio_vec() and BIO submission which causes unexpected BIO waits. Second, managed folios will be connected to their own pclusters for efficient inter-queries. However, this is somewhat hard to implement easily if overlapped big pclusters exist. Again, these only appear in fuzzed images so let's simply fall back to temporary short-lived pages for correctness. Additionally, it justifies that referenced managed folios cannot be truncated for now and reverts part of commit 2080ca1ed3e4 (\"erofs: tidy up `struct z_erofs_bvec`\") for simplicity although it shouldn't be any difference.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47706", "url": "https://ubuntu.com/security/CVE-2024-47706", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block, bfq: fix possible UAF for bfqq->bic with merge chain 1) initial state, three tasks: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t\t | ? | ?\t\t | ? \t\t | | | |\t\t | | \t\t V | V |\t\t V | \t\t bfqq1 bfqq2\t\t bfqq3 process ref:\t 1\t\t 1\t\t 1 2) bfqq1 merged to bfqq2: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t\t | |\t\t | ? \t\t \\--------------\\|\t\t | | \t\t V\t\t V | \t\t bfqq1--------->bfqq2\t\t bfqq3 process ref:\t 0\t\t 2\t\t 1 3) bfqq2 merged to bfqq3: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t here -> ? |\t\t | \t\t \\--------------\\ \\-------------\\| \t\t V\t\t V \t\t bfqq1--------->bfqq2---------->bfqq3 process ref:\t 0\t\t 1\t\t 3 In this case, IO from Process 1 will get bfqq2 from BIC1 first, and then get bfqq3 through merge chain, and finially handle IO by bfqq3. Howerver, current code will think bfqq2 is owned by BIC1, like initial state, and set bfqq2->bic to BIC1. bfq_insert_request -> by Process 1 bfqq = bfq_init_rq(rq) bfqq = bfq_get_bfqq_handle_split bfqq = bic_to_bfqq -> get bfqq2 from BIC1 bfqq->ref++ rq->elv.priv[0] = bic rq->elv.priv[1] = bfqq if (bfqq_process_refs(bfqq) == 1) bfqq->bic = bic -> record BIC1 to bfqq2 __bfq_insert_request new_bfqq = bfq_setup_cooperator -> get bfqq3 from bfqq2->new_bfqq bfqq_request_freed(bfqq) new_bfqq->ref++ rq->elv.priv[1] = new_bfqq -> handle IO by bfqq3 Fix the problem by checking bfqq is from merge chain fist. And this might fix a following problem reported by our syzkaller(unreproducible): ================================================================== BUG: KASAN: slab-use-after-free in bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] BUG: KASAN: slab-use-after-free in bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] BUG: KASAN: slab-use-after-free in bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 Write of size 1 at addr ffff888123839eb8 by task kworker/0:1H/18595 CPU: 0 PID: 18595 Comm: kworker/0:1H Tainted: G L 6.6.0-07439-gba2303cacfda #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Workqueue: kblockd blk_mq_requeue_work Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [inline] print_report+0x10d/0x610 mm/kasan/report.c:475 kasan_report+0x8e/0xc0 mm/kasan/report.c:588 bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 bfq_get_bfqq_handle_split+0x169/0x5d0 block/bfq-iosched.c:6757 bfq_init_rq block/bfq-iosched.c:6876 [inline] bfq_insert_request block/bfq-iosched.c:6254 [inline] bfq_insert_requests+0x1112/0x5cf0 block/bfq-iosched.c:6304 blk_mq_insert_request+0x290/0x8d0 block/blk-mq.c:2593 blk_mq_requeue_work+0x6bc/0xa70 block/blk-mq.c:1502 process_one_work kernel/workqueue.c:2627 [inline] process_scheduled_works+0x432/0x13f0 kernel/workqueue.c:2700 worker_thread+0x6f2/0x1160 kernel/workqueue.c:2781 kthread+0x33c/0x440 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:305 Allocated by task 20776: kasan_save_stack+0x20/0x40 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 __kasan_slab_alloc+0x87/0x90 mm/kasan/common.c:328 kasan_slab_alloc include/linux/kasan.h:188 [inline] slab_post_alloc_hook mm/slab.h:763 [inline] slab_alloc_node mm/slub.c:3458 [inline] kmem_cache_alloc_node+0x1a4/0x6f0 mm/slub.c:3503 ioc_create_icq block/blk-ioc.c:370 [inline] ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49855", "url": "https://ubuntu.com/security/CVE-2024-49855", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: fix race between timeout and normal completion If request timetout is handled by nbd_requeue_cmd(), normal completion has to be stopped for avoiding to complete this requeued request, other use-after-free can be triggered. Fix the race by clearing NBD_CMD_INFLIGHT in nbd_requeue_cmd(), meantime make sure that cmd->lock is grabbed for clearing the flag and the requeue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47707", "url": "https://ubuntu.com/security/CVE-2024-47707", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev() Blamed commit accidentally removed a check for rt->rt6i_idev being NULL, as spotted by syzbot: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 UID: 0 PID: 10998 Comm: syz-executor Not tainted 6.11.0-rc6-syzkaller-00208-g625403177711 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 RBP: ffffc900047375d0 R08: 0000000000000003 R09: fffff520008e6e8c R10: dffffc0000000000 R11: fffff520008e6e8c R12: 1ffff1100fdf8f18 R13: ffff88807efc7998 R14: 0000000000000000 R15: ffff88807efc7930 FS: 0000000000000000(0000) GS:ffff8880b8900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020002a80 CR3: 0000000022f62000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: addrconf_ifdown+0x15d/0x1bd0 net/ipv6/addrconf.c:3856 addrconf_notify+0x3cb/0x1020 notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93 call_netdevice_notifiers_extack net/core/dev.c:2032 [inline] call_netdevice_notifiers net/core/dev.c:2046 [inline] unregister_netdevice_many_notify+0xd81/0x1c40 net/core/dev.c:11352 unregister_netdevice_many net/core/dev.c:11414 [inline] unregister_netdevice_queue+0x303/0x370 net/core/dev.c:11289 unregister_netdevice include/linux/netdevice.h:3129 [inline] __tun_detach+0x6b9/0x1600 drivers/net/tun.c:685 tun_detach drivers/net/tun.c:701 [inline] tun_chr_close+0x108/0x1b0 drivers/net/tun.c:3510 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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:0x7f1acc77def9 Code: Unable to access opcode bytes at 0x7f1acc77decf. RSP: 002b:00007ffeb26fa738 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1acc77def9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000043 RBP: 00007f1acc7dd508 R08: 00007ffeb26f84d7 R09: 0000000000000003 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 0000000000000003 R14: 00000000ffffffff R15: 00007ffeb26fa8e0 Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 R ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47708", "url": "https://ubuntu.com/security/CVE-2024-47708", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netkit: Assign missing bpf_net_context During the introduction of struct bpf_net_context handling for XDP-redirect, the netkit driver has been missed, which also requires it because NETKIT_REDIRECT invokes skb_do_redirect() which is accessing the per-CPU variables. Otherwise we see the following crash: \tBUG: kernel NULL pointer dereference, address: 0000000000000038 \tbpf_redirect() \tnetkit_xmit() \tdev_hard_start_xmit() Set the bpf_net_context before invoking netkit_xmit() program within the netkit driver.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47709", "url": "https://ubuntu.com/security/CVE-2024-47709", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: Clear bo->bcm_proc_read after remove_proc_entry(). syzbot reported a warning in bcm_release(). [0] The blamed change fixed another warning that is triggered when connect() is issued again for a socket whose connect()ed device has been unregistered. However, if the socket is just close()d without the 2nd connect(), the remaining bo->bcm_proc_read triggers unnecessary remove_proc_entry() in bcm_release(). Let's clear bo->bcm_proc_read after remove_proc_entry() in bcm_notify(). [0] name '4986' WARNING: CPU: 0 PID: 5234 at fs/proc/generic.c:711 remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Modules linked in: CPU: 0 UID: 0 PID: 5234 Comm: syz-executor606 Not tainted 6.11.0-rc5-syzkaller-00178-g5517ae241919 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Code: ff eb 05 e8 cb 1e 5e ff 48 8b 5c 24 10 48 c7 c7 e0 f7 aa 8e e8 2a 38 8e 09 90 48 c7 c7 60 3a 1b 8c 48 89 de e8 da 42 20 ff 90 <0f> 0b 90 90 48 8b 44 24 18 48 c7 44 24 40 0e 36 e0 45 49 c7 04 07 RSP: 0018:ffffc9000345fa20 EFLAGS: 00010246 RAX: 2a2d0aee2eb64600 RBX: ffff888032f1f548 RCX: ffff888029431e00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000345fb08 R08: ffffffff8155b2f2 R09: 1ffff1101710519a R10: dffffc0000000000 R11: ffffed101710519b R12: ffff888011d38640 R13: 0000000000000004 R14: 0000000000000000 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8880b8800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcfb52722f0 CR3: 000000000e734000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: bcm_release+0x250/0x880 net/can/bcm.c:1578 __sock_release net/socket.c:659 [inline] sock_close+0xbc/0x240 net/socket.c:1421 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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:0x7fcfb51ee969 Code: Unable to access opcode bytes at 0x7fcfb51ee93f. RSP: 002b:00007ffce0109ca8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fcfb51ee969 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 00007fcfb526f3b0 R08: ffffffffffffffb8 R09: 0000555500000000 R10: 0000555500000000 R11: 0000000000000246 R12: 00007fcfb526f3b0 R13: 0000000000000000 R14: 00007fcfb5271ee0 R15: 00007fcfb51bf160 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47710", "url": "https://ubuntu.com/security/CVE-2024-47710", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sock_map: Add a cond_resched() in sock_hash_free() Several syzbot soft lockup reports all have in common sock_hash_free() If a map with a large number of buckets is destroyed, we need to yield the cpu when needed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47711", "url": "https://ubuntu.com/security/CVE-2024-47711", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Don't return OOB skb in manage_oob(). syzbot reported use-after-free in unix_stream_recv_urg(). [0] The scenario is 1. send(MSG_OOB) 2. recv(MSG_OOB) -> The consumed OOB remains in recv queue 3. send(MSG_OOB) 4. recv() -> manage_oob() returns the next skb of the consumed OOB -> This is also OOB, but unix_sk(sk)->oob_skb is not cleared 5. recv(MSG_OOB) -> unix_sk(sk)->oob_skb is used but already freed The recent commit 8594d9b85c07 (\"af_unix: Don't call skb_get() for OOB skb.\") uncovered the issue. If the OOB skb is consumed and the next skb is peeked in manage_oob(), we still need to check if the skb is OOB. Let's do so by falling back to the following checks in manage_oob() and add the test case in selftest. Note that we need to add a similar check for SIOCATMARK. [0]: BUG: KASAN: slab-use-after-free in unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959 Read of size 4 at addr ffff8880326abcc4 by task syz-executor178/5235 CPU: 0 UID: 0 PID: 5235 Comm: syz-executor178 Not tainted 6.11.0-rc5-syzkaller-00742-gfbdaffe41adc #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959 unix_stream_recv_urg+0x1df/0x320 net/unix/af_unix.c:2640 unix_stream_read_generic+0x2456/0x2520 net/unix/af_unix.c:2778 unix_stream_recvmsg+0x22b/0x2c0 net/unix/af_unix.c:2996 sock_recvmsg_nosec net/socket.c:1046 [inline] sock_recvmsg+0x22f/0x280 net/socket.c:1068 ____sys_recvmsg+0x1db/0x470 net/socket.c:2816 ___sys_recvmsg net/socket.c:2858 [inline] __sys_recvmsg+0x2f0/0x3e0 net/socket.c:2888 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:0x7f5360d6b4e9 Code: 48 83 c4 28 c3 e8 37 17 00 00 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff29b3a458 EFLAGS: 00000246 ORIG_RAX: 000000000000002f RAX: ffffffffffffffda RBX: 00007fff29b3a638 RCX: 00007f5360d6b4e9 RDX: 0000000000002001 RSI: 0000000020000640 RDI: 0000000000000003 RBP: 00007f5360dde610 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 00007fff29b3a628 R14: 0000000000000001 R15: 0000000000000001 Allocated by task 5235: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:312 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slub.c:3988 [inline] slab_alloc_node mm/slub.c:4037 [inline] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4080 __alloc_skb+0x1c3/0x440 net/core/skbuff.c:667 alloc_skb include/linux/skbuff.h:1320 [inline] alloc_skb_with_frags+0xc3/0x770 net/core/skbuff.c:6528 sock_alloc_send_pskb+0x91a/0xa60 net/core/sock.c:2815 sock_alloc_send_skb include/net/sock.h:1778 [inline] queue_oob+0x108/0x680 net/unix/af_unix.c:2198 unix_stream_sendmsg+0xd24/0xf80 net/unix/af_unix.c:2351 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2680 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 Freed by task 5235: kasan_save_stack mm/kasan/common.c:47 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47712", "url": "https://ubuntu.com/security/CVE-2024-47712", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: fix potential RCU dereference issue in wilc_parse_join_bss_param In the `wilc_parse_join_bss_param` function, the TSF field of the `ies` structure is accessed after the RCU read-side critical section is unlocked. According to RCU usage rules, this is illegal. Reusing this pointer can lead to unpredictable behavior, including accessing memory that has been updated or causing use-after-free issues. This possible bug was identified using a static analysis tool developed by myself, specifically designed to detect RCU-related issues. To address this, the TSF value is now stored in a local variable `ies_tsf` before the RCU lock is released. The `param->tsf_lo` field is then assigned using this local variable, ensuring that the TSF value is safely accessed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47713", "url": "https://ubuntu.com/security/CVE-2024-47713", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop() Since '__dev_queue_xmit()' should be called with interrupts enabled, the following backtrace: ieee80211_do_stop() ... spin_lock_irqsave(&local->queue_stop_reason_lock, flags) ... ieee80211_free_txskb() ieee80211_report_used_skb() ieee80211_report_ack_skb() cfg80211_mgmt_tx_status_ext() nl80211_frame_tx_status() genlmsg_multicast_netns() genlmsg_multicast_netns_filtered() nlmsg_multicast_filtered() \t netlink_broadcast_filtered() \t do_one_broadcast() \t netlink_broadcast_deliver() \t __netlink_sendskb() \t netlink_deliver_tap() \t __netlink_deliver_tap_skb() \t dev_queue_xmit() \t __dev_queue_xmit() ; with IRQS disabled ... spin_unlock_irqrestore(&local->queue_stop_reason_lock, flags) issues the warning (as reported by syzbot reproducer): WARNING: CPU: 2 PID: 5128 at kernel/softirq.c:362 __local_bh_enable_ip+0xc3/0x120 Fix this by implementing a two-phase skb reclamation in 'ieee80211_do_stop()', where actual work is performed outside of a section with interrupts disabled.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47730", "url": "https://ubuntu.com/security/CVE-2024-47730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/qm - inject error before stopping queue The master ooo cannot be completely closed when the accelerator core reports memory error. Therefore, the driver needs to inject the qm error to close the master ooo. Currently, the qm error is injected after stopping queue, memory may be released immediately after stopping queue, causing the device to access the released memory. Therefore, error is injected to close master ooo before stopping queue to ensure that the device does not access the released memory.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49856", "url": "https://ubuntu.com/security/CVE-2024-49856", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/sgx: Fix deadlock in SGX NUMA node search When the current node doesn't have an EPC section configured by firmware and all other EPC sections are used up, CPU can get stuck inside the while loop that looks for an available EPC page from remote nodes indefinitely, leading to a soft lockup. Note how nid_of_current will never be equal to nid in that while loop because nid_of_current is not set in sgx_numa_mask. Also worth mentioning is that it's perfectly fine for the firmware not to setup an EPC section on a node. While setting up an EPC section on each node can enhance performance, it is not a requirement for functionality. Rework the loop to start and end on *a* node that has SGX memory. This avoids the deadlock looking for the current SGX-lacking node to show up in the loop when it never will.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47714", "url": "https://ubuntu.com/security/CVE-2024-47714", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: use hweight16 to get correct tx antenna The chainmask is u16 so using hweight8 cannot get correct tx_ant. Without this patch, the tx_ant of band 2 would be -1 and lead to the following issue: BUG: KASAN: stack-out-of-bounds in mt7996_mcu_add_sta+0x12e0/0x16e0 [mt7996e]", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47715", "url": "https://ubuntu.com/security/CVE-2024-47715", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: fix oops on non-dbdc mt7986 mt7915_band_config() sets band_idx = 1 on the main phy for mt7986 with MT7975_ONE_ADIE or MT7976_ONE_ADIE. Commit 0335c034e726 (\"wifi: mt76: fix race condition related to checking tx queue fill status\") introduced a dereference of the phys array indirectly indexed by band_idx via wcid->phy_idx in mt76_wcid_cleanup(). This caused the following Oops on affected mt7986 devices: Unable to handle kernel read from unreadable memory at virtual address 0000000000000024 Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x00000005 CM = 0, WnR = 0 user pgtable: 4k pages, 39-bit VAs, pgdp=0000000042545000 [0000000000000024] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 Internal error: Oops: 0000000096000005 [#1] SMP Modules linked in: ... mt7915e mt76_connac_lib mt76 mac80211 cfg80211 ... CPU: 2 PID: 1631 Comm: hostapd Not tainted 5.15.150 #0 Hardware name: ZyXEL EX5700 (Telenor) (DT) pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mt76_wcid_cleanup+0x84/0x22c [mt76] lr : mt76_wcid_cleanup+0x64/0x22c [mt76] sp : ffffffc00a803700 x29: ffffffc00a803700 x28: ffffff80008f7300 x27: ffffff80003f3c00 x26: ffffff80000a7880 x25: ffffffc008c26e00 x24: 0000000000000001 x23: ffffffc000a68114 x22: 0000000000000000 x21: ffffff8004172cc8 x20: ffffffc00a803748 x19: ffffff8004152020 x18: 0000000000000000 x17: 00000000000017c0 x16: ffffffc008ef5000 x15: 0000000000000be0 x14: ffffff8004172e28 x13: ffffff8004172e28 x12: 0000000000000000 x11: 0000000000000000 x10: ffffff8004172e30 x9 : ffffff8004172e28 x8 : 0000000000000000 x7 : ffffff8004156020 x6 : 0000000000000000 x5 : 0000000000000031 x4 : 0000000000000000 x3 : 0000000000000001 x2 : 0000000000000000 x1 : ffffff80008f7300 x0 : 0000000000000024 Call trace: mt76_wcid_cleanup+0x84/0x22c [mt76] __mt76_sta_remove+0x70/0xbc [mt76] mt76_sta_state+0x8c/0x1a4 [mt76] mt7915_eeprom_get_power_delta+0x11e4/0x23a0 [mt7915e] drv_sta_state+0x144/0x274 [mac80211] sta_info_move_state+0x1cc/0x2a4 [mac80211] sta_set_sinfo+0xaf8/0xc24 [mac80211] sta_info_destroy_addr_bss+0x4c/0x6c [mac80211] ieee80211_color_change_finish+0x1c08/0x1e70 [mac80211] cfg80211_check_station_change+0x1360/0x4710 [cfg80211] genl_family_rcv_msg_doit+0xb4/0x110 genl_rcv_msg+0xd0/0x1bc netlink_rcv_skb+0x58/0x120 genl_rcv+0x34/0x50 netlink_unicast+0x1f0/0x2ec netlink_sendmsg+0x198/0x3d0 ____sys_sendmsg+0x1b0/0x210 ___sys_sendmsg+0x80/0xf0 __sys_sendmsg+0x44/0xa0 __arm64_sys_sendmsg+0x20/0x30 invoke_syscall.constprop.0+0x4c/0xe0 do_el0_svc+0x40/0xd0 el0_svc+0x14/0x4c el0t_64_sync_handler+0x100/0x110 el0t_64_sync+0x15c/0x160 Code: d2800002 910092c0 52800023 f9800011 (885f7c01) ---[ end trace 7e42dd9a39ed2281 ]--- Fix by using mt76_dev_phy() which will map band_idx to the correct phy for all hardware combinations.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49857", "url": "https://ubuntu.com/security/CVE-2024-49857", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: set the cipher for secured NDP ranging The cipher pointer is not set, but is derefereced trying to set its content, which leads to a NULL pointer dereference. Fix it by pointing to the cipher parameter before dereferencing.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47738", "url": "https://ubuntu.com/security/CVE-2024-47738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: don't use rate mask for offchannel TX either Like the commit ab9177d83c04 (\"wifi: mac80211: don't use rate mask for scanning\"), ignore incorrect settings to avoid no supported rate warning reported by syzbot. The syzbot did bisect and found cause is commit 9df66d5b9f45 (\"cfg80211: fix default HE tx bitrate mask in 2G band\"), which however corrects bitmask of HE MCS and recognizes correctly settings of empty legacy rate plus HE MCS rate instead of returning -EINVAL. As suggestions [1], follow the change of SCAN TX to consider this case of offchannel TX as well. [1] https://lore.kernel.org/linux-wireless/6ab2dc9c3afe753ca6fdcdd1421e7a1f47e87b84.camel@sipsolutions.net/T/#m2ac2a6d2be06a37c9c47a3d8a44b4f647ed4f024", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47731", "url": "https://ubuntu.com/security/CVE-2024-47731", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers/perf: Fix ali_drw_pmu driver interrupt status clearing The alibaba_uncore_pmu driver forgot to clear all interrupt status in the interrupt processing function. After the PMU counter overflow interrupt occurred, an interrupt storm occurred, causing the system to hang. Therefore, clear the correct interrupt status in the interrupt handling function to fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49862", "url": "https://ubuntu.com/security/CVE-2024-49862", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powercap: intel_rapl: Fix off by one in get_rpi() The rp->priv->rpi array is either rpi_msr or rpi_tpmi which have NR_RAPL_PRIMITIVES number of elements. Thus the > needs to be >= to prevent an off by one access.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47716", "url": "https://ubuntu.com/security/CVE-2024-47716", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: 9410/1: vfp: Use asm volatile in fmrx/fmxr macros Floating point instructions in userspace can crash some arm kernels built with clang/LLD 17.0.6: BUG: unsupported FP instruction in kernel mode FPEXC == 0xc0000780 Internal error: Oops - undefined instruction: 0 [#1] ARM CPU: 0 PID: 196 Comm: vfp-reproducer Not tainted 6.10.0 #1 Hardware name: BCM2835 PC is at vfp_support_entry+0xc8/0x2cc LR is at do_undefinstr+0xa8/0x250 pc : [] lr : [] psr: a0000013 sp : dc8d1f68 ip : 60000013 fp : bedea19c r10: ec532b17 r9 : 00000010 r8 : 0044766c r7 : c0000780 r6 : ec532b17 r5 : c1c13800 r4 : dc8d1fb0 r3 : c10072c4 r2 : c0101c88 r1 : ec532b17 r0 : 0044766c Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 00c5387d Table: 0251c008 DAC: 00000051 Register r0 information: non-paged memory Register r1 information: vmalloc memory Register r2 information: non-slab/vmalloc memory Register r3 information: non-slab/vmalloc memory Register r4 information: 2-page vmalloc region Register r5 information: slab kmalloc-cg-2k Register r6 information: vmalloc memory Register r7 information: non-slab/vmalloc memory Register r8 information: non-paged memory Register r9 information: zero-size pointer Register r10 information: vmalloc memory Register r11 information: non-paged memory Register r12 information: non-paged memory Process vfp-reproducer (pid: 196, stack limit = 0x61aaaf8b) Stack: (0xdc8d1f68 to 0xdc8d2000) 1f60: 0000081f b6f69300 0000000f c10073f4 c10072c4 dc8d1fb0 1f80: ec532b17 0c532b17 0044766c b6f9ccd8 00000000 c010a80c 00447670 60000010 1fa0: ffffffff c1c13800 00c5387d c0100f10 b6f68af8 00448fc0 00000000 bedea188 1fc0: bedea314 00000001 00448ebc b6f9d000 00447608 b6f9ccd8 00000000 bedea19c 1fe0: bede9198 bedea188 b6e1061c 0044766c 60000010 ffffffff 00000000 00000000 Call trace: [] (vfp_support_entry) from [] (do_undefinstr+0xa8/0x250) [] (do_undefinstr) from [] (__und_usr+0x70/0x80) Exception stack(0xdc8d1fb0 to 0xdc8d1ff8) 1fa0: b6f68af8 00448fc0 00000000 bedea188 1fc0: bedea314 00000001 00448ebc b6f9d000 00447608 b6f9ccd8 00000000 bedea19c 1fe0: bede9198 bedea188 b6e1061c 0044766c 60000010 ffffffff Code: 0a000061 e3877202 e594003c e3a09010 (eef16a10) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Fatal exception in interrupt ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]--- This is a minimal userspace reproducer on a Raspberry Pi Zero W: #include #include int main(void) { double v = 1.0; printf(\"%fn\", NAN + *(volatile double *)&v); return 0; } Another way to consistently trigger the oops is: calvin@raspberry-pi-zero-w ~$ python -c \"import json\" The bug reproduces only when the kernel is built with DYNAMIC_DEBUG=n, because the pr_debug() calls act as barriers even when not activated. This is the output from the same kernel source built with the same compiler and DYNAMIC_DEBUG=y, where the userspace reproducer works as expected: VFP: bounce: trigger ec532b17 fpexc c0000780 VFP: emulate: INST=0xee377b06 SCR=0x00000000 VFP: bounce: trigger eef1fa10 fpexc c0000780 VFP: emulate: INST=0xeeb40b40 SCR=0x00000000 VFP: raising exceptions 30000000 calvin@raspberry-pi-zero-w ~$ ./vfp-reproducer nan Crudely grepping for vmsr/vmrs instructions in the otherwise nearly idential text for vfp_support_entry() makes the problem obvious: vmlinux.llvm.good [0xc0101cb8] <+48>: vmrs r7, fpexc vmlinux.llvm.good [0xc0101cd8] <+80>: vmsr fpexc, r0 vmlinux.llvm.good [0xc0101d20 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47717", "url": "https://ubuntu.com/security/CVE-2024-47717", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RISC-V: KVM: Don't zero-out PMU snapshot area before freeing data With the latest Linux-6.11-rc3, the below NULL pointer crash is observed when SBI PMU snapshot is enabled for the guest and the guest is forcefully powered-off. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000508 Oops [#1] Modules linked in: kvm CPU: 0 UID: 0 PID: 61 Comm: term-poll Not tainted 6.11.0-rc3-00018-g44d7178dd77a #3 Hardware name: riscv-virtio,qemu (DT) epc : __kvm_write_guest_page+0x94/0xa6 [kvm] ra : __kvm_write_guest_page+0x54/0xa6 [kvm] epc : ffffffff01590e98 ra : ffffffff01590e58 sp : ffff8f80001f39b0 gp : ffffffff81512a60 tp : ffffaf80024872c0 t0 : ffffaf800247e000 t1 : 00000000000007e0 t2 : 0000000000000000 s0 : ffff8f80001f39f0 s1 : 00007fff89ac4000 a0 : ffffffff015dd7e8 a1 : 0000000000000086 a2 : 0000000000000000 a3 : ffffaf8000000000 a4 : ffffaf80024882c0 a5 : 0000000000000000 a6 : ffffaf800328d780 a7 : 00000000000001cc s2 : ffffaf800197bd00 s3 : 00000000000828c4 s4 : ffffaf800248c000 s5 : ffffaf800247d000 s6 : 0000000000001000 s7 : 0000000000001000 s8 : 0000000000000000 s9 : 00007fff861fd500 s10: 0000000000000001 s11: 0000000000800000 t3 : 00000000000004d3 t4 : 00000000000004d3 t5 : ffffffff814126e0 t6 : ffffffff81412700 status: 0000000200000120 badaddr: 0000000000000508 cause: 000000000000000d [] __kvm_write_guest_page+0x94/0xa6 [kvm] [] kvm_vcpu_write_guest+0x56/0x90 [kvm] [] kvm_pmu_clear_snapshot_area+0x42/0x7e [kvm] [] kvm_riscv_vcpu_pmu_deinit.part.0+0xe0/0x14e [kvm] [] kvm_riscv_vcpu_pmu_deinit+0x1a/0x24 [kvm] [] kvm_arch_vcpu_destroy+0x28/0x4c [kvm] [] kvm_destroy_vcpus+0x5a/0xda [kvm] [] kvm_arch_destroy_vm+0x14/0x28 [kvm] [] kvm_destroy_vm+0x168/0x2a0 [kvm] [] kvm_put_kvm+0x3c/0x58 [kvm] [] kvm_vm_release+0x22/0x2e [kvm] Clearly, the kvm_vcpu_write_guest() function is crashing because it is being called from kvm_pmu_clear_snapshot_area() upon guest tear down. To address the above issue, simplify the kvm_pmu_clear_snapshot_area() to not zero-out PMU snapshot area from kvm_pmu_clear_snapshot_area() because the guest is anyway being tore down. The kvm_pmu_clear_snapshot_area() is also called when guest changes PMU snapshot area of a VCPU but even in this case the previous PMU snaphsot area must not be zeroed-out because the guest might have reclaimed the pervious PMU snapshot area for some other purpose.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47721", "url": "https://ubuntu.com/security/CVE-2024-47721", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: remove unused C2H event ID RTW89_MAC_C2H_FUNC_READ_WOW_CAM to prevent out-of-bounds reading The handler of firmware C2H event RTW89_MAC_C2H_FUNC_READ_WOW_CAM isn't implemented, but driver expects number of handlers is NUM_OF_RTW89_MAC_C2H_FUNC_WOW causing out-of-bounds access. Fix it by removing ID. Addresses-Coverity-ID: 1598775 (\"Out-of-bounds read\")", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47732", "url": "https://ubuntu.com/security/CVE-2024-47732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: iaa - Fix potential use after free bug The free_device_compression_mode(iaa_device, device_mode) function frees \"device_mode\" but it iss passed to iaa_compression_modes[i]->free() a few lines later resulting in a use after free. The good news is that, so far as I can tell, nothing implements the ->free() function and the use after free happens in dead code. But, with this fix, when something does implement it, we'll be ready. :)", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47718", "url": "https://ubuntu.com/security/CVE-2024-47718", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: always wait for both firmware loading attempts In 'rtw_wait_firmware_completion()', always wait for both (regular and wowlan) firmware loading attempts. Otherwise if 'rtw_usb_intf_init()' has failed in 'rtw_usb_probe()', 'rtw_usb_disconnect()' may issue 'ieee80211_free_hw()' when one of 'rtw_load_firmware_cb()' (usually the wowlan one) is still in progress, causing UAF detected by KASAN.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47724", "url": "https://ubuntu.com/security/CVE-2024-47724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: use work queue to process beacon tx event Commit 3a415daa3e8b (\"wifi: ath11k: add P2P IE in beacon template\") from Feb 28, 2024 (linux-next), leads to the following Smatch static checker warning: drivers/net/wireless/ath/ath11k/wmi.c:1742 ath11k_wmi_p2p_go_bcn_ie() warn: sleeping in atomic context The reason is that ath11k_bcn_tx_status_event() will directly call might sleep function ath11k_wmi_cmd_send() during RCU read-side critical sections. The call trace is like: ath11k_bcn_tx_status_event() -> rcu_read_lock() -> ath11k_mac_bcn_tx_event() \t-> ath11k_mac_setup_bcn_tmpl() \t…… \t\t-> ath11k_wmi_bcn_tmpl() \t\t\t-> ath11k_wmi_cmd_send() -> rcu_read_unlock() Commit 886433a98425 (\"ath11k: add support for BSS color change\") added the ath11k_mac_bcn_tx_event(), commit 01e782c89108 (\"ath11k: fix warning of RCU usage for ath11k_mac_get_arvif_by_vdev_id()\") added the RCU lock to avoid warning but also introduced this BUG. Use work queue to avoid directly calling ath11k_mac_bcn_tx_event() during RCU critical sections. No need to worry about the deletion of vif because cancel_work_sync() will drop the work if it doesn't start or block vif deletion until the running work is done. 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": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47671", "url": "https://ubuntu.com/security/CVE-2024-47671", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: usbtmc: prevent kernel-usb-infoleak The syzbot reported a kernel-usb-infoleak in usbtmc_write, we need to clear the structure before filling fields.", "cve_priority": "medium", "cve_public_date": "2024-10-09 15:15:00 UTC" }, { "cve": "CVE-2024-46869", "url": "https://ubuntu.com/security/CVE-2024-46869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btintel_pcie: Allocate memory for driver private data Fix driver not allocating memory for struct btintel_data which is used to store internal data.", "cve_priority": "medium", "cve_public_date": "2024-09-30 16:15:00 UTC" }, { "cve": "CVE-2024-53164", "url": "https://ubuntu.com/security/CVE-2024-53164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: fix ordering of qlen adjustment Changes to sch->q.qlen around qdisc_tree_reduce_backlog() need to happen _before_ a call to said function because otherwise it may fail to notify parent qdiscs when the child is about to become empty.", "cve_priority": "medium", "cve_public_date": "2024-12-27 14:15:00 UTC" }, { "cve": "CVE-2024-53103", "url": "https://ubuntu.com/security/CVE-2024-53103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hv_sock: Initializing vsk->trans to NULL to prevent a dangling pointer When hvs is released, there is a possibility that vsk->trans may not be initialized to NULL, which could lead to a dangling pointer. This issue is resolved by initializing vsk->trans to NULL.", "cve_priority": "high", "cve_public_date": "2024-12-02 08:15:00 UTC" } ], "launchpad_bugs_fixed": [ 2093643, 1786013, 2091744, 2091184, 2093146, 2085406, 2089684, 2090932, 2085485, 2089357, 2089306, 2091655, 2091655, 2091655, 2091655, 2091655, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091386, 2091990, 2089327, 2089113, 2086587, 2086606, 2085950, 2085944, 2087853, 2087983, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089020, 2089020, 2089020 ], "changes": [ { "cves": [ { "cve": "CVE-2025-0927", "url": "https://ubuntu.com/security/CVE-2025-0927", "cve_description": "[fs: hfs/hfsplus: add key_len boundary check to hfs_bnode_read_key]", "cve_priority": "medium", "cve_public_date": "2025-02-13" } ], "log": [ "", " * CVE-2025-0927", " - SAUCE: fs: hfs/hfsplus: add key_len boundary check to hfs_bnode_read_key", "" ], "package": "linux", "version": "6.11.0-18.18", "urgency": "medium", "distributions": "oracular", "launchpad_bugs_fixed": [], "author": "Manuel Diewald ", "date": "Fri, 07 Feb 2025 18:44:32 +0100" }, { "cves": [ { "cve": "CVE-2024-53141", "url": "https://ubuntu.com/security/CVE-2024-53141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: add missing range check in bitmap_ip_uadt When tb[IPSET_ATTR_IP_TO] is not present but tb[IPSET_ATTR_CIDR] exists, the values of ip and ip_to are slightly swapped. Therefore, the range check for ip should be done later, but this part is missing and it seems that the vulnerability occurs. So we should add missing range checks and remove unnecessary range checks.", "cve_priority": "medium", "cve_public_date": "2024-12-06 10:15:00 UTC" }, { "cve": "CVE-2024-50010", "url": "https://ubuntu.com/security/CVE-2024-50010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exec: don't WARN for racy path_noexec check Both i_mode and noexec checks wrapped in WARN_ON stem from an artifact of the previous implementation. They used to legitimately check for the condition, but that got moved up in two commits: 633fb6ac3980 (\"exec: move S_ISREG() check earlier\") 0fd338b2d2cd (\"exec: move path_noexec() check earlier\") Instead of being removed said checks are WARN_ON'ed instead, which has some debug value. However, the spurious path_noexec check is racy, resulting in unwarranted warnings should someone race with setting the noexec flag. One can note there is more to perm-checking whether execve is allowed and none of the conditions are guaranteed to still hold after they were tested for. Additionally this does not validate whether the code path did any perm checking to begin with -- it will pass if the inode happens to be regular. Keep the redundant path_noexec() check even though it's mindless nonsense checking for guarantee that isn't given so drop the WARN. Reword the commentary and do small tidy ups while here. [brauner: keep redundant path_noexec() check]", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-53143", "url": "https://ubuntu.com/security/CVE-2024-53143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fsnotify: Fix ordering of iput() and watched_objects decrement Ensure the superblock is kept alive until we're done with iput(). Holding a reference to an inode is not allowed unless we ensure the superblock stays alive, which fsnotify does by keeping the watched_objects count elevated, so iput() must happen before the watched_objects decrement. This can lead to a UAF of something like sb->s_fs_info in tmpfs, but the UAF is hard to hit because race orderings that oops are more likely, thanks to the CHECK_DATA_CORRUPTION() block in generic_shutdown_super(). Also, ensure that fsnotify_put_sb_watched_objects() doesn't call fsnotify_sb_watched_objects() on a superblock that may have already been freed, which would cause a UAF read of sb->s_fsnotify_info.", "cve_priority": "medium", "cve_public_date": "2024-12-07 07:15:00 UTC" }, { "cve": "CVE-2024-53142", "url": "https://ubuntu.com/security/CVE-2024-53142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: initramfs: avoid filename buffer overrun The initramfs filename field is defined in Documentation/driver-api/early-userspace/buffer-format.rst as: 37 cpio_file := ALGN(4) + cpio_header + filename + \"\\0\" + ALGN(4) + data ... 55 ============= ================== ========================= 56 Field name Field size Meaning 57 ============= ================== ========================= ... 70 c_namesize 8 bytes Length of filename, including final \\0 When extracting an initramfs cpio archive, the kernel's do_name() path handler assumes a zero-terminated path at @collected, passing it directly to filp_open() / init_mkdir() / init_mknod(). If a specially crafted cpio entry carries a non-zero-terminated filename and is followed by uninitialized memory, then a file may be created with trailing characters that represent the uninitialized memory. The ability to create an initramfs entry would imply already having full control of the system, so the buffer overrun shouldn't be considered a security vulnerability. Append the output of the following bash script to an existing initramfs and observe any created /initramfs_test_fname_overrunAA* path. E.g. ./reproducer.sh | gzip >> /myinitramfs It's easiest to observe non-zero uninitialized memory when the output is gzipped, as it'll overflow the heap allocated @out_buf in __gunzip(), rather than the initrd_start+initrd_size block. ---- reproducer.sh ---- nilchar=\"A\"\t# change to \"\\0\" to properly zero terminate / pad magic=\"070701\" ino=1 mode=$(( 0100777 )) uid=0 gid=0 nlink=1 mtime=1 filesize=0 devmajor=0 devminor=1 rdevmajor=0 rdevminor=0 csum=0 fname=\"initramfs_test_fname_overrun\" namelen=$(( ${#fname} + 1 ))\t# plus one to account for terminator printf \"%s%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%s\" \\ \t$magic $ino $mode $uid $gid $nlink $mtime $filesize \\ \t$devmajor $devminor $rdevmajor $rdevminor $namelen $csum $fname termpadlen=$(( 1 + ((4 - ((110 + $namelen) & 3)) % 4) )) printf \"%.s${nilchar}\" $(seq 1 $termpadlen) ---- reproducer.sh ---- Symlink filename fields handled in do_symlink() won't overrun past the data segment, due to the explicit zero-termination of the symlink target. Fix filename buffer overrun by aborting the initramfs FSM if any cpio entry doesn't carry a zero-terminator at the expected (name_len - 1) offset.", "cve_priority": "medium", "cve_public_date": "2024-12-06 10:15:00 UTC" }, { "cve": "CVE-2024-53133", "url": "https://ubuntu.com/security/CVE-2024-53133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Handle dml allocation failure to avoid crash [Why] In the case where a dml allocation fails for any reason, the current state's dml contexts would no longer be valid. Then subsequent calls dc_state_copy_internal would shallow copy invalid memory and if the new state was released, a double free would occur. [How] Reset dml pointers in new_state to NULL and avoid invalid pointer (cherry picked from commit bcafdc61529a48f6f06355d78eb41b3aeda5296c)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53108", "url": "https://ubuntu.com/security/CVE-2024-53108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Adjust VSDB parser for replay feature At some point, the IEEE ID identification for the replay check in the AMD EDID was added. However, this check causes the following out-of-bounds issues when using KASAN: [ 27.804016] BUG: KASAN: slab-out-of-bounds in amdgpu_dm_update_freesync_caps+0xefa/0x17a0 [amdgpu] [ 27.804788] Read of size 1 at addr ffff8881647fdb00 by task systemd-udevd/383 ... [ 27.821207] Memory state around the buggy address: [ 27.821215] ffff8881647fda00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821224] ffff8881647fda80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821234] >ffff8881647fdb00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821243] ^ [ 27.821250] ffff8881647fdb80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821259] ffff8881647fdc00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821268] ================================================================== This is caused because the ID extraction happens outside of the range of the edid lenght. This commit addresses this issue by considering the amd_vsdb_block size. (cherry picked from commit b7e381b1ccd5e778e3d9c44c669ad38439a861d8)", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53134", "url": "https://ubuntu.com/security/CVE-2024-53134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pmdomain: imx93-blk-ctrl: correct remove path The check condition should be 'i < bc->onecell_data.num_domains', not 'bc->onecell_data.num_domains' which will make the look never finish and cause kernel panic. Also disable runtime to address \"imx93-blk-ctrl 4ac10000.system-controller: Unbalanced pm_runtime_enable!\"", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53132", "url": "https://ubuntu.com/security/CVE-2024-53132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/oa: Fix \"Missing outer runtime PM protection\" warning Fix the following drm_WARN: [953.586396] xe 0000:00:02.0: [drm] Missing outer runtime PM protection ... <4> [953.587090] ? xe_pm_runtime_get_noresume+0x8d/0xa0 [xe] <4> [953.587208] guc_exec_queue_add_msg+0x28/0x130 [xe] <4> [953.587319] guc_exec_queue_fini+0x3a/0x40 [xe] <4> [953.587425] xe_exec_queue_destroy+0xb3/0xf0 [xe] <4> [953.587515] xe_oa_release+0x9c/0xc0 [xe] (cherry picked from commit b107c63d2953907908fd0cafb0e543b3c3167b75)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53127", "url": "https://ubuntu.com/security/CVE-2024-53127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Revert \"mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K\" The commit 8396c793ffdf (\"mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K\") increased the max_req_size, even for 4K pages, causing various issues: - Panic booting the kernel/rootfs from an SD card on Rockchip RK3566 - Panic booting the kernel/rootfs from an SD card on StarFive JH7100 - \"swiotlb buffer is full\" and data corruption on StarFive JH7110 At this stage no fix have been found, so it's probably better to just revert the change. This reverts commit 8396c793ffdf28bb8aee7cfe0891080f8cab7890.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53130", "url": "https://ubuntu.com/security/CVE-2024-53130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint When using the \"block:block_dirty_buffer\" tracepoint, mark_buffer_dirty() may cause a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because, since the tracepoint was added in mark_buffer_dirty(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, nilfs_grab_buffer(), which grabs a buffer to read (or create) a block of metadata, including b-tree node blocks, does not set the block device, but instead does so only if the buffer is not in the \"uptodate\" state for each of its caller block reading functions. However, if the uptodate flag is set on a folio/page, and the buffer heads are detached from it by try_to_free_buffers(), and new buffer heads are then attached by create_empty_buffers(), the uptodate flag may be restored to each buffer without the block device being set to bh->b_bdev, and mark_buffer_dirty() may be called later in that state, resulting in the bug mentioned above. Fix this issue by making nilfs_grab_buffer() always set the block device of the super block structure to the buffer head, regardless of the state of the buffer's uptodate flag.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53105", "url": "https://ubuntu.com/security/CVE-2024-53105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: page_alloc: move mlocked flag clearance into free_pages_prepare() Syzbot reported a bad page state problem caused by a page being freed using free_page() still having a mlocked flag at free_pages_prepare() stage: BUG: Bad page state in process syz.5.504 pfn:61f45 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x61f45 flags: 0xfff00000080204(referenced|workingset|mlocked|node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000080204 0000000000000000 dead000000000122 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set page_owner tracks the page as allocated page last allocated via order 0, migratetype Unmovable, gfp_mask 0x400dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO), pid 8443, tgid 8442 (syz.5.504), ts 201884660643, free_ts 201499827394 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1537 prep_new_page mm/page_alloc.c:1545 [inline] get_page_from_freelist+0x303f/0x3190 mm/page_alloc.c:3457 __alloc_pages_noprof+0x292/0x710 mm/page_alloc.c:4733 alloc_pages_mpol_noprof+0x3e8/0x680 mm/mempolicy.c:2265 kvm_coalesced_mmio_init+0x1f/0xf0 virt/kvm/coalesced_mmio.c:99 kvm_create_vm virt/kvm/kvm_main.c:1235 [inline] kvm_dev_ioctl_create_vm virt/kvm/kvm_main.c:5488 [inline] kvm_dev_ioctl+0x12dc/0x2240 virt/kvm/kvm_main.c:5530 __do_compat_sys_ioctl fs/ioctl.c:1007 [inline] __se_compat_sys_ioctl+0x510/0xc90 fs/ioctl.c:950 do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline] __do_fast_syscall_32+0xb4/0x110 arch/x86/entry/common.c:386 do_fast_syscall_32+0x34/0x80 arch/x86/entry/common.c:411 entry_SYSENTER_compat_after_hwframe+0x84/0x8e page last free pid 8399 tgid 8399 stack trace: reset_page_owner include/linux/page_owner.h:25 [inline] free_pages_prepare mm/page_alloc.c:1108 [inline] free_unref_folios+0xf12/0x18d0 mm/page_alloc.c:2686 folios_put_refs+0x76c/0x860 mm/swap.c:1007 free_pages_and_swap_cache+0x5c8/0x690 mm/swap_state.c:335 __tlb_batch_free_encoded_pages mm/mmu_gather.c:136 [inline] tlb_batch_pages_flush mm/mmu_gather.c:149 [inline] tlb_flush_mmu_free mm/mmu_gather.c:366 [inline] tlb_flush_mmu+0x3a3/0x680 mm/mmu_gather.c:373 tlb_finish_mmu+0xd4/0x200 mm/mmu_gather.c:465 exit_mmap+0x496/0xc40 mm/mmap.c:1926 __mmput+0x115/0x390 kernel/fork.c:1348 exit_mm+0x220/0x310 kernel/exit.c:571 do_exit+0x9b2/0x28e0 kernel/exit.c:926 do_group_exit+0x207/0x2c0 kernel/exit.c:1088 __do_sys_exit_group kernel/exit.c:1099 [inline] __se_sys_exit_group kernel/exit.c:1097 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1097 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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 Modules linked in: CPU: 0 UID: 0 PID: 8442 Comm: syz.5.504 Not tainted 6.12.0-rc6-syzkaller #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 bad_page+0x176/0x1d0 mm/page_alloc.c:501 free_page_is_bad mm/page_alloc.c:918 [inline] free_pages_prepare mm/page_alloc.c:1100 [inline] free_unref_page+0xed0/0xf20 mm/page_alloc.c:2638 kvm_destroy_vm virt/kvm/kvm_main.c:1327 [inline] kvm_put_kvm+0xc75/0x1350 virt/kvm/kvm_main.c:1386 kvm_vcpu_release+0x54/0x60 virt/kvm/kvm_main.c:4143 __fput+0x23f/0x880 fs/file_table.c:431 task_work_run+0x24f/0x310 kernel/task_work.c:239 exit_task_work include/linux/task_work.h:43 [inline] do_exit+0xa2f/0x28e0 kernel/exit.c:939 do_group_exit+0x207/0x2c0 kernel/exit.c:1088 __do_sys_exit_group kernel/exit.c:1099 [in ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53109", "url": "https://ubuntu.com/security/CVE-2024-53109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nommu: pass NULL argument to vma_iter_prealloc() When deleting a vma entry from a maple tree, it has to pass NULL to vma_iter_prealloc() in order to calculate internal state of the tree, but it passed a wrong argument. As a result, nommu kernels crashed upon accessing a vma iterator, such as acct_collect() reading the size of vma entries after do_munmap(). This commit fixes this issue by passing a right argument to the preallocation call.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53131", "url": "https://ubuntu.com/security/CVE-2024-53131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint Patch series \"nilfs2: fix null-ptr-deref bugs on block tracepoints\". This series fixes null pointer dereference bugs that occur when using nilfs2 and two block-related tracepoints. This patch (of 2): It has been reported that when using \"block:block_touch_buffer\" tracepoint, touch_buffer() called from __nilfs_get_folio_block() causes a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because since the tracepoint was added in touch_buffer(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, the block_device structure is set after the function returns to the caller. Here, touch_buffer() is used to mark the folio/page that owns the buffer head as accessed, but the common search helper for folio/page used by the caller function was optimized to mark the folio/page as accessed when it was reimplemented a long time ago, eliminating the need to call touch_buffer() here in the first place. So this solves the issue by eliminating the touch_buffer() call itself.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53135", "url": "https://ubuntu.com/security/CVE-2024-53135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: VMX: Bury Intel PT virtualization (guest/host mode) behind CONFIG_BROKEN Hide KVM's pt_mode module param behind CONFIG_BROKEN, i.e. disable support for virtualizing Intel PT via guest/host mode unless BROKEN=y. There are myriad bugs in the implementation, some of which are fatal to the guest, and others which put the stability and health of the host at risk. For guest fatalities, the most glaring issue is that KVM fails to ensure tracing is disabled, and *stays* disabled prior to VM-Enter, which is necessary as hardware disallows loading (the guest's) RTIT_CTL if tracing is enabled (enforced via a VMX consistency check). Per the SDM: If the logical processor is operating with Intel PT enabled (if IA32_RTIT_CTL.TraceEn = 1) at the time of VM entry, the \"load IA32_RTIT_CTL\" VM-entry control must be 0. On the host side, KVM doesn't validate the guest CPUID configuration provided by userspace, and even worse, uses the guest configuration to decide what MSRs to save/load at VM-Enter and VM-Exit. E.g. configuring guest CPUID to enumerate more address ranges than are supported in hardware will result in KVM trying to passthrough, save, and load non-existent MSRs, which generates a variety of WARNs, ToPA ERRORs in the host, a potential deadlock, etc.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53106", "url": "https://ubuntu.com/security/CVE-2024-53106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: fix buffer overrun in ima_eventdigest_init_common Function ima_eventdigest_init() calls ima_eventdigest_init_common() with HASH_ALGO__LAST which is then used to access the array hash_digest_size[] leading to buffer overrun. Have a conditional statement to handle this.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53110", "url": "https://ubuntu.com/security/CVE-2024-53110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vp_vdpa: fix id_table array not null terminated error Allocate one extra virtio_device_id as null terminator, otherwise vdpa_mgmtdev_get_classes() may iterate multiple times and visit undefined memory.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53126", "url": "https://ubuntu.com/security/CVE-2024-53126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa: solidrun: Fix UB bug with devres In psnet_open_pf_bar() and snet_open_vf_bar() a string later passed to pcim_iomap_regions() is placed on the stack. Neither pcim_iomap_regions() nor the functions it calls copy that string. Should the string later ever be used, this, consequently, causes undefined behavior since the stack frame will by then have disappeared. Fix the bug by allocating the strings on the heap through devm_kasprintf().", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53111", "url": "https://ubuntu.com/security/CVE-2024-53111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mremap: fix address wraparound in move_page_tables() On 32-bit platforms, it is possible for the expression `len + old_addr < old_end` to be false-positive if `len + old_addr` wraps around. `old_addr` is the cursor in the old range up to which page table entries have been moved; so if the operation succeeded, `old_addr` is the *end* of the old region, and adding `len` to it can wrap. The overflow causes mremap() to mistakenly believe that PTEs have been copied; the consequence is that mremap() bails out, but doesn't move the PTEs back before the new VMA is unmapped, causing anonymous pages in the region to be lost. So basically if userspace tries to mremap() a private-anon region and hits this bug, mremap() will return an error and the private-anon region's contents appear to have been zeroed. The idea of this check is that `old_end - len` is the original start address, and writing the check that way also makes it easier to read; so fix the check by rearranging the comparison accordingly. (An alternate fix would be to refactor this function by introducing an \"orig_old_start\" variable or such.) Tested in a VM with a 32-bit X86 kernel; without the patch: ``` user@horn:~/big_mremap$ cat test.c #define _GNU_SOURCE #include #include #include #include #define ADDR1 ((void*)0x60000000) #define ADDR2 ((void*)0x10000000) #define SIZE 0x50000000uL int main(void) { unsigned char *p1 = mmap(ADDR1, SIZE, PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0); if (p1 == MAP_FAILED) err(1, \"mmap 1\"); unsigned char *p2 = mmap(ADDR2, SIZE, PROT_NONE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0); if (p2 == MAP_FAILED) err(1, \"mmap 2\"); *p1 = 0x41; printf(\"first char is 0x%02hhx\\n\", *p1); unsigned char *p3 = mremap(p1, SIZE, SIZE, MREMAP_MAYMOVE|MREMAP_FIXED, p2); if (p3 == MAP_FAILED) { printf(\"mremap() failed; first char is 0x%02hhx\\n\", *p1); } else { printf(\"mremap() succeeded; first char is 0x%02hhx\\n\", *p3); } } user@horn:~/big_mremap$ gcc -static -o test test.c user@horn:~/big_mremap$ setarch -R ./test first char is 0x41 mremap() failed; first char is 0x00 ``` With the patch: ``` user@horn:~/big_mremap$ setarch -R ./test first char is 0x41 mremap() succeeded; first char is 0x41 ```", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53107", "url": "https://ubuntu.com/security/CVE-2024-53107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: prevent integer overflow in pagemap_scan_get_args() The \"arg->vec_len\" variable is a u64 that comes from the user at the start of the function. The \"arg->vec_len * sizeof(struct page_region))\" multiplication can lead to integer wrapping. Use size_mul() to avoid that. Also the size_add/mul() functions work on unsigned long so for 32bit systems we need to ensure that \"arg->vec_len\" fits in an unsigned long.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53128", "url": "https://ubuntu.com/security/CVE-2024-53128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/task_stack: fix object_is_on_stack() for KASAN tagged pointers When CONFIG_KASAN_SW_TAGS and CONFIG_KASAN_STACK are enabled, the object_is_on_stack() function may produce incorrect results due to the presence of tags in the obj pointer, while the stack pointer does not have tags. This discrepancy can lead to incorrect stack object detection and subsequently trigger warnings if CONFIG_DEBUG_OBJECTS is also enabled. Example of the warning: ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at lib/debugobjects.c:557 __debug_object_init+0x330/0x364 Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5 #4 Hardware name: linux,dummy-virt (DT) pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __debug_object_init+0x330/0x364 lr : __debug_object_init+0x330/0x364 sp : ffff800082ea7b40 x29: ffff800082ea7b40 x28: 98ff0000c0164518 x27: 98ff0000c0164534 x26: ffff800082d93ec8 x25: 0000000000000001 x24: 1cff0000c00172a0 x23: 0000000000000000 x22: ffff800082d93ed0 x21: ffff800081a24418 x20: 3eff800082ea7bb0 x19: efff800000000000 x18: 0000000000000000 x17: 00000000000000ff x16: 0000000000000047 x15: 206b63617473206e x14: 0000000000000018 x13: ffff800082ea7780 x12: 0ffff800082ea78e x11: 0ffff800082ea790 x10: 0ffff800082ea79d x9 : 34d77febe173e800 x8 : 34d77febe173e800 x7 : 0000000000000001 x6 : 0000000000000001 x5 : feff800082ea74b8 x4 : ffff800082870a90 x3 : ffff80008018d3c4 x2 : 0000000000000001 x1 : ffff800082858810 x0 : 0000000000000050 Call trace: __debug_object_init+0x330/0x364 debug_object_init_on_stack+0x30/0x3c schedule_hrtimeout_range_clock+0xac/0x26c schedule_hrtimeout+0x1c/0x30 wait_task_inactive+0x1d4/0x25c kthread_bind_mask+0x28/0x98 init_rescuer+0x1e8/0x280 workqueue_init+0x1a0/0x3cc kernel_init_freeable+0x118/0x200 kernel_init+0x28/0x1f0 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53112", "url": "https://ubuntu.com/security/CVE-2024-53112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: uncache inode which has failed entering the group Syzbot has reported the following BUG: kernel BUG at fs/ocfs2/uptodate.c:509! ... Call Trace: ? __die_body+0x5f/0xb0 ? die+0x9e/0xc0 ? do_trap+0x15a/0x3a0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? do_error_trap+0x1dc/0x2c0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? __pfx_do_error_trap+0x10/0x10 ? handle_invalid_op+0x34/0x40 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? exc_invalid_op+0x38/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? ocfs2_set_new_buffer_uptodate+0x2e/0x160 ? ocfs2_set_new_buffer_uptodate+0x144/0x160 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ocfs2_group_add+0x39f/0x15a0 ? __pfx_ocfs2_group_add+0x10/0x10 ? __pfx_lock_acquire+0x10/0x10 ? mnt_get_write_access+0x68/0x2b0 ? __pfx_lock_release+0x10/0x10 ? rcu_read_lock_any_held+0xb7/0x160 ? __pfx_rcu_read_lock_any_held+0x10/0x10 ? smack_log+0x123/0x540 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x226/0x2b0 ocfs2_ioctl+0x65e/0x7d0 ? __pfx_ocfs2_ioctl+0x10/0x10 ? smack_file_ioctl+0x29e/0x3a0 ? __pfx_smack_file_ioctl+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x43d/0x780 ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10 ? __pfx_ocfs2_ioctl+0x10/0x10 __se_sys_ioctl+0xfb/0x170 do_syscall_64+0xf3/0x230 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... When 'ioctl(OCFS2_IOC_GROUP_ADD, ...)' has failed for the particular inode in 'ocfs2_verify_group_and_input()', corresponding buffer head remains cached and subsequent call to the same 'ioctl()' for the same inode issues the BUG() in 'ocfs2_set_new_buffer_uptodate()' (trying to cache the same buffer head of that inode). Fix this by uncaching the buffer head with 'ocfs2_remove_from_cache()' on error path in 'ocfs2_group_add()'.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53113", "url": "https://ubuntu.com/security/CVE-2024-53113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: fix NULL pointer dereference in alloc_pages_bulk_noprof We triggered a NULL pointer dereference for ac.preferred_zoneref->zone in alloc_pages_bulk_noprof() when the task is migrated between cpusets. When cpuset is enabled, in prepare_alloc_pages(), ac->nodemask may be ¤t->mems_allowed. when first_zones_zonelist() is called to find preferred_zoneref, the ac->nodemask may be modified concurrently if the task is migrated between different cpusets. Assuming we have 2 NUMA Node, when traversing Node1 in ac->zonelist, the nodemask is 2, and when traversing Node2 in ac->zonelist, the nodemask is 1. As a result, the ac->preferred_zoneref points to NULL zone. In alloc_pages_bulk_noprof(), for_each_zone_zonelist_nodemask() finds a allowable zone and calls zonelist_node_idx(ac.preferred_zoneref), leading to NULL pointer dereference. __alloc_pages_noprof() fixes this issue by checking NULL pointer in commit ea57485af8f4 (\"mm, page_alloc: fix check for NULL preferred_zone\") and commit df76cee6bbeb (\"mm, page_alloc: remove redundant checks from alloc fastpath\"). To fix it, check NULL pointer for preferred_zoneref->zone.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53114", "url": "https://ubuntu.com/security/CVE-2024-53114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 client A number of Zen4 client SoCs advertise the ability to use virtualized VMLOAD/VMSAVE, but using these instructions is reported to be a cause of a random host reboot. These instructions aren't intended to be advertised on Zen4 client so clear the capability.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53137", "url": "https://ubuntu.com/security/CVE-2024-53137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: fix cacheflush with PAN It seems that the cacheflush syscall got broken when PAN for LPAE was implemented. User access was not enabled around the cache maintenance instructions, causing them to fault.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53115", "url": "https://ubuntu.com/security/CVE-2024-53115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: avoid null_ptr_deref in vmw_framebuffer_surface_create_handle The 'vmw_user_object_buffer' function may return NULL with incorrect inputs. To avoid possible null pointer dereference, add a check whether the 'bo' is NULL in the vmw_framebuffer_surface_create_handle.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53116", "url": "https://ubuntu.com/security/CVE-2024-53116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix handling of partial GPU mapping of BOs This commit fixes the bug in the handling of partial mapping of the buffer objects to the GPU, which caused kernel warnings. Panthor didn't correctly handle the case where the partial mapping spanned multiple scatterlists and the mapping offset didn't point to the 1st page of starting scatterlist. The offset variable was not cleared after reaching the starting scatterlist. Following warning messages were seen. WARNING: CPU: 1 PID: 650 at drivers/iommu/io-pgtable-arm.c:659 __arm_lpae_unmap+0x254/0x5a0 pc : __arm_lpae_unmap+0x254/0x5a0 lr : __arm_lpae_unmap+0x2cc/0x5a0 Call trace: __arm_lpae_unmap+0x254/0x5a0 __arm_lpae_unmap+0x108/0x5a0 __arm_lpae_unmap+0x108/0x5a0 __arm_lpae_unmap+0x108/0x5a0 arm_lpae_unmap_pages+0x80/0xa0 panthor_vm_unmap_pages+0xac/0x1c8 [panthor] panthor_gpuva_sm_step_unmap+0x4c/0xc8 [panthor] op_unmap_cb.isra.23.constprop.30+0x54/0x80 __drm_gpuvm_sm_unmap+0x184/0x1c8 drm_gpuvm_sm_unmap+0x40/0x60 panthor_vm_exec_op+0xa8/0x120 [panthor] panthor_vm_bind_exec_sync_op+0xc4/0xe8 [panthor] panthor_ioctl_vm_bind+0x10c/0x170 [panthor] drm_ioctl_kernel+0xbc/0x138 drm_ioctl+0x210/0x4b0 __arm64_sys_ioctl+0xb0/0xf8 invoke_syscall+0x4c/0x110 el0_svc_common.constprop.1+0x98/0xf8 do_el0_svc+0x24/0x38 el0_svc+0x34/0xc8 el0t_64_sync_handler+0xa0/0xc8 el0t_64_sync+0x174/0x178 panthor : [drm] drm_WARN_ON(unmapped_sz != pgsize * pgcount) WARNING: CPU: 1 PID: 650 at drivers/gpu/drm/panthor/panthor_mmu.c:922 panthor_vm_unmap_pages+0x124/0x1c8 [panthor] pc : panthor_vm_unmap_pages+0x124/0x1c8 [panthor] lr : panthor_vm_unmap_pages+0x124/0x1c8 [panthor] panthor : [drm] *ERROR* failed to unmap range ffffa388f000-ffffa3890000 (requested range ffffa388c000-ffffa3890000)", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53117", "url": "https://ubuntu.com/security/CVE-2024-53117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio/vsock: Improve MSG_ZEROCOPY error handling Add a missing kfree_skb() to prevent memory leaks.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53118", "url": "https://ubuntu.com/security/CVE-2024-53118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Fix sk_error_queue memory leak Kernel queues MSG_ZEROCOPY completion notifications on the error queue. Where they remain, until explicitly recv()ed. To prevent memory leaks, clean up the queue when the socket is destroyed. unreferenced object 0xffff8881028beb00 (size 224): comm \"vsock_test\", pid 1218, jiffies 4294694897 hex dump (first 32 bytes): 90 b0 21 17 81 88 ff ff 90 b0 21 17 81 88 ff ff ..!.......!..... 00 00 00 00 00 00 00 00 00 b0 21 17 81 88 ff ff ..........!..... backtrace (crc 6c7031ca): [] kmem_cache_alloc_node_noprof+0x2f7/0x370 [] __alloc_skb+0x132/0x180 [] sock_omalloc+0x4b/0x80 [] msg_zerocopy_realloc+0x9e/0x240 [] virtio_transport_send_pkt_info+0x412/0x4c0 [] virtio_transport_stream_enqueue+0x43/0x50 [] vsock_connectible_sendmsg+0x373/0x450 [] ____sys_sendmsg+0x365/0x3a0 [] ___sys_sendmsg+0x84/0xd0 [] __sys_sendmsg+0x47/0x80 [] do_syscall_64+0x93/0x180 [] entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53119", "url": "https://ubuntu.com/security/CVE-2024-53119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio/vsock: Fix accept_queue memory leak As the final stages of socket destruction may be delayed, it is possible that virtio_transport_recv_listen() will be called after the accept_queue has been flushed, but before the SOCK_DONE flag has been set. As a result, sockets enqueued after the flush would remain unremoved, leading to a memory leak. vsock_release __vsock_release lock virtio_transport_release virtio_transport_close schedule_delayed_work(close_work) sk_shutdown = SHUTDOWN_MASK (!) flush accept_queue release virtio_transport_recv_pkt vsock_find_bound_socket lock if flag(SOCK_DONE) return virtio_transport_recv_listen child = vsock_create_connected (!) vsock_enqueue_accept(child) release close_work lock virtio_transport_do_close set_flag(SOCK_DONE) virtio_transport_remove_sock vsock_remove_sock vsock_remove_bound release Introduce a sk_shutdown check to disallow vsock_enqueue_accept() during socket destruction. unreferenced object 0xffff888109e3f800 (size 2040): comm \"kworker/5:2\", pid 371, jiffies 4294940105 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00 (..@............ backtrace (crc 9e5f4e84): [] kmem_cache_alloc_noprof+0x2c1/0x360 [] sk_prot_alloc+0x30/0x120 [] sk_alloc+0x2c/0x4b0 [] __vsock_create.constprop.0+0x2a/0x310 [] virtio_transport_recv_pkt+0x4dc/0x9a0 [] vsock_loopback_work+0xfd/0x140 [] process_one_work+0x20c/0x570 [] worker_thread+0x1bf/0x3a0 [] kthread+0xdd/0x110 [] ret_from_fork+0x2d/0x50 [] ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53120", "url": "https://ubuntu.com/security/CVE-2024-53120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: CT: Fix null-ptr-deref in add rule err flow In error flow of mlx5_tc_ct_entry_add_rule(), in case ct_rule_add() callback returns error, zone_rule->attr is used uninitiated. Fix it to use attr which has the needed pointer value. Kernel log: BUG: kernel NULL pointer dereference, address: 0000000000000110 RIP: 0010:mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core] … Call Trace: ? __die+0x20/0x70 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x140 ? asm_exc_page_fault+0x22/0x30 ? mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core] ? mlx5_tc_ct_entry_add_rule+0x1d5/0x2f0 [mlx5_core] mlx5_tc_ct_block_flow_offload+0xc6a/0xf90 [mlx5_core] ? nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] flow_offload_work_handler+0x142/0x320 [nf_flow_table] ? finish_task_switch.isra.0+0x15b/0x2b0 process_one_work+0x16c/0x320 worker_thread+0x28c/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xb8/0xf0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53138", "url": "https://ubuntu.com/security/CVE-2024-53138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: kTLS, Fix incorrect page refcounting The kTLS tx handling code is using a mix of get_page() and page_ref_inc() APIs to increment the page reference. But on the release path (mlx5e_ktls_tx_handle_resync_dump_comp()), only put_page() is used. This is an issue when using pages from large folios: the get_page() references are stored on the folio page while the page_ref_inc() references are stored directly in the given page. On release the folio page will be dereferenced too many times. This was found while doing kTLS testing with sendfile() + ZC when the served file was read from NFS on a kernel with NFS large folios support (commit 49b29a573da8 (\"nfs: add support for large folios\")).", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53121", "url": "https://ubuntu.com/security/CVE-2024-53121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: fs, lock FTE when checking if active The referenced commits introduced a two-step process for deleting FTEs: - Lock the FTE, delete it from hardware, set the hardware deletion function to NULL and unlock the FTE. - Lock the parent flow group, delete the software copy of the FTE, and remove it from the xarray. However, this approach encounters a race condition if a rule with the same match value is added simultaneously. In this scenario, fs_core may set the hardware deletion function to NULL prematurely, causing a panic during subsequent rule deletions. To prevent this, ensure the active flag of the FTE is checked under a lock, which will prevent the fs_core layer from attaching a new steering rule to an FTE that is in the process of deletion. [ 438.967589] MOSHE: 2496 mlx5_del_flow_rules del_hw_func [ 438.968205] ------------[ cut here ]------------ [ 438.968654] refcount_t: decrement hit 0; leaking memory. [ 438.969249] WARNING: CPU: 0 PID: 8957 at lib/refcount.c:31 refcount_warn_saturate+0xfb/0x110 [ 438.970054] Modules linked in: act_mirred cls_flower act_gact sch_ingress openvswitch nsh mlx5_vdpa vringh vhost_iotlb vdpa mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core zram zsmalloc fuse [last unloaded: cls_flower] [ 438.973288] CPU: 0 UID: 0 PID: 8957 Comm: tc Not tainted 6.12.0-rc1+ #8 [ 438.973888] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 438.974874] RIP: 0010:refcount_warn_saturate+0xfb/0x110 [ 438.975363] Code: 40 66 3b 82 c6 05 16 e9 4d 01 01 e8 1f 7c a0 ff 0f 0b c3 cc cc cc cc 48 c7 c7 10 66 3b 82 c6 05 fd e8 4d 01 01 e8 05 7c a0 ff <0f> 0b c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 90 [ 438.976947] RSP: 0018:ffff888124a53610 EFLAGS: 00010286 [ 438.977446] RAX: 0000000000000000 RBX: ffff888119d56de0 RCX: 0000000000000000 [ 438.978090] RDX: ffff88852c828700 RSI: ffff88852c81b3c0 RDI: ffff88852c81b3c0 [ 438.978721] RBP: ffff888120fa0e88 R08: 0000000000000000 R09: ffff888124a534b0 [ 438.979353] R10: 0000000000000001 R11: 0000000000000001 R12: ffff888119d56de0 [ 438.979979] R13: ffff888120fa0ec0 R14: ffff888120fa0ee8 R15: ffff888119d56de0 [ 438.980607] FS: 00007fe6dcc0f800(0000) GS:ffff88852c800000(0000) knlGS:0000000000000000 [ 438.983984] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 438.984544] CR2: 00000000004275e0 CR3: 0000000186982001 CR4: 0000000000372eb0 [ 438.985205] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 438.985842] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 438.986507] Call Trace: [ 438.986799] [ 438.987070] ? __warn+0x7d/0x110 [ 438.987426] ? refcount_warn_saturate+0xfb/0x110 [ 438.987877] ? report_bug+0x17d/0x190 [ 438.988261] ? prb_read_valid+0x17/0x20 [ 438.988659] ? handle_bug+0x53/0x90 [ 438.989054] ? exc_invalid_op+0x14/0x70 [ 438.989458] ? asm_exc_invalid_op+0x16/0x20 [ 438.989883] ? refcount_warn_saturate+0xfb/0x110 [ 438.990348] mlx5_del_flow_rules+0x2f7/0x340 [mlx5_core] [ 438.990932] __mlx5_eswitch_del_rule+0x49/0x170 [mlx5_core] [ 438.991519] ? mlx5_lag_is_sriov+0x3c/0x50 [mlx5_core] [ 438.992054] ? xas_load+0x9/0xb0 [ 438.992407] mlx5e_tc_rule_unoffload+0x45/0xe0 [mlx5_core] [ 438.993037] mlx5e_tc_del_fdb_flow+0x2a6/0x2e0 [mlx5_core] [ 438.993623] mlx5e_flow_put+0x29/0x60 [mlx5_core] [ 438.994161] mlx5e_delete_flower+0x261/0x390 [mlx5_core] [ 438.994728] tc_setup_cb_destroy+0xb9/0x190 [ 438.995150] fl_hw_destroy_filter+0x94/0xc0 [cls_flower] [ 438.995650] fl_change+0x11a4/0x13c0 [cls_flower] [ 438.996105] tc_new_tfilter+0x347/0xbc0 [ 438.996503] ? __ ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53122", "url": "https://ubuntu.com/security/CVE-2024-53122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: cope racing subflow creation in mptcp_rcv_space_adjust Additional active subflows - i.e. created by the in kernel path manager - are included into the subflow list before starting the 3whs. A racing recvmsg() spooling data received on an already established subflow would unconditionally call tcp_cleanup_rbuf() on all the current subflows, potentially hitting a divide by zero error on the newly created ones. Explicitly check that the subflow is in a suitable state before invoking tcp_cleanup_rbuf().", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53123", "url": "https://ubuntu.com/security/CVE-2024-53123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: error out earlier on disconnect Eric reported a division by zero splat in the MPTCP protocol: Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 6094 Comm: syz-executor317 Not tainted 6.12.0-rc5-syzkaller-00291-g05b92660cdfe #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:__tcp_select_window+0x5b4/0x1310 net/ipv4/tcp_output.c:3163 Code: f6 44 01 e3 89 df e8 9b 75 09 f8 44 39 f3 0f 8d 11 ff ff ff e8 0d 74 09 f8 45 89 f4 e9 04 ff ff ff e8 00 74 09 f8 44 89 f0 99 7c 24 14 41 29 d6 45 89 f4 e9 ec fe ff ff e8 e8 73 09 f8 48 89 RSP: 0018:ffffc900041f7930 EFLAGS: 00010293 RAX: 0000000000017e67 RBX: 0000000000017e67 RCX: ffffffff8983314b RDX: 0000000000000000 RSI: ffffffff898331b0 RDI: 0000000000000004 RBP: 00000000005d6000 R08: 0000000000000004 R09: 0000000000017e67 R10: 0000000000003e80 R11: 0000000000000000 R12: 0000000000003e80 R13: ffff888031d9b440 R14: 0000000000017e67 R15: 00000000002eb000 FS: 00007feb5d7f16c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007feb5d8adbb8 CR3: 0000000074e4c000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __tcp_cleanup_rbuf+0x3e7/0x4b0 net/ipv4/tcp.c:1493 mptcp_rcv_space_adjust net/mptcp/protocol.c:2085 [inline] mptcp_recvmsg+0x2156/0x2600 net/mptcp/protocol.c:2289 inet_recvmsg+0x469/0x6a0 net/ipv4/af_inet.c:885 sock_recvmsg_nosec net/socket.c:1051 [inline] sock_recvmsg+0x1b2/0x250 net/socket.c:1073 __sys_recvfrom+0x1a5/0x2e0 net/socket.c:2265 __do_sys_recvfrom net/socket.c:2283 [inline] __se_sys_recvfrom net/socket.c:2279 [inline] __x64_sys_recvfrom+0xe0/0x1c0 net/socket.c:2279 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 RIP: 0033:0x7feb5d857559 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:00007feb5d7f1208 EFLAGS: 00000246 ORIG_RAX: 000000000000002d RAX: ffffffffffffffda RBX: 00007feb5d8e1318 RCX: 00007feb5d857559 RDX: 000000800000000e RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007feb5d8e1310 R08: 0000000000000000 R09: ffffffff81000000 R10: 0000000000000100 R11: 0000000000000246 R12: 00007feb5d8e131c R13: 00007feb5d8ae074 R14: 000000800000000e R15: 00000000fffffdef and provided a nice reproducer. The root cause is the current bad handling of racing disconnect. After the blamed commit below, sk_wait_data() can return (with error) with the underlying socket disconnected and a zero rcv_mss. Catch the error and return without performing any additional operations on the current socket.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53124", "url": "https://ubuntu.com/security/CVE-2024-53124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix data-races around sk->sk_forward_alloc Syzkaller reported this warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 16 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x1c5/0x1e0 Modules linked in: CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:inet_sock_destruct+0x1c5/0x1e0 Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 <0f> 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00 RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206 RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007 RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00 RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007 R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00 R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78 FS: 0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn+0x88/0x130 ? inet_sock_destruct+0x1c5/0x1e0 ? report_bug+0x18e/0x1a0 ? handle_bug+0x53/0x90 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? inet_sock_destruct+0x1c5/0x1e0 __sk_destruct+0x2a/0x200 rcu_do_batch+0x1aa/0x530 ? rcu_do_batch+0x13b/0x530 rcu_core+0x159/0x2f0 handle_softirqs+0xd3/0x2b0 ? __pfx_smpboot_thread_fn+0x10/0x10 run_ksoftirqd+0x25/0x30 smpboot_thread_fn+0xdd/0x1d0 kthread+0xd3/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ---[ end trace 0000000000000000 ]--- Its possible that two threads call tcp_v6_do_rcv()/sk_forward_alloc_add() concurrently when sk->sk_state == TCP_LISTEN with sk->sk_lock unlocked, which triggers a data-race around sk->sk_forward_alloc: tcp_v6_rcv tcp_v6_do_rcv skb_clone_and_charge_r sk_rmem_schedule __sk_mem_schedule sk_forward_alloc_add() skb_set_owner_r sk_mem_charge sk_forward_alloc_add() __kfree_skb skb_release_all skb_release_head_state sock_rfree sk_mem_uncharge sk_forward_alloc_add() sk_mem_reclaim // set local var reclaimable __sk_mem_reclaim sk_forward_alloc_add() In this syzkaller testcase, two threads call tcp_v6_do_rcv() with skb->truesize=768, the sk_forward_alloc changes like this: (cpu 1) | (cpu 2) | sk_forward_alloc ... | ... | 0 __sk_mem_schedule() | | +4096 = 4096 | __sk_mem_schedule() | +4096 = 8192 sk_mem_charge() | | -768 = 7424 | sk_mem_charge() | -768 = 6656 ... | ... | sk_mem_uncharge() | | +768 = 7424 reclaimable=7424 | | | sk_mem_uncharge() | +768 = 8192 | reclaimable=8192 | __sk_mem_reclaim() | | -4096 = 4096 | __sk_mem_reclaim() | -8192 = -4096 != 0 The skb_clone_and_charge_r() should not be called in tcp_v6_do_rcv() when sk->sk_state is TCP_LISTEN, it happens later in tcp_v6_syn_recv_sock(). Fix the same issue in dccp_v6_do_rcv().", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53129", "url": "https://ubuntu.com/security/CVE-2024-53129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: vop: Fix a dereferenced before check warning The 'state' can't be NULL, we should check crtc_state. Fix warning: drivers/gpu/drm/rockchip/rockchip_drm_vop.c:1096 vop_plane_atomic_async_check() warn: variable dereferenced before check 'state' (see line 1077)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53139", "url": "https://ubuntu.com/security/CVE-2024-53139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix possible UAF in sctp_v6_available() A lockdep report [1] with CONFIG_PROVE_RCU_LIST=y hints that sctp_v6_available() is calling dev_get_by_index_rcu() and ipv6_chk_addr() without holding rcu. [1] ============================= WARNING: suspicious RCU usage 6.12.0-rc5-virtme #1216 Tainted: G W ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by sctp_hello/31495: #0: ffff9f1ebbdb7418 (sk_lock-AF_INET6){+.+.}-{0:0}, at: sctp_bind (./arch/x86/include/asm/jump_label.h:27 net/sctp/socket.c:315) sctp stack backtrace: CPU: 7 UID: 0 PID: 31495 Comm: sctp_hello Tainted: G W 6.12.0-rc5-virtme #1216 Tainted: [W]=WARN 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:123) lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822) dev_get_by_index_rcu (net/core/dev.c:876 (discriminator 7)) sctp_v6_available (net/sctp/ipv6.c:701) sctp sctp_do_bind (net/sctp/socket.c:400 (discriminator 1)) sctp sctp_bind (net/sctp/socket.c:320) sctp inet6_bind_sk (net/ipv6/af_inet6.c:465) ? security_socket_bind (security/security.c:4581 (discriminator 1)) __sys_bind (net/socket.c:1848 net/socket.c:1869) ? do_user_addr_fault (./include/linux/rcupdate.h:347 ./include/linux/rcupdate.h:880 ./include/linux/mm.h:729 arch/x86/mm/fault.c:1340) ? do_user_addr_fault (./arch/x86/include/asm/preempt.h:84 (discriminator 13) ./include/linux/rcupdate.h:98 (discriminator 13) ./include/linux/rcupdate.h:882 (discriminator 13) ./include/linux/mm.h:729 (discriminator 13) arch/x86/mm/fault.c:1340 (discriminator 13)) __x64_sys_bind (net/socket.c:1877 (discriminator 1) net/socket.c:1875 (discriminator 1) net/socket.c:1875 (discriminator 1)) do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f59b934a1e7 Code: 44 00 00 48 8b 15 39 8c 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 b8 31 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 09 8c 0c 00 f7 d8 64 89 01 48 All code ======== 0:\t44 00 00 \tadd %r8b,(%rax) 3:\t48 8b 15 39 8c 0c 00 \tmov 0xc8c39(%rip),%rdx # 0xc8c43 a:\tf7 d8 \tneg %eax c:\t64 89 02 \tmov %eax,%fs:(%rdx) f:\tb8 ff ff ff ff \tmov $0xffffffff,%eax 14:\teb bd \tjmp 0xffffffffffffffd3 16:\t66 2e 0f 1f 84 00 00 \tcs nopw 0x0(%rax,%rax,1) 1d:\t00 00 00 20:\t0f 1f 00 \tnopl (%rax) 23:\tb8 31 00 00 00 \tmov $0x31,%eax 28:\t0f 05 \tsyscall 2a:*\t48 3d 01 f0 ff ff \tcmp $0xfffffffffffff001,%rax\t\t<-- trapping instruction 30:\t73 01 \tjae 0x33 32:\tc3 \tret 33:\t48 8b 0d 09 8c 0c 00 \tmov 0xc8c09(%rip),%rcx # 0xc8c43 3a:\tf7 d8 \tneg %eax 3c:\t64 89 01 \tmov %eax,%fs:(%rcx) 3f:\t48 \trex.W Code starting with the faulting instruction =========================================== 0:\t48 3d 01 f0 ff ff \tcmp $0xfffffffffffff001,%rax 6:\t73 01 \tjae 0x9 8:\tc3 \tret 9:\t48 8b 0d 09 8c 0c 00 \tmov 0xc8c09(%rip),%rcx # 0xc8c19 10:\tf7 d8 \tneg %eax 12:\t64 89 01 \tmov %eax,%fs:(%rcx) 15:\t48 \trex.W RSP: 002b:00007ffe2d0ad398 EFLAGS: 00000202 ORIG_RAX: 0000000000000031 RAX: ffffffffffffffda RBX: 00007ffe2d0ad3d0 RCX: 00007f59b934a1e7 RDX: 000000000000001c RSI: 00007ffe2d0ad3d0 RDI: 0000000000000005 RBP: 0000000000000005 R08: 1999999999999999 R09: 0000000000000000 R10: 00007f59b9253298 R11: 000000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53140", "url": "https://ubuntu.com/security/CVE-2024-53140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netlink: terminate outstanding dump on socket close Netlink supports iterative dumping of data. It provides the families the following ops: - start - (optional) kicks off the dumping process - dump - actual dump helper, keeps getting called until it returns 0 - done - (optional) pairs with .start, can be used for cleanup The whole process is asynchronous and the repeated calls to .dump don't actually happen in a tight loop, but rather are triggered in response to recvmsg() on the socket. This gives the user full control over the dump, but also means that the user can close the socket without getting to the end of the dump. To make sure .start is always paired with .done we check if there is an ongoing dump before freeing the socket, and if so call .done. The complication is that sockets can get freed from BH and .done is allowed to sleep. So we use a workqueue to defer the call, when needed. Unfortunately this does not work correctly. What we defer is not the cleanup but rather releasing a reference on the socket. We have no guarantee that we own the last reference, if someone else holds the socket they may release it in BH and we're back to square one. The whole dance, however, appears to be unnecessary. Only the user can interact with dumps, so we can clean up when socket is closed. And close always happens in process context. Some async code may still access the socket after close, queue notification skbs to it etc. but no dumps can start, end or otherwise make progress. Delete the workqueue and flush the dump state directly from the release handler. Note that further cleanup is possible in -next, for instance we now always call .done before releasing the main module reference, so dump doesn't have to take a reference of its own.", "cve_priority": "high", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53098", "url": "https://ubuntu.com/security/CVE-2024-53098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/ufence: Prefetch ufence addr to catch bogus address access_ok() only checks for addr overflow so also try to read the addr to catch invalid addr sent from userspace. (cherry picked from commit 9408c4508483ffc60811e910a93d6425b8e63928)", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53099", "url": "https://ubuntu.com/security/CVE-2024-53099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check validity of link->type in bpf_link_show_fdinfo() If a newly-added link type doesn't invoke BPF_LINK_TYPE(), accessing bpf_link_type_strs[link->type] may result in an out-of-bounds access. To spot such missed invocations early in the future, checking the validity of link->type in bpf_link_show_fdinfo() and emitting a warning when such invocations are missed.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53089", "url": "https://ubuntu.com/security/CVE-2024-53089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: KVM: Mark hrtimer to expire in hard interrupt context Like commit 2c0d278f3293f (\"KVM: LAPIC: Mark hrtimer to expire in hard interrupt context\") and commit 9090825fa9974 (\"KVM: arm/arm64: Let the timer expire in hardirq context on RT\"), On PREEMPT_RT enabled kernels unmarked hrtimers are moved into soft interrupt expiry mode by default. Then the timers are canceled from an preempt-notifier which is invoked with disabled preemption which is not allowed on PREEMPT_RT. The timer callback is short so in could be invoked in hard-IRQ context. So let the timer expire on hard-IRQ context even on -RT. This fix a \"scheduling while atomic\" bug for PREEMPT_RT enabled kernels: BUG: scheduling while atomic: qemu-system-loo/1011/0x00000002 Modules linked in: amdgpu rfkill nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat ns CPU: 1 UID: 0 PID: 1011 Comm: qemu-system-loo Tainted: G W 6.12.0-rc2+ #1774 Tainted: [W]=WARN Hardware name: Loongson Loongson-3A5000-7A1000-1w-CRB/Loongson-LS3A5000-7A1000-1w-CRB, BIOS vUDK2018-LoongArch-V2.0.0-prebeta9 10/21/2022 Stack : ffffffffffffffff 0000000000000000 9000000004e3ea38 9000000116744000 90000001167475a0 0000000000000000 90000001167475a8 9000000005644830 90000000058dc000 90000000058dbff8 9000000116747420 0000000000000001 0000000000000001 6a613fc938313980 000000000790c000 90000001001c1140 00000000000003fe 0000000000000001 000000000000000d 0000000000000003 0000000000000030 00000000000003f3 000000000790c000 9000000116747830 90000000057ef000 0000000000000000 9000000005644830 0000000000000004 0000000000000000 90000000057f4b58 0000000000000001 9000000116747868 900000000451b600 9000000005644830 9000000003a13998 0000000010000020 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d ... Call Trace: [<9000000003a13998>] show_stack+0x38/0x180 [<9000000004e3ea34>] dump_stack_lvl+0x84/0xc0 [<9000000003a71708>] __schedule_bug+0x48/0x60 [<9000000004e45734>] __schedule+0x1114/0x1660 [<9000000004e46040>] schedule_rtlock+0x20/0x60 [<9000000004e4e330>] rtlock_slowlock_locked+0x3f0/0x10a0 [<9000000004e4f038>] rt_spin_lock+0x58/0x80 [<9000000003b02d68>] hrtimer_cancel_wait_running+0x68/0xc0 [<9000000003b02e30>] hrtimer_cancel+0x70/0x80 [] kvm_restore_timer+0x50/0x1a0 [kvm] [] kvm_arch_vcpu_load+0x68/0x2a0 [kvm] [] kvm_sched_in+0x34/0x60 [kvm] [<9000000003a749a0>] finish_task_switch.isra.0+0x140/0x2e0 [<9000000004e44a70>] __schedule+0x450/0x1660 [<9000000004e45cb0>] schedule+0x30/0x180 [] kvm_vcpu_block+0x70/0x120 [kvm] [] kvm_vcpu_halt+0x60/0x3e0 [kvm] [] kvm_handle_gspr+0x3f4/0x4e0 [kvm] [] kvm_handle_exit+0x1c8/0x260 [kvm]", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53090", "url": "https://ubuntu.com/security/CVE-2024-53090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix lock recursion afs_wake_up_async_call() can incur lock recursion. The problem is that it is called from AF_RXRPC whilst holding the ->notify_lock, but it tries to take a ref on the afs_call struct in order to pass it to a work queue - but if the afs_call is already queued, we then have an extraneous ref that must be put... calling afs_put_call() may call back down into AF_RXRPC through rxrpc_kernel_shutdown_call(), however, which might try taking the ->notify_lock again. This case isn't very common, however, so defer it to a workqueue. The oops looks something like: BUG: spinlock recursion on CPU#0, krxrpcio/7001/1646 lock: 0xffff888141399b30, .magic: dead4ead, .owner: krxrpcio/7001/1646, .owner_cpu: 0 CPU: 0 UID: 0 PID: 1646 Comm: krxrpcio/7001 Not tainted 6.12.0-rc2-build3+ #4351 Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014 Call Trace: dump_stack_lvl+0x47/0x70 do_raw_spin_lock+0x3c/0x90 rxrpc_kernel_shutdown_call+0x83/0xb0 afs_put_call+0xd7/0x180 rxrpc_notify_socket+0xa0/0x190 rxrpc_input_split_jumbo+0x198/0x1d0 rxrpc_input_data+0x14b/0x1e0 ? rxrpc_input_call_packet+0xc2/0x1f0 rxrpc_input_call_event+0xad/0x6b0 rxrpc_input_packet_on_conn+0x1e1/0x210 rxrpc_input_packet+0x3f2/0x4d0 rxrpc_io_thread+0x243/0x410 ? __pfx_rxrpc_io_thread+0x10/0x10 kthread+0xcf/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x24/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53101", "url": "https://ubuntu.com/security/CVE-2024-53101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized value issue in from_kuid and from_kgid ocfs2_setattr() uses attr->ia_mode, attr->ia_uid and attr->ia_gid in a trace point even though ATTR_MODE, ATTR_UID and ATTR_GID aren't set. Initialize all fields of newattrs to avoid uninitialized variables, by checking if ATTR_MODE, ATTR_UID, ATTR_GID are initialized, otherwise 0.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53091", "url": "https://ubuntu.com/security/CVE-2024-53091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Add sk_is_inet and IS_ICSK check in tls_sw_has_ctx_tx/rx As the introduction of the support for vsock and unix sockets in sockmap, tls_sw_has_ctx_tx/rx cannot presume the socket passed in must be IS_ICSK. vsock and af_unix sockets have vsock_sock and unix_sock instead of inet_connection_sock. For these sockets, tls_get_ctx may return an invalid pointer and cause page fault in function tls_sw_ctx_rx. BUG: unable to handle page fault for address: 0000000000040030 Workqueue: vsock-loopback vsock_loopback_work RIP: 0010:sk_psock_strp_data_ready+0x23/0x60 Call Trace: ? __die+0x81/0xc3 ? no_context+0x194/0x350 ? do_page_fault+0x30/0x110 ? async_page_fault+0x3e/0x50 ? sk_psock_strp_data_ready+0x23/0x60 virtio_transport_recv_pkt+0x750/0x800 ? update_load_avg+0x7e/0x620 vsock_loopback_work+0xd0/0x100 process_one_work+0x1a7/0x360 worker_thread+0x30/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x112/0x130 ? __kthread_cancel_work+0x40/0x40 ret_from_fork+0x1f/0x40 v2: - Add IS_ICSK check v3: - Update the commits in Fixes", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53092", "url": "https://ubuntu.com/security/CVE-2024-53092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_pci: Fix admin vq cleanup by using correct info pointer vp_modern_avq_cleanup() and vp_del_vqs() clean up admin vq resources by virtio_pci_vq_info pointer. The info pointer of admin vq is stored in vp_dev->admin_vq.info instead of vp_dev->vqs[]. Using the info pointer from vp_dev->vqs[] for admin vq causes a kernel NULL pointer dereference bug. In vp_modern_avq_cleanup() and vp_del_vqs(), get the info pointer from vp_dev->admin_vq.info for admin vq to clean up the resources. Also make info ptr as argument of vp_del_vq() to be symmetric with vp_setup_vq(). vp_reset calls vp_modern_avq_cleanup, and causes the Call Trace: ================================================================== BUG: kernel NULL pointer dereference, address:0000000000000000 ... CPU: 49 UID: 0 PID: 4439 Comm: modprobe Not tainted 6.11.0-rc5 #1 RIP: 0010:vp_reset+0x57/0x90 [virtio_pci] Call Trace: ... ? vp_reset+0x57/0x90 [virtio_pci] ? vp_reset+0x38/0x90 [virtio_pci] virtio_reset_device+0x1d/0x30 remove_vq_common+0x1c/0x1a0 [virtio_net] virtnet_remove+0xa1/0xc0 [virtio_net] virtio_dev_remove+0x46/0xa0 ... virtio_pci_driver_exit+0x14/0x810 [virtio_pci] ==================================================================", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53102", "url": "https://ubuntu.com/security/CVE-2024-53102", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53093", "url": "https://ubuntu.com/security/CVE-2024-53093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: defer partition scanning We need to suppress the partition scan from occuring within the controller's scan_work context. If a path error occurs here, the IO will wait until a path becomes available or all paths are torn down, but that action also occurs within scan_work, so it would deadlock. Defer the partion scan to a different context that does not block scan_work.", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53094", "url": "https://ubuntu.com/security/CVE-2024-53094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Add sendpage_ok() check to disable MSG_SPLICE_PAGES While running ISER over SIW, the initiator machine encounters a warning from skb_splice_from_iter() indicating that a slab page is being used in send_page. To address this, it is better to add a sendpage_ok() check within the driver itself, and if it returns 0, then MSG_SPLICE_PAGES flag should be disabled before entering the network stack. A similar issue has been discussed for NVMe in this thread: https://lore.kernel.org/all/20240530142417.146696-1-ofir.gal@volumez.com/ WARNING: CPU: 0 PID: 5342 at net/core/skbuff.c:7140 skb_splice_from_iter+0x173/0x320 Call Trace: tcp_sendmsg_locked+0x368/0xe40 siw_tx_hdt+0x695/0xa40 [siw] siw_qp_sq_process+0x102/0xb00 [siw] siw_sq_resume+0x39/0x110 [siw] siw_run_sq+0x74/0x160 [siw] kthread+0xd2/0x100 ret_from_fork+0x34/0x40 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53100", "url": "https://ubuntu.com/security/CVE-2024-53100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: tcp: avoid race between queue_lock lock and destroy Commit 76d54bf20cdc (\"nvme-tcp: don't access released socket during error recovery\") added a mutex_lock() call for the queue->queue_lock in nvme_tcp_get_address(). However, the mutex_lock() races with mutex_destroy() in nvme_tcp_free_queue(), and causes the WARN below. DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: CPU: 3 PID: 34077 at kernel/locking/mutex.c:587 __mutex_lock+0xcf0/0x1220 Modules linked in: nvmet_tcp nvmet nvme_tcp nvme_fabrics iw_cm ib_cm ib_core pktcdvd nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables qrtr sunrpc ppdev 9pnet_virtio 9pnet pcspkr netfs parport_pc parport e1000 i2c_piix4 i2c_smbus loop fuse nfnetlink zram bochs drm_vram_helper drm_ttm_helper ttm drm_kms_helper xfs drm sym53c8xx floppy nvme scsi_transport_spi nvme_core nvme_auth serio_raw ata_generic pata_acpi dm_multipath qemu_fw_cfg [last unloaded: ib_uverbs] CPU: 3 UID: 0 PID: 34077 Comm: udisksd Not tainted 6.11.0-rc7 #319 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:__mutex_lock+0xcf0/0x1220 Code: 08 84 d2 0f 85 c8 04 00 00 8b 15 ef b6 c8 01 85 d2 0f 85 78 f4 ff ff 48 c7 c6 20 93 ee af 48 c7 c7 60 91 ee af e8 f0 a7 6d fd <0f> 0b e9 5e f4 ff ff 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 RSP: 0018:ffff88811305f760 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff88812c652058 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000001 RBP: ffff88811305f8b0 R08: 0000000000000001 R09: ffffed1075c36341 R10: ffff8883ae1b1a0b R11: 0000000000010498 R12: 0000000000000000 R13: 0000000000000000 R14: dffffc0000000000 R15: ffff88812c652058 FS: 00007f9713ae4980(0000) GS:ffff8883ae180000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcd78483c7c CR3: 0000000122c38000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn.cold+0x5b/0x1af ? __mutex_lock+0xcf0/0x1220 ? report_bug+0x1ec/0x390 ? handle_bug+0x3c/0x80 ? exc_invalid_op+0x13/0x40 ? asm_exc_invalid_op+0x16/0x20 ? __mutex_lock+0xcf0/0x1220 ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] ? __pfx___mutex_lock+0x10/0x10 ? __lock_acquire+0xd6a/0x59e0 ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] ? __pfx_nvme_tcp_get_address+0x10/0x10 [nvme_tcp] nvme_sysfs_show_address+0x81/0xc0 [nvme_core] dev_attr_show+0x42/0x80 ? __asan_memset+0x1f/0x40 sysfs_kf_seq_show+0x1f0/0x370 seq_read_iter+0x2cb/0x1130 ? rw_verify_area+0x3b1/0x590 ? __mutex_lock+0x433/0x1220 vfs_read+0x6a6/0xa20 ? lockdep_hardirqs_on+0x78/0x100 ? __pfx_vfs_read+0x10/0x10 ksys_read+0xf7/0x1d0 ? __pfx_ksys_read+0x10/0x10 ? __x64_sys_openat+0x105/0x1d0 do_syscall_64+0x93/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? __pfx_ksys_read+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? do_syscall_64+0x9f/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f9713f55cfa Code: 55 48 89 e5 48 83 ec 20 48 89 55 e8 48 89 75 f0 89 7d f8 e8 e8 74 f8 ff 48 8b 55 e8 48 8b 75 f0 4 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53095", "url": "https://ubuntu.com/security/CVE-2024-53095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix use-after-free of network namespace. Recently, we got a customer report that CIFS triggers oops while reconnecting to a server. [0] The workload runs on Kubernetes, and some pods mount CIFS servers in non-root network namespaces. The problem rarely happened, but it was always while the pod was dying. The root cause is wrong reference counting for network namespace. CIFS uses kernel sockets, which do not hold refcnt of the netns that the socket belongs to. That means CIFS must ensure the socket is always freed before its netns; otherwise, use-after-free happens. The repro steps are roughly: 1. mount CIFS in a non-root netns 2. drop packets from the netns 3. destroy the netns 4. unmount CIFS We can reproduce the issue quickly with the script [1] below and see the splat [2] if CONFIG_NET_NS_REFCNT_TRACKER is enabled. When the socket is TCP, it is hard to guarantee the netns lifetime without holding refcnt due to async timers. Let's hold netns refcnt for each socket as done for SMC in commit 9744d2bf1976 (\"smc: Fix use-after-free in tcp_write_timer_handler().\"). Note that we need to move put_net() from cifs_put_tcp_session() to clean_demultiplex_info(); otherwise, __sock_create() still could touch a freed netns while cifsd tries to reconnect from cifs_demultiplex_thread(). Also, maybe_get_net() cannot be put just before __sock_create() because the code is not under RCU and there is a small chance that the same address happened to be reallocated to another netns. [0]: CIFS: VFS: \\\\XXXXXXXXXXX has not responded in 15 seconds. Reconnecting... CIFS: Serverclose failed 4 times, giving up Unable to handle kernel paging request at virtual address 14de99e461f84a07 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 CM = 0, WnR = 0 [14de99e461f84a07] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: cls_bpf sch_ingress nls_utf8 cifs cifs_arc4 cifs_md4 dns_resolver tcp_diag inet_diag veth xt_state xt_connmark nf_conntrack_netlink xt_nat xt_statistic xt_MASQUERADE xt_mark xt_addrtype ipt_REJECT nf_reject_ipv4 nft_chain_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment nft_compat nf_tables nfnetlink overlay nls_ascii nls_cp437 sunrpc vfat fat aes_ce_blk aes_ce_cipher ghash_ce sm4_ce_cipher sm4 sm3_ce sm3 sha3_ce sha512_ce sha512_arm64 sha1_ce ena button sch_fq_codel loop fuse configfs dmi_sysfs sha2_ce sha256_arm64 dm_mirror dm_region_hash dm_log dm_mod dax efivarfs CPU: 5 PID: 2690970 Comm: cifsd Not tainted 6.1.103-109.184.amzn2023.aarch64 #1 Hardware name: Amazon EC2 r7g.4xlarge/, BIOS 1.0 11/1/2018 pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : fib_rules_lookup+0x44/0x238 lr : __fib_lookup+0x64/0xbc sp : ffff8000265db790 x29: ffff8000265db790 x28: 0000000000000000 x27: 000000000000bd01 x26: 0000000000000000 x25: ffff000b4baf8000 x24: ffff00047b5e4580 x23: ffff8000265db7e0 x22: 0000000000000000 x21: ffff00047b5e4500 x20: ffff0010e3f694f8 x19: 14de99e461f849f7 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 3f92800abd010002 x11: 0000000000000001 x10: ffff0010e3f69420 x9 : ffff800008a6f294 x8 : 0000000000000000 x7 : 0000000000000006 x6 : 0000000000000000 x5 : 0000000000000001 x4 : ffff001924354280 x3 : ffff8000265db7e0 x2 : 0000000000000000 x1 : ffff0010e3f694f8 x0 : ffff00047b5e4500 Call trace: fib_rules_lookup+0x44/0x238 __fib_lookup+0x64/0xbc ip_route_output_key_hash_rcu+0x2c4/0x398 ip_route_output_key_hash+0x60/0x8c tcp_v4_connect+0x290/0x488 __inet_stream_connect+0x108/0x3d0 inet_stream_connect+0x50/0x78 kernel_connect+0x6c/0xac generic_ip_conne ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-50265", "url": "https://ubuntu.com/security/CVE-2024-50265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove() Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove(): [ 57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12 [ 57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry [ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004 [...] [ 57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [...] [ 57.331328] Call Trace: [ 57.331477] [...] [ 57.333511] ? do_user_addr_fault+0x3e5/0x740 [ 57.333778] ? exc_page_fault+0x70/0x170 [ 57.334016] ? asm_exc_page_fault+0x2b/0x30 [ 57.334263] ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10 [ 57.334596] ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [ 57.334913] ocfs2_xa_remove_entry+0x23/0xc0 [ 57.335164] ocfs2_xa_set+0x704/0xcf0 [ 57.335381] ? _raw_spin_unlock+0x1a/0x40 [ 57.335620] ? ocfs2_inode_cache_unlock+0x16/0x20 [ 57.335915] ? trace_preempt_on+0x1e/0x70 [ 57.336153] ? start_this_handle+0x16c/0x500 [ 57.336410] ? preempt_count_sub+0x50/0x80 [ 57.336656] ? _raw_read_unlock+0x20/0x40 [ 57.336906] ? start_this_handle+0x16c/0x500 [ 57.337162] ocfs2_xattr_block_set+0xa6/0x1e0 [ 57.337424] __ocfs2_xattr_set_handle+0x1fd/0x5d0 [ 57.337706] ? ocfs2_start_trans+0x13d/0x290 [ 57.337971] ocfs2_xattr_set+0xb13/0xfb0 [ 57.338207] ? dput+0x46/0x1c0 [ 57.338393] ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338665] ? ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338948] __vfs_removexattr+0x92/0xc0 [ 57.339182] __vfs_removexattr_locked+0xd5/0x190 [ 57.339456] ? preempt_count_sub+0x50/0x80 [ 57.339705] vfs_removexattr+0x5f/0x100 [...] Reproducer uses faultinject facility to fail ocfs2_xa_remove() -> ocfs2_xa_value_truncate() with -ENOMEM. In this case the comment mentions that we can return 0 if ocfs2_xa_cleanup_value_truncate() is going to wipe the entry anyway. But the following 'rc' check is wrong and execution flow do 'ocfs2_xa_remove_entry(loc);' twice: * 1st: in ocfs2_xa_cleanup_value_truncate(); * 2nd: returning back to ocfs2_xa_remove() instead of going to 'out'. Fix this by skipping the 2nd removal of the same entry and making syzkaller repro happy.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50266", "url": "https://ubuntu.com/security/CVE-2024-50266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: qcom: videocc-sm8350: use HW_CTRL_TRIGGER for vcodec GDSCs A recent change in the venus driver results in a stuck clock on the Lenovo ThinkPad X13s, for example, when streaming video in firefox: \tvideo_cc_mvs0_clk status stuck at 'off' \tWARNING: CPU: 6 PID: 2885 at drivers/clk/qcom/clk-branch.c:87 clk_branch_wait+0x144/0x15c \t... \tCall trace: \t clk_branch_wait+0x144/0x15c \t clk_branch2_enable+0x30/0x40 \t clk_core_enable+0xd8/0x29c \t clk_enable+0x2c/0x4c \t vcodec_clks_enable.isra.0+0x94/0xd8 [venus_core] \t coreid_power_v4+0x464/0x628 [venus_core] \t vdec_start_streaming+0xc4/0x510 [venus_dec] \t vb2_start_streaming+0x6c/0x180 [videobuf2_common] \t vb2_core_streamon+0x120/0x1dc [videobuf2_common] \t vb2_streamon+0x1c/0x6c [videobuf2_v4l2] \t v4l2_m2m_ioctl_streamon+0x30/0x80 [v4l2_mem2mem] \t v4l_streamon+0x24/0x30 [videodev] using the out-of-tree sm8350/sc8280xp venus support. [1] Update also the sm8350/sc8280xp GDSC definitions so that the hw control mode can be changed at runtime as the venus driver now requires.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50267", "url": "https://ubuntu.com/security/CVE-2024-50267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: fix use after free in debug printk The \"dev_dbg(&urb->dev->dev, ...\" which happens after usb_free_urb(urb) is a use after free of the \"urb\" pointer. Store the \"dev\" pointer at the start of the function to avoid this issue.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50268", "url": "https://ubuntu.com/security/CVE-2024-50268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: fix potential out of bounds in ucsi_ccg_update_set_new_cam_cmd() The \"*cmd\" variable can be controlled by the user via debugfs. That means \"new_cam\" can be as high as 255 while the size of the uc->updated[] array is UCSI_MAX_ALTMODES (30). The call tree is: ucsi_cmd() // val comes from simple_attr_write_xsigned() -> ucsi_send_command() -> ucsi_send_command_common() -> ucsi_run_command() // calls ucsi->ops->sync_control() -> ucsi_ccg_sync_control()", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53083", "url": "https://ubuntu.com/security/CVE-2024-53083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: qcom-pmic: init value of hdr_len/txbuf_len earlier If the read of USB_PDPHY_RX_ACKNOWLEDGE_REG failed, then hdr_len and txbuf_len are uninitialized. This commit stops to print uninitialized value and misleading/false data.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50269", "url": "https://ubuntu.com/security/CVE-2024-50269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: musb: sunxi: Fix accessing an released usb phy Commit 6ed05c68cbca (\"usb: musb: sunxi: Explicitly release USB PHY on exit\") will cause that usb phy @glue->xceiv is accessed after released. 1) register platform driver @sunxi_musb_driver // get the usb phy @glue->xceiv sunxi_musb_probe() -> devm_usb_get_phy(). 2) register and unregister platform driver @musb_driver musb_probe() -> sunxi_musb_init() use the phy here //the phy is released here musb_remove() -> sunxi_musb_exit() -> devm_usb_put_phy() 3) register @musb_driver again musb_probe() -> sunxi_musb_init() use the phy here but the phy has been released at 2). ... Fixed by reverting the commit, namely, removing devm_usb_put_phy() from sunxi_musb_exit().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53079", "url": "https://ubuntu.com/security/CVE-2024-53079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/thp: fix deferred split unqueue naming and locking Recent changes are putting more pressure on THP deferred split queues: under load revealing long-standing races, causing list_del corruptions, \"Bad page state\"s and worse (I keep BUGs in both of those, so usually don't get to see how badly they end up without). The relevant recent changes being 6.8's mTHP, 6.10's mTHP swapout, and 6.12's mTHP swapin, improved swap allocation, and underused THP splitting. Before fixing locking: rename misleading folio_undo_large_rmappable(), which does not undo large_rmappable, to folio_unqueue_deferred_split(), which is what it does. But that and its out-of-line __callee are mm internals of very limited usability: add comment and WARN_ON_ONCEs to check usage; and return a bool to say if a deferred split was unqueued, which can then be used in WARN_ON_ONCEs around safety checks (sparing callers the arcane conditionals in __folio_unqueue_deferred_split()). Just omit the folio_unqueue_deferred_split() from free_unref_folios(), all of whose callers now call it beforehand (and if any forget then bad_page() will tell) - except for its caller put_pages_list(), which itself no longer has any callers (and will be deleted separately). Swapout: mem_cgroup_swapout() has been resetting folio->memcg_data 0 without checking and unqueueing a THP folio from deferred split list; which is unfortunate, since the split_queue_lock depends on the memcg (when memcg is enabled); so swapout has been unqueueing such THPs later, when freeing the folio, using the pgdat's lock instead: potentially corrupting the memcg's list. __remove_mapping() has frozen refcount to 0 here, so no problem with calling folio_unqueue_deferred_split() before resetting memcg_data. That goes back to 5.4 commit 87eaceb3faa5 (\"mm: thp: make deferred split shrinker memcg aware\"): which included a check on swapcache before adding to deferred queue, but no check on deferred queue before adding THP to swapcache. That worked fine with the usual sequence of events in reclaim (though there were a couple of rare ways in which a THP on deferred queue could have been swapped out), but 6.12 commit dafff3f4c850 (\"mm: split underused THPs\") avoids splitting underused THPs in reclaim, which makes swapcache THPs on deferred queue commonplace. Keep the check on swapcache before adding to deferred queue? Yes: it is no longer essential, but preserves the existing behaviour, and is likely to be a worthwhile optimization (vmstat showed much more traffic on the queue under swapping load if the check was removed); update its comment. Memcg-v1 move (deprecated): mem_cgroup_move_account() has been changing folio->memcg_data without checking and unqueueing a THP folio from the deferred list, sometimes corrupting \"from\" memcg's list, like swapout. Refcount is non-zero here, so folio_unqueue_deferred_split() can only be used in a WARN_ON_ONCE to validate the fix, which must be done earlier: mem_cgroup_move_charge_pte_range() first try to split the THP (splitting of course unqueues), or skip it if that fails. Not ideal, but moving charge has been requested, and khugepaged should repair the THP later: nobody wants new custom unqueueing code just for this deprecated case. The 87eaceb3faa5 commit did have the code to move from one deferred list to another (but was not conscious of its unsafety while refcount non-0); but that was removed by 5.6 commit fac0516b5534 (\"mm: thp: don't need care deferred split queue in memcg charge move path\"), which argued that the existence of a PMD mapping guarantees that the THP cannot be on a deferred list. As above, false in rare cases, and now commonly false. Backport to 6.11 should be straightforward. Earlier backports must take care that other _deferred_list fixes and dependencies are included. There is not a strong case for backports, but they can fix cornercases.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50270", "url": "https://ubuntu.com/security/CVE-2024-50270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: avoid overflow in damon_feed_loop_next_input() damon_feed_loop_next_input() is inefficient and fragile to overflows. Specifically, 'score_goal_diff_bp' calculation can overflow when 'score' is high. The calculation is actually unnecessary at all because 'goal' is a constant of value 10,000. Calculation of 'compensation' is again fragile to overflow. Final calculation of return value for under-achiving case is again fragile to overflow when the current score is under-achieving the target. Add two corner cases handling at the beginning of the function to make the body easier to read, and rewrite the body of the function to avoid overflows and the unnecessary bp value calcuation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50271", "url": "https://ubuntu.com/security/CVE-2024-50271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: signal: restore the override_rlimit logic Prior to commit d64696905554 (\"Reimplement RLIMIT_SIGPENDING on top of ucounts\") UCOUNT_RLIMIT_SIGPENDING rlimit was not enforced for a class of signals. However now it's enforced unconditionally, even if override_rlimit is set. This behavior change caused production issues. For example, if the limit is reached and a process receives a SIGSEGV signal, sigqueue_alloc fails to allocate the necessary resources for the signal delivery, preventing the signal from being delivered with siginfo. This prevents the process from correctly identifying the fault address and handling the error. From the user-space perspective, applications are unaware that the limit has been reached and that the siginfo is effectively 'corrupted'. This can lead to unpredictable behavior and crashes, as we observed with java applications. Fix this by passing override_rlimit into inc_rlimit_get_ucounts() and skip the comparison to max there if override_rlimit is set. This effectively restores the old behavior.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50272", "url": "https://ubuntu.com/security/CVE-2024-50272", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: filemap: Fix bounds checking in filemap_read() If the caller supplies an iocb->ki_pos value that is close to the filesystem upper limit, and an iterator with a count that causes us to overflow that limit, then filemap_read() enters an infinite loop. This behaviour was discovered when testing xfstests generic/525 with the \"localio\" optimisation for loopback NFS mounts.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53104", "url": "https://ubuntu.com/security/CVE-2024-53104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_parse_format This can lead to out of bounds writes since frames of this type were not taken into account when calculating the size of the frames buffer in uvc_parse_streaming.", "cve_priority": "high", "cve_public_date": "2024-12-02 08:15:00 UTC" }, { "cve": "CVE-2024-50273", "url": "https://ubuntu.com/security/CVE-2024-50273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reinitialize delayed ref list after deleting it from the list At insert_delayed_ref() if we need to update the action of an existing ref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head's ref_add_list using list_del(), which leaves the ref's add_list member not reinitialized, as list_del() sets the next and prev members of the list to LIST_POISON1 and LIST_POISON2, respectively. If later we end up calling drop_delayed_ref() against the ref, which can happen during merging or when destroying delayed refs due to a transaction abort, we can trigger a crash since at drop_delayed_ref() we call list_empty() against the ref's add_list, which returns false since the list was not reinitialized after the list_del() and as a consequence we call list_del() again at drop_delayed_ref(). This results in an invalid list access since the next and prev members are set to poison pointers, resulting in a splat if CONFIG_LIST_HARDENED and CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences otherwise. So fix this by deleting from the list with list_del_init() instead.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53064", "url": "https://ubuntu.com/security/CVE-2024-53064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix idpf_vc_core_init error path In an event where the platform running the device control plane is rebooted, reset is detected on the driver. It releases all the resources and waits for the reset to complete. Once the reset is done, it tries to build the resources back. At this time if the device control plane is not yet started, then the driver timeouts on the virtchnl message and retries to establish the mailbox again. In the retry flow, mailbox is deinitialized but the mailbox workqueue is still alive and polling for the mailbox message. This results in accessing the released control queue leading to null-ptr-deref. Fix it by unrolling the work queue cancellation and mailbox deinitialization in the reverse order which they got initialized.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50274", "url": "https://ubuntu.com/security/CVE-2024-50274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: avoid vport access in idpf_get_link_ksettings When the device control plane is removed or the platform running device control plane is rebooted, a reset is detected on the driver. On driver reset, it releases the resources and waits for the reset to complete. If the reset fails, it takes the error path and releases the vport lock. At this time if the monitoring tools tries to access link settings, it call traces for accessing released vport pointer. To avoid it, move link_speed_mbps to netdev_priv structure which removes the dependency on vport pointer and the vport lock in idpf_get_link_ksettings. Also use netif_carrier_ok() to check the link status and adjust the offsetof to use link_up instead of link_speed_mbps.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53065", "url": "https://ubuntu.com/security/CVE-2024-53065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/slab: fix warning caused by duplicate kmem_cache creation in kmem_buckets_create Commit b035f5a6d852 (\"mm: slab: reduce the kmalloc() minimum alignment if DMA bouncing possible\") reduced ARCH_KMALLOC_MINALIGN to 8 on arm64. However, with KASAN_HW_TAGS enabled, arch_slab_minalign() becomes 16. This causes kmalloc_caches[*][8] to be aliased to kmalloc_caches[*][16], resulting in kmem_buckets_create() attempting to create a kmem_cache for size 16 twice. This duplication triggers warnings on boot: [ 2.325108] ------------[ cut here ]------------ [ 2.325135] kmem_cache of name 'memdup_user-16' already exists [ 2.325783] WARNING: CPU: 0 PID: 1 at mm/slab_common.c:107 __kmem_cache_create_args+0xb8/0x3b0 [ 2.327957] Modules linked in: [ 2.328550] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5mm-unstable-arm64+ #12 [ 2.328683] Hardware name: QEMU QEMU Virtual Machine, BIOS 2024.02-2 03/11/2024 [ 2.328790] pstate: 61000009 (nZCv daif -PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 2.328911] pc : __kmem_cache_create_args+0xb8/0x3b0 [ 2.328930] lr : __kmem_cache_create_args+0xb8/0x3b0 [ 2.328942] sp : ffff800083d6fc50 [ 2.328961] x29: ffff800083d6fc50 x28: f2ff0000c1674410 x27: ffff8000820b0598 [ 2.329061] x26: 000000007fffffff x25: 0000000000000010 x24: 0000000000002000 [ 2.329101] x23: ffff800083d6fce8 x22: ffff8000832222e8 x21: ffff800083222388 [ 2.329118] x20: f2ff0000c1674410 x19: f5ff0000c16364c0 x18: ffff800083d80030 [ 2.329135] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 2.329152] x14: 0000000000000000 x13: 0a73747369786520 x12: 79646165726c6120 [ 2.329169] x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : 0000000000000000 [ 2.329194] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 [ 2.329210] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 2.329226] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 2.329291] Call trace: [ 2.329407] __kmem_cache_create_args+0xb8/0x3b0 [ 2.329499] kmem_buckets_create+0xfc/0x320 [ 2.329526] init_user_buckets+0x34/0x78 [ 2.329540] do_one_initcall+0x64/0x3c8 [ 2.329550] kernel_init_freeable+0x26c/0x578 [ 2.329562] kernel_init+0x3c/0x258 [ 2.329574] ret_from_fork+0x10/0x20 [ 2.329698] ---[ end trace 0000000000000000 ]--- [ 2.403704] ------------[ cut here ]------------ [ 2.404716] kmem_cache of name 'msg_msg-16' already exists [ 2.404801] WARNING: CPU: 2 PID: 1 at mm/slab_common.c:107 __kmem_cache_create_args+0xb8/0x3b0 [ 2.404842] Modules linked in: [ 2.404971] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.12.0-rc5mm-unstable-arm64+ #12 [ 2.405026] Tainted: [W]=WARN [ 2.405043] Hardware name: QEMU QEMU Virtual Machine, BIOS 2024.02-2 03/11/2024 [ 2.405057] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2.405079] pc : __kmem_cache_create_args+0xb8/0x3b0 [ 2.405100] lr : __kmem_cache_create_args+0xb8/0x3b0 [ 2.405111] sp : ffff800083d6fc50 [ 2.405115] x29: ffff800083d6fc50 x28: fbff0000c1674410 x27: ffff8000820b0598 [ 2.405135] x26: 000000000000ffd0 x25: 0000000000000010 x24: 0000000000006000 [ 2.405153] x23: ffff800083d6fce8 x22: ffff8000832222e8 x21: ffff800083222388 [ 2.405169] x20: fbff0000c1674410 x19: fdff0000c163d6c0 x18: ffff800083d80030 [ 2.405185] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 2.405201] x14: 0000000000000000 x13: 0a73747369786520 x12: 79646165726c6120 [ 2.405217] x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : 0000000000000000 [ 2.405233] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 [ 2.405248] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 2.405271] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 2.405287] Call trace: [ 2 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50275", "url": "https://ubuntu.com/security/CVE-2024-50275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64/sve: Discard stale CPU state when handling SVE traps The logic for handling SVE traps manipulates saved FPSIMD/SVE state incorrectly, and a race with preemption can result in a task having TIF_SVE set and TIF_FOREIGN_FPSTATE clear even though the live CPU state is stale (e.g. with SVE traps enabled). This has been observed to result in warnings from do_sve_acc() where SVE traps are not expected while TIF_SVE is set: | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* SVE access shouldn't have trapped */ Warnings of this form have been reported intermittently, e.g. https://lore.kernel.org/linux-arm-kernel/CA+G9fYtEGe_DhY2Ms7+L7NKsLYUomGsgqpdBj+QwDLeSg=JhGg@mail.gmail.com/ https://lore.kernel.org/linux-arm-kernel/000000000000511e9a060ce5a45c@google.com/ The race can occur when the SVE trap handler is preempted before and after manipulating the saved FPSIMD/SVE state, starting and ending on the same CPU, e.g. | void do_sve_acc(unsigned long esr, struct pt_regs *regs) | { | // Trap on CPU 0 with TIF_SVE clear, SVE 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(); | | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* SVE access shouldn't have trapped */ | | sve_init_regs() { | if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) { | ... | } else { | fpsimd_to_sve(current); | current->thread.fp_type = FP_STATE_SVE; | } | } | | 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 SVE 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.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50276", "url": "https://ubuntu.com/security/CVE-2024-50276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: vertexcom: mse102x: Fix possible double free of TX skb The scope of the TX skb is wider than just mse102x_tx_frame_spi(), so in case the TX skb room needs to be expanded, we should free the the temporary skb instead of the original skb. Otherwise the original TX skb pointer would be freed again in mse102x_tx_work(), which leads to crashes: Internal error: Oops: 0000000096000004 [#2] PREEMPT SMP CPU: 0 PID: 712 Comm: kworker/0:1 Tainted: G D 6.6.23 Hardware name: chargebyte Charge SOM DC-ONE (DT) Workqueue: events mse102x_tx_work [mse102x] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_release_data+0xb8/0x1d8 lr : skb_release_data+0x1ac/0x1d8 sp : ffff8000819a3cc0 x29: ffff8000819a3cc0 x28: ffff0000046daa60 x27: ffff0000057f2dc0 x26: ffff000005386c00 x25: 0000000000000002 x24: 00000000ffffffff x23: 0000000000000000 x22: 0000000000000001 x21: ffff0000057f2e50 x20: 0000000000000006 x19: 0000000000000000 x18: ffff00003fdacfcc x17: e69ad452d0c49def x16: 84a005feff870102 x15: 0000000000000000 x14: 000000000000024a x13: 0000000000000002 x12: 0000000000000000 x11: 0000000000000400 x10: 0000000000000930 x9 : ffff00003fd913e8 x8 : fffffc00001bc008 x7 : 0000000000000000 x6 : 0000000000000008 x5 : ffff00003fd91340 x4 : 0000000000000000 x3 : 0000000000000009 x2 : 00000000fffffffe x1 : 0000000000000000 x0 : 0000000000000000 Call trace: skb_release_data+0xb8/0x1d8 kfree_skb_reason+0x48/0xb0 mse102x_tx_work+0x164/0x35c [mse102x] process_one_work+0x138/0x260 worker_thread+0x32c/0x438 kthread+0x118/0x11c ret_from_fork+0x10/0x20 Code: aa1303e0 97fffab6 72001c1f 54000141 (f9400660)", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53066", "url": "https://ubuntu.com/security/CVE-2024-53066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfs: Fix KMSAN warning in decode_getfattr_attrs() Fix the following KMSAN warning: CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G B Tainted: [B]=BAD_PAGE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) ===================================================== ===================================================== BUG: KMSAN: uninit-value in decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_generic+0x806/0xb00 nfs4_xdr_dec_getattr+0x1de/0x240 rpcauth_unwrap_resp_decode+0xab/0x100 rpcauth_unwrap_resp+0x95/0xc0 call_decode+0x4ff/0xb50 __rpc_execute+0x57b/0x19d0 rpc_execute+0x368/0x5e0 rpc_run_task+0xcfe/0xee0 nfs4_proc_getattr+0x5b5/0x990 __nfs_revalidate_inode+0x477/0xd00 nfs_access_get_cached+0x1021/0x1cc0 nfs_do_access+0x9f/0xae0 nfs_permission+0x1e4/0x8c0 inode_permission+0x356/0x6c0 link_path_walk+0x958/0x1330 path_lookupat+0xce/0x6b0 filename_lookup+0x23e/0x770 vfs_statx+0xe7/0x970 vfs_fstatat+0x1f2/0x2c0 __se_sys_newfstatat+0x67/0x880 __x64_sys_newfstatat+0xbd/0x120 x64_sys_call+0x1826/0x3cf0 do_syscall_64+0xd0/0x1b0 entry_SYSCALL_64_after_hwframe+0x77/0x7f The KMSAN warning is triggered in decode_getfattr_attrs(), when calling decode_attr_mdsthreshold(). It appears that fattr->mdsthreshold is not initialized. Fix the issue by initializing fattr->mdsthreshold to NULL in nfs_fattr_init().", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53067", "url": "https://ubuntu.com/security/CVE-2024-53067", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Start the RTC update work later The RTC update work involves runtime resuming the UFS controller. Hence, only start the RTC update work after runtime power management in the UFS driver has been fully initialized. This patch fixes the following kernel crash: Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP Workqueue: events ufshcd_rtc_work Call trace: _raw_spin_lock_irqsave+0x34/0x8c (P) pm_runtime_get_if_active+0x24/0x9c (L) pm_runtime_get_if_active+0x24/0x9c ufshcd_rtc_work+0x138/0x1b4 process_one_work+0x148/0x288 worker_thread+0x2cc/0x3d4 kthread+0x110/0x114 ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50277", "url": "https://ubuntu.com/security/CVE-2024-50277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: fix a crash if blk_alloc_disk fails If blk_alloc_disk fails, the variable md->disk is set to an error value. cleanup_mapped_device will see that md->disk is non-NULL and it will attempt to access it, causing a crash on this statement \"md->disk->private_data = NULL;\".", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50278", "url": "https://ubuntu.com/security/CVE-2024-50278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix potential out-of-bounds access on the first resume Out-of-bounds access occurs if the fast device is expanded unexpectedly before the first-time resume of the cache table. This happens because expanding the fast device requires reloading the cache table for cache_create to allocate new in-core data structures that fit the new size, and the check in cache_preresume is not performed during the first resume, leading to the issue. Reproduce steps: 1. prepare component devices: 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\" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct 2. load a cache table of 512 cache blocks, and deliberately expand the fast device before resuming the cache, making the in-core data structures inadequate. dmsetup create cache --notable dmsetup reload cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" dmsetup reload cdata --table \"0 131072 linear /dev/sdc 8192\" dmsetup resume cdata dmsetup resume cache 3. suspend the cache to write out the in-core dirty bitset and hint array, leading to out-of-bounds access to the dirty bitset at offset 0x40: dmsetup suspend cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80 Read of size 8 at addr ffffc90000085040 by task dmsetup/90 (...snip...) The buggy address belongs to the virtual mapping at [ffffc90000085000, ffffc90000087000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by checking the size change on the first resume.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50279", "url": "https://ubuntu.com/security/CVE-2024-50279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix out-of-bounds access to the dirty bitset when resizing dm-cache checks the dirty bits of the cache blocks to be dropped when shrinking the fast device, but an index bug in bitset iteration causes out-of-bounds access. Reproduce steps: 1. create a cache device of 1024 cache blocks (128 bytes dirty bitset) dmsetup create cmeta --table \"0 8192 linear /dev/sdc 0\" dmsetup create cdata --table \"0 131072 linear /dev/sdc 8192\" dmsetup create corig --table \"0 524288 linear /dev/sdc 262144\" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" 2. shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80) dmsetup suspend cache dmsetup reload cdata --table \"0 65536 linear /dev/sdc 8192\" dmsetup resume cdata dmsetup resume cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131 (...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by making the index post-incremented.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50280", "url": "https://ubuntu.com/security/CVE-2024-50280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix flushing uninitialized delayed_work on cache_ctr error An unexpected WARN_ON from flush_work() may occur when cache creation fails, caused by destroying the uninitialized delayed_work waker in the error path of cache_create(). For example, the warning appears on the superblock checksum error. Reproduce steps: 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\" dd if=/dev/urandom of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" Kernel logs: (snip) WARNING: CPU: 0 PID: 84 at kernel/workqueue.c:4178 __flush_work+0x5d4/0x890 Fix by pulling out the cancel_delayed_work_sync() from the constructor's error path. This patch doesn't affect the use-after-free fix for concurrent dm_resume and dm_destroy (commit 6a459d8edbdb (\"dm cache: Fix UAF in destroy()\")) as cache_dtr is not changed.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50281", "url": "https://ubuntu.com/security/CVE-2024-50281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: trusted: dcp: fix NULL dereference in AEAD crypto operation When sealing or unsealing a key blob we currently do not wait for the AEAD cipher operation to finish and simply return after submitting the request. If there is some load on the system we can exit before the cipher operation is done and the buffer we read from/write to is already removed from the stack. This will e.g. result in NULL pointer dereference errors in the DCP driver during blob creation. Fix this by waiting for the AEAD cipher operation to finish before resuming the seal and unseal calls.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50282", "url": "https://ubuntu.com/security/CVE-2024-50282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read() Avoid a possible buffer overflow if size is larger than 4K. (cherry picked from commit f5d873f5825b40d886d03bd2aede91d4cf002434)", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53071", "url": "https://ubuntu.com/security/CVE-2024-53071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Be stricter about IO mapping flags The current panthor_device_mmap_io() implementation has two issues: 1. For mapping DRM_PANTHOR_USER_FLUSH_ID_MMIO_OFFSET, panthor_device_mmap_io() bails if VM_WRITE is set, but does not clear VM_MAYWRITE. That means userspace can use mprotect() to make the mapping writable later on. This is a classic Linux driver gotcha. I don't think this actually has any impact in practice: When the GPU is powered, writes to the FLUSH_ID seem to be ignored; and when the GPU is not powered, the dummy_latest_flush page provided by the driver is deliberately designed to not do any flushes, so the only thing writing to the dummy_latest_flush could achieve would be to make *more* flushes happen. 2. panthor_device_mmap_io() does not block MAP_PRIVATE mappings (which are mappings without the VM_SHARED flag). MAP_PRIVATE in combination with VM_MAYWRITE indicates that the VMA has copy-on-write semantics, which for VM_PFNMAP are semi-supported but fairly cursed. In particular, in such a mapping, the driver can only install PTEs during mmap() by calling remap_pfn_range() (because remap_pfn_range() wants to **store the physical address of the mapped physical memory into the vm_pgoff of the VMA**); installing PTEs later on with a fault handler (as panthor does) is not supported in private mappings, and so if you try to fault in such a mapping, vmf_insert_pfn_prot() splats when it hits a BUG() check. Fix it by clearing the VM_MAYWRITE flag (userspace writing to the FLUSH_ID doesn't make sense) and requiring VM_SHARED (copy-on-write semantics for the FLUSH_ID don't make sense). Reproducers for both scenarios are in the notes of my patch on the mailing list; I tested that these bugs exist on a Rock 5B machine. Note that I only compile-tested the patch, I haven't tested it; I don't have a working kernel build setup for the test machine yet. Please test it before applying it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53080", "url": "https://ubuntu.com/security/CVE-2024-53080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Lock XArray when getting entries for the VM Similar to commit cac075706f29 (\"drm/panthor: Fix race when converting group handle to group object\") we need to use the XArray's internal locking when retrieving a vm pointer from there. v2: Removed part of the patch that was trying to protect fetching the heap pointer from XArray, as that operation is protected by the @pool->lock.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53084", "url": "https://ubuntu.com/security/CVE-2024-53084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Break an object reference loop When remaining resources are being cleaned up on driver close, outstanding VM mappings may result in resources being leaked, due to an object reference loop, as shown below, with each object (or set of objects) referencing the object below it: PVR GEM Object GPU scheduler \"finished\" fence GPU scheduler “scheduled” fence PVR driver “done” fence PVR Context PVR VM Context PVR VM Mappings PVR GEM Object The reference that the PVR VM Context has on the VM mappings is a soft one, in the sense that the freeing of outstanding VM mappings is done as part of VM context destruction; no reference counts are involved, as is the case for all the other references in the loop. To break the reference loop during cleanup, free the outstanding VM mappings before destroying the PVR Context associated with the VM context.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53085", "url": "https://ubuntu.com/security/CVE-2024-53085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: Lock TPM chip in tpm_pm_suspend() first Setting TPM_CHIP_FLAG_SUSPENDED in the end of tpm_pm_suspend() can be racy according, as this leaves window for tpm_hwrng_read() to be called while the operation is in progress. The recent bug report gives also evidence of this behaviour. Aadress this by locking the TPM chip before checking any chip->flags both in tpm_pm_suspend() and tpm_hwrng_read(). Move TPM_CHIP_FLAG_SUSPENDED check inside tpm_get_random() so that it will be always checked only when the lock is reserved.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53086", "url": "https://ubuntu.com/security/CVE-2024-53086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Drop VM dma-resv lock on xe_sync_in_fence_get failure in exec IOCTL Upon failure all locks need to be dropped before returning to the user. (cherry picked from commit 7d1a4258e602ffdce529f56686925034c1b3b095)", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53087", "url": "https://ubuntu.com/security/CVE-2024-53087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix possible exec queue leak in exec IOCTL In a couple of places after an exec queue is looked up the exec IOCTL returns on input errors without dropping the exec queue ref. Fix this ensuring the exec queue ref is dropped on input error. (cherry picked from commit 07064a200b40ac2195cb6b7b779897d9377e5e6f)", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50283", "url": "https://ubuntu.com/security/CVE-2024-50283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-use-after-free in smb3_preauth_hash_rsp ksmbd_user_session_put should be called under smb3_preauth_hash_rsp(). It will avoid freeing session before calling smb3_preauth_hash_rsp().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50284", "url": "https://ubuntu.com/security/CVE-2024-50284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix the missing xa_store error check xa_store() can fail, it return xa_err(-EINVAL) if the entry cannot be stored in an XArray, or xa_err(-ENOMEM) if memory allocation failed, so check error for xa_store() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50285", "url": "https://ubuntu.com/security/CVE-2024-50285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: check outstanding simultaneous SMB operations If Client send simultaneous SMB operations to ksmbd, It exhausts too much memory through the \"ksmbd_work_cache”. It will cause OOM issue. ksmbd has a credit mechanism but it can't handle this problem. This patch add the check if it exceeds max credits to prevent this problem by assuming that one smb request consumes at least one credit.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50286", "url": "https://ubuntu.com/security/CVE-2024-50286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-use-after-free in ksmbd_smb2_session_create There is a race condition between ksmbd_smb2_session_create and ksmbd_expire_session. This patch add missing sessions_table_lock while adding/deleting session from global session table.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50287", "url": "https://ubuntu.com/security/CVE-2024-50287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-tpg: prevent the risk of a division by zero As reported by Coverity, the logic at tpg_precalculate_line() blindly rescales the buffer even when scaled_witdh is equal to zero. If this ever happens, this will cause a division by zero. Instead, add a WARN_ON_ONCE() to trigger such cases and return without doing any precalculation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50288", "url": "https://ubuntu.com/security/CVE-2024-50288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: fix buffer overwrite when using > 32 buffers The maximum number of buffers that can be requested was increased to 64 for the video capture queue. But video capture used a must_blank array that was still sized for 32 (VIDEO_MAX_FRAME). This caused an out-of-bounds write when using buffer indices >= 32. Create a new define MAX_VID_CAP_BUFFERS that is used to access the must_blank array and set max_num_buffers for the video capture queue. This solves a crash reported by: \thttps://bugzilla.kernel.org/show_bug.cgi?id=219258", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50289", "url": "https://ubuntu.com/security/CVE-2024-50289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: av7110: fix a spectre vulnerability As warned by smatch: \tdrivers/staging/media/av7110/av7110_ca.c:270 dvb_ca_ioctl() warn: potential spectre issue 'av7110->ci_slot' [w] (local cap) There is a spectre-related vulnerability at the code. Fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50290", "url": "https://ubuntu.com/security/CVE-2024-50290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx24116: prevent overflows on SNR calculus as reported by Coverity, if reading SNR registers fail, a negative number will be returned, causing an underflow when reading SNR registers. Prevent that.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53061", "url": "https://ubuntu.com/security/CVE-2024-53061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: s5p-jpeg: prevent buffer overflows The current logic allows word to be less than 2. If this happens, there will be buffer overflows, as reported by smatch. Add extra checks to prevent it. While here, remove an unused word = 0 assignment.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53081", "url": "https://ubuntu.com/security/CVE-2024-53081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ar0521: don't overflow when checking PLL values The PLL checks are comparing 64 bit integers with 32 bit ones, as reported by Coverity. Depending on the values of the variables, this may underflow. Fix it ensuring that both sides of the expression are u64.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53062", "url": "https://ubuntu.com/security/CVE-2024-53062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mgb4: protect driver against spectre Frequency range is set from sysfs via frequency_range_store(), being vulnerable to spectre, as reported by smatch: \tdrivers/media/pci/mgb4/mgb4_cmt.c:231 mgb4_cmt_set_vin_freq_range() warn: potential spectre issue 'cmt_vals_in' [r] \tdrivers/media/pci/mgb4/mgb4_cmt.c:238 mgb4_cmt_set_vin_freq_range() warn: possible spectre second half. 'reg_set' Fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50291", "url": "https://ubuntu.com/security/CVE-2024-50291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvb-core: add missing buffer index check dvb_vb2_expbuf() didn't check if the given buffer index was for a valid buffer. Add this check.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50292", "url": "https://ubuntu.com/security/CVE-2024-50292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: stm32: spdifrx: fix dma channel release in stm32_spdifrx_remove In case of error when requesting ctrl_chan DMA channel, ctrl_chan is not null. So the release of the dma channel leads to the following issue: [ 4.879000] st,stm32-spdifrx 500d0000.audio-controller: dma_request_slave_channel error -19 [ 4.888975] Unable to handle kernel NULL pointer dereference at virtual address 000000000000003d [...] [ 5.096577] Call trace: [ 5.099099] dma_release_channel+0x24/0x100 [ 5.103235] stm32_spdifrx_remove+0x24/0x60 [snd_soc_stm32_spdifrx] [ 5.109494] stm32_spdifrx_probe+0x320/0x4c4 [snd_soc_stm32_spdifrx] To avoid this issue, release channel only if the pointer is valid.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53063", "url": "https://ubuntu.com/security/CVE-2024-53063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvbdev: prevent the risk of out of memory access The dvbdev contains a static variable used to store dvb minors. The behavior of it depends if CONFIG_DVB_DYNAMIC_MINORS is set or not. When not set, dvb_register_device() won't check for boundaries, as it will rely that a previous call to dvb_register_adapter() would already be enforcing it. On a similar way, dvb_device_open() uses the assumption that the register functions already did the needed checks. This can be fragile if some device ends using different calls. This also generate warnings on static check analysers like Coverity. So, add explicit guards to prevent potential risk of OOM issues.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50293", "url": "https://ubuntu.com/security/CVE-2024-50293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: do not leave a dangling sk pointer in __smc_create() Thanks to commit 4bbd360a5084 (\"socket: Print pf->create() when it does not clear sock->sk on failure.\"), syzbot found an issue with AF_SMC: smc_create must clear sock->sk on failure, family: 43, type: 1, protocol: 0 WARNING: CPU: 0 PID: 5827 at net/socket.c:1565 __sock_create+0x96f/0xa30 net/socket.c:1563 Modules linked in: CPU: 0 UID: 0 PID: 5827 Comm: syz-executor259 Not tainted 6.12.0-rc6-next-20241106-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:__sock_create+0x96f/0xa30 net/socket.c:1563 Code: 03 00 74 08 4c 89 e7 e8 4f 3b 85 f8 49 8b 34 24 48 c7 c7 40 89 0c 8d 8b 54 24 04 8b 4c 24 0c 44 8b 44 24 08 e8 32 78 db f7 90 <0f> 0b 90 90 e9 d3 fd ff ff 89 e9 80 e1 07 fe c1 38 c1 0f 8c ee f7 RSP: 0018:ffffc90003e4fda0 EFLAGS: 00010246 RAX: 099c6f938c7f4700 RBX: 1ffffffff1a595fd RCX: ffff888034823c00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 00000000ffffffe9 R08: ffffffff81567052 R09: 1ffff920007c9f50 R10: dffffc0000000000 R11: fffff520007c9f51 R12: ffffffff8d2cafe8 R13: 1ffffffff1a595fe R14: ffffffff9a789c40 R15: ffff8880764298c0 FS: 000055557b518380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa62ff43225 CR3: 0000000031628000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: sock_create net/socket.c:1616 [inline] __sys_socket_create net/socket.c:1653 [inline] __sys_socket+0x150/0x3c0 net/socket.c:1700 __do_sys_socket net/socket.c:1714 [inline] __se_sys_socket net/socket.c:1712 [inline] For reference, see commit 2d859aff775d (\"Merge branch 'do-not-leave-dangling-sk-pointers-in-pf-create-functions'\")", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50294", "url": "https://ubuntu.com/security/CVE-2024-50294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix missing locking causing hanging calls If a call gets aborted (e.g. because kafs saw a signal) between it being queued for connection and the I/O thread picking up the call, the abort will be prioritised over the connection and it will be removed from local->new_client_calls by rxrpc_disconnect_client_call() without a lock being held. This may cause other calls on the list to disappear if a race occurs. Fix this by taking the client_call_lock when removing a call from whatever list its ->wait_link happens to be on.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50295", "url": "https://ubuntu.com/security/CVE-2024-50295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: arc: fix the device for dma_map_single/dma_unmap_single The ndev->dev and pdev->dev aren't the same device, use ndev->dev.parent which has dma_mask, ndev->dev.parent is just pdev->dev. Or it would cause the following issue: [ 39.933526] ------------[ cut here ]------------ [ 39.938414] WARNING: CPU: 1 PID: 501 at kernel/dma/mapping.c:149 dma_map_page_attrs+0x90/0x1f8", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53082", "url": "https://ubuntu.com/security/CVE-2024-53082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_net: Add hash_key_length check Add hash_key_length check in virtnet_probe() to avoid possible out of bound errors when setting/reading the hash key.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50296", "url": "https://ubuntu.com/security/CVE-2024-50296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash when uninstalling driver When the driver is uninstalled and the VF is disabled concurrently, a kernel crash occurs. The reason is that the two actions call function pci_disable_sriov(). The num_VFs is checked to determine whether to release the corresponding resources. During the second calling, num_VFs is not 0 and the resource release function is called. However, the corresponding resource has been released during the first invoking. Therefore, the problem occurs: [15277.839633][T50670] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ... [15278.131557][T50670] Call trace: [15278.134686][T50670] klist_put+0x28/0x12c [15278.138682][T50670] klist_del+0x14/0x20 [15278.142592][T50670] device_del+0xbc/0x3c0 [15278.146676][T50670] pci_remove_bus_device+0x84/0x120 [15278.151714][T50670] pci_stop_and_remove_bus_device+0x6c/0x80 [15278.157447][T50670] pci_iov_remove_virtfn+0xb4/0x12c [15278.162485][T50670] sriov_disable+0x50/0x11c [15278.166829][T50670] pci_disable_sriov+0x24/0x30 [15278.171433][T50670] hnae3_unregister_ae_algo_prepare+0x60/0x90 [hnae3] [15278.178039][T50670] hclge_exit+0x28/0xd0 [hclge] [15278.182730][T50670] __se_sys_delete_module.isra.0+0x164/0x230 [15278.188550][T50670] __arm64_sys_delete_module+0x1c/0x30 [15278.193848][T50670] invoke_syscall+0x50/0x11c [15278.198278][T50670] el0_svc_common.constprop.0+0x158/0x164 [15278.203837][T50670] do_el0_svc+0x34/0xcc [15278.207834][T50670] el0_svc+0x20/0x30 For details, see the following figure. rmmod hclge disable VFs ---------------------------------------------------- hclge_exit() sriov_numvfs_store() ... device_lock() pci_disable_sriov() hns3_pci_sriov_configure() pci_disable_sriov() sriov_disable() sriov_disable() if !num_VFs : if !num_VFs : return; return; sriov_del_vfs() sriov_del_vfs() ... ... klist_put() klist_put() ... ... num_VFs = 0; num_VFs = 0; device_unlock(); In this patch, when driver is removing, we get the device_lock() to protect num_VFs, just like sriov_numvfs_store().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53088", "url": "https://ubuntu.com/security/CVE-2024-53088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: fix race condition by adding filter's intermediate sync state Fix a race condition in the i40e driver that leads to MAC/VLAN filters becoming corrupted and leaking. Address the issue that occurs under heavy load when multiple threads are concurrently modifying MAC/VLAN filters by setting mac and port VLAN. 1. Thread T0 allocates a filter in i40e_add_filter() within i40e_ndo_set_vf_port_vlan(). 2. Thread T1 concurrently frees the filter in __i40e_del_filter() within i40e_ndo_set_vf_mac(). 3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which refers to the already freed filter memory, causing corruption. Reproduction steps: 1. Spawn multiple VFs. 2. Apply a concurrent heavy load by running parallel operations to change MAC addresses on the VFs and change port VLANs on the host. 3. Observe errors in dmesg: \"Error I40E_AQ_RC_ENOSPC adding RX filters on VF XX, \tplease set promiscuous on manually for VF XX\". Exact code for stable reproduction Intel can't open-source now. The fix involves implementing a new intermediate filter state, I40E_FILTER_NEW_SYNC, for the time when a filter is on a tmp_add_list. These filters cannot be deleted from the hash list directly but must be removed using the full process.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50297", "url": "https://ubuntu.com/security/CVE-2024-50297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: xilinx: axienet: Enqueue Tx packets in dql before dmaengine starts Enqueue packets in dql after dma engine starts causes race condition. Tx transfer starts once dma engine is started and may execute dql dequeue in completion before it gets queued. It results in following kernel crash while running iperf stress test: kernel BUG at lib/dynamic_queue_limits.c:99! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP pc : dql_completed+0x238/0x248 lr : dql_completed+0x3c/0x248 Call trace: dql_completed+0x238/0x248 axienet_dma_tx_cb+0xa0/0x170 xilinx_dma_do_tasklet+0xdc/0x290 tasklet_action_common+0xf8/0x11c tasklet_action+0x30/0x3c handle_softirqs+0xf8/0x230 Start dmaengine after enqueue in dql fixes the crash.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50298", "url": "https://ubuntu.com/security/CVE-2024-50298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: enetc: allocate vf_state during PF probes In the previous implementation, vf_state is allocated memory only when VF is enabled. However, net_device_ops::ndo_set_vf_mac() may be called before VF is enabled to configure the MAC address of VF. If this is the case, enetc_pf_set_vf_mac() will access vf_state, resulting in access to a null pointer. The simplified error log is as follows. root@ls1028ardb:~# ip link set eno0 vf 1 mac 00:0c:e7:66:77:89 [ 173.543315] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 [ 173.637254] pc : enetc_pf_set_vf_mac+0x3c/0x80 Message from sy [ 173.641973] lr : do_setlink+0x4a8/0xec8 [ 173.732292] Call trace: [ 173.734740] enetc_pf_set_vf_mac+0x3c/0x80 [ 173.738847] __rtnl_newlink+0x530/0x89c [ 173.742692] rtnl_newlink+0x50/0x7c [ 173.746189] rtnetlink_rcv_msg+0x128/0x390 [ 173.750298] netlink_rcv_skb+0x60/0x130 [ 173.754145] rtnetlink_rcv+0x18/0x24 [ 173.757731] netlink_unicast+0x318/0x380 [ 173.761665] netlink_sendmsg+0x17c/0x3c8", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50299", "url": "https://ubuntu.com/security/CVE-2024-50299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: properly validate chunk size in sctp_sf_ootb() A size validation fix similar to that in Commit 50619dbf8db7 (\"sctp: add size validation when walking chunks\") is also required in sctp_sf_ootb() to address a crash reported by syzbot: BUG: KMSAN: uninit-value in sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_do_sm+0x181/0x93d0 net/sctp/sm_sideeffect.c:1166 sctp_endpoint_bh_rcv+0xc38/0xf90 net/sctp/endpointola.c:407 sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88 sctp_rcv+0x3831/0x3b20 net/sctp/input.c:243 sctp4_rcv+0x42/0x50 net/sctp/protocol.c:1159 ip_protocol_deliver_rcu+0xb51/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50300", "url": "https://ubuntu.com/security/CVE-2024-50300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: rtq2208: Fix uninitialized use of regulator_config Fix rtq2208 driver uninitialized use to cause kernel error.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50301", "url": "https://ubuntu.com/security/CVE-2024-50301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: security/keys: fix slab-out-of-bounds in key_task_permission KASAN reports an out of bounds read: BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline] BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362 CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0x107/0x167 lib/dump_stack.c:123 print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 __kuid_val include/linux/uidgid.h:36 [inline] uid_eq include/linux/uidgid.h:63 [inline] key_task_permission+0x394/0x410 security/keys/permission.c:54 search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793 This issue was also reported by syzbot. It can be reproduced by following these steps(more details [1]): 1. Obtain more than 32 inputs that have similar hashes, which ends with the pattern '0xxxxxxxe6'. 2. Reboot and add the keys obtained in step 1. The reproducer demonstrates how this issue happened: 1. In the search_nested_keyrings function, when it iterates through the slots in a node(below tag ascend_to_node), if the slot pointer is meta and node->back_pointer != NULL(it means a root), it will proceed to descend_to_node. However, there is an exception. If node is the root, and one of the slots points to a shortcut, it will be treated as a keyring. 2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function. However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as ASSOC_ARRAY_PTR_SUBTYPE_MASK. 3. When 32 keys with the similar hashes are added to the tree, the ROOT has keys with hashes that are not similar (e.g. slot 0) and it splits NODE A without using a shortcut. When NODE A is filled with keys that all hashes are xxe6, the keys are similar, NODE A will split with a shortcut. Finally, it forms the tree as shown below, where slot 6 points to a shortcut. NODE A +------>+---+ ROOT | | 0 | xxe6 +---+ | +---+ xxxx | 0 | shortcut : : xxe6 +---+ | +---+ xxe6 : : | | | xxe6 +---+ | +---+ | 6 |---+ : : xxe6 +---+ +---+ xxe6 : : | f | xxe6 +---+ +---+ xxe6 | f | +---+ 4. As mentioned above, If a slot(slot 6) of the root points to a shortcut, it may be mistakenly transferred to a key*, leading to a read out-of-bounds read. To fix this issue, one should jump to descend_to_node if the ptr is a shortcut, regardless of whether the node is root or not. [1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/ [jarkko: tweaked the commit message a bit to have an appropriate closes tag.]", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53072", "url": "https://ubuntu.com/security/CVE-2024-53072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/pmc: Detect when STB is not available Loading the amd_pmc module as: amd_pmc enable_stb=1 ...can result in the following messages in the kernel ring buffer: amd_pmc AMDI0009:00: SMU cmd failed. err: 0xff ioremap on RAM at 0x0000000000000000 - 0x0000000000ffffff WARNING: CPU: 10 PID: 2151 at arch/x86/mm/ioremap.c:217 __ioremap_caller+0x2cd/0x340 Further debugging reveals that this occurs when the requests for S2D_PHYS_ADDR_LOW and S2D_PHYS_ADDR_HIGH return a value of 0, indicating that the STB is inaccessible. To prevent the ioremap warning and provide clarity to the user, handle the invalid address and display an error message.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50302", "url": "https://ubuntu.com/security/CVE-2024-50302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: zero-initialize the report buffer Since the report buffer is used by all kinds of drivers in various ways, let's zero-initialize it during allocation to make sure that it can't be ever used to leak kernel memory via specially-crafted report.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53068", "url": "https://ubuntu.com/security/CVE-2024-53068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix slab-use-after-free in scmi_bus_notifier() The scmi_dev->name is released prematurely in __scmi_device_destroy(), which causes slab-use-after-free when accessing scmi_dev->name in scmi_bus_notifier(). So move the release of scmi_dev->name to scmi_device_release() to avoid slab-use-after-free. | BUG: KASAN: slab-use-after-free in strncmp+0xe4/0xec | Read of size 1 at addr ffffff80a482bcc0 by task swapper/0/1 | | CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.6.38-debug #1 | Hardware name: Qualcomm Technologies, Inc. SA8775P Ride (DT) | Call trace: | dump_backtrace+0x94/0x114 | show_stack+0x18/0x24 | dump_stack_lvl+0x48/0x60 | print_report+0xf4/0x5b0 | kasan_report+0xa4/0xec | __asan_report_load1_noabort+0x20/0x2c | strncmp+0xe4/0xec | scmi_bus_notifier+0x5c/0x54c | notifier_call_chain+0xb4/0x31c | blocking_notifier_call_chain+0x68/0x9c | bus_notify+0x54/0x78 | device_del+0x1bc/0x840 | device_unregister+0x20/0xb4 | __scmi_device_destroy+0xac/0x280 | scmi_device_destroy+0x94/0xd0 | scmi_chan_setup+0x524/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20 | | Allocated by task 1: | kasan_save_stack+0x2c/0x54 | kasan_set_track+0x2c/0x40 | kasan_save_alloc_info+0x24/0x34 | __kasan_kmalloc+0xa0/0xb8 | __kmalloc_node_track_caller+0x6c/0x104 | kstrdup+0x48/0x84 | kstrdup_const+0x34/0x40 | __scmi_device_create.part.0+0x8c/0x408 | scmi_device_create+0x104/0x370 | scmi_chan_setup+0x2a0/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20 | | Freed by task 1: | kasan_save_stack+0x2c/0x54 | kasan_set_track+0x2c/0x40 | kasan_save_free_info+0x38/0x5c | __kasan_slab_free+0xe8/0x164 | __kmem_cache_free+0x11c/0x230 | kfree+0x70/0x130 | kfree_const+0x20/0x40 | __scmi_device_destroy+0x70/0x280 | scmi_device_destroy+0x94/0xd0 | scmi_chan_setup+0x524/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53069", "url": "https://ubuntu.com/security/CVE-2024-53069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: qcom: scm: fix a NULL-pointer dereference Some SCM calls can be invoked with __scm being NULL (the driver may not have been and will not be probed as there's no SCM entry in device-tree). Make sure we don't dereference a NULL pointer.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50212", "url": "https://ubuntu.com/security/CVE-2024-50212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib: alloc_tag_module_unload must wait for pending kfree_rcu calls Ben Greear reports following splat: ------------[ cut here ]------------ net/netfilter/nf_nat_core.c:1114 module nf_nat func:nf_nat_register_fn has 256 allocated at module unload WARNING: CPU: 1 PID: 10421 at lib/alloc_tag.c:168 alloc_tag_module_unload+0x22b/0x3f0 Modules linked in: nf_nat(-) btrfs ufs qnx4 hfsplus hfs minix vfat msdos fat ... Hardware name: Default string Default string/SKYBAY, BIOS 5.12 08/04/2020 RIP: 0010:alloc_tag_module_unload+0x22b/0x3f0 codetag_unload_module+0x19b/0x2a0 ? codetag_load_module+0x80/0x80 nf_nat module exit calls kfree_rcu on those addresses, but the free operation is likely still pending by the time alloc_tag checks for leaks. Wait for outstanding kfree_rcu operations to complete before checking resolves this warning. Reproducer: unshare -n iptables-nft -t nat -A PREROUTING -p tcp grep nf_nat /proc/allocinfo # will list 4 allocations rmmod nft_chain_nat rmmod nf_nat # will WARN. [akpm@linux-foundation.org: add comment]", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53046", "url": "https://ubuntu.com/security/CVE-2024-53046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: dts: imx8ulp: correct the flexspi compatible string The flexspi on imx8ulp only has 16 LUTs, and imx8mm flexspi has 32 LUTs, so correct the compatible string here, otherwise will meet below error: [ 1.119072] ------------[ cut here ]------------ [ 1.123926] WARNING: CPU: 0 PID: 1 at drivers/spi/spi-nxp-fspi.c:855 nxp_fspi_exec_op+0xb04/0xb64 [ 1.133239] Modules linked in: [ 1.136448] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-rc6-next-20240902-00001-g131bf9439dd9 #69 [ 1.146821] Hardware name: NXP i.MX8ULP EVK (DT) [ 1.151647] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.158931] pc : nxp_fspi_exec_op+0xb04/0xb64 [ 1.163496] lr : nxp_fspi_exec_op+0xa34/0xb64 [ 1.168060] sp : ffff80008002b2a0 [ 1.171526] x29: ffff80008002b2d0 x28: 0000000000000000 x27: 0000000000000000 [ 1.179002] x26: ffff2eb645542580 x25: ffff800080610014 x24: ffff800080610000 [ 1.186480] x23: ffff2eb645548080 x22: 0000000000000006 x21: ffff2eb6455425e0 [ 1.193956] x20: 0000000000000000 x19: ffff80008002b5e0 x18: ffffffffffffffff [ 1.201432] x17: ffff2eb644467508 x16: 0000000000000138 x15: 0000000000000002 [ 1.208907] x14: 0000000000000000 x13: ffff2eb6400d8080 x12: 00000000ffffff00 [ 1.216378] x11: 0000000000000000 x10: ffff2eb6400d8080 x9 : ffff2eb697adca80 [ 1.223850] x8 : ffff2eb697ad3cc0 x7 : 0000000100000000 x6 : 0000000000000001 [ 1.231324] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000007a6 [ 1.238795] x2 : 0000000000000000 x1 : 00000000000001ce x0 : 00000000ffffff92 [ 1.246267] Call trace: [ 1.248824] nxp_fspi_exec_op+0xb04/0xb64 [ 1.253031] spi_mem_exec_op+0x3a0/0x430 [ 1.257139] spi_nor_read_id+0x80/0xcc [ 1.261065] spi_nor_scan+0x1ec/0xf10 [ 1.264901] spi_nor_probe+0x108/0x2fc [ 1.268828] spi_mem_probe+0x6c/0xbc [ 1.272574] spi_probe+0x84/0xe4 [ 1.275958] really_probe+0xbc/0x29c [ 1.279713] __driver_probe_device+0x78/0x12c [ 1.284277] driver_probe_device+0xd8/0x15c [ 1.288660] __device_attach_driver+0xb8/0x134 [ 1.293316] bus_for_each_drv+0x88/0xe8 [ 1.297337] __device_attach+0xa0/0x190 [ 1.301353] device_initial_probe+0x14/0x20 [ 1.305734] bus_probe_device+0xac/0xb0 [ 1.309752] device_add+0x5d0/0x790 [ 1.313408] __spi_add_device+0x134/0x204 [ 1.317606] of_register_spi_device+0x3b4/0x590 [ 1.322348] spi_register_controller+0x47c/0x754 [ 1.327181] devm_spi_register_controller+0x4c/0xa4 [ 1.332289] nxp_fspi_probe+0x1cc/0x2b0 [ 1.336307] platform_probe+0x68/0xc4 [ 1.340145] really_probe+0xbc/0x29c [ 1.343893] __driver_probe_device+0x78/0x12c [ 1.348457] driver_probe_device+0xd8/0x15c [ 1.352838] __driver_attach+0x90/0x19c [ 1.356857] bus_for_each_dev+0x7c/0xdc [ 1.360877] driver_attach+0x24/0x30 [ 1.364624] bus_add_driver+0xe4/0x208 [ 1.368552] driver_register+0x5c/0x124 [ 1.372573] __platform_driver_register+0x28/0x34 [ 1.377497] nxp_fspi_driver_init+0x1c/0x28 [ 1.381888] do_one_initcall+0x80/0x1c8 [ 1.385908] kernel_init_freeable+0x1c4/0x28c [ 1.390472] kernel_init+0x20/0x1d8 [ 1.394138] ret_from_fork+0x10/0x20 [ 1.397885] ---[ end trace 0000000000000000 ]--- [ 1.407908] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53052", "url": "https://ubuntu.com/security/CVE-2024-53052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/rw: fix missing NOWAIT check for O_DIRECT start write When io_uring starts a write, it'll call kiocb_start_write() to bump the super block rwsem, preventing any freezes from happening while that write is in-flight. The freeze side will grab that rwsem for writing, excluding any new writers from happening and waiting for existing writes to finish. But io_uring unconditionally uses kiocb_start_write(), which will block if someone is currently attempting to freeze the mount point. This causes a deadlock where freeze is waiting for previous writes to complete, but the previous writes cannot complete, as the task that is supposed to complete them is blocked waiting on starting a new write. This results in the following stuck trace showing that dependency with the write blocked starting a new write: task:fio state:D stack:0 pid:886 tgid:886 ppid:876 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_rwsem_wait+0x1e8/0x3f8 __percpu_down_read+0xe8/0x500 io_write+0xbb8/0xff8 io_issue_sqe+0x10c/0x1020 io_submit_sqes+0x614/0x2110 __arm64_sys_io_uring_enter+0x524/0x1038 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 INFO: task fsfreeze:7364 blocked for more than 15 seconds. Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963 with the attempting freezer stuck trying to grab the rwsem: task:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_down_write+0x2b0/0x680 freeze_super+0x248/0x8a8 do_vfs_ioctl+0x149c/0x1b18 __arm64_sys_ioctl+0xd0/0x1a0 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 Fix this by having the io_uring side honor IOCB_NOWAIT, and only attempt a blocking grab of the super block rwsem if it isn't set. For normal issue where IOCB_NOWAIT would always be set, this returns -EAGAIN which will have io_uring core issue a blocking attempt of the write. That will in turn also get completions run, ensuring forward progress. Since freezing requires CAP_SYS_ADMIN in the first place, this isn't something that can be triggered by a regular user.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50213", "url": "https://ubuntu.com/security/CVE-2024-50213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tests: hdmi: Fix memory leaks in drm_display_mode_from_cea_vic() modprobe drm_hdmi_state_helper_test and then rmmod it, the following memory leak occurs. The `mode` allocated in drm_mode_duplicate() called by drm_display_mode_from_cea_vic() is not freed, which cause the memory leak: \tunreferenced object 0xffffff80ccd18100 (size 128): \t comm \"kunit_try_catch\", pid 1851, jiffies 4295059695 \t hex dump (first 32 bytes): \t 57 62 00 00 80 02 90 02 f0 02 20 03 00 00 e0 01 Wb........ ..... \t ea 01 ec 01 0d 02 00 00 0a 00 00 00 00 00 00 00 ................ \t backtrace (crc c2f1aa95): \t [<000000000f10b11b>] kmemleak_alloc+0x34/0x40 \t [<000000001cd4cf73>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<00000000f1f3cffa>] drm_mode_duplicate+0x44/0x19c \t [<000000008cbeef13>] drm_display_mode_from_cea_vic+0x88/0x98 \t [<0000000019daaacf>] 0xffffffedc11ae69c \t [<000000000aad0f85>] kunit_try_run_case+0x13c/0x3ac \t [<00000000a9210bac>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<000000000a0b2e9e>] kthread+0x2e8/0x374 \t [<00000000bd668858>] ret_from_fork+0x10/0x20 \t...... Free `mode` by using drm_kunit_display_mode_from_cea_vic() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50214", "url": "https://ubuntu.com/security/CVE-2024-50214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/connector: hdmi: Fix memory leak in drm_display_mode_from_cea_vic() modprobe drm_connector_test and then rmmod drm_connector_test, the following memory leak occurs. The `mode` allocated in drm_mode_duplicate() called by drm_display_mode_from_cea_vic() is not freed, which cause the memory leak: \tunreferenced object 0xffffff80cb0ee400 (size 128): \t comm \"kunit_try_catch\", pid 1948, jiffies 4294950339 \t hex dump (first 32 bytes): \t 14 44 02 00 80 07 d8 07 04 08 98 08 00 00 38 04 .D............8. \t 3c 04 41 04 65 04 00 00 05 00 00 00 00 00 00 00 <.A.e........... \t backtrace (crc 90e9585c): \t [<00000000ec42e3d7>] kmemleak_alloc+0x34/0x40 \t [<00000000d0ef055a>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<00000000c2062161>] drm_mode_duplicate+0x44/0x19c \t [<00000000f96c74aa>] drm_display_mode_from_cea_vic+0x88/0x98 \t [<00000000d8f2c8b4>] 0xffffffdc982a4868 \t [<000000005d164dbc>] kunit_try_run_case+0x13c/0x3ac \t [<000000006fb23398>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<000000006ea56ca0>] kthread+0x2e8/0x374 \t [<000000000676063f>] ret_from_fork+0x10/0x20 \t...... Free `mode` by using drm_kunit_display_mode_from_cea_vic() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50215", "url": "https://ubuntu.com/security/CVE-2024-50215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: assign dh_key to NULL after kfree_sensitive ctrl->dh_key might be used across multiple calls to nvmet_setup_dhgroup() for the same controller. So it's better to nullify it after release on error path in order to avoid double free later in nvmet_destroy_auth(). Found by Linux Verification Center (linuxtesting.org) with Svace.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50216", "url": "https://ubuntu.com/security/CVE-2024-50216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix finding a last resort AG in xfs_filestream_pick_ag When the main loop in xfs_filestream_pick_ag fails to find a suitable AG it tries to just pick the online AG. But the loop for that uses args->pag as loop iterator while the later code expects pag to be set. Fix this by reusing the max_pag case for this last resort, and also add a check for impossible case of no AG just to make sure that the uninitialized pag doesn't even escape in theory.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50217", "url": "https://ubuntu.com/security/CVE-2024-50217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free of block device file in __btrfs_free_extra_devids() Mounting btrfs from two images (which have the same one fsid and two different dev_uuids) in certain executing order may trigger an UAF for variable 'device->bdev_file' in __btrfs_free_extra_devids(). And following are the details: 1. Attach image_1 to loop0, attach image_2 to loop1, and scan btrfs devices by ioctl(BTRFS_IOC_SCAN_DEV): / btrfs_device_1 ? loop0 fs_device \\ btrfs_device_2 ? loop1 2. mount /dev/loop0 /mnt btrfs_open_devices btrfs_device_1->bdev_file = btrfs_get_bdev_and_sb(loop0) btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree fail: btrfs_close_devices // -ENOMEM \t btrfs_close_bdev(btrfs_device_1) fput(btrfs_device_1->bdev_file) \t // btrfs_device_1->bdev_file is freed \t btrfs_close_bdev(btrfs_device_2) fput(btrfs_device_2->bdev_file) 3. mount /dev/loop1 /mnt btrfs_open_devices btrfs_get_bdev_and_sb(&bdev_file) // EIO, btrfs_device_1->bdev_file is not assigned, // which points to a freed memory area btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree btrfs_free_extra_devids if (btrfs_device_1->bdev_file) fput(btrfs_device_1->bdev_file) // UAF ! Fix it by setting 'device->bdev_file' as 'NULL' after closing the btrfs_device in btrfs_close_one_device().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53043", "url": "https://ubuntu.com/security/CVE-2024-53043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mctp i2c: handle NULL header address daddr can be NULL if there is no neighbour table entry present, in that case the tx packet should be dropped. saddr will usually be set by MCTP core, but check for NULL in case a packet is transmitted by a different protocol.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50303", "url": "https://ubuntu.com/security/CVE-2024-50303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: resource,kexec: walk_system_ram_res_rev must retain resource flags walk_system_ram_res_rev() erroneously discards resource flags when passing the information to the callback. This causes systems with IORESOURCE_SYSRAM_DRIVER_MANAGED memory to have these resources selected during kexec to store kexec buffers if that memory happens to be at placed above normal system ram. This leads to undefined behavior after reboot. If the kexec buffer is never touched, nothing happens. If the kexec buffer is touched, it could lead to a crash (like below) or undefined behavior. Tested on a system with CXL memory expanders with driver managed memory, TPM enabled, and CONFIG_IMA_KEXEC=y. Adding printk's showed the flags were being discarded and as a result the check for IORESOURCE_SYSRAM_DRIVER_MANAGED passes. find_next_iomem_res: name(System RAM (kmem)) \t\t start(10000000000) \t\t end(1034fffffff) \t\t flags(83000200) locate_mem_hole_top_down: start(10000000000) end(1034fffffff) flags(0) [.] BUG: unable to handle page fault for address: ffff89834ffff000 [.] #PF: supervisor read access in kernel mode [.] #PF: error_code(0x0000) - not-present page [.] PGD c04c8bf067 P4D c04c8bf067 PUD c04c8be067 PMD 0 [.] Oops: 0000 [#1] SMP [.] RIP: 0010:ima_restore_measurement_list+0x95/0x4b0 [.] RSP: 0018:ffffc900000d3a80 EFLAGS: 00010286 [.] RAX: 0000000000001000 RBX: 0000000000000000 RCX: ffff89834ffff000 [.] RDX: 0000000000000018 RSI: ffff89834ffff000 RDI: ffff89834ffff018 [.] RBP: ffffc900000d3ba0 R08: 0000000000000020 R09: ffff888132b8a900 [.] R10: 4000000000000000 R11: 000000003a616d69 R12: 0000000000000000 [.] R13: ffffffff8404ac28 R14: 0000000000000000 R15: ffff89834ffff000 [.] FS: 0000000000000000(0000) GS:ffff893d44640000(0000) knlGS:0000000000000000 [.] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [.] ata5: SATA link down (SStatus 0 SControl 300) [.] CR2: ffff89834ffff000 CR3: 000001034d00f001 CR4: 0000000000770ef0 [.] PKRU: 55555554 [.] Call Trace: [.] [.] ? __die+0x78/0xc0 [.] ? page_fault_oops+0x2a8/0x3a0 [.] ? exc_page_fault+0x84/0x130 [.] ? asm_exc_page_fault+0x22/0x30 [.] ? ima_restore_measurement_list+0x95/0x4b0 [.] ? template_desc_init_fields+0x317/0x410 [.] ? crypto_alloc_tfm_node+0x9c/0xc0 [.] ? init_ima_lsm+0x30/0x30 [.] ima_load_kexec_buffer+0x72/0xa0 [.] ima_init+0x44/0xa0 [.] __initstub__kmod_ima__373_1201_init_ima7+0x1e/0xb0 [.] ? init_ima_lsm+0x30/0x30 [.] do_one_initcall+0xad/0x200 [.] ? idr_alloc_cyclic+0xaa/0x110 [.] ? new_slab+0x12c/0x420 [.] ? new_slab+0x12c/0x420 [.] ? number+0x12a/0x430 [.] ? sysvec_apic_timer_interrupt+0xa/0x80 [.] ? asm_sysvec_apic_timer_interrupt+0x16/0x20 [.] ? parse_args+0xd4/0x380 [.] ? parse_args+0x14b/0x380 [.] kernel_init_freeable+0x1c1/0x2b0 [.] ? rest_init+0xb0/0xb0 [.] kernel_init+0x16/0x1a0 [.] ret_from_fork+0x2f/0x40 [.] ? rest_init+0xb0/0xb0 [.] ret_from_fork_asm+0x11/0x20 [.] ", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50218", "url": "https://ubuntu.com/security/CVE-2024-50218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow Syzbot reported a kernel BUG in ocfs2_truncate_inline. There are two reasons for this: first, the parameter value passed is greater than ocfs2_max_inline_data_with_xattr, second, the start and end parameters of ocfs2_truncate_inline are \"unsigned int\". So, we need to add a sanity check for byte_start and byte_len right before ocfs2_truncate_inline() in ocfs2_remove_inode_range(), if they are greater than ocfs2_max_inline_data_with_xattr return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50219", "url": "https://ubuntu.com/security/CVE-2024-50219", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50263", "url": "https://ubuntu.com/security/CVE-2024-50263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fork: only invoke khugepaged, ksm hooks if no error There is no reason to invoke these hooks early against an mm that is in an incomplete state. The change in commit d24062914837 (\"fork: use __mt_dup() to duplicate maple tree in dup_mmap()\") makes this more pertinent as we may be in a state where entries in the maple tree are not yet consistent. Their placement early in dup_mmap() only appears to have been meaningful for early error checking, and since functionally it'd require a very small allocation to fail (in practice 'too small to fail') that'd only occur in the most dire circumstances, meaning the fork would fail or be OOM'd in any case. Since both khugepaged and KSM tracking are there to provide optimisations to memory performance rather than critical functionality, it doesn't really matter all that much if, under such dire memory pressure, we fail to register an mm with these. As a result, we follow the example of commit d2081b2bf819 (\"mm: khugepaged: make khugepaged_enter() void function\") and make ksm_fork() a void function also. We only expose the mm to these functions once we are done with them and only if no error occurred in the fork operation.", "cve_priority": "medium", "cve_public_date": "2024-11-11 14:15:00 UTC" }, { "cve": "CVE-2024-50220", "url": "https://ubuntu.com/security/CVE-2024-50220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fork: do not invoke uffd on fork if error occurs Patch series \"fork: do not expose incomplete mm on fork\". During fork we may place the virtual memory address space into an inconsistent state before the fork operation is complete. In addition, we may encounter an error during the fork operation that indicates that the virtual memory address space is invalidated. As a result, we should not be exposing it in any way to external machinery that might interact with the mm or VMAs, machinery that is not designed to deal with incomplete state. We specifically update the fork logic to defer khugepaged and ksm to the end of the operation and only to be invoked if no error arose, and disallow uffd from observing fork events should an error have occurred. This patch (of 2): Currently on fork we expose the virtual address space of a process to userland unconditionally if uffd is registered in VMAs, regardless of whether an error arose in the fork. This is performed in dup_userfaultfd_complete() which is invoked unconditionally, and performs two duties - invoking registered handlers for the UFFD_EVENT_FORK event via dup_fctx(), and clearing down userfaultfd_fork_ctx objects established in dup_userfaultfd(). This is problematic, because the virtual address space may not yet be correctly initialised if an error arose. The change in commit d24062914837 (\"fork: use __mt_dup() to duplicate maple tree in dup_mmap()\") makes this more pertinent as we may be in a state where entries in the maple tree are not yet consistent. We address this by, on fork error, ensuring that we roll back state that we would otherwise expect to clean up through the event being handled by userland and perform the memory freeing duty otherwise performed by dup_userfaultfd_complete(). We do this by implementing a new function, dup_userfaultfd_fail(), which performs the same loop, only decrementing reference counts. Note that we perform mmgrab() on the parent and child mm's, however userfaultfd_ctx_put() will mmdrop() this once the reference count drops to zero, so we will avoid memory leaks correctly here.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53047", "url": "https://ubuntu.com/security/CVE-2024-53047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: init: protect sched with rcu_read_lock Enabling CONFIG_PROVE_RCU_LIST with its dependence CONFIG_RCU_EXPERT creates this splat when an MPTCP socket is created: ============================= WARNING: suspicious RCU usage 6.12.0-rc2+ #11 Not tainted ----------------------------- net/mptcp/sched.c:44 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 no locks held by mptcp_connect/176. stack backtrace: CPU: 0 UID: 0 PID: 176 Comm: mptcp_connect Not tainted 6.12.0-rc2+ #11 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl (lib/dump_stack.c:123) lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822) mptcp_sched_find (net/mptcp/sched.c:44 (discriminator 7)) mptcp_init_sock (net/mptcp/protocol.c:2867 (discriminator 1)) ? sock_init_data_uid (arch/x86/include/asm/atomic.h:28) inet_create.part.0.constprop.0 (net/ipv4/af_inet.c:386) ? __sock_create (include/linux/rcupdate.h:347 (discriminator 1)) __sock_create (net/socket.c:1576) __sys_socket (net/socket.c:1671) ? __pfx___sys_socket (net/socket.c:1712) ? do_user_addr_fault (arch/x86/mm/fault.c:1419 (discriminator 1)) __x64_sys_socket (net/socket.c:1728) do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) That's because when the socket is initialised, rcu_read_lock() is not used despite the explicit comment written above the declaration of mptcp_sched_find() in sched.c. Adding the missing lock/unlock avoids the warning.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50221", "url": "https://ubuntu.com/security/CVE-2024-50221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Vangogh: Fix kernel memory out of bounds write KASAN reports that the GPU metrics table allocated in vangogh_tables_init() is not large enough for the memset done in smu_cmn_init_soft_gpu_metrics(). Condensed report follows: [ 33.861314] BUG: KASAN: slab-out-of-bounds in smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu] [ 33.861799] Write of size 168 at addr ffff888129f59500 by task mangoapp/1067 ... [ 33.861808] CPU: 6 UID: 1000 PID: 1067 Comm: mangoapp Tainted: G W 6.12.0-rc4 #356 1a56f59a8b5182eeaf67eb7cb8b13594dd23b544 [ 33.861816] Tainted: [W]=WARN [ 33.861818] Hardware name: Valve Galileo/Galileo, BIOS F7G0107 12/01/2023 [ 33.861822] Call Trace: [ 33.861826] [ 33.861829] dump_stack_lvl+0x66/0x90 [ 33.861838] print_report+0xce/0x620 [ 33.861853] kasan_report+0xda/0x110 [ 33.862794] kasan_check_range+0xfd/0x1a0 [ 33.862799] __asan_memset+0x23/0x40 [ 33.862803] smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.863306] vangogh_get_gpu_metrics_v2_4+0x123/0xad0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.864257] vangogh_common_get_gpu_metrics+0xb0c/0xbc0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.865682] amdgpu_dpm_get_gpu_metrics+0xcc/0x110 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.866160] amdgpu_get_gpu_metrics+0x154/0x2d0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.867135] dev_attr_show+0x43/0xc0 [ 33.867147] sysfs_kf_seq_show+0x1f1/0x3b0 [ 33.867155] seq_read_iter+0x3f8/0x1140 [ 33.867173] vfs_read+0x76c/0xc50 [ 33.867198] ksys_read+0xfb/0x1d0 [ 33.867214] do_syscall_64+0x90/0x160 ... [ 33.867353] Allocated by task 378 on cpu 7 at 22.794876s: [ 33.867358] kasan_save_stack+0x33/0x50 [ 33.867364] kasan_save_track+0x17/0x60 [ 33.867367] __kasan_kmalloc+0x87/0x90 [ 33.867371] vangogh_init_smc_tables+0x3f9/0x840 [amdgpu] [ 33.867835] smu_sw_init+0xa32/0x1850 [amdgpu] [ 33.868299] amdgpu_device_init+0x467b/0x8d90 [amdgpu] [ 33.868733] amdgpu_driver_load_kms+0x19/0xf0 [amdgpu] [ 33.869167] amdgpu_pci_probe+0x2d6/0xcd0 [amdgpu] [ 33.869608] local_pci_probe+0xda/0x180 [ 33.869614] pci_device_probe+0x43f/0x6b0 Empirically we can confirm that the former allocates 152 bytes for the table, while the latter memsets the 168 large block. Root cause appears that when GPU metrics tables for v2_4 parts were added it was not considered to enlarge the table to fit. The fix in this patch is rather \"brute force\" and perhaps later should be done in a smarter way, by extracting and consolidating the part version to size logic to a common helper, instead of brute forcing the largest possible allocation. Nevertheless, for now this works and fixes the out of bounds write. v2: * Drop impossible v3_0 case. (Mario) (cherry picked from commit 0880f58f9609f0200483a49429af0f050d281703)", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50222", "url": "https://ubuntu.com/security/CVE-2024-50222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iov_iter: fix copy_page_from_iter_atomic() if KMAP_LOCAL_FORCE_MAP generic/077 on x86_32 CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP=y with highmem, on huge=always tmpfs, issues a warning and then hangs (interruptibly): WARNING: CPU: 5 PID: 3517 at mm/highmem.c:622 kunmap_local_indexed+0x62/0xc9 CPU: 5 UID: 0 PID: 3517 Comm: cp Not tainted 6.12.0-rc4 #2 ... copy_page_from_iter_atomic+0xa6/0x5ec generic_perform_write+0xf6/0x1b4 shmem_file_write_iter+0x54/0x67 Fix copy_page_from_iter_atomic() by limiting it in that case (include/linux/skbuff.h skb_frag_must_loop() does similar). But going forward, perhaps CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP is too surprising, has outlived its usefulness, and should just be removed?", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50223", "url": "https://ubuntu.com/security/CVE-2024-50223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/numa: Fix the potential null pointer dereference in task_numa_work() When running stress-ng-vm-segv test, we found a null pointer dereference error in task_numa_work(). Here is the backtrace: [323676.066985] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ...... [323676.067108] CPU: 35 PID: 2694524 Comm: stress-ng-vm-se ...... [323676.067113] pstate: 23401009 (nzCv daif +PAN -UAO +TCO +DIT +SSBS BTYPE=--) [323676.067115] pc : vma_migratable+0x1c/0xd0 [323676.067122] lr : task_numa_work+0x1ec/0x4e0 [323676.067127] sp : ffff8000ada73d20 [323676.067128] x29: ffff8000ada73d20 x28: 0000000000000000 x27: 000000003e89f010 [323676.067130] x26: 0000000000080000 x25: ffff800081b5c0d8 x24: ffff800081b27000 [323676.067133] x23: 0000000000010000 x22: 0000000104d18cc0 x21: ffff0009f7158000 [323676.067135] x20: 0000000000000000 x19: 0000000000000000 x18: ffff8000ada73db8 [323676.067138] x17: 0001400000000000 x16: ffff800080df40b0 x15: 0000000000000035 [323676.067140] x14: ffff8000ada73cc8 x13: 1fffe0017cc72001 x12: ffff8000ada73cc8 [323676.067142] x11: ffff80008001160c x10: ffff000be639000c x9 : ffff8000800f4ba4 [323676.067145] x8 : ffff000810375000 x7 : ffff8000ada73974 x6 : 0000000000000001 [323676.067147] x5 : 0068000b33e26707 x4 : 0000000000000001 x3 : ffff0009f7158000 [323676.067149] x2 : 0000000000000041 x1 : 0000000000004400 x0 : 0000000000000000 [323676.067152] Call trace: [323676.067153] vma_migratable+0x1c/0xd0 [323676.067155] task_numa_work+0x1ec/0x4e0 [323676.067157] task_work_run+0x78/0xd8 [323676.067161] do_notify_resume+0x1ec/0x290 [323676.067163] el0_svc+0x150/0x160 [323676.067167] el0t_64_sync_handler+0xf8/0x128 [323676.067170] el0t_64_sync+0x17c/0x180 [323676.067173] Code: d2888001 910003fd f9000bf3 aa0003f3 (f9401000) [323676.067177] SMP: stopping secondary CPUs [323676.070184] Starting crashdump kernel... stress-ng-vm-segv in stress-ng is used to stress test the SIGSEGV error handling function of the system, which tries to cause a SIGSEGV error on return from unmapping the whole address space of the child process. Normally this program will not cause kernel crashes. But before the munmap system call returns to user mode, a potential task_numa_work() for numa balancing could be added and executed. In this scenario, since the child process has no vma after munmap, the vma_next() in task_numa_work() will return a null pointer even if the vma iterator restarts from 0. Recheck the vma pointer before dereferencing it in task_numa_work().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53053", "url": "https://ubuntu.com/security/CVE-2024-53053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Fix another deadlock during RTC update If ufshcd_rtc_work calls ufshcd_rpm_put_sync() and the pm's usage_count is 0, we will enter the runtime suspend callback. However, the runtime suspend callback will wait to flush ufshcd_rtc_work, causing a deadlock. Replace ufshcd_rpm_put_sync() with ufshcd_rpm_put() to avoid the deadlock.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53075", "url": "https://ubuntu.com/security/CVE-2024-53075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv: Prevent a bad reference count on CPU nodes When populating cache leaves we previously fetched the CPU device node at the very beginning. But when ACPI is enabled we go through a specific branch which returns early and does not call 'of_node_put' for the node that was acquired. Since we are not using a CPU device node for the ACPI code anyways, we can simply move the initialization of it just passed the ACPI block, and we are guaranteed to have an 'of_node_put' call for the acquired node. This prevents a bad reference count of the CPU device node. Moreover, the previous function did not check for errors when acquiring the device node, so a return -ENOENT has been added for that case.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50224", "url": "https://ubuntu.com/security/CVE-2024-50224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: spi-fsl-dspi: Fix crash when not using GPIO chip select Add check for the return value of spi_get_csgpiod() to avoid passing a NULL pointer to gpiod_direction_output(), preventing a crash when GPIO chip select is not used. Fix below crash: [ 4.251960] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 4.260762] Mem abort info: [ 4.263556] ESR = 0x0000000096000004 [ 4.267308] EC = 0x25: DABT (current EL), IL = 32 bits [ 4.272624] SET = 0, FnV = 0 [ 4.275681] EA = 0, S1PTW = 0 [ 4.278822] FSC = 0x04: level 0 translation fault [ 4.283704] Data abort info: [ 4.286583] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 4.292074] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 4.297130] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 4.302445] [0000000000000000] user address but active_mm is swapper [ 4.308805] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 4.315072] Modules linked in: [ 4.318124] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc4-next-20241023-00008-ga20ec42c5fc1 #359 [ 4.328130] Hardware name: LS1046A QDS Board (DT) [ 4.332832] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 4.339794] pc : gpiod_direction_output+0x34/0x5c [ 4.344505] lr : gpiod_direction_output+0x18/0x5c [ 4.349208] sp : ffff80008003b8f0 [ 4.352517] x29: ffff80008003b8f0 x28: 0000000000000000 x27: ffffc96bcc7e9068 [ 4.359659] x26: ffffc96bcc6e00b0 x25: ffffc96bcc598398 x24: ffff447400132810 [ 4.366800] x23: 0000000000000000 x22: 0000000011e1a300 x21: 0000000000020002 [ 4.373940] x20: 0000000000000000 x19: 0000000000000000 x18: ffffffffffffffff [ 4.381081] x17: ffff44740016e600 x16: 0000000500000003 x15: 0000000000000007 [ 4.388221] x14: 0000000000989680 x13: 0000000000020000 x12: 000000000000001e [ 4.395362] x11: 0044b82fa09b5a53 x10: 0000000000000019 x9 : 0000000000000008 [ 4.402502] x8 : 0000000000000002 x7 : 0000000000000007 x6 : 0000000000000000 [ 4.409641] x5 : 0000000000000200 x4 : 0000000002000000 x3 : 0000000000000000 [ 4.416781] x2 : 0000000000022202 x1 : 0000000000000000 x0 : 0000000000000000 [ 4.423921] Call trace: [ 4.426362] gpiod_direction_output+0x34/0x5c (P) [ 4.431067] gpiod_direction_output+0x18/0x5c (L) [ 4.435771] dspi_setup+0x220/0x334", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50225", "url": "https://ubuntu.com/security/CVE-2024-50225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix error propagation of split bios The purpose of btrfs_bbio_propagate_error() shall be propagating an error of split bio to its original btrfs_bio, and tell the error to the upper layer. However, it's not working well on some cases. * Case 1. Immediate (or quick) end_bio with an error When btrfs sends btrfs_bio to mirrored devices, btrfs calls btrfs_bio_end_io() when all the mirroring bios are completed. If that btrfs_bio was split, it is from btrfs_clone_bioset and its end_io function is btrfs_orig_write_end_io. For this case, btrfs_bbio_propagate_error() accesses the orig_bbio's bio context to increase the error count. That works well in most cases. However, if the end_io is called enough fast, orig_bbio's (remaining part after split) bio context may not be properly set at that time. Since the bio context is set when the orig_bbio (the last btrfs_bio) is sent to devices, that might be too late for earlier split btrfs_bio's completion. That will result in NULL pointer dereference. That bug is easily reproducible by running btrfs/146 on zoned devices [1] and it shows the following trace. [1] You need raid-stripe-tree feature as it create \"-d raid0 -m raid1\" FS. BUG: kernel NULL pointer dereference, address: 0000000000000020 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 UID: 0 PID: 13 Comm: kworker/u32:1 Not tainted 6.11.0-rc7-BTRFS-ZNS+ #474 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Workqueue: writeback wb_workfn (flush-btrfs-5) RIP: 0010:btrfs_bio_end_io+0xae/0xc0 [btrfs] BTRFS error (device dm-0): bdev /dev/mapper/error-test errs: wr 2, rd 0, flush 0, corrupt 0, gen 0 RSP: 0018:ffffc9000006f248 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888005a7f080 RCX: ffffc9000006f1dc RDX: 0000000000000000 RSI: 000000000000000a RDI: ffff888005a7f080 RBP: ffff888011dfc540 R08: 0000000000000000 R09: 0000000000000001 R10: ffffffff82e508e0 R11: 0000000000000005 R12: ffff88800ddfbe58 R13: ffff888005a7f080 R14: ffff888005a7f158 R15: ffff888005a7f158 FS: 0000000000000000(0000) GS:ffff88803ea80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000020 CR3: 0000000002e22006 CR4: 0000000000370ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __die_body.cold+0x19/0x26 ? page_fault_oops+0x13e/0x2b0 ? _printk+0x58/0x73 ? do_user_addr_fault+0x5f/0x750 ? exc_page_fault+0x76/0x240 ? asm_exc_page_fault+0x22/0x30 ? btrfs_bio_end_io+0xae/0xc0 [btrfs] ? btrfs_log_dev_io_error+0x7f/0x90 [btrfs] btrfs_orig_write_end_io+0x51/0x90 [btrfs] dm_submit_bio+0x5c2/0xa50 [dm_mod] ? find_held_lock+0x2b/0x80 ? blk_try_enter_queue+0x90/0x1e0 __submit_bio+0xe0/0x130 ? ktime_get+0x10a/0x160 ? lockdep_hardirqs_on+0x74/0x100 submit_bio_noacct_nocheck+0x199/0x410 btrfs_submit_bio+0x7d/0x150 [btrfs] btrfs_submit_chunk+0x1a1/0x6d0 [btrfs] ? lockdep_hardirqs_on+0x74/0x100 ? __folio_start_writeback+0x10/0x2c0 btrfs_submit_bbio+0x1c/0x40 [btrfs] submit_one_bio+0x44/0x60 [btrfs] submit_extent_folio+0x13f/0x330 [btrfs] ? btrfs_set_range_writeback+0xa3/0xd0 [btrfs] extent_writepage_io+0x18b/0x360 [btrfs] extent_write_locked_range+0x17c/0x340 [btrfs] ? __pfx_end_bbio_data_write+0x10/0x10 [btrfs] run_delalloc_cow+0x71/0xd0 [btrfs] btrfs_run_delalloc_range+0x176/0x500 [btrfs] ? find_lock_delalloc_range+0x119/0x260 [btrfs] writepage_delalloc+0x2ab/0x480 [btrfs] extent_write_cache_pages+0x236/0x7d0 [btrfs] btrfs_writepages+0x72/0x130 [btrfs] do_writepages+0xd4/0x240 ? find_held_lock+0x2b/0x80 ? wbc_attach_and_unlock_inode+0x12c/0x290 ? wbc_attach_and_unlock_inode+0x12c/0x29 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53054", "url": "https://ubuntu.com/security/CVE-2024-53054", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50226", "url": "https://ubuntu.com/security/CVE-2024-50226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cxl/port: Fix use-after-free, permit out-of-order decoder shutdown In support of investigating an initialization failure report [1], cxl_test was updated to register mock memory-devices after the mock root-port/bus device had been registered. That led to cxl_test crashing with a use-after-free bug with the following signature: cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem0:decoder7.0 @ 0 next: cxl_switch_uport.0 nr_eps: 1 nr_targets: 1 cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem4:decoder14.0 @ 1 next: cxl_switch_uport.0 nr_eps: 2 nr_targets: 1 cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[0] = cxl_switch_dport.0 for mem0:decoder7.0 @ 0 1) cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[1] = cxl_switch_dport.4 for mem4:decoder14.0 @ 1 [..] cxld_unregister: cxl decoder14.0: cxl_region_decode_reset: cxl_region region3: mock_decoder_reset: cxl_port port3: decoder3.0 reset 2) mock_decoder_reset: cxl_port port3: decoder3.0: out of order reset, expected decoder3.1 cxl_endpoint_decoder_release: cxl decoder14.0: [..] cxld_unregister: cxl decoder7.0: 3) cxl_region_decode_reset: cxl_region region3: Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6bc3: 0000 [#1] PREEMPT SMP PTI [..] RIP: 0010:to_cxl_port+0x8/0x60 [cxl_core] [..] Call Trace: cxl_region_decode_reset+0x69/0x190 [cxl_core] cxl_region_detach+0xe8/0x210 [cxl_core] cxl_decoder_kill_region+0x27/0x40 [cxl_core] cxld_unregister+0x5d/0x60 [cxl_core] At 1) a region has been established with 2 endpoint decoders (7.0 and 14.0). Those endpoints share a common switch-decoder in the topology (3.0). At teardown, 2), decoder14.0 is the first to be removed and hits the \"out of order reset case\" in the switch decoder. The effect though is that region3 cleanup is aborted leaving it in-tact and referencing decoder14.0. At 3) the second attempt to teardown region3 trips over the stale decoder14.0 object which has long since been deleted. The fix here is to recognize that the CXL specification places no mandate on in-order shutdown of switch-decoders, the driver enforces in-order allocation, and hardware enforces in-order commit. So, rather than fail and leave objects dangling, always remove them. In support of making cxl_region_decode_reset() always succeed, cxl_region_invalidate_memregion() failures are turned into warnings. Crashing the kernel is ok there since system integrity is at risk if caches cannot be managed around physical address mutation events like CXL region destruction. A new device_for_each_child_reverse_from() is added to cleanup port->commit_end after all dependent decoders have been disabled. In other words if decoders are allocated 0->1->2 and disabled 1->2->0 then port->commit_end only decrements from 2 after 2 has been disabled, and it decrements all the way to zero since 1 was disabled previously.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50227", "url": "https://ubuntu.com/security/CVE-2024-50227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Fix KASAN reported stack out-of-bounds read in tb_retimer_scan() KASAN reported following issue: BUG: KASAN: stack-out-of-bounds in tb_retimer_scan+0xffe/0x1550 [thunderbolt] Read of size 4 at addr ffff88810111fc1c by task kworker/u56:0/11 CPU: 0 UID: 0 PID: 11 Comm: kworker/u56:0 Tainted: G U 6.11.0+ #1387 Tainted: [U]=USER Workqueue: thunderbolt0 tb_handle_hotplug [thunderbolt] Call Trace: dump_stack_lvl+0x6c/0x90 print_report+0xd1/0x630 kasan_report+0xdb/0x110 __asan_report_load4_noabort+0x14/0x20 tb_retimer_scan+0xffe/0x1550 [thunderbolt] tb_scan_port+0xa6f/0x2060 [thunderbolt] tb_handle_hotplug+0x17b1/0x3080 [thunderbolt] process_one_work+0x626/0x1100 worker_thread+0x6c8/0xfa0 kthread+0x2c8/0x3a0 ret_from_fork+0x3a/0x80 ret_from_fork_asm+0x1a/0x30 This happens because the loop variable still gets incremented by one so max becomes 3 instead of 2, and this makes the second loop read past the the array declared on the stack. Fix this by assigning to max directly in the loop body.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50228", "url": "https://ubuntu.com/security/CVE-2024-50228", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50229", "url": "https://ubuntu.com/security/CVE-2024-50229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential deadlock with newly created symlinks Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers memory reclamation involving the filesystem layer, which can result in circular lock dependencies among the reader/writer semaphore nilfs->ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the fs_reclaim pseudo lock. This is because after commit 21fc61c73c39 (\"don't put symlink bodies in pagecache into highmem\"), the gfp flags of the page cache for symbolic links are overwritten to GFP_KERNEL via inode_nohighmem(). This is not a problem for symlinks read from the backing device, because the __GFP_FS flag is dropped after inode_nohighmem() is called. However, when a new symlink is created with nilfs_symlink(), the gfp flags remain overwritten to GFP_KERNEL. Then, memory allocation called from page_symlink() etc. triggers memory reclamation including the FS layer, which may call nilfs_evict_inode() or nilfs_dirty_inode(). And these can cause a deadlock if they are called while nilfs->ns_segctor_sem is held: Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags of newly created symlinks in the same way that nilfs_new_inode() and __nilfs_read_inode() do, as a workaround until we adopt nofs allocation scope consistently or improve the locking constraints.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50230", "url": "https://ubuntu.com/security/CVE-2024-50230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug due to missing clearing of checked flag Syzbot reported that in directory operations after nilfs2 detects filesystem corruption and degrades to read-only, __block_write_begin_int(), which is called to prepare block writes, may fail the BUG_ON check for accesses exceeding the folio/page size, triggering a kernel bug. This was found to be because the \"checked\" flag of a page/folio was not cleared when it was discarded by nilfs2's own routine, which causes the sanity check of directory entries to be skipped when the directory page/folio is reloaded. So, fix that. This was necessary when the use of nilfs2's own page discard routine was applied to more than just metadata files.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50231", "url": "https://ubuntu.com/security/CVE-2024-50231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gts-helper: Fix memory leaks in iio_gts_build_avail_scale_table() modprobe iio-test-gts and rmmod it, then the following memory leak occurs: \tunreferenced object 0xffffff80c810be00 (size 64): \t comm \"kunit_try_catch\", pid 1654, jiffies 4294913981 \t hex dump (first 32 bytes): \t 02 00 00 00 08 00 00 00 20 00 00 00 40 00 00 00 ........ ...@... \t 80 00 00 00 00 02 00 00 00 04 00 00 00 08 00 00 ................ \t backtrace (crc a63d875e): \t [<0000000028c1b3c2>] kmemleak_alloc+0x34/0x40 \t [<000000001d6ecc87>] __kmalloc_noprof+0x2bc/0x3c0 \t [<00000000393795c1>] devm_iio_init_iio_gts+0x4b4/0x16f4 \t [<0000000071bb4b09>] 0xffffffdf052a62e0 \t [<000000000315bc18>] 0xffffffdf052a6488 \t [<00000000f9dc55b5>] kunit_try_run_case+0x13c/0x3ac \t [<00000000175a3fd4>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000f505065d>] kthread+0x2e8/0x374 \t [<00000000bbfb0e5d>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cbfe9e70 (size 16): \t comm \"kunit_try_catch\", pid 1658, jiffies 4294914015 \t hex dump (first 16 bytes): \t 10 00 00 00 40 00 00 00 80 00 00 00 00 00 00 00 ....@........... \t backtrace (crc 857f0cb4): \t [<0000000028c1b3c2>] kmemleak_alloc+0x34/0x40 \t [<000000001d6ecc87>] __kmalloc_noprof+0x2bc/0x3c0 \t [<00000000393795c1>] devm_iio_init_iio_gts+0x4b4/0x16f4 \t [<0000000071bb4b09>] 0xffffffdf052a62e0 \t [<000000007d089d45>] 0xffffffdf052a6864 \t [<00000000f9dc55b5>] kunit_try_run_case+0x13c/0x3ac \t [<00000000175a3fd4>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000f505065d>] kthread+0x2e8/0x374 \t [<00000000bbfb0e5d>] ret_from_fork+0x10/0x20 \t...... It includes 5*5 times \"size 64\" memory leaks, which correspond to 5 times test_init_iio_gain_scale() calls with gts_test_gains size 10 (10*size(int)) and gts_test_itimes size 5. It also includes 5*1 times \"size 16\" memory leak, which correspond to one time __test_init_iio_gain_scale() call with gts_test_gains_gain_low size 3 (3*size(int)) and gts_test_itimes size 5. The reason is that the per_time_gains[i] is not freed which is allocated in the \"gts->num_itime\" for loop in iio_gts_build_avail_scale_table().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53076", "url": "https://ubuntu.com/security/CVE-2024-53076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gts-helper: Fix memory leaks for the error path of iio_gts_build_avail_scale_table() If per_time_scales[i] or per_time_gains[i] kcalloc fails in the for loop of iio_gts_build_avail_scale_table(), the err_free_out will fail to call kfree() each time when i is reduced to 0, so all the per_time_scales[0] and per_time_gains[0] will not be freed, which will cause memory leaks. Fix it by checking if i >= 0.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50232", "url": "https://ubuntu.com/security/CVE-2024-50232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr() In the ad7124_write_raw() function, parameter val can potentially be zero. This may lead to a division by zero when DIV_ROUND_CLOSEST() is called within ad7124_set_channel_odr(). The ad7124_write_raw() function is invoked through the sequence: iio_write_channel_raw() -> iio_write_channel_attribute() -> iio_channel_write(), with no checks in place to ensure val is non-zero.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50233", "url": "https://ubuntu.com/security/CVE-2024-50233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: iio: frequency: ad9832: fix division by zero in ad9832_calc_freqreg() In the ad9832_write_frequency() function, clk_get_rate() might return 0. This can lead to a division by zero when calling ad9832_calc_freqreg(). The check if (fout > (clk_get_rate(st->mclk) / 2)) does not protect against the case when fout is 0. The ad9832_write_frequency() function is called from ad9832_write(), and fout is derived from a text buffer, which can contain any value.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53055", "url": "https://ubuntu.com/security/CVE-2024-53055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix 6 GHz scan construction If more than 255 colocated APs exist for the set of all APs found during 2.4/5 GHz scanning, then the 6 GHz scan construction will loop forever since the loop variable has type u8, which can never reach the number found when that's bigger than 255, and is stored in a u32 variable. Also move it into the loops to have a smaller scope. Using a u32 there is fine, we limit the number of APs in the scan list and each has a limit on the number of RNR entries due to the frame size. With a limit of 1000 scan results, a frame size upper bound of 4096 (really it's more like ~2300) and a TBTT entry size of at least 11, we get an upper bound for the number of ~372k, well in the bounds of a u32.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50234", "url": "https://ubuntu.com/security/CVE-2024-50234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlegacy: Clear stale interrupts before resuming device iwl4965 fails upon resume from hibernation on my laptop. The reason seems to be a stale interrupt which isn't being cleared out before interrupts are enabled. We end up with a race beween the resume trying to bring things back up, and the restart work (queued form the interrupt handler) trying to bring things down. Eventually the whole thing blows up. Fix the problem by clearing out any stale interrupts before interrupts get enabled during resume. Here's a debug log of the indicent: [ 12.042589] ieee80211 phy0: il_isr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000 [ 12.042625] ieee80211 phy0: il4965_irq_tasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000 [ 12.042651] iwl4965 0000:10:00.0: RF_KILL bit toggled to enable radio. [ 12.042653] iwl4965 0000:10:00.0: On demand firmware reload [ 12.042690] ieee80211 phy0: il4965_irq_tasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282 [ 12.052207] ieee80211 phy0: il4965_mac_start enter [ 12.052212] ieee80211 phy0: il_prep_station Add STA to driver ID 31: ff:ff:ff:ff:ff:ff [ 12.052244] ieee80211 phy0: il4965_set_hw_ready hardware ready [ 12.052324] ieee80211 phy0: il_apm_init Init card's basic functions [ 12.052348] ieee80211 phy0: il_apm_init L1 Enabled; Disabling L0S [ 12.055727] ieee80211 phy0: il4965_load_bsm Begin load bsm [ 12.056140] ieee80211 phy0: il4965_verify_bsm Begin verify bsm [ 12.058642] ieee80211 phy0: il4965_verify_bsm BSM bootstrap uCode image OK [ 12.058721] ieee80211 phy0: il4965_load_bsm BSM write complete, poll 1 iterations [ 12.058734] ieee80211 phy0: __il4965_up iwl4965 is coming up [ 12.058737] ieee80211 phy0: il4965_mac_start Start UP work done. [ 12.058757] ieee80211 phy0: __il4965_down iwl4965 is going down [ 12.058761] ieee80211 phy0: il_scan_cancel_timeout Scan cancel timeout [ 12.058762] ieee80211 phy0: il_do_scan_abort Not performing scan to abort [ 12.058765] ieee80211 phy0: il_clear_ucode_stations Clearing ucode stations in driver [ 12.058767] ieee80211 phy0: il_clear_ucode_stations No active stations found to be cleared [ 12.058819] ieee80211 phy0: _il_apm_stop Stop card, put in low power state [ 12.058827] ieee80211 phy0: _il_apm_stop_master stop master [ 12.058864] ieee80211 phy0: il4965_clear_free_frames 0 frames on pre-allocated heap on clear. [ 12.058869] ieee80211 phy0: Hardware restart was requested [ 16.132299] iwl4965 0000:10:00.0: START_ALIVE timeout after 4000ms. [ 16.132303] ------------[ cut here ]------------ [ 16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue. [ 16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132390] Modules linked in: ctr ccm sch_fq_codel xt_tcpudp xt_multiport xt_state iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables binfmt_misc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdh_generic ecc iTCO_wdt i2c_dev iwl4965 iwlegacy coretemp snd_hda_codec_analog pcspkr psmouse mac80211 snd_hda_codec_generic libarc4 sdhci_pci cqhci sha256_generic sdhci libsha256 firewire_ohci snd_hda_intel snd_intel_dspcfg mmc_core snd_hda_codec snd_hwdep firewire_core led_class iosf_mbi snd_hda_core uhci_hcd lpc_ich crc_itu_t cfg80211 ehci_pci ehci_hcd snd_pcm usbcore mfd_core rfkill snd_timer snd usb_common soundcore video parport_pc parport intel_agp wmi intel_gtt backlight e1000e agpgart evdev [ 16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143 [ 16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010 [ 16.132463] Workqueue: async async_run_entry_fn [ 16.132469] RIP: 0010:ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132501] Code: da 02 00 0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50235", "url": "https://ubuntu.com/security/CVE-2024-50235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: clear wdev->cqm_config pointer on free When we free wdev->cqm_config when unregistering, we also need to clear out the pointer since the same wdev/netdev may get re-registered in another network namespace, then destroyed later, running this code again, which results in a double-free.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50236", "url": "https://ubuntu.com/security/CVE-2024-50236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: Fix memory leak in management tx In the current logic, memory is allocated for storing the MSDU context during management packet TX but this memory is not being freed during management TX completion. Similar leaks are seen in the management TX cleanup logic. Kmemleak reports this problem as below, unreferenced object 0xffffff80b64ed250 (size 16): comm \"kworker/u16:7\", pid 148, jiffies 4294687130 (age 714.199s) hex dump (first 16 bytes): 00 2b d8 d8 80 ff ff ff c4 74 e9 fd 07 00 00 00 .+.......t...... backtrace: [] __kmem_cache_alloc_node+0x1e4/0x2d8 [] kmalloc_trace+0x48/0x110 [] ath10k_wmi_tlv_op_gen_mgmt_tx_send+0xd4/0x1d8 [ath10k_core] [] ath10k_mgmt_over_wmi_tx_work+0x134/0x298 [ath10k_core] [] process_scheduled_works+0x1ac/0x400 [] worker_thread+0x208/0x328 [] kthread+0x100/0x1c0 [] ret_from_fork+0x10/0x20 Free the memory during completion and cleanup to fix the leak. Protect the mgmt_pending_tx idr_remove() operation in ath10k_wmi_tlv_op_cleanup_mgmt_tx_send() using ar->data_lock similar to other instances. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50237", "url": "https://ubuntu.com/security/CVE-2024-50237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower Avoid potentially crashing in the driver because of uninitialized private data", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50238", "url": "https://ubuntu.com/security/CVE-2024-50238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usbc: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data from the qcom-qmp-usb driver, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. This bug was later reproduced when the driver was copied to create the qmp-usbc driver. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with these drivers.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50239", "url": "https://ubuntu.com/security/CVE-2024-50239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usb-legacy: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data from the qcom-qmp-usb driver, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. This bug was later reproduced when the driver was copied to create the qmp-usb-legacy driver. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with these drivers.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50240", "url": "https://ubuntu.com/security/CVE-2024-50240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usb: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with this driver.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53077", "url": "https://ubuntu.com/security/CVE-2024-53077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpcrdma: Always release the rpcrdma_device's xa_array Dai pointed out that the xa_init_flags() in rpcrdma_add_one() needs to have a matching xa_destroy() in rpcrdma_remove_one() to release underlying memory that the xarray might have accrued during operation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50242", "url": "https://ubuntu.com/security/CVE-2024-50242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ntfs_file_release", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50243", "url": "https://ubuntu.com/security/CVE-2024-50243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix general protection fault in run_is_mapped_full Fixed deleating of a non-resident attribute in ntfs_create_inode() rollback.", "cve_priority": "low", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50244", "url": "https://ubuntu.com/security/CVE-2024-50244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ni_clear() Checking of NTFS_FLAGS_LOG_REPLAYING added to prevent access to uninitialized bitmap during replay process.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50245", "url": "https://ubuntu.com/security/CVE-2024-50245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix possible deadlock in mi_read Mutex lock with another subclass used in ni_lock_dir().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50246", "url": "https://ubuntu.com/security/CVE-2024-50246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Add rough attr alloc_size check", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50247", "url": "https://ubuntu.com/security/CVE-2024-50247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Check if more than chunk-size bytes are written A incorrectly formatted chunk may decompress into more than LZNT_CHUNK_SIZE bytes and a index out of bounds will occur in s_max_off.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50248", "url": "https://ubuntu.com/security/CVE-2024-50248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Add bounds checking to mi_enum_attr() Added bounds checking to make sure that every attr don't stray beyond valid memory region.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53078", "url": "https://ubuntu.com/security/CVE-2024-53078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Fix NULL vs IS_ERR() check in probe() The iommu_paging_domain_alloc() function doesn't return NULL pointers, it returns error pointers. Update the check to match.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53056", "url": "https://ubuntu.com/security/CVE-2024-53056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Fix potential NULL dereference in mtk_crtc_destroy() In mtk_crtc_create(), if the call to mbox_request_channel() fails then we set the \"mtk_crtc->cmdq_client.chan\" pointer to NULL. In that situation, we do not call cmdq_pkt_create(). During the cleanup, we need to check if the \"mtk_crtc->cmdq_client.chan\" is NULL first before calling cmdq_pkt_destroy(). Calling cmdq_pkt_destroy() is unnecessary if we didn't call cmdq_pkt_create() and it will result in a NULL pointer dereference.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50249", "url": "https://ubuntu.com/security/CVE-2024-50249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Make rmw_lock a raw_spin_lock The following BUG was triggered: ============================= [ BUG: Invalid wait context ] 6.12.0-rc2-XXX #406 Not tainted ----------------------------- kworker/1:1/62 is trying to lock: ffffff8801593030 (&cpc_ptr->rmw_lock){+.+.}-{3:3}, at: cpc_write+0xcc/0x370 other info that might help us debug this: context-{5:5} 2 locks held by kworker/1:1/62: #0: ffffff897ef5ec98 (&rq->__lock){-.-.}-{2:2}, at: raw_spin_rq_lock_nested+0x2c/0x50 #1: ffffff880154e238 (&sg_policy->update_lock){....}-{2:2}, at: sugov_update_shared+0x3c/0x280 stack backtrace: CPU: 1 UID: 0 PID: 62 Comm: kworker/1:1 Not tainted 6.12.0-rc2-g9654bd3e8806 #406 Workqueue: 0x0 (events) Call trace: dump_backtrace+0xa4/0x130 show_stack+0x20/0x38 dump_stack_lvl+0x90/0xd0 dump_stack+0x18/0x28 __lock_acquire+0x480/0x1ad8 lock_acquire+0x114/0x310 _raw_spin_lock+0x50/0x70 cpc_write+0xcc/0x370 cppc_set_perf+0xa0/0x3a8 cppc_cpufreq_fast_switch+0x40/0xc0 cpufreq_driver_fast_switch+0x4c/0x218 sugov_update_shared+0x234/0x280 update_load_avg+0x6ec/0x7b8 dequeue_entities+0x108/0x830 dequeue_task_fair+0x58/0x408 __schedule+0x4f0/0x1070 schedule+0x54/0x130 worker_thread+0xc0/0x2e8 kthread+0x130/0x148 ret_from_fork+0x10/0x20 sugov_update_shared() locks a raw_spinlock while cpc_write() locks a spinlock. To have a correct wait-type order, update rmw_lock to a raw spinlock and ensure that interrupts will be disabled on the CPU holding it. [ rjw: Changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50250", "url": "https://ubuntu.com/security/CVE-2024-50250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fsdax: dax_unshare_iter needs to copy entire blocks The code that copies data from srcmap to iomap in dax_unshare_iter is very very broken, which bfoster's recent fsx changes have exposed. If the pos and len passed to dax_file_unshare are not aligned to an fsblock boundary, the iter pos and length in the _iter function will reflect this unalignment. dax_iomap_direct_access always returns a pointer to the start of the kmapped fsdax page, even if its pos argument is in the middle of that page. This is catastrophic for data integrity when iter->pos is not aligned to a page, because daddr/saddr do not point to the same byte in the file as iter->pos. Hence we corrupt user data by copying it to the wrong place. If iter->pos + iomap_length() in the _iter function not aligned to a page, then we fail to copy a full block, and only partially populate the destination block. This is catastrophic for data confidentiality because we expose stale pmem contents. Fix both of these issues by aligning copy_pos/copy_len to a page boundary (remember, this is fsdax so 1 fsblock == 1 base page) so that we always copy full blocks. We're not done yet -- there's no call to invalidate_inode_pages2_range, so programs that have the file range mmap'd will continue accessing the old memory mapping after the file metadata updates have completed. Be careful with the return value -- if the unshare succeeds, we still need to return the number of bytes that the iomap iter thinks we're operating on.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50251", "url": "https://ubuntu.com/security/CVE-2024-50251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_payload: sanitize offset and length before calling skb_checksum() If access to offset + length is larger than the skbuff length, then skb_checksum() triggers BUG_ON(). skb_checksum() internally subtracts the length parameter while iterating over skbuff, BUG_ON(len) at the end of it checks that the expected length to be included in the checksum calculation is fully consumed.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50252", "url": "https://ubuntu.com/security/CVE-2024-50252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_ipip: Fix memory leak when changing remote IPv6 address The device stores IPv6 addresses that are used for encapsulation in linear memory that is managed by the driver. Changing the remote address of an ip6gre net device never worked properly, but since cited commit the following reproducer [1] would result in a warning [2] and a memory leak [3]. The problem is that the new remote address is never added by the driver to its hash table (and therefore the device) and the old address is never removed from it. Fix by programming the new address when the configuration of the ip6gre net device changes and removing the old one. If the address did not change, then the above would result in increasing the reference count of the address and then decreasing it. [1] # ip link add name bla up type ip6gre local 2001:db8:1::1 remote 2001:db8:2::1 tos inherit ttl inherit # ip link set dev bla type ip6gre remote 2001:db8:3::1 # ip link del dev bla # devlink dev reload pci/0000:01:00.0 [2] WARNING: CPU: 0 PID: 1682 at drivers/net/ethernet/mellanox/mlxsw/spectrum.c:3002 mlxsw_sp_ipv6_addr_put+0x140/0x1d0 Modules linked in: CPU: 0 UID: 0 PID: 1682 Comm: ip Not tainted 6.12.0-rc3-custom-g86b5b55bc835 #151 Hardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023 RIP: 0010:mlxsw_sp_ipv6_addr_put+0x140/0x1d0 [...] Call Trace: mlxsw_sp_router_netdevice_event+0x55f/0x1240 notifier_call_chain+0x5a/0xd0 call_netdevice_notifiers_info+0x39/0x90 unregister_netdevice_many_notify+0x63e/0x9d0 rtnl_dellink+0x16b/0x3a0 rtnetlink_rcv_msg+0x142/0x3f0 netlink_rcv_skb+0x50/0x100 netlink_unicast+0x242/0x390 netlink_sendmsg+0x1de/0x420 ____sys_sendmsg+0x2bd/0x320 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xd0 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f [3] unreferenced object 0xffff898081f597a0 (size 32): comm \"ip\", pid 1626, jiffies 4294719324 hex dump (first 32 bytes): 20 01 0d b8 00 02 00 00 00 00 00 00 00 00 00 01 ............... 21 49 61 83 80 89 ff ff 00 00 00 00 01 00 00 00 !Ia............. backtrace (crc fd9be911): [<00000000df89c55d>] __kmalloc_cache_noprof+0x1da/0x260 [<00000000ff2a1ddb>] mlxsw_sp_ipv6_addr_kvdl_index_get+0x281/0x340 [<000000009ddd445d>] mlxsw_sp_router_netdevice_event+0x47b/0x1240 [<00000000743e7757>] notifier_call_chain+0x5a/0xd0 [<000000007c7b9e13>] call_netdevice_notifiers_info+0x39/0x90 [<000000002509645d>] register_netdevice+0x5f7/0x7a0 [<00000000c2e7d2a9>] ip6gre_newlink_common.isra.0+0x65/0x130 [<0000000087cd6d8d>] ip6gre_newlink+0x72/0x120 [<000000004df7c7cc>] rtnl_newlink+0x471/0xa20 [<0000000057ed632a>] rtnetlink_rcv_msg+0x142/0x3f0 [<0000000032e0d5b5>] netlink_rcv_skb+0x50/0x100 [<00000000908bca63>] netlink_unicast+0x242/0x390 [<00000000cdbe1c87>] netlink_sendmsg+0x1de/0x420 [<0000000011db153e>] ____sys_sendmsg+0x2bd/0x320 [<000000003b6d53eb>] ___sys_sendmsg+0x9a/0xe0 [<00000000cae27c62>] __sys_sendmsg+0x7a/0xd0", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50253", "url": "https://ubuntu.com/security/CVE-2024-50253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check the validity of nr_words in bpf_iter_bits_new() Check the validity of nr_words in bpf_iter_bits_new(). Without this check, when multiplication overflow occurs for nr_bits (e.g., when nr_words = 0x0400-0001, nr_bits becomes 64), stack corruption may occur due to bpf_probe_read_kernel_common(..., nr_bytes = 0x2000-0008). Fix it by limiting the maximum value of nr_words to 511. The value is derived from the current implementation of BPF memory allocator. To ensure compatibility if the BPF memory allocator's size limitation changes in the future, use the helper bpf_mem_alloc_check_size() to check whether nr_bytes is too larger. And return -E2BIG instead of -ENOMEM for oversized nr_bytes.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50254", "url": "https://ubuntu.com/security/CVE-2024-50254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free dynamically allocated bits in bpf_iter_bits_destroy() bpf_iter_bits_destroy() uses \"kit->nr_bits <= 64\" to check whether the bits are dynamically allocated. However, the check is incorrect and may cause a kmemleak as shown below: unreferenced object 0xffff88812628c8c0 (size 32): comm \"swapper/0\", pid 1, jiffies 4294727320 hex dump (first 32 bytes): \tb0 c1 55 f5 81 88 ff ff f0 f0 f0 f0 f0 f0 f0 f0 ..U........... \tf0 f0 f0 f0 f0 f0 f0 f0 00 00 00 00 00 00 00 00 .............. backtrace (crc 781e32cc): \t[<00000000c452b4ab>] kmemleak_alloc+0x4b/0x80 \t[<0000000004e09f80>] __kmalloc_node_noprof+0x480/0x5c0 \t[<00000000597124d6>] __alloc.isra.0+0x89/0xb0 \t[<000000004ebfffcd>] alloc_bulk+0x2af/0x720 \t[<00000000d9c10145>] prefill_mem_cache+0x7f/0xb0 \t[<00000000ff9738ff>] bpf_mem_alloc_init+0x3e2/0x610 \t[<000000008b616eac>] bpf_global_ma_init+0x19/0x30 \t[<00000000fc473efc>] do_one_initcall+0xd3/0x3c0 \t[<00000000ec81498c>] kernel_init_freeable+0x66a/0x940 \t[<00000000b119f72f>] kernel_init+0x20/0x160 \t[<00000000f11ac9a7>] ret_from_fork+0x3c/0x70 \t[<0000000004671da4>] ret_from_fork_asm+0x1a/0x30 That is because nr_bits will be set as zero in bpf_iter_bits_next() after all bits have been iterated. Fix the issue by setting kit->bit to kit->nr_bits instead of setting kit->nr_bits to zero when the iteration completes in bpf_iter_bits_next(). In addition, use \"!nr_bits || bits >= nr_bits\" to check whether the iteration is complete and still use \"nr_bits > 64\" to indicate whether bits are dynamically allocated. The \"!nr_bits\" check is necessary because bpf_iter_bits_new() may fail before setting kit->nr_bits, and this condition will stop the iteration early instead of accessing the zeroed or freed kit->bits. Considering the initial value of kit->bits is -1 and the type of kit->nr_bits is unsigned int, change the type of kit->nr_bits to int. The potential overflow problem will be handled in the following patch.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50255", "url": "https://ubuntu.com/security/CVE-2024-50255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci: fix null-ptr-deref in hci_read_supported_codecs Fix __hci_cmd_sync_sk() to return not NULL for unknown opcodes. __hci_cmd_sync_sk() returns NULL if a command returns a status event. However, it also returns NULL where an opcode doesn't exist in the hci_cc table because hci_cmd_complete_evt() assumes status = skb->data[0] for unknown opcodes. This leads to null-ptr-deref in cmd_sync for HCI_OP_READ_LOCAL_CODECS as there is no hci_cc for HCI_OP_READ_LOCAL_CODECS, which always assumes status = skb->data[0]. KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077] CPU: 1 PID: 2000 Comm: kworker/u9:5 Not tainted 6.9.0-ga6bcb805883c-dirty #10 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: hci7 hci_power_on RIP: 0010:hci_read_supported_codecs+0xb9/0x870 net/bluetooth/hci_codec.c:138 Code: 08 48 89 ef e8 b8 c1 8f fd 48 8b 75 00 e9 96 00 00 00 49 89 c6 48 ba 00 00 00 00 00 fc ff df 4c 8d 60 70 4c 89 e3 48 c1 eb 03 <0f> b6 04 13 84 c0 0f 85 82 06 00 00 41 83 3c 24 02 77 0a e8 bf 78 RSP: 0018:ffff888120bafac8 EFLAGS: 00010212 RAX: 0000000000000000 RBX: 000000000000000e RCX: ffff8881173f0040 RDX: dffffc0000000000 RSI: ffffffffa58496c0 RDI: ffff88810b9ad1e4 RBP: ffff88810b9ac000 R08: ffffffffa77882a7 R09: 1ffffffff4ef1054 R10: dffffc0000000000 R11: fffffbfff4ef1055 R12: 0000000000000070 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88810b9ac000 FS: 0000000000000000(0000) GS:ffff8881f6c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6ddaa3439e CR3: 0000000139764003 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: hci_read_local_codecs_sync net/bluetooth/hci_sync.c:4546 [inline] hci_init_stage_sync net/bluetooth/hci_sync.c:3441 [inline] hci_init4_sync net/bluetooth/hci_sync.c:4706 [inline] hci_init_sync net/bluetooth/hci_sync.c:4742 [inline] hci_dev_init_sync net/bluetooth/hci_sync.c:4912 [inline] hci_dev_open_sync+0x19a9/0x2d30 net/bluetooth/hci_sync.c:4994 hci_dev_do_open net/bluetooth/hci_core.c:483 [inline] hci_power_on+0x11e/0x560 net/bluetooth/hci_core.c:1015 process_one_work kernel/workqueue.c:3267 [inline] process_scheduled_works+0x8ef/0x14f0 kernel/workqueue.c:3348 worker_thread+0x91f/0xe50 kernel/workqueue.c:3429 kthread+0x2cb/0x360 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50256", "url": "https://ubuntu.com/security/CVE-2024-50256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6() I got a syzbot report without a repro [1] crashing in nf_send_reset6() I think the issue is that dev->hard_header_len is zero, and we attempt later to push an Ethernet header. Use LL_MAX_HEADER, as other functions in net/ipv6/netfilter/nf_reject_ipv6.c. [1] skbuff: skb_under_panic: text:ffffffff89b1d008 len:74 put:14 head:ffff88803123aa00 data:ffff88803123a9f2 tail:0x3c end:0x140 dev:syz_tun kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 UID: 0 PID: 7373 Comm: syz.1.568 Not tainted 6.12.0-rc2-syzkaller-00631-g6d858708d465 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:skb_panic net/core/skbuff.c:206 [inline] RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216 Code: 0d 8d 48 c7 c6 60 a6 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 ba 30 38 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP: 0018:ffffc900045269b0 EFLAGS: 00010282 RAX: 0000000000000088 RBX: dffffc0000000000 RCX: cd66dacdc5d8e800 RDX: 0000000000000000 RSI: 0000000000000200 RDI: 0000000000000000 RBP: ffff88802d39a3d0 R08: ffffffff8174afec R09: 1ffff920008a4ccc R10: dffffc0000000000 R11: fffff520008a4ccd R12: 0000000000000140 R13: ffff88803123aa00 R14: ffff88803123a9f2 R15: 000000000000003c FS: 00007fdbee5ff6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000005d322000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: skb_push+0xe5/0x100 net/core/skbuff.c:2636 eth_header+0x38/0x1f0 net/ethernet/eth.c:83 dev_hard_header include/linux/netdevice.h:3208 [inline] nf_send_reset6+0xce6/0x1270 net/ipv6/netfilter/nf_reject_ipv6.c:358 nft_reject_inet_eval+0x3b9/0x690 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x418/0x6b0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] br_nf_pre_routing_ipv6+0x63e/0x770 net/bridge/br_netfilter_ipv6.c:184 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_bridge_pre net/bridge/br_input.c:277 [inline] br_handle_frame+0x9fd/0x1530 net/bridge/br_input.c:424 __netif_receive_skb_core+0x13e8/0x4570 net/core/dev.c:5562 __netif_receive_skb_one_core net/core/dev.c:5666 [inline] __netif_receive_skb+0x12f/0x650 net/core/dev.c:5781 netif_receive_skb_internal net/core/dev.c:5867 [inline] netif_receive_skb+0x1e8/0x890 net/core/dev.c:5926 tun_rx_batched+0x1b7/0x8f0 drivers/net/tun.c:1550 tun_get_user+0x3056/0x47e0 drivers/net/tun.c:2007 tun_chr_write_iter+0x10d/0x1f0 drivers/net/tun.c:2053 new_sync_write fs/read_write.c:590 [inline] vfs_write+0xa6d/0xc90 fs/read_write.c:683 ksys_write+0x183/0x2b0 fs/read_write.c:736 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:0x7fdbeeb7d1ff Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 c9 8d 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 1c 8e 02 00 48 RSP: 002b:00007fdbee5ff000 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fdbeed36058 RCX: 00007fdbeeb7d1ff RDX: 000000000000008e RSI: 0000000020000040 RDI: 00000000000000c8 RBP: 00007fdbeebf12be R08: 0000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50257", "url": "https://ubuntu.com/security/CVE-2024-50257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: Fix use-after-free in get_info() ip6table_nat module unload has refcnt warning for UAF. call trace is: WARNING: CPU: 1 PID: 379 at kernel/module/main.c:853 module_put+0x6f/0x80 Modules linked in: ip6table_nat(-) CPU: 1 UID: 0 PID: 379 Comm: ip6tables Not tainted 6.12.0-rc4-00047-gc2ee9f594da8-dirty #205 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:module_put+0x6f/0x80 Call Trace: get_info+0x128/0x180 do_ip6t_get_ctl+0x6a/0x430 nf_getsockopt+0x46/0x80 ipv6_getsockopt+0xb9/0x100 rawv6_getsockopt+0x42/0x190 do_sock_getsockopt+0xaa/0x180 __sys_getsockopt+0x70/0xc0 __x64_sys_getsockopt+0x20/0x30 do_syscall_64+0xa2/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Concurrent execution of module unload and get_info() trigered the warning. The root cause is as follows: cpu0\t\t\t\t cpu1 module_exit //mod->state = MODULE_STATE_GOING ip6table_nat_exit xt_unregister_template \tkfree(t) \t//removed from templ_list \t\t\t\t getinfo() \t\t\t\t\t t = xt_find_table_lock \t\t\t\t\t\tlist_for_each_entry(tmpl, &xt_templates[af]...) \t\t\t\t\t\t\tif (strcmp(tmpl->name, name)) \t\t\t\t\t\t\t\tcontinue; //table not found \t\t\t\t\t\t\ttry_module_get \t\t\t\t\t\tlist_for_each_entry(t, &xt_net->tables[af]...) \t\t\t\t\t\t\treturn t; //not get refcnt \t\t\t\t\t module_put(t->me) //uaf unregister_pernet_subsys //remove table from xt_net list While xt_table module was going away and has been removed from xt_templates list, we couldnt get refcnt of xt_table->me. Check module in xt_net->tables list re-traversal to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50258", "url": "https://ubuntu.com/security/CVE-2024-50258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix crash when config small gso_max_size/gso_ipv4_max_size Config a small gso_max_size/gso_ipv4_max_size will lead to an underflow in sk_dst_gso_max_size(), which may trigger a BUG_ON crash, because sk->sk_gso_max_size would be much bigger than device limits. Call Trace: tcp_write_xmit tso_segs = tcp_init_tso_segs(skb, mss_now); tcp_set_skb_tso_segs tcp_skb_pcount_set // skb->len = 524288, mss_now = 8 // u16 tso_segs = 524288/8 = 65535 -> 0 tso_segs = DIV_ROUND_UP(skb->len, mss_now) BUG_ON(!tso_segs) Add check for the minimum value of gso_max_size and gso_ipv4_max_size.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50262", "url": "https://ubuntu.com/security/CVE-2024-50262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix out-of-bounds write in trie_get_next_key() trie_get_next_key() allocates a node stack with size trie->max_prefixlen, while it writes (trie->max_prefixlen + 1) nodes to the stack when it has full paths from the root to leaves. For example, consider a trie with max_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ... 0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with .prefixlen = 8 make 9 nodes be written on the node stack with size 8.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53044", "url": "https://ubuntu.com/security/CVE-2024-53044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_api: fix xa_insert() error path in tcf_block_get_ext() This command: $ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact Error: block dev insert failed: -EBUSY. fails because user space requests the same block index to be set for both ingress and egress. [ side note, I don't think it even failed prior to commit 913b47d3424e (\"net/sched: Introduce tc block netdev tracking infra\"), because this is a command from an old set of notes of mine which used to work, but alas, I did not scientifically bisect this ] The problem is not that it fails, but rather, that the second time around, it fails differently (and irrecoverably): $ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact Error: dsa_core: Flow block cb is busy. [ another note: the extack is added by me for illustration purposes. the context of the problem is that clsact_init() obtains the same &q->ingress_block pointer as &q->egress_block, and since we call tcf_block_get_ext() on both of them, \"dev\" will be added to the block->ports xarray twice, thus failing the operation: once through the ingress block pointer, and once again through the egress block pointer. the problem itself is that when xa_insert() fails, we have emitted a FLOW_BLOCK_BIND command through ndo_setup_tc(), but the offload never sees a corresponding FLOW_BLOCK_UNBIND. ] Even correcting the bad user input, we still cannot recover: $ tc qdisc replace dev swp3 ingress_block 1 egress_block 2 clsact Error: dsa_core: Flow block cb is busy. Basically the only way to recover is to reboot the system, or unbind and rebind the net device driver. To fix the bug, we need to fill the correct error teardown path which was missed during code movement, and call tcf_block_offload_unbind() when xa_insert() fails. [ last note, fundamentally I blame the label naming convention in tcf_block_get_ext() for the bug. The labels should be named after what they do, not after the error path that jumps to them. This way, it is obviously wrong that two labels pointing to the same code mean something is wrong, and checking the code correctness at the goto site is also easier ]", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50259", "url": "https://ubuntu.com/security/CVE-2024-50259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netdevsim: Add trailing zero to terminate the string in nsim_nexthop_bucket_activity_write() This was found by a static analyzer. We should not forget the trailing zero after copy_from_user() if we will further do some string operations, sscanf() in this case. Adding a trailing zero will ensure that the function performs properly.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50304", "url": "https://ubuntu.com/security/CVE-2024-50304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find() The per-netns IP tunnel hash table is protected by the RTNL mutex and ip_tunnel_find() is only called from the control path where the mutex is taken. Add a lockdep expression to hlist_for_each_entry_rcu() in ip_tunnel_find() in order to validate that the mutex is held and to silence the suspicious RCU usage warning [1]. [1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gd95d9a31aceb #139 Not tainted ----------------------------- net/ipv4/ip_tunnel.c:221 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/362: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60 stack backtrace: CPU: 12 UID: 0 PID: 362 Comm: ip Not tainted 6.12.0-rc3-custom-gd95d9a31aceb #139 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 ip_tunnel_find+0x435/0x4d0 ip_tunnel_newlink+0x517/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53042", "url": "https://ubuntu.com/security/CVE-2024-53042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_init_flow() There are code paths from which the function is called without holding the RCU read lock, resulting in a suspicious RCU usage warning [1]. Fix by using l3mdev_master_upper_ifindex_by_index() which will acquire the RCU read lock before calling l3mdev_master_upper_ifindex_by_index_rcu(). [1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gac8f72681cf2 #141 Not tainted ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/361: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60 stack backtrace: CPU: 3 UID: 0 PID: 361 Comm: ip Not tainted 6.12.0-rc3-custom-gac8f72681cf2 #141 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 dev_get_by_index_rcu+0x1d3/0x210 l3mdev_master_upper_ifindex_by_index_rcu+0x2b/0xf0 ip_tunnel_bind_dev+0x72f/0xa00 ip_tunnel_newlink+0x368/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53048", "url": "https://ubuntu.com/security/CVE-2024-53048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix crash on probe for DPLL enabled E810 LOM The E810 Lan On Motherboard (LOM) design is vendor specific. Intel provides the reference design, but it is up to vendor on the final product design. For some cases, like Linux DPLL support, the static values defined in the driver does not reflect the actual LOM design. Current implementation of dpll pins is causing the crash on probe of the ice driver for such DPLL enabled E810 LOM designs: WARNING: (...) at drivers/dpll/dpll_core.c:495 dpll_pin_get+0x2c4/0x330 ... Call Trace: ? __warn+0x83/0x130 ? dpll_pin_get+0x2c4/0x330 ? report_bug+0x1b7/0x1d0 ? handle_bug+0x42/0x70 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? dpll_pin_get+0x117/0x330 ? dpll_pin_get+0x2c4/0x330 ? dpll_pin_get+0x117/0x330 ice_dpll_get_pins.isra.0+0x52/0xe0 [ice] ... The number of dpll pins enabled by LOM vendor is greater than expected and defined in the driver for Intel designed NICs, which causes the crash. Prevent the crash and allow generic pin initialization within Linux DPLL subsystem for DPLL enabled E810 LOM designs. Newly designed solution for described issue will be based on \"per HW design\" pin initialization. It requires pin information dynamically acquired from the firmware and is already in progress, planned for next-tree only.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53058", "url": "https://ubuntu.com/security/CVE-2024-53058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data In case the non-paged data of a SKB carries protocol header and protocol payload to be transmitted on a certain platform that the DMA AXI address width is configured to 40-bit/48-bit, or the size of the non-paged data is bigger than TSO_MAX_BUFF_SIZE on a certain platform that the DMA AXI address width is configured to 32-bit, then this SKB requires at least two DMA transmit descriptors to serve it. For example, three descriptors are allocated to split one DMA buffer mapped from one piece of non-paged data: dma_desc[N + 0], dma_desc[N + 1], dma_desc[N + 2]. Then three elements of tx_q->tx_skbuff_dma[] will be allocated to hold extra information to be reused in stmmac_tx_clean(): tx_q->tx_skbuff_dma[N + 0], tx_q->tx_skbuff_dma[N + 1], tx_q->tx_skbuff_dma[N + 2]. Now we focus on tx_q->tx_skbuff_dma[entry].buf, which is the DMA buffer address returned by DMA mapping call. stmmac_tx_clean() will try to unmap the DMA buffer _ONLY_IF_ tx_q->tx_skbuff_dma[entry].buf is a valid buffer address. The expected behavior that saves DMA buffer address of this non-paged data to tx_q->tx_skbuff_dma[entry].buf is: tx_q->tx_skbuff_dma[N + 0].buf = NULL; tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = dma_map_single(); Unfortunately, the current code misbehaves like this: tx_q->tx_skbuff_dma[N + 0].buf = dma_map_single(); tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = NULL; On the stmmac_tx_clean() side, when dma_desc[N + 0] is closed by the DMA engine, tx_q->tx_skbuff_dma[N + 0].buf is a valid buffer address obviously, then the DMA buffer will be unmapped immediately. There may be a rare case that the DMA engine does not finish the pending dma_desc[N + 1], dma_desc[N + 2] yet. Now things will go horribly wrong, DMA is going to access a unmapped/unreferenced memory region, corrupted data will be transmited or iommu fault will be triggered :( In contrast, the for-loop that maps SKB fragments behaves perfectly as expected, and that is how the driver should do for both non-paged data and paged frags actually. This patch corrects DMA map/unmap sequences by fixing the array index for tx_q->tx_skbuff_dma[entry].buf when assigning DMA buffer address. Tested and verified on DWXGMAC CORE 3.20a", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50260", "url": "https://ubuntu.com/security/CVE-2024-50260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sock_map: fix a NULL pointer dereference in sock_map_link_update_prog() The following race condition could trigger a NULL pointer dereference: sock_map_link_detach():\t\tsock_map_link_update_prog(): mutex_lock(&sockmap_mutex); ... sockmap_link->map = NULL; mutex_unlock(&sockmap_mutex); \t\t\t\t mutex_lock(&sockmap_mutex); \t\t\t\t ... \t\t\t\t sock_map_prog_link_lookup(sockmap_link->map); \t\t\t\t mutex_unlock(&sockmap_mutex); Fix it by adding a NULL pointer check. In this specific case, it makes no sense to update a link which is being released.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53045", "url": "https://ubuntu.com/security/CVE-2024-53045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: dapm: fix bounds checker error in dapm_widget_list_create The widgets array in the snd_soc_dapm_widget_list has a __counted_by attribute attached to it, which points to the num_widgets variable. This attribute is used in bounds checking, and if it is not set before the array is filled, then the bounds sanitizer will issue a warning or a kernel panic if CONFIG_UBSAN_TRAP is set. This patch sets the size of the widgets list calculated with list_for_each as the initial value for num_widgets as it is used for allocating memory for the array. It is updated with the actual number of added elements after the array is filled.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50261", "url": "https://ubuntu.com/security/CVE-2024-50261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macsec: Fix use-after-free while sending the offloading packet KASAN reports the following UAF. The metadata_dst, which is used to store the SCI value for macsec offload, is already freed by metadata_dst_free() in macsec_free_netdev(), while driver still use it for sending the packet. To fix this issue, dst_release() is used instead to release metadata_dst. So it is not freed instantly in macsec_free_netdev() if still referenced by skb. BUG: KASAN: slab-use-after-free in mlx5e_xmit+0x1e8f/0x4190 [mlx5_core] Read of size 2 at addr ffff88813e42e038 by task kworker/7:2/714 [...] Workqueue: mld mld_ifc_work Call Trace: dump_stack_lvl+0x51/0x60 print_report+0xc1/0x600 kasan_report+0xab/0xe0 mlx5e_xmit+0x1e8f/0x4190 [mlx5_core] dev_hard_start_xmit+0x120/0x530 sch_direct_xmit+0x149/0x11e0 __qdisc_run+0x3ad/0x1730 __dev_queue_xmit+0x1196/0x2ed0 vlan_dev_hard_start_xmit+0x32e/0x510 [8021q] dev_hard_start_xmit+0x120/0x530 __dev_queue_xmit+0x14a7/0x2ed0 macsec_start_xmit+0x13e9/0x2340 dev_hard_start_xmit+0x120/0x530 __dev_queue_xmit+0x14a7/0x2ed0 ip6_finish_output2+0x923/0x1a70 ip6_finish_output+0x2d7/0x970 ip6_output+0x1ce/0x3a0 NF_HOOK.constprop.0+0x15f/0x190 mld_sendpack+0x59a/0xbd0 mld_ifc_work+0x48a/0xa80 process_one_work+0x5aa/0xe50 worker_thread+0x79c/0x1290 kthread+0x28f/0x350 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x11/0x20 Allocated by task 3922: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 __kasan_kmalloc+0x77/0x90 __kmalloc_noprof+0x188/0x400 metadata_dst_alloc+0x1f/0x4e0 macsec_newlink+0x914/0x1410 __rtnl_newlink+0xe08/0x15b0 rtnl_newlink+0x5f/0x90 rtnetlink_rcv_msg+0x667/0xa80 netlink_rcv_skb+0x12c/0x360 netlink_unicast+0x551/0x770 netlink_sendmsg+0x72d/0xbd0 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x52e/0x6a0 ___sys_sendmsg+0xeb/0x170 __sys_sendmsg+0xb5/0x140 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Freed by task 4011: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x50 poison_slab_object+0x10c/0x190 __kasan_slab_free+0x11/0x30 kfree+0xe0/0x290 macsec_free_netdev+0x3f/0x140 netdev_run_todo+0x450/0xc70 rtnetlink_rcv_msg+0x66f/0xa80 netlink_rcv_skb+0x12c/0x360 netlink_unicast+0x551/0x770 netlink_sendmsg+0x72d/0xbd0 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x52e/0x6a0 ___sys_sendmsg+0xeb/0x170 __sys_sendmsg+0xb5/0x140 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53059", "url": "https://ubuntu.com/security/CVE-2024-53059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd() 1. The size of the response packet is not validated. 2. The response buffer is not freed. Resolve these issues by switching to iwl_mvm_send_cmd_status(), which handles both size validation and frees the buffer.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53074", "url": "https://ubuntu.com/security/CVE-2024-53074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: don't leak a link on AP removal Release the link mapping resource in AP removal. This impacted devices that do not support the MLD API (9260 and down). On those devices, we couldn't start the AP again after the AP has been already started and stopped.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53049", "url": "https://ubuntu.com/security/CVE-2024-53049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slub/kunit: fix a WARNING due to unwrapped __kmalloc_cache_noprof 'modprobe slub_kunit' will have a warning as shown below. The root cause is that __kmalloc_cache_noprof was directly used, which resulted in no alloc_tag being allocated. This caused current->alloc_tag to be null, leading to a warning in alloc_tag_add_check. Let's add an alloc_hook layer to __kmalloc_cache_noprof specifically within lib/slub_kunit.c, which is the only user of this internal slub function outside kmalloc implementation itself. [58162.947016] WARNING: CPU: 2 PID: 6210 at ./include/linux/alloc_tag.h:125 alloc_tagging_slab_alloc_hook+0x268/0x27c [58162.957721] Call trace: [58162.957919] alloc_tagging_slab_alloc_hook+0x268/0x27c [58162.958286] __kmalloc_cache_noprof+0x14c/0x344 [58162.958615] test_kmalloc_redzone_access+0x50/0x10c [slub_kunit] [58162.959045] kunit_try_run_case+0x74/0x184 [kunit] [58162.959401] kunit_generic_run_threadfn_adapter+0x2c/0x4c [kunit] [58162.959841] kthread+0x10c/0x118 [58162.960093] ret_from_fork+0x10/0x20 [58162.960363] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50192", "url": "https://ubuntu.com/security/CVE-2024-50192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v4: Don't allow a VMOVP on a dying VPE Kunkun Jiang reported that there is a small window of opportunity for userspace to force a change of affinity for a VPE while the VPE has already been unmapped, but the corresponding doorbell interrupt still visible in /proc/irq/. Plug the race by checking the value of vmapp_count, which tracks whether the VPE is mapped ot not, and returning an error in this case. This involves making vmapp_count common to both GICv4.1 and its v4.0 ancestor.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50069", "url": "https://ubuntu.com/security/CVE-2024-50069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: apple: check devm_kasprintf() returned value devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked. Fix this lack and check the returned value. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50070", "url": "https://ubuntu.com/security/CVE-2024-50070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: stm32: check devm_kasprintf() returned value devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked. Fix this lack and check the returned value. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50196", "url": "https://ubuntu.com/security/CVE-2024-50196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: ocelot: fix system hang on level based interrupts The current implementation only calls chained_irq_enter() and chained_irq_exit() if it detects pending interrupts. ``` for (i = 0; i < info->stride; i++) { \turegmap_read(info->map, id_reg + 4 * i, ®); \tif (!reg) \t\tcontinue; \tchained_irq_enter(parent_chip, desc); ``` However, in case of GPIO pin configured in level mode and the parent controller configured in edge mode, GPIO interrupt might be lowered by the hardware. In the result, if the interrupt is short enough, the parent interrupt is still pending while the GPIO interrupt is cleared; chained_irq_enter() never gets called and the system hangs trying to service the parent interrupt. Moving chained_irq_enter() and chained_irq_exit() outside the for loop ensures that they are called even when GPIO interrupt is lowered by the hardware. The similar code with chained_irq_enter() / chained_irq_exit() functions wrapping interrupt checking loop may be found in many other drivers: ``` grep -r -A 10 chained_irq_enter drivers/pinctrl ```", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50197", "url": "https://ubuntu.com/security/CVE-2024-50197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: intel: platform: fix error path in device_for_each_child_node() The device_for_each_child_node() loop requires calls to fwnode_handle_put() upon early returns to decrement the refcount of the child node and avoid leaking memory if that error path is triggered. There is one early returns within that loop in intel_platform_pinctrl_prepare_community(), but fwnode_handle_put() is missing. Instead of adding the missing call, the scoped version of the loop can be used to simplify the code and avoid mistakes in the future if new early returns are added, as the child node is only used for parsing, and it is never assigned.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50071", "url": "https://ubuntu.com/security/CVE-2024-50071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: nuvoton: fix a double free in ma35_pinctrl_dt_node_to_map_func() 'new_map' is allocated using devm_* which takes care of freeing the allocated data on device removal, call to \t.dt_free_map = pinconf_generic_dt_free_map double frees the map as pinconf_generic_dt_free_map() calls pinctrl_utils_free_map(). Fix this by using kcalloc() instead of auto-managed devm_kcalloc().", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50072", "url": "https://ubuntu.com/security/CVE-2024-50072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/bugs: Use code segment selector for VERW operand Robert Gill reported below #GP in 32-bit mode when dosemu software was executing vm86() system call: general protection fault: 0000 [#1] PREEMPT SMP CPU: 4 PID: 4610 Comm: dosemu.bin Not tainted 6.6.21-gentoo-x86 #1 Hardware name: Dell Inc. PowerEdge 1950/0H723K, BIOS 2.7.0 10/30/2010 EIP: restore_all_switch_stack+0xbe/0xcf EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000 ESI: 00000000 EDI: 00000000 EBP: 00000000 ESP: ff8affdc DS: 0000 ES: 0000 FS: 0000 GS: 0033 SS: 0068 EFLAGS: 00010046 CR0: 80050033 CR2: 00c2101c CR3: 04b6d000 CR4: 000406d0 Call Trace: show_regs+0x70/0x78 die_addr+0x29/0x70 exc_general_protection+0x13c/0x348 exc_bounds+0x98/0x98 handle_exception+0x14d/0x14d exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf This only happens in 32-bit mode when VERW based mitigations like MDS/RFDS are enabled. This is because segment registers with an arbitrary user value can result in #GP when executing VERW. Intel SDM vol. 2C documents the following behavior for VERW instruction: #GP(0) - If a memory operand effective address is outside the CS, DS, ES, \t FS, or GS segment limit. CLEAR_CPU_BUFFERS macro executes VERW instruction before returning to user space. Use %cs selector to reference VERW operand. This ensures VERW will not #GP for an arbitrary user %ds. [ mingo: Fixed the SOB chain. ]", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50073", "url": "https://ubuntu.com/security/CVE-2024-50073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: Fix use-after-free in gsm_cleanup_mux BUG: KASAN: slab-use-after-free in gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] Read of size 8 at addr ffff88815fe99c00 by task poc/3379 CPU: 0 UID: 0 PID: 3379 Comm: poc Not tainted 6.11.0+ #56 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] __pfx_gsm_cleanup_mux+0x10/0x10 drivers/tty/n_gsm.c:3124 [n_gsm] __pfx_sched_clock_cpu+0x10/0x10 kernel/sched/clock.c:389 update_load_avg+0x1c1/0x27b0 kernel/sched/fair.c:4500 __pfx_min_vruntime_cb_rotate+0x10/0x10 kernel/sched/fair.c:846 __rb_insert_augmented+0x492/0xbf0 lib/rbtree.c:161 gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] _raw_spin_lock_irqsave+0x92/0xf0 arch/x86/include/asm/atomic.h:107 __pfx_gsmld_ioctl+0x10/0x10 drivers/tty/n_gsm.c:3822 [n_gsm] ktime_get+0x5e/0x140 kernel/time/timekeeping.c:195 ldsem_down_read+0x94/0x4e0 arch/x86/include/asm/atomic64_64.h:79 __pfx_ldsem_down_read+0x10/0x10 drivers/tty/tty_ldsem.c:338 __pfx_do_vfs_ioctl+0x10/0x10 fs/ioctl.c:805 tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 Allocated by task 65: gsm_data_alloc.constprop.0+0x27/0x190 drivers/tty/n_gsm.c:926 [n_gsm] gsm_send+0x2c/0x580 drivers/tty/n_gsm.c:819 [n_gsm] gsm1_receive+0x547/0xad0 drivers/tty/n_gsm.c:3038 [n_gsm] gsmld_receive_buf+0x176/0x280 drivers/tty/n_gsm.c:3609 [n_gsm] tty_ldisc_receive_buf+0x101/0x1e0 drivers/tty/tty_buffer.c:391 tty_port_default_receive_buf+0x61/0xa0 drivers/tty/tty_port.c:39 flush_to_ldisc+0x1b0/0x750 drivers/tty/tty_buffer.c:445 process_scheduled_works+0x2b0/0x10d0 kernel/workqueue.c:3229 worker_thread+0x3dc/0x950 kernel/workqueue.c:3391 kthread+0x2a3/0x370 kernel/kthread.c:389 ret_from_fork+0x2d/0x70 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:257 Freed by task 3367: kfree+0x126/0x420 mm/slub.c:4580 gsm_cleanup_mux+0x36c/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 [Analysis] gsm_msg on the tx_ctrl_list or tx_data_list of gsm_mux can be freed by multi threads through ioctl,which leads to the occurrence of uaf. Protect it by gsm tx lock.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50193", "url": "https://ubuntu.com/security/CVE-2024-50193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/entry_32: Clear CPU buffers after register restore in NMI return CPU buffers are currently cleared after call to exc_nmi, but before register state is restored. This may be okay for MDS mitigation but not for RDFS. Because RDFS mitigation requires CPU buffers to be cleared when registers don't have any sensitive data. Move CLEAR_CPU_BUFFERS after RESTORE_ALL_NMI.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50074", "url": "https://ubuntu.com/security/CVE-2024-50074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: parport: Proper fix for array out-of-bounds access The recent fix for array out-of-bounds accesses replaced sprintf() calls blindly with snprintf(). However, since snprintf() returns the would-be-printed size, not the actually output size, the length calculation can still go over the given limit. Use scnprintf() instead of snprintf(), which returns the actually output letters, for addressing the potential out-of-bounds access properly.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50100", "url": "https://ubuntu.com/security/CVE-2024-50100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: gadget: dummy-hcd: Fix \"task hung\" problem The syzbot fuzzer has been encountering \"task hung\" problems ever since the dummy-hcd driver was changed to use hrtimers instead of regular timers. It turns out that the problems are caused by a subtle difference between the timer_pending() and hrtimer_active() APIs. The changeover blindly replaced the first by the second. However, timer_pending() returns True when the timer is queued but not when its callback is running, whereas hrtimer_active() returns True when the hrtimer is queued _or_ its callback is running. This difference occasionally caused dummy_urb_enqueue() to think that the callback routine had not yet started when in fact it was almost finished. As a result the hrtimer was not restarted, which made it impossible for the driver to dequeue later the URB that was just enqueued. This caused usb_kill_urb() to hang, and things got worse from there. Since hrtimers have no API for telling when they are queued and the callback isn't running, the driver must keep track of this for itself. That's what this patch does, adding a new \"timer_pending\" flag and setting or clearing it at the appropriate times.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50075", "url": "https://ubuntu.com/security/CVE-2024-50075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xhci: tegra: fix checked USB2 port number If USB virtualizatoin is enabled, USB2 ports are shared between all Virtual Functions. The USB2 port number owned by an USB2 root hub in a Virtual Function may be less than total USB2 phy number supported by the Tegra XUSB controller. Using total USB2 phy number as port number to check all PORTSC values would cause invalid memory access. [ 116.923438] Unable to handle kernel paging request at virtual address 006c622f7665642f ... [ 117.213640] Call trace: [ 117.216783] tegra_xusb_enter_elpg+0x23c/0x658 [ 117.222021] tegra_xusb_runtime_suspend+0x40/0x68 [ 117.227260] pm_generic_runtime_suspend+0x30/0x50 [ 117.232847] __rpm_callback+0x84/0x3c0 [ 117.237038] rpm_suspend+0x2dc/0x740 [ 117.241229] pm_runtime_work+0xa0/0xb8 [ 117.245769] process_scheduled_works+0x24c/0x478 [ 117.251007] worker_thread+0x23c/0x328 [ 117.255547] kthread+0x104/0x1b0 [ 117.259389] ret_from_fork+0x10/0x20 [ 117.263582] Code: 54000222 f9461ae8 f8747908 b4ffff48 (f9400100)", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50076", "url": "https://ubuntu.com/security/CVE-2024-50076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vt: prevent kernel-infoleak in con_font_get() font.data may not initialize all memory spaces depending on the implementation of vc->vc_sw->con_font_get. This may cause info-leak, so to prevent this, it is safest to modify it to initialize the allocated memory space to 0, and it generally does not affect the overall performance of the system.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50077", "url": "https://ubuntu.com/security/CVE-2024-50077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix multiple init when debugfs is disabled If bt_debugfs is not created successfully, which happens if either CONFIG_DEBUG_FS or CONFIG_DEBUG_FS_ALLOW_ALL is unset, then iso_init() returns early and does not set iso_inited to true. This means that a subsequent call to iso_init() will result in duplicate calls to proto_register(), bt_sock_register(), etc. With CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, the duplicate call to proto_register() triggers this BUG(): list_add double add: new=ffffffffc0b280d0, prev=ffffffffbab56250, next=ffffffffc0b280d0. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:35! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 2 PID: 887 Comm: bluetoothd Not tainted 6.10.11-1-ao-desktop #1 RIP: 0010:__list_add_valid_or_report+0x9a/0xa0 ... __list_add_valid_or_report+0x9a/0xa0 proto_register+0x2b5/0x340 iso_init+0x23/0x150 [bluetooth] set_iso_socket_func+0x68/0x1b0 [bluetooth] kmem_cache_free+0x308/0x330 hci_sock_sendmsg+0x990/0x9e0 [bluetooth] __sock_sendmsg+0x7b/0x80 sock_write_iter+0x9a/0x110 do_iter_readv_writev+0x11d/0x220 vfs_writev+0x180/0x3e0 do_writev+0xca/0x100 ... This change removes the early return. The check for iso_debugfs being NULL was unnecessary, it is always NULL when iso_inited is false.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50078", "url": "https://ubuntu.com/security/CVE-2024-50078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Call iso_exit() on module unload If iso_init() has been called, iso_exit() must be called on module unload. Without that, the struct proto that iso_init() registered with proto_register() becomes invalid, which could cause unpredictable problems later. In my case, with CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, loading the module again usually triggers this BUG(): list_add corruption. next->prev should be prev (ffffffffb5355fd0), but was 0000000000000068. (next=ffffffffc0a010d0). ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:29! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 4159 Comm: modprobe Not tainted 6.10.11-4+bt2-ao-desktop #1 RIP: 0010:__list_add_valid_or_report+0x61/0xa0 ... __list_add_valid_or_report+0x61/0xa0 proto_register+0x299/0x320 hci_sock_init+0x16/0xc0 [bluetooth] bt_init+0x68/0xd0 [bluetooth] __pfx_bt_init+0x10/0x10 [bluetooth] do_one_initcall+0x80/0x2f0 do_init_module+0x8b/0x230 __do_sys_init_module+0x15f/0x190 do_syscall_64+0x68/0x110 ...", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50198", "url": "https://ubuntu.com/security/CVE-2024-50198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: veml6030: fix IIO device retrieval from embedded device The dev pointer that is received as an argument in the in_illuminance_period_available_show function references the device embedded in the IIO device, not in the i2c client. dev_to_iio_dev() must be used to accessthe right data. The current implementation leads to a segmentation fault on every attempt to read the attribute because indio_dev gets a NULL assignment. This bug has been present since the first appearance of the driver, apparently since the last version (V6) before getting applied. A constant attribute was used until then, and the last modifications might have not been tested again.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50201", "url": "https://ubuntu.com/security/CVE-2024-50201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: Fix encoder->possible_clones Include the encoder itself in its possible_clones bitmask. In the past nothing validated that drivers were populating possible_clones correctly, but that changed in commit 74d2aacbe840 (\"drm: Validate encoder->possible_clones\"). Looks like radeon never got the memo and is still not following the rules 100% correctly. This results in some warnings during driver initialization: Bogus possible_clones: [ENCODER:46:TV-46] possible_clones=0x4 (full encoder mask=0x7) WARNING: CPU: 0 PID: 170 at drivers/gpu/drm/drm_mode_config.c:615 drm_mode_config_validate+0x113/0x39c ... (cherry picked from commit 3b6e7d40649c0d75572039aff9d0911864c689db)", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50098", "url": "https://ubuntu.com/security/CVE-2024-50098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Set SDEV_OFFLINE when UFS is shut down There is a history of deadlock if reboot is performed at the beginning of booting. SDEV_QUIESCE was set for all LU's scsi_devices by UFS shutdown, and at that time the audio driver was waiting on blk_mq_submit_bio() holding a mutex_lock while reading the fw binary. After that, a deadlock issue occurred while audio driver shutdown was waiting for mutex_unlock of blk_mq_submit_bio(). To solve this, set SDEV_OFFLINE for all LUs except WLUN, so that any I/O that comes down after a UFS shutdown will return an error. [ 31.907781]I[0: swapper/0: 0] 1 130705007 1651079834 11289729804 0 D( 2) 3 ffffff882e208000 * init [device_shutdown] [ 31.907793]I[0: swapper/0: 0] Mutex: 0xffffff8849a2b8b0: owner[0xffffff882e28cb00 kworker/6:0 :49] [ 31.907806]I[0: swapper/0: 0] Call trace: [ 31.907810]I[0: swapper/0: 0] __switch_to+0x174/0x338 [ 31.907819]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc [ 31.907826]I[0: swapper/0: 0] schedule+0x7c/0xe8 [ 31.907834]I[0: swapper/0: 0] schedule_preempt_disabled+0x24/0x40 [ 31.907842]I[0: swapper/0: 0] __mutex_lock+0x408/0xdac [ 31.907849]I[0: swapper/0: 0] __mutex_lock_slowpath+0x14/0x24 [ 31.907858]I[0: swapper/0: 0] mutex_lock+0x40/0xec [ 31.907866]I[0: swapper/0: 0] device_shutdown+0x108/0x280 [ 31.907875]I[0: swapper/0: 0] kernel_restart+0x4c/0x11c [ 31.907883]I[0: swapper/0: 0] __arm64_sys_reboot+0x15c/0x280 [ 31.907890]I[0: swapper/0: 0] invoke_syscall+0x70/0x158 [ 31.907899]I[0: swapper/0: 0] el0_svc_common+0xb4/0xf4 [ 31.907909]I[0: swapper/0: 0] do_el0_svc+0x2c/0xb0 [ 31.907918]I[0: swapper/0: 0] el0_svc+0x34/0xe0 [ 31.907928]I[0: swapper/0: 0] el0t_64_sync_handler+0x68/0xb4 [ 31.907937]I[0: swapper/0: 0] el0t_64_sync+0x1a0/0x1a4 [ 31.908774]I[0: swapper/0: 0] 49 0 11960702 11236868007 0 D( 2) 6 ffffff882e28cb00 * kworker/6:0 [__bio_queue_enter] [ 31.908783]I[0: swapper/0: 0] Call trace: [ 31.908788]I[0: swapper/0: 0] __switch_to+0x174/0x338 [ 31.908796]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc [ 31.908803]I[0: swapper/0: 0] schedule+0x7c/0xe8 [ 31.908811]I[0: swapper/0: 0] __bio_queue_enter+0xb8/0x178 [ 31.908818]I[0: swapper/0: 0] blk_mq_submit_bio+0x194/0x67c [ 31.908827]I[0: swapper/0: 0] __submit_bio+0xb8/0x19c", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50079", "url": "https://ubuntu.com/security/CVE-2024-50079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/sqpoll: ensure task state is TASK_RUNNING when running task_work When the sqpoll is exiting and cancels pending work items, it may need to run task_work. If this happens from within io_uring_cancel_generic(), then it may be under waiting for the io_uring_task waitqueue. This results in the below splat from the scheduler, as the ring mutex may be attempted grabbed while in a TASK_INTERRUPTIBLE state. Ensure that the task state is set appropriately for that, just like what is done for the other cases in io_run_task_work(). do not call blocking ops when !TASK_RUNNING; state=1 set at [<0000000029387fd2>] prepare_to_wait+0x88/0x2fc WARNING: CPU: 6 PID: 59939 at kernel/sched/core.c:8561 __might_sleep+0xf4/0x140 Modules linked in: CPU: 6 UID: 0 PID: 59939 Comm: iou-sqp-59938 Not tainted 6.12.0-rc3-00113-g8d020023b155 #7456 Hardware name: linux,dummy-virt (DT) pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : __might_sleep+0xf4/0x140 lr : __might_sleep+0xf4/0x140 sp : ffff80008c5e7830 x29: ffff80008c5e7830 x28: ffff0000d93088c0 x27: ffff60001c2d7230 x26: dfff800000000000 x25: ffff0000e16b9180 x24: ffff80008c5e7a50 x23: 1ffff000118bcf4a x22: ffff0000e16b9180 x21: ffff0000e16b9180 x20: 000000000000011b x19: ffff80008310fac0 x18: 1ffff000118bcd90 x17: 30303c5b20746120 x16: 74657320313d6574 x15: 0720072007200720 x14: 0720072007200720 x13: 0720072007200720 x12: ffff600036c64f0b x11: 1fffe00036c64f0a x10: ffff600036c64f0a x9 : dfff800000000000 x8 : 00009fffc939b0f6 x7 : ffff0001b6327853 x6 : 0000000000000001 x5 : ffff0001b6327850 x4 : ffff600036c64f0b x3 : ffff8000803c35bc x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000e16b9180 Call trace: __might_sleep+0xf4/0x140 mutex_lock+0x84/0x124 io_handle_tw_list+0xf4/0x260 tctx_task_work_run+0x94/0x340 io_run_task_work+0x1ec/0x3c0 io_uring_cancel_generic+0x364/0x524 io_sq_thread+0x820/0x124c ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50080", "url": "https://ubuntu.com/security/CVE-2024-50080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: don't allow user copy for unprivileged device UBLK_F_USER_COPY requires userspace to call write() on ublk char device for filling request buffer, and unprivileged device can't be trusted. So don't allow user copy for unprivileged device.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50081", "url": "https://ubuntu.com/security/CVE-2024-50081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-mq: setup queue ->tag_set before initializing hctx Commit 7b815817aa58 (\"blk-mq: add helper for checking if one CPU is mapped to specified hctx\") needs to check queue mapping via tag set in hctx's cpuhp handler. However, q->tag_set may not be setup yet when the cpuhp handler is enabled, then kernel oops is triggered. Fix the issue by setup queue tag_set before initializing hctx.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50082", "url": "https://ubuntu.com/security/CVE-2024-50082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race We're seeing crashes from rq_qos_wake_function that look like this: BUG: unable to handle page fault for address: ffffafe180a40084 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 100000067 P4D 100000067 PUD 10027c067 PMD 10115d067 PTE 0 Oops: Oops: 0002 [#1] PREEMPT SMP PTI CPU: 17 UID: 0 PID: 0 Comm: swapper/17 Not tainted 6.12.0-rc3-00013-geca631b8fe80 #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:_raw_spin_lock_irqsave+0x1d/0x40 Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 9c 41 5c fa 65 ff 05 62 97 30 4c 31 c0 ba 01 00 00 00 0f b1 17 75 0a 4c 89 e0 41 5c c3 cc cc cc cc 89 c6 e8 2c 0b 00 RSP: 0018:ffffafe180580ca0 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffffafe180a3f7a8 RCX: 0000000000000011 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffffafe180a40084 RBP: 0000000000000000 R08: 00000000001e7240 R09: 0000000000000011 R10: 0000000000000028 R11: 0000000000000888 R12: 0000000000000002 R13: ffffafe180a40084 R14: 0000000000000000 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff9aaf1f280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffafe180a40084 CR3: 000000010e428002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: try_to_wake_up+0x5a/0x6a0 rq_qos_wake_function+0x71/0x80 __wake_up_common+0x75/0xa0 __wake_up+0x36/0x60 scale_up.part.0+0x50/0x110 wb_timer_fn+0x227/0x450 ... So rq_qos_wake_function() calls wake_up_process(data->task), which calls try_to_wake_up(), which faults in raw_spin_lock_irqsave(&p->pi_lock). p comes from data->task, and data comes from the waitqueue entry, which is stored on the waiter's stack in rq_qos_wait(). Analyzing the core dump with drgn, I found that the waiter had already woken up and moved on to a completely unrelated code path, clobbering what was previously data->task. Meanwhile, the waker was passing the clobbered garbage in data->task to wake_up_process(), leading to the crash. What's happening is that in between rq_qos_wake_function() deleting the waitqueue entry and calling wake_up_process(), rq_qos_wait() is finding that it already got a token and returning. The race looks like this: rq_qos_wait() rq_qos_wake_function() ============================================================== prepare_to_wait_exclusive() data->got_token = true; list_del_init(&curr->entry); if (data.got_token) break; finish_wait(&rqw->wait, &data.wq); ^- returns immediately because list_empty_careful(&wq_entry->entry) is true ... return, go do something else ... wake_up_process(data->task) (NO LONGER VALID!)-^ Normally, finish_wait() is supposed to synchronize against the waker. But, as noted above, it is returning immediately because the waitqueue entry has already been removed from the waitqueue. The bug is that rq_qos_wake_function() is accessing the waitqueue entry AFTER deleting it. Note that autoremove_wake_function() wakes the waiter and THEN deletes the waitqueue entry, which is the proper order. Fix it by swapping the order. We also need to use list_del_init_careful() to match the list_empty_careful() in finish_wait().", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50101", "url": "https://ubuntu.com/security/CVE-2024-50101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI devices Previously, the domain_context_clear() function incorrectly called pci_for_each_dma_alias() to set up context entries for non-PCI devices. This could lead to kernel hangs or other unexpected behavior. Add a check to only call pci_for_each_dma_alias() for PCI devices. For non-PCI devices, domain_context_clear_one() is called directly.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50083", "url": "https://ubuntu.com/security/CVE-2024-50083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix mptcp DSS corruption due to large pmtu xmit Syzkaller was able to trigger a DSS corruption: TCP: request_sock_subflow_v4: Possible SYN flooding on port [::]:20002. Sending cookies. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 5227 at net/mptcp/protocol.c:695 __mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695 Modules linked in: CPU: 0 UID: 0 PID: 5227 Comm: syz-executor350 Not tainted 6.11.0-syzkaller-08829-gaf9c191ac2a0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:__mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695 Code: 0f b6 dc 31 ff 89 de e8 b5 dd ea f5 89 d8 48 81 c4 50 01 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 98 da ea f5 90 <0f> 0b 90 e9 47 ff ff ff e8 8a da ea f5 90 0f 0b 90 e9 99 e0 ff ff RSP: 0018:ffffc90000006db8 EFLAGS: 00010246 RAX: ffffffff8ba9df18 RBX: 00000000000055f0 RCX: ffff888030023c00 RDX: 0000000000000100 RSI: 00000000000081e5 RDI: 00000000000055f0 RBP: 1ffff110062bf1ae R08: ffffffff8ba9cf12 R09: 1ffff110062bf1b8 R10: dffffc0000000000 R11: ffffed10062bf1b9 R12: 0000000000000000 R13: dffffc0000000000 R14: 00000000700cec61 R15: 00000000000081e5 FS: 000055556679c380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020287000 CR3: 0000000077892000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: move_skbs_to_msk net/mptcp/protocol.c:811 [inline] mptcp_data_ready+0x29c/0xa90 net/mptcp/protocol.c:854 subflow_data_ready+0x34a/0x920 net/mptcp/subflow.c:1490 tcp_data_queue+0x20fd/0x76c0 net/ipv4/tcp_input.c:5283 tcp_rcv_established+0xfba/0x2020 net/ipv4/tcp_input.c:6237 tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915 tcp_v4_rcv+0x2dc0/0x37f0 net/ipv4/tcp_ipv4.c:2350 ip_protocol_deliver_rcu+0x22e/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x341/0x5f0 net/ipv4/ip_input.c:233 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314 __netif_receive_skb_one_core net/core/dev.c:5662 [inline] __netif_receive_skb+0x2bf/0x650 net/core/dev.c:5775 process_backlog+0x662/0x15b0 net/core/dev.c:6107 __napi_poll+0xcb/0x490 net/core/dev.c:6771 napi_poll net/core/dev.c:6840 [inline] net_rx_action+0x89b/0x1240 net/core/dev.c:6962 handle_softirqs+0x2c5/0x980 kernel/softirq.c:554 do_softirq+0x11b/0x1e0 kernel/softirq.c:455 __local_bh_enable_ip+0x1bb/0x200 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0x1764/0x3e80 net/core/dev.c:4451 dev_queue_xmit include/linux/netdevice.h:3094 [inline] neigh_hh_output include/net/neighbour.h:526 [inline] neigh_output include/net/neighbour.h:540 [inline] ip_finish_output2+0xd41/0x1390 net/ipv4/ip_output.c:236 ip_local_out net/ipv4/ip_output.c:130 [inline] __ip_queue_xmit+0x118c/0x1b80 net/ipv4/ip_output.c:536 __tcp_transmit_skb+0x2544/0x3b30 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_mtu_probe net/ipv4/tcp_output.c:2547 [inline] tcp_write_xmit+0x641d/0x6bf0 net/ipv4/tcp_output.c:2752 __tcp_push_pending_frames+0x9b/0x360 net/ipv4/tcp_output.c:3015 tcp_push_pending_frames include/net/tcp.h:2107 [inline] tcp_data_snd_check net/ipv4/tcp_input.c:5714 [inline] tcp_rcv_established+0x1026/0x2020 net/ipv4/tcp_input.c:6239 tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915 sk_backlog_rcv include/net/sock.h:1113 [inline] __release_sock+0x214/0x350 net/core/sock.c:3072 release_sock+0x61/0x1f0 net/core/sock.c:3626 mptcp_push_ ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50068", "url": "https://ubuntu.com/security/CVE-2024-50068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/tests/sysfs-kunit.h: fix memory leak in damon_sysfs_test_add_targets() The sysfs_target->regions allocated in damon_sysfs_regions_alloc() is not freed in damon_sysfs_test_add_targets(), which cause the following memory leak, free it to fix it. \tunreferenced object 0xffffff80c2a8db80 (size 96): \t comm \"kunit_try_catch\", pid 187, jiffies 4294894363 \t hex dump (first 32 bytes): \t 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ \t 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ \t backtrace (crc 0): \t [<0000000001e3714d>] kmemleak_alloc+0x34/0x40 \t [<000000008e6835c1>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000001286d9f8>] damon_sysfs_test_add_targets+0x1cc/0x738 \t [<0000000032ef8f77>] kunit_try_run_case+0x13c/0x3ac \t [<00000000f3edea23>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000adf936cf>] kthread+0x2e8/0x374 \t [<0000000041bb1628>] ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50199", "url": "https://ubuntu.com/security/CVE-2024-50199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/swapfile: skip HugeTLB pages for unuse_vma I got a bad pud error and lost a 1GB HugeTLB when calling swapoff. The problem can be reproduced by the following steps: 1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory. 2. Swapout the above anonymous memory. 3. run swapoff and we will get a bad pud error in kernel message: mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7) We can tell that pud_clear_bad is called by pud_none_or_clear_bad in unuse_pud_range() by ftrace. And therefore the HugeTLB pages will never be freed because we lost it from page table. We can skip HugeTLB pages for unuse_vma to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50066", "url": "https://ubuntu.com/security/CVE-2024-50066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mremap: fix move_normal_pmd/retract_page_tables race In mremap(), move_page_tables() looks at the type of the PMD entry and the specified address range to figure out by which method the next chunk of page table entries should be moved. At that point, the mmap_lock is held in write mode, but no rmap locks are held yet. For PMD entries that point to page tables and are fully covered by the source address range, move_pgt_entry(NORMAL_PMD, ...) is called, which first takes rmap locks, then does move_normal_pmd(). move_normal_pmd() takes the necessary page table locks at source and destination, then moves an entire page table from the source to the destination. The problem is: The rmap locks, which protect against concurrent page table removal by retract_page_tables() in the THP code, are only taken after the PMD entry has been read and it has been decided how to move it. So we can race as follows (with two processes that have mappings of the same tmpfs file that is stored on a tmpfs mount with huge=advise); note that process A accesses page tables through the MM while process B does it through the file rmap: process A process B ========= ========= mremap mremap_to move_vma move_page_tables get_old_pmd alloc_new_pmd *** PREEMPT *** madvise(MADV_COLLAPSE) do_madvise madvise_walk_vmas madvise_vma_behavior madvise_collapse hpage_collapse_scan_file collapse_file retract_page_tables i_mmap_lock_read(mapping) pmdp_collapse_flush i_mmap_unlock_read(mapping) move_pgt_entry(NORMAL_PMD, ...) take_rmap_locks move_normal_pmd drop_rmap_locks When this happens, move_normal_pmd() can end up creating bogus PMD entries in the line `pmd_populate(mm, new_pmd, pmd_pgtable(pmd))`. The effect depends on arch-specific and machine-specific details; on x86, you can end up with physical page 0 mapped as a page table, which is likely exploitable for user->kernel privilege escalation. Fix the race by letting process B recheck that the PMD still points to a page table after the rmap locks have been taken. Otherwise, we bail and let the caller fall back to the PTE-level copying path, which will then bail immediately at the pmd_none() check. Bug reachability: Reaching this bug requires that you can create shmem/file THP mappings - anonymous THP uses different code that doesn't zap stuff under rmap locks. File THP is gated on an experimental config flag (CONFIG_READ_ONLY_THP_FOR_FS), so on normal distro kernels you need shmem THP to hit this bug. As far as I know, getting shmem THP normally requires that you can mount your own tmpfs with the right mount flags, which would require creating your own user+mount namespace; though I don't know if some distros maybe enable shmem THP by default or something like that. Bug impact: This issue can likely be used for user->kernel privilege escalation when it is reachable.", "cve_priority": "medium", "cve_public_date": "2024-10-23 06:15:00 UTC" }, { "cve": "CVE-2024-50202", "url": "https://ubuntu.com/security/CVE-2024-50202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: propagate directory read errors from nilfs_find_entry() Syzbot reported that a task hang occurs in vcs_open() during a fuzzing test for nilfs2. The root cause of this problem is that in nilfs_find_entry(), which searches for directory entries, ignores errors when loading a directory page/folio via nilfs_get_folio() fails. If the filesystem images is corrupted, and the i_size of the directory inode is large, and the directory page/folio is successfully read but fails the sanity check, for example when it is zero-filled, nilfs_check_folio() may continue to spit out error messages in bursts. Fix this issue by propagating the error to the callers when loading a page/folio fails in nilfs_find_entry(). The current interface of nilfs_find_entry() and its callers is outdated and cannot propagate error codes such as -EIO and -ENOMEM returned via nilfs_find_entry(), so fix it together.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50200", "url": "https://ubuntu.com/security/CVE-2024-50200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: maple_tree: correct tree corruption on spanning store Patch series \"maple_tree: correct tree corruption on spanning store\", v3. There has been a nasty yet subtle maple tree corruption bug that appears to have been in existence since the inception of the algorithm. This bug seems far more likely to happen since commit f8d112a4e657 (\"mm/mmap: avoid zeroing vma tree in mmap_region()\"), which is the point at which reports started to be submitted concerning this bug. We were made definitely aware of the bug thanks to the kind efforts of Bert Karwatzki who helped enormously in my being able to track this down and identify the cause of it. The bug arises when an attempt is made to perform a spanning store across two leaf nodes, where the right leaf node is the rightmost child of the shared parent, AND the store completely consumes the right-mode node. This results in mas_wr_spanning_store() mitakenly duplicating the new and existing entries at the maximum pivot within the range, and thus maple tree corruption. The fix patch corrects this by detecting this scenario and disallowing the mistaken duplicate copy. The fix patch commit message goes into great detail as to how this occurs. This series also includes a test which reliably reproduces the issue, and asserts that the fix works correctly. Bert has kindly tested the fix and confirmed it resolved his issues. Also Mikhail Gavrilov kindly reported what appears to be precisely the same bug, which this fix should also resolve. This patch (of 2): There has been a subtle bug present in the maple tree implementation from its inception. This arises from how stores are performed - when a store occurs, it will overwrite overlapping ranges and adjust the tree as necessary to accommodate this. A range may always ultimately span two leaf nodes. In this instance we walk the two leaf nodes, determine which elements are not overwritten to the left and to the right of the start and end of the ranges respectively and then rebalance the tree to contain these entries and the newly inserted one. This kind of store is dubbed a 'spanning store' and is implemented by mas_wr_spanning_store(). In order to reach this stage, mas_store_gfp() invokes mas_wr_preallocate(), mas_wr_store_type() and mas_wr_walk() in turn to walk the tree and update the object (mas) to traverse to the location where the write should be performed, determining its store type. When a spanning store is required, this function returns false stopping at the parent node which contains the target range, and mas_wr_store_type() marks the mas->store_type as wr_spanning_store to denote this fact. When we go to perform the store in mas_wr_spanning_store(), we first determine the elements AFTER the END of the range we wish to store (that is, to the right of the entry to be inserted) - we do this by walking to the NEXT pivot in the tree (i.e. r_mas.last + 1), starting at the node we have just determined contains the range over which we intend to write. We then turn our attention to the entries to the left of the entry we are inserting, whose state is represented by l_mas, and copy these into a 'big node', which is a special node which contains enough slots to contain two leaf node's worth of data. We then copy the entry we wish to store immediately after this - the copy and the insertion of the new entry is performed by mas_store_b_node(). After this we copy the elements to the right of the end of the range which we are inserting, if we have not exceeded the length of the node (i.e. r_mas.offset <= r_mas.end). Herein lies the bug - under very specific circumstances, this logic can break and corrupt the maple tree. Consider the following tree: Height 0 Root Node / \\ pivot = 0xffff / \\ pivot = ULONG_MAX / ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50084", "url": "https://ubuntu.com/security/CVE-2024-50084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: microchip: vcap api: Fix memory leaks in vcap_api_encode_rule_test() Commit a3c1e45156ad (\"net: microchip: vcap: Fix use-after-free error in kunit test\") fixed the use-after-free error, but introduced below memory leaks by removing necessary vcap_free_rule(), add it to fix it. \tunreferenced object 0xffffff80ca58b700 (size 192): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898264 \t hex dump (first 32 bytes): \t 00 12 7a 00 05 00 00 00 0a 00 00 00 64 00 00 00 ..z.........d... \t 00 00 00 00 00 00 00 00 00 04 0b cc 80 ff ff ff ................ \t backtrace (crc 9c09c3fe): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<0000000040a01b8d>] vcap_alloc_rule+0x3cc/0x9c4 \t [<000000003fe86110>] vcap_api_encode_rule_test+0x1ac/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0400 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898265 \t hex dump (first 32 bytes): \t 80 04 0b cc 80 ff ff ff 18 b7 58 ca 80 ff ff ff ..........X..... \t 39 00 00 00 02 00 00 00 06 05 04 03 02 01 ff ff 9............... \t backtrace (crc daf014e9): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<00000000dfdb1e81>] vcap_api_encode_rule_test+0x224/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0700 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898265 \t hex dump (first 32 bytes): \t 80 07 0b cc 80 ff ff ff 28 b7 58 ca 80 ff ff ff ........(.X..... \t 3c 00 00 00 00 00 00 00 01 2f 03 b3 ec ff ff ff <......../...... \t backtrace (crc 8d877792): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000006eadfab7>] vcap_rule_add_action+0x2d0/0x52c \t [<00000000323475d1>] vcap_api_encode_rule_test+0x4d4/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0900 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898266 \t hex dump (first 32 bytes): \t 80 09 0b cc 80 ff ff ff 80 06 0b cc 80 ff ff ff ................ \t 7d 00 00 00 01 00 00 00 00 00 00 00 ff 00 00 00 }............... \t backtrace (crc 34181e56): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<00000000991e3564>] vcap_val_rule+0xcf0/0x13e8 \t [<00000000fc9868e5>] vcap_api_encode_rule_test+0x678/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0980 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898266 \t hex dump (first 32 bytes): \t 18 b7 58 ca 80 ff ff ff 00 09 0b cc 80 ff ff ff ..X............. \t 67 00 00 00 00 00 00 00 01 01 74 88 c0 ff ff ff g.........t..... \t backtrace (crc 275fd9be): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<000000001396a1a2>] test_add_de ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50194", "url": "https://ubuntu.com/security/CVE-2024-50194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Fix uprobes for big-endian kernels The arm64 uprobes code is broken for big-endian kernels as it doesn't convert the in-memory instruction encoding (which is always little-endian) into the kernel's native endianness before analyzing and simulating instructions. This may result in a few distinct problems: * The kernel may may erroneously reject probing an instruction which can safely be probed. * The kernel may erroneously erroneously permit stepping an instruction out-of-line when that instruction cannot be stepped out-of-line safely. * The kernel may erroneously simulate instruction incorrectly dur to interpretting the byte-swapped encoding. The endianness mismatch isn't caught by the compiler or sparse because: * The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so the compiler and sparse have no idea these contain a little-endian 32-bit value. The core uprobes code populates these with a memcpy() which similarly does not handle endianness. * While the uprobe_opcode_t type is an alias for __le32, both arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[] to the similarly-named probe_opcode_t, which is an alias for u32. Hence there is no endianness conversion warning. Fix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and adding the appropriate __le32_to_cpu() conversions prior to consuming the instruction encoding. The core uprobes copies these fields as opaque ranges of bytes, and so is unaffected by this change. At the same time, remove MAX_UINSN_BYTES and consistently use AARCH64_INSN_SIZE for clarity. Tested with the following: | #include | #include | | #define noinline __attribute__((noinline)) | | static noinline void *adrp_self(void) | { | void *addr; | | asm volatile( | \" adrp %x0, adrp_self\\n\" | \" add %x0, %x0, :lo12:adrp_self\\n\" | : \"=r\" (addr)); | } | | | int main(int argc, char *argv) | { | void *ptr = adrp_self(); | bool equal = (ptr == adrp_self); | | printf(\"adrp_self => %p\\n\" | \"adrp_self() => %p\\n\" | \"%s\\n\", | adrp_self, ptr, equal ? \"EQUAL\" : \"NOT EQUAL\"); | | return 0; | } .... where the adrp_self() function was compiled to: | 00000000004007e0 : | 4007e0: 90000000 adrp x0, 400000 <__ehdr_start> | 4007e4: 911f8000 add x0, x0, #0x7e0 | 4007e8: d65f03c0 ret Before this patch, the ADRP is not recognized, and is assumed to be steppable, resulting in corruption of the result: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0xffffffffff7e0 | NOT EQUAL After this patch, the ADRP is correctly recognized and simulated: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50099", "url": "https://ubuntu.com/security/CVE-2024-50099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Remove broken LDR (literal) uprobe support The simulate_ldr_literal() and simulate_ldrsw_literal() functions are unsafe to use for uprobes. Both functions were originally written for use with kprobes, and access memory with plain C accesses. When uprobes was added, these were reused unmodified even though they cannot safely access user memory. There are three key problems: 1) The plain C accesses do not have corresponding extable entries, and thus if they encounter a fault the kernel will treat these as unintentional accesses to user memory, resulting in a BUG() which will kill the kernel thread, and likely lead to further issues (e.g. lockup or panic()). 2) The plain C accesses are subject to HW PAN and SW PAN, and so when either is in use, any attempt to simulate an access to user memory will fault. Thus neither simulate_ldr_literal() nor simulate_ldrsw_literal() can do anything useful when simulating a user instruction on any system with HW PAN or SW PAN. 3) The plain C accesses are privileged, as they run in kernel context, and in practice can access a small range of kernel virtual addresses. The instructions they simulate have a range of +/-1MiB, and since the simulated instructions must itself be a user instructions in the TTBR0 address range, these can address the final 1MiB of the TTBR1 acddress range by wrapping downwards from an address in the first 1MiB of the TTBR0 address range. In contemporary kernels the last 8MiB of TTBR1 address range is reserved, and accesses to this will always fault, meaning this is no worse than (1). Historically, it was theoretically possible for the linear map or vmemmap to spill into the final 8MiB of the TTBR1 address range, but in practice this is extremely unlikely to occur as this would require either: * Having enough physical memory to fill the entire linear map all the way to the final 1MiB of the TTBR1 address range. * Getting unlucky with KASLR randomization of the linear map such that the populated region happens to overlap with the last 1MiB of the TTBR address range. ... and in either case if we were to spill into the final page there would be larger problems as the final page would alias with error pointers. Practically speaking, (1) and (2) are the big issues. Given there have been no reports of problems since the broken code was introduced, it appears that no-one is relying on probing these instructions with uprobes. Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW (literal), limiting the use of simulate_ldr_literal() and simulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR (literal) and LDRSW (literal) will be rejected as arm_probe_decode_insn() will return INSN_REJECTED. In future we can consider introducing working uprobes support for these instructions, but this will require more significant work.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50195", "url": "https://ubuntu.com/security/CVE-2024-50195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-clock: Fix missing timespec64 check in pc_clock_settime() As Andrew pointed out, it will make sense that the PTP core checked timespec64 struct's tv_sec and tv_nsec range before calling ptp->info->settime64(). As the man manual of clock_settime() said, if tp.tv_sec is negative or tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL, which include dynamic clocks which handles PTP clock, and the condition is consistent with timespec64_valid(). As Thomas suggested, timespec64_valid() only check the timespec is valid, but not ensure that the time is in a valid range, so check it ahead using timespec64_valid_strict() in pc_clock_settime() and return -EINVAL if not valid. There are some drivers that use tp->tv_sec and tp->tv_nsec directly to write registers without validity checks and assume that the higher layer has checked it, which is dangerous and will benefit from this, such as hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(), and some drivers can remove the checks of itself.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50085", "url": "https://ubuntu.com/security/CVE-2024-50085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: fix UaF read in mptcp_pm_nl_rm_addr_or_subflow Syzkaller reported this splat: ================================================================== BUG: KASAN: slab-use-after-free in mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881 Read of size 4 at addr ffff8880569ac858 by task syz.1.2799/14662 CPU: 0 UID: 0 PID: 14662 Comm: syz.1.2799 Not tainted 6.12.0-rc2-syzkaller-00307-g36c254515dc6 #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+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881 mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:914 [inline] mptcp_nl_remove_id_zero_address+0x305/0x4a0 net/mptcp/pm_netlink.c:1572 mptcp_pm_nl_del_addr_doit+0x5c9/0x770 net/mptcp/pm_netlink.c:1603 genl_family_rcv_msg_doit+0x202/0x2f0 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x565/0x800 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x165/0x410 net/netlink/af_netlink.c:2551 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1331 [inline] netlink_unicast+0x53c/0x7f0 net/netlink/af_netlink.c:1357 netlink_sendmsg+0x8b8/0xd70 net/netlink/af_netlink.c:1901 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg net/socket.c:744 [inline] ____sys_sendmsg+0x9ae/0xb40 net/socket.c:2607 ___sys_sendmsg+0x135/0x1e0 net/socket.c:2661 __sys_sendmsg+0x117/0x1f0 net/socket.c:2690 do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline] __do_fast_syscall_32+0x73/0x120 arch/x86/entry/common.c:386 do_fast_syscall_32+0x32/0x80 arch/x86/entry/common.c:411 entry_SYSENTER_compat_after_hwframe+0x84/0x8e RIP: 0023:0xf7fe4579 Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00 RSP: 002b:00000000f574556c EFLAGS: 00000296 ORIG_RAX: 0000000000000172 RAX: ffffffffffffffda RBX: 000000000000000b RCX: 0000000020000140 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000296 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Allocated by task 5387: 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 kmalloc_noprof include/linux/slab.h:878 [inline] kzalloc_noprof include/linux/slab.h:1014 [inline] subflow_create_ctx+0x87/0x2a0 net/mptcp/subflow.c:1803 subflow_ulp_init+0xc3/0x4d0 net/mptcp/subflow.c:1956 __tcp_set_ulp net/ipv4/tcp_ulp.c:146 [inline] tcp_set_ulp+0x326/0x7f0 net/ipv4/tcp_ulp.c:167 mptcp_subflow_create_socket+0x4ae/0x10a0 net/mptcp/subflow.c:1764 __mptcp_subflow_connect+0x3cc/0x1490 net/mptcp/subflow.c:1592 mptcp_pm_create_subflow_or_signal_addr+0xbda/0x23a0 net/mptcp/pm_netlink.c:642 mptcp_pm_nl_fully_established net/mptcp/pm_netlink.c:650 [inline] mptcp_pm_nl_work+0x3a1/0x4f0 net/mptcp/pm_netlink.c:943 mptcp_worker+0x15a/0x1240 net/mptcp/protocol.c:2777 process_one_work+0x958/0x1b30 kernel/workqueue.c:3229 process_scheduled_works kernel/workqueue.c:3310 [inline] worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/ke ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50086", "url": "https://ubuntu.com/security/CVE-2024-50086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix user-after-free from session log off There is racy issue between smb2 session log off and smb2 session setup. It will cause user-after-free from session log off. This add session_lock when setting SMB2_SESSION_EXPIRED and referece count to session struct not to free session while it is being used.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50087", "url": "https://ubuntu.com/security/CVE-2024-50087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix uninitialized pointer free on read_alloc_one_name() error The function read_alloc_one_name() does not initialize the name field of the passed fscrypt_str struct if kmalloc fails to allocate the corresponding buffer. Thus, it is not guaranteed that fscrypt_str.name is initialized when freeing it. This is a follow-up to the linked patch that fixes the remaining instances of the bug introduced by commit e43eec81c516 (\"btrfs: use struct qstr instead of name and namelen pairs\").", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50088", "url": "https://ubuntu.com/security/CVE-2024-50088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix uninitialized pointer free in add_inode_ref() The add_inode_ref() function does not initialize the \"name\" struct when it is declared. If any of the following calls to \"read_one_inode() returns NULL, \tdir = read_one_inode(root, parent_objectid); \tif (!dir) { \t\tret = -ENOENT; \t\tgoto out; \t} \tinode = read_one_inode(root, inode_objectid); \tif (!inode) { \t\tret = -EIO; \t\tgoto out; \t} then \"name.name\" would be freed on \"out\" before being initialized. out: \t... \tkfree(name.name); This issue was reported by Coverity with CID 1526744.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50182", "url": "https://ubuntu.com/security/CVE-2024-50182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: secretmem: disable memfd_secret() if arch cannot set direct map Return -ENOSYS from memfd_secret() syscall if !can_set_direct_map(). This is the case for example on some arm64 configurations, where marking 4k PTEs in the direct map not present can only be done if the direct map is set up at 4k granularity in the first place (as ARM's break-before-make semantics do not easily allow breaking apart large/gigantic pages). More precisely, on arm64 systems with !can_set_direct_map(), set_direct_map_invalid_noflush() is a no-op, however it returns success (0) instead of an error. This means that memfd_secret will seemingly \"work\" (e.g. syscall succeeds, you can mmap the fd and fault in pages), but it does not actually achieve its goal of removing its memory from the direct map. Note that with this patch, memfd_secret() will start erroring on systems where can_set_direct_map() returns false (arm64 with CONFIG_RODATA_FULL_DEFAULT_ENABLED=n, CONFIG_DEBUG_PAGEALLOC=n and CONFIG_KFENCE=n), but that still seems better than the current silent failure. Since CONFIG_RODATA_FULL_DEFAULT_ENABLED defaults to 'y', most arm64 systems actually have a working memfd_secret() and aren't be affected. From going through the iterations of the original memfd_secret patch series, it seems that disabling the syscall in these scenarios was the intended behavior [1] (preferred over having set_direct_map_invalid_noflush return an error as that would result in SIGBUSes at page-fault time), however the check for it got dropped between v16 [2] and v17 [3], when secretmem moved away from CMA allocations. [1]: https://lore.kernel.org/lkml/20201124164930.GK8537@kernel.org/ [2]: https://lore.kernel.org/lkml/20210121122723.3446-11-rppt@kernel.org/#t [3]: https://lore.kernel.org/lkml/20201125092208.12544-10-rppt@kernel.org/", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50019", "url": "https://ubuntu.com/security/CVE-2024-50019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kthread: unpark only parked kthread Calling into kthread unparking unconditionally is mostly harmless when the kthread is already unparked. The wake up is then simply ignored because the target is not in TASK_PARKED state. However if the kthread is per CPU, the wake up is preceded by a call to kthread_bind() which expects the task to be inactive and in TASK_PARKED state, which obviously isn't the case if it is unparked. As a result, calling kthread_stop() on an unparked per-cpu kthread triggers such a warning: \tWARNING: CPU: 0 PID: 11 at kernel/kthread.c:525 __kthread_bind_mask kernel/kthread.c:525 \t \t kthread_stop+0x17a/0x630 kernel/kthread.c:707 \t destroy_workqueue+0x136/0xc40 kernel/workqueue.c:5810 \t wg_destruct+0x1e2/0x2e0 drivers/net/wireguard/device.c:257 \t netdev_run_todo+0xe1a/0x1000 net/core/dev.c:10693 \t default_device_exit_batch+0xa14/0xa90 net/core/dev.c:11769 \t ops_exit_list net/core/net_namespace.c:178 [inline] \t cleanup_net+0x89d/0xcc0 net/core/net_namespace.c:640 \t process_one_work kernel/workqueue.c:3231 [inline] \t process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 \t worker_thread+0x86d/0xd70 kernel/workqueue.c:3393 \t kthread+0x2f0/0x390 kernel/kthread.c:389 \t ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 \t ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 \t Fix this with skipping unecessary unparking while stopping a kthread.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50096", "url": "https://ubuntu.com/security/CVE-2024-50096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/dmem: Fix vulnerability in migrate_to_ram upon copy error The `nouveau_dmem_copy_one` function ensures that the copy push command is sent to the device firmware but does not track whether it was executed successfully. In the case of a copy error (e.g., firmware or hardware failure), the copy push command will be sent via the firmware channel, and `nouveau_dmem_copy_one` will likely report success, leading to the `migrate_to_ram` function returning a dirty HIGH_USER page to the user. This can result in a security vulnerability, as a HIGH_USER page that may contain sensitive or corrupted data could be returned to the user. To prevent this vulnerability, we allocate a zero page. Thus, in case of an error, a non-dirty (zero) page will be returned to the user.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50020", "url": "https://ubuntu.com/security/CVE-2024-50020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix improper handling of refcount in ice_sriov_set_msix_vec_count() This patch addresses an issue with improper reference count handling in the ice_sriov_set_msix_vec_count() function. First, the function calls ice_get_vf_by_id(), which increments the reference count of the vf pointer. If the subsequent call to ice_get_vf_vsi() fails, the function currently returns an error without decrementing the reference count of the vf pointer, leading to a reference count leak. The correct behavior, as implemented in this patch, is to decrement the reference count using ice_put_vf(vf) before returning an error when vsi is NULL. Second, the function calls ice_sriov_get_irqs(), which sets vf->first_vector_idx. If this call returns a negative value, indicating an error, the function returns an error without decrementing the reference count of the vf pointer, resulting in another reference count leak. The patch addresses this by adding a call to ice_put_vf(vf) before returning an error when vf->first_vector_idx < 0. This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and identifying potential mismanagement of reference counts. In this case, the tool flagged the missing decrement operation as a potential issue, leading to this patch.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50021", "url": "https://ubuntu.com/security/CVE-2024-50021", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix improper handling of refcount in ice_dpll_init_rclk_pins() This patch addresses a reference count handling issue in the ice_dpll_init_rclk_pins() function. The function calls ice_dpll_get_pins(), which increments the reference count of the relevant resources. However, if the condition WARN_ON((!vsi || !vsi->netdev)) is met, the function currently returns an error without properly releasing the resources acquired by ice_dpll_get_pins(), leading to a reference count leak. To resolve this, the check has been moved to the top of the function. This ensures that the function verifies the state before any resources are acquired, avoiding the need for additional resource management in the error path. This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and detecting potential issues where resources are not properly managed. In this case, the tool flagged the missing release operation as a potential problem, which led to the development of this patch.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50022", "url": "https://ubuntu.com/security/CVE-2024-50022", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: device-dax: correct pgoff align in dax_set_mapping() pgoff should be aligned using ALIGN_DOWN() instead of ALIGN(). Otherwise, vmf->address not aligned to fault_size will be aligned to the next alignment, that can result in memory failure getting the wrong address. It's a subtle situation that only can be observed in page_mapped_in_vma() after the page is page fault handled by dev_dax_huge_fault. Generally, there is little chance to perform page_mapped_in_vma in dev-dax's page unless in specific error injection to the dax device to trigger an MCE - memory-failure. In that case, page_mapped_in_vma() will be triggered to determine which task is accessing the failure address and kill that task in the end. We used self-developed dax device (which is 2M aligned mapping) , to perform error injection to random address. It turned out that error injected to non-2M-aligned address was causing endless MCE until panic. Because page_mapped_in_vma() kept resulting wrong address and the task accessing the failure address was never killed properly: [ 3783.719419] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.049006] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.049190] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.448042] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.448186] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.792026] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.792179] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.162502] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.162633] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.461116] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.461247] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.764730] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.764859] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.042128] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.042259] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.464293] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.464423] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.818090] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.818217] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3787.085297] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3787.085424] Memory failure: 0x200c9742: recovery action for dax page: Recovered It took us several weeks to pinpoint this problem,  but we eventually used bpftrace to trace the page fault and mce address and successfully identified the issue. Joao added: ; Likely we never reproduce in production because we always pin : device-dax regions in the region align they provide (Qemu does : similarly with prealloc in hugetlb/file backed memory). I think this : bug requires that we touch *unpinned* device-dax regions unaligned to : the device-dax selected alignment (page size i.e. 4K/2M/1G)", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50185", "url": "https://ubuntu.com/security/CVE-2024-50185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: handle consistently DSS corruption Bugged peer implementation can send corrupted DSS options, consistently hitting a few warning in the data path. Use DEBUG_NET assertions, to avoid the splat on some builds and handle consistently the error, dumping related MIBs and performing fallback and/or reset according to the subflow type.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50023", "url": "https://ubuntu.com/security/CVE-2024-50023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: Remove LED entry from LEDs list on unregister Commit c938ab4da0eb (\"net: phy: Manual remove LEDs to ensure correct ordering\") correctly fixed a problem with using devm_ but missed removing the LED entry from the LEDs list. This cause kernel panic on specific scenario where the port for the PHY is torn down and up and the kmod for the PHY is removed. On setting the port down the first time, the assosiacted LEDs are correctly unregistered. The associated kmod for the PHY is now removed. The kmod is now added again and the port is now put up, the associated LED are registered again. On putting the port down again for the second time after these step, the LED list now have 4 elements. With the first 2 already unregistered previously and the 2 new one registered again. This cause a kernel panic as the first 2 element should have been removed. Fix this by correctly removing the element when LED is unregistered.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50024", "url": "https://ubuntu.com/security/CVE-2024-50024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: Fix an unsafe loop on the list The kernel may crash when deleting a genetlink family if there are still listeners for that family: Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c000000000c080bc] netlink_update_socket_mc+0x3c/0xc0 LR [c000000000c0f764] __netlink_clear_multicast_users+0x74/0xc0 Call Trace: __netlink_clear_multicast_users+0x74/0xc0 genl_unregister_family+0xd4/0x2d0 Change the unsafe loop on the list to a safe one, because inside the loop there is an element removal from this list.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50186", "url": "https://ubuntu.com/security/CVE-2024-50186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: explicitly clear the sk pointer, when pf->create fails We have recently noticed the exact same KASAN splat as in commit 6cd4a78d962b (\"net: do not leave a dangling sk pointer, when socket creation fails\"). The problem is that commit did not fully address the problem, as some pf->create implementations do not use sk_common_release in their error paths. For example, we can use the same reproducer as in the above commit, but changing ping to arping. arping uses AF_PACKET socket and if packet_create fails, it will just sk_free the allocated sk object. While we could chase all the pf->create implementations and make sure they NULL the freed sk object on error from the socket, we can't guarantee future protocols will not make the same mistake. So it is easier to just explicitly NULL the sk pointer upon return from pf->create in __sock_create. We do know that pf->create always releases the allocated sk object on error, so if the pointer is not NULL, it is definitely dangling.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50025", "url": "https://ubuntu.com/security/CVE-2024-50025", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: fnic: Move flush_work initialization out of if block After commit 379a58caa199 (\"scsi: fnic: Move fnic_fnic_flush_tx() to a work queue\"), it can happen that a work item is sent to an uninitialized work queue. This may has the effect that the item being queued is never actually queued, and any further actions depending on it will not proceed. The following warning is observed while the fnic driver is loaded: kernel: WARNING: CPU: 11 PID: 0 at ../kernel/workqueue.c:1524 __queue_work+0x373/0x410 kernel: kernel: queue_work_on+0x3a/0x50 kernel: fnic_wq_copy_cmpl_handler+0x54a/0x730 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: fnic_isr_msix_wq_copy+0x2d/0x60 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: __handle_irq_event_percpu+0x36/0x1a0 kernel: handle_irq_event_percpu+0x30/0x70 kernel: handle_irq_event+0x34/0x60 kernel: handle_edge_irq+0x7e/0x1a0 kernel: __common_interrupt+0x3b/0xb0 kernel: common_interrupt+0x58/0xa0 kernel: It has been observed that this may break the rediscovery of Fibre Channel devices after a temporary fabric failure. This patch fixes it by moving the work queue initialization out of an if block in fnic_probe().", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50026", "url": "https://ubuntu.com/security/CVE-2024-50026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: wd33c93: Don't use stale scsi_pointer value A regression was introduced with commit dbb2da557a6a (\"scsi: wd33c93: Move the SCSI pointer to private command data\") which results in an oops in wd33c93_intr(). That commit added the scsi_pointer variable and initialized it from hostdata->connected. However, during selection, hostdata->connected is not yet valid. Fix this by getting the current scsi_pointer from hostdata->selecting.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50027", "url": "https://ubuntu.com/security/CVE-2024-50027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: core: Free tzp copy along with the thermal zone The object pointed to by tz->tzp may still be accessed after being freed in thermal_zone_device_unregister(), so move the freeing of it to the point after the removal completion has been completed at which it cannot be accessed any more.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50028", "url": "https://ubuntu.com/security/CVE-2024-50028", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: core: Reference count the zone in thermal_zone_get_by_id() There are places in the thermal netlink code where nothing prevents the thermal zone object from going away while being accessed after it has been returned by thermal_zone_get_by_id(). To address this, make thermal_zone_get_by_id() get a reference on the thermal zone device object to be returned with the help of get_device(), under thermal_list_lock, and adjust all of its callers to this change with the help of the cleanup.h infrastructure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50029", "url": "https://ubuntu.com/security/CVE-2024-50029", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_conn: Fix UAF in hci_enhanced_setup_sync This checks if the ACL connection remains valid as it could be destroyed while hci_enhanced_setup_sync is pending on cmd_sync leading to the following trace: BUG: KASAN: slab-use-after-free in hci_enhanced_setup_sync+0x91b/0xa60 Read of size 1 at addr ffff888002328ffd by task kworker/u5:2/37 CPU: 0 UID: 0 PID: 37 Comm: kworker/u5:2 Not tainted 6.11.0-rc6-01300-g810be445d8d6 #7099 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Workqueue: hci0 hci_cmd_sync_work Call Trace: dump_stack_lvl+0x5d/0x80 ? hci_enhanced_setup_sync+0x91b/0xa60 print_report+0x152/0x4c0 ? hci_enhanced_setup_sync+0x91b/0xa60 ? __virt_addr_valid+0x1fa/0x420 ? hci_enhanced_setup_sync+0x91b/0xa60 kasan_report+0xda/0x1b0 ? hci_enhanced_setup_sync+0x91b/0xa60 hci_enhanced_setup_sync+0x91b/0xa60 ? __pfx_hci_enhanced_setup_sync+0x10/0x10 ? __pfx___mutex_lock+0x10/0x10 hci_cmd_sync_work+0x1c2/0x330 process_one_work+0x7d9/0x1360 ? __pfx_lock_acquire+0x10/0x10 ? __pfx_process_one_work+0x10/0x10 ? assign_work+0x167/0x240 worker_thread+0x5b7/0xf60 ? __kthread_parkme+0xac/0x1c0 ? __pfx_worker_thread+0x10/0x10 ? __pfx_worker_thread+0x10/0x10 kthread+0x293/0x360 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2f/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 34: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __hci_conn_add+0x187/0x17d0 hci_connect_sco+0x2e1/0xb90 sco_sock_connect+0x2a2/0xb80 __sys_connect+0x227/0x2a0 __x64_sys_connect+0x6d/0xb0 do_syscall_64+0x71/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 37: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x101/0x160 kfree+0xd0/0x250 device_release+0x9a/0x210 kobject_put+0x151/0x280 hci_conn_del+0x448/0xbf0 hci_abort_conn_sync+0x46f/0x980 hci_cmd_sync_work+0x1c2/0x330 process_one_work+0x7d9/0x1360 worker_thread+0x5b7/0xf60 kthread+0x293/0x360 ret_from_fork+0x2f/0x70 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50030", "url": "https://ubuntu.com/security/CVE-2024-50030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/ct: prevent UAF in send_recv() Ensure we serialize with completion side to prevent UAF with fence going out of scope on the stack, since we have no clue if it will fire after the timeout before we can erase from the xa. Also we have some dependent loads and stores for which we need the correct ordering, and we lack the needed barriers. Fix this by grabbing the ct->lock after the wait, which is also held by the completion side. v2 (Badal): - Also print done after acquiring the lock and seeing timeout. (cherry picked from commit 52789ce35c55ccd30c4b67b9cc5b2af55e0122ea)", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50187", "url": "https://ubuntu.com/security/CVE-2024-50187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Stop the active perfmon before being destroyed Upon closing the file descriptor, the active performance monitor is not stopped. Although all perfmons are destroyed in `vc4_perfmon_close_file()`, the active performance monitor's pointer (`vc4->active_perfmon`) is still retained. If we open a new file descriptor and submit a few jobs with performance monitors, the driver will attempt to stop the active performance monitor using the stale pointer in `vc4->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50031", "url": "https://ubuntu.com/security/CVE-2024-50031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Stop the active perfmon before being destroyed When running `kmscube` with one or more performance monitors enabled via `GALLIUM_HUD`, the following kernel panic can occur: [ 55.008324] Unable to handle kernel paging request at virtual address 00000000052004a4 [ 55.008368] Mem abort info: [ 55.008377] ESR = 0x0000000096000005 [ 55.008387] EC = 0x25: DABT (current EL), IL = 32 bits [ 55.008402] SET = 0, FnV = 0 [ 55.008412] EA = 0, S1PTW = 0 [ 55.008421] FSC = 0x05: level 1 translation fault [ 55.008434] Data abort info: [ 55.008442] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 55.008455] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 55.008467] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 55.008481] user pgtable: 4k pages, 39-bit VAs, pgdp=00000001046c6000 [ 55.008497] [00000000052004a4] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 55.008525] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP [ 55.008542] Modules linked in: rfcomm [...] vc4 v3d snd_soc_hdmi_codec drm_display_helper gpu_sched drm_shmem_helper cec drm_dma_helper drm_kms_helper i2c_brcmstb drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight [ 55.008799] CPU: 2 PID: 166 Comm: v3d_bin Tainted: G C 6.6.47+rpt-rpi-v8 #1 Debian 1:6.6.47-1+rpt1 [ 55.008824] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [ 55.008838] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 55.008855] pc : __mutex_lock.constprop.0+0x90/0x608 [ 55.008879] lr : __mutex_lock.constprop.0+0x58/0x608 [ 55.008895] sp : ffffffc080673cf0 [ 55.008904] x29: ffffffc080673cf0 x28: 0000000000000000 x27: ffffff8106188a28 [ 55.008926] x26: ffffff8101e78040 x25: ffffff8101baa6c0 x24: ffffffd9d989f148 [ 55.008947] x23: ffffffda1c2a4008 x22: 0000000000000002 x21: ffffffc080673d38 [ 55.008968] x20: ffffff8101238000 x19: ffffff8104f83188 x18: 0000000000000000 [ 55.008988] x17: 0000000000000000 x16: ffffffda1bd04d18 x15: 00000055bb08bc90 [ 55.009715] x14: 0000000000000000 x13: 0000000000000000 x12: ffffffda1bd4cbb0 [ 55.010433] x11: 00000000fa83b2da x10: 0000000000001a40 x9 : ffffffda1bd04d04 [ 55.011162] x8 : ffffff8102097b80 x7 : 0000000000000000 x6 : 00000000030a5857 [ 55.011880] x5 : 00ffffffffffffff x4 : 0300000005200470 x3 : 0300000005200470 [ 55.012598] x2 : ffffff8101238000 x1 : 0000000000000021 x0 : 0300000005200470 [ 55.013292] Call trace: [ 55.013959] __mutex_lock.constprop.0+0x90/0x608 [ 55.014646] __mutex_lock_slowpath+0x1c/0x30 [ 55.015317] mutex_lock+0x50/0x68 [ 55.015961] v3d_perfmon_stop+0x40/0xe0 [v3d] [ 55.016627] v3d_bin_job_run+0x10c/0x2d8 [v3d] [ 55.017282] drm_sched_main+0x178/0x3f8 [gpu_sched] [ 55.017921] kthread+0x11c/0x128 [ 55.018554] ret_from_fork+0x10/0x20 [ 55.019168] Code: f9400260 f1001c1f 54001ea9 927df000 (b9403401) [ 55.019776] ---[ end trace 0000000000000000 ]--- [ 55.020411] note: v3d_bin[166] exited with preempt_count 1 This issue arises because, upon closing the file descriptor (which happens when we interrupt `kmscube`), the active performance monitor is not stopped. Although all perfmons are destroyed in `v3d_perfmon_close_file()`, the active performance monitor's pointer (`v3d->active_perfmon`) is still retained. If `kmscube` is run again, the driver will attempt to stop the active performance monitor using the stale pointer in `v3d->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50189", "url": "https://ubuntu.com/security/CVE-2024-50189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: amd_sfh: Switch to device-managed dmam_alloc_coherent() Using the device-managed version allows to simplify clean-up in probe() error path. Additionally, this device-managed ensures proper cleanup, which helps to resolve memory errors, page faults, btrfs going read-only, and btrfs disk corruption.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50033", "url": "https://ubuntu.com/security/CVE-2024-50033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slip: make slhc_remember() more robust against malicious packets syzbot found that slhc_remember() was missing checks against malicious packets [1]. slhc_remember() only checked the size of the packet was at least 20, which is not good enough. We need to make sure the packet includes the IPv4 and TCP header that are supposed to be carried. Add iph and th pointers to make the code more readable. [1] BUG: KMSAN: uninit-value in slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 ppp_receive_nonmp_frame+0xe45/0x35e0 drivers/net/ppp/ppp_generic.c:2455 ppp_receive_frame drivers/net/ppp/ppp_generic.c:2372 [inline] ppp_do_recv+0x65f/0x40d0 drivers/net/ppp/ppp_generic.c:2212 ppp_input+0x7dc/0xe60 drivers/net/ppp/ppp_generic.c:2327 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 Uninit was created at: slab_post_alloc_hook mm/slub.c:4091 [inline] slab_alloc_node mm/slub.c:4134 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 CPU: 0 UID: 0 PID: 5460 Comm: syz.2.33 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50034", "url": "https://ubuntu.com/security/CVE-2024-50034", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix lacks of icsk_syn_mss with IPPROTO_SMC Eric report a panic on IPPROTO_SMC, and give the facts that when INET_PROTOSW_ICSK was set, icsk->icsk_sync_mss must be set too. Bug: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000086000005 EC = 0x21: IABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault user pgtable: 4k pages, 48-bit VAs, pgdp=00000001195d1000 [0000000000000000] pgd=0800000109c46003, p4d=0800000109c46003, pud=0000000000000000 Internal error: Oops: 0000000086000005 [#1] PREEMPT SMP Modules linked in: CPU: 1 UID: 0 PID: 8037 Comm: syz.3.265 Not tainted 6.11.0-rc7-syzkaller-g5f5673607153 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0x0 lr : cipso_v4_sock_setattr+0x2a8/0x3c0 net/ipv4/cipso_ipv4.c:1910 sp : ffff80009b887a90 x29: ffff80009b887aa0 x28: ffff80008db94050 x27: 0000000000000000 x26: 1fffe0001aa6f5b3 x25: dfff800000000000 x24: ffff0000db75da00 x23: 0000000000000000 x22: ffff0000d8b78518 x21: 0000000000000000 x20: ffff0000d537ad80 x19: ffff0000d8b78000 x18: 1fffe000366d79ee x17: ffff8000800614a8 x16: ffff800080569b84 x15: 0000000000000001 x14: 000000008b336894 x13: 00000000cd96feaa x12: 0000000000000003 x11: 0000000000040000 x10: 00000000000020a3 x9 : 1fffe0001b16f0f1 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 000000000000003f x5 : 0000000000000040 x4 : 0000000000000001 x3 : 0000000000000000 x2 : 0000000000000002 x1 : 0000000000000000 x0 : ffff0000d8b78000 Call trace: 0x0 netlbl_sock_setattr+0x2e4/0x338 net/netlabel/netlabel_kapi.c:1000 smack_netlbl_add+0xa4/0x154 security/smack/smack_lsm.c:2593 smack_socket_post_create+0xa8/0x14c security/smack/smack_lsm.c:2973 security_socket_post_create+0x94/0xd4 security/security.c:4425 __sock_create+0x4c8/0x884 net/socket.c:1587 sock_create net/socket.c:1622 [inline] __sys_socket_create net/socket.c:1659 [inline] __sys_socket+0x134/0x340 net/socket.c:1706 __do_sys_socket net/socket.c:1720 [inline] __se_sys_socket net/socket.c:1718 [inline] __arm64_sys_socket+0x7c/0x94 net/socket.c:1718 __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:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 Code: ???????? ???????? ???????? ???????? (????????) ---[ end trace 0000000000000000 ]--- This patch add a toy implementation that performs a simple return to prevent such panic. This is because MSS can be set in sock_create_kern or smc_setsockopt, similar to how it's done in AF_SMC. However, for AF_SMC, there is currently no way to synchronize MSS within __sys_connect_file. This toy implementation lays the groundwork for us to support such feature for IPPROTO_SMC in the future.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50035", "url": "https://ubuntu.com/security/CVE-2024-50035", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: fix ppp_async_encode() illegal access syzbot reported an issue in ppp_async_encode() [1] In this case, pppoe_sendmsg() is called with a zero size. Then ppp_async_encode() is called with an empty skb. BUG: KMSAN: uninit-value in ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] BUG: KMSAN: uninit-value in ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_send+0x130/0x1b0 drivers/net/ppp/ppp_async.c:634 ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2280 [inline] ppp_input+0x1f1/0xe60 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 Uninit was created at: slab_post_alloc_hook mm/slub.c:4092 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4187 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 CPU: 1 UID: 0 PID: 5411 Comm: syz.1.14 Not tainted 6.12.0-rc1-syzkaller-00165-g360c1f1f24c6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50036", "url": "https://ubuntu.com/security/CVE-2024-50036", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: do not delay dst_entries_add() in dst_release() dst_entries_add() uses per-cpu data that might be freed at netns dismantle from ip6_route_net_exit() calling dst_entries_destroy() Before ip6_route_net_exit() can be called, we release all the dsts associated with this netns, via calls to dst_release(), which waits an rcu grace period before calling dst_destroy() dst_entries_add() use in dst_destroy() is racy, because dst_entries_destroy() could have been called already. Decrementing the number of dsts must happen sooner. Notes: 1) in CONFIG_XFRM case, dst_destroy() can call dst_release_immediate(child), this might also cause UAF if the child does not have DST_NOCOUNT set. IPSEC maintainers might take a look and see how to address this. 2) There is also discussion about removing this count of dst, which might happen in future kernels.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50037", "url": "https://ubuntu.com/security/CVE-2024-50037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/fbdev-dma: Only cleanup deferred I/O if necessary Commit 5a498d4d06d6 (\"drm/fbdev-dma: Only install deferred I/O if necessary\") initializes deferred I/O only if it is used. drm_fbdev_dma_fb_destroy() however calls fb_deferred_io_cleanup() unconditionally with struct fb_info.fbdefio == NULL. KASAN with the out-of-tree Apple silicon display driver posts following warning from __flush_work() of a random struct work_struct instead of the expected NULL pointer derefs. [ 22.053799] ------------[ cut here ]------------ [ 22.054832] WARNING: CPU: 2 PID: 1 at kernel/workqueue.c:4177 __flush_work+0x4d8/0x580 [ 22.056597] Modules linked in: uhid bnep uinput nls_ascii ip6_tables ip_tables i2c_dev loop fuse dm_multipath nfnetlink zram hid_magicmouse btrfs xor xor_neon brcmfmac_wcc raid6_pq hci_bcm4377 bluetooth brcmfmac hid_apple brcmutil nvmem_spmi_mfd simple_mfd_spmi dockchannel_hid cfg80211 joydev regmap_spmi nvme_apple ecdh_generic ecc macsmc_hid rfkill dwc3 appledrm snd_soc_macaudio macsmc_power nvme_core apple_isp phy_apple_atc apple_sart apple_rtkit_helper apple_dockchannel tps6598x macsmc_hwmon snd_soc_cs42l84 videobuf2_v4l2 spmi_apple_controller nvmem_apple_efuses videobuf2_dma_sg apple_z2 videobuf2_memops spi_nor panel_summit videobuf2_common asahi videodev pwm_apple apple_dcp snd_soc_apple_mca apple_admac spi_apple clk_apple_nco i2c_pasemi_platform snd_pcm_dmaengine mc i2c_pasemi_core mux_core ofpart adpdrm drm_dma_helper apple_dart apple_soc_cpufreq leds_pwm phram [ 22.073768] CPU: 2 UID: 0 PID: 1 Comm: systemd-shutdow Not tainted 6.11.2-asahi+ #asahi-dev [ 22.075612] Hardware name: Apple MacBook Pro (13-inch, M2, 2022) (DT) [ 22.077032] pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 22.078567] pc : __flush_work+0x4d8/0x580 [ 22.079471] lr : __flush_work+0x54/0x580 [ 22.080345] sp : ffffc000836ef820 [ 22.081089] x29: ffffc000836ef880 x28: 0000000000000000 x27: ffff80002ddb7128 [ 22.082678] x26: dfffc00000000000 x25: 1ffff000096f0c57 x24: ffffc00082d3e358 [ 22.084263] x23: ffff80004b7862b8 x22: dfffc00000000000 x21: ffff80005aa1d470 [ 22.085855] x20: ffff80004b786000 x19: ffff80004b7862a0 x18: 0000000000000000 [ 22.087439] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000005 [ 22.089030] x14: 1ffff800106ddf0a x13: 0000000000000000 x12: 0000000000000000 [ 22.090618] x11: ffffb800106ddf0f x10: dfffc00000000000 x9 : 1ffff800106ddf0e [ 22.092206] x8 : 0000000000000000 x7 : aaaaaaaaaaaaaaaa x6 : 0000000000000001 [ 22.093790] x5 : ffffc000836ef728 x4 : 0000000000000000 x3 : 0000000000000020 [ 22.095368] x2 : 0000000000000008 x1 : 00000000000000aa x0 : 0000000000000000 [ 22.096955] Call trace: [ 22.097505] __flush_work+0x4d8/0x580 [ 22.098330] flush_delayed_work+0x80/0xb8 [ 22.099231] fb_deferred_io_cleanup+0x3c/0x130 [ 22.100217] drm_fbdev_dma_fb_destroy+0x6c/0xe0 [drm_dma_helper] [ 22.101559] unregister_framebuffer+0x210/0x2f0 [ 22.102575] drm_fb_helper_unregister_info+0x48/0x60 [ 22.103683] drm_fbdev_dma_client_unregister+0x4c/0x80 [drm_dma_helper] [ 22.105147] drm_client_dev_unregister+0x1cc/0x230 [ 22.106217] drm_dev_unregister+0x58/0x570 [ 22.107125] apple_drm_unbind+0x50/0x98 [appledrm] [ 22.108199] component_del+0x1f8/0x3a8 [ 22.109042] dcp_platform_shutdown+0x24/0x38 [apple_dcp] [ 22.110357] platform_shutdown+0x70/0x90 [ 22.111219] device_shutdown+0x368/0x4d8 [ 22.112095] kernel_restart+0x6c/0x1d0 [ 22.112946] __arm64_sys_reboot+0x1c8/0x328 [ 22.113868] invoke_syscall+0x78/0x1a8 [ 22.114703] do_el0_svc+0x124/0x1a0 [ 22.115498] el0_svc+0x3c/0xe0 [ 22.116181] el0t_64_sync_handler+0x70/0xc0 [ 22.117110] el0t_64_sync+0x190/0x198 [ 22.117931] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50092", "url": "https://ubuntu.com/security/CVE-2024-50092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netconsole: fix wrong warning A warning is triggered when there is insufficient space in the buffer for userdata. However, this is not an issue since userdata will be sent in the next iteration. Current warning message: ------------[ cut here ]------------ WARNING: CPU: 13 PID: 3013042 at drivers/net/netconsole.c:1122 write_ext_msg+0x3b6/0x3d0 ? write_ext_msg+0x3b6/0x3d0 console_flush_all+0x1e9/0x330 The code incorrectly issues a warning when this_chunk is zero, which is a valid scenario. The warning should only be triggered when this_chunk is negative.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50038", "url": "https://ubuntu.com/security/CVE-2024-50038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xtables: avoid NFPROTO_UNSPEC where needed syzbot managed to call xt_cluster match via ebtables: WARNING: CPU: 0 PID: 11 at net/netfilter/xt_cluster.c:72 xt_cluster_mt+0x196/0x780 [..] ebt_do_table+0x174b/0x2a40 Module registers to NFPROTO_UNSPEC, but it assumes ipv4/ipv6 packet processing. As this is only useful to restrict locally terminating TCP/UDP traffic, register this for ipv4 and ipv6 family only. Pablo points out that this is a general issue, direct users of the set/getsockopt interface can call into targets/matches that were only intended for use with ip(6)tables. Check all UNSPEC matches and targets for similar issues: - matches and targets are fine except if they assume skb_network_header() is valid -- this is only true when called from inet layer: ip(6) stack pulls the ip/ipv6 header into linear data area. - targets that return XT_CONTINUE or other xtables verdicts must be restricted too, they are incompatbile with the ebtables traverser, e.g. EBT_CONTINUE is a completely different value than XT_CONTINUE. Most matches/targets are changed to register for NFPROTO_IPV4/IPV6, as they are provided for use by ip(6)tables. The MARK target is also used by arptables, so register for NFPROTO_ARP too. While at it, bail out if connbytes fails to enable the corresponding conntrack family. This change passes the selftests in iptables.git.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50039", "url": "https://ubuntu.com/security/CVE-2024-50039", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: accept TCA_STAB only for root qdisc Most qdiscs maintain their backlog using qdisc_pkt_len(skb) on the assumption it is invariant between the enqueue() and dequeue() handlers. Unfortunately syzbot can crash a host rather easily using a TBF + SFQ combination, with an STAB on SFQ [1] We can't support TCA_STAB on arbitrary level, this would require to maintain per-qdisc storage. [1] [ 88.796496] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 88.798611] #PF: supervisor read access in kernel mode [ 88.799014] #PF: error_code(0x0000) - not-present page [ 88.799506] PGD 0 P4D 0 [ 88.799829] Oops: Oops: 0000 [#1] SMP NOPTI [ 88.800569] CPU: 14 UID: 0 PID: 2053 Comm: b371744477 Not tainted 6.12.0-rc1-virtme #1117 [ 88.801107] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 88.801779] RIP: 0010:sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq [ 88.802544] Code: 0f b7 50 12 48 8d 04 d5 00 00 00 00 48 89 d6 48 29 d0 48 8b 91 c0 01 00 00 48 c1 e0 03 48 01 c2 66 83 7a 1a 00 7e c0 48 8b 3a <4c> 8b 07 4c 89 02 49 89 50 08 48 c7 47 08 00 00 00 00 48 c7 07 00 All code ======== 0:\t0f b7 50 12 \tmovzwl 0x12(%rax),%edx 4:\t48 8d 04 d5 00 00 00 \tlea 0x0(,%rdx,8),%rax b:\t00 c:\t48 89 d6 \tmov %rdx,%rsi f:\t48 29 d0 \tsub %rdx,%rax 12:\t48 8b 91 c0 01 00 00 \tmov 0x1c0(%rcx),%rdx 19:\t48 c1 e0 03 \tshl $0x3,%rax 1d:\t48 01 c2 \tadd %rax,%rdx 20:\t66 83 7a 1a 00 \tcmpw $0x0,0x1a(%rdx) 25:\t7e c0 \tjle 0xffffffffffffffe7 27:\t48 8b 3a \tmov (%rdx),%rdi 2a:*\t4c 8b 07 \tmov (%rdi),%r8\t\t<-- trapping instruction 2d:\t4c 89 02 \tmov %r8,(%rdx) 30:\t49 89 50 08 \tmov %rdx,0x8(%r8) 34:\t48 c7 47 08 00 00 00 \tmovq $0x0,0x8(%rdi) 3b:\t00 3c:\t48 \trex.W 3d:\tc7 \t.byte 0xc7 3e:\t07 \t(bad) \t... Code starting with the faulting instruction =========================================== 0:\t4c 8b 07 \tmov (%rdi),%r8 3:\t4c 89 02 \tmov %r8,(%rdx) 6:\t49 89 50 08 \tmov %rdx,0x8(%r8) a:\t48 c7 47 08 00 00 00 \tmovq $0x0,0x8(%rdi) 11:\t00 12:\t48 \trex.W 13:\tc7 \t.byte 0xc7 14:\t07 \t(bad) \t... [ 88.803721] RSP: 0018:ffff9a1f892b7d58 EFLAGS: 00000206 [ 88.804032] RAX: 0000000000000000 RBX: ffff9a1f8420c800 RCX: ffff9a1f8420c800 [ 88.804560] RDX: ffff9a1f81bc1440 RSI: 0000000000000000 RDI: 0000000000000000 [ 88.805056] RBP: ffffffffc04bb0e0 R08: 0000000000000001 R09: 00000000ff7f9a1f [ 88.805473] R10: 000000000001001b R11: 0000000000009a1f R12: 0000000000000140 [ 88.806194] R13: 0000000000000001 R14: ffff9a1f886df400 R15: ffff9a1f886df4ac [ 88.806734] FS: 00007f445601a740(0000) GS:ffff9a2e7fd80000(0000) knlGS:0000000000000000 [ 88.807225] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 88.807672] CR2: 0000000000000000 CR3: 000000050cc46000 CR4: 00000000000006f0 [ 88.808165] Call Trace: [ 88.808459] [ 88.808710] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434) [ 88.809261] ? page_fault_oops (arch/x86/mm/fault.c:715) [ 88.809561] ? exc_page_fault (./arch/x86/include/asm/irqflags.h:26 ./arch/x86/include/asm/irqflags.h:87 ./arch/x86/include/asm/irqflags.h:147 arch/x86/mm/fault.c:1489 arch/x86/mm/fault.c:1539) [ 88.809806] ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623) [ 88.810074] ? sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq [ 88.810411] sfq_reset (net/sched/sch_sfq.c:525) sch_sfq [ 88.810671] qdisc_reset (./include/linux/skbuff.h:2135 ./include/linux/skbuff.h:2441 ./include/linux/skbuff.h:3304 ./include/linux/skbuff.h:3310 net/sched/sch_g ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50040", "url": "https://ubuntu.com/security/CVE-2024-50040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: igb: Do not bring the device up after non-fatal error Commit 004d25060c78 (\"igb: Fix igb_down hung on surprise removal\") changed igb_io_error_detected() to ignore non-fatal pcie errors in order to avoid hung task that can happen when igb_down() is called multiple times. This caused an issue when processing transient non-fatal errors. igb_io_resume(), which is called after igb_io_error_detected(), assumes that device is brought down by igb_io_error_detected() if the interface is up. This resulted in panic with stacktrace below. [ T3256] igb 0000:09:00.0 haeth0: igb: haeth0 NIC Link is Down [ T292] pcieport 0000:00:1c.5: AER: Uncorrected (Non-Fatal) error received: 0000:09:00.0 [ T292] igb 0000:09:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, (Requester ID) [ T292] igb 0000:09:00.0: device [8086:1537] error status/mask=00004000/00000000 [ T292] igb 0000:09:00.0: [14] CmpltTO [ 200.105524,009][ T292] igb 0000:09:00.0: AER: TLP Header: 00000000 00000000 00000000 00000000 [ T292] pcieport 0000:00:1c.5: AER: broadcast error_detected message [ T292] igb 0000:09:00.0: Non-correctable non-fatal error reported. [ T292] pcieport 0000:00:1c.5: AER: broadcast mmio_enabled message [ T292] pcieport 0000:00:1c.5: AER: broadcast resume message [ T292] ------------[ cut here ]------------ [ T292] kernel BUG at net/core/dev.c:6539! [ T292] invalid opcode: 0000 [#1] PREEMPT SMP [ T292] RIP: 0010:napi_enable+0x37/0x40 [ T292] Call Trace: [ T292] [ T292] ? die+0x33/0x90 [ T292] ? do_trap+0xdc/0x110 [ T292] ? napi_enable+0x37/0x40 [ T292] ? do_error_trap+0x70/0xb0 [ T292] ? napi_enable+0x37/0x40 [ T292] ? napi_enable+0x37/0x40 [ T292] ? exc_invalid_op+0x4e/0x70 [ T292] ? napi_enable+0x37/0x40 [ T292] ? asm_exc_invalid_op+0x16/0x20 [ T292] ? napi_enable+0x37/0x40 [ T292] igb_up+0x41/0x150 [ T292] igb_io_resume+0x25/0x70 [ T292] report_resume+0x54/0x70 [ T292] ? report_frozen_detected+0x20/0x20 [ T292] pci_walk_bus+0x6c/0x90 [ T292] ? aer_print_port_info+0xa0/0xa0 [ T292] pcie_do_recovery+0x22f/0x380 [ T292] aer_process_err_devices+0x110/0x160 [ T292] aer_isr+0x1c1/0x1e0 [ T292] ? disable_irq_nosync+0x10/0x10 [ T292] irq_thread_fn+0x1a/0x60 [ T292] irq_thread+0xe3/0x1a0 [ T292] ? irq_set_affinity_notifier+0x120/0x120 [ T292] ? irq_affinity_notify+0x100/0x100 [ T292] kthread+0xe2/0x110 [ T292] ? kthread_complete_and_exit+0x20/0x20 [ T292] ret_from_fork+0x2d/0x50 [ T292] ? kthread_complete_and_exit+0x20/0x20 [ T292] ret_from_fork_asm+0x11/0x20 [ T292] To fix this issue igb_io_resume() checks if the interface is running and the device is not down this means igb_io_error_detected() did not bring the device down and there is no need to bring it up.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50041", "url": "https://ubuntu.com/security/CVE-2024-50041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: Fix macvlan leak by synchronizing access to mac_filter_hash This patch addresses a macvlan leak issue in the i40e driver caused by concurrent access to vsi->mac_filter_hash. The leak occurs when multiple threads attempt to modify the mac_filter_hash simultaneously, leading to inconsistent state and potential memory leaks. To fix this, we now wrap the calls to i40e_del_mac_filter() and zeroing vf->default_lan_addr.addr with spin_lock/unlock_bh(&vsi->mac_filter_hash_lock), ensuring atomic operations and preventing concurrent access. Additionally, we add lockdep_assert_held(&vsi->mac_filter_hash_lock) in i40e_add_mac_filter() to help catch similar issues in the future. Reproduction steps: 1. Spawn VFs and configure port vlan on them. 2. Trigger concurrent macvlan operations (e.g., adding and deleting \tportvlan and/or mac filters). 3. Observe the potential memory leak and inconsistent state in the \tmac_filter_hash. This synchronization ensures the integrity of the mac_filter_hash and prevents the described leak.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50042", "url": "https://ubuntu.com/security/CVE-2024-50042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix increasing MSI-X on VF Increasing MSI-X value on a VF leads to invalid memory operations. This is caused by not reallocating some arrays. Reproducer: modprobe ice echo 0 > /sys/bus/pci/devices/$PF_PCI/sriov_drivers_autoprobe echo 1 > /sys/bus/pci/devices/$PF_PCI/sriov_numvfs echo 17 > /sys/bus/pci/devices/$VF0_PCI/sriov_vf_msix_count Default MSI-X is 16, so 17 and above triggers this issue. KASAN reports: BUG: KASAN: slab-out-of-bounds in ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] Read of size 8 at addr ffff8888b937d180 by task bash/28433 (...) Call Trace: (...) ? ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] kasan_report+0xed/0x120 ? ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] ice_vsi_cfg_def+0x3360/0x4770 [ice] ? mutex_unlock+0x83/0xd0 ? __pfx_ice_vsi_cfg_def+0x10/0x10 [ice] ? __pfx_ice_remove_vsi_lkup_fltr+0x10/0x10 [ice] ice_vsi_cfg+0x7f/0x3b0 [ice] ice_vf_reconfig_vsi+0x114/0x210 [ice] ice_sriov_set_msix_vec_count+0x3d0/0x960 [ice] sriov_vf_msix_count_store+0x21c/0x300 (...) Allocated by task 28201: (...) ice_vsi_cfg_def+0x1c8e/0x4770 [ice] ice_vsi_cfg+0x7f/0x3b0 [ice] ice_vsi_setup+0x179/0xa30 [ice] ice_sriov_configure+0xcaa/0x1520 [ice] sriov_numvfs_store+0x212/0x390 (...) To fix it, use ice_vsi_rebuild() instead of ice_vf_reconfig_vsi(). This causes the required arrays to be reallocated taking the new queue count into account (ice_vsi_realloc_stat_arrays()). Set req_txq and req_rxq before ice_vsi_rebuild(), so that realloc uses the newly set queue count. Additionally, ice_vsi_rebuild() does not remove VSI filters (ice_fltr_remove_all()), so ice_vf_init_host_cfg() is no longer necessary.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50093", "url": "https://ubuntu.com/security/CVE-2024-50093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: intel: int340x: processor: Fix warning during module unload The processor_thermal driver uses pcim_device_enable() to enable a PCI device, which means the device will be automatically disabled on driver detach. Thus there is no need to call pci_disable_device() again on it. With recent PCI device resource management improvements, e.g. commit f748a07a0b64 (\"PCI: Remove legacy pcim_release()\"), this problem is exposed and triggers the warining below. [ 224.010735] proc_thermal_pci 0000:00:04.0: disabling already-disabled device [ 224.010747] WARNING: CPU: 8 PID: 4442 at drivers/pci/pci.c:2250 pci_disable_device+0xe5/0x100 ... [ 224.010844] Call Trace: [ 224.010845] [ 224.010847] ? show_regs+0x6d/0x80 [ 224.010851] ? __warn+0x8c/0x140 [ 224.010854] ? pci_disable_device+0xe5/0x100 [ 224.010856] ? report_bug+0x1c9/0x1e0 [ 224.010859] ? handle_bug+0x46/0x80 [ 224.010862] ? exc_invalid_op+0x1d/0x80 [ 224.010863] ? asm_exc_invalid_op+0x1f/0x30 [ 224.010867] ? pci_disable_device+0xe5/0x100 [ 224.010869] ? pci_disable_device+0xe5/0x100 [ 224.010871] ? kfree+0x21a/0x2b0 [ 224.010873] pcim_disable_device+0x20/0x30 [ 224.010875] devm_action_release+0x16/0x20 [ 224.010878] release_nodes+0x47/0xc0 [ 224.010880] devres_release_all+0x9f/0xe0 [ 224.010883] device_unbind_cleanup+0x12/0x80 [ 224.010885] device_release_driver_internal+0x1ca/0x210 [ 224.010887] driver_detach+0x4e/0xa0 [ 224.010889] bus_remove_driver+0x6f/0xf0 [ 224.010890] driver_unregister+0x35/0x60 [ 224.010892] pci_unregister_driver+0x44/0x90 [ 224.010894] proc_thermal_pci_driver_exit+0x14/0x5f0 [processor_thermal_device_pci] ... [ 224.010921] ---[ end trace 0000000000000000 ]--- Remove the excess pci_disable_device() calls. [ rjw: Subject and changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50043", "url": "https://ubuntu.com/security/CVE-2024-50043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix possible badness in FREE_STATEID When multiple FREE_STATEIDs are sent for the same delegation stateid, it can lead to a possible either use-after-free or counter refcount underflow errors. In nfsd4_free_stateid() under the client lock we find a delegation stateid, however the code drops the lock before calling nfs4_put_stid(), that allows another FREE_STATE to find the stateid again. The first one will proceed to then free the stateid which leads to either use-after-free or decrementing already zeroed counter.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50044", "url": "https://ubuntu.com/security/CVE-2024-50044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change rfcomm_sk_state_change attempts to use sock_lock so it must never be called with it locked but rfcomm_sock_ioctl always attempt to lock it causing the following trace: ====================================================== WARNING: possible circular locking dependency detected 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Not tainted ------------------------------------------------------ syz-executor386/5093 is trying to acquire lock: ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1671 [inline] ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73 but task is already holding lock: ffff88807badfd28 (&d->lock){+.+.}-{3:3}, at: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50045", "url": "https://ubuntu.com/security/CVE-2024-50045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: br_netfilter: fix panic with metadata_dst skb Fix a kernel panic in the br_netfilter module when sending untagged traffic via a VxLAN device. This happens during the check for fragmentation in br_nf_dev_queue_xmit. It is dependent on: 1) the br_netfilter module being loaded; 2) net.bridge.bridge-nf-call-iptables set to 1; 3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port; 4) untagged frames with size higher than the VxLAN MTU forwarded/flooded When forwarding the untagged packet to the VxLAN bridge port, before the netfilter hooks are called, br_handle_egress_vlan_tunnel is called and changes the skb_dst to the tunnel dst. The tunnel_dst is a metadata type of dst, i.e., skb_valid_dst(skb) is false, and metadata->dst.dev is NULL. Then in the br_netfilter hooks, in br_nf_dev_queue_xmit, there's a check for frames that needs to be fragmented: frames with higher MTU than the VxLAN device end up calling br_nf_ip_fragment, which in turns call ip_skb_dst_mtu. The ip_dst_mtu tries to use the skb_dst(skb) as if it was a valid dst with valid dst->dev, thus the crash. This case was never supported in the first place, so drop the packet instead. PING 10.0.0.2 (10.0.0.2) from 0.0.0.0 h1-eth0: 2000(2028) bytes of data. [ 176.291791] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000110 [ 176.292101] Mem abort info: [ 176.292184] ESR = 0x0000000096000004 [ 176.292322] EC = 0x25: DABT (current EL), IL = 32 bits [ 176.292530] SET = 0, FnV = 0 [ 176.292709] EA = 0, S1PTW = 0 [ 176.292862] FSC = 0x04: level 0 translation fault [ 176.293013] Data abort info: [ 176.293104] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 176.293488] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 176.293787] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 176.293995] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043ef5000 [ 176.294166] [0000000000000110] pgd=0000000000000000, p4d=0000000000000000 [ 176.294827] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 176.295252] Modules linked in: vxlan ip6_udp_tunnel udp_tunnel veth br_netfilter bridge stp llc ipv6 crct10dif_ce [ 176.295923] CPU: 0 PID: 188 Comm: ping Not tainted 6.8.0-rc3-g5b3fbd61b9d1 #2 [ 176.296314] Hardware name: linux,dummy-virt (DT) [ 176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 176.296808] pc : br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.297382] lr : br_nf_dev_queue_xmit+0x2ac/0x4ec [br_netfilter] [ 176.297636] sp : ffff800080003630 [ 176.297743] x29: ffff800080003630 x28: 0000000000000008 x27: ffff6828c49ad9f8 [ 176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24: 00000000000003e8 [ 176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21: ffff6828c3b16d28 [ 176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18: 0000000000000014 [ 176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15: 0000000095744632 [ 176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12: ffffb7e137926a70 [ 176.299574] x11: 0000000000000001 x10: ffff6828c3f1c898 x9 : 0000000000000000 [ 176.300049] x8 : ffff6828c49bf070 x7 : 0008460f18d5f20e x6 : f20e0100bebafeca [ 176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 : 0000000000000000 [ 176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 : ffff6828c7f918f0 [ 176.300889] Call trace: [ 176.301123] br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.301411] br_nf_post_routing+0x2a8/0x3e4 [br_netfilter] [ 176.301703] nf_hook_slow+0x48/0x124 [ 176.302060] br_forward_finish+0xc8/0xe8 [bridge] [ 176.302371] br_nf_hook_thresh+0x124/0x134 [br_netfilter] [ 176.302605] br_nf_forward_finish+0x118/0x22c [br_netfilter] [ 176.302824] br_nf_forward_ip.part.0+0x264/0x290 [br_netfilter] [ 176.303136] br_nf_forward+0x2b8/0x4e0 [br_netfilter] [ 176.303359] nf_hook_slow+0x48/0x124 [ 176.303 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50094", "url": "https://ubuntu.com/security/CVE-2024-50094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sfc: Don't invoke xdp_do_flush() from netpoll. Yury reported a crash in the sfc driver originated from netpoll_send_udp(). The netconsole sends a message and then netpoll invokes the driver's NAPI function with a budget of zero. It is dedicated to allow driver to free TX resources, that it may have used while sending the packet. In the netpoll case the driver invokes xdp_do_flush() unconditionally, leading to crash because bpf_net_context was never assigned. Invoke xdp_do_flush() only if budget is not zero.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50188", "url": "https://ubuntu.com/security/CVE-2024-50188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: dp83869: fix memory corruption when enabling fiber When configuring the fiber port, the DP83869 PHY driver incorrectly calls linkmode_set_bit() with a bit mask (1 << 10) rather than a bit number (10). This corrupts some other memory location -- in case of arm64 the priv pointer in the same structure. Since the advertising flags are updated from supported at the end of the function the incorrect line isn't needed at all and can be removed.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50046", "url": "https://ubuntu.com/security/CVE-2024-50046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies() On the node of an NFS client, some files saved in the mountpoint of the NFS server were copied to another location of the same NFS server. Accidentally, the nfs42_complete_copies() got a NULL-pointer dereference crash with the following syslog: [232064.838881] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232064.839360] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232066.588183] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 [232066.588586] Mem abort info: [232066.588701] ESR = 0x0000000096000007 [232066.588862] EC = 0x25: DABT (current EL), IL = 32 bits [232066.589084] SET = 0, FnV = 0 [232066.589216] EA = 0, S1PTW = 0 [232066.589340] FSC = 0x07: level 3 translation fault [232066.589559] Data abort info: [232066.589683] ISV = 0, ISS = 0x00000007 [232066.589842] CM = 0, WnR = 0 [232066.589967] user pgtable: 64k pages, 48-bit VAs, pgdp=00002000956ff400 [232066.590231] [0000000000000058] pgd=08001100ae100003, p4d=08001100ae100003, pud=08001100ae100003, pmd=08001100b3c00003, pte=0000000000000000 [232066.590757] Internal error: Oops: 96000007 [#1] SMP [232066.590958] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm vhost_net vhost vhost_iotlb tap tun ipt_rpfilter xt_multiport ip_set_hash_ip ip_set_hash_net xfrm_interface xfrm6_tunnel tunnel4 tunnel6 esp4 ah4 wireguard libcurve25519_generic veth xt_addrtype xt_set nf_conntrack_netlink ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_bitmap_port ip_set_hash_ipport dummy ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs iptable_filter sch_ingress nfnetlink_cttimeout vport_gre ip_gre ip_tunnel gre vport_geneve geneve vport_vxlan vxlan ip6_udp_tunnel udp_tunnel openvswitch nf_conncount dm_round_robin dm_service_time dm_multipath xt_nat xt_MASQUERADE nft_chain_nat nf_nat xt_mark xt_conntrack xt_comment nft_compat nft_counter nf_tables nfnetlink ocfs2 ocfs2_nodemanager ocfs2_stackglue iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_ssif nbd overlay 8021q garp mrp bonding tls rfkill sunrpc ext4 mbcache jbd2 [232066.591052] vfat fat cas_cache cas_disk ses enclosure scsi_transport_sas sg acpi_ipmi ipmi_si ipmi_devintf ipmi_msghandler ip_tables vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio dm_mirror dm_region_hash dm_log dm_mod nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc fuse xfs libcrc32c ast drm_vram_helper qla2xxx drm_kms_helper syscopyarea crct10dif_ce sysfillrect ghash_ce sysimgblt sha2_ce fb_sys_fops cec sha256_arm64 sha1_ce drm_ttm_helper ttm nvme_fc igb sbsa_gwdt nvme_fabrics drm nvme_core i2c_algo_bit i40e scsi_transport_fc megaraid_sas aes_neon_bs [232066.596953] CPU: 6 PID: 4124696 Comm: 10.253.166.125- Kdump: loaded Not tainted 5.15.131-9.cl9_ocfs2.aarch64 #1 [232066.597356] Hardware name: Great Wall .\\x93\\x8e...RF6260 V5/GWMSSE2GL1T, BIOS T656FBE_V3.0.18 2024-01-06 [232066.597721] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [232066.598034] pc : nfs4_reclaim_open_state+0x220/0x800 [nfsv4] [232066.598327] lr : nfs4_reclaim_open_state+0x12c/0x800 [nfsv4] [232066.598595] sp : ffff8000f568fc70 [232066.598731] x29: ffff8000f568fc70 x28: 0000000000001000 x27: ffff21003db33000 [232066.599030] x26: ffff800005521ae0 x25: ffff0100f98fa3f0 x24: 0000000000000001 [232066.599319] x23: ffff800009920008 x22: ffff21003db33040 x21: ffff21003db33050 [232066.599628] x20: ffff410172fe9e40 x19: ffff410172fe9e00 x18: 0000000000000000 [232066.599914] x17: 0000000000000000 x16: 0000000000000004 x15: 0000000000000000 [232066.600195] x14: 0000000000000000 x13: ffff800008e685a8 x12: 00000000eac0c6e6 [232066.600498] x11: 00000000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50190", "url": "https://ubuntu.com/security/CVE-2024-50190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix memleak in ice_init_tx_topology() Fix leak of the FW blob (DDP pkg). Make ice_cfg_tx_topo() const-correct, so ice_init_tx_topology() can avoid copying whole FW blob. Copy just the topology section, and only when needed. Reuse the buffer allocated for the read of the current topology. This was found by kmemleak, with the following trace for each PF: [] kmemdup_noprof+0x1d/0x50 [] ice_init_ddp_config+0x100/0x220 [ice] [] ice_init_dev+0x6f/0x200 [ice] [] ice_init+0x29/0x560 [ice] [] ice_probe+0x21d/0x310 [ice] Constify ice_cfg_tx_topo() @buf parameter. This cascades further down to few more functions.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50180", "url": "https://ubuntu.com/security/CVE-2024-50180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: sisfb: Fix strbuf array overflow The values of the variables xres and yres are placed in strbuf. These variables are obtained from strbuf1. The strbuf1 array contains digit characters and a space if the array contains non-digit characters. Then, when executing sprintf(strbuf, \"%ux%ux8\", xres, yres); more than 16 bytes will be written to strbuf. It is suggested to increase the size of the strbuf array to 24. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06: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": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50048", "url": "https://ubuntu.com/security/CVE-2024-50048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: Fix a NULL pointer dereference issue in fbcon_putcs syzbot has found a NULL pointer dereference bug in fbcon. Here is the simplified C reproducer: struct param { \tuint8_t type; \tstruct tiocl_selection ts; }; int main() { \tstruct fb_con2fbmap con2fb; \tstruct param param; \tint fd = open(\"/dev/fb1\", 0, 0); \tcon2fb.console = 0x19; \tcon2fb.framebuffer = 0; \tioctl(fd, FBIOPUT_CON2FBMAP, &con2fb); \tparam.type = 2; \tparam.ts.xs = 0; param.ts.ys = 0; \tparam.ts.xe = 0; param.ts.ye = 0; \tparam.ts.sel_mode = 0; \tint fd1 = open(\"/dev/tty1\", O_RDWR, 0); \tioctl(fd1, TIOCLINUX, ¶m); \tcon2fb.console = 1; \tcon2fb.framebuffer = 0; \tioctl(fd, FBIOPUT_CON2FBMAP, &con2fb); \treturn 0; } After calling ioctl(fd1, TIOCLINUX, ¶m), the subsequent ioctl(fd, FBIOPUT_CON2FBMAP, &con2fb) causes the kernel to follow a different execution path: set_con2fb_map -> con2fb_init_display -> fbcon_set_disp -> redraw_screen -> hide_cursor -> clear_selection -> highlight -> invert_screen -> do_update_region -> fbcon_putcs -> ops->putcs Since ops->putcs is a NULL pointer, this leads to a kernel panic. To prevent this, we need to call set_blitting_type() within set_con2fb_map() to properly initialize ops->putcs.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50049", "url": "https://ubuntu.com/security/CVE-2024-50049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before dereferencing se [WHAT & HOW] se is null checked previously in the same function, indicating it might be null; therefore, it must be checked when used again. This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50090", "url": "https://ubuntu.com/security/CVE-2024-50090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/oa: Fix overflow in oa batch buffer By default xe_bb_create_job() appends a MI_BATCH_BUFFER_END to batch buffer, this is not a problem if batch buffer is only used once but oa reuses the batch buffer for the same metric and at each call it appends a MI_BATCH_BUFFER_END, printing the warning below and then overflowing. [ 381.072016] ------------[ cut here ]------------ [ 381.072019] xe 0000:00:02.0: [drm] Assertion `bb->len * 4 + bb_prefetch(q->gt) <= size` failed! platform: LUNARLAKE subplatform: 1 graphics: Xe2_LPG / Xe2_HPG 20.04 step B0 media: Xe2_LPM / Xe2_HPM 20.00 step B0 tile: 0 VRAM 0 B GT: 0 type 1 So here checking if batch buffer already have MI_BATCH_BUFFER_END if not append it. v2: - simply fix, suggestion from Ashutosh (cherry picked from commit 9ba0e0f30ca42a98af3689460063edfb6315718a)", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50183", "url": "https://ubuntu.com/security/CVE-2024-50183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV instance Deleting an NPIV instance requires all fabric ndlps to be released before an NPIV's resources can be torn down. Failure to release fabric ndlps beforehand opens kref imbalance race conditions. Fix by forcing the DA_ID to complete synchronously with usage of wait_queue.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50055", "url": "https://ubuntu.com/security/CVE-2024-50055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: driver core: bus: Fix double free in driver API bus_register() For bus_register(), any error which happens after kset_register() will cause that @priv are freed twice, fixed by setting @priv with NULL after the first free.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50091", "url": "https://ubuntu.com/security/CVE-2024-50091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm vdo: don't refer to dedupe_context after releasing it Clear the dedupe_context pointer in a data_vio whenever ownership of the context is lost, so that vdo can't examine it accidentally.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50056", "url": "https://ubuntu.com/security/CVE-2024-50056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: Fix ERR_PTR dereference in uvc_v4l2.c Fix potential dereferencing of ERR_PTR() in find_format_by_pix() and uvc_v4l2_enum_format(). Fix the following smatch errors: drivers/usb/gadget/function/uvc_v4l2.c:124 find_format_by_pix() error: 'fmtdesc' dereferencing possible ERR_PTR() drivers/usb/gadget/function/uvc_v4l2.c:392 uvc_v4l2_enum_format() error: 'fmtdesc' dereferencing possible ERR_PTR() Also, fix similar issue in uvc_v4l2_try_format() for potential dereferencing of ERR_PTR().", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50184", "url": "https://ubuntu.com/security/CVE-2024-50184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_pmem: Check device status before requesting flush If a pmem device is in a bad status, the driver side could wait for host ack forever in virtio_pmem_flush(), causing the system to hang. So add a status check in the beginning of virtio_pmem_flush() to return early if the device is not activated.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50057", "url": "https://ubuntu.com/security/CVE-2024-50057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: tipd: Free IRQ only if it was requested before In polling mode, if no IRQ was requested there is no need to free it. Call devm_free_irq() only if client->irq is set. This fixes the warning caused by the tps6598x module removal: WARNING: CPU: 2 PID: 333 at kernel/irq/devres.c:144 devm_free_irq+0x80/0x8c ... ... Call trace: devm_free_irq+0x80/0x8c tps6598x_remove+0x28/0x88 [tps6598x] i2c_device_remove+0x2c/0x9c device_remove+0x4c/0x80 device_release_driver_internal+0x1cc/0x228 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 i2c_del_driver+0x54/0x64 tps6598x_i2c_driver_exit+0x18/0xc3c [tps6598x] __arm64_sys_delete_module+0x184/0x264 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc8/0xe8 do_el0_svc+0x20/0x2c el0_svc+0x28/0x98 el0t_64_sync_handler+0x13c/0x158 el0t_64_sync+0x190/0x194", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50058", "url": "https://ubuntu.com/security/CVE-2024-50058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: protect uart_port_dtr_rts() in uart_shutdown() too Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part 3) added few uport == NULL checks. It added one to uart_shutdown(), so the commit assumes, uport can be NULL in there. But right after that protection, there is an unprotected \"uart_port_dtr_rts(uport, false);\" call. That is invoked only if HUPCL is set, so I assume that is the reason why we do not see lots of these reports. Or it cannot be NULL at this point at all for some reason :P. Until the above is investigated, stay on the safe side and move this dereference to the if too. I got this inconsistency from Coverity under CID 1585130. Thanks.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50181", "url": "https://ubuntu.com/security/CVE-2024-50181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: imx: Remove CLK_SET_PARENT_GATE for DRAM mux for i.MX7D For i.MX7D DRAM related mux clock, the clock source change should ONLY be done done in low level asm code without accessing DRAM, and then calling clk API to sync the HW clock status with clk tree, it should never touch real clock source switch via clk API, so CLK_SET_PARENT_GATE flag should NOT be added, otherwise, DRAM's clock parent will be disabled when DRAM is active, and system will hang.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50059", "url": "https://ubuntu.com/security/CVE-2024-50059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntb: ntb_hw_switchtec: Fix use after free vulnerability in switchtec_ntb_remove due to race condition In the switchtec_ntb_add function, it can call switchtec_ntb_init_sndev function, then &sndev->check_link_status_work is bound with check_link_status_work. switchtec_ntb_link_notification may be called to start the work. If we remove the module which will call switchtec_ntb_remove to make cleanup, it will free sndev through kfree(sndev), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | check_link_status_work switchtec_ntb_remove | kfree(sndev); | | if (sndev->link_force_down) | // use sndev Fix it by ensuring that the work is canceled before proceeding with the cleanup in switchtec_ntb_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50060", "url": "https://ubuntu.com/security/CVE-2024-50060", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring: check if we need to reschedule during overflow flush In terms of normal application usage, this list will always be empty. And if an application does overflow a bit, it'll have a few entries. However, nothing obviously prevents syzbot from running a test case that generates a ton of overflow entries, and then flushing them can take quite a while. Check for needing to reschedule while flushing, and drop our locks and do so if necessary. There's no state to maintain here as overflows always prune from head-of-list, hence it's fine to drop and reacquire the locks at the end of the loop.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50061", "url": "https://ubuntu.com/security/CVE-2024-50061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: cdns: Fix use after free vulnerability in cdns_i3c_master Driver Due to Race Condition In the cdns_i3c_master_probe function, &master->hj_work is bound with cdns_i3c_master_hj. And cdns_i3c_master_interrupt can call cnds_i3c_master_demux_ibis function to start the work. If we remove the module which will call cdns_i3c_master_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | cdns_i3c_master_hj cdns_i3c_master_remove | i3c_master_unregister(&master->base) | device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in cdns_i3c_master_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50062", "url": "https://ubuntu.com/security/CVE-2024-50062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-srv: Avoid null pointer deref during path establishment For RTRS path establishment, RTRS client initiates and completes con_num of connections. After establishing all its connections, the information is exchanged between the client and server through the info_req message. During this exchange, it is essential that all connections have been established, and the state of the RTRS srv path is CONNECTED. So add these sanity checks, to make sure we detect and abort process in error scenarios to avoid null pointer deref.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50095", "url": "https://ubuntu.com/security/CVE-2024-50095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mad: Improve handling of timed out WRs of mad agent Current timeout handler of mad agent acquires/releases mad_agent_priv lock for every timed out WRs. This causes heavy locking contention when higher no. of WRs are to be handled inside timeout handler. This leads to softlockup with below trace in some use cases where rdma-cm path is used to establish connection between peer nodes Trace: ----- BUG: soft lockup - CPU#4 stuck for 26s! [kworker/u128:3:19767] CPU: 4 PID: 19767 Comm: kworker/u128:3 Kdump: loaded Tainted: G OE ------- --- 5.14.0-427.13.1.el9_4.x86_64 #1 Hardware name: Dell Inc. PowerEdge R740/01YM03, BIOS 2.4.8 11/26/2019 Workqueue: ib_mad1 timeout_sends [ib_core] RIP: 0010:__do_softirq+0x78/0x2ac RSP: 0018:ffffb253449e4f98 EFLAGS: 00000246 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 000000000000001f RDX: 000000000000001d RSI: 000000003d1879ab RDI: fff363b66fd3a86b RBP: ffffb253604cbcd8 R08: 0000009065635f3b R09: 0000000000000000 R10: 0000000000000040 R11: ffffb253449e4ff8 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000040 FS: 0000000000000000(0000) GS:ffff8caa1fc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd9ec9db900 CR3: 0000000891934006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? __irq_exit_rcu+0xa1/0xc0 ? watchdog_timer_fn+0x1b2/0x210 ? __pfx_watchdog_timer_fn+0x10/0x10 ? __hrtimer_run_queues+0x127/0x2c0 ? hrtimer_interrupt+0xfc/0x210 ? __sysvec_apic_timer_interrupt+0x5c/0x110 ? sysvec_apic_timer_interrupt+0x37/0x90 ? asm_sysvec_apic_timer_interrupt+0x16/0x20 ? __do_softirq+0x78/0x2ac ? __do_softirq+0x60/0x2ac __irq_exit_rcu+0xa1/0xc0 sysvec_call_function_single+0x72/0x90 asm_sysvec_call_function_single+0x16/0x20 RIP: 0010:_raw_spin_unlock_irq+0x14/0x30 RSP: 0018:ffffb253604cbd88 EFLAGS: 00000247 RAX: 000000000001960d RBX: 0000000000000002 RCX: ffff8cad2a064800 RDX: 000000008020001b RSI: 0000000000000001 RDI: ffff8cad5d39f66c RBP: ffff8cad5d39f600 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8caa443e0c00 R11: ffffb253604cbcd8 R12: ffff8cacb8682538 R13: 0000000000000005 R14: ffffb253604cbd90 R15: ffff8cad5d39f66c cm_process_send_error+0x122/0x1d0 [ib_cm] timeout_sends+0x1dd/0x270 [ib_core] process_one_work+0x1e2/0x3b0 ? __pfx_worker_thread+0x10/0x10 worker_thread+0x50/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xdd/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x50 Simplified timeout handler by creating local list of timed out WRs and invoke send handler post creating the list. The new method acquires/ releases lock once to fetch the list and hence helps to reduce locking contetiong when processing higher no. of WRs", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50063", "url": "https://ubuntu.com/security/CVE-2024-50063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Prevent tail call between progs attached to different hooks bpf progs can be attached to kernel functions, and the attached functions can take different parameters or return different return values. If prog attached to one kernel function tail calls prog attached to another kernel function, the ctx access or return value verification could be bypassed. For example, if prog1 is attached to func1 which takes only 1 parameter and prog2 is attached to func2 which takes two parameters. Since verifier assumes the bpf ctx passed to prog2 is constructed based on func2's prototype, verifier allows prog2 to access the second parameter from the bpf ctx passed to it. The problem is that verifier does not prevent prog1 from passing its bpf ctx to prog2 via tail call. In this case, the bpf ctx passed to prog2 is constructed from func1 instead of func2, that is, the assumption for ctx access verification is bypassed. Another example, if BPF LSM prog1 is attached to hook file_alloc_security, and BPF LSM prog2 is attached to hook bpf_lsm_audit_rule_known. Verifier knows the return value rules for these two hooks, e.g. it is legal for bpf_lsm_audit_rule_known to return positive number 1, and it is illegal for file_alloc_security to return positive number. So verifier allows prog2 to return positive number 1, but does not allow prog1 to return positive number. The problem is that verifier does not prevent prog1 from calling prog2 via tail call. In this case, prog2's return value 1 will be used as the return value for prog1's hook file_alloc_security. That is, the return value rule is bypassed. This patch adds restriction for tail call to prevent such bypasses.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50191", "url": "https://ubuntu.com/security/CVE-2024-50191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: don't set SB_RDONLY after filesystem errors When the filesystem is mounted with errors=remount-ro, we were setting SB_RDONLY flag to stop all filesystem modifications. We knew this misses proper locking (sb->s_umount) and does not go through proper filesystem remount procedure but it has been the way this worked since early ext2 days and it was good enough for catastrophic situation damage mitigation. Recently, syzbot has found a way (see link) to trigger warnings in filesystem freezing because the code got confused by SB_RDONLY changing under its hands. Since these days we set EXT4_FLAGS_SHUTDOWN on the superblock which is enough to stop all filesystem modifications, modifying SB_RDONLY shouldn't be needed. So stop doing that.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50064", "url": "https://ubuntu.com/security/CVE-2024-50064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: zram: free secondary algorithms names We need to kfree() secondary algorithms names when reset zram device that had multi-streams, otherwise we leak memory. [senozhatsky@chromium.org: kfree(NULL) is legal] Link: https://lkml.kernel.org/r/20240917013021.868769-1-senozhatsky@chromium.org", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50065", "url": "https://ubuntu.com/security/CVE-2024-50065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Change to non-blocking allocation in ntfs_d_hash d_hash is done while under \"rcu-walk\" and should not sleep. __get_name() allocates using GFP_KERNEL, having the possibility to sleep when under memory pressure. Change the allocation to GFP_NOWAIT.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50089", "url": "https://ubuntu.com/security/CVE-2024-50089", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-49863", "url": "https://ubuntu.com/security/CVE-2024-49863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost/scsi: null-ptr-dereference in vhost_scsi_get_req() Since commit 3f8ca2e115e5 (\"vhost/scsi: Extract common handling code from control queue handler\") a null pointer dereference bug can be triggered when guest sends an SCSI AN request. In vhost_scsi_ctl_handle_vq(), `vc.target` is assigned with `&v_req.tmf.lun[1]` within a switch-case block and is then passed to vhost_scsi_get_req() which extracts `vc->req` and `tpg`. However, for a `VIRTIO_SCSI_T_AN_*` request, tpg is not required, so `vc.target` is set to NULL in this branch. Later, in vhost_scsi_get_req(), `vc->target` is dereferenced without being checked, leading to a null pointer dereference bug. This bug can be triggered from guest. When this bug occurs, the vhost_worker process is killed while holding `vq->mutex` and the corresponding tpg will remain occupied indefinitely. Below is the KASAN report: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 PID: 840 Comm: poc Not tainted 6.10.0+ #1 Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:vhost_scsi_get_req+0x165/0x3a0 Code: 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 02 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 65 30 4c 89 e2 48 c1 ea 03 <0f> b6 04 02 4c 89 e2 83 e2 07 38 d0 7f 08 84 c0 0f 85 be 01 00 00 RSP: 0018:ffff888017affb50 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffff88801b000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888017affcb8 RBP: ffff888017affb80 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff888017affc88 R14: ffff888017affd1c R15: ffff888017993000 FS: 000055556e076500(0000) GS:ffff88806b100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200027c0 CR3: 0000000010ed0004 CR4: 0000000000370ef0 Call Trace: ? show_regs+0x86/0xa0 ? die_addr+0x4b/0xd0 ? exc_general_protection+0x163/0x260 ? asm_exc_general_protection+0x27/0x30 ? vhost_scsi_get_req+0x165/0x3a0 vhost_scsi_ctl_handle_vq+0x2a4/0xca0 ? __pfx_vhost_scsi_ctl_handle_vq+0x10/0x10 ? __switch_to+0x721/0xeb0 ? __schedule+0xda5/0x5710 ? __kasan_check_write+0x14/0x30 ? _raw_spin_lock+0x82/0xf0 vhost_scsi_ctl_handle_kick+0x52/0x90 vhost_run_work_list+0x134/0x1b0 vhost_task_fn+0x121/0x350 ... ---[ end trace 0000000000000000 ]--- Let's add a check in vhost_scsi_get_req. [whitespace fixes]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49864", "url": "https://ubuntu.com/security/CVE-2024-49864", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix a race between socket set up and I/O thread creation In rxrpc_open_socket(), it sets up the socket and then sets up the I/O thread that will handle it. This is a problem, however, as there's a gap between the two phases in which a packet may come into rxrpc_encap_rcv() from the UDP packet but we oops when trying to wake the not-yet created I/O thread. As a quick fix, just make rxrpc_encap_rcv() discard the packet if there's no I/O thread yet. A better, but more intrusive fix would perhaps be to rearrange things such that the socket creation is done by the I/O thread.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49865", "url": "https://ubuntu.com/security/CVE-2024-49865", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: move xa_alloc to prevent UAF Evil user can guess the next id of the vm before the ioctl completes and then call vm destroy ioctl to trigger UAF since create ioctl is still referencing the same vm. Move the xa_alloc all the way to the end to prevent this. v2: - Rebase (cherry picked from commit dcfd3971327f3ee92765154baebbaece833d3ca9)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49955", "url": "https://ubuntu.com/security/CVE-2024-49955", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: battery: Fix possible crash when unregistering a battery hook When a battery hook returns an error when adding a new battery, then the battery hook is automatically unregistered. However the battery hook provider cannot know that, so it will later call battery_hook_unregister() on the already unregistered battery hook, resulting in a crash. Fix this by using the list head to mark already unregistered battery hooks as already being unregistered so that they can be ignored by battery_hook_unregister().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49973", "url": "https://ubuntu.com/security/CVE-2024-49973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: r8169: add tally counter fields added with RTL8125 RTL8125 added fields to the tally counter, what may result in the chip dma'ing these new fields to unallocated memory. Therefore make sure that the allocated memory area is big enough to hold all of the tally counter values, even if we use only parts of it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49974", "url": "https://ubuntu.com/security/CVE-2024-49974", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Limit the number of concurrent async COPY operations Nothing appears to limit the number of concurrent async COPY operations that clients can start. In addition, AFAICT each async COPY can copy an unlimited number of 4MB chunks, so can run for a long time. Thus IMO async COPY can become a DoS vector. Add a restriction mechanism that bounds the number of concurrent background COPY operations. Start simple and try to be fair -- this patch implements a per-namespace limit. An async COPY request that occurs while this limit is exceeded gets NFS4ERR_DELAY. The requesting client can choose to send the request again after a delay or fall back to a traditional read/write style copy. If there is need to make the mechanism more sophisticated, we can visit that in future patches.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49975", "url": "https://ubuntu.com/security/CVE-2024-49975", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uprobes: fix kernel info leak via \"[uprobes]\" vma xol_add_vma() maps the uninitialized page allocated by __create_xol_area() into userspace. On some architectures (x86) this memory is readable even without VM_READ, VM_EXEC results in the same pgprot_t as VM_EXEC|VM_READ, although this doesn't really matter, debugger can read this memory anyway.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50003", "url": "https://ubuntu.com/security/CVE-2024-50003", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix system hang while resume with TBT monitor [Why] Connected with a Thunderbolt monitor and do the suspend and the system may hang while resume. The TBT monitor HPD will be triggered during the resume procedure and call the drm_client_modeset_probe() while struct drm_connector connector->dev->master is NULL. It will mess up the pipe topology after resume. [How] Skip the TBT monitor HPD during the resume procedure because we currently will probe the connectors after resume by default. (cherry picked from commit 453f86a26945207a16b8f66aaed5962dc2b95b85)", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50173", "url": "https://ubuntu.com/security/CVE-2024-50173", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix access to uninitialized variable in tick_ctx_cleanup() The group variable can't be used to retrieve ptdev in our second loop, because it points to the previously iterated list_head, not a valid group. Get the ptdev object from the scheduler instead.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49866", "url": "https://ubuntu.com/security/CVE-2024-49866", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Fix a race during cpuhp processing There is another found exception that the \"timerlat/1\" thread was scheduled on CPU0, and lead to timer corruption finally: ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ``` After tracing the scheduling event, it was discovered that the migration of the \"timerlat/1\" thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() | To fix this, skip online processing if the CPU is already offline.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49976", "url": "https://ubuntu.com/security/CVE-2024-49976", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Drop interface_lock in stop_kthread() stop_kthread() is the offline callback for \"trace/osnoise:online\", since commit 5bfbcd1ee57b (\"tracing/timerlat: Add interface_lock around clearing of kthread in stop_kthread()\"), the following ABBA deadlock scenario is introduced: T1 | T2 [BP] | T3 [AP] osnoise_hotplug_workfn() | work_for_cpu_fn() | cpuhp_thread_fun() | _cpu_down() | osnoise_cpu_die() mutex_lock(&interface_lock) | | stop_kthread() | cpus_write_lock() | mutex_lock(&interface_lock) cpus_read_lock() | cpuhp_kick_ap() | As the interface_lock here in just for protecting the \"kthread\" field of the osn_var, use xchg() instead to fix this issue. Also use for_each_online_cpu() back in stop_per_cpu_kthreads() as it can take cpu_read_lock() again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50005", "url": "https://ubuntu.com/security/CVE-2024-50005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: Fix potential RCU dereference issue in mac802154_scan_worker In the `mac802154_scan_worker` function, the `scan_req->type` field was accessed after the RCU read-side critical section was unlocked. According to RCU usage rules, this is illegal and can lead to unpredictable behavior, such as accessing memory that has been updated or causing use-after-free issues. This possible bug was identified using a static analysis tool developed by myself, specifically designed to detect RCU-related issues. To address this, the `scan_req->type` value is now stored in a local variable `scan_req_type` while still within the RCU read-side critical section. The `scan_req_type` is then used after the RCU lock is released, ensuring that the type value is safely accessed without violating RCU rules.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50012", "url": "https://ubuntu.com/security/CVE-2024-50012", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: Avoid a bad reference count on CPU node In the parse_perf_domain function, if the call to of_parse_phandle_with_args returns an error, then the reference to the CPU device node that was acquired at the start of the function would not be properly decremented. Address this by declaring the variable with the __free(device_node) cleanup attribute.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49867", "url": "https://ubuntu.com/security/CVE-2024-49867", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: wait for fixup workers before stopping cleaner kthread during umount During unmount, at close_ctree(), we have the following steps in this order: 1) Park the cleaner kthread - this doesn't destroy the kthread, it basically halts its execution (wake ups against it work but do nothing); 2) We stop the cleaner kthread - this results in freeing the respective struct task_struct; 3) We call btrfs_stop_all_workers() which waits for any jobs running in all the work queues and then free the work queues. Syzbot reported a case where a fixup worker resulted in a crash when doing a delayed iput on its inode while attempting to wake up the cleaner at btrfs_add_delayed_iput(), because the task_struct of the cleaner kthread was already freed. This can happen during unmount because we don't wait for any fixup workers still running before we call kthread_stop() against the cleaner kthread, which stops and free all its resources. Fix this by waiting for any fixup workers at close_ctree() before we call kthread_stop() against the cleaner and run pending delayed iputs. The stack traces reported by syzbot were the following: BUG: KASAN: slab-use-after-free in __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 Read of size 8 at addr ffff8880272a8a18 by task kworker/u8:3/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.12.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: btrfs-fixup btrfs_work_helper 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 __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline] try_to_wake_up+0xb0/0x1480 kernel/sched/core.c:4154 btrfs_writepage_fixup_worker+0xc16/0xdf0 fs/btrfs/inode.c:2842 btrfs_work_helper+0x390/0xc50 fs/btrfs/async-thread.c:314 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Allocated by task 2: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:319 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345 kasan_slab_alloc include/linux/kasan.h:247 [inline] slab_post_alloc_hook mm/slub.c:4086 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4187 alloc_task_struct_node kernel/fork.c:180 [inline] dup_task_struct+0x57/0x8c0 kernel/fork.c:1107 copy_process+0x5d1/0x3d50 kernel/fork.c:2206 kernel_clone+0x223/0x880 kernel/fork.c:2787 kernel_thread+0x1bc/0x240 kernel/fork.c:2849 create_kthread kernel/kthread.c:412 [inline] kthreadd+0x60d/0x810 kernel/kthread.c:765 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Freed by task 61: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:230 [inline] slab_free_h ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49868", "url": "https://ubuntu.com/security/CVE-2024-49868", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix a NULL pointer dereference when failed to start a new trasacntion [BUG] Syzbot reported a NULL pointer dereference with the following crash: FAULT_INJECTION: forcing a failure. start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676 prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642 relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678 ... BTRFS info (device loop0): balance: ended with status: -12 Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667] RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926 Call Trace: commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496 btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430 del_balance_item fs/btrfs/volumes.c:3678 [inline] reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742 btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574 btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673 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/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [CAUSE] The allocation failure happens at the start_transaction() inside prepare_to_relocate(), and during the error handling we call unset_reloc_control(), which makes fs_info->balance_ctl to be NULL. Then we continue the error path cleanup in btrfs_balance() by calling reset_balance_state() which will call del_balance_item() to fully delete the balance item in the root tree. However during the small window between set_reloc_contrl() and unset_reloc_control(), we can have a subvolume tree update and created a reloc_root for that subvolume. Then we go into the final btrfs_commit_transaction() of del_balance_item(), and into btrfs_update_reloc_root() inside commit_fs_roots(). That function checks if fs_info->reloc_ctl is in the merge_reloc_tree stage, but since fs_info->reloc_ctl is NULL, it results a NULL pointer dereference. [FIX] Just add extra check on fs_info->reloc_ctl inside btrfs_update_reloc_root(), before checking fs_info->reloc_ctl->merge_reloc_tree. That DEAD_RELOC_TREE handling is to prevent further modification to the reloc tree during merge stage, but since there is no reloc_ctl at all, we do not need to bother that.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49869", "url": "https://ubuntu.com/security/CVE-2024-49869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: send: fix buffer overflow detection when copying path to cache entry Starting with commit c0247d289e73 (\"btrfs: send: annotate struct name_cache_entry with __counted_by()\") we annotated the variable length array \"name\" from the name_cache_entry structure with __counted_by() to improve overflow detection. However that alone was not correct, because the length of that array does not match the \"name_len\" field - it matches that plus 1 to include the NUL string terminator, so that makes a fortified kernel think there's an overflow and report a splat like this: strcpy: detected buffer overflow: 20 byte write of buffer size 19 WARNING: CPU: 3 PID: 3310 at __fortify_report+0x45/0x50 CPU: 3 UID: 0 PID: 3310 Comm: btrfs Not tainted 6.11.0-prnet #1 Hardware name: CompuLab Ltd. sbc-ihsw/Intense-PC2 (IPC2), BIOS IPC2_3.330.7 X64 03/15/2018 RIP: 0010:__fortify_report+0x45/0x50 Code: 48 8b 34 (...) RSP: 0018:ffff97ebc0d6f650 EFLAGS: 00010246 RAX: 7749924ef60fa600 RBX: ffff8bf5446a521a RCX: 0000000000000027 RDX: 00000000ffffdfff RSI: ffff97ebc0d6f548 RDI: ffff8bf84e7a1cc8 RBP: ffff8bf548574080 R08: ffffffffa8c40e10 R09: 0000000000005ffd R10: 0000000000000004 R11: ffffffffa8c70e10 R12: ffff8bf551eef400 R13: 0000000000000000 R14: 0000000000000013 R15: 00000000000003a8 FS: 00007fae144de8c0(0000) GS:ffff8bf84e780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fae14691690 CR3: 00000001027a2003 CR4: 00000000001706f0 Call Trace: ? __warn+0x12a/0x1d0 ? __fortify_report+0x45/0x50 ? report_bug+0x154/0x1c0 ? handle_bug+0x42/0x70 ? exc_invalid_op+0x1a/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? __fortify_report+0x45/0x50 __fortify_panic+0x9/0x10 __get_cur_name_and_parent+0x3bc/0x3c0 get_cur_path+0x207/0x3b0 send_extent_data+0x709/0x10d0 ? find_parent_nodes+0x22df/0x25d0 ? mas_nomem+0x13/0x90 ? mtree_insert_range+0xa5/0x110 ? btrfs_lru_cache_store+0x5f/0x1e0 ? iterate_extent_inodes+0x52d/0x5a0 process_extent+0xa96/0x11a0 ? __pfx_lookup_backref_cache+0x10/0x10 ? __pfx_store_backref_cache+0x10/0x10 ? __pfx_iterate_backrefs+0x10/0x10 ? __pfx_check_extent_item+0x10/0x10 changed_cb+0x6fa/0x930 ? tree_advance+0x362/0x390 ? memcmp_extent_buffer+0xd7/0x160 send_subvol+0xf0a/0x1520 btrfs_ioctl_send+0x106b/0x11d0 ? __pfx___clone_root_cmp_sort+0x10/0x10 _btrfs_ioctl_send+0x1ac/0x240 btrfs_ioctl+0x75b/0x850 __se_sys_ioctl+0xca/0x150 do_syscall_64+0x85/0x160 ? __count_memcg_events+0x69/0x100 ? handle_mm_fault+0x1327/0x15c0 ? __se_sys_rt_sigprocmask+0xf1/0x180 ? syscall_exit_to_user_mode+0x75/0xa0 ? do_syscall_64+0x91/0x160 ? do_user_addr_fault+0x21d/0x630 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fae145eeb4f Code: 00 48 89 (...) RSP: 002b:00007ffdf1cb09b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fae145eeb4f RDX: 00007ffdf1cb0ad0 RSI: 0000000040489426 RDI: 0000000000000004 RBP: 00000000000078fe R08: 00007fae144006c0 R09: 00007ffdf1cb0927 R10: 0000000000000008 R11: 0000000000000246 R12: 00007ffdf1cb1ce8 R13: 0000000000000003 R14: 000055c499fab2e0 R15: 0000000000000004 Fix this by not storing the NUL string terminator since we don't actually need it for name cache entries, this way \"name_len\" corresponds to the actual size of the \"name\" array. This requires marking the \"name\" array field with __nonstring and using memcpy() instead of strcpy() as recommended by the guidelines at: https://github.com/KSPP/linux/issues/90", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49870", "url": "https://ubuntu.com/security/CVE-2024-49870", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cachefiles: fix dentry leak in cachefiles_open_file() A dentry leak may be caused when a lookup cookie and a cull are concurrent: P1 | P2 ----------------------------------------------------------- cachefiles_lookup_cookie cachefiles_look_up_object lookup_one_positive_unlocked // get dentry cachefiles_cull inode->i_flags |= S_KERNEL_FILE; cachefiles_open_file cachefiles_mark_inode_in_use __cachefiles_mark_inode_in_use can_use = false if (!(inode->i_flags & S_KERNEL_FILE)) can_use = true \t return false return false // Returns an error but doesn't put dentry After that the following WARNING will be triggered when the backend folder is umounted: ================================================================== BUG: Dentry 000000008ad87947{i=7a,n=Dx_1_1.img} still in use (1) [unmount of ext4 sda] WARNING: CPU: 4 PID: 359261 at fs/dcache.c:1767 umount_check+0x5d/0x70 CPU: 4 PID: 359261 Comm: umount Not tainted 6.6.0-dirty #25 RIP: 0010:umount_check+0x5d/0x70 Call Trace: d_walk+0xda/0x2b0 do_one_tree+0x20/0x40 shrink_dcache_for_umount+0x2c/0x90 generic_shutdown_super+0x20/0x160 kill_block_super+0x1a/0x40 ext4_kill_sb+0x22/0x40 deactivate_locked_super+0x35/0x80 cleanup_mnt+0x104/0x160 ================================================================== Whether cachefiles_open_file() returns true or false, the reference count obtained by lookup_positive_unlocked() in cachefiles_look_up_object() should be released. Therefore release that reference count in cachefiles_look_up_object() to fix the above issue and simplify the code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49871", "url": "https://ubuntu.com/security/CVE-2024-49871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: adp5589-keys - fix NULL pointer dereference We register a devm action to call adp5589_clear_config() and then pass the i2c client as argument so that we can call i2c_get_clientdata() in order to get our device object. However, i2c_set_clientdata() is only being set at the end of the probe function which means that we'll get a NULL pointer dereference in case the probe function fails early.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49872", "url": "https://ubuntu.com/security/CVE-2024-49872", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/gup: fix memfd_pin_folios alloc race panic If memfd_pin_folios tries to create a hugetlb page, but someone else already did, then folio gets the value -EEXIST here: folio = memfd_alloc_folio(memfd, start_idx); if (IS_ERR(folio)) { ret = PTR_ERR(folio); if (ret != -EEXIST) goto err; then on the next trip through the \"while start_idx\" loop we panic here: if (folio) { folio_put(folio); To fix, set the folio to NULL on error.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49964", "url": "https://ubuntu.com/security/CVE-2024-49964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix memfd_pin_folios free_huge_pages leak memfd_pin_folios followed by unpin_folios fails to restore free_huge_pages if the pages were not already faulted in, because the folio refcount for pages created by memfd_alloc_folio never goes to 0. memfd_pin_folios needs another folio_put to undo the folio_try_get below: memfd_alloc_folio() alloc_hugetlb_folio_nodemask() dequeue_hugetlb_folio_nodemask() dequeue_hugetlb_folio_node_exact() folio_ref_unfreeze(folio, 1); ; adds 1 refcount folio_try_get() ; adds 1 refcount hugetlb_add_to_page_cache() ; adds 512 refcount (on x86) With the fix, after memfd_pin_folios + unpin_folios, the refcount for the (unfaulted) page is 512, which is correct, as the refcount for a faulted unpinned page is 513.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49873", "url": "https://ubuntu.com/security/CVE-2024-49873", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/filemap: fix filemap_get_folios_contig THP panic Patch series \"memfd-pin huge page fixes\". Fix multiple bugs that occur when using memfd_pin_folios with hugetlb pages and THP. The hugetlb bugs only bite when the page is not yet faulted in when memfd_pin_folios is called. The THP bug bites when the starting offset passed to memfd_pin_folios is not huge page aligned. See the commit messages for details. This patch (of 5): memfd_pin_folios on memory backed by THP panics if the requested start offset is not huge page aligned: BUG: kernel NULL pointer dereference, address: 0000000000000036 RIP: 0010:filemap_get_folios_contig+0xdf/0x290 RSP: 0018:ffffc9002092fbe8 EFLAGS: 00010202 RAX: 0000000000000002 RBX: 0000000000000002 RCX: 0000000000000002 The fault occurs here, because xas_load returns a folio with value 2: filemap_get_folios_contig() for (folio = xas_load(&xas); folio && xas.xa_index <= end; folio = xas_next(&xas)) { ... if (!folio_try_get(folio)) <-- BOOM \"2\" is an xarray sibling entry. We get it because memfd_pin_folios does not round the indices passed to filemap_get_folios_contig to huge page boundaries for THP, so we load from the middle of a huge page range see a sibling. (It does round for hugetlbfs, at the is_file_hugepages test). To fix, if the folio is a sibling, then return the next index as the starting point for the next call to filemap_get_folios_contig.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49977", "url": "https://ubuntu.com/security/CVE-2024-49977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: Fix zero-division error when disabling tc cbs The commit b8c43360f6e4 (\"net: stmmac: No need to calculate speed divider when offload is disabled\") allows the \"port_transmit_rate_kbps\" to be set to a value of 0, which is then passed to the \"div_s64\" function when tc-cbs is disabled. This leads to a zero-division error. When tc-cbs is disabled, the idleslope, sendslope, and credit values the credit values are not required to be configured. Therefore, adding a return statement after setting the txQ mode to DCB when tc-cbs is disabled would prevent a zero-division error.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49978", "url": "https://ubuntu.com/security/CVE-2024-49978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gso: fix udp gso fraglist segmentation after pull from frag_list Detect gso fraglist skbs with corrupted geometry (see below) and pass these to skb_segment instead of skb_segment_list, as the first can segment them correctly. 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 these skbs, breaking these invariants. In extreme cases they pull all data into skb linear. For UDP, this causes a NULL ptr deref in __udpv4_gso_segment_list_csum at udp_hdr(seg->next)->dest. Detect invalid geometry due to pull, by checking head_skb size. Don't just drop, as this may blackhole a destination. Convert to be able to pass to regular skb_segment.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49979", "url": "https://ubuntu.com/security/CVE-2024-49979", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gso: fix tcp fraglist segmentation after pull from frag_list Detect tcp gso fraglist skbs with corrupted geometry (see below) and pass these to skb_segment instead of skb_segment_list, as the first can segment them correctly. 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 these skbs, breaking these invariants. In extreme cases they pull all data into skb linear. For TCP, this causes a NULL ptr deref in __tcpv4_gso_segment_list_csum at tcp_hdr(seg->next). Detect invalid geometry due to pull, by checking head_skb size. Don't just drop, as this may blackhole a destination. Convert to be able to pass to regular skb_segment. Approach and description based on a patch by Willem de Bruijn.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49980", "url": "https://ubuntu.com/security/CVE-2024-49980", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vrf: revert \"vrf: Remove unnecessary RCU-bh critical section\" This reverts commit 504fc6f4f7f681d2a03aa5f68aad549d90eab853. dev_queue_xmit_nit is expected to be called with BH disabled. __dev_queue_xmit has the following: /* Disable soft irqs for various locks below. Also * stops preemption for RCU. */ rcu_read_lock_bh(); VRF must follow this invariant. The referenced commit removed this protection. Which triggered a lockdep warning: \t================================ \tWARNING: inconsistent lock state \t6.11.0 #1 Tainted: G W \t-------------------------------- \tinconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage. \tbtserver/134819 [HC0[0]:SC0[0]:HE1:SE1] takes: \tffff8882da30c118 (rlock-AF_PACKET){+.?.}-{2:2}, at: tpacket_rcv+0x863/0x3b30 \t{IN-SOFTIRQ-W} state was registered at: \t lock_acquire+0x19a/0x4f0 \t _raw_spin_lock+0x27/0x40 \t packet_rcv+0xa33/0x1320 \t __netif_receive_skb_core.constprop.0+0xcb0/0x3a90 \t __netif_receive_skb_list_core+0x2c9/0x890 \t netif_receive_skb_list_internal+0x610/0xcc0 [...] \tother info that might help us debug this: \t Possible unsafe locking scenario: \t CPU0 \t ---- \t lock(rlock-AF_PACKET); \t \t lock(rlock-AF_PACKET); \t *** DEADLOCK *** \tCall Trace: \t \t dump_stack_lvl+0x73/0xa0 \t mark_lock+0x102e/0x16b0 \t __lock_acquire+0x9ae/0x6170 \t lock_acquire+0x19a/0x4f0 \t _raw_spin_lock+0x27/0x40 \t tpacket_rcv+0x863/0x3b30 \t dev_queue_xmit_nit+0x709/0xa40 \t vrf_finish_direct+0x26e/0x340 [vrf] \t vrf_l3_out+0x5f4/0xe80 [vrf] \t __ip_local_out+0x51e/0x7a0 [...]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49981", "url": "https://ubuntu.com/security/CVE-2024-49981", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: venus: fix use after free bug in venus_remove due to race condition in venus_probe, core->work is bound with venus_sys_error_handler, which is used to handle error. The code use core->sys_err_done to make sync work. The core->work is started in venus_event_notify. If we call venus_remove, there might be an unfished work. The possible sequence is as follows: CPU0 CPU1 |venus_sys_error_handler venus_remove | hfi_destroy\t \t\t | venus_hfi_destroy\t | kfree(hdev);\t | |hfi_reinit \t\t\t\t\t |venus_hfi_queues_reinit |//use hdev Fix it by canceling the work in venus_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49956", "url": "https://ubuntu.com/security/CVE-2024-49956", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: fix double destroy_workqueue error When gfs2_fill_super() fails, destroy_workqueue() is called within gfs2_gl_hash_clear(), and the subsequent code path calls destroy_workqueue() on the same work queue again. This issue can be fixed by setting the work queue pointer to NULL after the first destroy_workqueue() call and checking for a NULL pointer before attempting to destroy the work queue again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50176", "url": "https://ubuntu.com/security/CVE-2024-50176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: k3-r5: Fix error handling when power-up failed By simply bailing out, the driver was violating its rule and internal assumptions that either both or no rproc should be initialized. E.g., this could cause the first core to be available but not the second one, leading to crashes on its shutdown later on while trying to dereference that second instance.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49982", "url": "https://ubuntu.com/security/CVE-2024-49982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: aoe: fix the potential use-after-free problem in more places For fixing CVE-2023-6270, f98364e92662 (\"aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts\") makes tx() calling dev_put() instead of doing in aoecmd_cfg_pkts(). It avoids that the tx() runs into use-after-free. Then Nicolai Stange found more places in aoe have potential use-after-free problem with tx(). e.g. revalidate(), aoecmd_ata_rw(), resend(), probe() and aoecmd_cfg_rsp(). Those functions also use aoenet_xmit() to push packet to tx queue. So they should also use dev_hold() to increase the refcnt of skb->dev. On the other hand, moving dev_put() to tx() causes that the refcnt of skb->dev be reduced to a negative value, because corresponding dev_hold() are not called in revalidate(), aoecmd_ata_rw(), resend(), probe(), and aoecmd_cfg_rsp(). This patch fixed this issue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49874", "url": "https://ubuntu.com/security/CVE-2024-49874", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: svc: Fix use after free vulnerability in svc_i3c_master Driver Due to Race Condition In the svc_i3c_master_probe function, &master->hj_work is bound with svc_i3c_master_hj_work, &master->ibi_work is bound with svc_i3c_master_ibi_work. And svc_i3c_master_ibi_work can start the hj_work, svc_i3c_master_irq_handler can start the ibi_work. If we remove the module which will call svc_i3c_master_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | svc_i3c_master_hj_work svc_i3c_master_remove | i3c_master_unregister(&master->base)| device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in svc_i3c_master_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49875", "url": "https://ubuntu.com/security/CVE-2024-49875", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: map the EBADMSG to nfserr_io to avoid warning Ext4 will throw -EBADMSG through ext4_readdir when a checksum error occurs, resulting in the following WARNING. Fix it by mapping EBADMSG to nfserr_io. nfsd_buffered_readdir iterate_dir // -EBADMSG -74 ext4_readdir // .iterate_shared ext4_dx_readdir ext4_htree_fill_tree htree_dirblock_to_tree ext4_read_dirblock __ext4_read_dirblock ext4_dirblock_csum_verify warn_no_space_for_csum __warn_no_space_for_csum return ERR_PTR(-EFSBADCRC) // -EBADMSG -74 nfserrno // WARNING [ 161.115610] ------------[ cut here ]------------ [ 161.116465] nfsd: non-standard errno: -74 [ 161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0 [ 161.118596] Modules linked in: [ 161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138 [ 161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qe mu.org 04/01/2014 [ 161.123601] RIP: 0010:nfserrno+0x9d/0xd0 [ 161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6 05 ce 2b 61 03 01 e8 99 20 d8 00 <0f> 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33 [ 161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286 [ 161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a [ 161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827 [ 161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021 [ 161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8 [ 161.135244] FS: 0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000 [ 161.136695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0 [ 161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 161.141519] PKRU: 55555554 [ 161.142076] Call Trace: [ 161.142575] ? __warn+0x9b/0x140 [ 161.143229] ? nfserrno+0x9d/0xd0 [ 161.143872] ? report_bug+0x125/0x150 [ 161.144595] ? handle_bug+0x41/0x90 [ 161.145284] ? exc_invalid_op+0x14/0x70 [ 161.146009] ? asm_exc_invalid_op+0x12/0x20 [ 161.146816] ? nfserrno+0x9d/0xd0 [ 161.147487] nfsd_buffered_readdir+0x28b/0x2b0 [ 161.148333] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.149258] ? nfsd_buffered_filldir+0xf0/0xf0 [ 161.150093] ? wait_for_concurrent_writes+0x170/0x170 [ 161.151004] ? generic_file_llseek_size+0x48/0x160 [ 161.151895] nfsd_readdir+0x132/0x190 [ 161.152606] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.153516] ? nfsd_unlink+0x380/0x380 [ 161.154256] ? override_creds+0x45/0x60 [ 161.155006] nfsd4_encode_readdir+0x21a/0x3d0 [ 161.155850] ? nfsd4_encode_readlink+0x210/0x210 [ 161.156731] ? write_bytes_to_xdr_buf+0x97/0xe0 [ 161.157598] ? __write_bytes_to_xdr_buf+0xd0/0xd0 [ 161.158494] ? lock_downgrade+0x90/0x90 [ 161.159232] ? nfs4svc_decode_voidarg+0x10/0x10 [ 161.160092] nfsd4_encode_operation+0x15a/0x440 [ 161.160959] nfsd4_proc_compound+0x718/0xe90 [ 161.161818] nfsd_dispatch+0x18e/0x2c0 [ 161.162586] svc_process_common+0x786/0xc50 [ 161.163403] ? nfsd_svc+0x380/0x380 [ 161.164137] ? svc_printk+0x160/0x160 [ 161.164846] ? svc_xprt_do_enqueue.part.0+0x365/0x380 [ 161.165808] ? nfsd_svc+0x380/0x380 [ 161.166523] ? rcu_is_watching+0x23/0x40 [ 161.167309] svc_process+0x1a5/0x200 [ 161.168019] nfsd+0x1f5/0x380 [ 161.168663] ? nfsd_shutdown_threads+0x260/0x260 [ 161.169554] kthread+0x1c4/0x210 [ 161.170224] ? kthread_insert_work_sanity_check+0x80/0x80 [ 161.171246] ret_from_fork+0x1f/0x30", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50013", "url": "https://ubuntu.com/security/CVE-2024-50013", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix memory leak in exfat_load_bitmap() If the first directory entry in the root directory is not a bitmap directory entry, 'bh' will not be released and reassigned, which will cause a memory leak.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49876", "url": "https://ubuntu.com/security/CVE-2024-49876", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: fix UAF around queue destruction We currently do stuff like queuing the final destruction step on a random system wq, which will outlive the driver instance. With bad timing we can teardown the driver with one or more work workqueue still being alive leading to various UAF splats. Add a fini step to ensure user queues are properly torn down. At this point GuC should already be nuked so queue itself should no longer be referenced from hw pov. v2 (Matt B) - Looks much safer to use a waitqueue and then just wait for the xa_array to become empty before triggering the drain. (cherry picked from commit 861108666cc0e999cffeab6aff17b662e68774e3)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49877", "url": "https://ubuntu.com/security/CVE-2024-49877", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate When doing cleanup, if flags without OCFS2_BH_READAHEAD, it may trigger NULL pointer dereference in the following ocfs2_set_buffer_uptodate() if bh is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49957", "url": "https://ubuntu.com/security/CVE-2024-49957", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix null-ptr-deref when journal load failed. During the mounting process, if journal_reset() fails because of too short journal, then lead to jbd2_journal_load() fails with NULL j_sb_buffer. Subsequently, ocfs2_journal_shutdown() calls jbd2_journal_flush()->jbd2_cleanup_journal_tail()-> __jbd2_update_log_tail()->jbd2_journal_update_sb_log_tail() ->lock_buffer(journal->j_sb_buffer), resulting in a null-pointer dereference error. To resolve this issue, we should check the JBD2_LOADED flag to ensure the journal was properly loaded. Additionally, use journal instead of osb->journal directly to simplify the code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49965", "url": "https://ubuntu.com/security/CVE-2024-49965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove unreasonable unlock in ocfs2_read_blocks Patch series \"Misc fixes for ocfs2_read_blocks\", v5. This series contains 2 fixes for ocfs2_read_blocks(). The first patch fix the issue reported by syzbot, which detects bad unlock balance in ocfs2_read_blocks(). The second patch fixes an issue reported by Heming Zhao when reviewing above fix. This patch (of 2): There was a lock release before exiting, so remove the unreasonable unlock.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49966", "url": "https://ubuntu.com/security/CVE-2024-49966", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: cancel dqi_sync_work before freeing oinfo ocfs2_global_read_info() will initialize and schedule dqi_sync_work at the end, if error occurs after successfully reading global quota, it will trigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled: ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16c This reports that there is an active delayed work when freeing oinfo in error handling, so cancel dqi_sync_work first. BTW, return status instead of -1 when .read_file_info fails.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49958", "url": "https://ubuntu.com/security/CVE-2024-49958", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reserve space for inline xattr before attaching reflink tree One of our customers reported a crash and a corrupted ocfs2 filesystem. The crash was due to the detection of corruption. Upon troubleshooting, the fsck -fn output showed the below corruption [EXTENT_LIST_FREE] Extent list in owner 33080590 claims 230 as the next free chain record, but fsck believes the largest valid value is 227. Clamp the next record value? n The stat output from the debugfs.ocfs2 showed the following corruption where the \"Next Free Rec:\" had overshot the \"Count:\" in the root metadata block. Inode: 33080590 Mode: 0640 Generation: 2619713622 (0x9c25a856) FS Generation: 904309833 (0x35e6ac49) CRC32: 00000000 ECC: 0000 Type: Regular Attr: 0x0 Flags: Valid Dynamic Features: (0x16) HasXattr InlineXattr Refcounted Extended Attributes Block: 0 Extended Attributes Inline Size: 256 User: 0 (root) Group: 0 (root) Size: 281320357888 Links: 1 Clusters: 141738 ctime: 0x66911b56 0x316edcb8 -- Fri Jul 12 06:02:30.829349048 2024 atime: 0x66911d6b 0x7f7a28d -- Fri Jul 12 06:11:23.133669517 2024 mtime: 0x66911b56 0x12ed75d7 -- Fri Jul 12 06:02:30.317552087 2024 dtime: 0x0 -- Wed Dec 31 17:00:00 1969 Refcount Block: 2777346 Last Extblk: 2886943 Orphan Slot: 0 Sub Alloc Slot: 0 Sub Alloc Bit: 14 Tree Depth: 1 Count: 227 Next Free Rec: 230 ## Offset Clusters Block# 0 0 2310 2776351 1 2310 2139 2777375 2 4449 1221 2778399 3 5670 731 2779423 4 6401 566 2780447 ....... .... ....... ....... .... ....... The issue was in the reflink workfow while reserving space for inline xattr. The problematic function is ocfs2_reflink_xattr_inline(). By the time this function is called the reflink tree is already recreated at the destination inode from the source inode. At this point, this function reserves space for inline xattrs at the destination inode without even checking if there is space at the root metadata block. It simply reduces the l_count from 243 to 227 thereby making space of 256 bytes for inline xattr whereas the inode already has extents beyond this index (in this case up to 230), thereby causing corruption. The fix for this is to reserve space for inline metadata at the destination inode before the reflink tree gets recreated. The customer has verified the fix.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49959", "url": "https://ubuntu.com/security/CVE-2024-49959", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail() to recover some journal space. But if an error occurs while executing jbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for free space right away, we try other branches, and if j_committing_transaction is NULL (i.e., the tid is 0), we will get the following complain: ============================================ JBD2: I/O error when updating journal superblock for sdd-8. __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available __jbd2_log_wait_for_space: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Call Trace: add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70 [...] ============================================ So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways. Note that this fix relies on commit 6f6a6fda2945 (\"jbd2: fix ocfs2 corrupt when updating journal superblock fails\") to make jbd2_cleanup_journal_tail return the correct error code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49878", "url": "https://ubuntu.com/security/CVE-2024-49878", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: resource: fix region_intersects() vs add_memory_driver_managed() On a system with CXL memory, the resource tree (/proc/iomem) related to CXL memory may look like something as follows. 490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem) Because drivers/dax/kmem.c calls add_memory_driver_managed() during onlining CXL memory, which makes \"System RAM (kmem)\" a descendant of \"CXL Window X\". This confuses region_intersects(), which expects all \"System RAM\" resources to be at the top level of iomem_resource. This can lead to bugs. For example, when the following command line is executed to write some memory in CXL memory range via /dev/mem, $ dd if=data of=/dev/mem bs=$((1 << 10)) seek=$((0x490000000 >> 10)) count=1 dd: error writing '/dev/mem': Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/s the command fails as expected. However, the error code is wrong. It should be \"Operation not permitted\" instead of \"Bad address\". More seriously, the /dev/mem permission checking in devmem_is_allowed() passes incorrectly. Although the accessing is prevented later because ioremap() isn't allowed to map system RAM, it is a potential security issue. During command executing, the following warning is reported in the kernel log for calling ioremap() on system RAM. ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d Call Trace: memremap+0xcb/0x184 xlate_dev_mem_ptr+0x25/0x2f write_mem+0x94/0xfb vfs_write+0x128/0x26d ksys_write+0xac/0xfe do_syscall_64+0x9a/0xfd entry_SYSCALL_64_after_hwframe+0x4b/0x53 The details of command execution process are as follows. In the above resource tree, \"System RAM\" is a descendant of \"CXL Window 0\" instead of a top level resource. So, region_intersects() will report no System RAM resources in the CXL memory region incorrectly, because it only checks the top level resources. Consequently, devmem_is_allowed() will return 1 (allow access via /dev/mem) for CXL memory region incorrectly. Fortunately, ioremap() doesn't allow to map System RAM and reject the access. So, region_intersects() needs to be fixed to work correctly with the resource tree with \"System RAM\" not at top level as above. To fix it, if we found a unmatched resource in the top level, we will continue to search matched resources in its descendant resources. So, we will not miss any matched resources in resource tree anymore. In the new implementation, an example resource tree |------------- \"CXL Window 0\" ------------| |-- \"System RAM\" --| will behave similar as the following fake resource tree for region_intersects(, IORESOURCE_SYSTEM_RAM, ), |-- \"System RAM\" --||-- \"CXL Window 0a\" --| Where \"CXL Window 0a\" is part of the original \"CXL Window 0\" that isn't covered by \"System RAM\".", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49879", "url": "https://ubuntu.com/security/CVE-2024-49879", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm: omapdrm: Add missing check for alloc_ordered_workqueue As it may return NULL pointer and cause NULL pointer dereference. Add check for the return value of alloc_ordered_workqueue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49880", "url": "https://ubuntu.com/security/CVE-2024-49880", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix off by one issue in alloc_flex_gd() Wesley reported an issue: ================================================================== EXT4-fs (dm-5): resizing filesystem from 7168 to 786432 blocks ------------[ cut here ]------------ kernel BUG at fs/ext4/resize.c:324! CPU: 9 UID: 0 PID: 3576 Comm: resize2fs Not tainted 6.11.0+ #27 RIP: 0010:ext4_resize_fs+0x1212/0x12d0 Call Trace: __ext4_ioctl+0x4e0/0x1800 ext4_ioctl+0x12/0x20 __x64_sys_ioctl+0x99/0xd0 x64_sys_call+0x1206/0x20d0 do_syscall_64+0x72/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e ================================================================== While reviewing the patch, Honza found that when adjusting resize_bg in alloc_flex_gd(), it was possible for flex_gd->resize_bg to be bigger than flexbg_size. The reproduction of the problem requires the following: o_group = flexbg_size * 2 * n; o_size = (o_group + 1) * group_size; n_group: [o_group + flexbg_size, o_group + flexbg_size * 2) o_size = (n_group + 1) * group_size; Take n=0,flexbg_size=16 as an example: last:15 |o---------------|--------------n-| o_group:0 resize to n_group:30 The corresponding reproducer is: img=test.img rm -f $img truncate -s 600M $img mkfs.ext4 -F $img -b 1024 -G 16 8M dev=`losetup -f --show $img` mkdir -p /tmp/test mount $dev /tmp/test resize2fs $dev 248M Delete the problematic plus 1 to fix the issue, and add a WARN_ON_ONCE() to prevent the issue from happening again. [ Note: another reproucer which this commit fixes is: img=test.img rm -f $img truncate -s 25MiB $img mkfs.ext4 -b 4096 -E nodiscard,lazy_itable_init=0,lazy_journal_init=0 $img truncate -s 3GiB $img dev=`losetup -f --show $img` mkdir -p /tmp/test mount $dev /tmp/test resize2fs $dev 3G umount $dev losetup -d $dev -- TYT ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49881", "url": "https://ubuntu.com/security/CVE-2024-49881", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: update orig_path in ext4_find_extent() In ext4_find_extent(), if the path is not big enough, we free it and set *orig_path to NULL. But after reallocating and successfully initializing the path, we don't update *orig_path, in which case the caller gets a valid path but a NULL ppath, and this may cause a NULL pointer dereference or a path memory leak. For example: ext4_split_extent path = *ppath = 2000 ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path = 2000); *orig_path = path = NULL; path = kcalloc() = 3000 ext4_split_extent_at(*ppath = NULL) path = *ppath; ex = path[depth].p_ext; // NULL pointer dereference! ================================================================== BUG: kernel NULL pointer dereference, address: 0000000000000010 CPU: 6 UID: 0 PID: 576 Comm: fsstress Not tainted 6.11.0-rc2-dirty #847 RIP: 0010:ext4_split_extent_at+0x6d/0x560 Call Trace: ext4_split_extent.isra.0+0xcb/0x1b0 ext4_ext_convert_to_initialized+0x168/0x6c0 ext4_ext_handle_unwritten_extents+0x325/0x4d0 ext4_ext_map_blocks+0x520/0xdb0 ext4_map_blocks+0x2b0/0x690 ext4_iomap_begin+0x20e/0x2c0 [...] ================================================================== Therefore, *orig_path is updated when the extent lookup succeeds, so that the caller can safely use path or *ppath.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50014", "url": "https://ubuntu.com/security/CVE-2024-50014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix access to uninitialised lock in fc replay path The following kernel trace can be triggered with fstest generic/629 when executed against a filesystem with fast-commit feature enabled: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x66/0x90 register_lock_class+0x759/0x7d0 __lock_acquire+0x85/0x2630 ? __find_get_block+0xb4/0x380 lock_acquire+0xd1/0x2d0 ? __ext4_journal_get_write_access+0xd5/0x160 _raw_spin_lock+0x33/0x40 ? __ext4_journal_get_write_access+0xd5/0x160 __ext4_journal_get_write_access+0xd5/0x160 ext4_reserve_inode_write+0x61/0xb0 __ext4_mark_inode_dirty+0x79/0x270 ? ext4_ext_replay_set_iblocks+0x2f8/0x450 ext4_ext_replay_set_iblocks+0x330/0x450 ext4_fc_replay+0x14c8/0x1540 ? jread+0x88/0x2e0 ? rcu_is_watching+0x11/0x40 do_one_pass+0x447/0xd00 jbd2_journal_recover+0x139/0x1b0 jbd2_journal_load+0x96/0x390 ext4_load_and_init_journal+0x253/0xd40 ext4_fill_super+0x2cc6/0x3180 ... In the replay path there's an attempt to lock sbi->s_bdev_wb_lock in function ext4_check_bdev_write_error(). Unfortunately, at this point this spinlock has not been initialized yet. Moving it's initialization to an earlier point in __ext4_fill_super() fixes this splat.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49960", "url": "https://ubuntu.com/security/CVE-2024-49960", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix timer use-after-free on failed mount Syzbot has found an ODEBUG bug in ext4_fill_super The del_timer_sync function cancels the s_err_report timer, which reminds about filesystem errors daily. We should guarantee the timer is no longer active before kfree(sbi). When filesystem mounting fails, the flow goes to failed_mount3, where an error occurs when ext4_stop_mmpd is called, causing a read I/O failure. This triggers the ext4_handle_error function that ultimately re-arms the timer, leaving the s_err_report timer active before kfree(sbi) is called. Fix the issue by canceling the s_err_report timer after calling ext4_stop_mmpd.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49882", "url": "https://ubuntu.com/security/CVE-2024-49882", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix double brelse() the buffer of the extents path In ext4_ext_try_to_merge_up(), set path[1].p_bh to NULL after it has been released, otherwise it may be released twice. An example of what triggers this is as follows: split2 map split1 |--------|-------|--------| ext4_ext_map_blocks ext4_ext_handle_unwritten_extents ext4_split_convert_extents // path->p_depth == 0 ext4_split_extent // 1. do split1 ext4_split_extent_at |ext4_ext_insert_extent | ext4_ext_create_new_leaf | ext4_ext_grow_indepth | le16_add_cpu(&neh->eh_depth, 1) | ext4_find_extent | // return -ENOMEM |// get error and try zeroout |path = ext4_find_extent | path->p_depth = 1 |ext4_ext_try_to_merge | ext4_ext_try_to_merge_up | path->p_depth = 0 | brelse(path[1].p_bh) ---> not set to NULL here |// zeroout success // 2. update path ext4_find_extent // 3. do split2 ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth le16_add_cpu(&neh->eh_depth, 1) ext4_find_extent path[0].p_bh = NULL; path->p_depth = 1 read_extent_tree_block ---> return err // path[1].p_bh is still the old value ext4_free_ext_path ext4_ext_drop_refs // path->p_depth == 1 brelse(path[1].p_bh) ---> brelse a buffer twice Finally got the following WARRNING when removing the buffer from lru: ============================================ VFS: brelse: Trying to free free buffer WARNING: CPU: 2 PID: 72 at fs/buffer.c:1241 __brelse+0x58/0x90 CPU: 2 PID: 72 Comm: kworker/u19:1 Not tainted 6.9.0-dirty #716 RIP: 0010:__brelse+0x58/0x90 Call Trace: __find_get_block+0x6e7/0x810 bdev_getblk+0x2b/0x480 __ext4_get_inode_loc+0x48a/0x1240 ext4_get_inode_loc+0xb2/0x150 ext4_reserve_inode_write+0xb7/0x230 __ext4_mark_inode_dirty+0x144/0x6a0 ext4_ext_insert_extent+0x9c8/0x3230 ext4_ext_map_blocks+0xf45/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] ============================================", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49883", "url": "https://ubuntu.com/security/CVE-2024-49883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: aovid use-after-free in ext4_ext_insert_extent() As Ojaswin mentioned in Link, in ext4_ext_insert_extent(), if the path is reallocated in ext4_ext_create_new_leaf(), we'll use the stale path and cause UAF. Below is a sample trace with dummy values: ext4_ext_insert_extent path = *ppath = 2000 ext4_ext_create_new_leaf(ppath) ext4_find_extent(ppath) path = *ppath = 2000 if (depth > path[0].p_maxdepth) kfree(path = 2000); *ppath = path = NULL; path = kcalloc() = 3000 *ppath = 3000; return path; /* here path is still 2000, UAF! */ eh = path[depth].p_hdr ================================================================== BUG: KASAN: slab-use-after-free in ext4_ext_insert_extent+0x26d4/0x3330 Read of size 8 at addr ffff8881027bf7d0 by task kworker/u36:1/179 CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 Not tainted 6.11.0-rc2-dirty #866 Call Trace: ext4_ext_insert_extent+0x26d4/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 [...] Allocated by task 179: ext4_find_extent+0x81c/0x1f70 ext4_ext_map_blocks+0x146/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...] Freed by task 179: kfree+0xcb/0x240 ext4_find_extent+0x7c0/0x1f70 ext4_ext_insert_extent+0xa26/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...] ================================================================== So use *ppath to update the path to avoid the above problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49983", "url": "https://ubuntu.com/security/CVE-2024-49983", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-free When calling ext4_force_split_extent_at() in ext4_ext_replay_update_ex(), the 'ppath' is updated but it is the 'path' that is freed, thus potentially triggering a double-free in the following process: ext4_ext_replay_update_ex ppath = path ext4_force_split_extent_at(&ppath) ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path) ---> path First freed *orig_path = path = NULL ---> null ppath kfree(path) ---> path double-free !!! So drop the unnecessary ppath and use path directly to avoid this problem. And use ext4_find_extent() directly to update path, avoiding unnecessary memory allocation and freeing. Also, propagate the error returned by ext4_find_extent() instead of using strange error codes.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50015", "url": "https://ubuntu.com/security/CVE-2024-50015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: dax: fix overflowing extents beyond inode size when partially writing The dax_iomap_rw() does two things in each iteration: map written blocks and copy user data to blocks. If the process is killed by user(See signal handling in dax_iomap_iter()), the copied data will be returned and added on inode size, which means that the length of written extents may exceed the inode size, then fsck will fail. An example is given as: dd if=/dev/urandom of=file bs=4M count=1 dax_iomap_rw iomap_iter // round 1 ext4_iomap_begin ext4_iomap_alloc // allocate 0~2M extents(written flag) dax_iomap_iter // copy 2M data iomap_iter // round 2 iomap_iter_advance iter->pos += iter->processed // iter->pos = 2M ext4_iomap_begin ext4_iomap_alloc // allocate 2~4M extents(written flag) dax_iomap_iter fatal_signal_pending done = iter->pos - iocb->ki_pos // done = 2M ext4_handle_inode_extension ext4_update_inode_size // inode size = 2M fsck reports: Inode 13, i_size is 2097152, should be 4194304. Fix? Fix the problem by truncating extents if the written length is smaller than expected.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49884", "url": "https://ubuntu.com/security/CVE-2024-49884", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix slab-use-after-free in ext4_split_extent_at() We hit the following use-after-free: ================================================================== BUG: KASAN: slab-use-after-free in ext4_split_extent_at+0xba8/0xcc0 Read of size 2 at addr ffff88810548ed08 by task kworker/u20:0/40 CPU: 0 PID: 40 Comm: kworker/u20:0 Not tainted 6.9.0-dirty #724 Call Trace: kasan_report+0x93/0xc0 ext4_split_extent_at+0xba8/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] Allocated by task 40: __kmalloc_noprof+0x1ac/0x480 ext4_find_extent+0xf3b/0x1e70 ext4_ext_map_blocks+0x188/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] Freed by task 40: kfree+0xf1/0x2b0 ext4_find_extent+0xa71/0x1e70 ext4_ext_insert_extent+0xa22/0x3260 ext4_split_extent_at+0x3ef/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] ================================================================== The flow of issue triggering is as follows: ext4_split_extent_at path = *ppath ext4_ext_insert_extent(ppath) ext4_ext_create_new_leaf(ppath) ext4_find_extent(orig_path) path = *orig_path read_extent_tree_block // return -ENOMEM or -EIO ext4_free_ext_path(path) kfree(path) *orig_path = NULL a. If err is -ENOMEM: ext4_ext_dirty(path + path->p_depth) // path use-after-free !!! b. If err is -EIO and we have EXT_DEBUG defined: ext4_ext_show_leaf(path) eh = path[depth].p_hdr // path also use-after-free !!! So when trying to zeroout or fix the extent length, call ext4_find_extent() to update the path. In addition we use *ppath directly as an ext4_ext_show_leaf() input to avoid possible use-after-free when EXT_DEBUG is defined, and to avoid unnecessary path updates.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49885", "url": "https://ubuntu.com/security/CVE-2024-49885", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm, slub: avoid zeroing kmalloc redzone Since commit 946fa0dbf2d8 (\"mm/slub: extend redzone check to extra allocated kmalloc space than requested\"), setting orig_size treats the wasted space (object_size - orig_size) as a redzone. However with init_on_free=1 we clear the full object->size, including the redzone. Additionally we clear the object metadata, including the stored orig_size, making it zero, which makes check_object() treat the whole object as a redzone. These issues lead to the following BUG report with \"slub_debug=FUZ init_on_free=1\": [ 0.000000] ============================================================================= [ 0.000000] BUG kmalloc-8 (Not tainted): kmalloc Redzone overwritten [ 0.000000] ----------------------------------------------------------------------------- [ 0.000000] [ 0.000000] 0xffff000010032858-0xffff00001003285f @offset=2136. First byte 0x0 instead of 0xcc [ 0.000000] FIX kmalloc-8: Restoring kmalloc Redzone 0xffff000010032858-0xffff00001003285f=0xcc [ 0.000000] Slab 0xfffffdffc0400c80 objects=36 used=23 fp=0xffff000010032a18 flags=0x3fffe0000000200(workingset|node=0|zone=0|lastcpupid=0x1ffff) [ 0.000000] Object 0xffff000010032858 @offset=2136 fp=0xffff0000100328c8 [ 0.000000] [ 0.000000] Redzone ffff000010032850: cc cc cc cc cc cc cc cc ........ [ 0.000000] Object ffff000010032858: cc cc cc cc cc cc cc cc ........ [ 0.000000] Redzone ffff000010032860: cc cc cc cc cc cc cc cc ........ [ 0.000000] Padding ffff0000100328b4: 00 00 00 00 00 00 00 00 00 00 00 00 ............ [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.11.0-rc3-next-20240814-00004-g61844c55c3f4 #144 [ 0.000000] Hardware name: NXP i.MX95 19X19 board (DT) [ 0.000000] Call trace: [ 0.000000] dump_backtrace+0x90/0xe8 [ 0.000000] show_stack+0x18/0x24 [ 0.000000] dump_stack_lvl+0x74/0x8c [ 0.000000] dump_stack+0x18/0x24 [ 0.000000] print_trailer+0x150/0x218 [ 0.000000] check_object+0xe4/0x454 [ 0.000000] free_to_partial_list+0x2f8/0x5ec To address the issue, use orig_size to clear the used area. And restore the value of orig_size after clear the remaining area. When CONFIG_SLUB_DEBUG not defined, (get_orig_size()' directly returns s->object_size. So when using memset to init the area, the size can simply be orig_size, as orig_size returns object_size when CONFIG_SLUB_DEBUG not enabled. And orig_size can never be bigger than object_size.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49961", "url": "https://ubuntu.com/security/CVE-2024-49961", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: ar0521: Use cansleep version of gpiod_set_value() If we use GPIO reset from I2C port expander, we must use *_cansleep() variant of GPIO functions. This was not done in ar0521_power_on()/ar0521_power_off() functions. Let's fix that. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 11 at drivers/gpio/gpiolib.c:3496 gpiod_set_value+0x74/0x7c Modules linked in: CPU: 0 PID: 11 Comm: kworker/u16:0 Not tainted 6.10.0 #53 Hardware name: Diasom DS-RK3568-SOM-EVB (DT) Workqueue: events_unbound deferred_probe_work_func pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : gpiod_set_value+0x74/0x7c lr : ar0521_power_on+0xcc/0x290 sp : ffffff8001d7ab70 x29: ffffff8001d7ab70 x28: ffffff80027dcc90 x27: ffffff8003c82000 x26: ffffff8003ca9250 x25: ffffffc080a39c60 x24: ffffff8003ca9088 x23: ffffff8002402720 x22: ffffff8003ca9080 x21: ffffff8003ca9088 x20: 0000000000000000 x19: ffffff8001eb2a00 x18: ffffff80efeeac80 x17: 756d2d6332692f30 x16: 0000000000000000 x15: 0000000000000000 x14: ffffff8001d91d40 x13: 0000000000000016 x12: ffffffc080e98930 x11: ffffff8001eb2880 x10: 0000000000000890 x9 : ffffff8001d7a9f0 x8 : ffffff8001d92570 x7 : ffffff80efeeac80 x6 : 000000003fc6e780 x5 : ffffff8001d91c80 x4 : 0000000000000002 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000001 Call trace: gpiod_set_value+0x74/0x7c ar0521_power_on+0xcc/0x290 ...", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49985", "url": "https://ubuntu.com/security/CVE-2024-49985", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume In case there is any sort of clock controller attached to this I2C bus controller, for example Versaclock or even an AIC32x4 I2C codec, then an I2C transfer triggered from the clock controller clk_ops .prepare callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex. This is because the clock controller first grabs the prepare_lock mutex and then performs the prepare operation, including its I2C access. The I2C access resumes this I2C bus controller via .runtime_resume callback, which calls clk_prepare_enable(), which attempts to grab the prepare_lock mutex again and deadlocks. Since the clock are already prepared since probe() and unprepared in remove(), use simple clk_enable()/clk_disable() calls to enable and disable the clock on runtime suspend and resume, to avoid hitting the prepare_lock mutex.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49886", "url": "https://ubuntu.com/security/CVE-2024-49886", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bug Attaching SST PCI device to VM causes \"BUG: KASAN: slab-out-of-bounds\". kasan report: [ 19.411889] ================================================================== [ 19.413702] BUG: KASAN: slab-out-of-bounds in _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.415634] Read of size 8 at addr ffff888829e65200 by task cpuhp/16/113 [ 19.417368] [ 19.418627] CPU: 16 PID: 113 Comm: cpuhp/16 Tainted: G E 6.9.0 #10 [ 19.420435] Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.20192059.B64.2207280713 07/28/2022 [ 19.422687] Call Trace: [ 19.424091] [ 19.425448] dump_stack_lvl+0x5d/0x80 [ 19.426963] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.428694] print_report+0x19d/0x52e [ 19.430206] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 19.431837] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.433539] kasan_report+0xf0/0x170 [ 19.435019] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.436709] _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.438379] ? __pfx_sched_clock_cpu+0x10/0x10 [ 19.439910] isst_if_cpu_online+0x406/0x58f [isst_if_common] [ 19.441573] ? __pfx_isst_if_cpu_online+0x10/0x10 [isst_if_common] [ 19.443263] ? ttwu_queue_wakelist+0x2c1/0x360 [ 19.444797] cpuhp_invoke_callback+0x221/0xec0 [ 19.446337] cpuhp_thread_fun+0x21b/0x610 [ 19.447814] ? __pfx_cpuhp_thread_fun+0x10/0x10 [ 19.449354] smpboot_thread_fn+0x2e7/0x6e0 [ 19.450859] ? __pfx_smpboot_thread_fn+0x10/0x10 [ 19.452405] kthread+0x29c/0x350 [ 19.453817] ? __pfx_kthread+0x10/0x10 [ 19.455253] ret_from_fork+0x31/0x70 [ 19.456685] ? __pfx_kthread+0x10/0x10 [ 19.458114] ret_from_fork_asm+0x1a/0x30 [ 19.459573] [ 19.460853] [ 19.462055] Allocated by task 1198: [ 19.463410] kasan_save_stack+0x30/0x50 [ 19.464788] kasan_save_track+0x14/0x30 [ 19.466139] __kasan_kmalloc+0xaa/0xb0 [ 19.467465] __kmalloc+0x1cd/0x470 [ 19.468748] isst_if_cdev_register+0x1da/0x350 [isst_if_common] [ 19.470233] isst_if_mbox_init+0x108/0xff0 [isst_if_mbox_msr] [ 19.471670] do_one_initcall+0xa4/0x380 [ 19.472903] do_init_module+0x238/0x760 [ 19.474105] load_module+0x5239/0x6f00 [ 19.475285] init_module_from_file+0xd1/0x130 [ 19.476506] idempotent_init_module+0x23b/0x650 [ 19.477725] __x64_sys_finit_module+0xbe/0x130 [ 19.476506] idempotent_init_module+0x23b/0x650 [ 19.477725] __x64_sys_finit_module+0xbe/0x130 [ 19.478920] do_syscall_64+0x82/0x160 [ 19.480036] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 19.481292] [ 19.482205] The buggy address belongs to the object at ffff888829e65000 which belongs to the cache kmalloc-512 of size 512 [ 19.484818] The buggy address is located 0 bytes to the right of allocated 512-byte region [ffff888829e65000, ffff888829e65200) [ 19.487447] [ 19.488328] The buggy address belongs to the physical page: [ 19.489569] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888829e60c00 pfn:0x829e60 [ 19.491140] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [ 19.492466] anon flags: 0x57ffffc0000840(slab|head|node=1|zone=2|lastcpupid=0x1fffff) [ 19.493914] page_type: 0xffffffff() [ 19.494988] raw: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [ 19.496451] raw: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [ 19.497906] head: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [ 19.499379] head: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [ 19.500844] head: 0057ffffc0000003 ffffea0020a79801 ffffea0020a79848 00000000ffffffff [ 19.502316] head: 0000000800000000 0000000000000000 00000000ffffffff 0000000000000000 [ 19.503784] page dumped because: k ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49986", "url": "https://ubuntu.com/security/CVE-2024-49986", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: x86-android-tablets: Fix use after free on platform_device_register() errors x86_android_tablet_remove() frees the pdevs[] array, so it should not be used after calling x86_android_tablet_remove(). When platform_device_register() fails, store the pdevs[x] PTR_ERR() value into the local ret variable before calling x86_android_tablet_remove() to avoid using pdevs[] after it has been freed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49887", "url": "https://ubuntu.com/security/CVE-2024-49887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to don't panic system for no free segment fault injection f2fs: fix to don't panic system for no free segment fault injection syzbot reports a f2fs bug as below: F2FS-fs (loop0): inject no free segment in get_new_segment of __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3167 F2FS-fs (loop0): Stopped filesystem due to reason: 7 ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2748! CPU: 0 UID: 0 PID: 5109 Comm: syz-executor304 Not tainted 6.11.0-rc6-syzkaller-00363-g89f5e14d05b4 #0 RIP: 0010:get_new_segment fs/f2fs/segment.c:2748 [inline] RIP: 0010:new_curseg+0x1f61/0x1f70 fs/f2fs/segment.c:2836 Call Trace: __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3167 f2fs_allocate_new_section fs/f2fs/segment.c:3181 [inline] f2fs_allocate_pinning_section+0xfa/0x4e0 fs/f2fs/segment.c:3195 f2fs_expand_inode_data+0x5d6/0xbb0 fs/f2fs/file.c:1799 f2fs_fallocate+0x448/0x960 fs/f2fs/file.c:1903 vfs_fallocate+0x553/0x6c0 fs/open.c:334 do_vfs_ioctl+0x2592/0x2e50 fs/ioctl.c:886 __do_sys_ioctl fs/ioctl.c:905 [inline] __se_sys_ioctl+0x81/0x170 fs/ioctl.c:893 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: 0010:get_new_segment fs/f2fs/segment.c:2748 [inline] RIP: 0010:new_curseg+0x1f61/0x1f70 fs/f2fs/segment.c:2836 The root cause is when we inject no free segment fault into f2fs, we should not panic system, fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49888", "url": "https://ubuntu.com/security/CVE-2024-49888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix a sdiv overflow issue Zac Ecob reported a problem where a bpf program may cause kernel crash due to the following error: Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI The failure is due to the below signed divide: LLONG_MIN/-1 where LLONG_MIN equals to -9,223,372,036,854,775,808. LLONG_MIN/-1 is supposed to give a positive number 9,223,372,036,854,775,808, but it is impossible since for 64-bit system, the maximum positive number is 9,223,372,036,854,775,807. On x86_64, LLONG_MIN/-1 will cause a kernel exception. On arm64, the result for LLONG_MIN/-1 is LLONG_MIN. Further investigation found all the following sdiv/smod cases may trigger an exception when bpf program is running on x86_64 platform: - LLONG_MIN/-1 for 64bit operation - INT_MIN/-1 for 32bit operation - LLONG_MIN%-1 for 64bit operation - INT_MIN%-1 for 32bit operation where -1 can be an immediate or in a register. On arm64, there are no exceptions: - LLONG_MIN/-1 = LLONG_MIN - INT_MIN/-1 = INT_MIN - LLONG_MIN%-1 = 0 - INT_MIN%-1 = 0 where -1 can be an immediate or in a register. Insn patching is needed to handle the above cases and the patched codes produced results aligned with above arm64 result. The below are pseudo codes to handle sdiv/smod exceptions including both divisor -1 and divisor 0 and the divisor is stored in a register. sdiv: tmp = rX tmp += 1 /* [-1, 0] -> [0, 1] if tmp >(unsigned) 1 goto L2 if tmp == 0 goto L1 rY = 0 L1: rY = -rY; goto L3 L2: rY /= rX L3: smod: tmp = rX tmp += 1 /* [-1, 0] -> [0, 1] if tmp >(unsigned) 1 goto L1 if tmp == 1 (is64 ? goto L2 : goto L3) rY = 0; goto L2 L1: rY %= rX L2: goto L4 // only when !is64 L3: wY = wY // only when !is64 L4: [1] https://lore.kernel.org/bpf/tPJLTEh7S_DxFEqAI2Ji5MBSoZVg7_G-Py2iaZpAaWtM961fFTWtsnlzwvTbzBzaUzwQAoNATXKUlt0LZOFgnDcIyKCswAnAGdUF3LBrhGQ=@protonmail.com/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49987", "url": "https://ubuntu.com/security/CVE-2024-49987", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpftool: Fix undefined behavior in qsort(NULL, 0, ...) When netfilter has no entry to display, qsort is called with qsort(NULL, 0, ...). This results in undefined behavior, as UBSan reports: net.c:827:2: runtime error: null pointer passed as argument 1, which is declared to never be null Although the C standard does not explicitly state whether calling qsort with a NULL pointer when the size is 0 constitutes undefined behavior, Section 7.1.4 of the C standard (Use of library functions) mentions: \"Each of the following statements applies unless explicitly stated otherwise in the detailed descriptions that follow: If an argument to a function has an invalid value (such as a value outside the domain of the function, or a pointer outside the address space of the program, or a null pointer, or a pointer to non-modifiable storage when the corresponding parameter is not const-qualified) or a type (after promotion) not expected by a function with variable number of arguments, the behavior is undefined.\" To avoid this, add an early return when nf_link_info is NULL to prevent calling qsort with a NULL pointer.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50006", "url": "https://ubuntu.com/security/CVE-2024-50006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix i_data_sem unlock order in ext4_ind_migrate() Fuzzing reports a possible deadlock in jbd2_log_wait_commit. This issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to require synchronous updates because the file descriptor is opened with O_SYNC. This can lead to the jbd2_journal_stop() function calling jbd2_might_wait_for_commit(), potentially causing a deadlock if the EXT4_IOC_MIGRATE call races with a write(2) system call. This problem only arises when CONFIG_PROVE_LOCKING is enabled. In this case, the jbd2_might_wait_for_commit macro locks jbd2_handle in the jbd2_journal_stop function while i_data_sem is locked. This triggers lockdep because the jbd2_journal_start function might also lock the same jbd2_handle simultaneously. Found by Linux Verification Center (linuxtesting.org) with syzkaller. Rule: add", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49889", "url": "https://ubuntu.com/security/CVE-2024-49889", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid use-after-free in ext4_ext_show_leaf() In ext4_find_extent(), path may be freed by error or be reallocated, so using a previously saved *ppath may have been freed and thus may trigger use-after-free, as follows: ext4_split_extent path = *ppath; ext4_split_extent_at(ppath) path = ext4_find_extent(ppath) ext4_split_extent_at(ppath) // ext4_find_extent fails to free path // but zeroout succeeds ext4_ext_show_leaf(inode, path) eh = path[depth].p_hdr // path use-after-free !!! Similar to ext4_split_extent_at(), we use *ppath directly as an input to ext4_ext_show_leaf(). Fix a spelling error by the way. Same problem in ext4_ext_handle_unwritten_extents(). Since 'path' is only used in ext4_ext_show_leaf(), remove 'path' and use *ppath directly. This issue is triggered only when EXT_DEBUG is defined and therefore does not affect functionality.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49968", "url": "https://ubuntu.com/security/CVE-2024-49968", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: filesystems without casefold feature cannot be mounted with siphash When mounting the ext4 filesystem, if the default hash version is set to DX_HASH_SIPHASH but the casefold feature is not set, exit the mounting.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49988", "url": "https://ubuntu.com/security/CVE-2024-49988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: add refcnt to ksmbd_conn struct When sending an oplock break request, opinfo->conn is used, But freed ->conn can be used on multichannel. This patch add a reference count to the ksmbd_conn struct so that it can be freed when it is no longer used.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49890", "url": "https://ubuntu.com/security/CVE-2024-49890", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: ensure the fw_info is not null before using it This resolves the dereference null return value warning reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49891", "url": "https://ubuntu.com/security/CVE-2024-49891", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata paths When the HBA is undergoing a reset or is handling an errata event, NULL ptr dereference crashes may occur in routines such as lpfc_sli_flush_io_rings(), lpfc_dev_loss_tmo_callbk(), or lpfc_abort_handler(). Add NULL ptr checks before dereferencing hdwq pointers that may have been freed due to operations colliding with a reset or errata event handler.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49892", "url": "https://ubuntu.com/security/CVE-2024-49892", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize get_bytes_per_element's default to 1 Variables, used as denominators and maybe not assigned to other values, should not be 0. bytes_per_element_y & bytes_per_element_c are initialized by get_bytes_per_element() which should never return 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50016", "url": "https://ubuntu.com/security/CVE-2024-50016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Avoid overflow assignment in link_dp_cts sampling_rate is an uint8_t but is assigned an unsigned int, and thus it can overflow. As a result, sampling_rate is changed to uint32_t. Similarly, LINK_QUAL_PATTERN_SET has a size of 2 bits, and it should only be assigned to a value less or equal than 4. This fixes 2 INTEGER_OVERFLOW issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49893", "url": "https://ubuntu.com/security/CVE-2024-49893", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check stream_status before it is used [WHAT & HOW] dc_state_get_stream_status can return null, and therefore null must be checked before stream_status is used. This fixes 1 NULL_RETURNS issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49969", "url": "https://ubuntu.com/security/CVE-2024-49969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 color transformation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_hw_format` function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:180 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:181 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:182 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49970", "url": "https://ubuntu.com/security/CVE-2024-49970", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Implement bounds check for stream encoder creation in DCN401 'stream_enc_regs' array is an array of dcn10_stream_enc_registers structures. The array is initialized with four elements, corresponding to the four calls to stream_enc_regs() in the array initializer. This means that valid indices for this array are 0, 1, 2, and 3. The error message 'stream_enc_regs' 4 <= 5 below, is indicating that there is an attempt to access this array with an index of 5, which is out of bounds. This could lead to undefined behavior Here, eng_id is used as an index to access the stream_enc_regs array. If eng_id is 5, this would result in an out-of-bounds access on the stream_enc_regs array. Thus fixing Buffer overflow error in dcn401_stream_encoder_create Found by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn401/dcn401_resource.c:1209 dcn401_stream_encoder_create() error: buffer overflow 'stream_enc_regs' 4 <= 5", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49894", "url": "https://ubuntu.com/security/CVE-2024-49894", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in degamma hardware format translation Fixes index out of bounds issue in `cm_helper_translate_curve_to_degamma_hw_format` function. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49895", "url": "https://ubuntu.com/security/CVE-2024-49895", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format translation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_degamma_hw_format` function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:338 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:339 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:340 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49971", "url": "https://ubuntu.com/security/CVE-2024-49971", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Increase array size of dummy_boolean [WHY] dml2_core_shared_mode_support and dml_core_mode_support access the third element of dummy_boolean, i.e. hw_debug5 = &s->dummy_boolean[2], when dummy_boolean has size of 2. Any assignment to hw_debug5 causes an OVERRUN. [HOW] Increase dummy_boolean's array size to 3. This fixes 2 OVERRUN issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49972", "url": "https://ubuntu.com/security/CVE-2024-49972", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Deallocate DML memory if allocation fails [Why] When DC state create DML memory allocation fails, memory is not deallocated subsequently, resulting in uninitialized structure that is not NULL. [How] Deallocate memory if DML memory allocation fails.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49896", "url": "https://ubuntu.com/security/CVE-2024-49896", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check stream before comparing them [WHAT & HOW] amdgpu_dm can pass a null stream to dc_is_stream_unchanged. It is necessary to check for null before dereferencing them. This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49897", "url": "https://ubuntu.com/security/CVE-2024-49897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check phantom_stream before it is used dcn32_enable_phantom_stream can return null, so returned value must be checked before used. This fixes 1 NULL_RETURNS issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49898", "url": "https://ubuntu.com/security/CVE-2024-49898", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null-initialized variables [WHAT & HOW] drr_timing and subvp_pipe are initialized to null and they are not always assigned new values. It is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49899", "url": "https://ubuntu.com/security/CVE-2024-49899", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize denominators' default to 1 [WHAT & HOW] Variables used as denominators and maybe not assigned to other values, should not be 0. Change their default to 1 so they are never 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49900", "url": "https://ubuntu.com/security/CVE-2024-49900", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uninit-value access of new_ea in ea_buffer syzbot reports that lzo1x_1_do_compress is using uninit-value: ===================================================== BUG: KMSAN: uninit-value in lzo1x_1_do_compress+0x19f9/0x2510 lib/lzo/lzo1x_compress.c:178 ... Uninit was stored to memory at: ea_put fs/jfs/xattr.c:639 [inline] ... Local variable ea_buf created at: __jfs_setxattr+0x5d/0x1ae0 fs/jfs/xattr.c:662 __jfs_xattr_set+0xe6/0x1f0 fs/jfs/xattr.c:934 ===================================================== The reason is ea_buf->new_ea is not initialized properly. Fix this by using memset to empty its content at the beginning in ea_get().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49901", "url": "https://ubuntu.com/security/CVE-2024-49901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm/adreno: Assign msm_gpu->pdev earlier to avoid nullptrs There are some cases, such as the one uncovered by Commit 46d4efcccc68 (\"drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails\") where msm_gpu_cleanup() : platform_set_drvdata(gpu->pdev, NULL); is called on gpu->pdev == NULL, as the GPU device has not been fully initialized yet. Turns out that there's more than just the aforementioned path that causes this to happen (e.g. the case when there's speedbin data in the catalog, but opp-supported-hw is missing in DT). Assigning msm_gpu->pdev earlier seems like the least painful solution to this, therefore do so. Patchwork: https://patchwork.freedesktop.org/patch/602742/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49902", "url": "https://ubuntu.com/security/CVE-2024-49902", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: check if leafidx greater than num leaves per dmap tree syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf. Shaggy: Modified sanity check to apply to control pages as well as leaf pages.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49903", "url": "https://ubuntu.com/security/CVE-2024-49903", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uaf in dbFreeBits [syzbot reported] ================================================================== BUG: KASAN: slab-use-after-free in __mutex_lock_common kernel/locking/mutex.c:587 [inline] BUG: KASAN: slab-use-after-free in __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 Read of size 8 at addr ffff8880229254b0 by task syz-executor357/5216 CPU: 0 UID: 0 PID: 5216 Comm: syz-executor357 Not tainted 6.11.0-rc3-syzkaller-00156-gd7a5aa4b3c00 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 __mutex_lock_common kernel/locking/mutex.c:587 [inline] __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 dbFreeBits+0x7ea/0xd90 fs/jfs/jfs_dmap.c:2390 dbFreeDmap fs/jfs/jfs_dmap.c:2089 [inline] dbFree+0x35b/0x680 fs/jfs/jfs_dmap.c:409 dbDiscardAG+0x8a9/0xa20 fs/jfs/jfs_dmap.c:1650 jfs_ioc_trim+0x433/0x670 fs/jfs/jfs_discard.c:100 jfs_ioctl+0x2d0/0x3e0 fs/jfs/ioctl.c:131 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 Freed by task 5218: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object+0xe0/0x150 mm/kasan/common.c:240 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2252 [inline] slab_free mm/slub.c:4473 [inline] kfree+0x149/0x360 mm/slub.c:4594 dbUnmount+0x11d/0x190 fs/jfs/jfs_dmap.c:278 jfs_mount_rw+0x4ac/0x6a0 fs/jfs/jfs_mount.c:247 jfs_remount+0x3d1/0x6b0 fs/jfs/super.c:454 reconfigure_super+0x445/0x880 fs/super.c:1083 vfs_cmd_reconfigure fs/fsopen.c:263 [inline] vfs_fsconfig_locked fs/fsopen.c:292 [inline] __do_sys_fsconfig fs/fsopen.c:473 [inline] __se_sys_fsconfig+0xb6e/0xf80 fs/fsopen.c:345 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 [Analysis] There are two paths (dbUnmount and jfs_ioc_trim) that generate race condition when accessing bmap, which leads to the occurrence of uaf. Use the lock s_umount to synchronize them, in order to avoid uaf caused by race condition.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49904", "url": "https://ubuntu.com/security/CVE-2024-49904", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add list empty check to avoid null pointer issue Add list empty check to avoid null pointer issues in some corner cases. - list_for_each_entry_safe()", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49989", "url": "https://ubuntu.com/security/CVE-2024-49989", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix double free issue during amdgpu module unload Flexible endpoints use DIGs from available inflexible endpoints, so only the encoders of inflexible links need to be freed. Otherwise, a double free issue may occur when unloading the amdgpu module. [ 279.190523] RIP: 0010:__slab_free+0x152/0x2f0 [ 279.190577] Call Trace: [ 279.190580] [ 279.190582] ? show_regs+0x69/0x80 [ 279.190590] ? die+0x3b/0x90 [ 279.190595] ? do_trap+0xc8/0xe0 [ 279.190601] ? do_error_trap+0x73/0xa0 [ 279.190605] ? __slab_free+0x152/0x2f0 [ 279.190609] ? exc_invalid_op+0x56/0x70 [ 279.190616] ? __slab_free+0x152/0x2f0 [ 279.190642] ? asm_exc_invalid_op+0x1f/0x30 [ 279.190648] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191096] ? __slab_free+0x152/0x2f0 [ 279.191102] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191469] kfree+0x260/0x2b0 [ 279.191474] dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191821] link_destroy+0xd7/0x130 [amdgpu] [ 279.192248] dc_destruct+0x90/0x270 [amdgpu] [ 279.192666] dc_destroy+0x19/0x40 [amdgpu] [ 279.193020] amdgpu_dm_fini+0x16e/0x200 [amdgpu] [ 279.193432] dm_hw_fini+0x26/0x40 [amdgpu] [ 279.193795] amdgpu_device_fini_hw+0x24c/0x400 [amdgpu] [ 279.194108] amdgpu_driver_unload_kms+0x4f/0x70 [amdgpu] [ 279.194436] amdgpu_pci_remove+0x40/0x80 [amdgpu] [ 279.194632] pci_device_remove+0x3a/0xa0 [ 279.194638] device_remove+0x40/0x70 [ 279.194642] device_release_driver_internal+0x1ad/0x210 [ 279.194647] driver_detach+0x4e/0xa0 [ 279.194650] bus_remove_driver+0x6f/0xf0 [ 279.194653] driver_unregister+0x33/0x60 [ 279.194657] pci_unregister_driver+0x44/0x90 [ 279.194662] amdgpu_exit+0x19/0x1f0 [amdgpu] [ 279.194939] __do_sys_delete_module.isra.0+0x198/0x2f0 [ 279.194946] __x64_sys_delete_module+0x16/0x20 [ 279.194950] do_syscall_64+0x58/0x120 [ 279.194954] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 279.194980] ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49905", "url": "https://ubuntu.com/security/CVE-2024-49905", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for 'afb' in amdgpu_dm_plane_handle_cursor_update (v2) This commit adds a null check for the 'afb' variable in the amdgpu_dm_plane_handle_cursor_update function. Previously, 'afb' was assumed to be null, but was used later in the code without a null check. This could potentially lead to a null pointer dereference. Changes since v1: - Moved the null check for 'afb' to the line where 'afb' is used. (Alex) Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:1298 amdgpu_dm_plane_handle_cursor_update() error: we previously assumed 'afb' could be null (see line 1252)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49906", "url": "https://ubuntu.com/security/CVE-2024-49906", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before try to access it [why & how] Change the order of the pipe_ctx->plane_state check to ensure that plane_state is not null before accessing it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49907", "url": "https://ubuntu.com/security/CVE-2024-49907", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before using dc->clk_mgr [WHY & HOW] dc->clk_mgr is null checked previously in the same function, indicating it might be null. Passing \"dc\" to \"dc->hwss.apply_idle_power_optimizations\", which dereferences null \"dc->clk_mgr\". (The function pointer resolves to \"dcn35_apply_idle_power_optimizations\".) This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49908", "url": "https://ubuntu.com/security/CVE-2024-49908", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for 'afb' in amdgpu_dm_update_cursor (v2) This commit adds a null check for the 'afb' variable in the amdgpu_dm_update_cursor function. Previously, 'afb' was assumed to be null at line 8388, but was used later in the code without a null check. This could potentially lead to a null pointer dereference. Changes since v1: - Moved the null check for 'afb' to the line where 'afb' is used. (Alex) Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:8433 amdgpu_dm_update_cursor() \terror: we previously assumed 'afb' could be null (see line 8388)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50177", "url": "https://ubuntu.com/security/CVE-2024-50177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix a UBSAN warning in DML2.1 When programming phantom pipe, since cursor_width is explicity set to 0, this causes calculation logic to trigger overflow for an unsigned int triggering the kernel's UBSAN check as below: [ 40.962845] UBSAN: shift-out-of-bounds in /tmp/amd.EfpumTkO/amd/amdgpu/../display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c:3312:34 [ 40.962849] shift exponent 4294967170 is too large for 32-bit type 'unsigned int' [ 40.962852] CPU: 1 PID: 1670 Comm: gnome-shell Tainted: G W OE 6.5.0-41-generic #41~22.04.2-Ubuntu [ 40.962854] Hardware name: Gigabyte Technology Co., Ltd. X670E AORUS PRO X/X670E AORUS PRO X, BIOS F21 01/10/2024 [ 40.962856] Call Trace: [ 40.962857] [ 40.962860] dump_stack_lvl+0x48/0x70 [ 40.962870] dump_stack+0x10/0x20 [ 40.962872] __ubsan_handle_shift_out_of_bounds+0x1ac/0x360 [ 40.962878] calculate_cursor_req_attributes.cold+0x1b/0x28 [amdgpu] [ 40.963099] dml_core_mode_support+0x6b91/0x16bc0 [amdgpu] [ 40.963327] ? srso_alias_return_thunk+0x5/0x7f [ 40.963331] ? CalculateWatermarksMALLUseAndDRAMSpeedChangeSupport+0x18b8/0x2790 [amdgpu] [ 40.963534] ? srso_alias_return_thunk+0x5/0x7f [ 40.963536] ? dml_core_mode_support+0xb3db/0x16bc0 [amdgpu] [ 40.963730] dml2_core_calcs_mode_support_ex+0x2c/0x90 [amdgpu] [ 40.963906] ? srso_alias_return_thunk+0x5/0x7f [ 40.963909] ? dml2_core_calcs_mode_support_ex+0x2c/0x90 [amdgpu] [ 40.964078] core_dcn4_mode_support+0x72/0xbf0 [amdgpu] [ 40.964247] dml2_top_optimization_perform_optimization_phase+0x1d3/0x2a0 [amdgpu] [ 40.964420] dml2_build_mode_programming+0x23d/0x750 [amdgpu] [ 40.964587] dml21_validate+0x274/0x770 [amdgpu] [ 40.964761] ? srso_alias_return_thunk+0x5/0x7f [ 40.964763] ? resource_append_dpp_pipes_for_plane_composition+0x27c/0x3b0 [amdgpu] [ 40.964942] dml2_validate+0x504/0x750 [amdgpu] [ 40.965117] ? dml21_copy+0x95/0xb0 [amdgpu] [ 40.965291] ? srso_alias_return_thunk+0x5/0x7f [ 40.965295] dcn401_validate_bandwidth+0x4e/0x70 [amdgpu] [ 40.965491] update_planes_and_stream_state+0x38d/0x5c0 [amdgpu] [ 40.965672] update_planes_and_stream_v3+0x52/0x1e0 [amdgpu] [ 40.965845] ? srso_alias_return_thunk+0x5/0x7f [ 40.965849] dc_update_planes_and_stream+0x71/0xb0 [amdgpu] Fix this by adding a guard for checking cursor width before triggering the size calculation.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49909", "url": "https://ubuntu.com/security/CVE-2024-49909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn32_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn32_set_output_transfer_func function. Previously, set_output_gamma was being checked for null, but then it was being dereferenced without any null check. This could lead to a null pointer dereference if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49910", "url": "https://ubuntu.com/security/CVE-2024-49910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn401_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn401_set_output_transfer_func function. Previously, set_output_gamma was being checked for null, but then it was being dereferenced without any null check. This could lead to a null pointer dereference if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49911", "url": "https://ubuntu.com/security/CVE-2024-49911", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn20_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn20_set_output_transfer_func function. Previously, set_output_gamma was being checked for null at line 1030, but then it was being dereferenced without any null check at line 1048. This could potentially lead to a null pointer dereference error if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma at line 1048.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49912", "url": "https://ubuntu.com/security/CVE-2024-49912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Handle null 'stream_status' in 'planes_changed_for_existing_stream' This commit adds a null check for 'stream_status' in the function 'planes_changed_for_existing_stream'. Previously, the code assumed 'stream_status' could be null, but did not handle the case where it was actually null. This could lead to a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:3784 planes_changed_for_existing_stream() error: we previously assumed 'stream_status' could be null (see line 3774)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49913", "url": "https://ubuntu.com/security/CVE-2024-49913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for top_pipe_to_program in commit_planes_for_stream This commit addresses a null pointer dereference issue in the `commit_planes_for_stream` function at line 4140. The issue could occur when `top_pipe_to_program` is null. The fix adds a check to ensure `top_pipe_to_program` is not null before accessing its stream_res. This prevents a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:4140 commit_planes_for_stream() error: we previously assumed 'top_pipe_to_program' could be null (see line 3906)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49914", "url": "https://ubuntu.com/security/CVE-2024-49914", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for pipe_ctx->plane_state in dcn20_program_pipe This commit addresses a null pointer dereference issue in the `dcn20_program_pipe` function. The issue could occur when `pipe_ctx->plane_state` is null. The fix adds a check to ensure `pipe_ctx->plane_state` is not null before accessing. This prevents a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn20/dcn20_hwseq.c:1925 dcn20_program_pipe() error: we previously assumed 'pipe_ctx->plane_state' could be null (see line 1877)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49915", "url": "https://ubuntu.com/security/CVE-2024-49915", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr in dcn32_init_hw This commit addresses a potential null pointer dereference issue in the `dcn32_init_hw` function. The issue could occur when `dc->clk_mgr` is null. The fix adds a check to ensure `dc->clk_mgr` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn32/dcn32_hwseq.c:961 dcn32_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 782)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49916", "url": "https://ubuntu.com/security/CVE-2024-49916", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in dcn401_init_hw This commit addresses a potential null pointer dereference issue in the `dcn401_init_hw` function. The issue could occur when `dc->clk_mgr` or `dc->clk_mgr->funcs` is null. The fix adds a check to ensure `dc->clk_mgr` and `dc->clk_mgr->funcs` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn401/dcn401_hwseq.c:416 dcn401_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 225)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49917", "url": "https://ubuntu.com/security/CVE-2024-49917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in dcn30_init_hw This commit addresses a potential null pointer dereference issue in the `dcn30_init_hw` function. The issue could occur when `dc->clk_mgr` or `dc->clk_mgr->funcs` is null. The fix adds a check to ensure `dc->clk_mgr` and `dc->clk_mgr->funcs` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:789 dcn30_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 628)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49918", "url": "https://ubuntu.com/security/CVE-2024-49918", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for head_pipe in dcn32_acquire_idle_pipe_for_head_pipe_in_layer This commit addresses a potential null pointer dereference issue in the `dcn32_acquire_idle_pipe_for_head_pipe_in_layer` function. The issue could occur when `head_pipe` is null. The fix adds a check to ensure `head_pipe` is not null before asserting it. If `head_pipe` is null, the function returns NULL to prevent a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn32/dcn32_resource.c:2690 dcn32_acquire_idle_pipe_for_head_pipe_in_layer() error: we previously assumed 'head_pipe' could be null (see line 2681)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49919", "url": "https://ubuntu.com/security/CVE-2024-49919", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for head_pipe in dcn201_acquire_free_pipe_for_layer This commit addresses a potential null pointer dereference issue in the `dcn201_acquire_free_pipe_for_layer` function. The issue could occur when `head_pipe` is null. The fix adds a check to ensure `head_pipe` is not null before asserting it. If `head_pipe` is null, the function returns NULL to prevent a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn201/dcn201_resource.c:1016 dcn201_acquire_free_pipe_for_layer() error: we previously assumed 'head_pipe' could be null (see line 1010)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49991", "url": "https://ubuntu.com/security/CVE-2024-49991", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer Pass pointer reference to amdgpu_bo_unref to clear the correct pointer, otherwise amdgpu_bo_unref clear the local variable, the original pointer not set to NULL, this could cause use-after-free bug.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49920", "url": "https://ubuntu.com/security/CVE-2024-49920", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before multiple uses [WHAT & HOW] Poniters, such as stream_enc and dc->bw_vbios, are null checked previously in the same function, so Coverity warns \"implies that stream_enc and dc->bw_vbios might be null\". They are used multiple times in the subsequent code and need to be checked. This fixes 10 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49921", "url": "https://ubuntu.com/security/CVE-2024-49921", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before used [WHAT & HOW] Poniters, such as dc->clk_mgr, are null checked previously in the same function, so Coverity warns \"implies that \"dc->clk_mgr\" might be null\". As a result, these pointers need to be checked when used again. This fixes 10 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49922", "url": "https://ubuntu.com/security/CVE-2024-49922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before using them [WHAT & HOW] These pointers are null checked previously in the same function, indicating they might be null as reported by Coverity. As a result, they need to be checked when used again. This fixes 3 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49923", "url": "https://ubuntu.com/security/CVE-2024-49923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Pass non-null to dcn20_validate_apply_pipe_split_flags [WHAT & HOW] \"dcn20_validate_apply_pipe_split_flags\" dereferences merge, and thus it cannot be a null pointer. Let's pass a valid pointer to avoid null dereference. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49992", "url": "https://ubuntu.com/security/CVE-2024-49992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/stm: Avoid use-after-free issues with crtc and plane ltdc_load() calls functions drm_crtc_init_with_planes(), drm_universal_plane_init() and drm_encoder_init(). These functions should not be called with parameters allocated with devm_kzalloc() to avoid use-after-free issues [1]. Use allocations managed by the DRM framework. Found by Linux Verification Center (linuxtesting.org). [1] https://lore.kernel.org/lkml/u366i76e3qhh3ra5oxrtngjtm2u5lterkekcz6y2jkndhuxzli@diujon4h7qwb/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49993", "url": "https://ubuntu.com/security/CVE-2024-49993", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49924", "url": "https://ubuntu.com/security/CVE-2024-49924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: pxafb: Fix possible use after free in pxafb_task() In the pxafb_probe function, it calls the pxafb_init_fbinfo function, after which &fbi->task is associated with pxafb_task. Moreover, within this pxafb_init_fbinfo function, the pxafb_blank function within the &pxafb_ops struct is capable of scheduling work. If we remove the module which will call pxafb_remove to make cleanup, it will call unregister_framebuffer function which can call do_unregister_framebuffer to free fbi->fb through put_fb_info(fb_info), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | pxafb_task pxafb_remove | unregister_framebuffer(info) | do_unregister_framebuffer(fb_info) | put_fb_info(fb_info) | // free fbi->fb | set_ctrlr_state(fbi, state) | __pxafb_lcd_power(fbi, 0) | fbi->lcd_power(on, &fbi->fb.var) | //use fbi->fb Fix it by ensuring that the work is canceled before proceeding with the cleanup in pxafb_remove. Note that only root user can remove the driver at runtime.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49925", "url": "https://ubuntu.com/security/CVE-2024-49925", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: efifb: Register sysfs groups through driver core The driver core can register and cleanup sysfs groups already. Make use of that functionality to simplify the error handling and cleanup. Also avoid a UAF race during unregistering where the sysctl attributes were usable after the info struct was freed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49926", "url": "https://ubuntu.com/security/CVE-2024-49926", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rcu-tasks: Fix access non-existent percpu rtpcp variable in rcu_tasks_need_gpcb() For kernels built with CONFIG_FORCE_NR_CPUS=y, the nr_cpu_ids is defined as NR_CPUS instead of the number of possible cpus, this will cause the following system panic: smpboot: Allowing 4 CPUs, 0 hotplug CPUs ... setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:512 nr_node_ids:1 ... BUG: unable to handle page fault for address: ffffffff9911c8c8 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 15 Comm: rcu_tasks_trace Tainted: G W 6.6.21 #1 5dc7acf91a5e8e9ac9dcfc35bee0245691283ea6 RIP: 0010:rcu_tasks_need_gpcb+0x25d/0x2c0 RSP: 0018:ffffa371c00a3e60 EFLAGS: 00010082 CR2: ffffffff9911c8c8 CR3: 000000040fa20005 CR4: 00000000001706f0 Call Trace: ? __die+0x23/0x80 ? page_fault_oops+0xa4/0x180 ? exc_page_fault+0x152/0x180 ? asm_exc_page_fault+0x26/0x40 ? rcu_tasks_need_gpcb+0x25d/0x2c0 ? __pfx_rcu_tasks_kthread+0x40/0x40 rcu_tasks_one_gp+0x69/0x180 rcu_tasks_kthread+0x94/0xc0 kthread+0xe8/0x140 ? __pfx_kthread+0x40/0x40 ret_from_fork+0x34/0x80 ? __pfx_kthread+0x40/0x40 ret_from_fork_asm+0x1b/0x80 Considering that there may be holes in the CPU numbers, use the maximum possible cpu number, instead of nr_cpu_ids, for configuring enqueue and dequeue limits. [ neeraj.upadhyay: Fix htmldocs build error reported by Stephen Rothwell ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50007", "url": "https://ubuntu.com/security/CVE-2024-50007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: asihpi: Fix potential OOB array access ASIHPI driver stores some values in the static array upon a response from the driver, and its index depends on the firmware. We shouldn't trust it blindly. This patch adds a sanity check of the array index to fit in the array size.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50017", "url": "https://ubuntu.com/security/CVE-2024-50017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm/ident_map: Use gbpages only where full GB page should be mapped. When ident_pud_init() uses only GB pages to create identity maps, large ranges of addresses not actually requested can be included in the resulting table; a 4K request will map a full GB. This can include a lot of extra address space past that requested, including areas marked reserved by the BIOS. That allows processor speculation into reserved regions, that on UV systems can cause system halts. Only use GB pages when map creation requests include the full GB page of space. Fall back to using smaller 2M pages when only portions of a GB page are included in the request. No attempt is made to coalesce mapping requests. If a request requires a map entry at the 2M (pmd) level, subsequent mapping requests within the same 1G region will also be at the pmd level, even if adjacent or overlapping such requests could have been combined to map a full GB page. Existing usage starts with larger regions and then adds smaller regions, so this should not have any great consequence.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49927", "url": "https://ubuntu.com/security/CVE-2024-49927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/ioapic: Handle allocation failures gracefully Breno observed panics when using failslab under certain conditions during runtime: can not alloc irq_pin_list (-1,0,20) Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed panic+0x4e9/0x590 mp_irqdomain_alloc+0x9ab/0xa80 irq_domain_alloc_irqs_locked+0x25d/0x8d0 __irq_domain_alloc_irqs+0x80/0x110 mp_map_pin_to_irq+0x645/0x890 acpi_register_gsi_ioapic+0xe6/0x150 hpet_open+0x313/0x480 That's a pointless panic which is a leftover of the historic IO/APIC code which panic'ed during early boot when the interrupt allocation failed. The only place which might justify panic is the PIT/HPET timer_check() code which tries to figure out whether the timer interrupt is delivered through the IO/APIC. But that code does not require to handle interrupt allocation failures. If the interrupt cannot be allocated then timer delivery fails and it either panics due to that or falls back to legacy mode. Cure this by removing the panic wrapper around __add_pin_to_irq_node() and making mp_irqdomain_alloc() aware of the failure condition and handle it as any other failure in this function gracefully.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50008", "url": "https://ubuntu.com/security/CVE-2024-50008", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_cmd_802_11_scan_ext() Replace one-element array with a flexible-array member in `struct host_cmd_ds_802_11_scan_ext`. With this, fix the following warning: elo 16 17:51:58 surfacebook kernel: ------------[ cut here ]------------ elo 16 17:51:58 surfacebook kernel: memcpy: detected field-spanning write (size 243) of single field \"ext_scan->tlv_buffer\" at drivers/net/wireless/marvell/mwifiex/scan.c:2239 (size 1) elo 16 17:51:58 surfacebook kernel: WARNING: CPU: 0 PID: 498 at drivers/net/wireless/marvell/mwifiex/scan.c:2239 mwifiex_cmd_802_11_scan_ext+0x83/0x90 [mwifiex]", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50018", "url": "https://ubuntu.com/security/CVE-2024-50018", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49928", "url": "https://ubuntu.com/security/CVE-2024-49928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: avoid reading out of bounds when loading TX power FW elements Because the loop-expression will do one more time before getting false from cond-expression, the original code copied one more entry size beyond valid region. Fix it by moving the entry copy to loop-body.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50178", "url": "https://ubuntu.com/security/CVE-2024-50178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: loongson3: Use raw_smp_processor_id() in do_service_request() Use raw_smp_processor_id() instead of plain smp_processor_id() in do_service_request(), otherwise we may get some errors with the driver enabled: BUG: using smp_processor_id() in preemptible [00000000] code: (udev-worker)/208 caller is loongson3_cpufreq_probe+0x5c/0x250 [loongson3_cpufreq]", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50009", "url": "https://ubuntu.com/security/CVE-2024-50009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: amd-pstate: add check for cpufreq_cpu_get's return value cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it and return in case of error. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49994", "url": "https://ubuntu.com/security/CVE-2024-49994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix integer overflow in BLKSECDISCARD I independently rediscovered \tcommit 22d24a544b0d49bbcbd61c8c0eaf77d3c9297155 \tblock: fix overflow in blk_ioctl_discard() but for secure erase. Same problem: \tuint64_t r[2] = {512, 18446744073709551104ULL}; \tioctl(fd, BLKSECDISCARD, r); will enter near infinite loop inside blkdev_issue_secure_erase(): \ta.out: attempt to access beyond end of device \tloop0: rw=5, sector=3399043073, nr_sectors = 1024 limit=2048 \tbio_check_eod: 3286214 callbacks suppressed", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49929", "url": "https://ubuntu.com/security/CVE-2024-49929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: avoid NULL pointer dereference iwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta pointer is not NULL. It retrieves this pointer using iwl_mvm_sta_from_mac80211, which is dereferencing the ieee80211_sta pointer. If sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL pointer. Fix this by checking the sta pointer before retrieving the mvmsta from it. If sta is not NULL, then mvmsta isn't either.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49995", "url": "https://ubuntu.com/security/CVE-2024-49995", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: guard against string buffer overrun Smatch reports that copying media_name and if_name to name_parts may overwrite the destination. .../bearer.c:166 bearer_name_validate() error: strcpy() 'media_name' too large for 'name_parts->media_name' (32 vs 16) .../bearer.c:167 bearer_name_validate() error: strcpy() 'if_name' too large for 'name_parts->if_name' (1010102 vs 16) This does seem to be the case so guard against this possibility by using strscpy() and failing if truncation occurs. Introduced by commit b97bf3fd8f6a (\"[TIPC] Initial merge\") Compile tested only.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49962", "url": "https://ubuntu.com/security/CVE-2024-49962", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in acpi_db_convert_to_package() ACPICA commit 4d4547cf13cca820ff7e0f859ba83e1a610b9fd0 ACPI_ALLOCATE_ZEROED() may fail, elements might be NULL and will cause NULL pointer dereference later. [ rjw: Subject and changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49930", "url": "https://ubuntu.com/security/CVE-2024-49930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix array out-of-bound access in SoC stats Currently, the ath11k_soc_dp_stats::hal_reo_error array is defined with a maximum size of DP_REO_DST_RING_MAX. However, the ath11k_dp_process_rx() function access ath11k_soc_dp_stats::hal_reo_error using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath11k_dp_process_rx() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49931", "url": "https://ubuntu.com/security/CVE-2024-49931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix array out-of-bound access in SoC stats Currently, the ath12k_soc_dp_stats::hal_reo_error array is defined with a maximum size of DP_REO_DST_RING_MAX. However, the ath12k_dp_rx_process() function access ath12k_soc_dp_stats::hal_reo_error using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath12k_dp_rx_process() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49932", "url": "https://ubuntu.com/security/CVE-2024-49932", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: don't readahead the relocation inode on RST On relocation we're doing readahead on the relocation inode, but if the filesystem is backed by a RAID stripe tree we can get ENOENT (e.g. due to preallocated extents not being mapped in the RST) from the lookup. But readahead doesn't handle the error and submits invalid reads to the device, causing an assertion in the scatter-gather list code: BTRFS info (device nvme1n1): balance: start -d -m -s BTRFS info (device nvme1n1): relocating block group 6480920576 flags data|raid0 BTRFS error (device nvme1n1): cannot find raid-stripe for logical [6481928192, 6481969152] devid 2, profile raid0 ------------[ cut here ]------------ kernel BUG at include/linux/scatterlist.h:115! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 1012 Comm: btrfs Not tainted 6.10.0-rc7+ #567 RIP: 0010:__blk_rq_map_sg+0x339/0x4a0 RSP: 0018:ffffc90001a43820 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffea00045d4802 RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000 RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000001000 R12: ffff8881003d10b8 R13: ffffc90001a438f0 R14: 0000000000000000 R15: 0000000000003000 FS: 00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000002cd11000 CR3: 00000001109ea001 CR4: 0000000000370eb0 Call Trace: ? __die_body.cold+0x14/0x25 ? die+0x2e/0x50 ? do_trap+0xca/0x110 ? do_error_trap+0x65/0x80 ? __blk_rq_map_sg+0x339/0x4a0 ? exc_invalid_op+0x50/0x70 ? __blk_rq_map_sg+0x339/0x4a0 ? asm_exc_invalid_op+0x1a/0x20 ? __blk_rq_map_sg+0x339/0x4a0 nvme_prep_rq.part.0+0x9d/0x770 nvme_queue_rq+0x7d/0x1e0 __blk_mq_issue_directly+0x2a/0x90 ? blk_mq_get_budget_and_tag+0x61/0x90 blk_mq_try_issue_list_directly+0x56/0xf0 blk_mq_flush_plug_list.part.0+0x52b/0x5d0 __blk_flush_plug+0xc6/0x110 blk_finish_plug+0x28/0x40 read_pages+0x160/0x1c0 page_cache_ra_unbounded+0x109/0x180 relocate_file_extent_cluster+0x611/0x6a0 ? btrfs_search_slot+0xba4/0xd20 ? balance_dirty_pages_ratelimited_flags+0x26/0xb00 relocate_data_extent.constprop.0+0x134/0x160 relocate_block_group+0x3f2/0x500 btrfs_relocate_block_group+0x250/0x430 btrfs_relocate_chunk+0x3f/0x130 btrfs_balance+0x71b/0xef0 ? kmalloc_trace_noprof+0x13b/0x280 btrfs_ioctl+0x2c2e/0x3030 ? kvfree_call_rcu+0x1e6/0x340 ? list_lru_add_obj+0x66/0x80 ? mntput_no_expire+0x3a/0x220 __x64_sys_ioctl+0x96/0xc0 do_syscall_64+0x54/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fcc04514f9b Code: Unable to access opcode bytes at 0x7fcc04514f71. RSP: 002b:00007ffeba923370 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fcc04514f9b RDX: 00007ffeba923460 RSI: 00000000c4009420 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000013 R09: 0000000000000001 R10: 00007fcc043fbba8 R11: 0000000000000246 R12: 00007ffeba924fc5 R13: 00007ffeba923460 R14: 0000000000000002 R15: 00000000004d4bb0 Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:__blk_rq_map_sg+0x339/0x4a0 RSP: 0018:ffffc90001a43820 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffea00045d4802 RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000 RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000001000 R12: ffff8881003d10b8 R13: ffffc90001a438f0 R14: 0000000000000000 R15: 0000000000003000 FS: 00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcc04514f71 CR3: 00000001109ea001 CR4: 0000000000370eb0 Kernel p ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49933", "url": "https://ubuntu.com/security/CVE-2024-49933", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk_iocost: fix more out of bound shifts Recently running UBSAN caught few out of bound shifts in the ioc_forgive_debts() function: UBSAN: shift-out-of-bounds in block/blk-iocost.c:2142:38 shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long long') ... UBSAN: shift-out-of-bounds in block/blk-iocost.c:2144:30 shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long long') ... Call Trace: dump_stack_lvl+0xca/0x130 __ubsan_handle_shift_out_of_bounds+0x22c/0x280 ? __lock_acquire+0x6441/0x7c10 ioc_timer_fn+0x6cec/0x7750 ? blk_iocost_init+0x720/0x720 ? call_timer_fn+0x5d/0x470 call_timer_fn+0xfa/0x470 ? blk_iocost_init+0x720/0x720 __run_timer_base+0x519/0x700 ... Actual impact of this issue was not identified but I propose to fix the undefined behaviour. The proposed fix to prevent those out of bound shifts consist of precalculating exponent before using it the shift operations by taking min value from the actual exponent and maximum possible number of bits.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49934", "url": "https://ubuntu.com/security/CVE-2024-49934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/inode: Prevent dump_mapping() accessing invalid dentry.d_name.name It's observed that a crash occurs during hot-remove a memory device, in which user is accessing the hugetlb. See calltrace as following: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 14045 at arch/x86/mm/fault.c:1278 do_user_addr_fault+0x2a0/0x790 Modules linked in: kmem device_dax cxl_mem cxl_pmem cxl_port cxl_pci dax_hmem dax_pmem nd_pmem cxl_acpi nd_btt cxl_core crc32c_intel nvme virtiofs fuse nvme_core nfit libnvdimm dm_multipath scsi_dh_rdac scsi_dh_emc s mirror dm_region_hash dm_log dm_mod CPU: 1 PID: 14045 Comm: daxctl Not tainted 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:do_user_addr_fault+0x2a0/0x790 Code: 48 8b 00 a8 04 0f 84 b5 fe ff ff e9 1c ff ff ff 4c 89 e9 4c 89 e2 be 01 00 00 00 bf 02 00 00 00 e8 b5 ef 24 00 e9 42 fe ff ff <0f> 0b 48 83 c4 08 4c 89 ea 48 89 ee 4c 89 e7 5b 5d 41 5c 41 5d 41 RSP: 0000:ffffc90000a575f0 EFLAGS: 00010046 RAX: ffff88800c303600 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000001000 RSI: ffffffff82504162 RDI: ffffffff824b2c36 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffc90000a57658 R13: 0000000000001000 R14: ffff88800bc2e040 R15: 0000000000000000 FS: 00007f51cb57d880(0000) GS:ffff88807fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000001000 CR3: 00000000072e2004 CR4: 00000000001706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn+0x8d/0x190 ? do_user_addr_fault+0x2a0/0x790 ? report_bug+0x1c3/0x1d0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? do_user_addr_fault+0x2a0/0x790 ? exc_page_fault+0x31/0x200 exc_page_fault+0x68/0x200 <...snip...> BUG: unable to handle page fault for address: 0000000000001000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI ---[ end trace 0000000000000000 ]--- BUG: unable to handle page fault for address: 0000000000001000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 14045 Comm: daxctl Kdump: loaded Tainted: G W 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:dentry_name+0x1f4/0x440 <...snip...> ? dentry_name+0x2fa/0x440 vsnprintf+0x1f3/0x4f0 vprintk_store+0x23a/0x540 vprintk_emit+0x6d/0x330 _printk+0x58/0x80 dump_mapping+0x10b/0x1a0 ? __pfx_free_object_rcu+0x10/0x10 __dump_page+0x26b/0x3e0 ? vprintk_emit+0xe0/0x330 ? _printk+0x58/0x80 ? dump_page+0x17/0x50 dump_page+0x17/0x50 do_migrate_range+0x2f7/0x7f0 ? do_migrate_range+0x42/0x7f0 ? offline_pages+0x2f4/0x8c0 offline_pages+0x60a/0x8c0 memory_subsys_offline+0x9f/0x1c0 ? lockdep_hardirqs_on+0x77/0x100 ? _raw_spin_unlock_irqrestore+0x38/0x60 device_offline+0xe3/0x110 state_store+0x6e/0xc0 kernfs_fop_write_iter+0x143/0x200 vfs_write+0x39f/0x560 ksys_write+0x65/0xf0 do_syscall_64+0x62/0x130 Previously, some sanity check have been done in dump_mapping() before the print facility parsing '%pd' though, it's still possible to run into an invalid dentry.d_name.name. Since dump_mapping() only needs to dump the filename only, retrieve it by itself in a safer way to prevent an unnecessary crash. Note that either retrieving the filename with '%pd' or strncpy_from_kernel_nofault(), the filename could be unreliable.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49935", "url": "https://ubuntu.com/security/CVE-2024-49935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: PAD: fix crash in exit_round_robin() The kernel occasionally crashes in cpumask_clear_cpu(), which is called within exit_round_robin(), because when executing clear_bit(nr, addr) with nr set to 0xffffffff, the address calculation may cause misalignment within the memory, leading to access to an invalid memory address. ---------- BUG: unable to handle kernel paging request at ffffffffe0740618 ... CPU: 3 PID: 2919323 Comm: acpi_pad/14 Kdump: loaded Tainted: G OE X --------- - - 4.18.0-425.19.2.el8_7.x86_64 #1 ... RIP: 0010:power_saving_thread+0x313/0x411 [acpi_pad] Code: 89 cd 48 89 d3 eb d1 48 c7 c7 55 70 72 c0 e8 64 86 b0 e4 c6 05 0d a1 02 00 01 e9 bc fd ff ff 45 89 e4 42 8b 04 a5 20 82 72 c0 48 0f b3 05 f4 9c 01 00 42 c7 04 a5 20 82 72 c0 ff ff ff ff 31 RSP: 0018:ff72a5d51fa77ec8 EFLAGS: 00010202 RAX: 00000000ffffffff RBX: ff462981e5d8cb80 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246 RBP: ff46297556959d80 R08: 0000000000000382 R09: ff46297c8d0f38d8 R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000000e R13: 0000000000000000 R14: ffffffffffffffff R15: 000000000000000e FS: 0000000000000000(0000) GS:ff46297a800c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffe0740618 CR3: 0000007e20410004 CR4: 0000000000771ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? acpi_pad_add+0x120/0x120 [acpi_pad] kthread+0x10b/0x130 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x1f/0x40 ... CR2: ffffffffe0740618 crash> dis -lr ffffffffc0726923 ... /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 114 0xffffffffc0726918 :\tmov %r12d,%r12d /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 325 0xffffffffc072691b :\tmov -0x3f8d7de0(,%r12,4),%eax /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./arch/x86/include/asm/bitops.h: 80 0xffffffffc0726923 :\tlock btr %rax,0x19cf4(%rip) # 0xffffffffc0740620 crash> px tsk_in_cpu[14] $66 = 0xffffffff crash> px 0xffffffffc072692c+0x19cf4 $99 = 0xffffffffc0740620 crash> sym 0xffffffffc0740620 ffffffffc0740620 (b) pad_busy_cpus_bits [acpi_pad] crash> px pad_busy_cpus_bits[0] $42 = 0xfffc0 ---------- To fix this, ensure that tsk_in_cpu[tsk_index] != -1 before calling cpumask_clear_cpu() in exit_round_robin(), just as it is done in round_robin_cpu(). [ rjw: Subject edit, avoid updates to the same value ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49936", "url": "https://ubuntu.com/security/CVE-2024-49936", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/xen-netback: prevent UAF in xenvif_flush_hash() During the list_for_each_entry_rcu iteration call of xenvif_flush_hash, kfree_rcu does not exist inside the rcu read critical section, so if kfree_rcu is called when the rcu grace period ends during the iteration, UAF occurs when accessing head->next after the entry becomes free. Therefore, to solve this, you need to change it to list_for_each_entry_safe.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49937", "url": "https://ubuntu.com/security/CVE-2024-49937", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Set correct chandef when starting CAC When starting CAC in a mode other than AP mode, it return a \"WARNING: CPU: 0 PID: 63 at cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]\" caused by the chandef.chan being null at the end of CAC. Solution: Ensure the channel definition is set for the different modes when starting CAC to avoid getting a NULL 'chan' at the end of CAC. Call Trace: ? show_regs.part.0+0x14/0x16 ? __warn+0x67/0xc0 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? report_bug+0xa7/0x130 ? exc_overflow+0x30/0x30 ? handle_bug+0x27/0x50 ? exc_invalid_op+0x18/0x60 ? handle_exception+0xf6/0xf6 ? exc_overflow+0x30/0x30 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? exc_overflow+0x30/0x30 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? regulatory_propagate_dfs_state.cold+0x1b/0x4c [cfg80211] ? cfg80211_propagate_cac_done_wk+0x1a/0x30 [cfg80211] ? process_one_work+0x165/0x280 ? worker_thread+0x120/0x3f0 ? kthread+0xc2/0xf0 ? process_one_work+0x280/0x280 ? kthread_complete_and_exit+0x20/0x20 ? ret_from_fork+0x19/0x24 [shorten subject, remove OCB, reorder cases to match previous list]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49938", "url": "https://ubuntu.com/security/CVE-2024-49938", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmit Syzbot points out that skb_trim() has a sanity check on the existing length of the skb, which can be uninitialised in some error paths. The intent here is clearly just to reset the length to zero before resubmitting, so switch to calling __skb_set_length(skb, 0) directly. In addition, __skb_set_length() already contains a call to skb_reset_tail_pointer(), so remove the redundant call. The syzbot report came from ath9k_hif_usb_reg_in_cb(), but there's a similar usage of skb_trim() in ath9k_hif_usb_rx_cb(), change both while we're at it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49939", "url": "https://ubuntu.com/security/CVE-2024-49939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: avoid to add interface to list twice when SER If SER L2 occurs during the WoWLAN resume flow, the add interface flow is triggered by ieee80211_reconfig(). However, due to rtw89_wow_resume() return failure, it will cause the add interface flow to be executed again, resulting in a double add list and causing a kernel panic. Therefore, we have added a check to prevent double adding of the list. list_add double add: new=ffff99d6992e2010, prev=ffff99d6992e2010, next=ffff99d695302628. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:37! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G W O 6.6.30-02659-gc18865c4dfbd #1 770df2933251a0e3c888ba69d1053a817a6376a7 Hardware name: HP Grunt/Grunt, BIOS Google_Grunt.11031.169.0 06/24/2021 Workqueue: events_freezable ieee80211_restart_work [mac80211] RIP: 0010:__list_add_valid_or_report+0x5e/0xb0 Code: c7 74 18 48 39 ce 74 13 b0 01 59 5a 5e 5f 41 58 41 59 41 5a 5d e9 e2 d6 03 00 cc 48 c7 c7 8d 4f 17 83 48 89 c2 e8 02 c0 00 00 <0f> 0b 48 c7 c7 aa 8c 1c 83 e8 f4 bf 00 00 0f 0b 48 c7 c7 c8 bc 12 RSP: 0018:ffffa91b8007bc50 EFLAGS: 00010246 RAX: 0000000000000058 RBX: ffff99d6992e0900 RCX: a014d76c70ef3900 RDX: ffffa91b8007bae8 RSI: 00000000ffffdfff RDI: 0000000000000001 RBP: ffffa91b8007bc88 R08: 0000000000000000 R09: ffffa91b8007bae0 R10: 00000000ffffdfff R11: ffffffff83a79800 R12: ffff99d695302060 R13: ffff99d695300900 R14: ffff99d6992e1be0 R15: ffff99d6992e2010 FS: 0000000000000000(0000) GS:ffff99d6aac00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000078fbdba43480 CR3: 000000010e464000 CR4: 00000000001506f0 Call Trace: ? __die_body+0x1f/0x70 ? die+0x3d/0x60 ? do_trap+0xa4/0x110 ? __list_add_valid_or_report+0x5e/0xb0 ? do_error_trap+0x6d/0x90 ? __list_add_valid_or_report+0x5e/0xb0 ? handle_invalid_op+0x30/0x40 ? __list_add_valid_or_report+0x5e/0xb0 ? exc_invalid_op+0x3c/0x50 ? asm_exc_invalid_op+0x16/0x20 ? __list_add_valid_or_report+0x5e/0xb0 rtw89_ops_add_interface+0x309/0x310 [rtw89_core 7c32b1ee6854761c0321027c8a58c5160e41f48f] drv_add_interface+0x5c/0x130 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ieee80211_reconfig+0x241/0x13d0 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ? finish_wait+0x3e/0x90 ? synchronize_rcu_expedited+0x174/0x260 ? sync_rcu_exp_done_unlocked+0x50/0x50 ? wake_bit_function+0x40/0x40 ieee80211_restart_work+0xf0/0x140 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] process_scheduled_works+0x1e5/0x480 worker_thread+0xea/0x1e0 kthread+0xdb/0x110 ? move_linked_works+0x90/0x90 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork+0x3b/0x50 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork_asm+0x11/0x20 Modules linked in: dm_integrity async_xor xor async_tx lz4 lz4_compress zstd zstd_compress zram zsmalloc rfcomm cmac uinput algif_hash algif_skcipher af_alg btusb btrtl iio_trig_hrtimer industrialio_sw_trigger btmtk industrialio_configfs btbcm btintel uvcvideo videobuf2_vmalloc iio_trig_sysfs videobuf2_memops videobuf2_v4l2 videobuf2_common uvc snd_hda_codec_hdmi veth snd_hda_intel snd_intel_dspcfg acpi_als snd_hda_codec industrialio_triggered_buffer kfifo_buf snd_hwdep industrialio i2c_piix4 snd_hda_core designware_i2s ip6table_nat snd_soc_max98357a xt_MASQUERADE xt_cgroup snd_soc_acp_rt5682_mach fuse rtw89_8922ae(O) rtw89_8922a(O) rtw89_pci(O) rtw89_core(O) 8021q mac80211(O) bluetooth ecdh_generic ecc cfg80211 r8152 mii joydev gsmi: Log Shutdown Reason 0x03 ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49940", "url": "https://ubuntu.com/security/CVE-2024-49940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: prevent possible tunnel refcount underflow When a session is created, it sets a backpointer to its tunnel. When the session refcount drops to 0, l2tp_session_free drops the tunnel refcount if session->tunnel is non-NULL. However, session->tunnel is set in l2tp_session_create, before the tunnel refcount is incremented by l2tp_session_register, which leaves a small window where session->tunnel is non-NULL when the tunnel refcount hasn't been bumped. Moving the assignment to l2tp_session_register is trivial but l2tp_session_create calls l2tp_session_set_header_len which uses session->tunnel to get the tunnel's encap. Add an encap arg to l2tp_session_set_header_len to avoid using session->tunnel. If l2tpv3 sessions have colliding IDs, it is possible for l2tp_v3_session_get to race with l2tp_session_register and fetch a session which doesn't yet have session->tunnel set. Add a check for this case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49941", "url": "https://ubuntu.com/security/CVE-2024-49941", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpiolib: Fix potential NULL pointer dereference in gpiod_get_label() In `gpiod_get_label()`, it is possible that `srcu_dereference_check()` may return a NULL pointer, leading to a scenario where `label->str` is accessed without verifying if `label` itself is NULL. This patch adds a proper NULL check for `label` before accessing `label->str`. The check for `label->str != NULL` is removed because `label->str` can never be NULL if `label` is not NULL. This fixes the issue where the label name was being printed as `(efault)` when dumping the sysfs GPIO file when `label == NULL`.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49996", "url": "https://ubuntu.com/security/CVE-2024-49996", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: Fix buffer overflow when parsing NFS reparse points ReparseDataLength is sum of the InodeType size and DataBuffer size. So to get DataBuffer size it is needed to subtract InodeType's size from ReparseDataLength. Function cifs_strndup_from_utf16() is currentlly accessing buf->DataBuffer at position after the end of the buffer because it does not subtract InodeType size from the length. Fix this problem and correctly subtract variable len. Member InodeType is present only when reparse buffer is large enough. Check for ReparseDataLength before accessing InodeType to prevent another invalid memory access. Major and minor rdev values are present also only when reparse buffer is large enough. Check for reparse buffer size before calling reparse_mkdev().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49942", "url": "https://ubuntu.com/security/CVE-2024-49942", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Prevent null pointer access in xe_migrate_copy xe_migrate_copy designed to copy content of TTM resources. When source resource is null, it will trigger a NULL pointer dereference in xe_migrate_copy. To avoid this situation, update lacks source flag to true for this case, the flag will trigger xe_migrate_clear rather than xe_migrate_copy. Issue trace: <7> [317.089847] xe 0000:00:02.0: [drm:xe_migrate_copy [xe]] Pass 14, sizes: 4194304 & 4194304 <7> [317.089945] xe 0000:00:02.0: [drm:xe_migrate_copy [xe]] Pass 15, sizes: 4194304 & 4194304 <1> [317.128055] BUG: kernel NULL pointer dereference, address: 0000000000000010 <1> [317.128064] #PF: supervisor read access in kernel mode <1> [317.128066] #PF: error_code(0x0000) - not-present page <6> [317.128069] PGD 0 P4D 0 <4> [317.128071] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI <4> [317.128074] CPU: 1 UID: 0 PID: 1440 Comm: kunit_try_catch Tainted: G U N 6.11.0-rc7-xe #1 <4> [317.128078] Tainted: [U]=USER, [N]=TEST <4> [317.128080] Hardware name: Intel Corporation Lunar Lake Client Platform/LNL-M LP5 RVP1, BIOS LNLMFWI1.R00.3221.D80.2407291239 07/29/2024 <4> [317.128082] RIP: 0010:xe_migrate_copy+0x66/0x13e0 [xe] <4> [317.128158] Code: 00 00 48 89 8d e0 fe ff ff 48 8b 40 10 4c 89 85 c8 fe ff ff 44 88 8d bd fe ff ff 65 48 8b 3c 25 28 00 00 00 48 89 7d d0 31 ff <8b> 79 10 48 89 85 a0 fe ff ff 48 8b 00 48 89 b5 d8 fe ff ff 83 ff <4> [317.128162] RSP: 0018:ffffc9000167f9f0 EFLAGS: 00010246 <4> [317.128164] RAX: ffff8881120d8028 RBX: ffff88814d070428 RCX: 0000000000000000 <4> [317.128166] RDX: ffff88813cb99c00 RSI: 0000000004000000 RDI: 0000000000000000 <4> [317.128168] RBP: ffffc9000167fbb8 R08: ffff88814e7b1f08 R09: 0000000000000001 <4> [317.128170] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88814e7b1f08 <4> [317.128172] R13: ffff88814e7b1f08 R14: ffff88813cb99c00 R15: 0000000000000001 <4> [317.128174] FS: 0000000000000000(0000) GS:ffff88846f280000(0000) knlGS:0000000000000000 <4> [317.128176] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [317.128178] CR2: 0000000000000010 CR3: 000000011f676004 CR4: 0000000000770ef0 <4> [317.128180] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 <4> [317.128182] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400 <4> [317.128184] PKRU: 55555554 <4> [317.128185] Call Trace: <4> [317.128187] <4> [317.128189] ? show_regs+0x67/0x70 <4> [317.128194] ? __die_body+0x20/0x70 <4> [317.128196] ? __die+0x2b/0x40 <4> [317.128198] ? page_fault_oops+0x15f/0x4e0 <4> [317.128203] ? do_user_addr_fault+0x3fb/0x970 <4> [317.128205] ? lock_acquire+0xc7/0x2e0 <4> [317.128209] ? exc_page_fault+0x87/0x2b0 <4> [317.128212] ? asm_exc_page_fault+0x27/0x30 <4> [317.128216] ? xe_migrate_copy+0x66/0x13e0 [xe] <4> [317.128263] ? __lock_acquire+0xb9d/0x26f0 <4> [317.128265] ? __lock_acquire+0xb9d/0x26f0 <4> [317.128267] ? sg_free_append_table+0x20/0x80 <4> [317.128271] ? lock_acquire+0xc7/0x2e0 <4> [317.128273] ? mark_held_locks+0x4d/0x80 <4> [317.128275] ? trace_hardirqs_on+0x1e/0xd0 <4> [317.128278] ? _raw_spin_unlock_irqrestore+0x31/0x60 <4> [317.128281] ? __pm_runtime_resume+0x60/0xa0 <4> [317.128284] xe_bo_move+0x682/0xc50 [xe] <4> [317.128315] ? lock_is_held_type+0xaa/0x120 <4> [317.128318] ttm_bo_handle_move_mem+0xe5/0x1a0 [ttm] <4> [317.128324] ttm_bo_validate+0xd1/0x1a0 [ttm] <4> [317.128328] shrink_test_run_device+0x721/0xc10 [xe] <4> [317.128360] ? find_held_lock+0x31/0x90 <4> [317.128363] ? lock_release+0xd1/0x2a0 <4> [317.128365] ? __pfx_kunit_generic_run_threadfn_adapter+0x10/0x10 [kunit] <4> [317.128370] xe_bo_shrink_kunit+0x11/0x20 [xe] <4> [317.128397] kunit_try_run_case+0x6e/0x150 [kunit] <4> [317.128400] ? trace_hardirqs_on+0x1e/0xd0 <4> [317.128402] ? _raw_spin_unlock_irqrestore+0x31/0x60 <4> [317.128404] kunit_generic_run_threadfn_adapter+0x1e/0x40 [ku ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49943", "url": "https://ubuntu.com/security/CVE-2024-49943", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc_submit: add missing locking in wedged_fini Any non-wedged queue can have a zero refcount here and can be running concurrently with an async queue destroy, therefore dereferencing the queue ptr to check wedge status after the lookup can trigger UAF if queue is not wedged. Fix this by keeping the submission_state lock held around the check to postpone the free and make the check safe, before dropping again around the put() to avoid the deadlock. (cherry picked from commit d28af0b6b9580b9f90c265a7da0315b0ad20bbfd)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50011", "url": "https://ubuntu.com/security/CVE-2024-50011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: soc-acpi-intel-rpl-match: add missing empty item There is no links_num in struct snd_soc_acpi_mach {}, and we test !link->num_adr as a condition to end the loop in hda_sdw_machine_select(). So an empty item in struct snd_soc_acpi_link_adr array is required.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50174", "url": "https://ubuntu.com/security/CVE-2024-50174", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix race when converting group handle to group object XArray provides it's own internal lock which protects the internal array when entries are being simultaneously added and removed. However there is still a race between retrieving the pointer from the XArray and incrementing the reference count. To avoid this race simply hold the internal XArray lock when incrementing the reference count, this ensures there cannot be a racing call to xa_erase().", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49944", "url": "https://ubuntu.com/security/CVE-2024-49944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_start In sctp_listen_start() invoked by sctp_inet_listen(), it should set the sk_state back to CLOSED if sctp_autobind() fails due to whatever reason. Otherwise, next time when calling sctp_inet_listen(), if sctp_sk(sk)->reuse is already set via setsockopt(SCTP_REUSE_PORT), sctp_sk(sk)->bind_hash will be dereferenced as sk_state is LISTENING, which causes a crash as bind_hash is NULL. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:sctp_inet_listen+0x7f0/0xa20 net/sctp/socket.c:8617 Call Trace: __sys_listen_socket net/socket.c:1883 [inline] __sys_listen+0x1b7/0x230 net/socket.c:1894 __do_sys_listen net/socket.c:1902 [inline]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49945", "url": "https://ubuntu.com/security/CVE-2024-49945", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/ncsi: Disable the ncsi work before freeing the associated structure The work function can run after the ncsi device is freed, resulting in use-after-free bugs or kernel panic.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49946", "url": "https://ubuntu.com/security/CVE-2024-49946", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: do not assume bh is held in ppp_channel_bridge_input() Networking receive path is usually handled from BH handler. However, some protocols need to acquire the socket lock, and packets might be stored in the socket backlog is the socket was owned by a user process. In this case, release_sock(), __release_sock(), and sk_backlog_rcv() might call the sk->sk_backlog_rcv() handler in process context. sybot caught ppp was not considering this case in ppp_channel_bridge_input() : WARNING: inconsistent lock state 6.11.0-rc7-syzkaller-g5f5673607153 #0 Not tainted -------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. ksoftirqd/1/24 [HC0[0]:SC1[1]:HE1:SE0] takes: ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 {SOFTIRQ-ON-W} state was registered at: lock_acquire+0x240/0x728 kernel/locking/lockdep.c:5759 __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline] _raw_spin_lock+0x48/0x60 kernel/locking/spinlock.c:154 spin_lock include/linux/spinlock.h:351 [inline] ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline] ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0xfc/0x314 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv include/net/sock.h:1111 [inline] __release_sock+0x1a8/0x3d8 net/core/sock.c:3004 release_sock+0x68/0x1b8 net/core/sock.c:3558 pppoe_sendmsg+0xc8/0x5d8 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x374/0x4f4 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __arm64_sys_sendto+0xd8/0xf8 net/socket.c:2212 __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:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 irq event stamp: 282914 hardirqs last enabled at (282914): [] __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:151 [inline] hardirqs last enabled at (282914): [] _raw_spin_unlock_irqrestore+0x38/0x98 kernel/locking/spinlock.c:194 hardirqs last disabled at (282913): [] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline] hardirqs last disabled at (282913): [] _raw_spin_lock_irqsave+0x2c/0x7c kernel/locking/spinlock.c:162 softirqs last enabled at (282904): [] softirq_handle_end kernel/softirq.c:400 [inline] softirqs last enabled at (282904): [] handle_softirqs+0xa3c/0xbfc kernel/softirq.c:582 softirqs last disabled at (282909): [] run_ksoftirqd+0x70/0x158 kernel/softirq.c:928 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&pch->downl); lock(&pch->downl); *** DEADLOCK *** 1 lock held by ksoftirqd/1/24: #0: ffff80008f74dfa0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire+0x10/0x4c include/linux/rcupdate.h:325 stack backtrace: CPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 6.11.0-rc7-syzkaller-g5f5673607153 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call trace: dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:319 show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:326 __dump_sta ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49947", "url": "https://ubuntu.com/security/CVE-2024-49947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: test for not too small csum_start in virtio_net_hdr_to_skb() syzbot was able to trigger this warning [1], after injecting a malicious packet through af_packet, setting skb->csum_start and thus the transport header to an incorrect value. We can at least make sure the transport header is after the end of the network header (with a estimated minimal size). [1] [ 67.873027] skb len=4096 headroom=16 headlen=14 tailroom=0 mac=(-1,-1) mac_len=0 net=(16,-6) trans=10 shinfo(txflags=0 nr_frags=1 gso(size=0 type=0 segs=0)) csum(0xa start=10 offset=0 ip_summed=3 complete_sw=0 valid=0 level=0) hash(0x0 sw=0 l4=0) proto=0x0800 pkttype=0 iif=0 priority=0x0 mark=0x0 alloc_cpu=10 vlan_all=0x0 encapsulation=0 inner(proto=0x0000, mac=0, net=0, trans=0) [ 67.877172] dev name=veth0_vlan feat=0x000061164fdd09e9 [ 67.877764] sk family=17 type=3 proto=0 [ 67.878279] skb linear: 00000000: 00 00 10 00 00 00 00 00 0f 00 00 00 08 00 [ 67.879128] skb frag: 00000000: 0e 00 07 00 00 00 28 00 08 80 1c 00 04 00 00 02 [ 67.879877] skb frag: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.880647] skb frag: 00000020: 00 00 02 00 00 00 08 00 1b 00 00 00 00 00 00 00 [ 67.881156] skb frag: 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.881753] skb frag: 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.882173] skb frag: 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.882790] skb frag: 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.883171] skb frag: 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.883733] skb frag: 00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.884206] skb frag: 00000090: 00 00 00 00 00 00 00 00 00 00 69 70 76 6c 61 6e [ 67.884704] skb frag: 000000a0: 31 00 00 00 00 00 00 00 00 00 2b 00 00 00 00 00 [ 67.885139] skb frag: 000000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.885677] skb frag: 000000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.886042] skb frag: 000000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.886408] skb frag: 000000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.887020] skb frag: 000000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.887384] skb frag: 00000100: 00 00 [ 67.887878] ------------[ cut here ]------------ [ 67.887908] offset (-6) >= skb_headlen() (14) [ 67.888445] WARNING: CPU: 10 PID: 2088 at net/core/dev.c:3332 skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.889353] Modules linked in: macsec macvtap macvlan hsr wireguard curve25519_x86_64 libcurve25519_generic libchacha20poly1305 chacha_x86_64 libchacha poly1305_x86_64 dummy bridge sr_mod cdrom evdev pcspkr i2c_piix4 9pnet_virtio 9p 9pnet netfs [ 67.890111] CPU: 10 UID: 0 PID: 2088 Comm: b363492833 Not tainted 6.11.0-virtme #1011 [ 67.890183] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 67.890309] RIP: 0010:skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891043] Call Trace: [ 67.891173] [ 67.891274] ? __warn (kernel/panic.c:741) [ 67.891320] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891333] ? report_bug (lib/bug.c:180 lib/bug.c:219) [ 67.891348] ? handle_bug (arch/x86/kernel/traps.c:239) [ 67.891363] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) [ 67.891372] ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621) [ 67.891388] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891399] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891416] ip_do_fragment (net/ipv4/ip_output.c:777 (discriminator 1)) [ 67.891448] ? __ip_local_out (./include/linux/skbuff.h:1146 ./include/net/l3mdev.h:196 ./include/net/l3mdev.h:213 ne ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49948", "url": "https://ubuntu.com/security/CVE-2024-49948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: add more sanity checks to qdisc_pkt_len_init() One path takes care of SKB_GSO_DODGY, assuming skb->len is bigger than hdr_len. virtio_net_hdr_to_skb() does not fully dissect TCP headers, it only make sure it is at least 20 bytes. It is possible for an user to provide a malicious 'GSO' packet, total length of 80 bytes. - 20 bytes of IPv4 header - 60 bytes TCP header - a small gso_size like 8 virtio_net_hdr_to_skb() would declare this packet as a normal GSO packet, because it would see 40 bytes of payload, bigger than gso_size. We need to make detect this case to not underflow qdisc_skb_cb(skb)->pkt_len.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49949", "url": "https://ubuntu.com/security/CVE-2024-49949", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: avoid potential underflow in qdisc_pkt_len_init() with UFO After commit 7c6d2ecbda83 (\"net: be more gentle about silly gso requests coming from user\") virtio_net_hdr_to_skb() had sanity check to detect malicious attempts from user space to cook a bad GSO packet. Then commit cf9acc90c80ec (\"net: virtio_net_hdr_to_skb: count transport header in UFO\") while fixing one issue, allowed user space to cook a GSO packet with the following characteristic : IPv4 SKB_GSO_UDP, gso_size=3, skb->len = 28. When this packet arrives in qdisc_pkt_len_init(), we end up with hdr_len = 28 (IPv4 header + UDP header), matching skb->len Then the following sets gso_segs to 0 : gso_segs = DIV_ROUND_UP(skb->len - hdr_len, shinfo->gso_size); Then later we set qdisc_skb_cb(skb)->pkt_len to back to zero :/ qdisc_skb_cb(skb)->pkt_len += (gso_segs - 1) * hdr_len; This leads to the following crash in fq_codel [1] qdisc_pkt_len_init() is best effort, we only want an estimation of the bytes sent on the wire, not crashing the kernel. This patch is fixing this particular issue, a following one adds more sanity checks for another potential bug. [1] [ 70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 70.724561] #PF: supervisor read access in kernel mode [ 70.724561] #PF: error_code(0x0000) - not-present page [ 70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0 [ 70.724561] Oops: Oops: 0000 [#1] SMP NOPTI [ 70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991 [ 70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel [ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 <49> 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49 All code ======== 0:\t24 08 \tand $0x8,%al 2:\t49 c1 e1 06 \tshl $0x6,%r9 6:\t44 89 7c 24 18 \tmov %r15d,0x18(%rsp) b:\t45 31 ed \txor %r13d,%r13d e:\t45 31 c0 \txor %r8d,%r8d 11:\t31 ff \txor %edi,%edi 13:\t89 44 24 14 \tmov %eax,0x14(%rsp) 17:\t4c 03 8b 90 01 00 00 \tadd 0x190(%rbx),%r9 1e:\teb 04 \tjmp 0x24 20:\t39 ca \tcmp %ecx,%edx 22:\t73 37 \tjae 0x5b 24:\t4d 8b 39 \tmov (%r9),%r15 27:\t83 c7 01 \tadd $0x1,%edi 2a:*\t49 8b 17 \tmov (%r15),%rdx\t\t<-- trapping instruction 2d:\t49 89 11 \tmov %rdx,(%r9) 30:\t41 8b 57 28 \tmov 0x28(%r15),%edx 34:\t45 8b 5f 34 \tmov 0x34(%r15),%r11d 38:\t49 c7 07 00 00 00 00 \tmovq $0x0,(%r15) 3f:\t49 \trex.WB Code starting with the faulting instruction =========================================== 0:\t49 8b 17 \tmov (%r15),%rdx 3:\t49 89 11 \tmov %rdx,(%r9) 6:\t41 8b 57 28 \tmov 0x28(%r15),%edx a:\t45 8b 5f 34 \tmov 0x34(%r15),%r11d e:\t49 c7 07 00 00 00 00 \tmovq $0x0,(%r15) 15:\t49 \trex.WB [ 70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202 [ 70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000 [ 70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001 [ 70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000 [ 70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58 [ 70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000 [ 70.724561] FS: 000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000 [ 70.724561] CS: 0010 DS: 0000 ES: 0000 C ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49997", "url": "https://ubuntu.com/security/CVE-2024-49997", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: lantiq_etop: fix memory disclosure When applying padding, the buffer is not zeroed, which results in memory disclosure. The mentioned data is observed on the wire. This patch uses skb_put_padto() to pad Ethernet frames properly. The mentioned function zeroes the expanded buffer. In case the packet cannot be padded it is silently dropped. Statistics are also not incremented. This driver does not support statistics in the old 32-bit format or the new 64-bit format. These will be added in the future. In its current form, the patch should be easily backported to stable versions. Ethernet MACs on Amazon-SE and Danube cannot do padding of the packets in hardware, so software padding must be applied.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49998", "url": "https://ubuntu.com/security/CVE-2024-49998", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: improve shutdown sequence Alexander Sverdlin presents 2 problems during shutdown with the lan9303 driver. One is specific to lan9303 and the other just happens to reproduce there. The first problem is that lan9303 is unique among DSA drivers in that it calls dev_get_drvdata() at \"arbitrary runtime\" (not probe, not shutdown, not remove): phy_state_machine() -> ... -> dsa_user_phy_read() -> ds->ops->phy_read() -> lan9303_phy_read() -> chip->ops->phy_read() -> lan9303_mdio_phy_read() -> dev_get_drvdata() But we never stop the phy_state_machine(), so it may continue to run after dsa_switch_shutdown(). Our common pattern in all DSA drivers is to set drvdata to NULL to suppress the remove() method that may come afterwards. But in this case it will result in an NPD. The second problem is that the way in which we set dp->conduit->dsa_ptr = NULL; is concurrent with receive packet processing. dsa_switch_rcv() checks once whether dev->dsa_ptr is NULL, but afterwards, rather than continuing to use that non-NULL value, dev->dsa_ptr is dereferenced again and again without NULL checks: dsa_conduit_find_user() and many other places. In between dereferences, there is no locking to ensure that what was valid once continues to be valid. Both problems have the common aspect that closing the conduit interface solves them. In the first case, dev_close(conduit) triggers the NETDEV_GOING_DOWN event in dsa_user_netdevice_event() which closes user ports as well. dsa_port_disable_rt() calls phylink_stop(), which synchronously stops the phylink state machine, and ds->ops->phy_read() will thus no longer call into the driver after this point. In the second case, dev_close(conduit) should do this, as per Documentation/networking/driver.rst: | Quiescence | ---------- | | After the ndo_stop routine has been called, the hardware must | not receive or transmit any data. All in flight packets must | be aborted. If necessary, poll or wait for completion of | any reset commands. So it should be sufficient to ensure that later, when we zeroize conduit->dsa_ptr, there will be no concurrent dsa_switch_rcv() call on this conduit. The addition of the netif_device_detach() function is to ensure that ioctls, rtnetlinks and ethtool requests on the user ports no longer propagate down to the driver - we're no longer prepared to handle them. The race condition actually did not exist when commit 0650bf52b31f (\"net: dsa: be compatible with masters which unregister on shutdown\") first introduced dsa_switch_shutdown(). It was created later, when we stopped unregistering the user interfaces from a bad spot, and we just replaced that sequence with a racy zeroization of conduit->dsa_ptr (one which doesn't ensure that the interfaces aren't up).", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49999", "url": "https://ubuntu.com/security/CVE-2024-49999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix the setting of the server responding flag In afs_wait_for_operation(), we set transcribe the call responded flag to the server record that we used after doing the fileserver iteration loop - but it's possible to exit the loop having had a response from the server that we've discarded (e.g. it returned an abort or we started receiving data, but the call didn't complete). This means that op->server might be NULL, but we don't check that before attempting to set the server flag.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49950", "url": "https://ubuntu.com/security/CVE-2024-49950", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix uaf in l2cap_connect [Syzbot reported] BUG: KASAN: slab-use-after-free in l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 Read of size 8 at addr ffff8880241e9800 by task kworker/u9:0/54 CPU: 0 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-00268-g788220eee30d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Workqueue: hci2 hci_rx_work Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 l2cap_connect_req net/bluetooth/l2cap_core.c:4080 [inline] l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:4772 [inline] l2cap_sig_channel net/bluetooth/l2cap_core.c:5543 [inline] l2cap_recv_frame+0xf0b/0x8eb0 net/bluetooth/l2cap_core.c:6825 l2cap_recv_acldata+0x9b4/0xb70 net/bluetooth/l2cap_core.c:7514 hci_acldata_packet net/bluetooth/hci_core.c:3791 [inline] hci_rx_work+0xaab/0x1610 net/bluetooth/hci_core.c:4028 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 ... Freed by task 5245: 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:579 poison_slab_object+0xf7/0x160 mm/kasan/common.c:240 __kasan_slab_free+0x32/0x50 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2256 [inline] slab_free mm/slub.c:4477 [inline] kfree+0x12a/0x3b0 mm/slub.c:4598 l2cap_conn_free net/bluetooth/l2cap_core.c:1810 [inline] kref_put include/linux/kref.h:65 [inline] l2cap_conn_put net/bluetooth/l2cap_core.c:1822 [inline] l2cap_conn_del+0x59d/0x730 net/bluetooth/l2cap_core.c:1802 l2cap_connect_cfm+0x9e6/0xf80 net/bluetooth/l2cap_core.c:7241 hci_connect_cfm include/net/bluetooth/hci_core.h:1960 [inline] hci_conn_failed+0x1c3/0x370 net/bluetooth/hci_conn.c:1265 hci_abort_conn_sync+0x75a/0xb50 net/bluetooth/hci_sync.c:5583 abort_conn_sync+0x197/0x360 net/bluetooth/hci_conn.c:2917 hci_cmd_sync_work+0x1a4/0x410 net/bluetooth/hci_sync.c:328 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49951", "url": "https://ubuntu.com/security/CVE-2024-49951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Fix possible crash on mgmt_index_removed If mgmt_index_removed is called while there are commands queued on cmd_sync it could lead to crashes like the bellow trace: 0x0000053D: __list_del_entry_valid_or_report+0x98/0xdc 0x0000053D: mgmt_pending_remove+0x18/0x58 [bluetooth] 0x0000053E: mgmt_remove_adv_monitor_complete+0x80/0x108 [bluetooth] 0x0000053E: hci_cmd_sync_work+0xbc/0x164 [bluetooth] So while handling mgmt_index_removed this attempts to dequeue commands passed as user_data to cmd_sync.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49952", "url": "https://ubuntu.com/security/CVE-2024-49952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: prevent nf_skb_duplicated corruption syzbot found that nf_dup_ipv4() or nf_dup_ipv6() could write per-cpu variable nf_skb_duplicated in an unsafe way [1]. Disabling preemption as hinted by the splat is not enough, we have to disable soft interrupts as well. [1] BUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316 caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49 nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook+0x2c4/0x450 include/linux/netfilter.h:269 NF_HOOK_COND include/linux/netfilter.h:302 [inline] ip_output+0x185/0x230 net/ipv4/ip_output.c:433 ip_local_out net/ipv4/ip_output.c:129 [inline] ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495 udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981 udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737 __do_sys_sendmmsg net/socket.c:2766 [inline] __se_sys_sendmmsg net/socket.c:2763 [inline] __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763 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:0x7f4ce4f7def9 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:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9 RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006 RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49953", "url": "https://ubuntu.com/security/CVE-2024-49953", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix crash caused by calling __xfrm_state_delete() twice The km.state is not checked in driver's delayed work. When xfrm_state_check_expire() is called, the state can be reset to XFRM_STATE_EXPIRED, even if it is XFRM_STATE_DEAD already. This happens when xfrm state is deleted, but not freed yet. As __xfrm_state_delete() is called again in xfrm timer, the following crash occurs. To fix this issue, skip xfrm_state_check_expire() if km.state is not XFRM_STATE_VALID. Oops: general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] SMP CPU: 5 UID: 0 PID: 7448 Comm: kworker/u102:2 Not tainted 6.11.0-rc2+ #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5e_ipsec: eth%d mlx5e_ipsec_handle_sw_limits [mlx5_core] RIP: 0010:__xfrm_state_delete+0x3d/0x1b0 Code: 0f 84 8b 01 00 00 48 89 fd c6 87 c8 00 00 00 05 48 8d bb 40 10 00 00 e8 11 04 1a 00 48 8b 95 b8 00 00 00 48 8b 85 c0 00 00 00 <48> 89 42 08 48 89 10 48 8b 55 10 48 b8 00 01 00 00 00 00 ad de 48 RSP: 0018:ffff88885f945ec8 EFLAGS: 00010246 RAX: dead000000000122 RBX: ffffffff82afa940 RCX: 0000000000000036 RDX: dead000000000100 RSI: 0000000000000000 RDI: ffffffff82afb980 RBP: ffff888109a20340 R08: ffff88885f945ea0 R09: 0000000000000000 R10: 0000000000000000 R11: ffff88885f945ff8 R12: 0000000000000246 R13: ffff888109a20340 R14: ffff88885f95f420 R15: ffff88885f95f400 FS: 0000000000000000(0000) GS:ffff88885f940000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2163102430 CR3: 00000001128d6001 CR4: 0000000000370eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? die_addr+0x33/0x90 ? exc_general_protection+0x1a2/0x390 ? asm_exc_general_protection+0x22/0x30 ? __xfrm_state_delete+0x3d/0x1b0 ? __xfrm_state_delete+0x2f/0x1b0 xfrm_timer_handler+0x174/0x350 ? __xfrm_state_delete+0x1b0/0x1b0 __hrtimer_run_queues+0x121/0x270 hrtimer_run_softirq+0x88/0xd0 handle_softirqs+0xcc/0x270 do_softirq+0x3c/0x50 __local_bh_enable_ip+0x47/0x50 mlx5e_ipsec_handle_sw_limits+0x7d/0x90 [mlx5_core] process_one_work+0x137/0x2d0 worker_thread+0x28d/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50000", "url": "https://ubuntu.com/security/CVE-2024-50000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix NULL deref in mlx5e_tir_builder_alloc() In mlx5e_tir_builder_alloc() kvzalloc() may return NULL which is dereferenced on the next line in a reference to the modify field. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50001", "url": "https://ubuntu.com/security/CVE-2024-50001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix error path in multi-packet WQE transmit Remove the erroneous unmap in case no DMA mapping was established The multi-packet WQE transmit code attempts to obtain a DMA mapping for the skb. This could fail, e.g. under memory pressure, when the IOMMU driver just can't allocate more memory for page tables. While the code tries to handle this in the path below the err_unmap label it erroneously unmaps one entry from the sq's FIFO list of active mappings. Since the current map attempt failed this unmap is removing some random DMA mapping that might still be required. If the PCI function now presents that IOVA, the IOMMU may assumes a rogue DMA access and e.g. on s390 puts the PCI function in error state. The erroneous behavior was seen in a stress-test environment that created memory pressure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50179", "url": "https://ubuntu.com/security/CVE-2024-50179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: remove the incorrect Fw reference check when dirtying pages When doing the direct-io reads it will also try to mark pages dirty, but for the read path it won't hold the Fw caps and there is case will it get the Fw reference.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49963", "url": "https://ubuntu.com/security/CVE-2024-49963", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mailbox: bcm2835: Fix timeout during suspend mode During noirq suspend phase the Raspberry Pi power driver suffer of firmware property timeouts. The reason is that the IRQ of the underlying BCM2835 mailbox is disabled and rpi_firmware_property_list() will always run into a timeout [1]. Since the VideoCore side isn't consider as a wakeup source, set the IRQF_NO_SUSPEND flag for the mailbox IRQ in order to keep it enabled during suspend-resume cycle. [1] PM: late suspend of devices complete after 1.754 msecs WARNING: CPU: 0 PID: 438 at drivers/firmware/raspberrypi.c:128 rpi_firmware_property_list+0x204/0x22c Firmware transaction 0x00028001 timeout Modules linked in: CPU: 0 PID: 438 Comm: bash Tainted: G C 6.9.3-dirty #17 Hardware name: BCM2835 Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x44 dump_stack_lvl from __warn+0x88/0xec __warn from warn_slowpath_fmt+0x7c/0xb0 warn_slowpath_fmt from rpi_firmware_property_list+0x204/0x22c rpi_firmware_property_list from rpi_firmware_property+0x68/0x8c rpi_firmware_property from rpi_firmware_set_power+0x54/0xc0 rpi_firmware_set_power from _genpd_power_off+0xe4/0x148 _genpd_power_off from genpd_sync_power_off+0x7c/0x11c genpd_sync_power_off from genpd_finish_suspend+0xcc/0xe0 genpd_finish_suspend from dpm_run_callback+0x78/0xd0 dpm_run_callback from device_suspend_noirq+0xc0/0x238 device_suspend_noirq from dpm_suspend_noirq+0xb0/0x168 dpm_suspend_noirq from suspend_devices_and_enter+0x1b8/0x5ac suspend_devices_and_enter from pm_suspend+0x254/0x2e4 pm_suspend from state_store+0xa8/0xd4 state_store from kernfs_fop_write_iter+0x154/0x1a0 kernfs_fop_write_iter from vfs_write+0x12c/0x184 vfs_write from ksys_write+0x78/0xc0 ksys_write from ret_fast_syscall+0x0/0x54 Exception stack(0xcc93dfa8 to 0xcc93dff0) [...] PM: noirq suspend of devices complete after 3095.584 msecs", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49954", "url": "https://ubuntu.com/security/CVE-2024-49954", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: static_call: Replace pointless WARN_ON() in static_call_module_notify() static_call_module_notify() triggers a WARN_ON(), when memory allocation fails in __static_call_add_module(). That's not really justified, because the failure case must be correctly handled by the well known call chain and the error code is passed through to the initiating userspace application. A memory allocation fail is not a fatal problem, but the WARN_ON() takes the machine out when panic_on_warn is set. Replace it with a pr_warn().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50002", "url": "https://ubuntu.com/security/CVE-2024-50002", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: static_call: Handle module init failure correctly in static_call_del_module() Module insertion invokes static_call_add_module() to initialize the static calls in a module. static_call_add_module() invokes __static_call_init(), which allocates a struct static_call_mod to either encapsulate the built-in static call sites of the associated key into it so further modules can be added or to append the module to the module chain. If that allocation fails the function returns with an error code and the module core invokes static_call_del_module() to clean up eventually added static_call_mod entries. This works correctly, when all keys used by the module were converted over to a module chain before the failure. If not then static_call_del_module() causes a #GP as it blindly assumes that key::mods points to a valid struct static_call_mod. The problem is that key::mods is not a individual struct member of struct static_call_key, it's part of a union to save space: union { /* bit 0: 0 = mods, 1 = sites */ unsigned long type; struct static_call_mod *mods; struct static_call_site *sites; \t}; key::sites is a pointer to the list of built-in usage sites of the static call. The type of the pointer is differentiated by bit 0. A mods pointer has the bit clear, the sites pointer has the bit set. As static_call_del_module() blidly assumes that the pointer is a valid static_call_mod type, it fails to check for this failure case and dereferences the pointer to the list of built-in call sites, which is obviously bogus. Cure it by checking whether the key has a sites or a mods pointer. If it's a sites pointer then the key is not to be touched. As the sites are walked in the same order as in __static_call_init() the site walk can be terminated because all subsequent sites have not been touched by the init code due to the error exit. If it was converted before the allocation fail, then the inner loop which searches for a module match will find nothing. A fail in the second allocation in __static_call_init() is harmless and does not require special treatment. The first allocation succeeded and converted the key to a module chain. That first entry has mod::mod == NULL and mod::next == NULL, so the inner loop of static_call_del_module() will neither find a module match nor a module chain. The next site in the walk was either already converted, but can't match the module, or it will exit the outer loop because it has a static_call_site pointer and not a static_call_mod pointer.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-47675", "url": "https://ubuntu.com/security/CVE-2024-47675", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix use-after-free in bpf_uprobe_multi_link_attach() If bpf_link_prime() fails, bpf_uprobe_multi_link_attach() goes to the error_free label and frees the array of bpf_uprobe's without calling bpf_uprobe_unregister(). This leaks bpf_uprobe->uprobe and worse, this frees bpf_uprobe->consumer without removing it from the uprobe->consumers list.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47676", "url": "https://ubuntu.com/security/CVE-2024-47676", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb.c: fix UAF of vma in hugetlb fault pathway Syzbot reports a UAF in hugetlb_fault(). This happens because vmf_anon_prepare() could drop the per-VMA lock and allow the current VMA to be freed before hugetlb_vma_unlock_read() is called. We can fix this by using a modified version of vmf_anon_prepare() that doesn't release the VMA lock on failure, and then release it ourselves after hugetlb_vma_unlock_read().", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47677", "url": "https://ubuntu.com/security/CVE-2024-47677", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: resolve memory leak from exfat_create_upcase_table() If exfat_load_upcase_table reaches end and returns -EINVAL, allocated memory doesn't get freed and while exfat_load_default_upcase_table allocates more memory, leading to a memory leak. Here's link to syzkaller crash report illustrating this issue: https://syzkaller.appspot.com/text?tag=CrashReport&x=1406c201980000", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47725", "url": "https://ubuntu.com/security/CVE-2024-47725", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47739", "url": "https://ubuntu.com/security/CVE-2024-47739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: padata: use integer wrap around to prevent deadlock on seq_nr overflow When submitting more than 2^32 padata objects to padata_do_serial, the current sorting implementation incorrectly sorts padata objects with overflowed seq_nr, causing them to be placed before existing objects in the reorder list. This leads to a deadlock in the serialization process as padata_find_next cannot match padata->seq_nr and pd->processed because the padata instance with overflowed seq_nr will be selected next. To fix this, we use an unsigned integer wrap around to correctly sort padata objects in scenarios with integer overflow.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47678", "url": "https://ubuntu.com/security/CVE-2024-47678", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: icmp: change the order of rate limits ICMP messages are ratelimited : After the blamed commits, the two rate limiters are applied in this order: 1) host wide ratelimit (icmp_global_allow()) 2) Per destination ratelimit (inetpeer based) In order to avoid side-channels attacks, we need to apply the per destination check first. This patch makes the following change : 1) icmp_global_allow() checks if the host wide limit is reached. But credits are not yet consumed. This is deferred to 3) 2) The per destination limit is checked/updated. This might add a new node in inetpeer tree. 3) icmp_global_consume() consumes tokens if prior operations succeeded. This means that host wide ratelimit is still effective in keeping inetpeer tree small even under DDOS. As a bonus, I removed icmp_global.lock as the fast path can use a lock-free operation.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47733", "url": "https://ubuntu.com/security/CVE-2024-47733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfs: Delete subtree of 'fs/netfs' when netfs module exits In netfs_init() or fscache_proc_init(), we create dentry under 'fs/netfs', but in netfs_exit(), we only delete the proc entry of 'fs/netfs' without deleting its subtree. This triggers the following WARNING: ================================================================== remove_proc_entry: removing non-empty directory 'fs/netfs', leaking at least 'requests' WARNING: CPU: 4 PID: 566 at fs/proc/generic.c:717 remove_proc_entry+0x160/0x1c0 Modules linked in: netfs(-) CPU: 4 UID: 0 PID: 566 Comm: rmmod Not tainted 6.11.0-rc3 #860 RIP: 0010:remove_proc_entry+0x160/0x1c0 Call Trace: netfs_exit+0x12/0x620 [netfs] __do_sys_delete_module.isra.0+0x14c/0x2e0 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e ================================================================== Therefore use remove_proc_subtree() instead of remove_proc_entry() to fix the above problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47679", "url": "https://ubuntu.com/security/CVE-2024-47679", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfs: fix race between evice_inodes() and find_inode()&iput() Hi, all Recently I noticed a bug[1] in btrfs, after digged it into and I believe it'a race in vfs. Let's assume there's a inode (ie ino 261) with i_count 1 is called by iput(), and there's a concurrent thread calling generic_shutdown_super(). cpu0: cpu1: iput() // i_count is 1 ->spin_lock(inode) ->dec i_count to 0 ->iput_final() generic_shutdown_super() ->__inode_add_lru() ->evict_inodes() // cause some reason[2] ->if (atomic_read(inode->i_count)) continue; // return before // inode 261 passed the above check // list_lru_add_obj() // and then schedule out ->spin_unlock() // note here: the inode 261 // was still at sb list and hash list, // and I_FREEING|I_WILL_FREE was not been set btrfs_iget() // after some function calls ->find_inode() // found the above inode 261 ->spin_lock(inode) // check I_FREEING|I_WILL_FREE // and passed ->__iget() ->spin_unlock(inode) // schedule back ->spin_lock(inode) // check (I_NEW|I_FREEING|I_WILL_FREE) flags, // passed and set I_FREEING iput() ->spin_unlock(inode) ->spin_lock(inode)\t\t\t ->evict() // dec i_count to 0 ->iput_final() ->spin_unlock() ->evict() Now, we have two threads simultaneously evicting the same inode, which may trigger the BUG(inode->i_state & I_CLEAR) statement both within clear_inode() and iput(). To fix the bug, recheck the inode->i_count after holding i_lock. Because in the most scenarios, the first check is valid, and the overhead of spin_lock() can be reduced. If there is any misunderstanding, please let me know, thanks. [1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/ [2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable() return false when I reproduced the bug.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49859", "url": "https://ubuntu.com/security/CVE-2024-49859", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to check atomic_file in f2fs ioctl interfaces Some f2fs ioctl interfaces like f2fs_ioc_set_pin_file(), f2fs_move_file_range(), and f2fs_defragment_range() missed to check atomic_write status, which may cause potential race issue, fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47680", "url": "https://ubuntu.com/security/CVE-2024-47680", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: check discard support for conventional zones As the helper function f2fs_bdev_support_discard() shows, f2fs checks if the target block devices support discard by calling bdev_max_discard_sectors() and bdev_is_zoned(). This check works well for most cases, but it does not work for conventional zones on zoned block devices. F2fs assumes that zoned block devices support discard, and calls __submit_discard_cmd(). When __submit_discard_cmd() is called for sequential write required zones, it works fine since __submit_discard_cmd() issues zone reset commands instead of discard commands. However, when __submit_discard_cmd() is called for conventional zones, __blkdev_issue_discard() is called even when the devices do not support discard. The inappropriate __blkdev_issue_discard() call was not a problem before the commit 30f1e7241422 (\"block: move discard checks into the ioctl handler\") because __blkdev_issue_discard() checked if the target devices support discard or not. If not, it returned EOPNOTSUPP. After the commit, __blkdev_issue_discard() no longer checks it. It always returns zero and sets NULL to the given bio pointer. This NULL pointer triggers f2fs_bug_on() in __submit_discard_cmd(). The BUG is recreated with the commands below at the umount step, where /dev/nullb0 is a zoned null_blk with 5GB total size, 128MB zone size and 10 conventional zones. $ mkfs.f2fs -f -m /dev/nullb0 $ mount /dev/nullb0 /mnt $ for ((i=0;i<5;i++)); do dd if=/dev/zero of=/mnt/test bs=65536 count=1600 conv=fsync; done $ umount /mnt To fix the BUG, avoid the inappropriate __blkdev_issue_discard() call. When discard is requested for conventional zones, check if the device supports discard or not. If not, return EOPNOTSUPP.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47740", "url": "https://ubuntu.com/security/CVE-2024-47740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: Require FMODE_WRITE for atomic write ioctls The F2FS ioctls for starting and committing atomic writes check for inode_owner_or_capable(), but this does not give LSMs like SELinux or Landlock an opportunity to deny the write access - if the caller's FSUID matches the inode's UID, inode_owner_or_capable() immediately returns true. There are scenarios where LSMs want to deny a process the ability to write particular files, even files that the FSUID of the process owns; but this can currently partially be bypassed using atomic write ioctls in two ways: - F2FS_IOC_START_ATOMIC_REPLACE + F2FS_IOC_COMMIT_ATOMIC_WRITE can truncate an inode to size 0 - F2FS_IOC_START_ATOMIC_WRITE + F2FS_IOC_ABORT_ATOMIC_WRITE can revert changes another process concurrently made to a file Fix it by requiring FMODE_WRITE for these operations, just like for F2FS_IOC_MOVE_RANGE. Since any legitimate caller should only be using these ioctls when intending to write into the file, that seems unlikely to break anything.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47726", "url": "https://ubuntu.com/security/CVE-2024-47726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to wait dio completion It should wait all existing dio write IOs before block removal, otherwise, previous direct write IO may overwrite data in the block which may be reused by other inode.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47741", "url": "https://ubuntu.com/security/CVE-2024-47741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race setting file private on concurrent lseek using same fd When doing concurrent lseek(2) system calls against the same file descriptor, using multiple threads belonging to the same process, we have a short time window where a race happens and can result in a memory leak. The race happens like this: 1) A program opens a file descriptor for a file and then spawns two threads (with the pthreads library for example), lets call them task A and task B; 2) Task A calls lseek with SEEK_DATA or SEEK_HOLE and ends up at file.c:find_desired_extent() while holding a read lock on the inode; 3) At the start of find_desired_extent(), it extracts the file's private_data pointer into a local variable named 'private', which has a value of NULL; 4) Task B also calls lseek with SEEK_DATA or SEEK_HOLE, locks the inode in shared mode and enters file.c:find_desired_extent(), where it also extracts file->private_data into its local variable 'private', which has a NULL value; 5) Because it saw a NULL file private, task A allocates a private structure and assigns to the file structure; 6) Task B also saw a NULL file private so it also allocates its own file private and then assigns it to the same file structure, since both tasks are using the same file descriptor. At this point we leak the private structure allocated by task A. Besides the memory leak, there's also the detail that both tasks end up using the same cached state record in the private structure (struct btrfs_file_private::llseek_cached_state), which can result in a use-after-free problem since one task can free it while the other is still using it (only one task took a reference count on it). Also, sharing the cached state is not a good idea since it could result in incorrect results in the future - right now it should not be a problem because it end ups being used only in extent-io-tree.c:count_range_bits() where we do range validation before using the cached state. Fix this by protecting the private assignment and check of a file while holding the inode's spinlock and keep track of the task that allocated the private, so that it's used only by that task in order to prevent user-after-free issues with the cached state record as well as potentially using it incorrectly in the future.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47681", "url": "https://ubuntu.com/security/CVE-2024-47681", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix NULL pointer dereference in mt7996_mcu_sta_bfer_he Fix the NULL pointer dereference in mt7996_mcu_sta_bfer_he routine adding an sta interface to the mt7996 driver. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49858", "url": "https://ubuntu.com/security/CVE-2024-49858", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption The TPM event log table is a Linux specific construct, where the data produced by the GetEventLog() boot service is cached in memory, and passed on to the OS using an EFI configuration table. The use of EFI_LOADER_DATA here results in the region being left unreserved in the E820 memory map constructed by the EFI stub, and this is the memory description that is passed on to the incoming kernel by kexec, which is therefore unaware that the region should be reserved. Even though the utility of the TPM2 event log after a kexec is questionable, any corruption might send the parsing code off into the weeds and crash the kernel. So let's use EFI_ACPI_RECLAIM_MEMORY instead, which is always treated as reserved by the E820 conversion logic.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49860", "url": "https://ubuntu.com/security/CVE-2024-49860", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: sysfs: validate return type of _STR method Only buffer objects are valid return values of _STR. If something else is returned description_show() will access invalid memory.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47742", "url": "https://ubuntu.com/security/CVE-2024-47742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware_loader: Block path traversal Most firmware names are hardcoded strings, or are constructed from fairly constrained format strings where the dynamic parts are just some hex numbers or such. However, there are a couple codepaths in the kernel where firmware file names contain string components that are passed through from a device or semi-privileged userspace; the ones I could find (not counting interfaces that require root privileges) are: - lpfc_sli4_request_firmware_update() seems to construct the firmware filename from \"ModelName\", a string that was previously parsed out of some descriptor (\"Vital Product Data\") in lpfc_fill_vpd() - nfp_net_fw_find() seems to construct a firmware filename from a model name coming from nfp_hwinfo_lookup(pf->hwinfo, \"nffw.partno\"), which I think parses some descriptor that was read from the device. (But this case likely isn't exploitable because the format string looks like \"netronome/nic_%s\", and there shouldn't be any *folders* starting with \"netronome/nic_\". The previous case was different because there, the \"%s\" is *at the start* of the format string.) - module_flash_fw_schedule() is reachable from the ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is enough to pass the privilege check), and takes a userspace-provided firmware name. (But I think to reach this case, you need to have CAP_NET_ADMIN over a network namespace that a special kind of ethernet device is mapped into, so I think this is not a viable attack path in practice.) Fix it by rejecting any firmware names containing \"..\" path components. For what it's worth, I went looking and haven't found any USB device drivers that use the firmware loader dangerously.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47682", "url": "https://ubuntu.com/security/CVE-2024-47682", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sd: Fix off-by-one error in sd_read_block_characteristics() Ff the device returns page 0xb1 with length 8 (happens with qemu v2.x, for example), sd_read_block_characteristics() may attempt an out-of-bounds memory access when accessing the zoned field at offset 8.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47743", "url": "https://ubuntu.com/security/CVE-2024-47743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: prevent NULL pointer dereference in find_asymmetric_key() In find_asymmetric_key(), if all NULLs are passed in the id_{0,1,2} arguments, the kernel will first emit WARN but then have an oops because id_2 gets dereferenced anyway. Add the missing id_2 check and move WARN_ON() to the final else branch to avoid duplicate NULL checks. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47727", "url": "https://ubuntu.com/security/CVE-2024-47727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/tdx: Fix \"in-kernel MMIO\" check TDX only supports kernel-initiated MMIO operations. The handle_mmio() function checks if the #VE exception occurred in the kernel and rejects the operation if it did not. However, userspace can deceive the kernel into performing MMIO on its behalf. For example, if userspace can point a syscall to an MMIO address, syscall does get_user() or put_user() on it, triggering MMIO #VE. The kernel will treat the #VE as in-kernel MMIO. Ensure that the target MMIO address is within the kernel before decoding instruction.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47744", "url": "https://ubuntu.com/security/CVE-2024-47744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Use dedicated mutex to protect kvm_usage_count to avoid deadlock Use a dedicated mutex to guard kvm_usage_count to fix a potential deadlock on x86 due to a chain of locks and SRCU synchronizations. Translating the below lockdep splat, CPU1 #6 will wait on CPU0 #1, CPU0 #8 will wait on CPU2 #3, and CPU2 #7 will wait on CPU1 #4 (if there's a writer, due to the fairness of r/w semaphores). CPU0 CPU1 CPU2 1 lock(&kvm->slots_lock); 2 lock(&vcpu->mutex); 3 lock(&kvm->srcu); 4 lock(cpu_hotplug_lock); 5 lock(kvm_lock); 6 lock(&kvm->slots_lock); 7 lock(cpu_hotplug_lock); 8 sync(&kvm->srcu); Note, there are likely more potential deadlocks in KVM x86, e.g. the same pattern of taking cpu_hotplug_lock outside of kvm_lock likely exists with __kvmclock_cpufreq_notifier(): cpuhp_cpufreq_online() | -> cpufreq_online() | -> cpufreq_gov_performance_limits() | -> __cpufreq_driver_target() | -> __target_index() | -> cpufreq_freq_transition_begin() | -> cpufreq_notify_transition() | -> ... __kvmclock_cpufreq_notifier() But, actually triggering such deadlocks is beyond rare due to the combination of dependencies and timings involved. E.g. the cpufreq notifier is only used on older CPUs without a constant TSC, mucking with the NX hugepage mitigation while VMs are running is very uncommon, and doing so while also onlining/offlining a CPU (necessary to generate contention on cpu_hotplug_lock) would be even more unusual. The most robust solution to the general cpu_hotplug_lock issue is likely to switch vm_list to be an RCU-protected list, e.g. so that x86's cpufreq notifier doesn't to take kvm_lock. For now, settle for fixing the most blatant deadlock, as switching to an RCU-protected list is a much more involved change, but add a comment in locking.rst to call out that care needs to be taken when walking holding kvm_lock and walking vm_list. ====================================================== WARNING: possible circular locking dependency detected 6.10.0-smp--c257535a0c9d-pip #330 Tainted: G S O ------------------------------------------------------ tee/35048 is trying to acquire lock: ff6a80eced71e0a8 (&kvm->slots_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x179/0x1e0 [kvm] but task is already holding lock: ffffffffc07abb08 (kvm_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x14a/0x1e0 [kvm] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (kvm_lock){+.+.}-{3:3}: __mutex_lock+0x6a/0xb40 mutex_lock_nested+0x1f/0x30 kvm_dev_ioctl+0x4fb/0xe50 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #2 (cpu_hotplug_lock){++++}-{0:0}: cpus_read_lock+0x2e/0xb0 static_key_slow_inc+0x16/0x30 kvm_lapic_set_base+0x6a/0x1c0 [kvm] kvm_set_apic_base+0x8f/0xe0 [kvm] kvm_set_msr_common+0x9ae/0xf80 [kvm] vmx_set_msr+0xa54/0xbe0 [kvm_intel] __kvm_set_msr+0xb6/0x1a0 [kvm] kvm_arch_vcpu_ioctl+0xeca/0x10c0 [kvm] kvm_vcpu_ioctl+0x485/0x5b0 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (&kvm->srcu){.+.+}-{0:0}: __synchronize_srcu+0x44/0x1a0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47719", "url": "https://ubuntu.com/security/CVE-2024-47719", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommufd: Protect against overflow of ALIGN() during iova allocation Userspace can supply an iova and uptr such that the target iova alignment becomes really big and ALIGN() overflows which corrupts the selected area range during allocation. CONFIG_IOMMUFD_TEST can detect this: WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline] WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352 Modules linked in: CPU: 1 PID: 5092 Comm: syz-executor294 Not tainted 6.10.0-rc5-syzkaller-00294-g3ffea9a7a6f7 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024 RIP: 0010:iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline] RIP: 0010:iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352 Code: fc e9 a4 f3 ff ff e8 1a 8b 4c fc 41 be e4 ff ff ff e9 8a f3 ff ff e8 0a 8b 4c fc 90 0f 0b 90 e9 37 f5 ff ff e8 fc 8a 4c fc 90 <0f> 0b 90 e9 68 f3 ff ff 48 c7 c1 ec 82 ad 8f 80 e1 07 80 c1 03 38 RSP: 0018:ffffc90003ebf9e0 EFLAGS: 00010293 RAX: ffffffff85499fa4 RBX: 00000000ffffffef RCX: ffff888079b49e00 RDX: 0000000000000000 RSI: 00000000ffffffef RDI: 0000000000000000 RBP: ffffc90003ebfc50 R08: ffffffff85499b30 R09: ffffffff85499942 R10: 0000000000000002 R11: ffff888079b49e00 R12: ffff8880228e0010 R13: 0000000000000000 R14: 1ffff920007d7f68 R15: ffffc90003ebfd00 FS: 000055557d760380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000005fdeb8 CR3: 000000007404a000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: iommufd_ioas_copy+0x610/0x7b0 drivers/iommu/iommufd/ioas.c:274 iommufd_fops_ioctl+0x4d9/0x5a0 drivers/iommu/iommufd/main.c:421 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Cap the automatic alignment to the huge page size, which is probably a better idea overall. Huge automatic alignments can fragment and chew up the available IOVA space without any reason.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47745", "url": "https://ubuntu.com/security/CVE-2024-47745", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: call the security_mmap_file() LSM hook in remap_file_pages() The remap_file_pages syscall handler calls do_mmap() directly, which doesn't contain the LSM security check. And if the process has called personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for RW pages, this will actually result in remapping the pages to RWX, bypassing a W^X policy enforced by SELinux. So we should check prot by security_mmap_file LSM hook in the remap_file_pages syscall handler before do_mmap() is called. Otherwise, it potentially permits an attacker to bypass a W^X policy enforced by SELinux. The bypass is similar to CVE-2016-10044, which bypass the same thing via AIO and can be found in [1]. The PoC: $ cat > test.c int main(void) { \tsize_t pagesz = sysconf(_SC_PAGE_SIZE); \tint mfd = syscall(SYS_memfd_create, \"test\", 0); \tconst char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE, \t\tMAP_SHARED, mfd, 0); \tunsigned int old = syscall(SYS_personality, 0xffffffff); \tsyscall(SYS_personality, READ_IMPLIES_EXEC | old); \tsyscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0); \tsyscall(SYS_personality, old); \t// show the RWX page exists even if W^X policy is enforced \tint fd = open(\"/proc/self/maps\", O_RDONLY); \tunsigned char buf2[1024]; \twhile (1) { \t\tint ret = read(fd, buf2, 1024); \t\tif (ret <= 0) break; \t\twrite(1, buf2, ret); \t} \tclose(fd); } $ gcc test.c -o test $ ./test | grep rwx 7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted) [PM: subject line tweaks]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47746", "url": "https://ubuntu.com/security/CVE-2024-47746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: use exclusive lock when FUSE_I_CACHE_IO_MODE is set This may be a typo. The comment has said shared locks are not allowed when this bit is set. If using shared lock, the wait in `fuse_file_cached_io_open` may be forever.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47734", "url": "https://ubuntu.com/security/CVE-2024-47734", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: Fix unnecessary warnings and logs from bond_xdp_get_xmit_slave() syzbot reported a WARNING in bond_xdp_get_xmit_slave. To reproduce this[1], one bond device (bond1) has xdpdrv, which increases bpf_master_redirect_enabled_key. Another bond device (bond0) which is unsupported by XDP but its slave (veth3) has xdpgeneric that returns XDP_TX. This triggers WARN_ON_ONCE() from the xdp_master_redirect(). To reduce unnecessary warnings and improve log management, we need to delete the WARN_ON_ONCE() and add ratelimit to the netdev_err(). [1] Steps to reproduce: # Needs tx_xdp with return XDP_TX; ip l add veth0 type veth peer veth1 ip l add veth3 type veth peer veth4 ip l add bond0 type bond mode 6 # BOND_MODE_ALB, unsupported by XDP ip l add bond1 type bond # BOND_MODE_ROUNDROBIN by default ip l set veth0 master bond1 ip l set bond1 up # Increases bpf_master_redirect_enabled_key ip l set dev bond1 xdpdrv object tx_xdp.o section xdp_tx ip l set veth3 master bond0 ip l set bond0 up ip l set veth4 up # Triggers WARN_ON_ONCE() from the xdp_master_redirect() ip l set veth3 xdpgeneric object tx_xdp.o section xdp_tx", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47684", "url": "https://ubuntu.com/security/CVE-2024-47684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: check skb is non-NULL in tcp_rto_delta_us() We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic kernel that are running ceph and recently hit a null ptr dereference in tcp_rearm_rto(). Initially hitting it from the TLP path, but then later we also saw it getting hit from the RACK case as well. Here are examples of the oops messages we saw in each of those cases: Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020 Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode Jul 26 15:05:02 rx [11061395.792971] #PF: error_code(0x0000) - not-present page Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0 Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI Jul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu Jul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023 Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 <48> 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3 Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246 Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000 Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60 Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8 Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900 Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30 Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000 Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0 Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554 Jul 26 15:05:02 rx [11061395.916786] Call Trace: Jul 26 15:05:02 rx [11061395.919488] Jul 26 15:05:02 rx [11061395.921765] ? show_regs.cold+0x1a/0x1f Jul 26 15:05:02 rx [11061395.925859] ? __die+0x90/0xd9 Jul 26 15:05:02 rx [11061395.929169] ? no_context+0x196/0x380 Jul 26 15:05:02 rx [11061395.933088] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0 Jul 26 15:05:02 rx [11061395.938216] ? ip6_sublist_rcv_finish+0x3d/0x50 Jul 26 15:05:02 rx [11061395.943000] ? __bad_area_nosemaphore+0x50/0x1a0 Jul 26 15:05:02 rx [11061395.947873] ? bad_area_nosemaphore+0x16/0x20 Jul 26 15:05:02 rx [11061395.952486] ? do_user_addr_fault+0x267/0x450 Jul 26 15:05:02 rx [11061395.957104] ? ipv6_list_rcv+0x112/0x140 Jul 26 15:05:02 rx [11061395.961279] ? __do_page_fault+0x58/0x90 Jul 26 15:05:02 rx [11061395.965458] ? do_page_fault+0x2c/0xe0 Jul 26 15:05:02 rx [11061395.969465] ? page_fault+0x34/0x40 Jul 26 15:05:02 rx [11061395.973217] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.977313] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.981408] tcp_send_loss_probe+0x10b/0x220 Jul 26 15:05:02 rx [11061395.985937] tcp_write_timer_handler+0x1b4/0x240 Jul 26 15:05:02 rx [11061395.990809] tcp_write_timer+0x9e/0xe0 Jul 26 15:05:02 rx [11061395.994814] ? tcp_write_timer_handler+0x240/0x240 Jul 26 15:05:02 rx [11061395.999866] call_timer_fn+0x32/0x130 Jul 26 15:05:02 rx [11061396.003782] __run_timers.part.0+0x180/0x280 Jul 26 15:05:02 rx [11061396.008309] ? recalibrate_cpu_khz+0x10/0x10 Jul 26 15:05:02 rx [11061396.012841] ? native_x2apic_icr_write+0x30/0x30 Jul 26 15:05:02 rx [11061396.017718] ? lapic_next_even ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47747", "url": "https://ubuntu.com/security/CVE-2024-47747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race Condition In the ether3_probe function, a timer is initialized with a callback function ether3_ledoff, bound to &prev(dev)->timer. Once the timer is started, there is a risk of a race condition if the module or device is removed, triggering the ether3_remove function to perform cleanup. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | ether3_ledoff ether3_remove | free_netdev(dev); | put_devic | kfree(dev); | | ether3_outw(priv(dev)->regs.config2 |= CFG2_CTRLO, REG_CONFIG2); | // use dev Fix it by ensuring that the timer is canceled before proceeding with the cleanup in ether3_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47685", "url": "https://ubuntu.com/security/CVE-2024-47685", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put() syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending garbage on the four reserved tcp bits (th->res1) Use skb_put_zero() to clear the whole TCP header, as done in nf_reject_ip_tcphdr_put() BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5661 [inline] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775 process_backlog+0x4ad/0xa50 net/core/dev.c:6108 __napi_poll+0xe7/0x980 net/core/dev.c:6772 napi_poll net/core/dev.c:6841 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963 handle_softirqs+0x1ce/0x800 kernel/softirq.c:554 __do_softirq+0x14/0x1a kernel/softirq.c:588 do_softirq+0x9a/0x100 kernel/softirq.c:455 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline] __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450 dev_queue_xmit include/linux/netdevice.h:3105 [inline] neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366 inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135 __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143 tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333 __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679 inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750 __sys_connect_file net/socket.c:2061 [inline] __sys_connect+0x606/0x690 net/socket.c:2078 __do_sys_connect net/socket.c:2088 [inline] __se_sys_connect net/socket.c:2085 [inline] __x64_sys_connect+0x91/0xe0 net/socket.c:2085 x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43 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 Uninit was stored to memory at: nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47686", "url": "https://ubuntu.com/security/CVE-2024-47686", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ep93xx: clock: Fix off by one in ep93xx_div_recalc_rate() The psc->div[] array has psc->num_div elements. These values come from when we call clk_hw_register_div(). It's adc_divisors and ARRAY_SIZE(adc_divisors)) and so on. So this condition needs to be >= instead of > to prevent an out of bounds read.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47748", "url": "https://ubuntu.com/security/CVE-2024-47748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost_vdpa: assign irq bypass producer token correctly We used to call irq_bypass_unregister_producer() in vhost_vdpa_setup_vq_irq() which is problematic as we don't know if the token pointer is still valid or not. Actually, we use the eventfd_ctx as the token so the life cycle of the token should be bound to the VHOST_SET_VRING_CALL instead of vhost_vdpa_setup_vq_irq() which could be called by set_status(). Fixing this by setting up irq bypass producer's token when handling VHOST_SET_VRING_CALL and un-registering the producer before calling vhost_vring_ioctl() to prevent a possible use after free as eventfd could have been released in vhost_vring_ioctl(). And such registering and unregistering will only be done if DRIVER_OK is set.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47687", "url": "https://ubuntu.com/security/CVE-2024-47687", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa/mlx5: Fix invalid mr resource destroy Certain error paths from mlx5_vdpa_dev_add() can end up releasing mr resources which never got initialized in the first place. This patch adds the missing check in mlx5_vdpa_destroy_mr_resources() to block releasing non-initialized mr resources. Reference trace: mlx5_core 0000:08:00.2: mlx5_vdpa_dev_add:3274:(pid 2700) warning: No mac address provisioned? BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 140216067 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 8 PID: 2700 Comm: vdpa Kdump: loaded Not tainted 5.14.0-496.el9.x86_64 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:vhost_iotlb_del_range+0xf/0xe0 [vhost_iotlb] Code: [...] RSP: 0018:ff1c823ac23077f0 EFLAGS: 00010246 RAX: ffffffffc1a21a60 RBX: ffffffff899567a0 RCX: 0000000000000000 RDX: ffffffffffffffff RSI: 0000000000000000 RDI: 0000000000000000 RBP: ff1bda1f7c21e800 R08: 0000000000000000 R09: ff1c823ac2307670 R10: ff1c823ac2307668 R11: ffffffff8a9e7b68 R12: 0000000000000000 R13: 0000000000000000 R14: ff1bda1f43e341a0 R15: 00000000ffffffea FS: 00007f56eba7c740(0000) GS:ff1bda269f800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000104d90001 CR4: 0000000000771ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? mlx5_vdpa_free+0x3d/0x150 [mlx5_vdpa] ? __die_body.cold+0x8/0xd ? page_fault_oops+0x134/0x170 ? __irq_work_queue_local+0x2b/0xc0 ? irq_work_queue+0x2c/0x50 ? exc_page_fault+0x62/0x150 ? asm_exc_page_fault+0x22/0x30 ? __pfx_mlx5_vdpa_free+0x10/0x10 [mlx5_vdpa] ? vhost_iotlb_del_range+0xf/0xe0 [vhost_iotlb] mlx5_vdpa_free+0x3d/0x150 [mlx5_vdpa] vdpa_release_dev+0x1e/0x50 [vdpa] device_release+0x31/0x90 kobject_cleanup+0x37/0x130 mlx5_vdpa_dev_add+0x2d2/0x7a0 [mlx5_vdpa] vdpa_nl_cmd_dev_add_set_doit+0x277/0x4c0 [vdpa] genl_family_rcv_msg_doit+0xd9/0x130 genl_family_rcv_msg+0x14d/0x220 ? __pfx_vdpa_nl_cmd_dev_add_set_doit+0x10/0x10 [vdpa] ? _copy_to_user+0x1a/0x30 ? move_addr_to_user+0x4b/0xe0 genl_rcv_msg+0x47/0xa0 ? __import_iovec+0x46/0x150 ? __pfx_genl_rcv_msg+0x10/0x10 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x245/0x370 netlink_sendmsg+0x206/0x440 __sys_sendto+0x1dc/0x1f0 ? do_read_fault+0x10c/0x1d0 ? do_pte_missing+0x10d/0x190 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x5c/0xf0 ? __count_memcg_events+0x4f/0xb0 ? mm_account_fault+0x6c/0x100 ? handle_mm_fault+0x116/0x270 ? do_user_addr_fault+0x1d6/0x6a0 ? do_syscall_64+0x6b/0xf0 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 entry_SYSCALL_64_after_hwframe+0x78/0x80", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47688", "url": "https://ubuntu.com/security/CVE-2024-47688", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: driver core: Fix a potential null-ptr-deref in module_add_driver() Inject fault while probing of-fpga-region, if kasprintf() fails in module_add_driver(), the second sysfs_remove_link() in exit path will cause null-ptr-deref as below because kernfs_name_hash() will call strlen() with NULL driver_name. Fix it by releasing resources based on the exit path sequence. \t KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] \t Mem abort info: \t ESR = 0x0000000096000005 \t EC = 0x25: DABT (current EL), IL = 32 bits \t SET = 0, FnV = 0 \t EA = 0, S1PTW = 0 \t FSC = 0x05: level 1 translation fault \t Data abort info: \t ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 \t CM = 0, WnR = 0, TnD = 0, TagAccess = 0 \t GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 \t [dfffffc000000000] address between user and kernel address ranges \t Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP \t Dumping ftrace buffer: \t (ftrace buffer empty) \t Modules linked in: of_fpga_region(+) fpga_region fpga_bridge cfg80211 rfkill 8021q garp mrp stp llc ipv6 [last unloaded: of_fpga_region] \t CPU: 2 UID: 0 PID: 2036 Comm: modprobe Not tainted 6.11.0-rc2-g6a0e38264012 #295 \t Hardware name: linux,dummy-virt (DT) \t pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) \t pc : strlen+0x24/0xb0 \t lr : kernfs_name_hash+0x1c/0xc4 \t sp : ffffffc081f97380 \t x29: ffffffc081f97380 x28: ffffffc081f97b90 x27: ffffff80c821c2a0 \t x26: ffffffedac0be418 x25: 0000000000000000 x24: ffffff80c09d2000 \t x23: 0000000000000000 x22: 0000000000000000 x21: 0000000000000000 \t x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000001840 \t x17: 0000000000000000 x16: 0000000000000000 x15: 1ffffff8103f2e42 \t x14: 00000000f1f1f1f1 x13: 0000000000000004 x12: ffffffb01812d61d \t x11: 1ffffff01812d61c x10: ffffffb01812d61c x9 : dfffffc000000000 \t x8 : 0000004fe7ed29e4 x7 : ffffff80c096b0e7 x6 : 0000000000000001 \t x5 : ffffff80c096b0e0 x4 : 1ffffffdb990efa2 x3 : 0000000000000000 \t x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000000 \t Call trace: \t strlen+0x24/0xb0 \t kernfs_name_hash+0x1c/0xc4 \t kernfs_find_ns+0x118/0x2e8 \t kernfs_remove_by_name_ns+0x80/0x100 \t sysfs_remove_link+0x74/0xa8 \t module_add_driver+0x278/0x394 \t bus_add_driver+0x1f0/0x43c \t driver_register+0xf4/0x3c0 \t __platform_driver_register+0x60/0x88 \t of_fpga_region_init+0x20/0x1000 [of_fpga_region] \t do_one_initcall+0x110/0x788 \t do_init_module+0x1dc/0x5c8 \t load_module+0x3c38/0x4cac \t init_module_from_file+0xd4/0x128 \t idempotent_init_module+0x2cc/0x528 \t __arm64_sys_finit_module+0xac/0x100 \t invoke_syscall+0x6c/0x258 \t el0_svc_common.constprop.0+0x160/0x22c \t do_el0_svc+0x44/0x5c \t el0_svc+0x48/0xb8 \t el0t_64_sync_handler+0x13c/0x158 \t el0t_64_sync+0x190/0x194 \t Code: f2fbffe1 a90157f4 12000802 aa0003f5 (38e16861) \t ---[ end trace 0000000000000000 ]--- \t Kernel panic - not syncing: Oops: Fatal exception", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47689", "url": "https://ubuntu.com/security/CVE-2024-47689", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to don't set SB_RDONLY in f2fs_handle_critical_error() syzbot reports a f2fs bug as below: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 58 at kernel/rcu/sync.c:177 rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177 CPU: 1 UID: 0 PID: 58 Comm: kworker/1:2 Not tainted 6.10.0-syzkaller-12562-g1722389b0d86 #0 Workqueue: events destroy_super_work RIP: 0010:rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177 Call Trace: percpu_free_rwsem+0x41/0x80 kernel/locking/percpu-rwsem.c:42 destroy_super_work+0xec/0x130 fs/super.c:282 process_one_work kernel/workqueue.c:3231 [inline] process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 worker_thread+0x86d/0xd40 kernel/workqueue.c:3390 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 As Christian Brauner pointed out [1]: the root cause is f2fs sets SB_RDONLY flag in internal function, rather than setting the flag covered w/ sb->s_umount semaphore via remount procedure, then below race condition causes this bug: - freeze_super() - sb_wait_write(sb, SB_FREEZE_WRITE) - sb_wait_write(sb, SB_FREEZE_PAGEFAULT) - sb_wait_write(sb, SB_FREEZE_FS) \t\t\t\t\t- f2fs_handle_critical_error \t\t\t\t\t - sb->s_flags |= SB_RDONLY - thaw_super - thaw_super_locked - sb_rdonly() is true, so it skips sb_freeze_unlock(sb, SB_FREEZE_FS) - deactivate_locked_super Since f2fs has almost the same logic as ext4 [2] when handling critical error in filesystem if it mounts w/ errors=remount-ro option: - set CP_ERROR_FLAG flag which indicates filesystem is stopped - record errors to superblock - set SB_RDONLY falg Once we set CP_ERROR_FLAG flag, all writable interfaces can detect the flag and stop any further updates on filesystem. So, it is safe to not set SB_RDONLY flag, let's remove the logic and keep in line w/ ext4 [3]. [1] https://lore.kernel.org/all/20240729-himbeeren-funknetz-96e62f9c7aee@brauner [2] https://lore.kernel.org/all/20240729132721.hxih6ehigadqf7wx@quack3 [3] https://lore.kernel.org/linux-ext4/20240805201241.27286-1-jack@suse.cz", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47690", "url": "https://ubuntu.com/security/CVE-2024-47690", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: get rid of online repaire on corrupted directory syzbot reports a f2fs bug as below: kernel BUG at fs/f2fs/inode.c:896! RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Call Trace: evict+0x532/0x950 fs/inode.c:704 dispose_list fs/inode.c:747 [inline] evict_inodes+0x5f9/0x690 fs/inode.c:797 generic_shutdown_super+0x9d/0x2d0 fs/super.c:627 kill_block_super+0x44/0x90 fs/super.c:1696 kill_f2fs_super+0x344/0x690 fs/f2fs/super.c:4898 deactivate_locked_super+0xc4/0x130 fs/super.c:473 cleanup_mnt+0x41f/0x4b0 fs/namespace.c:1373 task_work_run+0x24f/0x310 kernel/task_work.c:228 ptrace_notify+0x2d2/0x380 kernel/signal.c:2402 ptrace_report_syscall include/linux/ptrace.h:415 [inline] ptrace_report_syscall_exit include/linux/ptrace.h:477 [inline] syscall_exit_work+0xc6/0x190 kernel/entry/common.c:173 syscall_exit_to_user_mode_prepare kernel/entry/common.c:200 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:205 [inline] syscall_exit_to_user_mode+0x279/0x370 kernel/entry/common.c:218 do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Online repaire on corrupted directory in f2fs_lookup() can generate dirty data/meta while racing w/ readonly remount, it may leave dirty inode after filesystem becomes readonly, however, checkpoint() will skips flushing dirty inode in a state of readonly mode, result in above panic. Let's get rid of online repaire in f2fs_lookup(), and leave the work to fsck.f2fs.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47691", "url": "https://ubuntu.com/security/CVE-2024-47691", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread() syzbot reports a f2fs bug as below: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_report+0xe8/0x550 mm/kasan/report.c:491 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 instrument_atomic_read_write include/linux/instrumented.h:96 [inline] atomic_fetch_add_relaxed include/linux/atomic/atomic-instrumented.h:252 [inline] __refcount_add include/linux/refcount.h:184 [inline] __refcount_inc include/linux/refcount.h:241 [inline] refcount_inc include/linux/refcount.h:258 [inline] get_task_struct include/linux/sched/task.h:118 [inline] kthread_stop+0xca/0x630 kernel/kthread.c:704 f2fs_stop_gc_thread+0x65/0xb0 fs/f2fs/gc.c:210 f2fs_do_shutdown+0x192/0x540 fs/f2fs/file.c:2283 f2fs_ioc_shutdown fs/f2fs/file.c:2325 [inline] __f2fs_ioctl+0x443a/0xbe60 fs/f2fs/file.c:4325 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f The root cause is below race condition, it may cause use-after-free issue in sbi->gc_th pointer. - remount - f2fs_remount - f2fs_stop_gc_thread - kfree(gc_th) \t\t\t\t- f2fs_ioc_shutdown \t\t\t\t - f2fs_do_shutdown \t\t\t\t - f2fs_stop_gc_thread \t\t\t\t - kthread_stop(gc_th->f2fs_gc_task) : sbi->gc_thread = NULL; We will call f2fs_do_shutdown() in two paths: - for f2fs_ioc_shutdown() path, we should grab sb->s_umount semaphore for fixing. - for f2fs_shutdown() path, it's safe since caller has already grabbed sb->s_umount semaphore.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47692", "url": "https://ubuntu.com/security/CVE-2024-47692", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: return -EINVAL when namelen is 0 When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may result in namelen being 0, which will cause memdup_user() to return ZERO_SIZE_PTR. When we access the name.data that has been assigned the value of ZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is triggered. [ T1205] ================================================================== [ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260 [ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205 [ T1205] [ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406 [ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ T1205] Call Trace: [ T1205] dump_stack+0x9a/0xd0 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] __kasan_report.cold+0x34/0x84 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] kasan_report+0x3a/0x50 [ T1205] nfs4_client_to_reclaim+0xe9/0x260 [ T1205] ? nfsd4_release_lockowner+0x410/0x410 [ T1205] cld_pipe_downcall+0x5ca/0x760 [ T1205] ? nfsd4_cld_tracking_exit+0x1d0/0x1d0 [ T1205] ? down_write_killable_nested+0x170/0x170 [ T1205] ? avc_policy_seqno+0x28/0x40 [ T1205] ? selinux_file_permission+0x1b4/0x1e0 [ T1205] rpc_pipe_write+0x84/0xb0 [ T1205] vfs_write+0x143/0x520 [ T1205] ksys_write+0xc9/0x170 [ T1205] ? __ia32_sys_read+0x50/0x50 [ T1205] ? ktime_get_coarse_real_ts64+0xfe/0x110 [ T1205] ? ktime_get_coarse_real_ts64+0xa2/0x110 [ T1205] do_syscall_64+0x33/0x40 [ T1205] entry_SYSCALL_64_after_hwframe+0x67/0xd1 [ T1205] RIP: 0033:0x7fdbdb761bc7 [ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 514 [ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7 [ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008 [ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001 [ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b [ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000 [ T1205] ================================================================== Fix it by checking namelen.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47737", "url": "https://ubuntu.com/security/CVE-2024-47737", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: call cache_put if xdr_reserve_space returns NULL If not enough buffer space available, but idmap_lookup has triggered lookup_fn which calls cache_get and returns successfully. Then we missed to call cache_put here which pairs with cache_get. Reviwed-by: Jeff Layton ", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2023-52917", "url": "https://ubuntu.com/security/CVE-2023-52917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir() The debugfs_create_dir() function returns error pointers. It never returns NULL. So use IS_ERR() to check it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47749", "url": "https://ubuntu.com/security/CVE-2024-47749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Added NULL check for lookup_atid The lookup_atid() function can return NULL if the ATID is invalid or does not exist in the identifier table, which could lead to dereferencing a null pointer without a check in the `act_establish()` and `act_open_rpl()` functions. Add a NULL check to prevent null pointer dereferencing. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47735", "url": "https://ubuntu.com/security/CVE-2024-47735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled Fix missuse of spin_lock_irq()/spin_unlock_irq() when spin_lock_irqsave()/spin_lock_irqrestore() was hold. This was discovered through the lock debugging, and the corresponding log is as follows: raw_local_irq_restore() called with IRQs enabled WARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40 ... Call trace: warn_bogus_irq_restore+0x30/0x40 _raw_spin_unlock_irqrestore+0x84/0xc8 add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2] hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2] hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2] create_qp+0x138/0x258 ib_create_qp_kernel+0x50/0xe8 create_mad_qp+0xa8/0x128 ib_mad_port_open+0x218/0x448 ib_mad_init_device+0x70/0x1f8 add_client_context+0xfc/0x220 enable_device_and_get+0xd0/0x140 ib_register_device.part.0+0xf4/0x1c8 ib_register_device+0x34/0x50 hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2] hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2] __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2] hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47750", "url": "https://ubuntu.com/security/CVE-2024-47750", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix Use-After-Free of rsv_qp on HIP08 Currently rsv_qp is freed before ib_unregister_device() is called on HIP08. During the time interval, users can still dereg MR and rsv_qp will be used in this process, leading to a UAF. Move the release of rsv_qp after calling ib_unregister_device() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47751", "url": "https://ubuntu.com/security/CVE-2024-47751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: kirin: Fix buffer overflow in kirin_pcie_parse_port() Within kirin_pcie_parse_port(), the pcie->num_slots is compared to pcie->gpio_id_reset size (MAX_PCI_SLOTS) which is correct and would lead to an overflow. Thus, fix condition to pcie->num_slots + 1 >= MAX_PCI_SLOTS and move pcie->num_slots increment below the if-statement to avoid out-of-bounds array access. Found by Linux Verification Center (linuxtesting.org) with SVACE. [kwilczynski: commit log]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47693", "url": "https://ubuntu.com/security/CVE-2024-47693", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/core: Fix ib_cache_setup_one error flow cleanup When ib_cache_update return an error, we exit ib_cache_setup_one instantly with no proper cleanup, even though before this we had already successfully done gid_table_setup_one, that results in the kernel WARN below. Do proper cleanup using gid_table_cleanup_one before returning the err in order to fix the issue. WARNING: CPU: 4 PID: 922 at drivers/infiniband/core/cache.c:806 gid_table_release_one+0x181/0x1a0 Modules linked in: CPU: 4 UID: 0 PID: 922 Comm: c_repro Not tainted 6.11.0-rc1+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:gid_table_release_one+0x181/0x1a0 Code: 44 8b 38 75 0c e8 2f cb 34 ff 4d 8b b5 28 05 00 00 e8 23 cb 34 ff 44 89 f9 89 da 4c 89 f6 48 c7 c7 d0 58 14 83 e8 4f de 21 ff <0f> 0b 4c 8b 75 30 e9 54 ff ff ff 48 8 3 c4 10 5b 5d 41 5c 41 5d 41 RSP: 0018:ffffc90002b835b0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c8527 RDX: 0000000000000000 RSI: ffffffff811c8534 RDI: 0000000000000001 RBP: ffff8881011b3d00 R08: ffff88810b3abe00 R09: 205d303839303631 R10: 666572207972746e R11: 72746e6520444947 R12: 0000000000000001 R13: ffff888106390000 R14: ffff8881011f2110 R15: 0000000000000001 FS: 00007fecc3b70800(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000340 CR3: 000000010435a001 CR4: 00000000003706b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? show_regs+0x94/0xa0 ? __warn+0x9e/0x1c0 ? gid_table_release_one+0x181/0x1a0 ? report_bug+0x1f9/0x340 ? gid_table_release_one+0x181/0x1a0 ? handle_bug+0xa2/0x110 ? exc_invalid_op+0x31/0xa0 ? asm_exc_invalid_op+0x16/0x20 ? __warn_printk+0xc7/0x180 ? __warn_printk+0xd4/0x180 ? gid_table_release_one+0x181/0x1a0 ib_device_release+0x71/0xe0 ? __pfx_ib_device_release+0x10/0x10 device_release+0x44/0xd0 kobject_put+0x135/0x3d0 put_device+0x20/0x30 rxe_net_add+0x7d/0xa0 rxe_newlink+0xd7/0x190 nldev_newlink+0x1b0/0x2a0 ? __pfx_nldev_newlink+0x10/0x10 rdma_nl_rcv_msg+0x1ad/0x2e0 rdma_nl_rcv_skb.constprop.0+0x176/0x210 netlink_unicast+0x2de/0x400 netlink_sendmsg+0x306/0x660 __sock_sendmsg+0x110/0x120 ____sys_sendmsg+0x30e/0x390 ___sys_sendmsg+0x9b/0xf0 ? kstrtouint+0x6e/0xa0 ? kstrtouint_from_user+0x7c/0xb0 ? get_pid_task+0xb0/0xd0 ? proc_fail_nth_write+0x5b/0x140 ? __fget_light+0x9a/0x200 ? preempt_count_add+0x47/0xa0 __sys_sendmsg+0x61/0xd0 do_syscall_64+0x50/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47694", "url": "https://ubuntu.com/security/CVE-2024-47694", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mlx5: Fix UMR pd cleanup on error flow of driver init The cited commit moves the pd allocation from function mlx5r_umr_resource_cleanup() to a new function mlx5r_umr_cleanup(). So the fix in commit [1] is broken. In error flow, will hit panic [2]. Fix it by checking pd pointer to avoid panic if it is NULL; [1] RDMA/mlx5: Fix UMR cleanup on error flow of driver init [2] [ 347.567063] infiniband mlx5_0: Couldn't register device with driver model [ 347.591382] BUG: kernel NULL pointer dereference, address: 0000000000000020 [ 347.593438] #PF: supervisor read access in kernel mode [ 347.595176] #PF: error_code(0x0000) - not-present page [ 347.596962] PGD 0 P4D 0 [ 347.601361] RIP: 0010:ib_dealloc_pd_user+0x12/0xc0 [ib_core] [ 347.604171] RSP: 0018:ffff888106293b10 EFLAGS: 00010282 [ 347.604834] RAX: 0000000000000000 RBX: 000000000000000e RCX: 0000000000000000 [ 347.605672] RDX: ffff888106293ad0 RSI: 0000000000000000 RDI: 0000000000000000 [ 347.606529] RBP: 0000000000000000 R08: ffff888106293ae0 R09: ffff888106293ae0 [ 347.607379] R10: 0000000000000a06 R11: 0000000000000000 R12: 0000000000000000 [ 347.608224] R13: ffffffffa0704dc0 R14: 0000000000000001 R15: 0000000000000001 [ 347.609067] FS: 00007fdc720cd9c0(0000) GS:ffff88852c880000(0000) knlGS:0000000000000000 [ 347.610094] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 347.610727] CR2: 0000000000000020 CR3: 0000000103012003 CR4: 0000000000370eb0 [ 347.611421] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 347.612113] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 347.612804] Call Trace: [ 347.613130] [ 347.613417] ? __die+0x20/0x60 [ 347.613793] ? page_fault_oops+0x150/0x3e0 [ 347.614243] ? free_msg+0x68/0x80 [mlx5_core] [ 347.614840] ? cmd_exec+0x48f/0x11d0 [mlx5_core] [ 347.615359] ? exc_page_fault+0x74/0x130 [ 347.615808] ? asm_exc_page_fault+0x22/0x30 [ 347.616273] ? ib_dealloc_pd_user+0x12/0xc0 [ib_core] [ 347.616801] mlx5r_umr_cleanup+0x23/0x90 [mlx5_ib] [ 347.617365] mlx5_ib_stage_pre_ib_reg_umr_cleanup+0x36/0x40 [mlx5_ib] [ 347.618025] __mlx5_ib_add+0x96/0xd0 [mlx5_ib] [ 347.618539] mlx5r_probe+0xe9/0x310 [mlx5_ib] [ 347.619032] ? kernfs_add_one+0x107/0x150 [ 347.619478] ? __mlx5_ib_add+0xd0/0xd0 [mlx5_ib] [ 347.619984] auxiliary_bus_probe+0x3e/0x90 [ 347.620448] really_probe+0xc5/0x3a0 [ 347.620857] __driver_probe_device+0x80/0x160 [ 347.621325] driver_probe_device+0x1e/0x90 [ 347.621770] __driver_attach+0xec/0x1c0 [ 347.622213] ? __device_attach_driver+0x100/0x100 [ 347.622724] bus_for_each_dev+0x71/0xc0 [ 347.623151] bus_add_driver+0xed/0x240 [ 347.623570] driver_register+0x58/0x100 [ 347.623998] __auxiliary_driver_register+0x6a/0xc0 [ 347.624499] ? driver_register+0xae/0x100 [ 347.624940] ? 0xffffffffa0893000 [ 347.625329] mlx5_ib_init+0x16a/0x1e0 [mlx5_ib] [ 347.625845] do_one_initcall+0x4a/0x2a0 [ 347.626273] ? gcov_event+0x2e2/0x3a0 [ 347.626706] do_init_module+0x8a/0x260 [ 347.627126] init_module_from_file+0x8b/0xd0 [ 347.627596] __x64_sys_finit_module+0x1ca/0x2f0 [ 347.628089] do_syscall_64+0x4c/0x100", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47695", "url": "https://ubuntu.com/security/CVE-2024-47695", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds In the function init_conns(), after the create_con() and create_cm() for loop if something fails. In the cleanup for loop after the destroy tag, we access out of bound memory because cid is set to clt_path->s.con_num. This commits resets the cid to clt_path->s.con_num - 1, to stay in bounds in the cleanup loop later.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47752", "url": "https://ubuntu.com/security/CVE-2024-47752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix H264 stateless decoder smatch warning Fix a smatch static checker warning on vdec_h264_req_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47753", "url": "https://ubuntu.com/security/CVE-2024-47753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix VP8 stateless decoder smatch warning Fix a smatch static checker warning on vdec_vp8_req_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47754", "url": "https://ubuntu.com/security/CVE-2024-47754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix H264 multi stateless decoder smatch warning Fix a smatch static checker warning on vdec_h264_req_multi_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47696", "url": "https://ubuntu.com/security/CVE-2024-47696", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency In the commit aee2424246f9 (\"RDMA/iwcm: Fix a use-after-free related to destroying CM IDs\"), the function flush_workqueue is invoked to flush the work queue iwcm_wq. But at that time, the work queue iwcm_wq was created via the function alloc_ordered_workqueue without the flag WQ_MEM_RECLAIM. Because the current process is trying to flush the whole iwcm_wq, if iwcm_wq doesn't have the flag WQ_MEM_RECLAIM, verify that the current process is not reclaiming memory or running on a workqueue which doesn't have the flag WQ_MEM_RECLAIM as that can break forward-progress guarantee leading to a deadlock. The call trace is as below: [ 125.350876][ T1430] Call Trace: [ 125.356281][ T1430] [ 125.361285][ T1430] ? __warn (kernel/panic.c:693) [ 125.367640][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.375689][ T1430] ? report_bug (lib/bug.c:180 lib/bug.c:219) [ 125.382505][ T1430] ? handle_bug (arch/x86/kernel/traps.c:239) [ 125.388987][ T1430] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) [ 125.395831][ T1430] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621) [ 125.403125][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.410984][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.418764][ T1430] __flush_workqueue (kernel/workqueue.c:3970) [ 125.426021][ T1430] ? __pfx___might_resched (kernel/sched/core.c:10151) [ 125.433431][ T1430] ? destroy_cm_id (drivers/infiniband/core/iwcm.c:375) iw_cm [ 125.441209][ T1430] ? __pfx___flush_workqueue (kernel/workqueue.c:3910) [ 125.473900][ T1430] ? _raw_spin_lock_irqsave (arch/x86/include/asm/atomic.h:107 include/linux/atomic/atomic-arch-fallback.h:2170 include/linux/atomic/atomic-instrumented.h:1302 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162) [ 125.473909][ T1430] ? __pfx__raw_spin_lock_irqsave (kernel/locking/spinlock.c:161) [ 125.482537][ T1430] _destroy_id (drivers/infiniband/core/cma.c:2044) rdma_cm [ 125.495072][ T1430] nvme_rdma_free_queue (drivers/nvme/host/rdma.c:656 drivers/nvme/host/rdma.c:650) nvme_rdma [ 125.505827][ T1430] nvme_rdma_reset_ctrl_work (drivers/nvme/host/rdma.c:2180) nvme_rdma [ 125.505831][ T1430] process_one_work (kernel/workqueue.c:3231) [ 125.515122][ T1430] worker_thread (kernel/workqueue.c:3306 kernel/workqueue.c:3393) [ 125.515127][ T1430] ? __pfx_worker_thread (kernel/workqueue.c:3339) [ 125.531837][ T1430] kthread (kernel/kthread.c:389) [ 125.539864][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.550628][ T1430] ret_from_fork (arch/x86/kernel/process.c:147) [ 125.558840][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.558844][ T1430] ret_from_fork_asm (arch/x86/entry/entry_64.S:257) [ 125.566487][ T1430] [ 125.566488][ T1430] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47755", "url": "https://ubuntu.com/security/CVE-2024-47755", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47756", "url": "https://ubuntu.com/security/CVE-2024-47756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: keystone: Fix if-statement expression in ks_pcie_quirk() This code accidentally uses && where || was intended. It potentially results in a NULL dereference. Thus, fix the if-statement expression to use the correct condition. [kwilczynski: commit log]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47697", "url": "https://ubuntu.com/security/CVE-2024-47697", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error Ensure index in rtl2830_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47698", "url": "https://ubuntu.com/security/CVE-2024-47698", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error Ensure index in rtl2832_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue. [hverkuil: added fixes tag, rtl2830_pid_filter -> rtl2832_pid_filter in logmsg]", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47728", "url": "https://ubuntu.com/security/CVE-2024-47728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error For all non-tracing helpers which formerly had ARG_PTR_TO_{LONG,INT} as input arguments, zero the value for the case of an error as otherwise it could leak memory. For tracing, it is not needed given CAP_PERFMON can already read all kernel memory anyway hence bpf_get_func_arg() and bpf_get_func_ret() is skipped in here. Also, the MTU helpers mtu_len pointer value is being written but also read. Technically, the MEM_UNINIT should not be there in order to always force init. Removing MEM_UNINIT needs more verifier rework though: MEM_UNINIT right now implies two things actually: i) write into memory, ii) memory does not have to be initialized. If we lift MEM_UNINIT, it then becomes: i) read into memory, ii) memory must be initialized. This means that for bpf_*_check_mtu() we're readding the issue we're trying to fix, that is, it would then be able to write back into things like .rodata BPF maps. Follow-up work will rework the MEM_UNINIT semantics such that the intent can be better expressed. For now just clear the *mtu_len on error path which can be lifted later again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49861", "url": "https://ubuntu.com/security/CVE-2024-49861", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix helper writes to read-only maps Lonial found an issue that despite user- and BPF-side frozen BPF map (like in case of .rodata), it was still possible to write into it from a BPF program side through specific helpers having ARG_PTR_TO_{LONG,INT} as arguments. In check_func_arg() when the argument is as mentioned, the meta->raw_mode is never set. Later, check_helper_mem_access(), under the case of PTR_TO_MAP_VALUE as register base type, it assumes BPF_READ for the subsequent call to check_map_access_type() and given the BPF map is read-only it succeeds. The helpers really need to be annotated as ARG_PTR_TO_{LONG,INT} | MEM_UNINIT when results are written into them as opposed to read out of them. The latter indicates that it's okay to pass a pointer to uninitialized memory as the memory is written to anyway. However, ARG_PTR_TO_{LONG,INT} is a special case of ARG_PTR_TO_FIXED_SIZE_MEM just with additional alignment requirement. So it is better to just get rid of the ARG_PTR_TO_{LONG,INT} special cases altogether and reuse the fixed size memory types. For this, add MEM_ALIGNED to additionally ensure alignment given these helpers write directly into the args via * = val. The .arg*_size has been initialized reflecting the actual sizeof(*). MEM_ALIGNED can only be used in combination with MEM_FIXED_SIZE annotated argument types, since in !MEM_FIXED_SIZE cases the verifier does not know the buffer size a priori and therefore cannot blindly write * = val.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47757", "url": "https://ubuntu.com/security/CVE-2024-47757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential oob read in nilfs_btree_check_delete() The function nilfs_btree_check_delete(), which checks whether degeneration to direct mapping occurs before deleting a b-tree entry, causes memory access outside the block buffer when retrieving the maximum key if the root node has no entries. This does not usually happen because b-tree mappings with 0 child nodes are never created by mkfs.nilfs2 or nilfs2 itself. However, it can happen if the b-tree root node read from a device is configured that way, so fix this potential issue by adding a check for that case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47699", "url": "https://ubuntu.com/security/CVE-2024-47699", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential null-ptr-deref in nilfs_btree_insert() Patch series \"nilfs2: fix potential issues with empty b-tree nodes\". This series addresses three potential issues with empty b-tree nodes that can occur with corrupted filesystem images, including one recently discovered by syzbot. This patch (of 3): If a b-tree is broken on the device, and the b-tree height is greater than 2 (the level of the root node is greater than 1) even if the number of child nodes of the b-tree root is 0, a NULL pointer dereference occurs in nilfs_btree_prepare_insert(), which is called from nilfs_btree_insert(). This is because, when the number of child nodes of the b-tree root is 0, nilfs_btree_do_lookup() does not set the block buffer head in any of path[x].bp_bh, leaving it as the initial value of NULL, but if the level of the b-tree root node is greater than 1, nilfs_btree_get_nonroot_node(), which accesses the buffer memory of path[x].bp_bh, is called. Fix this issue by adding a check to nilfs_btree_root_broken(), which performs sanity checks when reading the root node from the device, to detect this inconsistency. Thanks to Lizhi Xu for trying to solve the bug and clarifying the cause early on.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47700", "url": "https://ubuntu.com/security/CVE-2024-47700", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: check stripe size compatibility on remount as well We disable stripe size in __ext4_fill_super if it is not a multiple of the cluster ratio however this check is missed when trying to remount. This can leave us with cases where stripe < cluster_ratio after remount:set making EXT4_B2C(sbi->s_stripe) become 0 that can cause some unforeseen bugs like divide by 0. Fix that by adding the check in remount path as well.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47701", "url": "https://ubuntu.com/security/CVE-2024-47701", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid OOB when system.data xattr changes underneath the filesystem When looking up for an entry in an inlined directory, if e_value_offs is changed underneath the filesystem by some change in the block device, it will lead to an out-of-bounds access that KASAN detects as an UAF. EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none. loop0: detected capacity change from 2048 to 2047 ================================================================== BUG: KASAN: use-after-free in ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 Read of size 1 at addr ffff88803e91130f by task syz-executor269/5103 CPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 Not tainted 6.11.0-rc4-syzkaller #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:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 ext4_find_inline_entry+0x4be/0x5e0 fs/ext4/inline.c:1697 __ext4_find_entry+0x2b4/0x1b30 fs/ext4/namei.c:1573 ext4_lookup_entry fs/ext4/namei.c:1727 [inline] ext4_lookup+0x15f/0x750 fs/ext4/namei.c:1795 lookup_one_qstr_excl+0x11f/0x260 fs/namei.c:1633 filename_create+0x297/0x540 fs/namei.c:3980 do_symlinkat+0xf9/0x3a0 fs/namei.c:4587 __do_sys_symlinkat fs/namei.c:4610 [inline] __se_sys_symlinkat fs/namei.c:4607 [inline] __x64_sys_symlinkat+0x95/0xb0 fs/namei.c:4607 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:0x7f3e73ced469 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff4d40c258 EFLAGS: 00000246 ORIG_RAX: 000000000000010a RAX: ffffffffffffffda RBX: 0032656c69662f2e RCX: 00007f3e73ced469 RDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0 RBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290 R10: 0023706f6f6c2f76 R11: 0000000000000246 R12: 00007fff4d40c27c R13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0 Calling ext4_xattr_ibody_find right after reading the inode with ext4_get_inode_loc will lead to a check of the validity of the xattrs, avoiding this problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49850", "url": "https://ubuntu.com/security/CVE-2024-49850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: correctly handle malformed BPF_CORE_TYPE_ID_LOCAL relos In case of malformed relocation record of kind BPF_CORE_TYPE_ID_LOCAL referencing a non-existing BTF type, function bpf_core_calc_relo_insn would cause a null pointer deference. Fix this by adding a proper check upper in call stack, as malformed relocation records could be passed from user space. Simplest reproducer is a program: r0 = 0 exit With a single relocation record: .insn_off = 0, /* patch first instruction */ .type_id = 100500, /* this type id does not exist */ .access_str_off = 6, /* offset of string \"0\" */ .kind = BPF_CORE_TYPE_ID_LOCAL, See the link for original reproducer or next commit for a test case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47702", "url": "https://ubuntu.com/security/CVE-2024-47702", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fail verification for sign-extension of packet data/data_end/data_meta syzbot reported a kernel crash due to commit 1f1e864b6555 (\"bpf: Handle sign-extenstin ctx member accesses\"). The reason is due to sign-extension of 32-bit load for packet data/data_end/data_meta uapi field. The original code looks like: r2 = *(s32 *)(r1 + 76) /* load __sk_buff->data */ r3 = *(u32 *)(r1 + 80) /* load __sk_buff->data_end */ r0 = r2 r0 += 8 if r3 > r0 goto +1 ... Note that __sk_buff->data load has 32-bit sign extension. After verification and convert_ctx_accesses(), the final asm code looks like: r2 = *(u64 *)(r1 +208) r2 = (s32)r2 r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 ... Note that 'r2 = (s32)r2' may make the kernel __sk_buff->data address invalid which may cause runtime failure. Currently, in C code, typically we have void *data = (void *)(long)skb->data; void *data_end = (void *)(long)skb->data_end; ... and it will generate r2 = *(u64 *)(r1 +208) r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 If we allow sign-extension, void *data = (void *)(long)(int)skb->data; void *data_end = (void *)(long)skb->data_end; ... the generated code looks like r2 = *(u64 *)(r1 +208) r2 <<= 32 r2 s>>= 32 r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 and this will cause verification failure since \"r2 <<= 32\" is not allowed as \"r2\" is a packet pointer. To fix this issue for case r2 = *(s32 *)(r1 + 76) /* load __sk_buff->data */ this patch added additional checking in is_valid_access() callback function for packet data/data_end/data_meta access. If those accesses are with sign-extenstion, the verification will fail. [1] https://lore.kernel.org/bpf/000000000000c90eee061d236d37@google.com/", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47703", "url": "https://ubuntu.com/security/CVE-2024-47703", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, lsm: Add check for BPF LSM return value A bpf prog returning a positive number attached to file_alloc_security hook makes kernel panic. This happens because file system can not filter out the positive number returned by the LSM prog using IS_ERR, and misinterprets this positive number as a file pointer. Given that hook file_alloc_security never returned positive number before the introduction of BPF LSM, and other BPF LSM hooks may encounter similar issues, this patch adds LSM return value check in verifier, to ensure no unexpected value is returned.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49851", "url": "https://ubuntu.com/security/CVE-2024-49851", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: Clean up TPM space after command failure tpm_dev_transmit prepares the TPM space before attempting command transmission. However if the command fails no rollback of this preparation is done. This can result in transient handles being leaked if the device is subsequently closed with no further commands performed. Fix this by flushing the space in the event of command transmission failure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47723", "url": "https://ubuntu.com/security/CVE-2024-47723", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: fix out-of-bounds in dbNextAG() and diAlloc() In dbNextAG() , there is no check for the case where bmp->db_numag is greater or same than MAXAG due to a polluted image, which causes an out-of-bounds. Therefore, a bounds check should be added in dbMount(). And in dbNextAG(), a check for the case where agpref is greater than bmp->db_numag should be added, so an out-of-bounds exception should be prevented. Additionally, a check for the case where agno is greater or same than MAXAG should be added in diAlloc() to prevent out-of-bounds.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49852", "url": "https://ubuntu.com/security/CVE-2024-49852", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: elx: libefc: Fix potential use after free in efc_nport_vport_del() The kref_put() function will call nport->release if the refcount drops to zero. The nport->release release function is _efc_nport_free() which frees \"nport\". But then we dereference \"nport\" on the next line which is a use after free. Re-order these lines to avoid the use after free.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47720", "url": "https://ubuntu.com/security/CVE-2024-47720", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for set_output_gamma in dcn30_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn30_set_output_transfer_func function. Previously, set_output_gamma was being checked for nullity at line 386, but then it was being dereferenced without any nullity check at line 401. This could potentially lead to a null pointer dereference error if set_output_gamma is indeed null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a nullity check for set_output_gamma before the call to set_output_gamma at line 401. If set_output_gamma is null, we log an error message and do not call the function. This fix prevents a potential null pointer dereference error. drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:401 dcn30_set_output_transfer_func() error: we previously assumed 'mpc->funcs->set_output_gamma' could be null (see line 386) drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c 373 bool dcn30_set_output_transfer_func(struct dc *dc, 374 struct pipe_ctx *pipe_ctx, 375 const struct dc_stream_state *stream) 376 { 377 int mpcc_id = pipe_ctx->plane_res.hubp->inst; 378 struct mpc *mpc = pipe_ctx->stream_res.opp->ctx->dc->res_pool->mpc; 379 const struct pwl_params *params = NULL; 380 bool ret = false; 381 382 /* program OGAM or 3DLUT only for the top pipe*/ 383 if (pipe_ctx->top_pipe == NULL) { 384 /*program rmu shaper and 3dlut in MPC*/ 385 ret = dcn30_set_mpc_shaper_3dlut(pipe_ctx, stream); 386 if (ret == false && mpc->funcs->set_output_gamma) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If this is NULL 387 if (stream->out_transfer_func.type == TF_TYPE_HWPWL) 388 params = &stream->out_transfer_func.pwl; 389 else if (pipe_ctx->stream->out_transfer_func.type == 390 TF_TYPE_DISTRIBUTED_POINTS && 391 cm3_helper_translate_curve_to_hw_format( 392 &stream->out_transfer_func, 393 &mpc->blender_params, false)) 394 params = &mpc->blender_params; 395 /* there are no ROM LUTs in OUTGAM */ 396 if (stream->out_transfer_func.type == TF_TYPE_PREDEFINED) 397 BREAK_TO_DEBUGGER(); 398 } 399 } 400 --> 401 mpc->funcs->set_output_gamma(mpc, mpcc_id, params); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Then it will crash 402 return ret; 403 }", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47704", "url": "https://ubuntu.com/security/CVE-2024-47704", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check link_res->hpo_dp_link_enc before using it [WHAT & HOW] Functions dp_enable_link_phy and dp_disable_link_phy can pass link_res without initializing hpo_dp_link_enc and it is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49853", "url": "https://ubuntu.com/security/CVE-2024-49853", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix double free in OPTEE transport Channels can be shared between protocols, avoid freeing the same channel descriptors twice when unloading the stack.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47705", "url": "https://ubuntu.com/security/CVE-2024-47705", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix potential invalid pointer dereference in blk_add_partition The blk_add_partition() function initially used a single if-condition (IS_ERR(part)) to check for errors when adding a partition. This was modified to handle the specific case of -ENXIO separately, allowing the function to proceed without logging the error in this case. However, this change unintentionally left a path where md_autodetect_dev() could be called without confirming that part is a valid pointer. This commit separates the error handling logic by splitting the initial if-condition, improving code readability and handling specific error scenarios explicitly. The function now distinguishes the general error case from -ENXIO without altering the existing behavior of md_autodetect_dev() calls.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47736", "url": "https://ubuntu.com/security/CVE-2024-47736", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: handle overlapped pclusters out of crafted images properly syzbot reported a task hang issue due to a deadlock case where it is waiting for the folio lock of a cached folio that will be used for cache I/Os. After looking into the crafted fuzzed image, I found it's formed with several overlapped big pclusters as below: Ext: logical offset | length : physical offset | length 0: 0.. 16384 | 16384 : 151552.. 167936 | 16384 1: 16384.. 32768 | 16384 : 155648.. 172032 | 16384 2: 32768.. 49152 | 16384 : 537223168.. 537239552 | 16384 ... Here, extent 0/1 are physically overlapped although it's entirely _impossible_ for normal filesystem images generated by mkfs. First, managed folios containing compressed data will be marked as up-to-date and then unlocked immediately (unlike in-place folios) when compressed I/Os are complete. If physical blocks are not submitted in the incremental order, there should be separate BIOs to avoid dependency issues. However, the current code mis-arranges z_erofs_fill_bio_vec() and BIO submission which causes unexpected BIO waits. Second, managed folios will be connected to their own pclusters for efficient inter-queries. However, this is somewhat hard to implement easily if overlapped big pclusters exist. Again, these only appear in fuzzed images so let's simply fall back to temporary short-lived pages for correctness. Additionally, it justifies that referenced managed folios cannot be truncated for now and reverts part of commit 2080ca1ed3e4 (\"erofs: tidy up `struct z_erofs_bvec`\") for simplicity although it shouldn't be any difference.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47706", "url": "https://ubuntu.com/security/CVE-2024-47706", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block, bfq: fix possible UAF for bfqq->bic with merge chain 1) initial state, three tasks: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t\t | ? | ?\t\t | ? \t\t | | | |\t\t | | \t\t V | V |\t\t V | \t\t bfqq1 bfqq2\t\t bfqq3 process ref:\t 1\t\t 1\t\t 1 2) bfqq1 merged to bfqq2: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t\t | |\t\t | ? \t\t \\--------------\\|\t\t | | \t\t V\t\t V | \t\t bfqq1--------->bfqq2\t\t bfqq3 process ref:\t 0\t\t 2\t\t 1 3) bfqq2 merged to bfqq3: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t here -> ? |\t\t | \t\t \\--------------\\ \\-------------\\| \t\t V\t\t V \t\t bfqq1--------->bfqq2---------->bfqq3 process ref:\t 0\t\t 1\t\t 3 In this case, IO from Process 1 will get bfqq2 from BIC1 first, and then get bfqq3 through merge chain, and finially handle IO by bfqq3. Howerver, current code will think bfqq2 is owned by BIC1, like initial state, and set bfqq2->bic to BIC1. bfq_insert_request -> by Process 1 bfqq = bfq_init_rq(rq) bfqq = bfq_get_bfqq_handle_split bfqq = bic_to_bfqq -> get bfqq2 from BIC1 bfqq->ref++ rq->elv.priv[0] = bic rq->elv.priv[1] = bfqq if (bfqq_process_refs(bfqq) == 1) bfqq->bic = bic -> record BIC1 to bfqq2 __bfq_insert_request new_bfqq = bfq_setup_cooperator -> get bfqq3 from bfqq2->new_bfqq bfqq_request_freed(bfqq) new_bfqq->ref++ rq->elv.priv[1] = new_bfqq -> handle IO by bfqq3 Fix the problem by checking bfqq is from merge chain fist. And this might fix a following problem reported by our syzkaller(unreproducible): ================================================================== BUG: KASAN: slab-use-after-free in bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] BUG: KASAN: slab-use-after-free in bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] BUG: KASAN: slab-use-after-free in bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 Write of size 1 at addr ffff888123839eb8 by task kworker/0:1H/18595 CPU: 0 PID: 18595 Comm: kworker/0:1H Tainted: G L 6.6.0-07439-gba2303cacfda #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Workqueue: kblockd blk_mq_requeue_work Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [inline] print_report+0x10d/0x610 mm/kasan/report.c:475 kasan_report+0x8e/0xc0 mm/kasan/report.c:588 bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 bfq_get_bfqq_handle_split+0x169/0x5d0 block/bfq-iosched.c:6757 bfq_init_rq block/bfq-iosched.c:6876 [inline] bfq_insert_request block/bfq-iosched.c:6254 [inline] bfq_insert_requests+0x1112/0x5cf0 block/bfq-iosched.c:6304 blk_mq_insert_request+0x290/0x8d0 block/blk-mq.c:2593 blk_mq_requeue_work+0x6bc/0xa70 block/blk-mq.c:1502 process_one_work kernel/workqueue.c:2627 [inline] process_scheduled_works+0x432/0x13f0 kernel/workqueue.c:2700 worker_thread+0x6f2/0x1160 kernel/workqueue.c:2781 kthread+0x33c/0x440 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:305 Allocated by task 20776: kasan_save_stack+0x20/0x40 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 __kasan_slab_alloc+0x87/0x90 mm/kasan/common.c:328 kasan_slab_alloc include/linux/kasan.h:188 [inline] slab_post_alloc_hook mm/slab.h:763 [inline] slab_alloc_node mm/slub.c:3458 [inline] kmem_cache_alloc_node+0x1a4/0x6f0 mm/slub.c:3503 ioc_create_icq block/blk-ioc.c:370 [inline] ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49855", "url": "https://ubuntu.com/security/CVE-2024-49855", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: fix race between timeout and normal completion If request timetout is handled by nbd_requeue_cmd(), normal completion has to be stopped for avoiding to complete this requeued request, other use-after-free can be triggered. Fix the race by clearing NBD_CMD_INFLIGHT in nbd_requeue_cmd(), meantime make sure that cmd->lock is grabbed for clearing the flag and the requeue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47707", "url": "https://ubuntu.com/security/CVE-2024-47707", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev() Blamed commit accidentally removed a check for rt->rt6i_idev being NULL, as spotted by syzbot: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 UID: 0 PID: 10998 Comm: syz-executor Not tainted 6.11.0-rc6-syzkaller-00208-g625403177711 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 RBP: ffffc900047375d0 R08: 0000000000000003 R09: fffff520008e6e8c R10: dffffc0000000000 R11: fffff520008e6e8c R12: 1ffff1100fdf8f18 R13: ffff88807efc7998 R14: 0000000000000000 R15: ffff88807efc7930 FS: 0000000000000000(0000) GS:ffff8880b8900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020002a80 CR3: 0000000022f62000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: addrconf_ifdown+0x15d/0x1bd0 net/ipv6/addrconf.c:3856 addrconf_notify+0x3cb/0x1020 notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93 call_netdevice_notifiers_extack net/core/dev.c:2032 [inline] call_netdevice_notifiers net/core/dev.c:2046 [inline] unregister_netdevice_many_notify+0xd81/0x1c40 net/core/dev.c:11352 unregister_netdevice_many net/core/dev.c:11414 [inline] unregister_netdevice_queue+0x303/0x370 net/core/dev.c:11289 unregister_netdevice include/linux/netdevice.h:3129 [inline] __tun_detach+0x6b9/0x1600 drivers/net/tun.c:685 tun_detach drivers/net/tun.c:701 [inline] tun_chr_close+0x108/0x1b0 drivers/net/tun.c:3510 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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:0x7f1acc77def9 Code: Unable to access opcode bytes at 0x7f1acc77decf. RSP: 002b:00007ffeb26fa738 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1acc77def9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000043 RBP: 00007f1acc7dd508 R08: 00007ffeb26f84d7 R09: 0000000000000003 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 0000000000000003 R14: 00000000ffffffff R15: 00007ffeb26fa8e0 Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 R ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47708", "url": "https://ubuntu.com/security/CVE-2024-47708", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netkit: Assign missing bpf_net_context During the introduction of struct bpf_net_context handling for XDP-redirect, the netkit driver has been missed, which also requires it because NETKIT_REDIRECT invokes skb_do_redirect() which is accessing the per-CPU variables. Otherwise we see the following crash: \tBUG: kernel NULL pointer dereference, address: 0000000000000038 \tbpf_redirect() \tnetkit_xmit() \tdev_hard_start_xmit() Set the bpf_net_context before invoking netkit_xmit() program within the netkit driver.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47709", "url": "https://ubuntu.com/security/CVE-2024-47709", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: Clear bo->bcm_proc_read after remove_proc_entry(). syzbot reported a warning in bcm_release(). [0] The blamed change fixed another warning that is triggered when connect() is issued again for a socket whose connect()ed device has been unregistered. However, if the socket is just close()d without the 2nd connect(), the remaining bo->bcm_proc_read triggers unnecessary remove_proc_entry() in bcm_release(). Let's clear bo->bcm_proc_read after remove_proc_entry() in bcm_notify(). [0] name '4986' WARNING: CPU: 0 PID: 5234 at fs/proc/generic.c:711 remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Modules linked in: CPU: 0 UID: 0 PID: 5234 Comm: syz-executor606 Not tainted 6.11.0-rc5-syzkaller-00178-g5517ae241919 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Code: ff eb 05 e8 cb 1e 5e ff 48 8b 5c 24 10 48 c7 c7 e0 f7 aa 8e e8 2a 38 8e 09 90 48 c7 c7 60 3a 1b 8c 48 89 de e8 da 42 20 ff 90 <0f> 0b 90 90 48 8b 44 24 18 48 c7 44 24 40 0e 36 e0 45 49 c7 04 07 RSP: 0018:ffffc9000345fa20 EFLAGS: 00010246 RAX: 2a2d0aee2eb64600 RBX: ffff888032f1f548 RCX: ffff888029431e00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000345fb08 R08: ffffffff8155b2f2 R09: 1ffff1101710519a R10: dffffc0000000000 R11: ffffed101710519b R12: ffff888011d38640 R13: 0000000000000004 R14: 0000000000000000 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8880b8800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcfb52722f0 CR3: 000000000e734000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: bcm_release+0x250/0x880 net/can/bcm.c:1578 __sock_release net/socket.c:659 [inline] sock_close+0xbc/0x240 net/socket.c:1421 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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:0x7fcfb51ee969 Code: Unable to access opcode bytes at 0x7fcfb51ee93f. RSP: 002b:00007ffce0109ca8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fcfb51ee969 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 00007fcfb526f3b0 R08: ffffffffffffffb8 R09: 0000555500000000 R10: 0000555500000000 R11: 0000000000000246 R12: 00007fcfb526f3b0 R13: 0000000000000000 R14: 00007fcfb5271ee0 R15: 00007fcfb51bf160 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47710", "url": "https://ubuntu.com/security/CVE-2024-47710", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sock_map: Add a cond_resched() in sock_hash_free() Several syzbot soft lockup reports all have in common sock_hash_free() If a map with a large number of buckets is destroyed, we need to yield the cpu when needed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47711", "url": "https://ubuntu.com/security/CVE-2024-47711", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Don't return OOB skb in manage_oob(). syzbot reported use-after-free in unix_stream_recv_urg(). [0] The scenario is 1. send(MSG_OOB) 2. recv(MSG_OOB) -> The consumed OOB remains in recv queue 3. send(MSG_OOB) 4. recv() -> manage_oob() returns the next skb of the consumed OOB -> This is also OOB, but unix_sk(sk)->oob_skb is not cleared 5. recv(MSG_OOB) -> unix_sk(sk)->oob_skb is used but already freed The recent commit 8594d9b85c07 (\"af_unix: Don't call skb_get() for OOB skb.\") uncovered the issue. If the OOB skb is consumed and the next skb is peeked in manage_oob(), we still need to check if the skb is OOB. Let's do so by falling back to the following checks in manage_oob() and add the test case in selftest. Note that we need to add a similar check for SIOCATMARK. [0]: BUG: KASAN: slab-use-after-free in unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959 Read of size 4 at addr ffff8880326abcc4 by task syz-executor178/5235 CPU: 0 UID: 0 PID: 5235 Comm: syz-executor178 Not tainted 6.11.0-rc5-syzkaller-00742-gfbdaffe41adc #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959 unix_stream_recv_urg+0x1df/0x320 net/unix/af_unix.c:2640 unix_stream_read_generic+0x2456/0x2520 net/unix/af_unix.c:2778 unix_stream_recvmsg+0x22b/0x2c0 net/unix/af_unix.c:2996 sock_recvmsg_nosec net/socket.c:1046 [inline] sock_recvmsg+0x22f/0x280 net/socket.c:1068 ____sys_recvmsg+0x1db/0x470 net/socket.c:2816 ___sys_recvmsg net/socket.c:2858 [inline] __sys_recvmsg+0x2f0/0x3e0 net/socket.c:2888 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:0x7f5360d6b4e9 Code: 48 83 c4 28 c3 e8 37 17 00 00 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff29b3a458 EFLAGS: 00000246 ORIG_RAX: 000000000000002f RAX: ffffffffffffffda RBX: 00007fff29b3a638 RCX: 00007f5360d6b4e9 RDX: 0000000000002001 RSI: 0000000020000640 RDI: 0000000000000003 RBP: 00007f5360dde610 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 00007fff29b3a628 R14: 0000000000000001 R15: 0000000000000001 Allocated by task 5235: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:312 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slub.c:3988 [inline] slab_alloc_node mm/slub.c:4037 [inline] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4080 __alloc_skb+0x1c3/0x440 net/core/skbuff.c:667 alloc_skb include/linux/skbuff.h:1320 [inline] alloc_skb_with_frags+0xc3/0x770 net/core/skbuff.c:6528 sock_alloc_send_pskb+0x91a/0xa60 net/core/sock.c:2815 sock_alloc_send_skb include/net/sock.h:1778 [inline] queue_oob+0x108/0x680 net/unix/af_unix.c:2198 unix_stream_sendmsg+0xd24/0xf80 net/unix/af_unix.c:2351 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2680 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 Freed by task 5235: kasan_save_stack mm/kasan/common.c:47 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47712", "url": "https://ubuntu.com/security/CVE-2024-47712", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: fix potential RCU dereference issue in wilc_parse_join_bss_param In the `wilc_parse_join_bss_param` function, the TSF field of the `ies` structure is accessed after the RCU read-side critical section is unlocked. According to RCU usage rules, this is illegal. Reusing this pointer can lead to unpredictable behavior, including accessing memory that has been updated or causing use-after-free issues. This possible bug was identified using a static analysis tool developed by myself, specifically designed to detect RCU-related issues. To address this, the TSF value is now stored in a local variable `ies_tsf` before the RCU lock is released. The `param->tsf_lo` field is then assigned using this local variable, ensuring that the TSF value is safely accessed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47713", "url": "https://ubuntu.com/security/CVE-2024-47713", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop() Since '__dev_queue_xmit()' should be called with interrupts enabled, the following backtrace: ieee80211_do_stop() ... spin_lock_irqsave(&local->queue_stop_reason_lock, flags) ... ieee80211_free_txskb() ieee80211_report_used_skb() ieee80211_report_ack_skb() cfg80211_mgmt_tx_status_ext() nl80211_frame_tx_status() genlmsg_multicast_netns() genlmsg_multicast_netns_filtered() nlmsg_multicast_filtered() \t netlink_broadcast_filtered() \t do_one_broadcast() \t netlink_broadcast_deliver() \t __netlink_sendskb() \t netlink_deliver_tap() \t __netlink_deliver_tap_skb() \t dev_queue_xmit() \t __dev_queue_xmit() ; with IRQS disabled ... spin_unlock_irqrestore(&local->queue_stop_reason_lock, flags) issues the warning (as reported by syzbot reproducer): WARNING: CPU: 2 PID: 5128 at kernel/softirq.c:362 __local_bh_enable_ip+0xc3/0x120 Fix this by implementing a two-phase skb reclamation in 'ieee80211_do_stop()', where actual work is performed outside of a section with interrupts disabled.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47730", "url": "https://ubuntu.com/security/CVE-2024-47730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/qm - inject error before stopping queue The master ooo cannot be completely closed when the accelerator core reports memory error. Therefore, the driver needs to inject the qm error to close the master ooo. Currently, the qm error is injected after stopping queue, memory may be released immediately after stopping queue, causing the device to access the released memory. Therefore, error is injected to close master ooo before stopping queue to ensure that the device does not access the released memory.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49856", "url": "https://ubuntu.com/security/CVE-2024-49856", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/sgx: Fix deadlock in SGX NUMA node search When the current node doesn't have an EPC section configured by firmware and all other EPC sections are used up, CPU can get stuck inside the while loop that looks for an available EPC page from remote nodes indefinitely, leading to a soft lockup. Note how nid_of_current will never be equal to nid in that while loop because nid_of_current is not set in sgx_numa_mask. Also worth mentioning is that it's perfectly fine for the firmware not to setup an EPC section on a node. While setting up an EPC section on each node can enhance performance, it is not a requirement for functionality. Rework the loop to start and end on *a* node that has SGX memory. This avoids the deadlock looking for the current SGX-lacking node to show up in the loop when it never will.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47714", "url": "https://ubuntu.com/security/CVE-2024-47714", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: use hweight16 to get correct tx antenna The chainmask is u16 so using hweight8 cannot get correct tx_ant. Without this patch, the tx_ant of band 2 would be -1 and lead to the following issue: BUG: KASAN: stack-out-of-bounds in mt7996_mcu_add_sta+0x12e0/0x16e0 [mt7996e]", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47715", "url": "https://ubuntu.com/security/CVE-2024-47715", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: fix oops on non-dbdc mt7986 mt7915_band_config() sets band_idx = 1 on the main phy for mt7986 with MT7975_ONE_ADIE or MT7976_ONE_ADIE. Commit 0335c034e726 (\"wifi: mt76: fix race condition related to checking tx queue fill status\") introduced a dereference of the phys array indirectly indexed by band_idx via wcid->phy_idx in mt76_wcid_cleanup(). This caused the following Oops on affected mt7986 devices: Unable to handle kernel read from unreadable memory at virtual address 0000000000000024 Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x00000005 CM = 0, WnR = 0 user pgtable: 4k pages, 39-bit VAs, pgdp=0000000042545000 [0000000000000024] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 Internal error: Oops: 0000000096000005 [#1] SMP Modules linked in: ... mt7915e mt76_connac_lib mt76 mac80211 cfg80211 ... CPU: 2 PID: 1631 Comm: hostapd Not tainted 5.15.150 #0 Hardware name: ZyXEL EX5700 (Telenor) (DT) pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mt76_wcid_cleanup+0x84/0x22c [mt76] lr : mt76_wcid_cleanup+0x64/0x22c [mt76] sp : ffffffc00a803700 x29: ffffffc00a803700 x28: ffffff80008f7300 x27: ffffff80003f3c00 x26: ffffff80000a7880 x25: ffffffc008c26e00 x24: 0000000000000001 x23: ffffffc000a68114 x22: 0000000000000000 x21: ffffff8004172cc8 x20: ffffffc00a803748 x19: ffffff8004152020 x18: 0000000000000000 x17: 00000000000017c0 x16: ffffffc008ef5000 x15: 0000000000000be0 x14: ffffff8004172e28 x13: ffffff8004172e28 x12: 0000000000000000 x11: 0000000000000000 x10: ffffff8004172e30 x9 : ffffff8004172e28 x8 : 0000000000000000 x7 : ffffff8004156020 x6 : 0000000000000000 x5 : 0000000000000031 x4 : 0000000000000000 x3 : 0000000000000001 x2 : 0000000000000000 x1 : ffffff80008f7300 x0 : 0000000000000024 Call trace: mt76_wcid_cleanup+0x84/0x22c [mt76] __mt76_sta_remove+0x70/0xbc [mt76] mt76_sta_state+0x8c/0x1a4 [mt76] mt7915_eeprom_get_power_delta+0x11e4/0x23a0 [mt7915e] drv_sta_state+0x144/0x274 [mac80211] sta_info_move_state+0x1cc/0x2a4 [mac80211] sta_set_sinfo+0xaf8/0xc24 [mac80211] sta_info_destroy_addr_bss+0x4c/0x6c [mac80211] ieee80211_color_change_finish+0x1c08/0x1e70 [mac80211] cfg80211_check_station_change+0x1360/0x4710 [cfg80211] genl_family_rcv_msg_doit+0xb4/0x110 genl_rcv_msg+0xd0/0x1bc netlink_rcv_skb+0x58/0x120 genl_rcv+0x34/0x50 netlink_unicast+0x1f0/0x2ec netlink_sendmsg+0x198/0x3d0 ____sys_sendmsg+0x1b0/0x210 ___sys_sendmsg+0x80/0xf0 __sys_sendmsg+0x44/0xa0 __arm64_sys_sendmsg+0x20/0x30 invoke_syscall.constprop.0+0x4c/0xe0 do_el0_svc+0x40/0xd0 el0_svc+0x14/0x4c el0t_64_sync_handler+0x100/0x110 el0t_64_sync+0x15c/0x160 Code: d2800002 910092c0 52800023 f9800011 (885f7c01) ---[ end trace 7e42dd9a39ed2281 ]--- Fix by using mt76_dev_phy() which will map band_idx to the correct phy for all hardware combinations.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49857", "url": "https://ubuntu.com/security/CVE-2024-49857", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: set the cipher for secured NDP ranging The cipher pointer is not set, but is derefereced trying to set its content, which leads to a NULL pointer dereference. Fix it by pointing to the cipher parameter before dereferencing.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47738", "url": "https://ubuntu.com/security/CVE-2024-47738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: don't use rate mask for offchannel TX either Like the commit ab9177d83c04 (\"wifi: mac80211: don't use rate mask for scanning\"), ignore incorrect settings to avoid no supported rate warning reported by syzbot. The syzbot did bisect and found cause is commit 9df66d5b9f45 (\"cfg80211: fix default HE tx bitrate mask in 2G band\"), which however corrects bitmask of HE MCS and recognizes correctly settings of empty legacy rate plus HE MCS rate instead of returning -EINVAL. As suggestions [1], follow the change of SCAN TX to consider this case of offchannel TX as well. [1] https://lore.kernel.org/linux-wireless/6ab2dc9c3afe753ca6fdcdd1421e7a1f47e87b84.camel@sipsolutions.net/T/#m2ac2a6d2be06a37c9c47a3d8a44b4f647ed4f024", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47731", "url": "https://ubuntu.com/security/CVE-2024-47731", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers/perf: Fix ali_drw_pmu driver interrupt status clearing The alibaba_uncore_pmu driver forgot to clear all interrupt status in the interrupt processing function. After the PMU counter overflow interrupt occurred, an interrupt storm occurred, causing the system to hang. Therefore, clear the correct interrupt status in the interrupt handling function to fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49862", "url": "https://ubuntu.com/security/CVE-2024-49862", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powercap: intel_rapl: Fix off by one in get_rpi() The rp->priv->rpi array is either rpi_msr or rpi_tpmi which have NR_RAPL_PRIMITIVES number of elements. Thus the > needs to be >= to prevent an off by one access.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47716", "url": "https://ubuntu.com/security/CVE-2024-47716", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: 9410/1: vfp: Use asm volatile in fmrx/fmxr macros Floating point instructions in userspace can crash some arm kernels built with clang/LLD 17.0.6: BUG: unsupported FP instruction in kernel mode FPEXC == 0xc0000780 Internal error: Oops - undefined instruction: 0 [#1] ARM CPU: 0 PID: 196 Comm: vfp-reproducer Not tainted 6.10.0 #1 Hardware name: BCM2835 PC is at vfp_support_entry+0xc8/0x2cc LR is at do_undefinstr+0xa8/0x250 pc : [] lr : [] psr: a0000013 sp : dc8d1f68 ip : 60000013 fp : bedea19c r10: ec532b17 r9 : 00000010 r8 : 0044766c r7 : c0000780 r6 : ec532b17 r5 : c1c13800 r4 : dc8d1fb0 r3 : c10072c4 r2 : c0101c88 r1 : ec532b17 r0 : 0044766c Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 00c5387d Table: 0251c008 DAC: 00000051 Register r0 information: non-paged memory Register r1 information: vmalloc memory Register r2 information: non-slab/vmalloc memory Register r3 information: non-slab/vmalloc memory Register r4 information: 2-page vmalloc region Register r5 information: slab kmalloc-cg-2k Register r6 information: vmalloc memory Register r7 information: non-slab/vmalloc memory Register r8 information: non-paged memory Register r9 information: zero-size pointer Register r10 information: vmalloc memory Register r11 information: non-paged memory Register r12 information: non-paged memory Process vfp-reproducer (pid: 196, stack limit = 0x61aaaf8b) Stack: (0xdc8d1f68 to 0xdc8d2000) 1f60: 0000081f b6f69300 0000000f c10073f4 c10072c4 dc8d1fb0 1f80: ec532b17 0c532b17 0044766c b6f9ccd8 00000000 c010a80c 00447670 60000010 1fa0: ffffffff c1c13800 00c5387d c0100f10 b6f68af8 00448fc0 00000000 bedea188 1fc0: bedea314 00000001 00448ebc b6f9d000 00447608 b6f9ccd8 00000000 bedea19c 1fe0: bede9198 bedea188 b6e1061c 0044766c 60000010 ffffffff 00000000 00000000 Call trace: [] (vfp_support_entry) from [] (do_undefinstr+0xa8/0x250) [] (do_undefinstr) from [] (__und_usr+0x70/0x80) Exception stack(0xdc8d1fb0 to 0xdc8d1ff8) 1fa0: b6f68af8 00448fc0 00000000 bedea188 1fc0: bedea314 00000001 00448ebc b6f9d000 00447608 b6f9ccd8 00000000 bedea19c 1fe0: bede9198 bedea188 b6e1061c 0044766c 60000010 ffffffff Code: 0a000061 e3877202 e594003c e3a09010 (eef16a10) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Fatal exception in interrupt ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]--- This is a minimal userspace reproducer on a Raspberry Pi Zero W: #include #include int main(void) { double v = 1.0; printf(\"%fn\", NAN + *(volatile double *)&v); return 0; } Another way to consistently trigger the oops is: calvin@raspberry-pi-zero-w ~$ python -c \"import json\" The bug reproduces only when the kernel is built with DYNAMIC_DEBUG=n, because the pr_debug() calls act as barriers even when not activated. This is the output from the same kernel source built with the same compiler and DYNAMIC_DEBUG=y, where the userspace reproducer works as expected: VFP: bounce: trigger ec532b17 fpexc c0000780 VFP: emulate: INST=0xee377b06 SCR=0x00000000 VFP: bounce: trigger eef1fa10 fpexc c0000780 VFP: emulate: INST=0xeeb40b40 SCR=0x00000000 VFP: raising exceptions 30000000 calvin@raspberry-pi-zero-w ~$ ./vfp-reproducer nan Crudely grepping for vmsr/vmrs instructions in the otherwise nearly idential text for vfp_support_entry() makes the problem obvious: vmlinux.llvm.good [0xc0101cb8] <+48>: vmrs r7, fpexc vmlinux.llvm.good [0xc0101cd8] <+80>: vmsr fpexc, r0 vmlinux.llvm.good [0xc0101d20 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47717", "url": "https://ubuntu.com/security/CVE-2024-47717", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RISC-V: KVM: Don't zero-out PMU snapshot area before freeing data With the latest Linux-6.11-rc3, the below NULL pointer crash is observed when SBI PMU snapshot is enabled for the guest and the guest is forcefully powered-off. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000508 Oops [#1] Modules linked in: kvm CPU: 0 UID: 0 PID: 61 Comm: term-poll Not tainted 6.11.0-rc3-00018-g44d7178dd77a #3 Hardware name: riscv-virtio,qemu (DT) epc : __kvm_write_guest_page+0x94/0xa6 [kvm] ra : __kvm_write_guest_page+0x54/0xa6 [kvm] epc : ffffffff01590e98 ra : ffffffff01590e58 sp : ffff8f80001f39b0 gp : ffffffff81512a60 tp : ffffaf80024872c0 t0 : ffffaf800247e000 t1 : 00000000000007e0 t2 : 0000000000000000 s0 : ffff8f80001f39f0 s1 : 00007fff89ac4000 a0 : ffffffff015dd7e8 a1 : 0000000000000086 a2 : 0000000000000000 a3 : ffffaf8000000000 a4 : ffffaf80024882c0 a5 : 0000000000000000 a6 : ffffaf800328d780 a7 : 00000000000001cc s2 : ffffaf800197bd00 s3 : 00000000000828c4 s4 : ffffaf800248c000 s5 : ffffaf800247d000 s6 : 0000000000001000 s7 : 0000000000001000 s8 : 0000000000000000 s9 : 00007fff861fd500 s10: 0000000000000001 s11: 0000000000800000 t3 : 00000000000004d3 t4 : 00000000000004d3 t5 : ffffffff814126e0 t6 : ffffffff81412700 status: 0000000200000120 badaddr: 0000000000000508 cause: 000000000000000d [] __kvm_write_guest_page+0x94/0xa6 [kvm] [] kvm_vcpu_write_guest+0x56/0x90 [kvm] [] kvm_pmu_clear_snapshot_area+0x42/0x7e [kvm] [] kvm_riscv_vcpu_pmu_deinit.part.0+0xe0/0x14e [kvm] [] kvm_riscv_vcpu_pmu_deinit+0x1a/0x24 [kvm] [] kvm_arch_vcpu_destroy+0x28/0x4c [kvm] [] kvm_destroy_vcpus+0x5a/0xda [kvm] [] kvm_arch_destroy_vm+0x14/0x28 [kvm] [] kvm_destroy_vm+0x168/0x2a0 [kvm] [] kvm_put_kvm+0x3c/0x58 [kvm] [] kvm_vm_release+0x22/0x2e [kvm] Clearly, the kvm_vcpu_write_guest() function is crashing because it is being called from kvm_pmu_clear_snapshot_area() upon guest tear down. To address the above issue, simplify the kvm_pmu_clear_snapshot_area() to not zero-out PMU snapshot area from kvm_pmu_clear_snapshot_area() because the guest is anyway being tore down. The kvm_pmu_clear_snapshot_area() is also called when guest changes PMU snapshot area of a VCPU but even in this case the previous PMU snaphsot area must not be zeroed-out because the guest might have reclaimed the pervious PMU snapshot area for some other purpose.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47721", "url": "https://ubuntu.com/security/CVE-2024-47721", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: remove unused C2H event ID RTW89_MAC_C2H_FUNC_READ_WOW_CAM to prevent out-of-bounds reading The handler of firmware C2H event RTW89_MAC_C2H_FUNC_READ_WOW_CAM isn't implemented, but driver expects number of handlers is NUM_OF_RTW89_MAC_C2H_FUNC_WOW causing out-of-bounds access. Fix it by removing ID. Addresses-Coverity-ID: 1598775 (\"Out-of-bounds read\")", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47732", "url": "https://ubuntu.com/security/CVE-2024-47732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: iaa - Fix potential use after free bug The free_device_compression_mode(iaa_device, device_mode) function frees \"device_mode\" but it iss passed to iaa_compression_modes[i]->free() a few lines later resulting in a use after free. The good news is that, so far as I can tell, nothing implements the ->free() function and the use after free happens in dead code. But, with this fix, when something does implement it, we'll be ready. :)", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47718", "url": "https://ubuntu.com/security/CVE-2024-47718", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: always wait for both firmware loading attempts In 'rtw_wait_firmware_completion()', always wait for both (regular and wowlan) firmware loading attempts. Otherwise if 'rtw_usb_intf_init()' has failed in 'rtw_usb_probe()', 'rtw_usb_disconnect()' may issue 'ieee80211_free_hw()' when one of 'rtw_load_firmware_cb()' (usually the wowlan one) is still in progress, causing UAF detected by KASAN.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47724", "url": "https://ubuntu.com/security/CVE-2024-47724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: use work queue to process beacon tx event Commit 3a415daa3e8b (\"wifi: ath11k: add P2P IE in beacon template\") from Feb 28, 2024 (linux-next), leads to the following Smatch static checker warning: drivers/net/wireless/ath/ath11k/wmi.c:1742 ath11k_wmi_p2p_go_bcn_ie() warn: sleeping in atomic context The reason is that ath11k_bcn_tx_status_event() will directly call might sleep function ath11k_wmi_cmd_send() during RCU read-side critical sections. The call trace is like: ath11k_bcn_tx_status_event() -> rcu_read_lock() -> ath11k_mac_bcn_tx_event() \t-> ath11k_mac_setup_bcn_tmpl() \t…… \t\t-> ath11k_wmi_bcn_tmpl() \t\t\t-> ath11k_wmi_cmd_send() -> rcu_read_unlock() Commit 886433a98425 (\"ath11k: add support for BSS color change\") added the ath11k_mac_bcn_tx_event(), commit 01e782c89108 (\"ath11k: fix warning of RCU usage for ath11k_mac_get_arvif_by_vdev_id()\") added the RCU lock to avoid warning but also introduced this BUG. Use work queue to avoid directly calling ath11k_mac_bcn_tx_event() during RCU critical sections. No need to worry about the deletion of vif because cancel_work_sync() will drop the work if it doesn't start or block vif deletion until the running work is done. 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": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47671", "url": "https://ubuntu.com/security/CVE-2024-47671", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: usbtmc: prevent kernel-usb-infoleak The syzbot reported a kernel-usb-infoleak in usbtmc_write, we need to clear the structure before filling fields.", "cve_priority": "medium", "cve_public_date": "2024-10-09 15:15:00 UTC" }, { "cve": "CVE-2024-46869", "url": "https://ubuntu.com/security/CVE-2024-46869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btintel_pcie: Allocate memory for driver private data Fix driver not allocating memory for struct btintel_data which is used to store internal data.", "cve_priority": "medium", "cve_public_date": "2024-09-30 16:15:00 UTC" }, { "cve": "CVE-2024-53164", "url": "https://ubuntu.com/security/CVE-2024-53164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: fix ordering of qlen adjustment Changes to sch->q.qlen around qdisc_tree_reduce_backlog() need to happen _before_ a call to said function because otherwise it may fail to notify parent qdiscs when the child is about to become empty.", "cve_priority": "medium", "cve_public_date": "2024-12-27 14:15:00 UTC" }, { "cve": "CVE-2024-53103", "url": "https://ubuntu.com/security/CVE-2024-53103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hv_sock: Initializing vsk->trans to NULL to prevent a dangling pointer When hvs is released, there is a possibility that vsk->trans may not be initialized to NULL, which could lead to a dangling pointer. This issue is resolved by initializing vsk->trans to NULL.", "cve_priority": "high", "cve_public_date": "2024-12-02 08:15:00 UTC" } ], "log": [ "", " * oracular/linux: 6.11.0-17.17 -proposed tracker (LP: #2093643)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/2025.01.13)", "", " * When /dev/vmbus/hv_kvp is not present, disable hv-kvp-daemon (LP: #2091744)", " - [Packaging] disable hv-kvp-daemon if needed", "", " * Backport \"netkit: Add option for scrubbing skb meta data\" to 6.8", " (LP: #2091184)", " - netkit: Add option for scrubbing skb meta data", "", " * KVM: Cache CPUID at KVM.ko module init to reduce latency of VM-Enter and VM-", " Exit (LP: #2093146)", " - KVM: x86: Cache CPUID.0xD XSTATE offsets+sizes during module init", "", " * [SRU] add support of QCA BT 0489:e0fc (LP: #2085406)", " - Bluetooth: btusb: add Foxconn 0xe0fc for Qualcomm WCN785x", "", " * oracular: ubuntu_boot lib/dynamic_queue_limits.c:99! (LP: #2089684)", " - virtio_net: correct netdev_tx_reset_queue() invocation point", " - virtio_ring: add a func argument 'recycle_done' to virtqueue_resize()", " - virtio_net: ensure netdev_tx_reset_queue is called on tx ring resize", "", " * Failed to probe for OVTI02C1: chip id mismatch: 560243!=0 (LP: #2090932)", " - SAUCE: ACPI: scan: Update HID for new platform", "", " * Bluetooth[8086:a876] crash with \"hci0: Failed to read MSFT supported", " features (-110)\" (LP: #2085485)", " - Bluetooth: btintel_pcie: Add recovery mechanism", "", " * Poor bluetooth performance on Lenovo X13s (LP: #2089357)", " - SAUCE: Bluetooth: qca: Support downloading board ID specific NVM for WCN6855", "", " * vfio_pci soft lockup on VM start while using PCIe passthrough (LP: #2089306)", " - SAUCE: Revert \"mm: use rwsem assertion macros for mmap_lock\"", " - SAUCE: Revert \"vfio/pci: Insert full vma on mmap'd MMIO fault\"", " - SAUCE: Revert \"vfio/pci: Use unmap_mapping_range()\"", "", " * Oracular update: v6.11.11 upstream stable release (LP: #2091655)", " - wifi: mac80211: Fix setting txpower with emulate_chanctx", " - wifi: cfg80211: Add wiphy_delayed_work_pending()", " - wifi: mac80211: Convert color collision detection to wiphy work", " - wifi: radiotap: Avoid -Wflex-array-member-not-at-end warnings", " - spi: stm32: fix missing device mode capability in stm32mp25", " - ASoC: codecs: rt5640: Always disable IRQs from rt5640_cancel_work()", " - ASoC: Intel: bytcr_rt5640: Add support for non ACPI instantiated codec", " - ASoC: Intel: bytcr_rt5640: Add DMI quirk for Vexia Edu Atla 10 tablet", " - ASoC: Intel: sst: Support LPE0F28 ACPI HID", " - wifi: iwlwifi: mvm: Use the sync timepoint API in suspend", " - wifi: iwlwifi: mvm: SAR table alignment", " - mac80211: fix user-power when emulating chanctx", " - usb: add support for new USB device ID 0x17EF:0x3098 for the r8152 driver", " - usb: typec: use cleanup facility for 'altmodes_node'", " - selftests/watchdog-test: Fix system accidentally reset after watchdog-test", " - ALSA: hda/realtek: Add subwoofer quirk for Infinix ZERO BOOK 13", " - ASoC: codecs: wcd937x: add missing LO Switch control", " - ASoC: codecs: wcd937x: relax the AUX PDM watchdog", " - x86/amd_nb: Fix compile-testing without CONFIG_AMD_NB", " - bpf: fix filed access without lock", " - net: usb: qmi_wwan: add Quectel RG650V", " - soc: qcom: Add check devm_kasprintf() returned value", " - firmware: arm_scmi: Reject clear channel request on A2P", " - regulator: rk808: Add apply_bit for BUCK3 on RK809", " - platform/x86: dell-smbios-base: Extends support to Alienware products", " - platform/x86: dell-wmi-base: Handle META key Lock/Unlock events", " - platform/x86: ideapad-laptop: add missing Ideapad Pro 5 fn keys", " - ASoC: tas2781: Add new driver version for tas2563 & tas2781 qfn chip", " - tools/lib/thermal: Remove the thermal.h soft link when doing make clean", " - can: j1939: fix error in J1939 documentation.", " - platform/x86: thinkpad_acpi: Fix for ThinkPad's with ECFW showing incorrect", " fan speed", " - ASoC: amd: yc: Support dmic on another model of Lenovo Thinkpad E14 Gen 6", " - ASoC: stm: Prevent potential division by zero in stm32_sai_mclk_round_rate()", " - ASoC: stm: Prevent potential division by zero in stm32_sai_get_clk_div()", " - drm: panel-orientation-quirks: Make Lenovo Yoga Tab 3 X90F DMI match less", " strict", " - proc/softirqs: replace seq_printf with seq_put_decimal_ull_width", " - integrity: Use static_assert() to check struct sizes", " - ASoC: audio-graph-card2: Purge absent supplies for device tree nodes", " - LoongArch: For all possible CPUs setup logical-physical CPU mapping", " - LoongArch: Define a default value for VM_DATA_DEFAULT_FLAGS", " - ASoC: max9768: Fix event generation for playback mute", " - ALSA: usb-audio: Fix Yamaha P-125 Quirk Entry", " - ARM: 9420/1: smp: Fix SMP for xip kernels", " - ARM: 9434/1: cfi: Fix compilation corner case", " - ipmr: Fix access to mfc_cache_list without lock held", " - f2fs: fix fiemap failure issue when page size is 16KB", " - drm/amd/display: Skip Invalid Streams from DSC Policy", " - drm/amd/display: Fix incorrect DSC recompute trigger", " - s390/facilities: Fix warning about shadow of global variable", " - efs: fix the efs new mount api implementation", " - arm64: probes: Disable kprobes/uprobes on MOPS instructions", " - kselftest/arm64: hwcap: fix f8dp2 cpuinfo name", " - kselftest/arm64: mte: fix printf type warnings about __u64", " - kselftest/arm64: mte: fix printf type warnings about longs", " - block/fs: Pass an iocb to generic_atomic_write_valid()", " - fs/block: Check for IOCB_DIRECT in generic_atomic_write_valid()", " - s390/cio: Do not unregister the subchannel based on DNV", " - s390/pageattr: Implement missing kernel_page_present()", " - x86/pvh: Set phys_base when calling xen_prepare_pvh()", " - x86/pvh: Call C code via the kernel virtual mapping", " - brd: defer automatic disk creation until module initialization succeeds", " - ext4: avoid remount errors with 'abort' mount option", " - mips: asm: fix warning when disabling MIPS_FP_SUPPORT", " - arm64: Expose ID_AA64ISAR1_EL1.XS to sanitised feature consumers", " - kselftest/arm64: Fix encoding for SVE B16B16 test", " - nvme-pci: fix freeing of the HMB descriptor table", " - m68k: mvme147: Fix SCSI controller IRQ numbers", " - m68k: mvme147: Reinstate early console", " - arm64: fix .data.rel.ro size assertion when CONFIG_LTO_CLANG", " - acpi/arm64: Adjust error handling procedure in gtdt_parse_timer_block()", " - loop: fix type of block size", " - cachefiles: Fix incorrect length return value in", " cachefiles_ondemand_fd_write_iter()", " - cachefiles: Fix missing pos updates in cachefiles_ondemand_fd_write_iter()", " - cachefiles: Fix NULL pointer dereference in object->file", " - netfs/fscache: Add a memory barrier for FSCACHE_VOLUME_CREATING", " - block: constify the lim argument to queue_limits_max_zone_append_sectors", " - block: properly handle REQ_OP_ZONE_APPEND in __bio_split_to_limits", " - block: take chunk_sectors into account in bio_split_write_zeroes", " - block: fix bio_split_rw_at to take zone_write_granularity into account", " - s390/syscalls: Avoid creation of arch/arch/ directory", " - hfsplus: don't query the device logical block size multiple times", " - ext4: pipeline buffer reads in mext_page_mkuptodate()", " - ext4: remove array of buffer_heads from mext_page_mkuptodate()", " - ext4: fix race in buffer_head read fault injection", " - nvme-pci: reverse request order in nvme_queue_rqs", " - virtio_blk: reverse request order in virtio_queue_rqs", " - crypto: mxs-dcp - Fix AES-CBC with hardware-bound keys", " - crypto: caam - Fix the pointer passed to caam_qi_shutdown()", " - crypto: qat - remove check after debugfs_create_dir()", " - crypto: qat/qat_420xx - fix off by one in uof_get_name()", " - crypto: qat/qat_4xxx - fix off by one in uof_get_name()", " - firmware: google: Unregister driver_info on failure", " - EDAC/bluefield: Fix potential integer overflow", " - crypto: qat - remove faulty arbiter config reset", " - thermal: core: Initialize thermal zones before registering them", " - thermal: core: Drop thermal_zone_device_is_enabled()", " - thermal: core: Rearrange PM notification code", " - thermal: core: Represent suspend-related thermal zone flags as bits", " - thermal: core: Mark thermal zones as initializing to start with", " - thermal: core: Fix race between zone registration and system suspend", " - EDAC/fsl_ddr: Fix bad bit shift operations", " - EDAC/skx_common: Differentiate memory error sources", " - EDAC/{skx_common,i10nm}: Fix incorrect far-memory error source indicator", " - crypto: pcrypt - Call crypto layer directly when padata_do_parallel() return", " -EBUSY", " - crypto: cavium - Fix the if condition to exit loop after timeout", " - cpufreq/amd-pstate: Don't update CPPC request in", " amd_pstate_cpu_boost_update()", " - amd-pstate: Set min_perf to nominal_perf for active mode performance gov", " - crypto: hisilicon/qm - disable same error report before resetting", " - EDAC/igen6: Avoid segmentation fault on module unload", " - crypto: qat - Fix missing destroy_workqueue in adf_init_aer()", " - crypto: inside-secure - Fix the return value of safexcel_xcbcmac_cra_init()", " - sched/cpufreq: Ensure sd is rebuilt for EAS check", " - doc: rcu: update printed dynticks counter bits", " - rcu/srcutiny: don't return before reenabling preemption", " - rcu/kvfree: Fix data-race in __mod_timer / kvfree_call_rcu", " - hwmon: (pmbus/core) clear faults after setting smbalert mask", " - hwmon: (nct6775-core) Fix overflows seen when writing limit attributes", " - ACPI: CPPC: Fix _CPC register setting issue", " - crypto: caam - add error check to caam_rsa_set_priv_key_form", " - crypto: bcm - add error check in the ahash_hmac_init function", " - crypto: cavium - Fix an error handling path in cpt_ucode_load_fw()", " - rcuscale: Do a proper cleanup if kfree_scale_init() fails", " - tools/lib/thermal: Make more generic the command encoding function", " - thermal/lib: Fix memory leak on error in thermal_genl_auto()", " - x86/unwind/orc: Fix unwind for newly forked tasks", " - Revert \"scripts/faddr2line: Check only two symbols when calculating symbol", " size\"", " - cleanup: Remove address space of returned pointer", " - time: Partially revert cleanup on msecs_to_jiffies() documentation", " - time: Fix references to _msecs_to_jiffies() handling of values", " - locking/atomic/x86: Use ALT_OUTPUT_SP() for __alternative_atomic64()", " - locking/atomic/x86: Use ALT_OUTPUT_SP() for __arch_{,try_}cmpxchg64_emu()", " - kcsan, seqlock: Support seqcount_latch_t", " - kcsan, seqlock: Fix incorrect assumption in read_seqbegin()", " - clocksource/drivers:sp804: Make user selectable", " - clocksource/drivers/timer-ti-dm: Fix child node refcount handling", " - regulator: qcom-smd: make smd_vreg_rpm static", " - spi: spi-fsl-lpspi: Use IRQF_NO_AUTOEN flag in request_irq()", " - arm64: dts: qcom: qcs6390-rb3gen2: use modem.mbn for modem DSP", " - ARM: dts: renesas: genmai: Fix partition size for QSPI NOR Flash", " - drivers: soc: xilinx: add the missing kfree in xlnx_add_cb_for_suspend()", " - microblaze: Export xmb_manager functions", " - arm64: dts: mediatek: mt8188: Fix wrong clock provider in MFG1 power domain", " - arm64: dts: mediatek: mt8395-genio-1200-evk: Fix dtbs_check error for phy", " - arm64: dts: mt8195: Fix dtbs_check error for mutex node", " - arm64: dts: mt8195: Fix dtbs_check error for infracfg_ao node", " - soc: ti: smartreflex: Use IRQF_NO_AUTOEN flag in request_irq()", " - soc: qcom: geni-se: fix array underflow in geni_se_clk_tbl_get()", " - arm64: dts: qcom: sm6350: Fix GPU frequencies missing on some speedbins", " - arm64: dts: qcom: sda660-ifc6560: fix l10a voltage ranges", " - ARM: dts: microchip: sam9x60: Add missing property atmel,usart-mode", " - mmc: mmc_spi: drop buggy snprintf()", " - scripts/kernel-doc: Do not track section counter across processed files", " - arm64: dts: qcom: x1e80100-slim7x: Drop orientation-switch from USB SS[0-1]", " QMP PHYs", " - arm64: dts: qcom: x1e80100-vivobook-s15: Drop orientation-switch from USB", " SS[0-1] QMP PHYs", " - openrisc: Implement fixmap to fix earlycon", " - efi/libstub: fix efi_parse_options() ignoring the default command line", " - tpm: fix signed/unsigned bug when checking event logs", " - media: i2c: vgxy61: Fix an error handling path in vgxy61_detect()", " - media: i2c: ds90ub960: Fix missing return check on ub960_rxport_read call", " - arm64: dts: mt8183: krane: Fix the address of eeprom at i2c4", " - arm64: dts: mt8183: kukui: Fix the address of eeprom at i2c4", " - arm64: dts: qcom: x1e80100: Resize GIC Redistributor register region", " - kernel-doc: allow object-like macros in ReST output", " - arm64: dts: ti: k3-am62x-phyboard-lyra: Drop unnecessary McASP AFIFOs", " - arm64: dts: mediatek: mt8173-elm-hana: Add vdd-supply to second source", " trackpad", " - arm64: dts: mediatek: mt8188: Fix USB3 PHY port default status", " - arm64: dts: mediatek: mt8195-cherry: Use correct audio codec DAI", " - Revert \"cgroup: Fix memory leak caused by missing cgroup_bpf_offline\"", " - cgroup/bpf: only cgroup v2 can be attached by bpf programs", " - regulator: rk808: Restrict DVS GPIOs to the RK808 variant only", " - power: sequencing: make the QCom PMU pwrseq driver depend on CONFIG_OF", " - [Config] updateconfigs for POWER_SEQUENCING_QCOM_WCN", " - arm64: dts: rockchip: Remove 'enable-active-low' from two boards", " - arm64: dts: mt8183: fennel: add i2c2's i2c-scl-internal-delay-ns", " - arm64: dts: mt8183: burnet: add i2c2's i2c-scl-internal-delay-ns", " - arm64: dts: mt8183: cozmo: add i2c2's i2c-scl-internal-delay-ns", " - arm64: dts: mt8183: Damu: add i2c2's i2c-scl-internal-delay-ns", " - pwm: imx27: Workaround of the pwm output bug when decrease the duty cycle", " - ARM: dts: cubieboard4: Fix DCDC5 regulator constraints", " - arm64: dts: ti: k3-j7200: Fix register map for main domain pmx", " - arm64: dts: ti: k3-j7200: Fix clock ids for MCSPI instances", " - arm64: dts: ti: k3-j721e: Fix clock IDs for MCSPI instances", " - arm64: dts: ti: k3-j721s2: Fix clock IDs for MCSPI instances", " - watchdog: Add HAS_IOPORT dependency for SBC8360 and SBC7240", " - arm64: dts: qcom: x1e80100: Update C4/C5 residency/exit numbers", " - dt-bindings: cache: qcom,llcc: Fix X1E80100 reg entries", " - of/fdt: add dt_phys arg to early_init_dt_scan and early_init_dt_verify", " - pmdomain: ti-sci: Add missing of_node_put() for args.np", " - spi: tegra210-quad: Avoid shift-out-of-bounds", " - spi: zynqmp-gqspi: Undo runtime PM changes at driver exit time​", " - regmap: irq: Set lockdep class for hierarchical IRQ domains", " - arm64: dts: renesas: hihope: Drop #sound-dai-cells", " - arm64: dts: imx8mn-tqma8mqnl-mba8mx-usbot: fix coexistence of output-low and", " output-high in GPIO", " - arm64: dts: mediatek: Add ADC node on MT6357, MT6358, MT6359 PMICs", " - arm64: dts: mediatek: mt6358: fix dtbs_check error", " - arm64: dts: mediatek: mt8183-kukui-jacuzzi: Fix DP bridge supply names", " - arm64: dts: mediatek: mt8183-kukui-jacuzzi: Add supplies for fixed", " regulators", " - selftests/resctrl: Print accurate buffer size as part of MBM results", " - selftests/resctrl: Fix memory overflow due to unhandled wraparound", " - selftests/resctrl: Protect against array overrun during iMC config parsing", " - firmware: arm_scpi: Check the DVFS OPP count returned by the firmware", " - media: ipu6: Fix DMA and physical address debugging messages for 32-bit", " - media: ipu6: not override the dma_ops of device in driver", " - pwm: Assume a disabled PWM to emit a constant inactive output", " - media: atomisp: Add check for rgby_data memory allocation failure", " - arm64: dts: rockchip: correct analog audio name on Indiedroid Nova", " - HID: hyperv: streamline driver probe to avoid devres issues", " - platform/x86: panasonic-laptop: Return errno correctly in show callback", " - drm/imagination: Convert to use time_before macro", " - drm/imagination: Use pvr_vm_context_get()", " - drm/mm: Mark drm_mm_interval_tree*() functions with __maybe_unused", " - drm/vc4: hvs: Don't write gamma luts on 2711", " - drm/vc4: hdmi: Avoid hang with debug registers when suspended", " - drm/vc4: hvs: Fix dlist debug not resetting the next entry pointer", " - drm/vc4: hvs: Remove incorrect limit from hvs_dlist debugfs function", " - drm/vc4: hvs: Correct logic on stopping an HVS channel", " - wifi: ath9k: add range check for conn_rsp_epid in htc_connect_service()", " - drm/omap: Fix possible NULL dereference", " - drm/omap: Fix locking in omap_gem_new_dmabuf()", " - drm/v3d: Appease lockdep while updating GPU stats", " - wifi: p54: Use IRQF_NO_AUTOEN flag in request_irq()", " - wifi: mwifiex: Use IRQF_NO_AUTOEN flag in request_irq()", " - udmabuf: change folios array from kmalloc to kvmalloc", " - udmabuf: fix vmap_udmabuf error page set", " - [Config] updateconfigs for VMAP_PFN", " - drm/imx/dcss: Use IRQF_NO_AUTOEN flag in request_irq()", " - drm/imx/ipuv3: Use IRQF_NO_AUTOEN flag in request_irq()", " - drm/panel: nt35510: Make new commands optional", " - drm/v3d: Address race-condition in MMU flush", " - drm/v3d: Flush the MMU before we supply more memory to the binner", " - drm/amdgpu: Fix JPEG v4.0.3 register write", " - wifi: ath10k: fix invalid VHT parameters in supported_vht_mcs_rate_nss1", " - wifi: ath10k: fix invalid VHT parameters in supported_vht_mcs_rate_nss2", " - wifi: ath12k: Skip Rx TID cleanup for self peer", " - dt-bindings: vendor-prefixes: Add NeoFidelity, Inc", " - ASoC: fsl_micfil: fix regmap_write_bits usage", " - ASoC: dt-bindings: mt6359: Update generic node name and dmic-mode", " - ASoC: fsl-asoc-card: Add missing handling of {hp,mic}-dt-gpios", " - drm/bridge: anx7625: Drop EDID cache on bridge power off", " - drm/bridge: it6505: Drop EDID cache on bridge power off", " - libbpf: Fix expected_attach_type set handling in program load callback", " - libbpf: Fix output .symtab byte-order during linking", " - dlm: fix swapped args sb_flags vs sb_status", " - wifi: rtl8xxxu: Perform update_beacon_work when beaconing is enabled", " - drm/amd/display: fix a memleak issue when driver is removed", " - wifi: ath12k: fix use-after-free in ath12k_dp_cc_cleanup()", " - wifi: ath12k: fix one more memcpy size error", " - bpf: Fix the xdp_adjust_tail sample prog issue", " - selftests/bpf: netns_new() and netns_free() helpers.", " - selftests/bpf: Fix backtrace printing for selftests crashes", " - wifi: ath11k: Fix CE offset address calculation for WCN6750 in SSR", " - selftests/bpf: add missing header include for htons", " - wifi: cfg80211: check radio iface combination for multi radio per wiphy", " - ice: consistently use q_idx in ice_vc_cfg_qs_msg()", " - drm/vc4: hdmi: Increase audio MAI fifo dreq threshold", " - drm/vc4: Introduce generation number enum", " - drm/vc4: Match drm_dev_enter and exit calls in vc4_hvs_lut_load", " - drm/vc4: Match drm_dev_enter and exit calls in vc4_hvs_atomic_flush", " - drm/vc4: Correct generation check in vc4_hvs_lut_load", " - libbpf: fix sym_is_subprog() logic for weak global subprogs", " - accel/ivpu: Prevent recovery invocation during probe and resume", " - ASoC: rt722-sdca: Remove logically deadcode in rt722-sdca.c", " - libbpf: never interpret subprogs in .text as entry programs", " - netdevsim: copy addresses for both in and out paths", " - drm/bridge: tc358767: Fix link properties discovery", " - selftests/bpf: Fix msg_verify_data in test_sockmap", " - selftests/bpf: Fix txmsg_redir of test_txmsg_pull in test_sockmap", " - wifi: wilc1000: Set MAC after operation mode", " - wifi: mwifiex: Fix memcpy() field-spanning write warning in", " mwifiex_config_scan()", " - drm: fsl-dcu: enable PIXCLK on LS1021A", " - drm: panel: nv3052c: correct spi_device_id for RG35XX panel", " - drm/msm/dpu: on SDM845 move DSPP_3 to LM_5 block", " - drm/msm/dpu: drop LM_3 / LM_4 on SDM845", " - drm/msm/dpu: drop LM_3 / LM_4 on MSM8998", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_common.c", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_ethtool.c", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_flows.c", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in cn10k.c", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dmac_flt.c", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dcbnl.c", " - selftests/bpf: fix test_spin_lock_fail.c's global vars usage", " - libbpf: move global data mmap()'ing into bpf_object__load()", " - drm/panfrost: Remove unused id_mask from struct panfrost_model", " - bpf, arm64: Remove garbage frame for struct_ops trampoline", " - drm/msm/adreno: Use IRQF_NO_AUTOEN flag in request_irq()", " - drm/msm/gpu: Check the status of registration to PM QoS", " - drm/xe/hdcp: Fix gsc structure check in fw check status", " - drm/etnaviv: Request pages from DMA32 zone on addressing_limited", " - drm/etnaviv: hold GPU lock across perfmon sampling", " - drm/amd/display: Increase idle worker HPD detection time", " - drm/amd/display: Reduce HPD Detection Interval for IPS", " - drm/nouveau/gr/gf100: Fix missing unlock in gf100_gr_chan_new()", " - drm: zynqmp_kms: Unplug DRM device before removal", " - drm: xlnx: zynqmp_disp: layer may be null while releasing", " - wifi: wfx: Fix error handling in wfx_core_init()", " - wifi: cw1200: Fix potential NULL dereference", " - drm/msm/dpu: cast crtc_clk calculation to u64 in _dpu_core_perf_calc_clk()", " - bpf, bpftool: Fix incorrect disasm pc", " - bpf: Tighten tail call checks for lingering locks, RCU, preempt_disable", " - drm/vkms: Drop unnecessary call to drm_crtc_cleanup()", " - drm/amdgpu: Fix the memory allocation issue in", " amdgpu_discovery_get_nps_info()", " - bpf: Support __nullable argument suffix for tp_btf", " - selftests/bpf: Add test for __nullable suffix in tp_btf", " - bpf: Mark raw_tp arguments with PTR_MAYBE_NULL", " - drm: use ATOMIC64_INIT() for atomic64_t", " - netfilter: nf_tables: avoid false-positive lockdep splat on rule deletion", " - netfilter: nf_tables: must hold rcu read lock while iterating expression", " type list", " - netfilter: nf_tables: must hold rcu read lock while iterating object type", " list", " - netlink: typographical error in nlmsg_type constants definition", " - wifi: rtw89: coex: check NULL return of kmalloc in btc_fw_set_monreg()", " - drm/panfrost: Add missing OPP table refcnt decremental", " - drm/panthor: introduce job cycle and timestamp accounting", " - drm/panthor: record current and maximum device clock frequencies", " - drm/panthor: Fix OPP refcnt leaks in devfreq initialisation", " - isofs: avoid memory leak in iocharset", " - selftests/bpf: Add txmsg_pass to pull/push/pop in test_sockmap", " - selftests/bpf: Fix SENDPAGE data logic in test_sockmap", " - selftests/bpf: Fix total_bytes in msg_loop_rx in test_sockmap", " - selftests/bpf: Add push/pop checking for msg_verify_data in test_sockmap", " - bpf, sockmap: Several fixes to bpf_msg_push_data", " - bpf, sockmap: Several fixes to bpf_msg_pop_data", " - bpf, sockmap: Fix sk_msg_reset_curr", " - ipv6: release nexthop on device removal", " - selftests: net: really check for bg process completion", " - wifi: cfg80211: Remove the Medium Synchronization Delay validity check", " - wifi: iwlwifi: allow fast resume on ax200", " - wifi: iwlwifi: mvm: tell iwlmei when we finished suspending", " - drm/amdgpu: fix ACA bank count boundary check error", " - drm/amdgpu: Fix map/unmap queue logic", " - drm/amdkfd: Fix wrong usage of INIT_WORK()", " - bpf: Allow return values 0 and 1 for kprobe session", " - bpf: Force uprobe bpf program to always return 0", " - selftests/bpf: skip the timer_lockup test for single-CPU nodes", " - ipv6: Fix soft lockups in fib6_select_path under high next hop churn", " - net: rfkill: gpio: Add check for clk_enable()", " - Revert \"wifi: iwlegacy: do not skip frames with bad FCS\"", " - bpf: Use function pointers count as struct_ops links count", " - bpf: Add kernel symbol for struct_ops trampoline", " - ALSA: usx2y: Use snd_card_free_when_closed() at disconnection", " - ALSA: us122l: Use snd_card_free_when_closed() at disconnection", " - ALSA: caiaq: Use snd_card_free_when_closed() at disconnection", " - ALSA: 6fire: Release resources at card release", " - i2c: dev: Fix memory leak when underlying adapter does not support I2C", " - selftests: netfilter: Fix missing return values in conntrack_dump_flush", " - Bluetooth: btintel_pcie: Add handshake between driver and firmware", " - Bluetooth: btintel: Do no pass vendor events to stack", " - Bluetooth: btmtk: adjust the position to init iso data anchor", " - Bluetooth: btbcm: fix missing of_node_put() in btbcm_get_board_name()", " - Bluetooth: ISO: Use kref to track lifetime of iso_conn", " - Bluetooth: ISO: Do not emit LE PA Create Sync if previous is pending", " - Bluetooth: ISO: Do not emit LE BIG Create Sync if previous is pending", " - Bluetooth: ISO: Send BIG Create Sync via hci_sync", " - Bluetooth: fix use-after-free in device_for_each_child()", " - xsk: Free skb when TX metadata options are invalid", " - erofs: handle NONHEAD !delta[1] lclusters gracefully", " - dlm: fix dlm_recover_members refcount on error", " - eth: fbnic: don't disable the PCI device twice", " - net: txgbe: remove GPIO interrupt controller", " - net: txgbe: fix null pointer to pcs", " - netpoll: Use rcu_access_pointer() in netpoll_poll_lock", " - wireguard: selftests: load nf_conntrack if not present", " - bpf: fix recursive lock when verdict program return SK_PASS", " - unicode: Fix utf8_load() error path", " - cppc_cpufreq: Use desired perf if feedback ctrs are 0 or unchanged", " - RDMA/core: Provide rdma_user_mmap_disassociate() to disassociate mmap pages", " - RDMA/hns: Disassociate mmap pages for all uctx when HW is being reset", " - clk: mediatek: drop two dead config options", " - [Config] drop COMMON_CLK_MT8195_{AUDSYS,MSDC}", " - trace/trace_event_perf: remove duplicate samples on the first tracepoint", " event", " - pinctrl: zynqmp: drop excess struct member description", " - pinctrl: renesas: Select PINCTRL_RZG2L for RZ/V2H(P) SoC", " - clk: qcom: videocc-sm8550: depend on either gcc-sm8550 or gcc-sm8650", " - iommu/s390: Implement blocking domain", " - scsi: hisi_sas: Enable all PHYs that are not disabled by user during", " controller reset", " - powerpc/vdso: Flag VDSO64 entry points as functions", " - mfd: tps65010: Use IRQF_NO_AUTOEN flag in request_irq() to fix race", " - mfd: da9052-spi: Change read-mask to write-mask", " - mfd: intel_soc_pmic_bxtwc: Use IRQ domain for USB Type-C device", " - mfd: intel_soc_pmic_bxtwc: Use IRQ domain for TMU device", " - mfd: intel_soc_pmic_bxtwc: Use IRQ domain for PMIC devices", " - irqdomain: Simplify simple and legacy domain creation", " - irqdomain: Cleanup domain name allocation", " - irqdomain: Allow giving name suffix for domain", " - regmap: Allow setting IRQ domain name suffix", " - mfd: intel_soc_pmic_bxtwc: Fix IRQ domain names duplication", " - cpufreq: loongson2: Unregister platform_driver on failure", " - powerpc/fadump: Refactor and prepare fadump_cma_init for late init", " - powerpc/fadump: Move fadump_cma_init to setup_arch() after initmem_init()", " - mtd: hyperbus: rpc-if: Add missing MODULE_DEVICE_TABLE", " - mtd: rawnand: atmel: Fix possible memory leak", " - powerpc/mm/fault: Fix kfence page fault reporting", " - clk: sophgo: avoid integer overflow in sg2042_pll_recalc_rate()", " - mtd: spi-nor: spansion: Use nor->addr_nbytes in octal DTR mode in", " RD_ANY_REG_OP", " - powerpc/pseries: Fix dtl_access_lock to be a rw_semaphore", " - cpufreq: CPPC: Fix possible null-ptr-deref for cpufreq_cpu_get_raw()", " - cpufreq: CPPC: Fix possible null-ptr-deref for cppc_get_cpu_cost()", " - iommu/amd: Remove amd_iommu_domain_update() from page table freeing", " - iommu/amd: Remove the amd_iommu_domain_set_pt_root() and related", " - iommu/amd: Rename struct amd_io_pgtable iopt to pgtbl", " - iommu/amd: Store the nid in io_pgtable_cfg instead of the domain", " - iommu/amd: Narrow the use of struct protection_domain to invalidation", " - iommu/amd/pgtbl_v2: Take protection domain lock before invalidating TLB", " - RDMA/hns: Fix an AEQE overflow error caused by untimely update of eq_db_ci", " - RDMA/hns: Fix flush cqe error when racing with destroy qp", " - RDMA/hns: Modify debugfs name", " - RDMA/hns: Use dev_* printings in hem code instead of ibdev_*", " - RDMA/hns: Fix cpu stuck caused by printings during reset", " - RDMA/rxe: Fix the qp flush warnings in req", " - RDMA/bnxt_re: Check cqe flags to know imm_data vs inv_irkey", " - clk: sunxi-ng: d1: Fix PLL_AUDIO0 preset", " - clk: renesas: rzg2l: Fix FOUTPOSTDIV clk", " - RDMA/rxe: Set queue pair cur_qp_state when being queried", " - RISC-V: KVM: Fix APLIC in_clrip and clripnum write emulation", " - riscv: kvm: Fix out-of-bounds array access", " - clk: imx: lpcg-scu: SW workaround for errata (e10858)", " - clk: imx: fracn-gppll: correct PLL initialization flow", " - clk: imx: fracn-gppll: fix pll power up", " - clk: imx: clk-scu: fix clk enable state save and restore", " - clk: imx: imx8-acm: Fix return value check in", " clk_imx_acm_attach_pm_domains()", " - iommu/vt-d: Fix checks and print in dmar_fault_dump_ptes()", " - iommu/vt-d: Fix checks and print in pgtable_walk()", " - checkpatch: always parse orig_commit in fixes tag", " - mfd: rt5033: Fix missing regmap_del_irq_chip()", " - leds: max5970: Fix unreleased fwnode_handle in probe function", " - leds: ktd2692: Set missing timing properties", " - fs/proc/kcore.c: fix coccinelle reported ERROR instances", " - scsi: target: Fix incorrect function name in pscsi_create_type_disk()", " - scsi: bfa: Fix use-after-free in bfad_im_module_exit()", " - scsi: fusion: Remove unused variable 'rc'", " - scsi: qedf: Fix a possible memory leak in qedf_alloc_and_init_sb()", " - scsi: qedi: Fix a possible memory leak in qedi_alloc_and_init_sb()", " - scsi: sg: Enable runtime power management", " - x86/tdx: Introduce wrappers to read and write TD metadata", " - x86/tdx: Rename tdx_parse_tdinfo() to tdx_setup()", " - x86/tdx: Dynamically disable SEPT violations from causing #VEs", " - powerpc/fadump: allocate memory for additional parameters early", " - fadump: reserve param area if below boot_mem_top", " - RDMA/hns: Fix out-of-order issue of requester when setting FENCE", " - RDMA/hns: Fix NULL pointer derefernce in hns_roce_map_mr_sg()", " - cpufreq: loongson3: Check for error code from devm_mutex_init() call", " - cpufreq: CPPC: Fix wrong return value in cppc_get_cpu_cost()", " - cpufreq: CPPC: Fix wrong return value in cppc_get_cpu_power()", " - kasan: move checks to do_strncpy_from_user", " - kunit: skb: use \"gfp\" variable instead of hardcoding GFP_KERNEL", " - ocfs2: fix uninitialized value in ocfs2_file_read_iter()", " - dax: delete a stale directory pmem", " - KVM: PPC: Book3S HV: Stop using vc->dpdes for nested KVM guests", " - KVM: PPC: Book3S HV: Avoid returning to nested hypervisor on pending", " doorbells", " - powerpc/sstep: make emulate_vsx_load and emulate_vsx_store static", " - RDMA/hns: Fix different dgids mapping to the same dip_idx", " - KVM: PPC: Book3S HV: Fix kmv -> kvm typo", " - powerpc/kexec: Fix return of uninitialized variable", " - fbdev: sh7760fb: Fix a possible memory leak in sh7760fb_alloc_mem()", " - RDMA/mlx5: Move events notifier registration to be after device registration", " - clk: clk-apple-nco: Add NULL check in applnco_probe", " - clk: ralink: mtmips: fix clock plan for Ralink SoC RT3883", " - clk: ralink: mtmips: fix clocks probe order in oldest ralink SoCs", " - clk: en7523: remove REG_PCIE*_{MEM,MEM_MASK} configuration", " - clk: en7523: move clock_register in hw_init callback", " - clk: en7523: introduce chip_scu regmap", " - clk: en7523: fix estimation of fixed rate for EN7581", " - dt-bindings: clock: axi-clkgen: include AXI clk", " - clk: clk-axi-clkgen: make sure to enable the AXI bus clock", " - arm64: dts: qcom: sc8180x: Add a SoC-specific compatible to cpufreq-hw", " - pinctrl: k210: Undef K210_PC_DEFAULT", " - rtla/timerlat: Do not set params->user_workload with -U", " - smb: cached directories can be more than root file handle", " - mailbox: mtk-cmdq: fix wrong use of sizeof in cmdq_get_clocks()", " - mailbox: arm_mhuv2: clean up loop in get_irq_chan_comb()", " - x86: fix off-by-one in access_ok()", " - perf cs-etm: Don't flush when packet_queue fills up", " - gfs2: Rename GLF_VERIFY_EVICT to GLF_VERIFY_DELETE", " - gfs2: Allow immediate GLF_VERIFY_DELETE work", " - gfs2: Fix unlinked inode cleanup", " - perf test: Add test for Intel TPEBS counting mode", " - perf mem: Fix printing PERF_MEM_LVLNUM_{L2_MHB|MSC}", " - PCI: Fix reset_method_store() memory leak", " - perf stat: Close cork_fd when create_perf_stat_counter() failed", " - perf stat: Fix affinity memory leaks on error path", " - perf trace: Keep exited threads for summary", " - perf test attr: Add back missing topdown events", " - f2fs: compress: fix inconsistent update of i_blocks in", " release_compress_blocks and reserve_compress_blocks", " - f2fs: fix null-ptr-deref in f2fs_submit_page_bio()", " - f2fs: fix to account dirty data in __get_secs_required()", " - perf dso: Fix symtab_type for kmod compression", " - perf probe: Fix libdw memory leak", " - perf probe: Correct demangled symbols in C++ program", " - rust: kernel: fix THIS_MODULE header path in ThisModule doc comment", " - rust: macros: fix documentation of the paste! macro", " - PCI: cpqphp: Use PCI_POSSIBLE_ERROR() to check config reads", " - PCI: cpqphp: Fix PCIBIOS_* return value confusion", " - rust: block: fix formatting of `kernel::block::mq::request` module", " - perf disasm: Use disasm_line__free() to properly free disasm_line", " - virtiofs: use pages instead of pointer for kernel direct IO", " - perf ftrace latency: Fix unit on histogram first entry when using --use-nsec", " - i3c: master: Remove i3c_dev_disable_ibi_locked(olddev) on device hotjoin", " - f2fs: fix the wrong f2fs_bug_on condition in f2fs_do_replace_block", " - f2fs: check curseg->inited before write_sum_page in change_curseg", " - f2fs: Fix not used variable 'index'", " - f2fs: fix to avoid potential deadlock in f2fs_record_stop_reason()", " - f2fs: fix to avoid use GC_AT when setting gc_mode as GC_URGENT_LOW or", " GC_URGENT_MID", " - PCI: qcom-ep: Move controller cleanups to qcom_pcie_perst_deassert()", " - PCI: tegra194: Move controller cleanups to pex_ep_event_pex_rst_deassert()", " - PCI: cadence: Extract link setup sequence from cdns_pcie_host_setup()", " - PCI: cadence: Set cdns_pcie_host_init() global", " - PCI: j721e: Add reset GPIO to struct j721e_pcie", " - PCI: j721e: Use T_PERST_CLK_US macro", " - PCI: j721e: Add suspend and resume support", " - PCI: j721e: Deassert PERST# after a delay of PCIE_T_PVPERL_MS milliseconds", " - perf build: Add missing cflags when building with custom libtraceevent", " - f2fs: fix race in concurrent f2fs_stop_gc_thread", " - f2fs: fix to map blocks correctly for direct write", " - f2fs: fix to avoid forcing direct write to use buffered IO on inline_data", " inode", " - perf trace: avoid garbage when not printing a trace event's arguments", " - m68k: mcfgpio: Fix incorrect register offset for CONFIG_M5441x", " - m68k: coldfire/device.c: only build FEC when HW macros are defined", " - svcrdma: Address an integer overflow", " - nfsd: drop inode parameter from nfsd4_change_attribute()", " - perf list: Fix topic and pmu_name argument order", " - perf trace: Fix tracing itself, creating feedback loops", " - perf trace: Do not lose last events in a race", " - perf trace: Avoid garbage when not printing a syscall's arguments", " - remoteproc: qcom: pas: Remove subdevs on the error path of adsp_probe()", " - remoteproc: qcom: adsp: Remove subdevs on the error path of adsp_probe()", " - remoteproc: qcom: pas: add minidump_id to SM8350 resources", " - rpmsg: glink: use only lower 16-bits of param2 for CMD_OPEN name length", " - remoteproc: qcom_q6v5_mss: Re-order writes to the IMEM region", " - PCI: endpoint: epf-mhi: Avoid NULL dereference if DT lacks 'mmio'", " - NFSD: Prevent NULL dereference in nfsd4_process_cb_update()", " - NFSD: Cap the number of bytes copied by nfs4_reset_recoverydir()", " - nfsd: release svc_expkey/svc_export with rcu_work", " - svcrdma: fix miss destroy percpu_counter in svc_rdma_proc_init()", " - NFSD: Fix nfsd4_shutdown_copy()", " - f2fs: clean up val{>>,<<}F2FS_BLKSIZE_BITS", " - f2fs: fix to do cast in F2FS_{BLK_TO_BYTES, BTYES_TO_BLK} to avoid overflow", " - hwmon: (tps23861) Fix reporting of negative temperatures", " - hwmon: (aquacomputer_d5next) Fix length of speed_input array", " - phy: airoha: Fix REG_CSR_2L_PLL_CMN_RESERVE0 config in", " airoha_pcie_phy_init_clk_out()", " - phy: airoha: Fix REG_PCIE_PMA_TX_RESET config in", " airoha_pcie_phy_init_csr_2l()", " - phy: airoha: Fix REG_CSR_2L_JCPLL_SDM_HREN config in", " airoha_pcie_phy_init_ssc_jcpll()", " - phy: airoha: Fix REG_CSR_2L_RX{0,1}_REV0 definitions", " - vdpa/mlx5: Fix suboptimal range on iotlb iteration", " - vfio/mlx5: Fix an unwind issue in mlx5vf_add_migration_pages()", " - vfio/mlx5: Fix unwind flows in mlx5vf_pci_save/resume_device_data()", " - selftests/mount_setattr: Fix failures on 64K PAGE_SIZE kernels", " - gpio: zevio: Add missed label initialisation", " - vfio/pci: Properly hide first-in-list PCIe extended capability", " - fs_parser: update mount_api doc to match function signature", " - LoongArch: Fix build failure with GCC 15 (-std=gnu23)", " - LoongArch: BPF: Sign-extend return values", " - power: supply: core: Remove might_sleep() from power_supply_put()", " - power: supply: bq27xxx: Fix registers of bq27426", " - power: supply: rt9471: Fix wrong WDT function regfield declaration", " - power: supply: rt9471: Use IC status regfield to report real charger status", " - net: usb: lan78xx: Fix double free issue with interrupt buffer allocation", " - net: usb: lan78xx: Fix memory leak on device unplug by freeing PHY device", " - tg3: Set coherent DMA mask bits to 31 for BCM57766 chipsets", " - net: usb: lan78xx: Fix refcounting and autosuspend on invalid WoL", " configuration", " - net: microchip: vcap: Add typegroup table terminators in kunit tests", " - netlink: fix false positive warning in extack during dumps", " - exfat: fix file being changed by unaligned direct write", " - s390/iucv: MSG_PEEK causes memory leak in iucv_sock_destruct()", " - net/ipv6: delete temporary address if mngtmpaddr is removed or unmanaged", " - net: mdio-ipq4019: add missing error check", " - marvell: pxa168_eth: fix call balance of pep->clk handling routines", " - net: stmmac: dwmac-socfpga: Set RX watchdog interrupt as broken", " - octeontx2-af: RPM: Fix mismatch in lmac type", " - octeontx2-af: RPM: Fix low network performance", " - octeontx2-af: RPM: fix stale RSFEC counters", " - octeontx2-af: RPM: fix stale FCFEC counters", " - octeontx2-af: Quiesce traffic before NIX block reset", " - spi: atmel-quadspi: Fix register name in verbose logging function", " - net: hsr: fix hsr_init_sk() vs network/transport headers.", " - bnxt_en: Reserve rings after PCIe AER recovery if NIC interface is down", " - bnxt_en: Set backplane link modes correctly for ethtool", " - bnxt_en: Fix receive ring space parameters when XDP is active", " - bnxt_en: Refactor bnxt_ptp_init()", " - bnxt_en: Unregister PTP during PCI shutdown and suspend", " - Bluetooth: MGMT: Fix slab-use-after-free Read in set_powered_sync", " - Bluetooth: MGMT: Fix possible deadlocks", " - llc: Improve setsockopt() handling of malformed user input", " - rxrpc: Improve setsockopt() handling of malformed user input", " - tcp: Fix use-after-free of nreq in reqsk_timer_handler().", " - ip6mr: fix tables suspicious RCU usage", " - ipmr: fix tables suspicious RCU usage", " - iio: light: al3010: Fix an error handling path in al3010_probe()", " - usb: using mutex lock and supporting O_NONBLOCK flag in iowarrior_read()", " - usb: yurex: make waiting on yurex_write interruptible", " - USB: chaoskey: fail open after removal", " - USB: chaoskey: Fix possible deadlock chaoskey_list_lock", " - misc: apds990x: Fix missing pm_runtime_disable()", " - devres: Fix page faults when tracing devres from unloaded modules", " - usb: gadget: uvc: wake pump everytime we update the free list", " - interconnect: qcom: icc-rpmh: probe defer incase of missing QoS clock", " dependency", " - phy: realtek: usb: fix NULL deref in rtk_usb2phy_probe", " - phy: realtek: usb: fix NULL deref in rtk_usb3phy_probe", " - counter: stm32-timer-cnt: Add check for clk_enable()", " - counter: ti-ecap-capture: Add check for clk_enable()", " - bus: mhi: host: Switch trace_mhi_gen_tre fields to native endian", " - usb: typec: fix potential array underflow in ucsi_ccg_sync_control()", " - firmware_loader: Fix possible resource leak in fw_log_firmware_info()", " - ALSA: hda/realtek: Update ALC256 depop procedure", " - drm/radeon: add helper rdev_to_drm(rdev)", " - drm/radeon: change rdev->ddev to rdev_to_drm(rdev)", " - drm/radeon: Fix spurious unplug event on radeon HDMI", " - drm/amd/display: Fix null check for pipe_ctx->plane_state in", " dcn20_program_pipe", " - drm/amd/display: Fix null check for pipe_ctx->plane_state in hwss_setup_dpp", " - ASoC: imx-audmix: Add NULL check in imx_audmix_probe", " - drm/xe/ufence: Wake up waiters after setting ufence->signalled", " - apparmor: fix 'Do simple duplicate message elimination'", " - ALSA: core: Fix possible NULL dereference caused by kunit_kzalloc()", " - ASoC: amd: yc: Fix for enabling DMIC on acp6x via _DSD entry", " - ASoC: mediatek: Check num_codecs is not zero to avoid panic during probe", " - s390/pci: Fix potential double remove of hotplug slot", " - net_sched: sch_fq: don't follow the fast path if Tx is behind now", " - xen: Fix the issue of resource not being properly released in", " xenbus_dev_probe()", " - ALSA: usb-audio: Fix potential out-of-bound accesses for Extigy and Mbox", " devices", " - ALSA: usb-audio: Fix out of bounds reads when finding clock sources", " - usb: ehci-spear: fix call balance of sehci clk handling routines", " - usb: typec: ucsi: glink: fix off-by-one in connector_status", " - dm-cache: fix warnings about duplicate slab caches", " - dm-bufio: fix warnings about duplicate slab caches", " - ASoC: Intel: sst: Fix used of uninitialized ctx to log an error", " - soc: qcom: socinfo: fix revision check in qcom_socinfo_probe()", " - irqdomain: Always associate interrupts for legacy domains", " - ext4: supress data-race warnings in ext4_free_inodes_{count,set}()", " - ext4: fix FS_IOC_GETFSMAP handling", " - jfs: xattr: check invalid xattr size more strictly", " - ASoC: amd: yc: Add a quirk for microfone on Lenovo ThinkPad P14s Gen 5", " 21MES00B00", " - ASoC: codecs: Fix atomicity violation in snd_soc_component_get_drvdata()", " - ASoC: da7213: Populate max_register to regmap_config", " - perf/x86/intel/pt: Fix buffer full but size is 0 case", " - crypto: x86/aegis128 - access 32-bit arguments as 32-bit", " - KVM: x86: switch hugepage recovery thread to vhost_task", " - KVM: x86/mmu: Skip the \"try unsync\" path iff the old SPTE was a leaf SPTE", " - powerpc/pseries: Fix KVM guest detection for disabling hardlockup detector", " - KVM: arm64: vgic-v3: Sanitise guest writes to GICR_INVLPIR", " - KVM: arm64: Ignore PMCNTENSET_EL0 while checking for overflow status", " - KVM: arm64: Don't retire aborted MMIO instruction", " - KVM: arm64: vgic-its: Clear ITE when DISCARD frees an ITE", " - KVM: arm64: Get rid of userspace_irqchip_in_use", " - KVM: arm64: vgic-its: Add a data length check in vgic_its_save_*", " - KVM: arm64: vgic-its: Clear DTE when MAPD unmaps a device", " - Compiler Attributes: disable __counted_by for clang < 19.1.3", " - PCI: Fix use-after-free of slot->bus on hot remove", " - LoongArch: Explicitly specify code model in Makefile", " - clk: clk-loongson2: Fix memory corruption bug in struct", " loongson2_clk_provider", " - clk: clk-loongson2: Fix potential buffer overflow in flexible-array member", " access", " - fsnotify: fix sending inotify event with unexpected filename", " - comedi: Flush partial mappings in error case", " - apparmor: test: Fix memory leak for aa_unpack_strdup()", " - iio: dac: adi-axi-dac: fix wrong register bitfield", " - tty: ldsic: fix tty_ldisc_autoload sysctl's proc_handler", " - locking/lockdep: Avoid creating new name string literals in", " lockdep_set_subclass()", " - tools/nolibc: s390: include std.h", " - pinctrl: qcom: spmi: fix debugfs drive strength", " - dt-bindings: pinctrl: samsung: Fix interrupt constraint for variants with", " fallbacks", " - dt-bindings: iio: dac: ad3552r: fix maximum spi speed", " - exfat: fix uninit-value in __exfat_get_dentry_set", " - exfat: fix out-of-bounds access of directory entries", " - xhci: Fix control transfer error on Etron xHCI host", " - xhci: Combine two if statements for Etron xHCI host", " - xhci: Don't perform Soft Retry for Etron xHCI host", " - xhci: Don't issue Reset Device command to Etron xHCI host", " - Bluetooth: Fix type of len in rfcomm_sock_getsockopt{,_old}()", " - usb: xhci: Limit Stop Endpoint retries", " - usb: xhci: Fix TD invalidation under pending Set TR Dequeue", " - usb: xhci: Avoid queuing redundant Stop Endpoint commands", " - ARM: dts: omap36xx: declare 1GHz OPP as turbo again", " - wifi: ath12k: fix warning when unbinding", " - wifi: rtlwifi: Drastically reduce the attempts to read efuse in case of", " failures", " - wifi: nl80211: fix bounds checker error in nl80211_parse_sched_scan", " - wifi: ath12k: fix crash when unbinding", " - wifi: brcmfmac: release 'root' node in all execution paths", " - Revert \"fs: don't block i_writecount during exec\"", " - Revert \"f2fs: remove unreachable lazytime mount option parsing\"", " - Revert \"usb: gadget: composite: fix OS descriptors w_value logic\"", " - serial: sh-sci: Clean sci_ports[0] after at earlycon exit", " - Revert \"serial: sh-sci: Clean sci_ports[0] after at earlycon exit\"", " - io_uring: fix corner case forgetting to vunmap", " - io_uring: check for overflows in io_pin_pages", " - blk-settings: round down io_opt to physical_block_size", " - gpio: exar: set value when external pull-up or pull-down is present", " - spi: Fix acpi deferred irq probe", " - mtd: spi-nor: core: replace dummy buswidth from addr to data", " - cpufreq: mediatek-hw: Fix wrong return value in mtk_cpufreq_get_cpu_power()", " - cifs: support mounting with alternate password to allow password rotation", " - parisc/ftrace: Fix function graph tracing disablement", " - RISC-V: Scalar unaligned access emulated on hotplug CPUs", " - RISC-V: Check scalar unaligned access on all CPUs", " - ksmbd: fix use-after-free in SMB request handling", " - smb: client: fix NULL ptr deref in crypto_aead_setkey()", " - platform/chrome: cros_ec_typec: fix missing fwnode reference decrement", " - irqchip/irq-mvebu-sei: Move misplaced select() callback to SEI CP domain", " - x86/CPU/AMD: Terminate the erratum_1386_microcode array", " - ubi: wl: Put source PEB into correct list if trying locking LEB failed", " - um: ubd: Do not use drvdata in release", " - um: net: Do not use drvdata in release", " - dt-bindings: serial: rs485: Fix rs485-rts-delay property", " - serial: 8250_fintek: Add support for F81216E", " - serial: 8250: omap: Move pm_runtime_get_sync", " - serial: amba-pl011: Fix RX stall when DMA is used", " - serial: amba-pl011: fix build regression", " - mtd: ubi: fix unreleased fwnode_handle in find_volume_fwnode()", " - block: Prevent potential deadlock in blk_revalidate_disk_zones()", " - um: vector: Do not use drvdata in release", " - sh: cpuinfo: Fix a warning for CONFIG_CPUMASK_OFFSTACK", " - iio: gts: Fix uninitialized symbol 'ret'", " - ublk: fix ublk_ch_mmap() for 64K page size", " - arm64: tls: Fix context-switching of tpidrro_el0 when kpti is enabled", " - block: fix missing dispatching request when queue is started or unquiesced", " - block: fix ordering between checking QUEUE_FLAG_QUIESCED request adding", " - block: fix ordering between checking BLK_MQ_S_STOPPED request adding", " - blk-mq: Make blk_mq_quiesce_tagset() hold the tag list mutex less long", " - gve: Flow steering trigger reset only for timeout error", " - HID: wacom: Interpret tilt data from Intuos Pro BT as signed values", " - i40e: Fix handling changed priv flags", " - media: wl128x: Fix atomicity violation in fmc_send_cmd()", " - media: intel/ipu6: do not handle interrupts when device is disabled", " - arm64: dts: mediatek: mt8186-corsola-voltorb: Merge speaker codec nodes", " - netdev-genl: Hold rcu_read_lock in napi_get", " - soc: fsl: rcpm: fix missing of_node_put() in copy_ippdexpcr1_setting()", " - media: v4l2-core: v4l2-dv-timings: check cvt/gtf result", " - ALSA: rawmidi: Fix kvfree() call in spinlock", " - ALSA: ump: Fix evaluation of MIDI 1.0 FB info", " - ALSA: pcm: Add sanity NULL check for the default mmap fault handler", " - ALSA: hda/realtek: Update ALC225 depop procedure", " - ALSA: hda/realtek: Set PCBeep to default value for ALC274", " - ALSA: hda/realtek: Fix Internal Speaker and Mic boost of Infinix Y4 Max", " - ALSA: hda/realtek: Apply quirk for Medion E15433", " - smb3: request handle caching when caching directories", " - smb: client: handle max length for SMB symlinks", " - smb: Don't leak cfid when reconnect races with open_cached_dir", " - smb: prevent use-after-free due to open_cached_dir error paths", " - smb: During unmount, ensure all cached dir instances drop their dentry", " - usb: misc: ljca: set small runtime autosuspend delay", " - usb: misc: ljca: move usb_autopm_put_interface() after wait for response", " - usb: dwc3: ep0: Don't clear ep0 DWC3_EP_TRANSFER_STARTED", " - usb: musb: Fix hardware lockup on first Rx endpoint request", " - usb: dwc3: gadget: Fix checking for number of TRBs left", " - usb: dwc3: gadget: Fix looping of queued SG entries", " - staging: vchiq_arm: Fix missing refcount decrement in error path for fw_node", " - counter: stm32-timer-cnt: fix device_node handling in probe_encoder()", " - ublk: fix error code for unsupported command", " - lib: string_helpers: silence snprintf() output truncation warning", " - f2fs: fix to do sanity check on node blkaddr in truncate_node()", " - ipc: fix memleak if msg_init_ns failed in create_ipc_ns", " - Input: cs40l50 - fix wrong usage of INIT_WORK()", " - NFSD: Prevent a potential integer overflow", " - SUNRPC: make sure cache entry active before cache_show", " - um: Fix potential integer overflow during physmem setup", " - um: Fix the return value of elf_core_copy_task_fpregs", " - kfifo: don't include dma-mapping.h in kfifo.h", " - um: ubd: Initialize ubd's disk pointer in ubd_add", " - um: Always dump trace for specified task in show_stack", " - NFSv4.0: Fix a use-after-free problem in the asynchronous open()", " - rtc: st-lpc: Use IRQF_NO_AUTOEN flag in request_irq()", " - rtc: abx80x: Fix WDT bit position of the status register", " - rtc: check if __rtc_read_time was successful in rtc_timer_do_work()", " - ubi: fastmap: wl: Schedule fm_work if wear-leveling pool is empty", " - ubifs: Correct the total block count by deducting journal reservation", " - ubi: fastmap: Fix duplicate slab cache names while attaching", " - ubifs: authentication: Fix use-after-free in ubifs_tnc_end_commit", " - jffs2: fix use of uninitialized variable", " - rtc: rzn1: fix BCD to rtc_time conversion errors", " - Revert \"nfs: don't reuse partially completed requests in", " nfs_lock_and_join_requests\"", " - nvme-multipath: avoid hang on inaccessible namespaces", " - nvme/multipath: Fix RCU list traversal to use SRCU primitive", " - blk-mq: add non_owner variant of start_freeze/unfreeze queue APIs", " - block: model freeze & enter queue as lock for supporting lockdep", " - block: fix uaf for flush rq while iterating tags", " - block: return unsigned int from bdev_io_min", " - nvme-fabrics: fix kernel crash while shutting down controller", " - 9p/xen: fix init sequence", " - 9p/xen: fix release of IRQ", " - perf/arm-smmuv3: Fix lockdep assert in ->event_init()", " - perf/arm-cmn: Ensure port and device id bits are set properly", " - smb: client: disable directory caching when dir_cache_timeout is zero", " - x86/Documentation: Update algo in init_size description of boot protocol", " - cifs: Fix parsing native symlinks relative to the export", " - cifs: Fix parsing reparse point with native symlink in SMB1 non-UNICODE", " session", " - rtc: ab-eoz9: don't fail temperature reads on undervoltage notification", " - Rename .data.unlikely to .data..unlikely", " - Rename .data.once to .data..once to fix resetting WARN*_ONCE", " - kbuild: deb-pkg: Don't fail if modules.order is missing", " - smb: Initialize cfid->tcon before performing network ops", " - block: Don't allow an atomic write be truncated in blkdev_write_iter()", " - modpost: remove incorrect code in do_eisa_entry()", " - cifs: during remount, make sure passwords are in sync", " - cifs: unlock on error in smb3_reconfigure()", " - nfs: ignore SB_RDONLY when mounting nfs", " - sunrpc: clear XPRT_SOCK_UPD_TIMEOUT when reset transport", " - SUNRPC: timeout and cancel TLS handshake with -ETIMEDOUT", " - sunrpc: fix one UAF issue caused by sunrpc kernel tcp socket", " - nfs/blocklayout: Don't attempt unregister for invalid block device", " - nfs/blocklayout: Limit repeat device registration on failure", " - block, bfq: fix bfqq uaf in bfq_limit_depth()", " - brd: decrease the number of allocated pages which discarded", " - sh: intc: Fix use-after-free bug in register_intc_controller()", " - tools/power turbostat: Fix trailing '\\n' parsing", " - tools/power turbostat: Fix child's argument forwarding", " - block: always verify unfreeze lock on the owner task", " - block: don't verify IO lock for freeze/unfreeze in elevator_init_mq()", " - Linux 6.11.11", "", " * Oracular update: v6.11.11 upstream stable release (LP: #2091655) //", " CVE-2024-53141", " - netfilter: ipset: add missing range check in bitmap_ip_uadt", "", " * Oracular update: v6.11.11 upstream stable release (LP: #2091655) //", " CVE-2024-50010", " - Revert \"exec: don't WARN for racy path_noexec check\"", "", " * Oracular update: v6.11.11 upstream stable release (LP: #2091655) //", " CVE-2024-53143", " - fsnotify: Fix ordering of iput() and watched_objects decrement", "", " * Oracular update: v6.11.11 upstream stable release (LP: #2091655) //", " CVE-2024-53142", " - initramfs: avoid filename buffer overrun", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650)", " - net: vertexcom: mse102x: Fix tx_bytes calculation", " - net/mlx5: Fix msix vectors to respect platform limit", " - net/mlx5e: clear xdp features on non-uplink representors", " - net/mlx5e: Disable loopback self-test on multi-PF netdev", " - drm/i915/gsc: ARL-H and ARL-U need a newer GSC FW.", " - drivers: perf: Fix wrong put_cpu() placement", " - Bluetooth: hci_core: Fix calling mgmt_device_connected", " - Bluetooth: btintel: Direct exception event to bluetooth stack", " - net: sched: cls_u32: Fix u32's systematic failure to free IDR entries for", " hnodes.", " - net: phylink: ensure PHY momentary link-fails are handled", " - samples: pktgen: correct dev to DEV", " - net: stmmac: dwmac-mediatek: Fix inverted handling of mediatek,mac-wol", " - net: Make copy_safe_from_sockptr() match documentation", " - stmmac: dwmac-intel-plat: fix call balance of tx_clk handling routines", " - net: ti: icssg-prueth: Fix 1 PPS sync", " - bonding: add ns target multicast address to slave device", " - ARM: 9419/1: mm: Fix kernel memory mapping for xip kernels", " - tools/mm: fix compile error", " - drm/amd/display: Run idle optimizations at end of vblank handler", " - drm/amd/display: Change some variable name of psr", " - drm/amd/display: Fix Panel Replay not update screen correctly", " - x86/mm: Fix a kdump kernel failure on SME system when CONFIG_IMA_KEXEC=y", " - x86/stackprotector: Work around strict Clang TLS symbol requirements", " - crash, powerpc: default to CRASH_DUMP=n on PPC_BOOK3S_32", " - [Config] enable ARCH_DEFAULT_CRASH_DUMP", " - mm: revert \"mm: shmem: fix data-race in shmem_getattr()\"", " - vdpa/mlx5: Fix PA offset with unaligned starting iotlb map", " - evm: stop avoidably reading i_writecount in evm_file_release", " - KVM: selftests: Disable strict aliasing", " - KVM: nVMX: Treat vpid01 as current if L2 is active, but with VPID disabled", " - KVM: x86: Unconditionally set irr_pending when updating APICv state", " - tpm: Disable TPM on tpm2_create_primary() failure", " - ALSA: hda/realtek - Fixed Clevo platform headset Mic issue", " - ALSA: hda/realtek - update set GPIO3 to default for Thinkpad with ALC1318", " - mptcp: update local address flags when setting it", " - mptcp: hold pm lock when deleting entry", " - mptcp: pm: use _rcu variant under rcu_read_lock", " - ocfs2: fix UBSAN warning in ocfs2_verify_volume()", " - LoongArch: Fix early_numa_add_cpu() usage for FDT systems", " - LoongArch: Disable KASAN if PGDIR_SIZE is too large for cpu_vabits", " - LoongArch: Add WriteCombine shadow mapping in KASAN", " - LoongArch: Fix AP booting issue in VM mode", " - LoongArch: Make KASAN work with 5-level page-tables", " - selftests: hugetlb_dio: fixup check for initial conditions to skip in the", " start", " - btrfs: fix incorrect comparison for delayed refs", " - mailbox: qcom-cpucp: Mark the irq with IRQF_NO_SUSPEND flag", " - firmware: arm_scmi: Skip opp duplicates", " - firmware: arm_scmi: Report duplicate opps as firmware bugs", " - mmc: sunxi-mmc: Fix A100 compatible description", " - drm/bridge: tc358768: Fix DSI command tx", " - drm/xe: handle flat ccs during hibernation on igpu", " - pmdomain: arm: Use FLAG_DEV_NAME_FW to ensure unique names", " - pmdomain: core: Add GENPD_FLAG_DEV_NAME_FW flag", " - nouveau: fw: sync dma after setup is called.", " - nouveau: handle EBUSY and EAGAIN for GSP aux errors.", " - nouveau/dp: handle retries for AUX CH transfers with GSP.", " - drm/amd: Fix initialization mistake for NBIO 7.7.0", " - drm/amdgpu: fix check in gmc_v9_0_get_vm_pte()", " - drm/amdgpu: Fix video caps for H264 and HEVC encode maximum size", " - drm/amd/pm: print pp_dpm_mclk in ascending order on SMU v14.0.0", " - drm/amdgpu: enable GTT fallback handling for dGPUs only", " - drm/amdgpu/mes12: correct kiq unmap latency", " - drm/amd/display: Require minimum VBlank size for stutter optimization", " - drm/amd/display: Fix failure to read vram info due to static BP_RESULT", " - mm: refactor arch_calc_vm_flag_bits() and arm64 MTE handling", " - drm/xe: Restore system memory GGTT mappings", " - drm/xe: improve hibernation on igpu", " - lib/buildid: Fix build ID parsing logic", " - net: sched: u32: Add test case for systematic hnode IDR leaks", " - media: dvbdev: fix the logic when DVB_DYNAMIC_MINORS is not set", " - Linux 6.11.10", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53133", " - drm/amd/display: Handle dml allocation failure to avoid crash", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53108", " - drm/amd/display: Adjust VSDB parser for replay feature", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53134", " - pmdomain: imx93-blk-ctrl: correct remove path", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53132", " - drm/xe/oa: Fix \"Missing outer runtime PM protection\" warning", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53127", " - Revert \"mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K\"", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53130", " - nilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53105", " - mm: page_alloc: move mlocked flag clearance into free_pages_prepare()", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53109", " - nommu: pass NULL argument to vma_iter_prealloc()", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53131", " - nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53135", " - KVM: VMX: Bury Intel PT virtualization (guest/host mode) behind", " CONFIG_BROKEN", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53106", " - ima: fix buffer overrun in ima_eventdigest_init_common", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53110", " - vp_vdpa: fix id_table array not null terminated error", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53126", " - vdpa: solidrun: Fix UB bug with devres", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53111", " - mm/mremap: fix address wraparound in move_page_tables()", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53107", " - fs/proc/task_mmu: prevent integer overflow in pagemap_scan_get_args()", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53128", " - sched/task_stack: fix object_is_on_stack() for KASAN tagged pointers", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53112", " - ocfs2: uncache inode which has failed entering the group", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53113", " - mm: fix NULL pointer dereference in alloc_pages_bulk_noprof", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53114", " - x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 client", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53137", " - ARM: fix cacheflush with PAN", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53115", " - drm/vmwgfx: avoid null_ptr_deref in vmw_framebuffer_surface_create_handle", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53116", " - drm/panthor: Fix handling of partial GPU mapping of BOs", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53117", " - virtio/vsock: Improve MSG_ZEROCOPY error handling", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53118", " - vsock: Fix sk_error_queue memory leak", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53119", " - virtio/vsock: Fix accept_queue memory leak", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53120", " - net/mlx5e: CT: Fix null-ptr-deref in add rule err flow", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53138", " - net/mlx5e: kTLS, Fix incorrect page refcounting", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53121", " - net/mlx5: fs, lock FTE when checking if active", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53122", " - mptcp: cope racing subflow creation in mptcp_rcv_space_adjust", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53123", " - mptcp: error out earlier on disconnect", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53124", " - net: fix data-races around sk->sk_forward_alloc", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53129", " - drm/rockchip: vop: Fix a dereferenced before check warning", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53139", " - sctp: fix possible UAF in sctp_v6_available()", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53140", " - netlink: terminate outstanding dump on socket close", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649)", " - nvme/host: Fix RCU list traversal to use SRCU primitive", " - 9p: v9fs_fid_find: also lookup by inode if not found dentry", " - 9p: Avoid creating multiple slab caches with the same name", " - selftests/bpf: Verify that sync_linked_regs preserves subreg_def", " - nvmet-passthru: clear EUID/NGUID/UUID while using loop target", " - irqchip/ocelot: Fix trigger register address", " - pinctrl: aw9523: add missing mutex_destroy", " - pinctrl: intel: platform: Add Panther Lake to the list of supported", " - block: Fix elevator_get_default() checking for NULL q->tag_set", " - HID: multitouch: Add support for B2402FVA track point", " - HID: multitouch: Add quirk for HONOR MagicBook Art 14 touchpad", " - iommu/arm-smmu: Clarify MMU-500 CPRE workaround", " - nvme: disable CC.CRIME (NVME_CC_CRIME)", " - bpf: use kvzmalloc to allocate BPF verifier environment", " - crypto: api - Fix liveliness check in crypto_alg_tested", " - crypto: marvell/cesa - Disable hash algorithms", " - s390/ap: Fix CCA crypto card behavior within protected execution environment", " - sound: Make CONFIG_SND depend on INDIRECT_IOMEM instead of UML", " - drm/vmwgfx: Limit display layout ioctl array size to", " VMWGFX_NUM_DISPLAY_UNITS", " - selftests/bpf: Assert link info uprobe_multi count & path_size if unset", " - ALSA: hda/tas2781: Add new quirk for Lenovo, ASUS, Dell projects", " - drm/amdkfd: Accounting pdd vram_usage for svm", " - powerpc/powernv: Free name on error in opal_event_init()", " - net: phy: mdio-bcm-unimac: Add BCM6846 support", " - drm/xe/query: Increase timestamp width", " - nvme-loop: flush off pending I/O while shutting down loop controller", " - samples/landlock: Fix port parsing in sandboxer", " - vDPA/ifcvf: Fix pci_read_config_byte() return code handling", " - bpf: Fix mismatched RCU unlock flavour in bpf_out_neigh_v6", " - ASoC: Intel: avs: Update stream status in a separate thread", " - ASoC: codecs: Fix error handling in aw_dev_get_dsp_status function", " - ASoC: amd: yc: Add quirk for ASUS Vivobook S15 M3502RA", " - ASoC: amd: yc: Fix non-functional mic on ASUS E1404FA", " - ASoC: Intel: soc-acpi: lnl: Add match entry for TM2 laptops", " - netfs: Downgrade i_rwsem for a buffered write", " - HID: i2c-hid: Delayed i2c resume wakeup for 0x0d42 Goodix touchpad", " - HID: multitouch: Add quirk for Logitech Bolt receiver w/ Casa touchpad", " - HID: lenovo: Add support for Thinkpad X1 Tablet Gen 3 keyboard", " - ASoC: codecs: lpass-rx-macro: fix RXn(rx,n) macro for DSM_CTL and SEC7 regs", " - RISCV: KVM: use raw_spinlock for critical section in imsic", " - ASoC: rt722-sdca: increase clk_stop_timeout to fix clock stop issue", " - LoongArch: Use \"Exception return address\" to comment ERA", " - ASoC: fsl_micfil: Add sample rate constraint", " - net: usb: qmi_wwan: add Fibocom FG132 0x0112 composition", " - drm/xe: Enlarge the invalidation timeout from 150 to 500", " - drm/xe/guc/ct: Flush g2h worker in case of g2h response timeout", " - drm/xe: Handle unreliable MMIO reads during forcewake", " - drm/xe: Don't restart parallel queues multiple times on GT reset", " - mm: krealloc: Fix MTE false alarm in __do_krealloc", " - 9p: fix slab cache name creation for real", " - Linux 6.11.9", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53098", " - drm/xe/ufence: Prefetch ufence addr to catch bogus address", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53099", " - bpf: Check validity of link->type in bpf_link_show_fdinfo()", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53089", " - LoongArch: KVM: Mark hrtimer to expire in hard interrupt context", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53090", " - afs: Fix lock recursion", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53101", " - fs: Fix uninitialized value issue in from_kuid and from_kgid", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53091", " - bpf: Add sk_is_inet and IS_ICSK check in tls_sw_has_ctx_tx/rx", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53092", " - virtio_pci: Fix admin vq cleanup by using correct info pointer", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53102", " - nvme: make keep-alive synchronous operation", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53093", " - nvme-multipath: defer partition scanning", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53094", " - RDMA/siw: Add sendpage_ok() check to disable MSG_SPLICE_PAGES", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53100", " - nvme: tcp: avoid race between queue_lock lock and destroy", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53095", " - smb: client: Fix use-after-free of network namespace.", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645)", " - arm64: dts: rockchip: Fix rt5651 compatible value on rk3399-eaidk-610", " - arm64: dts: rockchip: Fix rt5651 compatible value on rk3399-sapphire-", " excavator", " - arm64: dts: rockchip: Move L3 cache outside CPUs in RK3588(S) SoC dtsi", " - arm64: dts: rockchip: Start cooling maps numbering from zero on ROCK 5B", " - arm64: dts: rockchip: Designate Turing RK1's system power controller", " - EDAC/qcom: Make irq configuration optional", " - arm64: dts: rockchip: Remove hdmi's 2nd interrupt on rk3328", " - arm64: dts: rockchip: Fix wakeup prop names on PineNote BT node", " - arm64: dts: rockchip: Fix reset-gpios property on brcm BT nodes", " - arm64: dts: rockchip: fix i2c2 pinctrl-names property on anbernic-rg353p/v", " - arm64: dts: rockchip: Drop regulator-init-microvolt from two boards", " - arm64: dts: rockchip: Fix bluetooth properties on rk3566 box demo", " - arm64: dts: rockchip: Fix bluetooth properties on Rock960 boards", " - arm64: dts: rockchip: Add DTS for FriendlyARM NanoPi R2S Plus", " - arm64: dts: rockchip: Remove undocumented supports-emmc property", " - arm64: dts: rockchip: Remove #cooling-cells from fan on Theobroma lion", " - arm64: dts: rockchip: Fix LED triggers on rk3308-roc-cc", " - arm64: dts: rockchip: remove num-slots property from rk3328-nanopi-r2s-plus", " - arm64: dts: qcom: sm8450 fix PIPE clock specification for pcie1", " - arm64: dts: imx8-ss-vpu: Fix imx8qm VPU IRQs", " - arm64: dts: imx8mp: correct sdhc ipg clk", " - arm64: dts: imx8mp-phyboard-pollux: Set Video PLL1 frequency to 506.8 MHz", " - firmware: qcom: scm: Return -EOPNOTSUPP for unsupported SHM bridge enabling", " - arm64: dts: rockchip: remove orphaned pinctrl-names from pinephone pro", " - ARM: dts: rockchip: fix rk3036 acodec node", " - ARM: dts: rockchip: drop grf reference from rk3036 hdmi", " - ARM: dts: rockchip: Fix the spi controller on rk3036", " - ARM: dts: rockchip: Fix the realtek audio codec on rk3036-kylin", " - arm64: dts: rockchip: Correct GPIO polarity on brcm BT nodes", " - sunrpc: handle -ENOTCONN in xs_tcp_setup_socket()", " - NFSv3: only use NFS timeout for MOUNT when protocols are compatible", " - NFS: Fix attribute delegation behaviour on exclusive create", " - NFS: Further fixes to attribute delegation a/mtime changes", " - nfs: avoid i_lock contention in nfs_clear_invalid_mapping", " - net: enetc: set MAC address to the VF net_device", " - net: dpaa_eth: print FD status in CPU endianness in dpaa_eth_fd tracepoint", " - dt-bindings: net: xlnx,axi-ethernet: Correct phy-mode property value", " - can: c_can: fix {rx,tx}_errors statistics", " - ice: change q_index variable type to s16 to store -1 value", " - e1000e: Remove Meteor Lake SMBUS workarounds", " - net: phy: ti: add PHY_RST_AFTER_CLK_EN flag", " - net: stmmac: Fix unbalanced IRQ wake disable warning on single irq case", " - netfilter: nf_tables: wait for rcu grace period on net_device removal", " - virtio_net: Support dynamic rss indirection table size", " - virtio_net: Sync rss config to device when virtnet_probe", " - virtio_net: Update rss when set queue", " - net: arc: rockchip: fix emac mdio node support", " - drivers: net: ionic: add missed debugfs cleanup to ionic_probe() error path", " - Revert \"ALSA: hda/conexant: Mute speakers at suspend / shutdown\"", " - media: stb0899_algo: initialize cfr before using it", " - media: dvb_frontend: don't play tricks with underflow values", " - media: adv7604: prevent underflow condition when reporting colorspace", " - scsi: sd_zbc: Use kvzalloc() to allocate REPORT ZONES buffer", " - ALSA: firewire-lib: fix return value on fail in amdtp_tscm_init()", " - tools/lib/thermal: Fix sampling handler context ptr", " - thermal/of: support thermal zones w/o trips subnode", " - ASoC: SOF: sof-client-probes-ipc4: Set param_size extension bits", " - media: pulse8-cec: fix data timestamp at pulse8_setup()", " - media: v4l2-ctrls-api: fix error handling for v4l2_g_ctrl()", " - can: m_can: m_can_close(): don't call free_irq() for IRQ-less devices", " - can: mcp251xfd: mcp251xfd_get_tef_len(): fix length calculation", " - can: mcp251xfd: mcp251xfd_ring_alloc(): fix coalescing configuration when", " switching CAN modes", " - can: {cc770,sja1000}_isa: allow building on x86_64", " - [Config] updateconfigs for CAN_{CC770,SJA1000}_ISA", " - drm/xe: Set mask bits for CCS_MODE register", " - pwm: imx-tpm: Use correct MODULO value for EPWM mode", " - rpmsg: glink: Handle rejected intent request better", " - drm/amd/pm: always pick the pptable from IFWI", " - drm/amd/display: Fix brightness level not retained over reboot", " - drm/imagination: Add a per-file PVR context list", " - drm/amdgpu: Adjust debugfs eviction and IB access permissions", " - drm/amdgpu: Adjust debugfs register access permissions", " - drm/amdgpu: Fix DPX valid mode check on GC 9.4.3", " - drm/amdgpu: prevent NULL pointer dereference if ATIF is not supported", " - thermal/drivers/qcom/lmh: Remove false lockdep backtrace", " - dm cache: correct the number of origin blocks to match the target length", " - dm cache: optimize dirty bit checking with find_next_bit when resizing", " - dm-unstriped: cast an operand to sector_t to prevent potential uint32_t", " overflow", " - mptcp: no admin perm to list endpoints", " - ALSA: usb-audio: Add quirk for HP 320 FHD Webcam", " - tracing: Fix tracefs mount options", " - net: wwan: t7xx: Fix off-by-one error in t7xx_dpmaif_rx_buf_alloc()", " - mptcp: use sock_kfree_s instead of kfree", " - arm64: Kconfig: Make SME depend on BROKEN for now", " - [Config] updateconfigs for ARM64_SME", " - arm64: smccc: Remove broken support for SMCCCv1.3 SVE discard hint", " - KVM: PPC: Book3S HV: Mask off LPCR_MER for a vCPU before running it to avoid", " spurious interrupts", " - btrfs: fix the length of reserved qgroup to free", " - btrfs: fix per-subvolume RO/RW flags with new mount API", " - platform/x86/amd/pmf: Relocate CPU ID macros to the PMF header", " - platform/x86/amd/pmf: Update SMU metrics table for 1AH family series", " - platform/x86/amd/pmf: Add SMU metrics table support for 1Ah family 60h model", " - i2c: designware: do not hold SCL low when I2C_DYNAMIC_TAR_UPDATE is not set", " - clk: qcom: gcc-x1e80100: Fix USB MP SS1 PHY GDSC pwrsts flags", " - clk: qcom: clk-alpha-pll: Fix pll post div mask when width is not set", " - fs/proc: fix compile warning about variable 'vmcore_mmap_ops'", " - objpool: fix to make percpu slot allocation more robust", " - mm/damon/core: handle zero {aggregation,ops_update} intervals", " - mm/damon/core: handle zero schemes apply interval", " - mm/mlock: set the correct prev on failure", " - thunderbolt: Add only on-board retimers when !CONFIG_USB4_DEBUGFS_MARGINING", " - usb: dwc3: fix fault at system suspend if device was already runtime", " suspended", " - USB: serial: qcserial: add support for Sierra Wireless EM86xx", " - USB: serial: option: add Fibocom FG132 0x0112 composition", " - USB: serial: option: add Quectel RG650V", " - clk: qcom: gcc-x1e80100: Fix halt_check for pipediv2 clocks", " - thunderbolt: Fix connection issue with Pluggable UD-4VPD dock", " - staging: vchiq_arm: Use devm_kzalloc() for drv_mgmt allocation", " - staging: vchiq_arm: Use devm_kzalloc() for vchiq_arm_state allocation", " - irqchip/gic-v3: Force propagation of the active state with a read-back", " - ucounts: fix counter leak in inc_rlimit_get_ucounts()", " - selftests: hugetlb_dio: check for initial conditions to skip in the start", " - firmware: qcom: scm: Refactor code to support multiple dload mode", " - [Config] updateconfigs for QCOM_SCM_DOWNLOAD_MODE_DEFAULT", " - firmware: qcom: scm: suppress download mode error", " - block: rework bio splitting", " - block: fix queue limits checks in blk_rq_map_user_bvec for real", " - drm/xe: Move LNL scheduling WA to xe_device.h", " - drm/xe/ufence: Flush xe ordered_wq in case of ufence timeout", " - drm/xe/guc/tlb: Flush g2h worker in case of tlb timeout", " - ASoC: amd: yc: fix internal mic on Xiaomi Book Pro 14 2022", " - xtensa: Emulate one-byte cmpxchg", " - Linux 6.11.8", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50265", " - ocfs2: remove entry once instead of null-ptr-dereference in", " ocfs2_xa_remove()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50266", " - clk: qcom: videocc-sm8350: use HW_CTRL_TRIGGER for vcodec GDSCs", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50267", " - USB: serial: io_edgeport: fix use after free in debug printk", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50268", " - usb: typec: fix potential out of bounds in ucsi_ccg_update_set_new_cam_cmd()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53083", " - usb: typec: qcom-pmic: init value of hdr_len/txbuf_len earlier", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50269", " - usb: musb: sunxi: Fix accessing an released usb phy", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53079", " - mm/thp: fix deferred split unqueue naming and locking", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50270", " - mm/damon/core: avoid overflow in damon_feed_loop_next_input()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50271", " - signal: restore the override_rlimit logic", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50272", " - filemap: Fix bounds checking in filemap_read()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53104", " - media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in", " uvc_parse_format", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50273", " - btrfs: reinitialize delayed ref list after deleting it from the list", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53064", " - idpf: fix idpf_vc_core_init error path", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50274", " - idpf: avoid vport access in idpf_get_link_ksettings", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53065", " - mm/slab: fix warning caused by duplicate kmem_cache creation in", " kmem_buckets_create", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50275", " - arm64/sve: Discard stale CPU state when handling SVE traps", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50276", " - net: vertexcom: mse102x: Fix possible double free of TX skb", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53066", " - nfs: Fix KMSAN warning in decode_getfattr_attrs()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53067", " - scsi: ufs: core: Start the RTC update work later", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50277", " - dm: fix a crash if blk_alloc_disk fails", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50278", " - dm cache: fix potential out-of-bounds access on the first resume", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50279", " - dm cache: fix out-of-bounds access to the dirty bitset when resizing", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50280", " - dm cache: fix flushing uninitialized delayed_work on cache_ctr error", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50281", " - KEYS: trusted: dcp: fix NULL dereference in AEAD crypto operation", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50282", " - drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53071", " - drm/panthor: Be stricter about IO mapping flags", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53080", " - drm/panthor: Lock XArray when getting entries for the VM", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53084", " - drm/imagination: Break an object reference loop", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53085", " - tpm: Lock TPM chip in tpm_pm_suspend() first", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53086", " - drm/xe: Drop VM dma-resv lock on xe_sync_in_fence_get failure in exec IOCTL", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53087", " - drm/xe: Fix possible exec queue leak in exec IOCTL", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50283", " - ksmbd: fix slab-use-after-free in smb3_preauth_hash_rsp", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50284", " - ksmbd: Fix the missing xa_store error check", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50285", " - ksmbd: check outstanding simultaneous SMB operations", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50286", " - ksmbd: fix slab-use-after-free in ksmbd_smb2_session_create", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50287", " - media: v4l2-tpg: prevent the risk of a division by zero", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50288", " - media: vivid: fix buffer overwrite when using > 32 buffers", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50289", " - media: av7110: fix a spectre vulnerability", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50290", " - media: cx24116: prevent overflows on SNR calculus", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53061", " - media: s5p-jpeg: prevent buffer overflows", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53081", " - media: ar0521: don't overflow when checking PLL values", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53062", " - media: mgb4: protect driver against spectre", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50291", " - media: dvb-core: add missing buffer index check", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50292", " - ASoC: stm32: spdifrx: fix dma channel release in stm32_spdifrx_remove", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53063", " - media: dvbdev: prevent the risk of out of memory access", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50293", " - net/smc: do not leave a dangling sk pointer in __smc_create()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50294", " - rxrpc: Fix missing locking causing hanging calls", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50295", " - net: arc: fix the device for dma_map_single/dma_unmap_single", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53082", " - virtio_net: Add hash_key_length check", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50296", " - net: hns3: fix kernel crash when uninstalling driver", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53088", " - i40e: fix race condition by adding filter's intermediate sync state", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50297", " - net: xilinx: axienet: Enqueue Tx packets in dql before dmaengine starts", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50298", " - net: enetc: allocate vf_state during PF probes", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50299", " - sctp: properly validate chunk size in sctp_sf_ootb()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50300", " - regulator: rtq2208: Fix uninitialized use of regulator_config", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50301", " - security/keys: fix slab-out-of-bounds in key_task_permission", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53072", " - platform/x86/amd/pmc: Detect when STB is not available", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50302", " - HID: core: zero-initialize the report buffer", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53068", " - firmware: arm_scmi: Fix slab-use-after-free in scmi_bus_notifier()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53069", " - firmware: qcom: scm: fix a NULL-pointer dereference", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629)", " - drm/amdgpu: fix random data corruption for sdma 7", " - cgroup: Fix potential overflow issue when checking max_depth", " - spi: geni-qcom: Fix boot warning related to pm_runtime and devres", " - perf trace: Fix non-listed archs in the syscalltbl routines", " - perf python: Fix up the build on architectures without HAVE_KVM_STAT_SUPPORT", " - scsi: scsi_debug: Fix do_device_access() handling of unexpected SG copy", " length", " - wifi: iwlegacy: Fix \"field-spanning write\" warning in il_enqueue_hcmd()", " - mac80211: MAC80211_MESSAGE_TRACING should depend on TRACING", " - wifi: mac80211: skip non-uploaded keys in ieee80211_iter_keys", " - wifi: ath11k: Fix invalid ring usage in full monitor mode", " - wifi: rtw89: pci: early chips only enable 36-bit DMA on specific PCI hosts", " - wifi: brcm80211: BRCM_TRACING should depend on TRACING", " - RDMA/cxgb4: Dump vendor specific QP details", " - RDMA/mlx5: Round max_rd_atomic/max_dest_rd_atomic up instead of down", " - RDMA/bnxt_re: Fix the usage of control path spin locks", " - RDMA/bnxt_re: synchronize the qp-handle table array", " - wifi: iwlwifi: mvm: really send iwl_txpower_constraints_cmd", " - wifi: iwlwifi: mvm: don't add default link in fw restart flow", " - Revert \"wifi: iwlwifi: remove retry loops in start\"", " - ASoC: cs42l51: Fix some error handling paths in cs42l51_probe()", " - net: stmmac: dwmac4: Fix high address display by updating reg_space[] from", " register values", " - dpll: add Embedded SYNC feature for a pin", " - ice: add callbacks for Embedded SYNC enablement on dpll pins", " - gtp: allow -1 to be specified as file description from userspace", " - bpf: Force checkpoint when jmp history is too long", " - bpf: Add bpf_mem_alloc_check_size() helper", " - net: skip offload for NETIF_F_IPV6_CSUM if ipv6 header contains extension", " - mlxsw: spectrum_ptp: Add missing verification before pushing Tx header", " - mlxsw: pci: Sync Rx buffers for CPU", " - mlxsw: pci: Sync Rx buffers for device", " - net: ethernet: mtk_wed: fix path of MT7988 WO firmware", " - bpf, test_run: Fix LIVE_FRAME frame update after a page has been recycled", " - iomap: improve shared block detection in iomap_unshare_iter", " - iomap: don't bother unsharing delalloc extents", " - iomap: share iomap_unshare_iter predicate code with fsdax", " - fsdax: remove zeroing code from dax_unshare_iter", " - iomap: turn iomap_want_unshare_iter into an inline function", " - kasan: Fix Software Tag-Based KASAN with GCC", " - firmware: arm_sdei: Fix the input parameter of cpuhp_remove_state()", " - afs: Fix missing subdir edit when renamed between parent dirs", " - gpio: sloppy-logic-analyzer: Check for error code from devm_mutex_init()", " call", " - smb: client: fix parsing of device numbers", " - smb: client: set correct device number on nfs reparse points", " - drm/mediatek: ovl: Remove the color format comment for ovl_fmt_convert()", " - drm/mediatek: Fix color format MACROs in OVL", " - drm/mediatek: Fix get efuse issue for MT8188 DPTX", " - drm/mediatek: Use cmdq_pkt_create() and cmdq_pkt_destroy()", " - cxl/events: Fix Trace DRAM Event Record", " - PCI: Fix pci_enable_acs() support for the ACS quirks", " - nvme: module parameter to disable pi with offsets", " - drm/panthor: Fix firmware initialization on systems with a page size > 4k", " - drm/panthor: Fail job creation when the group is dead", " - drm/panthor: Report group as timedout when we fail to properly suspend", " - fs/ntfs3: Fix warning possible deadlock in ntfs_set_state", " - fs/ntfs3: Stale inode instead of bad", " - rust: device: change the from_raw() function", " - scsi: scsi_transport_fc: Allow setting rport state to current state", " - cifs: Improve creating native symlinks pointing to directory", " - cifs: Fix creating native symlinks pointing to current or parent directory", " - ACPI: resource: Fold Asus Vivobook Pro N6506M* DMI quirks together", " - powercap: intel_rapl_msr: Add PL4 support for Arrowlake-U", " - thermal: intel: int340x: processor: Remove MMIO RAPL CPU hotplug support", " - thermal: intel: int340x: processor: Add MMIO RAPL PL4 support", " - net: amd: mvme147: Fix probe banner message", " - NFS: remove revoked delegation from server's delegation list", " - misc: sgi-gru: Don't disable preemption in GRU driver", " - NFSD: Initialize struct nfsd4_copy earlier", " - NFSD: Never decrement pending_async_copies on error", " - ALSA: usb-audio: Add quirks for Dell WD19 dock", " - wifi: rtlwifi: rtl8192du: Don't claim USB ID 0bda:8171", " - usbip: tools: Fix detach_port() invalid port error path", " - usb: phy: Fix API devm_usb_put_phy() can not release the phy", " - usb: typec: fix unreleased fwnode_handle in typec_port_register_altmodes()", " - usb: typec: tcpm: restrict SNK_WAIT_CAPABILITIES_TIMEOUT transitions to non", " self-powered devices", " - usb: typec: qcom-pmic-typec: use fwnode_handle_put() to release fwnodes", " - usb: typec: qcom-pmic-typec: fix missing fwnode removal in error path", " - xhci: Fix Link TRB DMA in command ring stopped completion event", " - xhci: Use pm_runtime_get to prevent RPM on unsupported systems", " - Revert \"driver core: Fix uevent_show() vs driver detach race\"", " - dt-bindings: iio: adc: ad7380: fix ad7380-4 reference supply", " - iio: light: veml6030: fix microlux value calculation", " - RISC-V: ACPI: fix early_ioremap to early_memremap", " - tools/mm: -Werror fixes in page-types/slabinfo", " - mm: shrinker: avoid memleak in alloc_shrinker_info", " - firmware: microchip: auto-update: fix poll_complete() to not report spurious", " timeout errors", " - thunderbolt: Honor TMU requirements in the domain when setting TMU mode", " - soc: qcom: pmic_glink: Handle GLINK intent allocation rejections", " - cxl/port: Fix CXL port initialization order when the subsystem is built-in", " - mmc: sdhci-pci-gli: GL9767: Fix low power mode on the set clock function", " - mmc: sdhci-pci-gli: GL9767: Fix low power mode in the SD Express process", " - block: fix sanity checks in blk_rq_map_user_bvec", " - phy: freescale: imx8m-pcie: Do CMN_RST just before PHY PLL lock check", " - btrfs: merge btrfs_orig_bbio_end_io() into btrfs_bio_end_io()", " - riscv: vdso: Prevent the compiler from inserting calls to memset()", " - Input: edt-ft5x06 - fix regmap leak when probe fails", " - ALSA: hda/realtek: Limit internal Mic boost on Dell platform", " - riscv: efi: Set NX compat flag in PE/COFF header", " - riscv: Use '%u' to format the output of 'cpu'", " - riscv: Remove unused GENERATING_ASM_OFFSETS", " - riscv: Remove duplicated GET_RM", " - cxl/port: Fix cxl_bus_rescan() vs bus_rescan_devices()", " - cxl/acpi: Ensure ports ready at cxl_acpi_probe() return", " - posix-cpu-timers: Clear TICK_DEP_BIT_POSIX_TIMER on clone", " - tpm: Return tpm2_sessions_init() when null key creation fails", " - tpm: Rollback tpm2_load_null()", " - drm/amdgpu/smu13: fix profile reporting", " - tpm: Lazily flush the auth session", " - mei: use kvmalloc for read buffer", " - x86/traps: Enable UBSAN traps on x86", " - x86/traps: move kmsan check after instrumentation_begin", " - accel/ivpu: Fix NOC firewall interrupt handling", " - ALSA: hda/realtek: Fix headset mic on TUXEDO Gemini 17 Gen3", " - ALSA: hda/realtek: Fix headset mic on TUXEDO Stellaris 16 Gen6 mb1", " - nvme: re-fix error-handling for io_uring nvme-passthrough", " - kasan: remove vmalloc_percpu test", " - drm/tests: helpers: Add helper for drm_display_mode_from_cea_vic()", " - drm/xe: Fix register definition order in xe_regs.h", " - drm/xe: Kill regs/xe_sriov_regs.h", " - drm/xe: Add mmio read before GGTT invalidate", " - drm/xe: Don't short circuit TDR on jobs not started", " - btrfs: fix extent map merging not happening for adjacent extents", " - btrfs: fix defrag not merging contiguous extents due to merged extent maps", " - gpiolib: fix debugfs newline separators", " - gpiolib: fix debugfs dangling chip separator", " - vmscan,migrate: fix page count imbalance on node stats when demoting pages", " - mm, mmap: limit THP alignment of anonymous mappings to PMD-aligned sizes", " - Input: fix regression when re-registering input handlers", " - mm: multi-gen LRU: ignore non-leaf pmd_young for force_scan=true", " - mm: multi-gen LRU: remove MM_LEAF_OLD and MM_NONLEAF_TOTAL stats", " - mm: shrink skip folio mapped by an exiting process", " - mm: multi-gen LRU: use {ptep,pmdp}_clear_young_notify()", " - riscv: dts: starfive: Update ethernet phy0 delay parameter values for Star64", " - riscv: dts: starfive: disable unused csi/camss nodes", " - arm64: dts: qcom: msm8939: revert use of APCS mbox for RPM", " - arm64: dts: qcom: x1e80100-yoga-slim7x: fix nvme regulator boot glitch", " - arm64: dts: qcom: x1e80100: Fix up BAR spaces", " - arm64: dts: qcom: x1e80100-vivobook-s15: fix nvme regulator boot glitch", " - arm64: dts: qcom: x1e80100: fix PCIe4 interconnect", " - arm64: dts: qcom: x1e80100-qcp: fix nvme regulator boot glitch", " - arm64: dts: qcom: x1e80100-crd: fix nvme regulator boot glitch", " - arm64: dts: qcom: x1e80100: Add Broadcast_AND region in LLCC block", " - arm64: dts: qcom: x1e80100: fix PCIe4 and PCIe6a PHY clocks", " - drm/xe/xe2hpg: Add Wa_15016589081", " - drm/amdgpu/swsmu: fix ordering for setting workload_mask", " - drm/amdgpu/swsmu: default to fullscreen 3D profile for dGPUs", " - fs/ntfs3: Sequential field availability check in mi_enum_attr()", " - drm/amdgpu: handle default profile on on devices without fullscreen 3D", " - MIPS: export __cmpxchg_small()", " - RISC-V: disallow gcc + rust builds", " - [Config] updateconfigs after disabling rust with gcc on riscv", " - rcu/kvfree: Add kvfree_rcu_barrier() API", " - rcu/kvfree: Refactor kvfree_rcu_queue_batch()", " - Linux 6.11.7", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50212", " - lib: alloc_tag_module_unload must wait for pending kfree_rcu calls", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53046", " - arm64: dts: imx8ulp: correct the flexspi compatible string", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53052", " - io_uring/rw: fix missing NOWAIT check for O_DIRECT start write", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50213", " - drm/tests: hdmi: Fix memory leaks in drm_display_mode_from_cea_vic()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50214", " - drm/connector: hdmi: Fix memory leak in drm_display_mode_from_cea_vic()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50215", " - nvmet-auth: assign dh_key to NULL after kfree_sensitive", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50216", " - xfs: fix finding a last resort AG in xfs_filestream_pick_ag", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50217", " - btrfs: fix use-after-free of block device file in", " __btrfs_free_extra_devids()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53043", " - mctp i2c: handle NULL header address", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50303", " - resource,kexec: walk_system_ram_res_rev must retain resource flags", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50218", " - ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50219", " - mm/page_alloc: let GFP_ATOMIC order-0 allocs access highatomic reserves", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50263", " - fork: only invoke khugepaged, ksm hooks if no error", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50220", " - fork: do not invoke uffd on fork if error occurs", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53047", " - mptcp: init: protect sched with rcu_read_lock", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50221", " - drm/amd/pm: Vangogh: Fix kernel memory out of bounds write", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50222", " - iov_iter: fix copy_page_from_iter_atomic() if KMAP_LOCAL_FORCE_MAP", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50223", " - sched/numa: Fix the potential null pointer dereference in task_numa_work()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53053", " - scsi: ufs: core: Fix another deadlock during RTC update", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53075", " - riscv: Prevent a bad reference count on CPU nodes", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50224", " - spi: spi-fsl-dspi: Fix crash when not using GPIO chip select", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50225", " - btrfs: fix error propagation of split bios", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53054", " - cgroup/bpf: use a dedicated workqueue for cgroup bpf destruction", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50226", " - cxl/port: Fix use-after-free, permit out-of-order decoder shutdown", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50227", " - thunderbolt: Fix KASAN reported stack out-of-bounds read in", " tb_retimer_scan()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50228", " - mm: shmem: fix data-race in shmem_getattr()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50229", " - nilfs2: fix potential deadlock with newly created symlinks", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50230", " - nilfs2: fix kernel bug due to missing clearing of checked flag", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50231", " - iio: gts-helper: Fix memory leaks in iio_gts_build_avail_scale_table()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53076", " - iio: gts-helper: Fix memory leaks for the error path of", " iio_gts_build_avail_scale_table()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50232", " - iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50233", " - staging: iio: frequency: ad9832: fix division by zero in", " ad9832_calc_freqreg()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53055", " - wifi: iwlwifi: mvm: fix 6 GHz scan construction", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50234", " - wifi: iwlegacy: Clear stale interrupts before resuming device", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50235", " - wifi: cfg80211: clear wdev->cqm_config pointer on free", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50236", " - wifi: ath10k: Fix memory leak in management tx", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50237", " - wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50238", " - phy: qcom: qmp-usbc: fix NULL-deref on runtime suspend", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50239", " - phy: qcom: qmp-usb-legacy: fix NULL-deref on runtime suspend", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50240", " - phy: qcom: qmp-usb: fix NULL-deref on runtime suspend", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53077", " - rpcrdma: Always release the rpcrdma_device's xa_array", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50242", " - fs/ntfs3: Additional check in ntfs_file_release", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50243", " - fs/ntfs3: Fix general protection fault in run_is_mapped_full", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50244", " - fs/ntfs3: Additional check in ni_clear()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50245", " - fs/ntfs3: Fix possible deadlock in mi_read", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50246", " - fs/ntfs3: Add rough attr alloc_size check", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50247", " - fs/ntfs3: Check if more than chunk-size bytes are written", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50248", " - ntfs3: Add bounds checking to mi_enum_attr()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53078", " - drm/tegra: Fix NULL vs IS_ERR() check in probe()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53056", " - drm/mediatek: Fix potential NULL dereference in mtk_crtc_destroy()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50249", " - ACPI: CPPC: Make rmw_lock a raw_spin_lock", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50250", " - fsdax: dax_unshare_iter needs to copy entire blocks", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50251", " - netfilter: nft_payload: sanitize offset and length before calling", " skb_checksum()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50252", " - mlxsw: spectrum_ipip: Fix memory leak when changing remote IPv6 address", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50253", " - bpf: Check the validity of nr_words in bpf_iter_bits_new()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50254", " - bpf: Free dynamically allocated bits in bpf_iter_bits_destroy()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50255", " - Bluetooth: hci: fix null-ptr-deref in hci_read_supported_codecs", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50256", " - netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50257", " - netfilter: Fix use-after-free in get_info()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50258", " - net: fix crash when config small gso_max_size/gso_ipv4_max_size", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50262", " - bpf: Fix out-of-bounds write in trie_get_next_key()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53044", " - net/sched: sch_api: fix xa_insert() error path in tcf_block_get_ext()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50259", " - netdevsim: Add trailing zero to terminate the string in", " nsim_nexthop_bucket_activity_write()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50304", " - ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53042", " - ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_init_flow()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53048", " - ice: fix crash on probe for DPLL enabled E810 LOM", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53058", " - net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50260", " - sock_map: fix a NULL pointer dereference in sock_map_link_update_prog()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53045", " - ASoC: dapm: fix bounds checker error in dapm_widget_list_create", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50261", " - macsec: Fix use-after-free while sending the offloading packet", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53059", " - wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53074", " - wifi: iwlwifi: mvm: don't leak a link on AP removal", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53049", " - slub/kunit: fix a WARNING due to unwrapped __kmalloc_cache_noprof", "", " * Oracular update: v6.11.6 upstream stable release (LP: #2091386)", " - bpf: Use raw_spinlock_t in ringbuf", " - iio: accel: bma400: Fix uninitialized variable field_value in tap event", " handling.", " - reset: starfive: jh71x0: Fix accessing the empty member on JH7110 SoC", " - bpf: sync_linked_regs() must preserve subreg_def", " - bpf: Make sure internal and UAPI bpf_redirect flags don't overlap", " - irqchip/riscv-imsic: Fix output text of base address", " - bpf: devmap: provide rxq after redirect", " - cpufreq/amd-pstate: Fix amd_pstate mode switch on shared memory systems", " - lib/Kconfig.debug: fix grammar in RUST_BUILD_ASSERT_ALLOW", " - bpf: Fix memory leak in bpf_core_apply", " - RDMA/bnxt_re: Fix a possible memory leak", " - RDMA/bnxt_re: Fix incorrect AVID type in WQE structure", " - RDMA/bnxt_re: Add a check for memory allocation", " - x86/resctrl: Avoid overflow in MB settings in bw_validate()", " - ARM: dts: bcm2837-rpi-cm3-io3: Fix HDMI hpd-gpio pin", " - clk: rockchip: fix finding of maximum clock ID", " - bpf: Check the remaining info_cnt before repeating btf fields", " - bpf: fix unpopulated name_len field in perf_event link info", " - selftests/bpf: fix perf_event link info name_len assertion", " - riscv, bpf: Fix possible infinite tailcall when CONFIG_CFI_CLANG is enabled", " - s390/pci: Handle PCI error codes other than 0x3a", " - bpf: fix kfunc btf caching for modules", " - iio: frequency: {admv4420,adrf6780}: format Kconfig entries", " - iio: frequency: admv4420: fix missing select REMAP_SPI in Kconfig", " - drm/vmwgfx: Handle possible ENOMEM in vmw_stdu_connector_atomic_check", " - selftests/bpf: Fix cross-compiling urandom_read", " - bpf: Fix unpopulated path_size when uprobe_multi fields unset", " - sched/core: Disable page allocation in task_tick_mm_cid()", " - ALSA: hda/cs8409: Fix possible NULL dereference", " - firmware: arm_scmi: Fix the double free in scmi_debugfs_common_setup()", " - RDMA/cxgb4: Fix RDMA_CM_EVENT_UNREACHABLE error for iWARP", " - RDMA/irdma: Fix misspelling of \"accept*\"", " - RDMA/srpt: Make slab cache names unique", " - elevator: do not request_module if elevator exists", " - elevator: Remove argument from elevator_find_get", " - ipv4: give an IPv4 dev to blackhole_netdev", " - net: sparx5: fix source port register when mirroring", " - RDMA/bnxt_re: Fix the max CQ WQEs for older adapters", " - RDMA/bnxt_re: Fix out of bound check", " - RDMA/bnxt_re: Fix incorrect dereference of srq in async event", " - RDMA/bnxt_re: Return more meaningful error", " - RDMA/bnxt_re: Avoid CPU lockups due fifo occupancy check loop", " - RDMA/bnxt_re: Get the toggle bits from SRQ events", " - RDMA/bnxt_re: Change the sequence of updating the CQ toggle value", " - RDMA/bnxt_re: Fix a bug while setting up Level-2 PBL pages", " - RDMA/bnxt_re: Fix the GID table length", " - accel/qaic: Fix the for loop used to walk SG table", " - drm/panel: himax-hx83102: Adjust power and gamma to optimize brightness", " - drm/msm/dpu: make sure phys resources are properly initialized", " - drm/msm/dpu: move CRTC resource assignment to dpu_encoder_virt_atomic_check", " - drm/msm/dpu: check for overflow in _dpu_crtc_setup_lm_bounds()", " - drm/msm/dsi: improve/fix dsc pclk calculation", " - drm/msm/dsi: fix 32-bit signed integer extension in pclk_rate calculation", " - drm/msm: Avoid NULL dereference in msm_disp_state_print_regs()", " - drm/msm: Allocate memory for disp snapshot with kvzalloc()", " - firmware: arm_scmi: Queue in scmi layer for mailbox implementation", " - net/smc: Fix memory leak when using percpu refs", " - [PATCH} hwmon: (jc42) Properly detect TSE2004-compliant devices again", " - net: usb: usbnet: fix race in probe failure", " - net: stmmac: dwmac-tegra: Fix link bring-up sequence", " - octeontx2-af: Fix potential integer overflows on integer shifts", " - ring-buffer: Fix reader locking when changing the sub buffer order", " - drm/amd/amdgpu: Fix double unlock in amdgpu_mes_add_ring", " - macsec: don't increment counters for an unrelated SA", " - netdevsim: use cond_resched() in nsim_dev_trap_report_work()", " - net: ethernet: aeroflex: fix potential memory leak in", " greth_start_xmit_gbit()", " - net/smc: Fix searching in list of known pnetids in smc_pnet_add_pnetid", " - net: xilinx: axienet: fix potential memory leak in axienet_start_xmit()", " - net: ethernet: rtsn: fix potential memory leak in rtsn_start_xmit()", " - bpf: Fix truncation bug in coerce_reg_to_size_sx()", " - net: systemport: fix potential memory leak in bcm_sysport_xmit()", " - irqchip/renesas-rzg2l: Fix missing put_device", " - drm/msm/dpu: Don't always set merge_3d pending flush", " - drm/msm/dpu: don't always program merge_3d block", " - net: bcmasp: fix potential memory leak in bcmasp_xmit()", " - drm/msm/a6xx+: Insert a fence wait before SMMU table update", " - tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink().", " - net: dsa: mv88e6xxx: Fix the max_vid definition for the MV88E6361", " - genetlink: hold RCU in genlmsg_mcast()", " - ravb: Remove setting of RX software timestamp", " - net: ravb: Only advertise Rx/Tx timestamps if hardware supports it", " - net: dsa: vsc73xx: fix reception from VLAN-unaware bridges", " - scsi: target: core: Fix null-ptr-deref in target_alloc_device()", " - smb: client: fix possible double free in smb2_set_ea()", " - smb: client: fix OOBs when building SMB2_IOCTL request", " - usb: typec: altmode should keep reference to parent", " - s390: Initialize psw mask in perf_arch_fetch_caller_regs()", " - drm/xe: fix unbalanced rpm put() with fence_fini()", " - drm/xe: fix unbalanced rpm put() with declare_wedged()", " - drm/xe: Take job list lock in xe_sched_add_pending_job", " - drm/xe: Don't free job in TDR", " - drm/xe: Use bookkeep slots for external BO's in exec IOCTL", " - bpf: Fix link info netfilter flags to populate defrag flag", " - Bluetooth: bnep: fix wild-memory-access in proto_unregister", " - vmxnet3: Fix packet corruption in vmxnet3_xdp_xmit_frame", " - net: ethernet: mtk_eth_soc: fix memory corruption during fq dma init", " - net/mlx5: Check for invalid vector index on EQ creation", " - net/mlx5: Fix command bitmask initialization", " - net/mlx5: Unregister notifier on eswitch init failure", " - net/mlx5e: Don't call cleanup on profile rollback failure", " - bpf, sockmap: SK_DROP on attempted redirects of unsupported af_vsock", " - vsock: Update rx_bytes on read_skb()", " - vsock: Update msg_count on read_skb()", " - bpf, vsock: Drop static vsock_bpf_prot initialization", " - riscv, bpf: Make BPF_CMPXCHG fully ordered", " - nvme-pci: fix race condition between reset and nvme_dev_disable()", " - bpf: Fix iter/task tid filtering", " - bpf: Fix incorrect delta propagation between linked registers", " - bpf: Fix print_reg_state's constant scalar dump", " - cdrom: Avoid barrier_nospec() in cdrom_ioctl_media_changed()", " - fgraph: Allocate ret_stack_list with proper size", " - mm: shmem: rename shmem_is_huge() to shmem_huge_global_enabled()", " - mm: shmem: move shmem_huge_global_enabled() into", " shmem_allowable_huge_orders()", " - mm: huge_memory: add vma_thp_disabled() and thp_disabled_by_hw()", " - mm: don't install PMD mappings when THPs are disabled by the hw/process/vma", " - iio: adc: ti-lmp92064: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - xhci: dbgtty: remove kfifo_out() wrapper", " - xhci: dbgtty: use kfifo from tty_port struct", " - xhci: dbc: honor usb transfer size boundaries.", " - uprobe: avoid out-of-bounds memory access of fetching args", " - drm/vboxvideo: Replace fake VLA at end of vbva_mouse_pointer_shape with real", " VLA", " - ASoC: amd: yc: Add quirk for HP Dragonfly pro one", " - ASoC: codecs: lpass-rx-macro: add missing CDC_RX_BCL_VBAT_RF_PROC2 to", " default regs values", " - ASoC: fsl_sai: Enable 'FIFO continue on error' FCONT bit", " - arm64: Force position-independent veneers", " - udf: refactor udf_current_aext() to handle error", " - udf: refactor udf_next_aext() to handle error", " - udf: refactor inode_bmap() to handle error", " - udf: fix uninit-value use in udf_get_fileshortad", " - ASoC: qcom: sm8250: add qrb4210-rb2-sndcard compatible string", " - fsnotify: Avoid data race between fsnotify_recalc_mask() and", " fsnotify_object_watched()", " - drm/xe/mcr: Use Xe2_LPM steering tables for Xe2_HPM", " - cifs: Validate content of NFS reparse point buffer", " - LoongArch: Don't crash in stack_top() for tasks without vDSO", " - objpool: fix choosing allocation for percpu slots", " - jfs: Fix sanity check in dbMount", " - tracing/probes: Fix MAX_TRACE_ARGS limit handling", " - tracing: Consider the NULL character when validating the event length", " - xfrm: extract dst lookup parameters into a struct", " - xfrm: respect ip protocols rules criteria when performing dst lookups", " - xfrm: validate new SA's prefixlen using SA family when sel.family is unset", " - netfilter: bpf: must hold reference on net namespace", " - net: pse-pd: Fix out of bound for loop", " - net/sun3_82586: fix potential memory leak in sun3_82586_send_packet()", " - be2net: fix potential memory leak in be_xmit()", " - net: plip: fix break; causing plip to never transmit", " - bnxt_en: replace ptp_lock with irqsave variant", " - octeon_ep: Implement helper for iterating packets in Rx queue", " - octeon_ep: Add SKB allocation failures handling in __octep_oq_process_rx()", " - net: dsa: mv88e6xxx: Fix error when setting port policy on mv88e6393x", " - bpf, arm64: Fix address emission with tag-based KASAN enabled", " - fsl/fman: Save device references taken in mac_probe()", " - fsl/fman: Fix refcount handling of fman-related devices", " - net: wwan: fix global oob in wwan_rtnl_policy", " - net: fix races in netdev_tx_sent_queue()/dev_watchdog()", " - virtio_net: fix integer overflow in stats", " - mlxsw: spectrum_router: fix xa_store() error checking", " - net: usb: usbnet: fix name regression", " - bpf: Preserve param->string when parsing mount options", " - bpf: Add MEM_WRITE attribute", " - bpf: Fix overloading of MEM_UNINIT's meaning", " - bpf: Remove MEM_UNINIT from skb/xdp MTU helpers", " - net/sched: act_api: deny mismatched skip_sw/skip_hw flags for actions", " created by classifiers", " - net: sched: fix use-after-free in taprio_change()", " - net: sched: use RCU read-side critical section in taprio_dump()", " - r8169: avoid unsolicited interrupts", " - posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime()", " - Bluetooth: hci_core: Disable works on hci_unregister_dev", " - Bluetooth: SCO: Fix UAF on sco_sock_timeout", " - Bluetooth: ISO: Fix UAF on iso_sock_timeout", " - bpf,perf: Fix perf_event_detach_bpf_prog error handling", " - bpf: fix do_misc_fixups() for bpf_get_branch_snapshot()", " - net: dsa: microchip: disable EEE for KSZ879x/KSZ877x/KSZ876x", " - net: dsa: mv88e6xxx: group cycle counter coefficients", " - net: dsa: mv88e6xxx: read cycle counter period from hardware", " - net: dsa: mv88e6xxx: support 4000ps cycle counter period", " - bpf: Add the missing BPF_LINK_TYPE invocation for sockmap", " - ASoC: dt-bindings: davinci-mcasp: Fix interrupts property", " - ASoC: dt-bindings: davinci-mcasp: Fix interrupt properties", " - ASoC: loongson: Fix component check failed on FDT systems", " - ASoC: topology: Bump minimal topology ABI version", " - ASoC: max98388: Fix missing increment of variable slot_found", " - ASoC: rsnd: Fix probe failure on HiHope boards due to endpoint parsing", " - PCI: Hold rescan lock while adding devices during host probe", " - fs: pass offset and result to backing_file end_write() callback", " - fuse: update inode size after extending passthrough write", " - ASoC: fsl_micfil: Add a flag to distinguish with different volume control", " types", " - ALSA: firewire-lib: Avoid division by zero in apply_constraint_to_size()", " - fbdev: wm8505fb: select CONFIG_FB_IOMEM_FOPS", " - powercap: dtpm_devfreq: Fix error check against dev_pm_qos_add_request()", " - nfsd: cancel nfsd_shrinker_work using sync mode in nfs4_state_shutdown_net", " - ALSA: hda/realtek: Update default depop procedure", " - smb: client: Handle kstrdup failures for passwords", " - cifs: fix warning when destroy 'cifs_io_request_pool'", " - PCI/pwrctl: Add WCN6855 support", " - PCI/pwrctl: Abandon QCom WCN probe on pre-pwrseq device-trees", " - cpufreq: CPPC: fix perf_to_khz/khz_to_perf conversion exception", " - btrfs: qgroup: set a more sane default value for subtree drop threshold", " - btrfs: clear force-compress on remount when compress mount option is given", " - btrfs: fix passing 0 to ERR_PTR in btrfs_search_dir_index_item()", " - perf/x86/rapl: Fix the energy-pkg event for AMD CPUs", " - btrfs: reject ro->rw reconfiguration if there are hard ro requirements", " - btrfs: zoned: fix zone unusable accounting for freed reserved extent", " - btrfs: fix read corruption due to race with extent map merging", " - drm/amd: Guard against bad data for ATIF ACPI method", " - ACPI: resource: Add LG 16T90SP to irq1_level_low_skip_override[]", " - ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context", " - ACPI: button: Add DMI quirk for Samsung Galaxy Book2 to fix initial lid", " detection issue", " - nilfs2: fix kernel bug due to missing clearing of buffer delay flag", " - fs: don't try and remove empty rbtree node", " - xfs: don't fail repairs on metadata files with no attr fork", " - openat2: explicitly return -E2BIG for (usize > PAGE_SIZE)", " - KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory", " - KVM: arm64: Unregister redistributor for failed vCPU creation", " - KVM: arm64: Fix shift-out-of-bounds bug", " - KVM: arm64: Don't eagerly teardown the vgic on init error", " - firewire: core: fix invalid port index for parent device", " - x86/lam: Disable ADDRESS_MASKING in most cases", " - [Config] updateconfigs to disable ADDRESS_MASKING", " - x86/sev: Ensure that RMP table fixups are reserved", " - ALSA: hda/tas2781: select CRC32 instead of CRC32_SARWATE", " - ALSA: hda/realtek: Add subwoofer quirk for Acer Predator G9-593", " - LoongArch: Get correct cores_per_package for SMT systems", " - LoongArch: Enable IRQ if do_ale() triggered in irq-enabled context", " - LoongArch: Make KASAN usable for variable cpu_vabits", " - xfrm: fix one more kernel-infoleak in algo dumping", " - hv_netvsc: Fix VF namespace also in synthetic NIC NETDEV_REGISTER event", " - md/raid10: fix null ptr dereference in raid10_size()", " - drm/bridge: Fix assignment of the of_node of the parent to aux bridge", " - drm/amd/display: Disable PSR-SU on Parade 08-01 TCON too", " - platform/x86/intel/pmc: Fix pmc_core_iounmap to call iounmap for valid", " addresses", " - fgraph: Fix missing unlock in register_ftrace_graph()", " - fgraph: Change the name of cpuhp state to \"fgraph:online\"", " - net: phy: dp83822: Fix reset pin definitions", " - nfsd: fix race between laundromat and free_stateid", " - drm/amd/display: temp w/a for DP Link Layer compliance", " - ata: libata: Set DID_TIME_OUT for commands that actually timed out", " - ASoC: SOF: Intel: hda-loader: do not wait for HDaudio IOC", " - ASoC: SOF: Intel: hda: Handle prepare without close for non-HDA DAI's", " - ASoC: SOF: Intel: hda: Always clean up link DMA during stop", " - ASoC: SOF: ipc4-topology: Do not set ALH node_id for aggregated DAIs", " - ASoC: dapm: avoid container_of() to get component", " - ASoC: qcom: sc7280: Fix missing Soundwire runtime stream alloc", " - ASoC: qcom: sdm845: add missing soundwire runtime stream alloc", " - ASoC: qcom: Fix NULL Dereference in asoc_qcom_lpass_cpu_platform_probe()", " - Revert \" fs/9p: mitigate inode collisions\"", " - Revert \"fs/9p: remove redundant pointer v9ses\"", " - Revert \"fs/9p: fix uaf in in v9fs_stat2inode_dotl\"", " - Revert \"fs/9p: simplify iget to remove unnecessary paths\"", " - soundwire: intel_ace2x: Send PDI stream number during prepare", " - x86: support user address masking instead of non-speculative conditional", " - x86: fix whitespace in runtime-const assembler output", " - x86: fix user address masking non-canonical speculation issue", " - platform/x86: dell-wmi: Ignore suspend notifications", " - ACPI: PRM: Clean up guid type in struct prm_handler_info", " - ASoC: qcom: Select missing common Soundwire module code on SDM845", " - Linux 6.11.6", "", " * ovs/linuxbridge jobs running on ubuntu jammy broken with latest kernel", " 5.15.0-127.137 (LP: #2091990)", " - netfilter: xtables: fix typo causing some targets not to load on IPv6", "", " * By always inlining _compound_head(), clone() sees 3%+ performance increase", " (LP: #2089327)", " - mm: always inline _compound_head() with", " CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP=y", "", " * Keyboard backlight controls do not work on Asus ROG Zephyrus GA503RM in", " Oracular (LP: #2089113)", " - hid-asus: use hid for brightness control on keyboard", "", " * Random flickering with Intel i915 (Comet Lake and Kaby Lake) on Linux 6.8+", " (LP: #2086587)", " - SAUCE: iommu/intel: disable DMAR for KBL and CML integrated gfx", "", " * Add list of source files to linux-buildinfo (LP: #2086606)", " - [Packaging] Sort build dependencies alphabetically", " - [Packaging] Add list of used source files to buildinfo package", "", " * asus: Fix thermal profile initialization on Lunar Lake (LP: #2085950)", " - platform/x86: asus-wmi: Fix thermal profile initialization", "", " * drm/xe: Fix LNL getting wedged after idling (LP: #2085944)", " - drm/xe/guc/ct: Flush g2h worker in case of g2h response timeout", "", " * UFS: uspi->s_3apb UBSAN: shift-out-of-bounds (LP: #2087853)", " - ufs: ufs_sb_private_info: remove unused s_{2, 3}apb fields", "", " * Mute/mic LEDs don't function on HP EliteBook 645 G10 (LP: #2087983)", " - ALSA: hda/realtek: fix mute/micmute LEDs for a HP EliteBook 645 G10", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152)", " - ALSA: scarlett2: Add error check after retrieving PEQ filter values", " - ALSA: hda/conexant - Fix audio routing for HP EliteOne 1000 G2", " - net: enetc: remove xdp_drops statistic from enetc_xdp_drop()", " - net: enetc: block concurrent XDP transmissions during ring reconfiguration", " - net: enetc: disable Tx BD rings after they are empty", " - net: enetc: disable NAPI after all rings are disabled", " - net: enetc: add missing static descriptor and inline keyword", " - udp: Compute L4 checksum as usual when not segmenting the skb", " - arm64: dts: marvell: cn9130-sr-som: fix cp0 mdio pin numbers", " - arm64: probes: Fix simulate_ldr*_literal()", " - net: macb: Avoid 20s boot delay by skipping MDIO bus registration for fixed-", " link PHY", " - selftests: mptcp: join: test for prohibited MPC to port-based endp", " - fat: fix uninitialized variable", " - mm: khugepaged: fix the arguments order in khugepaged_collapse_file trace", " point", " - net: fec: Move `fec_ptp_read()` to the top of the file", " - net: fec: Remove duplicated code", " - mptcp: prevent MPC handshake on port-based signal endpoints", " - s390/sclp: Deactivate sclp after all its users", " - s390/sclp_vt220: Convert newlines to CRLF instead of LFCR", " - KVM: s390: gaccess: Check if guest address is in memslot", " - KVM: s390: Change virtual to physical address access in diag 0x258 handler", " - x86/cpufeatures: Define X86_FEATURE_AMD_IBPB_RET", " - x86/cpufeatures: Add a IBPB_NO_RET BUG flag", " - x86/entry: Have entry_ibpb() invalidate return predictions", " - x86/bugs: Skip RSB fill at VMEXIT", " - x86/bugs: Do not use UNTRAIN_RET with IBPB on entry", " - fgraph: Use CPU hotplug mechanism to initialize idle shadow stacks", " - Input: xpad - add support for 8BitDo Ultimate 2C Wireless Controller", " - io_uring/sqpoll: close race on waiting for sqring entries", " - selftest: hid: add the missing tests directory", " - Input: xpad - add support for MSI Claw A1M", " - scsi: mpi3mr: Validate SAS port assignments", " - scsi: ufs: core: Fix the issue of ICU failure", " - scsi: ufs: core: Requeue aborted request", " - drm/i915/dp_mst: Handle error during DSC BW overhead/slice calculation", " - drm/i915/dp_mst: Don't require DSC hblank quirk for a non-DSC compatible", " mode", " - drm/xe/xe_sync: initialise ufence.signalled", " - drm/xe/ufence: ufence can be signaled right after wait_woken", " - drm/vmwgfx: Cleanup kms setup without 3d", " - drm/vmwgfx: Handle surface check failure correctly", " - drm/amdgpu/mes: fix issue of writing to the same log buffer from 2 MES pipes", " - drm/amdgpu/smu13: always apply the powersave optimization", " - drm/amdgpu/swsmu: Only force workload setup on init", " - drm/amdgpu: prevent BO_HANDLES error from being overwritten", " - iio: dac: ad5770r: add missing select REGMAP_SPI in Kconfig", " - iio: dac: ltc1660: add missing select REGMAP_SPI in Kconfig", " - iio: dac: stm32-dac-core: add missing select REGMAP_MMIO in Kconfig", " - iio: adc: ti-ads8688: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: hid-sensors: Fix an error handling path in", " _hid_sensor_set_report_latency()", " - iio: light: veml6030: fix ALS sensor resolution", " - iio: light: opt3001: add missing full-scale range value", " - iio: amplifiers: ada4250: add missing select REGMAP_SPI in Kconfig", " - iio: frequency: adf4377: add missing select REMAP_SPI in Kconfig", " - iio: chemical: ens160: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: light: bu27008: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: magnetometer: af8133j: add missing select IIO_(TRIGGERED_)BUFFER in", " Kconfig", " - iio: resolver: ad2s1210 add missing select REGMAP in Kconfig", " - iio: pressure: bm1390: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: dac: ad5766: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: proximity: mb1232: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: dac: ad3552r: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: adc: ti-lmp92064: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: adc: ti-lmp92064: add missing select REGMAP_SPI in Kconfig", " - iio: adc: ti-ads124s08: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: resolver: ad2s1210: add missing select (TRIGGERED_)BUFFER in Kconfig", " - iio: adc: ad7944: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: accel: kx022a: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - Bluetooth: Remove debugfs directory on module init failure", " - Bluetooth: btusb: Fix not being able to reconnect after suspend", " - Bluetooth: btusb: Fix regression with fake CSR controllers 0a12:0001", " - xhci: Fix incorrect stream context type macro", " - xhci: Mitigate failed set dequeue pointer commands", " - USB: serial: option: add support for Quectel EG916Q-GL", " - USB: serial: option: add Telit FN920C04 MBIM compositions", " - usb: typec: qcom-pmic-typec: fix sink status being overwritten with RP_DEF", " - usb: gadget: f_uac2: fix return value for UAC2_ATTRIBUTE_STRING store", " - usb: dwc3: Wait for EndXfer completion before restoring GUSB2PHYCFG", " - usb: dwc3: core: Fix system suspend on TI AM62 platforms", " - misc: microchip: pci1xxxx: add support for NVMEM_DEVID_AUTO for EEPROM", " device", " - misc: microchip: pci1xxxx: add support for NVMEM_DEVID_AUTO for OTP device", " - serial: imx: Update mctrl old_status on RTSD interrupt", " - x86/resctrl: Annotate get_mem_config() functions as __init", " - x86/CPU/AMD: Only apply Zenbleed fix for Zen2 during late microcode load", " - x86/entry_32: Do not clobber user EFLAGS.ZF", " - irqchip/sifive-plic: Unmask interrupt in plic_irq_enable()", " - irqchip/sifive-plic: Return error code on failure", " - serial: qcom-geni: fix polled console initialisation", " - serial: qcom-geni: revert broken hibernation support", " - serial: qcom-geni: fix shutdown race", " - serial: qcom-geni: fix dma rx cancellation", " - serial: qcom-geni: fix receiver enable", " - mm: vmscan.c: fix OOM on swap stress test", " - ALSA: hda/conexant - Use cached pin control for Node 0x1d on HP EliteOne", " 1000 G2", " - Linux 6.11.5", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50192", " - irqchip/gic-v4: Don't allow a VMOVP on a dying VPE", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50069", " - pinctrl: apple: check devm_kasprintf() returned value", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50070", " - pinctrl: stm32: check devm_kasprintf() returned value", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50196", " - pinctrl: ocelot: fix system hang on level based interrupts", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50197", " - pinctrl: intel: platform: fix error path in device_for_each_child_node()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50071", " - pinctrl: nuvoton: fix a double free in ma35_pinctrl_dt_node_to_map_func()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50072", " - x86/bugs: Use code segment selector for VERW operand", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50073", " - tty: n_gsm: Fix use-after-free in gsm_cleanup_mux", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50193", " - x86/entry_32: Clear CPU buffers after register restore in NMI return", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50074", " - parport: Proper fix for array out-of-bounds access", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50100", " - USB: gadget: dummy-hcd: Fix \"task hung\" problem", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50075", " - xhci: tegra: fix checked USB2 port number", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50076", " - vt: prevent kernel-infoleak in con_font_get()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50077", " - Bluetooth: ISO: Fix multiple init when debugfs is disabled", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50078", " - Bluetooth: Call iso_exit() on module unload", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50198", " - iio: light: veml6030: fix IIO device retrieval from embedded device", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50201", " - drm/radeon: Fix encoder->possible_clones", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50098", " - scsi: ufs: core: Set SDEV_OFFLINE when UFS is shut down", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50079", " - io_uring/sqpoll: ensure task state is TASK_RUNNING when running task_work", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50080", " - ublk: don't allow user copy for unprivileged device", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50081", " - blk-mq: setup queue ->tag_set before initializing hctx", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50082", " - blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50101", " - iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI devices", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50083", " - tcp: fix mptcp DSS corruption due to large pmtu xmit", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50068", " - mm/damon/tests/sysfs-kunit.h: fix memory leak in", " damon_sysfs_test_add_targets()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50199", " - mm/swapfile: skip HugeTLB pages for unuse_vma", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50066", " - mm/mremap: fix move_normal_pmd/retract_page_tables race", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50202", " - nilfs2: propagate directory read errors from nilfs_find_entry()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50200", " - maple_tree: correct tree corruption on spanning store", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50084", " - net: microchip: vcap api: Fix memory leaks in vcap_api_encode_rule_test()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50194", " - arm64: probes: Fix uprobes for big-endian kernels", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50099", " - arm64: probes: Remove broken LDR (literal) uprobe support", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50195", " - posix-clock: Fix missing timespec64 check in pc_clock_settime()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50085", " - mptcp: pm: fix UaF read in mptcp_pm_nl_rm_addr_or_subflow", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50086", " - ksmbd: fix user-after-free from session log off", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50087", " - btrfs: fix uninitialized pointer free on read_alloc_one_name() error", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50088", " - btrfs: fix uninitialized pointer free in add_inode_ref()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068)", " - net: fec: don't save PTP state if PTP is unsupported", " - fs/ntfs3: Do not call file_modified if collapse range failed", " - fs/ntfs3: Optimize large writes into sparse file", " - fs/ntfs3: Fix sparse warning for bigendian", " - fs/ntfs3: Fix sparse warning in ni_fiemap", " - fs/ntfs3: Refactor enum_rstbl to suppress static checker", " - vdpa/octeon_ep: Fix format specifier for pointers in debug messages", " - virtio_console: fix misc probe bugs", " - perf vdso: Missed put on 32-bit dsos", " - perf build: Fix static compilation error when libdw is not installed", " - perf build: Fix build feature-dwarf_getlocations fail for old libdw", " - zram: don't free statically defined names", " - bpf: Call the missed btf_record_free() when map creation fails", " - selftests/bpf: Fix ARG_PTR_TO_LONG {half-,}uninitialized test", " - bpf: Check percpu map value size first", " - s390/facility: Disable compile time optimization for decompressor code", " - s390/mm: Add cond_resched() to cmm_alloc/free_pages()", " - bpf, x64: Fix a jit convergence issue", " - ext4: nested locking for xattr inode", " - s390/cpum_sf: Remove WARN_ON_ONCE statements", " - s390/traps: Handle early warnings gracefully", " - ktest.pl: Avoid false positives with grub2 skip regex", " - soundwire: intel_bus_common: enable interrupts before exiting reset", " - PCI: Add function 0 DMA alias quirk for Glenfly Arise chip", " - clk: bcm: bcm53573: fix OF node leak in init", " - PCI: Add ACS quirk for Qualcomm SA8775P", " - i2c: i801: Use a different adapter-name for IDF adapters", " - PCI: Mark Creative Labs EMU20k2 INTx masking as broken", " - RISC-V: Don't have MAX_PHYSMEM_BITS exceed phys_addr_t", " - mfd: intel_soc_pmic_chtwc: Make Lenovo Yoga Tab 3 X90F DMI match less strict", " - mfd: intel-lpss: Add Intel Panther Lake LPSS PCI IDs", " - riscv: Omit optimized string routines when using KASAN", " - riscv: avoid Imbalance in RAS", " - RDMA/mlx5: Enforce umem boundaries for explicit ODP page faults", " - PCI: qcom: Disable mirroring of DBI and iATU register space in BAR region", " - PCI: endpoint: Assign PCI domain number for endpoint controllers", " - soundwire: cadence: re-check Peripheral status with delayed_work", " - riscv/kexec_file: Fix relocation type R_RISCV_ADD16 and R_RISCV_SUB16", " unknown", " - media: videobuf2-core: clear memory related fields in", " __vb2_plane_dmabuf_put()", " - remoteproc: imx_rproc: Use imx specific hook for find_loaded_rsc_table", " - usb: chipidea: udc: enable suspend interrupt after usb reset", " - usb: dwc2: Adjust the timing of USB Driver Interrupt Registration in the", " Crashkernel Scenario", " - xhci: dbc: Fix STALL transfer event handling", " - usb: host: xhci-plat: Parse xhci-missing_cas_quirk and apply quirk", " - comedi: ni_routing: tools: Check when the file could not be opened", " - LoongArch: Fix memleak in pci_acpi_scan_root()", " - netfilter: nf_nat: don't try nat source port reallocation for reverse dir", " clash", " - netfilter: nf_reject: Fix build warning when CONFIG_BRIDGE_NETFILTER=n", " - tools/iio: Add memory allocation failure check for trigger_name", " - staging: vme_user: added bound check to geoid", " - driver core: bus: Return -EIO instead of 0 when show/store invalid bus", " attribute", " - scsi: lpfc: Add ELS_RSP cmd to the list of WQEs to flush in", " lpfc_els_flush_cmd()", " - scsi: lpfc: Revise TRACE_EVENT log flag severities from KERN_ERR to", " KERN_WARNING", " - NFSD: Mark filecache \"down\" if init fails", " - nfsd: nfsd_destroy_serv() must call svc_destroy() even if nfsd_startup_net()", " failed", " - ice: set correct dst VSI in only LAN filters", " - ice: clear port vlan config during reset", " - ice: disallow DPLL_PIN_STATE_SELECTABLE for dpll output pins", " - ice: fix VLAN replay after reset", " - SUNRPC: Fix integer overflow in decode_rc_list()", " - net: phy: aquantia: AQR115c fix up PMA capabilities", " - net: phy: aquantia: remove usage of phy_set_max_speed", " - tcp: fix to allow timestamp undo if no retransmits were sent", " - tcp: fix tcp_enter_recovery() to zero retrans_stamp when it's safe", " - tcp: fix TFO SYN_RECV to not zero retrans_stamp with retransmits out", " - rxrpc: Fix uninitialised variable in rxrpc_send_data()", " - net: dsa: sja1105: fix reception from VLAN-unaware bridges", " - selftests: net: no_forwarding: fix VID for $swp2 in one_bridge_two_pvids()", " test", " - net: pse-pd: Fix enabled status mismatch", " - Bluetooth: btusb: Don't fail external suspend requests", " - net: phy: bcm84881: Fix some error handling paths", " - net: ethernet: adi: adin1110: Fix some error handling path in", " adin1110_read_fifo()", " - net: dsa: b53: fix jumbo frame mtu check", " - net: dsa: b53: fix max MTU for 1g switches", " - net: dsa: b53: fix max MTU for BCM5325/BCM5365", " - net: dsa: b53: allow lower MTUs on BCM5325/5365", " - net: dsa: b53: fix jumbo frames on 10/100 ports", " - drm/nouveau: pass cli to nouveau_channel_new() instead of drm+device", " - nouveau/dmem: Fix privileged error in copy engine channel", " - gpio: aspeed: Add the flush write to ensure the write complete.", " - gpio: aspeed: Use devm_clk api to manage clock source", " - x86/xen: mark boot CPU of PV guest in MSR_IA32_APICBASE", " - powercap: intel_rapl_tpmi: Ignore minor version change", " - ice: Fix entering Safe Mode", " - ice: Fix netif_is_ice() in Safe Mode", " - ice: Flush FDB entries before reset", " - drm/xe: Restore GT freq on GSC load error", " - drm/xe: Make wedged_mode debugfs writable", " - net: ibm: emac: mal: fix wrong goto", " - net: ti: icssg-prueth: Fix race condition for VLAN table access", " - btrfs: zoned: fix missing RCU locking in error message when loading zone", " info", " - sctp: ensure sk_state is set to CLOSED if hashing fails in sctp_listen_start", " - netfilter: fib: check correct rtable in vrf setups", " - net: ibm: emac: mal: add dcr_unmap to _remove", " - net: dsa: refuse cross-chip mirroring operations", " - rtnetlink: Add bulk registration helpers for rtnetlink message handlers.", " - vxlan: Handle error of rtnl_register_module().", " - bridge: Handle error of rtnl_register_module().", " - mctp: Handle error of rtnl_register_module().", " - mpls: Handle error of rtnl_register_module().", " - phonet: Handle error of rtnl_register_module().", " - rcu/nocb: Fix rcuog wake-up from offline softirq", " - HID: multitouch: Add support for lenovo Y9000P Touchpad", " - hwmon: intel-m10-bmc-hwmon: relabel Columbiaville to CVL Die Temperature", " - hwmon: (tmp513) Add missing dependency on REGMAP_I2C", " - hwmon: (mc34vr500) Add missing dependency on REGMAP_I2C", " - hwmon: (adm9240) Add missing dependency on REGMAP_I2C", " - hwmon: (adt7470) Add missing dependency on REGMAP_I2C", " - hwmon: (ltc2991) Add missing dependency on REGMAP_I2C", " - HID: plantronics: Workaround for an unexcepted opposite volume key", " - HID: wacom: Hardcode (non-inverted) AES pens as BTN_TOOL_PEN", " - Revert \"usb: yurex: Replace snprintf() with the safer scnprintf() variant\"", " - usb: dwc3: core: Stop processing of pending events if controller is halted", " - usb: xhci: Fix problem with xhci resume from suspend", " - usb: storage: ignore bogus device raised by JieLi BR21 USB sound chip", " - usb: dwc3: re-enable runtime PM after failed resume", " - usb: gadget: core: force synchronous registration", " - hid: intel-ish-hid: Fix uninitialized variable 'rv' in", " ish_fw_xfer_direct_dma", " - ACPI: resource: Make Asus ExpertBook B2402 matches cover more models", " - ACPI: resource: Make Asus ExpertBook B2502 matches cover more models", " - drm/amdgpu: partially revert powerplay `__counted_by` changes", " - drm/amd/display: Clear update flags after update has been applied", " - drm/amdkfd: Fix an eviction fence leak", " - drm/amd/display: fix hibernate entry for DCN35+", " - drm/xe/guc_submit: fix xa_store() error checking", " - drm/i915/hdcp: fix connector refcounting", " - drm/xe/ct: fix xa_store() error checking", " - scsi: ufs: Use pre-calculated offsets in ufshcd_init_lrb()", " - Revert \"mmc: mvsdio: Use sg_miter for PIO\"", " - mmc: sdhci-of-dwcmshc: Prevent stale command interrupt handling", " - mptcp: fallback when MPTCP opts are dropped after 1st data", " - ata: libata: avoid superfluous disk spin down + spin up during hibernation", " - OPP: fix error code in dev_pm_opp_set_config()", " - net: dsa: lan9303: ensure chip reset and wait for READY status", " - net: phy: realtek: Fix MMD access on RTL8126A-integrated PHY", " - mptcp: pm: do not remove closing subflows", " - powercap: intel_rapl_tpmi: Fix bogus register reading", " - selftests/mm: fix incorrect buffer->mirror size in hmm2 double_map test", " - selftests/rseq: Fix mm_cid test failure", " - btrfs: split remaining space to discard in chunks", " - btrfs: add cancellation points to trim loops", " - PM: domains: Fix alloc/free in dev_pm_domain_attach|detach_list()", " - idpf: use actual mbx receive payload length", " - fs/proc/kcore.c: allow translation of physical memory addresses", " - PCI: Pass domain number to pci_bus_release_domain_nr() explicitly", " - io_uring/rw: fix cflags posting for single issue multishot read", " - Linux 6.11.4", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50182", " - secretmem: disable memfd_secret() if arch cannot set direct map", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50019", " - kthread: unpark only parked kthread", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50096", " - nouveau/dmem: Fix vulnerability in migrate_to_ram upon copy error", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50020", " - ice: Fix improper handling of refcount in ice_sriov_set_msix_vec_count()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50021", " - ice: Fix improper handling of refcount in ice_dpll_init_rclk_pins()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50022", " - device-dax: correct pgoff align in dax_set_mapping()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50185", " - mptcp: handle consistently DSS corruption", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50023", " - net: phy: Remove LED entry from LEDs list on unregister", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50024", " - net: Fix an unsafe loop on the list", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50186", " - net: explicitly clear the sk pointer, when pf->create fails", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50025", " - scsi: fnic: Move flush_work initialization out of if block", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50026", " - scsi: wd33c93: Don't use stale scsi_pointer value", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50027", " - thermal: core: Free tzp copy along with the thermal zone", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50028", " - thermal: core: Reference count the zone in thermal_zone_get_by_id()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50029", " - Bluetooth: hci_conn: Fix UAF in hci_enhanced_setup_sync", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50030", " - drm/xe/ct: prevent UAF in send_recv()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50187", " - drm/vc4: Stop the active perfmon before being destroyed", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50031", " - drm/v3d: Stop the active perfmon before being destroyed", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50189", " - HID: amd_sfh: Switch to device-managed dmam_alloc_coherent()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50033", " - slip: make slhc_remember() more robust against malicious packets", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50034", " - net/smc: fix lacks of icsk_syn_mss with IPPROTO_SMC", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50035", " - ppp: fix ppp_async_encode() illegal access", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50036", " - net: do not delay dst_entries_add() in dst_release()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50037", " - drm/fbdev-dma: Only cleanup deferred I/O if necessary", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50092", " - net: netconsole: fix wrong warning", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50038", " - netfilter: xtables: avoid NFPROTO_UNSPEC where needed", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50039", " - net/sched: accept TCA_STAB only for root qdisc", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50040", " - igb: Do not bring the device up after non-fatal error", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50041", " - i40e: Fix macvlan leak by synchronizing access to mac_filter_hash", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50042", " - ice: Fix increasing MSI-X on VF", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50093", " - thermal: intel: int340x: processor: Fix warning during module unload", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50043", " - nfsd: fix possible badness in FREE_STATEID", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50044", " - Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50045", " - netfilter: br_netfilter: fix panic with metadata_dst skb", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50094", " - sfc: Don't invoke xdp_do_flush() from netpoll.", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50188", " - net: phy: dp83869: fix memory corruption when enabling fiber", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50046", " - NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50190", " - ice: fix memleak in ice_init_tx_topology()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50180", " - fbdev: sisfb: Fix strbuf array overflow", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50047", " - smb: client: fix UAF in async decryption", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50048", " - fbcon: Fix a NULL pointer dereference issue in fbcon_putcs", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50049", " - drm/amd/display: Check null pointer before dereferencing se", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50090", " - drm/xe/oa: Fix overflow in oa batch buffer", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50183", " - scsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV", " instance", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50055", " - driver core: bus: Fix double free in driver API bus_register()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50091", " - dm vdo: don't refer to dedupe_context after releasing it", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50056", " - usb: gadget: uvc: Fix ERR_PTR dereference in uvc_v4l2.c", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50184", " - virtio_pmem: Check device status before requesting flush", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50057", " - usb: typec: tipd: Free IRQ only if it was requested before", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50058", " - serial: protect uart_port_dtr_rts() in uart_shutdown() too", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50181", " - clk: imx: Remove CLK_SET_PARENT_GATE for DRAM mux for i.MX7D", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50059", " - ntb: ntb_hw_switchtec: Fix use after free vulnerability in", " switchtec_ntb_remove due to race condition", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50060", " - io_uring: check if we need to reschedule during overflow flush", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50061", " - i3c: master: cdns: Fix use after free vulnerability in cdns_i3c_master", " Driver Due to Race Condition", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50062", " - RDMA/rtrs-srv: Avoid null pointer deref during path establishment", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50095", " - RDMA/mad: Improve handling of timed out WRs of mad agent", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50063", " - bpf: Prevent tail call between progs attached to different hooks", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50191", " - ext4: don't set SB_RDONLY after filesystem errors", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50064", " - zram: free secondary algorithms names", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50065", " - ntfs3: Change to non-blocking allocation in ntfs_d_hash", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50089", " - unicode: Don't special case ignorable code points", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052)", " - jump_label: Fix static_key_slow_dec() yet again", " - scsi: st: Fix input/output error on empty drive reset", " - scsi: pm8001: Do not overwrite PCI queue mapping", " - drm/i915/psr: Do not wait for PSR being idle on on Panel Replay", " - drm/i915/display: BMG supports UHBR13.5", " - drm/i915/dp: Fix AUX IO power enabling for eDP PSR", " - drm/amdgpu: Fix get each xcp macro", " - drm/amd/display: handle nulled pipe context in DCE110's set_drr()", " - ksmbd: fix warning: comparison of distinct pointer types lacks a cast", " - mailbox: ARM_MHU_V3 should depend on ARM64", " - [Config] updateconfigs for ARM_MHU_V3", " - mailbox: rockchip: fix a typo in module autoloading", " - ceph: fix a memory leak on cap_auths in MDS client", " - drm/i915/dp: Fix colorimetry detection", " - ieee802154: Fix build error", " - net: sparx5: Fix invalid timestamps", " - net/mlx5: Added cond_resched() to crdump collection", " - net/mlx5e: SHAMPO, Fix overflow of hd_per_wq", " - netfilter: uapi: NFTA_FLOWTABLE_HOOK is NLA_NESTED", " - net: ieee802154: mcr20a: Use IRQF_NO_AUTOEN flag in request_irq()", " - net: wwan: qcom_bam_dmux: Fix missing pm_runtime_disable()", " - selftests: netfilter: Fix nft_audit.sh for newer nft binaries", " - selftests: netfilter: Add missing return value", " - Bluetooth: btmrvl: Use IRQF_NO_AUTOEN flag in request_irq()", " - afs: Fix missing wire-up of afs_retry_request()", " - net: Add netif_get_gro_max_size helper for GRO", " - net: Fix gso_features_check to check for both dev->gso_{ipv4_,}max_size", " - net: fec: Restart PPS after link state change", " - net: fec: Reload PTP registers after link-state change", " - net: stmmac: dwmac4: extend timeout for VLAN Tag register busy bit check", " - ipv4: ip_gre: Fix drops of small packets in ipgre_xmit", " - netfs: Fix missing wakeup after issuing writes", " - net: phy: realtek: Check the index value in led_hw_control_get", " - bridge: mcast: Fail MDB get request on empty entry", " - iomap: constrain the file range passed to iomap_file_unshare", " - dt-bindings: net: xlnx,axi-ethernet: Add missing reg minItems", " - ASoC: topology: Fix incorrect addressing assignments", " - ASoC: atmel: mchp-pdmc: Skip ALSA restoration if substream runtime is", " uninitialized", " - drm/connector: hdmi: Fix writing Dynamic Range Mastering infoframes", " - io_uring: fix memory leak when cache init fail", " - rust: kbuild: split up helpers.c", " - rust: kbuild: auto generate helper exports", " - rust: mutex: fix __mutex_init() usage in case of PREEMPT_RT", " - ALSA: mixer_oss: Remove some incorrect kfree_const() usages", " - ALSA: hda/realtek: Fix the push button function for the ALC257", " - cifs: Remove intermediate object of failed create reparse call", " - drm/panthor: Lock the VM resv before calling drm_gpuvm_bo_obtain_prealloc()", " - ALSA: hda/generic: Unconditionally prefer preferred_dacs pairs", " - ASoC: imx-card: Set card.owner to avoid a warning calltrace if SND=m", " - drm/xe: Restore pci state upon resume", " - drm/xe: Resume TDR after GT reset", " - cifs: Do not convert delimiter when parsing NFS-style symlinks", " - tools/rtla: Fix installation from out-of-tree build", " - ALSA: gus: Fix some error handling paths related to get_bpos() usage", " - ALSA: hda/conexant: Fix conflicting quirk for System76 Pangolin", " - drm/amd/display: Disable replay if VRR capability is false", " - drm/amd/display: Fix VRR cannot enable", " - drm/amd/display: Re-enable panel replay feature", " - e1000e: avoid failing the system during pm_suspend", " - wifi: ath9k: fix possible integer overflow in ath9k_get_et_stats()", " - crypto: x86/sha256 - Add parentheses around macros' single arguments", " - crypto: octeontx - Fix authenc setkey", " - crypto: octeontx2 - Fix authenc setkey", " - ice: Adjust over allocation of memory in ice_sched_add_root_node() and", " ice_sched_add_node()", " - wifi: iwlwifi: mvm: Fix a race in scan abort flow", " - wifi: iwlwifi: mvm: drop wrong STA selection in TX", " - net: hisilicon: hip04: fix OF node leak in probe()", " - net: hisilicon: hns_dsaf_mac: fix OF node leak in hns_mac_get_info()", " - net: hisilicon: hns_mdio: fix OF node leak in probe()", " - ACPICA: Fix memory leak if acpi_ps_get_next_namepath() fails", " - ACPICA: Fix memory leak if acpi_ps_get_next_field() fails", " - ACPI: resource: Skip IRQ override on Asus Vivobook Go E1404GAB", " - wifi: mt76: mt7915: disable tx worker during tx BA session enable/disable", " - net: sched: consistently use rcu_replace_pointer() in taprio_change()", " - Bluetooth: btusb: Add Realtek RTL8852C support ID 0x0489:0xe122", " - Bluetooth: btrtl: Set msft ext address filter quirk for RTL8852B", " - ACPI: video: Add force_vendor quirk for Panasonic Toughbook CF-18", " - ACPI: CPPC: Add support for setting EPP register in FFH", " - wifi: rtw88: select WANT_DEV_COREDUMP", " - l2tp: free sessions using rcu", " - l2tp: use rcu list add/del when updating lists", " - ACPI: EC: Do not release locks during operation region accesses", " - net: skbuff: sprinkle more __GFP_NOWARN on ingress allocs", " - net: mvpp2: Increase size of queue_name buffer", " - bnxt_en: Extend maximum length of version string by 1 byte", " - ipv4: Check !in_dev earlier for ioctl(SIOCSIFADDR).", " - wifi: rtw89: correct base HT rate mask for firmware", " - netfilter: nf_tables: do not remove elements if set backend implements", " .abort", " - ipv4: Mask upper DSCP bits and ECN bits in NETLINK_FIB_LOOKUP family", " - nvme-keyring: restrict match length for version '1' identifiers", " - nvme-tcp: sanitize TLS key handling", " - nvme-tcp: check for invalidated or revoked key", " - net: atlantic: Avoid warning about potential string truncation", " - crypto: simd - Do not call crypto_alloc_tfm during registration", " - netpoll: Ensure clean state on setup failures", " - tcp: avoid reusing FIN_WAIT2 when trying to find port in connect() process", " - wifi: iwlwifi: mvm: use correct key iteration", " - wifi: iwlwifi: allow only CN mcc from WRDD", " - virt: sev-guest: Ensure the SNP guest messages do not exceed a page", " - wifi: mac80211: fix RCU list iterations", " - ACPICA: iasl: handle empty connection_node", " - proc: add config & param to block forcing mem writes", " - [Config] updateconfigs to select PROC_MEM_ALWAYS_FORCE", " - vfs: use RCU in ilookup", " - drivers/perf: arm_spe: Use perf_allow_kernel() for permissions", " - nvme: fix metadata handling in nvme-passthrough", " - can: netlink: avoid call to do_set_data_bittiming callback with stale", " can_priv::ctrlmode", " - netdev-genl: Set extack and fix error on napi-get", " - wifi: wilc1000: Do not operate uninitialized hardware during suspend/resume", " - arm64: trans_pgd: mark PTEs entries as valid to avoid dead kexec()", " - net: phy: Check for read errors in SIOCGMIIREG", " - x86/bugs: Add missing NO_SSB flag", " - x86/bugs: Fix handling when SRSO mitigation is disabled", " - crypto: hisilicon - fix missed error branch", " - wifi: mt76: mt7915: add dummy HW offload of IEEE 802.11 fragmentation", " - wifi: mt76: mt7915: hold dev->mt76.mutex while disabling tx worker", " - netfs: Cancel dirty folios that have no storage destination", " - nfp: Use IRQF_NO_AUTOEN flag in request_irq()", " - ALSA: usb-audio: Add input value sanity checks for standard types", " - x86/apic: Remove logical destination mode for 64-bit", " - ALSA: usb-audio: Define macros for quirk table entries", " - ALSA: usb-audio: Replace complex quirk lines with macros", " - ALSA: usb-audio: Add quirk for RME Digiface USB", " - ALSA: usb-audio: Add mixer quirk for RME Digiface USB", " - ALSA: hda/realtek: Refactor and simplify Samsung Galaxy Book init", " - ALSA: usb-audio: Add logitech Audio profile quirk", " - ASoC: codecs: wsa883x: Handle reading version failure", " - ALSA: control: Take power_ref lock primarily", " - tools/x86/kcpuid: Protect against faulty \"max subleaf\" values", " - x86/pkeys: Add PKRU as a parameter in signal handling functions", " - x86/pkeys: Restore altstack access in sigreturn()", " - x86/kexec: Add EFI config table identity mapping for kexec kernel", " - ALSA: hdsp: Break infinite MIDI input flush loop", " - tools/nolibc: powerpc: limit stack-protector workaround to GCC", " - selftests/nolibc: avoid passing NULL to printf(\"%s\")", " - x86/syscall: Avoid memcpy() for ia32 syscall_get_arguments()", " - ASoC: Intel: boards: always check the result of", " acpi_dev_get_first_match_dev()", " - hwmon: (nct6775) add G15CF to ASUS WMI monitoring list", " - pmdomain: core: Don't hold the genpd-lock when calling dev_pm_domain_set()", " - pmdomain: core: Use dev_name() instead of kobject_get_path() in debugfs", " - rcuscale: Provide clear error when async specified without primitives", " - power: reset: brcmstb: Do not go into infinite loop if reset fails", " - iommu/arm-smmu-v3: Match Stall behaviour for S2", " - iommu/vt-d: Always reserve a domain ID for identity setup", " - iommu/vt-d: Unconditionally flush device TLB for pasid table updates", " - iommu/arm-smmu-v3: Do not use devm for the cd table allocations", " - drm/amdgpu: disallow multiple BO_HANDLES chunks in one submit", " - drm/amd/display: Use gpuvm_min_page_size_kbytes for DML2 surfaces", " - ata: pata_serverworks: Do not use the term blacklist", " - ata: sata_sil: Rename sil_blacklist to sil_quirks", " - selftests/bpf: fix uprobe.path leak in bpf_testmod", " - scsi: smartpqi: Add new controller PCI IDs", " - HID: Ignore battery for all ELAN I2C-HID devices", " - drm/amd/display: Underflow Seen on DCN401 eGPU", " - drm/xe: Name and document Wa_14019789679", " - jfs: UBSAN: shift-out-of-bounds in dbFindBits", " - scsi: smartpqi: correct stream detection", " - scsi: smartpqi: add new controller PCI IDs", " - drm/amdgpu: add raven1 gfxoff quirk", " - drm/amdgpu: enable gfxoff quirk on HP 705G4", " - drm/amdkfd: Fix resource leak in criu restore queue", " - HID: multitouch: Add support for Thinkpad X12 Gen 2 Kbd Portfolio", " - platform/x86: touchscreen_dmi: add nanote-next quirk", " - platform/x86/amd: pmf: Add quirk for TUF Gaming A14", " - drm/stm: ltdc: reset plane transparency after plane disable", " - drm/amdgpu/gfx12: properly handle error ints on all pipes", " - drm/amdgpu/gfx9: properly handle error ints on all pipes", " - drm/amd/display: Fix possible overflow in integer multiplication", " - drm/printer: Allow NULL data in devcoredump printer", " - perf,x86: avoid missing caller address in stack traces captured in uprobe", " - scsi: aacraid: Rearrange order of struct aac_srb_unit", " - scsi: lpfc: Fix unsolicited FLOGI kref imbalance when in direct attached", " topology", " - scsi: lpfc: Update PRLO handling in direct attached topology", " - drm/amd/display: Force enable 3DLUT DMA check for dcn401 in DML", " - drm/amdgpu: fix unchecked return value warning for amdgpu_gfx", " - drm/amdgpu: fix unchecked return value warning for amdgpu_atombios", " - perf: Fix event_function_call() locking", " - scsi: NCR5380: Initialize buffer for MSG IN and STATUS transfers", " - drm/radeon/r100: Handle unknown family in r100_cp_init_microcode()", " - drm/amd/display: Unlock Pipes Based On DET Allocation", " - drm/amdgpu: fix ptr check warning in gfx9 ip_dump", " - drm/amdgpu: fix ptr check warning in gfx10 ip_dump", " - drm/amdgpu: fix ptr check warning in gfx11 ip_dump", " - drm/amdgpu: Block MMR_READ IOCTL in reset", " - drm/amdgpu/gfx9: use rlc safe mode for soft recovery", " - drm/amdgpu/gfx11: enter safe mode before touching CP_INT_CNTL", " - drm/xe: Use topology to determine page fault queue size", " - drm/amdkfd: Check int source id for utcl2 poison event", " - of/irq: Refer to actual buffer size in of_irq_parse_one()", " - drm/amd/display: guard write a 0 post_divider value to HW", " - powerpc/pseries: Use correct data types from pseries_hp_errorlog struct", " - ovl: fsync after metadata copy-up", " - drm/amdgpu/gfx12: use rlc safe mode for soft recovery", " - drm/amdgpu/gfx11: use rlc safe mode for soft recovery", " - drm/amdgpu/gfx10: use rlc safe mode for soft recovery", " - platform/x86: lenovo-ymc: Ignore the 0x0 state", " - tools/hv: Add memory allocation check in hv_fcopy_start", " - HID: i2c-hid: ensure various commands do not interfere with each other", " - platform/mellanox: mlxbf-pmc: fix lockdep warning", " - platform/x86: x86-android-tablets: Adjust Xiaomi Pad 2 bottom bezel touch", " buttons LED", " - bpf: Make the pointer returned by iter next method valid", " - ext4: ext4_search_dir should return a proper error", " - bpftool: Fix undefined behavior caused by shifting into the sign bit", " - iomap: handle a post-direct I/O invalidate race in", " iomap_write_delalloc_release", " - EINJ, CXL: Fix CXL device SBDF calculation", " - spi: spi-imx: Fix pm_runtime_set_suspended() with runtime pm enabled", " - spi: spi-cadence: Fix pm_runtime_set_suspended() with runtime pm enabled", " - spi: spi-cadence: Fix missing spi_controller_is_target() check", " - selftest: hid: add missing run-hid-tools-tests.sh", " - spi: s3c64xx: fix timeout counters in flush_fifo", " - kselftest/devices/probe: Fix SyntaxWarning in regex strings for Python3", " - selftests: breakpoints: use remaining time to check if suspend succeed", " - accel/ivpu: Add missing MODULE_FIRMWARE metadata", " - spi: rpc-if: Add missing MODULE_DEVICE_TABLE", " - ALSA: control: Fix power_ref lock order for compat code, too", " - perf callchain: Fix stitch LBR memory leaks", " - perf: Really fix event_function_call() locking", " - drm/xe: fixup xe_alloc_pf_queue", " - drm/xe: Fix memory leak on xe_alloc_pf_queue failure", " - selftests: vDSO: fix vDSO name for powerpc", " - selftests: vDSO: fix vdso_config for powerpc", " - selftests: vDSO: fix vDSO symbols lookup for powerpc64", " - ext4: fix error message when rejecting the default hash", " - selftests/mm: fix charge_reserved_hugetlb.sh test", " - nvme-tcp: fix link failure for TCP auth", " - f2fs: add write priority option based on zone UFS", " - powerpc/vdso: Fix VDSO data access when running in a non-root time namespace", " - selftests: vDSO: fix ELF hash table entry size for s390x", " - selftests: vDSO: fix vdso_config for s390", " - f2fs: make BG GC more aggressive for zoned devices", " - f2fs: introduce migration_window_granularity", " - f2fs: increase BG GC migration window granularity when boosted for zoned", " devices", " - f2fs: do FG_GC when GC boosting is required for zoned devices", " - f2fs: forcibly migrate to secure space for zoned device file pinning", " - Revert \"ALSA: hda: Conditionally use snooping for AMD HDMI\"", " - KVM: arm64: Fix kvm_has_feat*() handling of negative features", " - i2c: qcom-geni: Use IRQF_NO_AUTOEN flag in request_irq()", " - i2c: xiic: Wait for TX empty to avoid missed TX NAKs", " - i2c: core: Lock address during client device instantiation", " - i2c: xiic: Fix pm_runtime_set_suspended() with runtime pm enabled", " - i2c: designware: fix controller is holding SCL low while ENABLE bit is", " disabled", " - i2c: synquacer: Deal with optional PCLK correctly", " - rust: sync: require `T: Sync` for `LockedBy::access`", " - ovl: fail if trusted xattrs are needed but caller lacks permission", " - firmware: tegra: bpmp: Drop unused mbox_client_to_bpmp()", " - memory: tegra186-emc: drop unused to_tegra186_emc()", " - dt-bindings: clock: exynos7885: Fix duplicated binding", " - spi: bcm63xx: Fix module autoloading", " - spi: bcm63xx: Fix missing pm_runtime_disable()", " - power: supply: hwmon: Fix missing temp1_max_alarm attribute", " - power: supply: Drop use_cnt check from power_supply_property_is_writeable()", " - perf/core: Fix small negative period being ignored", " - drm/v3d: Prevent out of bounds access in performance query extensions", " - parisc: Fix itlb miss handler for 64-bit programs", " - drm/mediatek: ovl_adaptor: Add missing of_node_put()", " - drm: Consistently use struct drm_mode_rect for FB_DAMAGE_CLIPS", " - ALSA: hda/tas2781: Add new quirk for Lenovo Y990 Laptop", " - ALSA: core: add isascii() check to card ID generator", " - ALSA: usb-audio: Add delay quirk for VIVO USB-C HEADSET", " - ALSA: usb-audio: Add native DSD support for Luxman D-08u", " - ALSA: line6: add hw monitor volume control to POD HD500X", " - ALSA: hda/realtek: fix mute/micmute LED for HP mt645 G8", " - ALSA: hda/realtek: Add quirk for Huawei MateBook 13 KLV-WX9", " - ALSA: hda/realtek: Add a quirk for HP Pavilion 15z-ec200", " - ext4: correct encrypted dentry name hash when not casefolded", " - ext4: propagate errors from ext4_find_extent() in ext4_insert_range()", " - ext4: fix incorrect tid assumption in ext4_fc_mark_ineligible()", " - ext4: fix incorrect tid assumption in __jbd2_log_wait_for_space()", " - ext4: fix incorrect tid assumption in ext4_wait_for_tail_page_commit()", " - ext4: fix incorrect tid assumption in jbd2_journal_shrink_checkpoint_list()", " - ext4: fix fast commit inode enqueueing during a full journal commit", " - ext4: use handle to mark fc as ineligible in __track_dentry_update()", " - ext4: mark fc as ineligible using an handle in ext4_xattr_set()", " - parisc: Fix 64-bit userspace syscall path", " - parisc: Allow mmap(MAP_STACK) memory to automatically expand upwards", " - parisc: Fix stack start for ADDR_NO_RANDOMIZE personality", " - drm/rockchip: vop: clear DMA stop bit on RK3066", " - of: address: Report error on resource bounds overflow", " - of/irq: Support #msi-cells=<0> in of_msi_get_domain", " - lib/buildid: harden build ID parsing logic", " - jbd2: correctly compare tids with tid_geq function in jbd2_fc_begin_commit", " - mm: krealloc: consider spare memory for __GFP_ZERO", " - ocfs2: fix the la space leak when unmounting an ocfs2 volume", " - ocfs2: fix uninit-value in ocfs2_get_block()", " - scripts/gdb: fix timerlist parsing issue", " - scripts/gdb: add iteration function for rbtree", " - scripts/gdb: fix lx-mounts command error", " - arm64: fix selection of HAVE_DYNAMIC_FTRACE_WITH_ARGS", " - arm64: Subscribe Microsoft Azure Cobalt 100 to erratum 3194386", " - drm/xe/oa: Don't reset OAC_CONTEXT_ENABLE on OA stream close", " - sched/deadline: Comment sched_dl_entity::dl_server variable", " - sched/core: Add clearing of ->dl_server in put_prev_task_balance()", " - sched/core: Clear prev->dl_server in CFS pick fast path", " - sched: psi: fix bogus pressure spikes from aggregation race", " - riscv: define ILLEGAL_POINTER_VALUE for 64bit", " - [Config] updateconfigs for ILLEGAL_POINTER_VALUE on riscv", " - perf python: Disable -Wno-cast-function-type-mismatch if present on clang", " - perf hist: Update hist symbol when updating maps", " - nfsd: fix delegation_blocked() to block correctly for at least 30 seconds", " - NFSD: Fix NFSv4's PUTPUBFH operation", " - sysctl: avoid spurious permanent empty tables", " - RDMA/mana_ib: use the correct page table index based on hardware page size", " - RDMA/mana_ib: use the correct page size for mapping user-mode doorbell page", " - drivers/perf: riscv: Align errno for unsupported perf event", " - riscv: Fix kernel stack size when KASAN is enabled", " - media: imx335: Fix reset-gpio handling", " - clk: rockchip: fix error for unknown clocks", " - leds: pca9532: Remove irrelevant blink configuration error message", " - media: videobuf2: Drop minimum allocation requirement of 2 buffers", " - clk: qcom: dispcc-sm8250: use CLK_SET_RATE_PARENT for branch clocks", " - media: sun4i_csi: Implement link validate for sun4i_csi subdev", " - clk: qcom: gcc-sm8450: Do not turn off PCIe GDSCs during gdsc_disable()", " - media: uapi/linux/cec.h: cec_msg_set_reply_to: zero flags", " - dt-bindings: clock: qcom: Add GPLL9 support on gcc-sc8180x", " - clk: qcom: gcc-sc8180x: Register QUPv3 RCGs for DFS on sc8180x", " - clk: qcom: clk-rpmh: Fix overflow in BCM vote", " - clk: samsung: exynos7885: Update CLKS_NR_FSYS after bindings fix", " - clk: qcom: gcc-sm8150: De-register gcc_cpuss_ahb_clk_src", " - clk: qcom: gcc-sm8250: Do not turn off PCIe GDSCs during gdsc_disable()", " - clk: qcom: gcc-sc8180x: Add GPLL9 support", " - clk: qcom: gcc-sc8180x: Fix the sdcc2 and sdcc4 clocks freq table", " - clk: qcom: clk-alpha-pll: Fix CAL_L_VAL override for LUCID EVO PLL", " - drm/amd/display: avoid set dispclk to 0", " - smb: client: use actual path when queryfs", " - smb3: fix incorrect mode displayed for read-only files", " - iio: magnetometer: ak8975: Fix reading for ak099xx sensors", " - iio: pressure: bmp280: Fix regmap for BMP280 device", " - iio: pressure: bmp280: Fix waiting time for BMP3xx configuration", " - tomoyo: fallback to realpath if symlink's pathname does not exist", " - kselftests: mm: fix wrong __NR_userfaultfd value", " - rtc: at91sam9: fix OF node leak in probe() error path", " - mm/hugetlb: fix memfd_pin_folios resv_huge_pages leak", " - mm/gup: fix memfd_pin_folios hugetlb page allocation", " - mm/hugetlb: simplify refs in memfd_alloc_folio", " - Input: adp5589-keys - fix adp5589_gpio_get_value()", " - HID: bpf: fix cfi stubs for hid_bpf_ops", " - pidfs: check for valid pid namespace", " - ACPI: video: Add backlight=native quirk for Dell OptiPlex 5480 AIO", " - ACPI: resource: Remove duplicate Asus E1504GAB IRQ override", " - ACPI: resource: Loosen the Asus E1404GAB DMI match to also cover the E1404GA", " - ACPI: resource: Add Asus Vivobook X1704VAP to irq1_level_low_skip_override[]", " - ACPI: resource: Add Asus ExpertBook B2502CVA to", " irq1_level_low_skip_override[]", " - btrfs: drop the backref cache during relocation if we commit", " - btrfs: send: fix invalid clone operation for file that got its size", " decreased", " - cpufreq: intel_pstate: Make hwp_notify_lock a raw spinlock", " - gpio: davinci: fix lazy disable", " - net: pcs: xpcs: fix the wrong register that was written back", " - Bluetooth: hci_event: Align BR/EDR JUST_WORKS paring with LE", " - io_uring/net: harden multishot termination case for recv", " - ceph: fix cap ref leak via netfs init_request", " - tracing/hwlat: Fix a race during cpuhp processing", " - tracing/timerlat: Fix duplicated kthread creation due to CPU online/offline", " - rtla: Fix the help text in osnoise and timerlat top tools", " - firmware/sysfb: Disable sysfb for firmware buffers with unknown parent", " - close_range(): fix the logics in descriptor table trimming", " - drm/i915/gem: fix bitwise and logical AND mixup", " - drm/panthor: Don't add write fences to the shared BOs", " - drm/panthor: Don't declare a queue blocked if deferred operations are", " pending", " - drm/sched: Fix dynamic job-flow control race", " - drm/sched: Add locking to drm_sched_entity_modify_sched", " - drm/sched: Always wake up correct scheduler in drm_sched_entity_push_job", " - drm/sched: Always increment correct scheduler score", " - drm/amd/display: Restore Optimized pbn Value if Failed to Disable DSC", " - drm/amd/display: Add HDR workaround for specific eDP", " - drm/amd/display: Enable idle workqueue for more IPS modes", " - kconfig: fix infinite loop in sym_calc_choice()", " - kconfig: qconf: move conf_read() before drawing tree pain", " - kconfig: qconf: fix buffer overflow in debug links", " - arm64: cputype: Add Neoverse-N3 definitions", " - arm64: errata: Expand speculative SSBS workaround once more", " - mm: z3fold: deprecate CONFIG_Z3FOLD", " - [Config] updateconfigs after deprecating Z3FOLD", " - drm/amd/display: Allow backlight to go below", " `AMDGPU_DM_DEFAULT_MIN_BACKLIGHT`", " - sunrpc: change sp_nrthreads from atomic_t to unsigned int.", " - NFSD: Async COPY result needs to return a write verifier", " - remoteproc: k3-r5: Acquire mailbox handle during probe routine", " - remoteproc: k3-r5: Delay notification of wakeup event", " - r8169: Fix spelling mistake: \"tx_underun\" -> \"tx_underrun\"", " - ACPI: battery: Simplify battery hook locking", " - drm/xe: Clean up VM / exec queue file lock usage.", " - drm/rockchip: vop: enable VOP_FEATURE_INTERNAL_RGB on RK3066", " - drm/xe/vram: fix ccs offset calculation", " - drm/sched: revert \"Always increment correct scheduler score\"", " - ALSA: control: Fix leftover snd_power_unref()", " - crypto: octeontx* - Select CRYPTO_AUTHENC", " - drm/amd/display: Revert Avoid overflow assignment", " - perf report: Fix segfault when 'sym' sort key is not used", " - pmdomain: core: Reduce debug summary table width", " - perf python: Allow checking for the existence of warning options in clang", " - Linux 6.11.3", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49863", " - vhost/scsi: null-ptr-dereference in vhost_scsi_get_req()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49864", " - rxrpc: Fix a race between socket set up and I/O thread creation", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49865", " - drm/xe/vm: move xa_alloc to prevent UAF", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49955", " - ACPI: battery: Fix possible crash when unregistering a battery hook", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49973", " - r8169: add tally counter fields added with RTL8125", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49974", " - NFSD: Limit the number of concurrent async COPY operations", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49975", " - uprobes: fix kernel info leak via \"[uprobes]\" vma", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50003", " - drm/amd/display: Fix system hang while resume with TBT monitor", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50173", " - drm/panthor: Fix access to uninitialized variable in tick_ctx_cleanup()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49866", " - tracing/timerlat: Fix a race during cpuhp processing", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49976", " - tracing/timerlat: Drop interface_lock in stop_kthread()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50005", " - mac802154: Fix potential RCU dereference issue in mac802154_scan_worker", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50012", " - cpufreq: Avoid a bad reference count on CPU node", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49867", " - btrfs: wait for fixup workers before stopping cleaner kthread during umount", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49868", " - btrfs: fix a NULL pointer dereference when failed to start a new trasacntion", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49869", " - btrfs: send: fix buffer overflow detection when copying path to cache entry", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49870", " - cachefiles: fix dentry leak in cachefiles_open_file()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49871", " - Input: adp5589-keys - fix NULL pointer dereference", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49872", " - mm/gup: fix memfd_pin_folios alloc race panic", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49964", " - mm/hugetlb: fix memfd_pin_folios free_huge_pages leak", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49873", " - mm/filemap: fix filemap_get_folios_contig THP panic", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49977", " - net: stmmac: Fix zero-division error when disabling tc cbs", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49978", " - gso: fix udp gso fraglist segmentation after pull from frag_list", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49979", " - net: gso: fix tcp fraglist segmentation after pull from frag_list", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49980", " - vrf: revert \"vrf: Remove unnecessary RCU-bh critical section\"", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49981", " - media: venus: fix use after free bug in venus_remove due to race condition", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49956", " - gfs2: fix double destroy_workqueue error", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50176", " - remoteproc: k3-r5: Fix error handling when power-up failed", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49982", " - aoe: fix the potential use-after-free problem in more places", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49874", " - i3c: master: svc: Fix use after free vulnerability in svc_i3c_master Driver", " Due to Race Condition", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49875", " - nfsd: map the EBADMSG to nfserr_io to avoid warning", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50013", " - exfat: fix memory leak in exfat_load_bitmap()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49876", " - drm/xe: fix UAF around queue destruction", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49877", " - ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49957", " - ocfs2: fix null-ptr-deref when journal load failed.", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49965", " - ocfs2: remove unreasonable unlock in ocfs2_read_blocks", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49966", " - ocfs2: cancel dqi_sync_work before freeing oinfo", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49958", " - ocfs2: reserve space for inline xattr before attaching reflink tree", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49959", " - jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49878", " - resource: fix region_intersects() vs add_memory_driver_managed()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49879", " - drm: omapdrm: Add missing check for alloc_ordered_workqueue", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49880", " - ext4: fix off by one issue in alloc_flex_gd()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49881", " - ext4: update orig_path in ext4_find_extent()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50014", " - ext4: fix access to uninitialised lock in fc replay path", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49960", " - ext4: fix timer use-after-free on failed mount", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49882", " - ext4: fix double brelse() the buffer of the extents path", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49883", " - ext4: aovid use-after-free in ext4_ext_insert_extent()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49983", " - ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-free", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50015", " - ext4: dax: fix overflowing extents beyond inode size when partially writing", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49884", " - ext4: fix slab-use-after-free in ext4_split_extent_at()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49885", " - mm, slub: avoid zeroing kmalloc redzone", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49961", " - media: i2c: ar0521: Use cansleep version of gpiod_set_value()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49985", " - i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49886", " - platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bug", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49986", " - platform/x86: x86-android-tablets: Fix use after free on", " platform_device_register() errors", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49887", " - f2fs: fix to don't panic system for no free segment fault injection", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49888", " - bpf: Fix a sdiv overflow issue", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49987", " - bpftool: Fix undefined behavior in qsort(NULL, 0, ...)", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50006", " - ext4: fix i_data_sem unlock order in ext4_ind_migrate()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49889", " - ext4: avoid use-after-free in ext4_ext_show_leaf()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49968", " - ext4: filesystems without casefold feature cannot be mounted with siphash", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49988", " - ksmbd: add refcnt to ksmbd_conn struct", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49890", " - drm/amd/pm: ensure the fw_info is not null before using it", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49891", " - scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata", " paths", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49892", " - drm/amd/display: Initialize get_bytes_per_element's default to 1", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50016", " - drm/amd/display: Avoid overflow assignment in link_dp_cts", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49893", " - drm/amd/display: Check stream_status before it is used", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49969", " - drm/amd/display: Fix index out of bounds in DCN30 color transformation", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49970", " - drm/amd/display: Implement bounds check for stream encoder creation in", " DCN401", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49894", " - drm/amd/display: Fix index out of bounds in degamma hardware format", " translation", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49895", " - drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format", " translation", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49971", " - drm/amd/display: Increase array size of dummy_boolean", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49972", " - drm/amd/display: Deallocate DML memory if allocation fails", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49896", " - drm/amd/display: Check stream before comparing them", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49897", " - drm/amd/display: Check phantom_stream before it is used", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49898", " - drm/amd/display: Check null-initialized variables", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49899", " - drm/amd/display: Initialize denominators' default to 1", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49900", " - jfs: Fix uninit-value access of new_ea in ea_buffer", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49901", " - drm/msm/adreno: Assign msm_gpu->pdev earlier to avoid nullptrs", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49902", " - jfs: check if leafidx greater than num leaves per dmap tree", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49903", " - jfs: Fix uaf in dbFreeBits", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49904", " - drm/amdgpu: add list empty check to avoid null pointer issue", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49989", " - drm/amd/display: fix double free issue during amdgpu module unload", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49905", " - drm/amd/display: Add null check for 'afb' in", " amdgpu_dm_plane_handle_cursor_update (v2)", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49906", " - drm/amd/display: Check null pointer before try to access it", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49907", " - drm/amd/display: Check null pointers before using dc->clk_mgr", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49908", " - drm/amd/display: Add null check for 'afb' in amdgpu_dm_update_cursor (v2)", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50177", " - drm/amd/display: fix a UBSAN warning in DML2.1", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49909", " - drm/amd/display: Add NULL check for function pointer in", " dcn32_set_output_transfer_func", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49910", " - drm/amd/display: Add NULL check for function pointer in", " dcn401_set_output_transfer_func", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49911", " - drm/amd/display: Add NULL check for function pointer in", " dcn20_set_output_transfer_func", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49912", " - drm/amd/display: Handle null 'stream_status' in", " 'planes_changed_for_existing_stream'", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49913", " - drm/amd/display: Add null check for top_pipe_to_program in", " commit_planes_for_stream", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49914", " - drm/amd/display: Add null check for pipe_ctx->plane_state in", " dcn20_program_pipe", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49915", " - drm/amd/display: Add NULL check for clk_mgr in dcn32_init_hw", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49916", " - drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in", " dcn401_init_hw", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49917", " - drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in", " dcn30_init_hw", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49918", " - drm/amd/display: Add null check for head_pipe in", " dcn32_acquire_idle_pipe_for_head_pipe_in_layer", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49919", " - drm/amd/display: Add null check for head_pipe in", " dcn201_acquire_free_pipe_for_layer", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49991", " - drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49920", " - drm/amd/display: Check null pointers before multiple uses", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49921", " - drm/amd/display: Check null pointers before used", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49922", " - drm/amd/display: Check null pointers before using them", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49923", " - drm/amd/display: Pass non-null to dcn20_validate_apply_pipe_split_flags", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49992", " - drm/stm: Avoid use-after-free issues with crtc and plane", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49993", " - iommu/vt-d: Fix potential lockup if qi_submit_sync called with 0 count", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49924", " - fbdev: pxafb: Fix possible use after free in pxafb_task()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49925", " - fbdev: efifb: Register sysfs groups through driver core", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49926", " - rcu-tasks: Fix access non-existent percpu rtpcp variable in", " rcu_tasks_need_gpcb()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50007", " - ALSA: asihpi: Fix potential OOB array access", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50017", " - x86/mm/ident_map: Use gbpages only where full GB page should be mapped.", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49927", " - x86/ioapic: Handle allocation failures gracefully", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50008", " - wifi: mwifiex: Fix memcpy() field-spanning write warning in", " mwifiex_cmd_802_11_scan_ext()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50018", " - net: napi: Prevent overflow of napi_defer_hard_irqs", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49928", " - wifi: rtw89: avoid reading out of bounds when loading TX power FW elements", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50178", " - cpufreq: loongson3: Use raw_smp_processor_id() in do_service_request()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50009", " - cpufreq: amd-pstate: add check for cpufreq_cpu_get's return value", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49994", " - block: fix integer overflow in BLKSECDISCARD", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49929", " - wifi: iwlwifi: mvm: avoid NULL pointer dereference", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49995", " - tipc: guard against string buffer overrun", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49962", " - ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in", " acpi_db_convert_to_package()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49930", " - wifi: ath11k: fix array out-of-bound access in SoC stats", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49931", " - wifi: ath12k: fix array out-of-bound access in SoC stats", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49932", " - btrfs: don't readahead the relocation inode on RST", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49933", " - blk_iocost: fix more out of bound shifts", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49934", " - fs/inode: Prevent dump_mapping() accessing invalid dentry.d_name.name", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50010", " - exec: don't WARN for racy path_noexec check", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49935", " - ACPI: PAD: fix crash in exit_round_robin()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49936", " - net/xen-netback: prevent UAF in xenvif_flush_hash()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49937", " - wifi: cfg80211: Set correct chandef when starting CAC", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49938", " - wifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmit", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49939", " - wifi: rtw89: avoid to add interface to list twice when SER", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49940", " - l2tp: prevent possible tunnel refcount underflow", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49941", " - gpiolib: Fix potential NULL pointer dereference in gpiod_get_label()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49996", " - cifs: Fix buffer overflow when parsing NFS reparse points", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49942", " - drm/xe: Prevent null pointer access in xe_migrate_copy", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49943", " - drm/xe/guc_submit: add missing locking in wedged_fini", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50011", " - ASoC: Intel: soc-acpi-intel-rpl-match: add missing empty item", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50174", " - drm/panthor: Fix race when converting group handle to group object", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49944", " - sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_start", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49945", " - net/ncsi: Disable the ncsi work before freeing the associated structure", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49946", " - ppp: do not assume bh is held in ppp_channel_bridge_input()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49947", " - net: test for not too small csum_start in virtio_net_hdr_to_skb()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49948", " - net: add more sanity checks to qdisc_pkt_len_init()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49949", " - net: avoid potential underflow in qdisc_pkt_len_init() with UFO", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49997", " - net: ethernet: lantiq_etop: fix memory disclosure", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49998", " - net: dsa: improve shutdown sequence", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49999", " - afs: Fix the setting of the server responding flag", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49950", " - Bluetooth: L2CAP: Fix uaf in l2cap_connect", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49951", " - Bluetooth: MGMT: Fix possible crash on mgmt_index_removed", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49952", " - netfilter: nf_tables: prevent nf_skb_duplicated corruption", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49953", " - net/mlx5e: Fix crash caused by calling __xfrm_state_delete() twice", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50000", " - net/mlx5e: Fix NULL deref in mlx5e_tir_builder_alloc()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50001", " - net/mlx5: Fix error path in multi-packet WQE transmit", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50179", " - ceph: remove the incorrect Fw reference check when dirtying pages", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49963", " - mailbox: bcm2835: Fix timeout during suspend mode", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49954", " - static_call: Replace pointless WARN_ON() in static_call_module_notify()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50002", " - static_call: Handle module init failure correctly in", " static_call_del_module()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033)", " - EDAC/synopsys: Fix error injection on Zynq UltraScale+", " - crypto: xor - fix template benchmarking", " - crypto: qat - disable IOV in adf_dev_stop()", " - crypto: qat - fix recovery flow for VFs", " - crypto: qat - ensure correct order in VF restarting handler", " - ACPI: PMIC: Remove unneeded check in tps68470_pmic_opregion_probe()", " - eth: fbnic: select DEVLINK and PAGE_POOL", " - wifi: brcmfmac: introducing fwil query functions", " - wifi: ath9k: Remove error checks when creating debugfs entries", " - wifi: ath12k: fix BSS chan info request WMI command", " - wifi: ath12k: match WMI BSS chan info structure with firmware definition", " - wifi: ath12k: fix invalid AMPDU factor calculation in", " ath12k_peer_assoc_h_he()", " - hwrng: cn10k - Enable by default CN10K driver if Thunder SoC is enabled", " - crypto: x86/aes-gcm - fix PREEMPT_RT issue in gcm_crypt()", " - net: stmmac: dwmac-loongson: Init ref and PTP clocks rate", " - virtio: rename virtio_config_enabled to virtio_config_core_enabled", " - virtio: allow driver to disable the configure change notification", " - virtio-net: synchronize operstate with admin state on up/down", " - virtio-net: synchronize probe with ndo_set_features", " - arm64: signal: Fix some under-bracketed UAPI macros", " - wifi: rtw88: remove CPT execution branch never used", " - RISC-V: KVM: Fix sbiret init before forwarding to userspace", " - RISC-V: KVM: Allow legacy PMU access from guest", " - RISC-V: KVM: Fix to allow hpmcounter31 from the guest", " - mount: handle OOM on mnt_warn_timestamp_expiry", " - autofs: fix missing fput for FSCONFIG_SET_FD", " - netfilter: nf_tables: store new sets in dedicated list", " - wifi: rtw89: limit the PPDU length for VHT rate to 0x40000", " - kselftest/arm64: signal: fix/refactor SVE vector length enumeration", " - arm64: smp: smp_send_stop() and crash_smp_send_stop() should try non-NMI", " first", " - thermal: core: Fold two functions into their respective callers", " - thermal: core: Fix rounding of delay jiffies", " - perf/dwc_pcie: Fix registration issue in multi PCIe controller instances", " - perf/dwc_pcie: Always register for PCIe bus notifier", " - crypto: qat - fix \"Full Going True\" macro definition", " - ACPI: video: force native for Apple MacbookPro9,2", " - wifi: mac80211_hwsim: correct MODULE_PARM_DESC of multi_radio", " - wifi: iwlwifi: config: label 'gl' devices as discrete", " - wifi: iwlwifi: mvm: increase the time between ranging measurements", " - wifi: cfg80211: fix bug of mapping AF3x to incorrect User Priority", " - wifi: mac80211: fix the comeback long retry times", " - wifi: iwlwifi: mvm: allow ESR when we the ROC expires", " - wifi: mac80211: Check for missing VHT elements only for 5 GHz", " - ACPICA: Implement ACPI_WARNING_ONCE and ACPI_ERROR_ONCE", " - ACPICA: executer/exsystem: Don't nag user about every Stall() violating the", " spec", " - padata: Honor the caller's alignment in case of chunk_size 0", " - drivers/perf: hisi_pcie: Record hardware counts correctly", " - drivers/perf: hisi_pcie: Fix TLP headers bandwidth counting", " - kselftest/arm64: Actually test SME vector length changes via sigreturn", " - can: j1939: use correct function name in comment", " - wifi: rtw89: wow: fix wait condition for AOAC report request", " - ACPI: CPPC: Fix MASK_VAL() usage", " - netfilter: nf_tables: elements with timeout below CONFIG_HZ never expire", " - netfilter: nf_tables: reject element expiration with no timeout", " - netfilter: nf_tables: reject expiration higher than timeout", " - netfilter: nf_tables: remove annotation to access set timeout while holding", " lock", " - netfilter: nft_dynset: annotate data-races around set timeout", " - perf/arm-cmn: Refactor node ID handling. Again.", " - perf/arm-cmn: Fix CCLA register offset", " - perf/arm-cmn: Ensure dtm_idx is big enough", " - cpufreq: ti-cpufreq: Introduce quirks to handle syscon fails appropriately", " - thermal: gov_bang_bang: Adjust states of all uninitialized instances", " - wifi: mt76: mt7921: fix wrong UNII-4 freq range check for the channel usage", " - wifi: mt76: mt7996: fix traffic delay when switching back to working channel", " - wifi: mt76: mt7996: fix wmm set of station interface to 3", " - wifi: mt76: mt7996: fix HE and EHT beamforming capabilities", " - wifi: mt76: mt7996: fix EHT beamforming capability check", " - pm:cpupower: Add missing powercap_set_enabled() stub function", " - crypto: ccp - do not request interrupt on cmd completion when irqs disabled", " - crypto: hisilicon/hpre - mask cluster timeout error", " - crypto: hisilicon/qm - reset device before enabling it", " - wifi: mt76: mt7996: fix handling mbss enable/disable", " - wifi: mt76: connac: fix checksum offload fields of connac3 RXD", " - wifi: mt76: mt7603: fix mixed declarations and code", " - wifi: cfg80211: fix UBSAN noise in cfg80211_wext_siwscan()", " - wifi: mt76: mt7915: fix rx filter setting for bfee functionality", " - wifi: mt76: mt7996: fix uninitialized TLV data", " - wifi: cfg80211: fix two more possible UBSAN-detected off-by-one errors", " - af_unix: Don't call skb_get() for OOB skb.", " - af_unix: Remove single nest in manage_oob().", " - af_unix: Rename unlinked_skb in manage_oob().", " - af_unix: Move spin_lock() in manage_oob().", " - Bluetooth: hci_core: Fix sending MGMT_EV_CONNECT_FAILED", " - Bluetooth: hci_sync: Ignore errors from HCI_OP_REMOTE_NAME_REQ_CANCEL", " - can: m_can: enable NAPI before enabling interrupts", " - can: m_can: m_can_close(): stop clocks after device has been shut down", " - Bluetooth: btusb: Fix not handling ZPL/short-transfer", " - bareudp: Pull inner IP header in bareudp_udp_encap_recv().", " - bareudp: Pull inner IP header on xmit.", " - net: enetc: Use IRQF_NO_AUTOEN flag in request_irq()", " - crypto: n2 - Set err to EINVAL if snprintf fails for hmac", " - xsk: fix batch alloc API on non-coherent systems", " - net: ipv6: rpl_iptunnel: Fix memory leak in rpl_input", " - fbnic: Set napi irq value after calling netif_napi_add", " - net: tipc: avoid possible garbage value", " - ublk: move zone report data out of request pdu", " - block, bfq: choose the last bfqq from merge chain in bfq_setup_cooperator()", " - block, bfq: don't break merge chain in bfq_split_bfqq()", " - cachefiles: Fix non-taking of sb_writers around set/removexattr", " - nbd: correct the maximum value for discard sectors", " - erofs: fix incorrect symlink detection in fast symlink", " - erofs: fix error handling in z_erofs_init_decompressor", " - block, bfq: fix uaf for accessing waker_bfqq after splitting", " - block, bfq: fix procress reference leakage for bfqq in merge chain", " - io_uring/io-wq: do not allow pinning outside of cpuset", " - io_uring/io-wq: inherit cpuset of cgroup in io worker", " - spi: ppc4xx: handle irq_of_parse_and_map() errors", " - arm64: dts: exynos: exynos7885-jackpotlte: Correct RAM amount to 4GB", " - arm64: dts: mediatek: mt8186: Fix supported-hw mask for GPU OPPs", " - spi: ppc4xx: Avoid returning 0 when failed to parse and map IRQ", " - firmware: qcom: scm: Disable SDI and write no dump to dump mode", " - regulator: Return actual error in of_regulator_bulk_get_all()", " - arm64: dts: renesas: r9a08g045: Correct GICD and GICR sizes", " - arm64: dts: renesas: r9a07g043u: Correct GICD and GICR sizes", " - arm64: dts: renesas: r9a07g054: Correct GICD and GICR sizes", " - arm64: dts: renesas: r9a07g044: Correct GICD and GICR sizes", " - ARM: dts: microchip: sam9x60: Fix rtc/rtt clocks", " - arm64: tegra: Correct location of power-sensors for IGX Orin", " - arm64: dts: rockchip: Correct vendor prefix for Hardkernel ODROID-M1", " - arm64: dts: ti: k3-j721e-sk: Fix reversed C6x carveout locations", " - arm64: dts: ti: k3-j721e-beagleboneai64: Fix reversed C6x carveout locations", " - spi: bcmbca-hsspi: Fix missing pm_runtime_disable()", " - arm64: dts: qcom: x1e80100: Fix PHY for DP2", " - ARM: dts: microchip: sama7g5: Fix RTT clock", " - ARM: dts: imx7d-zii-rmu2: fix Ethernet PHY pinctrl property", " - arm64: dts: ti: k3-am654-idk: Fix dtbs_check warning in ICSSG dmas", " - ARM: versatile: fix OF node leak in CPUs prepare", " - reset: berlin: fix OF node leak in probe() error path", " - reset: k210: fix OF node leak in probe() error path", " - platform: cznic: turris-omnia-mcu: Fix error check in", " omnia_mcu_register_trng()", " - clocksource/drivers/qcom: Add missing iounmap() on errors in", " msm_dt_timer_init()", " - arm64: dts: mediatek: mt8195: Correct clock order for dp_intf*", " - x86/mm: Use IPIs to synchronize LAM enablement", " - ASoC: rt5682s: Return devm_of_clk_add_hw_provider to transfer the error", " - ASoC: tas2781: Fix a compiling warning reported by robot kernel test due to", " adding tas2563_dvc_table", " - ASoC: tas2781-i2c: Drop weird GPIO code", " - ASoC: tas2781-i2c: Get the right GPIO line", " - selftests/ftrace: Add required dependency for kprobe tests", " - ALSA: hda: cs35l41: fix module autoloading", " - selftests/ftrace: Fix test to handle both old and new kernels", " - x86/boot/64: Strip percpu address space when setting up GDT descriptors", " - m68k: Fix kernel_clone_args.flags in m68k_clone()", " - ASoC: loongson: fix error release", " - selftests/ftrace: Fix eventfs ownership testcase to find mount point", " - selftests:resctrl: Fix build failure on archs without __cpuid_count()", " - cgroup/pids: Avoid spurious event notification", " - hwmon: (max16065) Fix overflows seen when writing limits", " - hwmon: (max16065) Fix alarm attributes", " - iommu/arm-smmu: Un-demote unhandled-fault msg", " - iommu/arm-smmu-v3: Fix a NULL vs IS_ERR() check", " - mtd: slram: insert break after errors in parsing the map", " - hwmon: (ntc_thermistor) fix module autoloading", " - power: supply: axp20x_battery: Remove design from min and max voltage", " - power: supply: max17042_battery: Fix SOC threshold calc w/ no current sense", " - fbdev: hpfb: Fix an error handling path in hpfb_dio_probe()", " - iommu/amd: Handle error path in amd_iommu_probe_device()", " - iommu/amd: Allocate the page table root using GFP_KERNEL", " - iommu/amd: Move allocation of the top table into v1_alloc_pgtable", " - iommu/amd: Set the pgsize_bitmap correctly", " - iommu/amd: Do not set the D bit on AMD v2 table entries", " - mtd: powernv: Add check devm_kasprintf() returned value", " - rcu/nocb: Fix RT throttling hrtimer armed from offline CPU", " - mtd: rawnand: mtk: Use for_each_child_of_node_scoped()", " - mtd: rawnand: mtk: Factorize out the logic cleaning mtk chips", " - mtd: rawnand: mtk: Fix init error path", " - iommu/arm-smmu-qcom: hide last LPASS SMMU context bank from linux", " - iommu/arm-smmu-qcom: Work around SDM845 Adreno SMMU w/ 16K pages", " - iommu/arm-smmu-qcom: apply num_context_bank fixes for SDM630 / SDM660", " - pmdomain: core: Harden inter-column space in debug summary", " - pmdomain: core: Fix \"managed by\" alignment in debug summary", " - drm/stm: Fix an error handling path in stm_drm_platform_probe()", " - drm/stm: ltdc: check memory returned by devm_kzalloc()", " - drm/amd/display: free bo used for dmub bounding box", " - drm/amdgpu: properly handle vbios fake edid sizing", " - drm/radeon: properly handle vbios fake edid sizing", " - drm/amd/display: Reset VRR config during resume", " - scsi: smartpqi: revert propagate-the-multipath-failure-to-SML-quickly", " - scsi: sd: Don't check if a write for REQ_ATOMIC", " - scsi: block: Don't check REQ_ATOMIC for reads", " - scsi: NCR5380: Check for phase match during PDMA fixup", " - drm/amd/amdgpu: Properly tune the size of struct", " - drm/amd/display: Improve FAM control for DCN401", " - drm/rockchip: vop: Allow 4096px width scaling", " - drm/rockchip: dw_hdmi: Fix reading EDID when using a forced mode", " - drm/radeon/evergreen_cs: fix int overflow errors in cs track offsets", " - drm/bridge: lontium-lt8912b: Validate mode in drm_bridge_funcs::mode_valid()", " - drm/vc4: hdmi: Handle error case of pm_runtime_resume_and_get", " - drm/mediatek: Fix missing configuration flags in mtk_crtc_ddp_config()", " - drm/mediatek: Use spin_lock_irqsave() for CRTC event lock", " - powerpc/8xx: Fix initial memory mapping", " - powerpc/8xx: Fix kernel vs user address comparison", " - powerpc/vdso: Inconditionally use CFUNC macro", " - drm/msm: Use a7xx family directly in gpu_state", " - drm/msm: Dump correct dbgahb clusters on a750", " - drm/msm: Fix CP_BV_DRAW_STATE_ADDR name", " - drm/msm: Fix incorrect file name output in adreno_request_fw()", " - drm/msm/a5xx: disable preemption in submits by default", " - drm/msm/a5xx: properly clear preemption records on resume", " - drm/msm/a5xx: fix races in preemption evaluation stage", " - drm/msm/a5xx: workaround early ring-buffer emptiness check", " - ipmi: docs: don't advertise deprecated sysfs entries", " - drm/msm/dp: enable widebus on all relevant chipsets", " - drm/msm/dsi: correct programming sequence for SM8350 / SM8450", " - drm/msm: fix %s null argument error", " - platform/x86: ideapad-laptop: Make the scope_guard() clear of its scope", " - kselftest: dt: Ignore nodes that have ancestors disabled", " - drivers:drm:exynos_drm_gsc:Fix wrong assignment in gsc_bind()", " - drm/amdgpu: fix invalid fence handling in amdgpu_vm_tlb_flush", " - xen: use correct end address of kernel for conflict checking", " - HID: wacom: Support sequence numbers smaller than 16-bit", " - HID: wacom: Do not warn about dropped packets for first packet", " - ata: libata: Clear DID_TIME_OUT for ATA PT commands with sense data", " - xen: introduce generic helper checking for memory map conflicts", " - xen: move max_pfn in xen_memory_setup() out of function scope", " - xen: add capability to remap non-RAM pages to different PFNs", " - xen: tolerate ACPI NVS memory overlapping with Xen allocated memory", " - drm/xe: fix missing 'xe_vm_put'", " - xen/swiotlb: add alignment check for dma buffers", " - xen/swiotlb: fix allocated size", " - sched/fair: Make SCHED_IDLE entity be preempted in strict hierarchy", " - bpf, x64: Fix tailcall hierarchy", " - bpf, arm64: Fix tailcall hierarchy", " - bpf: Fix compare error in function retval_range_within", " - selftests/bpf: Workaround strict bpf_lsm return value check.", " - selftests/bpf: Fix error linking uprobe_multi on mips", " - selftests/bpf: Fix wrong binary in Makefile log output", " - tools/runqslower: Fix LDFLAGS and add LDLIBS support", " - selftests/bpf: Use pid_t consistently in test_progs.c", " - selftests/bpf: Fix compile error from rlim_t in sk_storage_map.c", " - selftests/bpf: Fix error compiling bpf_iter_setsockopt.c with musl libc", " - selftests/bpf: Drop unneeded error.h includes", " - selftests/bpf: Fix missing ARRAY_SIZE() definition in bench.c", " - selftests/bpf: Fix missing UINT_MAX definitions in benchmarks", " - selftests/bpf: Fix missing BUILD_BUG_ON() declaration", " - selftests/bpf: Fix include of ", " - selftests/bpf: Fix compiling parse_tcp_hdr_opt.c with musl-libc", " - selftests/bpf: Fix compiling kfree_skb.c with musl-libc", " - selftests/bpf: Fix compiling flow_dissector.c with musl-libc", " - selftests/bpf: Fix compiling tcp_rtt.c with musl-libc", " - selftests/bpf: Fix compiling core_reloc.c with musl-libc", " - selftests/bpf: Fix errors compiling lwt_redirect.c with musl libc", " - selftests/bpf: Fix errors compiling decap_sanity.c with musl libc", " - selftests/bpf: Fix errors compiling crypto_sanity.c with musl libc", " - selftests/bpf: Fix errors compiling cg_storage_multi.h with musl libc", " - libbpf: Don't take direct pointers into BTF data from st_ops", " - selftests/bpf: Fix arg parsing in veristat, test_progs", " - selftests/bpf: Fix error compiling test_lru_map.c", " - selftests/bpf: Fix C++ compile error from missing _Bool type", " - selftests/bpf: Fix redefinition errors compiling lwt_reroute.c", " - selftests/bpf: Fix compile if backtrace support missing in libc", " - selftests/bpf: Fix error compiling tc_redirect.c with musl libc", " - s390/entry: Move early program check handler to entry.S", " - s390/entry: Make early program check handler relocated lowcore aware", " - libbpf: Fix license for btf_relocate.c", " - samples/bpf: Fix compilation errors with cf-protection option", " - selftests/bpf: no need to track next_match_pos in struct test_loader", " - selftests/bpf: extract test_loader->expect_msgs as a data structure", " - selftests/bpf: allow checking xlated programs in verifier_* tests", " - selftests/bpf: __arch_* macro to limit test cases to specific archs", " - selftests/bpf: fix to avoid __msg tag de-duplication by clang", " - selftests/bpf: Fix incorrect parameters in NULL pointer checking", " - libbpf: Fix bpf_object__open_skeleton()'s mishandling of options", " - s390/ap: Fix deadlock caused by recursive lock of the AP bus scan mutex", " - libbpf: Ensure new BTF objects inherit input endianness", " - xz: cleanup CRC32 edits from 2018", " - kthread: fix task state in kthread worker if being frozen", " - ext4: clear EXT4_GROUP_INFO_WAS_TRIMMED_BIT even mount with discard", " - bpftool: Fix handling enum64 in btf dump sorting", " - sched/deadline: Fix schedstats vs deadline servers", " - smackfs: Use rcu_assign_pointer() to ensure safe assignment in smk_set_cipso", " - ext4: avoid buffer_head leak in ext4_mark_inode_used()", " - ext4: avoid potential buffer_head leak in __ext4_new_inode()", " - ext4: avoid negative min_clusters in find_group_orlov()", " - ext4: return error on ext4_find_inline_entry", " - sched/numa: Fix the vma scan starving issue", " - nilfs2: determine empty node blocks as corrupted", " - sched/pelt: Use rq_clock_task() for hw_pressure", " - bpf: Fix bpf_strtol and bpf_strtoul helpers for 32bit", " - bpf: Improve check_raw_mode_ok test for MEM_UNINIT-tagged types", " - perf scripts python cs-etm: Restore first sample log in verbose mode", " - perf bpf: Move BPF disassembly routines to separate file to avoid clash with", " capstone bpf headers", " - perf mem: Free the allocated sort string, fixing a leak", " - perf lock contention: Change stack_id type to s32", " - perf vendor events: SKX, CLX, SNR uncore cache event fixes", " - perf inject: Fix leader sampling inserting additional samples", " - perf report: Fix --total-cycles --stdio output error", " - perf build: Fix up broken capstone feature detection fast path", " - perf sched timehist: Fix missing free of session in perf_sched__timehist()", " - perf stat: Display iostat headers correctly", " - perf dwarf-aux: Check allowed location expressions when collecting variables", " - perf annotate-data: Fix off-by-one in location range check", " - perf dwarf-aux: Handle bitfield members from pointer access", " - perf hist: Don't set hpp_fmt_value for members in --no-group", " - perf sched timehist: Fixed timestamp error when unable to confirm event", " sched_in time", " - perf time-utils: Fix 32-bit nsec parsing", " - perf mem: Check mem_events for all eligible PMUs", " - perf mem: Fix missed p-core mem events on ADL and RPL", " - clk: imx: clk-audiomix: Correct parent clock for earc_phy and audpll", " - clk: imx: imx6ul: fix default parent for enet*_ref_sel", " - clk: imx: composite-8m: Enable gate clk with mcore_booted", " - clk: imx: composite-93: keep root clock on when mcore enabled", " - clk: imx: composite-7ulp: Check the PCC present bit", " - clk: imx: fracn-gppll: fix fractional part of PLL getting lost", " - clk: imx: imx8mp: fix clock tree update of TF-A managed clocks", " - clk: imx: imx8qxp: Register dc0_bypass0_clk before disp clk", " - clk: imx: imx8qxp: Parent should be initialized earlier than the clock", " - quota: avoid missing put_quota_format when DQUOT_SUSPENDED is passed", " - remoteproc: imx_rproc: Correct ddr alias for i.MX8M", " - remoteproc: imx_rproc: Initialize workqueue earlier", " - clk: rockchip: Set parent rate for DCLK_VOP clock on RK3228", " - clk: qcom: dispcc-sm8550: fix several supposed typos", " - clk: qcom: dispcc-sm8550: use rcg2_ops for mdss_dptx1_aux_clk_src", " - clk: qcom: dispcc-sm8650: Update the GDSC flags", " - clk: qcom: dispcc-sm8550: use rcg2_shared_ops for ESC RCGs", " - leds: bd2606mvv: Fix device child node usage in bd2606mvv_probe()", " - pinctrl: renesas: rzg2l: Return -EINVAL if the pin doesn't support", " PIN_CFG_OEN", " - pinctrl: ti: ti-iodelay: Fix some error handling paths", " - phy: phy-rockchip-samsung-hdptx: Explicitly include pm_runtime.h", " - Input: ilitek_ts_i2c - avoid wrong input subsystem sync", " - Input: ilitek_ts_i2c - add report id message validation", " - media: raspberrypi: VIDEO_RASPBERRYPI_PISP_BE should depend on ARCH_BCM2835", " - [Config] updateconfigs for VIDEO_RASPBERRYPI_PISP_BE", " - PCI: Wait for Link before restoring Downstream Buses", " - firewire: core: correct range of block for case of switch statement", " - media: staging: media: starfive: camss: Drop obsolete return value", " documentation", " - clk: qcom: ipq5332: Register gcc_qdss_tsctr_clk_src", " - clk: qcom: dispcc-sm8250: use special function for Lucid 5LPE PLL", " - leds: pca995x: Use device_for_each_child_node() to access device child nodes", " - leds: pca995x: Fix device child node usage in pca995x_probe()", " - x86/PCI: Check pcie_find_root_port() return for NULL", " - PCI: xilinx-nwl: Fix register misspelling", " - PCI: xilinx-nwl: Clean up clock on probe failure/removal", " - leds: gpio: Set num_leds after allocation", " - media: platform: rzg2l-cru: rzg2l-csi2: Add missing MODULE_DEVICE_TABLE", " - pinctrl: single: fix missing error code in pcs_probe()", " - clk: at91: sama7g5: Allocate only the needed amount of memory for PLLs", " - iommufd/selftest: Fix buffer read overrrun in the dirty test", " - RDMA/bnxt_re: Fix the table size for PSN/MSN entries", " - media: imagination: VIDEO_E5010_JPEG_ENC should depend on ARCH_K3", " - [Config] updateconfigs for VIDEO_E5010_JPEG_ENC", " - RDMA/rtrs: Reset hb_missed_cnt after receiving other traffic from peer", " - clk: ti: dra7-atl: Fix leak of of_nodes", " - clk: starfive: Use pm_runtime_resume_and_get to fix pm_runtime_get_sync()", " usage", " - clk: rockchip: rk3588: Fix 32k clock name for pmu_24m_32k_100m_src_p", " - nfsd: remove unneeded EEXIST error check in nfsd_do_file_acquire", " - nfsd: fix refcount leak when file is unhashed after being found", " - pinctrl: mvebu: Fix devinit_dove_pinctrl_probe function", " - dt-bindings: PCI: layerscape-pci: Replace fsl,lx2160a-pcie with", " fsl,lx2160ar2-pcie", " - iommufd: Check the domain owner of the parent before creating a nesting", " domain", " - RDMA/erdma: Return QP state in erdma_query_qp", " - RDMA/mlx5: Fix counter update on MR cache mkey creation", " - RDMA/mlx5: Limit usage of over-sized mkeys from the MR cache", " - RDMA/mlx5: Drop redundant work canceling from clean_keys()", " - RDMA/mlx5: Fix MR cache temp entries cleanup", " - watchdog: imx_sc_wdt: Don't disable WDT in suspend", " - RDMA/hns: Don't modify rq next block addr in HIP09 QPC", " - RDMA/hns: Fix the overflow risk of hem_list_calc_ba_range()", " - RDMA/hns: Fix VF triggering PF reset in abnormal interrupt handler", " - RDMA/hns: Fix 1bit-ECC recovery address in non-4K OS", " - RDMA/hns: Optimize hem allocation performance", " - RDMA/hns: Fix restricted __le16 degrades to integer issue", " - Input: ims-pcu - fix calling interruptible mutex", " - RDMA/mlx5: Obtain upper net device only when needed", " - PCI: qcom-ep: Enable controller resources like PHY only after refclk is", " available", " - riscv: Fix fp alignment bug in perf_callchain_user()", " - RDMA/hns: Fix ah error counter in sw stat not increasing", " - RDMA/irdma: fix error message in irdma_modify_qp_roce()", " - ntb_perf: Fix printk format", " - ntb: Force physically contiguous allocation of rx ring buffers", " - nfsd: untangle code in nfsd4_deleg_getattr_conflict()", " - nfsd: fix initial getattr on write delegation", " - crypto: caam - Pad SG length when allocating hash edesc", " - crypto: powerpc/p10-aes-gcm - Disable CRYPTO_AES_GCM_P10", " - [Config] disable CRYPTO_AES_GCM_P10", " - f2fs: atomic: fix to avoid racing w/ GC", " - f2fs: reduce expensive checkpoint trigger frequency", " - f2fs: fix to avoid racing in between read and OPU dio write", " - f2fs: Create COW inode from parent dentry for atomic write", " - f2fs: fix to wait page writeback before setting gcing flag", " - f2fs: atomic: fix to truncate pagecache before on-disk metadata truncation", " - f2fs: compress: don't redirty sparse cluster during {,de}compress", " - f2fs: prevent atomic file from being dirtied before commit", " - spi: airoha: fix dirmap_{read,write} operations", " - spi: airoha: fix airoha_snand_{write,read}_data data_len estimation", " - spi: atmel-quadspi: Undo runtime PM changes at driver exit time", " - spi: spi-fsl-lpspi: Undo runtime PM changes at driver exit time", " - lib/sbitmap: define swap_lock as raw_spinlock_t", " - spi: airoha: remove read cache in airoha_snand_dirmap_read()", " - spi: atmel-quadspi: Avoid overwriting delay register settings", " - NFSv4.2: Fix detection of \"Proxying of Times\" server support", " - nvme-multipath: system fails to create generic nvme device", " - iio: adc: ad7606: fix oversampling gpio array", " - iio: adc: ad7606: fix standby gpio state to match the documentation", " - driver core: Fix error handling in driver API device_rename()", " - ABI: testing: fix admv8818 attr description", " - iio: chemical: bme680: Fix read/write ops to device by adding mutexes", " - iio: magnetometer: ak8975: drop incorrect AK09116 compatible", " - dt-bindings: iio: asahi-kasei,ak8975: drop incorrect AK09116 compatible", " - serial: 8250: omap: Cleanup on error in request_irq", " - Coresight: Set correct cs_mode for TPDM to fix disable issue", " - Coresight: Set correct cs_mode for dummy source to fix disable issue", " - coresight: tmc: sg: Do not leak sg_table", " - interconnect: icc-clk: Add missed num_nodes initialization", " - interconnect: qcom: sm8250: Enable sync_state", " - dm integrity: fix gcc 5 warning", " - cxl/pci: Fix to record only non-zero ranges", " - um: remove ARCH_NO_PREEMPT_DYNAMIC", " - Revert \"dm: requeue IO if mapping table not yet available\"", " - net: phy: aquantia: fix -ETIMEDOUT PHY probe failure when firmware not", " present", " - net: xilinx: axienet: Schedule NAPI in two steps", " - net: xilinx: axienet: Fix packet counting", " - net: ipv6: select DST_CACHE from IPV6_RPL_LWTUNNEL", " - net: qrtr: Update packets cloning when broadcasting", " - net: phy: aquantia: fix setting active_low bit", " - net: phy: aquantia: fix applying active_low bit after reset", " - net: ravb: Fix maximum TX frame size for GbEth devices", " - net: ravb: Fix R-Car RX frame size limit", " - virtio_net: Fix mismatched buf address when unmapping for small packets", " - netfilter: nf_tables: Keep deleted flowtable hooks until after RCU", " - netfilter: ctnetlink: compile ctnetlink_label_size with", " CONFIG_NF_CONNTRACK_EVENTS", " - netfilter: nf_tables: use rcu chain hook list iterator from netlink dump", " path", " - netfilter: nf_tables: missing objects with no memcg accounting", " - selftests: netfilter: Avoid hanging ipvs.sh", " - io_uring/sqpoll: do not allow pinning outside of cpuset", " - io_uring/rw: treat -EOPNOTSUPP for IOCB_NOWAIT like -EAGAIN", " - io_uring: check for presence of task_work rather than TIF_NOTIFY_SIGNAL", " - mm: migrate: annotate data-race in migrate_folio_unmap()", " - drm/amd/display: Fix Synaptics Cascaded Panamera DSC Determination", " - drm/amd/display: Add DSC Debug Log", " - drm/amdgpu/display: Fix a mistake in revert commit", " - xen: move checks for e820 conflicts further up", " - xen: allow mapping ACPI data using a different physical address", " - io_uring/sqpoll: retain test for whether the CPU is valid", " - drm/amd/display: disable_hpo_dp_link_output: Check link_res->hpo_dp_link_enc", " before using it", " - io_uring/sqpoll: do not put cpumask on stack", " - selftests/bpf: correctly move 'log' upon successful match", " - Remove *.orig pattern from .gitignore", " - PCI: Revert to the original speed after PCIe failed link retraining", " - PCI: Clear the LBMS bit after a link retrain", " - PCI: dra7xx: Fix threaded IRQ request for \"dra7xx-pcie-main\" IRQ", " - PCI: imx6: Fix missing call to phy_power_off() in error handling", " - PCI: imx6: Fix establish link failure in EP mode for i.MX8MM and i.MX8MP", " - PCI: imx6: Fix i.MX8MP PCIe EP's occasional failure to trigger MSI", " - PCI: Correct error reporting with PCIe failed link retraining", " - PCI: Use an error code with PCIe failed link retraining", " - PCI: xilinx-nwl: Fix off-by-one in INTx IRQ handler", " - PCI: dra7xx: Fix error handling when IRQ request fails in probe", " - Revert \"soc: qcom: smd-rpm: Match rpmsg channel instead of compatible\"", " - ASoC: rt5682: Return devm_of_clk_add_hw_provider to transfer the error", " - soc: fsl: cpm1: qmc: Update TRNSYNC only in transparent mode", " - soc: fsl: cpm1: tsa: Fix tsa_write8()", " - soc: versatile: integrator: fix OF node leak in probe() error path", " - Revert \"media: tuners: fix error return code of", " hybrid_tuner_request_state()\"", " - iommu/amd: Fix argument order in amd_iommu_dev_flush_pasid_all()", " - Input: adp5588-keys - fix check on return code", " - Input: i8042 - add TUXEDO Stellaris 16 Gen5 AMD to i8042 quirk table", " - Input: i8042 - add TUXEDO Stellaris 15 Slim Gen6 AMD to i8042 quirk table", " - Input: i8042 - add another board name for TUXEDO Stellaris Gen5 AMD line", " - KVM: arm64: Add memory length checks and remove inline in do_ffa_mem_xfer", " - KVM: x86: Enforce x2APIC's must-be-zero reserved ICR bits", " - KVM: x86: Move x2APIC ICR helper above kvm_apic_write_nodecode()", " - KVM: x86: Re-split x2APIC ICR into ICR+ICR2 for AMD (x2AVIC)", " - drm/amdgpu/mes12: reduce timeout", " - drm/amdgpu/mes11: reduce timeout", " - drm/amdkfd: Add SDMA queue quantum support for GFX12", " - drm/amdgpu: update golden regs for gfx12", " - drm/amdgpu/mes12: set enable_level_process_quantum_check", " - drm/amdgpu/vcn: enable AV1 on both instances", " - drm/amd/pm: update workload mask after the setting", " - drm/amdgpu: fix PTE copy corruption for sdma 7", " - drm/amdgpu: bump driver version for cleared VRAM", " - drm/amdgpu/mes12: switch SET_SHADER_DEBUGGER pkt to mes schq pipe", " - drm/amdgpu: Fix selfring initialization sequence on soc24", " - drm/amd/display: Add HDMI DSC native YCbCr422 support", " - drm/amd/display: Round calculated vtotal", " - drm/amd/display: Clean up dsc blocks in accelerated mode", " - drm/amd/display: Block timing sync for different output formats in pmo", " - drm/amd/display: Validate backlight caps are sane", " - drm/amd/display: Disable SYMCLK32_LE root clock gating", " - drm/amd/display: Block dynamic IPS2 on DCN35 for incompatible FW versions", " - drm/amd/display: Enable DML2 override_det_buffer_size_kbytes", " - drm/amd/display: Skip to enable dsc if it has been off", " - drm/amd/display: Fix underflow when setting underscan on DCN401", " - drm/amd/display: Update IPS default mode for DCN35/DCN351", " - objtool: Handle frame pointer related instructions", " - powerpc/atomic: Use YZ constraints for DS-form instructions", " - ksmbd: make __dir_empty() compatible with POSIX", " - ksmbd: allow write with FILE_APPEND_DATA", " - ksmbd: handle caseless file creation", " - ata: libata-scsi: Fix ata_msense_control() CDL page reporting", " - scsi: ufs: qcom: Update MODE_MAX cfg_bw value", " - scsi: lpfc: Restrict support for 32 byte CDBs to specific HBAs", " - scsi: mac_scsi: Revise printk(KERN_DEBUG ...) messages", " - scsi: mac_scsi: Refactor polling loop", " - scsi: mac_scsi: Disallow bus errors during PDMA send", " - can: esd_usb: Remove CAN_CTRLMODE_3_SAMPLES for CAN-USB/3-FD", " - wifi: rtw88: Fix USB/SDIO devices not transmitting beacons", " - usbnet: fix cyclical race on disconnect with work queue", " - arm64: dts: mediatek: mt8195-cherry: Mark USB 3.0 on xhci1 as disabled", " - arm64: dts: mediatek: mt8395-nio-12l: Mark USB 3.0 on xhci1 as disabled", " - USB: appledisplay: close race between probe and completion handler", " - USB: misc: cypress_cy7c63: check for short transfer", " - USB: class: CDC-ACM: fix race between get_serial and set_serial", " - USB: misc: yurex: fix race between read and write", " - usb: xhci: fix loss of data on Cadence xHC", " - usb: cdnsp: Fix incorrect usb_request status", " - usb: xHCI: add XHCI_RESET_ON_RESUME quirk for Phytium xHCI host", " - usb: gadget: dummy_hcd: execute hrtimer callback in softirq context", " - usb: dwc2: drd: fix clock gating on USB role switch", " - bus: integrator-lm: fix OF node leak in probe()", " - bus: mhi: host: pci_generic: Update EDL firmware path for Foxconn modems", " - bus: mhi: host: pci_generic: Fix the name for the Telit FE990A", " - tty: rp2: Fix reset with non forgiving PCIe host bridges", " - pps: add an error check in parport_attach", " - serial: don't use uninitialized value in uart_poll_init()", " - xhci: Set quirky xHC PCI hosts to D3 _after_ stopping and freeing them.", " - serial: qcom-geni: fix fifo polling timeout", " - serial: qcom-geni: fix false console tx restart", " - crypto: qcom-rng - fix support for ACPI-based systems", " - crypto: ccp - Properly unregister /dev/sev on sev PLATFORM_STATUS failure", " - drbd: Fix atomicity violation in drbd_uuid_set_bm()", " - drbd: Add NULL check for net_conf to prevent dereference in state validation", " - ACPI: resource: Do IRQ override on MECHREV GM7XG0M", " - ACPI: resource: Add another DMI match for the TongFang GMxXGxx", " - intel_idle: add Granite Rapids Xeon support", " - intel_idle: fix ACPI _CST matching for newer Xeon platforms", " - x86/entry: Remove unwanted instrumentation in common_interrupt()", " - perf/x86/intel: Allow to setup LBR for counting event for BPF", " - perf/x86/intel/pt: Fix sampling synchronization", " - btrfs: subpage: fix the bitmap dump which can cause bitmap corruption", " - wifi: mt76: mt7921: Check devm_kasprintf() returned value", " - wifi: mt76: mt7915: check devm_kasprintf() returned value", " - idpf: fix netdev Tx queue stop/wake", " - wifi: rtw88: 8821cu: Remove VID/PID 0bda:c82c", " - wifi: rtw88: 8822c: Fix reported RX band width", " - wifi: rtw88: 8703b: Fix reported RX band width", " - wifi: mt76: mt7615: check devm_kasprintf() returned value", " - wifi: mt76: mt7925: fix a potential association failure upon resuming", " - debugfs show actual source in /proc/mounts", " - debugobjects: Fix conditions in fill_pool()", " - btrfs: tree-checker: fix the wrong output of data backref objectid", " - btrfs: always update fstrim_range on failure in FITRIM ioctl", " - f2fs: fix several potential integer overflows in file offsets", " - f2fs: prevent possible int overflow in dir_block_index()", " - f2fs: avoid potential int overflow in sanity_check_area_boundary()", " - hwrng: mtk - Use devm_pm_runtime_enable", " - hwrng: bcm2835 - Add missing clk_disable_unprepare in bcm2835_rng_init", " - hwrng: cctrng - Add missing clk_disable_unprepare in cctrng_resume", " - arm64: esr: Define ESR_ELx_EC_* constants as UL", " - arm64: errata: Enable the AC03_CPU_38 workaround for ampere1a", " - arm64: dts: mediatek: mt8186-corsola: Disable DPI display interface", " - arm64: dts: rockchip: Raise Pinebook Pro's panel backlight PWM frequency", " - arm64: dts: qcom: sa8775p: Mark APPS and PCIe SMMUs as DMA coherent", " - arm64: dts: rockchip: Correct the Pinebook Pro battery design capacity", " - fs: Fix file_set_fowner LSM hook inconsistencies", " - nfs: fix memory leak in error path of nfs4_do_reclaim", " - EDAC/igen6: Fix conversion of system address to physical memory address", " - eventpoll: Annotate data-race of busy_poll_usecs", " - md: Don't flush sync_work in md_write_start()", " - cpuidle: riscv-sbi: Use scoped device node handling to fix missing", " of_node_put", " - lsm: add the inode_free_security_rcu() LSM implementation hook", " - spi: fspi: involve lut_num for struct nxp_fspi_devtype_data", " - dt-bindings: spi: nxp-fspi: add imx8ulp support", " - ARM: dts: imx6ul-geam: fix fsl,pins property in tscgrp pinctrl", " - ARM: dts: imx6ull-seeed-npi: fix fsl,pins property in tscgrp pinctrl", " - tools/nolibc: include arch.h from string.h", " - soc: versatile: realview: fix memory leak during device remove", " - soc: versatile: realview: fix soc_dev leak during device remove", " - usb: typec: ucsi: Call CANCEL from single location", " - usb: typec: ucsi: Fix busy loop on ASUS VivoBooks", " - soc: qcom: geni-se: add GP_LENGTH/IRQ_EN_SET/IRQ_EN_CLEAR registers", " - serial: qcom-geni: fix arg types for qcom_geni_serial_poll_bit()", " - serial: qcom-geni: introduce qcom_geni_serial_poll_bitfield()", " - serial: qcom-geni: fix console corruption", " - thermal: core: Store trip sysfs attributes in thermal_trip_desc", " - thermal: sysfs: Get to trips via attribute pointers", " - thermal: sysfs: Refine the handling of trip hysteresis changes", " - thermal: sysfs: Add sanity checks for trip temperature and hysteresis", " - bpf: lsm: Set bpf_lsm_blob_sizes.lbs_task to 0", " - compiler.h: specify correct attribute for .rodata..c_jump_table", " - lockdep: fix deadlock issue between lockdep and rcu", " - mm/hugetlb_vmemmap: batch HVO work when demoting", " - s390/ftrace: Avoid calling unwinder in ftrace_return_address()", " - selftest mm/mseal: fix test_seal_mremap_move_dontunmap_anyaddr", " - mm: only enforce minimum stack gap size if it's sensible", " - spi: fspi: add support for imx8ulp", " - module: Fix KCOV-ignored file name", " - fbdev: xen-fbfront: Assign fb_info->device", " - tpm: export tpm2_sessions_init() to fix ibmvtpm building", " - mm/huge_memory: ensure huge_zero_folio won't have large_rmappable flag set", " - mm: change vmf_anon_prepare() to __vmf_anon_prepare()", " - mm/damon/vaddr: protect vma traversal in __damon_va_thre_regions() with rcu", " read lock", " - i2c: aspeed: Update the stop sw state when the bus recovery occurs", " - i2c: isch: Add missed 'else'", " - i2c: xiic: Try re-initialization on bus busy timeout", " - Documentation: KVM: fix warning in \"make htmldocs\"", " - spi: atmel-quadspi: Fix wrong register value written to MR", " - Revert: \"dm-verity: restart or panic on an I/O error\"", " - Linux 6.11.2", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47675", " - bpf: Fix use-after-free in bpf_uprobe_multi_link_attach()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47676", " - mm/hugetlb.c: fix UAF of vma in hugetlb fault pathway", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47677", " - exfat: resolve memory leak from exfat_create_upcase_table()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47725", " - dm-verity: restart or panic on an I/O error", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47739", " - padata: use integer wrap around to prevent deadlock on seq_nr overflow", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47678", " - icmp: change the order of rate limits", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47733", " - netfs: Delete subtree of 'fs/netfs' when netfs module exits", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47679", " - vfs: fix race between evice_inodes() and find_inode()&iput()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49859", " - f2fs: fix to check atomic_file in f2fs ioctl interfaces", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47680", " - f2fs: check discard support for conventional zones", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47740", " - f2fs: Require FMODE_WRITE for atomic write ioctls", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47726", " - f2fs: fix to wait dio completion", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47741", " - btrfs: fix race setting file private on concurrent lseek using same fd", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47681", " - wifi: mt76: mt7996: fix NULL pointer dereference in mt7996_mcu_sta_bfer_he", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49858", " - efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49860", " - ACPI: sysfs: validate return type of _STR method", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47742", " - firmware_loader: Block path traversal", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47682", " - scsi: sd: Fix off-by-one error in sd_read_block_characteristics()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47743", " - KEYS: prevent NULL pointer dereference in find_asymmetric_key()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47727", " - x86/tdx: Fix \"in-kernel MMIO\" check", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47744", " - KVM: Use dedicated mutex to protect kvm_usage_count to avoid deadlock", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47719", " - iommufd: Protect against overflow of ALIGN() during iova allocation", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47745", " - mm: call the security_mmap_file() LSM hook in remap_file_pages()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47746", " - fuse: use exclusive lock when FUSE_I_CACHE_IO_MODE is set", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47734", " - bonding: Fix unnecessary warnings and logs from bond_xdp_get_xmit_slave()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47684", " - tcp: check skb is non-NULL in tcp_rto_delta_us()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47747", " - net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race", " Condition", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47685", " - netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47686", " - ep93xx: clock: Fix off by one in ep93xx_div_recalc_rate()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47748", " - vhost_vdpa: assign irq bypass producer token correctly", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47687", " - vdpa/mlx5: Fix invalid mr resource destroy", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47688", " - driver core: Fix a potential null-ptr-deref in module_add_driver()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47689", " - f2fs: fix to don't set SB_RDONLY in f2fs_handle_critical_error()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47690", " - f2fs: get rid of online repaire on corrupted directory", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47691", " - f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47692", " - nfsd: return -EINVAL when namelen is 0", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47737", " - nfsd: call cache_put if xdr_reserve_space returns NULL", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2023-52917", " - ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47749", " - RDMA/cxgb4: Added NULL check for lookup_atid", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47735", " - RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47750", " - RDMA/hns: Fix Use-After-Free of rsv_qp on HIP08", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47751", " - PCI: kirin: Fix buffer overflow in kirin_pcie_parse_port()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47693", " - IB/core: Fix ib_cache_setup_one error flow cleanup", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47694", " - IB/mlx5: Fix UMR pd cleanup on error flow of driver init", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47695", " - RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47752", " - media: mediatek: vcodec: Fix H264 stateless decoder smatch warning", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47753", " - media: mediatek: vcodec: Fix VP8 stateless decoder smatch warning", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47754", " - media: mediatek: vcodec: Fix H264 multi stateless decoder smatch warning", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47696", " - RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47755", " - nvdimm: Fix devs leaks in scan_labels()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47756", " - PCI: keystone: Fix if-statement expression in ks_pcie_quirk()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47697", " - drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47698", " - drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47728", " - bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49861", " - bpf: Fix helper writes to read-only maps", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47757", " - nilfs2: fix potential oob read in nilfs_btree_check_delete()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47699", " - nilfs2: fix potential null-ptr-deref in nilfs_btree_insert()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47700", " - ext4: check stripe size compatibility on remount as well", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47701", " - ext4: avoid OOB when system.data xattr changes underneath the filesystem", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49850", " - bpf: correctly handle malformed BPF_CORE_TYPE_ID_LOCAL relos", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47702", " - bpf: Fail verification for sign-extension of packet data/data_end/data_meta", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47703", " - bpf, lsm: Add check for BPF LSM return value", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49851", " - tpm: Clean up TPM space after command failure", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47723", " - jfs: fix out-of-bounds in dbNextAG() and diAlloc()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49852", " - scsi: elx: libefc: Fix potential use after free in efc_nport_vport_del()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47720", " - drm/amd/display: Add null check for set_output_gamma in", " dcn30_set_output_transfer_func", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47704", " - drm/amd/display: Check link_res->hpo_dp_link_enc before using it", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49853", " - firmware: arm_scmi: Fix double free in OPTEE transport", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47705", " - block: fix potential invalid pointer dereference in blk_add_partition", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47736", " - erofs: handle overlapped pclusters out of crafted images properly", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47706", " - block, bfq: fix possible UAF for bfqq->bic with merge chain", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49855", " - nbd: fix race between timeout and normal completion", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47707", " - ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47708", " - netkit: Assign missing bpf_net_context", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47709", " - can: bcm: Clear bo->bcm_proc_read after remove_proc_entry().", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47710", " - sock_map: Add a cond_resched() in sock_hash_free()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47711", " - af_unix: Don't return OOB skb in manage_oob().", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47712", " - wifi: wilc1000: fix potential RCU dereference issue in", " wilc_parse_join_bss_param", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47713", " - wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47730", " - crypto: hisilicon/qm - inject error before stopping queue", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49856", " - x86/sgx: Fix deadlock in SGX NUMA node search", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47714", " - wifi: mt76: mt7996: use hweight16 to get correct tx antenna", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47715", " - wifi: mt76: mt7915: fix oops on non-dbdc mt7986", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49857", " - wifi: iwlwifi: mvm: set the cipher for secured NDP ranging", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47738", " - wifi: mac80211: don't use rate mask for offchannel TX either", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47731", " - drivers/perf: Fix ali_drw_pmu driver interrupt status clearing", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49862", " - powercap: intel_rapl: Fix off by one in get_rpi()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47716", " - ARM: 9410/1: vfp: Use asm volatile in fmrx/fmxr macros", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47717", " - RISC-V: KVM: Don't zero-out PMU snapshot area before freeing data", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47721", " - wifi: rtw89: remove unused C2H event ID RTW89_MAC_C2H_FUNC_READ_WOW_CAM to", " prevent out-of-bounds reading", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47732", " - crypto: iaa - Fix potential use after free bug", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47718", " - wifi: rtw88: always wait for both firmware loading attempts", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47724", " - wifi: ath11k: use work queue to process beacon tx event", "", " * Oracular update: v6.11.1 upstream stable release (LP: #2089020)", " - powercap/intel_rapl: Add support for AMD family 1Ah", " - powercap/intel_rapl: Fix the energy-pkg event for AMD CPUs", " - cpufreq/amd-pstate: Add the missing cpufreq_cpu_put()", " - netfilter: nft_socket: Fix a NULL vs IS_ERR() bug in", " nft_socket_cgroup_subtree_level()", " - ASoC: amd: acp: add ZSC control register programming sequence", " - nvme-pci: qdepth 1 quirk", " - USB: serial: pl2303: add device id for Macrosilicon MS3020", " - powercap: intel_rapl: Change an error pointer to NULL", " - Linux 6.11.1", "", " * Oracular update: v6.11.1 upstream stable release (LP: #2089020) //", " CVE-2024-47671", " - USB: usbtmc: prevent kernel-usb-infoleak", "", " * Oracular update: v6.11.1 upstream stable release (LP: #2089020) //", " CVE-2024-46869", " - Bluetooth: btintel_pcie: Allocate memory for driver private data", "", " * CVE-2024-53164", " - net: sched: fix ordering of qlen adjustment", "", " * CVE-2024-53103", " - hv_sock: Initializing vsk->trans to NULL to prevent a dangling pointer", "" ], "package": "linux", "version": "6.11.0-17.17", "urgency": "medium", "distributions": "oracular", "launchpad_bugs_fixed": [ 2093643, 1786013, 2091744, 2091184, 2093146, 2085406, 2089684, 2090932, 2085485, 2089357, 2089306, 2091655, 2091655, 2091655, 2091655, 2091655, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091386, 2091990, 2089327, 2089113, 2086587, 2086606, 2085950, 2085944, 2087853, 2087983, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089020, 2089020, 2089020 ], "author": "Stefan Bader ", "date": "Thu, 16 Jan 2025 22:38:59 +0100" } ], "notes": "linux-image-6.11.0-18-generic version '6.11.0-18.18' (source package linux version '6.11.0-18.18') was added. linux-image-6.11.0-18-generic version '6.11.0-18.18' has the same source package name, linux, as removed package linux-headers-6.11.0-14. As such we can use the source package version of the removed package, '6.11.0-14.15', 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." }, { "name": "linux-modules-6.11.0-18-generic", "from_version": { "source_package_name": "linux", "source_package_version": "6.11.0-14.15", "version": null }, "to_version": { "source_package_name": "linux", "source_package_version": "6.11.0-18.18", "version": "6.11.0-18.18" }, "cves": [ { "cve": "CVE-2025-0927", "url": "https://ubuntu.com/security/CVE-2025-0927", "cve_description": "[fs: hfs/hfsplus: add key_len boundary check to hfs_bnode_read_key]", "cve_priority": "medium", "cve_public_date": "2025-02-13" }, { "cve": "CVE-2024-53141", "url": "https://ubuntu.com/security/CVE-2024-53141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: add missing range check in bitmap_ip_uadt When tb[IPSET_ATTR_IP_TO] is not present but tb[IPSET_ATTR_CIDR] exists, the values of ip and ip_to are slightly swapped. Therefore, the range check for ip should be done later, but this part is missing and it seems that the vulnerability occurs. So we should add missing range checks and remove unnecessary range checks.", "cve_priority": "medium", "cve_public_date": "2024-12-06 10:15:00 UTC" }, { "cve": "CVE-2024-50010", "url": "https://ubuntu.com/security/CVE-2024-50010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exec: don't WARN for racy path_noexec check Both i_mode and noexec checks wrapped in WARN_ON stem from an artifact of the previous implementation. They used to legitimately check for the condition, but that got moved up in two commits: 633fb6ac3980 (\"exec: move S_ISREG() check earlier\") 0fd338b2d2cd (\"exec: move path_noexec() check earlier\") Instead of being removed said checks are WARN_ON'ed instead, which has some debug value. However, the spurious path_noexec check is racy, resulting in unwarranted warnings should someone race with setting the noexec flag. One can note there is more to perm-checking whether execve is allowed and none of the conditions are guaranteed to still hold after they were tested for. Additionally this does not validate whether the code path did any perm checking to begin with -- it will pass if the inode happens to be regular. Keep the redundant path_noexec() check even though it's mindless nonsense checking for guarantee that isn't given so drop the WARN. Reword the commentary and do small tidy ups while here. [brauner: keep redundant path_noexec() check]", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-53143", "url": "https://ubuntu.com/security/CVE-2024-53143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fsnotify: Fix ordering of iput() and watched_objects decrement Ensure the superblock is kept alive until we're done with iput(). Holding a reference to an inode is not allowed unless we ensure the superblock stays alive, which fsnotify does by keeping the watched_objects count elevated, so iput() must happen before the watched_objects decrement. This can lead to a UAF of something like sb->s_fs_info in tmpfs, but the UAF is hard to hit because race orderings that oops are more likely, thanks to the CHECK_DATA_CORRUPTION() block in generic_shutdown_super(). Also, ensure that fsnotify_put_sb_watched_objects() doesn't call fsnotify_sb_watched_objects() on a superblock that may have already been freed, which would cause a UAF read of sb->s_fsnotify_info.", "cve_priority": "medium", "cve_public_date": "2024-12-07 07:15:00 UTC" }, { "cve": "CVE-2024-53142", "url": "https://ubuntu.com/security/CVE-2024-53142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: initramfs: avoid filename buffer overrun The initramfs filename field is defined in Documentation/driver-api/early-userspace/buffer-format.rst as: 37 cpio_file := ALGN(4) + cpio_header + filename + \"\\0\" + ALGN(4) + data ... 55 ============= ================== ========================= 56 Field name Field size Meaning 57 ============= ================== ========================= ... 70 c_namesize 8 bytes Length of filename, including final \\0 When extracting an initramfs cpio archive, the kernel's do_name() path handler assumes a zero-terminated path at @collected, passing it directly to filp_open() / init_mkdir() / init_mknod(). If a specially crafted cpio entry carries a non-zero-terminated filename and is followed by uninitialized memory, then a file may be created with trailing characters that represent the uninitialized memory. The ability to create an initramfs entry would imply already having full control of the system, so the buffer overrun shouldn't be considered a security vulnerability. Append the output of the following bash script to an existing initramfs and observe any created /initramfs_test_fname_overrunAA* path. E.g. ./reproducer.sh | gzip >> /myinitramfs It's easiest to observe non-zero uninitialized memory when the output is gzipped, as it'll overflow the heap allocated @out_buf in __gunzip(), rather than the initrd_start+initrd_size block. ---- reproducer.sh ---- nilchar=\"A\"\t# change to \"\\0\" to properly zero terminate / pad magic=\"070701\" ino=1 mode=$(( 0100777 )) uid=0 gid=0 nlink=1 mtime=1 filesize=0 devmajor=0 devminor=1 rdevmajor=0 rdevminor=0 csum=0 fname=\"initramfs_test_fname_overrun\" namelen=$(( ${#fname} + 1 ))\t# plus one to account for terminator printf \"%s%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%s\" \\ \t$magic $ino $mode $uid $gid $nlink $mtime $filesize \\ \t$devmajor $devminor $rdevmajor $rdevminor $namelen $csum $fname termpadlen=$(( 1 + ((4 - ((110 + $namelen) & 3)) % 4) )) printf \"%.s${nilchar}\" $(seq 1 $termpadlen) ---- reproducer.sh ---- Symlink filename fields handled in do_symlink() won't overrun past the data segment, due to the explicit zero-termination of the symlink target. Fix filename buffer overrun by aborting the initramfs FSM if any cpio entry doesn't carry a zero-terminator at the expected (name_len - 1) offset.", "cve_priority": "medium", "cve_public_date": "2024-12-06 10:15:00 UTC" }, { "cve": "CVE-2024-53133", "url": "https://ubuntu.com/security/CVE-2024-53133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Handle dml allocation failure to avoid crash [Why] In the case where a dml allocation fails for any reason, the current state's dml contexts would no longer be valid. Then subsequent calls dc_state_copy_internal would shallow copy invalid memory and if the new state was released, a double free would occur. [How] Reset dml pointers in new_state to NULL and avoid invalid pointer (cherry picked from commit bcafdc61529a48f6f06355d78eb41b3aeda5296c)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53108", "url": "https://ubuntu.com/security/CVE-2024-53108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Adjust VSDB parser for replay feature At some point, the IEEE ID identification for the replay check in the AMD EDID was added. However, this check causes the following out-of-bounds issues when using KASAN: [ 27.804016] BUG: KASAN: slab-out-of-bounds in amdgpu_dm_update_freesync_caps+0xefa/0x17a0 [amdgpu] [ 27.804788] Read of size 1 at addr ffff8881647fdb00 by task systemd-udevd/383 ... [ 27.821207] Memory state around the buggy address: [ 27.821215] ffff8881647fda00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821224] ffff8881647fda80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821234] >ffff8881647fdb00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821243] ^ [ 27.821250] ffff8881647fdb80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821259] ffff8881647fdc00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821268] ================================================================== This is caused because the ID extraction happens outside of the range of the edid lenght. This commit addresses this issue by considering the amd_vsdb_block size. (cherry picked from commit b7e381b1ccd5e778e3d9c44c669ad38439a861d8)", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53134", "url": "https://ubuntu.com/security/CVE-2024-53134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pmdomain: imx93-blk-ctrl: correct remove path The check condition should be 'i < bc->onecell_data.num_domains', not 'bc->onecell_data.num_domains' which will make the look never finish and cause kernel panic. Also disable runtime to address \"imx93-blk-ctrl 4ac10000.system-controller: Unbalanced pm_runtime_enable!\"", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53132", "url": "https://ubuntu.com/security/CVE-2024-53132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/oa: Fix \"Missing outer runtime PM protection\" warning Fix the following drm_WARN: [953.586396] xe 0000:00:02.0: [drm] Missing outer runtime PM protection ... <4> [953.587090] ? xe_pm_runtime_get_noresume+0x8d/0xa0 [xe] <4> [953.587208] guc_exec_queue_add_msg+0x28/0x130 [xe] <4> [953.587319] guc_exec_queue_fini+0x3a/0x40 [xe] <4> [953.587425] xe_exec_queue_destroy+0xb3/0xf0 [xe] <4> [953.587515] xe_oa_release+0x9c/0xc0 [xe] (cherry picked from commit b107c63d2953907908fd0cafb0e543b3c3167b75)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53127", "url": "https://ubuntu.com/security/CVE-2024-53127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Revert \"mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K\" The commit 8396c793ffdf (\"mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K\") increased the max_req_size, even for 4K pages, causing various issues: - Panic booting the kernel/rootfs from an SD card on Rockchip RK3566 - Panic booting the kernel/rootfs from an SD card on StarFive JH7100 - \"swiotlb buffer is full\" and data corruption on StarFive JH7110 At this stage no fix have been found, so it's probably better to just revert the change. This reverts commit 8396c793ffdf28bb8aee7cfe0891080f8cab7890.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53130", "url": "https://ubuntu.com/security/CVE-2024-53130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint When using the \"block:block_dirty_buffer\" tracepoint, mark_buffer_dirty() may cause a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because, since the tracepoint was added in mark_buffer_dirty(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, nilfs_grab_buffer(), which grabs a buffer to read (or create) a block of metadata, including b-tree node blocks, does not set the block device, but instead does so only if the buffer is not in the \"uptodate\" state for each of its caller block reading functions. However, if the uptodate flag is set on a folio/page, and the buffer heads are detached from it by try_to_free_buffers(), and new buffer heads are then attached by create_empty_buffers(), the uptodate flag may be restored to each buffer without the block device being set to bh->b_bdev, and mark_buffer_dirty() may be called later in that state, resulting in the bug mentioned above. Fix this issue by making nilfs_grab_buffer() always set the block device of the super block structure to the buffer head, regardless of the state of the buffer's uptodate flag.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53105", "url": "https://ubuntu.com/security/CVE-2024-53105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: page_alloc: move mlocked flag clearance into free_pages_prepare() Syzbot reported a bad page state problem caused by a page being freed using free_page() still having a mlocked flag at free_pages_prepare() stage: BUG: Bad page state in process syz.5.504 pfn:61f45 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x61f45 flags: 0xfff00000080204(referenced|workingset|mlocked|node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000080204 0000000000000000 dead000000000122 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set page_owner tracks the page as allocated page last allocated via order 0, migratetype Unmovable, gfp_mask 0x400dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO), pid 8443, tgid 8442 (syz.5.504), ts 201884660643, free_ts 201499827394 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1537 prep_new_page mm/page_alloc.c:1545 [inline] get_page_from_freelist+0x303f/0x3190 mm/page_alloc.c:3457 __alloc_pages_noprof+0x292/0x710 mm/page_alloc.c:4733 alloc_pages_mpol_noprof+0x3e8/0x680 mm/mempolicy.c:2265 kvm_coalesced_mmio_init+0x1f/0xf0 virt/kvm/coalesced_mmio.c:99 kvm_create_vm virt/kvm/kvm_main.c:1235 [inline] kvm_dev_ioctl_create_vm virt/kvm/kvm_main.c:5488 [inline] kvm_dev_ioctl+0x12dc/0x2240 virt/kvm/kvm_main.c:5530 __do_compat_sys_ioctl fs/ioctl.c:1007 [inline] __se_compat_sys_ioctl+0x510/0xc90 fs/ioctl.c:950 do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline] __do_fast_syscall_32+0xb4/0x110 arch/x86/entry/common.c:386 do_fast_syscall_32+0x34/0x80 arch/x86/entry/common.c:411 entry_SYSENTER_compat_after_hwframe+0x84/0x8e page last free pid 8399 tgid 8399 stack trace: reset_page_owner include/linux/page_owner.h:25 [inline] free_pages_prepare mm/page_alloc.c:1108 [inline] free_unref_folios+0xf12/0x18d0 mm/page_alloc.c:2686 folios_put_refs+0x76c/0x860 mm/swap.c:1007 free_pages_and_swap_cache+0x5c8/0x690 mm/swap_state.c:335 __tlb_batch_free_encoded_pages mm/mmu_gather.c:136 [inline] tlb_batch_pages_flush mm/mmu_gather.c:149 [inline] tlb_flush_mmu_free mm/mmu_gather.c:366 [inline] tlb_flush_mmu+0x3a3/0x680 mm/mmu_gather.c:373 tlb_finish_mmu+0xd4/0x200 mm/mmu_gather.c:465 exit_mmap+0x496/0xc40 mm/mmap.c:1926 __mmput+0x115/0x390 kernel/fork.c:1348 exit_mm+0x220/0x310 kernel/exit.c:571 do_exit+0x9b2/0x28e0 kernel/exit.c:926 do_group_exit+0x207/0x2c0 kernel/exit.c:1088 __do_sys_exit_group kernel/exit.c:1099 [inline] __se_sys_exit_group kernel/exit.c:1097 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1097 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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 Modules linked in: CPU: 0 UID: 0 PID: 8442 Comm: syz.5.504 Not tainted 6.12.0-rc6-syzkaller #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 bad_page+0x176/0x1d0 mm/page_alloc.c:501 free_page_is_bad mm/page_alloc.c:918 [inline] free_pages_prepare mm/page_alloc.c:1100 [inline] free_unref_page+0xed0/0xf20 mm/page_alloc.c:2638 kvm_destroy_vm virt/kvm/kvm_main.c:1327 [inline] kvm_put_kvm+0xc75/0x1350 virt/kvm/kvm_main.c:1386 kvm_vcpu_release+0x54/0x60 virt/kvm/kvm_main.c:4143 __fput+0x23f/0x880 fs/file_table.c:431 task_work_run+0x24f/0x310 kernel/task_work.c:239 exit_task_work include/linux/task_work.h:43 [inline] do_exit+0xa2f/0x28e0 kernel/exit.c:939 do_group_exit+0x207/0x2c0 kernel/exit.c:1088 __do_sys_exit_group kernel/exit.c:1099 [in ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53109", "url": "https://ubuntu.com/security/CVE-2024-53109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nommu: pass NULL argument to vma_iter_prealloc() When deleting a vma entry from a maple tree, it has to pass NULL to vma_iter_prealloc() in order to calculate internal state of the tree, but it passed a wrong argument. As a result, nommu kernels crashed upon accessing a vma iterator, such as acct_collect() reading the size of vma entries after do_munmap(). This commit fixes this issue by passing a right argument to the preallocation call.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53131", "url": "https://ubuntu.com/security/CVE-2024-53131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint Patch series \"nilfs2: fix null-ptr-deref bugs on block tracepoints\". This series fixes null pointer dereference bugs that occur when using nilfs2 and two block-related tracepoints. This patch (of 2): It has been reported that when using \"block:block_touch_buffer\" tracepoint, touch_buffer() called from __nilfs_get_folio_block() causes a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because since the tracepoint was added in touch_buffer(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, the block_device structure is set after the function returns to the caller. Here, touch_buffer() is used to mark the folio/page that owns the buffer head as accessed, but the common search helper for folio/page used by the caller function was optimized to mark the folio/page as accessed when it was reimplemented a long time ago, eliminating the need to call touch_buffer() here in the first place. So this solves the issue by eliminating the touch_buffer() call itself.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53135", "url": "https://ubuntu.com/security/CVE-2024-53135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: VMX: Bury Intel PT virtualization (guest/host mode) behind CONFIG_BROKEN Hide KVM's pt_mode module param behind CONFIG_BROKEN, i.e. disable support for virtualizing Intel PT via guest/host mode unless BROKEN=y. There are myriad bugs in the implementation, some of which are fatal to the guest, and others which put the stability and health of the host at risk. For guest fatalities, the most glaring issue is that KVM fails to ensure tracing is disabled, and *stays* disabled prior to VM-Enter, which is necessary as hardware disallows loading (the guest's) RTIT_CTL if tracing is enabled (enforced via a VMX consistency check). Per the SDM: If the logical processor is operating with Intel PT enabled (if IA32_RTIT_CTL.TraceEn = 1) at the time of VM entry, the \"load IA32_RTIT_CTL\" VM-entry control must be 0. On the host side, KVM doesn't validate the guest CPUID configuration provided by userspace, and even worse, uses the guest configuration to decide what MSRs to save/load at VM-Enter and VM-Exit. E.g. configuring guest CPUID to enumerate more address ranges than are supported in hardware will result in KVM trying to passthrough, save, and load non-existent MSRs, which generates a variety of WARNs, ToPA ERRORs in the host, a potential deadlock, etc.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53106", "url": "https://ubuntu.com/security/CVE-2024-53106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: fix buffer overrun in ima_eventdigest_init_common Function ima_eventdigest_init() calls ima_eventdigest_init_common() with HASH_ALGO__LAST which is then used to access the array hash_digest_size[] leading to buffer overrun. Have a conditional statement to handle this.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53110", "url": "https://ubuntu.com/security/CVE-2024-53110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vp_vdpa: fix id_table array not null terminated error Allocate one extra virtio_device_id as null terminator, otherwise vdpa_mgmtdev_get_classes() may iterate multiple times and visit undefined memory.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53126", "url": "https://ubuntu.com/security/CVE-2024-53126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa: solidrun: Fix UB bug with devres In psnet_open_pf_bar() and snet_open_vf_bar() a string later passed to pcim_iomap_regions() is placed on the stack. Neither pcim_iomap_regions() nor the functions it calls copy that string. Should the string later ever be used, this, consequently, causes undefined behavior since the stack frame will by then have disappeared. Fix the bug by allocating the strings on the heap through devm_kasprintf().", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53111", "url": "https://ubuntu.com/security/CVE-2024-53111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mremap: fix address wraparound in move_page_tables() On 32-bit platforms, it is possible for the expression `len + old_addr < old_end` to be false-positive if `len + old_addr` wraps around. `old_addr` is the cursor in the old range up to which page table entries have been moved; so if the operation succeeded, `old_addr` is the *end* of the old region, and adding `len` to it can wrap. The overflow causes mremap() to mistakenly believe that PTEs have been copied; the consequence is that mremap() bails out, but doesn't move the PTEs back before the new VMA is unmapped, causing anonymous pages in the region to be lost. So basically if userspace tries to mremap() a private-anon region and hits this bug, mremap() will return an error and the private-anon region's contents appear to have been zeroed. The idea of this check is that `old_end - len` is the original start address, and writing the check that way also makes it easier to read; so fix the check by rearranging the comparison accordingly. (An alternate fix would be to refactor this function by introducing an \"orig_old_start\" variable or such.) Tested in a VM with a 32-bit X86 kernel; without the patch: ``` user@horn:~/big_mremap$ cat test.c #define _GNU_SOURCE #include #include #include #include #define ADDR1 ((void*)0x60000000) #define ADDR2 ((void*)0x10000000) #define SIZE 0x50000000uL int main(void) { unsigned char *p1 = mmap(ADDR1, SIZE, PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0); if (p1 == MAP_FAILED) err(1, \"mmap 1\"); unsigned char *p2 = mmap(ADDR2, SIZE, PROT_NONE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0); if (p2 == MAP_FAILED) err(1, \"mmap 2\"); *p1 = 0x41; printf(\"first char is 0x%02hhx\\n\", *p1); unsigned char *p3 = mremap(p1, SIZE, SIZE, MREMAP_MAYMOVE|MREMAP_FIXED, p2); if (p3 == MAP_FAILED) { printf(\"mremap() failed; first char is 0x%02hhx\\n\", *p1); } else { printf(\"mremap() succeeded; first char is 0x%02hhx\\n\", *p3); } } user@horn:~/big_mremap$ gcc -static -o test test.c user@horn:~/big_mremap$ setarch -R ./test first char is 0x41 mremap() failed; first char is 0x00 ``` With the patch: ``` user@horn:~/big_mremap$ setarch -R ./test first char is 0x41 mremap() succeeded; first char is 0x41 ```", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53107", "url": "https://ubuntu.com/security/CVE-2024-53107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: prevent integer overflow in pagemap_scan_get_args() The \"arg->vec_len\" variable is a u64 that comes from the user at the start of the function. The \"arg->vec_len * sizeof(struct page_region))\" multiplication can lead to integer wrapping. Use size_mul() to avoid that. Also the size_add/mul() functions work on unsigned long so for 32bit systems we need to ensure that \"arg->vec_len\" fits in an unsigned long.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53128", "url": "https://ubuntu.com/security/CVE-2024-53128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/task_stack: fix object_is_on_stack() for KASAN tagged pointers When CONFIG_KASAN_SW_TAGS and CONFIG_KASAN_STACK are enabled, the object_is_on_stack() function may produce incorrect results due to the presence of tags in the obj pointer, while the stack pointer does not have tags. This discrepancy can lead to incorrect stack object detection and subsequently trigger warnings if CONFIG_DEBUG_OBJECTS is also enabled. Example of the warning: ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at lib/debugobjects.c:557 __debug_object_init+0x330/0x364 Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5 #4 Hardware name: linux,dummy-virt (DT) pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __debug_object_init+0x330/0x364 lr : __debug_object_init+0x330/0x364 sp : ffff800082ea7b40 x29: ffff800082ea7b40 x28: 98ff0000c0164518 x27: 98ff0000c0164534 x26: ffff800082d93ec8 x25: 0000000000000001 x24: 1cff0000c00172a0 x23: 0000000000000000 x22: ffff800082d93ed0 x21: ffff800081a24418 x20: 3eff800082ea7bb0 x19: efff800000000000 x18: 0000000000000000 x17: 00000000000000ff x16: 0000000000000047 x15: 206b63617473206e x14: 0000000000000018 x13: ffff800082ea7780 x12: 0ffff800082ea78e x11: 0ffff800082ea790 x10: 0ffff800082ea79d x9 : 34d77febe173e800 x8 : 34d77febe173e800 x7 : 0000000000000001 x6 : 0000000000000001 x5 : feff800082ea74b8 x4 : ffff800082870a90 x3 : ffff80008018d3c4 x2 : 0000000000000001 x1 : ffff800082858810 x0 : 0000000000000050 Call trace: __debug_object_init+0x330/0x364 debug_object_init_on_stack+0x30/0x3c schedule_hrtimeout_range_clock+0xac/0x26c schedule_hrtimeout+0x1c/0x30 wait_task_inactive+0x1d4/0x25c kthread_bind_mask+0x28/0x98 init_rescuer+0x1e8/0x280 workqueue_init+0x1a0/0x3cc kernel_init_freeable+0x118/0x200 kernel_init+0x28/0x1f0 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53112", "url": "https://ubuntu.com/security/CVE-2024-53112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: uncache inode which has failed entering the group Syzbot has reported the following BUG: kernel BUG at fs/ocfs2/uptodate.c:509! ... Call Trace: ? __die_body+0x5f/0xb0 ? die+0x9e/0xc0 ? do_trap+0x15a/0x3a0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? do_error_trap+0x1dc/0x2c0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? __pfx_do_error_trap+0x10/0x10 ? handle_invalid_op+0x34/0x40 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? exc_invalid_op+0x38/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? ocfs2_set_new_buffer_uptodate+0x2e/0x160 ? ocfs2_set_new_buffer_uptodate+0x144/0x160 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ocfs2_group_add+0x39f/0x15a0 ? __pfx_ocfs2_group_add+0x10/0x10 ? __pfx_lock_acquire+0x10/0x10 ? mnt_get_write_access+0x68/0x2b0 ? __pfx_lock_release+0x10/0x10 ? rcu_read_lock_any_held+0xb7/0x160 ? __pfx_rcu_read_lock_any_held+0x10/0x10 ? smack_log+0x123/0x540 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x226/0x2b0 ocfs2_ioctl+0x65e/0x7d0 ? __pfx_ocfs2_ioctl+0x10/0x10 ? smack_file_ioctl+0x29e/0x3a0 ? __pfx_smack_file_ioctl+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x43d/0x780 ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10 ? __pfx_ocfs2_ioctl+0x10/0x10 __se_sys_ioctl+0xfb/0x170 do_syscall_64+0xf3/0x230 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... When 'ioctl(OCFS2_IOC_GROUP_ADD, ...)' has failed for the particular inode in 'ocfs2_verify_group_and_input()', corresponding buffer head remains cached and subsequent call to the same 'ioctl()' for the same inode issues the BUG() in 'ocfs2_set_new_buffer_uptodate()' (trying to cache the same buffer head of that inode). Fix this by uncaching the buffer head with 'ocfs2_remove_from_cache()' on error path in 'ocfs2_group_add()'.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53113", "url": "https://ubuntu.com/security/CVE-2024-53113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: fix NULL pointer dereference in alloc_pages_bulk_noprof We triggered a NULL pointer dereference for ac.preferred_zoneref->zone in alloc_pages_bulk_noprof() when the task is migrated between cpusets. When cpuset is enabled, in prepare_alloc_pages(), ac->nodemask may be ¤t->mems_allowed. when first_zones_zonelist() is called to find preferred_zoneref, the ac->nodemask may be modified concurrently if the task is migrated between different cpusets. Assuming we have 2 NUMA Node, when traversing Node1 in ac->zonelist, the nodemask is 2, and when traversing Node2 in ac->zonelist, the nodemask is 1. As a result, the ac->preferred_zoneref points to NULL zone. In alloc_pages_bulk_noprof(), for_each_zone_zonelist_nodemask() finds a allowable zone and calls zonelist_node_idx(ac.preferred_zoneref), leading to NULL pointer dereference. __alloc_pages_noprof() fixes this issue by checking NULL pointer in commit ea57485af8f4 (\"mm, page_alloc: fix check for NULL preferred_zone\") and commit df76cee6bbeb (\"mm, page_alloc: remove redundant checks from alloc fastpath\"). To fix it, check NULL pointer for preferred_zoneref->zone.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53114", "url": "https://ubuntu.com/security/CVE-2024-53114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 client A number of Zen4 client SoCs advertise the ability to use virtualized VMLOAD/VMSAVE, but using these instructions is reported to be a cause of a random host reboot. These instructions aren't intended to be advertised on Zen4 client so clear the capability.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53137", "url": "https://ubuntu.com/security/CVE-2024-53137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: fix cacheflush with PAN It seems that the cacheflush syscall got broken when PAN for LPAE was implemented. User access was not enabled around the cache maintenance instructions, causing them to fault.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53115", "url": "https://ubuntu.com/security/CVE-2024-53115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: avoid null_ptr_deref in vmw_framebuffer_surface_create_handle The 'vmw_user_object_buffer' function may return NULL with incorrect inputs. To avoid possible null pointer dereference, add a check whether the 'bo' is NULL in the vmw_framebuffer_surface_create_handle.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53116", "url": "https://ubuntu.com/security/CVE-2024-53116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix handling of partial GPU mapping of BOs This commit fixes the bug in the handling of partial mapping of the buffer objects to the GPU, which caused kernel warnings. Panthor didn't correctly handle the case where the partial mapping spanned multiple scatterlists and the mapping offset didn't point to the 1st page of starting scatterlist. The offset variable was not cleared after reaching the starting scatterlist. Following warning messages were seen. WARNING: CPU: 1 PID: 650 at drivers/iommu/io-pgtable-arm.c:659 __arm_lpae_unmap+0x254/0x5a0 pc : __arm_lpae_unmap+0x254/0x5a0 lr : __arm_lpae_unmap+0x2cc/0x5a0 Call trace: __arm_lpae_unmap+0x254/0x5a0 __arm_lpae_unmap+0x108/0x5a0 __arm_lpae_unmap+0x108/0x5a0 __arm_lpae_unmap+0x108/0x5a0 arm_lpae_unmap_pages+0x80/0xa0 panthor_vm_unmap_pages+0xac/0x1c8 [panthor] panthor_gpuva_sm_step_unmap+0x4c/0xc8 [panthor] op_unmap_cb.isra.23.constprop.30+0x54/0x80 __drm_gpuvm_sm_unmap+0x184/0x1c8 drm_gpuvm_sm_unmap+0x40/0x60 panthor_vm_exec_op+0xa8/0x120 [panthor] panthor_vm_bind_exec_sync_op+0xc4/0xe8 [panthor] panthor_ioctl_vm_bind+0x10c/0x170 [panthor] drm_ioctl_kernel+0xbc/0x138 drm_ioctl+0x210/0x4b0 __arm64_sys_ioctl+0xb0/0xf8 invoke_syscall+0x4c/0x110 el0_svc_common.constprop.1+0x98/0xf8 do_el0_svc+0x24/0x38 el0_svc+0x34/0xc8 el0t_64_sync_handler+0xa0/0xc8 el0t_64_sync+0x174/0x178 panthor : [drm] drm_WARN_ON(unmapped_sz != pgsize * pgcount) WARNING: CPU: 1 PID: 650 at drivers/gpu/drm/panthor/panthor_mmu.c:922 panthor_vm_unmap_pages+0x124/0x1c8 [panthor] pc : panthor_vm_unmap_pages+0x124/0x1c8 [panthor] lr : panthor_vm_unmap_pages+0x124/0x1c8 [panthor] panthor : [drm] *ERROR* failed to unmap range ffffa388f000-ffffa3890000 (requested range ffffa388c000-ffffa3890000)", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53117", "url": "https://ubuntu.com/security/CVE-2024-53117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio/vsock: Improve MSG_ZEROCOPY error handling Add a missing kfree_skb() to prevent memory leaks.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53118", "url": "https://ubuntu.com/security/CVE-2024-53118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Fix sk_error_queue memory leak Kernel queues MSG_ZEROCOPY completion notifications on the error queue. Where they remain, until explicitly recv()ed. To prevent memory leaks, clean up the queue when the socket is destroyed. unreferenced object 0xffff8881028beb00 (size 224): comm \"vsock_test\", pid 1218, jiffies 4294694897 hex dump (first 32 bytes): 90 b0 21 17 81 88 ff ff 90 b0 21 17 81 88 ff ff ..!.......!..... 00 00 00 00 00 00 00 00 00 b0 21 17 81 88 ff ff ..........!..... backtrace (crc 6c7031ca): [] kmem_cache_alloc_node_noprof+0x2f7/0x370 [] __alloc_skb+0x132/0x180 [] sock_omalloc+0x4b/0x80 [] msg_zerocopy_realloc+0x9e/0x240 [] virtio_transport_send_pkt_info+0x412/0x4c0 [] virtio_transport_stream_enqueue+0x43/0x50 [] vsock_connectible_sendmsg+0x373/0x450 [] ____sys_sendmsg+0x365/0x3a0 [] ___sys_sendmsg+0x84/0xd0 [] __sys_sendmsg+0x47/0x80 [] do_syscall_64+0x93/0x180 [] entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53119", "url": "https://ubuntu.com/security/CVE-2024-53119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio/vsock: Fix accept_queue memory leak As the final stages of socket destruction may be delayed, it is possible that virtio_transport_recv_listen() will be called after the accept_queue has been flushed, but before the SOCK_DONE flag has been set. As a result, sockets enqueued after the flush would remain unremoved, leading to a memory leak. vsock_release __vsock_release lock virtio_transport_release virtio_transport_close schedule_delayed_work(close_work) sk_shutdown = SHUTDOWN_MASK (!) flush accept_queue release virtio_transport_recv_pkt vsock_find_bound_socket lock if flag(SOCK_DONE) return virtio_transport_recv_listen child = vsock_create_connected (!) vsock_enqueue_accept(child) release close_work lock virtio_transport_do_close set_flag(SOCK_DONE) virtio_transport_remove_sock vsock_remove_sock vsock_remove_bound release Introduce a sk_shutdown check to disallow vsock_enqueue_accept() during socket destruction. unreferenced object 0xffff888109e3f800 (size 2040): comm \"kworker/5:2\", pid 371, jiffies 4294940105 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00 (..@............ backtrace (crc 9e5f4e84): [] kmem_cache_alloc_noprof+0x2c1/0x360 [] sk_prot_alloc+0x30/0x120 [] sk_alloc+0x2c/0x4b0 [] __vsock_create.constprop.0+0x2a/0x310 [] virtio_transport_recv_pkt+0x4dc/0x9a0 [] vsock_loopback_work+0xfd/0x140 [] process_one_work+0x20c/0x570 [] worker_thread+0x1bf/0x3a0 [] kthread+0xdd/0x110 [] ret_from_fork+0x2d/0x50 [] ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53120", "url": "https://ubuntu.com/security/CVE-2024-53120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: CT: Fix null-ptr-deref in add rule err flow In error flow of mlx5_tc_ct_entry_add_rule(), in case ct_rule_add() callback returns error, zone_rule->attr is used uninitiated. Fix it to use attr which has the needed pointer value. Kernel log: BUG: kernel NULL pointer dereference, address: 0000000000000110 RIP: 0010:mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core] … Call Trace: ? __die+0x20/0x70 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x140 ? asm_exc_page_fault+0x22/0x30 ? mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core] ? mlx5_tc_ct_entry_add_rule+0x1d5/0x2f0 [mlx5_core] mlx5_tc_ct_block_flow_offload+0xc6a/0xf90 [mlx5_core] ? nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] flow_offload_work_handler+0x142/0x320 [nf_flow_table] ? finish_task_switch.isra.0+0x15b/0x2b0 process_one_work+0x16c/0x320 worker_thread+0x28c/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xb8/0xf0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53138", "url": "https://ubuntu.com/security/CVE-2024-53138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: kTLS, Fix incorrect page refcounting The kTLS tx handling code is using a mix of get_page() and page_ref_inc() APIs to increment the page reference. But on the release path (mlx5e_ktls_tx_handle_resync_dump_comp()), only put_page() is used. This is an issue when using pages from large folios: the get_page() references are stored on the folio page while the page_ref_inc() references are stored directly in the given page. On release the folio page will be dereferenced too many times. This was found while doing kTLS testing with sendfile() + ZC when the served file was read from NFS on a kernel with NFS large folios support (commit 49b29a573da8 (\"nfs: add support for large folios\")).", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53121", "url": "https://ubuntu.com/security/CVE-2024-53121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: fs, lock FTE when checking if active The referenced commits introduced a two-step process for deleting FTEs: - Lock the FTE, delete it from hardware, set the hardware deletion function to NULL and unlock the FTE. - Lock the parent flow group, delete the software copy of the FTE, and remove it from the xarray. However, this approach encounters a race condition if a rule with the same match value is added simultaneously. In this scenario, fs_core may set the hardware deletion function to NULL prematurely, causing a panic during subsequent rule deletions. To prevent this, ensure the active flag of the FTE is checked under a lock, which will prevent the fs_core layer from attaching a new steering rule to an FTE that is in the process of deletion. [ 438.967589] MOSHE: 2496 mlx5_del_flow_rules del_hw_func [ 438.968205] ------------[ cut here ]------------ [ 438.968654] refcount_t: decrement hit 0; leaking memory. [ 438.969249] WARNING: CPU: 0 PID: 8957 at lib/refcount.c:31 refcount_warn_saturate+0xfb/0x110 [ 438.970054] Modules linked in: act_mirred cls_flower act_gact sch_ingress openvswitch nsh mlx5_vdpa vringh vhost_iotlb vdpa mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core zram zsmalloc fuse [last unloaded: cls_flower] [ 438.973288] CPU: 0 UID: 0 PID: 8957 Comm: tc Not tainted 6.12.0-rc1+ #8 [ 438.973888] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 438.974874] RIP: 0010:refcount_warn_saturate+0xfb/0x110 [ 438.975363] Code: 40 66 3b 82 c6 05 16 e9 4d 01 01 e8 1f 7c a0 ff 0f 0b c3 cc cc cc cc 48 c7 c7 10 66 3b 82 c6 05 fd e8 4d 01 01 e8 05 7c a0 ff <0f> 0b c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 90 [ 438.976947] RSP: 0018:ffff888124a53610 EFLAGS: 00010286 [ 438.977446] RAX: 0000000000000000 RBX: ffff888119d56de0 RCX: 0000000000000000 [ 438.978090] RDX: ffff88852c828700 RSI: ffff88852c81b3c0 RDI: ffff88852c81b3c0 [ 438.978721] RBP: ffff888120fa0e88 R08: 0000000000000000 R09: ffff888124a534b0 [ 438.979353] R10: 0000000000000001 R11: 0000000000000001 R12: ffff888119d56de0 [ 438.979979] R13: ffff888120fa0ec0 R14: ffff888120fa0ee8 R15: ffff888119d56de0 [ 438.980607] FS: 00007fe6dcc0f800(0000) GS:ffff88852c800000(0000) knlGS:0000000000000000 [ 438.983984] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 438.984544] CR2: 00000000004275e0 CR3: 0000000186982001 CR4: 0000000000372eb0 [ 438.985205] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 438.985842] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 438.986507] Call Trace: [ 438.986799] [ 438.987070] ? __warn+0x7d/0x110 [ 438.987426] ? refcount_warn_saturate+0xfb/0x110 [ 438.987877] ? report_bug+0x17d/0x190 [ 438.988261] ? prb_read_valid+0x17/0x20 [ 438.988659] ? handle_bug+0x53/0x90 [ 438.989054] ? exc_invalid_op+0x14/0x70 [ 438.989458] ? asm_exc_invalid_op+0x16/0x20 [ 438.989883] ? refcount_warn_saturate+0xfb/0x110 [ 438.990348] mlx5_del_flow_rules+0x2f7/0x340 [mlx5_core] [ 438.990932] __mlx5_eswitch_del_rule+0x49/0x170 [mlx5_core] [ 438.991519] ? mlx5_lag_is_sriov+0x3c/0x50 [mlx5_core] [ 438.992054] ? xas_load+0x9/0xb0 [ 438.992407] mlx5e_tc_rule_unoffload+0x45/0xe0 [mlx5_core] [ 438.993037] mlx5e_tc_del_fdb_flow+0x2a6/0x2e0 [mlx5_core] [ 438.993623] mlx5e_flow_put+0x29/0x60 [mlx5_core] [ 438.994161] mlx5e_delete_flower+0x261/0x390 [mlx5_core] [ 438.994728] tc_setup_cb_destroy+0xb9/0x190 [ 438.995150] fl_hw_destroy_filter+0x94/0xc0 [cls_flower] [ 438.995650] fl_change+0x11a4/0x13c0 [cls_flower] [ 438.996105] tc_new_tfilter+0x347/0xbc0 [ 438.996503] ? __ ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53122", "url": "https://ubuntu.com/security/CVE-2024-53122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: cope racing subflow creation in mptcp_rcv_space_adjust Additional active subflows - i.e. created by the in kernel path manager - are included into the subflow list before starting the 3whs. A racing recvmsg() spooling data received on an already established subflow would unconditionally call tcp_cleanup_rbuf() on all the current subflows, potentially hitting a divide by zero error on the newly created ones. Explicitly check that the subflow is in a suitable state before invoking tcp_cleanup_rbuf().", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53123", "url": "https://ubuntu.com/security/CVE-2024-53123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: error out earlier on disconnect Eric reported a division by zero splat in the MPTCP protocol: Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 6094 Comm: syz-executor317 Not tainted 6.12.0-rc5-syzkaller-00291-g05b92660cdfe #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:__tcp_select_window+0x5b4/0x1310 net/ipv4/tcp_output.c:3163 Code: f6 44 01 e3 89 df e8 9b 75 09 f8 44 39 f3 0f 8d 11 ff ff ff e8 0d 74 09 f8 45 89 f4 e9 04 ff ff ff e8 00 74 09 f8 44 89 f0 99 7c 24 14 41 29 d6 45 89 f4 e9 ec fe ff ff e8 e8 73 09 f8 48 89 RSP: 0018:ffffc900041f7930 EFLAGS: 00010293 RAX: 0000000000017e67 RBX: 0000000000017e67 RCX: ffffffff8983314b RDX: 0000000000000000 RSI: ffffffff898331b0 RDI: 0000000000000004 RBP: 00000000005d6000 R08: 0000000000000004 R09: 0000000000017e67 R10: 0000000000003e80 R11: 0000000000000000 R12: 0000000000003e80 R13: ffff888031d9b440 R14: 0000000000017e67 R15: 00000000002eb000 FS: 00007feb5d7f16c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007feb5d8adbb8 CR3: 0000000074e4c000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __tcp_cleanup_rbuf+0x3e7/0x4b0 net/ipv4/tcp.c:1493 mptcp_rcv_space_adjust net/mptcp/protocol.c:2085 [inline] mptcp_recvmsg+0x2156/0x2600 net/mptcp/protocol.c:2289 inet_recvmsg+0x469/0x6a0 net/ipv4/af_inet.c:885 sock_recvmsg_nosec net/socket.c:1051 [inline] sock_recvmsg+0x1b2/0x250 net/socket.c:1073 __sys_recvfrom+0x1a5/0x2e0 net/socket.c:2265 __do_sys_recvfrom net/socket.c:2283 [inline] __se_sys_recvfrom net/socket.c:2279 [inline] __x64_sys_recvfrom+0xe0/0x1c0 net/socket.c:2279 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 RIP: 0033:0x7feb5d857559 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:00007feb5d7f1208 EFLAGS: 00000246 ORIG_RAX: 000000000000002d RAX: ffffffffffffffda RBX: 00007feb5d8e1318 RCX: 00007feb5d857559 RDX: 000000800000000e RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007feb5d8e1310 R08: 0000000000000000 R09: ffffffff81000000 R10: 0000000000000100 R11: 0000000000000246 R12: 00007feb5d8e131c R13: 00007feb5d8ae074 R14: 000000800000000e R15: 00000000fffffdef and provided a nice reproducer. The root cause is the current bad handling of racing disconnect. After the blamed commit below, sk_wait_data() can return (with error) with the underlying socket disconnected and a zero rcv_mss. Catch the error and return without performing any additional operations on the current socket.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53124", "url": "https://ubuntu.com/security/CVE-2024-53124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix data-races around sk->sk_forward_alloc Syzkaller reported this warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 16 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x1c5/0x1e0 Modules linked in: CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:inet_sock_destruct+0x1c5/0x1e0 Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 <0f> 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00 RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206 RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007 RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00 RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007 R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00 R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78 FS: 0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn+0x88/0x130 ? inet_sock_destruct+0x1c5/0x1e0 ? report_bug+0x18e/0x1a0 ? handle_bug+0x53/0x90 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? inet_sock_destruct+0x1c5/0x1e0 __sk_destruct+0x2a/0x200 rcu_do_batch+0x1aa/0x530 ? rcu_do_batch+0x13b/0x530 rcu_core+0x159/0x2f0 handle_softirqs+0xd3/0x2b0 ? __pfx_smpboot_thread_fn+0x10/0x10 run_ksoftirqd+0x25/0x30 smpboot_thread_fn+0xdd/0x1d0 kthread+0xd3/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ---[ end trace 0000000000000000 ]--- Its possible that two threads call tcp_v6_do_rcv()/sk_forward_alloc_add() concurrently when sk->sk_state == TCP_LISTEN with sk->sk_lock unlocked, which triggers a data-race around sk->sk_forward_alloc: tcp_v6_rcv tcp_v6_do_rcv skb_clone_and_charge_r sk_rmem_schedule __sk_mem_schedule sk_forward_alloc_add() skb_set_owner_r sk_mem_charge sk_forward_alloc_add() __kfree_skb skb_release_all skb_release_head_state sock_rfree sk_mem_uncharge sk_forward_alloc_add() sk_mem_reclaim // set local var reclaimable __sk_mem_reclaim sk_forward_alloc_add() In this syzkaller testcase, two threads call tcp_v6_do_rcv() with skb->truesize=768, the sk_forward_alloc changes like this: (cpu 1) | (cpu 2) | sk_forward_alloc ... | ... | 0 __sk_mem_schedule() | | +4096 = 4096 | __sk_mem_schedule() | +4096 = 8192 sk_mem_charge() | | -768 = 7424 | sk_mem_charge() | -768 = 6656 ... | ... | sk_mem_uncharge() | | +768 = 7424 reclaimable=7424 | | | sk_mem_uncharge() | +768 = 8192 | reclaimable=8192 | __sk_mem_reclaim() | | -4096 = 4096 | __sk_mem_reclaim() | -8192 = -4096 != 0 The skb_clone_and_charge_r() should not be called in tcp_v6_do_rcv() when sk->sk_state is TCP_LISTEN, it happens later in tcp_v6_syn_recv_sock(). Fix the same issue in dccp_v6_do_rcv().", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53129", "url": "https://ubuntu.com/security/CVE-2024-53129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: vop: Fix a dereferenced before check warning The 'state' can't be NULL, we should check crtc_state. Fix warning: drivers/gpu/drm/rockchip/rockchip_drm_vop.c:1096 vop_plane_atomic_async_check() warn: variable dereferenced before check 'state' (see line 1077)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53139", "url": "https://ubuntu.com/security/CVE-2024-53139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix possible UAF in sctp_v6_available() A lockdep report [1] with CONFIG_PROVE_RCU_LIST=y hints that sctp_v6_available() is calling dev_get_by_index_rcu() and ipv6_chk_addr() without holding rcu. [1] ============================= WARNING: suspicious RCU usage 6.12.0-rc5-virtme #1216 Tainted: G W ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by sctp_hello/31495: #0: ffff9f1ebbdb7418 (sk_lock-AF_INET6){+.+.}-{0:0}, at: sctp_bind (./arch/x86/include/asm/jump_label.h:27 net/sctp/socket.c:315) sctp stack backtrace: CPU: 7 UID: 0 PID: 31495 Comm: sctp_hello Tainted: G W 6.12.0-rc5-virtme #1216 Tainted: [W]=WARN 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:123) lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822) dev_get_by_index_rcu (net/core/dev.c:876 (discriminator 7)) sctp_v6_available (net/sctp/ipv6.c:701) sctp sctp_do_bind (net/sctp/socket.c:400 (discriminator 1)) sctp sctp_bind (net/sctp/socket.c:320) sctp inet6_bind_sk (net/ipv6/af_inet6.c:465) ? security_socket_bind (security/security.c:4581 (discriminator 1)) __sys_bind (net/socket.c:1848 net/socket.c:1869) ? do_user_addr_fault (./include/linux/rcupdate.h:347 ./include/linux/rcupdate.h:880 ./include/linux/mm.h:729 arch/x86/mm/fault.c:1340) ? do_user_addr_fault (./arch/x86/include/asm/preempt.h:84 (discriminator 13) ./include/linux/rcupdate.h:98 (discriminator 13) ./include/linux/rcupdate.h:882 (discriminator 13) ./include/linux/mm.h:729 (discriminator 13) arch/x86/mm/fault.c:1340 (discriminator 13)) __x64_sys_bind (net/socket.c:1877 (discriminator 1) net/socket.c:1875 (discriminator 1) net/socket.c:1875 (discriminator 1)) do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f59b934a1e7 Code: 44 00 00 48 8b 15 39 8c 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 b8 31 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 09 8c 0c 00 f7 d8 64 89 01 48 All code ======== 0:\t44 00 00 \tadd %r8b,(%rax) 3:\t48 8b 15 39 8c 0c 00 \tmov 0xc8c39(%rip),%rdx # 0xc8c43 a:\tf7 d8 \tneg %eax c:\t64 89 02 \tmov %eax,%fs:(%rdx) f:\tb8 ff ff ff ff \tmov $0xffffffff,%eax 14:\teb bd \tjmp 0xffffffffffffffd3 16:\t66 2e 0f 1f 84 00 00 \tcs nopw 0x0(%rax,%rax,1) 1d:\t00 00 00 20:\t0f 1f 00 \tnopl (%rax) 23:\tb8 31 00 00 00 \tmov $0x31,%eax 28:\t0f 05 \tsyscall 2a:*\t48 3d 01 f0 ff ff \tcmp $0xfffffffffffff001,%rax\t\t<-- trapping instruction 30:\t73 01 \tjae 0x33 32:\tc3 \tret 33:\t48 8b 0d 09 8c 0c 00 \tmov 0xc8c09(%rip),%rcx # 0xc8c43 3a:\tf7 d8 \tneg %eax 3c:\t64 89 01 \tmov %eax,%fs:(%rcx) 3f:\t48 \trex.W Code starting with the faulting instruction =========================================== 0:\t48 3d 01 f0 ff ff \tcmp $0xfffffffffffff001,%rax 6:\t73 01 \tjae 0x9 8:\tc3 \tret 9:\t48 8b 0d 09 8c 0c 00 \tmov 0xc8c09(%rip),%rcx # 0xc8c19 10:\tf7 d8 \tneg %eax 12:\t64 89 01 \tmov %eax,%fs:(%rcx) 15:\t48 \trex.W RSP: 002b:00007ffe2d0ad398 EFLAGS: 00000202 ORIG_RAX: 0000000000000031 RAX: ffffffffffffffda RBX: 00007ffe2d0ad3d0 RCX: 00007f59b934a1e7 RDX: 000000000000001c RSI: 00007ffe2d0ad3d0 RDI: 0000000000000005 RBP: 0000000000000005 R08: 1999999999999999 R09: 0000000000000000 R10: 00007f59b9253298 R11: 000000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53140", "url": "https://ubuntu.com/security/CVE-2024-53140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netlink: terminate outstanding dump on socket close Netlink supports iterative dumping of data. It provides the families the following ops: - start - (optional) kicks off the dumping process - dump - actual dump helper, keeps getting called until it returns 0 - done - (optional) pairs with .start, can be used for cleanup The whole process is asynchronous and the repeated calls to .dump don't actually happen in a tight loop, but rather are triggered in response to recvmsg() on the socket. This gives the user full control over the dump, but also means that the user can close the socket without getting to the end of the dump. To make sure .start is always paired with .done we check if there is an ongoing dump before freeing the socket, and if so call .done. The complication is that sockets can get freed from BH and .done is allowed to sleep. So we use a workqueue to defer the call, when needed. Unfortunately this does not work correctly. What we defer is not the cleanup but rather releasing a reference on the socket. We have no guarantee that we own the last reference, if someone else holds the socket they may release it in BH and we're back to square one. The whole dance, however, appears to be unnecessary. Only the user can interact with dumps, so we can clean up when socket is closed. And close always happens in process context. Some async code may still access the socket after close, queue notification skbs to it etc. but no dumps can start, end or otherwise make progress. Delete the workqueue and flush the dump state directly from the release handler. Note that further cleanup is possible in -next, for instance we now always call .done before releasing the main module reference, so dump doesn't have to take a reference of its own.", "cve_priority": "high", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53098", "url": "https://ubuntu.com/security/CVE-2024-53098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/ufence: Prefetch ufence addr to catch bogus address access_ok() only checks for addr overflow so also try to read the addr to catch invalid addr sent from userspace. (cherry picked from commit 9408c4508483ffc60811e910a93d6425b8e63928)", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53099", "url": "https://ubuntu.com/security/CVE-2024-53099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check validity of link->type in bpf_link_show_fdinfo() If a newly-added link type doesn't invoke BPF_LINK_TYPE(), accessing bpf_link_type_strs[link->type] may result in an out-of-bounds access. To spot such missed invocations early in the future, checking the validity of link->type in bpf_link_show_fdinfo() and emitting a warning when such invocations are missed.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53089", "url": "https://ubuntu.com/security/CVE-2024-53089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: KVM: Mark hrtimer to expire in hard interrupt context Like commit 2c0d278f3293f (\"KVM: LAPIC: Mark hrtimer to expire in hard interrupt context\") and commit 9090825fa9974 (\"KVM: arm/arm64: Let the timer expire in hardirq context on RT\"), On PREEMPT_RT enabled kernels unmarked hrtimers are moved into soft interrupt expiry mode by default. Then the timers are canceled from an preempt-notifier which is invoked with disabled preemption which is not allowed on PREEMPT_RT. The timer callback is short so in could be invoked in hard-IRQ context. So let the timer expire on hard-IRQ context even on -RT. This fix a \"scheduling while atomic\" bug for PREEMPT_RT enabled kernels: BUG: scheduling while atomic: qemu-system-loo/1011/0x00000002 Modules linked in: amdgpu rfkill nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat ns CPU: 1 UID: 0 PID: 1011 Comm: qemu-system-loo Tainted: G W 6.12.0-rc2+ #1774 Tainted: [W]=WARN Hardware name: Loongson Loongson-3A5000-7A1000-1w-CRB/Loongson-LS3A5000-7A1000-1w-CRB, BIOS vUDK2018-LoongArch-V2.0.0-prebeta9 10/21/2022 Stack : ffffffffffffffff 0000000000000000 9000000004e3ea38 9000000116744000 90000001167475a0 0000000000000000 90000001167475a8 9000000005644830 90000000058dc000 90000000058dbff8 9000000116747420 0000000000000001 0000000000000001 6a613fc938313980 000000000790c000 90000001001c1140 00000000000003fe 0000000000000001 000000000000000d 0000000000000003 0000000000000030 00000000000003f3 000000000790c000 9000000116747830 90000000057ef000 0000000000000000 9000000005644830 0000000000000004 0000000000000000 90000000057f4b58 0000000000000001 9000000116747868 900000000451b600 9000000005644830 9000000003a13998 0000000010000020 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d ... Call Trace: [<9000000003a13998>] show_stack+0x38/0x180 [<9000000004e3ea34>] dump_stack_lvl+0x84/0xc0 [<9000000003a71708>] __schedule_bug+0x48/0x60 [<9000000004e45734>] __schedule+0x1114/0x1660 [<9000000004e46040>] schedule_rtlock+0x20/0x60 [<9000000004e4e330>] rtlock_slowlock_locked+0x3f0/0x10a0 [<9000000004e4f038>] rt_spin_lock+0x58/0x80 [<9000000003b02d68>] hrtimer_cancel_wait_running+0x68/0xc0 [<9000000003b02e30>] hrtimer_cancel+0x70/0x80 [] kvm_restore_timer+0x50/0x1a0 [kvm] [] kvm_arch_vcpu_load+0x68/0x2a0 [kvm] [] kvm_sched_in+0x34/0x60 [kvm] [<9000000003a749a0>] finish_task_switch.isra.0+0x140/0x2e0 [<9000000004e44a70>] __schedule+0x450/0x1660 [<9000000004e45cb0>] schedule+0x30/0x180 [] kvm_vcpu_block+0x70/0x120 [kvm] [] kvm_vcpu_halt+0x60/0x3e0 [kvm] [] kvm_handle_gspr+0x3f4/0x4e0 [kvm] [] kvm_handle_exit+0x1c8/0x260 [kvm]", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53090", "url": "https://ubuntu.com/security/CVE-2024-53090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix lock recursion afs_wake_up_async_call() can incur lock recursion. The problem is that it is called from AF_RXRPC whilst holding the ->notify_lock, but it tries to take a ref on the afs_call struct in order to pass it to a work queue - but if the afs_call is already queued, we then have an extraneous ref that must be put... calling afs_put_call() may call back down into AF_RXRPC through rxrpc_kernel_shutdown_call(), however, which might try taking the ->notify_lock again. This case isn't very common, however, so defer it to a workqueue. The oops looks something like: BUG: spinlock recursion on CPU#0, krxrpcio/7001/1646 lock: 0xffff888141399b30, .magic: dead4ead, .owner: krxrpcio/7001/1646, .owner_cpu: 0 CPU: 0 UID: 0 PID: 1646 Comm: krxrpcio/7001 Not tainted 6.12.0-rc2-build3+ #4351 Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014 Call Trace: dump_stack_lvl+0x47/0x70 do_raw_spin_lock+0x3c/0x90 rxrpc_kernel_shutdown_call+0x83/0xb0 afs_put_call+0xd7/0x180 rxrpc_notify_socket+0xa0/0x190 rxrpc_input_split_jumbo+0x198/0x1d0 rxrpc_input_data+0x14b/0x1e0 ? rxrpc_input_call_packet+0xc2/0x1f0 rxrpc_input_call_event+0xad/0x6b0 rxrpc_input_packet_on_conn+0x1e1/0x210 rxrpc_input_packet+0x3f2/0x4d0 rxrpc_io_thread+0x243/0x410 ? __pfx_rxrpc_io_thread+0x10/0x10 kthread+0xcf/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x24/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53101", "url": "https://ubuntu.com/security/CVE-2024-53101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized value issue in from_kuid and from_kgid ocfs2_setattr() uses attr->ia_mode, attr->ia_uid and attr->ia_gid in a trace point even though ATTR_MODE, ATTR_UID and ATTR_GID aren't set. Initialize all fields of newattrs to avoid uninitialized variables, by checking if ATTR_MODE, ATTR_UID, ATTR_GID are initialized, otherwise 0.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53091", "url": "https://ubuntu.com/security/CVE-2024-53091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Add sk_is_inet and IS_ICSK check in tls_sw_has_ctx_tx/rx As the introduction of the support for vsock and unix sockets in sockmap, tls_sw_has_ctx_tx/rx cannot presume the socket passed in must be IS_ICSK. vsock and af_unix sockets have vsock_sock and unix_sock instead of inet_connection_sock. For these sockets, tls_get_ctx may return an invalid pointer and cause page fault in function tls_sw_ctx_rx. BUG: unable to handle page fault for address: 0000000000040030 Workqueue: vsock-loopback vsock_loopback_work RIP: 0010:sk_psock_strp_data_ready+0x23/0x60 Call Trace: ? __die+0x81/0xc3 ? no_context+0x194/0x350 ? do_page_fault+0x30/0x110 ? async_page_fault+0x3e/0x50 ? sk_psock_strp_data_ready+0x23/0x60 virtio_transport_recv_pkt+0x750/0x800 ? update_load_avg+0x7e/0x620 vsock_loopback_work+0xd0/0x100 process_one_work+0x1a7/0x360 worker_thread+0x30/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x112/0x130 ? __kthread_cancel_work+0x40/0x40 ret_from_fork+0x1f/0x40 v2: - Add IS_ICSK check v3: - Update the commits in Fixes", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53092", "url": "https://ubuntu.com/security/CVE-2024-53092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_pci: Fix admin vq cleanup by using correct info pointer vp_modern_avq_cleanup() and vp_del_vqs() clean up admin vq resources by virtio_pci_vq_info pointer. The info pointer of admin vq is stored in vp_dev->admin_vq.info instead of vp_dev->vqs[]. Using the info pointer from vp_dev->vqs[] for admin vq causes a kernel NULL pointer dereference bug. In vp_modern_avq_cleanup() and vp_del_vqs(), get the info pointer from vp_dev->admin_vq.info for admin vq to clean up the resources. Also make info ptr as argument of vp_del_vq() to be symmetric with vp_setup_vq(). vp_reset calls vp_modern_avq_cleanup, and causes the Call Trace: ================================================================== BUG: kernel NULL pointer dereference, address:0000000000000000 ... CPU: 49 UID: 0 PID: 4439 Comm: modprobe Not tainted 6.11.0-rc5 #1 RIP: 0010:vp_reset+0x57/0x90 [virtio_pci] Call Trace: ... ? vp_reset+0x57/0x90 [virtio_pci] ? vp_reset+0x38/0x90 [virtio_pci] virtio_reset_device+0x1d/0x30 remove_vq_common+0x1c/0x1a0 [virtio_net] virtnet_remove+0xa1/0xc0 [virtio_net] virtio_dev_remove+0x46/0xa0 ... virtio_pci_driver_exit+0x14/0x810 [virtio_pci] ==================================================================", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53102", "url": "https://ubuntu.com/security/CVE-2024-53102", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53093", "url": "https://ubuntu.com/security/CVE-2024-53093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: defer partition scanning We need to suppress the partition scan from occuring within the controller's scan_work context. If a path error occurs here, the IO will wait until a path becomes available or all paths are torn down, but that action also occurs within scan_work, so it would deadlock. Defer the partion scan to a different context that does not block scan_work.", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53094", "url": "https://ubuntu.com/security/CVE-2024-53094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Add sendpage_ok() check to disable MSG_SPLICE_PAGES While running ISER over SIW, the initiator machine encounters a warning from skb_splice_from_iter() indicating that a slab page is being used in send_page. To address this, it is better to add a sendpage_ok() check within the driver itself, and if it returns 0, then MSG_SPLICE_PAGES flag should be disabled before entering the network stack. A similar issue has been discussed for NVMe in this thread: https://lore.kernel.org/all/20240530142417.146696-1-ofir.gal@volumez.com/ WARNING: CPU: 0 PID: 5342 at net/core/skbuff.c:7140 skb_splice_from_iter+0x173/0x320 Call Trace: tcp_sendmsg_locked+0x368/0xe40 siw_tx_hdt+0x695/0xa40 [siw] siw_qp_sq_process+0x102/0xb00 [siw] siw_sq_resume+0x39/0x110 [siw] siw_run_sq+0x74/0x160 [siw] kthread+0xd2/0x100 ret_from_fork+0x34/0x40 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53100", "url": "https://ubuntu.com/security/CVE-2024-53100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: tcp: avoid race between queue_lock lock and destroy Commit 76d54bf20cdc (\"nvme-tcp: don't access released socket during error recovery\") added a mutex_lock() call for the queue->queue_lock in nvme_tcp_get_address(). However, the mutex_lock() races with mutex_destroy() in nvme_tcp_free_queue(), and causes the WARN below. DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: CPU: 3 PID: 34077 at kernel/locking/mutex.c:587 __mutex_lock+0xcf0/0x1220 Modules linked in: nvmet_tcp nvmet nvme_tcp nvme_fabrics iw_cm ib_cm ib_core pktcdvd nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables qrtr sunrpc ppdev 9pnet_virtio 9pnet pcspkr netfs parport_pc parport e1000 i2c_piix4 i2c_smbus loop fuse nfnetlink zram bochs drm_vram_helper drm_ttm_helper ttm drm_kms_helper xfs drm sym53c8xx floppy nvme scsi_transport_spi nvme_core nvme_auth serio_raw ata_generic pata_acpi dm_multipath qemu_fw_cfg [last unloaded: ib_uverbs] CPU: 3 UID: 0 PID: 34077 Comm: udisksd Not tainted 6.11.0-rc7 #319 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:__mutex_lock+0xcf0/0x1220 Code: 08 84 d2 0f 85 c8 04 00 00 8b 15 ef b6 c8 01 85 d2 0f 85 78 f4 ff ff 48 c7 c6 20 93 ee af 48 c7 c7 60 91 ee af e8 f0 a7 6d fd <0f> 0b e9 5e f4 ff ff 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 RSP: 0018:ffff88811305f760 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff88812c652058 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000001 RBP: ffff88811305f8b0 R08: 0000000000000001 R09: ffffed1075c36341 R10: ffff8883ae1b1a0b R11: 0000000000010498 R12: 0000000000000000 R13: 0000000000000000 R14: dffffc0000000000 R15: ffff88812c652058 FS: 00007f9713ae4980(0000) GS:ffff8883ae180000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcd78483c7c CR3: 0000000122c38000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn.cold+0x5b/0x1af ? __mutex_lock+0xcf0/0x1220 ? report_bug+0x1ec/0x390 ? handle_bug+0x3c/0x80 ? exc_invalid_op+0x13/0x40 ? asm_exc_invalid_op+0x16/0x20 ? __mutex_lock+0xcf0/0x1220 ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] ? __pfx___mutex_lock+0x10/0x10 ? __lock_acquire+0xd6a/0x59e0 ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] ? __pfx_nvme_tcp_get_address+0x10/0x10 [nvme_tcp] nvme_sysfs_show_address+0x81/0xc0 [nvme_core] dev_attr_show+0x42/0x80 ? __asan_memset+0x1f/0x40 sysfs_kf_seq_show+0x1f0/0x370 seq_read_iter+0x2cb/0x1130 ? rw_verify_area+0x3b1/0x590 ? __mutex_lock+0x433/0x1220 vfs_read+0x6a6/0xa20 ? lockdep_hardirqs_on+0x78/0x100 ? __pfx_vfs_read+0x10/0x10 ksys_read+0xf7/0x1d0 ? __pfx_ksys_read+0x10/0x10 ? __x64_sys_openat+0x105/0x1d0 do_syscall_64+0x93/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? __pfx_ksys_read+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? do_syscall_64+0x9f/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f9713f55cfa Code: 55 48 89 e5 48 83 ec 20 48 89 55 e8 48 89 75 f0 89 7d f8 e8 e8 74 f8 ff 48 8b 55 e8 48 8b 75 f0 4 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53095", "url": "https://ubuntu.com/security/CVE-2024-53095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix use-after-free of network namespace. Recently, we got a customer report that CIFS triggers oops while reconnecting to a server. [0] The workload runs on Kubernetes, and some pods mount CIFS servers in non-root network namespaces. The problem rarely happened, but it was always while the pod was dying. The root cause is wrong reference counting for network namespace. CIFS uses kernel sockets, which do not hold refcnt of the netns that the socket belongs to. That means CIFS must ensure the socket is always freed before its netns; otherwise, use-after-free happens. The repro steps are roughly: 1. mount CIFS in a non-root netns 2. drop packets from the netns 3. destroy the netns 4. unmount CIFS We can reproduce the issue quickly with the script [1] below and see the splat [2] if CONFIG_NET_NS_REFCNT_TRACKER is enabled. When the socket is TCP, it is hard to guarantee the netns lifetime without holding refcnt due to async timers. Let's hold netns refcnt for each socket as done for SMC in commit 9744d2bf1976 (\"smc: Fix use-after-free in tcp_write_timer_handler().\"). Note that we need to move put_net() from cifs_put_tcp_session() to clean_demultiplex_info(); otherwise, __sock_create() still could touch a freed netns while cifsd tries to reconnect from cifs_demultiplex_thread(). Also, maybe_get_net() cannot be put just before __sock_create() because the code is not under RCU and there is a small chance that the same address happened to be reallocated to another netns. [0]: CIFS: VFS: \\\\XXXXXXXXXXX has not responded in 15 seconds. Reconnecting... CIFS: Serverclose failed 4 times, giving up Unable to handle kernel paging request at virtual address 14de99e461f84a07 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 CM = 0, WnR = 0 [14de99e461f84a07] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: cls_bpf sch_ingress nls_utf8 cifs cifs_arc4 cifs_md4 dns_resolver tcp_diag inet_diag veth xt_state xt_connmark nf_conntrack_netlink xt_nat xt_statistic xt_MASQUERADE xt_mark xt_addrtype ipt_REJECT nf_reject_ipv4 nft_chain_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment nft_compat nf_tables nfnetlink overlay nls_ascii nls_cp437 sunrpc vfat fat aes_ce_blk aes_ce_cipher ghash_ce sm4_ce_cipher sm4 sm3_ce sm3 sha3_ce sha512_ce sha512_arm64 sha1_ce ena button sch_fq_codel loop fuse configfs dmi_sysfs sha2_ce sha256_arm64 dm_mirror dm_region_hash dm_log dm_mod dax efivarfs CPU: 5 PID: 2690970 Comm: cifsd Not tainted 6.1.103-109.184.amzn2023.aarch64 #1 Hardware name: Amazon EC2 r7g.4xlarge/, BIOS 1.0 11/1/2018 pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : fib_rules_lookup+0x44/0x238 lr : __fib_lookup+0x64/0xbc sp : ffff8000265db790 x29: ffff8000265db790 x28: 0000000000000000 x27: 000000000000bd01 x26: 0000000000000000 x25: ffff000b4baf8000 x24: ffff00047b5e4580 x23: ffff8000265db7e0 x22: 0000000000000000 x21: ffff00047b5e4500 x20: ffff0010e3f694f8 x19: 14de99e461f849f7 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 3f92800abd010002 x11: 0000000000000001 x10: ffff0010e3f69420 x9 : ffff800008a6f294 x8 : 0000000000000000 x7 : 0000000000000006 x6 : 0000000000000000 x5 : 0000000000000001 x4 : ffff001924354280 x3 : ffff8000265db7e0 x2 : 0000000000000000 x1 : ffff0010e3f694f8 x0 : ffff00047b5e4500 Call trace: fib_rules_lookup+0x44/0x238 __fib_lookup+0x64/0xbc ip_route_output_key_hash_rcu+0x2c4/0x398 ip_route_output_key_hash+0x60/0x8c tcp_v4_connect+0x290/0x488 __inet_stream_connect+0x108/0x3d0 inet_stream_connect+0x50/0x78 kernel_connect+0x6c/0xac generic_ip_conne ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-50265", "url": "https://ubuntu.com/security/CVE-2024-50265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove() Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove(): [ 57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12 [ 57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry [ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004 [...] [ 57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [...] [ 57.331328] Call Trace: [ 57.331477] [...] [ 57.333511] ? do_user_addr_fault+0x3e5/0x740 [ 57.333778] ? exc_page_fault+0x70/0x170 [ 57.334016] ? asm_exc_page_fault+0x2b/0x30 [ 57.334263] ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10 [ 57.334596] ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [ 57.334913] ocfs2_xa_remove_entry+0x23/0xc0 [ 57.335164] ocfs2_xa_set+0x704/0xcf0 [ 57.335381] ? _raw_spin_unlock+0x1a/0x40 [ 57.335620] ? ocfs2_inode_cache_unlock+0x16/0x20 [ 57.335915] ? trace_preempt_on+0x1e/0x70 [ 57.336153] ? start_this_handle+0x16c/0x500 [ 57.336410] ? preempt_count_sub+0x50/0x80 [ 57.336656] ? _raw_read_unlock+0x20/0x40 [ 57.336906] ? start_this_handle+0x16c/0x500 [ 57.337162] ocfs2_xattr_block_set+0xa6/0x1e0 [ 57.337424] __ocfs2_xattr_set_handle+0x1fd/0x5d0 [ 57.337706] ? ocfs2_start_trans+0x13d/0x290 [ 57.337971] ocfs2_xattr_set+0xb13/0xfb0 [ 57.338207] ? dput+0x46/0x1c0 [ 57.338393] ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338665] ? ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338948] __vfs_removexattr+0x92/0xc0 [ 57.339182] __vfs_removexattr_locked+0xd5/0x190 [ 57.339456] ? preempt_count_sub+0x50/0x80 [ 57.339705] vfs_removexattr+0x5f/0x100 [...] Reproducer uses faultinject facility to fail ocfs2_xa_remove() -> ocfs2_xa_value_truncate() with -ENOMEM. In this case the comment mentions that we can return 0 if ocfs2_xa_cleanup_value_truncate() is going to wipe the entry anyway. But the following 'rc' check is wrong and execution flow do 'ocfs2_xa_remove_entry(loc);' twice: * 1st: in ocfs2_xa_cleanup_value_truncate(); * 2nd: returning back to ocfs2_xa_remove() instead of going to 'out'. Fix this by skipping the 2nd removal of the same entry and making syzkaller repro happy.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50266", "url": "https://ubuntu.com/security/CVE-2024-50266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: qcom: videocc-sm8350: use HW_CTRL_TRIGGER for vcodec GDSCs A recent change in the venus driver results in a stuck clock on the Lenovo ThinkPad X13s, for example, when streaming video in firefox: \tvideo_cc_mvs0_clk status stuck at 'off' \tWARNING: CPU: 6 PID: 2885 at drivers/clk/qcom/clk-branch.c:87 clk_branch_wait+0x144/0x15c \t... \tCall trace: \t clk_branch_wait+0x144/0x15c \t clk_branch2_enable+0x30/0x40 \t clk_core_enable+0xd8/0x29c \t clk_enable+0x2c/0x4c \t vcodec_clks_enable.isra.0+0x94/0xd8 [venus_core] \t coreid_power_v4+0x464/0x628 [venus_core] \t vdec_start_streaming+0xc4/0x510 [venus_dec] \t vb2_start_streaming+0x6c/0x180 [videobuf2_common] \t vb2_core_streamon+0x120/0x1dc [videobuf2_common] \t vb2_streamon+0x1c/0x6c [videobuf2_v4l2] \t v4l2_m2m_ioctl_streamon+0x30/0x80 [v4l2_mem2mem] \t v4l_streamon+0x24/0x30 [videodev] using the out-of-tree sm8350/sc8280xp venus support. [1] Update also the sm8350/sc8280xp GDSC definitions so that the hw control mode can be changed at runtime as the venus driver now requires.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50267", "url": "https://ubuntu.com/security/CVE-2024-50267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: fix use after free in debug printk The \"dev_dbg(&urb->dev->dev, ...\" which happens after usb_free_urb(urb) is a use after free of the \"urb\" pointer. Store the \"dev\" pointer at the start of the function to avoid this issue.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50268", "url": "https://ubuntu.com/security/CVE-2024-50268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: fix potential out of bounds in ucsi_ccg_update_set_new_cam_cmd() The \"*cmd\" variable can be controlled by the user via debugfs. That means \"new_cam\" can be as high as 255 while the size of the uc->updated[] array is UCSI_MAX_ALTMODES (30). The call tree is: ucsi_cmd() // val comes from simple_attr_write_xsigned() -> ucsi_send_command() -> ucsi_send_command_common() -> ucsi_run_command() // calls ucsi->ops->sync_control() -> ucsi_ccg_sync_control()", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53083", "url": "https://ubuntu.com/security/CVE-2024-53083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: qcom-pmic: init value of hdr_len/txbuf_len earlier If the read of USB_PDPHY_RX_ACKNOWLEDGE_REG failed, then hdr_len and txbuf_len are uninitialized. This commit stops to print uninitialized value and misleading/false data.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50269", "url": "https://ubuntu.com/security/CVE-2024-50269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: musb: sunxi: Fix accessing an released usb phy Commit 6ed05c68cbca (\"usb: musb: sunxi: Explicitly release USB PHY on exit\") will cause that usb phy @glue->xceiv is accessed after released. 1) register platform driver @sunxi_musb_driver // get the usb phy @glue->xceiv sunxi_musb_probe() -> devm_usb_get_phy(). 2) register and unregister platform driver @musb_driver musb_probe() -> sunxi_musb_init() use the phy here //the phy is released here musb_remove() -> sunxi_musb_exit() -> devm_usb_put_phy() 3) register @musb_driver again musb_probe() -> sunxi_musb_init() use the phy here but the phy has been released at 2). ... Fixed by reverting the commit, namely, removing devm_usb_put_phy() from sunxi_musb_exit().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53079", "url": "https://ubuntu.com/security/CVE-2024-53079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/thp: fix deferred split unqueue naming and locking Recent changes are putting more pressure on THP deferred split queues: under load revealing long-standing races, causing list_del corruptions, \"Bad page state\"s and worse (I keep BUGs in both of those, so usually don't get to see how badly they end up without). The relevant recent changes being 6.8's mTHP, 6.10's mTHP swapout, and 6.12's mTHP swapin, improved swap allocation, and underused THP splitting. Before fixing locking: rename misleading folio_undo_large_rmappable(), which does not undo large_rmappable, to folio_unqueue_deferred_split(), which is what it does. But that and its out-of-line __callee are mm internals of very limited usability: add comment and WARN_ON_ONCEs to check usage; and return a bool to say if a deferred split was unqueued, which can then be used in WARN_ON_ONCEs around safety checks (sparing callers the arcane conditionals in __folio_unqueue_deferred_split()). Just omit the folio_unqueue_deferred_split() from free_unref_folios(), all of whose callers now call it beforehand (and if any forget then bad_page() will tell) - except for its caller put_pages_list(), which itself no longer has any callers (and will be deleted separately). Swapout: mem_cgroup_swapout() has been resetting folio->memcg_data 0 without checking and unqueueing a THP folio from deferred split list; which is unfortunate, since the split_queue_lock depends on the memcg (when memcg is enabled); so swapout has been unqueueing such THPs later, when freeing the folio, using the pgdat's lock instead: potentially corrupting the memcg's list. __remove_mapping() has frozen refcount to 0 here, so no problem with calling folio_unqueue_deferred_split() before resetting memcg_data. That goes back to 5.4 commit 87eaceb3faa5 (\"mm: thp: make deferred split shrinker memcg aware\"): which included a check on swapcache before adding to deferred queue, but no check on deferred queue before adding THP to swapcache. That worked fine with the usual sequence of events in reclaim (though there were a couple of rare ways in which a THP on deferred queue could have been swapped out), but 6.12 commit dafff3f4c850 (\"mm: split underused THPs\") avoids splitting underused THPs in reclaim, which makes swapcache THPs on deferred queue commonplace. Keep the check on swapcache before adding to deferred queue? Yes: it is no longer essential, but preserves the existing behaviour, and is likely to be a worthwhile optimization (vmstat showed much more traffic on the queue under swapping load if the check was removed); update its comment. Memcg-v1 move (deprecated): mem_cgroup_move_account() has been changing folio->memcg_data without checking and unqueueing a THP folio from the deferred list, sometimes corrupting \"from\" memcg's list, like swapout. Refcount is non-zero here, so folio_unqueue_deferred_split() can only be used in a WARN_ON_ONCE to validate the fix, which must be done earlier: mem_cgroup_move_charge_pte_range() first try to split the THP (splitting of course unqueues), or skip it if that fails. Not ideal, but moving charge has been requested, and khugepaged should repair the THP later: nobody wants new custom unqueueing code just for this deprecated case. The 87eaceb3faa5 commit did have the code to move from one deferred list to another (but was not conscious of its unsafety while refcount non-0); but that was removed by 5.6 commit fac0516b5534 (\"mm: thp: don't need care deferred split queue in memcg charge move path\"), which argued that the existence of a PMD mapping guarantees that the THP cannot be on a deferred list. As above, false in rare cases, and now commonly false. Backport to 6.11 should be straightforward. Earlier backports must take care that other _deferred_list fixes and dependencies are included. There is not a strong case for backports, but they can fix cornercases.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50270", "url": "https://ubuntu.com/security/CVE-2024-50270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: avoid overflow in damon_feed_loop_next_input() damon_feed_loop_next_input() is inefficient and fragile to overflows. Specifically, 'score_goal_diff_bp' calculation can overflow when 'score' is high. The calculation is actually unnecessary at all because 'goal' is a constant of value 10,000. Calculation of 'compensation' is again fragile to overflow. Final calculation of return value for under-achiving case is again fragile to overflow when the current score is under-achieving the target. Add two corner cases handling at the beginning of the function to make the body easier to read, and rewrite the body of the function to avoid overflows and the unnecessary bp value calcuation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50271", "url": "https://ubuntu.com/security/CVE-2024-50271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: signal: restore the override_rlimit logic Prior to commit d64696905554 (\"Reimplement RLIMIT_SIGPENDING on top of ucounts\") UCOUNT_RLIMIT_SIGPENDING rlimit was not enforced for a class of signals. However now it's enforced unconditionally, even if override_rlimit is set. This behavior change caused production issues. For example, if the limit is reached and a process receives a SIGSEGV signal, sigqueue_alloc fails to allocate the necessary resources for the signal delivery, preventing the signal from being delivered with siginfo. This prevents the process from correctly identifying the fault address and handling the error. From the user-space perspective, applications are unaware that the limit has been reached and that the siginfo is effectively 'corrupted'. This can lead to unpredictable behavior and crashes, as we observed with java applications. Fix this by passing override_rlimit into inc_rlimit_get_ucounts() and skip the comparison to max there if override_rlimit is set. This effectively restores the old behavior.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50272", "url": "https://ubuntu.com/security/CVE-2024-50272", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: filemap: Fix bounds checking in filemap_read() If the caller supplies an iocb->ki_pos value that is close to the filesystem upper limit, and an iterator with a count that causes us to overflow that limit, then filemap_read() enters an infinite loop. This behaviour was discovered when testing xfstests generic/525 with the \"localio\" optimisation for loopback NFS mounts.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53104", "url": "https://ubuntu.com/security/CVE-2024-53104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_parse_format This can lead to out of bounds writes since frames of this type were not taken into account when calculating the size of the frames buffer in uvc_parse_streaming.", "cve_priority": "high", "cve_public_date": "2024-12-02 08:15:00 UTC" }, { "cve": "CVE-2024-50273", "url": "https://ubuntu.com/security/CVE-2024-50273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reinitialize delayed ref list after deleting it from the list At insert_delayed_ref() if we need to update the action of an existing ref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head's ref_add_list using list_del(), which leaves the ref's add_list member not reinitialized, as list_del() sets the next and prev members of the list to LIST_POISON1 and LIST_POISON2, respectively. If later we end up calling drop_delayed_ref() against the ref, which can happen during merging or when destroying delayed refs due to a transaction abort, we can trigger a crash since at drop_delayed_ref() we call list_empty() against the ref's add_list, which returns false since the list was not reinitialized after the list_del() and as a consequence we call list_del() again at drop_delayed_ref(). This results in an invalid list access since the next and prev members are set to poison pointers, resulting in a splat if CONFIG_LIST_HARDENED and CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences otherwise. So fix this by deleting from the list with list_del_init() instead.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53064", "url": "https://ubuntu.com/security/CVE-2024-53064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix idpf_vc_core_init error path In an event where the platform running the device control plane is rebooted, reset is detected on the driver. It releases all the resources and waits for the reset to complete. Once the reset is done, it tries to build the resources back. At this time if the device control plane is not yet started, then the driver timeouts on the virtchnl message and retries to establish the mailbox again. In the retry flow, mailbox is deinitialized but the mailbox workqueue is still alive and polling for the mailbox message. This results in accessing the released control queue leading to null-ptr-deref. Fix it by unrolling the work queue cancellation and mailbox deinitialization in the reverse order which they got initialized.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50274", "url": "https://ubuntu.com/security/CVE-2024-50274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: avoid vport access in idpf_get_link_ksettings When the device control plane is removed or the platform running device control plane is rebooted, a reset is detected on the driver. On driver reset, it releases the resources and waits for the reset to complete. If the reset fails, it takes the error path and releases the vport lock. At this time if the monitoring tools tries to access link settings, it call traces for accessing released vport pointer. To avoid it, move link_speed_mbps to netdev_priv structure which removes the dependency on vport pointer and the vport lock in idpf_get_link_ksettings. Also use netif_carrier_ok() to check the link status and adjust the offsetof to use link_up instead of link_speed_mbps.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53065", "url": "https://ubuntu.com/security/CVE-2024-53065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/slab: fix warning caused by duplicate kmem_cache creation in kmem_buckets_create Commit b035f5a6d852 (\"mm: slab: reduce the kmalloc() minimum alignment if DMA bouncing possible\") reduced ARCH_KMALLOC_MINALIGN to 8 on arm64. However, with KASAN_HW_TAGS enabled, arch_slab_minalign() becomes 16. This causes kmalloc_caches[*][8] to be aliased to kmalloc_caches[*][16], resulting in kmem_buckets_create() attempting to create a kmem_cache for size 16 twice. This duplication triggers warnings on boot: [ 2.325108] ------------[ cut here ]------------ [ 2.325135] kmem_cache of name 'memdup_user-16' already exists [ 2.325783] WARNING: CPU: 0 PID: 1 at mm/slab_common.c:107 __kmem_cache_create_args+0xb8/0x3b0 [ 2.327957] Modules linked in: [ 2.328550] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5mm-unstable-arm64+ #12 [ 2.328683] Hardware name: QEMU QEMU Virtual Machine, BIOS 2024.02-2 03/11/2024 [ 2.328790] pstate: 61000009 (nZCv daif -PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 2.328911] pc : __kmem_cache_create_args+0xb8/0x3b0 [ 2.328930] lr : __kmem_cache_create_args+0xb8/0x3b0 [ 2.328942] sp : ffff800083d6fc50 [ 2.328961] x29: ffff800083d6fc50 x28: f2ff0000c1674410 x27: ffff8000820b0598 [ 2.329061] x26: 000000007fffffff x25: 0000000000000010 x24: 0000000000002000 [ 2.329101] x23: ffff800083d6fce8 x22: ffff8000832222e8 x21: ffff800083222388 [ 2.329118] x20: f2ff0000c1674410 x19: f5ff0000c16364c0 x18: ffff800083d80030 [ 2.329135] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 2.329152] x14: 0000000000000000 x13: 0a73747369786520 x12: 79646165726c6120 [ 2.329169] x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : 0000000000000000 [ 2.329194] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 [ 2.329210] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 2.329226] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 2.329291] Call trace: [ 2.329407] __kmem_cache_create_args+0xb8/0x3b0 [ 2.329499] kmem_buckets_create+0xfc/0x320 [ 2.329526] init_user_buckets+0x34/0x78 [ 2.329540] do_one_initcall+0x64/0x3c8 [ 2.329550] kernel_init_freeable+0x26c/0x578 [ 2.329562] kernel_init+0x3c/0x258 [ 2.329574] ret_from_fork+0x10/0x20 [ 2.329698] ---[ end trace 0000000000000000 ]--- [ 2.403704] ------------[ cut here ]------------ [ 2.404716] kmem_cache of name 'msg_msg-16' already exists [ 2.404801] WARNING: CPU: 2 PID: 1 at mm/slab_common.c:107 __kmem_cache_create_args+0xb8/0x3b0 [ 2.404842] Modules linked in: [ 2.404971] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.12.0-rc5mm-unstable-arm64+ #12 [ 2.405026] Tainted: [W]=WARN [ 2.405043] Hardware name: QEMU QEMU Virtual Machine, BIOS 2024.02-2 03/11/2024 [ 2.405057] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2.405079] pc : __kmem_cache_create_args+0xb8/0x3b0 [ 2.405100] lr : __kmem_cache_create_args+0xb8/0x3b0 [ 2.405111] sp : ffff800083d6fc50 [ 2.405115] x29: ffff800083d6fc50 x28: fbff0000c1674410 x27: ffff8000820b0598 [ 2.405135] x26: 000000000000ffd0 x25: 0000000000000010 x24: 0000000000006000 [ 2.405153] x23: ffff800083d6fce8 x22: ffff8000832222e8 x21: ffff800083222388 [ 2.405169] x20: fbff0000c1674410 x19: fdff0000c163d6c0 x18: ffff800083d80030 [ 2.405185] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 2.405201] x14: 0000000000000000 x13: 0a73747369786520 x12: 79646165726c6120 [ 2.405217] x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : 0000000000000000 [ 2.405233] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 [ 2.405248] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 2.405271] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 2.405287] Call trace: [ 2 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50275", "url": "https://ubuntu.com/security/CVE-2024-50275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64/sve: Discard stale CPU state when handling SVE traps The logic for handling SVE traps manipulates saved FPSIMD/SVE state incorrectly, and a race with preemption can result in a task having TIF_SVE set and TIF_FOREIGN_FPSTATE clear even though the live CPU state is stale (e.g. with SVE traps enabled). This has been observed to result in warnings from do_sve_acc() where SVE traps are not expected while TIF_SVE is set: | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* SVE access shouldn't have trapped */ Warnings of this form have been reported intermittently, e.g. https://lore.kernel.org/linux-arm-kernel/CA+G9fYtEGe_DhY2Ms7+L7NKsLYUomGsgqpdBj+QwDLeSg=JhGg@mail.gmail.com/ https://lore.kernel.org/linux-arm-kernel/000000000000511e9a060ce5a45c@google.com/ The race can occur when the SVE trap handler is preempted before and after manipulating the saved FPSIMD/SVE state, starting and ending on the same CPU, e.g. | void do_sve_acc(unsigned long esr, struct pt_regs *regs) | { | // Trap on CPU 0 with TIF_SVE clear, SVE 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(); | | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* SVE access shouldn't have trapped */ | | sve_init_regs() { | if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) { | ... | } else { | fpsimd_to_sve(current); | current->thread.fp_type = FP_STATE_SVE; | } | } | | 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 SVE 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.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50276", "url": "https://ubuntu.com/security/CVE-2024-50276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: vertexcom: mse102x: Fix possible double free of TX skb The scope of the TX skb is wider than just mse102x_tx_frame_spi(), so in case the TX skb room needs to be expanded, we should free the the temporary skb instead of the original skb. Otherwise the original TX skb pointer would be freed again in mse102x_tx_work(), which leads to crashes: Internal error: Oops: 0000000096000004 [#2] PREEMPT SMP CPU: 0 PID: 712 Comm: kworker/0:1 Tainted: G D 6.6.23 Hardware name: chargebyte Charge SOM DC-ONE (DT) Workqueue: events mse102x_tx_work [mse102x] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_release_data+0xb8/0x1d8 lr : skb_release_data+0x1ac/0x1d8 sp : ffff8000819a3cc0 x29: ffff8000819a3cc0 x28: ffff0000046daa60 x27: ffff0000057f2dc0 x26: ffff000005386c00 x25: 0000000000000002 x24: 00000000ffffffff x23: 0000000000000000 x22: 0000000000000001 x21: ffff0000057f2e50 x20: 0000000000000006 x19: 0000000000000000 x18: ffff00003fdacfcc x17: e69ad452d0c49def x16: 84a005feff870102 x15: 0000000000000000 x14: 000000000000024a x13: 0000000000000002 x12: 0000000000000000 x11: 0000000000000400 x10: 0000000000000930 x9 : ffff00003fd913e8 x8 : fffffc00001bc008 x7 : 0000000000000000 x6 : 0000000000000008 x5 : ffff00003fd91340 x4 : 0000000000000000 x3 : 0000000000000009 x2 : 00000000fffffffe x1 : 0000000000000000 x0 : 0000000000000000 Call trace: skb_release_data+0xb8/0x1d8 kfree_skb_reason+0x48/0xb0 mse102x_tx_work+0x164/0x35c [mse102x] process_one_work+0x138/0x260 worker_thread+0x32c/0x438 kthread+0x118/0x11c ret_from_fork+0x10/0x20 Code: aa1303e0 97fffab6 72001c1f 54000141 (f9400660)", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53066", "url": "https://ubuntu.com/security/CVE-2024-53066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfs: Fix KMSAN warning in decode_getfattr_attrs() Fix the following KMSAN warning: CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G B Tainted: [B]=BAD_PAGE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) ===================================================== ===================================================== BUG: KMSAN: uninit-value in decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_generic+0x806/0xb00 nfs4_xdr_dec_getattr+0x1de/0x240 rpcauth_unwrap_resp_decode+0xab/0x100 rpcauth_unwrap_resp+0x95/0xc0 call_decode+0x4ff/0xb50 __rpc_execute+0x57b/0x19d0 rpc_execute+0x368/0x5e0 rpc_run_task+0xcfe/0xee0 nfs4_proc_getattr+0x5b5/0x990 __nfs_revalidate_inode+0x477/0xd00 nfs_access_get_cached+0x1021/0x1cc0 nfs_do_access+0x9f/0xae0 nfs_permission+0x1e4/0x8c0 inode_permission+0x356/0x6c0 link_path_walk+0x958/0x1330 path_lookupat+0xce/0x6b0 filename_lookup+0x23e/0x770 vfs_statx+0xe7/0x970 vfs_fstatat+0x1f2/0x2c0 __se_sys_newfstatat+0x67/0x880 __x64_sys_newfstatat+0xbd/0x120 x64_sys_call+0x1826/0x3cf0 do_syscall_64+0xd0/0x1b0 entry_SYSCALL_64_after_hwframe+0x77/0x7f The KMSAN warning is triggered in decode_getfattr_attrs(), when calling decode_attr_mdsthreshold(). It appears that fattr->mdsthreshold is not initialized. Fix the issue by initializing fattr->mdsthreshold to NULL in nfs_fattr_init().", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53067", "url": "https://ubuntu.com/security/CVE-2024-53067", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Start the RTC update work later The RTC update work involves runtime resuming the UFS controller. Hence, only start the RTC update work after runtime power management in the UFS driver has been fully initialized. This patch fixes the following kernel crash: Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP Workqueue: events ufshcd_rtc_work Call trace: _raw_spin_lock_irqsave+0x34/0x8c (P) pm_runtime_get_if_active+0x24/0x9c (L) pm_runtime_get_if_active+0x24/0x9c ufshcd_rtc_work+0x138/0x1b4 process_one_work+0x148/0x288 worker_thread+0x2cc/0x3d4 kthread+0x110/0x114 ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50277", "url": "https://ubuntu.com/security/CVE-2024-50277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: fix a crash if blk_alloc_disk fails If blk_alloc_disk fails, the variable md->disk is set to an error value. cleanup_mapped_device will see that md->disk is non-NULL and it will attempt to access it, causing a crash on this statement \"md->disk->private_data = NULL;\".", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50278", "url": "https://ubuntu.com/security/CVE-2024-50278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix potential out-of-bounds access on the first resume Out-of-bounds access occurs if the fast device is expanded unexpectedly before the first-time resume of the cache table. This happens because expanding the fast device requires reloading the cache table for cache_create to allocate new in-core data structures that fit the new size, and the check in cache_preresume is not performed during the first resume, leading to the issue. Reproduce steps: 1. prepare component devices: 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\" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct 2. load a cache table of 512 cache blocks, and deliberately expand the fast device before resuming the cache, making the in-core data structures inadequate. dmsetup create cache --notable dmsetup reload cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" dmsetup reload cdata --table \"0 131072 linear /dev/sdc 8192\" dmsetup resume cdata dmsetup resume cache 3. suspend the cache to write out the in-core dirty bitset and hint array, leading to out-of-bounds access to the dirty bitset at offset 0x40: dmsetup suspend cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80 Read of size 8 at addr ffffc90000085040 by task dmsetup/90 (...snip...) The buggy address belongs to the virtual mapping at [ffffc90000085000, ffffc90000087000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by checking the size change on the first resume.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50279", "url": "https://ubuntu.com/security/CVE-2024-50279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix out-of-bounds access to the dirty bitset when resizing dm-cache checks the dirty bits of the cache blocks to be dropped when shrinking the fast device, but an index bug in bitset iteration causes out-of-bounds access. Reproduce steps: 1. create a cache device of 1024 cache blocks (128 bytes dirty bitset) dmsetup create cmeta --table \"0 8192 linear /dev/sdc 0\" dmsetup create cdata --table \"0 131072 linear /dev/sdc 8192\" dmsetup create corig --table \"0 524288 linear /dev/sdc 262144\" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" 2. shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80) dmsetup suspend cache dmsetup reload cdata --table \"0 65536 linear /dev/sdc 8192\" dmsetup resume cdata dmsetup resume cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131 (...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by making the index post-incremented.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50280", "url": "https://ubuntu.com/security/CVE-2024-50280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix flushing uninitialized delayed_work on cache_ctr error An unexpected WARN_ON from flush_work() may occur when cache creation fails, caused by destroying the uninitialized delayed_work waker in the error path of cache_create(). For example, the warning appears on the superblock checksum error. Reproduce steps: 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\" dd if=/dev/urandom of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" Kernel logs: (snip) WARNING: CPU: 0 PID: 84 at kernel/workqueue.c:4178 __flush_work+0x5d4/0x890 Fix by pulling out the cancel_delayed_work_sync() from the constructor's error path. This patch doesn't affect the use-after-free fix for concurrent dm_resume and dm_destroy (commit 6a459d8edbdb (\"dm cache: Fix UAF in destroy()\")) as cache_dtr is not changed.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50281", "url": "https://ubuntu.com/security/CVE-2024-50281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: trusted: dcp: fix NULL dereference in AEAD crypto operation When sealing or unsealing a key blob we currently do not wait for the AEAD cipher operation to finish and simply return after submitting the request. If there is some load on the system we can exit before the cipher operation is done and the buffer we read from/write to is already removed from the stack. This will e.g. result in NULL pointer dereference errors in the DCP driver during blob creation. Fix this by waiting for the AEAD cipher operation to finish before resuming the seal and unseal calls.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50282", "url": "https://ubuntu.com/security/CVE-2024-50282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read() Avoid a possible buffer overflow if size is larger than 4K. (cherry picked from commit f5d873f5825b40d886d03bd2aede91d4cf002434)", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53071", "url": "https://ubuntu.com/security/CVE-2024-53071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Be stricter about IO mapping flags The current panthor_device_mmap_io() implementation has two issues: 1. For mapping DRM_PANTHOR_USER_FLUSH_ID_MMIO_OFFSET, panthor_device_mmap_io() bails if VM_WRITE is set, but does not clear VM_MAYWRITE. That means userspace can use mprotect() to make the mapping writable later on. This is a classic Linux driver gotcha. I don't think this actually has any impact in practice: When the GPU is powered, writes to the FLUSH_ID seem to be ignored; and when the GPU is not powered, the dummy_latest_flush page provided by the driver is deliberately designed to not do any flushes, so the only thing writing to the dummy_latest_flush could achieve would be to make *more* flushes happen. 2. panthor_device_mmap_io() does not block MAP_PRIVATE mappings (which are mappings without the VM_SHARED flag). MAP_PRIVATE in combination with VM_MAYWRITE indicates that the VMA has copy-on-write semantics, which for VM_PFNMAP are semi-supported but fairly cursed. In particular, in such a mapping, the driver can only install PTEs during mmap() by calling remap_pfn_range() (because remap_pfn_range() wants to **store the physical address of the mapped physical memory into the vm_pgoff of the VMA**); installing PTEs later on with a fault handler (as panthor does) is not supported in private mappings, and so if you try to fault in such a mapping, vmf_insert_pfn_prot() splats when it hits a BUG() check. Fix it by clearing the VM_MAYWRITE flag (userspace writing to the FLUSH_ID doesn't make sense) and requiring VM_SHARED (copy-on-write semantics for the FLUSH_ID don't make sense). Reproducers for both scenarios are in the notes of my patch on the mailing list; I tested that these bugs exist on a Rock 5B machine. Note that I only compile-tested the patch, I haven't tested it; I don't have a working kernel build setup for the test machine yet. Please test it before applying it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53080", "url": "https://ubuntu.com/security/CVE-2024-53080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Lock XArray when getting entries for the VM Similar to commit cac075706f29 (\"drm/panthor: Fix race when converting group handle to group object\") we need to use the XArray's internal locking when retrieving a vm pointer from there. v2: Removed part of the patch that was trying to protect fetching the heap pointer from XArray, as that operation is protected by the @pool->lock.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53084", "url": "https://ubuntu.com/security/CVE-2024-53084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Break an object reference loop When remaining resources are being cleaned up on driver close, outstanding VM mappings may result in resources being leaked, due to an object reference loop, as shown below, with each object (or set of objects) referencing the object below it: PVR GEM Object GPU scheduler \"finished\" fence GPU scheduler “scheduled” fence PVR driver “done” fence PVR Context PVR VM Context PVR VM Mappings PVR GEM Object The reference that the PVR VM Context has on the VM mappings is a soft one, in the sense that the freeing of outstanding VM mappings is done as part of VM context destruction; no reference counts are involved, as is the case for all the other references in the loop. To break the reference loop during cleanup, free the outstanding VM mappings before destroying the PVR Context associated with the VM context.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53085", "url": "https://ubuntu.com/security/CVE-2024-53085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: Lock TPM chip in tpm_pm_suspend() first Setting TPM_CHIP_FLAG_SUSPENDED in the end of tpm_pm_suspend() can be racy according, as this leaves window for tpm_hwrng_read() to be called while the operation is in progress. The recent bug report gives also evidence of this behaviour. Aadress this by locking the TPM chip before checking any chip->flags both in tpm_pm_suspend() and tpm_hwrng_read(). Move TPM_CHIP_FLAG_SUSPENDED check inside tpm_get_random() so that it will be always checked only when the lock is reserved.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53086", "url": "https://ubuntu.com/security/CVE-2024-53086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Drop VM dma-resv lock on xe_sync_in_fence_get failure in exec IOCTL Upon failure all locks need to be dropped before returning to the user. (cherry picked from commit 7d1a4258e602ffdce529f56686925034c1b3b095)", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53087", "url": "https://ubuntu.com/security/CVE-2024-53087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix possible exec queue leak in exec IOCTL In a couple of places after an exec queue is looked up the exec IOCTL returns on input errors without dropping the exec queue ref. Fix this ensuring the exec queue ref is dropped on input error. (cherry picked from commit 07064a200b40ac2195cb6b7b779897d9377e5e6f)", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50283", "url": "https://ubuntu.com/security/CVE-2024-50283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-use-after-free in smb3_preauth_hash_rsp ksmbd_user_session_put should be called under smb3_preauth_hash_rsp(). It will avoid freeing session before calling smb3_preauth_hash_rsp().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50284", "url": "https://ubuntu.com/security/CVE-2024-50284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix the missing xa_store error check xa_store() can fail, it return xa_err(-EINVAL) if the entry cannot be stored in an XArray, or xa_err(-ENOMEM) if memory allocation failed, so check error for xa_store() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50285", "url": "https://ubuntu.com/security/CVE-2024-50285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: check outstanding simultaneous SMB operations If Client send simultaneous SMB operations to ksmbd, It exhausts too much memory through the \"ksmbd_work_cache”. It will cause OOM issue. ksmbd has a credit mechanism but it can't handle this problem. This patch add the check if it exceeds max credits to prevent this problem by assuming that one smb request consumes at least one credit.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50286", "url": "https://ubuntu.com/security/CVE-2024-50286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-use-after-free in ksmbd_smb2_session_create There is a race condition between ksmbd_smb2_session_create and ksmbd_expire_session. This patch add missing sessions_table_lock while adding/deleting session from global session table.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50287", "url": "https://ubuntu.com/security/CVE-2024-50287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-tpg: prevent the risk of a division by zero As reported by Coverity, the logic at tpg_precalculate_line() blindly rescales the buffer even when scaled_witdh is equal to zero. If this ever happens, this will cause a division by zero. Instead, add a WARN_ON_ONCE() to trigger such cases and return without doing any precalculation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50288", "url": "https://ubuntu.com/security/CVE-2024-50288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: fix buffer overwrite when using > 32 buffers The maximum number of buffers that can be requested was increased to 64 for the video capture queue. But video capture used a must_blank array that was still sized for 32 (VIDEO_MAX_FRAME). This caused an out-of-bounds write when using buffer indices >= 32. Create a new define MAX_VID_CAP_BUFFERS that is used to access the must_blank array and set max_num_buffers for the video capture queue. This solves a crash reported by: \thttps://bugzilla.kernel.org/show_bug.cgi?id=219258", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50289", "url": "https://ubuntu.com/security/CVE-2024-50289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: av7110: fix a spectre vulnerability As warned by smatch: \tdrivers/staging/media/av7110/av7110_ca.c:270 dvb_ca_ioctl() warn: potential spectre issue 'av7110->ci_slot' [w] (local cap) There is a spectre-related vulnerability at the code. Fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50290", "url": "https://ubuntu.com/security/CVE-2024-50290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx24116: prevent overflows on SNR calculus as reported by Coverity, if reading SNR registers fail, a negative number will be returned, causing an underflow when reading SNR registers. Prevent that.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53061", "url": "https://ubuntu.com/security/CVE-2024-53061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: s5p-jpeg: prevent buffer overflows The current logic allows word to be less than 2. If this happens, there will be buffer overflows, as reported by smatch. Add extra checks to prevent it. While here, remove an unused word = 0 assignment.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53081", "url": "https://ubuntu.com/security/CVE-2024-53081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ar0521: don't overflow when checking PLL values The PLL checks are comparing 64 bit integers with 32 bit ones, as reported by Coverity. Depending on the values of the variables, this may underflow. Fix it ensuring that both sides of the expression are u64.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53062", "url": "https://ubuntu.com/security/CVE-2024-53062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mgb4: protect driver against spectre Frequency range is set from sysfs via frequency_range_store(), being vulnerable to spectre, as reported by smatch: \tdrivers/media/pci/mgb4/mgb4_cmt.c:231 mgb4_cmt_set_vin_freq_range() warn: potential spectre issue 'cmt_vals_in' [r] \tdrivers/media/pci/mgb4/mgb4_cmt.c:238 mgb4_cmt_set_vin_freq_range() warn: possible spectre second half. 'reg_set' Fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50291", "url": "https://ubuntu.com/security/CVE-2024-50291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvb-core: add missing buffer index check dvb_vb2_expbuf() didn't check if the given buffer index was for a valid buffer. Add this check.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50292", "url": "https://ubuntu.com/security/CVE-2024-50292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: stm32: spdifrx: fix dma channel release in stm32_spdifrx_remove In case of error when requesting ctrl_chan DMA channel, ctrl_chan is not null. So the release of the dma channel leads to the following issue: [ 4.879000] st,stm32-spdifrx 500d0000.audio-controller: dma_request_slave_channel error -19 [ 4.888975] Unable to handle kernel NULL pointer dereference at virtual address 000000000000003d [...] [ 5.096577] Call trace: [ 5.099099] dma_release_channel+0x24/0x100 [ 5.103235] stm32_spdifrx_remove+0x24/0x60 [snd_soc_stm32_spdifrx] [ 5.109494] stm32_spdifrx_probe+0x320/0x4c4 [snd_soc_stm32_spdifrx] To avoid this issue, release channel only if the pointer is valid.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53063", "url": "https://ubuntu.com/security/CVE-2024-53063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvbdev: prevent the risk of out of memory access The dvbdev contains a static variable used to store dvb minors. The behavior of it depends if CONFIG_DVB_DYNAMIC_MINORS is set or not. When not set, dvb_register_device() won't check for boundaries, as it will rely that a previous call to dvb_register_adapter() would already be enforcing it. On a similar way, dvb_device_open() uses the assumption that the register functions already did the needed checks. This can be fragile if some device ends using different calls. This also generate warnings on static check analysers like Coverity. So, add explicit guards to prevent potential risk of OOM issues.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50293", "url": "https://ubuntu.com/security/CVE-2024-50293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: do not leave a dangling sk pointer in __smc_create() Thanks to commit 4bbd360a5084 (\"socket: Print pf->create() when it does not clear sock->sk on failure.\"), syzbot found an issue with AF_SMC: smc_create must clear sock->sk on failure, family: 43, type: 1, protocol: 0 WARNING: CPU: 0 PID: 5827 at net/socket.c:1565 __sock_create+0x96f/0xa30 net/socket.c:1563 Modules linked in: CPU: 0 UID: 0 PID: 5827 Comm: syz-executor259 Not tainted 6.12.0-rc6-next-20241106-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:__sock_create+0x96f/0xa30 net/socket.c:1563 Code: 03 00 74 08 4c 89 e7 e8 4f 3b 85 f8 49 8b 34 24 48 c7 c7 40 89 0c 8d 8b 54 24 04 8b 4c 24 0c 44 8b 44 24 08 e8 32 78 db f7 90 <0f> 0b 90 90 e9 d3 fd ff ff 89 e9 80 e1 07 fe c1 38 c1 0f 8c ee f7 RSP: 0018:ffffc90003e4fda0 EFLAGS: 00010246 RAX: 099c6f938c7f4700 RBX: 1ffffffff1a595fd RCX: ffff888034823c00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 00000000ffffffe9 R08: ffffffff81567052 R09: 1ffff920007c9f50 R10: dffffc0000000000 R11: fffff520007c9f51 R12: ffffffff8d2cafe8 R13: 1ffffffff1a595fe R14: ffffffff9a789c40 R15: ffff8880764298c0 FS: 000055557b518380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa62ff43225 CR3: 0000000031628000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: sock_create net/socket.c:1616 [inline] __sys_socket_create net/socket.c:1653 [inline] __sys_socket+0x150/0x3c0 net/socket.c:1700 __do_sys_socket net/socket.c:1714 [inline] __se_sys_socket net/socket.c:1712 [inline] For reference, see commit 2d859aff775d (\"Merge branch 'do-not-leave-dangling-sk-pointers-in-pf-create-functions'\")", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50294", "url": "https://ubuntu.com/security/CVE-2024-50294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix missing locking causing hanging calls If a call gets aborted (e.g. because kafs saw a signal) between it being queued for connection and the I/O thread picking up the call, the abort will be prioritised over the connection and it will be removed from local->new_client_calls by rxrpc_disconnect_client_call() without a lock being held. This may cause other calls on the list to disappear if a race occurs. Fix this by taking the client_call_lock when removing a call from whatever list its ->wait_link happens to be on.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50295", "url": "https://ubuntu.com/security/CVE-2024-50295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: arc: fix the device for dma_map_single/dma_unmap_single The ndev->dev and pdev->dev aren't the same device, use ndev->dev.parent which has dma_mask, ndev->dev.parent is just pdev->dev. Or it would cause the following issue: [ 39.933526] ------------[ cut here ]------------ [ 39.938414] WARNING: CPU: 1 PID: 501 at kernel/dma/mapping.c:149 dma_map_page_attrs+0x90/0x1f8", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53082", "url": "https://ubuntu.com/security/CVE-2024-53082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_net: Add hash_key_length check Add hash_key_length check in virtnet_probe() to avoid possible out of bound errors when setting/reading the hash key.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50296", "url": "https://ubuntu.com/security/CVE-2024-50296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash when uninstalling driver When the driver is uninstalled and the VF is disabled concurrently, a kernel crash occurs. The reason is that the two actions call function pci_disable_sriov(). The num_VFs is checked to determine whether to release the corresponding resources. During the second calling, num_VFs is not 0 and the resource release function is called. However, the corresponding resource has been released during the first invoking. Therefore, the problem occurs: [15277.839633][T50670] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ... [15278.131557][T50670] Call trace: [15278.134686][T50670] klist_put+0x28/0x12c [15278.138682][T50670] klist_del+0x14/0x20 [15278.142592][T50670] device_del+0xbc/0x3c0 [15278.146676][T50670] pci_remove_bus_device+0x84/0x120 [15278.151714][T50670] pci_stop_and_remove_bus_device+0x6c/0x80 [15278.157447][T50670] pci_iov_remove_virtfn+0xb4/0x12c [15278.162485][T50670] sriov_disable+0x50/0x11c [15278.166829][T50670] pci_disable_sriov+0x24/0x30 [15278.171433][T50670] hnae3_unregister_ae_algo_prepare+0x60/0x90 [hnae3] [15278.178039][T50670] hclge_exit+0x28/0xd0 [hclge] [15278.182730][T50670] __se_sys_delete_module.isra.0+0x164/0x230 [15278.188550][T50670] __arm64_sys_delete_module+0x1c/0x30 [15278.193848][T50670] invoke_syscall+0x50/0x11c [15278.198278][T50670] el0_svc_common.constprop.0+0x158/0x164 [15278.203837][T50670] do_el0_svc+0x34/0xcc [15278.207834][T50670] el0_svc+0x20/0x30 For details, see the following figure. rmmod hclge disable VFs ---------------------------------------------------- hclge_exit() sriov_numvfs_store() ... device_lock() pci_disable_sriov() hns3_pci_sriov_configure() pci_disable_sriov() sriov_disable() sriov_disable() if !num_VFs : if !num_VFs : return; return; sriov_del_vfs() sriov_del_vfs() ... ... klist_put() klist_put() ... ... num_VFs = 0; num_VFs = 0; device_unlock(); In this patch, when driver is removing, we get the device_lock() to protect num_VFs, just like sriov_numvfs_store().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53088", "url": "https://ubuntu.com/security/CVE-2024-53088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: fix race condition by adding filter's intermediate sync state Fix a race condition in the i40e driver that leads to MAC/VLAN filters becoming corrupted and leaking. Address the issue that occurs under heavy load when multiple threads are concurrently modifying MAC/VLAN filters by setting mac and port VLAN. 1. Thread T0 allocates a filter in i40e_add_filter() within i40e_ndo_set_vf_port_vlan(). 2. Thread T1 concurrently frees the filter in __i40e_del_filter() within i40e_ndo_set_vf_mac(). 3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which refers to the already freed filter memory, causing corruption. Reproduction steps: 1. Spawn multiple VFs. 2. Apply a concurrent heavy load by running parallel operations to change MAC addresses on the VFs and change port VLANs on the host. 3. Observe errors in dmesg: \"Error I40E_AQ_RC_ENOSPC adding RX filters on VF XX, \tplease set promiscuous on manually for VF XX\". Exact code for stable reproduction Intel can't open-source now. The fix involves implementing a new intermediate filter state, I40E_FILTER_NEW_SYNC, for the time when a filter is on a tmp_add_list. These filters cannot be deleted from the hash list directly but must be removed using the full process.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50297", "url": "https://ubuntu.com/security/CVE-2024-50297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: xilinx: axienet: Enqueue Tx packets in dql before dmaengine starts Enqueue packets in dql after dma engine starts causes race condition. Tx transfer starts once dma engine is started and may execute dql dequeue in completion before it gets queued. It results in following kernel crash while running iperf stress test: kernel BUG at lib/dynamic_queue_limits.c:99! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP pc : dql_completed+0x238/0x248 lr : dql_completed+0x3c/0x248 Call trace: dql_completed+0x238/0x248 axienet_dma_tx_cb+0xa0/0x170 xilinx_dma_do_tasklet+0xdc/0x290 tasklet_action_common+0xf8/0x11c tasklet_action+0x30/0x3c handle_softirqs+0xf8/0x230 Start dmaengine after enqueue in dql fixes the crash.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50298", "url": "https://ubuntu.com/security/CVE-2024-50298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: enetc: allocate vf_state during PF probes In the previous implementation, vf_state is allocated memory only when VF is enabled. However, net_device_ops::ndo_set_vf_mac() may be called before VF is enabled to configure the MAC address of VF. If this is the case, enetc_pf_set_vf_mac() will access vf_state, resulting in access to a null pointer. The simplified error log is as follows. root@ls1028ardb:~# ip link set eno0 vf 1 mac 00:0c:e7:66:77:89 [ 173.543315] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 [ 173.637254] pc : enetc_pf_set_vf_mac+0x3c/0x80 Message from sy [ 173.641973] lr : do_setlink+0x4a8/0xec8 [ 173.732292] Call trace: [ 173.734740] enetc_pf_set_vf_mac+0x3c/0x80 [ 173.738847] __rtnl_newlink+0x530/0x89c [ 173.742692] rtnl_newlink+0x50/0x7c [ 173.746189] rtnetlink_rcv_msg+0x128/0x390 [ 173.750298] netlink_rcv_skb+0x60/0x130 [ 173.754145] rtnetlink_rcv+0x18/0x24 [ 173.757731] netlink_unicast+0x318/0x380 [ 173.761665] netlink_sendmsg+0x17c/0x3c8", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50299", "url": "https://ubuntu.com/security/CVE-2024-50299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: properly validate chunk size in sctp_sf_ootb() A size validation fix similar to that in Commit 50619dbf8db7 (\"sctp: add size validation when walking chunks\") is also required in sctp_sf_ootb() to address a crash reported by syzbot: BUG: KMSAN: uninit-value in sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_do_sm+0x181/0x93d0 net/sctp/sm_sideeffect.c:1166 sctp_endpoint_bh_rcv+0xc38/0xf90 net/sctp/endpointola.c:407 sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88 sctp_rcv+0x3831/0x3b20 net/sctp/input.c:243 sctp4_rcv+0x42/0x50 net/sctp/protocol.c:1159 ip_protocol_deliver_rcu+0xb51/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50300", "url": "https://ubuntu.com/security/CVE-2024-50300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: rtq2208: Fix uninitialized use of regulator_config Fix rtq2208 driver uninitialized use to cause kernel error.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50301", "url": "https://ubuntu.com/security/CVE-2024-50301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: security/keys: fix slab-out-of-bounds in key_task_permission KASAN reports an out of bounds read: BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline] BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362 CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0x107/0x167 lib/dump_stack.c:123 print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 __kuid_val include/linux/uidgid.h:36 [inline] uid_eq include/linux/uidgid.h:63 [inline] key_task_permission+0x394/0x410 security/keys/permission.c:54 search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793 This issue was also reported by syzbot. It can be reproduced by following these steps(more details [1]): 1. Obtain more than 32 inputs that have similar hashes, which ends with the pattern '0xxxxxxxe6'. 2. Reboot and add the keys obtained in step 1. The reproducer demonstrates how this issue happened: 1. In the search_nested_keyrings function, when it iterates through the slots in a node(below tag ascend_to_node), if the slot pointer is meta and node->back_pointer != NULL(it means a root), it will proceed to descend_to_node. However, there is an exception. If node is the root, and one of the slots points to a shortcut, it will be treated as a keyring. 2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function. However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as ASSOC_ARRAY_PTR_SUBTYPE_MASK. 3. When 32 keys with the similar hashes are added to the tree, the ROOT has keys with hashes that are not similar (e.g. slot 0) and it splits NODE A without using a shortcut. When NODE A is filled with keys that all hashes are xxe6, the keys are similar, NODE A will split with a shortcut. Finally, it forms the tree as shown below, where slot 6 points to a shortcut. NODE A +------>+---+ ROOT | | 0 | xxe6 +---+ | +---+ xxxx | 0 | shortcut : : xxe6 +---+ | +---+ xxe6 : : | | | xxe6 +---+ | +---+ | 6 |---+ : : xxe6 +---+ +---+ xxe6 : : | f | xxe6 +---+ +---+ xxe6 | f | +---+ 4. As mentioned above, If a slot(slot 6) of the root points to a shortcut, it may be mistakenly transferred to a key*, leading to a read out-of-bounds read. To fix this issue, one should jump to descend_to_node if the ptr is a shortcut, regardless of whether the node is root or not. [1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/ [jarkko: tweaked the commit message a bit to have an appropriate closes tag.]", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53072", "url": "https://ubuntu.com/security/CVE-2024-53072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/pmc: Detect when STB is not available Loading the amd_pmc module as: amd_pmc enable_stb=1 ...can result in the following messages in the kernel ring buffer: amd_pmc AMDI0009:00: SMU cmd failed. err: 0xff ioremap on RAM at 0x0000000000000000 - 0x0000000000ffffff WARNING: CPU: 10 PID: 2151 at arch/x86/mm/ioremap.c:217 __ioremap_caller+0x2cd/0x340 Further debugging reveals that this occurs when the requests for S2D_PHYS_ADDR_LOW and S2D_PHYS_ADDR_HIGH return a value of 0, indicating that the STB is inaccessible. To prevent the ioremap warning and provide clarity to the user, handle the invalid address and display an error message.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50302", "url": "https://ubuntu.com/security/CVE-2024-50302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: zero-initialize the report buffer Since the report buffer is used by all kinds of drivers in various ways, let's zero-initialize it during allocation to make sure that it can't be ever used to leak kernel memory via specially-crafted report.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53068", "url": "https://ubuntu.com/security/CVE-2024-53068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix slab-use-after-free in scmi_bus_notifier() The scmi_dev->name is released prematurely in __scmi_device_destroy(), which causes slab-use-after-free when accessing scmi_dev->name in scmi_bus_notifier(). So move the release of scmi_dev->name to scmi_device_release() to avoid slab-use-after-free. | BUG: KASAN: slab-use-after-free in strncmp+0xe4/0xec | Read of size 1 at addr ffffff80a482bcc0 by task swapper/0/1 | | CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.6.38-debug #1 | Hardware name: Qualcomm Technologies, Inc. SA8775P Ride (DT) | Call trace: | dump_backtrace+0x94/0x114 | show_stack+0x18/0x24 | dump_stack_lvl+0x48/0x60 | print_report+0xf4/0x5b0 | kasan_report+0xa4/0xec | __asan_report_load1_noabort+0x20/0x2c | strncmp+0xe4/0xec | scmi_bus_notifier+0x5c/0x54c | notifier_call_chain+0xb4/0x31c | blocking_notifier_call_chain+0x68/0x9c | bus_notify+0x54/0x78 | device_del+0x1bc/0x840 | device_unregister+0x20/0xb4 | __scmi_device_destroy+0xac/0x280 | scmi_device_destroy+0x94/0xd0 | scmi_chan_setup+0x524/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20 | | Allocated by task 1: | kasan_save_stack+0x2c/0x54 | kasan_set_track+0x2c/0x40 | kasan_save_alloc_info+0x24/0x34 | __kasan_kmalloc+0xa0/0xb8 | __kmalloc_node_track_caller+0x6c/0x104 | kstrdup+0x48/0x84 | kstrdup_const+0x34/0x40 | __scmi_device_create.part.0+0x8c/0x408 | scmi_device_create+0x104/0x370 | scmi_chan_setup+0x2a0/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20 | | Freed by task 1: | kasan_save_stack+0x2c/0x54 | kasan_set_track+0x2c/0x40 | kasan_save_free_info+0x38/0x5c | __kasan_slab_free+0xe8/0x164 | __kmem_cache_free+0x11c/0x230 | kfree+0x70/0x130 | kfree_const+0x20/0x40 | __scmi_device_destroy+0x70/0x280 | scmi_device_destroy+0x94/0xd0 | scmi_chan_setup+0x524/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53069", "url": "https://ubuntu.com/security/CVE-2024-53069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: qcom: scm: fix a NULL-pointer dereference Some SCM calls can be invoked with __scm being NULL (the driver may not have been and will not be probed as there's no SCM entry in device-tree). Make sure we don't dereference a NULL pointer.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50212", "url": "https://ubuntu.com/security/CVE-2024-50212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib: alloc_tag_module_unload must wait for pending kfree_rcu calls Ben Greear reports following splat: ------------[ cut here ]------------ net/netfilter/nf_nat_core.c:1114 module nf_nat func:nf_nat_register_fn has 256 allocated at module unload WARNING: CPU: 1 PID: 10421 at lib/alloc_tag.c:168 alloc_tag_module_unload+0x22b/0x3f0 Modules linked in: nf_nat(-) btrfs ufs qnx4 hfsplus hfs minix vfat msdos fat ... Hardware name: Default string Default string/SKYBAY, BIOS 5.12 08/04/2020 RIP: 0010:alloc_tag_module_unload+0x22b/0x3f0 codetag_unload_module+0x19b/0x2a0 ? codetag_load_module+0x80/0x80 nf_nat module exit calls kfree_rcu on those addresses, but the free operation is likely still pending by the time alloc_tag checks for leaks. Wait for outstanding kfree_rcu operations to complete before checking resolves this warning. Reproducer: unshare -n iptables-nft -t nat -A PREROUTING -p tcp grep nf_nat /proc/allocinfo # will list 4 allocations rmmod nft_chain_nat rmmod nf_nat # will WARN. [akpm@linux-foundation.org: add comment]", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53046", "url": "https://ubuntu.com/security/CVE-2024-53046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: dts: imx8ulp: correct the flexspi compatible string The flexspi on imx8ulp only has 16 LUTs, and imx8mm flexspi has 32 LUTs, so correct the compatible string here, otherwise will meet below error: [ 1.119072] ------------[ cut here ]------------ [ 1.123926] WARNING: CPU: 0 PID: 1 at drivers/spi/spi-nxp-fspi.c:855 nxp_fspi_exec_op+0xb04/0xb64 [ 1.133239] Modules linked in: [ 1.136448] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-rc6-next-20240902-00001-g131bf9439dd9 #69 [ 1.146821] Hardware name: NXP i.MX8ULP EVK (DT) [ 1.151647] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.158931] pc : nxp_fspi_exec_op+0xb04/0xb64 [ 1.163496] lr : nxp_fspi_exec_op+0xa34/0xb64 [ 1.168060] sp : ffff80008002b2a0 [ 1.171526] x29: ffff80008002b2d0 x28: 0000000000000000 x27: 0000000000000000 [ 1.179002] x26: ffff2eb645542580 x25: ffff800080610014 x24: ffff800080610000 [ 1.186480] x23: ffff2eb645548080 x22: 0000000000000006 x21: ffff2eb6455425e0 [ 1.193956] x20: 0000000000000000 x19: ffff80008002b5e0 x18: ffffffffffffffff [ 1.201432] x17: ffff2eb644467508 x16: 0000000000000138 x15: 0000000000000002 [ 1.208907] x14: 0000000000000000 x13: ffff2eb6400d8080 x12: 00000000ffffff00 [ 1.216378] x11: 0000000000000000 x10: ffff2eb6400d8080 x9 : ffff2eb697adca80 [ 1.223850] x8 : ffff2eb697ad3cc0 x7 : 0000000100000000 x6 : 0000000000000001 [ 1.231324] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000007a6 [ 1.238795] x2 : 0000000000000000 x1 : 00000000000001ce x0 : 00000000ffffff92 [ 1.246267] Call trace: [ 1.248824] nxp_fspi_exec_op+0xb04/0xb64 [ 1.253031] spi_mem_exec_op+0x3a0/0x430 [ 1.257139] spi_nor_read_id+0x80/0xcc [ 1.261065] spi_nor_scan+0x1ec/0xf10 [ 1.264901] spi_nor_probe+0x108/0x2fc [ 1.268828] spi_mem_probe+0x6c/0xbc [ 1.272574] spi_probe+0x84/0xe4 [ 1.275958] really_probe+0xbc/0x29c [ 1.279713] __driver_probe_device+0x78/0x12c [ 1.284277] driver_probe_device+0xd8/0x15c [ 1.288660] __device_attach_driver+0xb8/0x134 [ 1.293316] bus_for_each_drv+0x88/0xe8 [ 1.297337] __device_attach+0xa0/0x190 [ 1.301353] device_initial_probe+0x14/0x20 [ 1.305734] bus_probe_device+0xac/0xb0 [ 1.309752] device_add+0x5d0/0x790 [ 1.313408] __spi_add_device+0x134/0x204 [ 1.317606] of_register_spi_device+0x3b4/0x590 [ 1.322348] spi_register_controller+0x47c/0x754 [ 1.327181] devm_spi_register_controller+0x4c/0xa4 [ 1.332289] nxp_fspi_probe+0x1cc/0x2b0 [ 1.336307] platform_probe+0x68/0xc4 [ 1.340145] really_probe+0xbc/0x29c [ 1.343893] __driver_probe_device+0x78/0x12c [ 1.348457] driver_probe_device+0xd8/0x15c [ 1.352838] __driver_attach+0x90/0x19c [ 1.356857] bus_for_each_dev+0x7c/0xdc [ 1.360877] driver_attach+0x24/0x30 [ 1.364624] bus_add_driver+0xe4/0x208 [ 1.368552] driver_register+0x5c/0x124 [ 1.372573] __platform_driver_register+0x28/0x34 [ 1.377497] nxp_fspi_driver_init+0x1c/0x28 [ 1.381888] do_one_initcall+0x80/0x1c8 [ 1.385908] kernel_init_freeable+0x1c4/0x28c [ 1.390472] kernel_init+0x20/0x1d8 [ 1.394138] ret_from_fork+0x10/0x20 [ 1.397885] ---[ end trace 0000000000000000 ]--- [ 1.407908] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53052", "url": "https://ubuntu.com/security/CVE-2024-53052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/rw: fix missing NOWAIT check for O_DIRECT start write When io_uring starts a write, it'll call kiocb_start_write() to bump the super block rwsem, preventing any freezes from happening while that write is in-flight. The freeze side will grab that rwsem for writing, excluding any new writers from happening and waiting for existing writes to finish. But io_uring unconditionally uses kiocb_start_write(), which will block if someone is currently attempting to freeze the mount point. This causes a deadlock where freeze is waiting for previous writes to complete, but the previous writes cannot complete, as the task that is supposed to complete them is blocked waiting on starting a new write. This results in the following stuck trace showing that dependency with the write blocked starting a new write: task:fio state:D stack:0 pid:886 tgid:886 ppid:876 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_rwsem_wait+0x1e8/0x3f8 __percpu_down_read+0xe8/0x500 io_write+0xbb8/0xff8 io_issue_sqe+0x10c/0x1020 io_submit_sqes+0x614/0x2110 __arm64_sys_io_uring_enter+0x524/0x1038 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 INFO: task fsfreeze:7364 blocked for more than 15 seconds. Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963 with the attempting freezer stuck trying to grab the rwsem: task:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_down_write+0x2b0/0x680 freeze_super+0x248/0x8a8 do_vfs_ioctl+0x149c/0x1b18 __arm64_sys_ioctl+0xd0/0x1a0 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 Fix this by having the io_uring side honor IOCB_NOWAIT, and only attempt a blocking grab of the super block rwsem if it isn't set. For normal issue where IOCB_NOWAIT would always be set, this returns -EAGAIN which will have io_uring core issue a blocking attempt of the write. That will in turn also get completions run, ensuring forward progress. Since freezing requires CAP_SYS_ADMIN in the first place, this isn't something that can be triggered by a regular user.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50213", "url": "https://ubuntu.com/security/CVE-2024-50213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tests: hdmi: Fix memory leaks in drm_display_mode_from_cea_vic() modprobe drm_hdmi_state_helper_test and then rmmod it, the following memory leak occurs. The `mode` allocated in drm_mode_duplicate() called by drm_display_mode_from_cea_vic() is not freed, which cause the memory leak: \tunreferenced object 0xffffff80ccd18100 (size 128): \t comm \"kunit_try_catch\", pid 1851, jiffies 4295059695 \t hex dump (first 32 bytes): \t 57 62 00 00 80 02 90 02 f0 02 20 03 00 00 e0 01 Wb........ ..... \t ea 01 ec 01 0d 02 00 00 0a 00 00 00 00 00 00 00 ................ \t backtrace (crc c2f1aa95): \t [<000000000f10b11b>] kmemleak_alloc+0x34/0x40 \t [<000000001cd4cf73>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<00000000f1f3cffa>] drm_mode_duplicate+0x44/0x19c \t [<000000008cbeef13>] drm_display_mode_from_cea_vic+0x88/0x98 \t [<0000000019daaacf>] 0xffffffedc11ae69c \t [<000000000aad0f85>] kunit_try_run_case+0x13c/0x3ac \t [<00000000a9210bac>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<000000000a0b2e9e>] kthread+0x2e8/0x374 \t [<00000000bd668858>] ret_from_fork+0x10/0x20 \t...... Free `mode` by using drm_kunit_display_mode_from_cea_vic() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50214", "url": "https://ubuntu.com/security/CVE-2024-50214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/connector: hdmi: Fix memory leak in drm_display_mode_from_cea_vic() modprobe drm_connector_test and then rmmod drm_connector_test, the following memory leak occurs. The `mode` allocated in drm_mode_duplicate() called by drm_display_mode_from_cea_vic() is not freed, which cause the memory leak: \tunreferenced object 0xffffff80cb0ee400 (size 128): \t comm \"kunit_try_catch\", pid 1948, jiffies 4294950339 \t hex dump (first 32 bytes): \t 14 44 02 00 80 07 d8 07 04 08 98 08 00 00 38 04 .D............8. \t 3c 04 41 04 65 04 00 00 05 00 00 00 00 00 00 00 <.A.e........... \t backtrace (crc 90e9585c): \t [<00000000ec42e3d7>] kmemleak_alloc+0x34/0x40 \t [<00000000d0ef055a>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<00000000c2062161>] drm_mode_duplicate+0x44/0x19c \t [<00000000f96c74aa>] drm_display_mode_from_cea_vic+0x88/0x98 \t [<00000000d8f2c8b4>] 0xffffffdc982a4868 \t [<000000005d164dbc>] kunit_try_run_case+0x13c/0x3ac \t [<000000006fb23398>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<000000006ea56ca0>] kthread+0x2e8/0x374 \t [<000000000676063f>] ret_from_fork+0x10/0x20 \t...... Free `mode` by using drm_kunit_display_mode_from_cea_vic() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50215", "url": "https://ubuntu.com/security/CVE-2024-50215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: assign dh_key to NULL after kfree_sensitive ctrl->dh_key might be used across multiple calls to nvmet_setup_dhgroup() for the same controller. So it's better to nullify it after release on error path in order to avoid double free later in nvmet_destroy_auth(). Found by Linux Verification Center (linuxtesting.org) with Svace.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50216", "url": "https://ubuntu.com/security/CVE-2024-50216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix finding a last resort AG in xfs_filestream_pick_ag When the main loop in xfs_filestream_pick_ag fails to find a suitable AG it tries to just pick the online AG. But the loop for that uses args->pag as loop iterator while the later code expects pag to be set. Fix this by reusing the max_pag case for this last resort, and also add a check for impossible case of no AG just to make sure that the uninitialized pag doesn't even escape in theory.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50217", "url": "https://ubuntu.com/security/CVE-2024-50217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free of block device file in __btrfs_free_extra_devids() Mounting btrfs from two images (which have the same one fsid and two different dev_uuids) in certain executing order may trigger an UAF for variable 'device->bdev_file' in __btrfs_free_extra_devids(). And following are the details: 1. Attach image_1 to loop0, attach image_2 to loop1, and scan btrfs devices by ioctl(BTRFS_IOC_SCAN_DEV): / btrfs_device_1 ? loop0 fs_device \\ btrfs_device_2 ? loop1 2. mount /dev/loop0 /mnt btrfs_open_devices btrfs_device_1->bdev_file = btrfs_get_bdev_and_sb(loop0) btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree fail: btrfs_close_devices // -ENOMEM \t btrfs_close_bdev(btrfs_device_1) fput(btrfs_device_1->bdev_file) \t // btrfs_device_1->bdev_file is freed \t btrfs_close_bdev(btrfs_device_2) fput(btrfs_device_2->bdev_file) 3. mount /dev/loop1 /mnt btrfs_open_devices btrfs_get_bdev_and_sb(&bdev_file) // EIO, btrfs_device_1->bdev_file is not assigned, // which points to a freed memory area btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree btrfs_free_extra_devids if (btrfs_device_1->bdev_file) fput(btrfs_device_1->bdev_file) // UAF ! Fix it by setting 'device->bdev_file' as 'NULL' after closing the btrfs_device in btrfs_close_one_device().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53043", "url": "https://ubuntu.com/security/CVE-2024-53043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mctp i2c: handle NULL header address daddr can be NULL if there is no neighbour table entry present, in that case the tx packet should be dropped. saddr will usually be set by MCTP core, but check for NULL in case a packet is transmitted by a different protocol.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50303", "url": "https://ubuntu.com/security/CVE-2024-50303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: resource,kexec: walk_system_ram_res_rev must retain resource flags walk_system_ram_res_rev() erroneously discards resource flags when passing the information to the callback. This causes systems with IORESOURCE_SYSRAM_DRIVER_MANAGED memory to have these resources selected during kexec to store kexec buffers if that memory happens to be at placed above normal system ram. This leads to undefined behavior after reboot. If the kexec buffer is never touched, nothing happens. If the kexec buffer is touched, it could lead to a crash (like below) or undefined behavior. Tested on a system with CXL memory expanders with driver managed memory, TPM enabled, and CONFIG_IMA_KEXEC=y. Adding printk's showed the flags were being discarded and as a result the check for IORESOURCE_SYSRAM_DRIVER_MANAGED passes. find_next_iomem_res: name(System RAM (kmem)) \t\t start(10000000000) \t\t end(1034fffffff) \t\t flags(83000200) locate_mem_hole_top_down: start(10000000000) end(1034fffffff) flags(0) [.] BUG: unable to handle page fault for address: ffff89834ffff000 [.] #PF: supervisor read access in kernel mode [.] #PF: error_code(0x0000) - not-present page [.] PGD c04c8bf067 P4D c04c8bf067 PUD c04c8be067 PMD 0 [.] Oops: 0000 [#1] SMP [.] RIP: 0010:ima_restore_measurement_list+0x95/0x4b0 [.] RSP: 0018:ffffc900000d3a80 EFLAGS: 00010286 [.] RAX: 0000000000001000 RBX: 0000000000000000 RCX: ffff89834ffff000 [.] RDX: 0000000000000018 RSI: ffff89834ffff000 RDI: ffff89834ffff018 [.] RBP: ffffc900000d3ba0 R08: 0000000000000020 R09: ffff888132b8a900 [.] R10: 4000000000000000 R11: 000000003a616d69 R12: 0000000000000000 [.] R13: ffffffff8404ac28 R14: 0000000000000000 R15: ffff89834ffff000 [.] FS: 0000000000000000(0000) GS:ffff893d44640000(0000) knlGS:0000000000000000 [.] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [.] ata5: SATA link down (SStatus 0 SControl 300) [.] CR2: ffff89834ffff000 CR3: 000001034d00f001 CR4: 0000000000770ef0 [.] PKRU: 55555554 [.] Call Trace: [.] [.] ? __die+0x78/0xc0 [.] ? page_fault_oops+0x2a8/0x3a0 [.] ? exc_page_fault+0x84/0x130 [.] ? asm_exc_page_fault+0x22/0x30 [.] ? ima_restore_measurement_list+0x95/0x4b0 [.] ? template_desc_init_fields+0x317/0x410 [.] ? crypto_alloc_tfm_node+0x9c/0xc0 [.] ? init_ima_lsm+0x30/0x30 [.] ima_load_kexec_buffer+0x72/0xa0 [.] ima_init+0x44/0xa0 [.] __initstub__kmod_ima__373_1201_init_ima7+0x1e/0xb0 [.] ? init_ima_lsm+0x30/0x30 [.] do_one_initcall+0xad/0x200 [.] ? idr_alloc_cyclic+0xaa/0x110 [.] ? new_slab+0x12c/0x420 [.] ? new_slab+0x12c/0x420 [.] ? number+0x12a/0x430 [.] ? sysvec_apic_timer_interrupt+0xa/0x80 [.] ? asm_sysvec_apic_timer_interrupt+0x16/0x20 [.] ? parse_args+0xd4/0x380 [.] ? parse_args+0x14b/0x380 [.] kernel_init_freeable+0x1c1/0x2b0 [.] ? rest_init+0xb0/0xb0 [.] kernel_init+0x16/0x1a0 [.] ret_from_fork+0x2f/0x40 [.] ? rest_init+0xb0/0xb0 [.] ret_from_fork_asm+0x11/0x20 [.] ", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50218", "url": "https://ubuntu.com/security/CVE-2024-50218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow Syzbot reported a kernel BUG in ocfs2_truncate_inline. There are two reasons for this: first, the parameter value passed is greater than ocfs2_max_inline_data_with_xattr, second, the start and end parameters of ocfs2_truncate_inline are \"unsigned int\". So, we need to add a sanity check for byte_start and byte_len right before ocfs2_truncate_inline() in ocfs2_remove_inode_range(), if they are greater than ocfs2_max_inline_data_with_xattr return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50219", "url": "https://ubuntu.com/security/CVE-2024-50219", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50263", "url": "https://ubuntu.com/security/CVE-2024-50263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fork: only invoke khugepaged, ksm hooks if no error There is no reason to invoke these hooks early against an mm that is in an incomplete state. The change in commit d24062914837 (\"fork: use __mt_dup() to duplicate maple tree in dup_mmap()\") makes this more pertinent as we may be in a state where entries in the maple tree are not yet consistent. Their placement early in dup_mmap() only appears to have been meaningful for early error checking, and since functionally it'd require a very small allocation to fail (in practice 'too small to fail') that'd only occur in the most dire circumstances, meaning the fork would fail or be OOM'd in any case. Since both khugepaged and KSM tracking are there to provide optimisations to memory performance rather than critical functionality, it doesn't really matter all that much if, under such dire memory pressure, we fail to register an mm with these. As a result, we follow the example of commit d2081b2bf819 (\"mm: khugepaged: make khugepaged_enter() void function\") and make ksm_fork() a void function also. We only expose the mm to these functions once we are done with them and only if no error occurred in the fork operation.", "cve_priority": "medium", "cve_public_date": "2024-11-11 14:15:00 UTC" }, { "cve": "CVE-2024-50220", "url": "https://ubuntu.com/security/CVE-2024-50220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fork: do not invoke uffd on fork if error occurs Patch series \"fork: do not expose incomplete mm on fork\". During fork we may place the virtual memory address space into an inconsistent state before the fork operation is complete. In addition, we may encounter an error during the fork operation that indicates that the virtual memory address space is invalidated. As a result, we should not be exposing it in any way to external machinery that might interact with the mm or VMAs, machinery that is not designed to deal with incomplete state. We specifically update the fork logic to defer khugepaged and ksm to the end of the operation and only to be invoked if no error arose, and disallow uffd from observing fork events should an error have occurred. This patch (of 2): Currently on fork we expose the virtual address space of a process to userland unconditionally if uffd is registered in VMAs, regardless of whether an error arose in the fork. This is performed in dup_userfaultfd_complete() which is invoked unconditionally, and performs two duties - invoking registered handlers for the UFFD_EVENT_FORK event via dup_fctx(), and clearing down userfaultfd_fork_ctx objects established in dup_userfaultfd(). This is problematic, because the virtual address space may not yet be correctly initialised if an error arose. The change in commit d24062914837 (\"fork: use __mt_dup() to duplicate maple tree in dup_mmap()\") makes this more pertinent as we may be in a state where entries in the maple tree are not yet consistent. We address this by, on fork error, ensuring that we roll back state that we would otherwise expect to clean up through the event being handled by userland and perform the memory freeing duty otherwise performed by dup_userfaultfd_complete(). We do this by implementing a new function, dup_userfaultfd_fail(), which performs the same loop, only decrementing reference counts. Note that we perform mmgrab() on the parent and child mm's, however userfaultfd_ctx_put() will mmdrop() this once the reference count drops to zero, so we will avoid memory leaks correctly here.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53047", "url": "https://ubuntu.com/security/CVE-2024-53047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: init: protect sched with rcu_read_lock Enabling CONFIG_PROVE_RCU_LIST with its dependence CONFIG_RCU_EXPERT creates this splat when an MPTCP socket is created: ============================= WARNING: suspicious RCU usage 6.12.0-rc2+ #11 Not tainted ----------------------------- net/mptcp/sched.c:44 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 no locks held by mptcp_connect/176. stack backtrace: CPU: 0 UID: 0 PID: 176 Comm: mptcp_connect Not tainted 6.12.0-rc2+ #11 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl (lib/dump_stack.c:123) lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822) mptcp_sched_find (net/mptcp/sched.c:44 (discriminator 7)) mptcp_init_sock (net/mptcp/protocol.c:2867 (discriminator 1)) ? sock_init_data_uid (arch/x86/include/asm/atomic.h:28) inet_create.part.0.constprop.0 (net/ipv4/af_inet.c:386) ? __sock_create (include/linux/rcupdate.h:347 (discriminator 1)) __sock_create (net/socket.c:1576) __sys_socket (net/socket.c:1671) ? __pfx___sys_socket (net/socket.c:1712) ? do_user_addr_fault (arch/x86/mm/fault.c:1419 (discriminator 1)) __x64_sys_socket (net/socket.c:1728) do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) That's because when the socket is initialised, rcu_read_lock() is not used despite the explicit comment written above the declaration of mptcp_sched_find() in sched.c. Adding the missing lock/unlock avoids the warning.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50221", "url": "https://ubuntu.com/security/CVE-2024-50221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Vangogh: Fix kernel memory out of bounds write KASAN reports that the GPU metrics table allocated in vangogh_tables_init() is not large enough for the memset done in smu_cmn_init_soft_gpu_metrics(). Condensed report follows: [ 33.861314] BUG: KASAN: slab-out-of-bounds in smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu] [ 33.861799] Write of size 168 at addr ffff888129f59500 by task mangoapp/1067 ... [ 33.861808] CPU: 6 UID: 1000 PID: 1067 Comm: mangoapp Tainted: G W 6.12.0-rc4 #356 1a56f59a8b5182eeaf67eb7cb8b13594dd23b544 [ 33.861816] Tainted: [W]=WARN [ 33.861818] Hardware name: Valve Galileo/Galileo, BIOS F7G0107 12/01/2023 [ 33.861822] Call Trace: [ 33.861826] [ 33.861829] dump_stack_lvl+0x66/0x90 [ 33.861838] print_report+0xce/0x620 [ 33.861853] kasan_report+0xda/0x110 [ 33.862794] kasan_check_range+0xfd/0x1a0 [ 33.862799] __asan_memset+0x23/0x40 [ 33.862803] smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.863306] vangogh_get_gpu_metrics_v2_4+0x123/0xad0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.864257] vangogh_common_get_gpu_metrics+0xb0c/0xbc0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.865682] amdgpu_dpm_get_gpu_metrics+0xcc/0x110 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.866160] amdgpu_get_gpu_metrics+0x154/0x2d0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.867135] dev_attr_show+0x43/0xc0 [ 33.867147] sysfs_kf_seq_show+0x1f1/0x3b0 [ 33.867155] seq_read_iter+0x3f8/0x1140 [ 33.867173] vfs_read+0x76c/0xc50 [ 33.867198] ksys_read+0xfb/0x1d0 [ 33.867214] do_syscall_64+0x90/0x160 ... [ 33.867353] Allocated by task 378 on cpu 7 at 22.794876s: [ 33.867358] kasan_save_stack+0x33/0x50 [ 33.867364] kasan_save_track+0x17/0x60 [ 33.867367] __kasan_kmalloc+0x87/0x90 [ 33.867371] vangogh_init_smc_tables+0x3f9/0x840 [amdgpu] [ 33.867835] smu_sw_init+0xa32/0x1850 [amdgpu] [ 33.868299] amdgpu_device_init+0x467b/0x8d90 [amdgpu] [ 33.868733] amdgpu_driver_load_kms+0x19/0xf0 [amdgpu] [ 33.869167] amdgpu_pci_probe+0x2d6/0xcd0 [amdgpu] [ 33.869608] local_pci_probe+0xda/0x180 [ 33.869614] pci_device_probe+0x43f/0x6b0 Empirically we can confirm that the former allocates 152 bytes for the table, while the latter memsets the 168 large block. Root cause appears that when GPU metrics tables for v2_4 parts were added it was not considered to enlarge the table to fit. The fix in this patch is rather \"brute force\" and perhaps later should be done in a smarter way, by extracting and consolidating the part version to size logic to a common helper, instead of brute forcing the largest possible allocation. Nevertheless, for now this works and fixes the out of bounds write. v2: * Drop impossible v3_0 case. (Mario) (cherry picked from commit 0880f58f9609f0200483a49429af0f050d281703)", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50222", "url": "https://ubuntu.com/security/CVE-2024-50222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iov_iter: fix copy_page_from_iter_atomic() if KMAP_LOCAL_FORCE_MAP generic/077 on x86_32 CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP=y with highmem, on huge=always tmpfs, issues a warning and then hangs (interruptibly): WARNING: CPU: 5 PID: 3517 at mm/highmem.c:622 kunmap_local_indexed+0x62/0xc9 CPU: 5 UID: 0 PID: 3517 Comm: cp Not tainted 6.12.0-rc4 #2 ... copy_page_from_iter_atomic+0xa6/0x5ec generic_perform_write+0xf6/0x1b4 shmem_file_write_iter+0x54/0x67 Fix copy_page_from_iter_atomic() by limiting it in that case (include/linux/skbuff.h skb_frag_must_loop() does similar). But going forward, perhaps CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP is too surprising, has outlived its usefulness, and should just be removed?", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50223", "url": "https://ubuntu.com/security/CVE-2024-50223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/numa: Fix the potential null pointer dereference in task_numa_work() When running stress-ng-vm-segv test, we found a null pointer dereference error in task_numa_work(). Here is the backtrace: [323676.066985] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ...... [323676.067108] CPU: 35 PID: 2694524 Comm: stress-ng-vm-se ...... [323676.067113] pstate: 23401009 (nzCv daif +PAN -UAO +TCO +DIT +SSBS BTYPE=--) [323676.067115] pc : vma_migratable+0x1c/0xd0 [323676.067122] lr : task_numa_work+0x1ec/0x4e0 [323676.067127] sp : ffff8000ada73d20 [323676.067128] x29: ffff8000ada73d20 x28: 0000000000000000 x27: 000000003e89f010 [323676.067130] x26: 0000000000080000 x25: ffff800081b5c0d8 x24: ffff800081b27000 [323676.067133] x23: 0000000000010000 x22: 0000000104d18cc0 x21: ffff0009f7158000 [323676.067135] x20: 0000000000000000 x19: 0000000000000000 x18: ffff8000ada73db8 [323676.067138] x17: 0001400000000000 x16: ffff800080df40b0 x15: 0000000000000035 [323676.067140] x14: ffff8000ada73cc8 x13: 1fffe0017cc72001 x12: ffff8000ada73cc8 [323676.067142] x11: ffff80008001160c x10: ffff000be639000c x9 : ffff8000800f4ba4 [323676.067145] x8 : ffff000810375000 x7 : ffff8000ada73974 x6 : 0000000000000001 [323676.067147] x5 : 0068000b33e26707 x4 : 0000000000000001 x3 : ffff0009f7158000 [323676.067149] x2 : 0000000000000041 x1 : 0000000000004400 x0 : 0000000000000000 [323676.067152] Call trace: [323676.067153] vma_migratable+0x1c/0xd0 [323676.067155] task_numa_work+0x1ec/0x4e0 [323676.067157] task_work_run+0x78/0xd8 [323676.067161] do_notify_resume+0x1ec/0x290 [323676.067163] el0_svc+0x150/0x160 [323676.067167] el0t_64_sync_handler+0xf8/0x128 [323676.067170] el0t_64_sync+0x17c/0x180 [323676.067173] Code: d2888001 910003fd f9000bf3 aa0003f3 (f9401000) [323676.067177] SMP: stopping secondary CPUs [323676.070184] Starting crashdump kernel... stress-ng-vm-segv in stress-ng is used to stress test the SIGSEGV error handling function of the system, which tries to cause a SIGSEGV error on return from unmapping the whole address space of the child process. Normally this program will not cause kernel crashes. But before the munmap system call returns to user mode, a potential task_numa_work() for numa balancing could be added and executed. In this scenario, since the child process has no vma after munmap, the vma_next() in task_numa_work() will return a null pointer even if the vma iterator restarts from 0. Recheck the vma pointer before dereferencing it in task_numa_work().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53053", "url": "https://ubuntu.com/security/CVE-2024-53053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Fix another deadlock during RTC update If ufshcd_rtc_work calls ufshcd_rpm_put_sync() and the pm's usage_count is 0, we will enter the runtime suspend callback. However, the runtime suspend callback will wait to flush ufshcd_rtc_work, causing a deadlock. Replace ufshcd_rpm_put_sync() with ufshcd_rpm_put() to avoid the deadlock.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53075", "url": "https://ubuntu.com/security/CVE-2024-53075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv: Prevent a bad reference count on CPU nodes When populating cache leaves we previously fetched the CPU device node at the very beginning. But when ACPI is enabled we go through a specific branch which returns early and does not call 'of_node_put' for the node that was acquired. Since we are not using a CPU device node for the ACPI code anyways, we can simply move the initialization of it just passed the ACPI block, and we are guaranteed to have an 'of_node_put' call for the acquired node. This prevents a bad reference count of the CPU device node. Moreover, the previous function did not check for errors when acquiring the device node, so a return -ENOENT has been added for that case.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50224", "url": "https://ubuntu.com/security/CVE-2024-50224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: spi-fsl-dspi: Fix crash when not using GPIO chip select Add check for the return value of spi_get_csgpiod() to avoid passing a NULL pointer to gpiod_direction_output(), preventing a crash when GPIO chip select is not used. Fix below crash: [ 4.251960] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 4.260762] Mem abort info: [ 4.263556] ESR = 0x0000000096000004 [ 4.267308] EC = 0x25: DABT (current EL), IL = 32 bits [ 4.272624] SET = 0, FnV = 0 [ 4.275681] EA = 0, S1PTW = 0 [ 4.278822] FSC = 0x04: level 0 translation fault [ 4.283704] Data abort info: [ 4.286583] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 4.292074] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 4.297130] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 4.302445] [0000000000000000] user address but active_mm is swapper [ 4.308805] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 4.315072] Modules linked in: [ 4.318124] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc4-next-20241023-00008-ga20ec42c5fc1 #359 [ 4.328130] Hardware name: LS1046A QDS Board (DT) [ 4.332832] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 4.339794] pc : gpiod_direction_output+0x34/0x5c [ 4.344505] lr : gpiod_direction_output+0x18/0x5c [ 4.349208] sp : ffff80008003b8f0 [ 4.352517] x29: ffff80008003b8f0 x28: 0000000000000000 x27: ffffc96bcc7e9068 [ 4.359659] x26: ffffc96bcc6e00b0 x25: ffffc96bcc598398 x24: ffff447400132810 [ 4.366800] x23: 0000000000000000 x22: 0000000011e1a300 x21: 0000000000020002 [ 4.373940] x20: 0000000000000000 x19: 0000000000000000 x18: ffffffffffffffff [ 4.381081] x17: ffff44740016e600 x16: 0000000500000003 x15: 0000000000000007 [ 4.388221] x14: 0000000000989680 x13: 0000000000020000 x12: 000000000000001e [ 4.395362] x11: 0044b82fa09b5a53 x10: 0000000000000019 x9 : 0000000000000008 [ 4.402502] x8 : 0000000000000002 x7 : 0000000000000007 x6 : 0000000000000000 [ 4.409641] x5 : 0000000000000200 x4 : 0000000002000000 x3 : 0000000000000000 [ 4.416781] x2 : 0000000000022202 x1 : 0000000000000000 x0 : 0000000000000000 [ 4.423921] Call trace: [ 4.426362] gpiod_direction_output+0x34/0x5c (P) [ 4.431067] gpiod_direction_output+0x18/0x5c (L) [ 4.435771] dspi_setup+0x220/0x334", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50225", "url": "https://ubuntu.com/security/CVE-2024-50225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix error propagation of split bios The purpose of btrfs_bbio_propagate_error() shall be propagating an error of split bio to its original btrfs_bio, and tell the error to the upper layer. However, it's not working well on some cases. * Case 1. Immediate (or quick) end_bio with an error When btrfs sends btrfs_bio to mirrored devices, btrfs calls btrfs_bio_end_io() when all the mirroring bios are completed. If that btrfs_bio was split, it is from btrfs_clone_bioset and its end_io function is btrfs_orig_write_end_io. For this case, btrfs_bbio_propagate_error() accesses the orig_bbio's bio context to increase the error count. That works well in most cases. However, if the end_io is called enough fast, orig_bbio's (remaining part after split) bio context may not be properly set at that time. Since the bio context is set when the orig_bbio (the last btrfs_bio) is sent to devices, that might be too late for earlier split btrfs_bio's completion. That will result in NULL pointer dereference. That bug is easily reproducible by running btrfs/146 on zoned devices [1] and it shows the following trace. [1] You need raid-stripe-tree feature as it create \"-d raid0 -m raid1\" FS. BUG: kernel NULL pointer dereference, address: 0000000000000020 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 UID: 0 PID: 13 Comm: kworker/u32:1 Not tainted 6.11.0-rc7-BTRFS-ZNS+ #474 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Workqueue: writeback wb_workfn (flush-btrfs-5) RIP: 0010:btrfs_bio_end_io+0xae/0xc0 [btrfs] BTRFS error (device dm-0): bdev /dev/mapper/error-test errs: wr 2, rd 0, flush 0, corrupt 0, gen 0 RSP: 0018:ffffc9000006f248 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888005a7f080 RCX: ffffc9000006f1dc RDX: 0000000000000000 RSI: 000000000000000a RDI: ffff888005a7f080 RBP: ffff888011dfc540 R08: 0000000000000000 R09: 0000000000000001 R10: ffffffff82e508e0 R11: 0000000000000005 R12: ffff88800ddfbe58 R13: ffff888005a7f080 R14: ffff888005a7f158 R15: ffff888005a7f158 FS: 0000000000000000(0000) GS:ffff88803ea80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000020 CR3: 0000000002e22006 CR4: 0000000000370ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __die_body.cold+0x19/0x26 ? page_fault_oops+0x13e/0x2b0 ? _printk+0x58/0x73 ? do_user_addr_fault+0x5f/0x750 ? exc_page_fault+0x76/0x240 ? asm_exc_page_fault+0x22/0x30 ? btrfs_bio_end_io+0xae/0xc0 [btrfs] ? btrfs_log_dev_io_error+0x7f/0x90 [btrfs] btrfs_orig_write_end_io+0x51/0x90 [btrfs] dm_submit_bio+0x5c2/0xa50 [dm_mod] ? find_held_lock+0x2b/0x80 ? blk_try_enter_queue+0x90/0x1e0 __submit_bio+0xe0/0x130 ? ktime_get+0x10a/0x160 ? lockdep_hardirqs_on+0x74/0x100 submit_bio_noacct_nocheck+0x199/0x410 btrfs_submit_bio+0x7d/0x150 [btrfs] btrfs_submit_chunk+0x1a1/0x6d0 [btrfs] ? lockdep_hardirqs_on+0x74/0x100 ? __folio_start_writeback+0x10/0x2c0 btrfs_submit_bbio+0x1c/0x40 [btrfs] submit_one_bio+0x44/0x60 [btrfs] submit_extent_folio+0x13f/0x330 [btrfs] ? btrfs_set_range_writeback+0xa3/0xd0 [btrfs] extent_writepage_io+0x18b/0x360 [btrfs] extent_write_locked_range+0x17c/0x340 [btrfs] ? __pfx_end_bbio_data_write+0x10/0x10 [btrfs] run_delalloc_cow+0x71/0xd0 [btrfs] btrfs_run_delalloc_range+0x176/0x500 [btrfs] ? find_lock_delalloc_range+0x119/0x260 [btrfs] writepage_delalloc+0x2ab/0x480 [btrfs] extent_write_cache_pages+0x236/0x7d0 [btrfs] btrfs_writepages+0x72/0x130 [btrfs] do_writepages+0xd4/0x240 ? find_held_lock+0x2b/0x80 ? wbc_attach_and_unlock_inode+0x12c/0x290 ? wbc_attach_and_unlock_inode+0x12c/0x29 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53054", "url": "https://ubuntu.com/security/CVE-2024-53054", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50226", "url": "https://ubuntu.com/security/CVE-2024-50226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cxl/port: Fix use-after-free, permit out-of-order decoder shutdown In support of investigating an initialization failure report [1], cxl_test was updated to register mock memory-devices after the mock root-port/bus device had been registered. That led to cxl_test crashing with a use-after-free bug with the following signature: cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem0:decoder7.0 @ 0 next: cxl_switch_uport.0 nr_eps: 1 nr_targets: 1 cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem4:decoder14.0 @ 1 next: cxl_switch_uport.0 nr_eps: 2 nr_targets: 1 cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[0] = cxl_switch_dport.0 for mem0:decoder7.0 @ 0 1) cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[1] = cxl_switch_dport.4 for mem4:decoder14.0 @ 1 [..] cxld_unregister: cxl decoder14.0: cxl_region_decode_reset: cxl_region region3: mock_decoder_reset: cxl_port port3: decoder3.0 reset 2) mock_decoder_reset: cxl_port port3: decoder3.0: out of order reset, expected decoder3.1 cxl_endpoint_decoder_release: cxl decoder14.0: [..] cxld_unregister: cxl decoder7.0: 3) cxl_region_decode_reset: cxl_region region3: Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6bc3: 0000 [#1] PREEMPT SMP PTI [..] RIP: 0010:to_cxl_port+0x8/0x60 [cxl_core] [..] Call Trace: cxl_region_decode_reset+0x69/0x190 [cxl_core] cxl_region_detach+0xe8/0x210 [cxl_core] cxl_decoder_kill_region+0x27/0x40 [cxl_core] cxld_unregister+0x5d/0x60 [cxl_core] At 1) a region has been established with 2 endpoint decoders (7.0 and 14.0). Those endpoints share a common switch-decoder in the topology (3.0). At teardown, 2), decoder14.0 is the first to be removed and hits the \"out of order reset case\" in the switch decoder. The effect though is that region3 cleanup is aborted leaving it in-tact and referencing decoder14.0. At 3) the second attempt to teardown region3 trips over the stale decoder14.0 object which has long since been deleted. The fix here is to recognize that the CXL specification places no mandate on in-order shutdown of switch-decoders, the driver enforces in-order allocation, and hardware enforces in-order commit. So, rather than fail and leave objects dangling, always remove them. In support of making cxl_region_decode_reset() always succeed, cxl_region_invalidate_memregion() failures are turned into warnings. Crashing the kernel is ok there since system integrity is at risk if caches cannot be managed around physical address mutation events like CXL region destruction. A new device_for_each_child_reverse_from() is added to cleanup port->commit_end after all dependent decoders have been disabled. In other words if decoders are allocated 0->1->2 and disabled 1->2->0 then port->commit_end only decrements from 2 after 2 has been disabled, and it decrements all the way to zero since 1 was disabled previously.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50227", "url": "https://ubuntu.com/security/CVE-2024-50227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Fix KASAN reported stack out-of-bounds read in tb_retimer_scan() KASAN reported following issue: BUG: KASAN: stack-out-of-bounds in tb_retimer_scan+0xffe/0x1550 [thunderbolt] Read of size 4 at addr ffff88810111fc1c by task kworker/u56:0/11 CPU: 0 UID: 0 PID: 11 Comm: kworker/u56:0 Tainted: G U 6.11.0+ #1387 Tainted: [U]=USER Workqueue: thunderbolt0 tb_handle_hotplug [thunderbolt] Call Trace: dump_stack_lvl+0x6c/0x90 print_report+0xd1/0x630 kasan_report+0xdb/0x110 __asan_report_load4_noabort+0x14/0x20 tb_retimer_scan+0xffe/0x1550 [thunderbolt] tb_scan_port+0xa6f/0x2060 [thunderbolt] tb_handle_hotplug+0x17b1/0x3080 [thunderbolt] process_one_work+0x626/0x1100 worker_thread+0x6c8/0xfa0 kthread+0x2c8/0x3a0 ret_from_fork+0x3a/0x80 ret_from_fork_asm+0x1a/0x30 This happens because the loop variable still gets incremented by one so max becomes 3 instead of 2, and this makes the second loop read past the the array declared on the stack. Fix this by assigning to max directly in the loop body.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50228", "url": "https://ubuntu.com/security/CVE-2024-50228", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50229", "url": "https://ubuntu.com/security/CVE-2024-50229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential deadlock with newly created symlinks Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers memory reclamation involving the filesystem layer, which can result in circular lock dependencies among the reader/writer semaphore nilfs->ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the fs_reclaim pseudo lock. This is because after commit 21fc61c73c39 (\"don't put symlink bodies in pagecache into highmem\"), the gfp flags of the page cache for symbolic links are overwritten to GFP_KERNEL via inode_nohighmem(). This is not a problem for symlinks read from the backing device, because the __GFP_FS flag is dropped after inode_nohighmem() is called. However, when a new symlink is created with nilfs_symlink(), the gfp flags remain overwritten to GFP_KERNEL. Then, memory allocation called from page_symlink() etc. triggers memory reclamation including the FS layer, which may call nilfs_evict_inode() or nilfs_dirty_inode(). And these can cause a deadlock if they are called while nilfs->ns_segctor_sem is held: Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags of newly created symlinks in the same way that nilfs_new_inode() and __nilfs_read_inode() do, as a workaround until we adopt nofs allocation scope consistently or improve the locking constraints.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50230", "url": "https://ubuntu.com/security/CVE-2024-50230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug due to missing clearing of checked flag Syzbot reported that in directory operations after nilfs2 detects filesystem corruption and degrades to read-only, __block_write_begin_int(), which is called to prepare block writes, may fail the BUG_ON check for accesses exceeding the folio/page size, triggering a kernel bug. This was found to be because the \"checked\" flag of a page/folio was not cleared when it was discarded by nilfs2's own routine, which causes the sanity check of directory entries to be skipped when the directory page/folio is reloaded. So, fix that. This was necessary when the use of nilfs2's own page discard routine was applied to more than just metadata files.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50231", "url": "https://ubuntu.com/security/CVE-2024-50231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gts-helper: Fix memory leaks in iio_gts_build_avail_scale_table() modprobe iio-test-gts and rmmod it, then the following memory leak occurs: \tunreferenced object 0xffffff80c810be00 (size 64): \t comm \"kunit_try_catch\", pid 1654, jiffies 4294913981 \t hex dump (first 32 bytes): \t 02 00 00 00 08 00 00 00 20 00 00 00 40 00 00 00 ........ ...@... \t 80 00 00 00 00 02 00 00 00 04 00 00 00 08 00 00 ................ \t backtrace (crc a63d875e): \t [<0000000028c1b3c2>] kmemleak_alloc+0x34/0x40 \t [<000000001d6ecc87>] __kmalloc_noprof+0x2bc/0x3c0 \t [<00000000393795c1>] devm_iio_init_iio_gts+0x4b4/0x16f4 \t [<0000000071bb4b09>] 0xffffffdf052a62e0 \t [<000000000315bc18>] 0xffffffdf052a6488 \t [<00000000f9dc55b5>] kunit_try_run_case+0x13c/0x3ac \t [<00000000175a3fd4>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000f505065d>] kthread+0x2e8/0x374 \t [<00000000bbfb0e5d>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cbfe9e70 (size 16): \t comm \"kunit_try_catch\", pid 1658, jiffies 4294914015 \t hex dump (first 16 bytes): \t 10 00 00 00 40 00 00 00 80 00 00 00 00 00 00 00 ....@........... \t backtrace (crc 857f0cb4): \t [<0000000028c1b3c2>] kmemleak_alloc+0x34/0x40 \t [<000000001d6ecc87>] __kmalloc_noprof+0x2bc/0x3c0 \t [<00000000393795c1>] devm_iio_init_iio_gts+0x4b4/0x16f4 \t [<0000000071bb4b09>] 0xffffffdf052a62e0 \t [<000000007d089d45>] 0xffffffdf052a6864 \t [<00000000f9dc55b5>] kunit_try_run_case+0x13c/0x3ac \t [<00000000175a3fd4>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000f505065d>] kthread+0x2e8/0x374 \t [<00000000bbfb0e5d>] ret_from_fork+0x10/0x20 \t...... It includes 5*5 times \"size 64\" memory leaks, which correspond to 5 times test_init_iio_gain_scale() calls with gts_test_gains size 10 (10*size(int)) and gts_test_itimes size 5. It also includes 5*1 times \"size 16\" memory leak, which correspond to one time __test_init_iio_gain_scale() call with gts_test_gains_gain_low size 3 (3*size(int)) and gts_test_itimes size 5. The reason is that the per_time_gains[i] is not freed which is allocated in the \"gts->num_itime\" for loop in iio_gts_build_avail_scale_table().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53076", "url": "https://ubuntu.com/security/CVE-2024-53076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gts-helper: Fix memory leaks for the error path of iio_gts_build_avail_scale_table() If per_time_scales[i] or per_time_gains[i] kcalloc fails in the for loop of iio_gts_build_avail_scale_table(), the err_free_out will fail to call kfree() each time when i is reduced to 0, so all the per_time_scales[0] and per_time_gains[0] will not be freed, which will cause memory leaks. Fix it by checking if i >= 0.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50232", "url": "https://ubuntu.com/security/CVE-2024-50232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr() In the ad7124_write_raw() function, parameter val can potentially be zero. This may lead to a division by zero when DIV_ROUND_CLOSEST() is called within ad7124_set_channel_odr(). The ad7124_write_raw() function is invoked through the sequence: iio_write_channel_raw() -> iio_write_channel_attribute() -> iio_channel_write(), with no checks in place to ensure val is non-zero.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50233", "url": "https://ubuntu.com/security/CVE-2024-50233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: iio: frequency: ad9832: fix division by zero in ad9832_calc_freqreg() In the ad9832_write_frequency() function, clk_get_rate() might return 0. This can lead to a division by zero when calling ad9832_calc_freqreg(). The check if (fout > (clk_get_rate(st->mclk) / 2)) does not protect against the case when fout is 0. The ad9832_write_frequency() function is called from ad9832_write(), and fout is derived from a text buffer, which can contain any value.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53055", "url": "https://ubuntu.com/security/CVE-2024-53055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix 6 GHz scan construction If more than 255 colocated APs exist for the set of all APs found during 2.4/5 GHz scanning, then the 6 GHz scan construction will loop forever since the loop variable has type u8, which can never reach the number found when that's bigger than 255, and is stored in a u32 variable. Also move it into the loops to have a smaller scope. Using a u32 there is fine, we limit the number of APs in the scan list and each has a limit on the number of RNR entries due to the frame size. With a limit of 1000 scan results, a frame size upper bound of 4096 (really it's more like ~2300) and a TBTT entry size of at least 11, we get an upper bound for the number of ~372k, well in the bounds of a u32.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50234", "url": "https://ubuntu.com/security/CVE-2024-50234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlegacy: Clear stale interrupts before resuming device iwl4965 fails upon resume from hibernation on my laptop. The reason seems to be a stale interrupt which isn't being cleared out before interrupts are enabled. We end up with a race beween the resume trying to bring things back up, and the restart work (queued form the interrupt handler) trying to bring things down. Eventually the whole thing blows up. Fix the problem by clearing out any stale interrupts before interrupts get enabled during resume. Here's a debug log of the indicent: [ 12.042589] ieee80211 phy0: il_isr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000 [ 12.042625] ieee80211 phy0: il4965_irq_tasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000 [ 12.042651] iwl4965 0000:10:00.0: RF_KILL bit toggled to enable radio. [ 12.042653] iwl4965 0000:10:00.0: On demand firmware reload [ 12.042690] ieee80211 phy0: il4965_irq_tasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282 [ 12.052207] ieee80211 phy0: il4965_mac_start enter [ 12.052212] ieee80211 phy0: il_prep_station Add STA to driver ID 31: ff:ff:ff:ff:ff:ff [ 12.052244] ieee80211 phy0: il4965_set_hw_ready hardware ready [ 12.052324] ieee80211 phy0: il_apm_init Init card's basic functions [ 12.052348] ieee80211 phy0: il_apm_init L1 Enabled; Disabling L0S [ 12.055727] ieee80211 phy0: il4965_load_bsm Begin load bsm [ 12.056140] ieee80211 phy0: il4965_verify_bsm Begin verify bsm [ 12.058642] ieee80211 phy0: il4965_verify_bsm BSM bootstrap uCode image OK [ 12.058721] ieee80211 phy0: il4965_load_bsm BSM write complete, poll 1 iterations [ 12.058734] ieee80211 phy0: __il4965_up iwl4965 is coming up [ 12.058737] ieee80211 phy0: il4965_mac_start Start UP work done. [ 12.058757] ieee80211 phy0: __il4965_down iwl4965 is going down [ 12.058761] ieee80211 phy0: il_scan_cancel_timeout Scan cancel timeout [ 12.058762] ieee80211 phy0: il_do_scan_abort Not performing scan to abort [ 12.058765] ieee80211 phy0: il_clear_ucode_stations Clearing ucode stations in driver [ 12.058767] ieee80211 phy0: il_clear_ucode_stations No active stations found to be cleared [ 12.058819] ieee80211 phy0: _il_apm_stop Stop card, put in low power state [ 12.058827] ieee80211 phy0: _il_apm_stop_master stop master [ 12.058864] ieee80211 phy0: il4965_clear_free_frames 0 frames on pre-allocated heap on clear. [ 12.058869] ieee80211 phy0: Hardware restart was requested [ 16.132299] iwl4965 0000:10:00.0: START_ALIVE timeout after 4000ms. [ 16.132303] ------------[ cut here ]------------ [ 16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue. [ 16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132390] Modules linked in: ctr ccm sch_fq_codel xt_tcpudp xt_multiport xt_state iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables binfmt_misc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdh_generic ecc iTCO_wdt i2c_dev iwl4965 iwlegacy coretemp snd_hda_codec_analog pcspkr psmouse mac80211 snd_hda_codec_generic libarc4 sdhci_pci cqhci sha256_generic sdhci libsha256 firewire_ohci snd_hda_intel snd_intel_dspcfg mmc_core snd_hda_codec snd_hwdep firewire_core led_class iosf_mbi snd_hda_core uhci_hcd lpc_ich crc_itu_t cfg80211 ehci_pci ehci_hcd snd_pcm usbcore mfd_core rfkill snd_timer snd usb_common soundcore video parport_pc parport intel_agp wmi intel_gtt backlight e1000e agpgart evdev [ 16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143 [ 16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010 [ 16.132463] Workqueue: async async_run_entry_fn [ 16.132469] RIP: 0010:ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132501] Code: da 02 00 0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50235", "url": "https://ubuntu.com/security/CVE-2024-50235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: clear wdev->cqm_config pointer on free When we free wdev->cqm_config when unregistering, we also need to clear out the pointer since the same wdev/netdev may get re-registered in another network namespace, then destroyed later, running this code again, which results in a double-free.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50236", "url": "https://ubuntu.com/security/CVE-2024-50236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: Fix memory leak in management tx In the current logic, memory is allocated for storing the MSDU context during management packet TX but this memory is not being freed during management TX completion. Similar leaks are seen in the management TX cleanup logic. Kmemleak reports this problem as below, unreferenced object 0xffffff80b64ed250 (size 16): comm \"kworker/u16:7\", pid 148, jiffies 4294687130 (age 714.199s) hex dump (first 16 bytes): 00 2b d8 d8 80 ff ff ff c4 74 e9 fd 07 00 00 00 .+.......t...... backtrace: [] __kmem_cache_alloc_node+0x1e4/0x2d8 [] kmalloc_trace+0x48/0x110 [] ath10k_wmi_tlv_op_gen_mgmt_tx_send+0xd4/0x1d8 [ath10k_core] [] ath10k_mgmt_over_wmi_tx_work+0x134/0x298 [ath10k_core] [] process_scheduled_works+0x1ac/0x400 [] worker_thread+0x208/0x328 [] kthread+0x100/0x1c0 [] ret_from_fork+0x10/0x20 Free the memory during completion and cleanup to fix the leak. Protect the mgmt_pending_tx idr_remove() operation in ath10k_wmi_tlv_op_cleanup_mgmt_tx_send() using ar->data_lock similar to other instances. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50237", "url": "https://ubuntu.com/security/CVE-2024-50237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower Avoid potentially crashing in the driver because of uninitialized private data", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50238", "url": "https://ubuntu.com/security/CVE-2024-50238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usbc: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data from the qcom-qmp-usb driver, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. This bug was later reproduced when the driver was copied to create the qmp-usbc driver. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with these drivers.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50239", "url": "https://ubuntu.com/security/CVE-2024-50239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usb-legacy: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data from the qcom-qmp-usb driver, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. This bug was later reproduced when the driver was copied to create the qmp-usb-legacy driver. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with these drivers.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50240", "url": "https://ubuntu.com/security/CVE-2024-50240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usb: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with this driver.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53077", "url": "https://ubuntu.com/security/CVE-2024-53077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpcrdma: Always release the rpcrdma_device's xa_array Dai pointed out that the xa_init_flags() in rpcrdma_add_one() needs to have a matching xa_destroy() in rpcrdma_remove_one() to release underlying memory that the xarray might have accrued during operation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50242", "url": "https://ubuntu.com/security/CVE-2024-50242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ntfs_file_release", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50243", "url": "https://ubuntu.com/security/CVE-2024-50243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix general protection fault in run_is_mapped_full Fixed deleating of a non-resident attribute in ntfs_create_inode() rollback.", "cve_priority": "low", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50244", "url": "https://ubuntu.com/security/CVE-2024-50244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ni_clear() Checking of NTFS_FLAGS_LOG_REPLAYING added to prevent access to uninitialized bitmap during replay process.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50245", "url": "https://ubuntu.com/security/CVE-2024-50245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix possible deadlock in mi_read Mutex lock with another subclass used in ni_lock_dir().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50246", "url": "https://ubuntu.com/security/CVE-2024-50246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Add rough attr alloc_size check", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50247", "url": "https://ubuntu.com/security/CVE-2024-50247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Check if more than chunk-size bytes are written A incorrectly formatted chunk may decompress into more than LZNT_CHUNK_SIZE bytes and a index out of bounds will occur in s_max_off.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50248", "url": "https://ubuntu.com/security/CVE-2024-50248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Add bounds checking to mi_enum_attr() Added bounds checking to make sure that every attr don't stray beyond valid memory region.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53078", "url": "https://ubuntu.com/security/CVE-2024-53078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Fix NULL vs IS_ERR() check in probe() The iommu_paging_domain_alloc() function doesn't return NULL pointers, it returns error pointers. Update the check to match.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53056", "url": "https://ubuntu.com/security/CVE-2024-53056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Fix potential NULL dereference in mtk_crtc_destroy() In mtk_crtc_create(), if the call to mbox_request_channel() fails then we set the \"mtk_crtc->cmdq_client.chan\" pointer to NULL. In that situation, we do not call cmdq_pkt_create(). During the cleanup, we need to check if the \"mtk_crtc->cmdq_client.chan\" is NULL first before calling cmdq_pkt_destroy(). Calling cmdq_pkt_destroy() is unnecessary if we didn't call cmdq_pkt_create() and it will result in a NULL pointer dereference.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50249", "url": "https://ubuntu.com/security/CVE-2024-50249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Make rmw_lock a raw_spin_lock The following BUG was triggered: ============================= [ BUG: Invalid wait context ] 6.12.0-rc2-XXX #406 Not tainted ----------------------------- kworker/1:1/62 is trying to lock: ffffff8801593030 (&cpc_ptr->rmw_lock){+.+.}-{3:3}, at: cpc_write+0xcc/0x370 other info that might help us debug this: context-{5:5} 2 locks held by kworker/1:1/62: #0: ffffff897ef5ec98 (&rq->__lock){-.-.}-{2:2}, at: raw_spin_rq_lock_nested+0x2c/0x50 #1: ffffff880154e238 (&sg_policy->update_lock){....}-{2:2}, at: sugov_update_shared+0x3c/0x280 stack backtrace: CPU: 1 UID: 0 PID: 62 Comm: kworker/1:1 Not tainted 6.12.0-rc2-g9654bd3e8806 #406 Workqueue: 0x0 (events) Call trace: dump_backtrace+0xa4/0x130 show_stack+0x20/0x38 dump_stack_lvl+0x90/0xd0 dump_stack+0x18/0x28 __lock_acquire+0x480/0x1ad8 lock_acquire+0x114/0x310 _raw_spin_lock+0x50/0x70 cpc_write+0xcc/0x370 cppc_set_perf+0xa0/0x3a8 cppc_cpufreq_fast_switch+0x40/0xc0 cpufreq_driver_fast_switch+0x4c/0x218 sugov_update_shared+0x234/0x280 update_load_avg+0x6ec/0x7b8 dequeue_entities+0x108/0x830 dequeue_task_fair+0x58/0x408 __schedule+0x4f0/0x1070 schedule+0x54/0x130 worker_thread+0xc0/0x2e8 kthread+0x130/0x148 ret_from_fork+0x10/0x20 sugov_update_shared() locks a raw_spinlock while cpc_write() locks a spinlock. To have a correct wait-type order, update rmw_lock to a raw spinlock and ensure that interrupts will be disabled on the CPU holding it. [ rjw: Changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50250", "url": "https://ubuntu.com/security/CVE-2024-50250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fsdax: dax_unshare_iter needs to copy entire blocks The code that copies data from srcmap to iomap in dax_unshare_iter is very very broken, which bfoster's recent fsx changes have exposed. If the pos and len passed to dax_file_unshare are not aligned to an fsblock boundary, the iter pos and length in the _iter function will reflect this unalignment. dax_iomap_direct_access always returns a pointer to the start of the kmapped fsdax page, even if its pos argument is in the middle of that page. This is catastrophic for data integrity when iter->pos is not aligned to a page, because daddr/saddr do not point to the same byte in the file as iter->pos. Hence we corrupt user data by copying it to the wrong place. If iter->pos + iomap_length() in the _iter function not aligned to a page, then we fail to copy a full block, and only partially populate the destination block. This is catastrophic for data confidentiality because we expose stale pmem contents. Fix both of these issues by aligning copy_pos/copy_len to a page boundary (remember, this is fsdax so 1 fsblock == 1 base page) so that we always copy full blocks. We're not done yet -- there's no call to invalidate_inode_pages2_range, so programs that have the file range mmap'd will continue accessing the old memory mapping after the file metadata updates have completed. Be careful with the return value -- if the unshare succeeds, we still need to return the number of bytes that the iomap iter thinks we're operating on.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50251", "url": "https://ubuntu.com/security/CVE-2024-50251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_payload: sanitize offset and length before calling skb_checksum() If access to offset + length is larger than the skbuff length, then skb_checksum() triggers BUG_ON(). skb_checksum() internally subtracts the length parameter while iterating over skbuff, BUG_ON(len) at the end of it checks that the expected length to be included in the checksum calculation is fully consumed.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50252", "url": "https://ubuntu.com/security/CVE-2024-50252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_ipip: Fix memory leak when changing remote IPv6 address The device stores IPv6 addresses that are used for encapsulation in linear memory that is managed by the driver. Changing the remote address of an ip6gre net device never worked properly, but since cited commit the following reproducer [1] would result in a warning [2] and a memory leak [3]. The problem is that the new remote address is never added by the driver to its hash table (and therefore the device) and the old address is never removed from it. Fix by programming the new address when the configuration of the ip6gre net device changes and removing the old one. If the address did not change, then the above would result in increasing the reference count of the address and then decreasing it. [1] # ip link add name bla up type ip6gre local 2001:db8:1::1 remote 2001:db8:2::1 tos inherit ttl inherit # ip link set dev bla type ip6gre remote 2001:db8:3::1 # ip link del dev bla # devlink dev reload pci/0000:01:00.0 [2] WARNING: CPU: 0 PID: 1682 at drivers/net/ethernet/mellanox/mlxsw/spectrum.c:3002 mlxsw_sp_ipv6_addr_put+0x140/0x1d0 Modules linked in: CPU: 0 UID: 0 PID: 1682 Comm: ip Not tainted 6.12.0-rc3-custom-g86b5b55bc835 #151 Hardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023 RIP: 0010:mlxsw_sp_ipv6_addr_put+0x140/0x1d0 [...] Call Trace: mlxsw_sp_router_netdevice_event+0x55f/0x1240 notifier_call_chain+0x5a/0xd0 call_netdevice_notifiers_info+0x39/0x90 unregister_netdevice_many_notify+0x63e/0x9d0 rtnl_dellink+0x16b/0x3a0 rtnetlink_rcv_msg+0x142/0x3f0 netlink_rcv_skb+0x50/0x100 netlink_unicast+0x242/0x390 netlink_sendmsg+0x1de/0x420 ____sys_sendmsg+0x2bd/0x320 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xd0 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f [3] unreferenced object 0xffff898081f597a0 (size 32): comm \"ip\", pid 1626, jiffies 4294719324 hex dump (first 32 bytes): 20 01 0d b8 00 02 00 00 00 00 00 00 00 00 00 01 ............... 21 49 61 83 80 89 ff ff 00 00 00 00 01 00 00 00 !Ia............. backtrace (crc fd9be911): [<00000000df89c55d>] __kmalloc_cache_noprof+0x1da/0x260 [<00000000ff2a1ddb>] mlxsw_sp_ipv6_addr_kvdl_index_get+0x281/0x340 [<000000009ddd445d>] mlxsw_sp_router_netdevice_event+0x47b/0x1240 [<00000000743e7757>] notifier_call_chain+0x5a/0xd0 [<000000007c7b9e13>] call_netdevice_notifiers_info+0x39/0x90 [<000000002509645d>] register_netdevice+0x5f7/0x7a0 [<00000000c2e7d2a9>] ip6gre_newlink_common.isra.0+0x65/0x130 [<0000000087cd6d8d>] ip6gre_newlink+0x72/0x120 [<000000004df7c7cc>] rtnl_newlink+0x471/0xa20 [<0000000057ed632a>] rtnetlink_rcv_msg+0x142/0x3f0 [<0000000032e0d5b5>] netlink_rcv_skb+0x50/0x100 [<00000000908bca63>] netlink_unicast+0x242/0x390 [<00000000cdbe1c87>] netlink_sendmsg+0x1de/0x420 [<0000000011db153e>] ____sys_sendmsg+0x2bd/0x320 [<000000003b6d53eb>] ___sys_sendmsg+0x9a/0xe0 [<00000000cae27c62>] __sys_sendmsg+0x7a/0xd0", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50253", "url": "https://ubuntu.com/security/CVE-2024-50253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check the validity of nr_words in bpf_iter_bits_new() Check the validity of nr_words in bpf_iter_bits_new(). Without this check, when multiplication overflow occurs for nr_bits (e.g., when nr_words = 0x0400-0001, nr_bits becomes 64), stack corruption may occur due to bpf_probe_read_kernel_common(..., nr_bytes = 0x2000-0008). Fix it by limiting the maximum value of nr_words to 511. The value is derived from the current implementation of BPF memory allocator. To ensure compatibility if the BPF memory allocator's size limitation changes in the future, use the helper bpf_mem_alloc_check_size() to check whether nr_bytes is too larger. And return -E2BIG instead of -ENOMEM for oversized nr_bytes.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50254", "url": "https://ubuntu.com/security/CVE-2024-50254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free dynamically allocated bits in bpf_iter_bits_destroy() bpf_iter_bits_destroy() uses \"kit->nr_bits <= 64\" to check whether the bits are dynamically allocated. However, the check is incorrect and may cause a kmemleak as shown below: unreferenced object 0xffff88812628c8c0 (size 32): comm \"swapper/0\", pid 1, jiffies 4294727320 hex dump (first 32 bytes): \tb0 c1 55 f5 81 88 ff ff f0 f0 f0 f0 f0 f0 f0 f0 ..U........... \tf0 f0 f0 f0 f0 f0 f0 f0 00 00 00 00 00 00 00 00 .............. backtrace (crc 781e32cc): \t[<00000000c452b4ab>] kmemleak_alloc+0x4b/0x80 \t[<0000000004e09f80>] __kmalloc_node_noprof+0x480/0x5c0 \t[<00000000597124d6>] __alloc.isra.0+0x89/0xb0 \t[<000000004ebfffcd>] alloc_bulk+0x2af/0x720 \t[<00000000d9c10145>] prefill_mem_cache+0x7f/0xb0 \t[<00000000ff9738ff>] bpf_mem_alloc_init+0x3e2/0x610 \t[<000000008b616eac>] bpf_global_ma_init+0x19/0x30 \t[<00000000fc473efc>] do_one_initcall+0xd3/0x3c0 \t[<00000000ec81498c>] kernel_init_freeable+0x66a/0x940 \t[<00000000b119f72f>] kernel_init+0x20/0x160 \t[<00000000f11ac9a7>] ret_from_fork+0x3c/0x70 \t[<0000000004671da4>] ret_from_fork_asm+0x1a/0x30 That is because nr_bits will be set as zero in bpf_iter_bits_next() after all bits have been iterated. Fix the issue by setting kit->bit to kit->nr_bits instead of setting kit->nr_bits to zero when the iteration completes in bpf_iter_bits_next(). In addition, use \"!nr_bits || bits >= nr_bits\" to check whether the iteration is complete and still use \"nr_bits > 64\" to indicate whether bits are dynamically allocated. The \"!nr_bits\" check is necessary because bpf_iter_bits_new() may fail before setting kit->nr_bits, and this condition will stop the iteration early instead of accessing the zeroed or freed kit->bits. Considering the initial value of kit->bits is -1 and the type of kit->nr_bits is unsigned int, change the type of kit->nr_bits to int. The potential overflow problem will be handled in the following patch.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50255", "url": "https://ubuntu.com/security/CVE-2024-50255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci: fix null-ptr-deref in hci_read_supported_codecs Fix __hci_cmd_sync_sk() to return not NULL for unknown opcodes. __hci_cmd_sync_sk() returns NULL if a command returns a status event. However, it also returns NULL where an opcode doesn't exist in the hci_cc table because hci_cmd_complete_evt() assumes status = skb->data[0] for unknown opcodes. This leads to null-ptr-deref in cmd_sync for HCI_OP_READ_LOCAL_CODECS as there is no hci_cc for HCI_OP_READ_LOCAL_CODECS, which always assumes status = skb->data[0]. KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077] CPU: 1 PID: 2000 Comm: kworker/u9:5 Not tainted 6.9.0-ga6bcb805883c-dirty #10 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: hci7 hci_power_on RIP: 0010:hci_read_supported_codecs+0xb9/0x870 net/bluetooth/hci_codec.c:138 Code: 08 48 89 ef e8 b8 c1 8f fd 48 8b 75 00 e9 96 00 00 00 49 89 c6 48 ba 00 00 00 00 00 fc ff df 4c 8d 60 70 4c 89 e3 48 c1 eb 03 <0f> b6 04 13 84 c0 0f 85 82 06 00 00 41 83 3c 24 02 77 0a e8 bf 78 RSP: 0018:ffff888120bafac8 EFLAGS: 00010212 RAX: 0000000000000000 RBX: 000000000000000e RCX: ffff8881173f0040 RDX: dffffc0000000000 RSI: ffffffffa58496c0 RDI: ffff88810b9ad1e4 RBP: ffff88810b9ac000 R08: ffffffffa77882a7 R09: 1ffffffff4ef1054 R10: dffffc0000000000 R11: fffffbfff4ef1055 R12: 0000000000000070 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88810b9ac000 FS: 0000000000000000(0000) GS:ffff8881f6c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6ddaa3439e CR3: 0000000139764003 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: hci_read_local_codecs_sync net/bluetooth/hci_sync.c:4546 [inline] hci_init_stage_sync net/bluetooth/hci_sync.c:3441 [inline] hci_init4_sync net/bluetooth/hci_sync.c:4706 [inline] hci_init_sync net/bluetooth/hci_sync.c:4742 [inline] hci_dev_init_sync net/bluetooth/hci_sync.c:4912 [inline] hci_dev_open_sync+0x19a9/0x2d30 net/bluetooth/hci_sync.c:4994 hci_dev_do_open net/bluetooth/hci_core.c:483 [inline] hci_power_on+0x11e/0x560 net/bluetooth/hci_core.c:1015 process_one_work kernel/workqueue.c:3267 [inline] process_scheduled_works+0x8ef/0x14f0 kernel/workqueue.c:3348 worker_thread+0x91f/0xe50 kernel/workqueue.c:3429 kthread+0x2cb/0x360 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50256", "url": "https://ubuntu.com/security/CVE-2024-50256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6() I got a syzbot report without a repro [1] crashing in nf_send_reset6() I think the issue is that dev->hard_header_len is zero, and we attempt later to push an Ethernet header. Use LL_MAX_HEADER, as other functions in net/ipv6/netfilter/nf_reject_ipv6.c. [1] skbuff: skb_under_panic: text:ffffffff89b1d008 len:74 put:14 head:ffff88803123aa00 data:ffff88803123a9f2 tail:0x3c end:0x140 dev:syz_tun kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 UID: 0 PID: 7373 Comm: syz.1.568 Not tainted 6.12.0-rc2-syzkaller-00631-g6d858708d465 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:skb_panic net/core/skbuff.c:206 [inline] RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216 Code: 0d 8d 48 c7 c6 60 a6 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 ba 30 38 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP: 0018:ffffc900045269b0 EFLAGS: 00010282 RAX: 0000000000000088 RBX: dffffc0000000000 RCX: cd66dacdc5d8e800 RDX: 0000000000000000 RSI: 0000000000000200 RDI: 0000000000000000 RBP: ffff88802d39a3d0 R08: ffffffff8174afec R09: 1ffff920008a4ccc R10: dffffc0000000000 R11: fffff520008a4ccd R12: 0000000000000140 R13: ffff88803123aa00 R14: ffff88803123a9f2 R15: 000000000000003c FS: 00007fdbee5ff6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000005d322000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: skb_push+0xe5/0x100 net/core/skbuff.c:2636 eth_header+0x38/0x1f0 net/ethernet/eth.c:83 dev_hard_header include/linux/netdevice.h:3208 [inline] nf_send_reset6+0xce6/0x1270 net/ipv6/netfilter/nf_reject_ipv6.c:358 nft_reject_inet_eval+0x3b9/0x690 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x418/0x6b0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] br_nf_pre_routing_ipv6+0x63e/0x770 net/bridge/br_netfilter_ipv6.c:184 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_bridge_pre net/bridge/br_input.c:277 [inline] br_handle_frame+0x9fd/0x1530 net/bridge/br_input.c:424 __netif_receive_skb_core+0x13e8/0x4570 net/core/dev.c:5562 __netif_receive_skb_one_core net/core/dev.c:5666 [inline] __netif_receive_skb+0x12f/0x650 net/core/dev.c:5781 netif_receive_skb_internal net/core/dev.c:5867 [inline] netif_receive_skb+0x1e8/0x890 net/core/dev.c:5926 tun_rx_batched+0x1b7/0x8f0 drivers/net/tun.c:1550 tun_get_user+0x3056/0x47e0 drivers/net/tun.c:2007 tun_chr_write_iter+0x10d/0x1f0 drivers/net/tun.c:2053 new_sync_write fs/read_write.c:590 [inline] vfs_write+0xa6d/0xc90 fs/read_write.c:683 ksys_write+0x183/0x2b0 fs/read_write.c:736 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:0x7fdbeeb7d1ff Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 c9 8d 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 1c 8e 02 00 48 RSP: 002b:00007fdbee5ff000 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fdbeed36058 RCX: 00007fdbeeb7d1ff RDX: 000000000000008e RSI: 0000000020000040 RDI: 00000000000000c8 RBP: 00007fdbeebf12be R08: 0000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50257", "url": "https://ubuntu.com/security/CVE-2024-50257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: Fix use-after-free in get_info() ip6table_nat module unload has refcnt warning for UAF. call trace is: WARNING: CPU: 1 PID: 379 at kernel/module/main.c:853 module_put+0x6f/0x80 Modules linked in: ip6table_nat(-) CPU: 1 UID: 0 PID: 379 Comm: ip6tables Not tainted 6.12.0-rc4-00047-gc2ee9f594da8-dirty #205 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:module_put+0x6f/0x80 Call Trace: get_info+0x128/0x180 do_ip6t_get_ctl+0x6a/0x430 nf_getsockopt+0x46/0x80 ipv6_getsockopt+0xb9/0x100 rawv6_getsockopt+0x42/0x190 do_sock_getsockopt+0xaa/0x180 __sys_getsockopt+0x70/0xc0 __x64_sys_getsockopt+0x20/0x30 do_syscall_64+0xa2/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Concurrent execution of module unload and get_info() trigered the warning. The root cause is as follows: cpu0\t\t\t\t cpu1 module_exit //mod->state = MODULE_STATE_GOING ip6table_nat_exit xt_unregister_template \tkfree(t) \t//removed from templ_list \t\t\t\t getinfo() \t\t\t\t\t t = xt_find_table_lock \t\t\t\t\t\tlist_for_each_entry(tmpl, &xt_templates[af]...) \t\t\t\t\t\t\tif (strcmp(tmpl->name, name)) \t\t\t\t\t\t\t\tcontinue; //table not found \t\t\t\t\t\t\ttry_module_get \t\t\t\t\t\tlist_for_each_entry(t, &xt_net->tables[af]...) \t\t\t\t\t\t\treturn t; //not get refcnt \t\t\t\t\t module_put(t->me) //uaf unregister_pernet_subsys //remove table from xt_net list While xt_table module was going away and has been removed from xt_templates list, we couldnt get refcnt of xt_table->me. Check module in xt_net->tables list re-traversal to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50258", "url": "https://ubuntu.com/security/CVE-2024-50258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix crash when config small gso_max_size/gso_ipv4_max_size Config a small gso_max_size/gso_ipv4_max_size will lead to an underflow in sk_dst_gso_max_size(), which may trigger a BUG_ON crash, because sk->sk_gso_max_size would be much bigger than device limits. Call Trace: tcp_write_xmit tso_segs = tcp_init_tso_segs(skb, mss_now); tcp_set_skb_tso_segs tcp_skb_pcount_set // skb->len = 524288, mss_now = 8 // u16 tso_segs = 524288/8 = 65535 -> 0 tso_segs = DIV_ROUND_UP(skb->len, mss_now) BUG_ON(!tso_segs) Add check for the minimum value of gso_max_size and gso_ipv4_max_size.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50262", "url": "https://ubuntu.com/security/CVE-2024-50262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix out-of-bounds write in trie_get_next_key() trie_get_next_key() allocates a node stack with size trie->max_prefixlen, while it writes (trie->max_prefixlen + 1) nodes to the stack when it has full paths from the root to leaves. For example, consider a trie with max_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ... 0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with .prefixlen = 8 make 9 nodes be written on the node stack with size 8.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53044", "url": "https://ubuntu.com/security/CVE-2024-53044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_api: fix xa_insert() error path in tcf_block_get_ext() This command: $ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact Error: block dev insert failed: -EBUSY. fails because user space requests the same block index to be set for both ingress and egress. [ side note, I don't think it even failed prior to commit 913b47d3424e (\"net/sched: Introduce tc block netdev tracking infra\"), because this is a command from an old set of notes of mine which used to work, but alas, I did not scientifically bisect this ] The problem is not that it fails, but rather, that the second time around, it fails differently (and irrecoverably): $ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact Error: dsa_core: Flow block cb is busy. [ another note: the extack is added by me for illustration purposes. the context of the problem is that clsact_init() obtains the same &q->ingress_block pointer as &q->egress_block, and since we call tcf_block_get_ext() on both of them, \"dev\" will be added to the block->ports xarray twice, thus failing the operation: once through the ingress block pointer, and once again through the egress block pointer. the problem itself is that when xa_insert() fails, we have emitted a FLOW_BLOCK_BIND command through ndo_setup_tc(), but the offload never sees a corresponding FLOW_BLOCK_UNBIND. ] Even correcting the bad user input, we still cannot recover: $ tc qdisc replace dev swp3 ingress_block 1 egress_block 2 clsact Error: dsa_core: Flow block cb is busy. Basically the only way to recover is to reboot the system, or unbind and rebind the net device driver. To fix the bug, we need to fill the correct error teardown path which was missed during code movement, and call tcf_block_offload_unbind() when xa_insert() fails. [ last note, fundamentally I blame the label naming convention in tcf_block_get_ext() for the bug. The labels should be named after what they do, not after the error path that jumps to them. This way, it is obviously wrong that two labels pointing to the same code mean something is wrong, and checking the code correctness at the goto site is also easier ]", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50259", "url": "https://ubuntu.com/security/CVE-2024-50259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netdevsim: Add trailing zero to terminate the string in nsim_nexthop_bucket_activity_write() This was found by a static analyzer. We should not forget the trailing zero after copy_from_user() if we will further do some string operations, sscanf() in this case. Adding a trailing zero will ensure that the function performs properly.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50304", "url": "https://ubuntu.com/security/CVE-2024-50304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find() The per-netns IP tunnel hash table is protected by the RTNL mutex and ip_tunnel_find() is only called from the control path where the mutex is taken. Add a lockdep expression to hlist_for_each_entry_rcu() in ip_tunnel_find() in order to validate that the mutex is held and to silence the suspicious RCU usage warning [1]. [1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gd95d9a31aceb #139 Not tainted ----------------------------- net/ipv4/ip_tunnel.c:221 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/362: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60 stack backtrace: CPU: 12 UID: 0 PID: 362 Comm: ip Not tainted 6.12.0-rc3-custom-gd95d9a31aceb #139 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 ip_tunnel_find+0x435/0x4d0 ip_tunnel_newlink+0x517/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53042", "url": "https://ubuntu.com/security/CVE-2024-53042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_init_flow() There are code paths from which the function is called without holding the RCU read lock, resulting in a suspicious RCU usage warning [1]. Fix by using l3mdev_master_upper_ifindex_by_index() which will acquire the RCU read lock before calling l3mdev_master_upper_ifindex_by_index_rcu(). [1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gac8f72681cf2 #141 Not tainted ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/361: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60 stack backtrace: CPU: 3 UID: 0 PID: 361 Comm: ip Not tainted 6.12.0-rc3-custom-gac8f72681cf2 #141 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 dev_get_by_index_rcu+0x1d3/0x210 l3mdev_master_upper_ifindex_by_index_rcu+0x2b/0xf0 ip_tunnel_bind_dev+0x72f/0xa00 ip_tunnel_newlink+0x368/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53048", "url": "https://ubuntu.com/security/CVE-2024-53048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix crash on probe for DPLL enabled E810 LOM The E810 Lan On Motherboard (LOM) design is vendor specific. Intel provides the reference design, but it is up to vendor on the final product design. For some cases, like Linux DPLL support, the static values defined in the driver does not reflect the actual LOM design. Current implementation of dpll pins is causing the crash on probe of the ice driver for such DPLL enabled E810 LOM designs: WARNING: (...) at drivers/dpll/dpll_core.c:495 dpll_pin_get+0x2c4/0x330 ... Call Trace: ? __warn+0x83/0x130 ? dpll_pin_get+0x2c4/0x330 ? report_bug+0x1b7/0x1d0 ? handle_bug+0x42/0x70 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? dpll_pin_get+0x117/0x330 ? dpll_pin_get+0x2c4/0x330 ? dpll_pin_get+0x117/0x330 ice_dpll_get_pins.isra.0+0x52/0xe0 [ice] ... The number of dpll pins enabled by LOM vendor is greater than expected and defined in the driver for Intel designed NICs, which causes the crash. Prevent the crash and allow generic pin initialization within Linux DPLL subsystem for DPLL enabled E810 LOM designs. Newly designed solution for described issue will be based on \"per HW design\" pin initialization. It requires pin information dynamically acquired from the firmware and is already in progress, planned for next-tree only.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53058", "url": "https://ubuntu.com/security/CVE-2024-53058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data In case the non-paged data of a SKB carries protocol header and protocol payload to be transmitted on a certain platform that the DMA AXI address width is configured to 40-bit/48-bit, or the size of the non-paged data is bigger than TSO_MAX_BUFF_SIZE on a certain platform that the DMA AXI address width is configured to 32-bit, then this SKB requires at least two DMA transmit descriptors to serve it. For example, three descriptors are allocated to split one DMA buffer mapped from one piece of non-paged data: dma_desc[N + 0], dma_desc[N + 1], dma_desc[N + 2]. Then three elements of tx_q->tx_skbuff_dma[] will be allocated to hold extra information to be reused in stmmac_tx_clean(): tx_q->tx_skbuff_dma[N + 0], tx_q->tx_skbuff_dma[N + 1], tx_q->tx_skbuff_dma[N + 2]. Now we focus on tx_q->tx_skbuff_dma[entry].buf, which is the DMA buffer address returned by DMA mapping call. stmmac_tx_clean() will try to unmap the DMA buffer _ONLY_IF_ tx_q->tx_skbuff_dma[entry].buf is a valid buffer address. The expected behavior that saves DMA buffer address of this non-paged data to tx_q->tx_skbuff_dma[entry].buf is: tx_q->tx_skbuff_dma[N + 0].buf = NULL; tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = dma_map_single(); Unfortunately, the current code misbehaves like this: tx_q->tx_skbuff_dma[N + 0].buf = dma_map_single(); tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = NULL; On the stmmac_tx_clean() side, when dma_desc[N + 0] is closed by the DMA engine, tx_q->tx_skbuff_dma[N + 0].buf is a valid buffer address obviously, then the DMA buffer will be unmapped immediately. There may be a rare case that the DMA engine does not finish the pending dma_desc[N + 1], dma_desc[N + 2] yet. Now things will go horribly wrong, DMA is going to access a unmapped/unreferenced memory region, corrupted data will be transmited or iommu fault will be triggered :( In contrast, the for-loop that maps SKB fragments behaves perfectly as expected, and that is how the driver should do for both non-paged data and paged frags actually. This patch corrects DMA map/unmap sequences by fixing the array index for tx_q->tx_skbuff_dma[entry].buf when assigning DMA buffer address. Tested and verified on DWXGMAC CORE 3.20a", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50260", "url": "https://ubuntu.com/security/CVE-2024-50260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sock_map: fix a NULL pointer dereference in sock_map_link_update_prog() The following race condition could trigger a NULL pointer dereference: sock_map_link_detach():\t\tsock_map_link_update_prog(): mutex_lock(&sockmap_mutex); ... sockmap_link->map = NULL; mutex_unlock(&sockmap_mutex); \t\t\t\t mutex_lock(&sockmap_mutex); \t\t\t\t ... \t\t\t\t sock_map_prog_link_lookup(sockmap_link->map); \t\t\t\t mutex_unlock(&sockmap_mutex); Fix it by adding a NULL pointer check. In this specific case, it makes no sense to update a link which is being released.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53045", "url": "https://ubuntu.com/security/CVE-2024-53045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: dapm: fix bounds checker error in dapm_widget_list_create The widgets array in the snd_soc_dapm_widget_list has a __counted_by attribute attached to it, which points to the num_widgets variable. This attribute is used in bounds checking, and if it is not set before the array is filled, then the bounds sanitizer will issue a warning or a kernel panic if CONFIG_UBSAN_TRAP is set. This patch sets the size of the widgets list calculated with list_for_each as the initial value for num_widgets as it is used for allocating memory for the array. It is updated with the actual number of added elements after the array is filled.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50261", "url": "https://ubuntu.com/security/CVE-2024-50261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macsec: Fix use-after-free while sending the offloading packet KASAN reports the following UAF. The metadata_dst, which is used to store the SCI value for macsec offload, is already freed by metadata_dst_free() in macsec_free_netdev(), while driver still use it for sending the packet. To fix this issue, dst_release() is used instead to release metadata_dst. So it is not freed instantly in macsec_free_netdev() if still referenced by skb. BUG: KASAN: slab-use-after-free in mlx5e_xmit+0x1e8f/0x4190 [mlx5_core] Read of size 2 at addr ffff88813e42e038 by task kworker/7:2/714 [...] Workqueue: mld mld_ifc_work Call Trace: dump_stack_lvl+0x51/0x60 print_report+0xc1/0x600 kasan_report+0xab/0xe0 mlx5e_xmit+0x1e8f/0x4190 [mlx5_core] dev_hard_start_xmit+0x120/0x530 sch_direct_xmit+0x149/0x11e0 __qdisc_run+0x3ad/0x1730 __dev_queue_xmit+0x1196/0x2ed0 vlan_dev_hard_start_xmit+0x32e/0x510 [8021q] dev_hard_start_xmit+0x120/0x530 __dev_queue_xmit+0x14a7/0x2ed0 macsec_start_xmit+0x13e9/0x2340 dev_hard_start_xmit+0x120/0x530 __dev_queue_xmit+0x14a7/0x2ed0 ip6_finish_output2+0x923/0x1a70 ip6_finish_output+0x2d7/0x970 ip6_output+0x1ce/0x3a0 NF_HOOK.constprop.0+0x15f/0x190 mld_sendpack+0x59a/0xbd0 mld_ifc_work+0x48a/0xa80 process_one_work+0x5aa/0xe50 worker_thread+0x79c/0x1290 kthread+0x28f/0x350 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x11/0x20 Allocated by task 3922: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 __kasan_kmalloc+0x77/0x90 __kmalloc_noprof+0x188/0x400 metadata_dst_alloc+0x1f/0x4e0 macsec_newlink+0x914/0x1410 __rtnl_newlink+0xe08/0x15b0 rtnl_newlink+0x5f/0x90 rtnetlink_rcv_msg+0x667/0xa80 netlink_rcv_skb+0x12c/0x360 netlink_unicast+0x551/0x770 netlink_sendmsg+0x72d/0xbd0 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x52e/0x6a0 ___sys_sendmsg+0xeb/0x170 __sys_sendmsg+0xb5/0x140 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Freed by task 4011: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x50 poison_slab_object+0x10c/0x190 __kasan_slab_free+0x11/0x30 kfree+0xe0/0x290 macsec_free_netdev+0x3f/0x140 netdev_run_todo+0x450/0xc70 rtnetlink_rcv_msg+0x66f/0xa80 netlink_rcv_skb+0x12c/0x360 netlink_unicast+0x551/0x770 netlink_sendmsg+0x72d/0xbd0 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x52e/0x6a0 ___sys_sendmsg+0xeb/0x170 __sys_sendmsg+0xb5/0x140 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53059", "url": "https://ubuntu.com/security/CVE-2024-53059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd() 1. The size of the response packet is not validated. 2. The response buffer is not freed. Resolve these issues by switching to iwl_mvm_send_cmd_status(), which handles both size validation and frees the buffer.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53074", "url": "https://ubuntu.com/security/CVE-2024-53074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: don't leak a link on AP removal Release the link mapping resource in AP removal. This impacted devices that do not support the MLD API (9260 and down). On those devices, we couldn't start the AP again after the AP has been already started and stopped.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53049", "url": "https://ubuntu.com/security/CVE-2024-53049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slub/kunit: fix a WARNING due to unwrapped __kmalloc_cache_noprof 'modprobe slub_kunit' will have a warning as shown below. The root cause is that __kmalloc_cache_noprof was directly used, which resulted in no alloc_tag being allocated. This caused current->alloc_tag to be null, leading to a warning in alloc_tag_add_check. Let's add an alloc_hook layer to __kmalloc_cache_noprof specifically within lib/slub_kunit.c, which is the only user of this internal slub function outside kmalloc implementation itself. [58162.947016] WARNING: CPU: 2 PID: 6210 at ./include/linux/alloc_tag.h:125 alloc_tagging_slab_alloc_hook+0x268/0x27c [58162.957721] Call trace: [58162.957919] alloc_tagging_slab_alloc_hook+0x268/0x27c [58162.958286] __kmalloc_cache_noprof+0x14c/0x344 [58162.958615] test_kmalloc_redzone_access+0x50/0x10c [slub_kunit] [58162.959045] kunit_try_run_case+0x74/0x184 [kunit] [58162.959401] kunit_generic_run_threadfn_adapter+0x2c/0x4c [kunit] [58162.959841] kthread+0x10c/0x118 [58162.960093] ret_from_fork+0x10/0x20 [58162.960363] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50192", "url": "https://ubuntu.com/security/CVE-2024-50192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v4: Don't allow a VMOVP on a dying VPE Kunkun Jiang reported that there is a small window of opportunity for userspace to force a change of affinity for a VPE while the VPE has already been unmapped, but the corresponding doorbell interrupt still visible in /proc/irq/. Plug the race by checking the value of vmapp_count, which tracks whether the VPE is mapped ot not, and returning an error in this case. This involves making vmapp_count common to both GICv4.1 and its v4.0 ancestor.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50069", "url": "https://ubuntu.com/security/CVE-2024-50069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: apple: check devm_kasprintf() returned value devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked. Fix this lack and check the returned value. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50070", "url": "https://ubuntu.com/security/CVE-2024-50070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: stm32: check devm_kasprintf() returned value devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked. Fix this lack and check the returned value. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50196", "url": "https://ubuntu.com/security/CVE-2024-50196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: ocelot: fix system hang on level based interrupts The current implementation only calls chained_irq_enter() and chained_irq_exit() if it detects pending interrupts. ``` for (i = 0; i < info->stride; i++) { \turegmap_read(info->map, id_reg + 4 * i, ®); \tif (!reg) \t\tcontinue; \tchained_irq_enter(parent_chip, desc); ``` However, in case of GPIO pin configured in level mode and the parent controller configured in edge mode, GPIO interrupt might be lowered by the hardware. In the result, if the interrupt is short enough, the parent interrupt is still pending while the GPIO interrupt is cleared; chained_irq_enter() never gets called and the system hangs trying to service the parent interrupt. Moving chained_irq_enter() and chained_irq_exit() outside the for loop ensures that they are called even when GPIO interrupt is lowered by the hardware. The similar code with chained_irq_enter() / chained_irq_exit() functions wrapping interrupt checking loop may be found in many other drivers: ``` grep -r -A 10 chained_irq_enter drivers/pinctrl ```", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50197", "url": "https://ubuntu.com/security/CVE-2024-50197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: intel: platform: fix error path in device_for_each_child_node() The device_for_each_child_node() loop requires calls to fwnode_handle_put() upon early returns to decrement the refcount of the child node and avoid leaking memory if that error path is triggered. There is one early returns within that loop in intel_platform_pinctrl_prepare_community(), but fwnode_handle_put() is missing. Instead of adding the missing call, the scoped version of the loop can be used to simplify the code and avoid mistakes in the future if new early returns are added, as the child node is only used for parsing, and it is never assigned.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50071", "url": "https://ubuntu.com/security/CVE-2024-50071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: nuvoton: fix a double free in ma35_pinctrl_dt_node_to_map_func() 'new_map' is allocated using devm_* which takes care of freeing the allocated data on device removal, call to \t.dt_free_map = pinconf_generic_dt_free_map double frees the map as pinconf_generic_dt_free_map() calls pinctrl_utils_free_map(). Fix this by using kcalloc() instead of auto-managed devm_kcalloc().", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50072", "url": "https://ubuntu.com/security/CVE-2024-50072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/bugs: Use code segment selector for VERW operand Robert Gill reported below #GP in 32-bit mode when dosemu software was executing vm86() system call: general protection fault: 0000 [#1] PREEMPT SMP CPU: 4 PID: 4610 Comm: dosemu.bin Not tainted 6.6.21-gentoo-x86 #1 Hardware name: Dell Inc. PowerEdge 1950/0H723K, BIOS 2.7.0 10/30/2010 EIP: restore_all_switch_stack+0xbe/0xcf EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000 ESI: 00000000 EDI: 00000000 EBP: 00000000 ESP: ff8affdc DS: 0000 ES: 0000 FS: 0000 GS: 0033 SS: 0068 EFLAGS: 00010046 CR0: 80050033 CR2: 00c2101c CR3: 04b6d000 CR4: 000406d0 Call Trace: show_regs+0x70/0x78 die_addr+0x29/0x70 exc_general_protection+0x13c/0x348 exc_bounds+0x98/0x98 handle_exception+0x14d/0x14d exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf This only happens in 32-bit mode when VERW based mitigations like MDS/RFDS are enabled. This is because segment registers with an arbitrary user value can result in #GP when executing VERW. Intel SDM vol. 2C documents the following behavior for VERW instruction: #GP(0) - If a memory operand effective address is outside the CS, DS, ES, \t FS, or GS segment limit. CLEAR_CPU_BUFFERS macro executes VERW instruction before returning to user space. Use %cs selector to reference VERW operand. This ensures VERW will not #GP for an arbitrary user %ds. [ mingo: Fixed the SOB chain. ]", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50073", "url": "https://ubuntu.com/security/CVE-2024-50073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: Fix use-after-free in gsm_cleanup_mux BUG: KASAN: slab-use-after-free in gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] Read of size 8 at addr ffff88815fe99c00 by task poc/3379 CPU: 0 UID: 0 PID: 3379 Comm: poc Not tainted 6.11.0+ #56 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] __pfx_gsm_cleanup_mux+0x10/0x10 drivers/tty/n_gsm.c:3124 [n_gsm] __pfx_sched_clock_cpu+0x10/0x10 kernel/sched/clock.c:389 update_load_avg+0x1c1/0x27b0 kernel/sched/fair.c:4500 __pfx_min_vruntime_cb_rotate+0x10/0x10 kernel/sched/fair.c:846 __rb_insert_augmented+0x492/0xbf0 lib/rbtree.c:161 gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] _raw_spin_lock_irqsave+0x92/0xf0 arch/x86/include/asm/atomic.h:107 __pfx_gsmld_ioctl+0x10/0x10 drivers/tty/n_gsm.c:3822 [n_gsm] ktime_get+0x5e/0x140 kernel/time/timekeeping.c:195 ldsem_down_read+0x94/0x4e0 arch/x86/include/asm/atomic64_64.h:79 __pfx_ldsem_down_read+0x10/0x10 drivers/tty/tty_ldsem.c:338 __pfx_do_vfs_ioctl+0x10/0x10 fs/ioctl.c:805 tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 Allocated by task 65: gsm_data_alloc.constprop.0+0x27/0x190 drivers/tty/n_gsm.c:926 [n_gsm] gsm_send+0x2c/0x580 drivers/tty/n_gsm.c:819 [n_gsm] gsm1_receive+0x547/0xad0 drivers/tty/n_gsm.c:3038 [n_gsm] gsmld_receive_buf+0x176/0x280 drivers/tty/n_gsm.c:3609 [n_gsm] tty_ldisc_receive_buf+0x101/0x1e0 drivers/tty/tty_buffer.c:391 tty_port_default_receive_buf+0x61/0xa0 drivers/tty/tty_port.c:39 flush_to_ldisc+0x1b0/0x750 drivers/tty/tty_buffer.c:445 process_scheduled_works+0x2b0/0x10d0 kernel/workqueue.c:3229 worker_thread+0x3dc/0x950 kernel/workqueue.c:3391 kthread+0x2a3/0x370 kernel/kthread.c:389 ret_from_fork+0x2d/0x70 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:257 Freed by task 3367: kfree+0x126/0x420 mm/slub.c:4580 gsm_cleanup_mux+0x36c/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 [Analysis] gsm_msg on the tx_ctrl_list or tx_data_list of gsm_mux can be freed by multi threads through ioctl,which leads to the occurrence of uaf. Protect it by gsm tx lock.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50193", "url": "https://ubuntu.com/security/CVE-2024-50193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/entry_32: Clear CPU buffers after register restore in NMI return CPU buffers are currently cleared after call to exc_nmi, but before register state is restored. This may be okay for MDS mitigation but not for RDFS. Because RDFS mitigation requires CPU buffers to be cleared when registers don't have any sensitive data. Move CLEAR_CPU_BUFFERS after RESTORE_ALL_NMI.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50074", "url": "https://ubuntu.com/security/CVE-2024-50074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: parport: Proper fix for array out-of-bounds access The recent fix for array out-of-bounds accesses replaced sprintf() calls blindly with snprintf(). However, since snprintf() returns the would-be-printed size, not the actually output size, the length calculation can still go over the given limit. Use scnprintf() instead of snprintf(), which returns the actually output letters, for addressing the potential out-of-bounds access properly.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50100", "url": "https://ubuntu.com/security/CVE-2024-50100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: gadget: dummy-hcd: Fix \"task hung\" problem The syzbot fuzzer has been encountering \"task hung\" problems ever since the dummy-hcd driver was changed to use hrtimers instead of regular timers. It turns out that the problems are caused by a subtle difference between the timer_pending() and hrtimer_active() APIs. The changeover blindly replaced the first by the second. However, timer_pending() returns True when the timer is queued but not when its callback is running, whereas hrtimer_active() returns True when the hrtimer is queued _or_ its callback is running. This difference occasionally caused dummy_urb_enqueue() to think that the callback routine had not yet started when in fact it was almost finished. As a result the hrtimer was not restarted, which made it impossible for the driver to dequeue later the URB that was just enqueued. This caused usb_kill_urb() to hang, and things got worse from there. Since hrtimers have no API for telling when they are queued and the callback isn't running, the driver must keep track of this for itself. That's what this patch does, adding a new \"timer_pending\" flag and setting or clearing it at the appropriate times.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50075", "url": "https://ubuntu.com/security/CVE-2024-50075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xhci: tegra: fix checked USB2 port number If USB virtualizatoin is enabled, USB2 ports are shared between all Virtual Functions. The USB2 port number owned by an USB2 root hub in a Virtual Function may be less than total USB2 phy number supported by the Tegra XUSB controller. Using total USB2 phy number as port number to check all PORTSC values would cause invalid memory access. [ 116.923438] Unable to handle kernel paging request at virtual address 006c622f7665642f ... [ 117.213640] Call trace: [ 117.216783] tegra_xusb_enter_elpg+0x23c/0x658 [ 117.222021] tegra_xusb_runtime_suspend+0x40/0x68 [ 117.227260] pm_generic_runtime_suspend+0x30/0x50 [ 117.232847] __rpm_callback+0x84/0x3c0 [ 117.237038] rpm_suspend+0x2dc/0x740 [ 117.241229] pm_runtime_work+0xa0/0xb8 [ 117.245769] process_scheduled_works+0x24c/0x478 [ 117.251007] worker_thread+0x23c/0x328 [ 117.255547] kthread+0x104/0x1b0 [ 117.259389] ret_from_fork+0x10/0x20 [ 117.263582] Code: 54000222 f9461ae8 f8747908 b4ffff48 (f9400100)", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50076", "url": "https://ubuntu.com/security/CVE-2024-50076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vt: prevent kernel-infoleak in con_font_get() font.data may not initialize all memory spaces depending on the implementation of vc->vc_sw->con_font_get. This may cause info-leak, so to prevent this, it is safest to modify it to initialize the allocated memory space to 0, and it generally does not affect the overall performance of the system.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50077", "url": "https://ubuntu.com/security/CVE-2024-50077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix multiple init when debugfs is disabled If bt_debugfs is not created successfully, which happens if either CONFIG_DEBUG_FS or CONFIG_DEBUG_FS_ALLOW_ALL is unset, then iso_init() returns early and does not set iso_inited to true. This means that a subsequent call to iso_init() will result in duplicate calls to proto_register(), bt_sock_register(), etc. With CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, the duplicate call to proto_register() triggers this BUG(): list_add double add: new=ffffffffc0b280d0, prev=ffffffffbab56250, next=ffffffffc0b280d0. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:35! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 2 PID: 887 Comm: bluetoothd Not tainted 6.10.11-1-ao-desktop #1 RIP: 0010:__list_add_valid_or_report+0x9a/0xa0 ... __list_add_valid_or_report+0x9a/0xa0 proto_register+0x2b5/0x340 iso_init+0x23/0x150 [bluetooth] set_iso_socket_func+0x68/0x1b0 [bluetooth] kmem_cache_free+0x308/0x330 hci_sock_sendmsg+0x990/0x9e0 [bluetooth] __sock_sendmsg+0x7b/0x80 sock_write_iter+0x9a/0x110 do_iter_readv_writev+0x11d/0x220 vfs_writev+0x180/0x3e0 do_writev+0xca/0x100 ... This change removes the early return. The check for iso_debugfs being NULL was unnecessary, it is always NULL when iso_inited is false.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50078", "url": "https://ubuntu.com/security/CVE-2024-50078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Call iso_exit() on module unload If iso_init() has been called, iso_exit() must be called on module unload. Without that, the struct proto that iso_init() registered with proto_register() becomes invalid, which could cause unpredictable problems later. In my case, with CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, loading the module again usually triggers this BUG(): list_add corruption. next->prev should be prev (ffffffffb5355fd0), but was 0000000000000068. (next=ffffffffc0a010d0). ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:29! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 4159 Comm: modprobe Not tainted 6.10.11-4+bt2-ao-desktop #1 RIP: 0010:__list_add_valid_or_report+0x61/0xa0 ... __list_add_valid_or_report+0x61/0xa0 proto_register+0x299/0x320 hci_sock_init+0x16/0xc0 [bluetooth] bt_init+0x68/0xd0 [bluetooth] __pfx_bt_init+0x10/0x10 [bluetooth] do_one_initcall+0x80/0x2f0 do_init_module+0x8b/0x230 __do_sys_init_module+0x15f/0x190 do_syscall_64+0x68/0x110 ...", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50198", "url": "https://ubuntu.com/security/CVE-2024-50198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: veml6030: fix IIO device retrieval from embedded device The dev pointer that is received as an argument in the in_illuminance_period_available_show function references the device embedded in the IIO device, not in the i2c client. dev_to_iio_dev() must be used to accessthe right data. The current implementation leads to a segmentation fault on every attempt to read the attribute because indio_dev gets a NULL assignment. This bug has been present since the first appearance of the driver, apparently since the last version (V6) before getting applied. A constant attribute was used until then, and the last modifications might have not been tested again.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50201", "url": "https://ubuntu.com/security/CVE-2024-50201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: Fix encoder->possible_clones Include the encoder itself in its possible_clones bitmask. In the past nothing validated that drivers were populating possible_clones correctly, but that changed in commit 74d2aacbe840 (\"drm: Validate encoder->possible_clones\"). Looks like radeon never got the memo and is still not following the rules 100% correctly. This results in some warnings during driver initialization: Bogus possible_clones: [ENCODER:46:TV-46] possible_clones=0x4 (full encoder mask=0x7) WARNING: CPU: 0 PID: 170 at drivers/gpu/drm/drm_mode_config.c:615 drm_mode_config_validate+0x113/0x39c ... (cherry picked from commit 3b6e7d40649c0d75572039aff9d0911864c689db)", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50098", "url": "https://ubuntu.com/security/CVE-2024-50098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Set SDEV_OFFLINE when UFS is shut down There is a history of deadlock if reboot is performed at the beginning of booting. SDEV_QUIESCE was set for all LU's scsi_devices by UFS shutdown, and at that time the audio driver was waiting on blk_mq_submit_bio() holding a mutex_lock while reading the fw binary. After that, a deadlock issue occurred while audio driver shutdown was waiting for mutex_unlock of blk_mq_submit_bio(). To solve this, set SDEV_OFFLINE for all LUs except WLUN, so that any I/O that comes down after a UFS shutdown will return an error. [ 31.907781]I[0: swapper/0: 0] 1 130705007 1651079834 11289729804 0 D( 2) 3 ffffff882e208000 * init [device_shutdown] [ 31.907793]I[0: swapper/0: 0] Mutex: 0xffffff8849a2b8b0: owner[0xffffff882e28cb00 kworker/6:0 :49] [ 31.907806]I[0: swapper/0: 0] Call trace: [ 31.907810]I[0: swapper/0: 0] __switch_to+0x174/0x338 [ 31.907819]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc [ 31.907826]I[0: swapper/0: 0] schedule+0x7c/0xe8 [ 31.907834]I[0: swapper/0: 0] schedule_preempt_disabled+0x24/0x40 [ 31.907842]I[0: swapper/0: 0] __mutex_lock+0x408/0xdac [ 31.907849]I[0: swapper/0: 0] __mutex_lock_slowpath+0x14/0x24 [ 31.907858]I[0: swapper/0: 0] mutex_lock+0x40/0xec [ 31.907866]I[0: swapper/0: 0] device_shutdown+0x108/0x280 [ 31.907875]I[0: swapper/0: 0] kernel_restart+0x4c/0x11c [ 31.907883]I[0: swapper/0: 0] __arm64_sys_reboot+0x15c/0x280 [ 31.907890]I[0: swapper/0: 0] invoke_syscall+0x70/0x158 [ 31.907899]I[0: swapper/0: 0] el0_svc_common+0xb4/0xf4 [ 31.907909]I[0: swapper/0: 0] do_el0_svc+0x2c/0xb0 [ 31.907918]I[0: swapper/0: 0] el0_svc+0x34/0xe0 [ 31.907928]I[0: swapper/0: 0] el0t_64_sync_handler+0x68/0xb4 [ 31.907937]I[0: swapper/0: 0] el0t_64_sync+0x1a0/0x1a4 [ 31.908774]I[0: swapper/0: 0] 49 0 11960702 11236868007 0 D( 2) 6 ffffff882e28cb00 * kworker/6:0 [__bio_queue_enter] [ 31.908783]I[0: swapper/0: 0] Call trace: [ 31.908788]I[0: swapper/0: 0] __switch_to+0x174/0x338 [ 31.908796]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc [ 31.908803]I[0: swapper/0: 0] schedule+0x7c/0xe8 [ 31.908811]I[0: swapper/0: 0] __bio_queue_enter+0xb8/0x178 [ 31.908818]I[0: swapper/0: 0] blk_mq_submit_bio+0x194/0x67c [ 31.908827]I[0: swapper/0: 0] __submit_bio+0xb8/0x19c", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50079", "url": "https://ubuntu.com/security/CVE-2024-50079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/sqpoll: ensure task state is TASK_RUNNING when running task_work When the sqpoll is exiting and cancels pending work items, it may need to run task_work. If this happens from within io_uring_cancel_generic(), then it may be under waiting for the io_uring_task waitqueue. This results in the below splat from the scheduler, as the ring mutex may be attempted grabbed while in a TASK_INTERRUPTIBLE state. Ensure that the task state is set appropriately for that, just like what is done for the other cases in io_run_task_work(). do not call blocking ops when !TASK_RUNNING; state=1 set at [<0000000029387fd2>] prepare_to_wait+0x88/0x2fc WARNING: CPU: 6 PID: 59939 at kernel/sched/core.c:8561 __might_sleep+0xf4/0x140 Modules linked in: CPU: 6 UID: 0 PID: 59939 Comm: iou-sqp-59938 Not tainted 6.12.0-rc3-00113-g8d020023b155 #7456 Hardware name: linux,dummy-virt (DT) pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : __might_sleep+0xf4/0x140 lr : __might_sleep+0xf4/0x140 sp : ffff80008c5e7830 x29: ffff80008c5e7830 x28: ffff0000d93088c0 x27: ffff60001c2d7230 x26: dfff800000000000 x25: ffff0000e16b9180 x24: ffff80008c5e7a50 x23: 1ffff000118bcf4a x22: ffff0000e16b9180 x21: ffff0000e16b9180 x20: 000000000000011b x19: ffff80008310fac0 x18: 1ffff000118bcd90 x17: 30303c5b20746120 x16: 74657320313d6574 x15: 0720072007200720 x14: 0720072007200720 x13: 0720072007200720 x12: ffff600036c64f0b x11: 1fffe00036c64f0a x10: ffff600036c64f0a x9 : dfff800000000000 x8 : 00009fffc939b0f6 x7 : ffff0001b6327853 x6 : 0000000000000001 x5 : ffff0001b6327850 x4 : ffff600036c64f0b x3 : ffff8000803c35bc x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000e16b9180 Call trace: __might_sleep+0xf4/0x140 mutex_lock+0x84/0x124 io_handle_tw_list+0xf4/0x260 tctx_task_work_run+0x94/0x340 io_run_task_work+0x1ec/0x3c0 io_uring_cancel_generic+0x364/0x524 io_sq_thread+0x820/0x124c ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50080", "url": "https://ubuntu.com/security/CVE-2024-50080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: don't allow user copy for unprivileged device UBLK_F_USER_COPY requires userspace to call write() on ublk char device for filling request buffer, and unprivileged device can't be trusted. So don't allow user copy for unprivileged device.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50081", "url": "https://ubuntu.com/security/CVE-2024-50081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-mq: setup queue ->tag_set before initializing hctx Commit 7b815817aa58 (\"blk-mq: add helper for checking if one CPU is mapped to specified hctx\") needs to check queue mapping via tag set in hctx's cpuhp handler. However, q->tag_set may not be setup yet when the cpuhp handler is enabled, then kernel oops is triggered. Fix the issue by setup queue tag_set before initializing hctx.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50082", "url": "https://ubuntu.com/security/CVE-2024-50082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race We're seeing crashes from rq_qos_wake_function that look like this: BUG: unable to handle page fault for address: ffffafe180a40084 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 100000067 P4D 100000067 PUD 10027c067 PMD 10115d067 PTE 0 Oops: Oops: 0002 [#1] PREEMPT SMP PTI CPU: 17 UID: 0 PID: 0 Comm: swapper/17 Not tainted 6.12.0-rc3-00013-geca631b8fe80 #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:_raw_spin_lock_irqsave+0x1d/0x40 Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 9c 41 5c fa 65 ff 05 62 97 30 4c 31 c0 ba 01 00 00 00 0f b1 17 75 0a 4c 89 e0 41 5c c3 cc cc cc cc 89 c6 e8 2c 0b 00 RSP: 0018:ffffafe180580ca0 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffffafe180a3f7a8 RCX: 0000000000000011 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffffafe180a40084 RBP: 0000000000000000 R08: 00000000001e7240 R09: 0000000000000011 R10: 0000000000000028 R11: 0000000000000888 R12: 0000000000000002 R13: ffffafe180a40084 R14: 0000000000000000 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff9aaf1f280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffafe180a40084 CR3: 000000010e428002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: try_to_wake_up+0x5a/0x6a0 rq_qos_wake_function+0x71/0x80 __wake_up_common+0x75/0xa0 __wake_up+0x36/0x60 scale_up.part.0+0x50/0x110 wb_timer_fn+0x227/0x450 ... So rq_qos_wake_function() calls wake_up_process(data->task), which calls try_to_wake_up(), which faults in raw_spin_lock_irqsave(&p->pi_lock). p comes from data->task, and data comes from the waitqueue entry, which is stored on the waiter's stack in rq_qos_wait(). Analyzing the core dump with drgn, I found that the waiter had already woken up and moved on to a completely unrelated code path, clobbering what was previously data->task. Meanwhile, the waker was passing the clobbered garbage in data->task to wake_up_process(), leading to the crash. What's happening is that in between rq_qos_wake_function() deleting the waitqueue entry and calling wake_up_process(), rq_qos_wait() is finding that it already got a token and returning. The race looks like this: rq_qos_wait() rq_qos_wake_function() ============================================================== prepare_to_wait_exclusive() data->got_token = true; list_del_init(&curr->entry); if (data.got_token) break; finish_wait(&rqw->wait, &data.wq); ^- returns immediately because list_empty_careful(&wq_entry->entry) is true ... return, go do something else ... wake_up_process(data->task) (NO LONGER VALID!)-^ Normally, finish_wait() is supposed to synchronize against the waker. But, as noted above, it is returning immediately because the waitqueue entry has already been removed from the waitqueue. The bug is that rq_qos_wake_function() is accessing the waitqueue entry AFTER deleting it. Note that autoremove_wake_function() wakes the waiter and THEN deletes the waitqueue entry, which is the proper order. Fix it by swapping the order. We also need to use list_del_init_careful() to match the list_empty_careful() in finish_wait().", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50101", "url": "https://ubuntu.com/security/CVE-2024-50101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI devices Previously, the domain_context_clear() function incorrectly called pci_for_each_dma_alias() to set up context entries for non-PCI devices. This could lead to kernel hangs or other unexpected behavior. Add a check to only call pci_for_each_dma_alias() for PCI devices. For non-PCI devices, domain_context_clear_one() is called directly.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50083", "url": "https://ubuntu.com/security/CVE-2024-50083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix mptcp DSS corruption due to large pmtu xmit Syzkaller was able to trigger a DSS corruption: TCP: request_sock_subflow_v4: Possible SYN flooding on port [::]:20002. Sending cookies. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 5227 at net/mptcp/protocol.c:695 __mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695 Modules linked in: CPU: 0 UID: 0 PID: 5227 Comm: syz-executor350 Not tainted 6.11.0-syzkaller-08829-gaf9c191ac2a0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:__mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695 Code: 0f b6 dc 31 ff 89 de e8 b5 dd ea f5 89 d8 48 81 c4 50 01 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 98 da ea f5 90 <0f> 0b 90 e9 47 ff ff ff e8 8a da ea f5 90 0f 0b 90 e9 99 e0 ff ff RSP: 0018:ffffc90000006db8 EFLAGS: 00010246 RAX: ffffffff8ba9df18 RBX: 00000000000055f0 RCX: ffff888030023c00 RDX: 0000000000000100 RSI: 00000000000081e5 RDI: 00000000000055f0 RBP: 1ffff110062bf1ae R08: ffffffff8ba9cf12 R09: 1ffff110062bf1b8 R10: dffffc0000000000 R11: ffffed10062bf1b9 R12: 0000000000000000 R13: dffffc0000000000 R14: 00000000700cec61 R15: 00000000000081e5 FS: 000055556679c380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020287000 CR3: 0000000077892000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: move_skbs_to_msk net/mptcp/protocol.c:811 [inline] mptcp_data_ready+0x29c/0xa90 net/mptcp/protocol.c:854 subflow_data_ready+0x34a/0x920 net/mptcp/subflow.c:1490 tcp_data_queue+0x20fd/0x76c0 net/ipv4/tcp_input.c:5283 tcp_rcv_established+0xfba/0x2020 net/ipv4/tcp_input.c:6237 tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915 tcp_v4_rcv+0x2dc0/0x37f0 net/ipv4/tcp_ipv4.c:2350 ip_protocol_deliver_rcu+0x22e/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x341/0x5f0 net/ipv4/ip_input.c:233 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314 __netif_receive_skb_one_core net/core/dev.c:5662 [inline] __netif_receive_skb+0x2bf/0x650 net/core/dev.c:5775 process_backlog+0x662/0x15b0 net/core/dev.c:6107 __napi_poll+0xcb/0x490 net/core/dev.c:6771 napi_poll net/core/dev.c:6840 [inline] net_rx_action+0x89b/0x1240 net/core/dev.c:6962 handle_softirqs+0x2c5/0x980 kernel/softirq.c:554 do_softirq+0x11b/0x1e0 kernel/softirq.c:455 __local_bh_enable_ip+0x1bb/0x200 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0x1764/0x3e80 net/core/dev.c:4451 dev_queue_xmit include/linux/netdevice.h:3094 [inline] neigh_hh_output include/net/neighbour.h:526 [inline] neigh_output include/net/neighbour.h:540 [inline] ip_finish_output2+0xd41/0x1390 net/ipv4/ip_output.c:236 ip_local_out net/ipv4/ip_output.c:130 [inline] __ip_queue_xmit+0x118c/0x1b80 net/ipv4/ip_output.c:536 __tcp_transmit_skb+0x2544/0x3b30 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_mtu_probe net/ipv4/tcp_output.c:2547 [inline] tcp_write_xmit+0x641d/0x6bf0 net/ipv4/tcp_output.c:2752 __tcp_push_pending_frames+0x9b/0x360 net/ipv4/tcp_output.c:3015 tcp_push_pending_frames include/net/tcp.h:2107 [inline] tcp_data_snd_check net/ipv4/tcp_input.c:5714 [inline] tcp_rcv_established+0x1026/0x2020 net/ipv4/tcp_input.c:6239 tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915 sk_backlog_rcv include/net/sock.h:1113 [inline] __release_sock+0x214/0x350 net/core/sock.c:3072 release_sock+0x61/0x1f0 net/core/sock.c:3626 mptcp_push_ ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50068", "url": "https://ubuntu.com/security/CVE-2024-50068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/tests/sysfs-kunit.h: fix memory leak in damon_sysfs_test_add_targets() The sysfs_target->regions allocated in damon_sysfs_regions_alloc() is not freed in damon_sysfs_test_add_targets(), which cause the following memory leak, free it to fix it. \tunreferenced object 0xffffff80c2a8db80 (size 96): \t comm \"kunit_try_catch\", pid 187, jiffies 4294894363 \t hex dump (first 32 bytes): \t 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ \t 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ \t backtrace (crc 0): \t [<0000000001e3714d>] kmemleak_alloc+0x34/0x40 \t [<000000008e6835c1>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000001286d9f8>] damon_sysfs_test_add_targets+0x1cc/0x738 \t [<0000000032ef8f77>] kunit_try_run_case+0x13c/0x3ac \t [<00000000f3edea23>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000adf936cf>] kthread+0x2e8/0x374 \t [<0000000041bb1628>] ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50199", "url": "https://ubuntu.com/security/CVE-2024-50199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/swapfile: skip HugeTLB pages for unuse_vma I got a bad pud error and lost a 1GB HugeTLB when calling swapoff. The problem can be reproduced by the following steps: 1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory. 2. Swapout the above anonymous memory. 3. run swapoff and we will get a bad pud error in kernel message: mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7) We can tell that pud_clear_bad is called by pud_none_or_clear_bad in unuse_pud_range() by ftrace. And therefore the HugeTLB pages will never be freed because we lost it from page table. We can skip HugeTLB pages for unuse_vma to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50066", "url": "https://ubuntu.com/security/CVE-2024-50066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mremap: fix move_normal_pmd/retract_page_tables race In mremap(), move_page_tables() looks at the type of the PMD entry and the specified address range to figure out by which method the next chunk of page table entries should be moved. At that point, the mmap_lock is held in write mode, but no rmap locks are held yet. For PMD entries that point to page tables and are fully covered by the source address range, move_pgt_entry(NORMAL_PMD, ...) is called, which first takes rmap locks, then does move_normal_pmd(). move_normal_pmd() takes the necessary page table locks at source and destination, then moves an entire page table from the source to the destination. The problem is: The rmap locks, which protect against concurrent page table removal by retract_page_tables() in the THP code, are only taken after the PMD entry has been read and it has been decided how to move it. So we can race as follows (with two processes that have mappings of the same tmpfs file that is stored on a tmpfs mount with huge=advise); note that process A accesses page tables through the MM while process B does it through the file rmap: process A process B ========= ========= mremap mremap_to move_vma move_page_tables get_old_pmd alloc_new_pmd *** PREEMPT *** madvise(MADV_COLLAPSE) do_madvise madvise_walk_vmas madvise_vma_behavior madvise_collapse hpage_collapse_scan_file collapse_file retract_page_tables i_mmap_lock_read(mapping) pmdp_collapse_flush i_mmap_unlock_read(mapping) move_pgt_entry(NORMAL_PMD, ...) take_rmap_locks move_normal_pmd drop_rmap_locks When this happens, move_normal_pmd() can end up creating bogus PMD entries in the line `pmd_populate(mm, new_pmd, pmd_pgtable(pmd))`. The effect depends on arch-specific and machine-specific details; on x86, you can end up with physical page 0 mapped as a page table, which is likely exploitable for user->kernel privilege escalation. Fix the race by letting process B recheck that the PMD still points to a page table after the rmap locks have been taken. Otherwise, we bail and let the caller fall back to the PTE-level copying path, which will then bail immediately at the pmd_none() check. Bug reachability: Reaching this bug requires that you can create shmem/file THP mappings - anonymous THP uses different code that doesn't zap stuff under rmap locks. File THP is gated on an experimental config flag (CONFIG_READ_ONLY_THP_FOR_FS), so on normal distro kernels you need shmem THP to hit this bug. As far as I know, getting shmem THP normally requires that you can mount your own tmpfs with the right mount flags, which would require creating your own user+mount namespace; though I don't know if some distros maybe enable shmem THP by default or something like that. Bug impact: This issue can likely be used for user->kernel privilege escalation when it is reachable.", "cve_priority": "medium", "cve_public_date": "2024-10-23 06:15:00 UTC" }, { "cve": "CVE-2024-50202", "url": "https://ubuntu.com/security/CVE-2024-50202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: propagate directory read errors from nilfs_find_entry() Syzbot reported that a task hang occurs in vcs_open() during a fuzzing test for nilfs2. The root cause of this problem is that in nilfs_find_entry(), which searches for directory entries, ignores errors when loading a directory page/folio via nilfs_get_folio() fails. If the filesystem images is corrupted, and the i_size of the directory inode is large, and the directory page/folio is successfully read but fails the sanity check, for example when it is zero-filled, nilfs_check_folio() may continue to spit out error messages in bursts. Fix this issue by propagating the error to the callers when loading a page/folio fails in nilfs_find_entry(). The current interface of nilfs_find_entry() and its callers is outdated and cannot propagate error codes such as -EIO and -ENOMEM returned via nilfs_find_entry(), so fix it together.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50200", "url": "https://ubuntu.com/security/CVE-2024-50200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: maple_tree: correct tree corruption on spanning store Patch series \"maple_tree: correct tree corruption on spanning store\", v3. There has been a nasty yet subtle maple tree corruption bug that appears to have been in existence since the inception of the algorithm. This bug seems far more likely to happen since commit f8d112a4e657 (\"mm/mmap: avoid zeroing vma tree in mmap_region()\"), which is the point at which reports started to be submitted concerning this bug. We were made definitely aware of the bug thanks to the kind efforts of Bert Karwatzki who helped enormously in my being able to track this down and identify the cause of it. The bug arises when an attempt is made to perform a spanning store across two leaf nodes, where the right leaf node is the rightmost child of the shared parent, AND the store completely consumes the right-mode node. This results in mas_wr_spanning_store() mitakenly duplicating the new and existing entries at the maximum pivot within the range, and thus maple tree corruption. The fix patch corrects this by detecting this scenario and disallowing the mistaken duplicate copy. The fix patch commit message goes into great detail as to how this occurs. This series also includes a test which reliably reproduces the issue, and asserts that the fix works correctly. Bert has kindly tested the fix and confirmed it resolved his issues. Also Mikhail Gavrilov kindly reported what appears to be precisely the same bug, which this fix should also resolve. This patch (of 2): There has been a subtle bug present in the maple tree implementation from its inception. This arises from how stores are performed - when a store occurs, it will overwrite overlapping ranges and adjust the tree as necessary to accommodate this. A range may always ultimately span two leaf nodes. In this instance we walk the two leaf nodes, determine which elements are not overwritten to the left and to the right of the start and end of the ranges respectively and then rebalance the tree to contain these entries and the newly inserted one. This kind of store is dubbed a 'spanning store' and is implemented by mas_wr_spanning_store(). In order to reach this stage, mas_store_gfp() invokes mas_wr_preallocate(), mas_wr_store_type() and mas_wr_walk() in turn to walk the tree and update the object (mas) to traverse to the location where the write should be performed, determining its store type. When a spanning store is required, this function returns false stopping at the parent node which contains the target range, and mas_wr_store_type() marks the mas->store_type as wr_spanning_store to denote this fact. When we go to perform the store in mas_wr_spanning_store(), we first determine the elements AFTER the END of the range we wish to store (that is, to the right of the entry to be inserted) - we do this by walking to the NEXT pivot in the tree (i.e. r_mas.last + 1), starting at the node we have just determined contains the range over which we intend to write. We then turn our attention to the entries to the left of the entry we are inserting, whose state is represented by l_mas, and copy these into a 'big node', which is a special node which contains enough slots to contain two leaf node's worth of data. We then copy the entry we wish to store immediately after this - the copy and the insertion of the new entry is performed by mas_store_b_node(). After this we copy the elements to the right of the end of the range which we are inserting, if we have not exceeded the length of the node (i.e. r_mas.offset <= r_mas.end). Herein lies the bug - under very specific circumstances, this logic can break and corrupt the maple tree. Consider the following tree: Height 0 Root Node / \\ pivot = 0xffff / \\ pivot = ULONG_MAX / ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50084", "url": "https://ubuntu.com/security/CVE-2024-50084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: microchip: vcap api: Fix memory leaks in vcap_api_encode_rule_test() Commit a3c1e45156ad (\"net: microchip: vcap: Fix use-after-free error in kunit test\") fixed the use-after-free error, but introduced below memory leaks by removing necessary vcap_free_rule(), add it to fix it. \tunreferenced object 0xffffff80ca58b700 (size 192): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898264 \t hex dump (first 32 bytes): \t 00 12 7a 00 05 00 00 00 0a 00 00 00 64 00 00 00 ..z.........d... \t 00 00 00 00 00 00 00 00 00 04 0b cc 80 ff ff ff ................ \t backtrace (crc 9c09c3fe): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<0000000040a01b8d>] vcap_alloc_rule+0x3cc/0x9c4 \t [<000000003fe86110>] vcap_api_encode_rule_test+0x1ac/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0400 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898265 \t hex dump (first 32 bytes): \t 80 04 0b cc 80 ff ff ff 18 b7 58 ca 80 ff ff ff ..........X..... \t 39 00 00 00 02 00 00 00 06 05 04 03 02 01 ff ff 9............... \t backtrace (crc daf014e9): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<00000000dfdb1e81>] vcap_api_encode_rule_test+0x224/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0700 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898265 \t hex dump (first 32 bytes): \t 80 07 0b cc 80 ff ff ff 28 b7 58 ca 80 ff ff ff ........(.X..... \t 3c 00 00 00 00 00 00 00 01 2f 03 b3 ec ff ff ff <......../...... \t backtrace (crc 8d877792): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000006eadfab7>] vcap_rule_add_action+0x2d0/0x52c \t [<00000000323475d1>] vcap_api_encode_rule_test+0x4d4/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0900 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898266 \t hex dump (first 32 bytes): \t 80 09 0b cc 80 ff ff ff 80 06 0b cc 80 ff ff ff ................ \t 7d 00 00 00 01 00 00 00 00 00 00 00 ff 00 00 00 }............... \t backtrace (crc 34181e56): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<00000000991e3564>] vcap_val_rule+0xcf0/0x13e8 \t [<00000000fc9868e5>] vcap_api_encode_rule_test+0x678/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0980 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898266 \t hex dump (first 32 bytes): \t 18 b7 58 ca 80 ff ff ff 00 09 0b cc 80 ff ff ff ..X............. \t 67 00 00 00 00 00 00 00 01 01 74 88 c0 ff ff ff g.........t..... \t backtrace (crc 275fd9be): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<000000001396a1a2>] test_add_de ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50194", "url": "https://ubuntu.com/security/CVE-2024-50194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Fix uprobes for big-endian kernels The arm64 uprobes code is broken for big-endian kernels as it doesn't convert the in-memory instruction encoding (which is always little-endian) into the kernel's native endianness before analyzing and simulating instructions. This may result in a few distinct problems: * The kernel may may erroneously reject probing an instruction which can safely be probed. * The kernel may erroneously erroneously permit stepping an instruction out-of-line when that instruction cannot be stepped out-of-line safely. * The kernel may erroneously simulate instruction incorrectly dur to interpretting the byte-swapped encoding. The endianness mismatch isn't caught by the compiler or sparse because: * The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so the compiler and sparse have no idea these contain a little-endian 32-bit value. The core uprobes code populates these with a memcpy() which similarly does not handle endianness. * While the uprobe_opcode_t type is an alias for __le32, both arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[] to the similarly-named probe_opcode_t, which is an alias for u32. Hence there is no endianness conversion warning. Fix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and adding the appropriate __le32_to_cpu() conversions prior to consuming the instruction encoding. The core uprobes copies these fields as opaque ranges of bytes, and so is unaffected by this change. At the same time, remove MAX_UINSN_BYTES and consistently use AARCH64_INSN_SIZE for clarity. Tested with the following: | #include | #include | | #define noinline __attribute__((noinline)) | | static noinline void *adrp_self(void) | { | void *addr; | | asm volatile( | \" adrp %x0, adrp_self\\n\" | \" add %x0, %x0, :lo12:adrp_self\\n\" | : \"=r\" (addr)); | } | | | int main(int argc, char *argv) | { | void *ptr = adrp_self(); | bool equal = (ptr == adrp_self); | | printf(\"adrp_self => %p\\n\" | \"adrp_self() => %p\\n\" | \"%s\\n\", | adrp_self, ptr, equal ? \"EQUAL\" : \"NOT EQUAL\"); | | return 0; | } .... where the adrp_self() function was compiled to: | 00000000004007e0 : | 4007e0: 90000000 adrp x0, 400000 <__ehdr_start> | 4007e4: 911f8000 add x0, x0, #0x7e0 | 4007e8: d65f03c0 ret Before this patch, the ADRP is not recognized, and is assumed to be steppable, resulting in corruption of the result: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0xffffffffff7e0 | NOT EQUAL After this patch, the ADRP is correctly recognized and simulated: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50099", "url": "https://ubuntu.com/security/CVE-2024-50099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Remove broken LDR (literal) uprobe support The simulate_ldr_literal() and simulate_ldrsw_literal() functions are unsafe to use for uprobes. Both functions were originally written for use with kprobes, and access memory with plain C accesses. When uprobes was added, these were reused unmodified even though they cannot safely access user memory. There are three key problems: 1) The plain C accesses do not have corresponding extable entries, and thus if they encounter a fault the kernel will treat these as unintentional accesses to user memory, resulting in a BUG() which will kill the kernel thread, and likely lead to further issues (e.g. lockup or panic()). 2) The plain C accesses are subject to HW PAN and SW PAN, and so when either is in use, any attempt to simulate an access to user memory will fault. Thus neither simulate_ldr_literal() nor simulate_ldrsw_literal() can do anything useful when simulating a user instruction on any system with HW PAN or SW PAN. 3) The plain C accesses are privileged, as they run in kernel context, and in practice can access a small range of kernel virtual addresses. The instructions they simulate have a range of +/-1MiB, and since the simulated instructions must itself be a user instructions in the TTBR0 address range, these can address the final 1MiB of the TTBR1 acddress range by wrapping downwards from an address in the first 1MiB of the TTBR0 address range. In contemporary kernels the last 8MiB of TTBR1 address range is reserved, and accesses to this will always fault, meaning this is no worse than (1). Historically, it was theoretically possible for the linear map or vmemmap to spill into the final 8MiB of the TTBR1 address range, but in practice this is extremely unlikely to occur as this would require either: * Having enough physical memory to fill the entire linear map all the way to the final 1MiB of the TTBR1 address range. * Getting unlucky with KASLR randomization of the linear map such that the populated region happens to overlap with the last 1MiB of the TTBR address range. ... and in either case if we were to spill into the final page there would be larger problems as the final page would alias with error pointers. Practically speaking, (1) and (2) are the big issues. Given there have been no reports of problems since the broken code was introduced, it appears that no-one is relying on probing these instructions with uprobes. Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW (literal), limiting the use of simulate_ldr_literal() and simulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR (literal) and LDRSW (literal) will be rejected as arm_probe_decode_insn() will return INSN_REJECTED. In future we can consider introducing working uprobes support for these instructions, but this will require more significant work.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50195", "url": "https://ubuntu.com/security/CVE-2024-50195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-clock: Fix missing timespec64 check in pc_clock_settime() As Andrew pointed out, it will make sense that the PTP core checked timespec64 struct's tv_sec and tv_nsec range before calling ptp->info->settime64(). As the man manual of clock_settime() said, if tp.tv_sec is negative or tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL, which include dynamic clocks which handles PTP clock, and the condition is consistent with timespec64_valid(). As Thomas suggested, timespec64_valid() only check the timespec is valid, but not ensure that the time is in a valid range, so check it ahead using timespec64_valid_strict() in pc_clock_settime() and return -EINVAL if not valid. There are some drivers that use tp->tv_sec and tp->tv_nsec directly to write registers without validity checks and assume that the higher layer has checked it, which is dangerous and will benefit from this, such as hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(), and some drivers can remove the checks of itself.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50085", "url": "https://ubuntu.com/security/CVE-2024-50085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: fix UaF read in mptcp_pm_nl_rm_addr_or_subflow Syzkaller reported this splat: ================================================================== BUG: KASAN: slab-use-after-free in mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881 Read of size 4 at addr ffff8880569ac858 by task syz.1.2799/14662 CPU: 0 UID: 0 PID: 14662 Comm: syz.1.2799 Not tainted 6.12.0-rc2-syzkaller-00307-g36c254515dc6 #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+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881 mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:914 [inline] mptcp_nl_remove_id_zero_address+0x305/0x4a0 net/mptcp/pm_netlink.c:1572 mptcp_pm_nl_del_addr_doit+0x5c9/0x770 net/mptcp/pm_netlink.c:1603 genl_family_rcv_msg_doit+0x202/0x2f0 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x565/0x800 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x165/0x410 net/netlink/af_netlink.c:2551 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1331 [inline] netlink_unicast+0x53c/0x7f0 net/netlink/af_netlink.c:1357 netlink_sendmsg+0x8b8/0xd70 net/netlink/af_netlink.c:1901 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg net/socket.c:744 [inline] ____sys_sendmsg+0x9ae/0xb40 net/socket.c:2607 ___sys_sendmsg+0x135/0x1e0 net/socket.c:2661 __sys_sendmsg+0x117/0x1f0 net/socket.c:2690 do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline] __do_fast_syscall_32+0x73/0x120 arch/x86/entry/common.c:386 do_fast_syscall_32+0x32/0x80 arch/x86/entry/common.c:411 entry_SYSENTER_compat_after_hwframe+0x84/0x8e RIP: 0023:0xf7fe4579 Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00 RSP: 002b:00000000f574556c EFLAGS: 00000296 ORIG_RAX: 0000000000000172 RAX: ffffffffffffffda RBX: 000000000000000b RCX: 0000000020000140 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000296 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Allocated by task 5387: 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 kmalloc_noprof include/linux/slab.h:878 [inline] kzalloc_noprof include/linux/slab.h:1014 [inline] subflow_create_ctx+0x87/0x2a0 net/mptcp/subflow.c:1803 subflow_ulp_init+0xc3/0x4d0 net/mptcp/subflow.c:1956 __tcp_set_ulp net/ipv4/tcp_ulp.c:146 [inline] tcp_set_ulp+0x326/0x7f0 net/ipv4/tcp_ulp.c:167 mptcp_subflow_create_socket+0x4ae/0x10a0 net/mptcp/subflow.c:1764 __mptcp_subflow_connect+0x3cc/0x1490 net/mptcp/subflow.c:1592 mptcp_pm_create_subflow_or_signal_addr+0xbda/0x23a0 net/mptcp/pm_netlink.c:642 mptcp_pm_nl_fully_established net/mptcp/pm_netlink.c:650 [inline] mptcp_pm_nl_work+0x3a1/0x4f0 net/mptcp/pm_netlink.c:943 mptcp_worker+0x15a/0x1240 net/mptcp/protocol.c:2777 process_one_work+0x958/0x1b30 kernel/workqueue.c:3229 process_scheduled_works kernel/workqueue.c:3310 [inline] worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/ke ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50086", "url": "https://ubuntu.com/security/CVE-2024-50086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix user-after-free from session log off There is racy issue between smb2 session log off and smb2 session setup. It will cause user-after-free from session log off. This add session_lock when setting SMB2_SESSION_EXPIRED and referece count to session struct not to free session while it is being used.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50087", "url": "https://ubuntu.com/security/CVE-2024-50087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix uninitialized pointer free on read_alloc_one_name() error The function read_alloc_one_name() does not initialize the name field of the passed fscrypt_str struct if kmalloc fails to allocate the corresponding buffer. Thus, it is not guaranteed that fscrypt_str.name is initialized when freeing it. This is a follow-up to the linked patch that fixes the remaining instances of the bug introduced by commit e43eec81c516 (\"btrfs: use struct qstr instead of name and namelen pairs\").", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50088", "url": "https://ubuntu.com/security/CVE-2024-50088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix uninitialized pointer free in add_inode_ref() The add_inode_ref() function does not initialize the \"name\" struct when it is declared. If any of the following calls to \"read_one_inode() returns NULL, \tdir = read_one_inode(root, parent_objectid); \tif (!dir) { \t\tret = -ENOENT; \t\tgoto out; \t} \tinode = read_one_inode(root, inode_objectid); \tif (!inode) { \t\tret = -EIO; \t\tgoto out; \t} then \"name.name\" would be freed on \"out\" before being initialized. out: \t... \tkfree(name.name); This issue was reported by Coverity with CID 1526744.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50182", "url": "https://ubuntu.com/security/CVE-2024-50182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: secretmem: disable memfd_secret() if arch cannot set direct map Return -ENOSYS from memfd_secret() syscall if !can_set_direct_map(). This is the case for example on some arm64 configurations, where marking 4k PTEs in the direct map not present can only be done if the direct map is set up at 4k granularity in the first place (as ARM's break-before-make semantics do not easily allow breaking apart large/gigantic pages). More precisely, on arm64 systems with !can_set_direct_map(), set_direct_map_invalid_noflush() is a no-op, however it returns success (0) instead of an error. This means that memfd_secret will seemingly \"work\" (e.g. syscall succeeds, you can mmap the fd and fault in pages), but it does not actually achieve its goal of removing its memory from the direct map. Note that with this patch, memfd_secret() will start erroring on systems where can_set_direct_map() returns false (arm64 with CONFIG_RODATA_FULL_DEFAULT_ENABLED=n, CONFIG_DEBUG_PAGEALLOC=n and CONFIG_KFENCE=n), but that still seems better than the current silent failure. Since CONFIG_RODATA_FULL_DEFAULT_ENABLED defaults to 'y', most arm64 systems actually have a working memfd_secret() and aren't be affected. From going through the iterations of the original memfd_secret patch series, it seems that disabling the syscall in these scenarios was the intended behavior [1] (preferred over having set_direct_map_invalid_noflush return an error as that would result in SIGBUSes at page-fault time), however the check for it got dropped between v16 [2] and v17 [3], when secretmem moved away from CMA allocations. [1]: https://lore.kernel.org/lkml/20201124164930.GK8537@kernel.org/ [2]: https://lore.kernel.org/lkml/20210121122723.3446-11-rppt@kernel.org/#t [3]: https://lore.kernel.org/lkml/20201125092208.12544-10-rppt@kernel.org/", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50019", "url": "https://ubuntu.com/security/CVE-2024-50019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kthread: unpark only parked kthread Calling into kthread unparking unconditionally is mostly harmless when the kthread is already unparked. The wake up is then simply ignored because the target is not in TASK_PARKED state. However if the kthread is per CPU, the wake up is preceded by a call to kthread_bind() which expects the task to be inactive and in TASK_PARKED state, which obviously isn't the case if it is unparked. As a result, calling kthread_stop() on an unparked per-cpu kthread triggers such a warning: \tWARNING: CPU: 0 PID: 11 at kernel/kthread.c:525 __kthread_bind_mask kernel/kthread.c:525 \t \t kthread_stop+0x17a/0x630 kernel/kthread.c:707 \t destroy_workqueue+0x136/0xc40 kernel/workqueue.c:5810 \t wg_destruct+0x1e2/0x2e0 drivers/net/wireguard/device.c:257 \t netdev_run_todo+0xe1a/0x1000 net/core/dev.c:10693 \t default_device_exit_batch+0xa14/0xa90 net/core/dev.c:11769 \t ops_exit_list net/core/net_namespace.c:178 [inline] \t cleanup_net+0x89d/0xcc0 net/core/net_namespace.c:640 \t process_one_work kernel/workqueue.c:3231 [inline] \t process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 \t worker_thread+0x86d/0xd70 kernel/workqueue.c:3393 \t kthread+0x2f0/0x390 kernel/kthread.c:389 \t ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 \t ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 \t Fix this with skipping unecessary unparking while stopping a kthread.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50096", "url": "https://ubuntu.com/security/CVE-2024-50096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/dmem: Fix vulnerability in migrate_to_ram upon copy error The `nouveau_dmem_copy_one` function ensures that the copy push command is sent to the device firmware but does not track whether it was executed successfully. In the case of a copy error (e.g., firmware or hardware failure), the copy push command will be sent via the firmware channel, and `nouveau_dmem_copy_one` will likely report success, leading to the `migrate_to_ram` function returning a dirty HIGH_USER page to the user. This can result in a security vulnerability, as a HIGH_USER page that may contain sensitive or corrupted data could be returned to the user. To prevent this vulnerability, we allocate a zero page. Thus, in case of an error, a non-dirty (zero) page will be returned to the user.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50020", "url": "https://ubuntu.com/security/CVE-2024-50020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix improper handling of refcount in ice_sriov_set_msix_vec_count() This patch addresses an issue with improper reference count handling in the ice_sriov_set_msix_vec_count() function. First, the function calls ice_get_vf_by_id(), which increments the reference count of the vf pointer. If the subsequent call to ice_get_vf_vsi() fails, the function currently returns an error without decrementing the reference count of the vf pointer, leading to a reference count leak. The correct behavior, as implemented in this patch, is to decrement the reference count using ice_put_vf(vf) before returning an error when vsi is NULL. Second, the function calls ice_sriov_get_irqs(), which sets vf->first_vector_idx. If this call returns a negative value, indicating an error, the function returns an error without decrementing the reference count of the vf pointer, resulting in another reference count leak. The patch addresses this by adding a call to ice_put_vf(vf) before returning an error when vf->first_vector_idx < 0. This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and identifying potential mismanagement of reference counts. In this case, the tool flagged the missing decrement operation as a potential issue, leading to this patch.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50021", "url": "https://ubuntu.com/security/CVE-2024-50021", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix improper handling of refcount in ice_dpll_init_rclk_pins() This patch addresses a reference count handling issue in the ice_dpll_init_rclk_pins() function. The function calls ice_dpll_get_pins(), which increments the reference count of the relevant resources. However, if the condition WARN_ON((!vsi || !vsi->netdev)) is met, the function currently returns an error without properly releasing the resources acquired by ice_dpll_get_pins(), leading to a reference count leak. To resolve this, the check has been moved to the top of the function. This ensures that the function verifies the state before any resources are acquired, avoiding the need for additional resource management in the error path. This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and detecting potential issues where resources are not properly managed. In this case, the tool flagged the missing release operation as a potential problem, which led to the development of this patch.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50022", "url": "https://ubuntu.com/security/CVE-2024-50022", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: device-dax: correct pgoff align in dax_set_mapping() pgoff should be aligned using ALIGN_DOWN() instead of ALIGN(). Otherwise, vmf->address not aligned to fault_size will be aligned to the next alignment, that can result in memory failure getting the wrong address. It's a subtle situation that only can be observed in page_mapped_in_vma() after the page is page fault handled by dev_dax_huge_fault. Generally, there is little chance to perform page_mapped_in_vma in dev-dax's page unless in specific error injection to the dax device to trigger an MCE - memory-failure. In that case, page_mapped_in_vma() will be triggered to determine which task is accessing the failure address and kill that task in the end. We used self-developed dax device (which is 2M aligned mapping) , to perform error injection to random address. It turned out that error injected to non-2M-aligned address was causing endless MCE until panic. Because page_mapped_in_vma() kept resulting wrong address and the task accessing the failure address was never killed properly: [ 3783.719419] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.049006] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.049190] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.448042] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.448186] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.792026] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.792179] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.162502] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.162633] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.461116] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.461247] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.764730] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.764859] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.042128] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.042259] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.464293] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.464423] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.818090] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.818217] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3787.085297] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3787.085424] Memory failure: 0x200c9742: recovery action for dax page: Recovered It took us several weeks to pinpoint this problem,  but we eventually used bpftrace to trace the page fault and mce address and successfully identified the issue. Joao added: ; Likely we never reproduce in production because we always pin : device-dax regions in the region align they provide (Qemu does : similarly with prealloc in hugetlb/file backed memory). I think this : bug requires that we touch *unpinned* device-dax regions unaligned to : the device-dax selected alignment (page size i.e. 4K/2M/1G)", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50185", "url": "https://ubuntu.com/security/CVE-2024-50185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: handle consistently DSS corruption Bugged peer implementation can send corrupted DSS options, consistently hitting a few warning in the data path. Use DEBUG_NET assertions, to avoid the splat on some builds and handle consistently the error, dumping related MIBs and performing fallback and/or reset according to the subflow type.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50023", "url": "https://ubuntu.com/security/CVE-2024-50023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: Remove LED entry from LEDs list on unregister Commit c938ab4da0eb (\"net: phy: Manual remove LEDs to ensure correct ordering\") correctly fixed a problem with using devm_ but missed removing the LED entry from the LEDs list. This cause kernel panic on specific scenario where the port for the PHY is torn down and up and the kmod for the PHY is removed. On setting the port down the first time, the assosiacted LEDs are correctly unregistered. The associated kmod for the PHY is now removed. The kmod is now added again and the port is now put up, the associated LED are registered again. On putting the port down again for the second time after these step, the LED list now have 4 elements. With the first 2 already unregistered previously and the 2 new one registered again. This cause a kernel panic as the first 2 element should have been removed. Fix this by correctly removing the element when LED is unregistered.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50024", "url": "https://ubuntu.com/security/CVE-2024-50024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: Fix an unsafe loop on the list The kernel may crash when deleting a genetlink family if there are still listeners for that family: Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c000000000c080bc] netlink_update_socket_mc+0x3c/0xc0 LR [c000000000c0f764] __netlink_clear_multicast_users+0x74/0xc0 Call Trace: __netlink_clear_multicast_users+0x74/0xc0 genl_unregister_family+0xd4/0x2d0 Change the unsafe loop on the list to a safe one, because inside the loop there is an element removal from this list.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50186", "url": "https://ubuntu.com/security/CVE-2024-50186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: explicitly clear the sk pointer, when pf->create fails We have recently noticed the exact same KASAN splat as in commit 6cd4a78d962b (\"net: do not leave a dangling sk pointer, when socket creation fails\"). The problem is that commit did not fully address the problem, as some pf->create implementations do not use sk_common_release in their error paths. For example, we can use the same reproducer as in the above commit, but changing ping to arping. arping uses AF_PACKET socket and if packet_create fails, it will just sk_free the allocated sk object. While we could chase all the pf->create implementations and make sure they NULL the freed sk object on error from the socket, we can't guarantee future protocols will not make the same mistake. So it is easier to just explicitly NULL the sk pointer upon return from pf->create in __sock_create. We do know that pf->create always releases the allocated sk object on error, so if the pointer is not NULL, it is definitely dangling.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50025", "url": "https://ubuntu.com/security/CVE-2024-50025", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: fnic: Move flush_work initialization out of if block After commit 379a58caa199 (\"scsi: fnic: Move fnic_fnic_flush_tx() to a work queue\"), it can happen that a work item is sent to an uninitialized work queue. This may has the effect that the item being queued is never actually queued, and any further actions depending on it will not proceed. The following warning is observed while the fnic driver is loaded: kernel: WARNING: CPU: 11 PID: 0 at ../kernel/workqueue.c:1524 __queue_work+0x373/0x410 kernel: kernel: queue_work_on+0x3a/0x50 kernel: fnic_wq_copy_cmpl_handler+0x54a/0x730 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: fnic_isr_msix_wq_copy+0x2d/0x60 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: __handle_irq_event_percpu+0x36/0x1a0 kernel: handle_irq_event_percpu+0x30/0x70 kernel: handle_irq_event+0x34/0x60 kernel: handle_edge_irq+0x7e/0x1a0 kernel: __common_interrupt+0x3b/0xb0 kernel: common_interrupt+0x58/0xa0 kernel: It has been observed that this may break the rediscovery of Fibre Channel devices after a temporary fabric failure. This patch fixes it by moving the work queue initialization out of an if block in fnic_probe().", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50026", "url": "https://ubuntu.com/security/CVE-2024-50026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: wd33c93: Don't use stale scsi_pointer value A regression was introduced with commit dbb2da557a6a (\"scsi: wd33c93: Move the SCSI pointer to private command data\") which results in an oops in wd33c93_intr(). That commit added the scsi_pointer variable and initialized it from hostdata->connected. However, during selection, hostdata->connected is not yet valid. Fix this by getting the current scsi_pointer from hostdata->selecting.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50027", "url": "https://ubuntu.com/security/CVE-2024-50027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: core: Free tzp copy along with the thermal zone The object pointed to by tz->tzp may still be accessed after being freed in thermal_zone_device_unregister(), so move the freeing of it to the point after the removal completion has been completed at which it cannot be accessed any more.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50028", "url": "https://ubuntu.com/security/CVE-2024-50028", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: core: Reference count the zone in thermal_zone_get_by_id() There are places in the thermal netlink code where nothing prevents the thermal zone object from going away while being accessed after it has been returned by thermal_zone_get_by_id(). To address this, make thermal_zone_get_by_id() get a reference on the thermal zone device object to be returned with the help of get_device(), under thermal_list_lock, and adjust all of its callers to this change with the help of the cleanup.h infrastructure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50029", "url": "https://ubuntu.com/security/CVE-2024-50029", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_conn: Fix UAF in hci_enhanced_setup_sync This checks if the ACL connection remains valid as it could be destroyed while hci_enhanced_setup_sync is pending on cmd_sync leading to the following trace: BUG: KASAN: slab-use-after-free in hci_enhanced_setup_sync+0x91b/0xa60 Read of size 1 at addr ffff888002328ffd by task kworker/u5:2/37 CPU: 0 UID: 0 PID: 37 Comm: kworker/u5:2 Not tainted 6.11.0-rc6-01300-g810be445d8d6 #7099 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Workqueue: hci0 hci_cmd_sync_work Call Trace: dump_stack_lvl+0x5d/0x80 ? hci_enhanced_setup_sync+0x91b/0xa60 print_report+0x152/0x4c0 ? hci_enhanced_setup_sync+0x91b/0xa60 ? __virt_addr_valid+0x1fa/0x420 ? hci_enhanced_setup_sync+0x91b/0xa60 kasan_report+0xda/0x1b0 ? hci_enhanced_setup_sync+0x91b/0xa60 hci_enhanced_setup_sync+0x91b/0xa60 ? __pfx_hci_enhanced_setup_sync+0x10/0x10 ? __pfx___mutex_lock+0x10/0x10 hci_cmd_sync_work+0x1c2/0x330 process_one_work+0x7d9/0x1360 ? __pfx_lock_acquire+0x10/0x10 ? __pfx_process_one_work+0x10/0x10 ? assign_work+0x167/0x240 worker_thread+0x5b7/0xf60 ? __kthread_parkme+0xac/0x1c0 ? __pfx_worker_thread+0x10/0x10 ? __pfx_worker_thread+0x10/0x10 kthread+0x293/0x360 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2f/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 34: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __hci_conn_add+0x187/0x17d0 hci_connect_sco+0x2e1/0xb90 sco_sock_connect+0x2a2/0xb80 __sys_connect+0x227/0x2a0 __x64_sys_connect+0x6d/0xb0 do_syscall_64+0x71/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 37: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x101/0x160 kfree+0xd0/0x250 device_release+0x9a/0x210 kobject_put+0x151/0x280 hci_conn_del+0x448/0xbf0 hci_abort_conn_sync+0x46f/0x980 hci_cmd_sync_work+0x1c2/0x330 process_one_work+0x7d9/0x1360 worker_thread+0x5b7/0xf60 kthread+0x293/0x360 ret_from_fork+0x2f/0x70 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50030", "url": "https://ubuntu.com/security/CVE-2024-50030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/ct: prevent UAF in send_recv() Ensure we serialize with completion side to prevent UAF with fence going out of scope on the stack, since we have no clue if it will fire after the timeout before we can erase from the xa. Also we have some dependent loads and stores for which we need the correct ordering, and we lack the needed barriers. Fix this by grabbing the ct->lock after the wait, which is also held by the completion side. v2 (Badal): - Also print done after acquiring the lock and seeing timeout. (cherry picked from commit 52789ce35c55ccd30c4b67b9cc5b2af55e0122ea)", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50187", "url": "https://ubuntu.com/security/CVE-2024-50187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Stop the active perfmon before being destroyed Upon closing the file descriptor, the active performance monitor is not stopped. Although all perfmons are destroyed in `vc4_perfmon_close_file()`, the active performance monitor's pointer (`vc4->active_perfmon`) is still retained. If we open a new file descriptor and submit a few jobs with performance monitors, the driver will attempt to stop the active performance monitor using the stale pointer in `vc4->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50031", "url": "https://ubuntu.com/security/CVE-2024-50031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Stop the active perfmon before being destroyed When running `kmscube` with one or more performance monitors enabled via `GALLIUM_HUD`, the following kernel panic can occur: [ 55.008324] Unable to handle kernel paging request at virtual address 00000000052004a4 [ 55.008368] Mem abort info: [ 55.008377] ESR = 0x0000000096000005 [ 55.008387] EC = 0x25: DABT (current EL), IL = 32 bits [ 55.008402] SET = 0, FnV = 0 [ 55.008412] EA = 0, S1PTW = 0 [ 55.008421] FSC = 0x05: level 1 translation fault [ 55.008434] Data abort info: [ 55.008442] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 55.008455] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 55.008467] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 55.008481] user pgtable: 4k pages, 39-bit VAs, pgdp=00000001046c6000 [ 55.008497] [00000000052004a4] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 55.008525] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP [ 55.008542] Modules linked in: rfcomm [...] vc4 v3d snd_soc_hdmi_codec drm_display_helper gpu_sched drm_shmem_helper cec drm_dma_helper drm_kms_helper i2c_brcmstb drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight [ 55.008799] CPU: 2 PID: 166 Comm: v3d_bin Tainted: G C 6.6.47+rpt-rpi-v8 #1 Debian 1:6.6.47-1+rpt1 [ 55.008824] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [ 55.008838] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 55.008855] pc : __mutex_lock.constprop.0+0x90/0x608 [ 55.008879] lr : __mutex_lock.constprop.0+0x58/0x608 [ 55.008895] sp : ffffffc080673cf0 [ 55.008904] x29: ffffffc080673cf0 x28: 0000000000000000 x27: ffffff8106188a28 [ 55.008926] x26: ffffff8101e78040 x25: ffffff8101baa6c0 x24: ffffffd9d989f148 [ 55.008947] x23: ffffffda1c2a4008 x22: 0000000000000002 x21: ffffffc080673d38 [ 55.008968] x20: ffffff8101238000 x19: ffffff8104f83188 x18: 0000000000000000 [ 55.008988] x17: 0000000000000000 x16: ffffffda1bd04d18 x15: 00000055bb08bc90 [ 55.009715] x14: 0000000000000000 x13: 0000000000000000 x12: ffffffda1bd4cbb0 [ 55.010433] x11: 00000000fa83b2da x10: 0000000000001a40 x9 : ffffffda1bd04d04 [ 55.011162] x8 : ffffff8102097b80 x7 : 0000000000000000 x6 : 00000000030a5857 [ 55.011880] x5 : 00ffffffffffffff x4 : 0300000005200470 x3 : 0300000005200470 [ 55.012598] x2 : ffffff8101238000 x1 : 0000000000000021 x0 : 0300000005200470 [ 55.013292] Call trace: [ 55.013959] __mutex_lock.constprop.0+0x90/0x608 [ 55.014646] __mutex_lock_slowpath+0x1c/0x30 [ 55.015317] mutex_lock+0x50/0x68 [ 55.015961] v3d_perfmon_stop+0x40/0xe0 [v3d] [ 55.016627] v3d_bin_job_run+0x10c/0x2d8 [v3d] [ 55.017282] drm_sched_main+0x178/0x3f8 [gpu_sched] [ 55.017921] kthread+0x11c/0x128 [ 55.018554] ret_from_fork+0x10/0x20 [ 55.019168] Code: f9400260 f1001c1f 54001ea9 927df000 (b9403401) [ 55.019776] ---[ end trace 0000000000000000 ]--- [ 55.020411] note: v3d_bin[166] exited with preempt_count 1 This issue arises because, upon closing the file descriptor (which happens when we interrupt `kmscube`), the active performance monitor is not stopped. Although all perfmons are destroyed in `v3d_perfmon_close_file()`, the active performance monitor's pointer (`v3d->active_perfmon`) is still retained. If `kmscube` is run again, the driver will attempt to stop the active performance monitor using the stale pointer in `v3d->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50189", "url": "https://ubuntu.com/security/CVE-2024-50189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: amd_sfh: Switch to device-managed dmam_alloc_coherent() Using the device-managed version allows to simplify clean-up in probe() error path. Additionally, this device-managed ensures proper cleanup, which helps to resolve memory errors, page faults, btrfs going read-only, and btrfs disk corruption.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50033", "url": "https://ubuntu.com/security/CVE-2024-50033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slip: make slhc_remember() more robust against malicious packets syzbot found that slhc_remember() was missing checks against malicious packets [1]. slhc_remember() only checked the size of the packet was at least 20, which is not good enough. We need to make sure the packet includes the IPv4 and TCP header that are supposed to be carried. Add iph and th pointers to make the code more readable. [1] BUG: KMSAN: uninit-value in slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 ppp_receive_nonmp_frame+0xe45/0x35e0 drivers/net/ppp/ppp_generic.c:2455 ppp_receive_frame drivers/net/ppp/ppp_generic.c:2372 [inline] ppp_do_recv+0x65f/0x40d0 drivers/net/ppp/ppp_generic.c:2212 ppp_input+0x7dc/0xe60 drivers/net/ppp/ppp_generic.c:2327 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 Uninit was created at: slab_post_alloc_hook mm/slub.c:4091 [inline] slab_alloc_node mm/slub.c:4134 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 CPU: 0 UID: 0 PID: 5460 Comm: syz.2.33 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50034", "url": "https://ubuntu.com/security/CVE-2024-50034", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix lacks of icsk_syn_mss with IPPROTO_SMC Eric report a panic on IPPROTO_SMC, and give the facts that when INET_PROTOSW_ICSK was set, icsk->icsk_sync_mss must be set too. Bug: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000086000005 EC = 0x21: IABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault user pgtable: 4k pages, 48-bit VAs, pgdp=00000001195d1000 [0000000000000000] pgd=0800000109c46003, p4d=0800000109c46003, pud=0000000000000000 Internal error: Oops: 0000000086000005 [#1] PREEMPT SMP Modules linked in: CPU: 1 UID: 0 PID: 8037 Comm: syz.3.265 Not tainted 6.11.0-rc7-syzkaller-g5f5673607153 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0x0 lr : cipso_v4_sock_setattr+0x2a8/0x3c0 net/ipv4/cipso_ipv4.c:1910 sp : ffff80009b887a90 x29: ffff80009b887aa0 x28: ffff80008db94050 x27: 0000000000000000 x26: 1fffe0001aa6f5b3 x25: dfff800000000000 x24: ffff0000db75da00 x23: 0000000000000000 x22: ffff0000d8b78518 x21: 0000000000000000 x20: ffff0000d537ad80 x19: ffff0000d8b78000 x18: 1fffe000366d79ee x17: ffff8000800614a8 x16: ffff800080569b84 x15: 0000000000000001 x14: 000000008b336894 x13: 00000000cd96feaa x12: 0000000000000003 x11: 0000000000040000 x10: 00000000000020a3 x9 : 1fffe0001b16f0f1 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 000000000000003f x5 : 0000000000000040 x4 : 0000000000000001 x3 : 0000000000000000 x2 : 0000000000000002 x1 : 0000000000000000 x0 : ffff0000d8b78000 Call trace: 0x0 netlbl_sock_setattr+0x2e4/0x338 net/netlabel/netlabel_kapi.c:1000 smack_netlbl_add+0xa4/0x154 security/smack/smack_lsm.c:2593 smack_socket_post_create+0xa8/0x14c security/smack/smack_lsm.c:2973 security_socket_post_create+0x94/0xd4 security/security.c:4425 __sock_create+0x4c8/0x884 net/socket.c:1587 sock_create net/socket.c:1622 [inline] __sys_socket_create net/socket.c:1659 [inline] __sys_socket+0x134/0x340 net/socket.c:1706 __do_sys_socket net/socket.c:1720 [inline] __se_sys_socket net/socket.c:1718 [inline] __arm64_sys_socket+0x7c/0x94 net/socket.c:1718 __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:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 Code: ???????? ???????? ???????? ???????? (????????) ---[ end trace 0000000000000000 ]--- This patch add a toy implementation that performs a simple return to prevent such panic. This is because MSS can be set in sock_create_kern or smc_setsockopt, similar to how it's done in AF_SMC. However, for AF_SMC, there is currently no way to synchronize MSS within __sys_connect_file. This toy implementation lays the groundwork for us to support such feature for IPPROTO_SMC in the future.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50035", "url": "https://ubuntu.com/security/CVE-2024-50035", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: fix ppp_async_encode() illegal access syzbot reported an issue in ppp_async_encode() [1] In this case, pppoe_sendmsg() is called with a zero size. Then ppp_async_encode() is called with an empty skb. BUG: KMSAN: uninit-value in ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] BUG: KMSAN: uninit-value in ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_send+0x130/0x1b0 drivers/net/ppp/ppp_async.c:634 ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2280 [inline] ppp_input+0x1f1/0xe60 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 Uninit was created at: slab_post_alloc_hook mm/slub.c:4092 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4187 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 CPU: 1 UID: 0 PID: 5411 Comm: syz.1.14 Not tainted 6.12.0-rc1-syzkaller-00165-g360c1f1f24c6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50036", "url": "https://ubuntu.com/security/CVE-2024-50036", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: do not delay dst_entries_add() in dst_release() dst_entries_add() uses per-cpu data that might be freed at netns dismantle from ip6_route_net_exit() calling dst_entries_destroy() Before ip6_route_net_exit() can be called, we release all the dsts associated with this netns, via calls to dst_release(), which waits an rcu grace period before calling dst_destroy() dst_entries_add() use in dst_destroy() is racy, because dst_entries_destroy() could have been called already. Decrementing the number of dsts must happen sooner. Notes: 1) in CONFIG_XFRM case, dst_destroy() can call dst_release_immediate(child), this might also cause UAF if the child does not have DST_NOCOUNT set. IPSEC maintainers might take a look and see how to address this. 2) There is also discussion about removing this count of dst, which might happen in future kernels.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50037", "url": "https://ubuntu.com/security/CVE-2024-50037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/fbdev-dma: Only cleanup deferred I/O if necessary Commit 5a498d4d06d6 (\"drm/fbdev-dma: Only install deferred I/O if necessary\") initializes deferred I/O only if it is used. drm_fbdev_dma_fb_destroy() however calls fb_deferred_io_cleanup() unconditionally with struct fb_info.fbdefio == NULL. KASAN with the out-of-tree Apple silicon display driver posts following warning from __flush_work() of a random struct work_struct instead of the expected NULL pointer derefs. [ 22.053799] ------------[ cut here ]------------ [ 22.054832] WARNING: CPU: 2 PID: 1 at kernel/workqueue.c:4177 __flush_work+0x4d8/0x580 [ 22.056597] Modules linked in: uhid bnep uinput nls_ascii ip6_tables ip_tables i2c_dev loop fuse dm_multipath nfnetlink zram hid_magicmouse btrfs xor xor_neon brcmfmac_wcc raid6_pq hci_bcm4377 bluetooth brcmfmac hid_apple brcmutil nvmem_spmi_mfd simple_mfd_spmi dockchannel_hid cfg80211 joydev regmap_spmi nvme_apple ecdh_generic ecc macsmc_hid rfkill dwc3 appledrm snd_soc_macaudio macsmc_power nvme_core apple_isp phy_apple_atc apple_sart apple_rtkit_helper apple_dockchannel tps6598x macsmc_hwmon snd_soc_cs42l84 videobuf2_v4l2 spmi_apple_controller nvmem_apple_efuses videobuf2_dma_sg apple_z2 videobuf2_memops spi_nor panel_summit videobuf2_common asahi videodev pwm_apple apple_dcp snd_soc_apple_mca apple_admac spi_apple clk_apple_nco i2c_pasemi_platform snd_pcm_dmaengine mc i2c_pasemi_core mux_core ofpart adpdrm drm_dma_helper apple_dart apple_soc_cpufreq leds_pwm phram [ 22.073768] CPU: 2 UID: 0 PID: 1 Comm: systemd-shutdow Not tainted 6.11.2-asahi+ #asahi-dev [ 22.075612] Hardware name: Apple MacBook Pro (13-inch, M2, 2022) (DT) [ 22.077032] pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 22.078567] pc : __flush_work+0x4d8/0x580 [ 22.079471] lr : __flush_work+0x54/0x580 [ 22.080345] sp : ffffc000836ef820 [ 22.081089] x29: ffffc000836ef880 x28: 0000000000000000 x27: ffff80002ddb7128 [ 22.082678] x26: dfffc00000000000 x25: 1ffff000096f0c57 x24: ffffc00082d3e358 [ 22.084263] x23: ffff80004b7862b8 x22: dfffc00000000000 x21: ffff80005aa1d470 [ 22.085855] x20: ffff80004b786000 x19: ffff80004b7862a0 x18: 0000000000000000 [ 22.087439] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000005 [ 22.089030] x14: 1ffff800106ddf0a x13: 0000000000000000 x12: 0000000000000000 [ 22.090618] x11: ffffb800106ddf0f x10: dfffc00000000000 x9 : 1ffff800106ddf0e [ 22.092206] x8 : 0000000000000000 x7 : aaaaaaaaaaaaaaaa x6 : 0000000000000001 [ 22.093790] x5 : ffffc000836ef728 x4 : 0000000000000000 x3 : 0000000000000020 [ 22.095368] x2 : 0000000000000008 x1 : 00000000000000aa x0 : 0000000000000000 [ 22.096955] Call trace: [ 22.097505] __flush_work+0x4d8/0x580 [ 22.098330] flush_delayed_work+0x80/0xb8 [ 22.099231] fb_deferred_io_cleanup+0x3c/0x130 [ 22.100217] drm_fbdev_dma_fb_destroy+0x6c/0xe0 [drm_dma_helper] [ 22.101559] unregister_framebuffer+0x210/0x2f0 [ 22.102575] drm_fb_helper_unregister_info+0x48/0x60 [ 22.103683] drm_fbdev_dma_client_unregister+0x4c/0x80 [drm_dma_helper] [ 22.105147] drm_client_dev_unregister+0x1cc/0x230 [ 22.106217] drm_dev_unregister+0x58/0x570 [ 22.107125] apple_drm_unbind+0x50/0x98 [appledrm] [ 22.108199] component_del+0x1f8/0x3a8 [ 22.109042] dcp_platform_shutdown+0x24/0x38 [apple_dcp] [ 22.110357] platform_shutdown+0x70/0x90 [ 22.111219] device_shutdown+0x368/0x4d8 [ 22.112095] kernel_restart+0x6c/0x1d0 [ 22.112946] __arm64_sys_reboot+0x1c8/0x328 [ 22.113868] invoke_syscall+0x78/0x1a8 [ 22.114703] do_el0_svc+0x124/0x1a0 [ 22.115498] el0_svc+0x3c/0xe0 [ 22.116181] el0t_64_sync_handler+0x70/0xc0 [ 22.117110] el0t_64_sync+0x190/0x198 [ 22.117931] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50092", "url": "https://ubuntu.com/security/CVE-2024-50092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netconsole: fix wrong warning A warning is triggered when there is insufficient space in the buffer for userdata. However, this is not an issue since userdata will be sent in the next iteration. Current warning message: ------------[ cut here ]------------ WARNING: CPU: 13 PID: 3013042 at drivers/net/netconsole.c:1122 write_ext_msg+0x3b6/0x3d0 ? write_ext_msg+0x3b6/0x3d0 console_flush_all+0x1e9/0x330 The code incorrectly issues a warning when this_chunk is zero, which is a valid scenario. The warning should only be triggered when this_chunk is negative.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50038", "url": "https://ubuntu.com/security/CVE-2024-50038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xtables: avoid NFPROTO_UNSPEC where needed syzbot managed to call xt_cluster match via ebtables: WARNING: CPU: 0 PID: 11 at net/netfilter/xt_cluster.c:72 xt_cluster_mt+0x196/0x780 [..] ebt_do_table+0x174b/0x2a40 Module registers to NFPROTO_UNSPEC, but it assumes ipv4/ipv6 packet processing. As this is only useful to restrict locally terminating TCP/UDP traffic, register this for ipv4 and ipv6 family only. Pablo points out that this is a general issue, direct users of the set/getsockopt interface can call into targets/matches that were only intended for use with ip(6)tables. Check all UNSPEC matches and targets for similar issues: - matches and targets are fine except if they assume skb_network_header() is valid -- this is only true when called from inet layer: ip(6) stack pulls the ip/ipv6 header into linear data area. - targets that return XT_CONTINUE or other xtables verdicts must be restricted too, they are incompatbile with the ebtables traverser, e.g. EBT_CONTINUE is a completely different value than XT_CONTINUE. Most matches/targets are changed to register for NFPROTO_IPV4/IPV6, as they are provided for use by ip(6)tables. The MARK target is also used by arptables, so register for NFPROTO_ARP too. While at it, bail out if connbytes fails to enable the corresponding conntrack family. This change passes the selftests in iptables.git.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50039", "url": "https://ubuntu.com/security/CVE-2024-50039", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: accept TCA_STAB only for root qdisc Most qdiscs maintain their backlog using qdisc_pkt_len(skb) on the assumption it is invariant between the enqueue() and dequeue() handlers. Unfortunately syzbot can crash a host rather easily using a TBF + SFQ combination, with an STAB on SFQ [1] We can't support TCA_STAB on arbitrary level, this would require to maintain per-qdisc storage. [1] [ 88.796496] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 88.798611] #PF: supervisor read access in kernel mode [ 88.799014] #PF: error_code(0x0000) - not-present page [ 88.799506] PGD 0 P4D 0 [ 88.799829] Oops: Oops: 0000 [#1] SMP NOPTI [ 88.800569] CPU: 14 UID: 0 PID: 2053 Comm: b371744477 Not tainted 6.12.0-rc1-virtme #1117 [ 88.801107] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 88.801779] RIP: 0010:sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq [ 88.802544] Code: 0f b7 50 12 48 8d 04 d5 00 00 00 00 48 89 d6 48 29 d0 48 8b 91 c0 01 00 00 48 c1 e0 03 48 01 c2 66 83 7a 1a 00 7e c0 48 8b 3a <4c> 8b 07 4c 89 02 49 89 50 08 48 c7 47 08 00 00 00 00 48 c7 07 00 All code ======== 0:\t0f b7 50 12 \tmovzwl 0x12(%rax),%edx 4:\t48 8d 04 d5 00 00 00 \tlea 0x0(,%rdx,8),%rax b:\t00 c:\t48 89 d6 \tmov %rdx,%rsi f:\t48 29 d0 \tsub %rdx,%rax 12:\t48 8b 91 c0 01 00 00 \tmov 0x1c0(%rcx),%rdx 19:\t48 c1 e0 03 \tshl $0x3,%rax 1d:\t48 01 c2 \tadd %rax,%rdx 20:\t66 83 7a 1a 00 \tcmpw $0x0,0x1a(%rdx) 25:\t7e c0 \tjle 0xffffffffffffffe7 27:\t48 8b 3a \tmov (%rdx),%rdi 2a:*\t4c 8b 07 \tmov (%rdi),%r8\t\t<-- trapping instruction 2d:\t4c 89 02 \tmov %r8,(%rdx) 30:\t49 89 50 08 \tmov %rdx,0x8(%r8) 34:\t48 c7 47 08 00 00 00 \tmovq $0x0,0x8(%rdi) 3b:\t00 3c:\t48 \trex.W 3d:\tc7 \t.byte 0xc7 3e:\t07 \t(bad) \t... Code starting with the faulting instruction =========================================== 0:\t4c 8b 07 \tmov (%rdi),%r8 3:\t4c 89 02 \tmov %r8,(%rdx) 6:\t49 89 50 08 \tmov %rdx,0x8(%r8) a:\t48 c7 47 08 00 00 00 \tmovq $0x0,0x8(%rdi) 11:\t00 12:\t48 \trex.W 13:\tc7 \t.byte 0xc7 14:\t07 \t(bad) \t... [ 88.803721] RSP: 0018:ffff9a1f892b7d58 EFLAGS: 00000206 [ 88.804032] RAX: 0000000000000000 RBX: ffff9a1f8420c800 RCX: ffff9a1f8420c800 [ 88.804560] RDX: ffff9a1f81bc1440 RSI: 0000000000000000 RDI: 0000000000000000 [ 88.805056] RBP: ffffffffc04bb0e0 R08: 0000000000000001 R09: 00000000ff7f9a1f [ 88.805473] R10: 000000000001001b R11: 0000000000009a1f R12: 0000000000000140 [ 88.806194] R13: 0000000000000001 R14: ffff9a1f886df400 R15: ffff9a1f886df4ac [ 88.806734] FS: 00007f445601a740(0000) GS:ffff9a2e7fd80000(0000) knlGS:0000000000000000 [ 88.807225] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 88.807672] CR2: 0000000000000000 CR3: 000000050cc46000 CR4: 00000000000006f0 [ 88.808165] Call Trace: [ 88.808459] [ 88.808710] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434) [ 88.809261] ? page_fault_oops (arch/x86/mm/fault.c:715) [ 88.809561] ? exc_page_fault (./arch/x86/include/asm/irqflags.h:26 ./arch/x86/include/asm/irqflags.h:87 ./arch/x86/include/asm/irqflags.h:147 arch/x86/mm/fault.c:1489 arch/x86/mm/fault.c:1539) [ 88.809806] ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623) [ 88.810074] ? sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq [ 88.810411] sfq_reset (net/sched/sch_sfq.c:525) sch_sfq [ 88.810671] qdisc_reset (./include/linux/skbuff.h:2135 ./include/linux/skbuff.h:2441 ./include/linux/skbuff.h:3304 ./include/linux/skbuff.h:3310 net/sched/sch_g ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50040", "url": "https://ubuntu.com/security/CVE-2024-50040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: igb: Do not bring the device up after non-fatal error Commit 004d25060c78 (\"igb: Fix igb_down hung on surprise removal\") changed igb_io_error_detected() to ignore non-fatal pcie errors in order to avoid hung task that can happen when igb_down() is called multiple times. This caused an issue when processing transient non-fatal errors. igb_io_resume(), which is called after igb_io_error_detected(), assumes that device is brought down by igb_io_error_detected() if the interface is up. This resulted in panic with stacktrace below. [ T3256] igb 0000:09:00.0 haeth0: igb: haeth0 NIC Link is Down [ T292] pcieport 0000:00:1c.5: AER: Uncorrected (Non-Fatal) error received: 0000:09:00.0 [ T292] igb 0000:09:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, (Requester ID) [ T292] igb 0000:09:00.0: device [8086:1537] error status/mask=00004000/00000000 [ T292] igb 0000:09:00.0: [14] CmpltTO [ 200.105524,009][ T292] igb 0000:09:00.0: AER: TLP Header: 00000000 00000000 00000000 00000000 [ T292] pcieport 0000:00:1c.5: AER: broadcast error_detected message [ T292] igb 0000:09:00.0: Non-correctable non-fatal error reported. [ T292] pcieport 0000:00:1c.5: AER: broadcast mmio_enabled message [ T292] pcieport 0000:00:1c.5: AER: broadcast resume message [ T292] ------------[ cut here ]------------ [ T292] kernel BUG at net/core/dev.c:6539! [ T292] invalid opcode: 0000 [#1] PREEMPT SMP [ T292] RIP: 0010:napi_enable+0x37/0x40 [ T292] Call Trace: [ T292] [ T292] ? die+0x33/0x90 [ T292] ? do_trap+0xdc/0x110 [ T292] ? napi_enable+0x37/0x40 [ T292] ? do_error_trap+0x70/0xb0 [ T292] ? napi_enable+0x37/0x40 [ T292] ? napi_enable+0x37/0x40 [ T292] ? exc_invalid_op+0x4e/0x70 [ T292] ? napi_enable+0x37/0x40 [ T292] ? asm_exc_invalid_op+0x16/0x20 [ T292] ? napi_enable+0x37/0x40 [ T292] igb_up+0x41/0x150 [ T292] igb_io_resume+0x25/0x70 [ T292] report_resume+0x54/0x70 [ T292] ? report_frozen_detected+0x20/0x20 [ T292] pci_walk_bus+0x6c/0x90 [ T292] ? aer_print_port_info+0xa0/0xa0 [ T292] pcie_do_recovery+0x22f/0x380 [ T292] aer_process_err_devices+0x110/0x160 [ T292] aer_isr+0x1c1/0x1e0 [ T292] ? disable_irq_nosync+0x10/0x10 [ T292] irq_thread_fn+0x1a/0x60 [ T292] irq_thread+0xe3/0x1a0 [ T292] ? irq_set_affinity_notifier+0x120/0x120 [ T292] ? irq_affinity_notify+0x100/0x100 [ T292] kthread+0xe2/0x110 [ T292] ? kthread_complete_and_exit+0x20/0x20 [ T292] ret_from_fork+0x2d/0x50 [ T292] ? kthread_complete_and_exit+0x20/0x20 [ T292] ret_from_fork_asm+0x11/0x20 [ T292] To fix this issue igb_io_resume() checks if the interface is running and the device is not down this means igb_io_error_detected() did not bring the device down and there is no need to bring it up.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50041", "url": "https://ubuntu.com/security/CVE-2024-50041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: Fix macvlan leak by synchronizing access to mac_filter_hash This patch addresses a macvlan leak issue in the i40e driver caused by concurrent access to vsi->mac_filter_hash. The leak occurs when multiple threads attempt to modify the mac_filter_hash simultaneously, leading to inconsistent state and potential memory leaks. To fix this, we now wrap the calls to i40e_del_mac_filter() and zeroing vf->default_lan_addr.addr with spin_lock/unlock_bh(&vsi->mac_filter_hash_lock), ensuring atomic operations and preventing concurrent access. Additionally, we add lockdep_assert_held(&vsi->mac_filter_hash_lock) in i40e_add_mac_filter() to help catch similar issues in the future. Reproduction steps: 1. Spawn VFs and configure port vlan on them. 2. Trigger concurrent macvlan operations (e.g., adding and deleting \tportvlan and/or mac filters). 3. Observe the potential memory leak and inconsistent state in the \tmac_filter_hash. This synchronization ensures the integrity of the mac_filter_hash and prevents the described leak.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50042", "url": "https://ubuntu.com/security/CVE-2024-50042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix increasing MSI-X on VF Increasing MSI-X value on a VF leads to invalid memory operations. This is caused by not reallocating some arrays. Reproducer: modprobe ice echo 0 > /sys/bus/pci/devices/$PF_PCI/sriov_drivers_autoprobe echo 1 > /sys/bus/pci/devices/$PF_PCI/sriov_numvfs echo 17 > /sys/bus/pci/devices/$VF0_PCI/sriov_vf_msix_count Default MSI-X is 16, so 17 and above triggers this issue. KASAN reports: BUG: KASAN: slab-out-of-bounds in ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] Read of size 8 at addr ffff8888b937d180 by task bash/28433 (...) Call Trace: (...) ? ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] kasan_report+0xed/0x120 ? ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] ice_vsi_cfg_def+0x3360/0x4770 [ice] ? mutex_unlock+0x83/0xd0 ? __pfx_ice_vsi_cfg_def+0x10/0x10 [ice] ? __pfx_ice_remove_vsi_lkup_fltr+0x10/0x10 [ice] ice_vsi_cfg+0x7f/0x3b0 [ice] ice_vf_reconfig_vsi+0x114/0x210 [ice] ice_sriov_set_msix_vec_count+0x3d0/0x960 [ice] sriov_vf_msix_count_store+0x21c/0x300 (...) Allocated by task 28201: (...) ice_vsi_cfg_def+0x1c8e/0x4770 [ice] ice_vsi_cfg+0x7f/0x3b0 [ice] ice_vsi_setup+0x179/0xa30 [ice] ice_sriov_configure+0xcaa/0x1520 [ice] sriov_numvfs_store+0x212/0x390 (...) To fix it, use ice_vsi_rebuild() instead of ice_vf_reconfig_vsi(). This causes the required arrays to be reallocated taking the new queue count into account (ice_vsi_realloc_stat_arrays()). Set req_txq and req_rxq before ice_vsi_rebuild(), so that realloc uses the newly set queue count. Additionally, ice_vsi_rebuild() does not remove VSI filters (ice_fltr_remove_all()), so ice_vf_init_host_cfg() is no longer necessary.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50093", "url": "https://ubuntu.com/security/CVE-2024-50093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: intel: int340x: processor: Fix warning during module unload The processor_thermal driver uses pcim_device_enable() to enable a PCI device, which means the device will be automatically disabled on driver detach. Thus there is no need to call pci_disable_device() again on it. With recent PCI device resource management improvements, e.g. commit f748a07a0b64 (\"PCI: Remove legacy pcim_release()\"), this problem is exposed and triggers the warining below. [ 224.010735] proc_thermal_pci 0000:00:04.0: disabling already-disabled device [ 224.010747] WARNING: CPU: 8 PID: 4442 at drivers/pci/pci.c:2250 pci_disable_device+0xe5/0x100 ... [ 224.010844] Call Trace: [ 224.010845] [ 224.010847] ? show_regs+0x6d/0x80 [ 224.010851] ? __warn+0x8c/0x140 [ 224.010854] ? pci_disable_device+0xe5/0x100 [ 224.010856] ? report_bug+0x1c9/0x1e0 [ 224.010859] ? handle_bug+0x46/0x80 [ 224.010862] ? exc_invalid_op+0x1d/0x80 [ 224.010863] ? asm_exc_invalid_op+0x1f/0x30 [ 224.010867] ? pci_disable_device+0xe5/0x100 [ 224.010869] ? pci_disable_device+0xe5/0x100 [ 224.010871] ? kfree+0x21a/0x2b0 [ 224.010873] pcim_disable_device+0x20/0x30 [ 224.010875] devm_action_release+0x16/0x20 [ 224.010878] release_nodes+0x47/0xc0 [ 224.010880] devres_release_all+0x9f/0xe0 [ 224.010883] device_unbind_cleanup+0x12/0x80 [ 224.010885] device_release_driver_internal+0x1ca/0x210 [ 224.010887] driver_detach+0x4e/0xa0 [ 224.010889] bus_remove_driver+0x6f/0xf0 [ 224.010890] driver_unregister+0x35/0x60 [ 224.010892] pci_unregister_driver+0x44/0x90 [ 224.010894] proc_thermal_pci_driver_exit+0x14/0x5f0 [processor_thermal_device_pci] ... [ 224.010921] ---[ end trace 0000000000000000 ]--- Remove the excess pci_disable_device() calls. [ rjw: Subject and changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50043", "url": "https://ubuntu.com/security/CVE-2024-50043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix possible badness in FREE_STATEID When multiple FREE_STATEIDs are sent for the same delegation stateid, it can lead to a possible either use-after-free or counter refcount underflow errors. In nfsd4_free_stateid() under the client lock we find a delegation stateid, however the code drops the lock before calling nfs4_put_stid(), that allows another FREE_STATE to find the stateid again. The first one will proceed to then free the stateid which leads to either use-after-free or decrementing already zeroed counter.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50044", "url": "https://ubuntu.com/security/CVE-2024-50044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change rfcomm_sk_state_change attempts to use sock_lock so it must never be called with it locked but rfcomm_sock_ioctl always attempt to lock it causing the following trace: ====================================================== WARNING: possible circular locking dependency detected 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Not tainted ------------------------------------------------------ syz-executor386/5093 is trying to acquire lock: ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1671 [inline] ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73 but task is already holding lock: ffff88807badfd28 (&d->lock){+.+.}-{3:3}, at: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50045", "url": "https://ubuntu.com/security/CVE-2024-50045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: br_netfilter: fix panic with metadata_dst skb Fix a kernel panic in the br_netfilter module when sending untagged traffic via a VxLAN device. This happens during the check for fragmentation in br_nf_dev_queue_xmit. It is dependent on: 1) the br_netfilter module being loaded; 2) net.bridge.bridge-nf-call-iptables set to 1; 3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port; 4) untagged frames with size higher than the VxLAN MTU forwarded/flooded When forwarding the untagged packet to the VxLAN bridge port, before the netfilter hooks are called, br_handle_egress_vlan_tunnel is called and changes the skb_dst to the tunnel dst. The tunnel_dst is a metadata type of dst, i.e., skb_valid_dst(skb) is false, and metadata->dst.dev is NULL. Then in the br_netfilter hooks, in br_nf_dev_queue_xmit, there's a check for frames that needs to be fragmented: frames with higher MTU than the VxLAN device end up calling br_nf_ip_fragment, which in turns call ip_skb_dst_mtu. The ip_dst_mtu tries to use the skb_dst(skb) as if it was a valid dst with valid dst->dev, thus the crash. This case was never supported in the first place, so drop the packet instead. PING 10.0.0.2 (10.0.0.2) from 0.0.0.0 h1-eth0: 2000(2028) bytes of data. [ 176.291791] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000110 [ 176.292101] Mem abort info: [ 176.292184] ESR = 0x0000000096000004 [ 176.292322] EC = 0x25: DABT (current EL), IL = 32 bits [ 176.292530] SET = 0, FnV = 0 [ 176.292709] EA = 0, S1PTW = 0 [ 176.292862] FSC = 0x04: level 0 translation fault [ 176.293013] Data abort info: [ 176.293104] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 176.293488] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 176.293787] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 176.293995] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043ef5000 [ 176.294166] [0000000000000110] pgd=0000000000000000, p4d=0000000000000000 [ 176.294827] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 176.295252] Modules linked in: vxlan ip6_udp_tunnel udp_tunnel veth br_netfilter bridge stp llc ipv6 crct10dif_ce [ 176.295923] CPU: 0 PID: 188 Comm: ping Not tainted 6.8.0-rc3-g5b3fbd61b9d1 #2 [ 176.296314] Hardware name: linux,dummy-virt (DT) [ 176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 176.296808] pc : br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.297382] lr : br_nf_dev_queue_xmit+0x2ac/0x4ec [br_netfilter] [ 176.297636] sp : ffff800080003630 [ 176.297743] x29: ffff800080003630 x28: 0000000000000008 x27: ffff6828c49ad9f8 [ 176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24: 00000000000003e8 [ 176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21: ffff6828c3b16d28 [ 176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18: 0000000000000014 [ 176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15: 0000000095744632 [ 176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12: ffffb7e137926a70 [ 176.299574] x11: 0000000000000001 x10: ffff6828c3f1c898 x9 : 0000000000000000 [ 176.300049] x8 : ffff6828c49bf070 x7 : 0008460f18d5f20e x6 : f20e0100bebafeca [ 176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 : 0000000000000000 [ 176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 : ffff6828c7f918f0 [ 176.300889] Call trace: [ 176.301123] br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.301411] br_nf_post_routing+0x2a8/0x3e4 [br_netfilter] [ 176.301703] nf_hook_slow+0x48/0x124 [ 176.302060] br_forward_finish+0xc8/0xe8 [bridge] [ 176.302371] br_nf_hook_thresh+0x124/0x134 [br_netfilter] [ 176.302605] br_nf_forward_finish+0x118/0x22c [br_netfilter] [ 176.302824] br_nf_forward_ip.part.0+0x264/0x290 [br_netfilter] [ 176.303136] br_nf_forward+0x2b8/0x4e0 [br_netfilter] [ 176.303359] nf_hook_slow+0x48/0x124 [ 176.303 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50094", "url": "https://ubuntu.com/security/CVE-2024-50094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sfc: Don't invoke xdp_do_flush() from netpoll. Yury reported a crash in the sfc driver originated from netpoll_send_udp(). The netconsole sends a message and then netpoll invokes the driver's NAPI function with a budget of zero. It is dedicated to allow driver to free TX resources, that it may have used while sending the packet. In the netpoll case the driver invokes xdp_do_flush() unconditionally, leading to crash because bpf_net_context was never assigned. Invoke xdp_do_flush() only if budget is not zero.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50188", "url": "https://ubuntu.com/security/CVE-2024-50188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: dp83869: fix memory corruption when enabling fiber When configuring the fiber port, the DP83869 PHY driver incorrectly calls linkmode_set_bit() with a bit mask (1 << 10) rather than a bit number (10). This corrupts some other memory location -- in case of arm64 the priv pointer in the same structure. Since the advertising flags are updated from supported at the end of the function the incorrect line isn't needed at all and can be removed.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50046", "url": "https://ubuntu.com/security/CVE-2024-50046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies() On the node of an NFS client, some files saved in the mountpoint of the NFS server were copied to another location of the same NFS server. Accidentally, the nfs42_complete_copies() got a NULL-pointer dereference crash with the following syslog: [232064.838881] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232064.839360] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232066.588183] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 [232066.588586] Mem abort info: [232066.588701] ESR = 0x0000000096000007 [232066.588862] EC = 0x25: DABT (current EL), IL = 32 bits [232066.589084] SET = 0, FnV = 0 [232066.589216] EA = 0, S1PTW = 0 [232066.589340] FSC = 0x07: level 3 translation fault [232066.589559] Data abort info: [232066.589683] ISV = 0, ISS = 0x00000007 [232066.589842] CM = 0, WnR = 0 [232066.589967] user pgtable: 64k pages, 48-bit VAs, pgdp=00002000956ff400 [232066.590231] [0000000000000058] pgd=08001100ae100003, p4d=08001100ae100003, pud=08001100ae100003, pmd=08001100b3c00003, pte=0000000000000000 [232066.590757] Internal error: Oops: 96000007 [#1] SMP [232066.590958] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm vhost_net vhost vhost_iotlb tap tun ipt_rpfilter xt_multiport ip_set_hash_ip ip_set_hash_net xfrm_interface xfrm6_tunnel tunnel4 tunnel6 esp4 ah4 wireguard libcurve25519_generic veth xt_addrtype xt_set nf_conntrack_netlink ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_bitmap_port ip_set_hash_ipport dummy ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs iptable_filter sch_ingress nfnetlink_cttimeout vport_gre ip_gre ip_tunnel gre vport_geneve geneve vport_vxlan vxlan ip6_udp_tunnel udp_tunnel openvswitch nf_conncount dm_round_robin dm_service_time dm_multipath xt_nat xt_MASQUERADE nft_chain_nat nf_nat xt_mark xt_conntrack xt_comment nft_compat nft_counter nf_tables nfnetlink ocfs2 ocfs2_nodemanager ocfs2_stackglue iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_ssif nbd overlay 8021q garp mrp bonding tls rfkill sunrpc ext4 mbcache jbd2 [232066.591052] vfat fat cas_cache cas_disk ses enclosure scsi_transport_sas sg acpi_ipmi ipmi_si ipmi_devintf ipmi_msghandler ip_tables vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio dm_mirror dm_region_hash dm_log dm_mod nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc fuse xfs libcrc32c ast drm_vram_helper qla2xxx drm_kms_helper syscopyarea crct10dif_ce sysfillrect ghash_ce sysimgblt sha2_ce fb_sys_fops cec sha256_arm64 sha1_ce drm_ttm_helper ttm nvme_fc igb sbsa_gwdt nvme_fabrics drm nvme_core i2c_algo_bit i40e scsi_transport_fc megaraid_sas aes_neon_bs [232066.596953] CPU: 6 PID: 4124696 Comm: 10.253.166.125- Kdump: loaded Not tainted 5.15.131-9.cl9_ocfs2.aarch64 #1 [232066.597356] Hardware name: Great Wall .\\x93\\x8e...RF6260 V5/GWMSSE2GL1T, BIOS T656FBE_V3.0.18 2024-01-06 [232066.597721] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [232066.598034] pc : nfs4_reclaim_open_state+0x220/0x800 [nfsv4] [232066.598327] lr : nfs4_reclaim_open_state+0x12c/0x800 [nfsv4] [232066.598595] sp : ffff8000f568fc70 [232066.598731] x29: ffff8000f568fc70 x28: 0000000000001000 x27: ffff21003db33000 [232066.599030] x26: ffff800005521ae0 x25: ffff0100f98fa3f0 x24: 0000000000000001 [232066.599319] x23: ffff800009920008 x22: ffff21003db33040 x21: ffff21003db33050 [232066.599628] x20: ffff410172fe9e40 x19: ffff410172fe9e00 x18: 0000000000000000 [232066.599914] x17: 0000000000000000 x16: 0000000000000004 x15: 0000000000000000 [232066.600195] x14: 0000000000000000 x13: ffff800008e685a8 x12: 00000000eac0c6e6 [232066.600498] x11: 00000000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50190", "url": "https://ubuntu.com/security/CVE-2024-50190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix memleak in ice_init_tx_topology() Fix leak of the FW blob (DDP pkg). Make ice_cfg_tx_topo() const-correct, so ice_init_tx_topology() can avoid copying whole FW blob. Copy just the topology section, and only when needed. Reuse the buffer allocated for the read of the current topology. This was found by kmemleak, with the following trace for each PF: [] kmemdup_noprof+0x1d/0x50 [] ice_init_ddp_config+0x100/0x220 [ice] [] ice_init_dev+0x6f/0x200 [ice] [] ice_init+0x29/0x560 [ice] [] ice_probe+0x21d/0x310 [ice] Constify ice_cfg_tx_topo() @buf parameter. This cascades further down to few more functions.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50180", "url": "https://ubuntu.com/security/CVE-2024-50180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: sisfb: Fix strbuf array overflow The values of the variables xres and yres are placed in strbuf. These variables are obtained from strbuf1. The strbuf1 array contains digit characters and a space if the array contains non-digit characters. Then, when executing sprintf(strbuf, \"%ux%ux8\", xres, yres); more than 16 bytes will be written to strbuf. It is suggested to increase the size of the strbuf array to 24. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06: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": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50048", "url": "https://ubuntu.com/security/CVE-2024-50048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: Fix a NULL pointer dereference issue in fbcon_putcs syzbot has found a NULL pointer dereference bug in fbcon. Here is the simplified C reproducer: struct param { \tuint8_t type; \tstruct tiocl_selection ts; }; int main() { \tstruct fb_con2fbmap con2fb; \tstruct param param; \tint fd = open(\"/dev/fb1\", 0, 0); \tcon2fb.console = 0x19; \tcon2fb.framebuffer = 0; \tioctl(fd, FBIOPUT_CON2FBMAP, &con2fb); \tparam.type = 2; \tparam.ts.xs = 0; param.ts.ys = 0; \tparam.ts.xe = 0; param.ts.ye = 0; \tparam.ts.sel_mode = 0; \tint fd1 = open(\"/dev/tty1\", O_RDWR, 0); \tioctl(fd1, TIOCLINUX, ¶m); \tcon2fb.console = 1; \tcon2fb.framebuffer = 0; \tioctl(fd, FBIOPUT_CON2FBMAP, &con2fb); \treturn 0; } After calling ioctl(fd1, TIOCLINUX, ¶m), the subsequent ioctl(fd, FBIOPUT_CON2FBMAP, &con2fb) causes the kernel to follow a different execution path: set_con2fb_map -> con2fb_init_display -> fbcon_set_disp -> redraw_screen -> hide_cursor -> clear_selection -> highlight -> invert_screen -> do_update_region -> fbcon_putcs -> ops->putcs Since ops->putcs is a NULL pointer, this leads to a kernel panic. To prevent this, we need to call set_blitting_type() within set_con2fb_map() to properly initialize ops->putcs.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50049", "url": "https://ubuntu.com/security/CVE-2024-50049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before dereferencing se [WHAT & HOW] se is null checked previously in the same function, indicating it might be null; therefore, it must be checked when used again. This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50090", "url": "https://ubuntu.com/security/CVE-2024-50090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/oa: Fix overflow in oa batch buffer By default xe_bb_create_job() appends a MI_BATCH_BUFFER_END to batch buffer, this is not a problem if batch buffer is only used once but oa reuses the batch buffer for the same metric and at each call it appends a MI_BATCH_BUFFER_END, printing the warning below and then overflowing. [ 381.072016] ------------[ cut here ]------------ [ 381.072019] xe 0000:00:02.0: [drm] Assertion `bb->len * 4 + bb_prefetch(q->gt) <= size` failed! platform: LUNARLAKE subplatform: 1 graphics: Xe2_LPG / Xe2_HPG 20.04 step B0 media: Xe2_LPM / Xe2_HPM 20.00 step B0 tile: 0 VRAM 0 B GT: 0 type 1 So here checking if batch buffer already have MI_BATCH_BUFFER_END if not append it. v2: - simply fix, suggestion from Ashutosh (cherry picked from commit 9ba0e0f30ca42a98af3689460063edfb6315718a)", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50183", "url": "https://ubuntu.com/security/CVE-2024-50183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV instance Deleting an NPIV instance requires all fabric ndlps to be released before an NPIV's resources can be torn down. Failure to release fabric ndlps beforehand opens kref imbalance race conditions. Fix by forcing the DA_ID to complete synchronously with usage of wait_queue.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50055", "url": "https://ubuntu.com/security/CVE-2024-50055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: driver core: bus: Fix double free in driver API bus_register() For bus_register(), any error which happens after kset_register() will cause that @priv are freed twice, fixed by setting @priv with NULL after the first free.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50091", "url": "https://ubuntu.com/security/CVE-2024-50091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm vdo: don't refer to dedupe_context after releasing it Clear the dedupe_context pointer in a data_vio whenever ownership of the context is lost, so that vdo can't examine it accidentally.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50056", "url": "https://ubuntu.com/security/CVE-2024-50056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: Fix ERR_PTR dereference in uvc_v4l2.c Fix potential dereferencing of ERR_PTR() in find_format_by_pix() and uvc_v4l2_enum_format(). Fix the following smatch errors: drivers/usb/gadget/function/uvc_v4l2.c:124 find_format_by_pix() error: 'fmtdesc' dereferencing possible ERR_PTR() drivers/usb/gadget/function/uvc_v4l2.c:392 uvc_v4l2_enum_format() error: 'fmtdesc' dereferencing possible ERR_PTR() Also, fix similar issue in uvc_v4l2_try_format() for potential dereferencing of ERR_PTR().", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50184", "url": "https://ubuntu.com/security/CVE-2024-50184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_pmem: Check device status before requesting flush If a pmem device is in a bad status, the driver side could wait for host ack forever in virtio_pmem_flush(), causing the system to hang. So add a status check in the beginning of virtio_pmem_flush() to return early if the device is not activated.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50057", "url": "https://ubuntu.com/security/CVE-2024-50057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: tipd: Free IRQ only if it was requested before In polling mode, if no IRQ was requested there is no need to free it. Call devm_free_irq() only if client->irq is set. This fixes the warning caused by the tps6598x module removal: WARNING: CPU: 2 PID: 333 at kernel/irq/devres.c:144 devm_free_irq+0x80/0x8c ... ... Call trace: devm_free_irq+0x80/0x8c tps6598x_remove+0x28/0x88 [tps6598x] i2c_device_remove+0x2c/0x9c device_remove+0x4c/0x80 device_release_driver_internal+0x1cc/0x228 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 i2c_del_driver+0x54/0x64 tps6598x_i2c_driver_exit+0x18/0xc3c [tps6598x] __arm64_sys_delete_module+0x184/0x264 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc8/0xe8 do_el0_svc+0x20/0x2c el0_svc+0x28/0x98 el0t_64_sync_handler+0x13c/0x158 el0t_64_sync+0x190/0x194", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50058", "url": "https://ubuntu.com/security/CVE-2024-50058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: protect uart_port_dtr_rts() in uart_shutdown() too Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part 3) added few uport == NULL checks. It added one to uart_shutdown(), so the commit assumes, uport can be NULL in there. But right after that protection, there is an unprotected \"uart_port_dtr_rts(uport, false);\" call. That is invoked only if HUPCL is set, so I assume that is the reason why we do not see lots of these reports. Or it cannot be NULL at this point at all for some reason :P. Until the above is investigated, stay on the safe side and move this dereference to the if too. I got this inconsistency from Coverity under CID 1585130. Thanks.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50181", "url": "https://ubuntu.com/security/CVE-2024-50181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: imx: Remove CLK_SET_PARENT_GATE for DRAM mux for i.MX7D For i.MX7D DRAM related mux clock, the clock source change should ONLY be done done in low level asm code without accessing DRAM, and then calling clk API to sync the HW clock status with clk tree, it should never touch real clock source switch via clk API, so CLK_SET_PARENT_GATE flag should NOT be added, otherwise, DRAM's clock parent will be disabled when DRAM is active, and system will hang.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50059", "url": "https://ubuntu.com/security/CVE-2024-50059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntb: ntb_hw_switchtec: Fix use after free vulnerability in switchtec_ntb_remove due to race condition In the switchtec_ntb_add function, it can call switchtec_ntb_init_sndev function, then &sndev->check_link_status_work is bound with check_link_status_work. switchtec_ntb_link_notification may be called to start the work. If we remove the module which will call switchtec_ntb_remove to make cleanup, it will free sndev through kfree(sndev), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | check_link_status_work switchtec_ntb_remove | kfree(sndev); | | if (sndev->link_force_down) | // use sndev Fix it by ensuring that the work is canceled before proceeding with the cleanup in switchtec_ntb_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50060", "url": "https://ubuntu.com/security/CVE-2024-50060", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring: check if we need to reschedule during overflow flush In terms of normal application usage, this list will always be empty. And if an application does overflow a bit, it'll have a few entries. However, nothing obviously prevents syzbot from running a test case that generates a ton of overflow entries, and then flushing them can take quite a while. Check for needing to reschedule while flushing, and drop our locks and do so if necessary. There's no state to maintain here as overflows always prune from head-of-list, hence it's fine to drop and reacquire the locks at the end of the loop.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50061", "url": "https://ubuntu.com/security/CVE-2024-50061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: cdns: Fix use after free vulnerability in cdns_i3c_master Driver Due to Race Condition In the cdns_i3c_master_probe function, &master->hj_work is bound with cdns_i3c_master_hj. And cdns_i3c_master_interrupt can call cnds_i3c_master_demux_ibis function to start the work. If we remove the module which will call cdns_i3c_master_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | cdns_i3c_master_hj cdns_i3c_master_remove | i3c_master_unregister(&master->base) | device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in cdns_i3c_master_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50062", "url": "https://ubuntu.com/security/CVE-2024-50062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-srv: Avoid null pointer deref during path establishment For RTRS path establishment, RTRS client initiates and completes con_num of connections. After establishing all its connections, the information is exchanged between the client and server through the info_req message. During this exchange, it is essential that all connections have been established, and the state of the RTRS srv path is CONNECTED. So add these sanity checks, to make sure we detect and abort process in error scenarios to avoid null pointer deref.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50095", "url": "https://ubuntu.com/security/CVE-2024-50095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mad: Improve handling of timed out WRs of mad agent Current timeout handler of mad agent acquires/releases mad_agent_priv lock for every timed out WRs. This causes heavy locking contention when higher no. of WRs are to be handled inside timeout handler. This leads to softlockup with below trace in some use cases where rdma-cm path is used to establish connection between peer nodes Trace: ----- BUG: soft lockup - CPU#4 stuck for 26s! [kworker/u128:3:19767] CPU: 4 PID: 19767 Comm: kworker/u128:3 Kdump: loaded Tainted: G OE ------- --- 5.14.0-427.13.1.el9_4.x86_64 #1 Hardware name: Dell Inc. PowerEdge R740/01YM03, BIOS 2.4.8 11/26/2019 Workqueue: ib_mad1 timeout_sends [ib_core] RIP: 0010:__do_softirq+0x78/0x2ac RSP: 0018:ffffb253449e4f98 EFLAGS: 00000246 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 000000000000001f RDX: 000000000000001d RSI: 000000003d1879ab RDI: fff363b66fd3a86b RBP: ffffb253604cbcd8 R08: 0000009065635f3b R09: 0000000000000000 R10: 0000000000000040 R11: ffffb253449e4ff8 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000040 FS: 0000000000000000(0000) GS:ffff8caa1fc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd9ec9db900 CR3: 0000000891934006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? __irq_exit_rcu+0xa1/0xc0 ? watchdog_timer_fn+0x1b2/0x210 ? __pfx_watchdog_timer_fn+0x10/0x10 ? __hrtimer_run_queues+0x127/0x2c0 ? hrtimer_interrupt+0xfc/0x210 ? __sysvec_apic_timer_interrupt+0x5c/0x110 ? sysvec_apic_timer_interrupt+0x37/0x90 ? asm_sysvec_apic_timer_interrupt+0x16/0x20 ? __do_softirq+0x78/0x2ac ? __do_softirq+0x60/0x2ac __irq_exit_rcu+0xa1/0xc0 sysvec_call_function_single+0x72/0x90 asm_sysvec_call_function_single+0x16/0x20 RIP: 0010:_raw_spin_unlock_irq+0x14/0x30 RSP: 0018:ffffb253604cbd88 EFLAGS: 00000247 RAX: 000000000001960d RBX: 0000000000000002 RCX: ffff8cad2a064800 RDX: 000000008020001b RSI: 0000000000000001 RDI: ffff8cad5d39f66c RBP: ffff8cad5d39f600 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8caa443e0c00 R11: ffffb253604cbcd8 R12: ffff8cacb8682538 R13: 0000000000000005 R14: ffffb253604cbd90 R15: ffff8cad5d39f66c cm_process_send_error+0x122/0x1d0 [ib_cm] timeout_sends+0x1dd/0x270 [ib_core] process_one_work+0x1e2/0x3b0 ? __pfx_worker_thread+0x10/0x10 worker_thread+0x50/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xdd/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x50 Simplified timeout handler by creating local list of timed out WRs and invoke send handler post creating the list. The new method acquires/ releases lock once to fetch the list and hence helps to reduce locking contetiong when processing higher no. of WRs", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50063", "url": "https://ubuntu.com/security/CVE-2024-50063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Prevent tail call between progs attached to different hooks bpf progs can be attached to kernel functions, and the attached functions can take different parameters or return different return values. If prog attached to one kernel function tail calls prog attached to another kernel function, the ctx access or return value verification could be bypassed. For example, if prog1 is attached to func1 which takes only 1 parameter and prog2 is attached to func2 which takes two parameters. Since verifier assumes the bpf ctx passed to prog2 is constructed based on func2's prototype, verifier allows prog2 to access the second parameter from the bpf ctx passed to it. The problem is that verifier does not prevent prog1 from passing its bpf ctx to prog2 via tail call. In this case, the bpf ctx passed to prog2 is constructed from func1 instead of func2, that is, the assumption for ctx access verification is bypassed. Another example, if BPF LSM prog1 is attached to hook file_alloc_security, and BPF LSM prog2 is attached to hook bpf_lsm_audit_rule_known. Verifier knows the return value rules for these two hooks, e.g. it is legal for bpf_lsm_audit_rule_known to return positive number 1, and it is illegal for file_alloc_security to return positive number. So verifier allows prog2 to return positive number 1, but does not allow prog1 to return positive number. The problem is that verifier does not prevent prog1 from calling prog2 via tail call. In this case, prog2's return value 1 will be used as the return value for prog1's hook file_alloc_security. That is, the return value rule is bypassed. This patch adds restriction for tail call to prevent such bypasses.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50191", "url": "https://ubuntu.com/security/CVE-2024-50191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: don't set SB_RDONLY after filesystem errors When the filesystem is mounted with errors=remount-ro, we were setting SB_RDONLY flag to stop all filesystem modifications. We knew this misses proper locking (sb->s_umount) and does not go through proper filesystem remount procedure but it has been the way this worked since early ext2 days and it was good enough for catastrophic situation damage mitigation. Recently, syzbot has found a way (see link) to trigger warnings in filesystem freezing because the code got confused by SB_RDONLY changing under its hands. Since these days we set EXT4_FLAGS_SHUTDOWN on the superblock which is enough to stop all filesystem modifications, modifying SB_RDONLY shouldn't be needed. So stop doing that.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50064", "url": "https://ubuntu.com/security/CVE-2024-50064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: zram: free secondary algorithms names We need to kfree() secondary algorithms names when reset zram device that had multi-streams, otherwise we leak memory. [senozhatsky@chromium.org: kfree(NULL) is legal] Link: https://lkml.kernel.org/r/20240917013021.868769-1-senozhatsky@chromium.org", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50065", "url": "https://ubuntu.com/security/CVE-2024-50065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Change to non-blocking allocation in ntfs_d_hash d_hash is done while under \"rcu-walk\" and should not sleep. __get_name() allocates using GFP_KERNEL, having the possibility to sleep when under memory pressure. Change the allocation to GFP_NOWAIT.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50089", "url": "https://ubuntu.com/security/CVE-2024-50089", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-49863", "url": "https://ubuntu.com/security/CVE-2024-49863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost/scsi: null-ptr-dereference in vhost_scsi_get_req() Since commit 3f8ca2e115e5 (\"vhost/scsi: Extract common handling code from control queue handler\") a null pointer dereference bug can be triggered when guest sends an SCSI AN request. In vhost_scsi_ctl_handle_vq(), `vc.target` is assigned with `&v_req.tmf.lun[1]` within a switch-case block and is then passed to vhost_scsi_get_req() which extracts `vc->req` and `tpg`. However, for a `VIRTIO_SCSI_T_AN_*` request, tpg is not required, so `vc.target` is set to NULL in this branch. Later, in vhost_scsi_get_req(), `vc->target` is dereferenced without being checked, leading to a null pointer dereference bug. This bug can be triggered from guest. When this bug occurs, the vhost_worker process is killed while holding `vq->mutex` and the corresponding tpg will remain occupied indefinitely. Below is the KASAN report: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 PID: 840 Comm: poc Not tainted 6.10.0+ #1 Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:vhost_scsi_get_req+0x165/0x3a0 Code: 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 02 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 65 30 4c 89 e2 48 c1 ea 03 <0f> b6 04 02 4c 89 e2 83 e2 07 38 d0 7f 08 84 c0 0f 85 be 01 00 00 RSP: 0018:ffff888017affb50 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffff88801b000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888017affcb8 RBP: ffff888017affb80 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff888017affc88 R14: ffff888017affd1c R15: ffff888017993000 FS: 000055556e076500(0000) GS:ffff88806b100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200027c0 CR3: 0000000010ed0004 CR4: 0000000000370ef0 Call Trace: ? show_regs+0x86/0xa0 ? die_addr+0x4b/0xd0 ? exc_general_protection+0x163/0x260 ? asm_exc_general_protection+0x27/0x30 ? vhost_scsi_get_req+0x165/0x3a0 vhost_scsi_ctl_handle_vq+0x2a4/0xca0 ? __pfx_vhost_scsi_ctl_handle_vq+0x10/0x10 ? __switch_to+0x721/0xeb0 ? __schedule+0xda5/0x5710 ? __kasan_check_write+0x14/0x30 ? _raw_spin_lock+0x82/0xf0 vhost_scsi_ctl_handle_kick+0x52/0x90 vhost_run_work_list+0x134/0x1b0 vhost_task_fn+0x121/0x350 ... ---[ end trace 0000000000000000 ]--- Let's add a check in vhost_scsi_get_req. [whitespace fixes]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49864", "url": "https://ubuntu.com/security/CVE-2024-49864", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix a race between socket set up and I/O thread creation In rxrpc_open_socket(), it sets up the socket and then sets up the I/O thread that will handle it. This is a problem, however, as there's a gap between the two phases in which a packet may come into rxrpc_encap_rcv() from the UDP packet but we oops when trying to wake the not-yet created I/O thread. As a quick fix, just make rxrpc_encap_rcv() discard the packet if there's no I/O thread yet. A better, but more intrusive fix would perhaps be to rearrange things such that the socket creation is done by the I/O thread.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49865", "url": "https://ubuntu.com/security/CVE-2024-49865", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: move xa_alloc to prevent UAF Evil user can guess the next id of the vm before the ioctl completes and then call vm destroy ioctl to trigger UAF since create ioctl is still referencing the same vm. Move the xa_alloc all the way to the end to prevent this. v2: - Rebase (cherry picked from commit dcfd3971327f3ee92765154baebbaece833d3ca9)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49955", "url": "https://ubuntu.com/security/CVE-2024-49955", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: battery: Fix possible crash when unregistering a battery hook When a battery hook returns an error when adding a new battery, then the battery hook is automatically unregistered. However the battery hook provider cannot know that, so it will later call battery_hook_unregister() on the already unregistered battery hook, resulting in a crash. Fix this by using the list head to mark already unregistered battery hooks as already being unregistered so that they can be ignored by battery_hook_unregister().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49973", "url": "https://ubuntu.com/security/CVE-2024-49973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: r8169: add tally counter fields added with RTL8125 RTL8125 added fields to the tally counter, what may result in the chip dma'ing these new fields to unallocated memory. Therefore make sure that the allocated memory area is big enough to hold all of the tally counter values, even if we use only parts of it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49974", "url": "https://ubuntu.com/security/CVE-2024-49974", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Limit the number of concurrent async COPY operations Nothing appears to limit the number of concurrent async COPY operations that clients can start. In addition, AFAICT each async COPY can copy an unlimited number of 4MB chunks, so can run for a long time. Thus IMO async COPY can become a DoS vector. Add a restriction mechanism that bounds the number of concurrent background COPY operations. Start simple and try to be fair -- this patch implements a per-namespace limit. An async COPY request that occurs while this limit is exceeded gets NFS4ERR_DELAY. The requesting client can choose to send the request again after a delay or fall back to a traditional read/write style copy. If there is need to make the mechanism more sophisticated, we can visit that in future patches.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49975", "url": "https://ubuntu.com/security/CVE-2024-49975", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uprobes: fix kernel info leak via \"[uprobes]\" vma xol_add_vma() maps the uninitialized page allocated by __create_xol_area() into userspace. On some architectures (x86) this memory is readable even without VM_READ, VM_EXEC results in the same pgprot_t as VM_EXEC|VM_READ, although this doesn't really matter, debugger can read this memory anyway.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50003", "url": "https://ubuntu.com/security/CVE-2024-50003", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix system hang while resume with TBT monitor [Why] Connected with a Thunderbolt monitor and do the suspend and the system may hang while resume. The TBT monitor HPD will be triggered during the resume procedure and call the drm_client_modeset_probe() while struct drm_connector connector->dev->master is NULL. It will mess up the pipe topology after resume. [How] Skip the TBT monitor HPD during the resume procedure because we currently will probe the connectors after resume by default. (cherry picked from commit 453f86a26945207a16b8f66aaed5962dc2b95b85)", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50173", "url": "https://ubuntu.com/security/CVE-2024-50173", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix access to uninitialized variable in tick_ctx_cleanup() The group variable can't be used to retrieve ptdev in our second loop, because it points to the previously iterated list_head, not a valid group. Get the ptdev object from the scheduler instead.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49866", "url": "https://ubuntu.com/security/CVE-2024-49866", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Fix a race during cpuhp processing There is another found exception that the \"timerlat/1\" thread was scheduled on CPU0, and lead to timer corruption finally: ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ``` After tracing the scheduling event, it was discovered that the migration of the \"timerlat/1\" thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() | To fix this, skip online processing if the CPU is already offline.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49976", "url": "https://ubuntu.com/security/CVE-2024-49976", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Drop interface_lock in stop_kthread() stop_kthread() is the offline callback for \"trace/osnoise:online\", since commit 5bfbcd1ee57b (\"tracing/timerlat: Add interface_lock around clearing of kthread in stop_kthread()\"), the following ABBA deadlock scenario is introduced: T1 | T2 [BP] | T3 [AP] osnoise_hotplug_workfn() | work_for_cpu_fn() | cpuhp_thread_fun() | _cpu_down() | osnoise_cpu_die() mutex_lock(&interface_lock) | | stop_kthread() | cpus_write_lock() | mutex_lock(&interface_lock) cpus_read_lock() | cpuhp_kick_ap() | As the interface_lock here in just for protecting the \"kthread\" field of the osn_var, use xchg() instead to fix this issue. Also use for_each_online_cpu() back in stop_per_cpu_kthreads() as it can take cpu_read_lock() again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50005", "url": "https://ubuntu.com/security/CVE-2024-50005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: Fix potential RCU dereference issue in mac802154_scan_worker In the `mac802154_scan_worker` function, the `scan_req->type` field was accessed after the RCU read-side critical section was unlocked. According to RCU usage rules, this is illegal and can lead to unpredictable behavior, such as accessing memory that has been updated or causing use-after-free issues. This possible bug was identified using a static analysis tool developed by myself, specifically designed to detect RCU-related issues. To address this, the `scan_req->type` value is now stored in a local variable `scan_req_type` while still within the RCU read-side critical section. The `scan_req_type` is then used after the RCU lock is released, ensuring that the type value is safely accessed without violating RCU rules.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50012", "url": "https://ubuntu.com/security/CVE-2024-50012", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: Avoid a bad reference count on CPU node In the parse_perf_domain function, if the call to of_parse_phandle_with_args returns an error, then the reference to the CPU device node that was acquired at the start of the function would not be properly decremented. Address this by declaring the variable with the __free(device_node) cleanup attribute.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49867", "url": "https://ubuntu.com/security/CVE-2024-49867", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: wait for fixup workers before stopping cleaner kthread during umount During unmount, at close_ctree(), we have the following steps in this order: 1) Park the cleaner kthread - this doesn't destroy the kthread, it basically halts its execution (wake ups against it work but do nothing); 2) We stop the cleaner kthread - this results in freeing the respective struct task_struct; 3) We call btrfs_stop_all_workers() which waits for any jobs running in all the work queues and then free the work queues. Syzbot reported a case where a fixup worker resulted in a crash when doing a delayed iput on its inode while attempting to wake up the cleaner at btrfs_add_delayed_iput(), because the task_struct of the cleaner kthread was already freed. This can happen during unmount because we don't wait for any fixup workers still running before we call kthread_stop() against the cleaner kthread, which stops and free all its resources. Fix this by waiting for any fixup workers at close_ctree() before we call kthread_stop() against the cleaner and run pending delayed iputs. The stack traces reported by syzbot were the following: BUG: KASAN: slab-use-after-free in __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 Read of size 8 at addr ffff8880272a8a18 by task kworker/u8:3/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.12.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: btrfs-fixup btrfs_work_helper 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 __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline] try_to_wake_up+0xb0/0x1480 kernel/sched/core.c:4154 btrfs_writepage_fixup_worker+0xc16/0xdf0 fs/btrfs/inode.c:2842 btrfs_work_helper+0x390/0xc50 fs/btrfs/async-thread.c:314 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Allocated by task 2: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:319 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345 kasan_slab_alloc include/linux/kasan.h:247 [inline] slab_post_alloc_hook mm/slub.c:4086 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4187 alloc_task_struct_node kernel/fork.c:180 [inline] dup_task_struct+0x57/0x8c0 kernel/fork.c:1107 copy_process+0x5d1/0x3d50 kernel/fork.c:2206 kernel_clone+0x223/0x880 kernel/fork.c:2787 kernel_thread+0x1bc/0x240 kernel/fork.c:2849 create_kthread kernel/kthread.c:412 [inline] kthreadd+0x60d/0x810 kernel/kthread.c:765 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Freed by task 61: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:230 [inline] slab_free_h ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49868", "url": "https://ubuntu.com/security/CVE-2024-49868", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix a NULL pointer dereference when failed to start a new trasacntion [BUG] Syzbot reported a NULL pointer dereference with the following crash: FAULT_INJECTION: forcing a failure. start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676 prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642 relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678 ... BTRFS info (device loop0): balance: ended with status: -12 Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667] RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926 Call Trace: commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496 btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430 del_balance_item fs/btrfs/volumes.c:3678 [inline] reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742 btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574 btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673 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/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [CAUSE] The allocation failure happens at the start_transaction() inside prepare_to_relocate(), and during the error handling we call unset_reloc_control(), which makes fs_info->balance_ctl to be NULL. Then we continue the error path cleanup in btrfs_balance() by calling reset_balance_state() which will call del_balance_item() to fully delete the balance item in the root tree. However during the small window between set_reloc_contrl() and unset_reloc_control(), we can have a subvolume tree update and created a reloc_root for that subvolume. Then we go into the final btrfs_commit_transaction() of del_balance_item(), and into btrfs_update_reloc_root() inside commit_fs_roots(). That function checks if fs_info->reloc_ctl is in the merge_reloc_tree stage, but since fs_info->reloc_ctl is NULL, it results a NULL pointer dereference. [FIX] Just add extra check on fs_info->reloc_ctl inside btrfs_update_reloc_root(), before checking fs_info->reloc_ctl->merge_reloc_tree. That DEAD_RELOC_TREE handling is to prevent further modification to the reloc tree during merge stage, but since there is no reloc_ctl at all, we do not need to bother that.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49869", "url": "https://ubuntu.com/security/CVE-2024-49869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: send: fix buffer overflow detection when copying path to cache entry Starting with commit c0247d289e73 (\"btrfs: send: annotate struct name_cache_entry with __counted_by()\") we annotated the variable length array \"name\" from the name_cache_entry structure with __counted_by() to improve overflow detection. However that alone was not correct, because the length of that array does not match the \"name_len\" field - it matches that plus 1 to include the NUL string terminator, so that makes a fortified kernel think there's an overflow and report a splat like this: strcpy: detected buffer overflow: 20 byte write of buffer size 19 WARNING: CPU: 3 PID: 3310 at __fortify_report+0x45/0x50 CPU: 3 UID: 0 PID: 3310 Comm: btrfs Not tainted 6.11.0-prnet #1 Hardware name: CompuLab Ltd. sbc-ihsw/Intense-PC2 (IPC2), BIOS IPC2_3.330.7 X64 03/15/2018 RIP: 0010:__fortify_report+0x45/0x50 Code: 48 8b 34 (...) RSP: 0018:ffff97ebc0d6f650 EFLAGS: 00010246 RAX: 7749924ef60fa600 RBX: ffff8bf5446a521a RCX: 0000000000000027 RDX: 00000000ffffdfff RSI: ffff97ebc0d6f548 RDI: ffff8bf84e7a1cc8 RBP: ffff8bf548574080 R08: ffffffffa8c40e10 R09: 0000000000005ffd R10: 0000000000000004 R11: ffffffffa8c70e10 R12: ffff8bf551eef400 R13: 0000000000000000 R14: 0000000000000013 R15: 00000000000003a8 FS: 00007fae144de8c0(0000) GS:ffff8bf84e780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fae14691690 CR3: 00000001027a2003 CR4: 00000000001706f0 Call Trace: ? __warn+0x12a/0x1d0 ? __fortify_report+0x45/0x50 ? report_bug+0x154/0x1c0 ? handle_bug+0x42/0x70 ? exc_invalid_op+0x1a/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? __fortify_report+0x45/0x50 __fortify_panic+0x9/0x10 __get_cur_name_and_parent+0x3bc/0x3c0 get_cur_path+0x207/0x3b0 send_extent_data+0x709/0x10d0 ? find_parent_nodes+0x22df/0x25d0 ? mas_nomem+0x13/0x90 ? mtree_insert_range+0xa5/0x110 ? btrfs_lru_cache_store+0x5f/0x1e0 ? iterate_extent_inodes+0x52d/0x5a0 process_extent+0xa96/0x11a0 ? __pfx_lookup_backref_cache+0x10/0x10 ? __pfx_store_backref_cache+0x10/0x10 ? __pfx_iterate_backrefs+0x10/0x10 ? __pfx_check_extent_item+0x10/0x10 changed_cb+0x6fa/0x930 ? tree_advance+0x362/0x390 ? memcmp_extent_buffer+0xd7/0x160 send_subvol+0xf0a/0x1520 btrfs_ioctl_send+0x106b/0x11d0 ? __pfx___clone_root_cmp_sort+0x10/0x10 _btrfs_ioctl_send+0x1ac/0x240 btrfs_ioctl+0x75b/0x850 __se_sys_ioctl+0xca/0x150 do_syscall_64+0x85/0x160 ? __count_memcg_events+0x69/0x100 ? handle_mm_fault+0x1327/0x15c0 ? __se_sys_rt_sigprocmask+0xf1/0x180 ? syscall_exit_to_user_mode+0x75/0xa0 ? do_syscall_64+0x91/0x160 ? do_user_addr_fault+0x21d/0x630 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fae145eeb4f Code: 00 48 89 (...) RSP: 002b:00007ffdf1cb09b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fae145eeb4f RDX: 00007ffdf1cb0ad0 RSI: 0000000040489426 RDI: 0000000000000004 RBP: 00000000000078fe R08: 00007fae144006c0 R09: 00007ffdf1cb0927 R10: 0000000000000008 R11: 0000000000000246 R12: 00007ffdf1cb1ce8 R13: 0000000000000003 R14: 000055c499fab2e0 R15: 0000000000000004 Fix this by not storing the NUL string terminator since we don't actually need it for name cache entries, this way \"name_len\" corresponds to the actual size of the \"name\" array. This requires marking the \"name\" array field with __nonstring and using memcpy() instead of strcpy() as recommended by the guidelines at: https://github.com/KSPP/linux/issues/90", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49870", "url": "https://ubuntu.com/security/CVE-2024-49870", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cachefiles: fix dentry leak in cachefiles_open_file() A dentry leak may be caused when a lookup cookie and a cull are concurrent: P1 | P2 ----------------------------------------------------------- cachefiles_lookup_cookie cachefiles_look_up_object lookup_one_positive_unlocked // get dentry cachefiles_cull inode->i_flags |= S_KERNEL_FILE; cachefiles_open_file cachefiles_mark_inode_in_use __cachefiles_mark_inode_in_use can_use = false if (!(inode->i_flags & S_KERNEL_FILE)) can_use = true \t return false return false // Returns an error but doesn't put dentry After that the following WARNING will be triggered when the backend folder is umounted: ================================================================== BUG: Dentry 000000008ad87947{i=7a,n=Dx_1_1.img} still in use (1) [unmount of ext4 sda] WARNING: CPU: 4 PID: 359261 at fs/dcache.c:1767 umount_check+0x5d/0x70 CPU: 4 PID: 359261 Comm: umount Not tainted 6.6.0-dirty #25 RIP: 0010:umount_check+0x5d/0x70 Call Trace: d_walk+0xda/0x2b0 do_one_tree+0x20/0x40 shrink_dcache_for_umount+0x2c/0x90 generic_shutdown_super+0x20/0x160 kill_block_super+0x1a/0x40 ext4_kill_sb+0x22/0x40 deactivate_locked_super+0x35/0x80 cleanup_mnt+0x104/0x160 ================================================================== Whether cachefiles_open_file() returns true or false, the reference count obtained by lookup_positive_unlocked() in cachefiles_look_up_object() should be released. Therefore release that reference count in cachefiles_look_up_object() to fix the above issue and simplify the code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49871", "url": "https://ubuntu.com/security/CVE-2024-49871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: adp5589-keys - fix NULL pointer dereference We register a devm action to call adp5589_clear_config() and then pass the i2c client as argument so that we can call i2c_get_clientdata() in order to get our device object. However, i2c_set_clientdata() is only being set at the end of the probe function which means that we'll get a NULL pointer dereference in case the probe function fails early.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49872", "url": "https://ubuntu.com/security/CVE-2024-49872", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/gup: fix memfd_pin_folios alloc race panic If memfd_pin_folios tries to create a hugetlb page, but someone else already did, then folio gets the value -EEXIST here: folio = memfd_alloc_folio(memfd, start_idx); if (IS_ERR(folio)) { ret = PTR_ERR(folio); if (ret != -EEXIST) goto err; then on the next trip through the \"while start_idx\" loop we panic here: if (folio) { folio_put(folio); To fix, set the folio to NULL on error.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49964", "url": "https://ubuntu.com/security/CVE-2024-49964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix memfd_pin_folios free_huge_pages leak memfd_pin_folios followed by unpin_folios fails to restore free_huge_pages if the pages were not already faulted in, because the folio refcount for pages created by memfd_alloc_folio never goes to 0. memfd_pin_folios needs another folio_put to undo the folio_try_get below: memfd_alloc_folio() alloc_hugetlb_folio_nodemask() dequeue_hugetlb_folio_nodemask() dequeue_hugetlb_folio_node_exact() folio_ref_unfreeze(folio, 1); ; adds 1 refcount folio_try_get() ; adds 1 refcount hugetlb_add_to_page_cache() ; adds 512 refcount (on x86) With the fix, after memfd_pin_folios + unpin_folios, the refcount for the (unfaulted) page is 512, which is correct, as the refcount for a faulted unpinned page is 513.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49873", "url": "https://ubuntu.com/security/CVE-2024-49873", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/filemap: fix filemap_get_folios_contig THP panic Patch series \"memfd-pin huge page fixes\". Fix multiple bugs that occur when using memfd_pin_folios with hugetlb pages and THP. The hugetlb bugs only bite when the page is not yet faulted in when memfd_pin_folios is called. The THP bug bites when the starting offset passed to memfd_pin_folios is not huge page aligned. See the commit messages for details. This patch (of 5): memfd_pin_folios on memory backed by THP panics if the requested start offset is not huge page aligned: BUG: kernel NULL pointer dereference, address: 0000000000000036 RIP: 0010:filemap_get_folios_contig+0xdf/0x290 RSP: 0018:ffffc9002092fbe8 EFLAGS: 00010202 RAX: 0000000000000002 RBX: 0000000000000002 RCX: 0000000000000002 The fault occurs here, because xas_load returns a folio with value 2: filemap_get_folios_contig() for (folio = xas_load(&xas); folio && xas.xa_index <= end; folio = xas_next(&xas)) { ... if (!folio_try_get(folio)) <-- BOOM \"2\" is an xarray sibling entry. We get it because memfd_pin_folios does not round the indices passed to filemap_get_folios_contig to huge page boundaries for THP, so we load from the middle of a huge page range see a sibling. (It does round for hugetlbfs, at the is_file_hugepages test). To fix, if the folio is a sibling, then return the next index as the starting point for the next call to filemap_get_folios_contig.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49977", "url": "https://ubuntu.com/security/CVE-2024-49977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: Fix zero-division error when disabling tc cbs The commit b8c43360f6e4 (\"net: stmmac: No need to calculate speed divider when offload is disabled\") allows the \"port_transmit_rate_kbps\" to be set to a value of 0, which is then passed to the \"div_s64\" function when tc-cbs is disabled. This leads to a zero-division error. When tc-cbs is disabled, the idleslope, sendslope, and credit values the credit values are not required to be configured. Therefore, adding a return statement after setting the txQ mode to DCB when tc-cbs is disabled would prevent a zero-division error.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49978", "url": "https://ubuntu.com/security/CVE-2024-49978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gso: fix udp gso fraglist segmentation after pull from frag_list Detect gso fraglist skbs with corrupted geometry (see below) and pass these to skb_segment instead of skb_segment_list, as the first can segment them correctly. 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 these skbs, breaking these invariants. In extreme cases they pull all data into skb linear. For UDP, this causes a NULL ptr deref in __udpv4_gso_segment_list_csum at udp_hdr(seg->next)->dest. Detect invalid geometry due to pull, by checking head_skb size. Don't just drop, as this may blackhole a destination. Convert to be able to pass to regular skb_segment.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49979", "url": "https://ubuntu.com/security/CVE-2024-49979", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gso: fix tcp fraglist segmentation after pull from frag_list Detect tcp gso fraglist skbs with corrupted geometry (see below) and pass these to skb_segment instead of skb_segment_list, as the first can segment them correctly. 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 these skbs, breaking these invariants. In extreme cases they pull all data into skb linear. For TCP, this causes a NULL ptr deref in __tcpv4_gso_segment_list_csum at tcp_hdr(seg->next). Detect invalid geometry due to pull, by checking head_skb size. Don't just drop, as this may blackhole a destination. Convert to be able to pass to regular skb_segment. Approach and description based on a patch by Willem de Bruijn.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49980", "url": "https://ubuntu.com/security/CVE-2024-49980", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vrf: revert \"vrf: Remove unnecessary RCU-bh critical section\" This reverts commit 504fc6f4f7f681d2a03aa5f68aad549d90eab853. dev_queue_xmit_nit is expected to be called with BH disabled. __dev_queue_xmit has the following: /* Disable soft irqs for various locks below. Also * stops preemption for RCU. */ rcu_read_lock_bh(); VRF must follow this invariant. The referenced commit removed this protection. Which triggered a lockdep warning: \t================================ \tWARNING: inconsistent lock state \t6.11.0 #1 Tainted: G W \t-------------------------------- \tinconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage. \tbtserver/134819 [HC0[0]:SC0[0]:HE1:SE1] takes: \tffff8882da30c118 (rlock-AF_PACKET){+.?.}-{2:2}, at: tpacket_rcv+0x863/0x3b30 \t{IN-SOFTIRQ-W} state was registered at: \t lock_acquire+0x19a/0x4f0 \t _raw_spin_lock+0x27/0x40 \t packet_rcv+0xa33/0x1320 \t __netif_receive_skb_core.constprop.0+0xcb0/0x3a90 \t __netif_receive_skb_list_core+0x2c9/0x890 \t netif_receive_skb_list_internal+0x610/0xcc0 [...] \tother info that might help us debug this: \t Possible unsafe locking scenario: \t CPU0 \t ---- \t lock(rlock-AF_PACKET); \t \t lock(rlock-AF_PACKET); \t *** DEADLOCK *** \tCall Trace: \t \t dump_stack_lvl+0x73/0xa0 \t mark_lock+0x102e/0x16b0 \t __lock_acquire+0x9ae/0x6170 \t lock_acquire+0x19a/0x4f0 \t _raw_spin_lock+0x27/0x40 \t tpacket_rcv+0x863/0x3b30 \t dev_queue_xmit_nit+0x709/0xa40 \t vrf_finish_direct+0x26e/0x340 [vrf] \t vrf_l3_out+0x5f4/0xe80 [vrf] \t __ip_local_out+0x51e/0x7a0 [...]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49981", "url": "https://ubuntu.com/security/CVE-2024-49981", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: venus: fix use after free bug in venus_remove due to race condition in venus_probe, core->work is bound with venus_sys_error_handler, which is used to handle error. The code use core->sys_err_done to make sync work. The core->work is started in venus_event_notify. If we call venus_remove, there might be an unfished work. The possible sequence is as follows: CPU0 CPU1 |venus_sys_error_handler venus_remove | hfi_destroy\t \t\t | venus_hfi_destroy\t | kfree(hdev);\t | |hfi_reinit \t\t\t\t\t |venus_hfi_queues_reinit |//use hdev Fix it by canceling the work in venus_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49956", "url": "https://ubuntu.com/security/CVE-2024-49956", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: fix double destroy_workqueue error When gfs2_fill_super() fails, destroy_workqueue() is called within gfs2_gl_hash_clear(), and the subsequent code path calls destroy_workqueue() on the same work queue again. This issue can be fixed by setting the work queue pointer to NULL after the first destroy_workqueue() call and checking for a NULL pointer before attempting to destroy the work queue again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50176", "url": "https://ubuntu.com/security/CVE-2024-50176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: k3-r5: Fix error handling when power-up failed By simply bailing out, the driver was violating its rule and internal assumptions that either both or no rproc should be initialized. E.g., this could cause the first core to be available but not the second one, leading to crashes on its shutdown later on while trying to dereference that second instance.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49982", "url": "https://ubuntu.com/security/CVE-2024-49982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: aoe: fix the potential use-after-free problem in more places For fixing CVE-2023-6270, f98364e92662 (\"aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts\") makes tx() calling dev_put() instead of doing in aoecmd_cfg_pkts(). It avoids that the tx() runs into use-after-free. Then Nicolai Stange found more places in aoe have potential use-after-free problem with tx(). e.g. revalidate(), aoecmd_ata_rw(), resend(), probe() and aoecmd_cfg_rsp(). Those functions also use aoenet_xmit() to push packet to tx queue. So they should also use dev_hold() to increase the refcnt of skb->dev. On the other hand, moving dev_put() to tx() causes that the refcnt of skb->dev be reduced to a negative value, because corresponding dev_hold() are not called in revalidate(), aoecmd_ata_rw(), resend(), probe(), and aoecmd_cfg_rsp(). This patch fixed this issue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49874", "url": "https://ubuntu.com/security/CVE-2024-49874", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: svc: Fix use after free vulnerability in svc_i3c_master Driver Due to Race Condition In the svc_i3c_master_probe function, &master->hj_work is bound with svc_i3c_master_hj_work, &master->ibi_work is bound with svc_i3c_master_ibi_work. And svc_i3c_master_ibi_work can start the hj_work, svc_i3c_master_irq_handler can start the ibi_work. If we remove the module which will call svc_i3c_master_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | svc_i3c_master_hj_work svc_i3c_master_remove | i3c_master_unregister(&master->base)| device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in svc_i3c_master_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49875", "url": "https://ubuntu.com/security/CVE-2024-49875", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: map the EBADMSG to nfserr_io to avoid warning Ext4 will throw -EBADMSG through ext4_readdir when a checksum error occurs, resulting in the following WARNING. Fix it by mapping EBADMSG to nfserr_io. nfsd_buffered_readdir iterate_dir // -EBADMSG -74 ext4_readdir // .iterate_shared ext4_dx_readdir ext4_htree_fill_tree htree_dirblock_to_tree ext4_read_dirblock __ext4_read_dirblock ext4_dirblock_csum_verify warn_no_space_for_csum __warn_no_space_for_csum return ERR_PTR(-EFSBADCRC) // -EBADMSG -74 nfserrno // WARNING [ 161.115610] ------------[ cut here ]------------ [ 161.116465] nfsd: non-standard errno: -74 [ 161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0 [ 161.118596] Modules linked in: [ 161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138 [ 161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qe mu.org 04/01/2014 [ 161.123601] RIP: 0010:nfserrno+0x9d/0xd0 [ 161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6 05 ce 2b 61 03 01 e8 99 20 d8 00 <0f> 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33 [ 161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286 [ 161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a [ 161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827 [ 161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021 [ 161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8 [ 161.135244] FS: 0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000 [ 161.136695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0 [ 161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 161.141519] PKRU: 55555554 [ 161.142076] Call Trace: [ 161.142575] ? __warn+0x9b/0x140 [ 161.143229] ? nfserrno+0x9d/0xd0 [ 161.143872] ? report_bug+0x125/0x150 [ 161.144595] ? handle_bug+0x41/0x90 [ 161.145284] ? exc_invalid_op+0x14/0x70 [ 161.146009] ? asm_exc_invalid_op+0x12/0x20 [ 161.146816] ? nfserrno+0x9d/0xd0 [ 161.147487] nfsd_buffered_readdir+0x28b/0x2b0 [ 161.148333] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.149258] ? nfsd_buffered_filldir+0xf0/0xf0 [ 161.150093] ? wait_for_concurrent_writes+0x170/0x170 [ 161.151004] ? generic_file_llseek_size+0x48/0x160 [ 161.151895] nfsd_readdir+0x132/0x190 [ 161.152606] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.153516] ? nfsd_unlink+0x380/0x380 [ 161.154256] ? override_creds+0x45/0x60 [ 161.155006] nfsd4_encode_readdir+0x21a/0x3d0 [ 161.155850] ? nfsd4_encode_readlink+0x210/0x210 [ 161.156731] ? write_bytes_to_xdr_buf+0x97/0xe0 [ 161.157598] ? __write_bytes_to_xdr_buf+0xd0/0xd0 [ 161.158494] ? lock_downgrade+0x90/0x90 [ 161.159232] ? nfs4svc_decode_voidarg+0x10/0x10 [ 161.160092] nfsd4_encode_operation+0x15a/0x440 [ 161.160959] nfsd4_proc_compound+0x718/0xe90 [ 161.161818] nfsd_dispatch+0x18e/0x2c0 [ 161.162586] svc_process_common+0x786/0xc50 [ 161.163403] ? nfsd_svc+0x380/0x380 [ 161.164137] ? svc_printk+0x160/0x160 [ 161.164846] ? svc_xprt_do_enqueue.part.0+0x365/0x380 [ 161.165808] ? nfsd_svc+0x380/0x380 [ 161.166523] ? rcu_is_watching+0x23/0x40 [ 161.167309] svc_process+0x1a5/0x200 [ 161.168019] nfsd+0x1f5/0x380 [ 161.168663] ? nfsd_shutdown_threads+0x260/0x260 [ 161.169554] kthread+0x1c4/0x210 [ 161.170224] ? kthread_insert_work_sanity_check+0x80/0x80 [ 161.171246] ret_from_fork+0x1f/0x30", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50013", "url": "https://ubuntu.com/security/CVE-2024-50013", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix memory leak in exfat_load_bitmap() If the first directory entry in the root directory is not a bitmap directory entry, 'bh' will not be released and reassigned, which will cause a memory leak.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49876", "url": "https://ubuntu.com/security/CVE-2024-49876", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: fix UAF around queue destruction We currently do stuff like queuing the final destruction step on a random system wq, which will outlive the driver instance. With bad timing we can teardown the driver with one or more work workqueue still being alive leading to various UAF splats. Add a fini step to ensure user queues are properly torn down. At this point GuC should already be nuked so queue itself should no longer be referenced from hw pov. v2 (Matt B) - Looks much safer to use a waitqueue and then just wait for the xa_array to become empty before triggering the drain. (cherry picked from commit 861108666cc0e999cffeab6aff17b662e68774e3)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49877", "url": "https://ubuntu.com/security/CVE-2024-49877", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate When doing cleanup, if flags without OCFS2_BH_READAHEAD, it may trigger NULL pointer dereference in the following ocfs2_set_buffer_uptodate() if bh is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49957", "url": "https://ubuntu.com/security/CVE-2024-49957", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix null-ptr-deref when journal load failed. During the mounting process, if journal_reset() fails because of too short journal, then lead to jbd2_journal_load() fails with NULL j_sb_buffer. Subsequently, ocfs2_journal_shutdown() calls jbd2_journal_flush()->jbd2_cleanup_journal_tail()-> __jbd2_update_log_tail()->jbd2_journal_update_sb_log_tail() ->lock_buffer(journal->j_sb_buffer), resulting in a null-pointer dereference error. To resolve this issue, we should check the JBD2_LOADED flag to ensure the journal was properly loaded. Additionally, use journal instead of osb->journal directly to simplify the code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49965", "url": "https://ubuntu.com/security/CVE-2024-49965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove unreasonable unlock in ocfs2_read_blocks Patch series \"Misc fixes for ocfs2_read_blocks\", v5. This series contains 2 fixes for ocfs2_read_blocks(). The first patch fix the issue reported by syzbot, which detects bad unlock balance in ocfs2_read_blocks(). The second patch fixes an issue reported by Heming Zhao when reviewing above fix. This patch (of 2): There was a lock release before exiting, so remove the unreasonable unlock.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49966", "url": "https://ubuntu.com/security/CVE-2024-49966", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: cancel dqi_sync_work before freeing oinfo ocfs2_global_read_info() will initialize and schedule dqi_sync_work at the end, if error occurs after successfully reading global quota, it will trigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled: ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16c This reports that there is an active delayed work when freeing oinfo in error handling, so cancel dqi_sync_work first. BTW, return status instead of -1 when .read_file_info fails.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49958", "url": "https://ubuntu.com/security/CVE-2024-49958", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reserve space for inline xattr before attaching reflink tree One of our customers reported a crash and a corrupted ocfs2 filesystem. The crash was due to the detection of corruption. Upon troubleshooting, the fsck -fn output showed the below corruption [EXTENT_LIST_FREE] Extent list in owner 33080590 claims 230 as the next free chain record, but fsck believes the largest valid value is 227. Clamp the next record value? n The stat output from the debugfs.ocfs2 showed the following corruption where the \"Next Free Rec:\" had overshot the \"Count:\" in the root metadata block. Inode: 33080590 Mode: 0640 Generation: 2619713622 (0x9c25a856) FS Generation: 904309833 (0x35e6ac49) CRC32: 00000000 ECC: 0000 Type: Regular Attr: 0x0 Flags: Valid Dynamic Features: (0x16) HasXattr InlineXattr Refcounted Extended Attributes Block: 0 Extended Attributes Inline Size: 256 User: 0 (root) Group: 0 (root) Size: 281320357888 Links: 1 Clusters: 141738 ctime: 0x66911b56 0x316edcb8 -- Fri Jul 12 06:02:30.829349048 2024 atime: 0x66911d6b 0x7f7a28d -- Fri Jul 12 06:11:23.133669517 2024 mtime: 0x66911b56 0x12ed75d7 -- Fri Jul 12 06:02:30.317552087 2024 dtime: 0x0 -- Wed Dec 31 17:00:00 1969 Refcount Block: 2777346 Last Extblk: 2886943 Orphan Slot: 0 Sub Alloc Slot: 0 Sub Alloc Bit: 14 Tree Depth: 1 Count: 227 Next Free Rec: 230 ## Offset Clusters Block# 0 0 2310 2776351 1 2310 2139 2777375 2 4449 1221 2778399 3 5670 731 2779423 4 6401 566 2780447 ....... .... ....... ....... .... ....... The issue was in the reflink workfow while reserving space for inline xattr. The problematic function is ocfs2_reflink_xattr_inline(). By the time this function is called the reflink tree is already recreated at the destination inode from the source inode. At this point, this function reserves space for inline xattrs at the destination inode without even checking if there is space at the root metadata block. It simply reduces the l_count from 243 to 227 thereby making space of 256 bytes for inline xattr whereas the inode already has extents beyond this index (in this case up to 230), thereby causing corruption. The fix for this is to reserve space for inline metadata at the destination inode before the reflink tree gets recreated. The customer has verified the fix.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49959", "url": "https://ubuntu.com/security/CVE-2024-49959", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail() to recover some journal space. But if an error occurs while executing jbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for free space right away, we try other branches, and if j_committing_transaction is NULL (i.e., the tid is 0), we will get the following complain: ============================================ JBD2: I/O error when updating journal superblock for sdd-8. __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available __jbd2_log_wait_for_space: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Call Trace: add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70 [...] ============================================ So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways. Note that this fix relies on commit 6f6a6fda2945 (\"jbd2: fix ocfs2 corrupt when updating journal superblock fails\") to make jbd2_cleanup_journal_tail return the correct error code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49878", "url": "https://ubuntu.com/security/CVE-2024-49878", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: resource: fix region_intersects() vs add_memory_driver_managed() On a system with CXL memory, the resource tree (/proc/iomem) related to CXL memory may look like something as follows. 490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem) Because drivers/dax/kmem.c calls add_memory_driver_managed() during onlining CXL memory, which makes \"System RAM (kmem)\" a descendant of \"CXL Window X\". This confuses region_intersects(), which expects all \"System RAM\" resources to be at the top level of iomem_resource. This can lead to bugs. For example, when the following command line is executed to write some memory in CXL memory range via /dev/mem, $ dd if=data of=/dev/mem bs=$((1 << 10)) seek=$((0x490000000 >> 10)) count=1 dd: error writing '/dev/mem': Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/s the command fails as expected. However, the error code is wrong. It should be \"Operation not permitted\" instead of \"Bad address\". More seriously, the /dev/mem permission checking in devmem_is_allowed() passes incorrectly. Although the accessing is prevented later because ioremap() isn't allowed to map system RAM, it is a potential security issue. During command executing, the following warning is reported in the kernel log for calling ioremap() on system RAM. ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d Call Trace: memremap+0xcb/0x184 xlate_dev_mem_ptr+0x25/0x2f write_mem+0x94/0xfb vfs_write+0x128/0x26d ksys_write+0xac/0xfe do_syscall_64+0x9a/0xfd entry_SYSCALL_64_after_hwframe+0x4b/0x53 The details of command execution process are as follows. In the above resource tree, \"System RAM\" is a descendant of \"CXL Window 0\" instead of a top level resource. So, region_intersects() will report no System RAM resources in the CXL memory region incorrectly, because it only checks the top level resources. Consequently, devmem_is_allowed() will return 1 (allow access via /dev/mem) for CXL memory region incorrectly. Fortunately, ioremap() doesn't allow to map System RAM and reject the access. So, region_intersects() needs to be fixed to work correctly with the resource tree with \"System RAM\" not at top level as above. To fix it, if we found a unmatched resource in the top level, we will continue to search matched resources in its descendant resources. So, we will not miss any matched resources in resource tree anymore. In the new implementation, an example resource tree |------------- \"CXL Window 0\" ------------| |-- \"System RAM\" --| will behave similar as the following fake resource tree for region_intersects(, IORESOURCE_SYSTEM_RAM, ), |-- \"System RAM\" --||-- \"CXL Window 0a\" --| Where \"CXL Window 0a\" is part of the original \"CXL Window 0\" that isn't covered by \"System RAM\".", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49879", "url": "https://ubuntu.com/security/CVE-2024-49879", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm: omapdrm: Add missing check for alloc_ordered_workqueue As it may return NULL pointer and cause NULL pointer dereference. Add check for the return value of alloc_ordered_workqueue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49880", "url": "https://ubuntu.com/security/CVE-2024-49880", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix off by one issue in alloc_flex_gd() Wesley reported an issue: ================================================================== EXT4-fs (dm-5): resizing filesystem from 7168 to 786432 blocks ------------[ cut here ]------------ kernel BUG at fs/ext4/resize.c:324! CPU: 9 UID: 0 PID: 3576 Comm: resize2fs Not tainted 6.11.0+ #27 RIP: 0010:ext4_resize_fs+0x1212/0x12d0 Call Trace: __ext4_ioctl+0x4e0/0x1800 ext4_ioctl+0x12/0x20 __x64_sys_ioctl+0x99/0xd0 x64_sys_call+0x1206/0x20d0 do_syscall_64+0x72/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e ================================================================== While reviewing the patch, Honza found that when adjusting resize_bg in alloc_flex_gd(), it was possible for flex_gd->resize_bg to be bigger than flexbg_size. The reproduction of the problem requires the following: o_group = flexbg_size * 2 * n; o_size = (o_group + 1) * group_size; n_group: [o_group + flexbg_size, o_group + flexbg_size * 2) o_size = (n_group + 1) * group_size; Take n=0,flexbg_size=16 as an example: last:15 |o---------------|--------------n-| o_group:0 resize to n_group:30 The corresponding reproducer is: img=test.img rm -f $img truncate -s 600M $img mkfs.ext4 -F $img -b 1024 -G 16 8M dev=`losetup -f --show $img` mkdir -p /tmp/test mount $dev /tmp/test resize2fs $dev 248M Delete the problematic plus 1 to fix the issue, and add a WARN_ON_ONCE() to prevent the issue from happening again. [ Note: another reproucer which this commit fixes is: img=test.img rm -f $img truncate -s 25MiB $img mkfs.ext4 -b 4096 -E nodiscard,lazy_itable_init=0,lazy_journal_init=0 $img truncate -s 3GiB $img dev=`losetup -f --show $img` mkdir -p /tmp/test mount $dev /tmp/test resize2fs $dev 3G umount $dev losetup -d $dev -- TYT ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49881", "url": "https://ubuntu.com/security/CVE-2024-49881", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: update orig_path in ext4_find_extent() In ext4_find_extent(), if the path is not big enough, we free it and set *orig_path to NULL. But after reallocating and successfully initializing the path, we don't update *orig_path, in which case the caller gets a valid path but a NULL ppath, and this may cause a NULL pointer dereference or a path memory leak. For example: ext4_split_extent path = *ppath = 2000 ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path = 2000); *orig_path = path = NULL; path = kcalloc() = 3000 ext4_split_extent_at(*ppath = NULL) path = *ppath; ex = path[depth].p_ext; // NULL pointer dereference! ================================================================== BUG: kernel NULL pointer dereference, address: 0000000000000010 CPU: 6 UID: 0 PID: 576 Comm: fsstress Not tainted 6.11.0-rc2-dirty #847 RIP: 0010:ext4_split_extent_at+0x6d/0x560 Call Trace: ext4_split_extent.isra.0+0xcb/0x1b0 ext4_ext_convert_to_initialized+0x168/0x6c0 ext4_ext_handle_unwritten_extents+0x325/0x4d0 ext4_ext_map_blocks+0x520/0xdb0 ext4_map_blocks+0x2b0/0x690 ext4_iomap_begin+0x20e/0x2c0 [...] ================================================================== Therefore, *orig_path is updated when the extent lookup succeeds, so that the caller can safely use path or *ppath.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50014", "url": "https://ubuntu.com/security/CVE-2024-50014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix access to uninitialised lock in fc replay path The following kernel trace can be triggered with fstest generic/629 when executed against a filesystem with fast-commit feature enabled: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x66/0x90 register_lock_class+0x759/0x7d0 __lock_acquire+0x85/0x2630 ? __find_get_block+0xb4/0x380 lock_acquire+0xd1/0x2d0 ? __ext4_journal_get_write_access+0xd5/0x160 _raw_spin_lock+0x33/0x40 ? __ext4_journal_get_write_access+0xd5/0x160 __ext4_journal_get_write_access+0xd5/0x160 ext4_reserve_inode_write+0x61/0xb0 __ext4_mark_inode_dirty+0x79/0x270 ? ext4_ext_replay_set_iblocks+0x2f8/0x450 ext4_ext_replay_set_iblocks+0x330/0x450 ext4_fc_replay+0x14c8/0x1540 ? jread+0x88/0x2e0 ? rcu_is_watching+0x11/0x40 do_one_pass+0x447/0xd00 jbd2_journal_recover+0x139/0x1b0 jbd2_journal_load+0x96/0x390 ext4_load_and_init_journal+0x253/0xd40 ext4_fill_super+0x2cc6/0x3180 ... In the replay path there's an attempt to lock sbi->s_bdev_wb_lock in function ext4_check_bdev_write_error(). Unfortunately, at this point this spinlock has not been initialized yet. Moving it's initialization to an earlier point in __ext4_fill_super() fixes this splat.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49960", "url": "https://ubuntu.com/security/CVE-2024-49960", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix timer use-after-free on failed mount Syzbot has found an ODEBUG bug in ext4_fill_super The del_timer_sync function cancels the s_err_report timer, which reminds about filesystem errors daily. We should guarantee the timer is no longer active before kfree(sbi). When filesystem mounting fails, the flow goes to failed_mount3, where an error occurs when ext4_stop_mmpd is called, causing a read I/O failure. This triggers the ext4_handle_error function that ultimately re-arms the timer, leaving the s_err_report timer active before kfree(sbi) is called. Fix the issue by canceling the s_err_report timer after calling ext4_stop_mmpd.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49882", "url": "https://ubuntu.com/security/CVE-2024-49882", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix double brelse() the buffer of the extents path In ext4_ext_try_to_merge_up(), set path[1].p_bh to NULL after it has been released, otherwise it may be released twice. An example of what triggers this is as follows: split2 map split1 |--------|-------|--------| ext4_ext_map_blocks ext4_ext_handle_unwritten_extents ext4_split_convert_extents // path->p_depth == 0 ext4_split_extent // 1. do split1 ext4_split_extent_at |ext4_ext_insert_extent | ext4_ext_create_new_leaf | ext4_ext_grow_indepth | le16_add_cpu(&neh->eh_depth, 1) | ext4_find_extent | // return -ENOMEM |// get error and try zeroout |path = ext4_find_extent | path->p_depth = 1 |ext4_ext_try_to_merge | ext4_ext_try_to_merge_up | path->p_depth = 0 | brelse(path[1].p_bh) ---> not set to NULL here |// zeroout success // 2. update path ext4_find_extent // 3. do split2 ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth le16_add_cpu(&neh->eh_depth, 1) ext4_find_extent path[0].p_bh = NULL; path->p_depth = 1 read_extent_tree_block ---> return err // path[1].p_bh is still the old value ext4_free_ext_path ext4_ext_drop_refs // path->p_depth == 1 brelse(path[1].p_bh) ---> brelse a buffer twice Finally got the following WARRNING when removing the buffer from lru: ============================================ VFS: brelse: Trying to free free buffer WARNING: CPU: 2 PID: 72 at fs/buffer.c:1241 __brelse+0x58/0x90 CPU: 2 PID: 72 Comm: kworker/u19:1 Not tainted 6.9.0-dirty #716 RIP: 0010:__brelse+0x58/0x90 Call Trace: __find_get_block+0x6e7/0x810 bdev_getblk+0x2b/0x480 __ext4_get_inode_loc+0x48a/0x1240 ext4_get_inode_loc+0xb2/0x150 ext4_reserve_inode_write+0xb7/0x230 __ext4_mark_inode_dirty+0x144/0x6a0 ext4_ext_insert_extent+0x9c8/0x3230 ext4_ext_map_blocks+0xf45/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] ============================================", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49883", "url": "https://ubuntu.com/security/CVE-2024-49883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: aovid use-after-free in ext4_ext_insert_extent() As Ojaswin mentioned in Link, in ext4_ext_insert_extent(), if the path is reallocated in ext4_ext_create_new_leaf(), we'll use the stale path and cause UAF. Below is a sample trace with dummy values: ext4_ext_insert_extent path = *ppath = 2000 ext4_ext_create_new_leaf(ppath) ext4_find_extent(ppath) path = *ppath = 2000 if (depth > path[0].p_maxdepth) kfree(path = 2000); *ppath = path = NULL; path = kcalloc() = 3000 *ppath = 3000; return path; /* here path is still 2000, UAF! */ eh = path[depth].p_hdr ================================================================== BUG: KASAN: slab-use-after-free in ext4_ext_insert_extent+0x26d4/0x3330 Read of size 8 at addr ffff8881027bf7d0 by task kworker/u36:1/179 CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 Not tainted 6.11.0-rc2-dirty #866 Call Trace: ext4_ext_insert_extent+0x26d4/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 [...] Allocated by task 179: ext4_find_extent+0x81c/0x1f70 ext4_ext_map_blocks+0x146/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...] Freed by task 179: kfree+0xcb/0x240 ext4_find_extent+0x7c0/0x1f70 ext4_ext_insert_extent+0xa26/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...] ================================================================== So use *ppath to update the path to avoid the above problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49983", "url": "https://ubuntu.com/security/CVE-2024-49983", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-free When calling ext4_force_split_extent_at() in ext4_ext_replay_update_ex(), the 'ppath' is updated but it is the 'path' that is freed, thus potentially triggering a double-free in the following process: ext4_ext_replay_update_ex ppath = path ext4_force_split_extent_at(&ppath) ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path) ---> path First freed *orig_path = path = NULL ---> null ppath kfree(path) ---> path double-free !!! So drop the unnecessary ppath and use path directly to avoid this problem. And use ext4_find_extent() directly to update path, avoiding unnecessary memory allocation and freeing. Also, propagate the error returned by ext4_find_extent() instead of using strange error codes.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50015", "url": "https://ubuntu.com/security/CVE-2024-50015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: dax: fix overflowing extents beyond inode size when partially writing The dax_iomap_rw() does two things in each iteration: map written blocks and copy user data to blocks. If the process is killed by user(See signal handling in dax_iomap_iter()), the copied data will be returned and added on inode size, which means that the length of written extents may exceed the inode size, then fsck will fail. An example is given as: dd if=/dev/urandom of=file bs=4M count=1 dax_iomap_rw iomap_iter // round 1 ext4_iomap_begin ext4_iomap_alloc // allocate 0~2M extents(written flag) dax_iomap_iter // copy 2M data iomap_iter // round 2 iomap_iter_advance iter->pos += iter->processed // iter->pos = 2M ext4_iomap_begin ext4_iomap_alloc // allocate 2~4M extents(written flag) dax_iomap_iter fatal_signal_pending done = iter->pos - iocb->ki_pos // done = 2M ext4_handle_inode_extension ext4_update_inode_size // inode size = 2M fsck reports: Inode 13, i_size is 2097152, should be 4194304. Fix? Fix the problem by truncating extents if the written length is smaller than expected.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49884", "url": "https://ubuntu.com/security/CVE-2024-49884", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix slab-use-after-free in ext4_split_extent_at() We hit the following use-after-free: ================================================================== BUG: KASAN: slab-use-after-free in ext4_split_extent_at+0xba8/0xcc0 Read of size 2 at addr ffff88810548ed08 by task kworker/u20:0/40 CPU: 0 PID: 40 Comm: kworker/u20:0 Not tainted 6.9.0-dirty #724 Call Trace: kasan_report+0x93/0xc0 ext4_split_extent_at+0xba8/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] Allocated by task 40: __kmalloc_noprof+0x1ac/0x480 ext4_find_extent+0xf3b/0x1e70 ext4_ext_map_blocks+0x188/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] Freed by task 40: kfree+0xf1/0x2b0 ext4_find_extent+0xa71/0x1e70 ext4_ext_insert_extent+0xa22/0x3260 ext4_split_extent_at+0x3ef/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] ================================================================== The flow of issue triggering is as follows: ext4_split_extent_at path = *ppath ext4_ext_insert_extent(ppath) ext4_ext_create_new_leaf(ppath) ext4_find_extent(orig_path) path = *orig_path read_extent_tree_block // return -ENOMEM or -EIO ext4_free_ext_path(path) kfree(path) *orig_path = NULL a. If err is -ENOMEM: ext4_ext_dirty(path + path->p_depth) // path use-after-free !!! b. If err is -EIO and we have EXT_DEBUG defined: ext4_ext_show_leaf(path) eh = path[depth].p_hdr // path also use-after-free !!! So when trying to zeroout or fix the extent length, call ext4_find_extent() to update the path. In addition we use *ppath directly as an ext4_ext_show_leaf() input to avoid possible use-after-free when EXT_DEBUG is defined, and to avoid unnecessary path updates.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49885", "url": "https://ubuntu.com/security/CVE-2024-49885", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm, slub: avoid zeroing kmalloc redzone Since commit 946fa0dbf2d8 (\"mm/slub: extend redzone check to extra allocated kmalloc space than requested\"), setting orig_size treats the wasted space (object_size - orig_size) as a redzone. However with init_on_free=1 we clear the full object->size, including the redzone. Additionally we clear the object metadata, including the stored orig_size, making it zero, which makes check_object() treat the whole object as a redzone. These issues lead to the following BUG report with \"slub_debug=FUZ init_on_free=1\": [ 0.000000] ============================================================================= [ 0.000000] BUG kmalloc-8 (Not tainted): kmalloc Redzone overwritten [ 0.000000] ----------------------------------------------------------------------------- [ 0.000000] [ 0.000000] 0xffff000010032858-0xffff00001003285f @offset=2136. First byte 0x0 instead of 0xcc [ 0.000000] FIX kmalloc-8: Restoring kmalloc Redzone 0xffff000010032858-0xffff00001003285f=0xcc [ 0.000000] Slab 0xfffffdffc0400c80 objects=36 used=23 fp=0xffff000010032a18 flags=0x3fffe0000000200(workingset|node=0|zone=0|lastcpupid=0x1ffff) [ 0.000000] Object 0xffff000010032858 @offset=2136 fp=0xffff0000100328c8 [ 0.000000] [ 0.000000] Redzone ffff000010032850: cc cc cc cc cc cc cc cc ........ [ 0.000000] Object ffff000010032858: cc cc cc cc cc cc cc cc ........ [ 0.000000] Redzone ffff000010032860: cc cc cc cc cc cc cc cc ........ [ 0.000000] Padding ffff0000100328b4: 00 00 00 00 00 00 00 00 00 00 00 00 ............ [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.11.0-rc3-next-20240814-00004-g61844c55c3f4 #144 [ 0.000000] Hardware name: NXP i.MX95 19X19 board (DT) [ 0.000000] Call trace: [ 0.000000] dump_backtrace+0x90/0xe8 [ 0.000000] show_stack+0x18/0x24 [ 0.000000] dump_stack_lvl+0x74/0x8c [ 0.000000] dump_stack+0x18/0x24 [ 0.000000] print_trailer+0x150/0x218 [ 0.000000] check_object+0xe4/0x454 [ 0.000000] free_to_partial_list+0x2f8/0x5ec To address the issue, use orig_size to clear the used area. And restore the value of orig_size after clear the remaining area. When CONFIG_SLUB_DEBUG not defined, (get_orig_size()' directly returns s->object_size. So when using memset to init the area, the size can simply be orig_size, as orig_size returns object_size when CONFIG_SLUB_DEBUG not enabled. And orig_size can never be bigger than object_size.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49961", "url": "https://ubuntu.com/security/CVE-2024-49961", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: ar0521: Use cansleep version of gpiod_set_value() If we use GPIO reset from I2C port expander, we must use *_cansleep() variant of GPIO functions. This was not done in ar0521_power_on()/ar0521_power_off() functions. Let's fix that. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 11 at drivers/gpio/gpiolib.c:3496 gpiod_set_value+0x74/0x7c Modules linked in: CPU: 0 PID: 11 Comm: kworker/u16:0 Not tainted 6.10.0 #53 Hardware name: Diasom DS-RK3568-SOM-EVB (DT) Workqueue: events_unbound deferred_probe_work_func pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : gpiod_set_value+0x74/0x7c lr : ar0521_power_on+0xcc/0x290 sp : ffffff8001d7ab70 x29: ffffff8001d7ab70 x28: ffffff80027dcc90 x27: ffffff8003c82000 x26: ffffff8003ca9250 x25: ffffffc080a39c60 x24: ffffff8003ca9088 x23: ffffff8002402720 x22: ffffff8003ca9080 x21: ffffff8003ca9088 x20: 0000000000000000 x19: ffffff8001eb2a00 x18: ffffff80efeeac80 x17: 756d2d6332692f30 x16: 0000000000000000 x15: 0000000000000000 x14: ffffff8001d91d40 x13: 0000000000000016 x12: ffffffc080e98930 x11: ffffff8001eb2880 x10: 0000000000000890 x9 : ffffff8001d7a9f0 x8 : ffffff8001d92570 x7 : ffffff80efeeac80 x6 : 000000003fc6e780 x5 : ffffff8001d91c80 x4 : 0000000000000002 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000001 Call trace: gpiod_set_value+0x74/0x7c ar0521_power_on+0xcc/0x290 ...", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49985", "url": "https://ubuntu.com/security/CVE-2024-49985", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume In case there is any sort of clock controller attached to this I2C bus controller, for example Versaclock or even an AIC32x4 I2C codec, then an I2C transfer triggered from the clock controller clk_ops .prepare callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex. This is because the clock controller first grabs the prepare_lock mutex and then performs the prepare operation, including its I2C access. The I2C access resumes this I2C bus controller via .runtime_resume callback, which calls clk_prepare_enable(), which attempts to grab the prepare_lock mutex again and deadlocks. Since the clock are already prepared since probe() and unprepared in remove(), use simple clk_enable()/clk_disable() calls to enable and disable the clock on runtime suspend and resume, to avoid hitting the prepare_lock mutex.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49886", "url": "https://ubuntu.com/security/CVE-2024-49886", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bug Attaching SST PCI device to VM causes \"BUG: KASAN: slab-out-of-bounds\". kasan report: [ 19.411889] ================================================================== [ 19.413702] BUG: KASAN: slab-out-of-bounds in _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.415634] Read of size 8 at addr ffff888829e65200 by task cpuhp/16/113 [ 19.417368] [ 19.418627] CPU: 16 PID: 113 Comm: cpuhp/16 Tainted: G E 6.9.0 #10 [ 19.420435] Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.20192059.B64.2207280713 07/28/2022 [ 19.422687] Call Trace: [ 19.424091] [ 19.425448] dump_stack_lvl+0x5d/0x80 [ 19.426963] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.428694] print_report+0x19d/0x52e [ 19.430206] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 19.431837] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.433539] kasan_report+0xf0/0x170 [ 19.435019] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.436709] _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.438379] ? __pfx_sched_clock_cpu+0x10/0x10 [ 19.439910] isst_if_cpu_online+0x406/0x58f [isst_if_common] [ 19.441573] ? __pfx_isst_if_cpu_online+0x10/0x10 [isst_if_common] [ 19.443263] ? ttwu_queue_wakelist+0x2c1/0x360 [ 19.444797] cpuhp_invoke_callback+0x221/0xec0 [ 19.446337] cpuhp_thread_fun+0x21b/0x610 [ 19.447814] ? __pfx_cpuhp_thread_fun+0x10/0x10 [ 19.449354] smpboot_thread_fn+0x2e7/0x6e0 [ 19.450859] ? __pfx_smpboot_thread_fn+0x10/0x10 [ 19.452405] kthread+0x29c/0x350 [ 19.453817] ? __pfx_kthread+0x10/0x10 [ 19.455253] ret_from_fork+0x31/0x70 [ 19.456685] ? __pfx_kthread+0x10/0x10 [ 19.458114] ret_from_fork_asm+0x1a/0x30 [ 19.459573] [ 19.460853] [ 19.462055] Allocated by task 1198: [ 19.463410] kasan_save_stack+0x30/0x50 [ 19.464788] kasan_save_track+0x14/0x30 [ 19.466139] __kasan_kmalloc+0xaa/0xb0 [ 19.467465] __kmalloc+0x1cd/0x470 [ 19.468748] isst_if_cdev_register+0x1da/0x350 [isst_if_common] [ 19.470233] isst_if_mbox_init+0x108/0xff0 [isst_if_mbox_msr] [ 19.471670] do_one_initcall+0xa4/0x380 [ 19.472903] do_init_module+0x238/0x760 [ 19.474105] load_module+0x5239/0x6f00 [ 19.475285] init_module_from_file+0xd1/0x130 [ 19.476506] idempotent_init_module+0x23b/0x650 [ 19.477725] __x64_sys_finit_module+0xbe/0x130 [ 19.476506] idempotent_init_module+0x23b/0x650 [ 19.477725] __x64_sys_finit_module+0xbe/0x130 [ 19.478920] do_syscall_64+0x82/0x160 [ 19.480036] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 19.481292] [ 19.482205] The buggy address belongs to the object at ffff888829e65000 which belongs to the cache kmalloc-512 of size 512 [ 19.484818] The buggy address is located 0 bytes to the right of allocated 512-byte region [ffff888829e65000, ffff888829e65200) [ 19.487447] [ 19.488328] The buggy address belongs to the physical page: [ 19.489569] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888829e60c00 pfn:0x829e60 [ 19.491140] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [ 19.492466] anon flags: 0x57ffffc0000840(slab|head|node=1|zone=2|lastcpupid=0x1fffff) [ 19.493914] page_type: 0xffffffff() [ 19.494988] raw: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [ 19.496451] raw: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [ 19.497906] head: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [ 19.499379] head: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [ 19.500844] head: 0057ffffc0000003 ffffea0020a79801 ffffea0020a79848 00000000ffffffff [ 19.502316] head: 0000000800000000 0000000000000000 00000000ffffffff 0000000000000000 [ 19.503784] page dumped because: k ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49986", "url": "https://ubuntu.com/security/CVE-2024-49986", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: x86-android-tablets: Fix use after free on platform_device_register() errors x86_android_tablet_remove() frees the pdevs[] array, so it should not be used after calling x86_android_tablet_remove(). When platform_device_register() fails, store the pdevs[x] PTR_ERR() value into the local ret variable before calling x86_android_tablet_remove() to avoid using pdevs[] after it has been freed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49887", "url": "https://ubuntu.com/security/CVE-2024-49887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to don't panic system for no free segment fault injection f2fs: fix to don't panic system for no free segment fault injection syzbot reports a f2fs bug as below: F2FS-fs (loop0): inject no free segment in get_new_segment of __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3167 F2FS-fs (loop0): Stopped filesystem due to reason: 7 ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2748! CPU: 0 UID: 0 PID: 5109 Comm: syz-executor304 Not tainted 6.11.0-rc6-syzkaller-00363-g89f5e14d05b4 #0 RIP: 0010:get_new_segment fs/f2fs/segment.c:2748 [inline] RIP: 0010:new_curseg+0x1f61/0x1f70 fs/f2fs/segment.c:2836 Call Trace: __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3167 f2fs_allocate_new_section fs/f2fs/segment.c:3181 [inline] f2fs_allocate_pinning_section+0xfa/0x4e0 fs/f2fs/segment.c:3195 f2fs_expand_inode_data+0x5d6/0xbb0 fs/f2fs/file.c:1799 f2fs_fallocate+0x448/0x960 fs/f2fs/file.c:1903 vfs_fallocate+0x553/0x6c0 fs/open.c:334 do_vfs_ioctl+0x2592/0x2e50 fs/ioctl.c:886 __do_sys_ioctl fs/ioctl.c:905 [inline] __se_sys_ioctl+0x81/0x170 fs/ioctl.c:893 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: 0010:get_new_segment fs/f2fs/segment.c:2748 [inline] RIP: 0010:new_curseg+0x1f61/0x1f70 fs/f2fs/segment.c:2836 The root cause is when we inject no free segment fault into f2fs, we should not panic system, fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49888", "url": "https://ubuntu.com/security/CVE-2024-49888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix a sdiv overflow issue Zac Ecob reported a problem where a bpf program may cause kernel crash due to the following error: Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI The failure is due to the below signed divide: LLONG_MIN/-1 where LLONG_MIN equals to -9,223,372,036,854,775,808. LLONG_MIN/-1 is supposed to give a positive number 9,223,372,036,854,775,808, but it is impossible since for 64-bit system, the maximum positive number is 9,223,372,036,854,775,807. On x86_64, LLONG_MIN/-1 will cause a kernel exception. On arm64, the result for LLONG_MIN/-1 is LLONG_MIN. Further investigation found all the following sdiv/smod cases may trigger an exception when bpf program is running on x86_64 platform: - LLONG_MIN/-1 for 64bit operation - INT_MIN/-1 for 32bit operation - LLONG_MIN%-1 for 64bit operation - INT_MIN%-1 for 32bit operation where -1 can be an immediate or in a register. On arm64, there are no exceptions: - LLONG_MIN/-1 = LLONG_MIN - INT_MIN/-1 = INT_MIN - LLONG_MIN%-1 = 0 - INT_MIN%-1 = 0 where -1 can be an immediate or in a register. Insn patching is needed to handle the above cases and the patched codes produced results aligned with above arm64 result. The below are pseudo codes to handle sdiv/smod exceptions including both divisor -1 and divisor 0 and the divisor is stored in a register. sdiv: tmp = rX tmp += 1 /* [-1, 0] -> [0, 1] if tmp >(unsigned) 1 goto L2 if tmp == 0 goto L1 rY = 0 L1: rY = -rY; goto L3 L2: rY /= rX L3: smod: tmp = rX tmp += 1 /* [-1, 0] -> [0, 1] if tmp >(unsigned) 1 goto L1 if tmp == 1 (is64 ? goto L2 : goto L3) rY = 0; goto L2 L1: rY %= rX L2: goto L4 // only when !is64 L3: wY = wY // only when !is64 L4: [1] https://lore.kernel.org/bpf/tPJLTEh7S_DxFEqAI2Ji5MBSoZVg7_G-Py2iaZpAaWtM961fFTWtsnlzwvTbzBzaUzwQAoNATXKUlt0LZOFgnDcIyKCswAnAGdUF3LBrhGQ=@protonmail.com/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49987", "url": "https://ubuntu.com/security/CVE-2024-49987", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpftool: Fix undefined behavior in qsort(NULL, 0, ...) When netfilter has no entry to display, qsort is called with qsort(NULL, 0, ...). This results in undefined behavior, as UBSan reports: net.c:827:2: runtime error: null pointer passed as argument 1, which is declared to never be null Although the C standard does not explicitly state whether calling qsort with a NULL pointer when the size is 0 constitutes undefined behavior, Section 7.1.4 of the C standard (Use of library functions) mentions: \"Each of the following statements applies unless explicitly stated otherwise in the detailed descriptions that follow: If an argument to a function has an invalid value (such as a value outside the domain of the function, or a pointer outside the address space of the program, or a null pointer, or a pointer to non-modifiable storage when the corresponding parameter is not const-qualified) or a type (after promotion) not expected by a function with variable number of arguments, the behavior is undefined.\" To avoid this, add an early return when nf_link_info is NULL to prevent calling qsort with a NULL pointer.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50006", "url": "https://ubuntu.com/security/CVE-2024-50006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix i_data_sem unlock order in ext4_ind_migrate() Fuzzing reports a possible deadlock in jbd2_log_wait_commit. This issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to require synchronous updates because the file descriptor is opened with O_SYNC. This can lead to the jbd2_journal_stop() function calling jbd2_might_wait_for_commit(), potentially causing a deadlock if the EXT4_IOC_MIGRATE call races with a write(2) system call. This problem only arises when CONFIG_PROVE_LOCKING is enabled. In this case, the jbd2_might_wait_for_commit macro locks jbd2_handle in the jbd2_journal_stop function while i_data_sem is locked. This triggers lockdep because the jbd2_journal_start function might also lock the same jbd2_handle simultaneously. Found by Linux Verification Center (linuxtesting.org) with syzkaller. Rule: add", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49889", "url": "https://ubuntu.com/security/CVE-2024-49889", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid use-after-free in ext4_ext_show_leaf() In ext4_find_extent(), path may be freed by error or be reallocated, so using a previously saved *ppath may have been freed and thus may trigger use-after-free, as follows: ext4_split_extent path = *ppath; ext4_split_extent_at(ppath) path = ext4_find_extent(ppath) ext4_split_extent_at(ppath) // ext4_find_extent fails to free path // but zeroout succeeds ext4_ext_show_leaf(inode, path) eh = path[depth].p_hdr // path use-after-free !!! Similar to ext4_split_extent_at(), we use *ppath directly as an input to ext4_ext_show_leaf(). Fix a spelling error by the way. Same problem in ext4_ext_handle_unwritten_extents(). Since 'path' is only used in ext4_ext_show_leaf(), remove 'path' and use *ppath directly. This issue is triggered only when EXT_DEBUG is defined and therefore does not affect functionality.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49968", "url": "https://ubuntu.com/security/CVE-2024-49968", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: filesystems without casefold feature cannot be mounted with siphash When mounting the ext4 filesystem, if the default hash version is set to DX_HASH_SIPHASH but the casefold feature is not set, exit the mounting.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49988", "url": "https://ubuntu.com/security/CVE-2024-49988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: add refcnt to ksmbd_conn struct When sending an oplock break request, opinfo->conn is used, But freed ->conn can be used on multichannel. This patch add a reference count to the ksmbd_conn struct so that it can be freed when it is no longer used.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49890", "url": "https://ubuntu.com/security/CVE-2024-49890", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: ensure the fw_info is not null before using it This resolves the dereference null return value warning reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49891", "url": "https://ubuntu.com/security/CVE-2024-49891", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata paths When the HBA is undergoing a reset or is handling an errata event, NULL ptr dereference crashes may occur in routines such as lpfc_sli_flush_io_rings(), lpfc_dev_loss_tmo_callbk(), or lpfc_abort_handler(). Add NULL ptr checks before dereferencing hdwq pointers that may have been freed due to operations colliding with a reset or errata event handler.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49892", "url": "https://ubuntu.com/security/CVE-2024-49892", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize get_bytes_per_element's default to 1 Variables, used as denominators and maybe not assigned to other values, should not be 0. bytes_per_element_y & bytes_per_element_c are initialized by get_bytes_per_element() which should never return 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50016", "url": "https://ubuntu.com/security/CVE-2024-50016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Avoid overflow assignment in link_dp_cts sampling_rate is an uint8_t but is assigned an unsigned int, and thus it can overflow. As a result, sampling_rate is changed to uint32_t. Similarly, LINK_QUAL_PATTERN_SET has a size of 2 bits, and it should only be assigned to a value less or equal than 4. This fixes 2 INTEGER_OVERFLOW issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49893", "url": "https://ubuntu.com/security/CVE-2024-49893", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check stream_status before it is used [WHAT & HOW] dc_state_get_stream_status can return null, and therefore null must be checked before stream_status is used. This fixes 1 NULL_RETURNS issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49969", "url": "https://ubuntu.com/security/CVE-2024-49969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 color transformation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_hw_format` function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:180 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:181 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:182 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49970", "url": "https://ubuntu.com/security/CVE-2024-49970", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Implement bounds check for stream encoder creation in DCN401 'stream_enc_regs' array is an array of dcn10_stream_enc_registers structures. The array is initialized with four elements, corresponding to the four calls to stream_enc_regs() in the array initializer. This means that valid indices for this array are 0, 1, 2, and 3. The error message 'stream_enc_regs' 4 <= 5 below, is indicating that there is an attempt to access this array with an index of 5, which is out of bounds. This could lead to undefined behavior Here, eng_id is used as an index to access the stream_enc_regs array. If eng_id is 5, this would result in an out-of-bounds access on the stream_enc_regs array. Thus fixing Buffer overflow error in dcn401_stream_encoder_create Found by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn401/dcn401_resource.c:1209 dcn401_stream_encoder_create() error: buffer overflow 'stream_enc_regs' 4 <= 5", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49894", "url": "https://ubuntu.com/security/CVE-2024-49894", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in degamma hardware format translation Fixes index out of bounds issue in `cm_helper_translate_curve_to_degamma_hw_format` function. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49895", "url": "https://ubuntu.com/security/CVE-2024-49895", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format translation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_degamma_hw_format` function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:338 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:339 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:340 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49971", "url": "https://ubuntu.com/security/CVE-2024-49971", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Increase array size of dummy_boolean [WHY] dml2_core_shared_mode_support and dml_core_mode_support access the third element of dummy_boolean, i.e. hw_debug5 = &s->dummy_boolean[2], when dummy_boolean has size of 2. Any assignment to hw_debug5 causes an OVERRUN. [HOW] Increase dummy_boolean's array size to 3. This fixes 2 OVERRUN issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49972", "url": "https://ubuntu.com/security/CVE-2024-49972", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Deallocate DML memory if allocation fails [Why] When DC state create DML memory allocation fails, memory is not deallocated subsequently, resulting in uninitialized structure that is not NULL. [How] Deallocate memory if DML memory allocation fails.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49896", "url": "https://ubuntu.com/security/CVE-2024-49896", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check stream before comparing them [WHAT & HOW] amdgpu_dm can pass a null stream to dc_is_stream_unchanged. It is necessary to check for null before dereferencing them. This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49897", "url": "https://ubuntu.com/security/CVE-2024-49897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check phantom_stream before it is used dcn32_enable_phantom_stream can return null, so returned value must be checked before used. This fixes 1 NULL_RETURNS issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49898", "url": "https://ubuntu.com/security/CVE-2024-49898", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null-initialized variables [WHAT & HOW] drr_timing and subvp_pipe are initialized to null and they are not always assigned new values. It is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49899", "url": "https://ubuntu.com/security/CVE-2024-49899", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize denominators' default to 1 [WHAT & HOW] Variables used as denominators and maybe not assigned to other values, should not be 0. Change their default to 1 so they are never 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49900", "url": "https://ubuntu.com/security/CVE-2024-49900", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uninit-value access of new_ea in ea_buffer syzbot reports that lzo1x_1_do_compress is using uninit-value: ===================================================== BUG: KMSAN: uninit-value in lzo1x_1_do_compress+0x19f9/0x2510 lib/lzo/lzo1x_compress.c:178 ... Uninit was stored to memory at: ea_put fs/jfs/xattr.c:639 [inline] ... Local variable ea_buf created at: __jfs_setxattr+0x5d/0x1ae0 fs/jfs/xattr.c:662 __jfs_xattr_set+0xe6/0x1f0 fs/jfs/xattr.c:934 ===================================================== The reason is ea_buf->new_ea is not initialized properly. Fix this by using memset to empty its content at the beginning in ea_get().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49901", "url": "https://ubuntu.com/security/CVE-2024-49901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm/adreno: Assign msm_gpu->pdev earlier to avoid nullptrs There are some cases, such as the one uncovered by Commit 46d4efcccc68 (\"drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails\") where msm_gpu_cleanup() : platform_set_drvdata(gpu->pdev, NULL); is called on gpu->pdev == NULL, as the GPU device has not been fully initialized yet. Turns out that there's more than just the aforementioned path that causes this to happen (e.g. the case when there's speedbin data in the catalog, but opp-supported-hw is missing in DT). Assigning msm_gpu->pdev earlier seems like the least painful solution to this, therefore do so. Patchwork: https://patchwork.freedesktop.org/patch/602742/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49902", "url": "https://ubuntu.com/security/CVE-2024-49902", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: check if leafidx greater than num leaves per dmap tree syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf. Shaggy: Modified sanity check to apply to control pages as well as leaf pages.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49903", "url": "https://ubuntu.com/security/CVE-2024-49903", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uaf in dbFreeBits [syzbot reported] ================================================================== BUG: KASAN: slab-use-after-free in __mutex_lock_common kernel/locking/mutex.c:587 [inline] BUG: KASAN: slab-use-after-free in __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 Read of size 8 at addr ffff8880229254b0 by task syz-executor357/5216 CPU: 0 UID: 0 PID: 5216 Comm: syz-executor357 Not tainted 6.11.0-rc3-syzkaller-00156-gd7a5aa4b3c00 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 __mutex_lock_common kernel/locking/mutex.c:587 [inline] __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 dbFreeBits+0x7ea/0xd90 fs/jfs/jfs_dmap.c:2390 dbFreeDmap fs/jfs/jfs_dmap.c:2089 [inline] dbFree+0x35b/0x680 fs/jfs/jfs_dmap.c:409 dbDiscardAG+0x8a9/0xa20 fs/jfs/jfs_dmap.c:1650 jfs_ioc_trim+0x433/0x670 fs/jfs/jfs_discard.c:100 jfs_ioctl+0x2d0/0x3e0 fs/jfs/ioctl.c:131 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 Freed by task 5218: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object+0xe0/0x150 mm/kasan/common.c:240 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2252 [inline] slab_free mm/slub.c:4473 [inline] kfree+0x149/0x360 mm/slub.c:4594 dbUnmount+0x11d/0x190 fs/jfs/jfs_dmap.c:278 jfs_mount_rw+0x4ac/0x6a0 fs/jfs/jfs_mount.c:247 jfs_remount+0x3d1/0x6b0 fs/jfs/super.c:454 reconfigure_super+0x445/0x880 fs/super.c:1083 vfs_cmd_reconfigure fs/fsopen.c:263 [inline] vfs_fsconfig_locked fs/fsopen.c:292 [inline] __do_sys_fsconfig fs/fsopen.c:473 [inline] __se_sys_fsconfig+0xb6e/0xf80 fs/fsopen.c:345 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 [Analysis] There are two paths (dbUnmount and jfs_ioc_trim) that generate race condition when accessing bmap, which leads to the occurrence of uaf. Use the lock s_umount to synchronize them, in order to avoid uaf caused by race condition.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49904", "url": "https://ubuntu.com/security/CVE-2024-49904", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add list empty check to avoid null pointer issue Add list empty check to avoid null pointer issues in some corner cases. - list_for_each_entry_safe()", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49989", "url": "https://ubuntu.com/security/CVE-2024-49989", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix double free issue during amdgpu module unload Flexible endpoints use DIGs from available inflexible endpoints, so only the encoders of inflexible links need to be freed. Otherwise, a double free issue may occur when unloading the amdgpu module. [ 279.190523] RIP: 0010:__slab_free+0x152/0x2f0 [ 279.190577] Call Trace: [ 279.190580] [ 279.190582] ? show_regs+0x69/0x80 [ 279.190590] ? die+0x3b/0x90 [ 279.190595] ? do_trap+0xc8/0xe0 [ 279.190601] ? do_error_trap+0x73/0xa0 [ 279.190605] ? __slab_free+0x152/0x2f0 [ 279.190609] ? exc_invalid_op+0x56/0x70 [ 279.190616] ? __slab_free+0x152/0x2f0 [ 279.190642] ? asm_exc_invalid_op+0x1f/0x30 [ 279.190648] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191096] ? __slab_free+0x152/0x2f0 [ 279.191102] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191469] kfree+0x260/0x2b0 [ 279.191474] dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191821] link_destroy+0xd7/0x130 [amdgpu] [ 279.192248] dc_destruct+0x90/0x270 [amdgpu] [ 279.192666] dc_destroy+0x19/0x40 [amdgpu] [ 279.193020] amdgpu_dm_fini+0x16e/0x200 [amdgpu] [ 279.193432] dm_hw_fini+0x26/0x40 [amdgpu] [ 279.193795] amdgpu_device_fini_hw+0x24c/0x400 [amdgpu] [ 279.194108] amdgpu_driver_unload_kms+0x4f/0x70 [amdgpu] [ 279.194436] amdgpu_pci_remove+0x40/0x80 [amdgpu] [ 279.194632] pci_device_remove+0x3a/0xa0 [ 279.194638] device_remove+0x40/0x70 [ 279.194642] device_release_driver_internal+0x1ad/0x210 [ 279.194647] driver_detach+0x4e/0xa0 [ 279.194650] bus_remove_driver+0x6f/0xf0 [ 279.194653] driver_unregister+0x33/0x60 [ 279.194657] pci_unregister_driver+0x44/0x90 [ 279.194662] amdgpu_exit+0x19/0x1f0 [amdgpu] [ 279.194939] __do_sys_delete_module.isra.0+0x198/0x2f0 [ 279.194946] __x64_sys_delete_module+0x16/0x20 [ 279.194950] do_syscall_64+0x58/0x120 [ 279.194954] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 279.194980] ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49905", "url": "https://ubuntu.com/security/CVE-2024-49905", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for 'afb' in amdgpu_dm_plane_handle_cursor_update (v2) This commit adds a null check for the 'afb' variable in the amdgpu_dm_plane_handle_cursor_update function. Previously, 'afb' was assumed to be null, but was used later in the code without a null check. This could potentially lead to a null pointer dereference. Changes since v1: - Moved the null check for 'afb' to the line where 'afb' is used. (Alex) Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:1298 amdgpu_dm_plane_handle_cursor_update() error: we previously assumed 'afb' could be null (see line 1252)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49906", "url": "https://ubuntu.com/security/CVE-2024-49906", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before try to access it [why & how] Change the order of the pipe_ctx->plane_state check to ensure that plane_state is not null before accessing it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49907", "url": "https://ubuntu.com/security/CVE-2024-49907", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before using dc->clk_mgr [WHY & HOW] dc->clk_mgr is null checked previously in the same function, indicating it might be null. Passing \"dc\" to \"dc->hwss.apply_idle_power_optimizations\", which dereferences null \"dc->clk_mgr\". (The function pointer resolves to \"dcn35_apply_idle_power_optimizations\".) This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49908", "url": "https://ubuntu.com/security/CVE-2024-49908", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for 'afb' in amdgpu_dm_update_cursor (v2) This commit adds a null check for the 'afb' variable in the amdgpu_dm_update_cursor function. Previously, 'afb' was assumed to be null at line 8388, but was used later in the code without a null check. This could potentially lead to a null pointer dereference. Changes since v1: - Moved the null check for 'afb' to the line where 'afb' is used. (Alex) Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:8433 amdgpu_dm_update_cursor() \terror: we previously assumed 'afb' could be null (see line 8388)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50177", "url": "https://ubuntu.com/security/CVE-2024-50177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix a UBSAN warning in DML2.1 When programming phantom pipe, since cursor_width is explicity set to 0, this causes calculation logic to trigger overflow for an unsigned int triggering the kernel's UBSAN check as below: [ 40.962845] UBSAN: shift-out-of-bounds in /tmp/amd.EfpumTkO/amd/amdgpu/../display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c:3312:34 [ 40.962849] shift exponent 4294967170 is too large for 32-bit type 'unsigned int' [ 40.962852] CPU: 1 PID: 1670 Comm: gnome-shell Tainted: G W OE 6.5.0-41-generic #41~22.04.2-Ubuntu [ 40.962854] Hardware name: Gigabyte Technology Co., Ltd. X670E AORUS PRO X/X670E AORUS PRO X, BIOS F21 01/10/2024 [ 40.962856] Call Trace: [ 40.962857] [ 40.962860] dump_stack_lvl+0x48/0x70 [ 40.962870] dump_stack+0x10/0x20 [ 40.962872] __ubsan_handle_shift_out_of_bounds+0x1ac/0x360 [ 40.962878] calculate_cursor_req_attributes.cold+0x1b/0x28 [amdgpu] [ 40.963099] dml_core_mode_support+0x6b91/0x16bc0 [amdgpu] [ 40.963327] ? srso_alias_return_thunk+0x5/0x7f [ 40.963331] ? CalculateWatermarksMALLUseAndDRAMSpeedChangeSupport+0x18b8/0x2790 [amdgpu] [ 40.963534] ? srso_alias_return_thunk+0x5/0x7f [ 40.963536] ? dml_core_mode_support+0xb3db/0x16bc0 [amdgpu] [ 40.963730] dml2_core_calcs_mode_support_ex+0x2c/0x90 [amdgpu] [ 40.963906] ? srso_alias_return_thunk+0x5/0x7f [ 40.963909] ? dml2_core_calcs_mode_support_ex+0x2c/0x90 [amdgpu] [ 40.964078] core_dcn4_mode_support+0x72/0xbf0 [amdgpu] [ 40.964247] dml2_top_optimization_perform_optimization_phase+0x1d3/0x2a0 [amdgpu] [ 40.964420] dml2_build_mode_programming+0x23d/0x750 [amdgpu] [ 40.964587] dml21_validate+0x274/0x770 [amdgpu] [ 40.964761] ? srso_alias_return_thunk+0x5/0x7f [ 40.964763] ? resource_append_dpp_pipes_for_plane_composition+0x27c/0x3b0 [amdgpu] [ 40.964942] dml2_validate+0x504/0x750 [amdgpu] [ 40.965117] ? dml21_copy+0x95/0xb0 [amdgpu] [ 40.965291] ? srso_alias_return_thunk+0x5/0x7f [ 40.965295] dcn401_validate_bandwidth+0x4e/0x70 [amdgpu] [ 40.965491] update_planes_and_stream_state+0x38d/0x5c0 [amdgpu] [ 40.965672] update_planes_and_stream_v3+0x52/0x1e0 [amdgpu] [ 40.965845] ? srso_alias_return_thunk+0x5/0x7f [ 40.965849] dc_update_planes_and_stream+0x71/0xb0 [amdgpu] Fix this by adding a guard for checking cursor width before triggering the size calculation.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49909", "url": "https://ubuntu.com/security/CVE-2024-49909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn32_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn32_set_output_transfer_func function. Previously, set_output_gamma was being checked for null, but then it was being dereferenced without any null check. This could lead to a null pointer dereference if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49910", "url": "https://ubuntu.com/security/CVE-2024-49910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn401_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn401_set_output_transfer_func function. Previously, set_output_gamma was being checked for null, but then it was being dereferenced without any null check. This could lead to a null pointer dereference if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49911", "url": "https://ubuntu.com/security/CVE-2024-49911", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn20_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn20_set_output_transfer_func function. Previously, set_output_gamma was being checked for null at line 1030, but then it was being dereferenced without any null check at line 1048. This could potentially lead to a null pointer dereference error if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma at line 1048.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49912", "url": "https://ubuntu.com/security/CVE-2024-49912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Handle null 'stream_status' in 'planes_changed_for_existing_stream' This commit adds a null check for 'stream_status' in the function 'planes_changed_for_existing_stream'. Previously, the code assumed 'stream_status' could be null, but did not handle the case where it was actually null. This could lead to a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:3784 planes_changed_for_existing_stream() error: we previously assumed 'stream_status' could be null (see line 3774)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49913", "url": "https://ubuntu.com/security/CVE-2024-49913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for top_pipe_to_program in commit_planes_for_stream This commit addresses a null pointer dereference issue in the `commit_planes_for_stream` function at line 4140. The issue could occur when `top_pipe_to_program` is null. The fix adds a check to ensure `top_pipe_to_program` is not null before accessing its stream_res. This prevents a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:4140 commit_planes_for_stream() error: we previously assumed 'top_pipe_to_program' could be null (see line 3906)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49914", "url": "https://ubuntu.com/security/CVE-2024-49914", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for pipe_ctx->plane_state in dcn20_program_pipe This commit addresses a null pointer dereference issue in the `dcn20_program_pipe` function. The issue could occur when `pipe_ctx->plane_state` is null. The fix adds a check to ensure `pipe_ctx->plane_state` is not null before accessing. This prevents a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn20/dcn20_hwseq.c:1925 dcn20_program_pipe() error: we previously assumed 'pipe_ctx->plane_state' could be null (see line 1877)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49915", "url": "https://ubuntu.com/security/CVE-2024-49915", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr in dcn32_init_hw This commit addresses a potential null pointer dereference issue in the `dcn32_init_hw` function. The issue could occur when `dc->clk_mgr` is null. The fix adds a check to ensure `dc->clk_mgr` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn32/dcn32_hwseq.c:961 dcn32_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 782)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49916", "url": "https://ubuntu.com/security/CVE-2024-49916", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in dcn401_init_hw This commit addresses a potential null pointer dereference issue in the `dcn401_init_hw` function. The issue could occur when `dc->clk_mgr` or `dc->clk_mgr->funcs` is null. The fix adds a check to ensure `dc->clk_mgr` and `dc->clk_mgr->funcs` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn401/dcn401_hwseq.c:416 dcn401_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 225)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49917", "url": "https://ubuntu.com/security/CVE-2024-49917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in dcn30_init_hw This commit addresses a potential null pointer dereference issue in the `dcn30_init_hw` function. The issue could occur when `dc->clk_mgr` or `dc->clk_mgr->funcs` is null. The fix adds a check to ensure `dc->clk_mgr` and `dc->clk_mgr->funcs` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:789 dcn30_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 628)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49918", "url": "https://ubuntu.com/security/CVE-2024-49918", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for head_pipe in dcn32_acquire_idle_pipe_for_head_pipe_in_layer This commit addresses a potential null pointer dereference issue in the `dcn32_acquire_idle_pipe_for_head_pipe_in_layer` function. The issue could occur when `head_pipe` is null. The fix adds a check to ensure `head_pipe` is not null before asserting it. If `head_pipe` is null, the function returns NULL to prevent a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn32/dcn32_resource.c:2690 dcn32_acquire_idle_pipe_for_head_pipe_in_layer() error: we previously assumed 'head_pipe' could be null (see line 2681)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49919", "url": "https://ubuntu.com/security/CVE-2024-49919", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for head_pipe in dcn201_acquire_free_pipe_for_layer This commit addresses a potential null pointer dereference issue in the `dcn201_acquire_free_pipe_for_layer` function. The issue could occur when `head_pipe` is null. The fix adds a check to ensure `head_pipe` is not null before asserting it. If `head_pipe` is null, the function returns NULL to prevent a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn201/dcn201_resource.c:1016 dcn201_acquire_free_pipe_for_layer() error: we previously assumed 'head_pipe' could be null (see line 1010)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49991", "url": "https://ubuntu.com/security/CVE-2024-49991", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer Pass pointer reference to amdgpu_bo_unref to clear the correct pointer, otherwise amdgpu_bo_unref clear the local variable, the original pointer not set to NULL, this could cause use-after-free bug.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49920", "url": "https://ubuntu.com/security/CVE-2024-49920", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before multiple uses [WHAT & HOW] Poniters, such as stream_enc and dc->bw_vbios, are null checked previously in the same function, so Coverity warns \"implies that stream_enc and dc->bw_vbios might be null\". They are used multiple times in the subsequent code and need to be checked. This fixes 10 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49921", "url": "https://ubuntu.com/security/CVE-2024-49921", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before used [WHAT & HOW] Poniters, such as dc->clk_mgr, are null checked previously in the same function, so Coverity warns \"implies that \"dc->clk_mgr\" might be null\". As a result, these pointers need to be checked when used again. This fixes 10 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49922", "url": "https://ubuntu.com/security/CVE-2024-49922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before using them [WHAT & HOW] These pointers are null checked previously in the same function, indicating they might be null as reported by Coverity. As a result, they need to be checked when used again. This fixes 3 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49923", "url": "https://ubuntu.com/security/CVE-2024-49923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Pass non-null to dcn20_validate_apply_pipe_split_flags [WHAT & HOW] \"dcn20_validate_apply_pipe_split_flags\" dereferences merge, and thus it cannot be a null pointer. Let's pass a valid pointer to avoid null dereference. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49992", "url": "https://ubuntu.com/security/CVE-2024-49992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/stm: Avoid use-after-free issues with crtc and plane ltdc_load() calls functions drm_crtc_init_with_planes(), drm_universal_plane_init() and drm_encoder_init(). These functions should not be called with parameters allocated with devm_kzalloc() to avoid use-after-free issues [1]. Use allocations managed by the DRM framework. Found by Linux Verification Center (linuxtesting.org). [1] https://lore.kernel.org/lkml/u366i76e3qhh3ra5oxrtngjtm2u5lterkekcz6y2jkndhuxzli@diujon4h7qwb/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49993", "url": "https://ubuntu.com/security/CVE-2024-49993", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49924", "url": "https://ubuntu.com/security/CVE-2024-49924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: pxafb: Fix possible use after free in pxafb_task() In the pxafb_probe function, it calls the pxafb_init_fbinfo function, after which &fbi->task is associated with pxafb_task. Moreover, within this pxafb_init_fbinfo function, the pxafb_blank function within the &pxafb_ops struct is capable of scheduling work. If we remove the module which will call pxafb_remove to make cleanup, it will call unregister_framebuffer function which can call do_unregister_framebuffer to free fbi->fb through put_fb_info(fb_info), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | pxafb_task pxafb_remove | unregister_framebuffer(info) | do_unregister_framebuffer(fb_info) | put_fb_info(fb_info) | // free fbi->fb | set_ctrlr_state(fbi, state) | __pxafb_lcd_power(fbi, 0) | fbi->lcd_power(on, &fbi->fb.var) | //use fbi->fb Fix it by ensuring that the work is canceled before proceeding with the cleanup in pxafb_remove. Note that only root user can remove the driver at runtime.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49925", "url": "https://ubuntu.com/security/CVE-2024-49925", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: efifb: Register sysfs groups through driver core The driver core can register and cleanup sysfs groups already. Make use of that functionality to simplify the error handling and cleanup. Also avoid a UAF race during unregistering where the sysctl attributes were usable after the info struct was freed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49926", "url": "https://ubuntu.com/security/CVE-2024-49926", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rcu-tasks: Fix access non-existent percpu rtpcp variable in rcu_tasks_need_gpcb() For kernels built with CONFIG_FORCE_NR_CPUS=y, the nr_cpu_ids is defined as NR_CPUS instead of the number of possible cpus, this will cause the following system panic: smpboot: Allowing 4 CPUs, 0 hotplug CPUs ... setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:512 nr_node_ids:1 ... BUG: unable to handle page fault for address: ffffffff9911c8c8 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 15 Comm: rcu_tasks_trace Tainted: G W 6.6.21 #1 5dc7acf91a5e8e9ac9dcfc35bee0245691283ea6 RIP: 0010:rcu_tasks_need_gpcb+0x25d/0x2c0 RSP: 0018:ffffa371c00a3e60 EFLAGS: 00010082 CR2: ffffffff9911c8c8 CR3: 000000040fa20005 CR4: 00000000001706f0 Call Trace: ? __die+0x23/0x80 ? page_fault_oops+0xa4/0x180 ? exc_page_fault+0x152/0x180 ? asm_exc_page_fault+0x26/0x40 ? rcu_tasks_need_gpcb+0x25d/0x2c0 ? __pfx_rcu_tasks_kthread+0x40/0x40 rcu_tasks_one_gp+0x69/0x180 rcu_tasks_kthread+0x94/0xc0 kthread+0xe8/0x140 ? __pfx_kthread+0x40/0x40 ret_from_fork+0x34/0x80 ? __pfx_kthread+0x40/0x40 ret_from_fork_asm+0x1b/0x80 Considering that there may be holes in the CPU numbers, use the maximum possible cpu number, instead of nr_cpu_ids, for configuring enqueue and dequeue limits. [ neeraj.upadhyay: Fix htmldocs build error reported by Stephen Rothwell ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50007", "url": "https://ubuntu.com/security/CVE-2024-50007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: asihpi: Fix potential OOB array access ASIHPI driver stores some values in the static array upon a response from the driver, and its index depends on the firmware. We shouldn't trust it blindly. This patch adds a sanity check of the array index to fit in the array size.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50017", "url": "https://ubuntu.com/security/CVE-2024-50017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm/ident_map: Use gbpages only where full GB page should be mapped. When ident_pud_init() uses only GB pages to create identity maps, large ranges of addresses not actually requested can be included in the resulting table; a 4K request will map a full GB. This can include a lot of extra address space past that requested, including areas marked reserved by the BIOS. That allows processor speculation into reserved regions, that on UV systems can cause system halts. Only use GB pages when map creation requests include the full GB page of space. Fall back to using smaller 2M pages when only portions of a GB page are included in the request. No attempt is made to coalesce mapping requests. If a request requires a map entry at the 2M (pmd) level, subsequent mapping requests within the same 1G region will also be at the pmd level, even if adjacent or overlapping such requests could have been combined to map a full GB page. Existing usage starts with larger regions and then adds smaller regions, so this should not have any great consequence.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49927", "url": "https://ubuntu.com/security/CVE-2024-49927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/ioapic: Handle allocation failures gracefully Breno observed panics when using failslab under certain conditions during runtime: can not alloc irq_pin_list (-1,0,20) Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed panic+0x4e9/0x590 mp_irqdomain_alloc+0x9ab/0xa80 irq_domain_alloc_irqs_locked+0x25d/0x8d0 __irq_domain_alloc_irqs+0x80/0x110 mp_map_pin_to_irq+0x645/0x890 acpi_register_gsi_ioapic+0xe6/0x150 hpet_open+0x313/0x480 That's a pointless panic which is a leftover of the historic IO/APIC code which panic'ed during early boot when the interrupt allocation failed. The only place which might justify panic is the PIT/HPET timer_check() code which tries to figure out whether the timer interrupt is delivered through the IO/APIC. But that code does not require to handle interrupt allocation failures. If the interrupt cannot be allocated then timer delivery fails and it either panics due to that or falls back to legacy mode. Cure this by removing the panic wrapper around __add_pin_to_irq_node() and making mp_irqdomain_alloc() aware of the failure condition and handle it as any other failure in this function gracefully.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50008", "url": "https://ubuntu.com/security/CVE-2024-50008", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_cmd_802_11_scan_ext() Replace one-element array with a flexible-array member in `struct host_cmd_ds_802_11_scan_ext`. With this, fix the following warning: elo 16 17:51:58 surfacebook kernel: ------------[ cut here ]------------ elo 16 17:51:58 surfacebook kernel: memcpy: detected field-spanning write (size 243) of single field \"ext_scan->tlv_buffer\" at drivers/net/wireless/marvell/mwifiex/scan.c:2239 (size 1) elo 16 17:51:58 surfacebook kernel: WARNING: CPU: 0 PID: 498 at drivers/net/wireless/marvell/mwifiex/scan.c:2239 mwifiex_cmd_802_11_scan_ext+0x83/0x90 [mwifiex]", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50018", "url": "https://ubuntu.com/security/CVE-2024-50018", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49928", "url": "https://ubuntu.com/security/CVE-2024-49928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: avoid reading out of bounds when loading TX power FW elements Because the loop-expression will do one more time before getting false from cond-expression, the original code copied one more entry size beyond valid region. Fix it by moving the entry copy to loop-body.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50178", "url": "https://ubuntu.com/security/CVE-2024-50178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: loongson3: Use raw_smp_processor_id() in do_service_request() Use raw_smp_processor_id() instead of plain smp_processor_id() in do_service_request(), otherwise we may get some errors with the driver enabled: BUG: using smp_processor_id() in preemptible [00000000] code: (udev-worker)/208 caller is loongson3_cpufreq_probe+0x5c/0x250 [loongson3_cpufreq]", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50009", "url": "https://ubuntu.com/security/CVE-2024-50009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: amd-pstate: add check for cpufreq_cpu_get's return value cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it and return in case of error. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49994", "url": "https://ubuntu.com/security/CVE-2024-49994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix integer overflow in BLKSECDISCARD I independently rediscovered \tcommit 22d24a544b0d49bbcbd61c8c0eaf77d3c9297155 \tblock: fix overflow in blk_ioctl_discard() but for secure erase. Same problem: \tuint64_t r[2] = {512, 18446744073709551104ULL}; \tioctl(fd, BLKSECDISCARD, r); will enter near infinite loop inside blkdev_issue_secure_erase(): \ta.out: attempt to access beyond end of device \tloop0: rw=5, sector=3399043073, nr_sectors = 1024 limit=2048 \tbio_check_eod: 3286214 callbacks suppressed", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49929", "url": "https://ubuntu.com/security/CVE-2024-49929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: avoid NULL pointer dereference iwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta pointer is not NULL. It retrieves this pointer using iwl_mvm_sta_from_mac80211, which is dereferencing the ieee80211_sta pointer. If sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL pointer. Fix this by checking the sta pointer before retrieving the mvmsta from it. If sta is not NULL, then mvmsta isn't either.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49995", "url": "https://ubuntu.com/security/CVE-2024-49995", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: guard against string buffer overrun Smatch reports that copying media_name and if_name to name_parts may overwrite the destination. .../bearer.c:166 bearer_name_validate() error: strcpy() 'media_name' too large for 'name_parts->media_name' (32 vs 16) .../bearer.c:167 bearer_name_validate() error: strcpy() 'if_name' too large for 'name_parts->if_name' (1010102 vs 16) This does seem to be the case so guard against this possibility by using strscpy() and failing if truncation occurs. Introduced by commit b97bf3fd8f6a (\"[TIPC] Initial merge\") Compile tested only.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49962", "url": "https://ubuntu.com/security/CVE-2024-49962", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in acpi_db_convert_to_package() ACPICA commit 4d4547cf13cca820ff7e0f859ba83e1a610b9fd0 ACPI_ALLOCATE_ZEROED() may fail, elements might be NULL and will cause NULL pointer dereference later. [ rjw: Subject and changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49930", "url": "https://ubuntu.com/security/CVE-2024-49930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix array out-of-bound access in SoC stats Currently, the ath11k_soc_dp_stats::hal_reo_error array is defined with a maximum size of DP_REO_DST_RING_MAX. However, the ath11k_dp_process_rx() function access ath11k_soc_dp_stats::hal_reo_error using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath11k_dp_process_rx() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49931", "url": "https://ubuntu.com/security/CVE-2024-49931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix array out-of-bound access in SoC stats Currently, the ath12k_soc_dp_stats::hal_reo_error array is defined with a maximum size of DP_REO_DST_RING_MAX. However, the ath12k_dp_rx_process() function access ath12k_soc_dp_stats::hal_reo_error using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath12k_dp_rx_process() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49932", "url": "https://ubuntu.com/security/CVE-2024-49932", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: don't readahead the relocation inode on RST On relocation we're doing readahead on the relocation inode, but if the filesystem is backed by a RAID stripe tree we can get ENOENT (e.g. due to preallocated extents not being mapped in the RST) from the lookup. But readahead doesn't handle the error and submits invalid reads to the device, causing an assertion in the scatter-gather list code: BTRFS info (device nvme1n1): balance: start -d -m -s BTRFS info (device nvme1n1): relocating block group 6480920576 flags data|raid0 BTRFS error (device nvme1n1): cannot find raid-stripe for logical [6481928192, 6481969152] devid 2, profile raid0 ------------[ cut here ]------------ kernel BUG at include/linux/scatterlist.h:115! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 1012 Comm: btrfs Not tainted 6.10.0-rc7+ #567 RIP: 0010:__blk_rq_map_sg+0x339/0x4a0 RSP: 0018:ffffc90001a43820 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffea00045d4802 RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000 RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000001000 R12: ffff8881003d10b8 R13: ffffc90001a438f0 R14: 0000000000000000 R15: 0000000000003000 FS: 00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000002cd11000 CR3: 00000001109ea001 CR4: 0000000000370eb0 Call Trace: ? __die_body.cold+0x14/0x25 ? die+0x2e/0x50 ? do_trap+0xca/0x110 ? do_error_trap+0x65/0x80 ? __blk_rq_map_sg+0x339/0x4a0 ? exc_invalid_op+0x50/0x70 ? __blk_rq_map_sg+0x339/0x4a0 ? asm_exc_invalid_op+0x1a/0x20 ? __blk_rq_map_sg+0x339/0x4a0 nvme_prep_rq.part.0+0x9d/0x770 nvme_queue_rq+0x7d/0x1e0 __blk_mq_issue_directly+0x2a/0x90 ? blk_mq_get_budget_and_tag+0x61/0x90 blk_mq_try_issue_list_directly+0x56/0xf0 blk_mq_flush_plug_list.part.0+0x52b/0x5d0 __blk_flush_plug+0xc6/0x110 blk_finish_plug+0x28/0x40 read_pages+0x160/0x1c0 page_cache_ra_unbounded+0x109/0x180 relocate_file_extent_cluster+0x611/0x6a0 ? btrfs_search_slot+0xba4/0xd20 ? balance_dirty_pages_ratelimited_flags+0x26/0xb00 relocate_data_extent.constprop.0+0x134/0x160 relocate_block_group+0x3f2/0x500 btrfs_relocate_block_group+0x250/0x430 btrfs_relocate_chunk+0x3f/0x130 btrfs_balance+0x71b/0xef0 ? kmalloc_trace_noprof+0x13b/0x280 btrfs_ioctl+0x2c2e/0x3030 ? kvfree_call_rcu+0x1e6/0x340 ? list_lru_add_obj+0x66/0x80 ? mntput_no_expire+0x3a/0x220 __x64_sys_ioctl+0x96/0xc0 do_syscall_64+0x54/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fcc04514f9b Code: Unable to access opcode bytes at 0x7fcc04514f71. RSP: 002b:00007ffeba923370 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fcc04514f9b RDX: 00007ffeba923460 RSI: 00000000c4009420 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000013 R09: 0000000000000001 R10: 00007fcc043fbba8 R11: 0000000000000246 R12: 00007ffeba924fc5 R13: 00007ffeba923460 R14: 0000000000000002 R15: 00000000004d4bb0 Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:__blk_rq_map_sg+0x339/0x4a0 RSP: 0018:ffffc90001a43820 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffea00045d4802 RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000 RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000001000 R12: ffff8881003d10b8 R13: ffffc90001a438f0 R14: 0000000000000000 R15: 0000000000003000 FS: 00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcc04514f71 CR3: 00000001109ea001 CR4: 0000000000370eb0 Kernel p ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49933", "url": "https://ubuntu.com/security/CVE-2024-49933", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk_iocost: fix more out of bound shifts Recently running UBSAN caught few out of bound shifts in the ioc_forgive_debts() function: UBSAN: shift-out-of-bounds in block/blk-iocost.c:2142:38 shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long long') ... UBSAN: shift-out-of-bounds in block/blk-iocost.c:2144:30 shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long long') ... Call Trace: dump_stack_lvl+0xca/0x130 __ubsan_handle_shift_out_of_bounds+0x22c/0x280 ? __lock_acquire+0x6441/0x7c10 ioc_timer_fn+0x6cec/0x7750 ? blk_iocost_init+0x720/0x720 ? call_timer_fn+0x5d/0x470 call_timer_fn+0xfa/0x470 ? blk_iocost_init+0x720/0x720 __run_timer_base+0x519/0x700 ... Actual impact of this issue was not identified but I propose to fix the undefined behaviour. The proposed fix to prevent those out of bound shifts consist of precalculating exponent before using it the shift operations by taking min value from the actual exponent and maximum possible number of bits.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49934", "url": "https://ubuntu.com/security/CVE-2024-49934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/inode: Prevent dump_mapping() accessing invalid dentry.d_name.name It's observed that a crash occurs during hot-remove a memory device, in which user is accessing the hugetlb. See calltrace as following: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 14045 at arch/x86/mm/fault.c:1278 do_user_addr_fault+0x2a0/0x790 Modules linked in: kmem device_dax cxl_mem cxl_pmem cxl_port cxl_pci dax_hmem dax_pmem nd_pmem cxl_acpi nd_btt cxl_core crc32c_intel nvme virtiofs fuse nvme_core nfit libnvdimm dm_multipath scsi_dh_rdac scsi_dh_emc s mirror dm_region_hash dm_log dm_mod CPU: 1 PID: 14045 Comm: daxctl Not tainted 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:do_user_addr_fault+0x2a0/0x790 Code: 48 8b 00 a8 04 0f 84 b5 fe ff ff e9 1c ff ff ff 4c 89 e9 4c 89 e2 be 01 00 00 00 bf 02 00 00 00 e8 b5 ef 24 00 e9 42 fe ff ff <0f> 0b 48 83 c4 08 4c 89 ea 48 89 ee 4c 89 e7 5b 5d 41 5c 41 5d 41 RSP: 0000:ffffc90000a575f0 EFLAGS: 00010046 RAX: ffff88800c303600 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000001000 RSI: ffffffff82504162 RDI: ffffffff824b2c36 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffc90000a57658 R13: 0000000000001000 R14: ffff88800bc2e040 R15: 0000000000000000 FS: 00007f51cb57d880(0000) GS:ffff88807fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000001000 CR3: 00000000072e2004 CR4: 00000000001706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn+0x8d/0x190 ? do_user_addr_fault+0x2a0/0x790 ? report_bug+0x1c3/0x1d0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? do_user_addr_fault+0x2a0/0x790 ? exc_page_fault+0x31/0x200 exc_page_fault+0x68/0x200 <...snip...> BUG: unable to handle page fault for address: 0000000000001000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI ---[ end trace 0000000000000000 ]--- BUG: unable to handle page fault for address: 0000000000001000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 14045 Comm: daxctl Kdump: loaded Tainted: G W 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:dentry_name+0x1f4/0x440 <...snip...> ? dentry_name+0x2fa/0x440 vsnprintf+0x1f3/0x4f0 vprintk_store+0x23a/0x540 vprintk_emit+0x6d/0x330 _printk+0x58/0x80 dump_mapping+0x10b/0x1a0 ? __pfx_free_object_rcu+0x10/0x10 __dump_page+0x26b/0x3e0 ? vprintk_emit+0xe0/0x330 ? _printk+0x58/0x80 ? dump_page+0x17/0x50 dump_page+0x17/0x50 do_migrate_range+0x2f7/0x7f0 ? do_migrate_range+0x42/0x7f0 ? offline_pages+0x2f4/0x8c0 offline_pages+0x60a/0x8c0 memory_subsys_offline+0x9f/0x1c0 ? lockdep_hardirqs_on+0x77/0x100 ? _raw_spin_unlock_irqrestore+0x38/0x60 device_offline+0xe3/0x110 state_store+0x6e/0xc0 kernfs_fop_write_iter+0x143/0x200 vfs_write+0x39f/0x560 ksys_write+0x65/0xf0 do_syscall_64+0x62/0x130 Previously, some sanity check have been done in dump_mapping() before the print facility parsing '%pd' though, it's still possible to run into an invalid dentry.d_name.name. Since dump_mapping() only needs to dump the filename only, retrieve it by itself in a safer way to prevent an unnecessary crash. Note that either retrieving the filename with '%pd' or strncpy_from_kernel_nofault(), the filename could be unreliable.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49935", "url": "https://ubuntu.com/security/CVE-2024-49935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: PAD: fix crash in exit_round_robin() The kernel occasionally crashes in cpumask_clear_cpu(), which is called within exit_round_robin(), because when executing clear_bit(nr, addr) with nr set to 0xffffffff, the address calculation may cause misalignment within the memory, leading to access to an invalid memory address. ---------- BUG: unable to handle kernel paging request at ffffffffe0740618 ... CPU: 3 PID: 2919323 Comm: acpi_pad/14 Kdump: loaded Tainted: G OE X --------- - - 4.18.0-425.19.2.el8_7.x86_64 #1 ... RIP: 0010:power_saving_thread+0x313/0x411 [acpi_pad] Code: 89 cd 48 89 d3 eb d1 48 c7 c7 55 70 72 c0 e8 64 86 b0 e4 c6 05 0d a1 02 00 01 e9 bc fd ff ff 45 89 e4 42 8b 04 a5 20 82 72 c0 48 0f b3 05 f4 9c 01 00 42 c7 04 a5 20 82 72 c0 ff ff ff ff 31 RSP: 0018:ff72a5d51fa77ec8 EFLAGS: 00010202 RAX: 00000000ffffffff RBX: ff462981e5d8cb80 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246 RBP: ff46297556959d80 R08: 0000000000000382 R09: ff46297c8d0f38d8 R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000000e R13: 0000000000000000 R14: ffffffffffffffff R15: 000000000000000e FS: 0000000000000000(0000) GS:ff46297a800c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffe0740618 CR3: 0000007e20410004 CR4: 0000000000771ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? acpi_pad_add+0x120/0x120 [acpi_pad] kthread+0x10b/0x130 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x1f/0x40 ... CR2: ffffffffe0740618 crash> dis -lr ffffffffc0726923 ... /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 114 0xffffffffc0726918 :\tmov %r12d,%r12d /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 325 0xffffffffc072691b :\tmov -0x3f8d7de0(,%r12,4),%eax /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./arch/x86/include/asm/bitops.h: 80 0xffffffffc0726923 :\tlock btr %rax,0x19cf4(%rip) # 0xffffffffc0740620 crash> px tsk_in_cpu[14] $66 = 0xffffffff crash> px 0xffffffffc072692c+0x19cf4 $99 = 0xffffffffc0740620 crash> sym 0xffffffffc0740620 ffffffffc0740620 (b) pad_busy_cpus_bits [acpi_pad] crash> px pad_busy_cpus_bits[0] $42 = 0xfffc0 ---------- To fix this, ensure that tsk_in_cpu[tsk_index] != -1 before calling cpumask_clear_cpu() in exit_round_robin(), just as it is done in round_robin_cpu(). [ rjw: Subject edit, avoid updates to the same value ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49936", "url": "https://ubuntu.com/security/CVE-2024-49936", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/xen-netback: prevent UAF in xenvif_flush_hash() During the list_for_each_entry_rcu iteration call of xenvif_flush_hash, kfree_rcu does not exist inside the rcu read critical section, so if kfree_rcu is called when the rcu grace period ends during the iteration, UAF occurs when accessing head->next after the entry becomes free. Therefore, to solve this, you need to change it to list_for_each_entry_safe.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49937", "url": "https://ubuntu.com/security/CVE-2024-49937", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Set correct chandef when starting CAC When starting CAC in a mode other than AP mode, it return a \"WARNING: CPU: 0 PID: 63 at cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]\" caused by the chandef.chan being null at the end of CAC. Solution: Ensure the channel definition is set for the different modes when starting CAC to avoid getting a NULL 'chan' at the end of CAC. Call Trace: ? show_regs.part.0+0x14/0x16 ? __warn+0x67/0xc0 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? report_bug+0xa7/0x130 ? exc_overflow+0x30/0x30 ? handle_bug+0x27/0x50 ? exc_invalid_op+0x18/0x60 ? handle_exception+0xf6/0xf6 ? exc_overflow+0x30/0x30 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? exc_overflow+0x30/0x30 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? regulatory_propagate_dfs_state.cold+0x1b/0x4c [cfg80211] ? cfg80211_propagate_cac_done_wk+0x1a/0x30 [cfg80211] ? process_one_work+0x165/0x280 ? worker_thread+0x120/0x3f0 ? kthread+0xc2/0xf0 ? process_one_work+0x280/0x280 ? kthread_complete_and_exit+0x20/0x20 ? ret_from_fork+0x19/0x24 [shorten subject, remove OCB, reorder cases to match previous list]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49938", "url": "https://ubuntu.com/security/CVE-2024-49938", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmit Syzbot points out that skb_trim() has a sanity check on the existing length of the skb, which can be uninitialised in some error paths. The intent here is clearly just to reset the length to zero before resubmitting, so switch to calling __skb_set_length(skb, 0) directly. In addition, __skb_set_length() already contains a call to skb_reset_tail_pointer(), so remove the redundant call. The syzbot report came from ath9k_hif_usb_reg_in_cb(), but there's a similar usage of skb_trim() in ath9k_hif_usb_rx_cb(), change both while we're at it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49939", "url": "https://ubuntu.com/security/CVE-2024-49939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: avoid to add interface to list twice when SER If SER L2 occurs during the WoWLAN resume flow, the add interface flow is triggered by ieee80211_reconfig(). However, due to rtw89_wow_resume() return failure, it will cause the add interface flow to be executed again, resulting in a double add list and causing a kernel panic. Therefore, we have added a check to prevent double adding of the list. list_add double add: new=ffff99d6992e2010, prev=ffff99d6992e2010, next=ffff99d695302628. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:37! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G W O 6.6.30-02659-gc18865c4dfbd #1 770df2933251a0e3c888ba69d1053a817a6376a7 Hardware name: HP Grunt/Grunt, BIOS Google_Grunt.11031.169.0 06/24/2021 Workqueue: events_freezable ieee80211_restart_work [mac80211] RIP: 0010:__list_add_valid_or_report+0x5e/0xb0 Code: c7 74 18 48 39 ce 74 13 b0 01 59 5a 5e 5f 41 58 41 59 41 5a 5d e9 e2 d6 03 00 cc 48 c7 c7 8d 4f 17 83 48 89 c2 e8 02 c0 00 00 <0f> 0b 48 c7 c7 aa 8c 1c 83 e8 f4 bf 00 00 0f 0b 48 c7 c7 c8 bc 12 RSP: 0018:ffffa91b8007bc50 EFLAGS: 00010246 RAX: 0000000000000058 RBX: ffff99d6992e0900 RCX: a014d76c70ef3900 RDX: ffffa91b8007bae8 RSI: 00000000ffffdfff RDI: 0000000000000001 RBP: ffffa91b8007bc88 R08: 0000000000000000 R09: ffffa91b8007bae0 R10: 00000000ffffdfff R11: ffffffff83a79800 R12: ffff99d695302060 R13: ffff99d695300900 R14: ffff99d6992e1be0 R15: ffff99d6992e2010 FS: 0000000000000000(0000) GS:ffff99d6aac00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000078fbdba43480 CR3: 000000010e464000 CR4: 00000000001506f0 Call Trace: ? __die_body+0x1f/0x70 ? die+0x3d/0x60 ? do_trap+0xa4/0x110 ? __list_add_valid_or_report+0x5e/0xb0 ? do_error_trap+0x6d/0x90 ? __list_add_valid_or_report+0x5e/0xb0 ? handle_invalid_op+0x30/0x40 ? __list_add_valid_or_report+0x5e/0xb0 ? exc_invalid_op+0x3c/0x50 ? asm_exc_invalid_op+0x16/0x20 ? __list_add_valid_or_report+0x5e/0xb0 rtw89_ops_add_interface+0x309/0x310 [rtw89_core 7c32b1ee6854761c0321027c8a58c5160e41f48f] drv_add_interface+0x5c/0x130 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ieee80211_reconfig+0x241/0x13d0 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ? finish_wait+0x3e/0x90 ? synchronize_rcu_expedited+0x174/0x260 ? sync_rcu_exp_done_unlocked+0x50/0x50 ? wake_bit_function+0x40/0x40 ieee80211_restart_work+0xf0/0x140 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] process_scheduled_works+0x1e5/0x480 worker_thread+0xea/0x1e0 kthread+0xdb/0x110 ? move_linked_works+0x90/0x90 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork+0x3b/0x50 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork_asm+0x11/0x20 Modules linked in: dm_integrity async_xor xor async_tx lz4 lz4_compress zstd zstd_compress zram zsmalloc rfcomm cmac uinput algif_hash algif_skcipher af_alg btusb btrtl iio_trig_hrtimer industrialio_sw_trigger btmtk industrialio_configfs btbcm btintel uvcvideo videobuf2_vmalloc iio_trig_sysfs videobuf2_memops videobuf2_v4l2 videobuf2_common uvc snd_hda_codec_hdmi veth snd_hda_intel snd_intel_dspcfg acpi_als snd_hda_codec industrialio_triggered_buffer kfifo_buf snd_hwdep industrialio i2c_piix4 snd_hda_core designware_i2s ip6table_nat snd_soc_max98357a xt_MASQUERADE xt_cgroup snd_soc_acp_rt5682_mach fuse rtw89_8922ae(O) rtw89_8922a(O) rtw89_pci(O) rtw89_core(O) 8021q mac80211(O) bluetooth ecdh_generic ecc cfg80211 r8152 mii joydev gsmi: Log Shutdown Reason 0x03 ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49940", "url": "https://ubuntu.com/security/CVE-2024-49940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: prevent possible tunnel refcount underflow When a session is created, it sets a backpointer to its tunnel. When the session refcount drops to 0, l2tp_session_free drops the tunnel refcount if session->tunnel is non-NULL. However, session->tunnel is set in l2tp_session_create, before the tunnel refcount is incremented by l2tp_session_register, which leaves a small window where session->tunnel is non-NULL when the tunnel refcount hasn't been bumped. Moving the assignment to l2tp_session_register is trivial but l2tp_session_create calls l2tp_session_set_header_len which uses session->tunnel to get the tunnel's encap. Add an encap arg to l2tp_session_set_header_len to avoid using session->tunnel. If l2tpv3 sessions have colliding IDs, it is possible for l2tp_v3_session_get to race with l2tp_session_register and fetch a session which doesn't yet have session->tunnel set. Add a check for this case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49941", "url": "https://ubuntu.com/security/CVE-2024-49941", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpiolib: Fix potential NULL pointer dereference in gpiod_get_label() In `gpiod_get_label()`, it is possible that `srcu_dereference_check()` may return a NULL pointer, leading to a scenario where `label->str` is accessed without verifying if `label` itself is NULL. This patch adds a proper NULL check for `label` before accessing `label->str`. The check for `label->str != NULL` is removed because `label->str` can never be NULL if `label` is not NULL. This fixes the issue where the label name was being printed as `(efault)` when dumping the sysfs GPIO file when `label == NULL`.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49996", "url": "https://ubuntu.com/security/CVE-2024-49996", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: Fix buffer overflow when parsing NFS reparse points ReparseDataLength is sum of the InodeType size and DataBuffer size. So to get DataBuffer size it is needed to subtract InodeType's size from ReparseDataLength. Function cifs_strndup_from_utf16() is currentlly accessing buf->DataBuffer at position after the end of the buffer because it does not subtract InodeType size from the length. Fix this problem and correctly subtract variable len. Member InodeType is present only when reparse buffer is large enough. Check for ReparseDataLength before accessing InodeType to prevent another invalid memory access. Major and minor rdev values are present also only when reparse buffer is large enough. Check for reparse buffer size before calling reparse_mkdev().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49942", "url": "https://ubuntu.com/security/CVE-2024-49942", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Prevent null pointer access in xe_migrate_copy xe_migrate_copy designed to copy content of TTM resources. When source resource is null, it will trigger a NULL pointer dereference in xe_migrate_copy. To avoid this situation, update lacks source flag to true for this case, the flag will trigger xe_migrate_clear rather than xe_migrate_copy. Issue trace: <7> [317.089847] xe 0000:00:02.0: [drm:xe_migrate_copy [xe]] Pass 14, sizes: 4194304 & 4194304 <7> [317.089945] xe 0000:00:02.0: [drm:xe_migrate_copy [xe]] Pass 15, sizes: 4194304 & 4194304 <1> [317.128055] BUG: kernel NULL pointer dereference, address: 0000000000000010 <1> [317.128064] #PF: supervisor read access in kernel mode <1> [317.128066] #PF: error_code(0x0000) - not-present page <6> [317.128069] PGD 0 P4D 0 <4> [317.128071] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI <4> [317.128074] CPU: 1 UID: 0 PID: 1440 Comm: kunit_try_catch Tainted: G U N 6.11.0-rc7-xe #1 <4> [317.128078] Tainted: [U]=USER, [N]=TEST <4> [317.128080] Hardware name: Intel Corporation Lunar Lake Client Platform/LNL-M LP5 RVP1, BIOS LNLMFWI1.R00.3221.D80.2407291239 07/29/2024 <4> [317.128082] RIP: 0010:xe_migrate_copy+0x66/0x13e0 [xe] <4> [317.128158] Code: 00 00 48 89 8d e0 fe ff ff 48 8b 40 10 4c 89 85 c8 fe ff ff 44 88 8d bd fe ff ff 65 48 8b 3c 25 28 00 00 00 48 89 7d d0 31 ff <8b> 79 10 48 89 85 a0 fe ff ff 48 8b 00 48 89 b5 d8 fe ff ff 83 ff <4> [317.128162] RSP: 0018:ffffc9000167f9f0 EFLAGS: 00010246 <4> [317.128164] RAX: ffff8881120d8028 RBX: ffff88814d070428 RCX: 0000000000000000 <4> [317.128166] RDX: ffff88813cb99c00 RSI: 0000000004000000 RDI: 0000000000000000 <4> [317.128168] RBP: ffffc9000167fbb8 R08: ffff88814e7b1f08 R09: 0000000000000001 <4> [317.128170] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88814e7b1f08 <4> [317.128172] R13: ffff88814e7b1f08 R14: ffff88813cb99c00 R15: 0000000000000001 <4> [317.128174] FS: 0000000000000000(0000) GS:ffff88846f280000(0000) knlGS:0000000000000000 <4> [317.128176] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [317.128178] CR2: 0000000000000010 CR3: 000000011f676004 CR4: 0000000000770ef0 <4> [317.128180] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 <4> [317.128182] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400 <4> [317.128184] PKRU: 55555554 <4> [317.128185] Call Trace: <4> [317.128187] <4> [317.128189] ? show_regs+0x67/0x70 <4> [317.128194] ? __die_body+0x20/0x70 <4> [317.128196] ? __die+0x2b/0x40 <4> [317.128198] ? page_fault_oops+0x15f/0x4e0 <4> [317.128203] ? do_user_addr_fault+0x3fb/0x970 <4> [317.128205] ? lock_acquire+0xc7/0x2e0 <4> [317.128209] ? exc_page_fault+0x87/0x2b0 <4> [317.128212] ? asm_exc_page_fault+0x27/0x30 <4> [317.128216] ? xe_migrate_copy+0x66/0x13e0 [xe] <4> [317.128263] ? __lock_acquire+0xb9d/0x26f0 <4> [317.128265] ? __lock_acquire+0xb9d/0x26f0 <4> [317.128267] ? sg_free_append_table+0x20/0x80 <4> [317.128271] ? lock_acquire+0xc7/0x2e0 <4> [317.128273] ? mark_held_locks+0x4d/0x80 <4> [317.128275] ? trace_hardirqs_on+0x1e/0xd0 <4> [317.128278] ? _raw_spin_unlock_irqrestore+0x31/0x60 <4> [317.128281] ? __pm_runtime_resume+0x60/0xa0 <4> [317.128284] xe_bo_move+0x682/0xc50 [xe] <4> [317.128315] ? lock_is_held_type+0xaa/0x120 <4> [317.128318] ttm_bo_handle_move_mem+0xe5/0x1a0 [ttm] <4> [317.128324] ttm_bo_validate+0xd1/0x1a0 [ttm] <4> [317.128328] shrink_test_run_device+0x721/0xc10 [xe] <4> [317.128360] ? find_held_lock+0x31/0x90 <4> [317.128363] ? lock_release+0xd1/0x2a0 <4> [317.128365] ? __pfx_kunit_generic_run_threadfn_adapter+0x10/0x10 [kunit] <4> [317.128370] xe_bo_shrink_kunit+0x11/0x20 [xe] <4> [317.128397] kunit_try_run_case+0x6e/0x150 [kunit] <4> [317.128400] ? trace_hardirqs_on+0x1e/0xd0 <4> [317.128402] ? _raw_spin_unlock_irqrestore+0x31/0x60 <4> [317.128404] kunit_generic_run_threadfn_adapter+0x1e/0x40 [ku ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49943", "url": "https://ubuntu.com/security/CVE-2024-49943", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc_submit: add missing locking in wedged_fini Any non-wedged queue can have a zero refcount here and can be running concurrently with an async queue destroy, therefore dereferencing the queue ptr to check wedge status after the lookup can trigger UAF if queue is not wedged. Fix this by keeping the submission_state lock held around the check to postpone the free and make the check safe, before dropping again around the put() to avoid the deadlock. (cherry picked from commit d28af0b6b9580b9f90c265a7da0315b0ad20bbfd)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50011", "url": "https://ubuntu.com/security/CVE-2024-50011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: soc-acpi-intel-rpl-match: add missing empty item There is no links_num in struct snd_soc_acpi_mach {}, and we test !link->num_adr as a condition to end the loop in hda_sdw_machine_select(). So an empty item in struct snd_soc_acpi_link_adr array is required.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50174", "url": "https://ubuntu.com/security/CVE-2024-50174", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix race when converting group handle to group object XArray provides it's own internal lock which protects the internal array when entries are being simultaneously added and removed. However there is still a race between retrieving the pointer from the XArray and incrementing the reference count. To avoid this race simply hold the internal XArray lock when incrementing the reference count, this ensures there cannot be a racing call to xa_erase().", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49944", "url": "https://ubuntu.com/security/CVE-2024-49944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_start In sctp_listen_start() invoked by sctp_inet_listen(), it should set the sk_state back to CLOSED if sctp_autobind() fails due to whatever reason. Otherwise, next time when calling sctp_inet_listen(), if sctp_sk(sk)->reuse is already set via setsockopt(SCTP_REUSE_PORT), sctp_sk(sk)->bind_hash will be dereferenced as sk_state is LISTENING, which causes a crash as bind_hash is NULL. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:sctp_inet_listen+0x7f0/0xa20 net/sctp/socket.c:8617 Call Trace: __sys_listen_socket net/socket.c:1883 [inline] __sys_listen+0x1b7/0x230 net/socket.c:1894 __do_sys_listen net/socket.c:1902 [inline]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49945", "url": "https://ubuntu.com/security/CVE-2024-49945", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/ncsi: Disable the ncsi work before freeing the associated structure The work function can run after the ncsi device is freed, resulting in use-after-free bugs or kernel panic.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49946", "url": "https://ubuntu.com/security/CVE-2024-49946", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: do not assume bh is held in ppp_channel_bridge_input() Networking receive path is usually handled from BH handler. However, some protocols need to acquire the socket lock, and packets might be stored in the socket backlog is the socket was owned by a user process. In this case, release_sock(), __release_sock(), and sk_backlog_rcv() might call the sk->sk_backlog_rcv() handler in process context. sybot caught ppp was not considering this case in ppp_channel_bridge_input() : WARNING: inconsistent lock state 6.11.0-rc7-syzkaller-g5f5673607153 #0 Not tainted -------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. ksoftirqd/1/24 [HC0[0]:SC1[1]:HE1:SE0] takes: ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 {SOFTIRQ-ON-W} state was registered at: lock_acquire+0x240/0x728 kernel/locking/lockdep.c:5759 __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline] _raw_spin_lock+0x48/0x60 kernel/locking/spinlock.c:154 spin_lock include/linux/spinlock.h:351 [inline] ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline] ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0xfc/0x314 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv include/net/sock.h:1111 [inline] __release_sock+0x1a8/0x3d8 net/core/sock.c:3004 release_sock+0x68/0x1b8 net/core/sock.c:3558 pppoe_sendmsg+0xc8/0x5d8 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x374/0x4f4 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __arm64_sys_sendto+0xd8/0xf8 net/socket.c:2212 __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:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 irq event stamp: 282914 hardirqs last enabled at (282914): [] __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:151 [inline] hardirqs last enabled at (282914): [] _raw_spin_unlock_irqrestore+0x38/0x98 kernel/locking/spinlock.c:194 hardirqs last disabled at (282913): [] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline] hardirqs last disabled at (282913): [] _raw_spin_lock_irqsave+0x2c/0x7c kernel/locking/spinlock.c:162 softirqs last enabled at (282904): [] softirq_handle_end kernel/softirq.c:400 [inline] softirqs last enabled at (282904): [] handle_softirqs+0xa3c/0xbfc kernel/softirq.c:582 softirqs last disabled at (282909): [] run_ksoftirqd+0x70/0x158 kernel/softirq.c:928 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&pch->downl); lock(&pch->downl); *** DEADLOCK *** 1 lock held by ksoftirqd/1/24: #0: ffff80008f74dfa0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire+0x10/0x4c include/linux/rcupdate.h:325 stack backtrace: CPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 6.11.0-rc7-syzkaller-g5f5673607153 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call trace: dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:319 show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:326 __dump_sta ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49947", "url": "https://ubuntu.com/security/CVE-2024-49947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: test for not too small csum_start in virtio_net_hdr_to_skb() syzbot was able to trigger this warning [1], after injecting a malicious packet through af_packet, setting skb->csum_start and thus the transport header to an incorrect value. We can at least make sure the transport header is after the end of the network header (with a estimated minimal size). [1] [ 67.873027] skb len=4096 headroom=16 headlen=14 tailroom=0 mac=(-1,-1) mac_len=0 net=(16,-6) trans=10 shinfo(txflags=0 nr_frags=1 gso(size=0 type=0 segs=0)) csum(0xa start=10 offset=0 ip_summed=3 complete_sw=0 valid=0 level=0) hash(0x0 sw=0 l4=0) proto=0x0800 pkttype=0 iif=0 priority=0x0 mark=0x0 alloc_cpu=10 vlan_all=0x0 encapsulation=0 inner(proto=0x0000, mac=0, net=0, trans=0) [ 67.877172] dev name=veth0_vlan feat=0x000061164fdd09e9 [ 67.877764] sk family=17 type=3 proto=0 [ 67.878279] skb linear: 00000000: 00 00 10 00 00 00 00 00 0f 00 00 00 08 00 [ 67.879128] skb frag: 00000000: 0e 00 07 00 00 00 28 00 08 80 1c 00 04 00 00 02 [ 67.879877] skb frag: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.880647] skb frag: 00000020: 00 00 02 00 00 00 08 00 1b 00 00 00 00 00 00 00 [ 67.881156] skb frag: 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.881753] skb frag: 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.882173] skb frag: 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.882790] skb frag: 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.883171] skb frag: 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.883733] skb frag: 00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.884206] skb frag: 00000090: 00 00 00 00 00 00 00 00 00 00 69 70 76 6c 61 6e [ 67.884704] skb frag: 000000a0: 31 00 00 00 00 00 00 00 00 00 2b 00 00 00 00 00 [ 67.885139] skb frag: 000000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.885677] skb frag: 000000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.886042] skb frag: 000000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.886408] skb frag: 000000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.887020] skb frag: 000000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.887384] skb frag: 00000100: 00 00 [ 67.887878] ------------[ cut here ]------------ [ 67.887908] offset (-6) >= skb_headlen() (14) [ 67.888445] WARNING: CPU: 10 PID: 2088 at net/core/dev.c:3332 skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.889353] Modules linked in: macsec macvtap macvlan hsr wireguard curve25519_x86_64 libcurve25519_generic libchacha20poly1305 chacha_x86_64 libchacha poly1305_x86_64 dummy bridge sr_mod cdrom evdev pcspkr i2c_piix4 9pnet_virtio 9p 9pnet netfs [ 67.890111] CPU: 10 UID: 0 PID: 2088 Comm: b363492833 Not tainted 6.11.0-virtme #1011 [ 67.890183] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 67.890309] RIP: 0010:skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891043] Call Trace: [ 67.891173] [ 67.891274] ? __warn (kernel/panic.c:741) [ 67.891320] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891333] ? report_bug (lib/bug.c:180 lib/bug.c:219) [ 67.891348] ? handle_bug (arch/x86/kernel/traps.c:239) [ 67.891363] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) [ 67.891372] ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621) [ 67.891388] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891399] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891416] ip_do_fragment (net/ipv4/ip_output.c:777 (discriminator 1)) [ 67.891448] ? __ip_local_out (./include/linux/skbuff.h:1146 ./include/net/l3mdev.h:196 ./include/net/l3mdev.h:213 ne ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49948", "url": "https://ubuntu.com/security/CVE-2024-49948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: add more sanity checks to qdisc_pkt_len_init() One path takes care of SKB_GSO_DODGY, assuming skb->len is bigger than hdr_len. virtio_net_hdr_to_skb() does not fully dissect TCP headers, it only make sure it is at least 20 bytes. It is possible for an user to provide a malicious 'GSO' packet, total length of 80 bytes. - 20 bytes of IPv4 header - 60 bytes TCP header - a small gso_size like 8 virtio_net_hdr_to_skb() would declare this packet as a normal GSO packet, because it would see 40 bytes of payload, bigger than gso_size. We need to make detect this case to not underflow qdisc_skb_cb(skb)->pkt_len.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49949", "url": "https://ubuntu.com/security/CVE-2024-49949", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: avoid potential underflow in qdisc_pkt_len_init() with UFO After commit 7c6d2ecbda83 (\"net: be more gentle about silly gso requests coming from user\") virtio_net_hdr_to_skb() had sanity check to detect malicious attempts from user space to cook a bad GSO packet. Then commit cf9acc90c80ec (\"net: virtio_net_hdr_to_skb: count transport header in UFO\") while fixing one issue, allowed user space to cook a GSO packet with the following characteristic : IPv4 SKB_GSO_UDP, gso_size=3, skb->len = 28. When this packet arrives in qdisc_pkt_len_init(), we end up with hdr_len = 28 (IPv4 header + UDP header), matching skb->len Then the following sets gso_segs to 0 : gso_segs = DIV_ROUND_UP(skb->len - hdr_len, shinfo->gso_size); Then later we set qdisc_skb_cb(skb)->pkt_len to back to zero :/ qdisc_skb_cb(skb)->pkt_len += (gso_segs - 1) * hdr_len; This leads to the following crash in fq_codel [1] qdisc_pkt_len_init() is best effort, we only want an estimation of the bytes sent on the wire, not crashing the kernel. This patch is fixing this particular issue, a following one adds more sanity checks for another potential bug. [1] [ 70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 70.724561] #PF: supervisor read access in kernel mode [ 70.724561] #PF: error_code(0x0000) - not-present page [ 70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0 [ 70.724561] Oops: Oops: 0000 [#1] SMP NOPTI [ 70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991 [ 70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel [ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 <49> 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49 All code ======== 0:\t24 08 \tand $0x8,%al 2:\t49 c1 e1 06 \tshl $0x6,%r9 6:\t44 89 7c 24 18 \tmov %r15d,0x18(%rsp) b:\t45 31 ed \txor %r13d,%r13d e:\t45 31 c0 \txor %r8d,%r8d 11:\t31 ff \txor %edi,%edi 13:\t89 44 24 14 \tmov %eax,0x14(%rsp) 17:\t4c 03 8b 90 01 00 00 \tadd 0x190(%rbx),%r9 1e:\teb 04 \tjmp 0x24 20:\t39 ca \tcmp %ecx,%edx 22:\t73 37 \tjae 0x5b 24:\t4d 8b 39 \tmov (%r9),%r15 27:\t83 c7 01 \tadd $0x1,%edi 2a:*\t49 8b 17 \tmov (%r15),%rdx\t\t<-- trapping instruction 2d:\t49 89 11 \tmov %rdx,(%r9) 30:\t41 8b 57 28 \tmov 0x28(%r15),%edx 34:\t45 8b 5f 34 \tmov 0x34(%r15),%r11d 38:\t49 c7 07 00 00 00 00 \tmovq $0x0,(%r15) 3f:\t49 \trex.WB Code starting with the faulting instruction =========================================== 0:\t49 8b 17 \tmov (%r15),%rdx 3:\t49 89 11 \tmov %rdx,(%r9) 6:\t41 8b 57 28 \tmov 0x28(%r15),%edx a:\t45 8b 5f 34 \tmov 0x34(%r15),%r11d e:\t49 c7 07 00 00 00 00 \tmovq $0x0,(%r15) 15:\t49 \trex.WB [ 70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202 [ 70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000 [ 70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001 [ 70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000 [ 70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58 [ 70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000 [ 70.724561] FS: 000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000 [ 70.724561] CS: 0010 DS: 0000 ES: 0000 C ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49997", "url": "https://ubuntu.com/security/CVE-2024-49997", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: lantiq_etop: fix memory disclosure When applying padding, the buffer is not zeroed, which results in memory disclosure. The mentioned data is observed on the wire. This patch uses skb_put_padto() to pad Ethernet frames properly. The mentioned function zeroes the expanded buffer. In case the packet cannot be padded it is silently dropped. Statistics are also not incremented. This driver does not support statistics in the old 32-bit format or the new 64-bit format. These will be added in the future. In its current form, the patch should be easily backported to stable versions. Ethernet MACs on Amazon-SE and Danube cannot do padding of the packets in hardware, so software padding must be applied.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49998", "url": "https://ubuntu.com/security/CVE-2024-49998", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: improve shutdown sequence Alexander Sverdlin presents 2 problems during shutdown with the lan9303 driver. One is specific to lan9303 and the other just happens to reproduce there. The first problem is that lan9303 is unique among DSA drivers in that it calls dev_get_drvdata() at \"arbitrary runtime\" (not probe, not shutdown, not remove): phy_state_machine() -> ... -> dsa_user_phy_read() -> ds->ops->phy_read() -> lan9303_phy_read() -> chip->ops->phy_read() -> lan9303_mdio_phy_read() -> dev_get_drvdata() But we never stop the phy_state_machine(), so it may continue to run after dsa_switch_shutdown(). Our common pattern in all DSA drivers is to set drvdata to NULL to suppress the remove() method that may come afterwards. But in this case it will result in an NPD. The second problem is that the way in which we set dp->conduit->dsa_ptr = NULL; is concurrent with receive packet processing. dsa_switch_rcv() checks once whether dev->dsa_ptr is NULL, but afterwards, rather than continuing to use that non-NULL value, dev->dsa_ptr is dereferenced again and again without NULL checks: dsa_conduit_find_user() and many other places. In between dereferences, there is no locking to ensure that what was valid once continues to be valid. Both problems have the common aspect that closing the conduit interface solves them. In the first case, dev_close(conduit) triggers the NETDEV_GOING_DOWN event in dsa_user_netdevice_event() which closes user ports as well. dsa_port_disable_rt() calls phylink_stop(), which synchronously stops the phylink state machine, and ds->ops->phy_read() will thus no longer call into the driver after this point. In the second case, dev_close(conduit) should do this, as per Documentation/networking/driver.rst: | Quiescence | ---------- | | After the ndo_stop routine has been called, the hardware must | not receive or transmit any data. All in flight packets must | be aborted. If necessary, poll or wait for completion of | any reset commands. So it should be sufficient to ensure that later, when we zeroize conduit->dsa_ptr, there will be no concurrent dsa_switch_rcv() call on this conduit. The addition of the netif_device_detach() function is to ensure that ioctls, rtnetlinks and ethtool requests on the user ports no longer propagate down to the driver - we're no longer prepared to handle them. The race condition actually did not exist when commit 0650bf52b31f (\"net: dsa: be compatible with masters which unregister on shutdown\") first introduced dsa_switch_shutdown(). It was created later, when we stopped unregistering the user interfaces from a bad spot, and we just replaced that sequence with a racy zeroization of conduit->dsa_ptr (one which doesn't ensure that the interfaces aren't up).", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49999", "url": "https://ubuntu.com/security/CVE-2024-49999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix the setting of the server responding flag In afs_wait_for_operation(), we set transcribe the call responded flag to the server record that we used after doing the fileserver iteration loop - but it's possible to exit the loop having had a response from the server that we've discarded (e.g. it returned an abort or we started receiving data, but the call didn't complete). This means that op->server might be NULL, but we don't check that before attempting to set the server flag.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49950", "url": "https://ubuntu.com/security/CVE-2024-49950", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix uaf in l2cap_connect [Syzbot reported] BUG: KASAN: slab-use-after-free in l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 Read of size 8 at addr ffff8880241e9800 by task kworker/u9:0/54 CPU: 0 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-00268-g788220eee30d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Workqueue: hci2 hci_rx_work Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 l2cap_connect_req net/bluetooth/l2cap_core.c:4080 [inline] l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:4772 [inline] l2cap_sig_channel net/bluetooth/l2cap_core.c:5543 [inline] l2cap_recv_frame+0xf0b/0x8eb0 net/bluetooth/l2cap_core.c:6825 l2cap_recv_acldata+0x9b4/0xb70 net/bluetooth/l2cap_core.c:7514 hci_acldata_packet net/bluetooth/hci_core.c:3791 [inline] hci_rx_work+0xaab/0x1610 net/bluetooth/hci_core.c:4028 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 ... Freed by task 5245: 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:579 poison_slab_object+0xf7/0x160 mm/kasan/common.c:240 __kasan_slab_free+0x32/0x50 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2256 [inline] slab_free mm/slub.c:4477 [inline] kfree+0x12a/0x3b0 mm/slub.c:4598 l2cap_conn_free net/bluetooth/l2cap_core.c:1810 [inline] kref_put include/linux/kref.h:65 [inline] l2cap_conn_put net/bluetooth/l2cap_core.c:1822 [inline] l2cap_conn_del+0x59d/0x730 net/bluetooth/l2cap_core.c:1802 l2cap_connect_cfm+0x9e6/0xf80 net/bluetooth/l2cap_core.c:7241 hci_connect_cfm include/net/bluetooth/hci_core.h:1960 [inline] hci_conn_failed+0x1c3/0x370 net/bluetooth/hci_conn.c:1265 hci_abort_conn_sync+0x75a/0xb50 net/bluetooth/hci_sync.c:5583 abort_conn_sync+0x197/0x360 net/bluetooth/hci_conn.c:2917 hci_cmd_sync_work+0x1a4/0x410 net/bluetooth/hci_sync.c:328 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49951", "url": "https://ubuntu.com/security/CVE-2024-49951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Fix possible crash on mgmt_index_removed If mgmt_index_removed is called while there are commands queued on cmd_sync it could lead to crashes like the bellow trace: 0x0000053D: __list_del_entry_valid_or_report+0x98/0xdc 0x0000053D: mgmt_pending_remove+0x18/0x58 [bluetooth] 0x0000053E: mgmt_remove_adv_monitor_complete+0x80/0x108 [bluetooth] 0x0000053E: hci_cmd_sync_work+0xbc/0x164 [bluetooth] So while handling mgmt_index_removed this attempts to dequeue commands passed as user_data to cmd_sync.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49952", "url": "https://ubuntu.com/security/CVE-2024-49952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: prevent nf_skb_duplicated corruption syzbot found that nf_dup_ipv4() or nf_dup_ipv6() could write per-cpu variable nf_skb_duplicated in an unsafe way [1]. Disabling preemption as hinted by the splat is not enough, we have to disable soft interrupts as well. [1] BUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316 caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49 nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook+0x2c4/0x450 include/linux/netfilter.h:269 NF_HOOK_COND include/linux/netfilter.h:302 [inline] ip_output+0x185/0x230 net/ipv4/ip_output.c:433 ip_local_out net/ipv4/ip_output.c:129 [inline] ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495 udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981 udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737 __do_sys_sendmmsg net/socket.c:2766 [inline] __se_sys_sendmmsg net/socket.c:2763 [inline] __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763 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:0x7f4ce4f7def9 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:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9 RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006 RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49953", "url": "https://ubuntu.com/security/CVE-2024-49953", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix crash caused by calling __xfrm_state_delete() twice The km.state is not checked in driver's delayed work. When xfrm_state_check_expire() is called, the state can be reset to XFRM_STATE_EXPIRED, even if it is XFRM_STATE_DEAD already. This happens when xfrm state is deleted, but not freed yet. As __xfrm_state_delete() is called again in xfrm timer, the following crash occurs. To fix this issue, skip xfrm_state_check_expire() if km.state is not XFRM_STATE_VALID. Oops: general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] SMP CPU: 5 UID: 0 PID: 7448 Comm: kworker/u102:2 Not tainted 6.11.0-rc2+ #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5e_ipsec: eth%d mlx5e_ipsec_handle_sw_limits [mlx5_core] RIP: 0010:__xfrm_state_delete+0x3d/0x1b0 Code: 0f 84 8b 01 00 00 48 89 fd c6 87 c8 00 00 00 05 48 8d bb 40 10 00 00 e8 11 04 1a 00 48 8b 95 b8 00 00 00 48 8b 85 c0 00 00 00 <48> 89 42 08 48 89 10 48 8b 55 10 48 b8 00 01 00 00 00 00 ad de 48 RSP: 0018:ffff88885f945ec8 EFLAGS: 00010246 RAX: dead000000000122 RBX: ffffffff82afa940 RCX: 0000000000000036 RDX: dead000000000100 RSI: 0000000000000000 RDI: ffffffff82afb980 RBP: ffff888109a20340 R08: ffff88885f945ea0 R09: 0000000000000000 R10: 0000000000000000 R11: ffff88885f945ff8 R12: 0000000000000246 R13: ffff888109a20340 R14: ffff88885f95f420 R15: ffff88885f95f400 FS: 0000000000000000(0000) GS:ffff88885f940000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2163102430 CR3: 00000001128d6001 CR4: 0000000000370eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? die_addr+0x33/0x90 ? exc_general_protection+0x1a2/0x390 ? asm_exc_general_protection+0x22/0x30 ? __xfrm_state_delete+0x3d/0x1b0 ? __xfrm_state_delete+0x2f/0x1b0 xfrm_timer_handler+0x174/0x350 ? __xfrm_state_delete+0x1b0/0x1b0 __hrtimer_run_queues+0x121/0x270 hrtimer_run_softirq+0x88/0xd0 handle_softirqs+0xcc/0x270 do_softirq+0x3c/0x50 __local_bh_enable_ip+0x47/0x50 mlx5e_ipsec_handle_sw_limits+0x7d/0x90 [mlx5_core] process_one_work+0x137/0x2d0 worker_thread+0x28d/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50000", "url": "https://ubuntu.com/security/CVE-2024-50000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix NULL deref in mlx5e_tir_builder_alloc() In mlx5e_tir_builder_alloc() kvzalloc() may return NULL which is dereferenced on the next line in a reference to the modify field. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50001", "url": "https://ubuntu.com/security/CVE-2024-50001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix error path in multi-packet WQE transmit Remove the erroneous unmap in case no DMA mapping was established The multi-packet WQE transmit code attempts to obtain a DMA mapping for the skb. This could fail, e.g. under memory pressure, when the IOMMU driver just can't allocate more memory for page tables. While the code tries to handle this in the path below the err_unmap label it erroneously unmaps one entry from the sq's FIFO list of active mappings. Since the current map attempt failed this unmap is removing some random DMA mapping that might still be required. If the PCI function now presents that IOVA, the IOMMU may assumes a rogue DMA access and e.g. on s390 puts the PCI function in error state. The erroneous behavior was seen in a stress-test environment that created memory pressure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50179", "url": "https://ubuntu.com/security/CVE-2024-50179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: remove the incorrect Fw reference check when dirtying pages When doing the direct-io reads it will also try to mark pages dirty, but for the read path it won't hold the Fw caps and there is case will it get the Fw reference.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49963", "url": "https://ubuntu.com/security/CVE-2024-49963", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mailbox: bcm2835: Fix timeout during suspend mode During noirq suspend phase the Raspberry Pi power driver suffer of firmware property timeouts. The reason is that the IRQ of the underlying BCM2835 mailbox is disabled and rpi_firmware_property_list() will always run into a timeout [1]. Since the VideoCore side isn't consider as a wakeup source, set the IRQF_NO_SUSPEND flag for the mailbox IRQ in order to keep it enabled during suspend-resume cycle. [1] PM: late suspend of devices complete after 1.754 msecs WARNING: CPU: 0 PID: 438 at drivers/firmware/raspberrypi.c:128 rpi_firmware_property_list+0x204/0x22c Firmware transaction 0x00028001 timeout Modules linked in: CPU: 0 PID: 438 Comm: bash Tainted: G C 6.9.3-dirty #17 Hardware name: BCM2835 Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x44 dump_stack_lvl from __warn+0x88/0xec __warn from warn_slowpath_fmt+0x7c/0xb0 warn_slowpath_fmt from rpi_firmware_property_list+0x204/0x22c rpi_firmware_property_list from rpi_firmware_property+0x68/0x8c rpi_firmware_property from rpi_firmware_set_power+0x54/0xc0 rpi_firmware_set_power from _genpd_power_off+0xe4/0x148 _genpd_power_off from genpd_sync_power_off+0x7c/0x11c genpd_sync_power_off from genpd_finish_suspend+0xcc/0xe0 genpd_finish_suspend from dpm_run_callback+0x78/0xd0 dpm_run_callback from device_suspend_noirq+0xc0/0x238 device_suspend_noirq from dpm_suspend_noirq+0xb0/0x168 dpm_suspend_noirq from suspend_devices_and_enter+0x1b8/0x5ac suspend_devices_and_enter from pm_suspend+0x254/0x2e4 pm_suspend from state_store+0xa8/0xd4 state_store from kernfs_fop_write_iter+0x154/0x1a0 kernfs_fop_write_iter from vfs_write+0x12c/0x184 vfs_write from ksys_write+0x78/0xc0 ksys_write from ret_fast_syscall+0x0/0x54 Exception stack(0xcc93dfa8 to 0xcc93dff0) [...] PM: noirq suspend of devices complete after 3095.584 msecs", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49954", "url": "https://ubuntu.com/security/CVE-2024-49954", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: static_call: Replace pointless WARN_ON() in static_call_module_notify() static_call_module_notify() triggers a WARN_ON(), when memory allocation fails in __static_call_add_module(). That's not really justified, because the failure case must be correctly handled by the well known call chain and the error code is passed through to the initiating userspace application. A memory allocation fail is not a fatal problem, but the WARN_ON() takes the machine out when panic_on_warn is set. Replace it with a pr_warn().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50002", "url": "https://ubuntu.com/security/CVE-2024-50002", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: static_call: Handle module init failure correctly in static_call_del_module() Module insertion invokes static_call_add_module() to initialize the static calls in a module. static_call_add_module() invokes __static_call_init(), which allocates a struct static_call_mod to either encapsulate the built-in static call sites of the associated key into it so further modules can be added or to append the module to the module chain. If that allocation fails the function returns with an error code and the module core invokes static_call_del_module() to clean up eventually added static_call_mod entries. This works correctly, when all keys used by the module were converted over to a module chain before the failure. If not then static_call_del_module() causes a #GP as it blindly assumes that key::mods points to a valid struct static_call_mod. The problem is that key::mods is not a individual struct member of struct static_call_key, it's part of a union to save space: union { /* bit 0: 0 = mods, 1 = sites */ unsigned long type; struct static_call_mod *mods; struct static_call_site *sites; \t}; key::sites is a pointer to the list of built-in usage sites of the static call. The type of the pointer is differentiated by bit 0. A mods pointer has the bit clear, the sites pointer has the bit set. As static_call_del_module() blidly assumes that the pointer is a valid static_call_mod type, it fails to check for this failure case and dereferences the pointer to the list of built-in call sites, which is obviously bogus. Cure it by checking whether the key has a sites or a mods pointer. If it's a sites pointer then the key is not to be touched. As the sites are walked in the same order as in __static_call_init() the site walk can be terminated because all subsequent sites have not been touched by the init code due to the error exit. If it was converted before the allocation fail, then the inner loop which searches for a module match will find nothing. A fail in the second allocation in __static_call_init() is harmless and does not require special treatment. The first allocation succeeded and converted the key to a module chain. That first entry has mod::mod == NULL and mod::next == NULL, so the inner loop of static_call_del_module() will neither find a module match nor a module chain. The next site in the walk was either already converted, but can't match the module, or it will exit the outer loop because it has a static_call_site pointer and not a static_call_mod pointer.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-47675", "url": "https://ubuntu.com/security/CVE-2024-47675", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix use-after-free in bpf_uprobe_multi_link_attach() If bpf_link_prime() fails, bpf_uprobe_multi_link_attach() goes to the error_free label and frees the array of bpf_uprobe's without calling bpf_uprobe_unregister(). This leaks bpf_uprobe->uprobe and worse, this frees bpf_uprobe->consumer without removing it from the uprobe->consumers list.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47676", "url": "https://ubuntu.com/security/CVE-2024-47676", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb.c: fix UAF of vma in hugetlb fault pathway Syzbot reports a UAF in hugetlb_fault(). This happens because vmf_anon_prepare() could drop the per-VMA lock and allow the current VMA to be freed before hugetlb_vma_unlock_read() is called. We can fix this by using a modified version of vmf_anon_prepare() that doesn't release the VMA lock on failure, and then release it ourselves after hugetlb_vma_unlock_read().", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47677", "url": "https://ubuntu.com/security/CVE-2024-47677", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: resolve memory leak from exfat_create_upcase_table() If exfat_load_upcase_table reaches end and returns -EINVAL, allocated memory doesn't get freed and while exfat_load_default_upcase_table allocates more memory, leading to a memory leak. Here's link to syzkaller crash report illustrating this issue: https://syzkaller.appspot.com/text?tag=CrashReport&x=1406c201980000", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47725", "url": "https://ubuntu.com/security/CVE-2024-47725", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47739", "url": "https://ubuntu.com/security/CVE-2024-47739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: padata: use integer wrap around to prevent deadlock on seq_nr overflow When submitting more than 2^32 padata objects to padata_do_serial, the current sorting implementation incorrectly sorts padata objects with overflowed seq_nr, causing them to be placed before existing objects in the reorder list. This leads to a deadlock in the serialization process as padata_find_next cannot match padata->seq_nr and pd->processed because the padata instance with overflowed seq_nr will be selected next. To fix this, we use an unsigned integer wrap around to correctly sort padata objects in scenarios with integer overflow.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47678", "url": "https://ubuntu.com/security/CVE-2024-47678", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: icmp: change the order of rate limits ICMP messages are ratelimited : After the blamed commits, the two rate limiters are applied in this order: 1) host wide ratelimit (icmp_global_allow()) 2) Per destination ratelimit (inetpeer based) In order to avoid side-channels attacks, we need to apply the per destination check first. This patch makes the following change : 1) icmp_global_allow() checks if the host wide limit is reached. But credits are not yet consumed. This is deferred to 3) 2) The per destination limit is checked/updated. This might add a new node in inetpeer tree. 3) icmp_global_consume() consumes tokens if prior operations succeeded. This means that host wide ratelimit is still effective in keeping inetpeer tree small even under DDOS. As a bonus, I removed icmp_global.lock as the fast path can use a lock-free operation.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47733", "url": "https://ubuntu.com/security/CVE-2024-47733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfs: Delete subtree of 'fs/netfs' when netfs module exits In netfs_init() or fscache_proc_init(), we create dentry under 'fs/netfs', but in netfs_exit(), we only delete the proc entry of 'fs/netfs' without deleting its subtree. This triggers the following WARNING: ================================================================== remove_proc_entry: removing non-empty directory 'fs/netfs', leaking at least 'requests' WARNING: CPU: 4 PID: 566 at fs/proc/generic.c:717 remove_proc_entry+0x160/0x1c0 Modules linked in: netfs(-) CPU: 4 UID: 0 PID: 566 Comm: rmmod Not tainted 6.11.0-rc3 #860 RIP: 0010:remove_proc_entry+0x160/0x1c0 Call Trace: netfs_exit+0x12/0x620 [netfs] __do_sys_delete_module.isra.0+0x14c/0x2e0 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e ================================================================== Therefore use remove_proc_subtree() instead of remove_proc_entry() to fix the above problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47679", "url": "https://ubuntu.com/security/CVE-2024-47679", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfs: fix race between evice_inodes() and find_inode()&iput() Hi, all Recently I noticed a bug[1] in btrfs, after digged it into and I believe it'a race in vfs. Let's assume there's a inode (ie ino 261) with i_count 1 is called by iput(), and there's a concurrent thread calling generic_shutdown_super(). cpu0: cpu1: iput() // i_count is 1 ->spin_lock(inode) ->dec i_count to 0 ->iput_final() generic_shutdown_super() ->__inode_add_lru() ->evict_inodes() // cause some reason[2] ->if (atomic_read(inode->i_count)) continue; // return before // inode 261 passed the above check // list_lru_add_obj() // and then schedule out ->spin_unlock() // note here: the inode 261 // was still at sb list and hash list, // and I_FREEING|I_WILL_FREE was not been set btrfs_iget() // after some function calls ->find_inode() // found the above inode 261 ->spin_lock(inode) // check I_FREEING|I_WILL_FREE // and passed ->__iget() ->spin_unlock(inode) // schedule back ->spin_lock(inode) // check (I_NEW|I_FREEING|I_WILL_FREE) flags, // passed and set I_FREEING iput() ->spin_unlock(inode) ->spin_lock(inode)\t\t\t ->evict() // dec i_count to 0 ->iput_final() ->spin_unlock() ->evict() Now, we have two threads simultaneously evicting the same inode, which may trigger the BUG(inode->i_state & I_CLEAR) statement both within clear_inode() and iput(). To fix the bug, recheck the inode->i_count after holding i_lock. Because in the most scenarios, the first check is valid, and the overhead of spin_lock() can be reduced. If there is any misunderstanding, please let me know, thanks. [1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/ [2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable() return false when I reproduced the bug.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49859", "url": "https://ubuntu.com/security/CVE-2024-49859", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to check atomic_file in f2fs ioctl interfaces Some f2fs ioctl interfaces like f2fs_ioc_set_pin_file(), f2fs_move_file_range(), and f2fs_defragment_range() missed to check atomic_write status, which may cause potential race issue, fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47680", "url": "https://ubuntu.com/security/CVE-2024-47680", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: check discard support for conventional zones As the helper function f2fs_bdev_support_discard() shows, f2fs checks if the target block devices support discard by calling bdev_max_discard_sectors() and bdev_is_zoned(). This check works well for most cases, but it does not work for conventional zones on zoned block devices. F2fs assumes that zoned block devices support discard, and calls __submit_discard_cmd(). When __submit_discard_cmd() is called for sequential write required zones, it works fine since __submit_discard_cmd() issues zone reset commands instead of discard commands. However, when __submit_discard_cmd() is called for conventional zones, __blkdev_issue_discard() is called even when the devices do not support discard. The inappropriate __blkdev_issue_discard() call was not a problem before the commit 30f1e7241422 (\"block: move discard checks into the ioctl handler\") because __blkdev_issue_discard() checked if the target devices support discard or not. If not, it returned EOPNOTSUPP. After the commit, __blkdev_issue_discard() no longer checks it. It always returns zero and sets NULL to the given bio pointer. This NULL pointer triggers f2fs_bug_on() in __submit_discard_cmd(). The BUG is recreated with the commands below at the umount step, where /dev/nullb0 is a zoned null_blk with 5GB total size, 128MB zone size and 10 conventional zones. $ mkfs.f2fs -f -m /dev/nullb0 $ mount /dev/nullb0 /mnt $ for ((i=0;i<5;i++)); do dd if=/dev/zero of=/mnt/test bs=65536 count=1600 conv=fsync; done $ umount /mnt To fix the BUG, avoid the inappropriate __blkdev_issue_discard() call. When discard is requested for conventional zones, check if the device supports discard or not. If not, return EOPNOTSUPP.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47740", "url": "https://ubuntu.com/security/CVE-2024-47740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: Require FMODE_WRITE for atomic write ioctls The F2FS ioctls for starting and committing atomic writes check for inode_owner_or_capable(), but this does not give LSMs like SELinux or Landlock an opportunity to deny the write access - if the caller's FSUID matches the inode's UID, inode_owner_or_capable() immediately returns true. There are scenarios where LSMs want to deny a process the ability to write particular files, even files that the FSUID of the process owns; but this can currently partially be bypassed using atomic write ioctls in two ways: - F2FS_IOC_START_ATOMIC_REPLACE + F2FS_IOC_COMMIT_ATOMIC_WRITE can truncate an inode to size 0 - F2FS_IOC_START_ATOMIC_WRITE + F2FS_IOC_ABORT_ATOMIC_WRITE can revert changes another process concurrently made to a file Fix it by requiring FMODE_WRITE for these operations, just like for F2FS_IOC_MOVE_RANGE. Since any legitimate caller should only be using these ioctls when intending to write into the file, that seems unlikely to break anything.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47726", "url": "https://ubuntu.com/security/CVE-2024-47726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to wait dio completion It should wait all existing dio write IOs before block removal, otherwise, previous direct write IO may overwrite data in the block which may be reused by other inode.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47741", "url": "https://ubuntu.com/security/CVE-2024-47741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race setting file private on concurrent lseek using same fd When doing concurrent lseek(2) system calls against the same file descriptor, using multiple threads belonging to the same process, we have a short time window where a race happens and can result in a memory leak. The race happens like this: 1) A program opens a file descriptor for a file and then spawns two threads (with the pthreads library for example), lets call them task A and task B; 2) Task A calls lseek with SEEK_DATA or SEEK_HOLE and ends up at file.c:find_desired_extent() while holding a read lock on the inode; 3) At the start of find_desired_extent(), it extracts the file's private_data pointer into a local variable named 'private', which has a value of NULL; 4) Task B also calls lseek with SEEK_DATA or SEEK_HOLE, locks the inode in shared mode and enters file.c:find_desired_extent(), where it also extracts file->private_data into its local variable 'private', which has a NULL value; 5) Because it saw a NULL file private, task A allocates a private structure and assigns to the file structure; 6) Task B also saw a NULL file private so it also allocates its own file private and then assigns it to the same file structure, since both tasks are using the same file descriptor. At this point we leak the private structure allocated by task A. Besides the memory leak, there's also the detail that both tasks end up using the same cached state record in the private structure (struct btrfs_file_private::llseek_cached_state), which can result in a use-after-free problem since one task can free it while the other is still using it (only one task took a reference count on it). Also, sharing the cached state is not a good idea since it could result in incorrect results in the future - right now it should not be a problem because it end ups being used only in extent-io-tree.c:count_range_bits() where we do range validation before using the cached state. Fix this by protecting the private assignment and check of a file while holding the inode's spinlock and keep track of the task that allocated the private, so that it's used only by that task in order to prevent user-after-free issues with the cached state record as well as potentially using it incorrectly in the future.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47681", "url": "https://ubuntu.com/security/CVE-2024-47681", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix NULL pointer dereference in mt7996_mcu_sta_bfer_he Fix the NULL pointer dereference in mt7996_mcu_sta_bfer_he routine adding an sta interface to the mt7996 driver. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49858", "url": "https://ubuntu.com/security/CVE-2024-49858", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption The TPM event log table is a Linux specific construct, where the data produced by the GetEventLog() boot service is cached in memory, and passed on to the OS using an EFI configuration table. The use of EFI_LOADER_DATA here results in the region being left unreserved in the E820 memory map constructed by the EFI stub, and this is the memory description that is passed on to the incoming kernel by kexec, which is therefore unaware that the region should be reserved. Even though the utility of the TPM2 event log after a kexec is questionable, any corruption might send the parsing code off into the weeds and crash the kernel. So let's use EFI_ACPI_RECLAIM_MEMORY instead, which is always treated as reserved by the E820 conversion logic.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49860", "url": "https://ubuntu.com/security/CVE-2024-49860", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: sysfs: validate return type of _STR method Only buffer objects are valid return values of _STR. If something else is returned description_show() will access invalid memory.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47742", "url": "https://ubuntu.com/security/CVE-2024-47742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware_loader: Block path traversal Most firmware names are hardcoded strings, or are constructed from fairly constrained format strings where the dynamic parts are just some hex numbers or such. However, there are a couple codepaths in the kernel where firmware file names contain string components that are passed through from a device or semi-privileged userspace; the ones I could find (not counting interfaces that require root privileges) are: - lpfc_sli4_request_firmware_update() seems to construct the firmware filename from \"ModelName\", a string that was previously parsed out of some descriptor (\"Vital Product Data\") in lpfc_fill_vpd() - nfp_net_fw_find() seems to construct a firmware filename from a model name coming from nfp_hwinfo_lookup(pf->hwinfo, \"nffw.partno\"), which I think parses some descriptor that was read from the device. (But this case likely isn't exploitable because the format string looks like \"netronome/nic_%s\", and there shouldn't be any *folders* starting with \"netronome/nic_\". The previous case was different because there, the \"%s\" is *at the start* of the format string.) - module_flash_fw_schedule() is reachable from the ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is enough to pass the privilege check), and takes a userspace-provided firmware name. (But I think to reach this case, you need to have CAP_NET_ADMIN over a network namespace that a special kind of ethernet device is mapped into, so I think this is not a viable attack path in practice.) Fix it by rejecting any firmware names containing \"..\" path components. For what it's worth, I went looking and haven't found any USB device drivers that use the firmware loader dangerously.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47682", "url": "https://ubuntu.com/security/CVE-2024-47682", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sd: Fix off-by-one error in sd_read_block_characteristics() Ff the device returns page 0xb1 with length 8 (happens with qemu v2.x, for example), sd_read_block_characteristics() may attempt an out-of-bounds memory access when accessing the zoned field at offset 8.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47743", "url": "https://ubuntu.com/security/CVE-2024-47743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: prevent NULL pointer dereference in find_asymmetric_key() In find_asymmetric_key(), if all NULLs are passed in the id_{0,1,2} arguments, the kernel will first emit WARN but then have an oops because id_2 gets dereferenced anyway. Add the missing id_2 check and move WARN_ON() to the final else branch to avoid duplicate NULL checks. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47727", "url": "https://ubuntu.com/security/CVE-2024-47727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/tdx: Fix \"in-kernel MMIO\" check TDX only supports kernel-initiated MMIO operations. The handle_mmio() function checks if the #VE exception occurred in the kernel and rejects the operation if it did not. However, userspace can deceive the kernel into performing MMIO on its behalf. For example, if userspace can point a syscall to an MMIO address, syscall does get_user() or put_user() on it, triggering MMIO #VE. The kernel will treat the #VE as in-kernel MMIO. Ensure that the target MMIO address is within the kernel before decoding instruction.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47744", "url": "https://ubuntu.com/security/CVE-2024-47744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Use dedicated mutex to protect kvm_usage_count to avoid deadlock Use a dedicated mutex to guard kvm_usage_count to fix a potential deadlock on x86 due to a chain of locks and SRCU synchronizations. Translating the below lockdep splat, CPU1 #6 will wait on CPU0 #1, CPU0 #8 will wait on CPU2 #3, and CPU2 #7 will wait on CPU1 #4 (if there's a writer, due to the fairness of r/w semaphores). CPU0 CPU1 CPU2 1 lock(&kvm->slots_lock); 2 lock(&vcpu->mutex); 3 lock(&kvm->srcu); 4 lock(cpu_hotplug_lock); 5 lock(kvm_lock); 6 lock(&kvm->slots_lock); 7 lock(cpu_hotplug_lock); 8 sync(&kvm->srcu); Note, there are likely more potential deadlocks in KVM x86, e.g. the same pattern of taking cpu_hotplug_lock outside of kvm_lock likely exists with __kvmclock_cpufreq_notifier(): cpuhp_cpufreq_online() | -> cpufreq_online() | -> cpufreq_gov_performance_limits() | -> __cpufreq_driver_target() | -> __target_index() | -> cpufreq_freq_transition_begin() | -> cpufreq_notify_transition() | -> ... __kvmclock_cpufreq_notifier() But, actually triggering such deadlocks is beyond rare due to the combination of dependencies and timings involved. E.g. the cpufreq notifier is only used on older CPUs without a constant TSC, mucking with the NX hugepage mitigation while VMs are running is very uncommon, and doing so while also onlining/offlining a CPU (necessary to generate contention on cpu_hotplug_lock) would be even more unusual. The most robust solution to the general cpu_hotplug_lock issue is likely to switch vm_list to be an RCU-protected list, e.g. so that x86's cpufreq notifier doesn't to take kvm_lock. For now, settle for fixing the most blatant deadlock, as switching to an RCU-protected list is a much more involved change, but add a comment in locking.rst to call out that care needs to be taken when walking holding kvm_lock and walking vm_list. ====================================================== WARNING: possible circular locking dependency detected 6.10.0-smp--c257535a0c9d-pip #330 Tainted: G S O ------------------------------------------------------ tee/35048 is trying to acquire lock: ff6a80eced71e0a8 (&kvm->slots_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x179/0x1e0 [kvm] but task is already holding lock: ffffffffc07abb08 (kvm_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x14a/0x1e0 [kvm] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (kvm_lock){+.+.}-{3:3}: __mutex_lock+0x6a/0xb40 mutex_lock_nested+0x1f/0x30 kvm_dev_ioctl+0x4fb/0xe50 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #2 (cpu_hotplug_lock){++++}-{0:0}: cpus_read_lock+0x2e/0xb0 static_key_slow_inc+0x16/0x30 kvm_lapic_set_base+0x6a/0x1c0 [kvm] kvm_set_apic_base+0x8f/0xe0 [kvm] kvm_set_msr_common+0x9ae/0xf80 [kvm] vmx_set_msr+0xa54/0xbe0 [kvm_intel] __kvm_set_msr+0xb6/0x1a0 [kvm] kvm_arch_vcpu_ioctl+0xeca/0x10c0 [kvm] kvm_vcpu_ioctl+0x485/0x5b0 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (&kvm->srcu){.+.+}-{0:0}: __synchronize_srcu+0x44/0x1a0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47719", "url": "https://ubuntu.com/security/CVE-2024-47719", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommufd: Protect against overflow of ALIGN() during iova allocation Userspace can supply an iova and uptr such that the target iova alignment becomes really big and ALIGN() overflows which corrupts the selected area range during allocation. CONFIG_IOMMUFD_TEST can detect this: WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline] WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352 Modules linked in: CPU: 1 PID: 5092 Comm: syz-executor294 Not tainted 6.10.0-rc5-syzkaller-00294-g3ffea9a7a6f7 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024 RIP: 0010:iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline] RIP: 0010:iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352 Code: fc e9 a4 f3 ff ff e8 1a 8b 4c fc 41 be e4 ff ff ff e9 8a f3 ff ff e8 0a 8b 4c fc 90 0f 0b 90 e9 37 f5 ff ff e8 fc 8a 4c fc 90 <0f> 0b 90 e9 68 f3 ff ff 48 c7 c1 ec 82 ad 8f 80 e1 07 80 c1 03 38 RSP: 0018:ffffc90003ebf9e0 EFLAGS: 00010293 RAX: ffffffff85499fa4 RBX: 00000000ffffffef RCX: ffff888079b49e00 RDX: 0000000000000000 RSI: 00000000ffffffef RDI: 0000000000000000 RBP: ffffc90003ebfc50 R08: ffffffff85499b30 R09: ffffffff85499942 R10: 0000000000000002 R11: ffff888079b49e00 R12: ffff8880228e0010 R13: 0000000000000000 R14: 1ffff920007d7f68 R15: ffffc90003ebfd00 FS: 000055557d760380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000005fdeb8 CR3: 000000007404a000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: iommufd_ioas_copy+0x610/0x7b0 drivers/iommu/iommufd/ioas.c:274 iommufd_fops_ioctl+0x4d9/0x5a0 drivers/iommu/iommufd/main.c:421 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Cap the automatic alignment to the huge page size, which is probably a better idea overall. Huge automatic alignments can fragment and chew up the available IOVA space without any reason.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47745", "url": "https://ubuntu.com/security/CVE-2024-47745", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: call the security_mmap_file() LSM hook in remap_file_pages() The remap_file_pages syscall handler calls do_mmap() directly, which doesn't contain the LSM security check. And if the process has called personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for RW pages, this will actually result in remapping the pages to RWX, bypassing a W^X policy enforced by SELinux. So we should check prot by security_mmap_file LSM hook in the remap_file_pages syscall handler before do_mmap() is called. Otherwise, it potentially permits an attacker to bypass a W^X policy enforced by SELinux. The bypass is similar to CVE-2016-10044, which bypass the same thing via AIO and can be found in [1]. The PoC: $ cat > test.c int main(void) { \tsize_t pagesz = sysconf(_SC_PAGE_SIZE); \tint mfd = syscall(SYS_memfd_create, \"test\", 0); \tconst char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE, \t\tMAP_SHARED, mfd, 0); \tunsigned int old = syscall(SYS_personality, 0xffffffff); \tsyscall(SYS_personality, READ_IMPLIES_EXEC | old); \tsyscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0); \tsyscall(SYS_personality, old); \t// show the RWX page exists even if W^X policy is enforced \tint fd = open(\"/proc/self/maps\", O_RDONLY); \tunsigned char buf2[1024]; \twhile (1) { \t\tint ret = read(fd, buf2, 1024); \t\tif (ret <= 0) break; \t\twrite(1, buf2, ret); \t} \tclose(fd); } $ gcc test.c -o test $ ./test | grep rwx 7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted) [PM: subject line tweaks]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47746", "url": "https://ubuntu.com/security/CVE-2024-47746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: use exclusive lock when FUSE_I_CACHE_IO_MODE is set This may be a typo. The comment has said shared locks are not allowed when this bit is set. If using shared lock, the wait in `fuse_file_cached_io_open` may be forever.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47734", "url": "https://ubuntu.com/security/CVE-2024-47734", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: Fix unnecessary warnings and logs from bond_xdp_get_xmit_slave() syzbot reported a WARNING in bond_xdp_get_xmit_slave. To reproduce this[1], one bond device (bond1) has xdpdrv, which increases bpf_master_redirect_enabled_key. Another bond device (bond0) which is unsupported by XDP but its slave (veth3) has xdpgeneric that returns XDP_TX. This triggers WARN_ON_ONCE() from the xdp_master_redirect(). To reduce unnecessary warnings and improve log management, we need to delete the WARN_ON_ONCE() and add ratelimit to the netdev_err(). [1] Steps to reproduce: # Needs tx_xdp with return XDP_TX; ip l add veth0 type veth peer veth1 ip l add veth3 type veth peer veth4 ip l add bond0 type bond mode 6 # BOND_MODE_ALB, unsupported by XDP ip l add bond1 type bond # BOND_MODE_ROUNDROBIN by default ip l set veth0 master bond1 ip l set bond1 up # Increases bpf_master_redirect_enabled_key ip l set dev bond1 xdpdrv object tx_xdp.o section xdp_tx ip l set veth3 master bond0 ip l set bond0 up ip l set veth4 up # Triggers WARN_ON_ONCE() from the xdp_master_redirect() ip l set veth3 xdpgeneric object tx_xdp.o section xdp_tx", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47684", "url": "https://ubuntu.com/security/CVE-2024-47684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: check skb is non-NULL in tcp_rto_delta_us() We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic kernel that are running ceph and recently hit a null ptr dereference in tcp_rearm_rto(). Initially hitting it from the TLP path, but then later we also saw it getting hit from the RACK case as well. Here are examples of the oops messages we saw in each of those cases: Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020 Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode Jul 26 15:05:02 rx [11061395.792971] #PF: error_code(0x0000) - not-present page Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0 Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI Jul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu Jul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023 Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 <48> 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3 Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246 Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000 Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60 Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8 Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900 Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30 Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000 Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0 Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554 Jul 26 15:05:02 rx [11061395.916786] Call Trace: Jul 26 15:05:02 rx [11061395.919488] Jul 26 15:05:02 rx [11061395.921765] ? show_regs.cold+0x1a/0x1f Jul 26 15:05:02 rx [11061395.925859] ? __die+0x90/0xd9 Jul 26 15:05:02 rx [11061395.929169] ? no_context+0x196/0x380 Jul 26 15:05:02 rx [11061395.933088] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0 Jul 26 15:05:02 rx [11061395.938216] ? ip6_sublist_rcv_finish+0x3d/0x50 Jul 26 15:05:02 rx [11061395.943000] ? __bad_area_nosemaphore+0x50/0x1a0 Jul 26 15:05:02 rx [11061395.947873] ? bad_area_nosemaphore+0x16/0x20 Jul 26 15:05:02 rx [11061395.952486] ? do_user_addr_fault+0x267/0x450 Jul 26 15:05:02 rx [11061395.957104] ? ipv6_list_rcv+0x112/0x140 Jul 26 15:05:02 rx [11061395.961279] ? __do_page_fault+0x58/0x90 Jul 26 15:05:02 rx [11061395.965458] ? do_page_fault+0x2c/0xe0 Jul 26 15:05:02 rx [11061395.969465] ? page_fault+0x34/0x40 Jul 26 15:05:02 rx [11061395.973217] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.977313] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.981408] tcp_send_loss_probe+0x10b/0x220 Jul 26 15:05:02 rx [11061395.985937] tcp_write_timer_handler+0x1b4/0x240 Jul 26 15:05:02 rx [11061395.990809] tcp_write_timer+0x9e/0xe0 Jul 26 15:05:02 rx [11061395.994814] ? tcp_write_timer_handler+0x240/0x240 Jul 26 15:05:02 rx [11061395.999866] call_timer_fn+0x32/0x130 Jul 26 15:05:02 rx [11061396.003782] __run_timers.part.0+0x180/0x280 Jul 26 15:05:02 rx [11061396.008309] ? recalibrate_cpu_khz+0x10/0x10 Jul 26 15:05:02 rx [11061396.012841] ? native_x2apic_icr_write+0x30/0x30 Jul 26 15:05:02 rx [11061396.017718] ? lapic_next_even ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47747", "url": "https://ubuntu.com/security/CVE-2024-47747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race Condition In the ether3_probe function, a timer is initialized with a callback function ether3_ledoff, bound to &prev(dev)->timer. Once the timer is started, there is a risk of a race condition if the module or device is removed, triggering the ether3_remove function to perform cleanup. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | ether3_ledoff ether3_remove | free_netdev(dev); | put_devic | kfree(dev); | | ether3_outw(priv(dev)->regs.config2 |= CFG2_CTRLO, REG_CONFIG2); | // use dev Fix it by ensuring that the timer is canceled before proceeding with the cleanup in ether3_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47685", "url": "https://ubuntu.com/security/CVE-2024-47685", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put() syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending garbage on the four reserved tcp bits (th->res1) Use skb_put_zero() to clear the whole TCP header, as done in nf_reject_ip_tcphdr_put() BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5661 [inline] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775 process_backlog+0x4ad/0xa50 net/core/dev.c:6108 __napi_poll+0xe7/0x980 net/core/dev.c:6772 napi_poll net/core/dev.c:6841 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963 handle_softirqs+0x1ce/0x800 kernel/softirq.c:554 __do_softirq+0x14/0x1a kernel/softirq.c:588 do_softirq+0x9a/0x100 kernel/softirq.c:455 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline] __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450 dev_queue_xmit include/linux/netdevice.h:3105 [inline] neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366 inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135 __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143 tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333 __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679 inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750 __sys_connect_file net/socket.c:2061 [inline] __sys_connect+0x606/0x690 net/socket.c:2078 __do_sys_connect net/socket.c:2088 [inline] __se_sys_connect net/socket.c:2085 [inline] __x64_sys_connect+0x91/0xe0 net/socket.c:2085 x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43 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 Uninit was stored to memory at: nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47686", "url": "https://ubuntu.com/security/CVE-2024-47686", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ep93xx: clock: Fix off by one in ep93xx_div_recalc_rate() The psc->div[] array has psc->num_div elements. These values come from when we call clk_hw_register_div(). It's adc_divisors and ARRAY_SIZE(adc_divisors)) and so on. So this condition needs to be >= instead of > to prevent an out of bounds read.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47748", "url": "https://ubuntu.com/security/CVE-2024-47748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost_vdpa: assign irq bypass producer token correctly We used to call irq_bypass_unregister_producer() in vhost_vdpa_setup_vq_irq() which is problematic as we don't know if the token pointer is still valid or not. Actually, we use the eventfd_ctx as the token so the life cycle of the token should be bound to the VHOST_SET_VRING_CALL instead of vhost_vdpa_setup_vq_irq() which could be called by set_status(). Fixing this by setting up irq bypass producer's token when handling VHOST_SET_VRING_CALL and un-registering the producer before calling vhost_vring_ioctl() to prevent a possible use after free as eventfd could have been released in vhost_vring_ioctl(). And such registering and unregistering will only be done if DRIVER_OK is set.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47687", "url": "https://ubuntu.com/security/CVE-2024-47687", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa/mlx5: Fix invalid mr resource destroy Certain error paths from mlx5_vdpa_dev_add() can end up releasing mr resources which never got initialized in the first place. This patch adds the missing check in mlx5_vdpa_destroy_mr_resources() to block releasing non-initialized mr resources. Reference trace: mlx5_core 0000:08:00.2: mlx5_vdpa_dev_add:3274:(pid 2700) warning: No mac address provisioned? BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 140216067 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 8 PID: 2700 Comm: vdpa Kdump: loaded Not tainted 5.14.0-496.el9.x86_64 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:vhost_iotlb_del_range+0xf/0xe0 [vhost_iotlb] Code: [...] RSP: 0018:ff1c823ac23077f0 EFLAGS: 00010246 RAX: ffffffffc1a21a60 RBX: ffffffff899567a0 RCX: 0000000000000000 RDX: ffffffffffffffff RSI: 0000000000000000 RDI: 0000000000000000 RBP: ff1bda1f7c21e800 R08: 0000000000000000 R09: ff1c823ac2307670 R10: ff1c823ac2307668 R11: ffffffff8a9e7b68 R12: 0000000000000000 R13: 0000000000000000 R14: ff1bda1f43e341a0 R15: 00000000ffffffea FS: 00007f56eba7c740(0000) GS:ff1bda269f800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000104d90001 CR4: 0000000000771ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? mlx5_vdpa_free+0x3d/0x150 [mlx5_vdpa] ? __die_body.cold+0x8/0xd ? page_fault_oops+0x134/0x170 ? __irq_work_queue_local+0x2b/0xc0 ? irq_work_queue+0x2c/0x50 ? exc_page_fault+0x62/0x150 ? asm_exc_page_fault+0x22/0x30 ? __pfx_mlx5_vdpa_free+0x10/0x10 [mlx5_vdpa] ? vhost_iotlb_del_range+0xf/0xe0 [vhost_iotlb] mlx5_vdpa_free+0x3d/0x150 [mlx5_vdpa] vdpa_release_dev+0x1e/0x50 [vdpa] device_release+0x31/0x90 kobject_cleanup+0x37/0x130 mlx5_vdpa_dev_add+0x2d2/0x7a0 [mlx5_vdpa] vdpa_nl_cmd_dev_add_set_doit+0x277/0x4c0 [vdpa] genl_family_rcv_msg_doit+0xd9/0x130 genl_family_rcv_msg+0x14d/0x220 ? __pfx_vdpa_nl_cmd_dev_add_set_doit+0x10/0x10 [vdpa] ? _copy_to_user+0x1a/0x30 ? move_addr_to_user+0x4b/0xe0 genl_rcv_msg+0x47/0xa0 ? __import_iovec+0x46/0x150 ? __pfx_genl_rcv_msg+0x10/0x10 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x245/0x370 netlink_sendmsg+0x206/0x440 __sys_sendto+0x1dc/0x1f0 ? do_read_fault+0x10c/0x1d0 ? do_pte_missing+0x10d/0x190 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x5c/0xf0 ? __count_memcg_events+0x4f/0xb0 ? mm_account_fault+0x6c/0x100 ? handle_mm_fault+0x116/0x270 ? do_user_addr_fault+0x1d6/0x6a0 ? do_syscall_64+0x6b/0xf0 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 entry_SYSCALL_64_after_hwframe+0x78/0x80", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47688", "url": "https://ubuntu.com/security/CVE-2024-47688", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: driver core: Fix a potential null-ptr-deref in module_add_driver() Inject fault while probing of-fpga-region, if kasprintf() fails in module_add_driver(), the second sysfs_remove_link() in exit path will cause null-ptr-deref as below because kernfs_name_hash() will call strlen() with NULL driver_name. Fix it by releasing resources based on the exit path sequence. \t KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] \t Mem abort info: \t ESR = 0x0000000096000005 \t EC = 0x25: DABT (current EL), IL = 32 bits \t SET = 0, FnV = 0 \t EA = 0, S1PTW = 0 \t FSC = 0x05: level 1 translation fault \t Data abort info: \t ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 \t CM = 0, WnR = 0, TnD = 0, TagAccess = 0 \t GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 \t [dfffffc000000000] address between user and kernel address ranges \t Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP \t Dumping ftrace buffer: \t (ftrace buffer empty) \t Modules linked in: of_fpga_region(+) fpga_region fpga_bridge cfg80211 rfkill 8021q garp mrp stp llc ipv6 [last unloaded: of_fpga_region] \t CPU: 2 UID: 0 PID: 2036 Comm: modprobe Not tainted 6.11.0-rc2-g6a0e38264012 #295 \t Hardware name: linux,dummy-virt (DT) \t pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) \t pc : strlen+0x24/0xb0 \t lr : kernfs_name_hash+0x1c/0xc4 \t sp : ffffffc081f97380 \t x29: ffffffc081f97380 x28: ffffffc081f97b90 x27: ffffff80c821c2a0 \t x26: ffffffedac0be418 x25: 0000000000000000 x24: ffffff80c09d2000 \t x23: 0000000000000000 x22: 0000000000000000 x21: 0000000000000000 \t x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000001840 \t x17: 0000000000000000 x16: 0000000000000000 x15: 1ffffff8103f2e42 \t x14: 00000000f1f1f1f1 x13: 0000000000000004 x12: ffffffb01812d61d \t x11: 1ffffff01812d61c x10: ffffffb01812d61c x9 : dfffffc000000000 \t x8 : 0000004fe7ed29e4 x7 : ffffff80c096b0e7 x6 : 0000000000000001 \t x5 : ffffff80c096b0e0 x4 : 1ffffffdb990efa2 x3 : 0000000000000000 \t x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000000 \t Call trace: \t strlen+0x24/0xb0 \t kernfs_name_hash+0x1c/0xc4 \t kernfs_find_ns+0x118/0x2e8 \t kernfs_remove_by_name_ns+0x80/0x100 \t sysfs_remove_link+0x74/0xa8 \t module_add_driver+0x278/0x394 \t bus_add_driver+0x1f0/0x43c \t driver_register+0xf4/0x3c0 \t __platform_driver_register+0x60/0x88 \t of_fpga_region_init+0x20/0x1000 [of_fpga_region] \t do_one_initcall+0x110/0x788 \t do_init_module+0x1dc/0x5c8 \t load_module+0x3c38/0x4cac \t init_module_from_file+0xd4/0x128 \t idempotent_init_module+0x2cc/0x528 \t __arm64_sys_finit_module+0xac/0x100 \t invoke_syscall+0x6c/0x258 \t el0_svc_common.constprop.0+0x160/0x22c \t do_el0_svc+0x44/0x5c \t el0_svc+0x48/0xb8 \t el0t_64_sync_handler+0x13c/0x158 \t el0t_64_sync+0x190/0x194 \t Code: f2fbffe1 a90157f4 12000802 aa0003f5 (38e16861) \t ---[ end trace 0000000000000000 ]--- \t Kernel panic - not syncing: Oops: Fatal exception", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47689", "url": "https://ubuntu.com/security/CVE-2024-47689", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to don't set SB_RDONLY in f2fs_handle_critical_error() syzbot reports a f2fs bug as below: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 58 at kernel/rcu/sync.c:177 rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177 CPU: 1 UID: 0 PID: 58 Comm: kworker/1:2 Not tainted 6.10.0-syzkaller-12562-g1722389b0d86 #0 Workqueue: events destroy_super_work RIP: 0010:rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177 Call Trace: percpu_free_rwsem+0x41/0x80 kernel/locking/percpu-rwsem.c:42 destroy_super_work+0xec/0x130 fs/super.c:282 process_one_work kernel/workqueue.c:3231 [inline] process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 worker_thread+0x86d/0xd40 kernel/workqueue.c:3390 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 As Christian Brauner pointed out [1]: the root cause is f2fs sets SB_RDONLY flag in internal function, rather than setting the flag covered w/ sb->s_umount semaphore via remount procedure, then below race condition causes this bug: - freeze_super() - sb_wait_write(sb, SB_FREEZE_WRITE) - sb_wait_write(sb, SB_FREEZE_PAGEFAULT) - sb_wait_write(sb, SB_FREEZE_FS) \t\t\t\t\t- f2fs_handle_critical_error \t\t\t\t\t - sb->s_flags |= SB_RDONLY - thaw_super - thaw_super_locked - sb_rdonly() is true, so it skips sb_freeze_unlock(sb, SB_FREEZE_FS) - deactivate_locked_super Since f2fs has almost the same logic as ext4 [2] when handling critical error in filesystem if it mounts w/ errors=remount-ro option: - set CP_ERROR_FLAG flag which indicates filesystem is stopped - record errors to superblock - set SB_RDONLY falg Once we set CP_ERROR_FLAG flag, all writable interfaces can detect the flag and stop any further updates on filesystem. So, it is safe to not set SB_RDONLY flag, let's remove the logic and keep in line w/ ext4 [3]. [1] https://lore.kernel.org/all/20240729-himbeeren-funknetz-96e62f9c7aee@brauner [2] https://lore.kernel.org/all/20240729132721.hxih6ehigadqf7wx@quack3 [3] https://lore.kernel.org/linux-ext4/20240805201241.27286-1-jack@suse.cz", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47690", "url": "https://ubuntu.com/security/CVE-2024-47690", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: get rid of online repaire on corrupted directory syzbot reports a f2fs bug as below: kernel BUG at fs/f2fs/inode.c:896! RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Call Trace: evict+0x532/0x950 fs/inode.c:704 dispose_list fs/inode.c:747 [inline] evict_inodes+0x5f9/0x690 fs/inode.c:797 generic_shutdown_super+0x9d/0x2d0 fs/super.c:627 kill_block_super+0x44/0x90 fs/super.c:1696 kill_f2fs_super+0x344/0x690 fs/f2fs/super.c:4898 deactivate_locked_super+0xc4/0x130 fs/super.c:473 cleanup_mnt+0x41f/0x4b0 fs/namespace.c:1373 task_work_run+0x24f/0x310 kernel/task_work.c:228 ptrace_notify+0x2d2/0x380 kernel/signal.c:2402 ptrace_report_syscall include/linux/ptrace.h:415 [inline] ptrace_report_syscall_exit include/linux/ptrace.h:477 [inline] syscall_exit_work+0xc6/0x190 kernel/entry/common.c:173 syscall_exit_to_user_mode_prepare kernel/entry/common.c:200 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:205 [inline] syscall_exit_to_user_mode+0x279/0x370 kernel/entry/common.c:218 do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Online repaire on corrupted directory in f2fs_lookup() can generate dirty data/meta while racing w/ readonly remount, it may leave dirty inode after filesystem becomes readonly, however, checkpoint() will skips flushing dirty inode in a state of readonly mode, result in above panic. Let's get rid of online repaire in f2fs_lookup(), and leave the work to fsck.f2fs.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47691", "url": "https://ubuntu.com/security/CVE-2024-47691", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread() syzbot reports a f2fs bug as below: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_report+0xe8/0x550 mm/kasan/report.c:491 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 instrument_atomic_read_write include/linux/instrumented.h:96 [inline] atomic_fetch_add_relaxed include/linux/atomic/atomic-instrumented.h:252 [inline] __refcount_add include/linux/refcount.h:184 [inline] __refcount_inc include/linux/refcount.h:241 [inline] refcount_inc include/linux/refcount.h:258 [inline] get_task_struct include/linux/sched/task.h:118 [inline] kthread_stop+0xca/0x630 kernel/kthread.c:704 f2fs_stop_gc_thread+0x65/0xb0 fs/f2fs/gc.c:210 f2fs_do_shutdown+0x192/0x540 fs/f2fs/file.c:2283 f2fs_ioc_shutdown fs/f2fs/file.c:2325 [inline] __f2fs_ioctl+0x443a/0xbe60 fs/f2fs/file.c:4325 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f The root cause is below race condition, it may cause use-after-free issue in sbi->gc_th pointer. - remount - f2fs_remount - f2fs_stop_gc_thread - kfree(gc_th) \t\t\t\t- f2fs_ioc_shutdown \t\t\t\t - f2fs_do_shutdown \t\t\t\t - f2fs_stop_gc_thread \t\t\t\t - kthread_stop(gc_th->f2fs_gc_task) : sbi->gc_thread = NULL; We will call f2fs_do_shutdown() in two paths: - for f2fs_ioc_shutdown() path, we should grab sb->s_umount semaphore for fixing. - for f2fs_shutdown() path, it's safe since caller has already grabbed sb->s_umount semaphore.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47692", "url": "https://ubuntu.com/security/CVE-2024-47692", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: return -EINVAL when namelen is 0 When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may result in namelen being 0, which will cause memdup_user() to return ZERO_SIZE_PTR. When we access the name.data that has been assigned the value of ZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is triggered. [ T1205] ================================================================== [ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260 [ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205 [ T1205] [ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406 [ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ T1205] Call Trace: [ T1205] dump_stack+0x9a/0xd0 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] __kasan_report.cold+0x34/0x84 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] kasan_report+0x3a/0x50 [ T1205] nfs4_client_to_reclaim+0xe9/0x260 [ T1205] ? nfsd4_release_lockowner+0x410/0x410 [ T1205] cld_pipe_downcall+0x5ca/0x760 [ T1205] ? nfsd4_cld_tracking_exit+0x1d0/0x1d0 [ T1205] ? down_write_killable_nested+0x170/0x170 [ T1205] ? avc_policy_seqno+0x28/0x40 [ T1205] ? selinux_file_permission+0x1b4/0x1e0 [ T1205] rpc_pipe_write+0x84/0xb0 [ T1205] vfs_write+0x143/0x520 [ T1205] ksys_write+0xc9/0x170 [ T1205] ? __ia32_sys_read+0x50/0x50 [ T1205] ? ktime_get_coarse_real_ts64+0xfe/0x110 [ T1205] ? ktime_get_coarse_real_ts64+0xa2/0x110 [ T1205] do_syscall_64+0x33/0x40 [ T1205] entry_SYSCALL_64_after_hwframe+0x67/0xd1 [ T1205] RIP: 0033:0x7fdbdb761bc7 [ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 514 [ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7 [ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008 [ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001 [ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b [ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000 [ T1205] ================================================================== Fix it by checking namelen.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47737", "url": "https://ubuntu.com/security/CVE-2024-47737", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: call cache_put if xdr_reserve_space returns NULL If not enough buffer space available, but idmap_lookup has triggered lookup_fn which calls cache_get and returns successfully. Then we missed to call cache_put here which pairs with cache_get. Reviwed-by: Jeff Layton ", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2023-52917", "url": "https://ubuntu.com/security/CVE-2023-52917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir() The debugfs_create_dir() function returns error pointers. It never returns NULL. So use IS_ERR() to check it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47749", "url": "https://ubuntu.com/security/CVE-2024-47749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Added NULL check for lookup_atid The lookup_atid() function can return NULL if the ATID is invalid or does not exist in the identifier table, which could lead to dereferencing a null pointer without a check in the `act_establish()` and `act_open_rpl()` functions. Add a NULL check to prevent null pointer dereferencing. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47735", "url": "https://ubuntu.com/security/CVE-2024-47735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled Fix missuse of spin_lock_irq()/spin_unlock_irq() when spin_lock_irqsave()/spin_lock_irqrestore() was hold. This was discovered through the lock debugging, and the corresponding log is as follows: raw_local_irq_restore() called with IRQs enabled WARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40 ... Call trace: warn_bogus_irq_restore+0x30/0x40 _raw_spin_unlock_irqrestore+0x84/0xc8 add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2] hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2] hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2] create_qp+0x138/0x258 ib_create_qp_kernel+0x50/0xe8 create_mad_qp+0xa8/0x128 ib_mad_port_open+0x218/0x448 ib_mad_init_device+0x70/0x1f8 add_client_context+0xfc/0x220 enable_device_and_get+0xd0/0x140 ib_register_device.part.0+0xf4/0x1c8 ib_register_device+0x34/0x50 hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2] hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2] __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2] hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47750", "url": "https://ubuntu.com/security/CVE-2024-47750", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix Use-After-Free of rsv_qp on HIP08 Currently rsv_qp is freed before ib_unregister_device() is called on HIP08. During the time interval, users can still dereg MR and rsv_qp will be used in this process, leading to a UAF. Move the release of rsv_qp after calling ib_unregister_device() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47751", "url": "https://ubuntu.com/security/CVE-2024-47751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: kirin: Fix buffer overflow in kirin_pcie_parse_port() Within kirin_pcie_parse_port(), the pcie->num_slots is compared to pcie->gpio_id_reset size (MAX_PCI_SLOTS) which is correct and would lead to an overflow. Thus, fix condition to pcie->num_slots + 1 >= MAX_PCI_SLOTS and move pcie->num_slots increment below the if-statement to avoid out-of-bounds array access. Found by Linux Verification Center (linuxtesting.org) with SVACE. [kwilczynski: commit log]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47693", "url": "https://ubuntu.com/security/CVE-2024-47693", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/core: Fix ib_cache_setup_one error flow cleanup When ib_cache_update return an error, we exit ib_cache_setup_one instantly with no proper cleanup, even though before this we had already successfully done gid_table_setup_one, that results in the kernel WARN below. Do proper cleanup using gid_table_cleanup_one before returning the err in order to fix the issue. WARNING: CPU: 4 PID: 922 at drivers/infiniband/core/cache.c:806 gid_table_release_one+0x181/0x1a0 Modules linked in: CPU: 4 UID: 0 PID: 922 Comm: c_repro Not tainted 6.11.0-rc1+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:gid_table_release_one+0x181/0x1a0 Code: 44 8b 38 75 0c e8 2f cb 34 ff 4d 8b b5 28 05 00 00 e8 23 cb 34 ff 44 89 f9 89 da 4c 89 f6 48 c7 c7 d0 58 14 83 e8 4f de 21 ff <0f> 0b 4c 8b 75 30 e9 54 ff ff ff 48 8 3 c4 10 5b 5d 41 5c 41 5d 41 RSP: 0018:ffffc90002b835b0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c8527 RDX: 0000000000000000 RSI: ffffffff811c8534 RDI: 0000000000000001 RBP: ffff8881011b3d00 R08: ffff88810b3abe00 R09: 205d303839303631 R10: 666572207972746e R11: 72746e6520444947 R12: 0000000000000001 R13: ffff888106390000 R14: ffff8881011f2110 R15: 0000000000000001 FS: 00007fecc3b70800(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000340 CR3: 000000010435a001 CR4: 00000000003706b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? show_regs+0x94/0xa0 ? __warn+0x9e/0x1c0 ? gid_table_release_one+0x181/0x1a0 ? report_bug+0x1f9/0x340 ? gid_table_release_one+0x181/0x1a0 ? handle_bug+0xa2/0x110 ? exc_invalid_op+0x31/0xa0 ? asm_exc_invalid_op+0x16/0x20 ? __warn_printk+0xc7/0x180 ? __warn_printk+0xd4/0x180 ? gid_table_release_one+0x181/0x1a0 ib_device_release+0x71/0xe0 ? __pfx_ib_device_release+0x10/0x10 device_release+0x44/0xd0 kobject_put+0x135/0x3d0 put_device+0x20/0x30 rxe_net_add+0x7d/0xa0 rxe_newlink+0xd7/0x190 nldev_newlink+0x1b0/0x2a0 ? __pfx_nldev_newlink+0x10/0x10 rdma_nl_rcv_msg+0x1ad/0x2e0 rdma_nl_rcv_skb.constprop.0+0x176/0x210 netlink_unicast+0x2de/0x400 netlink_sendmsg+0x306/0x660 __sock_sendmsg+0x110/0x120 ____sys_sendmsg+0x30e/0x390 ___sys_sendmsg+0x9b/0xf0 ? kstrtouint+0x6e/0xa0 ? kstrtouint_from_user+0x7c/0xb0 ? get_pid_task+0xb0/0xd0 ? proc_fail_nth_write+0x5b/0x140 ? __fget_light+0x9a/0x200 ? preempt_count_add+0x47/0xa0 __sys_sendmsg+0x61/0xd0 do_syscall_64+0x50/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47694", "url": "https://ubuntu.com/security/CVE-2024-47694", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mlx5: Fix UMR pd cleanup on error flow of driver init The cited commit moves the pd allocation from function mlx5r_umr_resource_cleanup() to a new function mlx5r_umr_cleanup(). So the fix in commit [1] is broken. In error flow, will hit panic [2]. Fix it by checking pd pointer to avoid panic if it is NULL; [1] RDMA/mlx5: Fix UMR cleanup on error flow of driver init [2] [ 347.567063] infiniband mlx5_0: Couldn't register device with driver model [ 347.591382] BUG: kernel NULL pointer dereference, address: 0000000000000020 [ 347.593438] #PF: supervisor read access in kernel mode [ 347.595176] #PF: error_code(0x0000) - not-present page [ 347.596962] PGD 0 P4D 0 [ 347.601361] RIP: 0010:ib_dealloc_pd_user+0x12/0xc0 [ib_core] [ 347.604171] RSP: 0018:ffff888106293b10 EFLAGS: 00010282 [ 347.604834] RAX: 0000000000000000 RBX: 000000000000000e RCX: 0000000000000000 [ 347.605672] RDX: ffff888106293ad0 RSI: 0000000000000000 RDI: 0000000000000000 [ 347.606529] RBP: 0000000000000000 R08: ffff888106293ae0 R09: ffff888106293ae0 [ 347.607379] R10: 0000000000000a06 R11: 0000000000000000 R12: 0000000000000000 [ 347.608224] R13: ffffffffa0704dc0 R14: 0000000000000001 R15: 0000000000000001 [ 347.609067] FS: 00007fdc720cd9c0(0000) GS:ffff88852c880000(0000) knlGS:0000000000000000 [ 347.610094] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 347.610727] CR2: 0000000000000020 CR3: 0000000103012003 CR4: 0000000000370eb0 [ 347.611421] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 347.612113] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 347.612804] Call Trace: [ 347.613130] [ 347.613417] ? __die+0x20/0x60 [ 347.613793] ? page_fault_oops+0x150/0x3e0 [ 347.614243] ? free_msg+0x68/0x80 [mlx5_core] [ 347.614840] ? cmd_exec+0x48f/0x11d0 [mlx5_core] [ 347.615359] ? exc_page_fault+0x74/0x130 [ 347.615808] ? asm_exc_page_fault+0x22/0x30 [ 347.616273] ? ib_dealloc_pd_user+0x12/0xc0 [ib_core] [ 347.616801] mlx5r_umr_cleanup+0x23/0x90 [mlx5_ib] [ 347.617365] mlx5_ib_stage_pre_ib_reg_umr_cleanup+0x36/0x40 [mlx5_ib] [ 347.618025] __mlx5_ib_add+0x96/0xd0 [mlx5_ib] [ 347.618539] mlx5r_probe+0xe9/0x310 [mlx5_ib] [ 347.619032] ? kernfs_add_one+0x107/0x150 [ 347.619478] ? __mlx5_ib_add+0xd0/0xd0 [mlx5_ib] [ 347.619984] auxiliary_bus_probe+0x3e/0x90 [ 347.620448] really_probe+0xc5/0x3a0 [ 347.620857] __driver_probe_device+0x80/0x160 [ 347.621325] driver_probe_device+0x1e/0x90 [ 347.621770] __driver_attach+0xec/0x1c0 [ 347.622213] ? __device_attach_driver+0x100/0x100 [ 347.622724] bus_for_each_dev+0x71/0xc0 [ 347.623151] bus_add_driver+0xed/0x240 [ 347.623570] driver_register+0x58/0x100 [ 347.623998] __auxiliary_driver_register+0x6a/0xc0 [ 347.624499] ? driver_register+0xae/0x100 [ 347.624940] ? 0xffffffffa0893000 [ 347.625329] mlx5_ib_init+0x16a/0x1e0 [mlx5_ib] [ 347.625845] do_one_initcall+0x4a/0x2a0 [ 347.626273] ? gcov_event+0x2e2/0x3a0 [ 347.626706] do_init_module+0x8a/0x260 [ 347.627126] init_module_from_file+0x8b/0xd0 [ 347.627596] __x64_sys_finit_module+0x1ca/0x2f0 [ 347.628089] do_syscall_64+0x4c/0x100", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47695", "url": "https://ubuntu.com/security/CVE-2024-47695", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds In the function init_conns(), after the create_con() and create_cm() for loop if something fails. In the cleanup for loop after the destroy tag, we access out of bound memory because cid is set to clt_path->s.con_num. This commits resets the cid to clt_path->s.con_num - 1, to stay in bounds in the cleanup loop later.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47752", "url": "https://ubuntu.com/security/CVE-2024-47752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix H264 stateless decoder smatch warning Fix a smatch static checker warning on vdec_h264_req_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47753", "url": "https://ubuntu.com/security/CVE-2024-47753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix VP8 stateless decoder smatch warning Fix a smatch static checker warning on vdec_vp8_req_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47754", "url": "https://ubuntu.com/security/CVE-2024-47754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix H264 multi stateless decoder smatch warning Fix a smatch static checker warning on vdec_h264_req_multi_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47696", "url": "https://ubuntu.com/security/CVE-2024-47696", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency In the commit aee2424246f9 (\"RDMA/iwcm: Fix a use-after-free related to destroying CM IDs\"), the function flush_workqueue is invoked to flush the work queue iwcm_wq. But at that time, the work queue iwcm_wq was created via the function alloc_ordered_workqueue without the flag WQ_MEM_RECLAIM. Because the current process is trying to flush the whole iwcm_wq, if iwcm_wq doesn't have the flag WQ_MEM_RECLAIM, verify that the current process is not reclaiming memory or running on a workqueue which doesn't have the flag WQ_MEM_RECLAIM as that can break forward-progress guarantee leading to a deadlock. The call trace is as below: [ 125.350876][ T1430] Call Trace: [ 125.356281][ T1430] [ 125.361285][ T1430] ? __warn (kernel/panic.c:693) [ 125.367640][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.375689][ T1430] ? report_bug (lib/bug.c:180 lib/bug.c:219) [ 125.382505][ T1430] ? handle_bug (arch/x86/kernel/traps.c:239) [ 125.388987][ T1430] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) [ 125.395831][ T1430] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621) [ 125.403125][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.410984][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.418764][ T1430] __flush_workqueue (kernel/workqueue.c:3970) [ 125.426021][ T1430] ? __pfx___might_resched (kernel/sched/core.c:10151) [ 125.433431][ T1430] ? destroy_cm_id (drivers/infiniband/core/iwcm.c:375) iw_cm [ 125.441209][ T1430] ? __pfx___flush_workqueue (kernel/workqueue.c:3910) [ 125.473900][ T1430] ? _raw_spin_lock_irqsave (arch/x86/include/asm/atomic.h:107 include/linux/atomic/atomic-arch-fallback.h:2170 include/linux/atomic/atomic-instrumented.h:1302 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162) [ 125.473909][ T1430] ? __pfx__raw_spin_lock_irqsave (kernel/locking/spinlock.c:161) [ 125.482537][ T1430] _destroy_id (drivers/infiniband/core/cma.c:2044) rdma_cm [ 125.495072][ T1430] nvme_rdma_free_queue (drivers/nvme/host/rdma.c:656 drivers/nvme/host/rdma.c:650) nvme_rdma [ 125.505827][ T1430] nvme_rdma_reset_ctrl_work (drivers/nvme/host/rdma.c:2180) nvme_rdma [ 125.505831][ T1430] process_one_work (kernel/workqueue.c:3231) [ 125.515122][ T1430] worker_thread (kernel/workqueue.c:3306 kernel/workqueue.c:3393) [ 125.515127][ T1430] ? __pfx_worker_thread (kernel/workqueue.c:3339) [ 125.531837][ T1430] kthread (kernel/kthread.c:389) [ 125.539864][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.550628][ T1430] ret_from_fork (arch/x86/kernel/process.c:147) [ 125.558840][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.558844][ T1430] ret_from_fork_asm (arch/x86/entry/entry_64.S:257) [ 125.566487][ T1430] [ 125.566488][ T1430] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47755", "url": "https://ubuntu.com/security/CVE-2024-47755", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47756", "url": "https://ubuntu.com/security/CVE-2024-47756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: keystone: Fix if-statement expression in ks_pcie_quirk() This code accidentally uses && where || was intended. It potentially results in a NULL dereference. Thus, fix the if-statement expression to use the correct condition. [kwilczynski: commit log]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47697", "url": "https://ubuntu.com/security/CVE-2024-47697", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error Ensure index in rtl2830_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47698", "url": "https://ubuntu.com/security/CVE-2024-47698", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error Ensure index in rtl2832_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue. [hverkuil: added fixes tag, rtl2830_pid_filter -> rtl2832_pid_filter in logmsg]", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47728", "url": "https://ubuntu.com/security/CVE-2024-47728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error For all non-tracing helpers which formerly had ARG_PTR_TO_{LONG,INT} as input arguments, zero the value for the case of an error as otherwise it could leak memory. For tracing, it is not needed given CAP_PERFMON can already read all kernel memory anyway hence bpf_get_func_arg() and bpf_get_func_ret() is skipped in here. Also, the MTU helpers mtu_len pointer value is being written but also read. Technically, the MEM_UNINIT should not be there in order to always force init. Removing MEM_UNINIT needs more verifier rework though: MEM_UNINIT right now implies two things actually: i) write into memory, ii) memory does not have to be initialized. If we lift MEM_UNINIT, it then becomes: i) read into memory, ii) memory must be initialized. This means that for bpf_*_check_mtu() we're readding the issue we're trying to fix, that is, it would then be able to write back into things like .rodata BPF maps. Follow-up work will rework the MEM_UNINIT semantics such that the intent can be better expressed. For now just clear the *mtu_len on error path which can be lifted later again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49861", "url": "https://ubuntu.com/security/CVE-2024-49861", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix helper writes to read-only maps Lonial found an issue that despite user- and BPF-side frozen BPF map (like in case of .rodata), it was still possible to write into it from a BPF program side through specific helpers having ARG_PTR_TO_{LONG,INT} as arguments. In check_func_arg() when the argument is as mentioned, the meta->raw_mode is never set. Later, check_helper_mem_access(), under the case of PTR_TO_MAP_VALUE as register base type, it assumes BPF_READ for the subsequent call to check_map_access_type() and given the BPF map is read-only it succeeds. The helpers really need to be annotated as ARG_PTR_TO_{LONG,INT} | MEM_UNINIT when results are written into them as opposed to read out of them. The latter indicates that it's okay to pass a pointer to uninitialized memory as the memory is written to anyway. However, ARG_PTR_TO_{LONG,INT} is a special case of ARG_PTR_TO_FIXED_SIZE_MEM just with additional alignment requirement. So it is better to just get rid of the ARG_PTR_TO_{LONG,INT} special cases altogether and reuse the fixed size memory types. For this, add MEM_ALIGNED to additionally ensure alignment given these helpers write directly into the args via * = val. The .arg*_size has been initialized reflecting the actual sizeof(*). MEM_ALIGNED can only be used in combination with MEM_FIXED_SIZE annotated argument types, since in !MEM_FIXED_SIZE cases the verifier does not know the buffer size a priori and therefore cannot blindly write * = val.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47757", "url": "https://ubuntu.com/security/CVE-2024-47757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential oob read in nilfs_btree_check_delete() The function nilfs_btree_check_delete(), which checks whether degeneration to direct mapping occurs before deleting a b-tree entry, causes memory access outside the block buffer when retrieving the maximum key if the root node has no entries. This does not usually happen because b-tree mappings with 0 child nodes are never created by mkfs.nilfs2 or nilfs2 itself. However, it can happen if the b-tree root node read from a device is configured that way, so fix this potential issue by adding a check for that case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47699", "url": "https://ubuntu.com/security/CVE-2024-47699", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential null-ptr-deref in nilfs_btree_insert() Patch series \"nilfs2: fix potential issues with empty b-tree nodes\". This series addresses three potential issues with empty b-tree nodes that can occur with corrupted filesystem images, including one recently discovered by syzbot. This patch (of 3): If a b-tree is broken on the device, and the b-tree height is greater than 2 (the level of the root node is greater than 1) even if the number of child nodes of the b-tree root is 0, a NULL pointer dereference occurs in nilfs_btree_prepare_insert(), which is called from nilfs_btree_insert(). This is because, when the number of child nodes of the b-tree root is 0, nilfs_btree_do_lookup() does not set the block buffer head in any of path[x].bp_bh, leaving it as the initial value of NULL, but if the level of the b-tree root node is greater than 1, nilfs_btree_get_nonroot_node(), which accesses the buffer memory of path[x].bp_bh, is called. Fix this issue by adding a check to nilfs_btree_root_broken(), which performs sanity checks when reading the root node from the device, to detect this inconsistency. Thanks to Lizhi Xu for trying to solve the bug and clarifying the cause early on.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47700", "url": "https://ubuntu.com/security/CVE-2024-47700", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: check stripe size compatibility on remount as well We disable stripe size in __ext4_fill_super if it is not a multiple of the cluster ratio however this check is missed when trying to remount. This can leave us with cases where stripe < cluster_ratio after remount:set making EXT4_B2C(sbi->s_stripe) become 0 that can cause some unforeseen bugs like divide by 0. Fix that by adding the check in remount path as well.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47701", "url": "https://ubuntu.com/security/CVE-2024-47701", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid OOB when system.data xattr changes underneath the filesystem When looking up for an entry in an inlined directory, if e_value_offs is changed underneath the filesystem by some change in the block device, it will lead to an out-of-bounds access that KASAN detects as an UAF. EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none. loop0: detected capacity change from 2048 to 2047 ================================================================== BUG: KASAN: use-after-free in ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 Read of size 1 at addr ffff88803e91130f by task syz-executor269/5103 CPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 Not tainted 6.11.0-rc4-syzkaller #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:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 ext4_find_inline_entry+0x4be/0x5e0 fs/ext4/inline.c:1697 __ext4_find_entry+0x2b4/0x1b30 fs/ext4/namei.c:1573 ext4_lookup_entry fs/ext4/namei.c:1727 [inline] ext4_lookup+0x15f/0x750 fs/ext4/namei.c:1795 lookup_one_qstr_excl+0x11f/0x260 fs/namei.c:1633 filename_create+0x297/0x540 fs/namei.c:3980 do_symlinkat+0xf9/0x3a0 fs/namei.c:4587 __do_sys_symlinkat fs/namei.c:4610 [inline] __se_sys_symlinkat fs/namei.c:4607 [inline] __x64_sys_symlinkat+0x95/0xb0 fs/namei.c:4607 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:0x7f3e73ced469 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff4d40c258 EFLAGS: 00000246 ORIG_RAX: 000000000000010a RAX: ffffffffffffffda RBX: 0032656c69662f2e RCX: 00007f3e73ced469 RDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0 RBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290 R10: 0023706f6f6c2f76 R11: 0000000000000246 R12: 00007fff4d40c27c R13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0 Calling ext4_xattr_ibody_find right after reading the inode with ext4_get_inode_loc will lead to a check of the validity of the xattrs, avoiding this problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49850", "url": "https://ubuntu.com/security/CVE-2024-49850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: correctly handle malformed BPF_CORE_TYPE_ID_LOCAL relos In case of malformed relocation record of kind BPF_CORE_TYPE_ID_LOCAL referencing a non-existing BTF type, function bpf_core_calc_relo_insn would cause a null pointer deference. Fix this by adding a proper check upper in call stack, as malformed relocation records could be passed from user space. Simplest reproducer is a program: r0 = 0 exit With a single relocation record: .insn_off = 0, /* patch first instruction */ .type_id = 100500, /* this type id does not exist */ .access_str_off = 6, /* offset of string \"0\" */ .kind = BPF_CORE_TYPE_ID_LOCAL, See the link for original reproducer or next commit for a test case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47702", "url": "https://ubuntu.com/security/CVE-2024-47702", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fail verification for sign-extension of packet data/data_end/data_meta syzbot reported a kernel crash due to commit 1f1e864b6555 (\"bpf: Handle sign-extenstin ctx member accesses\"). The reason is due to sign-extension of 32-bit load for packet data/data_end/data_meta uapi field. The original code looks like: r2 = *(s32 *)(r1 + 76) /* load __sk_buff->data */ r3 = *(u32 *)(r1 + 80) /* load __sk_buff->data_end */ r0 = r2 r0 += 8 if r3 > r0 goto +1 ... Note that __sk_buff->data load has 32-bit sign extension. After verification and convert_ctx_accesses(), the final asm code looks like: r2 = *(u64 *)(r1 +208) r2 = (s32)r2 r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 ... Note that 'r2 = (s32)r2' may make the kernel __sk_buff->data address invalid which may cause runtime failure. Currently, in C code, typically we have void *data = (void *)(long)skb->data; void *data_end = (void *)(long)skb->data_end; ... and it will generate r2 = *(u64 *)(r1 +208) r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 If we allow sign-extension, void *data = (void *)(long)(int)skb->data; void *data_end = (void *)(long)skb->data_end; ... the generated code looks like r2 = *(u64 *)(r1 +208) r2 <<= 32 r2 s>>= 32 r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 and this will cause verification failure since \"r2 <<= 32\" is not allowed as \"r2\" is a packet pointer. To fix this issue for case r2 = *(s32 *)(r1 + 76) /* load __sk_buff->data */ this patch added additional checking in is_valid_access() callback function for packet data/data_end/data_meta access. If those accesses are with sign-extenstion, the verification will fail. [1] https://lore.kernel.org/bpf/000000000000c90eee061d236d37@google.com/", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47703", "url": "https://ubuntu.com/security/CVE-2024-47703", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, lsm: Add check for BPF LSM return value A bpf prog returning a positive number attached to file_alloc_security hook makes kernel panic. This happens because file system can not filter out the positive number returned by the LSM prog using IS_ERR, and misinterprets this positive number as a file pointer. Given that hook file_alloc_security never returned positive number before the introduction of BPF LSM, and other BPF LSM hooks may encounter similar issues, this patch adds LSM return value check in verifier, to ensure no unexpected value is returned.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49851", "url": "https://ubuntu.com/security/CVE-2024-49851", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: Clean up TPM space after command failure tpm_dev_transmit prepares the TPM space before attempting command transmission. However if the command fails no rollback of this preparation is done. This can result in transient handles being leaked if the device is subsequently closed with no further commands performed. Fix this by flushing the space in the event of command transmission failure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47723", "url": "https://ubuntu.com/security/CVE-2024-47723", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: fix out-of-bounds in dbNextAG() and diAlloc() In dbNextAG() , there is no check for the case where bmp->db_numag is greater or same than MAXAG due to a polluted image, which causes an out-of-bounds. Therefore, a bounds check should be added in dbMount(). And in dbNextAG(), a check for the case where agpref is greater than bmp->db_numag should be added, so an out-of-bounds exception should be prevented. Additionally, a check for the case where agno is greater or same than MAXAG should be added in diAlloc() to prevent out-of-bounds.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49852", "url": "https://ubuntu.com/security/CVE-2024-49852", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: elx: libefc: Fix potential use after free in efc_nport_vport_del() The kref_put() function will call nport->release if the refcount drops to zero. The nport->release release function is _efc_nport_free() which frees \"nport\". But then we dereference \"nport\" on the next line which is a use after free. Re-order these lines to avoid the use after free.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47720", "url": "https://ubuntu.com/security/CVE-2024-47720", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for set_output_gamma in dcn30_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn30_set_output_transfer_func function. Previously, set_output_gamma was being checked for nullity at line 386, but then it was being dereferenced without any nullity check at line 401. This could potentially lead to a null pointer dereference error if set_output_gamma is indeed null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a nullity check for set_output_gamma before the call to set_output_gamma at line 401. If set_output_gamma is null, we log an error message and do not call the function. This fix prevents a potential null pointer dereference error. drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:401 dcn30_set_output_transfer_func() error: we previously assumed 'mpc->funcs->set_output_gamma' could be null (see line 386) drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c 373 bool dcn30_set_output_transfer_func(struct dc *dc, 374 struct pipe_ctx *pipe_ctx, 375 const struct dc_stream_state *stream) 376 { 377 int mpcc_id = pipe_ctx->plane_res.hubp->inst; 378 struct mpc *mpc = pipe_ctx->stream_res.opp->ctx->dc->res_pool->mpc; 379 const struct pwl_params *params = NULL; 380 bool ret = false; 381 382 /* program OGAM or 3DLUT only for the top pipe*/ 383 if (pipe_ctx->top_pipe == NULL) { 384 /*program rmu shaper and 3dlut in MPC*/ 385 ret = dcn30_set_mpc_shaper_3dlut(pipe_ctx, stream); 386 if (ret == false && mpc->funcs->set_output_gamma) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If this is NULL 387 if (stream->out_transfer_func.type == TF_TYPE_HWPWL) 388 params = &stream->out_transfer_func.pwl; 389 else if (pipe_ctx->stream->out_transfer_func.type == 390 TF_TYPE_DISTRIBUTED_POINTS && 391 cm3_helper_translate_curve_to_hw_format( 392 &stream->out_transfer_func, 393 &mpc->blender_params, false)) 394 params = &mpc->blender_params; 395 /* there are no ROM LUTs in OUTGAM */ 396 if (stream->out_transfer_func.type == TF_TYPE_PREDEFINED) 397 BREAK_TO_DEBUGGER(); 398 } 399 } 400 --> 401 mpc->funcs->set_output_gamma(mpc, mpcc_id, params); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Then it will crash 402 return ret; 403 }", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47704", "url": "https://ubuntu.com/security/CVE-2024-47704", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check link_res->hpo_dp_link_enc before using it [WHAT & HOW] Functions dp_enable_link_phy and dp_disable_link_phy can pass link_res without initializing hpo_dp_link_enc and it is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49853", "url": "https://ubuntu.com/security/CVE-2024-49853", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix double free in OPTEE transport Channels can be shared between protocols, avoid freeing the same channel descriptors twice when unloading the stack.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47705", "url": "https://ubuntu.com/security/CVE-2024-47705", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix potential invalid pointer dereference in blk_add_partition The blk_add_partition() function initially used a single if-condition (IS_ERR(part)) to check for errors when adding a partition. This was modified to handle the specific case of -ENXIO separately, allowing the function to proceed without logging the error in this case. However, this change unintentionally left a path where md_autodetect_dev() could be called without confirming that part is a valid pointer. This commit separates the error handling logic by splitting the initial if-condition, improving code readability and handling specific error scenarios explicitly. The function now distinguishes the general error case from -ENXIO without altering the existing behavior of md_autodetect_dev() calls.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47736", "url": "https://ubuntu.com/security/CVE-2024-47736", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: handle overlapped pclusters out of crafted images properly syzbot reported a task hang issue due to a deadlock case where it is waiting for the folio lock of a cached folio that will be used for cache I/Os. After looking into the crafted fuzzed image, I found it's formed with several overlapped big pclusters as below: Ext: logical offset | length : physical offset | length 0: 0.. 16384 | 16384 : 151552.. 167936 | 16384 1: 16384.. 32768 | 16384 : 155648.. 172032 | 16384 2: 32768.. 49152 | 16384 : 537223168.. 537239552 | 16384 ... Here, extent 0/1 are physically overlapped although it's entirely _impossible_ for normal filesystem images generated by mkfs. First, managed folios containing compressed data will be marked as up-to-date and then unlocked immediately (unlike in-place folios) when compressed I/Os are complete. If physical blocks are not submitted in the incremental order, there should be separate BIOs to avoid dependency issues. However, the current code mis-arranges z_erofs_fill_bio_vec() and BIO submission which causes unexpected BIO waits. Second, managed folios will be connected to their own pclusters for efficient inter-queries. However, this is somewhat hard to implement easily if overlapped big pclusters exist. Again, these only appear in fuzzed images so let's simply fall back to temporary short-lived pages for correctness. Additionally, it justifies that referenced managed folios cannot be truncated for now and reverts part of commit 2080ca1ed3e4 (\"erofs: tidy up `struct z_erofs_bvec`\") for simplicity although it shouldn't be any difference.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47706", "url": "https://ubuntu.com/security/CVE-2024-47706", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block, bfq: fix possible UAF for bfqq->bic with merge chain 1) initial state, three tasks: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t\t | ? | ?\t\t | ? \t\t | | | |\t\t | | \t\t V | V |\t\t V | \t\t bfqq1 bfqq2\t\t bfqq3 process ref:\t 1\t\t 1\t\t 1 2) bfqq1 merged to bfqq2: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t\t | |\t\t | ? \t\t \\--------------\\|\t\t | | \t\t V\t\t V | \t\t bfqq1--------->bfqq2\t\t bfqq3 process ref:\t 0\t\t 2\t\t 1 3) bfqq2 merged to bfqq3: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t here -> ? |\t\t | \t\t \\--------------\\ \\-------------\\| \t\t V\t\t V \t\t bfqq1--------->bfqq2---------->bfqq3 process ref:\t 0\t\t 1\t\t 3 In this case, IO from Process 1 will get bfqq2 from BIC1 first, and then get bfqq3 through merge chain, and finially handle IO by bfqq3. Howerver, current code will think bfqq2 is owned by BIC1, like initial state, and set bfqq2->bic to BIC1. bfq_insert_request -> by Process 1 bfqq = bfq_init_rq(rq) bfqq = bfq_get_bfqq_handle_split bfqq = bic_to_bfqq -> get bfqq2 from BIC1 bfqq->ref++ rq->elv.priv[0] = bic rq->elv.priv[1] = bfqq if (bfqq_process_refs(bfqq) == 1) bfqq->bic = bic -> record BIC1 to bfqq2 __bfq_insert_request new_bfqq = bfq_setup_cooperator -> get bfqq3 from bfqq2->new_bfqq bfqq_request_freed(bfqq) new_bfqq->ref++ rq->elv.priv[1] = new_bfqq -> handle IO by bfqq3 Fix the problem by checking bfqq is from merge chain fist. And this might fix a following problem reported by our syzkaller(unreproducible): ================================================================== BUG: KASAN: slab-use-after-free in bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] BUG: KASAN: slab-use-after-free in bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] BUG: KASAN: slab-use-after-free in bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 Write of size 1 at addr ffff888123839eb8 by task kworker/0:1H/18595 CPU: 0 PID: 18595 Comm: kworker/0:1H Tainted: G L 6.6.0-07439-gba2303cacfda #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Workqueue: kblockd blk_mq_requeue_work Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [inline] print_report+0x10d/0x610 mm/kasan/report.c:475 kasan_report+0x8e/0xc0 mm/kasan/report.c:588 bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 bfq_get_bfqq_handle_split+0x169/0x5d0 block/bfq-iosched.c:6757 bfq_init_rq block/bfq-iosched.c:6876 [inline] bfq_insert_request block/bfq-iosched.c:6254 [inline] bfq_insert_requests+0x1112/0x5cf0 block/bfq-iosched.c:6304 blk_mq_insert_request+0x290/0x8d0 block/blk-mq.c:2593 blk_mq_requeue_work+0x6bc/0xa70 block/blk-mq.c:1502 process_one_work kernel/workqueue.c:2627 [inline] process_scheduled_works+0x432/0x13f0 kernel/workqueue.c:2700 worker_thread+0x6f2/0x1160 kernel/workqueue.c:2781 kthread+0x33c/0x440 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:305 Allocated by task 20776: kasan_save_stack+0x20/0x40 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 __kasan_slab_alloc+0x87/0x90 mm/kasan/common.c:328 kasan_slab_alloc include/linux/kasan.h:188 [inline] slab_post_alloc_hook mm/slab.h:763 [inline] slab_alloc_node mm/slub.c:3458 [inline] kmem_cache_alloc_node+0x1a4/0x6f0 mm/slub.c:3503 ioc_create_icq block/blk-ioc.c:370 [inline] ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49855", "url": "https://ubuntu.com/security/CVE-2024-49855", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: fix race between timeout and normal completion If request timetout is handled by nbd_requeue_cmd(), normal completion has to be stopped for avoiding to complete this requeued request, other use-after-free can be triggered. Fix the race by clearing NBD_CMD_INFLIGHT in nbd_requeue_cmd(), meantime make sure that cmd->lock is grabbed for clearing the flag and the requeue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47707", "url": "https://ubuntu.com/security/CVE-2024-47707", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev() Blamed commit accidentally removed a check for rt->rt6i_idev being NULL, as spotted by syzbot: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 UID: 0 PID: 10998 Comm: syz-executor Not tainted 6.11.0-rc6-syzkaller-00208-g625403177711 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 RBP: ffffc900047375d0 R08: 0000000000000003 R09: fffff520008e6e8c R10: dffffc0000000000 R11: fffff520008e6e8c R12: 1ffff1100fdf8f18 R13: ffff88807efc7998 R14: 0000000000000000 R15: ffff88807efc7930 FS: 0000000000000000(0000) GS:ffff8880b8900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020002a80 CR3: 0000000022f62000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: addrconf_ifdown+0x15d/0x1bd0 net/ipv6/addrconf.c:3856 addrconf_notify+0x3cb/0x1020 notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93 call_netdevice_notifiers_extack net/core/dev.c:2032 [inline] call_netdevice_notifiers net/core/dev.c:2046 [inline] unregister_netdevice_many_notify+0xd81/0x1c40 net/core/dev.c:11352 unregister_netdevice_many net/core/dev.c:11414 [inline] unregister_netdevice_queue+0x303/0x370 net/core/dev.c:11289 unregister_netdevice include/linux/netdevice.h:3129 [inline] __tun_detach+0x6b9/0x1600 drivers/net/tun.c:685 tun_detach drivers/net/tun.c:701 [inline] tun_chr_close+0x108/0x1b0 drivers/net/tun.c:3510 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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:0x7f1acc77def9 Code: Unable to access opcode bytes at 0x7f1acc77decf. RSP: 002b:00007ffeb26fa738 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1acc77def9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000043 RBP: 00007f1acc7dd508 R08: 00007ffeb26f84d7 R09: 0000000000000003 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 0000000000000003 R14: 00000000ffffffff R15: 00007ffeb26fa8e0 Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 R ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47708", "url": "https://ubuntu.com/security/CVE-2024-47708", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netkit: Assign missing bpf_net_context During the introduction of struct bpf_net_context handling for XDP-redirect, the netkit driver has been missed, which also requires it because NETKIT_REDIRECT invokes skb_do_redirect() which is accessing the per-CPU variables. Otherwise we see the following crash: \tBUG: kernel NULL pointer dereference, address: 0000000000000038 \tbpf_redirect() \tnetkit_xmit() \tdev_hard_start_xmit() Set the bpf_net_context before invoking netkit_xmit() program within the netkit driver.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47709", "url": "https://ubuntu.com/security/CVE-2024-47709", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: Clear bo->bcm_proc_read after remove_proc_entry(). syzbot reported a warning in bcm_release(). [0] The blamed change fixed another warning that is triggered when connect() is issued again for a socket whose connect()ed device has been unregistered. However, if the socket is just close()d without the 2nd connect(), the remaining bo->bcm_proc_read triggers unnecessary remove_proc_entry() in bcm_release(). Let's clear bo->bcm_proc_read after remove_proc_entry() in bcm_notify(). [0] name '4986' WARNING: CPU: 0 PID: 5234 at fs/proc/generic.c:711 remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Modules linked in: CPU: 0 UID: 0 PID: 5234 Comm: syz-executor606 Not tainted 6.11.0-rc5-syzkaller-00178-g5517ae241919 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Code: ff eb 05 e8 cb 1e 5e ff 48 8b 5c 24 10 48 c7 c7 e0 f7 aa 8e e8 2a 38 8e 09 90 48 c7 c7 60 3a 1b 8c 48 89 de e8 da 42 20 ff 90 <0f> 0b 90 90 48 8b 44 24 18 48 c7 44 24 40 0e 36 e0 45 49 c7 04 07 RSP: 0018:ffffc9000345fa20 EFLAGS: 00010246 RAX: 2a2d0aee2eb64600 RBX: ffff888032f1f548 RCX: ffff888029431e00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000345fb08 R08: ffffffff8155b2f2 R09: 1ffff1101710519a R10: dffffc0000000000 R11: ffffed101710519b R12: ffff888011d38640 R13: 0000000000000004 R14: 0000000000000000 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8880b8800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcfb52722f0 CR3: 000000000e734000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: bcm_release+0x250/0x880 net/can/bcm.c:1578 __sock_release net/socket.c:659 [inline] sock_close+0xbc/0x240 net/socket.c:1421 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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:0x7fcfb51ee969 Code: Unable to access opcode bytes at 0x7fcfb51ee93f. RSP: 002b:00007ffce0109ca8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fcfb51ee969 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 00007fcfb526f3b0 R08: ffffffffffffffb8 R09: 0000555500000000 R10: 0000555500000000 R11: 0000000000000246 R12: 00007fcfb526f3b0 R13: 0000000000000000 R14: 00007fcfb5271ee0 R15: 00007fcfb51bf160 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47710", "url": "https://ubuntu.com/security/CVE-2024-47710", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sock_map: Add a cond_resched() in sock_hash_free() Several syzbot soft lockup reports all have in common sock_hash_free() If a map with a large number of buckets is destroyed, we need to yield the cpu when needed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47711", "url": "https://ubuntu.com/security/CVE-2024-47711", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Don't return OOB skb in manage_oob(). syzbot reported use-after-free in unix_stream_recv_urg(). [0] The scenario is 1. send(MSG_OOB) 2. recv(MSG_OOB) -> The consumed OOB remains in recv queue 3. send(MSG_OOB) 4. recv() -> manage_oob() returns the next skb of the consumed OOB -> This is also OOB, but unix_sk(sk)->oob_skb is not cleared 5. recv(MSG_OOB) -> unix_sk(sk)->oob_skb is used but already freed The recent commit 8594d9b85c07 (\"af_unix: Don't call skb_get() for OOB skb.\") uncovered the issue. If the OOB skb is consumed and the next skb is peeked in manage_oob(), we still need to check if the skb is OOB. Let's do so by falling back to the following checks in manage_oob() and add the test case in selftest. Note that we need to add a similar check for SIOCATMARK. [0]: BUG: KASAN: slab-use-after-free in unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959 Read of size 4 at addr ffff8880326abcc4 by task syz-executor178/5235 CPU: 0 UID: 0 PID: 5235 Comm: syz-executor178 Not tainted 6.11.0-rc5-syzkaller-00742-gfbdaffe41adc #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959 unix_stream_recv_urg+0x1df/0x320 net/unix/af_unix.c:2640 unix_stream_read_generic+0x2456/0x2520 net/unix/af_unix.c:2778 unix_stream_recvmsg+0x22b/0x2c0 net/unix/af_unix.c:2996 sock_recvmsg_nosec net/socket.c:1046 [inline] sock_recvmsg+0x22f/0x280 net/socket.c:1068 ____sys_recvmsg+0x1db/0x470 net/socket.c:2816 ___sys_recvmsg net/socket.c:2858 [inline] __sys_recvmsg+0x2f0/0x3e0 net/socket.c:2888 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:0x7f5360d6b4e9 Code: 48 83 c4 28 c3 e8 37 17 00 00 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff29b3a458 EFLAGS: 00000246 ORIG_RAX: 000000000000002f RAX: ffffffffffffffda RBX: 00007fff29b3a638 RCX: 00007f5360d6b4e9 RDX: 0000000000002001 RSI: 0000000020000640 RDI: 0000000000000003 RBP: 00007f5360dde610 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 00007fff29b3a628 R14: 0000000000000001 R15: 0000000000000001 Allocated by task 5235: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:312 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slub.c:3988 [inline] slab_alloc_node mm/slub.c:4037 [inline] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4080 __alloc_skb+0x1c3/0x440 net/core/skbuff.c:667 alloc_skb include/linux/skbuff.h:1320 [inline] alloc_skb_with_frags+0xc3/0x770 net/core/skbuff.c:6528 sock_alloc_send_pskb+0x91a/0xa60 net/core/sock.c:2815 sock_alloc_send_skb include/net/sock.h:1778 [inline] queue_oob+0x108/0x680 net/unix/af_unix.c:2198 unix_stream_sendmsg+0xd24/0xf80 net/unix/af_unix.c:2351 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2680 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 Freed by task 5235: kasan_save_stack mm/kasan/common.c:47 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47712", "url": "https://ubuntu.com/security/CVE-2024-47712", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: fix potential RCU dereference issue in wilc_parse_join_bss_param In the `wilc_parse_join_bss_param` function, the TSF field of the `ies` structure is accessed after the RCU read-side critical section is unlocked. According to RCU usage rules, this is illegal. Reusing this pointer can lead to unpredictable behavior, including accessing memory that has been updated or causing use-after-free issues. This possible bug was identified using a static analysis tool developed by myself, specifically designed to detect RCU-related issues. To address this, the TSF value is now stored in a local variable `ies_tsf` before the RCU lock is released. The `param->tsf_lo` field is then assigned using this local variable, ensuring that the TSF value is safely accessed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47713", "url": "https://ubuntu.com/security/CVE-2024-47713", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop() Since '__dev_queue_xmit()' should be called with interrupts enabled, the following backtrace: ieee80211_do_stop() ... spin_lock_irqsave(&local->queue_stop_reason_lock, flags) ... ieee80211_free_txskb() ieee80211_report_used_skb() ieee80211_report_ack_skb() cfg80211_mgmt_tx_status_ext() nl80211_frame_tx_status() genlmsg_multicast_netns() genlmsg_multicast_netns_filtered() nlmsg_multicast_filtered() \t netlink_broadcast_filtered() \t do_one_broadcast() \t netlink_broadcast_deliver() \t __netlink_sendskb() \t netlink_deliver_tap() \t __netlink_deliver_tap_skb() \t dev_queue_xmit() \t __dev_queue_xmit() ; with IRQS disabled ... spin_unlock_irqrestore(&local->queue_stop_reason_lock, flags) issues the warning (as reported by syzbot reproducer): WARNING: CPU: 2 PID: 5128 at kernel/softirq.c:362 __local_bh_enable_ip+0xc3/0x120 Fix this by implementing a two-phase skb reclamation in 'ieee80211_do_stop()', where actual work is performed outside of a section with interrupts disabled.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47730", "url": "https://ubuntu.com/security/CVE-2024-47730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/qm - inject error before stopping queue The master ooo cannot be completely closed when the accelerator core reports memory error. Therefore, the driver needs to inject the qm error to close the master ooo. Currently, the qm error is injected after stopping queue, memory may be released immediately after stopping queue, causing the device to access the released memory. Therefore, error is injected to close master ooo before stopping queue to ensure that the device does not access the released memory.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49856", "url": "https://ubuntu.com/security/CVE-2024-49856", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/sgx: Fix deadlock in SGX NUMA node search When the current node doesn't have an EPC section configured by firmware and all other EPC sections are used up, CPU can get stuck inside the while loop that looks for an available EPC page from remote nodes indefinitely, leading to a soft lockup. Note how nid_of_current will never be equal to nid in that while loop because nid_of_current is not set in sgx_numa_mask. Also worth mentioning is that it's perfectly fine for the firmware not to setup an EPC section on a node. While setting up an EPC section on each node can enhance performance, it is not a requirement for functionality. Rework the loop to start and end on *a* node that has SGX memory. This avoids the deadlock looking for the current SGX-lacking node to show up in the loop when it never will.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47714", "url": "https://ubuntu.com/security/CVE-2024-47714", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: use hweight16 to get correct tx antenna The chainmask is u16 so using hweight8 cannot get correct tx_ant. Without this patch, the tx_ant of band 2 would be -1 and lead to the following issue: BUG: KASAN: stack-out-of-bounds in mt7996_mcu_add_sta+0x12e0/0x16e0 [mt7996e]", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47715", "url": "https://ubuntu.com/security/CVE-2024-47715", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: fix oops on non-dbdc mt7986 mt7915_band_config() sets band_idx = 1 on the main phy for mt7986 with MT7975_ONE_ADIE or MT7976_ONE_ADIE. Commit 0335c034e726 (\"wifi: mt76: fix race condition related to checking tx queue fill status\") introduced a dereference of the phys array indirectly indexed by band_idx via wcid->phy_idx in mt76_wcid_cleanup(). This caused the following Oops on affected mt7986 devices: Unable to handle kernel read from unreadable memory at virtual address 0000000000000024 Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x00000005 CM = 0, WnR = 0 user pgtable: 4k pages, 39-bit VAs, pgdp=0000000042545000 [0000000000000024] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 Internal error: Oops: 0000000096000005 [#1] SMP Modules linked in: ... mt7915e mt76_connac_lib mt76 mac80211 cfg80211 ... CPU: 2 PID: 1631 Comm: hostapd Not tainted 5.15.150 #0 Hardware name: ZyXEL EX5700 (Telenor) (DT) pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mt76_wcid_cleanup+0x84/0x22c [mt76] lr : mt76_wcid_cleanup+0x64/0x22c [mt76] sp : ffffffc00a803700 x29: ffffffc00a803700 x28: ffffff80008f7300 x27: ffffff80003f3c00 x26: ffffff80000a7880 x25: ffffffc008c26e00 x24: 0000000000000001 x23: ffffffc000a68114 x22: 0000000000000000 x21: ffffff8004172cc8 x20: ffffffc00a803748 x19: ffffff8004152020 x18: 0000000000000000 x17: 00000000000017c0 x16: ffffffc008ef5000 x15: 0000000000000be0 x14: ffffff8004172e28 x13: ffffff8004172e28 x12: 0000000000000000 x11: 0000000000000000 x10: ffffff8004172e30 x9 : ffffff8004172e28 x8 : 0000000000000000 x7 : ffffff8004156020 x6 : 0000000000000000 x5 : 0000000000000031 x4 : 0000000000000000 x3 : 0000000000000001 x2 : 0000000000000000 x1 : ffffff80008f7300 x0 : 0000000000000024 Call trace: mt76_wcid_cleanup+0x84/0x22c [mt76] __mt76_sta_remove+0x70/0xbc [mt76] mt76_sta_state+0x8c/0x1a4 [mt76] mt7915_eeprom_get_power_delta+0x11e4/0x23a0 [mt7915e] drv_sta_state+0x144/0x274 [mac80211] sta_info_move_state+0x1cc/0x2a4 [mac80211] sta_set_sinfo+0xaf8/0xc24 [mac80211] sta_info_destroy_addr_bss+0x4c/0x6c [mac80211] ieee80211_color_change_finish+0x1c08/0x1e70 [mac80211] cfg80211_check_station_change+0x1360/0x4710 [cfg80211] genl_family_rcv_msg_doit+0xb4/0x110 genl_rcv_msg+0xd0/0x1bc netlink_rcv_skb+0x58/0x120 genl_rcv+0x34/0x50 netlink_unicast+0x1f0/0x2ec netlink_sendmsg+0x198/0x3d0 ____sys_sendmsg+0x1b0/0x210 ___sys_sendmsg+0x80/0xf0 __sys_sendmsg+0x44/0xa0 __arm64_sys_sendmsg+0x20/0x30 invoke_syscall.constprop.0+0x4c/0xe0 do_el0_svc+0x40/0xd0 el0_svc+0x14/0x4c el0t_64_sync_handler+0x100/0x110 el0t_64_sync+0x15c/0x160 Code: d2800002 910092c0 52800023 f9800011 (885f7c01) ---[ end trace 7e42dd9a39ed2281 ]--- Fix by using mt76_dev_phy() which will map band_idx to the correct phy for all hardware combinations.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49857", "url": "https://ubuntu.com/security/CVE-2024-49857", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: set the cipher for secured NDP ranging The cipher pointer is not set, but is derefereced trying to set its content, which leads to a NULL pointer dereference. Fix it by pointing to the cipher parameter before dereferencing.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47738", "url": "https://ubuntu.com/security/CVE-2024-47738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: don't use rate mask for offchannel TX either Like the commit ab9177d83c04 (\"wifi: mac80211: don't use rate mask for scanning\"), ignore incorrect settings to avoid no supported rate warning reported by syzbot. The syzbot did bisect and found cause is commit 9df66d5b9f45 (\"cfg80211: fix default HE tx bitrate mask in 2G band\"), which however corrects bitmask of HE MCS and recognizes correctly settings of empty legacy rate plus HE MCS rate instead of returning -EINVAL. As suggestions [1], follow the change of SCAN TX to consider this case of offchannel TX as well. [1] https://lore.kernel.org/linux-wireless/6ab2dc9c3afe753ca6fdcdd1421e7a1f47e87b84.camel@sipsolutions.net/T/#m2ac2a6d2be06a37c9c47a3d8a44b4f647ed4f024", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47731", "url": "https://ubuntu.com/security/CVE-2024-47731", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers/perf: Fix ali_drw_pmu driver interrupt status clearing The alibaba_uncore_pmu driver forgot to clear all interrupt status in the interrupt processing function. After the PMU counter overflow interrupt occurred, an interrupt storm occurred, causing the system to hang. Therefore, clear the correct interrupt status in the interrupt handling function to fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49862", "url": "https://ubuntu.com/security/CVE-2024-49862", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powercap: intel_rapl: Fix off by one in get_rpi() The rp->priv->rpi array is either rpi_msr or rpi_tpmi which have NR_RAPL_PRIMITIVES number of elements. Thus the > needs to be >= to prevent an off by one access.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47716", "url": "https://ubuntu.com/security/CVE-2024-47716", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: 9410/1: vfp: Use asm volatile in fmrx/fmxr macros Floating point instructions in userspace can crash some arm kernels built with clang/LLD 17.0.6: BUG: unsupported FP instruction in kernel mode FPEXC == 0xc0000780 Internal error: Oops - undefined instruction: 0 [#1] ARM CPU: 0 PID: 196 Comm: vfp-reproducer Not tainted 6.10.0 #1 Hardware name: BCM2835 PC is at vfp_support_entry+0xc8/0x2cc LR is at do_undefinstr+0xa8/0x250 pc : [] lr : [] psr: a0000013 sp : dc8d1f68 ip : 60000013 fp : bedea19c r10: ec532b17 r9 : 00000010 r8 : 0044766c r7 : c0000780 r6 : ec532b17 r5 : c1c13800 r4 : dc8d1fb0 r3 : c10072c4 r2 : c0101c88 r1 : ec532b17 r0 : 0044766c Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 00c5387d Table: 0251c008 DAC: 00000051 Register r0 information: non-paged memory Register r1 information: vmalloc memory Register r2 information: non-slab/vmalloc memory Register r3 information: non-slab/vmalloc memory Register r4 information: 2-page vmalloc region Register r5 information: slab kmalloc-cg-2k Register r6 information: vmalloc memory Register r7 information: non-slab/vmalloc memory Register r8 information: non-paged memory Register r9 information: zero-size pointer Register r10 information: vmalloc memory Register r11 information: non-paged memory Register r12 information: non-paged memory Process vfp-reproducer (pid: 196, stack limit = 0x61aaaf8b) Stack: (0xdc8d1f68 to 0xdc8d2000) 1f60: 0000081f b6f69300 0000000f c10073f4 c10072c4 dc8d1fb0 1f80: ec532b17 0c532b17 0044766c b6f9ccd8 00000000 c010a80c 00447670 60000010 1fa0: ffffffff c1c13800 00c5387d c0100f10 b6f68af8 00448fc0 00000000 bedea188 1fc0: bedea314 00000001 00448ebc b6f9d000 00447608 b6f9ccd8 00000000 bedea19c 1fe0: bede9198 bedea188 b6e1061c 0044766c 60000010 ffffffff 00000000 00000000 Call trace: [] (vfp_support_entry) from [] (do_undefinstr+0xa8/0x250) [] (do_undefinstr) from [] (__und_usr+0x70/0x80) Exception stack(0xdc8d1fb0 to 0xdc8d1ff8) 1fa0: b6f68af8 00448fc0 00000000 bedea188 1fc0: bedea314 00000001 00448ebc b6f9d000 00447608 b6f9ccd8 00000000 bedea19c 1fe0: bede9198 bedea188 b6e1061c 0044766c 60000010 ffffffff Code: 0a000061 e3877202 e594003c e3a09010 (eef16a10) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Fatal exception in interrupt ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]--- This is a minimal userspace reproducer on a Raspberry Pi Zero W: #include #include int main(void) { double v = 1.0; printf(\"%fn\", NAN + *(volatile double *)&v); return 0; } Another way to consistently trigger the oops is: calvin@raspberry-pi-zero-w ~$ python -c \"import json\" The bug reproduces only when the kernel is built with DYNAMIC_DEBUG=n, because the pr_debug() calls act as barriers even when not activated. This is the output from the same kernel source built with the same compiler and DYNAMIC_DEBUG=y, where the userspace reproducer works as expected: VFP: bounce: trigger ec532b17 fpexc c0000780 VFP: emulate: INST=0xee377b06 SCR=0x00000000 VFP: bounce: trigger eef1fa10 fpexc c0000780 VFP: emulate: INST=0xeeb40b40 SCR=0x00000000 VFP: raising exceptions 30000000 calvin@raspberry-pi-zero-w ~$ ./vfp-reproducer nan Crudely grepping for vmsr/vmrs instructions in the otherwise nearly idential text for vfp_support_entry() makes the problem obvious: vmlinux.llvm.good [0xc0101cb8] <+48>: vmrs r7, fpexc vmlinux.llvm.good [0xc0101cd8] <+80>: vmsr fpexc, r0 vmlinux.llvm.good [0xc0101d20 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47717", "url": "https://ubuntu.com/security/CVE-2024-47717", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RISC-V: KVM: Don't zero-out PMU snapshot area before freeing data With the latest Linux-6.11-rc3, the below NULL pointer crash is observed when SBI PMU snapshot is enabled for the guest and the guest is forcefully powered-off. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000508 Oops [#1] Modules linked in: kvm CPU: 0 UID: 0 PID: 61 Comm: term-poll Not tainted 6.11.0-rc3-00018-g44d7178dd77a #3 Hardware name: riscv-virtio,qemu (DT) epc : __kvm_write_guest_page+0x94/0xa6 [kvm] ra : __kvm_write_guest_page+0x54/0xa6 [kvm] epc : ffffffff01590e98 ra : ffffffff01590e58 sp : ffff8f80001f39b0 gp : ffffffff81512a60 tp : ffffaf80024872c0 t0 : ffffaf800247e000 t1 : 00000000000007e0 t2 : 0000000000000000 s0 : ffff8f80001f39f0 s1 : 00007fff89ac4000 a0 : ffffffff015dd7e8 a1 : 0000000000000086 a2 : 0000000000000000 a3 : ffffaf8000000000 a4 : ffffaf80024882c0 a5 : 0000000000000000 a6 : ffffaf800328d780 a7 : 00000000000001cc s2 : ffffaf800197bd00 s3 : 00000000000828c4 s4 : ffffaf800248c000 s5 : ffffaf800247d000 s6 : 0000000000001000 s7 : 0000000000001000 s8 : 0000000000000000 s9 : 00007fff861fd500 s10: 0000000000000001 s11: 0000000000800000 t3 : 00000000000004d3 t4 : 00000000000004d3 t5 : ffffffff814126e0 t6 : ffffffff81412700 status: 0000000200000120 badaddr: 0000000000000508 cause: 000000000000000d [] __kvm_write_guest_page+0x94/0xa6 [kvm] [] kvm_vcpu_write_guest+0x56/0x90 [kvm] [] kvm_pmu_clear_snapshot_area+0x42/0x7e [kvm] [] kvm_riscv_vcpu_pmu_deinit.part.0+0xe0/0x14e [kvm] [] kvm_riscv_vcpu_pmu_deinit+0x1a/0x24 [kvm] [] kvm_arch_vcpu_destroy+0x28/0x4c [kvm] [] kvm_destroy_vcpus+0x5a/0xda [kvm] [] kvm_arch_destroy_vm+0x14/0x28 [kvm] [] kvm_destroy_vm+0x168/0x2a0 [kvm] [] kvm_put_kvm+0x3c/0x58 [kvm] [] kvm_vm_release+0x22/0x2e [kvm] Clearly, the kvm_vcpu_write_guest() function is crashing because it is being called from kvm_pmu_clear_snapshot_area() upon guest tear down. To address the above issue, simplify the kvm_pmu_clear_snapshot_area() to not zero-out PMU snapshot area from kvm_pmu_clear_snapshot_area() because the guest is anyway being tore down. The kvm_pmu_clear_snapshot_area() is also called when guest changes PMU snapshot area of a VCPU but even in this case the previous PMU snaphsot area must not be zeroed-out because the guest might have reclaimed the pervious PMU snapshot area for some other purpose.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47721", "url": "https://ubuntu.com/security/CVE-2024-47721", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: remove unused C2H event ID RTW89_MAC_C2H_FUNC_READ_WOW_CAM to prevent out-of-bounds reading The handler of firmware C2H event RTW89_MAC_C2H_FUNC_READ_WOW_CAM isn't implemented, but driver expects number of handlers is NUM_OF_RTW89_MAC_C2H_FUNC_WOW causing out-of-bounds access. Fix it by removing ID. Addresses-Coverity-ID: 1598775 (\"Out-of-bounds read\")", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47732", "url": "https://ubuntu.com/security/CVE-2024-47732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: iaa - Fix potential use after free bug The free_device_compression_mode(iaa_device, device_mode) function frees \"device_mode\" but it iss passed to iaa_compression_modes[i]->free() a few lines later resulting in a use after free. The good news is that, so far as I can tell, nothing implements the ->free() function and the use after free happens in dead code. But, with this fix, when something does implement it, we'll be ready. :)", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47718", "url": "https://ubuntu.com/security/CVE-2024-47718", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: always wait for both firmware loading attempts In 'rtw_wait_firmware_completion()', always wait for both (regular and wowlan) firmware loading attempts. Otherwise if 'rtw_usb_intf_init()' has failed in 'rtw_usb_probe()', 'rtw_usb_disconnect()' may issue 'ieee80211_free_hw()' when one of 'rtw_load_firmware_cb()' (usually the wowlan one) is still in progress, causing UAF detected by KASAN.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47724", "url": "https://ubuntu.com/security/CVE-2024-47724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: use work queue to process beacon tx event Commit 3a415daa3e8b (\"wifi: ath11k: add P2P IE in beacon template\") from Feb 28, 2024 (linux-next), leads to the following Smatch static checker warning: drivers/net/wireless/ath/ath11k/wmi.c:1742 ath11k_wmi_p2p_go_bcn_ie() warn: sleeping in atomic context The reason is that ath11k_bcn_tx_status_event() will directly call might sleep function ath11k_wmi_cmd_send() during RCU read-side critical sections. The call trace is like: ath11k_bcn_tx_status_event() -> rcu_read_lock() -> ath11k_mac_bcn_tx_event() \t-> ath11k_mac_setup_bcn_tmpl() \t…… \t\t-> ath11k_wmi_bcn_tmpl() \t\t\t-> ath11k_wmi_cmd_send() -> rcu_read_unlock() Commit 886433a98425 (\"ath11k: add support for BSS color change\") added the ath11k_mac_bcn_tx_event(), commit 01e782c89108 (\"ath11k: fix warning of RCU usage for ath11k_mac_get_arvif_by_vdev_id()\") added the RCU lock to avoid warning but also introduced this BUG. Use work queue to avoid directly calling ath11k_mac_bcn_tx_event() during RCU critical sections. No need to worry about the deletion of vif because cancel_work_sync() will drop the work if it doesn't start or block vif deletion until the running work is done. 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": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47671", "url": "https://ubuntu.com/security/CVE-2024-47671", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: usbtmc: prevent kernel-usb-infoleak The syzbot reported a kernel-usb-infoleak in usbtmc_write, we need to clear the structure before filling fields.", "cve_priority": "medium", "cve_public_date": "2024-10-09 15:15:00 UTC" }, { "cve": "CVE-2024-46869", "url": "https://ubuntu.com/security/CVE-2024-46869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btintel_pcie: Allocate memory for driver private data Fix driver not allocating memory for struct btintel_data which is used to store internal data.", "cve_priority": "medium", "cve_public_date": "2024-09-30 16:15:00 UTC" }, { "cve": "CVE-2024-53164", "url": "https://ubuntu.com/security/CVE-2024-53164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: fix ordering of qlen adjustment Changes to sch->q.qlen around qdisc_tree_reduce_backlog() need to happen _before_ a call to said function because otherwise it may fail to notify parent qdiscs when the child is about to become empty.", "cve_priority": "medium", "cve_public_date": "2024-12-27 14:15:00 UTC" }, { "cve": "CVE-2024-53103", "url": "https://ubuntu.com/security/CVE-2024-53103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hv_sock: Initializing vsk->trans to NULL to prevent a dangling pointer When hvs is released, there is a possibility that vsk->trans may not be initialized to NULL, which could lead to a dangling pointer. This issue is resolved by initializing vsk->trans to NULL.", "cve_priority": "high", "cve_public_date": "2024-12-02 08:15:00 UTC" } ], "launchpad_bugs_fixed": [ 2093643, 1786013, 2091744, 2091184, 2093146, 2085406, 2089684, 2090932, 2085485, 2089357, 2089306, 2091655, 2091655, 2091655, 2091655, 2091655, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091386, 2091990, 2089327, 2089113, 2086587, 2086606, 2085950, 2085944, 2087853, 2087983, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089020, 2089020, 2089020 ], "changes": [ { "cves": [ { "cve": "CVE-2025-0927", "url": "https://ubuntu.com/security/CVE-2025-0927", "cve_description": "[fs: hfs/hfsplus: add key_len boundary check to hfs_bnode_read_key]", "cve_priority": "medium", "cve_public_date": "2025-02-13" } ], "log": [ "", " * CVE-2025-0927", " - SAUCE: fs: hfs/hfsplus: add key_len boundary check to hfs_bnode_read_key", "" ], "package": "linux", "version": "6.11.0-18.18", "urgency": "medium", "distributions": "oracular", "launchpad_bugs_fixed": [], "author": "Manuel Diewald ", "date": "Fri, 07 Feb 2025 18:44:32 +0100" }, { "cves": [ { "cve": "CVE-2024-53141", "url": "https://ubuntu.com/security/CVE-2024-53141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: add missing range check in bitmap_ip_uadt When tb[IPSET_ATTR_IP_TO] is not present but tb[IPSET_ATTR_CIDR] exists, the values of ip and ip_to are slightly swapped. Therefore, the range check for ip should be done later, but this part is missing and it seems that the vulnerability occurs. So we should add missing range checks and remove unnecessary range checks.", "cve_priority": "medium", "cve_public_date": "2024-12-06 10:15:00 UTC" }, { "cve": "CVE-2024-50010", "url": "https://ubuntu.com/security/CVE-2024-50010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exec: don't WARN for racy path_noexec check Both i_mode and noexec checks wrapped in WARN_ON stem from an artifact of the previous implementation. They used to legitimately check for the condition, but that got moved up in two commits: 633fb6ac3980 (\"exec: move S_ISREG() check earlier\") 0fd338b2d2cd (\"exec: move path_noexec() check earlier\") Instead of being removed said checks are WARN_ON'ed instead, which has some debug value. However, the spurious path_noexec check is racy, resulting in unwarranted warnings should someone race with setting the noexec flag. One can note there is more to perm-checking whether execve is allowed and none of the conditions are guaranteed to still hold after they were tested for. Additionally this does not validate whether the code path did any perm checking to begin with -- it will pass if the inode happens to be regular. Keep the redundant path_noexec() check even though it's mindless nonsense checking for guarantee that isn't given so drop the WARN. Reword the commentary and do small tidy ups while here. [brauner: keep redundant path_noexec() check]", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-53143", "url": "https://ubuntu.com/security/CVE-2024-53143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fsnotify: Fix ordering of iput() and watched_objects decrement Ensure the superblock is kept alive until we're done with iput(). Holding a reference to an inode is not allowed unless we ensure the superblock stays alive, which fsnotify does by keeping the watched_objects count elevated, so iput() must happen before the watched_objects decrement. This can lead to a UAF of something like sb->s_fs_info in tmpfs, but the UAF is hard to hit because race orderings that oops are more likely, thanks to the CHECK_DATA_CORRUPTION() block in generic_shutdown_super(). Also, ensure that fsnotify_put_sb_watched_objects() doesn't call fsnotify_sb_watched_objects() on a superblock that may have already been freed, which would cause a UAF read of sb->s_fsnotify_info.", "cve_priority": "medium", "cve_public_date": "2024-12-07 07:15:00 UTC" }, { "cve": "CVE-2024-53142", "url": "https://ubuntu.com/security/CVE-2024-53142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: initramfs: avoid filename buffer overrun The initramfs filename field is defined in Documentation/driver-api/early-userspace/buffer-format.rst as: 37 cpio_file := ALGN(4) + cpio_header + filename + \"\\0\" + ALGN(4) + data ... 55 ============= ================== ========================= 56 Field name Field size Meaning 57 ============= ================== ========================= ... 70 c_namesize 8 bytes Length of filename, including final \\0 When extracting an initramfs cpio archive, the kernel's do_name() path handler assumes a zero-terminated path at @collected, passing it directly to filp_open() / init_mkdir() / init_mknod(). If a specially crafted cpio entry carries a non-zero-terminated filename and is followed by uninitialized memory, then a file may be created with trailing characters that represent the uninitialized memory. The ability to create an initramfs entry would imply already having full control of the system, so the buffer overrun shouldn't be considered a security vulnerability. Append the output of the following bash script to an existing initramfs and observe any created /initramfs_test_fname_overrunAA* path. E.g. ./reproducer.sh | gzip >> /myinitramfs It's easiest to observe non-zero uninitialized memory when the output is gzipped, as it'll overflow the heap allocated @out_buf in __gunzip(), rather than the initrd_start+initrd_size block. ---- reproducer.sh ---- nilchar=\"A\"\t# change to \"\\0\" to properly zero terminate / pad magic=\"070701\" ino=1 mode=$(( 0100777 )) uid=0 gid=0 nlink=1 mtime=1 filesize=0 devmajor=0 devminor=1 rdevmajor=0 rdevminor=0 csum=0 fname=\"initramfs_test_fname_overrun\" namelen=$(( ${#fname} + 1 ))\t# plus one to account for terminator printf \"%s%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%s\" \\ \t$magic $ino $mode $uid $gid $nlink $mtime $filesize \\ \t$devmajor $devminor $rdevmajor $rdevminor $namelen $csum $fname termpadlen=$(( 1 + ((4 - ((110 + $namelen) & 3)) % 4) )) printf \"%.s${nilchar}\" $(seq 1 $termpadlen) ---- reproducer.sh ---- Symlink filename fields handled in do_symlink() won't overrun past the data segment, due to the explicit zero-termination of the symlink target. Fix filename buffer overrun by aborting the initramfs FSM if any cpio entry doesn't carry a zero-terminator at the expected (name_len - 1) offset.", "cve_priority": "medium", "cve_public_date": "2024-12-06 10:15:00 UTC" }, { "cve": "CVE-2024-53133", "url": "https://ubuntu.com/security/CVE-2024-53133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Handle dml allocation failure to avoid crash [Why] In the case where a dml allocation fails for any reason, the current state's dml contexts would no longer be valid. Then subsequent calls dc_state_copy_internal would shallow copy invalid memory and if the new state was released, a double free would occur. [How] Reset dml pointers in new_state to NULL and avoid invalid pointer (cherry picked from commit bcafdc61529a48f6f06355d78eb41b3aeda5296c)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53108", "url": "https://ubuntu.com/security/CVE-2024-53108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Adjust VSDB parser for replay feature At some point, the IEEE ID identification for the replay check in the AMD EDID was added. However, this check causes the following out-of-bounds issues when using KASAN: [ 27.804016] BUG: KASAN: slab-out-of-bounds in amdgpu_dm_update_freesync_caps+0xefa/0x17a0 [amdgpu] [ 27.804788] Read of size 1 at addr ffff8881647fdb00 by task systemd-udevd/383 ... [ 27.821207] Memory state around the buggy address: [ 27.821215] ffff8881647fda00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821224] ffff8881647fda80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821234] >ffff8881647fdb00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821243] ^ [ 27.821250] ffff8881647fdb80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821259] ffff8881647fdc00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821268] ================================================================== This is caused because the ID extraction happens outside of the range of the edid lenght. This commit addresses this issue by considering the amd_vsdb_block size. (cherry picked from commit b7e381b1ccd5e778e3d9c44c669ad38439a861d8)", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53134", "url": "https://ubuntu.com/security/CVE-2024-53134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pmdomain: imx93-blk-ctrl: correct remove path The check condition should be 'i < bc->onecell_data.num_domains', not 'bc->onecell_data.num_domains' which will make the look never finish and cause kernel panic. Also disable runtime to address \"imx93-blk-ctrl 4ac10000.system-controller: Unbalanced pm_runtime_enable!\"", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53132", "url": "https://ubuntu.com/security/CVE-2024-53132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/oa: Fix \"Missing outer runtime PM protection\" warning Fix the following drm_WARN: [953.586396] xe 0000:00:02.0: [drm] Missing outer runtime PM protection ... <4> [953.587090] ? xe_pm_runtime_get_noresume+0x8d/0xa0 [xe] <4> [953.587208] guc_exec_queue_add_msg+0x28/0x130 [xe] <4> [953.587319] guc_exec_queue_fini+0x3a/0x40 [xe] <4> [953.587425] xe_exec_queue_destroy+0xb3/0xf0 [xe] <4> [953.587515] xe_oa_release+0x9c/0xc0 [xe] (cherry picked from commit b107c63d2953907908fd0cafb0e543b3c3167b75)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53127", "url": "https://ubuntu.com/security/CVE-2024-53127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Revert \"mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K\" The commit 8396c793ffdf (\"mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K\") increased the max_req_size, even for 4K pages, causing various issues: - Panic booting the kernel/rootfs from an SD card on Rockchip RK3566 - Panic booting the kernel/rootfs from an SD card on StarFive JH7100 - \"swiotlb buffer is full\" and data corruption on StarFive JH7110 At this stage no fix have been found, so it's probably better to just revert the change. This reverts commit 8396c793ffdf28bb8aee7cfe0891080f8cab7890.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53130", "url": "https://ubuntu.com/security/CVE-2024-53130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint When using the \"block:block_dirty_buffer\" tracepoint, mark_buffer_dirty() may cause a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because, since the tracepoint was added in mark_buffer_dirty(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, nilfs_grab_buffer(), which grabs a buffer to read (or create) a block of metadata, including b-tree node blocks, does not set the block device, but instead does so only if the buffer is not in the \"uptodate\" state for each of its caller block reading functions. However, if the uptodate flag is set on a folio/page, and the buffer heads are detached from it by try_to_free_buffers(), and new buffer heads are then attached by create_empty_buffers(), the uptodate flag may be restored to each buffer without the block device being set to bh->b_bdev, and mark_buffer_dirty() may be called later in that state, resulting in the bug mentioned above. Fix this issue by making nilfs_grab_buffer() always set the block device of the super block structure to the buffer head, regardless of the state of the buffer's uptodate flag.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53105", "url": "https://ubuntu.com/security/CVE-2024-53105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: page_alloc: move mlocked flag clearance into free_pages_prepare() Syzbot reported a bad page state problem caused by a page being freed using free_page() still having a mlocked flag at free_pages_prepare() stage: BUG: Bad page state in process syz.5.504 pfn:61f45 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x61f45 flags: 0xfff00000080204(referenced|workingset|mlocked|node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000080204 0000000000000000 dead000000000122 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set page_owner tracks the page as allocated page last allocated via order 0, migratetype Unmovable, gfp_mask 0x400dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO), pid 8443, tgid 8442 (syz.5.504), ts 201884660643, free_ts 201499827394 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1537 prep_new_page mm/page_alloc.c:1545 [inline] get_page_from_freelist+0x303f/0x3190 mm/page_alloc.c:3457 __alloc_pages_noprof+0x292/0x710 mm/page_alloc.c:4733 alloc_pages_mpol_noprof+0x3e8/0x680 mm/mempolicy.c:2265 kvm_coalesced_mmio_init+0x1f/0xf0 virt/kvm/coalesced_mmio.c:99 kvm_create_vm virt/kvm/kvm_main.c:1235 [inline] kvm_dev_ioctl_create_vm virt/kvm/kvm_main.c:5488 [inline] kvm_dev_ioctl+0x12dc/0x2240 virt/kvm/kvm_main.c:5530 __do_compat_sys_ioctl fs/ioctl.c:1007 [inline] __se_compat_sys_ioctl+0x510/0xc90 fs/ioctl.c:950 do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline] __do_fast_syscall_32+0xb4/0x110 arch/x86/entry/common.c:386 do_fast_syscall_32+0x34/0x80 arch/x86/entry/common.c:411 entry_SYSENTER_compat_after_hwframe+0x84/0x8e page last free pid 8399 tgid 8399 stack trace: reset_page_owner include/linux/page_owner.h:25 [inline] free_pages_prepare mm/page_alloc.c:1108 [inline] free_unref_folios+0xf12/0x18d0 mm/page_alloc.c:2686 folios_put_refs+0x76c/0x860 mm/swap.c:1007 free_pages_and_swap_cache+0x5c8/0x690 mm/swap_state.c:335 __tlb_batch_free_encoded_pages mm/mmu_gather.c:136 [inline] tlb_batch_pages_flush mm/mmu_gather.c:149 [inline] tlb_flush_mmu_free mm/mmu_gather.c:366 [inline] tlb_flush_mmu+0x3a3/0x680 mm/mmu_gather.c:373 tlb_finish_mmu+0xd4/0x200 mm/mmu_gather.c:465 exit_mmap+0x496/0xc40 mm/mmap.c:1926 __mmput+0x115/0x390 kernel/fork.c:1348 exit_mm+0x220/0x310 kernel/exit.c:571 do_exit+0x9b2/0x28e0 kernel/exit.c:926 do_group_exit+0x207/0x2c0 kernel/exit.c:1088 __do_sys_exit_group kernel/exit.c:1099 [inline] __se_sys_exit_group kernel/exit.c:1097 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1097 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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 Modules linked in: CPU: 0 UID: 0 PID: 8442 Comm: syz.5.504 Not tainted 6.12.0-rc6-syzkaller #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 bad_page+0x176/0x1d0 mm/page_alloc.c:501 free_page_is_bad mm/page_alloc.c:918 [inline] free_pages_prepare mm/page_alloc.c:1100 [inline] free_unref_page+0xed0/0xf20 mm/page_alloc.c:2638 kvm_destroy_vm virt/kvm/kvm_main.c:1327 [inline] kvm_put_kvm+0xc75/0x1350 virt/kvm/kvm_main.c:1386 kvm_vcpu_release+0x54/0x60 virt/kvm/kvm_main.c:4143 __fput+0x23f/0x880 fs/file_table.c:431 task_work_run+0x24f/0x310 kernel/task_work.c:239 exit_task_work include/linux/task_work.h:43 [inline] do_exit+0xa2f/0x28e0 kernel/exit.c:939 do_group_exit+0x207/0x2c0 kernel/exit.c:1088 __do_sys_exit_group kernel/exit.c:1099 [in ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53109", "url": "https://ubuntu.com/security/CVE-2024-53109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nommu: pass NULL argument to vma_iter_prealloc() When deleting a vma entry from a maple tree, it has to pass NULL to vma_iter_prealloc() in order to calculate internal state of the tree, but it passed a wrong argument. As a result, nommu kernels crashed upon accessing a vma iterator, such as acct_collect() reading the size of vma entries after do_munmap(). This commit fixes this issue by passing a right argument to the preallocation call.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53131", "url": "https://ubuntu.com/security/CVE-2024-53131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint Patch series \"nilfs2: fix null-ptr-deref bugs on block tracepoints\". This series fixes null pointer dereference bugs that occur when using nilfs2 and two block-related tracepoints. This patch (of 2): It has been reported that when using \"block:block_touch_buffer\" tracepoint, touch_buffer() called from __nilfs_get_folio_block() causes a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because since the tracepoint was added in touch_buffer(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, the block_device structure is set after the function returns to the caller. Here, touch_buffer() is used to mark the folio/page that owns the buffer head as accessed, but the common search helper for folio/page used by the caller function was optimized to mark the folio/page as accessed when it was reimplemented a long time ago, eliminating the need to call touch_buffer() here in the first place. So this solves the issue by eliminating the touch_buffer() call itself.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53135", "url": "https://ubuntu.com/security/CVE-2024-53135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: VMX: Bury Intel PT virtualization (guest/host mode) behind CONFIG_BROKEN Hide KVM's pt_mode module param behind CONFIG_BROKEN, i.e. disable support for virtualizing Intel PT via guest/host mode unless BROKEN=y. There are myriad bugs in the implementation, some of which are fatal to the guest, and others which put the stability and health of the host at risk. For guest fatalities, the most glaring issue is that KVM fails to ensure tracing is disabled, and *stays* disabled prior to VM-Enter, which is necessary as hardware disallows loading (the guest's) RTIT_CTL if tracing is enabled (enforced via a VMX consistency check). Per the SDM: If the logical processor is operating with Intel PT enabled (if IA32_RTIT_CTL.TraceEn = 1) at the time of VM entry, the \"load IA32_RTIT_CTL\" VM-entry control must be 0. On the host side, KVM doesn't validate the guest CPUID configuration provided by userspace, and even worse, uses the guest configuration to decide what MSRs to save/load at VM-Enter and VM-Exit. E.g. configuring guest CPUID to enumerate more address ranges than are supported in hardware will result in KVM trying to passthrough, save, and load non-existent MSRs, which generates a variety of WARNs, ToPA ERRORs in the host, a potential deadlock, etc.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53106", "url": "https://ubuntu.com/security/CVE-2024-53106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: fix buffer overrun in ima_eventdigest_init_common Function ima_eventdigest_init() calls ima_eventdigest_init_common() with HASH_ALGO__LAST which is then used to access the array hash_digest_size[] leading to buffer overrun. Have a conditional statement to handle this.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53110", "url": "https://ubuntu.com/security/CVE-2024-53110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vp_vdpa: fix id_table array not null terminated error Allocate one extra virtio_device_id as null terminator, otherwise vdpa_mgmtdev_get_classes() may iterate multiple times and visit undefined memory.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53126", "url": "https://ubuntu.com/security/CVE-2024-53126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa: solidrun: Fix UB bug with devres In psnet_open_pf_bar() and snet_open_vf_bar() a string later passed to pcim_iomap_regions() is placed on the stack. Neither pcim_iomap_regions() nor the functions it calls copy that string. Should the string later ever be used, this, consequently, causes undefined behavior since the stack frame will by then have disappeared. Fix the bug by allocating the strings on the heap through devm_kasprintf().", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53111", "url": "https://ubuntu.com/security/CVE-2024-53111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mremap: fix address wraparound in move_page_tables() On 32-bit platforms, it is possible for the expression `len + old_addr < old_end` to be false-positive if `len + old_addr` wraps around. `old_addr` is the cursor in the old range up to which page table entries have been moved; so if the operation succeeded, `old_addr` is the *end* of the old region, and adding `len` to it can wrap. The overflow causes mremap() to mistakenly believe that PTEs have been copied; the consequence is that mremap() bails out, but doesn't move the PTEs back before the new VMA is unmapped, causing anonymous pages in the region to be lost. So basically if userspace tries to mremap() a private-anon region and hits this bug, mremap() will return an error and the private-anon region's contents appear to have been zeroed. The idea of this check is that `old_end - len` is the original start address, and writing the check that way also makes it easier to read; so fix the check by rearranging the comparison accordingly. (An alternate fix would be to refactor this function by introducing an \"orig_old_start\" variable or such.) Tested in a VM with a 32-bit X86 kernel; without the patch: ``` user@horn:~/big_mremap$ cat test.c #define _GNU_SOURCE #include #include #include #include #define ADDR1 ((void*)0x60000000) #define ADDR2 ((void*)0x10000000) #define SIZE 0x50000000uL int main(void) { unsigned char *p1 = mmap(ADDR1, SIZE, PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0); if (p1 == MAP_FAILED) err(1, \"mmap 1\"); unsigned char *p2 = mmap(ADDR2, SIZE, PROT_NONE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0); if (p2 == MAP_FAILED) err(1, \"mmap 2\"); *p1 = 0x41; printf(\"first char is 0x%02hhx\\n\", *p1); unsigned char *p3 = mremap(p1, SIZE, SIZE, MREMAP_MAYMOVE|MREMAP_FIXED, p2); if (p3 == MAP_FAILED) { printf(\"mremap() failed; first char is 0x%02hhx\\n\", *p1); } else { printf(\"mremap() succeeded; first char is 0x%02hhx\\n\", *p3); } } user@horn:~/big_mremap$ gcc -static -o test test.c user@horn:~/big_mremap$ setarch -R ./test first char is 0x41 mremap() failed; first char is 0x00 ``` With the patch: ``` user@horn:~/big_mremap$ setarch -R ./test first char is 0x41 mremap() succeeded; first char is 0x41 ```", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53107", "url": "https://ubuntu.com/security/CVE-2024-53107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: prevent integer overflow in pagemap_scan_get_args() The \"arg->vec_len\" variable is a u64 that comes from the user at the start of the function. The \"arg->vec_len * sizeof(struct page_region))\" multiplication can lead to integer wrapping. Use size_mul() to avoid that. Also the size_add/mul() functions work on unsigned long so for 32bit systems we need to ensure that \"arg->vec_len\" fits in an unsigned long.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53128", "url": "https://ubuntu.com/security/CVE-2024-53128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/task_stack: fix object_is_on_stack() for KASAN tagged pointers When CONFIG_KASAN_SW_TAGS and CONFIG_KASAN_STACK are enabled, the object_is_on_stack() function may produce incorrect results due to the presence of tags in the obj pointer, while the stack pointer does not have tags. This discrepancy can lead to incorrect stack object detection and subsequently trigger warnings if CONFIG_DEBUG_OBJECTS is also enabled. Example of the warning: ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at lib/debugobjects.c:557 __debug_object_init+0x330/0x364 Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5 #4 Hardware name: linux,dummy-virt (DT) pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __debug_object_init+0x330/0x364 lr : __debug_object_init+0x330/0x364 sp : ffff800082ea7b40 x29: ffff800082ea7b40 x28: 98ff0000c0164518 x27: 98ff0000c0164534 x26: ffff800082d93ec8 x25: 0000000000000001 x24: 1cff0000c00172a0 x23: 0000000000000000 x22: ffff800082d93ed0 x21: ffff800081a24418 x20: 3eff800082ea7bb0 x19: efff800000000000 x18: 0000000000000000 x17: 00000000000000ff x16: 0000000000000047 x15: 206b63617473206e x14: 0000000000000018 x13: ffff800082ea7780 x12: 0ffff800082ea78e x11: 0ffff800082ea790 x10: 0ffff800082ea79d x9 : 34d77febe173e800 x8 : 34d77febe173e800 x7 : 0000000000000001 x6 : 0000000000000001 x5 : feff800082ea74b8 x4 : ffff800082870a90 x3 : ffff80008018d3c4 x2 : 0000000000000001 x1 : ffff800082858810 x0 : 0000000000000050 Call trace: __debug_object_init+0x330/0x364 debug_object_init_on_stack+0x30/0x3c schedule_hrtimeout_range_clock+0xac/0x26c schedule_hrtimeout+0x1c/0x30 wait_task_inactive+0x1d4/0x25c kthread_bind_mask+0x28/0x98 init_rescuer+0x1e8/0x280 workqueue_init+0x1a0/0x3cc kernel_init_freeable+0x118/0x200 kernel_init+0x28/0x1f0 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53112", "url": "https://ubuntu.com/security/CVE-2024-53112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: uncache inode which has failed entering the group Syzbot has reported the following BUG: kernel BUG at fs/ocfs2/uptodate.c:509! ... Call Trace: ? __die_body+0x5f/0xb0 ? die+0x9e/0xc0 ? do_trap+0x15a/0x3a0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? do_error_trap+0x1dc/0x2c0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? __pfx_do_error_trap+0x10/0x10 ? handle_invalid_op+0x34/0x40 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? exc_invalid_op+0x38/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? ocfs2_set_new_buffer_uptodate+0x2e/0x160 ? ocfs2_set_new_buffer_uptodate+0x144/0x160 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ocfs2_group_add+0x39f/0x15a0 ? __pfx_ocfs2_group_add+0x10/0x10 ? __pfx_lock_acquire+0x10/0x10 ? mnt_get_write_access+0x68/0x2b0 ? __pfx_lock_release+0x10/0x10 ? rcu_read_lock_any_held+0xb7/0x160 ? __pfx_rcu_read_lock_any_held+0x10/0x10 ? smack_log+0x123/0x540 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x226/0x2b0 ocfs2_ioctl+0x65e/0x7d0 ? __pfx_ocfs2_ioctl+0x10/0x10 ? smack_file_ioctl+0x29e/0x3a0 ? __pfx_smack_file_ioctl+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x43d/0x780 ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10 ? __pfx_ocfs2_ioctl+0x10/0x10 __se_sys_ioctl+0xfb/0x170 do_syscall_64+0xf3/0x230 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... When 'ioctl(OCFS2_IOC_GROUP_ADD, ...)' has failed for the particular inode in 'ocfs2_verify_group_and_input()', corresponding buffer head remains cached and subsequent call to the same 'ioctl()' for the same inode issues the BUG() in 'ocfs2_set_new_buffer_uptodate()' (trying to cache the same buffer head of that inode). Fix this by uncaching the buffer head with 'ocfs2_remove_from_cache()' on error path in 'ocfs2_group_add()'.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53113", "url": "https://ubuntu.com/security/CVE-2024-53113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: fix NULL pointer dereference in alloc_pages_bulk_noprof We triggered a NULL pointer dereference for ac.preferred_zoneref->zone in alloc_pages_bulk_noprof() when the task is migrated between cpusets. When cpuset is enabled, in prepare_alloc_pages(), ac->nodemask may be ¤t->mems_allowed. when first_zones_zonelist() is called to find preferred_zoneref, the ac->nodemask may be modified concurrently if the task is migrated between different cpusets. Assuming we have 2 NUMA Node, when traversing Node1 in ac->zonelist, the nodemask is 2, and when traversing Node2 in ac->zonelist, the nodemask is 1. As a result, the ac->preferred_zoneref points to NULL zone. In alloc_pages_bulk_noprof(), for_each_zone_zonelist_nodemask() finds a allowable zone and calls zonelist_node_idx(ac.preferred_zoneref), leading to NULL pointer dereference. __alloc_pages_noprof() fixes this issue by checking NULL pointer in commit ea57485af8f4 (\"mm, page_alloc: fix check for NULL preferred_zone\") and commit df76cee6bbeb (\"mm, page_alloc: remove redundant checks from alloc fastpath\"). To fix it, check NULL pointer for preferred_zoneref->zone.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53114", "url": "https://ubuntu.com/security/CVE-2024-53114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 client A number of Zen4 client SoCs advertise the ability to use virtualized VMLOAD/VMSAVE, but using these instructions is reported to be a cause of a random host reboot. These instructions aren't intended to be advertised on Zen4 client so clear the capability.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53137", "url": "https://ubuntu.com/security/CVE-2024-53137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: fix cacheflush with PAN It seems that the cacheflush syscall got broken when PAN for LPAE was implemented. User access was not enabled around the cache maintenance instructions, causing them to fault.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53115", "url": "https://ubuntu.com/security/CVE-2024-53115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: avoid null_ptr_deref in vmw_framebuffer_surface_create_handle The 'vmw_user_object_buffer' function may return NULL with incorrect inputs. To avoid possible null pointer dereference, add a check whether the 'bo' is NULL in the vmw_framebuffer_surface_create_handle.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53116", "url": "https://ubuntu.com/security/CVE-2024-53116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix handling of partial GPU mapping of BOs This commit fixes the bug in the handling of partial mapping of the buffer objects to the GPU, which caused kernel warnings. Panthor didn't correctly handle the case where the partial mapping spanned multiple scatterlists and the mapping offset didn't point to the 1st page of starting scatterlist. The offset variable was not cleared after reaching the starting scatterlist. Following warning messages were seen. WARNING: CPU: 1 PID: 650 at drivers/iommu/io-pgtable-arm.c:659 __arm_lpae_unmap+0x254/0x5a0 pc : __arm_lpae_unmap+0x254/0x5a0 lr : __arm_lpae_unmap+0x2cc/0x5a0 Call trace: __arm_lpae_unmap+0x254/0x5a0 __arm_lpae_unmap+0x108/0x5a0 __arm_lpae_unmap+0x108/0x5a0 __arm_lpae_unmap+0x108/0x5a0 arm_lpae_unmap_pages+0x80/0xa0 panthor_vm_unmap_pages+0xac/0x1c8 [panthor] panthor_gpuva_sm_step_unmap+0x4c/0xc8 [panthor] op_unmap_cb.isra.23.constprop.30+0x54/0x80 __drm_gpuvm_sm_unmap+0x184/0x1c8 drm_gpuvm_sm_unmap+0x40/0x60 panthor_vm_exec_op+0xa8/0x120 [panthor] panthor_vm_bind_exec_sync_op+0xc4/0xe8 [panthor] panthor_ioctl_vm_bind+0x10c/0x170 [panthor] drm_ioctl_kernel+0xbc/0x138 drm_ioctl+0x210/0x4b0 __arm64_sys_ioctl+0xb0/0xf8 invoke_syscall+0x4c/0x110 el0_svc_common.constprop.1+0x98/0xf8 do_el0_svc+0x24/0x38 el0_svc+0x34/0xc8 el0t_64_sync_handler+0xa0/0xc8 el0t_64_sync+0x174/0x178 panthor : [drm] drm_WARN_ON(unmapped_sz != pgsize * pgcount) WARNING: CPU: 1 PID: 650 at drivers/gpu/drm/panthor/panthor_mmu.c:922 panthor_vm_unmap_pages+0x124/0x1c8 [panthor] pc : panthor_vm_unmap_pages+0x124/0x1c8 [panthor] lr : panthor_vm_unmap_pages+0x124/0x1c8 [panthor] panthor : [drm] *ERROR* failed to unmap range ffffa388f000-ffffa3890000 (requested range ffffa388c000-ffffa3890000)", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53117", "url": "https://ubuntu.com/security/CVE-2024-53117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio/vsock: Improve MSG_ZEROCOPY error handling Add a missing kfree_skb() to prevent memory leaks.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53118", "url": "https://ubuntu.com/security/CVE-2024-53118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Fix sk_error_queue memory leak Kernel queues MSG_ZEROCOPY completion notifications on the error queue. Where they remain, until explicitly recv()ed. To prevent memory leaks, clean up the queue when the socket is destroyed. unreferenced object 0xffff8881028beb00 (size 224): comm \"vsock_test\", pid 1218, jiffies 4294694897 hex dump (first 32 bytes): 90 b0 21 17 81 88 ff ff 90 b0 21 17 81 88 ff ff ..!.......!..... 00 00 00 00 00 00 00 00 00 b0 21 17 81 88 ff ff ..........!..... backtrace (crc 6c7031ca): [] kmem_cache_alloc_node_noprof+0x2f7/0x370 [] __alloc_skb+0x132/0x180 [] sock_omalloc+0x4b/0x80 [] msg_zerocopy_realloc+0x9e/0x240 [] virtio_transport_send_pkt_info+0x412/0x4c0 [] virtio_transport_stream_enqueue+0x43/0x50 [] vsock_connectible_sendmsg+0x373/0x450 [] ____sys_sendmsg+0x365/0x3a0 [] ___sys_sendmsg+0x84/0xd0 [] __sys_sendmsg+0x47/0x80 [] do_syscall_64+0x93/0x180 [] entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53119", "url": "https://ubuntu.com/security/CVE-2024-53119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio/vsock: Fix accept_queue memory leak As the final stages of socket destruction may be delayed, it is possible that virtio_transport_recv_listen() will be called after the accept_queue has been flushed, but before the SOCK_DONE flag has been set. As a result, sockets enqueued after the flush would remain unremoved, leading to a memory leak. vsock_release __vsock_release lock virtio_transport_release virtio_transport_close schedule_delayed_work(close_work) sk_shutdown = SHUTDOWN_MASK (!) flush accept_queue release virtio_transport_recv_pkt vsock_find_bound_socket lock if flag(SOCK_DONE) return virtio_transport_recv_listen child = vsock_create_connected (!) vsock_enqueue_accept(child) release close_work lock virtio_transport_do_close set_flag(SOCK_DONE) virtio_transport_remove_sock vsock_remove_sock vsock_remove_bound release Introduce a sk_shutdown check to disallow vsock_enqueue_accept() during socket destruction. unreferenced object 0xffff888109e3f800 (size 2040): comm \"kworker/5:2\", pid 371, jiffies 4294940105 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00 (..@............ backtrace (crc 9e5f4e84): [] kmem_cache_alloc_noprof+0x2c1/0x360 [] sk_prot_alloc+0x30/0x120 [] sk_alloc+0x2c/0x4b0 [] __vsock_create.constprop.0+0x2a/0x310 [] virtio_transport_recv_pkt+0x4dc/0x9a0 [] vsock_loopback_work+0xfd/0x140 [] process_one_work+0x20c/0x570 [] worker_thread+0x1bf/0x3a0 [] kthread+0xdd/0x110 [] ret_from_fork+0x2d/0x50 [] ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53120", "url": "https://ubuntu.com/security/CVE-2024-53120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: CT: Fix null-ptr-deref in add rule err flow In error flow of mlx5_tc_ct_entry_add_rule(), in case ct_rule_add() callback returns error, zone_rule->attr is used uninitiated. Fix it to use attr which has the needed pointer value. Kernel log: BUG: kernel NULL pointer dereference, address: 0000000000000110 RIP: 0010:mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core] … Call Trace: ? __die+0x20/0x70 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x140 ? asm_exc_page_fault+0x22/0x30 ? mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core] ? mlx5_tc_ct_entry_add_rule+0x1d5/0x2f0 [mlx5_core] mlx5_tc_ct_block_flow_offload+0xc6a/0xf90 [mlx5_core] ? nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] flow_offload_work_handler+0x142/0x320 [nf_flow_table] ? finish_task_switch.isra.0+0x15b/0x2b0 process_one_work+0x16c/0x320 worker_thread+0x28c/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xb8/0xf0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53138", "url": "https://ubuntu.com/security/CVE-2024-53138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: kTLS, Fix incorrect page refcounting The kTLS tx handling code is using a mix of get_page() and page_ref_inc() APIs to increment the page reference. But on the release path (mlx5e_ktls_tx_handle_resync_dump_comp()), only put_page() is used. This is an issue when using pages from large folios: the get_page() references are stored on the folio page while the page_ref_inc() references are stored directly in the given page. On release the folio page will be dereferenced too many times. This was found while doing kTLS testing with sendfile() + ZC when the served file was read from NFS on a kernel with NFS large folios support (commit 49b29a573da8 (\"nfs: add support for large folios\")).", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53121", "url": "https://ubuntu.com/security/CVE-2024-53121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: fs, lock FTE when checking if active The referenced commits introduced a two-step process for deleting FTEs: - Lock the FTE, delete it from hardware, set the hardware deletion function to NULL and unlock the FTE. - Lock the parent flow group, delete the software copy of the FTE, and remove it from the xarray. However, this approach encounters a race condition if a rule with the same match value is added simultaneously. In this scenario, fs_core may set the hardware deletion function to NULL prematurely, causing a panic during subsequent rule deletions. To prevent this, ensure the active flag of the FTE is checked under a lock, which will prevent the fs_core layer from attaching a new steering rule to an FTE that is in the process of deletion. [ 438.967589] MOSHE: 2496 mlx5_del_flow_rules del_hw_func [ 438.968205] ------------[ cut here ]------------ [ 438.968654] refcount_t: decrement hit 0; leaking memory. [ 438.969249] WARNING: CPU: 0 PID: 8957 at lib/refcount.c:31 refcount_warn_saturate+0xfb/0x110 [ 438.970054] Modules linked in: act_mirred cls_flower act_gact sch_ingress openvswitch nsh mlx5_vdpa vringh vhost_iotlb vdpa mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core zram zsmalloc fuse [last unloaded: cls_flower] [ 438.973288] CPU: 0 UID: 0 PID: 8957 Comm: tc Not tainted 6.12.0-rc1+ #8 [ 438.973888] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 438.974874] RIP: 0010:refcount_warn_saturate+0xfb/0x110 [ 438.975363] Code: 40 66 3b 82 c6 05 16 e9 4d 01 01 e8 1f 7c a0 ff 0f 0b c3 cc cc cc cc 48 c7 c7 10 66 3b 82 c6 05 fd e8 4d 01 01 e8 05 7c a0 ff <0f> 0b c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 90 [ 438.976947] RSP: 0018:ffff888124a53610 EFLAGS: 00010286 [ 438.977446] RAX: 0000000000000000 RBX: ffff888119d56de0 RCX: 0000000000000000 [ 438.978090] RDX: ffff88852c828700 RSI: ffff88852c81b3c0 RDI: ffff88852c81b3c0 [ 438.978721] RBP: ffff888120fa0e88 R08: 0000000000000000 R09: ffff888124a534b0 [ 438.979353] R10: 0000000000000001 R11: 0000000000000001 R12: ffff888119d56de0 [ 438.979979] R13: ffff888120fa0ec0 R14: ffff888120fa0ee8 R15: ffff888119d56de0 [ 438.980607] FS: 00007fe6dcc0f800(0000) GS:ffff88852c800000(0000) knlGS:0000000000000000 [ 438.983984] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 438.984544] CR2: 00000000004275e0 CR3: 0000000186982001 CR4: 0000000000372eb0 [ 438.985205] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 438.985842] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 438.986507] Call Trace: [ 438.986799] [ 438.987070] ? __warn+0x7d/0x110 [ 438.987426] ? refcount_warn_saturate+0xfb/0x110 [ 438.987877] ? report_bug+0x17d/0x190 [ 438.988261] ? prb_read_valid+0x17/0x20 [ 438.988659] ? handle_bug+0x53/0x90 [ 438.989054] ? exc_invalid_op+0x14/0x70 [ 438.989458] ? asm_exc_invalid_op+0x16/0x20 [ 438.989883] ? refcount_warn_saturate+0xfb/0x110 [ 438.990348] mlx5_del_flow_rules+0x2f7/0x340 [mlx5_core] [ 438.990932] __mlx5_eswitch_del_rule+0x49/0x170 [mlx5_core] [ 438.991519] ? mlx5_lag_is_sriov+0x3c/0x50 [mlx5_core] [ 438.992054] ? xas_load+0x9/0xb0 [ 438.992407] mlx5e_tc_rule_unoffload+0x45/0xe0 [mlx5_core] [ 438.993037] mlx5e_tc_del_fdb_flow+0x2a6/0x2e0 [mlx5_core] [ 438.993623] mlx5e_flow_put+0x29/0x60 [mlx5_core] [ 438.994161] mlx5e_delete_flower+0x261/0x390 [mlx5_core] [ 438.994728] tc_setup_cb_destroy+0xb9/0x190 [ 438.995150] fl_hw_destroy_filter+0x94/0xc0 [cls_flower] [ 438.995650] fl_change+0x11a4/0x13c0 [cls_flower] [ 438.996105] tc_new_tfilter+0x347/0xbc0 [ 438.996503] ? __ ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53122", "url": "https://ubuntu.com/security/CVE-2024-53122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: cope racing subflow creation in mptcp_rcv_space_adjust Additional active subflows - i.e. created by the in kernel path manager - are included into the subflow list before starting the 3whs. A racing recvmsg() spooling data received on an already established subflow would unconditionally call tcp_cleanup_rbuf() on all the current subflows, potentially hitting a divide by zero error on the newly created ones. Explicitly check that the subflow is in a suitable state before invoking tcp_cleanup_rbuf().", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53123", "url": "https://ubuntu.com/security/CVE-2024-53123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: error out earlier on disconnect Eric reported a division by zero splat in the MPTCP protocol: Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 6094 Comm: syz-executor317 Not tainted 6.12.0-rc5-syzkaller-00291-g05b92660cdfe #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:__tcp_select_window+0x5b4/0x1310 net/ipv4/tcp_output.c:3163 Code: f6 44 01 e3 89 df e8 9b 75 09 f8 44 39 f3 0f 8d 11 ff ff ff e8 0d 74 09 f8 45 89 f4 e9 04 ff ff ff e8 00 74 09 f8 44 89 f0 99 7c 24 14 41 29 d6 45 89 f4 e9 ec fe ff ff e8 e8 73 09 f8 48 89 RSP: 0018:ffffc900041f7930 EFLAGS: 00010293 RAX: 0000000000017e67 RBX: 0000000000017e67 RCX: ffffffff8983314b RDX: 0000000000000000 RSI: ffffffff898331b0 RDI: 0000000000000004 RBP: 00000000005d6000 R08: 0000000000000004 R09: 0000000000017e67 R10: 0000000000003e80 R11: 0000000000000000 R12: 0000000000003e80 R13: ffff888031d9b440 R14: 0000000000017e67 R15: 00000000002eb000 FS: 00007feb5d7f16c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007feb5d8adbb8 CR3: 0000000074e4c000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __tcp_cleanup_rbuf+0x3e7/0x4b0 net/ipv4/tcp.c:1493 mptcp_rcv_space_adjust net/mptcp/protocol.c:2085 [inline] mptcp_recvmsg+0x2156/0x2600 net/mptcp/protocol.c:2289 inet_recvmsg+0x469/0x6a0 net/ipv4/af_inet.c:885 sock_recvmsg_nosec net/socket.c:1051 [inline] sock_recvmsg+0x1b2/0x250 net/socket.c:1073 __sys_recvfrom+0x1a5/0x2e0 net/socket.c:2265 __do_sys_recvfrom net/socket.c:2283 [inline] __se_sys_recvfrom net/socket.c:2279 [inline] __x64_sys_recvfrom+0xe0/0x1c0 net/socket.c:2279 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 RIP: 0033:0x7feb5d857559 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:00007feb5d7f1208 EFLAGS: 00000246 ORIG_RAX: 000000000000002d RAX: ffffffffffffffda RBX: 00007feb5d8e1318 RCX: 00007feb5d857559 RDX: 000000800000000e RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007feb5d8e1310 R08: 0000000000000000 R09: ffffffff81000000 R10: 0000000000000100 R11: 0000000000000246 R12: 00007feb5d8e131c R13: 00007feb5d8ae074 R14: 000000800000000e R15: 00000000fffffdef and provided a nice reproducer. The root cause is the current bad handling of racing disconnect. After the blamed commit below, sk_wait_data() can return (with error) with the underlying socket disconnected and a zero rcv_mss. Catch the error and return without performing any additional operations on the current socket.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53124", "url": "https://ubuntu.com/security/CVE-2024-53124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix data-races around sk->sk_forward_alloc Syzkaller reported this warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 16 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x1c5/0x1e0 Modules linked in: CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:inet_sock_destruct+0x1c5/0x1e0 Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 <0f> 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00 RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206 RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007 RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00 RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007 R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00 R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78 FS: 0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn+0x88/0x130 ? inet_sock_destruct+0x1c5/0x1e0 ? report_bug+0x18e/0x1a0 ? handle_bug+0x53/0x90 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? inet_sock_destruct+0x1c5/0x1e0 __sk_destruct+0x2a/0x200 rcu_do_batch+0x1aa/0x530 ? rcu_do_batch+0x13b/0x530 rcu_core+0x159/0x2f0 handle_softirqs+0xd3/0x2b0 ? __pfx_smpboot_thread_fn+0x10/0x10 run_ksoftirqd+0x25/0x30 smpboot_thread_fn+0xdd/0x1d0 kthread+0xd3/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ---[ end trace 0000000000000000 ]--- Its possible that two threads call tcp_v6_do_rcv()/sk_forward_alloc_add() concurrently when sk->sk_state == TCP_LISTEN with sk->sk_lock unlocked, which triggers a data-race around sk->sk_forward_alloc: tcp_v6_rcv tcp_v6_do_rcv skb_clone_and_charge_r sk_rmem_schedule __sk_mem_schedule sk_forward_alloc_add() skb_set_owner_r sk_mem_charge sk_forward_alloc_add() __kfree_skb skb_release_all skb_release_head_state sock_rfree sk_mem_uncharge sk_forward_alloc_add() sk_mem_reclaim // set local var reclaimable __sk_mem_reclaim sk_forward_alloc_add() In this syzkaller testcase, two threads call tcp_v6_do_rcv() with skb->truesize=768, the sk_forward_alloc changes like this: (cpu 1) | (cpu 2) | sk_forward_alloc ... | ... | 0 __sk_mem_schedule() | | +4096 = 4096 | __sk_mem_schedule() | +4096 = 8192 sk_mem_charge() | | -768 = 7424 | sk_mem_charge() | -768 = 6656 ... | ... | sk_mem_uncharge() | | +768 = 7424 reclaimable=7424 | | | sk_mem_uncharge() | +768 = 8192 | reclaimable=8192 | __sk_mem_reclaim() | | -4096 = 4096 | __sk_mem_reclaim() | -8192 = -4096 != 0 The skb_clone_and_charge_r() should not be called in tcp_v6_do_rcv() when sk->sk_state is TCP_LISTEN, it happens later in tcp_v6_syn_recv_sock(). Fix the same issue in dccp_v6_do_rcv().", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53129", "url": "https://ubuntu.com/security/CVE-2024-53129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: vop: Fix a dereferenced before check warning The 'state' can't be NULL, we should check crtc_state. Fix warning: drivers/gpu/drm/rockchip/rockchip_drm_vop.c:1096 vop_plane_atomic_async_check() warn: variable dereferenced before check 'state' (see line 1077)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53139", "url": "https://ubuntu.com/security/CVE-2024-53139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix possible UAF in sctp_v6_available() A lockdep report [1] with CONFIG_PROVE_RCU_LIST=y hints that sctp_v6_available() is calling dev_get_by_index_rcu() and ipv6_chk_addr() without holding rcu. [1] ============================= WARNING: suspicious RCU usage 6.12.0-rc5-virtme #1216 Tainted: G W ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by sctp_hello/31495: #0: ffff9f1ebbdb7418 (sk_lock-AF_INET6){+.+.}-{0:0}, at: sctp_bind (./arch/x86/include/asm/jump_label.h:27 net/sctp/socket.c:315) sctp stack backtrace: CPU: 7 UID: 0 PID: 31495 Comm: sctp_hello Tainted: G W 6.12.0-rc5-virtme #1216 Tainted: [W]=WARN 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:123) lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822) dev_get_by_index_rcu (net/core/dev.c:876 (discriminator 7)) sctp_v6_available (net/sctp/ipv6.c:701) sctp sctp_do_bind (net/sctp/socket.c:400 (discriminator 1)) sctp sctp_bind (net/sctp/socket.c:320) sctp inet6_bind_sk (net/ipv6/af_inet6.c:465) ? security_socket_bind (security/security.c:4581 (discriminator 1)) __sys_bind (net/socket.c:1848 net/socket.c:1869) ? do_user_addr_fault (./include/linux/rcupdate.h:347 ./include/linux/rcupdate.h:880 ./include/linux/mm.h:729 arch/x86/mm/fault.c:1340) ? do_user_addr_fault (./arch/x86/include/asm/preempt.h:84 (discriminator 13) ./include/linux/rcupdate.h:98 (discriminator 13) ./include/linux/rcupdate.h:882 (discriminator 13) ./include/linux/mm.h:729 (discriminator 13) arch/x86/mm/fault.c:1340 (discriminator 13)) __x64_sys_bind (net/socket.c:1877 (discriminator 1) net/socket.c:1875 (discriminator 1) net/socket.c:1875 (discriminator 1)) do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f59b934a1e7 Code: 44 00 00 48 8b 15 39 8c 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 b8 31 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 09 8c 0c 00 f7 d8 64 89 01 48 All code ======== 0:\t44 00 00 \tadd %r8b,(%rax) 3:\t48 8b 15 39 8c 0c 00 \tmov 0xc8c39(%rip),%rdx # 0xc8c43 a:\tf7 d8 \tneg %eax c:\t64 89 02 \tmov %eax,%fs:(%rdx) f:\tb8 ff ff ff ff \tmov $0xffffffff,%eax 14:\teb bd \tjmp 0xffffffffffffffd3 16:\t66 2e 0f 1f 84 00 00 \tcs nopw 0x0(%rax,%rax,1) 1d:\t00 00 00 20:\t0f 1f 00 \tnopl (%rax) 23:\tb8 31 00 00 00 \tmov $0x31,%eax 28:\t0f 05 \tsyscall 2a:*\t48 3d 01 f0 ff ff \tcmp $0xfffffffffffff001,%rax\t\t<-- trapping instruction 30:\t73 01 \tjae 0x33 32:\tc3 \tret 33:\t48 8b 0d 09 8c 0c 00 \tmov 0xc8c09(%rip),%rcx # 0xc8c43 3a:\tf7 d8 \tneg %eax 3c:\t64 89 01 \tmov %eax,%fs:(%rcx) 3f:\t48 \trex.W Code starting with the faulting instruction =========================================== 0:\t48 3d 01 f0 ff ff \tcmp $0xfffffffffffff001,%rax 6:\t73 01 \tjae 0x9 8:\tc3 \tret 9:\t48 8b 0d 09 8c 0c 00 \tmov 0xc8c09(%rip),%rcx # 0xc8c19 10:\tf7 d8 \tneg %eax 12:\t64 89 01 \tmov %eax,%fs:(%rcx) 15:\t48 \trex.W RSP: 002b:00007ffe2d0ad398 EFLAGS: 00000202 ORIG_RAX: 0000000000000031 RAX: ffffffffffffffda RBX: 00007ffe2d0ad3d0 RCX: 00007f59b934a1e7 RDX: 000000000000001c RSI: 00007ffe2d0ad3d0 RDI: 0000000000000005 RBP: 0000000000000005 R08: 1999999999999999 R09: 0000000000000000 R10: 00007f59b9253298 R11: 000000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53140", "url": "https://ubuntu.com/security/CVE-2024-53140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netlink: terminate outstanding dump on socket close Netlink supports iterative dumping of data. It provides the families the following ops: - start - (optional) kicks off the dumping process - dump - actual dump helper, keeps getting called until it returns 0 - done - (optional) pairs with .start, can be used for cleanup The whole process is asynchronous and the repeated calls to .dump don't actually happen in a tight loop, but rather are triggered in response to recvmsg() on the socket. This gives the user full control over the dump, but also means that the user can close the socket without getting to the end of the dump. To make sure .start is always paired with .done we check if there is an ongoing dump before freeing the socket, and if so call .done. The complication is that sockets can get freed from BH and .done is allowed to sleep. So we use a workqueue to defer the call, when needed. Unfortunately this does not work correctly. What we defer is not the cleanup but rather releasing a reference on the socket. We have no guarantee that we own the last reference, if someone else holds the socket they may release it in BH and we're back to square one. The whole dance, however, appears to be unnecessary. Only the user can interact with dumps, so we can clean up when socket is closed. And close always happens in process context. Some async code may still access the socket after close, queue notification skbs to it etc. but no dumps can start, end or otherwise make progress. Delete the workqueue and flush the dump state directly from the release handler. Note that further cleanup is possible in -next, for instance we now always call .done before releasing the main module reference, so dump doesn't have to take a reference of its own.", "cve_priority": "high", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53098", "url": "https://ubuntu.com/security/CVE-2024-53098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/ufence: Prefetch ufence addr to catch bogus address access_ok() only checks for addr overflow so also try to read the addr to catch invalid addr sent from userspace. (cherry picked from commit 9408c4508483ffc60811e910a93d6425b8e63928)", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53099", "url": "https://ubuntu.com/security/CVE-2024-53099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check validity of link->type in bpf_link_show_fdinfo() If a newly-added link type doesn't invoke BPF_LINK_TYPE(), accessing bpf_link_type_strs[link->type] may result in an out-of-bounds access. To spot such missed invocations early in the future, checking the validity of link->type in bpf_link_show_fdinfo() and emitting a warning when such invocations are missed.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53089", "url": "https://ubuntu.com/security/CVE-2024-53089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: KVM: Mark hrtimer to expire in hard interrupt context Like commit 2c0d278f3293f (\"KVM: LAPIC: Mark hrtimer to expire in hard interrupt context\") and commit 9090825fa9974 (\"KVM: arm/arm64: Let the timer expire in hardirq context on RT\"), On PREEMPT_RT enabled kernels unmarked hrtimers are moved into soft interrupt expiry mode by default. Then the timers are canceled from an preempt-notifier which is invoked with disabled preemption which is not allowed on PREEMPT_RT. The timer callback is short so in could be invoked in hard-IRQ context. So let the timer expire on hard-IRQ context even on -RT. This fix a \"scheduling while atomic\" bug for PREEMPT_RT enabled kernels: BUG: scheduling while atomic: qemu-system-loo/1011/0x00000002 Modules linked in: amdgpu rfkill nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat ns CPU: 1 UID: 0 PID: 1011 Comm: qemu-system-loo Tainted: G W 6.12.0-rc2+ #1774 Tainted: [W]=WARN Hardware name: Loongson Loongson-3A5000-7A1000-1w-CRB/Loongson-LS3A5000-7A1000-1w-CRB, BIOS vUDK2018-LoongArch-V2.0.0-prebeta9 10/21/2022 Stack : ffffffffffffffff 0000000000000000 9000000004e3ea38 9000000116744000 90000001167475a0 0000000000000000 90000001167475a8 9000000005644830 90000000058dc000 90000000058dbff8 9000000116747420 0000000000000001 0000000000000001 6a613fc938313980 000000000790c000 90000001001c1140 00000000000003fe 0000000000000001 000000000000000d 0000000000000003 0000000000000030 00000000000003f3 000000000790c000 9000000116747830 90000000057ef000 0000000000000000 9000000005644830 0000000000000004 0000000000000000 90000000057f4b58 0000000000000001 9000000116747868 900000000451b600 9000000005644830 9000000003a13998 0000000010000020 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d ... Call Trace: [<9000000003a13998>] show_stack+0x38/0x180 [<9000000004e3ea34>] dump_stack_lvl+0x84/0xc0 [<9000000003a71708>] __schedule_bug+0x48/0x60 [<9000000004e45734>] __schedule+0x1114/0x1660 [<9000000004e46040>] schedule_rtlock+0x20/0x60 [<9000000004e4e330>] rtlock_slowlock_locked+0x3f0/0x10a0 [<9000000004e4f038>] rt_spin_lock+0x58/0x80 [<9000000003b02d68>] hrtimer_cancel_wait_running+0x68/0xc0 [<9000000003b02e30>] hrtimer_cancel+0x70/0x80 [] kvm_restore_timer+0x50/0x1a0 [kvm] [] kvm_arch_vcpu_load+0x68/0x2a0 [kvm] [] kvm_sched_in+0x34/0x60 [kvm] [<9000000003a749a0>] finish_task_switch.isra.0+0x140/0x2e0 [<9000000004e44a70>] __schedule+0x450/0x1660 [<9000000004e45cb0>] schedule+0x30/0x180 [] kvm_vcpu_block+0x70/0x120 [kvm] [] kvm_vcpu_halt+0x60/0x3e0 [kvm] [] kvm_handle_gspr+0x3f4/0x4e0 [kvm] [] kvm_handle_exit+0x1c8/0x260 [kvm]", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53090", "url": "https://ubuntu.com/security/CVE-2024-53090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix lock recursion afs_wake_up_async_call() can incur lock recursion. The problem is that it is called from AF_RXRPC whilst holding the ->notify_lock, but it tries to take a ref on the afs_call struct in order to pass it to a work queue - but if the afs_call is already queued, we then have an extraneous ref that must be put... calling afs_put_call() may call back down into AF_RXRPC through rxrpc_kernel_shutdown_call(), however, which might try taking the ->notify_lock again. This case isn't very common, however, so defer it to a workqueue. The oops looks something like: BUG: spinlock recursion on CPU#0, krxrpcio/7001/1646 lock: 0xffff888141399b30, .magic: dead4ead, .owner: krxrpcio/7001/1646, .owner_cpu: 0 CPU: 0 UID: 0 PID: 1646 Comm: krxrpcio/7001 Not tainted 6.12.0-rc2-build3+ #4351 Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014 Call Trace: dump_stack_lvl+0x47/0x70 do_raw_spin_lock+0x3c/0x90 rxrpc_kernel_shutdown_call+0x83/0xb0 afs_put_call+0xd7/0x180 rxrpc_notify_socket+0xa0/0x190 rxrpc_input_split_jumbo+0x198/0x1d0 rxrpc_input_data+0x14b/0x1e0 ? rxrpc_input_call_packet+0xc2/0x1f0 rxrpc_input_call_event+0xad/0x6b0 rxrpc_input_packet_on_conn+0x1e1/0x210 rxrpc_input_packet+0x3f2/0x4d0 rxrpc_io_thread+0x243/0x410 ? __pfx_rxrpc_io_thread+0x10/0x10 kthread+0xcf/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x24/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53101", "url": "https://ubuntu.com/security/CVE-2024-53101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized value issue in from_kuid and from_kgid ocfs2_setattr() uses attr->ia_mode, attr->ia_uid and attr->ia_gid in a trace point even though ATTR_MODE, ATTR_UID and ATTR_GID aren't set. Initialize all fields of newattrs to avoid uninitialized variables, by checking if ATTR_MODE, ATTR_UID, ATTR_GID are initialized, otherwise 0.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53091", "url": "https://ubuntu.com/security/CVE-2024-53091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Add sk_is_inet and IS_ICSK check in tls_sw_has_ctx_tx/rx As the introduction of the support for vsock and unix sockets in sockmap, tls_sw_has_ctx_tx/rx cannot presume the socket passed in must be IS_ICSK. vsock and af_unix sockets have vsock_sock and unix_sock instead of inet_connection_sock. For these sockets, tls_get_ctx may return an invalid pointer and cause page fault in function tls_sw_ctx_rx. BUG: unable to handle page fault for address: 0000000000040030 Workqueue: vsock-loopback vsock_loopback_work RIP: 0010:sk_psock_strp_data_ready+0x23/0x60 Call Trace: ? __die+0x81/0xc3 ? no_context+0x194/0x350 ? do_page_fault+0x30/0x110 ? async_page_fault+0x3e/0x50 ? sk_psock_strp_data_ready+0x23/0x60 virtio_transport_recv_pkt+0x750/0x800 ? update_load_avg+0x7e/0x620 vsock_loopback_work+0xd0/0x100 process_one_work+0x1a7/0x360 worker_thread+0x30/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x112/0x130 ? __kthread_cancel_work+0x40/0x40 ret_from_fork+0x1f/0x40 v2: - Add IS_ICSK check v3: - Update the commits in Fixes", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53092", "url": "https://ubuntu.com/security/CVE-2024-53092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_pci: Fix admin vq cleanup by using correct info pointer vp_modern_avq_cleanup() and vp_del_vqs() clean up admin vq resources by virtio_pci_vq_info pointer. The info pointer of admin vq is stored in vp_dev->admin_vq.info instead of vp_dev->vqs[]. Using the info pointer from vp_dev->vqs[] for admin vq causes a kernel NULL pointer dereference bug. In vp_modern_avq_cleanup() and vp_del_vqs(), get the info pointer from vp_dev->admin_vq.info for admin vq to clean up the resources. Also make info ptr as argument of vp_del_vq() to be symmetric with vp_setup_vq(). vp_reset calls vp_modern_avq_cleanup, and causes the Call Trace: ================================================================== BUG: kernel NULL pointer dereference, address:0000000000000000 ... CPU: 49 UID: 0 PID: 4439 Comm: modprobe Not tainted 6.11.0-rc5 #1 RIP: 0010:vp_reset+0x57/0x90 [virtio_pci] Call Trace: ... ? vp_reset+0x57/0x90 [virtio_pci] ? vp_reset+0x38/0x90 [virtio_pci] virtio_reset_device+0x1d/0x30 remove_vq_common+0x1c/0x1a0 [virtio_net] virtnet_remove+0xa1/0xc0 [virtio_net] virtio_dev_remove+0x46/0xa0 ... virtio_pci_driver_exit+0x14/0x810 [virtio_pci] ==================================================================", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53102", "url": "https://ubuntu.com/security/CVE-2024-53102", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53093", "url": "https://ubuntu.com/security/CVE-2024-53093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: defer partition scanning We need to suppress the partition scan from occuring within the controller's scan_work context. If a path error occurs here, the IO will wait until a path becomes available or all paths are torn down, but that action also occurs within scan_work, so it would deadlock. Defer the partion scan to a different context that does not block scan_work.", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53094", "url": "https://ubuntu.com/security/CVE-2024-53094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Add sendpage_ok() check to disable MSG_SPLICE_PAGES While running ISER over SIW, the initiator machine encounters a warning from skb_splice_from_iter() indicating that a slab page is being used in send_page. To address this, it is better to add a sendpage_ok() check within the driver itself, and if it returns 0, then MSG_SPLICE_PAGES flag should be disabled before entering the network stack. A similar issue has been discussed for NVMe in this thread: https://lore.kernel.org/all/20240530142417.146696-1-ofir.gal@volumez.com/ WARNING: CPU: 0 PID: 5342 at net/core/skbuff.c:7140 skb_splice_from_iter+0x173/0x320 Call Trace: tcp_sendmsg_locked+0x368/0xe40 siw_tx_hdt+0x695/0xa40 [siw] siw_qp_sq_process+0x102/0xb00 [siw] siw_sq_resume+0x39/0x110 [siw] siw_run_sq+0x74/0x160 [siw] kthread+0xd2/0x100 ret_from_fork+0x34/0x40 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53100", "url": "https://ubuntu.com/security/CVE-2024-53100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: tcp: avoid race between queue_lock lock and destroy Commit 76d54bf20cdc (\"nvme-tcp: don't access released socket during error recovery\") added a mutex_lock() call for the queue->queue_lock in nvme_tcp_get_address(). However, the mutex_lock() races with mutex_destroy() in nvme_tcp_free_queue(), and causes the WARN below. DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: CPU: 3 PID: 34077 at kernel/locking/mutex.c:587 __mutex_lock+0xcf0/0x1220 Modules linked in: nvmet_tcp nvmet nvme_tcp nvme_fabrics iw_cm ib_cm ib_core pktcdvd nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables qrtr sunrpc ppdev 9pnet_virtio 9pnet pcspkr netfs parport_pc parport e1000 i2c_piix4 i2c_smbus loop fuse nfnetlink zram bochs drm_vram_helper drm_ttm_helper ttm drm_kms_helper xfs drm sym53c8xx floppy nvme scsi_transport_spi nvme_core nvme_auth serio_raw ata_generic pata_acpi dm_multipath qemu_fw_cfg [last unloaded: ib_uverbs] CPU: 3 UID: 0 PID: 34077 Comm: udisksd Not tainted 6.11.0-rc7 #319 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:__mutex_lock+0xcf0/0x1220 Code: 08 84 d2 0f 85 c8 04 00 00 8b 15 ef b6 c8 01 85 d2 0f 85 78 f4 ff ff 48 c7 c6 20 93 ee af 48 c7 c7 60 91 ee af e8 f0 a7 6d fd <0f> 0b e9 5e f4 ff ff 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 RSP: 0018:ffff88811305f760 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff88812c652058 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000001 RBP: ffff88811305f8b0 R08: 0000000000000001 R09: ffffed1075c36341 R10: ffff8883ae1b1a0b R11: 0000000000010498 R12: 0000000000000000 R13: 0000000000000000 R14: dffffc0000000000 R15: ffff88812c652058 FS: 00007f9713ae4980(0000) GS:ffff8883ae180000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcd78483c7c CR3: 0000000122c38000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn.cold+0x5b/0x1af ? __mutex_lock+0xcf0/0x1220 ? report_bug+0x1ec/0x390 ? handle_bug+0x3c/0x80 ? exc_invalid_op+0x13/0x40 ? asm_exc_invalid_op+0x16/0x20 ? __mutex_lock+0xcf0/0x1220 ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] ? __pfx___mutex_lock+0x10/0x10 ? __lock_acquire+0xd6a/0x59e0 ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] ? __pfx_nvme_tcp_get_address+0x10/0x10 [nvme_tcp] nvme_sysfs_show_address+0x81/0xc0 [nvme_core] dev_attr_show+0x42/0x80 ? __asan_memset+0x1f/0x40 sysfs_kf_seq_show+0x1f0/0x370 seq_read_iter+0x2cb/0x1130 ? rw_verify_area+0x3b1/0x590 ? __mutex_lock+0x433/0x1220 vfs_read+0x6a6/0xa20 ? lockdep_hardirqs_on+0x78/0x100 ? __pfx_vfs_read+0x10/0x10 ksys_read+0xf7/0x1d0 ? __pfx_ksys_read+0x10/0x10 ? __x64_sys_openat+0x105/0x1d0 do_syscall_64+0x93/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? __pfx_ksys_read+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? do_syscall_64+0x9f/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f9713f55cfa Code: 55 48 89 e5 48 83 ec 20 48 89 55 e8 48 89 75 f0 89 7d f8 e8 e8 74 f8 ff 48 8b 55 e8 48 8b 75 f0 4 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53095", "url": "https://ubuntu.com/security/CVE-2024-53095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix use-after-free of network namespace. Recently, we got a customer report that CIFS triggers oops while reconnecting to a server. [0] The workload runs on Kubernetes, and some pods mount CIFS servers in non-root network namespaces. The problem rarely happened, but it was always while the pod was dying. The root cause is wrong reference counting for network namespace. CIFS uses kernel sockets, which do not hold refcnt of the netns that the socket belongs to. That means CIFS must ensure the socket is always freed before its netns; otherwise, use-after-free happens. The repro steps are roughly: 1. mount CIFS in a non-root netns 2. drop packets from the netns 3. destroy the netns 4. unmount CIFS We can reproduce the issue quickly with the script [1] below and see the splat [2] if CONFIG_NET_NS_REFCNT_TRACKER is enabled. When the socket is TCP, it is hard to guarantee the netns lifetime without holding refcnt due to async timers. Let's hold netns refcnt for each socket as done for SMC in commit 9744d2bf1976 (\"smc: Fix use-after-free in tcp_write_timer_handler().\"). Note that we need to move put_net() from cifs_put_tcp_session() to clean_demultiplex_info(); otherwise, __sock_create() still could touch a freed netns while cifsd tries to reconnect from cifs_demultiplex_thread(). Also, maybe_get_net() cannot be put just before __sock_create() because the code is not under RCU and there is a small chance that the same address happened to be reallocated to another netns. [0]: CIFS: VFS: \\\\XXXXXXXXXXX has not responded in 15 seconds. Reconnecting... CIFS: Serverclose failed 4 times, giving up Unable to handle kernel paging request at virtual address 14de99e461f84a07 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 CM = 0, WnR = 0 [14de99e461f84a07] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: cls_bpf sch_ingress nls_utf8 cifs cifs_arc4 cifs_md4 dns_resolver tcp_diag inet_diag veth xt_state xt_connmark nf_conntrack_netlink xt_nat xt_statistic xt_MASQUERADE xt_mark xt_addrtype ipt_REJECT nf_reject_ipv4 nft_chain_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment nft_compat nf_tables nfnetlink overlay nls_ascii nls_cp437 sunrpc vfat fat aes_ce_blk aes_ce_cipher ghash_ce sm4_ce_cipher sm4 sm3_ce sm3 sha3_ce sha512_ce sha512_arm64 sha1_ce ena button sch_fq_codel loop fuse configfs dmi_sysfs sha2_ce sha256_arm64 dm_mirror dm_region_hash dm_log dm_mod dax efivarfs CPU: 5 PID: 2690970 Comm: cifsd Not tainted 6.1.103-109.184.amzn2023.aarch64 #1 Hardware name: Amazon EC2 r7g.4xlarge/, BIOS 1.0 11/1/2018 pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : fib_rules_lookup+0x44/0x238 lr : __fib_lookup+0x64/0xbc sp : ffff8000265db790 x29: ffff8000265db790 x28: 0000000000000000 x27: 000000000000bd01 x26: 0000000000000000 x25: ffff000b4baf8000 x24: ffff00047b5e4580 x23: ffff8000265db7e0 x22: 0000000000000000 x21: ffff00047b5e4500 x20: ffff0010e3f694f8 x19: 14de99e461f849f7 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 3f92800abd010002 x11: 0000000000000001 x10: ffff0010e3f69420 x9 : ffff800008a6f294 x8 : 0000000000000000 x7 : 0000000000000006 x6 : 0000000000000000 x5 : 0000000000000001 x4 : ffff001924354280 x3 : ffff8000265db7e0 x2 : 0000000000000000 x1 : ffff0010e3f694f8 x0 : ffff00047b5e4500 Call trace: fib_rules_lookup+0x44/0x238 __fib_lookup+0x64/0xbc ip_route_output_key_hash_rcu+0x2c4/0x398 ip_route_output_key_hash+0x60/0x8c tcp_v4_connect+0x290/0x488 __inet_stream_connect+0x108/0x3d0 inet_stream_connect+0x50/0x78 kernel_connect+0x6c/0xac generic_ip_conne ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-50265", "url": "https://ubuntu.com/security/CVE-2024-50265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove() Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove(): [ 57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12 [ 57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry [ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004 [...] [ 57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [...] [ 57.331328] Call Trace: [ 57.331477] [...] [ 57.333511] ? do_user_addr_fault+0x3e5/0x740 [ 57.333778] ? exc_page_fault+0x70/0x170 [ 57.334016] ? asm_exc_page_fault+0x2b/0x30 [ 57.334263] ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10 [ 57.334596] ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [ 57.334913] ocfs2_xa_remove_entry+0x23/0xc0 [ 57.335164] ocfs2_xa_set+0x704/0xcf0 [ 57.335381] ? _raw_spin_unlock+0x1a/0x40 [ 57.335620] ? ocfs2_inode_cache_unlock+0x16/0x20 [ 57.335915] ? trace_preempt_on+0x1e/0x70 [ 57.336153] ? start_this_handle+0x16c/0x500 [ 57.336410] ? preempt_count_sub+0x50/0x80 [ 57.336656] ? _raw_read_unlock+0x20/0x40 [ 57.336906] ? start_this_handle+0x16c/0x500 [ 57.337162] ocfs2_xattr_block_set+0xa6/0x1e0 [ 57.337424] __ocfs2_xattr_set_handle+0x1fd/0x5d0 [ 57.337706] ? ocfs2_start_trans+0x13d/0x290 [ 57.337971] ocfs2_xattr_set+0xb13/0xfb0 [ 57.338207] ? dput+0x46/0x1c0 [ 57.338393] ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338665] ? ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338948] __vfs_removexattr+0x92/0xc0 [ 57.339182] __vfs_removexattr_locked+0xd5/0x190 [ 57.339456] ? preempt_count_sub+0x50/0x80 [ 57.339705] vfs_removexattr+0x5f/0x100 [...] Reproducer uses faultinject facility to fail ocfs2_xa_remove() -> ocfs2_xa_value_truncate() with -ENOMEM. In this case the comment mentions that we can return 0 if ocfs2_xa_cleanup_value_truncate() is going to wipe the entry anyway. But the following 'rc' check is wrong and execution flow do 'ocfs2_xa_remove_entry(loc);' twice: * 1st: in ocfs2_xa_cleanup_value_truncate(); * 2nd: returning back to ocfs2_xa_remove() instead of going to 'out'. Fix this by skipping the 2nd removal of the same entry and making syzkaller repro happy.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50266", "url": "https://ubuntu.com/security/CVE-2024-50266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: qcom: videocc-sm8350: use HW_CTRL_TRIGGER for vcodec GDSCs A recent change in the venus driver results in a stuck clock on the Lenovo ThinkPad X13s, for example, when streaming video in firefox: \tvideo_cc_mvs0_clk status stuck at 'off' \tWARNING: CPU: 6 PID: 2885 at drivers/clk/qcom/clk-branch.c:87 clk_branch_wait+0x144/0x15c \t... \tCall trace: \t clk_branch_wait+0x144/0x15c \t clk_branch2_enable+0x30/0x40 \t clk_core_enable+0xd8/0x29c \t clk_enable+0x2c/0x4c \t vcodec_clks_enable.isra.0+0x94/0xd8 [venus_core] \t coreid_power_v4+0x464/0x628 [venus_core] \t vdec_start_streaming+0xc4/0x510 [venus_dec] \t vb2_start_streaming+0x6c/0x180 [videobuf2_common] \t vb2_core_streamon+0x120/0x1dc [videobuf2_common] \t vb2_streamon+0x1c/0x6c [videobuf2_v4l2] \t v4l2_m2m_ioctl_streamon+0x30/0x80 [v4l2_mem2mem] \t v4l_streamon+0x24/0x30 [videodev] using the out-of-tree sm8350/sc8280xp venus support. [1] Update also the sm8350/sc8280xp GDSC definitions so that the hw control mode can be changed at runtime as the venus driver now requires.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50267", "url": "https://ubuntu.com/security/CVE-2024-50267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: fix use after free in debug printk The \"dev_dbg(&urb->dev->dev, ...\" which happens after usb_free_urb(urb) is a use after free of the \"urb\" pointer. Store the \"dev\" pointer at the start of the function to avoid this issue.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50268", "url": "https://ubuntu.com/security/CVE-2024-50268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: fix potential out of bounds in ucsi_ccg_update_set_new_cam_cmd() The \"*cmd\" variable can be controlled by the user via debugfs. That means \"new_cam\" can be as high as 255 while the size of the uc->updated[] array is UCSI_MAX_ALTMODES (30). The call tree is: ucsi_cmd() // val comes from simple_attr_write_xsigned() -> ucsi_send_command() -> ucsi_send_command_common() -> ucsi_run_command() // calls ucsi->ops->sync_control() -> ucsi_ccg_sync_control()", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53083", "url": "https://ubuntu.com/security/CVE-2024-53083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: qcom-pmic: init value of hdr_len/txbuf_len earlier If the read of USB_PDPHY_RX_ACKNOWLEDGE_REG failed, then hdr_len and txbuf_len are uninitialized. This commit stops to print uninitialized value and misleading/false data.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50269", "url": "https://ubuntu.com/security/CVE-2024-50269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: musb: sunxi: Fix accessing an released usb phy Commit 6ed05c68cbca (\"usb: musb: sunxi: Explicitly release USB PHY on exit\") will cause that usb phy @glue->xceiv is accessed after released. 1) register platform driver @sunxi_musb_driver // get the usb phy @glue->xceiv sunxi_musb_probe() -> devm_usb_get_phy(). 2) register and unregister platform driver @musb_driver musb_probe() -> sunxi_musb_init() use the phy here //the phy is released here musb_remove() -> sunxi_musb_exit() -> devm_usb_put_phy() 3) register @musb_driver again musb_probe() -> sunxi_musb_init() use the phy here but the phy has been released at 2). ... Fixed by reverting the commit, namely, removing devm_usb_put_phy() from sunxi_musb_exit().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53079", "url": "https://ubuntu.com/security/CVE-2024-53079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/thp: fix deferred split unqueue naming and locking Recent changes are putting more pressure on THP deferred split queues: under load revealing long-standing races, causing list_del corruptions, \"Bad page state\"s and worse (I keep BUGs in both of those, so usually don't get to see how badly they end up without). The relevant recent changes being 6.8's mTHP, 6.10's mTHP swapout, and 6.12's mTHP swapin, improved swap allocation, and underused THP splitting. Before fixing locking: rename misleading folio_undo_large_rmappable(), which does not undo large_rmappable, to folio_unqueue_deferred_split(), which is what it does. But that and its out-of-line __callee are mm internals of very limited usability: add comment and WARN_ON_ONCEs to check usage; and return a bool to say if a deferred split was unqueued, which can then be used in WARN_ON_ONCEs around safety checks (sparing callers the arcane conditionals in __folio_unqueue_deferred_split()). Just omit the folio_unqueue_deferred_split() from free_unref_folios(), all of whose callers now call it beforehand (and if any forget then bad_page() will tell) - except for its caller put_pages_list(), which itself no longer has any callers (and will be deleted separately). Swapout: mem_cgroup_swapout() has been resetting folio->memcg_data 0 without checking and unqueueing a THP folio from deferred split list; which is unfortunate, since the split_queue_lock depends on the memcg (when memcg is enabled); so swapout has been unqueueing such THPs later, when freeing the folio, using the pgdat's lock instead: potentially corrupting the memcg's list. __remove_mapping() has frozen refcount to 0 here, so no problem with calling folio_unqueue_deferred_split() before resetting memcg_data. That goes back to 5.4 commit 87eaceb3faa5 (\"mm: thp: make deferred split shrinker memcg aware\"): which included a check on swapcache before adding to deferred queue, but no check on deferred queue before adding THP to swapcache. That worked fine with the usual sequence of events in reclaim (though there were a couple of rare ways in which a THP on deferred queue could have been swapped out), but 6.12 commit dafff3f4c850 (\"mm: split underused THPs\") avoids splitting underused THPs in reclaim, which makes swapcache THPs on deferred queue commonplace. Keep the check on swapcache before adding to deferred queue? Yes: it is no longer essential, but preserves the existing behaviour, and is likely to be a worthwhile optimization (vmstat showed much more traffic on the queue under swapping load if the check was removed); update its comment. Memcg-v1 move (deprecated): mem_cgroup_move_account() has been changing folio->memcg_data without checking and unqueueing a THP folio from the deferred list, sometimes corrupting \"from\" memcg's list, like swapout. Refcount is non-zero here, so folio_unqueue_deferred_split() can only be used in a WARN_ON_ONCE to validate the fix, which must be done earlier: mem_cgroup_move_charge_pte_range() first try to split the THP (splitting of course unqueues), or skip it if that fails. Not ideal, but moving charge has been requested, and khugepaged should repair the THP later: nobody wants new custom unqueueing code just for this deprecated case. The 87eaceb3faa5 commit did have the code to move from one deferred list to another (but was not conscious of its unsafety while refcount non-0); but that was removed by 5.6 commit fac0516b5534 (\"mm: thp: don't need care deferred split queue in memcg charge move path\"), which argued that the existence of a PMD mapping guarantees that the THP cannot be on a deferred list. As above, false in rare cases, and now commonly false. Backport to 6.11 should be straightforward. Earlier backports must take care that other _deferred_list fixes and dependencies are included. There is not a strong case for backports, but they can fix cornercases.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50270", "url": "https://ubuntu.com/security/CVE-2024-50270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: avoid overflow in damon_feed_loop_next_input() damon_feed_loop_next_input() is inefficient and fragile to overflows. Specifically, 'score_goal_diff_bp' calculation can overflow when 'score' is high. The calculation is actually unnecessary at all because 'goal' is a constant of value 10,000. Calculation of 'compensation' is again fragile to overflow. Final calculation of return value for under-achiving case is again fragile to overflow when the current score is under-achieving the target. Add two corner cases handling at the beginning of the function to make the body easier to read, and rewrite the body of the function to avoid overflows and the unnecessary bp value calcuation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50271", "url": "https://ubuntu.com/security/CVE-2024-50271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: signal: restore the override_rlimit logic Prior to commit d64696905554 (\"Reimplement RLIMIT_SIGPENDING on top of ucounts\") UCOUNT_RLIMIT_SIGPENDING rlimit was not enforced for a class of signals. However now it's enforced unconditionally, even if override_rlimit is set. This behavior change caused production issues. For example, if the limit is reached and a process receives a SIGSEGV signal, sigqueue_alloc fails to allocate the necessary resources for the signal delivery, preventing the signal from being delivered with siginfo. This prevents the process from correctly identifying the fault address and handling the error. From the user-space perspective, applications are unaware that the limit has been reached and that the siginfo is effectively 'corrupted'. This can lead to unpredictable behavior and crashes, as we observed with java applications. Fix this by passing override_rlimit into inc_rlimit_get_ucounts() and skip the comparison to max there if override_rlimit is set. This effectively restores the old behavior.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50272", "url": "https://ubuntu.com/security/CVE-2024-50272", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: filemap: Fix bounds checking in filemap_read() If the caller supplies an iocb->ki_pos value that is close to the filesystem upper limit, and an iterator with a count that causes us to overflow that limit, then filemap_read() enters an infinite loop. This behaviour was discovered when testing xfstests generic/525 with the \"localio\" optimisation for loopback NFS mounts.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53104", "url": "https://ubuntu.com/security/CVE-2024-53104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_parse_format This can lead to out of bounds writes since frames of this type were not taken into account when calculating the size of the frames buffer in uvc_parse_streaming.", "cve_priority": "high", "cve_public_date": "2024-12-02 08:15:00 UTC" }, { "cve": "CVE-2024-50273", "url": "https://ubuntu.com/security/CVE-2024-50273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reinitialize delayed ref list after deleting it from the list At insert_delayed_ref() if we need to update the action of an existing ref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head's ref_add_list using list_del(), which leaves the ref's add_list member not reinitialized, as list_del() sets the next and prev members of the list to LIST_POISON1 and LIST_POISON2, respectively. If later we end up calling drop_delayed_ref() against the ref, which can happen during merging or when destroying delayed refs due to a transaction abort, we can trigger a crash since at drop_delayed_ref() we call list_empty() against the ref's add_list, which returns false since the list was not reinitialized after the list_del() and as a consequence we call list_del() again at drop_delayed_ref(). This results in an invalid list access since the next and prev members are set to poison pointers, resulting in a splat if CONFIG_LIST_HARDENED and CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences otherwise. So fix this by deleting from the list with list_del_init() instead.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53064", "url": "https://ubuntu.com/security/CVE-2024-53064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix idpf_vc_core_init error path In an event where the platform running the device control plane is rebooted, reset is detected on the driver. It releases all the resources and waits for the reset to complete. Once the reset is done, it tries to build the resources back. At this time if the device control plane is not yet started, then the driver timeouts on the virtchnl message and retries to establish the mailbox again. In the retry flow, mailbox is deinitialized but the mailbox workqueue is still alive and polling for the mailbox message. This results in accessing the released control queue leading to null-ptr-deref. Fix it by unrolling the work queue cancellation and mailbox deinitialization in the reverse order which they got initialized.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50274", "url": "https://ubuntu.com/security/CVE-2024-50274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: avoid vport access in idpf_get_link_ksettings When the device control plane is removed or the platform running device control plane is rebooted, a reset is detected on the driver. On driver reset, it releases the resources and waits for the reset to complete. If the reset fails, it takes the error path and releases the vport lock. At this time if the monitoring tools tries to access link settings, it call traces for accessing released vport pointer. To avoid it, move link_speed_mbps to netdev_priv structure which removes the dependency on vport pointer and the vport lock in idpf_get_link_ksettings. Also use netif_carrier_ok() to check the link status and adjust the offsetof to use link_up instead of link_speed_mbps.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53065", "url": "https://ubuntu.com/security/CVE-2024-53065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/slab: fix warning caused by duplicate kmem_cache creation in kmem_buckets_create Commit b035f5a6d852 (\"mm: slab: reduce the kmalloc() minimum alignment if DMA bouncing possible\") reduced ARCH_KMALLOC_MINALIGN to 8 on arm64. However, with KASAN_HW_TAGS enabled, arch_slab_minalign() becomes 16. This causes kmalloc_caches[*][8] to be aliased to kmalloc_caches[*][16], resulting in kmem_buckets_create() attempting to create a kmem_cache for size 16 twice. This duplication triggers warnings on boot: [ 2.325108] ------------[ cut here ]------------ [ 2.325135] kmem_cache of name 'memdup_user-16' already exists [ 2.325783] WARNING: CPU: 0 PID: 1 at mm/slab_common.c:107 __kmem_cache_create_args+0xb8/0x3b0 [ 2.327957] Modules linked in: [ 2.328550] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5mm-unstable-arm64+ #12 [ 2.328683] Hardware name: QEMU QEMU Virtual Machine, BIOS 2024.02-2 03/11/2024 [ 2.328790] pstate: 61000009 (nZCv daif -PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 2.328911] pc : __kmem_cache_create_args+0xb8/0x3b0 [ 2.328930] lr : __kmem_cache_create_args+0xb8/0x3b0 [ 2.328942] sp : ffff800083d6fc50 [ 2.328961] x29: ffff800083d6fc50 x28: f2ff0000c1674410 x27: ffff8000820b0598 [ 2.329061] x26: 000000007fffffff x25: 0000000000000010 x24: 0000000000002000 [ 2.329101] x23: ffff800083d6fce8 x22: ffff8000832222e8 x21: ffff800083222388 [ 2.329118] x20: f2ff0000c1674410 x19: f5ff0000c16364c0 x18: ffff800083d80030 [ 2.329135] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 2.329152] x14: 0000000000000000 x13: 0a73747369786520 x12: 79646165726c6120 [ 2.329169] x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : 0000000000000000 [ 2.329194] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 [ 2.329210] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 2.329226] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 2.329291] Call trace: [ 2.329407] __kmem_cache_create_args+0xb8/0x3b0 [ 2.329499] kmem_buckets_create+0xfc/0x320 [ 2.329526] init_user_buckets+0x34/0x78 [ 2.329540] do_one_initcall+0x64/0x3c8 [ 2.329550] kernel_init_freeable+0x26c/0x578 [ 2.329562] kernel_init+0x3c/0x258 [ 2.329574] ret_from_fork+0x10/0x20 [ 2.329698] ---[ end trace 0000000000000000 ]--- [ 2.403704] ------------[ cut here ]------------ [ 2.404716] kmem_cache of name 'msg_msg-16' already exists [ 2.404801] WARNING: CPU: 2 PID: 1 at mm/slab_common.c:107 __kmem_cache_create_args+0xb8/0x3b0 [ 2.404842] Modules linked in: [ 2.404971] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.12.0-rc5mm-unstable-arm64+ #12 [ 2.405026] Tainted: [W]=WARN [ 2.405043] Hardware name: QEMU QEMU Virtual Machine, BIOS 2024.02-2 03/11/2024 [ 2.405057] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2.405079] pc : __kmem_cache_create_args+0xb8/0x3b0 [ 2.405100] lr : __kmem_cache_create_args+0xb8/0x3b0 [ 2.405111] sp : ffff800083d6fc50 [ 2.405115] x29: ffff800083d6fc50 x28: fbff0000c1674410 x27: ffff8000820b0598 [ 2.405135] x26: 000000000000ffd0 x25: 0000000000000010 x24: 0000000000006000 [ 2.405153] x23: ffff800083d6fce8 x22: ffff8000832222e8 x21: ffff800083222388 [ 2.405169] x20: fbff0000c1674410 x19: fdff0000c163d6c0 x18: ffff800083d80030 [ 2.405185] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 2.405201] x14: 0000000000000000 x13: 0a73747369786520 x12: 79646165726c6120 [ 2.405217] x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : 0000000000000000 [ 2.405233] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 [ 2.405248] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 2.405271] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 2.405287] Call trace: [ 2 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50275", "url": "https://ubuntu.com/security/CVE-2024-50275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64/sve: Discard stale CPU state when handling SVE traps The logic for handling SVE traps manipulates saved FPSIMD/SVE state incorrectly, and a race with preemption can result in a task having TIF_SVE set and TIF_FOREIGN_FPSTATE clear even though the live CPU state is stale (e.g. with SVE traps enabled). This has been observed to result in warnings from do_sve_acc() where SVE traps are not expected while TIF_SVE is set: | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* SVE access shouldn't have trapped */ Warnings of this form have been reported intermittently, e.g. https://lore.kernel.org/linux-arm-kernel/CA+G9fYtEGe_DhY2Ms7+L7NKsLYUomGsgqpdBj+QwDLeSg=JhGg@mail.gmail.com/ https://lore.kernel.org/linux-arm-kernel/000000000000511e9a060ce5a45c@google.com/ The race can occur when the SVE trap handler is preempted before and after manipulating the saved FPSIMD/SVE state, starting and ending on the same CPU, e.g. | void do_sve_acc(unsigned long esr, struct pt_regs *regs) | { | // Trap on CPU 0 with TIF_SVE clear, SVE 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(); | | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* SVE access shouldn't have trapped */ | | sve_init_regs() { | if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) { | ... | } else { | fpsimd_to_sve(current); | current->thread.fp_type = FP_STATE_SVE; | } | } | | 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 SVE 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.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50276", "url": "https://ubuntu.com/security/CVE-2024-50276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: vertexcom: mse102x: Fix possible double free of TX skb The scope of the TX skb is wider than just mse102x_tx_frame_spi(), so in case the TX skb room needs to be expanded, we should free the the temporary skb instead of the original skb. Otherwise the original TX skb pointer would be freed again in mse102x_tx_work(), which leads to crashes: Internal error: Oops: 0000000096000004 [#2] PREEMPT SMP CPU: 0 PID: 712 Comm: kworker/0:1 Tainted: G D 6.6.23 Hardware name: chargebyte Charge SOM DC-ONE (DT) Workqueue: events mse102x_tx_work [mse102x] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_release_data+0xb8/0x1d8 lr : skb_release_data+0x1ac/0x1d8 sp : ffff8000819a3cc0 x29: ffff8000819a3cc0 x28: ffff0000046daa60 x27: ffff0000057f2dc0 x26: ffff000005386c00 x25: 0000000000000002 x24: 00000000ffffffff x23: 0000000000000000 x22: 0000000000000001 x21: ffff0000057f2e50 x20: 0000000000000006 x19: 0000000000000000 x18: ffff00003fdacfcc x17: e69ad452d0c49def x16: 84a005feff870102 x15: 0000000000000000 x14: 000000000000024a x13: 0000000000000002 x12: 0000000000000000 x11: 0000000000000400 x10: 0000000000000930 x9 : ffff00003fd913e8 x8 : fffffc00001bc008 x7 : 0000000000000000 x6 : 0000000000000008 x5 : ffff00003fd91340 x4 : 0000000000000000 x3 : 0000000000000009 x2 : 00000000fffffffe x1 : 0000000000000000 x0 : 0000000000000000 Call trace: skb_release_data+0xb8/0x1d8 kfree_skb_reason+0x48/0xb0 mse102x_tx_work+0x164/0x35c [mse102x] process_one_work+0x138/0x260 worker_thread+0x32c/0x438 kthread+0x118/0x11c ret_from_fork+0x10/0x20 Code: aa1303e0 97fffab6 72001c1f 54000141 (f9400660)", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53066", "url": "https://ubuntu.com/security/CVE-2024-53066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfs: Fix KMSAN warning in decode_getfattr_attrs() Fix the following KMSAN warning: CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G B Tainted: [B]=BAD_PAGE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) ===================================================== ===================================================== BUG: KMSAN: uninit-value in decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_generic+0x806/0xb00 nfs4_xdr_dec_getattr+0x1de/0x240 rpcauth_unwrap_resp_decode+0xab/0x100 rpcauth_unwrap_resp+0x95/0xc0 call_decode+0x4ff/0xb50 __rpc_execute+0x57b/0x19d0 rpc_execute+0x368/0x5e0 rpc_run_task+0xcfe/0xee0 nfs4_proc_getattr+0x5b5/0x990 __nfs_revalidate_inode+0x477/0xd00 nfs_access_get_cached+0x1021/0x1cc0 nfs_do_access+0x9f/0xae0 nfs_permission+0x1e4/0x8c0 inode_permission+0x356/0x6c0 link_path_walk+0x958/0x1330 path_lookupat+0xce/0x6b0 filename_lookup+0x23e/0x770 vfs_statx+0xe7/0x970 vfs_fstatat+0x1f2/0x2c0 __se_sys_newfstatat+0x67/0x880 __x64_sys_newfstatat+0xbd/0x120 x64_sys_call+0x1826/0x3cf0 do_syscall_64+0xd0/0x1b0 entry_SYSCALL_64_after_hwframe+0x77/0x7f The KMSAN warning is triggered in decode_getfattr_attrs(), when calling decode_attr_mdsthreshold(). It appears that fattr->mdsthreshold is not initialized. Fix the issue by initializing fattr->mdsthreshold to NULL in nfs_fattr_init().", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53067", "url": "https://ubuntu.com/security/CVE-2024-53067", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Start the RTC update work later The RTC update work involves runtime resuming the UFS controller. Hence, only start the RTC update work after runtime power management in the UFS driver has been fully initialized. This patch fixes the following kernel crash: Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP Workqueue: events ufshcd_rtc_work Call trace: _raw_spin_lock_irqsave+0x34/0x8c (P) pm_runtime_get_if_active+0x24/0x9c (L) pm_runtime_get_if_active+0x24/0x9c ufshcd_rtc_work+0x138/0x1b4 process_one_work+0x148/0x288 worker_thread+0x2cc/0x3d4 kthread+0x110/0x114 ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50277", "url": "https://ubuntu.com/security/CVE-2024-50277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: fix a crash if blk_alloc_disk fails If blk_alloc_disk fails, the variable md->disk is set to an error value. cleanup_mapped_device will see that md->disk is non-NULL and it will attempt to access it, causing a crash on this statement \"md->disk->private_data = NULL;\".", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50278", "url": "https://ubuntu.com/security/CVE-2024-50278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix potential out-of-bounds access on the first resume Out-of-bounds access occurs if the fast device is expanded unexpectedly before the first-time resume of the cache table. This happens because expanding the fast device requires reloading the cache table for cache_create to allocate new in-core data structures that fit the new size, and the check in cache_preresume is not performed during the first resume, leading to the issue. Reproduce steps: 1. prepare component devices: 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\" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct 2. load a cache table of 512 cache blocks, and deliberately expand the fast device before resuming the cache, making the in-core data structures inadequate. dmsetup create cache --notable dmsetup reload cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" dmsetup reload cdata --table \"0 131072 linear /dev/sdc 8192\" dmsetup resume cdata dmsetup resume cache 3. suspend the cache to write out the in-core dirty bitset and hint array, leading to out-of-bounds access to the dirty bitset at offset 0x40: dmsetup suspend cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80 Read of size 8 at addr ffffc90000085040 by task dmsetup/90 (...snip...) The buggy address belongs to the virtual mapping at [ffffc90000085000, ffffc90000087000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by checking the size change on the first resume.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50279", "url": "https://ubuntu.com/security/CVE-2024-50279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix out-of-bounds access to the dirty bitset when resizing dm-cache checks the dirty bits of the cache blocks to be dropped when shrinking the fast device, but an index bug in bitset iteration causes out-of-bounds access. Reproduce steps: 1. create a cache device of 1024 cache blocks (128 bytes dirty bitset) dmsetup create cmeta --table \"0 8192 linear /dev/sdc 0\" dmsetup create cdata --table \"0 131072 linear /dev/sdc 8192\" dmsetup create corig --table \"0 524288 linear /dev/sdc 262144\" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" 2. shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80) dmsetup suspend cache dmsetup reload cdata --table \"0 65536 linear /dev/sdc 8192\" dmsetup resume cdata dmsetup resume cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131 (...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by making the index post-incremented.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50280", "url": "https://ubuntu.com/security/CVE-2024-50280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix flushing uninitialized delayed_work on cache_ctr error An unexpected WARN_ON from flush_work() may occur when cache creation fails, caused by destroying the uninitialized delayed_work waker in the error path of cache_create(). For example, the warning appears on the superblock checksum error. Reproduce steps: 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\" dd if=/dev/urandom of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" Kernel logs: (snip) WARNING: CPU: 0 PID: 84 at kernel/workqueue.c:4178 __flush_work+0x5d4/0x890 Fix by pulling out the cancel_delayed_work_sync() from the constructor's error path. This patch doesn't affect the use-after-free fix for concurrent dm_resume and dm_destroy (commit 6a459d8edbdb (\"dm cache: Fix UAF in destroy()\")) as cache_dtr is not changed.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50281", "url": "https://ubuntu.com/security/CVE-2024-50281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: trusted: dcp: fix NULL dereference in AEAD crypto operation When sealing or unsealing a key blob we currently do not wait for the AEAD cipher operation to finish and simply return after submitting the request. If there is some load on the system we can exit before the cipher operation is done and the buffer we read from/write to is already removed from the stack. This will e.g. result in NULL pointer dereference errors in the DCP driver during blob creation. Fix this by waiting for the AEAD cipher operation to finish before resuming the seal and unseal calls.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50282", "url": "https://ubuntu.com/security/CVE-2024-50282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read() Avoid a possible buffer overflow if size is larger than 4K. (cherry picked from commit f5d873f5825b40d886d03bd2aede91d4cf002434)", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53071", "url": "https://ubuntu.com/security/CVE-2024-53071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Be stricter about IO mapping flags The current panthor_device_mmap_io() implementation has two issues: 1. For mapping DRM_PANTHOR_USER_FLUSH_ID_MMIO_OFFSET, panthor_device_mmap_io() bails if VM_WRITE is set, but does not clear VM_MAYWRITE. That means userspace can use mprotect() to make the mapping writable later on. This is a classic Linux driver gotcha. I don't think this actually has any impact in practice: When the GPU is powered, writes to the FLUSH_ID seem to be ignored; and when the GPU is not powered, the dummy_latest_flush page provided by the driver is deliberately designed to not do any flushes, so the only thing writing to the dummy_latest_flush could achieve would be to make *more* flushes happen. 2. panthor_device_mmap_io() does not block MAP_PRIVATE mappings (which are mappings without the VM_SHARED flag). MAP_PRIVATE in combination with VM_MAYWRITE indicates that the VMA has copy-on-write semantics, which for VM_PFNMAP are semi-supported but fairly cursed. In particular, in such a mapping, the driver can only install PTEs during mmap() by calling remap_pfn_range() (because remap_pfn_range() wants to **store the physical address of the mapped physical memory into the vm_pgoff of the VMA**); installing PTEs later on with a fault handler (as panthor does) is not supported in private mappings, and so if you try to fault in such a mapping, vmf_insert_pfn_prot() splats when it hits a BUG() check. Fix it by clearing the VM_MAYWRITE flag (userspace writing to the FLUSH_ID doesn't make sense) and requiring VM_SHARED (copy-on-write semantics for the FLUSH_ID don't make sense). Reproducers for both scenarios are in the notes of my patch on the mailing list; I tested that these bugs exist on a Rock 5B machine. Note that I only compile-tested the patch, I haven't tested it; I don't have a working kernel build setup for the test machine yet. Please test it before applying it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53080", "url": "https://ubuntu.com/security/CVE-2024-53080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Lock XArray when getting entries for the VM Similar to commit cac075706f29 (\"drm/panthor: Fix race when converting group handle to group object\") we need to use the XArray's internal locking when retrieving a vm pointer from there. v2: Removed part of the patch that was trying to protect fetching the heap pointer from XArray, as that operation is protected by the @pool->lock.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53084", "url": "https://ubuntu.com/security/CVE-2024-53084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Break an object reference loop When remaining resources are being cleaned up on driver close, outstanding VM mappings may result in resources being leaked, due to an object reference loop, as shown below, with each object (or set of objects) referencing the object below it: PVR GEM Object GPU scheduler \"finished\" fence GPU scheduler “scheduled” fence PVR driver “done” fence PVR Context PVR VM Context PVR VM Mappings PVR GEM Object The reference that the PVR VM Context has on the VM mappings is a soft one, in the sense that the freeing of outstanding VM mappings is done as part of VM context destruction; no reference counts are involved, as is the case for all the other references in the loop. To break the reference loop during cleanup, free the outstanding VM mappings before destroying the PVR Context associated with the VM context.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53085", "url": "https://ubuntu.com/security/CVE-2024-53085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: Lock TPM chip in tpm_pm_suspend() first Setting TPM_CHIP_FLAG_SUSPENDED in the end of tpm_pm_suspend() can be racy according, as this leaves window for tpm_hwrng_read() to be called while the operation is in progress. The recent bug report gives also evidence of this behaviour. Aadress this by locking the TPM chip before checking any chip->flags both in tpm_pm_suspend() and tpm_hwrng_read(). Move TPM_CHIP_FLAG_SUSPENDED check inside tpm_get_random() so that it will be always checked only when the lock is reserved.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53086", "url": "https://ubuntu.com/security/CVE-2024-53086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Drop VM dma-resv lock on xe_sync_in_fence_get failure in exec IOCTL Upon failure all locks need to be dropped before returning to the user. (cherry picked from commit 7d1a4258e602ffdce529f56686925034c1b3b095)", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53087", "url": "https://ubuntu.com/security/CVE-2024-53087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix possible exec queue leak in exec IOCTL In a couple of places after an exec queue is looked up the exec IOCTL returns on input errors without dropping the exec queue ref. Fix this ensuring the exec queue ref is dropped on input error. (cherry picked from commit 07064a200b40ac2195cb6b7b779897d9377e5e6f)", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50283", "url": "https://ubuntu.com/security/CVE-2024-50283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-use-after-free in smb3_preauth_hash_rsp ksmbd_user_session_put should be called under smb3_preauth_hash_rsp(). It will avoid freeing session before calling smb3_preauth_hash_rsp().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50284", "url": "https://ubuntu.com/security/CVE-2024-50284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix the missing xa_store error check xa_store() can fail, it return xa_err(-EINVAL) if the entry cannot be stored in an XArray, or xa_err(-ENOMEM) if memory allocation failed, so check error for xa_store() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50285", "url": "https://ubuntu.com/security/CVE-2024-50285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: check outstanding simultaneous SMB operations If Client send simultaneous SMB operations to ksmbd, It exhausts too much memory through the \"ksmbd_work_cache”. It will cause OOM issue. ksmbd has a credit mechanism but it can't handle this problem. This patch add the check if it exceeds max credits to prevent this problem by assuming that one smb request consumes at least one credit.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50286", "url": "https://ubuntu.com/security/CVE-2024-50286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-use-after-free in ksmbd_smb2_session_create There is a race condition between ksmbd_smb2_session_create and ksmbd_expire_session. This patch add missing sessions_table_lock while adding/deleting session from global session table.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50287", "url": "https://ubuntu.com/security/CVE-2024-50287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-tpg: prevent the risk of a division by zero As reported by Coverity, the logic at tpg_precalculate_line() blindly rescales the buffer even when scaled_witdh is equal to zero. If this ever happens, this will cause a division by zero. Instead, add a WARN_ON_ONCE() to trigger such cases and return without doing any precalculation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50288", "url": "https://ubuntu.com/security/CVE-2024-50288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: fix buffer overwrite when using > 32 buffers The maximum number of buffers that can be requested was increased to 64 for the video capture queue. But video capture used a must_blank array that was still sized for 32 (VIDEO_MAX_FRAME). This caused an out-of-bounds write when using buffer indices >= 32. Create a new define MAX_VID_CAP_BUFFERS that is used to access the must_blank array and set max_num_buffers for the video capture queue. This solves a crash reported by: \thttps://bugzilla.kernel.org/show_bug.cgi?id=219258", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50289", "url": "https://ubuntu.com/security/CVE-2024-50289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: av7110: fix a spectre vulnerability As warned by smatch: \tdrivers/staging/media/av7110/av7110_ca.c:270 dvb_ca_ioctl() warn: potential spectre issue 'av7110->ci_slot' [w] (local cap) There is a spectre-related vulnerability at the code. Fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50290", "url": "https://ubuntu.com/security/CVE-2024-50290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx24116: prevent overflows on SNR calculus as reported by Coverity, if reading SNR registers fail, a negative number will be returned, causing an underflow when reading SNR registers. Prevent that.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53061", "url": "https://ubuntu.com/security/CVE-2024-53061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: s5p-jpeg: prevent buffer overflows The current logic allows word to be less than 2. If this happens, there will be buffer overflows, as reported by smatch. Add extra checks to prevent it. While here, remove an unused word = 0 assignment.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53081", "url": "https://ubuntu.com/security/CVE-2024-53081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ar0521: don't overflow when checking PLL values The PLL checks are comparing 64 bit integers with 32 bit ones, as reported by Coverity. Depending on the values of the variables, this may underflow. Fix it ensuring that both sides of the expression are u64.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53062", "url": "https://ubuntu.com/security/CVE-2024-53062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mgb4: protect driver against spectre Frequency range is set from sysfs via frequency_range_store(), being vulnerable to spectre, as reported by smatch: \tdrivers/media/pci/mgb4/mgb4_cmt.c:231 mgb4_cmt_set_vin_freq_range() warn: potential spectre issue 'cmt_vals_in' [r] \tdrivers/media/pci/mgb4/mgb4_cmt.c:238 mgb4_cmt_set_vin_freq_range() warn: possible spectre second half. 'reg_set' Fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50291", "url": "https://ubuntu.com/security/CVE-2024-50291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvb-core: add missing buffer index check dvb_vb2_expbuf() didn't check if the given buffer index was for a valid buffer. Add this check.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50292", "url": "https://ubuntu.com/security/CVE-2024-50292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: stm32: spdifrx: fix dma channel release in stm32_spdifrx_remove In case of error when requesting ctrl_chan DMA channel, ctrl_chan is not null. So the release of the dma channel leads to the following issue: [ 4.879000] st,stm32-spdifrx 500d0000.audio-controller: dma_request_slave_channel error -19 [ 4.888975] Unable to handle kernel NULL pointer dereference at virtual address 000000000000003d [...] [ 5.096577] Call trace: [ 5.099099] dma_release_channel+0x24/0x100 [ 5.103235] stm32_spdifrx_remove+0x24/0x60 [snd_soc_stm32_spdifrx] [ 5.109494] stm32_spdifrx_probe+0x320/0x4c4 [snd_soc_stm32_spdifrx] To avoid this issue, release channel only if the pointer is valid.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53063", "url": "https://ubuntu.com/security/CVE-2024-53063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvbdev: prevent the risk of out of memory access The dvbdev contains a static variable used to store dvb minors. The behavior of it depends if CONFIG_DVB_DYNAMIC_MINORS is set or not. When not set, dvb_register_device() won't check for boundaries, as it will rely that a previous call to dvb_register_adapter() would already be enforcing it. On a similar way, dvb_device_open() uses the assumption that the register functions already did the needed checks. This can be fragile if some device ends using different calls. This also generate warnings on static check analysers like Coverity. So, add explicit guards to prevent potential risk of OOM issues.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50293", "url": "https://ubuntu.com/security/CVE-2024-50293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: do not leave a dangling sk pointer in __smc_create() Thanks to commit 4bbd360a5084 (\"socket: Print pf->create() when it does not clear sock->sk on failure.\"), syzbot found an issue with AF_SMC: smc_create must clear sock->sk on failure, family: 43, type: 1, protocol: 0 WARNING: CPU: 0 PID: 5827 at net/socket.c:1565 __sock_create+0x96f/0xa30 net/socket.c:1563 Modules linked in: CPU: 0 UID: 0 PID: 5827 Comm: syz-executor259 Not tainted 6.12.0-rc6-next-20241106-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:__sock_create+0x96f/0xa30 net/socket.c:1563 Code: 03 00 74 08 4c 89 e7 e8 4f 3b 85 f8 49 8b 34 24 48 c7 c7 40 89 0c 8d 8b 54 24 04 8b 4c 24 0c 44 8b 44 24 08 e8 32 78 db f7 90 <0f> 0b 90 90 e9 d3 fd ff ff 89 e9 80 e1 07 fe c1 38 c1 0f 8c ee f7 RSP: 0018:ffffc90003e4fda0 EFLAGS: 00010246 RAX: 099c6f938c7f4700 RBX: 1ffffffff1a595fd RCX: ffff888034823c00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 00000000ffffffe9 R08: ffffffff81567052 R09: 1ffff920007c9f50 R10: dffffc0000000000 R11: fffff520007c9f51 R12: ffffffff8d2cafe8 R13: 1ffffffff1a595fe R14: ffffffff9a789c40 R15: ffff8880764298c0 FS: 000055557b518380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa62ff43225 CR3: 0000000031628000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: sock_create net/socket.c:1616 [inline] __sys_socket_create net/socket.c:1653 [inline] __sys_socket+0x150/0x3c0 net/socket.c:1700 __do_sys_socket net/socket.c:1714 [inline] __se_sys_socket net/socket.c:1712 [inline] For reference, see commit 2d859aff775d (\"Merge branch 'do-not-leave-dangling-sk-pointers-in-pf-create-functions'\")", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50294", "url": "https://ubuntu.com/security/CVE-2024-50294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix missing locking causing hanging calls If a call gets aborted (e.g. because kafs saw a signal) between it being queued for connection and the I/O thread picking up the call, the abort will be prioritised over the connection and it will be removed from local->new_client_calls by rxrpc_disconnect_client_call() without a lock being held. This may cause other calls on the list to disappear if a race occurs. Fix this by taking the client_call_lock when removing a call from whatever list its ->wait_link happens to be on.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50295", "url": "https://ubuntu.com/security/CVE-2024-50295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: arc: fix the device for dma_map_single/dma_unmap_single The ndev->dev and pdev->dev aren't the same device, use ndev->dev.parent which has dma_mask, ndev->dev.parent is just pdev->dev. Or it would cause the following issue: [ 39.933526] ------------[ cut here ]------------ [ 39.938414] WARNING: CPU: 1 PID: 501 at kernel/dma/mapping.c:149 dma_map_page_attrs+0x90/0x1f8", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53082", "url": "https://ubuntu.com/security/CVE-2024-53082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_net: Add hash_key_length check Add hash_key_length check in virtnet_probe() to avoid possible out of bound errors when setting/reading the hash key.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50296", "url": "https://ubuntu.com/security/CVE-2024-50296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash when uninstalling driver When the driver is uninstalled and the VF is disabled concurrently, a kernel crash occurs. The reason is that the two actions call function pci_disable_sriov(). The num_VFs is checked to determine whether to release the corresponding resources. During the second calling, num_VFs is not 0 and the resource release function is called. However, the corresponding resource has been released during the first invoking. Therefore, the problem occurs: [15277.839633][T50670] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ... [15278.131557][T50670] Call trace: [15278.134686][T50670] klist_put+0x28/0x12c [15278.138682][T50670] klist_del+0x14/0x20 [15278.142592][T50670] device_del+0xbc/0x3c0 [15278.146676][T50670] pci_remove_bus_device+0x84/0x120 [15278.151714][T50670] pci_stop_and_remove_bus_device+0x6c/0x80 [15278.157447][T50670] pci_iov_remove_virtfn+0xb4/0x12c [15278.162485][T50670] sriov_disable+0x50/0x11c [15278.166829][T50670] pci_disable_sriov+0x24/0x30 [15278.171433][T50670] hnae3_unregister_ae_algo_prepare+0x60/0x90 [hnae3] [15278.178039][T50670] hclge_exit+0x28/0xd0 [hclge] [15278.182730][T50670] __se_sys_delete_module.isra.0+0x164/0x230 [15278.188550][T50670] __arm64_sys_delete_module+0x1c/0x30 [15278.193848][T50670] invoke_syscall+0x50/0x11c [15278.198278][T50670] el0_svc_common.constprop.0+0x158/0x164 [15278.203837][T50670] do_el0_svc+0x34/0xcc [15278.207834][T50670] el0_svc+0x20/0x30 For details, see the following figure. rmmod hclge disable VFs ---------------------------------------------------- hclge_exit() sriov_numvfs_store() ... device_lock() pci_disable_sriov() hns3_pci_sriov_configure() pci_disable_sriov() sriov_disable() sriov_disable() if !num_VFs : if !num_VFs : return; return; sriov_del_vfs() sriov_del_vfs() ... ... klist_put() klist_put() ... ... num_VFs = 0; num_VFs = 0; device_unlock(); In this patch, when driver is removing, we get the device_lock() to protect num_VFs, just like sriov_numvfs_store().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53088", "url": "https://ubuntu.com/security/CVE-2024-53088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: fix race condition by adding filter's intermediate sync state Fix a race condition in the i40e driver that leads to MAC/VLAN filters becoming corrupted and leaking. Address the issue that occurs under heavy load when multiple threads are concurrently modifying MAC/VLAN filters by setting mac and port VLAN. 1. Thread T0 allocates a filter in i40e_add_filter() within i40e_ndo_set_vf_port_vlan(). 2. Thread T1 concurrently frees the filter in __i40e_del_filter() within i40e_ndo_set_vf_mac(). 3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which refers to the already freed filter memory, causing corruption. Reproduction steps: 1. Spawn multiple VFs. 2. Apply a concurrent heavy load by running parallel operations to change MAC addresses on the VFs and change port VLANs on the host. 3. Observe errors in dmesg: \"Error I40E_AQ_RC_ENOSPC adding RX filters on VF XX, \tplease set promiscuous on manually for VF XX\". Exact code for stable reproduction Intel can't open-source now. The fix involves implementing a new intermediate filter state, I40E_FILTER_NEW_SYNC, for the time when a filter is on a tmp_add_list. These filters cannot be deleted from the hash list directly but must be removed using the full process.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50297", "url": "https://ubuntu.com/security/CVE-2024-50297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: xilinx: axienet: Enqueue Tx packets in dql before dmaengine starts Enqueue packets in dql after dma engine starts causes race condition. Tx transfer starts once dma engine is started and may execute dql dequeue in completion before it gets queued. It results in following kernel crash while running iperf stress test: kernel BUG at lib/dynamic_queue_limits.c:99! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP pc : dql_completed+0x238/0x248 lr : dql_completed+0x3c/0x248 Call trace: dql_completed+0x238/0x248 axienet_dma_tx_cb+0xa0/0x170 xilinx_dma_do_tasklet+0xdc/0x290 tasklet_action_common+0xf8/0x11c tasklet_action+0x30/0x3c handle_softirqs+0xf8/0x230 Start dmaengine after enqueue in dql fixes the crash.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50298", "url": "https://ubuntu.com/security/CVE-2024-50298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: enetc: allocate vf_state during PF probes In the previous implementation, vf_state is allocated memory only when VF is enabled. However, net_device_ops::ndo_set_vf_mac() may be called before VF is enabled to configure the MAC address of VF. If this is the case, enetc_pf_set_vf_mac() will access vf_state, resulting in access to a null pointer. The simplified error log is as follows. root@ls1028ardb:~# ip link set eno0 vf 1 mac 00:0c:e7:66:77:89 [ 173.543315] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 [ 173.637254] pc : enetc_pf_set_vf_mac+0x3c/0x80 Message from sy [ 173.641973] lr : do_setlink+0x4a8/0xec8 [ 173.732292] Call trace: [ 173.734740] enetc_pf_set_vf_mac+0x3c/0x80 [ 173.738847] __rtnl_newlink+0x530/0x89c [ 173.742692] rtnl_newlink+0x50/0x7c [ 173.746189] rtnetlink_rcv_msg+0x128/0x390 [ 173.750298] netlink_rcv_skb+0x60/0x130 [ 173.754145] rtnetlink_rcv+0x18/0x24 [ 173.757731] netlink_unicast+0x318/0x380 [ 173.761665] netlink_sendmsg+0x17c/0x3c8", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50299", "url": "https://ubuntu.com/security/CVE-2024-50299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: properly validate chunk size in sctp_sf_ootb() A size validation fix similar to that in Commit 50619dbf8db7 (\"sctp: add size validation when walking chunks\") is also required in sctp_sf_ootb() to address a crash reported by syzbot: BUG: KMSAN: uninit-value in sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_do_sm+0x181/0x93d0 net/sctp/sm_sideeffect.c:1166 sctp_endpoint_bh_rcv+0xc38/0xf90 net/sctp/endpointola.c:407 sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88 sctp_rcv+0x3831/0x3b20 net/sctp/input.c:243 sctp4_rcv+0x42/0x50 net/sctp/protocol.c:1159 ip_protocol_deliver_rcu+0xb51/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50300", "url": "https://ubuntu.com/security/CVE-2024-50300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: rtq2208: Fix uninitialized use of regulator_config Fix rtq2208 driver uninitialized use to cause kernel error.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50301", "url": "https://ubuntu.com/security/CVE-2024-50301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: security/keys: fix slab-out-of-bounds in key_task_permission KASAN reports an out of bounds read: BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline] BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362 CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0x107/0x167 lib/dump_stack.c:123 print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 __kuid_val include/linux/uidgid.h:36 [inline] uid_eq include/linux/uidgid.h:63 [inline] key_task_permission+0x394/0x410 security/keys/permission.c:54 search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793 This issue was also reported by syzbot. It can be reproduced by following these steps(more details [1]): 1. Obtain more than 32 inputs that have similar hashes, which ends with the pattern '0xxxxxxxe6'. 2. Reboot and add the keys obtained in step 1. The reproducer demonstrates how this issue happened: 1. In the search_nested_keyrings function, when it iterates through the slots in a node(below tag ascend_to_node), if the slot pointer is meta and node->back_pointer != NULL(it means a root), it will proceed to descend_to_node. However, there is an exception. If node is the root, and one of the slots points to a shortcut, it will be treated as a keyring. 2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function. However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as ASSOC_ARRAY_PTR_SUBTYPE_MASK. 3. When 32 keys with the similar hashes are added to the tree, the ROOT has keys with hashes that are not similar (e.g. slot 0) and it splits NODE A without using a shortcut. When NODE A is filled with keys that all hashes are xxe6, the keys are similar, NODE A will split with a shortcut. Finally, it forms the tree as shown below, where slot 6 points to a shortcut. NODE A +------>+---+ ROOT | | 0 | xxe6 +---+ | +---+ xxxx | 0 | shortcut : : xxe6 +---+ | +---+ xxe6 : : | | | xxe6 +---+ | +---+ | 6 |---+ : : xxe6 +---+ +---+ xxe6 : : | f | xxe6 +---+ +---+ xxe6 | f | +---+ 4. As mentioned above, If a slot(slot 6) of the root points to a shortcut, it may be mistakenly transferred to a key*, leading to a read out-of-bounds read. To fix this issue, one should jump to descend_to_node if the ptr is a shortcut, regardless of whether the node is root or not. [1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/ [jarkko: tweaked the commit message a bit to have an appropriate closes tag.]", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53072", "url": "https://ubuntu.com/security/CVE-2024-53072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/pmc: Detect when STB is not available Loading the amd_pmc module as: amd_pmc enable_stb=1 ...can result in the following messages in the kernel ring buffer: amd_pmc AMDI0009:00: SMU cmd failed. err: 0xff ioremap on RAM at 0x0000000000000000 - 0x0000000000ffffff WARNING: CPU: 10 PID: 2151 at arch/x86/mm/ioremap.c:217 __ioremap_caller+0x2cd/0x340 Further debugging reveals that this occurs when the requests for S2D_PHYS_ADDR_LOW and S2D_PHYS_ADDR_HIGH return a value of 0, indicating that the STB is inaccessible. To prevent the ioremap warning and provide clarity to the user, handle the invalid address and display an error message.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50302", "url": "https://ubuntu.com/security/CVE-2024-50302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: zero-initialize the report buffer Since the report buffer is used by all kinds of drivers in various ways, let's zero-initialize it during allocation to make sure that it can't be ever used to leak kernel memory via specially-crafted report.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53068", "url": "https://ubuntu.com/security/CVE-2024-53068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix slab-use-after-free in scmi_bus_notifier() The scmi_dev->name is released prematurely in __scmi_device_destroy(), which causes slab-use-after-free when accessing scmi_dev->name in scmi_bus_notifier(). So move the release of scmi_dev->name to scmi_device_release() to avoid slab-use-after-free. | BUG: KASAN: slab-use-after-free in strncmp+0xe4/0xec | Read of size 1 at addr ffffff80a482bcc0 by task swapper/0/1 | | CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.6.38-debug #1 | Hardware name: Qualcomm Technologies, Inc. SA8775P Ride (DT) | Call trace: | dump_backtrace+0x94/0x114 | show_stack+0x18/0x24 | dump_stack_lvl+0x48/0x60 | print_report+0xf4/0x5b0 | kasan_report+0xa4/0xec | __asan_report_load1_noabort+0x20/0x2c | strncmp+0xe4/0xec | scmi_bus_notifier+0x5c/0x54c | notifier_call_chain+0xb4/0x31c | blocking_notifier_call_chain+0x68/0x9c | bus_notify+0x54/0x78 | device_del+0x1bc/0x840 | device_unregister+0x20/0xb4 | __scmi_device_destroy+0xac/0x280 | scmi_device_destroy+0x94/0xd0 | scmi_chan_setup+0x524/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20 | | Allocated by task 1: | kasan_save_stack+0x2c/0x54 | kasan_set_track+0x2c/0x40 | kasan_save_alloc_info+0x24/0x34 | __kasan_kmalloc+0xa0/0xb8 | __kmalloc_node_track_caller+0x6c/0x104 | kstrdup+0x48/0x84 | kstrdup_const+0x34/0x40 | __scmi_device_create.part.0+0x8c/0x408 | scmi_device_create+0x104/0x370 | scmi_chan_setup+0x2a0/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20 | | Freed by task 1: | kasan_save_stack+0x2c/0x54 | kasan_set_track+0x2c/0x40 | kasan_save_free_info+0x38/0x5c | __kasan_slab_free+0xe8/0x164 | __kmem_cache_free+0x11c/0x230 | kfree+0x70/0x130 | kfree_const+0x20/0x40 | __scmi_device_destroy+0x70/0x280 | scmi_device_destroy+0x94/0xd0 | scmi_chan_setup+0x524/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53069", "url": "https://ubuntu.com/security/CVE-2024-53069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: qcom: scm: fix a NULL-pointer dereference Some SCM calls can be invoked with __scm being NULL (the driver may not have been and will not be probed as there's no SCM entry in device-tree). Make sure we don't dereference a NULL pointer.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50212", "url": "https://ubuntu.com/security/CVE-2024-50212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib: alloc_tag_module_unload must wait for pending kfree_rcu calls Ben Greear reports following splat: ------------[ cut here ]------------ net/netfilter/nf_nat_core.c:1114 module nf_nat func:nf_nat_register_fn has 256 allocated at module unload WARNING: CPU: 1 PID: 10421 at lib/alloc_tag.c:168 alloc_tag_module_unload+0x22b/0x3f0 Modules linked in: nf_nat(-) btrfs ufs qnx4 hfsplus hfs minix vfat msdos fat ... Hardware name: Default string Default string/SKYBAY, BIOS 5.12 08/04/2020 RIP: 0010:alloc_tag_module_unload+0x22b/0x3f0 codetag_unload_module+0x19b/0x2a0 ? codetag_load_module+0x80/0x80 nf_nat module exit calls kfree_rcu on those addresses, but the free operation is likely still pending by the time alloc_tag checks for leaks. Wait for outstanding kfree_rcu operations to complete before checking resolves this warning. Reproducer: unshare -n iptables-nft -t nat -A PREROUTING -p tcp grep nf_nat /proc/allocinfo # will list 4 allocations rmmod nft_chain_nat rmmod nf_nat # will WARN. [akpm@linux-foundation.org: add comment]", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53046", "url": "https://ubuntu.com/security/CVE-2024-53046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: dts: imx8ulp: correct the flexspi compatible string The flexspi on imx8ulp only has 16 LUTs, and imx8mm flexspi has 32 LUTs, so correct the compatible string here, otherwise will meet below error: [ 1.119072] ------------[ cut here ]------------ [ 1.123926] WARNING: CPU: 0 PID: 1 at drivers/spi/spi-nxp-fspi.c:855 nxp_fspi_exec_op+0xb04/0xb64 [ 1.133239] Modules linked in: [ 1.136448] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-rc6-next-20240902-00001-g131bf9439dd9 #69 [ 1.146821] Hardware name: NXP i.MX8ULP EVK (DT) [ 1.151647] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.158931] pc : nxp_fspi_exec_op+0xb04/0xb64 [ 1.163496] lr : nxp_fspi_exec_op+0xa34/0xb64 [ 1.168060] sp : ffff80008002b2a0 [ 1.171526] x29: ffff80008002b2d0 x28: 0000000000000000 x27: 0000000000000000 [ 1.179002] x26: ffff2eb645542580 x25: ffff800080610014 x24: ffff800080610000 [ 1.186480] x23: ffff2eb645548080 x22: 0000000000000006 x21: ffff2eb6455425e0 [ 1.193956] x20: 0000000000000000 x19: ffff80008002b5e0 x18: ffffffffffffffff [ 1.201432] x17: ffff2eb644467508 x16: 0000000000000138 x15: 0000000000000002 [ 1.208907] x14: 0000000000000000 x13: ffff2eb6400d8080 x12: 00000000ffffff00 [ 1.216378] x11: 0000000000000000 x10: ffff2eb6400d8080 x9 : ffff2eb697adca80 [ 1.223850] x8 : ffff2eb697ad3cc0 x7 : 0000000100000000 x6 : 0000000000000001 [ 1.231324] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000007a6 [ 1.238795] x2 : 0000000000000000 x1 : 00000000000001ce x0 : 00000000ffffff92 [ 1.246267] Call trace: [ 1.248824] nxp_fspi_exec_op+0xb04/0xb64 [ 1.253031] spi_mem_exec_op+0x3a0/0x430 [ 1.257139] spi_nor_read_id+0x80/0xcc [ 1.261065] spi_nor_scan+0x1ec/0xf10 [ 1.264901] spi_nor_probe+0x108/0x2fc [ 1.268828] spi_mem_probe+0x6c/0xbc [ 1.272574] spi_probe+0x84/0xe4 [ 1.275958] really_probe+0xbc/0x29c [ 1.279713] __driver_probe_device+0x78/0x12c [ 1.284277] driver_probe_device+0xd8/0x15c [ 1.288660] __device_attach_driver+0xb8/0x134 [ 1.293316] bus_for_each_drv+0x88/0xe8 [ 1.297337] __device_attach+0xa0/0x190 [ 1.301353] device_initial_probe+0x14/0x20 [ 1.305734] bus_probe_device+0xac/0xb0 [ 1.309752] device_add+0x5d0/0x790 [ 1.313408] __spi_add_device+0x134/0x204 [ 1.317606] of_register_spi_device+0x3b4/0x590 [ 1.322348] spi_register_controller+0x47c/0x754 [ 1.327181] devm_spi_register_controller+0x4c/0xa4 [ 1.332289] nxp_fspi_probe+0x1cc/0x2b0 [ 1.336307] platform_probe+0x68/0xc4 [ 1.340145] really_probe+0xbc/0x29c [ 1.343893] __driver_probe_device+0x78/0x12c [ 1.348457] driver_probe_device+0xd8/0x15c [ 1.352838] __driver_attach+0x90/0x19c [ 1.356857] bus_for_each_dev+0x7c/0xdc [ 1.360877] driver_attach+0x24/0x30 [ 1.364624] bus_add_driver+0xe4/0x208 [ 1.368552] driver_register+0x5c/0x124 [ 1.372573] __platform_driver_register+0x28/0x34 [ 1.377497] nxp_fspi_driver_init+0x1c/0x28 [ 1.381888] do_one_initcall+0x80/0x1c8 [ 1.385908] kernel_init_freeable+0x1c4/0x28c [ 1.390472] kernel_init+0x20/0x1d8 [ 1.394138] ret_from_fork+0x10/0x20 [ 1.397885] ---[ end trace 0000000000000000 ]--- [ 1.407908] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53052", "url": "https://ubuntu.com/security/CVE-2024-53052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/rw: fix missing NOWAIT check for O_DIRECT start write When io_uring starts a write, it'll call kiocb_start_write() to bump the super block rwsem, preventing any freezes from happening while that write is in-flight. The freeze side will grab that rwsem for writing, excluding any new writers from happening and waiting for existing writes to finish. But io_uring unconditionally uses kiocb_start_write(), which will block if someone is currently attempting to freeze the mount point. This causes a deadlock where freeze is waiting for previous writes to complete, but the previous writes cannot complete, as the task that is supposed to complete them is blocked waiting on starting a new write. This results in the following stuck trace showing that dependency with the write blocked starting a new write: task:fio state:D stack:0 pid:886 tgid:886 ppid:876 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_rwsem_wait+0x1e8/0x3f8 __percpu_down_read+0xe8/0x500 io_write+0xbb8/0xff8 io_issue_sqe+0x10c/0x1020 io_submit_sqes+0x614/0x2110 __arm64_sys_io_uring_enter+0x524/0x1038 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 INFO: task fsfreeze:7364 blocked for more than 15 seconds. Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963 with the attempting freezer stuck trying to grab the rwsem: task:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_down_write+0x2b0/0x680 freeze_super+0x248/0x8a8 do_vfs_ioctl+0x149c/0x1b18 __arm64_sys_ioctl+0xd0/0x1a0 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 Fix this by having the io_uring side honor IOCB_NOWAIT, and only attempt a blocking grab of the super block rwsem if it isn't set. For normal issue where IOCB_NOWAIT would always be set, this returns -EAGAIN which will have io_uring core issue a blocking attempt of the write. That will in turn also get completions run, ensuring forward progress. Since freezing requires CAP_SYS_ADMIN in the first place, this isn't something that can be triggered by a regular user.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50213", "url": "https://ubuntu.com/security/CVE-2024-50213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tests: hdmi: Fix memory leaks in drm_display_mode_from_cea_vic() modprobe drm_hdmi_state_helper_test and then rmmod it, the following memory leak occurs. The `mode` allocated in drm_mode_duplicate() called by drm_display_mode_from_cea_vic() is not freed, which cause the memory leak: \tunreferenced object 0xffffff80ccd18100 (size 128): \t comm \"kunit_try_catch\", pid 1851, jiffies 4295059695 \t hex dump (first 32 bytes): \t 57 62 00 00 80 02 90 02 f0 02 20 03 00 00 e0 01 Wb........ ..... \t ea 01 ec 01 0d 02 00 00 0a 00 00 00 00 00 00 00 ................ \t backtrace (crc c2f1aa95): \t [<000000000f10b11b>] kmemleak_alloc+0x34/0x40 \t [<000000001cd4cf73>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<00000000f1f3cffa>] drm_mode_duplicate+0x44/0x19c \t [<000000008cbeef13>] drm_display_mode_from_cea_vic+0x88/0x98 \t [<0000000019daaacf>] 0xffffffedc11ae69c \t [<000000000aad0f85>] kunit_try_run_case+0x13c/0x3ac \t [<00000000a9210bac>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<000000000a0b2e9e>] kthread+0x2e8/0x374 \t [<00000000bd668858>] ret_from_fork+0x10/0x20 \t...... Free `mode` by using drm_kunit_display_mode_from_cea_vic() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50214", "url": "https://ubuntu.com/security/CVE-2024-50214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/connector: hdmi: Fix memory leak in drm_display_mode_from_cea_vic() modprobe drm_connector_test and then rmmod drm_connector_test, the following memory leak occurs. The `mode` allocated in drm_mode_duplicate() called by drm_display_mode_from_cea_vic() is not freed, which cause the memory leak: \tunreferenced object 0xffffff80cb0ee400 (size 128): \t comm \"kunit_try_catch\", pid 1948, jiffies 4294950339 \t hex dump (first 32 bytes): \t 14 44 02 00 80 07 d8 07 04 08 98 08 00 00 38 04 .D............8. \t 3c 04 41 04 65 04 00 00 05 00 00 00 00 00 00 00 <.A.e........... \t backtrace (crc 90e9585c): \t [<00000000ec42e3d7>] kmemleak_alloc+0x34/0x40 \t [<00000000d0ef055a>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<00000000c2062161>] drm_mode_duplicate+0x44/0x19c \t [<00000000f96c74aa>] drm_display_mode_from_cea_vic+0x88/0x98 \t [<00000000d8f2c8b4>] 0xffffffdc982a4868 \t [<000000005d164dbc>] kunit_try_run_case+0x13c/0x3ac \t [<000000006fb23398>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<000000006ea56ca0>] kthread+0x2e8/0x374 \t [<000000000676063f>] ret_from_fork+0x10/0x20 \t...... Free `mode` by using drm_kunit_display_mode_from_cea_vic() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50215", "url": "https://ubuntu.com/security/CVE-2024-50215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: assign dh_key to NULL after kfree_sensitive ctrl->dh_key might be used across multiple calls to nvmet_setup_dhgroup() for the same controller. So it's better to nullify it after release on error path in order to avoid double free later in nvmet_destroy_auth(). Found by Linux Verification Center (linuxtesting.org) with Svace.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50216", "url": "https://ubuntu.com/security/CVE-2024-50216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix finding a last resort AG in xfs_filestream_pick_ag When the main loop in xfs_filestream_pick_ag fails to find a suitable AG it tries to just pick the online AG. But the loop for that uses args->pag as loop iterator while the later code expects pag to be set. Fix this by reusing the max_pag case for this last resort, and also add a check for impossible case of no AG just to make sure that the uninitialized pag doesn't even escape in theory.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50217", "url": "https://ubuntu.com/security/CVE-2024-50217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free of block device file in __btrfs_free_extra_devids() Mounting btrfs from two images (which have the same one fsid and two different dev_uuids) in certain executing order may trigger an UAF for variable 'device->bdev_file' in __btrfs_free_extra_devids(). And following are the details: 1. Attach image_1 to loop0, attach image_2 to loop1, and scan btrfs devices by ioctl(BTRFS_IOC_SCAN_DEV): / btrfs_device_1 ? loop0 fs_device \\ btrfs_device_2 ? loop1 2. mount /dev/loop0 /mnt btrfs_open_devices btrfs_device_1->bdev_file = btrfs_get_bdev_and_sb(loop0) btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree fail: btrfs_close_devices // -ENOMEM \t btrfs_close_bdev(btrfs_device_1) fput(btrfs_device_1->bdev_file) \t // btrfs_device_1->bdev_file is freed \t btrfs_close_bdev(btrfs_device_2) fput(btrfs_device_2->bdev_file) 3. mount /dev/loop1 /mnt btrfs_open_devices btrfs_get_bdev_and_sb(&bdev_file) // EIO, btrfs_device_1->bdev_file is not assigned, // which points to a freed memory area btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree btrfs_free_extra_devids if (btrfs_device_1->bdev_file) fput(btrfs_device_1->bdev_file) // UAF ! Fix it by setting 'device->bdev_file' as 'NULL' after closing the btrfs_device in btrfs_close_one_device().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53043", "url": "https://ubuntu.com/security/CVE-2024-53043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mctp i2c: handle NULL header address daddr can be NULL if there is no neighbour table entry present, in that case the tx packet should be dropped. saddr will usually be set by MCTP core, but check for NULL in case a packet is transmitted by a different protocol.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50303", "url": "https://ubuntu.com/security/CVE-2024-50303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: resource,kexec: walk_system_ram_res_rev must retain resource flags walk_system_ram_res_rev() erroneously discards resource flags when passing the information to the callback. This causes systems with IORESOURCE_SYSRAM_DRIVER_MANAGED memory to have these resources selected during kexec to store kexec buffers if that memory happens to be at placed above normal system ram. This leads to undefined behavior after reboot. If the kexec buffer is never touched, nothing happens. If the kexec buffer is touched, it could lead to a crash (like below) or undefined behavior. Tested on a system with CXL memory expanders with driver managed memory, TPM enabled, and CONFIG_IMA_KEXEC=y. Adding printk's showed the flags were being discarded and as a result the check for IORESOURCE_SYSRAM_DRIVER_MANAGED passes. find_next_iomem_res: name(System RAM (kmem)) \t\t start(10000000000) \t\t end(1034fffffff) \t\t flags(83000200) locate_mem_hole_top_down: start(10000000000) end(1034fffffff) flags(0) [.] BUG: unable to handle page fault for address: ffff89834ffff000 [.] #PF: supervisor read access in kernel mode [.] #PF: error_code(0x0000) - not-present page [.] PGD c04c8bf067 P4D c04c8bf067 PUD c04c8be067 PMD 0 [.] Oops: 0000 [#1] SMP [.] RIP: 0010:ima_restore_measurement_list+0x95/0x4b0 [.] RSP: 0018:ffffc900000d3a80 EFLAGS: 00010286 [.] RAX: 0000000000001000 RBX: 0000000000000000 RCX: ffff89834ffff000 [.] RDX: 0000000000000018 RSI: ffff89834ffff000 RDI: ffff89834ffff018 [.] RBP: ffffc900000d3ba0 R08: 0000000000000020 R09: ffff888132b8a900 [.] R10: 4000000000000000 R11: 000000003a616d69 R12: 0000000000000000 [.] R13: ffffffff8404ac28 R14: 0000000000000000 R15: ffff89834ffff000 [.] FS: 0000000000000000(0000) GS:ffff893d44640000(0000) knlGS:0000000000000000 [.] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [.] ata5: SATA link down (SStatus 0 SControl 300) [.] CR2: ffff89834ffff000 CR3: 000001034d00f001 CR4: 0000000000770ef0 [.] PKRU: 55555554 [.] Call Trace: [.] [.] ? __die+0x78/0xc0 [.] ? page_fault_oops+0x2a8/0x3a0 [.] ? exc_page_fault+0x84/0x130 [.] ? asm_exc_page_fault+0x22/0x30 [.] ? ima_restore_measurement_list+0x95/0x4b0 [.] ? template_desc_init_fields+0x317/0x410 [.] ? crypto_alloc_tfm_node+0x9c/0xc0 [.] ? init_ima_lsm+0x30/0x30 [.] ima_load_kexec_buffer+0x72/0xa0 [.] ima_init+0x44/0xa0 [.] __initstub__kmod_ima__373_1201_init_ima7+0x1e/0xb0 [.] ? init_ima_lsm+0x30/0x30 [.] do_one_initcall+0xad/0x200 [.] ? idr_alloc_cyclic+0xaa/0x110 [.] ? new_slab+0x12c/0x420 [.] ? new_slab+0x12c/0x420 [.] ? number+0x12a/0x430 [.] ? sysvec_apic_timer_interrupt+0xa/0x80 [.] ? asm_sysvec_apic_timer_interrupt+0x16/0x20 [.] ? parse_args+0xd4/0x380 [.] ? parse_args+0x14b/0x380 [.] kernel_init_freeable+0x1c1/0x2b0 [.] ? rest_init+0xb0/0xb0 [.] kernel_init+0x16/0x1a0 [.] ret_from_fork+0x2f/0x40 [.] ? rest_init+0xb0/0xb0 [.] ret_from_fork_asm+0x11/0x20 [.] ", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50218", "url": "https://ubuntu.com/security/CVE-2024-50218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow Syzbot reported a kernel BUG in ocfs2_truncate_inline. There are two reasons for this: first, the parameter value passed is greater than ocfs2_max_inline_data_with_xattr, second, the start and end parameters of ocfs2_truncate_inline are \"unsigned int\". So, we need to add a sanity check for byte_start and byte_len right before ocfs2_truncate_inline() in ocfs2_remove_inode_range(), if they are greater than ocfs2_max_inline_data_with_xattr return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50219", "url": "https://ubuntu.com/security/CVE-2024-50219", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50263", "url": "https://ubuntu.com/security/CVE-2024-50263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fork: only invoke khugepaged, ksm hooks if no error There is no reason to invoke these hooks early against an mm that is in an incomplete state. The change in commit d24062914837 (\"fork: use __mt_dup() to duplicate maple tree in dup_mmap()\") makes this more pertinent as we may be in a state where entries in the maple tree are not yet consistent. Their placement early in dup_mmap() only appears to have been meaningful for early error checking, and since functionally it'd require a very small allocation to fail (in practice 'too small to fail') that'd only occur in the most dire circumstances, meaning the fork would fail or be OOM'd in any case. Since both khugepaged and KSM tracking are there to provide optimisations to memory performance rather than critical functionality, it doesn't really matter all that much if, under such dire memory pressure, we fail to register an mm with these. As a result, we follow the example of commit d2081b2bf819 (\"mm: khugepaged: make khugepaged_enter() void function\") and make ksm_fork() a void function also. We only expose the mm to these functions once we are done with them and only if no error occurred in the fork operation.", "cve_priority": "medium", "cve_public_date": "2024-11-11 14:15:00 UTC" }, { "cve": "CVE-2024-50220", "url": "https://ubuntu.com/security/CVE-2024-50220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fork: do not invoke uffd on fork if error occurs Patch series \"fork: do not expose incomplete mm on fork\". During fork we may place the virtual memory address space into an inconsistent state before the fork operation is complete. In addition, we may encounter an error during the fork operation that indicates that the virtual memory address space is invalidated. As a result, we should not be exposing it in any way to external machinery that might interact with the mm or VMAs, machinery that is not designed to deal with incomplete state. We specifically update the fork logic to defer khugepaged and ksm to the end of the operation and only to be invoked if no error arose, and disallow uffd from observing fork events should an error have occurred. This patch (of 2): Currently on fork we expose the virtual address space of a process to userland unconditionally if uffd is registered in VMAs, regardless of whether an error arose in the fork. This is performed in dup_userfaultfd_complete() which is invoked unconditionally, and performs two duties - invoking registered handlers for the UFFD_EVENT_FORK event via dup_fctx(), and clearing down userfaultfd_fork_ctx objects established in dup_userfaultfd(). This is problematic, because the virtual address space may not yet be correctly initialised if an error arose. The change in commit d24062914837 (\"fork: use __mt_dup() to duplicate maple tree in dup_mmap()\") makes this more pertinent as we may be in a state where entries in the maple tree are not yet consistent. We address this by, on fork error, ensuring that we roll back state that we would otherwise expect to clean up through the event being handled by userland and perform the memory freeing duty otherwise performed by dup_userfaultfd_complete(). We do this by implementing a new function, dup_userfaultfd_fail(), which performs the same loop, only decrementing reference counts. Note that we perform mmgrab() on the parent and child mm's, however userfaultfd_ctx_put() will mmdrop() this once the reference count drops to zero, so we will avoid memory leaks correctly here.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53047", "url": "https://ubuntu.com/security/CVE-2024-53047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: init: protect sched with rcu_read_lock Enabling CONFIG_PROVE_RCU_LIST with its dependence CONFIG_RCU_EXPERT creates this splat when an MPTCP socket is created: ============================= WARNING: suspicious RCU usage 6.12.0-rc2+ #11 Not tainted ----------------------------- net/mptcp/sched.c:44 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 no locks held by mptcp_connect/176. stack backtrace: CPU: 0 UID: 0 PID: 176 Comm: mptcp_connect Not tainted 6.12.0-rc2+ #11 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl (lib/dump_stack.c:123) lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822) mptcp_sched_find (net/mptcp/sched.c:44 (discriminator 7)) mptcp_init_sock (net/mptcp/protocol.c:2867 (discriminator 1)) ? sock_init_data_uid (arch/x86/include/asm/atomic.h:28) inet_create.part.0.constprop.0 (net/ipv4/af_inet.c:386) ? __sock_create (include/linux/rcupdate.h:347 (discriminator 1)) __sock_create (net/socket.c:1576) __sys_socket (net/socket.c:1671) ? __pfx___sys_socket (net/socket.c:1712) ? do_user_addr_fault (arch/x86/mm/fault.c:1419 (discriminator 1)) __x64_sys_socket (net/socket.c:1728) do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) That's because when the socket is initialised, rcu_read_lock() is not used despite the explicit comment written above the declaration of mptcp_sched_find() in sched.c. Adding the missing lock/unlock avoids the warning.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50221", "url": "https://ubuntu.com/security/CVE-2024-50221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Vangogh: Fix kernel memory out of bounds write KASAN reports that the GPU metrics table allocated in vangogh_tables_init() is not large enough for the memset done in smu_cmn_init_soft_gpu_metrics(). Condensed report follows: [ 33.861314] BUG: KASAN: slab-out-of-bounds in smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu] [ 33.861799] Write of size 168 at addr ffff888129f59500 by task mangoapp/1067 ... [ 33.861808] CPU: 6 UID: 1000 PID: 1067 Comm: mangoapp Tainted: G W 6.12.0-rc4 #356 1a56f59a8b5182eeaf67eb7cb8b13594dd23b544 [ 33.861816] Tainted: [W]=WARN [ 33.861818] Hardware name: Valve Galileo/Galileo, BIOS F7G0107 12/01/2023 [ 33.861822] Call Trace: [ 33.861826] [ 33.861829] dump_stack_lvl+0x66/0x90 [ 33.861838] print_report+0xce/0x620 [ 33.861853] kasan_report+0xda/0x110 [ 33.862794] kasan_check_range+0xfd/0x1a0 [ 33.862799] __asan_memset+0x23/0x40 [ 33.862803] smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.863306] vangogh_get_gpu_metrics_v2_4+0x123/0xad0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.864257] vangogh_common_get_gpu_metrics+0xb0c/0xbc0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.865682] amdgpu_dpm_get_gpu_metrics+0xcc/0x110 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.866160] amdgpu_get_gpu_metrics+0x154/0x2d0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.867135] dev_attr_show+0x43/0xc0 [ 33.867147] sysfs_kf_seq_show+0x1f1/0x3b0 [ 33.867155] seq_read_iter+0x3f8/0x1140 [ 33.867173] vfs_read+0x76c/0xc50 [ 33.867198] ksys_read+0xfb/0x1d0 [ 33.867214] do_syscall_64+0x90/0x160 ... [ 33.867353] Allocated by task 378 on cpu 7 at 22.794876s: [ 33.867358] kasan_save_stack+0x33/0x50 [ 33.867364] kasan_save_track+0x17/0x60 [ 33.867367] __kasan_kmalloc+0x87/0x90 [ 33.867371] vangogh_init_smc_tables+0x3f9/0x840 [amdgpu] [ 33.867835] smu_sw_init+0xa32/0x1850 [amdgpu] [ 33.868299] amdgpu_device_init+0x467b/0x8d90 [amdgpu] [ 33.868733] amdgpu_driver_load_kms+0x19/0xf0 [amdgpu] [ 33.869167] amdgpu_pci_probe+0x2d6/0xcd0 [amdgpu] [ 33.869608] local_pci_probe+0xda/0x180 [ 33.869614] pci_device_probe+0x43f/0x6b0 Empirically we can confirm that the former allocates 152 bytes for the table, while the latter memsets the 168 large block. Root cause appears that when GPU metrics tables for v2_4 parts were added it was not considered to enlarge the table to fit. The fix in this patch is rather \"brute force\" and perhaps later should be done in a smarter way, by extracting and consolidating the part version to size logic to a common helper, instead of brute forcing the largest possible allocation. Nevertheless, for now this works and fixes the out of bounds write. v2: * Drop impossible v3_0 case. (Mario) (cherry picked from commit 0880f58f9609f0200483a49429af0f050d281703)", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50222", "url": "https://ubuntu.com/security/CVE-2024-50222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iov_iter: fix copy_page_from_iter_atomic() if KMAP_LOCAL_FORCE_MAP generic/077 on x86_32 CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP=y with highmem, on huge=always tmpfs, issues a warning and then hangs (interruptibly): WARNING: CPU: 5 PID: 3517 at mm/highmem.c:622 kunmap_local_indexed+0x62/0xc9 CPU: 5 UID: 0 PID: 3517 Comm: cp Not tainted 6.12.0-rc4 #2 ... copy_page_from_iter_atomic+0xa6/0x5ec generic_perform_write+0xf6/0x1b4 shmem_file_write_iter+0x54/0x67 Fix copy_page_from_iter_atomic() by limiting it in that case (include/linux/skbuff.h skb_frag_must_loop() does similar). But going forward, perhaps CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP is too surprising, has outlived its usefulness, and should just be removed?", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50223", "url": "https://ubuntu.com/security/CVE-2024-50223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/numa: Fix the potential null pointer dereference in task_numa_work() When running stress-ng-vm-segv test, we found a null pointer dereference error in task_numa_work(). Here is the backtrace: [323676.066985] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ...... [323676.067108] CPU: 35 PID: 2694524 Comm: stress-ng-vm-se ...... [323676.067113] pstate: 23401009 (nzCv daif +PAN -UAO +TCO +DIT +SSBS BTYPE=--) [323676.067115] pc : vma_migratable+0x1c/0xd0 [323676.067122] lr : task_numa_work+0x1ec/0x4e0 [323676.067127] sp : ffff8000ada73d20 [323676.067128] x29: ffff8000ada73d20 x28: 0000000000000000 x27: 000000003e89f010 [323676.067130] x26: 0000000000080000 x25: ffff800081b5c0d8 x24: ffff800081b27000 [323676.067133] x23: 0000000000010000 x22: 0000000104d18cc0 x21: ffff0009f7158000 [323676.067135] x20: 0000000000000000 x19: 0000000000000000 x18: ffff8000ada73db8 [323676.067138] x17: 0001400000000000 x16: ffff800080df40b0 x15: 0000000000000035 [323676.067140] x14: ffff8000ada73cc8 x13: 1fffe0017cc72001 x12: ffff8000ada73cc8 [323676.067142] x11: ffff80008001160c x10: ffff000be639000c x9 : ffff8000800f4ba4 [323676.067145] x8 : ffff000810375000 x7 : ffff8000ada73974 x6 : 0000000000000001 [323676.067147] x5 : 0068000b33e26707 x4 : 0000000000000001 x3 : ffff0009f7158000 [323676.067149] x2 : 0000000000000041 x1 : 0000000000004400 x0 : 0000000000000000 [323676.067152] Call trace: [323676.067153] vma_migratable+0x1c/0xd0 [323676.067155] task_numa_work+0x1ec/0x4e0 [323676.067157] task_work_run+0x78/0xd8 [323676.067161] do_notify_resume+0x1ec/0x290 [323676.067163] el0_svc+0x150/0x160 [323676.067167] el0t_64_sync_handler+0xf8/0x128 [323676.067170] el0t_64_sync+0x17c/0x180 [323676.067173] Code: d2888001 910003fd f9000bf3 aa0003f3 (f9401000) [323676.067177] SMP: stopping secondary CPUs [323676.070184] Starting crashdump kernel... stress-ng-vm-segv in stress-ng is used to stress test the SIGSEGV error handling function of the system, which tries to cause a SIGSEGV error on return from unmapping the whole address space of the child process. Normally this program will not cause kernel crashes. But before the munmap system call returns to user mode, a potential task_numa_work() for numa balancing could be added and executed. In this scenario, since the child process has no vma after munmap, the vma_next() in task_numa_work() will return a null pointer even if the vma iterator restarts from 0. Recheck the vma pointer before dereferencing it in task_numa_work().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53053", "url": "https://ubuntu.com/security/CVE-2024-53053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Fix another deadlock during RTC update If ufshcd_rtc_work calls ufshcd_rpm_put_sync() and the pm's usage_count is 0, we will enter the runtime suspend callback. However, the runtime suspend callback will wait to flush ufshcd_rtc_work, causing a deadlock. Replace ufshcd_rpm_put_sync() with ufshcd_rpm_put() to avoid the deadlock.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53075", "url": "https://ubuntu.com/security/CVE-2024-53075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv: Prevent a bad reference count on CPU nodes When populating cache leaves we previously fetched the CPU device node at the very beginning. But when ACPI is enabled we go through a specific branch which returns early and does not call 'of_node_put' for the node that was acquired. Since we are not using a CPU device node for the ACPI code anyways, we can simply move the initialization of it just passed the ACPI block, and we are guaranteed to have an 'of_node_put' call for the acquired node. This prevents a bad reference count of the CPU device node. Moreover, the previous function did not check for errors when acquiring the device node, so a return -ENOENT has been added for that case.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50224", "url": "https://ubuntu.com/security/CVE-2024-50224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: spi-fsl-dspi: Fix crash when not using GPIO chip select Add check for the return value of spi_get_csgpiod() to avoid passing a NULL pointer to gpiod_direction_output(), preventing a crash when GPIO chip select is not used. Fix below crash: [ 4.251960] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 4.260762] Mem abort info: [ 4.263556] ESR = 0x0000000096000004 [ 4.267308] EC = 0x25: DABT (current EL), IL = 32 bits [ 4.272624] SET = 0, FnV = 0 [ 4.275681] EA = 0, S1PTW = 0 [ 4.278822] FSC = 0x04: level 0 translation fault [ 4.283704] Data abort info: [ 4.286583] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 4.292074] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 4.297130] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 4.302445] [0000000000000000] user address but active_mm is swapper [ 4.308805] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 4.315072] Modules linked in: [ 4.318124] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc4-next-20241023-00008-ga20ec42c5fc1 #359 [ 4.328130] Hardware name: LS1046A QDS Board (DT) [ 4.332832] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 4.339794] pc : gpiod_direction_output+0x34/0x5c [ 4.344505] lr : gpiod_direction_output+0x18/0x5c [ 4.349208] sp : ffff80008003b8f0 [ 4.352517] x29: ffff80008003b8f0 x28: 0000000000000000 x27: ffffc96bcc7e9068 [ 4.359659] x26: ffffc96bcc6e00b0 x25: ffffc96bcc598398 x24: ffff447400132810 [ 4.366800] x23: 0000000000000000 x22: 0000000011e1a300 x21: 0000000000020002 [ 4.373940] x20: 0000000000000000 x19: 0000000000000000 x18: ffffffffffffffff [ 4.381081] x17: ffff44740016e600 x16: 0000000500000003 x15: 0000000000000007 [ 4.388221] x14: 0000000000989680 x13: 0000000000020000 x12: 000000000000001e [ 4.395362] x11: 0044b82fa09b5a53 x10: 0000000000000019 x9 : 0000000000000008 [ 4.402502] x8 : 0000000000000002 x7 : 0000000000000007 x6 : 0000000000000000 [ 4.409641] x5 : 0000000000000200 x4 : 0000000002000000 x3 : 0000000000000000 [ 4.416781] x2 : 0000000000022202 x1 : 0000000000000000 x0 : 0000000000000000 [ 4.423921] Call trace: [ 4.426362] gpiod_direction_output+0x34/0x5c (P) [ 4.431067] gpiod_direction_output+0x18/0x5c (L) [ 4.435771] dspi_setup+0x220/0x334", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50225", "url": "https://ubuntu.com/security/CVE-2024-50225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix error propagation of split bios The purpose of btrfs_bbio_propagate_error() shall be propagating an error of split bio to its original btrfs_bio, and tell the error to the upper layer. However, it's not working well on some cases. * Case 1. Immediate (or quick) end_bio with an error When btrfs sends btrfs_bio to mirrored devices, btrfs calls btrfs_bio_end_io() when all the mirroring bios are completed. If that btrfs_bio was split, it is from btrfs_clone_bioset and its end_io function is btrfs_orig_write_end_io. For this case, btrfs_bbio_propagate_error() accesses the orig_bbio's bio context to increase the error count. That works well in most cases. However, if the end_io is called enough fast, orig_bbio's (remaining part after split) bio context may not be properly set at that time. Since the bio context is set when the orig_bbio (the last btrfs_bio) is sent to devices, that might be too late for earlier split btrfs_bio's completion. That will result in NULL pointer dereference. That bug is easily reproducible by running btrfs/146 on zoned devices [1] and it shows the following trace. [1] You need raid-stripe-tree feature as it create \"-d raid0 -m raid1\" FS. BUG: kernel NULL pointer dereference, address: 0000000000000020 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 UID: 0 PID: 13 Comm: kworker/u32:1 Not tainted 6.11.0-rc7-BTRFS-ZNS+ #474 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Workqueue: writeback wb_workfn (flush-btrfs-5) RIP: 0010:btrfs_bio_end_io+0xae/0xc0 [btrfs] BTRFS error (device dm-0): bdev /dev/mapper/error-test errs: wr 2, rd 0, flush 0, corrupt 0, gen 0 RSP: 0018:ffffc9000006f248 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888005a7f080 RCX: ffffc9000006f1dc RDX: 0000000000000000 RSI: 000000000000000a RDI: ffff888005a7f080 RBP: ffff888011dfc540 R08: 0000000000000000 R09: 0000000000000001 R10: ffffffff82e508e0 R11: 0000000000000005 R12: ffff88800ddfbe58 R13: ffff888005a7f080 R14: ffff888005a7f158 R15: ffff888005a7f158 FS: 0000000000000000(0000) GS:ffff88803ea80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000020 CR3: 0000000002e22006 CR4: 0000000000370ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __die_body.cold+0x19/0x26 ? page_fault_oops+0x13e/0x2b0 ? _printk+0x58/0x73 ? do_user_addr_fault+0x5f/0x750 ? exc_page_fault+0x76/0x240 ? asm_exc_page_fault+0x22/0x30 ? btrfs_bio_end_io+0xae/0xc0 [btrfs] ? btrfs_log_dev_io_error+0x7f/0x90 [btrfs] btrfs_orig_write_end_io+0x51/0x90 [btrfs] dm_submit_bio+0x5c2/0xa50 [dm_mod] ? find_held_lock+0x2b/0x80 ? blk_try_enter_queue+0x90/0x1e0 __submit_bio+0xe0/0x130 ? ktime_get+0x10a/0x160 ? lockdep_hardirqs_on+0x74/0x100 submit_bio_noacct_nocheck+0x199/0x410 btrfs_submit_bio+0x7d/0x150 [btrfs] btrfs_submit_chunk+0x1a1/0x6d0 [btrfs] ? lockdep_hardirqs_on+0x74/0x100 ? __folio_start_writeback+0x10/0x2c0 btrfs_submit_bbio+0x1c/0x40 [btrfs] submit_one_bio+0x44/0x60 [btrfs] submit_extent_folio+0x13f/0x330 [btrfs] ? btrfs_set_range_writeback+0xa3/0xd0 [btrfs] extent_writepage_io+0x18b/0x360 [btrfs] extent_write_locked_range+0x17c/0x340 [btrfs] ? __pfx_end_bbio_data_write+0x10/0x10 [btrfs] run_delalloc_cow+0x71/0xd0 [btrfs] btrfs_run_delalloc_range+0x176/0x500 [btrfs] ? find_lock_delalloc_range+0x119/0x260 [btrfs] writepage_delalloc+0x2ab/0x480 [btrfs] extent_write_cache_pages+0x236/0x7d0 [btrfs] btrfs_writepages+0x72/0x130 [btrfs] do_writepages+0xd4/0x240 ? find_held_lock+0x2b/0x80 ? wbc_attach_and_unlock_inode+0x12c/0x290 ? wbc_attach_and_unlock_inode+0x12c/0x29 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53054", "url": "https://ubuntu.com/security/CVE-2024-53054", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50226", "url": "https://ubuntu.com/security/CVE-2024-50226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cxl/port: Fix use-after-free, permit out-of-order decoder shutdown In support of investigating an initialization failure report [1], cxl_test was updated to register mock memory-devices after the mock root-port/bus device had been registered. That led to cxl_test crashing with a use-after-free bug with the following signature: cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem0:decoder7.0 @ 0 next: cxl_switch_uport.0 nr_eps: 1 nr_targets: 1 cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem4:decoder14.0 @ 1 next: cxl_switch_uport.0 nr_eps: 2 nr_targets: 1 cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[0] = cxl_switch_dport.0 for mem0:decoder7.0 @ 0 1) cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[1] = cxl_switch_dport.4 for mem4:decoder14.0 @ 1 [..] cxld_unregister: cxl decoder14.0: cxl_region_decode_reset: cxl_region region3: mock_decoder_reset: cxl_port port3: decoder3.0 reset 2) mock_decoder_reset: cxl_port port3: decoder3.0: out of order reset, expected decoder3.1 cxl_endpoint_decoder_release: cxl decoder14.0: [..] cxld_unregister: cxl decoder7.0: 3) cxl_region_decode_reset: cxl_region region3: Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6bc3: 0000 [#1] PREEMPT SMP PTI [..] RIP: 0010:to_cxl_port+0x8/0x60 [cxl_core] [..] Call Trace: cxl_region_decode_reset+0x69/0x190 [cxl_core] cxl_region_detach+0xe8/0x210 [cxl_core] cxl_decoder_kill_region+0x27/0x40 [cxl_core] cxld_unregister+0x5d/0x60 [cxl_core] At 1) a region has been established with 2 endpoint decoders (7.0 and 14.0). Those endpoints share a common switch-decoder in the topology (3.0). At teardown, 2), decoder14.0 is the first to be removed and hits the \"out of order reset case\" in the switch decoder. The effect though is that region3 cleanup is aborted leaving it in-tact and referencing decoder14.0. At 3) the second attempt to teardown region3 trips over the stale decoder14.0 object which has long since been deleted. The fix here is to recognize that the CXL specification places no mandate on in-order shutdown of switch-decoders, the driver enforces in-order allocation, and hardware enforces in-order commit. So, rather than fail and leave objects dangling, always remove them. In support of making cxl_region_decode_reset() always succeed, cxl_region_invalidate_memregion() failures are turned into warnings. Crashing the kernel is ok there since system integrity is at risk if caches cannot be managed around physical address mutation events like CXL region destruction. A new device_for_each_child_reverse_from() is added to cleanup port->commit_end after all dependent decoders have been disabled. In other words if decoders are allocated 0->1->2 and disabled 1->2->0 then port->commit_end only decrements from 2 after 2 has been disabled, and it decrements all the way to zero since 1 was disabled previously.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50227", "url": "https://ubuntu.com/security/CVE-2024-50227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Fix KASAN reported stack out-of-bounds read in tb_retimer_scan() KASAN reported following issue: BUG: KASAN: stack-out-of-bounds in tb_retimer_scan+0xffe/0x1550 [thunderbolt] Read of size 4 at addr ffff88810111fc1c by task kworker/u56:0/11 CPU: 0 UID: 0 PID: 11 Comm: kworker/u56:0 Tainted: G U 6.11.0+ #1387 Tainted: [U]=USER Workqueue: thunderbolt0 tb_handle_hotplug [thunderbolt] Call Trace: dump_stack_lvl+0x6c/0x90 print_report+0xd1/0x630 kasan_report+0xdb/0x110 __asan_report_load4_noabort+0x14/0x20 tb_retimer_scan+0xffe/0x1550 [thunderbolt] tb_scan_port+0xa6f/0x2060 [thunderbolt] tb_handle_hotplug+0x17b1/0x3080 [thunderbolt] process_one_work+0x626/0x1100 worker_thread+0x6c8/0xfa0 kthread+0x2c8/0x3a0 ret_from_fork+0x3a/0x80 ret_from_fork_asm+0x1a/0x30 This happens because the loop variable still gets incremented by one so max becomes 3 instead of 2, and this makes the second loop read past the the array declared on the stack. Fix this by assigning to max directly in the loop body.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50228", "url": "https://ubuntu.com/security/CVE-2024-50228", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50229", "url": "https://ubuntu.com/security/CVE-2024-50229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential deadlock with newly created symlinks Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers memory reclamation involving the filesystem layer, which can result in circular lock dependencies among the reader/writer semaphore nilfs->ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the fs_reclaim pseudo lock. This is because after commit 21fc61c73c39 (\"don't put symlink bodies in pagecache into highmem\"), the gfp flags of the page cache for symbolic links are overwritten to GFP_KERNEL via inode_nohighmem(). This is not a problem for symlinks read from the backing device, because the __GFP_FS flag is dropped after inode_nohighmem() is called. However, when a new symlink is created with nilfs_symlink(), the gfp flags remain overwritten to GFP_KERNEL. Then, memory allocation called from page_symlink() etc. triggers memory reclamation including the FS layer, which may call nilfs_evict_inode() or nilfs_dirty_inode(). And these can cause a deadlock if they are called while nilfs->ns_segctor_sem is held: Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags of newly created symlinks in the same way that nilfs_new_inode() and __nilfs_read_inode() do, as a workaround until we adopt nofs allocation scope consistently or improve the locking constraints.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50230", "url": "https://ubuntu.com/security/CVE-2024-50230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug due to missing clearing of checked flag Syzbot reported that in directory operations after nilfs2 detects filesystem corruption and degrades to read-only, __block_write_begin_int(), which is called to prepare block writes, may fail the BUG_ON check for accesses exceeding the folio/page size, triggering a kernel bug. This was found to be because the \"checked\" flag of a page/folio was not cleared when it was discarded by nilfs2's own routine, which causes the sanity check of directory entries to be skipped when the directory page/folio is reloaded. So, fix that. This was necessary when the use of nilfs2's own page discard routine was applied to more than just metadata files.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50231", "url": "https://ubuntu.com/security/CVE-2024-50231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gts-helper: Fix memory leaks in iio_gts_build_avail_scale_table() modprobe iio-test-gts and rmmod it, then the following memory leak occurs: \tunreferenced object 0xffffff80c810be00 (size 64): \t comm \"kunit_try_catch\", pid 1654, jiffies 4294913981 \t hex dump (first 32 bytes): \t 02 00 00 00 08 00 00 00 20 00 00 00 40 00 00 00 ........ ...@... \t 80 00 00 00 00 02 00 00 00 04 00 00 00 08 00 00 ................ \t backtrace (crc a63d875e): \t [<0000000028c1b3c2>] kmemleak_alloc+0x34/0x40 \t [<000000001d6ecc87>] __kmalloc_noprof+0x2bc/0x3c0 \t [<00000000393795c1>] devm_iio_init_iio_gts+0x4b4/0x16f4 \t [<0000000071bb4b09>] 0xffffffdf052a62e0 \t [<000000000315bc18>] 0xffffffdf052a6488 \t [<00000000f9dc55b5>] kunit_try_run_case+0x13c/0x3ac \t [<00000000175a3fd4>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000f505065d>] kthread+0x2e8/0x374 \t [<00000000bbfb0e5d>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cbfe9e70 (size 16): \t comm \"kunit_try_catch\", pid 1658, jiffies 4294914015 \t hex dump (first 16 bytes): \t 10 00 00 00 40 00 00 00 80 00 00 00 00 00 00 00 ....@........... \t backtrace (crc 857f0cb4): \t [<0000000028c1b3c2>] kmemleak_alloc+0x34/0x40 \t [<000000001d6ecc87>] __kmalloc_noprof+0x2bc/0x3c0 \t [<00000000393795c1>] devm_iio_init_iio_gts+0x4b4/0x16f4 \t [<0000000071bb4b09>] 0xffffffdf052a62e0 \t [<000000007d089d45>] 0xffffffdf052a6864 \t [<00000000f9dc55b5>] kunit_try_run_case+0x13c/0x3ac \t [<00000000175a3fd4>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000f505065d>] kthread+0x2e8/0x374 \t [<00000000bbfb0e5d>] ret_from_fork+0x10/0x20 \t...... It includes 5*5 times \"size 64\" memory leaks, which correspond to 5 times test_init_iio_gain_scale() calls with gts_test_gains size 10 (10*size(int)) and gts_test_itimes size 5. It also includes 5*1 times \"size 16\" memory leak, which correspond to one time __test_init_iio_gain_scale() call with gts_test_gains_gain_low size 3 (3*size(int)) and gts_test_itimes size 5. The reason is that the per_time_gains[i] is not freed which is allocated in the \"gts->num_itime\" for loop in iio_gts_build_avail_scale_table().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53076", "url": "https://ubuntu.com/security/CVE-2024-53076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gts-helper: Fix memory leaks for the error path of iio_gts_build_avail_scale_table() If per_time_scales[i] or per_time_gains[i] kcalloc fails in the for loop of iio_gts_build_avail_scale_table(), the err_free_out will fail to call kfree() each time when i is reduced to 0, so all the per_time_scales[0] and per_time_gains[0] will not be freed, which will cause memory leaks. Fix it by checking if i >= 0.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50232", "url": "https://ubuntu.com/security/CVE-2024-50232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr() In the ad7124_write_raw() function, parameter val can potentially be zero. This may lead to a division by zero when DIV_ROUND_CLOSEST() is called within ad7124_set_channel_odr(). The ad7124_write_raw() function is invoked through the sequence: iio_write_channel_raw() -> iio_write_channel_attribute() -> iio_channel_write(), with no checks in place to ensure val is non-zero.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50233", "url": "https://ubuntu.com/security/CVE-2024-50233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: iio: frequency: ad9832: fix division by zero in ad9832_calc_freqreg() In the ad9832_write_frequency() function, clk_get_rate() might return 0. This can lead to a division by zero when calling ad9832_calc_freqreg(). The check if (fout > (clk_get_rate(st->mclk) / 2)) does not protect against the case when fout is 0. The ad9832_write_frequency() function is called from ad9832_write(), and fout is derived from a text buffer, which can contain any value.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53055", "url": "https://ubuntu.com/security/CVE-2024-53055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix 6 GHz scan construction If more than 255 colocated APs exist for the set of all APs found during 2.4/5 GHz scanning, then the 6 GHz scan construction will loop forever since the loop variable has type u8, which can never reach the number found when that's bigger than 255, and is stored in a u32 variable. Also move it into the loops to have a smaller scope. Using a u32 there is fine, we limit the number of APs in the scan list and each has a limit on the number of RNR entries due to the frame size. With a limit of 1000 scan results, a frame size upper bound of 4096 (really it's more like ~2300) and a TBTT entry size of at least 11, we get an upper bound for the number of ~372k, well in the bounds of a u32.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50234", "url": "https://ubuntu.com/security/CVE-2024-50234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlegacy: Clear stale interrupts before resuming device iwl4965 fails upon resume from hibernation on my laptop. The reason seems to be a stale interrupt which isn't being cleared out before interrupts are enabled. We end up with a race beween the resume trying to bring things back up, and the restart work (queued form the interrupt handler) trying to bring things down. Eventually the whole thing blows up. Fix the problem by clearing out any stale interrupts before interrupts get enabled during resume. Here's a debug log of the indicent: [ 12.042589] ieee80211 phy0: il_isr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000 [ 12.042625] ieee80211 phy0: il4965_irq_tasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000 [ 12.042651] iwl4965 0000:10:00.0: RF_KILL bit toggled to enable radio. [ 12.042653] iwl4965 0000:10:00.0: On demand firmware reload [ 12.042690] ieee80211 phy0: il4965_irq_tasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282 [ 12.052207] ieee80211 phy0: il4965_mac_start enter [ 12.052212] ieee80211 phy0: il_prep_station Add STA to driver ID 31: ff:ff:ff:ff:ff:ff [ 12.052244] ieee80211 phy0: il4965_set_hw_ready hardware ready [ 12.052324] ieee80211 phy0: il_apm_init Init card's basic functions [ 12.052348] ieee80211 phy0: il_apm_init L1 Enabled; Disabling L0S [ 12.055727] ieee80211 phy0: il4965_load_bsm Begin load bsm [ 12.056140] ieee80211 phy0: il4965_verify_bsm Begin verify bsm [ 12.058642] ieee80211 phy0: il4965_verify_bsm BSM bootstrap uCode image OK [ 12.058721] ieee80211 phy0: il4965_load_bsm BSM write complete, poll 1 iterations [ 12.058734] ieee80211 phy0: __il4965_up iwl4965 is coming up [ 12.058737] ieee80211 phy0: il4965_mac_start Start UP work done. [ 12.058757] ieee80211 phy0: __il4965_down iwl4965 is going down [ 12.058761] ieee80211 phy0: il_scan_cancel_timeout Scan cancel timeout [ 12.058762] ieee80211 phy0: il_do_scan_abort Not performing scan to abort [ 12.058765] ieee80211 phy0: il_clear_ucode_stations Clearing ucode stations in driver [ 12.058767] ieee80211 phy0: il_clear_ucode_stations No active stations found to be cleared [ 12.058819] ieee80211 phy0: _il_apm_stop Stop card, put in low power state [ 12.058827] ieee80211 phy0: _il_apm_stop_master stop master [ 12.058864] ieee80211 phy0: il4965_clear_free_frames 0 frames on pre-allocated heap on clear. [ 12.058869] ieee80211 phy0: Hardware restart was requested [ 16.132299] iwl4965 0000:10:00.0: START_ALIVE timeout after 4000ms. [ 16.132303] ------------[ cut here ]------------ [ 16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue. [ 16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132390] Modules linked in: ctr ccm sch_fq_codel xt_tcpudp xt_multiport xt_state iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables binfmt_misc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdh_generic ecc iTCO_wdt i2c_dev iwl4965 iwlegacy coretemp snd_hda_codec_analog pcspkr psmouse mac80211 snd_hda_codec_generic libarc4 sdhci_pci cqhci sha256_generic sdhci libsha256 firewire_ohci snd_hda_intel snd_intel_dspcfg mmc_core snd_hda_codec snd_hwdep firewire_core led_class iosf_mbi snd_hda_core uhci_hcd lpc_ich crc_itu_t cfg80211 ehci_pci ehci_hcd snd_pcm usbcore mfd_core rfkill snd_timer snd usb_common soundcore video parport_pc parport intel_agp wmi intel_gtt backlight e1000e agpgart evdev [ 16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143 [ 16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010 [ 16.132463] Workqueue: async async_run_entry_fn [ 16.132469] RIP: 0010:ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132501] Code: da 02 00 0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50235", "url": "https://ubuntu.com/security/CVE-2024-50235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: clear wdev->cqm_config pointer on free When we free wdev->cqm_config when unregistering, we also need to clear out the pointer since the same wdev/netdev may get re-registered in another network namespace, then destroyed later, running this code again, which results in a double-free.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50236", "url": "https://ubuntu.com/security/CVE-2024-50236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: Fix memory leak in management tx In the current logic, memory is allocated for storing the MSDU context during management packet TX but this memory is not being freed during management TX completion. Similar leaks are seen in the management TX cleanup logic. Kmemleak reports this problem as below, unreferenced object 0xffffff80b64ed250 (size 16): comm \"kworker/u16:7\", pid 148, jiffies 4294687130 (age 714.199s) hex dump (first 16 bytes): 00 2b d8 d8 80 ff ff ff c4 74 e9 fd 07 00 00 00 .+.......t...... backtrace: [] __kmem_cache_alloc_node+0x1e4/0x2d8 [] kmalloc_trace+0x48/0x110 [] ath10k_wmi_tlv_op_gen_mgmt_tx_send+0xd4/0x1d8 [ath10k_core] [] ath10k_mgmt_over_wmi_tx_work+0x134/0x298 [ath10k_core] [] process_scheduled_works+0x1ac/0x400 [] worker_thread+0x208/0x328 [] kthread+0x100/0x1c0 [] ret_from_fork+0x10/0x20 Free the memory during completion and cleanup to fix the leak. Protect the mgmt_pending_tx idr_remove() operation in ath10k_wmi_tlv_op_cleanup_mgmt_tx_send() using ar->data_lock similar to other instances. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50237", "url": "https://ubuntu.com/security/CVE-2024-50237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower Avoid potentially crashing in the driver because of uninitialized private data", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50238", "url": "https://ubuntu.com/security/CVE-2024-50238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usbc: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data from the qcom-qmp-usb driver, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. This bug was later reproduced when the driver was copied to create the qmp-usbc driver. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with these drivers.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50239", "url": "https://ubuntu.com/security/CVE-2024-50239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usb-legacy: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data from the qcom-qmp-usb driver, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. This bug was later reproduced when the driver was copied to create the qmp-usb-legacy driver. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with these drivers.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50240", "url": "https://ubuntu.com/security/CVE-2024-50240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usb: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with this driver.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53077", "url": "https://ubuntu.com/security/CVE-2024-53077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpcrdma: Always release the rpcrdma_device's xa_array Dai pointed out that the xa_init_flags() in rpcrdma_add_one() needs to have a matching xa_destroy() in rpcrdma_remove_one() to release underlying memory that the xarray might have accrued during operation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50242", "url": "https://ubuntu.com/security/CVE-2024-50242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ntfs_file_release", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50243", "url": "https://ubuntu.com/security/CVE-2024-50243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix general protection fault in run_is_mapped_full Fixed deleating of a non-resident attribute in ntfs_create_inode() rollback.", "cve_priority": "low", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50244", "url": "https://ubuntu.com/security/CVE-2024-50244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ni_clear() Checking of NTFS_FLAGS_LOG_REPLAYING added to prevent access to uninitialized bitmap during replay process.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50245", "url": "https://ubuntu.com/security/CVE-2024-50245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix possible deadlock in mi_read Mutex lock with another subclass used in ni_lock_dir().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50246", "url": "https://ubuntu.com/security/CVE-2024-50246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Add rough attr alloc_size check", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50247", "url": "https://ubuntu.com/security/CVE-2024-50247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Check if more than chunk-size bytes are written A incorrectly formatted chunk may decompress into more than LZNT_CHUNK_SIZE bytes and a index out of bounds will occur in s_max_off.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50248", "url": "https://ubuntu.com/security/CVE-2024-50248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Add bounds checking to mi_enum_attr() Added bounds checking to make sure that every attr don't stray beyond valid memory region.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53078", "url": "https://ubuntu.com/security/CVE-2024-53078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Fix NULL vs IS_ERR() check in probe() The iommu_paging_domain_alloc() function doesn't return NULL pointers, it returns error pointers. Update the check to match.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53056", "url": "https://ubuntu.com/security/CVE-2024-53056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Fix potential NULL dereference in mtk_crtc_destroy() In mtk_crtc_create(), if the call to mbox_request_channel() fails then we set the \"mtk_crtc->cmdq_client.chan\" pointer to NULL. In that situation, we do not call cmdq_pkt_create(). During the cleanup, we need to check if the \"mtk_crtc->cmdq_client.chan\" is NULL first before calling cmdq_pkt_destroy(). Calling cmdq_pkt_destroy() is unnecessary if we didn't call cmdq_pkt_create() and it will result in a NULL pointer dereference.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50249", "url": "https://ubuntu.com/security/CVE-2024-50249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Make rmw_lock a raw_spin_lock The following BUG was triggered: ============================= [ BUG: Invalid wait context ] 6.12.0-rc2-XXX #406 Not tainted ----------------------------- kworker/1:1/62 is trying to lock: ffffff8801593030 (&cpc_ptr->rmw_lock){+.+.}-{3:3}, at: cpc_write+0xcc/0x370 other info that might help us debug this: context-{5:5} 2 locks held by kworker/1:1/62: #0: ffffff897ef5ec98 (&rq->__lock){-.-.}-{2:2}, at: raw_spin_rq_lock_nested+0x2c/0x50 #1: ffffff880154e238 (&sg_policy->update_lock){....}-{2:2}, at: sugov_update_shared+0x3c/0x280 stack backtrace: CPU: 1 UID: 0 PID: 62 Comm: kworker/1:1 Not tainted 6.12.0-rc2-g9654bd3e8806 #406 Workqueue: 0x0 (events) Call trace: dump_backtrace+0xa4/0x130 show_stack+0x20/0x38 dump_stack_lvl+0x90/0xd0 dump_stack+0x18/0x28 __lock_acquire+0x480/0x1ad8 lock_acquire+0x114/0x310 _raw_spin_lock+0x50/0x70 cpc_write+0xcc/0x370 cppc_set_perf+0xa0/0x3a8 cppc_cpufreq_fast_switch+0x40/0xc0 cpufreq_driver_fast_switch+0x4c/0x218 sugov_update_shared+0x234/0x280 update_load_avg+0x6ec/0x7b8 dequeue_entities+0x108/0x830 dequeue_task_fair+0x58/0x408 __schedule+0x4f0/0x1070 schedule+0x54/0x130 worker_thread+0xc0/0x2e8 kthread+0x130/0x148 ret_from_fork+0x10/0x20 sugov_update_shared() locks a raw_spinlock while cpc_write() locks a spinlock. To have a correct wait-type order, update rmw_lock to a raw spinlock and ensure that interrupts will be disabled on the CPU holding it. [ rjw: Changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50250", "url": "https://ubuntu.com/security/CVE-2024-50250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fsdax: dax_unshare_iter needs to copy entire blocks The code that copies data from srcmap to iomap in dax_unshare_iter is very very broken, which bfoster's recent fsx changes have exposed. If the pos and len passed to dax_file_unshare are not aligned to an fsblock boundary, the iter pos and length in the _iter function will reflect this unalignment. dax_iomap_direct_access always returns a pointer to the start of the kmapped fsdax page, even if its pos argument is in the middle of that page. This is catastrophic for data integrity when iter->pos is not aligned to a page, because daddr/saddr do not point to the same byte in the file as iter->pos. Hence we corrupt user data by copying it to the wrong place. If iter->pos + iomap_length() in the _iter function not aligned to a page, then we fail to copy a full block, and only partially populate the destination block. This is catastrophic for data confidentiality because we expose stale pmem contents. Fix both of these issues by aligning copy_pos/copy_len to a page boundary (remember, this is fsdax so 1 fsblock == 1 base page) so that we always copy full blocks. We're not done yet -- there's no call to invalidate_inode_pages2_range, so programs that have the file range mmap'd will continue accessing the old memory mapping after the file metadata updates have completed. Be careful with the return value -- if the unshare succeeds, we still need to return the number of bytes that the iomap iter thinks we're operating on.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50251", "url": "https://ubuntu.com/security/CVE-2024-50251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_payload: sanitize offset and length before calling skb_checksum() If access to offset + length is larger than the skbuff length, then skb_checksum() triggers BUG_ON(). skb_checksum() internally subtracts the length parameter while iterating over skbuff, BUG_ON(len) at the end of it checks that the expected length to be included in the checksum calculation is fully consumed.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50252", "url": "https://ubuntu.com/security/CVE-2024-50252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_ipip: Fix memory leak when changing remote IPv6 address The device stores IPv6 addresses that are used for encapsulation in linear memory that is managed by the driver. Changing the remote address of an ip6gre net device never worked properly, but since cited commit the following reproducer [1] would result in a warning [2] and a memory leak [3]. The problem is that the new remote address is never added by the driver to its hash table (and therefore the device) and the old address is never removed from it. Fix by programming the new address when the configuration of the ip6gre net device changes and removing the old one. If the address did not change, then the above would result in increasing the reference count of the address and then decreasing it. [1] # ip link add name bla up type ip6gre local 2001:db8:1::1 remote 2001:db8:2::1 tos inherit ttl inherit # ip link set dev bla type ip6gre remote 2001:db8:3::1 # ip link del dev bla # devlink dev reload pci/0000:01:00.0 [2] WARNING: CPU: 0 PID: 1682 at drivers/net/ethernet/mellanox/mlxsw/spectrum.c:3002 mlxsw_sp_ipv6_addr_put+0x140/0x1d0 Modules linked in: CPU: 0 UID: 0 PID: 1682 Comm: ip Not tainted 6.12.0-rc3-custom-g86b5b55bc835 #151 Hardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023 RIP: 0010:mlxsw_sp_ipv6_addr_put+0x140/0x1d0 [...] Call Trace: mlxsw_sp_router_netdevice_event+0x55f/0x1240 notifier_call_chain+0x5a/0xd0 call_netdevice_notifiers_info+0x39/0x90 unregister_netdevice_many_notify+0x63e/0x9d0 rtnl_dellink+0x16b/0x3a0 rtnetlink_rcv_msg+0x142/0x3f0 netlink_rcv_skb+0x50/0x100 netlink_unicast+0x242/0x390 netlink_sendmsg+0x1de/0x420 ____sys_sendmsg+0x2bd/0x320 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xd0 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f [3] unreferenced object 0xffff898081f597a0 (size 32): comm \"ip\", pid 1626, jiffies 4294719324 hex dump (first 32 bytes): 20 01 0d b8 00 02 00 00 00 00 00 00 00 00 00 01 ............... 21 49 61 83 80 89 ff ff 00 00 00 00 01 00 00 00 !Ia............. backtrace (crc fd9be911): [<00000000df89c55d>] __kmalloc_cache_noprof+0x1da/0x260 [<00000000ff2a1ddb>] mlxsw_sp_ipv6_addr_kvdl_index_get+0x281/0x340 [<000000009ddd445d>] mlxsw_sp_router_netdevice_event+0x47b/0x1240 [<00000000743e7757>] notifier_call_chain+0x5a/0xd0 [<000000007c7b9e13>] call_netdevice_notifiers_info+0x39/0x90 [<000000002509645d>] register_netdevice+0x5f7/0x7a0 [<00000000c2e7d2a9>] ip6gre_newlink_common.isra.0+0x65/0x130 [<0000000087cd6d8d>] ip6gre_newlink+0x72/0x120 [<000000004df7c7cc>] rtnl_newlink+0x471/0xa20 [<0000000057ed632a>] rtnetlink_rcv_msg+0x142/0x3f0 [<0000000032e0d5b5>] netlink_rcv_skb+0x50/0x100 [<00000000908bca63>] netlink_unicast+0x242/0x390 [<00000000cdbe1c87>] netlink_sendmsg+0x1de/0x420 [<0000000011db153e>] ____sys_sendmsg+0x2bd/0x320 [<000000003b6d53eb>] ___sys_sendmsg+0x9a/0xe0 [<00000000cae27c62>] __sys_sendmsg+0x7a/0xd0", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50253", "url": "https://ubuntu.com/security/CVE-2024-50253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check the validity of nr_words in bpf_iter_bits_new() Check the validity of nr_words in bpf_iter_bits_new(). Without this check, when multiplication overflow occurs for nr_bits (e.g., when nr_words = 0x0400-0001, nr_bits becomes 64), stack corruption may occur due to bpf_probe_read_kernel_common(..., nr_bytes = 0x2000-0008). Fix it by limiting the maximum value of nr_words to 511. The value is derived from the current implementation of BPF memory allocator. To ensure compatibility if the BPF memory allocator's size limitation changes in the future, use the helper bpf_mem_alloc_check_size() to check whether nr_bytes is too larger. And return -E2BIG instead of -ENOMEM for oversized nr_bytes.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50254", "url": "https://ubuntu.com/security/CVE-2024-50254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free dynamically allocated bits in bpf_iter_bits_destroy() bpf_iter_bits_destroy() uses \"kit->nr_bits <= 64\" to check whether the bits are dynamically allocated. However, the check is incorrect and may cause a kmemleak as shown below: unreferenced object 0xffff88812628c8c0 (size 32): comm \"swapper/0\", pid 1, jiffies 4294727320 hex dump (first 32 bytes): \tb0 c1 55 f5 81 88 ff ff f0 f0 f0 f0 f0 f0 f0 f0 ..U........... \tf0 f0 f0 f0 f0 f0 f0 f0 00 00 00 00 00 00 00 00 .............. backtrace (crc 781e32cc): \t[<00000000c452b4ab>] kmemleak_alloc+0x4b/0x80 \t[<0000000004e09f80>] __kmalloc_node_noprof+0x480/0x5c0 \t[<00000000597124d6>] __alloc.isra.0+0x89/0xb0 \t[<000000004ebfffcd>] alloc_bulk+0x2af/0x720 \t[<00000000d9c10145>] prefill_mem_cache+0x7f/0xb0 \t[<00000000ff9738ff>] bpf_mem_alloc_init+0x3e2/0x610 \t[<000000008b616eac>] bpf_global_ma_init+0x19/0x30 \t[<00000000fc473efc>] do_one_initcall+0xd3/0x3c0 \t[<00000000ec81498c>] kernel_init_freeable+0x66a/0x940 \t[<00000000b119f72f>] kernel_init+0x20/0x160 \t[<00000000f11ac9a7>] ret_from_fork+0x3c/0x70 \t[<0000000004671da4>] ret_from_fork_asm+0x1a/0x30 That is because nr_bits will be set as zero in bpf_iter_bits_next() after all bits have been iterated. Fix the issue by setting kit->bit to kit->nr_bits instead of setting kit->nr_bits to zero when the iteration completes in bpf_iter_bits_next(). In addition, use \"!nr_bits || bits >= nr_bits\" to check whether the iteration is complete and still use \"nr_bits > 64\" to indicate whether bits are dynamically allocated. The \"!nr_bits\" check is necessary because bpf_iter_bits_new() may fail before setting kit->nr_bits, and this condition will stop the iteration early instead of accessing the zeroed or freed kit->bits. Considering the initial value of kit->bits is -1 and the type of kit->nr_bits is unsigned int, change the type of kit->nr_bits to int. The potential overflow problem will be handled in the following patch.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50255", "url": "https://ubuntu.com/security/CVE-2024-50255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci: fix null-ptr-deref in hci_read_supported_codecs Fix __hci_cmd_sync_sk() to return not NULL for unknown opcodes. __hci_cmd_sync_sk() returns NULL if a command returns a status event. However, it also returns NULL where an opcode doesn't exist in the hci_cc table because hci_cmd_complete_evt() assumes status = skb->data[0] for unknown opcodes. This leads to null-ptr-deref in cmd_sync for HCI_OP_READ_LOCAL_CODECS as there is no hci_cc for HCI_OP_READ_LOCAL_CODECS, which always assumes status = skb->data[0]. KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077] CPU: 1 PID: 2000 Comm: kworker/u9:5 Not tainted 6.9.0-ga6bcb805883c-dirty #10 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: hci7 hci_power_on RIP: 0010:hci_read_supported_codecs+0xb9/0x870 net/bluetooth/hci_codec.c:138 Code: 08 48 89 ef e8 b8 c1 8f fd 48 8b 75 00 e9 96 00 00 00 49 89 c6 48 ba 00 00 00 00 00 fc ff df 4c 8d 60 70 4c 89 e3 48 c1 eb 03 <0f> b6 04 13 84 c0 0f 85 82 06 00 00 41 83 3c 24 02 77 0a e8 bf 78 RSP: 0018:ffff888120bafac8 EFLAGS: 00010212 RAX: 0000000000000000 RBX: 000000000000000e RCX: ffff8881173f0040 RDX: dffffc0000000000 RSI: ffffffffa58496c0 RDI: ffff88810b9ad1e4 RBP: ffff88810b9ac000 R08: ffffffffa77882a7 R09: 1ffffffff4ef1054 R10: dffffc0000000000 R11: fffffbfff4ef1055 R12: 0000000000000070 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88810b9ac000 FS: 0000000000000000(0000) GS:ffff8881f6c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6ddaa3439e CR3: 0000000139764003 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: hci_read_local_codecs_sync net/bluetooth/hci_sync.c:4546 [inline] hci_init_stage_sync net/bluetooth/hci_sync.c:3441 [inline] hci_init4_sync net/bluetooth/hci_sync.c:4706 [inline] hci_init_sync net/bluetooth/hci_sync.c:4742 [inline] hci_dev_init_sync net/bluetooth/hci_sync.c:4912 [inline] hci_dev_open_sync+0x19a9/0x2d30 net/bluetooth/hci_sync.c:4994 hci_dev_do_open net/bluetooth/hci_core.c:483 [inline] hci_power_on+0x11e/0x560 net/bluetooth/hci_core.c:1015 process_one_work kernel/workqueue.c:3267 [inline] process_scheduled_works+0x8ef/0x14f0 kernel/workqueue.c:3348 worker_thread+0x91f/0xe50 kernel/workqueue.c:3429 kthread+0x2cb/0x360 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50256", "url": "https://ubuntu.com/security/CVE-2024-50256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6() I got a syzbot report without a repro [1] crashing in nf_send_reset6() I think the issue is that dev->hard_header_len is zero, and we attempt later to push an Ethernet header. Use LL_MAX_HEADER, as other functions in net/ipv6/netfilter/nf_reject_ipv6.c. [1] skbuff: skb_under_panic: text:ffffffff89b1d008 len:74 put:14 head:ffff88803123aa00 data:ffff88803123a9f2 tail:0x3c end:0x140 dev:syz_tun kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 UID: 0 PID: 7373 Comm: syz.1.568 Not tainted 6.12.0-rc2-syzkaller-00631-g6d858708d465 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:skb_panic net/core/skbuff.c:206 [inline] RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216 Code: 0d 8d 48 c7 c6 60 a6 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 ba 30 38 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP: 0018:ffffc900045269b0 EFLAGS: 00010282 RAX: 0000000000000088 RBX: dffffc0000000000 RCX: cd66dacdc5d8e800 RDX: 0000000000000000 RSI: 0000000000000200 RDI: 0000000000000000 RBP: ffff88802d39a3d0 R08: ffffffff8174afec R09: 1ffff920008a4ccc R10: dffffc0000000000 R11: fffff520008a4ccd R12: 0000000000000140 R13: ffff88803123aa00 R14: ffff88803123a9f2 R15: 000000000000003c FS: 00007fdbee5ff6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000005d322000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: skb_push+0xe5/0x100 net/core/skbuff.c:2636 eth_header+0x38/0x1f0 net/ethernet/eth.c:83 dev_hard_header include/linux/netdevice.h:3208 [inline] nf_send_reset6+0xce6/0x1270 net/ipv6/netfilter/nf_reject_ipv6.c:358 nft_reject_inet_eval+0x3b9/0x690 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x418/0x6b0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] br_nf_pre_routing_ipv6+0x63e/0x770 net/bridge/br_netfilter_ipv6.c:184 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_bridge_pre net/bridge/br_input.c:277 [inline] br_handle_frame+0x9fd/0x1530 net/bridge/br_input.c:424 __netif_receive_skb_core+0x13e8/0x4570 net/core/dev.c:5562 __netif_receive_skb_one_core net/core/dev.c:5666 [inline] __netif_receive_skb+0x12f/0x650 net/core/dev.c:5781 netif_receive_skb_internal net/core/dev.c:5867 [inline] netif_receive_skb+0x1e8/0x890 net/core/dev.c:5926 tun_rx_batched+0x1b7/0x8f0 drivers/net/tun.c:1550 tun_get_user+0x3056/0x47e0 drivers/net/tun.c:2007 tun_chr_write_iter+0x10d/0x1f0 drivers/net/tun.c:2053 new_sync_write fs/read_write.c:590 [inline] vfs_write+0xa6d/0xc90 fs/read_write.c:683 ksys_write+0x183/0x2b0 fs/read_write.c:736 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:0x7fdbeeb7d1ff Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 c9 8d 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 1c 8e 02 00 48 RSP: 002b:00007fdbee5ff000 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fdbeed36058 RCX: 00007fdbeeb7d1ff RDX: 000000000000008e RSI: 0000000020000040 RDI: 00000000000000c8 RBP: 00007fdbeebf12be R08: 0000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50257", "url": "https://ubuntu.com/security/CVE-2024-50257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: Fix use-after-free in get_info() ip6table_nat module unload has refcnt warning for UAF. call trace is: WARNING: CPU: 1 PID: 379 at kernel/module/main.c:853 module_put+0x6f/0x80 Modules linked in: ip6table_nat(-) CPU: 1 UID: 0 PID: 379 Comm: ip6tables Not tainted 6.12.0-rc4-00047-gc2ee9f594da8-dirty #205 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:module_put+0x6f/0x80 Call Trace: get_info+0x128/0x180 do_ip6t_get_ctl+0x6a/0x430 nf_getsockopt+0x46/0x80 ipv6_getsockopt+0xb9/0x100 rawv6_getsockopt+0x42/0x190 do_sock_getsockopt+0xaa/0x180 __sys_getsockopt+0x70/0xc0 __x64_sys_getsockopt+0x20/0x30 do_syscall_64+0xa2/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Concurrent execution of module unload and get_info() trigered the warning. The root cause is as follows: cpu0\t\t\t\t cpu1 module_exit //mod->state = MODULE_STATE_GOING ip6table_nat_exit xt_unregister_template \tkfree(t) \t//removed from templ_list \t\t\t\t getinfo() \t\t\t\t\t t = xt_find_table_lock \t\t\t\t\t\tlist_for_each_entry(tmpl, &xt_templates[af]...) \t\t\t\t\t\t\tif (strcmp(tmpl->name, name)) \t\t\t\t\t\t\t\tcontinue; //table not found \t\t\t\t\t\t\ttry_module_get \t\t\t\t\t\tlist_for_each_entry(t, &xt_net->tables[af]...) \t\t\t\t\t\t\treturn t; //not get refcnt \t\t\t\t\t module_put(t->me) //uaf unregister_pernet_subsys //remove table from xt_net list While xt_table module was going away and has been removed from xt_templates list, we couldnt get refcnt of xt_table->me. Check module in xt_net->tables list re-traversal to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50258", "url": "https://ubuntu.com/security/CVE-2024-50258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix crash when config small gso_max_size/gso_ipv4_max_size Config a small gso_max_size/gso_ipv4_max_size will lead to an underflow in sk_dst_gso_max_size(), which may trigger a BUG_ON crash, because sk->sk_gso_max_size would be much bigger than device limits. Call Trace: tcp_write_xmit tso_segs = tcp_init_tso_segs(skb, mss_now); tcp_set_skb_tso_segs tcp_skb_pcount_set // skb->len = 524288, mss_now = 8 // u16 tso_segs = 524288/8 = 65535 -> 0 tso_segs = DIV_ROUND_UP(skb->len, mss_now) BUG_ON(!tso_segs) Add check for the minimum value of gso_max_size and gso_ipv4_max_size.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50262", "url": "https://ubuntu.com/security/CVE-2024-50262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix out-of-bounds write in trie_get_next_key() trie_get_next_key() allocates a node stack with size trie->max_prefixlen, while it writes (trie->max_prefixlen + 1) nodes to the stack when it has full paths from the root to leaves. For example, consider a trie with max_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ... 0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with .prefixlen = 8 make 9 nodes be written on the node stack with size 8.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53044", "url": "https://ubuntu.com/security/CVE-2024-53044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_api: fix xa_insert() error path in tcf_block_get_ext() This command: $ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact Error: block dev insert failed: -EBUSY. fails because user space requests the same block index to be set for both ingress and egress. [ side note, I don't think it even failed prior to commit 913b47d3424e (\"net/sched: Introduce tc block netdev tracking infra\"), because this is a command from an old set of notes of mine which used to work, but alas, I did not scientifically bisect this ] The problem is not that it fails, but rather, that the second time around, it fails differently (and irrecoverably): $ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact Error: dsa_core: Flow block cb is busy. [ another note: the extack is added by me for illustration purposes. the context of the problem is that clsact_init() obtains the same &q->ingress_block pointer as &q->egress_block, and since we call tcf_block_get_ext() on both of them, \"dev\" will be added to the block->ports xarray twice, thus failing the operation: once through the ingress block pointer, and once again through the egress block pointer. the problem itself is that when xa_insert() fails, we have emitted a FLOW_BLOCK_BIND command through ndo_setup_tc(), but the offload never sees a corresponding FLOW_BLOCK_UNBIND. ] Even correcting the bad user input, we still cannot recover: $ tc qdisc replace dev swp3 ingress_block 1 egress_block 2 clsact Error: dsa_core: Flow block cb is busy. Basically the only way to recover is to reboot the system, or unbind and rebind the net device driver. To fix the bug, we need to fill the correct error teardown path which was missed during code movement, and call tcf_block_offload_unbind() when xa_insert() fails. [ last note, fundamentally I blame the label naming convention in tcf_block_get_ext() for the bug. The labels should be named after what they do, not after the error path that jumps to them. This way, it is obviously wrong that two labels pointing to the same code mean something is wrong, and checking the code correctness at the goto site is also easier ]", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50259", "url": "https://ubuntu.com/security/CVE-2024-50259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netdevsim: Add trailing zero to terminate the string in nsim_nexthop_bucket_activity_write() This was found by a static analyzer. We should not forget the trailing zero after copy_from_user() if we will further do some string operations, sscanf() in this case. Adding a trailing zero will ensure that the function performs properly.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50304", "url": "https://ubuntu.com/security/CVE-2024-50304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find() The per-netns IP tunnel hash table is protected by the RTNL mutex and ip_tunnel_find() is only called from the control path where the mutex is taken. Add a lockdep expression to hlist_for_each_entry_rcu() in ip_tunnel_find() in order to validate that the mutex is held and to silence the suspicious RCU usage warning [1]. [1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gd95d9a31aceb #139 Not tainted ----------------------------- net/ipv4/ip_tunnel.c:221 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/362: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60 stack backtrace: CPU: 12 UID: 0 PID: 362 Comm: ip Not tainted 6.12.0-rc3-custom-gd95d9a31aceb #139 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 ip_tunnel_find+0x435/0x4d0 ip_tunnel_newlink+0x517/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53042", "url": "https://ubuntu.com/security/CVE-2024-53042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_init_flow() There are code paths from which the function is called without holding the RCU read lock, resulting in a suspicious RCU usage warning [1]. Fix by using l3mdev_master_upper_ifindex_by_index() which will acquire the RCU read lock before calling l3mdev_master_upper_ifindex_by_index_rcu(). [1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gac8f72681cf2 #141 Not tainted ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/361: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60 stack backtrace: CPU: 3 UID: 0 PID: 361 Comm: ip Not tainted 6.12.0-rc3-custom-gac8f72681cf2 #141 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 dev_get_by_index_rcu+0x1d3/0x210 l3mdev_master_upper_ifindex_by_index_rcu+0x2b/0xf0 ip_tunnel_bind_dev+0x72f/0xa00 ip_tunnel_newlink+0x368/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53048", "url": "https://ubuntu.com/security/CVE-2024-53048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix crash on probe for DPLL enabled E810 LOM The E810 Lan On Motherboard (LOM) design is vendor specific. Intel provides the reference design, but it is up to vendor on the final product design. For some cases, like Linux DPLL support, the static values defined in the driver does not reflect the actual LOM design. Current implementation of dpll pins is causing the crash on probe of the ice driver for such DPLL enabled E810 LOM designs: WARNING: (...) at drivers/dpll/dpll_core.c:495 dpll_pin_get+0x2c4/0x330 ... Call Trace: ? __warn+0x83/0x130 ? dpll_pin_get+0x2c4/0x330 ? report_bug+0x1b7/0x1d0 ? handle_bug+0x42/0x70 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? dpll_pin_get+0x117/0x330 ? dpll_pin_get+0x2c4/0x330 ? dpll_pin_get+0x117/0x330 ice_dpll_get_pins.isra.0+0x52/0xe0 [ice] ... The number of dpll pins enabled by LOM vendor is greater than expected and defined in the driver for Intel designed NICs, which causes the crash. Prevent the crash and allow generic pin initialization within Linux DPLL subsystem for DPLL enabled E810 LOM designs. Newly designed solution for described issue will be based on \"per HW design\" pin initialization. It requires pin information dynamically acquired from the firmware and is already in progress, planned for next-tree only.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53058", "url": "https://ubuntu.com/security/CVE-2024-53058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data In case the non-paged data of a SKB carries protocol header and protocol payload to be transmitted on a certain platform that the DMA AXI address width is configured to 40-bit/48-bit, or the size of the non-paged data is bigger than TSO_MAX_BUFF_SIZE on a certain platform that the DMA AXI address width is configured to 32-bit, then this SKB requires at least two DMA transmit descriptors to serve it. For example, three descriptors are allocated to split one DMA buffer mapped from one piece of non-paged data: dma_desc[N + 0], dma_desc[N + 1], dma_desc[N + 2]. Then three elements of tx_q->tx_skbuff_dma[] will be allocated to hold extra information to be reused in stmmac_tx_clean(): tx_q->tx_skbuff_dma[N + 0], tx_q->tx_skbuff_dma[N + 1], tx_q->tx_skbuff_dma[N + 2]. Now we focus on tx_q->tx_skbuff_dma[entry].buf, which is the DMA buffer address returned by DMA mapping call. stmmac_tx_clean() will try to unmap the DMA buffer _ONLY_IF_ tx_q->tx_skbuff_dma[entry].buf is a valid buffer address. The expected behavior that saves DMA buffer address of this non-paged data to tx_q->tx_skbuff_dma[entry].buf is: tx_q->tx_skbuff_dma[N + 0].buf = NULL; tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = dma_map_single(); Unfortunately, the current code misbehaves like this: tx_q->tx_skbuff_dma[N + 0].buf = dma_map_single(); tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = NULL; On the stmmac_tx_clean() side, when dma_desc[N + 0] is closed by the DMA engine, tx_q->tx_skbuff_dma[N + 0].buf is a valid buffer address obviously, then the DMA buffer will be unmapped immediately. There may be a rare case that the DMA engine does not finish the pending dma_desc[N + 1], dma_desc[N + 2] yet. Now things will go horribly wrong, DMA is going to access a unmapped/unreferenced memory region, corrupted data will be transmited or iommu fault will be triggered :( In contrast, the for-loop that maps SKB fragments behaves perfectly as expected, and that is how the driver should do for both non-paged data and paged frags actually. This patch corrects DMA map/unmap sequences by fixing the array index for tx_q->tx_skbuff_dma[entry].buf when assigning DMA buffer address. Tested and verified on DWXGMAC CORE 3.20a", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50260", "url": "https://ubuntu.com/security/CVE-2024-50260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sock_map: fix a NULL pointer dereference in sock_map_link_update_prog() The following race condition could trigger a NULL pointer dereference: sock_map_link_detach():\t\tsock_map_link_update_prog(): mutex_lock(&sockmap_mutex); ... sockmap_link->map = NULL; mutex_unlock(&sockmap_mutex); \t\t\t\t mutex_lock(&sockmap_mutex); \t\t\t\t ... \t\t\t\t sock_map_prog_link_lookup(sockmap_link->map); \t\t\t\t mutex_unlock(&sockmap_mutex); Fix it by adding a NULL pointer check. In this specific case, it makes no sense to update a link which is being released.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53045", "url": "https://ubuntu.com/security/CVE-2024-53045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: dapm: fix bounds checker error in dapm_widget_list_create The widgets array in the snd_soc_dapm_widget_list has a __counted_by attribute attached to it, which points to the num_widgets variable. This attribute is used in bounds checking, and if it is not set before the array is filled, then the bounds sanitizer will issue a warning or a kernel panic if CONFIG_UBSAN_TRAP is set. This patch sets the size of the widgets list calculated with list_for_each as the initial value for num_widgets as it is used for allocating memory for the array. It is updated with the actual number of added elements after the array is filled.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50261", "url": "https://ubuntu.com/security/CVE-2024-50261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macsec: Fix use-after-free while sending the offloading packet KASAN reports the following UAF. The metadata_dst, which is used to store the SCI value for macsec offload, is already freed by metadata_dst_free() in macsec_free_netdev(), while driver still use it for sending the packet. To fix this issue, dst_release() is used instead to release metadata_dst. So it is not freed instantly in macsec_free_netdev() if still referenced by skb. BUG: KASAN: slab-use-after-free in mlx5e_xmit+0x1e8f/0x4190 [mlx5_core] Read of size 2 at addr ffff88813e42e038 by task kworker/7:2/714 [...] Workqueue: mld mld_ifc_work Call Trace: dump_stack_lvl+0x51/0x60 print_report+0xc1/0x600 kasan_report+0xab/0xe0 mlx5e_xmit+0x1e8f/0x4190 [mlx5_core] dev_hard_start_xmit+0x120/0x530 sch_direct_xmit+0x149/0x11e0 __qdisc_run+0x3ad/0x1730 __dev_queue_xmit+0x1196/0x2ed0 vlan_dev_hard_start_xmit+0x32e/0x510 [8021q] dev_hard_start_xmit+0x120/0x530 __dev_queue_xmit+0x14a7/0x2ed0 macsec_start_xmit+0x13e9/0x2340 dev_hard_start_xmit+0x120/0x530 __dev_queue_xmit+0x14a7/0x2ed0 ip6_finish_output2+0x923/0x1a70 ip6_finish_output+0x2d7/0x970 ip6_output+0x1ce/0x3a0 NF_HOOK.constprop.0+0x15f/0x190 mld_sendpack+0x59a/0xbd0 mld_ifc_work+0x48a/0xa80 process_one_work+0x5aa/0xe50 worker_thread+0x79c/0x1290 kthread+0x28f/0x350 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x11/0x20 Allocated by task 3922: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 __kasan_kmalloc+0x77/0x90 __kmalloc_noprof+0x188/0x400 metadata_dst_alloc+0x1f/0x4e0 macsec_newlink+0x914/0x1410 __rtnl_newlink+0xe08/0x15b0 rtnl_newlink+0x5f/0x90 rtnetlink_rcv_msg+0x667/0xa80 netlink_rcv_skb+0x12c/0x360 netlink_unicast+0x551/0x770 netlink_sendmsg+0x72d/0xbd0 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x52e/0x6a0 ___sys_sendmsg+0xeb/0x170 __sys_sendmsg+0xb5/0x140 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Freed by task 4011: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x50 poison_slab_object+0x10c/0x190 __kasan_slab_free+0x11/0x30 kfree+0xe0/0x290 macsec_free_netdev+0x3f/0x140 netdev_run_todo+0x450/0xc70 rtnetlink_rcv_msg+0x66f/0xa80 netlink_rcv_skb+0x12c/0x360 netlink_unicast+0x551/0x770 netlink_sendmsg+0x72d/0xbd0 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x52e/0x6a0 ___sys_sendmsg+0xeb/0x170 __sys_sendmsg+0xb5/0x140 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53059", "url": "https://ubuntu.com/security/CVE-2024-53059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd() 1. The size of the response packet is not validated. 2. The response buffer is not freed. Resolve these issues by switching to iwl_mvm_send_cmd_status(), which handles both size validation and frees the buffer.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53074", "url": "https://ubuntu.com/security/CVE-2024-53074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: don't leak a link on AP removal Release the link mapping resource in AP removal. This impacted devices that do not support the MLD API (9260 and down). On those devices, we couldn't start the AP again after the AP has been already started and stopped.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53049", "url": "https://ubuntu.com/security/CVE-2024-53049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slub/kunit: fix a WARNING due to unwrapped __kmalloc_cache_noprof 'modprobe slub_kunit' will have a warning as shown below. The root cause is that __kmalloc_cache_noprof was directly used, which resulted in no alloc_tag being allocated. This caused current->alloc_tag to be null, leading to a warning in alloc_tag_add_check. Let's add an alloc_hook layer to __kmalloc_cache_noprof specifically within lib/slub_kunit.c, which is the only user of this internal slub function outside kmalloc implementation itself. [58162.947016] WARNING: CPU: 2 PID: 6210 at ./include/linux/alloc_tag.h:125 alloc_tagging_slab_alloc_hook+0x268/0x27c [58162.957721] Call trace: [58162.957919] alloc_tagging_slab_alloc_hook+0x268/0x27c [58162.958286] __kmalloc_cache_noprof+0x14c/0x344 [58162.958615] test_kmalloc_redzone_access+0x50/0x10c [slub_kunit] [58162.959045] kunit_try_run_case+0x74/0x184 [kunit] [58162.959401] kunit_generic_run_threadfn_adapter+0x2c/0x4c [kunit] [58162.959841] kthread+0x10c/0x118 [58162.960093] ret_from_fork+0x10/0x20 [58162.960363] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50192", "url": "https://ubuntu.com/security/CVE-2024-50192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v4: Don't allow a VMOVP on a dying VPE Kunkun Jiang reported that there is a small window of opportunity for userspace to force a change of affinity for a VPE while the VPE has already been unmapped, but the corresponding doorbell interrupt still visible in /proc/irq/. Plug the race by checking the value of vmapp_count, which tracks whether the VPE is mapped ot not, and returning an error in this case. This involves making vmapp_count common to both GICv4.1 and its v4.0 ancestor.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50069", "url": "https://ubuntu.com/security/CVE-2024-50069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: apple: check devm_kasprintf() returned value devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked. Fix this lack and check the returned value. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50070", "url": "https://ubuntu.com/security/CVE-2024-50070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: stm32: check devm_kasprintf() returned value devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked. Fix this lack and check the returned value. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50196", "url": "https://ubuntu.com/security/CVE-2024-50196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: ocelot: fix system hang on level based interrupts The current implementation only calls chained_irq_enter() and chained_irq_exit() if it detects pending interrupts. ``` for (i = 0; i < info->stride; i++) { \turegmap_read(info->map, id_reg + 4 * i, ®); \tif (!reg) \t\tcontinue; \tchained_irq_enter(parent_chip, desc); ``` However, in case of GPIO pin configured in level mode and the parent controller configured in edge mode, GPIO interrupt might be lowered by the hardware. In the result, if the interrupt is short enough, the parent interrupt is still pending while the GPIO interrupt is cleared; chained_irq_enter() never gets called and the system hangs trying to service the parent interrupt. Moving chained_irq_enter() and chained_irq_exit() outside the for loop ensures that they are called even when GPIO interrupt is lowered by the hardware. The similar code with chained_irq_enter() / chained_irq_exit() functions wrapping interrupt checking loop may be found in many other drivers: ``` grep -r -A 10 chained_irq_enter drivers/pinctrl ```", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50197", "url": "https://ubuntu.com/security/CVE-2024-50197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: intel: platform: fix error path in device_for_each_child_node() The device_for_each_child_node() loop requires calls to fwnode_handle_put() upon early returns to decrement the refcount of the child node and avoid leaking memory if that error path is triggered. There is one early returns within that loop in intel_platform_pinctrl_prepare_community(), but fwnode_handle_put() is missing. Instead of adding the missing call, the scoped version of the loop can be used to simplify the code and avoid mistakes in the future if new early returns are added, as the child node is only used for parsing, and it is never assigned.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50071", "url": "https://ubuntu.com/security/CVE-2024-50071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: nuvoton: fix a double free in ma35_pinctrl_dt_node_to_map_func() 'new_map' is allocated using devm_* which takes care of freeing the allocated data on device removal, call to \t.dt_free_map = pinconf_generic_dt_free_map double frees the map as pinconf_generic_dt_free_map() calls pinctrl_utils_free_map(). Fix this by using kcalloc() instead of auto-managed devm_kcalloc().", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50072", "url": "https://ubuntu.com/security/CVE-2024-50072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/bugs: Use code segment selector for VERW operand Robert Gill reported below #GP in 32-bit mode when dosemu software was executing vm86() system call: general protection fault: 0000 [#1] PREEMPT SMP CPU: 4 PID: 4610 Comm: dosemu.bin Not tainted 6.6.21-gentoo-x86 #1 Hardware name: Dell Inc. PowerEdge 1950/0H723K, BIOS 2.7.0 10/30/2010 EIP: restore_all_switch_stack+0xbe/0xcf EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000 ESI: 00000000 EDI: 00000000 EBP: 00000000 ESP: ff8affdc DS: 0000 ES: 0000 FS: 0000 GS: 0033 SS: 0068 EFLAGS: 00010046 CR0: 80050033 CR2: 00c2101c CR3: 04b6d000 CR4: 000406d0 Call Trace: show_regs+0x70/0x78 die_addr+0x29/0x70 exc_general_protection+0x13c/0x348 exc_bounds+0x98/0x98 handle_exception+0x14d/0x14d exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf This only happens in 32-bit mode when VERW based mitigations like MDS/RFDS are enabled. This is because segment registers with an arbitrary user value can result in #GP when executing VERW. Intel SDM vol. 2C documents the following behavior for VERW instruction: #GP(0) - If a memory operand effective address is outside the CS, DS, ES, \t FS, or GS segment limit. CLEAR_CPU_BUFFERS macro executes VERW instruction before returning to user space. Use %cs selector to reference VERW operand. This ensures VERW will not #GP for an arbitrary user %ds. [ mingo: Fixed the SOB chain. ]", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50073", "url": "https://ubuntu.com/security/CVE-2024-50073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: Fix use-after-free in gsm_cleanup_mux BUG: KASAN: slab-use-after-free in gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] Read of size 8 at addr ffff88815fe99c00 by task poc/3379 CPU: 0 UID: 0 PID: 3379 Comm: poc Not tainted 6.11.0+ #56 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] __pfx_gsm_cleanup_mux+0x10/0x10 drivers/tty/n_gsm.c:3124 [n_gsm] __pfx_sched_clock_cpu+0x10/0x10 kernel/sched/clock.c:389 update_load_avg+0x1c1/0x27b0 kernel/sched/fair.c:4500 __pfx_min_vruntime_cb_rotate+0x10/0x10 kernel/sched/fair.c:846 __rb_insert_augmented+0x492/0xbf0 lib/rbtree.c:161 gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] _raw_spin_lock_irqsave+0x92/0xf0 arch/x86/include/asm/atomic.h:107 __pfx_gsmld_ioctl+0x10/0x10 drivers/tty/n_gsm.c:3822 [n_gsm] ktime_get+0x5e/0x140 kernel/time/timekeeping.c:195 ldsem_down_read+0x94/0x4e0 arch/x86/include/asm/atomic64_64.h:79 __pfx_ldsem_down_read+0x10/0x10 drivers/tty/tty_ldsem.c:338 __pfx_do_vfs_ioctl+0x10/0x10 fs/ioctl.c:805 tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 Allocated by task 65: gsm_data_alloc.constprop.0+0x27/0x190 drivers/tty/n_gsm.c:926 [n_gsm] gsm_send+0x2c/0x580 drivers/tty/n_gsm.c:819 [n_gsm] gsm1_receive+0x547/0xad0 drivers/tty/n_gsm.c:3038 [n_gsm] gsmld_receive_buf+0x176/0x280 drivers/tty/n_gsm.c:3609 [n_gsm] tty_ldisc_receive_buf+0x101/0x1e0 drivers/tty/tty_buffer.c:391 tty_port_default_receive_buf+0x61/0xa0 drivers/tty/tty_port.c:39 flush_to_ldisc+0x1b0/0x750 drivers/tty/tty_buffer.c:445 process_scheduled_works+0x2b0/0x10d0 kernel/workqueue.c:3229 worker_thread+0x3dc/0x950 kernel/workqueue.c:3391 kthread+0x2a3/0x370 kernel/kthread.c:389 ret_from_fork+0x2d/0x70 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:257 Freed by task 3367: kfree+0x126/0x420 mm/slub.c:4580 gsm_cleanup_mux+0x36c/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 [Analysis] gsm_msg on the tx_ctrl_list or tx_data_list of gsm_mux can be freed by multi threads through ioctl,which leads to the occurrence of uaf. Protect it by gsm tx lock.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50193", "url": "https://ubuntu.com/security/CVE-2024-50193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/entry_32: Clear CPU buffers after register restore in NMI return CPU buffers are currently cleared after call to exc_nmi, but before register state is restored. This may be okay for MDS mitigation but not for RDFS. Because RDFS mitigation requires CPU buffers to be cleared when registers don't have any sensitive data. Move CLEAR_CPU_BUFFERS after RESTORE_ALL_NMI.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50074", "url": "https://ubuntu.com/security/CVE-2024-50074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: parport: Proper fix for array out-of-bounds access The recent fix for array out-of-bounds accesses replaced sprintf() calls blindly with snprintf(). However, since snprintf() returns the would-be-printed size, not the actually output size, the length calculation can still go over the given limit. Use scnprintf() instead of snprintf(), which returns the actually output letters, for addressing the potential out-of-bounds access properly.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50100", "url": "https://ubuntu.com/security/CVE-2024-50100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: gadget: dummy-hcd: Fix \"task hung\" problem The syzbot fuzzer has been encountering \"task hung\" problems ever since the dummy-hcd driver was changed to use hrtimers instead of regular timers. It turns out that the problems are caused by a subtle difference between the timer_pending() and hrtimer_active() APIs. The changeover blindly replaced the first by the second. However, timer_pending() returns True when the timer is queued but not when its callback is running, whereas hrtimer_active() returns True when the hrtimer is queued _or_ its callback is running. This difference occasionally caused dummy_urb_enqueue() to think that the callback routine had not yet started when in fact it was almost finished. As a result the hrtimer was not restarted, which made it impossible for the driver to dequeue later the URB that was just enqueued. This caused usb_kill_urb() to hang, and things got worse from there. Since hrtimers have no API for telling when they are queued and the callback isn't running, the driver must keep track of this for itself. That's what this patch does, adding a new \"timer_pending\" flag and setting or clearing it at the appropriate times.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50075", "url": "https://ubuntu.com/security/CVE-2024-50075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xhci: tegra: fix checked USB2 port number If USB virtualizatoin is enabled, USB2 ports are shared between all Virtual Functions. The USB2 port number owned by an USB2 root hub in a Virtual Function may be less than total USB2 phy number supported by the Tegra XUSB controller. Using total USB2 phy number as port number to check all PORTSC values would cause invalid memory access. [ 116.923438] Unable to handle kernel paging request at virtual address 006c622f7665642f ... [ 117.213640] Call trace: [ 117.216783] tegra_xusb_enter_elpg+0x23c/0x658 [ 117.222021] tegra_xusb_runtime_suspend+0x40/0x68 [ 117.227260] pm_generic_runtime_suspend+0x30/0x50 [ 117.232847] __rpm_callback+0x84/0x3c0 [ 117.237038] rpm_suspend+0x2dc/0x740 [ 117.241229] pm_runtime_work+0xa0/0xb8 [ 117.245769] process_scheduled_works+0x24c/0x478 [ 117.251007] worker_thread+0x23c/0x328 [ 117.255547] kthread+0x104/0x1b0 [ 117.259389] ret_from_fork+0x10/0x20 [ 117.263582] Code: 54000222 f9461ae8 f8747908 b4ffff48 (f9400100)", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50076", "url": "https://ubuntu.com/security/CVE-2024-50076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vt: prevent kernel-infoleak in con_font_get() font.data may not initialize all memory spaces depending on the implementation of vc->vc_sw->con_font_get. This may cause info-leak, so to prevent this, it is safest to modify it to initialize the allocated memory space to 0, and it generally does not affect the overall performance of the system.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50077", "url": "https://ubuntu.com/security/CVE-2024-50077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix multiple init when debugfs is disabled If bt_debugfs is not created successfully, which happens if either CONFIG_DEBUG_FS or CONFIG_DEBUG_FS_ALLOW_ALL is unset, then iso_init() returns early and does not set iso_inited to true. This means that a subsequent call to iso_init() will result in duplicate calls to proto_register(), bt_sock_register(), etc. With CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, the duplicate call to proto_register() triggers this BUG(): list_add double add: new=ffffffffc0b280d0, prev=ffffffffbab56250, next=ffffffffc0b280d0. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:35! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 2 PID: 887 Comm: bluetoothd Not tainted 6.10.11-1-ao-desktop #1 RIP: 0010:__list_add_valid_or_report+0x9a/0xa0 ... __list_add_valid_or_report+0x9a/0xa0 proto_register+0x2b5/0x340 iso_init+0x23/0x150 [bluetooth] set_iso_socket_func+0x68/0x1b0 [bluetooth] kmem_cache_free+0x308/0x330 hci_sock_sendmsg+0x990/0x9e0 [bluetooth] __sock_sendmsg+0x7b/0x80 sock_write_iter+0x9a/0x110 do_iter_readv_writev+0x11d/0x220 vfs_writev+0x180/0x3e0 do_writev+0xca/0x100 ... This change removes the early return. The check for iso_debugfs being NULL was unnecessary, it is always NULL when iso_inited is false.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50078", "url": "https://ubuntu.com/security/CVE-2024-50078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Call iso_exit() on module unload If iso_init() has been called, iso_exit() must be called on module unload. Without that, the struct proto that iso_init() registered with proto_register() becomes invalid, which could cause unpredictable problems later. In my case, with CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, loading the module again usually triggers this BUG(): list_add corruption. next->prev should be prev (ffffffffb5355fd0), but was 0000000000000068. (next=ffffffffc0a010d0). ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:29! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 4159 Comm: modprobe Not tainted 6.10.11-4+bt2-ao-desktop #1 RIP: 0010:__list_add_valid_or_report+0x61/0xa0 ... __list_add_valid_or_report+0x61/0xa0 proto_register+0x299/0x320 hci_sock_init+0x16/0xc0 [bluetooth] bt_init+0x68/0xd0 [bluetooth] __pfx_bt_init+0x10/0x10 [bluetooth] do_one_initcall+0x80/0x2f0 do_init_module+0x8b/0x230 __do_sys_init_module+0x15f/0x190 do_syscall_64+0x68/0x110 ...", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50198", "url": "https://ubuntu.com/security/CVE-2024-50198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: veml6030: fix IIO device retrieval from embedded device The dev pointer that is received as an argument in the in_illuminance_period_available_show function references the device embedded in the IIO device, not in the i2c client. dev_to_iio_dev() must be used to accessthe right data. The current implementation leads to a segmentation fault on every attempt to read the attribute because indio_dev gets a NULL assignment. This bug has been present since the first appearance of the driver, apparently since the last version (V6) before getting applied. A constant attribute was used until then, and the last modifications might have not been tested again.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50201", "url": "https://ubuntu.com/security/CVE-2024-50201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: Fix encoder->possible_clones Include the encoder itself in its possible_clones bitmask. In the past nothing validated that drivers were populating possible_clones correctly, but that changed in commit 74d2aacbe840 (\"drm: Validate encoder->possible_clones\"). Looks like radeon never got the memo and is still not following the rules 100% correctly. This results in some warnings during driver initialization: Bogus possible_clones: [ENCODER:46:TV-46] possible_clones=0x4 (full encoder mask=0x7) WARNING: CPU: 0 PID: 170 at drivers/gpu/drm/drm_mode_config.c:615 drm_mode_config_validate+0x113/0x39c ... (cherry picked from commit 3b6e7d40649c0d75572039aff9d0911864c689db)", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50098", "url": "https://ubuntu.com/security/CVE-2024-50098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Set SDEV_OFFLINE when UFS is shut down There is a history of deadlock if reboot is performed at the beginning of booting. SDEV_QUIESCE was set for all LU's scsi_devices by UFS shutdown, and at that time the audio driver was waiting on blk_mq_submit_bio() holding a mutex_lock while reading the fw binary. After that, a deadlock issue occurred while audio driver shutdown was waiting for mutex_unlock of blk_mq_submit_bio(). To solve this, set SDEV_OFFLINE for all LUs except WLUN, so that any I/O that comes down after a UFS shutdown will return an error. [ 31.907781]I[0: swapper/0: 0] 1 130705007 1651079834 11289729804 0 D( 2) 3 ffffff882e208000 * init [device_shutdown] [ 31.907793]I[0: swapper/0: 0] Mutex: 0xffffff8849a2b8b0: owner[0xffffff882e28cb00 kworker/6:0 :49] [ 31.907806]I[0: swapper/0: 0] Call trace: [ 31.907810]I[0: swapper/0: 0] __switch_to+0x174/0x338 [ 31.907819]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc [ 31.907826]I[0: swapper/0: 0] schedule+0x7c/0xe8 [ 31.907834]I[0: swapper/0: 0] schedule_preempt_disabled+0x24/0x40 [ 31.907842]I[0: swapper/0: 0] __mutex_lock+0x408/0xdac [ 31.907849]I[0: swapper/0: 0] __mutex_lock_slowpath+0x14/0x24 [ 31.907858]I[0: swapper/0: 0] mutex_lock+0x40/0xec [ 31.907866]I[0: swapper/0: 0] device_shutdown+0x108/0x280 [ 31.907875]I[0: swapper/0: 0] kernel_restart+0x4c/0x11c [ 31.907883]I[0: swapper/0: 0] __arm64_sys_reboot+0x15c/0x280 [ 31.907890]I[0: swapper/0: 0] invoke_syscall+0x70/0x158 [ 31.907899]I[0: swapper/0: 0] el0_svc_common+0xb4/0xf4 [ 31.907909]I[0: swapper/0: 0] do_el0_svc+0x2c/0xb0 [ 31.907918]I[0: swapper/0: 0] el0_svc+0x34/0xe0 [ 31.907928]I[0: swapper/0: 0] el0t_64_sync_handler+0x68/0xb4 [ 31.907937]I[0: swapper/0: 0] el0t_64_sync+0x1a0/0x1a4 [ 31.908774]I[0: swapper/0: 0] 49 0 11960702 11236868007 0 D( 2) 6 ffffff882e28cb00 * kworker/6:0 [__bio_queue_enter] [ 31.908783]I[0: swapper/0: 0] Call trace: [ 31.908788]I[0: swapper/0: 0] __switch_to+0x174/0x338 [ 31.908796]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc [ 31.908803]I[0: swapper/0: 0] schedule+0x7c/0xe8 [ 31.908811]I[0: swapper/0: 0] __bio_queue_enter+0xb8/0x178 [ 31.908818]I[0: swapper/0: 0] blk_mq_submit_bio+0x194/0x67c [ 31.908827]I[0: swapper/0: 0] __submit_bio+0xb8/0x19c", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50079", "url": "https://ubuntu.com/security/CVE-2024-50079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/sqpoll: ensure task state is TASK_RUNNING when running task_work When the sqpoll is exiting and cancels pending work items, it may need to run task_work. If this happens from within io_uring_cancel_generic(), then it may be under waiting for the io_uring_task waitqueue. This results in the below splat from the scheduler, as the ring mutex may be attempted grabbed while in a TASK_INTERRUPTIBLE state. Ensure that the task state is set appropriately for that, just like what is done for the other cases in io_run_task_work(). do not call blocking ops when !TASK_RUNNING; state=1 set at [<0000000029387fd2>] prepare_to_wait+0x88/0x2fc WARNING: CPU: 6 PID: 59939 at kernel/sched/core.c:8561 __might_sleep+0xf4/0x140 Modules linked in: CPU: 6 UID: 0 PID: 59939 Comm: iou-sqp-59938 Not tainted 6.12.0-rc3-00113-g8d020023b155 #7456 Hardware name: linux,dummy-virt (DT) pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : __might_sleep+0xf4/0x140 lr : __might_sleep+0xf4/0x140 sp : ffff80008c5e7830 x29: ffff80008c5e7830 x28: ffff0000d93088c0 x27: ffff60001c2d7230 x26: dfff800000000000 x25: ffff0000e16b9180 x24: ffff80008c5e7a50 x23: 1ffff000118bcf4a x22: ffff0000e16b9180 x21: ffff0000e16b9180 x20: 000000000000011b x19: ffff80008310fac0 x18: 1ffff000118bcd90 x17: 30303c5b20746120 x16: 74657320313d6574 x15: 0720072007200720 x14: 0720072007200720 x13: 0720072007200720 x12: ffff600036c64f0b x11: 1fffe00036c64f0a x10: ffff600036c64f0a x9 : dfff800000000000 x8 : 00009fffc939b0f6 x7 : ffff0001b6327853 x6 : 0000000000000001 x5 : ffff0001b6327850 x4 : ffff600036c64f0b x3 : ffff8000803c35bc x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000e16b9180 Call trace: __might_sleep+0xf4/0x140 mutex_lock+0x84/0x124 io_handle_tw_list+0xf4/0x260 tctx_task_work_run+0x94/0x340 io_run_task_work+0x1ec/0x3c0 io_uring_cancel_generic+0x364/0x524 io_sq_thread+0x820/0x124c ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50080", "url": "https://ubuntu.com/security/CVE-2024-50080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: don't allow user copy for unprivileged device UBLK_F_USER_COPY requires userspace to call write() on ublk char device for filling request buffer, and unprivileged device can't be trusted. So don't allow user copy for unprivileged device.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50081", "url": "https://ubuntu.com/security/CVE-2024-50081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-mq: setup queue ->tag_set before initializing hctx Commit 7b815817aa58 (\"blk-mq: add helper for checking if one CPU is mapped to specified hctx\") needs to check queue mapping via tag set in hctx's cpuhp handler. However, q->tag_set may not be setup yet when the cpuhp handler is enabled, then kernel oops is triggered. Fix the issue by setup queue tag_set before initializing hctx.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50082", "url": "https://ubuntu.com/security/CVE-2024-50082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race We're seeing crashes from rq_qos_wake_function that look like this: BUG: unable to handle page fault for address: ffffafe180a40084 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 100000067 P4D 100000067 PUD 10027c067 PMD 10115d067 PTE 0 Oops: Oops: 0002 [#1] PREEMPT SMP PTI CPU: 17 UID: 0 PID: 0 Comm: swapper/17 Not tainted 6.12.0-rc3-00013-geca631b8fe80 #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:_raw_spin_lock_irqsave+0x1d/0x40 Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 9c 41 5c fa 65 ff 05 62 97 30 4c 31 c0 ba 01 00 00 00 0f b1 17 75 0a 4c 89 e0 41 5c c3 cc cc cc cc 89 c6 e8 2c 0b 00 RSP: 0018:ffffafe180580ca0 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffffafe180a3f7a8 RCX: 0000000000000011 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffffafe180a40084 RBP: 0000000000000000 R08: 00000000001e7240 R09: 0000000000000011 R10: 0000000000000028 R11: 0000000000000888 R12: 0000000000000002 R13: ffffafe180a40084 R14: 0000000000000000 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff9aaf1f280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffafe180a40084 CR3: 000000010e428002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: try_to_wake_up+0x5a/0x6a0 rq_qos_wake_function+0x71/0x80 __wake_up_common+0x75/0xa0 __wake_up+0x36/0x60 scale_up.part.0+0x50/0x110 wb_timer_fn+0x227/0x450 ... So rq_qos_wake_function() calls wake_up_process(data->task), which calls try_to_wake_up(), which faults in raw_spin_lock_irqsave(&p->pi_lock). p comes from data->task, and data comes from the waitqueue entry, which is stored on the waiter's stack in rq_qos_wait(). Analyzing the core dump with drgn, I found that the waiter had already woken up and moved on to a completely unrelated code path, clobbering what was previously data->task. Meanwhile, the waker was passing the clobbered garbage in data->task to wake_up_process(), leading to the crash. What's happening is that in between rq_qos_wake_function() deleting the waitqueue entry and calling wake_up_process(), rq_qos_wait() is finding that it already got a token and returning. The race looks like this: rq_qos_wait() rq_qos_wake_function() ============================================================== prepare_to_wait_exclusive() data->got_token = true; list_del_init(&curr->entry); if (data.got_token) break; finish_wait(&rqw->wait, &data.wq); ^- returns immediately because list_empty_careful(&wq_entry->entry) is true ... return, go do something else ... wake_up_process(data->task) (NO LONGER VALID!)-^ Normally, finish_wait() is supposed to synchronize against the waker. But, as noted above, it is returning immediately because the waitqueue entry has already been removed from the waitqueue. The bug is that rq_qos_wake_function() is accessing the waitqueue entry AFTER deleting it. Note that autoremove_wake_function() wakes the waiter and THEN deletes the waitqueue entry, which is the proper order. Fix it by swapping the order. We also need to use list_del_init_careful() to match the list_empty_careful() in finish_wait().", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50101", "url": "https://ubuntu.com/security/CVE-2024-50101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI devices Previously, the domain_context_clear() function incorrectly called pci_for_each_dma_alias() to set up context entries for non-PCI devices. This could lead to kernel hangs or other unexpected behavior. Add a check to only call pci_for_each_dma_alias() for PCI devices. For non-PCI devices, domain_context_clear_one() is called directly.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50083", "url": "https://ubuntu.com/security/CVE-2024-50083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix mptcp DSS corruption due to large pmtu xmit Syzkaller was able to trigger a DSS corruption: TCP: request_sock_subflow_v4: Possible SYN flooding on port [::]:20002. Sending cookies. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 5227 at net/mptcp/protocol.c:695 __mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695 Modules linked in: CPU: 0 UID: 0 PID: 5227 Comm: syz-executor350 Not tainted 6.11.0-syzkaller-08829-gaf9c191ac2a0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:__mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695 Code: 0f b6 dc 31 ff 89 de e8 b5 dd ea f5 89 d8 48 81 c4 50 01 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 98 da ea f5 90 <0f> 0b 90 e9 47 ff ff ff e8 8a da ea f5 90 0f 0b 90 e9 99 e0 ff ff RSP: 0018:ffffc90000006db8 EFLAGS: 00010246 RAX: ffffffff8ba9df18 RBX: 00000000000055f0 RCX: ffff888030023c00 RDX: 0000000000000100 RSI: 00000000000081e5 RDI: 00000000000055f0 RBP: 1ffff110062bf1ae R08: ffffffff8ba9cf12 R09: 1ffff110062bf1b8 R10: dffffc0000000000 R11: ffffed10062bf1b9 R12: 0000000000000000 R13: dffffc0000000000 R14: 00000000700cec61 R15: 00000000000081e5 FS: 000055556679c380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020287000 CR3: 0000000077892000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: move_skbs_to_msk net/mptcp/protocol.c:811 [inline] mptcp_data_ready+0x29c/0xa90 net/mptcp/protocol.c:854 subflow_data_ready+0x34a/0x920 net/mptcp/subflow.c:1490 tcp_data_queue+0x20fd/0x76c0 net/ipv4/tcp_input.c:5283 tcp_rcv_established+0xfba/0x2020 net/ipv4/tcp_input.c:6237 tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915 tcp_v4_rcv+0x2dc0/0x37f0 net/ipv4/tcp_ipv4.c:2350 ip_protocol_deliver_rcu+0x22e/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x341/0x5f0 net/ipv4/ip_input.c:233 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314 __netif_receive_skb_one_core net/core/dev.c:5662 [inline] __netif_receive_skb+0x2bf/0x650 net/core/dev.c:5775 process_backlog+0x662/0x15b0 net/core/dev.c:6107 __napi_poll+0xcb/0x490 net/core/dev.c:6771 napi_poll net/core/dev.c:6840 [inline] net_rx_action+0x89b/0x1240 net/core/dev.c:6962 handle_softirqs+0x2c5/0x980 kernel/softirq.c:554 do_softirq+0x11b/0x1e0 kernel/softirq.c:455 __local_bh_enable_ip+0x1bb/0x200 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0x1764/0x3e80 net/core/dev.c:4451 dev_queue_xmit include/linux/netdevice.h:3094 [inline] neigh_hh_output include/net/neighbour.h:526 [inline] neigh_output include/net/neighbour.h:540 [inline] ip_finish_output2+0xd41/0x1390 net/ipv4/ip_output.c:236 ip_local_out net/ipv4/ip_output.c:130 [inline] __ip_queue_xmit+0x118c/0x1b80 net/ipv4/ip_output.c:536 __tcp_transmit_skb+0x2544/0x3b30 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_mtu_probe net/ipv4/tcp_output.c:2547 [inline] tcp_write_xmit+0x641d/0x6bf0 net/ipv4/tcp_output.c:2752 __tcp_push_pending_frames+0x9b/0x360 net/ipv4/tcp_output.c:3015 tcp_push_pending_frames include/net/tcp.h:2107 [inline] tcp_data_snd_check net/ipv4/tcp_input.c:5714 [inline] tcp_rcv_established+0x1026/0x2020 net/ipv4/tcp_input.c:6239 tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915 sk_backlog_rcv include/net/sock.h:1113 [inline] __release_sock+0x214/0x350 net/core/sock.c:3072 release_sock+0x61/0x1f0 net/core/sock.c:3626 mptcp_push_ ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50068", "url": "https://ubuntu.com/security/CVE-2024-50068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/tests/sysfs-kunit.h: fix memory leak in damon_sysfs_test_add_targets() The sysfs_target->regions allocated in damon_sysfs_regions_alloc() is not freed in damon_sysfs_test_add_targets(), which cause the following memory leak, free it to fix it. \tunreferenced object 0xffffff80c2a8db80 (size 96): \t comm \"kunit_try_catch\", pid 187, jiffies 4294894363 \t hex dump (first 32 bytes): \t 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ \t 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ \t backtrace (crc 0): \t [<0000000001e3714d>] kmemleak_alloc+0x34/0x40 \t [<000000008e6835c1>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000001286d9f8>] damon_sysfs_test_add_targets+0x1cc/0x738 \t [<0000000032ef8f77>] kunit_try_run_case+0x13c/0x3ac \t [<00000000f3edea23>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000adf936cf>] kthread+0x2e8/0x374 \t [<0000000041bb1628>] ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50199", "url": "https://ubuntu.com/security/CVE-2024-50199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/swapfile: skip HugeTLB pages for unuse_vma I got a bad pud error and lost a 1GB HugeTLB when calling swapoff. The problem can be reproduced by the following steps: 1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory. 2. Swapout the above anonymous memory. 3. run swapoff and we will get a bad pud error in kernel message: mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7) We can tell that pud_clear_bad is called by pud_none_or_clear_bad in unuse_pud_range() by ftrace. And therefore the HugeTLB pages will never be freed because we lost it from page table. We can skip HugeTLB pages for unuse_vma to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50066", "url": "https://ubuntu.com/security/CVE-2024-50066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mremap: fix move_normal_pmd/retract_page_tables race In mremap(), move_page_tables() looks at the type of the PMD entry and the specified address range to figure out by which method the next chunk of page table entries should be moved. At that point, the mmap_lock is held in write mode, but no rmap locks are held yet. For PMD entries that point to page tables and are fully covered by the source address range, move_pgt_entry(NORMAL_PMD, ...) is called, which first takes rmap locks, then does move_normal_pmd(). move_normal_pmd() takes the necessary page table locks at source and destination, then moves an entire page table from the source to the destination. The problem is: The rmap locks, which protect against concurrent page table removal by retract_page_tables() in the THP code, are only taken after the PMD entry has been read and it has been decided how to move it. So we can race as follows (with two processes that have mappings of the same tmpfs file that is stored on a tmpfs mount with huge=advise); note that process A accesses page tables through the MM while process B does it through the file rmap: process A process B ========= ========= mremap mremap_to move_vma move_page_tables get_old_pmd alloc_new_pmd *** PREEMPT *** madvise(MADV_COLLAPSE) do_madvise madvise_walk_vmas madvise_vma_behavior madvise_collapse hpage_collapse_scan_file collapse_file retract_page_tables i_mmap_lock_read(mapping) pmdp_collapse_flush i_mmap_unlock_read(mapping) move_pgt_entry(NORMAL_PMD, ...) take_rmap_locks move_normal_pmd drop_rmap_locks When this happens, move_normal_pmd() can end up creating bogus PMD entries in the line `pmd_populate(mm, new_pmd, pmd_pgtable(pmd))`. The effect depends on arch-specific and machine-specific details; on x86, you can end up with physical page 0 mapped as a page table, which is likely exploitable for user->kernel privilege escalation. Fix the race by letting process B recheck that the PMD still points to a page table after the rmap locks have been taken. Otherwise, we bail and let the caller fall back to the PTE-level copying path, which will then bail immediately at the pmd_none() check. Bug reachability: Reaching this bug requires that you can create shmem/file THP mappings - anonymous THP uses different code that doesn't zap stuff under rmap locks. File THP is gated on an experimental config flag (CONFIG_READ_ONLY_THP_FOR_FS), so on normal distro kernels you need shmem THP to hit this bug. As far as I know, getting shmem THP normally requires that you can mount your own tmpfs with the right mount flags, which would require creating your own user+mount namespace; though I don't know if some distros maybe enable shmem THP by default or something like that. Bug impact: This issue can likely be used for user->kernel privilege escalation when it is reachable.", "cve_priority": "medium", "cve_public_date": "2024-10-23 06:15:00 UTC" }, { "cve": "CVE-2024-50202", "url": "https://ubuntu.com/security/CVE-2024-50202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: propagate directory read errors from nilfs_find_entry() Syzbot reported that a task hang occurs in vcs_open() during a fuzzing test for nilfs2. The root cause of this problem is that in nilfs_find_entry(), which searches for directory entries, ignores errors when loading a directory page/folio via nilfs_get_folio() fails. If the filesystem images is corrupted, and the i_size of the directory inode is large, and the directory page/folio is successfully read but fails the sanity check, for example when it is zero-filled, nilfs_check_folio() may continue to spit out error messages in bursts. Fix this issue by propagating the error to the callers when loading a page/folio fails in nilfs_find_entry(). The current interface of nilfs_find_entry() and its callers is outdated and cannot propagate error codes such as -EIO and -ENOMEM returned via nilfs_find_entry(), so fix it together.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50200", "url": "https://ubuntu.com/security/CVE-2024-50200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: maple_tree: correct tree corruption on spanning store Patch series \"maple_tree: correct tree corruption on spanning store\", v3. There has been a nasty yet subtle maple tree corruption bug that appears to have been in existence since the inception of the algorithm. This bug seems far more likely to happen since commit f8d112a4e657 (\"mm/mmap: avoid zeroing vma tree in mmap_region()\"), which is the point at which reports started to be submitted concerning this bug. We were made definitely aware of the bug thanks to the kind efforts of Bert Karwatzki who helped enormously in my being able to track this down and identify the cause of it. The bug arises when an attempt is made to perform a spanning store across two leaf nodes, where the right leaf node is the rightmost child of the shared parent, AND the store completely consumes the right-mode node. This results in mas_wr_spanning_store() mitakenly duplicating the new and existing entries at the maximum pivot within the range, and thus maple tree corruption. The fix patch corrects this by detecting this scenario and disallowing the mistaken duplicate copy. The fix patch commit message goes into great detail as to how this occurs. This series also includes a test which reliably reproduces the issue, and asserts that the fix works correctly. Bert has kindly tested the fix and confirmed it resolved his issues. Also Mikhail Gavrilov kindly reported what appears to be precisely the same bug, which this fix should also resolve. This patch (of 2): There has been a subtle bug present in the maple tree implementation from its inception. This arises from how stores are performed - when a store occurs, it will overwrite overlapping ranges and adjust the tree as necessary to accommodate this. A range may always ultimately span two leaf nodes. In this instance we walk the two leaf nodes, determine which elements are not overwritten to the left and to the right of the start and end of the ranges respectively and then rebalance the tree to contain these entries and the newly inserted one. This kind of store is dubbed a 'spanning store' and is implemented by mas_wr_spanning_store(). In order to reach this stage, mas_store_gfp() invokes mas_wr_preallocate(), mas_wr_store_type() and mas_wr_walk() in turn to walk the tree and update the object (mas) to traverse to the location where the write should be performed, determining its store type. When a spanning store is required, this function returns false stopping at the parent node which contains the target range, and mas_wr_store_type() marks the mas->store_type as wr_spanning_store to denote this fact. When we go to perform the store in mas_wr_spanning_store(), we first determine the elements AFTER the END of the range we wish to store (that is, to the right of the entry to be inserted) - we do this by walking to the NEXT pivot in the tree (i.e. r_mas.last + 1), starting at the node we have just determined contains the range over which we intend to write. We then turn our attention to the entries to the left of the entry we are inserting, whose state is represented by l_mas, and copy these into a 'big node', which is a special node which contains enough slots to contain two leaf node's worth of data. We then copy the entry we wish to store immediately after this - the copy and the insertion of the new entry is performed by mas_store_b_node(). After this we copy the elements to the right of the end of the range which we are inserting, if we have not exceeded the length of the node (i.e. r_mas.offset <= r_mas.end). Herein lies the bug - under very specific circumstances, this logic can break and corrupt the maple tree. Consider the following tree: Height 0 Root Node / \\ pivot = 0xffff / \\ pivot = ULONG_MAX / ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50084", "url": "https://ubuntu.com/security/CVE-2024-50084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: microchip: vcap api: Fix memory leaks in vcap_api_encode_rule_test() Commit a3c1e45156ad (\"net: microchip: vcap: Fix use-after-free error in kunit test\") fixed the use-after-free error, but introduced below memory leaks by removing necessary vcap_free_rule(), add it to fix it. \tunreferenced object 0xffffff80ca58b700 (size 192): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898264 \t hex dump (first 32 bytes): \t 00 12 7a 00 05 00 00 00 0a 00 00 00 64 00 00 00 ..z.........d... \t 00 00 00 00 00 00 00 00 00 04 0b cc 80 ff ff ff ................ \t backtrace (crc 9c09c3fe): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<0000000040a01b8d>] vcap_alloc_rule+0x3cc/0x9c4 \t [<000000003fe86110>] vcap_api_encode_rule_test+0x1ac/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0400 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898265 \t hex dump (first 32 bytes): \t 80 04 0b cc 80 ff ff ff 18 b7 58 ca 80 ff ff ff ..........X..... \t 39 00 00 00 02 00 00 00 06 05 04 03 02 01 ff ff 9............... \t backtrace (crc daf014e9): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<00000000dfdb1e81>] vcap_api_encode_rule_test+0x224/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0700 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898265 \t hex dump (first 32 bytes): \t 80 07 0b cc 80 ff ff ff 28 b7 58 ca 80 ff ff ff ........(.X..... \t 3c 00 00 00 00 00 00 00 01 2f 03 b3 ec ff ff ff <......../...... \t backtrace (crc 8d877792): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000006eadfab7>] vcap_rule_add_action+0x2d0/0x52c \t [<00000000323475d1>] vcap_api_encode_rule_test+0x4d4/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0900 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898266 \t hex dump (first 32 bytes): \t 80 09 0b cc 80 ff ff ff 80 06 0b cc 80 ff ff ff ................ \t 7d 00 00 00 01 00 00 00 00 00 00 00 ff 00 00 00 }............... \t backtrace (crc 34181e56): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<00000000991e3564>] vcap_val_rule+0xcf0/0x13e8 \t [<00000000fc9868e5>] vcap_api_encode_rule_test+0x678/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0980 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898266 \t hex dump (first 32 bytes): \t 18 b7 58 ca 80 ff ff ff 00 09 0b cc 80 ff ff ff ..X............. \t 67 00 00 00 00 00 00 00 01 01 74 88 c0 ff ff ff g.........t..... \t backtrace (crc 275fd9be): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<000000001396a1a2>] test_add_de ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50194", "url": "https://ubuntu.com/security/CVE-2024-50194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Fix uprobes for big-endian kernels The arm64 uprobes code is broken for big-endian kernels as it doesn't convert the in-memory instruction encoding (which is always little-endian) into the kernel's native endianness before analyzing and simulating instructions. This may result in a few distinct problems: * The kernel may may erroneously reject probing an instruction which can safely be probed. * The kernel may erroneously erroneously permit stepping an instruction out-of-line when that instruction cannot be stepped out-of-line safely. * The kernel may erroneously simulate instruction incorrectly dur to interpretting the byte-swapped encoding. The endianness mismatch isn't caught by the compiler or sparse because: * The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so the compiler and sparse have no idea these contain a little-endian 32-bit value. The core uprobes code populates these with a memcpy() which similarly does not handle endianness. * While the uprobe_opcode_t type is an alias for __le32, both arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[] to the similarly-named probe_opcode_t, which is an alias for u32. Hence there is no endianness conversion warning. Fix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and adding the appropriate __le32_to_cpu() conversions prior to consuming the instruction encoding. The core uprobes copies these fields as opaque ranges of bytes, and so is unaffected by this change. At the same time, remove MAX_UINSN_BYTES and consistently use AARCH64_INSN_SIZE for clarity. Tested with the following: | #include | #include | | #define noinline __attribute__((noinline)) | | static noinline void *adrp_self(void) | { | void *addr; | | asm volatile( | \" adrp %x0, adrp_self\\n\" | \" add %x0, %x0, :lo12:adrp_self\\n\" | : \"=r\" (addr)); | } | | | int main(int argc, char *argv) | { | void *ptr = adrp_self(); | bool equal = (ptr == adrp_self); | | printf(\"adrp_self => %p\\n\" | \"adrp_self() => %p\\n\" | \"%s\\n\", | adrp_self, ptr, equal ? \"EQUAL\" : \"NOT EQUAL\"); | | return 0; | } .... where the adrp_self() function was compiled to: | 00000000004007e0 : | 4007e0: 90000000 adrp x0, 400000 <__ehdr_start> | 4007e4: 911f8000 add x0, x0, #0x7e0 | 4007e8: d65f03c0 ret Before this patch, the ADRP is not recognized, and is assumed to be steppable, resulting in corruption of the result: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0xffffffffff7e0 | NOT EQUAL After this patch, the ADRP is correctly recognized and simulated: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50099", "url": "https://ubuntu.com/security/CVE-2024-50099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Remove broken LDR (literal) uprobe support The simulate_ldr_literal() and simulate_ldrsw_literal() functions are unsafe to use for uprobes. Both functions were originally written for use with kprobes, and access memory with plain C accesses. When uprobes was added, these were reused unmodified even though they cannot safely access user memory. There are three key problems: 1) The plain C accesses do not have corresponding extable entries, and thus if they encounter a fault the kernel will treat these as unintentional accesses to user memory, resulting in a BUG() which will kill the kernel thread, and likely lead to further issues (e.g. lockup or panic()). 2) The plain C accesses are subject to HW PAN and SW PAN, and so when either is in use, any attempt to simulate an access to user memory will fault. Thus neither simulate_ldr_literal() nor simulate_ldrsw_literal() can do anything useful when simulating a user instruction on any system with HW PAN or SW PAN. 3) The plain C accesses are privileged, as they run in kernel context, and in practice can access a small range of kernel virtual addresses. The instructions they simulate have a range of +/-1MiB, and since the simulated instructions must itself be a user instructions in the TTBR0 address range, these can address the final 1MiB of the TTBR1 acddress range by wrapping downwards from an address in the first 1MiB of the TTBR0 address range. In contemporary kernels the last 8MiB of TTBR1 address range is reserved, and accesses to this will always fault, meaning this is no worse than (1). Historically, it was theoretically possible for the linear map or vmemmap to spill into the final 8MiB of the TTBR1 address range, but in practice this is extremely unlikely to occur as this would require either: * Having enough physical memory to fill the entire linear map all the way to the final 1MiB of the TTBR1 address range. * Getting unlucky with KASLR randomization of the linear map such that the populated region happens to overlap with the last 1MiB of the TTBR address range. ... and in either case if we were to spill into the final page there would be larger problems as the final page would alias with error pointers. Practically speaking, (1) and (2) are the big issues. Given there have been no reports of problems since the broken code was introduced, it appears that no-one is relying on probing these instructions with uprobes. Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW (literal), limiting the use of simulate_ldr_literal() and simulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR (literal) and LDRSW (literal) will be rejected as arm_probe_decode_insn() will return INSN_REJECTED. In future we can consider introducing working uprobes support for these instructions, but this will require more significant work.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50195", "url": "https://ubuntu.com/security/CVE-2024-50195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-clock: Fix missing timespec64 check in pc_clock_settime() As Andrew pointed out, it will make sense that the PTP core checked timespec64 struct's tv_sec and tv_nsec range before calling ptp->info->settime64(). As the man manual of clock_settime() said, if tp.tv_sec is negative or tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL, which include dynamic clocks which handles PTP clock, and the condition is consistent with timespec64_valid(). As Thomas suggested, timespec64_valid() only check the timespec is valid, but not ensure that the time is in a valid range, so check it ahead using timespec64_valid_strict() in pc_clock_settime() and return -EINVAL if not valid. There are some drivers that use tp->tv_sec and tp->tv_nsec directly to write registers without validity checks and assume that the higher layer has checked it, which is dangerous and will benefit from this, such as hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(), and some drivers can remove the checks of itself.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50085", "url": "https://ubuntu.com/security/CVE-2024-50085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: fix UaF read in mptcp_pm_nl_rm_addr_or_subflow Syzkaller reported this splat: ================================================================== BUG: KASAN: slab-use-after-free in mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881 Read of size 4 at addr ffff8880569ac858 by task syz.1.2799/14662 CPU: 0 UID: 0 PID: 14662 Comm: syz.1.2799 Not tainted 6.12.0-rc2-syzkaller-00307-g36c254515dc6 #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+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881 mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:914 [inline] mptcp_nl_remove_id_zero_address+0x305/0x4a0 net/mptcp/pm_netlink.c:1572 mptcp_pm_nl_del_addr_doit+0x5c9/0x770 net/mptcp/pm_netlink.c:1603 genl_family_rcv_msg_doit+0x202/0x2f0 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x565/0x800 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x165/0x410 net/netlink/af_netlink.c:2551 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1331 [inline] netlink_unicast+0x53c/0x7f0 net/netlink/af_netlink.c:1357 netlink_sendmsg+0x8b8/0xd70 net/netlink/af_netlink.c:1901 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg net/socket.c:744 [inline] ____sys_sendmsg+0x9ae/0xb40 net/socket.c:2607 ___sys_sendmsg+0x135/0x1e0 net/socket.c:2661 __sys_sendmsg+0x117/0x1f0 net/socket.c:2690 do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline] __do_fast_syscall_32+0x73/0x120 arch/x86/entry/common.c:386 do_fast_syscall_32+0x32/0x80 arch/x86/entry/common.c:411 entry_SYSENTER_compat_after_hwframe+0x84/0x8e RIP: 0023:0xf7fe4579 Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00 RSP: 002b:00000000f574556c EFLAGS: 00000296 ORIG_RAX: 0000000000000172 RAX: ffffffffffffffda RBX: 000000000000000b RCX: 0000000020000140 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000296 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Allocated by task 5387: 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 kmalloc_noprof include/linux/slab.h:878 [inline] kzalloc_noprof include/linux/slab.h:1014 [inline] subflow_create_ctx+0x87/0x2a0 net/mptcp/subflow.c:1803 subflow_ulp_init+0xc3/0x4d0 net/mptcp/subflow.c:1956 __tcp_set_ulp net/ipv4/tcp_ulp.c:146 [inline] tcp_set_ulp+0x326/0x7f0 net/ipv4/tcp_ulp.c:167 mptcp_subflow_create_socket+0x4ae/0x10a0 net/mptcp/subflow.c:1764 __mptcp_subflow_connect+0x3cc/0x1490 net/mptcp/subflow.c:1592 mptcp_pm_create_subflow_or_signal_addr+0xbda/0x23a0 net/mptcp/pm_netlink.c:642 mptcp_pm_nl_fully_established net/mptcp/pm_netlink.c:650 [inline] mptcp_pm_nl_work+0x3a1/0x4f0 net/mptcp/pm_netlink.c:943 mptcp_worker+0x15a/0x1240 net/mptcp/protocol.c:2777 process_one_work+0x958/0x1b30 kernel/workqueue.c:3229 process_scheduled_works kernel/workqueue.c:3310 [inline] worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/ke ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50086", "url": "https://ubuntu.com/security/CVE-2024-50086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix user-after-free from session log off There is racy issue between smb2 session log off and smb2 session setup. It will cause user-after-free from session log off. This add session_lock when setting SMB2_SESSION_EXPIRED and referece count to session struct not to free session while it is being used.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50087", "url": "https://ubuntu.com/security/CVE-2024-50087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix uninitialized pointer free on read_alloc_one_name() error The function read_alloc_one_name() does not initialize the name field of the passed fscrypt_str struct if kmalloc fails to allocate the corresponding buffer. Thus, it is not guaranteed that fscrypt_str.name is initialized when freeing it. This is a follow-up to the linked patch that fixes the remaining instances of the bug introduced by commit e43eec81c516 (\"btrfs: use struct qstr instead of name and namelen pairs\").", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50088", "url": "https://ubuntu.com/security/CVE-2024-50088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix uninitialized pointer free in add_inode_ref() The add_inode_ref() function does not initialize the \"name\" struct when it is declared. If any of the following calls to \"read_one_inode() returns NULL, \tdir = read_one_inode(root, parent_objectid); \tif (!dir) { \t\tret = -ENOENT; \t\tgoto out; \t} \tinode = read_one_inode(root, inode_objectid); \tif (!inode) { \t\tret = -EIO; \t\tgoto out; \t} then \"name.name\" would be freed on \"out\" before being initialized. out: \t... \tkfree(name.name); This issue was reported by Coverity with CID 1526744.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50182", "url": "https://ubuntu.com/security/CVE-2024-50182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: secretmem: disable memfd_secret() if arch cannot set direct map Return -ENOSYS from memfd_secret() syscall if !can_set_direct_map(). This is the case for example on some arm64 configurations, where marking 4k PTEs in the direct map not present can only be done if the direct map is set up at 4k granularity in the first place (as ARM's break-before-make semantics do not easily allow breaking apart large/gigantic pages). More precisely, on arm64 systems with !can_set_direct_map(), set_direct_map_invalid_noflush() is a no-op, however it returns success (0) instead of an error. This means that memfd_secret will seemingly \"work\" (e.g. syscall succeeds, you can mmap the fd and fault in pages), but it does not actually achieve its goal of removing its memory from the direct map. Note that with this patch, memfd_secret() will start erroring on systems where can_set_direct_map() returns false (arm64 with CONFIG_RODATA_FULL_DEFAULT_ENABLED=n, CONFIG_DEBUG_PAGEALLOC=n and CONFIG_KFENCE=n), but that still seems better than the current silent failure. Since CONFIG_RODATA_FULL_DEFAULT_ENABLED defaults to 'y', most arm64 systems actually have a working memfd_secret() and aren't be affected. From going through the iterations of the original memfd_secret patch series, it seems that disabling the syscall in these scenarios was the intended behavior [1] (preferred over having set_direct_map_invalid_noflush return an error as that would result in SIGBUSes at page-fault time), however the check for it got dropped between v16 [2] and v17 [3], when secretmem moved away from CMA allocations. [1]: https://lore.kernel.org/lkml/20201124164930.GK8537@kernel.org/ [2]: https://lore.kernel.org/lkml/20210121122723.3446-11-rppt@kernel.org/#t [3]: https://lore.kernel.org/lkml/20201125092208.12544-10-rppt@kernel.org/", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50019", "url": "https://ubuntu.com/security/CVE-2024-50019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kthread: unpark only parked kthread Calling into kthread unparking unconditionally is mostly harmless when the kthread is already unparked. The wake up is then simply ignored because the target is not in TASK_PARKED state. However if the kthread is per CPU, the wake up is preceded by a call to kthread_bind() which expects the task to be inactive and in TASK_PARKED state, which obviously isn't the case if it is unparked. As a result, calling kthread_stop() on an unparked per-cpu kthread triggers such a warning: \tWARNING: CPU: 0 PID: 11 at kernel/kthread.c:525 __kthread_bind_mask kernel/kthread.c:525 \t \t kthread_stop+0x17a/0x630 kernel/kthread.c:707 \t destroy_workqueue+0x136/0xc40 kernel/workqueue.c:5810 \t wg_destruct+0x1e2/0x2e0 drivers/net/wireguard/device.c:257 \t netdev_run_todo+0xe1a/0x1000 net/core/dev.c:10693 \t default_device_exit_batch+0xa14/0xa90 net/core/dev.c:11769 \t ops_exit_list net/core/net_namespace.c:178 [inline] \t cleanup_net+0x89d/0xcc0 net/core/net_namespace.c:640 \t process_one_work kernel/workqueue.c:3231 [inline] \t process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 \t worker_thread+0x86d/0xd70 kernel/workqueue.c:3393 \t kthread+0x2f0/0x390 kernel/kthread.c:389 \t ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 \t ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 \t Fix this with skipping unecessary unparking while stopping a kthread.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50096", "url": "https://ubuntu.com/security/CVE-2024-50096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/dmem: Fix vulnerability in migrate_to_ram upon copy error The `nouveau_dmem_copy_one` function ensures that the copy push command is sent to the device firmware but does not track whether it was executed successfully. In the case of a copy error (e.g., firmware or hardware failure), the copy push command will be sent via the firmware channel, and `nouveau_dmem_copy_one` will likely report success, leading to the `migrate_to_ram` function returning a dirty HIGH_USER page to the user. This can result in a security vulnerability, as a HIGH_USER page that may contain sensitive or corrupted data could be returned to the user. To prevent this vulnerability, we allocate a zero page. Thus, in case of an error, a non-dirty (zero) page will be returned to the user.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50020", "url": "https://ubuntu.com/security/CVE-2024-50020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix improper handling of refcount in ice_sriov_set_msix_vec_count() This patch addresses an issue with improper reference count handling in the ice_sriov_set_msix_vec_count() function. First, the function calls ice_get_vf_by_id(), which increments the reference count of the vf pointer. If the subsequent call to ice_get_vf_vsi() fails, the function currently returns an error without decrementing the reference count of the vf pointer, leading to a reference count leak. The correct behavior, as implemented in this patch, is to decrement the reference count using ice_put_vf(vf) before returning an error when vsi is NULL. Second, the function calls ice_sriov_get_irqs(), which sets vf->first_vector_idx. If this call returns a negative value, indicating an error, the function returns an error without decrementing the reference count of the vf pointer, resulting in another reference count leak. The patch addresses this by adding a call to ice_put_vf(vf) before returning an error when vf->first_vector_idx < 0. This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and identifying potential mismanagement of reference counts. In this case, the tool flagged the missing decrement operation as a potential issue, leading to this patch.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50021", "url": "https://ubuntu.com/security/CVE-2024-50021", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix improper handling of refcount in ice_dpll_init_rclk_pins() This patch addresses a reference count handling issue in the ice_dpll_init_rclk_pins() function. The function calls ice_dpll_get_pins(), which increments the reference count of the relevant resources. However, if the condition WARN_ON((!vsi || !vsi->netdev)) is met, the function currently returns an error without properly releasing the resources acquired by ice_dpll_get_pins(), leading to a reference count leak. To resolve this, the check has been moved to the top of the function. This ensures that the function verifies the state before any resources are acquired, avoiding the need for additional resource management in the error path. This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and detecting potential issues where resources are not properly managed. In this case, the tool flagged the missing release operation as a potential problem, which led to the development of this patch.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50022", "url": "https://ubuntu.com/security/CVE-2024-50022", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: device-dax: correct pgoff align in dax_set_mapping() pgoff should be aligned using ALIGN_DOWN() instead of ALIGN(). Otherwise, vmf->address not aligned to fault_size will be aligned to the next alignment, that can result in memory failure getting the wrong address. It's a subtle situation that only can be observed in page_mapped_in_vma() after the page is page fault handled by dev_dax_huge_fault. Generally, there is little chance to perform page_mapped_in_vma in dev-dax's page unless in specific error injection to the dax device to trigger an MCE - memory-failure. In that case, page_mapped_in_vma() will be triggered to determine which task is accessing the failure address and kill that task in the end. We used self-developed dax device (which is 2M aligned mapping) , to perform error injection to random address. It turned out that error injected to non-2M-aligned address was causing endless MCE until panic. Because page_mapped_in_vma() kept resulting wrong address and the task accessing the failure address was never killed properly: [ 3783.719419] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.049006] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.049190] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.448042] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.448186] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.792026] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.792179] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.162502] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.162633] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.461116] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.461247] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.764730] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.764859] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.042128] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.042259] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.464293] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.464423] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.818090] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.818217] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3787.085297] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3787.085424] Memory failure: 0x200c9742: recovery action for dax page: Recovered It took us several weeks to pinpoint this problem,  but we eventually used bpftrace to trace the page fault and mce address and successfully identified the issue. Joao added: ; Likely we never reproduce in production because we always pin : device-dax regions in the region align they provide (Qemu does : similarly with prealloc in hugetlb/file backed memory). I think this : bug requires that we touch *unpinned* device-dax regions unaligned to : the device-dax selected alignment (page size i.e. 4K/2M/1G)", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50185", "url": "https://ubuntu.com/security/CVE-2024-50185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: handle consistently DSS corruption Bugged peer implementation can send corrupted DSS options, consistently hitting a few warning in the data path. Use DEBUG_NET assertions, to avoid the splat on some builds and handle consistently the error, dumping related MIBs and performing fallback and/or reset according to the subflow type.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50023", "url": "https://ubuntu.com/security/CVE-2024-50023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: Remove LED entry from LEDs list on unregister Commit c938ab4da0eb (\"net: phy: Manual remove LEDs to ensure correct ordering\") correctly fixed a problem with using devm_ but missed removing the LED entry from the LEDs list. This cause kernel panic on specific scenario where the port for the PHY is torn down and up and the kmod for the PHY is removed. On setting the port down the first time, the assosiacted LEDs are correctly unregistered. The associated kmod for the PHY is now removed. The kmod is now added again and the port is now put up, the associated LED are registered again. On putting the port down again for the second time after these step, the LED list now have 4 elements. With the first 2 already unregistered previously and the 2 new one registered again. This cause a kernel panic as the first 2 element should have been removed. Fix this by correctly removing the element when LED is unregistered.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50024", "url": "https://ubuntu.com/security/CVE-2024-50024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: Fix an unsafe loop on the list The kernel may crash when deleting a genetlink family if there are still listeners for that family: Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c000000000c080bc] netlink_update_socket_mc+0x3c/0xc0 LR [c000000000c0f764] __netlink_clear_multicast_users+0x74/0xc0 Call Trace: __netlink_clear_multicast_users+0x74/0xc0 genl_unregister_family+0xd4/0x2d0 Change the unsafe loop on the list to a safe one, because inside the loop there is an element removal from this list.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50186", "url": "https://ubuntu.com/security/CVE-2024-50186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: explicitly clear the sk pointer, when pf->create fails We have recently noticed the exact same KASAN splat as in commit 6cd4a78d962b (\"net: do not leave a dangling sk pointer, when socket creation fails\"). The problem is that commit did not fully address the problem, as some pf->create implementations do not use sk_common_release in their error paths. For example, we can use the same reproducer as in the above commit, but changing ping to arping. arping uses AF_PACKET socket and if packet_create fails, it will just sk_free the allocated sk object. While we could chase all the pf->create implementations and make sure they NULL the freed sk object on error from the socket, we can't guarantee future protocols will not make the same mistake. So it is easier to just explicitly NULL the sk pointer upon return from pf->create in __sock_create. We do know that pf->create always releases the allocated sk object on error, so if the pointer is not NULL, it is definitely dangling.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50025", "url": "https://ubuntu.com/security/CVE-2024-50025", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: fnic: Move flush_work initialization out of if block After commit 379a58caa199 (\"scsi: fnic: Move fnic_fnic_flush_tx() to a work queue\"), it can happen that a work item is sent to an uninitialized work queue. This may has the effect that the item being queued is never actually queued, and any further actions depending on it will not proceed. The following warning is observed while the fnic driver is loaded: kernel: WARNING: CPU: 11 PID: 0 at ../kernel/workqueue.c:1524 __queue_work+0x373/0x410 kernel: kernel: queue_work_on+0x3a/0x50 kernel: fnic_wq_copy_cmpl_handler+0x54a/0x730 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: fnic_isr_msix_wq_copy+0x2d/0x60 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: __handle_irq_event_percpu+0x36/0x1a0 kernel: handle_irq_event_percpu+0x30/0x70 kernel: handle_irq_event+0x34/0x60 kernel: handle_edge_irq+0x7e/0x1a0 kernel: __common_interrupt+0x3b/0xb0 kernel: common_interrupt+0x58/0xa0 kernel: It has been observed that this may break the rediscovery of Fibre Channel devices after a temporary fabric failure. This patch fixes it by moving the work queue initialization out of an if block in fnic_probe().", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50026", "url": "https://ubuntu.com/security/CVE-2024-50026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: wd33c93: Don't use stale scsi_pointer value A regression was introduced with commit dbb2da557a6a (\"scsi: wd33c93: Move the SCSI pointer to private command data\") which results in an oops in wd33c93_intr(). That commit added the scsi_pointer variable and initialized it from hostdata->connected. However, during selection, hostdata->connected is not yet valid. Fix this by getting the current scsi_pointer from hostdata->selecting.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50027", "url": "https://ubuntu.com/security/CVE-2024-50027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: core: Free tzp copy along with the thermal zone The object pointed to by tz->tzp may still be accessed after being freed in thermal_zone_device_unregister(), so move the freeing of it to the point after the removal completion has been completed at which it cannot be accessed any more.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50028", "url": "https://ubuntu.com/security/CVE-2024-50028", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: core: Reference count the zone in thermal_zone_get_by_id() There are places in the thermal netlink code where nothing prevents the thermal zone object from going away while being accessed after it has been returned by thermal_zone_get_by_id(). To address this, make thermal_zone_get_by_id() get a reference on the thermal zone device object to be returned with the help of get_device(), under thermal_list_lock, and adjust all of its callers to this change with the help of the cleanup.h infrastructure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50029", "url": "https://ubuntu.com/security/CVE-2024-50029", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_conn: Fix UAF in hci_enhanced_setup_sync This checks if the ACL connection remains valid as it could be destroyed while hci_enhanced_setup_sync is pending on cmd_sync leading to the following trace: BUG: KASAN: slab-use-after-free in hci_enhanced_setup_sync+0x91b/0xa60 Read of size 1 at addr ffff888002328ffd by task kworker/u5:2/37 CPU: 0 UID: 0 PID: 37 Comm: kworker/u5:2 Not tainted 6.11.0-rc6-01300-g810be445d8d6 #7099 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Workqueue: hci0 hci_cmd_sync_work Call Trace: dump_stack_lvl+0x5d/0x80 ? hci_enhanced_setup_sync+0x91b/0xa60 print_report+0x152/0x4c0 ? hci_enhanced_setup_sync+0x91b/0xa60 ? __virt_addr_valid+0x1fa/0x420 ? hci_enhanced_setup_sync+0x91b/0xa60 kasan_report+0xda/0x1b0 ? hci_enhanced_setup_sync+0x91b/0xa60 hci_enhanced_setup_sync+0x91b/0xa60 ? __pfx_hci_enhanced_setup_sync+0x10/0x10 ? __pfx___mutex_lock+0x10/0x10 hci_cmd_sync_work+0x1c2/0x330 process_one_work+0x7d9/0x1360 ? __pfx_lock_acquire+0x10/0x10 ? __pfx_process_one_work+0x10/0x10 ? assign_work+0x167/0x240 worker_thread+0x5b7/0xf60 ? __kthread_parkme+0xac/0x1c0 ? __pfx_worker_thread+0x10/0x10 ? __pfx_worker_thread+0x10/0x10 kthread+0x293/0x360 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2f/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 34: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __hci_conn_add+0x187/0x17d0 hci_connect_sco+0x2e1/0xb90 sco_sock_connect+0x2a2/0xb80 __sys_connect+0x227/0x2a0 __x64_sys_connect+0x6d/0xb0 do_syscall_64+0x71/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 37: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x101/0x160 kfree+0xd0/0x250 device_release+0x9a/0x210 kobject_put+0x151/0x280 hci_conn_del+0x448/0xbf0 hci_abort_conn_sync+0x46f/0x980 hci_cmd_sync_work+0x1c2/0x330 process_one_work+0x7d9/0x1360 worker_thread+0x5b7/0xf60 kthread+0x293/0x360 ret_from_fork+0x2f/0x70 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50030", "url": "https://ubuntu.com/security/CVE-2024-50030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/ct: prevent UAF in send_recv() Ensure we serialize with completion side to prevent UAF with fence going out of scope on the stack, since we have no clue if it will fire after the timeout before we can erase from the xa. Also we have some dependent loads and stores for which we need the correct ordering, and we lack the needed barriers. Fix this by grabbing the ct->lock after the wait, which is also held by the completion side. v2 (Badal): - Also print done after acquiring the lock and seeing timeout. (cherry picked from commit 52789ce35c55ccd30c4b67b9cc5b2af55e0122ea)", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50187", "url": "https://ubuntu.com/security/CVE-2024-50187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Stop the active perfmon before being destroyed Upon closing the file descriptor, the active performance monitor is not stopped. Although all perfmons are destroyed in `vc4_perfmon_close_file()`, the active performance monitor's pointer (`vc4->active_perfmon`) is still retained. If we open a new file descriptor and submit a few jobs with performance monitors, the driver will attempt to stop the active performance monitor using the stale pointer in `vc4->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50031", "url": "https://ubuntu.com/security/CVE-2024-50031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Stop the active perfmon before being destroyed When running `kmscube` with one or more performance monitors enabled via `GALLIUM_HUD`, the following kernel panic can occur: [ 55.008324] Unable to handle kernel paging request at virtual address 00000000052004a4 [ 55.008368] Mem abort info: [ 55.008377] ESR = 0x0000000096000005 [ 55.008387] EC = 0x25: DABT (current EL), IL = 32 bits [ 55.008402] SET = 0, FnV = 0 [ 55.008412] EA = 0, S1PTW = 0 [ 55.008421] FSC = 0x05: level 1 translation fault [ 55.008434] Data abort info: [ 55.008442] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 55.008455] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 55.008467] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 55.008481] user pgtable: 4k pages, 39-bit VAs, pgdp=00000001046c6000 [ 55.008497] [00000000052004a4] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 55.008525] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP [ 55.008542] Modules linked in: rfcomm [...] vc4 v3d snd_soc_hdmi_codec drm_display_helper gpu_sched drm_shmem_helper cec drm_dma_helper drm_kms_helper i2c_brcmstb drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight [ 55.008799] CPU: 2 PID: 166 Comm: v3d_bin Tainted: G C 6.6.47+rpt-rpi-v8 #1 Debian 1:6.6.47-1+rpt1 [ 55.008824] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [ 55.008838] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 55.008855] pc : __mutex_lock.constprop.0+0x90/0x608 [ 55.008879] lr : __mutex_lock.constprop.0+0x58/0x608 [ 55.008895] sp : ffffffc080673cf0 [ 55.008904] x29: ffffffc080673cf0 x28: 0000000000000000 x27: ffffff8106188a28 [ 55.008926] x26: ffffff8101e78040 x25: ffffff8101baa6c0 x24: ffffffd9d989f148 [ 55.008947] x23: ffffffda1c2a4008 x22: 0000000000000002 x21: ffffffc080673d38 [ 55.008968] x20: ffffff8101238000 x19: ffffff8104f83188 x18: 0000000000000000 [ 55.008988] x17: 0000000000000000 x16: ffffffda1bd04d18 x15: 00000055bb08bc90 [ 55.009715] x14: 0000000000000000 x13: 0000000000000000 x12: ffffffda1bd4cbb0 [ 55.010433] x11: 00000000fa83b2da x10: 0000000000001a40 x9 : ffffffda1bd04d04 [ 55.011162] x8 : ffffff8102097b80 x7 : 0000000000000000 x6 : 00000000030a5857 [ 55.011880] x5 : 00ffffffffffffff x4 : 0300000005200470 x3 : 0300000005200470 [ 55.012598] x2 : ffffff8101238000 x1 : 0000000000000021 x0 : 0300000005200470 [ 55.013292] Call trace: [ 55.013959] __mutex_lock.constprop.0+0x90/0x608 [ 55.014646] __mutex_lock_slowpath+0x1c/0x30 [ 55.015317] mutex_lock+0x50/0x68 [ 55.015961] v3d_perfmon_stop+0x40/0xe0 [v3d] [ 55.016627] v3d_bin_job_run+0x10c/0x2d8 [v3d] [ 55.017282] drm_sched_main+0x178/0x3f8 [gpu_sched] [ 55.017921] kthread+0x11c/0x128 [ 55.018554] ret_from_fork+0x10/0x20 [ 55.019168] Code: f9400260 f1001c1f 54001ea9 927df000 (b9403401) [ 55.019776] ---[ end trace 0000000000000000 ]--- [ 55.020411] note: v3d_bin[166] exited with preempt_count 1 This issue arises because, upon closing the file descriptor (which happens when we interrupt `kmscube`), the active performance monitor is not stopped. Although all perfmons are destroyed in `v3d_perfmon_close_file()`, the active performance monitor's pointer (`v3d->active_perfmon`) is still retained. If `kmscube` is run again, the driver will attempt to stop the active performance monitor using the stale pointer in `v3d->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50189", "url": "https://ubuntu.com/security/CVE-2024-50189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: amd_sfh: Switch to device-managed dmam_alloc_coherent() Using the device-managed version allows to simplify clean-up in probe() error path. Additionally, this device-managed ensures proper cleanup, which helps to resolve memory errors, page faults, btrfs going read-only, and btrfs disk corruption.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50033", "url": "https://ubuntu.com/security/CVE-2024-50033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slip: make slhc_remember() more robust against malicious packets syzbot found that slhc_remember() was missing checks against malicious packets [1]. slhc_remember() only checked the size of the packet was at least 20, which is not good enough. We need to make sure the packet includes the IPv4 and TCP header that are supposed to be carried. Add iph and th pointers to make the code more readable. [1] BUG: KMSAN: uninit-value in slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 ppp_receive_nonmp_frame+0xe45/0x35e0 drivers/net/ppp/ppp_generic.c:2455 ppp_receive_frame drivers/net/ppp/ppp_generic.c:2372 [inline] ppp_do_recv+0x65f/0x40d0 drivers/net/ppp/ppp_generic.c:2212 ppp_input+0x7dc/0xe60 drivers/net/ppp/ppp_generic.c:2327 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 Uninit was created at: slab_post_alloc_hook mm/slub.c:4091 [inline] slab_alloc_node mm/slub.c:4134 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 CPU: 0 UID: 0 PID: 5460 Comm: syz.2.33 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50034", "url": "https://ubuntu.com/security/CVE-2024-50034", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix lacks of icsk_syn_mss with IPPROTO_SMC Eric report a panic on IPPROTO_SMC, and give the facts that when INET_PROTOSW_ICSK was set, icsk->icsk_sync_mss must be set too. Bug: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000086000005 EC = 0x21: IABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault user pgtable: 4k pages, 48-bit VAs, pgdp=00000001195d1000 [0000000000000000] pgd=0800000109c46003, p4d=0800000109c46003, pud=0000000000000000 Internal error: Oops: 0000000086000005 [#1] PREEMPT SMP Modules linked in: CPU: 1 UID: 0 PID: 8037 Comm: syz.3.265 Not tainted 6.11.0-rc7-syzkaller-g5f5673607153 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0x0 lr : cipso_v4_sock_setattr+0x2a8/0x3c0 net/ipv4/cipso_ipv4.c:1910 sp : ffff80009b887a90 x29: ffff80009b887aa0 x28: ffff80008db94050 x27: 0000000000000000 x26: 1fffe0001aa6f5b3 x25: dfff800000000000 x24: ffff0000db75da00 x23: 0000000000000000 x22: ffff0000d8b78518 x21: 0000000000000000 x20: ffff0000d537ad80 x19: ffff0000d8b78000 x18: 1fffe000366d79ee x17: ffff8000800614a8 x16: ffff800080569b84 x15: 0000000000000001 x14: 000000008b336894 x13: 00000000cd96feaa x12: 0000000000000003 x11: 0000000000040000 x10: 00000000000020a3 x9 : 1fffe0001b16f0f1 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 000000000000003f x5 : 0000000000000040 x4 : 0000000000000001 x3 : 0000000000000000 x2 : 0000000000000002 x1 : 0000000000000000 x0 : ffff0000d8b78000 Call trace: 0x0 netlbl_sock_setattr+0x2e4/0x338 net/netlabel/netlabel_kapi.c:1000 smack_netlbl_add+0xa4/0x154 security/smack/smack_lsm.c:2593 smack_socket_post_create+0xa8/0x14c security/smack/smack_lsm.c:2973 security_socket_post_create+0x94/0xd4 security/security.c:4425 __sock_create+0x4c8/0x884 net/socket.c:1587 sock_create net/socket.c:1622 [inline] __sys_socket_create net/socket.c:1659 [inline] __sys_socket+0x134/0x340 net/socket.c:1706 __do_sys_socket net/socket.c:1720 [inline] __se_sys_socket net/socket.c:1718 [inline] __arm64_sys_socket+0x7c/0x94 net/socket.c:1718 __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:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 Code: ???????? ???????? ???????? ???????? (????????) ---[ end trace 0000000000000000 ]--- This patch add a toy implementation that performs a simple return to prevent such panic. This is because MSS can be set in sock_create_kern or smc_setsockopt, similar to how it's done in AF_SMC. However, for AF_SMC, there is currently no way to synchronize MSS within __sys_connect_file. This toy implementation lays the groundwork for us to support such feature for IPPROTO_SMC in the future.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50035", "url": "https://ubuntu.com/security/CVE-2024-50035", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: fix ppp_async_encode() illegal access syzbot reported an issue in ppp_async_encode() [1] In this case, pppoe_sendmsg() is called with a zero size. Then ppp_async_encode() is called with an empty skb. BUG: KMSAN: uninit-value in ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] BUG: KMSAN: uninit-value in ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_send+0x130/0x1b0 drivers/net/ppp/ppp_async.c:634 ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2280 [inline] ppp_input+0x1f1/0xe60 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 Uninit was created at: slab_post_alloc_hook mm/slub.c:4092 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4187 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 CPU: 1 UID: 0 PID: 5411 Comm: syz.1.14 Not tainted 6.12.0-rc1-syzkaller-00165-g360c1f1f24c6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50036", "url": "https://ubuntu.com/security/CVE-2024-50036", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: do not delay dst_entries_add() in dst_release() dst_entries_add() uses per-cpu data that might be freed at netns dismantle from ip6_route_net_exit() calling dst_entries_destroy() Before ip6_route_net_exit() can be called, we release all the dsts associated with this netns, via calls to dst_release(), which waits an rcu grace period before calling dst_destroy() dst_entries_add() use in dst_destroy() is racy, because dst_entries_destroy() could have been called already. Decrementing the number of dsts must happen sooner. Notes: 1) in CONFIG_XFRM case, dst_destroy() can call dst_release_immediate(child), this might also cause UAF if the child does not have DST_NOCOUNT set. IPSEC maintainers might take a look and see how to address this. 2) There is also discussion about removing this count of dst, which might happen in future kernels.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50037", "url": "https://ubuntu.com/security/CVE-2024-50037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/fbdev-dma: Only cleanup deferred I/O if necessary Commit 5a498d4d06d6 (\"drm/fbdev-dma: Only install deferred I/O if necessary\") initializes deferred I/O only if it is used. drm_fbdev_dma_fb_destroy() however calls fb_deferred_io_cleanup() unconditionally with struct fb_info.fbdefio == NULL. KASAN with the out-of-tree Apple silicon display driver posts following warning from __flush_work() of a random struct work_struct instead of the expected NULL pointer derefs. [ 22.053799] ------------[ cut here ]------------ [ 22.054832] WARNING: CPU: 2 PID: 1 at kernel/workqueue.c:4177 __flush_work+0x4d8/0x580 [ 22.056597] Modules linked in: uhid bnep uinput nls_ascii ip6_tables ip_tables i2c_dev loop fuse dm_multipath nfnetlink zram hid_magicmouse btrfs xor xor_neon brcmfmac_wcc raid6_pq hci_bcm4377 bluetooth brcmfmac hid_apple brcmutil nvmem_spmi_mfd simple_mfd_spmi dockchannel_hid cfg80211 joydev regmap_spmi nvme_apple ecdh_generic ecc macsmc_hid rfkill dwc3 appledrm snd_soc_macaudio macsmc_power nvme_core apple_isp phy_apple_atc apple_sart apple_rtkit_helper apple_dockchannel tps6598x macsmc_hwmon snd_soc_cs42l84 videobuf2_v4l2 spmi_apple_controller nvmem_apple_efuses videobuf2_dma_sg apple_z2 videobuf2_memops spi_nor panel_summit videobuf2_common asahi videodev pwm_apple apple_dcp snd_soc_apple_mca apple_admac spi_apple clk_apple_nco i2c_pasemi_platform snd_pcm_dmaengine mc i2c_pasemi_core mux_core ofpart adpdrm drm_dma_helper apple_dart apple_soc_cpufreq leds_pwm phram [ 22.073768] CPU: 2 UID: 0 PID: 1 Comm: systemd-shutdow Not tainted 6.11.2-asahi+ #asahi-dev [ 22.075612] Hardware name: Apple MacBook Pro (13-inch, M2, 2022) (DT) [ 22.077032] pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 22.078567] pc : __flush_work+0x4d8/0x580 [ 22.079471] lr : __flush_work+0x54/0x580 [ 22.080345] sp : ffffc000836ef820 [ 22.081089] x29: ffffc000836ef880 x28: 0000000000000000 x27: ffff80002ddb7128 [ 22.082678] x26: dfffc00000000000 x25: 1ffff000096f0c57 x24: ffffc00082d3e358 [ 22.084263] x23: ffff80004b7862b8 x22: dfffc00000000000 x21: ffff80005aa1d470 [ 22.085855] x20: ffff80004b786000 x19: ffff80004b7862a0 x18: 0000000000000000 [ 22.087439] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000005 [ 22.089030] x14: 1ffff800106ddf0a x13: 0000000000000000 x12: 0000000000000000 [ 22.090618] x11: ffffb800106ddf0f x10: dfffc00000000000 x9 : 1ffff800106ddf0e [ 22.092206] x8 : 0000000000000000 x7 : aaaaaaaaaaaaaaaa x6 : 0000000000000001 [ 22.093790] x5 : ffffc000836ef728 x4 : 0000000000000000 x3 : 0000000000000020 [ 22.095368] x2 : 0000000000000008 x1 : 00000000000000aa x0 : 0000000000000000 [ 22.096955] Call trace: [ 22.097505] __flush_work+0x4d8/0x580 [ 22.098330] flush_delayed_work+0x80/0xb8 [ 22.099231] fb_deferred_io_cleanup+0x3c/0x130 [ 22.100217] drm_fbdev_dma_fb_destroy+0x6c/0xe0 [drm_dma_helper] [ 22.101559] unregister_framebuffer+0x210/0x2f0 [ 22.102575] drm_fb_helper_unregister_info+0x48/0x60 [ 22.103683] drm_fbdev_dma_client_unregister+0x4c/0x80 [drm_dma_helper] [ 22.105147] drm_client_dev_unregister+0x1cc/0x230 [ 22.106217] drm_dev_unregister+0x58/0x570 [ 22.107125] apple_drm_unbind+0x50/0x98 [appledrm] [ 22.108199] component_del+0x1f8/0x3a8 [ 22.109042] dcp_platform_shutdown+0x24/0x38 [apple_dcp] [ 22.110357] platform_shutdown+0x70/0x90 [ 22.111219] device_shutdown+0x368/0x4d8 [ 22.112095] kernel_restart+0x6c/0x1d0 [ 22.112946] __arm64_sys_reboot+0x1c8/0x328 [ 22.113868] invoke_syscall+0x78/0x1a8 [ 22.114703] do_el0_svc+0x124/0x1a0 [ 22.115498] el0_svc+0x3c/0xe0 [ 22.116181] el0t_64_sync_handler+0x70/0xc0 [ 22.117110] el0t_64_sync+0x190/0x198 [ 22.117931] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50092", "url": "https://ubuntu.com/security/CVE-2024-50092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netconsole: fix wrong warning A warning is triggered when there is insufficient space in the buffer for userdata. However, this is not an issue since userdata will be sent in the next iteration. Current warning message: ------------[ cut here ]------------ WARNING: CPU: 13 PID: 3013042 at drivers/net/netconsole.c:1122 write_ext_msg+0x3b6/0x3d0 ? write_ext_msg+0x3b6/0x3d0 console_flush_all+0x1e9/0x330 The code incorrectly issues a warning when this_chunk is zero, which is a valid scenario. The warning should only be triggered when this_chunk is negative.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50038", "url": "https://ubuntu.com/security/CVE-2024-50038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xtables: avoid NFPROTO_UNSPEC where needed syzbot managed to call xt_cluster match via ebtables: WARNING: CPU: 0 PID: 11 at net/netfilter/xt_cluster.c:72 xt_cluster_mt+0x196/0x780 [..] ebt_do_table+0x174b/0x2a40 Module registers to NFPROTO_UNSPEC, but it assumes ipv4/ipv6 packet processing. As this is only useful to restrict locally terminating TCP/UDP traffic, register this for ipv4 and ipv6 family only. Pablo points out that this is a general issue, direct users of the set/getsockopt interface can call into targets/matches that were only intended for use with ip(6)tables. Check all UNSPEC matches and targets for similar issues: - matches and targets are fine except if they assume skb_network_header() is valid -- this is only true when called from inet layer: ip(6) stack pulls the ip/ipv6 header into linear data area. - targets that return XT_CONTINUE or other xtables verdicts must be restricted too, they are incompatbile with the ebtables traverser, e.g. EBT_CONTINUE is a completely different value than XT_CONTINUE. Most matches/targets are changed to register for NFPROTO_IPV4/IPV6, as they are provided for use by ip(6)tables. The MARK target is also used by arptables, so register for NFPROTO_ARP too. While at it, bail out if connbytes fails to enable the corresponding conntrack family. This change passes the selftests in iptables.git.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50039", "url": "https://ubuntu.com/security/CVE-2024-50039", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: accept TCA_STAB only for root qdisc Most qdiscs maintain their backlog using qdisc_pkt_len(skb) on the assumption it is invariant between the enqueue() and dequeue() handlers. Unfortunately syzbot can crash a host rather easily using a TBF + SFQ combination, with an STAB on SFQ [1] We can't support TCA_STAB on arbitrary level, this would require to maintain per-qdisc storage. [1] [ 88.796496] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 88.798611] #PF: supervisor read access in kernel mode [ 88.799014] #PF: error_code(0x0000) - not-present page [ 88.799506] PGD 0 P4D 0 [ 88.799829] Oops: Oops: 0000 [#1] SMP NOPTI [ 88.800569] CPU: 14 UID: 0 PID: 2053 Comm: b371744477 Not tainted 6.12.0-rc1-virtme #1117 [ 88.801107] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 88.801779] RIP: 0010:sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq [ 88.802544] Code: 0f b7 50 12 48 8d 04 d5 00 00 00 00 48 89 d6 48 29 d0 48 8b 91 c0 01 00 00 48 c1 e0 03 48 01 c2 66 83 7a 1a 00 7e c0 48 8b 3a <4c> 8b 07 4c 89 02 49 89 50 08 48 c7 47 08 00 00 00 00 48 c7 07 00 All code ======== 0:\t0f b7 50 12 \tmovzwl 0x12(%rax),%edx 4:\t48 8d 04 d5 00 00 00 \tlea 0x0(,%rdx,8),%rax b:\t00 c:\t48 89 d6 \tmov %rdx,%rsi f:\t48 29 d0 \tsub %rdx,%rax 12:\t48 8b 91 c0 01 00 00 \tmov 0x1c0(%rcx),%rdx 19:\t48 c1 e0 03 \tshl $0x3,%rax 1d:\t48 01 c2 \tadd %rax,%rdx 20:\t66 83 7a 1a 00 \tcmpw $0x0,0x1a(%rdx) 25:\t7e c0 \tjle 0xffffffffffffffe7 27:\t48 8b 3a \tmov (%rdx),%rdi 2a:*\t4c 8b 07 \tmov (%rdi),%r8\t\t<-- trapping instruction 2d:\t4c 89 02 \tmov %r8,(%rdx) 30:\t49 89 50 08 \tmov %rdx,0x8(%r8) 34:\t48 c7 47 08 00 00 00 \tmovq $0x0,0x8(%rdi) 3b:\t00 3c:\t48 \trex.W 3d:\tc7 \t.byte 0xc7 3e:\t07 \t(bad) \t... Code starting with the faulting instruction =========================================== 0:\t4c 8b 07 \tmov (%rdi),%r8 3:\t4c 89 02 \tmov %r8,(%rdx) 6:\t49 89 50 08 \tmov %rdx,0x8(%r8) a:\t48 c7 47 08 00 00 00 \tmovq $0x0,0x8(%rdi) 11:\t00 12:\t48 \trex.W 13:\tc7 \t.byte 0xc7 14:\t07 \t(bad) \t... [ 88.803721] RSP: 0018:ffff9a1f892b7d58 EFLAGS: 00000206 [ 88.804032] RAX: 0000000000000000 RBX: ffff9a1f8420c800 RCX: ffff9a1f8420c800 [ 88.804560] RDX: ffff9a1f81bc1440 RSI: 0000000000000000 RDI: 0000000000000000 [ 88.805056] RBP: ffffffffc04bb0e0 R08: 0000000000000001 R09: 00000000ff7f9a1f [ 88.805473] R10: 000000000001001b R11: 0000000000009a1f R12: 0000000000000140 [ 88.806194] R13: 0000000000000001 R14: ffff9a1f886df400 R15: ffff9a1f886df4ac [ 88.806734] FS: 00007f445601a740(0000) GS:ffff9a2e7fd80000(0000) knlGS:0000000000000000 [ 88.807225] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 88.807672] CR2: 0000000000000000 CR3: 000000050cc46000 CR4: 00000000000006f0 [ 88.808165] Call Trace: [ 88.808459] [ 88.808710] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434) [ 88.809261] ? page_fault_oops (arch/x86/mm/fault.c:715) [ 88.809561] ? exc_page_fault (./arch/x86/include/asm/irqflags.h:26 ./arch/x86/include/asm/irqflags.h:87 ./arch/x86/include/asm/irqflags.h:147 arch/x86/mm/fault.c:1489 arch/x86/mm/fault.c:1539) [ 88.809806] ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623) [ 88.810074] ? sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq [ 88.810411] sfq_reset (net/sched/sch_sfq.c:525) sch_sfq [ 88.810671] qdisc_reset (./include/linux/skbuff.h:2135 ./include/linux/skbuff.h:2441 ./include/linux/skbuff.h:3304 ./include/linux/skbuff.h:3310 net/sched/sch_g ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50040", "url": "https://ubuntu.com/security/CVE-2024-50040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: igb: Do not bring the device up after non-fatal error Commit 004d25060c78 (\"igb: Fix igb_down hung on surprise removal\") changed igb_io_error_detected() to ignore non-fatal pcie errors in order to avoid hung task that can happen when igb_down() is called multiple times. This caused an issue when processing transient non-fatal errors. igb_io_resume(), which is called after igb_io_error_detected(), assumes that device is brought down by igb_io_error_detected() if the interface is up. This resulted in panic with stacktrace below. [ T3256] igb 0000:09:00.0 haeth0: igb: haeth0 NIC Link is Down [ T292] pcieport 0000:00:1c.5: AER: Uncorrected (Non-Fatal) error received: 0000:09:00.0 [ T292] igb 0000:09:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, (Requester ID) [ T292] igb 0000:09:00.0: device [8086:1537] error status/mask=00004000/00000000 [ T292] igb 0000:09:00.0: [14] CmpltTO [ 200.105524,009][ T292] igb 0000:09:00.0: AER: TLP Header: 00000000 00000000 00000000 00000000 [ T292] pcieport 0000:00:1c.5: AER: broadcast error_detected message [ T292] igb 0000:09:00.0: Non-correctable non-fatal error reported. [ T292] pcieport 0000:00:1c.5: AER: broadcast mmio_enabled message [ T292] pcieport 0000:00:1c.5: AER: broadcast resume message [ T292] ------------[ cut here ]------------ [ T292] kernel BUG at net/core/dev.c:6539! [ T292] invalid opcode: 0000 [#1] PREEMPT SMP [ T292] RIP: 0010:napi_enable+0x37/0x40 [ T292] Call Trace: [ T292] [ T292] ? die+0x33/0x90 [ T292] ? do_trap+0xdc/0x110 [ T292] ? napi_enable+0x37/0x40 [ T292] ? do_error_trap+0x70/0xb0 [ T292] ? napi_enable+0x37/0x40 [ T292] ? napi_enable+0x37/0x40 [ T292] ? exc_invalid_op+0x4e/0x70 [ T292] ? napi_enable+0x37/0x40 [ T292] ? asm_exc_invalid_op+0x16/0x20 [ T292] ? napi_enable+0x37/0x40 [ T292] igb_up+0x41/0x150 [ T292] igb_io_resume+0x25/0x70 [ T292] report_resume+0x54/0x70 [ T292] ? report_frozen_detected+0x20/0x20 [ T292] pci_walk_bus+0x6c/0x90 [ T292] ? aer_print_port_info+0xa0/0xa0 [ T292] pcie_do_recovery+0x22f/0x380 [ T292] aer_process_err_devices+0x110/0x160 [ T292] aer_isr+0x1c1/0x1e0 [ T292] ? disable_irq_nosync+0x10/0x10 [ T292] irq_thread_fn+0x1a/0x60 [ T292] irq_thread+0xe3/0x1a0 [ T292] ? irq_set_affinity_notifier+0x120/0x120 [ T292] ? irq_affinity_notify+0x100/0x100 [ T292] kthread+0xe2/0x110 [ T292] ? kthread_complete_and_exit+0x20/0x20 [ T292] ret_from_fork+0x2d/0x50 [ T292] ? kthread_complete_and_exit+0x20/0x20 [ T292] ret_from_fork_asm+0x11/0x20 [ T292] To fix this issue igb_io_resume() checks if the interface is running and the device is not down this means igb_io_error_detected() did not bring the device down and there is no need to bring it up.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50041", "url": "https://ubuntu.com/security/CVE-2024-50041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: Fix macvlan leak by synchronizing access to mac_filter_hash This patch addresses a macvlan leak issue in the i40e driver caused by concurrent access to vsi->mac_filter_hash. The leak occurs when multiple threads attempt to modify the mac_filter_hash simultaneously, leading to inconsistent state and potential memory leaks. To fix this, we now wrap the calls to i40e_del_mac_filter() and zeroing vf->default_lan_addr.addr with spin_lock/unlock_bh(&vsi->mac_filter_hash_lock), ensuring atomic operations and preventing concurrent access. Additionally, we add lockdep_assert_held(&vsi->mac_filter_hash_lock) in i40e_add_mac_filter() to help catch similar issues in the future. Reproduction steps: 1. Spawn VFs and configure port vlan on them. 2. Trigger concurrent macvlan operations (e.g., adding and deleting \tportvlan and/or mac filters). 3. Observe the potential memory leak and inconsistent state in the \tmac_filter_hash. This synchronization ensures the integrity of the mac_filter_hash and prevents the described leak.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50042", "url": "https://ubuntu.com/security/CVE-2024-50042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix increasing MSI-X on VF Increasing MSI-X value on a VF leads to invalid memory operations. This is caused by not reallocating some arrays. Reproducer: modprobe ice echo 0 > /sys/bus/pci/devices/$PF_PCI/sriov_drivers_autoprobe echo 1 > /sys/bus/pci/devices/$PF_PCI/sriov_numvfs echo 17 > /sys/bus/pci/devices/$VF0_PCI/sriov_vf_msix_count Default MSI-X is 16, so 17 and above triggers this issue. KASAN reports: BUG: KASAN: slab-out-of-bounds in ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] Read of size 8 at addr ffff8888b937d180 by task bash/28433 (...) Call Trace: (...) ? ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] kasan_report+0xed/0x120 ? ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] ice_vsi_cfg_def+0x3360/0x4770 [ice] ? mutex_unlock+0x83/0xd0 ? __pfx_ice_vsi_cfg_def+0x10/0x10 [ice] ? __pfx_ice_remove_vsi_lkup_fltr+0x10/0x10 [ice] ice_vsi_cfg+0x7f/0x3b0 [ice] ice_vf_reconfig_vsi+0x114/0x210 [ice] ice_sriov_set_msix_vec_count+0x3d0/0x960 [ice] sriov_vf_msix_count_store+0x21c/0x300 (...) Allocated by task 28201: (...) ice_vsi_cfg_def+0x1c8e/0x4770 [ice] ice_vsi_cfg+0x7f/0x3b0 [ice] ice_vsi_setup+0x179/0xa30 [ice] ice_sriov_configure+0xcaa/0x1520 [ice] sriov_numvfs_store+0x212/0x390 (...) To fix it, use ice_vsi_rebuild() instead of ice_vf_reconfig_vsi(). This causes the required arrays to be reallocated taking the new queue count into account (ice_vsi_realloc_stat_arrays()). Set req_txq and req_rxq before ice_vsi_rebuild(), so that realloc uses the newly set queue count. Additionally, ice_vsi_rebuild() does not remove VSI filters (ice_fltr_remove_all()), so ice_vf_init_host_cfg() is no longer necessary.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50093", "url": "https://ubuntu.com/security/CVE-2024-50093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: intel: int340x: processor: Fix warning during module unload The processor_thermal driver uses pcim_device_enable() to enable a PCI device, which means the device will be automatically disabled on driver detach. Thus there is no need to call pci_disable_device() again on it. With recent PCI device resource management improvements, e.g. commit f748a07a0b64 (\"PCI: Remove legacy pcim_release()\"), this problem is exposed and triggers the warining below. [ 224.010735] proc_thermal_pci 0000:00:04.0: disabling already-disabled device [ 224.010747] WARNING: CPU: 8 PID: 4442 at drivers/pci/pci.c:2250 pci_disable_device+0xe5/0x100 ... [ 224.010844] Call Trace: [ 224.010845] [ 224.010847] ? show_regs+0x6d/0x80 [ 224.010851] ? __warn+0x8c/0x140 [ 224.010854] ? pci_disable_device+0xe5/0x100 [ 224.010856] ? report_bug+0x1c9/0x1e0 [ 224.010859] ? handle_bug+0x46/0x80 [ 224.010862] ? exc_invalid_op+0x1d/0x80 [ 224.010863] ? asm_exc_invalid_op+0x1f/0x30 [ 224.010867] ? pci_disable_device+0xe5/0x100 [ 224.010869] ? pci_disable_device+0xe5/0x100 [ 224.010871] ? kfree+0x21a/0x2b0 [ 224.010873] pcim_disable_device+0x20/0x30 [ 224.010875] devm_action_release+0x16/0x20 [ 224.010878] release_nodes+0x47/0xc0 [ 224.010880] devres_release_all+0x9f/0xe0 [ 224.010883] device_unbind_cleanup+0x12/0x80 [ 224.010885] device_release_driver_internal+0x1ca/0x210 [ 224.010887] driver_detach+0x4e/0xa0 [ 224.010889] bus_remove_driver+0x6f/0xf0 [ 224.010890] driver_unregister+0x35/0x60 [ 224.010892] pci_unregister_driver+0x44/0x90 [ 224.010894] proc_thermal_pci_driver_exit+0x14/0x5f0 [processor_thermal_device_pci] ... [ 224.010921] ---[ end trace 0000000000000000 ]--- Remove the excess pci_disable_device() calls. [ rjw: Subject and changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50043", "url": "https://ubuntu.com/security/CVE-2024-50043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix possible badness in FREE_STATEID When multiple FREE_STATEIDs are sent for the same delegation stateid, it can lead to a possible either use-after-free or counter refcount underflow errors. In nfsd4_free_stateid() under the client lock we find a delegation stateid, however the code drops the lock before calling nfs4_put_stid(), that allows another FREE_STATE to find the stateid again. The first one will proceed to then free the stateid which leads to either use-after-free or decrementing already zeroed counter.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50044", "url": "https://ubuntu.com/security/CVE-2024-50044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change rfcomm_sk_state_change attempts to use sock_lock so it must never be called with it locked but rfcomm_sock_ioctl always attempt to lock it causing the following trace: ====================================================== WARNING: possible circular locking dependency detected 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Not tainted ------------------------------------------------------ syz-executor386/5093 is trying to acquire lock: ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1671 [inline] ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73 but task is already holding lock: ffff88807badfd28 (&d->lock){+.+.}-{3:3}, at: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50045", "url": "https://ubuntu.com/security/CVE-2024-50045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: br_netfilter: fix panic with metadata_dst skb Fix a kernel panic in the br_netfilter module when sending untagged traffic via a VxLAN device. This happens during the check for fragmentation in br_nf_dev_queue_xmit. It is dependent on: 1) the br_netfilter module being loaded; 2) net.bridge.bridge-nf-call-iptables set to 1; 3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port; 4) untagged frames with size higher than the VxLAN MTU forwarded/flooded When forwarding the untagged packet to the VxLAN bridge port, before the netfilter hooks are called, br_handle_egress_vlan_tunnel is called and changes the skb_dst to the tunnel dst. The tunnel_dst is a metadata type of dst, i.e., skb_valid_dst(skb) is false, and metadata->dst.dev is NULL. Then in the br_netfilter hooks, in br_nf_dev_queue_xmit, there's a check for frames that needs to be fragmented: frames with higher MTU than the VxLAN device end up calling br_nf_ip_fragment, which in turns call ip_skb_dst_mtu. The ip_dst_mtu tries to use the skb_dst(skb) as if it was a valid dst with valid dst->dev, thus the crash. This case was never supported in the first place, so drop the packet instead. PING 10.0.0.2 (10.0.0.2) from 0.0.0.0 h1-eth0: 2000(2028) bytes of data. [ 176.291791] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000110 [ 176.292101] Mem abort info: [ 176.292184] ESR = 0x0000000096000004 [ 176.292322] EC = 0x25: DABT (current EL), IL = 32 bits [ 176.292530] SET = 0, FnV = 0 [ 176.292709] EA = 0, S1PTW = 0 [ 176.292862] FSC = 0x04: level 0 translation fault [ 176.293013] Data abort info: [ 176.293104] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 176.293488] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 176.293787] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 176.293995] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043ef5000 [ 176.294166] [0000000000000110] pgd=0000000000000000, p4d=0000000000000000 [ 176.294827] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 176.295252] Modules linked in: vxlan ip6_udp_tunnel udp_tunnel veth br_netfilter bridge stp llc ipv6 crct10dif_ce [ 176.295923] CPU: 0 PID: 188 Comm: ping Not tainted 6.8.0-rc3-g5b3fbd61b9d1 #2 [ 176.296314] Hardware name: linux,dummy-virt (DT) [ 176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 176.296808] pc : br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.297382] lr : br_nf_dev_queue_xmit+0x2ac/0x4ec [br_netfilter] [ 176.297636] sp : ffff800080003630 [ 176.297743] x29: ffff800080003630 x28: 0000000000000008 x27: ffff6828c49ad9f8 [ 176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24: 00000000000003e8 [ 176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21: ffff6828c3b16d28 [ 176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18: 0000000000000014 [ 176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15: 0000000095744632 [ 176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12: ffffb7e137926a70 [ 176.299574] x11: 0000000000000001 x10: ffff6828c3f1c898 x9 : 0000000000000000 [ 176.300049] x8 : ffff6828c49bf070 x7 : 0008460f18d5f20e x6 : f20e0100bebafeca [ 176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 : 0000000000000000 [ 176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 : ffff6828c7f918f0 [ 176.300889] Call trace: [ 176.301123] br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.301411] br_nf_post_routing+0x2a8/0x3e4 [br_netfilter] [ 176.301703] nf_hook_slow+0x48/0x124 [ 176.302060] br_forward_finish+0xc8/0xe8 [bridge] [ 176.302371] br_nf_hook_thresh+0x124/0x134 [br_netfilter] [ 176.302605] br_nf_forward_finish+0x118/0x22c [br_netfilter] [ 176.302824] br_nf_forward_ip.part.0+0x264/0x290 [br_netfilter] [ 176.303136] br_nf_forward+0x2b8/0x4e0 [br_netfilter] [ 176.303359] nf_hook_slow+0x48/0x124 [ 176.303 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50094", "url": "https://ubuntu.com/security/CVE-2024-50094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sfc: Don't invoke xdp_do_flush() from netpoll. Yury reported a crash in the sfc driver originated from netpoll_send_udp(). The netconsole sends a message and then netpoll invokes the driver's NAPI function with a budget of zero. It is dedicated to allow driver to free TX resources, that it may have used while sending the packet. In the netpoll case the driver invokes xdp_do_flush() unconditionally, leading to crash because bpf_net_context was never assigned. Invoke xdp_do_flush() only if budget is not zero.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50188", "url": "https://ubuntu.com/security/CVE-2024-50188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: dp83869: fix memory corruption when enabling fiber When configuring the fiber port, the DP83869 PHY driver incorrectly calls linkmode_set_bit() with a bit mask (1 << 10) rather than a bit number (10). This corrupts some other memory location -- in case of arm64 the priv pointer in the same structure. Since the advertising flags are updated from supported at the end of the function the incorrect line isn't needed at all and can be removed.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50046", "url": "https://ubuntu.com/security/CVE-2024-50046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies() On the node of an NFS client, some files saved in the mountpoint of the NFS server were copied to another location of the same NFS server. Accidentally, the nfs42_complete_copies() got a NULL-pointer dereference crash with the following syslog: [232064.838881] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232064.839360] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232066.588183] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 [232066.588586] Mem abort info: [232066.588701] ESR = 0x0000000096000007 [232066.588862] EC = 0x25: DABT (current EL), IL = 32 bits [232066.589084] SET = 0, FnV = 0 [232066.589216] EA = 0, S1PTW = 0 [232066.589340] FSC = 0x07: level 3 translation fault [232066.589559] Data abort info: [232066.589683] ISV = 0, ISS = 0x00000007 [232066.589842] CM = 0, WnR = 0 [232066.589967] user pgtable: 64k pages, 48-bit VAs, pgdp=00002000956ff400 [232066.590231] [0000000000000058] pgd=08001100ae100003, p4d=08001100ae100003, pud=08001100ae100003, pmd=08001100b3c00003, pte=0000000000000000 [232066.590757] Internal error: Oops: 96000007 [#1] SMP [232066.590958] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm vhost_net vhost vhost_iotlb tap tun ipt_rpfilter xt_multiport ip_set_hash_ip ip_set_hash_net xfrm_interface xfrm6_tunnel tunnel4 tunnel6 esp4 ah4 wireguard libcurve25519_generic veth xt_addrtype xt_set nf_conntrack_netlink ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_bitmap_port ip_set_hash_ipport dummy ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs iptable_filter sch_ingress nfnetlink_cttimeout vport_gre ip_gre ip_tunnel gre vport_geneve geneve vport_vxlan vxlan ip6_udp_tunnel udp_tunnel openvswitch nf_conncount dm_round_robin dm_service_time dm_multipath xt_nat xt_MASQUERADE nft_chain_nat nf_nat xt_mark xt_conntrack xt_comment nft_compat nft_counter nf_tables nfnetlink ocfs2 ocfs2_nodemanager ocfs2_stackglue iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_ssif nbd overlay 8021q garp mrp bonding tls rfkill sunrpc ext4 mbcache jbd2 [232066.591052] vfat fat cas_cache cas_disk ses enclosure scsi_transport_sas sg acpi_ipmi ipmi_si ipmi_devintf ipmi_msghandler ip_tables vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio dm_mirror dm_region_hash dm_log dm_mod nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc fuse xfs libcrc32c ast drm_vram_helper qla2xxx drm_kms_helper syscopyarea crct10dif_ce sysfillrect ghash_ce sysimgblt sha2_ce fb_sys_fops cec sha256_arm64 sha1_ce drm_ttm_helper ttm nvme_fc igb sbsa_gwdt nvme_fabrics drm nvme_core i2c_algo_bit i40e scsi_transport_fc megaraid_sas aes_neon_bs [232066.596953] CPU: 6 PID: 4124696 Comm: 10.253.166.125- Kdump: loaded Not tainted 5.15.131-9.cl9_ocfs2.aarch64 #1 [232066.597356] Hardware name: Great Wall .\\x93\\x8e...RF6260 V5/GWMSSE2GL1T, BIOS T656FBE_V3.0.18 2024-01-06 [232066.597721] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [232066.598034] pc : nfs4_reclaim_open_state+0x220/0x800 [nfsv4] [232066.598327] lr : nfs4_reclaim_open_state+0x12c/0x800 [nfsv4] [232066.598595] sp : ffff8000f568fc70 [232066.598731] x29: ffff8000f568fc70 x28: 0000000000001000 x27: ffff21003db33000 [232066.599030] x26: ffff800005521ae0 x25: ffff0100f98fa3f0 x24: 0000000000000001 [232066.599319] x23: ffff800009920008 x22: ffff21003db33040 x21: ffff21003db33050 [232066.599628] x20: ffff410172fe9e40 x19: ffff410172fe9e00 x18: 0000000000000000 [232066.599914] x17: 0000000000000000 x16: 0000000000000004 x15: 0000000000000000 [232066.600195] x14: 0000000000000000 x13: ffff800008e685a8 x12: 00000000eac0c6e6 [232066.600498] x11: 00000000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50190", "url": "https://ubuntu.com/security/CVE-2024-50190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix memleak in ice_init_tx_topology() Fix leak of the FW blob (DDP pkg). Make ice_cfg_tx_topo() const-correct, so ice_init_tx_topology() can avoid copying whole FW blob. Copy just the topology section, and only when needed. Reuse the buffer allocated for the read of the current topology. This was found by kmemleak, with the following trace for each PF: [] kmemdup_noprof+0x1d/0x50 [] ice_init_ddp_config+0x100/0x220 [ice] [] ice_init_dev+0x6f/0x200 [ice] [] ice_init+0x29/0x560 [ice] [] ice_probe+0x21d/0x310 [ice] Constify ice_cfg_tx_topo() @buf parameter. This cascades further down to few more functions.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50180", "url": "https://ubuntu.com/security/CVE-2024-50180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: sisfb: Fix strbuf array overflow The values of the variables xres and yres are placed in strbuf. These variables are obtained from strbuf1. The strbuf1 array contains digit characters and a space if the array contains non-digit characters. Then, when executing sprintf(strbuf, \"%ux%ux8\", xres, yres); more than 16 bytes will be written to strbuf. It is suggested to increase the size of the strbuf array to 24. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06: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": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50048", "url": "https://ubuntu.com/security/CVE-2024-50048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: Fix a NULL pointer dereference issue in fbcon_putcs syzbot has found a NULL pointer dereference bug in fbcon. Here is the simplified C reproducer: struct param { \tuint8_t type; \tstruct tiocl_selection ts; }; int main() { \tstruct fb_con2fbmap con2fb; \tstruct param param; \tint fd = open(\"/dev/fb1\", 0, 0); \tcon2fb.console = 0x19; \tcon2fb.framebuffer = 0; \tioctl(fd, FBIOPUT_CON2FBMAP, &con2fb); \tparam.type = 2; \tparam.ts.xs = 0; param.ts.ys = 0; \tparam.ts.xe = 0; param.ts.ye = 0; \tparam.ts.sel_mode = 0; \tint fd1 = open(\"/dev/tty1\", O_RDWR, 0); \tioctl(fd1, TIOCLINUX, ¶m); \tcon2fb.console = 1; \tcon2fb.framebuffer = 0; \tioctl(fd, FBIOPUT_CON2FBMAP, &con2fb); \treturn 0; } After calling ioctl(fd1, TIOCLINUX, ¶m), the subsequent ioctl(fd, FBIOPUT_CON2FBMAP, &con2fb) causes the kernel to follow a different execution path: set_con2fb_map -> con2fb_init_display -> fbcon_set_disp -> redraw_screen -> hide_cursor -> clear_selection -> highlight -> invert_screen -> do_update_region -> fbcon_putcs -> ops->putcs Since ops->putcs is a NULL pointer, this leads to a kernel panic. To prevent this, we need to call set_blitting_type() within set_con2fb_map() to properly initialize ops->putcs.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50049", "url": "https://ubuntu.com/security/CVE-2024-50049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before dereferencing se [WHAT & HOW] se is null checked previously in the same function, indicating it might be null; therefore, it must be checked when used again. This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50090", "url": "https://ubuntu.com/security/CVE-2024-50090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/oa: Fix overflow in oa batch buffer By default xe_bb_create_job() appends a MI_BATCH_BUFFER_END to batch buffer, this is not a problem if batch buffer is only used once but oa reuses the batch buffer for the same metric and at each call it appends a MI_BATCH_BUFFER_END, printing the warning below and then overflowing. [ 381.072016] ------------[ cut here ]------------ [ 381.072019] xe 0000:00:02.0: [drm] Assertion `bb->len * 4 + bb_prefetch(q->gt) <= size` failed! platform: LUNARLAKE subplatform: 1 graphics: Xe2_LPG / Xe2_HPG 20.04 step B0 media: Xe2_LPM / Xe2_HPM 20.00 step B0 tile: 0 VRAM 0 B GT: 0 type 1 So here checking if batch buffer already have MI_BATCH_BUFFER_END if not append it. v2: - simply fix, suggestion from Ashutosh (cherry picked from commit 9ba0e0f30ca42a98af3689460063edfb6315718a)", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50183", "url": "https://ubuntu.com/security/CVE-2024-50183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV instance Deleting an NPIV instance requires all fabric ndlps to be released before an NPIV's resources can be torn down. Failure to release fabric ndlps beforehand opens kref imbalance race conditions. Fix by forcing the DA_ID to complete synchronously with usage of wait_queue.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50055", "url": "https://ubuntu.com/security/CVE-2024-50055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: driver core: bus: Fix double free in driver API bus_register() For bus_register(), any error which happens after kset_register() will cause that @priv are freed twice, fixed by setting @priv with NULL after the first free.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50091", "url": "https://ubuntu.com/security/CVE-2024-50091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm vdo: don't refer to dedupe_context after releasing it Clear the dedupe_context pointer in a data_vio whenever ownership of the context is lost, so that vdo can't examine it accidentally.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50056", "url": "https://ubuntu.com/security/CVE-2024-50056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: Fix ERR_PTR dereference in uvc_v4l2.c Fix potential dereferencing of ERR_PTR() in find_format_by_pix() and uvc_v4l2_enum_format(). Fix the following smatch errors: drivers/usb/gadget/function/uvc_v4l2.c:124 find_format_by_pix() error: 'fmtdesc' dereferencing possible ERR_PTR() drivers/usb/gadget/function/uvc_v4l2.c:392 uvc_v4l2_enum_format() error: 'fmtdesc' dereferencing possible ERR_PTR() Also, fix similar issue in uvc_v4l2_try_format() for potential dereferencing of ERR_PTR().", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50184", "url": "https://ubuntu.com/security/CVE-2024-50184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_pmem: Check device status before requesting flush If a pmem device is in a bad status, the driver side could wait for host ack forever in virtio_pmem_flush(), causing the system to hang. So add a status check in the beginning of virtio_pmem_flush() to return early if the device is not activated.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50057", "url": "https://ubuntu.com/security/CVE-2024-50057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: tipd: Free IRQ only if it was requested before In polling mode, if no IRQ was requested there is no need to free it. Call devm_free_irq() only if client->irq is set. This fixes the warning caused by the tps6598x module removal: WARNING: CPU: 2 PID: 333 at kernel/irq/devres.c:144 devm_free_irq+0x80/0x8c ... ... Call trace: devm_free_irq+0x80/0x8c tps6598x_remove+0x28/0x88 [tps6598x] i2c_device_remove+0x2c/0x9c device_remove+0x4c/0x80 device_release_driver_internal+0x1cc/0x228 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 i2c_del_driver+0x54/0x64 tps6598x_i2c_driver_exit+0x18/0xc3c [tps6598x] __arm64_sys_delete_module+0x184/0x264 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc8/0xe8 do_el0_svc+0x20/0x2c el0_svc+0x28/0x98 el0t_64_sync_handler+0x13c/0x158 el0t_64_sync+0x190/0x194", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50058", "url": "https://ubuntu.com/security/CVE-2024-50058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: protect uart_port_dtr_rts() in uart_shutdown() too Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part 3) added few uport == NULL checks. It added one to uart_shutdown(), so the commit assumes, uport can be NULL in there. But right after that protection, there is an unprotected \"uart_port_dtr_rts(uport, false);\" call. That is invoked only if HUPCL is set, so I assume that is the reason why we do not see lots of these reports. Or it cannot be NULL at this point at all for some reason :P. Until the above is investigated, stay on the safe side and move this dereference to the if too. I got this inconsistency from Coverity under CID 1585130. Thanks.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50181", "url": "https://ubuntu.com/security/CVE-2024-50181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: imx: Remove CLK_SET_PARENT_GATE for DRAM mux for i.MX7D For i.MX7D DRAM related mux clock, the clock source change should ONLY be done done in low level asm code without accessing DRAM, and then calling clk API to sync the HW clock status with clk tree, it should never touch real clock source switch via clk API, so CLK_SET_PARENT_GATE flag should NOT be added, otherwise, DRAM's clock parent will be disabled when DRAM is active, and system will hang.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50059", "url": "https://ubuntu.com/security/CVE-2024-50059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntb: ntb_hw_switchtec: Fix use after free vulnerability in switchtec_ntb_remove due to race condition In the switchtec_ntb_add function, it can call switchtec_ntb_init_sndev function, then &sndev->check_link_status_work is bound with check_link_status_work. switchtec_ntb_link_notification may be called to start the work. If we remove the module which will call switchtec_ntb_remove to make cleanup, it will free sndev through kfree(sndev), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | check_link_status_work switchtec_ntb_remove | kfree(sndev); | | if (sndev->link_force_down) | // use sndev Fix it by ensuring that the work is canceled before proceeding with the cleanup in switchtec_ntb_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50060", "url": "https://ubuntu.com/security/CVE-2024-50060", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring: check if we need to reschedule during overflow flush In terms of normal application usage, this list will always be empty. And if an application does overflow a bit, it'll have a few entries. However, nothing obviously prevents syzbot from running a test case that generates a ton of overflow entries, and then flushing them can take quite a while. Check for needing to reschedule while flushing, and drop our locks and do so if necessary. There's no state to maintain here as overflows always prune from head-of-list, hence it's fine to drop and reacquire the locks at the end of the loop.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50061", "url": "https://ubuntu.com/security/CVE-2024-50061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: cdns: Fix use after free vulnerability in cdns_i3c_master Driver Due to Race Condition In the cdns_i3c_master_probe function, &master->hj_work is bound with cdns_i3c_master_hj. And cdns_i3c_master_interrupt can call cnds_i3c_master_demux_ibis function to start the work. If we remove the module which will call cdns_i3c_master_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | cdns_i3c_master_hj cdns_i3c_master_remove | i3c_master_unregister(&master->base) | device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in cdns_i3c_master_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50062", "url": "https://ubuntu.com/security/CVE-2024-50062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-srv: Avoid null pointer deref during path establishment For RTRS path establishment, RTRS client initiates and completes con_num of connections. After establishing all its connections, the information is exchanged between the client and server through the info_req message. During this exchange, it is essential that all connections have been established, and the state of the RTRS srv path is CONNECTED. So add these sanity checks, to make sure we detect and abort process in error scenarios to avoid null pointer deref.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50095", "url": "https://ubuntu.com/security/CVE-2024-50095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mad: Improve handling of timed out WRs of mad agent Current timeout handler of mad agent acquires/releases mad_agent_priv lock for every timed out WRs. This causes heavy locking contention when higher no. of WRs are to be handled inside timeout handler. This leads to softlockup with below trace in some use cases where rdma-cm path is used to establish connection between peer nodes Trace: ----- BUG: soft lockup - CPU#4 stuck for 26s! [kworker/u128:3:19767] CPU: 4 PID: 19767 Comm: kworker/u128:3 Kdump: loaded Tainted: G OE ------- --- 5.14.0-427.13.1.el9_4.x86_64 #1 Hardware name: Dell Inc. PowerEdge R740/01YM03, BIOS 2.4.8 11/26/2019 Workqueue: ib_mad1 timeout_sends [ib_core] RIP: 0010:__do_softirq+0x78/0x2ac RSP: 0018:ffffb253449e4f98 EFLAGS: 00000246 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 000000000000001f RDX: 000000000000001d RSI: 000000003d1879ab RDI: fff363b66fd3a86b RBP: ffffb253604cbcd8 R08: 0000009065635f3b R09: 0000000000000000 R10: 0000000000000040 R11: ffffb253449e4ff8 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000040 FS: 0000000000000000(0000) GS:ffff8caa1fc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd9ec9db900 CR3: 0000000891934006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? __irq_exit_rcu+0xa1/0xc0 ? watchdog_timer_fn+0x1b2/0x210 ? __pfx_watchdog_timer_fn+0x10/0x10 ? __hrtimer_run_queues+0x127/0x2c0 ? hrtimer_interrupt+0xfc/0x210 ? __sysvec_apic_timer_interrupt+0x5c/0x110 ? sysvec_apic_timer_interrupt+0x37/0x90 ? asm_sysvec_apic_timer_interrupt+0x16/0x20 ? __do_softirq+0x78/0x2ac ? __do_softirq+0x60/0x2ac __irq_exit_rcu+0xa1/0xc0 sysvec_call_function_single+0x72/0x90 asm_sysvec_call_function_single+0x16/0x20 RIP: 0010:_raw_spin_unlock_irq+0x14/0x30 RSP: 0018:ffffb253604cbd88 EFLAGS: 00000247 RAX: 000000000001960d RBX: 0000000000000002 RCX: ffff8cad2a064800 RDX: 000000008020001b RSI: 0000000000000001 RDI: ffff8cad5d39f66c RBP: ffff8cad5d39f600 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8caa443e0c00 R11: ffffb253604cbcd8 R12: ffff8cacb8682538 R13: 0000000000000005 R14: ffffb253604cbd90 R15: ffff8cad5d39f66c cm_process_send_error+0x122/0x1d0 [ib_cm] timeout_sends+0x1dd/0x270 [ib_core] process_one_work+0x1e2/0x3b0 ? __pfx_worker_thread+0x10/0x10 worker_thread+0x50/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xdd/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x50 Simplified timeout handler by creating local list of timed out WRs and invoke send handler post creating the list. The new method acquires/ releases lock once to fetch the list and hence helps to reduce locking contetiong when processing higher no. of WRs", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50063", "url": "https://ubuntu.com/security/CVE-2024-50063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Prevent tail call between progs attached to different hooks bpf progs can be attached to kernel functions, and the attached functions can take different parameters or return different return values. If prog attached to one kernel function tail calls prog attached to another kernel function, the ctx access or return value verification could be bypassed. For example, if prog1 is attached to func1 which takes only 1 parameter and prog2 is attached to func2 which takes two parameters. Since verifier assumes the bpf ctx passed to prog2 is constructed based on func2's prototype, verifier allows prog2 to access the second parameter from the bpf ctx passed to it. The problem is that verifier does not prevent prog1 from passing its bpf ctx to prog2 via tail call. In this case, the bpf ctx passed to prog2 is constructed from func1 instead of func2, that is, the assumption for ctx access verification is bypassed. Another example, if BPF LSM prog1 is attached to hook file_alloc_security, and BPF LSM prog2 is attached to hook bpf_lsm_audit_rule_known. Verifier knows the return value rules for these two hooks, e.g. it is legal for bpf_lsm_audit_rule_known to return positive number 1, and it is illegal for file_alloc_security to return positive number. So verifier allows prog2 to return positive number 1, but does not allow prog1 to return positive number. The problem is that verifier does not prevent prog1 from calling prog2 via tail call. In this case, prog2's return value 1 will be used as the return value for prog1's hook file_alloc_security. That is, the return value rule is bypassed. This patch adds restriction for tail call to prevent such bypasses.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50191", "url": "https://ubuntu.com/security/CVE-2024-50191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: don't set SB_RDONLY after filesystem errors When the filesystem is mounted with errors=remount-ro, we were setting SB_RDONLY flag to stop all filesystem modifications. We knew this misses proper locking (sb->s_umount) and does not go through proper filesystem remount procedure but it has been the way this worked since early ext2 days and it was good enough for catastrophic situation damage mitigation. Recently, syzbot has found a way (see link) to trigger warnings in filesystem freezing because the code got confused by SB_RDONLY changing under its hands. Since these days we set EXT4_FLAGS_SHUTDOWN on the superblock which is enough to stop all filesystem modifications, modifying SB_RDONLY shouldn't be needed. So stop doing that.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50064", "url": "https://ubuntu.com/security/CVE-2024-50064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: zram: free secondary algorithms names We need to kfree() secondary algorithms names when reset zram device that had multi-streams, otherwise we leak memory. [senozhatsky@chromium.org: kfree(NULL) is legal] Link: https://lkml.kernel.org/r/20240917013021.868769-1-senozhatsky@chromium.org", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50065", "url": "https://ubuntu.com/security/CVE-2024-50065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Change to non-blocking allocation in ntfs_d_hash d_hash is done while under \"rcu-walk\" and should not sleep. __get_name() allocates using GFP_KERNEL, having the possibility to sleep when under memory pressure. Change the allocation to GFP_NOWAIT.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50089", "url": "https://ubuntu.com/security/CVE-2024-50089", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-49863", "url": "https://ubuntu.com/security/CVE-2024-49863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost/scsi: null-ptr-dereference in vhost_scsi_get_req() Since commit 3f8ca2e115e5 (\"vhost/scsi: Extract common handling code from control queue handler\") a null pointer dereference bug can be triggered when guest sends an SCSI AN request. In vhost_scsi_ctl_handle_vq(), `vc.target` is assigned with `&v_req.tmf.lun[1]` within a switch-case block and is then passed to vhost_scsi_get_req() which extracts `vc->req` and `tpg`. However, for a `VIRTIO_SCSI_T_AN_*` request, tpg is not required, so `vc.target` is set to NULL in this branch. Later, in vhost_scsi_get_req(), `vc->target` is dereferenced without being checked, leading to a null pointer dereference bug. This bug can be triggered from guest. When this bug occurs, the vhost_worker process is killed while holding `vq->mutex` and the corresponding tpg will remain occupied indefinitely. Below is the KASAN report: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 PID: 840 Comm: poc Not tainted 6.10.0+ #1 Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:vhost_scsi_get_req+0x165/0x3a0 Code: 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 02 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 65 30 4c 89 e2 48 c1 ea 03 <0f> b6 04 02 4c 89 e2 83 e2 07 38 d0 7f 08 84 c0 0f 85 be 01 00 00 RSP: 0018:ffff888017affb50 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffff88801b000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888017affcb8 RBP: ffff888017affb80 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff888017affc88 R14: ffff888017affd1c R15: ffff888017993000 FS: 000055556e076500(0000) GS:ffff88806b100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200027c0 CR3: 0000000010ed0004 CR4: 0000000000370ef0 Call Trace: ? show_regs+0x86/0xa0 ? die_addr+0x4b/0xd0 ? exc_general_protection+0x163/0x260 ? asm_exc_general_protection+0x27/0x30 ? vhost_scsi_get_req+0x165/0x3a0 vhost_scsi_ctl_handle_vq+0x2a4/0xca0 ? __pfx_vhost_scsi_ctl_handle_vq+0x10/0x10 ? __switch_to+0x721/0xeb0 ? __schedule+0xda5/0x5710 ? __kasan_check_write+0x14/0x30 ? _raw_spin_lock+0x82/0xf0 vhost_scsi_ctl_handle_kick+0x52/0x90 vhost_run_work_list+0x134/0x1b0 vhost_task_fn+0x121/0x350 ... ---[ end trace 0000000000000000 ]--- Let's add a check in vhost_scsi_get_req. [whitespace fixes]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49864", "url": "https://ubuntu.com/security/CVE-2024-49864", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix a race between socket set up and I/O thread creation In rxrpc_open_socket(), it sets up the socket and then sets up the I/O thread that will handle it. This is a problem, however, as there's a gap between the two phases in which a packet may come into rxrpc_encap_rcv() from the UDP packet but we oops when trying to wake the not-yet created I/O thread. As a quick fix, just make rxrpc_encap_rcv() discard the packet if there's no I/O thread yet. A better, but more intrusive fix would perhaps be to rearrange things such that the socket creation is done by the I/O thread.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49865", "url": "https://ubuntu.com/security/CVE-2024-49865", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: move xa_alloc to prevent UAF Evil user can guess the next id of the vm before the ioctl completes and then call vm destroy ioctl to trigger UAF since create ioctl is still referencing the same vm. Move the xa_alloc all the way to the end to prevent this. v2: - Rebase (cherry picked from commit dcfd3971327f3ee92765154baebbaece833d3ca9)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49955", "url": "https://ubuntu.com/security/CVE-2024-49955", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: battery: Fix possible crash when unregistering a battery hook When a battery hook returns an error when adding a new battery, then the battery hook is automatically unregistered. However the battery hook provider cannot know that, so it will later call battery_hook_unregister() on the already unregistered battery hook, resulting in a crash. Fix this by using the list head to mark already unregistered battery hooks as already being unregistered so that they can be ignored by battery_hook_unregister().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49973", "url": "https://ubuntu.com/security/CVE-2024-49973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: r8169: add tally counter fields added with RTL8125 RTL8125 added fields to the tally counter, what may result in the chip dma'ing these new fields to unallocated memory. Therefore make sure that the allocated memory area is big enough to hold all of the tally counter values, even if we use only parts of it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49974", "url": "https://ubuntu.com/security/CVE-2024-49974", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Limit the number of concurrent async COPY operations Nothing appears to limit the number of concurrent async COPY operations that clients can start. In addition, AFAICT each async COPY can copy an unlimited number of 4MB chunks, so can run for a long time. Thus IMO async COPY can become a DoS vector. Add a restriction mechanism that bounds the number of concurrent background COPY operations. Start simple and try to be fair -- this patch implements a per-namespace limit. An async COPY request that occurs while this limit is exceeded gets NFS4ERR_DELAY. The requesting client can choose to send the request again after a delay or fall back to a traditional read/write style copy. If there is need to make the mechanism more sophisticated, we can visit that in future patches.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49975", "url": "https://ubuntu.com/security/CVE-2024-49975", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uprobes: fix kernel info leak via \"[uprobes]\" vma xol_add_vma() maps the uninitialized page allocated by __create_xol_area() into userspace. On some architectures (x86) this memory is readable even without VM_READ, VM_EXEC results in the same pgprot_t as VM_EXEC|VM_READ, although this doesn't really matter, debugger can read this memory anyway.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50003", "url": "https://ubuntu.com/security/CVE-2024-50003", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix system hang while resume with TBT monitor [Why] Connected with a Thunderbolt monitor and do the suspend and the system may hang while resume. The TBT monitor HPD will be triggered during the resume procedure and call the drm_client_modeset_probe() while struct drm_connector connector->dev->master is NULL. It will mess up the pipe topology after resume. [How] Skip the TBT monitor HPD during the resume procedure because we currently will probe the connectors after resume by default. (cherry picked from commit 453f86a26945207a16b8f66aaed5962dc2b95b85)", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50173", "url": "https://ubuntu.com/security/CVE-2024-50173", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix access to uninitialized variable in tick_ctx_cleanup() The group variable can't be used to retrieve ptdev in our second loop, because it points to the previously iterated list_head, not a valid group. Get the ptdev object from the scheduler instead.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49866", "url": "https://ubuntu.com/security/CVE-2024-49866", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Fix a race during cpuhp processing There is another found exception that the \"timerlat/1\" thread was scheduled on CPU0, and lead to timer corruption finally: ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ``` After tracing the scheduling event, it was discovered that the migration of the \"timerlat/1\" thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() | To fix this, skip online processing if the CPU is already offline.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49976", "url": "https://ubuntu.com/security/CVE-2024-49976", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Drop interface_lock in stop_kthread() stop_kthread() is the offline callback for \"trace/osnoise:online\", since commit 5bfbcd1ee57b (\"tracing/timerlat: Add interface_lock around clearing of kthread in stop_kthread()\"), the following ABBA deadlock scenario is introduced: T1 | T2 [BP] | T3 [AP] osnoise_hotplug_workfn() | work_for_cpu_fn() | cpuhp_thread_fun() | _cpu_down() | osnoise_cpu_die() mutex_lock(&interface_lock) | | stop_kthread() | cpus_write_lock() | mutex_lock(&interface_lock) cpus_read_lock() | cpuhp_kick_ap() | As the interface_lock here in just for protecting the \"kthread\" field of the osn_var, use xchg() instead to fix this issue. Also use for_each_online_cpu() back in stop_per_cpu_kthreads() as it can take cpu_read_lock() again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50005", "url": "https://ubuntu.com/security/CVE-2024-50005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: Fix potential RCU dereference issue in mac802154_scan_worker In the `mac802154_scan_worker` function, the `scan_req->type` field was accessed after the RCU read-side critical section was unlocked. According to RCU usage rules, this is illegal and can lead to unpredictable behavior, such as accessing memory that has been updated or causing use-after-free issues. This possible bug was identified using a static analysis tool developed by myself, specifically designed to detect RCU-related issues. To address this, the `scan_req->type` value is now stored in a local variable `scan_req_type` while still within the RCU read-side critical section. The `scan_req_type` is then used after the RCU lock is released, ensuring that the type value is safely accessed without violating RCU rules.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50012", "url": "https://ubuntu.com/security/CVE-2024-50012", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: Avoid a bad reference count on CPU node In the parse_perf_domain function, if the call to of_parse_phandle_with_args returns an error, then the reference to the CPU device node that was acquired at the start of the function would not be properly decremented. Address this by declaring the variable with the __free(device_node) cleanup attribute.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49867", "url": "https://ubuntu.com/security/CVE-2024-49867", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: wait for fixup workers before stopping cleaner kthread during umount During unmount, at close_ctree(), we have the following steps in this order: 1) Park the cleaner kthread - this doesn't destroy the kthread, it basically halts its execution (wake ups against it work but do nothing); 2) We stop the cleaner kthread - this results in freeing the respective struct task_struct; 3) We call btrfs_stop_all_workers() which waits for any jobs running in all the work queues and then free the work queues. Syzbot reported a case where a fixup worker resulted in a crash when doing a delayed iput on its inode while attempting to wake up the cleaner at btrfs_add_delayed_iput(), because the task_struct of the cleaner kthread was already freed. This can happen during unmount because we don't wait for any fixup workers still running before we call kthread_stop() against the cleaner kthread, which stops and free all its resources. Fix this by waiting for any fixup workers at close_ctree() before we call kthread_stop() against the cleaner and run pending delayed iputs. The stack traces reported by syzbot were the following: BUG: KASAN: slab-use-after-free in __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 Read of size 8 at addr ffff8880272a8a18 by task kworker/u8:3/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.12.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: btrfs-fixup btrfs_work_helper 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 __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline] try_to_wake_up+0xb0/0x1480 kernel/sched/core.c:4154 btrfs_writepage_fixup_worker+0xc16/0xdf0 fs/btrfs/inode.c:2842 btrfs_work_helper+0x390/0xc50 fs/btrfs/async-thread.c:314 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Allocated by task 2: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:319 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345 kasan_slab_alloc include/linux/kasan.h:247 [inline] slab_post_alloc_hook mm/slub.c:4086 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4187 alloc_task_struct_node kernel/fork.c:180 [inline] dup_task_struct+0x57/0x8c0 kernel/fork.c:1107 copy_process+0x5d1/0x3d50 kernel/fork.c:2206 kernel_clone+0x223/0x880 kernel/fork.c:2787 kernel_thread+0x1bc/0x240 kernel/fork.c:2849 create_kthread kernel/kthread.c:412 [inline] kthreadd+0x60d/0x810 kernel/kthread.c:765 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Freed by task 61: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:230 [inline] slab_free_h ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49868", "url": "https://ubuntu.com/security/CVE-2024-49868", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix a NULL pointer dereference when failed to start a new trasacntion [BUG] Syzbot reported a NULL pointer dereference with the following crash: FAULT_INJECTION: forcing a failure. start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676 prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642 relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678 ... BTRFS info (device loop0): balance: ended with status: -12 Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667] RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926 Call Trace: commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496 btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430 del_balance_item fs/btrfs/volumes.c:3678 [inline] reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742 btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574 btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673 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/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [CAUSE] The allocation failure happens at the start_transaction() inside prepare_to_relocate(), and during the error handling we call unset_reloc_control(), which makes fs_info->balance_ctl to be NULL. Then we continue the error path cleanup in btrfs_balance() by calling reset_balance_state() which will call del_balance_item() to fully delete the balance item in the root tree. However during the small window between set_reloc_contrl() and unset_reloc_control(), we can have a subvolume tree update and created a reloc_root for that subvolume. Then we go into the final btrfs_commit_transaction() of del_balance_item(), and into btrfs_update_reloc_root() inside commit_fs_roots(). That function checks if fs_info->reloc_ctl is in the merge_reloc_tree stage, but since fs_info->reloc_ctl is NULL, it results a NULL pointer dereference. [FIX] Just add extra check on fs_info->reloc_ctl inside btrfs_update_reloc_root(), before checking fs_info->reloc_ctl->merge_reloc_tree. That DEAD_RELOC_TREE handling is to prevent further modification to the reloc tree during merge stage, but since there is no reloc_ctl at all, we do not need to bother that.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49869", "url": "https://ubuntu.com/security/CVE-2024-49869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: send: fix buffer overflow detection when copying path to cache entry Starting with commit c0247d289e73 (\"btrfs: send: annotate struct name_cache_entry with __counted_by()\") we annotated the variable length array \"name\" from the name_cache_entry structure with __counted_by() to improve overflow detection. However that alone was not correct, because the length of that array does not match the \"name_len\" field - it matches that plus 1 to include the NUL string terminator, so that makes a fortified kernel think there's an overflow and report a splat like this: strcpy: detected buffer overflow: 20 byte write of buffer size 19 WARNING: CPU: 3 PID: 3310 at __fortify_report+0x45/0x50 CPU: 3 UID: 0 PID: 3310 Comm: btrfs Not tainted 6.11.0-prnet #1 Hardware name: CompuLab Ltd. sbc-ihsw/Intense-PC2 (IPC2), BIOS IPC2_3.330.7 X64 03/15/2018 RIP: 0010:__fortify_report+0x45/0x50 Code: 48 8b 34 (...) RSP: 0018:ffff97ebc0d6f650 EFLAGS: 00010246 RAX: 7749924ef60fa600 RBX: ffff8bf5446a521a RCX: 0000000000000027 RDX: 00000000ffffdfff RSI: ffff97ebc0d6f548 RDI: ffff8bf84e7a1cc8 RBP: ffff8bf548574080 R08: ffffffffa8c40e10 R09: 0000000000005ffd R10: 0000000000000004 R11: ffffffffa8c70e10 R12: ffff8bf551eef400 R13: 0000000000000000 R14: 0000000000000013 R15: 00000000000003a8 FS: 00007fae144de8c0(0000) GS:ffff8bf84e780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fae14691690 CR3: 00000001027a2003 CR4: 00000000001706f0 Call Trace: ? __warn+0x12a/0x1d0 ? __fortify_report+0x45/0x50 ? report_bug+0x154/0x1c0 ? handle_bug+0x42/0x70 ? exc_invalid_op+0x1a/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? __fortify_report+0x45/0x50 __fortify_panic+0x9/0x10 __get_cur_name_and_parent+0x3bc/0x3c0 get_cur_path+0x207/0x3b0 send_extent_data+0x709/0x10d0 ? find_parent_nodes+0x22df/0x25d0 ? mas_nomem+0x13/0x90 ? mtree_insert_range+0xa5/0x110 ? btrfs_lru_cache_store+0x5f/0x1e0 ? iterate_extent_inodes+0x52d/0x5a0 process_extent+0xa96/0x11a0 ? __pfx_lookup_backref_cache+0x10/0x10 ? __pfx_store_backref_cache+0x10/0x10 ? __pfx_iterate_backrefs+0x10/0x10 ? __pfx_check_extent_item+0x10/0x10 changed_cb+0x6fa/0x930 ? tree_advance+0x362/0x390 ? memcmp_extent_buffer+0xd7/0x160 send_subvol+0xf0a/0x1520 btrfs_ioctl_send+0x106b/0x11d0 ? __pfx___clone_root_cmp_sort+0x10/0x10 _btrfs_ioctl_send+0x1ac/0x240 btrfs_ioctl+0x75b/0x850 __se_sys_ioctl+0xca/0x150 do_syscall_64+0x85/0x160 ? __count_memcg_events+0x69/0x100 ? handle_mm_fault+0x1327/0x15c0 ? __se_sys_rt_sigprocmask+0xf1/0x180 ? syscall_exit_to_user_mode+0x75/0xa0 ? do_syscall_64+0x91/0x160 ? do_user_addr_fault+0x21d/0x630 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fae145eeb4f Code: 00 48 89 (...) RSP: 002b:00007ffdf1cb09b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fae145eeb4f RDX: 00007ffdf1cb0ad0 RSI: 0000000040489426 RDI: 0000000000000004 RBP: 00000000000078fe R08: 00007fae144006c0 R09: 00007ffdf1cb0927 R10: 0000000000000008 R11: 0000000000000246 R12: 00007ffdf1cb1ce8 R13: 0000000000000003 R14: 000055c499fab2e0 R15: 0000000000000004 Fix this by not storing the NUL string terminator since we don't actually need it for name cache entries, this way \"name_len\" corresponds to the actual size of the \"name\" array. This requires marking the \"name\" array field with __nonstring and using memcpy() instead of strcpy() as recommended by the guidelines at: https://github.com/KSPP/linux/issues/90", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49870", "url": "https://ubuntu.com/security/CVE-2024-49870", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cachefiles: fix dentry leak in cachefiles_open_file() A dentry leak may be caused when a lookup cookie and a cull are concurrent: P1 | P2 ----------------------------------------------------------- cachefiles_lookup_cookie cachefiles_look_up_object lookup_one_positive_unlocked // get dentry cachefiles_cull inode->i_flags |= S_KERNEL_FILE; cachefiles_open_file cachefiles_mark_inode_in_use __cachefiles_mark_inode_in_use can_use = false if (!(inode->i_flags & S_KERNEL_FILE)) can_use = true \t return false return false // Returns an error but doesn't put dentry After that the following WARNING will be triggered when the backend folder is umounted: ================================================================== BUG: Dentry 000000008ad87947{i=7a,n=Dx_1_1.img} still in use (1) [unmount of ext4 sda] WARNING: CPU: 4 PID: 359261 at fs/dcache.c:1767 umount_check+0x5d/0x70 CPU: 4 PID: 359261 Comm: umount Not tainted 6.6.0-dirty #25 RIP: 0010:umount_check+0x5d/0x70 Call Trace: d_walk+0xda/0x2b0 do_one_tree+0x20/0x40 shrink_dcache_for_umount+0x2c/0x90 generic_shutdown_super+0x20/0x160 kill_block_super+0x1a/0x40 ext4_kill_sb+0x22/0x40 deactivate_locked_super+0x35/0x80 cleanup_mnt+0x104/0x160 ================================================================== Whether cachefiles_open_file() returns true or false, the reference count obtained by lookup_positive_unlocked() in cachefiles_look_up_object() should be released. Therefore release that reference count in cachefiles_look_up_object() to fix the above issue and simplify the code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49871", "url": "https://ubuntu.com/security/CVE-2024-49871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: adp5589-keys - fix NULL pointer dereference We register a devm action to call adp5589_clear_config() and then pass the i2c client as argument so that we can call i2c_get_clientdata() in order to get our device object. However, i2c_set_clientdata() is only being set at the end of the probe function which means that we'll get a NULL pointer dereference in case the probe function fails early.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49872", "url": "https://ubuntu.com/security/CVE-2024-49872", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/gup: fix memfd_pin_folios alloc race panic If memfd_pin_folios tries to create a hugetlb page, but someone else already did, then folio gets the value -EEXIST here: folio = memfd_alloc_folio(memfd, start_idx); if (IS_ERR(folio)) { ret = PTR_ERR(folio); if (ret != -EEXIST) goto err; then on the next trip through the \"while start_idx\" loop we panic here: if (folio) { folio_put(folio); To fix, set the folio to NULL on error.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49964", "url": "https://ubuntu.com/security/CVE-2024-49964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix memfd_pin_folios free_huge_pages leak memfd_pin_folios followed by unpin_folios fails to restore free_huge_pages if the pages were not already faulted in, because the folio refcount for pages created by memfd_alloc_folio never goes to 0. memfd_pin_folios needs another folio_put to undo the folio_try_get below: memfd_alloc_folio() alloc_hugetlb_folio_nodemask() dequeue_hugetlb_folio_nodemask() dequeue_hugetlb_folio_node_exact() folio_ref_unfreeze(folio, 1); ; adds 1 refcount folio_try_get() ; adds 1 refcount hugetlb_add_to_page_cache() ; adds 512 refcount (on x86) With the fix, after memfd_pin_folios + unpin_folios, the refcount for the (unfaulted) page is 512, which is correct, as the refcount for a faulted unpinned page is 513.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49873", "url": "https://ubuntu.com/security/CVE-2024-49873", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/filemap: fix filemap_get_folios_contig THP panic Patch series \"memfd-pin huge page fixes\". Fix multiple bugs that occur when using memfd_pin_folios with hugetlb pages and THP. The hugetlb bugs only bite when the page is not yet faulted in when memfd_pin_folios is called. The THP bug bites when the starting offset passed to memfd_pin_folios is not huge page aligned. See the commit messages for details. This patch (of 5): memfd_pin_folios on memory backed by THP panics if the requested start offset is not huge page aligned: BUG: kernel NULL pointer dereference, address: 0000000000000036 RIP: 0010:filemap_get_folios_contig+0xdf/0x290 RSP: 0018:ffffc9002092fbe8 EFLAGS: 00010202 RAX: 0000000000000002 RBX: 0000000000000002 RCX: 0000000000000002 The fault occurs here, because xas_load returns a folio with value 2: filemap_get_folios_contig() for (folio = xas_load(&xas); folio && xas.xa_index <= end; folio = xas_next(&xas)) { ... if (!folio_try_get(folio)) <-- BOOM \"2\" is an xarray sibling entry. We get it because memfd_pin_folios does not round the indices passed to filemap_get_folios_contig to huge page boundaries for THP, so we load from the middle of a huge page range see a sibling. (It does round for hugetlbfs, at the is_file_hugepages test). To fix, if the folio is a sibling, then return the next index as the starting point for the next call to filemap_get_folios_contig.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49977", "url": "https://ubuntu.com/security/CVE-2024-49977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: Fix zero-division error when disabling tc cbs The commit b8c43360f6e4 (\"net: stmmac: No need to calculate speed divider when offload is disabled\") allows the \"port_transmit_rate_kbps\" to be set to a value of 0, which is then passed to the \"div_s64\" function when tc-cbs is disabled. This leads to a zero-division error. When tc-cbs is disabled, the idleslope, sendslope, and credit values the credit values are not required to be configured. Therefore, adding a return statement after setting the txQ mode to DCB when tc-cbs is disabled would prevent a zero-division error.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49978", "url": "https://ubuntu.com/security/CVE-2024-49978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gso: fix udp gso fraglist segmentation after pull from frag_list Detect gso fraglist skbs with corrupted geometry (see below) and pass these to skb_segment instead of skb_segment_list, as the first can segment them correctly. 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 these skbs, breaking these invariants. In extreme cases they pull all data into skb linear. For UDP, this causes a NULL ptr deref in __udpv4_gso_segment_list_csum at udp_hdr(seg->next)->dest. Detect invalid geometry due to pull, by checking head_skb size. Don't just drop, as this may blackhole a destination. Convert to be able to pass to regular skb_segment.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49979", "url": "https://ubuntu.com/security/CVE-2024-49979", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gso: fix tcp fraglist segmentation after pull from frag_list Detect tcp gso fraglist skbs with corrupted geometry (see below) and pass these to skb_segment instead of skb_segment_list, as the first can segment them correctly. 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 these skbs, breaking these invariants. In extreme cases they pull all data into skb linear. For TCP, this causes a NULL ptr deref in __tcpv4_gso_segment_list_csum at tcp_hdr(seg->next). Detect invalid geometry due to pull, by checking head_skb size. Don't just drop, as this may blackhole a destination. Convert to be able to pass to regular skb_segment. Approach and description based on a patch by Willem de Bruijn.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49980", "url": "https://ubuntu.com/security/CVE-2024-49980", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vrf: revert \"vrf: Remove unnecessary RCU-bh critical section\" This reverts commit 504fc6f4f7f681d2a03aa5f68aad549d90eab853. dev_queue_xmit_nit is expected to be called with BH disabled. __dev_queue_xmit has the following: /* Disable soft irqs for various locks below. Also * stops preemption for RCU. */ rcu_read_lock_bh(); VRF must follow this invariant. The referenced commit removed this protection. Which triggered a lockdep warning: \t================================ \tWARNING: inconsistent lock state \t6.11.0 #1 Tainted: G W \t-------------------------------- \tinconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage. \tbtserver/134819 [HC0[0]:SC0[0]:HE1:SE1] takes: \tffff8882da30c118 (rlock-AF_PACKET){+.?.}-{2:2}, at: tpacket_rcv+0x863/0x3b30 \t{IN-SOFTIRQ-W} state was registered at: \t lock_acquire+0x19a/0x4f0 \t _raw_spin_lock+0x27/0x40 \t packet_rcv+0xa33/0x1320 \t __netif_receive_skb_core.constprop.0+0xcb0/0x3a90 \t __netif_receive_skb_list_core+0x2c9/0x890 \t netif_receive_skb_list_internal+0x610/0xcc0 [...] \tother info that might help us debug this: \t Possible unsafe locking scenario: \t CPU0 \t ---- \t lock(rlock-AF_PACKET); \t \t lock(rlock-AF_PACKET); \t *** DEADLOCK *** \tCall Trace: \t \t dump_stack_lvl+0x73/0xa0 \t mark_lock+0x102e/0x16b0 \t __lock_acquire+0x9ae/0x6170 \t lock_acquire+0x19a/0x4f0 \t _raw_spin_lock+0x27/0x40 \t tpacket_rcv+0x863/0x3b30 \t dev_queue_xmit_nit+0x709/0xa40 \t vrf_finish_direct+0x26e/0x340 [vrf] \t vrf_l3_out+0x5f4/0xe80 [vrf] \t __ip_local_out+0x51e/0x7a0 [...]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49981", "url": "https://ubuntu.com/security/CVE-2024-49981", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: venus: fix use after free bug in venus_remove due to race condition in venus_probe, core->work is bound with venus_sys_error_handler, which is used to handle error. The code use core->sys_err_done to make sync work. The core->work is started in venus_event_notify. If we call venus_remove, there might be an unfished work. The possible sequence is as follows: CPU0 CPU1 |venus_sys_error_handler venus_remove | hfi_destroy\t \t\t | venus_hfi_destroy\t | kfree(hdev);\t | |hfi_reinit \t\t\t\t\t |venus_hfi_queues_reinit |//use hdev Fix it by canceling the work in venus_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49956", "url": "https://ubuntu.com/security/CVE-2024-49956", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: fix double destroy_workqueue error When gfs2_fill_super() fails, destroy_workqueue() is called within gfs2_gl_hash_clear(), and the subsequent code path calls destroy_workqueue() on the same work queue again. This issue can be fixed by setting the work queue pointer to NULL after the first destroy_workqueue() call and checking for a NULL pointer before attempting to destroy the work queue again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50176", "url": "https://ubuntu.com/security/CVE-2024-50176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: k3-r5: Fix error handling when power-up failed By simply bailing out, the driver was violating its rule and internal assumptions that either both or no rproc should be initialized. E.g., this could cause the first core to be available but not the second one, leading to crashes on its shutdown later on while trying to dereference that second instance.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49982", "url": "https://ubuntu.com/security/CVE-2024-49982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: aoe: fix the potential use-after-free problem in more places For fixing CVE-2023-6270, f98364e92662 (\"aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts\") makes tx() calling dev_put() instead of doing in aoecmd_cfg_pkts(). It avoids that the tx() runs into use-after-free. Then Nicolai Stange found more places in aoe have potential use-after-free problem with tx(). e.g. revalidate(), aoecmd_ata_rw(), resend(), probe() and aoecmd_cfg_rsp(). Those functions also use aoenet_xmit() to push packet to tx queue. So they should also use dev_hold() to increase the refcnt of skb->dev. On the other hand, moving dev_put() to tx() causes that the refcnt of skb->dev be reduced to a negative value, because corresponding dev_hold() are not called in revalidate(), aoecmd_ata_rw(), resend(), probe(), and aoecmd_cfg_rsp(). This patch fixed this issue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49874", "url": "https://ubuntu.com/security/CVE-2024-49874", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: svc: Fix use after free vulnerability in svc_i3c_master Driver Due to Race Condition In the svc_i3c_master_probe function, &master->hj_work is bound with svc_i3c_master_hj_work, &master->ibi_work is bound with svc_i3c_master_ibi_work. And svc_i3c_master_ibi_work can start the hj_work, svc_i3c_master_irq_handler can start the ibi_work. If we remove the module which will call svc_i3c_master_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | svc_i3c_master_hj_work svc_i3c_master_remove | i3c_master_unregister(&master->base)| device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in svc_i3c_master_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49875", "url": "https://ubuntu.com/security/CVE-2024-49875", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: map the EBADMSG to nfserr_io to avoid warning Ext4 will throw -EBADMSG through ext4_readdir when a checksum error occurs, resulting in the following WARNING. Fix it by mapping EBADMSG to nfserr_io. nfsd_buffered_readdir iterate_dir // -EBADMSG -74 ext4_readdir // .iterate_shared ext4_dx_readdir ext4_htree_fill_tree htree_dirblock_to_tree ext4_read_dirblock __ext4_read_dirblock ext4_dirblock_csum_verify warn_no_space_for_csum __warn_no_space_for_csum return ERR_PTR(-EFSBADCRC) // -EBADMSG -74 nfserrno // WARNING [ 161.115610] ------------[ cut here ]------------ [ 161.116465] nfsd: non-standard errno: -74 [ 161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0 [ 161.118596] Modules linked in: [ 161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138 [ 161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qe mu.org 04/01/2014 [ 161.123601] RIP: 0010:nfserrno+0x9d/0xd0 [ 161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6 05 ce 2b 61 03 01 e8 99 20 d8 00 <0f> 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33 [ 161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286 [ 161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a [ 161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827 [ 161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021 [ 161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8 [ 161.135244] FS: 0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000 [ 161.136695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0 [ 161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 161.141519] PKRU: 55555554 [ 161.142076] Call Trace: [ 161.142575] ? __warn+0x9b/0x140 [ 161.143229] ? nfserrno+0x9d/0xd0 [ 161.143872] ? report_bug+0x125/0x150 [ 161.144595] ? handle_bug+0x41/0x90 [ 161.145284] ? exc_invalid_op+0x14/0x70 [ 161.146009] ? asm_exc_invalid_op+0x12/0x20 [ 161.146816] ? nfserrno+0x9d/0xd0 [ 161.147487] nfsd_buffered_readdir+0x28b/0x2b0 [ 161.148333] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.149258] ? nfsd_buffered_filldir+0xf0/0xf0 [ 161.150093] ? wait_for_concurrent_writes+0x170/0x170 [ 161.151004] ? generic_file_llseek_size+0x48/0x160 [ 161.151895] nfsd_readdir+0x132/0x190 [ 161.152606] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.153516] ? nfsd_unlink+0x380/0x380 [ 161.154256] ? override_creds+0x45/0x60 [ 161.155006] nfsd4_encode_readdir+0x21a/0x3d0 [ 161.155850] ? nfsd4_encode_readlink+0x210/0x210 [ 161.156731] ? write_bytes_to_xdr_buf+0x97/0xe0 [ 161.157598] ? __write_bytes_to_xdr_buf+0xd0/0xd0 [ 161.158494] ? lock_downgrade+0x90/0x90 [ 161.159232] ? nfs4svc_decode_voidarg+0x10/0x10 [ 161.160092] nfsd4_encode_operation+0x15a/0x440 [ 161.160959] nfsd4_proc_compound+0x718/0xe90 [ 161.161818] nfsd_dispatch+0x18e/0x2c0 [ 161.162586] svc_process_common+0x786/0xc50 [ 161.163403] ? nfsd_svc+0x380/0x380 [ 161.164137] ? svc_printk+0x160/0x160 [ 161.164846] ? svc_xprt_do_enqueue.part.0+0x365/0x380 [ 161.165808] ? nfsd_svc+0x380/0x380 [ 161.166523] ? rcu_is_watching+0x23/0x40 [ 161.167309] svc_process+0x1a5/0x200 [ 161.168019] nfsd+0x1f5/0x380 [ 161.168663] ? nfsd_shutdown_threads+0x260/0x260 [ 161.169554] kthread+0x1c4/0x210 [ 161.170224] ? kthread_insert_work_sanity_check+0x80/0x80 [ 161.171246] ret_from_fork+0x1f/0x30", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50013", "url": "https://ubuntu.com/security/CVE-2024-50013", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix memory leak in exfat_load_bitmap() If the first directory entry in the root directory is not a bitmap directory entry, 'bh' will not be released and reassigned, which will cause a memory leak.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49876", "url": "https://ubuntu.com/security/CVE-2024-49876", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: fix UAF around queue destruction We currently do stuff like queuing the final destruction step on a random system wq, which will outlive the driver instance. With bad timing we can teardown the driver with one or more work workqueue still being alive leading to various UAF splats. Add a fini step to ensure user queues are properly torn down. At this point GuC should already be nuked so queue itself should no longer be referenced from hw pov. v2 (Matt B) - Looks much safer to use a waitqueue and then just wait for the xa_array to become empty before triggering the drain. (cherry picked from commit 861108666cc0e999cffeab6aff17b662e68774e3)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49877", "url": "https://ubuntu.com/security/CVE-2024-49877", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate When doing cleanup, if flags without OCFS2_BH_READAHEAD, it may trigger NULL pointer dereference in the following ocfs2_set_buffer_uptodate() if bh is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49957", "url": "https://ubuntu.com/security/CVE-2024-49957", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix null-ptr-deref when journal load failed. During the mounting process, if journal_reset() fails because of too short journal, then lead to jbd2_journal_load() fails with NULL j_sb_buffer. Subsequently, ocfs2_journal_shutdown() calls jbd2_journal_flush()->jbd2_cleanup_journal_tail()-> __jbd2_update_log_tail()->jbd2_journal_update_sb_log_tail() ->lock_buffer(journal->j_sb_buffer), resulting in a null-pointer dereference error. To resolve this issue, we should check the JBD2_LOADED flag to ensure the journal was properly loaded. Additionally, use journal instead of osb->journal directly to simplify the code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49965", "url": "https://ubuntu.com/security/CVE-2024-49965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove unreasonable unlock in ocfs2_read_blocks Patch series \"Misc fixes for ocfs2_read_blocks\", v5. This series contains 2 fixes for ocfs2_read_blocks(). The first patch fix the issue reported by syzbot, which detects bad unlock balance in ocfs2_read_blocks(). The second patch fixes an issue reported by Heming Zhao when reviewing above fix. This patch (of 2): There was a lock release before exiting, so remove the unreasonable unlock.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49966", "url": "https://ubuntu.com/security/CVE-2024-49966", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: cancel dqi_sync_work before freeing oinfo ocfs2_global_read_info() will initialize and schedule dqi_sync_work at the end, if error occurs after successfully reading global quota, it will trigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled: ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16c This reports that there is an active delayed work when freeing oinfo in error handling, so cancel dqi_sync_work first. BTW, return status instead of -1 when .read_file_info fails.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49958", "url": "https://ubuntu.com/security/CVE-2024-49958", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reserve space for inline xattr before attaching reflink tree One of our customers reported a crash and a corrupted ocfs2 filesystem. The crash was due to the detection of corruption. Upon troubleshooting, the fsck -fn output showed the below corruption [EXTENT_LIST_FREE] Extent list in owner 33080590 claims 230 as the next free chain record, but fsck believes the largest valid value is 227. Clamp the next record value? n The stat output from the debugfs.ocfs2 showed the following corruption where the \"Next Free Rec:\" had overshot the \"Count:\" in the root metadata block. Inode: 33080590 Mode: 0640 Generation: 2619713622 (0x9c25a856) FS Generation: 904309833 (0x35e6ac49) CRC32: 00000000 ECC: 0000 Type: Regular Attr: 0x0 Flags: Valid Dynamic Features: (0x16) HasXattr InlineXattr Refcounted Extended Attributes Block: 0 Extended Attributes Inline Size: 256 User: 0 (root) Group: 0 (root) Size: 281320357888 Links: 1 Clusters: 141738 ctime: 0x66911b56 0x316edcb8 -- Fri Jul 12 06:02:30.829349048 2024 atime: 0x66911d6b 0x7f7a28d -- Fri Jul 12 06:11:23.133669517 2024 mtime: 0x66911b56 0x12ed75d7 -- Fri Jul 12 06:02:30.317552087 2024 dtime: 0x0 -- Wed Dec 31 17:00:00 1969 Refcount Block: 2777346 Last Extblk: 2886943 Orphan Slot: 0 Sub Alloc Slot: 0 Sub Alloc Bit: 14 Tree Depth: 1 Count: 227 Next Free Rec: 230 ## Offset Clusters Block# 0 0 2310 2776351 1 2310 2139 2777375 2 4449 1221 2778399 3 5670 731 2779423 4 6401 566 2780447 ....... .... ....... ....... .... ....... The issue was in the reflink workfow while reserving space for inline xattr. The problematic function is ocfs2_reflink_xattr_inline(). By the time this function is called the reflink tree is already recreated at the destination inode from the source inode. At this point, this function reserves space for inline xattrs at the destination inode without even checking if there is space at the root metadata block. It simply reduces the l_count from 243 to 227 thereby making space of 256 bytes for inline xattr whereas the inode already has extents beyond this index (in this case up to 230), thereby causing corruption. The fix for this is to reserve space for inline metadata at the destination inode before the reflink tree gets recreated. The customer has verified the fix.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49959", "url": "https://ubuntu.com/security/CVE-2024-49959", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail() to recover some journal space. But if an error occurs while executing jbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for free space right away, we try other branches, and if j_committing_transaction is NULL (i.e., the tid is 0), we will get the following complain: ============================================ JBD2: I/O error when updating journal superblock for sdd-8. __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available __jbd2_log_wait_for_space: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Call Trace: add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70 [...] ============================================ So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways. Note that this fix relies on commit 6f6a6fda2945 (\"jbd2: fix ocfs2 corrupt when updating journal superblock fails\") to make jbd2_cleanup_journal_tail return the correct error code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49878", "url": "https://ubuntu.com/security/CVE-2024-49878", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: resource: fix region_intersects() vs add_memory_driver_managed() On a system with CXL memory, the resource tree (/proc/iomem) related to CXL memory may look like something as follows. 490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem) Because drivers/dax/kmem.c calls add_memory_driver_managed() during onlining CXL memory, which makes \"System RAM (kmem)\" a descendant of \"CXL Window X\". This confuses region_intersects(), which expects all \"System RAM\" resources to be at the top level of iomem_resource. This can lead to bugs. For example, when the following command line is executed to write some memory in CXL memory range via /dev/mem, $ dd if=data of=/dev/mem bs=$((1 << 10)) seek=$((0x490000000 >> 10)) count=1 dd: error writing '/dev/mem': Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/s the command fails as expected. However, the error code is wrong. It should be \"Operation not permitted\" instead of \"Bad address\". More seriously, the /dev/mem permission checking in devmem_is_allowed() passes incorrectly. Although the accessing is prevented later because ioremap() isn't allowed to map system RAM, it is a potential security issue. During command executing, the following warning is reported in the kernel log for calling ioremap() on system RAM. ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d Call Trace: memremap+0xcb/0x184 xlate_dev_mem_ptr+0x25/0x2f write_mem+0x94/0xfb vfs_write+0x128/0x26d ksys_write+0xac/0xfe do_syscall_64+0x9a/0xfd entry_SYSCALL_64_after_hwframe+0x4b/0x53 The details of command execution process are as follows. In the above resource tree, \"System RAM\" is a descendant of \"CXL Window 0\" instead of a top level resource. So, region_intersects() will report no System RAM resources in the CXL memory region incorrectly, because it only checks the top level resources. Consequently, devmem_is_allowed() will return 1 (allow access via /dev/mem) for CXL memory region incorrectly. Fortunately, ioremap() doesn't allow to map System RAM and reject the access. So, region_intersects() needs to be fixed to work correctly with the resource tree with \"System RAM\" not at top level as above. To fix it, if we found a unmatched resource in the top level, we will continue to search matched resources in its descendant resources. So, we will not miss any matched resources in resource tree anymore. In the new implementation, an example resource tree |------------- \"CXL Window 0\" ------------| |-- \"System RAM\" --| will behave similar as the following fake resource tree for region_intersects(, IORESOURCE_SYSTEM_RAM, ), |-- \"System RAM\" --||-- \"CXL Window 0a\" --| Where \"CXL Window 0a\" is part of the original \"CXL Window 0\" that isn't covered by \"System RAM\".", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49879", "url": "https://ubuntu.com/security/CVE-2024-49879", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm: omapdrm: Add missing check for alloc_ordered_workqueue As it may return NULL pointer and cause NULL pointer dereference. Add check for the return value of alloc_ordered_workqueue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49880", "url": "https://ubuntu.com/security/CVE-2024-49880", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix off by one issue in alloc_flex_gd() Wesley reported an issue: ================================================================== EXT4-fs (dm-5): resizing filesystem from 7168 to 786432 blocks ------------[ cut here ]------------ kernel BUG at fs/ext4/resize.c:324! CPU: 9 UID: 0 PID: 3576 Comm: resize2fs Not tainted 6.11.0+ #27 RIP: 0010:ext4_resize_fs+0x1212/0x12d0 Call Trace: __ext4_ioctl+0x4e0/0x1800 ext4_ioctl+0x12/0x20 __x64_sys_ioctl+0x99/0xd0 x64_sys_call+0x1206/0x20d0 do_syscall_64+0x72/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e ================================================================== While reviewing the patch, Honza found that when adjusting resize_bg in alloc_flex_gd(), it was possible for flex_gd->resize_bg to be bigger than flexbg_size. The reproduction of the problem requires the following: o_group = flexbg_size * 2 * n; o_size = (o_group + 1) * group_size; n_group: [o_group + flexbg_size, o_group + flexbg_size * 2) o_size = (n_group + 1) * group_size; Take n=0,flexbg_size=16 as an example: last:15 |o---------------|--------------n-| o_group:0 resize to n_group:30 The corresponding reproducer is: img=test.img rm -f $img truncate -s 600M $img mkfs.ext4 -F $img -b 1024 -G 16 8M dev=`losetup -f --show $img` mkdir -p /tmp/test mount $dev /tmp/test resize2fs $dev 248M Delete the problematic plus 1 to fix the issue, and add a WARN_ON_ONCE() to prevent the issue from happening again. [ Note: another reproucer which this commit fixes is: img=test.img rm -f $img truncate -s 25MiB $img mkfs.ext4 -b 4096 -E nodiscard,lazy_itable_init=0,lazy_journal_init=0 $img truncate -s 3GiB $img dev=`losetup -f --show $img` mkdir -p /tmp/test mount $dev /tmp/test resize2fs $dev 3G umount $dev losetup -d $dev -- TYT ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49881", "url": "https://ubuntu.com/security/CVE-2024-49881", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: update orig_path in ext4_find_extent() In ext4_find_extent(), if the path is not big enough, we free it and set *orig_path to NULL. But after reallocating and successfully initializing the path, we don't update *orig_path, in which case the caller gets a valid path but a NULL ppath, and this may cause a NULL pointer dereference or a path memory leak. For example: ext4_split_extent path = *ppath = 2000 ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path = 2000); *orig_path = path = NULL; path = kcalloc() = 3000 ext4_split_extent_at(*ppath = NULL) path = *ppath; ex = path[depth].p_ext; // NULL pointer dereference! ================================================================== BUG: kernel NULL pointer dereference, address: 0000000000000010 CPU: 6 UID: 0 PID: 576 Comm: fsstress Not tainted 6.11.0-rc2-dirty #847 RIP: 0010:ext4_split_extent_at+0x6d/0x560 Call Trace: ext4_split_extent.isra.0+0xcb/0x1b0 ext4_ext_convert_to_initialized+0x168/0x6c0 ext4_ext_handle_unwritten_extents+0x325/0x4d0 ext4_ext_map_blocks+0x520/0xdb0 ext4_map_blocks+0x2b0/0x690 ext4_iomap_begin+0x20e/0x2c0 [...] ================================================================== Therefore, *orig_path is updated when the extent lookup succeeds, so that the caller can safely use path or *ppath.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50014", "url": "https://ubuntu.com/security/CVE-2024-50014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix access to uninitialised lock in fc replay path The following kernel trace can be triggered with fstest generic/629 when executed against a filesystem with fast-commit feature enabled: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x66/0x90 register_lock_class+0x759/0x7d0 __lock_acquire+0x85/0x2630 ? __find_get_block+0xb4/0x380 lock_acquire+0xd1/0x2d0 ? __ext4_journal_get_write_access+0xd5/0x160 _raw_spin_lock+0x33/0x40 ? __ext4_journal_get_write_access+0xd5/0x160 __ext4_journal_get_write_access+0xd5/0x160 ext4_reserve_inode_write+0x61/0xb0 __ext4_mark_inode_dirty+0x79/0x270 ? ext4_ext_replay_set_iblocks+0x2f8/0x450 ext4_ext_replay_set_iblocks+0x330/0x450 ext4_fc_replay+0x14c8/0x1540 ? jread+0x88/0x2e0 ? rcu_is_watching+0x11/0x40 do_one_pass+0x447/0xd00 jbd2_journal_recover+0x139/0x1b0 jbd2_journal_load+0x96/0x390 ext4_load_and_init_journal+0x253/0xd40 ext4_fill_super+0x2cc6/0x3180 ... In the replay path there's an attempt to lock sbi->s_bdev_wb_lock in function ext4_check_bdev_write_error(). Unfortunately, at this point this spinlock has not been initialized yet. Moving it's initialization to an earlier point in __ext4_fill_super() fixes this splat.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49960", "url": "https://ubuntu.com/security/CVE-2024-49960", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix timer use-after-free on failed mount Syzbot has found an ODEBUG bug in ext4_fill_super The del_timer_sync function cancels the s_err_report timer, which reminds about filesystem errors daily. We should guarantee the timer is no longer active before kfree(sbi). When filesystem mounting fails, the flow goes to failed_mount3, where an error occurs when ext4_stop_mmpd is called, causing a read I/O failure. This triggers the ext4_handle_error function that ultimately re-arms the timer, leaving the s_err_report timer active before kfree(sbi) is called. Fix the issue by canceling the s_err_report timer after calling ext4_stop_mmpd.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49882", "url": "https://ubuntu.com/security/CVE-2024-49882", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix double brelse() the buffer of the extents path In ext4_ext_try_to_merge_up(), set path[1].p_bh to NULL after it has been released, otherwise it may be released twice. An example of what triggers this is as follows: split2 map split1 |--------|-------|--------| ext4_ext_map_blocks ext4_ext_handle_unwritten_extents ext4_split_convert_extents // path->p_depth == 0 ext4_split_extent // 1. do split1 ext4_split_extent_at |ext4_ext_insert_extent | ext4_ext_create_new_leaf | ext4_ext_grow_indepth | le16_add_cpu(&neh->eh_depth, 1) | ext4_find_extent | // return -ENOMEM |// get error and try zeroout |path = ext4_find_extent | path->p_depth = 1 |ext4_ext_try_to_merge | ext4_ext_try_to_merge_up | path->p_depth = 0 | brelse(path[1].p_bh) ---> not set to NULL here |// zeroout success // 2. update path ext4_find_extent // 3. do split2 ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth le16_add_cpu(&neh->eh_depth, 1) ext4_find_extent path[0].p_bh = NULL; path->p_depth = 1 read_extent_tree_block ---> return err // path[1].p_bh is still the old value ext4_free_ext_path ext4_ext_drop_refs // path->p_depth == 1 brelse(path[1].p_bh) ---> brelse a buffer twice Finally got the following WARRNING when removing the buffer from lru: ============================================ VFS: brelse: Trying to free free buffer WARNING: CPU: 2 PID: 72 at fs/buffer.c:1241 __brelse+0x58/0x90 CPU: 2 PID: 72 Comm: kworker/u19:1 Not tainted 6.9.0-dirty #716 RIP: 0010:__brelse+0x58/0x90 Call Trace: __find_get_block+0x6e7/0x810 bdev_getblk+0x2b/0x480 __ext4_get_inode_loc+0x48a/0x1240 ext4_get_inode_loc+0xb2/0x150 ext4_reserve_inode_write+0xb7/0x230 __ext4_mark_inode_dirty+0x144/0x6a0 ext4_ext_insert_extent+0x9c8/0x3230 ext4_ext_map_blocks+0xf45/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] ============================================", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49883", "url": "https://ubuntu.com/security/CVE-2024-49883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: aovid use-after-free in ext4_ext_insert_extent() As Ojaswin mentioned in Link, in ext4_ext_insert_extent(), if the path is reallocated in ext4_ext_create_new_leaf(), we'll use the stale path and cause UAF. Below is a sample trace with dummy values: ext4_ext_insert_extent path = *ppath = 2000 ext4_ext_create_new_leaf(ppath) ext4_find_extent(ppath) path = *ppath = 2000 if (depth > path[0].p_maxdepth) kfree(path = 2000); *ppath = path = NULL; path = kcalloc() = 3000 *ppath = 3000; return path; /* here path is still 2000, UAF! */ eh = path[depth].p_hdr ================================================================== BUG: KASAN: slab-use-after-free in ext4_ext_insert_extent+0x26d4/0x3330 Read of size 8 at addr ffff8881027bf7d0 by task kworker/u36:1/179 CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 Not tainted 6.11.0-rc2-dirty #866 Call Trace: ext4_ext_insert_extent+0x26d4/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 [...] Allocated by task 179: ext4_find_extent+0x81c/0x1f70 ext4_ext_map_blocks+0x146/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...] Freed by task 179: kfree+0xcb/0x240 ext4_find_extent+0x7c0/0x1f70 ext4_ext_insert_extent+0xa26/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...] ================================================================== So use *ppath to update the path to avoid the above problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49983", "url": "https://ubuntu.com/security/CVE-2024-49983", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-free When calling ext4_force_split_extent_at() in ext4_ext_replay_update_ex(), the 'ppath' is updated but it is the 'path' that is freed, thus potentially triggering a double-free in the following process: ext4_ext_replay_update_ex ppath = path ext4_force_split_extent_at(&ppath) ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path) ---> path First freed *orig_path = path = NULL ---> null ppath kfree(path) ---> path double-free !!! So drop the unnecessary ppath and use path directly to avoid this problem. And use ext4_find_extent() directly to update path, avoiding unnecessary memory allocation and freeing. Also, propagate the error returned by ext4_find_extent() instead of using strange error codes.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50015", "url": "https://ubuntu.com/security/CVE-2024-50015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: dax: fix overflowing extents beyond inode size when partially writing The dax_iomap_rw() does two things in each iteration: map written blocks and copy user data to blocks. If the process is killed by user(See signal handling in dax_iomap_iter()), the copied data will be returned and added on inode size, which means that the length of written extents may exceed the inode size, then fsck will fail. An example is given as: dd if=/dev/urandom of=file bs=4M count=1 dax_iomap_rw iomap_iter // round 1 ext4_iomap_begin ext4_iomap_alloc // allocate 0~2M extents(written flag) dax_iomap_iter // copy 2M data iomap_iter // round 2 iomap_iter_advance iter->pos += iter->processed // iter->pos = 2M ext4_iomap_begin ext4_iomap_alloc // allocate 2~4M extents(written flag) dax_iomap_iter fatal_signal_pending done = iter->pos - iocb->ki_pos // done = 2M ext4_handle_inode_extension ext4_update_inode_size // inode size = 2M fsck reports: Inode 13, i_size is 2097152, should be 4194304. Fix? Fix the problem by truncating extents if the written length is smaller than expected.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49884", "url": "https://ubuntu.com/security/CVE-2024-49884", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix slab-use-after-free in ext4_split_extent_at() We hit the following use-after-free: ================================================================== BUG: KASAN: slab-use-after-free in ext4_split_extent_at+0xba8/0xcc0 Read of size 2 at addr ffff88810548ed08 by task kworker/u20:0/40 CPU: 0 PID: 40 Comm: kworker/u20:0 Not tainted 6.9.0-dirty #724 Call Trace: kasan_report+0x93/0xc0 ext4_split_extent_at+0xba8/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] Allocated by task 40: __kmalloc_noprof+0x1ac/0x480 ext4_find_extent+0xf3b/0x1e70 ext4_ext_map_blocks+0x188/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] Freed by task 40: kfree+0xf1/0x2b0 ext4_find_extent+0xa71/0x1e70 ext4_ext_insert_extent+0xa22/0x3260 ext4_split_extent_at+0x3ef/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] ================================================================== The flow of issue triggering is as follows: ext4_split_extent_at path = *ppath ext4_ext_insert_extent(ppath) ext4_ext_create_new_leaf(ppath) ext4_find_extent(orig_path) path = *orig_path read_extent_tree_block // return -ENOMEM or -EIO ext4_free_ext_path(path) kfree(path) *orig_path = NULL a. If err is -ENOMEM: ext4_ext_dirty(path + path->p_depth) // path use-after-free !!! b. If err is -EIO and we have EXT_DEBUG defined: ext4_ext_show_leaf(path) eh = path[depth].p_hdr // path also use-after-free !!! So when trying to zeroout or fix the extent length, call ext4_find_extent() to update the path. In addition we use *ppath directly as an ext4_ext_show_leaf() input to avoid possible use-after-free when EXT_DEBUG is defined, and to avoid unnecessary path updates.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49885", "url": "https://ubuntu.com/security/CVE-2024-49885", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm, slub: avoid zeroing kmalloc redzone Since commit 946fa0dbf2d8 (\"mm/slub: extend redzone check to extra allocated kmalloc space than requested\"), setting orig_size treats the wasted space (object_size - orig_size) as a redzone. However with init_on_free=1 we clear the full object->size, including the redzone. Additionally we clear the object metadata, including the stored orig_size, making it zero, which makes check_object() treat the whole object as a redzone. These issues lead to the following BUG report with \"slub_debug=FUZ init_on_free=1\": [ 0.000000] ============================================================================= [ 0.000000] BUG kmalloc-8 (Not tainted): kmalloc Redzone overwritten [ 0.000000] ----------------------------------------------------------------------------- [ 0.000000] [ 0.000000] 0xffff000010032858-0xffff00001003285f @offset=2136. First byte 0x0 instead of 0xcc [ 0.000000] FIX kmalloc-8: Restoring kmalloc Redzone 0xffff000010032858-0xffff00001003285f=0xcc [ 0.000000] Slab 0xfffffdffc0400c80 objects=36 used=23 fp=0xffff000010032a18 flags=0x3fffe0000000200(workingset|node=0|zone=0|lastcpupid=0x1ffff) [ 0.000000] Object 0xffff000010032858 @offset=2136 fp=0xffff0000100328c8 [ 0.000000] [ 0.000000] Redzone ffff000010032850: cc cc cc cc cc cc cc cc ........ [ 0.000000] Object ffff000010032858: cc cc cc cc cc cc cc cc ........ [ 0.000000] Redzone ffff000010032860: cc cc cc cc cc cc cc cc ........ [ 0.000000] Padding ffff0000100328b4: 00 00 00 00 00 00 00 00 00 00 00 00 ............ [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.11.0-rc3-next-20240814-00004-g61844c55c3f4 #144 [ 0.000000] Hardware name: NXP i.MX95 19X19 board (DT) [ 0.000000] Call trace: [ 0.000000] dump_backtrace+0x90/0xe8 [ 0.000000] show_stack+0x18/0x24 [ 0.000000] dump_stack_lvl+0x74/0x8c [ 0.000000] dump_stack+0x18/0x24 [ 0.000000] print_trailer+0x150/0x218 [ 0.000000] check_object+0xe4/0x454 [ 0.000000] free_to_partial_list+0x2f8/0x5ec To address the issue, use orig_size to clear the used area. And restore the value of orig_size after clear the remaining area. When CONFIG_SLUB_DEBUG not defined, (get_orig_size()' directly returns s->object_size. So when using memset to init the area, the size can simply be orig_size, as orig_size returns object_size when CONFIG_SLUB_DEBUG not enabled. And orig_size can never be bigger than object_size.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49961", "url": "https://ubuntu.com/security/CVE-2024-49961", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: ar0521: Use cansleep version of gpiod_set_value() If we use GPIO reset from I2C port expander, we must use *_cansleep() variant of GPIO functions. This was not done in ar0521_power_on()/ar0521_power_off() functions. Let's fix that. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 11 at drivers/gpio/gpiolib.c:3496 gpiod_set_value+0x74/0x7c Modules linked in: CPU: 0 PID: 11 Comm: kworker/u16:0 Not tainted 6.10.0 #53 Hardware name: Diasom DS-RK3568-SOM-EVB (DT) Workqueue: events_unbound deferred_probe_work_func pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : gpiod_set_value+0x74/0x7c lr : ar0521_power_on+0xcc/0x290 sp : ffffff8001d7ab70 x29: ffffff8001d7ab70 x28: ffffff80027dcc90 x27: ffffff8003c82000 x26: ffffff8003ca9250 x25: ffffffc080a39c60 x24: ffffff8003ca9088 x23: ffffff8002402720 x22: ffffff8003ca9080 x21: ffffff8003ca9088 x20: 0000000000000000 x19: ffffff8001eb2a00 x18: ffffff80efeeac80 x17: 756d2d6332692f30 x16: 0000000000000000 x15: 0000000000000000 x14: ffffff8001d91d40 x13: 0000000000000016 x12: ffffffc080e98930 x11: ffffff8001eb2880 x10: 0000000000000890 x9 : ffffff8001d7a9f0 x8 : ffffff8001d92570 x7 : ffffff80efeeac80 x6 : 000000003fc6e780 x5 : ffffff8001d91c80 x4 : 0000000000000002 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000001 Call trace: gpiod_set_value+0x74/0x7c ar0521_power_on+0xcc/0x290 ...", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49985", "url": "https://ubuntu.com/security/CVE-2024-49985", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume In case there is any sort of clock controller attached to this I2C bus controller, for example Versaclock or even an AIC32x4 I2C codec, then an I2C transfer triggered from the clock controller clk_ops .prepare callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex. This is because the clock controller first grabs the prepare_lock mutex and then performs the prepare operation, including its I2C access. The I2C access resumes this I2C bus controller via .runtime_resume callback, which calls clk_prepare_enable(), which attempts to grab the prepare_lock mutex again and deadlocks. Since the clock are already prepared since probe() and unprepared in remove(), use simple clk_enable()/clk_disable() calls to enable and disable the clock on runtime suspend and resume, to avoid hitting the prepare_lock mutex.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49886", "url": "https://ubuntu.com/security/CVE-2024-49886", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bug Attaching SST PCI device to VM causes \"BUG: KASAN: slab-out-of-bounds\". kasan report: [ 19.411889] ================================================================== [ 19.413702] BUG: KASAN: slab-out-of-bounds in _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.415634] Read of size 8 at addr ffff888829e65200 by task cpuhp/16/113 [ 19.417368] [ 19.418627] CPU: 16 PID: 113 Comm: cpuhp/16 Tainted: G E 6.9.0 #10 [ 19.420435] Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.20192059.B64.2207280713 07/28/2022 [ 19.422687] Call Trace: [ 19.424091] [ 19.425448] dump_stack_lvl+0x5d/0x80 [ 19.426963] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.428694] print_report+0x19d/0x52e [ 19.430206] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 19.431837] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.433539] kasan_report+0xf0/0x170 [ 19.435019] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.436709] _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.438379] ? __pfx_sched_clock_cpu+0x10/0x10 [ 19.439910] isst_if_cpu_online+0x406/0x58f [isst_if_common] [ 19.441573] ? __pfx_isst_if_cpu_online+0x10/0x10 [isst_if_common] [ 19.443263] ? ttwu_queue_wakelist+0x2c1/0x360 [ 19.444797] cpuhp_invoke_callback+0x221/0xec0 [ 19.446337] cpuhp_thread_fun+0x21b/0x610 [ 19.447814] ? __pfx_cpuhp_thread_fun+0x10/0x10 [ 19.449354] smpboot_thread_fn+0x2e7/0x6e0 [ 19.450859] ? __pfx_smpboot_thread_fn+0x10/0x10 [ 19.452405] kthread+0x29c/0x350 [ 19.453817] ? __pfx_kthread+0x10/0x10 [ 19.455253] ret_from_fork+0x31/0x70 [ 19.456685] ? __pfx_kthread+0x10/0x10 [ 19.458114] ret_from_fork_asm+0x1a/0x30 [ 19.459573] [ 19.460853] [ 19.462055] Allocated by task 1198: [ 19.463410] kasan_save_stack+0x30/0x50 [ 19.464788] kasan_save_track+0x14/0x30 [ 19.466139] __kasan_kmalloc+0xaa/0xb0 [ 19.467465] __kmalloc+0x1cd/0x470 [ 19.468748] isst_if_cdev_register+0x1da/0x350 [isst_if_common] [ 19.470233] isst_if_mbox_init+0x108/0xff0 [isst_if_mbox_msr] [ 19.471670] do_one_initcall+0xa4/0x380 [ 19.472903] do_init_module+0x238/0x760 [ 19.474105] load_module+0x5239/0x6f00 [ 19.475285] init_module_from_file+0xd1/0x130 [ 19.476506] idempotent_init_module+0x23b/0x650 [ 19.477725] __x64_sys_finit_module+0xbe/0x130 [ 19.476506] idempotent_init_module+0x23b/0x650 [ 19.477725] __x64_sys_finit_module+0xbe/0x130 [ 19.478920] do_syscall_64+0x82/0x160 [ 19.480036] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 19.481292] [ 19.482205] The buggy address belongs to the object at ffff888829e65000 which belongs to the cache kmalloc-512 of size 512 [ 19.484818] The buggy address is located 0 bytes to the right of allocated 512-byte region [ffff888829e65000, ffff888829e65200) [ 19.487447] [ 19.488328] The buggy address belongs to the physical page: [ 19.489569] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888829e60c00 pfn:0x829e60 [ 19.491140] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [ 19.492466] anon flags: 0x57ffffc0000840(slab|head|node=1|zone=2|lastcpupid=0x1fffff) [ 19.493914] page_type: 0xffffffff() [ 19.494988] raw: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [ 19.496451] raw: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [ 19.497906] head: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [ 19.499379] head: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [ 19.500844] head: 0057ffffc0000003 ffffea0020a79801 ffffea0020a79848 00000000ffffffff [ 19.502316] head: 0000000800000000 0000000000000000 00000000ffffffff 0000000000000000 [ 19.503784] page dumped because: k ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49986", "url": "https://ubuntu.com/security/CVE-2024-49986", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: x86-android-tablets: Fix use after free on platform_device_register() errors x86_android_tablet_remove() frees the pdevs[] array, so it should not be used after calling x86_android_tablet_remove(). When platform_device_register() fails, store the pdevs[x] PTR_ERR() value into the local ret variable before calling x86_android_tablet_remove() to avoid using pdevs[] after it has been freed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49887", "url": "https://ubuntu.com/security/CVE-2024-49887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to don't panic system for no free segment fault injection f2fs: fix to don't panic system for no free segment fault injection syzbot reports a f2fs bug as below: F2FS-fs (loop0): inject no free segment in get_new_segment of __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3167 F2FS-fs (loop0): Stopped filesystem due to reason: 7 ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2748! CPU: 0 UID: 0 PID: 5109 Comm: syz-executor304 Not tainted 6.11.0-rc6-syzkaller-00363-g89f5e14d05b4 #0 RIP: 0010:get_new_segment fs/f2fs/segment.c:2748 [inline] RIP: 0010:new_curseg+0x1f61/0x1f70 fs/f2fs/segment.c:2836 Call Trace: __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3167 f2fs_allocate_new_section fs/f2fs/segment.c:3181 [inline] f2fs_allocate_pinning_section+0xfa/0x4e0 fs/f2fs/segment.c:3195 f2fs_expand_inode_data+0x5d6/0xbb0 fs/f2fs/file.c:1799 f2fs_fallocate+0x448/0x960 fs/f2fs/file.c:1903 vfs_fallocate+0x553/0x6c0 fs/open.c:334 do_vfs_ioctl+0x2592/0x2e50 fs/ioctl.c:886 __do_sys_ioctl fs/ioctl.c:905 [inline] __se_sys_ioctl+0x81/0x170 fs/ioctl.c:893 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: 0010:get_new_segment fs/f2fs/segment.c:2748 [inline] RIP: 0010:new_curseg+0x1f61/0x1f70 fs/f2fs/segment.c:2836 The root cause is when we inject no free segment fault into f2fs, we should not panic system, fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49888", "url": "https://ubuntu.com/security/CVE-2024-49888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix a sdiv overflow issue Zac Ecob reported a problem where a bpf program may cause kernel crash due to the following error: Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI The failure is due to the below signed divide: LLONG_MIN/-1 where LLONG_MIN equals to -9,223,372,036,854,775,808. LLONG_MIN/-1 is supposed to give a positive number 9,223,372,036,854,775,808, but it is impossible since for 64-bit system, the maximum positive number is 9,223,372,036,854,775,807. On x86_64, LLONG_MIN/-1 will cause a kernel exception. On arm64, the result for LLONG_MIN/-1 is LLONG_MIN. Further investigation found all the following sdiv/smod cases may trigger an exception when bpf program is running on x86_64 platform: - LLONG_MIN/-1 for 64bit operation - INT_MIN/-1 for 32bit operation - LLONG_MIN%-1 for 64bit operation - INT_MIN%-1 for 32bit operation where -1 can be an immediate or in a register. On arm64, there are no exceptions: - LLONG_MIN/-1 = LLONG_MIN - INT_MIN/-1 = INT_MIN - LLONG_MIN%-1 = 0 - INT_MIN%-1 = 0 where -1 can be an immediate or in a register. Insn patching is needed to handle the above cases and the patched codes produced results aligned with above arm64 result. The below are pseudo codes to handle sdiv/smod exceptions including both divisor -1 and divisor 0 and the divisor is stored in a register. sdiv: tmp = rX tmp += 1 /* [-1, 0] -> [0, 1] if tmp >(unsigned) 1 goto L2 if tmp == 0 goto L1 rY = 0 L1: rY = -rY; goto L3 L2: rY /= rX L3: smod: tmp = rX tmp += 1 /* [-1, 0] -> [0, 1] if tmp >(unsigned) 1 goto L1 if tmp == 1 (is64 ? goto L2 : goto L3) rY = 0; goto L2 L1: rY %= rX L2: goto L4 // only when !is64 L3: wY = wY // only when !is64 L4: [1] https://lore.kernel.org/bpf/tPJLTEh7S_DxFEqAI2Ji5MBSoZVg7_G-Py2iaZpAaWtM961fFTWtsnlzwvTbzBzaUzwQAoNATXKUlt0LZOFgnDcIyKCswAnAGdUF3LBrhGQ=@protonmail.com/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49987", "url": "https://ubuntu.com/security/CVE-2024-49987", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpftool: Fix undefined behavior in qsort(NULL, 0, ...) When netfilter has no entry to display, qsort is called with qsort(NULL, 0, ...). This results in undefined behavior, as UBSan reports: net.c:827:2: runtime error: null pointer passed as argument 1, which is declared to never be null Although the C standard does not explicitly state whether calling qsort with a NULL pointer when the size is 0 constitutes undefined behavior, Section 7.1.4 of the C standard (Use of library functions) mentions: \"Each of the following statements applies unless explicitly stated otherwise in the detailed descriptions that follow: If an argument to a function has an invalid value (such as a value outside the domain of the function, or a pointer outside the address space of the program, or a null pointer, or a pointer to non-modifiable storage when the corresponding parameter is not const-qualified) or a type (after promotion) not expected by a function with variable number of arguments, the behavior is undefined.\" To avoid this, add an early return when nf_link_info is NULL to prevent calling qsort with a NULL pointer.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50006", "url": "https://ubuntu.com/security/CVE-2024-50006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix i_data_sem unlock order in ext4_ind_migrate() Fuzzing reports a possible deadlock in jbd2_log_wait_commit. This issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to require synchronous updates because the file descriptor is opened with O_SYNC. This can lead to the jbd2_journal_stop() function calling jbd2_might_wait_for_commit(), potentially causing a deadlock if the EXT4_IOC_MIGRATE call races with a write(2) system call. This problem only arises when CONFIG_PROVE_LOCKING is enabled. In this case, the jbd2_might_wait_for_commit macro locks jbd2_handle in the jbd2_journal_stop function while i_data_sem is locked. This triggers lockdep because the jbd2_journal_start function might also lock the same jbd2_handle simultaneously. Found by Linux Verification Center (linuxtesting.org) with syzkaller. Rule: add", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49889", "url": "https://ubuntu.com/security/CVE-2024-49889", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid use-after-free in ext4_ext_show_leaf() In ext4_find_extent(), path may be freed by error or be reallocated, so using a previously saved *ppath may have been freed and thus may trigger use-after-free, as follows: ext4_split_extent path = *ppath; ext4_split_extent_at(ppath) path = ext4_find_extent(ppath) ext4_split_extent_at(ppath) // ext4_find_extent fails to free path // but zeroout succeeds ext4_ext_show_leaf(inode, path) eh = path[depth].p_hdr // path use-after-free !!! Similar to ext4_split_extent_at(), we use *ppath directly as an input to ext4_ext_show_leaf(). Fix a spelling error by the way. Same problem in ext4_ext_handle_unwritten_extents(). Since 'path' is only used in ext4_ext_show_leaf(), remove 'path' and use *ppath directly. This issue is triggered only when EXT_DEBUG is defined and therefore does not affect functionality.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49968", "url": "https://ubuntu.com/security/CVE-2024-49968", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: filesystems without casefold feature cannot be mounted with siphash When mounting the ext4 filesystem, if the default hash version is set to DX_HASH_SIPHASH but the casefold feature is not set, exit the mounting.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49988", "url": "https://ubuntu.com/security/CVE-2024-49988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: add refcnt to ksmbd_conn struct When sending an oplock break request, opinfo->conn is used, But freed ->conn can be used on multichannel. This patch add a reference count to the ksmbd_conn struct so that it can be freed when it is no longer used.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49890", "url": "https://ubuntu.com/security/CVE-2024-49890", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: ensure the fw_info is not null before using it This resolves the dereference null return value warning reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49891", "url": "https://ubuntu.com/security/CVE-2024-49891", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata paths When the HBA is undergoing a reset or is handling an errata event, NULL ptr dereference crashes may occur in routines such as lpfc_sli_flush_io_rings(), lpfc_dev_loss_tmo_callbk(), or lpfc_abort_handler(). Add NULL ptr checks before dereferencing hdwq pointers that may have been freed due to operations colliding with a reset or errata event handler.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49892", "url": "https://ubuntu.com/security/CVE-2024-49892", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize get_bytes_per_element's default to 1 Variables, used as denominators and maybe not assigned to other values, should not be 0. bytes_per_element_y & bytes_per_element_c are initialized by get_bytes_per_element() which should never return 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50016", "url": "https://ubuntu.com/security/CVE-2024-50016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Avoid overflow assignment in link_dp_cts sampling_rate is an uint8_t but is assigned an unsigned int, and thus it can overflow. As a result, sampling_rate is changed to uint32_t. Similarly, LINK_QUAL_PATTERN_SET has a size of 2 bits, and it should only be assigned to a value less or equal than 4. This fixes 2 INTEGER_OVERFLOW issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49893", "url": "https://ubuntu.com/security/CVE-2024-49893", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check stream_status before it is used [WHAT & HOW] dc_state_get_stream_status can return null, and therefore null must be checked before stream_status is used. This fixes 1 NULL_RETURNS issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49969", "url": "https://ubuntu.com/security/CVE-2024-49969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 color transformation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_hw_format` function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:180 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:181 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:182 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49970", "url": "https://ubuntu.com/security/CVE-2024-49970", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Implement bounds check for stream encoder creation in DCN401 'stream_enc_regs' array is an array of dcn10_stream_enc_registers structures. The array is initialized with four elements, corresponding to the four calls to stream_enc_regs() in the array initializer. This means that valid indices for this array are 0, 1, 2, and 3. The error message 'stream_enc_regs' 4 <= 5 below, is indicating that there is an attempt to access this array with an index of 5, which is out of bounds. This could lead to undefined behavior Here, eng_id is used as an index to access the stream_enc_regs array. If eng_id is 5, this would result in an out-of-bounds access on the stream_enc_regs array. Thus fixing Buffer overflow error in dcn401_stream_encoder_create Found by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn401/dcn401_resource.c:1209 dcn401_stream_encoder_create() error: buffer overflow 'stream_enc_regs' 4 <= 5", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49894", "url": "https://ubuntu.com/security/CVE-2024-49894", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in degamma hardware format translation Fixes index out of bounds issue in `cm_helper_translate_curve_to_degamma_hw_format` function. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49895", "url": "https://ubuntu.com/security/CVE-2024-49895", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format translation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_degamma_hw_format` function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:338 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:339 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:340 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49971", "url": "https://ubuntu.com/security/CVE-2024-49971", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Increase array size of dummy_boolean [WHY] dml2_core_shared_mode_support and dml_core_mode_support access the third element of dummy_boolean, i.e. hw_debug5 = &s->dummy_boolean[2], when dummy_boolean has size of 2. Any assignment to hw_debug5 causes an OVERRUN. [HOW] Increase dummy_boolean's array size to 3. This fixes 2 OVERRUN issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49972", "url": "https://ubuntu.com/security/CVE-2024-49972", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Deallocate DML memory if allocation fails [Why] When DC state create DML memory allocation fails, memory is not deallocated subsequently, resulting in uninitialized structure that is not NULL. [How] Deallocate memory if DML memory allocation fails.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49896", "url": "https://ubuntu.com/security/CVE-2024-49896", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check stream before comparing them [WHAT & HOW] amdgpu_dm can pass a null stream to dc_is_stream_unchanged. It is necessary to check for null before dereferencing them. This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49897", "url": "https://ubuntu.com/security/CVE-2024-49897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check phantom_stream before it is used dcn32_enable_phantom_stream can return null, so returned value must be checked before used. This fixes 1 NULL_RETURNS issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49898", "url": "https://ubuntu.com/security/CVE-2024-49898", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null-initialized variables [WHAT & HOW] drr_timing and subvp_pipe are initialized to null and they are not always assigned new values. It is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49899", "url": "https://ubuntu.com/security/CVE-2024-49899", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize denominators' default to 1 [WHAT & HOW] Variables used as denominators and maybe not assigned to other values, should not be 0. Change their default to 1 so they are never 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49900", "url": "https://ubuntu.com/security/CVE-2024-49900", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uninit-value access of new_ea in ea_buffer syzbot reports that lzo1x_1_do_compress is using uninit-value: ===================================================== BUG: KMSAN: uninit-value in lzo1x_1_do_compress+0x19f9/0x2510 lib/lzo/lzo1x_compress.c:178 ... Uninit was stored to memory at: ea_put fs/jfs/xattr.c:639 [inline] ... Local variable ea_buf created at: __jfs_setxattr+0x5d/0x1ae0 fs/jfs/xattr.c:662 __jfs_xattr_set+0xe6/0x1f0 fs/jfs/xattr.c:934 ===================================================== The reason is ea_buf->new_ea is not initialized properly. Fix this by using memset to empty its content at the beginning in ea_get().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49901", "url": "https://ubuntu.com/security/CVE-2024-49901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm/adreno: Assign msm_gpu->pdev earlier to avoid nullptrs There are some cases, such as the one uncovered by Commit 46d4efcccc68 (\"drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails\") where msm_gpu_cleanup() : platform_set_drvdata(gpu->pdev, NULL); is called on gpu->pdev == NULL, as the GPU device has not been fully initialized yet. Turns out that there's more than just the aforementioned path that causes this to happen (e.g. the case when there's speedbin data in the catalog, but opp-supported-hw is missing in DT). Assigning msm_gpu->pdev earlier seems like the least painful solution to this, therefore do so. Patchwork: https://patchwork.freedesktop.org/patch/602742/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49902", "url": "https://ubuntu.com/security/CVE-2024-49902", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: check if leafidx greater than num leaves per dmap tree syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf. Shaggy: Modified sanity check to apply to control pages as well as leaf pages.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49903", "url": "https://ubuntu.com/security/CVE-2024-49903", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uaf in dbFreeBits [syzbot reported] ================================================================== BUG: KASAN: slab-use-after-free in __mutex_lock_common kernel/locking/mutex.c:587 [inline] BUG: KASAN: slab-use-after-free in __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 Read of size 8 at addr ffff8880229254b0 by task syz-executor357/5216 CPU: 0 UID: 0 PID: 5216 Comm: syz-executor357 Not tainted 6.11.0-rc3-syzkaller-00156-gd7a5aa4b3c00 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 __mutex_lock_common kernel/locking/mutex.c:587 [inline] __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 dbFreeBits+0x7ea/0xd90 fs/jfs/jfs_dmap.c:2390 dbFreeDmap fs/jfs/jfs_dmap.c:2089 [inline] dbFree+0x35b/0x680 fs/jfs/jfs_dmap.c:409 dbDiscardAG+0x8a9/0xa20 fs/jfs/jfs_dmap.c:1650 jfs_ioc_trim+0x433/0x670 fs/jfs/jfs_discard.c:100 jfs_ioctl+0x2d0/0x3e0 fs/jfs/ioctl.c:131 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 Freed by task 5218: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object+0xe0/0x150 mm/kasan/common.c:240 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2252 [inline] slab_free mm/slub.c:4473 [inline] kfree+0x149/0x360 mm/slub.c:4594 dbUnmount+0x11d/0x190 fs/jfs/jfs_dmap.c:278 jfs_mount_rw+0x4ac/0x6a0 fs/jfs/jfs_mount.c:247 jfs_remount+0x3d1/0x6b0 fs/jfs/super.c:454 reconfigure_super+0x445/0x880 fs/super.c:1083 vfs_cmd_reconfigure fs/fsopen.c:263 [inline] vfs_fsconfig_locked fs/fsopen.c:292 [inline] __do_sys_fsconfig fs/fsopen.c:473 [inline] __se_sys_fsconfig+0xb6e/0xf80 fs/fsopen.c:345 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 [Analysis] There are two paths (dbUnmount and jfs_ioc_trim) that generate race condition when accessing bmap, which leads to the occurrence of uaf. Use the lock s_umount to synchronize them, in order to avoid uaf caused by race condition.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49904", "url": "https://ubuntu.com/security/CVE-2024-49904", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add list empty check to avoid null pointer issue Add list empty check to avoid null pointer issues in some corner cases. - list_for_each_entry_safe()", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49989", "url": "https://ubuntu.com/security/CVE-2024-49989", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix double free issue during amdgpu module unload Flexible endpoints use DIGs from available inflexible endpoints, so only the encoders of inflexible links need to be freed. Otherwise, a double free issue may occur when unloading the amdgpu module. [ 279.190523] RIP: 0010:__slab_free+0x152/0x2f0 [ 279.190577] Call Trace: [ 279.190580] [ 279.190582] ? show_regs+0x69/0x80 [ 279.190590] ? die+0x3b/0x90 [ 279.190595] ? do_trap+0xc8/0xe0 [ 279.190601] ? do_error_trap+0x73/0xa0 [ 279.190605] ? __slab_free+0x152/0x2f0 [ 279.190609] ? exc_invalid_op+0x56/0x70 [ 279.190616] ? __slab_free+0x152/0x2f0 [ 279.190642] ? asm_exc_invalid_op+0x1f/0x30 [ 279.190648] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191096] ? __slab_free+0x152/0x2f0 [ 279.191102] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191469] kfree+0x260/0x2b0 [ 279.191474] dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191821] link_destroy+0xd7/0x130 [amdgpu] [ 279.192248] dc_destruct+0x90/0x270 [amdgpu] [ 279.192666] dc_destroy+0x19/0x40 [amdgpu] [ 279.193020] amdgpu_dm_fini+0x16e/0x200 [amdgpu] [ 279.193432] dm_hw_fini+0x26/0x40 [amdgpu] [ 279.193795] amdgpu_device_fini_hw+0x24c/0x400 [amdgpu] [ 279.194108] amdgpu_driver_unload_kms+0x4f/0x70 [amdgpu] [ 279.194436] amdgpu_pci_remove+0x40/0x80 [amdgpu] [ 279.194632] pci_device_remove+0x3a/0xa0 [ 279.194638] device_remove+0x40/0x70 [ 279.194642] device_release_driver_internal+0x1ad/0x210 [ 279.194647] driver_detach+0x4e/0xa0 [ 279.194650] bus_remove_driver+0x6f/0xf0 [ 279.194653] driver_unregister+0x33/0x60 [ 279.194657] pci_unregister_driver+0x44/0x90 [ 279.194662] amdgpu_exit+0x19/0x1f0 [amdgpu] [ 279.194939] __do_sys_delete_module.isra.0+0x198/0x2f0 [ 279.194946] __x64_sys_delete_module+0x16/0x20 [ 279.194950] do_syscall_64+0x58/0x120 [ 279.194954] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 279.194980] ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49905", "url": "https://ubuntu.com/security/CVE-2024-49905", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for 'afb' in amdgpu_dm_plane_handle_cursor_update (v2) This commit adds a null check for the 'afb' variable in the amdgpu_dm_plane_handle_cursor_update function. Previously, 'afb' was assumed to be null, but was used later in the code without a null check. This could potentially lead to a null pointer dereference. Changes since v1: - Moved the null check for 'afb' to the line where 'afb' is used. (Alex) Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:1298 amdgpu_dm_plane_handle_cursor_update() error: we previously assumed 'afb' could be null (see line 1252)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49906", "url": "https://ubuntu.com/security/CVE-2024-49906", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before try to access it [why & how] Change the order of the pipe_ctx->plane_state check to ensure that plane_state is not null before accessing it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49907", "url": "https://ubuntu.com/security/CVE-2024-49907", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before using dc->clk_mgr [WHY & HOW] dc->clk_mgr is null checked previously in the same function, indicating it might be null. Passing \"dc\" to \"dc->hwss.apply_idle_power_optimizations\", which dereferences null \"dc->clk_mgr\". (The function pointer resolves to \"dcn35_apply_idle_power_optimizations\".) This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49908", "url": "https://ubuntu.com/security/CVE-2024-49908", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for 'afb' in amdgpu_dm_update_cursor (v2) This commit adds a null check for the 'afb' variable in the amdgpu_dm_update_cursor function. Previously, 'afb' was assumed to be null at line 8388, but was used later in the code without a null check. This could potentially lead to a null pointer dereference. Changes since v1: - Moved the null check for 'afb' to the line where 'afb' is used. (Alex) Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:8433 amdgpu_dm_update_cursor() \terror: we previously assumed 'afb' could be null (see line 8388)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50177", "url": "https://ubuntu.com/security/CVE-2024-50177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix a UBSAN warning in DML2.1 When programming phantom pipe, since cursor_width is explicity set to 0, this causes calculation logic to trigger overflow for an unsigned int triggering the kernel's UBSAN check as below: [ 40.962845] UBSAN: shift-out-of-bounds in /tmp/amd.EfpumTkO/amd/amdgpu/../display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c:3312:34 [ 40.962849] shift exponent 4294967170 is too large for 32-bit type 'unsigned int' [ 40.962852] CPU: 1 PID: 1670 Comm: gnome-shell Tainted: G W OE 6.5.0-41-generic #41~22.04.2-Ubuntu [ 40.962854] Hardware name: Gigabyte Technology Co., Ltd. X670E AORUS PRO X/X670E AORUS PRO X, BIOS F21 01/10/2024 [ 40.962856] Call Trace: [ 40.962857] [ 40.962860] dump_stack_lvl+0x48/0x70 [ 40.962870] dump_stack+0x10/0x20 [ 40.962872] __ubsan_handle_shift_out_of_bounds+0x1ac/0x360 [ 40.962878] calculate_cursor_req_attributes.cold+0x1b/0x28 [amdgpu] [ 40.963099] dml_core_mode_support+0x6b91/0x16bc0 [amdgpu] [ 40.963327] ? srso_alias_return_thunk+0x5/0x7f [ 40.963331] ? CalculateWatermarksMALLUseAndDRAMSpeedChangeSupport+0x18b8/0x2790 [amdgpu] [ 40.963534] ? srso_alias_return_thunk+0x5/0x7f [ 40.963536] ? dml_core_mode_support+0xb3db/0x16bc0 [amdgpu] [ 40.963730] dml2_core_calcs_mode_support_ex+0x2c/0x90 [amdgpu] [ 40.963906] ? srso_alias_return_thunk+0x5/0x7f [ 40.963909] ? dml2_core_calcs_mode_support_ex+0x2c/0x90 [amdgpu] [ 40.964078] core_dcn4_mode_support+0x72/0xbf0 [amdgpu] [ 40.964247] dml2_top_optimization_perform_optimization_phase+0x1d3/0x2a0 [amdgpu] [ 40.964420] dml2_build_mode_programming+0x23d/0x750 [amdgpu] [ 40.964587] dml21_validate+0x274/0x770 [amdgpu] [ 40.964761] ? srso_alias_return_thunk+0x5/0x7f [ 40.964763] ? resource_append_dpp_pipes_for_plane_composition+0x27c/0x3b0 [amdgpu] [ 40.964942] dml2_validate+0x504/0x750 [amdgpu] [ 40.965117] ? dml21_copy+0x95/0xb0 [amdgpu] [ 40.965291] ? srso_alias_return_thunk+0x5/0x7f [ 40.965295] dcn401_validate_bandwidth+0x4e/0x70 [amdgpu] [ 40.965491] update_planes_and_stream_state+0x38d/0x5c0 [amdgpu] [ 40.965672] update_planes_and_stream_v3+0x52/0x1e0 [amdgpu] [ 40.965845] ? srso_alias_return_thunk+0x5/0x7f [ 40.965849] dc_update_planes_and_stream+0x71/0xb0 [amdgpu] Fix this by adding a guard for checking cursor width before triggering the size calculation.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49909", "url": "https://ubuntu.com/security/CVE-2024-49909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn32_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn32_set_output_transfer_func function. Previously, set_output_gamma was being checked for null, but then it was being dereferenced without any null check. This could lead to a null pointer dereference if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49910", "url": "https://ubuntu.com/security/CVE-2024-49910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn401_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn401_set_output_transfer_func function. Previously, set_output_gamma was being checked for null, but then it was being dereferenced without any null check. This could lead to a null pointer dereference if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49911", "url": "https://ubuntu.com/security/CVE-2024-49911", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn20_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn20_set_output_transfer_func function. Previously, set_output_gamma was being checked for null at line 1030, but then it was being dereferenced without any null check at line 1048. This could potentially lead to a null pointer dereference error if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma at line 1048.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49912", "url": "https://ubuntu.com/security/CVE-2024-49912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Handle null 'stream_status' in 'planes_changed_for_existing_stream' This commit adds a null check for 'stream_status' in the function 'planes_changed_for_existing_stream'. Previously, the code assumed 'stream_status' could be null, but did not handle the case where it was actually null. This could lead to a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:3784 planes_changed_for_existing_stream() error: we previously assumed 'stream_status' could be null (see line 3774)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49913", "url": "https://ubuntu.com/security/CVE-2024-49913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for top_pipe_to_program in commit_planes_for_stream This commit addresses a null pointer dereference issue in the `commit_planes_for_stream` function at line 4140. The issue could occur when `top_pipe_to_program` is null. The fix adds a check to ensure `top_pipe_to_program` is not null before accessing its stream_res. This prevents a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:4140 commit_planes_for_stream() error: we previously assumed 'top_pipe_to_program' could be null (see line 3906)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49914", "url": "https://ubuntu.com/security/CVE-2024-49914", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for pipe_ctx->plane_state in dcn20_program_pipe This commit addresses a null pointer dereference issue in the `dcn20_program_pipe` function. The issue could occur when `pipe_ctx->plane_state` is null. The fix adds a check to ensure `pipe_ctx->plane_state` is not null before accessing. This prevents a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn20/dcn20_hwseq.c:1925 dcn20_program_pipe() error: we previously assumed 'pipe_ctx->plane_state' could be null (see line 1877)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49915", "url": "https://ubuntu.com/security/CVE-2024-49915", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr in dcn32_init_hw This commit addresses a potential null pointer dereference issue in the `dcn32_init_hw` function. The issue could occur when `dc->clk_mgr` is null. The fix adds a check to ensure `dc->clk_mgr` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn32/dcn32_hwseq.c:961 dcn32_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 782)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49916", "url": "https://ubuntu.com/security/CVE-2024-49916", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in dcn401_init_hw This commit addresses a potential null pointer dereference issue in the `dcn401_init_hw` function. The issue could occur when `dc->clk_mgr` or `dc->clk_mgr->funcs` is null. The fix adds a check to ensure `dc->clk_mgr` and `dc->clk_mgr->funcs` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn401/dcn401_hwseq.c:416 dcn401_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 225)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49917", "url": "https://ubuntu.com/security/CVE-2024-49917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in dcn30_init_hw This commit addresses a potential null pointer dereference issue in the `dcn30_init_hw` function. The issue could occur when `dc->clk_mgr` or `dc->clk_mgr->funcs` is null. The fix adds a check to ensure `dc->clk_mgr` and `dc->clk_mgr->funcs` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:789 dcn30_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 628)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49918", "url": "https://ubuntu.com/security/CVE-2024-49918", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for head_pipe in dcn32_acquire_idle_pipe_for_head_pipe_in_layer This commit addresses a potential null pointer dereference issue in the `dcn32_acquire_idle_pipe_for_head_pipe_in_layer` function. The issue could occur when `head_pipe` is null. The fix adds a check to ensure `head_pipe` is not null before asserting it. If `head_pipe` is null, the function returns NULL to prevent a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn32/dcn32_resource.c:2690 dcn32_acquire_idle_pipe_for_head_pipe_in_layer() error: we previously assumed 'head_pipe' could be null (see line 2681)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49919", "url": "https://ubuntu.com/security/CVE-2024-49919", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for head_pipe in dcn201_acquire_free_pipe_for_layer This commit addresses a potential null pointer dereference issue in the `dcn201_acquire_free_pipe_for_layer` function. The issue could occur when `head_pipe` is null. The fix adds a check to ensure `head_pipe` is not null before asserting it. If `head_pipe` is null, the function returns NULL to prevent a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn201/dcn201_resource.c:1016 dcn201_acquire_free_pipe_for_layer() error: we previously assumed 'head_pipe' could be null (see line 1010)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49991", "url": "https://ubuntu.com/security/CVE-2024-49991", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer Pass pointer reference to amdgpu_bo_unref to clear the correct pointer, otherwise amdgpu_bo_unref clear the local variable, the original pointer not set to NULL, this could cause use-after-free bug.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49920", "url": "https://ubuntu.com/security/CVE-2024-49920", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before multiple uses [WHAT & HOW] Poniters, such as stream_enc and dc->bw_vbios, are null checked previously in the same function, so Coverity warns \"implies that stream_enc and dc->bw_vbios might be null\". They are used multiple times in the subsequent code and need to be checked. This fixes 10 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49921", "url": "https://ubuntu.com/security/CVE-2024-49921", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before used [WHAT & HOW] Poniters, such as dc->clk_mgr, are null checked previously in the same function, so Coverity warns \"implies that \"dc->clk_mgr\" might be null\". As a result, these pointers need to be checked when used again. This fixes 10 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49922", "url": "https://ubuntu.com/security/CVE-2024-49922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before using them [WHAT & HOW] These pointers are null checked previously in the same function, indicating they might be null as reported by Coverity. As a result, they need to be checked when used again. This fixes 3 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49923", "url": "https://ubuntu.com/security/CVE-2024-49923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Pass non-null to dcn20_validate_apply_pipe_split_flags [WHAT & HOW] \"dcn20_validate_apply_pipe_split_flags\" dereferences merge, and thus it cannot be a null pointer. Let's pass a valid pointer to avoid null dereference. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49992", "url": "https://ubuntu.com/security/CVE-2024-49992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/stm: Avoid use-after-free issues with crtc and plane ltdc_load() calls functions drm_crtc_init_with_planes(), drm_universal_plane_init() and drm_encoder_init(). These functions should not be called with parameters allocated with devm_kzalloc() to avoid use-after-free issues [1]. Use allocations managed by the DRM framework. Found by Linux Verification Center (linuxtesting.org). [1] https://lore.kernel.org/lkml/u366i76e3qhh3ra5oxrtngjtm2u5lterkekcz6y2jkndhuxzli@diujon4h7qwb/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49993", "url": "https://ubuntu.com/security/CVE-2024-49993", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49924", "url": "https://ubuntu.com/security/CVE-2024-49924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: pxafb: Fix possible use after free in pxafb_task() In the pxafb_probe function, it calls the pxafb_init_fbinfo function, after which &fbi->task is associated with pxafb_task. Moreover, within this pxafb_init_fbinfo function, the pxafb_blank function within the &pxafb_ops struct is capable of scheduling work. If we remove the module which will call pxafb_remove to make cleanup, it will call unregister_framebuffer function which can call do_unregister_framebuffer to free fbi->fb through put_fb_info(fb_info), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | pxafb_task pxafb_remove | unregister_framebuffer(info) | do_unregister_framebuffer(fb_info) | put_fb_info(fb_info) | // free fbi->fb | set_ctrlr_state(fbi, state) | __pxafb_lcd_power(fbi, 0) | fbi->lcd_power(on, &fbi->fb.var) | //use fbi->fb Fix it by ensuring that the work is canceled before proceeding with the cleanup in pxafb_remove. Note that only root user can remove the driver at runtime.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49925", "url": "https://ubuntu.com/security/CVE-2024-49925", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: efifb: Register sysfs groups through driver core The driver core can register and cleanup sysfs groups already. Make use of that functionality to simplify the error handling and cleanup. Also avoid a UAF race during unregistering where the sysctl attributes were usable after the info struct was freed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49926", "url": "https://ubuntu.com/security/CVE-2024-49926", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rcu-tasks: Fix access non-existent percpu rtpcp variable in rcu_tasks_need_gpcb() For kernels built with CONFIG_FORCE_NR_CPUS=y, the nr_cpu_ids is defined as NR_CPUS instead of the number of possible cpus, this will cause the following system panic: smpboot: Allowing 4 CPUs, 0 hotplug CPUs ... setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:512 nr_node_ids:1 ... BUG: unable to handle page fault for address: ffffffff9911c8c8 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 15 Comm: rcu_tasks_trace Tainted: G W 6.6.21 #1 5dc7acf91a5e8e9ac9dcfc35bee0245691283ea6 RIP: 0010:rcu_tasks_need_gpcb+0x25d/0x2c0 RSP: 0018:ffffa371c00a3e60 EFLAGS: 00010082 CR2: ffffffff9911c8c8 CR3: 000000040fa20005 CR4: 00000000001706f0 Call Trace: ? __die+0x23/0x80 ? page_fault_oops+0xa4/0x180 ? exc_page_fault+0x152/0x180 ? asm_exc_page_fault+0x26/0x40 ? rcu_tasks_need_gpcb+0x25d/0x2c0 ? __pfx_rcu_tasks_kthread+0x40/0x40 rcu_tasks_one_gp+0x69/0x180 rcu_tasks_kthread+0x94/0xc0 kthread+0xe8/0x140 ? __pfx_kthread+0x40/0x40 ret_from_fork+0x34/0x80 ? __pfx_kthread+0x40/0x40 ret_from_fork_asm+0x1b/0x80 Considering that there may be holes in the CPU numbers, use the maximum possible cpu number, instead of nr_cpu_ids, for configuring enqueue and dequeue limits. [ neeraj.upadhyay: Fix htmldocs build error reported by Stephen Rothwell ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50007", "url": "https://ubuntu.com/security/CVE-2024-50007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: asihpi: Fix potential OOB array access ASIHPI driver stores some values in the static array upon a response from the driver, and its index depends on the firmware. We shouldn't trust it blindly. This patch adds a sanity check of the array index to fit in the array size.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50017", "url": "https://ubuntu.com/security/CVE-2024-50017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm/ident_map: Use gbpages only where full GB page should be mapped. When ident_pud_init() uses only GB pages to create identity maps, large ranges of addresses not actually requested can be included in the resulting table; a 4K request will map a full GB. This can include a lot of extra address space past that requested, including areas marked reserved by the BIOS. That allows processor speculation into reserved regions, that on UV systems can cause system halts. Only use GB pages when map creation requests include the full GB page of space. Fall back to using smaller 2M pages when only portions of a GB page are included in the request. No attempt is made to coalesce mapping requests. If a request requires a map entry at the 2M (pmd) level, subsequent mapping requests within the same 1G region will also be at the pmd level, even if adjacent or overlapping such requests could have been combined to map a full GB page. Existing usage starts with larger regions and then adds smaller regions, so this should not have any great consequence.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49927", "url": "https://ubuntu.com/security/CVE-2024-49927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/ioapic: Handle allocation failures gracefully Breno observed panics when using failslab under certain conditions during runtime: can not alloc irq_pin_list (-1,0,20) Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed panic+0x4e9/0x590 mp_irqdomain_alloc+0x9ab/0xa80 irq_domain_alloc_irqs_locked+0x25d/0x8d0 __irq_domain_alloc_irqs+0x80/0x110 mp_map_pin_to_irq+0x645/0x890 acpi_register_gsi_ioapic+0xe6/0x150 hpet_open+0x313/0x480 That's a pointless panic which is a leftover of the historic IO/APIC code which panic'ed during early boot when the interrupt allocation failed. The only place which might justify panic is the PIT/HPET timer_check() code which tries to figure out whether the timer interrupt is delivered through the IO/APIC. But that code does not require to handle interrupt allocation failures. If the interrupt cannot be allocated then timer delivery fails and it either panics due to that or falls back to legacy mode. Cure this by removing the panic wrapper around __add_pin_to_irq_node() and making mp_irqdomain_alloc() aware of the failure condition and handle it as any other failure in this function gracefully.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50008", "url": "https://ubuntu.com/security/CVE-2024-50008", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_cmd_802_11_scan_ext() Replace one-element array with a flexible-array member in `struct host_cmd_ds_802_11_scan_ext`. With this, fix the following warning: elo 16 17:51:58 surfacebook kernel: ------------[ cut here ]------------ elo 16 17:51:58 surfacebook kernel: memcpy: detected field-spanning write (size 243) of single field \"ext_scan->tlv_buffer\" at drivers/net/wireless/marvell/mwifiex/scan.c:2239 (size 1) elo 16 17:51:58 surfacebook kernel: WARNING: CPU: 0 PID: 498 at drivers/net/wireless/marvell/mwifiex/scan.c:2239 mwifiex_cmd_802_11_scan_ext+0x83/0x90 [mwifiex]", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50018", "url": "https://ubuntu.com/security/CVE-2024-50018", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49928", "url": "https://ubuntu.com/security/CVE-2024-49928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: avoid reading out of bounds when loading TX power FW elements Because the loop-expression will do one more time before getting false from cond-expression, the original code copied one more entry size beyond valid region. Fix it by moving the entry copy to loop-body.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50178", "url": "https://ubuntu.com/security/CVE-2024-50178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: loongson3: Use raw_smp_processor_id() in do_service_request() Use raw_smp_processor_id() instead of plain smp_processor_id() in do_service_request(), otherwise we may get some errors with the driver enabled: BUG: using smp_processor_id() in preemptible [00000000] code: (udev-worker)/208 caller is loongson3_cpufreq_probe+0x5c/0x250 [loongson3_cpufreq]", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50009", "url": "https://ubuntu.com/security/CVE-2024-50009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: amd-pstate: add check for cpufreq_cpu_get's return value cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it and return in case of error. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49994", "url": "https://ubuntu.com/security/CVE-2024-49994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix integer overflow in BLKSECDISCARD I independently rediscovered \tcommit 22d24a544b0d49bbcbd61c8c0eaf77d3c9297155 \tblock: fix overflow in blk_ioctl_discard() but for secure erase. Same problem: \tuint64_t r[2] = {512, 18446744073709551104ULL}; \tioctl(fd, BLKSECDISCARD, r); will enter near infinite loop inside blkdev_issue_secure_erase(): \ta.out: attempt to access beyond end of device \tloop0: rw=5, sector=3399043073, nr_sectors = 1024 limit=2048 \tbio_check_eod: 3286214 callbacks suppressed", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49929", "url": "https://ubuntu.com/security/CVE-2024-49929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: avoid NULL pointer dereference iwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta pointer is not NULL. It retrieves this pointer using iwl_mvm_sta_from_mac80211, which is dereferencing the ieee80211_sta pointer. If sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL pointer. Fix this by checking the sta pointer before retrieving the mvmsta from it. If sta is not NULL, then mvmsta isn't either.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49995", "url": "https://ubuntu.com/security/CVE-2024-49995", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: guard against string buffer overrun Smatch reports that copying media_name and if_name to name_parts may overwrite the destination. .../bearer.c:166 bearer_name_validate() error: strcpy() 'media_name' too large for 'name_parts->media_name' (32 vs 16) .../bearer.c:167 bearer_name_validate() error: strcpy() 'if_name' too large for 'name_parts->if_name' (1010102 vs 16) This does seem to be the case so guard against this possibility by using strscpy() and failing if truncation occurs. Introduced by commit b97bf3fd8f6a (\"[TIPC] Initial merge\") Compile tested only.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49962", "url": "https://ubuntu.com/security/CVE-2024-49962", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in acpi_db_convert_to_package() ACPICA commit 4d4547cf13cca820ff7e0f859ba83e1a610b9fd0 ACPI_ALLOCATE_ZEROED() may fail, elements might be NULL and will cause NULL pointer dereference later. [ rjw: Subject and changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49930", "url": "https://ubuntu.com/security/CVE-2024-49930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix array out-of-bound access in SoC stats Currently, the ath11k_soc_dp_stats::hal_reo_error array is defined with a maximum size of DP_REO_DST_RING_MAX. However, the ath11k_dp_process_rx() function access ath11k_soc_dp_stats::hal_reo_error using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath11k_dp_process_rx() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49931", "url": "https://ubuntu.com/security/CVE-2024-49931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix array out-of-bound access in SoC stats Currently, the ath12k_soc_dp_stats::hal_reo_error array is defined with a maximum size of DP_REO_DST_RING_MAX. However, the ath12k_dp_rx_process() function access ath12k_soc_dp_stats::hal_reo_error using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath12k_dp_rx_process() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49932", "url": "https://ubuntu.com/security/CVE-2024-49932", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: don't readahead the relocation inode on RST On relocation we're doing readahead on the relocation inode, but if the filesystem is backed by a RAID stripe tree we can get ENOENT (e.g. due to preallocated extents not being mapped in the RST) from the lookup. But readahead doesn't handle the error and submits invalid reads to the device, causing an assertion in the scatter-gather list code: BTRFS info (device nvme1n1): balance: start -d -m -s BTRFS info (device nvme1n1): relocating block group 6480920576 flags data|raid0 BTRFS error (device nvme1n1): cannot find raid-stripe for logical [6481928192, 6481969152] devid 2, profile raid0 ------------[ cut here ]------------ kernel BUG at include/linux/scatterlist.h:115! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 1012 Comm: btrfs Not tainted 6.10.0-rc7+ #567 RIP: 0010:__blk_rq_map_sg+0x339/0x4a0 RSP: 0018:ffffc90001a43820 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffea00045d4802 RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000 RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000001000 R12: ffff8881003d10b8 R13: ffffc90001a438f0 R14: 0000000000000000 R15: 0000000000003000 FS: 00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000002cd11000 CR3: 00000001109ea001 CR4: 0000000000370eb0 Call Trace: ? __die_body.cold+0x14/0x25 ? die+0x2e/0x50 ? do_trap+0xca/0x110 ? do_error_trap+0x65/0x80 ? __blk_rq_map_sg+0x339/0x4a0 ? exc_invalid_op+0x50/0x70 ? __blk_rq_map_sg+0x339/0x4a0 ? asm_exc_invalid_op+0x1a/0x20 ? __blk_rq_map_sg+0x339/0x4a0 nvme_prep_rq.part.0+0x9d/0x770 nvme_queue_rq+0x7d/0x1e0 __blk_mq_issue_directly+0x2a/0x90 ? blk_mq_get_budget_and_tag+0x61/0x90 blk_mq_try_issue_list_directly+0x56/0xf0 blk_mq_flush_plug_list.part.0+0x52b/0x5d0 __blk_flush_plug+0xc6/0x110 blk_finish_plug+0x28/0x40 read_pages+0x160/0x1c0 page_cache_ra_unbounded+0x109/0x180 relocate_file_extent_cluster+0x611/0x6a0 ? btrfs_search_slot+0xba4/0xd20 ? balance_dirty_pages_ratelimited_flags+0x26/0xb00 relocate_data_extent.constprop.0+0x134/0x160 relocate_block_group+0x3f2/0x500 btrfs_relocate_block_group+0x250/0x430 btrfs_relocate_chunk+0x3f/0x130 btrfs_balance+0x71b/0xef0 ? kmalloc_trace_noprof+0x13b/0x280 btrfs_ioctl+0x2c2e/0x3030 ? kvfree_call_rcu+0x1e6/0x340 ? list_lru_add_obj+0x66/0x80 ? mntput_no_expire+0x3a/0x220 __x64_sys_ioctl+0x96/0xc0 do_syscall_64+0x54/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fcc04514f9b Code: Unable to access opcode bytes at 0x7fcc04514f71. RSP: 002b:00007ffeba923370 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fcc04514f9b RDX: 00007ffeba923460 RSI: 00000000c4009420 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000013 R09: 0000000000000001 R10: 00007fcc043fbba8 R11: 0000000000000246 R12: 00007ffeba924fc5 R13: 00007ffeba923460 R14: 0000000000000002 R15: 00000000004d4bb0 Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:__blk_rq_map_sg+0x339/0x4a0 RSP: 0018:ffffc90001a43820 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffea00045d4802 RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000 RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000001000 R12: ffff8881003d10b8 R13: ffffc90001a438f0 R14: 0000000000000000 R15: 0000000000003000 FS: 00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcc04514f71 CR3: 00000001109ea001 CR4: 0000000000370eb0 Kernel p ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49933", "url": "https://ubuntu.com/security/CVE-2024-49933", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk_iocost: fix more out of bound shifts Recently running UBSAN caught few out of bound shifts in the ioc_forgive_debts() function: UBSAN: shift-out-of-bounds in block/blk-iocost.c:2142:38 shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long long') ... UBSAN: shift-out-of-bounds in block/blk-iocost.c:2144:30 shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long long') ... Call Trace: dump_stack_lvl+0xca/0x130 __ubsan_handle_shift_out_of_bounds+0x22c/0x280 ? __lock_acquire+0x6441/0x7c10 ioc_timer_fn+0x6cec/0x7750 ? blk_iocost_init+0x720/0x720 ? call_timer_fn+0x5d/0x470 call_timer_fn+0xfa/0x470 ? blk_iocost_init+0x720/0x720 __run_timer_base+0x519/0x700 ... Actual impact of this issue was not identified but I propose to fix the undefined behaviour. The proposed fix to prevent those out of bound shifts consist of precalculating exponent before using it the shift operations by taking min value from the actual exponent and maximum possible number of bits.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49934", "url": "https://ubuntu.com/security/CVE-2024-49934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/inode: Prevent dump_mapping() accessing invalid dentry.d_name.name It's observed that a crash occurs during hot-remove a memory device, in which user is accessing the hugetlb. See calltrace as following: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 14045 at arch/x86/mm/fault.c:1278 do_user_addr_fault+0x2a0/0x790 Modules linked in: kmem device_dax cxl_mem cxl_pmem cxl_port cxl_pci dax_hmem dax_pmem nd_pmem cxl_acpi nd_btt cxl_core crc32c_intel nvme virtiofs fuse nvme_core nfit libnvdimm dm_multipath scsi_dh_rdac scsi_dh_emc s mirror dm_region_hash dm_log dm_mod CPU: 1 PID: 14045 Comm: daxctl Not tainted 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:do_user_addr_fault+0x2a0/0x790 Code: 48 8b 00 a8 04 0f 84 b5 fe ff ff e9 1c ff ff ff 4c 89 e9 4c 89 e2 be 01 00 00 00 bf 02 00 00 00 e8 b5 ef 24 00 e9 42 fe ff ff <0f> 0b 48 83 c4 08 4c 89 ea 48 89 ee 4c 89 e7 5b 5d 41 5c 41 5d 41 RSP: 0000:ffffc90000a575f0 EFLAGS: 00010046 RAX: ffff88800c303600 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000001000 RSI: ffffffff82504162 RDI: ffffffff824b2c36 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffc90000a57658 R13: 0000000000001000 R14: ffff88800bc2e040 R15: 0000000000000000 FS: 00007f51cb57d880(0000) GS:ffff88807fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000001000 CR3: 00000000072e2004 CR4: 00000000001706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn+0x8d/0x190 ? do_user_addr_fault+0x2a0/0x790 ? report_bug+0x1c3/0x1d0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? do_user_addr_fault+0x2a0/0x790 ? exc_page_fault+0x31/0x200 exc_page_fault+0x68/0x200 <...snip...> BUG: unable to handle page fault for address: 0000000000001000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI ---[ end trace 0000000000000000 ]--- BUG: unable to handle page fault for address: 0000000000001000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 14045 Comm: daxctl Kdump: loaded Tainted: G W 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:dentry_name+0x1f4/0x440 <...snip...> ? dentry_name+0x2fa/0x440 vsnprintf+0x1f3/0x4f0 vprintk_store+0x23a/0x540 vprintk_emit+0x6d/0x330 _printk+0x58/0x80 dump_mapping+0x10b/0x1a0 ? __pfx_free_object_rcu+0x10/0x10 __dump_page+0x26b/0x3e0 ? vprintk_emit+0xe0/0x330 ? _printk+0x58/0x80 ? dump_page+0x17/0x50 dump_page+0x17/0x50 do_migrate_range+0x2f7/0x7f0 ? do_migrate_range+0x42/0x7f0 ? offline_pages+0x2f4/0x8c0 offline_pages+0x60a/0x8c0 memory_subsys_offline+0x9f/0x1c0 ? lockdep_hardirqs_on+0x77/0x100 ? _raw_spin_unlock_irqrestore+0x38/0x60 device_offline+0xe3/0x110 state_store+0x6e/0xc0 kernfs_fop_write_iter+0x143/0x200 vfs_write+0x39f/0x560 ksys_write+0x65/0xf0 do_syscall_64+0x62/0x130 Previously, some sanity check have been done in dump_mapping() before the print facility parsing '%pd' though, it's still possible to run into an invalid dentry.d_name.name. Since dump_mapping() only needs to dump the filename only, retrieve it by itself in a safer way to prevent an unnecessary crash. Note that either retrieving the filename with '%pd' or strncpy_from_kernel_nofault(), the filename could be unreliable.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49935", "url": "https://ubuntu.com/security/CVE-2024-49935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: PAD: fix crash in exit_round_robin() The kernel occasionally crashes in cpumask_clear_cpu(), which is called within exit_round_robin(), because when executing clear_bit(nr, addr) with nr set to 0xffffffff, the address calculation may cause misalignment within the memory, leading to access to an invalid memory address. ---------- BUG: unable to handle kernel paging request at ffffffffe0740618 ... CPU: 3 PID: 2919323 Comm: acpi_pad/14 Kdump: loaded Tainted: G OE X --------- - - 4.18.0-425.19.2.el8_7.x86_64 #1 ... RIP: 0010:power_saving_thread+0x313/0x411 [acpi_pad] Code: 89 cd 48 89 d3 eb d1 48 c7 c7 55 70 72 c0 e8 64 86 b0 e4 c6 05 0d a1 02 00 01 e9 bc fd ff ff 45 89 e4 42 8b 04 a5 20 82 72 c0 48 0f b3 05 f4 9c 01 00 42 c7 04 a5 20 82 72 c0 ff ff ff ff 31 RSP: 0018:ff72a5d51fa77ec8 EFLAGS: 00010202 RAX: 00000000ffffffff RBX: ff462981e5d8cb80 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246 RBP: ff46297556959d80 R08: 0000000000000382 R09: ff46297c8d0f38d8 R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000000e R13: 0000000000000000 R14: ffffffffffffffff R15: 000000000000000e FS: 0000000000000000(0000) GS:ff46297a800c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffe0740618 CR3: 0000007e20410004 CR4: 0000000000771ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? acpi_pad_add+0x120/0x120 [acpi_pad] kthread+0x10b/0x130 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x1f/0x40 ... CR2: ffffffffe0740618 crash> dis -lr ffffffffc0726923 ... /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 114 0xffffffffc0726918 :\tmov %r12d,%r12d /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 325 0xffffffffc072691b :\tmov -0x3f8d7de0(,%r12,4),%eax /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./arch/x86/include/asm/bitops.h: 80 0xffffffffc0726923 :\tlock btr %rax,0x19cf4(%rip) # 0xffffffffc0740620 crash> px tsk_in_cpu[14] $66 = 0xffffffff crash> px 0xffffffffc072692c+0x19cf4 $99 = 0xffffffffc0740620 crash> sym 0xffffffffc0740620 ffffffffc0740620 (b) pad_busy_cpus_bits [acpi_pad] crash> px pad_busy_cpus_bits[0] $42 = 0xfffc0 ---------- To fix this, ensure that tsk_in_cpu[tsk_index] != -1 before calling cpumask_clear_cpu() in exit_round_robin(), just as it is done in round_robin_cpu(). [ rjw: Subject edit, avoid updates to the same value ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49936", "url": "https://ubuntu.com/security/CVE-2024-49936", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/xen-netback: prevent UAF in xenvif_flush_hash() During the list_for_each_entry_rcu iteration call of xenvif_flush_hash, kfree_rcu does not exist inside the rcu read critical section, so if kfree_rcu is called when the rcu grace period ends during the iteration, UAF occurs when accessing head->next after the entry becomes free. Therefore, to solve this, you need to change it to list_for_each_entry_safe.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49937", "url": "https://ubuntu.com/security/CVE-2024-49937", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Set correct chandef when starting CAC When starting CAC in a mode other than AP mode, it return a \"WARNING: CPU: 0 PID: 63 at cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]\" caused by the chandef.chan being null at the end of CAC. Solution: Ensure the channel definition is set for the different modes when starting CAC to avoid getting a NULL 'chan' at the end of CAC. Call Trace: ? show_regs.part.0+0x14/0x16 ? __warn+0x67/0xc0 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? report_bug+0xa7/0x130 ? exc_overflow+0x30/0x30 ? handle_bug+0x27/0x50 ? exc_invalid_op+0x18/0x60 ? handle_exception+0xf6/0xf6 ? exc_overflow+0x30/0x30 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? exc_overflow+0x30/0x30 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? regulatory_propagate_dfs_state.cold+0x1b/0x4c [cfg80211] ? cfg80211_propagate_cac_done_wk+0x1a/0x30 [cfg80211] ? process_one_work+0x165/0x280 ? worker_thread+0x120/0x3f0 ? kthread+0xc2/0xf0 ? process_one_work+0x280/0x280 ? kthread_complete_and_exit+0x20/0x20 ? ret_from_fork+0x19/0x24 [shorten subject, remove OCB, reorder cases to match previous list]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49938", "url": "https://ubuntu.com/security/CVE-2024-49938", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmit Syzbot points out that skb_trim() has a sanity check on the existing length of the skb, which can be uninitialised in some error paths. The intent here is clearly just to reset the length to zero before resubmitting, so switch to calling __skb_set_length(skb, 0) directly. In addition, __skb_set_length() already contains a call to skb_reset_tail_pointer(), so remove the redundant call. The syzbot report came from ath9k_hif_usb_reg_in_cb(), but there's a similar usage of skb_trim() in ath9k_hif_usb_rx_cb(), change both while we're at it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49939", "url": "https://ubuntu.com/security/CVE-2024-49939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: avoid to add interface to list twice when SER If SER L2 occurs during the WoWLAN resume flow, the add interface flow is triggered by ieee80211_reconfig(). However, due to rtw89_wow_resume() return failure, it will cause the add interface flow to be executed again, resulting in a double add list and causing a kernel panic. Therefore, we have added a check to prevent double adding of the list. list_add double add: new=ffff99d6992e2010, prev=ffff99d6992e2010, next=ffff99d695302628. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:37! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G W O 6.6.30-02659-gc18865c4dfbd #1 770df2933251a0e3c888ba69d1053a817a6376a7 Hardware name: HP Grunt/Grunt, BIOS Google_Grunt.11031.169.0 06/24/2021 Workqueue: events_freezable ieee80211_restart_work [mac80211] RIP: 0010:__list_add_valid_or_report+0x5e/0xb0 Code: c7 74 18 48 39 ce 74 13 b0 01 59 5a 5e 5f 41 58 41 59 41 5a 5d e9 e2 d6 03 00 cc 48 c7 c7 8d 4f 17 83 48 89 c2 e8 02 c0 00 00 <0f> 0b 48 c7 c7 aa 8c 1c 83 e8 f4 bf 00 00 0f 0b 48 c7 c7 c8 bc 12 RSP: 0018:ffffa91b8007bc50 EFLAGS: 00010246 RAX: 0000000000000058 RBX: ffff99d6992e0900 RCX: a014d76c70ef3900 RDX: ffffa91b8007bae8 RSI: 00000000ffffdfff RDI: 0000000000000001 RBP: ffffa91b8007bc88 R08: 0000000000000000 R09: ffffa91b8007bae0 R10: 00000000ffffdfff R11: ffffffff83a79800 R12: ffff99d695302060 R13: ffff99d695300900 R14: ffff99d6992e1be0 R15: ffff99d6992e2010 FS: 0000000000000000(0000) GS:ffff99d6aac00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000078fbdba43480 CR3: 000000010e464000 CR4: 00000000001506f0 Call Trace: ? __die_body+0x1f/0x70 ? die+0x3d/0x60 ? do_trap+0xa4/0x110 ? __list_add_valid_or_report+0x5e/0xb0 ? do_error_trap+0x6d/0x90 ? __list_add_valid_or_report+0x5e/0xb0 ? handle_invalid_op+0x30/0x40 ? __list_add_valid_or_report+0x5e/0xb0 ? exc_invalid_op+0x3c/0x50 ? asm_exc_invalid_op+0x16/0x20 ? __list_add_valid_or_report+0x5e/0xb0 rtw89_ops_add_interface+0x309/0x310 [rtw89_core 7c32b1ee6854761c0321027c8a58c5160e41f48f] drv_add_interface+0x5c/0x130 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ieee80211_reconfig+0x241/0x13d0 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ? finish_wait+0x3e/0x90 ? synchronize_rcu_expedited+0x174/0x260 ? sync_rcu_exp_done_unlocked+0x50/0x50 ? wake_bit_function+0x40/0x40 ieee80211_restart_work+0xf0/0x140 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] process_scheduled_works+0x1e5/0x480 worker_thread+0xea/0x1e0 kthread+0xdb/0x110 ? move_linked_works+0x90/0x90 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork+0x3b/0x50 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork_asm+0x11/0x20 Modules linked in: dm_integrity async_xor xor async_tx lz4 lz4_compress zstd zstd_compress zram zsmalloc rfcomm cmac uinput algif_hash algif_skcipher af_alg btusb btrtl iio_trig_hrtimer industrialio_sw_trigger btmtk industrialio_configfs btbcm btintel uvcvideo videobuf2_vmalloc iio_trig_sysfs videobuf2_memops videobuf2_v4l2 videobuf2_common uvc snd_hda_codec_hdmi veth snd_hda_intel snd_intel_dspcfg acpi_als snd_hda_codec industrialio_triggered_buffer kfifo_buf snd_hwdep industrialio i2c_piix4 snd_hda_core designware_i2s ip6table_nat snd_soc_max98357a xt_MASQUERADE xt_cgroup snd_soc_acp_rt5682_mach fuse rtw89_8922ae(O) rtw89_8922a(O) rtw89_pci(O) rtw89_core(O) 8021q mac80211(O) bluetooth ecdh_generic ecc cfg80211 r8152 mii joydev gsmi: Log Shutdown Reason 0x03 ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49940", "url": "https://ubuntu.com/security/CVE-2024-49940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: prevent possible tunnel refcount underflow When a session is created, it sets a backpointer to its tunnel. When the session refcount drops to 0, l2tp_session_free drops the tunnel refcount if session->tunnel is non-NULL. However, session->tunnel is set in l2tp_session_create, before the tunnel refcount is incremented by l2tp_session_register, which leaves a small window where session->tunnel is non-NULL when the tunnel refcount hasn't been bumped. Moving the assignment to l2tp_session_register is trivial but l2tp_session_create calls l2tp_session_set_header_len which uses session->tunnel to get the tunnel's encap. Add an encap arg to l2tp_session_set_header_len to avoid using session->tunnel. If l2tpv3 sessions have colliding IDs, it is possible for l2tp_v3_session_get to race with l2tp_session_register and fetch a session which doesn't yet have session->tunnel set. Add a check for this case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49941", "url": "https://ubuntu.com/security/CVE-2024-49941", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpiolib: Fix potential NULL pointer dereference in gpiod_get_label() In `gpiod_get_label()`, it is possible that `srcu_dereference_check()` may return a NULL pointer, leading to a scenario where `label->str` is accessed without verifying if `label` itself is NULL. This patch adds a proper NULL check for `label` before accessing `label->str`. The check for `label->str != NULL` is removed because `label->str` can never be NULL if `label` is not NULL. This fixes the issue where the label name was being printed as `(efault)` when dumping the sysfs GPIO file when `label == NULL`.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49996", "url": "https://ubuntu.com/security/CVE-2024-49996", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: Fix buffer overflow when parsing NFS reparse points ReparseDataLength is sum of the InodeType size and DataBuffer size. So to get DataBuffer size it is needed to subtract InodeType's size from ReparseDataLength. Function cifs_strndup_from_utf16() is currentlly accessing buf->DataBuffer at position after the end of the buffer because it does not subtract InodeType size from the length. Fix this problem and correctly subtract variable len. Member InodeType is present only when reparse buffer is large enough. Check for ReparseDataLength before accessing InodeType to prevent another invalid memory access. Major and minor rdev values are present also only when reparse buffer is large enough. Check for reparse buffer size before calling reparse_mkdev().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49942", "url": "https://ubuntu.com/security/CVE-2024-49942", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Prevent null pointer access in xe_migrate_copy xe_migrate_copy designed to copy content of TTM resources. When source resource is null, it will trigger a NULL pointer dereference in xe_migrate_copy. To avoid this situation, update lacks source flag to true for this case, the flag will trigger xe_migrate_clear rather than xe_migrate_copy. Issue trace: <7> [317.089847] xe 0000:00:02.0: [drm:xe_migrate_copy [xe]] Pass 14, sizes: 4194304 & 4194304 <7> [317.089945] xe 0000:00:02.0: [drm:xe_migrate_copy [xe]] Pass 15, sizes: 4194304 & 4194304 <1> [317.128055] BUG: kernel NULL pointer dereference, address: 0000000000000010 <1> [317.128064] #PF: supervisor read access in kernel mode <1> [317.128066] #PF: error_code(0x0000) - not-present page <6> [317.128069] PGD 0 P4D 0 <4> [317.128071] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI <4> [317.128074] CPU: 1 UID: 0 PID: 1440 Comm: kunit_try_catch Tainted: G U N 6.11.0-rc7-xe #1 <4> [317.128078] Tainted: [U]=USER, [N]=TEST <4> [317.128080] Hardware name: Intel Corporation Lunar Lake Client Platform/LNL-M LP5 RVP1, BIOS LNLMFWI1.R00.3221.D80.2407291239 07/29/2024 <4> [317.128082] RIP: 0010:xe_migrate_copy+0x66/0x13e0 [xe] <4> [317.128158] Code: 00 00 48 89 8d e0 fe ff ff 48 8b 40 10 4c 89 85 c8 fe ff ff 44 88 8d bd fe ff ff 65 48 8b 3c 25 28 00 00 00 48 89 7d d0 31 ff <8b> 79 10 48 89 85 a0 fe ff ff 48 8b 00 48 89 b5 d8 fe ff ff 83 ff <4> [317.128162] RSP: 0018:ffffc9000167f9f0 EFLAGS: 00010246 <4> [317.128164] RAX: ffff8881120d8028 RBX: ffff88814d070428 RCX: 0000000000000000 <4> [317.128166] RDX: ffff88813cb99c00 RSI: 0000000004000000 RDI: 0000000000000000 <4> [317.128168] RBP: ffffc9000167fbb8 R08: ffff88814e7b1f08 R09: 0000000000000001 <4> [317.128170] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88814e7b1f08 <4> [317.128172] R13: ffff88814e7b1f08 R14: ffff88813cb99c00 R15: 0000000000000001 <4> [317.128174] FS: 0000000000000000(0000) GS:ffff88846f280000(0000) knlGS:0000000000000000 <4> [317.128176] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [317.128178] CR2: 0000000000000010 CR3: 000000011f676004 CR4: 0000000000770ef0 <4> [317.128180] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 <4> [317.128182] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400 <4> [317.128184] PKRU: 55555554 <4> [317.128185] Call Trace: <4> [317.128187] <4> [317.128189] ? show_regs+0x67/0x70 <4> [317.128194] ? __die_body+0x20/0x70 <4> [317.128196] ? __die+0x2b/0x40 <4> [317.128198] ? page_fault_oops+0x15f/0x4e0 <4> [317.128203] ? do_user_addr_fault+0x3fb/0x970 <4> [317.128205] ? lock_acquire+0xc7/0x2e0 <4> [317.128209] ? exc_page_fault+0x87/0x2b0 <4> [317.128212] ? asm_exc_page_fault+0x27/0x30 <4> [317.128216] ? xe_migrate_copy+0x66/0x13e0 [xe] <4> [317.128263] ? __lock_acquire+0xb9d/0x26f0 <4> [317.128265] ? __lock_acquire+0xb9d/0x26f0 <4> [317.128267] ? sg_free_append_table+0x20/0x80 <4> [317.128271] ? lock_acquire+0xc7/0x2e0 <4> [317.128273] ? mark_held_locks+0x4d/0x80 <4> [317.128275] ? trace_hardirqs_on+0x1e/0xd0 <4> [317.128278] ? _raw_spin_unlock_irqrestore+0x31/0x60 <4> [317.128281] ? __pm_runtime_resume+0x60/0xa0 <4> [317.128284] xe_bo_move+0x682/0xc50 [xe] <4> [317.128315] ? lock_is_held_type+0xaa/0x120 <4> [317.128318] ttm_bo_handle_move_mem+0xe5/0x1a0 [ttm] <4> [317.128324] ttm_bo_validate+0xd1/0x1a0 [ttm] <4> [317.128328] shrink_test_run_device+0x721/0xc10 [xe] <4> [317.128360] ? find_held_lock+0x31/0x90 <4> [317.128363] ? lock_release+0xd1/0x2a0 <4> [317.128365] ? __pfx_kunit_generic_run_threadfn_adapter+0x10/0x10 [kunit] <4> [317.128370] xe_bo_shrink_kunit+0x11/0x20 [xe] <4> [317.128397] kunit_try_run_case+0x6e/0x150 [kunit] <4> [317.128400] ? trace_hardirqs_on+0x1e/0xd0 <4> [317.128402] ? _raw_spin_unlock_irqrestore+0x31/0x60 <4> [317.128404] kunit_generic_run_threadfn_adapter+0x1e/0x40 [ku ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49943", "url": "https://ubuntu.com/security/CVE-2024-49943", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc_submit: add missing locking in wedged_fini Any non-wedged queue can have a zero refcount here and can be running concurrently with an async queue destroy, therefore dereferencing the queue ptr to check wedge status after the lookup can trigger UAF if queue is not wedged. Fix this by keeping the submission_state lock held around the check to postpone the free and make the check safe, before dropping again around the put() to avoid the deadlock. (cherry picked from commit d28af0b6b9580b9f90c265a7da0315b0ad20bbfd)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50011", "url": "https://ubuntu.com/security/CVE-2024-50011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: soc-acpi-intel-rpl-match: add missing empty item There is no links_num in struct snd_soc_acpi_mach {}, and we test !link->num_adr as a condition to end the loop in hda_sdw_machine_select(). So an empty item in struct snd_soc_acpi_link_adr array is required.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50174", "url": "https://ubuntu.com/security/CVE-2024-50174", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix race when converting group handle to group object XArray provides it's own internal lock which protects the internal array when entries are being simultaneously added and removed. However there is still a race between retrieving the pointer from the XArray and incrementing the reference count. To avoid this race simply hold the internal XArray lock when incrementing the reference count, this ensures there cannot be a racing call to xa_erase().", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49944", "url": "https://ubuntu.com/security/CVE-2024-49944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_start In sctp_listen_start() invoked by sctp_inet_listen(), it should set the sk_state back to CLOSED if sctp_autobind() fails due to whatever reason. Otherwise, next time when calling sctp_inet_listen(), if sctp_sk(sk)->reuse is already set via setsockopt(SCTP_REUSE_PORT), sctp_sk(sk)->bind_hash will be dereferenced as sk_state is LISTENING, which causes a crash as bind_hash is NULL. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:sctp_inet_listen+0x7f0/0xa20 net/sctp/socket.c:8617 Call Trace: __sys_listen_socket net/socket.c:1883 [inline] __sys_listen+0x1b7/0x230 net/socket.c:1894 __do_sys_listen net/socket.c:1902 [inline]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49945", "url": "https://ubuntu.com/security/CVE-2024-49945", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/ncsi: Disable the ncsi work before freeing the associated structure The work function can run after the ncsi device is freed, resulting in use-after-free bugs or kernel panic.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49946", "url": "https://ubuntu.com/security/CVE-2024-49946", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: do not assume bh is held in ppp_channel_bridge_input() Networking receive path is usually handled from BH handler. However, some protocols need to acquire the socket lock, and packets might be stored in the socket backlog is the socket was owned by a user process. In this case, release_sock(), __release_sock(), and sk_backlog_rcv() might call the sk->sk_backlog_rcv() handler in process context. sybot caught ppp was not considering this case in ppp_channel_bridge_input() : WARNING: inconsistent lock state 6.11.0-rc7-syzkaller-g5f5673607153 #0 Not tainted -------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. ksoftirqd/1/24 [HC0[0]:SC1[1]:HE1:SE0] takes: ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 {SOFTIRQ-ON-W} state was registered at: lock_acquire+0x240/0x728 kernel/locking/lockdep.c:5759 __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline] _raw_spin_lock+0x48/0x60 kernel/locking/spinlock.c:154 spin_lock include/linux/spinlock.h:351 [inline] ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline] ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0xfc/0x314 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv include/net/sock.h:1111 [inline] __release_sock+0x1a8/0x3d8 net/core/sock.c:3004 release_sock+0x68/0x1b8 net/core/sock.c:3558 pppoe_sendmsg+0xc8/0x5d8 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x374/0x4f4 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __arm64_sys_sendto+0xd8/0xf8 net/socket.c:2212 __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:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 irq event stamp: 282914 hardirqs last enabled at (282914): [] __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:151 [inline] hardirqs last enabled at (282914): [] _raw_spin_unlock_irqrestore+0x38/0x98 kernel/locking/spinlock.c:194 hardirqs last disabled at (282913): [] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline] hardirqs last disabled at (282913): [] _raw_spin_lock_irqsave+0x2c/0x7c kernel/locking/spinlock.c:162 softirqs last enabled at (282904): [] softirq_handle_end kernel/softirq.c:400 [inline] softirqs last enabled at (282904): [] handle_softirqs+0xa3c/0xbfc kernel/softirq.c:582 softirqs last disabled at (282909): [] run_ksoftirqd+0x70/0x158 kernel/softirq.c:928 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&pch->downl); lock(&pch->downl); *** DEADLOCK *** 1 lock held by ksoftirqd/1/24: #0: ffff80008f74dfa0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire+0x10/0x4c include/linux/rcupdate.h:325 stack backtrace: CPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 6.11.0-rc7-syzkaller-g5f5673607153 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call trace: dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:319 show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:326 __dump_sta ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49947", "url": "https://ubuntu.com/security/CVE-2024-49947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: test for not too small csum_start in virtio_net_hdr_to_skb() syzbot was able to trigger this warning [1], after injecting a malicious packet through af_packet, setting skb->csum_start and thus the transport header to an incorrect value. We can at least make sure the transport header is after the end of the network header (with a estimated minimal size). [1] [ 67.873027] skb len=4096 headroom=16 headlen=14 tailroom=0 mac=(-1,-1) mac_len=0 net=(16,-6) trans=10 shinfo(txflags=0 nr_frags=1 gso(size=0 type=0 segs=0)) csum(0xa start=10 offset=0 ip_summed=3 complete_sw=0 valid=0 level=0) hash(0x0 sw=0 l4=0) proto=0x0800 pkttype=0 iif=0 priority=0x0 mark=0x0 alloc_cpu=10 vlan_all=0x0 encapsulation=0 inner(proto=0x0000, mac=0, net=0, trans=0) [ 67.877172] dev name=veth0_vlan feat=0x000061164fdd09e9 [ 67.877764] sk family=17 type=3 proto=0 [ 67.878279] skb linear: 00000000: 00 00 10 00 00 00 00 00 0f 00 00 00 08 00 [ 67.879128] skb frag: 00000000: 0e 00 07 00 00 00 28 00 08 80 1c 00 04 00 00 02 [ 67.879877] skb frag: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.880647] skb frag: 00000020: 00 00 02 00 00 00 08 00 1b 00 00 00 00 00 00 00 [ 67.881156] skb frag: 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.881753] skb frag: 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.882173] skb frag: 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.882790] skb frag: 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.883171] skb frag: 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.883733] skb frag: 00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.884206] skb frag: 00000090: 00 00 00 00 00 00 00 00 00 00 69 70 76 6c 61 6e [ 67.884704] skb frag: 000000a0: 31 00 00 00 00 00 00 00 00 00 2b 00 00 00 00 00 [ 67.885139] skb frag: 000000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.885677] skb frag: 000000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.886042] skb frag: 000000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.886408] skb frag: 000000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.887020] skb frag: 000000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.887384] skb frag: 00000100: 00 00 [ 67.887878] ------------[ cut here ]------------ [ 67.887908] offset (-6) >= skb_headlen() (14) [ 67.888445] WARNING: CPU: 10 PID: 2088 at net/core/dev.c:3332 skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.889353] Modules linked in: macsec macvtap macvlan hsr wireguard curve25519_x86_64 libcurve25519_generic libchacha20poly1305 chacha_x86_64 libchacha poly1305_x86_64 dummy bridge sr_mod cdrom evdev pcspkr i2c_piix4 9pnet_virtio 9p 9pnet netfs [ 67.890111] CPU: 10 UID: 0 PID: 2088 Comm: b363492833 Not tainted 6.11.0-virtme #1011 [ 67.890183] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 67.890309] RIP: 0010:skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891043] Call Trace: [ 67.891173] [ 67.891274] ? __warn (kernel/panic.c:741) [ 67.891320] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891333] ? report_bug (lib/bug.c:180 lib/bug.c:219) [ 67.891348] ? handle_bug (arch/x86/kernel/traps.c:239) [ 67.891363] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) [ 67.891372] ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621) [ 67.891388] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891399] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891416] ip_do_fragment (net/ipv4/ip_output.c:777 (discriminator 1)) [ 67.891448] ? __ip_local_out (./include/linux/skbuff.h:1146 ./include/net/l3mdev.h:196 ./include/net/l3mdev.h:213 ne ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49948", "url": "https://ubuntu.com/security/CVE-2024-49948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: add more sanity checks to qdisc_pkt_len_init() One path takes care of SKB_GSO_DODGY, assuming skb->len is bigger than hdr_len. virtio_net_hdr_to_skb() does not fully dissect TCP headers, it only make sure it is at least 20 bytes. It is possible for an user to provide a malicious 'GSO' packet, total length of 80 bytes. - 20 bytes of IPv4 header - 60 bytes TCP header - a small gso_size like 8 virtio_net_hdr_to_skb() would declare this packet as a normal GSO packet, because it would see 40 bytes of payload, bigger than gso_size. We need to make detect this case to not underflow qdisc_skb_cb(skb)->pkt_len.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49949", "url": "https://ubuntu.com/security/CVE-2024-49949", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: avoid potential underflow in qdisc_pkt_len_init() with UFO After commit 7c6d2ecbda83 (\"net: be more gentle about silly gso requests coming from user\") virtio_net_hdr_to_skb() had sanity check to detect malicious attempts from user space to cook a bad GSO packet. Then commit cf9acc90c80ec (\"net: virtio_net_hdr_to_skb: count transport header in UFO\") while fixing one issue, allowed user space to cook a GSO packet with the following characteristic : IPv4 SKB_GSO_UDP, gso_size=3, skb->len = 28. When this packet arrives in qdisc_pkt_len_init(), we end up with hdr_len = 28 (IPv4 header + UDP header), matching skb->len Then the following sets gso_segs to 0 : gso_segs = DIV_ROUND_UP(skb->len - hdr_len, shinfo->gso_size); Then later we set qdisc_skb_cb(skb)->pkt_len to back to zero :/ qdisc_skb_cb(skb)->pkt_len += (gso_segs - 1) * hdr_len; This leads to the following crash in fq_codel [1] qdisc_pkt_len_init() is best effort, we only want an estimation of the bytes sent on the wire, not crashing the kernel. This patch is fixing this particular issue, a following one adds more sanity checks for another potential bug. [1] [ 70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 70.724561] #PF: supervisor read access in kernel mode [ 70.724561] #PF: error_code(0x0000) - not-present page [ 70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0 [ 70.724561] Oops: Oops: 0000 [#1] SMP NOPTI [ 70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991 [ 70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel [ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 <49> 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49 All code ======== 0:\t24 08 \tand $0x8,%al 2:\t49 c1 e1 06 \tshl $0x6,%r9 6:\t44 89 7c 24 18 \tmov %r15d,0x18(%rsp) b:\t45 31 ed \txor %r13d,%r13d e:\t45 31 c0 \txor %r8d,%r8d 11:\t31 ff \txor %edi,%edi 13:\t89 44 24 14 \tmov %eax,0x14(%rsp) 17:\t4c 03 8b 90 01 00 00 \tadd 0x190(%rbx),%r9 1e:\teb 04 \tjmp 0x24 20:\t39 ca \tcmp %ecx,%edx 22:\t73 37 \tjae 0x5b 24:\t4d 8b 39 \tmov (%r9),%r15 27:\t83 c7 01 \tadd $0x1,%edi 2a:*\t49 8b 17 \tmov (%r15),%rdx\t\t<-- trapping instruction 2d:\t49 89 11 \tmov %rdx,(%r9) 30:\t41 8b 57 28 \tmov 0x28(%r15),%edx 34:\t45 8b 5f 34 \tmov 0x34(%r15),%r11d 38:\t49 c7 07 00 00 00 00 \tmovq $0x0,(%r15) 3f:\t49 \trex.WB Code starting with the faulting instruction =========================================== 0:\t49 8b 17 \tmov (%r15),%rdx 3:\t49 89 11 \tmov %rdx,(%r9) 6:\t41 8b 57 28 \tmov 0x28(%r15),%edx a:\t45 8b 5f 34 \tmov 0x34(%r15),%r11d e:\t49 c7 07 00 00 00 00 \tmovq $0x0,(%r15) 15:\t49 \trex.WB [ 70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202 [ 70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000 [ 70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001 [ 70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000 [ 70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58 [ 70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000 [ 70.724561] FS: 000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000 [ 70.724561] CS: 0010 DS: 0000 ES: 0000 C ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49997", "url": "https://ubuntu.com/security/CVE-2024-49997", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: lantiq_etop: fix memory disclosure When applying padding, the buffer is not zeroed, which results in memory disclosure. The mentioned data is observed on the wire. This patch uses skb_put_padto() to pad Ethernet frames properly. The mentioned function zeroes the expanded buffer. In case the packet cannot be padded it is silently dropped. Statistics are also not incremented. This driver does not support statistics in the old 32-bit format or the new 64-bit format. These will be added in the future. In its current form, the patch should be easily backported to stable versions. Ethernet MACs on Amazon-SE and Danube cannot do padding of the packets in hardware, so software padding must be applied.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49998", "url": "https://ubuntu.com/security/CVE-2024-49998", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: improve shutdown sequence Alexander Sverdlin presents 2 problems during shutdown with the lan9303 driver. One is specific to lan9303 and the other just happens to reproduce there. The first problem is that lan9303 is unique among DSA drivers in that it calls dev_get_drvdata() at \"arbitrary runtime\" (not probe, not shutdown, not remove): phy_state_machine() -> ... -> dsa_user_phy_read() -> ds->ops->phy_read() -> lan9303_phy_read() -> chip->ops->phy_read() -> lan9303_mdio_phy_read() -> dev_get_drvdata() But we never stop the phy_state_machine(), so it may continue to run after dsa_switch_shutdown(). Our common pattern in all DSA drivers is to set drvdata to NULL to suppress the remove() method that may come afterwards. But in this case it will result in an NPD. The second problem is that the way in which we set dp->conduit->dsa_ptr = NULL; is concurrent with receive packet processing. dsa_switch_rcv() checks once whether dev->dsa_ptr is NULL, but afterwards, rather than continuing to use that non-NULL value, dev->dsa_ptr is dereferenced again and again without NULL checks: dsa_conduit_find_user() and many other places. In between dereferences, there is no locking to ensure that what was valid once continues to be valid. Both problems have the common aspect that closing the conduit interface solves them. In the first case, dev_close(conduit) triggers the NETDEV_GOING_DOWN event in dsa_user_netdevice_event() which closes user ports as well. dsa_port_disable_rt() calls phylink_stop(), which synchronously stops the phylink state machine, and ds->ops->phy_read() will thus no longer call into the driver after this point. In the second case, dev_close(conduit) should do this, as per Documentation/networking/driver.rst: | Quiescence | ---------- | | After the ndo_stop routine has been called, the hardware must | not receive or transmit any data. All in flight packets must | be aborted. If necessary, poll or wait for completion of | any reset commands. So it should be sufficient to ensure that later, when we zeroize conduit->dsa_ptr, there will be no concurrent dsa_switch_rcv() call on this conduit. The addition of the netif_device_detach() function is to ensure that ioctls, rtnetlinks and ethtool requests on the user ports no longer propagate down to the driver - we're no longer prepared to handle them. The race condition actually did not exist when commit 0650bf52b31f (\"net: dsa: be compatible with masters which unregister on shutdown\") first introduced dsa_switch_shutdown(). It was created later, when we stopped unregistering the user interfaces from a bad spot, and we just replaced that sequence with a racy zeroization of conduit->dsa_ptr (one which doesn't ensure that the interfaces aren't up).", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49999", "url": "https://ubuntu.com/security/CVE-2024-49999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix the setting of the server responding flag In afs_wait_for_operation(), we set transcribe the call responded flag to the server record that we used after doing the fileserver iteration loop - but it's possible to exit the loop having had a response from the server that we've discarded (e.g. it returned an abort or we started receiving data, but the call didn't complete). This means that op->server might be NULL, but we don't check that before attempting to set the server flag.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49950", "url": "https://ubuntu.com/security/CVE-2024-49950", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix uaf in l2cap_connect [Syzbot reported] BUG: KASAN: slab-use-after-free in l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 Read of size 8 at addr ffff8880241e9800 by task kworker/u9:0/54 CPU: 0 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-00268-g788220eee30d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Workqueue: hci2 hci_rx_work Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 l2cap_connect_req net/bluetooth/l2cap_core.c:4080 [inline] l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:4772 [inline] l2cap_sig_channel net/bluetooth/l2cap_core.c:5543 [inline] l2cap_recv_frame+0xf0b/0x8eb0 net/bluetooth/l2cap_core.c:6825 l2cap_recv_acldata+0x9b4/0xb70 net/bluetooth/l2cap_core.c:7514 hci_acldata_packet net/bluetooth/hci_core.c:3791 [inline] hci_rx_work+0xaab/0x1610 net/bluetooth/hci_core.c:4028 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 ... Freed by task 5245: 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:579 poison_slab_object+0xf7/0x160 mm/kasan/common.c:240 __kasan_slab_free+0x32/0x50 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2256 [inline] slab_free mm/slub.c:4477 [inline] kfree+0x12a/0x3b0 mm/slub.c:4598 l2cap_conn_free net/bluetooth/l2cap_core.c:1810 [inline] kref_put include/linux/kref.h:65 [inline] l2cap_conn_put net/bluetooth/l2cap_core.c:1822 [inline] l2cap_conn_del+0x59d/0x730 net/bluetooth/l2cap_core.c:1802 l2cap_connect_cfm+0x9e6/0xf80 net/bluetooth/l2cap_core.c:7241 hci_connect_cfm include/net/bluetooth/hci_core.h:1960 [inline] hci_conn_failed+0x1c3/0x370 net/bluetooth/hci_conn.c:1265 hci_abort_conn_sync+0x75a/0xb50 net/bluetooth/hci_sync.c:5583 abort_conn_sync+0x197/0x360 net/bluetooth/hci_conn.c:2917 hci_cmd_sync_work+0x1a4/0x410 net/bluetooth/hci_sync.c:328 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49951", "url": "https://ubuntu.com/security/CVE-2024-49951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Fix possible crash on mgmt_index_removed If mgmt_index_removed is called while there are commands queued on cmd_sync it could lead to crashes like the bellow trace: 0x0000053D: __list_del_entry_valid_or_report+0x98/0xdc 0x0000053D: mgmt_pending_remove+0x18/0x58 [bluetooth] 0x0000053E: mgmt_remove_adv_monitor_complete+0x80/0x108 [bluetooth] 0x0000053E: hci_cmd_sync_work+0xbc/0x164 [bluetooth] So while handling mgmt_index_removed this attempts to dequeue commands passed as user_data to cmd_sync.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49952", "url": "https://ubuntu.com/security/CVE-2024-49952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: prevent nf_skb_duplicated corruption syzbot found that nf_dup_ipv4() or nf_dup_ipv6() could write per-cpu variable nf_skb_duplicated in an unsafe way [1]. Disabling preemption as hinted by the splat is not enough, we have to disable soft interrupts as well. [1] BUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316 caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49 nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook+0x2c4/0x450 include/linux/netfilter.h:269 NF_HOOK_COND include/linux/netfilter.h:302 [inline] ip_output+0x185/0x230 net/ipv4/ip_output.c:433 ip_local_out net/ipv4/ip_output.c:129 [inline] ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495 udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981 udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737 __do_sys_sendmmsg net/socket.c:2766 [inline] __se_sys_sendmmsg net/socket.c:2763 [inline] __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763 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:0x7f4ce4f7def9 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:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9 RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006 RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49953", "url": "https://ubuntu.com/security/CVE-2024-49953", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix crash caused by calling __xfrm_state_delete() twice The km.state is not checked in driver's delayed work. When xfrm_state_check_expire() is called, the state can be reset to XFRM_STATE_EXPIRED, even if it is XFRM_STATE_DEAD already. This happens when xfrm state is deleted, but not freed yet. As __xfrm_state_delete() is called again in xfrm timer, the following crash occurs. To fix this issue, skip xfrm_state_check_expire() if km.state is not XFRM_STATE_VALID. Oops: general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] SMP CPU: 5 UID: 0 PID: 7448 Comm: kworker/u102:2 Not tainted 6.11.0-rc2+ #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5e_ipsec: eth%d mlx5e_ipsec_handle_sw_limits [mlx5_core] RIP: 0010:__xfrm_state_delete+0x3d/0x1b0 Code: 0f 84 8b 01 00 00 48 89 fd c6 87 c8 00 00 00 05 48 8d bb 40 10 00 00 e8 11 04 1a 00 48 8b 95 b8 00 00 00 48 8b 85 c0 00 00 00 <48> 89 42 08 48 89 10 48 8b 55 10 48 b8 00 01 00 00 00 00 ad de 48 RSP: 0018:ffff88885f945ec8 EFLAGS: 00010246 RAX: dead000000000122 RBX: ffffffff82afa940 RCX: 0000000000000036 RDX: dead000000000100 RSI: 0000000000000000 RDI: ffffffff82afb980 RBP: ffff888109a20340 R08: ffff88885f945ea0 R09: 0000000000000000 R10: 0000000000000000 R11: ffff88885f945ff8 R12: 0000000000000246 R13: ffff888109a20340 R14: ffff88885f95f420 R15: ffff88885f95f400 FS: 0000000000000000(0000) GS:ffff88885f940000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2163102430 CR3: 00000001128d6001 CR4: 0000000000370eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? die_addr+0x33/0x90 ? exc_general_protection+0x1a2/0x390 ? asm_exc_general_protection+0x22/0x30 ? __xfrm_state_delete+0x3d/0x1b0 ? __xfrm_state_delete+0x2f/0x1b0 xfrm_timer_handler+0x174/0x350 ? __xfrm_state_delete+0x1b0/0x1b0 __hrtimer_run_queues+0x121/0x270 hrtimer_run_softirq+0x88/0xd0 handle_softirqs+0xcc/0x270 do_softirq+0x3c/0x50 __local_bh_enable_ip+0x47/0x50 mlx5e_ipsec_handle_sw_limits+0x7d/0x90 [mlx5_core] process_one_work+0x137/0x2d0 worker_thread+0x28d/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50000", "url": "https://ubuntu.com/security/CVE-2024-50000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix NULL deref in mlx5e_tir_builder_alloc() In mlx5e_tir_builder_alloc() kvzalloc() may return NULL which is dereferenced on the next line in a reference to the modify field. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50001", "url": "https://ubuntu.com/security/CVE-2024-50001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix error path in multi-packet WQE transmit Remove the erroneous unmap in case no DMA mapping was established The multi-packet WQE transmit code attempts to obtain a DMA mapping for the skb. This could fail, e.g. under memory pressure, when the IOMMU driver just can't allocate more memory for page tables. While the code tries to handle this in the path below the err_unmap label it erroneously unmaps one entry from the sq's FIFO list of active mappings. Since the current map attempt failed this unmap is removing some random DMA mapping that might still be required. If the PCI function now presents that IOVA, the IOMMU may assumes a rogue DMA access and e.g. on s390 puts the PCI function in error state. The erroneous behavior was seen in a stress-test environment that created memory pressure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50179", "url": "https://ubuntu.com/security/CVE-2024-50179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: remove the incorrect Fw reference check when dirtying pages When doing the direct-io reads it will also try to mark pages dirty, but for the read path it won't hold the Fw caps and there is case will it get the Fw reference.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49963", "url": "https://ubuntu.com/security/CVE-2024-49963", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mailbox: bcm2835: Fix timeout during suspend mode During noirq suspend phase the Raspberry Pi power driver suffer of firmware property timeouts. The reason is that the IRQ of the underlying BCM2835 mailbox is disabled and rpi_firmware_property_list() will always run into a timeout [1]. Since the VideoCore side isn't consider as a wakeup source, set the IRQF_NO_SUSPEND flag for the mailbox IRQ in order to keep it enabled during suspend-resume cycle. [1] PM: late suspend of devices complete after 1.754 msecs WARNING: CPU: 0 PID: 438 at drivers/firmware/raspberrypi.c:128 rpi_firmware_property_list+0x204/0x22c Firmware transaction 0x00028001 timeout Modules linked in: CPU: 0 PID: 438 Comm: bash Tainted: G C 6.9.3-dirty #17 Hardware name: BCM2835 Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x44 dump_stack_lvl from __warn+0x88/0xec __warn from warn_slowpath_fmt+0x7c/0xb0 warn_slowpath_fmt from rpi_firmware_property_list+0x204/0x22c rpi_firmware_property_list from rpi_firmware_property+0x68/0x8c rpi_firmware_property from rpi_firmware_set_power+0x54/0xc0 rpi_firmware_set_power from _genpd_power_off+0xe4/0x148 _genpd_power_off from genpd_sync_power_off+0x7c/0x11c genpd_sync_power_off from genpd_finish_suspend+0xcc/0xe0 genpd_finish_suspend from dpm_run_callback+0x78/0xd0 dpm_run_callback from device_suspend_noirq+0xc0/0x238 device_suspend_noirq from dpm_suspend_noirq+0xb0/0x168 dpm_suspend_noirq from suspend_devices_and_enter+0x1b8/0x5ac suspend_devices_and_enter from pm_suspend+0x254/0x2e4 pm_suspend from state_store+0xa8/0xd4 state_store from kernfs_fop_write_iter+0x154/0x1a0 kernfs_fop_write_iter from vfs_write+0x12c/0x184 vfs_write from ksys_write+0x78/0xc0 ksys_write from ret_fast_syscall+0x0/0x54 Exception stack(0xcc93dfa8 to 0xcc93dff0) [...] PM: noirq suspend of devices complete after 3095.584 msecs", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49954", "url": "https://ubuntu.com/security/CVE-2024-49954", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: static_call: Replace pointless WARN_ON() in static_call_module_notify() static_call_module_notify() triggers a WARN_ON(), when memory allocation fails in __static_call_add_module(). That's not really justified, because the failure case must be correctly handled by the well known call chain and the error code is passed through to the initiating userspace application. A memory allocation fail is not a fatal problem, but the WARN_ON() takes the machine out when panic_on_warn is set. Replace it with a pr_warn().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50002", "url": "https://ubuntu.com/security/CVE-2024-50002", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: static_call: Handle module init failure correctly in static_call_del_module() Module insertion invokes static_call_add_module() to initialize the static calls in a module. static_call_add_module() invokes __static_call_init(), which allocates a struct static_call_mod to either encapsulate the built-in static call sites of the associated key into it so further modules can be added or to append the module to the module chain. If that allocation fails the function returns with an error code and the module core invokes static_call_del_module() to clean up eventually added static_call_mod entries. This works correctly, when all keys used by the module were converted over to a module chain before the failure. If not then static_call_del_module() causes a #GP as it blindly assumes that key::mods points to a valid struct static_call_mod. The problem is that key::mods is not a individual struct member of struct static_call_key, it's part of a union to save space: union { /* bit 0: 0 = mods, 1 = sites */ unsigned long type; struct static_call_mod *mods; struct static_call_site *sites; \t}; key::sites is a pointer to the list of built-in usage sites of the static call. The type of the pointer is differentiated by bit 0. A mods pointer has the bit clear, the sites pointer has the bit set. As static_call_del_module() blidly assumes that the pointer is a valid static_call_mod type, it fails to check for this failure case and dereferences the pointer to the list of built-in call sites, which is obviously bogus. Cure it by checking whether the key has a sites or a mods pointer. If it's a sites pointer then the key is not to be touched. As the sites are walked in the same order as in __static_call_init() the site walk can be terminated because all subsequent sites have not been touched by the init code due to the error exit. If it was converted before the allocation fail, then the inner loop which searches for a module match will find nothing. A fail in the second allocation in __static_call_init() is harmless and does not require special treatment. The first allocation succeeded and converted the key to a module chain. That first entry has mod::mod == NULL and mod::next == NULL, so the inner loop of static_call_del_module() will neither find a module match nor a module chain. The next site in the walk was either already converted, but can't match the module, or it will exit the outer loop because it has a static_call_site pointer and not a static_call_mod pointer.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-47675", "url": "https://ubuntu.com/security/CVE-2024-47675", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix use-after-free in bpf_uprobe_multi_link_attach() If bpf_link_prime() fails, bpf_uprobe_multi_link_attach() goes to the error_free label and frees the array of bpf_uprobe's without calling bpf_uprobe_unregister(). This leaks bpf_uprobe->uprobe and worse, this frees bpf_uprobe->consumer without removing it from the uprobe->consumers list.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47676", "url": "https://ubuntu.com/security/CVE-2024-47676", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb.c: fix UAF of vma in hugetlb fault pathway Syzbot reports a UAF in hugetlb_fault(). This happens because vmf_anon_prepare() could drop the per-VMA lock and allow the current VMA to be freed before hugetlb_vma_unlock_read() is called. We can fix this by using a modified version of vmf_anon_prepare() that doesn't release the VMA lock on failure, and then release it ourselves after hugetlb_vma_unlock_read().", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47677", "url": "https://ubuntu.com/security/CVE-2024-47677", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: resolve memory leak from exfat_create_upcase_table() If exfat_load_upcase_table reaches end and returns -EINVAL, allocated memory doesn't get freed and while exfat_load_default_upcase_table allocates more memory, leading to a memory leak. Here's link to syzkaller crash report illustrating this issue: https://syzkaller.appspot.com/text?tag=CrashReport&x=1406c201980000", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47725", "url": "https://ubuntu.com/security/CVE-2024-47725", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47739", "url": "https://ubuntu.com/security/CVE-2024-47739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: padata: use integer wrap around to prevent deadlock on seq_nr overflow When submitting more than 2^32 padata objects to padata_do_serial, the current sorting implementation incorrectly sorts padata objects with overflowed seq_nr, causing them to be placed before existing objects in the reorder list. This leads to a deadlock in the serialization process as padata_find_next cannot match padata->seq_nr and pd->processed because the padata instance with overflowed seq_nr will be selected next. To fix this, we use an unsigned integer wrap around to correctly sort padata objects in scenarios with integer overflow.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47678", "url": "https://ubuntu.com/security/CVE-2024-47678", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: icmp: change the order of rate limits ICMP messages are ratelimited : After the blamed commits, the two rate limiters are applied in this order: 1) host wide ratelimit (icmp_global_allow()) 2) Per destination ratelimit (inetpeer based) In order to avoid side-channels attacks, we need to apply the per destination check first. This patch makes the following change : 1) icmp_global_allow() checks if the host wide limit is reached. But credits are not yet consumed. This is deferred to 3) 2) The per destination limit is checked/updated. This might add a new node in inetpeer tree. 3) icmp_global_consume() consumes tokens if prior operations succeeded. This means that host wide ratelimit is still effective in keeping inetpeer tree small even under DDOS. As a bonus, I removed icmp_global.lock as the fast path can use a lock-free operation.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47733", "url": "https://ubuntu.com/security/CVE-2024-47733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfs: Delete subtree of 'fs/netfs' when netfs module exits In netfs_init() or fscache_proc_init(), we create dentry under 'fs/netfs', but in netfs_exit(), we only delete the proc entry of 'fs/netfs' without deleting its subtree. This triggers the following WARNING: ================================================================== remove_proc_entry: removing non-empty directory 'fs/netfs', leaking at least 'requests' WARNING: CPU: 4 PID: 566 at fs/proc/generic.c:717 remove_proc_entry+0x160/0x1c0 Modules linked in: netfs(-) CPU: 4 UID: 0 PID: 566 Comm: rmmod Not tainted 6.11.0-rc3 #860 RIP: 0010:remove_proc_entry+0x160/0x1c0 Call Trace: netfs_exit+0x12/0x620 [netfs] __do_sys_delete_module.isra.0+0x14c/0x2e0 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e ================================================================== Therefore use remove_proc_subtree() instead of remove_proc_entry() to fix the above problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47679", "url": "https://ubuntu.com/security/CVE-2024-47679", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfs: fix race between evice_inodes() and find_inode()&iput() Hi, all Recently I noticed a bug[1] in btrfs, after digged it into and I believe it'a race in vfs. Let's assume there's a inode (ie ino 261) with i_count 1 is called by iput(), and there's a concurrent thread calling generic_shutdown_super(). cpu0: cpu1: iput() // i_count is 1 ->spin_lock(inode) ->dec i_count to 0 ->iput_final() generic_shutdown_super() ->__inode_add_lru() ->evict_inodes() // cause some reason[2] ->if (atomic_read(inode->i_count)) continue; // return before // inode 261 passed the above check // list_lru_add_obj() // and then schedule out ->spin_unlock() // note here: the inode 261 // was still at sb list and hash list, // and I_FREEING|I_WILL_FREE was not been set btrfs_iget() // after some function calls ->find_inode() // found the above inode 261 ->spin_lock(inode) // check I_FREEING|I_WILL_FREE // and passed ->__iget() ->spin_unlock(inode) // schedule back ->spin_lock(inode) // check (I_NEW|I_FREEING|I_WILL_FREE) flags, // passed and set I_FREEING iput() ->spin_unlock(inode) ->spin_lock(inode)\t\t\t ->evict() // dec i_count to 0 ->iput_final() ->spin_unlock() ->evict() Now, we have two threads simultaneously evicting the same inode, which may trigger the BUG(inode->i_state & I_CLEAR) statement both within clear_inode() and iput(). To fix the bug, recheck the inode->i_count after holding i_lock. Because in the most scenarios, the first check is valid, and the overhead of spin_lock() can be reduced. If there is any misunderstanding, please let me know, thanks. [1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/ [2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable() return false when I reproduced the bug.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49859", "url": "https://ubuntu.com/security/CVE-2024-49859", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to check atomic_file in f2fs ioctl interfaces Some f2fs ioctl interfaces like f2fs_ioc_set_pin_file(), f2fs_move_file_range(), and f2fs_defragment_range() missed to check atomic_write status, which may cause potential race issue, fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47680", "url": "https://ubuntu.com/security/CVE-2024-47680", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: check discard support for conventional zones As the helper function f2fs_bdev_support_discard() shows, f2fs checks if the target block devices support discard by calling bdev_max_discard_sectors() and bdev_is_zoned(). This check works well for most cases, but it does not work for conventional zones on zoned block devices. F2fs assumes that zoned block devices support discard, and calls __submit_discard_cmd(). When __submit_discard_cmd() is called for sequential write required zones, it works fine since __submit_discard_cmd() issues zone reset commands instead of discard commands. However, when __submit_discard_cmd() is called for conventional zones, __blkdev_issue_discard() is called even when the devices do not support discard. The inappropriate __blkdev_issue_discard() call was not a problem before the commit 30f1e7241422 (\"block: move discard checks into the ioctl handler\") because __blkdev_issue_discard() checked if the target devices support discard or not. If not, it returned EOPNOTSUPP. After the commit, __blkdev_issue_discard() no longer checks it. It always returns zero and sets NULL to the given bio pointer. This NULL pointer triggers f2fs_bug_on() in __submit_discard_cmd(). The BUG is recreated with the commands below at the umount step, where /dev/nullb0 is a zoned null_blk with 5GB total size, 128MB zone size and 10 conventional zones. $ mkfs.f2fs -f -m /dev/nullb0 $ mount /dev/nullb0 /mnt $ for ((i=0;i<5;i++)); do dd if=/dev/zero of=/mnt/test bs=65536 count=1600 conv=fsync; done $ umount /mnt To fix the BUG, avoid the inappropriate __blkdev_issue_discard() call. When discard is requested for conventional zones, check if the device supports discard or not. If not, return EOPNOTSUPP.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47740", "url": "https://ubuntu.com/security/CVE-2024-47740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: Require FMODE_WRITE for atomic write ioctls The F2FS ioctls for starting and committing atomic writes check for inode_owner_or_capable(), but this does not give LSMs like SELinux or Landlock an opportunity to deny the write access - if the caller's FSUID matches the inode's UID, inode_owner_or_capable() immediately returns true. There are scenarios where LSMs want to deny a process the ability to write particular files, even files that the FSUID of the process owns; but this can currently partially be bypassed using atomic write ioctls in two ways: - F2FS_IOC_START_ATOMIC_REPLACE + F2FS_IOC_COMMIT_ATOMIC_WRITE can truncate an inode to size 0 - F2FS_IOC_START_ATOMIC_WRITE + F2FS_IOC_ABORT_ATOMIC_WRITE can revert changes another process concurrently made to a file Fix it by requiring FMODE_WRITE for these operations, just like for F2FS_IOC_MOVE_RANGE. Since any legitimate caller should only be using these ioctls when intending to write into the file, that seems unlikely to break anything.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47726", "url": "https://ubuntu.com/security/CVE-2024-47726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to wait dio completion It should wait all existing dio write IOs before block removal, otherwise, previous direct write IO may overwrite data in the block which may be reused by other inode.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47741", "url": "https://ubuntu.com/security/CVE-2024-47741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race setting file private on concurrent lseek using same fd When doing concurrent lseek(2) system calls against the same file descriptor, using multiple threads belonging to the same process, we have a short time window where a race happens and can result in a memory leak. The race happens like this: 1) A program opens a file descriptor for a file and then spawns two threads (with the pthreads library for example), lets call them task A and task B; 2) Task A calls lseek with SEEK_DATA or SEEK_HOLE and ends up at file.c:find_desired_extent() while holding a read lock on the inode; 3) At the start of find_desired_extent(), it extracts the file's private_data pointer into a local variable named 'private', which has a value of NULL; 4) Task B also calls lseek with SEEK_DATA or SEEK_HOLE, locks the inode in shared mode and enters file.c:find_desired_extent(), where it also extracts file->private_data into its local variable 'private', which has a NULL value; 5) Because it saw a NULL file private, task A allocates a private structure and assigns to the file structure; 6) Task B also saw a NULL file private so it also allocates its own file private and then assigns it to the same file structure, since both tasks are using the same file descriptor. At this point we leak the private structure allocated by task A. Besides the memory leak, there's also the detail that both tasks end up using the same cached state record in the private structure (struct btrfs_file_private::llseek_cached_state), which can result in a use-after-free problem since one task can free it while the other is still using it (only one task took a reference count on it). Also, sharing the cached state is not a good idea since it could result in incorrect results in the future - right now it should not be a problem because it end ups being used only in extent-io-tree.c:count_range_bits() where we do range validation before using the cached state. Fix this by protecting the private assignment and check of a file while holding the inode's spinlock and keep track of the task that allocated the private, so that it's used only by that task in order to prevent user-after-free issues with the cached state record as well as potentially using it incorrectly in the future.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47681", "url": "https://ubuntu.com/security/CVE-2024-47681", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix NULL pointer dereference in mt7996_mcu_sta_bfer_he Fix the NULL pointer dereference in mt7996_mcu_sta_bfer_he routine adding an sta interface to the mt7996 driver. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49858", "url": "https://ubuntu.com/security/CVE-2024-49858", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption The TPM event log table is a Linux specific construct, where the data produced by the GetEventLog() boot service is cached in memory, and passed on to the OS using an EFI configuration table. The use of EFI_LOADER_DATA here results in the region being left unreserved in the E820 memory map constructed by the EFI stub, and this is the memory description that is passed on to the incoming kernel by kexec, which is therefore unaware that the region should be reserved. Even though the utility of the TPM2 event log after a kexec is questionable, any corruption might send the parsing code off into the weeds and crash the kernel. So let's use EFI_ACPI_RECLAIM_MEMORY instead, which is always treated as reserved by the E820 conversion logic.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49860", "url": "https://ubuntu.com/security/CVE-2024-49860", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: sysfs: validate return type of _STR method Only buffer objects are valid return values of _STR. If something else is returned description_show() will access invalid memory.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47742", "url": "https://ubuntu.com/security/CVE-2024-47742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware_loader: Block path traversal Most firmware names are hardcoded strings, or are constructed from fairly constrained format strings where the dynamic parts are just some hex numbers or such. However, there are a couple codepaths in the kernel where firmware file names contain string components that are passed through from a device or semi-privileged userspace; the ones I could find (not counting interfaces that require root privileges) are: - lpfc_sli4_request_firmware_update() seems to construct the firmware filename from \"ModelName\", a string that was previously parsed out of some descriptor (\"Vital Product Data\") in lpfc_fill_vpd() - nfp_net_fw_find() seems to construct a firmware filename from a model name coming from nfp_hwinfo_lookup(pf->hwinfo, \"nffw.partno\"), which I think parses some descriptor that was read from the device. (But this case likely isn't exploitable because the format string looks like \"netronome/nic_%s\", and there shouldn't be any *folders* starting with \"netronome/nic_\". The previous case was different because there, the \"%s\" is *at the start* of the format string.) - module_flash_fw_schedule() is reachable from the ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is enough to pass the privilege check), and takes a userspace-provided firmware name. (But I think to reach this case, you need to have CAP_NET_ADMIN over a network namespace that a special kind of ethernet device is mapped into, so I think this is not a viable attack path in practice.) Fix it by rejecting any firmware names containing \"..\" path components. For what it's worth, I went looking and haven't found any USB device drivers that use the firmware loader dangerously.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47682", "url": "https://ubuntu.com/security/CVE-2024-47682", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sd: Fix off-by-one error in sd_read_block_characteristics() Ff the device returns page 0xb1 with length 8 (happens with qemu v2.x, for example), sd_read_block_characteristics() may attempt an out-of-bounds memory access when accessing the zoned field at offset 8.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47743", "url": "https://ubuntu.com/security/CVE-2024-47743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: prevent NULL pointer dereference in find_asymmetric_key() In find_asymmetric_key(), if all NULLs are passed in the id_{0,1,2} arguments, the kernel will first emit WARN but then have an oops because id_2 gets dereferenced anyway. Add the missing id_2 check and move WARN_ON() to the final else branch to avoid duplicate NULL checks. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47727", "url": "https://ubuntu.com/security/CVE-2024-47727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/tdx: Fix \"in-kernel MMIO\" check TDX only supports kernel-initiated MMIO operations. The handle_mmio() function checks if the #VE exception occurred in the kernel and rejects the operation if it did not. However, userspace can deceive the kernel into performing MMIO on its behalf. For example, if userspace can point a syscall to an MMIO address, syscall does get_user() or put_user() on it, triggering MMIO #VE. The kernel will treat the #VE as in-kernel MMIO. Ensure that the target MMIO address is within the kernel before decoding instruction.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47744", "url": "https://ubuntu.com/security/CVE-2024-47744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Use dedicated mutex to protect kvm_usage_count to avoid deadlock Use a dedicated mutex to guard kvm_usage_count to fix a potential deadlock on x86 due to a chain of locks and SRCU synchronizations. Translating the below lockdep splat, CPU1 #6 will wait on CPU0 #1, CPU0 #8 will wait on CPU2 #3, and CPU2 #7 will wait on CPU1 #4 (if there's a writer, due to the fairness of r/w semaphores). CPU0 CPU1 CPU2 1 lock(&kvm->slots_lock); 2 lock(&vcpu->mutex); 3 lock(&kvm->srcu); 4 lock(cpu_hotplug_lock); 5 lock(kvm_lock); 6 lock(&kvm->slots_lock); 7 lock(cpu_hotplug_lock); 8 sync(&kvm->srcu); Note, there are likely more potential deadlocks in KVM x86, e.g. the same pattern of taking cpu_hotplug_lock outside of kvm_lock likely exists with __kvmclock_cpufreq_notifier(): cpuhp_cpufreq_online() | -> cpufreq_online() | -> cpufreq_gov_performance_limits() | -> __cpufreq_driver_target() | -> __target_index() | -> cpufreq_freq_transition_begin() | -> cpufreq_notify_transition() | -> ... __kvmclock_cpufreq_notifier() But, actually triggering such deadlocks is beyond rare due to the combination of dependencies and timings involved. E.g. the cpufreq notifier is only used on older CPUs without a constant TSC, mucking with the NX hugepage mitigation while VMs are running is very uncommon, and doing so while also onlining/offlining a CPU (necessary to generate contention on cpu_hotplug_lock) would be even more unusual. The most robust solution to the general cpu_hotplug_lock issue is likely to switch vm_list to be an RCU-protected list, e.g. so that x86's cpufreq notifier doesn't to take kvm_lock. For now, settle for fixing the most blatant deadlock, as switching to an RCU-protected list is a much more involved change, but add a comment in locking.rst to call out that care needs to be taken when walking holding kvm_lock and walking vm_list. ====================================================== WARNING: possible circular locking dependency detected 6.10.0-smp--c257535a0c9d-pip #330 Tainted: G S O ------------------------------------------------------ tee/35048 is trying to acquire lock: ff6a80eced71e0a8 (&kvm->slots_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x179/0x1e0 [kvm] but task is already holding lock: ffffffffc07abb08 (kvm_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x14a/0x1e0 [kvm] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (kvm_lock){+.+.}-{3:3}: __mutex_lock+0x6a/0xb40 mutex_lock_nested+0x1f/0x30 kvm_dev_ioctl+0x4fb/0xe50 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #2 (cpu_hotplug_lock){++++}-{0:0}: cpus_read_lock+0x2e/0xb0 static_key_slow_inc+0x16/0x30 kvm_lapic_set_base+0x6a/0x1c0 [kvm] kvm_set_apic_base+0x8f/0xe0 [kvm] kvm_set_msr_common+0x9ae/0xf80 [kvm] vmx_set_msr+0xa54/0xbe0 [kvm_intel] __kvm_set_msr+0xb6/0x1a0 [kvm] kvm_arch_vcpu_ioctl+0xeca/0x10c0 [kvm] kvm_vcpu_ioctl+0x485/0x5b0 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (&kvm->srcu){.+.+}-{0:0}: __synchronize_srcu+0x44/0x1a0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47719", "url": "https://ubuntu.com/security/CVE-2024-47719", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommufd: Protect against overflow of ALIGN() during iova allocation Userspace can supply an iova and uptr such that the target iova alignment becomes really big and ALIGN() overflows which corrupts the selected area range during allocation. CONFIG_IOMMUFD_TEST can detect this: WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline] WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352 Modules linked in: CPU: 1 PID: 5092 Comm: syz-executor294 Not tainted 6.10.0-rc5-syzkaller-00294-g3ffea9a7a6f7 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024 RIP: 0010:iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline] RIP: 0010:iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352 Code: fc e9 a4 f3 ff ff e8 1a 8b 4c fc 41 be e4 ff ff ff e9 8a f3 ff ff e8 0a 8b 4c fc 90 0f 0b 90 e9 37 f5 ff ff e8 fc 8a 4c fc 90 <0f> 0b 90 e9 68 f3 ff ff 48 c7 c1 ec 82 ad 8f 80 e1 07 80 c1 03 38 RSP: 0018:ffffc90003ebf9e0 EFLAGS: 00010293 RAX: ffffffff85499fa4 RBX: 00000000ffffffef RCX: ffff888079b49e00 RDX: 0000000000000000 RSI: 00000000ffffffef RDI: 0000000000000000 RBP: ffffc90003ebfc50 R08: ffffffff85499b30 R09: ffffffff85499942 R10: 0000000000000002 R11: ffff888079b49e00 R12: ffff8880228e0010 R13: 0000000000000000 R14: 1ffff920007d7f68 R15: ffffc90003ebfd00 FS: 000055557d760380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000005fdeb8 CR3: 000000007404a000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: iommufd_ioas_copy+0x610/0x7b0 drivers/iommu/iommufd/ioas.c:274 iommufd_fops_ioctl+0x4d9/0x5a0 drivers/iommu/iommufd/main.c:421 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Cap the automatic alignment to the huge page size, which is probably a better idea overall. Huge automatic alignments can fragment and chew up the available IOVA space without any reason.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47745", "url": "https://ubuntu.com/security/CVE-2024-47745", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: call the security_mmap_file() LSM hook in remap_file_pages() The remap_file_pages syscall handler calls do_mmap() directly, which doesn't contain the LSM security check. And if the process has called personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for RW pages, this will actually result in remapping the pages to RWX, bypassing a W^X policy enforced by SELinux. So we should check prot by security_mmap_file LSM hook in the remap_file_pages syscall handler before do_mmap() is called. Otherwise, it potentially permits an attacker to bypass a W^X policy enforced by SELinux. The bypass is similar to CVE-2016-10044, which bypass the same thing via AIO and can be found in [1]. The PoC: $ cat > test.c int main(void) { \tsize_t pagesz = sysconf(_SC_PAGE_SIZE); \tint mfd = syscall(SYS_memfd_create, \"test\", 0); \tconst char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE, \t\tMAP_SHARED, mfd, 0); \tunsigned int old = syscall(SYS_personality, 0xffffffff); \tsyscall(SYS_personality, READ_IMPLIES_EXEC | old); \tsyscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0); \tsyscall(SYS_personality, old); \t// show the RWX page exists even if W^X policy is enforced \tint fd = open(\"/proc/self/maps\", O_RDONLY); \tunsigned char buf2[1024]; \twhile (1) { \t\tint ret = read(fd, buf2, 1024); \t\tif (ret <= 0) break; \t\twrite(1, buf2, ret); \t} \tclose(fd); } $ gcc test.c -o test $ ./test | grep rwx 7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted) [PM: subject line tweaks]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47746", "url": "https://ubuntu.com/security/CVE-2024-47746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: use exclusive lock when FUSE_I_CACHE_IO_MODE is set This may be a typo. The comment has said shared locks are not allowed when this bit is set. If using shared lock, the wait in `fuse_file_cached_io_open` may be forever.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47734", "url": "https://ubuntu.com/security/CVE-2024-47734", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: Fix unnecessary warnings and logs from bond_xdp_get_xmit_slave() syzbot reported a WARNING in bond_xdp_get_xmit_slave. To reproduce this[1], one bond device (bond1) has xdpdrv, which increases bpf_master_redirect_enabled_key. Another bond device (bond0) which is unsupported by XDP but its slave (veth3) has xdpgeneric that returns XDP_TX. This triggers WARN_ON_ONCE() from the xdp_master_redirect(). To reduce unnecessary warnings and improve log management, we need to delete the WARN_ON_ONCE() and add ratelimit to the netdev_err(). [1] Steps to reproduce: # Needs tx_xdp with return XDP_TX; ip l add veth0 type veth peer veth1 ip l add veth3 type veth peer veth4 ip l add bond0 type bond mode 6 # BOND_MODE_ALB, unsupported by XDP ip l add bond1 type bond # BOND_MODE_ROUNDROBIN by default ip l set veth0 master bond1 ip l set bond1 up # Increases bpf_master_redirect_enabled_key ip l set dev bond1 xdpdrv object tx_xdp.o section xdp_tx ip l set veth3 master bond0 ip l set bond0 up ip l set veth4 up # Triggers WARN_ON_ONCE() from the xdp_master_redirect() ip l set veth3 xdpgeneric object tx_xdp.o section xdp_tx", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47684", "url": "https://ubuntu.com/security/CVE-2024-47684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: check skb is non-NULL in tcp_rto_delta_us() We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic kernel that are running ceph and recently hit a null ptr dereference in tcp_rearm_rto(). Initially hitting it from the TLP path, but then later we also saw it getting hit from the RACK case as well. Here are examples of the oops messages we saw in each of those cases: Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020 Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode Jul 26 15:05:02 rx [11061395.792971] #PF: error_code(0x0000) - not-present page Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0 Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI Jul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu Jul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023 Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 <48> 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3 Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246 Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000 Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60 Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8 Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900 Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30 Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000 Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0 Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554 Jul 26 15:05:02 rx [11061395.916786] Call Trace: Jul 26 15:05:02 rx [11061395.919488] Jul 26 15:05:02 rx [11061395.921765] ? show_regs.cold+0x1a/0x1f Jul 26 15:05:02 rx [11061395.925859] ? __die+0x90/0xd9 Jul 26 15:05:02 rx [11061395.929169] ? no_context+0x196/0x380 Jul 26 15:05:02 rx [11061395.933088] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0 Jul 26 15:05:02 rx [11061395.938216] ? ip6_sublist_rcv_finish+0x3d/0x50 Jul 26 15:05:02 rx [11061395.943000] ? __bad_area_nosemaphore+0x50/0x1a0 Jul 26 15:05:02 rx [11061395.947873] ? bad_area_nosemaphore+0x16/0x20 Jul 26 15:05:02 rx [11061395.952486] ? do_user_addr_fault+0x267/0x450 Jul 26 15:05:02 rx [11061395.957104] ? ipv6_list_rcv+0x112/0x140 Jul 26 15:05:02 rx [11061395.961279] ? __do_page_fault+0x58/0x90 Jul 26 15:05:02 rx [11061395.965458] ? do_page_fault+0x2c/0xe0 Jul 26 15:05:02 rx [11061395.969465] ? page_fault+0x34/0x40 Jul 26 15:05:02 rx [11061395.973217] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.977313] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.981408] tcp_send_loss_probe+0x10b/0x220 Jul 26 15:05:02 rx [11061395.985937] tcp_write_timer_handler+0x1b4/0x240 Jul 26 15:05:02 rx [11061395.990809] tcp_write_timer+0x9e/0xe0 Jul 26 15:05:02 rx [11061395.994814] ? tcp_write_timer_handler+0x240/0x240 Jul 26 15:05:02 rx [11061395.999866] call_timer_fn+0x32/0x130 Jul 26 15:05:02 rx [11061396.003782] __run_timers.part.0+0x180/0x280 Jul 26 15:05:02 rx [11061396.008309] ? recalibrate_cpu_khz+0x10/0x10 Jul 26 15:05:02 rx [11061396.012841] ? native_x2apic_icr_write+0x30/0x30 Jul 26 15:05:02 rx [11061396.017718] ? lapic_next_even ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47747", "url": "https://ubuntu.com/security/CVE-2024-47747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race Condition In the ether3_probe function, a timer is initialized with a callback function ether3_ledoff, bound to &prev(dev)->timer. Once the timer is started, there is a risk of a race condition if the module or device is removed, triggering the ether3_remove function to perform cleanup. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | ether3_ledoff ether3_remove | free_netdev(dev); | put_devic | kfree(dev); | | ether3_outw(priv(dev)->regs.config2 |= CFG2_CTRLO, REG_CONFIG2); | // use dev Fix it by ensuring that the timer is canceled before proceeding with the cleanup in ether3_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47685", "url": "https://ubuntu.com/security/CVE-2024-47685", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put() syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending garbage on the four reserved tcp bits (th->res1) Use skb_put_zero() to clear the whole TCP header, as done in nf_reject_ip_tcphdr_put() BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5661 [inline] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775 process_backlog+0x4ad/0xa50 net/core/dev.c:6108 __napi_poll+0xe7/0x980 net/core/dev.c:6772 napi_poll net/core/dev.c:6841 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963 handle_softirqs+0x1ce/0x800 kernel/softirq.c:554 __do_softirq+0x14/0x1a kernel/softirq.c:588 do_softirq+0x9a/0x100 kernel/softirq.c:455 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline] __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450 dev_queue_xmit include/linux/netdevice.h:3105 [inline] neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366 inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135 __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143 tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333 __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679 inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750 __sys_connect_file net/socket.c:2061 [inline] __sys_connect+0x606/0x690 net/socket.c:2078 __do_sys_connect net/socket.c:2088 [inline] __se_sys_connect net/socket.c:2085 [inline] __x64_sys_connect+0x91/0xe0 net/socket.c:2085 x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43 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 Uninit was stored to memory at: nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47686", "url": "https://ubuntu.com/security/CVE-2024-47686", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ep93xx: clock: Fix off by one in ep93xx_div_recalc_rate() The psc->div[] array has psc->num_div elements. These values come from when we call clk_hw_register_div(). It's adc_divisors and ARRAY_SIZE(adc_divisors)) and so on. So this condition needs to be >= instead of > to prevent an out of bounds read.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47748", "url": "https://ubuntu.com/security/CVE-2024-47748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost_vdpa: assign irq bypass producer token correctly We used to call irq_bypass_unregister_producer() in vhost_vdpa_setup_vq_irq() which is problematic as we don't know if the token pointer is still valid or not. Actually, we use the eventfd_ctx as the token so the life cycle of the token should be bound to the VHOST_SET_VRING_CALL instead of vhost_vdpa_setup_vq_irq() which could be called by set_status(). Fixing this by setting up irq bypass producer's token when handling VHOST_SET_VRING_CALL and un-registering the producer before calling vhost_vring_ioctl() to prevent a possible use after free as eventfd could have been released in vhost_vring_ioctl(). And such registering and unregistering will only be done if DRIVER_OK is set.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47687", "url": "https://ubuntu.com/security/CVE-2024-47687", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa/mlx5: Fix invalid mr resource destroy Certain error paths from mlx5_vdpa_dev_add() can end up releasing mr resources which never got initialized in the first place. This patch adds the missing check in mlx5_vdpa_destroy_mr_resources() to block releasing non-initialized mr resources. Reference trace: mlx5_core 0000:08:00.2: mlx5_vdpa_dev_add:3274:(pid 2700) warning: No mac address provisioned? BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 140216067 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 8 PID: 2700 Comm: vdpa Kdump: loaded Not tainted 5.14.0-496.el9.x86_64 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:vhost_iotlb_del_range+0xf/0xe0 [vhost_iotlb] Code: [...] RSP: 0018:ff1c823ac23077f0 EFLAGS: 00010246 RAX: ffffffffc1a21a60 RBX: ffffffff899567a0 RCX: 0000000000000000 RDX: ffffffffffffffff RSI: 0000000000000000 RDI: 0000000000000000 RBP: ff1bda1f7c21e800 R08: 0000000000000000 R09: ff1c823ac2307670 R10: ff1c823ac2307668 R11: ffffffff8a9e7b68 R12: 0000000000000000 R13: 0000000000000000 R14: ff1bda1f43e341a0 R15: 00000000ffffffea FS: 00007f56eba7c740(0000) GS:ff1bda269f800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000104d90001 CR4: 0000000000771ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? mlx5_vdpa_free+0x3d/0x150 [mlx5_vdpa] ? __die_body.cold+0x8/0xd ? page_fault_oops+0x134/0x170 ? __irq_work_queue_local+0x2b/0xc0 ? irq_work_queue+0x2c/0x50 ? exc_page_fault+0x62/0x150 ? asm_exc_page_fault+0x22/0x30 ? __pfx_mlx5_vdpa_free+0x10/0x10 [mlx5_vdpa] ? vhost_iotlb_del_range+0xf/0xe0 [vhost_iotlb] mlx5_vdpa_free+0x3d/0x150 [mlx5_vdpa] vdpa_release_dev+0x1e/0x50 [vdpa] device_release+0x31/0x90 kobject_cleanup+0x37/0x130 mlx5_vdpa_dev_add+0x2d2/0x7a0 [mlx5_vdpa] vdpa_nl_cmd_dev_add_set_doit+0x277/0x4c0 [vdpa] genl_family_rcv_msg_doit+0xd9/0x130 genl_family_rcv_msg+0x14d/0x220 ? __pfx_vdpa_nl_cmd_dev_add_set_doit+0x10/0x10 [vdpa] ? _copy_to_user+0x1a/0x30 ? move_addr_to_user+0x4b/0xe0 genl_rcv_msg+0x47/0xa0 ? __import_iovec+0x46/0x150 ? __pfx_genl_rcv_msg+0x10/0x10 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x245/0x370 netlink_sendmsg+0x206/0x440 __sys_sendto+0x1dc/0x1f0 ? do_read_fault+0x10c/0x1d0 ? do_pte_missing+0x10d/0x190 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x5c/0xf0 ? __count_memcg_events+0x4f/0xb0 ? mm_account_fault+0x6c/0x100 ? handle_mm_fault+0x116/0x270 ? do_user_addr_fault+0x1d6/0x6a0 ? do_syscall_64+0x6b/0xf0 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 entry_SYSCALL_64_after_hwframe+0x78/0x80", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47688", "url": "https://ubuntu.com/security/CVE-2024-47688", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: driver core: Fix a potential null-ptr-deref in module_add_driver() Inject fault while probing of-fpga-region, if kasprintf() fails in module_add_driver(), the second sysfs_remove_link() in exit path will cause null-ptr-deref as below because kernfs_name_hash() will call strlen() with NULL driver_name. Fix it by releasing resources based on the exit path sequence. \t KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] \t Mem abort info: \t ESR = 0x0000000096000005 \t EC = 0x25: DABT (current EL), IL = 32 bits \t SET = 0, FnV = 0 \t EA = 0, S1PTW = 0 \t FSC = 0x05: level 1 translation fault \t Data abort info: \t ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 \t CM = 0, WnR = 0, TnD = 0, TagAccess = 0 \t GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 \t [dfffffc000000000] address between user and kernel address ranges \t Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP \t Dumping ftrace buffer: \t (ftrace buffer empty) \t Modules linked in: of_fpga_region(+) fpga_region fpga_bridge cfg80211 rfkill 8021q garp mrp stp llc ipv6 [last unloaded: of_fpga_region] \t CPU: 2 UID: 0 PID: 2036 Comm: modprobe Not tainted 6.11.0-rc2-g6a0e38264012 #295 \t Hardware name: linux,dummy-virt (DT) \t pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) \t pc : strlen+0x24/0xb0 \t lr : kernfs_name_hash+0x1c/0xc4 \t sp : ffffffc081f97380 \t x29: ffffffc081f97380 x28: ffffffc081f97b90 x27: ffffff80c821c2a0 \t x26: ffffffedac0be418 x25: 0000000000000000 x24: ffffff80c09d2000 \t x23: 0000000000000000 x22: 0000000000000000 x21: 0000000000000000 \t x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000001840 \t x17: 0000000000000000 x16: 0000000000000000 x15: 1ffffff8103f2e42 \t x14: 00000000f1f1f1f1 x13: 0000000000000004 x12: ffffffb01812d61d \t x11: 1ffffff01812d61c x10: ffffffb01812d61c x9 : dfffffc000000000 \t x8 : 0000004fe7ed29e4 x7 : ffffff80c096b0e7 x6 : 0000000000000001 \t x5 : ffffff80c096b0e0 x4 : 1ffffffdb990efa2 x3 : 0000000000000000 \t x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000000 \t Call trace: \t strlen+0x24/0xb0 \t kernfs_name_hash+0x1c/0xc4 \t kernfs_find_ns+0x118/0x2e8 \t kernfs_remove_by_name_ns+0x80/0x100 \t sysfs_remove_link+0x74/0xa8 \t module_add_driver+0x278/0x394 \t bus_add_driver+0x1f0/0x43c \t driver_register+0xf4/0x3c0 \t __platform_driver_register+0x60/0x88 \t of_fpga_region_init+0x20/0x1000 [of_fpga_region] \t do_one_initcall+0x110/0x788 \t do_init_module+0x1dc/0x5c8 \t load_module+0x3c38/0x4cac \t init_module_from_file+0xd4/0x128 \t idempotent_init_module+0x2cc/0x528 \t __arm64_sys_finit_module+0xac/0x100 \t invoke_syscall+0x6c/0x258 \t el0_svc_common.constprop.0+0x160/0x22c \t do_el0_svc+0x44/0x5c \t el0_svc+0x48/0xb8 \t el0t_64_sync_handler+0x13c/0x158 \t el0t_64_sync+0x190/0x194 \t Code: f2fbffe1 a90157f4 12000802 aa0003f5 (38e16861) \t ---[ end trace 0000000000000000 ]--- \t Kernel panic - not syncing: Oops: Fatal exception", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47689", "url": "https://ubuntu.com/security/CVE-2024-47689", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to don't set SB_RDONLY in f2fs_handle_critical_error() syzbot reports a f2fs bug as below: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 58 at kernel/rcu/sync.c:177 rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177 CPU: 1 UID: 0 PID: 58 Comm: kworker/1:2 Not tainted 6.10.0-syzkaller-12562-g1722389b0d86 #0 Workqueue: events destroy_super_work RIP: 0010:rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177 Call Trace: percpu_free_rwsem+0x41/0x80 kernel/locking/percpu-rwsem.c:42 destroy_super_work+0xec/0x130 fs/super.c:282 process_one_work kernel/workqueue.c:3231 [inline] process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 worker_thread+0x86d/0xd40 kernel/workqueue.c:3390 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 As Christian Brauner pointed out [1]: the root cause is f2fs sets SB_RDONLY flag in internal function, rather than setting the flag covered w/ sb->s_umount semaphore via remount procedure, then below race condition causes this bug: - freeze_super() - sb_wait_write(sb, SB_FREEZE_WRITE) - sb_wait_write(sb, SB_FREEZE_PAGEFAULT) - sb_wait_write(sb, SB_FREEZE_FS) \t\t\t\t\t- f2fs_handle_critical_error \t\t\t\t\t - sb->s_flags |= SB_RDONLY - thaw_super - thaw_super_locked - sb_rdonly() is true, so it skips sb_freeze_unlock(sb, SB_FREEZE_FS) - deactivate_locked_super Since f2fs has almost the same logic as ext4 [2] when handling critical error in filesystem if it mounts w/ errors=remount-ro option: - set CP_ERROR_FLAG flag which indicates filesystem is stopped - record errors to superblock - set SB_RDONLY falg Once we set CP_ERROR_FLAG flag, all writable interfaces can detect the flag and stop any further updates on filesystem. So, it is safe to not set SB_RDONLY flag, let's remove the logic and keep in line w/ ext4 [3]. [1] https://lore.kernel.org/all/20240729-himbeeren-funknetz-96e62f9c7aee@brauner [2] https://lore.kernel.org/all/20240729132721.hxih6ehigadqf7wx@quack3 [3] https://lore.kernel.org/linux-ext4/20240805201241.27286-1-jack@suse.cz", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47690", "url": "https://ubuntu.com/security/CVE-2024-47690", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: get rid of online repaire on corrupted directory syzbot reports a f2fs bug as below: kernel BUG at fs/f2fs/inode.c:896! RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Call Trace: evict+0x532/0x950 fs/inode.c:704 dispose_list fs/inode.c:747 [inline] evict_inodes+0x5f9/0x690 fs/inode.c:797 generic_shutdown_super+0x9d/0x2d0 fs/super.c:627 kill_block_super+0x44/0x90 fs/super.c:1696 kill_f2fs_super+0x344/0x690 fs/f2fs/super.c:4898 deactivate_locked_super+0xc4/0x130 fs/super.c:473 cleanup_mnt+0x41f/0x4b0 fs/namespace.c:1373 task_work_run+0x24f/0x310 kernel/task_work.c:228 ptrace_notify+0x2d2/0x380 kernel/signal.c:2402 ptrace_report_syscall include/linux/ptrace.h:415 [inline] ptrace_report_syscall_exit include/linux/ptrace.h:477 [inline] syscall_exit_work+0xc6/0x190 kernel/entry/common.c:173 syscall_exit_to_user_mode_prepare kernel/entry/common.c:200 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:205 [inline] syscall_exit_to_user_mode+0x279/0x370 kernel/entry/common.c:218 do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Online repaire on corrupted directory in f2fs_lookup() can generate dirty data/meta while racing w/ readonly remount, it may leave dirty inode after filesystem becomes readonly, however, checkpoint() will skips flushing dirty inode in a state of readonly mode, result in above panic. Let's get rid of online repaire in f2fs_lookup(), and leave the work to fsck.f2fs.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47691", "url": "https://ubuntu.com/security/CVE-2024-47691", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread() syzbot reports a f2fs bug as below: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_report+0xe8/0x550 mm/kasan/report.c:491 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 instrument_atomic_read_write include/linux/instrumented.h:96 [inline] atomic_fetch_add_relaxed include/linux/atomic/atomic-instrumented.h:252 [inline] __refcount_add include/linux/refcount.h:184 [inline] __refcount_inc include/linux/refcount.h:241 [inline] refcount_inc include/linux/refcount.h:258 [inline] get_task_struct include/linux/sched/task.h:118 [inline] kthread_stop+0xca/0x630 kernel/kthread.c:704 f2fs_stop_gc_thread+0x65/0xb0 fs/f2fs/gc.c:210 f2fs_do_shutdown+0x192/0x540 fs/f2fs/file.c:2283 f2fs_ioc_shutdown fs/f2fs/file.c:2325 [inline] __f2fs_ioctl+0x443a/0xbe60 fs/f2fs/file.c:4325 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f The root cause is below race condition, it may cause use-after-free issue in sbi->gc_th pointer. - remount - f2fs_remount - f2fs_stop_gc_thread - kfree(gc_th) \t\t\t\t- f2fs_ioc_shutdown \t\t\t\t - f2fs_do_shutdown \t\t\t\t - f2fs_stop_gc_thread \t\t\t\t - kthread_stop(gc_th->f2fs_gc_task) : sbi->gc_thread = NULL; We will call f2fs_do_shutdown() in two paths: - for f2fs_ioc_shutdown() path, we should grab sb->s_umount semaphore for fixing. - for f2fs_shutdown() path, it's safe since caller has already grabbed sb->s_umount semaphore.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47692", "url": "https://ubuntu.com/security/CVE-2024-47692", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: return -EINVAL when namelen is 0 When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may result in namelen being 0, which will cause memdup_user() to return ZERO_SIZE_PTR. When we access the name.data that has been assigned the value of ZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is triggered. [ T1205] ================================================================== [ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260 [ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205 [ T1205] [ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406 [ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ T1205] Call Trace: [ T1205] dump_stack+0x9a/0xd0 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] __kasan_report.cold+0x34/0x84 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] kasan_report+0x3a/0x50 [ T1205] nfs4_client_to_reclaim+0xe9/0x260 [ T1205] ? nfsd4_release_lockowner+0x410/0x410 [ T1205] cld_pipe_downcall+0x5ca/0x760 [ T1205] ? nfsd4_cld_tracking_exit+0x1d0/0x1d0 [ T1205] ? down_write_killable_nested+0x170/0x170 [ T1205] ? avc_policy_seqno+0x28/0x40 [ T1205] ? selinux_file_permission+0x1b4/0x1e0 [ T1205] rpc_pipe_write+0x84/0xb0 [ T1205] vfs_write+0x143/0x520 [ T1205] ksys_write+0xc9/0x170 [ T1205] ? __ia32_sys_read+0x50/0x50 [ T1205] ? ktime_get_coarse_real_ts64+0xfe/0x110 [ T1205] ? ktime_get_coarse_real_ts64+0xa2/0x110 [ T1205] do_syscall_64+0x33/0x40 [ T1205] entry_SYSCALL_64_after_hwframe+0x67/0xd1 [ T1205] RIP: 0033:0x7fdbdb761bc7 [ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 514 [ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7 [ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008 [ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001 [ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b [ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000 [ T1205] ================================================================== Fix it by checking namelen.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47737", "url": "https://ubuntu.com/security/CVE-2024-47737", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: call cache_put if xdr_reserve_space returns NULL If not enough buffer space available, but idmap_lookup has triggered lookup_fn which calls cache_get and returns successfully. Then we missed to call cache_put here which pairs with cache_get. Reviwed-by: Jeff Layton ", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2023-52917", "url": "https://ubuntu.com/security/CVE-2023-52917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir() The debugfs_create_dir() function returns error pointers. It never returns NULL. So use IS_ERR() to check it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47749", "url": "https://ubuntu.com/security/CVE-2024-47749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Added NULL check for lookup_atid The lookup_atid() function can return NULL if the ATID is invalid or does not exist in the identifier table, which could lead to dereferencing a null pointer without a check in the `act_establish()` and `act_open_rpl()` functions. Add a NULL check to prevent null pointer dereferencing. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47735", "url": "https://ubuntu.com/security/CVE-2024-47735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled Fix missuse of spin_lock_irq()/spin_unlock_irq() when spin_lock_irqsave()/spin_lock_irqrestore() was hold. This was discovered through the lock debugging, and the corresponding log is as follows: raw_local_irq_restore() called with IRQs enabled WARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40 ... Call trace: warn_bogus_irq_restore+0x30/0x40 _raw_spin_unlock_irqrestore+0x84/0xc8 add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2] hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2] hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2] create_qp+0x138/0x258 ib_create_qp_kernel+0x50/0xe8 create_mad_qp+0xa8/0x128 ib_mad_port_open+0x218/0x448 ib_mad_init_device+0x70/0x1f8 add_client_context+0xfc/0x220 enable_device_and_get+0xd0/0x140 ib_register_device.part.0+0xf4/0x1c8 ib_register_device+0x34/0x50 hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2] hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2] __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2] hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47750", "url": "https://ubuntu.com/security/CVE-2024-47750", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix Use-After-Free of rsv_qp on HIP08 Currently rsv_qp is freed before ib_unregister_device() is called on HIP08. During the time interval, users can still dereg MR and rsv_qp will be used in this process, leading to a UAF. Move the release of rsv_qp after calling ib_unregister_device() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47751", "url": "https://ubuntu.com/security/CVE-2024-47751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: kirin: Fix buffer overflow in kirin_pcie_parse_port() Within kirin_pcie_parse_port(), the pcie->num_slots is compared to pcie->gpio_id_reset size (MAX_PCI_SLOTS) which is correct and would lead to an overflow. Thus, fix condition to pcie->num_slots + 1 >= MAX_PCI_SLOTS and move pcie->num_slots increment below the if-statement to avoid out-of-bounds array access. Found by Linux Verification Center (linuxtesting.org) with SVACE. [kwilczynski: commit log]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47693", "url": "https://ubuntu.com/security/CVE-2024-47693", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/core: Fix ib_cache_setup_one error flow cleanup When ib_cache_update return an error, we exit ib_cache_setup_one instantly with no proper cleanup, even though before this we had already successfully done gid_table_setup_one, that results in the kernel WARN below. Do proper cleanup using gid_table_cleanup_one before returning the err in order to fix the issue. WARNING: CPU: 4 PID: 922 at drivers/infiniband/core/cache.c:806 gid_table_release_one+0x181/0x1a0 Modules linked in: CPU: 4 UID: 0 PID: 922 Comm: c_repro Not tainted 6.11.0-rc1+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:gid_table_release_one+0x181/0x1a0 Code: 44 8b 38 75 0c e8 2f cb 34 ff 4d 8b b5 28 05 00 00 e8 23 cb 34 ff 44 89 f9 89 da 4c 89 f6 48 c7 c7 d0 58 14 83 e8 4f de 21 ff <0f> 0b 4c 8b 75 30 e9 54 ff ff ff 48 8 3 c4 10 5b 5d 41 5c 41 5d 41 RSP: 0018:ffffc90002b835b0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c8527 RDX: 0000000000000000 RSI: ffffffff811c8534 RDI: 0000000000000001 RBP: ffff8881011b3d00 R08: ffff88810b3abe00 R09: 205d303839303631 R10: 666572207972746e R11: 72746e6520444947 R12: 0000000000000001 R13: ffff888106390000 R14: ffff8881011f2110 R15: 0000000000000001 FS: 00007fecc3b70800(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000340 CR3: 000000010435a001 CR4: 00000000003706b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? show_regs+0x94/0xa0 ? __warn+0x9e/0x1c0 ? gid_table_release_one+0x181/0x1a0 ? report_bug+0x1f9/0x340 ? gid_table_release_one+0x181/0x1a0 ? handle_bug+0xa2/0x110 ? exc_invalid_op+0x31/0xa0 ? asm_exc_invalid_op+0x16/0x20 ? __warn_printk+0xc7/0x180 ? __warn_printk+0xd4/0x180 ? gid_table_release_one+0x181/0x1a0 ib_device_release+0x71/0xe0 ? __pfx_ib_device_release+0x10/0x10 device_release+0x44/0xd0 kobject_put+0x135/0x3d0 put_device+0x20/0x30 rxe_net_add+0x7d/0xa0 rxe_newlink+0xd7/0x190 nldev_newlink+0x1b0/0x2a0 ? __pfx_nldev_newlink+0x10/0x10 rdma_nl_rcv_msg+0x1ad/0x2e0 rdma_nl_rcv_skb.constprop.0+0x176/0x210 netlink_unicast+0x2de/0x400 netlink_sendmsg+0x306/0x660 __sock_sendmsg+0x110/0x120 ____sys_sendmsg+0x30e/0x390 ___sys_sendmsg+0x9b/0xf0 ? kstrtouint+0x6e/0xa0 ? kstrtouint_from_user+0x7c/0xb0 ? get_pid_task+0xb0/0xd0 ? proc_fail_nth_write+0x5b/0x140 ? __fget_light+0x9a/0x200 ? preempt_count_add+0x47/0xa0 __sys_sendmsg+0x61/0xd0 do_syscall_64+0x50/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47694", "url": "https://ubuntu.com/security/CVE-2024-47694", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mlx5: Fix UMR pd cleanup on error flow of driver init The cited commit moves the pd allocation from function mlx5r_umr_resource_cleanup() to a new function mlx5r_umr_cleanup(). So the fix in commit [1] is broken. In error flow, will hit panic [2]. Fix it by checking pd pointer to avoid panic if it is NULL; [1] RDMA/mlx5: Fix UMR cleanup on error flow of driver init [2] [ 347.567063] infiniband mlx5_0: Couldn't register device with driver model [ 347.591382] BUG: kernel NULL pointer dereference, address: 0000000000000020 [ 347.593438] #PF: supervisor read access in kernel mode [ 347.595176] #PF: error_code(0x0000) - not-present page [ 347.596962] PGD 0 P4D 0 [ 347.601361] RIP: 0010:ib_dealloc_pd_user+0x12/0xc0 [ib_core] [ 347.604171] RSP: 0018:ffff888106293b10 EFLAGS: 00010282 [ 347.604834] RAX: 0000000000000000 RBX: 000000000000000e RCX: 0000000000000000 [ 347.605672] RDX: ffff888106293ad0 RSI: 0000000000000000 RDI: 0000000000000000 [ 347.606529] RBP: 0000000000000000 R08: ffff888106293ae0 R09: ffff888106293ae0 [ 347.607379] R10: 0000000000000a06 R11: 0000000000000000 R12: 0000000000000000 [ 347.608224] R13: ffffffffa0704dc0 R14: 0000000000000001 R15: 0000000000000001 [ 347.609067] FS: 00007fdc720cd9c0(0000) GS:ffff88852c880000(0000) knlGS:0000000000000000 [ 347.610094] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 347.610727] CR2: 0000000000000020 CR3: 0000000103012003 CR4: 0000000000370eb0 [ 347.611421] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 347.612113] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 347.612804] Call Trace: [ 347.613130] [ 347.613417] ? __die+0x20/0x60 [ 347.613793] ? page_fault_oops+0x150/0x3e0 [ 347.614243] ? free_msg+0x68/0x80 [mlx5_core] [ 347.614840] ? cmd_exec+0x48f/0x11d0 [mlx5_core] [ 347.615359] ? exc_page_fault+0x74/0x130 [ 347.615808] ? asm_exc_page_fault+0x22/0x30 [ 347.616273] ? ib_dealloc_pd_user+0x12/0xc0 [ib_core] [ 347.616801] mlx5r_umr_cleanup+0x23/0x90 [mlx5_ib] [ 347.617365] mlx5_ib_stage_pre_ib_reg_umr_cleanup+0x36/0x40 [mlx5_ib] [ 347.618025] __mlx5_ib_add+0x96/0xd0 [mlx5_ib] [ 347.618539] mlx5r_probe+0xe9/0x310 [mlx5_ib] [ 347.619032] ? kernfs_add_one+0x107/0x150 [ 347.619478] ? __mlx5_ib_add+0xd0/0xd0 [mlx5_ib] [ 347.619984] auxiliary_bus_probe+0x3e/0x90 [ 347.620448] really_probe+0xc5/0x3a0 [ 347.620857] __driver_probe_device+0x80/0x160 [ 347.621325] driver_probe_device+0x1e/0x90 [ 347.621770] __driver_attach+0xec/0x1c0 [ 347.622213] ? __device_attach_driver+0x100/0x100 [ 347.622724] bus_for_each_dev+0x71/0xc0 [ 347.623151] bus_add_driver+0xed/0x240 [ 347.623570] driver_register+0x58/0x100 [ 347.623998] __auxiliary_driver_register+0x6a/0xc0 [ 347.624499] ? driver_register+0xae/0x100 [ 347.624940] ? 0xffffffffa0893000 [ 347.625329] mlx5_ib_init+0x16a/0x1e0 [mlx5_ib] [ 347.625845] do_one_initcall+0x4a/0x2a0 [ 347.626273] ? gcov_event+0x2e2/0x3a0 [ 347.626706] do_init_module+0x8a/0x260 [ 347.627126] init_module_from_file+0x8b/0xd0 [ 347.627596] __x64_sys_finit_module+0x1ca/0x2f0 [ 347.628089] do_syscall_64+0x4c/0x100", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47695", "url": "https://ubuntu.com/security/CVE-2024-47695", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds In the function init_conns(), after the create_con() and create_cm() for loop if something fails. In the cleanup for loop after the destroy tag, we access out of bound memory because cid is set to clt_path->s.con_num. This commits resets the cid to clt_path->s.con_num - 1, to stay in bounds in the cleanup loop later.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47752", "url": "https://ubuntu.com/security/CVE-2024-47752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix H264 stateless decoder smatch warning Fix a smatch static checker warning on vdec_h264_req_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47753", "url": "https://ubuntu.com/security/CVE-2024-47753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix VP8 stateless decoder smatch warning Fix a smatch static checker warning on vdec_vp8_req_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47754", "url": "https://ubuntu.com/security/CVE-2024-47754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix H264 multi stateless decoder smatch warning Fix a smatch static checker warning on vdec_h264_req_multi_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47696", "url": "https://ubuntu.com/security/CVE-2024-47696", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency In the commit aee2424246f9 (\"RDMA/iwcm: Fix a use-after-free related to destroying CM IDs\"), the function flush_workqueue is invoked to flush the work queue iwcm_wq. But at that time, the work queue iwcm_wq was created via the function alloc_ordered_workqueue without the flag WQ_MEM_RECLAIM. Because the current process is trying to flush the whole iwcm_wq, if iwcm_wq doesn't have the flag WQ_MEM_RECLAIM, verify that the current process is not reclaiming memory or running on a workqueue which doesn't have the flag WQ_MEM_RECLAIM as that can break forward-progress guarantee leading to a deadlock. The call trace is as below: [ 125.350876][ T1430] Call Trace: [ 125.356281][ T1430] [ 125.361285][ T1430] ? __warn (kernel/panic.c:693) [ 125.367640][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.375689][ T1430] ? report_bug (lib/bug.c:180 lib/bug.c:219) [ 125.382505][ T1430] ? handle_bug (arch/x86/kernel/traps.c:239) [ 125.388987][ T1430] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) [ 125.395831][ T1430] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621) [ 125.403125][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.410984][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.418764][ T1430] __flush_workqueue (kernel/workqueue.c:3970) [ 125.426021][ T1430] ? __pfx___might_resched (kernel/sched/core.c:10151) [ 125.433431][ T1430] ? destroy_cm_id (drivers/infiniband/core/iwcm.c:375) iw_cm [ 125.441209][ T1430] ? __pfx___flush_workqueue (kernel/workqueue.c:3910) [ 125.473900][ T1430] ? _raw_spin_lock_irqsave (arch/x86/include/asm/atomic.h:107 include/linux/atomic/atomic-arch-fallback.h:2170 include/linux/atomic/atomic-instrumented.h:1302 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162) [ 125.473909][ T1430] ? __pfx__raw_spin_lock_irqsave (kernel/locking/spinlock.c:161) [ 125.482537][ T1430] _destroy_id (drivers/infiniband/core/cma.c:2044) rdma_cm [ 125.495072][ T1430] nvme_rdma_free_queue (drivers/nvme/host/rdma.c:656 drivers/nvme/host/rdma.c:650) nvme_rdma [ 125.505827][ T1430] nvme_rdma_reset_ctrl_work (drivers/nvme/host/rdma.c:2180) nvme_rdma [ 125.505831][ T1430] process_one_work (kernel/workqueue.c:3231) [ 125.515122][ T1430] worker_thread (kernel/workqueue.c:3306 kernel/workqueue.c:3393) [ 125.515127][ T1430] ? __pfx_worker_thread (kernel/workqueue.c:3339) [ 125.531837][ T1430] kthread (kernel/kthread.c:389) [ 125.539864][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.550628][ T1430] ret_from_fork (arch/x86/kernel/process.c:147) [ 125.558840][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.558844][ T1430] ret_from_fork_asm (arch/x86/entry/entry_64.S:257) [ 125.566487][ T1430] [ 125.566488][ T1430] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47755", "url": "https://ubuntu.com/security/CVE-2024-47755", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47756", "url": "https://ubuntu.com/security/CVE-2024-47756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: keystone: Fix if-statement expression in ks_pcie_quirk() This code accidentally uses && where || was intended. It potentially results in a NULL dereference. Thus, fix the if-statement expression to use the correct condition. [kwilczynski: commit log]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47697", "url": "https://ubuntu.com/security/CVE-2024-47697", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error Ensure index in rtl2830_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47698", "url": "https://ubuntu.com/security/CVE-2024-47698", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error Ensure index in rtl2832_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue. [hverkuil: added fixes tag, rtl2830_pid_filter -> rtl2832_pid_filter in logmsg]", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47728", "url": "https://ubuntu.com/security/CVE-2024-47728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error For all non-tracing helpers which formerly had ARG_PTR_TO_{LONG,INT} as input arguments, zero the value for the case of an error as otherwise it could leak memory. For tracing, it is not needed given CAP_PERFMON can already read all kernel memory anyway hence bpf_get_func_arg() and bpf_get_func_ret() is skipped in here. Also, the MTU helpers mtu_len pointer value is being written but also read. Technically, the MEM_UNINIT should not be there in order to always force init. Removing MEM_UNINIT needs more verifier rework though: MEM_UNINIT right now implies two things actually: i) write into memory, ii) memory does not have to be initialized. If we lift MEM_UNINIT, it then becomes: i) read into memory, ii) memory must be initialized. This means that for bpf_*_check_mtu() we're readding the issue we're trying to fix, that is, it would then be able to write back into things like .rodata BPF maps. Follow-up work will rework the MEM_UNINIT semantics such that the intent can be better expressed. For now just clear the *mtu_len on error path which can be lifted later again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49861", "url": "https://ubuntu.com/security/CVE-2024-49861", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix helper writes to read-only maps Lonial found an issue that despite user- and BPF-side frozen BPF map (like in case of .rodata), it was still possible to write into it from a BPF program side through specific helpers having ARG_PTR_TO_{LONG,INT} as arguments. In check_func_arg() when the argument is as mentioned, the meta->raw_mode is never set. Later, check_helper_mem_access(), under the case of PTR_TO_MAP_VALUE as register base type, it assumes BPF_READ for the subsequent call to check_map_access_type() and given the BPF map is read-only it succeeds. The helpers really need to be annotated as ARG_PTR_TO_{LONG,INT} | MEM_UNINIT when results are written into them as opposed to read out of them. The latter indicates that it's okay to pass a pointer to uninitialized memory as the memory is written to anyway. However, ARG_PTR_TO_{LONG,INT} is a special case of ARG_PTR_TO_FIXED_SIZE_MEM just with additional alignment requirement. So it is better to just get rid of the ARG_PTR_TO_{LONG,INT} special cases altogether and reuse the fixed size memory types. For this, add MEM_ALIGNED to additionally ensure alignment given these helpers write directly into the args via * = val. The .arg*_size has been initialized reflecting the actual sizeof(*). MEM_ALIGNED can only be used in combination with MEM_FIXED_SIZE annotated argument types, since in !MEM_FIXED_SIZE cases the verifier does not know the buffer size a priori and therefore cannot blindly write * = val.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47757", "url": "https://ubuntu.com/security/CVE-2024-47757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential oob read in nilfs_btree_check_delete() The function nilfs_btree_check_delete(), which checks whether degeneration to direct mapping occurs before deleting a b-tree entry, causes memory access outside the block buffer when retrieving the maximum key if the root node has no entries. This does not usually happen because b-tree mappings with 0 child nodes are never created by mkfs.nilfs2 or nilfs2 itself. However, it can happen if the b-tree root node read from a device is configured that way, so fix this potential issue by adding a check for that case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47699", "url": "https://ubuntu.com/security/CVE-2024-47699", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential null-ptr-deref in nilfs_btree_insert() Patch series \"nilfs2: fix potential issues with empty b-tree nodes\". This series addresses three potential issues with empty b-tree nodes that can occur with corrupted filesystem images, including one recently discovered by syzbot. This patch (of 3): If a b-tree is broken on the device, and the b-tree height is greater than 2 (the level of the root node is greater than 1) even if the number of child nodes of the b-tree root is 0, a NULL pointer dereference occurs in nilfs_btree_prepare_insert(), which is called from nilfs_btree_insert(). This is because, when the number of child nodes of the b-tree root is 0, nilfs_btree_do_lookup() does not set the block buffer head in any of path[x].bp_bh, leaving it as the initial value of NULL, but if the level of the b-tree root node is greater than 1, nilfs_btree_get_nonroot_node(), which accesses the buffer memory of path[x].bp_bh, is called. Fix this issue by adding a check to nilfs_btree_root_broken(), which performs sanity checks when reading the root node from the device, to detect this inconsistency. Thanks to Lizhi Xu for trying to solve the bug and clarifying the cause early on.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47700", "url": "https://ubuntu.com/security/CVE-2024-47700", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: check stripe size compatibility on remount as well We disable stripe size in __ext4_fill_super if it is not a multiple of the cluster ratio however this check is missed when trying to remount. This can leave us with cases where stripe < cluster_ratio after remount:set making EXT4_B2C(sbi->s_stripe) become 0 that can cause some unforeseen bugs like divide by 0. Fix that by adding the check in remount path as well.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47701", "url": "https://ubuntu.com/security/CVE-2024-47701", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid OOB when system.data xattr changes underneath the filesystem When looking up for an entry in an inlined directory, if e_value_offs is changed underneath the filesystem by some change in the block device, it will lead to an out-of-bounds access that KASAN detects as an UAF. EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none. loop0: detected capacity change from 2048 to 2047 ================================================================== BUG: KASAN: use-after-free in ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 Read of size 1 at addr ffff88803e91130f by task syz-executor269/5103 CPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 Not tainted 6.11.0-rc4-syzkaller #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:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 ext4_find_inline_entry+0x4be/0x5e0 fs/ext4/inline.c:1697 __ext4_find_entry+0x2b4/0x1b30 fs/ext4/namei.c:1573 ext4_lookup_entry fs/ext4/namei.c:1727 [inline] ext4_lookup+0x15f/0x750 fs/ext4/namei.c:1795 lookup_one_qstr_excl+0x11f/0x260 fs/namei.c:1633 filename_create+0x297/0x540 fs/namei.c:3980 do_symlinkat+0xf9/0x3a0 fs/namei.c:4587 __do_sys_symlinkat fs/namei.c:4610 [inline] __se_sys_symlinkat fs/namei.c:4607 [inline] __x64_sys_symlinkat+0x95/0xb0 fs/namei.c:4607 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:0x7f3e73ced469 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff4d40c258 EFLAGS: 00000246 ORIG_RAX: 000000000000010a RAX: ffffffffffffffda RBX: 0032656c69662f2e RCX: 00007f3e73ced469 RDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0 RBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290 R10: 0023706f6f6c2f76 R11: 0000000000000246 R12: 00007fff4d40c27c R13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0 Calling ext4_xattr_ibody_find right after reading the inode with ext4_get_inode_loc will lead to a check of the validity of the xattrs, avoiding this problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49850", "url": "https://ubuntu.com/security/CVE-2024-49850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: correctly handle malformed BPF_CORE_TYPE_ID_LOCAL relos In case of malformed relocation record of kind BPF_CORE_TYPE_ID_LOCAL referencing a non-existing BTF type, function bpf_core_calc_relo_insn would cause a null pointer deference. Fix this by adding a proper check upper in call stack, as malformed relocation records could be passed from user space. Simplest reproducer is a program: r0 = 0 exit With a single relocation record: .insn_off = 0, /* patch first instruction */ .type_id = 100500, /* this type id does not exist */ .access_str_off = 6, /* offset of string \"0\" */ .kind = BPF_CORE_TYPE_ID_LOCAL, See the link for original reproducer or next commit for a test case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47702", "url": "https://ubuntu.com/security/CVE-2024-47702", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fail verification for sign-extension of packet data/data_end/data_meta syzbot reported a kernel crash due to commit 1f1e864b6555 (\"bpf: Handle sign-extenstin ctx member accesses\"). The reason is due to sign-extension of 32-bit load for packet data/data_end/data_meta uapi field. The original code looks like: r2 = *(s32 *)(r1 + 76) /* load __sk_buff->data */ r3 = *(u32 *)(r1 + 80) /* load __sk_buff->data_end */ r0 = r2 r0 += 8 if r3 > r0 goto +1 ... Note that __sk_buff->data load has 32-bit sign extension. After verification and convert_ctx_accesses(), the final asm code looks like: r2 = *(u64 *)(r1 +208) r2 = (s32)r2 r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 ... Note that 'r2 = (s32)r2' may make the kernel __sk_buff->data address invalid which may cause runtime failure. Currently, in C code, typically we have void *data = (void *)(long)skb->data; void *data_end = (void *)(long)skb->data_end; ... and it will generate r2 = *(u64 *)(r1 +208) r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 If we allow sign-extension, void *data = (void *)(long)(int)skb->data; void *data_end = (void *)(long)skb->data_end; ... the generated code looks like r2 = *(u64 *)(r1 +208) r2 <<= 32 r2 s>>= 32 r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 and this will cause verification failure since \"r2 <<= 32\" is not allowed as \"r2\" is a packet pointer. To fix this issue for case r2 = *(s32 *)(r1 + 76) /* load __sk_buff->data */ this patch added additional checking in is_valid_access() callback function for packet data/data_end/data_meta access. If those accesses are with sign-extenstion, the verification will fail. [1] https://lore.kernel.org/bpf/000000000000c90eee061d236d37@google.com/", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47703", "url": "https://ubuntu.com/security/CVE-2024-47703", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, lsm: Add check for BPF LSM return value A bpf prog returning a positive number attached to file_alloc_security hook makes kernel panic. This happens because file system can not filter out the positive number returned by the LSM prog using IS_ERR, and misinterprets this positive number as a file pointer. Given that hook file_alloc_security never returned positive number before the introduction of BPF LSM, and other BPF LSM hooks may encounter similar issues, this patch adds LSM return value check in verifier, to ensure no unexpected value is returned.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49851", "url": "https://ubuntu.com/security/CVE-2024-49851", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: Clean up TPM space after command failure tpm_dev_transmit prepares the TPM space before attempting command transmission. However if the command fails no rollback of this preparation is done. This can result in transient handles being leaked if the device is subsequently closed with no further commands performed. Fix this by flushing the space in the event of command transmission failure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47723", "url": "https://ubuntu.com/security/CVE-2024-47723", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: fix out-of-bounds in dbNextAG() and diAlloc() In dbNextAG() , there is no check for the case where bmp->db_numag is greater or same than MAXAG due to a polluted image, which causes an out-of-bounds. Therefore, a bounds check should be added in dbMount(). And in dbNextAG(), a check for the case where agpref is greater than bmp->db_numag should be added, so an out-of-bounds exception should be prevented. Additionally, a check for the case where agno is greater or same than MAXAG should be added in diAlloc() to prevent out-of-bounds.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49852", "url": "https://ubuntu.com/security/CVE-2024-49852", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: elx: libefc: Fix potential use after free in efc_nport_vport_del() The kref_put() function will call nport->release if the refcount drops to zero. The nport->release release function is _efc_nport_free() which frees \"nport\". But then we dereference \"nport\" on the next line which is a use after free. Re-order these lines to avoid the use after free.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47720", "url": "https://ubuntu.com/security/CVE-2024-47720", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for set_output_gamma in dcn30_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn30_set_output_transfer_func function. Previously, set_output_gamma was being checked for nullity at line 386, but then it was being dereferenced without any nullity check at line 401. This could potentially lead to a null pointer dereference error if set_output_gamma is indeed null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a nullity check for set_output_gamma before the call to set_output_gamma at line 401. If set_output_gamma is null, we log an error message and do not call the function. This fix prevents a potential null pointer dereference error. drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:401 dcn30_set_output_transfer_func() error: we previously assumed 'mpc->funcs->set_output_gamma' could be null (see line 386) drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c 373 bool dcn30_set_output_transfer_func(struct dc *dc, 374 struct pipe_ctx *pipe_ctx, 375 const struct dc_stream_state *stream) 376 { 377 int mpcc_id = pipe_ctx->plane_res.hubp->inst; 378 struct mpc *mpc = pipe_ctx->stream_res.opp->ctx->dc->res_pool->mpc; 379 const struct pwl_params *params = NULL; 380 bool ret = false; 381 382 /* program OGAM or 3DLUT only for the top pipe*/ 383 if (pipe_ctx->top_pipe == NULL) { 384 /*program rmu shaper and 3dlut in MPC*/ 385 ret = dcn30_set_mpc_shaper_3dlut(pipe_ctx, stream); 386 if (ret == false && mpc->funcs->set_output_gamma) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If this is NULL 387 if (stream->out_transfer_func.type == TF_TYPE_HWPWL) 388 params = &stream->out_transfer_func.pwl; 389 else if (pipe_ctx->stream->out_transfer_func.type == 390 TF_TYPE_DISTRIBUTED_POINTS && 391 cm3_helper_translate_curve_to_hw_format( 392 &stream->out_transfer_func, 393 &mpc->blender_params, false)) 394 params = &mpc->blender_params; 395 /* there are no ROM LUTs in OUTGAM */ 396 if (stream->out_transfer_func.type == TF_TYPE_PREDEFINED) 397 BREAK_TO_DEBUGGER(); 398 } 399 } 400 --> 401 mpc->funcs->set_output_gamma(mpc, mpcc_id, params); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Then it will crash 402 return ret; 403 }", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47704", "url": "https://ubuntu.com/security/CVE-2024-47704", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check link_res->hpo_dp_link_enc before using it [WHAT & HOW] Functions dp_enable_link_phy and dp_disable_link_phy can pass link_res without initializing hpo_dp_link_enc and it is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49853", "url": "https://ubuntu.com/security/CVE-2024-49853", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix double free in OPTEE transport Channels can be shared between protocols, avoid freeing the same channel descriptors twice when unloading the stack.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47705", "url": "https://ubuntu.com/security/CVE-2024-47705", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix potential invalid pointer dereference in blk_add_partition The blk_add_partition() function initially used a single if-condition (IS_ERR(part)) to check for errors when adding a partition. This was modified to handle the specific case of -ENXIO separately, allowing the function to proceed without logging the error in this case. However, this change unintentionally left a path where md_autodetect_dev() could be called without confirming that part is a valid pointer. This commit separates the error handling logic by splitting the initial if-condition, improving code readability and handling specific error scenarios explicitly. The function now distinguishes the general error case from -ENXIO without altering the existing behavior of md_autodetect_dev() calls.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47736", "url": "https://ubuntu.com/security/CVE-2024-47736", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: handle overlapped pclusters out of crafted images properly syzbot reported a task hang issue due to a deadlock case where it is waiting for the folio lock of a cached folio that will be used for cache I/Os. After looking into the crafted fuzzed image, I found it's formed with several overlapped big pclusters as below: Ext: logical offset | length : physical offset | length 0: 0.. 16384 | 16384 : 151552.. 167936 | 16384 1: 16384.. 32768 | 16384 : 155648.. 172032 | 16384 2: 32768.. 49152 | 16384 : 537223168.. 537239552 | 16384 ... Here, extent 0/1 are physically overlapped although it's entirely _impossible_ for normal filesystem images generated by mkfs. First, managed folios containing compressed data will be marked as up-to-date and then unlocked immediately (unlike in-place folios) when compressed I/Os are complete. If physical blocks are not submitted in the incremental order, there should be separate BIOs to avoid dependency issues. However, the current code mis-arranges z_erofs_fill_bio_vec() and BIO submission which causes unexpected BIO waits. Second, managed folios will be connected to their own pclusters for efficient inter-queries. However, this is somewhat hard to implement easily if overlapped big pclusters exist. Again, these only appear in fuzzed images so let's simply fall back to temporary short-lived pages for correctness. Additionally, it justifies that referenced managed folios cannot be truncated for now and reverts part of commit 2080ca1ed3e4 (\"erofs: tidy up `struct z_erofs_bvec`\") for simplicity although it shouldn't be any difference.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47706", "url": "https://ubuntu.com/security/CVE-2024-47706", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block, bfq: fix possible UAF for bfqq->bic with merge chain 1) initial state, three tasks: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t\t | ? | ?\t\t | ? \t\t | | | |\t\t | | \t\t V | V |\t\t V | \t\t bfqq1 bfqq2\t\t bfqq3 process ref:\t 1\t\t 1\t\t 1 2) bfqq1 merged to bfqq2: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t\t | |\t\t | ? \t\t \\--------------\\|\t\t | | \t\t V\t\t V | \t\t bfqq1--------->bfqq2\t\t bfqq3 process ref:\t 0\t\t 2\t\t 1 3) bfqq2 merged to bfqq3: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t here -> ? |\t\t | \t\t \\--------------\\ \\-------------\\| \t\t V\t\t V \t\t bfqq1--------->bfqq2---------->bfqq3 process ref:\t 0\t\t 1\t\t 3 In this case, IO from Process 1 will get bfqq2 from BIC1 first, and then get bfqq3 through merge chain, and finially handle IO by bfqq3. Howerver, current code will think bfqq2 is owned by BIC1, like initial state, and set bfqq2->bic to BIC1. bfq_insert_request -> by Process 1 bfqq = bfq_init_rq(rq) bfqq = bfq_get_bfqq_handle_split bfqq = bic_to_bfqq -> get bfqq2 from BIC1 bfqq->ref++ rq->elv.priv[0] = bic rq->elv.priv[1] = bfqq if (bfqq_process_refs(bfqq) == 1) bfqq->bic = bic -> record BIC1 to bfqq2 __bfq_insert_request new_bfqq = bfq_setup_cooperator -> get bfqq3 from bfqq2->new_bfqq bfqq_request_freed(bfqq) new_bfqq->ref++ rq->elv.priv[1] = new_bfqq -> handle IO by bfqq3 Fix the problem by checking bfqq is from merge chain fist. And this might fix a following problem reported by our syzkaller(unreproducible): ================================================================== BUG: KASAN: slab-use-after-free in bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] BUG: KASAN: slab-use-after-free in bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] BUG: KASAN: slab-use-after-free in bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 Write of size 1 at addr ffff888123839eb8 by task kworker/0:1H/18595 CPU: 0 PID: 18595 Comm: kworker/0:1H Tainted: G L 6.6.0-07439-gba2303cacfda #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Workqueue: kblockd blk_mq_requeue_work Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [inline] print_report+0x10d/0x610 mm/kasan/report.c:475 kasan_report+0x8e/0xc0 mm/kasan/report.c:588 bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 bfq_get_bfqq_handle_split+0x169/0x5d0 block/bfq-iosched.c:6757 bfq_init_rq block/bfq-iosched.c:6876 [inline] bfq_insert_request block/bfq-iosched.c:6254 [inline] bfq_insert_requests+0x1112/0x5cf0 block/bfq-iosched.c:6304 blk_mq_insert_request+0x290/0x8d0 block/blk-mq.c:2593 blk_mq_requeue_work+0x6bc/0xa70 block/blk-mq.c:1502 process_one_work kernel/workqueue.c:2627 [inline] process_scheduled_works+0x432/0x13f0 kernel/workqueue.c:2700 worker_thread+0x6f2/0x1160 kernel/workqueue.c:2781 kthread+0x33c/0x440 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:305 Allocated by task 20776: kasan_save_stack+0x20/0x40 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 __kasan_slab_alloc+0x87/0x90 mm/kasan/common.c:328 kasan_slab_alloc include/linux/kasan.h:188 [inline] slab_post_alloc_hook mm/slab.h:763 [inline] slab_alloc_node mm/slub.c:3458 [inline] kmem_cache_alloc_node+0x1a4/0x6f0 mm/slub.c:3503 ioc_create_icq block/blk-ioc.c:370 [inline] ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49855", "url": "https://ubuntu.com/security/CVE-2024-49855", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: fix race between timeout and normal completion If request timetout is handled by nbd_requeue_cmd(), normal completion has to be stopped for avoiding to complete this requeued request, other use-after-free can be triggered. Fix the race by clearing NBD_CMD_INFLIGHT in nbd_requeue_cmd(), meantime make sure that cmd->lock is grabbed for clearing the flag and the requeue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47707", "url": "https://ubuntu.com/security/CVE-2024-47707", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev() Blamed commit accidentally removed a check for rt->rt6i_idev being NULL, as spotted by syzbot: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 UID: 0 PID: 10998 Comm: syz-executor Not tainted 6.11.0-rc6-syzkaller-00208-g625403177711 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 RBP: ffffc900047375d0 R08: 0000000000000003 R09: fffff520008e6e8c R10: dffffc0000000000 R11: fffff520008e6e8c R12: 1ffff1100fdf8f18 R13: ffff88807efc7998 R14: 0000000000000000 R15: ffff88807efc7930 FS: 0000000000000000(0000) GS:ffff8880b8900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020002a80 CR3: 0000000022f62000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: addrconf_ifdown+0x15d/0x1bd0 net/ipv6/addrconf.c:3856 addrconf_notify+0x3cb/0x1020 notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93 call_netdevice_notifiers_extack net/core/dev.c:2032 [inline] call_netdevice_notifiers net/core/dev.c:2046 [inline] unregister_netdevice_many_notify+0xd81/0x1c40 net/core/dev.c:11352 unregister_netdevice_many net/core/dev.c:11414 [inline] unregister_netdevice_queue+0x303/0x370 net/core/dev.c:11289 unregister_netdevice include/linux/netdevice.h:3129 [inline] __tun_detach+0x6b9/0x1600 drivers/net/tun.c:685 tun_detach drivers/net/tun.c:701 [inline] tun_chr_close+0x108/0x1b0 drivers/net/tun.c:3510 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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:0x7f1acc77def9 Code: Unable to access opcode bytes at 0x7f1acc77decf. RSP: 002b:00007ffeb26fa738 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1acc77def9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000043 RBP: 00007f1acc7dd508 R08: 00007ffeb26f84d7 R09: 0000000000000003 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 0000000000000003 R14: 00000000ffffffff R15: 00007ffeb26fa8e0 Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 R ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47708", "url": "https://ubuntu.com/security/CVE-2024-47708", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netkit: Assign missing bpf_net_context During the introduction of struct bpf_net_context handling for XDP-redirect, the netkit driver has been missed, which also requires it because NETKIT_REDIRECT invokes skb_do_redirect() which is accessing the per-CPU variables. Otherwise we see the following crash: \tBUG: kernel NULL pointer dereference, address: 0000000000000038 \tbpf_redirect() \tnetkit_xmit() \tdev_hard_start_xmit() Set the bpf_net_context before invoking netkit_xmit() program within the netkit driver.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47709", "url": "https://ubuntu.com/security/CVE-2024-47709", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: Clear bo->bcm_proc_read after remove_proc_entry(). syzbot reported a warning in bcm_release(). [0] The blamed change fixed another warning that is triggered when connect() is issued again for a socket whose connect()ed device has been unregistered. However, if the socket is just close()d without the 2nd connect(), the remaining bo->bcm_proc_read triggers unnecessary remove_proc_entry() in bcm_release(). Let's clear bo->bcm_proc_read after remove_proc_entry() in bcm_notify(). [0] name '4986' WARNING: CPU: 0 PID: 5234 at fs/proc/generic.c:711 remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Modules linked in: CPU: 0 UID: 0 PID: 5234 Comm: syz-executor606 Not tainted 6.11.0-rc5-syzkaller-00178-g5517ae241919 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Code: ff eb 05 e8 cb 1e 5e ff 48 8b 5c 24 10 48 c7 c7 e0 f7 aa 8e e8 2a 38 8e 09 90 48 c7 c7 60 3a 1b 8c 48 89 de e8 da 42 20 ff 90 <0f> 0b 90 90 48 8b 44 24 18 48 c7 44 24 40 0e 36 e0 45 49 c7 04 07 RSP: 0018:ffffc9000345fa20 EFLAGS: 00010246 RAX: 2a2d0aee2eb64600 RBX: ffff888032f1f548 RCX: ffff888029431e00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000345fb08 R08: ffffffff8155b2f2 R09: 1ffff1101710519a R10: dffffc0000000000 R11: ffffed101710519b R12: ffff888011d38640 R13: 0000000000000004 R14: 0000000000000000 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8880b8800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcfb52722f0 CR3: 000000000e734000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: bcm_release+0x250/0x880 net/can/bcm.c:1578 __sock_release net/socket.c:659 [inline] sock_close+0xbc/0x240 net/socket.c:1421 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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:0x7fcfb51ee969 Code: Unable to access opcode bytes at 0x7fcfb51ee93f. RSP: 002b:00007ffce0109ca8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fcfb51ee969 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 00007fcfb526f3b0 R08: ffffffffffffffb8 R09: 0000555500000000 R10: 0000555500000000 R11: 0000000000000246 R12: 00007fcfb526f3b0 R13: 0000000000000000 R14: 00007fcfb5271ee0 R15: 00007fcfb51bf160 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47710", "url": "https://ubuntu.com/security/CVE-2024-47710", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sock_map: Add a cond_resched() in sock_hash_free() Several syzbot soft lockup reports all have in common sock_hash_free() If a map with a large number of buckets is destroyed, we need to yield the cpu when needed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47711", "url": "https://ubuntu.com/security/CVE-2024-47711", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Don't return OOB skb in manage_oob(). syzbot reported use-after-free in unix_stream_recv_urg(). [0] The scenario is 1. send(MSG_OOB) 2. recv(MSG_OOB) -> The consumed OOB remains in recv queue 3. send(MSG_OOB) 4. recv() -> manage_oob() returns the next skb of the consumed OOB -> This is also OOB, but unix_sk(sk)->oob_skb is not cleared 5. recv(MSG_OOB) -> unix_sk(sk)->oob_skb is used but already freed The recent commit 8594d9b85c07 (\"af_unix: Don't call skb_get() for OOB skb.\") uncovered the issue. If the OOB skb is consumed and the next skb is peeked in manage_oob(), we still need to check if the skb is OOB. Let's do so by falling back to the following checks in manage_oob() and add the test case in selftest. Note that we need to add a similar check for SIOCATMARK. [0]: BUG: KASAN: slab-use-after-free in unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959 Read of size 4 at addr ffff8880326abcc4 by task syz-executor178/5235 CPU: 0 UID: 0 PID: 5235 Comm: syz-executor178 Not tainted 6.11.0-rc5-syzkaller-00742-gfbdaffe41adc #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959 unix_stream_recv_urg+0x1df/0x320 net/unix/af_unix.c:2640 unix_stream_read_generic+0x2456/0x2520 net/unix/af_unix.c:2778 unix_stream_recvmsg+0x22b/0x2c0 net/unix/af_unix.c:2996 sock_recvmsg_nosec net/socket.c:1046 [inline] sock_recvmsg+0x22f/0x280 net/socket.c:1068 ____sys_recvmsg+0x1db/0x470 net/socket.c:2816 ___sys_recvmsg net/socket.c:2858 [inline] __sys_recvmsg+0x2f0/0x3e0 net/socket.c:2888 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:0x7f5360d6b4e9 Code: 48 83 c4 28 c3 e8 37 17 00 00 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff29b3a458 EFLAGS: 00000246 ORIG_RAX: 000000000000002f RAX: ffffffffffffffda RBX: 00007fff29b3a638 RCX: 00007f5360d6b4e9 RDX: 0000000000002001 RSI: 0000000020000640 RDI: 0000000000000003 RBP: 00007f5360dde610 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 00007fff29b3a628 R14: 0000000000000001 R15: 0000000000000001 Allocated by task 5235: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:312 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slub.c:3988 [inline] slab_alloc_node mm/slub.c:4037 [inline] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4080 __alloc_skb+0x1c3/0x440 net/core/skbuff.c:667 alloc_skb include/linux/skbuff.h:1320 [inline] alloc_skb_with_frags+0xc3/0x770 net/core/skbuff.c:6528 sock_alloc_send_pskb+0x91a/0xa60 net/core/sock.c:2815 sock_alloc_send_skb include/net/sock.h:1778 [inline] queue_oob+0x108/0x680 net/unix/af_unix.c:2198 unix_stream_sendmsg+0xd24/0xf80 net/unix/af_unix.c:2351 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2680 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 Freed by task 5235: kasan_save_stack mm/kasan/common.c:47 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47712", "url": "https://ubuntu.com/security/CVE-2024-47712", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: fix potential RCU dereference issue in wilc_parse_join_bss_param In the `wilc_parse_join_bss_param` function, the TSF field of the `ies` structure is accessed after the RCU read-side critical section is unlocked. According to RCU usage rules, this is illegal. Reusing this pointer can lead to unpredictable behavior, including accessing memory that has been updated or causing use-after-free issues. This possible bug was identified using a static analysis tool developed by myself, specifically designed to detect RCU-related issues. To address this, the TSF value is now stored in a local variable `ies_tsf` before the RCU lock is released. The `param->tsf_lo` field is then assigned using this local variable, ensuring that the TSF value is safely accessed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47713", "url": "https://ubuntu.com/security/CVE-2024-47713", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop() Since '__dev_queue_xmit()' should be called with interrupts enabled, the following backtrace: ieee80211_do_stop() ... spin_lock_irqsave(&local->queue_stop_reason_lock, flags) ... ieee80211_free_txskb() ieee80211_report_used_skb() ieee80211_report_ack_skb() cfg80211_mgmt_tx_status_ext() nl80211_frame_tx_status() genlmsg_multicast_netns() genlmsg_multicast_netns_filtered() nlmsg_multicast_filtered() \t netlink_broadcast_filtered() \t do_one_broadcast() \t netlink_broadcast_deliver() \t __netlink_sendskb() \t netlink_deliver_tap() \t __netlink_deliver_tap_skb() \t dev_queue_xmit() \t __dev_queue_xmit() ; with IRQS disabled ... spin_unlock_irqrestore(&local->queue_stop_reason_lock, flags) issues the warning (as reported by syzbot reproducer): WARNING: CPU: 2 PID: 5128 at kernel/softirq.c:362 __local_bh_enable_ip+0xc3/0x120 Fix this by implementing a two-phase skb reclamation in 'ieee80211_do_stop()', where actual work is performed outside of a section with interrupts disabled.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47730", "url": "https://ubuntu.com/security/CVE-2024-47730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/qm - inject error before stopping queue The master ooo cannot be completely closed when the accelerator core reports memory error. Therefore, the driver needs to inject the qm error to close the master ooo. Currently, the qm error is injected after stopping queue, memory may be released immediately after stopping queue, causing the device to access the released memory. Therefore, error is injected to close master ooo before stopping queue to ensure that the device does not access the released memory.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49856", "url": "https://ubuntu.com/security/CVE-2024-49856", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/sgx: Fix deadlock in SGX NUMA node search When the current node doesn't have an EPC section configured by firmware and all other EPC sections are used up, CPU can get stuck inside the while loop that looks for an available EPC page from remote nodes indefinitely, leading to a soft lockup. Note how nid_of_current will never be equal to nid in that while loop because nid_of_current is not set in sgx_numa_mask. Also worth mentioning is that it's perfectly fine for the firmware not to setup an EPC section on a node. While setting up an EPC section on each node can enhance performance, it is not a requirement for functionality. Rework the loop to start and end on *a* node that has SGX memory. This avoids the deadlock looking for the current SGX-lacking node to show up in the loop when it never will.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47714", "url": "https://ubuntu.com/security/CVE-2024-47714", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: use hweight16 to get correct tx antenna The chainmask is u16 so using hweight8 cannot get correct tx_ant. Without this patch, the tx_ant of band 2 would be -1 and lead to the following issue: BUG: KASAN: stack-out-of-bounds in mt7996_mcu_add_sta+0x12e0/0x16e0 [mt7996e]", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47715", "url": "https://ubuntu.com/security/CVE-2024-47715", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: fix oops on non-dbdc mt7986 mt7915_band_config() sets band_idx = 1 on the main phy for mt7986 with MT7975_ONE_ADIE or MT7976_ONE_ADIE. Commit 0335c034e726 (\"wifi: mt76: fix race condition related to checking tx queue fill status\") introduced a dereference of the phys array indirectly indexed by band_idx via wcid->phy_idx in mt76_wcid_cleanup(). This caused the following Oops on affected mt7986 devices: Unable to handle kernel read from unreadable memory at virtual address 0000000000000024 Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x00000005 CM = 0, WnR = 0 user pgtable: 4k pages, 39-bit VAs, pgdp=0000000042545000 [0000000000000024] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 Internal error: Oops: 0000000096000005 [#1] SMP Modules linked in: ... mt7915e mt76_connac_lib mt76 mac80211 cfg80211 ... CPU: 2 PID: 1631 Comm: hostapd Not tainted 5.15.150 #0 Hardware name: ZyXEL EX5700 (Telenor) (DT) pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mt76_wcid_cleanup+0x84/0x22c [mt76] lr : mt76_wcid_cleanup+0x64/0x22c [mt76] sp : ffffffc00a803700 x29: ffffffc00a803700 x28: ffffff80008f7300 x27: ffffff80003f3c00 x26: ffffff80000a7880 x25: ffffffc008c26e00 x24: 0000000000000001 x23: ffffffc000a68114 x22: 0000000000000000 x21: ffffff8004172cc8 x20: ffffffc00a803748 x19: ffffff8004152020 x18: 0000000000000000 x17: 00000000000017c0 x16: ffffffc008ef5000 x15: 0000000000000be0 x14: ffffff8004172e28 x13: ffffff8004172e28 x12: 0000000000000000 x11: 0000000000000000 x10: ffffff8004172e30 x9 : ffffff8004172e28 x8 : 0000000000000000 x7 : ffffff8004156020 x6 : 0000000000000000 x5 : 0000000000000031 x4 : 0000000000000000 x3 : 0000000000000001 x2 : 0000000000000000 x1 : ffffff80008f7300 x0 : 0000000000000024 Call trace: mt76_wcid_cleanup+0x84/0x22c [mt76] __mt76_sta_remove+0x70/0xbc [mt76] mt76_sta_state+0x8c/0x1a4 [mt76] mt7915_eeprom_get_power_delta+0x11e4/0x23a0 [mt7915e] drv_sta_state+0x144/0x274 [mac80211] sta_info_move_state+0x1cc/0x2a4 [mac80211] sta_set_sinfo+0xaf8/0xc24 [mac80211] sta_info_destroy_addr_bss+0x4c/0x6c [mac80211] ieee80211_color_change_finish+0x1c08/0x1e70 [mac80211] cfg80211_check_station_change+0x1360/0x4710 [cfg80211] genl_family_rcv_msg_doit+0xb4/0x110 genl_rcv_msg+0xd0/0x1bc netlink_rcv_skb+0x58/0x120 genl_rcv+0x34/0x50 netlink_unicast+0x1f0/0x2ec netlink_sendmsg+0x198/0x3d0 ____sys_sendmsg+0x1b0/0x210 ___sys_sendmsg+0x80/0xf0 __sys_sendmsg+0x44/0xa0 __arm64_sys_sendmsg+0x20/0x30 invoke_syscall.constprop.0+0x4c/0xe0 do_el0_svc+0x40/0xd0 el0_svc+0x14/0x4c el0t_64_sync_handler+0x100/0x110 el0t_64_sync+0x15c/0x160 Code: d2800002 910092c0 52800023 f9800011 (885f7c01) ---[ end trace 7e42dd9a39ed2281 ]--- Fix by using mt76_dev_phy() which will map band_idx to the correct phy for all hardware combinations.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49857", "url": "https://ubuntu.com/security/CVE-2024-49857", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: set the cipher for secured NDP ranging The cipher pointer is not set, but is derefereced trying to set its content, which leads to a NULL pointer dereference. Fix it by pointing to the cipher parameter before dereferencing.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47738", "url": "https://ubuntu.com/security/CVE-2024-47738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: don't use rate mask for offchannel TX either Like the commit ab9177d83c04 (\"wifi: mac80211: don't use rate mask for scanning\"), ignore incorrect settings to avoid no supported rate warning reported by syzbot. The syzbot did bisect and found cause is commit 9df66d5b9f45 (\"cfg80211: fix default HE tx bitrate mask in 2G band\"), which however corrects bitmask of HE MCS and recognizes correctly settings of empty legacy rate plus HE MCS rate instead of returning -EINVAL. As suggestions [1], follow the change of SCAN TX to consider this case of offchannel TX as well. [1] https://lore.kernel.org/linux-wireless/6ab2dc9c3afe753ca6fdcdd1421e7a1f47e87b84.camel@sipsolutions.net/T/#m2ac2a6d2be06a37c9c47a3d8a44b4f647ed4f024", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47731", "url": "https://ubuntu.com/security/CVE-2024-47731", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers/perf: Fix ali_drw_pmu driver interrupt status clearing The alibaba_uncore_pmu driver forgot to clear all interrupt status in the interrupt processing function. After the PMU counter overflow interrupt occurred, an interrupt storm occurred, causing the system to hang. Therefore, clear the correct interrupt status in the interrupt handling function to fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49862", "url": "https://ubuntu.com/security/CVE-2024-49862", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powercap: intel_rapl: Fix off by one in get_rpi() The rp->priv->rpi array is either rpi_msr or rpi_tpmi which have NR_RAPL_PRIMITIVES number of elements. Thus the > needs to be >= to prevent an off by one access.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47716", "url": "https://ubuntu.com/security/CVE-2024-47716", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: 9410/1: vfp: Use asm volatile in fmrx/fmxr macros Floating point instructions in userspace can crash some arm kernels built with clang/LLD 17.0.6: BUG: unsupported FP instruction in kernel mode FPEXC == 0xc0000780 Internal error: Oops - undefined instruction: 0 [#1] ARM CPU: 0 PID: 196 Comm: vfp-reproducer Not tainted 6.10.0 #1 Hardware name: BCM2835 PC is at vfp_support_entry+0xc8/0x2cc LR is at do_undefinstr+0xa8/0x250 pc : [] lr : [] psr: a0000013 sp : dc8d1f68 ip : 60000013 fp : bedea19c r10: ec532b17 r9 : 00000010 r8 : 0044766c r7 : c0000780 r6 : ec532b17 r5 : c1c13800 r4 : dc8d1fb0 r3 : c10072c4 r2 : c0101c88 r1 : ec532b17 r0 : 0044766c Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 00c5387d Table: 0251c008 DAC: 00000051 Register r0 information: non-paged memory Register r1 information: vmalloc memory Register r2 information: non-slab/vmalloc memory Register r3 information: non-slab/vmalloc memory Register r4 information: 2-page vmalloc region Register r5 information: slab kmalloc-cg-2k Register r6 information: vmalloc memory Register r7 information: non-slab/vmalloc memory Register r8 information: non-paged memory Register r9 information: zero-size pointer Register r10 information: vmalloc memory Register r11 information: non-paged memory Register r12 information: non-paged memory Process vfp-reproducer (pid: 196, stack limit = 0x61aaaf8b) Stack: (0xdc8d1f68 to 0xdc8d2000) 1f60: 0000081f b6f69300 0000000f c10073f4 c10072c4 dc8d1fb0 1f80: ec532b17 0c532b17 0044766c b6f9ccd8 00000000 c010a80c 00447670 60000010 1fa0: ffffffff c1c13800 00c5387d c0100f10 b6f68af8 00448fc0 00000000 bedea188 1fc0: bedea314 00000001 00448ebc b6f9d000 00447608 b6f9ccd8 00000000 bedea19c 1fe0: bede9198 bedea188 b6e1061c 0044766c 60000010 ffffffff 00000000 00000000 Call trace: [] (vfp_support_entry) from [] (do_undefinstr+0xa8/0x250) [] (do_undefinstr) from [] (__und_usr+0x70/0x80) Exception stack(0xdc8d1fb0 to 0xdc8d1ff8) 1fa0: b6f68af8 00448fc0 00000000 bedea188 1fc0: bedea314 00000001 00448ebc b6f9d000 00447608 b6f9ccd8 00000000 bedea19c 1fe0: bede9198 bedea188 b6e1061c 0044766c 60000010 ffffffff Code: 0a000061 e3877202 e594003c e3a09010 (eef16a10) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Fatal exception in interrupt ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]--- This is a minimal userspace reproducer on a Raspberry Pi Zero W: #include #include int main(void) { double v = 1.0; printf(\"%fn\", NAN + *(volatile double *)&v); return 0; } Another way to consistently trigger the oops is: calvin@raspberry-pi-zero-w ~$ python -c \"import json\" The bug reproduces only when the kernel is built with DYNAMIC_DEBUG=n, because the pr_debug() calls act as barriers even when not activated. This is the output from the same kernel source built with the same compiler and DYNAMIC_DEBUG=y, where the userspace reproducer works as expected: VFP: bounce: trigger ec532b17 fpexc c0000780 VFP: emulate: INST=0xee377b06 SCR=0x00000000 VFP: bounce: trigger eef1fa10 fpexc c0000780 VFP: emulate: INST=0xeeb40b40 SCR=0x00000000 VFP: raising exceptions 30000000 calvin@raspberry-pi-zero-w ~$ ./vfp-reproducer nan Crudely grepping for vmsr/vmrs instructions in the otherwise nearly idential text for vfp_support_entry() makes the problem obvious: vmlinux.llvm.good [0xc0101cb8] <+48>: vmrs r7, fpexc vmlinux.llvm.good [0xc0101cd8] <+80>: vmsr fpexc, r0 vmlinux.llvm.good [0xc0101d20 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47717", "url": "https://ubuntu.com/security/CVE-2024-47717", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RISC-V: KVM: Don't zero-out PMU snapshot area before freeing data With the latest Linux-6.11-rc3, the below NULL pointer crash is observed when SBI PMU snapshot is enabled for the guest and the guest is forcefully powered-off. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000508 Oops [#1] Modules linked in: kvm CPU: 0 UID: 0 PID: 61 Comm: term-poll Not tainted 6.11.0-rc3-00018-g44d7178dd77a #3 Hardware name: riscv-virtio,qemu (DT) epc : __kvm_write_guest_page+0x94/0xa6 [kvm] ra : __kvm_write_guest_page+0x54/0xa6 [kvm] epc : ffffffff01590e98 ra : ffffffff01590e58 sp : ffff8f80001f39b0 gp : ffffffff81512a60 tp : ffffaf80024872c0 t0 : ffffaf800247e000 t1 : 00000000000007e0 t2 : 0000000000000000 s0 : ffff8f80001f39f0 s1 : 00007fff89ac4000 a0 : ffffffff015dd7e8 a1 : 0000000000000086 a2 : 0000000000000000 a3 : ffffaf8000000000 a4 : ffffaf80024882c0 a5 : 0000000000000000 a6 : ffffaf800328d780 a7 : 00000000000001cc s2 : ffffaf800197bd00 s3 : 00000000000828c4 s4 : ffffaf800248c000 s5 : ffffaf800247d000 s6 : 0000000000001000 s7 : 0000000000001000 s8 : 0000000000000000 s9 : 00007fff861fd500 s10: 0000000000000001 s11: 0000000000800000 t3 : 00000000000004d3 t4 : 00000000000004d3 t5 : ffffffff814126e0 t6 : ffffffff81412700 status: 0000000200000120 badaddr: 0000000000000508 cause: 000000000000000d [] __kvm_write_guest_page+0x94/0xa6 [kvm] [] kvm_vcpu_write_guest+0x56/0x90 [kvm] [] kvm_pmu_clear_snapshot_area+0x42/0x7e [kvm] [] kvm_riscv_vcpu_pmu_deinit.part.0+0xe0/0x14e [kvm] [] kvm_riscv_vcpu_pmu_deinit+0x1a/0x24 [kvm] [] kvm_arch_vcpu_destroy+0x28/0x4c [kvm] [] kvm_destroy_vcpus+0x5a/0xda [kvm] [] kvm_arch_destroy_vm+0x14/0x28 [kvm] [] kvm_destroy_vm+0x168/0x2a0 [kvm] [] kvm_put_kvm+0x3c/0x58 [kvm] [] kvm_vm_release+0x22/0x2e [kvm] Clearly, the kvm_vcpu_write_guest() function is crashing because it is being called from kvm_pmu_clear_snapshot_area() upon guest tear down. To address the above issue, simplify the kvm_pmu_clear_snapshot_area() to not zero-out PMU snapshot area from kvm_pmu_clear_snapshot_area() because the guest is anyway being tore down. The kvm_pmu_clear_snapshot_area() is also called when guest changes PMU snapshot area of a VCPU but even in this case the previous PMU snaphsot area must not be zeroed-out because the guest might have reclaimed the pervious PMU snapshot area for some other purpose.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47721", "url": "https://ubuntu.com/security/CVE-2024-47721", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: remove unused C2H event ID RTW89_MAC_C2H_FUNC_READ_WOW_CAM to prevent out-of-bounds reading The handler of firmware C2H event RTW89_MAC_C2H_FUNC_READ_WOW_CAM isn't implemented, but driver expects number of handlers is NUM_OF_RTW89_MAC_C2H_FUNC_WOW causing out-of-bounds access. Fix it by removing ID. Addresses-Coverity-ID: 1598775 (\"Out-of-bounds read\")", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47732", "url": "https://ubuntu.com/security/CVE-2024-47732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: iaa - Fix potential use after free bug The free_device_compression_mode(iaa_device, device_mode) function frees \"device_mode\" but it iss passed to iaa_compression_modes[i]->free() a few lines later resulting in a use after free. The good news is that, so far as I can tell, nothing implements the ->free() function and the use after free happens in dead code. But, with this fix, when something does implement it, we'll be ready. :)", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47718", "url": "https://ubuntu.com/security/CVE-2024-47718", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: always wait for both firmware loading attempts In 'rtw_wait_firmware_completion()', always wait for both (regular and wowlan) firmware loading attempts. Otherwise if 'rtw_usb_intf_init()' has failed in 'rtw_usb_probe()', 'rtw_usb_disconnect()' may issue 'ieee80211_free_hw()' when one of 'rtw_load_firmware_cb()' (usually the wowlan one) is still in progress, causing UAF detected by KASAN.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47724", "url": "https://ubuntu.com/security/CVE-2024-47724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: use work queue to process beacon tx event Commit 3a415daa3e8b (\"wifi: ath11k: add P2P IE in beacon template\") from Feb 28, 2024 (linux-next), leads to the following Smatch static checker warning: drivers/net/wireless/ath/ath11k/wmi.c:1742 ath11k_wmi_p2p_go_bcn_ie() warn: sleeping in atomic context The reason is that ath11k_bcn_tx_status_event() will directly call might sleep function ath11k_wmi_cmd_send() during RCU read-side critical sections. The call trace is like: ath11k_bcn_tx_status_event() -> rcu_read_lock() -> ath11k_mac_bcn_tx_event() \t-> ath11k_mac_setup_bcn_tmpl() \t…… \t\t-> ath11k_wmi_bcn_tmpl() \t\t\t-> ath11k_wmi_cmd_send() -> rcu_read_unlock() Commit 886433a98425 (\"ath11k: add support for BSS color change\") added the ath11k_mac_bcn_tx_event(), commit 01e782c89108 (\"ath11k: fix warning of RCU usage for ath11k_mac_get_arvif_by_vdev_id()\") added the RCU lock to avoid warning but also introduced this BUG. Use work queue to avoid directly calling ath11k_mac_bcn_tx_event() during RCU critical sections. No need to worry about the deletion of vif because cancel_work_sync() will drop the work if it doesn't start or block vif deletion until the running work is done. 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": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47671", "url": "https://ubuntu.com/security/CVE-2024-47671", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: usbtmc: prevent kernel-usb-infoleak The syzbot reported a kernel-usb-infoleak in usbtmc_write, we need to clear the structure before filling fields.", "cve_priority": "medium", "cve_public_date": "2024-10-09 15:15:00 UTC" }, { "cve": "CVE-2024-46869", "url": "https://ubuntu.com/security/CVE-2024-46869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btintel_pcie: Allocate memory for driver private data Fix driver not allocating memory for struct btintel_data which is used to store internal data.", "cve_priority": "medium", "cve_public_date": "2024-09-30 16:15:00 UTC" }, { "cve": "CVE-2024-53164", "url": "https://ubuntu.com/security/CVE-2024-53164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: fix ordering of qlen adjustment Changes to sch->q.qlen around qdisc_tree_reduce_backlog() need to happen _before_ a call to said function because otherwise it may fail to notify parent qdiscs when the child is about to become empty.", "cve_priority": "medium", "cve_public_date": "2024-12-27 14:15:00 UTC" }, { "cve": "CVE-2024-53103", "url": "https://ubuntu.com/security/CVE-2024-53103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hv_sock: Initializing vsk->trans to NULL to prevent a dangling pointer When hvs is released, there is a possibility that vsk->trans may not be initialized to NULL, which could lead to a dangling pointer. This issue is resolved by initializing vsk->trans to NULL.", "cve_priority": "high", "cve_public_date": "2024-12-02 08:15:00 UTC" } ], "log": [ "", " * oracular/linux: 6.11.0-17.17 -proposed tracker (LP: #2093643)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/2025.01.13)", "", " * When /dev/vmbus/hv_kvp is not present, disable hv-kvp-daemon (LP: #2091744)", " - [Packaging] disable hv-kvp-daemon if needed", "", " * Backport \"netkit: Add option for scrubbing skb meta data\" to 6.8", " (LP: #2091184)", " - netkit: Add option for scrubbing skb meta data", "", " * KVM: Cache CPUID at KVM.ko module init to reduce latency of VM-Enter and VM-", " Exit (LP: #2093146)", " - KVM: x86: Cache CPUID.0xD XSTATE offsets+sizes during module init", "", " * [SRU] add support of QCA BT 0489:e0fc (LP: #2085406)", " - Bluetooth: btusb: add Foxconn 0xe0fc for Qualcomm WCN785x", "", " * oracular: ubuntu_boot lib/dynamic_queue_limits.c:99! (LP: #2089684)", " - virtio_net: correct netdev_tx_reset_queue() invocation point", " - virtio_ring: add a func argument 'recycle_done' to virtqueue_resize()", " - virtio_net: ensure netdev_tx_reset_queue is called on tx ring resize", "", " * Failed to probe for OVTI02C1: chip id mismatch: 560243!=0 (LP: #2090932)", " - SAUCE: ACPI: scan: Update HID for new platform", "", " * Bluetooth[8086:a876] crash with \"hci0: Failed to read MSFT supported", " features (-110)\" (LP: #2085485)", " - Bluetooth: btintel_pcie: Add recovery mechanism", "", " * Poor bluetooth performance on Lenovo X13s (LP: #2089357)", " - SAUCE: Bluetooth: qca: Support downloading board ID specific NVM for WCN6855", "", " * vfio_pci soft lockup on VM start while using PCIe passthrough (LP: #2089306)", " - SAUCE: Revert \"mm: use rwsem assertion macros for mmap_lock\"", " - SAUCE: Revert \"vfio/pci: Insert full vma on mmap'd MMIO fault\"", " - SAUCE: Revert \"vfio/pci: Use unmap_mapping_range()\"", "", " * Oracular update: v6.11.11 upstream stable release (LP: #2091655)", " - wifi: mac80211: Fix setting txpower with emulate_chanctx", " - wifi: cfg80211: Add wiphy_delayed_work_pending()", " - wifi: mac80211: Convert color collision detection to wiphy work", " - wifi: radiotap: Avoid -Wflex-array-member-not-at-end warnings", " - spi: stm32: fix missing device mode capability in stm32mp25", " - ASoC: codecs: rt5640: Always disable IRQs from rt5640_cancel_work()", " - ASoC: Intel: bytcr_rt5640: Add support for non ACPI instantiated codec", " - ASoC: Intel: bytcr_rt5640: Add DMI quirk for Vexia Edu Atla 10 tablet", " - ASoC: Intel: sst: Support LPE0F28 ACPI HID", " - wifi: iwlwifi: mvm: Use the sync timepoint API in suspend", " - wifi: iwlwifi: mvm: SAR table alignment", " - mac80211: fix user-power when emulating chanctx", " - usb: add support for new USB device ID 0x17EF:0x3098 for the r8152 driver", " - usb: typec: use cleanup facility for 'altmodes_node'", " - selftests/watchdog-test: Fix system accidentally reset after watchdog-test", " - ALSA: hda/realtek: Add subwoofer quirk for Infinix ZERO BOOK 13", " - ASoC: codecs: wcd937x: add missing LO Switch control", " - ASoC: codecs: wcd937x: relax the AUX PDM watchdog", " - x86/amd_nb: Fix compile-testing without CONFIG_AMD_NB", " - bpf: fix filed access without lock", " - net: usb: qmi_wwan: add Quectel RG650V", " - soc: qcom: Add check devm_kasprintf() returned value", " - firmware: arm_scmi: Reject clear channel request on A2P", " - regulator: rk808: Add apply_bit for BUCK3 on RK809", " - platform/x86: dell-smbios-base: Extends support to Alienware products", " - platform/x86: dell-wmi-base: Handle META key Lock/Unlock events", " - platform/x86: ideapad-laptop: add missing Ideapad Pro 5 fn keys", " - ASoC: tas2781: Add new driver version for tas2563 & tas2781 qfn chip", " - tools/lib/thermal: Remove the thermal.h soft link when doing make clean", " - can: j1939: fix error in J1939 documentation.", " - platform/x86: thinkpad_acpi: Fix for ThinkPad's with ECFW showing incorrect", " fan speed", " - ASoC: amd: yc: Support dmic on another model of Lenovo Thinkpad E14 Gen 6", " - ASoC: stm: Prevent potential division by zero in stm32_sai_mclk_round_rate()", " - ASoC: stm: Prevent potential division by zero in stm32_sai_get_clk_div()", " - drm: panel-orientation-quirks: Make Lenovo Yoga Tab 3 X90F DMI match less", " strict", " - proc/softirqs: replace seq_printf with seq_put_decimal_ull_width", " - integrity: Use static_assert() to check struct sizes", " - ASoC: audio-graph-card2: Purge absent supplies for device tree nodes", " - LoongArch: For all possible CPUs setup logical-physical CPU mapping", " - LoongArch: Define a default value for VM_DATA_DEFAULT_FLAGS", " - ASoC: max9768: Fix event generation for playback mute", " - ALSA: usb-audio: Fix Yamaha P-125 Quirk Entry", " - ARM: 9420/1: smp: Fix SMP for xip kernels", " - ARM: 9434/1: cfi: Fix compilation corner case", " - ipmr: Fix access to mfc_cache_list without lock held", " - f2fs: fix fiemap failure issue when page size is 16KB", " - drm/amd/display: Skip Invalid Streams from DSC Policy", " - drm/amd/display: Fix incorrect DSC recompute trigger", " - s390/facilities: Fix warning about shadow of global variable", " - efs: fix the efs new mount api implementation", " - arm64: probes: Disable kprobes/uprobes on MOPS instructions", " - kselftest/arm64: hwcap: fix f8dp2 cpuinfo name", " - kselftest/arm64: mte: fix printf type warnings about __u64", " - kselftest/arm64: mte: fix printf type warnings about longs", " - block/fs: Pass an iocb to generic_atomic_write_valid()", " - fs/block: Check for IOCB_DIRECT in generic_atomic_write_valid()", " - s390/cio: Do not unregister the subchannel based on DNV", " - s390/pageattr: Implement missing kernel_page_present()", " - x86/pvh: Set phys_base when calling xen_prepare_pvh()", " - x86/pvh: Call C code via the kernel virtual mapping", " - brd: defer automatic disk creation until module initialization succeeds", " - ext4: avoid remount errors with 'abort' mount option", " - mips: asm: fix warning when disabling MIPS_FP_SUPPORT", " - arm64: Expose ID_AA64ISAR1_EL1.XS to sanitised feature consumers", " - kselftest/arm64: Fix encoding for SVE B16B16 test", " - nvme-pci: fix freeing of the HMB descriptor table", " - m68k: mvme147: Fix SCSI controller IRQ numbers", " - m68k: mvme147: Reinstate early console", " - arm64: fix .data.rel.ro size assertion when CONFIG_LTO_CLANG", " - acpi/arm64: Adjust error handling procedure in gtdt_parse_timer_block()", " - loop: fix type of block size", " - cachefiles: Fix incorrect length return value in", " cachefiles_ondemand_fd_write_iter()", " - cachefiles: Fix missing pos updates in cachefiles_ondemand_fd_write_iter()", " - cachefiles: Fix NULL pointer dereference in object->file", " - netfs/fscache: Add a memory barrier for FSCACHE_VOLUME_CREATING", " - block: constify the lim argument to queue_limits_max_zone_append_sectors", " - block: properly handle REQ_OP_ZONE_APPEND in __bio_split_to_limits", " - block: take chunk_sectors into account in bio_split_write_zeroes", " - block: fix bio_split_rw_at to take zone_write_granularity into account", " - s390/syscalls: Avoid creation of arch/arch/ directory", " - hfsplus: don't query the device logical block size multiple times", " - ext4: pipeline buffer reads in mext_page_mkuptodate()", " - ext4: remove array of buffer_heads from mext_page_mkuptodate()", " - ext4: fix race in buffer_head read fault injection", " - nvme-pci: reverse request order in nvme_queue_rqs", " - virtio_blk: reverse request order in virtio_queue_rqs", " - crypto: mxs-dcp - Fix AES-CBC with hardware-bound keys", " - crypto: caam - Fix the pointer passed to caam_qi_shutdown()", " - crypto: qat - remove check after debugfs_create_dir()", " - crypto: qat/qat_420xx - fix off by one in uof_get_name()", " - crypto: qat/qat_4xxx - fix off by one in uof_get_name()", " - firmware: google: Unregister driver_info on failure", " - EDAC/bluefield: Fix potential integer overflow", " - crypto: qat - remove faulty arbiter config reset", " - thermal: core: Initialize thermal zones before registering them", " - thermal: core: Drop thermal_zone_device_is_enabled()", " - thermal: core: Rearrange PM notification code", " - thermal: core: Represent suspend-related thermal zone flags as bits", " - thermal: core: Mark thermal zones as initializing to start with", " - thermal: core: Fix race between zone registration and system suspend", " - EDAC/fsl_ddr: Fix bad bit shift operations", " - EDAC/skx_common: Differentiate memory error sources", " - EDAC/{skx_common,i10nm}: Fix incorrect far-memory error source indicator", " - crypto: pcrypt - Call crypto layer directly when padata_do_parallel() return", " -EBUSY", " - crypto: cavium - Fix the if condition to exit loop after timeout", " - cpufreq/amd-pstate: Don't update CPPC request in", " amd_pstate_cpu_boost_update()", " - amd-pstate: Set min_perf to nominal_perf for active mode performance gov", " - crypto: hisilicon/qm - disable same error report before resetting", " - EDAC/igen6: Avoid segmentation fault on module unload", " - crypto: qat - Fix missing destroy_workqueue in adf_init_aer()", " - crypto: inside-secure - Fix the return value of safexcel_xcbcmac_cra_init()", " - sched/cpufreq: Ensure sd is rebuilt for EAS check", " - doc: rcu: update printed dynticks counter bits", " - rcu/srcutiny: don't return before reenabling preemption", " - rcu/kvfree: Fix data-race in __mod_timer / kvfree_call_rcu", " - hwmon: (pmbus/core) clear faults after setting smbalert mask", " - hwmon: (nct6775-core) Fix overflows seen when writing limit attributes", " - ACPI: CPPC: Fix _CPC register setting issue", " - crypto: caam - add error check to caam_rsa_set_priv_key_form", " - crypto: bcm - add error check in the ahash_hmac_init function", " - crypto: cavium - Fix an error handling path in cpt_ucode_load_fw()", " - rcuscale: Do a proper cleanup if kfree_scale_init() fails", " - tools/lib/thermal: Make more generic the command encoding function", " - thermal/lib: Fix memory leak on error in thermal_genl_auto()", " - x86/unwind/orc: Fix unwind for newly forked tasks", " - Revert \"scripts/faddr2line: Check only two symbols when calculating symbol", " size\"", " - cleanup: Remove address space of returned pointer", " - time: Partially revert cleanup on msecs_to_jiffies() documentation", " - time: Fix references to _msecs_to_jiffies() handling of values", " - locking/atomic/x86: Use ALT_OUTPUT_SP() for __alternative_atomic64()", " - locking/atomic/x86: Use ALT_OUTPUT_SP() for __arch_{,try_}cmpxchg64_emu()", " - kcsan, seqlock: Support seqcount_latch_t", " - kcsan, seqlock: Fix incorrect assumption in read_seqbegin()", " - clocksource/drivers:sp804: Make user selectable", " - clocksource/drivers/timer-ti-dm: Fix child node refcount handling", " - regulator: qcom-smd: make smd_vreg_rpm static", " - spi: spi-fsl-lpspi: Use IRQF_NO_AUTOEN flag in request_irq()", " - arm64: dts: qcom: qcs6390-rb3gen2: use modem.mbn for modem DSP", " - ARM: dts: renesas: genmai: Fix partition size for QSPI NOR Flash", " - drivers: soc: xilinx: add the missing kfree in xlnx_add_cb_for_suspend()", " - microblaze: Export xmb_manager functions", " - arm64: dts: mediatek: mt8188: Fix wrong clock provider in MFG1 power domain", " - arm64: dts: mediatek: mt8395-genio-1200-evk: Fix dtbs_check error for phy", " - arm64: dts: mt8195: Fix dtbs_check error for mutex node", " - arm64: dts: mt8195: Fix dtbs_check error for infracfg_ao node", " - soc: ti: smartreflex: Use IRQF_NO_AUTOEN flag in request_irq()", " - soc: qcom: geni-se: fix array underflow in geni_se_clk_tbl_get()", " - arm64: dts: qcom: sm6350: Fix GPU frequencies missing on some speedbins", " - arm64: dts: qcom: sda660-ifc6560: fix l10a voltage ranges", " - ARM: dts: microchip: sam9x60: Add missing property atmel,usart-mode", " - mmc: mmc_spi: drop buggy snprintf()", " - scripts/kernel-doc: Do not track section counter across processed files", " - arm64: dts: qcom: x1e80100-slim7x: Drop orientation-switch from USB SS[0-1]", " QMP PHYs", " - arm64: dts: qcom: x1e80100-vivobook-s15: Drop orientation-switch from USB", " SS[0-1] QMP PHYs", " - openrisc: Implement fixmap to fix earlycon", " - efi/libstub: fix efi_parse_options() ignoring the default command line", " - tpm: fix signed/unsigned bug when checking event logs", " - media: i2c: vgxy61: Fix an error handling path in vgxy61_detect()", " - media: i2c: ds90ub960: Fix missing return check on ub960_rxport_read call", " - arm64: dts: mt8183: krane: Fix the address of eeprom at i2c4", " - arm64: dts: mt8183: kukui: Fix the address of eeprom at i2c4", " - arm64: dts: qcom: x1e80100: Resize GIC Redistributor register region", " - kernel-doc: allow object-like macros in ReST output", " - arm64: dts: ti: k3-am62x-phyboard-lyra: Drop unnecessary McASP AFIFOs", " - arm64: dts: mediatek: mt8173-elm-hana: Add vdd-supply to second source", " trackpad", " - arm64: dts: mediatek: mt8188: Fix USB3 PHY port default status", " - arm64: dts: mediatek: mt8195-cherry: Use correct audio codec DAI", " - Revert \"cgroup: Fix memory leak caused by missing cgroup_bpf_offline\"", " - cgroup/bpf: only cgroup v2 can be attached by bpf programs", " - regulator: rk808: Restrict DVS GPIOs to the RK808 variant only", " - power: sequencing: make the QCom PMU pwrseq driver depend on CONFIG_OF", " - [Config] updateconfigs for POWER_SEQUENCING_QCOM_WCN", " - arm64: dts: rockchip: Remove 'enable-active-low' from two boards", " - arm64: dts: mt8183: fennel: add i2c2's i2c-scl-internal-delay-ns", " - arm64: dts: mt8183: burnet: add i2c2's i2c-scl-internal-delay-ns", " - arm64: dts: mt8183: cozmo: add i2c2's i2c-scl-internal-delay-ns", " - arm64: dts: mt8183: Damu: add i2c2's i2c-scl-internal-delay-ns", " - pwm: imx27: Workaround of the pwm output bug when decrease the duty cycle", " - ARM: dts: cubieboard4: Fix DCDC5 regulator constraints", " - arm64: dts: ti: k3-j7200: Fix register map for main domain pmx", " - arm64: dts: ti: k3-j7200: Fix clock ids for MCSPI instances", " - arm64: dts: ti: k3-j721e: Fix clock IDs for MCSPI instances", " - arm64: dts: ti: k3-j721s2: Fix clock IDs for MCSPI instances", " - watchdog: Add HAS_IOPORT dependency for SBC8360 and SBC7240", " - arm64: dts: qcom: x1e80100: Update C4/C5 residency/exit numbers", " - dt-bindings: cache: qcom,llcc: Fix X1E80100 reg entries", " - of/fdt: add dt_phys arg to early_init_dt_scan and early_init_dt_verify", " - pmdomain: ti-sci: Add missing of_node_put() for args.np", " - spi: tegra210-quad: Avoid shift-out-of-bounds", " - spi: zynqmp-gqspi: Undo runtime PM changes at driver exit time​", " - regmap: irq: Set lockdep class for hierarchical IRQ domains", " - arm64: dts: renesas: hihope: Drop #sound-dai-cells", " - arm64: dts: imx8mn-tqma8mqnl-mba8mx-usbot: fix coexistence of output-low and", " output-high in GPIO", " - arm64: dts: mediatek: Add ADC node on MT6357, MT6358, MT6359 PMICs", " - arm64: dts: mediatek: mt6358: fix dtbs_check error", " - arm64: dts: mediatek: mt8183-kukui-jacuzzi: Fix DP bridge supply names", " - arm64: dts: mediatek: mt8183-kukui-jacuzzi: Add supplies for fixed", " regulators", " - selftests/resctrl: Print accurate buffer size as part of MBM results", " - selftests/resctrl: Fix memory overflow due to unhandled wraparound", " - selftests/resctrl: Protect against array overrun during iMC config parsing", " - firmware: arm_scpi: Check the DVFS OPP count returned by the firmware", " - media: ipu6: Fix DMA and physical address debugging messages for 32-bit", " - media: ipu6: not override the dma_ops of device in driver", " - pwm: Assume a disabled PWM to emit a constant inactive output", " - media: atomisp: Add check for rgby_data memory allocation failure", " - arm64: dts: rockchip: correct analog audio name on Indiedroid Nova", " - HID: hyperv: streamline driver probe to avoid devres issues", " - platform/x86: panasonic-laptop: Return errno correctly in show callback", " - drm/imagination: Convert to use time_before macro", " - drm/imagination: Use pvr_vm_context_get()", " - drm/mm: Mark drm_mm_interval_tree*() functions with __maybe_unused", " - drm/vc4: hvs: Don't write gamma luts on 2711", " - drm/vc4: hdmi: Avoid hang with debug registers when suspended", " - drm/vc4: hvs: Fix dlist debug not resetting the next entry pointer", " - drm/vc4: hvs: Remove incorrect limit from hvs_dlist debugfs function", " - drm/vc4: hvs: Correct logic on stopping an HVS channel", " - wifi: ath9k: add range check for conn_rsp_epid in htc_connect_service()", " - drm/omap: Fix possible NULL dereference", " - drm/omap: Fix locking in omap_gem_new_dmabuf()", " - drm/v3d: Appease lockdep while updating GPU stats", " - wifi: p54: Use IRQF_NO_AUTOEN flag in request_irq()", " - wifi: mwifiex: Use IRQF_NO_AUTOEN flag in request_irq()", " - udmabuf: change folios array from kmalloc to kvmalloc", " - udmabuf: fix vmap_udmabuf error page set", " - [Config] updateconfigs for VMAP_PFN", " - drm/imx/dcss: Use IRQF_NO_AUTOEN flag in request_irq()", " - drm/imx/ipuv3: Use IRQF_NO_AUTOEN flag in request_irq()", " - drm/panel: nt35510: Make new commands optional", " - drm/v3d: Address race-condition in MMU flush", " - drm/v3d: Flush the MMU before we supply more memory to the binner", " - drm/amdgpu: Fix JPEG v4.0.3 register write", " - wifi: ath10k: fix invalid VHT parameters in supported_vht_mcs_rate_nss1", " - wifi: ath10k: fix invalid VHT parameters in supported_vht_mcs_rate_nss2", " - wifi: ath12k: Skip Rx TID cleanup for self peer", " - dt-bindings: vendor-prefixes: Add NeoFidelity, Inc", " - ASoC: fsl_micfil: fix regmap_write_bits usage", " - ASoC: dt-bindings: mt6359: Update generic node name and dmic-mode", " - ASoC: fsl-asoc-card: Add missing handling of {hp,mic}-dt-gpios", " - drm/bridge: anx7625: Drop EDID cache on bridge power off", " - drm/bridge: it6505: Drop EDID cache on bridge power off", " - libbpf: Fix expected_attach_type set handling in program load callback", " - libbpf: Fix output .symtab byte-order during linking", " - dlm: fix swapped args sb_flags vs sb_status", " - wifi: rtl8xxxu: Perform update_beacon_work when beaconing is enabled", " - drm/amd/display: fix a memleak issue when driver is removed", " - wifi: ath12k: fix use-after-free in ath12k_dp_cc_cleanup()", " - wifi: ath12k: fix one more memcpy size error", " - bpf: Fix the xdp_adjust_tail sample prog issue", " - selftests/bpf: netns_new() and netns_free() helpers.", " - selftests/bpf: Fix backtrace printing for selftests crashes", " - wifi: ath11k: Fix CE offset address calculation for WCN6750 in SSR", " - selftests/bpf: add missing header include for htons", " - wifi: cfg80211: check radio iface combination for multi radio per wiphy", " - ice: consistently use q_idx in ice_vc_cfg_qs_msg()", " - drm/vc4: hdmi: Increase audio MAI fifo dreq threshold", " - drm/vc4: Introduce generation number enum", " - drm/vc4: Match drm_dev_enter and exit calls in vc4_hvs_lut_load", " - drm/vc4: Match drm_dev_enter and exit calls in vc4_hvs_atomic_flush", " - drm/vc4: Correct generation check in vc4_hvs_lut_load", " - libbpf: fix sym_is_subprog() logic for weak global subprogs", " - accel/ivpu: Prevent recovery invocation during probe and resume", " - ASoC: rt722-sdca: Remove logically deadcode in rt722-sdca.c", " - libbpf: never interpret subprogs in .text as entry programs", " - netdevsim: copy addresses for both in and out paths", " - drm/bridge: tc358767: Fix link properties discovery", " - selftests/bpf: Fix msg_verify_data in test_sockmap", " - selftests/bpf: Fix txmsg_redir of test_txmsg_pull in test_sockmap", " - wifi: wilc1000: Set MAC after operation mode", " - wifi: mwifiex: Fix memcpy() field-spanning write warning in", " mwifiex_config_scan()", " - drm: fsl-dcu: enable PIXCLK on LS1021A", " - drm: panel: nv3052c: correct spi_device_id for RG35XX panel", " - drm/msm/dpu: on SDM845 move DSPP_3 to LM_5 block", " - drm/msm/dpu: drop LM_3 / LM_4 on SDM845", " - drm/msm/dpu: drop LM_3 / LM_4 on MSM8998", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_common.c", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_ethtool.c", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_flows.c", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in cn10k.c", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dmac_flt.c", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dcbnl.c", " - selftests/bpf: fix test_spin_lock_fail.c's global vars usage", " - libbpf: move global data mmap()'ing into bpf_object__load()", " - drm/panfrost: Remove unused id_mask from struct panfrost_model", " - bpf, arm64: Remove garbage frame for struct_ops trampoline", " - drm/msm/adreno: Use IRQF_NO_AUTOEN flag in request_irq()", " - drm/msm/gpu: Check the status of registration to PM QoS", " - drm/xe/hdcp: Fix gsc structure check in fw check status", " - drm/etnaviv: Request pages from DMA32 zone on addressing_limited", " - drm/etnaviv: hold GPU lock across perfmon sampling", " - drm/amd/display: Increase idle worker HPD detection time", " - drm/amd/display: Reduce HPD Detection Interval for IPS", " - drm/nouveau/gr/gf100: Fix missing unlock in gf100_gr_chan_new()", " - drm: zynqmp_kms: Unplug DRM device before removal", " - drm: xlnx: zynqmp_disp: layer may be null while releasing", " - wifi: wfx: Fix error handling in wfx_core_init()", " - wifi: cw1200: Fix potential NULL dereference", " - drm/msm/dpu: cast crtc_clk calculation to u64 in _dpu_core_perf_calc_clk()", " - bpf, bpftool: Fix incorrect disasm pc", " - bpf: Tighten tail call checks for lingering locks, RCU, preempt_disable", " - drm/vkms: Drop unnecessary call to drm_crtc_cleanup()", " - drm/amdgpu: Fix the memory allocation issue in", " amdgpu_discovery_get_nps_info()", " - bpf: Support __nullable argument suffix for tp_btf", " - selftests/bpf: Add test for __nullable suffix in tp_btf", " - bpf: Mark raw_tp arguments with PTR_MAYBE_NULL", " - drm: use ATOMIC64_INIT() for atomic64_t", " - netfilter: nf_tables: avoid false-positive lockdep splat on rule deletion", " - netfilter: nf_tables: must hold rcu read lock while iterating expression", " type list", " - netfilter: nf_tables: must hold rcu read lock while iterating object type", " list", " - netlink: typographical error in nlmsg_type constants definition", " - wifi: rtw89: coex: check NULL return of kmalloc in btc_fw_set_monreg()", " - drm/panfrost: Add missing OPP table refcnt decremental", " - drm/panthor: introduce job cycle and timestamp accounting", " - drm/panthor: record current and maximum device clock frequencies", " - drm/panthor: Fix OPP refcnt leaks in devfreq initialisation", " - isofs: avoid memory leak in iocharset", " - selftests/bpf: Add txmsg_pass to pull/push/pop in test_sockmap", " - selftests/bpf: Fix SENDPAGE data logic in test_sockmap", " - selftests/bpf: Fix total_bytes in msg_loop_rx in test_sockmap", " - selftests/bpf: Add push/pop checking for msg_verify_data in test_sockmap", " - bpf, sockmap: Several fixes to bpf_msg_push_data", " - bpf, sockmap: Several fixes to bpf_msg_pop_data", " - bpf, sockmap: Fix sk_msg_reset_curr", " - ipv6: release nexthop on device removal", " - selftests: net: really check for bg process completion", " - wifi: cfg80211: Remove the Medium Synchronization Delay validity check", " - wifi: iwlwifi: allow fast resume on ax200", " - wifi: iwlwifi: mvm: tell iwlmei when we finished suspending", " - drm/amdgpu: fix ACA bank count boundary check error", " - drm/amdgpu: Fix map/unmap queue logic", " - drm/amdkfd: Fix wrong usage of INIT_WORK()", " - bpf: Allow return values 0 and 1 for kprobe session", " - bpf: Force uprobe bpf program to always return 0", " - selftests/bpf: skip the timer_lockup test for single-CPU nodes", " - ipv6: Fix soft lockups in fib6_select_path under high next hop churn", " - net: rfkill: gpio: Add check for clk_enable()", " - Revert \"wifi: iwlegacy: do not skip frames with bad FCS\"", " - bpf: Use function pointers count as struct_ops links count", " - bpf: Add kernel symbol for struct_ops trampoline", " - ALSA: usx2y: Use snd_card_free_when_closed() at disconnection", " - ALSA: us122l: Use snd_card_free_when_closed() at disconnection", " - ALSA: caiaq: Use snd_card_free_when_closed() at disconnection", " - ALSA: 6fire: Release resources at card release", " - i2c: dev: Fix memory leak when underlying adapter does not support I2C", " - selftests: netfilter: Fix missing return values in conntrack_dump_flush", " - Bluetooth: btintel_pcie: Add handshake between driver and firmware", " - Bluetooth: btintel: Do no pass vendor events to stack", " - Bluetooth: btmtk: adjust the position to init iso data anchor", " - Bluetooth: btbcm: fix missing of_node_put() in btbcm_get_board_name()", " - Bluetooth: ISO: Use kref to track lifetime of iso_conn", " - Bluetooth: ISO: Do not emit LE PA Create Sync if previous is pending", " - Bluetooth: ISO: Do not emit LE BIG Create Sync if previous is pending", " - Bluetooth: ISO: Send BIG Create Sync via hci_sync", " - Bluetooth: fix use-after-free in device_for_each_child()", " - xsk: Free skb when TX metadata options are invalid", " - erofs: handle NONHEAD !delta[1] lclusters gracefully", " - dlm: fix dlm_recover_members refcount on error", " - eth: fbnic: don't disable the PCI device twice", " - net: txgbe: remove GPIO interrupt controller", " - net: txgbe: fix null pointer to pcs", " - netpoll: Use rcu_access_pointer() in netpoll_poll_lock", " - wireguard: selftests: load nf_conntrack if not present", " - bpf: fix recursive lock when verdict program return SK_PASS", " - unicode: Fix utf8_load() error path", " - cppc_cpufreq: Use desired perf if feedback ctrs are 0 or unchanged", " - RDMA/core: Provide rdma_user_mmap_disassociate() to disassociate mmap pages", " - RDMA/hns: Disassociate mmap pages for all uctx when HW is being reset", " - clk: mediatek: drop two dead config options", " - [Config] drop COMMON_CLK_MT8195_{AUDSYS,MSDC}", " - trace/trace_event_perf: remove duplicate samples on the first tracepoint", " event", " - pinctrl: zynqmp: drop excess struct member description", " - pinctrl: renesas: Select PINCTRL_RZG2L for RZ/V2H(P) SoC", " - clk: qcom: videocc-sm8550: depend on either gcc-sm8550 or gcc-sm8650", " - iommu/s390: Implement blocking domain", " - scsi: hisi_sas: Enable all PHYs that are not disabled by user during", " controller reset", " - powerpc/vdso: Flag VDSO64 entry points as functions", " - mfd: tps65010: Use IRQF_NO_AUTOEN flag in request_irq() to fix race", " - mfd: da9052-spi: Change read-mask to write-mask", " - mfd: intel_soc_pmic_bxtwc: Use IRQ domain for USB Type-C device", " - mfd: intel_soc_pmic_bxtwc: Use IRQ domain for TMU device", " - mfd: intel_soc_pmic_bxtwc: Use IRQ domain for PMIC devices", " - irqdomain: Simplify simple and legacy domain creation", " - irqdomain: Cleanup domain name allocation", " - irqdomain: Allow giving name suffix for domain", " - regmap: Allow setting IRQ domain name suffix", " - mfd: intel_soc_pmic_bxtwc: Fix IRQ domain names duplication", " - cpufreq: loongson2: Unregister platform_driver on failure", " - powerpc/fadump: Refactor and prepare fadump_cma_init for late init", " - powerpc/fadump: Move fadump_cma_init to setup_arch() after initmem_init()", " - mtd: hyperbus: rpc-if: Add missing MODULE_DEVICE_TABLE", " - mtd: rawnand: atmel: Fix possible memory leak", " - powerpc/mm/fault: Fix kfence page fault reporting", " - clk: sophgo: avoid integer overflow in sg2042_pll_recalc_rate()", " - mtd: spi-nor: spansion: Use nor->addr_nbytes in octal DTR mode in", " RD_ANY_REG_OP", " - powerpc/pseries: Fix dtl_access_lock to be a rw_semaphore", " - cpufreq: CPPC: Fix possible null-ptr-deref for cpufreq_cpu_get_raw()", " - cpufreq: CPPC: Fix possible null-ptr-deref for cppc_get_cpu_cost()", " - iommu/amd: Remove amd_iommu_domain_update() from page table freeing", " - iommu/amd: Remove the amd_iommu_domain_set_pt_root() and related", " - iommu/amd: Rename struct amd_io_pgtable iopt to pgtbl", " - iommu/amd: Store the nid in io_pgtable_cfg instead of the domain", " - iommu/amd: Narrow the use of struct protection_domain to invalidation", " - iommu/amd/pgtbl_v2: Take protection domain lock before invalidating TLB", " - RDMA/hns: Fix an AEQE overflow error caused by untimely update of eq_db_ci", " - RDMA/hns: Fix flush cqe error when racing with destroy qp", " - RDMA/hns: Modify debugfs name", " - RDMA/hns: Use dev_* printings in hem code instead of ibdev_*", " - RDMA/hns: Fix cpu stuck caused by printings during reset", " - RDMA/rxe: Fix the qp flush warnings in req", " - RDMA/bnxt_re: Check cqe flags to know imm_data vs inv_irkey", " - clk: sunxi-ng: d1: Fix PLL_AUDIO0 preset", " - clk: renesas: rzg2l: Fix FOUTPOSTDIV clk", " - RDMA/rxe: Set queue pair cur_qp_state when being queried", " - RISC-V: KVM: Fix APLIC in_clrip and clripnum write emulation", " - riscv: kvm: Fix out-of-bounds array access", " - clk: imx: lpcg-scu: SW workaround for errata (e10858)", " - clk: imx: fracn-gppll: correct PLL initialization flow", " - clk: imx: fracn-gppll: fix pll power up", " - clk: imx: clk-scu: fix clk enable state save and restore", " - clk: imx: imx8-acm: Fix return value check in", " clk_imx_acm_attach_pm_domains()", " - iommu/vt-d: Fix checks and print in dmar_fault_dump_ptes()", " - iommu/vt-d: Fix checks and print in pgtable_walk()", " - checkpatch: always parse orig_commit in fixes tag", " - mfd: rt5033: Fix missing regmap_del_irq_chip()", " - leds: max5970: Fix unreleased fwnode_handle in probe function", " - leds: ktd2692: Set missing timing properties", " - fs/proc/kcore.c: fix coccinelle reported ERROR instances", " - scsi: target: Fix incorrect function name in pscsi_create_type_disk()", " - scsi: bfa: Fix use-after-free in bfad_im_module_exit()", " - scsi: fusion: Remove unused variable 'rc'", " - scsi: qedf: Fix a possible memory leak in qedf_alloc_and_init_sb()", " - scsi: qedi: Fix a possible memory leak in qedi_alloc_and_init_sb()", " - scsi: sg: Enable runtime power management", " - x86/tdx: Introduce wrappers to read and write TD metadata", " - x86/tdx: Rename tdx_parse_tdinfo() to tdx_setup()", " - x86/tdx: Dynamically disable SEPT violations from causing #VEs", " - powerpc/fadump: allocate memory for additional parameters early", " - fadump: reserve param area if below boot_mem_top", " - RDMA/hns: Fix out-of-order issue of requester when setting FENCE", " - RDMA/hns: Fix NULL pointer derefernce in hns_roce_map_mr_sg()", " - cpufreq: loongson3: Check for error code from devm_mutex_init() call", " - cpufreq: CPPC: Fix wrong return value in cppc_get_cpu_cost()", " - cpufreq: CPPC: Fix wrong return value in cppc_get_cpu_power()", " - kasan: move checks to do_strncpy_from_user", " - kunit: skb: use \"gfp\" variable instead of hardcoding GFP_KERNEL", " - ocfs2: fix uninitialized value in ocfs2_file_read_iter()", " - dax: delete a stale directory pmem", " - KVM: PPC: Book3S HV: Stop using vc->dpdes for nested KVM guests", " - KVM: PPC: Book3S HV: Avoid returning to nested hypervisor on pending", " doorbells", " - powerpc/sstep: make emulate_vsx_load and emulate_vsx_store static", " - RDMA/hns: Fix different dgids mapping to the same dip_idx", " - KVM: PPC: Book3S HV: Fix kmv -> kvm typo", " - powerpc/kexec: Fix return of uninitialized variable", " - fbdev: sh7760fb: Fix a possible memory leak in sh7760fb_alloc_mem()", " - RDMA/mlx5: Move events notifier registration to be after device registration", " - clk: clk-apple-nco: Add NULL check in applnco_probe", " - clk: ralink: mtmips: fix clock plan for Ralink SoC RT3883", " - clk: ralink: mtmips: fix clocks probe order in oldest ralink SoCs", " - clk: en7523: remove REG_PCIE*_{MEM,MEM_MASK} configuration", " - clk: en7523: move clock_register in hw_init callback", " - clk: en7523: introduce chip_scu regmap", " - clk: en7523: fix estimation of fixed rate for EN7581", " - dt-bindings: clock: axi-clkgen: include AXI clk", " - clk: clk-axi-clkgen: make sure to enable the AXI bus clock", " - arm64: dts: qcom: sc8180x: Add a SoC-specific compatible to cpufreq-hw", " - pinctrl: k210: Undef K210_PC_DEFAULT", " - rtla/timerlat: Do not set params->user_workload with -U", " - smb: cached directories can be more than root file handle", " - mailbox: mtk-cmdq: fix wrong use of sizeof in cmdq_get_clocks()", " - mailbox: arm_mhuv2: clean up loop in get_irq_chan_comb()", " - x86: fix off-by-one in access_ok()", " - perf cs-etm: Don't flush when packet_queue fills up", " - gfs2: Rename GLF_VERIFY_EVICT to GLF_VERIFY_DELETE", " - gfs2: Allow immediate GLF_VERIFY_DELETE work", " - gfs2: Fix unlinked inode cleanup", " - perf test: Add test for Intel TPEBS counting mode", " - perf mem: Fix printing PERF_MEM_LVLNUM_{L2_MHB|MSC}", " - PCI: Fix reset_method_store() memory leak", " - perf stat: Close cork_fd when create_perf_stat_counter() failed", " - perf stat: Fix affinity memory leaks on error path", " - perf trace: Keep exited threads for summary", " - perf test attr: Add back missing topdown events", " - f2fs: compress: fix inconsistent update of i_blocks in", " release_compress_blocks and reserve_compress_blocks", " - f2fs: fix null-ptr-deref in f2fs_submit_page_bio()", " - f2fs: fix to account dirty data in __get_secs_required()", " - perf dso: Fix symtab_type for kmod compression", " - perf probe: Fix libdw memory leak", " - perf probe: Correct demangled symbols in C++ program", " - rust: kernel: fix THIS_MODULE header path in ThisModule doc comment", " - rust: macros: fix documentation of the paste! macro", " - PCI: cpqphp: Use PCI_POSSIBLE_ERROR() to check config reads", " - PCI: cpqphp: Fix PCIBIOS_* return value confusion", " - rust: block: fix formatting of `kernel::block::mq::request` module", " - perf disasm: Use disasm_line__free() to properly free disasm_line", " - virtiofs: use pages instead of pointer for kernel direct IO", " - perf ftrace latency: Fix unit on histogram first entry when using --use-nsec", " - i3c: master: Remove i3c_dev_disable_ibi_locked(olddev) on device hotjoin", " - f2fs: fix the wrong f2fs_bug_on condition in f2fs_do_replace_block", " - f2fs: check curseg->inited before write_sum_page in change_curseg", " - f2fs: Fix not used variable 'index'", " - f2fs: fix to avoid potential deadlock in f2fs_record_stop_reason()", " - f2fs: fix to avoid use GC_AT when setting gc_mode as GC_URGENT_LOW or", " GC_URGENT_MID", " - PCI: qcom-ep: Move controller cleanups to qcom_pcie_perst_deassert()", " - PCI: tegra194: Move controller cleanups to pex_ep_event_pex_rst_deassert()", " - PCI: cadence: Extract link setup sequence from cdns_pcie_host_setup()", " - PCI: cadence: Set cdns_pcie_host_init() global", " - PCI: j721e: Add reset GPIO to struct j721e_pcie", " - PCI: j721e: Use T_PERST_CLK_US macro", " - PCI: j721e: Add suspend and resume support", " - PCI: j721e: Deassert PERST# after a delay of PCIE_T_PVPERL_MS milliseconds", " - perf build: Add missing cflags when building with custom libtraceevent", " - f2fs: fix race in concurrent f2fs_stop_gc_thread", " - f2fs: fix to map blocks correctly for direct write", " - f2fs: fix to avoid forcing direct write to use buffered IO on inline_data", " inode", " - perf trace: avoid garbage when not printing a trace event's arguments", " - m68k: mcfgpio: Fix incorrect register offset for CONFIG_M5441x", " - m68k: coldfire/device.c: only build FEC when HW macros are defined", " - svcrdma: Address an integer overflow", " - nfsd: drop inode parameter from nfsd4_change_attribute()", " - perf list: Fix topic and pmu_name argument order", " - perf trace: Fix tracing itself, creating feedback loops", " - perf trace: Do not lose last events in a race", " - perf trace: Avoid garbage when not printing a syscall's arguments", " - remoteproc: qcom: pas: Remove subdevs on the error path of adsp_probe()", " - remoteproc: qcom: adsp: Remove subdevs on the error path of adsp_probe()", " - remoteproc: qcom: pas: add minidump_id to SM8350 resources", " - rpmsg: glink: use only lower 16-bits of param2 for CMD_OPEN name length", " - remoteproc: qcom_q6v5_mss: Re-order writes to the IMEM region", " - PCI: endpoint: epf-mhi: Avoid NULL dereference if DT lacks 'mmio'", " - NFSD: Prevent NULL dereference in nfsd4_process_cb_update()", " - NFSD: Cap the number of bytes copied by nfs4_reset_recoverydir()", " - nfsd: release svc_expkey/svc_export with rcu_work", " - svcrdma: fix miss destroy percpu_counter in svc_rdma_proc_init()", " - NFSD: Fix nfsd4_shutdown_copy()", " - f2fs: clean up val{>>,<<}F2FS_BLKSIZE_BITS", " - f2fs: fix to do cast in F2FS_{BLK_TO_BYTES, BTYES_TO_BLK} to avoid overflow", " - hwmon: (tps23861) Fix reporting of negative temperatures", " - hwmon: (aquacomputer_d5next) Fix length of speed_input array", " - phy: airoha: Fix REG_CSR_2L_PLL_CMN_RESERVE0 config in", " airoha_pcie_phy_init_clk_out()", " - phy: airoha: Fix REG_PCIE_PMA_TX_RESET config in", " airoha_pcie_phy_init_csr_2l()", " - phy: airoha: Fix REG_CSR_2L_JCPLL_SDM_HREN config in", " airoha_pcie_phy_init_ssc_jcpll()", " - phy: airoha: Fix REG_CSR_2L_RX{0,1}_REV0 definitions", " - vdpa/mlx5: Fix suboptimal range on iotlb iteration", " - vfio/mlx5: Fix an unwind issue in mlx5vf_add_migration_pages()", " - vfio/mlx5: Fix unwind flows in mlx5vf_pci_save/resume_device_data()", " - selftests/mount_setattr: Fix failures on 64K PAGE_SIZE kernels", " - gpio: zevio: Add missed label initialisation", " - vfio/pci: Properly hide first-in-list PCIe extended capability", " - fs_parser: update mount_api doc to match function signature", " - LoongArch: Fix build failure with GCC 15 (-std=gnu23)", " - LoongArch: BPF: Sign-extend return values", " - power: supply: core: Remove might_sleep() from power_supply_put()", " - power: supply: bq27xxx: Fix registers of bq27426", " - power: supply: rt9471: Fix wrong WDT function regfield declaration", " - power: supply: rt9471: Use IC status regfield to report real charger status", " - net: usb: lan78xx: Fix double free issue with interrupt buffer allocation", " - net: usb: lan78xx: Fix memory leak on device unplug by freeing PHY device", " - tg3: Set coherent DMA mask bits to 31 for BCM57766 chipsets", " - net: usb: lan78xx: Fix refcounting and autosuspend on invalid WoL", " configuration", " - net: microchip: vcap: Add typegroup table terminators in kunit tests", " - netlink: fix false positive warning in extack during dumps", " - exfat: fix file being changed by unaligned direct write", " - s390/iucv: MSG_PEEK causes memory leak in iucv_sock_destruct()", " - net/ipv6: delete temporary address if mngtmpaddr is removed or unmanaged", " - net: mdio-ipq4019: add missing error check", " - marvell: pxa168_eth: fix call balance of pep->clk handling routines", " - net: stmmac: dwmac-socfpga: Set RX watchdog interrupt as broken", " - octeontx2-af: RPM: Fix mismatch in lmac type", " - octeontx2-af: RPM: Fix low network performance", " - octeontx2-af: RPM: fix stale RSFEC counters", " - octeontx2-af: RPM: fix stale FCFEC counters", " - octeontx2-af: Quiesce traffic before NIX block reset", " - spi: atmel-quadspi: Fix register name in verbose logging function", " - net: hsr: fix hsr_init_sk() vs network/transport headers.", " - bnxt_en: Reserve rings after PCIe AER recovery if NIC interface is down", " - bnxt_en: Set backplane link modes correctly for ethtool", " - bnxt_en: Fix receive ring space parameters when XDP is active", " - bnxt_en: Refactor bnxt_ptp_init()", " - bnxt_en: Unregister PTP during PCI shutdown and suspend", " - Bluetooth: MGMT: Fix slab-use-after-free Read in set_powered_sync", " - Bluetooth: MGMT: Fix possible deadlocks", " - llc: Improve setsockopt() handling of malformed user input", " - rxrpc: Improve setsockopt() handling of malformed user input", " - tcp: Fix use-after-free of nreq in reqsk_timer_handler().", " - ip6mr: fix tables suspicious RCU usage", " - ipmr: fix tables suspicious RCU usage", " - iio: light: al3010: Fix an error handling path in al3010_probe()", " - usb: using mutex lock and supporting O_NONBLOCK flag in iowarrior_read()", " - usb: yurex: make waiting on yurex_write interruptible", " - USB: chaoskey: fail open after removal", " - USB: chaoskey: Fix possible deadlock chaoskey_list_lock", " - misc: apds990x: Fix missing pm_runtime_disable()", " - devres: Fix page faults when tracing devres from unloaded modules", " - usb: gadget: uvc: wake pump everytime we update the free list", " - interconnect: qcom: icc-rpmh: probe defer incase of missing QoS clock", " dependency", " - phy: realtek: usb: fix NULL deref in rtk_usb2phy_probe", " - phy: realtek: usb: fix NULL deref in rtk_usb3phy_probe", " - counter: stm32-timer-cnt: Add check for clk_enable()", " - counter: ti-ecap-capture: Add check for clk_enable()", " - bus: mhi: host: Switch trace_mhi_gen_tre fields to native endian", " - usb: typec: fix potential array underflow in ucsi_ccg_sync_control()", " - firmware_loader: Fix possible resource leak in fw_log_firmware_info()", " - ALSA: hda/realtek: Update ALC256 depop procedure", " - drm/radeon: add helper rdev_to_drm(rdev)", " - drm/radeon: change rdev->ddev to rdev_to_drm(rdev)", " - drm/radeon: Fix spurious unplug event on radeon HDMI", " - drm/amd/display: Fix null check for pipe_ctx->plane_state in", " dcn20_program_pipe", " - drm/amd/display: Fix null check for pipe_ctx->plane_state in hwss_setup_dpp", " - ASoC: imx-audmix: Add NULL check in imx_audmix_probe", " - drm/xe/ufence: Wake up waiters after setting ufence->signalled", " - apparmor: fix 'Do simple duplicate message elimination'", " - ALSA: core: Fix possible NULL dereference caused by kunit_kzalloc()", " - ASoC: amd: yc: Fix for enabling DMIC on acp6x via _DSD entry", " - ASoC: mediatek: Check num_codecs is not zero to avoid panic during probe", " - s390/pci: Fix potential double remove of hotplug slot", " - net_sched: sch_fq: don't follow the fast path if Tx is behind now", " - xen: Fix the issue of resource not being properly released in", " xenbus_dev_probe()", " - ALSA: usb-audio: Fix potential out-of-bound accesses for Extigy and Mbox", " devices", " - ALSA: usb-audio: Fix out of bounds reads when finding clock sources", " - usb: ehci-spear: fix call balance of sehci clk handling routines", " - usb: typec: ucsi: glink: fix off-by-one in connector_status", " - dm-cache: fix warnings about duplicate slab caches", " - dm-bufio: fix warnings about duplicate slab caches", " - ASoC: Intel: sst: Fix used of uninitialized ctx to log an error", " - soc: qcom: socinfo: fix revision check in qcom_socinfo_probe()", " - irqdomain: Always associate interrupts for legacy domains", " - ext4: supress data-race warnings in ext4_free_inodes_{count,set}()", " - ext4: fix FS_IOC_GETFSMAP handling", " - jfs: xattr: check invalid xattr size more strictly", " - ASoC: amd: yc: Add a quirk for microfone on Lenovo ThinkPad P14s Gen 5", " 21MES00B00", " - ASoC: codecs: Fix atomicity violation in snd_soc_component_get_drvdata()", " - ASoC: da7213: Populate max_register to regmap_config", " - perf/x86/intel/pt: Fix buffer full but size is 0 case", " - crypto: x86/aegis128 - access 32-bit arguments as 32-bit", " - KVM: x86: switch hugepage recovery thread to vhost_task", " - KVM: x86/mmu: Skip the \"try unsync\" path iff the old SPTE was a leaf SPTE", " - powerpc/pseries: Fix KVM guest detection for disabling hardlockup detector", " - KVM: arm64: vgic-v3: Sanitise guest writes to GICR_INVLPIR", " - KVM: arm64: Ignore PMCNTENSET_EL0 while checking for overflow status", " - KVM: arm64: Don't retire aborted MMIO instruction", " - KVM: arm64: vgic-its: Clear ITE when DISCARD frees an ITE", " - KVM: arm64: Get rid of userspace_irqchip_in_use", " - KVM: arm64: vgic-its: Add a data length check in vgic_its_save_*", " - KVM: arm64: vgic-its: Clear DTE when MAPD unmaps a device", " - Compiler Attributes: disable __counted_by for clang < 19.1.3", " - PCI: Fix use-after-free of slot->bus on hot remove", " - LoongArch: Explicitly specify code model in Makefile", " - clk: clk-loongson2: Fix memory corruption bug in struct", " loongson2_clk_provider", " - clk: clk-loongson2: Fix potential buffer overflow in flexible-array member", " access", " - fsnotify: fix sending inotify event with unexpected filename", " - comedi: Flush partial mappings in error case", " - apparmor: test: Fix memory leak for aa_unpack_strdup()", " - iio: dac: adi-axi-dac: fix wrong register bitfield", " - tty: ldsic: fix tty_ldisc_autoload sysctl's proc_handler", " - locking/lockdep: Avoid creating new name string literals in", " lockdep_set_subclass()", " - tools/nolibc: s390: include std.h", " - pinctrl: qcom: spmi: fix debugfs drive strength", " - dt-bindings: pinctrl: samsung: Fix interrupt constraint for variants with", " fallbacks", " - dt-bindings: iio: dac: ad3552r: fix maximum spi speed", " - exfat: fix uninit-value in __exfat_get_dentry_set", " - exfat: fix out-of-bounds access of directory entries", " - xhci: Fix control transfer error on Etron xHCI host", " - xhci: Combine two if statements for Etron xHCI host", " - xhci: Don't perform Soft Retry for Etron xHCI host", " - xhci: Don't issue Reset Device command to Etron xHCI host", " - Bluetooth: Fix type of len in rfcomm_sock_getsockopt{,_old}()", " - usb: xhci: Limit Stop Endpoint retries", " - usb: xhci: Fix TD invalidation under pending Set TR Dequeue", " - usb: xhci: Avoid queuing redundant Stop Endpoint commands", " - ARM: dts: omap36xx: declare 1GHz OPP as turbo again", " - wifi: ath12k: fix warning when unbinding", " - wifi: rtlwifi: Drastically reduce the attempts to read efuse in case of", " failures", " - wifi: nl80211: fix bounds checker error in nl80211_parse_sched_scan", " - wifi: ath12k: fix crash when unbinding", " - wifi: brcmfmac: release 'root' node in all execution paths", " - Revert \"fs: don't block i_writecount during exec\"", " - Revert \"f2fs: remove unreachable lazytime mount option parsing\"", " - Revert \"usb: gadget: composite: fix OS descriptors w_value logic\"", " - serial: sh-sci: Clean sci_ports[0] after at earlycon exit", " - Revert \"serial: sh-sci: Clean sci_ports[0] after at earlycon exit\"", " - io_uring: fix corner case forgetting to vunmap", " - io_uring: check for overflows in io_pin_pages", " - blk-settings: round down io_opt to physical_block_size", " - gpio: exar: set value when external pull-up or pull-down is present", " - spi: Fix acpi deferred irq probe", " - mtd: spi-nor: core: replace dummy buswidth from addr to data", " - cpufreq: mediatek-hw: Fix wrong return value in mtk_cpufreq_get_cpu_power()", " - cifs: support mounting with alternate password to allow password rotation", " - parisc/ftrace: Fix function graph tracing disablement", " - RISC-V: Scalar unaligned access emulated on hotplug CPUs", " - RISC-V: Check scalar unaligned access on all CPUs", " - ksmbd: fix use-after-free in SMB request handling", " - smb: client: fix NULL ptr deref in crypto_aead_setkey()", " - platform/chrome: cros_ec_typec: fix missing fwnode reference decrement", " - irqchip/irq-mvebu-sei: Move misplaced select() callback to SEI CP domain", " - x86/CPU/AMD: Terminate the erratum_1386_microcode array", " - ubi: wl: Put source PEB into correct list if trying locking LEB failed", " - um: ubd: Do not use drvdata in release", " - um: net: Do not use drvdata in release", " - dt-bindings: serial: rs485: Fix rs485-rts-delay property", " - serial: 8250_fintek: Add support for F81216E", " - serial: 8250: omap: Move pm_runtime_get_sync", " - serial: amba-pl011: Fix RX stall when DMA is used", " - serial: amba-pl011: fix build regression", " - mtd: ubi: fix unreleased fwnode_handle in find_volume_fwnode()", " - block: Prevent potential deadlock in blk_revalidate_disk_zones()", " - um: vector: Do not use drvdata in release", " - sh: cpuinfo: Fix a warning for CONFIG_CPUMASK_OFFSTACK", " - iio: gts: Fix uninitialized symbol 'ret'", " - ublk: fix ublk_ch_mmap() for 64K page size", " - arm64: tls: Fix context-switching of tpidrro_el0 when kpti is enabled", " - block: fix missing dispatching request when queue is started or unquiesced", " - block: fix ordering between checking QUEUE_FLAG_QUIESCED request adding", " - block: fix ordering between checking BLK_MQ_S_STOPPED request adding", " - blk-mq: Make blk_mq_quiesce_tagset() hold the tag list mutex less long", " - gve: Flow steering trigger reset only for timeout error", " - HID: wacom: Interpret tilt data from Intuos Pro BT as signed values", " - i40e: Fix handling changed priv flags", " - media: wl128x: Fix atomicity violation in fmc_send_cmd()", " - media: intel/ipu6: do not handle interrupts when device is disabled", " - arm64: dts: mediatek: mt8186-corsola-voltorb: Merge speaker codec nodes", " - netdev-genl: Hold rcu_read_lock in napi_get", " - soc: fsl: rcpm: fix missing of_node_put() in copy_ippdexpcr1_setting()", " - media: v4l2-core: v4l2-dv-timings: check cvt/gtf result", " - ALSA: rawmidi: Fix kvfree() call in spinlock", " - ALSA: ump: Fix evaluation of MIDI 1.0 FB info", " - ALSA: pcm: Add sanity NULL check for the default mmap fault handler", " - ALSA: hda/realtek: Update ALC225 depop procedure", " - ALSA: hda/realtek: Set PCBeep to default value for ALC274", " - ALSA: hda/realtek: Fix Internal Speaker and Mic boost of Infinix Y4 Max", " - ALSA: hda/realtek: Apply quirk for Medion E15433", " - smb3: request handle caching when caching directories", " - smb: client: handle max length for SMB symlinks", " - smb: Don't leak cfid when reconnect races with open_cached_dir", " - smb: prevent use-after-free due to open_cached_dir error paths", " - smb: During unmount, ensure all cached dir instances drop their dentry", " - usb: misc: ljca: set small runtime autosuspend delay", " - usb: misc: ljca: move usb_autopm_put_interface() after wait for response", " - usb: dwc3: ep0: Don't clear ep0 DWC3_EP_TRANSFER_STARTED", " - usb: musb: Fix hardware lockup on first Rx endpoint request", " - usb: dwc3: gadget: Fix checking for number of TRBs left", " - usb: dwc3: gadget: Fix looping of queued SG entries", " - staging: vchiq_arm: Fix missing refcount decrement in error path for fw_node", " - counter: stm32-timer-cnt: fix device_node handling in probe_encoder()", " - ublk: fix error code for unsupported command", " - lib: string_helpers: silence snprintf() output truncation warning", " - f2fs: fix to do sanity check on node blkaddr in truncate_node()", " - ipc: fix memleak if msg_init_ns failed in create_ipc_ns", " - Input: cs40l50 - fix wrong usage of INIT_WORK()", " - NFSD: Prevent a potential integer overflow", " - SUNRPC: make sure cache entry active before cache_show", " - um: Fix potential integer overflow during physmem setup", " - um: Fix the return value of elf_core_copy_task_fpregs", " - kfifo: don't include dma-mapping.h in kfifo.h", " - um: ubd: Initialize ubd's disk pointer in ubd_add", " - um: Always dump trace for specified task in show_stack", " - NFSv4.0: Fix a use-after-free problem in the asynchronous open()", " - rtc: st-lpc: Use IRQF_NO_AUTOEN flag in request_irq()", " - rtc: abx80x: Fix WDT bit position of the status register", " - rtc: check if __rtc_read_time was successful in rtc_timer_do_work()", " - ubi: fastmap: wl: Schedule fm_work if wear-leveling pool is empty", " - ubifs: Correct the total block count by deducting journal reservation", " - ubi: fastmap: Fix duplicate slab cache names while attaching", " - ubifs: authentication: Fix use-after-free in ubifs_tnc_end_commit", " - jffs2: fix use of uninitialized variable", " - rtc: rzn1: fix BCD to rtc_time conversion errors", " - Revert \"nfs: don't reuse partially completed requests in", " nfs_lock_and_join_requests\"", " - nvme-multipath: avoid hang on inaccessible namespaces", " - nvme/multipath: Fix RCU list traversal to use SRCU primitive", " - blk-mq: add non_owner variant of start_freeze/unfreeze queue APIs", " - block: model freeze & enter queue as lock for supporting lockdep", " - block: fix uaf for flush rq while iterating tags", " - block: return unsigned int from bdev_io_min", " - nvme-fabrics: fix kernel crash while shutting down controller", " - 9p/xen: fix init sequence", " - 9p/xen: fix release of IRQ", " - perf/arm-smmuv3: Fix lockdep assert in ->event_init()", " - perf/arm-cmn: Ensure port and device id bits are set properly", " - smb: client: disable directory caching when dir_cache_timeout is zero", " - x86/Documentation: Update algo in init_size description of boot protocol", " - cifs: Fix parsing native symlinks relative to the export", " - cifs: Fix parsing reparse point with native symlink in SMB1 non-UNICODE", " session", " - rtc: ab-eoz9: don't fail temperature reads on undervoltage notification", " - Rename .data.unlikely to .data..unlikely", " - Rename .data.once to .data..once to fix resetting WARN*_ONCE", " - kbuild: deb-pkg: Don't fail if modules.order is missing", " - smb: Initialize cfid->tcon before performing network ops", " - block: Don't allow an atomic write be truncated in blkdev_write_iter()", " - modpost: remove incorrect code in do_eisa_entry()", " - cifs: during remount, make sure passwords are in sync", " - cifs: unlock on error in smb3_reconfigure()", " - nfs: ignore SB_RDONLY when mounting nfs", " - sunrpc: clear XPRT_SOCK_UPD_TIMEOUT when reset transport", " - SUNRPC: timeout and cancel TLS handshake with -ETIMEDOUT", " - sunrpc: fix one UAF issue caused by sunrpc kernel tcp socket", " - nfs/blocklayout: Don't attempt unregister for invalid block device", " - nfs/blocklayout: Limit repeat device registration on failure", " - block, bfq: fix bfqq uaf in bfq_limit_depth()", " - brd: decrease the number of allocated pages which discarded", " - sh: intc: Fix use-after-free bug in register_intc_controller()", " - tools/power turbostat: Fix trailing '\\n' parsing", " - tools/power turbostat: Fix child's argument forwarding", " - block: always verify unfreeze lock on the owner task", " - block: don't verify IO lock for freeze/unfreeze in elevator_init_mq()", " - Linux 6.11.11", "", " * Oracular update: v6.11.11 upstream stable release (LP: #2091655) //", " CVE-2024-53141", " - netfilter: ipset: add missing range check in bitmap_ip_uadt", "", " * Oracular update: v6.11.11 upstream stable release (LP: #2091655) //", " CVE-2024-50010", " - Revert \"exec: don't WARN for racy path_noexec check\"", "", " * Oracular update: v6.11.11 upstream stable release (LP: #2091655) //", " CVE-2024-53143", " - fsnotify: Fix ordering of iput() and watched_objects decrement", "", " * Oracular update: v6.11.11 upstream stable release (LP: #2091655) //", " CVE-2024-53142", " - initramfs: avoid filename buffer overrun", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650)", " - net: vertexcom: mse102x: Fix tx_bytes calculation", " - net/mlx5: Fix msix vectors to respect platform limit", " - net/mlx5e: clear xdp features on non-uplink representors", " - net/mlx5e: Disable loopback self-test on multi-PF netdev", " - drm/i915/gsc: ARL-H and ARL-U need a newer GSC FW.", " - drivers: perf: Fix wrong put_cpu() placement", " - Bluetooth: hci_core: Fix calling mgmt_device_connected", " - Bluetooth: btintel: Direct exception event to bluetooth stack", " - net: sched: cls_u32: Fix u32's systematic failure to free IDR entries for", " hnodes.", " - net: phylink: ensure PHY momentary link-fails are handled", " - samples: pktgen: correct dev to DEV", " - net: stmmac: dwmac-mediatek: Fix inverted handling of mediatek,mac-wol", " - net: Make copy_safe_from_sockptr() match documentation", " - stmmac: dwmac-intel-plat: fix call balance of tx_clk handling routines", " - net: ti: icssg-prueth: Fix 1 PPS sync", " - bonding: add ns target multicast address to slave device", " - ARM: 9419/1: mm: Fix kernel memory mapping for xip kernels", " - tools/mm: fix compile error", " - drm/amd/display: Run idle optimizations at end of vblank handler", " - drm/amd/display: Change some variable name of psr", " - drm/amd/display: Fix Panel Replay not update screen correctly", " - x86/mm: Fix a kdump kernel failure on SME system when CONFIG_IMA_KEXEC=y", " - x86/stackprotector: Work around strict Clang TLS symbol requirements", " - crash, powerpc: default to CRASH_DUMP=n on PPC_BOOK3S_32", " - [Config] enable ARCH_DEFAULT_CRASH_DUMP", " - mm: revert \"mm: shmem: fix data-race in shmem_getattr()\"", " - vdpa/mlx5: Fix PA offset with unaligned starting iotlb map", " - evm: stop avoidably reading i_writecount in evm_file_release", " - KVM: selftests: Disable strict aliasing", " - KVM: nVMX: Treat vpid01 as current if L2 is active, but with VPID disabled", " - KVM: x86: Unconditionally set irr_pending when updating APICv state", " - tpm: Disable TPM on tpm2_create_primary() failure", " - ALSA: hda/realtek - Fixed Clevo platform headset Mic issue", " - ALSA: hda/realtek - update set GPIO3 to default for Thinkpad with ALC1318", " - mptcp: update local address flags when setting it", " - mptcp: hold pm lock when deleting entry", " - mptcp: pm: use _rcu variant under rcu_read_lock", " - ocfs2: fix UBSAN warning in ocfs2_verify_volume()", " - LoongArch: Fix early_numa_add_cpu() usage for FDT systems", " - LoongArch: Disable KASAN if PGDIR_SIZE is too large for cpu_vabits", " - LoongArch: Add WriteCombine shadow mapping in KASAN", " - LoongArch: Fix AP booting issue in VM mode", " - LoongArch: Make KASAN work with 5-level page-tables", " - selftests: hugetlb_dio: fixup check for initial conditions to skip in the", " start", " - btrfs: fix incorrect comparison for delayed refs", " - mailbox: qcom-cpucp: Mark the irq with IRQF_NO_SUSPEND flag", " - firmware: arm_scmi: Skip opp duplicates", " - firmware: arm_scmi: Report duplicate opps as firmware bugs", " - mmc: sunxi-mmc: Fix A100 compatible description", " - drm/bridge: tc358768: Fix DSI command tx", " - drm/xe: handle flat ccs during hibernation on igpu", " - pmdomain: arm: Use FLAG_DEV_NAME_FW to ensure unique names", " - pmdomain: core: Add GENPD_FLAG_DEV_NAME_FW flag", " - nouveau: fw: sync dma after setup is called.", " - nouveau: handle EBUSY and EAGAIN for GSP aux errors.", " - nouveau/dp: handle retries for AUX CH transfers with GSP.", " - drm/amd: Fix initialization mistake for NBIO 7.7.0", " - drm/amdgpu: fix check in gmc_v9_0_get_vm_pte()", " - drm/amdgpu: Fix video caps for H264 and HEVC encode maximum size", " - drm/amd/pm: print pp_dpm_mclk in ascending order on SMU v14.0.0", " - drm/amdgpu: enable GTT fallback handling for dGPUs only", " - drm/amdgpu/mes12: correct kiq unmap latency", " - drm/amd/display: Require minimum VBlank size for stutter optimization", " - drm/amd/display: Fix failure to read vram info due to static BP_RESULT", " - mm: refactor arch_calc_vm_flag_bits() and arm64 MTE handling", " - drm/xe: Restore system memory GGTT mappings", " - drm/xe: improve hibernation on igpu", " - lib/buildid: Fix build ID parsing logic", " - net: sched: u32: Add test case for systematic hnode IDR leaks", " - media: dvbdev: fix the logic when DVB_DYNAMIC_MINORS is not set", " - Linux 6.11.10", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53133", " - drm/amd/display: Handle dml allocation failure to avoid crash", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53108", " - drm/amd/display: Adjust VSDB parser for replay feature", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53134", " - pmdomain: imx93-blk-ctrl: correct remove path", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53132", " - drm/xe/oa: Fix \"Missing outer runtime PM protection\" warning", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53127", " - Revert \"mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K\"", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53130", " - nilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53105", " - mm: page_alloc: move mlocked flag clearance into free_pages_prepare()", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53109", " - nommu: pass NULL argument to vma_iter_prealloc()", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53131", " - nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53135", " - KVM: VMX: Bury Intel PT virtualization (guest/host mode) behind", " CONFIG_BROKEN", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53106", " - ima: fix buffer overrun in ima_eventdigest_init_common", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53110", " - vp_vdpa: fix id_table array not null terminated error", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53126", " - vdpa: solidrun: Fix UB bug with devres", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53111", " - mm/mremap: fix address wraparound in move_page_tables()", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53107", " - fs/proc/task_mmu: prevent integer overflow in pagemap_scan_get_args()", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53128", " - sched/task_stack: fix object_is_on_stack() for KASAN tagged pointers", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53112", " - ocfs2: uncache inode which has failed entering the group", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53113", " - mm: fix NULL pointer dereference in alloc_pages_bulk_noprof", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53114", " - x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 client", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53137", " - ARM: fix cacheflush with PAN", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53115", " - drm/vmwgfx: avoid null_ptr_deref in vmw_framebuffer_surface_create_handle", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53116", " - drm/panthor: Fix handling of partial GPU mapping of BOs", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53117", " - virtio/vsock: Improve MSG_ZEROCOPY error handling", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53118", " - vsock: Fix sk_error_queue memory leak", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53119", " - virtio/vsock: Fix accept_queue memory leak", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53120", " - net/mlx5e: CT: Fix null-ptr-deref in add rule err flow", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53138", " - net/mlx5e: kTLS, Fix incorrect page refcounting", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53121", " - net/mlx5: fs, lock FTE when checking if active", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53122", " - mptcp: cope racing subflow creation in mptcp_rcv_space_adjust", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53123", " - mptcp: error out earlier on disconnect", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53124", " - net: fix data-races around sk->sk_forward_alloc", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53129", " - drm/rockchip: vop: Fix a dereferenced before check warning", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53139", " - sctp: fix possible UAF in sctp_v6_available()", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53140", " - netlink: terminate outstanding dump on socket close", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649)", " - nvme/host: Fix RCU list traversal to use SRCU primitive", " - 9p: v9fs_fid_find: also lookup by inode if not found dentry", " - 9p: Avoid creating multiple slab caches with the same name", " - selftests/bpf: Verify that sync_linked_regs preserves subreg_def", " - nvmet-passthru: clear EUID/NGUID/UUID while using loop target", " - irqchip/ocelot: Fix trigger register address", " - pinctrl: aw9523: add missing mutex_destroy", " - pinctrl: intel: platform: Add Panther Lake to the list of supported", " - block: Fix elevator_get_default() checking for NULL q->tag_set", " - HID: multitouch: Add support for B2402FVA track point", " - HID: multitouch: Add quirk for HONOR MagicBook Art 14 touchpad", " - iommu/arm-smmu: Clarify MMU-500 CPRE workaround", " - nvme: disable CC.CRIME (NVME_CC_CRIME)", " - bpf: use kvzmalloc to allocate BPF verifier environment", " - crypto: api - Fix liveliness check in crypto_alg_tested", " - crypto: marvell/cesa - Disable hash algorithms", " - s390/ap: Fix CCA crypto card behavior within protected execution environment", " - sound: Make CONFIG_SND depend on INDIRECT_IOMEM instead of UML", " - drm/vmwgfx: Limit display layout ioctl array size to", " VMWGFX_NUM_DISPLAY_UNITS", " - selftests/bpf: Assert link info uprobe_multi count & path_size if unset", " - ALSA: hda/tas2781: Add new quirk for Lenovo, ASUS, Dell projects", " - drm/amdkfd: Accounting pdd vram_usage for svm", " - powerpc/powernv: Free name on error in opal_event_init()", " - net: phy: mdio-bcm-unimac: Add BCM6846 support", " - drm/xe/query: Increase timestamp width", " - nvme-loop: flush off pending I/O while shutting down loop controller", " - samples/landlock: Fix port parsing in sandboxer", " - vDPA/ifcvf: Fix pci_read_config_byte() return code handling", " - bpf: Fix mismatched RCU unlock flavour in bpf_out_neigh_v6", " - ASoC: Intel: avs: Update stream status in a separate thread", " - ASoC: codecs: Fix error handling in aw_dev_get_dsp_status function", " - ASoC: amd: yc: Add quirk for ASUS Vivobook S15 M3502RA", " - ASoC: amd: yc: Fix non-functional mic on ASUS E1404FA", " - ASoC: Intel: soc-acpi: lnl: Add match entry for TM2 laptops", " - netfs: Downgrade i_rwsem for a buffered write", " - HID: i2c-hid: Delayed i2c resume wakeup for 0x0d42 Goodix touchpad", " - HID: multitouch: Add quirk for Logitech Bolt receiver w/ Casa touchpad", " - HID: lenovo: Add support for Thinkpad X1 Tablet Gen 3 keyboard", " - ASoC: codecs: lpass-rx-macro: fix RXn(rx,n) macro for DSM_CTL and SEC7 regs", " - RISCV: KVM: use raw_spinlock for critical section in imsic", " - ASoC: rt722-sdca: increase clk_stop_timeout to fix clock stop issue", " - LoongArch: Use \"Exception return address\" to comment ERA", " - ASoC: fsl_micfil: Add sample rate constraint", " - net: usb: qmi_wwan: add Fibocom FG132 0x0112 composition", " - drm/xe: Enlarge the invalidation timeout from 150 to 500", " - drm/xe/guc/ct: Flush g2h worker in case of g2h response timeout", " - drm/xe: Handle unreliable MMIO reads during forcewake", " - drm/xe: Don't restart parallel queues multiple times on GT reset", " - mm: krealloc: Fix MTE false alarm in __do_krealloc", " - 9p: fix slab cache name creation for real", " - Linux 6.11.9", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53098", " - drm/xe/ufence: Prefetch ufence addr to catch bogus address", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53099", " - bpf: Check validity of link->type in bpf_link_show_fdinfo()", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53089", " - LoongArch: KVM: Mark hrtimer to expire in hard interrupt context", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53090", " - afs: Fix lock recursion", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53101", " - fs: Fix uninitialized value issue in from_kuid and from_kgid", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53091", " - bpf: Add sk_is_inet and IS_ICSK check in tls_sw_has_ctx_tx/rx", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53092", " - virtio_pci: Fix admin vq cleanup by using correct info pointer", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53102", " - nvme: make keep-alive synchronous operation", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53093", " - nvme-multipath: defer partition scanning", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53094", " - RDMA/siw: Add sendpage_ok() check to disable MSG_SPLICE_PAGES", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53100", " - nvme: tcp: avoid race between queue_lock lock and destroy", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53095", " - smb: client: Fix use-after-free of network namespace.", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645)", " - arm64: dts: rockchip: Fix rt5651 compatible value on rk3399-eaidk-610", " - arm64: dts: rockchip: Fix rt5651 compatible value on rk3399-sapphire-", " excavator", " - arm64: dts: rockchip: Move L3 cache outside CPUs in RK3588(S) SoC dtsi", " - arm64: dts: rockchip: Start cooling maps numbering from zero on ROCK 5B", " - arm64: dts: rockchip: Designate Turing RK1's system power controller", " - EDAC/qcom: Make irq configuration optional", " - arm64: dts: rockchip: Remove hdmi's 2nd interrupt on rk3328", " - arm64: dts: rockchip: Fix wakeup prop names on PineNote BT node", " - arm64: dts: rockchip: Fix reset-gpios property on brcm BT nodes", " - arm64: dts: rockchip: fix i2c2 pinctrl-names property on anbernic-rg353p/v", " - arm64: dts: rockchip: Drop regulator-init-microvolt from two boards", " - arm64: dts: rockchip: Fix bluetooth properties on rk3566 box demo", " - arm64: dts: rockchip: Fix bluetooth properties on Rock960 boards", " - arm64: dts: rockchip: Add DTS for FriendlyARM NanoPi R2S Plus", " - arm64: dts: rockchip: Remove undocumented supports-emmc property", " - arm64: dts: rockchip: Remove #cooling-cells from fan on Theobroma lion", " - arm64: dts: rockchip: Fix LED triggers on rk3308-roc-cc", " - arm64: dts: rockchip: remove num-slots property from rk3328-nanopi-r2s-plus", " - arm64: dts: qcom: sm8450 fix PIPE clock specification for pcie1", " - arm64: dts: imx8-ss-vpu: Fix imx8qm VPU IRQs", " - arm64: dts: imx8mp: correct sdhc ipg clk", " - arm64: dts: imx8mp-phyboard-pollux: Set Video PLL1 frequency to 506.8 MHz", " - firmware: qcom: scm: Return -EOPNOTSUPP for unsupported SHM bridge enabling", " - arm64: dts: rockchip: remove orphaned pinctrl-names from pinephone pro", " - ARM: dts: rockchip: fix rk3036 acodec node", " - ARM: dts: rockchip: drop grf reference from rk3036 hdmi", " - ARM: dts: rockchip: Fix the spi controller on rk3036", " - ARM: dts: rockchip: Fix the realtek audio codec on rk3036-kylin", " - arm64: dts: rockchip: Correct GPIO polarity on brcm BT nodes", " - sunrpc: handle -ENOTCONN in xs_tcp_setup_socket()", " - NFSv3: only use NFS timeout for MOUNT when protocols are compatible", " - NFS: Fix attribute delegation behaviour on exclusive create", " - NFS: Further fixes to attribute delegation a/mtime changes", " - nfs: avoid i_lock contention in nfs_clear_invalid_mapping", " - net: enetc: set MAC address to the VF net_device", " - net: dpaa_eth: print FD status in CPU endianness in dpaa_eth_fd tracepoint", " - dt-bindings: net: xlnx,axi-ethernet: Correct phy-mode property value", " - can: c_can: fix {rx,tx}_errors statistics", " - ice: change q_index variable type to s16 to store -1 value", " - e1000e: Remove Meteor Lake SMBUS workarounds", " - net: phy: ti: add PHY_RST_AFTER_CLK_EN flag", " - net: stmmac: Fix unbalanced IRQ wake disable warning on single irq case", " - netfilter: nf_tables: wait for rcu grace period on net_device removal", " - virtio_net: Support dynamic rss indirection table size", " - virtio_net: Sync rss config to device when virtnet_probe", " - virtio_net: Update rss when set queue", " - net: arc: rockchip: fix emac mdio node support", " - drivers: net: ionic: add missed debugfs cleanup to ionic_probe() error path", " - Revert \"ALSA: hda/conexant: Mute speakers at suspend / shutdown\"", " - media: stb0899_algo: initialize cfr before using it", " - media: dvb_frontend: don't play tricks with underflow values", " - media: adv7604: prevent underflow condition when reporting colorspace", " - scsi: sd_zbc: Use kvzalloc() to allocate REPORT ZONES buffer", " - ALSA: firewire-lib: fix return value on fail in amdtp_tscm_init()", " - tools/lib/thermal: Fix sampling handler context ptr", " - thermal/of: support thermal zones w/o trips subnode", " - ASoC: SOF: sof-client-probes-ipc4: Set param_size extension bits", " - media: pulse8-cec: fix data timestamp at pulse8_setup()", " - media: v4l2-ctrls-api: fix error handling for v4l2_g_ctrl()", " - can: m_can: m_can_close(): don't call free_irq() for IRQ-less devices", " - can: mcp251xfd: mcp251xfd_get_tef_len(): fix length calculation", " - can: mcp251xfd: mcp251xfd_ring_alloc(): fix coalescing configuration when", " switching CAN modes", " - can: {cc770,sja1000}_isa: allow building on x86_64", " - [Config] updateconfigs for CAN_{CC770,SJA1000}_ISA", " - drm/xe: Set mask bits for CCS_MODE register", " - pwm: imx-tpm: Use correct MODULO value for EPWM mode", " - rpmsg: glink: Handle rejected intent request better", " - drm/amd/pm: always pick the pptable from IFWI", " - drm/amd/display: Fix brightness level not retained over reboot", " - drm/imagination: Add a per-file PVR context list", " - drm/amdgpu: Adjust debugfs eviction and IB access permissions", " - drm/amdgpu: Adjust debugfs register access permissions", " - drm/amdgpu: Fix DPX valid mode check on GC 9.4.3", " - drm/amdgpu: prevent NULL pointer dereference if ATIF is not supported", " - thermal/drivers/qcom/lmh: Remove false lockdep backtrace", " - dm cache: correct the number of origin blocks to match the target length", " - dm cache: optimize dirty bit checking with find_next_bit when resizing", " - dm-unstriped: cast an operand to sector_t to prevent potential uint32_t", " overflow", " - mptcp: no admin perm to list endpoints", " - ALSA: usb-audio: Add quirk for HP 320 FHD Webcam", " - tracing: Fix tracefs mount options", " - net: wwan: t7xx: Fix off-by-one error in t7xx_dpmaif_rx_buf_alloc()", " - mptcp: use sock_kfree_s instead of kfree", " - arm64: Kconfig: Make SME depend on BROKEN for now", " - [Config] updateconfigs for ARM64_SME", " - arm64: smccc: Remove broken support for SMCCCv1.3 SVE discard hint", " - KVM: PPC: Book3S HV: Mask off LPCR_MER for a vCPU before running it to avoid", " spurious interrupts", " - btrfs: fix the length of reserved qgroup to free", " - btrfs: fix per-subvolume RO/RW flags with new mount API", " - platform/x86/amd/pmf: Relocate CPU ID macros to the PMF header", " - platform/x86/amd/pmf: Update SMU metrics table for 1AH family series", " - platform/x86/amd/pmf: Add SMU metrics table support for 1Ah family 60h model", " - i2c: designware: do not hold SCL low when I2C_DYNAMIC_TAR_UPDATE is not set", " - clk: qcom: gcc-x1e80100: Fix USB MP SS1 PHY GDSC pwrsts flags", " - clk: qcom: clk-alpha-pll: Fix pll post div mask when width is not set", " - fs/proc: fix compile warning about variable 'vmcore_mmap_ops'", " - objpool: fix to make percpu slot allocation more robust", " - mm/damon/core: handle zero {aggregation,ops_update} intervals", " - mm/damon/core: handle zero schemes apply interval", " - mm/mlock: set the correct prev on failure", " - thunderbolt: Add only on-board retimers when !CONFIG_USB4_DEBUGFS_MARGINING", " - usb: dwc3: fix fault at system suspend if device was already runtime", " suspended", " - USB: serial: qcserial: add support for Sierra Wireless EM86xx", " - USB: serial: option: add Fibocom FG132 0x0112 composition", " - USB: serial: option: add Quectel RG650V", " - clk: qcom: gcc-x1e80100: Fix halt_check for pipediv2 clocks", " - thunderbolt: Fix connection issue with Pluggable UD-4VPD dock", " - staging: vchiq_arm: Use devm_kzalloc() for drv_mgmt allocation", " - staging: vchiq_arm: Use devm_kzalloc() for vchiq_arm_state allocation", " - irqchip/gic-v3: Force propagation of the active state with a read-back", " - ucounts: fix counter leak in inc_rlimit_get_ucounts()", " - selftests: hugetlb_dio: check for initial conditions to skip in the start", " - firmware: qcom: scm: Refactor code to support multiple dload mode", " - [Config] updateconfigs for QCOM_SCM_DOWNLOAD_MODE_DEFAULT", " - firmware: qcom: scm: suppress download mode error", " - block: rework bio splitting", " - block: fix queue limits checks in blk_rq_map_user_bvec for real", " - drm/xe: Move LNL scheduling WA to xe_device.h", " - drm/xe/ufence: Flush xe ordered_wq in case of ufence timeout", " - drm/xe/guc/tlb: Flush g2h worker in case of tlb timeout", " - ASoC: amd: yc: fix internal mic on Xiaomi Book Pro 14 2022", " - xtensa: Emulate one-byte cmpxchg", " - Linux 6.11.8", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50265", " - ocfs2: remove entry once instead of null-ptr-dereference in", " ocfs2_xa_remove()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50266", " - clk: qcom: videocc-sm8350: use HW_CTRL_TRIGGER for vcodec GDSCs", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50267", " - USB: serial: io_edgeport: fix use after free in debug printk", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50268", " - usb: typec: fix potential out of bounds in ucsi_ccg_update_set_new_cam_cmd()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53083", " - usb: typec: qcom-pmic: init value of hdr_len/txbuf_len earlier", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50269", " - usb: musb: sunxi: Fix accessing an released usb phy", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53079", " - mm/thp: fix deferred split unqueue naming and locking", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50270", " - mm/damon/core: avoid overflow in damon_feed_loop_next_input()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50271", " - signal: restore the override_rlimit logic", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50272", " - filemap: Fix bounds checking in filemap_read()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53104", " - media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in", " uvc_parse_format", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50273", " - btrfs: reinitialize delayed ref list after deleting it from the list", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53064", " - idpf: fix idpf_vc_core_init error path", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50274", " - idpf: avoid vport access in idpf_get_link_ksettings", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53065", " - mm/slab: fix warning caused by duplicate kmem_cache creation in", " kmem_buckets_create", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50275", " - arm64/sve: Discard stale CPU state when handling SVE traps", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50276", " - net: vertexcom: mse102x: Fix possible double free of TX skb", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53066", " - nfs: Fix KMSAN warning in decode_getfattr_attrs()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53067", " - scsi: ufs: core: Start the RTC update work later", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50277", " - dm: fix a crash if blk_alloc_disk fails", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50278", " - dm cache: fix potential out-of-bounds access on the first resume", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50279", " - dm cache: fix out-of-bounds access to the dirty bitset when resizing", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50280", " - dm cache: fix flushing uninitialized delayed_work on cache_ctr error", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50281", " - KEYS: trusted: dcp: fix NULL dereference in AEAD crypto operation", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50282", " - drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53071", " - drm/panthor: Be stricter about IO mapping flags", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53080", " - drm/panthor: Lock XArray when getting entries for the VM", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53084", " - drm/imagination: Break an object reference loop", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53085", " - tpm: Lock TPM chip in tpm_pm_suspend() first", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53086", " - drm/xe: Drop VM dma-resv lock on xe_sync_in_fence_get failure in exec IOCTL", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53087", " - drm/xe: Fix possible exec queue leak in exec IOCTL", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50283", " - ksmbd: fix slab-use-after-free in smb3_preauth_hash_rsp", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50284", " - ksmbd: Fix the missing xa_store error check", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50285", " - ksmbd: check outstanding simultaneous SMB operations", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50286", " - ksmbd: fix slab-use-after-free in ksmbd_smb2_session_create", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50287", " - media: v4l2-tpg: prevent the risk of a division by zero", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50288", " - media: vivid: fix buffer overwrite when using > 32 buffers", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50289", " - media: av7110: fix a spectre vulnerability", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50290", " - media: cx24116: prevent overflows on SNR calculus", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53061", " - media: s5p-jpeg: prevent buffer overflows", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53081", " - media: ar0521: don't overflow when checking PLL values", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53062", " - media: mgb4: protect driver against spectre", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50291", " - media: dvb-core: add missing buffer index check", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50292", " - ASoC: stm32: spdifrx: fix dma channel release in stm32_spdifrx_remove", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53063", " - media: dvbdev: prevent the risk of out of memory access", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50293", " - net/smc: do not leave a dangling sk pointer in __smc_create()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50294", " - rxrpc: Fix missing locking causing hanging calls", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50295", " - net: arc: fix the device for dma_map_single/dma_unmap_single", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53082", " - virtio_net: Add hash_key_length check", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50296", " - net: hns3: fix kernel crash when uninstalling driver", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53088", " - i40e: fix race condition by adding filter's intermediate sync state", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50297", " - net: xilinx: axienet: Enqueue Tx packets in dql before dmaengine starts", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50298", " - net: enetc: allocate vf_state during PF probes", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50299", " - sctp: properly validate chunk size in sctp_sf_ootb()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50300", " - regulator: rtq2208: Fix uninitialized use of regulator_config", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50301", " - security/keys: fix slab-out-of-bounds in key_task_permission", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53072", " - platform/x86/amd/pmc: Detect when STB is not available", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50302", " - HID: core: zero-initialize the report buffer", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53068", " - firmware: arm_scmi: Fix slab-use-after-free in scmi_bus_notifier()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53069", " - firmware: qcom: scm: fix a NULL-pointer dereference", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629)", " - drm/amdgpu: fix random data corruption for sdma 7", " - cgroup: Fix potential overflow issue when checking max_depth", " - spi: geni-qcom: Fix boot warning related to pm_runtime and devres", " - perf trace: Fix non-listed archs in the syscalltbl routines", " - perf python: Fix up the build on architectures without HAVE_KVM_STAT_SUPPORT", " - scsi: scsi_debug: Fix do_device_access() handling of unexpected SG copy", " length", " - wifi: iwlegacy: Fix \"field-spanning write\" warning in il_enqueue_hcmd()", " - mac80211: MAC80211_MESSAGE_TRACING should depend on TRACING", " - wifi: mac80211: skip non-uploaded keys in ieee80211_iter_keys", " - wifi: ath11k: Fix invalid ring usage in full monitor mode", " - wifi: rtw89: pci: early chips only enable 36-bit DMA on specific PCI hosts", " - wifi: brcm80211: BRCM_TRACING should depend on TRACING", " - RDMA/cxgb4: Dump vendor specific QP details", " - RDMA/mlx5: Round max_rd_atomic/max_dest_rd_atomic up instead of down", " - RDMA/bnxt_re: Fix the usage of control path spin locks", " - RDMA/bnxt_re: synchronize the qp-handle table array", " - wifi: iwlwifi: mvm: really send iwl_txpower_constraints_cmd", " - wifi: iwlwifi: mvm: don't add default link in fw restart flow", " - Revert \"wifi: iwlwifi: remove retry loops in start\"", " - ASoC: cs42l51: Fix some error handling paths in cs42l51_probe()", " - net: stmmac: dwmac4: Fix high address display by updating reg_space[] from", " register values", " - dpll: add Embedded SYNC feature for a pin", " - ice: add callbacks for Embedded SYNC enablement on dpll pins", " - gtp: allow -1 to be specified as file description from userspace", " - bpf: Force checkpoint when jmp history is too long", " - bpf: Add bpf_mem_alloc_check_size() helper", " - net: skip offload for NETIF_F_IPV6_CSUM if ipv6 header contains extension", " - mlxsw: spectrum_ptp: Add missing verification before pushing Tx header", " - mlxsw: pci: Sync Rx buffers for CPU", " - mlxsw: pci: Sync Rx buffers for device", " - net: ethernet: mtk_wed: fix path of MT7988 WO firmware", " - bpf, test_run: Fix LIVE_FRAME frame update after a page has been recycled", " - iomap: improve shared block detection in iomap_unshare_iter", " - iomap: don't bother unsharing delalloc extents", " - iomap: share iomap_unshare_iter predicate code with fsdax", " - fsdax: remove zeroing code from dax_unshare_iter", " - iomap: turn iomap_want_unshare_iter into an inline function", " - kasan: Fix Software Tag-Based KASAN with GCC", " - firmware: arm_sdei: Fix the input parameter of cpuhp_remove_state()", " - afs: Fix missing subdir edit when renamed between parent dirs", " - gpio: sloppy-logic-analyzer: Check for error code from devm_mutex_init()", " call", " - smb: client: fix parsing of device numbers", " - smb: client: set correct device number on nfs reparse points", " - drm/mediatek: ovl: Remove the color format comment for ovl_fmt_convert()", " - drm/mediatek: Fix color format MACROs in OVL", " - drm/mediatek: Fix get efuse issue for MT8188 DPTX", " - drm/mediatek: Use cmdq_pkt_create() and cmdq_pkt_destroy()", " - cxl/events: Fix Trace DRAM Event Record", " - PCI: Fix pci_enable_acs() support for the ACS quirks", " - nvme: module parameter to disable pi with offsets", " - drm/panthor: Fix firmware initialization on systems with a page size > 4k", " - drm/panthor: Fail job creation when the group is dead", " - drm/panthor: Report group as timedout when we fail to properly suspend", " - fs/ntfs3: Fix warning possible deadlock in ntfs_set_state", " - fs/ntfs3: Stale inode instead of bad", " - rust: device: change the from_raw() function", " - scsi: scsi_transport_fc: Allow setting rport state to current state", " - cifs: Improve creating native symlinks pointing to directory", " - cifs: Fix creating native symlinks pointing to current or parent directory", " - ACPI: resource: Fold Asus Vivobook Pro N6506M* DMI quirks together", " - powercap: intel_rapl_msr: Add PL4 support for Arrowlake-U", " - thermal: intel: int340x: processor: Remove MMIO RAPL CPU hotplug support", " - thermal: intel: int340x: processor: Add MMIO RAPL PL4 support", " - net: amd: mvme147: Fix probe banner message", " - NFS: remove revoked delegation from server's delegation list", " - misc: sgi-gru: Don't disable preemption in GRU driver", " - NFSD: Initialize struct nfsd4_copy earlier", " - NFSD: Never decrement pending_async_copies on error", " - ALSA: usb-audio: Add quirks for Dell WD19 dock", " - wifi: rtlwifi: rtl8192du: Don't claim USB ID 0bda:8171", " - usbip: tools: Fix detach_port() invalid port error path", " - usb: phy: Fix API devm_usb_put_phy() can not release the phy", " - usb: typec: fix unreleased fwnode_handle in typec_port_register_altmodes()", " - usb: typec: tcpm: restrict SNK_WAIT_CAPABILITIES_TIMEOUT transitions to non", " self-powered devices", " - usb: typec: qcom-pmic-typec: use fwnode_handle_put() to release fwnodes", " - usb: typec: qcom-pmic-typec: fix missing fwnode removal in error path", " - xhci: Fix Link TRB DMA in command ring stopped completion event", " - xhci: Use pm_runtime_get to prevent RPM on unsupported systems", " - Revert \"driver core: Fix uevent_show() vs driver detach race\"", " - dt-bindings: iio: adc: ad7380: fix ad7380-4 reference supply", " - iio: light: veml6030: fix microlux value calculation", " - RISC-V: ACPI: fix early_ioremap to early_memremap", " - tools/mm: -Werror fixes in page-types/slabinfo", " - mm: shrinker: avoid memleak in alloc_shrinker_info", " - firmware: microchip: auto-update: fix poll_complete() to not report spurious", " timeout errors", " - thunderbolt: Honor TMU requirements in the domain when setting TMU mode", " - soc: qcom: pmic_glink: Handle GLINK intent allocation rejections", " - cxl/port: Fix CXL port initialization order when the subsystem is built-in", " - mmc: sdhci-pci-gli: GL9767: Fix low power mode on the set clock function", " - mmc: sdhci-pci-gli: GL9767: Fix low power mode in the SD Express process", " - block: fix sanity checks in blk_rq_map_user_bvec", " - phy: freescale: imx8m-pcie: Do CMN_RST just before PHY PLL lock check", " - btrfs: merge btrfs_orig_bbio_end_io() into btrfs_bio_end_io()", " - riscv: vdso: Prevent the compiler from inserting calls to memset()", " - Input: edt-ft5x06 - fix regmap leak when probe fails", " - ALSA: hda/realtek: Limit internal Mic boost on Dell platform", " - riscv: efi: Set NX compat flag in PE/COFF header", " - riscv: Use '%u' to format the output of 'cpu'", " - riscv: Remove unused GENERATING_ASM_OFFSETS", " - riscv: Remove duplicated GET_RM", " - cxl/port: Fix cxl_bus_rescan() vs bus_rescan_devices()", " - cxl/acpi: Ensure ports ready at cxl_acpi_probe() return", " - posix-cpu-timers: Clear TICK_DEP_BIT_POSIX_TIMER on clone", " - tpm: Return tpm2_sessions_init() when null key creation fails", " - tpm: Rollback tpm2_load_null()", " - drm/amdgpu/smu13: fix profile reporting", " - tpm: Lazily flush the auth session", " - mei: use kvmalloc for read buffer", " - x86/traps: Enable UBSAN traps on x86", " - x86/traps: move kmsan check after instrumentation_begin", " - accel/ivpu: Fix NOC firewall interrupt handling", " - ALSA: hda/realtek: Fix headset mic on TUXEDO Gemini 17 Gen3", " - ALSA: hda/realtek: Fix headset mic on TUXEDO Stellaris 16 Gen6 mb1", " - nvme: re-fix error-handling for io_uring nvme-passthrough", " - kasan: remove vmalloc_percpu test", " - drm/tests: helpers: Add helper for drm_display_mode_from_cea_vic()", " - drm/xe: Fix register definition order in xe_regs.h", " - drm/xe: Kill regs/xe_sriov_regs.h", " - drm/xe: Add mmio read before GGTT invalidate", " - drm/xe: Don't short circuit TDR on jobs not started", " - btrfs: fix extent map merging not happening for adjacent extents", " - btrfs: fix defrag not merging contiguous extents due to merged extent maps", " - gpiolib: fix debugfs newline separators", " - gpiolib: fix debugfs dangling chip separator", " - vmscan,migrate: fix page count imbalance on node stats when demoting pages", " - mm, mmap: limit THP alignment of anonymous mappings to PMD-aligned sizes", " - Input: fix regression when re-registering input handlers", " - mm: multi-gen LRU: ignore non-leaf pmd_young for force_scan=true", " - mm: multi-gen LRU: remove MM_LEAF_OLD and MM_NONLEAF_TOTAL stats", " - mm: shrink skip folio mapped by an exiting process", " - mm: multi-gen LRU: use {ptep,pmdp}_clear_young_notify()", " - riscv: dts: starfive: Update ethernet phy0 delay parameter values for Star64", " - riscv: dts: starfive: disable unused csi/camss nodes", " - arm64: dts: qcom: msm8939: revert use of APCS mbox for RPM", " - arm64: dts: qcom: x1e80100-yoga-slim7x: fix nvme regulator boot glitch", " - arm64: dts: qcom: x1e80100: Fix up BAR spaces", " - arm64: dts: qcom: x1e80100-vivobook-s15: fix nvme regulator boot glitch", " - arm64: dts: qcom: x1e80100: fix PCIe4 interconnect", " - arm64: dts: qcom: x1e80100-qcp: fix nvme regulator boot glitch", " - arm64: dts: qcom: x1e80100-crd: fix nvme regulator boot glitch", " - arm64: dts: qcom: x1e80100: Add Broadcast_AND region in LLCC block", " - arm64: dts: qcom: x1e80100: fix PCIe4 and PCIe6a PHY clocks", " - drm/xe/xe2hpg: Add Wa_15016589081", " - drm/amdgpu/swsmu: fix ordering for setting workload_mask", " - drm/amdgpu/swsmu: default to fullscreen 3D profile for dGPUs", " - fs/ntfs3: Sequential field availability check in mi_enum_attr()", " - drm/amdgpu: handle default profile on on devices without fullscreen 3D", " - MIPS: export __cmpxchg_small()", " - RISC-V: disallow gcc + rust builds", " - [Config] updateconfigs after disabling rust with gcc on riscv", " - rcu/kvfree: Add kvfree_rcu_barrier() API", " - rcu/kvfree: Refactor kvfree_rcu_queue_batch()", " - Linux 6.11.7", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50212", " - lib: alloc_tag_module_unload must wait for pending kfree_rcu calls", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53046", " - arm64: dts: imx8ulp: correct the flexspi compatible string", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53052", " - io_uring/rw: fix missing NOWAIT check for O_DIRECT start write", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50213", " - drm/tests: hdmi: Fix memory leaks in drm_display_mode_from_cea_vic()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50214", " - drm/connector: hdmi: Fix memory leak in drm_display_mode_from_cea_vic()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50215", " - nvmet-auth: assign dh_key to NULL after kfree_sensitive", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50216", " - xfs: fix finding a last resort AG in xfs_filestream_pick_ag", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50217", " - btrfs: fix use-after-free of block device file in", " __btrfs_free_extra_devids()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53043", " - mctp i2c: handle NULL header address", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50303", " - resource,kexec: walk_system_ram_res_rev must retain resource flags", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50218", " - ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50219", " - mm/page_alloc: let GFP_ATOMIC order-0 allocs access highatomic reserves", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50263", " - fork: only invoke khugepaged, ksm hooks if no error", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50220", " - fork: do not invoke uffd on fork if error occurs", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53047", " - mptcp: init: protect sched with rcu_read_lock", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50221", " - drm/amd/pm: Vangogh: Fix kernel memory out of bounds write", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50222", " - iov_iter: fix copy_page_from_iter_atomic() if KMAP_LOCAL_FORCE_MAP", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50223", " - sched/numa: Fix the potential null pointer dereference in task_numa_work()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53053", " - scsi: ufs: core: Fix another deadlock during RTC update", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53075", " - riscv: Prevent a bad reference count on CPU nodes", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50224", " - spi: spi-fsl-dspi: Fix crash when not using GPIO chip select", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50225", " - btrfs: fix error propagation of split bios", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53054", " - cgroup/bpf: use a dedicated workqueue for cgroup bpf destruction", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50226", " - cxl/port: Fix use-after-free, permit out-of-order decoder shutdown", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50227", " - thunderbolt: Fix KASAN reported stack out-of-bounds read in", " tb_retimer_scan()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50228", " - mm: shmem: fix data-race in shmem_getattr()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50229", " - nilfs2: fix potential deadlock with newly created symlinks", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50230", " - nilfs2: fix kernel bug due to missing clearing of checked flag", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50231", " - iio: gts-helper: Fix memory leaks in iio_gts_build_avail_scale_table()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53076", " - iio: gts-helper: Fix memory leaks for the error path of", " iio_gts_build_avail_scale_table()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50232", " - iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50233", " - staging: iio: frequency: ad9832: fix division by zero in", " ad9832_calc_freqreg()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53055", " - wifi: iwlwifi: mvm: fix 6 GHz scan construction", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50234", " - wifi: iwlegacy: Clear stale interrupts before resuming device", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50235", " - wifi: cfg80211: clear wdev->cqm_config pointer on free", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50236", " - wifi: ath10k: Fix memory leak in management tx", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50237", " - wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50238", " - phy: qcom: qmp-usbc: fix NULL-deref on runtime suspend", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50239", " - phy: qcom: qmp-usb-legacy: fix NULL-deref on runtime suspend", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50240", " - phy: qcom: qmp-usb: fix NULL-deref on runtime suspend", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53077", " - rpcrdma: Always release the rpcrdma_device's xa_array", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50242", " - fs/ntfs3: Additional check in ntfs_file_release", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50243", " - fs/ntfs3: Fix general protection fault in run_is_mapped_full", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50244", " - fs/ntfs3: Additional check in ni_clear()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50245", " - fs/ntfs3: Fix possible deadlock in mi_read", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50246", " - fs/ntfs3: Add rough attr alloc_size check", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50247", " - fs/ntfs3: Check if more than chunk-size bytes are written", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50248", " - ntfs3: Add bounds checking to mi_enum_attr()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53078", " - drm/tegra: Fix NULL vs IS_ERR() check in probe()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53056", " - drm/mediatek: Fix potential NULL dereference in mtk_crtc_destroy()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50249", " - ACPI: CPPC: Make rmw_lock a raw_spin_lock", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50250", " - fsdax: dax_unshare_iter needs to copy entire blocks", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50251", " - netfilter: nft_payload: sanitize offset and length before calling", " skb_checksum()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50252", " - mlxsw: spectrum_ipip: Fix memory leak when changing remote IPv6 address", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50253", " - bpf: Check the validity of nr_words in bpf_iter_bits_new()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50254", " - bpf: Free dynamically allocated bits in bpf_iter_bits_destroy()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50255", " - Bluetooth: hci: fix null-ptr-deref in hci_read_supported_codecs", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50256", " - netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50257", " - netfilter: Fix use-after-free in get_info()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50258", " - net: fix crash when config small gso_max_size/gso_ipv4_max_size", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50262", " - bpf: Fix out-of-bounds write in trie_get_next_key()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53044", " - net/sched: sch_api: fix xa_insert() error path in tcf_block_get_ext()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50259", " - netdevsim: Add trailing zero to terminate the string in", " nsim_nexthop_bucket_activity_write()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50304", " - ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53042", " - ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_init_flow()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53048", " - ice: fix crash on probe for DPLL enabled E810 LOM", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53058", " - net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50260", " - sock_map: fix a NULL pointer dereference in sock_map_link_update_prog()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53045", " - ASoC: dapm: fix bounds checker error in dapm_widget_list_create", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50261", " - macsec: Fix use-after-free while sending the offloading packet", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53059", " - wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53074", " - wifi: iwlwifi: mvm: don't leak a link on AP removal", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53049", " - slub/kunit: fix a WARNING due to unwrapped __kmalloc_cache_noprof", "", " * Oracular update: v6.11.6 upstream stable release (LP: #2091386)", " - bpf: Use raw_spinlock_t in ringbuf", " - iio: accel: bma400: Fix uninitialized variable field_value in tap event", " handling.", " - reset: starfive: jh71x0: Fix accessing the empty member on JH7110 SoC", " - bpf: sync_linked_regs() must preserve subreg_def", " - bpf: Make sure internal and UAPI bpf_redirect flags don't overlap", " - irqchip/riscv-imsic: Fix output text of base address", " - bpf: devmap: provide rxq after redirect", " - cpufreq/amd-pstate: Fix amd_pstate mode switch on shared memory systems", " - lib/Kconfig.debug: fix grammar in RUST_BUILD_ASSERT_ALLOW", " - bpf: Fix memory leak in bpf_core_apply", " - RDMA/bnxt_re: Fix a possible memory leak", " - RDMA/bnxt_re: Fix incorrect AVID type in WQE structure", " - RDMA/bnxt_re: Add a check for memory allocation", " - x86/resctrl: Avoid overflow in MB settings in bw_validate()", " - ARM: dts: bcm2837-rpi-cm3-io3: Fix HDMI hpd-gpio pin", " - clk: rockchip: fix finding of maximum clock ID", " - bpf: Check the remaining info_cnt before repeating btf fields", " - bpf: fix unpopulated name_len field in perf_event link info", " - selftests/bpf: fix perf_event link info name_len assertion", " - riscv, bpf: Fix possible infinite tailcall when CONFIG_CFI_CLANG is enabled", " - s390/pci: Handle PCI error codes other than 0x3a", " - bpf: fix kfunc btf caching for modules", " - iio: frequency: {admv4420,adrf6780}: format Kconfig entries", " - iio: frequency: admv4420: fix missing select REMAP_SPI in Kconfig", " - drm/vmwgfx: Handle possible ENOMEM in vmw_stdu_connector_atomic_check", " - selftests/bpf: Fix cross-compiling urandom_read", " - bpf: Fix unpopulated path_size when uprobe_multi fields unset", " - sched/core: Disable page allocation in task_tick_mm_cid()", " - ALSA: hda/cs8409: Fix possible NULL dereference", " - firmware: arm_scmi: Fix the double free in scmi_debugfs_common_setup()", " - RDMA/cxgb4: Fix RDMA_CM_EVENT_UNREACHABLE error for iWARP", " - RDMA/irdma: Fix misspelling of \"accept*\"", " - RDMA/srpt: Make slab cache names unique", " - elevator: do not request_module if elevator exists", " - elevator: Remove argument from elevator_find_get", " - ipv4: give an IPv4 dev to blackhole_netdev", " - net: sparx5: fix source port register when mirroring", " - RDMA/bnxt_re: Fix the max CQ WQEs for older adapters", " - RDMA/bnxt_re: Fix out of bound check", " - RDMA/bnxt_re: Fix incorrect dereference of srq in async event", " - RDMA/bnxt_re: Return more meaningful error", " - RDMA/bnxt_re: Avoid CPU lockups due fifo occupancy check loop", " - RDMA/bnxt_re: Get the toggle bits from SRQ events", " - RDMA/bnxt_re: Change the sequence of updating the CQ toggle value", " - RDMA/bnxt_re: Fix a bug while setting up Level-2 PBL pages", " - RDMA/bnxt_re: Fix the GID table length", " - accel/qaic: Fix the for loop used to walk SG table", " - drm/panel: himax-hx83102: Adjust power and gamma to optimize brightness", " - drm/msm/dpu: make sure phys resources are properly initialized", " - drm/msm/dpu: move CRTC resource assignment to dpu_encoder_virt_atomic_check", " - drm/msm/dpu: check for overflow in _dpu_crtc_setup_lm_bounds()", " - drm/msm/dsi: improve/fix dsc pclk calculation", " - drm/msm/dsi: fix 32-bit signed integer extension in pclk_rate calculation", " - drm/msm: Avoid NULL dereference in msm_disp_state_print_regs()", " - drm/msm: Allocate memory for disp snapshot with kvzalloc()", " - firmware: arm_scmi: Queue in scmi layer for mailbox implementation", " - net/smc: Fix memory leak when using percpu refs", " - [PATCH} hwmon: (jc42) Properly detect TSE2004-compliant devices again", " - net: usb: usbnet: fix race in probe failure", " - net: stmmac: dwmac-tegra: Fix link bring-up sequence", " - octeontx2-af: Fix potential integer overflows on integer shifts", " - ring-buffer: Fix reader locking when changing the sub buffer order", " - drm/amd/amdgpu: Fix double unlock in amdgpu_mes_add_ring", " - macsec: don't increment counters for an unrelated SA", " - netdevsim: use cond_resched() in nsim_dev_trap_report_work()", " - net: ethernet: aeroflex: fix potential memory leak in", " greth_start_xmit_gbit()", " - net/smc: Fix searching in list of known pnetids in smc_pnet_add_pnetid", " - net: xilinx: axienet: fix potential memory leak in axienet_start_xmit()", " - net: ethernet: rtsn: fix potential memory leak in rtsn_start_xmit()", " - bpf: Fix truncation bug in coerce_reg_to_size_sx()", " - net: systemport: fix potential memory leak in bcm_sysport_xmit()", " - irqchip/renesas-rzg2l: Fix missing put_device", " - drm/msm/dpu: Don't always set merge_3d pending flush", " - drm/msm/dpu: don't always program merge_3d block", " - net: bcmasp: fix potential memory leak in bcmasp_xmit()", " - drm/msm/a6xx+: Insert a fence wait before SMMU table update", " - tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink().", " - net: dsa: mv88e6xxx: Fix the max_vid definition for the MV88E6361", " - genetlink: hold RCU in genlmsg_mcast()", " - ravb: Remove setting of RX software timestamp", " - net: ravb: Only advertise Rx/Tx timestamps if hardware supports it", " - net: dsa: vsc73xx: fix reception from VLAN-unaware bridges", " - scsi: target: core: Fix null-ptr-deref in target_alloc_device()", " - smb: client: fix possible double free in smb2_set_ea()", " - smb: client: fix OOBs when building SMB2_IOCTL request", " - usb: typec: altmode should keep reference to parent", " - s390: Initialize psw mask in perf_arch_fetch_caller_regs()", " - drm/xe: fix unbalanced rpm put() with fence_fini()", " - drm/xe: fix unbalanced rpm put() with declare_wedged()", " - drm/xe: Take job list lock in xe_sched_add_pending_job", " - drm/xe: Don't free job in TDR", " - drm/xe: Use bookkeep slots for external BO's in exec IOCTL", " - bpf: Fix link info netfilter flags to populate defrag flag", " - Bluetooth: bnep: fix wild-memory-access in proto_unregister", " - vmxnet3: Fix packet corruption in vmxnet3_xdp_xmit_frame", " - net: ethernet: mtk_eth_soc: fix memory corruption during fq dma init", " - net/mlx5: Check for invalid vector index on EQ creation", " - net/mlx5: Fix command bitmask initialization", " - net/mlx5: Unregister notifier on eswitch init failure", " - net/mlx5e: Don't call cleanup on profile rollback failure", " - bpf, sockmap: SK_DROP on attempted redirects of unsupported af_vsock", " - vsock: Update rx_bytes on read_skb()", " - vsock: Update msg_count on read_skb()", " - bpf, vsock: Drop static vsock_bpf_prot initialization", " - riscv, bpf: Make BPF_CMPXCHG fully ordered", " - nvme-pci: fix race condition between reset and nvme_dev_disable()", " - bpf: Fix iter/task tid filtering", " - bpf: Fix incorrect delta propagation between linked registers", " - bpf: Fix print_reg_state's constant scalar dump", " - cdrom: Avoid barrier_nospec() in cdrom_ioctl_media_changed()", " - fgraph: Allocate ret_stack_list with proper size", " - mm: shmem: rename shmem_is_huge() to shmem_huge_global_enabled()", " - mm: shmem: move shmem_huge_global_enabled() into", " shmem_allowable_huge_orders()", " - mm: huge_memory: add vma_thp_disabled() and thp_disabled_by_hw()", " - mm: don't install PMD mappings when THPs are disabled by the hw/process/vma", " - iio: adc: ti-lmp92064: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - xhci: dbgtty: remove kfifo_out() wrapper", " - xhci: dbgtty: use kfifo from tty_port struct", " - xhci: dbc: honor usb transfer size boundaries.", " - uprobe: avoid out-of-bounds memory access of fetching args", " - drm/vboxvideo: Replace fake VLA at end of vbva_mouse_pointer_shape with real", " VLA", " - ASoC: amd: yc: Add quirk for HP Dragonfly pro one", " - ASoC: codecs: lpass-rx-macro: add missing CDC_RX_BCL_VBAT_RF_PROC2 to", " default regs values", " - ASoC: fsl_sai: Enable 'FIFO continue on error' FCONT bit", " - arm64: Force position-independent veneers", " - udf: refactor udf_current_aext() to handle error", " - udf: refactor udf_next_aext() to handle error", " - udf: refactor inode_bmap() to handle error", " - udf: fix uninit-value use in udf_get_fileshortad", " - ASoC: qcom: sm8250: add qrb4210-rb2-sndcard compatible string", " - fsnotify: Avoid data race between fsnotify_recalc_mask() and", " fsnotify_object_watched()", " - drm/xe/mcr: Use Xe2_LPM steering tables for Xe2_HPM", " - cifs: Validate content of NFS reparse point buffer", " - LoongArch: Don't crash in stack_top() for tasks without vDSO", " - objpool: fix choosing allocation for percpu slots", " - jfs: Fix sanity check in dbMount", " - tracing/probes: Fix MAX_TRACE_ARGS limit handling", " - tracing: Consider the NULL character when validating the event length", " - xfrm: extract dst lookup parameters into a struct", " - xfrm: respect ip protocols rules criteria when performing dst lookups", " - xfrm: validate new SA's prefixlen using SA family when sel.family is unset", " - netfilter: bpf: must hold reference on net namespace", " - net: pse-pd: Fix out of bound for loop", " - net/sun3_82586: fix potential memory leak in sun3_82586_send_packet()", " - be2net: fix potential memory leak in be_xmit()", " - net: plip: fix break; causing plip to never transmit", " - bnxt_en: replace ptp_lock with irqsave variant", " - octeon_ep: Implement helper for iterating packets in Rx queue", " - octeon_ep: Add SKB allocation failures handling in __octep_oq_process_rx()", " - net: dsa: mv88e6xxx: Fix error when setting port policy on mv88e6393x", " - bpf, arm64: Fix address emission with tag-based KASAN enabled", " - fsl/fman: Save device references taken in mac_probe()", " - fsl/fman: Fix refcount handling of fman-related devices", " - net: wwan: fix global oob in wwan_rtnl_policy", " - net: fix races in netdev_tx_sent_queue()/dev_watchdog()", " - virtio_net: fix integer overflow in stats", " - mlxsw: spectrum_router: fix xa_store() error checking", " - net: usb: usbnet: fix name regression", " - bpf: Preserve param->string when parsing mount options", " - bpf: Add MEM_WRITE attribute", " - bpf: Fix overloading of MEM_UNINIT's meaning", " - bpf: Remove MEM_UNINIT from skb/xdp MTU helpers", " - net/sched: act_api: deny mismatched skip_sw/skip_hw flags for actions", " created by classifiers", " - net: sched: fix use-after-free in taprio_change()", " - net: sched: use RCU read-side critical section in taprio_dump()", " - r8169: avoid unsolicited interrupts", " - posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime()", " - Bluetooth: hci_core: Disable works on hci_unregister_dev", " - Bluetooth: SCO: Fix UAF on sco_sock_timeout", " - Bluetooth: ISO: Fix UAF on iso_sock_timeout", " - bpf,perf: Fix perf_event_detach_bpf_prog error handling", " - bpf: fix do_misc_fixups() for bpf_get_branch_snapshot()", " - net: dsa: microchip: disable EEE for KSZ879x/KSZ877x/KSZ876x", " - net: dsa: mv88e6xxx: group cycle counter coefficients", " - net: dsa: mv88e6xxx: read cycle counter period from hardware", " - net: dsa: mv88e6xxx: support 4000ps cycle counter period", " - bpf: Add the missing BPF_LINK_TYPE invocation for sockmap", " - ASoC: dt-bindings: davinci-mcasp: Fix interrupts property", " - ASoC: dt-bindings: davinci-mcasp: Fix interrupt properties", " - ASoC: loongson: Fix component check failed on FDT systems", " - ASoC: topology: Bump minimal topology ABI version", " - ASoC: max98388: Fix missing increment of variable slot_found", " - ASoC: rsnd: Fix probe failure on HiHope boards due to endpoint parsing", " - PCI: Hold rescan lock while adding devices during host probe", " - fs: pass offset and result to backing_file end_write() callback", " - fuse: update inode size after extending passthrough write", " - ASoC: fsl_micfil: Add a flag to distinguish with different volume control", " types", " - ALSA: firewire-lib: Avoid division by zero in apply_constraint_to_size()", " - fbdev: wm8505fb: select CONFIG_FB_IOMEM_FOPS", " - powercap: dtpm_devfreq: Fix error check against dev_pm_qos_add_request()", " - nfsd: cancel nfsd_shrinker_work using sync mode in nfs4_state_shutdown_net", " - ALSA: hda/realtek: Update default depop procedure", " - smb: client: Handle kstrdup failures for passwords", " - cifs: fix warning when destroy 'cifs_io_request_pool'", " - PCI/pwrctl: Add WCN6855 support", " - PCI/pwrctl: Abandon QCom WCN probe on pre-pwrseq device-trees", " - cpufreq: CPPC: fix perf_to_khz/khz_to_perf conversion exception", " - btrfs: qgroup: set a more sane default value for subtree drop threshold", " - btrfs: clear force-compress on remount when compress mount option is given", " - btrfs: fix passing 0 to ERR_PTR in btrfs_search_dir_index_item()", " - perf/x86/rapl: Fix the energy-pkg event for AMD CPUs", " - btrfs: reject ro->rw reconfiguration if there are hard ro requirements", " - btrfs: zoned: fix zone unusable accounting for freed reserved extent", " - btrfs: fix read corruption due to race with extent map merging", " - drm/amd: Guard against bad data for ATIF ACPI method", " - ACPI: resource: Add LG 16T90SP to irq1_level_low_skip_override[]", " - ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context", " - ACPI: button: Add DMI quirk for Samsung Galaxy Book2 to fix initial lid", " detection issue", " - nilfs2: fix kernel bug due to missing clearing of buffer delay flag", " - fs: don't try and remove empty rbtree node", " - xfs: don't fail repairs on metadata files with no attr fork", " - openat2: explicitly return -E2BIG for (usize > PAGE_SIZE)", " - KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory", " - KVM: arm64: Unregister redistributor for failed vCPU creation", " - KVM: arm64: Fix shift-out-of-bounds bug", " - KVM: arm64: Don't eagerly teardown the vgic on init error", " - firewire: core: fix invalid port index for parent device", " - x86/lam: Disable ADDRESS_MASKING in most cases", " - [Config] updateconfigs to disable ADDRESS_MASKING", " - x86/sev: Ensure that RMP table fixups are reserved", " - ALSA: hda/tas2781: select CRC32 instead of CRC32_SARWATE", " - ALSA: hda/realtek: Add subwoofer quirk for Acer Predator G9-593", " - LoongArch: Get correct cores_per_package for SMT systems", " - LoongArch: Enable IRQ if do_ale() triggered in irq-enabled context", " - LoongArch: Make KASAN usable for variable cpu_vabits", " - xfrm: fix one more kernel-infoleak in algo dumping", " - hv_netvsc: Fix VF namespace also in synthetic NIC NETDEV_REGISTER event", " - md/raid10: fix null ptr dereference in raid10_size()", " - drm/bridge: Fix assignment of the of_node of the parent to aux bridge", " - drm/amd/display: Disable PSR-SU on Parade 08-01 TCON too", " - platform/x86/intel/pmc: Fix pmc_core_iounmap to call iounmap for valid", " addresses", " - fgraph: Fix missing unlock in register_ftrace_graph()", " - fgraph: Change the name of cpuhp state to \"fgraph:online\"", " - net: phy: dp83822: Fix reset pin definitions", " - nfsd: fix race between laundromat and free_stateid", " - drm/amd/display: temp w/a for DP Link Layer compliance", " - ata: libata: Set DID_TIME_OUT for commands that actually timed out", " - ASoC: SOF: Intel: hda-loader: do not wait for HDaudio IOC", " - ASoC: SOF: Intel: hda: Handle prepare without close for non-HDA DAI's", " - ASoC: SOF: Intel: hda: Always clean up link DMA during stop", " - ASoC: SOF: ipc4-topology: Do not set ALH node_id for aggregated DAIs", " - ASoC: dapm: avoid container_of() to get component", " - ASoC: qcom: sc7280: Fix missing Soundwire runtime stream alloc", " - ASoC: qcom: sdm845: add missing soundwire runtime stream alloc", " - ASoC: qcom: Fix NULL Dereference in asoc_qcom_lpass_cpu_platform_probe()", " - Revert \" fs/9p: mitigate inode collisions\"", " - Revert \"fs/9p: remove redundant pointer v9ses\"", " - Revert \"fs/9p: fix uaf in in v9fs_stat2inode_dotl\"", " - Revert \"fs/9p: simplify iget to remove unnecessary paths\"", " - soundwire: intel_ace2x: Send PDI stream number during prepare", " - x86: support user address masking instead of non-speculative conditional", " - x86: fix whitespace in runtime-const assembler output", " - x86: fix user address masking non-canonical speculation issue", " - platform/x86: dell-wmi: Ignore suspend notifications", " - ACPI: PRM: Clean up guid type in struct prm_handler_info", " - ASoC: qcom: Select missing common Soundwire module code on SDM845", " - Linux 6.11.6", "", " * ovs/linuxbridge jobs running on ubuntu jammy broken with latest kernel", " 5.15.0-127.137 (LP: #2091990)", " - netfilter: xtables: fix typo causing some targets not to load on IPv6", "", " * By always inlining _compound_head(), clone() sees 3%+ performance increase", " (LP: #2089327)", " - mm: always inline _compound_head() with", " CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP=y", "", " * Keyboard backlight controls do not work on Asus ROG Zephyrus GA503RM in", " Oracular (LP: #2089113)", " - hid-asus: use hid for brightness control on keyboard", "", " * Random flickering with Intel i915 (Comet Lake and Kaby Lake) on Linux 6.8+", " (LP: #2086587)", " - SAUCE: iommu/intel: disable DMAR for KBL and CML integrated gfx", "", " * Add list of source files to linux-buildinfo (LP: #2086606)", " - [Packaging] Sort build dependencies alphabetically", " - [Packaging] Add list of used source files to buildinfo package", "", " * asus: Fix thermal profile initialization on Lunar Lake (LP: #2085950)", " - platform/x86: asus-wmi: Fix thermal profile initialization", "", " * drm/xe: Fix LNL getting wedged after idling (LP: #2085944)", " - drm/xe/guc/ct: Flush g2h worker in case of g2h response timeout", "", " * UFS: uspi->s_3apb UBSAN: shift-out-of-bounds (LP: #2087853)", " - ufs: ufs_sb_private_info: remove unused s_{2, 3}apb fields", "", " * Mute/mic LEDs don't function on HP EliteBook 645 G10 (LP: #2087983)", " - ALSA: hda/realtek: fix mute/micmute LEDs for a HP EliteBook 645 G10", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152)", " - ALSA: scarlett2: Add error check after retrieving PEQ filter values", " - ALSA: hda/conexant - Fix audio routing for HP EliteOne 1000 G2", " - net: enetc: remove xdp_drops statistic from enetc_xdp_drop()", " - net: enetc: block concurrent XDP transmissions during ring reconfiguration", " - net: enetc: disable Tx BD rings after they are empty", " - net: enetc: disable NAPI after all rings are disabled", " - net: enetc: add missing static descriptor and inline keyword", " - udp: Compute L4 checksum as usual when not segmenting the skb", " - arm64: dts: marvell: cn9130-sr-som: fix cp0 mdio pin numbers", " - arm64: probes: Fix simulate_ldr*_literal()", " - net: macb: Avoid 20s boot delay by skipping MDIO bus registration for fixed-", " link PHY", " - selftests: mptcp: join: test for prohibited MPC to port-based endp", " - fat: fix uninitialized variable", " - mm: khugepaged: fix the arguments order in khugepaged_collapse_file trace", " point", " - net: fec: Move `fec_ptp_read()` to the top of the file", " - net: fec: Remove duplicated code", " - mptcp: prevent MPC handshake on port-based signal endpoints", " - s390/sclp: Deactivate sclp after all its users", " - s390/sclp_vt220: Convert newlines to CRLF instead of LFCR", " - KVM: s390: gaccess: Check if guest address is in memslot", " - KVM: s390: Change virtual to physical address access in diag 0x258 handler", " - x86/cpufeatures: Define X86_FEATURE_AMD_IBPB_RET", " - x86/cpufeatures: Add a IBPB_NO_RET BUG flag", " - x86/entry: Have entry_ibpb() invalidate return predictions", " - x86/bugs: Skip RSB fill at VMEXIT", " - x86/bugs: Do not use UNTRAIN_RET with IBPB on entry", " - fgraph: Use CPU hotplug mechanism to initialize idle shadow stacks", " - Input: xpad - add support for 8BitDo Ultimate 2C Wireless Controller", " - io_uring/sqpoll: close race on waiting for sqring entries", " - selftest: hid: add the missing tests directory", " - Input: xpad - add support for MSI Claw A1M", " - scsi: mpi3mr: Validate SAS port assignments", " - scsi: ufs: core: Fix the issue of ICU failure", " - scsi: ufs: core: Requeue aborted request", " - drm/i915/dp_mst: Handle error during DSC BW overhead/slice calculation", " - drm/i915/dp_mst: Don't require DSC hblank quirk for a non-DSC compatible", " mode", " - drm/xe/xe_sync: initialise ufence.signalled", " - drm/xe/ufence: ufence can be signaled right after wait_woken", " - drm/vmwgfx: Cleanup kms setup without 3d", " - drm/vmwgfx: Handle surface check failure correctly", " - drm/amdgpu/mes: fix issue of writing to the same log buffer from 2 MES pipes", " - drm/amdgpu/smu13: always apply the powersave optimization", " - drm/amdgpu/swsmu: Only force workload setup on init", " - drm/amdgpu: prevent BO_HANDLES error from being overwritten", " - iio: dac: ad5770r: add missing select REGMAP_SPI in Kconfig", " - iio: dac: ltc1660: add missing select REGMAP_SPI in Kconfig", " - iio: dac: stm32-dac-core: add missing select REGMAP_MMIO in Kconfig", " - iio: adc: ti-ads8688: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: hid-sensors: Fix an error handling path in", " _hid_sensor_set_report_latency()", " - iio: light: veml6030: fix ALS sensor resolution", " - iio: light: opt3001: add missing full-scale range value", " - iio: amplifiers: ada4250: add missing select REGMAP_SPI in Kconfig", " - iio: frequency: adf4377: add missing select REMAP_SPI in Kconfig", " - iio: chemical: ens160: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: light: bu27008: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: magnetometer: af8133j: add missing select IIO_(TRIGGERED_)BUFFER in", " Kconfig", " - iio: resolver: ad2s1210 add missing select REGMAP in Kconfig", " - iio: pressure: bm1390: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: dac: ad5766: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: proximity: mb1232: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: dac: ad3552r: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: adc: ti-lmp92064: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: adc: ti-lmp92064: add missing select REGMAP_SPI in Kconfig", " - iio: adc: ti-ads124s08: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: resolver: ad2s1210: add missing select (TRIGGERED_)BUFFER in Kconfig", " - iio: adc: ad7944: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: accel: kx022a: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - Bluetooth: Remove debugfs directory on module init failure", " - Bluetooth: btusb: Fix not being able to reconnect after suspend", " - Bluetooth: btusb: Fix regression with fake CSR controllers 0a12:0001", " - xhci: Fix incorrect stream context type macro", " - xhci: Mitigate failed set dequeue pointer commands", " - USB: serial: option: add support for Quectel EG916Q-GL", " - USB: serial: option: add Telit FN920C04 MBIM compositions", " - usb: typec: qcom-pmic-typec: fix sink status being overwritten with RP_DEF", " - usb: gadget: f_uac2: fix return value for UAC2_ATTRIBUTE_STRING store", " - usb: dwc3: Wait for EndXfer completion before restoring GUSB2PHYCFG", " - usb: dwc3: core: Fix system suspend on TI AM62 platforms", " - misc: microchip: pci1xxxx: add support for NVMEM_DEVID_AUTO for EEPROM", " device", " - misc: microchip: pci1xxxx: add support for NVMEM_DEVID_AUTO for OTP device", " - serial: imx: Update mctrl old_status on RTSD interrupt", " - x86/resctrl: Annotate get_mem_config() functions as __init", " - x86/CPU/AMD: Only apply Zenbleed fix for Zen2 during late microcode load", " - x86/entry_32: Do not clobber user EFLAGS.ZF", " - irqchip/sifive-plic: Unmask interrupt in plic_irq_enable()", " - irqchip/sifive-plic: Return error code on failure", " - serial: qcom-geni: fix polled console initialisation", " - serial: qcom-geni: revert broken hibernation support", " - serial: qcom-geni: fix shutdown race", " - serial: qcom-geni: fix dma rx cancellation", " - serial: qcom-geni: fix receiver enable", " - mm: vmscan.c: fix OOM on swap stress test", " - ALSA: hda/conexant - Use cached pin control for Node 0x1d on HP EliteOne", " 1000 G2", " - Linux 6.11.5", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50192", " - irqchip/gic-v4: Don't allow a VMOVP on a dying VPE", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50069", " - pinctrl: apple: check devm_kasprintf() returned value", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50070", " - pinctrl: stm32: check devm_kasprintf() returned value", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50196", " - pinctrl: ocelot: fix system hang on level based interrupts", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50197", " - pinctrl: intel: platform: fix error path in device_for_each_child_node()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50071", " - pinctrl: nuvoton: fix a double free in ma35_pinctrl_dt_node_to_map_func()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50072", " - x86/bugs: Use code segment selector for VERW operand", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50073", " - tty: n_gsm: Fix use-after-free in gsm_cleanup_mux", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50193", " - x86/entry_32: Clear CPU buffers after register restore in NMI return", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50074", " - parport: Proper fix for array out-of-bounds access", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50100", " - USB: gadget: dummy-hcd: Fix \"task hung\" problem", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50075", " - xhci: tegra: fix checked USB2 port number", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50076", " - vt: prevent kernel-infoleak in con_font_get()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50077", " - Bluetooth: ISO: Fix multiple init when debugfs is disabled", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50078", " - Bluetooth: Call iso_exit() on module unload", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50198", " - iio: light: veml6030: fix IIO device retrieval from embedded device", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50201", " - drm/radeon: Fix encoder->possible_clones", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50098", " - scsi: ufs: core: Set SDEV_OFFLINE when UFS is shut down", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50079", " - io_uring/sqpoll: ensure task state is TASK_RUNNING when running task_work", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50080", " - ublk: don't allow user copy for unprivileged device", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50081", " - blk-mq: setup queue ->tag_set before initializing hctx", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50082", " - blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50101", " - iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI devices", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50083", " - tcp: fix mptcp DSS corruption due to large pmtu xmit", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50068", " - mm/damon/tests/sysfs-kunit.h: fix memory leak in", " damon_sysfs_test_add_targets()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50199", " - mm/swapfile: skip HugeTLB pages for unuse_vma", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50066", " - mm/mremap: fix move_normal_pmd/retract_page_tables race", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50202", " - nilfs2: propagate directory read errors from nilfs_find_entry()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50200", " - maple_tree: correct tree corruption on spanning store", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50084", " - net: microchip: vcap api: Fix memory leaks in vcap_api_encode_rule_test()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50194", " - arm64: probes: Fix uprobes for big-endian kernels", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50099", " - arm64: probes: Remove broken LDR (literal) uprobe support", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50195", " - posix-clock: Fix missing timespec64 check in pc_clock_settime()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50085", " - mptcp: pm: fix UaF read in mptcp_pm_nl_rm_addr_or_subflow", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50086", " - ksmbd: fix user-after-free from session log off", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50087", " - btrfs: fix uninitialized pointer free on read_alloc_one_name() error", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50088", " - btrfs: fix uninitialized pointer free in add_inode_ref()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068)", " - net: fec: don't save PTP state if PTP is unsupported", " - fs/ntfs3: Do not call file_modified if collapse range failed", " - fs/ntfs3: Optimize large writes into sparse file", " - fs/ntfs3: Fix sparse warning for bigendian", " - fs/ntfs3: Fix sparse warning in ni_fiemap", " - fs/ntfs3: Refactor enum_rstbl to suppress static checker", " - vdpa/octeon_ep: Fix format specifier for pointers in debug messages", " - virtio_console: fix misc probe bugs", " - perf vdso: Missed put on 32-bit dsos", " - perf build: Fix static compilation error when libdw is not installed", " - perf build: Fix build feature-dwarf_getlocations fail for old libdw", " - zram: don't free statically defined names", " - bpf: Call the missed btf_record_free() when map creation fails", " - selftests/bpf: Fix ARG_PTR_TO_LONG {half-,}uninitialized test", " - bpf: Check percpu map value size first", " - s390/facility: Disable compile time optimization for decompressor code", " - s390/mm: Add cond_resched() to cmm_alloc/free_pages()", " - bpf, x64: Fix a jit convergence issue", " - ext4: nested locking for xattr inode", " - s390/cpum_sf: Remove WARN_ON_ONCE statements", " - s390/traps: Handle early warnings gracefully", " - ktest.pl: Avoid false positives with grub2 skip regex", " - soundwire: intel_bus_common: enable interrupts before exiting reset", " - PCI: Add function 0 DMA alias quirk for Glenfly Arise chip", " - clk: bcm: bcm53573: fix OF node leak in init", " - PCI: Add ACS quirk for Qualcomm SA8775P", " - i2c: i801: Use a different adapter-name for IDF adapters", " - PCI: Mark Creative Labs EMU20k2 INTx masking as broken", " - RISC-V: Don't have MAX_PHYSMEM_BITS exceed phys_addr_t", " - mfd: intel_soc_pmic_chtwc: Make Lenovo Yoga Tab 3 X90F DMI match less strict", " - mfd: intel-lpss: Add Intel Panther Lake LPSS PCI IDs", " - riscv: Omit optimized string routines when using KASAN", " - riscv: avoid Imbalance in RAS", " - RDMA/mlx5: Enforce umem boundaries for explicit ODP page faults", " - PCI: qcom: Disable mirroring of DBI and iATU register space in BAR region", " - PCI: endpoint: Assign PCI domain number for endpoint controllers", " - soundwire: cadence: re-check Peripheral status with delayed_work", " - riscv/kexec_file: Fix relocation type R_RISCV_ADD16 and R_RISCV_SUB16", " unknown", " - media: videobuf2-core: clear memory related fields in", " __vb2_plane_dmabuf_put()", " - remoteproc: imx_rproc: Use imx specific hook for find_loaded_rsc_table", " - usb: chipidea: udc: enable suspend interrupt after usb reset", " - usb: dwc2: Adjust the timing of USB Driver Interrupt Registration in the", " Crashkernel Scenario", " - xhci: dbc: Fix STALL transfer event handling", " - usb: host: xhci-plat: Parse xhci-missing_cas_quirk and apply quirk", " - comedi: ni_routing: tools: Check when the file could not be opened", " - LoongArch: Fix memleak in pci_acpi_scan_root()", " - netfilter: nf_nat: don't try nat source port reallocation for reverse dir", " clash", " - netfilter: nf_reject: Fix build warning when CONFIG_BRIDGE_NETFILTER=n", " - tools/iio: Add memory allocation failure check for trigger_name", " - staging: vme_user: added bound check to geoid", " - driver core: bus: Return -EIO instead of 0 when show/store invalid bus", " attribute", " - scsi: lpfc: Add ELS_RSP cmd to the list of WQEs to flush in", " lpfc_els_flush_cmd()", " - scsi: lpfc: Revise TRACE_EVENT log flag severities from KERN_ERR to", " KERN_WARNING", " - NFSD: Mark filecache \"down\" if init fails", " - nfsd: nfsd_destroy_serv() must call svc_destroy() even if nfsd_startup_net()", " failed", " - ice: set correct dst VSI in only LAN filters", " - ice: clear port vlan config during reset", " - ice: disallow DPLL_PIN_STATE_SELECTABLE for dpll output pins", " - ice: fix VLAN replay after reset", " - SUNRPC: Fix integer overflow in decode_rc_list()", " - net: phy: aquantia: AQR115c fix up PMA capabilities", " - net: phy: aquantia: remove usage of phy_set_max_speed", " - tcp: fix to allow timestamp undo if no retransmits were sent", " - tcp: fix tcp_enter_recovery() to zero retrans_stamp when it's safe", " - tcp: fix TFO SYN_RECV to not zero retrans_stamp with retransmits out", " - rxrpc: Fix uninitialised variable in rxrpc_send_data()", " - net: dsa: sja1105: fix reception from VLAN-unaware bridges", " - selftests: net: no_forwarding: fix VID for $swp2 in one_bridge_two_pvids()", " test", " - net: pse-pd: Fix enabled status mismatch", " - Bluetooth: btusb: Don't fail external suspend requests", " - net: phy: bcm84881: Fix some error handling paths", " - net: ethernet: adi: adin1110: Fix some error handling path in", " adin1110_read_fifo()", " - net: dsa: b53: fix jumbo frame mtu check", " - net: dsa: b53: fix max MTU for 1g switches", " - net: dsa: b53: fix max MTU for BCM5325/BCM5365", " - net: dsa: b53: allow lower MTUs on BCM5325/5365", " - net: dsa: b53: fix jumbo frames on 10/100 ports", " - drm/nouveau: pass cli to nouveau_channel_new() instead of drm+device", " - nouveau/dmem: Fix privileged error in copy engine channel", " - gpio: aspeed: Add the flush write to ensure the write complete.", " - gpio: aspeed: Use devm_clk api to manage clock source", " - x86/xen: mark boot CPU of PV guest in MSR_IA32_APICBASE", " - powercap: intel_rapl_tpmi: Ignore minor version change", " - ice: Fix entering Safe Mode", " - ice: Fix netif_is_ice() in Safe Mode", " - ice: Flush FDB entries before reset", " - drm/xe: Restore GT freq on GSC load error", " - drm/xe: Make wedged_mode debugfs writable", " - net: ibm: emac: mal: fix wrong goto", " - net: ti: icssg-prueth: Fix race condition for VLAN table access", " - btrfs: zoned: fix missing RCU locking in error message when loading zone", " info", " - sctp: ensure sk_state is set to CLOSED if hashing fails in sctp_listen_start", " - netfilter: fib: check correct rtable in vrf setups", " - net: ibm: emac: mal: add dcr_unmap to _remove", " - net: dsa: refuse cross-chip mirroring operations", " - rtnetlink: Add bulk registration helpers for rtnetlink message handlers.", " - vxlan: Handle error of rtnl_register_module().", " - bridge: Handle error of rtnl_register_module().", " - mctp: Handle error of rtnl_register_module().", " - mpls: Handle error of rtnl_register_module().", " - phonet: Handle error of rtnl_register_module().", " - rcu/nocb: Fix rcuog wake-up from offline softirq", " - HID: multitouch: Add support for lenovo Y9000P Touchpad", " - hwmon: intel-m10-bmc-hwmon: relabel Columbiaville to CVL Die Temperature", " - hwmon: (tmp513) Add missing dependency on REGMAP_I2C", " - hwmon: (mc34vr500) Add missing dependency on REGMAP_I2C", " - hwmon: (adm9240) Add missing dependency on REGMAP_I2C", " - hwmon: (adt7470) Add missing dependency on REGMAP_I2C", " - hwmon: (ltc2991) Add missing dependency on REGMAP_I2C", " - HID: plantronics: Workaround for an unexcepted opposite volume key", " - HID: wacom: Hardcode (non-inverted) AES pens as BTN_TOOL_PEN", " - Revert \"usb: yurex: Replace snprintf() with the safer scnprintf() variant\"", " - usb: dwc3: core: Stop processing of pending events if controller is halted", " - usb: xhci: Fix problem with xhci resume from suspend", " - usb: storage: ignore bogus device raised by JieLi BR21 USB sound chip", " - usb: dwc3: re-enable runtime PM after failed resume", " - usb: gadget: core: force synchronous registration", " - hid: intel-ish-hid: Fix uninitialized variable 'rv' in", " ish_fw_xfer_direct_dma", " - ACPI: resource: Make Asus ExpertBook B2402 matches cover more models", " - ACPI: resource: Make Asus ExpertBook B2502 matches cover more models", " - drm/amdgpu: partially revert powerplay `__counted_by` changes", " - drm/amd/display: Clear update flags after update has been applied", " - drm/amdkfd: Fix an eviction fence leak", " - drm/amd/display: fix hibernate entry for DCN35+", " - drm/xe/guc_submit: fix xa_store() error checking", " - drm/i915/hdcp: fix connector refcounting", " - drm/xe/ct: fix xa_store() error checking", " - scsi: ufs: Use pre-calculated offsets in ufshcd_init_lrb()", " - Revert \"mmc: mvsdio: Use sg_miter for PIO\"", " - mmc: sdhci-of-dwcmshc: Prevent stale command interrupt handling", " - mptcp: fallback when MPTCP opts are dropped after 1st data", " - ata: libata: avoid superfluous disk spin down + spin up during hibernation", " - OPP: fix error code in dev_pm_opp_set_config()", " - net: dsa: lan9303: ensure chip reset and wait for READY status", " - net: phy: realtek: Fix MMD access on RTL8126A-integrated PHY", " - mptcp: pm: do not remove closing subflows", " - powercap: intel_rapl_tpmi: Fix bogus register reading", " - selftests/mm: fix incorrect buffer->mirror size in hmm2 double_map test", " - selftests/rseq: Fix mm_cid test failure", " - btrfs: split remaining space to discard in chunks", " - btrfs: add cancellation points to trim loops", " - PM: domains: Fix alloc/free in dev_pm_domain_attach|detach_list()", " - idpf: use actual mbx receive payload length", " - fs/proc/kcore.c: allow translation of physical memory addresses", " - PCI: Pass domain number to pci_bus_release_domain_nr() explicitly", " - io_uring/rw: fix cflags posting for single issue multishot read", " - Linux 6.11.4", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50182", " - secretmem: disable memfd_secret() if arch cannot set direct map", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50019", " - kthread: unpark only parked kthread", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50096", " - nouveau/dmem: Fix vulnerability in migrate_to_ram upon copy error", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50020", " - ice: Fix improper handling of refcount in ice_sriov_set_msix_vec_count()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50021", " - ice: Fix improper handling of refcount in ice_dpll_init_rclk_pins()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50022", " - device-dax: correct pgoff align in dax_set_mapping()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50185", " - mptcp: handle consistently DSS corruption", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50023", " - net: phy: Remove LED entry from LEDs list on unregister", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50024", " - net: Fix an unsafe loop on the list", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50186", " - net: explicitly clear the sk pointer, when pf->create fails", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50025", " - scsi: fnic: Move flush_work initialization out of if block", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50026", " - scsi: wd33c93: Don't use stale scsi_pointer value", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50027", " - thermal: core: Free tzp copy along with the thermal zone", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50028", " - thermal: core: Reference count the zone in thermal_zone_get_by_id()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50029", " - Bluetooth: hci_conn: Fix UAF in hci_enhanced_setup_sync", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50030", " - drm/xe/ct: prevent UAF in send_recv()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50187", " - drm/vc4: Stop the active perfmon before being destroyed", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50031", " - drm/v3d: Stop the active perfmon before being destroyed", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50189", " - HID: amd_sfh: Switch to device-managed dmam_alloc_coherent()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50033", " - slip: make slhc_remember() more robust against malicious packets", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50034", " - net/smc: fix lacks of icsk_syn_mss with IPPROTO_SMC", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50035", " - ppp: fix ppp_async_encode() illegal access", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50036", " - net: do not delay dst_entries_add() in dst_release()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50037", " - drm/fbdev-dma: Only cleanup deferred I/O if necessary", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50092", " - net: netconsole: fix wrong warning", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50038", " - netfilter: xtables: avoid NFPROTO_UNSPEC where needed", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50039", " - net/sched: accept TCA_STAB only for root qdisc", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50040", " - igb: Do not bring the device up after non-fatal error", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50041", " - i40e: Fix macvlan leak by synchronizing access to mac_filter_hash", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50042", " - ice: Fix increasing MSI-X on VF", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50093", " - thermal: intel: int340x: processor: Fix warning during module unload", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50043", " - nfsd: fix possible badness in FREE_STATEID", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50044", " - Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50045", " - netfilter: br_netfilter: fix panic with metadata_dst skb", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50094", " - sfc: Don't invoke xdp_do_flush() from netpoll.", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50188", " - net: phy: dp83869: fix memory corruption when enabling fiber", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50046", " - NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50190", " - ice: fix memleak in ice_init_tx_topology()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50180", " - fbdev: sisfb: Fix strbuf array overflow", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50047", " - smb: client: fix UAF in async decryption", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50048", " - fbcon: Fix a NULL pointer dereference issue in fbcon_putcs", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50049", " - drm/amd/display: Check null pointer before dereferencing se", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50090", " - drm/xe/oa: Fix overflow in oa batch buffer", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50183", " - scsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV", " instance", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50055", " - driver core: bus: Fix double free in driver API bus_register()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50091", " - dm vdo: don't refer to dedupe_context after releasing it", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50056", " - usb: gadget: uvc: Fix ERR_PTR dereference in uvc_v4l2.c", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50184", " - virtio_pmem: Check device status before requesting flush", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50057", " - usb: typec: tipd: Free IRQ only if it was requested before", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50058", " - serial: protect uart_port_dtr_rts() in uart_shutdown() too", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50181", " - clk: imx: Remove CLK_SET_PARENT_GATE for DRAM mux for i.MX7D", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50059", " - ntb: ntb_hw_switchtec: Fix use after free vulnerability in", " switchtec_ntb_remove due to race condition", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50060", " - io_uring: check if we need to reschedule during overflow flush", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50061", " - i3c: master: cdns: Fix use after free vulnerability in cdns_i3c_master", " Driver Due to Race Condition", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50062", " - RDMA/rtrs-srv: Avoid null pointer deref during path establishment", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50095", " - RDMA/mad: Improve handling of timed out WRs of mad agent", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50063", " - bpf: Prevent tail call between progs attached to different hooks", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50191", " - ext4: don't set SB_RDONLY after filesystem errors", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50064", " - zram: free secondary algorithms names", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50065", " - ntfs3: Change to non-blocking allocation in ntfs_d_hash", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50089", " - unicode: Don't special case ignorable code points", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052)", " - jump_label: Fix static_key_slow_dec() yet again", " - scsi: st: Fix input/output error on empty drive reset", " - scsi: pm8001: Do not overwrite PCI queue mapping", " - drm/i915/psr: Do not wait for PSR being idle on on Panel Replay", " - drm/i915/display: BMG supports UHBR13.5", " - drm/i915/dp: Fix AUX IO power enabling for eDP PSR", " - drm/amdgpu: Fix get each xcp macro", " - drm/amd/display: handle nulled pipe context in DCE110's set_drr()", " - ksmbd: fix warning: comparison of distinct pointer types lacks a cast", " - mailbox: ARM_MHU_V3 should depend on ARM64", " - [Config] updateconfigs for ARM_MHU_V3", " - mailbox: rockchip: fix a typo in module autoloading", " - ceph: fix a memory leak on cap_auths in MDS client", " - drm/i915/dp: Fix colorimetry detection", " - ieee802154: Fix build error", " - net: sparx5: Fix invalid timestamps", " - net/mlx5: Added cond_resched() to crdump collection", " - net/mlx5e: SHAMPO, Fix overflow of hd_per_wq", " - netfilter: uapi: NFTA_FLOWTABLE_HOOK is NLA_NESTED", " - net: ieee802154: mcr20a: Use IRQF_NO_AUTOEN flag in request_irq()", " - net: wwan: qcom_bam_dmux: Fix missing pm_runtime_disable()", " - selftests: netfilter: Fix nft_audit.sh for newer nft binaries", " - selftests: netfilter: Add missing return value", " - Bluetooth: btmrvl: Use IRQF_NO_AUTOEN flag in request_irq()", " - afs: Fix missing wire-up of afs_retry_request()", " - net: Add netif_get_gro_max_size helper for GRO", " - net: Fix gso_features_check to check for both dev->gso_{ipv4_,}max_size", " - net: fec: Restart PPS after link state change", " - net: fec: Reload PTP registers after link-state change", " - net: stmmac: dwmac4: extend timeout for VLAN Tag register busy bit check", " - ipv4: ip_gre: Fix drops of small packets in ipgre_xmit", " - netfs: Fix missing wakeup after issuing writes", " - net: phy: realtek: Check the index value in led_hw_control_get", " - bridge: mcast: Fail MDB get request on empty entry", " - iomap: constrain the file range passed to iomap_file_unshare", " - dt-bindings: net: xlnx,axi-ethernet: Add missing reg minItems", " - ASoC: topology: Fix incorrect addressing assignments", " - ASoC: atmel: mchp-pdmc: Skip ALSA restoration if substream runtime is", " uninitialized", " - drm/connector: hdmi: Fix writing Dynamic Range Mastering infoframes", " - io_uring: fix memory leak when cache init fail", " - rust: kbuild: split up helpers.c", " - rust: kbuild: auto generate helper exports", " - rust: mutex: fix __mutex_init() usage in case of PREEMPT_RT", " - ALSA: mixer_oss: Remove some incorrect kfree_const() usages", " - ALSA: hda/realtek: Fix the push button function for the ALC257", " - cifs: Remove intermediate object of failed create reparse call", " - drm/panthor: Lock the VM resv before calling drm_gpuvm_bo_obtain_prealloc()", " - ALSA: hda/generic: Unconditionally prefer preferred_dacs pairs", " - ASoC: imx-card: Set card.owner to avoid a warning calltrace if SND=m", " - drm/xe: Restore pci state upon resume", " - drm/xe: Resume TDR after GT reset", " - cifs: Do not convert delimiter when parsing NFS-style symlinks", " - tools/rtla: Fix installation from out-of-tree build", " - ALSA: gus: Fix some error handling paths related to get_bpos() usage", " - ALSA: hda/conexant: Fix conflicting quirk for System76 Pangolin", " - drm/amd/display: Disable replay if VRR capability is false", " - drm/amd/display: Fix VRR cannot enable", " - drm/amd/display: Re-enable panel replay feature", " - e1000e: avoid failing the system during pm_suspend", " - wifi: ath9k: fix possible integer overflow in ath9k_get_et_stats()", " - crypto: x86/sha256 - Add parentheses around macros' single arguments", " - crypto: octeontx - Fix authenc setkey", " - crypto: octeontx2 - Fix authenc setkey", " - ice: Adjust over allocation of memory in ice_sched_add_root_node() and", " ice_sched_add_node()", " - wifi: iwlwifi: mvm: Fix a race in scan abort flow", " - wifi: iwlwifi: mvm: drop wrong STA selection in TX", " - net: hisilicon: hip04: fix OF node leak in probe()", " - net: hisilicon: hns_dsaf_mac: fix OF node leak in hns_mac_get_info()", " - net: hisilicon: hns_mdio: fix OF node leak in probe()", " - ACPICA: Fix memory leak if acpi_ps_get_next_namepath() fails", " - ACPICA: Fix memory leak if acpi_ps_get_next_field() fails", " - ACPI: resource: Skip IRQ override on Asus Vivobook Go E1404GAB", " - wifi: mt76: mt7915: disable tx worker during tx BA session enable/disable", " - net: sched: consistently use rcu_replace_pointer() in taprio_change()", " - Bluetooth: btusb: Add Realtek RTL8852C support ID 0x0489:0xe122", " - Bluetooth: btrtl: Set msft ext address filter quirk for RTL8852B", " - ACPI: video: Add force_vendor quirk for Panasonic Toughbook CF-18", " - ACPI: CPPC: Add support for setting EPP register in FFH", " - wifi: rtw88: select WANT_DEV_COREDUMP", " - l2tp: free sessions using rcu", " - l2tp: use rcu list add/del when updating lists", " - ACPI: EC: Do not release locks during operation region accesses", " - net: skbuff: sprinkle more __GFP_NOWARN on ingress allocs", " - net: mvpp2: Increase size of queue_name buffer", " - bnxt_en: Extend maximum length of version string by 1 byte", " - ipv4: Check !in_dev earlier for ioctl(SIOCSIFADDR).", " - wifi: rtw89: correct base HT rate mask for firmware", " - netfilter: nf_tables: do not remove elements if set backend implements", " .abort", " - ipv4: Mask upper DSCP bits and ECN bits in NETLINK_FIB_LOOKUP family", " - nvme-keyring: restrict match length for version '1' identifiers", " - nvme-tcp: sanitize TLS key handling", " - nvme-tcp: check for invalidated or revoked key", " - net: atlantic: Avoid warning about potential string truncation", " - crypto: simd - Do not call crypto_alloc_tfm during registration", " - netpoll: Ensure clean state on setup failures", " - tcp: avoid reusing FIN_WAIT2 when trying to find port in connect() process", " - wifi: iwlwifi: mvm: use correct key iteration", " - wifi: iwlwifi: allow only CN mcc from WRDD", " - virt: sev-guest: Ensure the SNP guest messages do not exceed a page", " - wifi: mac80211: fix RCU list iterations", " - ACPICA: iasl: handle empty connection_node", " - proc: add config & param to block forcing mem writes", " - [Config] updateconfigs to select PROC_MEM_ALWAYS_FORCE", " - vfs: use RCU in ilookup", " - drivers/perf: arm_spe: Use perf_allow_kernel() for permissions", " - nvme: fix metadata handling in nvme-passthrough", " - can: netlink: avoid call to do_set_data_bittiming callback with stale", " can_priv::ctrlmode", " - netdev-genl: Set extack and fix error on napi-get", " - wifi: wilc1000: Do not operate uninitialized hardware during suspend/resume", " - arm64: trans_pgd: mark PTEs entries as valid to avoid dead kexec()", " - net: phy: Check for read errors in SIOCGMIIREG", " - x86/bugs: Add missing NO_SSB flag", " - x86/bugs: Fix handling when SRSO mitigation is disabled", " - crypto: hisilicon - fix missed error branch", " - wifi: mt76: mt7915: add dummy HW offload of IEEE 802.11 fragmentation", " - wifi: mt76: mt7915: hold dev->mt76.mutex while disabling tx worker", " - netfs: Cancel dirty folios that have no storage destination", " - nfp: Use IRQF_NO_AUTOEN flag in request_irq()", " - ALSA: usb-audio: Add input value sanity checks for standard types", " - x86/apic: Remove logical destination mode for 64-bit", " - ALSA: usb-audio: Define macros for quirk table entries", " - ALSA: usb-audio: Replace complex quirk lines with macros", " - ALSA: usb-audio: Add quirk for RME Digiface USB", " - ALSA: usb-audio: Add mixer quirk for RME Digiface USB", " - ALSA: hda/realtek: Refactor and simplify Samsung Galaxy Book init", " - ALSA: usb-audio: Add logitech Audio profile quirk", " - ASoC: codecs: wsa883x: Handle reading version failure", " - ALSA: control: Take power_ref lock primarily", " - tools/x86/kcpuid: Protect against faulty \"max subleaf\" values", " - x86/pkeys: Add PKRU as a parameter in signal handling functions", " - x86/pkeys: Restore altstack access in sigreturn()", " - x86/kexec: Add EFI config table identity mapping for kexec kernel", " - ALSA: hdsp: Break infinite MIDI input flush loop", " - tools/nolibc: powerpc: limit stack-protector workaround to GCC", " - selftests/nolibc: avoid passing NULL to printf(\"%s\")", " - x86/syscall: Avoid memcpy() for ia32 syscall_get_arguments()", " - ASoC: Intel: boards: always check the result of", " acpi_dev_get_first_match_dev()", " - hwmon: (nct6775) add G15CF to ASUS WMI monitoring list", " - pmdomain: core: Don't hold the genpd-lock when calling dev_pm_domain_set()", " - pmdomain: core: Use dev_name() instead of kobject_get_path() in debugfs", " - rcuscale: Provide clear error when async specified without primitives", " - power: reset: brcmstb: Do not go into infinite loop if reset fails", " - iommu/arm-smmu-v3: Match Stall behaviour for S2", " - iommu/vt-d: Always reserve a domain ID for identity setup", " - iommu/vt-d: Unconditionally flush device TLB for pasid table updates", " - iommu/arm-smmu-v3: Do not use devm for the cd table allocations", " - drm/amdgpu: disallow multiple BO_HANDLES chunks in one submit", " - drm/amd/display: Use gpuvm_min_page_size_kbytes for DML2 surfaces", " - ata: pata_serverworks: Do not use the term blacklist", " - ata: sata_sil: Rename sil_blacklist to sil_quirks", " - selftests/bpf: fix uprobe.path leak in bpf_testmod", " - scsi: smartpqi: Add new controller PCI IDs", " - HID: Ignore battery for all ELAN I2C-HID devices", " - drm/amd/display: Underflow Seen on DCN401 eGPU", " - drm/xe: Name and document Wa_14019789679", " - jfs: UBSAN: shift-out-of-bounds in dbFindBits", " - scsi: smartpqi: correct stream detection", " - scsi: smartpqi: add new controller PCI IDs", " - drm/amdgpu: add raven1 gfxoff quirk", " - drm/amdgpu: enable gfxoff quirk on HP 705G4", " - drm/amdkfd: Fix resource leak in criu restore queue", " - HID: multitouch: Add support for Thinkpad X12 Gen 2 Kbd Portfolio", " - platform/x86: touchscreen_dmi: add nanote-next quirk", " - platform/x86/amd: pmf: Add quirk for TUF Gaming A14", " - drm/stm: ltdc: reset plane transparency after plane disable", " - drm/amdgpu/gfx12: properly handle error ints on all pipes", " - drm/amdgpu/gfx9: properly handle error ints on all pipes", " - drm/amd/display: Fix possible overflow in integer multiplication", " - drm/printer: Allow NULL data in devcoredump printer", " - perf,x86: avoid missing caller address in stack traces captured in uprobe", " - scsi: aacraid: Rearrange order of struct aac_srb_unit", " - scsi: lpfc: Fix unsolicited FLOGI kref imbalance when in direct attached", " topology", " - scsi: lpfc: Update PRLO handling in direct attached topology", " - drm/amd/display: Force enable 3DLUT DMA check for dcn401 in DML", " - drm/amdgpu: fix unchecked return value warning for amdgpu_gfx", " - drm/amdgpu: fix unchecked return value warning for amdgpu_atombios", " - perf: Fix event_function_call() locking", " - scsi: NCR5380: Initialize buffer for MSG IN and STATUS transfers", " - drm/radeon/r100: Handle unknown family in r100_cp_init_microcode()", " - drm/amd/display: Unlock Pipes Based On DET Allocation", " - drm/amdgpu: fix ptr check warning in gfx9 ip_dump", " - drm/amdgpu: fix ptr check warning in gfx10 ip_dump", " - drm/amdgpu: fix ptr check warning in gfx11 ip_dump", " - drm/amdgpu: Block MMR_READ IOCTL in reset", " - drm/amdgpu/gfx9: use rlc safe mode for soft recovery", " - drm/amdgpu/gfx11: enter safe mode before touching CP_INT_CNTL", " - drm/xe: Use topology to determine page fault queue size", " - drm/amdkfd: Check int source id for utcl2 poison event", " - of/irq: Refer to actual buffer size in of_irq_parse_one()", " - drm/amd/display: guard write a 0 post_divider value to HW", " - powerpc/pseries: Use correct data types from pseries_hp_errorlog struct", " - ovl: fsync after metadata copy-up", " - drm/amdgpu/gfx12: use rlc safe mode for soft recovery", " - drm/amdgpu/gfx11: use rlc safe mode for soft recovery", " - drm/amdgpu/gfx10: use rlc safe mode for soft recovery", " - platform/x86: lenovo-ymc: Ignore the 0x0 state", " - tools/hv: Add memory allocation check in hv_fcopy_start", " - HID: i2c-hid: ensure various commands do not interfere with each other", " - platform/mellanox: mlxbf-pmc: fix lockdep warning", " - platform/x86: x86-android-tablets: Adjust Xiaomi Pad 2 bottom bezel touch", " buttons LED", " - bpf: Make the pointer returned by iter next method valid", " - ext4: ext4_search_dir should return a proper error", " - bpftool: Fix undefined behavior caused by shifting into the sign bit", " - iomap: handle a post-direct I/O invalidate race in", " iomap_write_delalloc_release", " - EINJ, CXL: Fix CXL device SBDF calculation", " - spi: spi-imx: Fix pm_runtime_set_suspended() with runtime pm enabled", " - spi: spi-cadence: Fix pm_runtime_set_suspended() with runtime pm enabled", " - spi: spi-cadence: Fix missing spi_controller_is_target() check", " - selftest: hid: add missing run-hid-tools-tests.sh", " - spi: s3c64xx: fix timeout counters in flush_fifo", " - kselftest/devices/probe: Fix SyntaxWarning in regex strings for Python3", " - selftests: breakpoints: use remaining time to check if suspend succeed", " - accel/ivpu: Add missing MODULE_FIRMWARE metadata", " - spi: rpc-if: Add missing MODULE_DEVICE_TABLE", " - ALSA: control: Fix power_ref lock order for compat code, too", " - perf callchain: Fix stitch LBR memory leaks", " - perf: Really fix event_function_call() locking", " - drm/xe: fixup xe_alloc_pf_queue", " - drm/xe: Fix memory leak on xe_alloc_pf_queue failure", " - selftests: vDSO: fix vDSO name for powerpc", " - selftests: vDSO: fix vdso_config for powerpc", " - selftests: vDSO: fix vDSO symbols lookup for powerpc64", " - ext4: fix error message when rejecting the default hash", " - selftests/mm: fix charge_reserved_hugetlb.sh test", " - nvme-tcp: fix link failure for TCP auth", " - f2fs: add write priority option based on zone UFS", " - powerpc/vdso: Fix VDSO data access when running in a non-root time namespace", " - selftests: vDSO: fix ELF hash table entry size for s390x", " - selftests: vDSO: fix vdso_config for s390", " - f2fs: make BG GC more aggressive for zoned devices", " - f2fs: introduce migration_window_granularity", " - f2fs: increase BG GC migration window granularity when boosted for zoned", " devices", " - f2fs: do FG_GC when GC boosting is required for zoned devices", " - f2fs: forcibly migrate to secure space for zoned device file pinning", " - Revert \"ALSA: hda: Conditionally use snooping for AMD HDMI\"", " - KVM: arm64: Fix kvm_has_feat*() handling of negative features", " - i2c: qcom-geni: Use IRQF_NO_AUTOEN flag in request_irq()", " - i2c: xiic: Wait for TX empty to avoid missed TX NAKs", " - i2c: core: Lock address during client device instantiation", " - i2c: xiic: Fix pm_runtime_set_suspended() with runtime pm enabled", " - i2c: designware: fix controller is holding SCL low while ENABLE bit is", " disabled", " - i2c: synquacer: Deal with optional PCLK correctly", " - rust: sync: require `T: Sync` for `LockedBy::access`", " - ovl: fail if trusted xattrs are needed but caller lacks permission", " - firmware: tegra: bpmp: Drop unused mbox_client_to_bpmp()", " - memory: tegra186-emc: drop unused to_tegra186_emc()", " - dt-bindings: clock: exynos7885: Fix duplicated binding", " - spi: bcm63xx: Fix module autoloading", " - spi: bcm63xx: Fix missing pm_runtime_disable()", " - power: supply: hwmon: Fix missing temp1_max_alarm attribute", " - power: supply: Drop use_cnt check from power_supply_property_is_writeable()", " - perf/core: Fix small negative period being ignored", " - drm/v3d: Prevent out of bounds access in performance query extensions", " - parisc: Fix itlb miss handler for 64-bit programs", " - drm/mediatek: ovl_adaptor: Add missing of_node_put()", " - drm: Consistently use struct drm_mode_rect for FB_DAMAGE_CLIPS", " - ALSA: hda/tas2781: Add new quirk for Lenovo Y990 Laptop", " - ALSA: core: add isascii() check to card ID generator", " - ALSA: usb-audio: Add delay quirk for VIVO USB-C HEADSET", " - ALSA: usb-audio: Add native DSD support for Luxman D-08u", " - ALSA: line6: add hw monitor volume control to POD HD500X", " - ALSA: hda/realtek: fix mute/micmute LED for HP mt645 G8", " - ALSA: hda/realtek: Add quirk for Huawei MateBook 13 KLV-WX9", " - ALSA: hda/realtek: Add a quirk for HP Pavilion 15z-ec200", " - ext4: correct encrypted dentry name hash when not casefolded", " - ext4: propagate errors from ext4_find_extent() in ext4_insert_range()", " - ext4: fix incorrect tid assumption in ext4_fc_mark_ineligible()", " - ext4: fix incorrect tid assumption in __jbd2_log_wait_for_space()", " - ext4: fix incorrect tid assumption in ext4_wait_for_tail_page_commit()", " - ext4: fix incorrect tid assumption in jbd2_journal_shrink_checkpoint_list()", " - ext4: fix fast commit inode enqueueing during a full journal commit", " - ext4: use handle to mark fc as ineligible in __track_dentry_update()", " - ext4: mark fc as ineligible using an handle in ext4_xattr_set()", " - parisc: Fix 64-bit userspace syscall path", " - parisc: Allow mmap(MAP_STACK) memory to automatically expand upwards", " - parisc: Fix stack start for ADDR_NO_RANDOMIZE personality", " - drm/rockchip: vop: clear DMA stop bit on RK3066", " - of: address: Report error on resource bounds overflow", " - of/irq: Support #msi-cells=<0> in of_msi_get_domain", " - lib/buildid: harden build ID parsing logic", " - jbd2: correctly compare tids with tid_geq function in jbd2_fc_begin_commit", " - mm: krealloc: consider spare memory for __GFP_ZERO", " - ocfs2: fix the la space leak when unmounting an ocfs2 volume", " - ocfs2: fix uninit-value in ocfs2_get_block()", " - scripts/gdb: fix timerlist parsing issue", " - scripts/gdb: add iteration function for rbtree", " - scripts/gdb: fix lx-mounts command error", " - arm64: fix selection of HAVE_DYNAMIC_FTRACE_WITH_ARGS", " - arm64: Subscribe Microsoft Azure Cobalt 100 to erratum 3194386", " - drm/xe/oa: Don't reset OAC_CONTEXT_ENABLE on OA stream close", " - sched/deadline: Comment sched_dl_entity::dl_server variable", " - sched/core: Add clearing of ->dl_server in put_prev_task_balance()", " - sched/core: Clear prev->dl_server in CFS pick fast path", " - sched: psi: fix bogus pressure spikes from aggregation race", " - riscv: define ILLEGAL_POINTER_VALUE for 64bit", " - [Config] updateconfigs for ILLEGAL_POINTER_VALUE on riscv", " - perf python: Disable -Wno-cast-function-type-mismatch if present on clang", " - perf hist: Update hist symbol when updating maps", " - nfsd: fix delegation_blocked() to block correctly for at least 30 seconds", " - NFSD: Fix NFSv4's PUTPUBFH operation", " - sysctl: avoid spurious permanent empty tables", " - RDMA/mana_ib: use the correct page table index based on hardware page size", " - RDMA/mana_ib: use the correct page size for mapping user-mode doorbell page", " - drivers/perf: riscv: Align errno for unsupported perf event", " - riscv: Fix kernel stack size when KASAN is enabled", " - media: imx335: Fix reset-gpio handling", " - clk: rockchip: fix error for unknown clocks", " - leds: pca9532: Remove irrelevant blink configuration error message", " - media: videobuf2: Drop minimum allocation requirement of 2 buffers", " - clk: qcom: dispcc-sm8250: use CLK_SET_RATE_PARENT for branch clocks", " - media: sun4i_csi: Implement link validate for sun4i_csi subdev", " - clk: qcom: gcc-sm8450: Do not turn off PCIe GDSCs during gdsc_disable()", " - media: uapi/linux/cec.h: cec_msg_set_reply_to: zero flags", " - dt-bindings: clock: qcom: Add GPLL9 support on gcc-sc8180x", " - clk: qcom: gcc-sc8180x: Register QUPv3 RCGs for DFS on sc8180x", " - clk: qcom: clk-rpmh: Fix overflow in BCM vote", " - clk: samsung: exynos7885: Update CLKS_NR_FSYS after bindings fix", " - clk: qcom: gcc-sm8150: De-register gcc_cpuss_ahb_clk_src", " - clk: qcom: gcc-sm8250: Do not turn off PCIe GDSCs during gdsc_disable()", " - clk: qcom: gcc-sc8180x: Add GPLL9 support", " - clk: qcom: gcc-sc8180x: Fix the sdcc2 and sdcc4 clocks freq table", " - clk: qcom: clk-alpha-pll: Fix CAL_L_VAL override for LUCID EVO PLL", " - drm/amd/display: avoid set dispclk to 0", " - smb: client: use actual path when queryfs", " - smb3: fix incorrect mode displayed for read-only files", " - iio: magnetometer: ak8975: Fix reading for ak099xx sensors", " - iio: pressure: bmp280: Fix regmap for BMP280 device", " - iio: pressure: bmp280: Fix waiting time for BMP3xx configuration", " - tomoyo: fallback to realpath if symlink's pathname does not exist", " - kselftests: mm: fix wrong __NR_userfaultfd value", " - rtc: at91sam9: fix OF node leak in probe() error path", " - mm/hugetlb: fix memfd_pin_folios resv_huge_pages leak", " - mm/gup: fix memfd_pin_folios hugetlb page allocation", " - mm/hugetlb: simplify refs in memfd_alloc_folio", " - Input: adp5589-keys - fix adp5589_gpio_get_value()", " - HID: bpf: fix cfi stubs for hid_bpf_ops", " - pidfs: check for valid pid namespace", " - ACPI: video: Add backlight=native quirk for Dell OptiPlex 5480 AIO", " - ACPI: resource: Remove duplicate Asus E1504GAB IRQ override", " - ACPI: resource: Loosen the Asus E1404GAB DMI match to also cover the E1404GA", " - ACPI: resource: Add Asus Vivobook X1704VAP to irq1_level_low_skip_override[]", " - ACPI: resource: Add Asus ExpertBook B2502CVA to", " irq1_level_low_skip_override[]", " - btrfs: drop the backref cache during relocation if we commit", " - btrfs: send: fix invalid clone operation for file that got its size", " decreased", " - cpufreq: intel_pstate: Make hwp_notify_lock a raw spinlock", " - gpio: davinci: fix lazy disable", " - net: pcs: xpcs: fix the wrong register that was written back", " - Bluetooth: hci_event: Align BR/EDR JUST_WORKS paring with LE", " - io_uring/net: harden multishot termination case for recv", " - ceph: fix cap ref leak via netfs init_request", " - tracing/hwlat: Fix a race during cpuhp processing", " - tracing/timerlat: Fix duplicated kthread creation due to CPU online/offline", " - rtla: Fix the help text in osnoise and timerlat top tools", " - firmware/sysfb: Disable sysfb for firmware buffers with unknown parent", " - close_range(): fix the logics in descriptor table trimming", " - drm/i915/gem: fix bitwise and logical AND mixup", " - drm/panthor: Don't add write fences to the shared BOs", " - drm/panthor: Don't declare a queue blocked if deferred operations are", " pending", " - drm/sched: Fix dynamic job-flow control race", " - drm/sched: Add locking to drm_sched_entity_modify_sched", " - drm/sched: Always wake up correct scheduler in drm_sched_entity_push_job", " - drm/sched: Always increment correct scheduler score", " - drm/amd/display: Restore Optimized pbn Value if Failed to Disable DSC", " - drm/amd/display: Add HDR workaround for specific eDP", " - drm/amd/display: Enable idle workqueue for more IPS modes", " - kconfig: fix infinite loop in sym_calc_choice()", " - kconfig: qconf: move conf_read() before drawing tree pain", " - kconfig: qconf: fix buffer overflow in debug links", " - arm64: cputype: Add Neoverse-N3 definitions", " - arm64: errata: Expand speculative SSBS workaround once more", " - mm: z3fold: deprecate CONFIG_Z3FOLD", " - [Config] updateconfigs after deprecating Z3FOLD", " - drm/amd/display: Allow backlight to go below", " `AMDGPU_DM_DEFAULT_MIN_BACKLIGHT`", " - sunrpc: change sp_nrthreads from atomic_t to unsigned int.", " - NFSD: Async COPY result needs to return a write verifier", " - remoteproc: k3-r5: Acquire mailbox handle during probe routine", " - remoteproc: k3-r5: Delay notification of wakeup event", " - r8169: Fix spelling mistake: \"tx_underun\" -> \"tx_underrun\"", " - ACPI: battery: Simplify battery hook locking", " - drm/xe: Clean up VM / exec queue file lock usage.", " - drm/rockchip: vop: enable VOP_FEATURE_INTERNAL_RGB on RK3066", " - drm/xe/vram: fix ccs offset calculation", " - drm/sched: revert \"Always increment correct scheduler score\"", " - ALSA: control: Fix leftover snd_power_unref()", " - crypto: octeontx* - Select CRYPTO_AUTHENC", " - drm/amd/display: Revert Avoid overflow assignment", " - perf report: Fix segfault when 'sym' sort key is not used", " - pmdomain: core: Reduce debug summary table width", " - perf python: Allow checking for the existence of warning options in clang", " - Linux 6.11.3", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49863", " - vhost/scsi: null-ptr-dereference in vhost_scsi_get_req()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49864", " - rxrpc: Fix a race between socket set up and I/O thread creation", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49865", " - drm/xe/vm: move xa_alloc to prevent UAF", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49955", " - ACPI: battery: Fix possible crash when unregistering a battery hook", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49973", " - r8169: add tally counter fields added with RTL8125", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49974", " - NFSD: Limit the number of concurrent async COPY operations", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49975", " - uprobes: fix kernel info leak via \"[uprobes]\" vma", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50003", " - drm/amd/display: Fix system hang while resume with TBT monitor", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50173", " - drm/panthor: Fix access to uninitialized variable in tick_ctx_cleanup()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49866", " - tracing/timerlat: Fix a race during cpuhp processing", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49976", " - tracing/timerlat: Drop interface_lock in stop_kthread()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50005", " - mac802154: Fix potential RCU dereference issue in mac802154_scan_worker", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50012", " - cpufreq: Avoid a bad reference count on CPU node", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49867", " - btrfs: wait for fixup workers before stopping cleaner kthread during umount", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49868", " - btrfs: fix a NULL pointer dereference when failed to start a new trasacntion", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49869", " - btrfs: send: fix buffer overflow detection when copying path to cache entry", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49870", " - cachefiles: fix dentry leak in cachefiles_open_file()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49871", " - Input: adp5589-keys - fix NULL pointer dereference", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49872", " - mm/gup: fix memfd_pin_folios alloc race panic", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49964", " - mm/hugetlb: fix memfd_pin_folios free_huge_pages leak", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49873", " - mm/filemap: fix filemap_get_folios_contig THP panic", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49977", " - net: stmmac: Fix zero-division error when disabling tc cbs", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49978", " - gso: fix udp gso fraglist segmentation after pull from frag_list", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49979", " - net: gso: fix tcp fraglist segmentation after pull from frag_list", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49980", " - vrf: revert \"vrf: Remove unnecessary RCU-bh critical section\"", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49981", " - media: venus: fix use after free bug in venus_remove due to race condition", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49956", " - gfs2: fix double destroy_workqueue error", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50176", " - remoteproc: k3-r5: Fix error handling when power-up failed", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49982", " - aoe: fix the potential use-after-free problem in more places", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49874", " - i3c: master: svc: Fix use after free vulnerability in svc_i3c_master Driver", " Due to Race Condition", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49875", " - nfsd: map the EBADMSG to nfserr_io to avoid warning", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50013", " - exfat: fix memory leak in exfat_load_bitmap()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49876", " - drm/xe: fix UAF around queue destruction", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49877", " - ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49957", " - ocfs2: fix null-ptr-deref when journal load failed.", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49965", " - ocfs2: remove unreasonable unlock in ocfs2_read_blocks", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49966", " - ocfs2: cancel dqi_sync_work before freeing oinfo", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49958", " - ocfs2: reserve space for inline xattr before attaching reflink tree", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49959", " - jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49878", " - resource: fix region_intersects() vs add_memory_driver_managed()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49879", " - drm: omapdrm: Add missing check for alloc_ordered_workqueue", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49880", " - ext4: fix off by one issue in alloc_flex_gd()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49881", " - ext4: update orig_path in ext4_find_extent()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50014", " - ext4: fix access to uninitialised lock in fc replay path", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49960", " - ext4: fix timer use-after-free on failed mount", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49882", " - ext4: fix double brelse() the buffer of the extents path", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49883", " - ext4: aovid use-after-free in ext4_ext_insert_extent()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49983", " - ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-free", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50015", " - ext4: dax: fix overflowing extents beyond inode size when partially writing", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49884", " - ext4: fix slab-use-after-free in ext4_split_extent_at()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49885", " - mm, slub: avoid zeroing kmalloc redzone", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49961", " - media: i2c: ar0521: Use cansleep version of gpiod_set_value()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49985", " - i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49886", " - platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bug", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49986", " - platform/x86: x86-android-tablets: Fix use after free on", " platform_device_register() errors", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49887", " - f2fs: fix to don't panic system for no free segment fault injection", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49888", " - bpf: Fix a sdiv overflow issue", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49987", " - bpftool: Fix undefined behavior in qsort(NULL, 0, ...)", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50006", " - ext4: fix i_data_sem unlock order in ext4_ind_migrate()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49889", " - ext4: avoid use-after-free in ext4_ext_show_leaf()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49968", " - ext4: filesystems without casefold feature cannot be mounted with siphash", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49988", " - ksmbd: add refcnt to ksmbd_conn struct", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49890", " - drm/amd/pm: ensure the fw_info is not null before using it", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49891", " - scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata", " paths", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49892", " - drm/amd/display: Initialize get_bytes_per_element's default to 1", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50016", " - drm/amd/display: Avoid overflow assignment in link_dp_cts", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49893", " - drm/amd/display: Check stream_status before it is used", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49969", " - drm/amd/display: Fix index out of bounds in DCN30 color transformation", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49970", " - drm/amd/display: Implement bounds check for stream encoder creation in", " DCN401", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49894", " - drm/amd/display: Fix index out of bounds in degamma hardware format", " translation", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49895", " - drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format", " translation", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49971", " - drm/amd/display: Increase array size of dummy_boolean", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49972", " - drm/amd/display: Deallocate DML memory if allocation fails", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49896", " - drm/amd/display: Check stream before comparing them", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49897", " - drm/amd/display: Check phantom_stream before it is used", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49898", " - drm/amd/display: Check null-initialized variables", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49899", " - drm/amd/display: Initialize denominators' default to 1", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49900", " - jfs: Fix uninit-value access of new_ea in ea_buffer", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49901", " - drm/msm/adreno: Assign msm_gpu->pdev earlier to avoid nullptrs", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49902", " - jfs: check if leafidx greater than num leaves per dmap tree", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49903", " - jfs: Fix uaf in dbFreeBits", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49904", " - drm/amdgpu: add list empty check to avoid null pointer issue", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49989", " - drm/amd/display: fix double free issue during amdgpu module unload", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49905", " - drm/amd/display: Add null check for 'afb' in", " amdgpu_dm_plane_handle_cursor_update (v2)", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49906", " - drm/amd/display: Check null pointer before try to access it", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49907", " - drm/amd/display: Check null pointers before using dc->clk_mgr", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49908", " - drm/amd/display: Add null check for 'afb' in amdgpu_dm_update_cursor (v2)", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50177", " - drm/amd/display: fix a UBSAN warning in DML2.1", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49909", " - drm/amd/display: Add NULL check for function pointer in", " dcn32_set_output_transfer_func", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49910", " - drm/amd/display: Add NULL check for function pointer in", " dcn401_set_output_transfer_func", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49911", " - drm/amd/display: Add NULL check for function pointer in", " dcn20_set_output_transfer_func", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49912", " - drm/amd/display: Handle null 'stream_status' in", " 'planes_changed_for_existing_stream'", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49913", " - drm/amd/display: Add null check for top_pipe_to_program in", " commit_planes_for_stream", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49914", " - drm/amd/display: Add null check for pipe_ctx->plane_state in", " dcn20_program_pipe", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49915", " - drm/amd/display: Add NULL check for clk_mgr in dcn32_init_hw", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49916", " - drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in", " dcn401_init_hw", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49917", " - drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in", " dcn30_init_hw", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49918", " - drm/amd/display: Add null check for head_pipe in", " dcn32_acquire_idle_pipe_for_head_pipe_in_layer", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49919", " - drm/amd/display: Add null check for head_pipe in", " dcn201_acquire_free_pipe_for_layer", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49991", " - drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49920", " - drm/amd/display: Check null pointers before multiple uses", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49921", " - drm/amd/display: Check null pointers before used", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49922", " - drm/amd/display: Check null pointers before using them", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49923", " - drm/amd/display: Pass non-null to dcn20_validate_apply_pipe_split_flags", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49992", " - drm/stm: Avoid use-after-free issues with crtc and plane", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49993", " - iommu/vt-d: Fix potential lockup if qi_submit_sync called with 0 count", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49924", " - fbdev: pxafb: Fix possible use after free in pxafb_task()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49925", " - fbdev: efifb: Register sysfs groups through driver core", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49926", " - rcu-tasks: Fix access non-existent percpu rtpcp variable in", " rcu_tasks_need_gpcb()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50007", " - ALSA: asihpi: Fix potential OOB array access", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50017", " - x86/mm/ident_map: Use gbpages only where full GB page should be mapped.", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49927", " - x86/ioapic: Handle allocation failures gracefully", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50008", " - wifi: mwifiex: Fix memcpy() field-spanning write warning in", " mwifiex_cmd_802_11_scan_ext()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50018", " - net: napi: Prevent overflow of napi_defer_hard_irqs", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49928", " - wifi: rtw89: avoid reading out of bounds when loading TX power FW elements", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50178", " - cpufreq: loongson3: Use raw_smp_processor_id() in do_service_request()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50009", " - cpufreq: amd-pstate: add check for cpufreq_cpu_get's return value", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49994", " - block: fix integer overflow in BLKSECDISCARD", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49929", " - wifi: iwlwifi: mvm: avoid NULL pointer dereference", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49995", " - tipc: guard against string buffer overrun", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49962", " - ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in", " acpi_db_convert_to_package()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49930", " - wifi: ath11k: fix array out-of-bound access in SoC stats", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49931", " - wifi: ath12k: fix array out-of-bound access in SoC stats", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49932", " - btrfs: don't readahead the relocation inode on RST", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49933", " - blk_iocost: fix more out of bound shifts", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49934", " - fs/inode: Prevent dump_mapping() accessing invalid dentry.d_name.name", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50010", " - exec: don't WARN for racy path_noexec check", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49935", " - ACPI: PAD: fix crash in exit_round_robin()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49936", " - net/xen-netback: prevent UAF in xenvif_flush_hash()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49937", " - wifi: cfg80211: Set correct chandef when starting CAC", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49938", " - wifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmit", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49939", " - wifi: rtw89: avoid to add interface to list twice when SER", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49940", " - l2tp: prevent possible tunnel refcount underflow", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49941", " - gpiolib: Fix potential NULL pointer dereference in gpiod_get_label()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49996", " - cifs: Fix buffer overflow when parsing NFS reparse points", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49942", " - drm/xe: Prevent null pointer access in xe_migrate_copy", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49943", " - drm/xe/guc_submit: add missing locking in wedged_fini", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50011", " - ASoC: Intel: soc-acpi-intel-rpl-match: add missing empty item", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50174", " - drm/panthor: Fix race when converting group handle to group object", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49944", " - sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_start", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49945", " - net/ncsi: Disable the ncsi work before freeing the associated structure", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49946", " - ppp: do not assume bh is held in ppp_channel_bridge_input()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49947", " - net: test for not too small csum_start in virtio_net_hdr_to_skb()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49948", " - net: add more sanity checks to qdisc_pkt_len_init()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49949", " - net: avoid potential underflow in qdisc_pkt_len_init() with UFO", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49997", " - net: ethernet: lantiq_etop: fix memory disclosure", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49998", " - net: dsa: improve shutdown sequence", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49999", " - afs: Fix the setting of the server responding flag", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49950", " - Bluetooth: L2CAP: Fix uaf in l2cap_connect", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49951", " - Bluetooth: MGMT: Fix possible crash on mgmt_index_removed", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49952", " - netfilter: nf_tables: prevent nf_skb_duplicated corruption", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49953", " - net/mlx5e: Fix crash caused by calling __xfrm_state_delete() twice", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50000", " - net/mlx5e: Fix NULL deref in mlx5e_tir_builder_alloc()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50001", " - net/mlx5: Fix error path in multi-packet WQE transmit", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50179", " - ceph: remove the incorrect Fw reference check when dirtying pages", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49963", " - mailbox: bcm2835: Fix timeout during suspend mode", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49954", " - static_call: Replace pointless WARN_ON() in static_call_module_notify()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50002", " - static_call: Handle module init failure correctly in", " static_call_del_module()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033)", " - EDAC/synopsys: Fix error injection on Zynq UltraScale+", " - crypto: xor - fix template benchmarking", " - crypto: qat - disable IOV in adf_dev_stop()", " - crypto: qat - fix recovery flow for VFs", " - crypto: qat - ensure correct order in VF restarting handler", " - ACPI: PMIC: Remove unneeded check in tps68470_pmic_opregion_probe()", " - eth: fbnic: select DEVLINK and PAGE_POOL", " - wifi: brcmfmac: introducing fwil query functions", " - wifi: ath9k: Remove error checks when creating debugfs entries", " - wifi: ath12k: fix BSS chan info request WMI command", " - wifi: ath12k: match WMI BSS chan info structure with firmware definition", " - wifi: ath12k: fix invalid AMPDU factor calculation in", " ath12k_peer_assoc_h_he()", " - hwrng: cn10k - Enable by default CN10K driver if Thunder SoC is enabled", " - crypto: x86/aes-gcm - fix PREEMPT_RT issue in gcm_crypt()", " - net: stmmac: dwmac-loongson: Init ref and PTP clocks rate", " - virtio: rename virtio_config_enabled to virtio_config_core_enabled", " - virtio: allow driver to disable the configure change notification", " - virtio-net: synchronize operstate with admin state on up/down", " - virtio-net: synchronize probe with ndo_set_features", " - arm64: signal: Fix some under-bracketed UAPI macros", " - wifi: rtw88: remove CPT execution branch never used", " - RISC-V: KVM: Fix sbiret init before forwarding to userspace", " - RISC-V: KVM: Allow legacy PMU access from guest", " - RISC-V: KVM: Fix to allow hpmcounter31 from the guest", " - mount: handle OOM on mnt_warn_timestamp_expiry", " - autofs: fix missing fput for FSCONFIG_SET_FD", " - netfilter: nf_tables: store new sets in dedicated list", " - wifi: rtw89: limit the PPDU length for VHT rate to 0x40000", " - kselftest/arm64: signal: fix/refactor SVE vector length enumeration", " - arm64: smp: smp_send_stop() and crash_smp_send_stop() should try non-NMI", " first", " - thermal: core: Fold two functions into their respective callers", " - thermal: core: Fix rounding of delay jiffies", " - perf/dwc_pcie: Fix registration issue in multi PCIe controller instances", " - perf/dwc_pcie: Always register for PCIe bus notifier", " - crypto: qat - fix \"Full Going True\" macro definition", " - ACPI: video: force native for Apple MacbookPro9,2", " - wifi: mac80211_hwsim: correct MODULE_PARM_DESC of multi_radio", " - wifi: iwlwifi: config: label 'gl' devices as discrete", " - wifi: iwlwifi: mvm: increase the time between ranging measurements", " - wifi: cfg80211: fix bug of mapping AF3x to incorrect User Priority", " - wifi: mac80211: fix the comeback long retry times", " - wifi: iwlwifi: mvm: allow ESR when we the ROC expires", " - wifi: mac80211: Check for missing VHT elements only for 5 GHz", " - ACPICA: Implement ACPI_WARNING_ONCE and ACPI_ERROR_ONCE", " - ACPICA: executer/exsystem: Don't nag user about every Stall() violating the", " spec", " - padata: Honor the caller's alignment in case of chunk_size 0", " - drivers/perf: hisi_pcie: Record hardware counts correctly", " - drivers/perf: hisi_pcie: Fix TLP headers bandwidth counting", " - kselftest/arm64: Actually test SME vector length changes via sigreturn", " - can: j1939: use correct function name in comment", " - wifi: rtw89: wow: fix wait condition for AOAC report request", " - ACPI: CPPC: Fix MASK_VAL() usage", " - netfilter: nf_tables: elements with timeout below CONFIG_HZ never expire", " - netfilter: nf_tables: reject element expiration with no timeout", " - netfilter: nf_tables: reject expiration higher than timeout", " - netfilter: nf_tables: remove annotation to access set timeout while holding", " lock", " - netfilter: nft_dynset: annotate data-races around set timeout", " - perf/arm-cmn: Refactor node ID handling. Again.", " - perf/arm-cmn: Fix CCLA register offset", " - perf/arm-cmn: Ensure dtm_idx is big enough", " - cpufreq: ti-cpufreq: Introduce quirks to handle syscon fails appropriately", " - thermal: gov_bang_bang: Adjust states of all uninitialized instances", " - wifi: mt76: mt7921: fix wrong UNII-4 freq range check for the channel usage", " - wifi: mt76: mt7996: fix traffic delay when switching back to working channel", " - wifi: mt76: mt7996: fix wmm set of station interface to 3", " - wifi: mt76: mt7996: fix HE and EHT beamforming capabilities", " - wifi: mt76: mt7996: fix EHT beamforming capability check", " - pm:cpupower: Add missing powercap_set_enabled() stub function", " - crypto: ccp - do not request interrupt on cmd completion when irqs disabled", " - crypto: hisilicon/hpre - mask cluster timeout error", " - crypto: hisilicon/qm - reset device before enabling it", " - wifi: mt76: mt7996: fix handling mbss enable/disable", " - wifi: mt76: connac: fix checksum offload fields of connac3 RXD", " - wifi: mt76: mt7603: fix mixed declarations and code", " - wifi: cfg80211: fix UBSAN noise in cfg80211_wext_siwscan()", " - wifi: mt76: mt7915: fix rx filter setting for bfee functionality", " - wifi: mt76: mt7996: fix uninitialized TLV data", " - wifi: cfg80211: fix two more possible UBSAN-detected off-by-one errors", " - af_unix: Don't call skb_get() for OOB skb.", " - af_unix: Remove single nest in manage_oob().", " - af_unix: Rename unlinked_skb in manage_oob().", " - af_unix: Move spin_lock() in manage_oob().", " - Bluetooth: hci_core: Fix sending MGMT_EV_CONNECT_FAILED", " - Bluetooth: hci_sync: Ignore errors from HCI_OP_REMOTE_NAME_REQ_CANCEL", " - can: m_can: enable NAPI before enabling interrupts", " - can: m_can: m_can_close(): stop clocks after device has been shut down", " - Bluetooth: btusb: Fix not handling ZPL/short-transfer", " - bareudp: Pull inner IP header in bareudp_udp_encap_recv().", " - bareudp: Pull inner IP header on xmit.", " - net: enetc: Use IRQF_NO_AUTOEN flag in request_irq()", " - crypto: n2 - Set err to EINVAL if snprintf fails for hmac", " - xsk: fix batch alloc API on non-coherent systems", " - net: ipv6: rpl_iptunnel: Fix memory leak in rpl_input", " - fbnic: Set napi irq value after calling netif_napi_add", " - net: tipc: avoid possible garbage value", " - ublk: move zone report data out of request pdu", " - block, bfq: choose the last bfqq from merge chain in bfq_setup_cooperator()", " - block, bfq: don't break merge chain in bfq_split_bfqq()", " - cachefiles: Fix non-taking of sb_writers around set/removexattr", " - nbd: correct the maximum value for discard sectors", " - erofs: fix incorrect symlink detection in fast symlink", " - erofs: fix error handling in z_erofs_init_decompressor", " - block, bfq: fix uaf for accessing waker_bfqq after splitting", " - block, bfq: fix procress reference leakage for bfqq in merge chain", " - io_uring/io-wq: do not allow pinning outside of cpuset", " - io_uring/io-wq: inherit cpuset of cgroup in io worker", " - spi: ppc4xx: handle irq_of_parse_and_map() errors", " - arm64: dts: exynos: exynos7885-jackpotlte: Correct RAM amount to 4GB", " - arm64: dts: mediatek: mt8186: Fix supported-hw mask for GPU OPPs", " - spi: ppc4xx: Avoid returning 0 when failed to parse and map IRQ", " - firmware: qcom: scm: Disable SDI and write no dump to dump mode", " - regulator: Return actual error in of_regulator_bulk_get_all()", " - arm64: dts: renesas: r9a08g045: Correct GICD and GICR sizes", " - arm64: dts: renesas: r9a07g043u: Correct GICD and GICR sizes", " - arm64: dts: renesas: r9a07g054: Correct GICD and GICR sizes", " - arm64: dts: renesas: r9a07g044: Correct GICD and GICR sizes", " - ARM: dts: microchip: sam9x60: Fix rtc/rtt clocks", " - arm64: tegra: Correct location of power-sensors for IGX Orin", " - arm64: dts: rockchip: Correct vendor prefix for Hardkernel ODROID-M1", " - arm64: dts: ti: k3-j721e-sk: Fix reversed C6x carveout locations", " - arm64: dts: ti: k3-j721e-beagleboneai64: Fix reversed C6x carveout locations", " - spi: bcmbca-hsspi: Fix missing pm_runtime_disable()", " - arm64: dts: qcom: x1e80100: Fix PHY for DP2", " - ARM: dts: microchip: sama7g5: Fix RTT clock", " - ARM: dts: imx7d-zii-rmu2: fix Ethernet PHY pinctrl property", " - arm64: dts: ti: k3-am654-idk: Fix dtbs_check warning in ICSSG dmas", " - ARM: versatile: fix OF node leak in CPUs prepare", " - reset: berlin: fix OF node leak in probe() error path", " - reset: k210: fix OF node leak in probe() error path", " - platform: cznic: turris-omnia-mcu: Fix error check in", " omnia_mcu_register_trng()", " - clocksource/drivers/qcom: Add missing iounmap() on errors in", " msm_dt_timer_init()", " - arm64: dts: mediatek: mt8195: Correct clock order for dp_intf*", " - x86/mm: Use IPIs to synchronize LAM enablement", " - ASoC: rt5682s: Return devm_of_clk_add_hw_provider to transfer the error", " - ASoC: tas2781: Fix a compiling warning reported by robot kernel test due to", " adding tas2563_dvc_table", " - ASoC: tas2781-i2c: Drop weird GPIO code", " - ASoC: tas2781-i2c: Get the right GPIO line", " - selftests/ftrace: Add required dependency for kprobe tests", " - ALSA: hda: cs35l41: fix module autoloading", " - selftests/ftrace: Fix test to handle both old and new kernels", " - x86/boot/64: Strip percpu address space when setting up GDT descriptors", " - m68k: Fix kernel_clone_args.flags in m68k_clone()", " - ASoC: loongson: fix error release", " - selftests/ftrace: Fix eventfs ownership testcase to find mount point", " - selftests:resctrl: Fix build failure on archs without __cpuid_count()", " - cgroup/pids: Avoid spurious event notification", " - hwmon: (max16065) Fix overflows seen when writing limits", " - hwmon: (max16065) Fix alarm attributes", " - iommu/arm-smmu: Un-demote unhandled-fault msg", " - iommu/arm-smmu-v3: Fix a NULL vs IS_ERR() check", " - mtd: slram: insert break after errors in parsing the map", " - hwmon: (ntc_thermistor) fix module autoloading", " - power: supply: axp20x_battery: Remove design from min and max voltage", " - power: supply: max17042_battery: Fix SOC threshold calc w/ no current sense", " - fbdev: hpfb: Fix an error handling path in hpfb_dio_probe()", " - iommu/amd: Handle error path in amd_iommu_probe_device()", " - iommu/amd: Allocate the page table root using GFP_KERNEL", " - iommu/amd: Move allocation of the top table into v1_alloc_pgtable", " - iommu/amd: Set the pgsize_bitmap correctly", " - iommu/amd: Do not set the D bit on AMD v2 table entries", " - mtd: powernv: Add check devm_kasprintf() returned value", " - rcu/nocb: Fix RT throttling hrtimer armed from offline CPU", " - mtd: rawnand: mtk: Use for_each_child_of_node_scoped()", " - mtd: rawnand: mtk: Factorize out the logic cleaning mtk chips", " - mtd: rawnand: mtk: Fix init error path", " - iommu/arm-smmu-qcom: hide last LPASS SMMU context bank from linux", " - iommu/arm-smmu-qcom: Work around SDM845 Adreno SMMU w/ 16K pages", " - iommu/arm-smmu-qcom: apply num_context_bank fixes for SDM630 / SDM660", " - pmdomain: core: Harden inter-column space in debug summary", " - pmdomain: core: Fix \"managed by\" alignment in debug summary", " - drm/stm: Fix an error handling path in stm_drm_platform_probe()", " - drm/stm: ltdc: check memory returned by devm_kzalloc()", " - drm/amd/display: free bo used for dmub bounding box", " - drm/amdgpu: properly handle vbios fake edid sizing", " - drm/radeon: properly handle vbios fake edid sizing", " - drm/amd/display: Reset VRR config during resume", " - scsi: smartpqi: revert propagate-the-multipath-failure-to-SML-quickly", " - scsi: sd: Don't check if a write for REQ_ATOMIC", " - scsi: block: Don't check REQ_ATOMIC for reads", " - scsi: NCR5380: Check for phase match during PDMA fixup", " - drm/amd/amdgpu: Properly tune the size of struct", " - drm/amd/display: Improve FAM control for DCN401", " - drm/rockchip: vop: Allow 4096px width scaling", " - drm/rockchip: dw_hdmi: Fix reading EDID when using a forced mode", " - drm/radeon/evergreen_cs: fix int overflow errors in cs track offsets", " - drm/bridge: lontium-lt8912b: Validate mode in drm_bridge_funcs::mode_valid()", " - drm/vc4: hdmi: Handle error case of pm_runtime_resume_and_get", " - drm/mediatek: Fix missing configuration flags in mtk_crtc_ddp_config()", " - drm/mediatek: Use spin_lock_irqsave() for CRTC event lock", " - powerpc/8xx: Fix initial memory mapping", " - powerpc/8xx: Fix kernel vs user address comparison", " - powerpc/vdso: Inconditionally use CFUNC macro", " - drm/msm: Use a7xx family directly in gpu_state", " - drm/msm: Dump correct dbgahb clusters on a750", " - drm/msm: Fix CP_BV_DRAW_STATE_ADDR name", " - drm/msm: Fix incorrect file name output in adreno_request_fw()", " - drm/msm/a5xx: disable preemption in submits by default", " - drm/msm/a5xx: properly clear preemption records on resume", " - drm/msm/a5xx: fix races in preemption evaluation stage", " - drm/msm/a5xx: workaround early ring-buffer emptiness check", " - ipmi: docs: don't advertise deprecated sysfs entries", " - drm/msm/dp: enable widebus on all relevant chipsets", " - drm/msm/dsi: correct programming sequence for SM8350 / SM8450", " - drm/msm: fix %s null argument error", " - platform/x86: ideapad-laptop: Make the scope_guard() clear of its scope", " - kselftest: dt: Ignore nodes that have ancestors disabled", " - drivers:drm:exynos_drm_gsc:Fix wrong assignment in gsc_bind()", " - drm/amdgpu: fix invalid fence handling in amdgpu_vm_tlb_flush", " - xen: use correct end address of kernel for conflict checking", " - HID: wacom: Support sequence numbers smaller than 16-bit", " - HID: wacom: Do not warn about dropped packets for first packet", " - ata: libata: Clear DID_TIME_OUT for ATA PT commands with sense data", " - xen: introduce generic helper checking for memory map conflicts", " - xen: move max_pfn in xen_memory_setup() out of function scope", " - xen: add capability to remap non-RAM pages to different PFNs", " - xen: tolerate ACPI NVS memory overlapping with Xen allocated memory", " - drm/xe: fix missing 'xe_vm_put'", " - xen/swiotlb: add alignment check for dma buffers", " - xen/swiotlb: fix allocated size", " - sched/fair: Make SCHED_IDLE entity be preempted in strict hierarchy", " - bpf, x64: Fix tailcall hierarchy", " - bpf, arm64: Fix tailcall hierarchy", " - bpf: Fix compare error in function retval_range_within", " - selftests/bpf: Workaround strict bpf_lsm return value check.", " - selftests/bpf: Fix error linking uprobe_multi on mips", " - selftests/bpf: Fix wrong binary in Makefile log output", " - tools/runqslower: Fix LDFLAGS and add LDLIBS support", " - selftests/bpf: Use pid_t consistently in test_progs.c", " - selftests/bpf: Fix compile error from rlim_t in sk_storage_map.c", " - selftests/bpf: Fix error compiling bpf_iter_setsockopt.c with musl libc", " - selftests/bpf: Drop unneeded error.h includes", " - selftests/bpf: Fix missing ARRAY_SIZE() definition in bench.c", " - selftests/bpf: Fix missing UINT_MAX definitions in benchmarks", " - selftests/bpf: Fix missing BUILD_BUG_ON() declaration", " - selftests/bpf: Fix include of ", " - selftests/bpf: Fix compiling parse_tcp_hdr_opt.c with musl-libc", " - selftests/bpf: Fix compiling kfree_skb.c with musl-libc", " - selftests/bpf: Fix compiling flow_dissector.c with musl-libc", " - selftests/bpf: Fix compiling tcp_rtt.c with musl-libc", " - selftests/bpf: Fix compiling core_reloc.c with musl-libc", " - selftests/bpf: Fix errors compiling lwt_redirect.c with musl libc", " - selftests/bpf: Fix errors compiling decap_sanity.c with musl libc", " - selftests/bpf: Fix errors compiling crypto_sanity.c with musl libc", " - selftests/bpf: Fix errors compiling cg_storage_multi.h with musl libc", " - libbpf: Don't take direct pointers into BTF data from st_ops", " - selftests/bpf: Fix arg parsing in veristat, test_progs", " - selftests/bpf: Fix error compiling test_lru_map.c", " - selftests/bpf: Fix C++ compile error from missing _Bool type", " - selftests/bpf: Fix redefinition errors compiling lwt_reroute.c", " - selftests/bpf: Fix compile if backtrace support missing in libc", " - selftests/bpf: Fix error compiling tc_redirect.c with musl libc", " - s390/entry: Move early program check handler to entry.S", " - s390/entry: Make early program check handler relocated lowcore aware", " - libbpf: Fix license for btf_relocate.c", " - samples/bpf: Fix compilation errors with cf-protection option", " - selftests/bpf: no need to track next_match_pos in struct test_loader", " - selftests/bpf: extract test_loader->expect_msgs as a data structure", " - selftests/bpf: allow checking xlated programs in verifier_* tests", " - selftests/bpf: __arch_* macro to limit test cases to specific archs", " - selftests/bpf: fix to avoid __msg tag de-duplication by clang", " - selftests/bpf: Fix incorrect parameters in NULL pointer checking", " - libbpf: Fix bpf_object__open_skeleton()'s mishandling of options", " - s390/ap: Fix deadlock caused by recursive lock of the AP bus scan mutex", " - libbpf: Ensure new BTF objects inherit input endianness", " - xz: cleanup CRC32 edits from 2018", " - kthread: fix task state in kthread worker if being frozen", " - ext4: clear EXT4_GROUP_INFO_WAS_TRIMMED_BIT even mount with discard", " - bpftool: Fix handling enum64 in btf dump sorting", " - sched/deadline: Fix schedstats vs deadline servers", " - smackfs: Use rcu_assign_pointer() to ensure safe assignment in smk_set_cipso", " - ext4: avoid buffer_head leak in ext4_mark_inode_used()", " - ext4: avoid potential buffer_head leak in __ext4_new_inode()", " - ext4: avoid negative min_clusters in find_group_orlov()", " - ext4: return error on ext4_find_inline_entry", " - sched/numa: Fix the vma scan starving issue", " - nilfs2: determine empty node blocks as corrupted", " - sched/pelt: Use rq_clock_task() for hw_pressure", " - bpf: Fix bpf_strtol and bpf_strtoul helpers for 32bit", " - bpf: Improve check_raw_mode_ok test for MEM_UNINIT-tagged types", " - perf scripts python cs-etm: Restore first sample log in verbose mode", " - perf bpf: Move BPF disassembly routines to separate file to avoid clash with", " capstone bpf headers", " - perf mem: Free the allocated sort string, fixing a leak", " - perf lock contention: Change stack_id type to s32", " - perf vendor events: SKX, CLX, SNR uncore cache event fixes", " - perf inject: Fix leader sampling inserting additional samples", " - perf report: Fix --total-cycles --stdio output error", " - perf build: Fix up broken capstone feature detection fast path", " - perf sched timehist: Fix missing free of session in perf_sched__timehist()", " - perf stat: Display iostat headers correctly", " - perf dwarf-aux: Check allowed location expressions when collecting variables", " - perf annotate-data: Fix off-by-one in location range check", " - perf dwarf-aux: Handle bitfield members from pointer access", " - perf hist: Don't set hpp_fmt_value for members in --no-group", " - perf sched timehist: Fixed timestamp error when unable to confirm event", " sched_in time", " - perf time-utils: Fix 32-bit nsec parsing", " - perf mem: Check mem_events for all eligible PMUs", " - perf mem: Fix missed p-core mem events on ADL and RPL", " - clk: imx: clk-audiomix: Correct parent clock for earc_phy and audpll", " - clk: imx: imx6ul: fix default parent for enet*_ref_sel", " - clk: imx: composite-8m: Enable gate clk with mcore_booted", " - clk: imx: composite-93: keep root clock on when mcore enabled", " - clk: imx: composite-7ulp: Check the PCC present bit", " - clk: imx: fracn-gppll: fix fractional part of PLL getting lost", " - clk: imx: imx8mp: fix clock tree update of TF-A managed clocks", " - clk: imx: imx8qxp: Register dc0_bypass0_clk before disp clk", " - clk: imx: imx8qxp: Parent should be initialized earlier than the clock", " - quota: avoid missing put_quota_format when DQUOT_SUSPENDED is passed", " - remoteproc: imx_rproc: Correct ddr alias for i.MX8M", " - remoteproc: imx_rproc: Initialize workqueue earlier", " - clk: rockchip: Set parent rate for DCLK_VOP clock on RK3228", " - clk: qcom: dispcc-sm8550: fix several supposed typos", " - clk: qcom: dispcc-sm8550: use rcg2_ops for mdss_dptx1_aux_clk_src", " - clk: qcom: dispcc-sm8650: Update the GDSC flags", " - clk: qcom: dispcc-sm8550: use rcg2_shared_ops for ESC RCGs", " - leds: bd2606mvv: Fix device child node usage in bd2606mvv_probe()", " - pinctrl: renesas: rzg2l: Return -EINVAL if the pin doesn't support", " PIN_CFG_OEN", " - pinctrl: ti: ti-iodelay: Fix some error handling paths", " - phy: phy-rockchip-samsung-hdptx: Explicitly include pm_runtime.h", " - Input: ilitek_ts_i2c - avoid wrong input subsystem sync", " - Input: ilitek_ts_i2c - add report id message validation", " - media: raspberrypi: VIDEO_RASPBERRYPI_PISP_BE should depend on ARCH_BCM2835", " - [Config] updateconfigs for VIDEO_RASPBERRYPI_PISP_BE", " - PCI: Wait for Link before restoring Downstream Buses", " - firewire: core: correct range of block for case of switch statement", " - media: staging: media: starfive: camss: Drop obsolete return value", " documentation", " - clk: qcom: ipq5332: Register gcc_qdss_tsctr_clk_src", " - clk: qcom: dispcc-sm8250: use special function for Lucid 5LPE PLL", " - leds: pca995x: Use device_for_each_child_node() to access device child nodes", " - leds: pca995x: Fix device child node usage in pca995x_probe()", " - x86/PCI: Check pcie_find_root_port() return for NULL", " - PCI: xilinx-nwl: Fix register misspelling", " - PCI: xilinx-nwl: Clean up clock on probe failure/removal", " - leds: gpio: Set num_leds after allocation", " - media: platform: rzg2l-cru: rzg2l-csi2: Add missing MODULE_DEVICE_TABLE", " - pinctrl: single: fix missing error code in pcs_probe()", " - clk: at91: sama7g5: Allocate only the needed amount of memory for PLLs", " - iommufd/selftest: Fix buffer read overrrun in the dirty test", " - RDMA/bnxt_re: Fix the table size for PSN/MSN entries", " - media: imagination: VIDEO_E5010_JPEG_ENC should depend on ARCH_K3", " - [Config] updateconfigs for VIDEO_E5010_JPEG_ENC", " - RDMA/rtrs: Reset hb_missed_cnt after receiving other traffic from peer", " - clk: ti: dra7-atl: Fix leak of of_nodes", " - clk: starfive: Use pm_runtime_resume_and_get to fix pm_runtime_get_sync()", " usage", " - clk: rockchip: rk3588: Fix 32k clock name for pmu_24m_32k_100m_src_p", " - nfsd: remove unneeded EEXIST error check in nfsd_do_file_acquire", " - nfsd: fix refcount leak when file is unhashed after being found", " - pinctrl: mvebu: Fix devinit_dove_pinctrl_probe function", " - dt-bindings: PCI: layerscape-pci: Replace fsl,lx2160a-pcie with", " fsl,lx2160ar2-pcie", " - iommufd: Check the domain owner of the parent before creating a nesting", " domain", " - RDMA/erdma: Return QP state in erdma_query_qp", " - RDMA/mlx5: Fix counter update on MR cache mkey creation", " - RDMA/mlx5: Limit usage of over-sized mkeys from the MR cache", " - RDMA/mlx5: Drop redundant work canceling from clean_keys()", " - RDMA/mlx5: Fix MR cache temp entries cleanup", " - watchdog: imx_sc_wdt: Don't disable WDT in suspend", " - RDMA/hns: Don't modify rq next block addr in HIP09 QPC", " - RDMA/hns: Fix the overflow risk of hem_list_calc_ba_range()", " - RDMA/hns: Fix VF triggering PF reset in abnormal interrupt handler", " - RDMA/hns: Fix 1bit-ECC recovery address in non-4K OS", " - RDMA/hns: Optimize hem allocation performance", " - RDMA/hns: Fix restricted __le16 degrades to integer issue", " - Input: ims-pcu - fix calling interruptible mutex", " - RDMA/mlx5: Obtain upper net device only when needed", " - PCI: qcom-ep: Enable controller resources like PHY only after refclk is", " available", " - riscv: Fix fp alignment bug in perf_callchain_user()", " - RDMA/hns: Fix ah error counter in sw stat not increasing", " - RDMA/irdma: fix error message in irdma_modify_qp_roce()", " - ntb_perf: Fix printk format", " - ntb: Force physically contiguous allocation of rx ring buffers", " - nfsd: untangle code in nfsd4_deleg_getattr_conflict()", " - nfsd: fix initial getattr on write delegation", " - crypto: caam - Pad SG length when allocating hash edesc", " - crypto: powerpc/p10-aes-gcm - Disable CRYPTO_AES_GCM_P10", " - [Config] disable CRYPTO_AES_GCM_P10", " - f2fs: atomic: fix to avoid racing w/ GC", " - f2fs: reduce expensive checkpoint trigger frequency", " - f2fs: fix to avoid racing in between read and OPU dio write", " - f2fs: Create COW inode from parent dentry for atomic write", " - f2fs: fix to wait page writeback before setting gcing flag", " - f2fs: atomic: fix to truncate pagecache before on-disk metadata truncation", " - f2fs: compress: don't redirty sparse cluster during {,de}compress", " - f2fs: prevent atomic file from being dirtied before commit", " - spi: airoha: fix dirmap_{read,write} operations", " - spi: airoha: fix airoha_snand_{write,read}_data data_len estimation", " - spi: atmel-quadspi: Undo runtime PM changes at driver exit time", " - spi: spi-fsl-lpspi: Undo runtime PM changes at driver exit time", " - lib/sbitmap: define swap_lock as raw_spinlock_t", " - spi: airoha: remove read cache in airoha_snand_dirmap_read()", " - spi: atmel-quadspi: Avoid overwriting delay register settings", " - NFSv4.2: Fix detection of \"Proxying of Times\" server support", " - nvme-multipath: system fails to create generic nvme device", " - iio: adc: ad7606: fix oversampling gpio array", " - iio: adc: ad7606: fix standby gpio state to match the documentation", " - driver core: Fix error handling in driver API device_rename()", " - ABI: testing: fix admv8818 attr description", " - iio: chemical: bme680: Fix read/write ops to device by adding mutexes", " - iio: magnetometer: ak8975: drop incorrect AK09116 compatible", " - dt-bindings: iio: asahi-kasei,ak8975: drop incorrect AK09116 compatible", " - serial: 8250: omap: Cleanup on error in request_irq", " - Coresight: Set correct cs_mode for TPDM to fix disable issue", " - Coresight: Set correct cs_mode for dummy source to fix disable issue", " - coresight: tmc: sg: Do not leak sg_table", " - interconnect: icc-clk: Add missed num_nodes initialization", " - interconnect: qcom: sm8250: Enable sync_state", " - dm integrity: fix gcc 5 warning", " - cxl/pci: Fix to record only non-zero ranges", " - um: remove ARCH_NO_PREEMPT_DYNAMIC", " - Revert \"dm: requeue IO if mapping table not yet available\"", " - net: phy: aquantia: fix -ETIMEDOUT PHY probe failure when firmware not", " present", " - net: xilinx: axienet: Schedule NAPI in two steps", " - net: xilinx: axienet: Fix packet counting", " - net: ipv6: select DST_CACHE from IPV6_RPL_LWTUNNEL", " - net: qrtr: Update packets cloning when broadcasting", " - net: phy: aquantia: fix setting active_low bit", " - net: phy: aquantia: fix applying active_low bit after reset", " - net: ravb: Fix maximum TX frame size for GbEth devices", " - net: ravb: Fix R-Car RX frame size limit", " - virtio_net: Fix mismatched buf address when unmapping for small packets", " - netfilter: nf_tables: Keep deleted flowtable hooks until after RCU", " - netfilter: ctnetlink: compile ctnetlink_label_size with", " CONFIG_NF_CONNTRACK_EVENTS", " - netfilter: nf_tables: use rcu chain hook list iterator from netlink dump", " path", " - netfilter: nf_tables: missing objects with no memcg accounting", " - selftests: netfilter: Avoid hanging ipvs.sh", " - io_uring/sqpoll: do not allow pinning outside of cpuset", " - io_uring/rw: treat -EOPNOTSUPP for IOCB_NOWAIT like -EAGAIN", " - io_uring: check for presence of task_work rather than TIF_NOTIFY_SIGNAL", " - mm: migrate: annotate data-race in migrate_folio_unmap()", " - drm/amd/display: Fix Synaptics Cascaded Panamera DSC Determination", " - drm/amd/display: Add DSC Debug Log", " - drm/amdgpu/display: Fix a mistake in revert commit", " - xen: move checks for e820 conflicts further up", " - xen: allow mapping ACPI data using a different physical address", " - io_uring/sqpoll: retain test for whether the CPU is valid", " - drm/amd/display: disable_hpo_dp_link_output: Check link_res->hpo_dp_link_enc", " before using it", " - io_uring/sqpoll: do not put cpumask on stack", " - selftests/bpf: correctly move 'log' upon successful match", " - Remove *.orig pattern from .gitignore", " - PCI: Revert to the original speed after PCIe failed link retraining", " - PCI: Clear the LBMS bit after a link retrain", " - PCI: dra7xx: Fix threaded IRQ request for \"dra7xx-pcie-main\" IRQ", " - PCI: imx6: Fix missing call to phy_power_off() in error handling", " - PCI: imx6: Fix establish link failure in EP mode for i.MX8MM and i.MX8MP", " - PCI: imx6: Fix i.MX8MP PCIe EP's occasional failure to trigger MSI", " - PCI: Correct error reporting with PCIe failed link retraining", " - PCI: Use an error code with PCIe failed link retraining", " - PCI: xilinx-nwl: Fix off-by-one in INTx IRQ handler", " - PCI: dra7xx: Fix error handling when IRQ request fails in probe", " - Revert \"soc: qcom: smd-rpm: Match rpmsg channel instead of compatible\"", " - ASoC: rt5682: Return devm_of_clk_add_hw_provider to transfer the error", " - soc: fsl: cpm1: qmc: Update TRNSYNC only in transparent mode", " - soc: fsl: cpm1: tsa: Fix tsa_write8()", " - soc: versatile: integrator: fix OF node leak in probe() error path", " - Revert \"media: tuners: fix error return code of", " hybrid_tuner_request_state()\"", " - iommu/amd: Fix argument order in amd_iommu_dev_flush_pasid_all()", " - Input: adp5588-keys - fix check on return code", " - Input: i8042 - add TUXEDO Stellaris 16 Gen5 AMD to i8042 quirk table", " - Input: i8042 - add TUXEDO Stellaris 15 Slim Gen6 AMD to i8042 quirk table", " - Input: i8042 - add another board name for TUXEDO Stellaris Gen5 AMD line", " - KVM: arm64: Add memory length checks and remove inline in do_ffa_mem_xfer", " - KVM: x86: Enforce x2APIC's must-be-zero reserved ICR bits", " - KVM: x86: Move x2APIC ICR helper above kvm_apic_write_nodecode()", " - KVM: x86: Re-split x2APIC ICR into ICR+ICR2 for AMD (x2AVIC)", " - drm/amdgpu/mes12: reduce timeout", " - drm/amdgpu/mes11: reduce timeout", " - drm/amdkfd: Add SDMA queue quantum support for GFX12", " - drm/amdgpu: update golden regs for gfx12", " - drm/amdgpu/mes12: set enable_level_process_quantum_check", " - drm/amdgpu/vcn: enable AV1 on both instances", " - drm/amd/pm: update workload mask after the setting", " - drm/amdgpu: fix PTE copy corruption for sdma 7", " - drm/amdgpu: bump driver version for cleared VRAM", " - drm/amdgpu/mes12: switch SET_SHADER_DEBUGGER pkt to mes schq pipe", " - drm/amdgpu: Fix selfring initialization sequence on soc24", " - drm/amd/display: Add HDMI DSC native YCbCr422 support", " - drm/amd/display: Round calculated vtotal", " - drm/amd/display: Clean up dsc blocks in accelerated mode", " - drm/amd/display: Block timing sync for different output formats in pmo", " - drm/amd/display: Validate backlight caps are sane", " - drm/amd/display: Disable SYMCLK32_LE root clock gating", " - drm/amd/display: Block dynamic IPS2 on DCN35 for incompatible FW versions", " - drm/amd/display: Enable DML2 override_det_buffer_size_kbytes", " - drm/amd/display: Skip to enable dsc if it has been off", " - drm/amd/display: Fix underflow when setting underscan on DCN401", " - drm/amd/display: Update IPS default mode for DCN35/DCN351", " - objtool: Handle frame pointer related instructions", " - powerpc/atomic: Use YZ constraints for DS-form instructions", " - ksmbd: make __dir_empty() compatible with POSIX", " - ksmbd: allow write with FILE_APPEND_DATA", " - ksmbd: handle caseless file creation", " - ata: libata-scsi: Fix ata_msense_control() CDL page reporting", " - scsi: ufs: qcom: Update MODE_MAX cfg_bw value", " - scsi: lpfc: Restrict support for 32 byte CDBs to specific HBAs", " - scsi: mac_scsi: Revise printk(KERN_DEBUG ...) messages", " - scsi: mac_scsi: Refactor polling loop", " - scsi: mac_scsi: Disallow bus errors during PDMA send", " - can: esd_usb: Remove CAN_CTRLMODE_3_SAMPLES for CAN-USB/3-FD", " - wifi: rtw88: Fix USB/SDIO devices not transmitting beacons", " - usbnet: fix cyclical race on disconnect with work queue", " - arm64: dts: mediatek: mt8195-cherry: Mark USB 3.0 on xhci1 as disabled", " - arm64: dts: mediatek: mt8395-nio-12l: Mark USB 3.0 on xhci1 as disabled", " - USB: appledisplay: close race between probe and completion handler", " - USB: misc: cypress_cy7c63: check for short transfer", " - USB: class: CDC-ACM: fix race between get_serial and set_serial", " - USB: misc: yurex: fix race between read and write", " - usb: xhci: fix loss of data on Cadence xHC", " - usb: cdnsp: Fix incorrect usb_request status", " - usb: xHCI: add XHCI_RESET_ON_RESUME quirk for Phytium xHCI host", " - usb: gadget: dummy_hcd: execute hrtimer callback in softirq context", " - usb: dwc2: drd: fix clock gating on USB role switch", " - bus: integrator-lm: fix OF node leak in probe()", " - bus: mhi: host: pci_generic: Update EDL firmware path for Foxconn modems", " - bus: mhi: host: pci_generic: Fix the name for the Telit FE990A", " - tty: rp2: Fix reset with non forgiving PCIe host bridges", " - pps: add an error check in parport_attach", " - serial: don't use uninitialized value in uart_poll_init()", " - xhci: Set quirky xHC PCI hosts to D3 _after_ stopping and freeing them.", " - serial: qcom-geni: fix fifo polling timeout", " - serial: qcom-geni: fix false console tx restart", " - crypto: qcom-rng - fix support for ACPI-based systems", " - crypto: ccp - Properly unregister /dev/sev on sev PLATFORM_STATUS failure", " - drbd: Fix atomicity violation in drbd_uuid_set_bm()", " - drbd: Add NULL check for net_conf to prevent dereference in state validation", " - ACPI: resource: Do IRQ override on MECHREV GM7XG0M", " - ACPI: resource: Add another DMI match for the TongFang GMxXGxx", " - intel_idle: add Granite Rapids Xeon support", " - intel_idle: fix ACPI _CST matching for newer Xeon platforms", " - x86/entry: Remove unwanted instrumentation in common_interrupt()", " - perf/x86/intel: Allow to setup LBR for counting event for BPF", " - perf/x86/intel/pt: Fix sampling synchronization", " - btrfs: subpage: fix the bitmap dump which can cause bitmap corruption", " - wifi: mt76: mt7921: Check devm_kasprintf() returned value", " - wifi: mt76: mt7915: check devm_kasprintf() returned value", " - idpf: fix netdev Tx queue stop/wake", " - wifi: rtw88: 8821cu: Remove VID/PID 0bda:c82c", " - wifi: rtw88: 8822c: Fix reported RX band width", " - wifi: rtw88: 8703b: Fix reported RX band width", " - wifi: mt76: mt7615: check devm_kasprintf() returned value", " - wifi: mt76: mt7925: fix a potential association failure upon resuming", " - debugfs show actual source in /proc/mounts", " - debugobjects: Fix conditions in fill_pool()", " - btrfs: tree-checker: fix the wrong output of data backref objectid", " - btrfs: always update fstrim_range on failure in FITRIM ioctl", " - f2fs: fix several potential integer overflows in file offsets", " - f2fs: prevent possible int overflow in dir_block_index()", " - f2fs: avoid potential int overflow in sanity_check_area_boundary()", " - hwrng: mtk - Use devm_pm_runtime_enable", " - hwrng: bcm2835 - Add missing clk_disable_unprepare in bcm2835_rng_init", " - hwrng: cctrng - Add missing clk_disable_unprepare in cctrng_resume", " - arm64: esr: Define ESR_ELx_EC_* constants as UL", " - arm64: errata: Enable the AC03_CPU_38 workaround for ampere1a", " - arm64: dts: mediatek: mt8186-corsola: Disable DPI display interface", " - arm64: dts: rockchip: Raise Pinebook Pro's panel backlight PWM frequency", " - arm64: dts: qcom: sa8775p: Mark APPS and PCIe SMMUs as DMA coherent", " - arm64: dts: rockchip: Correct the Pinebook Pro battery design capacity", " - fs: Fix file_set_fowner LSM hook inconsistencies", " - nfs: fix memory leak in error path of nfs4_do_reclaim", " - EDAC/igen6: Fix conversion of system address to physical memory address", " - eventpoll: Annotate data-race of busy_poll_usecs", " - md: Don't flush sync_work in md_write_start()", " - cpuidle: riscv-sbi: Use scoped device node handling to fix missing", " of_node_put", " - lsm: add the inode_free_security_rcu() LSM implementation hook", " - spi: fspi: involve lut_num for struct nxp_fspi_devtype_data", " - dt-bindings: spi: nxp-fspi: add imx8ulp support", " - ARM: dts: imx6ul-geam: fix fsl,pins property in tscgrp pinctrl", " - ARM: dts: imx6ull-seeed-npi: fix fsl,pins property in tscgrp pinctrl", " - tools/nolibc: include arch.h from string.h", " - soc: versatile: realview: fix memory leak during device remove", " - soc: versatile: realview: fix soc_dev leak during device remove", " - usb: typec: ucsi: Call CANCEL from single location", " - usb: typec: ucsi: Fix busy loop on ASUS VivoBooks", " - soc: qcom: geni-se: add GP_LENGTH/IRQ_EN_SET/IRQ_EN_CLEAR registers", " - serial: qcom-geni: fix arg types for qcom_geni_serial_poll_bit()", " - serial: qcom-geni: introduce qcom_geni_serial_poll_bitfield()", " - serial: qcom-geni: fix console corruption", " - thermal: core: Store trip sysfs attributes in thermal_trip_desc", " - thermal: sysfs: Get to trips via attribute pointers", " - thermal: sysfs: Refine the handling of trip hysteresis changes", " - thermal: sysfs: Add sanity checks for trip temperature and hysteresis", " - bpf: lsm: Set bpf_lsm_blob_sizes.lbs_task to 0", " - compiler.h: specify correct attribute for .rodata..c_jump_table", " - lockdep: fix deadlock issue between lockdep and rcu", " - mm/hugetlb_vmemmap: batch HVO work when demoting", " - s390/ftrace: Avoid calling unwinder in ftrace_return_address()", " - selftest mm/mseal: fix test_seal_mremap_move_dontunmap_anyaddr", " - mm: only enforce minimum stack gap size if it's sensible", " - spi: fspi: add support for imx8ulp", " - module: Fix KCOV-ignored file name", " - fbdev: xen-fbfront: Assign fb_info->device", " - tpm: export tpm2_sessions_init() to fix ibmvtpm building", " - mm/huge_memory: ensure huge_zero_folio won't have large_rmappable flag set", " - mm: change vmf_anon_prepare() to __vmf_anon_prepare()", " - mm/damon/vaddr: protect vma traversal in __damon_va_thre_regions() with rcu", " read lock", " - i2c: aspeed: Update the stop sw state when the bus recovery occurs", " - i2c: isch: Add missed 'else'", " - i2c: xiic: Try re-initialization on bus busy timeout", " - Documentation: KVM: fix warning in \"make htmldocs\"", " - spi: atmel-quadspi: Fix wrong register value written to MR", " - Revert: \"dm-verity: restart or panic on an I/O error\"", " - Linux 6.11.2", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47675", " - bpf: Fix use-after-free in bpf_uprobe_multi_link_attach()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47676", " - mm/hugetlb.c: fix UAF of vma in hugetlb fault pathway", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47677", " - exfat: resolve memory leak from exfat_create_upcase_table()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47725", " - dm-verity: restart or panic on an I/O error", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47739", " - padata: use integer wrap around to prevent deadlock on seq_nr overflow", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47678", " - icmp: change the order of rate limits", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47733", " - netfs: Delete subtree of 'fs/netfs' when netfs module exits", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47679", " - vfs: fix race between evice_inodes() and find_inode()&iput()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49859", " - f2fs: fix to check atomic_file in f2fs ioctl interfaces", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47680", " - f2fs: check discard support for conventional zones", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47740", " - f2fs: Require FMODE_WRITE for atomic write ioctls", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47726", " - f2fs: fix to wait dio completion", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47741", " - btrfs: fix race setting file private on concurrent lseek using same fd", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47681", " - wifi: mt76: mt7996: fix NULL pointer dereference in mt7996_mcu_sta_bfer_he", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49858", " - efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49860", " - ACPI: sysfs: validate return type of _STR method", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47742", " - firmware_loader: Block path traversal", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47682", " - scsi: sd: Fix off-by-one error in sd_read_block_characteristics()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47743", " - KEYS: prevent NULL pointer dereference in find_asymmetric_key()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47727", " - x86/tdx: Fix \"in-kernel MMIO\" check", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47744", " - KVM: Use dedicated mutex to protect kvm_usage_count to avoid deadlock", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47719", " - iommufd: Protect against overflow of ALIGN() during iova allocation", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47745", " - mm: call the security_mmap_file() LSM hook in remap_file_pages()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47746", " - fuse: use exclusive lock when FUSE_I_CACHE_IO_MODE is set", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47734", " - bonding: Fix unnecessary warnings and logs from bond_xdp_get_xmit_slave()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47684", " - tcp: check skb is non-NULL in tcp_rto_delta_us()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47747", " - net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race", " Condition", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47685", " - netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47686", " - ep93xx: clock: Fix off by one in ep93xx_div_recalc_rate()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47748", " - vhost_vdpa: assign irq bypass producer token correctly", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47687", " - vdpa/mlx5: Fix invalid mr resource destroy", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47688", " - driver core: Fix a potential null-ptr-deref in module_add_driver()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47689", " - f2fs: fix to don't set SB_RDONLY in f2fs_handle_critical_error()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47690", " - f2fs: get rid of online repaire on corrupted directory", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47691", " - f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47692", " - nfsd: return -EINVAL when namelen is 0", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47737", " - nfsd: call cache_put if xdr_reserve_space returns NULL", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2023-52917", " - ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47749", " - RDMA/cxgb4: Added NULL check for lookup_atid", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47735", " - RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47750", " - RDMA/hns: Fix Use-After-Free of rsv_qp on HIP08", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47751", " - PCI: kirin: Fix buffer overflow in kirin_pcie_parse_port()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47693", " - IB/core: Fix ib_cache_setup_one error flow cleanup", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47694", " - IB/mlx5: Fix UMR pd cleanup on error flow of driver init", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47695", " - RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47752", " - media: mediatek: vcodec: Fix H264 stateless decoder smatch warning", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47753", " - media: mediatek: vcodec: Fix VP8 stateless decoder smatch warning", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47754", " - media: mediatek: vcodec: Fix H264 multi stateless decoder smatch warning", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47696", " - RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47755", " - nvdimm: Fix devs leaks in scan_labels()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47756", " - PCI: keystone: Fix if-statement expression in ks_pcie_quirk()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47697", " - drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47698", " - drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47728", " - bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49861", " - bpf: Fix helper writes to read-only maps", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47757", " - nilfs2: fix potential oob read in nilfs_btree_check_delete()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47699", " - nilfs2: fix potential null-ptr-deref in nilfs_btree_insert()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47700", " - ext4: check stripe size compatibility on remount as well", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47701", " - ext4: avoid OOB when system.data xattr changes underneath the filesystem", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49850", " - bpf: correctly handle malformed BPF_CORE_TYPE_ID_LOCAL relos", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47702", " - bpf: Fail verification for sign-extension of packet data/data_end/data_meta", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47703", " - bpf, lsm: Add check for BPF LSM return value", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49851", " - tpm: Clean up TPM space after command failure", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47723", " - jfs: fix out-of-bounds in dbNextAG() and diAlloc()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49852", " - scsi: elx: libefc: Fix potential use after free in efc_nport_vport_del()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47720", " - drm/amd/display: Add null check for set_output_gamma in", " dcn30_set_output_transfer_func", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47704", " - drm/amd/display: Check link_res->hpo_dp_link_enc before using it", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49853", " - firmware: arm_scmi: Fix double free in OPTEE transport", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47705", " - block: fix potential invalid pointer dereference in blk_add_partition", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47736", " - erofs: handle overlapped pclusters out of crafted images properly", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47706", " - block, bfq: fix possible UAF for bfqq->bic with merge chain", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49855", " - nbd: fix race between timeout and normal completion", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47707", " - ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47708", " - netkit: Assign missing bpf_net_context", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47709", " - can: bcm: Clear bo->bcm_proc_read after remove_proc_entry().", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47710", " - sock_map: Add a cond_resched() in sock_hash_free()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47711", " - af_unix: Don't return OOB skb in manage_oob().", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47712", " - wifi: wilc1000: fix potential RCU dereference issue in", " wilc_parse_join_bss_param", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47713", " - wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47730", " - crypto: hisilicon/qm - inject error before stopping queue", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49856", " - x86/sgx: Fix deadlock in SGX NUMA node search", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47714", " - wifi: mt76: mt7996: use hweight16 to get correct tx antenna", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47715", " - wifi: mt76: mt7915: fix oops on non-dbdc mt7986", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49857", " - wifi: iwlwifi: mvm: set the cipher for secured NDP ranging", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47738", " - wifi: mac80211: don't use rate mask for offchannel TX either", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47731", " - drivers/perf: Fix ali_drw_pmu driver interrupt status clearing", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49862", " - powercap: intel_rapl: Fix off by one in get_rpi()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47716", " - ARM: 9410/1: vfp: Use asm volatile in fmrx/fmxr macros", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47717", " - RISC-V: KVM: Don't zero-out PMU snapshot area before freeing data", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47721", " - wifi: rtw89: remove unused C2H event ID RTW89_MAC_C2H_FUNC_READ_WOW_CAM to", " prevent out-of-bounds reading", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47732", " - crypto: iaa - Fix potential use after free bug", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47718", " - wifi: rtw88: always wait for both firmware loading attempts", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47724", " - wifi: ath11k: use work queue to process beacon tx event", "", " * Oracular update: v6.11.1 upstream stable release (LP: #2089020)", " - powercap/intel_rapl: Add support for AMD family 1Ah", " - powercap/intel_rapl: Fix the energy-pkg event for AMD CPUs", " - cpufreq/amd-pstate: Add the missing cpufreq_cpu_put()", " - netfilter: nft_socket: Fix a NULL vs IS_ERR() bug in", " nft_socket_cgroup_subtree_level()", " - ASoC: amd: acp: add ZSC control register programming sequence", " - nvme-pci: qdepth 1 quirk", " - USB: serial: pl2303: add device id for Macrosilicon MS3020", " - powercap: intel_rapl: Change an error pointer to NULL", " - Linux 6.11.1", "", " * Oracular update: v6.11.1 upstream stable release (LP: #2089020) //", " CVE-2024-47671", " - USB: usbtmc: prevent kernel-usb-infoleak", "", " * Oracular update: v6.11.1 upstream stable release (LP: #2089020) //", " CVE-2024-46869", " - Bluetooth: btintel_pcie: Allocate memory for driver private data", "", " * CVE-2024-53164", " - net: sched: fix ordering of qlen adjustment", "", " * CVE-2024-53103", " - hv_sock: Initializing vsk->trans to NULL to prevent a dangling pointer", "" ], "package": "linux", "version": "6.11.0-17.17", "urgency": "medium", "distributions": "oracular", "launchpad_bugs_fixed": [ 2093643, 1786013, 2091744, 2091184, 2093146, 2085406, 2089684, 2090932, 2085485, 2089357, 2089306, 2091655, 2091655, 2091655, 2091655, 2091655, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091386, 2091990, 2089327, 2089113, 2086587, 2086606, 2085950, 2085944, 2087853, 2087983, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089020, 2089020, 2089020 ], "author": "Stefan Bader ", "date": "Thu, 16 Jan 2025 22:38:59 +0100" } ], "notes": "linux-modules-6.11.0-18-generic version '6.11.0-18.18' (source package linux version '6.11.0-18.18') was added. linux-modules-6.11.0-18-generic version '6.11.0-18.18' has the same source package name, linux, as removed package linux-headers-6.11.0-14. As such we can use the source package version of the removed package, '6.11.0-14.15', 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." }, { "name": "linux-tools-6.11.0-18", "from_version": { "source_package_name": "linux", "source_package_version": "6.11.0-14.15", "version": null }, "to_version": { "source_package_name": "linux", "source_package_version": "6.11.0-18.18", "version": "6.11.0-18.18" }, "cves": [ { "cve": "CVE-2025-0927", "url": "https://ubuntu.com/security/CVE-2025-0927", "cve_description": "[fs: hfs/hfsplus: add key_len boundary check to hfs_bnode_read_key]", "cve_priority": "medium", "cve_public_date": "2025-02-13" }, { "cve": "CVE-2024-53141", "url": "https://ubuntu.com/security/CVE-2024-53141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: add missing range check in bitmap_ip_uadt When tb[IPSET_ATTR_IP_TO] is not present but tb[IPSET_ATTR_CIDR] exists, the values of ip and ip_to are slightly swapped. Therefore, the range check for ip should be done later, but this part is missing and it seems that the vulnerability occurs. So we should add missing range checks and remove unnecessary range checks.", "cve_priority": "medium", "cve_public_date": "2024-12-06 10:15:00 UTC" }, { "cve": "CVE-2024-50010", "url": "https://ubuntu.com/security/CVE-2024-50010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exec: don't WARN for racy path_noexec check Both i_mode and noexec checks wrapped in WARN_ON stem from an artifact of the previous implementation. They used to legitimately check for the condition, but that got moved up in two commits: 633fb6ac3980 (\"exec: move S_ISREG() check earlier\") 0fd338b2d2cd (\"exec: move path_noexec() check earlier\") Instead of being removed said checks are WARN_ON'ed instead, which has some debug value. However, the spurious path_noexec check is racy, resulting in unwarranted warnings should someone race with setting the noexec flag. One can note there is more to perm-checking whether execve is allowed and none of the conditions are guaranteed to still hold after they were tested for. Additionally this does not validate whether the code path did any perm checking to begin with -- it will pass if the inode happens to be regular. Keep the redundant path_noexec() check even though it's mindless nonsense checking for guarantee that isn't given so drop the WARN. Reword the commentary and do small tidy ups while here. [brauner: keep redundant path_noexec() check]", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-53143", "url": "https://ubuntu.com/security/CVE-2024-53143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fsnotify: Fix ordering of iput() and watched_objects decrement Ensure the superblock is kept alive until we're done with iput(). Holding a reference to an inode is not allowed unless we ensure the superblock stays alive, which fsnotify does by keeping the watched_objects count elevated, so iput() must happen before the watched_objects decrement. This can lead to a UAF of something like sb->s_fs_info in tmpfs, but the UAF is hard to hit because race orderings that oops are more likely, thanks to the CHECK_DATA_CORRUPTION() block in generic_shutdown_super(). Also, ensure that fsnotify_put_sb_watched_objects() doesn't call fsnotify_sb_watched_objects() on a superblock that may have already been freed, which would cause a UAF read of sb->s_fsnotify_info.", "cve_priority": "medium", "cve_public_date": "2024-12-07 07:15:00 UTC" }, { "cve": "CVE-2024-53142", "url": "https://ubuntu.com/security/CVE-2024-53142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: initramfs: avoid filename buffer overrun The initramfs filename field is defined in Documentation/driver-api/early-userspace/buffer-format.rst as: 37 cpio_file := ALGN(4) + cpio_header + filename + \"\\0\" + ALGN(4) + data ... 55 ============= ================== ========================= 56 Field name Field size Meaning 57 ============= ================== ========================= ... 70 c_namesize 8 bytes Length of filename, including final \\0 When extracting an initramfs cpio archive, the kernel's do_name() path handler assumes a zero-terminated path at @collected, passing it directly to filp_open() / init_mkdir() / init_mknod(). If a specially crafted cpio entry carries a non-zero-terminated filename and is followed by uninitialized memory, then a file may be created with trailing characters that represent the uninitialized memory. The ability to create an initramfs entry would imply already having full control of the system, so the buffer overrun shouldn't be considered a security vulnerability. Append the output of the following bash script to an existing initramfs and observe any created /initramfs_test_fname_overrunAA* path. E.g. ./reproducer.sh | gzip >> /myinitramfs It's easiest to observe non-zero uninitialized memory when the output is gzipped, as it'll overflow the heap allocated @out_buf in __gunzip(), rather than the initrd_start+initrd_size block. ---- reproducer.sh ---- nilchar=\"A\"\t# change to \"\\0\" to properly zero terminate / pad magic=\"070701\" ino=1 mode=$(( 0100777 )) uid=0 gid=0 nlink=1 mtime=1 filesize=0 devmajor=0 devminor=1 rdevmajor=0 rdevminor=0 csum=0 fname=\"initramfs_test_fname_overrun\" namelen=$(( ${#fname} + 1 ))\t# plus one to account for terminator printf \"%s%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%s\" \\ \t$magic $ino $mode $uid $gid $nlink $mtime $filesize \\ \t$devmajor $devminor $rdevmajor $rdevminor $namelen $csum $fname termpadlen=$(( 1 + ((4 - ((110 + $namelen) & 3)) % 4) )) printf \"%.s${nilchar}\" $(seq 1 $termpadlen) ---- reproducer.sh ---- Symlink filename fields handled in do_symlink() won't overrun past the data segment, due to the explicit zero-termination of the symlink target. Fix filename buffer overrun by aborting the initramfs FSM if any cpio entry doesn't carry a zero-terminator at the expected (name_len - 1) offset.", "cve_priority": "medium", "cve_public_date": "2024-12-06 10:15:00 UTC" }, { "cve": "CVE-2024-53133", "url": "https://ubuntu.com/security/CVE-2024-53133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Handle dml allocation failure to avoid crash [Why] In the case where a dml allocation fails for any reason, the current state's dml contexts would no longer be valid. Then subsequent calls dc_state_copy_internal would shallow copy invalid memory and if the new state was released, a double free would occur. [How] Reset dml pointers in new_state to NULL and avoid invalid pointer (cherry picked from commit bcafdc61529a48f6f06355d78eb41b3aeda5296c)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53108", "url": "https://ubuntu.com/security/CVE-2024-53108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Adjust VSDB parser for replay feature At some point, the IEEE ID identification for the replay check in the AMD EDID was added. However, this check causes the following out-of-bounds issues when using KASAN: [ 27.804016] BUG: KASAN: slab-out-of-bounds in amdgpu_dm_update_freesync_caps+0xefa/0x17a0 [amdgpu] [ 27.804788] Read of size 1 at addr ffff8881647fdb00 by task systemd-udevd/383 ... [ 27.821207] Memory state around the buggy address: [ 27.821215] ffff8881647fda00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821224] ffff8881647fda80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821234] >ffff8881647fdb00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821243] ^ [ 27.821250] ffff8881647fdb80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821259] ffff8881647fdc00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821268] ================================================================== This is caused because the ID extraction happens outside of the range of the edid lenght. This commit addresses this issue by considering the amd_vsdb_block size. (cherry picked from commit b7e381b1ccd5e778e3d9c44c669ad38439a861d8)", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53134", "url": "https://ubuntu.com/security/CVE-2024-53134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pmdomain: imx93-blk-ctrl: correct remove path The check condition should be 'i < bc->onecell_data.num_domains', not 'bc->onecell_data.num_domains' which will make the look never finish and cause kernel panic. Also disable runtime to address \"imx93-blk-ctrl 4ac10000.system-controller: Unbalanced pm_runtime_enable!\"", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53132", "url": "https://ubuntu.com/security/CVE-2024-53132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/oa: Fix \"Missing outer runtime PM protection\" warning Fix the following drm_WARN: [953.586396] xe 0000:00:02.0: [drm] Missing outer runtime PM protection ... <4> [953.587090] ? xe_pm_runtime_get_noresume+0x8d/0xa0 [xe] <4> [953.587208] guc_exec_queue_add_msg+0x28/0x130 [xe] <4> [953.587319] guc_exec_queue_fini+0x3a/0x40 [xe] <4> [953.587425] xe_exec_queue_destroy+0xb3/0xf0 [xe] <4> [953.587515] xe_oa_release+0x9c/0xc0 [xe] (cherry picked from commit b107c63d2953907908fd0cafb0e543b3c3167b75)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53127", "url": "https://ubuntu.com/security/CVE-2024-53127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Revert \"mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K\" The commit 8396c793ffdf (\"mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K\") increased the max_req_size, even for 4K pages, causing various issues: - Panic booting the kernel/rootfs from an SD card on Rockchip RK3566 - Panic booting the kernel/rootfs from an SD card on StarFive JH7100 - \"swiotlb buffer is full\" and data corruption on StarFive JH7110 At this stage no fix have been found, so it's probably better to just revert the change. This reverts commit 8396c793ffdf28bb8aee7cfe0891080f8cab7890.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53130", "url": "https://ubuntu.com/security/CVE-2024-53130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint When using the \"block:block_dirty_buffer\" tracepoint, mark_buffer_dirty() may cause a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because, since the tracepoint was added in mark_buffer_dirty(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, nilfs_grab_buffer(), which grabs a buffer to read (or create) a block of metadata, including b-tree node blocks, does not set the block device, but instead does so only if the buffer is not in the \"uptodate\" state for each of its caller block reading functions. However, if the uptodate flag is set on a folio/page, and the buffer heads are detached from it by try_to_free_buffers(), and new buffer heads are then attached by create_empty_buffers(), the uptodate flag may be restored to each buffer without the block device being set to bh->b_bdev, and mark_buffer_dirty() may be called later in that state, resulting in the bug mentioned above. Fix this issue by making nilfs_grab_buffer() always set the block device of the super block structure to the buffer head, regardless of the state of the buffer's uptodate flag.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53105", "url": "https://ubuntu.com/security/CVE-2024-53105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: page_alloc: move mlocked flag clearance into free_pages_prepare() Syzbot reported a bad page state problem caused by a page being freed using free_page() still having a mlocked flag at free_pages_prepare() stage: BUG: Bad page state in process syz.5.504 pfn:61f45 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x61f45 flags: 0xfff00000080204(referenced|workingset|mlocked|node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000080204 0000000000000000 dead000000000122 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set page_owner tracks the page as allocated page last allocated via order 0, migratetype Unmovable, gfp_mask 0x400dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO), pid 8443, tgid 8442 (syz.5.504), ts 201884660643, free_ts 201499827394 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1537 prep_new_page mm/page_alloc.c:1545 [inline] get_page_from_freelist+0x303f/0x3190 mm/page_alloc.c:3457 __alloc_pages_noprof+0x292/0x710 mm/page_alloc.c:4733 alloc_pages_mpol_noprof+0x3e8/0x680 mm/mempolicy.c:2265 kvm_coalesced_mmio_init+0x1f/0xf0 virt/kvm/coalesced_mmio.c:99 kvm_create_vm virt/kvm/kvm_main.c:1235 [inline] kvm_dev_ioctl_create_vm virt/kvm/kvm_main.c:5488 [inline] kvm_dev_ioctl+0x12dc/0x2240 virt/kvm/kvm_main.c:5530 __do_compat_sys_ioctl fs/ioctl.c:1007 [inline] __se_compat_sys_ioctl+0x510/0xc90 fs/ioctl.c:950 do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline] __do_fast_syscall_32+0xb4/0x110 arch/x86/entry/common.c:386 do_fast_syscall_32+0x34/0x80 arch/x86/entry/common.c:411 entry_SYSENTER_compat_after_hwframe+0x84/0x8e page last free pid 8399 tgid 8399 stack trace: reset_page_owner include/linux/page_owner.h:25 [inline] free_pages_prepare mm/page_alloc.c:1108 [inline] free_unref_folios+0xf12/0x18d0 mm/page_alloc.c:2686 folios_put_refs+0x76c/0x860 mm/swap.c:1007 free_pages_and_swap_cache+0x5c8/0x690 mm/swap_state.c:335 __tlb_batch_free_encoded_pages mm/mmu_gather.c:136 [inline] tlb_batch_pages_flush mm/mmu_gather.c:149 [inline] tlb_flush_mmu_free mm/mmu_gather.c:366 [inline] tlb_flush_mmu+0x3a3/0x680 mm/mmu_gather.c:373 tlb_finish_mmu+0xd4/0x200 mm/mmu_gather.c:465 exit_mmap+0x496/0xc40 mm/mmap.c:1926 __mmput+0x115/0x390 kernel/fork.c:1348 exit_mm+0x220/0x310 kernel/exit.c:571 do_exit+0x9b2/0x28e0 kernel/exit.c:926 do_group_exit+0x207/0x2c0 kernel/exit.c:1088 __do_sys_exit_group kernel/exit.c:1099 [inline] __se_sys_exit_group kernel/exit.c:1097 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1097 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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 Modules linked in: CPU: 0 UID: 0 PID: 8442 Comm: syz.5.504 Not tainted 6.12.0-rc6-syzkaller #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 bad_page+0x176/0x1d0 mm/page_alloc.c:501 free_page_is_bad mm/page_alloc.c:918 [inline] free_pages_prepare mm/page_alloc.c:1100 [inline] free_unref_page+0xed0/0xf20 mm/page_alloc.c:2638 kvm_destroy_vm virt/kvm/kvm_main.c:1327 [inline] kvm_put_kvm+0xc75/0x1350 virt/kvm/kvm_main.c:1386 kvm_vcpu_release+0x54/0x60 virt/kvm/kvm_main.c:4143 __fput+0x23f/0x880 fs/file_table.c:431 task_work_run+0x24f/0x310 kernel/task_work.c:239 exit_task_work include/linux/task_work.h:43 [inline] do_exit+0xa2f/0x28e0 kernel/exit.c:939 do_group_exit+0x207/0x2c0 kernel/exit.c:1088 __do_sys_exit_group kernel/exit.c:1099 [in ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53109", "url": "https://ubuntu.com/security/CVE-2024-53109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nommu: pass NULL argument to vma_iter_prealloc() When deleting a vma entry from a maple tree, it has to pass NULL to vma_iter_prealloc() in order to calculate internal state of the tree, but it passed a wrong argument. As a result, nommu kernels crashed upon accessing a vma iterator, such as acct_collect() reading the size of vma entries after do_munmap(). This commit fixes this issue by passing a right argument to the preallocation call.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53131", "url": "https://ubuntu.com/security/CVE-2024-53131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint Patch series \"nilfs2: fix null-ptr-deref bugs on block tracepoints\". This series fixes null pointer dereference bugs that occur when using nilfs2 and two block-related tracepoints. This patch (of 2): It has been reported that when using \"block:block_touch_buffer\" tracepoint, touch_buffer() called from __nilfs_get_folio_block() causes a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because since the tracepoint was added in touch_buffer(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, the block_device structure is set after the function returns to the caller. Here, touch_buffer() is used to mark the folio/page that owns the buffer head as accessed, but the common search helper for folio/page used by the caller function was optimized to mark the folio/page as accessed when it was reimplemented a long time ago, eliminating the need to call touch_buffer() here in the first place. So this solves the issue by eliminating the touch_buffer() call itself.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53135", "url": "https://ubuntu.com/security/CVE-2024-53135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: VMX: Bury Intel PT virtualization (guest/host mode) behind CONFIG_BROKEN Hide KVM's pt_mode module param behind CONFIG_BROKEN, i.e. disable support for virtualizing Intel PT via guest/host mode unless BROKEN=y. There are myriad bugs in the implementation, some of which are fatal to the guest, and others which put the stability and health of the host at risk. For guest fatalities, the most glaring issue is that KVM fails to ensure tracing is disabled, and *stays* disabled prior to VM-Enter, which is necessary as hardware disallows loading (the guest's) RTIT_CTL if tracing is enabled (enforced via a VMX consistency check). Per the SDM: If the logical processor is operating with Intel PT enabled (if IA32_RTIT_CTL.TraceEn = 1) at the time of VM entry, the \"load IA32_RTIT_CTL\" VM-entry control must be 0. On the host side, KVM doesn't validate the guest CPUID configuration provided by userspace, and even worse, uses the guest configuration to decide what MSRs to save/load at VM-Enter and VM-Exit. E.g. configuring guest CPUID to enumerate more address ranges than are supported in hardware will result in KVM trying to passthrough, save, and load non-existent MSRs, which generates a variety of WARNs, ToPA ERRORs in the host, a potential deadlock, etc.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53106", "url": "https://ubuntu.com/security/CVE-2024-53106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: fix buffer overrun in ima_eventdigest_init_common Function ima_eventdigest_init() calls ima_eventdigest_init_common() with HASH_ALGO__LAST which is then used to access the array hash_digest_size[] leading to buffer overrun. Have a conditional statement to handle this.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53110", "url": "https://ubuntu.com/security/CVE-2024-53110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vp_vdpa: fix id_table array not null terminated error Allocate one extra virtio_device_id as null terminator, otherwise vdpa_mgmtdev_get_classes() may iterate multiple times and visit undefined memory.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53126", "url": "https://ubuntu.com/security/CVE-2024-53126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa: solidrun: Fix UB bug with devres In psnet_open_pf_bar() and snet_open_vf_bar() a string later passed to pcim_iomap_regions() is placed on the stack. Neither pcim_iomap_regions() nor the functions it calls copy that string. Should the string later ever be used, this, consequently, causes undefined behavior since the stack frame will by then have disappeared. Fix the bug by allocating the strings on the heap through devm_kasprintf().", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53111", "url": "https://ubuntu.com/security/CVE-2024-53111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mremap: fix address wraparound in move_page_tables() On 32-bit platforms, it is possible for the expression `len + old_addr < old_end` to be false-positive if `len + old_addr` wraps around. `old_addr` is the cursor in the old range up to which page table entries have been moved; so if the operation succeeded, `old_addr` is the *end* of the old region, and adding `len` to it can wrap. The overflow causes mremap() to mistakenly believe that PTEs have been copied; the consequence is that mremap() bails out, but doesn't move the PTEs back before the new VMA is unmapped, causing anonymous pages in the region to be lost. So basically if userspace tries to mremap() a private-anon region and hits this bug, mremap() will return an error and the private-anon region's contents appear to have been zeroed. The idea of this check is that `old_end - len` is the original start address, and writing the check that way also makes it easier to read; so fix the check by rearranging the comparison accordingly. (An alternate fix would be to refactor this function by introducing an \"orig_old_start\" variable or such.) Tested in a VM with a 32-bit X86 kernel; without the patch: ``` user@horn:~/big_mremap$ cat test.c #define _GNU_SOURCE #include #include #include #include #define ADDR1 ((void*)0x60000000) #define ADDR2 ((void*)0x10000000) #define SIZE 0x50000000uL int main(void) { unsigned char *p1 = mmap(ADDR1, SIZE, PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0); if (p1 == MAP_FAILED) err(1, \"mmap 1\"); unsigned char *p2 = mmap(ADDR2, SIZE, PROT_NONE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0); if (p2 == MAP_FAILED) err(1, \"mmap 2\"); *p1 = 0x41; printf(\"first char is 0x%02hhx\\n\", *p1); unsigned char *p3 = mremap(p1, SIZE, SIZE, MREMAP_MAYMOVE|MREMAP_FIXED, p2); if (p3 == MAP_FAILED) { printf(\"mremap() failed; first char is 0x%02hhx\\n\", *p1); } else { printf(\"mremap() succeeded; first char is 0x%02hhx\\n\", *p3); } } user@horn:~/big_mremap$ gcc -static -o test test.c user@horn:~/big_mremap$ setarch -R ./test first char is 0x41 mremap() failed; first char is 0x00 ``` With the patch: ``` user@horn:~/big_mremap$ setarch -R ./test first char is 0x41 mremap() succeeded; first char is 0x41 ```", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53107", "url": "https://ubuntu.com/security/CVE-2024-53107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: prevent integer overflow in pagemap_scan_get_args() The \"arg->vec_len\" variable is a u64 that comes from the user at the start of the function. The \"arg->vec_len * sizeof(struct page_region))\" multiplication can lead to integer wrapping. Use size_mul() to avoid that. Also the size_add/mul() functions work on unsigned long so for 32bit systems we need to ensure that \"arg->vec_len\" fits in an unsigned long.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53128", "url": "https://ubuntu.com/security/CVE-2024-53128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/task_stack: fix object_is_on_stack() for KASAN tagged pointers When CONFIG_KASAN_SW_TAGS and CONFIG_KASAN_STACK are enabled, the object_is_on_stack() function may produce incorrect results due to the presence of tags in the obj pointer, while the stack pointer does not have tags. This discrepancy can lead to incorrect stack object detection and subsequently trigger warnings if CONFIG_DEBUG_OBJECTS is also enabled. Example of the warning: ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at lib/debugobjects.c:557 __debug_object_init+0x330/0x364 Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5 #4 Hardware name: linux,dummy-virt (DT) pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __debug_object_init+0x330/0x364 lr : __debug_object_init+0x330/0x364 sp : ffff800082ea7b40 x29: ffff800082ea7b40 x28: 98ff0000c0164518 x27: 98ff0000c0164534 x26: ffff800082d93ec8 x25: 0000000000000001 x24: 1cff0000c00172a0 x23: 0000000000000000 x22: ffff800082d93ed0 x21: ffff800081a24418 x20: 3eff800082ea7bb0 x19: efff800000000000 x18: 0000000000000000 x17: 00000000000000ff x16: 0000000000000047 x15: 206b63617473206e x14: 0000000000000018 x13: ffff800082ea7780 x12: 0ffff800082ea78e x11: 0ffff800082ea790 x10: 0ffff800082ea79d x9 : 34d77febe173e800 x8 : 34d77febe173e800 x7 : 0000000000000001 x6 : 0000000000000001 x5 : feff800082ea74b8 x4 : ffff800082870a90 x3 : ffff80008018d3c4 x2 : 0000000000000001 x1 : ffff800082858810 x0 : 0000000000000050 Call trace: __debug_object_init+0x330/0x364 debug_object_init_on_stack+0x30/0x3c schedule_hrtimeout_range_clock+0xac/0x26c schedule_hrtimeout+0x1c/0x30 wait_task_inactive+0x1d4/0x25c kthread_bind_mask+0x28/0x98 init_rescuer+0x1e8/0x280 workqueue_init+0x1a0/0x3cc kernel_init_freeable+0x118/0x200 kernel_init+0x28/0x1f0 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53112", "url": "https://ubuntu.com/security/CVE-2024-53112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: uncache inode which has failed entering the group Syzbot has reported the following BUG: kernel BUG at fs/ocfs2/uptodate.c:509! ... Call Trace: ? __die_body+0x5f/0xb0 ? die+0x9e/0xc0 ? do_trap+0x15a/0x3a0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? do_error_trap+0x1dc/0x2c0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? __pfx_do_error_trap+0x10/0x10 ? handle_invalid_op+0x34/0x40 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? exc_invalid_op+0x38/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? ocfs2_set_new_buffer_uptodate+0x2e/0x160 ? ocfs2_set_new_buffer_uptodate+0x144/0x160 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ocfs2_group_add+0x39f/0x15a0 ? __pfx_ocfs2_group_add+0x10/0x10 ? __pfx_lock_acquire+0x10/0x10 ? mnt_get_write_access+0x68/0x2b0 ? __pfx_lock_release+0x10/0x10 ? rcu_read_lock_any_held+0xb7/0x160 ? __pfx_rcu_read_lock_any_held+0x10/0x10 ? smack_log+0x123/0x540 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x226/0x2b0 ocfs2_ioctl+0x65e/0x7d0 ? __pfx_ocfs2_ioctl+0x10/0x10 ? smack_file_ioctl+0x29e/0x3a0 ? __pfx_smack_file_ioctl+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x43d/0x780 ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10 ? __pfx_ocfs2_ioctl+0x10/0x10 __se_sys_ioctl+0xfb/0x170 do_syscall_64+0xf3/0x230 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... When 'ioctl(OCFS2_IOC_GROUP_ADD, ...)' has failed for the particular inode in 'ocfs2_verify_group_and_input()', corresponding buffer head remains cached and subsequent call to the same 'ioctl()' for the same inode issues the BUG() in 'ocfs2_set_new_buffer_uptodate()' (trying to cache the same buffer head of that inode). Fix this by uncaching the buffer head with 'ocfs2_remove_from_cache()' on error path in 'ocfs2_group_add()'.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53113", "url": "https://ubuntu.com/security/CVE-2024-53113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: fix NULL pointer dereference in alloc_pages_bulk_noprof We triggered a NULL pointer dereference for ac.preferred_zoneref->zone in alloc_pages_bulk_noprof() when the task is migrated between cpusets. When cpuset is enabled, in prepare_alloc_pages(), ac->nodemask may be ¤t->mems_allowed. when first_zones_zonelist() is called to find preferred_zoneref, the ac->nodemask may be modified concurrently if the task is migrated between different cpusets. Assuming we have 2 NUMA Node, when traversing Node1 in ac->zonelist, the nodemask is 2, and when traversing Node2 in ac->zonelist, the nodemask is 1. As a result, the ac->preferred_zoneref points to NULL zone. In alloc_pages_bulk_noprof(), for_each_zone_zonelist_nodemask() finds a allowable zone and calls zonelist_node_idx(ac.preferred_zoneref), leading to NULL pointer dereference. __alloc_pages_noprof() fixes this issue by checking NULL pointer in commit ea57485af8f4 (\"mm, page_alloc: fix check for NULL preferred_zone\") and commit df76cee6bbeb (\"mm, page_alloc: remove redundant checks from alloc fastpath\"). To fix it, check NULL pointer for preferred_zoneref->zone.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53114", "url": "https://ubuntu.com/security/CVE-2024-53114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 client A number of Zen4 client SoCs advertise the ability to use virtualized VMLOAD/VMSAVE, but using these instructions is reported to be a cause of a random host reboot. These instructions aren't intended to be advertised on Zen4 client so clear the capability.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53137", "url": "https://ubuntu.com/security/CVE-2024-53137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: fix cacheflush with PAN It seems that the cacheflush syscall got broken when PAN for LPAE was implemented. User access was not enabled around the cache maintenance instructions, causing them to fault.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53115", "url": "https://ubuntu.com/security/CVE-2024-53115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: avoid null_ptr_deref in vmw_framebuffer_surface_create_handle The 'vmw_user_object_buffer' function may return NULL with incorrect inputs. To avoid possible null pointer dereference, add a check whether the 'bo' is NULL in the vmw_framebuffer_surface_create_handle.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53116", "url": "https://ubuntu.com/security/CVE-2024-53116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix handling of partial GPU mapping of BOs This commit fixes the bug in the handling of partial mapping of the buffer objects to the GPU, which caused kernel warnings. Panthor didn't correctly handle the case where the partial mapping spanned multiple scatterlists and the mapping offset didn't point to the 1st page of starting scatterlist. The offset variable was not cleared after reaching the starting scatterlist. Following warning messages were seen. WARNING: CPU: 1 PID: 650 at drivers/iommu/io-pgtable-arm.c:659 __arm_lpae_unmap+0x254/0x5a0 pc : __arm_lpae_unmap+0x254/0x5a0 lr : __arm_lpae_unmap+0x2cc/0x5a0 Call trace: __arm_lpae_unmap+0x254/0x5a0 __arm_lpae_unmap+0x108/0x5a0 __arm_lpae_unmap+0x108/0x5a0 __arm_lpae_unmap+0x108/0x5a0 arm_lpae_unmap_pages+0x80/0xa0 panthor_vm_unmap_pages+0xac/0x1c8 [panthor] panthor_gpuva_sm_step_unmap+0x4c/0xc8 [panthor] op_unmap_cb.isra.23.constprop.30+0x54/0x80 __drm_gpuvm_sm_unmap+0x184/0x1c8 drm_gpuvm_sm_unmap+0x40/0x60 panthor_vm_exec_op+0xa8/0x120 [panthor] panthor_vm_bind_exec_sync_op+0xc4/0xe8 [panthor] panthor_ioctl_vm_bind+0x10c/0x170 [panthor] drm_ioctl_kernel+0xbc/0x138 drm_ioctl+0x210/0x4b0 __arm64_sys_ioctl+0xb0/0xf8 invoke_syscall+0x4c/0x110 el0_svc_common.constprop.1+0x98/0xf8 do_el0_svc+0x24/0x38 el0_svc+0x34/0xc8 el0t_64_sync_handler+0xa0/0xc8 el0t_64_sync+0x174/0x178 panthor : [drm] drm_WARN_ON(unmapped_sz != pgsize * pgcount) WARNING: CPU: 1 PID: 650 at drivers/gpu/drm/panthor/panthor_mmu.c:922 panthor_vm_unmap_pages+0x124/0x1c8 [panthor] pc : panthor_vm_unmap_pages+0x124/0x1c8 [panthor] lr : panthor_vm_unmap_pages+0x124/0x1c8 [panthor] panthor : [drm] *ERROR* failed to unmap range ffffa388f000-ffffa3890000 (requested range ffffa388c000-ffffa3890000)", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53117", "url": "https://ubuntu.com/security/CVE-2024-53117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio/vsock: Improve MSG_ZEROCOPY error handling Add a missing kfree_skb() to prevent memory leaks.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53118", "url": "https://ubuntu.com/security/CVE-2024-53118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Fix sk_error_queue memory leak Kernel queues MSG_ZEROCOPY completion notifications on the error queue. Where they remain, until explicitly recv()ed. To prevent memory leaks, clean up the queue when the socket is destroyed. unreferenced object 0xffff8881028beb00 (size 224): comm \"vsock_test\", pid 1218, jiffies 4294694897 hex dump (first 32 bytes): 90 b0 21 17 81 88 ff ff 90 b0 21 17 81 88 ff ff ..!.......!..... 00 00 00 00 00 00 00 00 00 b0 21 17 81 88 ff ff ..........!..... backtrace (crc 6c7031ca): [] kmem_cache_alloc_node_noprof+0x2f7/0x370 [] __alloc_skb+0x132/0x180 [] sock_omalloc+0x4b/0x80 [] msg_zerocopy_realloc+0x9e/0x240 [] virtio_transport_send_pkt_info+0x412/0x4c0 [] virtio_transport_stream_enqueue+0x43/0x50 [] vsock_connectible_sendmsg+0x373/0x450 [] ____sys_sendmsg+0x365/0x3a0 [] ___sys_sendmsg+0x84/0xd0 [] __sys_sendmsg+0x47/0x80 [] do_syscall_64+0x93/0x180 [] entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53119", "url": "https://ubuntu.com/security/CVE-2024-53119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio/vsock: Fix accept_queue memory leak As the final stages of socket destruction may be delayed, it is possible that virtio_transport_recv_listen() will be called after the accept_queue has been flushed, but before the SOCK_DONE flag has been set. As a result, sockets enqueued after the flush would remain unremoved, leading to a memory leak. vsock_release __vsock_release lock virtio_transport_release virtio_transport_close schedule_delayed_work(close_work) sk_shutdown = SHUTDOWN_MASK (!) flush accept_queue release virtio_transport_recv_pkt vsock_find_bound_socket lock if flag(SOCK_DONE) return virtio_transport_recv_listen child = vsock_create_connected (!) vsock_enqueue_accept(child) release close_work lock virtio_transport_do_close set_flag(SOCK_DONE) virtio_transport_remove_sock vsock_remove_sock vsock_remove_bound release Introduce a sk_shutdown check to disallow vsock_enqueue_accept() during socket destruction. unreferenced object 0xffff888109e3f800 (size 2040): comm \"kworker/5:2\", pid 371, jiffies 4294940105 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00 (..@............ backtrace (crc 9e5f4e84): [] kmem_cache_alloc_noprof+0x2c1/0x360 [] sk_prot_alloc+0x30/0x120 [] sk_alloc+0x2c/0x4b0 [] __vsock_create.constprop.0+0x2a/0x310 [] virtio_transport_recv_pkt+0x4dc/0x9a0 [] vsock_loopback_work+0xfd/0x140 [] process_one_work+0x20c/0x570 [] worker_thread+0x1bf/0x3a0 [] kthread+0xdd/0x110 [] ret_from_fork+0x2d/0x50 [] ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53120", "url": "https://ubuntu.com/security/CVE-2024-53120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: CT: Fix null-ptr-deref in add rule err flow In error flow of mlx5_tc_ct_entry_add_rule(), in case ct_rule_add() callback returns error, zone_rule->attr is used uninitiated. Fix it to use attr which has the needed pointer value. Kernel log: BUG: kernel NULL pointer dereference, address: 0000000000000110 RIP: 0010:mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core] … Call Trace: ? __die+0x20/0x70 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x140 ? asm_exc_page_fault+0x22/0x30 ? mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core] ? mlx5_tc_ct_entry_add_rule+0x1d5/0x2f0 [mlx5_core] mlx5_tc_ct_block_flow_offload+0xc6a/0xf90 [mlx5_core] ? nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] flow_offload_work_handler+0x142/0x320 [nf_flow_table] ? finish_task_switch.isra.0+0x15b/0x2b0 process_one_work+0x16c/0x320 worker_thread+0x28c/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xb8/0xf0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53138", "url": "https://ubuntu.com/security/CVE-2024-53138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: kTLS, Fix incorrect page refcounting The kTLS tx handling code is using a mix of get_page() and page_ref_inc() APIs to increment the page reference. But on the release path (mlx5e_ktls_tx_handle_resync_dump_comp()), only put_page() is used. This is an issue when using pages from large folios: the get_page() references are stored on the folio page while the page_ref_inc() references are stored directly in the given page. On release the folio page will be dereferenced too many times. This was found while doing kTLS testing with sendfile() + ZC when the served file was read from NFS on a kernel with NFS large folios support (commit 49b29a573da8 (\"nfs: add support for large folios\")).", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53121", "url": "https://ubuntu.com/security/CVE-2024-53121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: fs, lock FTE when checking if active The referenced commits introduced a two-step process for deleting FTEs: - Lock the FTE, delete it from hardware, set the hardware deletion function to NULL and unlock the FTE. - Lock the parent flow group, delete the software copy of the FTE, and remove it from the xarray. However, this approach encounters a race condition if a rule with the same match value is added simultaneously. In this scenario, fs_core may set the hardware deletion function to NULL prematurely, causing a panic during subsequent rule deletions. To prevent this, ensure the active flag of the FTE is checked under a lock, which will prevent the fs_core layer from attaching a new steering rule to an FTE that is in the process of deletion. [ 438.967589] MOSHE: 2496 mlx5_del_flow_rules del_hw_func [ 438.968205] ------------[ cut here ]------------ [ 438.968654] refcount_t: decrement hit 0; leaking memory. [ 438.969249] WARNING: CPU: 0 PID: 8957 at lib/refcount.c:31 refcount_warn_saturate+0xfb/0x110 [ 438.970054] Modules linked in: act_mirred cls_flower act_gact sch_ingress openvswitch nsh mlx5_vdpa vringh vhost_iotlb vdpa mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core zram zsmalloc fuse [last unloaded: cls_flower] [ 438.973288] CPU: 0 UID: 0 PID: 8957 Comm: tc Not tainted 6.12.0-rc1+ #8 [ 438.973888] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 438.974874] RIP: 0010:refcount_warn_saturate+0xfb/0x110 [ 438.975363] Code: 40 66 3b 82 c6 05 16 e9 4d 01 01 e8 1f 7c a0 ff 0f 0b c3 cc cc cc cc 48 c7 c7 10 66 3b 82 c6 05 fd e8 4d 01 01 e8 05 7c a0 ff <0f> 0b c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 90 [ 438.976947] RSP: 0018:ffff888124a53610 EFLAGS: 00010286 [ 438.977446] RAX: 0000000000000000 RBX: ffff888119d56de0 RCX: 0000000000000000 [ 438.978090] RDX: ffff88852c828700 RSI: ffff88852c81b3c0 RDI: ffff88852c81b3c0 [ 438.978721] RBP: ffff888120fa0e88 R08: 0000000000000000 R09: ffff888124a534b0 [ 438.979353] R10: 0000000000000001 R11: 0000000000000001 R12: ffff888119d56de0 [ 438.979979] R13: ffff888120fa0ec0 R14: ffff888120fa0ee8 R15: ffff888119d56de0 [ 438.980607] FS: 00007fe6dcc0f800(0000) GS:ffff88852c800000(0000) knlGS:0000000000000000 [ 438.983984] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 438.984544] CR2: 00000000004275e0 CR3: 0000000186982001 CR4: 0000000000372eb0 [ 438.985205] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 438.985842] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 438.986507] Call Trace: [ 438.986799] [ 438.987070] ? __warn+0x7d/0x110 [ 438.987426] ? refcount_warn_saturate+0xfb/0x110 [ 438.987877] ? report_bug+0x17d/0x190 [ 438.988261] ? prb_read_valid+0x17/0x20 [ 438.988659] ? handle_bug+0x53/0x90 [ 438.989054] ? exc_invalid_op+0x14/0x70 [ 438.989458] ? asm_exc_invalid_op+0x16/0x20 [ 438.989883] ? refcount_warn_saturate+0xfb/0x110 [ 438.990348] mlx5_del_flow_rules+0x2f7/0x340 [mlx5_core] [ 438.990932] __mlx5_eswitch_del_rule+0x49/0x170 [mlx5_core] [ 438.991519] ? mlx5_lag_is_sriov+0x3c/0x50 [mlx5_core] [ 438.992054] ? xas_load+0x9/0xb0 [ 438.992407] mlx5e_tc_rule_unoffload+0x45/0xe0 [mlx5_core] [ 438.993037] mlx5e_tc_del_fdb_flow+0x2a6/0x2e0 [mlx5_core] [ 438.993623] mlx5e_flow_put+0x29/0x60 [mlx5_core] [ 438.994161] mlx5e_delete_flower+0x261/0x390 [mlx5_core] [ 438.994728] tc_setup_cb_destroy+0xb9/0x190 [ 438.995150] fl_hw_destroy_filter+0x94/0xc0 [cls_flower] [ 438.995650] fl_change+0x11a4/0x13c0 [cls_flower] [ 438.996105] tc_new_tfilter+0x347/0xbc0 [ 438.996503] ? __ ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53122", "url": "https://ubuntu.com/security/CVE-2024-53122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: cope racing subflow creation in mptcp_rcv_space_adjust Additional active subflows - i.e. created by the in kernel path manager - are included into the subflow list before starting the 3whs. A racing recvmsg() spooling data received on an already established subflow would unconditionally call tcp_cleanup_rbuf() on all the current subflows, potentially hitting a divide by zero error on the newly created ones. Explicitly check that the subflow is in a suitable state before invoking tcp_cleanup_rbuf().", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53123", "url": "https://ubuntu.com/security/CVE-2024-53123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: error out earlier on disconnect Eric reported a division by zero splat in the MPTCP protocol: Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 6094 Comm: syz-executor317 Not tainted 6.12.0-rc5-syzkaller-00291-g05b92660cdfe #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:__tcp_select_window+0x5b4/0x1310 net/ipv4/tcp_output.c:3163 Code: f6 44 01 e3 89 df e8 9b 75 09 f8 44 39 f3 0f 8d 11 ff ff ff e8 0d 74 09 f8 45 89 f4 e9 04 ff ff ff e8 00 74 09 f8 44 89 f0 99 7c 24 14 41 29 d6 45 89 f4 e9 ec fe ff ff e8 e8 73 09 f8 48 89 RSP: 0018:ffffc900041f7930 EFLAGS: 00010293 RAX: 0000000000017e67 RBX: 0000000000017e67 RCX: ffffffff8983314b RDX: 0000000000000000 RSI: ffffffff898331b0 RDI: 0000000000000004 RBP: 00000000005d6000 R08: 0000000000000004 R09: 0000000000017e67 R10: 0000000000003e80 R11: 0000000000000000 R12: 0000000000003e80 R13: ffff888031d9b440 R14: 0000000000017e67 R15: 00000000002eb000 FS: 00007feb5d7f16c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007feb5d8adbb8 CR3: 0000000074e4c000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __tcp_cleanup_rbuf+0x3e7/0x4b0 net/ipv4/tcp.c:1493 mptcp_rcv_space_adjust net/mptcp/protocol.c:2085 [inline] mptcp_recvmsg+0x2156/0x2600 net/mptcp/protocol.c:2289 inet_recvmsg+0x469/0x6a0 net/ipv4/af_inet.c:885 sock_recvmsg_nosec net/socket.c:1051 [inline] sock_recvmsg+0x1b2/0x250 net/socket.c:1073 __sys_recvfrom+0x1a5/0x2e0 net/socket.c:2265 __do_sys_recvfrom net/socket.c:2283 [inline] __se_sys_recvfrom net/socket.c:2279 [inline] __x64_sys_recvfrom+0xe0/0x1c0 net/socket.c:2279 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 RIP: 0033:0x7feb5d857559 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:00007feb5d7f1208 EFLAGS: 00000246 ORIG_RAX: 000000000000002d RAX: ffffffffffffffda RBX: 00007feb5d8e1318 RCX: 00007feb5d857559 RDX: 000000800000000e RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007feb5d8e1310 R08: 0000000000000000 R09: ffffffff81000000 R10: 0000000000000100 R11: 0000000000000246 R12: 00007feb5d8e131c R13: 00007feb5d8ae074 R14: 000000800000000e R15: 00000000fffffdef and provided a nice reproducer. The root cause is the current bad handling of racing disconnect. After the blamed commit below, sk_wait_data() can return (with error) with the underlying socket disconnected and a zero rcv_mss. Catch the error and return without performing any additional operations on the current socket.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53124", "url": "https://ubuntu.com/security/CVE-2024-53124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix data-races around sk->sk_forward_alloc Syzkaller reported this warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 16 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x1c5/0x1e0 Modules linked in: CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:inet_sock_destruct+0x1c5/0x1e0 Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 <0f> 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00 RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206 RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007 RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00 RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007 R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00 R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78 FS: 0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn+0x88/0x130 ? inet_sock_destruct+0x1c5/0x1e0 ? report_bug+0x18e/0x1a0 ? handle_bug+0x53/0x90 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? inet_sock_destruct+0x1c5/0x1e0 __sk_destruct+0x2a/0x200 rcu_do_batch+0x1aa/0x530 ? rcu_do_batch+0x13b/0x530 rcu_core+0x159/0x2f0 handle_softirqs+0xd3/0x2b0 ? __pfx_smpboot_thread_fn+0x10/0x10 run_ksoftirqd+0x25/0x30 smpboot_thread_fn+0xdd/0x1d0 kthread+0xd3/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ---[ end trace 0000000000000000 ]--- Its possible that two threads call tcp_v6_do_rcv()/sk_forward_alloc_add() concurrently when sk->sk_state == TCP_LISTEN with sk->sk_lock unlocked, which triggers a data-race around sk->sk_forward_alloc: tcp_v6_rcv tcp_v6_do_rcv skb_clone_and_charge_r sk_rmem_schedule __sk_mem_schedule sk_forward_alloc_add() skb_set_owner_r sk_mem_charge sk_forward_alloc_add() __kfree_skb skb_release_all skb_release_head_state sock_rfree sk_mem_uncharge sk_forward_alloc_add() sk_mem_reclaim // set local var reclaimable __sk_mem_reclaim sk_forward_alloc_add() In this syzkaller testcase, two threads call tcp_v6_do_rcv() with skb->truesize=768, the sk_forward_alloc changes like this: (cpu 1) | (cpu 2) | sk_forward_alloc ... | ... | 0 __sk_mem_schedule() | | +4096 = 4096 | __sk_mem_schedule() | +4096 = 8192 sk_mem_charge() | | -768 = 7424 | sk_mem_charge() | -768 = 6656 ... | ... | sk_mem_uncharge() | | +768 = 7424 reclaimable=7424 | | | sk_mem_uncharge() | +768 = 8192 | reclaimable=8192 | __sk_mem_reclaim() | | -4096 = 4096 | __sk_mem_reclaim() | -8192 = -4096 != 0 The skb_clone_and_charge_r() should not be called in tcp_v6_do_rcv() when sk->sk_state is TCP_LISTEN, it happens later in tcp_v6_syn_recv_sock(). Fix the same issue in dccp_v6_do_rcv().", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53129", "url": "https://ubuntu.com/security/CVE-2024-53129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: vop: Fix a dereferenced before check warning The 'state' can't be NULL, we should check crtc_state. Fix warning: drivers/gpu/drm/rockchip/rockchip_drm_vop.c:1096 vop_plane_atomic_async_check() warn: variable dereferenced before check 'state' (see line 1077)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53139", "url": "https://ubuntu.com/security/CVE-2024-53139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix possible UAF in sctp_v6_available() A lockdep report [1] with CONFIG_PROVE_RCU_LIST=y hints that sctp_v6_available() is calling dev_get_by_index_rcu() and ipv6_chk_addr() without holding rcu. [1] ============================= WARNING: suspicious RCU usage 6.12.0-rc5-virtme #1216 Tainted: G W ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by sctp_hello/31495: #0: ffff9f1ebbdb7418 (sk_lock-AF_INET6){+.+.}-{0:0}, at: sctp_bind (./arch/x86/include/asm/jump_label.h:27 net/sctp/socket.c:315) sctp stack backtrace: CPU: 7 UID: 0 PID: 31495 Comm: sctp_hello Tainted: G W 6.12.0-rc5-virtme #1216 Tainted: [W]=WARN 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:123) lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822) dev_get_by_index_rcu (net/core/dev.c:876 (discriminator 7)) sctp_v6_available (net/sctp/ipv6.c:701) sctp sctp_do_bind (net/sctp/socket.c:400 (discriminator 1)) sctp sctp_bind (net/sctp/socket.c:320) sctp inet6_bind_sk (net/ipv6/af_inet6.c:465) ? security_socket_bind (security/security.c:4581 (discriminator 1)) __sys_bind (net/socket.c:1848 net/socket.c:1869) ? do_user_addr_fault (./include/linux/rcupdate.h:347 ./include/linux/rcupdate.h:880 ./include/linux/mm.h:729 arch/x86/mm/fault.c:1340) ? do_user_addr_fault (./arch/x86/include/asm/preempt.h:84 (discriminator 13) ./include/linux/rcupdate.h:98 (discriminator 13) ./include/linux/rcupdate.h:882 (discriminator 13) ./include/linux/mm.h:729 (discriminator 13) arch/x86/mm/fault.c:1340 (discriminator 13)) __x64_sys_bind (net/socket.c:1877 (discriminator 1) net/socket.c:1875 (discriminator 1) net/socket.c:1875 (discriminator 1)) do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f59b934a1e7 Code: 44 00 00 48 8b 15 39 8c 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 b8 31 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 09 8c 0c 00 f7 d8 64 89 01 48 All code ======== 0:\t44 00 00 \tadd %r8b,(%rax) 3:\t48 8b 15 39 8c 0c 00 \tmov 0xc8c39(%rip),%rdx # 0xc8c43 a:\tf7 d8 \tneg %eax c:\t64 89 02 \tmov %eax,%fs:(%rdx) f:\tb8 ff ff ff ff \tmov $0xffffffff,%eax 14:\teb bd \tjmp 0xffffffffffffffd3 16:\t66 2e 0f 1f 84 00 00 \tcs nopw 0x0(%rax,%rax,1) 1d:\t00 00 00 20:\t0f 1f 00 \tnopl (%rax) 23:\tb8 31 00 00 00 \tmov $0x31,%eax 28:\t0f 05 \tsyscall 2a:*\t48 3d 01 f0 ff ff \tcmp $0xfffffffffffff001,%rax\t\t<-- trapping instruction 30:\t73 01 \tjae 0x33 32:\tc3 \tret 33:\t48 8b 0d 09 8c 0c 00 \tmov 0xc8c09(%rip),%rcx # 0xc8c43 3a:\tf7 d8 \tneg %eax 3c:\t64 89 01 \tmov %eax,%fs:(%rcx) 3f:\t48 \trex.W Code starting with the faulting instruction =========================================== 0:\t48 3d 01 f0 ff ff \tcmp $0xfffffffffffff001,%rax 6:\t73 01 \tjae 0x9 8:\tc3 \tret 9:\t48 8b 0d 09 8c 0c 00 \tmov 0xc8c09(%rip),%rcx # 0xc8c19 10:\tf7 d8 \tneg %eax 12:\t64 89 01 \tmov %eax,%fs:(%rcx) 15:\t48 \trex.W RSP: 002b:00007ffe2d0ad398 EFLAGS: 00000202 ORIG_RAX: 0000000000000031 RAX: ffffffffffffffda RBX: 00007ffe2d0ad3d0 RCX: 00007f59b934a1e7 RDX: 000000000000001c RSI: 00007ffe2d0ad3d0 RDI: 0000000000000005 RBP: 0000000000000005 R08: 1999999999999999 R09: 0000000000000000 R10: 00007f59b9253298 R11: 000000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53140", "url": "https://ubuntu.com/security/CVE-2024-53140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netlink: terminate outstanding dump on socket close Netlink supports iterative dumping of data. It provides the families the following ops: - start - (optional) kicks off the dumping process - dump - actual dump helper, keeps getting called until it returns 0 - done - (optional) pairs with .start, can be used for cleanup The whole process is asynchronous and the repeated calls to .dump don't actually happen in a tight loop, but rather are triggered in response to recvmsg() on the socket. This gives the user full control over the dump, but also means that the user can close the socket without getting to the end of the dump. To make sure .start is always paired with .done we check if there is an ongoing dump before freeing the socket, and if so call .done. The complication is that sockets can get freed from BH and .done is allowed to sleep. So we use a workqueue to defer the call, when needed. Unfortunately this does not work correctly. What we defer is not the cleanup but rather releasing a reference on the socket. We have no guarantee that we own the last reference, if someone else holds the socket they may release it in BH and we're back to square one. The whole dance, however, appears to be unnecessary. Only the user can interact with dumps, so we can clean up when socket is closed. And close always happens in process context. Some async code may still access the socket after close, queue notification skbs to it etc. but no dumps can start, end or otherwise make progress. Delete the workqueue and flush the dump state directly from the release handler. Note that further cleanup is possible in -next, for instance we now always call .done before releasing the main module reference, so dump doesn't have to take a reference of its own.", "cve_priority": "high", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53098", "url": "https://ubuntu.com/security/CVE-2024-53098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/ufence: Prefetch ufence addr to catch bogus address access_ok() only checks for addr overflow so also try to read the addr to catch invalid addr sent from userspace. (cherry picked from commit 9408c4508483ffc60811e910a93d6425b8e63928)", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53099", "url": "https://ubuntu.com/security/CVE-2024-53099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check validity of link->type in bpf_link_show_fdinfo() If a newly-added link type doesn't invoke BPF_LINK_TYPE(), accessing bpf_link_type_strs[link->type] may result in an out-of-bounds access. To spot such missed invocations early in the future, checking the validity of link->type in bpf_link_show_fdinfo() and emitting a warning when such invocations are missed.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53089", "url": "https://ubuntu.com/security/CVE-2024-53089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: KVM: Mark hrtimer to expire in hard interrupt context Like commit 2c0d278f3293f (\"KVM: LAPIC: Mark hrtimer to expire in hard interrupt context\") and commit 9090825fa9974 (\"KVM: arm/arm64: Let the timer expire in hardirq context on RT\"), On PREEMPT_RT enabled kernels unmarked hrtimers are moved into soft interrupt expiry mode by default. Then the timers are canceled from an preempt-notifier which is invoked with disabled preemption which is not allowed on PREEMPT_RT. The timer callback is short so in could be invoked in hard-IRQ context. So let the timer expire on hard-IRQ context even on -RT. This fix a \"scheduling while atomic\" bug for PREEMPT_RT enabled kernels: BUG: scheduling while atomic: qemu-system-loo/1011/0x00000002 Modules linked in: amdgpu rfkill nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat ns CPU: 1 UID: 0 PID: 1011 Comm: qemu-system-loo Tainted: G W 6.12.0-rc2+ #1774 Tainted: [W]=WARN Hardware name: Loongson Loongson-3A5000-7A1000-1w-CRB/Loongson-LS3A5000-7A1000-1w-CRB, BIOS vUDK2018-LoongArch-V2.0.0-prebeta9 10/21/2022 Stack : ffffffffffffffff 0000000000000000 9000000004e3ea38 9000000116744000 90000001167475a0 0000000000000000 90000001167475a8 9000000005644830 90000000058dc000 90000000058dbff8 9000000116747420 0000000000000001 0000000000000001 6a613fc938313980 000000000790c000 90000001001c1140 00000000000003fe 0000000000000001 000000000000000d 0000000000000003 0000000000000030 00000000000003f3 000000000790c000 9000000116747830 90000000057ef000 0000000000000000 9000000005644830 0000000000000004 0000000000000000 90000000057f4b58 0000000000000001 9000000116747868 900000000451b600 9000000005644830 9000000003a13998 0000000010000020 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d ... Call Trace: [<9000000003a13998>] show_stack+0x38/0x180 [<9000000004e3ea34>] dump_stack_lvl+0x84/0xc0 [<9000000003a71708>] __schedule_bug+0x48/0x60 [<9000000004e45734>] __schedule+0x1114/0x1660 [<9000000004e46040>] schedule_rtlock+0x20/0x60 [<9000000004e4e330>] rtlock_slowlock_locked+0x3f0/0x10a0 [<9000000004e4f038>] rt_spin_lock+0x58/0x80 [<9000000003b02d68>] hrtimer_cancel_wait_running+0x68/0xc0 [<9000000003b02e30>] hrtimer_cancel+0x70/0x80 [] kvm_restore_timer+0x50/0x1a0 [kvm] [] kvm_arch_vcpu_load+0x68/0x2a0 [kvm] [] kvm_sched_in+0x34/0x60 [kvm] [<9000000003a749a0>] finish_task_switch.isra.0+0x140/0x2e0 [<9000000004e44a70>] __schedule+0x450/0x1660 [<9000000004e45cb0>] schedule+0x30/0x180 [] kvm_vcpu_block+0x70/0x120 [kvm] [] kvm_vcpu_halt+0x60/0x3e0 [kvm] [] kvm_handle_gspr+0x3f4/0x4e0 [kvm] [] kvm_handle_exit+0x1c8/0x260 [kvm]", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53090", "url": "https://ubuntu.com/security/CVE-2024-53090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix lock recursion afs_wake_up_async_call() can incur lock recursion. The problem is that it is called from AF_RXRPC whilst holding the ->notify_lock, but it tries to take a ref on the afs_call struct in order to pass it to a work queue - but if the afs_call is already queued, we then have an extraneous ref that must be put... calling afs_put_call() may call back down into AF_RXRPC through rxrpc_kernel_shutdown_call(), however, which might try taking the ->notify_lock again. This case isn't very common, however, so defer it to a workqueue. The oops looks something like: BUG: spinlock recursion on CPU#0, krxrpcio/7001/1646 lock: 0xffff888141399b30, .magic: dead4ead, .owner: krxrpcio/7001/1646, .owner_cpu: 0 CPU: 0 UID: 0 PID: 1646 Comm: krxrpcio/7001 Not tainted 6.12.0-rc2-build3+ #4351 Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014 Call Trace: dump_stack_lvl+0x47/0x70 do_raw_spin_lock+0x3c/0x90 rxrpc_kernel_shutdown_call+0x83/0xb0 afs_put_call+0xd7/0x180 rxrpc_notify_socket+0xa0/0x190 rxrpc_input_split_jumbo+0x198/0x1d0 rxrpc_input_data+0x14b/0x1e0 ? rxrpc_input_call_packet+0xc2/0x1f0 rxrpc_input_call_event+0xad/0x6b0 rxrpc_input_packet_on_conn+0x1e1/0x210 rxrpc_input_packet+0x3f2/0x4d0 rxrpc_io_thread+0x243/0x410 ? __pfx_rxrpc_io_thread+0x10/0x10 kthread+0xcf/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x24/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53101", "url": "https://ubuntu.com/security/CVE-2024-53101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized value issue in from_kuid and from_kgid ocfs2_setattr() uses attr->ia_mode, attr->ia_uid and attr->ia_gid in a trace point even though ATTR_MODE, ATTR_UID and ATTR_GID aren't set. Initialize all fields of newattrs to avoid uninitialized variables, by checking if ATTR_MODE, ATTR_UID, ATTR_GID are initialized, otherwise 0.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53091", "url": "https://ubuntu.com/security/CVE-2024-53091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Add sk_is_inet and IS_ICSK check in tls_sw_has_ctx_tx/rx As the introduction of the support for vsock and unix sockets in sockmap, tls_sw_has_ctx_tx/rx cannot presume the socket passed in must be IS_ICSK. vsock and af_unix sockets have vsock_sock and unix_sock instead of inet_connection_sock. For these sockets, tls_get_ctx may return an invalid pointer and cause page fault in function tls_sw_ctx_rx. BUG: unable to handle page fault for address: 0000000000040030 Workqueue: vsock-loopback vsock_loopback_work RIP: 0010:sk_psock_strp_data_ready+0x23/0x60 Call Trace: ? __die+0x81/0xc3 ? no_context+0x194/0x350 ? do_page_fault+0x30/0x110 ? async_page_fault+0x3e/0x50 ? sk_psock_strp_data_ready+0x23/0x60 virtio_transport_recv_pkt+0x750/0x800 ? update_load_avg+0x7e/0x620 vsock_loopback_work+0xd0/0x100 process_one_work+0x1a7/0x360 worker_thread+0x30/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x112/0x130 ? __kthread_cancel_work+0x40/0x40 ret_from_fork+0x1f/0x40 v2: - Add IS_ICSK check v3: - Update the commits in Fixes", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53092", "url": "https://ubuntu.com/security/CVE-2024-53092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_pci: Fix admin vq cleanup by using correct info pointer vp_modern_avq_cleanup() and vp_del_vqs() clean up admin vq resources by virtio_pci_vq_info pointer. The info pointer of admin vq is stored in vp_dev->admin_vq.info instead of vp_dev->vqs[]. Using the info pointer from vp_dev->vqs[] for admin vq causes a kernel NULL pointer dereference bug. In vp_modern_avq_cleanup() and vp_del_vqs(), get the info pointer from vp_dev->admin_vq.info for admin vq to clean up the resources. Also make info ptr as argument of vp_del_vq() to be symmetric with vp_setup_vq(). vp_reset calls vp_modern_avq_cleanup, and causes the Call Trace: ================================================================== BUG: kernel NULL pointer dereference, address:0000000000000000 ... CPU: 49 UID: 0 PID: 4439 Comm: modprobe Not tainted 6.11.0-rc5 #1 RIP: 0010:vp_reset+0x57/0x90 [virtio_pci] Call Trace: ... ? vp_reset+0x57/0x90 [virtio_pci] ? vp_reset+0x38/0x90 [virtio_pci] virtio_reset_device+0x1d/0x30 remove_vq_common+0x1c/0x1a0 [virtio_net] virtnet_remove+0xa1/0xc0 [virtio_net] virtio_dev_remove+0x46/0xa0 ... virtio_pci_driver_exit+0x14/0x810 [virtio_pci] ==================================================================", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53102", "url": "https://ubuntu.com/security/CVE-2024-53102", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53093", "url": "https://ubuntu.com/security/CVE-2024-53093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: defer partition scanning We need to suppress the partition scan from occuring within the controller's scan_work context. If a path error occurs here, the IO will wait until a path becomes available or all paths are torn down, but that action also occurs within scan_work, so it would deadlock. Defer the partion scan to a different context that does not block scan_work.", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53094", "url": "https://ubuntu.com/security/CVE-2024-53094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Add sendpage_ok() check to disable MSG_SPLICE_PAGES While running ISER over SIW, the initiator machine encounters a warning from skb_splice_from_iter() indicating that a slab page is being used in send_page. To address this, it is better to add a sendpage_ok() check within the driver itself, and if it returns 0, then MSG_SPLICE_PAGES flag should be disabled before entering the network stack. A similar issue has been discussed for NVMe in this thread: https://lore.kernel.org/all/20240530142417.146696-1-ofir.gal@volumez.com/ WARNING: CPU: 0 PID: 5342 at net/core/skbuff.c:7140 skb_splice_from_iter+0x173/0x320 Call Trace: tcp_sendmsg_locked+0x368/0xe40 siw_tx_hdt+0x695/0xa40 [siw] siw_qp_sq_process+0x102/0xb00 [siw] siw_sq_resume+0x39/0x110 [siw] siw_run_sq+0x74/0x160 [siw] kthread+0xd2/0x100 ret_from_fork+0x34/0x40 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53100", "url": "https://ubuntu.com/security/CVE-2024-53100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: tcp: avoid race between queue_lock lock and destroy Commit 76d54bf20cdc (\"nvme-tcp: don't access released socket during error recovery\") added a mutex_lock() call for the queue->queue_lock in nvme_tcp_get_address(). However, the mutex_lock() races with mutex_destroy() in nvme_tcp_free_queue(), and causes the WARN below. DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: CPU: 3 PID: 34077 at kernel/locking/mutex.c:587 __mutex_lock+0xcf0/0x1220 Modules linked in: nvmet_tcp nvmet nvme_tcp nvme_fabrics iw_cm ib_cm ib_core pktcdvd nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables qrtr sunrpc ppdev 9pnet_virtio 9pnet pcspkr netfs parport_pc parport e1000 i2c_piix4 i2c_smbus loop fuse nfnetlink zram bochs drm_vram_helper drm_ttm_helper ttm drm_kms_helper xfs drm sym53c8xx floppy nvme scsi_transport_spi nvme_core nvme_auth serio_raw ata_generic pata_acpi dm_multipath qemu_fw_cfg [last unloaded: ib_uverbs] CPU: 3 UID: 0 PID: 34077 Comm: udisksd Not tainted 6.11.0-rc7 #319 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:__mutex_lock+0xcf0/0x1220 Code: 08 84 d2 0f 85 c8 04 00 00 8b 15 ef b6 c8 01 85 d2 0f 85 78 f4 ff ff 48 c7 c6 20 93 ee af 48 c7 c7 60 91 ee af e8 f0 a7 6d fd <0f> 0b e9 5e f4 ff ff 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 RSP: 0018:ffff88811305f760 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff88812c652058 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000001 RBP: ffff88811305f8b0 R08: 0000000000000001 R09: ffffed1075c36341 R10: ffff8883ae1b1a0b R11: 0000000000010498 R12: 0000000000000000 R13: 0000000000000000 R14: dffffc0000000000 R15: ffff88812c652058 FS: 00007f9713ae4980(0000) GS:ffff8883ae180000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcd78483c7c CR3: 0000000122c38000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn.cold+0x5b/0x1af ? __mutex_lock+0xcf0/0x1220 ? report_bug+0x1ec/0x390 ? handle_bug+0x3c/0x80 ? exc_invalid_op+0x13/0x40 ? asm_exc_invalid_op+0x16/0x20 ? __mutex_lock+0xcf0/0x1220 ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] ? __pfx___mutex_lock+0x10/0x10 ? __lock_acquire+0xd6a/0x59e0 ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] ? __pfx_nvme_tcp_get_address+0x10/0x10 [nvme_tcp] nvme_sysfs_show_address+0x81/0xc0 [nvme_core] dev_attr_show+0x42/0x80 ? __asan_memset+0x1f/0x40 sysfs_kf_seq_show+0x1f0/0x370 seq_read_iter+0x2cb/0x1130 ? rw_verify_area+0x3b1/0x590 ? __mutex_lock+0x433/0x1220 vfs_read+0x6a6/0xa20 ? lockdep_hardirqs_on+0x78/0x100 ? __pfx_vfs_read+0x10/0x10 ksys_read+0xf7/0x1d0 ? __pfx_ksys_read+0x10/0x10 ? __x64_sys_openat+0x105/0x1d0 do_syscall_64+0x93/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? __pfx_ksys_read+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? do_syscall_64+0x9f/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f9713f55cfa Code: 55 48 89 e5 48 83 ec 20 48 89 55 e8 48 89 75 f0 89 7d f8 e8 e8 74 f8 ff 48 8b 55 e8 48 8b 75 f0 4 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53095", "url": "https://ubuntu.com/security/CVE-2024-53095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix use-after-free of network namespace. Recently, we got a customer report that CIFS triggers oops while reconnecting to a server. [0] The workload runs on Kubernetes, and some pods mount CIFS servers in non-root network namespaces. The problem rarely happened, but it was always while the pod was dying. The root cause is wrong reference counting for network namespace. CIFS uses kernel sockets, which do not hold refcnt of the netns that the socket belongs to. That means CIFS must ensure the socket is always freed before its netns; otherwise, use-after-free happens. The repro steps are roughly: 1. mount CIFS in a non-root netns 2. drop packets from the netns 3. destroy the netns 4. unmount CIFS We can reproduce the issue quickly with the script [1] below and see the splat [2] if CONFIG_NET_NS_REFCNT_TRACKER is enabled. When the socket is TCP, it is hard to guarantee the netns lifetime without holding refcnt due to async timers. Let's hold netns refcnt for each socket as done for SMC in commit 9744d2bf1976 (\"smc: Fix use-after-free in tcp_write_timer_handler().\"). Note that we need to move put_net() from cifs_put_tcp_session() to clean_demultiplex_info(); otherwise, __sock_create() still could touch a freed netns while cifsd tries to reconnect from cifs_demultiplex_thread(). Also, maybe_get_net() cannot be put just before __sock_create() because the code is not under RCU and there is a small chance that the same address happened to be reallocated to another netns. [0]: CIFS: VFS: \\\\XXXXXXXXXXX has not responded in 15 seconds. Reconnecting... CIFS: Serverclose failed 4 times, giving up Unable to handle kernel paging request at virtual address 14de99e461f84a07 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 CM = 0, WnR = 0 [14de99e461f84a07] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: cls_bpf sch_ingress nls_utf8 cifs cifs_arc4 cifs_md4 dns_resolver tcp_diag inet_diag veth xt_state xt_connmark nf_conntrack_netlink xt_nat xt_statistic xt_MASQUERADE xt_mark xt_addrtype ipt_REJECT nf_reject_ipv4 nft_chain_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment nft_compat nf_tables nfnetlink overlay nls_ascii nls_cp437 sunrpc vfat fat aes_ce_blk aes_ce_cipher ghash_ce sm4_ce_cipher sm4 sm3_ce sm3 sha3_ce sha512_ce sha512_arm64 sha1_ce ena button sch_fq_codel loop fuse configfs dmi_sysfs sha2_ce sha256_arm64 dm_mirror dm_region_hash dm_log dm_mod dax efivarfs CPU: 5 PID: 2690970 Comm: cifsd Not tainted 6.1.103-109.184.amzn2023.aarch64 #1 Hardware name: Amazon EC2 r7g.4xlarge/, BIOS 1.0 11/1/2018 pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : fib_rules_lookup+0x44/0x238 lr : __fib_lookup+0x64/0xbc sp : ffff8000265db790 x29: ffff8000265db790 x28: 0000000000000000 x27: 000000000000bd01 x26: 0000000000000000 x25: ffff000b4baf8000 x24: ffff00047b5e4580 x23: ffff8000265db7e0 x22: 0000000000000000 x21: ffff00047b5e4500 x20: ffff0010e3f694f8 x19: 14de99e461f849f7 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 3f92800abd010002 x11: 0000000000000001 x10: ffff0010e3f69420 x9 : ffff800008a6f294 x8 : 0000000000000000 x7 : 0000000000000006 x6 : 0000000000000000 x5 : 0000000000000001 x4 : ffff001924354280 x3 : ffff8000265db7e0 x2 : 0000000000000000 x1 : ffff0010e3f694f8 x0 : ffff00047b5e4500 Call trace: fib_rules_lookup+0x44/0x238 __fib_lookup+0x64/0xbc ip_route_output_key_hash_rcu+0x2c4/0x398 ip_route_output_key_hash+0x60/0x8c tcp_v4_connect+0x290/0x488 __inet_stream_connect+0x108/0x3d0 inet_stream_connect+0x50/0x78 kernel_connect+0x6c/0xac generic_ip_conne ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-50265", "url": "https://ubuntu.com/security/CVE-2024-50265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove() Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove(): [ 57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12 [ 57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry [ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004 [...] [ 57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [...] [ 57.331328] Call Trace: [ 57.331477] [...] [ 57.333511] ? do_user_addr_fault+0x3e5/0x740 [ 57.333778] ? exc_page_fault+0x70/0x170 [ 57.334016] ? asm_exc_page_fault+0x2b/0x30 [ 57.334263] ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10 [ 57.334596] ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [ 57.334913] ocfs2_xa_remove_entry+0x23/0xc0 [ 57.335164] ocfs2_xa_set+0x704/0xcf0 [ 57.335381] ? _raw_spin_unlock+0x1a/0x40 [ 57.335620] ? ocfs2_inode_cache_unlock+0x16/0x20 [ 57.335915] ? trace_preempt_on+0x1e/0x70 [ 57.336153] ? start_this_handle+0x16c/0x500 [ 57.336410] ? preempt_count_sub+0x50/0x80 [ 57.336656] ? _raw_read_unlock+0x20/0x40 [ 57.336906] ? start_this_handle+0x16c/0x500 [ 57.337162] ocfs2_xattr_block_set+0xa6/0x1e0 [ 57.337424] __ocfs2_xattr_set_handle+0x1fd/0x5d0 [ 57.337706] ? ocfs2_start_trans+0x13d/0x290 [ 57.337971] ocfs2_xattr_set+0xb13/0xfb0 [ 57.338207] ? dput+0x46/0x1c0 [ 57.338393] ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338665] ? ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338948] __vfs_removexattr+0x92/0xc0 [ 57.339182] __vfs_removexattr_locked+0xd5/0x190 [ 57.339456] ? preempt_count_sub+0x50/0x80 [ 57.339705] vfs_removexattr+0x5f/0x100 [...] Reproducer uses faultinject facility to fail ocfs2_xa_remove() -> ocfs2_xa_value_truncate() with -ENOMEM. In this case the comment mentions that we can return 0 if ocfs2_xa_cleanup_value_truncate() is going to wipe the entry anyway. But the following 'rc' check is wrong and execution flow do 'ocfs2_xa_remove_entry(loc);' twice: * 1st: in ocfs2_xa_cleanup_value_truncate(); * 2nd: returning back to ocfs2_xa_remove() instead of going to 'out'. Fix this by skipping the 2nd removal of the same entry and making syzkaller repro happy.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50266", "url": "https://ubuntu.com/security/CVE-2024-50266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: qcom: videocc-sm8350: use HW_CTRL_TRIGGER for vcodec GDSCs A recent change in the venus driver results in a stuck clock on the Lenovo ThinkPad X13s, for example, when streaming video in firefox: \tvideo_cc_mvs0_clk status stuck at 'off' \tWARNING: CPU: 6 PID: 2885 at drivers/clk/qcom/clk-branch.c:87 clk_branch_wait+0x144/0x15c \t... \tCall trace: \t clk_branch_wait+0x144/0x15c \t clk_branch2_enable+0x30/0x40 \t clk_core_enable+0xd8/0x29c \t clk_enable+0x2c/0x4c \t vcodec_clks_enable.isra.0+0x94/0xd8 [venus_core] \t coreid_power_v4+0x464/0x628 [venus_core] \t vdec_start_streaming+0xc4/0x510 [venus_dec] \t vb2_start_streaming+0x6c/0x180 [videobuf2_common] \t vb2_core_streamon+0x120/0x1dc [videobuf2_common] \t vb2_streamon+0x1c/0x6c [videobuf2_v4l2] \t v4l2_m2m_ioctl_streamon+0x30/0x80 [v4l2_mem2mem] \t v4l_streamon+0x24/0x30 [videodev] using the out-of-tree sm8350/sc8280xp venus support. [1] Update also the sm8350/sc8280xp GDSC definitions so that the hw control mode can be changed at runtime as the venus driver now requires.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50267", "url": "https://ubuntu.com/security/CVE-2024-50267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: fix use after free in debug printk The \"dev_dbg(&urb->dev->dev, ...\" which happens after usb_free_urb(urb) is a use after free of the \"urb\" pointer. Store the \"dev\" pointer at the start of the function to avoid this issue.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50268", "url": "https://ubuntu.com/security/CVE-2024-50268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: fix potential out of bounds in ucsi_ccg_update_set_new_cam_cmd() The \"*cmd\" variable can be controlled by the user via debugfs. That means \"new_cam\" can be as high as 255 while the size of the uc->updated[] array is UCSI_MAX_ALTMODES (30). The call tree is: ucsi_cmd() // val comes from simple_attr_write_xsigned() -> ucsi_send_command() -> ucsi_send_command_common() -> ucsi_run_command() // calls ucsi->ops->sync_control() -> ucsi_ccg_sync_control()", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53083", "url": "https://ubuntu.com/security/CVE-2024-53083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: qcom-pmic: init value of hdr_len/txbuf_len earlier If the read of USB_PDPHY_RX_ACKNOWLEDGE_REG failed, then hdr_len and txbuf_len are uninitialized. This commit stops to print uninitialized value and misleading/false data.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50269", "url": "https://ubuntu.com/security/CVE-2024-50269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: musb: sunxi: Fix accessing an released usb phy Commit 6ed05c68cbca (\"usb: musb: sunxi: Explicitly release USB PHY on exit\") will cause that usb phy @glue->xceiv is accessed after released. 1) register platform driver @sunxi_musb_driver // get the usb phy @glue->xceiv sunxi_musb_probe() -> devm_usb_get_phy(). 2) register and unregister platform driver @musb_driver musb_probe() -> sunxi_musb_init() use the phy here //the phy is released here musb_remove() -> sunxi_musb_exit() -> devm_usb_put_phy() 3) register @musb_driver again musb_probe() -> sunxi_musb_init() use the phy here but the phy has been released at 2). ... Fixed by reverting the commit, namely, removing devm_usb_put_phy() from sunxi_musb_exit().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53079", "url": "https://ubuntu.com/security/CVE-2024-53079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/thp: fix deferred split unqueue naming and locking Recent changes are putting more pressure on THP deferred split queues: under load revealing long-standing races, causing list_del corruptions, \"Bad page state\"s and worse (I keep BUGs in both of those, so usually don't get to see how badly they end up without). The relevant recent changes being 6.8's mTHP, 6.10's mTHP swapout, and 6.12's mTHP swapin, improved swap allocation, and underused THP splitting. Before fixing locking: rename misleading folio_undo_large_rmappable(), which does not undo large_rmappable, to folio_unqueue_deferred_split(), which is what it does. But that and its out-of-line __callee are mm internals of very limited usability: add comment and WARN_ON_ONCEs to check usage; and return a bool to say if a deferred split was unqueued, which can then be used in WARN_ON_ONCEs around safety checks (sparing callers the arcane conditionals in __folio_unqueue_deferred_split()). Just omit the folio_unqueue_deferred_split() from free_unref_folios(), all of whose callers now call it beforehand (and if any forget then bad_page() will tell) - except for its caller put_pages_list(), which itself no longer has any callers (and will be deleted separately). Swapout: mem_cgroup_swapout() has been resetting folio->memcg_data 0 without checking and unqueueing a THP folio from deferred split list; which is unfortunate, since the split_queue_lock depends on the memcg (when memcg is enabled); so swapout has been unqueueing such THPs later, when freeing the folio, using the pgdat's lock instead: potentially corrupting the memcg's list. __remove_mapping() has frozen refcount to 0 here, so no problem with calling folio_unqueue_deferred_split() before resetting memcg_data. That goes back to 5.4 commit 87eaceb3faa5 (\"mm: thp: make deferred split shrinker memcg aware\"): which included a check on swapcache before adding to deferred queue, but no check on deferred queue before adding THP to swapcache. That worked fine with the usual sequence of events in reclaim (though there were a couple of rare ways in which a THP on deferred queue could have been swapped out), but 6.12 commit dafff3f4c850 (\"mm: split underused THPs\") avoids splitting underused THPs in reclaim, which makes swapcache THPs on deferred queue commonplace. Keep the check on swapcache before adding to deferred queue? Yes: it is no longer essential, but preserves the existing behaviour, and is likely to be a worthwhile optimization (vmstat showed much more traffic on the queue under swapping load if the check was removed); update its comment. Memcg-v1 move (deprecated): mem_cgroup_move_account() has been changing folio->memcg_data without checking and unqueueing a THP folio from the deferred list, sometimes corrupting \"from\" memcg's list, like swapout. Refcount is non-zero here, so folio_unqueue_deferred_split() can only be used in a WARN_ON_ONCE to validate the fix, which must be done earlier: mem_cgroup_move_charge_pte_range() first try to split the THP (splitting of course unqueues), or skip it if that fails. Not ideal, but moving charge has been requested, and khugepaged should repair the THP later: nobody wants new custom unqueueing code just for this deprecated case. The 87eaceb3faa5 commit did have the code to move from one deferred list to another (but was not conscious of its unsafety while refcount non-0); but that was removed by 5.6 commit fac0516b5534 (\"mm: thp: don't need care deferred split queue in memcg charge move path\"), which argued that the existence of a PMD mapping guarantees that the THP cannot be on a deferred list. As above, false in rare cases, and now commonly false. Backport to 6.11 should be straightforward. Earlier backports must take care that other _deferred_list fixes and dependencies are included. There is not a strong case for backports, but they can fix cornercases.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50270", "url": "https://ubuntu.com/security/CVE-2024-50270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: avoid overflow in damon_feed_loop_next_input() damon_feed_loop_next_input() is inefficient and fragile to overflows. Specifically, 'score_goal_diff_bp' calculation can overflow when 'score' is high. The calculation is actually unnecessary at all because 'goal' is a constant of value 10,000. Calculation of 'compensation' is again fragile to overflow. Final calculation of return value for under-achiving case is again fragile to overflow when the current score is under-achieving the target. Add two corner cases handling at the beginning of the function to make the body easier to read, and rewrite the body of the function to avoid overflows and the unnecessary bp value calcuation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50271", "url": "https://ubuntu.com/security/CVE-2024-50271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: signal: restore the override_rlimit logic Prior to commit d64696905554 (\"Reimplement RLIMIT_SIGPENDING on top of ucounts\") UCOUNT_RLIMIT_SIGPENDING rlimit was not enforced for a class of signals. However now it's enforced unconditionally, even if override_rlimit is set. This behavior change caused production issues. For example, if the limit is reached and a process receives a SIGSEGV signal, sigqueue_alloc fails to allocate the necessary resources for the signal delivery, preventing the signal from being delivered with siginfo. This prevents the process from correctly identifying the fault address and handling the error. From the user-space perspective, applications are unaware that the limit has been reached and that the siginfo is effectively 'corrupted'. This can lead to unpredictable behavior and crashes, as we observed with java applications. Fix this by passing override_rlimit into inc_rlimit_get_ucounts() and skip the comparison to max there if override_rlimit is set. This effectively restores the old behavior.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50272", "url": "https://ubuntu.com/security/CVE-2024-50272", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: filemap: Fix bounds checking in filemap_read() If the caller supplies an iocb->ki_pos value that is close to the filesystem upper limit, and an iterator with a count that causes us to overflow that limit, then filemap_read() enters an infinite loop. This behaviour was discovered when testing xfstests generic/525 with the \"localio\" optimisation for loopback NFS mounts.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53104", "url": "https://ubuntu.com/security/CVE-2024-53104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_parse_format This can lead to out of bounds writes since frames of this type were not taken into account when calculating the size of the frames buffer in uvc_parse_streaming.", "cve_priority": "high", "cve_public_date": "2024-12-02 08:15:00 UTC" }, { "cve": "CVE-2024-50273", "url": "https://ubuntu.com/security/CVE-2024-50273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reinitialize delayed ref list after deleting it from the list At insert_delayed_ref() if we need to update the action of an existing ref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head's ref_add_list using list_del(), which leaves the ref's add_list member not reinitialized, as list_del() sets the next and prev members of the list to LIST_POISON1 and LIST_POISON2, respectively. If later we end up calling drop_delayed_ref() against the ref, which can happen during merging or when destroying delayed refs due to a transaction abort, we can trigger a crash since at drop_delayed_ref() we call list_empty() against the ref's add_list, which returns false since the list was not reinitialized after the list_del() and as a consequence we call list_del() again at drop_delayed_ref(). This results in an invalid list access since the next and prev members are set to poison pointers, resulting in a splat if CONFIG_LIST_HARDENED and CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences otherwise. So fix this by deleting from the list with list_del_init() instead.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53064", "url": "https://ubuntu.com/security/CVE-2024-53064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix idpf_vc_core_init error path In an event where the platform running the device control plane is rebooted, reset is detected on the driver. It releases all the resources and waits for the reset to complete. Once the reset is done, it tries to build the resources back. At this time if the device control plane is not yet started, then the driver timeouts on the virtchnl message and retries to establish the mailbox again. In the retry flow, mailbox is deinitialized but the mailbox workqueue is still alive and polling for the mailbox message. This results in accessing the released control queue leading to null-ptr-deref. Fix it by unrolling the work queue cancellation and mailbox deinitialization in the reverse order which they got initialized.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50274", "url": "https://ubuntu.com/security/CVE-2024-50274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: avoid vport access in idpf_get_link_ksettings When the device control plane is removed or the platform running device control plane is rebooted, a reset is detected on the driver. On driver reset, it releases the resources and waits for the reset to complete. If the reset fails, it takes the error path and releases the vport lock. At this time if the monitoring tools tries to access link settings, it call traces for accessing released vport pointer. To avoid it, move link_speed_mbps to netdev_priv structure which removes the dependency on vport pointer and the vport lock in idpf_get_link_ksettings. Also use netif_carrier_ok() to check the link status and adjust the offsetof to use link_up instead of link_speed_mbps.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53065", "url": "https://ubuntu.com/security/CVE-2024-53065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/slab: fix warning caused by duplicate kmem_cache creation in kmem_buckets_create Commit b035f5a6d852 (\"mm: slab: reduce the kmalloc() minimum alignment if DMA bouncing possible\") reduced ARCH_KMALLOC_MINALIGN to 8 on arm64. However, with KASAN_HW_TAGS enabled, arch_slab_minalign() becomes 16. This causes kmalloc_caches[*][8] to be aliased to kmalloc_caches[*][16], resulting in kmem_buckets_create() attempting to create a kmem_cache for size 16 twice. This duplication triggers warnings on boot: [ 2.325108] ------------[ cut here ]------------ [ 2.325135] kmem_cache of name 'memdup_user-16' already exists [ 2.325783] WARNING: CPU: 0 PID: 1 at mm/slab_common.c:107 __kmem_cache_create_args+0xb8/0x3b0 [ 2.327957] Modules linked in: [ 2.328550] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5mm-unstable-arm64+ #12 [ 2.328683] Hardware name: QEMU QEMU Virtual Machine, BIOS 2024.02-2 03/11/2024 [ 2.328790] pstate: 61000009 (nZCv daif -PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 2.328911] pc : __kmem_cache_create_args+0xb8/0x3b0 [ 2.328930] lr : __kmem_cache_create_args+0xb8/0x3b0 [ 2.328942] sp : ffff800083d6fc50 [ 2.328961] x29: ffff800083d6fc50 x28: f2ff0000c1674410 x27: ffff8000820b0598 [ 2.329061] x26: 000000007fffffff x25: 0000000000000010 x24: 0000000000002000 [ 2.329101] x23: ffff800083d6fce8 x22: ffff8000832222e8 x21: ffff800083222388 [ 2.329118] x20: f2ff0000c1674410 x19: f5ff0000c16364c0 x18: ffff800083d80030 [ 2.329135] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 2.329152] x14: 0000000000000000 x13: 0a73747369786520 x12: 79646165726c6120 [ 2.329169] x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : 0000000000000000 [ 2.329194] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 [ 2.329210] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 2.329226] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 2.329291] Call trace: [ 2.329407] __kmem_cache_create_args+0xb8/0x3b0 [ 2.329499] kmem_buckets_create+0xfc/0x320 [ 2.329526] init_user_buckets+0x34/0x78 [ 2.329540] do_one_initcall+0x64/0x3c8 [ 2.329550] kernel_init_freeable+0x26c/0x578 [ 2.329562] kernel_init+0x3c/0x258 [ 2.329574] ret_from_fork+0x10/0x20 [ 2.329698] ---[ end trace 0000000000000000 ]--- [ 2.403704] ------------[ cut here ]------------ [ 2.404716] kmem_cache of name 'msg_msg-16' already exists [ 2.404801] WARNING: CPU: 2 PID: 1 at mm/slab_common.c:107 __kmem_cache_create_args+0xb8/0x3b0 [ 2.404842] Modules linked in: [ 2.404971] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.12.0-rc5mm-unstable-arm64+ #12 [ 2.405026] Tainted: [W]=WARN [ 2.405043] Hardware name: QEMU QEMU Virtual Machine, BIOS 2024.02-2 03/11/2024 [ 2.405057] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2.405079] pc : __kmem_cache_create_args+0xb8/0x3b0 [ 2.405100] lr : __kmem_cache_create_args+0xb8/0x3b0 [ 2.405111] sp : ffff800083d6fc50 [ 2.405115] x29: ffff800083d6fc50 x28: fbff0000c1674410 x27: ffff8000820b0598 [ 2.405135] x26: 000000000000ffd0 x25: 0000000000000010 x24: 0000000000006000 [ 2.405153] x23: ffff800083d6fce8 x22: ffff8000832222e8 x21: ffff800083222388 [ 2.405169] x20: fbff0000c1674410 x19: fdff0000c163d6c0 x18: ffff800083d80030 [ 2.405185] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 2.405201] x14: 0000000000000000 x13: 0a73747369786520 x12: 79646165726c6120 [ 2.405217] x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : 0000000000000000 [ 2.405233] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 [ 2.405248] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 2.405271] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 2.405287] Call trace: [ 2 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50275", "url": "https://ubuntu.com/security/CVE-2024-50275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64/sve: Discard stale CPU state when handling SVE traps The logic for handling SVE traps manipulates saved FPSIMD/SVE state incorrectly, and a race with preemption can result in a task having TIF_SVE set and TIF_FOREIGN_FPSTATE clear even though the live CPU state is stale (e.g. with SVE traps enabled). This has been observed to result in warnings from do_sve_acc() where SVE traps are not expected while TIF_SVE is set: | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* SVE access shouldn't have trapped */ Warnings of this form have been reported intermittently, e.g. https://lore.kernel.org/linux-arm-kernel/CA+G9fYtEGe_DhY2Ms7+L7NKsLYUomGsgqpdBj+QwDLeSg=JhGg@mail.gmail.com/ https://lore.kernel.org/linux-arm-kernel/000000000000511e9a060ce5a45c@google.com/ The race can occur when the SVE trap handler is preempted before and after manipulating the saved FPSIMD/SVE state, starting and ending on the same CPU, e.g. | void do_sve_acc(unsigned long esr, struct pt_regs *regs) | { | // Trap on CPU 0 with TIF_SVE clear, SVE 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(); | | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* SVE access shouldn't have trapped */ | | sve_init_regs() { | if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) { | ... | } else { | fpsimd_to_sve(current); | current->thread.fp_type = FP_STATE_SVE; | } | } | | 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 SVE 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.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50276", "url": "https://ubuntu.com/security/CVE-2024-50276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: vertexcom: mse102x: Fix possible double free of TX skb The scope of the TX skb is wider than just mse102x_tx_frame_spi(), so in case the TX skb room needs to be expanded, we should free the the temporary skb instead of the original skb. Otherwise the original TX skb pointer would be freed again in mse102x_tx_work(), which leads to crashes: Internal error: Oops: 0000000096000004 [#2] PREEMPT SMP CPU: 0 PID: 712 Comm: kworker/0:1 Tainted: G D 6.6.23 Hardware name: chargebyte Charge SOM DC-ONE (DT) Workqueue: events mse102x_tx_work [mse102x] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_release_data+0xb8/0x1d8 lr : skb_release_data+0x1ac/0x1d8 sp : ffff8000819a3cc0 x29: ffff8000819a3cc0 x28: ffff0000046daa60 x27: ffff0000057f2dc0 x26: ffff000005386c00 x25: 0000000000000002 x24: 00000000ffffffff x23: 0000000000000000 x22: 0000000000000001 x21: ffff0000057f2e50 x20: 0000000000000006 x19: 0000000000000000 x18: ffff00003fdacfcc x17: e69ad452d0c49def x16: 84a005feff870102 x15: 0000000000000000 x14: 000000000000024a x13: 0000000000000002 x12: 0000000000000000 x11: 0000000000000400 x10: 0000000000000930 x9 : ffff00003fd913e8 x8 : fffffc00001bc008 x7 : 0000000000000000 x6 : 0000000000000008 x5 : ffff00003fd91340 x4 : 0000000000000000 x3 : 0000000000000009 x2 : 00000000fffffffe x1 : 0000000000000000 x0 : 0000000000000000 Call trace: skb_release_data+0xb8/0x1d8 kfree_skb_reason+0x48/0xb0 mse102x_tx_work+0x164/0x35c [mse102x] process_one_work+0x138/0x260 worker_thread+0x32c/0x438 kthread+0x118/0x11c ret_from_fork+0x10/0x20 Code: aa1303e0 97fffab6 72001c1f 54000141 (f9400660)", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53066", "url": "https://ubuntu.com/security/CVE-2024-53066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfs: Fix KMSAN warning in decode_getfattr_attrs() Fix the following KMSAN warning: CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G B Tainted: [B]=BAD_PAGE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) ===================================================== ===================================================== BUG: KMSAN: uninit-value in decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_generic+0x806/0xb00 nfs4_xdr_dec_getattr+0x1de/0x240 rpcauth_unwrap_resp_decode+0xab/0x100 rpcauth_unwrap_resp+0x95/0xc0 call_decode+0x4ff/0xb50 __rpc_execute+0x57b/0x19d0 rpc_execute+0x368/0x5e0 rpc_run_task+0xcfe/0xee0 nfs4_proc_getattr+0x5b5/0x990 __nfs_revalidate_inode+0x477/0xd00 nfs_access_get_cached+0x1021/0x1cc0 nfs_do_access+0x9f/0xae0 nfs_permission+0x1e4/0x8c0 inode_permission+0x356/0x6c0 link_path_walk+0x958/0x1330 path_lookupat+0xce/0x6b0 filename_lookup+0x23e/0x770 vfs_statx+0xe7/0x970 vfs_fstatat+0x1f2/0x2c0 __se_sys_newfstatat+0x67/0x880 __x64_sys_newfstatat+0xbd/0x120 x64_sys_call+0x1826/0x3cf0 do_syscall_64+0xd0/0x1b0 entry_SYSCALL_64_after_hwframe+0x77/0x7f The KMSAN warning is triggered in decode_getfattr_attrs(), when calling decode_attr_mdsthreshold(). It appears that fattr->mdsthreshold is not initialized. Fix the issue by initializing fattr->mdsthreshold to NULL in nfs_fattr_init().", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53067", "url": "https://ubuntu.com/security/CVE-2024-53067", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Start the RTC update work later The RTC update work involves runtime resuming the UFS controller. Hence, only start the RTC update work after runtime power management in the UFS driver has been fully initialized. This patch fixes the following kernel crash: Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP Workqueue: events ufshcd_rtc_work Call trace: _raw_spin_lock_irqsave+0x34/0x8c (P) pm_runtime_get_if_active+0x24/0x9c (L) pm_runtime_get_if_active+0x24/0x9c ufshcd_rtc_work+0x138/0x1b4 process_one_work+0x148/0x288 worker_thread+0x2cc/0x3d4 kthread+0x110/0x114 ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50277", "url": "https://ubuntu.com/security/CVE-2024-50277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: fix a crash if blk_alloc_disk fails If blk_alloc_disk fails, the variable md->disk is set to an error value. cleanup_mapped_device will see that md->disk is non-NULL and it will attempt to access it, causing a crash on this statement \"md->disk->private_data = NULL;\".", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50278", "url": "https://ubuntu.com/security/CVE-2024-50278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix potential out-of-bounds access on the first resume Out-of-bounds access occurs if the fast device is expanded unexpectedly before the first-time resume of the cache table. This happens because expanding the fast device requires reloading the cache table for cache_create to allocate new in-core data structures that fit the new size, and the check in cache_preresume is not performed during the first resume, leading to the issue. Reproduce steps: 1. prepare component devices: 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\" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct 2. load a cache table of 512 cache blocks, and deliberately expand the fast device before resuming the cache, making the in-core data structures inadequate. dmsetup create cache --notable dmsetup reload cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" dmsetup reload cdata --table \"0 131072 linear /dev/sdc 8192\" dmsetup resume cdata dmsetup resume cache 3. suspend the cache to write out the in-core dirty bitset and hint array, leading to out-of-bounds access to the dirty bitset at offset 0x40: dmsetup suspend cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80 Read of size 8 at addr ffffc90000085040 by task dmsetup/90 (...snip...) The buggy address belongs to the virtual mapping at [ffffc90000085000, ffffc90000087000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by checking the size change on the first resume.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50279", "url": "https://ubuntu.com/security/CVE-2024-50279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix out-of-bounds access to the dirty bitset when resizing dm-cache checks the dirty bits of the cache blocks to be dropped when shrinking the fast device, but an index bug in bitset iteration causes out-of-bounds access. Reproduce steps: 1. create a cache device of 1024 cache blocks (128 bytes dirty bitset) dmsetup create cmeta --table \"0 8192 linear /dev/sdc 0\" dmsetup create cdata --table \"0 131072 linear /dev/sdc 8192\" dmsetup create corig --table \"0 524288 linear /dev/sdc 262144\" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" 2. shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80) dmsetup suspend cache dmsetup reload cdata --table \"0 65536 linear /dev/sdc 8192\" dmsetup resume cdata dmsetup resume cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131 (...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by making the index post-incremented.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50280", "url": "https://ubuntu.com/security/CVE-2024-50280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix flushing uninitialized delayed_work on cache_ctr error An unexpected WARN_ON from flush_work() may occur when cache creation fails, caused by destroying the uninitialized delayed_work waker in the error path of cache_create(). For example, the warning appears on the superblock checksum error. Reproduce steps: 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\" dd if=/dev/urandom of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" Kernel logs: (snip) WARNING: CPU: 0 PID: 84 at kernel/workqueue.c:4178 __flush_work+0x5d4/0x890 Fix by pulling out the cancel_delayed_work_sync() from the constructor's error path. This patch doesn't affect the use-after-free fix for concurrent dm_resume and dm_destroy (commit 6a459d8edbdb (\"dm cache: Fix UAF in destroy()\")) as cache_dtr is not changed.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50281", "url": "https://ubuntu.com/security/CVE-2024-50281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: trusted: dcp: fix NULL dereference in AEAD crypto operation When sealing or unsealing a key blob we currently do not wait for the AEAD cipher operation to finish and simply return after submitting the request. If there is some load on the system we can exit before the cipher operation is done and the buffer we read from/write to is already removed from the stack. This will e.g. result in NULL pointer dereference errors in the DCP driver during blob creation. Fix this by waiting for the AEAD cipher operation to finish before resuming the seal and unseal calls.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50282", "url": "https://ubuntu.com/security/CVE-2024-50282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read() Avoid a possible buffer overflow if size is larger than 4K. (cherry picked from commit f5d873f5825b40d886d03bd2aede91d4cf002434)", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53071", "url": "https://ubuntu.com/security/CVE-2024-53071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Be stricter about IO mapping flags The current panthor_device_mmap_io() implementation has two issues: 1. For mapping DRM_PANTHOR_USER_FLUSH_ID_MMIO_OFFSET, panthor_device_mmap_io() bails if VM_WRITE is set, but does not clear VM_MAYWRITE. That means userspace can use mprotect() to make the mapping writable later on. This is a classic Linux driver gotcha. I don't think this actually has any impact in practice: When the GPU is powered, writes to the FLUSH_ID seem to be ignored; and when the GPU is not powered, the dummy_latest_flush page provided by the driver is deliberately designed to not do any flushes, so the only thing writing to the dummy_latest_flush could achieve would be to make *more* flushes happen. 2. panthor_device_mmap_io() does not block MAP_PRIVATE mappings (which are mappings without the VM_SHARED flag). MAP_PRIVATE in combination with VM_MAYWRITE indicates that the VMA has copy-on-write semantics, which for VM_PFNMAP are semi-supported but fairly cursed. In particular, in such a mapping, the driver can only install PTEs during mmap() by calling remap_pfn_range() (because remap_pfn_range() wants to **store the physical address of the mapped physical memory into the vm_pgoff of the VMA**); installing PTEs later on with a fault handler (as panthor does) is not supported in private mappings, and so if you try to fault in such a mapping, vmf_insert_pfn_prot() splats when it hits a BUG() check. Fix it by clearing the VM_MAYWRITE flag (userspace writing to the FLUSH_ID doesn't make sense) and requiring VM_SHARED (copy-on-write semantics for the FLUSH_ID don't make sense). Reproducers for both scenarios are in the notes of my patch on the mailing list; I tested that these bugs exist on a Rock 5B machine. Note that I only compile-tested the patch, I haven't tested it; I don't have a working kernel build setup for the test machine yet. Please test it before applying it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53080", "url": "https://ubuntu.com/security/CVE-2024-53080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Lock XArray when getting entries for the VM Similar to commit cac075706f29 (\"drm/panthor: Fix race when converting group handle to group object\") we need to use the XArray's internal locking when retrieving a vm pointer from there. v2: Removed part of the patch that was trying to protect fetching the heap pointer from XArray, as that operation is protected by the @pool->lock.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53084", "url": "https://ubuntu.com/security/CVE-2024-53084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Break an object reference loop When remaining resources are being cleaned up on driver close, outstanding VM mappings may result in resources being leaked, due to an object reference loop, as shown below, with each object (or set of objects) referencing the object below it: PVR GEM Object GPU scheduler \"finished\" fence GPU scheduler “scheduled” fence PVR driver “done” fence PVR Context PVR VM Context PVR VM Mappings PVR GEM Object The reference that the PVR VM Context has on the VM mappings is a soft one, in the sense that the freeing of outstanding VM mappings is done as part of VM context destruction; no reference counts are involved, as is the case for all the other references in the loop. To break the reference loop during cleanup, free the outstanding VM mappings before destroying the PVR Context associated with the VM context.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53085", "url": "https://ubuntu.com/security/CVE-2024-53085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: Lock TPM chip in tpm_pm_suspend() first Setting TPM_CHIP_FLAG_SUSPENDED in the end of tpm_pm_suspend() can be racy according, as this leaves window for tpm_hwrng_read() to be called while the operation is in progress. The recent bug report gives also evidence of this behaviour. Aadress this by locking the TPM chip before checking any chip->flags both in tpm_pm_suspend() and tpm_hwrng_read(). Move TPM_CHIP_FLAG_SUSPENDED check inside tpm_get_random() so that it will be always checked only when the lock is reserved.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53086", "url": "https://ubuntu.com/security/CVE-2024-53086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Drop VM dma-resv lock on xe_sync_in_fence_get failure in exec IOCTL Upon failure all locks need to be dropped before returning to the user. (cherry picked from commit 7d1a4258e602ffdce529f56686925034c1b3b095)", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53087", "url": "https://ubuntu.com/security/CVE-2024-53087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix possible exec queue leak in exec IOCTL In a couple of places after an exec queue is looked up the exec IOCTL returns on input errors without dropping the exec queue ref. Fix this ensuring the exec queue ref is dropped on input error. (cherry picked from commit 07064a200b40ac2195cb6b7b779897d9377e5e6f)", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50283", "url": "https://ubuntu.com/security/CVE-2024-50283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-use-after-free in smb3_preauth_hash_rsp ksmbd_user_session_put should be called under smb3_preauth_hash_rsp(). It will avoid freeing session before calling smb3_preauth_hash_rsp().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50284", "url": "https://ubuntu.com/security/CVE-2024-50284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix the missing xa_store error check xa_store() can fail, it return xa_err(-EINVAL) if the entry cannot be stored in an XArray, or xa_err(-ENOMEM) if memory allocation failed, so check error for xa_store() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50285", "url": "https://ubuntu.com/security/CVE-2024-50285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: check outstanding simultaneous SMB operations If Client send simultaneous SMB operations to ksmbd, It exhausts too much memory through the \"ksmbd_work_cache”. It will cause OOM issue. ksmbd has a credit mechanism but it can't handle this problem. This patch add the check if it exceeds max credits to prevent this problem by assuming that one smb request consumes at least one credit.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50286", "url": "https://ubuntu.com/security/CVE-2024-50286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-use-after-free in ksmbd_smb2_session_create There is a race condition between ksmbd_smb2_session_create and ksmbd_expire_session. This patch add missing sessions_table_lock while adding/deleting session from global session table.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50287", "url": "https://ubuntu.com/security/CVE-2024-50287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-tpg: prevent the risk of a division by zero As reported by Coverity, the logic at tpg_precalculate_line() blindly rescales the buffer even when scaled_witdh is equal to zero. If this ever happens, this will cause a division by zero. Instead, add a WARN_ON_ONCE() to trigger such cases and return without doing any precalculation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50288", "url": "https://ubuntu.com/security/CVE-2024-50288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: fix buffer overwrite when using > 32 buffers The maximum number of buffers that can be requested was increased to 64 for the video capture queue. But video capture used a must_blank array that was still sized for 32 (VIDEO_MAX_FRAME). This caused an out-of-bounds write when using buffer indices >= 32. Create a new define MAX_VID_CAP_BUFFERS that is used to access the must_blank array and set max_num_buffers for the video capture queue. This solves a crash reported by: \thttps://bugzilla.kernel.org/show_bug.cgi?id=219258", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50289", "url": "https://ubuntu.com/security/CVE-2024-50289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: av7110: fix a spectre vulnerability As warned by smatch: \tdrivers/staging/media/av7110/av7110_ca.c:270 dvb_ca_ioctl() warn: potential spectre issue 'av7110->ci_slot' [w] (local cap) There is a spectre-related vulnerability at the code. Fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50290", "url": "https://ubuntu.com/security/CVE-2024-50290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx24116: prevent overflows on SNR calculus as reported by Coverity, if reading SNR registers fail, a negative number will be returned, causing an underflow when reading SNR registers. Prevent that.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53061", "url": "https://ubuntu.com/security/CVE-2024-53061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: s5p-jpeg: prevent buffer overflows The current logic allows word to be less than 2. If this happens, there will be buffer overflows, as reported by smatch. Add extra checks to prevent it. While here, remove an unused word = 0 assignment.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53081", "url": "https://ubuntu.com/security/CVE-2024-53081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ar0521: don't overflow when checking PLL values The PLL checks are comparing 64 bit integers with 32 bit ones, as reported by Coverity. Depending on the values of the variables, this may underflow. Fix it ensuring that both sides of the expression are u64.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53062", "url": "https://ubuntu.com/security/CVE-2024-53062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mgb4: protect driver against spectre Frequency range is set from sysfs via frequency_range_store(), being vulnerable to spectre, as reported by smatch: \tdrivers/media/pci/mgb4/mgb4_cmt.c:231 mgb4_cmt_set_vin_freq_range() warn: potential spectre issue 'cmt_vals_in' [r] \tdrivers/media/pci/mgb4/mgb4_cmt.c:238 mgb4_cmt_set_vin_freq_range() warn: possible spectre second half. 'reg_set' Fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50291", "url": "https://ubuntu.com/security/CVE-2024-50291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvb-core: add missing buffer index check dvb_vb2_expbuf() didn't check if the given buffer index was for a valid buffer. Add this check.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50292", "url": "https://ubuntu.com/security/CVE-2024-50292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: stm32: spdifrx: fix dma channel release in stm32_spdifrx_remove In case of error when requesting ctrl_chan DMA channel, ctrl_chan is not null. So the release of the dma channel leads to the following issue: [ 4.879000] st,stm32-spdifrx 500d0000.audio-controller: dma_request_slave_channel error -19 [ 4.888975] Unable to handle kernel NULL pointer dereference at virtual address 000000000000003d [...] [ 5.096577] Call trace: [ 5.099099] dma_release_channel+0x24/0x100 [ 5.103235] stm32_spdifrx_remove+0x24/0x60 [snd_soc_stm32_spdifrx] [ 5.109494] stm32_spdifrx_probe+0x320/0x4c4 [snd_soc_stm32_spdifrx] To avoid this issue, release channel only if the pointer is valid.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53063", "url": "https://ubuntu.com/security/CVE-2024-53063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvbdev: prevent the risk of out of memory access The dvbdev contains a static variable used to store dvb minors. The behavior of it depends if CONFIG_DVB_DYNAMIC_MINORS is set or not. When not set, dvb_register_device() won't check for boundaries, as it will rely that a previous call to dvb_register_adapter() would already be enforcing it. On a similar way, dvb_device_open() uses the assumption that the register functions already did the needed checks. This can be fragile if some device ends using different calls. This also generate warnings on static check analysers like Coverity. So, add explicit guards to prevent potential risk of OOM issues.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50293", "url": "https://ubuntu.com/security/CVE-2024-50293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: do not leave a dangling sk pointer in __smc_create() Thanks to commit 4bbd360a5084 (\"socket: Print pf->create() when it does not clear sock->sk on failure.\"), syzbot found an issue with AF_SMC: smc_create must clear sock->sk on failure, family: 43, type: 1, protocol: 0 WARNING: CPU: 0 PID: 5827 at net/socket.c:1565 __sock_create+0x96f/0xa30 net/socket.c:1563 Modules linked in: CPU: 0 UID: 0 PID: 5827 Comm: syz-executor259 Not tainted 6.12.0-rc6-next-20241106-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:__sock_create+0x96f/0xa30 net/socket.c:1563 Code: 03 00 74 08 4c 89 e7 e8 4f 3b 85 f8 49 8b 34 24 48 c7 c7 40 89 0c 8d 8b 54 24 04 8b 4c 24 0c 44 8b 44 24 08 e8 32 78 db f7 90 <0f> 0b 90 90 e9 d3 fd ff ff 89 e9 80 e1 07 fe c1 38 c1 0f 8c ee f7 RSP: 0018:ffffc90003e4fda0 EFLAGS: 00010246 RAX: 099c6f938c7f4700 RBX: 1ffffffff1a595fd RCX: ffff888034823c00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 00000000ffffffe9 R08: ffffffff81567052 R09: 1ffff920007c9f50 R10: dffffc0000000000 R11: fffff520007c9f51 R12: ffffffff8d2cafe8 R13: 1ffffffff1a595fe R14: ffffffff9a789c40 R15: ffff8880764298c0 FS: 000055557b518380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa62ff43225 CR3: 0000000031628000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: sock_create net/socket.c:1616 [inline] __sys_socket_create net/socket.c:1653 [inline] __sys_socket+0x150/0x3c0 net/socket.c:1700 __do_sys_socket net/socket.c:1714 [inline] __se_sys_socket net/socket.c:1712 [inline] For reference, see commit 2d859aff775d (\"Merge branch 'do-not-leave-dangling-sk-pointers-in-pf-create-functions'\")", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50294", "url": "https://ubuntu.com/security/CVE-2024-50294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix missing locking causing hanging calls If a call gets aborted (e.g. because kafs saw a signal) between it being queued for connection and the I/O thread picking up the call, the abort will be prioritised over the connection and it will be removed from local->new_client_calls by rxrpc_disconnect_client_call() without a lock being held. This may cause other calls on the list to disappear if a race occurs. Fix this by taking the client_call_lock when removing a call from whatever list its ->wait_link happens to be on.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50295", "url": "https://ubuntu.com/security/CVE-2024-50295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: arc: fix the device for dma_map_single/dma_unmap_single The ndev->dev and pdev->dev aren't the same device, use ndev->dev.parent which has dma_mask, ndev->dev.parent is just pdev->dev. Or it would cause the following issue: [ 39.933526] ------------[ cut here ]------------ [ 39.938414] WARNING: CPU: 1 PID: 501 at kernel/dma/mapping.c:149 dma_map_page_attrs+0x90/0x1f8", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53082", "url": "https://ubuntu.com/security/CVE-2024-53082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_net: Add hash_key_length check Add hash_key_length check in virtnet_probe() to avoid possible out of bound errors when setting/reading the hash key.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50296", "url": "https://ubuntu.com/security/CVE-2024-50296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash when uninstalling driver When the driver is uninstalled and the VF is disabled concurrently, a kernel crash occurs. The reason is that the two actions call function pci_disable_sriov(). The num_VFs is checked to determine whether to release the corresponding resources. During the second calling, num_VFs is not 0 and the resource release function is called. However, the corresponding resource has been released during the first invoking. Therefore, the problem occurs: [15277.839633][T50670] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ... [15278.131557][T50670] Call trace: [15278.134686][T50670] klist_put+0x28/0x12c [15278.138682][T50670] klist_del+0x14/0x20 [15278.142592][T50670] device_del+0xbc/0x3c0 [15278.146676][T50670] pci_remove_bus_device+0x84/0x120 [15278.151714][T50670] pci_stop_and_remove_bus_device+0x6c/0x80 [15278.157447][T50670] pci_iov_remove_virtfn+0xb4/0x12c [15278.162485][T50670] sriov_disable+0x50/0x11c [15278.166829][T50670] pci_disable_sriov+0x24/0x30 [15278.171433][T50670] hnae3_unregister_ae_algo_prepare+0x60/0x90 [hnae3] [15278.178039][T50670] hclge_exit+0x28/0xd0 [hclge] [15278.182730][T50670] __se_sys_delete_module.isra.0+0x164/0x230 [15278.188550][T50670] __arm64_sys_delete_module+0x1c/0x30 [15278.193848][T50670] invoke_syscall+0x50/0x11c [15278.198278][T50670] el0_svc_common.constprop.0+0x158/0x164 [15278.203837][T50670] do_el0_svc+0x34/0xcc [15278.207834][T50670] el0_svc+0x20/0x30 For details, see the following figure. rmmod hclge disable VFs ---------------------------------------------------- hclge_exit() sriov_numvfs_store() ... device_lock() pci_disable_sriov() hns3_pci_sriov_configure() pci_disable_sriov() sriov_disable() sriov_disable() if !num_VFs : if !num_VFs : return; return; sriov_del_vfs() sriov_del_vfs() ... ... klist_put() klist_put() ... ... num_VFs = 0; num_VFs = 0; device_unlock(); In this patch, when driver is removing, we get the device_lock() to protect num_VFs, just like sriov_numvfs_store().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53088", "url": "https://ubuntu.com/security/CVE-2024-53088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: fix race condition by adding filter's intermediate sync state Fix a race condition in the i40e driver that leads to MAC/VLAN filters becoming corrupted and leaking. Address the issue that occurs under heavy load when multiple threads are concurrently modifying MAC/VLAN filters by setting mac and port VLAN. 1. Thread T0 allocates a filter in i40e_add_filter() within i40e_ndo_set_vf_port_vlan(). 2. Thread T1 concurrently frees the filter in __i40e_del_filter() within i40e_ndo_set_vf_mac(). 3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which refers to the already freed filter memory, causing corruption. Reproduction steps: 1. Spawn multiple VFs. 2. Apply a concurrent heavy load by running parallel operations to change MAC addresses on the VFs and change port VLANs on the host. 3. Observe errors in dmesg: \"Error I40E_AQ_RC_ENOSPC adding RX filters on VF XX, \tplease set promiscuous on manually for VF XX\". Exact code for stable reproduction Intel can't open-source now. The fix involves implementing a new intermediate filter state, I40E_FILTER_NEW_SYNC, for the time when a filter is on a tmp_add_list. These filters cannot be deleted from the hash list directly but must be removed using the full process.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50297", "url": "https://ubuntu.com/security/CVE-2024-50297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: xilinx: axienet: Enqueue Tx packets in dql before dmaengine starts Enqueue packets in dql after dma engine starts causes race condition. Tx transfer starts once dma engine is started and may execute dql dequeue in completion before it gets queued. It results in following kernel crash while running iperf stress test: kernel BUG at lib/dynamic_queue_limits.c:99! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP pc : dql_completed+0x238/0x248 lr : dql_completed+0x3c/0x248 Call trace: dql_completed+0x238/0x248 axienet_dma_tx_cb+0xa0/0x170 xilinx_dma_do_tasklet+0xdc/0x290 tasklet_action_common+0xf8/0x11c tasklet_action+0x30/0x3c handle_softirqs+0xf8/0x230 Start dmaengine after enqueue in dql fixes the crash.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50298", "url": "https://ubuntu.com/security/CVE-2024-50298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: enetc: allocate vf_state during PF probes In the previous implementation, vf_state is allocated memory only when VF is enabled. However, net_device_ops::ndo_set_vf_mac() may be called before VF is enabled to configure the MAC address of VF. If this is the case, enetc_pf_set_vf_mac() will access vf_state, resulting in access to a null pointer. The simplified error log is as follows. root@ls1028ardb:~# ip link set eno0 vf 1 mac 00:0c:e7:66:77:89 [ 173.543315] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 [ 173.637254] pc : enetc_pf_set_vf_mac+0x3c/0x80 Message from sy [ 173.641973] lr : do_setlink+0x4a8/0xec8 [ 173.732292] Call trace: [ 173.734740] enetc_pf_set_vf_mac+0x3c/0x80 [ 173.738847] __rtnl_newlink+0x530/0x89c [ 173.742692] rtnl_newlink+0x50/0x7c [ 173.746189] rtnetlink_rcv_msg+0x128/0x390 [ 173.750298] netlink_rcv_skb+0x60/0x130 [ 173.754145] rtnetlink_rcv+0x18/0x24 [ 173.757731] netlink_unicast+0x318/0x380 [ 173.761665] netlink_sendmsg+0x17c/0x3c8", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50299", "url": "https://ubuntu.com/security/CVE-2024-50299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: properly validate chunk size in sctp_sf_ootb() A size validation fix similar to that in Commit 50619dbf8db7 (\"sctp: add size validation when walking chunks\") is also required in sctp_sf_ootb() to address a crash reported by syzbot: BUG: KMSAN: uninit-value in sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_do_sm+0x181/0x93d0 net/sctp/sm_sideeffect.c:1166 sctp_endpoint_bh_rcv+0xc38/0xf90 net/sctp/endpointola.c:407 sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88 sctp_rcv+0x3831/0x3b20 net/sctp/input.c:243 sctp4_rcv+0x42/0x50 net/sctp/protocol.c:1159 ip_protocol_deliver_rcu+0xb51/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50300", "url": "https://ubuntu.com/security/CVE-2024-50300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: rtq2208: Fix uninitialized use of regulator_config Fix rtq2208 driver uninitialized use to cause kernel error.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50301", "url": "https://ubuntu.com/security/CVE-2024-50301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: security/keys: fix slab-out-of-bounds in key_task_permission KASAN reports an out of bounds read: BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline] BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362 CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0x107/0x167 lib/dump_stack.c:123 print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 __kuid_val include/linux/uidgid.h:36 [inline] uid_eq include/linux/uidgid.h:63 [inline] key_task_permission+0x394/0x410 security/keys/permission.c:54 search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793 This issue was also reported by syzbot. It can be reproduced by following these steps(more details [1]): 1. Obtain more than 32 inputs that have similar hashes, which ends with the pattern '0xxxxxxxe6'. 2. Reboot and add the keys obtained in step 1. The reproducer demonstrates how this issue happened: 1. In the search_nested_keyrings function, when it iterates through the slots in a node(below tag ascend_to_node), if the slot pointer is meta and node->back_pointer != NULL(it means a root), it will proceed to descend_to_node. However, there is an exception. If node is the root, and one of the slots points to a shortcut, it will be treated as a keyring. 2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function. However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as ASSOC_ARRAY_PTR_SUBTYPE_MASK. 3. When 32 keys with the similar hashes are added to the tree, the ROOT has keys with hashes that are not similar (e.g. slot 0) and it splits NODE A without using a shortcut. When NODE A is filled with keys that all hashes are xxe6, the keys are similar, NODE A will split with a shortcut. Finally, it forms the tree as shown below, where slot 6 points to a shortcut. NODE A +------>+---+ ROOT | | 0 | xxe6 +---+ | +---+ xxxx | 0 | shortcut : : xxe6 +---+ | +---+ xxe6 : : | | | xxe6 +---+ | +---+ | 6 |---+ : : xxe6 +---+ +---+ xxe6 : : | f | xxe6 +---+ +---+ xxe6 | f | +---+ 4. As mentioned above, If a slot(slot 6) of the root points to a shortcut, it may be mistakenly transferred to a key*, leading to a read out-of-bounds read. To fix this issue, one should jump to descend_to_node if the ptr is a shortcut, regardless of whether the node is root or not. [1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/ [jarkko: tweaked the commit message a bit to have an appropriate closes tag.]", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53072", "url": "https://ubuntu.com/security/CVE-2024-53072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/pmc: Detect when STB is not available Loading the amd_pmc module as: amd_pmc enable_stb=1 ...can result in the following messages in the kernel ring buffer: amd_pmc AMDI0009:00: SMU cmd failed. err: 0xff ioremap on RAM at 0x0000000000000000 - 0x0000000000ffffff WARNING: CPU: 10 PID: 2151 at arch/x86/mm/ioremap.c:217 __ioremap_caller+0x2cd/0x340 Further debugging reveals that this occurs when the requests for S2D_PHYS_ADDR_LOW and S2D_PHYS_ADDR_HIGH return a value of 0, indicating that the STB is inaccessible. To prevent the ioremap warning and provide clarity to the user, handle the invalid address and display an error message.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50302", "url": "https://ubuntu.com/security/CVE-2024-50302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: zero-initialize the report buffer Since the report buffer is used by all kinds of drivers in various ways, let's zero-initialize it during allocation to make sure that it can't be ever used to leak kernel memory via specially-crafted report.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53068", "url": "https://ubuntu.com/security/CVE-2024-53068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix slab-use-after-free in scmi_bus_notifier() The scmi_dev->name is released prematurely in __scmi_device_destroy(), which causes slab-use-after-free when accessing scmi_dev->name in scmi_bus_notifier(). So move the release of scmi_dev->name to scmi_device_release() to avoid slab-use-after-free. | BUG: KASAN: slab-use-after-free in strncmp+0xe4/0xec | Read of size 1 at addr ffffff80a482bcc0 by task swapper/0/1 | | CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.6.38-debug #1 | Hardware name: Qualcomm Technologies, Inc. SA8775P Ride (DT) | Call trace: | dump_backtrace+0x94/0x114 | show_stack+0x18/0x24 | dump_stack_lvl+0x48/0x60 | print_report+0xf4/0x5b0 | kasan_report+0xa4/0xec | __asan_report_load1_noabort+0x20/0x2c | strncmp+0xe4/0xec | scmi_bus_notifier+0x5c/0x54c | notifier_call_chain+0xb4/0x31c | blocking_notifier_call_chain+0x68/0x9c | bus_notify+0x54/0x78 | device_del+0x1bc/0x840 | device_unregister+0x20/0xb4 | __scmi_device_destroy+0xac/0x280 | scmi_device_destroy+0x94/0xd0 | scmi_chan_setup+0x524/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20 | | Allocated by task 1: | kasan_save_stack+0x2c/0x54 | kasan_set_track+0x2c/0x40 | kasan_save_alloc_info+0x24/0x34 | __kasan_kmalloc+0xa0/0xb8 | __kmalloc_node_track_caller+0x6c/0x104 | kstrdup+0x48/0x84 | kstrdup_const+0x34/0x40 | __scmi_device_create.part.0+0x8c/0x408 | scmi_device_create+0x104/0x370 | scmi_chan_setup+0x2a0/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20 | | Freed by task 1: | kasan_save_stack+0x2c/0x54 | kasan_set_track+0x2c/0x40 | kasan_save_free_info+0x38/0x5c | __kasan_slab_free+0xe8/0x164 | __kmem_cache_free+0x11c/0x230 | kfree+0x70/0x130 | kfree_const+0x20/0x40 | __scmi_device_destroy+0x70/0x280 | scmi_device_destroy+0x94/0xd0 | scmi_chan_setup+0x524/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53069", "url": "https://ubuntu.com/security/CVE-2024-53069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: qcom: scm: fix a NULL-pointer dereference Some SCM calls can be invoked with __scm being NULL (the driver may not have been and will not be probed as there's no SCM entry in device-tree). Make sure we don't dereference a NULL pointer.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50212", "url": "https://ubuntu.com/security/CVE-2024-50212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib: alloc_tag_module_unload must wait for pending kfree_rcu calls Ben Greear reports following splat: ------------[ cut here ]------------ net/netfilter/nf_nat_core.c:1114 module nf_nat func:nf_nat_register_fn has 256 allocated at module unload WARNING: CPU: 1 PID: 10421 at lib/alloc_tag.c:168 alloc_tag_module_unload+0x22b/0x3f0 Modules linked in: nf_nat(-) btrfs ufs qnx4 hfsplus hfs minix vfat msdos fat ... Hardware name: Default string Default string/SKYBAY, BIOS 5.12 08/04/2020 RIP: 0010:alloc_tag_module_unload+0x22b/0x3f0 codetag_unload_module+0x19b/0x2a0 ? codetag_load_module+0x80/0x80 nf_nat module exit calls kfree_rcu on those addresses, but the free operation is likely still pending by the time alloc_tag checks for leaks. Wait for outstanding kfree_rcu operations to complete before checking resolves this warning. Reproducer: unshare -n iptables-nft -t nat -A PREROUTING -p tcp grep nf_nat /proc/allocinfo # will list 4 allocations rmmod nft_chain_nat rmmod nf_nat # will WARN. [akpm@linux-foundation.org: add comment]", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53046", "url": "https://ubuntu.com/security/CVE-2024-53046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: dts: imx8ulp: correct the flexspi compatible string The flexspi on imx8ulp only has 16 LUTs, and imx8mm flexspi has 32 LUTs, so correct the compatible string here, otherwise will meet below error: [ 1.119072] ------------[ cut here ]------------ [ 1.123926] WARNING: CPU: 0 PID: 1 at drivers/spi/spi-nxp-fspi.c:855 nxp_fspi_exec_op+0xb04/0xb64 [ 1.133239] Modules linked in: [ 1.136448] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-rc6-next-20240902-00001-g131bf9439dd9 #69 [ 1.146821] Hardware name: NXP i.MX8ULP EVK (DT) [ 1.151647] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.158931] pc : nxp_fspi_exec_op+0xb04/0xb64 [ 1.163496] lr : nxp_fspi_exec_op+0xa34/0xb64 [ 1.168060] sp : ffff80008002b2a0 [ 1.171526] x29: ffff80008002b2d0 x28: 0000000000000000 x27: 0000000000000000 [ 1.179002] x26: ffff2eb645542580 x25: ffff800080610014 x24: ffff800080610000 [ 1.186480] x23: ffff2eb645548080 x22: 0000000000000006 x21: ffff2eb6455425e0 [ 1.193956] x20: 0000000000000000 x19: ffff80008002b5e0 x18: ffffffffffffffff [ 1.201432] x17: ffff2eb644467508 x16: 0000000000000138 x15: 0000000000000002 [ 1.208907] x14: 0000000000000000 x13: ffff2eb6400d8080 x12: 00000000ffffff00 [ 1.216378] x11: 0000000000000000 x10: ffff2eb6400d8080 x9 : ffff2eb697adca80 [ 1.223850] x8 : ffff2eb697ad3cc0 x7 : 0000000100000000 x6 : 0000000000000001 [ 1.231324] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000007a6 [ 1.238795] x2 : 0000000000000000 x1 : 00000000000001ce x0 : 00000000ffffff92 [ 1.246267] Call trace: [ 1.248824] nxp_fspi_exec_op+0xb04/0xb64 [ 1.253031] spi_mem_exec_op+0x3a0/0x430 [ 1.257139] spi_nor_read_id+0x80/0xcc [ 1.261065] spi_nor_scan+0x1ec/0xf10 [ 1.264901] spi_nor_probe+0x108/0x2fc [ 1.268828] spi_mem_probe+0x6c/0xbc [ 1.272574] spi_probe+0x84/0xe4 [ 1.275958] really_probe+0xbc/0x29c [ 1.279713] __driver_probe_device+0x78/0x12c [ 1.284277] driver_probe_device+0xd8/0x15c [ 1.288660] __device_attach_driver+0xb8/0x134 [ 1.293316] bus_for_each_drv+0x88/0xe8 [ 1.297337] __device_attach+0xa0/0x190 [ 1.301353] device_initial_probe+0x14/0x20 [ 1.305734] bus_probe_device+0xac/0xb0 [ 1.309752] device_add+0x5d0/0x790 [ 1.313408] __spi_add_device+0x134/0x204 [ 1.317606] of_register_spi_device+0x3b4/0x590 [ 1.322348] spi_register_controller+0x47c/0x754 [ 1.327181] devm_spi_register_controller+0x4c/0xa4 [ 1.332289] nxp_fspi_probe+0x1cc/0x2b0 [ 1.336307] platform_probe+0x68/0xc4 [ 1.340145] really_probe+0xbc/0x29c [ 1.343893] __driver_probe_device+0x78/0x12c [ 1.348457] driver_probe_device+0xd8/0x15c [ 1.352838] __driver_attach+0x90/0x19c [ 1.356857] bus_for_each_dev+0x7c/0xdc [ 1.360877] driver_attach+0x24/0x30 [ 1.364624] bus_add_driver+0xe4/0x208 [ 1.368552] driver_register+0x5c/0x124 [ 1.372573] __platform_driver_register+0x28/0x34 [ 1.377497] nxp_fspi_driver_init+0x1c/0x28 [ 1.381888] do_one_initcall+0x80/0x1c8 [ 1.385908] kernel_init_freeable+0x1c4/0x28c [ 1.390472] kernel_init+0x20/0x1d8 [ 1.394138] ret_from_fork+0x10/0x20 [ 1.397885] ---[ end trace 0000000000000000 ]--- [ 1.407908] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53052", "url": "https://ubuntu.com/security/CVE-2024-53052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/rw: fix missing NOWAIT check for O_DIRECT start write When io_uring starts a write, it'll call kiocb_start_write() to bump the super block rwsem, preventing any freezes from happening while that write is in-flight. The freeze side will grab that rwsem for writing, excluding any new writers from happening and waiting for existing writes to finish. But io_uring unconditionally uses kiocb_start_write(), which will block if someone is currently attempting to freeze the mount point. This causes a deadlock where freeze is waiting for previous writes to complete, but the previous writes cannot complete, as the task that is supposed to complete them is blocked waiting on starting a new write. This results in the following stuck trace showing that dependency with the write blocked starting a new write: task:fio state:D stack:0 pid:886 tgid:886 ppid:876 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_rwsem_wait+0x1e8/0x3f8 __percpu_down_read+0xe8/0x500 io_write+0xbb8/0xff8 io_issue_sqe+0x10c/0x1020 io_submit_sqes+0x614/0x2110 __arm64_sys_io_uring_enter+0x524/0x1038 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 INFO: task fsfreeze:7364 blocked for more than 15 seconds. Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963 with the attempting freezer stuck trying to grab the rwsem: task:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_down_write+0x2b0/0x680 freeze_super+0x248/0x8a8 do_vfs_ioctl+0x149c/0x1b18 __arm64_sys_ioctl+0xd0/0x1a0 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 Fix this by having the io_uring side honor IOCB_NOWAIT, and only attempt a blocking grab of the super block rwsem if it isn't set. For normal issue where IOCB_NOWAIT would always be set, this returns -EAGAIN which will have io_uring core issue a blocking attempt of the write. That will in turn also get completions run, ensuring forward progress. Since freezing requires CAP_SYS_ADMIN in the first place, this isn't something that can be triggered by a regular user.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50213", "url": "https://ubuntu.com/security/CVE-2024-50213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tests: hdmi: Fix memory leaks in drm_display_mode_from_cea_vic() modprobe drm_hdmi_state_helper_test and then rmmod it, the following memory leak occurs. The `mode` allocated in drm_mode_duplicate() called by drm_display_mode_from_cea_vic() is not freed, which cause the memory leak: \tunreferenced object 0xffffff80ccd18100 (size 128): \t comm \"kunit_try_catch\", pid 1851, jiffies 4295059695 \t hex dump (first 32 bytes): \t 57 62 00 00 80 02 90 02 f0 02 20 03 00 00 e0 01 Wb........ ..... \t ea 01 ec 01 0d 02 00 00 0a 00 00 00 00 00 00 00 ................ \t backtrace (crc c2f1aa95): \t [<000000000f10b11b>] kmemleak_alloc+0x34/0x40 \t [<000000001cd4cf73>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<00000000f1f3cffa>] drm_mode_duplicate+0x44/0x19c \t [<000000008cbeef13>] drm_display_mode_from_cea_vic+0x88/0x98 \t [<0000000019daaacf>] 0xffffffedc11ae69c \t [<000000000aad0f85>] kunit_try_run_case+0x13c/0x3ac \t [<00000000a9210bac>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<000000000a0b2e9e>] kthread+0x2e8/0x374 \t [<00000000bd668858>] ret_from_fork+0x10/0x20 \t...... Free `mode` by using drm_kunit_display_mode_from_cea_vic() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50214", "url": "https://ubuntu.com/security/CVE-2024-50214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/connector: hdmi: Fix memory leak in drm_display_mode_from_cea_vic() modprobe drm_connector_test and then rmmod drm_connector_test, the following memory leak occurs. The `mode` allocated in drm_mode_duplicate() called by drm_display_mode_from_cea_vic() is not freed, which cause the memory leak: \tunreferenced object 0xffffff80cb0ee400 (size 128): \t comm \"kunit_try_catch\", pid 1948, jiffies 4294950339 \t hex dump (first 32 bytes): \t 14 44 02 00 80 07 d8 07 04 08 98 08 00 00 38 04 .D............8. \t 3c 04 41 04 65 04 00 00 05 00 00 00 00 00 00 00 <.A.e........... \t backtrace (crc 90e9585c): \t [<00000000ec42e3d7>] kmemleak_alloc+0x34/0x40 \t [<00000000d0ef055a>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<00000000c2062161>] drm_mode_duplicate+0x44/0x19c \t [<00000000f96c74aa>] drm_display_mode_from_cea_vic+0x88/0x98 \t [<00000000d8f2c8b4>] 0xffffffdc982a4868 \t [<000000005d164dbc>] kunit_try_run_case+0x13c/0x3ac \t [<000000006fb23398>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<000000006ea56ca0>] kthread+0x2e8/0x374 \t [<000000000676063f>] ret_from_fork+0x10/0x20 \t...... Free `mode` by using drm_kunit_display_mode_from_cea_vic() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50215", "url": "https://ubuntu.com/security/CVE-2024-50215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: assign dh_key to NULL after kfree_sensitive ctrl->dh_key might be used across multiple calls to nvmet_setup_dhgroup() for the same controller. So it's better to nullify it after release on error path in order to avoid double free later in nvmet_destroy_auth(). Found by Linux Verification Center (linuxtesting.org) with Svace.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50216", "url": "https://ubuntu.com/security/CVE-2024-50216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix finding a last resort AG in xfs_filestream_pick_ag When the main loop in xfs_filestream_pick_ag fails to find a suitable AG it tries to just pick the online AG. But the loop for that uses args->pag as loop iterator while the later code expects pag to be set. Fix this by reusing the max_pag case for this last resort, and also add a check for impossible case of no AG just to make sure that the uninitialized pag doesn't even escape in theory.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50217", "url": "https://ubuntu.com/security/CVE-2024-50217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free of block device file in __btrfs_free_extra_devids() Mounting btrfs from two images (which have the same one fsid and two different dev_uuids) in certain executing order may trigger an UAF for variable 'device->bdev_file' in __btrfs_free_extra_devids(). And following are the details: 1. Attach image_1 to loop0, attach image_2 to loop1, and scan btrfs devices by ioctl(BTRFS_IOC_SCAN_DEV): / btrfs_device_1 ? loop0 fs_device \\ btrfs_device_2 ? loop1 2. mount /dev/loop0 /mnt btrfs_open_devices btrfs_device_1->bdev_file = btrfs_get_bdev_and_sb(loop0) btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree fail: btrfs_close_devices // -ENOMEM \t btrfs_close_bdev(btrfs_device_1) fput(btrfs_device_1->bdev_file) \t // btrfs_device_1->bdev_file is freed \t btrfs_close_bdev(btrfs_device_2) fput(btrfs_device_2->bdev_file) 3. mount /dev/loop1 /mnt btrfs_open_devices btrfs_get_bdev_and_sb(&bdev_file) // EIO, btrfs_device_1->bdev_file is not assigned, // which points to a freed memory area btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree btrfs_free_extra_devids if (btrfs_device_1->bdev_file) fput(btrfs_device_1->bdev_file) // UAF ! Fix it by setting 'device->bdev_file' as 'NULL' after closing the btrfs_device in btrfs_close_one_device().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53043", "url": "https://ubuntu.com/security/CVE-2024-53043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mctp i2c: handle NULL header address daddr can be NULL if there is no neighbour table entry present, in that case the tx packet should be dropped. saddr will usually be set by MCTP core, but check for NULL in case a packet is transmitted by a different protocol.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50303", "url": "https://ubuntu.com/security/CVE-2024-50303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: resource,kexec: walk_system_ram_res_rev must retain resource flags walk_system_ram_res_rev() erroneously discards resource flags when passing the information to the callback. This causes systems with IORESOURCE_SYSRAM_DRIVER_MANAGED memory to have these resources selected during kexec to store kexec buffers if that memory happens to be at placed above normal system ram. This leads to undefined behavior after reboot. If the kexec buffer is never touched, nothing happens. If the kexec buffer is touched, it could lead to a crash (like below) or undefined behavior. Tested on a system with CXL memory expanders with driver managed memory, TPM enabled, and CONFIG_IMA_KEXEC=y. Adding printk's showed the flags were being discarded and as a result the check for IORESOURCE_SYSRAM_DRIVER_MANAGED passes. find_next_iomem_res: name(System RAM (kmem)) \t\t start(10000000000) \t\t end(1034fffffff) \t\t flags(83000200) locate_mem_hole_top_down: start(10000000000) end(1034fffffff) flags(0) [.] BUG: unable to handle page fault for address: ffff89834ffff000 [.] #PF: supervisor read access in kernel mode [.] #PF: error_code(0x0000) - not-present page [.] PGD c04c8bf067 P4D c04c8bf067 PUD c04c8be067 PMD 0 [.] Oops: 0000 [#1] SMP [.] RIP: 0010:ima_restore_measurement_list+0x95/0x4b0 [.] RSP: 0018:ffffc900000d3a80 EFLAGS: 00010286 [.] RAX: 0000000000001000 RBX: 0000000000000000 RCX: ffff89834ffff000 [.] RDX: 0000000000000018 RSI: ffff89834ffff000 RDI: ffff89834ffff018 [.] RBP: ffffc900000d3ba0 R08: 0000000000000020 R09: ffff888132b8a900 [.] R10: 4000000000000000 R11: 000000003a616d69 R12: 0000000000000000 [.] R13: ffffffff8404ac28 R14: 0000000000000000 R15: ffff89834ffff000 [.] FS: 0000000000000000(0000) GS:ffff893d44640000(0000) knlGS:0000000000000000 [.] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [.] ata5: SATA link down (SStatus 0 SControl 300) [.] CR2: ffff89834ffff000 CR3: 000001034d00f001 CR4: 0000000000770ef0 [.] PKRU: 55555554 [.] Call Trace: [.] [.] ? __die+0x78/0xc0 [.] ? page_fault_oops+0x2a8/0x3a0 [.] ? exc_page_fault+0x84/0x130 [.] ? asm_exc_page_fault+0x22/0x30 [.] ? ima_restore_measurement_list+0x95/0x4b0 [.] ? template_desc_init_fields+0x317/0x410 [.] ? crypto_alloc_tfm_node+0x9c/0xc0 [.] ? init_ima_lsm+0x30/0x30 [.] ima_load_kexec_buffer+0x72/0xa0 [.] ima_init+0x44/0xa0 [.] __initstub__kmod_ima__373_1201_init_ima7+0x1e/0xb0 [.] ? init_ima_lsm+0x30/0x30 [.] do_one_initcall+0xad/0x200 [.] ? idr_alloc_cyclic+0xaa/0x110 [.] ? new_slab+0x12c/0x420 [.] ? new_slab+0x12c/0x420 [.] ? number+0x12a/0x430 [.] ? sysvec_apic_timer_interrupt+0xa/0x80 [.] ? asm_sysvec_apic_timer_interrupt+0x16/0x20 [.] ? parse_args+0xd4/0x380 [.] ? parse_args+0x14b/0x380 [.] kernel_init_freeable+0x1c1/0x2b0 [.] ? rest_init+0xb0/0xb0 [.] kernel_init+0x16/0x1a0 [.] ret_from_fork+0x2f/0x40 [.] ? rest_init+0xb0/0xb0 [.] ret_from_fork_asm+0x11/0x20 [.] ", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50218", "url": "https://ubuntu.com/security/CVE-2024-50218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow Syzbot reported a kernel BUG in ocfs2_truncate_inline. There are two reasons for this: first, the parameter value passed is greater than ocfs2_max_inline_data_with_xattr, second, the start and end parameters of ocfs2_truncate_inline are \"unsigned int\". So, we need to add a sanity check for byte_start and byte_len right before ocfs2_truncate_inline() in ocfs2_remove_inode_range(), if they are greater than ocfs2_max_inline_data_with_xattr return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50219", "url": "https://ubuntu.com/security/CVE-2024-50219", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50263", "url": "https://ubuntu.com/security/CVE-2024-50263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fork: only invoke khugepaged, ksm hooks if no error There is no reason to invoke these hooks early against an mm that is in an incomplete state. The change in commit d24062914837 (\"fork: use __mt_dup() to duplicate maple tree in dup_mmap()\") makes this more pertinent as we may be in a state where entries in the maple tree are not yet consistent. Their placement early in dup_mmap() only appears to have been meaningful for early error checking, and since functionally it'd require a very small allocation to fail (in practice 'too small to fail') that'd only occur in the most dire circumstances, meaning the fork would fail or be OOM'd in any case. Since both khugepaged and KSM tracking are there to provide optimisations to memory performance rather than critical functionality, it doesn't really matter all that much if, under such dire memory pressure, we fail to register an mm with these. As a result, we follow the example of commit d2081b2bf819 (\"mm: khugepaged: make khugepaged_enter() void function\") and make ksm_fork() a void function also. We only expose the mm to these functions once we are done with them and only if no error occurred in the fork operation.", "cve_priority": "medium", "cve_public_date": "2024-11-11 14:15:00 UTC" }, { "cve": "CVE-2024-50220", "url": "https://ubuntu.com/security/CVE-2024-50220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fork: do not invoke uffd on fork if error occurs Patch series \"fork: do not expose incomplete mm on fork\". During fork we may place the virtual memory address space into an inconsistent state before the fork operation is complete. In addition, we may encounter an error during the fork operation that indicates that the virtual memory address space is invalidated. As a result, we should not be exposing it in any way to external machinery that might interact with the mm or VMAs, machinery that is not designed to deal with incomplete state. We specifically update the fork logic to defer khugepaged and ksm to the end of the operation and only to be invoked if no error arose, and disallow uffd from observing fork events should an error have occurred. This patch (of 2): Currently on fork we expose the virtual address space of a process to userland unconditionally if uffd is registered in VMAs, regardless of whether an error arose in the fork. This is performed in dup_userfaultfd_complete() which is invoked unconditionally, and performs two duties - invoking registered handlers for the UFFD_EVENT_FORK event via dup_fctx(), and clearing down userfaultfd_fork_ctx objects established in dup_userfaultfd(). This is problematic, because the virtual address space may not yet be correctly initialised if an error arose. The change in commit d24062914837 (\"fork: use __mt_dup() to duplicate maple tree in dup_mmap()\") makes this more pertinent as we may be in a state where entries in the maple tree are not yet consistent. We address this by, on fork error, ensuring that we roll back state that we would otherwise expect to clean up through the event being handled by userland and perform the memory freeing duty otherwise performed by dup_userfaultfd_complete(). We do this by implementing a new function, dup_userfaultfd_fail(), which performs the same loop, only decrementing reference counts. Note that we perform mmgrab() on the parent and child mm's, however userfaultfd_ctx_put() will mmdrop() this once the reference count drops to zero, so we will avoid memory leaks correctly here.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53047", "url": "https://ubuntu.com/security/CVE-2024-53047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: init: protect sched with rcu_read_lock Enabling CONFIG_PROVE_RCU_LIST with its dependence CONFIG_RCU_EXPERT creates this splat when an MPTCP socket is created: ============================= WARNING: suspicious RCU usage 6.12.0-rc2+ #11 Not tainted ----------------------------- net/mptcp/sched.c:44 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 no locks held by mptcp_connect/176. stack backtrace: CPU: 0 UID: 0 PID: 176 Comm: mptcp_connect Not tainted 6.12.0-rc2+ #11 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl (lib/dump_stack.c:123) lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822) mptcp_sched_find (net/mptcp/sched.c:44 (discriminator 7)) mptcp_init_sock (net/mptcp/protocol.c:2867 (discriminator 1)) ? sock_init_data_uid (arch/x86/include/asm/atomic.h:28) inet_create.part.0.constprop.0 (net/ipv4/af_inet.c:386) ? __sock_create (include/linux/rcupdate.h:347 (discriminator 1)) __sock_create (net/socket.c:1576) __sys_socket (net/socket.c:1671) ? __pfx___sys_socket (net/socket.c:1712) ? do_user_addr_fault (arch/x86/mm/fault.c:1419 (discriminator 1)) __x64_sys_socket (net/socket.c:1728) do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) That's because when the socket is initialised, rcu_read_lock() is not used despite the explicit comment written above the declaration of mptcp_sched_find() in sched.c. Adding the missing lock/unlock avoids the warning.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50221", "url": "https://ubuntu.com/security/CVE-2024-50221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Vangogh: Fix kernel memory out of bounds write KASAN reports that the GPU metrics table allocated in vangogh_tables_init() is not large enough for the memset done in smu_cmn_init_soft_gpu_metrics(). Condensed report follows: [ 33.861314] BUG: KASAN: slab-out-of-bounds in smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu] [ 33.861799] Write of size 168 at addr ffff888129f59500 by task mangoapp/1067 ... [ 33.861808] CPU: 6 UID: 1000 PID: 1067 Comm: mangoapp Tainted: G W 6.12.0-rc4 #356 1a56f59a8b5182eeaf67eb7cb8b13594dd23b544 [ 33.861816] Tainted: [W]=WARN [ 33.861818] Hardware name: Valve Galileo/Galileo, BIOS F7G0107 12/01/2023 [ 33.861822] Call Trace: [ 33.861826] [ 33.861829] dump_stack_lvl+0x66/0x90 [ 33.861838] print_report+0xce/0x620 [ 33.861853] kasan_report+0xda/0x110 [ 33.862794] kasan_check_range+0xfd/0x1a0 [ 33.862799] __asan_memset+0x23/0x40 [ 33.862803] smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.863306] vangogh_get_gpu_metrics_v2_4+0x123/0xad0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.864257] vangogh_common_get_gpu_metrics+0xb0c/0xbc0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.865682] amdgpu_dpm_get_gpu_metrics+0xcc/0x110 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.866160] amdgpu_get_gpu_metrics+0x154/0x2d0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.867135] dev_attr_show+0x43/0xc0 [ 33.867147] sysfs_kf_seq_show+0x1f1/0x3b0 [ 33.867155] seq_read_iter+0x3f8/0x1140 [ 33.867173] vfs_read+0x76c/0xc50 [ 33.867198] ksys_read+0xfb/0x1d0 [ 33.867214] do_syscall_64+0x90/0x160 ... [ 33.867353] Allocated by task 378 on cpu 7 at 22.794876s: [ 33.867358] kasan_save_stack+0x33/0x50 [ 33.867364] kasan_save_track+0x17/0x60 [ 33.867367] __kasan_kmalloc+0x87/0x90 [ 33.867371] vangogh_init_smc_tables+0x3f9/0x840 [amdgpu] [ 33.867835] smu_sw_init+0xa32/0x1850 [amdgpu] [ 33.868299] amdgpu_device_init+0x467b/0x8d90 [amdgpu] [ 33.868733] amdgpu_driver_load_kms+0x19/0xf0 [amdgpu] [ 33.869167] amdgpu_pci_probe+0x2d6/0xcd0 [amdgpu] [ 33.869608] local_pci_probe+0xda/0x180 [ 33.869614] pci_device_probe+0x43f/0x6b0 Empirically we can confirm that the former allocates 152 bytes for the table, while the latter memsets the 168 large block. Root cause appears that when GPU metrics tables for v2_4 parts were added it was not considered to enlarge the table to fit. The fix in this patch is rather \"brute force\" and perhaps later should be done in a smarter way, by extracting and consolidating the part version to size logic to a common helper, instead of brute forcing the largest possible allocation. Nevertheless, for now this works and fixes the out of bounds write. v2: * Drop impossible v3_0 case. (Mario) (cherry picked from commit 0880f58f9609f0200483a49429af0f050d281703)", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50222", "url": "https://ubuntu.com/security/CVE-2024-50222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iov_iter: fix copy_page_from_iter_atomic() if KMAP_LOCAL_FORCE_MAP generic/077 on x86_32 CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP=y with highmem, on huge=always tmpfs, issues a warning and then hangs (interruptibly): WARNING: CPU: 5 PID: 3517 at mm/highmem.c:622 kunmap_local_indexed+0x62/0xc9 CPU: 5 UID: 0 PID: 3517 Comm: cp Not tainted 6.12.0-rc4 #2 ... copy_page_from_iter_atomic+0xa6/0x5ec generic_perform_write+0xf6/0x1b4 shmem_file_write_iter+0x54/0x67 Fix copy_page_from_iter_atomic() by limiting it in that case (include/linux/skbuff.h skb_frag_must_loop() does similar). But going forward, perhaps CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP is too surprising, has outlived its usefulness, and should just be removed?", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50223", "url": "https://ubuntu.com/security/CVE-2024-50223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/numa: Fix the potential null pointer dereference in task_numa_work() When running stress-ng-vm-segv test, we found a null pointer dereference error in task_numa_work(). Here is the backtrace: [323676.066985] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ...... [323676.067108] CPU: 35 PID: 2694524 Comm: stress-ng-vm-se ...... [323676.067113] pstate: 23401009 (nzCv daif +PAN -UAO +TCO +DIT +SSBS BTYPE=--) [323676.067115] pc : vma_migratable+0x1c/0xd0 [323676.067122] lr : task_numa_work+0x1ec/0x4e0 [323676.067127] sp : ffff8000ada73d20 [323676.067128] x29: ffff8000ada73d20 x28: 0000000000000000 x27: 000000003e89f010 [323676.067130] x26: 0000000000080000 x25: ffff800081b5c0d8 x24: ffff800081b27000 [323676.067133] x23: 0000000000010000 x22: 0000000104d18cc0 x21: ffff0009f7158000 [323676.067135] x20: 0000000000000000 x19: 0000000000000000 x18: ffff8000ada73db8 [323676.067138] x17: 0001400000000000 x16: ffff800080df40b0 x15: 0000000000000035 [323676.067140] x14: ffff8000ada73cc8 x13: 1fffe0017cc72001 x12: ffff8000ada73cc8 [323676.067142] x11: ffff80008001160c x10: ffff000be639000c x9 : ffff8000800f4ba4 [323676.067145] x8 : ffff000810375000 x7 : ffff8000ada73974 x6 : 0000000000000001 [323676.067147] x5 : 0068000b33e26707 x4 : 0000000000000001 x3 : ffff0009f7158000 [323676.067149] x2 : 0000000000000041 x1 : 0000000000004400 x0 : 0000000000000000 [323676.067152] Call trace: [323676.067153] vma_migratable+0x1c/0xd0 [323676.067155] task_numa_work+0x1ec/0x4e0 [323676.067157] task_work_run+0x78/0xd8 [323676.067161] do_notify_resume+0x1ec/0x290 [323676.067163] el0_svc+0x150/0x160 [323676.067167] el0t_64_sync_handler+0xf8/0x128 [323676.067170] el0t_64_sync+0x17c/0x180 [323676.067173] Code: d2888001 910003fd f9000bf3 aa0003f3 (f9401000) [323676.067177] SMP: stopping secondary CPUs [323676.070184] Starting crashdump kernel... stress-ng-vm-segv in stress-ng is used to stress test the SIGSEGV error handling function of the system, which tries to cause a SIGSEGV error on return from unmapping the whole address space of the child process. Normally this program will not cause kernel crashes. But before the munmap system call returns to user mode, a potential task_numa_work() for numa balancing could be added and executed. In this scenario, since the child process has no vma after munmap, the vma_next() in task_numa_work() will return a null pointer even if the vma iterator restarts from 0. Recheck the vma pointer before dereferencing it in task_numa_work().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53053", "url": "https://ubuntu.com/security/CVE-2024-53053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Fix another deadlock during RTC update If ufshcd_rtc_work calls ufshcd_rpm_put_sync() and the pm's usage_count is 0, we will enter the runtime suspend callback. However, the runtime suspend callback will wait to flush ufshcd_rtc_work, causing a deadlock. Replace ufshcd_rpm_put_sync() with ufshcd_rpm_put() to avoid the deadlock.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53075", "url": "https://ubuntu.com/security/CVE-2024-53075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv: Prevent a bad reference count on CPU nodes When populating cache leaves we previously fetched the CPU device node at the very beginning. But when ACPI is enabled we go through a specific branch which returns early and does not call 'of_node_put' for the node that was acquired. Since we are not using a CPU device node for the ACPI code anyways, we can simply move the initialization of it just passed the ACPI block, and we are guaranteed to have an 'of_node_put' call for the acquired node. This prevents a bad reference count of the CPU device node. Moreover, the previous function did not check for errors when acquiring the device node, so a return -ENOENT has been added for that case.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50224", "url": "https://ubuntu.com/security/CVE-2024-50224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: spi-fsl-dspi: Fix crash when not using GPIO chip select Add check for the return value of spi_get_csgpiod() to avoid passing a NULL pointer to gpiod_direction_output(), preventing a crash when GPIO chip select is not used. Fix below crash: [ 4.251960] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 4.260762] Mem abort info: [ 4.263556] ESR = 0x0000000096000004 [ 4.267308] EC = 0x25: DABT (current EL), IL = 32 bits [ 4.272624] SET = 0, FnV = 0 [ 4.275681] EA = 0, S1PTW = 0 [ 4.278822] FSC = 0x04: level 0 translation fault [ 4.283704] Data abort info: [ 4.286583] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 4.292074] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 4.297130] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 4.302445] [0000000000000000] user address but active_mm is swapper [ 4.308805] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 4.315072] Modules linked in: [ 4.318124] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc4-next-20241023-00008-ga20ec42c5fc1 #359 [ 4.328130] Hardware name: LS1046A QDS Board (DT) [ 4.332832] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 4.339794] pc : gpiod_direction_output+0x34/0x5c [ 4.344505] lr : gpiod_direction_output+0x18/0x5c [ 4.349208] sp : ffff80008003b8f0 [ 4.352517] x29: ffff80008003b8f0 x28: 0000000000000000 x27: ffffc96bcc7e9068 [ 4.359659] x26: ffffc96bcc6e00b0 x25: ffffc96bcc598398 x24: ffff447400132810 [ 4.366800] x23: 0000000000000000 x22: 0000000011e1a300 x21: 0000000000020002 [ 4.373940] x20: 0000000000000000 x19: 0000000000000000 x18: ffffffffffffffff [ 4.381081] x17: ffff44740016e600 x16: 0000000500000003 x15: 0000000000000007 [ 4.388221] x14: 0000000000989680 x13: 0000000000020000 x12: 000000000000001e [ 4.395362] x11: 0044b82fa09b5a53 x10: 0000000000000019 x9 : 0000000000000008 [ 4.402502] x8 : 0000000000000002 x7 : 0000000000000007 x6 : 0000000000000000 [ 4.409641] x5 : 0000000000000200 x4 : 0000000002000000 x3 : 0000000000000000 [ 4.416781] x2 : 0000000000022202 x1 : 0000000000000000 x0 : 0000000000000000 [ 4.423921] Call trace: [ 4.426362] gpiod_direction_output+0x34/0x5c (P) [ 4.431067] gpiod_direction_output+0x18/0x5c (L) [ 4.435771] dspi_setup+0x220/0x334", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50225", "url": "https://ubuntu.com/security/CVE-2024-50225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix error propagation of split bios The purpose of btrfs_bbio_propagate_error() shall be propagating an error of split bio to its original btrfs_bio, and tell the error to the upper layer. However, it's not working well on some cases. * Case 1. Immediate (or quick) end_bio with an error When btrfs sends btrfs_bio to mirrored devices, btrfs calls btrfs_bio_end_io() when all the mirroring bios are completed. If that btrfs_bio was split, it is from btrfs_clone_bioset and its end_io function is btrfs_orig_write_end_io. For this case, btrfs_bbio_propagate_error() accesses the orig_bbio's bio context to increase the error count. That works well in most cases. However, if the end_io is called enough fast, orig_bbio's (remaining part after split) bio context may not be properly set at that time. Since the bio context is set when the orig_bbio (the last btrfs_bio) is sent to devices, that might be too late for earlier split btrfs_bio's completion. That will result in NULL pointer dereference. That bug is easily reproducible by running btrfs/146 on zoned devices [1] and it shows the following trace. [1] You need raid-stripe-tree feature as it create \"-d raid0 -m raid1\" FS. BUG: kernel NULL pointer dereference, address: 0000000000000020 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 UID: 0 PID: 13 Comm: kworker/u32:1 Not tainted 6.11.0-rc7-BTRFS-ZNS+ #474 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Workqueue: writeback wb_workfn (flush-btrfs-5) RIP: 0010:btrfs_bio_end_io+0xae/0xc0 [btrfs] BTRFS error (device dm-0): bdev /dev/mapper/error-test errs: wr 2, rd 0, flush 0, corrupt 0, gen 0 RSP: 0018:ffffc9000006f248 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888005a7f080 RCX: ffffc9000006f1dc RDX: 0000000000000000 RSI: 000000000000000a RDI: ffff888005a7f080 RBP: ffff888011dfc540 R08: 0000000000000000 R09: 0000000000000001 R10: ffffffff82e508e0 R11: 0000000000000005 R12: ffff88800ddfbe58 R13: ffff888005a7f080 R14: ffff888005a7f158 R15: ffff888005a7f158 FS: 0000000000000000(0000) GS:ffff88803ea80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000020 CR3: 0000000002e22006 CR4: 0000000000370ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __die_body.cold+0x19/0x26 ? page_fault_oops+0x13e/0x2b0 ? _printk+0x58/0x73 ? do_user_addr_fault+0x5f/0x750 ? exc_page_fault+0x76/0x240 ? asm_exc_page_fault+0x22/0x30 ? btrfs_bio_end_io+0xae/0xc0 [btrfs] ? btrfs_log_dev_io_error+0x7f/0x90 [btrfs] btrfs_orig_write_end_io+0x51/0x90 [btrfs] dm_submit_bio+0x5c2/0xa50 [dm_mod] ? find_held_lock+0x2b/0x80 ? blk_try_enter_queue+0x90/0x1e0 __submit_bio+0xe0/0x130 ? ktime_get+0x10a/0x160 ? lockdep_hardirqs_on+0x74/0x100 submit_bio_noacct_nocheck+0x199/0x410 btrfs_submit_bio+0x7d/0x150 [btrfs] btrfs_submit_chunk+0x1a1/0x6d0 [btrfs] ? lockdep_hardirqs_on+0x74/0x100 ? __folio_start_writeback+0x10/0x2c0 btrfs_submit_bbio+0x1c/0x40 [btrfs] submit_one_bio+0x44/0x60 [btrfs] submit_extent_folio+0x13f/0x330 [btrfs] ? btrfs_set_range_writeback+0xa3/0xd0 [btrfs] extent_writepage_io+0x18b/0x360 [btrfs] extent_write_locked_range+0x17c/0x340 [btrfs] ? __pfx_end_bbio_data_write+0x10/0x10 [btrfs] run_delalloc_cow+0x71/0xd0 [btrfs] btrfs_run_delalloc_range+0x176/0x500 [btrfs] ? find_lock_delalloc_range+0x119/0x260 [btrfs] writepage_delalloc+0x2ab/0x480 [btrfs] extent_write_cache_pages+0x236/0x7d0 [btrfs] btrfs_writepages+0x72/0x130 [btrfs] do_writepages+0xd4/0x240 ? find_held_lock+0x2b/0x80 ? wbc_attach_and_unlock_inode+0x12c/0x290 ? wbc_attach_and_unlock_inode+0x12c/0x29 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53054", "url": "https://ubuntu.com/security/CVE-2024-53054", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50226", "url": "https://ubuntu.com/security/CVE-2024-50226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cxl/port: Fix use-after-free, permit out-of-order decoder shutdown In support of investigating an initialization failure report [1], cxl_test was updated to register mock memory-devices after the mock root-port/bus device had been registered. That led to cxl_test crashing with a use-after-free bug with the following signature: cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem0:decoder7.0 @ 0 next: cxl_switch_uport.0 nr_eps: 1 nr_targets: 1 cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem4:decoder14.0 @ 1 next: cxl_switch_uport.0 nr_eps: 2 nr_targets: 1 cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[0] = cxl_switch_dport.0 for mem0:decoder7.0 @ 0 1) cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[1] = cxl_switch_dport.4 for mem4:decoder14.0 @ 1 [..] cxld_unregister: cxl decoder14.0: cxl_region_decode_reset: cxl_region region3: mock_decoder_reset: cxl_port port3: decoder3.0 reset 2) mock_decoder_reset: cxl_port port3: decoder3.0: out of order reset, expected decoder3.1 cxl_endpoint_decoder_release: cxl decoder14.0: [..] cxld_unregister: cxl decoder7.0: 3) cxl_region_decode_reset: cxl_region region3: Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6bc3: 0000 [#1] PREEMPT SMP PTI [..] RIP: 0010:to_cxl_port+0x8/0x60 [cxl_core] [..] Call Trace: cxl_region_decode_reset+0x69/0x190 [cxl_core] cxl_region_detach+0xe8/0x210 [cxl_core] cxl_decoder_kill_region+0x27/0x40 [cxl_core] cxld_unregister+0x5d/0x60 [cxl_core] At 1) a region has been established with 2 endpoint decoders (7.0 and 14.0). Those endpoints share a common switch-decoder in the topology (3.0). At teardown, 2), decoder14.0 is the first to be removed and hits the \"out of order reset case\" in the switch decoder. The effect though is that region3 cleanup is aborted leaving it in-tact and referencing decoder14.0. At 3) the second attempt to teardown region3 trips over the stale decoder14.0 object which has long since been deleted. The fix here is to recognize that the CXL specification places no mandate on in-order shutdown of switch-decoders, the driver enforces in-order allocation, and hardware enforces in-order commit. So, rather than fail and leave objects dangling, always remove them. In support of making cxl_region_decode_reset() always succeed, cxl_region_invalidate_memregion() failures are turned into warnings. Crashing the kernel is ok there since system integrity is at risk if caches cannot be managed around physical address mutation events like CXL region destruction. A new device_for_each_child_reverse_from() is added to cleanup port->commit_end after all dependent decoders have been disabled. In other words if decoders are allocated 0->1->2 and disabled 1->2->0 then port->commit_end only decrements from 2 after 2 has been disabled, and it decrements all the way to zero since 1 was disabled previously.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50227", "url": "https://ubuntu.com/security/CVE-2024-50227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Fix KASAN reported stack out-of-bounds read in tb_retimer_scan() KASAN reported following issue: BUG: KASAN: stack-out-of-bounds in tb_retimer_scan+0xffe/0x1550 [thunderbolt] Read of size 4 at addr ffff88810111fc1c by task kworker/u56:0/11 CPU: 0 UID: 0 PID: 11 Comm: kworker/u56:0 Tainted: G U 6.11.0+ #1387 Tainted: [U]=USER Workqueue: thunderbolt0 tb_handle_hotplug [thunderbolt] Call Trace: dump_stack_lvl+0x6c/0x90 print_report+0xd1/0x630 kasan_report+0xdb/0x110 __asan_report_load4_noabort+0x14/0x20 tb_retimer_scan+0xffe/0x1550 [thunderbolt] tb_scan_port+0xa6f/0x2060 [thunderbolt] tb_handle_hotplug+0x17b1/0x3080 [thunderbolt] process_one_work+0x626/0x1100 worker_thread+0x6c8/0xfa0 kthread+0x2c8/0x3a0 ret_from_fork+0x3a/0x80 ret_from_fork_asm+0x1a/0x30 This happens because the loop variable still gets incremented by one so max becomes 3 instead of 2, and this makes the second loop read past the the array declared on the stack. Fix this by assigning to max directly in the loop body.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50228", "url": "https://ubuntu.com/security/CVE-2024-50228", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50229", "url": "https://ubuntu.com/security/CVE-2024-50229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential deadlock with newly created symlinks Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers memory reclamation involving the filesystem layer, which can result in circular lock dependencies among the reader/writer semaphore nilfs->ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the fs_reclaim pseudo lock. This is because after commit 21fc61c73c39 (\"don't put symlink bodies in pagecache into highmem\"), the gfp flags of the page cache for symbolic links are overwritten to GFP_KERNEL via inode_nohighmem(). This is not a problem for symlinks read from the backing device, because the __GFP_FS flag is dropped after inode_nohighmem() is called. However, when a new symlink is created with nilfs_symlink(), the gfp flags remain overwritten to GFP_KERNEL. Then, memory allocation called from page_symlink() etc. triggers memory reclamation including the FS layer, which may call nilfs_evict_inode() or nilfs_dirty_inode(). And these can cause a deadlock if they are called while nilfs->ns_segctor_sem is held: Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags of newly created symlinks in the same way that nilfs_new_inode() and __nilfs_read_inode() do, as a workaround until we adopt nofs allocation scope consistently or improve the locking constraints.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50230", "url": "https://ubuntu.com/security/CVE-2024-50230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug due to missing clearing of checked flag Syzbot reported that in directory operations after nilfs2 detects filesystem corruption and degrades to read-only, __block_write_begin_int(), which is called to prepare block writes, may fail the BUG_ON check for accesses exceeding the folio/page size, triggering a kernel bug. This was found to be because the \"checked\" flag of a page/folio was not cleared when it was discarded by nilfs2's own routine, which causes the sanity check of directory entries to be skipped when the directory page/folio is reloaded. So, fix that. This was necessary when the use of nilfs2's own page discard routine was applied to more than just metadata files.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50231", "url": "https://ubuntu.com/security/CVE-2024-50231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gts-helper: Fix memory leaks in iio_gts_build_avail_scale_table() modprobe iio-test-gts and rmmod it, then the following memory leak occurs: \tunreferenced object 0xffffff80c810be00 (size 64): \t comm \"kunit_try_catch\", pid 1654, jiffies 4294913981 \t hex dump (first 32 bytes): \t 02 00 00 00 08 00 00 00 20 00 00 00 40 00 00 00 ........ ...@... \t 80 00 00 00 00 02 00 00 00 04 00 00 00 08 00 00 ................ \t backtrace (crc a63d875e): \t [<0000000028c1b3c2>] kmemleak_alloc+0x34/0x40 \t [<000000001d6ecc87>] __kmalloc_noprof+0x2bc/0x3c0 \t [<00000000393795c1>] devm_iio_init_iio_gts+0x4b4/0x16f4 \t [<0000000071bb4b09>] 0xffffffdf052a62e0 \t [<000000000315bc18>] 0xffffffdf052a6488 \t [<00000000f9dc55b5>] kunit_try_run_case+0x13c/0x3ac \t [<00000000175a3fd4>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000f505065d>] kthread+0x2e8/0x374 \t [<00000000bbfb0e5d>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cbfe9e70 (size 16): \t comm \"kunit_try_catch\", pid 1658, jiffies 4294914015 \t hex dump (first 16 bytes): \t 10 00 00 00 40 00 00 00 80 00 00 00 00 00 00 00 ....@........... \t backtrace (crc 857f0cb4): \t [<0000000028c1b3c2>] kmemleak_alloc+0x34/0x40 \t [<000000001d6ecc87>] __kmalloc_noprof+0x2bc/0x3c0 \t [<00000000393795c1>] devm_iio_init_iio_gts+0x4b4/0x16f4 \t [<0000000071bb4b09>] 0xffffffdf052a62e0 \t [<000000007d089d45>] 0xffffffdf052a6864 \t [<00000000f9dc55b5>] kunit_try_run_case+0x13c/0x3ac \t [<00000000175a3fd4>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000f505065d>] kthread+0x2e8/0x374 \t [<00000000bbfb0e5d>] ret_from_fork+0x10/0x20 \t...... It includes 5*5 times \"size 64\" memory leaks, which correspond to 5 times test_init_iio_gain_scale() calls with gts_test_gains size 10 (10*size(int)) and gts_test_itimes size 5. It also includes 5*1 times \"size 16\" memory leak, which correspond to one time __test_init_iio_gain_scale() call with gts_test_gains_gain_low size 3 (3*size(int)) and gts_test_itimes size 5. The reason is that the per_time_gains[i] is not freed which is allocated in the \"gts->num_itime\" for loop in iio_gts_build_avail_scale_table().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53076", "url": "https://ubuntu.com/security/CVE-2024-53076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gts-helper: Fix memory leaks for the error path of iio_gts_build_avail_scale_table() If per_time_scales[i] or per_time_gains[i] kcalloc fails in the for loop of iio_gts_build_avail_scale_table(), the err_free_out will fail to call kfree() each time when i is reduced to 0, so all the per_time_scales[0] and per_time_gains[0] will not be freed, which will cause memory leaks. Fix it by checking if i >= 0.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50232", "url": "https://ubuntu.com/security/CVE-2024-50232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr() In the ad7124_write_raw() function, parameter val can potentially be zero. This may lead to a division by zero when DIV_ROUND_CLOSEST() is called within ad7124_set_channel_odr(). The ad7124_write_raw() function is invoked through the sequence: iio_write_channel_raw() -> iio_write_channel_attribute() -> iio_channel_write(), with no checks in place to ensure val is non-zero.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50233", "url": "https://ubuntu.com/security/CVE-2024-50233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: iio: frequency: ad9832: fix division by zero in ad9832_calc_freqreg() In the ad9832_write_frequency() function, clk_get_rate() might return 0. This can lead to a division by zero when calling ad9832_calc_freqreg(). The check if (fout > (clk_get_rate(st->mclk) / 2)) does not protect against the case when fout is 0. The ad9832_write_frequency() function is called from ad9832_write(), and fout is derived from a text buffer, which can contain any value.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53055", "url": "https://ubuntu.com/security/CVE-2024-53055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix 6 GHz scan construction If more than 255 colocated APs exist for the set of all APs found during 2.4/5 GHz scanning, then the 6 GHz scan construction will loop forever since the loop variable has type u8, which can never reach the number found when that's bigger than 255, and is stored in a u32 variable. Also move it into the loops to have a smaller scope. Using a u32 there is fine, we limit the number of APs in the scan list and each has a limit on the number of RNR entries due to the frame size. With a limit of 1000 scan results, a frame size upper bound of 4096 (really it's more like ~2300) and a TBTT entry size of at least 11, we get an upper bound for the number of ~372k, well in the bounds of a u32.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50234", "url": "https://ubuntu.com/security/CVE-2024-50234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlegacy: Clear stale interrupts before resuming device iwl4965 fails upon resume from hibernation on my laptop. The reason seems to be a stale interrupt which isn't being cleared out before interrupts are enabled. We end up with a race beween the resume trying to bring things back up, and the restart work (queued form the interrupt handler) trying to bring things down. Eventually the whole thing blows up. Fix the problem by clearing out any stale interrupts before interrupts get enabled during resume. Here's a debug log of the indicent: [ 12.042589] ieee80211 phy0: il_isr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000 [ 12.042625] ieee80211 phy0: il4965_irq_tasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000 [ 12.042651] iwl4965 0000:10:00.0: RF_KILL bit toggled to enable radio. [ 12.042653] iwl4965 0000:10:00.0: On demand firmware reload [ 12.042690] ieee80211 phy0: il4965_irq_tasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282 [ 12.052207] ieee80211 phy0: il4965_mac_start enter [ 12.052212] ieee80211 phy0: il_prep_station Add STA to driver ID 31: ff:ff:ff:ff:ff:ff [ 12.052244] ieee80211 phy0: il4965_set_hw_ready hardware ready [ 12.052324] ieee80211 phy0: il_apm_init Init card's basic functions [ 12.052348] ieee80211 phy0: il_apm_init L1 Enabled; Disabling L0S [ 12.055727] ieee80211 phy0: il4965_load_bsm Begin load bsm [ 12.056140] ieee80211 phy0: il4965_verify_bsm Begin verify bsm [ 12.058642] ieee80211 phy0: il4965_verify_bsm BSM bootstrap uCode image OK [ 12.058721] ieee80211 phy0: il4965_load_bsm BSM write complete, poll 1 iterations [ 12.058734] ieee80211 phy0: __il4965_up iwl4965 is coming up [ 12.058737] ieee80211 phy0: il4965_mac_start Start UP work done. [ 12.058757] ieee80211 phy0: __il4965_down iwl4965 is going down [ 12.058761] ieee80211 phy0: il_scan_cancel_timeout Scan cancel timeout [ 12.058762] ieee80211 phy0: il_do_scan_abort Not performing scan to abort [ 12.058765] ieee80211 phy0: il_clear_ucode_stations Clearing ucode stations in driver [ 12.058767] ieee80211 phy0: il_clear_ucode_stations No active stations found to be cleared [ 12.058819] ieee80211 phy0: _il_apm_stop Stop card, put in low power state [ 12.058827] ieee80211 phy0: _il_apm_stop_master stop master [ 12.058864] ieee80211 phy0: il4965_clear_free_frames 0 frames on pre-allocated heap on clear. [ 12.058869] ieee80211 phy0: Hardware restart was requested [ 16.132299] iwl4965 0000:10:00.0: START_ALIVE timeout after 4000ms. [ 16.132303] ------------[ cut here ]------------ [ 16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue. [ 16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132390] Modules linked in: ctr ccm sch_fq_codel xt_tcpudp xt_multiport xt_state iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables binfmt_misc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdh_generic ecc iTCO_wdt i2c_dev iwl4965 iwlegacy coretemp snd_hda_codec_analog pcspkr psmouse mac80211 snd_hda_codec_generic libarc4 sdhci_pci cqhci sha256_generic sdhci libsha256 firewire_ohci snd_hda_intel snd_intel_dspcfg mmc_core snd_hda_codec snd_hwdep firewire_core led_class iosf_mbi snd_hda_core uhci_hcd lpc_ich crc_itu_t cfg80211 ehci_pci ehci_hcd snd_pcm usbcore mfd_core rfkill snd_timer snd usb_common soundcore video parport_pc parport intel_agp wmi intel_gtt backlight e1000e agpgart evdev [ 16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143 [ 16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010 [ 16.132463] Workqueue: async async_run_entry_fn [ 16.132469] RIP: 0010:ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132501] Code: da 02 00 0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50235", "url": "https://ubuntu.com/security/CVE-2024-50235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: clear wdev->cqm_config pointer on free When we free wdev->cqm_config when unregistering, we also need to clear out the pointer since the same wdev/netdev may get re-registered in another network namespace, then destroyed later, running this code again, which results in a double-free.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50236", "url": "https://ubuntu.com/security/CVE-2024-50236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: Fix memory leak in management tx In the current logic, memory is allocated for storing the MSDU context during management packet TX but this memory is not being freed during management TX completion. Similar leaks are seen in the management TX cleanup logic. Kmemleak reports this problem as below, unreferenced object 0xffffff80b64ed250 (size 16): comm \"kworker/u16:7\", pid 148, jiffies 4294687130 (age 714.199s) hex dump (first 16 bytes): 00 2b d8 d8 80 ff ff ff c4 74 e9 fd 07 00 00 00 .+.......t...... backtrace: [] __kmem_cache_alloc_node+0x1e4/0x2d8 [] kmalloc_trace+0x48/0x110 [] ath10k_wmi_tlv_op_gen_mgmt_tx_send+0xd4/0x1d8 [ath10k_core] [] ath10k_mgmt_over_wmi_tx_work+0x134/0x298 [ath10k_core] [] process_scheduled_works+0x1ac/0x400 [] worker_thread+0x208/0x328 [] kthread+0x100/0x1c0 [] ret_from_fork+0x10/0x20 Free the memory during completion and cleanup to fix the leak. Protect the mgmt_pending_tx idr_remove() operation in ath10k_wmi_tlv_op_cleanup_mgmt_tx_send() using ar->data_lock similar to other instances. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50237", "url": "https://ubuntu.com/security/CVE-2024-50237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower Avoid potentially crashing in the driver because of uninitialized private data", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50238", "url": "https://ubuntu.com/security/CVE-2024-50238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usbc: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data from the qcom-qmp-usb driver, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. This bug was later reproduced when the driver was copied to create the qmp-usbc driver. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with these drivers.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50239", "url": "https://ubuntu.com/security/CVE-2024-50239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usb-legacy: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data from the qcom-qmp-usb driver, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. This bug was later reproduced when the driver was copied to create the qmp-usb-legacy driver. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with these drivers.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50240", "url": "https://ubuntu.com/security/CVE-2024-50240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usb: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with this driver.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53077", "url": "https://ubuntu.com/security/CVE-2024-53077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpcrdma: Always release the rpcrdma_device's xa_array Dai pointed out that the xa_init_flags() in rpcrdma_add_one() needs to have a matching xa_destroy() in rpcrdma_remove_one() to release underlying memory that the xarray might have accrued during operation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50242", "url": "https://ubuntu.com/security/CVE-2024-50242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ntfs_file_release", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50243", "url": "https://ubuntu.com/security/CVE-2024-50243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix general protection fault in run_is_mapped_full Fixed deleating of a non-resident attribute in ntfs_create_inode() rollback.", "cve_priority": "low", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50244", "url": "https://ubuntu.com/security/CVE-2024-50244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ni_clear() Checking of NTFS_FLAGS_LOG_REPLAYING added to prevent access to uninitialized bitmap during replay process.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50245", "url": "https://ubuntu.com/security/CVE-2024-50245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix possible deadlock in mi_read Mutex lock with another subclass used in ni_lock_dir().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50246", "url": "https://ubuntu.com/security/CVE-2024-50246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Add rough attr alloc_size check", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50247", "url": "https://ubuntu.com/security/CVE-2024-50247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Check if more than chunk-size bytes are written A incorrectly formatted chunk may decompress into more than LZNT_CHUNK_SIZE bytes and a index out of bounds will occur in s_max_off.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50248", "url": "https://ubuntu.com/security/CVE-2024-50248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Add bounds checking to mi_enum_attr() Added bounds checking to make sure that every attr don't stray beyond valid memory region.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53078", "url": "https://ubuntu.com/security/CVE-2024-53078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Fix NULL vs IS_ERR() check in probe() The iommu_paging_domain_alloc() function doesn't return NULL pointers, it returns error pointers. Update the check to match.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53056", "url": "https://ubuntu.com/security/CVE-2024-53056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Fix potential NULL dereference in mtk_crtc_destroy() In mtk_crtc_create(), if the call to mbox_request_channel() fails then we set the \"mtk_crtc->cmdq_client.chan\" pointer to NULL. In that situation, we do not call cmdq_pkt_create(). During the cleanup, we need to check if the \"mtk_crtc->cmdq_client.chan\" is NULL first before calling cmdq_pkt_destroy(). Calling cmdq_pkt_destroy() is unnecessary if we didn't call cmdq_pkt_create() and it will result in a NULL pointer dereference.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50249", "url": "https://ubuntu.com/security/CVE-2024-50249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Make rmw_lock a raw_spin_lock The following BUG was triggered: ============================= [ BUG: Invalid wait context ] 6.12.0-rc2-XXX #406 Not tainted ----------------------------- kworker/1:1/62 is trying to lock: ffffff8801593030 (&cpc_ptr->rmw_lock){+.+.}-{3:3}, at: cpc_write+0xcc/0x370 other info that might help us debug this: context-{5:5} 2 locks held by kworker/1:1/62: #0: ffffff897ef5ec98 (&rq->__lock){-.-.}-{2:2}, at: raw_spin_rq_lock_nested+0x2c/0x50 #1: ffffff880154e238 (&sg_policy->update_lock){....}-{2:2}, at: sugov_update_shared+0x3c/0x280 stack backtrace: CPU: 1 UID: 0 PID: 62 Comm: kworker/1:1 Not tainted 6.12.0-rc2-g9654bd3e8806 #406 Workqueue: 0x0 (events) Call trace: dump_backtrace+0xa4/0x130 show_stack+0x20/0x38 dump_stack_lvl+0x90/0xd0 dump_stack+0x18/0x28 __lock_acquire+0x480/0x1ad8 lock_acquire+0x114/0x310 _raw_spin_lock+0x50/0x70 cpc_write+0xcc/0x370 cppc_set_perf+0xa0/0x3a8 cppc_cpufreq_fast_switch+0x40/0xc0 cpufreq_driver_fast_switch+0x4c/0x218 sugov_update_shared+0x234/0x280 update_load_avg+0x6ec/0x7b8 dequeue_entities+0x108/0x830 dequeue_task_fair+0x58/0x408 __schedule+0x4f0/0x1070 schedule+0x54/0x130 worker_thread+0xc0/0x2e8 kthread+0x130/0x148 ret_from_fork+0x10/0x20 sugov_update_shared() locks a raw_spinlock while cpc_write() locks a spinlock. To have a correct wait-type order, update rmw_lock to a raw spinlock and ensure that interrupts will be disabled on the CPU holding it. [ rjw: Changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50250", "url": "https://ubuntu.com/security/CVE-2024-50250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fsdax: dax_unshare_iter needs to copy entire blocks The code that copies data from srcmap to iomap in dax_unshare_iter is very very broken, which bfoster's recent fsx changes have exposed. If the pos and len passed to dax_file_unshare are not aligned to an fsblock boundary, the iter pos and length in the _iter function will reflect this unalignment. dax_iomap_direct_access always returns a pointer to the start of the kmapped fsdax page, even if its pos argument is in the middle of that page. This is catastrophic for data integrity when iter->pos is not aligned to a page, because daddr/saddr do not point to the same byte in the file as iter->pos. Hence we corrupt user data by copying it to the wrong place. If iter->pos + iomap_length() in the _iter function not aligned to a page, then we fail to copy a full block, and only partially populate the destination block. This is catastrophic for data confidentiality because we expose stale pmem contents. Fix both of these issues by aligning copy_pos/copy_len to a page boundary (remember, this is fsdax so 1 fsblock == 1 base page) so that we always copy full blocks. We're not done yet -- there's no call to invalidate_inode_pages2_range, so programs that have the file range mmap'd will continue accessing the old memory mapping after the file metadata updates have completed. Be careful with the return value -- if the unshare succeeds, we still need to return the number of bytes that the iomap iter thinks we're operating on.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50251", "url": "https://ubuntu.com/security/CVE-2024-50251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_payload: sanitize offset and length before calling skb_checksum() If access to offset + length is larger than the skbuff length, then skb_checksum() triggers BUG_ON(). skb_checksum() internally subtracts the length parameter while iterating over skbuff, BUG_ON(len) at the end of it checks that the expected length to be included in the checksum calculation is fully consumed.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50252", "url": "https://ubuntu.com/security/CVE-2024-50252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_ipip: Fix memory leak when changing remote IPv6 address The device stores IPv6 addresses that are used for encapsulation in linear memory that is managed by the driver. Changing the remote address of an ip6gre net device never worked properly, but since cited commit the following reproducer [1] would result in a warning [2] and a memory leak [3]. The problem is that the new remote address is never added by the driver to its hash table (and therefore the device) and the old address is never removed from it. Fix by programming the new address when the configuration of the ip6gre net device changes and removing the old one. If the address did not change, then the above would result in increasing the reference count of the address and then decreasing it. [1] # ip link add name bla up type ip6gre local 2001:db8:1::1 remote 2001:db8:2::1 tos inherit ttl inherit # ip link set dev bla type ip6gre remote 2001:db8:3::1 # ip link del dev bla # devlink dev reload pci/0000:01:00.0 [2] WARNING: CPU: 0 PID: 1682 at drivers/net/ethernet/mellanox/mlxsw/spectrum.c:3002 mlxsw_sp_ipv6_addr_put+0x140/0x1d0 Modules linked in: CPU: 0 UID: 0 PID: 1682 Comm: ip Not tainted 6.12.0-rc3-custom-g86b5b55bc835 #151 Hardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023 RIP: 0010:mlxsw_sp_ipv6_addr_put+0x140/0x1d0 [...] Call Trace: mlxsw_sp_router_netdevice_event+0x55f/0x1240 notifier_call_chain+0x5a/0xd0 call_netdevice_notifiers_info+0x39/0x90 unregister_netdevice_many_notify+0x63e/0x9d0 rtnl_dellink+0x16b/0x3a0 rtnetlink_rcv_msg+0x142/0x3f0 netlink_rcv_skb+0x50/0x100 netlink_unicast+0x242/0x390 netlink_sendmsg+0x1de/0x420 ____sys_sendmsg+0x2bd/0x320 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xd0 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f [3] unreferenced object 0xffff898081f597a0 (size 32): comm \"ip\", pid 1626, jiffies 4294719324 hex dump (first 32 bytes): 20 01 0d b8 00 02 00 00 00 00 00 00 00 00 00 01 ............... 21 49 61 83 80 89 ff ff 00 00 00 00 01 00 00 00 !Ia............. backtrace (crc fd9be911): [<00000000df89c55d>] __kmalloc_cache_noprof+0x1da/0x260 [<00000000ff2a1ddb>] mlxsw_sp_ipv6_addr_kvdl_index_get+0x281/0x340 [<000000009ddd445d>] mlxsw_sp_router_netdevice_event+0x47b/0x1240 [<00000000743e7757>] notifier_call_chain+0x5a/0xd0 [<000000007c7b9e13>] call_netdevice_notifiers_info+0x39/0x90 [<000000002509645d>] register_netdevice+0x5f7/0x7a0 [<00000000c2e7d2a9>] ip6gre_newlink_common.isra.0+0x65/0x130 [<0000000087cd6d8d>] ip6gre_newlink+0x72/0x120 [<000000004df7c7cc>] rtnl_newlink+0x471/0xa20 [<0000000057ed632a>] rtnetlink_rcv_msg+0x142/0x3f0 [<0000000032e0d5b5>] netlink_rcv_skb+0x50/0x100 [<00000000908bca63>] netlink_unicast+0x242/0x390 [<00000000cdbe1c87>] netlink_sendmsg+0x1de/0x420 [<0000000011db153e>] ____sys_sendmsg+0x2bd/0x320 [<000000003b6d53eb>] ___sys_sendmsg+0x9a/0xe0 [<00000000cae27c62>] __sys_sendmsg+0x7a/0xd0", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50253", "url": "https://ubuntu.com/security/CVE-2024-50253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check the validity of nr_words in bpf_iter_bits_new() Check the validity of nr_words in bpf_iter_bits_new(). Without this check, when multiplication overflow occurs for nr_bits (e.g., when nr_words = 0x0400-0001, nr_bits becomes 64), stack corruption may occur due to bpf_probe_read_kernel_common(..., nr_bytes = 0x2000-0008). Fix it by limiting the maximum value of nr_words to 511. The value is derived from the current implementation of BPF memory allocator. To ensure compatibility if the BPF memory allocator's size limitation changes in the future, use the helper bpf_mem_alloc_check_size() to check whether nr_bytes is too larger. And return -E2BIG instead of -ENOMEM for oversized nr_bytes.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50254", "url": "https://ubuntu.com/security/CVE-2024-50254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free dynamically allocated bits in bpf_iter_bits_destroy() bpf_iter_bits_destroy() uses \"kit->nr_bits <= 64\" to check whether the bits are dynamically allocated. However, the check is incorrect and may cause a kmemleak as shown below: unreferenced object 0xffff88812628c8c0 (size 32): comm \"swapper/0\", pid 1, jiffies 4294727320 hex dump (first 32 bytes): \tb0 c1 55 f5 81 88 ff ff f0 f0 f0 f0 f0 f0 f0 f0 ..U........... \tf0 f0 f0 f0 f0 f0 f0 f0 00 00 00 00 00 00 00 00 .............. backtrace (crc 781e32cc): \t[<00000000c452b4ab>] kmemleak_alloc+0x4b/0x80 \t[<0000000004e09f80>] __kmalloc_node_noprof+0x480/0x5c0 \t[<00000000597124d6>] __alloc.isra.0+0x89/0xb0 \t[<000000004ebfffcd>] alloc_bulk+0x2af/0x720 \t[<00000000d9c10145>] prefill_mem_cache+0x7f/0xb0 \t[<00000000ff9738ff>] bpf_mem_alloc_init+0x3e2/0x610 \t[<000000008b616eac>] bpf_global_ma_init+0x19/0x30 \t[<00000000fc473efc>] do_one_initcall+0xd3/0x3c0 \t[<00000000ec81498c>] kernel_init_freeable+0x66a/0x940 \t[<00000000b119f72f>] kernel_init+0x20/0x160 \t[<00000000f11ac9a7>] ret_from_fork+0x3c/0x70 \t[<0000000004671da4>] ret_from_fork_asm+0x1a/0x30 That is because nr_bits will be set as zero in bpf_iter_bits_next() after all bits have been iterated. Fix the issue by setting kit->bit to kit->nr_bits instead of setting kit->nr_bits to zero when the iteration completes in bpf_iter_bits_next(). In addition, use \"!nr_bits || bits >= nr_bits\" to check whether the iteration is complete and still use \"nr_bits > 64\" to indicate whether bits are dynamically allocated. The \"!nr_bits\" check is necessary because bpf_iter_bits_new() may fail before setting kit->nr_bits, and this condition will stop the iteration early instead of accessing the zeroed or freed kit->bits. Considering the initial value of kit->bits is -1 and the type of kit->nr_bits is unsigned int, change the type of kit->nr_bits to int. The potential overflow problem will be handled in the following patch.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50255", "url": "https://ubuntu.com/security/CVE-2024-50255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci: fix null-ptr-deref in hci_read_supported_codecs Fix __hci_cmd_sync_sk() to return not NULL for unknown opcodes. __hci_cmd_sync_sk() returns NULL if a command returns a status event. However, it also returns NULL where an opcode doesn't exist in the hci_cc table because hci_cmd_complete_evt() assumes status = skb->data[0] for unknown opcodes. This leads to null-ptr-deref in cmd_sync for HCI_OP_READ_LOCAL_CODECS as there is no hci_cc for HCI_OP_READ_LOCAL_CODECS, which always assumes status = skb->data[0]. KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077] CPU: 1 PID: 2000 Comm: kworker/u9:5 Not tainted 6.9.0-ga6bcb805883c-dirty #10 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: hci7 hci_power_on RIP: 0010:hci_read_supported_codecs+0xb9/0x870 net/bluetooth/hci_codec.c:138 Code: 08 48 89 ef e8 b8 c1 8f fd 48 8b 75 00 e9 96 00 00 00 49 89 c6 48 ba 00 00 00 00 00 fc ff df 4c 8d 60 70 4c 89 e3 48 c1 eb 03 <0f> b6 04 13 84 c0 0f 85 82 06 00 00 41 83 3c 24 02 77 0a e8 bf 78 RSP: 0018:ffff888120bafac8 EFLAGS: 00010212 RAX: 0000000000000000 RBX: 000000000000000e RCX: ffff8881173f0040 RDX: dffffc0000000000 RSI: ffffffffa58496c0 RDI: ffff88810b9ad1e4 RBP: ffff88810b9ac000 R08: ffffffffa77882a7 R09: 1ffffffff4ef1054 R10: dffffc0000000000 R11: fffffbfff4ef1055 R12: 0000000000000070 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88810b9ac000 FS: 0000000000000000(0000) GS:ffff8881f6c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6ddaa3439e CR3: 0000000139764003 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: hci_read_local_codecs_sync net/bluetooth/hci_sync.c:4546 [inline] hci_init_stage_sync net/bluetooth/hci_sync.c:3441 [inline] hci_init4_sync net/bluetooth/hci_sync.c:4706 [inline] hci_init_sync net/bluetooth/hci_sync.c:4742 [inline] hci_dev_init_sync net/bluetooth/hci_sync.c:4912 [inline] hci_dev_open_sync+0x19a9/0x2d30 net/bluetooth/hci_sync.c:4994 hci_dev_do_open net/bluetooth/hci_core.c:483 [inline] hci_power_on+0x11e/0x560 net/bluetooth/hci_core.c:1015 process_one_work kernel/workqueue.c:3267 [inline] process_scheduled_works+0x8ef/0x14f0 kernel/workqueue.c:3348 worker_thread+0x91f/0xe50 kernel/workqueue.c:3429 kthread+0x2cb/0x360 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50256", "url": "https://ubuntu.com/security/CVE-2024-50256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6() I got a syzbot report without a repro [1] crashing in nf_send_reset6() I think the issue is that dev->hard_header_len is zero, and we attempt later to push an Ethernet header. Use LL_MAX_HEADER, as other functions in net/ipv6/netfilter/nf_reject_ipv6.c. [1] skbuff: skb_under_panic: text:ffffffff89b1d008 len:74 put:14 head:ffff88803123aa00 data:ffff88803123a9f2 tail:0x3c end:0x140 dev:syz_tun kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 UID: 0 PID: 7373 Comm: syz.1.568 Not tainted 6.12.0-rc2-syzkaller-00631-g6d858708d465 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:skb_panic net/core/skbuff.c:206 [inline] RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216 Code: 0d 8d 48 c7 c6 60 a6 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 ba 30 38 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP: 0018:ffffc900045269b0 EFLAGS: 00010282 RAX: 0000000000000088 RBX: dffffc0000000000 RCX: cd66dacdc5d8e800 RDX: 0000000000000000 RSI: 0000000000000200 RDI: 0000000000000000 RBP: ffff88802d39a3d0 R08: ffffffff8174afec R09: 1ffff920008a4ccc R10: dffffc0000000000 R11: fffff520008a4ccd R12: 0000000000000140 R13: ffff88803123aa00 R14: ffff88803123a9f2 R15: 000000000000003c FS: 00007fdbee5ff6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000005d322000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: skb_push+0xe5/0x100 net/core/skbuff.c:2636 eth_header+0x38/0x1f0 net/ethernet/eth.c:83 dev_hard_header include/linux/netdevice.h:3208 [inline] nf_send_reset6+0xce6/0x1270 net/ipv6/netfilter/nf_reject_ipv6.c:358 nft_reject_inet_eval+0x3b9/0x690 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x418/0x6b0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] br_nf_pre_routing_ipv6+0x63e/0x770 net/bridge/br_netfilter_ipv6.c:184 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_bridge_pre net/bridge/br_input.c:277 [inline] br_handle_frame+0x9fd/0x1530 net/bridge/br_input.c:424 __netif_receive_skb_core+0x13e8/0x4570 net/core/dev.c:5562 __netif_receive_skb_one_core net/core/dev.c:5666 [inline] __netif_receive_skb+0x12f/0x650 net/core/dev.c:5781 netif_receive_skb_internal net/core/dev.c:5867 [inline] netif_receive_skb+0x1e8/0x890 net/core/dev.c:5926 tun_rx_batched+0x1b7/0x8f0 drivers/net/tun.c:1550 tun_get_user+0x3056/0x47e0 drivers/net/tun.c:2007 tun_chr_write_iter+0x10d/0x1f0 drivers/net/tun.c:2053 new_sync_write fs/read_write.c:590 [inline] vfs_write+0xa6d/0xc90 fs/read_write.c:683 ksys_write+0x183/0x2b0 fs/read_write.c:736 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:0x7fdbeeb7d1ff Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 c9 8d 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 1c 8e 02 00 48 RSP: 002b:00007fdbee5ff000 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fdbeed36058 RCX: 00007fdbeeb7d1ff RDX: 000000000000008e RSI: 0000000020000040 RDI: 00000000000000c8 RBP: 00007fdbeebf12be R08: 0000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50257", "url": "https://ubuntu.com/security/CVE-2024-50257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: Fix use-after-free in get_info() ip6table_nat module unload has refcnt warning for UAF. call trace is: WARNING: CPU: 1 PID: 379 at kernel/module/main.c:853 module_put+0x6f/0x80 Modules linked in: ip6table_nat(-) CPU: 1 UID: 0 PID: 379 Comm: ip6tables Not tainted 6.12.0-rc4-00047-gc2ee9f594da8-dirty #205 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:module_put+0x6f/0x80 Call Trace: get_info+0x128/0x180 do_ip6t_get_ctl+0x6a/0x430 nf_getsockopt+0x46/0x80 ipv6_getsockopt+0xb9/0x100 rawv6_getsockopt+0x42/0x190 do_sock_getsockopt+0xaa/0x180 __sys_getsockopt+0x70/0xc0 __x64_sys_getsockopt+0x20/0x30 do_syscall_64+0xa2/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Concurrent execution of module unload and get_info() trigered the warning. The root cause is as follows: cpu0\t\t\t\t cpu1 module_exit //mod->state = MODULE_STATE_GOING ip6table_nat_exit xt_unregister_template \tkfree(t) \t//removed from templ_list \t\t\t\t getinfo() \t\t\t\t\t t = xt_find_table_lock \t\t\t\t\t\tlist_for_each_entry(tmpl, &xt_templates[af]...) \t\t\t\t\t\t\tif (strcmp(tmpl->name, name)) \t\t\t\t\t\t\t\tcontinue; //table not found \t\t\t\t\t\t\ttry_module_get \t\t\t\t\t\tlist_for_each_entry(t, &xt_net->tables[af]...) \t\t\t\t\t\t\treturn t; //not get refcnt \t\t\t\t\t module_put(t->me) //uaf unregister_pernet_subsys //remove table from xt_net list While xt_table module was going away and has been removed from xt_templates list, we couldnt get refcnt of xt_table->me. Check module in xt_net->tables list re-traversal to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50258", "url": "https://ubuntu.com/security/CVE-2024-50258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix crash when config small gso_max_size/gso_ipv4_max_size Config a small gso_max_size/gso_ipv4_max_size will lead to an underflow in sk_dst_gso_max_size(), which may trigger a BUG_ON crash, because sk->sk_gso_max_size would be much bigger than device limits. Call Trace: tcp_write_xmit tso_segs = tcp_init_tso_segs(skb, mss_now); tcp_set_skb_tso_segs tcp_skb_pcount_set // skb->len = 524288, mss_now = 8 // u16 tso_segs = 524288/8 = 65535 -> 0 tso_segs = DIV_ROUND_UP(skb->len, mss_now) BUG_ON(!tso_segs) Add check for the minimum value of gso_max_size and gso_ipv4_max_size.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50262", "url": "https://ubuntu.com/security/CVE-2024-50262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix out-of-bounds write in trie_get_next_key() trie_get_next_key() allocates a node stack with size trie->max_prefixlen, while it writes (trie->max_prefixlen + 1) nodes to the stack when it has full paths from the root to leaves. For example, consider a trie with max_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ... 0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with .prefixlen = 8 make 9 nodes be written on the node stack with size 8.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53044", "url": "https://ubuntu.com/security/CVE-2024-53044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_api: fix xa_insert() error path in tcf_block_get_ext() This command: $ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact Error: block dev insert failed: -EBUSY. fails because user space requests the same block index to be set for both ingress and egress. [ side note, I don't think it even failed prior to commit 913b47d3424e (\"net/sched: Introduce tc block netdev tracking infra\"), because this is a command from an old set of notes of mine which used to work, but alas, I did not scientifically bisect this ] The problem is not that it fails, but rather, that the second time around, it fails differently (and irrecoverably): $ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact Error: dsa_core: Flow block cb is busy. [ another note: the extack is added by me for illustration purposes. the context of the problem is that clsact_init() obtains the same &q->ingress_block pointer as &q->egress_block, and since we call tcf_block_get_ext() on both of them, \"dev\" will be added to the block->ports xarray twice, thus failing the operation: once through the ingress block pointer, and once again through the egress block pointer. the problem itself is that when xa_insert() fails, we have emitted a FLOW_BLOCK_BIND command through ndo_setup_tc(), but the offload never sees a corresponding FLOW_BLOCK_UNBIND. ] Even correcting the bad user input, we still cannot recover: $ tc qdisc replace dev swp3 ingress_block 1 egress_block 2 clsact Error: dsa_core: Flow block cb is busy. Basically the only way to recover is to reboot the system, or unbind and rebind the net device driver. To fix the bug, we need to fill the correct error teardown path which was missed during code movement, and call tcf_block_offload_unbind() when xa_insert() fails. [ last note, fundamentally I blame the label naming convention in tcf_block_get_ext() for the bug. The labels should be named after what they do, not after the error path that jumps to them. This way, it is obviously wrong that two labels pointing to the same code mean something is wrong, and checking the code correctness at the goto site is also easier ]", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50259", "url": "https://ubuntu.com/security/CVE-2024-50259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netdevsim: Add trailing zero to terminate the string in nsim_nexthop_bucket_activity_write() This was found by a static analyzer. We should not forget the trailing zero after copy_from_user() if we will further do some string operations, sscanf() in this case. Adding a trailing zero will ensure that the function performs properly.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50304", "url": "https://ubuntu.com/security/CVE-2024-50304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find() The per-netns IP tunnel hash table is protected by the RTNL mutex and ip_tunnel_find() is only called from the control path where the mutex is taken. Add a lockdep expression to hlist_for_each_entry_rcu() in ip_tunnel_find() in order to validate that the mutex is held and to silence the suspicious RCU usage warning [1]. [1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gd95d9a31aceb #139 Not tainted ----------------------------- net/ipv4/ip_tunnel.c:221 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/362: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60 stack backtrace: CPU: 12 UID: 0 PID: 362 Comm: ip Not tainted 6.12.0-rc3-custom-gd95d9a31aceb #139 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 ip_tunnel_find+0x435/0x4d0 ip_tunnel_newlink+0x517/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53042", "url": "https://ubuntu.com/security/CVE-2024-53042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_init_flow() There are code paths from which the function is called without holding the RCU read lock, resulting in a suspicious RCU usage warning [1]. Fix by using l3mdev_master_upper_ifindex_by_index() which will acquire the RCU read lock before calling l3mdev_master_upper_ifindex_by_index_rcu(). [1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gac8f72681cf2 #141 Not tainted ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/361: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60 stack backtrace: CPU: 3 UID: 0 PID: 361 Comm: ip Not tainted 6.12.0-rc3-custom-gac8f72681cf2 #141 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 dev_get_by_index_rcu+0x1d3/0x210 l3mdev_master_upper_ifindex_by_index_rcu+0x2b/0xf0 ip_tunnel_bind_dev+0x72f/0xa00 ip_tunnel_newlink+0x368/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53048", "url": "https://ubuntu.com/security/CVE-2024-53048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix crash on probe for DPLL enabled E810 LOM The E810 Lan On Motherboard (LOM) design is vendor specific. Intel provides the reference design, but it is up to vendor on the final product design. For some cases, like Linux DPLL support, the static values defined in the driver does not reflect the actual LOM design. Current implementation of dpll pins is causing the crash on probe of the ice driver for such DPLL enabled E810 LOM designs: WARNING: (...) at drivers/dpll/dpll_core.c:495 dpll_pin_get+0x2c4/0x330 ... Call Trace: ? __warn+0x83/0x130 ? dpll_pin_get+0x2c4/0x330 ? report_bug+0x1b7/0x1d0 ? handle_bug+0x42/0x70 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? dpll_pin_get+0x117/0x330 ? dpll_pin_get+0x2c4/0x330 ? dpll_pin_get+0x117/0x330 ice_dpll_get_pins.isra.0+0x52/0xe0 [ice] ... The number of dpll pins enabled by LOM vendor is greater than expected and defined in the driver for Intel designed NICs, which causes the crash. Prevent the crash and allow generic pin initialization within Linux DPLL subsystem for DPLL enabled E810 LOM designs. Newly designed solution for described issue will be based on \"per HW design\" pin initialization. It requires pin information dynamically acquired from the firmware and is already in progress, planned for next-tree only.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53058", "url": "https://ubuntu.com/security/CVE-2024-53058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data In case the non-paged data of a SKB carries protocol header and protocol payload to be transmitted on a certain platform that the DMA AXI address width is configured to 40-bit/48-bit, or the size of the non-paged data is bigger than TSO_MAX_BUFF_SIZE on a certain platform that the DMA AXI address width is configured to 32-bit, then this SKB requires at least two DMA transmit descriptors to serve it. For example, three descriptors are allocated to split one DMA buffer mapped from one piece of non-paged data: dma_desc[N + 0], dma_desc[N + 1], dma_desc[N + 2]. Then three elements of tx_q->tx_skbuff_dma[] will be allocated to hold extra information to be reused in stmmac_tx_clean(): tx_q->tx_skbuff_dma[N + 0], tx_q->tx_skbuff_dma[N + 1], tx_q->tx_skbuff_dma[N + 2]. Now we focus on tx_q->tx_skbuff_dma[entry].buf, which is the DMA buffer address returned by DMA mapping call. stmmac_tx_clean() will try to unmap the DMA buffer _ONLY_IF_ tx_q->tx_skbuff_dma[entry].buf is a valid buffer address. The expected behavior that saves DMA buffer address of this non-paged data to tx_q->tx_skbuff_dma[entry].buf is: tx_q->tx_skbuff_dma[N + 0].buf = NULL; tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = dma_map_single(); Unfortunately, the current code misbehaves like this: tx_q->tx_skbuff_dma[N + 0].buf = dma_map_single(); tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = NULL; On the stmmac_tx_clean() side, when dma_desc[N + 0] is closed by the DMA engine, tx_q->tx_skbuff_dma[N + 0].buf is a valid buffer address obviously, then the DMA buffer will be unmapped immediately. There may be a rare case that the DMA engine does not finish the pending dma_desc[N + 1], dma_desc[N + 2] yet. Now things will go horribly wrong, DMA is going to access a unmapped/unreferenced memory region, corrupted data will be transmited or iommu fault will be triggered :( In contrast, the for-loop that maps SKB fragments behaves perfectly as expected, and that is how the driver should do for both non-paged data and paged frags actually. This patch corrects DMA map/unmap sequences by fixing the array index for tx_q->tx_skbuff_dma[entry].buf when assigning DMA buffer address. Tested and verified on DWXGMAC CORE 3.20a", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50260", "url": "https://ubuntu.com/security/CVE-2024-50260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sock_map: fix a NULL pointer dereference in sock_map_link_update_prog() The following race condition could trigger a NULL pointer dereference: sock_map_link_detach():\t\tsock_map_link_update_prog(): mutex_lock(&sockmap_mutex); ... sockmap_link->map = NULL; mutex_unlock(&sockmap_mutex); \t\t\t\t mutex_lock(&sockmap_mutex); \t\t\t\t ... \t\t\t\t sock_map_prog_link_lookup(sockmap_link->map); \t\t\t\t mutex_unlock(&sockmap_mutex); Fix it by adding a NULL pointer check. In this specific case, it makes no sense to update a link which is being released.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53045", "url": "https://ubuntu.com/security/CVE-2024-53045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: dapm: fix bounds checker error in dapm_widget_list_create The widgets array in the snd_soc_dapm_widget_list has a __counted_by attribute attached to it, which points to the num_widgets variable. This attribute is used in bounds checking, and if it is not set before the array is filled, then the bounds sanitizer will issue a warning or a kernel panic if CONFIG_UBSAN_TRAP is set. This patch sets the size of the widgets list calculated with list_for_each as the initial value for num_widgets as it is used for allocating memory for the array. It is updated with the actual number of added elements after the array is filled.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50261", "url": "https://ubuntu.com/security/CVE-2024-50261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macsec: Fix use-after-free while sending the offloading packet KASAN reports the following UAF. The metadata_dst, which is used to store the SCI value for macsec offload, is already freed by metadata_dst_free() in macsec_free_netdev(), while driver still use it for sending the packet. To fix this issue, dst_release() is used instead to release metadata_dst. So it is not freed instantly in macsec_free_netdev() if still referenced by skb. BUG: KASAN: slab-use-after-free in mlx5e_xmit+0x1e8f/0x4190 [mlx5_core] Read of size 2 at addr ffff88813e42e038 by task kworker/7:2/714 [...] Workqueue: mld mld_ifc_work Call Trace: dump_stack_lvl+0x51/0x60 print_report+0xc1/0x600 kasan_report+0xab/0xe0 mlx5e_xmit+0x1e8f/0x4190 [mlx5_core] dev_hard_start_xmit+0x120/0x530 sch_direct_xmit+0x149/0x11e0 __qdisc_run+0x3ad/0x1730 __dev_queue_xmit+0x1196/0x2ed0 vlan_dev_hard_start_xmit+0x32e/0x510 [8021q] dev_hard_start_xmit+0x120/0x530 __dev_queue_xmit+0x14a7/0x2ed0 macsec_start_xmit+0x13e9/0x2340 dev_hard_start_xmit+0x120/0x530 __dev_queue_xmit+0x14a7/0x2ed0 ip6_finish_output2+0x923/0x1a70 ip6_finish_output+0x2d7/0x970 ip6_output+0x1ce/0x3a0 NF_HOOK.constprop.0+0x15f/0x190 mld_sendpack+0x59a/0xbd0 mld_ifc_work+0x48a/0xa80 process_one_work+0x5aa/0xe50 worker_thread+0x79c/0x1290 kthread+0x28f/0x350 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x11/0x20 Allocated by task 3922: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 __kasan_kmalloc+0x77/0x90 __kmalloc_noprof+0x188/0x400 metadata_dst_alloc+0x1f/0x4e0 macsec_newlink+0x914/0x1410 __rtnl_newlink+0xe08/0x15b0 rtnl_newlink+0x5f/0x90 rtnetlink_rcv_msg+0x667/0xa80 netlink_rcv_skb+0x12c/0x360 netlink_unicast+0x551/0x770 netlink_sendmsg+0x72d/0xbd0 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x52e/0x6a0 ___sys_sendmsg+0xeb/0x170 __sys_sendmsg+0xb5/0x140 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Freed by task 4011: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x50 poison_slab_object+0x10c/0x190 __kasan_slab_free+0x11/0x30 kfree+0xe0/0x290 macsec_free_netdev+0x3f/0x140 netdev_run_todo+0x450/0xc70 rtnetlink_rcv_msg+0x66f/0xa80 netlink_rcv_skb+0x12c/0x360 netlink_unicast+0x551/0x770 netlink_sendmsg+0x72d/0xbd0 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x52e/0x6a0 ___sys_sendmsg+0xeb/0x170 __sys_sendmsg+0xb5/0x140 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53059", "url": "https://ubuntu.com/security/CVE-2024-53059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd() 1. The size of the response packet is not validated. 2. The response buffer is not freed. Resolve these issues by switching to iwl_mvm_send_cmd_status(), which handles both size validation and frees the buffer.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53074", "url": "https://ubuntu.com/security/CVE-2024-53074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: don't leak a link on AP removal Release the link mapping resource in AP removal. This impacted devices that do not support the MLD API (9260 and down). On those devices, we couldn't start the AP again after the AP has been already started and stopped.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53049", "url": "https://ubuntu.com/security/CVE-2024-53049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slub/kunit: fix a WARNING due to unwrapped __kmalloc_cache_noprof 'modprobe slub_kunit' will have a warning as shown below. The root cause is that __kmalloc_cache_noprof was directly used, which resulted in no alloc_tag being allocated. This caused current->alloc_tag to be null, leading to a warning in alloc_tag_add_check. Let's add an alloc_hook layer to __kmalloc_cache_noprof specifically within lib/slub_kunit.c, which is the only user of this internal slub function outside kmalloc implementation itself. [58162.947016] WARNING: CPU: 2 PID: 6210 at ./include/linux/alloc_tag.h:125 alloc_tagging_slab_alloc_hook+0x268/0x27c [58162.957721] Call trace: [58162.957919] alloc_tagging_slab_alloc_hook+0x268/0x27c [58162.958286] __kmalloc_cache_noprof+0x14c/0x344 [58162.958615] test_kmalloc_redzone_access+0x50/0x10c [slub_kunit] [58162.959045] kunit_try_run_case+0x74/0x184 [kunit] [58162.959401] kunit_generic_run_threadfn_adapter+0x2c/0x4c [kunit] [58162.959841] kthread+0x10c/0x118 [58162.960093] ret_from_fork+0x10/0x20 [58162.960363] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50192", "url": "https://ubuntu.com/security/CVE-2024-50192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v4: Don't allow a VMOVP on a dying VPE Kunkun Jiang reported that there is a small window of opportunity for userspace to force a change of affinity for a VPE while the VPE has already been unmapped, but the corresponding doorbell interrupt still visible in /proc/irq/. Plug the race by checking the value of vmapp_count, which tracks whether the VPE is mapped ot not, and returning an error in this case. This involves making vmapp_count common to both GICv4.1 and its v4.0 ancestor.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50069", "url": "https://ubuntu.com/security/CVE-2024-50069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: apple: check devm_kasprintf() returned value devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked. Fix this lack and check the returned value. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50070", "url": "https://ubuntu.com/security/CVE-2024-50070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: stm32: check devm_kasprintf() returned value devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked. Fix this lack and check the returned value. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50196", "url": "https://ubuntu.com/security/CVE-2024-50196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: ocelot: fix system hang on level based interrupts The current implementation only calls chained_irq_enter() and chained_irq_exit() if it detects pending interrupts. ``` for (i = 0; i < info->stride; i++) { \turegmap_read(info->map, id_reg + 4 * i, ®); \tif (!reg) \t\tcontinue; \tchained_irq_enter(parent_chip, desc); ``` However, in case of GPIO pin configured in level mode and the parent controller configured in edge mode, GPIO interrupt might be lowered by the hardware. In the result, if the interrupt is short enough, the parent interrupt is still pending while the GPIO interrupt is cleared; chained_irq_enter() never gets called and the system hangs trying to service the parent interrupt. Moving chained_irq_enter() and chained_irq_exit() outside the for loop ensures that they are called even when GPIO interrupt is lowered by the hardware. The similar code with chained_irq_enter() / chained_irq_exit() functions wrapping interrupt checking loop may be found in many other drivers: ``` grep -r -A 10 chained_irq_enter drivers/pinctrl ```", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50197", "url": "https://ubuntu.com/security/CVE-2024-50197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: intel: platform: fix error path in device_for_each_child_node() The device_for_each_child_node() loop requires calls to fwnode_handle_put() upon early returns to decrement the refcount of the child node and avoid leaking memory if that error path is triggered. There is one early returns within that loop in intel_platform_pinctrl_prepare_community(), but fwnode_handle_put() is missing. Instead of adding the missing call, the scoped version of the loop can be used to simplify the code and avoid mistakes in the future if new early returns are added, as the child node is only used for parsing, and it is never assigned.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50071", "url": "https://ubuntu.com/security/CVE-2024-50071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: nuvoton: fix a double free in ma35_pinctrl_dt_node_to_map_func() 'new_map' is allocated using devm_* which takes care of freeing the allocated data on device removal, call to \t.dt_free_map = pinconf_generic_dt_free_map double frees the map as pinconf_generic_dt_free_map() calls pinctrl_utils_free_map(). Fix this by using kcalloc() instead of auto-managed devm_kcalloc().", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50072", "url": "https://ubuntu.com/security/CVE-2024-50072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/bugs: Use code segment selector for VERW operand Robert Gill reported below #GP in 32-bit mode when dosemu software was executing vm86() system call: general protection fault: 0000 [#1] PREEMPT SMP CPU: 4 PID: 4610 Comm: dosemu.bin Not tainted 6.6.21-gentoo-x86 #1 Hardware name: Dell Inc. PowerEdge 1950/0H723K, BIOS 2.7.0 10/30/2010 EIP: restore_all_switch_stack+0xbe/0xcf EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000 ESI: 00000000 EDI: 00000000 EBP: 00000000 ESP: ff8affdc DS: 0000 ES: 0000 FS: 0000 GS: 0033 SS: 0068 EFLAGS: 00010046 CR0: 80050033 CR2: 00c2101c CR3: 04b6d000 CR4: 000406d0 Call Trace: show_regs+0x70/0x78 die_addr+0x29/0x70 exc_general_protection+0x13c/0x348 exc_bounds+0x98/0x98 handle_exception+0x14d/0x14d exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf This only happens in 32-bit mode when VERW based mitigations like MDS/RFDS are enabled. This is because segment registers with an arbitrary user value can result in #GP when executing VERW. Intel SDM vol. 2C documents the following behavior for VERW instruction: #GP(0) - If a memory operand effective address is outside the CS, DS, ES, \t FS, or GS segment limit. CLEAR_CPU_BUFFERS macro executes VERW instruction before returning to user space. Use %cs selector to reference VERW operand. This ensures VERW will not #GP for an arbitrary user %ds. [ mingo: Fixed the SOB chain. ]", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50073", "url": "https://ubuntu.com/security/CVE-2024-50073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: Fix use-after-free in gsm_cleanup_mux BUG: KASAN: slab-use-after-free in gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] Read of size 8 at addr ffff88815fe99c00 by task poc/3379 CPU: 0 UID: 0 PID: 3379 Comm: poc Not tainted 6.11.0+ #56 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] __pfx_gsm_cleanup_mux+0x10/0x10 drivers/tty/n_gsm.c:3124 [n_gsm] __pfx_sched_clock_cpu+0x10/0x10 kernel/sched/clock.c:389 update_load_avg+0x1c1/0x27b0 kernel/sched/fair.c:4500 __pfx_min_vruntime_cb_rotate+0x10/0x10 kernel/sched/fair.c:846 __rb_insert_augmented+0x492/0xbf0 lib/rbtree.c:161 gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] _raw_spin_lock_irqsave+0x92/0xf0 arch/x86/include/asm/atomic.h:107 __pfx_gsmld_ioctl+0x10/0x10 drivers/tty/n_gsm.c:3822 [n_gsm] ktime_get+0x5e/0x140 kernel/time/timekeeping.c:195 ldsem_down_read+0x94/0x4e0 arch/x86/include/asm/atomic64_64.h:79 __pfx_ldsem_down_read+0x10/0x10 drivers/tty/tty_ldsem.c:338 __pfx_do_vfs_ioctl+0x10/0x10 fs/ioctl.c:805 tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 Allocated by task 65: gsm_data_alloc.constprop.0+0x27/0x190 drivers/tty/n_gsm.c:926 [n_gsm] gsm_send+0x2c/0x580 drivers/tty/n_gsm.c:819 [n_gsm] gsm1_receive+0x547/0xad0 drivers/tty/n_gsm.c:3038 [n_gsm] gsmld_receive_buf+0x176/0x280 drivers/tty/n_gsm.c:3609 [n_gsm] tty_ldisc_receive_buf+0x101/0x1e0 drivers/tty/tty_buffer.c:391 tty_port_default_receive_buf+0x61/0xa0 drivers/tty/tty_port.c:39 flush_to_ldisc+0x1b0/0x750 drivers/tty/tty_buffer.c:445 process_scheduled_works+0x2b0/0x10d0 kernel/workqueue.c:3229 worker_thread+0x3dc/0x950 kernel/workqueue.c:3391 kthread+0x2a3/0x370 kernel/kthread.c:389 ret_from_fork+0x2d/0x70 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:257 Freed by task 3367: kfree+0x126/0x420 mm/slub.c:4580 gsm_cleanup_mux+0x36c/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 [Analysis] gsm_msg on the tx_ctrl_list or tx_data_list of gsm_mux can be freed by multi threads through ioctl,which leads to the occurrence of uaf. Protect it by gsm tx lock.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50193", "url": "https://ubuntu.com/security/CVE-2024-50193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/entry_32: Clear CPU buffers after register restore in NMI return CPU buffers are currently cleared after call to exc_nmi, but before register state is restored. This may be okay for MDS mitigation but not for RDFS. Because RDFS mitigation requires CPU buffers to be cleared when registers don't have any sensitive data. Move CLEAR_CPU_BUFFERS after RESTORE_ALL_NMI.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50074", "url": "https://ubuntu.com/security/CVE-2024-50074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: parport: Proper fix for array out-of-bounds access The recent fix for array out-of-bounds accesses replaced sprintf() calls blindly with snprintf(). However, since snprintf() returns the would-be-printed size, not the actually output size, the length calculation can still go over the given limit. Use scnprintf() instead of snprintf(), which returns the actually output letters, for addressing the potential out-of-bounds access properly.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50100", "url": "https://ubuntu.com/security/CVE-2024-50100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: gadget: dummy-hcd: Fix \"task hung\" problem The syzbot fuzzer has been encountering \"task hung\" problems ever since the dummy-hcd driver was changed to use hrtimers instead of regular timers. It turns out that the problems are caused by a subtle difference between the timer_pending() and hrtimer_active() APIs. The changeover blindly replaced the first by the second. However, timer_pending() returns True when the timer is queued but not when its callback is running, whereas hrtimer_active() returns True when the hrtimer is queued _or_ its callback is running. This difference occasionally caused dummy_urb_enqueue() to think that the callback routine had not yet started when in fact it was almost finished. As a result the hrtimer was not restarted, which made it impossible for the driver to dequeue later the URB that was just enqueued. This caused usb_kill_urb() to hang, and things got worse from there. Since hrtimers have no API for telling when they are queued and the callback isn't running, the driver must keep track of this for itself. That's what this patch does, adding a new \"timer_pending\" flag and setting or clearing it at the appropriate times.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50075", "url": "https://ubuntu.com/security/CVE-2024-50075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xhci: tegra: fix checked USB2 port number If USB virtualizatoin is enabled, USB2 ports are shared between all Virtual Functions. The USB2 port number owned by an USB2 root hub in a Virtual Function may be less than total USB2 phy number supported by the Tegra XUSB controller. Using total USB2 phy number as port number to check all PORTSC values would cause invalid memory access. [ 116.923438] Unable to handle kernel paging request at virtual address 006c622f7665642f ... [ 117.213640] Call trace: [ 117.216783] tegra_xusb_enter_elpg+0x23c/0x658 [ 117.222021] tegra_xusb_runtime_suspend+0x40/0x68 [ 117.227260] pm_generic_runtime_suspend+0x30/0x50 [ 117.232847] __rpm_callback+0x84/0x3c0 [ 117.237038] rpm_suspend+0x2dc/0x740 [ 117.241229] pm_runtime_work+0xa0/0xb8 [ 117.245769] process_scheduled_works+0x24c/0x478 [ 117.251007] worker_thread+0x23c/0x328 [ 117.255547] kthread+0x104/0x1b0 [ 117.259389] ret_from_fork+0x10/0x20 [ 117.263582] Code: 54000222 f9461ae8 f8747908 b4ffff48 (f9400100)", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50076", "url": "https://ubuntu.com/security/CVE-2024-50076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vt: prevent kernel-infoleak in con_font_get() font.data may not initialize all memory spaces depending on the implementation of vc->vc_sw->con_font_get. This may cause info-leak, so to prevent this, it is safest to modify it to initialize the allocated memory space to 0, and it generally does not affect the overall performance of the system.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50077", "url": "https://ubuntu.com/security/CVE-2024-50077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix multiple init when debugfs is disabled If bt_debugfs is not created successfully, which happens if either CONFIG_DEBUG_FS or CONFIG_DEBUG_FS_ALLOW_ALL is unset, then iso_init() returns early and does not set iso_inited to true. This means that a subsequent call to iso_init() will result in duplicate calls to proto_register(), bt_sock_register(), etc. With CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, the duplicate call to proto_register() triggers this BUG(): list_add double add: new=ffffffffc0b280d0, prev=ffffffffbab56250, next=ffffffffc0b280d0. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:35! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 2 PID: 887 Comm: bluetoothd Not tainted 6.10.11-1-ao-desktop #1 RIP: 0010:__list_add_valid_or_report+0x9a/0xa0 ... __list_add_valid_or_report+0x9a/0xa0 proto_register+0x2b5/0x340 iso_init+0x23/0x150 [bluetooth] set_iso_socket_func+0x68/0x1b0 [bluetooth] kmem_cache_free+0x308/0x330 hci_sock_sendmsg+0x990/0x9e0 [bluetooth] __sock_sendmsg+0x7b/0x80 sock_write_iter+0x9a/0x110 do_iter_readv_writev+0x11d/0x220 vfs_writev+0x180/0x3e0 do_writev+0xca/0x100 ... This change removes the early return. The check for iso_debugfs being NULL was unnecessary, it is always NULL when iso_inited is false.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50078", "url": "https://ubuntu.com/security/CVE-2024-50078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Call iso_exit() on module unload If iso_init() has been called, iso_exit() must be called on module unload. Without that, the struct proto that iso_init() registered with proto_register() becomes invalid, which could cause unpredictable problems later. In my case, with CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, loading the module again usually triggers this BUG(): list_add corruption. next->prev should be prev (ffffffffb5355fd0), but was 0000000000000068. (next=ffffffffc0a010d0). ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:29! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 4159 Comm: modprobe Not tainted 6.10.11-4+bt2-ao-desktop #1 RIP: 0010:__list_add_valid_or_report+0x61/0xa0 ... __list_add_valid_or_report+0x61/0xa0 proto_register+0x299/0x320 hci_sock_init+0x16/0xc0 [bluetooth] bt_init+0x68/0xd0 [bluetooth] __pfx_bt_init+0x10/0x10 [bluetooth] do_one_initcall+0x80/0x2f0 do_init_module+0x8b/0x230 __do_sys_init_module+0x15f/0x190 do_syscall_64+0x68/0x110 ...", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50198", "url": "https://ubuntu.com/security/CVE-2024-50198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: veml6030: fix IIO device retrieval from embedded device The dev pointer that is received as an argument in the in_illuminance_period_available_show function references the device embedded in the IIO device, not in the i2c client. dev_to_iio_dev() must be used to accessthe right data. The current implementation leads to a segmentation fault on every attempt to read the attribute because indio_dev gets a NULL assignment. This bug has been present since the first appearance of the driver, apparently since the last version (V6) before getting applied. A constant attribute was used until then, and the last modifications might have not been tested again.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50201", "url": "https://ubuntu.com/security/CVE-2024-50201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: Fix encoder->possible_clones Include the encoder itself in its possible_clones bitmask. In the past nothing validated that drivers were populating possible_clones correctly, but that changed in commit 74d2aacbe840 (\"drm: Validate encoder->possible_clones\"). Looks like radeon never got the memo and is still not following the rules 100% correctly. This results in some warnings during driver initialization: Bogus possible_clones: [ENCODER:46:TV-46] possible_clones=0x4 (full encoder mask=0x7) WARNING: CPU: 0 PID: 170 at drivers/gpu/drm/drm_mode_config.c:615 drm_mode_config_validate+0x113/0x39c ... (cherry picked from commit 3b6e7d40649c0d75572039aff9d0911864c689db)", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50098", "url": "https://ubuntu.com/security/CVE-2024-50098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Set SDEV_OFFLINE when UFS is shut down There is a history of deadlock if reboot is performed at the beginning of booting. SDEV_QUIESCE was set for all LU's scsi_devices by UFS shutdown, and at that time the audio driver was waiting on blk_mq_submit_bio() holding a mutex_lock while reading the fw binary. After that, a deadlock issue occurred while audio driver shutdown was waiting for mutex_unlock of blk_mq_submit_bio(). To solve this, set SDEV_OFFLINE for all LUs except WLUN, so that any I/O that comes down after a UFS shutdown will return an error. [ 31.907781]I[0: swapper/0: 0] 1 130705007 1651079834 11289729804 0 D( 2) 3 ffffff882e208000 * init [device_shutdown] [ 31.907793]I[0: swapper/0: 0] Mutex: 0xffffff8849a2b8b0: owner[0xffffff882e28cb00 kworker/6:0 :49] [ 31.907806]I[0: swapper/0: 0] Call trace: [ 31.907810]I[0: swapper/0: 0] __switch_to+0x174/0x338 [ 31.907819]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc [ 31.907826]I[0: swapper/0: 0] schedule+0x7c/0xe8 [ 31.907834]I[0: swapper/0: 0] schedule_preempt_disabled+0x24/0x40 [ 31.907842]I[0: swapper/0: 0] __mutex_lock+0x408/0xdac [ 31.907849]I[0: swapper/0: 0] __mutex_lock_slowpath+0x14/0x24 [ 31.907858]I[0: swapper/0: 0] mutex_lock+0x40/0xec [ 31.907866]I[0: swapper/0: 0] device_shutdown+0x108/0x280 [ 31.907875]I[0: swapper/0: 0] kernel_restart+0x4c/0x11c [ 31.907883]I[0: swapper/0: 0] __arm64_sys_reboot+0x15c/0x280 [ 31.907890]I[0: swapper/0: 0] invoke_syscall+0x70/0x158 [ 31.907899]I[0: swapper/0: 0] el0_svc_common+0xb4/0xf4 [ 31.907909]I[0: swapper/0: 0] do_el0_svc+0x2c/0xb0 [ 31.907918]I[0: swapper/0: 0] el0_svc+0x34/0xe0 [ 31.907928]I[0: swapper/0: 0] el0t_64_sync_handler+0x68/0xb4 [ 31.907937]I[0: swapper/0: 0] el0t_64_sync+0x1a0/0x1a4 [ 31.908774]I[0: swapper/0: 0] 49 0 11960702 11236868007 0 D( 2) 6 ffffff882e28cb00 * kworker/6:0 [__bio_queue_enter] [ 31.908783]I[0: swapper/0: 0] Call trace: [ 31.908788]I[0: swapper/0: 0] __switch_to+0x174/0x338 [ 31.908796]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc [ 31.908803]I[0: swapper/0: 0] schedule+0x7c/0xe8 [ 31.908811]I[0: swapper/0: 0] __bio_queue_enter+0xb8/0x178 [ 31.908818]I[0: swapper/0: 0] blk_mq_submit_bio+0x194/0x67c [ 31.908827]I[0: swapper/0: 0] __submit_bio+0xb8/0x19c", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50079", "url": "https://ubuntu.com/security/CVE-2024-50079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/sqpoll: ensure task state is TASK_RUNNING when running task_work When the sqpoll is exiting and cancels pending work items, it may need to run task_work. If this happens from within io_uring_cancel_generic(), then it may be under waiting for the io_uring_task waitqueue. This results in the below splat from the scheduler, as the ring mutex may be attempted grabbed while in a TASK_INTERRUPTIBLE state. Ensure that the task state is set appropriately for that, just like what is done for the other cases in io_run_task_work(). do not call blocking ops when !TASK_RUNNING; state=1 set at [<0000000029387fd2>] prepare_to_wait+0x88/0x2fc WARNING: CPU: 6 PID: 59939 at kernel/sched/core.c:8561 __might_sleep+0xf4/0x140 Modules linked in: CPU: 6 UID: 0 PID: 59939 Comm: iou-sqp-59938 Not tainted 6.12.0-rc3-00113-g8d020023b155 #7456 Hardware name: linux,dummy-virt (DT) pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : __might_sleep+0xf4/0x140 lr : __might_sleep+0xf4/0x140 sp : ffff80008c5e7830 x29: ffff80008c5e7830 x28: ffff0000d93088c0 x27: ffff60001c2d7230 x26: dfff800000000000 x25: ffff0000e16b9180 x24: ffff80008c5e7a50 x23: 1ffff000118bcf4a x22: ffff0000e16b9180 x21: ffff0000e16b9180 x20: 000000000000011b x19: ffff80008310fac0 x18: 1ffff000118bcd90 x17: 30303c5b20746120 x16: 74657320313d6574 x15: 0720072007200720 x14: 0720072007200720 x13: 0720072007200720 x12: ffff600036c64f0b x11: 1fffe00036c64f0a x10: ffff600036c64f0a x9 : dfff800000000000 x8 : 00009fffc939b0f6 x7 : ffff0001b6327853 x6 : 0000000000000001 x5 : ffff0001b6327850 x4 : ffff600036c64f0b x3 : ffff8000803c35bc x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000e16b9180 Call trace: __might_sleep+0xf4/0x140 mutex_lock+0x84/0x124 io_handle_tw_list+0xf4/0x260 tctx_task_work_run+0x94/0x340 io_run_task_work+0x1ec/0x3c0 io_uring_cancel_generic+0x364/0x524 io_sq_thread+0x820/0x124c ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50080", "url": "https://ubuntu.com/security/CVE-2024-50080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: don't allow user copy for unprivileged device UBLK_F_USER_COPY requires userspace to call write() on ublk char device for filling request buffer, and unprivileged device can't be trusted. So don't allow user copy for unprivileged device.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50081", "url": "https://ubuntu.com/security/CVE-2024-50081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-mq: setup queue ->tag_set before initializing hctx Commit 7b815817aa58 (\"blk-mq: add helper for checking if one CPU is mapped to specified hctx\") needs to check queue mapping via tag set in hctx's cpuhp handler. However, q->tag_set may not be setup yet when the cpuhp handler is enabled, then kernel oops is triggered. Fix the issue by setup queue tag_set before initializing hctx.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50082", "url": "https://ubuntu.com/security/CVE-2024-50082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race We're seeing crashes from rq_qos_wake_function that look like this: BUG: unable to handle page fault for address: ffffafe180a40084 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 100000067 P4D 100000067 PUD 10027c067 PMD 10115d067 PTE 0 Oops: Oops: 0002 [#1] PREEMPT SMP PTI CPU: 17 UID: 0 PID: 0 Comm: swapper/17 Not tainted 6.12.0-rc3-00013-geca631b8fe80 #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:_raw_spin_lock_irqsave+0x1d/0x40 Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 9c 41 5c fa 65 ff 05 62 97 30 4c 31 c0 ba 01 00 00 00 0f b1 17 75 0a 4c 89 e0 41 5c c3 cc cc cc cc 89 c6 e8 2c 0b 00 RSP: 0018:ffffafe180580ca0 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffffafe180a3f7a8 RCX: 0000000000000011 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffffafe180a40084 RBP: 0000000000000000 R08: 00000000001e7240 R09: 0000000000000011 R10: 0000000000000028 R11: 0000000000000888 R12: 0000000000000002 R13: ffffafe180a40084 R14: 0000000000000000 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff9aaf1f280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffafe180a40084 CR3: 000000010e428002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: try_to_wake_up+0x5a/0x6a0 rq_qos_wake_function+0x71/0x80 __wake_up_common+0x75/0xa0 __wake_up+0x36/0x60 scale_up.part.0+0x50/0x110 wb_timer_fn+0x227/0x450 ... So rq_qos_wake_function() calls wake_up_process(data->task), which calls try_to_wake_up(), which faults in raw_spin_lock_irqsave(&p->pi_lock). p comes from data->task, and data comes from the waitqueue entry, which is stored on the waiter's stack in rq_qos_wait(). Analyzing the core dump with drgn, I found that the waiter had already woken up and moved on to a completely unrelated code path, clobbering what was previously data->task. Meanwhile, the waker was passing the clobbered garbage in data->task to wake_up_process(), leading to the crash. What's happening is that in between rq_qos_wake_function() deleting the waitqueue entry and calling wake_up_process(), rq_qos_wait() is finding that it already got a token and returning. The race looks like this: rq_qos_wait() rq_qos_wake_function() ============================================================== prepare_to_wait_exclusive() data->got_token = true; list_del_init(&curr->entry); if (data.got_token) break; finish_wait(&rqw->wait, &data.wq); ^- returns immediately because list_empty_careful(&wq_entry->entry) is true ... return, go do something else ... wake_up_process(data->task) (NO LONGER VALID!)-^ Normally, finish_wait() is supposed to synchronize against the waker. But, as noted above, it is returning immediately because the waitqueue entry has already been removed from the waitqueue. The bug is that rq_qos_wake_function() is accessing the waitqueue entry AFTER deleting it. Note that autoremove_wake_function() wakes the waiter and THEN deletes the waitqueue entry, which is the proper order. Fix it by swapping the order. We also need to use list_del_init_careful() to match the list_empty_careful() in finish_wait().", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50101", "url": "https://ubuntu.com/security/CVE-2024-50101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI devices Previously, the domain_context_clear() function incorrectly called pci_for_each_dma_alias() to set up context entries for non-PCI devices. This could lead to kernel hangs or other unexpected behavior. Add a check to only call pci_for_each_dma_alias() for PCI devices. For non-PCI devices, domain_context_clear_one() is called directly.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50083", "url": "https://ubuntu.com/security/CVE-2024-50083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix mptcp DSS corruption due to large pmtu xmit Syzkaller was able to trigger a DSS corruption: TCP: request_sock_subflow_v4: Possible SYN flooding on port [::]:20002. Sending cookies. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 5227 at net/mptcp/protocol.c:695 __mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695 Modules linked in: CPU: 0 UID: 0 PID: 5227 Comm: syz-executor350 Not tainted 6.11.0-syzkaller-08829-gaf9c191ac2a0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:__mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695 Code: 0f b6 dc 31 ff 89 de e8 b5 dd ea f5 89 d8 48 81 c4 50 01 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 98 da ea f5 90 <0f> 0b 90 e9 47 ff ff ff e8 8a da ea f5 90 0f 0b 90 e9 99 e0 ff ff RSP: 0018:ffffc90000006db8 EFLAGS: 00010246 RAX: ffffffff8ba9df18 RBX: 00000000000055f0 RCX: ffff888030023c00 RDX: 0000000000000100 RSI: 00000000000081e5 RDI: 00000000000055f0 RBP: 1ffff110062bf1ae R08: ffffffff8ba9cf12 R09: 1ffff110062bf1b8 R10: dffffc0000000000 R11: ffffed10062bf1b9 R12: 0000000000000000 R13: dffffc0000000000 R14: 00000000700cec61 R15: 00000000000081e5 FS: 000055556679c380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020287000 CR3: 0000000077892000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: move_skbs_to_msk net/mptcp/protocol.c:811 [inline] mptcp_data_ready+0x29c/0xa90 net/mptcp/protocol.c:854 subflow_data_ready+0x34a/0x920 net/mptcp/subflow.c:1490 tcp_data_queue+0x20fd/0x76c0 net/ipv4/tcp_input.c:5283 tcp_rcv_established+0xfba/0x2020 net/ipv4/tcp_input.c:6237 tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915 tcp_v4_rcv+0x2dc0/0x37f0 net/ipv4/tcp_ipv4.c:2350 ip_protocol_deliver_rcu+0x22e/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x341/0x5f0 net/ipv4/ip_input.c:233 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314 __netif_receive_skb_one_core net/core/dev.c:5662 [inline] __netif_receive_skb+0x2bf/0x650 net/core/dev.c:5775 process_backlog+0x662/0x15b0 net/core/dev.c:6107 __napi_poll+0xcb/0x490 net/core/dev.c:6771 napi_poll net/core/dev.c:6840 [inline] net_rx_action+0x89b/0x1240 net/core/dev.c:6962 handle_softirqs+0x2c5/0x980 kernel/softirq.c:554 do_softirq+0x11b/0x1e0 kernel/softirq.c:455 __local_bh_enable_ip+0x1bb/0x200 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0x1764/0x3e80 net/core/dev.c:4451 dev_queue_xmit include/linux/netdevice.h:3094 [inline] neigh_hh_output include/net/neighbour.h:526 [inline] neigh_output include/net/neighbour.h:540 [inline] ip_finish_output2+0xd41/0x1390 net/ipv4/ip_output.c:236 ip_local_out net/ipv4/ip_output.c:130 [inline] __ip_queue_xmit+0x118c/0x1b80 net/ipv4/ip_output.c:536 __tcp_transmit_skb+0x2544/0x3b30 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_mtu_probe net/ipv4/tcp_output.c:2547 [inline] tcp_write_xmit+0x641d/0x6bf0 net/ipv4/tcp_output.c:2752 __tcp_push_pending_frames+0x9b/0x360 net/ipv4/tcp_output.c:3015 tcp_push_pending_frames include/net/tcp.h:2107 [inline] tcp_data_snd_check net/ipv4/tcp_input.c:5714 [inline] tcp_rcv_established+0x1026/0x2020 net/ipv4/tcp_input.c:6239 tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915 sk_backlog_rcv include/net/sock.h:1113 [inline] __release_sock+0x214/0x350 net/core/sock.c:3072 release_sock+0x61/0x1f0 net/core/sock.c:3626 mptcp_push_ ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50068", "url": "https://ubuntu.com/security/CVE-2024-50068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/tests/sysfs-kunit.h: fix memory leak in damon_sysfs_test_add_targets() The sysfs_target->regions allocated in damon_sysfs_regions_alloc() is not freed in damon_sysfs_test_add_targets(), which cause the following memory leak, free it to fix it. \tunreferenced object 0xffffff80c2a8db80 (size 96): \t comm \"kunit_try_catch\", pid 187, jiffies 4294894363 \t hex dump (first 32 bytes): \t 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ \t 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ \t backtrace (crc 0): \t [<0000000001e3714d>] kmemleak_alloc+0x34/0x40 \t [<000000008e6835c1>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000001286d9f8>] damon_sysfs_test_add_targets+0x1cc/0x738 \t [<0000000032ef8f77>] kunit_try_run_case+0x13c/0x3ac \t [<00000000f3edea23>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000adf936cf>] kthread+0x2e8/0x374 \t [<0000000041bb1628>] ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50199", "url": "https://ubuntu.com/security/CVE-2024-50199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/swapfile: skip HugeTLB pages for unuse_vma I got a bad pud error and lost a 1GB HugeTLB when calling swapoff. The problem can be reproduced by the following steps: 1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory. 2. Swapout the above anonymous memory. 3. run swapoff and we will get a bad pud error in kernel message: mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7) We can tell that pud_clear_bad is called by pud_none_or_clear_bad in unuse_pud_range() by ftrace. And therefore the HugeTLB pages will never be freed because we lost it from page table. We can skip HugeTLB pages for unuse_vma to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50066", "url": "https://ubuntu.com/security/CVE-2024-50066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mremap: fix move_normal_pmd/retract_page_tables race In mremap(), move_page_tables() looks at the type of the PMD entry and the specified address range to figure out by which method the next chunk of page table entries should be moved. At that point, the mmap_lock is held in write mode, but no rmap locks are held yet. For PMD entries that point to page tables and are fully covered by the source address range, move_pgt_entry(NORMAL_PMD, ...) is called, which first takes rmap locks, then does move_normal_pmd(). move_normal_pmd() takes the necessary page table locks at source and destination, then moves an entire page table from the source to the destination. The problem is: The rmap locks, which protect against concurrent page table removal by retract_page_tables() in the THP code, are only taken after the PMD entry has been read and it has been decided how to move it. So we can race as follows (with two processes that have mappings of the same tmpfs file that is stored on a tmpfs mount with huge=advise); note that process A accesses page tables through the MM while process B does it through the file rmap: process A process B ========= ========= mremap mremap_to move_vma move_page_tables get_old_pmd alloc_new_pmd *** PREEMPT *** madvise(MADV_COLLAPSE) do_madvise madvise_walk_vmas madvise_vma_behavior madvise_collapse hpage_collapse_scan_file collapse_file retract_page_tables i_mmap_lock_read(mapping) pmdp_collapse_flush i_mmap_unlock_read(mapping) move_pgt_entry(NORMAL_PMD, ...) take_rmap_locks move_normal_pmd drop_rmap_locks When this happens, move_normal_pmd() can end up creating bogus PMD entries in the line `pmd_populate(mm, new_pmd, pmd_pgtable(pmd))`. The effect depends on arch-specific and machine-specific details; on x86, you can end up with physical page 0 mapped as a page table, which is likely exploitable for user->kernel privilege escalation. Fix the race by letting process B recheck that the PMD still points to a page table after the rmap locks have been taken. Otherwise, we bail and let the caller fall back to the PTE-level copying path, which will then bail immediately at the pmd_none() check. Bug reachability: Reaching this bug requires that you can create shmem/file THP mappings - anonymous THP uses different code that doesn't zap stuff under rmap locks. File THP is gated on an experimental config flag (CONFIG_READ_ONLY_THP_FOR_FS), so on normal distro kernels you need shmem THP to hit this bug. As far as I know, getting shmem THP normally requires that you can mount your own tmpfs with the right mount flags, which would require creating your own user+mount namespace; though I don't know if some distros maybe enable shmem THP by default or something like that. Bug impact: This issue can likely be used for user->kernel privilege escalation when it is reachable.", "cve_priority": "medium", "cve_public_date": "2024-10-23 06:15:00 UTC" }, { "cve": "CVE-2024-50202", "url": "https://ubuntu.com/security/CVE-2024-50202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: propagate directory read errors from nilfs_find_entry() Syzbot reported that a task hang occurs in vcs_open() during a fuzzing test for nilfs2. The root cause of this problem is that in nilfs_find_entry(), which searches for directory entries, ignores errors when loading a directory page/folio via nilfs_get_folio() fails. If the filesystem images is corrupted, and the i_size of the directory inode is large, and the directory page/folio is successfully read but fails the sanity check, for example when it is zero-filled, nilfs_check_folio() may continue to spit out error messages in bursts. Fix this issue by propagating the error to the callers when loading a page/folio fails in nilfs_find_entry(). The current interface of nilfs_find_entry() and its callers is outdated and cannot propagate error codes such as -EIO and -ENOMEM returned via nilfs_find_entry(), so fix it together.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50200", "url": "https://ubuntu.com/security/CVE-2024-50200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: maple_tree: correct tree corruption on spanning store Patch series \"maple_tree: correct tree corruption on spanning store\", v3. There has been a nasty yet subtle maple tree corruption bug that appears to have been in existence since the inception of the algorithm. This bug seems far more likely to happen since commit f8d112a4e657 (\"mm/mmap: avoid zeroing vma tree in mmap_region()\"), which is the point at which reports started to be submitted concerning this bug. We were made definitely aware of the bug thanks to the kind efforts of Bert Karwatzki who helped enormously in my being able to track this down and identify the cause of it. The bug arises when an attempt is made to perform a spanning store across two leaf nodes, where the right leaf node is the rightmost child of the shared parent, AND the store completely consumes the right-mode node. This results in mas_wr_spanning_store() mitakenly duplicating the new and existing entries at the maximum pivot within the range, and thus maple tree corruption. The fix patch corrects this by detecting this scenario and disallowing the mistaken duplicate copy. The fix patch commit message goes into great detail as to how this occurs. This series also includes a test which reliably reproduces the issue, and asserts that the fix works correctly. Bert has kindly tested the fix and confirmed it resolved his issues. Also Mikhail Gavrilov kindly reported what appears to be precisely the same bug, which this fix should also resolve. This patch (of 2): There has been a subtle bug present in the maple tree implementation from its inception. This arises from how stores are performed - when a store occurs, it will overwrite overlapping ranges and adjust the tree as necessary to accommodate this. A range may always ultimately span two leaf nodes. In this instance we walk the two leaf nodes, determine which elements are not overwritten to the left and to the right of the start and end of the ranges respectively and then rebalance the tree to contain these entries and the newly inserted one. This kind of store is dubbed a 'spanning store' and is implemented by mas_wr_spanning_store(). In order to reach this stage, mas_store_gfp() invokes mas_wr_preallocate(), mas_wr_store_type() and mas_wr_walk() in turn to walk the tree and update the object (mas) to traverse to the location where the write should be performed, determining its store type. When a spanning store is required, this function returns false stopping at the parent node which contains the target range, and mas_wr_store_type() marks the mas->store_type as wr_spanning_store to denote this fact. When we go to perform the store in mas_wr_spanning_store(), we first determine the elements AFTER the END of the range we wish to store (that is, to the right of the entry to be inserted) - we do this by walking to the NEXT pivot in the tree (i.e. r_mas.last + 1), starting at the node we have just determined contains the range over which we intend to write. We then turn our attention to the entries to the left of the entry we are inserting, whose state is represented by l_mas, and copy these into a 'big node', which is a special node which contains enough slots to contain two leaf node's worth of data. We then copy the entry we wish to store immediately after this - the copy and the insertion of the new entry is performed by mas_store_b_node(). After this we copy the elements to the right of the end of the range which we are inserting, if we have not exceeded the length of the node (i.e. r_mas.offset <= r_mas.end). Herein lies the bug - under very specific circumstances, this logic can break and corrupt the maple tree. Consider the following tree: Height 0 Root Node / \\ pivot = 0xffff / \\ pivot = ULONG_MAX / ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50084", "url": "https://ubuntu.com/security/CVE-2024-50084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: microchip: vcap api: Fix memory leaks in vcap_api_encode_rule_test() Commit a3c1e45156ad (\"net: microchip: vcap: Fix use-after-free error in kunit test\") fixed the use-after-free error, but introduced below memory leaks by removing necessary vcap_free_rule(), add it to fix it. \tunreferenced object 0xffffff80ca58b700 (size 192): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898264 \t hex dump (first 32 bytes): \t 00 12 7a 00 05 00 00 00 0a 00 00 00 64 00 00 00 ..z.........d... \t 00 00 00 00 00 00 00 00 00 04 0b cc 80 ff ff ff ................ \t backtrace (crc 9c09c3fe): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<0000000040a01b8d>] vcap_alloc_rule+0x3cc/0x9c4 \t [<000000003fe86110>] vcap_api_encode_rule_test+0x1ac/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0400 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898265 \t hex dump (first 32 bytes): \t 80 04 0b cc 80 ff ff ff 18 b7 58 ca 80 ff ff ff ..........X..... \t 39 00 00 00 02 00 00 00 06 05 04 03 02 01 ff ff 9............... \t backtrace (crc daf014e9): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<00000000dfdb1e81>] vcap_api_encode_rule_test+0x224/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0700 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898265 \t hex dump (first 32 bytes): \t 80 07 0b cc 80 ff ff ff 28 b7 58 ca 80 ff ff ff ........(.X..... \t 3c 00 00 00 00 00 00 00 01 2f 03 b3 ec ff ff ff <......../...... \t backtrace (crc 8d877792): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000006eadfab7>] vcap_rule_add_action+0x2d0/0x52c \t [<00000000323475d1>] vcap_api_encode_rule_test+0x4d4/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0900 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898266 \t hex dump (first 32 bytes): \t 80 09 0b cc 80 ff ff ff 80 06 0b cc 80 ff ff ff ................ \t 7d 00 00 00 01 00 00 00 00 00 00 00 ff 00 00 00 }............... \t backtrace (crc 34181e56): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<00000000991e3564>] vcap_val_rule+0xcf0/0x13e8 \t [<00000000fc9868e5>] vcap_api_encode_rule_test+0x678/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0980 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898266 \t hex dump (first 32 bytes): \t 18 b7 58 ca 80 ff ff ff 00 09 0b cc 80 ff ff ff ..X............. \t 67 00 00 00 00 00 00 00 01 01 74 88 c0 ff ff ff g.........t..... \t backtrace (crc 275fd9be): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<000000001396a1a2>] test_add_de ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50194", "url": "https://ubuntu.com/security/CVE-2024-50194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Fix uprobes for big-endian kernels The arm64 uprobes code is broken for big-endian kernels as it doesn't convert the in-memory instruction encoding (which is always little-endian) into the kernel's native endianness before analyzing and simulating instructions. This may result in a few distinct problems: * The kernel may may erroneously reject probing an instruction which can safely be probed. * The kernel may erroneously erroneously permit stepping an instruction out-of-line when that instruction cannot be stepped out-of-line safely. * The kernel may erroneously simulate instruction incorrectly dur to interpretting the byte-swapped encoding. The endianness mismatch isn't caught by the compiler or sparse because: * The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so the compiler and sparse have no idea these contain a little-endian 32-bit value. The core uprobes code populates these with a memcpy() which similarly does not handle endianness. * While the uprobe_opcode_t type is an alias for __le32, both arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[] to the similarly-named probe_opcode_t, which is an alias for u32. Hence there is no endianness conversion warning. Fix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and adding the appropriate __le32_to_cpu() conversions prior to consuming the instruction encoding. The core uprobes copies these fields as opaque ranges of bytes, and so is unaffected by this change. At the same time, remove MAX_UINSN_BYTES and consistently use AARCH64_INSN_SIZE for clarity. Tested with the following: | #include | #include | | #define noinline __attribute__((noinline)) | | static noinline void *adrp_self(void) | { | void *addr; | | asm volatile( | \" adrp %x0, adrp_self\\n\" | \" add %x0, %x0, :lo12:adrp_self\\n\" | : \"=r\" (addr)); | } | | | int main(int argc, char *argv) | { | void *ptr = adrp_self(); | bool equal = (ptr == adrp_self); | | printf(\"adrp_self => %p\\n\" | \"adrp_self() => %p\\n\" | \"%s\\n\", | adrp_self, ptr, equal ? \"EQUAL\" : \"NOT EQUAL\"); | | return 0; | } .... where the adrp_self() function was compiled to: | 00000000004007e0 : | 4007e0: 90000000 adrp x0, 400000 <__ehdr_start> | 4007e4: 911f8000 add x0, x0, #0x7e0 | 4007e8: d65f03c0 ret Before this patch, the ADRP is not recognized, and is assumed to be steppable, resulting in corruption of the result: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0xffffffffff7e0 | NOT EQUAL After this patch, the ADRP is correctly recognized and simulated: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50099", "url": "https://ubuntu.com/security/CVE-2024-50099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Remove broken LDR (literal) uprobe support The simulate_ldr_literal() and simulate_ldrsw_literal() functions are unsafe to use for uprobes. Both functions were originally written for use with kprobes, and access memory with plain C accesses. When uprobes was added, these were reused unmodified even though they cannot safely access user memory. There are three key problems: 1) The plain C accesses do not have corresponding extable entries, and thus if they encounter a fault the kernel will treat these as unintentional accesses to user memory, resulting in a BUG() which will kill the kernel thread, and likely lead to further issues (e.g. lockup or panic()). 2) The plain C accesses are subject to HW PAN and SW PAN, and so when either is in use, any attempt to simulate an access to user memory will fault. Thus neither simulate_ldr_literal() nor simulate_ldrsw_literal() can do anything useful when simulating a user instruction on any system with HW PAN or SW PAN. 3) The plain C accesses are privileged, as they run in kernel context, and in practice can access a small range of kernel virtual addresses. The instructions they simulate have a range of +/-1MiB, and since the simulated instructions must itself be a user instructions in the TTBR0 address range, these can address the final 1MiB of the TTBR1 acddress range by wrapping downwards from an address in the first 1MiB of the TTBR0 address range. In contemporary kernels the last 8MiB of TTBR1 address range is reserved, and accesses to this will always fault, meaning this is no worse than (1). Historically, it was theoretically possible for the linear map or vmemmap to spill into the final 8MiB of the TTBR1 address range, but in practice this is extremely unlikely to occur as this would require either: * Having enough physical memory to fill the entire linear map all the way to the final 1MiB of the TTBR1 address range. * Getting unlucky with KASLR randomization of the linear map such that the populated region happens to overlap with the last 1MiB of the TTBR address range. ... and in either case if we were to spill into the final page there would be larger problems as the final page would alias with error pointers. Practically speaking, (1) and (2) are the big issues. Given there have been no reports of problems since the broken code was introduced, it appears that no-one is relying on probing these instructions with uprobes. Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW (literal), limiting the use of simulate_ldr_literal() and simulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR (literal) and LDRSW (literal) will be rejected as arm_probe_decode_insn() will return INSN_REJECTED. In future we can consider introducing working uprobes support for these instructions, but this will require more significant work.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50195", "url": "https://ubuntu.com/security/CVE-2024-50195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-clock: Fix missing timespec64 check in pc_clock_settime() As Andrew pointed out, it will make sense that the PTP core checked timespec64 struct's tv_sec and tv_nsec range before calling ptp->info->settime64(). As the man manual of clock_settime() said, if tp.tv_sec is negative or tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL, which include dynamic clocks which handles PTP clock, and the condition is consistent with timespec64_valid(). As Thomas suggested, timespec64_valid() only check the timespec is valid, but not ensure that the time is in a valid range, so check it ahead using timespec64_valid_strict() in pc_clock_settime() and return -EINVAL if not valid. There are some drivers that use tp->tv_sec and tp->tv_nsec directly to write registers without validity checks and assume that the higher layer has checked it, which is dangerous and will benefit from this, such as hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(), and some drivers can remove the checks of itself.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50085", "url": "https://ubuntu.com/security/CVE-2024-50085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: fix UaF read in mptcp_pm_nl_rm_addr_or_subflow Syzkaller reported this splat: ================================================================== BUG: KASAN: slab-use-after-free in mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881 Read of size 4 at addr ffff8880569ac858 by task syz.1.2799/14662 CPU: 0 UID: 0 PID: 14662 Comm: syz.1.2799 Not tainted 6.12.0-rc2-syzkaller-00307-g36c254515dc6 #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+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881 mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:914 [inline] mptcp_nl_remove_id_zero_address+0x305/0x4a0 net/mptcp/pm_netlink.c:1572 mptcp_pm_nl_del_addr_doit+0x5c9/0x770 net/mptcp/pm_netlink.c:1603 genl_family_rcv_msg_doit+0x202/0x2f0 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x565/0x800 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x165/0x410 net/netlink/af_netlink.c:2551 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1331 [inline] netlink_unicast+0x53c/0x7f0 net/netlink/af_netlink.c:1357 netlink_sendmsg+0x8b8/0xd70 net/netlink/af_netlink.c:1901 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg net/socket.c:744 [inline] ____sys_sendmsg+0x9ae/0xb40 net/socket.c:2607 ___sys_sendmsg+0x135/0x1e0 net/socket.c:2661 __sys_sendmsg+0x117/0x1f0 net/socket.c:2690 do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline] __do_fast_syscall_32+0x73/0x120 arch/x86/entry/common.c:386 do_fast_syscall_32+0x32/0x80 arch/x86/entry/common.c:411 entry_SYSENTER_compat_after_hwframe+0x84/0x8e RIP: 0023:0xf7fe4579 Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00 RSP: 002b:00000000f574556c EFLAGS: 00000296 ORIG_RAX: 0000000000000172 RAX: ffffffffffffffda RBX: 000000000000000b RCX: 0000000020000140 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000296 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Allocated by task 5387: 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 kmalloc_noprof include/linux/slab.h:878 [inline] kzalloc_noprof include/linux/slab.h:1014 [inline] subflow_create_ctx+0x87/0x2a0 net/mptcp/subflow.c:1803 subflow_ulp_init+0xc3/0x4d0 net/mptcp/subflow.c:1956 __tcp_set_ulp net/ipv4/tcp_ulp.c:146 [inline] tcp_set_ulp+0x326/0x7f0 net/ipv4/tcp_ulp.c:167 mptcp_subflow_create_socket+0x4ae/0x10a0 net/mptcp/subflow.c:1764 __mptcp_subflow_connect+0x3cc/0x1490 net/mptcp/subflow.c:1592 mptcp_pm_create_subflow_or_signal_addr+0xbda/0x23a0 net/mptcp/pm_netlink.c:642 mptcp_pm_nl_fully_established net/mptcp/pm_netlink.c:650 [inline] mptcp_pm_nl_work+0x3a1/0x4f0 net/mptcp/pm_netlink.c:943 mptcp_worker+0x15a/0x1240 net/mptcp/protocol.c:2777 process_one_work+0x958/0x1b30 kernel/workqueue.c:3229 process_scheduled_works kernel/workqueue.c:3310 [inline] worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/ke ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50086", "url": "https://ubuntu.com/security/CVE-2024-50086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix user-after-free from session log off There is racy issue between smb2 session log off and smb2 session setup. It will cause user-after-free from session log off. This add session_lock when setting SMB2_SESSION_EXPIRED and referece count to session struct not to free session while it is being used.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50087", "url": "https://ubuntu.com/security/CVE-2024-50087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix uninitialized pointer free on read_alloc_one_name() error The function read_alloc_one_name() does not initialize the name field of the passed fscrypt_str struct if kmalloc fails to allocate the corresponding buffer. Thus, it is not guaranteed that fscrypt_str.name is initialized when freeing it. This is a follow-up to the linked patch that fixes the remaining instances of the bug introduced by commit e43eec81c516 (\"btrfs: use struct qstr instead of name and namelen pairs\").", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50088", "url": "https://ubuntu.com/security/CVE-2024-50088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix uninitialized pointer free in add_inode_ref() The add_inode_ref() function does not initialize the \"name\" struct when it is declared. If any of the following calls to \"read_one_inode() returns NULL, \tdir = read_one_inode(root, parent_objectid); \tif (!dir) { \t\tret = -ENOENT; \t\tgoto out; \t} \tinode = read_one_inode(root, inode_objectid); \tif (!inode) { \t\tret = -EIO; \t\tgoto out; \t} then \"name.name\" would be freed on \"out\" before being initialized. out: \t... \tkfree(name.name); This issue was reported by Coverity with CID 1526744.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50182", "url": "https://ubuntu.com/security/CVE-2024-50182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: secretmem: disable memfd_secret() if arch cannot set direct map Return -ENOSYS from memfd_secret() syscall if !can_set_direct_map(). This is the case for example on some arm64 configurations, where marking 4k PTEs in the direct map not present can only be done if the direct map is set up at 4k granularity in the first place (as ARM's break-before-make semantics do not easily allow breaking apart large/gigantic pages). More precisely, on arm64 systems with !can_set_direct_map(), set_direct_map_invalid_noflush() is a no-op, however it returns success (0) instead of an error. This means that memfd_secret will seemingly \"work\" (e.g. syscall succeeds, you can mmap the fd and fault in pages), but it does not actually achieve its goal of removing its memory from the direct map. Note that with this patch, memfd_secret() will start erroring on systems where can_set_direct_map() returns false (arm64 with CONFIG_RODATA_FULL_DEFAULT_ENABLED=n, CONFIG_DEBUG_PAGEALLOC=n and CONFIG_KFENCE=n), but that still seems better than the current silent failure. Since CONFIG_RODATA_FULL_DEFAULT_ENABLED defaults to 'y', most arm64 systems actually have a working memfd_secret() and aren't be affected. From going through the iterations of the original memfd_secret patch series, it seems that disabling the syscall in these scenarios was the intended behavior [1] (preferred over having set_direct_map_invalid_noflush return an error as that would result in SIGBUSes at page-fault time), however the check for it got dropped between v16 [2] and v17 [3], when secretmem moved away from CMA allocations. [1]: https://lore.kernel.org/lkml/20201124164930.GK8537@kernel.org/ [2]: https://lore.kernel.org/lkml/20210121122723.3446-11-rppt@kernel.org/#t [3]: https://lore.kernel.org/lkml/20201125092208.12544-10-rppt@kernel.org/", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50019", "url": "https://ubuntu.com/security/CVE-2024-50019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kthread: unpark only parked kthread Calling into kthread unparking unconditionally is mostly harmless when the kthread is already unparked. The wake up is then simply ignored because the target is not in TASK_PARKED state. However if the kthread is per CPU, the wake up is preceded by a call to kthread_bind() which expects the task to be inactive and in TASK_PARKED state, which obviously isn't the case if it is unparked. As a result, calling kthread_stop() on an unparked per-cpu kthread triggers such a warning: \tWARNING: CPU: 0 PID: 11 at kernel/kthread.c:525 __kthread_bind_mask kernel/kthread.c:525 \t \t kthread_stop+0x17a/0x630 kernel/kthread.c:707 \t destroy_workqueue+0x136/0xc40 kernel/workqueue.c:5810 \t wg_destruct+0x1e2/0x2e0 drivers/net/wireguard/device.c:257 \t netdev_run_todo+0xe1a/0x1000 net/core/dev.c:10693 \t default_device_exit_batch+0xa14/0xa90 net/core/dev.c:11769 \t ops_exit_list net/core/net_namespace.c:178 [inline] \t cleanup_net+0x89d/0xcc0 net/core/net_namespace.c:640 \t process_one_work kernel/workqueue.c:3231 [inline] \t process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 \t worker_thread+0x86d/0xd70 kernel/workqueue.c:3393 \t kthread+0x2f0/0x390 kernel/kthread.c:389 \t ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 \t ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 \t Fix this with skipping unecessary unparking while stopping a kthread.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50096", "url": "https://ubuntu.com/security/CVE-2024-50096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/dmem: Fix vulnerability in migrate_to_ram upon copy error The `nouveau_dmem_copy_one` function ensures that the copy push command is sent to the device firmware but does not track whether it was executed successfully. In the case of a copy error (e.g., firmware or hardware failure), the copy push command will be sent via the firmware channel, and `nouveau_dmem_copy_one` will likely report success, leading to the `migrate_to_ram` function returning a dirty HIGH_USER page to the user. This can result in a security vulnerability, as a HIGH_USER page that may contain sensitive or corrupted data could be returned to the user. To prevent this vulnerability, we allocate a zero page. Thus, in case of an error, a non-dirty (zero) page will be returned to the user.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50020", "url": "https://ubuntu.com/security/CVE-2024-50020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix improper handling of refcount in ice_sriov_set_msix_vec_count() This patch addresses an issue with improper reference count handling in the ice_sriov_set_msix_vec_count() function. First, the function calls ice_get_vf_by_id(), which increments the reference count of the vf pointer. If the subsequent call to ice_get_vf_vsi() fails, the function currently returns an error without decrementing the reference count of the vf pointer, leading to a reference count leak. The correct behavior, as implemented in this patch, is to decrement the reference count using ice_put_vf(vf) before returning an error when vsi is NULL. Second, the function calls ice_sriov_get_irqs(), which sets vf->first_vector_idx. If this call returns a negative value, indicating an error, the function returns an error without decrementing the reference count of the vf pointer, resulting in another reference count leak. The patch addresses this by adding a call to ice_put_vf(vf) before returning an error when vf->first_vector_idx < 0. This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and identifying potential mismanagement of reference counts. In this case, the tool flagged the missing decrement operation as a potential issue, leading to this patch.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50021", "url": "https://ubuntu.com/security/CVE-2024-50021", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix improper handling of refcount in ice_dpll_init_rclk_pins() This patch addresses a reference count handling issue in the ice_dpll_init_rclk_pins() function. The function calls ice_dpll_get_pins(), which increments the reference count of the relevant resources. However, if the condition WARN_ON((!vsi || !vsi->netdev)) is met, the function currently returns an error without properly releasing the resources acquired by ice_dpll_get_pins(), leading to a reference count leak. To resolve this, the check has been moved to the top of the function. This ensures that the function verifies the state before any resources are acquired, avoiding the need for additional resource management in the error path. This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and detecting potential issues where resources are not properly managed. In this case, the tool flagged the missing release operation as a potential problem, which led to the development of this patch.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50022", "url": "https://ubuntu.com/security/CVE-2024-50022", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: device-dax: correct pgoff align in dax_set_mapping() pgoff should be aligned using ALIGN_DOWN() instead of ALIGN(). Otherwise, vmf->address not aligned to fault_size will be aligned to the next alignment, that can result in memory failure getting the wrong address. It's a subtle situation that only can be observed in page_mapped_in_vma() after the page is page fault handled by dev_dax_huge_fault. Generally, there is little chance to perform page_mapped_in_vma in dev-dax's page unless in specific error injection to the dax device to trigger an MCE - memory-failure. In that case, page_mapped_in_vma() will be triggered to determine which task is accessing the failure address and kill that task in the end. We used self-developed dax device (which is 2M aligned mapping) , to perform error injection to random address. It turned out that error injected to non-2M-aligned address was causing endless MCE until panic. Because page_mapped_in_vma() kept resulting wrong address and the task accessing the failure address was never killed properly: [ 3783.719419] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.049006] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.049190] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.448042] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.448186] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.792026] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.792179] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.162502] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.162633] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.461116] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.461247] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.764730] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.764859] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.042128] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.042259] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.464293] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.464423] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.818090] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.818217] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3787.085297] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3787.085424] Memory failure: 0x200c9742: recovery action for dax page: Recovered It took us several weeks to pinpoint this problem,  but we eventually used bpftrace to trace the page fault and mce address and successfully identified the issue. Joao added: ; Likely we never reproduce in production because we always pin : device-dax regions in the region align they provide (Qemu does : similarly with prealloc in hugetlb/file backed memory). I think this : bug requires that we touch *unpinned* device-dax regions unaligned to : the device-dax selected alignment (page size i.e. 4K/2M/1G)", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50185", "url": "https://ubuntu.com/security/CVE-2024-50185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: handle consistently DSS corruption Bugged peer implementation can send corrupted DSS options, consistently hitting a few warning in the data path. Use DEBUG_NET assertions, to avoid the splat on some builds and handle consistently the error, dumping related MIBs and performing fallback and/or reset according to the subflow type.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50023", "url": "https://ubuntu.com/security/CVE-2024-50023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: Remove LED entry from LEDs list on unregister Commit c938ab4da0eb (\"net: phy: Manual remove LEDs to ensure correct ordering\") correctly fixed a problem with using devm_ but missed removing the LED entry from the LEDs list. This cause kernel panic on specific scenario where the port for the PHY is torn down and up and the kmod for the PHY is removed. On setting the port down the first time, the assosiacted LEDs are correctly unregistered. The associated kmod for the PHY is now removed. The kmod is now added again and the port is now put up, the associated LED are registered again. On putting the port down again for the second time after these step, the LED list now have 4 elements. With the first 2 already unregistered previously and the 2 new one registered again. This cause a kernel panic as the first 2 element should have been removed. Fix this by correctly removing the element when LED is unregistered.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50024", "url": "https://ubuntu.com/security/CVE-2024-50024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: Fix an unsafe loop on the list The kernel may crash when deleting a genetlink family if there are still listeners for that family: Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c000000000c080bc] netlink_update_socket_mc+0x3c/0xc0 LR [c000000000c0f764] __netlink_clear_multicast_users+0x74/0xc0 Call Trace: __netlink_clear_multicast_users+0x74/0xc0 genl_unregister_family+0xd4/0x2d0 Change the unsafe loop on the list to a safe one, because inside the loop there is an element removal from this list.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50186", "url": "https://ubuntu.com/security/CVE-2024-50186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: explicitly clear the sk pointer, when pf->create fails We have recently noticed the exact same KASAN splat as in commit 6cd4a78d962b (\"net: do not leave a dangling sk pointer, when socket creation fails\"). The problem is that commit did not fully address the problem, as some pf->create implementations do not use sk_common_release in their error paths. For example, we can use the same reproducer as in the above commit, but changing ping to arping. arping uses AF_PACKET socket and if packet_create fails, it will just sk_free the allocated sk object. While we could chase all the pf->create implementations and make sure they NULL the freed sk object on error from the socket, we can't guarantee future protocols will not make the same mistake. So it is easier to just explicitly NULL the sk pointer upon return from pf->create in __sock_create. We do know that pf->create always releases the allocated sk object on error, so if the pointer is not NULL, it is definitely dangling.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50025", "url": "https://ubuntu.com/security/CVE-2024-50025", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: fnic: Move flush_work initialization out of if block After commit 379a58caa199 (\"scsi: fnic: Move fnic_fnic_flush_tx() to a work queue\"), it can happen that a work item is sent to an uninitialized work queue. This may has the effect that the item being queued is never actually queued, and any further actions depending on it will not proceed. The following warning is observed while the fnic driver is loaded: kernel: WARNING: CPU: 11 PID: 0 at ../kernel/workqueue.c:1524 __queue_work+0x373/0x410 kernel: kernel: queue_work_on+0x3a/0x50 kernel: fnic_wq_copy_cmpl_handler+0x54a/0x730 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: fnic_isr_msix_wq_copy+0x2d/0x60 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: __handle_irq_event_percpu+0x36/0x1a0 kernel: handle_irq_event_percpu+0x30/0x70 kernel: handle_irq_event+0x34/0x60 kernel: handle_edge_irq+0x7e/0x1a0 kernel: __common_interrupt+0x3b/0xb0 kernel: common_interrupt+0x58/0xa0 kernel: It has been observed that this may break the rediscovery of Fibre Channel devices after a temporary fabric failure. This patch fixes it by moving the work queue initialization out of an if block in fnic_probe().", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50026", "url": "https://ubuntu.com/security/CVE-2024-50026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: wd33c93: Don't use stale scsi_pointer value A regression was introduced with commit dbb2da557a6a (\"scsi: wd33c93: Move the SCSI pointer to private command data\") which results in an oops in wd33c93_intr(). That commit added the scsi_pointer variable and initialized it from hostdata->connected. However, during selection, hostdata->connected is not yet valid. Fix this by getting the current scsi_pointer from hostdata->selecting.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50027", "url": "https://ubuntu.com/security/CVE-2024-50027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: core: Free tzp copy along with the thermal zone The object pointed to by tz->tzp may still be accessed after being freed in thermal_zone_device_unregister(), so move the freeing of it to the point after the removal completion has been completed at which it cannot be accessed any more.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50028", "url": "https://ubuntu.com/security/CVE-2024-50028", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: core: Reference count the zone in thermal_zone_get_by_id() There are places in the thermal netlink code where nothing prevents the thermal zone object from going away while being accessed after it has been returned by thermal_zone_get_by_id(). To address this, make thermal_zone_get_by_id() get a reference on the thermal zone device object to be returned with the help of get_device(), under thermal_list_lock, and adjust all of its callers to this change with the help of the cleanup.h infrastructure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50029", "url": "https://ubuntu.com/security/CVE-2024-50029", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_conn: Fix UAF in hci_enhanced_setup_sync This checks if the ACL connection remains valid as it could be destroyed while hci_enhanced_setup_sync is pending on cmd_sync leading to the following trace: BUG: KASAN: slab-use-after-free in hci_enhanced_setup_sync+0x91b/0xa60 Read of size 1 at addr ffff888002328ffd by task kworker/u5:2/37 CPU: 0 UID: 0 PID: 37 Comm: kworker/u5:2 Not tainted 6.11.0-rc6-01300-g810be445d8d6 #7099 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Workqueue: hci0 hci_cmd_sync_work Call Trace: dump_stack_lvl+0x5d/0x80 ? hci_enhanced_setup_sync+0x91b/0xa60 print_report+0x152/0x4c0 ? hci_enhanced_setup_sync+0x91b/0xa60 ? __virt_addr_valid+0x1fa/0x420 ? hci_enhanced_setup_sync+0x91b/0xa60 kasan_report+0xda/0x1b0 ? hci_enhanced_setup_sync+0x91b/0xa60 hci_enhanced_setup_sync+0x91b/0xa60 ? __pfx_hci_enhanced_setup_sync+0x10/0x10 ? __pfx___mutex_lock+0x10/0x10 hci_cmd_sync_work+0x1c2/0x330 process_one_work+0x7d9/0x1360 ? __pfx_lock_acquire+0x10/0x10 ? __pfx_process_one_work+0x10/0x10 ? assign_work+0x167/0x240 worker_thread+0x5b7/0xf60 ? __kthread_parkme+0xac/0x1c0 ? __pfx_worker_thread+0x10/0x10 ? __pfx_worker_thread+0x10/0x10 kthread+0x293/0x360 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2f/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 34: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __hci_conn_add+0x187/0x17d0 hci_connect_sco+0x2e1/0xb90 sco_sock_connect+0x2a2/0xb80 __sys_connect+0x227/0x2a0 __x64_sys_connect+0x6d/0xb0 do_syscall_64+0x71/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 37: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x101/0x160 kfree+0xd0/0x250 device_release+0x9a/0x210 kobject_put+0x151/0x280 hci_conn_del+0x448/0xbf0 hci_abort_conn_sync+0x46f/0x980 hci_cmd_sync_work+0x1c2/0x330 process_one_work+0x7d9/0x1360 worker_thread+0x5b7/0xf60 kthread+0x293/0x360 ret_from_fork+0x2f/0x70 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50030", "url": "https://ubuntu.com/security/CVE-2024-50030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/ct: prevent UAF in send_recv() Ensure we serialize with completion side to prevent UAF with fence going out of scope on the stack, since we have no clue if it will fire after the timeout before we can erase from the xa. Also we have some dependent loads and stores for which we need the correct ordering, and we lack the needed barriers. Fix this by grabbing the ct->lock after the wait, which is also held by the completion side. v2 (Badal): - Also print done after acquiring the lock and seeing timeout. (cherry picked from commit 52789ce35c55ccd30c4b67b9cc5b2af55e0122ea)", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50187", "url": "https://ubuntu.com/security/CVE-2024-50187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Stop the active perfmon before being destroyed Upon closing the file descriptor, the active performance monitor is not stopped. Although all perfmons are destroyed in `vc4_perfmon_close_file()`, the active performance monitor's pointer (`vc4->active_perfmon`) is still retained. If we open a new file descriptor and submit a few jobs with performance monitors, the driver will attempt to stop the active performance monitor using the stale pointer in `vc4->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50031", "url": "https://ubuntu.com/security/CVE-2024-50031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Stop the active perfmon before being destroyed When running `kmscube` with one or more performance monitors enabled via `GALLIUM_HUD`, the following kernel panic can occur: [ 55.008324] Unable to handle kernel paging request at virtual address 00000000052004a4 [ 55.008368] Mem abort info: [ 55.008377] ESR = 0x0000000096000005 [ 55.008387] EC = 0x25: DABT (current EL), IL = 32 bits [ 55.008402] SET = 0, FnV = 0 [ 55.008412] EA = 0, S1PTW = 0 [ 55.008421] FSC = 0x05: level 1 translation fault [ 55.008434] Data abort info: [ 55.008442] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 55.008455] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 55.008467] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 55.008481] user pgtable: 4k pages, 39-bit VAs, pgdp=00000001046c6000 [ 55.008497] [00000000052004a4] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 55.008525] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP [ 55.008542] Modules linked in: rfcomm [...] vc4 v3d snd_soc_hdmi_codec drm_display_helper gpu_sched drm_shmem_helper cec drm_dma_helper drm_kms_helper i2c_brcmstb drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight [ 55.008799] CPU: 2 PID: 166 Comm: v3d_bin Tainted: G C 6.6.47+rpt-rpi-v8 #1 Debian 1:6.6.47-1+rpt1 [ 55.008824] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [ 55.008838] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 55.008855] pc : __mutex_lock.constprop.0+0x90/0x608 [ 55.008879] lr : __mutex_lock.constprop.0+0x58/0x608 [ 55.008895] sp : ffffffc080673cf0 [ 55.008904] x29: ffffffc080673cf0 x28: 0000000000000000 x27: ffffff8106188a28 [ 55.008926] x26: ffffff8101e78040 x25: ffffff8101baa6c0 x24: ffffffd9d989f148 [ 55.008947] x23: ffffffda1c2a4008 x22: 0000000000000002 x21: ffffffc080673d38 [ 55.008968] x20: ffffff8101238000 x19: ffffff8104f83188 x18: 0000000000000000 [ 55.008988] x17: 0000000000000000 x16: ffffffda1bd04d18 x15: 00000055bb08bc90 [ 55.009715] x14: 0000000000000000 x13: 0000000000000000 x12: ffffffda1bd4cbb0 [ 55.010433] x11: 00000000fa83b2da x10: 0000000000001a40 x9 : ffffffda1bd04d04 [ 55.011162] x8 : ffffff8102097b80 x7 : 0000000000000000 x6 : 00000000030a5857 [ 55.011880] x5 : 00ffffffffffffff x4 : 0300000005200470 x3 : 0300000005200470 [ 55.012598] x2 : ffffff8101238000 x1 : 0000000000000021 x0 : 0300000005200470 [ 55.013292] Call trace: [ 55.013959] __mutex_lock.constprop.0+0x90/0x608 [ 55.014646] __mutex_lock_slowpath+0x1c/0x30 [ 55.015317] mutex_lock+0x50/0x68 [ 55.015961] v3d_perfmon_stop+0x40/0xe0 [v3d] [ 55.016627] v3d_bin_job_run+0x10c/0x2d8 [v3d] [ 55.017282] drm_sched_main+0x178/0x3f8 [gpu_sched] [ 55.017921] kthread+0x11c/0x128 [ 55.018554] ret_from_fork+0x10/0x20 [ 55.019168] Code: f9400260 f1001c1f 54001ea9 927df000 (b9403401) [ 55.019776] ---[ end trace 0000000000000000 ]--- [ 55.020411] note: v3d_bin[166] exited with preempt_count 1 This issue arises because, upon closing the file descriptor (which happens when we interrupt `kmscube`), the active performance monitor is not stopped. Although all perfmons are destroyed in `v3d_perfmon_close_file()`, the active performance monitor's pointer (`v3d->active_perfmon`) is still retained. If `kmscube` is run again, the driver will attempt to stop the active performance monitor using the stale pointer in `v3d->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50189", "url": "https://ubuntu.com/security/CVE-2024-50189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: amd_sfh: Switch to device-managed dmam_alloc_coherent() Using the device-managed version allows to simplify clean-up in probe() error path. Additionally, this device-managed ensures proper cleanup, which helps to resolve memory errors, page faults, btrfs going read-only, and btrfs disk corruption.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50033", "url": "https://ubuntu.com/security/CVE-2024-50033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slip: make slhc_remember() more robust against malicious packets syzbot found that slhc_remember() was missing checks against malicious packets [1]. slhc_remember() only checked the size of the packet was at least 20, which is not good enough. We need to make sure the packet includes the IPv4 and TCP header that are supposed to be carried. Add iph and th pointers to make the code more readable. [1] BUG: KMSAN: uninit-value in slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 ppp_receive_nonmp_frame+0xe45/0x35e0 drivers/net/ppp/ppp_generic.c:2455 ppp_receive_frame drivers/net/ppp/ppp_generic.c:2372 [inline] ppp_do_recv+0x65f/0x40d0 drivers/net/ppp/ppp_generic.c:2212 ppp_input+0x7dc/0xe60 drivers/net/ppp/ppp_generic.c:2327 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 Uninit was created at: slab_post_alloc_hook mm/slub.c:4091 [inline] slab_alloc_node mm/slub.c:4134 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 CPU: 0 UID: 0 PID: 5460 Comm: syz.2.33 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50034", "url": "https://ubuntu.com/security/CVE-2024-50034", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix lacks of icsk_syn_mss with IPPROTO_SMC Eric report a panic on IPPROTO_SMC, and give the facts that when INET_PROTOSW_ICSK was set, icsk->icsk_sync_mss must be set too. Bug: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000086000005 EC = 0x21: IABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault user pgtable: 4k pages, 48-bit VAs, pgdp=00000001195d1000 [0000000000000000] pgd=0800000109c46003, p4d=0800000109c46003, pud=0000000000000000 Internal error: Oops: 0000000086000005 [#1] PREEMPT SMP Modules linked in: CPU: 1 UID: 0 PID: 8037 Comm: syz.3.265 Not tainted 6.11.0-rc7-syzkaller-g5f5673607153 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0x0 lr : cipso_v4_sock_setattr+0x2a8/0x3c0 net/ipv4/cipso_ipv4.c:1910 sp : ffff80009b887a90 x29: ffff80009b887aa0 x28: ffff80008db94050 x27: 0000000000000000 x26: 1fffe0001aa6f5b3 x25: dfff800000000000 x24: ffff0000db75da00 x23: 0000000000000000 x22: ffff0000d8b78518 x21: 0000000000000000 x20: ffff0000d537ad80 x19: ffff0000d8b78000 x18: 1fffe000366d79ee x17: ffff8000800614a8 x16: ffff800080569b84 x15: 0000000000000001 x14: 000000008b336894 x13: 00000000cd96feaa x12: 0000000000000003 x11: 0000000000040000 x10: 00000000000020a3 x9 : 1fffe0001b16f0f1 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 000000000000003f x5 : 0000000000000040 x4 : 0000000000000001 x3 : 0000000000000000 x2 : 0000000000000002 x1 : 0000000000000000 x0 : ffff0000d8b78000 Call trace: 0x0 netlbl_sock_setattr+0x2e4/0x338 net/netlabel/netlabel_kapi.c:1000 smack_netlbl_add+0xa4/0x154 security/smack/smack_lsm.c:2593 smack_socket_post_create+0xa8/0x14c security/smack/smack_lsm.c:2973 security_socket_post_create+0x94/0xd4 security/security.c:4425 __sock_create+0x4c8/0x884 net/socket.c:1587 sock_create net/socket.c:1622 [inline] __sys_socket_create net/socket.c:1659 [inline] __sys_socket+0x134/0x340 net/socket.c:1706 __do_sys_socket net/socket.c:1720 [inline] __se_sys_socket net/socket.c:1718 [inline] __arm64_sys_socket+0x7c/0x94 net/socket.c:1718 __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:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 Code: ???????? ???????? ???????? ???????? (????????) ---[ end trace 0000000000000000 ]--- This patch add a toy implementation that performs a simple return to prevent such panic. This is because MSS can be set in sock_create_kern or smc_setsockopt, similar to how it's done in AF_SMC. However, for AF_SMC, there is currently no way to synchronize MSS within __sys_connect_file. This toy implementation lays the groundwork for us to support such feature for IPPROTO_SMC in the future.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50035", "url": "https://ubuntu.com/security/CVE-2024-50035", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: fix ppp_async_encode() illegal access syzbot reported an issue in ppp_async_encode() [1] In this case, pppoe_sendmsg() is called with a zero size. Then ppp_async_encode() is called with an empty skb. BUG: KMSAN: uninit-value in ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] BUG: KMSAN: uninit-value in ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_send+0x130/0x1b0 drivers/net/ppp/ppp_async.c:634 ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2280 [inline] ppp_input+0x1f1/0xe60 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 Uninit was created at: slab_post_alloc_hook mm/slub.c:4092 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4187 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 CPU: 1 UID: 0 PID: 5411 Comm: syz.1.14 Not tainted 6.12.0-rc1-syzkaller-00165-g360c1f1f24c6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50036", "url": "https://ubuntu.com/security/CVE-2024-50036", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: do not delay dst_entries_add() in dst_release() dst_entries_add() uses per-cpu data that might be freed at netns dismantle from ip6_route_net_exit() calling dst_entries_destroy() Before ip6_route_net_exit() can be called, we release all the dsts associated with this netns, via calls to dst_release(), which waits an rcu grace period before calling dst_destroy() dst_entries_add() use in dst_destroy() is racy, because dst_entries_destroy() could have been called already. Decrementing the number of dsts must happen sooner. Notes: 1) in CONFIG_XFRM case, dst_destroy() can call dst_release_immediate(child), this might also cause UAF if the child does not have DST_NOCOUNT set. IPSEC maintainers might take a look and see how to address this. 2) There is also discussion about removing this count of dst, which might happen in future kernels.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50037", "url": "https://ubuntu.com/security/CVE-2024-50037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/fbdev-dma: Only cleanup deferred I/O if necessary Commit 5a498d4d06d6 (\"drm/fbdev-dma: Only install deferred I/O if necessary\") initializes deferred I/O only if it is used. drm_fbdev_dma_fb_destroy() however calls fb_deferred_io_cleanup() unconditionally with struct fb_info.fbdefio == NULL. KASAN with the out-of-tree Apple silicon display driver posts following warning from __flush_work() of a random struct work_struct instead of the expected NULL pointer derefs. [ 22.053799] ------------[ cut here ]------------ [ 22.054832] WARNING: CPU: 2 PID: 1 at kernel/workqueue.c:4177 __flush_work+0x4d8/0x580 [ 22.056597] Modules linked in: uhid bnep uinput nls_ascii ip6_tables ip_tables i2c_dev loop fuse dm_multipath nfnetlink zram hid_magicmouse btrfs xor xor_neon brcmfmac_wcc raid6_pq hci_bcm4377 bluetooth brcmfmac hid_apple brcmutil nvmem_spmi_mfd simple_mfd_spmi dockchannel_hid cfg80211 joydev regmap_spmi nvme_apple ecdh_generic ecc macsmc_hid rfkill dwc3 appledrm snd_soc_macaudio macsmc_power nvme_core apple_isp phy_apple_atc apple_sart apple_rtkit_helper apple_dockchannel tps6598x macsmc_hwmon snd_soc_cs42l84 videobuf2_v4l2 spmi_apple_controller nvmem_apple_efuses videobuf2_dma_sg apple_z2 videobuf2_memops spi_nor panel_summit videobuf2_common asahi videodev pwm_apple apple_dcp snd_soc_apple_mca apple_admac spi_apple clk_apple_nco i2c_pasemi_platform snd_pcm_dmaengine mc i2c_pasemi_core mux_core ofpart adpdrm drm_dma_helper apple_dart apple_soc_cpufreq leds_pwm phram [ 22.073768] CPU: 2 UID: 0 PID: 1 Comm: systemd-shutdow Not tainted 6.11.2-asahi+ #asahi-dev [ 22.075612] Hardware name: Apple MacBook Pro (13-inch, M2, 2022) (DT) [ 22.077032] pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 22.078567] pc : __flush_work+0x4d8/0x580 [ 22.079471] lr : __flush_work+0x54/0x580 [ 22.080345] sp : ffffc000836ef820 [ 22.081089] x29: ffffc000836ef880 x28: 0000000000000000 x27: ffff80002ddb7128 [ 22.082678] x26: dfffc00000000000 x25: 1ffff000096f0c57 x24: ffffc00082d3e358 [ 22.084263] x23: ffff80004b7862b8 x22: dfffc00000000000 x21: ffff80005aa1d470 [ 22.085855] x20: ffff80004b786000 x19: ffff80004b7862a0 x18: 0000000000000000 [ 22.087439] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000005 [ 22.089030] x14: 1ffff800106ddf0a x13: 0000000000000000 x12: 0000000000000000 [ 22.090618] x11: ffffb800106ddf0f x10: dfffc00000000000 x9 : 1ffff800106ddf0e [ 22.092206] x8 : 0000000000000000 x7 : aaaaaaaaaaaaaaaa x6 : 0000000000000001 [ 22.093790] x5 : ffffc000836ef728 x4 : 0000000000000000 x3 : 0000000000000020 [ 22.095368] x2 : 0000000000000008 x1 : 00000000000000aa x0 : 0000000000000000 [ 22.096955] Call trace: [ 22.097505] __flush_work+0x4d8/0x580 [ 22.098330] flush_delayed_work+0x80/0xb8 [ 22.099231] fb_deferred_io_cleanup+0x3c/0x130 [ 22.100217] drm_fbdev_dma_fb_destroy+0x6c/0xe0 [drm_dma_helper] [ 22.101559] unregister_framebuffer+0x210/0x2f0 [ 22.102575] drm_fb_helper_unregister_info+0x48/0x60 [ 22.103683] drm_fbdev_dma_client_unregister+0x4c/0x80 [drm_dma_helper] [ 22.105147] drm_client_dev_unregister+0x1cc/0x230 [ 22.106217] drm_dev_unregister+0x58/0x570 [ 22.107125] apple_drm_unbind+0x50/0x98 [appledrm] [ 22.108199] component_del+0x1f8/0x3a8 [ 22.109042] dcp_platform_shutdown+0x24/0x38 [apple_dcp] [ 22.110357] platform_shutdown+0x70/0x90 [ 22.111219] device_shutdown+0x368/0x4d8 [ 22.112095] kernel_restart+0x6c/0x1d0 [ 22.112946] __arm64_sys_reboot+0x1c8/0x328 [ 22.113868] invoke_syscall+0x78/0x1a8 [ 22.114703] do_el0_svc+0x124/0x1a0 [ 22.115498] el0_svc+0x3c/0xe0 [ 22.116181] el0t_64_sync_handler+0x70/0xc0 [ 22.117110] el0t_64_sync+0x190/0x198 [ 22.117931] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50092", "url": "https://ubuntu.com/security/CVE-2024-50092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netconsole: fix wrong warning A warning is triggered when there is insufficient space in the buffer for userdata. However, this is not an issue since userdata will be sent in the next iteration. Current warning message: ------------[ cut here ]------------ WARNING: CPU: 13 PID: 3013042 at drivers/net/netconsole.c:1122 write_ext_msg+0x3b6/0x3d0 ? write_ext_msg+0x3b6/0x3d0 console_flush_all+0x1e9/0x330 The code incorrectly issues a warning when this_chunk is zero, which is a valid scenario. The warning should only be triggered when this_chunk is negative.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50038", "url": "https://ubuntu.com/security/CVE-2024-50038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xtables: avoid NFPROTO_UNSPEC where needed syzbot managed to call xt_cluster match via ebtables: WARNING: CPU: 0 PID: 11 at net/netfilter/xt_cluster.c:72 xt_cluster_mt+0x196/0x780 [..] ebt_do_table+0x174b/0x2a40 Module registers to NFPROTO_UNSPEC, but it assumes ipv4/ipv6 packet processing. As this is only useful to restrict locally terminating TCP/UDP traffic, register this for ipv4 and ipv6 family only. Pablo points out that this is a general issue, direct users of the set/getsockopt interface can call into targets/matches that were only intended for use with ip(6)tables. Check all UNSPEC matches and targets for similar issues: - matches and targets are fine except if they assume skb_network_header() is valid -- this is only true when called from inet layer: ip(6) stack pulls the ip/ipv6 header into linear data area. - targets that return XT_CONTINUE or other xtables verdicts must be restricted too, they are incompatbile with the ebtables traverser, e.g. EBT_CONTINUE is a completely different value than XT_CONTINUE. Most matches/targets are changed to register for NFPROTO_IPV4/IPV6, as they are provided for use by ip(6)tables. The MARK target is also used by arptables, so register for NFPROTO_ARP too. While at it, bail out if connbytes fails to enable the corresponding conntrack family. This change passes the selftests in iptables.git.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50039", "url": "https://ubuntu.com/security/CVE-2024-50039", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: accept TCA_STAB only for root qdisc Most qdiscs maintain their backlog using qdisc_pkt_len(skb) on the assumption it is invariant between the enqueue() and dequeue() handlers. Unfortunately syzbot can crash a host rather easily using a TBF + SFQ combination, with an STAB on SFQ [1] We can't support TCA_STAB on arbitrary level, this would require to maintain per-qdisc storage. [1] [ 88.796496] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 88.798611] #PF: supervisor read access in kernel mode [ 88.799014] #PF: error_code(0x0000) - not-present page [ 88.799506] PGD 0 P4D 0 [ 88.799829] Oops: Oops: 0000 [#1] SMP NOPTI [ 88.800569] CPU: 14 UID: 0 PID: 2053 Comm: b371744477 Not tainted 6.12.0-rc1-virtme #1117 [ 88.801107] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 88.801779] RIP: 0010:sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq [ 88.802544] Code: 0f b7 50 12 48 8d 04 d5 00 00 00 00 48 89 d6 48 29 d0 48 8b 91 c0 01 00 00 48 c1 e0 03 48 01 c2 66 83 7a 1a 00 7e c0 48 8b 3a <4c> 8b 07 4c 89 02 49 89 50 08 48 c7 47 08 00 00 00 00 48 c7 07 00 All code ======== 0:\t0f b7 50 12 \tmovzwl 0x12(%rax),%edx 4:\t48 8d 04 d5 00 00 00 \tlea 0x0(,%rdx,8),%rax b:\t00 c:\t48 89 d6 \tmov %rdx,%rsi f:\t48 29 d0 \tsub %rdx,%rax 12:\t48 8b 91 c0 01 00 00 \tmov 0x1c0(%rcx),%rdx 19:\t48 c1 e0 03 \tshl $0x3,%rax 1d:\t48 01 c2 \tadd %rax,%rdx 20:\t66 83 7a 1a 00 \tcmpw $0x0,0x1a(%rdx) 25:\t7e c0 \tjle 0xffffffffffffffe7 27:\t48 8b 3a \tmov (%rdx),%rdi 2a:*\t4c 8b 07 \tmov (%rdi),%r8\t\t<-- trapping instruction 2d:\t4c 89 02 \tmov %r8,(%rdx) 30:\t49 89 50 08 \tmov %rdx,0x8(%r8) 34:\t48 c7 47 08 00 00 00 \tmovq $0x0,0x8(%rdi) 3b:\t00 3c:\t48 \trex.W 3d:\tc7 \t.byte 0xc7 3e:\t07 \t(bad) \t... Code starting with the faulting instruction =========================================== 0:\t4c 8b 07 \tmov (%rdi),%r8 3:\t4c 89 02 \tmov %r8,(%rdx) 6:\t49 89 50 08 \tmov %rdx,0x8(%r8) a:\t48 c7 47 08 00 00 00 \tmovq $0x0,0x8(%rdi) 11:\t00 12:\t48 \trex.W 13:\tc7 \t.byte 0xc7 14:\t07 \t(bad) \t... [ 88.803721] RSP: 0018:ffff9a1f892b7d58 EFLAGS: 00000206 [ 88.804032] RAX: 0000000000000000 RBX: ffff9a1f8420c800 RCX: ffff9a1f8420c800 [ 88.804560] RDX: ffff9a1f81bc1440 RSI: 0000000000000000 RDI: 0000000000000000 [ 88.805056] RBP: ffffffffc04bb0e0 R08: 0000000000000001 R09: 00000000ff7f9a1f [ 88.805473] R10: 000000000001001b R11: 0000000000009a1f R12: 0000000000000140 [ 88.806194] R13: 0000000000000001 R14: ffff9a1f886df400 R15: ffff9a1f886df4ac [ 88.806734] FS: 00007f445601a740(0000) GS:ffff9a2e7fd80000(0000) knlGS:0000000000000000 [ 88.807225] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 88.807672] CR2: 0000000000000000 CR3: 000000050cc46000 CR4: 00000000000006f0 [ 88.808165] Call Trace: [ 88.808459] [ 88.808710] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434) [ 88.809261] ? page_fault_oops (arch/x86/mm/fault.c:715) [ 88.809561] ? exc_page_fault (./arch/x86/include/asm/irqflags.h:26 ./arch/x86/include/asm/irqflags.h:87 ./arch/x86/include/asm/irqflags.h:147 arch/x86/mm/fault.c:1489 arch/x86/mm/fault.c:1539) [ 88.809806] ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623) [ 88.810074] ? sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq [ 88.810411] sfq_reset (net/sched/sch_sfq.c:525) sch_sfq [ 88.810671] qdisc_reset (./include/linux/skbuff.h:2135 ./include/linux/skbuff.h:2441 ./include/linux/skbuff.h:3304 ./include/linux/skbuff.h:3310 net/sched/sch_g ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50040", "url": "https://ubuntu.com/security/CVE-2024-50040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: igb: Do not bring the device up after non-fatal error Commit 004d25060c78 (\"igb: Fix igb_down hung on surprise removal\") changed igb_io_error_detected() to ignore non-fatal pcie errors in order to avoid hung task that can happen when igb_down() is called multiple times. This caused an issue when processing transient non-fatal errors. igb_io_resume(), which is called after igb_io_error_detected(), assumes that device is brought down by igb_io_error_detected() if the interface is up. This resulted in panic with stacktrace below. [ T3256] igb 0000:09:00.0 haeth0: igb: haeth0 NIC Link is Down [ T292] pcieport 0000:00:1c.5: AER: Uncorrected (Non-Fatal) error received: 0000:09:00.0 [ T292] igb 0000:09:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, (Requester ID) [ T292] igb 0000:09:00.0: device [8086:1537] error status/mask=00004000/00000000 [ T292] igb 0000:09:00.0: [14] CmpltTO [ 200.105524,009][ T292] igb 0000:09:00.0: AER: TLP Header: 00000000 00000000 00000000 00000000 [ T292] pcieport 0000:00:1c.5: AER: broadcast error_detected message [ T292] igb 0000:09:00.0: Non-correctable non-fatal error reported. [ T292] pcieport 0000:00:1c.5: AER: broadcast mmio_enabled message [ T292] pcieport 0000:00:1c.5: AER: broadcast resume message [ T292] ------------[ cut here ]------------ [ T292] kernel BUG at net/core/dev.c:6539! [ T292] invalid opcode: 0000 [#1] PREEMPT SMP [ T292] RIP: 0010:napi_enable+0x37/0x40 [ T292] Call Trace: [ T292] [ T292] ? die+0x33/0x90 [ T292] ? do_trap+0xdc/0x110 [ T292] ? napi_enable+0x37/0x40 [ T292] ? do_error_trap+0x70/0xb0 [ T292] ? napi_enable+0x37/0x40 [ T292] ? napi_enable+0x37/0x40 [ T292] ? exc_invalid_op+0x4e/0x70 [ T292] ? napi_enable+0x37/0x40 [ T292] ? asm_exc_invalid_op+0x16/0x20 [ T292] ? napi_enable+0x37/0x40 [ T292] igb_up+0x41/0x150 [ T292] igb_io_resume+0x25/0x70 [ T292] report_resume+0x54/0x70 [ T292] ? report_frozen_detected+0x20/0x20 [ T292] pci_walk_bus+0x6c/0x90 [ T292] ? aer_print_port_info+0xa0/0xa0 [ T292] pcie_do_recovery+0x22f/0x380 [ T292] aer_process_err_devices+0x110/0x160 [ T292] aer_isr+0x1c1/0x1e0 [ T292] ? disable_irq_nosync+0x10/0x10 [ T292] irq_thread_fn+0x1a/0x60 [ T292] irq_thread+0xe3/0x1a0 [ T292] ? irq_set_affinity_notifier+0x120/0x120 [ T292] ? irq_affinity_notify+0x100/0x100 [ T292] kthread+0xe2/0x110 [ T292] ? kthread_complete_and_exit+0x20/0x20 [ T292] ret_from_fork+0x2d/0x50 [ T292] ? kthread_complete_and_exit+0x20/0x20 [ T292] ret_from_fork_asm+0x11/0x20 [ T292] To fix this issue igb_io_resume() checks if the interface is running and the device is not down this means igb_io_error_detected() did not bring the device down and there is no need to bring it up.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50041", "url": "https://ubuntu.com/security/CVE-2024-50041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: Fix macvlan leak by synchronizing access to mac_filter_hash This patch addresses a macvlan leak issue in the i40e driver caused by concurrent access to vsi->mac_filter_hash. The leak occurs when multiple threads attempt to modify the mac_filter_hash simultaneously, leading to inconsistent state and potential memory leaks. To fix this, we now wrap the calls to i40e_del_mac_filter() and zeroing vf->default_lan_addr.addr with spin_lock/unlock_bh(&vsi->mac_filter_hash_lock), ensuring atomic operations and preventing concurrent access. Additionally, we add lockdep_assert_held(&vsi->mac_filter_hash_lock) in i40e_add_mac_filter() to help catch similar issues in the future. Reproduction steps: 1. Spawn VFs and configure port vlan on them. 2. Trigger concurrent macvlan operations (e.g., adding and deleting \tportvlan and/or mac filters). 3. Observe the potential memory leak and inconsistent state in the \tmac_filter_hash. This synchronization ensures the integrity of the mac_filter_hash and prevents the described leak.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50042", "url": "https://ubuntu.com/security/CVE-2024-50042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix increasing MSI-X on VF Increasing MSI-X value on a VF leads to invalid memory operations. This is caused by not reallocating some arrays. Reproducer: modprobe ice echo 0 > /sys/bus/pci/devices/$PF_PCI/sriov_drivers_autoprobe echo 1 > /sys/bus/pci/devices/$PF_PCI/sriov_numvfs echo 17 > /sys/bus/pci/devices/$VF0_PCI/sriov_vf_msix_count Default MSI-X is 16, so 17 and above triggers this issue. KASAN reports: BUG: KASAN: slab-out-of-bounds in ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] Read of size 8 at addr ffff8888b937d180 by task bash/28433 (...) Call Trace: (...) ? ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] kasan_report+0xed/0x120 ? ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] ice_vsi_cfg_def+0x3360/0x4770 [ice] ? mutex_unlock+0x83/0xd0 ? __pfx_ice_vsi_cfg_def+0x10/0x10 [ice] ? __pfx_ice_remove_vsi_lkup_fltr+0x10/0x10 [ice] ice_vsi_cfg+0x7f/0x3b0 [ice] ice_vf_reconfig_vsi+0x114/0x210 [ice] ice_sriov_set_msix_vec_count+0x3d0/0x960 [ice] sriov_vf_msix_count_store+0x21c/0x300 (...) Allocated by task 28201: (...) ice_vsi_cfg_def+0x1c8e/0x4770 [ice] ice_vsi_cfg+0x7f/0x3b0 [ice] ice_vsi_setup+0x179/0xa30 [ice] ice_sriov_configure+0xcaa/0x1520 [ice] sriov_numvfs_store+0x212/0x390 (...) To fix it, use ice_vsi_rebuild() instead of ice_vf_reconfig_vsi(). This causes the required arrays to be reallocated taking the new queue count into account (ice_vsi_realloc_stat_arrays()). Set req_txq and req_rxq before ice_vsi_rebuild(), so that realloc uses the newly set queue count. Additionally, ice_vsi_rebuild() does not remove VSI filters (ice_fltr_remove_all()), so ice_vf_init_host_cfg() is no longer necessary.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50093", "url": "https://ubuntu.com/security/CVE-2024-50093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: intel: int340x: processor: Fix warning during module unload The processor_thermal driver uses pcim_device_enable() to enable a PCI device, which means the device will be automatically disabled on driver detach. Thus there is no need to call pci_disable_device() again on it. With recent PCI device resource management improvements, e.g. commit f748a07a0b64 (\"PCI: Remove legacy pcim_release()\"), this problem is exposed and triggers the warining below. [ 224.010735] proc_thermal_pci 0000:00:04.0: disabling already-disabled device [ 224.010747] WARNING: CPU: 8 PID: 4442 at drivers/pci/pci.c:2250 pci_disable_device+0xe5/0x100 ... [ 224.010844] Call Trace: [ 224.010845] [ 224.010847] ? show_regs+0x6d/0x80 [ 224.010851] ? __warn+0x8c/0x140 [ 224.010854] ? pci_disable_device+0xe5/0x100 [ 224.010856] ? report_bug+0x1c9/0x1e0 [ 224.010859] ? handle_bug+0x46/0x80 [ 224.010862] ? exc_invalid_op+0x1d/0x80 [ 224.010863] ? asm_exc_invalid_op+0x1f/0x30 [ 224.010867] ? pci_disable_device+0xe5/0x100 [ 224.010869] ? pci_disable_device+0xe5/0x100 [ 224.010871] ? kfree+0x21a/0x2b0 [ 224.010873] pcim_disable_device+0x20/0x30 [ 224.010875] devm_action_release+0x16/0x20 [ 224.010878] release_nodes+0x47/0xc0 [ 224.010880] devres_release_all+0x9f/0xe0 [ 224.010883] device_unbind_cleanup+0x12/0x80 [ 224.010885] device_release_driver_internal+0x1ca/0x210 [ 224.010887] driver_detach+0x4e/0xa0 [ 224.010889] bus_remove_driver+0x6f/0xf0 [ 224.010890] driver_unregister+0x35/0x60 [ 224.010892] pci_unregister_driver+0x44/0x90 [ 224.010894] proc_thermal_pci_driver_exit+0x14/0x5f0 [processor_thermal_device_pci] ... [ 224.010921] ---[ end trace 0000000000000000 ]--- Remove the excess pci_disable_device() calls. [ rjw: Subject and changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50043", "url": "https://ubuntu.com/security/CVE-2024-50043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix possible badness in FREE_STATEID When multiple FREE_STATEIDs are sent for the same delegation stateid, it can lead to a possible either use-after-free or counter refcount underflow errors. In nfsd4_free_stateid() under the client lock we find a delegation stateid, however the code drops the lock before calling nfs4_put_stid(), that allows another FREE_STATE to find the stateid again. The first one will proceed to then free the stateid which leads to either use-after-free or decrementing already zeroed counter.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50044", "url": "https://ubuntu.com/security/CVE-2024-50044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change rfcomm_sk_state_change attempts to use sock_lock so it must never be called with it locked but rfcomm_sock_ioctl always attempt to lock it causing the following trace: ====================================================== WARNING: possible circular locking dependency detected 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Not tainted ------------------------------------------------------ syz-executor386/5093 is trying to acquire lock: ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1671 [inline] ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73 but task is already holding lock: ffff88807badfd28 (&d->lock){+.+.}-{3:3}, at: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50045", "url": "https://ubuntu.com/security/CVE-2024-50045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: br_netfilter: fix panic with metadata_dst skb Fix a kernel panic in the br_netfilter module when sending untagged traffic via a VxLAN device. This happens during the check for fragmentation in br_nf_dev_queue_xmit. It is dependent on: 1) the br_netfilter module being loaded; 2) net.bridge.bridge-nf-call-iptables set to 1; 3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port; 4) untagged frames with size higher than the VxLAN MTU forwarded/flooded When forwarding the untagged packet to the VxLAN bridge port, before the netfilter hooks are called, br_handle_egress_vlan_tunnel is called and changes the skb_dst to the tunnel dst. The tunnel_dst is a metadata type of dst, i.e., skb_valid_dst(skb) is false, and metadata->dst.dev is NULL. Then in the br_netfilter hooks, in br_nf_dev_queue_xmit, there's a check for frames that needs to be fragmented: frames with higher MTU than the VxLAN device end up calling br_nf_ip_fragment, which in turns call ip_skb_dst_mtu. The ip_dst_mtu tries to use the skb_dst(skb) as if it was a valid dst with valid dst->dev, thus the crash. This case was never supported in the first place, so drop the packet instead. PING 10.0.0.2 (10.0.0.2) from 0.0.0.0 h1-eth0: 2000(2028) bytes of data. [ 176.291791] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000110 [ 176.292101] Mem abort info: [ 176.292184] ESR = 0x0000000096000004 [ 176.292322] EC = 0x25: DABT (current EL), IL = 32 bits [ 176.292530] SET = 0, FnV = 0 [ 176.292709] EA = 0, S1PTW = 0 [ 176.292862] FSC = 0x04: level 0 translation fault [ 176.293013] Data abort info: [ 176.293104] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 176.293488] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 176.293787] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 176.293995] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043ef5000 [ 176.294166] [0000000000000110] pgd=0000000000000000, p4d=0000000000000000 [ 176.294827] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 176.295252] Modules linked in: vxlan ip6_udp_tunnel udp_tunnel veth br_netfilter bridge stp llc ipv6 crct10dif_ce [ 176.295923] CPU: 0 PID: 188 Comm: ping Not tainted 6.8.0-rc3-g5b3fbd61b9d1 #2 [ 176.296314] Hardware name: linux,dummy-virt (DT) [ 176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 176.296808] pc : br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.297382] lr : br_nf_dev_queue_xmit+0x2ac/0x4ec [br_netfilter] [ 176.297636] sp : ffff800080003630 [ 176.297743] x29: ffff800080003630 x28: 0000000000000008 x27: ffff6828c49ad9f8 [ 176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24: 00000000000003e8 [ 176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21: ffff6828c3b16d28 [ 176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18: 0000000000000014 [ 176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15: 0000000095744632 [ 176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12: ffffb7e137926a70 [ 176.299574] x11: 0000000000000001 x10: ffff6828c3f1c898 x9 : 0000000000000000 [ 176.300049] x8 : ffff6828c49bf070 x7 : 0008460f18d5f20e x6 : f20e0100bebafeca [ 176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 : 0000000000000000 [ 176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 : ffff6828c7f918f0 [ 176.300889] Call trace: [ 176.301123] br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.301411] br_nf_post_routing+0x2a8/0x3e4 [br_netfilter] [ 176.301703] nf_hook_slow+0x48/0x124 [ 176.302060] br_forward_finish+0xc8/0xe8 [bridge] [ 176.302371] br_nf_hook_thresh+0x124/0x134 [br_netfilter] [ 176.302605] br_nf_forward_finish+0x118/0x22c [br_netfilter] [ 176.302824] br_nf_forward_ip.part.0+0x264/0x290 [br_netfilter] [ 176.303136] br_nf_forward+0x2b8/0x4e0 [br_netfilter] [ 176.303359] nf_hook_slow+0x48/0x124 [ 176.303 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50094", "url": "https://ubuntu.com/security/CVE-2024-50094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sfc: Don't invoke xdp_do_flush() from netpoll. Yury reported a crash in the sfc driver originated from netpoll_send_udp(). The netconsole sends a message and then netpoll invokes the driver's NAPI function with a budget of zero. It is dedicated to allow driver to free TX resources, that it may have used while sending the packet. In the netpoll case the driver invokes xdp_do_flush() unconditionally, leading to crash because bpf_net_context was never assigned. Invoke xdp_do_flush() only if budget is not zero.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50188", "url": "https://ubuntu.com/security/CVE-2024-50188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: dp83869: fix memory corruption when enabling fiber When configuring the fiber port, the DP83869 PHY driver incorrectly calls linkmode_set_bit() with a bit mask (1 << 10) rather than a bit number (10). This corrupts some other memory location -- in case of arm64 the priv pointer in the same structure. Since the advertising flags are updated from supported at the end of the function the incorrect line isn't needed at all and can be removed.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50046", "url": "https://ubuntu.com/security/CVE-2024-50046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies() On the node of an NFS client, some files saved in the mountpoint of the NFS server were copied to another location of the same NFS server. Accidentally, the nfs42_complete_copies() got a NULL-pointer dereference crash with the following syslog: [232064.838881] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232064.839360] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232066.588183] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 [232066.588586] Mem abort info: [232066.588701] ESR = 0x0000000096000007 [232066.588862] EC = 0x25: DABT (current EL), IL = 32 bits [232066.589084] SET = 0, FnV = 0 [232066.589216] EA = 0, S1PTW = 0 [232066.589340] FSC = 0x07: level 3 translation fault [232066.589559] Data abort info: [232066.589683] ISV = 0, ISS = 0x00000007 [232066.589842] CM = 0, WnR = 0 [232066.589967] user pgtable: 64k pages, 48-bit VAs, pgdp=00002000956ff400 [232066.590231] [0000000000000058] pgd=08001100ae100003, p4d=08001100ae100003, pud=08001100ae100003, pmd=08001100b3c00003, pte=0000000000000000 [232066.590757] Internal error: Oops: 96000007 [#1] SMP [232066.590958] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm vhost_net vhost vhost_iotlb tap tun ipt_rpfilter xt_multiport ip_set_hash_ip ip_set_hash_net xfrm_interface xfrm6_tunnel tunnel4 tunnel6 esp4 ah4 wireguard libcurve25519_generic veth xt_addrtype xt_set nf_conntrack_netlink ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_bitmap_port ip_set_hash_ipport dummy ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs iptable_filter sch_ingress nfnetlink_cttimeout vport_gre ip_gre ip_tunnel gre vport_geneve geneve vport_vxlan vxlan ip6_udp_tunnel udp_tunnel openvswitch nf_conncount dm_round_robin dm_service_time dm_multipath xt_nat xt_MASQUERADE nft_chain_nat nf_nat xt_mark xt_conntrack xt_comment nft_compat nft_counter nf_tables nfnetlink ocfs2 ocfs2_nodemanager ocfs2_stackglue iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_ssif nbd overlay 8021q garp mrp bonding tls rfkill sunrpc ext4 mbcache jbd2 [232066.591052] vfat fat cas_cache cas_disk ses enclosure scsi_transport_sas sg acpi_ipmi ipmi_si ipmi_devintf ipmi_msghandler ip_tables vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio dm_mirror dm_region_hash dm_log dm_mod nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc fuse xfs libcrc32c ast drm_vram_helper qla2xxx drm_kms_helper syscopyarea crct10dif_ce sysfillrect ghash_ce sysimgblt sha2_ce fb_sys_fops cec sha256_arm64 sha1_ce drm_ttm_helper ttm nvme_fc igb sbsa_gwdt nvme_fabrics drm nvme_core i2c_algo_bit i40e scsi_transport_fc megaraid_sas aes_neon_bs [232066.596953] CPU: 6 PID: 4124696 Comm: 10.253.166.125- Kdump: loaded Not tainted 5.15.131-9.cl9_ocfs2.aarch64 #1 [232066.597356] Hardware name: Great Wall .\\x93\\x8e...RF6260 V5/GWMSSE2GL1T, BIOS T656FBE_V3.0.18 2024-01-06 [232066.597721] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [232066.598034] pc : nfs4_reclaim_open_state+0x220/0x800 [nfsv4] [232066.598327] lr : nfs4_reclaim_open_state+0x12c/0x800 [nfsv4] [232066.598595] sp : ffff8000f568fc70 [232066.598731] x29: ffff8000f568fc70 x28: 0000000000001000 x27: ffff21003db33000 [232066.599030] x26: ffff800005521ae0 x25: ffff0100f98fa3f0 x24: 0000000000000001 [232066.599319] x23: ffff800009920008 x22: ffff21003db33040 x21: ffff21003db33050 [232066.599628] x20: ffff410172fe9e40 x19: ffff410172fe9e00 x18: 0000000000000000 [232066.599914] x17: 0000000000000000 x16: 0000000000000004 x15: 0000000000000000 [232066.600195] x14: 0000000000000000 x13: ffff800008e685a8 x12: 00000000eac0c6e6 [232066.600498] x11: 00000000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50190", "url": "https://ubuntu.com/security/CVE-2024-50190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix memleak in ice_init_tx_topology() Fix leak of the FW blob (DDP pkg). Make ice_cfg_tx_topo() const-correct, so ice_init_tx_topology() can avoid copying whole FW blob. Copy just the topology section, and only when needed. Reuse the buffer allocated for the read of the current topology. This was found by kmemleak, with the following trace for each PF: [] kmemdup_noprof+0x1d/0x50 [] ice_init_ddp_config+0x100/0x220 [ice] [] ice_init_dev+0x6f/0x200 [ice] [] ice_init+0x29/0x560 [ice] [] ice_probe+0x21d/0x310 [ice] Constify ice_cfg_tx_topo() @buf parameter. This cascades further down to few more functions.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50180", "url": "https://ubuntu.com/security/CVE-2024-50180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: sisfb: Fix strbuf array overflow The values of the variables xres and yres are placed in strbuf. These variables are obtained from strbuf1. The strbuf1 array contains digit characters and a space if the array contains non-digit characters. Then, when executing sprintf(strbuf, \"%ux%ux8\", xres, yres); more than 16 bytes will be written to strbuf. It is suggested to increase the size of the strbuf array to 24. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06: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": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50048", "url": "https://ubuntu.com/security/CVE-2024-50048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: Fix a NULL pointer dereference issue in fbcon_putcs syzbot has found a NULL pointer dereference bug in fbcon. Here is the simplified C reproducer: struct param { \tuint8_t type; \tstruct tiocl_selection ts; }; int main() { \tstruct fb_con2fbmap con2fb; \tstruct param param; \tint fd = open(\"/dev/fb1\", 0, 0); \tcon2fb.console = 0x19; \tcon2fb.framebuffer = 0; \tioctl(fd, FBIOPUT_CON2FBMAP, &con2fb); \tparam.type = 2; \tparam.ts.xs = 0; param.ts.ys = 0; \tparam.ts.xe = 0; param.ts.ye = 0; \tparam.ts.sel_mode = 0; \tint fd1 = open(\"/dev/tty1\", O_RDWR, 0); \tioctl(fd1, TIOCLINUX, ¶m); \tcon2fb.console = 1; \tcon2fb.framebuffer = 0; \tioctl(fd, FBIOPUT_CON2FBMAP, &con2fb); \treturn 0; } After calling ioctl(fd1, TIOCLINUX, ¶m), the subsequent ioctl(fd, FBIOPUT_CON2FBMAP, &con2fb) causes the kernel to follow a different execution path: set_con2fb_map -> con2fb_init_display -> fbcon_set_disp -> redraw_screen -> hide_cursor -> clear_selection -> highlight -> invert_screen -> do_update_region -> fbcon_putcs -> ops->putcs Since ops->putcs is a NULL pointer, this leads to a kernel panic. To prevent this, we need to call set_blitting_type() within set_con2fb_map() to properly initialize ops->putcs.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50049", "url": "https://ubuntu.com/security/CVE-2024-50049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before dereferencing se [WHAT & HOW] se is null checked previously in the same function, indicating it might be null; therefore, it must be checked when used again. This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50090", "url": "https://ubuntu.com/security/CVE-2024-50090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/oa: Fix overflow in oa batch buffer By default xe_bb_create_job() appends a MI_BATCH_BUFFER_END to batch buffer, this is not a problem if batch buffer is only used once but oa reuses the batch buffer for the same metric and at each call it appends a MI_BATCH_BUFFER_END, printing the warning below and then overflowing. [ 381.072016] ------------[ cut here ]------------ [ 381.072019] xe 0000:00:02.0: [drm] Assertion `bb->len * 4 + bb_prefetch(q->gt) <= size` failed! platform: LUNARLAKE subplatform: 1 graphics: Xe2_LPG / Xe2_HPG 20.04 step B0 media: Xe2_LPM / Xe2_HPM 20.00 step B0 tile: 0 VRAM 0 B GT: 0 type 1 So here checking if batch buffer already have MI_BATCH_BUFFER_END if not append it. v2: - simply fix, suggestion from Ashutosh (cherry picked from commit 9ba0e0f30ca42a98af3689460063edfb6315718a)", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50183", "url": "https://ubuntu.com/security/CVE-2024-50183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV instance Deleting an NPIV instance requires all fabric ndlps to be released before an NPIV's resources can be torn down. Failure to release fabric ndlps beforehand opens kref imbalance race conditions. Fix by forcing the DA_ID to complete synchronously with usage of wait_queue.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50055", "url": "https://ubuntu.com/security/CVE-2024-50055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: driver core: bus: Fix double free in driver API bus_register() For bus_register(), any error which happens after kset_register() will cause that @priv are freed twice, fixed by setting @priv with NULL after the first free.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50091", "url": "https://ubuntu.com/security/CVE-2024-50091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm vdo: don't refer to dedupe_context after releasing it Clear the dedupe_context pointer in a data_vio whenever ownership of the context is lost, so that vdo can't examine it accidentally.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50056", "url": "https://ubuntu.com/security/CVE-2024-50056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: Fix ERR_PTR dereference in uvc_v4l2.c Fix potential dereferencing of ERR_PTR() in find_format_by_pix() and uvc_v4l2_enum_format(). Fix the following smatch errors: drivers/usb/gadget/function/uvc_v4l2.c:124 find_format_by_pix() error: 'fmtdesc' dereferencing possible ERR_PTR() drivers/usb/gadget/function/uvc_v4l2.c:392 uvc_v4l2_enum_format() error: 'fmtdesc' dereferencing possible ERR_PTR() Also, fix similar issue in uvc_v4l2_try_format() for potential dereferencing of ERR_PTR().", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50184", "url": "https://ubuntu.com/security/CVE-2024-50184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_pmem: Check device status before requesting flush If a pmem device is in a bad status, the driver side could wait for host ack forever in virtio_pmem_flush(), causing the system to hang. So add a status check in the beginning of virtio_pmem_flush() to return early if the device is not activated.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50057", "url": "https://ubuntu.com/security/CVE-2024-50057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: tipd: Free IRQ only if it was requested before In polling mode, if no IRQ was requested there is no need to free it. Call devm_free_irq() only if client->irq is set. This fixes the warning caused by the tps6598x module removal: WARNING: CPU: 2 PID: 333 at kernel/irq/devres.c:144 devm_free_irq+0x80/0x8c ... ... Call trace: devm_free_irq+0x80/0x8c tps6598x_remove+0x28/0x88 [tps6598x] i2c_device_remove+0x2c/0x9c device_remove+0x4c/0x80 device_release_driver_internal+0x1cc/0x228 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 i2c_del_driver+0x54/0x64 tps6598x_i2c_driver_exit+0x18/0xc3c [tps6598x] __arm64_sys_delete_module+0x184/0x264 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc8/0xe8 do_el0_svc+0x20/0x2c el0_svc+0x28/0x98 el0t_64_sync_handler+0x13c/0x158 el0t_64_sync+0x190/0x194", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50058", "url": "https://ubuntu.com/security/CVE-2024-50058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: protect uart_port_dtr_rts() in uart_shutdown() too Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part 3) added few uport == NULL checks. It added one to uart_shutdown(), so the commit assumes, uport can be NULL in there. But right after that protection, there is an unprotected \"uart_port_dtr_rts(uport, false);\" call. That is invoked only if HUPCL is set, so I assume that is the reason why we do not see lots of these reports. Or it cannot be NULL at this point at all for some reason :P. Until the above is investigated, stay on the safe side and move this dereference to the if too. I got this inconsistency from Coverity under CID 1585130. Thanks.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50181", "url": "https://ubuntu.com/security/CVE-2024-50181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: imx: Remove CLK_SET_PARENT_GATE for DRAM mux for i.MX7D For i.MX7D DRAM related mux clock, the clock source change should ONLY be done done in low level asm code without accessing DRAM, and then calling clk API to sync the HW clock status with clk tree, it should never touch real clock source switch via clk API, so CLK_SET_PARENT_GATE flag should NOT be added, otherwise, DRAM's clock parent will be disabled when DRAM is active, and system will hang.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50059", "url": "https://ubuntu.com/security/CVE-2024-50059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntb: ntb_hw_switchtec: Fix use after free vulnerability in switchtec_ntb_remove due to race condition In the switchtec_ntb_add function, it can call switchtec_ntb_init_sndev function, then &sndev->check_link_status_work is bound with check_link_status_work. switchtec_ntb_link_notification may be called to start the work. If we remove the module which will call switchtec_ntb_remove to make cleanup, it will free sndev through kfree(sndev), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | check_link_status_work switchtec_ntb_remove | kfree(sndev); | | if (sndev->link_force_down) | // use sndev Fix it by ensuring that the work is canceled before proceeding with the cleanup in switchtec_ntb_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50060", "url": "https://ubuntu.com/security/CVE-2024-50060", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring: check if we need to reschedule during overflow flush In terms of normal application usage, this list will always be empty. And if an application does overflow a bit, it'll have a few entries. However, nothing obviously prevents syzbot from running a test case that generates a ton of overflow entries, and then flushing them can take quite a while. Check for needing to reschedule while flushing, and drop our locks and do so if necessary. There's no state to maintain here as overflows always prune from head-of-list, hence it's fine to drop and reacquire the locks at the end of the loop.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50061", "url": "https://ubuntu.com/security/CVE-2024-50061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: cdns: Fix use after free vulnerability in cdns_i3c_master Driver Due to Race Condition In the cdns_i3c_master_probe function, &master->hj_work is bound with cdns_i3c_master_hj. And cdns_i3c_master_interrupt can call cnds_i3c_master_demux_ibis function to start the work. If we remove the module which will call cdns_i3c_master_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | cdns_i3c_master_hj cdns_i3c_master_remove | i3c_master_unregister(&master->base) | device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in cdns_i3c_master_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50062", "url": "https://ubuntu.com/security/CVE-2024-50062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-srv: Avoid null pointer deref during path establishment For RTRS path establishment, RTRS client initiates and completes con_num of connections. After establishing all its connections, the information is exchanged between the client and server through the info_req message. During this exchange, it is essential that all connections have been established, and the state of the RTRS srv path is CONNECTED. So add these sanity checks, to make sure we detect and abort process in error scenarios to avoid null pointer deref.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50095", "url": "https://ubuntu.com/security/CVE-2024-50095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mad: Improve handling of timed out WRs of mad agent Current timeout handler of mad agent acquires/releases mad_agent_priv lock for every timed out WRs. This causes heavy locking contention when higher no. of WRs are to be handled inside timeout handler. This leads to softlockup with below trace in some use cases where rdma-cm path is used to establish connection between peer nodes Trace: ----- BUG: soft lockup - CPU#4 stuck for 26s! [kworker/u128:3:19767] CPU: 4 PID: 19767 Comm: kworker/u128:3 Kdump: loaded Tainted: G OE ------- --- 5.14.0-427.13.1.el9_4.x86_64 #1 Hardware name: Dell Inc. PowerEdge R740/01YM03, BIOS 2.4.8 11/26/2019 Workqueue: ib_mad1 timeout_sends [ib_core] RIP: 0010:__do_softirq+0x78/0x2ac RSP: 0018:ffffb253449e4f98 EFLAGS: 00000246 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 000000000000001f RDX: 000000000000001d RSI: 000000003d1879ab RDI: fff363b66fd3a86b RBP: ffffb253604cbcd8 R08: 0000009065635f3b R09: 0000000000000000 R10: 0000000000000040 R11: ffffb253449e4ff8 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000040 FS: 0000000000000000(0000) GS:ffff8caa1fc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd9ec9db900 CR3: 0000000891934006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? __irq_exit_rcu+0xa1/0xc0 ? watchdog_timer_fn+0x1b2/0x210 ? __pfx_watchdog_timer_fn+0x10/0x10 ? __hrtimer_run_queues+0x127/0x2c0 ? hrtimer_interrupt+0xfc/0x210 ? __sysvec_apic_timer_interrupt+0x5c/0x110 ? sysvec_apic_timer_interrupt+0x37/0x90 ? asm_sysvec_apic_timer_interrupt+0x16/0x20 ? __do_softirq+0x78/0x2ac ? __do_softirq+0x60/0x2ac __irq_exit_rcu+0xa1/0xc0 sysvec_call_function_single+0x72/0x90 asm_sysvec_call_function_single+0x16/0x20 RIP: 0010:_raw_spin_unlock_irq+0x14/0x30 RSP: 0018:ffffb253604cbd88 EFLAGS: 00000247 RAX: 000000000001960d RBX: 0000000000000002 RCX: ffff8cad2a064800 RDX: 000000008020001b RSI: 0000000000000001 RDI: ffff8cad5d39f66c RBP: ffff8cad5d39f600 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8caa443e0c00 R11: ffffb253604cbcd8 R12: ffff8cacb8682538 R13: 0000000000000005 R14: ffffb253604cbd90 R15: ffff8cad5d39f66c cm_process_send_error+0x122/0x1d0 [ib_cm] timeout_sends+0x1dd/0x270 [ib_core] process_one_work+0x1e2/0x3b0 ? __pfx_worker_thread+0x10/0x10 worker_thread+0x50/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xdd/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x50 Simplified timeout handler by creating local list of timed out WRs and invoke send handler post creating the list. The new method acquires/ releases lock once to fetch the list and hence helps to reduce locking contetiong when processing higher no. of WRs", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50063", "url": "https://ubuntu.com/security/CVE-2024-50063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Prevent tail call between progs attached to different hooks bpf progs can be attached to kernel functions, and the attached functions can take different parameters or return different return values. If prog attached to one kernel function tail calls prog attached to another kernel function, the ctx access or return value verification could be bypassed. For example, if prog1 is attached to func1 which takes only 1 parameter and prog2 is attached to func2 which takes two parameters. Since verifier assumes the bpf ctx passed to prog2 is constructed based on func2's prototype, verifier allows prog2 to access the second parameter from the bpf ctx passed to it. The problem is that verifier does not prevent prog1 from passing its bpf ctx to prog2 via tail call. In this case, the bpf ctx passed to prog2 is constructed from func1 instead of func2, that is, the assumption for ctx access verification is bypassed. Another example, if BPF LSM prog1 is attached to hook file_alloc_security, and BPF LSM prog2 is attached to hook bpf_lsm_audit_rule_known. Verifier knows the return value rules for these two hooks, e.g. it is legal for bpf_lsm_audit_rule_known to return positive number 1, and it is illegal for file_alloc_security to return positive number. So verifier allows prog2 to return positive number 1, but does not allow prog1 to return positive number. The problem is that verifier does not prevent prog1 from calling prog2 via tail call. In this case, prog2's return value 1 will be used as the return value for prog1's hook file_alloc_security. That is, the return value rule is bypassed. This patch adds restriction for tail call to prevent such bypasses.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50191", "url": "https://ubuntu.com/security/CVE-2024-50191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: don't set SB_RDONLY after filesystem errors When the filesystem is mounted with errors=remount-ro, we were setting SB_RDONLY flag to stop all filesystem modifications. We knew this misses proper locking (sb->s_umount) and does not go through proper filesystem remount procedure but it has been the way this worked since early ext2 days and it was good enough for catastrophic situation damage mitigation. Recently, syzbot has found a way (see link) to trigger warnings in filesystem freezing because the code got confused by SB_RDONLY changing under its hands. Since these days we set EXT4_FLAGS_SHUTDOWN on the superblock which is enough to stop all filesystem modifications, modifying SB_RDONLY shouldn't be needed. So stop doing that.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50064", "url": "https://ubuntu.com/security/CVE-2024-50064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: zram: free secondary algorithms names We need to kfree() secondary algorithms names when reset zram device that had multi-streams, otherwise we leak memory. [senozhatsky@chromium.org: kfree(NULL) is legal] Link: https://lkml.kernel.org/r/20240917013021.868769-1-senozhatsky@chromium.org", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50065", "url": "https://ubuntu.com/security/CVE-2024-50065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Change to non-blocking allocation in ntfs_d_hash d_hash is done while under \"rcu-walk\" and should not sleep. __get_name() allocates using GFP_KERNEL, having the possibility to sleep when under memory pressure. Change the allocation to GFP_NOWAIT.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50089", "url": "https://ubuntu.com/security/CVE-2024-50089", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-49863", "url": "https://ubuntu.com/security/CVE-2024-49863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost/scsi: null-ptr-dereference in vhost_scsi_get_req() Since commit 3f8ca2e115e5 (\"vhost/scsi: Extract common handling code from control queue handler\") a null pointer dereference bug can be triggered when guest sends an SCSI AN request. In vhost_scsi_ctl_handle_vq(), `vc.target` is assigned with `&v_req.tmf.lun[1]` within a switch-case block and is then passed to vhost_scsi_get_req() which extracts `vc->req` and `tpg`. However, for a `VIRTIO_SCSI_T_AN_*` request, tpg is not required, so `vc.target` is set to NULL in this branch. Later, in vhost_scsi_get_req(), `vc->target` is dereferenced without being checked, leading to a null pointer dereference bug. This bug can be triggered from guest. When this bug occurs, the vhost_worker process is killed while holding `vq->mutex` and the corresponding tpg will remain occupied indefinitely. Below is the KASAN report: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 PID: 840 Comm: poc Not tainted 6.10.0+ #1 Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:vhost_scsi_get_req+0x165/0x3a0 Code: 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 02 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 65 30 4c 89 e2 48 c1 ea 03 <0f> b6 04 02 4c 89 e2 83 e2 07 38 d0 7f 08 84 c0 0f 85 be 01 00 00 RSP: 0018:ffff888017affb50 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffff88801b000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888017affcb8 RBP: ffff888017affb80 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff888017affc88 R14: ffff888017affd1c R15: ffff888017993000 FS: 000055556e076500(0000) GS:ffff88806b100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200027c0 CR3: 0000000010ed0004 CR4: 0000000000370ef0 Call Trace: ? show_regs+0x86/0xa0 ? die_addr+0x4b/0xd0 ? exc_general_protection+0x163/0x260 ? asm_exc_general_protection+0x27/0x30 ? vhost_scsi_get_req+0x165/0x3a0 vhost_scsi_ctl_handle_vq+0x2a4/0xca0 ? __pfx_vhost_scsi_ctl_handle_vq+0x10/0x10 ? __switch_to+0x721/0xeb0 ? __schedule+0xda5/0x5710 ? __kasan_check_write+0x14/0x30 ? _raw_spin_lock+0x82/0xf0 vhost_scsi_ctl_handle_kick+0x52/0x90 vhost_run_work_list+0x134/0x1b0 vhost_task_fn+0x121/0x350 ... ---[ end trace 0000000000000000 ]--- Let's add a check in vhost_scsi_get_req. [whitespace fixes]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49864", "url": "https://ubuntu.com/security/CVE-2024-49864", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix a race between socket set up and I/O thread creation In rxrpc_open_socket(), it sets up the socket and then sets up the I/O thread that will handle it. This is a problem, however, as there's a gap between the two phases in which a packet may come into rxrpc_encap_rcv() from the UDP packet but we oops when trying to wake the not-yet created I/O thread. As a quick fix, just make rxrpc_encap_rcv() discard the packet if there's no I/O thread yet. A better, but more intrusive fix would perhaps be to rearrange things such that the socket creation is done by the I/O thread.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49865", "url": "https://ubuntu.com/security/CVE-2024-49865", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: move xa_alloc to prevent UAF Evil user can guess the next id of the vm before the ioctl completes and then call vm destroy ioctl to trigger UAF since create ioctl is still referencing the same vm. Move the xa_alloc all the way to the end to prevent this. v2: - Rebase (cherry picked from commit dcfd3971327f3ee92765154baebbaece833d3ca9)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49955", "url": "https://ubuntu.com/security/CVE-2024-49955", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: battery: Fix possible crash when unregistering a battery hook When a battery hook returns an error when adding a new battery, then the battery hook is automatically unregistered. However the battery hook provider cannot know that, so it will later call battery_hook_unregister() on the already unregistered battery hook, resulting in a crash. Fix this by using the list head to mark already unregistered battery hooks as already being unregistered so that they can be ignored by battery_hook_unregister().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49973", "url": "https://ubuntu.com/security/CVE-2024-49973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: r8169: add tally counter fields added with RTL8125 RTL8125 added fields to the tally counter, what may result in the chip dma'ing these new fields to unallocated memory. Therefore make sure that the allocated memory area is big enough to hold all of the tally counter values, even if we use only parts of it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49974", "url": "https://ubuntu.com/security/CVE-2024-49974", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Limit the number of concurrent async COPY operations Nothing appears to limit the number of concurrent async COPY operations that clients can start. In addition, AFAICT each async COPY can copy an unlimited number of 4MB chunks, so can run for a long time. Thus IMO async COPY can become a DoS vector. Add a restriction mechanism that bounds the number of concurrent background COPY operations. Start simple and try to be fair -- this patch implements a per-namespace limit. An async COPY request that occurs while this limit is exceeded gets NFS4ERR_DELAY. The requesting client can choose to send the request again after a delay or fall back to a traditional read/write style copy. If there is need to make the mechanism more sophisticated, we can visit that in future patches.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49975", "url": "https://ubuntu.com/security/CVE-2024-49975", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uprobes: fix kernel info leak via \"[uprobes]\" vma xol_add_vma() maps the uninitialized page allocated by __create_xol_area() into userspace. On some architectures (x86) this memory is readable even without VM_READ, VM_EXEC results in the same pgprot_t as VM_EXEC|VM_READ, although this doesn't really matter, debugger can read this memory anyway.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50003", "url": "https://ubuntu.com/security/CVE-2024-50003", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix system hang while resume with TBT monitor [Why] Connected with a Thunderbolt monitor and do the suspend and the system may hang while resume. The TBT monitor HPD will be triggered during the resume procedure and call the drm_client_modeset_probe() while struct drm_connector connector->dev->master is NULL. It will mess up the pipe topology after resume. [How] Skip the TBT monitor HPD during the resume procedure because we currently will probe the connectors after resume by default. (cherry picked from commit 453f86a26945207a16b8f66aaed5962dc2b95b85)", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50173", "url": "https://ubuntu.com/security/CVE-2024-50173", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix access to uninitialized variable in tick_ctx_cleanup() The group variable can't be used to retrieve ptdev in our second loop, because it points to the previously iterated list_head, not a valid group. Get the ptdev object from the scheduler instead.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49866", "url": "https://ubuntu.com/security/CVE-2024-49866", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Fix a race during cpuhp processing There is another found exception that the \"timerlat/1\" thread was scheduled on CPU0, and lead to timer corruption finally: ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ``` After tracing the scheduling event, it was discovered that the migration of the \"timerlat/1\" thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() | To fix this, skip online processing if the CPU is already offline.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49976", "url": "https://ubuntu.com/security/CVE-2024-49976", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Drop interface_lock in stop_kthread() stop_kthread() is the offline callback for \"trace/osnoise:online\", since commit 5bfbcd1ee57b (\"tracing/timerlat: Add interface_lock around clearing of kthread in stop_kthread()\"), the following ABBA deadlock scenario is introduced: T1 | T2 [BP] | T3 [AP] osnoise_hotplug_workfn() | work_for_cpu_fn() | cpuhp_thread_fun() | _cpu_down() | osnoise_cpu_die() mutex_lock(&interface_lock) | | stop_kthread() | cpus_write_lock() | mutex_lock(&interface_lock) cpus_read_lock() | cpuhp_kick_ap() | As the interface_lock here in just for protecting the \"kthread\" field of the osn_var, use xchg() instead to fix this issue. Also use for_each_online_cpu() back in stop_per_cpu_kthreads() as it can take cpu_read_lock() again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50005", "url": "https://ubuntu.com/security/CVE-2024-50005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: Fix potential RCU dereference issue in mac802154_scan_worker In the `mac802154_scan_worker` function, the `scan_req->type` field was accessed after the RCU read-side critical section was unlocked. According to RCU usage rules, this is illegal and can lead to unpredictable behavior, such as accessing memory that has been updated or causing use-after-free issues. This possible bug was identified using a static analysis tool developed by myself, specifically designed to detect RCU-related issues. To address this, the `scan_req->type` value is now stored in a local variable `scan_req_type` while still within the RCU read-side critical section. The `scan_req_type` is then used after the RCU lock is released, ensuring that the type value is safely accessed without violating RCU rules.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50012", "url": "https://ubuntu.com/security/CVE-2024-50012", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: Avoid a bad reference count on CPU node In the parse_perf_domain function, if the call to of_parse_phandle_with_args returns an error, then the reference to the CPU device node that was acquired at the start of the function would not be properly decremented. Address this by declaring the variable with the __free(device_node) cleanup attribute.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49867", "url": "https://ubuntu.com/security/CVE-2024-49867", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: wait for fixup workers before stopping cleaner kthread during umount During unmount, at close_ctree(), we have the following steps in this order: 1) Park the cleaner kthread - this doesn't destroy the kthread, it basically halts its execution (wake ups against it work but do nothing); 2) We stop the cleaner kthread - this results in freeing the respective struct task_struct; 3) We call btrfs_stop_all_workers() which waits for any jobs running in all the work queues and then free the work queues. Syzbot reported a case where a fixup worker resulted in a crash when doing a delayed iput on its inode while attempting to wake up the cleaner at btrfs_add_delayed_iput(), because the task_struct of the cleaner kthread was already freed. This can happen during unmount because we don't wait for any fixup workers still running before we call kthread_stop() against the cleaner kthread, which stops and free all its resources. Fix this by waiting for any fixup workers at close_ctree() before we call kthread_stop() against the cleaner and run pending delayed iputs. The stack traces reported by syzbot were the following: BUG: KASAN: slab-use-after-free in __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 Read of size 8 at addr ffff8880272a8a18 by task kworker/u8:3/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.12.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: btrfs-fixup btrfs_work_helper 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 __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline] try_to_wake_up+0xb0/0x1480 kernel/sched/core.c:4154 btrfs_writepage_fixup_worker+0xc16/0xdf0 fs/btrfs/inode.c:2842 btrfs_work_helper+0x390/0xc50 fs/btrfs/async-thread.c:314 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Allocated by task 2: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:319 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345 kasan_slab_alloc include/linux/kasan.h:247 [inline] slab_post_alloc_hook mm/slub.c:4086 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4187 alloc_task_struct_node kernel/fork.c:180 [inline] dup_task_struct+0x57/0x8c0 kernel/fork.c:1107 copy_process+0x5d1/0x3d50 kernel/fork.c:2206 kernel_clone+0x223/0x880 kernel/fork.c:2787 kernel_thread+0x1bc/0x240 kernel/fork.c:2849 create_kthread kernel/kthread.c:412 [inline] kthreadd+0x60d/0x810 kernel/kthread.c:765 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Freed by task 61: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:230 [inline] slab_free_h ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49868", "url": "https://ubuntu.com/security/CVE-2024-49868", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix a NULL pointer dereference when failed to start a new trasacntion [BUG] Syzbot reported a NULL pointer dereference with the following crash: FAULT_INJECTION: forcing a failure. start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676 prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642 relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678 ... BTRFS info (device loop0): balance: ended with status: -12 Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667] RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926 Call Trace: commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496 btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430 del_balance_item fs/btrfs/volumes.c:3678 [inline] reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742 btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574 btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673 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/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [CAUSE] The allocation failure happens at the start_transaction() inside prepare_to_relocate(), and during the error handling we call unset_reloc_control(), which makes fs_info->balance_ctl to be NULL. Then we continue the error path cleanup in btrfs_balance() by calling reset_balance_state() which will call del_balance_item() to fully delete the balance item in the root tree. However during the small window between set_reloc_contrl() and unset_reloc_control(), we can have a subvolume tree update and created a reloc_root for that subvolume. Then we go into the final btrfs_commit_transaction() of del_balance_item(), and into btrfs_update_reloc_root() inside commit_fs_roots(). That function checks if fs_info->reloc_ctl is in the merge_reloc_tree stage, but since fs_info->reloc_ctl is NULL, it results a NULL pointer dereference. [FIX] Just add extra check on fs_info->reloc_ctl inside btrfs_update_reloc_root(), before checking fs_info->reloc_ctl->merge_reloc_tree. That DEAD_RELOC_TREE handling is to prevent further modification to the reloc tree during merge stage, but since there is no reloc_ctl at all, we do not need to bother that.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49869", "url": "https://ubuntu.com/security/CVE-2024-49869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: send: fix buffer overflow detection when copying path to cache entry Starting with commit c0247d289e73 (\"btrfs: send: annotate struct name_cache_entry with __counted_by()\") we annotated the variable length array \"name\" from the name_cache_entry structure with __counted_by() to improve overflow detection. However that alone was not correct, because the length of that array does not match the \"name_len\" field - it matches that plus 1 to include the NUL string terminator, so that makes a fortified kernel think there's an overflow and report a splat like this: strcpy: detected buffer overflow: 20 byte write of buffer size 19 WARNING: CPU: 3 PID: 3310 at __fortify_report+0x45/0x50 CPU: 3 UID: 0 PID: 3310 Comm: btrfs Not tainted 6.11.0-prnet #1 Hardware name: CompuLab Ltd. sbc-ihsw/Intense-PC2 (IPC2), BIOS IPC2_3.330.7 X64 03/15/2018 RIP: 0010:__fortify_report+0x45/0x50 Code: 48 8b 34 (...) RSP: 0018:ffff97ebc0d6f650 EFLAGS: 00010246 RAX: 7749924ef60fa600 RBX: ffff8bf5446a521a RCX: 0000000000000027 RDX: 00000000ffffdfff RSI: ffff97ebc0d6f548 RDI: ffff8bf84e7a1cc8 RBP: ffff8bf548574080 R08: ffffffffa8c40e10 R09: 0000000000005ffd R10: 0000000000000004 R11: ffffffffa8c70e10 R12: ffff8bf551eef400 R13: 0000000000000000 R14: 0000000000000013 R15: 00000000000003a8 FS: 00007fae144de8c0(0000) GS:ffff8bf84e780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fae14691690 CR3: 00000001027a2003 CR4: 00000000001706f0 Call Trace: ? __warn+0x12a/0x1d0 ? __fortify_report+0x45/0x50 ? report_bug+0x154/0x1c0 ? handle_bug+0x42/0x70 ? exc_invalid_op+0x1a/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? __fortify_report+0x45/0x50 __fortify_panic+0x9/0x10 __get_cur_name_and_parent+0x3bc/0x3c0 get_cur_path+0x207/0x3b0 send_extent_data+0x709/0x10d0 ? find_parent_nodes+0x22df/0x25d0 ? mas_nomem+0x13/0x90 ? mtree_insert_range+0xa5/0x110 ? btrfs_lru_cache_store+0x5f/0x1e0 ? iterate_extent_inodes+0x52d/0x5a0 process_extent+0xa96/0x11a0 ? __pfx_lookup_backref_cache+0x10/0x10 ? __pfx_store_backref_cache+0x10/0x10 ? __pfx_iterate_backrefs+0x10/0x10 ? __pfx_check_extent_item+0x10/0x10 changed_cb+0x6fa/0x930 ? tree_advance+0x362/0x390 ? memcmp_extent_buffer+0xd7/0x160 send_subvol+0xf0a/0x1520 btrfs_ioctl_send+0x106b/0x11d0 ? __pfx___clone_root_cmp_sort+0x10/0x10 _btrfs_ioctl_send+0x1ac/0x240 btrfs_ioctl+0x75b/0x850 __se_sys_ioctl+0xca/0x150 do_syscall_64+0x85/0x160 ? __count_memcg_events+0x69/0x100 ? handle_mm_fault+0x1327/0x15c0 ? __se_sys_rt_sigprocmask+0xf1/0x180 ? syscall_exit_to_user_mode+0x75/0xa0 ? do_syscall_64+0x91/0x160 ? do_user_addr_fault+0x21d/0x630 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fae145eeb4f Code: 00 48 89 (...) RSP: 002b:00007ffdf1cb09b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fae145eeb4f RDX: 00007ffdf1cb0ad0 RSI: 0000000040489426 RDI: 0000000000000004 RBP: 00000000000078fe R08: 00007fae144006c0 R09: 00007ffdf1cb0927 R10: 0000000000000008 R11: 0000000000000246 R12: 00007ffdf1cb1ce8 R13: 0000000000000003 R14: 000055c499fab2e0 R15: 0000000000000004 Fix this by not storing the NUL string terminator since we don't actually need it for name cache entries, this way \"name_len\" corresponds to the actual size of the \"name\" array. This requires marking the \"name\" array field with __nonstring and using memcpy() instead of strcpy() as recommended by the guidelines at: https://github.com/KSPP/linux/issues/90", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49870", "url": "https://ubuntu.com/security/CVE-2024-49870", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cachefiles: fix dentry leak in cachefiles_open_file() A dentry leak may be caused when a lookup cookie and a cull are concurrent: P1 | P2 ----------------------------------------------------------- cachefiles_lookup_cookie cachefiles_look_up_object lookup_one_positive_unlocked // get dentry cachefiles_cull inode->i_flags |= S_KERNEL_FILE; cachefiles_open_file cachefiles_mark_inode_in_use __cachefiles_mark_inode_in_use can_use = false if (!(inode->i_flags & S_KERNEL_FILE)) can_use = true \t return false return false // Returns an error but doesn't put dentry After that the following WARNING will be triggered when the backend folder is umounted: ================================================================== BUG: Dentry 000000008ad87947{i=7a,n=Dx_1_1.img} still in use (1) [unmount of ext4 sda] WARNING: CPU: 4 PID: 359261 at fs/dcache.c:1767 umount_check+0x5d/0x70 CPU: 4 PID: 359261 Comm: umount Not tainted 6.6.0-dirty #25 RIP: 0010:umount_check+0x5d/0x70 Call Trace: d_walk+0xda/0x2b0 do_one_tree+0x20/0x40 shrink_dcache_for_umount+0x2c/0x90 generic_shutdown_super+0x20/0x160 kill_block_super+0x1a/0x40 ext4_kill_sb+0x22/0x40 deactivate_locked_super+0x35/0x80 cleanup_mnt+0x104/0x160 ================================================================== Whether cachefiles_open_file() returns true or false, the reference count obtained by lookup_positive_unlocked() in cachefiles_look_up_object() should be released. Therefore release that reference count in cachefiles_look_up_object() to fix the above issue and simplify the code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49871", "url": "https://ubuntu.com/security/CVE-2024-49871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: adp5589-keys - fix NULL pointer dereference We register a devm action to call adp5589_clear_config() and then pass the i2c client as argument so that we can call i2c_get_clientdata() in order to get our device object. However, i2c_set_clientdata() is only being set at the end of the probe function which means that we'll get a NULL pointer dereference in case the probe function fails early.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49872", "url": "https://ubuntu.com/security/CVE-2024-49872", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/gup: fix memfd_pin_folios alloc race panic If memfd_pin_folios tries to create a hugetlb page, but someone else already did, then folio gets the value -EEXIST here: folio = memfd_alloc_folio(memfd, start_idx); if (IS_ERR(folio)) { ret = PTR_ERR(folio); if (ret != -EEXIST) goto err; then on the next trip through the \"while start_idx\" loop we panic here: if (folio) { folio_put(folio); To fix, set the folio to NULL on error.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49964", "url": "https://ubuntu.com/security/CVE-2024-49964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix memfd_pin_folios free_huge_pages leak memfd_pin_folios followed by unpin_folios fails to restore free_huge_pages if the pages were not already faulted in, because the folio refcount for pages created by memfd_alloc_folio never goes to 0. memfd_pin_folios needs another folio_put to undo the folio_try_get below: memfd_alloc_folio() alloc_hugetlb_folio_nodemask() dequeue_hugetlb_folio_nodemask() dequeue_hugetlb_folio_node_exact() folio_ref_unfreeze(folio, 1); ; adds 1 refcount folio_try_get() ; adds 1 refcount hugetlb_add_to_page_cache() ; adds 512 refcount (on x86) With the fix, after memfd_pin_folios + unpin_folios, the refcount for the (unfaulted) page is 512, which is correct, as the refcount for a faulted unpinned page is 513.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49873", "url": "https://ubuntu.com/security/CVE-2024-49873", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/filemap: fix filemap_get_folios_contig THP panic Patch series \"memfd-pin huge page fixes\". Fix multiple bugs that occur when using memfd_pin_folios with hugetlb pages and THP. The hugetlb bugs only bite when the page is not yet faulted in when memfd_pin_folios is called. The THP bug bites when the starting offset passed to memfd_pin_folios is not huge page aligned. See the commit messages for details. This patch (of 5): memfd_pin_folios on memory backed by THP panics if the requested start offset is not huge page aligned: BUG: kernel NULL pointer dereference, address: 0000000000000036 RIP: 0010:filemap_get_folios_contig+0xdf/0x290 RSP: 0018:ffffc9002092fbe8 EFLAGS: 00010202 RAX: 0000000000000002 RBX: 0000000000000002 RCX: 0000000000000002 The fault occurs here, because xas_load returns a folio with value 2: filemap_get_folios_contig() for (folio = xas_load(&xas); folio && xas.xa_index <= end; folio = xas_next(&xas)) { ... if (!folio_try_get(folio)) <-- BOOM \"2\" is an xarray sibling entry. We get it because memfd_pin_folios does not round the indices passed to filemap_get_folios_contig to huge page boundaries for THP, so we load from the middle of a huge page range see a sibling. (It does round for hugetlbfs, at the is_file_hugepages test). To fix, if the folio is a sibling, then return the next index as the starting point for the next call to filemap_get_folios_contig.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49977", "url": "https://ubuntu.com/security/CVE-2024-49977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: Fix zero-division error when disabling tc cbs The commit b8c43360f6e4 (\"net: stmmac: No need to calculate speed divider when offload is disabled\") allows the \"port_transmit_rate_kbps\" to be set to a value of 0, which is then passed to the \"div_s64\" function when tc-cbs is disabled. This leads to a zero-division error. When tc-cbs is disabled, the idleslope, sendslope, and credit values the credit values are not required to be configured. Therefore, adding a return statement after setting the txQ mode to DCB when tc-cbs is disabled would prevent a zero-division error.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49978", "url": "https://ubuntu.com/security/CVE-2024-49978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gso: fix udp gso fraglist segmentation after pull from frag_list Detect gso fraglist skbs with corrupted geometry (see below) and pass these to skb_segment instead of skb_segment_list, as the first can segment them correctly. 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 these skbs, breaking these invariants. In extreme cases they pull all data into skb linear. For UDP, this causes a NULL ptr deref in __udpv4_gso_segment_list_csum at udp_hdr(seg->next)->dest. Detect invalid geometry due to pull, by checking head_skb size. Don't just drop, as this may blackhole a destination. Convert to be able to pass to regular skb_segment.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49979", "url": "https://ubuntu.com/security/CVE-2024-49979", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gso: fix tcp fraglist segmentation after pull from frag_list Detect tcp gso fraglist skbs with corrupted geometry (see below) and pass these to skb_segment instead of skb_segment_list, as the first can segment them correctly. 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 these skbs, breaking these invariants. In extreme cases they pull all data into skb linear. For TCP, this causes a NULL ptr deref in __tcpv4_gso_segment_list_csum at tcp_hdr(seg->next). Detect invalid geometry due to pull, by checking head_skb size. Don't just drop, as this may blackhole a destination. Convert to be able to pass to regular skb_segment. Approach and description based on a patch by Willem de Bruijn.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49980", "url": "https://ubuntu.com/security/CVE-2024-49980", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vrf: revert \"vrf: Remove unnecessary RCU-bh critical section\" This reverts commit 504fc6f4f7f681d2a03aa5f68aad549d90eab853. dev_queue_xmit_nit is expected to be called with BH disabled. __dev_queue_xmit has the following: /* Disable soft irqs for various locks below. Also * stops preemption for RCU. */ rcu_read_lock_bh(); VRF must follow this invariant. The referenced commit removed this protection. Which triggered a lockdep warning: \t================================ \tWARNING: inconsistent lock state \t6.11.0 #1 Tainted: G W \t-------------------------------- \tinconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage. \tbtserver/134819 [HC0[0]:SC0[0]:HE1:SE1] takes: \tffff8882da30c118 (rlock-AF_PACKET){+.?.}-{2:2}, at: tpacket_rcv+0x863/0x3b30 \t{IN-SOFTIRQ-W} state was registered at: \t lock_acquire+0x19a/0x4f0 \t _raw_spin_lock+0x27/0x40 \t packet_rcv+0xa33/0x1320 \t __netif_receive_skb_core.constprop.0+0xcb0/0x3a90 \t __netif_receive_skb_list_core+0x2c9/0x890 \t netif_receive_skb_list_internal+0x610/0xcc0 [...] \tother info that might help us debug this: \t Possible unsafe locking scenario: \t CPU0 \t ---- \t lock(rlock-AF_PACKET); \t \t lock(rlock-AF_PACKET); \t *** DEADLOCK *** \tCall Trace: \t \t dump_stack_lvl+0x73/0xa0 \t mark_lock+0x102e/0x16b0 \t __lock_acquire+0x9ae/0x6170 \t lock_acquire+0x19a/0x4f0 \t _raw_spin_lock+0x27/0x40 \t tpacket_rcv+0x863/0x3b30 \t dev_queue_xmit_nit+0x709/0xa40 \t vrf_finish_direct+0x26e/0x340 [vrf] \t vrf_l3_out+0x5f4/0xe80 [vrf] \t __ip_local_out+0x51e/0x7a0 [...]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49981", "url": "https://ubuntu.com/security/CVE-2024-49981", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: venus: fix use after free bug in venus_remove due to race condition in venus_probe, core->work is bound with venus_sys_error_handler, which is used to handle error. The code use core->sys_err_done to make sync work. The core->work is started in venus_event_notify. If we call venus_remove, there might be an unfished work. The possible sequence is as follows: CPU0 CPU1 |venus_sys_error_handler venus_remove | hfi_destroy\t \t\t | venus_hfi_destroy\t | kfree(hdev);\t | |hfi_reinit \t\t\t\t\t |venus_hfi_queues_reinit |//use hdev Fix it by canceling the work in venus_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49956", "url": "https://ubuntu.com/security/CVE-2024-49956", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: fix double destroy_workqueue error When gfs2_fill_super() fails, destroy_workqueue() is called within gfs2_gl_hash_clear(), and the subsequent code path calls destroy_workqueue() on the same work queue again. This issue can be fixed by setting the work queue pointer to NULL after the first destroy_workqueue() call and checking for a NULL pointer before attempting to destroy the work queue again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50176", "url": "https://ubuntu.com/security/CVE-2024-50176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: k3-r5: Fix error handling when power-up failed By simply bailing out, the driver was violating its rule and internal assumptions that either both or no rproc should be initialized. E.g., this could cause the first core to be available but not the second one, leading to crashes on its shutdown later on while trying to dereference that second instance.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49982", "url": "https://ubuntu.com/security/CVE-2024-49982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: aoe: fix the potential use-after-free problem in more places For fixing CVE-2023-6270, f98364e92662 (\"aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts\") makes tx() calling dev_put() instead of doing in aoecmd_cfg_pkts(). It avoids that the tx() runs into use-after-free. Then Nicolai Stange found more places in aoe have potential use-after-free problem with tx(). e.g. revalidate(), aoecmd_ata_rw(), resend(), probe() and aoecmd_cfg_rsp(). Those functions also use aoenet_xmit() to push packet to tx queue. So they should also use dev_hold() to increase the refcnt of skb->dev. On the other hand, moving dev_put() to tx() causes that the refcnt of skb->dev be reduced to a negative value, because corresponding dev_hold() are not called in revalidate(), aoecmd_ata_rw(), resend(), probe(), and aoecmd_cfg_rsp(). This patch fixed this issue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49874", "url": "https://ubuntu.com/security/CVE-2024-49874", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: svc: Fix use after free vulnerability in svc_i3c_master Driver Due to Race Condition In the svc_i3c_master_probe function, &master->hj_work is bound with svc_i3c_master_hj_work, &master->ibi_work is bound with svc_i3c_master_ibi_work. And svc_i3c_master_ibi_work can start the hj_work, svc_i3c_master_irq_handler can start the ibi_work. If we remove the module which will call svc_i3c_master_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | svc_i3c_master_hj_work svc_i3c_master_remove | i3c_master_unregister(&master->base)| device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in svc_i3c_master_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49875", "url": "https://ubuntu.com/security/CVE-2024-49875", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: map the EBADMSG to nfserr_io to avoid warning Ext4 will throw -EBADMSG through ext4_readdir when a checksum error occurs, resulting in the following WARNING. Fix it by mapping EBADMSG to nfserr_io. nfsd_buffered_readdir iterate_dir // -EBADMSG -74 ext4_readdir // .iterate_shared ext4_dx_readdir ext4_htree_fill_tree htree_dirblock_to_tree ext4_read_dirblock __ext4_read_dirblock ext4_dirblock_csum_verify warn_no_space_for_csum __warn_no_space_for_csum return ERR_PTR(-EFSBADCRC) // -EBADMSG -74 nfserrno // WARNING [ 161.115610] ------------[ cut here ]------------ [ 161.116465] nfsd: non-standard errno: -74 [ 161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0 [ 161.118596] Modules linked in: [ 161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138 [ 161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qe mu.org 04/01/2014 [ 161.123601] RIP: 0010:nfserrno+0x9d/0xd0 [ 161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6 05 ce 2b 61 03 01 e8 99 20 d8 00 <0f> 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33 [ 161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286 [ 161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a [ 161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827 [ 161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021 [ 161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8 [ 161.135244] FS: 0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000 [ 161.136695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0 [ 161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 161.141519] PKRU: 55555554 [ 161.142076] Call Trace: [ 161.142575] ? __warn+0x9b/0x140 [ 161.143229] ? nfserrno+0x9d/0xd0 [ 161.143872] ? report_bug+0x125/0x150 [ 161.144595] ? handle_bug+0x41/0x90 [ 161.145284] ? exc_invalid_op+0x14/0x70 [ 161.146009] ? asm_exc_invalid_op+0x12/0x20 [ 161.146816] ? nfserrno+0x9d/0xd0 [ 161.147487] nfsd_buffered_readdir+0x28b/0x2b0 [ 161.148333] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.149258] ? nfsd_buffered_filldir+0xf0/0xf0 [ 161.150093] ? wait_for_concurrent_writes+0x170/0x170 [ 161.151004] ? generic_file_llseek_size+0x48/0x160 [ 161.151895] nfsd_readdir+0x132/0x190 [ 161.152606] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.153516] ? nfsd_unlink+0x380/0x380 [ 161.154256] ? override_creds+0x45/0x60 [ 161.155006] nfsd4_encode_readdir+0x21a/0x3d0 [ 161.155850] ? nfsd4_encode_readlink+0x210/0x210 [ 161.156731] ? write_bytes_to_xdr_buf+0x97/0xe0 [ 161.157598] ? __write_bytes_to_xdr_buf+0xd0/0xd0 [ 161.158494] ? lock_downgrade+0x90/0x90 [ 161.159232] ? nfs4svc_decode_voidarg+0x10/0x10 [ 161.160092] nfsd4_encode_operation+0x15a/0x440 [ 161.160959] nfsd4_proc_compound+0x718/0xe90 [ 161.161818] nfsd_dispatch+0x18e/0x2c0 [ 161.162586] svc_process_common+0x786/0xc50 [ 161.163403] ? nfsd_svc+0x380/0x380 [ 161.164137] ? svc_printk+0x160/0x160 [ 161.164846] ? svc_xprt_do_enqueue.part.0+0x365/0x380 [ 161.165808] ? nfsd_svc+0x380/0x380 [ 161.166523] ? rcu_is_watching+0x23/0x40 [ 161.167309] svc_process+0x1a5/0x200 [ 161.168019] nfsd+0x1f5/0x380 [ 161.168663] ? nfsd_shutdown_threads+0x260/0x260 [ 161.169554] kthread+0x1c4/0x210 [ 161.170224] ? kthread_insert_work_sanity_check+0x80/0x80 [ 161.171246] ret_from_fork+0x1f/0x30", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50013", "url": "https://ubuntu.com/security/CVE-2024-50013", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix memory leak in exfat_load_bitmap() If the first directory entry in the root directory is not a bitmap directory entry, 'bh' will not be released and reassigned, which will cause a memory leak.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49876", "url": "https://ubuntu.com/security/CVE-2024-49876", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: fix UAF around queue destruction We currently do stuff like queuing the final destruction step on a random system wq, which will outlive the driver instance. With bad timing we can teardown the driver with one or more work workqueue still being alive leading to various UAF splats. Add a fini step to ensure user queues are properly torn down. At this point GuC should already be nuked so queue itself should no longer be referenced from hw pov. v2 (Matt B) - Looks much safer to use a waitqueue and then just wait for the xa_array to become empty before triggering the drain. (cherry picked from commit 861108666cc0e999cffeab6aff17b662e68774e3)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49877", "url": "https://ubuntu.com/security/CVE-2024-49877", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate When doing cleanup, if flags without OCFS2_BH_READAHEAD, it may trigger NULL pointer dereference in the following ocfs2_set_buffer_uptodate() if bh is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49957", "url": "https://ubuntu.com/security/CVE-2024-49957", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix null-ptr-deref when journal load failed. During the mounting process, if journal_reset() fails because of too short journal, then lead to jbd2_journal_load() fails with NULL j_sb_buffer. Subsequently, ocfs2_journal_shutdown() calls jbd2_journal_flush()->jbd2_cleanup_journal_tail()-> __jbd2_update_log_tail()->jbd2_journal_update_sb_log_tail() ->lock_buffer(journal->j_sb_buffer), resulting in a null-pointer dereference error. To resolve this issue, we should check the JBD2_LOADED flag to ensure the journal was properly loaded. Additionally, use journal instead of osb->journal directly to simplify the code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49965", "url": "https://ubuntu.com/security/CVE-2024-49965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove unreasonable unlock in ocfs2_read_blocks Patch series \"Misc fixes for ocfs2_read_blocks\", v5. This series contains 2 fixes for ocfs2_read_blocks(). The first patch fix the issue reported by syzbot, which detects bad unlock balance in ocfs2_read_blocks(). The second patch fixes an issue reported by Heming Zhao when reviewing above fix. This patch (of 2): There was a lock release before exiting, so remove the unreasonable unlock.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49966", "url": "https://ubuntu.com/security/CVE-2024-49966", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: cancel dqi_sync_work before freeing oinfo ocfs2_global_read_info() will initialize and schedule dqi_sync_work at the end, if error occurs after successfully reading global quota, it will trigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled: ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16c This reports that there is an active delayed work when freeing oinfo in error handling, so cancel dqi_sync_work first. BTW, return status instead of -1 when .read_file_info fails.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49958", "url": "https://ubuntu.com/security/CVE-2024-49958", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reserve space for inline xattr before attaching reflink tree One of our customers reported a crash and a corrupted ocfs2 filesystem. The crash was due to the detection of corruption. Upon troubleshooting, the fsck -fn output showed the below corruption [EXTENT_LIST_FREE] Extent list in owner 33080590 claims 230 as the next free chain record, but fsck believes the largest valid value is 227. Clamp the next record value? n The stat output from the debugfs.ocfs2 showed the following corruption where the \"Next Free Rec:\" had overshot the \"Count:\" in the root metadata block. Inode: 33080590 Mode: 0640 Generation: 2619713622 (0x9c25a856) FS Generation: 904309833 (0x35e6ac49) CRC32: 00000000 ECC: 0000 Type: Regular Attr: 0x0 Flags: Valid Dynamic Features: (0x16) HasXattr InlineXattr Refcounted Extended Attributes Block: 0 Extended Attributes Inline Size: 256 User: 0 (root) Group: 0 (root) Size: 281320357888 Links: 1 Clusters: 141738 ctime: 0x66911b56 0x316edcb8 -- Fri Jul 12 06:02:30.829349048 2024 atime: 0x66911d6b 0x7f7a28d -- Fri Jul 12 06:11:23.133669517 2024 mtime: 0x66911b56 0x12ed75d7 -- Fri Jul 12 06:02:30.317552087 2024 dtime: 0x0 -- Wed Dec 31 17:00:00 1969 Refcount Block: 2777346 Last Extblk: 2886943 Orphan Slot: 0 Sub Alloc Slot: 0 Sub Alloc Bit: 14 Tree Depth: 1 Count: 227 Next Free Rec: 230 ## Offset Clusters Block# 0 0 2310 2776351 1 2310 2139 2777375 2 4449 1221 2778399 3 5670 731 2779423 4 6401 566 2780447 ....... .... ....... ....... .... ....... The issue was in the reflink workfow while reserving space for inline xattr. The problematic function is ocfs2_reflink_xattr_inline(). By the time this function is called the reflink tree is already recreated at the destination inode from the source inode. At this point, this function reserves space for inline xattrs at the destination inode without even checking if there is space at the root metadata block. It simply reduces the l_count from 243 to 227 thereby making space of 256 bytes for inline xattr whereas the inode already has extents beyond this index (in this case up to 230), thereby causing corruption. The fix for this is to reserve space for inline metadata at the destination inode before the reflink tree gets recreated. The customer has verified the fix.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49959", "url": "https://ubuntu.com/security/CVE-2024-49959", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail() to recover some journal space. But if an error occurs while executing jbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for free space right away, we try other branches, and if j_committing_transaction is NULL (i.e., the tid is 0), we will get the following complain: ============================================ JBD2: I/O error when updating journal superblock for sdd-8. __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available __jbd2_log_wait_for_space: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Call Trace: add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70 [...] ============================================ So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways. Note that this fix relies on commit 6f6a6fda2945 (\"jbd2: fix ocfs2 corrupt when updating journal superblock fails\") to make jbd2_cleanup_journal_tail return the correct error code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49878", "url": "https://ubuntu.com/security/CVE-2024-49878", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: resource: fix region_intersects() vs add_memory_driver_managed() On a system with CXL memory, the resource tree (/proc/iomem) related to CXL memory may look like something as follows. 490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem) Because drivers/dax/kmem.c calls add_memory_driver_managed() during onlining CXL memory, which makes \"System RAM (kmem)\" a descendant of \"CXL Window X\". This confuses region_intersects(), which expects all \"System RAM\" resources to be at the top level of iomem_resource. This can lead to bugs. For example, when the following command line is executed to write some memory in CXL memory range via /dev/mem, $ dd if=data of=/dev/mem bs=$((1 << 10)) seek=$((0x490000000 >> 10)) count=1 dd: error writing '/dev/mem': Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/s the command fails as expected. However, the error code is wrong. It should be \"Operation not permitted\" instead of \"Bad address\". More seriously, the /dev/mem permission checking in devmem_is_allowed() passes incorrectly. Although the accessing is prevented later because ioremap() isn't allowed to map system RAM, it is a potential security issue. During command executing, the following warning is reported in the kernel log for calling ioremap() on system RAM. ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d Call Trace: memremap+0xcb/0x184 xlate_dev_mem_ptr+0x25/0x2f write_mem+0x94/0xfb vfs_write+0x128/0x26d ksys_write+0xac/0xfe do_syscall_64+0x9a/0xfd entry_SYSCALL_64_after_hwframe+0x4b/0x53 The details of command execution process are as follows. In the above resource tree, \"System RAM\" is a descendant of \"CXL Window 0\" instead of a top level resource. So, region_intersects() will report no System RAM resources in the CXL memory region incorrectly, because it only checks the top level resources. Consequently, devmem_is_allowed() will return 1 (allow access via /dev/mem) for CXL memory region incorrectly. Fortunately, ioremap() doesn't allow to map System RAM and reject the access. So, region_intersects() needs to be fixed to work correctly with the resource tree with \"System RAM\" not at top level as above. To fix it, if we found a unmatched resource in the top level, we will continue to search matched resources in its descendant resources. So, we will not miss any matched resources in resource tree anymore. In the new implementation, an example resource tree |------------- \"CXL Window 0\" ------------| |-- \"System RAM\" --| will behave similar as the following fake resource tree for region_intersects(, IORESOURCE_SYSTEM_RAM, ), |-- \"System RAM\" --||-- \"CXL Window 0a\" --| Where \"CXL Window 0a\" is part of the original \"CXL Window 0\" that isn't covered by \"System RAM\".", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49879", "url": "https://ubuntu.com/security/CVE-2024-49879", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm: omapdrm: Add missing check for alloc_ordered_workqueue As it may return NULL pointer and cause NULL pointer dereference. Add check for the return value of alloc_ordered_workqueue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49880", "url": "https://ubuntu.com/security/CVE-2024-49880", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix off by one issue in alloc_flex_gd() Wesley reported an issue: ================================================================== EXT4-fs (dm-5): resizing filesystem from 7168 to 786432 blocks ------------[ cut here ]------------ kernel BUG at fs/ext4/resize.c:324! CPU: 9 UID: 0 PID: 3576 Comm: resize2fs Not tainted 6.11.0+ #27 RIP: 0010:ext4_resize_fs+0x1212/0x12d0 Call Trace: __ext4_ioctl+0x4e0/0x1800 ext4_ioctl+0x12/0x20 __x64_sys_ioctl+0x99/0xd0 x64_sys_call+0x1206/0x20d0 do_syscall_64+0x72/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e ================================================================== While reviewing the patch, Honza found that when adjusting resize_bg in alloc_flex_gd(), it was possible for flex_gd->resize_bg to be bigger than flexbg_size. The reproduction of the problem requires the following: o_group = flexbg_size * 2 * n; o_size = (o_group + 1) * group_size; n_group: [o_group + flexbg_size, o_group + flexbg_size * 2) o_size = (n_group + 1) * group_size; Take n=0,flexbg_size=16 as an example: last:15 |o---------------|--------------n-| o_group:0 resize to n_group:30 The corresponding reproducer is: img=test.img rm -f $img truncate -s 600M $img mkfs.ext4 -F $img -b 1024 -G 16 8M dev=`losetup -f --show $img` mkdir -p /tmp/test mount $dev /tmp/test resize2fs $dev 248M Delete the problematic plus 1 to fix the issue, and add a WARN_ON_ONCE() to prevent the issue from happening again. [ Note: another reproucer which this commit fixes is: img=test.img rm -f $img truncate -s 25MiB $img mkfs.ext4 -b 4096 -E nodiscard,lazy_itable_init=0,lazy_journal_init=0 $img truncate -s 3GiB $img dev=`losetup -f --show $img` mkdir -p /tmp/test mount $dev /tmp/test resize2fs $dev 3G umount $dev losetup -d $dev -- TYT ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49881", "url": "https://ubuntu.com/security/CVE-2024-49881", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: update orig_path in ext4_find_extent() In ext4_find_extent(), if the path is not big enough, we free it and set *orig_path to NULL. But after reallocating and successfully initializing the path, we don't update *orig_path, in which case the caller gets a valid path but a NULL ppath, and this may cause a NULL pointer dereference or a path memory leak. For example: ext4_split_extent path = *ppath = 2000 ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path = 2000); *orig_path = path = NULL; path = kcalloc() = 3000 ext4_split_extent_at(*ppath = NULL) path = *ppath; ex = path[depth].p_ext; // NULL pointer dereference! ================================================================== BUG: kernel NULL pointer dereference, address: 0000000000000010 CPU: 6 UID: 0 PID: 576 Comm: fsstress Not tainted 6.11.0-rc2-dirty #847 RIP: 0010:ext4_split_extent_at+0x6d/0x560 Call Trace: ext4_split_extent.isra.0+0xcb/0x1b0 ext4_ext_convert_to_initialized+0x168/0x6c0 ext4_ext_handle_unwritten_extents+0x325/0x4d0 ext4_ext_map_blocks+0x520/0xdb0 ext4_map_blocks+0x2b0/0x690 ext4_iomap_begin+0x20e/0x2c0 [...] ================================================================== Therefore, *orig_path is updated when the extent lookup succeeds, so that the caller can safely use path or *ppath.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50014", "url": "https://ubuntu.com/security/CVE-2024-50014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix access to uninitialised lock in fc replay path The following kernel trace can be triggered with fstest generic/629 when executed against a filesystem with fast-commit feature enabled: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x66/0x90 register_lock_class+0x759/0x7d0 __lock_acquire+0x85/0x2630 ? __find_get_block+0xb4/0x380 lock_acquire+0xd1/0x2d0 ? __ext4_journal_get_write_access+0xd5/0x160 _raw_spin_lock+0x33/0x40 ? __ext4_journal_get_write_access+0xd5/0x160 __ext4_journal_get_write_access+0xd5/0x160 ext4_reserve_inode_write+0x61/0xb0 __ext4_mark_inode_dirty+0x79/0x270 ? ext4_ext_replay_set_iblocks+0x2f8/0x450 ext4_ext_replay_set_iblocks+0x330/0x450 ext4_fc_replay+0x14c8/0x1540 ? jread+0x88/0x2e0 ? rcu_is_watching+0x11/0x40 do_one_pass+0x447/0xd00 jbd2_journal_recover+0x139/0x1b0 jbd2_journal_load+0x96/0x390 ext4_load_and_init_journal+0x253/0xd40 ext4_fill_super+0x2cc6/0x3180 ... In the replay path there's an attempt to lock sbi->s_bdev_wb_lock in function ext4_check_bdev_write_error(). Unfortunately, at this point this spinlock has not been initialized yet. Moving it's initialization to an earlier point in __ext4_fill_super() fixes this splat.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49960", "url": "https://ubuntu.com/security/CVE-2024-49960", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix timer use-after-free on failed mount Syzbot has found an ODEBUG bug in ext4_fill_super The del_timer_sync function cancels the s_err_report timer, which reminds about filesystem errors daily. We should guarantee the timer is no longer active before kfree(sbi). When filesystem mounting fails, the flow goes to failed_mount3, where an error occurs when ext4_stop_mmpd is called, causing a read I/O failure. This triggers the ext4_handle_error function that ultimately re-arms the timer, leaving the s_err_report timer active before kfree(sbi) is called. Fix the issue by canceling the s_err_report timer after calling ext4_stop_mmpd.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49882", "url": "https://ubuntu.com/security/CVE-2024-49882", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix double brelse() the buffer of the extents path In ext4_ext_try_to_merge_up(), set path[1].p_bh to NULL after it has been released, otherwise it may be released twice. An example of what triggers this is as follows: split2 map split1 |--------|-------|--------| ext4_ext_map_blocks ext4_ext_handle_unwritten_extents ext4_split_convert_extents // path->p_depth == 0 ext4_split_extent // 1. do split1 ext4_split_extent_at |ext4_ext_insert_extent | ext4_ext_create_new_leaf | ext4_ext_grow_indepth | le16_add_cpu(&neh->eh_depth, 1) | ext4_find_extent | // return -ENOMEM |// get error and try zeroout |path = ext4_find_extent | path->p_depth = 1 |ext4_ext_try_to_merge | ext4_ext_try_to_merge_up | path->p_depth = 0 | brelse(path[1].p_bh) ---> not set to NULL here |// zeroout success // 2. update path ext4_find_extent // 3. do split2 ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth le16_add_cpu(&neh->eh_depth, 1) ext4_find_extent path[0].p_bh = NULL; path->p_depth = 1 read_extent_tree_block ---> return err // path[1].p_bh is still the old value ext4_free_ext_path ext4_ext_drop_refs // path->p_depth == 1 brelse(path[1].p_bh) ---> brelse a buffer twice Finally got the following WARRNING when removing the buffer from lru: ============================================ VFS: brelse: Trying to free free buffer WARNING: CPU: 2 PID: 72 at fs/buffer.c:1241 __brelse+0x58/0x90 CPU: 2 PID: 72 Comm: kworker/u19:1 Not tainted 6.9.0-dirty #716 RIP: 0010:__brelse+0x58/0x90 Call Trace: __find_get_block+0x6e7/0x810 bdev_getblk+0x2b/0x480 __ext4_get_inode_loc+0x48a/0x1240 ext4_get_inode_loc+0xb2/0x150 ext4_reserve_inode_write+0xb7/0x230 __ext4_mark_inode_dirty+0x144/0x6a0 ext4_ext_insert_extent+0x9c8/0x3230 ext4_ext_map_blocks+0xf45/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] ============================================", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49883", "url": "https://ubuntu.com/security/CVE-2024-49883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: aovid use-after-free in ext4_ext_insert_extent() As Ojaswin mentioned in Link, in ext4_ext_insert_extent(), if the path is reallocated in ext4_ext_create_new_leaf(), we'll use the stale path and cause UAF. Below is a sample trace with dummy values: ext4_ext_insert_extent path = *ppath = 2000 ext4_ext_create_new_leaf(ppath) ext4_find_extent(ppath) path = *ppath = 2000 if (depth > path[0].p_maxdepth) kfree(path = 2000); *ppath = path = NULL; path = kcalloc() = 3000 *ppath = 3000; return path; /* here path is still 2000, UAF! */ eh = path[depth].p_hdr ================================================================== BUG: KASAN: slab-use-after-free in ext4_ext_insert_extent+0x26d4/0x3330 Read of size 8 at addr ffff8881027bf7d0 by task kworker/u36:1/179 CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 Not tainted 6.11.0-rc2-dirty #866 Call Trace: ext4_ext_insert_extent+0x26d4/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 [...] Allocated by task 179: ext4_find_extent+0x81c/0x1f70 ext4_ext_map_blocks+0x146/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...] Freed by task 179: kfree+0xcb/0x240 ext4_find_extent+0x7c0/0x1f70 ext4_ext_insert_extent+0xa26/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...] ================================================================== So use *ppath to update the path to avoid the above problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49983", "url": "https://ubuntu.com/security/CVE-2024-49983", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-free When calling ext4_force_split_extent_at() in ext4_ext_replay_update_ex(), the 'ppath' is updated but it is the 'path' that is freed, thus potentially triggering a double-free in the following process: ext4_ext_replay_update_ex ppath = path ext4_force_split_extent_at(&ppath) ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path) ---> path First freed *orig_path = path = NULL ---> null ppath kfree(path) ---> path double-free !!! So drop the unnecessary ppath and use path directly to avoid this problem. And use ext4_find_extent() directly to update path, avoiding unnecessary memory allocation and freeing. Also, propagate the error returned by ext4_find_extent() instead of using strange error codes.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50015", "url": "https://ubuntu.com/security/CVE-2024-50015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: dax: fix overflowing extents beyond inode size when partially writing The dax_iomap_rw() does two things in each iteration: map written blocks and copy user data to blocks. If the process is killed by user(See signal handling in dax_iomap_iter()), the copied data will be returned and added on inode size, which means that the length of written extents may exceed the inode size, then fsck will fail. An example is given as: dd if=/dev/urandom of=file bs=4M count=1 dax_iomap_rw iomap_iter // round 1 ext4_iomap_begin ext4_iomap_alloc // allocate 0~2M extents(written flag) dax_iomap_iter // copy 2M data iomap_iter // round 2 iomap_iter_advance iter->pos += iter->processed // iter->pos = 2M ext4_iomap_begin ext4_iomap_alloc // allocate 2~4M extents(written flag) dax_iomap_iter fatal_signal_pending done = iter->pos - iocb->ki_pos // done = 2M ext4_handle_inode_extension ext4_update_inode_size // inode size = 2M fsck reports: Inode 13, i_size is 2097152, should be 4194304. Fix? Fix the problem by truncating extents if the written length is smaller than expected.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49884", "url": "https://ubuntu.com/security/CVE-2024-49884", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix slab-use-after-free in ext4_split_extent_at() We hit the following use-after-free: ================================================================== BUG: KASAN: slab-use-after-free in ext4_split_extent_at+0xba8/0xcc0 Read of size 2 at addr ffff88810548ed08 by task kworker/u20:0/40 CPU: 0 PID: 40 Comm: kworker/u20:0 Not tainted 6.9.0-dirty #724 Call Trace: kasan_report+0x93/0xc0 ext4_split_extent_at+0xba8/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] Allocated by task 40: __kmalloc_noprof+0x1ac/0x480 ext4_find_extent+0xf3b/0x1e70 ext4_ext_map_blocks+0x188/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] Freed by task 40: kfree+0xf1/0x2b0 ext4_find_extent+0xa71/0x1e70 ext4_ext_insert_extent+0xa22/0x3260 ext4_split_extent_at+0x3ef/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] ================================================================== The flow of issue triggering is as follows: ext4_split_extent_at path = *ppath ext4_ext_insert_extent(ppath) ext4_ext_create_new_leaf(ppath) ext4_find_extent(orig_path) path = *orig_path read_extent_tree_block // return -ENOMEM or -EIO ext4_free_ext_path(path) kfree(path) *orig_path = NULL a. If err is -ENOMEM: ext4_ext_dirty(path + path->p_depth) // path use-after-free !!! b. If err is -EIO and we have EXT_DEBUG defined: ext4_ext_show_leaf(path) eh = path[depth].p_hdr // path also use-after-free !!! So when trying to zeroout or fix the extent length, call ext4_find_extent() to update the path. In addition we use *ppath directly as an ext4_ext_show_leaf() input to avoid possible use-after-free when EXT_DEBUG is defined, and to avoid unnecessary path updates.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49885", "url": "https://ubuntu.com/security/CVE-2024-49885", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm, slub: avoid zeroing kmalloc redzone Since commit 946fa0dbf2d8 (\"mm/slub: extend redzone check to extra allocated kmalloc space than requested\"), setting orig_size treats the wasted space (object_size - orig_size) as a redzone. However with init_on_free=1 we clear the full object->size, including the redzone. Additionally we clear the object metadata, including the stored orig_size, making it zero, which makes check_object() treat the whole object as a redzone. These issues lead to the following BUG report with \"slub_debug=FUZ init_on_free=1\": [ 0.000000] ============================================================================= [ 0.000000] BUG kmalloc-8 (Not tainted): kmalloc Redzone overwritten [ 0.000000] ----------------------------------------------------------------------------- [ 0.000000] [ 0.000000] 0xffff000010032858-0xffff00001003285f @offset=2136. First byte 0x0 instead of 0xcc [ 0.000000] FIX kmalloc-8: Restoring kmalloc Redzone 0xffff000010032858-0xffff00001003285f=0xcc [ 0.000000] Slab 0xfffffdffc0400c80 objects=36 used=23 fp=0xffff000010032a18 flags=0x3fffe0000000200(workingset|node=0|zone=0|lastcpupid=0x1ffff) [ 0.000000] Object 0xffff000010032858 @offset=2136 fp=0xffff0000100328c8 [ 0.000000] [ 0.000000] Redzone ffff000010032850: cc cc cc cc cc cc cc cc ........ [ 0.000000] Object ffff000010032858: cc cc cc cc cc cc cc cc ........ [ 0.000000] Redzone ffff000010032860: cc cc cc cc cc cc cc cc ........ [ 0.000000] Padding ffff0000100328b4: 00 00 00 00 00 00 00 00 00 00 00 00 ............ [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.11.0-rc3-next-20240814-00004-g61844c55c3f4 #144 [ 0.000000] Hardware name: NXP i.MX95 19X19 board (DT) [ 0.000000] Call trace: [ 0.000000] dump_backtrace+0x90/0xe8 [ 0.000000] show_stack+0x18/0x24 [ 0.000000] dump_stack_lvl+0x74/0x8c [ 0.000000] dump_stack+0x18/0x24 [ 0.000000] print_trailer+0x150/0x218 [ 0.000000] check_object+0xe4/0x454 [ 0.000000] free_to_partial_list+0x2f8/0x5ec To address the issue, use orig_size to clear the used area. And restore the value of orig_size after clear the remaining area. When CONFIG_SLUB_DEBUG not defined, (get_orig_size()' directly returns s->object_size. So when using memset to init the area, the size can simply be orig_size, as orig_size returns object_size when CONFIG_SLUB_DEBUG not enabled. And orig_size can never be bigger than object_size.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49961", "url": "https://ubuntu.com/security/CVE-2024-49961", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: ar0521: Use cansleep version of gpiod_set_value() If we use GPIO reset from I2C port expander, we must use *_cansleep() variant of GPIO functions. This was not done in ar0521_power_on()/ar0521_power_off() functions. Let's fix that. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 11 at drivers/gpio/gpiolib.c:3496 gpiod_set_value+0x74/0x7c Modules linked in: CPU: 0 PID: 11 Comm: kworker/u16:0 Not tainted 6.10.0 #53 Hardware name: Diasom DS-RK3568-SOM-EVB (DT) Workqueue: events_unbound deferred_probe_work_func pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : gpiod_set_value+0x74/0x7c lr : ar0521_power_on+0xcc/0x290 sp : ffffff8001d7ab70 x29: ffffff8001d7ab70 x28: ffffff80027dcc90 x27: ffffff8003c82000 x26: ffffff8003ca9250 x25: ffffffc080a39c60 x24: ffffff8003ca9088 x23: ffffff8002402720 x22: ffffff8003ca9080 x21: ffffff8003ca9088 x20: 0000000000000000 x19: ffffff8001eb2a00 x18: ffffff80efeeac80 x17: 756d2d6332692f30 x16: 0000000000000000 x15: 0000000000000000 x14: ffffff8001d91d40 x13: 0000000000000016 x12: ffffffc080e98930 x11: ffffff8001eb2880 x10: 0000000000000890 x9 : ffffff8001d7a9f0 x8 : ffffff8001d92570 x7 : ffffff80efeeac80 x6 : 000000003fc6e780 x5 : ffffff8001d91c80 x4 : 0000000000000002 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000001 Call trace: gpiod_set_value+0x74/0x7c ar0521_power_on+0xcc/0x290 ...", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49985", "url": "https://ubuntu.com/security/CVE-2024-49985", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume In case there is any sort of clock controller attached to this I2C bus controller, for example Versaclock or even an AIC32x4 I2C codec, then an I2C transfer triggered from the clock controller clk_ops .prepare callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex. This is because the clock controller first grabs the prepare_lock mutex and then performs the prepare operation, including its I2C access. The I2C access resumes this I2C bus controller via .runtime_resume callback, which calls clk_prepare_enable(), which attempts to grab the prepare_lock mutex again and deadlocks. Since the clock are already prepared since probe() and unprepared in remove(), use simple clk_enable()/clk_disable() calls to enable and disable the clock on runtime suspend and resume, to avoid hitting the prepare_lock mutex.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49886", "url": "https://ubuntu.com/security/CVE-2024-49886", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bug Attaching SST PCI device to VM causes \"BUG: KASAN: slab-out-of-bounds\". kasan report: [ 19.411889] ================================================================== [ 19.413702] BUG: KASAN: slab-out-of-bounds in _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.415634] Read of size 8 at addr ffff888829e65200 by task cpuhp/16/113 [ 19.417368] [ 19.418627] CPU: 16 PID: 113 Comm: cpuhp/16 Tainted: G E 6.9.0 #10 [ 19.420435] Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.20192059.B64.2207280713 07/28/2022 [ 19.422687] Call Trace: [ 19.424091] [ 19.425448] dump_stack_lvl+0x5d/0x80 [ 19.426963] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.428694] print_report+0x19d/0x52e [ 19.430206] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 19.431837] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.433539] kasan_report+0xf0/0x170 [ 19.435019] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.436709] _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.438379] ? __pfx_sched_clock_cpu+0x10/0x10 [ 19.439910] isst_if_cpu_online+0x406/0x58f [isst_if_common] [ 19.441573] ? __pfx_isst_if_cpu_online+0x10/0x10 [isst_if_common] [ 19.443263] ? ttwu_queue_wakelist+0x2c1/0x360 [ 19.444797] cpuhp_invoke_callback+0x221/0xec0 [ 19.446337] cpuhp_thread_fun+0x21b/0x610 [ 19.447814] ? __pfx_cpuhp_thread_fun+0x10/0x10 [ 19.449354] smpboot_thread_fn+0x2e7/0x6e0 [ 19.450859] ? __pfx_smpboot_thread_fn+0x10/0x10 [ 19.452405] kthread+0x29c/0x350 [ 19.453817] ? __pfx_kthread+0x10/0x10 [ 19.455253] ret_from_fork+0x31/0x70 [ 19.456685] ? __pfx_kthread+0x10/0x10 [ 19.458114] ret_from_fork_asm+0x1a/0x30 [ 19.459573] [ 19.460853] [ 19.462055] Allocated by task 1198: [ 19.463410] kasan_save_stack+0x30/0x50 [ 19.464788] kasan_save_track+0x14/0x30 [ 19.466139] __kasan_kmalloc+0xaa/0xb0 [ 19.467465] __kmalloc+0x1cd/0x470 [ 19.468748] isst_if_cdev_register+0x1da/0x350 [isst_if_common] [ 19.470233] isst_if_mbox_init+0x108/0xff0 [isst_if_mbox_msr] [ 19.471670] do_one_initcall+0xa4/0x380 [ 19.472903] do_init_module+0x238/0x760 [ 19.474105] load_module+0x5239/0x6f00 [ 19.475285] init_module_from_file+0xd1/0x130 [ 19.476506] idempotent_init_module+0x23b/0x650 [ 19.477725] __x64_sys_finit_module+0xbe/0x130 [ 19.476506] idempotent_init_module+0x23b/0x650 [ 19.477725] __x64_sys_finit_module+0xbe/0x130 [ 19.478920] do_syscall_64+0x82/0x160 [ 19.480036] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 19.481292] [ 19.482205] The buggy address belongs to the object at ffff888829e65000 which belongs to the cache kmalloc-512 of size 512 [ 19.484818] The buggy address is located 0 bytes to the right of allocated 512-byte region [ffff888829e65000, ffff888829e65200) [ 19.487447] [ 19.488328] The buggy address belongs to the physical page: [ 19.489569] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888829e60c00 pfn:0x829e60 [ 19.491140] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [ 19.492466] anon flags: 0x57ffffc0000840(slab|head|node=1|zone=2|lastcpupid=0x1fffff) [ 19.493914] page_type: 0xffffffff() [ 19.494988] raw: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [ 19.496451] raw: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [ 19.497906] head: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [ 19.499379] head: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [ 19.500844] head: 0057ffffc0000003 ffffea0020a79801 ffffea0020a79848 00000000ffffffff [ 19.502316] head: 0000000800000000 0000000000000000 00000000ffffffff 0000000000000000 [ 19.503784] page dumped because: k ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49986", "url": "https://ubuntu.com/security/CVE-2024-49986", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: x86-android-tablets: Fix use after free on platform_device_register() errors x86_android_tablet_remove() frees the pdevs[] array, so it should not be used after calling x86_android_tablet_remove(). When platform_device_register() fails, store the pdevs[x] PTR_ERR() value into the local ret variable before calling x86_android_tablet_remove() to avoid using pdevs[] after it has been freed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49887", "url": "https://ubuntu.com/security/CVE-2024-49887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to don't panic system for no free segment fault injection f2fs: fix to don't panic system for no free segment fault injection syzbot reports a f2fs bug as below: F2FS-fs (loop0): inject no free segment in get_new_segment of __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3167 F2FS-fs (loop0): Stopped filesystem due to reason: 7 ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2748! CPU: 0 UID: 0 PID: 5109 Comm: syz-executor304 Not tainted 6.11.0-rc6-syzkaller-00363-g89f5e14d05b4 #0 RIP: 0010:get_new_segment fs/f2fs/segment.c:2748 [inline] RIP: 0010:new_curseg+0x1f61/0x1f70 fs/f2fs/segment.c:2836 Call Trace: __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3167 f2fs_allocate_new_section fs/f2fs/segment.c:3181 [inline] f2fs_allocate_pinning_section+0xfa/0x4e0 fs/f2fs/segment.c:3195 f2fs_expand_inode_data+0x5d6/0xbb0 fs/f2fs/file.c:1799 f2fs_fallocate+0x448/0x960 fs/f2fs/file.c:1903 vfs_fallocate+0x553/0x6c0 fs/open.c:334 do_vfs_ioctl+0x2592/0x2e50 fs/ioctl.c:886 __do_sys_ioctl fs/ioctl.c:905 [inline] __se_sys_ioctl+0x81/0x170 fs/ioctl.c:893 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: 0010:get_new_segment fs/f2fs/segment.c:2748 [inline] RIP: 0010:new_curseg+0x1f61/0x1f70 fs/f2fs/segment.c:2836 The root cause is when we inject no free segment fault into f2fs, we should not panic system, fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49888", "url": "https://ubuntu.com/security/CVE-2024-49888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix a sdiv overflow issue Zac Ecob reported a problem where a bpf program may cause kernel crash due to the following error: Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI The failure is due to the below signed divide: LLONG_MIN/-1 where LLONG_MIN equals to -9,223,372,036,854,775,808. LLONG_MIN/-1 is supposed to give a positive number 9,223,372,036,854,775,808, but it is impossible since for 64-bit system, the maximum positive number is 9,223,372,036,854,775,807. On x86_64, LLONG_MIN/-1 will cause a kernel exception. On arm64, the result for LLONG_MIN/-1 is LLONG_MIN. Further investigation found all the following sdiv/smod cases may trigger an exception when bpf program is running on x86_64 platform: - LLONG_MIN/-1 for 64bit operation - INT_MIN/-1 for 32bit operation - LLONG_MIN%-1 for 64bit operation - INT_MIN%-1 for 32bit operation where -1 can be an immediate or in a register. On arm64, there are no exceptions: - LLONG_MIN/-1 = LLONG_MIN - INT_MIN/-1 = INT_MIN - LLONG_MIN%-1 = 0 - INT_MIN%-1 = 0 where -1 can be an immediate or in a register. Insn patching is needed to handle the above cases and the patched codes produced results aligned with above arm64 result. The below are pseudo codes to handle sdiv/smod exceptions including both divisor -1 and divisor 0 and the divisor is stored in a register. sdiv: tmp = rX tmp += 1 /* [-1, 0] -> [0, 1] if tmp >(unsigned) 1 goto L2 if tmp == 0 goto L1 rY = 0 L1: rY = -rY; goto L3 L2: rY /= rX L3: smod: tmp = rX tmp += 1 /* [-1, 0] -> [0, 1] if tmp >(unsigned) 1 goto L1 if tmp == 1 (is64 ? goto L2 : goto L3) rY = 0; goto L2 L1: rY %= rX L2: goto L4 // only when !is64 L3: wY = wY // only when !is64 L4: [1] https://lore.kernel.org/bpf/tPJLTEh7S_DxFEqAI2Ji5MBSoZVg7_G-Py2iaZpAaWtM961fFTWtsnlzwvTbzBzaUzwQAoNATXKUlt0LZOFgnDcIyKCswAnAGdUF3LBrhGQ=@protonmail.com/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49987", "url": "https://ubuntu.com/security/CVE-2024-49987", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpftool: Fix undefined behavior in qsort(NULL, 0, ...) When netfilter has no entry to display, qsort is called with qsort(NULL, 0, ...). This results in undefined behavior, as UBSan reports: net.c:827:2: runtime error: null pointer passed as argument 1, which is declared to never be null Although the C standard does not explicitly state whether calling qsort with a NULL pointer when the size is 0 constitutes undefined behavior, Section 7.1.4 of the C standard (Use of library functions) mentions: \"Each of the following statements applies unless explicitly stated otherwise in the detailed descriptions that follow: If an argument to a function has an invalid value (such as a value outside the domain of the function, or a pointer outside the address space of the program, or a null pointer, or a pointer to non-modifiable storage when the corresponding parameter is not const-qualified) or a type (after promotion) not expected by a function with variable number of arguments, the behavior is undefined.\" To avoid this, add an early return when nf_link_info is NULL to prevent calling qsort with a NULL pointer.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50006", "url": "https://ubuntu.com/security/CVE-2024-50006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix i_data_sem unlock order in ext4_ind_migrate() Fuzzing reports a possible deadlock in jbd2_log_wait_commit. This issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to require synchronous updates because the file descriptor is opened with O_SYNC. This can lead to the jbd2_journal_stop() function calling jbd2_might_wait_for_commit(), potentially causing a deadlock if the EXT4_IOC_MIGRATE call races with a write(2) system call. This problem only arises when CONFIG_PROVE_LOCKING is enabled. In this case, the jbd2_might_wait_for_commit macro locks jbd2_handle in the jbd2_journal_stop function while i_data_sem is locked. This triggers lockdep because the jbd2_journal_start function might also lock the same jbd2_handle simultaneously. Found by Linux Verification Center (linuxtesting.org) with syzkaller. Rule: add", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49889", "url": "https://ubuntu.com/security/CVE-2024-49889", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid use-after-free in ext4_ext_show_leaf() In ext4_find_extent(), path may be freed by error or be reallocated, so using a previously saved *ppath may have been freed and thus may trigger use-after-free, as follows: ext4_split_extent path = *ppath; ext4_split_extent_at(ppath) path = ext4_find_extent(ppath) ext4_split_extent_at(ppath) // ext4_find_extent fails to free path // but zeroout succeeds ext4_ext_show_leaf(inode, path) eh = path[depth].p_hdr // path use-after-free !!! Similar to ext4_split_extent_at(), we use *ppath directly as an input to ext4_ext_show_leaf(). Fix a spelling error by the way. Same problem in ext4_ext_handle_unwritten_extents(). Since 'path' is only used in ext4_ext_show_leaf(), remove 'path' and use *ppath directly. This issue is triggered only when EXT_DEBUG is defined and therefore does not affect functionality.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49968", "url": "https://ubuntu.com/security/CVE-2024-49968", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: filesystems without casefold feature cannot be mounted with siphash When mounting the ext4 filesystem, if the default hash version is set to DX_HASH_SIPHASH but the casefold feature is not set, exit the mounting.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49988", "url": "https://ubuntu.com/security/CVE-2024-49988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: add refcnt to ksmbd_conn struct When sending an oplock break request, opinfo->conn is used, But freed ->conn can be used on multichannel. This patch add a reference count to the ksmbd_conn struct so that it can be freed when it is no longer used.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49890", "url": "https://ubuntu.com/security/CVE-2024-49890", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: ensure the fw_info is not null before using it This resolves the dereference null return value warning reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49891", "url": "https://ubuntu.com/security/CVE-2024-49891", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata paths When the HBA is undergoing a reset or is handling an errata event, NULL ptr dereference crashes may occur in routines such as lpfc_sli_flush_io_rings(), lpfc_dev_loss_tmo_callbk(), or lpfc_abort_handler(). Add NULL ptr checks before dereferencing hdwq pointers that may have been freed due to operations colliding with a reset or errata event handler.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49892", "url": "https://ubuntu.com/security/CVE-2024-49892", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize get_bytes_per_element's default to 1 Variables, used as denominators and maybe not assigned to other values, should not be 0. bytes_per_element_y & bytes_per_element_c are initialized by get_bytes_per_element() which should never return 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50016", "url": "https://ubuntu.com/security/CVE-2024-50016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Avoid overflow assignment in link_dp_cts sampling_rate is an uint8_t but is assigned an unsigned int, and thus it can overflow. As a result, sampling_rate is changed to uint32_t. Similarly, LINK_QUAL_PATTERN_SET has a size of 2 bits, and it should only be assigned to a value less or equal than 4. This fixes 2 INTEGER_OVERFLOW issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49893", "url": "https://ubuntu.com/security/CVE-2024-49893", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check stream_status before it is used [WHAT & HOW] dc_state_get_stream_status can return null, and therefore null must be checked before stream_status is used. This fixes 1 NULL_RETURNS issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49969", "url": "https://ubuntu.com/security/CVE-2024-49969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 color transformation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_hw_format` function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:180 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:181 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:182 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49970", "url": "https://ubuntu.com/security/CVE-2024-49970", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Implement bounds check for stream encoder creation in DCN401 'stream_enc_regs' array is an array of dcn10_stream_enc_registers structures. The array is initialized with four elements, corresponding to the four calls to stream_enc_regs() in the array initializer. This means that valid indices for this array are 0, 1, 2, and 3. The error message 'stream_enc_regs' 4 <= 5 below, is indicating that there is an attempt to access this array with an index of 5, which is out of bounds. This could lead to undefined behavior Here, eng_id is used as an index to access the stream_enc_regs array. If eng_id is 5, this would result in an out-of-bounds access on the stream_enc_regs array. Thus fixing Buffer overflow error in dcn401_stream_encoder_create Found by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn401/dcn401_resource.c:1209 dcn401_stream_encoder_create() error: buffer overflow 'stream_enc_regs' 4 <= 5", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49894", "url": "https://ubuntu.com/security/CVE-2024-49894", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in degamma hardware format translation Fixes index out of bounds issue in `cm_helper_translate_curve_to_degamma_hw_format` function. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49895", "url": "https://ubuntu.com/security/CVE-2024-49895", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format translation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_degamma_hw_format` function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:338 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:339 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:340 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49971", "url": "https://ubuntu.com/security/CVE-2024-49971", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Increase array size of dummy_boolean [WHY] dml2_core_shared_mode_support and dml_core_mode_support access the third element of dummy_boolean, i.e. hw_debug5 = &s->dummy_boolean[2], when dummy_boolean has size of 2. Any assignment to hw_debug5 causes an OVERRUN. [HOW] Increase dummy_boolean's array size to 3. This fixes 2 OVERRUN issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49972", "url": "https://ubuntu.com/security/CVE-2024-49972", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Deallocate DML memory if allocation fails [Why] When DC state create DML memory allocation fails, memory is not deallocated subsequently, resulting in uninitialized structure that is not NULL. [How] Deallocate memory if DML memory allocation fails.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49896", "url": "https://ubuntu.com/security/CVE-2024-49896", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check stream before comparing them [WHAT & HOW] amdgpu_dm can pass a null stream to dc_is_stream_unchanged. It is necessary to check for null before dereferencing them. This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49897", "url": "https://ubuntu.com/security/CVE-2024-49897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check phantom_stream before it is used dcn32_enable_phantom_stream can return null, so returned value must be checked before used. This fixes 1 NULL_RETURNS issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49898", "url": "https://ubuntu.com/security/CVE-2024-49898", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null-initialized variables [WHAT & HOW] drr_timing and subvp_pipe are initialized to null and they are not always assigned new values. It is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49899", "url": "https://ubuntu.com/security/CVE-2024-49899", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize denominators' default to 1 [WHAT & HOW] Variables used as denominators and maybe not assigned to other values, should not be 0. Change their default to 1 so they are never 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49900", "url": "https://ubuntu.com/security/CVE-2024-49900", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uninit-value access of new_ea in ea_buffer syzbot reports that lzo1x_1_do_compress is using uninit-value: ===================================================== BUG: KMSAN: uninit-value in lzo1x_1_do_compress+0x19f9/0x2510 lib/lzo/lzo1x_compress.c:178 ... Uninit was stored to memory at: ea_put fs/jfs/xattr.c:639 [inline] ... Local variable ea_buf created at: __jfs_setxattr+0x5d/0x1ae0 fs/jfs/xattr.c:662 __jfs_xattr_set+0xe6/0x1f0 fs/jfs/xattr.c:934 ===================================================== The reason is ea_buf->new_ea is not initialized properly. Fix this by using memset to empty its content at the beginning in ea_get().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49901", "url": "https://ubuntu.com/security/CVE-2024-49901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm/adreno: Assign msm_gpu->pdev earlier to avoid nullptrs There are some cases, such as the one uncovered by Commit 46d4efcccc68 (\"drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails\") where msm_gpu_cleanup() : platform_set_drvdata(gpu->pdev, NULL); is called on gpu->pdev == NULL, as the GPU device has not been fully initialized yet. Turns out that there's more than just the aforementioned path that causes this to happen (e.g. the case when there's speedbin data in the catalog, but opp-supported-hw is missing in DT). Assigning msm_gpu->pdev earlier seems like the least painful solution to this, therefore do so. Patchwork: https://patchwork.freedesktop.org/patch/602742/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49902", "url": "https://ubuntu.com/security/CVE-2024-49902", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: check if leafidx greater than num leaves per dmap tree syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf. Shaggy: Modified sanity check to apply to control pages as well as leaf pages.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49903", "url": "https://ubuntu.com/security/CVE-2024-49903", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uaf in dbFreeBits [syzbot reported] ================================================================== BUG: KASAN: slab-use-after-free in __mutex_lock_common kernel/locking/mutex.c:587 [inline] BUG: KASAN: slab-use-after-free in __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 Read of size 8 at addr ffff8880229254b0 by task syz-executor357/5216 CPU: 0 UID: 0 PID: 5216 Comm: syz-executor357 Not tainted 6.11.0-rc3-syzkaller-00156-gd7a5aa4b3c00 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 __mutex_lock_common kernel/locking/mutex.c:587 [inline] __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 dbFreeBits+0x7ea/0xd90 fs/jfs/jfs_dmap.c:2390 dbFreeDmap fs/jfs/jfs_dmap.c:2089 [inline] dbFree+0x35b/0x680 fs/jfs/jfs_dmap.c:409 dbDiscardAG+0x8a9/0xa20 fs/jfs/jfs_dmap.c:1650 jfs_ioc_trim+0x433/0x670 fs/jfs/jfs_discard.c:100 jfs_ioctl+0x2d0/0x3e0 fs/jfs/ioctl.c:131 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 Freed by task 5218: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object+0xe0/0x150 mm/kasan/common.c:240 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2252 [inline] slab_free mm/slub.c:4473 [inline] kfree+0x149/0x360 mm/slub.c:4594 dbUnmount+0x11d/0x190 fs/jfs/jfs_dmap.c:278 jfs_mount_rw+0x4ac/0x6a0 fs/jfs/jfs_mount.c:247 jfs_remount+0x3d1/0x6b0 fs/jfs/super.c:454 reconfigure_super+0x445/0x880 fs/super.c:1083 vfs_cmd_reconfigure fs/fsopen.c:263 [inline] vfs_fsconfig_locked fs/fsopen.c:292 [inline] __do_sys_fsconfig fs/fsopen.c:473 [inline] __se_sys_fsconfig+0xb6e/0xf80 fs/fsopen.c:345 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 [Analysis] There are two paths (dbUnmount and jfs_ioc_trim) that generate race condition when accessing bmap, which leads to the occurrence of uaf. Use the lock s_umount to synchronize them, in order to avoid uaf caused by race condition.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49904", "url": "https://ubuntu.com/security/CVE-2024-49904", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add list empty check to avoid null pointer issue Add list empty check to avoid null pointer issues in some corner cases. - list_for_each_entry_safe()", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49989", "url": "https://ubuntu.com/security/CVE-2024-49989", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix double free issue during amdgpu module unload Flexible endpoints use DIGs from available inflexible endpoints, so only the encoders of inflexible links need to be freed. Otherwise, a double free issue may occur when unloading the amdgpu module. [ 279.190523] RIP: 0010:__slab_free+0x152/0x2f0 [ 279.190577] Call Trace: [ 279.190580] [ 279.190582] ? show_regs+0x69/0x80 [ 279.190590] ? die+0x3b/0x90 [ 279.190595] ? do_trap+0xc8/0xe0 [ 279.190601] ? do_error_trap+0x73/0xa0 [ 279.190605] ? __slab_free+0x152/0x2f0 [ 279.190609] ? exc_invalid_op+0x56/0x70 [ 279.190616] ? __slab_free+0x152/0x2f0 [ 279.190642] ? asm_exc_invalid_op+0x1f/0x30 [ 279.190648] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191096] ? __slab_free+0x152/0x2f0 [ 279.191102] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191469] kfree+0x260/0x2b0 [ 279.191474] dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191821] link_destroy+0xd7/0x130 [amdgpu] [ 279.192248] dc_destruct+0x90/0x270 [amdgpu] [ 279.192666] dc_destroy+0x19/0x40 [amdgpu] [ 279.193020] amdgpu_dm_fini+0x16e/0x200 [amdgpu] [ 279.193432] dm_hw_fini+0x26/0x40 [amdgpu] [ 279.193795] amdgpu_device_fini_hw+0x24c/0x400 [amdgpu] [ 279.194108] amdgpu_driver_unload_kms+0x4f/0x70 [amdgpu] [ 279.194436] amdgpu_pci_remove+0x40/0x80 [amdgpu] [ 279.194632] pci_device_remove+0x3a/0xa0 [ 279.194638] device_remove+0x40/0x70 [ 279.194642] device_release_driver_internal+0x1ad/0x210 [ 279.194647] driver_detach+0x4e/0xa0 [ 279.194650] bus_remove_driver+0x6f/0xf0 [ 279.194653] driver_unregister+0x33/0x60 [ 279.194657] pci_unregister_driver+0x44/0x90 [ 279.194662] amdgpu_exit+0x19/0x1f0 [amdgpu] [ 279.194939] __do_sys_delete_module.isra.0+0x198/0x2f0 [ 279.194946] __x64_sys_delete_module+0x16/0x20 [ 279.194950] do_syscall_64+0x58/0x120 [ 279.194954] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 279.194980] ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49905", "url": "https://ubuntu.com/security/CVE-2024-49905", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for 'afb' in amdgpu_dm_plane_handle_cursor_update (v2) This commit adds a null check for the 'afb' variable in the amdgpu_dm_plane_handle_cursor_update function. Previously, 'afb' was assumed to be null, but was used later in the code without a null check. This could potentially lead to a null pointer dereference. Changes since v1: - Moved the null check for 'afb' to the line where 'afb' is used. (Alex) Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:1298 amdgpu_dm_plane_handle_cursor_update() error: we previously assumed 'afb' could be null (see line 1252)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49906", "url": "https://ubuntu.com/security/CVE-2024-49906", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before try to access it [why & how] Change the order of the pipe_ctx->plane_state check to ensure that plane_state is not null before accessing it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49907", "url": "https://ubuntu.com/security/CVE-2024-49907", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before using dc->clk_mgr [WHY & HOW] dc->clk_mgr is null checked previously in the same function, indicating it might be null. Passing \"dc\" to \"dc->hwss.apply_idle_power_optimizations\", which dereferences null \"dc->clk_mgr\". (The function pointer resolves to \"dcn35_apply_idle_power_optimizations\".) This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49908", "url": "https://ubuntu.com/security/CVE-2024-49908", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for 'afb' in amdgpu_dm_update_cursor (v2) This commit adds a null check for the 'afb' variable in the amdgpu_dm_update_cursor function. Previously, 'afb' was assumed to be null at line 8388, but was used later in the code without a null check. This could potentially lead to a null pointer dereference. Changes since v1: - Moved the null check for 'afb' to the line where 'afb' is used. (Alex) Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:8433 amdgpu_dm_update_cursor() \terror: we previously assumed 'afb' could be null (see line 8388)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50177", "url": "https://ubuntu.com/security/CVE-2024-50177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix a UBSAN warning in DML2.1 When programming phantom pipe, since cursor_width is explicity set to 0, this causes calculation logic to trigger overflow for an unsigned int triggering the kernel's UBSAN check as below: [ 40.962845] UBSAN: shift-out-of-bounds in /tmp/amd.EfpumTkO/amd/amdgpu/../display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c:3312:34 [ 40.962849] shift exponent 4294967170 is too large for 32-bit type 'unsigned int' [ 40.962852] CPU: 1 PID: 1670 Comm: gnome-shell Tainted: G W OE 6.5.0-41-generic #41~22.04.2-Ubuntu [ 40.962854] Hardware name: Gigabyte Technology Co., Ltd. X670E AORUS PRO X/X670E AORUS PRO X, BIOS F21 01/10/2024 [ 40.962856] Call Trace: [ 40.962857] [ 40.962860] dump_stack_lvl+0x48/0x70 [ 40.962870] dump_stack+0x10/0x20 [ 40.962872] __ubsan_handle_shift_out_of_bounds+0x1ac/0x360 [ 40.962878] calculate_cursor_req_attributes.cold+0x1b/0x28 [amdgpu] [ 40.963099] dml_core_mode_support+0x6b91/0x16bc0 [amdgpu] [ 40.963327] ? srso_alias_return_thunk+0x5/0x7f [ 40.963331] ? CalculateWatermarksMALLUseAndDRAMSpeedChangeSupport+0x18b8/0x2790 [amdgpu] [ 40.963534] ? srso_alias_return_thunk+0x5/0x7f [ 40.963536] ? dml_core_mode_support+0xb3db/0x16bc0 [amdgpu] [ 40.963730] dml2_core_calcs_mode_support_ex+0x2c/0x90 [amdgpu] [ 40.963906] ? srso_alias_return_thunk+0x5/0x7f [ 40.963909] ? dml2_core_calcs_mode_support_ex+0x2c/0x90 [amdgpu] [ 40.964078] core_dcn4_mode_support+0x72/0xbf0 [amdgpu] [ 40.964247] dml2_top_optimization_perform_optimization_phase+0x1d3/0x2a0 [amdgpu] [ 40.964420] dml2_build_mode_programming+0x23d/0x750 [amdgpu] [ 40.964587] dml21_validate+0x274/0x770 [amdgpu] [ 40.964761] ? srso_alias_return_thunk+0x5/0x7f [ 40.964763] ? resource_append_dpp_pipes_for_plane_composition+0x27c/0x3b0 [amdgpu] [ 40.964942] dml2_validate+0x504/0x750 [amdgpu] [ 40.965117] ? dml21_copy+0x95/0xb0 [amdgpu] [ 40.965291] ? srso_alias_return_thunk+0x5/0x7f [ 40.965295] dcn401_validate_bandwidth+0x4e/0x70 [amdgpu] [ 40.965491] update_planes_and_stream_state+0x38d/0x5c0 [amdgpu] [ 40.965672] update_planes_and_stream_v3+0x52/0x1e0 [amdgpu] [ 40.965845] ? srso_alias_return_thunk+0x5/0x7f [ 40.965849] dc_update_planes_and_stream+0x71/0xb0 [amdgpu] Fix this by adding a guard for checking cursor width before triggering the size calculation.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49909", "url": "https://ubuntu.com/security/CVE-2024-49909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn32_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn32_set_output_transfer_func function. Previously, set_output_gamma was being checked for null, but then it was being dereferenced without any null check. This could lead to a null pointer dereference if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49910", "url": "https://ubuntu.com/security/CVE-2024-49910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn401_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn401_set_output_transfer_func function. Previously, set_output_gamma was being checked for null, but then it was being dereferenced without any null check. This could lead to a null pointer dereference if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49911", "url": "https://ubuntu.com/security/CVE-2024-49911", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn20_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn20_set_output_transfer_func function. Previously, set_output_gamma was being checked for null at line 1030, but then it was being dereferenced without any null check at line 1048. This could potentially lead to a null pointer dereference error if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma at line 1048.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49912", "url": "https://ubuntu.com/security/CVE-2024-49912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Handle null 'stream_status' in 'planes_changed_for_existing_stream' This commit adds a null check for 'stream_status' in the function 'planes_changed_for_existing_stream'. Previously, the code assumed 'stream_status' could be null, but did not handle the case where it was actually null. This could lead to a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:3784 planes_changed_for_existing_stream() error: we previously assumed 'stream_status' could be null (see line 3774)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49913", "url": "https://ubuntu.com/security/CVE-2024-49913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for top_pipe_to_program in commit_planes_for_stream This commit addresses a null pointer dereference issue in the `commit_planes_for_stream` function at line 4140. The issue could occur when `top_pipe_to_program` is null. The fix adds a check to ensure `top_pipe_to_program` is not null before accessing its stream_res. This prevents a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:4140 commit_planes_for_stream() error: we previously assumed 'top_pipe_to_program' could be null (see line 3906)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49914", "url": "https://ubuntu.com/security/CVE-2024-49914", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for pipe_ctx->plane_state in dcn20_program_pipe This commit addresses a null pointer dereference issue in the `dcn20_program_pipe` function. The issue could occur when `pipe_ctx->plane_state` is null. The fix adds a check to ensure `pipe_ctx->plane_state` is not null before accessing. This prevents a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn20/dcn20_hwseq.c:1925 dcn20_program_pipe() error: we previously assumed 'pipe_ctx->plane_state' could be null (see line 1877)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49915", "url": "https://ubuntu.com/security/CVE-2024-49915", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr in dcn32_init_hw This commit addresses a potential null pointer dereference issue in the `dcn32_init_hw` function. The issue could occur when `dc->clk_mgr` is null. The fix adds a check to ensure `dc->clk_mgr` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn32/dcn32_hwseq.c:961 dcn32_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 782)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49916", "url": "https://ubuntu.com/security/CVE-2024-49916", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in dcn401_init_hw This commit addresses a potential null pointer dereference issue in the `dcn401_init_hw` function. The issue could occur when `dc->clk_mgr` or `dc->clk_mgr->funcs` is null. The fix adds a check to ensure `dc->clk_mgr` and `dc->clk_mgr->funcs` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn401/dcn401_hwseq.c:416 dcn401_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 225)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49917", "url": "https://ubuntu.com/security/CVE-2024-49917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in dcn30_init_hw This commit addresses a potential null pointer dereference issue in the `dcn30_init_hw` function. The issue could occur when `dc->clk_mgr` or `dc->clk_mgr->funcs` is null. The fix adds a check to ensure `dc->clk_mgr` and `dc->clk_mgr->funcs` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:789 dcn30_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 628)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49918", "url": "https://ubuntu.com/security/CVE-2024-49918", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for head_pipe in dcn32_acquire_idle_pipe_for_head_pipe_in_layer This commit addresses a potential null pointer dereference issue in the `dcn32_acquire_idle_pipe_for_head_pipe_in_layer` function. The issue could occur when `head_pipe` is null. The fix adds a check to ensure `head_pipe` is not null before asserting it. If `head_pipe` is null, the function returns NULL to prevent a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn32/dcn32_resource.c:2690 dcn32_acquire_idle_pipe_for_head_pipe_in_layer() error: we previously assumed 'head_pipe' could be null (see line 2681)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49919", "url": "https://ubuntu.com/security/CVE-2024-49919", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for head_pipe in dcn201_acquire_free_pipe_for_layer This commit addresses a potential null pointer dereference issue in the `dcn201_acquire_free_pipe_for_layer` function. The issue could occur when `head_pipe` is null. The fix adds a check to ensure `head_pipe` is not null before asserting it. If `head_pipe` is null, the function returns NULL to prevent a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn201/dcn201_resource.c:1016 dcn201_acquire_free_pipe_for_layer() error: we previously assumed 'head_pipe' could be null (see line 1010)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49991", "url": "https://ubuntu.com/security/CVE-2024-49991", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer Pass pointer reference to amdgpu_bo_unref to clear the correct pointer, otherwise amdgpu_bo_unref clear the local variable, the original pointer not set to NULL, this could cause use-after-free bug.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49920", "url": "https://ubuntu.com/security/CVE-2024-49920", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before multiple uses [WHAT & HOW] Poniters, such as stream_enc and dc->bw_vbios, are null checked previously in the same function, so Coverity warns \"implies that stream_enc and dc->bw_vbios might be null\". They are used multiple times in the subsequent code and need to be checked. This fixes 10 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49921", "url": "https://ubuntu.com/security/CVE-2024-49921", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before used [WHAT & HOW] Poniters, such as dc->clk_mgr, are null checked previously in the same function, so Coverity warns \"implies that \"dc->clk_mgr\" might be null\". As a result, these pointers need to be checked when used again. This fixes 10 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49922", "url": "https://ubuntu.com/security/CVE-2024-49922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before using them [WHAT & HOW] These pointers are null checked previously in the same function, indicating they might be null as reported by Coverity. As a result, they need to be checked when used again. This fixes 3 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49923", "url": "https://ubuntu.com/security/CVE-2024-49923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Pass non-null to dcn20_validate_apply_pipe_split_flags [WHAT & HOW] \"dcn20_validate_apply_pipe_split_flags\" dereferences merge, and thus it cannot be a null pointer. Let's pass a valid pointer to avoid null dereference. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49992", "url": "https://ubuntu.com/security/CVE-2024-49992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/stm: Avoid use-after-free issues with crtc and plane ltdc_load() calls functions drm_crtc_init_with_planes(), drm_universal_plane_init() and drm_encoder_init(). These functions should not be called with parameters allocated with devm_kzalloc() to avoid use-after-free issues [1]. Use allocations managed by the DRM framework. Found by Linux Verification Center (linuxtesting.org). [1] https://lore.kernel.org/lkml/u366i76e3qhh3ra5oxrtngjtm2u5lterkekcz6y2jkndhuxzli@diujon4h7qwb/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49993", "url": "https://ubuntu.com/security/CVE-2024-49993", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49924", "url": "https://ubuntu.com/security/CVE-2024-49924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: pxafb: Fix possible use after free in pxafb_task() In the pxafb_probe function, it calls the pxafb_init_fbinfo function, after which &fbi->task is associated with pxafb_task. Moreover, within this pxafb_init_fbinfo function, the pxafb_blank function within the &pxafb_ops struct is capable of scheduling work. If we remove the module which will call pxafb_remove to make cleanup, it will call unregister_framebuffer function which can call do_unregister_framebuffer to free fbi->fb through put_fb_info(fb_info), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | pxafb_task pxafb_remove | unregister_framebuffer(info) | do_unregister_framebuffer(fb_info) | put_fb_info(fb_info) | // free fbi->fb | set_ctrlr_state(fbi, state) | __pxafb_lcd_power(fbi, 0) | fbi->lcd_power(on, &fbi->fb.var) | //use fbi->fb Fix it by ensuring that the work is canceled before proceeding with the cleanup in pxafb_remove. Note that only root user can remove the driver at runtime.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49925", "url": "https://ubuntu.com/security/CVE-2024-49925", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: efifb: Register sysfs groups through driver core The driver core can register and cleanup sysfs groups already. Make use of that functionality to simplify the error handling and cleanup. Also avoid a UAF race during unregistering where the sysctl attributes were usable after the info struct was freed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49926", "url": "https://ubuntu.com/security/CVE-2024-49926", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rcu-tasks: Fix access non-existent percpu rtpcp variable in rcu_tasks_need_gpcb() For kernels built with CONFIG_FORCE_NR_CPUS=y, the nr_cpu_ids is defined as NR_CPUS instead of the number of possible cpus, this will cause the following system panic: smpboot: Allowing 4 CPUs, 0 hotplug CPUs ... setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:512 nr_node_ids:1 ... BUG: unable to handle page fault for address: ffffffff9911c8c8 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 15 Comm: rcu_tasks_trace Tainted: G W 6.6.21 #1 5dc7acf91a5e8e9ac9dcfc35bee0245691283ea6 RIP: 0010:rcu_tasks_need_gpcb+0x25d/0x2c0 RSP: 0018:ffffa371c00a3e60 EFLAGS: 00010082 CR2: ffffffff9911c8c8 CR3: 000000040fa20005 CR4: 00000000001706f0 Call Trace: ? __die+0x23/0x80 ? page_fault_oops+0xa4/0x180 ? exc_page_fault+0x152/0x180 ? asm_exc_page_fault+0x26/0x40 ? rcu_tasks_need_gpcb+0x25d/0x2c0 ? __pfx_rcu_tasks_kthread+0x40/0x40 rcu_tasks_one_gp+0x69/0x180 rcu_tasks_kthread+0x94/0xc0 kthread+0xe8/0x140 ? __pfx_kthread+0x40/0x40 ret_from_fork+0x34/0x80 ? __pfx_kthread+0x40/0x40 ret_from_fork_asm+0x1b/0x80 Considering that there may be holes in the CPU numbers, use the maximum possible cpu number, instead of nr_cpu_ids, for configuring enqueue and dequeue limits. [ neeraj.upadhyay: Fix htmldocs build error reported by Stephen Rothwell ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50007", "url": "https://ubuntu.com/security/CVE-2024-50007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: asihpi: Fix potential OOB array access ASIHPI driver stores some values in the static array upon a response from the driver, and its index depends on the firmware. We shouldn't trust it blindly. This patch adds a sanity check of the array index to fit in the array size.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50017", "url": "https://ubuntu.com/security/CVE-2024-50017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm/ident_map: Use gbpages only where full GB page should be mapped. When ident_pud_init() uses only GB pages to create identity maps, large ranges of addresses not actually requested can be included in the resulting table; a 4K request will map a full GB. This can include a lot of extra address space past that requested, including areas marked reserved by the BIOS. That allows processor speculation into reserved regions, that on UV systems can cause system halts. Only use GB pages when map creation requests include the full GB page of space. Fall back to using smaller 2M pages when only portions of a GB page are included in the request. No attempt is made to coalesce mapping requests. If a request requires a map entry at the 2M (pmd) level, subsequent mapping requests within the same 1G region will also be at the pmd level, even if adjacent or overlapping such requests could have been combined to map a full GB page. Existing usage starts with larger regions and then adds smaller regions, so this should not have any great consequence.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49927", "url": "https://ubuntu.com/security/CVE-2024-49927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/ioapic: Handle allocation failures gracefully Breno observed panics when using failslab under certain conditions during runtime: can not alloc irq_pin_list (-1,0,20) Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed panic+0x4e9/0x590 mp_irqdomain_alloc+0x9ab/0xa80 irq_domain_alloc_irqs_locked+0x25d/0x8d0 __irq_domain_alloc_irqs+0x80/0x110 mp_map_pin_to_irq+0x645/0x890 acpi_register_gsi_ioapic+0xe6/0x150 hpet_open+0x313/0x480 That's a pointless panic which is a leftover of the historic IO/APIC code which panic'ed during early boot when the interrupt allocation failed. The only place which might justify panic is the PIT/HPET timer_check() code which tries to figure out whether the timer interrupt is delivered through the IO/APIC. But that code does not require to handle interrupt allocation failures. If the interrupt cannot be allocated then timer delivery fails and it either panics due to that or falls back to legacy mode. Cure this by removing the panic wrapper around __add_pin_to_irq_node() and making mp_irqdomain_alloc() aware of the failure condition and handle it as any other failure in this function gracefully.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50008", "url": "https://ubuntu.com/security/CVE-2024-50008", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_cmd_802_11_scan_ext() Replace one-element array with a flexible-array member in `struct host_cmd_ds_802_11_scan_ext`. With this, fix the following warning: elo 16 17:51:58 surfacebook kernel: ------------[ cut here ]------------ elo 16 17:51:58 surfacebook kernel: memcpy: detected field-spanning write (size 243) of single field \"ext_scan->tlv_buffer\" at drivers/net/wireless/marvell/mwifiex/scan.c:2239 (size 1) elo 16 17:51:58 surfacebook kernel: WARNING: CPU: 0 PID: 498 at drivers/net/wireless/marvell/mwifiex/scan.c:2239 mwifiex_cmd_802_11_scan_ext+0x83/0x90 [mwifiex]", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50018", "url": "https://ubuntu.com/security/CVE-2024-50018", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49928", "url": "https://ubuntu.com/security/CVE-2024-49928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: avoid reading out of bounds when loading TX power FW elements Because the loop-expression will do one more time before getting false from cond-expression, the original code copied one more entry size beyond valid region. Fix it by moving the entry copy to loop-body.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50178", "url": "https://ubuntu.com/security/CVE-2024-50178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: loongson3: Use raw_smp_processor_id() in do_service_request() Use raw_smp_processor_id() instead of plain smp_processor_id() in do_service_request(), otherwise we may get some errors with the driver enabled: BUG: using smp_processor_id() in preemptible [00000000] code: (udev-worker)/208 caller is loongson3_cpufreq_probe+0x5c/0x250 [loongson3_cpufreq]", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50009", "url": "https://ubuntu.com/security/CVE-2024-50009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: amd-pstate: add check for cpufreq_cpu_get's return value cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it and return in case of error. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49994", "url": "https://ubuntu.com/security/CVE-2024-49994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix integer overflow in BLKSECDISCARD I independently rediscovered \tcommit 22d24a544b0d49bbcbd61c8c0eaf77d3c9297155 \tblock: fix overflow in blk_ioctl_discard() but for secure erase. Same problem: \tuint64_t r[2] = {512, 18446744073709551104ULL}; \tioctl(fd, BLKSECDISCARD, r); will enter near infinite loop inside blkdev_issue_secure_erase(): \ta.out: attempt to access beyond end of device \tloop0: rw=5, sector=3399043073, nr_sectors = 1024 limit=2048 \tbio_check_eod: 3286214 callbacks suppressed", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49929", "url": "https://ubuntu.com/security/CVE-2024-49929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: avoid NULL pointer dereference iwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta pointer is not NULL. It retrieves this pointer using iwl_mvm_sta_from_mac80211, which is dereferencing the ieee80211_sta pointer. If sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL pointer. Fix this by checking the sta pointer before retrieving the mvmsta from it. If sta is not NULL, then mvmsta isn't either.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49995", "url": "https://ubuntu.com/security/CVE-2024-49995", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: guard against string buffer overrun Smatch reports that copying media_name and if_name to name_parts may overwrite the destination. .../bearer.c:166 bearer_name_validate() error: strcpy() 'media_name' too large for 'name_parts->media_name' (32 vs 16) .../bearer.c:167 bearer_name_validate() error: strcpy() 'if_name' too large for 'name_parts->if_name' (1010102 vs 16) This does seem to be the case so guard against this possibility by using strscpy() and failing if truncation occurs. Introduced by commit b97bf3fd8f6a (\"[TIPC] Initial merge\") Compile tested only.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49962", "url": "https://ubuntu.com/security/CVE-2024-49962", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in acpi_db_convert_to_package() ACPICA commit 4d4547cf13cca820ff7e0f859ba83e1a610b9fd0 ACPI_ALLOCATE_ZEROED() may fail, elements might be NULL and will cause NULL pointer dereference later. [ rjw: Subject and changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49930", "url": "https://ubuntu.com/security/CVE-2024-49930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix array out-of-bound access in SoC stats Currently, the ath11k_soc_dp_stats::hal_reo_error array is defined with a maximum size of DP_REO_DST_RING_MAX. However, the ath11k_dp_process_rx() function access ath11k_soc_dp_stats::hal_reo_error using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath11k_dp_process_rx() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49931", "url": "https://ubuntu.com/security/CVE-2024-49931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix array out-of-bound access in SoC stats Currently, the ath12k_soc_dp_stats::hal_reo_error array is defined with a maximum size of DP_REO_DST_RING_MAX. However, the ath12k_dp_rx_process() function access ath12k_soc_dp_stats::hal_reo_error using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath12k_dp_rx_process() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49932", "url": "https://ubuntu.com/security/CVE-2024-49932", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: don't readahead the relocation inode on RST On relocation we're doing readahead on the relocation inode, but if the filesystem is backed by a RAID stripe tree we can get ENOENT (e.g. due to preallocated extents not being mapped in the RST) from the lookup. But readahead doesn't handle the error and submits invalid reads to the device, causing an assertion in the scatter-gather list code: BTRFS info (device nvme1n1): balance: start -d -m -s BTRFS info (device nvme1n1): relocating block group 6480920576 flags data|raid0 BTRFS error (device nvme1n1): cannot find raid-stripe for logical [6481928192, 6481969152] devid 2, profile raid0 ------------[ cut here ]------------ kernel BUG at include/linux/scatterlist.h:115! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 1012 Comm: btrfs Not tainted 6.10.0-rc7+ #567 RIP: 0010:__blk_rq_map_sg+0x339/0x4a0 RSP: 0018:ffffc90001a43820 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffea00045d4802 RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000 RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000001000 R12: ffff8881003d10b8 R13: ffffc90001a438f0 R14: 0000000000000000 R15: 0000000000003000 FS: 00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000002cd11000 CR3: 00000001109ea001 CR4: 0000000000370eb0 Call Trace: ? __die_body.cold+0x14/0x25 ? die+0x2e/0x50 ? do_trap+0xca/0x110 ? do_error_trap+0x65/0x80 ? __blk_rq_map_sg+0x339/0x4a0 ? exc_invalid_op+0x50/0x70 ? __blk_rq_map_sg+0x339/0x4a0 ? asm_exc_invalid_op+0x1a/0x20 ? __blk_rq_map_sg+0x339/0x4a0 nvme_prep_rq.part.0+0x9d/0x770 nvme_queue_rq+0x7d/0x1e0 __blk_mq_issue_directly+0x2a/0x90 ? blk_mq_get_budget_and_tag+0x61/0x90 blk_mq_try_issue_list_directly+0x56/0xf0 blk_mq_flush_plug_list.part.0+0x52b/0x5d0 __blk_flush_plug+0xc6/0x110 blk_finish_plug+0x28/0x40 read_pages+0x160/0x1c0 page_cache_ra_unbounded+0x109/0x180 relocate_file_extent_cluster+0x611/0x6a0 ? btrfs_search_slot+0xba4/0xd20 ? balance_dirty_pages_ratelimited_flags+0x26/0xb00 relocate_data_extent.constprop.0+0x134/0x160 relocate_block_group+0x3f2/0x500 btrfs_relocate_block_group+0x250/0x430 btrfs_relocate_chunk+0x3f/0x130 btrfs_balance+0x71b/0xef0 ? kmalloc_trace_noprof+0x13b/0x280 btrfs_ioctl+0x2c2e/0x3030 ? kvfree_call_rcu+0x1e6/0x340 ? list_lru_add_obj+0x66/0x80 ? mntput_no_expire+0x3a/0x220 __x64_sys_ioctl+0x96/0xc0 do_syscall_64+0x54/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fcc04514f9b Code: Unable to access opcode bytes at 0x7fcc04514f71. RSP: 002b:00007ffeba923370 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fcc04514f9b RDX: 00007ffeba923460 RSI: 00000000c4009420 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000013 R09: 0000000000000001 R10: 00007fcc043fbba8 R11: 0000000000000246 R12: 00007ffeba924fc5 R13: 00007ffeba923460 R14: 0000000000000002 R15: 00000000004d4bb0 Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:__blk_rq_map_sg+0x339/0x4a0 RSP: 0018:ffffc90001a43820 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffea00045d4802 RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000 RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000001000 R12: ffff8881003d10b8 R13: ffffc90001a438f0 R14: 0000000000000000 R15: 0000000000003000 FS: 00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcc04514f71 CR3: 00000001109ea001 CR4: 0000000000370eb0 Kernel p ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49933", "url": "https://ubuntu.com/security/CVE-2024-49933", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk_iocost: fix more out of bound shifts Recently running UBSAN caught few out of bound shifts in the ioc_forgive_debts() function: UBSAN: shift-out-of-bounds in block/blk-iocost.c:2142:38 shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long long') ... UBSAN: shift-out-of-bounds in block/blk-iocost.c:2144:30 shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long long') ... Call Trace: dump_stack_lvl+0xca/0x130 __ubsan_handle_shift_out_of_bounds+0x22c/0x280 ? __lock_acquire+0x6441/0x7c10 ioc_timer_fn+0x6cec/0x7750 ? blk_iocost_init+0x720/0x720 ? call_timer_fn+0x5d/0x470 call_timer_fn+0xfa/0x470 ? blk_iocost_init+0x720/0x720 __run_timer_base+0x519/0x700 ... Actual impact of this issue was not identified but I propose to fix the undefined behaviour. The proposed fix to prevent those out of bound shifts consist of precalculating exponent before using it the shift operations by taking min value from the actual exponent and maximum possible number of bits.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49934", "url": "https://ubuntu.com/security/CVE-2024-49934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/inode: Prevent dump_mapping() accessing invalid dentry.d_name.name It's observed that a crash occurs during hot-remove a memory device, in which user is accessing the hugetlb. See calltrace as following: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 14045 at arch/x86/mm/fault.c:1278 do_user_addr_fault+0x2a0/0x790 Modules linked in: kmem device_dax cxl_mem cxl_pmem cxl_port cxl_pci dax_hmem dax_pmem nd_pmem cxl_acpi nd_btt cxl_core crc32c_intel nvme virtiofs fuse nvme_core nfit libnvdimm dm_multipath scsi_dh_rdac scsi_dh_emc s mirror dm_region_hash dm_log dm_mod CPU: 1 PID: 14045 Comm: daxctl Not tainted 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:do_user_addr_fault+0x2a0/0x790 Code: 48 8b 00 a8 04 0f 84 b5 fe ff ff e9 1c ff ff ff 4c 89 e9 4c 89 e2 be 01 00 00 00 bf 02 00 00 00 e8 b5 ef 24 00 e9 42 fe ff ff <0f> 0b 48 83 c4 08 4c 89 ea 48 89 ee 4c 89 e7 5b 5d 41 5c 41 5d 41 RSP: 0000:ffffc90000a575f0 EFLAGS: 00010046 RAX: ffff88800c303600 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000001000 RSI: ffffffff82504162 RDI: ffffffff824b2c36 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffc90000a57658 R13: 0000000000001000 R14: ffff88800bc2e040 R15: 0000000000000000 FS: 00007f51cb57d880(0000) GS:ffff88807fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000001000 CR3: 00000000072e2004 CR4: 00000000001706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn+0x8d/0x190 ? do_user_addr_fault+0x2a0/0x790 ? report_bug+0x1c3/0x1d0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? do_user_addr_fault+0x2a0/0x790 ? exc_page_fault+0x31/0x200 exc_page_fault+0x68/0x200 <...snip...> BUG: unable to handle page fault for address: 0000000000001000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI ---[ end trace 0000000000000000 ]--- BUG: unable to handle page fault for address: 0000000000001000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 14045 Comm: daxctl Kdump: loaded Tainted: G W 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:dentry_name+0x1f4/0x440 <...snip...> ? dentry_name+0x2fa/0x440 vsnprintf+0x1f3/0x4f0 vprintk_store+0x23a/0x540 vprintk_emit+0x6d/0x330 _printk+0x58/0x80 dump_mapping+0x10b/0x1a0 ? __pfx_free_object_rcu+0x10/0x10 __dump_page+0x26b/0x3e0 ? vprintk_emit+0xe0/0x330 ? _printk+0x58/0x80 ? dump_page+0x17/0x50 dump_page+0x17/0x50 do_migrate_range+0x2f7/0x7f0 ? do_migrate_range+0x42/0x7f0 ? offline_pages+0x2f4/0x8c0 offline_pages+0x60a/0x8c0 memory_subsys_offline+0x9f/0x1c0 ? lockdep_hardirqs_on+0x77/0x100 ? _raw_spin_unlock_irqrestore+0x38/0x60 device_offline+0xe3/0x110 state_store+0x6e/0xc0 kernfs_fop_write_iter+0x143/0x200 vfs_write+0x39f/0x560 ksys_write+0x65/0xf0 do_syscall_64+0x62/0x130 Previously, some sanity check have been done in dump_mapping() before the print facility parsing '%pd' though, it's still possible to run into an invalid dentry.d_name.name. Since dump_mapping() only needs to dump the filename only, retrieve it by itself in a safer way to prevent an unnecessary crash. Note that either retrieving the filename with '%pd' or strncpy_from_kernel_nofault(), the filename could be unreliable.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49935", "url": "https://ubuntu.com/security/CVE-2024-49935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: PAD: fix crash in exit_round_robin() The kernel occasionally crashes in cpumask_clear_cpu(), which is called within exit_round_robin(), because when executing clear_bit(nr, addr) with nr set to 0xffffffff, the address calculation may cause misalignment within the memory, leading to access to an invalid memory address. ---------- BUG: unable to handle kernel paging request at ffffffffe0740618 ... CPU: 3 PID: 2919323 Comm: acpi_pad/14 Kdump: loaded Tainted: G OE X --------- - - 4.18.0-425.19.2.el8_7.x86_64 #1 ... RIP: 0010:power_saving_thread+0x313/0x411 [acpi_pad] Code: 89 cd 48 89 d3 eb d1 48 c7 c7 55 70 72 c0 e8 64 86 b0 e4 c6 05 0d a1 02 00 01 e9 bc fd ff ff 45 89 e4 42 8b 04 a5 20 82 72 c0 48 0f b3 05 f4 9c 01 00 42 c7 04 a5 20 82 72 c0 ff ff ff ff 31 RSP: 0018:ff72a5d51fa77ec8 EFLAGS: 00010202 RAX: 00000000ffffffff RBX: ff462981e5d8cb80 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246 RBP: ff46297556959d80 R08: 0000000000000382 R09: ff46297c8d0f38d8 R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000000e R13: 0000000000000000 R14: ffffffffffffffff R15: 000000000000000e FS: 0000000000000000(0000) GS:ff46297a800c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffe0740618 CR3: 0000007e20410004 CR4: 0000000000771ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? acpi_pad_add+0x120/0x120 [acpi_pad] kthread+0x10b/0x130 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x1f/0x40 ... CR2: ffffffffe0740618 crash> dis -lr ffffffffc0726923 ... /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 114 0xffffffffc0726918 :\tmov %r12d,%r12d /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 325 0xffffffffc072691b :\tmov -0x3f8d7de0(,%r12,4),%eax /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./arch/x86/include/asm/bitops.h: 80 0xffffffffc0726923 :\tlock btr %rax,0x19cf4(%rip) # 0xffffffffc0740620 crash> px tsk_in_cpu[14] $66 = 0xffffffff crash> px 0xffffffffc072692c+0x19cf4 $99 = 0xffffffffc0740620 crash> sym 0xffffffffc0740620 ffffffffc0740620 (b) pad_busy_cpus_bits [acpi_pad] crash> px pad_busy_cpus_bits[0] $42 = 0xfffc0 ---------- To fix this, ensure that tsk_in_cpu[tsk_index] != -1 before calling cpumask_clear_cpu() in exit_round_robin(), just as it is done in round_robin_cpu(). [ rjw: Subject edit, avoid updates to the same value ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49936", "url": "https://ubuntu.com/security/CVE-2024-49936", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/xen-netback: prevent UAF in xenvif_flush_hash() During the list_for_each_entry_rcu iteration call of xenvif_flush_hash, kfree_rcu does not exist inside the rcu read critical section, so if kfree_rcu is called when the rcu grace period ends during the iteration, UAF occurs when accessing head->next after the entry becomes free. Therefore, to solve this, you need to change it to list_for_each_entry_safe.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49937", "url": "https://ubuntu.com/security/CVE-2024-49937", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Set correct chandef when starting CAC When starting CAC in a mode other than AP mode, it return a \"WARNING: CPU: 0 PID: 63 at cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]\" caused by the chandef.chan being null at the end of CAC. Solution: Ensure the channel definition is set for the different modes when starting CAC to avoid getting a NULL 'chan' at the end of CAC. Call Trace: ? show_regs.part.0+0x14/0x16 ? __warn+0x67/0xc0 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? report_bug+0xa7/0x130 ? exc_overflow+0x30/0x30 ? handle_bug+0x27/0x50 ? exc_invalid_op+0x18/0x60 ? handle_exception+0xf6/0xf6 ? exc_overflow+0x30/0x30 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? exc_overflow+0x30/0x30 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? regulatory_propagate_dfs_state.cold+0x1b/0x4c [cfg80211] ? cfg80211_propagate_cac_done_wk+0x1a/0x30 [cfg80211] ? process_one_work+0x165/0x280 ? worker_thread+0x120/0x3f0 ? kthread+0xc2/0xf0 ? process_one_work+0x280/0x280 ? kthread_complete_and_exit+0x20/0x20 ? ret_from_fork+0x19/0x24 [shorten subject, remove OCB, reorder cases to match previous list]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49938", "url": "https://ubuntu.com/security/CVE-2024-49938", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmit Syzbot points out that skb_trim() has a sanity check on the existing length of the skb, which can be uninitialised in some error paths. The intent here is clearly just to reset the length to zero before resubmitting, so switch to calling __skb_set_length(skb, 0) directly. In addition, __skb_set_length() already contains a call to skb_reset_tail_pointer(), so remove the redundant call. The syzbot report came from ath9k_hif_usb_reg_in_cb(), but there's a similar usage of skb_trim() in ath9k_hif_usb_rx_cb(), change both while we're at it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49939", "url": "https://ubuntu.com/security/CVE-2024-49939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: avoid to add interface to list twice when SER If SER L2 occurs during the WoWLAN resume flow, the add interface flow is triggered by ieee80211_reconfig(). However, due to rtw89_wow_resume() return failure, it will cause the add interface flow to be executed again, resulting in a double add list and causing a kernel panic. Therefore, we have added a check to prevent double adding of the list. list_add double add: new=ffff99d6992e2010, prev=ffff99d6992e2010, next=ffff99d695302628. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:37! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G W O 6.6.30-02659-gc18865c4dfbd #1 770df2933251a0e3c888ba69d1053a817a6376a7 Hardware name: HP Grunt/Grunt, BIOS Google_Grunt.11031.169.0 06/24/2021 Workqueue: events_freezable ieee80211_restart_work [mac80211] RIP: 0010:__list_add_valid_or_report+0x5e/0xb0 Code: c7 74 18 48 39 ce 74 13 b0 01 59 5a 5e 5f 41 58 41 59 41 5a 5d e9 e2 d6 03 00 cc 48 c7 c7 8d 4f 17 83 48 89 c2 e8 02 c0 00 00 <0f> 0b 48 c7 c7 aa 8c 1c 83 e8 f4 bf 00 00 0f 0b 48 c7 c7 c8 bc 12 RSP: 0018:ffffa91b8007bc50 EFLAGS: 00010246 RAX: 0000000000000058 RBX: ffff99d6992e0900 RCX: a014d76c70ef3900 RDX: ffffa91b8007bae8 RSI: 00000000ffffdfff RDI: 0000000000000001 RBP: ffffa91b8007bc88 R08: 0000000000000000 R09: ffffa91b8007bae0 R10: 00000000ffffdfff R11: ffffffff83a79800 R12: ffff99d695302060 R13: ffff99d695300900 R14: ffff99d6992e1be0 R15: ffff99d6992e2010 FS: 0000000000000000(0000) GS:ffff99d6aac00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000078fbdba43480 CR3: 000000010e464000 CR4: 00000000001506f0 Call Trace: ? __die_body+0x1f/0x70 ? die+0x3d/0x60 ? do_trap+0xa4/0x110 ? __list_add_valid_or_report+0x5e/0xb0 ? do_error_trap+0x6d/0x90 ? __list_add_valid_or_report+0x5e/0xb0 ? handle_invalid_op+0x30/0x40 ? __list_add_valid_or_report+0x5e/0xb0 ? exc_invalid_op+0x3c/0x50 ? asm_exc_invalid_op+0x16/0x20 ? __list_add_valid_or_report+0x5e/0xb0 rtw89_ops_add_interface+0x309/0x310 [rtw89_core 7c32b1ee6854761c0321027c8a58c5160e41f48f] drv_add_interface+0x5c/0x130 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ieee80211_reconfig+0x241/0x13d0 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ? finish_wait+0x3e/0x90 ? synchronize_rcu_expedited+0x174/0x260 ? sync_rcu_exp_done_unlocked+0x50/0x50 ? wake_bit_function+0x40/0x40 ieee80211_restart_work+0xf0/0x140 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] process_scheduled_works+0x1e5/0x480 worker_thread+0xea/0x1e0 kthread+0xdb/0x110 ? move_linked_works+0x90/0x90 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork+0x3b/0x50 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork_asm+0x11/0x20 Modules linked in: dm_integrity async_xor xor async_tx lz4 lz4_compress zstd zstd_compress zram zsmalloc rfcomm cmac uinput algif_hash algif_skcipher af_alg btusb btrtl iio_trig_hrtimer industrialio_sw_trigger btmtk industrialio_configfs btbcm btintel uvcvideo videobuf2_vmalloc iio_trig_sysfs videobuf2_memops videobuf2_v4l2 videobuf2_common uvc snd_hda_codec_hdmi veth snd_hda_intel snd_intel_dspcfg acpi_als snd_hda_codec industrialio_triggered_buffer kfifo_buf snd_hwdep industrialio i2c_piix4 snd_hda_core designware_i2s ip6table_nat snd_soc_max98357a xt_MASQUERADE xt_cgroup snd_soc_acp_rt5682_mach fuse rtw89_8922ae(O) rtw89_8922a(O) rtw89_pci(O) rtw89_core(O) 8021q mac80211(O) bluetooth ecdh_generic ecc cfg80211 r8152 mii joydev gsmi: Log Shutdown Reason 0x03 ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49940", "url": "https://ubuntu.com/security/CVE-2024-49940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: prevent possible tunnel refcount underflow When a session is created, it sets a backpointer to its tunnel. When the session refcount drops to 0, l2tp_session_free drops the tunnel refcount if session->tunnel is non-NULL. However, session->tunnel is set in l2tp_session_create, before the tunnel refcount is incremented by l2tp_session_register, which leaves a small window where session->tunnel is non-NULL when the tunnel refcount hasn't been bumped. Moving the assignment to l2tp_session_register is trivial but l2tp_session_create calls l2tp_session_set_header_len which uses session->tunnel to get the tunnel's encap. Add an encap arg to l2tp_session_set_header_len to avoid using session->tunnel. If l2tpv3 sessions have colliding IDs, it is possible for l2tp_v3_session_get to race with l2tp_session_register and fetch a session which doesn't yet have session->tunnel set. Add a check for this case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49941", "url": "https://ubuntu.com/security/CVE-2024-49941", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpiolib: Fix potential NULL pointer dereference in gpiod_get_label() In `gpiod_get_label()`, it is possible that `srcu_dereference_check()` may return a NULL pointer, leading to a scenario where `label->str` is accessed without verifying if `label` itself is NULL. This patch adds a proper NULL check for `label` before accessing `label->str`. The check for `label->str != NULL` is removed because `label->str` can never be NULL if `label` is not NULL. This fixes the issue where the label name was being printed as `(efault)` when dumping the sysfs GPIO file when `label == NULL`.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49996", "url": "https://ubuntu.com/security/CVE-2024-49996", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: Fix buffer overflow when parsing NFS reparse points ReparseDataLength is sum of the InodeType size and DataBuffer size. So to get DataBuffer size it is needed to subtract InodeType's size from ReparseDataLength. Function cifs_strndup_from_utf16() is currentlly accessing buf->DataBuffer at position after the end of the buffer because it does not subtract InodeType size from the length. Fix this problem and correctly subtract variable len. Member InodeType is present only when reparse buffer is large enough. Check for ReparseDataLength before accessing InodeType to prevent another invalid memory access. Major and minor rdev values are present also only when reparse buffer is large enough. Check for reparse buffer size before calling reparse_mkdev().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49942", "url": "https://ubuntu.com/security/CVE-2024-49942", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Prevent null pointer access in xe_migrate_copy xe_migrate_copy designed to copy content of TTM resources. When source resource is null, it will trigger a NULL pointer dereference in xe_migrate_copy. To avoid this situation, update lacks source flag to true for this case, the flag will trigger xe_migrate_clear rather than xe_migrate_copy. Issue trace: <7> [317.089847] xe 0000:00:02.0: [drm:xe_migrate_copy [xe]] Pass 14, sizes: 4194304 & 4194304 <7> [317.089945] xe 0000:00:02.0: [drm:xe_migrate_copy [xe]] Pass 15, sizes: 4194304 & 4194304 <1> [317.128055] BUG: kernel NULL pointer dereference, address: 0000000000000010 <1> [317.128064] #PF: supervisor read access in kernel mode <1> [317.128066] #PF: error_code(0x0000) - not-present page <6> [317.128069] PGD 0 P4D 0 <4> [317.128071] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI <4> [317.128074] CPU: 1 UID: 0 PID: 1440 Comm: kunit_try_catch Tainted: G U N 6.11.0-rc7-xe #1 <4> [317.128078] Tainted: [U]=USER, [N]=TEST <4> [317.128080] Hardware name: Intel Corporation Lunar Lake Client Platform/LNL-M LP5 RVP1, BIOS LNLMFWI1.R00.3221.D80.2407291239 07/29/2024 <4> [317.128082] RIP: 0010:xe_migrate_copy+0x66/0x13e0 [xe] <4> [317.128158] Code: 00 00 48 89 8d e0 fe ff ff 48 8b 40 10 4c 89 85 c8 fe ff ff 44 88 8d bd fe ff ff 65 48 8b 3c 25 28 00 00 00 48 89 7d d0 31 ff <8b> 79 10 48 89 85 a0 fe ff ff 48 8b 00 48 89 b5 d8 fe ff ff 83 ff <4> [317.128162] RSP: 0018:ffffc9000167f9f0 EFLAGS: 00010246 <4> [317.128164] RAX: ffff8881120d8028 RBX: ffff88814d070428 RCX: 0000000000000000 <4> [317.128166] RDX: ffff88813cb99c00 RSI: 0000000004000000 RDI: 0000000000000000 <4> [317.128168] RBP: ffffc9000167fbb8 R08: ffff88814e7b1f08 R09: 0000000000000001 <4> [317.128170] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88814e7b1f08 <4> [317.128172] R13: ffff88814e7b1f08 R14: ffff88813cb99c00 R15: 0000000000000001 <4> [317.128174] FS: 0000000000000000(0000) GS:ffff88846f280000(0000) knlGS:0000000000000000 <4> [317.128176] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [317.128178] CR2: 0000000000000010 CR3: 000000011f676004 CR4: 0000000000770ef0 <4> [317.128180] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 <4> [317.128182] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400 <4> [317.128184] PKRU: 55555554 <4> [317.128185] Call Trace: <4> [317.128187] <4> [317.128189] ? show_regs+0x67/0x70 <4> [317.128194] ? __die_body+0x20/0x70 <4> [317.128196] ? __die+0x2b/0x40 <4> [317.128198] ? page_fault_oops+0x15f/0x4e0 <4> [317.128203] ? do_user_addr_fault+0x3fb/0x970 <4> [317.128205] ? lock_acquire+0xc7/0x2e0 <4> [317.128209] ? exc_page_fault+0x87/0x2b0 <4> [317.128212] ? asm_exc_page_fault+0x27/0x30 <4> [317.128216] ? xe_migrate_copy+0x66/0x13e0 [xe] <4> [317.128263] ? __lock_acquire+0xb9d/0x26f0 <4> [317.128265] ? __lock_acquire+0xb9d/0x26f0 <4> [317.128267] ? sg_free_append_table+0x20/0x80 <4> [317.128271] ? lock_acquire+0xc7/0x2e0 <4> [317.128273] ? mark_held_locks+0x4d/0x80 <4> [317.128275] ? trace_hardirqs_on+0x1e/0xd0 <4> [317.128278] ? _raw_spin_unlock_irqrestore+0x31/0x60 <4> [317.128281] ? __pm_runtime_resume+0x60/0xa0 <4> [317.128284] xe_bo_move+0x682/0xc50 [xe] <4> [317.128315] ? lock_is_held_type+0xaa/0x120 <4> [317.128318] ttm_bo_handle_move_mem+0xe5/0x1a0 [ttm] <4> [317.128324] ttm_bo_validate+0xd1/0x1a0 [ttm] <4> [317.128328] shrink_test_run_device+0x721/0xc10 [xe] <4> [317.128360] ? find_held_lock+0x31/0x90 <4> [317.128363] ? lock_release+0xd1/0x2a0 <4> [317.128365] ? __pfx_kunit_generic_run_threadfn_adapter+0x10/0x10 [kunit] <4> [317.128370] xe_bo_shrink_kunit+0x11/0x20 [xe] <4> [317.128397] kunit_try_run_case+0x6e/0x150 [kunit] <4> [317.128400] ? trace_hardirqs_on+0x1e/0xd0 <4> [317.128402] ? _raw_spin_unlock_irqrestore+0x31/0x60 <4> [317.128404] kunit_generic_run_threadfn_adapter+0x1e/0x40 [ku ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49943", "url": "https://ubuntu.com/security/CVE-2024-49943", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc_submit: add missing locking in wedged_fini Any non-wedged queue can have a zero refcount here and can be running concurrently with an async queue destroy, therefore dereferencing the queue ptr to check wedge status after the lookup can trigger UAF if queue is not wedged. Fix this by keeping the submission_state lock held around the check to postpone the free and make the check safe, before dropping again around the put() to avoid the deadlock. (cherry picked from commit d28af0b6b9580b9f90c265a7da0315b0ad20bbfd)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50011", "url": "https://ubuntu.com/security/CVE-2024-50011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: soc-acpi-intel-rpl-match: add missing empty item There is no links_num in struct snd_soc_acpi_mach {}, and we test !link->num_adr as a condition to end the loop in hda_sdw_machine_select(). So an empty item in struct snd_soc_acpi_link_adr array is required.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50174", "url": "https://ubuntu.com/security/CVE-2024-50174", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix race when converting group handle to group object XArray provides it's own internal lock which protects the internal array when entries are being simultaneously added and removed. However there is still a race between retrieving the pointer from the XArray and incrementing the reference count. To avoid this race simply hold the internal XArray lock when incrementing the reference count, this ensures there cannot be a racing call to xa_erase().", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49944", "url": "https://ubuntu.com/security/CVE-2024-49944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_start In sctp_listen_start() invoked by sctp_inet_listen(), it should set the sk_state back to CLOSED if sctp_autobind() fails due to whatever reason. Otherwise, next time when calling sctp_inet_listen(), if sctp_sk(sk)->reuse is already set via setsockopt(SCTP_REUSE_PORT), sctp_sk(sk)->bind_hash will be dereferenced as sk_state is LISTENING, which causes a crash as bind_hash is NULL. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:sctp_inet_listen+0x7f0/0xa20 net/sctp/socket.c:8617 Call Trace: __sys_listen_socket net/socket.c:1883 [inline] __sys_listen+0x1b7/0x230 net/socket.c:1894 __do_sys_listen net/socket.c:1902 [inline]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49945", "url": "https://ubuntu.com/security/CVE-2024-49945", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/ncsi: Disable the ncsi work before freeing the associated structure The work function can run after the ncsi device is freed, resulting in use-after-free bugs or kernel panic.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49946", "url": "https://ubuntu.com/security/CVE-2024-49946", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: do not assume bh is held in ppp_channel_bridge_input() Networking receive path is usually handled from BH handler. However, some protocols need to acquire the socket lock, and packets might be stored in the socket backlog is the socket was owned by a user process. In this case, release_sock(), __release_sock(), and sk_backlog_rcv() might call the sk->sk_backlog_rcv() handler in process context. sybot caught ppp was not considering this case in ppp_channel_bridge_input() : WARNING: inconsistent lock state 6.11.0-rc7-syzkaller-g5f5673607153 #0 Not tainted -------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. ksoftirqd/1/24 [HC0[0]:SC1[1]:HE1:SE0] takes: ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 {SOFTIRQ-ON-W} state was registered at: lock_acquire+0x240/0x728 kernel/locking/lockdep.c:5759 __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline] _raw_spin_lock+0x48/0x60 kernel/locking/spinlock.c:154 spin_lock include/linux/spinlock.h:351 [inline] ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline] ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0xfc/0x314 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv include/net/sock.h:1111 [inline] __release_sock+0x1a8/0x3d8 net/core/sock.c:3004 release_sock+0x68/0x1b8 net/core/sock.c:3558 pppoe_sendmsg+0xc8/0x5d8 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x374/0x4f4 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __arm64_sys_sendto+0xd8/0xf8 net/socket.c:2212 __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:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 irq event stamp: 282914 hardirqs last enabled at (282914): [] __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:151 [inline] hardirqs last enabled at (282914): [] _raw_spin_unlock_irqrestore+0x38/0x98 kernel/locking/spinlock.c:194 hardirqs last disabled at (282913): [] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline] hardirqs last disabled at (282913): [] _raw_spin_lock_irqsave+0x2c/0x7c kernel/locking/spinlock.c:162 softirqs last enabled at (282904): [] softirq_handle_end kernel/softirq.c:400 [inline] softirqs last enabled at (282904): [] handle_softirqs+0xa3c/0xbfc kernel/softirq.c:582 softirqs last disabled at (282909): [] run_ksoftirqd+0x70/0x158 kernel/softirq.c:928 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&pch->downl); lock(&pch->downl); *** DEADLOCK *** 1 lock held by ksoftirqd/1/24: #0: ffff80008f74dfa0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire+0x10/0x4c include/linux/rcupdate.h:325 stack backtrace: CPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 6.11.0-rc7-syzkaller-g5f5673607153 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call trace: dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:319 show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:326 __dump_sta ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49947", "url": "https://ubuntu.com/security/CVE-2024-49947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: test for not too small csum_start in virtio_net_hdr_to_skb() syzbot was able to trigger this warning [1], after injecting a malicious packet through af_packet, setting skb->csum_start and thus the transport header to an incorrect value. We can at least make sure the transport header is after the end of the network header (with a estimated minimal size). [1] [ 67.873027] skb len=4096 headroom=16 headlen=14 tailroom=0 mac=(-1,-1) mac_len=0 net=(16,-6) trans=10 shinfo(txflags=0 nr_frags=1 gso(size=0 type=0 segs=0)) csum(0xa start=10 offset=0 ip_summed=3 complete_sw=0 valid=0 level=0) hash(0x0 sw=0 l4=0) proto=0x0800 pkttype=0 iif=0 priority=0x0 mark=0x0 alloc_cpu=10 vlan_all=0x0 encapsulation=0 inner(proto=0x0000, mac=0, net=0, trans=0) [ 67.877172] dev name=veth0_vlan feat=0x000061164fdd09e9 [ 67.877764] sk family=17 type=3 proto=0 [ 67.878279] skb linear: 00000000: 00 00 10 00 00 00 00 00 0f 00 00 00 08 00 [ 67.879128] skb frag: 00000000: 0e 00 07 00 00 00 28 00 08 80 1c 00 04 00 00 02 [ 67.879877] skb frag: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.880647] skb frag: 00000020: 00 00 02 00 00 00 08 00 1b 00 00 00 00 00 00 00 [ 67.881156] skb frag: 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.881753] skb frag: 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.882173] skb frag: 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.882790] skb frag: 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.883171] skb frag: 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.883733] skb frag: 00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.884206] skb frag: 00000090: 00 00 00 00 00 00 00 00 00 00 69 70 76 6c 61 6e [ 67.884704] skb frag: 000000a0: 31 00 00 00 00 00 00 00 00 00 2b 00 00 00 00 00 [ 67.885139] skb frag: 000000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.885677] skb frag: 000000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.886042] skb frag: 000000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.886408] skb frag: 000000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.887020] skb frag: 000000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.887384] skb frag: 00000100: 00 00 [ 67.887878] ------------[ cut here ]------------ [ 67.887908] offset (-6) >= skb_headlen() (14) [ 67.888445] WARNING: CPU: 10 PID: 2088 at net/core/dev.c:3332 skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.889353] Modules linked in: macsec macvtap macvlan hsr wireguard curve25519_x86_64 libcurve25519_generic libchacha20poly1305 chacha_x86_64 libchacha poly1305_x86_64 dummy bridge sr_mod cdrom evdev pcspkr i2c_piix4 9pnet_virtio 9p 9pnet netfs [ 67.890111] CPU: 10 UID: 0 PID: 2088 Comm: b363492833 Not tainted 6.11.0-virtme #1011 [ 67.890183] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 67.890309] RIP: 0010:skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891043] Call Trace: [ 67.891173] [ 67.891274] ? __warn (kernel/panic.c:741) [ 67.891320] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891333] ? report_bug (lib/bug.c:180 lib/bug.c:219) [ 67.891348] ? handle_bug (arch/x86/kernel/traps.c:239) [ 67.891363] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) [ 67.891372] ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621) [ 67.891388] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891399] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891416] ip_do_fragment (net/ipv4/ip_output.c:777 (discriminator 1)) [ 67.891448] ? __ip_local_out (./include/linux/skbuff.h:1146 ./include/net/l3mdev.h:196 ./include/net/l3mdev.h:213 ne ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49948", "url": "https://ubuntu.com/security/CVE-2024-49948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: add more sanity checks to qdisc_pkt_len_init() One path takes care of SKB_GSO_DODGY, assuming skb->len is bigger than hdr_len. virtio_net_hdr_to_skb() does not fully dissect TCP headers, it only make sure it is at least 20 bytes. It is possible for an user to provide a malicious 'GSO' packet, total length of 80 bytes. - 20 bytes of IPv4 header - 60 bytes TCP header - a small gso_size like 8 virtio_net_hdr_to_skb() would declare this packet as a normal GSO packet, because it would see 40 bytes of payload, bigger than gso_size. We need to make detect this case to not underflow qdisc_skb_cb(skb)->pkt_len.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49949", "url": "https://ubuntu.com/security/CVE-2024-49949", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: avoid potential underflow in qdisc_pkt_len_init() with UFO After commit 7c6d2ecbda83 (\"net: be more gentle about silly gso requests coming from user\") virtio_net_hdr_to_skb() had sanity check to detect malicious attempts from user space to cook a bad GSO packet. Then commit cf9acc90c80ec (\"net: virtio_net_hdr_to_skb: count transport header in UFO\") while fixing one issue, allowed user space to cook a GSO packet with the following characteristic : IPv4 SKB_GSO_UDP, gso_size=3, skb->len = 28. When this packet arrives in qdisc_pkt_len_init(), we end up with hdr_len = 28 (IPv4 header + UDP header), matching skb->len Then the following sets gso_segs to 0 : gso_segs = DIV_ROUND_UP(skb->len - hdr_len, shinfo->gso_size); Then later we set qdisc_skb_cb(skb)->pkt_len to back to zero :/ qdisc_skb_cb(skb)->pkt_len += (gso_segs - 1) * hdr_len; This leads to the following crash in fq_codel [1] qdisc_pkt_len_init() is best effort, we only want an estimation of the bytes sent on the wire, not crashing the kernel. This patch is fixing this particular issue, a following one adds more sanity checks for another potential bug. [1] [ 70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 70.724561] #PF: supervisor read access in kernel mode [ 70.724561] #PF: error_code(0x0000) - not-present page [ 70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0 [ 70.724561] Oops: Oops: 0000 [#1] SMP NOPTI [ 70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991 [ 70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel [ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 <49> 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49 All code ======== 0:\t24 08 \tand $0x8,%al 2:\t49 c1 e1 06 \tshl $0x6,%r9 6:\t44 89 7c 24 18 \tmov %r15d,0x18(%rsp) b:\t45 31 ed \txor %r13d,%r13d e:\t45 31 c0 \txor %r8d,%r8d 11:\t31 ff \txor %edi,%edi 13:\t89 44 24 14 \tmov %eax,0x14(%rsp) 17:\t4c 03 8b 90 01 00 00 \tadd 0x190(%rbx),%r9 1e:\teb 04 \tjmp 0x24 20:\t39 ca \tcmp %ecx,%edx 22:\t73 37 \tjae 0x5b 24:\t4d 8b 39 \tmov (%r9),%r15 27:\t83 c7 01 \tadd $0x1,%edi 2a:*\t49 8b 17 \tmov (%r15),%rdx\t\t<-- trapping instruction 2d:\t49 89 11 \tmov %rdx,(%r9) 30:\t41 8b 57 28 \tmov 0x28(%r15),%edx 34:\t45 8b 5f 34 \tmov 0x34(%r15),%r11d 38:\t49 c7 07 00 00 00 00 \tmovq $0x0,(%r15) 3f:\t49 \trex.WB Code starting with the faulting instruction =========================================== 0:\t49 8b 17 \tmov (%r15),%rdx 3:\t49 89 11 \tmov %rdx,(%r9) 6:\t41 8b 57 28 \tmov 0x28(%r15),%edx a:\t45 8b 5f 34 \tmov 0x34(%r15),%r11d e:\t49 c7 07 00 00 00 00 \tmovq $0x0,(%r15) 15:\t49 \trex.WB [ 70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202 [ 70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000 [ 70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001 [ 70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000 [ 70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58 [ 70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000 [ 70.724561] FS: 000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000 [ 70.724561] CS: 0010 DS: 0000 ES: 0000 C ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49997", "url": "https://ubuntu.com/security/CVE-2024-49997", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: lantiq_etop: fix memory disclosure When applying padding, the buffer is not zeroed, which results in memory disclosure. The mentioned data is observed on the wire. This patch uses skb_put_padto() to pad Ethernet frames properly. The mentioned function zeroes the expanded buffer. In case the packet cannot be padded it is silently dropped. Statistics are also not incremented. This driver does not support statistics in the old 32-bit format or the new 64-bit format. These will be added in the future. In its current form, the patch should be easily backported to stable versions. Ethernet MACs on Amazon-SE and Danube cannot do padding of the packets in hardware, so software padding must be applied.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49998", "url": "https://ubuntu.com/security/CVE-2024-49998", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: improve shutdown sequence Alexander Sverdlin presents 2 problems during shutdown with the lan9303 driver. One is specific to lan9303 and the other just happens to reproduce there. The first problem is that lan9303 is unique among DSA drivers in that it calls dev_get_drvdata() at \"arbitrary runtime\" (not probe, not shutdown, not remove): phy_state_machine() -> ... -> dsa_user_phy_read() -> ds->ops->phy_read() -> lan9303_phy_read() -> chip->ops->phy_read() -> lan9303_mdio_phy_read() -> dev_get_drvdata() But we never stop the phy_state_machine(), so it may continue to run after dsa_switch_shutdown(). Our common pattern in all DSA drivers is to set drvdata to NULL to suppress the remove() method that may come afterwards. But in this case it will result in an NPD. The second problem is that the way in which we set dp->conduit->dsa_ptr = NULL; is concurrent with receive packet processing. dsa_switch_rcv() checks once whether dev->dsa_ptr is NULL, but afterwards, rather than continuing to use that non-NULL value, dev->dsa_ptr is dereferenced again and again without NULL checks: dsa_conduit_find_user() and many other places. In between dereferences, there is no locking to ensure that what was valid once continues to be valid. Both problems have the common aspect that closing the conduit interface solves them. In the first case, dev_close(conduit) triggers the NETDEV_GOING_DOWN event in dsa_user_netdevice_event() which closes user ports as well. dsa_port_disable_rt() calls phylink_stop(), which synchronously stops the phylink state machine, and ds->ops->phy_read() will thus no longer call into the driver after this point. In the second case, dev_close(conduit) should do this, as per Documentation/networking/driver.rst: | Quiescence | ---------- | | After the ndo_stop routine has been called, the hardware must | not receive or transmit any data. All in flight packets must | be aborted. If necessary, poll or wait for completion of | any reset commands. So it should be sufficient to ensure that later, when we zeroize conduit->dsa_ptr, there will be no concurrent dsa_switch_rcv() call on this conduit. The addition of the netif_device_detach() function is to ensure that ioctls, rtnetlinks and ethtool requests on the user ports no longer propagate down to the driver - we're no longer prepared to handle them. The race condition actually did not exist when commit 0650bf52b31f (\"net: dsa: be compatible with masters which unregister on shutdown\") first introduced dsa_switch_shutdown(). It was created later, when we stopped unregistering the user interfaces from a bad spot, and we just replaced that sequence with a racy zeroization of conduit->dsa_ptr (one which doesn't ensure that the interfaces aren't up).", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49999", "url": "https://ubuntu.com/security/CVE-2024-49999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix the setting of the server responding flag In afs_wait_for_operation(), we set transcribe the call responded flag to the server record that we used after doing the fileserver iteration loop - but it's possible to exit the loop having had a response from the server that we've discarded (e.g. it returned an abort or we started receiving data, but the call didn't complete). This means that op->server might be NULL, but we don't check that before attempting to set the server flag.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49950", "url": "https://ubuntu.com/security/CVE-2024-49950", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix uaf in l2cap_connect [Syzbot reported] BUG: KASAN: slab-use-after-free in l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 Read of size 8 at addr ffff8880241e9800 by task kworker/u9:0/54 CPU: 0 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-00268-g788220eee30d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Workqueue: hci2 hci_rx_work Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 l2cap_connect_req net/bluetooth/l2cap_core.c:4080 [inline] l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:4772 [inline] l2cap_sig_channel net/bluetooth/l2cap_core.c:5543 [inline] l2cap_recv_frame+0xf0b/0x8eb0 net/bluetooth/l2cap_core.c:6825 l2cap_recv_acldata+0x9b4/0xb70 net/bluetooth/l2cap_core.c:7514 hci_acldata_packet net/bluetooth/hci_core.c:3791 [inline] hci_rx_work+0xaab/0x1610 net/bluetooth/hci_core.c:4028 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 ... Freed by task 5245: 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:579 poison_slab_object+0xf7/0x160 mm/kasan/common.c:240 __kasan_slab_free+0x32/0x50 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2256 [inline] slab_free mm/slub.c:4477 [inline] kfree+0x12a/0x3b0 mm/slub.c:4598 l2cap_conn_free net/bluetooth/l2cap_core.c:1810 [inline] kref_put include/linux/kref.h:65 [inline] l2cap_conn_put net/bluetooth/l2cap_core.c:1822 [inline] l2cap_conn_del+0x59d/0x730 net/bluetooth/l2cap_core.c:1802 l2cap_connect_cfm+0x9e6/0xf80 net/bluetooth/l2cap_core.c:7241 hci_connect_cfm include/net/bluetooth/hci_core.h:1960 [inline] hci_conn_failed+0x1c3/0x370 net/bluetooth/hci_conn.c:1265 hci_abort_conn_sync+0x75a/0xb50 net/bluetooth/hci_sync.c:5583 abort_conn_sync+0x197/0x360 net/bluetooth/hci_conn.c:2917 hci_cmd_sync_work+0x1a4/0x410 net/bluetooth/hci_sync.c:328 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49951", "url": "https://ubuntu.com/security/CVE-2024-49951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Fix possible crash on mgmt_index_removed If mgmt_index_removed is called while there are commands queued on cmd_sync it could lead to crashes like the bellow trace: 0x0000053D: __list_del_entry_valid_or_report+0x98/0xdc 0x0000053D: mgmt_pending_remove+0x18/0x58 [bluetooth] 0x0000053E: mgmt_remove_adv_monitor_complete+0x80/0x108 [bluetooth] 0x0000053E: hci_cmd_sync_work+0xbc/0x164 [bluetooth] So while handling mgmt_index_removed this attempts to dequeue commands passed as user_data to cmd_sync.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49952", "url": "https://ubuntu.com/security/CVE-2024-49952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: prevent nf_skb_duplicated corruption syzbot found that nf_dup_ipv4() or nf_dup_ipv6() could write per-cpu variable nf_skb_duplicated in an unsafe way [1]. Disabling preemption as hinted by the splat is not enough, we have to disable soft interrupts as well. [1] BUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316 caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49 nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook+0x2c4/0x450 include/linux/netfilter.h:269 NF_HOOK_COND include/linux/netfilter.h:302 [inline] ip_output+0x185/0x230 net/ipv4/ip_output.c:433 ip_local_out net/ipv4/ip_output.c:129 [inline] ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495 udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981 udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737 __do_sys_sendmmsg net/socket.c:2766 [inline] __se_sys_sendmmsg net/socket.c:2763 [inline] __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763 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:0x7f4ce4f7def9 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:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9 RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006 RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49953", "url": "https://ubuntu.com/security/CVE-2024-49953", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix crash caused by calling __xfrm_state_delete() twice The km.state is not checked in driver's delayed work. When xfrm_state_check_expire() is called, the state can be reset to XFRM_STATE_EXPIRED, even if it is XFRM_STATE_DEAD already. This happens when xfrm state is deleted, but not freed yet. As __xfrm_state_delete() is called again in xfrm timer, the following crash occurs. To fix this issue, skip xfrm_state_check_expire() if km.state is not XFRM_STATE_VALID. Oops: general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] SMP CPU: 5 UID: 0 PID: 7448 Comm: kworker/u102:2 Not tainted 6.11.0-rc2+ #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5e_ipsec: eth%d mlx5e_ipsec_handle_sw_limits [mlx5_core] RIP: 0010:__xfrm_state_delete+0x3d/0x1b0 Code: 0f 84 8b 01 00 00 48 89 fd c6 87 c8 00 00 00 05 48 8d bb 40 10 00 00 e8 11 04 1a 00 48 8b 95 b8 00 00 00 48 8b 85 c0 00 00 00 <48> 89 42 08 48 89 10 48 8b 55 10 48 b8 00 01 00 00 00 00 ad de 48 RSP: 0018:ffff88885f945ec8 EFLAGS: 00010246 RAX: dead000000000122 RBX: ffffffff82afa940 RCX: 0000000000000036 RDX: dead000000000100 RSI: 0000000000000000 RDI: ffffffff82afb980 RBP: ffff888109a20340 R08: ffff88885f945ea0 R09: 0000000000000000 R10: 0000000000000000 R11: ffff88885f945ff8 R12: 0000000000000246 R13: ffff888109a20340 R14: ffff88885f95f420 R15: ffff88885f95f400 FS: 0000000000000000(0000) GS:ffff88885f940000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2163102430 CR3: 00000001128d6001 CR4: 0000000000370eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? die_addr+0x33/0x90 ? exc_general_protection+0x1a2/0x390 ? asm_exc_general_protection+0x22/0x30 ? __xfrm_state_delete+0x3d/0x1b0 ? __xfrm_state_delete+0x2f/0x1b0 xfrm_timer_handler+0x174/0x350 ? __xfrm_state_delete+0x1b0/0x1b0 __hrtimer_run_queues+0x121/0x270 hrtimer_run_softirq+0x88/0xd0 handle_softirqs+0xcc/0x270 do_softirq+0x3c/0x50 __local_bh_enable_ip+0x47/0x50 mlx5e_ipsec_handle_sw_limits+0x7d/0x90 [mlx5_core] process_one_work+0x137/0x2d0 worker_thread+0x28d/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50000", "url": "https://ubuntu.com/security/CVE-2024-50000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix NULL deref in mlx5e_tir_builder_alloc() In mlx5e_tir_builder_alloc() kvzalloc() may return NULL which is dereferenced on the next line in a reference to the modify field. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50001", "url": "https://ubuntu.com/security/CVE-2024-50001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix error path in multi-packet WQE transmit Remove the erroneous unmap in case no DMA mapping was established The multi-packet WQE transmit code attempts to obtain a DMA mapping for the skb. This could fail, e.g. under memory pressure, when the IOMMU driver just can't allocate more memory for page tables. While the code tries to handle this in the path below the err_unmap label it erroneously unmaps one entry from the sq's FIFO list of active mappings. Since the current map attempt failed this unmap is removing some random DMA mapping that might still be required. If the PCI function now presents that IOVA, the IOMMU may assumes a rogue DMA access and e.g. on s390 puts the PCI function in error state. The erroneous behavior was seen in a stress-test environment that created memory pressure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50179", "url": "https://ubuntu.com/security/CVE-2024-50179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: remove the incorrect Fw reference check when dirtying pages When doing the direct-io reads it will also try to mark pages dirty, but for the read path it won't hold the Fw caps and there is case will it get the Fw reference.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49963", "url": "https://ubuntu.com/security/CVE-2024-49963", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mailbox: bcm2835: Fix timeout during suspend mode During noirq suspend phase the Raspberry Pi power driver suffer of firmware property timeouts. The reason is that the IRQ of the underlying BCM2835 mailbox is disabled and rpi_firmware_property_list() will always run into a timeout [1]. Since the VideoCore side isn't consider as a wakeup source, set the IRQF_NO_SUSPEND flag for the mailbox IRQ in order to keep it enabled during suspend-resume cycle. [1] PM: late suspend of devices complete after 1.754 msecs WARNING: CPU: 0 PID: 438 at drivers/firmware/raspberrypi.c:128 rpi_firmware_property_list+0x204/0x22c Firmware transaction 0x00028001 timeout Modules linked in: CPU: 0 PID: 438 Comm: bash Tainted: G C 6.9.3-dirty #17 Hardware name: BCM2835 Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x44 dump_stack_lvl from __warn+0x88/0xec __warn from warn_slowpath_fmt+0x7c/0xb0 warn_slowpath_fmt from rpi_firmware_property_list+0x204/0x22c rpi_firmware_property_list from rpi_firmware_property+0x68/0x8c rpi_firmware_property from rpi_firmware_set_power+0x54/0xc0 rpi_firmware_set_power from _genpd_power_off+0xe4/0x148 _genpd_power_off from genpd_sync_power_off+0x7c/0x11c genpd_sync_power_off from genpd_finish_suspend+0xcc/0xe0 genpd_finish_suspend from dpm_run_callback+0x78/0xd0 dpm_run_callback from device_suspend_noirq+0xc0/0x238 device_suspend_noirq from dpm_suspend_noirq+0xb0/0x168 dpm_suspend_noirq from suspend_devices_and_enter+0x1b8/0x5ac suspend_devices_and_enter from pm_suspend+0x254/0x2e4 pm_suspend from state_store+0xa8/0xd4 state_store from kernfs_fop_write_iter+0x154/0x1a0 kernfs_fop_write_iter from vfs_write+0x12c/0x184 vfs_write from ksys_write+0x78/0xc0 ksys_write from ret_fast_syscall+0x0/0x54 Exception stack(0xcc93dfa8 to 0xcc93dff0) [...] PM: noirq suspend of devices complete after 3095.584 msecs", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49954", "url": "https://ubuntu.com/security/CVE-2024-49954", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: static_call: Replace pointless WARN_ON() in static_call_module_notify() static_call_module_notify() triggers a WARN_ON(), when memory allocation fails in __static_call_add_module(). That's not really justified, because the failure case must be correctly handled by the well known call chain and the error code is passed through to the initiating userspace application. A memory allocation fail is not a fatal problem, but the WARN_ON() takes the machine out when panic_on_warn is set. Replace it with a pr_warn().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50002", "url": "https://ubuntu.com/security/CVE-2024-50002", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: static_call: Handle module init failure correctly in static_call_del_module() Module insertion invokes static_call_add_module() to initialize the static calls in a module. static_call_add_module() invokes __static_call_init(), which allocates a struct static_call_mod to either encapsulate the built-in static call sites of the associated key into it so further modules can be added or to append the module to the module chain. If that allocation fails the function returns with an error code and the module core invokes static_call_del_module() to clean up eventually added static_call_mod entries. This works correctly, when all keys used by the module were converted over to a module chain before the failure. If not then static_call_del_module() causes a #GP as it blindly assumes that key::mods points to a valid struct static_call_mod. The problem is that key::mods is not a individual struct member of struct static_call_key, it's part of a union to save space: union { /* bit 0: 0 = mods, 1 = sites */ unsigned long type; struct static_call_mod *mods; struct static_call_site *sites; \t}; key::sites is a pointer to the list of built-in usage sites of the static call. The type of the pointer is differentiated by bit 0. A mods pointer has the bit clear, the sites pointer has the bit set. As static_call_del_module() blidly assumes that the pointer is a valid static_call_mod type, it fails to check for this failure case and dereferences the pointer to the list of built-in call sites, which is obviously bogus. Cure it by checking whether the key has a sites or a mods pointer. If it's a sites pointer then the key is not to be touched. As the sites are walked in the same order as in __static_call_init() the site walk can be terminated because all subsequent sites have not been touched by the init code due to the error exit. If it was converted before the allocation fail, then the inner loop which searches for a module match will find nothing. A fail in the second allocation in __static_call_init() is harmless and does not require special treatment. The first allocation succeeded and converted the key to a module chain. That first entry has mod::mod == NULL and mod::next == NULL, so the inner loop of static_call_del_module() will neither find a module match nor a module chain. The next site in the walk was either already converted, but can't match the module, or it will exit the outer loop because it has a static_call_site pointer and not a static_call_mod pointer.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-47675", "url": "https://ubuntu.com/security/CVE-2024-47675", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix use-after-free in bpf_uprobe_multi_link_attach() If bpf_link_prime() fails, bpf_uprobe_multi_link_attach() goes to the error_free label and frees the array of bpf_uprobe's without calling bpf_uprobe_unregister(). This leaks bpf_uprobe->uprobe and worse, this frees bpf_uprobe->consumer without removing it from the uprobe->consumers list.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47676", "url": "https://ubuntu.com/security/CVE-2024-47676", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb.c: fix UAF of vma in hugetlb fault pathway Syzbot reports a UAF in hugetlb_fault(). This happens because vmf_anon_prepare() could drop the per-VMA lock and allow the current VMA to be freed before hugetlb_vma_unlock_read() is called. We can fix this by using a modified version of vmf_anon_prepare() that doesn't release the VMA lock on failure, and then release it ourselves after hugetlb_vma_unlock_read().", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47677", "url": "https://ubuntu.com/security/CVE-2024-47677", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: resolve memory leak from exfat_create_upcase_table() If exfat_load_upcase_table reaches end and returns -EINVAL, allocated memory doesn't get freed and while exfat_load_default_upcase_table allocates more memory, leading to a memory leak. Here's link to syzkaller crash report illustrating this issue: https://syzkaller.appspot.com/text?tag=CrashReport&x=1406c201980000", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47725", "url": "https://ubuntu.com/security/CVE-2024-47725", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47739", "url": "https://ubuntu.com/security/CVE-2024-47739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: padata: use integer wrap around to prevent deadlock on seq_nr overflow When submitting more than 2^32 padata objects to padata_do_serial, the current sorting implementation incorrectly sorts padata objects with overflowed seq_nr, causing them to be placed before existing objects in the reorder list. This leads to a deadlock in the serialization process as padata_find_next cannot match padata->seq_nr and pd->processed because the padata instance with overflowed seq_nr will be selected next. To fix this, we use an unsigned integer wrap around to correctly sort padata objects in scenarios with integer overflow.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47678", "url": "https://ubuntu.com/security/CVE-2024-47678", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: icmp: change the order of rate limits ICMP messages are ratelimited : After the blamed commits, the two rate limiters are applied in this order: 1) host wide ratelimit (icmp_global_allow()) 2) Per destination ratelimit (inetpeer based) In order to avoid side-channels attacks, we need to apply the per destination check first. This patch makes the following change : 1) icmp_global_allow() checks if the host wide limit is reached. But credits are not yet consumed. This is deferred to 3) 2) The per destination limit is checked/updated. This might add a new node in inetpeer tree. 3) icmp_global_consume() consumes tokens if prior operations succeeded. This means that host wide ratelimit is still effective in keeping inetpeer tree small even under DDOS. As a bonus, I removed icmp_global.lock as the fast path can use a lock-free operation.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47733", "url": "https://ubuntu.com/security/CVE-2024-47733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfs: Delete subtree of 'fs/netfs' when netfs module exits In netfs_init() or fscache_proc_init(), we create dentry under 'fs/netfs', but in netfs_exit(), we only delete the proc entry of 'fs/netfs' without deleting its subtree. This triggers the following WARNING: ================================================================== remove_proc_entry: removing non-empty directory 'fs/netfs', leaking at least 'requests' WARNING: CPU: 4 PID: 566 at fs/proc/generic.c:717 remove_proc_entry+0x160/0x1c0 Modules linked in: netfs(-) CPU: 4 UID: 0 PID: 566 Comm: rmmod Not tainted 6.11.0-rc3 #860 RIP: 0010:remove_proc_entry+0x160/0x1c0 Call Trace: netfs_exit+0x12/0x620 [netfs] __do_sys_delete_module.isra.0+0x14c/0x2e0 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e ================================================================== Therefore use remove_proc_subtree() instead of remove_proc_entry() to fix the above problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47679", "url": "https://ubuntu.com/security/CVE-2024-47679", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfs: fix race between evice_inodes() and find_inode()&iput() Hi, all Recently I noticed a bug[1] in btrfs, after digged it into and I believe it'a race in vfs. Let's assume there's a inode (ie ino 261) with i_count 1 is called by iput(), and there's a concurrent thread calling generic_shutdown_super(). cpu0: cpu1: iput() // i_count is 1 ->spin_lock(inode) ->dec i_count to 0 ->iput_final() generic_shutdown_super() ->__inode_add_lru() ->evict_inodes() // cause some reason[2] ->if (atomic_read(inode->i_count)) continue; // return before // inode 261 passed the above check // list_lru_add_obj() // and then schedule out ->spin_unlock() // note here: the inode 261 // was still at sb list and hash list, // and I_FREEING|I_WILL_FREE was not been set btrfs_iget() // after some function calls ->find_inode() // found the above inode 261 ->spin_lock(inode) // check I_FREEING|I_WILL_FREE // and passed ->__iget() ->spin_unlock(inode) // schedule back ->spin_lock(inode) // check (I_NEW|I_FREEING|I_WILL_FREE) flags, // passed and set I_FREEING iput() ->spin_unlock(inode) ->spin_lock(inode)\t\t\t ->evict() // dec i_count to 0 ->iput_final() ->spin_unlock() ->evict() Now, we have two threads simultaneously evicting the same inode, which may trigger the BUG(inode->i_state & I_CLEAR) statement both within clear_inode() and iput(). To fix the bug, recheck the inode->i_count after holding i_lock. Because in the most scenarios, the first check is valid, and the overhead of spin_lock() can be reduced. If there is any misunderstanding, please let me know, thanks. [1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/ [2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable() return false when I reproduced the bug.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49859", "url": "https://ubuntu.com/security/CVE-2024-49859", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to check atomic_file in f2fs ioctl interfaces Some f2fs ioctl interfaces like f2fs_ioc_set_pin_file(), f2fs_move_file_range(), and f2fs_defragment_range() missed to check atomic_write status, which may cause potential race issue, fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47680", "url": "https://ubuntu.com/security/CVE-2024-47680", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: check discard support for conventional zones As the helper function f2fs_bdev_support_discard() shows, f2fs checks if the target block devices support discard by calling bdev_max_discard_sectors() and bdev_is_zoned(). This check works well for most cases, but it does not work for conventional zones on zoned block devices. F2fs assumes that zoned block devices support discard, and calls __submit_discard_cmd(). When __submit_discard_cmd() is called for sequential write required zones, it works fine since __submit_discard_cmd() issues zone reset commands instead of discard commands. However, when __submit_discard_cmd() is called for conventional zones, __blkdev_issue_discard() is called even when the devices do not support discard. The inappropriate __blkdev_issue_discard() call was not a problem before the commit 30f1e7241422 (\"block: move discard checks into the ioctl handler\") because __blkdev_issue_discard() checked if the target devices support discard or not. If not, it returned EOPNOTSUPP. After the commit, __blkdev_issue_discard() no longer checks it. It always returns zero and sets NULL to the given bio pointer. This NULL pointer triggers f2fs_bug_on() in __submit_discard_cmd(). The BUG is recreated with the commands below at the umount step, where /dev/nullb0 is a zoned null_blk with 5GB total size, 128MB zone size and 10 conventional zones. $ mkfs.f2fs -f -m /dev/nullb0 $ mount /dev/nullb0 /mnt $ for ((i=0;i<5;i++)); do dd if=/dev/zero of=/mnt/test bs=65536 count=1600 conv=fsync; done $ umount /mnt To fix the BUG, avoid the inappropriate __blkdev_issue_discard() call. When discard is requested for conventional zones, check if the device supports discard or not. If not, return EOPNOTSUPP.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47740", "url": "https://ubuntu.com/security/CVE-2024-47740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: Require FMODE_WRITE for atomic write ioctls The F2FS ioctls for starting and committing atomic writes check for inode_owner_or_capable(), but this does not give LSMs like SELinux or Landlock an opportunity to deny the write access - if the caller's FSUID matches the inode's UID, inode_owner_or_capable() immediately returns true. There are scenarios where LSMs want to deny a process the ability to write particular files, even files that the FSUID of the process owns; but this can currently partially be bypassed using atomic write ioctls in two ways: - F2FS_IOC_START_ATOMIC_REPLACE + F2FS_IOC_COMMIT_ATOMIC_WRITE can truncate an inode to size 0 - F2FS_IOC_START_ATOMIC_WRITE + F2FS_IOC_ABORT_ATOMIC_WRITE can revert changes another process concurrently made to a file Fix it by requiring FMODE_WRITE for these operations, just like for F2FS_IOC_MOVE_RANGE. Since any legitimate caller should only be using these ioctls when intending to write into the file, that seems unlikely to break anything.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47726", "url": "https://ubuntu.com/security/CVE-2024-47726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to wait dio completion It should wait all existing dio write IOs before block removal, otherwise, previous direct write IO may overwrite data in the block which may be reused by other inode.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47741", "url": "https://ubuntu.com/security/CVE-2024-47741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race setting file private on concurrent lseek using same fd When doing concurrent lseek(2) system calls against the same file descriptor, using multiple threads belonging to the same process, we have a short time window where a race happens and can result in a memory leak. The race happens like this: 1) A program opens a file descriptor for a file and then spawns two threads (with the pthreads library for example), lets call them task A and task B; 2) Task A calls lseek with SEEK_DATA or SEEK_HOLE and ends up at file.c:find_desired_extent() while holding a read lock on the inode; 3) At the start of find_desired_extent(), it extracts the file's private_data pointer into a local variable named 'private', which has a value of NULL; 4) Task B also calls lseek with SEEK_DATA or SEEK_HOLE, locks the inode in shared mode and enters file.c:find_desired_extent(), where it also extracts file->private_data into its local variable 'private', which has a NULL value; 5) Because it saw a NULL file private, task A allocates a private structure and assigns to the file structure; 6) Task B also saw a NULL file private so it also allocates its own file private and then assigns it to the same file structure, since both tasks are using the same file descriptor. At this point we leak the private structure allocated by task A. Besides the memory leak, there's also the detail that both tasks end up using the same cached state record in the private structure (struct btrfs_file_private::llseek_cached_state), which can result in a use-after-free problem since one task can free it while the other is still using it (only one task took a reference count on it). Also, sharing the cached state is not a good idea since it could result in incorrect results in the future - right now it should not be a problem because it end ups being used only in extent-io-tree.c:count_range_bits() where we do range validation before using the cached state. Fix this by protecting the private assignment and check of a file while holding the inode's spinlock and keep track of the task that allocated the private, so that it's used only by that task in order to prevent user-after-free issues with the cached state record as well as potentially using it incorrectly in the future.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47681", "url": "https://ubuntu.com/security/CVE-2024-47681", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix NULL pointer dereference in mt7996_mcu_sta_bfer_he Fix the NULL pointer dereference in mt7996_mcu_sta_bfer_he routine adding an sta interface to the mt7996 driver. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49858", "url": "https://ubuntu.com/security/CVE-2024-49858", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption The TPM event log table is a Linux specific construct, where the data produced by the GetEventLog() boot service is cached in memory, and passed on to the OS using an EFI configuration table. The use of EFI_LOADER_DATA here results in the region being left unreserved in the E820 memory map constructed by the EFI stub, and this is the memory description that is passed on to the incoming kernel by kexec, which is therefore unaware that the region should be reserved. Even though the utility of the TPM2 event log after a kexec is questionable, any corruption might send the parsing code off into the weeds and crash the kernel. So let's use EFI_ACPI_RECLAIM_MEMORY instead, which is always treated as reserved by the E820 conversion logic.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49860", "url": "https://ubuntu.com/security/CVE-2024-49860", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: sysfs: validate return type of _STR method Only buffer objects are valid return values of _STR. If something else is returned description_show() will access invalid memory.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47742", "url": "https://ubuntu.com/security/CVE-2024-47742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware_loader: Block path traversal Most firmware names are hardcoded strings, or are constructed from fairly constrained format strings where the dynamic parts are just some hex numbers or such. However, there are a couple codepaths in the kernel where firmware file names contain string components that are passed through from a device or semi-privileged userspace; the ones I could find (not counting interfaces that require root privileges) are: - lpfc_sli4_request_firmware_update() seems to construct the firmware filename from \"ModelName\", a string that was previously parsed out of some descriptor (\"Vital Product Data\") in lpfc_fill_vpd() - nfp_net_fw_find() seems to construct a firmware filename from a model name coming from nfp_hwinfo_lookup(pf->hwinfo, \"nffw.partno\"), which I think parses some descriptor that was read from the device. (But this case likely isn't exploitable because the format string looks like \"netronome/nic_%s\", and there shouldn't be any *folders* starting with \"netronome/nic_\". The previous case was different because there, the \"%s\" is *at the start* of the format string.) - module_flash_fw_schedule() is reachable from the ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is enough to pass the privilege check), and takes a userspace-provided firmware name. (But I think to reach this case, you need to have CAP_NET_ADMIN over a network namespace that a special kind of ethernet device is mapped into, so I think this is not a viable attack path in practice.) Fix it by rejecting any firmware names containing \"..\" path components. For what it's worth, I went looking and haven't found any USB device drivers that use the firmware loader dangerously.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47682", "url": "https://ubuntu.com/security/CVE-2024-47682", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sd: Fix off-by-one error in sd_read_block_characteristics() Ff the device returns page 0xb1 with length 8 (happens with qemu v2.x, for example), sd_read_block_characteristics() may attempt an out-of-bounds memory access when accessing the zoned field at offset 8.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47743", "url": "https://ubuntu.com/security/CVE-2024-47743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: prevent NULL pointer dereference in find_asymmetric_key() In find_asymmetric_key(), if all NULLs are passed in the id_{0,1,2} arguments, the kernel will first emit WARN but then have an oops because id_2 gets dereferenced anyway. Add the missing id_2 check and move WARN_ON() to the final else branch to avoid duplicate NULL checks. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47727", "url": "https://ubuntu.com/security/CVE-2024-47727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/tdx: Fix \"in-kernel MMIO\" check TDX only supports kernel-initiated MMIO operations. The handle_mmio() function checks if the #VE exception occurred in the kernel and rejects the operation if it did not. However, userspace can deceive the kernel into performing MMIO on its behalf. For example, if userspace can point a syscall to an MMIO address, syscall does get_user() or put_user() on it, triggering MMIO #VE. The kernel will treat the #VE as in-kernel MMIO. Ensure that the target MMIO address is within the kernel before decoding instruction.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47744", "url": "https://ubuntu.com/security/CVE-2024-47744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Use dedicated mutex to protect kvm_usage_count to avoid deadlock Use a dedicated mutex to guard kvm_usage_count to fix a potential deadlock on x86 due to a chain of locks and SRCU synchronizations. Translating the below lockdep splat, CPU1 #6 will wait on CPU0 #1, CPU0 #8 will wait on CPU2 #3, and CPU2 #7 will wait on CPU1 #4 (if there's a writer, due to the fairness of r/w semaphores). CPU0 CPU1 CPU2 1 lock(&kvm->slots_lock); 2 lock(&vcpu->mutex); 3 lock(&kvm->srcu); 4 lock(cpu_hotplug_lock); 5 lock(kvm_lock); 6 lock(&kvm->slots_lock); 7 lock(cpu_hotplug_lock); 8 sync(&kvm->srcu); Note, there are likely more potential deadlocks in KVM x86, e.g. the same pattern of taking cpu_hotplug_lock outside of kvm_lock likely exists with __kvmclock_cpufreq_notifier(): cpuhp_cpufreq_online() | -> cpufreq_online() | -> cpufreq_gov_performance_limits() | -> __cpufreq_driver_target() | -> __target_index() | -> cpufreq_freq_transition_begin() | -> cpufreq_notify_transition() | -> ... __kvmclock_cpufreq_notifier() But, actually triggering such deadlocks is beyond rare due to the combination of dependencies and timings involved. E.g. the cpufreq notifier is only used on older CPUs without a constant TSC, mucking with the NX hugepage mitigation while VMs are running is very uncommon, and doing so while also onlining/offlining a CPU (necessary to generate contention on cpu_hotplug_lock) would be even more unusual. The most robust solution to the general cpu_hotplug_lock issue is likely to switch vm_list to be an RCU-protected list, e.g. so that x86's cpufreq notifier doesn't to take kvm_lock. For now, settle for fixing the most blatant deadlock, as switching to an RCU-protected list is a much more involved change, but add a comment in locking.rst to call out that care needs to be taken when walking holding kvm_lock and walking vm_list. ====================================================== WARNING: possible circular locking dependency detected 6.10.0-smp--c257535a0c9d-pip #330 Tainted: G S O ------------------------------------------------------ tee/35048 is trying to acquire lock: ff6a80eced71e0a8 (&kvm->slots_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x179/0x1e0 [kvm] but task is already holding lock: ffffffffc07abb08 (kvm_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x14a/0x1e0 [kvm] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (kvm_lock){+.+.}-{3:3}: __mutex_lock+0x6a/0xb40 mutex_lock_nested+0x1f/0x30 kvm_dev_ioctl+0x4fb/0xe50 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #2 (cpu_hotplug_lock){++++}-{0:0}: cpus_read_lock+0x2e/0xb0 static_key_slow_inc+0x16/0x30 kvm_lapic_set_base+0x6a/0x1c0 [kvm] kvm_set_apic_base+0x8f/0xe0 [kvm] kvm_set_msr_common+0x9ae/0xf80 [kvm] vmx_set_msr+0xa54/0xbe0 [kvm_intel] __kvm_set_msr+0xb6/0x1a0 [kvm] kvm_arch_vcpu_ioctl+0xeca/0x10c0 [kvm] kvm_vcpu_ioctl+0x485/0x5b0 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (&kvm->srcu){.+.+}-{0:0}: __synchronize_srcu+0x44/0x1a0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47719", "url": "https://ubuntu.com/security/CVE-2024-47719", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommufd: Protect against overflow of ALIGN() during iova allocation Userspace can supply an iova and uptr such that the target iova alignment becomes really big and ALIGN() overflows which corrupts the selected area range during allocation. CONFIG_IOMMUFD_TEST can detect this: WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline] WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352 Modules linked in: CPU: 1 PID: 5092 Comm: syz-executor294 Not tainted 6.10.0-rc5-syzkaller-00294-g3ffea9a7a6f7 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024 RIP: 0010:iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline] RIP: 0010:iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352 Code: fc e9 a4 f3 ff ff e8 1a 8b 4c fc 41 be e4 ff ff ff e9 8a f3 ff ff e8 0a 8b 4c fc 90 0f 0b 90 e9 37 f5 ff ff e8 fc 8a 4c fc 90 <0f> 0b 90 e9 68 f3 ff ff 48 c7 c1 ec 82 ad 8f 80 e1 07 80 c1 03 38 RSP: 0018:ffffc90003ebf9e0 EFLAGS: 00010293 RAX: ffffffff85499fa4 RBX: 00000000ffffffef RCX: ffff888079b49e00 RDX: 0000000000000000 RSI: 00000000ffffffef RDI: 0000000000000000 RBP: ffffc90003ebfc50 R08: ffffffff85499b30 R09: ffffffff85499942 R10: 0000000000000002 R11: ffff888079b49e00 R12: ffff8880228e0010 R13: 0000000000000000 R14: 1ffff920007d7f68 R15: ffffc90003ebfd00 FS: 000055557d760380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000005fdeb8 CR3: 000000007404a000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: iommufd_ioas_copy+0x610/0x7b0 drivers/iommu/iommufd/ioas.c:274 iommufd_fops_ioctl+0x4d9/0x5a0 drivers/iommu/iommufd/main.c:421 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Cap the automatic alignment to the huge page size, which is probably a better idea overall. Huge automatic alignments can fragment and chew up the available IOVA space without any reason.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47745", "url": "https://ubuntu.com/security/CVE-2024-47745", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: call the security_mmap_file() LSM hook in remap_file_pages() The remap_file_pages syscall handler calls do_mmap() directly, which doesn't contain the LSM security check. And if the process has called personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for RW pages, this will actually result in remapping the pages to RWX, bypassing a W^X policy enforced by SELinux. So we should check prot by security_mmap_file LSM hook in the remap_file_pages syscall handler before do_mmap() is called. Otherwise, it potentially permits an attacker to bypass a W^X policy enforced by SELinux. The bypass is similar to CVE-2016-10044, which bypass the same thing via AIO and can be found in [1]. The PoC: $ cat > test.c int main(void) { \tsize_t pagesz = sysconf(_SC_PAGE_SIZE); \tint mfd = syscall(SYS_memfd_create, \"test\", 0); \tconst char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE, \t\tMAP_SHARED, mfd, 0); \tunsigned int old = syscall(SYS_personality, 0xffffffff); \tsyscall(SYS_personality, READ_IMPLIES_EXEC | old); \tsyscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0); \tsyscall(SYS_personality, old); \t// show the RWX page exists even if W^X policy is enforced \tint fd = open(\"/proc/self/maps\", O_RDONLY); \tunsigned char buf2[1024]; \twhile (1) { \t\tint ret = read(fd, buf2, 1024); \t\tif (ret <= 0) break; \t\twrite(1, buf2, ret); \t} \tclose(fd); } $ gcc test.c -o test $ ./test | grep rwx 7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted) [PM: subject line tweaks]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47746", "url": "https://ubuntu.com/security/CVE-2024-47746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: use exclusive lock when FUSE_I_CACHE_IO_MODE is set This may be a typo. The comment has said shared locks are not allowed when this bit is set. If using shared lock, the wait in `fuse_file_cached_io_open` may be forever.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47734", "url": "https://ubuntu.com/security/CVE-2024-47734", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: Fix unnecessary warnings and logs from bond_xdp_get_xmit_slave() syzbot reported a WARNING in bond_xdp_get_xmit_slave. To reproduce this[1], one bond device (bond1) has xdpdrv, which increases bpf_master_redirect_enabled_key. Another bond device (bond0) which is unsupported by XDP but its slave (veth3) has xdpgeneric that returns XDP_TX. This triggers WARN_ON_ONCE() from the xdp_master_redirect(). To reduce unnecessary warnings and improve log management, we need to delete the WARN_ON_ONCE() and add ratelimit to the netdev_err(). [1] Steps to reproduce: # Needs tx_xdp with return XDP_TX; ip l add veth0 type veth peer veth1 ip l add veth3 type veth peer veth4 ip l add bond0 type bond mode 6 # BOND_MODE_ALB, unsupported by XDP ip l add bond1 type bond # BOND_MODE_ROUNDROBIN by default ip l set veth0 master bond1 ip l set bond1 up # Increases bpf_master_redirect_enabled_key ip l set dev bond1 xdpdrv object tx_xdp.o section xdp_tx ip l set veth3 master bond0 ip l set bond0 up ip l set veth4 up # Triggers WARN_ON_ONCE() from the xdp_master_redirect() ip l set veth3 xdpgeneric object tx_xdp.o section xdp_tx", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47684", "url": "https://ubuntu.com/security/CVE-2024-47684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: check skb is non-NULL in tcp_rto_delta_us() We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic kernel that are running ceph and recently hit a null ptr dereference in tcp_rearm_rto(). Initially hitting it from the TLP path, but then later we also saw it getting hit from the RACK case as well. Here are examples of the oops messages we saw in each of those cases: Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020 Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode Jul 26 15:05:02 rx [11061395.792971] #PF: error_code(0x0000) - not-present page Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0 Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI Jul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu Jul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023 Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 <48> 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3 Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246 Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000 Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60 Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8 Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900 Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30 Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000 Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0 Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554 Jul 26 15:05:02 rx [11061395.916786] Call Trace: Jul 26 15:05:02 rx [11061395.919488] Jul 26 15:05:02 rx [11061395.921765] ? show_regs.cold+0x1a/0x1f Jul 26 15:05:02 rx [11061395.925859] ? __die+0x90/0xd9 Jul 26 15:05:02 rx [11061395.929169] ? no_context+0x196/0x380 Jul 26 15:05:02 rx [11061395.933088] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0 Jul 26 15:05:02 rx [11061395.938216] ? ip6_sublist_rcv_finish+0x3d/0x50 Jul 26 15:05:02 rx [11061395.943000] ? __bad_area_nosemaphore+0x50/0x1a0 Jul 26 15:05:02 rx [11061395.947873] ? bad_area_nosemaphore+0x16/0x20 Jul 26 15:05:02 rx [11061395.952486] ? do_user_addr_fault+0x267/0x450 Jul 26 15:05:02 rx [11061395.957104] ? ipv6_list_rcv+0x112/0x140 Jul 26 15:05:02 rx [11061395.961279] ? __do_page_fault+0x58/0x90 Jul 26 15:05:02 rx [11061395.965458] ? do_page_fault+0x2c/0xe0 Jul 26 15:05:02 rx [11061395.969465] ? page_fault+0x34/0x40 Jul 26 15:05:02 rx [11061395.973217] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.977313] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.981408] tcp_send_loss_probe+0x10b/0x220 Jul 26 15:05:02 rx [11061395.985937] tcp_write_timer_handler+0x1b4/0x240 Jul 26 15:05:02 rx [11061395.990809] tcp_write_timer+0x9e/0xe0 Jul 26 15:05:02 rx [11061395.994814] ? tcp_write_timer_handler+0x240/0x240 Jul 26 15:05:02 rx [11061395.999866] call_timer_fn+0x32/0x130 Jul 26 15:05:02 rx [11061396.003782] __run_timers.part.0+0x180/0x280 Jul 26 15:05:02 rx [11061396.008309] ? recalibrate_cpu_khz+0x10/0x10 Jul 26 15:05:02 rx [11061396.012841] ? native_x2apic_icr_write+0x30/0x30 Jul 26 15:05:02 rx [11061396.017718] ? lapic_next_even ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47747", "url": "https://ubuntu.com/security/CVE-2024-47747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race Condition In the ether3_probe function, a timer is initialized with a callback function ether3_ledoff, bound to &prev(dev)->timer. Once the timer is started, there is a risk of a race condition if the module or device is removed, triggering the ether3_remove function to perform cleanup. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | ether3_ledoff ether3_remove | free_netdev(dev); | put_devic | kfree(dev); | | ether3_outw(priv(dev)->regs.config2 |= CFG2_CTRLO, REG_CONFIG2); | // use dev Fix it by ensuring that the timer is canceled before proceeding with the cleanup in ether3_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47685", "url": "https://ubuntu.com/security/CVE-2024-47685", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put() syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending garbage on the four reserved tcp bits (th->res1) Use skb_put_zero() to clear the whole TCP header, as done in nf_reject_ip_tcphdr_put() BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5661 [inline] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775 process_backlog+0x4ad/0xa50 net/core/dev.c:6108 __napi_poll+0xe7/0x980 net/core/dev.c:6772 napi_poll net/core/dev.c:6841 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963 handle_softirqs+0x1ce/0x800 kernel/softirq.c:554 __do_softirq+0x14/0x1a kernel/softirq.c:588 do_softirq+0x9a/0x100 kernel/softirq.c:455 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline] __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450 dev_queue_xmit include/linux/netdevice.h:3105 [inline] neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366 inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135 __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143 tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333 __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679 inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750 __sys_connect_file net/socket.c:2061 [inline] __sys_connect+0x606/0x690 net/socket.c:2078 __do_sys_connect net/socket.c:2088 [inline] __se_sys_connect net/socket.c:2085 [inline] __x64_sys_connect+0x91/0xe0 net/socket.c:2085 x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43 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 Uninit was stored to memory at: nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47686", "url": "https://ubuntu.com/security/CVE-2024-47686", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ep93xx: clock: Fix off by one in ep93xx_div_recalc_rate() The psc->div[] array has psc->num_div elements. These values come from when we call clk_hw_register_div(). It's adc_divisors and ARRAY_SIZE(adc_divisors)) and so on. So this condition needs to be >= instead of > to prevent an out of bounds read.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47748", "url": "https://ubuntu.com/security/CVE-2024-47748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost_vdpa: assign irq bypass producer token correctly We used to call irq_bypass_unregister_producer() in vhost_vdpa_setup_vq_irq() which is problematic as we don't know if the token pointer is still valid or not. Actually, we use the eventfd_ctx as the token so the life cycle of the token should be bound to the VHOST_SET_VRING_CALL instead of vhost_vdpa_setup_vq_irq() which could be called by set_status(). Fixing this by setting up irq bypass producer's token when handling VHOST_SET_VRING_CALL and un-registering the producer before calling vhost_vring_ioctl() to prevent a possible use after free as eventfd could have been released in vhost_vring_ioctl(). And such registering and unregistering will only be done if DRIVER_OK is set.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47687", "url": "https://ubuntu.com/security/CVE-2024-47687", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa/mlx5: Fix invalid mr resource destroy Certain error paths from mlx5_vdpa_dev_add() can end up releasing mr resources which never got initialized in the first place. This patch adds the missing check in mlx5_vdpa_destroy_mr_resources() to block releasing non-initialized mr resources. Reference trace: mlx5_core 0000:08:00.2: mlx5_vdpa_dev_add:3274:(pid 2700) warning: No mac address provisioned? BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 140216067 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 8 PID: 2700 Comm: vdpa Kdump: loaded Not tainted 5.14.0-496.el9.x86_64 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:vhost_iotlb_del_range+0xf/0xe0 [vhost_iotlb] Code: [...] RSP: 0018:ff1c823ac23077f0 EFLAGS: 00010246 RAX: ffffffffc1a21a60 RBX: ffffffff899567a0 RCX: 0000000000000000 RDX: ffffffffffffffff RSI: 0000000000000000 RDI: 0000000000000000 RBP: ff1bda1f7c21e800 R08: 0000000000000000 R09: ff1c823ac2307670 R10: ff1c823ac2307668 R11: ffffffff8a9e7b68 R12: 0000000000000000 R13: 0000000000000000 R14: ff1bda1f43e341a0 R15: 00000000ffffffea FS: 00007f56eba7c740(0000) GS:ff1bda269f800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000104d90001 CR4: 0000000000771ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? mlx5_vdpa_free+0x3d/0x150 [mlx5_vdpa] ? __die_body.cold+0x8/0xd ? page_fault_oops+0x134/0x170 ? __irq_work_queue_local+0x2b/0xc0 ? irq_work_queue+0x2c/0x50 ? exc_page_fault+0x62/0x150 ? asm_exc_page_fault+0x22/0x30 ? __pfx_mlx5_vdpa_free+0x10/0x10 [mlx5_vdpa] ? vhost_iotlb_del_range+0xf/0xe0 [vhost_iotlb] mlx5_vdpa_free+0x3d/0x150 [mlx5_vdpa] vdpa_release_dev+0x1e/0x50 [vdpa] device_release+0x31/0x90 kobject_cleanup+0x37/0x130 mlx5_vdpa_dev_add+0x2d2/0x7a0 [mlx5_vdpa] vdpa_nl_cmd_dev_add_set_doit+0x277/0x4c0 [vdpa] genl_family_rcv_msg_doit+0xd9/0x130 genl_family_rcv_msg+0x14d/0x220 ? __pfx_vdpa_nl_cmd_dev_add_set_doit+0x10/0x10 [vdpa] ? _copy_to_user+0x1a/0x30 ? move_addr_to_user+0x4b/0xe0 genl_rcv_msg+0x47/0xa0 ? __import_iovec+0x46/0x150 ? __pfx_genl_rcv_msg+0x10/0x10 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x245/0x370 netlink_sendmsg+0x206/0x440 __sys_sendto+0x1dc/0x1f0 ? do_read_fault+0x10c/0x1d0 ? do_pte_missing+0x10d/0x190 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x5c/0xf0 ? __count_memcg_events+0x4f/0xb0 ? mm_account_fault+0x6c/0x100 ? handle_mm_fault+0x116/0x270 ? do_user_addr_fault+0x1d6/0x6a0 ? do_syscall_64+0x6b/0xf0 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 entry_SYSCALL_64_after_hwframe+0x78/0x80", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47688", "url": "https://ubuntu.com/security/CVE-2024-47688", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: driver core: Fix a potential null-ptr-deref in module_add_driver() Inject fault while probing of-fpga-region, if kasprintf() fails in module_add_driver(), the second sysfs_remove_link() in exit path will cause null-ptr-deref as below because kernfs_name_hash() will call strlen() with NULL driver_name. Fix it by releasing resources based on the exit path sequence. \t KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] \t Mem abort info: \t ESR = 0x0000000096000005 \t EC = 0x25: DABT (current EL), IL = 32 bits \t SET = 0, FnV = 0 \t EA = 0, S1PTW = 0 \t FSC = 0x05: level 1 translation fault \t Data abort info: \t ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 \t CM = 0, WnR = 0, TnD = 0, TagAccess = 0 \t GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 \t [dfffffc000000000] address between user and kernel address ranges \t Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP \t Dumping ftrace buffer: \t (ftrace buffer empty) \t Modules linked in: of_fpga_region(+) fpga_region fpga_bridge cfg80211 rfkill 8021q garp mrp stp llc ipv6 [last unloaded: of_fpga_region] \t CPU: 2 UID: 0 PID: 2036 Comm: modprobe Not tainted 6.11.0-rc2-g6a0e38264012 #295 \t Hardware name: linux,dummy-virt (DT) \t pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) \t pc : strlen+0x24/0xb0 \t lr : kernfs_name_hash+0x1c/0xc4 \t sp : ffffffc081f97380 \t x29: ffffffc081f97380 x28: ffffffc081f97b90 x27: ffffff80c821c2a0 \t x26: ffffffedac0be418 x25: 0000000000000000 x24: ffffff80c09d2000 \t x23: 0000000000000000 x22: 0000000000000000 x21: 0000000000000000 \t x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000001840 \t x17: 0000000000000000 x16: 0000000000000000 x15: 1ffffff8103f2e42 \t x14: 00000000f1f1f1f1 x13: 0000000000000004 x12: ffffffb01812d61d \t x11: 1ffffff01812d61c x10: ffffffb01812d61c x9 : dfffffc000000000 \t x8 : 0000004fe7ed29e4 x7 : ffffff80c096b0e7 x6 : 0000000000000001 \t x5 : ffffff80c096b0e0 x4 : 1ffffffdb990efa2 x3 : 0000000000000000 \t x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000000 \t Call trace: \t strlen+0x24/0xb0 \t kernfs_name_hash+0x1c/0xc4 \t kernfs_find_ns+0x118/0x2e8 \t kernfs_remove_by_name_ns+0x80/0x100 \t sysfs_remove_link+0x74/0xa8 \t module_add_driver+0x278/0x394 \t bus_add_driver+0x1f0/0x43c \t driver_register+0xf4/0x3c0 \t __platform_driver_register+0x60/0x88 \t of_fpga_region_init+0x20/0x1000 [of_fpga_region] \t do_one_initcall+0x110/0x788 \t do_init_module+0x1dc/0x5c8 \t load_module+0x3c38/0x4cac \t init_module_from_file+0xd4/0x128 \t idempotent_init_module+0x2cc/0x528 \t __arm64_sys_finit_module+0xac/0x100 \t invoke_syscall+0x6c/0x258 \t el0_svc_common.constprop.0+0x160/0x22c \t do_el0_svc+0x44/0x5c \t el0_svc+0x48/0xb8 \t el0t_64_sync_handler+0x13c/0x158 \t el0t_64_sync+0x190/0x194 \t Code: f2fbffe1 a90157f4 12000802 aa0003f5 (38e16861) \t ---[ end trace 0000000000000000 ]--- \t Kernel panic - not syncing: Oops: Fatal exception", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47689", "url": "https://ubuntu.com/security/CVE-2024-47689", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to don't set SB_RDONLY in f2fs_handle_critical_error() syzbot reports a f2fs bug as below: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 58 at kernel/rcu/sync.c:177 rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177 CPU: 1 UID: 0 PID: 58 Comm: kworker/1:2 Not tainted 6.10.0-syzkaller-12562-g1722389b0d86 #0 Workqueue: events destroy_super_work RIP: 0010:rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177 Call Trace: percpu_free_rwsem+0x41/0x80 kernel/locking/percpu-rwsem.c:42 destroy_super_work+0xec/0x130 fs/super.c:282 process_one_work kernel/workqueue.c:3231 [inline] process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 worker_thread+0x86d/0xd40 kernel/workqueue.c:3390 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 As Christian Brauner pointed out [1]: the root cause is f2fs sets SB_RDONLY flag in internal function, rather than setting the flag covered w/ sb->s_umount semaphore via remount procedure, then below race condition causes this bug: - freeze_super() - sb_wait_write(sb, SB_FREEZE_WRITE) - sb_wait_write(sb, SB_FREEZE_PAGEFAULT) - sb_wait_write(sb, SB_FREEZE_FS) \t\t\t\t\t- f2fs_handle_critical_error \t\t\t\t\t - sb->s_flags |= SB_RDONLY - thaw_super - thaw_super_locked - sb_rdonly() is true, so it skips sb_freeze_unlock(sb, SB_FREEZE_FS) - deactivate_locked_super Since f2fs has almost the same logic as ext4 [2] when handling critical error in filesystem if it mounts w/ errors=remount-ro option: - set CP_ERROR_FLAG flag which indicates filesystem is stopped - record errors to superblock - set SB_RDONLY falg Once we set CP_ERROR_FLAG flag, all writable interfaces can detect the flag and stop any further updates on filesystem. So, it is safe to not set SB_RDONLY flag, let's remove the logic and keep in line w/ ext4 [3]. [1] https://lore.kernel.org/all/20240729-himbeeren-funknetz-96e62f9c7aee@brauner [2] https://lore.kernel.org/all/20240729132721.hxih6ehigadqf7wx@quack3 [3] https://lore.kernel.org/linux-ext4/20240805201241.27286-1-jack@suse.cz", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47690", "url": "https://ubuntu.com/security/CVE-2024-47690", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: get rid of online repaire on corrupted directory syzbot reports a f2fs bug as below: kernel BUG at fs/f2fs/inode.c:896! RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Call Trace: evict+0x532/0x950 fs/inode.c:704 dispose_list fs/inode.c:747 [inline] evict_inodes+0x5f9/0x690 fs/inode.c:797 generic_shutdown_super+0x9d/0x2d0 fs/super.c:627 kill_block_super+0x44/0x90 fs/super.c:1696 kill_f2fs_super+0x344/0x690 fs/f2fs/super.c:4898 deactivate_locked_super+0xc4/0x130 fs/super.c:473 cleanup_mnt+0x41f/0x4b0 fs/namespace.c:1373 task_work_run+0x24f/0x310 kernel/task_work.c:228 ptrace_notify+0x2d2/0x380 kernel/signal.c:2402 ptrace_report_syscall include/linux/ptrace.h:415 [inline] ptrace_report_syscall_exit include/linux/ptrace.h:477 [inline] syscall_exit_work+0xc6/0x190 kernel/entry/common.c:173 syscall_exit_to_user_mode_prepare kernel/entry/common.c:200 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:205 [inline] syscall_exit_to_user_mode+0x279/0x370 kernel/entry/common.c:218 do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Online repaire on corrupted directory in f2fs_lookup() can generate dirty data/meta while racing w/ readonly remount, it may leave dirty inode after filesystem becomes readonly, however, checkpoint() will skips flushing dirty inode in a state of readonly mode, result in above panic. Let's get rid of online repaire in f2fs_lookup(), and leave the work to fsck.f2fs.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47691", "url": "https://ubuntu.com/security/CVE-2024-47691", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread() syzbot reports a f2fs bug as below: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_report+0xe8/0x550 mm/kasan/report.c:491 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 instrument_atomic_read_write include/linux/instrumented.h:96 [inline] atomic_fetch_add_relaxed include/linux/atomic/atomic-instrumented.h:252 [inline] __refcount_add include/linux/refcount.h:184 [inline] __refcount_inc include/linux/refcount.h:241 [inline] refcount_inc include/linux/refcount.h:258 [inline] get_task_struct include/linux/sched/task.h:118 [inline] kthread_stop+0xca/0x630 kernel/kthread.c:704 f2fs_stop_gc_thread+0x65/0xb0 fs/f2fs/gc.c:210 f2fs_do_shutdown+0x192/0x540 fs/f2fs/file.c:2283 f2fs_ioc_shutdown fs/f2fs/file.c:2325 [inline] __f2fs_ioctl+0x443a/0xbe60 fs/f2fs/file.c:4325 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f The root cause is below race condition, it may cause use-after-free issue in sbi->gc_th pointer. - remount - f2fs_remount - f2fs_stop_gc_thread - kfree(gc_th) \t\t\t\t- f2fs_ioc_shutdown \t\t\t\t - f2fs_do_shutdown \t\t\t\t - f2fs_stop_gc_thread \t\t\t\t - kthread_stop(gc_th->f2fs_gc_task) : sbi->gc_thread = NULL; We will call f2fs_do_shutdown() in two paths: - for f2fs_ioc_shutdown() path, we should grab sb->s_umount semaphore for fixing. - for f2fs_shutdown() path, it's safe since caller has already grabbed sb->s_umount semaphore.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47692", "url": "https://ubuntu.com/security/CVE-2024-47692", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: return -EINVAL when namelen is 0 When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may result in namelen being 0, which will cause memdup_user() to return ZERO_SIZE_PTR. When we access the name.data that has been assigned the value of ZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is triggered. [ T1205] ================================================================== [ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260 [ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205 [ T1205] [ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406 [ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ T1205] Call Trace: [ T1205] dump_stack+0x9a/0xd0 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] __kasan_report.cold+0x34/0x84 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] kasan_report+0x3a/0x50 [ T1205] nfs4_client_to_reclaim+0xe9/0x260 [ T1205] ? nfsd4_release_lockowner+0x410/0x410 [ T1205] cld_pipe_downcall+0x5ca/0x760 [ T1205] ? nfsd4_cld_tracking_exit+0x1d0/0x1d0 [ T1205] ? down_write_killable_nested+0x170/0x170 [ T1205] ? avc_policy_seqno+0x28/0x40 [ T1205] ? selinux_file_permission+0x1b4/0x1e0 [ T1205] rpc_pipe_write+0x84/0xb0 [ T1205] vfs_write+0x143/0x520 [ T1205] ksys_write+0xc9/0x170 [ T1205] ? __ia32_sys_read+0x50/0x50 [ T1205] ? ktime_get_coarse_real_ts64+0xfe/0x110 [ T1205] ? ktime_get_coarse_real_ts64+0xa2/0x110 [ T1205] do_syscall_64+0x33/0x40 [ T1205] entry_SYSCALL_64_after_hwframe+0x67/0xd1 [ T1205] RIP: 0033:0x7fdbdb761bc7 [ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 514 [ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7 [ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008 [ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001 [ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b [ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000 [ T1205] ================================================================== Fix it by checking namelen.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47737", "url": "https://ubuntu.com/security/CVE-2024-47737", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: call cache_put if xdr_reserve_space returns NULL If not enough buffer space available, but idmap_lookup has triggered lookup_fn which calls cache_get and returns successfully. Then we missed to call cache_put here which pairs with cache_get. Reviwed-by: Jeff Layton ", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2023-52917", "url": "https://ubuntu.com/security/CVE-2023-52917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir() The debugfs_create_dir() function returns error pointers. It never returns NULL. So use IS_ERR() to check it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47749", "url": "https://ubuntu.com/security/CVE-2024-47749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Added NULL check for lookup_atid The lookup_atid() function can return NULL if the ATID is invalid or does not exist in the identifier table, which could lead to dereferencing a null pointer without a check in the `act_establish()` and `act_open_rpl()` functions. Add a NULL check to prevent null pointer dereferencing. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47735", "url": "https://ubuntu.com/security/CVE-2024-47735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled Fix missuse of spin_lock_irq()/spin_unlock_irq() when spin_lock_irqsave()/spin_lock_irqrestore() was hold. This was discovered through the lock debugging, and the corresponding log is as follows: raw_local_irq_restore() called with IRQs enabled WARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40 ... Call trace: warn_bogus_irq_restore+0x30/0x40 _raw_spin_unlock_irqrestore+0x84/0xc8 add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2] hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2] hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2] create_qp+0x138/0x258 ib_create_qp_kernel+0x50/0xe8 create_mad_qp+0xa8/0x128 ib_mad_port_open+0x218/0x448 ib_mad_init_device+0x70/0x1f8 add_client_context+0xfc/0x220 enable_device_and_get+0xd0/0x140 ib_register_device.part.0+0xf4/0x1c8 ib_register_device+0x34/0x50 hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2] hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2] __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2] hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47750", "url": "https://ubuntu.com/security/CVE-2024-47750", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix Use-After-Free of rsv_qp on HIP08 Currently rsv_qp is freed before ib_unregister_device() is called on HIP08. During the time interval, users can still dereg MR and rsv_qp will be used in this process, leading to a UAF. Move the release of rsv_qp after calling ib_unregister_device() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47751", "url": "https://ubuntu.com/security/CVE-2024-47751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: kirin: Fix buffer overflow in kirin_pcie_parse_port() Within kirin_pcie_parse_port(), the pcie->num_slots is compared to pcie->gpio_id_reset size (MAX_PCI_SLOTS) which is correct and would lead to an overflow. Thus, fix condition to pcie->num_slots + 1 >= MAX_PCI_SLOTS and move pcie->num_slots increment below the if-statement to avoid out-of-bounds array access. Found by Linux Verification Center (linuxtesting.org) with SVACE. [kwilczynski: commit log]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47693", "url": "https://ubuntu.com/security/CVE-2024-47693", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/core: Fix ib_cache_setup_one error flow cleanup When ib_cache_update return an error, we exit ib_cache_setup_one instantly with no proper cleanup, even though before this we had already successfully done gid_table_setup_one, that results in the kernel WARN below. Do proper cleanup using gid_table_cleanup_one before returning the err in order to fix the issue. WARNING: CPU: 4 PID: 922 at drivers/infiniband/core/cache.c:806 gid_table_release_one+0x181/0x1a0 Modules linked in: CPU: 4 UID: 0 PID: 922 Comm: c_repro Not tainted 6.11.0-rc1+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:gid_table_release_one+0x181/0x1a0 Code: 44 8b 38 75 0c e8 2f cb 34 ff 4d 8b b5 28 05 00 00 e8 23 cb 34 ff 44 89 f9 89 da 4c 89 f6 48 c7 c7 d0 58 14 83 e8 4f de 21 ff <0f> 0b 4c 8b 75 30 e9 54 ff ff ff 48 8 3 c4 10 5b 5d 41 5c 41 5d 41 RSP: 0018:ffffc90002b835b0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c8527 RDX: 0000000000000000 RSI: ffffffff811c8534 RDI: 0000000000000001 RBP: ffff8881011b3d00 R08: ffff88810b3abe00 R09: 205d303839303631 R10: 666572207972746e R11: 72746e6520444947 R12: 0000000000000001 R13: ffff888106390000 R14: ffff8881011f2110 R15: 0000000000000001 FS: 00007fecc3b70800(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000340 CR3: 000000010435a001 CR4: 00000000003706b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? show_regs+0x94/0xa0 ? __warn+0x9e/0x1c0 ? gid_table_release_one+0x181/0x1a0 ? report_bug+0x1f9/0x340 ? gid_table_release_one+0x181/0x1a0 ? handle_bug+0xa2/0x110 ? exc_invalid_op+0x31/0xa0 ? asm_exc_invalid_op+0x16/0x20 ? __warn_printk+0xc7/0x180 ? __warn_printk+0xd4/0x180 ? gid_table_release_one+0x181/0x1a0 ib_device_release+0x71/0xe0 ? __pfx_ib_device_release+0x10/0x10 device_release+0x44/0xd0 kobject_put+0x135/0x3d0 put_device+0x20/0x30 rxe_net_add+0x7d/0xa0 rxe_newlink+0xd7/0x190 nldev_newlink+0x1b0/0x2a0 ? __pfx_nldev_newlink+0x10/0x10 rdma_nl_rcv_msg+0x1ad/0x2e0 rdma_nl_rcv_skb.constprop.0+0x176/0x210 netlink_unicast+0x2de/0x400 netlink_sendmsg+0x306/0x660 __sock_sendmsg+0x110/0x120 ____sys_sendmsg+0x30e/0x390 ___sys_sendmsg+0x9b/0xf0 ? kstrtouint+0x6e/0xa0 ? kstrtouint_from_user+0x7c/0xb0 ? get_pid_task+0xb0/0xd0 ? proc_fail_nth_write+0x5b/0x140 ? __fget_light+0x9a/0x200 ? preempt_count_add+0x47/0xa0 __sys_sendmsg+0x61/0xd0 do_syscall_64+0x50/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47694", "url": "https://ubuntu.com/security/CVE-2024-47694", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mlx5: Fix UMR pd cleanup on error flow of driver init The cited commit moves the pd allocation from function mlx5r_umr_resource_cleanup() to a new function mlx5r_umr_cleanup(). So the fix in commit [1] is broken. In error flow, will hit panic [2]. Fix it by checking pd pointer to avoid panic if it is NULL; [1] RDMA/mlx5: Fix UMR cleanup on error flow of driver init [2] [ 347.567063] infiniband mlx5_0: Couldn't register device with driver model [ 347.591382] BUG: kernel NULL pointer dereference, address: 0000000000000020 [ 347.593438] #PF: supervisor read access in kernel mode [ 347.595176] #PF: error_code(0x0000) - not-present page [ 347.596962] PGD 0 P4D 0 [ 347.601361] RIP: 0010:ib_dealloc_pd_user+0x12/0xc0 [ib_core] [ 347.604171] RSP: 0018:ffff888106293b10 EFLAGS: 00010282 [ 347.604834] RAX: 0000000000000000 RBX: 000000000000000e RCX: 0000000000000000 [ 347.605672] RDX: ffff888106293ad0 RSI: 0000000000000000 RDI: 0000000000000000 [ 347.606529] RBP: 0000000000000000 R08: ffff888106293ae0 R09: ffff888106293ae0 [ 347.607379] R10: 0000000000000a06 R11: 0000000000000000 R12: 0000000000000000 [ 347.608224] R13: ffffffffa0704dc0 R14: 0000000000000001 R15: 0000000000000001 [ 347.609067] FS: 00007fdc720cd9c0(0000) GS:ffff88852c880000(0000) knlGS:0000000000000000 [ 347.610094] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 347.610727] CR2: 0000000000000020 CR3: 0000000103012003 CR4: 0000000000370eb0 [ 347.611421] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 347.612113] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 347.612804] Call Trace: [ 347.613130] [ 347.613417] ? __die+0x20/0x60 [ 347.613793] ? page_fault_oops+0x150/0x3e0 [ 347.614243] ? free_msg+0x68/0x80 [mlx5_core] [ 347.614840] ? cmd_exec+0x48f/0x11d0 [mlx5_core] [ 347.615359] ? exc_page_fault+0x74/0x130 [ 347.615808] ? asm_exc_page_fault+0x22/0x30 [ 347.616273] ? ib_dealloc_pd_user+0x12/0xc0 [ib_core] [ 347.616801] mlx5r_umr_cleanup+0x23/0x90 [mlx5_ib] [ 347.617365] mlx5_ib_stage_pre_ib_reg_umr_cleanup+0x36/0x40 [mlx5_ib] [ 347.618025] __mlx5_ib_add+0x96/0xd0 [mlx5_ib] [ 347.618539] mlx5r_probe+0xe9/0x310 [mlx5_ib] [ 347.619032] ? kernfs_add_one+0x107/0x150 [ 347.619478] ? __mlx5_ib_add+0xd0/0xd0 [mlx5_ib] [ 347.619984] auxiliary_bus_probe+0x3e/0x90 [ 347.620448] really_probe+0xc5/0x3a0 [ 347.620857] __driver_probe_device+0x80/0x160 [ 347.621325] driver_probe_device+0x1e/0x90 [ 347.621770] __driver_attach+0xec/0x1c0 [ 347.622213] ? __device_attach_driver+0x100/0x100 [ 347.622724] bus_for_each_dev+0x71/0xc0 [ 347.623151] bus_add_driver+0xed/0x240 [ 347.623570] driver_register+0x58/0x100 [ 347.623998] __auxiliary_driver_register+0x6a/0xc0 [ 347.624499] ? driver_register+0xae/0x100 [ 347.624940] ? 0xffffffffa0893000 [ 347.625329] mlx5_ib_init+0x16a/0x1e0 [mlx5_ib] [ 347.625845] do_one_initcall+0x4a/0x2a0 [ 347.626273] ? gcov_event+0x2e2/0x3a0 [ 347.626706] do_init_module+0x8a/0x260 [ 347.627126] init_module_from_file+0x8b/0xd0 [ 347.627596] __x64_sys_finit_module+0x1ca/0x2f0 [ 347.628089] do_syscall_64+0x4c/0x100", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47695", "url": "https://ubuntu.com/security/CVE-2024-47695", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds In the function init_conns(), after the create_con() and create_cm() for loop if something fails. In the cleanup for loop after the destroy tag, we access out of bound memory because cid is set to clt_path->s.con_num. This commits resets the cid to clt_path->s.con_num - 1, to stay in bounds in the cleanup loop later.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47752", "url": "https://ubuntu.com/security/CVE-2024-47752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix H264 stateless decoder smatch warning Fix a smatch static checker warning on vdec_h264_req_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47753", "url": "https://ubuntu.com/security/CVE-2024-47753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix VP8 stateless decoder smatch warning Fix a smatch static checker warning on vdec_vp8_req_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47754", "url": "https://ubuntu.com/security/CVE-2024-47754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix H264 multi stateless decoder smatch warning Fix a smatch static checker warning on vdec_h264_req_multi_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47696", "url": "https://ubuntu.com/security/CVE-2024-47696", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency In the commit aee2424246f9 (\"RDMA/iwcm: Fix a use-after-free related to destroying CM IDs\"), the function flush_workqueue is invoked to flush the work queue iwcm_wq. But at that time, the work queue iwcm_wq was created via the function alloc_ordered_workqueue without the flag WQ_MEM_RECLAIM. Because the current process is trying to flush the whole iwcm_wq, if iwcm_wq doesn't have the flag WQ_MEM_RECLAIM, verify that the current process is not reclaiming memory or running on a workqueue which doesn't have the flag WQ_MEM_RECLAIM as that can break forward-progress guarantee leading to a deadlock. The call trace is as below: [ 125.350876][ T1430] Call Trace: [ 125.356281][ T1430] [ 125.361285][ T1430] ? __warn (kernel/panic.c:693) [ 125.367640][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.375689][ T1430] ? report_bug (lib/bug.c:180 lib/bug.c:219) [ 125.382505][ T1430] ? handle_bug (arch/x86/kernel/traps.c:239) [ 125.388987][ T1430] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) [ 125.395831][ T1430] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621) [ 125.403125][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.410984][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.418764][ T1430] __flush_workqueue (kernel/workqueue.c:3970) [ 125.426021][ T1430] ? __pfx___might_resched (kernel/sched/core.c:10151) [ 125.433431][ T1430] ? destroy_cm_id (drivers/infiniband/core/iwcm.c:375) iw_cm [ 125.441209][ T1430] ? __pfx___flush_workqueue (kernel/workqueue.c:3910) [ 125.473900][ T1430] ? _raw_spin_lock_irqsave (arch/x86/include/asm/atomic.h:107 include/linux/atomic/atomic-arch-fallback.h:2170 include/linux/atomic/atomic-instrumented.h:1302 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162) [ 125.473909][ T1430] ? __pfx__raw_spin_lock_irqsave (kernel/locking/spinlock.c:161) [ 125.482537][ T1430] _destroy_id (drivers/infiniband/core/cma.c:2044) rdma_cm [ 125.495072][ T1430] nvme_rdma_free_queue (drivers/nvme/host/rdma.c:656 drivers/nvme/host/rdma.c:650) nvme_rdma [ 125.505827][ T1430] nvme_rdma_reset_ctrl_work (drivers/nvme/host/rdma.c:2180) nvme_rdma [ 125.505831][ T1430] process_one_work (kernel/workqueue.c:3231) [ 125.515122][ T1430] worker_thread (kernel/workqueue.c:3306 kernel/workqueue.c:3393) [ 125.515127][ T1430] ? __pfx_worker_thread (kernel/workqueue.c:3339) [ 125.531837][ T1430] kthread (kernel/kthread.c:389) [ 125.539864][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.550628][ T1430] ret_from_fork (arch/x86/kernel/process.c:147) [ 125.558840][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.558844][ T1430] ret_from_fork_asm (arch/x86/entry/entry_64.S:257) [ 125.566487][ T1430] [ 125.566488][ T1430] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47755", "url": "https://ubuntu.com/security/CVE-2024-47755", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47756", "url": "https://ubuntu.com/security/CVE-2024-47756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: keystone: Fix if-statement expression in ks_pcie_quirk() This code accidentally uses && where || was intended. It potentially results in a NULL dereference. Thus, fix the if-statement expression to use the correct condition. [kwilczynski: commit log]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47697", "url": "https://ubuntu.com/security/CVE-2024-47697", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error Ensure index in rtl2830_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47698", "url": "https://ubuntu.com/security/CVE-2024-47698", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error Ensure index in rtl2832_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue. [hverkuil: added fixes tag, rtl2830_pid_filter -> rtl2832_pid_filter in logmsg]", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47728", "url": "https://ubuntu.com/security/CVE-2024-47728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error For all non-tracing helpers which formerly had ARG_PTR_TO_{LONG,INT} as input arguments, zero the value for the case of an error as otherwise it could leak memory. For tracing, it is not needed given CAP_PERFMON can already read all kernel memory anyway hence bpf_get_func_arg() and bpf_get_func_ret() is skipped in here. Also, the MTU helpers mtu_len pointer value is being written but also read. Technically, the MEM_UNINIT should not be there in order to always force init. Removing MEM_UNINIT needs more verifier rework though: MEM_UNINIT right now implies two things actually: i) write into memory, ii) memory does not have to be initialized. If we lift MEM_UNINIT, it then becomes: i) read into memory, ii) memory must be initialized. This means that for bpf_*_check_mtu() we're readding the issue we're trying to fix, that is, it would then be able to write back into things like .rodata BPF maps. Follow-up work will rework the MEM_UNINIT semantics such that the intent can be better expressed. For now just clear the *mtu_len on error path which can be lifted later again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49861", "url": "https://ubuntu.com/security/CVE-2024-49861", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix helper writes to read-only maps Lonial found an issue that despite user- and BPF-side frozen BPF map (like in case of .rodata), it was still possible to write into it from a BPF program side through specific helpers having ARG_PTR_TO_{LONG,INT} as arguments. In check_func_arg() when the argument is as mentioned, the meta->raw_mode is never set. Later, check_helper_mem_access(), under the case of PTR_TO_MAP_VALUE as register base type, it assumes BPF_READ for the subsequent call to check_map_access_type() and given the BPF map is read-only it succeeds. The helpers really need to be annotated as ARG_PTR_TO_{LONG,INT} | MEM_UNINIT when results are written into them as opposed to read out of them. The latter indicates that it's okay to pass a pointer to uninitialized memory as the memory is written to anyway. However, ARG_PTR_TO_{LONG,INT} is a special case of ARG_PTR_TO_FIXED_SIZE_MEM just with additional alignment requirement. So it is better to just get rid of the ARG_PTR_TO_{LONG,INT} special cases altogether and reuse the fixed size memory types. For this, add MEM_ALIGNED to additionally ensure alignment given these helpers write directly into the args via * = val. The .arg*_size has been initialized reflecting the actual sizeof(*). MEM_ALIGNED can only be used in combination with MEM_FIXED_SIZE annotated argument types, since in !MEM_FIXED_SIZE cases the verifier does not know the buffer size a priori and therefore cannot blindly write * = val.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47757", "url": "https://ubuntu.com/security/CVE-2024-47757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential oob read in nilfs_btree_check_delete() The function nilfs_btree_check_delete(), which checks whether degeneration to direct mapping occurs before deleting a b-tree entry, causes memory access outside the block buffer when retrieving the maximum key if the root node has no entries. This does not usually happen because b-tree mappings with 0 child nodes are never created by mkfs.nilfs2 or nilfs2 itself. However, it can happen if the b-tree root node read from a device is configured that way, so fix this potential issue by adding a check for that case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47699", "url": "https://ubuntu.com/security/CVE-2024-47699", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential null-ptr-deref in nilfs_btree_insert() Patch series \"nilfs2: fix potential issues with empty b-tree nodes\". This series addresses three potential issues with empty b-tree nodes that can occur with corrupted filesystem images, including one recently discovered by syzbot. This patch (of 3): If a b-tree is broken on the device, and the b-tree height is greater than 2 (the level of the root node is greater than 1) even if the number of child nodes of the b-tree root is 0, a NULL pointer dereference occurs in nilfs_btree_prepare_insert(), which is called from nilfs_btree_insert(). This is because, when the number of child nodes of the b-tree root is 0, nilfs_btree_do_lookup() does not set the block buffer head in any of path[x].bp_bh, leaving it as the initial value of NULL, but if the level of the b-tree root node is greater than 1, nilfs_btree_get_nonroot_node(), which accesses the buffer memory of path[x].bp_bh, is called. Fix this issue by adding a check to nilfs_btree_root_broken(), which performs sanity checks when reading the root node from the device, to detect this inconsistency. Thanks to Lizhi Xu for trying to solve the bug and clarifying the cause early on.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47700", "url": "https://ubuntu.com/security/CVE-2024-47700", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: check stripe size compatibility on remount as well We disable stripe size in __ext4_fill_super if it is not a multiple of the cluster ratio however this check is missed when trying to remount. This can leave us with cases where stripe < cluster_ratio after remount:set making EXT4_B2C(sbi->s_stripe) become 0 that can cause some unforeseen bugs like divide by 0. Fix that by adding the check in remount path as well.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47701", "url": "https://ubuntu.com/security/CVE-2024-47701", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid OOB when system.data xattr changes underneath the filesystem When looking up for an entry in an inlined directory, if e_value_offs is changed underneath the filesystem by some change in the block device, it will lead to an out-of-bounds access that KASAN detects as an UAF. EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none. loop0: detected capacity change from 2048 to 2047 ================================================================== BUG: KASAN: use-after-free in ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 Read of size 1 at addr ffff88803e91130f by task syz-executor269/5103 CPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 Not tainted 6.11.0-rc4-syzkaller #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:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 ext4_find_inline_entry+0x4be/0x5e0 fs/ext4/inline.c:1697 __ext4_find_entry+0x2b4/0x1b30 fs/ext4/namei.c:1573 ext4_lookup_entry fs/ext4/namei.c:1727 [inline] ext4_lookup+0x15f/0x750 fs/ext4/namei.c:1795 lookup_one_qstr_excl+0x11f/0x260 fs/namei.c:1633 filename_create+0x297/0x540 fs/namei.c:3980 do_symlinkat+0xf9/0x3a0 fs/namei.c:4587 __do_sys_symlinkat fs/namei.c:4610 [inline] __se_sys_symlinkat fs/namei.c:4607 [inline] __x64_sys_symlinkat+0x95/0xb0 fs/namei.c:4607 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:0x7f3e73ced469 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff4d40c258 EFLAGS: 00000246 ORIG_RAX: 000000000000010a RAX: ffffffffffffffda RBX: 0032656c69662f2e RCX: 00007f3e73ced469 RDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0 RBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290 R10: 0023706f6f6c2f76 R11: 0000000000000246 R12: 00007fff4d40c27c R13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0 Calling ext4_xattr_ibody_find right after reading the inode with ext4_get_inode_loc will lead to a check of the validity of the xattrs, avoiding this problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49850", "url": "https://ubuntu.com/security/CVE-2024-49850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: correctly handle malformed BPF_CORE_TYPE_ID_LOCAL relos In case of malformed relocation record of kind BPF_CORE_TYPE_ID_LOCAL referencing a non-existing BTF type, function bpf_core_calc_relo_insn would cause a null pointer deference. Fix this by adding a proper check upper in call stack, as malformed relocation records could be passed from user space. Simplest reproducer is a program: r0 = 0 exit With a single relocation record: .insn_off = 0, /* patch first instruction */ .type_id = 100500, /* this type id does not exist */ .access_str_off = 6, /* offset of string \"0\" */ .kind = BPF_CORE_TYPE_ID_LOCAL, See the link for original reproducer or next commit for a test case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47702", "url": "https://ubuntu.com/security/CVE-2024-47702", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fail verification for sign-extension of packet data/data_end/data_meta syzbot reported a kernel crash due to commit 1f1e864b6555 (\"bpf: Handle sign-extenstin ctx member accesses\"). The reason is due to sign-extension of 32-bit load for packet data/data_end/data_meta uapi field. The original code looks like: r2 = *(s32 *)(r1 + 76) /* load __sk_buff->data */ r3 = *(u32 *)(r1 + 80) /* load __sk_buff->data_end */ r0 = r2 r0 += 8 if r3 > r0 goto +1 ... Note that __sk_buff->data load has 32-bit sign extension. After verification and convert_ctx_accesses(), the final asm code looks like: r2 = *(u64 *)(r1 +208) r2 = (s32)r2 r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 ... Note that 'r2 = (s32)r2' may make the kernel __sk_buff->data address invalid which may cause runtime failure. Currently, in C code, typically we have void *data = (void *)(long)skb->data; void *data_end = (void *)(long)skb->data_end; ... and it will generate r2 = *(u64 *)(r1 +208) r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 If we allow sign-extension, void *data = (void *)(long)(int)skb->data; void *data_end = (void *)(long)skb->data_end; ... the generated code looks like r2 = *(u64 *)(r1 +208) r2 <<= 32 r2 s>>= 32 r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 and this will cause verification failure since \"r2 <<= 32\" is not allowed as \"r2\" is a packet pointer. To fix this issue for case r2 = *(s32 *)(r1 + 76) /* load __sk_buff->data */ this patch added additional checking in is_valid_access() callback function for packet data/data_end/data_meta access. If those accesses are with sign-extenstion, the verification will fail. [1] https://lore.kernel.org/bpf/000000000000c90eee061d236d37@google.com/", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47703", "url": "https://ubuntu.com/security/CVE-2024-47703", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, lsm: Add check for BPF LSM return value A bpf prog returning a positive number attached to file_alloc_security hook makes kernel panic. This happens because file system can not filter out the positive number returned by the LSM prog using IS_ERR, and misinterprets this positive number as a file pointer. Given that hook file_alloc_security never returned positive number before the introduction of BPF LSM, and other BPF LSM hooks may encounter similar issues, this patch adds LSM return value check in verifier, to ensure no unexpected value is returned.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49851", "url": "https://ubuntu.com/security/CVE-2024-49851", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: Clean up TPM space after command failure tpm_dev_transmit prepares the TPM space before attempting command transmission. However if the command fails no rollback of this preparation is done. This can result in transient handles being leaked if the device is subsequently closed with no further commands performed. Fix this by flushing the space in the event of command transmission failure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47723", "url": "https://ubuntu.com/security/CVE-2024-47723", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: fix out-of-bounds in dbNextAG() and diAlloc() In dbNextAG() , there is no check for the case where bmp->db_numag is greater or same than MAXAG due to a polluted image, which causes an out-of-bounds. Therefore, a bounds check should be added in dbMount(). And in dbNextAG(), a check for the case where agpref is greater than bmp->db_numag should be added, so an out-of-bounds exception should be prevented. Additionally, a check for the case where agno is greater or same than MAXAG should be added in diAlloc() to prevent out-of-bounds.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49852", "url": "https://ubuntu.com/security/CVE-2024-49852", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: elx: libefc: Fix potential use after free in efc_nport_vport_del() The kref_put() function will call nport->release if the refcount drops to zero. The nport->release release function is _efc_nport_free() which frees \"nport\". But then we dereference \"nport\" on the next line which is a use after free. Re-order these lines to avoid the use after free.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47720", "url": "https://ubuntu.com/security/CVE-2024-47720", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for set_output_gamma in dcn30_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn30_set_output_transfer_func function. Previously, set_output_gamma was being checked for nullity at line 386, but then it was being dereferenced without any nullity check at line 401. This could potentially lead to a null pointer dereference error if set_output_gamma is indeed null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a nullity check for set_output_gamma before the call to set_output_gamma at line 401. If set_output_gamma is null, we log an error message and do not call the function. This fix prevents a potential null pointer dereference error. drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:401 dcn30_set_output_transfer_func() error: we previously assumed 'mpc->funcs->set_output_gamma' could be null (see line 386) drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c 373 bool dcn30_set_output_transfer_func(struct dc *dc, 374 struct pipe_ctx *pipe_ctx, 375 const struct dc_stream_state *stream) 376 { 377 int mpcc_id = pipe_ctx->plane_res.hubp->inst; 378 struct mpc *mpc = pipe_ctx->stream_res.opp->ctx->dc->res_pool->mpc; 379 const struct pwl_params *params = NULL; 380 bool ret = false; 381 382 /* program OGAM or 3DLUT only for the top pipe*/ 383 if (pipe_ctx->top_pipe == NULL) { 384 /*program rmu shaper and 3dlut in MPC*/ 385 ret = dcn30_set_mpc_shaper_3dlut(pipe_ctx, stream); 386 if (ret == false && mpc->funcs->set_output_gamma) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If this is NULL 387 if (stream->out_transfer_func.type == TF_TYPE_HWPWL) 388 params = &stream->out_transfer_func.pwl; 389 else if (pipe_ctx->stream->out_transfer_func.type == 390 TF_TYPE_DISTRIBUTED_POINTS && 391 cm3_helper_translate_curve_to_hw_format( 392 &stream->out_transfer_func, 393 &mpc->blender_params, false)) 394 params = &mpc->blender_params; 395 /* there are no ROM LUTs in OUTGAM */ 396 if (stream->out_transfer_func.type == TF_TYPE_PREDEFINED) 397 BREAK_TO_DEBUGGER(); 398 } 399 } 400 --> 401 mpc->funcs->set_output_gamma(mpc, mpcc_id, params); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Then it will crash 402 return ret; 403 }", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47704", "url": "https://ubuntu.com/security/CVE-2024-47704", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check link_res->hpo_dp_link_enc before using it [WHAT & HOW] Functions dp_enable_link_phy and dp_disable_link_phy can pass link_res without initializing hpo_dp_link_enc and it is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49853", "url": "https://ubuntu.com/security/CVE-2024-49853", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix double free in OPTEE transport Channels can be shared between protocols, avoid freeing the same channel descriptors twice when unloading the stack.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47705", "url": "https://ubuntu.com/security/CVE-2024-47705", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix potential invalid pointer dereference in blk_add_partition The blk_add_partition() function initially used a single if-condition (IS_ERR(part)) to check for errors when adding a partition. This was modified to handle the specific case of -ENXIO separately, allowing the function to proceed without logging the error in this case. However, this change unintentionally left a path where md_autodetect_dev() could be called without confirming that part is a valid pointer. This commit separates the error handling logic by splitting the initial if-condition, improving code readability and handling specific error scenarios explicitly. The function now distinguishes the general error case from -ENXIO without altering the existing behavior of md_autodetect_dev() calls.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47736", "url": "https://ubuntu.com/security/CVE-2024-47736", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: handle overlapped pclusters out of crafted images properly syzbot reported a task hang issue due to a deadlock case where it is waiting for the folio lock of a cached folio that will be used for cache I/Os. After looking into the crafted fuzzed image, I found it's formed with several overlapped big pclusters as below: Ext: logical offset | length : physical offset | length 0: 0.. 16384 | 16384 : 151552.. 167936 | 16384 1: 16384.. 32768 | 16384 : 155648.. 172032 | 16384 2: 32768.. 49152 | 16384 : 537223168.. 537239552 | 16384 ... Here, extent 0/1 are physically overlapped although it's entirely _impossible_ for normal filesystem images generated by mkfs. First, managed folios containing compressed data will be marked as up-to-date and then unlocked immediately (unlike in-place folios) when compressed I/Os are complete. If physical blocks are not submitted in the incremental order, there should be separate BIOs to avoid dependency issues. However, the current code mis-arranges z_erofs_fill_bio_vec() and BIO submission which causes unexpected BIO waits. Second, managed folios will be connected to their own pclusters for efficient inter-queries. However, this is somewhat hard to implement easily if overlapped big pclusters exist. Again, these only appear in fuzzed images so let's simply fall back to temporary short-lived pages for correctness. Additionally, it justifies that referenced managed folios cannot be truncated for now and reverts part of commit 2080ca1ed3e4 (\"erofs: tidy up `struct z_erofs_bvec`\") for simplicity although it shouldn't be any difference.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47706", "url": "https://ubuntu.com/security/CVE-2024-47706", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block, bfq: fix possible UAF for bfqq->bic with merge chain 1) initial state, three tasks: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t\t | ? | ?\t\t | ? \t\t | | | |\t\t | | \t\t V | V |\t\t V | \t\t bfqq1 bfqq2\t\t bfqq3 process ref:\t 1\t\t 1\t\t 1 2) bfqq1 merged to bfqq2: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t\t | |\t\t | ? \t\t \\--------------\\|\t\t | | \t\t V\t\t V | \t\t bfqq1--------->bfqq2\t\t bfqq3 process ref:\t 0\t\t 2\t\t 1 3) bfqq2 merged to bfqq3: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t here -> ? |\t\t | \t\t \\--------------\\ \\-------------\\| \t\t V\t\t V \t\t bfqq1--------->bfqq2---------->bfqq3 process ref:\t 0\t\t 1\t\t 3 In this case, IO from Process 1 will get bfqq2 from BIC1 first, and then get bfqq3 through merge chain, and finially handle IO by bfqq3. Howerver, current code will think bfqq2 is owned by BIC1, like initial state, and set bfqq2->bic to BIC1. bfq_insert_request -> by Process 1 bfqq = bfq_init_rq(rq) bfqq = bfq_get_bfqq_handle_split bfqq = bic_to_bfqq -> get bfqq2 from BIC1 bfqq->ref++ rq->elv.priv[0] = bic rq->elv.priv[1] = bfqq if (bfqq_process_refs(bfqq) == 1) bfqq->bic = bic -> record BIC1 to bfqq2 __bfq_insert_request new_bfqq = bfq_setup_cooperator -> get bfqq3 from bfqq2->new_bfqq bfqq_request_freed(bfqq) new_bfqq->ref++ rq->elv.priv[1] = new_bfqq -> handle IO by bfqq3 Fix the problem by checking bfqq is from merge chain fist. And this might fix a following problem reported by our syzkaller(unreproducible): ================================================================== BUG: KASAN: slab-use-after-free in bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] BUG: KASAN: slab-use-after-free in bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] BUG: KASAN: slab-use-after-free in bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 Write of size 1 at addr ffff888123839eb8 by task kworker/0:1H/18595 CPU: 0 PID: 18595 Comm: kworker/0:1H Tainted: G L 6.6.0-07439-gba2303cacfda #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Workqueue: kblockd blk_mq_requeue_work Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [inline] print_report+0x10d/0x610 mm/kasan/report.c:475 kasan_report+0x8e/0xc0 mm/kasan/report.c:588 bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 bfq_get_bfqq_handle_split+0x169/0x5d0 block/bfq-iosched.c:6757 bfq_init_rq block/bfq-iosched.c:6876 [inline] bfq_insert_request block/bfq-iosched.c:6254 [inline] bfq_insert_requests+0x1112/0x5cf0 block/bfq-iosched.c:6304 blk_mq_insert_request+0x290/0x8d0 block/blk-mq.c:2593 blk_mq_requeue_work+0x6bc/0xa70 block/blk-mq.c:1502 process_one_work kernel/workqueue.c:2627 [inline] process_scheduled_works+0x432/0x13f0 kernel/workqueue.c:2700 worker_thread+0x6f2/0x1160 kernel/workqueue.c:2781 kthread+0x33c/0x440 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:305 Allocated by task 20776: kasan_save_stack+0x20/0x40 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 __kasan_slab_alloc+0x87/0x90 mm/kasan/common.c:328 kasan_slab_alloc include/linux/kasan.h:188 [inline] slab_post_alloc_hook mm/slab.h:763 [inline] slab_alloc_node mm/slub.c:3458 [inline] kmem_cache_alloc_node+0x1a4/0x6f0 mm/slub.c:3503 ioc_create_icq block/blk-ioc.c:370 [inline] ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49855", "url": "https://ubuntu.com/security/CVE-2024-49855", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: fix race between timeout and normal completion If request timetout is handled by nbd_requeue_cmd(), normal completion has to be stopped for avoiding to complete this requeued request, other use-after-free can be triggered. Fix the race by clearing NBD_CMD_INFLIGHT in nbd_requeue_cmd(), meantime make sure that cmd->lock is grabbed for clearing the flag and the requeue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47707", "url": "https://ubuntu.com/security/CVE-2024-47707", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev() Blamed commit accidentally removed a check for rt->rt6i_idev being NULL, as spotted by syzbot: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 UID: 0 PID: 10998 Comm: syz-executor Not tainted 6.11.0-rc6-syzkaller-00208-g625403177711 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 RBP: ffffc900047375d0 R08: 0000000000000003 R09: fffff520008e6e8c R10: dffffc0000000000 R11: fffff520008e6e8c R12: 1ffff1100fdf8f18 R13: ffff88807efc7998 R14: 0000000000000000 R15: ffff88807efc7930 FS: 0000000000000000(0000) GS:ffff8880b8900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020002a80 CR3: 0000000022f62000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: addrconf_ifdown+0x15d/0x1bd0 net/ipv6/addrconf.c:3856 addrconf_notify+0x3cb/0x1020 notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93 call_netdevice_notifiers_extack net/core/dev.c:2032 [inline] call_netdevice_notifiers net/core/dev.c:2046 [inline] unregister_netdevice_many_notify+0xd81/0x1c40 net/core/dev.c:11352 unregister_netdevice_many net/core/dev.c:11414 [inline] unregister_netdevice_queue+0x303/0x370 net/core/dev.c:11289 unregister_netdevice include/linux/netdevice.h:3129 [inline] __tun_detach+0x6b9/0x1600 drivers/net/tun.c:685 tun_detach drivers/net/tun.c:701 [inline] tun_chr_close+0x108/0x1b0 drivers/net/tun.c:3510 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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:0x7f1acc77def9 Code: Unable to access opcode bytes at 0x7f1acc77decf. RSP: 002b:00007ffeb26fa738 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1acc77def9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000043 RBP: 00007f1acc7dd508 R08: 00007ffeb26f84d7 R09: 0000000000000003 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 0000000000000003 R14: 00000000ffffffff R15: 00007ffeb26fa8e0 Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 R ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47708", "url": "https://ubuntu.com/security/CVE-2024-47708", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netkit: Assign missing bpf_net_context During the introduction of struct bpf_net_context handling for XDP-redirect, the netkit driver has been missed, which also requires it because NETKIT_REDIRECT invokes skb_do_redirect() which is accessing the per-CPU variables. Otherwise we see the following crash: \tBUG: kernel NULL pointer dereference, address: 0000000000000038 \tbpf_redirect() \tnetkit_xmit() \tdev_hard_start_xmit() Set the bpf_net_context before invoking netkit_xmit() program within the netkit driver.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47709", "url": "https://ubuntu.com/security/CVE-2024-47709", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: Clear bo->bcm_proc_read after remove_proc_entry(). syzbot reported a warning in bcm_release(). [0] The blamed change fixed another warning that is triggered when connect() is issued again for a socket whose connect()ed device has been unregistered. However, if the socket is just close()d without the 2nd connect(), the remaining bo->bcm_proc_read triggers unnecessary remove_proc_entry() in bcm_release(). Let's clear bo->bcm_proc_read after remove_proc_entry() in bcm_notify(). [0] name '4986' WARNING: CPU: 0 PID: 5234 at fs/proc/generic.c:711 remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Modules linked in: CPU: 0 UID: 0 PID: 5234 Comm: syz-executor606 Not tainted 6.11.0-rc5-syzkaller-00178-g5517ae241919 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Code: ff eb 05 e8 cb 1e 5e ff 48 8b 5c 24 10 48 c7 c7 e0 f7 aa 8e e8 2a 38 8e 09 90 48 c7 c7 60 3a 1b 8c 48 89 de e8 da 42 20 ff 90 <0f> 0b 90 90 48 8b 44 24 18 48 c7 44 24 40 0e 36 e0 45 49 c7 04 07 RSP: 0018:ffffc9000345fa20 EFLAGS: 00010246 RAX: 2a2d0aee2eb64600 RBX: ffff888032f1f548 RCX: ffff888029431e00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000345fb08 R08: ffffffff8155b2f2 R09: 1ffff1101710519a R10: dffffc0000000000 R11: ffffed101710519b R12: ffff888011d38640 R13: 0000000000000004 R14: 0000000000000000 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8880b8800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcfb52722f0 CR3: 000000000e734000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: bcm_release+0x250/0x880 net/can/bcm.c:1578 __sock_release net/socket.c:659 [inline] sock_close+0xbc/0x240 net/socket.c:1421 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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:0x7fcfb51ee969 Code: Unable to access opcode bytes at 0x7fcfb51ee93f. RSP: 002b:00007ffce0109ca8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fcfb51ee969 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 00007fcfb526f3b0 R08: ffffffffffffffb8 R09: 0000555500000000 R10: 0000555500000000 R11: 0000000000000246 R12: 00007fcfb526f3b0 R13: 0000000000000000 R14: 00007fcfb5271ee0 R15: 00007fcfb51bf160 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47710", "url": "https://ubuntu.com/security/CVE-2024-47710", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sock_map: Add a cond_resched() in sock_hash_free() Several syzbot soft lockup reports all have in common sock_hash_free() If a map with a large number of buckets is destroyed, we need to yield the cpu when needed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47711", "url": "https://ubuntu.com/security/CVE-2024-47711", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Don't return OOB skb in manage_oob(). syzbot reported use-after-free in unix_stream_recv_urg(). [0] The scenario is 1. send(MSG_OOB) 2. recv(MSG_OOB) -> The consumed OOB remains in recv queue 3. send(MSG_OOB) 4. recv() -> manage_oob() returns the next skb of the consumed OOB -> This is also OOB, but unix_sk(sk)->oob_skb is not cleared 5. recv(MSG_OOB) -> unix_sk(sk)->oob_skb is used but already freed The recent commit 8594d9b85c07 (\"af_unix: Don't call skb_get() for OOB skb.\") uncovered the issue. If the OOB skb is consumed and the next skb is peeked in manage_oob(), we still need to check if the skb is OOB. Let's do so by falling back to the following checks in manage_oob() and add the test case in selftest. Note that we need to add a similar check for SIOCATMARK. [0]: BUG: KASAN: slab-use-after-free in unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959 Read of size 4 at addr ffff8880326abcc4 by task syz-executor178/5235 CPU: 0 UID: 0 PID: 5235 Comm: syz-executor178 Not tainted 6.11.0-rc5-syzkaller-00742-gfbdaffe41adc #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959 unix_stream_recv_urg+0x1df/0x320 net/unix/af_unix.c:2640 unix_stream_read_generic+0x2456/0x2520 net/unix/af_unix.c:2778 unix_stream_recvmsg+0x22b/0x2c0 net/unix/af_unix.c:2996 sock_recvmsg_nosec net/socket.c:1046 [inline] sock_recvmsg+0x22f/0x280 net/socket.c:1068 ____sys_recvmsg+0x1db/0x470 net/socket.c:2816 ___sys_recvmsg net/socket.c:2858 [inline] __sys_recvmsg+0x2f0/0x3e0 net/socket.c:2888 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:0x7f5360d6b4e9 Code: 48 83 c4 28 c3 e8 37 17 00 00 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff29b3a458 EFLAGS: 00000246 ORIG_RAX: 000000000000002f RAX: ffffffffffffffda RBX: 00007fff29b3a638 RCX: 00007f5360d6b4e9 RDX: 0000000000002001 RSI: 0000000020000640 RDI: 0000000000000003 RBP: 00007f5360dde610 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 00007fff29b3a628 R14: 0000000000000001 R15: 0000000000000001 Allocated by task 5235: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:312 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slub.c:3988 [inline] slab_alloc_node mm/slub.c:4037 [inline] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4080 __alloc_skb+0x1c3/0x440 net/core/skbuff.c:667 alloc_skb include/linux/skbuff.h:1320 [inline] alloc_skb_with_frags+0xc3/0x770 net/core/skbuff.c:6528 sock_alloc_send_pskb+0x91a/0xa60 net/core/sock.c:2815 sock_alloc_send_skb include/net/sock.h:1778 [inline] queue_oob+0x108/0x680 net/unix/af_unix.c:2198 unix_stream_sendmsg+0xd24/0xf80 net/unix/af_unix.c:2351 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2680 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 Freed by task 5235: kasan_save_stack mm/kasan/common.c:47 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47712", "url": "https://ubuntu.com/security/CVE-2024-47712", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: fix potential RCU dereference issue in wilc_parse_join_bss_param In the `wilc_parse_join_bss_param` function, the TSF field of the `ies` structure is accessed after the RCU read-side critical section is unlocked. According to RCU usage rules, this is illegal. Reusing this pointer can lead to unpredictable behavior, including accessing memory that has been updated or causing use-after-free issues. This possible bug was identified using a static analysis tool developed by myself, specifically designed to detect RCU-related issues. To address this, the TSF value is now stored in a local variable `ies_tsf` before the RCU lock is released. The `param->tsf_lo` field is then assigned using this local variable, ensuring that the TSF value is safely accessed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47713", "url": "https://ubuntu.com/security/CVE-2024-47713", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop() Since '__dev_queue_xmit()' should be called with interrupts enabled, the following backtrace: ieee80211_do_stop() ... spin_lock_irqsave(&local->queue_stop_reason_lock, flags) ... ieee80211_free_txskb() ieee80211_report_used_skb() ieee80211_report_ack_skb() cfg80211_mgmt_tx_status_ext() nl80211_frame_tx_status() genlmsg_multicast_netns() genlmsg_multicast_netns_filtered() nlmsg_multicast_filtered() \t netlink_broadcast_filtered() \t do_one_broadcast() \t netlink_broadcast_deliver() \t __netlink_sendskb() \t netlink_deliver_tap() \t __netlink_deliver_tap_skb() \t dev_queue_xmit() \t __dev_queue_xmit() ; with IRQS disabled ... spin_unlock_irqrestore(&local->queue_stop_reason_lock, flags) issues the warning (as reported by syzbot reproducer): WARNING: CPU: 2 PID: 5128 at kernel/softirq.c:362 __local_bh_enable_ip+0xc3/0x120 Fix this by implementing a two-phase skb reclamation in 'ieee80211_do_stop()', where actual work is performed outside of a section with interrupts disabled.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47730", "url": "https://ubuntu.com/security/CVE-2024-47730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/qm - inject error before stopping queue The master ooo cannot be completely closed when the accelerator core reports memory error. Therefore, the driver needs to inject the qm error to close the master ooo. Currently, the qm error is injected after stopping queue, memory may be released immediately after stopping queue, causing the device to access the released memory. Therefore, error is injected to close master ooo before stopping queue to ensure that the device does not access the released memory.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49856", "url": "https://ubuntu.com/security/CVE-2024-49856", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/sgx: Fix deadlock in SGX NUMA node search When the current node doesn't have an EPC section configured by firmware and all other EPC sections are used up, CPU can get stuck inside the while loop that looks for an available EPC page from remote nodes indefinitely, leading to a soft lockup. Note how nid_of_current will never be equal to nid in that while loop because nid_of_current is not set in sgx_numa_mask. Also worth mentioning is that it's perfectly fine for the firmware not to setup an EPC section on a node. While setting up an EPC section on each node can enhance performance, it is not a requirement for functionality. Rework the loop to start and end on *a* node that has SGX memory. This avoids the deadlock looking for the current SGX-lacking node to show up in the loop when it never will.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47714", "url": "https://ubuntu.com/security/CVE-2024-47714", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: use hweight16 to get correct tx antenna The chainmask is u16 so using hweight8 cannot get correct tx_ant. Without this patch, the tx_ant of band 2 would be -1 and lead to the following issue: BUG: KASAN: stack-out-of-bounds in mt7996_mcu_add_sta+0x12e0/0x16e0 [mt7996e]", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47715", "url": "https://ubuntu.com/security/CVE-2024-47715", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: fix oops on non-dbdc mt7986 mt7915_band_config() sets band_idx = 1 on the main phy for mt7986 with MT7975_ONE_ADIE or MT7976_ONE_ADIE. Commit 0335c034e726 (\"wifi: mt76: fix race condition related to checking tx queue fill status\") introduced a dereference of the phys array indirectly indexed by band_idx via wcid->phy_idx in mt76_wcid_cleanup(). This caused the following Oops on affected mt7986 devices: Unable to handle kernel read from unreadable memory at virtual address 0000000000000024 Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x00000005 CM = 0, WnR = 0 user pgtable: 4k pages, 39-bit VAs, pgdp=0000000042545000 [0000000000000024] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 Internal error: Oops: 0000000096000005 [#1] SMP Modules linked in: ... mt7915e mt76_connac_lib mt76 mac80211 cfg80211 ... CPU: 2 PID: 1631 Comm: hostapd Not tainted 5.15.150 #0 Hardware name: ZyXEL EX5700 (Telenor) (DT) pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mt76_wcid_cleanup+0x84/0x22c [mt76] lr : mt76_wcid_cleanup+0x64/0x22c [mt76] sp : ffffffc00a803700 x29: ffffffc00a803700 x28: ffffff80008f7300 x27: ffffff80003f3c00 x26: ffffff80000a7880 x25: ffffffc008c26e00 x24: 0000000000000001 x23: ffffffc000a68114 x22: 0000000000000000 x21: ffffff8004172cc8 x20: ffffffc00a803748 x19: ffffff8004152020 x18: 0000000000000000 x17: 00000000000017c0 x16: ffffffc008ef5000 x15: 0000000000000be0 x14: ffffff8004172e28 x13: ffffff8004172e28 x12: 0000000000000000 x11: 0000000000000000 x10: ffffff8004172e30 x9 : ffffff8004172e28 x8 : 0000000000000000 x7 : ffffff8004156020 x6 : 0000000000000000 x5 : 0000000000000031 x4 : 0000000000000000 x3 : 0000000000000001 x2 : 0000000000000000 x1 : ffffff80008f7300 x0 : 0000000000000024 Call trace: mt76_wcid_cleanup+0x84/0x22c [mt76] __mt76_sta_remove+0x70/0xbc [mt76] mt76_sta_state+0x8c/0x1a4 [mt76] mt7915_eeprom_get_power_delta+0x11e4/0x23a0 [mt7915e] drv_sta_state+0x144/0x274 [mac80211] sta_info_move_state+0x1cc/0x2a4 [mac80211] sta_set_sinfo+0xaf8/0xc24 [mac80211] sta_info_destroy_addr_bss+0x4c/0x6c [mac80211] ieee80211_color_change_finish+0x1c08/0x1e70 [mac80211] cfg80211_check_station_change+0x1360/0x4710 [cfg80211] genl_family_rcv_msg_doit+0xb4/0x110 genl_rcv_msg+0xd0/0x1bc netlink_rcv_skb+0x58/0x120 genl_rcv+0x34/0x50 netlink_unicast+0x1f0/0x2ec netlink_sendmsg+0x198/0x3d0 ____sys_sendmsg+0x1b0/0x210 ___sys_sendmsg+0x80/0xf0 __sys_sendmsg+0x44/0xa0 __arm64_sys_sendmsg+0x20/0x30 invoke_syscall.constprop.0+0x4c/0xe0 do_el0_svc+0x40/0xd0 el0_svc+0x14/0x4c el0t_64_sync_handler+0x100/0x110 el0t_64_sync+0x15c/0x160 Code: d2800002 910092c0 52800023 f9800011 (885f7c01) ---[ end trace 7e42dd9a39ed2281 ]--- Fix by using mt76_dev_phy() which will map band_idx to the correct phy for all hardware combinations.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49857", "url": "https://ubuntu.com/security/CVE-2024-49857", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: set the cipher for secured NDP ranging The cipher pointer is not set, but is derefereced trying to set its content, which leads to a NULL pointer dereference. Fix it by pointing to the cipher parameter before dereferencing.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47738", "url": "https://ubuntu.com/security/CVE-2024-47738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: don't use rate mask for offchannel TX either Like the commit ab9177d83c04 (\"wifi: mac80211: don't use rate mask for scanning\"), ignore incorrect settings to avoid no supported rate warning reported by syzbot. The syzbot did bisect and found cause is commit 9df66d5b9f45 (\"cfg80211: fix default HE tx bitrate mask in 2G band\"), which however corrects bitmask of HE MCS and recognizes correctly settings of empty legacy rate plus HE MCS rate instead of returning -EINVAL. As suggestions [1], follow the change of SCAN TX to consider this case of offchannel TX as well. [1] https://lore.kernel.org/linux-wireless/6ab2dc9c3afe753ca6fdcdd1421e7a1f47e87b84.camel@sipsolutions.net/T/#m2ac2a6d2be06a37c9c47a3d8a44b4f647ed4f024", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47731", "url": "https://ubuntu.com/security/CVE-2024-47731", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers/perf: Fix ali_drw_pmu driver interrupt status clearing The alibaba_uncore_pmu driver forgot to clear all interrupt status in the interrupt processing function. After the PMU counter overflow interrupt occurred, an interrupt storm occurred, causing the system to hang. Therefore, clear the correct interrupt status in the interrupt handling function to fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49862", "url": "https://ubuntu.com/security/CVE-2024-49862", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powercap: intel_rapl: Fix off by one in get_rpi() The rp->priv->rpi array is either rpi_msr or rpi_tpmi which have NR_RAPL_PRIMITIVES number of elements. Thus the > needs to be >= to prevent an off by one access.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47716", "url": "https://ubuntu.com/security/CVE-2024-47716", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: 9410/1: vfp: Use asm volatile in fmrx/fmxr macros Floating point instructions in userspace can crash some arm kernels built with clang/LLD 17.0.6: BUG: unsupported FP instruction in kernel mode FPEXC == 0xc0000780 Internal error: Oops - undefined instruction: 0 [#1] ARM CPU: 0 PID: 196 Comm: vfp-reproducer Not tainted 6.10.0 #1 Hardware name: BCM2835 PC is at vfp_support_entry+0xc8/0x2cc LR is at do_undefinstr+0xa8/0x250 pc : [] lr : [] psr: a0000013 sp : dc8d1f68 ip : 60000013 fp : bedea19c r10: ec532b17 r9 : 00000010 r8 : 0044766c r7 : c0000780 r6 : ec532b17 r5 : c1c13800 r4 : dc8d1fb0 r3 : c10072c4 r2 : c0101c88 r1 : ec532b17 r0 : 0044766c Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 00c5387d Table: 0251c008 DAC: 00000051 Register r0 information: non-paged memory Register r1 information: vmalloc memory Register r2 information: non-slab/vmalloc memory Register r3 information: non-slab/vmalloc memory Register r4 information: 2-page vmalloc region Register r5 information: slab kmalloc-cg-2k Register r6 information: vmalloc memory Register r7 information: non-slab/vmalloc memory Register r8 information: non-paged memory Register r9 information: zero-size pointer Register r10 information: vmalloc memory Register r11 information: non-paged memory Register r12 information: non-paged memory Process vfp-reproducer (pid: 196, stack limit = 0x61aaaf8b) Stack: (0xdc8d1f68 to 0xdc8d2000) 1f60: 0000081f b6f69300 0000000f c10073f4 c10072c4 dc8d1fb0 1f80: ec532b17 0c532b17 0044766c b6f9ccd8 00000000 c010a80c 00447670 60000010 1fa0: ffffffff c1c13800 00c5387d c0100f10 b6f68af8 00448fc0 00000000 bedea188 1fc0: bedea314 00000001 00448ebc b6f9d000 00447608 b6f9ccd8 00000000 bedea19c 1fe0: bede9198 bedea188 b6e1061c 0044766c 60000010 ffffffff 00000000 00000000 Call trace: [] (vfp_support_entry) from [] (do_undefinstr+0xa8/0x250) [] (do_undefinstr) from [] (__und_usr+0x70/0x80) Exception stack(0xdc8d1fb0 to 0xdc8d1ff8) 1fa0: b6f68af8 00448fc0 00000000 bedea188 1fc0: bedea314 00000001 00448ebc b6f9d000 00447608 b6f9ccd8 00000000 bedea19c 1fe0: bede9198 bedea188 b6e1061c 0044766c 60000010 ffffffff Code: 0a000061 e3877202 e594003c e3a09010 (eef16a10) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Fatal exception in interrupt ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]--- This is a minimal userspace reproducer on a Raspberry Pi Zero W: #include #include int main(void) { double v = 1.0; printf(\"%fn\", NAN + *(volatile double *)&v); return 0; } Another way to consistently trigger the oops is: calvin@raspberry-pi-zero-w ~$ python -c \"import json\" The bug reproduces only when the kernel is built with DYNAMIC_DEBUG=n, because the pr_debug() calls act as barriers even when not activated. This is the output from the same kernel source built with the same compiler and DYNAMIC_DEBUG=y, where the userspace reproducer works as expected: VFP: bounce: trigger ec532b17 fpexc c0000780 VFP: emulate: INST=0xee377b06 SCR=0x00000000 VFP: bounce: trigger eef1fa10 fpexc c0000780 VFP: emulate: INST=0xeeb40b40 SCR=0x00000000 VFP: raising exceptions 30000000 calvin@raspberry-pi-zero-w ~$ ./vfp-reproducer nan Crudely grepping for vmsr/vmrs instructions in the otherwise nearly idential text for vfp_support_entry() makes the problem obvious: vmlinux.llvm.good [0xc0101cb8] <+48>: vmrs r7, fpexc vmlinux.llvm.good [0xc0101cd8] <+80>: vmsr fpexc, r0 vmlinux.llvm.good [0xc0101d20 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47717", "url": "https://ubuntu.com/security/CVE-2024-47717", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RISC-V: KVM: Don't zero-out PMU snapshot area before freeing data With the latest Linux-6.11-rc3, the below NULL pointer crash is observed when SBI PMU snapshot is enabled for the guest and the guest is forcefully powered-off. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000508 Oops [#1] Modules linked in: kvm CPU: 0 UID: 0 PID: 61 Comm: term-poll Not tainted 6.11.0-rc3-00018-g44d7178dd77a #3 Hardware name: riscv-virtio,qemu (DT) epc : __kvm_write_guest_page+0x94/0xa6 [kvm] ra : __kvm_write_guest_page+0x54/0xa6 [kvm] epc : ffffffff01590e98 ra : ffffffff01590e58 sp : ffff8f80001f39b0 gp : ffffffff81512a60 tp : ffffaf80024872c0 t0 : ffffaf800247e000 t1 : 00000000000007e0 t2 : 0000000000000000 s0 : ffff8f80001f39f0 s1 : 00007fff89ac4000 a0 : ffffffff015dd7e8 a1 : 0000000000000086 a2 : 0000000000000000 a3 : ffffaf8000000000 a4 : ffffaf80024882c0 a5 : 0000000000000000 a6 : ffffaf800328d780 a7 : 00000000000001cc s2 : ffffaf800197bd00 s3 : 00000000000828c4 s4 : ffffaf800248c000 s5 : ffffaf800247d000 s6 : 0000000000001000 s7 : 0000000000001000 s8 : 0000000000000000 s9 : 00007fff861fd500 s10: 0000000000000001 s11: 0000000000800000 t3 : 00000000000004d3 t4 : 00000000000004d3 t5 : ffffffff814126e0 t6 : ffffffff81412700 status: 0000000200000120 badaddr: 0000000000000508 cause: 000000000000000d [] __kvm_write_guest_page+0x94/0xa6 [kvm] [] kvm_vcpu_write_guest+0x56/0x90 [kvm] [] kvm_pmu_clear_snapshot_area+0x42/0x7e [kvm] [] kvm_riscv_vcpu_pmu_deinit.part.0+0xe0/0x14e [kvm] [] kvm_riscv_vcpu_pmu_deinit+0x1a/0x24 [kvm] [] kvm_arch_vcpu_destroy+0x28/0x4c [kvm] [] kvm_destroy_vcpus+0x5a/0xda [kvm] [] kvm_arch_destroy_vm+0x14/0x28 [kvm] [] kvm_destroy_vm+0x168/0x2a0 [kvm] [] kvm_put_kvm+0x3c/0x58 [kvm] [] kvm_vm_release+0x22/0x2e [kvm] Clearly, the kvm_vcpu_write_guest() function is crashing because it is being called from kvm_pmu_clear_snapshot_area() upon guest tear down. To address the above issue, simplify the kvm_pmu_clear_snapshot_area() to not zero-out PMU snapshot area from kvm_pmu_clear_snapshot_area() because the guest is anyway being tore down. The kvm_pmu_clear_snapshot_area() is also called when guest changes PMU snapshot area of a VCPU but even in this case the previous PMU snaphsot area must not be zeroed-out because the guest might have reclaimed the pervious PMU snapshot area for some other purpose.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47721", "url": "https://ubuntu.com/security/CVE-2024-47721", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: remove unused C2H event ID RTW89_MAC_C2H_FUNC_READ_WOW_CAM to prevent out-of-bounds reading The handler of firmware C2H event RTW89_MAC_C2H_FUNC_READ_WOW_CAM isn't implemented, but driver expects number of handlers is NUM_OF_RTW89_MAC_C2H_FUNC_WOW causing out-of-bounds access. Fix it by removing ID. Addresses-Coverity-ID: 1598775 (\"Out-of-bounds read\")", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47732", "url": "https://ubuntu.com/security/CVE-2024-47732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: iaa - Fix potential use after free bug The free_device_compression_mode(iaa_device, device_mode) function frees \"device_mode\" but it iss passed to iaa_compression_modes[i]->free() a few lines later resulting in a use after free. The good news is that, so far as I can tell, nothing implements the ->free() function and the use after free happens in dead code. But, with this fix, when something does implement it, we'll be ready. :)", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47718", "url": "https://ubuntu.com/security/CVE-2024-47718", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: always wait for both firmware loading attempts In 'rtw_wait_firmware_completion()', always wait for both (regular and wowlan) firmware loading attempts. Otherwise if 'rtw_usb_intf_init()' has failed in 'rtw_usb_probe()', 'rtw_usb_disconnect()' may issue 'ieee80211_free_hw()' when one of 'rtw_load_firmware_cb()' (usually the wowlan one) is still in progress, causing UAF detected by KASAN.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47724", "url": "https://ubuntu.com/security/CVE-2024-47724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: use work queue to process beacon tx event Commit 3a415daa3e8b (\"wifi: ath11k: add P2P IE in beacon template\") from Feb 28, 2024 (linux-next), leads to the following Smatch static checker warning: drivers/net/wireless/ath/ath11k/wmi.c:1742 ath11k_wmi_p2p_go_bcn_ie() warn: sleeping in atomic context The reason is that ath11k_bcn_tx_status_event() will directly call might sleep function ath11k_wmi_cmd_send() during RCU read-side critical sections. The call trace is like: ath11k_bcn_tx_status_event() -> rcu_read_lock() -> ath11k_mac_bcn_tx_event() \t-> ath11k_mac_setup_bcn_tmpl() \t…… \t\t-> ath11k_wmi_bcn_tmpl() \t\t\t-> ath11k_wmi_cmd_send() -> rcu_read_unlock() Commit 886433a98425 (\"ath11k: add support for BSS color change\") added the ath11k_mac_bcn_tx_event(), commit 01e782c89108 (\"ath11k: fix warning of RCU usage for ath11k_mac_get_arvif_by_vdev_id()\") added the RCU lock to avoid warning but also introduced this BUG. Use work queue to avoid directly calling ath11k_mac_bcn_tx_event() during RCU critical sections. No need to worry about the deletion of vif because cancel_work_sync() will drop the work if it doesn't start or block vif deletion until the running work is done. 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": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47671", "url": "https://ubuntu.com/security/CVE-2024-47671", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: usbtmc: prevent kernel-usb-infoleak The syzbot reported a kernel-usb-infoleak in usbtmc_write, we need to clear the structure before filling fields.", "cve_priority": "medium", "cve_public_date": "2024-10-09 15:15:00 UTC" }, { "cve": "CVE-2024-46869", "url": "https://ubuntu.com/security/CVE-2024-46869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btintel_pcie: Allocate memory for driver private data Fix driver not allocating memory for struct btintel_data which is used to store internal data.", "cve_priority": "medium", "cve_public_date": "2024-09-30 16:15:00 UTC" }, { "cve": "CVE-2024-53164", "url": "https://ubuntu.com/security/CVE-2024-53164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: fix ordering of qlen adjustment Changes to sch->q.qlen around qdisc_tree_reduce_backlog() need to happen _before_ a call to said function because otherwise it may fail to notify parent qdiscs when the child is about to become empty.", "cve_priority": "medium", "cve_public_date": "2024-12-27 14:15:00 UTC" }, { "cve": "CVE-2024-53103", "url": "https://ubuntu.com/security/CVE-2024-53103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hv_sock: Initializing vsk->trans to NULL to prevent a dangling pointer When hvs is released, there is a possibility that vsk->trans may not be initialized to NULL, which could lead to a dangling pointer. This issue is resolved by initializing vsk->trans to NULL.", "cve_priority": "high", "cve_public_date": "2024-12-02 08:15:00 UTC" } ], "launchpad_bugs_fixed": [ 2093643, 1786013, 2091744, 2091184, 2093146, 2085406, 2089684, 2090932, 2085485, 2089357, 2089306, 2091655, 2091655, 2091655, 2091655, 2091655, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091386, 2091990, 2089327, 2089113, 2086587, 2086606, 2085950, 2085944, 2087853, 2087983, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089020, 2089020, 2089020 ], "changes": [ { "cves": [ { "cve": "CVE-2025-0927", "url": "https://ubuntu.com/security/CVE-2025-0927", "cve_description": "[fs: hfs/hfsplus: add key_len boundary check to hfs_bnode_read_key]", "cve_priority": "medium", "cve_public_date": "2025-02-13" } ], "log": [ "", " * CVE-2025-0927", " - SAUCE: fs: hfs/hfsplus: add key_len boundary check to hfs_bnode_read_key", "" ], "package": "linux", "version": "6.11.0-18.18", "urgency": "medium", "distributions": "oracular", "launchpad_bugs_fixed": [], "author": "Manuel Diewald ", "date": "Fri, 07 Feb 2025 18:44:32 +0100" }, { "cves": [ { "cve": "CVE-2024-53141", "url": "https://ubuntu.com/security/CVE-2024-53141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: add missing range check in bitmap_ip_uadt When tb[IPSET_ATTR_IP_TO] is not present but tb[IPSET_ATTR_CIDR] exists, the values of ip and ip_to are slightly swapped. Therefore, the range check for ip should be done later, but this part is missing and it seems that the vulnerability occurs. So we should add missing range checks and remove unnecessary range checks.", "cve_priority": "medium", "cve_public_date": "2024-12-06 10:15:00 UTC" }, { "cve": "CVE-2024-50010", "url": "https://ubuntu.com/security/CVE-2024-50010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exec: don't WARN for racy path_noexec check Both i_mode and noexec checks wrapped in WARN_ON stem from an artifact of the previous implementation. They used to legitimately check for the condition, but that got moved up in two commits: 633fb6ac3980 (\"exec: move S_ISREG() check earlier\") 0fd338b2d2cd (\"exec: move path_noexec() check earlier\") Instead of being removed said checks are WARN_ON'ed instead, which has some debug value. However, the spurious path_noexec check is racy, resulting in unwarranted warnings should someone race with setting the noexec flag. One can note there is more to perm-checking whether execve is allowed and none of the conditions are guaranteed to still hold after they were tested for. Additionally this does not validate whether the code path did any perm checking to begin with -- it will pass if the inode happens to be regular. Keep the redundant path_noexec() check even though it's mindless nonsense checking for guarantee that isn't given so drop the WARN. Reword the commentary and do small tidy ups while here. [brauner: keep redundant path_noexec() check]", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-53143", "url": "https://ubuntu.com/security/CVE-2024-53143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fsnotify: Fix ordering of iput() and watched_objects decrement Ensure the superblock is kept alive until we're done with iput(). Holding a reference to an inode is not allowed unless we ensure the superblock stays alive, which fsnotify does by keeping the watched_objects count elevated, so iput() must happen before the watched_objects decrement. This can lead to a UAF of something like sb->s_fs_info in tmpfs, but the UAF is hard to hit because race orderings that oops are more likely, thanks to the CHECK_DATA_CORRUPTION() block in generic_shutdown_super(). Also, ensure that fsnotify_put_sb_watched_objects() doesn't call fsnotify_sb_watched_objects() on a superblock that may have already been freed, which would cause a UAF read of sb->s_fsnotify_info.", "cve_priority": "medium", "cve_public_date": "2024-12-07 07:15:00 UTC" }, { "cve": "CVE-2024-53142", "url": "https://ubuntu.com/security/CVE-2024-53142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: initramfs: avoid filename buffer overrun The initramfs filename field is defined in Documentation/driver-api/early-userspace/buffer-format.rst as: 37 cpio_file := ALGN(4) + cpio_header + filename + \"\\0\" + ALGN(4) + data ... 55 ============= ================== ========================= 56 Field name Field size Meaning 57 ============= ================== ========================= ... 70 c_namesize 8 bytes Length of filename, including final \\0 When extracting an initramfs cpio archive, the kernel's do_name() path handler assumes a zero-terminated path at @collected, passing it directly to filp_open() / init_mkdir() / init_mknod(). If a specially crafted cpio entry carries a non-zero-terminated filename and is followed by uninitialized memory, then a file may be created with trailing characters that represent the uninitialized memory. The ability to create an initramfs entry would imply already having full control of the system, so the buffer overrun shouldn't be considered a security vulnerability. Append the output of the following bash script to an existing initramfs and observe any created /initramfs_test_fname_overrunAA* path. E.g. ./reproducer.sh | gzip >> /myinitramfs It's easiest to observe non-zero uninitialized memory when the output is gzipped, as it'll overflow the heap allocated @out_buf in __gunzip(), rather than the initrd_start+initrd_size block. ---- reproducer.sh ---- nilchar=\"A\"\t# change to \"\\0\" to properly zero terminate / pad magic=\"070701\" ino=1 mode=$(( 0100777 )) uid=0 gid=0 nlink=1 mtime=1 filesize=0 devmajor=0 devminor=1 rdevmajor=0 rdevminor=0 csum=0 fname=\"initramfs_test_fname_overrun\" namelen=$(( ${#fname} + 1 ))\t# plus one to account for terminator printf \"%s%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%s\" \\ \t$magic $ino $mode $uid $gid $nlink $mtime $filesize \\ \t$devmajor $devminor $rdevmajor $rdevminor $namelen $csum $fname termpadlen=$(( 1 + ((4 - ((110 + $namelen) & 3)) % 4) )) printf \"%.s${nilchar}\" $(seq 1 $termpadlen) ---- reproducer.sh ---- Symlink filename fields handled in do_symlink() won't overrun past the data segment, due to the explicit zero-termination of the symlink target. Fix filename buffer overrun by aborting the initramfs FSM if any cpio entry doesn't carry a zero-terminator at the expected (name_len - 1) offset.", "cve_priority": "medium", "cve_public_date": "2024-12-06 10:15:00 UTC" }, { "cve": "CVE-2024-53133", "url": "https://ubuntu.com/security/CVE-2024-53133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Handle dml allocation failure to avoid crash [Why] In the case where a dml allocation fails for any reason, the current state's dml contexts would no longer be valid. Then subsequent calls dc_state_copy_internal would shallow copy invalid memory and if the new state was released, a double free would occur. [How] Reset dml pointers in new_state to NULL and avoid invalid pointer (cherry picked from commit bcafdc61529a48f6f06355d78eb41b3aeda5296c)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53108", "url": "https://ubuntu.com/security/CVE-2024-53108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Adjust VSDB parser for replay feature At some point, the IEEE ID identification for the replay check in the AMD EDID was added. However, this check causes the following out-of-bounds issues when using KASAN: [ 27.804016] BUG: KASAN: slab-out-of-bounds in amdgpu_dm_update_freesync_caps+0xefa/0x17a0 [amdgpu] [ 27.804788] Read of size 1 at addr ffff8881647fdb00 by task systemd-udevd/383 ... [ 27.821207] Memory state around the buggy address: [ 27.821215] ffff8881647fda00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821224] ffff8881647fda80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821234] >ffff8881647fdb00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821243] ^ [ 27.821250] ffff8881647fdb80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821259] ffff8881647fdc00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821268] ================================================================== This is caused because the ID extraction happens outside of the range of the edid lenght. This commit addresses this issue by considering the amd_vsdb_block size. (cherry picked from commit b7e381b1ccd5e778e3d9c44c669ad38439a861d8)", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53134", "url": "https://ubuntu.com/security/CVE-2024-53134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pmdomain: imx93-blk-ctrl: correct remove path The check condition should be 'i < bc->onecell_data.num_domains', not 'bc->onecell_data.num_domains' which will make the look never finish and cause kernel panic. Also disable runtime to address \"imx93-blk-ctrl 4ac10000.system-controller: Unbalanced pm_runtime_enable!\"", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53132", "url": "https://ubuntu.com/security/CVE-2024-53132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/oa: Fix \"Missing outer runtime PM protection\" warning Fix the following drm_WARN: [953.586396] xe 0000:00:02.0: [drm] Missing outer runtime PM protection ... <4> [953.587090] ? xe_pm_runtime_get_noresume+0x8d/0xa0 [xe] <4> [953.587208] guc_exec_queue_add_msg+0x28/0x130 [xe] <4> [953.587319] guc_exec_queue_fini+0x3a/0x40 [xe] <4> [953.587425] xe_exec_queue_destroy+0xb3/0xf0 [xe] <4> [953.587515] xe_oa_release+0x9c/0xc0 [xe] (cherry picked from commit b107c63d2953907908fd0cafb0e543b3c3167b75)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53127", "url": "https://ubuntu.com/security/CVE-2024-53127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Revert \"mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K\" The commit 8396c793ffdf (\"mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K\") increased the max_req_size, even for 4K pages, causing various issues: - Panic booting the kernel/rootfs from an SD card on Rockchip RK3566 - Panic booting the kernel/rootfs from an SD card on StarFive JH7100 - \"swiotlb buffer is full\" and data corruption on StarFive JH7110 At this stage no fix have been found, so it's probably better to just revert the change. This reverts commit 8396c793ffdf28bb8aee7cfe0891080f8cab7890.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53130", "url": "https://ubuntu.com/security/CVE-2024-53130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint When using the \"block:block_dirty_buffer\" tracepoint, mark_buffer_dirty() may cause a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because, since the tracepoint was added in mark_buffer_dirty(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, nilfs_grab_buffer(), which grabs a buffer to read (or create) a block of metadata, including b-tree node blocks, does not set the block device, but instead does so only if the buffer is not in the \"uptodate\" state for each of its caller block reading functions. However, if the uptodate flag is set on a folio/page, and the buffer heads are detached from it by try_to_free_buffers(), and new buffer heads are then attached by create_empty_buffers(), the uptodate flag may be restored to each buffer without the block device being set to bh->b_bdev, and mark_buffer_dirty() may be called later in that state, resulting in the bug mentioned above. Fix this issue by making nilfs_grab_buffer() always set the block device of the super block structure to the buffer head, regardless of the state of the buffer's uptodate flag.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53105", "url": "https://ubuntu.com/security/CVE-2024-53105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: page_alloc: move mlocked flag clearance into free_pages_prepare() Syzbot reported a bad page state problem caused by a page being freed using free_page() still having a mlocked flag at free_pages_prepare() stage: BUG: Bad page state in process syz.5.504 pfn:61f45 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x61f45 flags: 0xfff00000080204(referenced|workingset|mlocked|node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000080204 0000000000000000 dead000000000122 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set page_owner tracks the page as allocated page last allocated via order 0, migratetype Unmovable, gfp_mask 0x400dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO), pid 8443, tgid 8442 (syz.5.504), ts 201884660643, free_ts 201499827394 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1537 prep_new_page mm/page_alloc.c:1545 [inline] get_page_from_freelist+0x303f/0x3190 mm/page_alloc.c:3457 __alloc_pages_noprof+0x292/0x710 mm/page_alloc.c:4733 alloc_pages_mpol_noprof+0x3e8/0x680 mm/mempolicy.c:2265 kvm_coalesced_mmio_init+0x1f/0xf0 virt/kvm/coalesced_mmio.c:99 kvm_create_vm virt/kvm/kvm_main.c:1235 [inline] kvm_dev_ioctl_create_vm virt/kvm/kvm_main.c:5488 [inline] kvm_dev_ioctl+0x12dc/0x2240 virt/kvm/kvm_main.c:5530 __do_compat_sys_ioctl fs/ioctl.c:1007 [inline] __se_compat_sys_ioctl+0x510/0xc90 fs/ioctl.c:950 do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline] __do_fast_syscall_32+0xb4/0x110 arch/x86/entry/common.c:386 do_fast_syscall_32+0x34/0x80 arch/x86/entry/common.c:411 entry_SYSENTER_compat_after_hwframe+0x84/0x8e page last free pid 8399 tgid 8399 stack trace: reset_page_owner include/linux/page_owner.h:25 [inline] free_pages_prepare mm/page_alloc.c:1108 [inline] free_unref_folios+0xf12/0x18d0 mm/page_alloc.c:2686 folios_put_refs+0x76c/0x860 mm/swap.c:1007 free_pages_and_swap_cache+0x5c8/0x690 mm/swap_state.c:335 __tlb_batch_free_encoded_pages mm/mmu_gather.c:136 [inline] tlb_batch_pages_flush mm/mmu_gather.c:149 [inline] tlb_flush_mmu_free mm/mmu_gather.c:366 [inline] tlb_flush_mmu+0x3a3/0x680 mm/mmu_gather.c:373 tlb_finish_mmu+0xd4/0x200 mm/mmu_gather.c:465 exit_mmap+0x496/0xc40 mm/mmap.c:1926 __mmput+0x115/0x390 kernel/fork.c:1348 exit_mm+0x220/0x310 kernel/exit.c:571 do_exit+0x9b2/0x28e0 kernel/exit.c:926 do_group_exit+0x207/0x2c0 kernel/exit.c:1088 __do_sys_exit_group kernel/exit.c:1099 [inline] __se_sys_exit_group kernel/exit.c:1097 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1097 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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 Modules linked in: CPU: 0 UID: 0 PID: 8442 Comm: syz.5.504 Not tainted 6.12.0-rc6-syzkaller #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 bad_page+0x176/0x1d0 mm/page_alloc.c:501 free_page_is_bad mm/page_alloc.c:918 [inline] free_pages_prepare mm/page_alloc.c:1100 [inline] free_unref_page+0xed0/0xf20 mm/page_alloc.c:2638 kvm_destroy_vm virt/kvm/kvm_main.c:1327 [inline] kvm_put_kvm+0xc75/0x1350 virt/kvm/kvm_main.c:1386 kvm_vcpu_release+0x54/0x60 virt/kvm/kvm_main.c:4143 __fput+0x23f/0x880 fs/file_table.c:431 task_work_run+0x24f/0x310 kernel/task_work.c:239 exit_task_work include/linux/task_work.h:43 [inline] do_exit+0xa2f/0x28e0 kernel/exit.c:939 do_group_exit+0x207/0x2c0 kernel/exit.c:1088 __do_sys_exit_group kernel/exit.c:1099 [in ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53109", "url": "https://ubuntu.com/security/CVE-2024-53109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nommu: pass NULL argument to vma_iter_prealloc() When deleting a vma entry from a maple tree, it has to pass NULL to vma_iter_prealloc() in order to calculate internal state of the tree, but it passed a wrong argument. As a result, nommu kernels crashed upon accessing a vma iterator, such as acct_collect() reading the size of vma entries after do_munmap(). This commit fixes this issue by passing a right argument to the preallocation call.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53131", "url": "https://ubuntu.com/security/CVE-2024-53131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint Patch series \"nilfs2: fix null-ptr-deref bugs on block tracepoints\". This series fixes null pointer dereference bugs that occur when using nilfs2 and two block-related tracepoints. This patch (of 2): It has been reported that when using \"block:block_touch_buffer\" tracepoint, touch_buffer() called from __nilfs_get_folio_block() causes a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because since the tracepoint was added in touch_buffer(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, the block_device structure is set after the function returns to the caller. Here, touch_buffer() is used to mark the folio/page that owns the buffer head as accessed, but the common search helper for folio/page used by the caller function was optimized to mark the folio/page as accessed when it was reimplemented a long time ago, eliminating the need to call touch_buffer() here in the first place. So this solves the issue by eliminating the touch_buffer() call itself.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53135", "url": "https://ubuntu.com/security/CVE-2024-53135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: VMX: Bury Intel PT virtualization (guest/host mode) behind CONFIG_BROKEN Hide KVM's pt_mode module param behind CONFIG_BROKEN, i.e. disable support for virtualizing Intel PT via guest/host mode unless BROKEN=y. There are myriad bugs in the implementation, some of which are fatal to the guest, and others which put the stability and health of the host at risk. For guest fatalities, the most glaring issue is that KVM fails to ensure tracing is disabled, and *stays* disabled prior to VM-Enter, which is necessary as hardware disallows loading (the guest's) RTIT_CTL if tracing is enabled (enforced via a VMX consistency check). Per the SDM: If the logical processor is operating with Intel PT enabled (if IA32_RTIT_CTL.TraceEn = 1) at the time of VM entry, the \"load IA32_RTIT_CTL\" VM-entry control must be 0. On the host side, KVM doesn't validate the guest CPUID configuration provided by userspace, and even worse, uses the guest configuration to decide what MSRs to save/load at VM-Enter and VM-Exit. E.g. configuring guest CPUID to enumerate more address ranges than are supported in hardware will result in KVM trying to passthrough, save, and load non-existent MSRs, which generates a variety of WARNs, ToPA ERRORs in the host, a potential deadlock, etc.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53106", "url": "https://ubuntu.com/security/CVE-2024-53106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: fix buffer overrun in ima_eventdigest_init_common Function ima_eventdigest_init() calls ima_eventdigest_init_common() with HASH_ALGO__LAST which is then used to access the array hash_digest_size[] leading to buffer overrun. Have a conditional statement to handle this.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53110", "url": "https://ubuntu.com/security/CVE-2024-53110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vp_vdpa: fix id_table array not null terminated error Allocate one extra virtio_device_id as null terminator, otherwise vdpa_mgmtdev_get_classes() may iterate multiple times and visit undefined memory.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53126", "url": "https://ubuntu.com/security/CVE-2024-53126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa: solidrun: Fix UB bug with devres In psnet_open_pf_bar() and snet_open_vf_bar() a string later passed to pcim_iomap_regions() is placed on the stack. Neither pcim_iomap_regions() nor the functions it calls copy that string. Should the string later ever be used, this, consequently, causes undefined behavior since the stack frame will by then have disappeared. Fix the bug by allocating the strings on the heap through devm_kasprintf().", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53111", "url": "https://ubuntu.com/security/CVE-2024-53111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mremap: fix address wraparound in move_page_tables() On 32-bit platforms, it is possible for the expression `len + old_addr < old_end` to be false-positive if `len + old_addr` wraps around. `old_addr` is the cursor in the old range up to which page table entries have been moved; so if the operation succeeded, `old_addr` is the *end* of the old region, and adding `len` to it can wrap. The overflow causes mremap() to mistakenly believe that PTEs have been copied; the consequence is that mremap() bails out, but doesn't move the PTEs back before the new VMA is unmapped, causing anonymous pages in the region to be lost. So basically if userspace tries to mremap() a private-anon region and hits this bug, mremap() will return an error and the private-anon region's contents appear to have been zeroed. The idea of this check is that `old_end - len` is the original start address, and writing the check that way also makes it easier to read; so fix the check by rearranging the comparison accordingly. (An alternate fix would be to refactor this function by introducing an \"orig_old_start\" variable or such.) Tested in a VM with a 32-bit X86 kernel; without the patch: ``` user@horn:~/big_mremap$ cat test.c #define _GNU_SOURCE #include #include #include #include #define ADDR1 ((void*)0x60000000) #define ADDR2 ((void*)0x10000000) #define SIZE 0x50000000uL int main(void) { unsigned char *p1 = mmap(ADDR1, SIZE, PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0); if (p1 == MAP_FAILED) err(1, \"mmap 1\"); unsigned char *p2 = mmap(ADDR2, SIZE, PROT_NONE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0); if (p2 == MAP_FAILED) err(1, \"mmap 2\"); *p1 = 0x41; printf(\"first char is 0x%02hhx\\n\", *p1); unsigned char *p3 = mremap(p1, SIZE, SIZE, MREMAP_MAYMOVE|MREMAP_FIXED, p2); if (p3 == MAP_FAILED) { printf(\"mremap() failed; first char is 0x%02hhx\\n\", *p1); } else { printf(\"mremap() succeeded; first char is 0x%02hhx\\n\", *p3); } } user@horn:~/big_mremap$ gcc -static -o test test.c user@horn:~/big_mremap$ setarch -R ./test first char is 0x41 mremap() failed; first char is 0x00 ``` With the patch: ``` user@horn:~/big_mremap$ setarch -R ./test first char is 0x41 mremap() succeeded; first char is 0x41 ```", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53107", "url": "https://ubuntu.com/security/CVE-2024-53107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: prevent integer overflow in pagemap_scan_get_args() The \"arg->vec_len\" variable is a u64 that comes from the user at the start of the function. The \"arg->vec_len * sizeof(struct page_region))\" multiplication can lead to integer wrapping. Use size_mul() to avoid that. Also the size_add/mul() functions work on unsigned long so for 32bit systems we need to ensure that \"arg->vec_len\" fits in an unsigned long.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53128", "url": "https://ubuntu.com/security/CVE-2024-53128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/task_stack: fix object_is_on_stack() for KASAN tagged pointers When CONFIG_KASAN_SW_TAGS and CONFIG_KASAN_STACK are enabled, the object_is_on_stack() function may produce incorrect results due to the presence of tags in the obj pointer, while the stack pointer does not have tags. This discrepancy can lead to incorrect stack object detection and subsequently trigger warnings if CONFIG_DEBUG_OBJECTS is also enabled. Example of the warning: ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at lib/debugobjects.c:557 __debug_object_init+0x330/0x364 Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5 #4 Hardware name: linux,dummy-virt (DT) pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __debug_object_init+0x330/0x364 lr : __debug_object_init+0x330/0x364 sp : ffff800082ea7b40 x29: ffff800082ea7b40 x28: 98ff0000c0164518 x27: 98ff0000c0164534 x26: ffff800082d93ec8 x25: 0000000000000001 x24: 1cff0000c00172a0 x23: 0000000000000000 x22: ffff800082d93ed0 x21: ffff800081a24418 x20: 3eff800082ea7bb0 x19: efff800000000000 x18: 0000000000000000 x17: 00000000000000ff x16: 0000000000000047 x15: 206b63617473206e x14: 0000000000000018 x13: ffff800082ea7780 x12: 0ffff800082ea78e x11: 0ffff800082ea790 x10: 0ffff800082ea79d x9 : 34d77febe173e800 x8 : 34d77febe173e800 x7 : 0000000000000001 x6 : 0000000000000001 x5 : feff800082ea74b8 x4 : ffff800082870a90 x3 : ffff80008018d3c4 x2 : 0000000000000001 x1 : ffff800082858810 x0 : 0000000000000050 Call trace: __debug_object_init+0x330/0x364 debug_object_init_on_stack+0x30/0x3c schedule_hrtimeout_range_clock+0xac/0x26c schedule_hrtimeout+0x1c/0x30 wait_task_inactive+0x1d4/0x25c kthread_bind_mask+0x28/0x98 init_rescuer+0x1e8/0x280 workqueue_init+0x1a0/0x3cc kernel_init_freeable+0x118/0x200 kernel_init+0x28/0x1f0 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53112", "url": "https://ubuntu.com/security/CVE-2024-53112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: uncache inode which has failed entering the group Syzbot has reported the following BUG: kernel BUG at fs/ocfs2/uptodate.c:509! ... Call Trace: ? __die_body+0x5f/0xb0 ? die+0x9e/0xc0 ? do_trap+0x15a/0x3a0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? do_error_trap+0x1dc/0x2c0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? __pfx_do_error_trap+0x10/0x10 ? handle_invalid_op+0x34/0x40 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? exc_invalid_op+0x38/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? ocfs2_set_new_buffer_uptodate+0x2e/0x160 ? ocfs2_set_new_buffer_uptodate+0x144/0x160 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ocfs2_group_add+0x39f/0x15a0 ? __pfx_ocfs2_group_add+0x10/0x10 ? __pfx_lock_acquire+0x10/0x10 ? mnt_get_write_access+0x68/0x2b0 ? __pfx_lock_release+0x10/0x10 ? rcu_read_lock_any_held+0xb7/0x160 ? __pfx_rcu_read_lock_any_held+0x10/0x10 ? smack_log+0x123/0x540 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x226/0x2b0 ocfs2_ioctl+0x65e/0x7d0 ? __pfx_ocfs2_ioctl+0x10/0x10 ? smack_file_ioctl+0x29e/0x3a0 ? __pfx_smack_file_ioctl+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x43d/0x780 ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10 ? __pfx_ocfs2_ioctl+0x10/0x10 __se_sys_ioctl+0xfb/0x170 do_syscall_64+0xf3/0x230 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... When 'ioctl(OCFS2_IOC_GROUP_ADD, ...)' has failed for the particular inode in 'ocfs2_verify_group_and_input()', corresponding buffer head remains cached and subsequent call to the same 'ioctl()' for the same inode issues the BUG() in 'ocfs2_set_new_buffer_uptodate()' (trying to cache the same buffer head of that inode). Fix this by uncaching the buffer head with 'ocfs2_remove_from_cache()' on error path in 'ocfs2_group_add()'.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53113", "url": "https://ubuntu.com/security/CVE-2024-53113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: fix NULL pointer dereference in alloc_pages_bulk_noprof We triggered a NULL pointer dereference for ac.preferred_zoneref->zone in alloc_pages_bulk_noprof() when the task is migrated between cpusets. When cpuset is enabled, in prepare_alloc_pages(), ac->nodemask may be ¤t->mems_allowed. when first_zones_zonelist() is called to find preferred_zoneref, the ac->nodemask may be modified concurrently if the task is migrated between different cpusets. Assuming we have 2 NUMA Node, when traversing Node1 in ac->zonelist, the nodemask is 2, and when traversing Node2 in ac->zonelist, the nodemask is 1. As a result, the ac->preferred_zoneref points to NULL zone. In alloc_pages_bulk_noprof(), for_each_zone_zonelist_nodemask() finds a allowable zone and calls zonelist_node_idx(ac.preferred_zoneref), leading to NULL pointer dereference. __alloc_pages_noprof() fixes this issue by checking NULL pointer in commit ea57485af8f4 (\"mm, page_alloc: fix check for NULL preferred_zone\") and commit df76cee6bbeb (\"mm, page_alloc: remove redundant checks from alloc fastpath\"). To fix it, check NULL pointer for preferred_zoneref->zone.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53114", "url": "https://ubuntu.com/security/CVE-2024-53114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 client A number of Zen4 client SoCs advertise the ability to use virtualized VMLOAD/VMSAVE, but using these instructions is reported to be a cause of a random host reboot. These instructions aren't intended to be advertised on Zen4 client so clear the capability.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53137", "url": "https://ubuntu.com/security/CVE-2024-53137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: fix cacheflush with PAN It seems that the cacheflush syscall got broken when PAN for LPAE was implemented. User access was not enabled around the cache maintenance instructions, causing them to fault.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53115", "url": "https://ubuntu.com/security/CVE-2024-53115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: avoid null_ptr_deref in vmw_framebuffer_surface_create_handle The 'vmw_user_object_buffer' function may return NULL with incorrect inputs. To avoid possible null pointer dereference, add a check whether the 'bo' is NULL in the vmw_framebuffer_surface_create_handle.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53116", "url": "https://ubuntu.com/security/CVE-2024-53116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix handling of partial GPU mapping of BOs This commit fixes the bug in the handling of partial mapping of the buffer objects to the GPU, which caused kernel warnings. Panthor didn't correctly handle the case where the partial mapping spanned multiple scatterlists and the mapping offset didn't point to the 1st page of starting scatterlist. The offset variable was not cleared after reaching the starting scatterlist. Following warning messages were seen. WARNING: CPU: 1 PID: 650 at drivers/iommu/io-pgtable-arm.c:659 __arm_lpae_unmap+0x254/0x5a0 pc : __arm_lpae_unmap+0x254/0x5a0 lr : __arm_lpae_unmap+0x2cc/0x5a0 Call trace: __arm_lpae_unmap+0x254/0x5a0 __arm_lpae_unmap+0x108/0x5a0 __arm_lpae_unmap+0x108/0x5a0 __arm_lpae_unmap+0x108/0x5a0 arm_lpae_unmap_pages+0x80/0xa0 panthor_vm_unmap_pages+0xac/0x1c8 [panthor] panthor_gpuva_sm_step_unmap+0x4c/0xc8 [panthor] op_unmap_cb.isra.23.constprop.30+0x54/0x80 __drm_gpuvm_sm_unmap+0x184/0x1c8 drm_gpuvm_sm_unmap+0x40/0x60 panthor_vm_exec_op+0xa8/0x120 [panthor] panthor_vm_bind_exec_sync_op+0xc4/0xe8 [panthor] panthor_ioctl_vm_bind+0x10c/0x170 [panthor] drm_ioctl_kernel+0xbc/0x138 drm_ioctl+0x210/0x4b0 __arm64_sys_ioctl+0xb0/0xf8 invoke_syscall+0x4c/0x110 el0_svc_common.constprop.1+0x98/0xf8 do_el0_svc+0x24/0x38 el0_svc+0x34/0xc8 el0t_64_sync_handler+0xa0/0xc8 el0t_64_sync+0x174/0x178 panthor : [drm] drm_WARN_ON(unmapped_sz != pgsize * pgcount) WARNING: CPU: 1 PID: 650 at drivers/gpu/drm/panthor/panthor_mmu.c:922 panthor_vm_unmap_pages+0x124/0x1c8 [panthor] pc : panthor_vm_unmap_pages+0x124/0x1c8 [panthor] lr : panthor_vm_unmap_pages+0x124/0x1c8 [panthor] panthor : [drm] *ERROR* failed to unmap range ffffa388f000-ffffa3890000 (requested range ffffa388c000-ffffa3890000)", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53117", "url": "https://ubuntu.com/security/CVE-2024-53117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio/vsock: Improve MSG_ZEROCOPY error handling Add a missing kfree_skb() to prevent memory leaks.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53118", "url": "https://ubuntu.com/security/CVE-2024-53118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Fix sk_error_queue memory leak Kernel queues MSG_ZEROCOPY completion notifications on the error queue. Where they remain, until explicitly recv()ed. To prevent memory leaks, clean up the queue when the socket is destroyed. unreferenced object 0xffff8881028beb00 (size 224): comm \"vsock_test\", pid 1218, jiffies 4294694897 hex dump (first 32 bytes): 90 b0 21 17 81 88 ff ff 90 b0 21 17 81 88 ff ff ..!.......!..... 00 00 00 00 00 00 00 00 00 b0 21 17 81 88 ff ff ..........!..... backtrace (crc 6c7031ca): [] kmem_cache_alloc_node_noprof+0x2f7/0x370 [] __alloc_skb+0x132/0x180 [] sock_omalloc+0x4b/0x80 [] msg_zerocopy_realloc+0x9e/0x240 [] virtio_transport_send_pkt_info+0x412/0x4c0 [] virtio_transport_stream_enqueue+0x43/0x50 [] vsock_connectible_sendmsg+0x373/0x450 [] ____sys_sendmsg+0x365/0x3a0 [] ___sys_sendmsg+0x84/0xd0 [] __sys_sendmsg+0x47/0x80 [] do_syscall_64+0x93/0x180 [] entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53119", "url": "https://ubuntu.com/security/CVE-2024-53119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio/vsock: Fix accept_queue memory leak As the final stages of socket destruction may be delayed, it is possible that virtio_transport_recv_listen() will be called after the accept_queue has been flushed, but before the SOCK_DONE flag has been set. As a result, sockets enqueued after the flush would remain unremoved, leading to a memory leak. vsock_release __vsock_release lock virtio_transport_release virtio_transport_close schedule_delayed_work(close_work) sk_shutdown = SHUTDOWN_MASK (!) flush accept_queue release virtio_transport_recv_pkt vsock_find_bound_socket lock if flag(SOCK_DONE) return virtio_transport_recv_listen child = vsock_create_connected (!) vsock_enqueue_accept(child) release close_work lock virtio_transport_do_close set_flag(SOCK_DONE) virtio_transport_remove_sock vsock_remove_sock vsock_remove_bound release Introduce a sk_shutdown check to disallow vsock_enqueue_accept() during socket destruction. unreferenced object 0xffff888109e3f800 (size 2040): comm \"kworker/5:2\", pid 371, jiffies 4294940105 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00 (..@............ backtrace (crc 9e5f4e84): [] kmem_cache_alloc_noprof+0x2c1/0x360 [] sk_prot_alloc+0x30/0x120 [] sk_alloc+0x2c/0x4b0 [] __vsock_create.constprop.0+0x2a/0x310 [] virtio_transport_recv_pkt+0x4dc/0x9a0 [] vsock_loopback_work+0xfd/0x140 [] process_one_work+0x20c/0x570 [] worker_thread+0x1bf/0x3a0 [] kthread+0xdd/0x110 [] ret_from_fork+0x2d/0x50 [] ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53120", "url": "https://ubuntu.com/security/CVE-2024-53120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: CT: Fix null-ptr-deref in add rule err flow In error flow of mlx5_tc_ct_entry_add_rule(), in case ct_rule_add() callback returns error, zone_rule->attr is used uninitiated. Fix it to use attr which has the needed pointer value. Kernel log: BUG: kernel NULL pointer dereference, address: 0000000000000110 RIP: 0010:mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core] … Call Trace: ? __die+0x20/0x70 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x140 ? asm_exc_page_fault+0x22/0x30 ? mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core] ? mlx5_tc_ct_entry_add_rule+0x1d5/0x2f0 [mlx5_core] mlx5_tc_ct_block_flow_offload+0xc6a/0xf90 [mlx5_core] ? nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] flow_offload_work_handler+0x142/0x320 [nf_flow_table] ? finish_task_switch.isra.0+0x15b/0x2b0 process_one_work+0x16c/0x320 worker_thread+0x28c/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xb8/0xf0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53138", "url": "https://ubuntu.com/security/CVE-2024-53138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: kTLS, Fix incorrect page refcounting The kTLS tx handling code is using a mix of get_page() and page_ref_inc() APIs to increment the page reference. But on the release path (mlx5e_ktls_tx_handle_resync_dump_comp()), only put_page() is used. This is an issue when using pages from large folios: the get_page() references are stored on the folio page while the page_ref_inc() references are stored directly in the given page. On release the folio page will be dereferenced too many times. This was found while doing kTLS testing with sendfile() + ZC when the served file was read from NFS on a kernel with NFS large folios support (commit 49b29a573da8 (\"nfs: add support for large folios\")).", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53121", "url": "https://ubuntu.com/security/CVE-2024-53121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: fs, lock FTE when checking if active The referenced commits introduced a two-step process for deleting FTEs: - Lock the FTE, delete it from hardware, set the hardware deletion function to NULL and unlock the FTE. - Lock the parent flow group, delete the software copy of the FTE, and remove it from the xarray. However, this approach encounters a race condition if a rule with the same match value is added simultaneously. In this scenario, fs_core may set the hardware deletion function to NULL prematurely, causing a panic during subsequent rule deletions. To prevent this, ensure the active flag of the FTE is checked under a lock, which will prevent the fs_core layer from attaching a new steering rule to an FTE that is in the process of deletion. [ 438.967589] MOSHE: 2496 mlx5_del_flow_rules del_hw_func [ 438.968205] ------------[ cut here ]------------ [ 438.968654] refcount_t: decrement hit 0; leaking memory. [ 438.969249] WARNING: CPU: 0 PID: 8957 at lib/refcount.c:31 refcount_warn_saturate+0xfb/0x110 [ 438.970054] Modules linked in: act_mirred cls_flower act_gact sch_ingress openvswitch nsh mlx5_vdpa vringh vhost_iotlb vdpa mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core zram zsmalloc fuse [last unloaded: cls_flower] [ 438.973288] CPU: 0 UID: 0 PID: 8957 Comm: tc Not tainted 6.12.0-rc1+ #8 [ 438.973888] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 438.974874] RIP: 0010:refcount_warn_saturate+0xfb/0x110 [ 438.975363] Code: 40 66 3b 82 c6 05 16 e9 4d 01 01 e8 1f 7c a0 ff 0f 0b c3 cc cc cc cc 48 c7 c7 10 66 3b 82 c6 05 fd e8 4d 01 01 e8 05 7c a0 ff <0f> 0b c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 90 [ 438.976947] RSP: 0018:ffff888124a53610 EFLAGS: 00010286 [ 438.977446] RAX: 0000000000000000 RBX: ffff888119d56de0 RCX: 0000000000000000 [ 438.978090] RDX: ffff88852c828700 RSI: ffff88852c81b3c0 RDI: ffff88852c81b3c0 [ 438.978721] RBP: ffff888120fa0e88 R08: 0000000000000000 R09: ffff888124a534b0 [ 438.979353] R10: 0000000000000001 R11: 0000000000000001 R12: ffff888119d56de0 [ 438.979979] R13: ffff888120fa0ec0 R14: ffff888120fa0ee8 R15: ffff888119d56de0 [ 438.980607] FS: 00007fe6dcc0f800(0000) GS:ffff88852c800000(0000) knlGS:0000000000000000 [ 438.983984] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 438.984544] CR2: 00000000004275e0 CR3: 0000000186982001 CR4: 0000000000372eb0 [ 438.985205] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 438.985842] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 438.986507] Call Trace: [ 438.986799] [ 438.987070] ? __warn+0x7d/0x110 [ 438.987426] ? refcount_warn_saturate+0xfb/0x110 [ 438.987877] ? report_bug+0x17d/0x190 [ 438.988261] ? prb_read_valid+0x17/0x20 [ 438.988659] ? handle_bug+0x53/0x90 [ 438.989054] ? exc_invalid_op+0x14/0x70 [ 438.989458] ? asm_exc_invalid_op+0x16/0x20 [ 438.989883] ? refcount_warn_saturate+0xfb/0x110 [ 438.990348] mlx5_del_flow_rules+0x2f7/0x340 [mlx5_core] [ 438.990932] __mlx5_eswitch_del_rule+0x49/0x170 [mlx5_core] [ 438.991519] ? mlx5_lag_is_sriov+0x3c/0x50 [mlx5_core] [ 438.992054] ? xas_load+0x9/0xb0 [ 438.992407] mlx5e_tc_rule_unoffload+0x45/0xe0 [mlx5_core] [ 438.993037] mlx5e_tc_del_fdb_flow+0x2a6/0x2e0 [mlx5_core] [ 438.993623] mlx5e_flow_put+0x29/0x60 [mlx5_core] [ 438.994161] mlx5e_delete_flower+0x261/0x390 [mlx5_core] [ 438.994728] tc_setup_cb_destroy+0xb9/0x190 [ 438.995150] fl_hw_destroy_filter+0x94/0xc0 [cls_flower] [ 438.995650] fl_change+0x11a4/0x13c0 [cls_flower] [ 438.996105] tc_new_tfilter+0x347/0xbc0 [ 438.996503] ? __ ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53122", "url": "https://ubuntu.com/security/CVE-2024-53122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: cope racing subflow creation in mptcp_rcv_space_adjust Additional active subflows - i.e. created by the in kernel path manager - are included into the subflow list before starting the 3whs. A racing recvmsg() spooling data received on an already established subflow would unconditionally call tcp_cleanup_rbuf() on all the current subflows, potentially hitting a divide by zero error on the newly created ones. Explicitly check that the subflow is in a suitable state before invoking tcp_cleanup_rbuf().", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53123", "url": "https://ubuntu.com/security/CVE-2024-53123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: error out earlier on disconnect Eric reported a division by zero splat in the MPTCP protocol: Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 6094 Comm: syz-executor317 Not tainted 6.12.0-rc5-syzkaller-00291-g05b92660cdfe #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:__tcp_select_window+0x5b4/0x1310 net/ipv4/tcp_output.c:3163 Code: f6 44 01 e3 89 df e8 9b 75 09 f8 44 39 f3 0f 8d 11 ff ff ff e8 0d 74 09 f8 45 89 f4 e9 04 ff ff ff e8 00 74 09 f8 44 89 f0 99 7c 24 14 41 29 d6 45 89 f4 e9 ec fe ff ff e8 e8 73 09 f8 48 89 RSP: 0018:ffffc900041f7930 EFLAGS: 00010293 RAX: 0000000000017e67 RBX: 0000000000017e67 RCX: ffffffff8983314b RDX: 0000000000000000 RSI: ffffffff898331b0 RDI: 0000000000000004 RBP: 00000000005d6000 R08: 0000000000000004 R09: 0000000000017e67 R10: 0000000000003e80 R11: 0000000000000000 R12: 0000000000003e80 R13: ffff888031d9b440 R14: 0000000000017e67 R15: 00000000002eb000 FS: 00007feb5d7f16c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007feb5d8adbb8 CR3: 0000000074e4c000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __tcp_cleanup_rbuf+0x3e7/0x4b0 net/ipv4/tcp.c:1493 mptcp_rcv_space_adjust net/mptcp/protocol.c:2085 [inline] mptcp_recvmsg+0x2156/0x2600 net/mptcp/protocol.c:2289 inet_recvmsg+0x469/0x6a0 net/ipv4/af_inet.c:885 sock_recvmsg_nosec net/socket.c:1051 [inline] sock_recvmsg+0x1b2/0x250 net/socket.c:1073 __sys_recvfrom+0x1a5/0x2e0 net/socket.c:2265 __do_sys_recvfrom net/socket.c:2283 [inline] __se_sys_recvfrom net/socket.c:2279 [inline] __x64_sys_recvfrom+0xe0/0x1c0 net/socket.c:2279 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 RIP: 0033:0x7feb5d857559 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:00007feb5d7f1208 EFLAGS: 00000246 ORIG_RAX: 000000000000002d RAX: ffffffffffffffda RBX: 00007feb5d8e1318 RCX: 00007feb5d857559 RDX: 000000800000000e RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007feb5d8e1310 R08: 0000000000000000 R09: ffffffff81000000 R10: 0000000000000100 R11: 0000000000000246 R12: 00007feb5d8e131c R13: 00007feb5d8ae074 R14: 000000800000000e R15: 00000000fffffdef and provided a nice reproducer. The root cause is the current bad handling of racing disconnect. After the blamed commit below, sk_wait_data() can return (with error) with the underlying socket disconnected and a zero rcv_mss. Catch the error and return without performing any additional operations on the current socket.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53124", "url": "https://ubuntu.com/security/CVE-2024-53124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix data-races around sk->sk_forward_alloc Syzkaller reported this warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 16 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x1c5/0x1e0 Modules linked in: CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:inet_sock_destruct+0x1c5/0x1e0 Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 <0f> 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00 RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206 RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007 RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00 RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007 R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00 R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78 FS: 0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn+0x88/0x130 ? inet_sock_destruct+0x1c5/0x1e0 ? report_bug+0x18e/0x1a0 ? handle_bug+0x53/0x90 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? inet_sock_destruct+0x1c5/0x1e0 __sk_destruct+0x2a/0x200 rcu_do_batch+0x1aa/0x530 ? rcu_do_batch+0x13b/0x530 rcu_core+0x159/0x2f0 handle_softirqs+0xd3/0x2b0 ? __pfx_smpboot_thread_fn+0x10/0x10 run_ksoftirqd+0x25/0x30 smpboot_thread_fn+0xdd/0x1d0 kthread+0xd3/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ---[ end trace 0000000000000000 ]--- Its possible that two threads call tcp_v6_do_rcv()/sk_forward_alloc_add() concurrently when sk->sk_state == TCP_LISTEN with sk->sk_lock unlocked, which triggers a data-race around sk->sk_forward_alloc: tcp_v6_rcv tcp_v6_do_rcv skb_clone_and_charge_r sk_rmem_schedule __sk_mem_schedule sk_forward_alloc_add() skb_set_owner_r sk_mem_charge sk_forward_alloc_add() __kfree_skb skb_release_all skb_release_head_state sock_rfree sk_mem_uncharge sk_forward_alloc_add() sk_mem_reclaim // set local var reclaimable __sk_mem_reclaim sk_forward_alloc_add() In this syzkaller testcase, two threads call tcp_v6_do_rcv() with skb->truesize=768, the sk_forward_alloc changes like this: (cpu 1) | (cpu 2) | sk_forward_alloc ... | ... | 0 __sk_mem_schedule() | | +4096 = 4096 | __sk_mem_schedule() | +4096 = 8192 sk_mem_charge() | | -768 = 7424 | sk_mem_charge() | -768 = 6656 ... | ... | sk_mem_uncharge() | | +768 = 7424 reclaimable=7424 | | | sk_mem_uncharge() | +768 = 8192 | reclaimable=8192 | __sk_mem_reclaim() | | -4096 = 4096 | __sk_mem_reclaim() | -8192 = -4096 != 0 The skb_clone_and_charge_r() should not be called in tcp_v6_do_rcv() when sk->sk_state is TCP_LISTEN, it happens later in tcp_v6_syn_recv_sock(). Fix the same issue in dccp_v6_do_rcv().", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53129", "url": "https://ubuntu.com/security/CVE-2024-53129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: vop: Fix a dereferenced before check warning The 'state' can't be NULL, we should check crtc_state. Fix warning: drivers/gpu/drm/rockchip/rockchip_drm_vop.c:1096 vop_plane_atomic_async_check() warn: variable dereferenced before check 'state' (see line 1077)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53139", "url": "https://ubuntu.com/security/CVE-2024-53139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix possible UAF in sctp_v6_available() A lockdep report [1] with CONFIG_PROVE_RCU_LIST=y hints that sctp_v6_available() is calling dev_get_by_index_rcu() and ipv6_chk_addr() without holding rcu. [1] ============================= WARNING: suspicious RCU usage 6.12.0-rc5-virtme #1216 Tainted: G W ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by sctp_hello/31495: #0: ffff9f1ebbdb7418 (sk_lock-AF_INET6){+.+.}-{0:0}, at: sctp_bind (./arch/x86/include/asm/jump_label.h:27 net/sctp/socket.c:315) sctp stack backtrace: CPU: 7 UID: 0 PID: 31495 Comm: sctp_hello Tainted: G W 6.12.0-rc5-virtme #1216 Tainted: [W]=WARN 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:123) lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822) dev_get_by_index_rcu (net/core/dev.c:876 (discriminator 7)) sctp_v6_available (net/sctp/ipv6.c:701) sctp sctp_do_bind (net/sctp/socket.c:400 (discriminator 1)) sctp sctp_bind (net/sctp/socket.c:320) sctp inet6_bind_sk (net/ipv6/af_inet6.c:465) ? security_socket_bind (security/security.c:4581 (discriminator 1)) __sys_bind (net/socket.c:1848 net/socket.c:1869) ? do_user_addr_fault (./include/linux/rcupdate.h:347 ./include/linux/rcupdate.h:880 ./include/linux/mm.h:729 arch/x86/mm/fault.c:1340) ? do_user_addr_fault (./arch/x86/include/asm/preempt.h:84 (discriminator 13) ./include/linux/rcupdate.h:98 (discriminator 13) ./include/linux/rcupdate.h:882 (discriminator 13) ./include/linux/mm.h:729 (discriminator 13) arch/x86/mm/fault.c:1340 (discriminator 13)) __x64_sys_bind (net/socket.c:1877 (discriminator 1) net/socket.c:1875 (discriminator 1) net/socket.c:1875 (discriminator 1)) do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f59b934a1e7 Code: 44 00 00 48 8b 15 39 8c 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 b8 31 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 09 8c 0c 00 f7 d8 64 89 01 48 All code ======== 0:\t44 00 00 \tadd %r8b,(%rax) 3:\t48 8b 15 39 8c 0c 00 \tmov 0xc8c39(%rip),%rdx # 0xc8c43 a:\tf7 d8 \tneg %eax c:\t64 89 02 \tmov %eax,%fs:(%rdx) f:\tb8 ff ff ff ff \tmov $0xffffffff,%eax 14:\teb bd \tjmp 0xffffffffffffffd3 16:\t66 2e 0f 1f 84 00 00 \tcs nopw 0x0(%rax,%rax,1) 1d:\t00 00 00 20:\t0f 1f 00 \tnopl (%rax) 23:\tb8 31 00 00 00 \tmov $0x31,%eax 28:\t0f 05 \tsyscall 2a:*\t48 3d 01 f0 ff ff \tcmp $0xfffffffffffff001,%rax\t\t<-- trapping instruction 30:\t73 01 \tjae 0x33 32:\tc3 \tret 33:\t48 8b 0d 09 8c 0c 00 \tmov 0xc8c09(%rip),%rcx # 0xc8c43 3a:\tf7 d8 \tneg %eax 3c:\t64 89 01 \tmov %eax,%fs:(%rcx) 3f:\t48 \trex.W Code starting with the faulting instruction =========================================== 0:\t48 3d 01 f0 ff ff \tcmp $0xfffffffffffff001,%rax 6:\t73 01 \tjae 0x9 8:\tc3 \tret 9:\t48 8b 0d 09 8c 0c 00 \tmov 0xc8c09(%rip),%rcx # 0xc8c19 10:\tf7 d8 \tneg %eax 12:\t64 89 01 \tmov %eax,%fs:(%rcx) 15:\t48 \trex.W RSP: 002b:00007ffe2d0ad398 EFLAGS: 00000202 ORIG_RAX: 0000000000000031 RAX: ffffffffffffffda RBX: 00007ffe2d0ad3d0 RCX: 00007f59b934a1e7 RDX: 000000000000001c RSI: 00007ffe2d0ad3d0 RDI: 0000000000000005 RBP: 0000000000000005 R08: 1999999999999999 R09: 0000000000000000 R10: 00007f59b9253298 R11: 000000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53140", "url": "https://ubuntu.com/security/CVE-2024-53140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netlink: terminate outstanding dump on socket close Netlink supports iterative dumping of data. It provides the families the following ops: - start - (optional) kicks off the dumping process - dump - actual dump helper, keeps getting called until it returns 0 - done - (optional) pairs with .start, can be used for cleanup The whole process is asynchronous and the repeated calls to .dump don't actually happen in a tight loop, but rather are triggered in response to recvmsg() on the socket. This gives the user full control over the dump, but also means that the user can close the socket without getting to the end of the dump. To make sure .start is always paired with .done we check if there is an ongoing dump before freeing the socket, and if so call .done. The complication is that sockets can get freed from BH and .done is allowed to sleep. So we use a workqueue to defer the call, when needed. Unfortunately this does not work correctly. What we defer is not the cleanup but rather releasing a reference on the socket. We have no guarantee that we own the last reference, if someone else holds the socket they may release it in BH and we're back to square one. The whole dance, however, appears to be unnecessary. Only the user can interact with dumps, so we can clean up when socket is closed. And close always happens in process context. Some async code may still access the socket after close, queue notification skbs to it etc. but no dumps can start, end or otherwise make progress. Delete the workqueue and flush the dump state directly from the release handler. Note that further cleanup is possible in -next, for instance we now always call .done before releasing the main module reference, so dump doesn't have to take a reference of its own.", "cve_priority": "high", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53098", "url": "https://ubuntu.com/security/CVE-2024-53098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/ufence: Prefetch ufence addr to catch bogus address access_ok() only checks for addr overflow so also try to read the addr to catch invalid addr sent from userspace. (cherry picked from commit 9408c4508483ffc60811e910a93d6425b8e63928)", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53099", "url": "https://ubuntu.com/security/CVE-2024-53099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check validity of link->type in bpf_link_show_fdinfo() If a newly-added link type doesn't invoke BPF_LINK_TYPE(), accessing bpf_link_type_strs[link->type] may result in an out-of-bounds access. To spot such missed invocations early in the future, checking the validity of link->type in bpf_link_show_fdinfo() and emitting a warning when such invocations are missed.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53089", "url": "https://ubuntu.com/security/CVE-2024-53089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: KVM: Mark hrtimer to expire in hard interrupt context Like commit 2c0d278f3293f (\"KVM: LAPIC: Mark hrtimer to expire in hard interrupt context\") and commit 9090825fa9974 (\"KVM: arm/arm64: Let the timer expire in hardirq context on RT\"), On PREEMPT_RT enabled kernels unmarked hrtimers are moved into soft interrupt expiry mode by default. Then the timers are canceled from an preempt-notifier which is invoked with disabled preemption which is not allowed on PREEMPT_RT. The timer callback is short so in could be invoked in hard-IRQ context. So let the timer expire on hard-IRQ context even on -RT. This fix a \"scheduling while atomic\" bug for PREEMPT_RT enabled kernels: BUG: scheduling while atomic: qemu-system-loo/1011/0x00000002 Modules linked in: amdgpu rfkill nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat ns CPU: 1 UID: 0 PID: 1011 Comm: qemu-system-loo Tainted: G W 6.12.0-rc2+ #1774 Tainted: [W]=WARN Hardware name: Loongson Loongson-3A5000-7A1000-1w-CRB/Loongson-LS3A5000-7A1000-1w-CRB, BIOS vUDK2018-LoongArch-V2.0.0-prebeta9 10/21/2022 Stack : ffffffffffffffff 0000000000000000 9000000004e3ea38 9000000116744000 90000001167475a0 0000000000000000 90000001167475a8 9000000005644830 90000000058dc000 90000000058dbff8 9000000116747420 0000000000000001 0000000000000001 6a613fc938313980 000000000790c000 90000001001c1140 00000000000003fe 0000000000000001 000000000000000d 0000000000000003 0000000000000030 00000000000003f3 000000000790c000 9000000116747830 90000000057ef000 0000000000000000 9000000005644830 0000000000000004 0000000000000000 90000000057f4b58 0000000000000001 9000000116747868 900000000451b600 9000000005644830 9000000003a13998 0000000010000020 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d ... Call Trace: [<9000000003a13998>] show_stack+0x38/0x180 [<9000000004e3ea34>] dump_stack_lvl+0x84/0xc0 [<9000000003a71708>] __schedule_bug+0x48/0x60 [<9000000004e45734>] __schedule+0x1114/0x1660 [<9000000004e46040>] schedule_rtlock+0x20/0x60 [<9000000004e4e330>] rtlock_slowlock_locked+0x3f0/0x10a0 [<9000000004e4f038>] rt_spin_lock+0x58/0x80 [<9000000003b02d68>] hrtimer_cancel_wait_running+0x68/0xc0 [<9000000003b02e30>] hrtimer_cancel+0x70/0x80 [] kvm_restore_timer+0x50/0x1a0 [kvm] [] kvm_arch_vcpu_load+0x68/0x2a0 [kvm] [] kvm_sched_in+0x34/0x60 [kvm] [<9000000003a749a0>] finish_task_switch.isra.0+0x140/0x2e0 [<9000000004e44a70>] __schedule+0x450/0x1660 [<9000000004e45cb0>] schedule+0x30/0x180 [] kvm_vcpu_block+0x70/0x120 [kvm] [] kvm_vcpu_halt+0x60/0x3e0 [kvm] [] kvm_handle_gspr+0x3f4/0x4e0 [kvm] [] kvm_handle_exit+0x1c8/0x260 [kvm]", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53090", "url": "https://ubuntu.com/security/CVE-2024-53090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix lock recursion afs_wake_up_async_call() can incur lock recursion. The problem is that it is called from AF_RXRPC whilst holding the ->notify_lock, but it tries to take a ref on the afs_call struct in order to pass it to a work queue - but if the afs_call is already queued, we then have an extraneous ref that must be put... calling afs_put_call() may call back down into AF_RXRPC through rxrpc_kernel_shutdown_call(), however, which might try taking the ->notify_lock again. This case isn't very common, however, so defer it to a workqueue. The oops looks something like: BUG: spinlock recursion on CPU#0, krxrpcio/7001/1646 lock: 0xffff888141399b30, .magic: dead4ead, .owner: krxrpcio/7001/1646, .owner_cpu: 0 CPU: 0 UID: 0 PID: 1646 Comm: krxrpcio/7001 Not tainted 6.12.0-rc2-build3+ #4351 Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014 Call Trace: dump_stack_lvl+0x47/0x70 do_raw_spin_lock+0x3c/0x90 rxrpc_kernel_shutdown_call+0x83/0xb0 afs_put_call+0xd7/0x180 rxrpc_notify_socket+0xa0/0x190 rxrpc_input_split_jumbo+0x198/0x1d0 rxrpc_input_data+0x14b/0x1e0 ? rxrpc_input_call_packet+0xc2/0x1f0 rxrpc_input_call_event+0xad/0x6b0 rxrpc_input_packet_on_conn+0x1e1/0x210 rxrpc_input_packet+0x3f2/0x4d0 rxrpc_io_thread+0x243/0x410 ? __pfx_rxrpc_io_thread+0x10/0x10 kthread+0xcf/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x24/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53101", "url": "https://ubuntu.com/security/CVE-2024-53101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized value issue in from_kuid and from_kgid ocfs2_setattr() uses attr->ia_mode, attr->ia_uid and attr->ia_gid in a trace point even though ATTR_MODE, ATTR_UID and ATTR_GID aren't set. Initialize all fields of newattrs to avoid uninitialized variables, by checking if ATTR_MODE, ATTR_UID, ATTR_GID are initialized, otherwise 0.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53091", "url": "https://ubuntu.com/security/CVE-2024-53091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Add sk_is_inet and IS_ICSK check in tls_sw_has_ctx_tx/rx As the introduction of the support for vsock and unix sockets in sockmap, tls_sw_has_ctx_tx/rx cannot presume the socket passed in must be IS_ICSK. vsock and af_unix sockets have vsock_sock and unix_sock instead of inet_connection_sock. For these sockets, tls_get_ctx may return an invalid pointer and cause page fault in function tls_sw_ctx_rx. BUG: unable to handle page fault for address: 0000000000040030 Workqueue: vsock-loopback vsock_loopback_work RIP: 0010:sk_psock_strp_data_ready+0x23/0x60 Call Trace: ? __die+0x81/0xc3 ? no_context+0x194/0x350 ? do_page_fault+0x30/0x110 ? async_page_fault+0x3e/0x50 ? sk_psock_strp_data_ready+0x23/0x60 virtio_transport_recv_pkt+0x750/0x800 ? update_load_avg+0x7e/0x620 vsock_loopback_work+0xd0/0x100 process_one_work+0x1a7/0x360 worker_thread+0x30/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x112/0x130 ? __kthread_cancel_work+0x40/0x40 ret_from_fork+0x1f/0x40 v2: - Add IS_ICSK check v3: - Update the commits in Fixes", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53092", "url": "https://ubuntu.com/security/CVE-2024-53092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_pci: Fix admin vq cleanup by using correct info pointer vp_modern_avq_cleanup() and vp_del_vqs() clean up admin vq resources by virtio_pci_vq_info pointer. The info pointer of admin vq is stored in vp_dev->admin_vq.info instead of vp_dev->vqs[]. Using the info pointer from vp_dev->vqs[] for admin vq causes a kernel NULL pointer dereference bug. In vp_modern_avq_cleanup() and vp_del_vqs(), get the info pointer from vp_dev->admin_vq.info for admin vq to clean up the resources. Also make info ptr as argument of vp_del_vq() to be symmetric with vp_setup_vq(). vp_reset calls vp_modern_avq_cleanup, and causes the Call Trace: ================================================================== BUG: kernel NULL pointer dereference, address:0000000000000000 ... CPU: 49 UID: 0 PID: 4439 Comm: modprobe Not tainted 6.11.0-rc5 #1 RIP: 0010:vp_reset+0x57/0x90 [virtio_pci] Call Trace: ... ? vp_reset+0x57/0x90 [virtio_pci] ? vp_reset+0x38/0x90 [virtio_pci] virtio_reset_device+0x1d/0x30 remove_vq_common+0x1c/0x1a0 [virtio_net] virtnet_remove+0xa1/0xc0 [virtio_net] virtio_dev_remove+0x46/0xa0 ... virtio_pci_driver_exit+0x14/0x810 [virtio_pci] ==================================================================", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53102", "url": "https://ubuntu.com/security/CVE-2024-53102", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53093", "url": "https://ubuntu.com/security/CVE-2024-53093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: defer partition scanning We need to suppress the partition scan from occuring within the controller's scan_work context. If a path error occurs here, the IO will wait until a path becomes available or all paths are torn down, but that action also occurs within scan_work, so it would deadlock. Defer the partion scan to a different context that does not block scan_work.", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53094", "url": "https://ubuntu.com/security/CVE-2024-53094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Add sendpage_ok() check to disable MSG_SPLICE_PAGES While running ISER over SIW, the initiator machine encounters a warning from skb_splice_from_iter() indicating that a slab page is being used in send_page. To address this, it is better to add a sendpage_ok() check within the driver itself, and if it returns 0, then MSG_SPLICE_PAGES flag should be disabled before entering the network stack. A similar issue has been discussed for NVMe in this thread: https://lore.kernel.org/all/20240530142417.146696-1-ofir.gal@volumez.com/ WARNING: CPU: 0 PID: 5342 at net/core/skbuff.c:7140 skb_splice_from_iter+0x173/0x320 Call Trace: tcp_sendmsg_locked+0x368/0xe40 siw_tx_hdt+0x695/0xa40 [siw] siw_qp_sq_process+0x102/0xb00 [siw] siw_sq_resume+0x39/0x110 [siw] siw_run_sq+0x74/0x160 [siw] kthread+0xd2/0x100 ret_from_fork+0x34/0x40 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53100", "url": "https://ubuntu.com/security/CVE-2024-53100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: tcp: avoid race between queue_lock lock and destroy Commit 76d54bf20cdc (\"nvme-tcp: don't access released socket during error recovery\") added a mutex_lock() call for the queue->queue_lock in nvme_tcp_get_address(). However, the mutex_lock() races with mutex_destroy() in nvme_tcp_free_queue(), and causes the WARN below. DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: CPU: 3 PID: 34077 at kernel/locking/mutex.c:587 __mutex_lock+0xcf0/0x1220 Modules linked in: nvmet_tcp nvmet nvme_tcp nvme_fabrics iw_cm ib_cm ib_core pktcdvd nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables qrtr sunrpc ppdev 9pnet_virtio 9pnet pcspkr netfs parport_pc parport e1000 i2c_piix4 i2c_smbus loop fuse nfnetlink zram bochs drm_vram_helper drm_ttm_helper ttm drm_kms_helper xfs drm sym53c8xx floppy nvme scsi_transport_spi nvme_core nvme_auth serio_raw ata_generic pata_acpi dm_multipath qemu_fw_cfg [last unloaded: ib_uverbs] CPU: 3 UID: 0 PID: 34077 Comm: udisksd Not tainted 6.11.0-rc7 #319 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:__mutex_lock+0xcf0/0x1220 Code: 08 84 d2 0f 85 c8 04 00 00 8b 15 ef b6 c8 01 85 d2 0f 85 78 f4 ff ff 48 c7 c6 20 93 ee af 48 c7 c7 60 91 ee af e8 f0 a7 6d fd <0f> 0b e9 5e f4 ff ff 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 RSP: 0018:ffff88811305f760 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff88812c652058 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000001 RBP: ffff88811305f8b0 R08: 0000000000000001 R09: ffffed1075c36341 R10: ffff8883ae1b1a0b R11: 0000000000010498 R12: 0000000000000000 R13: 0000000000000000 R14: dffffc0000000000 R15: ffff88812c652058 FS: 00007f9713ae4980(0000) GS:ffff8883ae180000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcd78483c7c CR3: 0000000122c38000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn.cold+0x5b/0x1af ? __mutex_lock+0xcf0/0x1220 ? report_bug+0x1ec/0x390 ? handle_bug+0x3c/0x80 ? exc_invalid_op+0x13/0x40 ? asm_exc_invalid_op+0x16/0x20 ? __mutex_lock+0xcf0/0x1220 ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] ? __pfx___mutex_lock+0x10/0x10 ? __lock_acquire+0xd6a/0x59e0 ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] ? __pfx_nvme_tcp_get_address+0x10/0x10 [nvme_tcp] nvme_sysfs_show_address+0x81/0xc0 [nvme_core] dev_attr_show+0x42/0x80 ? __asan_memset+0x1f/0x40 sysfs_kf_seq_show+0x1f0/0x370 seq_read_iter+0x2cb/0x1130 ? rw_verify_area+0x3b1/0x590 ? __mutex_lock+0x433/0x1220 vfs_read+0x6a6/0xa20 ? lockdep_hardirqs_on+0x78/0x100 ? __pfx_vfs_read+0x10/0x10 ksys_read+0xf7/0x1d0 ? __pfx_ksys_read+0x10/0x10 ? __x64_sys_openat+0x105/0x1d0 do_syscall_64+0x93/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? __pfx_ksys_read+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? do_syscall_64+0x9f/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f9713f55cfa Code: 55 48 89 e5 48 83 ec 20 48 89 55 e8 48 89 75 f0 89 7d f8 e8 e8 74 f8 ff 48 8b 55 e8 48 8b 75 f0 4 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53095", "url": "https://ubuntu.com/security/CVE-2024-53095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix use-after-free of network namespace. Recently, we got a customer report that CIFS triggers oops while reconnecting to a server. [0] The workload runs on Kubernetes, and some pods mount CIFS servers in non-root network namespaces. The problem rarely happened, but it was always while the pod was dying. The root cause is wrong reference counting for network namespace. CIFS uses kernel sockets, which do not hold refcnt of the netns that the socket belongs to. That means CIFS must ensure the socket is always freed before its netns; otherwise, use-after-free happens. The repro steps are roughly: 1. mount CIFS in a non-root netns 2. drop packets from the netns 3. destroy the netns 4. unmount CIFS We can reproduce the issue quickly with the script [1] below and see the splat [2] if CONFIG_NET_NS_REFCNT_TRACKER is enabled. When the socket is TCP, it is hard to guarantee the netns lifetime without holding refcnt due to async timers. Let's hold netns refcnt for each socket as done for SMC in commit 9744d2bf1976 (\"smc: Fix use-after-free in tcp_write_timer_handler().\"). Note that we need to move put_net() from cifs_put_tcp_session() to clean_demultiplex_info(); otherwise, __sock_create() still could touch a freed netns while cifsd tries to reconnect from cifs_demultiplex_thread(). Also, maybe_get_net() cannot be put just before __sock_create() because the code is not under RCU and there is a small chance that the same address happened to be reallocated to another netns. [0]: CIFS: VFS: \\\\XXXXXXXXXXX has not responded in 15 seconds. Reconnecting... CIFS: Serverclose failed 4 times, giving up Unable to handle kernel paging request at virtual address 14de99e461f84a07 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 CM = 0, WnR = 0 [14de99e461f84a07] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: cls_bpf sch_ingress nls_utf8 cifs cifs_arc4 cifs_md4 dns_resolver tcp_diag inet_diag veth xt_state xt_connmark nf_conntrack_netlink xt_nat xt_statistic xt_MASQUERADE xt_mark xt_addrtype ipt_REJECT nf_reject_ipv4 nft_chain_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment nft_compat nf_tables nfnetlink overlay nls_ascii nls_cp437 sunrpc vfat fat aes_ce_blk aes_ce_cipher ghash_ce sm4_ce_cipher sm4 sm3_ce sm3 sha3_ce sha512_ce sha512_arm64 sha1_ce ena button sch_fq_codel loop fuse configfs dmi_sysfs sha2_ce sha256_arm64 dm_mirror dm_region_hash dm_log dm_mod dax efivarfs CPU: 5 PID: 2690970 Comm: cifsd Not tainted 6.1.103-109.184.amzn2023.aarch64 #1 Hardware name: Amazon EC2 r7g.4xlarge/, BIOS 1.0 11/1/2018 pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : fib_rules_lookup+0x44/0x238 lr : __fib_lookup+0x64/0xbc sp : ffff8000265db790 x29: ffff8000265db790 x28: 0000000000000000 x27: 000000000000bd01 x26: 0000000000000000 x25: ffff000b4baf8000 x24: ffff00047b5e4580 x23: ffff8000265db7e0 x22: 0000000000000000 x21: ffff00047b5e4500 x20: ffff0010e3f694f8 x19: 14de99e461f849f7 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 3f92800abd010002 x11: 0000000000000001 x10: ffff0010e3f69420 x9 : ffff800008a6f294 x8 : 0000000000000000 x7 : 0000000000000006 x6 : 0000000000000000 x5 : 0000000000000001 x4 : ffff001924354280 x3 : ffff8000265db7e0 x2 : 0000000000000000 x1 : ffff0010e3f694f8 x0 : ffff00047b5e4500 Call trace: fib_rules_lookup+0x44/0x238 __fib_lookup+0x64/0xbc ip_route_output_key_hash_rcu+0x2c4/0x398 ip_route_output_key_hash+0x60/0x8c tcp_v4_connect+0x290/0x488 __inet_stream_connect+0x108/0x3d0 inet_stream_connect+0x50/0x78 kernel_connect+0x6c/0xac generic_ip_conne ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-50265", "url": "https://ubuntu.com/security/CVE-2024-50265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove() Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove(): [ 57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12 [ 57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry [ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004 [...] [ 57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [...] [ 57.331328] Call Trace: [ 57.331477] [...] [ 57.333511] ? do_user_addr_fault+0x3e5/0x740 [ 57.333778] ? exc_page_fault+0x70/0x170 [ 57.334016] ? asm_exc_page_fault+0x2b/0x30 [ 57.334263] ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10 [ 57.334596] ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [ 57.334913] ocfs2_xa_remove_entry+0x23/0xc0 [ 57.335164] ocfs2_xa_set+0x704/0xcf0 [ 57.335381] ? _raw_spin_unlock+0x1a/0x40 [ 57.335620] ? ocfs2_inode_cache_unlock+0x16/0x20 [ 57.335915] ? trace_preempt_on+0x1e/0x70 [ 57.336153] ? start_this_handle+0x16c/0x500 [ 57.336410] ? preempt_count_sub+0x50/0x80 [ 57.336656] ? _raw_read_unlock+0x20/0x40 [ 57.336906] ? start_this_handle+0x16c/0x500 [ 57.337162] ocfs2_xattr_block_set+0xa6/0x1e0 [ 57.337424] __ocfs2_xattr_set_handle+0x1fd/0x5d0 [ 57.337706] ? ocfs2_start_trans+0x13d/0x290 [ 57.337971] ocfs2_xattr_set+0xb13/0xfb0 [ 57.338207] ? dput+0x46/0x1c0 [ 57.338393] ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338665] ? ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338948] __vfs_removexattr+0x92/0xc0 [ 57.339182] __vfs_removexattr_locked+0xd5/0x190 [ 57.339456] ? preempt_count_sub+0x50/0x80 [ 57.339705] vfs_removexattr+0x5f/0x100 [...] Reproducer uses faultinject facility to fail ocfs2_xa_remove() -> ocfs2_xa_value_truncate() with -ENOMEM. In this case the comment mentions that we can return 0 if ocfs2_xa_cleanup_value_truncate() is going to wipe the entry anyway. But the following 'rc' check is wrong and execution flow do 'ocfs2_xa_remove_entry(loc);' twice: * 1st: in ocfs2_xa_cleanup_value_truncate(); * 2nd: returning back to ocfs2_xa_remove() instead of going to 'out'. Fix this by skipping the 2nd removal of the same entry and making syzkaller repro happy.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50266", "url": "https://ubuntu.com/security/CVE-2024-50266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: qcom: videocc-sm8350: use HW_CTRL_TRIGGER for vcodec GDSCs A recent change in the venus driver results in a stuck clock on the Lenovo ThinkPad X13s, for example, when streaming video in firefox: \tvideo_cc_mvs0_clk status stuck at 'off' \tWARNING: CPU: 6 PID: 2885 at drivers/clk/qcom/clk-branch.c:87 clk_branch_wait+0x144/0x15c \t... \tCall trace: \t clk_branch_wait+0x144/0x15c \t clk_branch2_enable+0x30/0x40 \t clk_core_enable+0xd8/0x29c \t clk_enable+0x2c/0x4c \t vcodec_clks_enable.isra.0+0x94/0xd8 [venus_core] \t coreid_power_v4+0x464/0x628 [venus_core] \t vdec_start_streaming+0xc4/0x510 [venus_dec] \t vb2_start_streaming+0x6c/0x180 [videobuf2_common] \t vb2_core_streamon+0x120/0x1dc [videobuf2_common] \t vb2_streamon+0x1c/0x6c [videobuf2_v4l2] \t v4l2_m2m_ioctl_streamon+0x30/0x80 [v4l2_mem2mem] \t v4l_streamon+0x24/0x30 [videodev] using the out-of-tree sm8350/sc8280xp venus support. [1] Update also the sm8350/sc8280xp GDSC definitions so that the hw control mode can be changed at runtime as the venus driver now requires.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50267", "url": "https://ubuntu.com/security/CVE-2024-50267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: fix use after free in debug printk The \"dev_dbg(&urb->dev->dev, ...\" which happens after usb_free_urb(urb) is a use after free of the \"urb\" pointer. Store the \"dev\" pointer at the start of the function to avoid this issue.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50268", "url": "https://ubuntu.com/security/CVE-2024-50268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: fix potential out of bounds in ucsi_ccg_update_set_new_cam_cmd() The \"*cmd\" variable can be controlled by the user via debugfs. That means \"new_cam\" can be as high as 255 while the size of the uc->updated[] array is UCSI_MAX_ALTMODES (30). The call tree is: ucsi_cmd() // val comes from simple_attr_write_xsigned() -> ucsi_send_command() -> ucsi_send_command_common() -> ucsi_run_command() // calls ucsi->ops->sync_control() -> ucsi_ccg_sync_control()", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53083", "url": "https://ubuntu.com/security/CVE-2024-53083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: qcom-pmic: init value of hdr_len/txbuf_len earlier If the read of USB_PDPHY_RX_ACKNOWLEDGE_REG failed, then hdr_len and txbuf_len are uninitialized. This commit stops to print uninitialized value and misleading/false data.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50269", "url": "https://ubuntu.com/security/CVE-2024-50269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: musb: sunxi: Fix accessing an released usb phy Commit 6ed05c68cbca (\"usb: musb: sunxi: Explicitly release USB PHY on exit\") will cause that usb phy @glue->xceiv is accessed after released. 1) register platform driver @sunxi_musb_driver // get the usb phy @glue->xceiv sunxi_musb_probe() -> devm_usb_get_phy(). 2) register and unregister platform driver @musb_driver musb_probe() -> sunxi_musb_init() use the phy here //the phy is released here musb_remove() -> sunxi_musb_exit() -> devm_usb_put_phy() 3) register @musb_driver again musb_probe() -> sunxi_musb_init() use the phy here but the phy has been released at 2). ... Fixed by reverting the commit, namely, removing devm_usb_put_phy() from sunxi_musb_exit().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53079", "url": "https://ubuntu.com/security/CVE-2024-53079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/thp: fix deferred split unqueue naming and locking Recent changes are putting more pressure on THP deferred split queues: under load revealing long-standing races, causing list_del corruptions, \"Bad page state\"s and worse (I keep BUGs in both of those, so usually don't get to see how badly they end up without). The relevant recent changes being 6.8's mTHP, 6.10's mTHP swapout, and 6.12's mTHP swapin, improved swap allocation, and underused THP splitting. Before fixing locking: rename misleading folio_undo_large_rmappable(), which does not undo large_rmappable, to folio_unqueue_deferred_split(), which is what it does. But that and its out-of-line __callee are mm internals of very limited usability: add comment and WARN_ON_ONCEs to check usage; and return a bool to say if a deferred split was unqueued, which can then be used in WARN_ON_ONCEs around safety checks (sparing callers the arcane conditionals in __folio_unqueue_deferred_split()). Just omit the folio_unqueue_deferred_split() from free_unref_folios(), all of whose callers now call it beforehand (and if any forget then bad_page() will tell) - except for its caller put_pages_list(), which itself no longer has any callers (and will be deleted separately). Swapout: mem_cgroup_swapout() has been resetting folio->memcg_data 0 without checking and unqueueing a THP folio from deferred split list; which is unfortunate, since the split_queue_lock depends on the memcg (when memcg is enabled); so swapout has been unqueueing such THPs later, when freeing the folio, using the pgdat's lock instead: potentially corrupting the memcg's list. __remove_mapping() has frozen refcount to 0 here, so no problem with calling folio_unqueue_deferred_split() before resetting memcg_data. That goes back to 5.4 commit 87eaceb3faa5 (\"mm: thp: make deferred split shrinker memcg aware\"): which included a check on swapcache before adding to deferred queue, but no check on deferred queue before adding THP to swapcache. That worked fine with the usual sequence of events in reclaim (though there were a couple of rare ways in which a THP on deferred queue could have been swapped out), but 6.12 commit dafff3f4c850 (\"mm: split underused THPs\") avoids splitting underused THPs in reclaim, which makes swapcache THPs on deferred queue commonplace. Keep the check on swapcache before adding to deferred queue? Yes: it is no longer essential, but preserves the existing behaviour, and is likely to be a worthwhile optimization (vmstat showed much more traffic on the queue under swapping load if the check was removed); update its comment. Memcg-v1 move (deprecated): mem_cgroup_move_account() has been changing folio->memcg_data without checking and unqueueing a THP folio from the deferred list, sometimes corrupting \"from\" memcg's list, like swapout. Refcount is non-zero here, so folio_unqueue_deferred_split() can only be used in a WARN_ON_ONCE to validate the fix, which must be done earlier: mem_cgroup_move_charge_pte_range() first try to split the THP (splitting of course unqueues), or skip it if that fails. Not ideal, but moving charge has been requested, and khugepaged should repair the THP later: nobody wants new custom unqueueing code just for this deprecated case. The 87eaceb3faa5 commit did have the code to move from one deferred list to another (but was not conscious of its unsafety while refcount non-0); but that was removed by 5.6 commit fac0516b5534 (\"mm: thp: don't need care deferred split queue in memcg charge move path\"), which argued that the existence of a PMD mapping guarantees that the THP cannot be on a deferred list. As above, false in rare cases, and now commonly false. Backport to 6.11 should be straightforward. Earlier backports must take care that other _deferred_list fixes and dependencies are included. There is not a strong case for backports, but they can fix cornercases.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50270", "url": "https://ubuntu.com/security/CVE-2024-50270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: avoid overflow in damon_feed_loop_next_input() damon_feed_loop_next_input() is inefficient and fragile to overflows. Specifically, 'score_goal_diff_bp' calculation can overflow when 'score' is high. The calculation is actually unnecessary at all because 'goal' is a constant of value 10,000. Calculation of 'compensation' is again fragile to overflow. Final calculation of return value for under-achiving case is again fragile to overflow when the current score is under-achieving the target. Add two corner cases handling at the beginning of the function to make the body easier to read, and rewrite the body of the function to avoid overflows and the unnecessary bp value calcuation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50271", "url": "https://ubuntu.com/security/CVE-2024-50271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: signal: restore the override_rlimit logic Prior to commit d64696905554 (\"Reimplement RLIMIT_SIGPENDING on top of ucounts\") UCOUNT_RLIMIT_SIGPENDING rlimit was not enforced for a class of signals. However now it's enforced unconditionally, even if override_rlimit is set. This behavior change caused production issues. For example, if the limit is reached and a process receives a SIGSEGV signal, sigqueue_alloc fails to allocate the necessary resources for the signal delivery, preventing the signal from being delivered with siginfo. This prevents the process from correctly identifying the fault address and handling the error. From the user-space perspective, applications are unaware that the limit has been reached and that the siginfo is effectively 'corrupted'. This can lead to unpredictable behavior and crashes, as we observed with java applications. Fix this by passing override_rlimit into inc_rlimit_get_ucounts() and skip the comparison to max there if override_rlimit is set. This effectively restores the old behavior.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50272", "url": "https://ubuntu.com/security/CVE-2024-50272", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: filemap: Fix bounds checking in filemap_read() If the caller supplies an iocb->ki_pos value that is close to the filesystem upper limit, and an iterator with a count that causes us to overflow that limit, then filemap_read() enters an infinite loop. This behaviour was discovered when testing xfstests generic/525 with the \"localio\" optimisation for loopback NFS mounts.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53104", "url": "https://ubuntu.com/security/CVE-2024-53104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_parse_format This can lead to out of bounds writes since frames of this type were not taken into account when calculating the size of the frames buffer in uvc_parse_streaming.", "cve_priority": "high", "cve_public_date": "2024-12-02 08:15:00 UTC" }, { "cve": "CVE-2024-50273", "url": "https://ubuntu.com/security/CVE-2024-50273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reinitialize delayed ref list after deleting it from the list At insert_delayed_ref() if we need to update the action of an existing ref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head's ref_add_list using list_del(), which leaves the ref's add_list member not reinitialized, as list_del() sets the next and prev members of the list to LIST_POISON1 and LIST_POISON2, respectively. If later we end up calling drop_delayed_ref() against the ref, which can happen during merging or when destroying delayed refs due to a transaction abort, we can trigger a crash since at drop_delayed_ref() we call list_empty() against the ref's add_list, which returns false since the list was not reinitialized after the list_del() and as a consequence we call list_del() again at drop_delayed_ref(). This results in an invalid list access since the next and prev members are set to poison pointers, resulting in a splat if CONFIG_LIST_HARDENED and CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences otherwise. So fix this by deleting from the list with list_del_init() instead.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53064", "url": "https://ubuntu.com/security/CVE-2024-53064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix idpf_vc_core_init error path In an event where the platform running the device control plane is rebooted, reset is detected on the driver. It releases all the resources and waits for the reset to complete. Once the reset is done, it tries to build the resources back. At this time if the device control plane is not yet started, then the driver timeouts on the virtchnl message and retries to establish the mailbox again. In the retry flow, mailbox is deinitialized but the mailbox workqueue is still alive and polling for the mailbox message. This results in accessing the released control queue leading to null-ptr-deref. Fix it by unrolling the work queue cancellation and mailbox deinitialization in the reverse order which they got initialized.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50274", "url": "https://ubuntu.com/security/CVE-2024-50274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: avoid vport access in idpf_get_link_ksettings When the device control plane is removed or the platform running device control plane is rebooted, a reset is detected on the driver. On driver reset, it releases the resources and waits for the reset to complete. If the reset fails, it takes the error path and releases the vport lock. At this time if the monitoring tools tries to access link settings, it call traces for accessing released vport pointer. To avoid it, move link_speed_mbps to netdev_priv structure which removes the dependency on vport pointer and the vport lock in idpf_get_link_ksettings. Also use netif_carrier_ok() to check the link status and adjust the offsetof to use link_up instead of link_speed_mbps.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53065", "url": "https://ubuntu.com/security/CVE-2024-53065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/slab: fix warning caused by duplicate kmem_cache creation in kmem_buckets_create Commit b035f5a6d852 (\"mm: slab: reduce the kmalloc() minimum alignment if DMA bouncing possible\") reduced ARCH_KMALLOC_MINALIGN to 8 on arm64. However, with KASAN_HW_TAGS enabled, arch_slab_minalign() becomes 16. This causes kmalloc_caches[*][8] to be aliased to kmalloc_caches[*][16], resulting in kmem_buckets_create() attempting to create a kmem_cache for size 16 twice. This duplication triggers warnings on boot: [ 2.325108] ------------[ cut here ]------------ [ 2.325135] kmem_cache of name 'memdup_user-16' already exists [ 2.325783] WARNING: CPU: 0 PID: 1 at mm/slab_common.c:107 __kmem_cache_create_args+0xb8/0x3b0 [ 2.327957] Modules linked in: [ 2.328550] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5mm-unstable-arm64+ #12 [ 2.328683] Hardware name: QEMU QEMU Virtual Machine, BIOS 2024.02-2 03/11/2024 [ 2.328790] pstate: 61000009 (nZCv daif -PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 2.328911] pc : __kmem_cache_create_args+0xb8/0x3b0 [ 2.328930] lr : __kmem_cache_create_args+0xb8/0x3b0 [ 2.328942] sp : ffff800083d6fc50 [ 2.328961] x29: ffff800083d6fc50 x28: f2ff0000c1674410 x27: ffff8000820b0598 [ 2.329061] x26: 000000007fffffff x25: 0000000000000010 x24: 0000000000002000 [ 2.329101] x23: ffff800083d6fce8 x22: ffff8000832222e8 x21: ffff800083222388 [ 2.329118] x20: f2ff0000c1674410 x19: f5ff0000c16364c0 x18: ffff800083d80030 [ 2.329135] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 2.329152] x14: 0000000000000000 x13: 0a73747369786520 x12: 79646165726c6120 [ 2.329169] x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : 0000000000000000 [ 2.329194] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 [ 2.329210] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 2.329226] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 2.329291] Call trace: [ 2.329407] __kmem_cache_create_args+0xb8/0x3b0 [ 2.329499] kmem_buckets_create+0xfc/0x320 [ 2.329526] init_user_buckets+0x34/0x78 [ 2.329540] do_one_initcall+0x64/0x3c8 [ 2.329550] kernel_init_freeable+0x26c/0x578 [ 2.329562] kernel_init+0x3c/0x258 [ 2.329574] ret_from_fork+0x10/0x20 [ 2.329698] ---[ end trace 0000000000000000 ]--- [ 2.403704] ------------[ cut here ]------------ [ 2.404716] kmem_cache of name 'msg_msg-16' already exists [ 2.404801] WARNING: CPU: 2 PID: 1 at mm/slab_common.c:107 __kmem_cache_create_args+0xb8/0x3b0 [ 2.404842] Modules linked in: [ 2.404971] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.12.0-rc5mm-unstable-arm64+ #12 [ 2.405026] Tainted: [W]=WARN [ 2.405043] Hardware name: QEMU QEMU Virtual Machine, BIOS 2024.02-2 03/11/2024 [ 2.405057] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2.405079] pc : __kmem_cache_create_args+0xb8/0x3b0 [ 2.405100] lr : __kmem_cache_create_args+0xb8/0x3b0 [ 2.405111] sp : ffff800083d6fc50 [ 2.405115] x29: ffff800083d6fc50 x28: fbff0000c1674410 x27: ffff8000820b0598 [ 2.405135] x26: 000000000000ffd0 x25: 0000000000000010 x24: 0000000000006000 [ 2.405153] x23: ffff800083d6fce8 x22: ffff8000832222e8 x21: ffff800083222388 [ 2.405169] x20: fbff0000c1674410 x19: fdff0000c163d6c0 x18: ffff800083d80030 [ 2.405185] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 2.405201] x14: 0000000000000000 x13: 0a73747369786520 x12: 79646165726c6120 [ 2.405217] x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : 0000000000000000 [ 2.405233] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 [ 2.405248] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 2.405271] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 2.405287] Call trace: [ 2 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50275", "url": "https://ubuntu.com/security/CVE-2024-50275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64/sve: Discard stale CPU state when handling SVE traps The logic for handling SVE traps manipulates saved FPSIMD/SVE state incorrectly, and a race with preemption can result in a task having TIF_SVE set and TIF_FOREIGN_FPSTATE clear even though the live CPU state is stale (e.g. with SVE traps enabled). This has been observed to result in warnings from do_sve_acc() where SVE traps are not expected while TIF_SVE is set: | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* SVE access shouldn't have trapped */ Warnings of this form have been reported intermittently, e.g. https://lore.kernel.org/linux-arm-kernel/CA+G9fYtEGe_DhY2Ms7+L7NKsLYUomGsgqpdBj+QwDLeSg=JhGg@mail.gmail.com/ https://lore.kernel.org/linux-arm-kernel/000000000000511e9a060ce5a45c@google.com/ The race can occur when the SVE trap handler is preempted before and after manipulating the saved FPSIMD/SVE state, starting and ending on the same CPU, e.g. | void do_sve_acc(unsigned long esr, struct pt_regs *regs) | { | // Trap on CPU 0 with TIF_SVE clear, SVE 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(); | | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* SVE access shouldn't have trapped */ | | sve_init_regs() { | if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) { | ... | } else { | fpsimd_to_sve(current); | current->thread.fp_type = FP_STATE_SVE; | } | } | | 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 SVE 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.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50276", "url": "https://ubuntu.com/security/CVE-2024-50276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: vertexcom: mse102x: Fix possible double free of TX skb The scope of the TX skb is wider than just mse102x_tx_frame_spi(), so in case the TX skb room needs to be expanded, we should free the the temporary skb instead of the original skb. Otherwise the original TX skb pointer would be freed again in mse102x_tx_work(), which leads to crashes: Internal error: Oops: 0000000096000004 [#2] PREEMPT SMP CPU: 0 PID: 712 Comm: kworker/0:1 Tainted: G D 6.6.23 Hardware name: chargebyte Charge SOM DC-ONE (DT) Workqueue: events mse102x_tx_work [mse102x] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_release_data+0xb8/0x1d8 lr : skb_release_data+0x1ac/0x1d8 sp : ffff8000819a3cc0 x29: ffff8000819a3cc0 x28: ffff0000046daa60 x27: ffff0000057f2dc0 x26: ffff000005386c00 x25: 0000000000000002 x24: 00000000ffffffff x23: 0000000000000000 x22: 0000000000000001 x21: ffff0000057f2e50 x20: 0000000000000006 x19: 0000000000000000 x18: ffff00003fdacfcc x17: e69ad452d0c49def x16: 84a005feff870102 x15: 0000000000000000 x14: 000000000000024a x13: 0000000000000002 x12: 0000000000000000 x11: 0000000000000400 x10: 0000000000000930 x9 : ffff00003fd913e8 x8 : fffffc00001bc008 x7 : 0000000000000000 x6 : 0000000000000008 x5 : ffff00003fd91340 x4 : 0000000000000000 x3 : 0000000000000009 x2 : 00000000fffffffe x1 : 0000000000000000 x0 : 0000000000000000 Call trace: skb_release_data+0xb8/0x1d8 kfree_skb_reason+0x48/0xb0 mse102x_tx_work+0x164/0x35c [mse102x] process_one_work+0x138/0x260 worker_thread+0x32c/0x438 kthread+0x118/0x11c ret_from_fork+0x10/0x20 Code: aa1303e0 97fffab6 72001c1f 54000141 (f9400660)", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53066", "url": "https://ubuntu.com/security/CVE-2024-53066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfs: Fix KMSAN warning in decode_getfattr_attrs() Fix the following KMSAN warning: CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G B Tainted: [B]=BAD_PAGE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) ===================================================== ===================================================== BUG: KMSAN: uninit-value in decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_generic+0x806/0xb00 nfs4_xdr_dec_getattr+0x1de/0x240 rpcauth_unwrap_resp_decode+0xab/0x100 rpcauth_unwrap_resp+0x95/0xc0 call_decode+0x4ff/0xb50 __rpc_execute+0x57b/0x19d0 rpc_execute+0x368/0x5e0 rpc_run_task+0xcfe/0xee0 nfs4_proc_getattr+0x5b5/0x990 __nfs_revalidate_inode+0x477/0xd00 nfs_access_get_cached+0x1021/0x1cc0 nfs_do_access+0x9f/0xae0 nfs_permission+0x1e4/0x8c0 inode_permission+0x356/0x6c0 link_path_walk+0x958/0x1330 path_lookupat+0xce/0x6b0 filename_lookup+0x23e/0x770 vfs_statx+0xe7/0x970 vfs_fstatat+0x1f2/0x2c0 __se_sys_newfstatat+0x67/0x880 __x64_sys_newfstatat+0xbd/0x120 x64_sys_call+0x1826/0x3cf0 do_syscall_64+0xd0/0x1b0 entry_SYSCALL_64_after_hwframe+0x77/0x7f The KMSAN warning is triggered in decode_getfattr_attrs(), when calling decode_attr_mdsthreshold(). It appears that fattr->mdsthreshold is not initialized. Fix the issue by initializing fattr->mdsthreshold to NULL in nfs_fattr_init().", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53067", "url": "https://ubuntu.com/security/CVE-2024-53067", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Start the RTC update work later The RTC update work involves runtime resuming the UFS controller. Hence, only start the RTC update work after runtime power management in the UFS driver has been fully initialized. This patch fixes the following kernel crash: Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP Workqueue: events ufshcd_rtc_work Call trace: _raw_spin_lock_irqsave+0x34/0x8c (P) pm_runtime_get_if_active+0x24/0x9c (L) pm_runtime_get_if_active+0x24/0x9c ufshcd_rtc_work+0x138/0x1b4 process_one_work+0x148/0x288 worker_thread+0x2cc/0x3d4 kthread+0x110/0x114 ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50277", "url": "https://ubuntu.com/security/CVE-2024-50277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: fix a crash if blk_alloc_disk fails If blk_alloc_disk fails, the variable md->disk is set to an error value. cleanup_mapped_device will see that md->disk is non-NULL and it will attempt to access it, causing a crash on this statement \"md->disk->private_data = NULL;\".", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50278", "url": "https://ubuntu.com/security/CVE-2024-50278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix potential out-of-bounds access on the first resume Out-of-bounds access occurs if the fast device is expanded unexpectedly before the first-time resume of the cache table. This happens because expanding the fast device requires reloading the cache table for cache_create to allocate new in-core data structures that fit the new size, and the check in cache_preresume is not performed during the first resume, leading to the issue. Reproduce steps: 1. prepare component devices: 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\" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct 2. load a cache table of 512 cache blocks, and deliberately expand the fast device before resuming the cache, making the in-core data structures inadequate. dmsetup create cache --notable dmsetup reload cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" dmsetup reload cdata --table \"0 131072 linear /dev/sdc 8192\" dmsetup resume cdata dmsetup resume cache 3. suspend the cache to write out the in-core dirty bitset and hint array, leading to out-of-bounds access to the dirty bitset at offset 0x40: dmsetup suspend cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80 Read of size 8 at addr ffffc90000085040 by task dmsetup/90 (...snip...) The buggy address belongs to the virtual mapping at [ffffc90000085000, ffffc90000087000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by checking the size change on the first resume.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50279", "url": "https://ubuntu.com/security/CVE-2024-50279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix out-of-bounds access to the dirty bitset when resizing dm-cache checks the dirty bits of the cache blocks to be dropped when shrinking the fast device, but an index bug in bitset iteration causes out-of-bounds access. Reproduce steps: 1. create a cache device of 1024 cache blocks (128 bytes dirty bitset) dmsetup create cmeta --table \"0 8192 linear /dev/sdc 0\" dmsetup create cdata --table \"0 131072 linear /dev/sdc 8192\" dmsetup create corig --table \"0 524288 linear /dev/sdc 262144\" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" 2. shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80) dmsetup suspend cache dmsetup reload cdata --table \"0 65536 linear /dev/sdc 8192\" dmsetup resume cdata dmsetup resume cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131 (...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by making the index post-incremented.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50280", "url": "https://ubuntu.com/security/CVE-2024-50280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix flushing uninitialized delayed_work on cache_ctr error An unexpected WARN_ON from flush_work() may occur when cache creation fails, caused by destroying the uninitialized delayed_work waker in the error path of cache_create(). For example, the warning appears on the superblock checksum error. Reproduce steps: 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\" dd if=/dev/urandom of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" Kernel logs: (snip) WARNING: CPU: 0 PID: 84 at kernel/workqueue.c:4178 __flush_work+0x5d4/0x890 Fix by pulling out the cancel_delayed_work_sync() from the constructor's error path. This patch doesn't affect the use-after-free fix for concurrent dm_resume and dm_destroy (commit 6a459d8edbdb (\"dm cache: Fix UAF in destroy()\")) as cache_dtr is not changed.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50281", "url": "https://ubuntu.com/security/CVE-2024-50281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: trusted: dcp: fix NULL dereference in AEAD crypto operation When sealing or unsealing a key blob we currently do not wait for the AEAD cipher operation to finish and simply return after submitting the request. If there is some load on the system we can exit before the cipher operation is done and the buffer we read from/write to is already removed from the stack. This will e.g. result in NULL pointer dereference errors in the DCP driver during blob creation. Fix this by waiting for the AEAD cipher operation to finish before resuming the seal and unseal calls.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50282", "url": "https://ubuntu.com/security/CVE-2024-50282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read() Avoid a possible buffer overflow if size is larger than 4K. (cherry picked from commit f5d873f5825b40d886d03bd2aede91d4cf002434)", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53071", "url": "https://ubuntu.com/security/CVE-2024-53071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Be stricter about IO mapping flags The current panthor_device_mmap_io() implementation has two issues: 1. For mapping DRM_PANTHOR_USER_FLUSH_ID_MMIO_OFFSET, panthor_device_mmap_io() bails if VM_WRITE is set, but does not clear VM_MAYWRITE. That means userspace can use mprotect() to make the mapping writable later on. This is a classic Linux driver gotcha. I don't think this actually has any impact in practice: When the GPU is powered, writes to the FLUSH_ID seem to be ignored; and when the GPU is not powered, the dummy_latest_flush page provided by the driver is deliberately designed to not do any flushes, so the only thing writing to the dummy_latest_flush could achieve would be to make *more* flushes happen. 2. panthor_device_mmap_io() does not block MAP_PRIVATE mappings (which are mappings without the VM_SHARED flag). MAP_PRIVATE in combination with VM_MAYWRITE indicates that the VMA has copy-on-write semantics, which for VM_PFNMAP are semi-supported but fairly cursed. In particular, in such a mapping, the driver can only install PTEs during mmap() by calling remap_pfn_range() (because remap_pfn_range() wants to **store the physical address of the mapped physical memory into the vm_pgoff of the VMA**); installing PTEs later on with a fault handler (as panthor does) is not supported in private mappings, and so if you try to fault in such a mapping, vmf_insert_pfn_prot() splats when it hits a BUG() check. Fix it by clearing the VM_MAYWRITE flag (userspace writing to the FLUSH_ID doesn't make sense) and requiring VM_SHARED (copy-on-write semantics for the FLUSH_ID don't make sense). Reproducers for both scenarios are in the notes of my patch on the mailing list; I tested that these bugs exist on a Rock 5B machine. Note that I only compile-tested the patch, I haven't tested it; I don't have a working kernel build setup for the test machine yet. Please test it before applying it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53080", "url": "https://ubuntu.com/security/CVE-2024-53080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Lock XArray when getting entries for the VM Similar to commit cac075706f29 (\"drm/panthor: Fix race when converting group handle to group object\") we need to use the XArray's internal locking when retrieving a vm pointer from there. v2: Removed part of the patch that was trying to protect fetching the heap pointer from XArray, as that operation is protected by the @pool->lock.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53084", "url": "https://ubuntu.com/security/CVE-2024-53084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Break an object reference loop When remaining resources are being cleaned up on driver close, outstanding VM mappings may result in resources being leaked, due to an object reference loop, as shown below, with each object (or set of objects) referencing the object below it: PVR GEM Object GPU scheduler \"finished\" fence GPU scheduler “scheduled” fence PVR driver “done” fence PVR Context PVR VM Context PVR VM Mappings PVR GEM Object The reference that the PVR VM Context has on the VM mappings is a soft one, in the sense that the freeing of outstanding VM mappings is done as part of VM context destruction; no reference counts are involved, as is the case for all the other references in the loop. To break the reference loop during cleanup, free the outstanding VM mappings before destroying the PVR Context associated with the VM context.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53085", "url": "https://ubuntu.com/security/CVE-2024-53085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: Lock TPM chip in tpm_pm_suspend() first Setting TPM_CHIP_FLAG_SUSPENDED in the end of tpm_pm_suspend() can be racy according, as this leaves window for tpm_hwrng_read() to be called while the operation is in progress. The recent bug report gives also evidence of this behaviour. Aadress this by locking the TPM chip before checking any chip->flags both in tpm_pm_suspend() and tpm_hwrng_read(). Move TPM_CHIP_FLAG_SUSPENDED check inside tpm_get_random() so that it will be always checked only when the lock is reserved.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53086", "url": "https://ubuntu.com/security/CVE-2024-53086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Drop VM dma-resv lock on xe_sync_in_fence_get failure in exec IOCTL Upon failure all locks need to be dropped before returning to the user. (cherry picked from commit 7d1a4258e602ffdce529f56686925034c1b3b095)", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53087", "url": "https://ubuntu.com/security/CVE-2024-53087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix possible exec queue leak in exec IOCTL In a couple of places after an exec queue is looked up the exec IOCTL returns on input errors without dropping the exec queue ref. Fix this ensuring the exec queue ref is dropped on input error. (cherry picked from commit 07064a200b40ac2195cb6b7b779897d9377e5e6f)", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50283", "url": "https://ubuntu.com/security/CVE-2024-50283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-use-after-free in smb3_preauth_hash_rsp ksmbd_user_session_put should be called under smb3_preauth_hash_rsp(). It will avoid freeing session before calling smb3_preauth_hash_rsp().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50284", "url": "https://ubuntu.com/security/CVE-2024-50284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix the missing xa_store error check xa_store() can fail, it return xa_err(-EINVAL) if the entry cannot be stored in an XArray, or xa_err(-ENOMEM) if memory allocation failed, so check error for xa_store() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50285", "url": "https://ubuntu.com/security/CVE-2024-50285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: check outstanding simultaneous SMB operations If Client send simultaneous SMB operations to ksmbd, It exhausts too much memory through the \"ksmbd_work_cache”. It will cause OOM issue. ksmbd has a credit mechanism but it can't handle this problem. This patch add the check if it exceeds max credits to prevent this problem by assuming that one smb request consumes at least one credit.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50286", "url": "https://ubuntu.com/security/CVE-2024-50286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-use-after-free in ksmbd_smb2_session_create There is a race condition between ksmbd_smb2_session_create and ksmbd_expire_session. This patch add missing sessions_table_lock while adding/deleting session from global session table.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50287", "url": "https://ubuntu.com/security/CVE-2024-50287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-tpg: prevent the risk of a division by zero As reported by Coverity, the logic at tpg_precalculate_line() blindly rescales the buffer even when scaled_witdh is equal to zero. If this ever happens, this will cause a division by zero. Instead, add a WARN_ON_ONCE() to trigger such cases and return without doing any precalculation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50288", "url": "https://ubuntu.com/security/CVE-2024-50288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: fix buffer overwrite when using > 32 buffers The maximum number of buffers that can be requested was increased to 64 for the video capture queue. But video capture used a must_blank array that was still sized for 32 (VIDEO_MAX_FRAME). This caused an out-of-bounds write when using buffer indices >= 32. Create a new define MAX_VID_CAP_BUFFERS that is used to access the must_blank array and set max_num_buffers for the video capture queue. This solves a crash reported by: \thttps://bugzilla.kernel.org/show_bug.cgi?id=219258", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50289", "url": "https://ubuntu.com/security/CVE-2024-50289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: av7110: fix a spectre vulnerability As warned by smatch: \tdrivers/staging/media/av7110/av7110_ca.c:270 dvb_ca_ioctl() warn: potential spectre issue 'av7110->ci_slot' [w] (local cap) There is a spectre-related vulnerability at the code. Fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50290", "url": "https://ubuntu.com/security/CVE-2024-50290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx24116: prevent overflows on SNR calculus as reported by Coverity, if reading SNR registers fail, a negative number will be returned, causing an underflow when reading SNR registers. Prevent that.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53061", "url": "https://ubuntu.com/security/CVE-2024-53061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: s5p-jpeg: prevent buffer overflows The current logic allows word to be less than 2. If this happens, there will be buffer overflows, as reported by smatch. Add extra checks to prevent it. While here, remove an unused word = 0 assignment.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53081", "url": "https://ubuntu.com/security/CVE-2024-53081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ar0521: don't overflow when checking PLL values The PLL checks are comparing 64 bit integers with 32 bit ones, as reported by Coverity. Depending on the values of the variables, this may underflow. Fix it ensuring that both sides of the expression are u64.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53062", "url": "https://ubuntu.com/security/CVE-2024-53062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mgb4: protect driver against spectre Frequency range is set from sysfs via frequency_range_store(), being vulnerable to spectre, as reported by smatch: \tdrivers/media/pci/mgb4/mgb4_cmt.c:231 mgb4_cmt_set_vin_freq_range() warn: potential spectre issue 'cmt_vals_in' [r] \tdrivers/media/pci/mgb4/mgb4_cmt.c:238 mgb4_cmt_set_vin_freq_range() warn: possible spectre second half. 'reg_set' Fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50291", "url": "https://ubuntu.com/security/CVE-2024-50291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvb-core: add missing buffer index check dvb_vb2_expbuf() didn't check if the given buffer index was for a valid buffer. Add this check.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50292", "url": "https://ubuntu.com/security/CVE-2024-50292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: stm32: spdifrx: fix dma channel release in stm32_spdifrx_remove In case of error when requesting ctrl_chan DMA channel, ctrl_chan is not null. So the release of the dma channel leads to the following issue: [ 4.879000] st,stm32-spdifrx 500d0000.audio-controller: dma_request_slave_channel error -19 [ 4.888975] Unable to handle kernel NULL pointer dereference at virtual address 000000000000003d [...] [ 5.096577] Call trace: [ 5.099099] dma_release_channel+0x24/0x100 [ 5.103235] stm32_spdifrx_remove+0x24/0x60 [snd_soc_stm32_spdifrx] [ 5.109494] stm32_spdifrx_probe+0x320/0x4c4 [snd_soc_stm32_spdifrx] To avoid this issue, release channel only if the pointer is valid.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53063", "url": "https://ubuntu.com/security/CVE-2024-53063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvbdev: prevent the risk of out of memory access The dvbdev contains a static variable used to store dvb minors. The behavior of it depends if CONFIG_DVB_DYNAMIC_MINORS is set or not. When not set, dvb_register_device() won't check for boundaries, as it will rely that a previous call to dvb_register_adapter() would already be enforcing it. On a similar way, dvb_device_open() uses the assumption that the register functions already did the needed checks. This can be fragile if some device ends using different calls. This also generate warnings on static check analysers like Coverity. So, add explicit guards to prevent potential risk of OOM issues.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50293", "url": "https://ubuntu.com/security/CVE-2024-50293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: do not leave a dangling sk pointer in __smc_create() Thanks to commit 4bbd360a5084 (\"socket: Print pf->create() when it does not clear sock->sk on failure.\"), syzbot found an issue with AF_SMC: smc_create must clear sock->sk on failure, family: 43, type: 1, protocol: 0 WARNING: CPU: 0 PID: 5827 at net/socket.c:1565 __sock_create+0x96f/0xa30 net/socket.c:1563 Modules linked in: CPU: 0 UID: 0 PID: 5827 Comm: syz-executor259 Not tainted 6.12.0-rc6-next-20241106-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:__sock_create+0x96f/0xa30 net/socket.c:1563 Code: 03 00 74 08 4c 89 e7 e8 4f 3b 85 f8 49 8b 34 24 48 c7 c7 40 89 0c 8d 8b 54 24 04 8b 4c 24 0c 44 8b 44 24 08 e8 32 78 db f7 90 <0f> 0b 90 90 e9 d3 fd ff ff 89 e9 80 e1 07 fe c1 38 c1 0f 8c ee f7 RSP: 0018:ffffc90003e4fda0 EFLAGS: 00010246 RAX: 099c6f938c7f4700 RBX: 1ffffffff1a595fd RCX: ffff888034823c00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 00000000ffffffe9 R08: ffffffff81567052 R09: 1ffff920007c9f50 R10: dffffc0000000000 R11: fffff520007c9f51 R12: ffffffff8d2cafe8 R13: 1ffffffff1a595fe R14: ffffffff9a789c40 R15: ffff8880764298c0 FS: 000055557b518380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa62ff43225 CR3: 0000000031628000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: sock_create net/socket.c:1616 [inline] __sys_socket_create net/socket.c:1653 [inline] __sys_socket+0x150/0x3c0 net/socket.c:1700 __do_sys_socket net/socket.c:1714 [inline] __se_sys_socket net/socket.c:1712 [inline] For reference, see commit 2d859aff775d (\"Merge branch 'do-not-leave-dangling-sk-pointers-in-pf-create-functions'\")", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50294", "url": "https://ubuntu.com/security/CVE-2024-50294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix missing locking causing hanging calls If a call gets aborted (e.g. because kafs saw a signal) between it being queued for connection and the I/O thread picking up the call, the abort will be prioritised over the connection and it will be removed from local->new_client_calls by rxrpc_disconnect_client_call() without a lock being held. This may cause other calls on the list to disappear if a race occurs. Fix this by taking the client_call_lock when removing a call from whatever list its ->wait_link happens to be on.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50295", "url": "https://ubuntu.com/security/CVE-2024-50295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: arc: fix the device for dma_map_single/dma_unmap_single The ndev->dev and pdev->dev aren't the same device, use ndev->dev.parent which has dma_mask, ndev->dev.parent is just pdev->dev. Or it would cause the following issue: [ 39.933526] ------------[ cut here ]------------ [ 39.938414] WARNING: CPU: 1 PID: 501 at kernel/dma/mapping.c:149 dma_map_page_attrs+0x90/0x1f8", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53082", "url": "https://ubuntu.com/security/CVE-2024-53082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_net: Add hash_key_length check Add hash_key_length check in virtnet_probe() to avoid possible out of bound errors when setting/reading the hash key.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50296", "url": "https://ubuntu.com/security/CVE-2024-50296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash when uninstalling driver When the driver is uninstalled and the VF is disabled concurrently, a kernel crash occurs. The reason is that the two actions call function pci_disable_sriov(). The num_VFs is checked to determine whether to release the corresponding resources. During the second calling, num_VFs is not 0 and the resource release function is called. However, the corresponding resource has been released during the first invoking. Therefore, the problem occurs: [15277.839633][T50670] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ... [15278.131557][T50670] Call trace: [15278.134686][T50670] klist_put+0x28/0x12c [15278.138682][T50670] klist_del+0x14/0x20 [15278.142592][T50670] device_del+0xbc/0x3c0 [15278.146676][T50670] pci_remove_bus_device+0x84/0x120 [15278.151714][T50670] pci_stop_and_remove_bus_device+0x6c/0x80 [15278.157447][T50670] pci_iov_remove_virtfn+0xb4/0x12c [15278.162485][T50670] sriov_disable+0x50/0x11c [15278.166829][T50670] pci_disable_sriov+0x24/0x30 [15278.171433][T50670] hnae3_unregister_ae_algo_prepare+0x60/0x90 [hnae3] [15278.178039][T50670] hclge_exit+0x28/0xd0 [hclge] [15278.182730][T50670] __se_sys_delete_module.isra.0+0x164/0x230 [15278.188550][T50670] __arm64_sys_delete_module+0x1c/0x30 [15278.193848][T50670] invoke_syscall+0x50/0x11c [15278.198278][T50670] el0_svc_common.constprop.0+0x158/0x164 [15278.203837][T50670] do_el0_svc+0x34/0xcc [15278.207834][T50670] el0_svc+0x20/0x30 For details, see the following figure. rmmod hclge disable VFs ---------------------------------------------------- hclge_exit() sriov_numvfs_store() ... device_lock() pci_disable_sriov() hns3_pci_sriov_configure() pci_disable_sriov() sriov_disable() sriov_disable() if !num_VFs : if !num_VFs : return; return; sriov_del_vfs() sriov_del_vfs() ... ... klist_put() klist_put() ... ... num_VFs = 0; num_VFs = 0; device_unlock(); In this patch, when driver is removing, we get the device_lock() to protect num_VFs, just like sriov_numvfs_store().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53088", "url": "https://ubuntu.com/security/CVE-2024-53088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: fix race condition by adding filter's intermediate sync state Fix a race condition in the i40e driver that leads to MAC/VLAN filters becoming corrupted and leaking. Address the issue that occurs under heavy load when multiple threads are concurrently modifying MAC/VLAN filters by setting mac and port VLAN. 1. Thread T0 allocates a filter in i40e_add_filter() within i40e_ndo_set_vf_port_vlan(). 2. Thread T1 concurrently frees the filter in __i40e_del_filter() within i40e_ndo_set_vf_mac(). 3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which refers to the already freed filter memory, causing corruption. Reproduction steps: 1. Spawn multiple VFs. 2. Apply a concurrent heavy load by running parallel operations to change MAC addresses on the VFs and change port VLANs on the host. 3. Observe errors in dmesg: \"Error I40E_AQ_RC_ENOSPC adding RX filters on VF XX, \tplease set promiscuous on manually for VF XX\". Exact code for stable reproduction Intel can't open-source now. The fix involves implementing a new intermediate filter state, I40E_FILTER_NEW_SYNC, for the time when a filter is on a tmp_add_list. These filters cannot be deleted from the hash list directly but must be removed using the full process.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50297", "url": "https://ubuntu.com/security/CVE-2024-50297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: xilinx: axienet: Enqueue Tx packets in dql before dmaengine starts Enqueue packets in dql after dma engine starts causes race condition. Tx transfer starts once dma engine is started and may execute dql dequeue in completion before it gets queued. It results in following kernel crash while running iperf stress test: kernel BUG at lib/dynamic_queue_limits.c:99! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP pc : dql_completed+0x238/0x248 lr : dql_completed+0x3c/0x248 Call trace: dql_completed+0x238/0x248 axienet_dma_tx_cb+0xa0/0x170 xilinx_dma_do_tasklet+0xdc/0x290 tasklet_action_common+0xf8/0x11c tasklet_action+0x30/0x3c handle_softirqs+0xf8/0x230 Start dmaengine after enqueue in dql fixes the crash.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50298", "url": "https://ubuntu.com/security/CVE-2024-50298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: enetc: allocate vf_state during PF probes In the previous implementation, vf_state is allocated memory only when VF is enabled. However, net_device_ops::ndo_set_vf_mac() may be called before VF is enabled to configure the MAC address of VF. If this is the case, enetc_pf_set_vf_mac() will access vf_state, resulting in access to a null pointer. The simplified error log is as follows. root@ls1028ardb:~# ip link set eno0 vf 1 mac 00:0c:e7:66:77:89 [ 173.543315] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 [ 173.637254] pc : enetc_pf_set_vf_mac+0x3c/0x80 Message from sy [ 173.641973] lr : do_setlink+0x4a8/0xec8 [ 173.732292] Call trace: [ 173.734740] enetc_pf_set_vf_mac+0x3c/0x80 [ 173.738847] __rtnl_newlink+0x530/0x89c [ 173.742692] rtnl_newlink+0x50/0x7c [ 173.746189] rtnetlink_rcv_msg+0x128/0x390 [ 173.750298] netlink_rcv_skb+0x60/0x130 [ 173.754145] rtnetlink_rcv+0x18/0x24 [ 173.757731] netlink_unicast+0x318/0x380 [ 173.761665] netlink_sendmsg+0x17c/0x3c8", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50299", "url": "https://ubuntu.com/security/CVE-2024-50299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: properly validate chunk size in sctp_sf_ootb() A size validation fix similar to that in Commit 50619dbf8db7 (\"sctp: add size validation when walking chunks\") is also required in sctp_sf_ootb() to address a crash reported by syzbot: BUG: KMSAN: uninit-value in sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_do_sm+0x181/0x93d0 net/sctp/sm_sideeffect.c:1166 sctp_endpoint_bh_rcv+0xc38/0xf90 net/sctp/endpointola.c:407 sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88 sctp_rcv+0x3831/0x3b20 net/sctp/input.c:243 sctp4_rcv+0x42/0x50 net/sctp/protocol.c:1159 ip_protocol_deliver_rcu+0xb51/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50300", "url": "https://ubuntu.com/security/CVE-2024-50300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: rtq2208: Fix uninitialized use of regulator_config Fix rtq2208 driver uninitialized use to cause kernel error.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50301", "url": "https://ubuntu.com/security/CVE-2024-50301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: security/keys: fix slab-out-of-bounds in key_task_permission KASAN reports an out of bounds read: BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline] BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362 CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0x107/0x167 lib/dump_stack.c:123 print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 __kuid_val include/linux/uidgid.h:36 [inline] uid_eq include/linux/uidgid.h:63 [inline] key_task_permission+0x394/0x410 security/keys/permission.c:54 search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793 This issue was also reported by syzbot. It can be reproduced by following these steps(more details [1]): 1. Obtain more than 32 inputs that have similar hashes, which ends with the pattern '0xxxxxxxe6'. 2. Reboot and add the keys obtained in step 1. The reproducer demonstrates how this issue happened: 1. In the search_nested_keyrings function, when it iterates through the slots in a node(below tag ascend_to_node), if the slot pointer is meta and node->back_pointer != NULL(it means a root), it will proceed to descend_to_node. However, there is an exception. If node is the root, and one of the slots points to a shortcut, it will be treated as a keyring. 2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function. However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as ASSOC_ARRAY_PTR_SUBTYPE_MASK. 3. When 32 keys with the similar hashes are added to the tree, the ROOT has keys with hashes that are not similar (e.g. slot 0) and it splits NODE A without using a shortcut. When NODE A is filled with keys that all hashes are xxe6, the keys are similar, NODE A will split with a shortcut. Finally, it forms the tree as shown below, where slot 6 points to a shortcut. NODE A +------>+---+ ROOT | | 0 | xxe6 +---+ | +---+ xxxx | 0 | shortcut : : xxe6 +---+ | +---+ xxe6 : : | | | xxe6 +---+ | +---+ | 6 |---+ : : xxe6 +---+ +---+ xxe6 : : | f | xxe6 +---+ +---+ xxe6 | f | +---+ 4. As mentioned above, If a slot(slot 6) of the root points to a shortcut, it may be mistakenly transferred to a key*, leading to a read out-of-bounds read. To fix this issue, one should jump to descend_to_node if the ptr is a shortcut, regardless of whether the node is root or not. [1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/ [jarkko: tweaked the commit message a bit to have an appropriate closes tag.]", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53072", "url": "https://ubuntu.com/security/CVE-2024-53072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/pmc: Detect when STB is not available Loading the amd_pmc module as: amd_pmc enable_stb=1 ...can result in the following messages in the kernel ring buffer: amd_pmc AMDI0009:00: SMU cmd failed. err: 0xff ioremap on RAM at 0x0000000000000000 - 0x0000000000ffffff WARNING: CPU: 10 PID: 2151 at arch/x86/mm/ioremap.c:217 __ioremap_caller+0x2cd/0x340 Further debugging reveals that this occurs when the requests for S2D_PHYS_ADDR_LOW and S2D_PHYS_ADDR_HIGH return a value of 0, indicating that the STB is inaccessible. To prevent the ioremap warning and provide clarity to the user, handle the invalid address and display an error message.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50302", "url": "https://ubuntu.com/security/CVE-2024-50302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: zero-initialize the report buffer Since the report buffer is used by all kinds of drivers in various ways, let's zero-initialize it during allocation to make sure that it can't be ever used to leak kernel memory via specially-crafted report.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53068", "url": "https://ubuntu.com/security/CVE-2024-53068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix slab-use-after-free in scmi_bus_notifier() The scmi_dev->name is released prematurely in __scmi_device_destroy(), which causes slab-use-after-free when accessing scmi_dev->name in scmi_bus_notifier(). So move the release of scmi_dev->name to scmi_device_release() to avoid slab-use-after-free. | BUG: KASAN: slab-use-after-free in strncmp+0xe4/0xec | Read of size 1 at addr ffffff80a482bcc0 by task swapper/0/1 | | CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.6.38-debug #1 | Hardware name: Qualcomm Technologies, Inc. SA8775P Ride (DT) | Call trace: | dump_backtrace+0x94/0x114 | show_stack+0x18/0x24 | dump_stack_lvl+0x48/0x60 | print_report+0xf4/0x5b0 | kasan_report+0xa4/0xec | __asan_report_load1_noabort+0x20/0x2c | strncmp+0xe4/0xec | scmi_bus_notifier+0x5c/0x54c | notifier_call_chain+0xb4/0x31c | blocking_notifier_call_chain+0x68/0x9c | bus_notify+0x54/0x78 | device_del+0x1bc/0x840 | device_unregister+0x20/0xb4 | __scmi_device_destroy+0xac/0x280 | scmi_device_destroy+0x94/0xd0 | scmi_chan_setup+0x524/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20 | | Allocated by task 1: | kasan_save_stack+0x2c/0x54 | kasan_set_track+0x2c/0x40 | kasan_save_alloc_info+0x24/0x34 | __kasan_kmalloc+0xa0/0xb8 | __kmalloc_node_track_caller+0x6c/0x104 | kstrdup+0x48/0x84 | kstrdup_const+0x34/0x40 | __scmi_device_create.part.0+0x8c/0x408 | scmi_device_create+0x104/0x370 | scmi_chan_setup+0x2a0/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20 | | Freed by task 1: | kasan_save_stack+0x2c/0x54 | kasan_set_track+0x2c/0x40 | kasan_save_free_info+0x38/0x5c | __kasan_slab_free+0xe8/0x164 | __kmem_cache_free+0x11c/0x230 | kfree+0x70/0x130 | kfree_const+0x20/0x40 | __scmi_device_destroy+0x70/0x280 | scmi_device_destroy+0x94/0xd0 | scmi_chan_setup+0x524/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53069", "url": "https://ubuntu.com/security/CVE-2024-53069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: qcom: scm: fix a NULL-pointer dereference Some SCM calls can be invoked with __scm being NULL (the driver may not have been and will not be probed as there's no SCM entry in device-tree). Make sure we don't dereference a NULL pointer.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50212", "url": "https://ubuntu.com/security/CVE-2024-50212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib: alloc_tag_module_unload must wait for pending kfree_rcu calls Ben Greear reports following splat: ------------[ cut here ]------------ net/netfilter/nf_nat_core.c:1114 module nf_nat func:nf_nat_register_fn has 256 allocated at module unload WARNING: CPU: 1 PID: 10421 at lib/alloc_tag.c:168 alloc_tag_module_unload+0x22b/0x3f0 Modules linked in: nf_nat(-) btrfs ufs qnx4 hfsplus hfs minix vfat msdos fat ... Hardware name: Default string Default string/SKYBAY, BIOS 5.12 08/04/2020 RIP: 0010:alloc_tag_module_unload+0x22b/0x3f0 codetag_unload_module+0x19b/0x2a0 ? codetag_load_module+0x80/0x80 nf_nat module exit calls kfree_rcu on those addresses, but the free operation is likely still pending by the time alloc_tag checks for leaks. Wait for outstanding kfree_rcu operations to complete before checking resolves this warning. Reproducer: unshare -n iptables-nft -t nat -A PREROUTING -p tcp grep nf_nat /proc/allocinfo # will list 4 allocations rmmod nft_chain_nat rmmod nf_nat # will WARN. [akpm@linux-foundation.org: add comment]", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53046", "url": "https://ubuntu.com/security/CVE-2024-53046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: dts: imx8ulp: correct the flexspi compatible string The flexspi on imx8ulp only has 16 LUTs, and imx8mm flexspi has 32 LUTs, so correct the compatible string here, otherwise will meet below error: [ 1.119072] ------------[ cut here ]------------ [ 1.123926] WARNING: CPU: 0 PID: 1 at drivers/spi/spi-nxp-fspi.c:855 nxp_fspi_exec_op+0xb04/0xb64 [ 1.133239] Modules linked in: [ 1.136448] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-rc6-next-20240902-00001-g131bf9439dd9 #69 [ 1.146821] Hardware name: NXP i.MX8ULP EVK (DT) [ 1.151647] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.158931] pc : nxp_fspi_exec_op+0xb04/0xb64 [ 1.163496] lr : nxp_fspi_exec_op+0xa34/0xb64 [ 1.168060] sp : ffff80008002b2a0 [ 1.171526] x29: ffff80008002b2d0 x28: 0000000000000000 x27: 0000000000000000 [ 1.179002] x26: ffff2eb645542580 x25: ffff800080610014 x24: ffff800080610000 [ 1.186480] x23: ffff2eb645548080 x22: 0000000000000006 x21: ffff2eb6455425e0 [ 1.193956] x20: 0000000000000000 x19: ffff80008002b5e0 x18: ffffffffffffffff [ 1.201432] x17: ffff2eb644467508 x16: 0000000000000138 x15: 0000000000000002 [ 1.208907] x14: 0000000000000000 x13: ffff2eb6400d8080 x12: 00000000ffffff00 [ 1.216378] x11: 0000000000000000 x10: ffff2eb6400d8080 x9 : ffff2eb697adca80 [ 1.223850] x8 : ffff2eb697ad3cc0 x7 : 0000000100000000 x6 : 0000000000000001 [ 1.231324] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000007a6 [ 1.238795] x2 : 0000000000000000 x1 : 00000000000001ce x0 : 00000000ffffff92 [ 1.246267] Call trace: [ 1.248824] nxp_fspi_exec_op+0xb04/0xb64 [ 1.253031] spi_mem_exec_op+0x3a0/0x430 [ 1.257139] spi_nor_read_id+0x80/0xcc [ 1.261065] spi_nor_scan+0x1ec/0xf10 [ 1.264901] spi_nor_probe+0x108/0x2fc [ 1.268828] spi_mem_probe+0x6c/0xbc [ 1.272574] spi_probe+0x84/0xe4 [ 1.275958] really_probe+0xbc/0x29c [ 1.279713] __driver_probe_device+0x78/0x12c [ 1.284277] driver_probe_device+0xd8/0x15c [ 1.288660] __device_attach_driver+0xb8/0x134 [ 1.293316] bus_for_each_drv+0x88/0xe8 [ 1.297337] __device_attach+0xa0/0x190 [ 1.301353] device_initial_probe+0x14/0x20 [ 1.305734] bus_probe_device+0xac/0xb0 [ 1.309752] device_add+0x5d0/0x790 [ 1.313408] __spi_add_device+0x134/0x204 [ 1.317606] of_register_spi_device+0x3b4/0x590 [ 1.322348] spi_register_controller+0x47c/0x754 [ 1.327181] devm_spi_register_controller+0x4c/0xa4 [ 1.332289] nxp_fspi_probe+0x1cc/0x2b0 [ 1.336307] platform_probe+0x68/0xc4 [ 1.340145] really_probe+0xbc/0x29c [ 1.343893] __driver_probe_device+0x78/0x12c [ 1.348457] driver_probe_device+0xd8/0x15c [ 1.352838] __driver_attach+0x90/0x19c [ 1.356857] bus_for_each_dev+0x7c/0xdc [ 1.360877] driver_attach+0x24/0x30 [ 1.364624] bus_add_driver+0xe4/0x208 [ 1.368552] driver_register+0x5c/0x124 [ 1.372573] __platform_driver_register+0x28/0x34 [ 1.377497] nxp_fspi_driver_init+0x1c/0x28 [ 1.381888] do_one_initcall+0x80/0x1c8 [ 1.385908] kernel_init_freeable+0x1c4/0x28c [ 1.390472] kernel_init+0x20/0x1d8 [ 1.394138] ret_from_fork+0x10/0x20 [ 1.397885] ---[ end trace 0000000000000000 ]--- [ 1.407908] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53052", "url": "https://ubuntu.com/security/CVE-2024-53052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/rw: fix missing NOWAIT check for O_DIRECT start write When io_uring starts a write, it'll call kiocb_start_write() to bump the super block rwsem, preventing any freezes from happening while that write is in-flight. The freeze side will grab that rwsem for writing, excluding any new writers from happening and waiting for existing writes to finish. But io_uring unconditionally uses kiocb_start_write(), which will block if someone is currently attempting to freeze the mount point. This causes a deadlock where freeze is waiting for previous writes to complete, but the previous writes cannot complete, as the task that is supposed to complete them is blocked waiting on starting a new write. This results in the following stuck trace showing that dependency with the write blocked starting a new write: task:fio state:D stack:0 pid:886 tgid:886 ppid:876 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_rwsem_wait+0x1e8/0x3f8 __percpu_down_read+0xe8/0x500 io_write+0xbb8/0xff8 io_issue_sqe+0x10c/0x1020 io_submit_sqes+0x614/0x2110 __arm64_sys_io_uring_enter+0x524/0x1038 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 INFO: task fsfreeze:7364 blocked for more than 15 seconds. Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963 with the attempting freezer stuck trying to grab the rwsem: task:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_down_write+0x2b0/0x680 freeze_super+0x248/0x8a8 do_vfs_ioctl+0x149c/0x1b18 __arm64_sys_ioctl+0xd0/0x1a0 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 Fix this by having the io_uring side honor IOCB_NOWAIT, and only attempt a blocking grab of the super block rwsem if it isn't set. For normal issue where IOCB_NOWAIT would always be set, this returns -EAGAIN which will have io_uring core issue a blocking attempt of the write. That will in turn also get completions run, ensuring forward progress. Since freezing requires CAP_SYS_ADMIN in the first place, this isn't something that can be triggered by a regular user.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50213", "url": "https://ubuntu.com/security/CVE-2024-50213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tests: hdmi: Fix memory leaks in drm_display_mode_from_cea_vic() modprobe drm_hdmi_state_helper_test and then rmmod it, the following memory leak occurs. The `mode` allocated in drm_mode_duplicate() called by drm_display_mode_from_cea_vic() is not freed, which cause the memory leak: \tunreferenced object 0xffffff80ccd18100 (size 128): \t comm \"kunit_try_catch\", pid 1851, jiffies 4295059695 \t hex dump (first 32 bytes): \t 57 62 00 00 80 02 90 02 f0 02 20 03 00 00 e0 01 Wb........ ..... \t ea 01 ec 01 0d 02 00 00 0a 00 00 00 00 00 00 00 ................ \t backtrace (crc c2f1aa95): \t [<000000000f10b11b>] kmemleak_alloc+0x34/0x40 \t [<000000001cd4cf73>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<00000000f1f3cffa>] drm_mode_duplicate+0x44/0x19c \t [<000000008cbeef13>] drm_display_mode_from_cea_vic+0x88/0x98 \t [<0000000019daaacf>] 0xffffffedc11ae69c \t [<000000000aad0f85>] kunit_try_run_case+0x13c/0x3ac \t [<00000000a9210bac>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<000000000a0b2e9e>] kthread+0x2e8/0x374 \t [<00000000bd668858>] ret_from_fork+0x10/0x20 \t...... Free `mode` by using drm_kunit_display_mode_from_cea_vic() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50214", "url": "https://ubuntu.com/security/CVE-2024-50214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/connector: hdmi: Fix memory leak in drm_display_mode_from_cea_vic() modprobe drm_connector_test and then rmmod drm_connector_test, the following memory leak occurs. The `mode` allocated in drm_mode_duplicate() called by drm_display_mode_from_cea_vic() is not freed, which cause the memory leak: \tunreferenced object 0xffffff80cb0ee400 (size 128): \t comm \"kunit_try_catch\", pid 1948, jiffies 4294950339 \t hex dump (first 32 bytes): \t 14 44 02 00 80 07 d8 07 04 08 98 08 00 00 38 04 .D............8. \t 3c 04 41 04 65 04 00 00 05 00 00 00 00 00 00 00 <.A.e........... \t backtrace (crc 90e9585c): \t [<00000000ec42e3d7>] kmemleak_alloc+0x34/0x40 \t [<00000000d0ef055a>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<00000000c2062161>] drm_mode_duplicate+0x44/0x19c \t [<00000000f96c74aa>] drm_display_mode_from_cea_vic+0x88/0x98 \t [<00000000d8f2c8b4>] 0xffffffdc982a4868 \t [<000000005d164dbc>] kunit_try_run_case+0x13c/0x3ac \t [<000000006fb23398>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<000000006ea56ca0>] kthread+0x2e8/0x374 \t [<000000000676063f>] ret_from_fork+0x10/0x20 \t...... Free `mode` by using drm_kunit_display_mode_from_cea_vic() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50215", "url": "https://ubuntu.com/security/CVE-2024-50215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: assign dh_key to NULL after kfree_sensitive ctrl->dh_key might be used across multiple calls to nvmet_setup_dhgroup() for the same controller. So it's better to nullify it after release on error path in order to avoid double free later in nvmet_destroy_auth(). Found by Linux Verification Center (linuxtesting.org) with Svace.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50216", "url": "https://ubuntu.com/security/CVE-2024-50216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix finding a last resort AG in xfs_filestream_pick_ag When the main loop in xfs_filestream_pick_ag fails to find a suitable AG it tries to just pick the online AG. But the loop for that uses args->pag as loop iterator while the later code expects pag to be set. Fix this by reusing the max_pag case for this last resort, and also add a check for impossible case of no AG just to make sure that the uninitialized pag doesn't even escape in theory.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50217", "url": "https://ubuntu.com/security/CVE-2024-50217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free of block device file in __btrfs_free_extra_devids() Mounting btrfs from two images (which have the same one fsid and two different dev_uuids) in certain executing order may trigger an UAF for variable 'device->bdev_file' in __btrfs_free_extra_devids(). And following are the details: 1. Attach image_1 to loop0, attach image_2 to loop1, and scan btrfs devices by ioctl(BTRFS_IOC_SCAN_DEV): / btrfs_device_1 ? loop0 fs_device \\ btrfs_device_2 ? loop1 2. mount /dev/loop0 /mnt btrfs_open_devices btrfs_device_1->bdev_file = btrfs_get_bdev_and_sb(loop0) btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree fail: btrfs_close_devices // -ENOMEM \t btrfs_close_bdev(btrfs_device_1) fput(btrfs_device_1->bdev_file) \t // btrfs_device_1->bdev_file is freed \t btrfs_close_bdev(btrfs_device_2) fput(btrfs_device_2->bdev_file) 3. mount /dev/loop1 /mnt btrfs_open_devices btrfs_get_bdev_and_sb(&bdev_file) // EIO, btrfs_device_1->bdev_file is not assigned, // which points to a freed memory area btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree btrfs_free_extra_devids if (btrfs_device_1->bdev_file) fput(btrfs_device_1->bdev_file) // UAF ! Fix it by setting 'device->bdev_file' as 'NULL' after closing the btrfs_device in btrfs_close_one_device().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53043", "url": "https://ubuntu.com/security/CVE-2024-53043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mctp i2c: handle NULL header address daddr can be NULL if there is no neighbour table entry present, in that case the tx packet should be dropped. saddr will usually be set by MCTP core, but check for NULL in case a packet is transmitted by a different protocol.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50303", "url": "https://ubuntu.com/security/CVE-2024-50303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: resource,kexec: walk_system_ram_res_rev must retain resource flags walk_system_ram_res_rev() erroneously discards resource flags when passing the information to the callback. This causes systems with IORESOURCE_SYSRAM_DRIVER_MANAGED memory to have these resources selected during kexec to store kexec buffers if that memory happens to be at placed above normal system ram. This leads to undefined behavior after reboot. If the kexec buffer is never touched, nothing happens. If the kexec buffer is touched, it could lead to a crash (like below) or undefined behavior. Tested on a system with CXL memory expanders with driver managed memory, TPM enabled, and CONFIG_IMA_KEXEC=y. Adding printk's showed the flags were being discarded and as a result the check for IORESOURCE_SYSRAM_DRIVER_MANAGED passes. find_next_iomem_res: name(System RAM (kmem)) \t\t start(10000000000) \t\t end(1034fffffff) \t\t flags(83000200) locate_mem_hole_top_down: start(10000000000) end(1034fffffff) flags(0) [.] BUG: unable to handle page fault for address: ffff89834ffff000 [.] #PF: supervisor read access in kernel mode [.] #PF: error_code(0x0000) - not-present page [.] PGD c04c8bf067 P4D c04c8bf067 PUD c04c8be067 PMD 0 [.] Oops: 0000 [#1] SMP [.] RIP: 0010:ima_restore_measurement_list+0x95/0x4b0 [.] RSP: 0018:ffffc900000d3a80 EFLAGS: 00010286 [.] RAX: 0000000000001000 RBX: 0000000000000000 RCX: ffff89834ffff000 [.] RDX: 0000000000000018 RSI: ffff89834ffff000 RDI: ffff89834ffff018 [.] RBP: ffffc900000d3ba0 R08: 0000000000000020 R09: ffff888132b8a900 [.] R10: 4000000000000000 R11: 000000003a616d69 R12: 0000000000000000 [.] R13: ffffffff8404ac28 R14: 0000000000000000 R15: ffff89834ffff000 [.] FS: 0000000000000000(0000) GS:ffff893d44640000(0000) knlGS:0000000000000000 [.] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [.] ata5: SATA link down (SStatus 0 SControl 300) [.] CR2: ffff89834ffff000 CR3: 000001034d00f001 CR4: 0000000000770ef0 [.] PKRU: 55555554 [.] Call Trace: [.] [.] ? __die+0x78/0xc0 [.] ? page_fault_oops+0x2a8/0x3a0 [.] ? exc_page_fault+0x84/0x130 [.] ? asm_exc_page_fault+0x22/0x30 [.] ? ima_restore_measurement_list+0x95/0x4b0 [.] ? template_desc_init_fields+0x317/0x410 [.] ? crypto_alloc_tfm_node+0x9c/0xc0 [.] ? init_ima_lsm+0x30/0x30 [.] ima_load_kexec_buffer+0x72/0xa0 [.] ima_init+0x44/0xa0 [.] __initstub__kmod_ima__373_1201_init_ima7+0x1e/0xb0 [.] ? init_ima_lsm+0x30/0x30 [.] do_one_initcall+0xad/0x200 [.] ? idr_alloc_cyclic+0xaa/0x110 [.] ? new_slab+0x12c/0x420 [.] ? new_slab+0x12c/0x420 [.] ? number+0x12a/0x430 [.] ? sysvec_apic_timer_interrupt+0xa/0x80 [.] ? asm_sysvec_apic_timer_interrupt+0x16/0x20 [.] ? parse_args+0xd4/0x380 [.] ? parse_args+0x14b/0x380 [.] kernel_init_freeable+0x1c1/0x2b0 [.] ? rest_init+0xb0/0xb0 [.] kernel_init+0x16/0x1a0 [.] ret_from_fork+0x2f/0x40 [.] ? rest_init+0xb0/0xb0 [.] ret_from_fork_asm+0x11/0x20 [.] ", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50218", "url": "https://ubuntu.com/security/CVE-2024-50218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow Syzbot reported a kernel BUG in ocfs2_truncate_inline. There are two reasons for this: first, the parameter value passed is greater than ocfs2_max_inline_data_with_xattr, second, the start and end parameters of ocfs2_truncate_inline are \"unsigned int\". So, we need to add a sanity check for byte_start and byte_len right before ocfs2_truncate_inline() in ocfs2_remove_inode_range(), if they are greater than ocfs2_max_inline_data_with_xattr return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50219", "url": "https://ubuntu.com/security/CVE-2024-50219", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50263", "url": "https://ubuntu.com/security/CVE-2024-50263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fork: only invoke khugepaged, ksm hooks if no error There is no reason to invoke these hooks early against an mm that is in an incomplete state. The change in commit d24062914837 (\"fork: use __mt_dup() to duplicate maple tree in dup_mmap()\") makes this more pertinent as we may be in a state where entries in the maple tree are not yet consistent. Their placement early in dup_mmap() only appears to have been meaningful for early error checking, and since functionally it'd require a very small allocation to fail (in practice 'too small to fail') that'd only occur in the most dire circumstances, meaning the fork would fail or be OOM'd in any case. Since both khugepaged and KSM tracking are there to provide optimisations to memory performance rather than critical functionality, it doesn't really matter all that much if, under such dire memory pressure, we fail to register an mm with these. As a result, we follow the example of commit d2081b2bf819 (\"mm: khugepaged: make khugepaged_enter() void function\") and make ksm_fork() a void function also. We only expose the mm to these functions once we are done with them and only if no error occurred in the fork operation.", "cve_priority": "medium", "cve_public_date": "2024-11-11 14:15:00 UTC" }, { "cve": "CVE-2024-50220", "url": "https://ubuntu.com/security/CVE-2024-50220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fork: do not invoke uffd on fork if error occurs Patch series \"fork: do not expose incomplete mm on fork\". During fork we may place the virtual memory address space into an inconsistent state before the fork operation is complete. In addition, we may encounter an error during the fork operation that indicates that the virtual memory address space is invalidated. As a result, we should not be exposing it in any way to external machinery that might interact with the mm or VMAs, machinery that is not designed to deal with incomplete state. We specifically update the fork logic to defer khugepaged and ksm to the end of the operation and only to be invoked if no error arose, and disallow uffd from observing fork events should an error have occurred. This patch (of 2): Currently on fork we expose the virtual address space of a process to userland unconditionally if uffd is registered in VMAs, regardless of whether an error arose in the fork. This is performed in dup_userfaultfd_complete() which is invoked unconditionally, and performs two duties - invoking registered handlers for the UFFD_EVENT_FORK event via dup_fctx(), and clearing down userfaultfd_fork_ctx objects established in dup_userfaultfd(). This is problematic, because the virtual address space may not yet be correctly initialised if an error arose. The change in commit d24062914837 (\"fork: use __mt_dup() to duplicate maple tree in dup_mmap()\") makes this more pertinent as we may be in a state where entries in the maple tree are not yet consistent. We address this by, on fork error, ensuring that we roll back state that we would otherwise expect to clean up through the event being handled by userland and perform the memory freeing duty otherwise performed by dup_userfaultfd_complete(). We do this by implementing a new function, dup_userfaultfd_fail(), which performs the same loop, only decrementing reference counts. Note that we perform mmgrab() on the parent and child mm's, however userfaultfd_ctx_put() will mmdrop() this once the reference count drops to zero, so we will avoid memory leaks correctly here.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53047", "url": "https://ubuntu.com/security/CVE-2024-53047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: init: protect sched with rcu_read_lock Enabling CONFIG_PROVE_RCU_LIST with its dependence CONFIG_RCU_EXPERT creates this splat when an MPTCP socket is created: ============================= WARNING: suspicious RCU usage 6.12.0-rc2+ #11 Not tainted ----------------------------- net/mptcp/sched.c:44 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 no locks held by mptcp_connect/176. stack backtrace: CPU: 0 UID: 0 PID: 176 Comm: mptcp_connect Not tainted 6.12.0-rc2+ #11 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl (lib/dump_stack.c:123) lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822) mptcp_sched_find (net/mptcp/sched.c:44 (discriminator 7)) mptcp_init_sock (net/mptcp/protocol.c:2867 (discriminator 1)) ? sock_init_data_uid (arch/x86/include/asm/atomic.h:28) inet_create.part.0.constprop.0 (net/ipv4/af_inet.c:386) ? __sock_create (include/linux/rcupdate.h:347 (discriminator 1)) __sock_create (net/socket.c:1576) __sys_socket (net/socket.c:1671) ? __pfx___sys_socket (net/socket.c:1712) ? do_user_addr_fault (arch/x86/mm/fault.c:1419 (discriminator 1)) __x64_sys_socket (net/socket.c:1728) do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) That's because when the socket is initialised, rcu_read_lock() is not used despite the explicit comment written above the declaration of mptcp_sched_find() in sched.c. Adding the missing lock/unlock avoids the warning.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50221", "url": "https://ubuntu.com/security/CVE-2024-50221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Vangogh: Fix kernel memory out of bounds write KASAN reports that the GPU metrics table allocated in vangogh_tables_init() is not large enough for the memset done in smu_cmn_init_soft_gpu_metrics(). Condensed report follows: [ 33.861314] BUG: KASAN: slab-out-of-bounds in smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu] [ 33.861799] Write of size 168 at addr ffff888129f59500 by task mangoapp/1067 ... [ 33.861808] CPU: 6 UID: 1000 PID: 1067 Comm: mangoapp Tainted: G W 6.12.0-rc4 #356 1a56f59a8b5182eeaf67eb7cb8b13594dd23b544 [ 33.861816] Tainted: [W]=WARN [ 33.861818] Hardware name: Valve Galileo/Galileo, BIOS F7G0107 12/01/2023 [ 33.861822] Call Trace: [ 33.861826] [ 33.861829] dump_stack_lvl+0x66/0x90 [ 33.861838] print_report+0xce/0x620 [ 33.861853] kasan_report+0xda/0x110 [ 33.862794] kasan_check_range+0xfd/0x1a0 [ 33.862799] __asan_memset+0x23/0x40 [ 33.862803] smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.863306] vangogh_get_gpu_metrics_v2_4+0x123/0xad0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.864257] vangogh_common_get_gpu_metrics+0xb0c/0xbc0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.865682] amdgpu_dpm_get_gpu_metrics+0xcc/0x110 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.866160] amdgpu_get_gpu_metrics+0x154/0x2d0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.867135] dev_attr_show+0x43/0xc0 [ 33.867147] sysfs_kf_seq_show+0x1f1/0x3b0 [ 33.867155] seq_read_iter+0x3f8/0x1140 [ 33.867173] vfs_read+0x76c/0xc50 [ 33.867198] ksys_read+0xfb/0x1d0 [ 33.867214] do_syscall_64+0x90/0x160 ... [ 33.867353] Allocated by task 378 on cpu 7 at 22.794876s: [ 33.867358] kasan_save_stack+0x33/0x50 [ 33.867364] kasan_save_track+0x17/0x60 [ 33.867367] __kasan_kmalloc+0x87/0x90 [ 33.867371] vangogh_init_smc_tables+0x3f9/0x840 [amdgpu] [ 33.867835] smu_sw_init+0xa32/0x1850 [amdgpu] [ 33.868299] amdgpu_device_init+0x467b/0x8d90 [amdgpu] [ 33.868733] amdgpu_driver_load_kms+0x19/0xf0 [amdgpu] [ 33.869167] amdgpu_pci_probe+0x2d6/0xcd0 [amdgpu] [ 33.869608] local_pci_probe+0xda/0x180 [ 33.869614] pci_device_probe+0x43f/0x6b0 Empirically we can confirm that the former allocates 152 bytes for the table, while the latter memsets the 168 large block. Root cause appears that when GPU metrics tables for v2_4 parts were added it was not considered to enlarge the table to fit. The fix in this patch is rather \"brute force\" and perhaps later should be done in a smarter way, by extracting and consolidating the part version to size logic to a common helper, instead of brute forcing the largest possible allocation. Nevertheless, for now this works and fixes the out of bounds write. v2: * Drop impossible v3_0 case. (Mario) (cherry picked from commit 0880f58f9609f0200483a49429af0f050d281703)", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50222", "url": "https://ubuntu.com/security/CVE-2024-50222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iov_iter: fix copy_page_from_iter_atomic() if KMAP_LOCAL_FORCE_MAP generic/077 on x86_32 CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP=y with highmem, on huge=always tmpfs, issues a warning and then hangs (interruptibly): WARNING: CPU: 5 PID: 3517 at mm/highmem.c:622 kunmap_local_indexed+0x62/0xc9 CPU: 5 UID: 0 PID: 3517 Comm: cp Not tainted 6.12.0-rc4 #2 ... copy_page_from_iter_atomic+0xa6/0x5ec generic_perform_write+0xf6/0x1b4 shmem_file_write_iter+0x54/0x67 Fix copy_page_from_iter_atomic() by limiting it in that case (include/linux/skbuff.h skb_frag_must_loop() does similar). But going forward, perhaps CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP is too surprising, has outlived its usefulness, and should just be removed?", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50223", "url": "https://ubuntu.com/security/CVE-2024-50223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/numa: Fix the potential null pointer dereference in task_numa_work() When running stress-ng-vm-segv test, we found a null pointer dereference error in task_numa_work(). Here is the backtrace: [323676.066985] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ...... [323676.067108] CPU: 35 PID: 2694524 Comm: stress-ng-vm-se ...... [323676.067113] pstate: 23401009 (nzCv daif +PAN -UAO +TCO +DIT +SSBS BTYPE=--) [323676.067115] pc : vma_migratable+0x1c/0xd0 [323676.067122] lr : task_numa_work+0x1ec/0x4e0 [323676.067127] sp : ffff8000ada73d20 [323676.067128] x29: ffff8000ada73d20 x28: 0000000000000000 x27: 000000003e89f010 [323676.067130] x26: 0000000000080000 x25: ffff800081b5c0d8 x24: ffff800081b27000 [323676.067133] x23: 0000000000010000 x22: 0000000104d18cc0 x21: ffff0009f7158000 [323676.067135] x20: 0000000000000000 x19: 0000000000000000 x18: ffff8000ada73db8 [323676.067138] x17: 0001400000000000 x16: ffff800080df40b0 x15: 0000000000000035 [323676.067140] x14: ffff8000ada73cc8 x13: 1fffe0017cc72001 x12: ffff8000ada73cc8 [323676.067142] x11: ffff80008001160c x10: ffff000be639000c x9 : ffff8000800f4ba4 [323676.067145] x8 : ffff000810375000 x7 : ffff8000ada73974 x6 : 0000000000000001 [323676.067147] x5 : 0068000b33e26707 x4 : 0000000000000001 x3 : ffff0009f7158000 [323676.067149] x2 : 0000000000000041 x1 : 0000000000004400 x0 : 0000000000000000 [323676.067152] Call trace: [323676.067153] vma_migratable+0x1c/0xd0 [323676.067155] task_numa_work+0x1ec/0x4e0 [323676.067157] task_work_run+0x78/0xd8 [323676.067161] do_notify_resume+0x1ec/0x290 [323676.067163] el0_svc+0x150/0x160 [323676.067167] el0t_64_sync_handler+0xf8/0x128 [323676.067170] el0t_64_sync+0x17c/0x180 [323676.067173] Code: d2888001 910003fd f9000bf3 aa0003f3 (f9401000) [323676.067177] SMP: stopping secondary CPUs [323676.070184] Starting crashdump kernel... stress-ng-vm-segv in stress-ng is used to stress test the SIGSEGV error handling function of the system, which tries to cause a SIGSEGV error on return from unmapping the whole address space of the child process. Normally this program will not cause kernel crashes. But before the munmap system call returns to user mode, a potential task_numa_work() for numa balancing could be added and executed. In this scenario, since the child process has no vma after munmap, the vma_next() in task_numa_work() will return a null pointer even if the vma iterator restarts from 0. Recheck the vma pointer before dereferencing it in task_numa_work().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53053", "url": "https://ubuntu.com/security/CVE-2024-53053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Fix another deadlock during RTC update If ufshcd_rtc_work calls ufshcd_rpm_put_sync() and the pm's usage_count is 0, we will enter the runtime suspend callback. However, the runtime suspend callback will wait to flush ufshcd_rtc_work, causing a deadlock. Replace ufshcd_rpm_put_sync() with ufshcd_rpm_put() to avoid the deadlock.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53075", "url": "https://ubuntu.com/security/CVE-2024-53075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv: Prevent a bad reference count on CPU nodes When populating cache leaves we previously fetched the CPU device node at the very beginning. But when ACPI is enabled we go through a specific branch which returns early and does not call 'of_node_put' for the node that was acquired. Since we are not using a CPU device node for the ACPI code anyways, we can simply move the initialization of it just passed the ACPI block, and we are guaranteed to have an 'of_node_put' call for the acquired node. This prevents a bad reference count of the CPU device node. Moreover, the previous function did not check for errors when acquiring the device node, so a return -ENOENT has been added for that case.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50224", "url": "https://ubuntu.com/security/CVE-2024-50224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: spi-fsl-dspi: Fix crash when not using GPIO chip select Add check for the return value of spi_get_csgpiod() to avoid passing a NULL pointer to gpiod_direction_output(), preventing a crash when GPIO chip select is not used. Fix below crash: [ 4.251960] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 4.260762] Mem abort info: [ 4.263556] ESR = 0x0000000096000004 [ 4.267308] EC = 0x25: DABT (current EL), IL = 32 bits [ 4.272624] SET = 0, FnV = 0 [ 4.275681] EA = 0, S1PTW = 0 [ 4.278822] FSC = 0x04: level 0 translation fault [ 4.283704] Data abort info: [ 4.286583] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 4.292074] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 4.297130] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 4.302445] [0000000000000000] user address but active_mm is swapper [ 4.308805] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 4.315072] Modules linked in: [ 4.318124] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc4-next-20241023-00008-ga20ec42c5fc1 #359 [ 4.328130] Hardware name: LS1046A QDS Board (DT) [ 4.332832] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 4.339794] pc : gpiod_direction_output+0x34/0x5c [ 4.344505] lr : gpiod_direction_output+0x18/0x5c [ 4.349208] sp : ffff80008003b8f0 [ 4.352517] x29: ffff80008003b8f0 x28: 0000000000000000 x27: ffffc96bcc7e9068 [ 4.359659] x26: ffffc96bcc6e00b0 x25: ffffc96bcc598398 x24: ffff447400132810 [ 4.366800] x23: 0000000000000000 x22: 0000000011e1a300 x21: 0000000000020002 [ 4.373940] x20: 0000000000000000 x19: 0000000000000000 x18: ffffffffffffffff [ 4.381081] x17: ffff44740016e600 x16: 0000000500000003 x15: 0000000000000007 [ 4.388221] x14: 0000000000989680 x13: 0000000000020000 x12: 000000000000001e [ 4.395362] x11: 0044b82fa09b5a53 x10: 0000000000000019 x9 : 0000000000000008 [ 4.402502] x8 : 0000000000000002 x7 : 0000000000000007 x6 : 0000000000000000 [ 4.409641] x5 : 0000000000000200 x4 : 0000000002000000 x3 : 0000000000000000 [ 4.416781] x2 : 0000000000022202 x1 : 0000000000000000 x0 : 0000000000000000 [ 4.423921] Call trace: [ 4.426362] gpiod_direction_output+0x34/0x5c (P) [ 4.431067] gpiod_direction_output+0x18/0x5c (L) [ 4.435771] dspi_setup+0x220/0x334", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50225", "url": "https://ubuntu.com/security/CVE-2024-50225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix error propagation of split bios The purpose of btrfs_bbio_propagate_error() shall be propagating an error of split bio to its original btrfs_bio, and tell the error to the upper layer. However, it's not working well on some cases. * Case 1. Immediate (or quick) end_bio with an error When btrfs sends btrfs_bio to mirrored devices, btrfs calls btrfs_bio_end_io() when all the mirroring bios are completed. If that btrfs_bio was split, it is from btrfs_clone_bioset and its end_io function is btrfs_orig_write_end_io. For this case, btrfs_bbio_propagate_error() accesses the orig_bbio's bio context to increase the error count. That works well in most cases. However, if the end_io is called enough fast, orig_bbio's (remaining part after split) bio context may not be properly set at that time. Since the bio context is set when the orig_bbio (the last btrfs_bio) is sent to devices, that might be too late for earlier split btrfs_bio's completion. That will result in NULL pointer dereference. That bug is easily reproducible by running btrfs/146 on zoned devices [1] and it shows the following trace. [1] You need raid-stripe-tree feature as it create \"-d raid0 -m raid1\" FS. BUG: kernel NULL pointer dereference, address: 0000000000000020 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 UID: 0 PID: 13 Comm: kworker/u32:1 Not tainted 6.11.0-rc7-BTRFS-ZNS+ #474 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Workqueue: writeback wb_workfn (flush-btrfs-5) RIP: 0010:btrfs_bio_end_io+0xae/0xc0 [btrfs] BTRFS error (device dm-0): bdev /dev/mapper/error-test errs: wr 2, rd 0, flush 0, corrupt 0, gen 0 RSP: 0018:ffffc9000006f248 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888005a7f080 RCX: ffffc9000006f1dc RDX: 0000000000000000 RSI: 000000000000000a RDI: ffff888005a7f080 RBP: ffff888011dfc540 R08: 0000000000000000 R09: 0000000000000001 R10: ffffffff82e508e0 R11: 0000000000000005 R12: ffff88800ddfbe58 R13: ffff888005a7f080 R14: ffff888005a7f158 R15: ffff888005a7f158 FS: 0000000000000000(0000) GS:ffff88803ea80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000020 CR3: 0000000002e22006 CR4: 0000000000370ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __die_body.cold+0x19/0x26 ? page_fault_oops+0x13e/0x2b0 ? _printk+0x58/0x73 ? do_user_addr_fault+0x5f/0x750 ? exc_page_fault+0x76/0x240 ? asm_exc_page_fault+0x22/0x30 ? btrfs_bio_end_io+0xae/0xc0 [btrfs] ? btrfs_log_dev_io_error+0x7f/0x90 [btrfs] btrfs_orig_write_end_io+0x51/0x90 [btrfs] dm_submit_bio+0x5c2/0xa50 [dm_mod] ? find_held_lock+0x2b/0x80 ? blk_try_enter_queue+0x90/0x1e0 __submit_bio+0xe0/0x130 ? ktime_get+0x10a/0x160 ? lockdep_hardirqs_on+0x74/0x100 submit_bio_noacct_nocheck+0x199/0x410 btrfs_submit_bio+0x7d/0x150 [btrfs] btrfs_submit_chunk+0x1a1/0x6d0 [btrfs] ? lockdep_hardirqs_on+0x74/0x100 ? __folio_start_writeback+0x10/0x2c0 btrfs_submit_bbio+0x1c/0x40 [btrfs] submit_one_bio+0x44/0x60 [btrfs] submit_extent_folio+0x13f/0x330 [btrfs] ? btrfs_set_range_writeback+0xa3/0xd0 [btrfs] extent_writepage_io+0x18b/0x360 [btrfs] extent_write_locked_range+0x17c/0x340 [btrfs] ? __pfx_end_bbio_data_write+0x10/0x10 [btrfs] run_delalloc_cow+0x71/0xd0 [btrfs] btrfs_run_delalloc_range+0x176/0x500 [btrfs] ? find_lock_delalloc_range+0x119/0x260 [btrfs] writepage_delalloc+0x2ab/0x480 [btrfs] extent_write_cache_pages+0x236/0x7d0 [btrfs] btrfs_writepages+0x72/0x130 [btrfs] do_writepages+0xd4/0x240 ? find_held_lock+0x2b/0x80 ? wbc_attach_and_unlock_inode+0x12c/0x290 ? wbc_attach_and_unlock_inode+0x12c/0x29 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53054", "url": "https://ubuntu.com/security/CVE-2024-53054", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50226", "url": "https://ubuntu.com/security/CVE-2024-50226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cxl/port: Fix use-after-free, permit out-of-order decoder shutdown In support of investigating an initialization failure report [1], cxl_test was updated to register mock memory-devices after the mock root-port/bus device had been registered. That led to cxl_test crashing with a use-after-free bug with the following signature: cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem0:decoder7.0 @ 0 next: cxl_switch_uport.0 nr_eps: 1 nr_targets: 1 cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem4:decoder14.0 @ 1 next: cxl_switch_uport.0 nr_eps: 2 nr_targets: 1 cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[0] = cxl_switch_dport.0 for mem0:decoder7.0 @ 0 1) cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[1] = cxl_switch_dport.4 for mem4:decoder14.0 @ 1 [..] cxld_unregister: cxl decoder14.0: cxl_region_decode_reset: cxl_region region3: mock_decoder_reset: cxl_port port3: decoder3.0 reset 2) mock_decoder_reset: cxl_port port3: decoder3.0: out of order reset, expected decoder3.1 cxl_endpoint_decoder_release: cxl decoder14.0: [..] cxld_unregister: cxl decoder7.0: 3) cxl_region_decode_reset: cxl_region region3: Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6bc3: 0000 [#1] PREEMPT SMP PTI [..] RIP: 0010:to_cxl_port+0x8/0x60 [cxl_core] [..] Call Trace: cxl_region_decode_reset+0x69/0x190 [cxl_core] cxl_region_detach+0xe8/0x210 [cxl_core] cxl_decoder_kill_region+0x27/0x40 [cxl_core] cxld_unregister+0x5d/0x60 [cxl_core] At 1) a region has been established with 2 endpoint decoders (7.0 and 14.0). Those endpoints share a common switch-decoder in the topology (3.0). At teardown, 2), decoder14.0 is the first to be removed and hits the \"out of order reset case\" in the switch decoder. The effect though is that region3 cleanup is aborted leaving it in-tact and referencing decoder14.0. At 3) the second attempt to teardown region3 trips over the stale decoder14.0 object which has long since been deleted. The fix here is to recognize that the CXL specification places no mandate on in-order shutdown of switch-decoders, the driver enforces in-order allocation, and hardware enforces in-order commit. So, rather than fail and leave objects dangling, always remove them. In support of making cxl_region_decode_reset() always succeed, cxl_region_invalidate_memregion() failures are turned into warnings. Crashing the kernel is ok there since system integrity is at risk if caches cannot be managed around physical address mutation events like CXL region destruction. A new device_for_each_child_reverse_from() is added to cleanup port->commit_end after all dependent decoders have been disabled. In other words if decoders are allocated 0->1->2 and disabled 1->2->0 then port->commit_end only decrements from 2 after 2 has been disabled, and it decrements all the way to zero since 1 was disabled previously.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50227", "url": "https://ubuntu.com/security/CVE-2024-50227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Fix KASAN reported stack out-of-bounds read in tb_retimer_scan() KASAN reported following issue: BUG: KASAN: stack-out-of-bounds in tb_retimer_scan+0xffe/0x1550 [thunderbolt] Read of size 4 at addr ffff88810111fc1c by task kworker/u56:0/11 CPU: 0 UID: 0 PID: 11 Comm: kworker/u56:0 Tainted: G U 6.11.0+ #1387 Tainted: [U]=USER Workqueue: thunderbolt0 tb_handle_hotplug [thunderbolt] Call Trace: dump_stack_lvl+0x6c/0x90 print_report+0xd1/0x630 kasan_report+0xdb/0x110 __asan_report_load4_noabort+0x14/0x20 tb_retimer_scan+0xffe/0x1550 [thunderbolt] tb_scan_port+0xa6f/0x2060 [thunderbolt] tb_handle_hotplug+0x17b1/0x3080 [thunderbolt] process_one_work+0x626/0x1100 worker_thread+0x6c8/0xfa0 kthread+0x2c8/0x3a0 ret_from_fork+0x3a/0x80 ret_from_fork_asm+0x1a/0x30 This happens because the loop variable still gets incremented by one so max becomes 3 instead of 2, and this makes the second loop read past the the array declared on the stack. Fix this by assigning to max directly in the loop body.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50228", "url": "https://ubuntu.com/security/CVE-2024-50228", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50229", "url": "https://ubuntu.com/security/CVE-2024-50229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential deadlock with newly created symlinks Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers memory reclamation involving the filesystem layer, which can result in circular lock dependencies among the reader/writer semaphore nilfs->ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the fs_reclaim pseudo lock. This is because after commit 21fc61c73c39 (\"don't put symlink bodies in pagecache into highmem\"), the gfp flags of the page cache for symbolic links are overwritten to GFP_KERNEL via inode_nohighmem(). This is not a problem for symlinks read from the backing device, because the __GFP_FS flag is dropped after inode_nohighmem() is called. However, when a new symlink is created with nilfs_symlink(), the gfp flags remain overwritten to GFP_KERNEL. Then, memory allocation called from page_symlink() etc. triggers memory reclamation including the FS layer, which may call nilfs_evict_inode() or nilfs_dirty_inode(). And these can cause a deadlock if they are called while nilfs->ns_segctor_sem is held: Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags of newly created symlinks in the same way that nilfs_new_inode() and __nilfs_read_inode() do, as a workaround until we adopt nofs allocation scope consistently or improve the locking constraints.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50230", "url": "https://ubuntu.com/security/CVE-2024-50230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug due to missing clearing of checked flag Syzbot reported that in directory operations after nilfs2 detects filesystem corruption and degrades to read-only, __block_write_begin_int(), which is called to prepare block writes, may fail the BUG_ON check for accesses exceeding the folio/page size, triggering a kernel bug. This was found to be because the \"checked\" flag of a page/folio was not cleared when it was discarded by nilfs2's own routine, which causes the sanity check of directory entries to be skipped when the directory page/folio is reloaded. So, fix that. This was necessary when the use of nilfs2's own page discard routine was applied to more than just metadata files.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50231", "url": "https://ubuntu.com/security/CVE-2024-50231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gts-helper: Fix memory leaks in iio_gts_build_avail_scale_table() modprobe iio-test-gts and rmmod it, then the following memory leak occurs: \tunreferenced object 0xffffff80c810be00 (size 64): \t comm \"kunit_try_catch\", pid 1654, jiffies 4294913981 \t hex dump (first 32 bytes): \t 02 00 00 00 08 00 00 00 20 00 00 00 40 00 00 00 ........ ...@... \t 80 00 00 00 00 02 00 00 00 04 00 00 00 08 00 00 ................ \t backtrace (crc a63d875e): \t [<0000000028c1b3c2>] kmemleak_alloc+0x34/0x40 \t [<000000001d6ecc87>] __kmalloc_noprof+0x2bc/0x3c0 \t [<00000000393795c1>] devm_iio_init_iio_gts+0x4b4/0x16f4 \t [<0000000071bb4b09>] 0xffffffdf052a62e0 \t [<000000000315bc18>] 0xffffffdf052a6488 \t [<00000000f9dc55b5>] kunit_try_run_case+0x13c/0x3ac \t [<00000000175a3fd4>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000f505065d>] kthread+0x2e8/0x374 \t [<00000000bbfb0e5d>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cbfe9e70 (size 16): \t comm \"kunit_try_catch\", pid 1658, jiffies 4294914015 \t hex dump (first 16 bytes): \t 10 00 00 00 40 00 00 00 80 00 00 00 00 00 00 00 ....@........... \t backtrace (crc 857f0cb4): \t [<0000000028c1b3c2>] kmemleak_alloc+0x34/0x40 \t [<000000001d6ecc87>] __kmalloc_noprof+0x2bc/0x3c0 \t [<00000000393795c1>] devm_iio_init_iio_gts+0x4b4/0x16f4 \t [<0000000071bb4b09>] 0xffffffdf052a62e0 \t [<000000007d089d45>] 0xffffffdf052a6864 \t [<00000000f9dc55b5>] kunit_try_run_case+0x13c/0x3ac \t [<00000000175a3fd4>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000f505065d>] kthread+0x2e8/0x374 \t [<00000000bbfb0e5d>] ret_from_fork+0x10/0x20 \t...... It includes 5*5 times \"size 64\" memory leaks, which correspond to 5 times test_init_iio_gain_scale() calls with gts_test_gains size 10 (10*size(int)) and gts_test_itimes size 5. It also includes 5*1 times \"size 16\" memory leak, which correspond to one time __test_init_iio_gain_scale() call with gts_test_gains_gain_low size 3 (3*size(int)) and gts_test_itimes size 5. The reason is that the per_time_gains[i] is not freed which is allocated in the \"gts->num_itime\" for loop in iio_gts_build_avail_scale_table().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53076", "url": "https://ubuntu.com/security/CVE-2024-53076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gts-helper: Fix memory leaks for the error path of iio_gts_build_avail_scale_table() If per_time_scales[i] or per_time_gains[i] kcalloc fails in the for loop of iio_gts_build_avail_scale_table(), the err_free_out will fail to call kfree() each time when i is reduced to 0, so all the per_time_scales[0] and per_time_gains[0] will not be freed, which will cause memory leaks. Fix it by checking if i >= 0.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50232", "url": "https://ubuntu.com/security/CVE-2024-50232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr() In the ad7124_write_raw() function, parameter val can potentially be zero. This may lead to a division by zero when DIV_ROUND_CLOSEST() is called within ad7124_set_channel_odr(). The ad7124_write_raw() function is invoked through the sequence: iio_write_channel_raw() -> iio_write_channel_attribute() -> iio_channel_write(), with no checks in place to ensure val is non-zero.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50233", "url": "https://ubuntu.com/security/CVE-2024-50233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: iio: frequency: ad9832: fix division by zero in ad9832_calc_freqreg() In the ad9832_write_frequency() function, clk_get_rate() might return 0. This can lead to a division by zero when calling ad9832_calc_freqreg(). The check if (fout > (clk_get_rate(st->mclk) / 2)) does not protect against the case when fout is 0. The ad9832_write_frequency() function is called from ad9832_write(), and fout is derived from a text buffer, which can contain any value.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53055", "url": "https://ubuntu.com/security/CVE-2024-53055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix 6 GHz scan construction If more than 255 colocated APs exist for the set of all APs found during 2.4/5 GHz scanning, then the 6 GHz scan construction will loop forever since the loop variable has type u8, which can never reach the number found when that's bigger than 255, and is stored in a u32 variable. Also move it into the loops to have a smaller scope. Using a u32 there is fine, we limit the number of APs in the scan list and each has a limit on the number of RNR entries due to the frame size. With a limit of 1000 scan results, a frame size upper bound of 4096 (really it's more like ~2300) and a TBTT entry size of at least 11, we get an upper bound for the number of ~372k, well in the bounds of a u32.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50234", "url": "https://ubuntu.com/security/CVE-2024-50234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlegacy: Clear stale interrupts before resuming device iwl4965 fails upon resume from hibernation on my laptop. The reason seems to be a stale interrupt which isn't being cleared out before interrupts are enabled. We end up with a race beween the resume trying to bring things back up, and the restart work (queued form the interrupt handler) trying to bring things down. Eventually the whole thing blows up. Fix the problem by clearing out any stale interrupts before interrupts get enabled during resume. Here's a debug log of the indicent: [ 12.042589] ieee80211 phy0: il_isr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000 [ 12.042625] ieee80211 phy0: il4965_irq_tasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000 [ 12.042651] iwl4965 0000:10:00.0: RF_KILL bit toggled to enable radio. [ 12.042653] iwl4965 0000:10:00.0: On demand firmware reload [ 12.042690] ieee80211 phy0: il4965_irq_tasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282 [ 12.052207] ieee80211 phy0: il4965_mac_start enter [ 12.052212] ieee80211 phy0: il_prep_station Add STA to driver ID 31: ff:ff:ff:ff:ff:ff [ 12.052244] ieee80211 phy0: il4965_set_hw_ready hardware ready [ 12.052324] ieee80211 phy0: il_apm_init Init card's basic functions [ 12.052348] ieee80211 phy0: il_apm_init L1 Enabled; Disabling L0S [ 12.055727] ieee80211 phy0: il4965_load_bsm Begin load bsm [ 12.056140] ieee80211 phy0: il4965_verify_bsm Begin verify bsm [ 12.058642] ieee80211 phy0: il4965_verify_bsm BSM bootstrap uCode image OK [ 12.058721] ieee80211 phy0: il4965_load_bsm BSM write complete, poll 1 iterations [ 12.058734] ieee80211 phy0: __il4965_up iwl4965 is coming up [ 12.058737] ieee80211 phy0: il4965_mac_start Start UP work done. [ 12.058757] ieee80211 phy0: __il4965_down iwl4965 is going down [ 12.058761] ieee80211 phy0: il_scan_cancel_timeout Scan cancel timeout [ 12.058762] ieee80211 phy0: il_do_scan_abort Not performing scan to abort [ 12.058765] ieee80211 phy0: il_clear_ucode_stations Clearing ucode stations in driver [ 12.058767] ieee80211 phy0: il_clear_ucode_stations No active stations found to be cleared [ 12.058819] ieee80211 phy0: _il_apm_stop Stop card, put in low power state [ 12.058827] ieee80211 phy0: _il_apm_stop_master stop master [ 12.058864] ieee80211 phy0: il4965_clear_free_frames 0 frames on pre-allocated heap on clear. [ 12.058869] ieee80211 phy0: Hardware restart was requested [ 16.132299] iwl4965 0000:10:00.0: START_ALIVE timeout after 4000ms. [ 16.132303] ------------[ cut here ]------------ [ 16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue. [ 16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132390] Modules linked in: ctr ccm sch_fq_codel xt_tcpudp xt_multiport xt_state iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables binfmt_misc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdh_generic ecc iTCO_wdt i2c_dev iwl4965 iwlegacy coretemp snd_hda_codec_analog pcspkr psmouse mac80211 snd_hda_codec_generic libarc4 sdhci_pci cqhci sha256_generic sdhci libsha256 firewire_ohci snd_hda_intel snd_intel_dspcfg mmc_core snd_hda_codec snd_hwdep firewire_core led_class iosf_mbi snd_hda_core uhci_hcd lpc_ich crc_itu_t cfg80211 ehci_pci ehci_hcd snd_pcm usbcore mfd_core rfkill snd_timer snd usb_common soundcore video parport_pc parport intel_agp wmi intel_gtt backlight e1000e agpgart evdev [ 16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143 [ 16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010 [ 16.132463] Workqueue: async async_run_entry_fn [ 16.132469] RIP: 0010:ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132501] Code: da 02 00 0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50235", "url": "https://ubuntu.com/security/CVE-2024-50235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: clear wdev->cqm_config pointer on free When we free wdev->cqm_config when unregistering, we also need to clear out the pointer since the same wdev/netdev may get re-registered in another network namespace, then destroyed later, running this code again, which results in a double-free.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50236", "url": "https://ubuntu.com/security/CVE-2024-50236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: Fix memory leak in management tx In the current logic, memory is allocated for storing the MSDU context during management packet TX but this memory is not being freed during management TX completion. Similar leaks are seen in the management TX cleanup logic. Kmemleak reports this problem as below, unreferenced object 0xffffff80b64ed250 (size 16): comm \"kworker/u16:7\", pid 148, jiffies 4294687130 (age 714.199s) hex dump (first 16 bytes): 00 2b d8 d8 80 ff ff ff c4 74 e9 fd 07 00 00 00 .+.......t...... backtrace: [] __kmem_cache_alloc_node+0x1e4/0x2d8 [] kmalloc_trace+0x48/0x110 [] ath10k_wmi_tlv_op_gen_mgmt_tx_send+0xd4/0x1d8 [ath10k_core] [] ath10k_mgmt_over_wmi_tx_work+0x134/0x298 [ath10k_core] [] process_scheduled_works+0x1ac/0x400 [] worker_thread+0x208/0x328 [] kthread+0x100/0x1c0 [] ret_from_fork+0x10/0x20 Free the memory during completion and cleanup to fix the leak. Protect the mgmt_pending_tx idr_remove() operation in ath10k_wmi_tlv_op_cleanup_mgmt_tx_send() using ar->data_lock similar to other instances. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50237", "url": "https://ubuntu.com/security/CVE-2024-50237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower Avoid potentially crashing in the driver because of uninitialized private data", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50238", "url": "https://ubuntu.com/security/CVE-2024-50238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usbc: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data from the qcom-qmp-usb driver, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. This bug was later reproduced when the driver was copied to create the qmp-usbc driver. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with these drivers.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50239", "url": "https://ubuntu.com/security/CVE-2024-50239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usb-legacy: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data from the qcom-qmp-usb driver, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. This bug was later reproduced when the driver was copied to create the qmp-usb-legacy driver. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with these drivers.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50240", "url": "https://ubuntu.com/security/CVE-2024-50240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usb: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with this driver.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53077", "url": "https://ubuntu.com/security/CVE-2024-53077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpcrdma: Always release the rpcrdma_device's xa_array Dai pointed out that the xa_init_flags() in rpcrdma_add_one() needs to have a matching xa_destroy() in rpcrdma_remove_one() to release underlying memory that the xarray might have accrued during operation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50242", "url": "https://ubuntu.com/security/CVE-2024-50242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ntfs_file_release", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50243", "url": "https://ubuntu.com/security/CVE-2024-50243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix general protection fault in run_is_mapped_full Fixed deleating of a non-resident attribute in ntfs_create_inode() rollback.", "cve_priority": "low", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50244", "url": "https://ubuntu.com/security/CVE-2024-50244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ni_clear() Checking of NTFS_FLAGS_LOG_REPLAYING added to prevent access to uninitialized bitmap during replay process.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50245", "url": "https://ubuntu.com/security/CVE-2024-50245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix possible deadlock in mi_read Mutex lock with another subclass used in ni_lock_dir().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50246", "url": "https://ubuntu.com/security/CVE-2024-50246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Add rough attr alloc_size check", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50247", "url": "https://ubuntu.com/security/CVE-2024-50247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Check if more than chunk-size bytes are written A incorrectly formatted chunk may decompress into more than LZNT_CHUNK_SIZE bytes and a index out of bounds will occur in s_max_off.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50248", "url": "https://ubuntu.com/security/CVE-2024-50248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Add bounds checking to mi_enum_attr() Added bounds checking to make sure that every attr don't stray beyond valid memory region.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53078", "url": "https://ubuntu.com/security/CVE-2024-53078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Fix NULL vs IS_ERR() check in probe() The iommu_paging_domain_alloc() function doesn't return NULL pointers, it returns error pointers. Update the check to match.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53056", "url": "https://ubuntu.com/security/CVE-2024-53056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Fix potential NULL dereference in mtk_crtc_destroy() In mtk_crtc_create(), if the call to mbox_request_channel() fails then we set the \"mtk_crtc->cmdq_client.chan\" pointer to NULL. In that situation, we do not call cmdq_pkt_create(). During the cleanup, we need to check if the \"mtk_crtc->cmdq_client.chan\" is NULL first before calling cmdq_pkt_destroy(). Calling cmdq_pkt_destroy() is unnecessary if we didn't call cmdq_pkt_create() and it will result in a NULL pointer dereference.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50249", "url": "https://ubuntu.com/security/CVE-2024-50249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Make rmw_lock a raw_spin_lock The following BUG was triggered: ============================= [ BUG: Invalid wait context ] 6.12.0-rc2-XXX #406 Not tainted ----------------------------- kworker/1:1/62 is trying to lock: ffffff8801593030 (&cpc_ptr->rmw_lock){+.+.}-{3:3}, at: cpc_write+0xcc/0x370 other info that might help us debug this: context-{5:5} 2 locks held by kworker/1:1/62: #0: ffffff897ef5ec98 (&rq->__lock){-.-.}-{2:2}, at: raw_spin_rq_lock_nested+0x2c/0x50 #1: ffffff880154e238 (&sg_policy->update_lock){....}-{2:2}, at: sugov_update_shared+0x3c/0x280 stack backtrace: CPU: 1 UID: 0 PID: 62 Comm: kworker/1:1 Not tainted 6.12.0-rc2-g9654bd3e8806 #406 Workqueue: 0x0 (events) Call trace: dump_backtrace+0xa4/0x130 show_stack+0x20/0x38 dump_stack_lvl+0x90/0xd0 dump_stack+0x18/0x28 __lock_acquire+0x480/0x1ad8 lock_acquire+0x114/0x310 _raw_spin_lock+0x50/0x70 cpc_write+0xcc/0x370 cppc_set_perf+0xa0/0x3a8 cppc_cpufreq_fast_switch+0x40/0xc0 cpufreq_driver_fast_switch+0x4c/0x218 sugov_update_shared+0x234/0x280 update_load_avg+0x6ec/0x7b8 dequeue_entities+0x108/0x830 dequeue_task_fair+0x58/0x408 __schedule+0x4f0/0x1070 schedule+0x54/0x130 worker_thread+0xc0/0x2e8 kthread+0x130/0x148 ret_from_fork+0x10/0x20 sugov_update_shared() locks a raw_spinlock while cpc_write() locks a spinlock. To have a correct wait-type order, update rmw_lock to a raw spinlock and ensure that interrupts will be disabled on the CPU holding it. [ rjw: Changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50250", "url": "https://ubuntu.com/security/CVE-2024-50250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fsdax: dax_unshare_iter needs to copy entire blocks The code that copies data from srcmap to iomap in dax_unshare_iter is very very broken, which bfoster's recent fsx changes have exposed. If the pos and len passed to dax_file_unshare are not aligned to an fsblock boundary, the iter pos and length in the _iter function will reflect this unalignment. dax_iomap_direct_access always returns a pointer to the start of the kmapped fsdax page, even if its pos argument is in the middle of that page. This is catastrophic for data integrity when iter->pos is not aligned to a page, because daddr/saddr do not point to the same byte in the file as iter->pos. Hence we corrupt user data by copying it to the wrong place. If iter->pos + iomap_length() in the _iter function not aligned to a page, then we fail to copy a full block, and only partially populate the destination block. This is catastrophic for data confidentiality because we expose stale pmem contents. Fix both of these issues by aligning copy_pos/copy_len to a page boundary (remember, this is fsdax so 1 fsblock == 1 base page) so that we always copy full blocks. We're not done yet -- there's no call to invalidate_inode_pages2_range, so programs that have the file range mmap'd will continue accessing the old memory mapping after the file metadata updates have completed. Be careful with the return value -- if the unshare succeeds, we still need to return the number of bytes that the iomap iter thinks we're operating on.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50251", "url": "https://ubuntu.com/security/CVE-2024-50251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_payload: sanitize offset and length before calling skb_checksum() If access to offset + length is larger than the skbuff length, then skb_checksum() triggers BUG_ON(). skb_checksum() internally subtracts the length parameter while iterating over skbuff, BUG_ON(len) at the end of it checks that the expected length to be included in the checksum calculation is fully consumed.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50252", "url": "https://ubuntu.com/security/CVE-2024-50252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_ipip: Fix memory leak when changing remote IPv6 address The device stores IPv6 addresses that are used for encapsulation in linear memory that is managed by the driver. Changing the remote address of an ip6gre net device never worked properly, but since cited commit the following reproducer [1] would result in a warning [2] and a memory leak [3]. The problem is that the new remote address is never added by the driver to its hash table (and therefore the device) and the old address is never removed from it. Fix by programming the new address when the configuration of the ip6gre net device changes and removing the old one. If the address did not change, then the above would result in increasing the reference count of the address and then decreasing it. [1] # ip link add name bla up type ip6gre local 2001:db8:1::1 remote 2001:db8:2::1 tos inherit ttl inherit # ip link set dev bla type ip6gre remote 2001:db8:3::1 # ip link del dev bla # devlink dev reload pci/0000:01:00.0 [2] WARNING: CPU: 0 PID: 1682 at drivers/net/ethernet/mellanox/mlxsw/spectrum.c:3002 mlxsw_sp_ipv6_addr_put+0x140/0x1d0 Modules linked in: CPU: 0 UID: 0 PID: 1682 Comm: ip Not tainted 6.12.0-rc3-custom-g86b5b55bc835 #151 Hardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023 RIP: 0010:mlxsw_sp_ipv6_addr_put+0x140/0x1d0 [...] Call Trace: mlxsw_sp_router_netdevice_event+0x55f/0x1240 notifier_call_chain+0x5a/0xd0 call_netdevice_notifiers_info+0x39/0x90 unregister_netdevice_many_notify+0x63e/0x9d0 rtnl_dellink+0x16b/0x3a0 rtnetlink_rcv_msg+0x142/0x3f0 netlink_rcv_skb+0x50/0x100 netlink_unicast+0x242/0x390 netlink_sendmsg+0x1de/0x420 ____sys_sendmsg+0x2bd/0x320 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xd0 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f [3] unreferenced object 0xffff898081f597a0 (size 32): comm \"ip\", pid 1626, jiffies 4294719324 hex dump (first 32 bytes): 20 01 0d b8 00 02 00 00 00 00 00 00 00 00 00 01 ............... 21 49 61 83 80 89 ff ff 00 00 00 00 01 00 00 00 !Ia............. backtrace (crc fd9be911): [<00000000df89c55d>] __kmalloc_cache_noprof+0x1da/0x260 [<00000000ff2a1ddb>] mlxsw_sp_ipv6_addr_kvdl_index_get+0x281/0x340 [<000000009ddd445d>] mlxsw_sp_router_netdevice_event+0x47b/0x1240 [<00000000743e7757>] notifier_call_chain+0x5a/0xd0 [<000000007c7b9e13>] call_netdevice_notifiers_info+0x39/0x90 [<000000002509645d>] register_netdevice+0x5f7/0x7a0 [<00000000c2e7d2a9>] ip6gre_newlink_common.isra.0+0x65/0x130 [<0000000087cd6d8d>] ip6gre_newlink+0x72/0x120 [<000000004df7c7cc>] rtnl_newlink+0x471/0xa20 [<0000000057ed632a>] rtnetlink_rcv_msg+0x142/0x3f0 [<0000000032e0d5b5>] netlink_rcv_skb+0x50/0x100 [<00000000908bca63>] netlink_unicast+0x242/0x390 [<00000000cdbe1c87>] netlink_sendmsg+0x1de/0x420 [<0000000011db153e>] ____sys_sendmsg+0x2bd/0x320 [<000000003b6d53eb>] ___sys_sendmsg+0x9a/0xe0 [<00000000cae27c62>] __sys_sendmsg+0x7a/0xd0", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50253", "url": "https://ubuntu.com/security/CVE-2024-50253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check the validity of nr_words in bpf_iter_bits_new() Check the validity of nr_words in bpf_iter_bits_new(). Without this check, when multiplication overflow occurs for nr_bits (e.g., when nr_words = 0x0400-0001, nr_bits becomes 64), stack corruption may occur due to bpf_probe_read_kernel_common(..., nr_bytes = 0x2000-0008). Fix it by limiting the maximum value of nr_words to 511. The value is derived from the current implementation of BPF memory allocator. To ensure compatibility if the BPF memory allocator's size limitation changes in the future, use the helper bpf_mem_alloc_check_size() to check whether nr_bytes is too larger. And return -E2BIG instead of -ENOMEM for oversized nr_bytes.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50254", "url": "https://ubuntu.com/security/CVE-2024-50254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free dynamically allocated bits in bpf_iter_bits_destroy() bpf_iter_bits_destroy() uses \"kit->nr_bits <= 64\" to check whether the bits are dynamically allocated. However, the check is incorrect and may cause a kmemleak as shown below: unreferenced object 0xffff88812628c8c0 (size 32): comm \"swapper/0\", pid 1, jiffies 4294727320 hex dump (first 32 bytes): \tb0 c1 55 f5 81 88 ff ff f0 f0 f0 f0 f0 f0 f0 f0 ..U........... \tf0 f0 f0 f0 f0 f0 f0 f0 00 00 00 00 00 00 00 00 .............. backtrace (crc 781e32cc): \t[<00000000c452b4ab>] kmemleak_alloc+0x4b/0x80 \t[<0000000004e09f80>] __kmalloc_node_noprof+0x480/0x5c0 \t[<00000000597124d6>] __alloc.isra.0+0x89/0xb0 \t[<000000004ebfffcd>] alloc_bulk+0x2af/0x720 \t[<00000000d9c10145>] prefill_mem_cache+0x7f/0xb0 \t[<00000000ff9738ff>] bpf_mem_alloc_init+0x3e2/0x610 \t[<000000008b616eac>] bpf_global_ma_init+0x19/0x30 \t[<00000000fc473efc>] do_one_initcall+0xd3/0x3c0 \t[<00000000ec81498c>] kernel_init_freeable+0x66a/0x940 \t[<00000000b119f72f>] kernel_init+0x20/0x160 \t[<00000000f11ac9a7>] ret_from_fork+0x3c/0x70 \t[<0000000004671da4>] ret_from_fork_asm+0x1a/0x30 That is because nr_bits will be set as zero in bpf_iter_bits_next() after all bits have been iterated. Fix the issue by setting kit->bit to kit->nr_bits instead of setting kit->nr_bits to zero when the iteration completes in bpf_iter_bits_next(). In addition, use \"!nr_bits || bits >= nr_bits\" to check whether the iteration is complete and still use \"nr_bits > 64\" to indicate whether bits are dynamically allocated. The \"!nr_bits\" check is necessary because bpf_iter_bits_new() may fail before setting kit->nr_bits, and this condition will stop the iteration early instead of accessing the zeroed or freed kit->bits. Considering the initial value of kit->bits is -1 and the type of kit->nr_bits is unsigned int, change the type of kit->nr_bits to int. The potential overflow problem will be handled in the following patch.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50255", "url": "https://ubuntu.com/security/CVE-2024-50255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci: fix null-ptr-deref in hci_read_supported_codecs Fix __hci_cmd_sync_sk() to return not NULL for unknown opcodes. __hci_cmd_sync_sk() returns NULL if a command returns a status event. However, it also returns NULL where an opcode doesn't exist in the hci_cc table because hci_cmd_complete_evt() assumes status = skb->data[0] for unknown opcodes. This leads to null-ptr-deref in cmd_sync for HCI_OP_READ_LOCAL_CODECS as there is no hci_cc for HCI_OP_READ_LOCAL_CODECS, which always assumes status = skb->data[0]. KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077] CPU: 1 PID: 2000 Comm: kworker/u9:5 Not tainted 6.9.0-ga6bcb805883c-dirty #10 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: hci7 hci_power_on RIP: 0010:hci_read_supported_codecs+0xb9/0x870 net/bluetooth/hci_codec.c:138 Code: 08 48 89 ef e8 b8 c1 8f fd 48 8b 75 00 e9 96 00 00 00 49 89 c6 48 ba 00 00 00 00 00 fc ff df 4c 8d 60 70 4c 89 e3 48 c1 eb 03 <0f> b6 04 13 84 c0 0f 85 82 06 00 00 41 83 3c 24 02 77 0a e8 bf 78 RSP: 0018:ffff888120bafac8 EFLAGS: 00010212 RAX: 0000000000000000 RBX: 000000000000000e RCX: ffff8881173f0040 RDX: dffffc0000000000 RSI: ffffffffa58496c0 RDI: ffff88810b9ad1e4 RBP: ffff88810b9ac000 R08: ffffffffa77882a7 R09: 1ffffffff4ef1054 R10: dffffc0000000000 R11: fffffbfff4ef1055 R12: 0000000000000070 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88810b9ac000 FS: 0000000000000000(0000) GS:ffff8881f6c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6ddaa3439e CR3: 0000000139764003 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: hci_read_local_codecs_sync net/bluetooth/hci_sync.c:4546 [inline] hci_init_stage_sync net/bluetooth/hci_sync.c:3441 [inline] hci_init4_sync net/bluetooth/hci_sync.c:4706 [inline] hci_init_sync net/bluetooth/hci_sync.c:4742 [inline] hci_dev_init_sync net/bluetooth/hci_sync.c:4912 [inline] hci_dev_open_sync+0x19a9/0x2d30 net/bluetooth/hci_sync.c:4994 hci_dev_do_open net/bluetooth/hci_core.c:483 [inline] hci_power_on+0x11e/0x560 net/bluetooth/hci_core.c:1015 process_one_work kernel/workqueue.c:3267 [inline] process_scheduled_works+0x8ef/0x14f0 kernel/workqueue.c:3348 worker_thread+0x91f/0xe50 kernel/workqueue.c:3429 kthread+0x2cb/0x360 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50256", "url": "https://ubuntu.com/security/CVE-2024-50256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6() I got a syzbot report without a repro [1] crashing in nf_send_reset6() I think the issue is that dev->hard_header_len is zero, and we attempt later to push an Ethernet header. Use LL_MAX_HEADER, as other functions in net/ipv6/netfilter/nf_reject_ipv6.c. [1] skbuff: skb_under_panic: text:ffffffff89b1d008 len:74 put:14 head:ffff88803123aa00 data:ffff88803123a9f2 tail:0x3c end:0x140 dev:syz_tun kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 UID: 0 PID: 7373 Comm: syz.1.568 Not tainted 6.12.0-rc2-syzkaller-00631-g6d858708d465 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:skb_panic net/core/skbuff.c:206 [inline] RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216 Code: 0d 8d 48 c7 c6 60 a6 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 ba 30 38 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP: 0018:ffffc900045269b0 EFLAGS: 00010282 RAX: 0000000000000088 RBX: dffffc0000000000 RCX: cd66dacdc5d8e800 RDX: 0000000000000000 RSI: 0000000000000200 RDI: 0000000000000000 RBP: ffff88802d39a3d0 R08: ffffffff8174afec R09: 1ffff920008a4ccc R10: dffffc0000000000 R11: fffff520008a4ccd R12: 0000000000000140 R13: ffff88803123aa00 R14: ffff88803123a9f2 R15: 000000000000003c FS: 00007fdbee5ff6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000005d322000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: skb_push+0xe5/0x100 net/core/skbuff.c:2636 eth_header+0x38/0x1f0 net/ethernet/eth.c:83 dev_hard_header include/linux/netdevice.h:3208 [inline] nf_send_reset6+0xce6/0x1270 net/ipv6/netfilter/nf_reject_ipv6.c:358 nft_reject_inet_eval+0x3b9/0x690 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x418/0x6b0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] br_nf_pre_routing_ipv6+0x63e/0x770 net/bridge/br_netfilter_ipv6.c:184 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_bridge_pre net/bridge/br_input.c:277 [inline] br_handle_frame+0x9fd/0x1530 net/bridge/br_input.c:424 __netif_receive_skb_core+0x13e8/0x4570 net/core/dev.c:5562 __netif_receive_skb_one_core net/core/dev.c:5666 [inline] __netif_receive_skb+0x12f/0x650 net/core/dev.c:5781 netif_receive_skb_internal net/core/dev.c:5867 [inline] netif_receive_skb+0x1e8/0x890 net/core/dev.c:5926 tun_rx_batched+0x1b7/0x8f0 drivers/net/tun.c:1550 tun_get_user+0x3056/0x47e0 drivers/net/tun.c:2007 tun_chr_write_iter+0x10d/0x1f0 drivers/net/tun.c:2053 new_sync_write fs/read_write.c:590 [inline] vfs_write+0xa6d/0xc90 fs/read_write.c:683 ksys_write+0x183/0x2b0 fs/read_write.c:736 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:0x7fdbeeb7d1ff Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 c9 8d 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 1c 8e 02 00 48 RSP: 002b:00007fdbee5ff000 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fdbeed36058 RCX: 00007fdbeeb7d1ff RDX: 000000000000008e RSI: 0000000020000040 RDI: 00000000000000c8 RBP: 00007fdbeebf12be R08: 0000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50257", "url": "https://ubuntu.com/security/CVE-2024-50257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: Fix use-after-free in get_info() ip6table_nat module unload has refcnt warning for UAF. call trace is: WARNING: CPU: 1 PID: 379 at kernel/module/main.c:853 module_put+0x6f/0x80 Modules linked in: ip6table_nat(-) CPU: 1 UID: 0 PID: 379 Comm: ip6tables Not tainted 6.12.0-rc4-00047-gc2ee9f594da8-dirty #205 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:module_put+0x6f/0x80 Call Trace: get_info+0x128/0x180 do_ip6t_get_ctl+0x6a/0x430 nf_getsockopt+0x46/0x80 ipv6_getsockopt+0xb9/0x100 rawv6_getsockopt+0x42/0x190 do_sock_getsockopt+0xaa/0x180 __sys_getsockopt+0x70/0xc0 __x64_sys_getsockopt+0x20/0x30 do_syscall_64+0xa2/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Concurrent execution of module unload and get_info() trigered the warning. The root cause is as follows: cpu0\t\t\t\t cpu1 module_exit //mod->state = MODULE_STATE_GOING ip6table_nat_exit xt_unregister_template \tkfree(t) \t//removed from templ_list \t\t\t\t getinfo() \t\t\t\t\t t = xt_find_table_lock \t\t\t\t\t\tlist_for_each_entry(tmpl, &xt_templates[af]...) \t\t\t\t\t\t\tif (strcmp(tmpl->name, name)) \t\t\t\t\t\t\t\tcontinue; //table not found \t\t\t\t\t\t\ttry_module_get \t\t\t\t\t\tlist_for_each_entry(t, &xt_net->tables[af]...) \t\t\t\t\t\t\treturn t; //not get refcnt \t\t\t\t\t module_put(t->me) //uaf unregister_pernet_subsys //remove table from xt_net list While xt_table module was going away and has been removed from xt_templates list, we couldnt get refcnt of xt_table->me. Check module in xt_net->tables list re-traversal to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50258", "url": "https://ubuntu.com/security/CVE-2024-50258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix crash when config small gso_max_size/gso_ipv4_max_size Config a small gso_max_size/gso_ipv4_max_size will lead to an underflow in sk_dst_gso_max_size(), which may trigger a BUG_ON crash, because sk->sk_gso_max_size would be much bigger than device limits. Call Trace: tcp_write_xmit tso_segs = tcp_init_tso_segs(skb, mss_now); tcp_set_skb_tso_segs tcp_skb_pcount_set // skb->len = 524288, mss_now = 8 // u16 tso_segs = 524288/8 = 65535 -> 0 tso_segs = DIV_ROUND_UP(skb->len, mss_now) BUG_ON(!tso_segs) Add check for the minimum value of gso_max_size and gso_ipv4_max_size.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50262", "url": "https://ubuntu.com/security/CVE-2024-50262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix out-of-bounds write in trie_get_next_key() trie_get_next_key() allocates a node stack with size trie->max_prefixlen, while it writes (trie->max_prefixlen + 1) nodes to the stack when it has full paths from the root to leaves. For example, consider a trie with max_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ... 0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with .prefixlen = 8 make 9 nodes be written on the node stack with size 8.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53044", "url": "https://ubuntu.com/security/CVE-2024-53044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_api: fix xa_insert() error path in tcf_block_get_ext() This command: $ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact Error: block dev insert failed: -EBUSY. fails because user space requests the same block index to be set for both ingress and egress. [ side note, I don't think it even failed prior to commit 913b47d3424e (\"net/sched: Introduce tc block netdev tracking infra\"), because this is a command from an old set of notes of mine which used to work, but alas, I did not scientifically bisect this ] The problem is not that it fails, but rather, that the second time around, it fails differently (and irrecoverably): $ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact Error: dsa_core: Flow block cb is busy. [ another note: the extack is added by me for illustration purposes. the context of the problem is that clsact_init() obtains the same &q->ingress_block pointer as &q->egress_block, and since we call tcf_block_get_ext() on both of them, \"dev\" will be added to the block->ports xarray twice, thus failing the operation: once through the ingress block pointer, and once again through the egress block pointer. the problem itself is that when xa_insert() fails, we have emitted a FLOW_BLOCK_BIND command through ndo_setup_tc(), but the offload never sees a corresponding FLOW_BLOCK_UNBIND. ] Even correcting the bad user input, we still cannot recover: $ tc qdisc replace dev swp3 ingress_block 1 egress_block 2 clsact Error: dsa_core: Flow block cb is busy. Basically the only way to recover is to reboot the system, or unbind and rebind the net device driver. To fix the bug, we need to fill the correct error teardown path which was missed during code movement, and call tcf_block_offload_unbind() when xa_insert() fails. [ last note, fundamentally I blame the label naming convention in tcf_block_get_ext() for the bug. The labels should be named after what they do, not after the error path that jumps to them. This way, it is obviously wrong that two labels pointing to the same code mean something is wrong, and checking the code correctness at the goto site is also easier ]", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50259", "url": "https://ubuntu.com/security/CVE-2024-50259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netdevsim: Add trailing zero to terminate the string in nsim_nexthop_bucket_activity_write() This was found by a static analyzer. We should not forget the trailing zero after copy_from_user() if we will further do some string operations, sscanf() in this case. Adding a trailing zero will ensure that the function performs properly.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50304", "url": "https://ubuntu.com/security/CVE-2024-50304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find() The per-netns IP tunnel hash table is protected by the RTNL mutex and ip_tunnel_find() is only called from the control path where the mutex is taken. Add a lockdep expression to hlist_for_each_entry_rcu() in ip_tunnel_find() in order to validate that the mutex is held and to silence the suspicious RCU usage warning [1]. [1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gd95d9a31aceb #139 Not tainted ----------------------------- net/ipv4/ip_tunnel.c:221 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/362: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60 stack backtrace: CPU: 12 UID: 0 PID: 362 Comm: ip Not tainted 6.12.0-rc3-custom-gd95d9a31aceb #139 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 ip_tunnel_find+0x435/0x4d0 ip_tunnel_newlink+0x517/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53042", "url": "https://ubuntu.com/security/CVE-2024-53042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_init_flow() There are code paths from which the function is called without holding the RCU read lock, resulting in a suspicious RCU usage warning [1]. Fix by using l3mdev_master_upper_ifindex_by_index() which will acquire the RCU read lock before calling l3mdev_master_upper_ifindex_by_index_rcu(). [1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gac8f72681cf2 #141 Not tainted ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/361: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60 stack backtrace: CPU: 3 UID: 0 PID: 361 Comm: ip Not tainted 6.12.0-rc3-custom-gac8f72681cf2 #141 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 dev_get_by_index_rcu+0x1d3/0x210 l3mdev_master_upper_ifindex_by_index_rcu+0x2b/0xf0 ip_tunnel_bind_dev+0x72f/0xa00 ip_tunnel_newlink+0x368/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53048", "url": "https://ubuntu.com/security/CVE-2024-53048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix crash on probe for DPLL enabled E810 LOM The E810 Lan On Motherboard (LOM) design is vendor specific. Intel provides the reference design, but it is up to vendor on the final product design. For some cases, like Linux DPLL support, the static values defined in the driver does not reflect the actual LOM design. Current implementation of dpll pins is causing the crash on probe of the ice driver for such DPLL enabled E810 LOM designs: WARNING: (...) at drivers/dpll/dpll_core.c:495 dpll_pin_get+0x2c4/0x330 ... Call Trace: ? __warn+0x83/0x130 ? dpll_pin_get+0x2c4/0x330 ? report_bug+0x1b7/0x1d0 ? handle_bug+0x42/0x70 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? dpll_pin_get+0x117/0x330 ? dpll_pin_get+0x2c4/0x330 ? dpll_pin_get+0x117/0x330 ice_dpll_get_pins.isra.0+0x52/0xe0 [ice] ... The number of dpll pins enabled by LOM vendor is greater than expected and defined in the driver for Intel designed NICs, which causes the crash. Prevent the crash and allow generic pin initialization within Linux DPLL subsystem for DPLL enabled E810 LOM designs. Newly designed solution for described issue will be based on \"per HW design\" pin initialization. It requires pin information dynamically acquired from the firmware and is already in progress, planned for next-tree only.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53058", "url": "https://ubuntu.com/security/CVE-2024-53058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data In case the non-paged data of a SKB carries protocol header and protocol payload to be transmitted on a certain platform that the DMA AXI address width is configured to 40-bit/48-bit, or the size of the non-paged data is bigger than TSO_MAX_BUFF_SIZE on a certain platform that the DMA AXI address width is configured to 32-bit, then this SKB requires at least two DMA transmit descriptors to serve it. For example, three descriptors are allocated to split one DMA buffer mapped from one piece of non-paged data: dma_desc[N + 0], dma_desc[N + 1], dma_desc[N + 2]. Then three elements of tx_q->tx_skbuff_dma[] will be allocated to hold extra information to be reused in stmmac_tx_clean(): tx_q->tx_skbuff_dma[N + 0], tx_q->tx_skbuff_dma[N + 1], tx_q->tx_skbuff_dma[N + 2]. Now we focus on tx_q->tx_skbuff_dma[entry].buf, which is the DMA buffer address returned by DMA mapping call. stmmac_tx_clean() will try to unmap the DMA buffer _ONLY_IF_ tx_q->tx_skbuff_dma[entry].buf is a valid buffer address. The expected behavior that saves DMA buffer address of this non-paged data to tx_q->tx_skbuff_dma[entry].buf is: tx_q->tx_skbuff_dma[N + 0].buf = NULL; tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = dma_map_single(); Unfortunately, the current code misbehaves like this: tx_q->tx_skbuff_dma[N + 0].buf = dma_map_single(); tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = NULL; On the stmmac_tx_clean() side, when dma_desc[N + 0] is closed by the DMA engine, tx_q->tx_skbuff_dma[N + 0].buf is a valid buffer address obviously, then the DMA buffer will be unmapped immediately. There may be a rare case that the DMA engine does not finish the pending dma_desc[N + 1], dma_desc[N + 2] yet. Now things will go horribly wrong, DMA is going to access a unmapped/unreferenced memory region, corrupted data will be transmited or iommu fault will be triggered :( In contrast, the for-loop that maps SKB fragments behaves perfectly as expected, and that is how the driver should do for both non-paged data and paged frags actually. This patch corrects DMA map/unmap sequences by fixing the array index for tx_q->tx_skbuff_dma[entry].buf when assigning DMA buffer address. Tested and verified on DWXGMAC CORE 3.20a", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50260", "url": "https://ubuntu.com/security/CVE-2024-50260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sock_map: fix a NULL pointer dereference in sock_map_link_update_prog() The following race condition could trigger a NULL pointer dereference: sock_map_link_detach():\t\tsock_map_link_update_prog(): mutex_lock(&sockmap_mutex); ... sockmap_link->map = NULL; mutex_unlock(&sockmap_mutex); \t\t\t\t mutex_lock(&sockmap_mutex); \t\t\t\t ... \t\t\t\t sock_map_prog_link_lookup(sockmap_link->map); \t\t\t\t mutex_unlock(&sockmap_mutex); Fix it by adding a NULL pointer check. In this specific case, it makes no sense to update a link which is being released.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53045", "url": "https://ubuntu.com/security/CVE-2024-53045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: dapm: fix bounds checker error in dapm_widget_list_create The widgets array in the snd_soc_dapm_widget_list has a __counted_by attribute attached to it, which points to the num_widgets variable. This attribute is used in bounds checking, and if it is not set before the array is filled, then the bounds sanitizer will issue a warning or a kernel panic if CONFIG_UBSAN_TRAP is set. This patch sets the size of the widgets list calculated with list_for_each as the initial value for num_widgets as it is used for allocating memory for the array. It is updated with the actual number of added elements after the array is filled.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50261", "url": "https://ubuntu.com/security/CVE-2024-50261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macsec: Fix use-after-free while sending the offloading packet KASAN reports the following UAF. The metadata_dst, which is used to store the SCI value for macsec offload, is already freed by metadata_dst_free() in macsec_free_netdev(), while driver still use it for sending the packet. To fix this issue, dst_release() is used instead to release metadata_dst. So it is not freed instantly in macsec_free_netdev() if still referenced by skb. BUG: KASAN: slab-use-after-free in mlx5e_xmit+0x1e8f/0x4190 [mlx5_core] Read of size 2 at addr ffff88813e42e038 by task kworker/7:2/714 [...] Workqueue: mld mld_ifc_work Call Trace: dump_stack_lvl+0x51/0x60 print_report+0xc1/0x600 kasan_report+0xab/0xe0 mlx5e_xmit+0x1e8f/0x4190 [mlx5_core] dev_hard_start_xmit+0x120/0x530 sch_direct_xmit+0x149/0x11e0 __qdisc_run+0x3ad/0x1730 __dev_queue_xmit+0x1196/0x2ed0 vlan_dev_hard_start_xmit+0x32e/0x510 [8021q] dev_hard_start_xmit+0x120/0x530 __dev_queue_xmit+0x14a7/0x2ed0 macsec_start_xmit+0x13e9/0x2340 dev_hard_start_xmit+0x120/0x530 __dev_queue_xmit+0x14a7/0x2ed0 ip6_finish_output2+0x923/0x1a70 ip6_finish_output+0x2d7/0x970 ip6_output+0x1ce/0x3a0 NF_HOOK.constprop.0+0x15f/0x190 mld_sendpack+0x59a/0xbd0 mld_ifc_work+0x48a/0xa80 process_one_work+0x5aa/0xe50 worker_thread+0x79c/0x1290 kthread+0x28f/0x350 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x11/0x20 Allocated by task 3922: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 __kasan_kmalloc+0x77/0x90 __kmalloc_noprof+0x188/0x400 metadata_dst_alloc+0x1f/0x4e0 macsec_newlink+0x914/0x1410 __rtnl_newlink+0xe08/0x15b0 rtnl_newlink+0x5f/0x90 rtnetlink_rcv_msg+0x667/0xa80 netlink_rcv_skb+0x12c/0x360 netlink_unicast+0x551/0x770 netlink_sendmsg+0x72d/0xbd0 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x52e/0x6a0 ___sys_sendmsg+0xeb/0x170 __sys_sendmsg+0xb5/0x140 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Freed by task 4011: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x50 poison_slab_object+0x10c/0x190 __kasan_slab_free+0x11/0x30 kfree+0xe0/0x290 macsec_free_netdev+0x3f/0x140 netdev_run_todo+0x450/0xc70 rtnetlink_rcv_msg+0x66f/0xa80 netlink_rcv_skb+0x12c/0x360 netlink_unicast+0x551/0x770 netlink_sendmsg+0x72d/0xbd0 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x52e/0x6a0 ___sys_sendmsg+0xeb/0x170 __sys_sendmsg+0xb5/0x140 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53059", "url": "https://ubuntu.com/security/CVE-2024-53059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd() 1. The size of the response packet is not validated. 2. The response buffer is not freed. Resolve these issues by switching to iwl_mvm_send_cmd_status(), which handles both size validation and frees the buffer.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53074", "url": "https://ubuntu.com/security/CVE-2024-53074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: don't leak a link on AP removal Release the link mapping resource in AP removal. This impacted devices that do not support the MLD API (9260 and down). On those devices, we couldn't start the AP again after the AP has been already started and stopped.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53049", "url": "https://ubuntu.com/security/CVE-2024-53049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slub/kunit: fix a WARNING due to unwrapped __kmalloc_cache_noprof 'modprobe slub_kunit' will have a warning as shown below. The root cause is that __kmalloc_cache_noprof was directly used, which resulted in no alloc_tag being allocated. This caused current->alloc_tag to be null, leading to a warning in alloc_tag_add_check. Let's add an alloc_hook layer to __kmalloc_cache_noprof specifically within lib/slub_kunit.c, which is the only user of this internal slub function outside kmalloc implementation itself. [58162.947016] WARNING: CPU: 2 PID: 6210 at ./include/linux/alloc_tag.h:125 alloc_tagging_slab_alloc_hook+0x268/0x27c [58162.957721] Call trace: [58162.957919] alloc_tagging_slab_alloc_hook+0x268/0x27c [58162.958286] __kmalloc_cache_noprof+0x14c/0x344 [58162.958615] test_kmalloc_redzone_access+0x50/0x10c [slub_kunit] [58162.959045] kunit_try_run_case+0x74/0x184 [kunit] [58162.959401] kunit_generic_run_threadfn_adapter+0x2c/0x4c [kunit] [58162.959841] kthread+0x10c/0x118 [58162.960093] ret_from_fork+0x10/0x20 [58162.960363] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50192", "url": "https://ubuntu.com/security/CVE-2024-50192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v4: Don't allow a VMOVP on a dying VPE Kunkun Jiang reported that there is a small window of opportunity for userspace to force a change of affinity for a VPE while the VPE has already been unmapped, but the corresponding doorbell interrupt still visible in /proc/irq/. Plug the race by checking the value of vmapp_count, which tracks whether the VPE is mapped ot not, and returning an error in this case. This involves making vmapp_count common to both GICv4.1 and its v4.0 ancestor.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50069", "url": "https://ubuntu.com/security/CVE-2024-50069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: apple: check devm_kasprintf() returned value devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked. Fix this lack and check the returned value. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50070", "url": "https://ubuntu.com/security/CVE-2024-50070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: stm32: check devm_kasprintf() returned value devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked. Fix this lack and check the returned value. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50196", "url": "https://ubuntu.com/security/CVE-2024-50196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: ocelot: fix system hang on level based interrupts The current implementation only calls chained_irq_enter() and chained_irq_exit() if it detects pending interrupts. ``` for (i = 0; i < info->stride; i++) { \turegmap_read(info->map, id_reg + 4 * i, ®); \tif (!reg) \t\tcontinue; \tchained_irq_enter(parent_chip, desc); ``` However, in case of GPIO pin configured in level mode and the parent controller configured in edge mode, GPIO interrupt might be lowered by the hardware. In the result, if the interrupt is short enough, the parent interrupt is still pending while the GPIO interrupt is cleared; chained_irq_enter() never gets called and the system hangs trying to service the parent interrupt. Moving chained_irq_enter() and chained_irq_exit() outside the for loop ensures that they are called even when GPIO interrupt is lowered by the hardware. The similar code with chained_irq_enter() / chained_irq_exit() functions wrapping interrupt checking loop may be found in many other drivers: ``` grep -r -A 10 chained_irq_enter drivers/pinctrl ```", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50197", "url": "https://ubuntu.com/security/CVE-2024-50197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: intel: platform: fix error path in device_for_each_child_node() The device_for_each_child_node() loop requires calls to fwnode_handle_put() upon early returns to decrement the refcount of the child node and avoid leaking memory if that error path is triggered. There is one early returns within that loop in intel_platform_pinctrl_prepare_community(), but fwnode_handle_put() is missing. Instead of adding the missing call, the scoped version of the loop can be used to simplify the code and avoid mistakes in the future if new early returns are added, as the child node is only used for parsing, and it is never assigned.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50071", "url": "https://ubuntu.com/security/CVE-2024-50071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: nuvoton: fix a double free in ma35_pinctrl_dt_node_to_map_func() 'new_map' is allocated using devm_* which takes care of freeing the allocated data on device removal, call to \t.dt_free_map = pinconf_generic_dt_free_map double frees the map as pinconf_generic_dt_free_map() calls pinctrl_utils_free_map(). Fix this by using kcalloc() instead of auto-managed devm_kcalloc().", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50072", "url": "https://ubuntu.com/security/CVE-2024-50072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/bugs: Use code segment selector for VERW operand Robert Gill reported below #GP in 32-bit mode when dosemu software was executing vm86() system call: general protection fault: 0000 [#1] PREEMPT SMP CPU: 4 PID: 4610 Comm: dosemu.bin Not tainted 6.6.21-gentoo-x86 #1 Hardware name: Dell Inc. PowerEdge 1950/0H723K, BIOS 2.7.0 10/30/2010 EIP: restore_all_switch_stack+0xbe/0xcf EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000 ESI: 00000000 EDI: 00000000 EBP: 00000000 ESP: ff8affdc DS: 0000 ES: 0000 FS: 0000 GS: 0033 SS: 0068 EFLAGS: 00010046 CR0: 80050033 CR2: 00c2101c CR3: 04b6d000 CR4: 000406d0 Call Trace: show_regs+0x70/0x78 die_addr+0x29/0x70 exc_general_protection+0x13c/0x348 exc_bounds+0x98/0x98 handle_exception+0x14d/0x14d exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf This only happens in 32-bit mode when VERW based mitigations like MDS/RFDS are enabled. This is because segment registers with an arbitrary user value can result in #GP when executing VERW. Intel SDM vol. 2C documents the following behavior for VERW instruction: #GP(0) - If a memory operand effective address is outside the CS, DS, ES, \t FS, or GS segment limit. CLEAR_CPU_BUFFERS macro executes VERW instruction before returning to user space. Use %cs selector to reference VERW operand. This ensures VERW will not #GP for an arbitrary user %ds. [ mingo: Fixed the SOB chain. ]", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50073", "url": "https://ubuntu.com/security/CVE-2024-50073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: Fix use-after-free in gsm_cleanup_mux BUG: KASAN: slab-use-after-free in gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] Read of size 8 at addr ffff88815fe99c00 by task poc/3379 CPU: 0 UID: 0 PID: 3379 Comm: poc Not tainted 6.11.0+ #56 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] __pfx_gsm_cleanup_mux+0x10/0x10 drivers/tty/n_gsm.c:3124 [n_gsm] __pfx_sched_clock_cpu+0x10/0x10 kernel/sched/clock.c:389 update_load_avg+0x1c1/0x27b0 kernel/sched/fair.c:4500 __pfx_min_vruntime_cb_rotate+0x10/0x10 kernel/sched/fair.c:846 __rb_insert_augmented+0x492/0xbf0 lib/rbtree.c:161 gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] _raw_spin_lock_irqsave+0x92/0xf0 arch/x86/include/asm/atomic.h:107 __pfx_gsmld_ioctl+0x10/0x10 drivers/tty/n_gsm.c:3822 [n_gsm] ktime_get+0x5e/0x140 kernel/time/timekeeping.c:195 ldsem_down_read+0x94/0x4e0 arch/x86/include/asm/atomic64_64.h:79 __pfx_ldsem_down_read+0x10/0x10 drivers/tty/tty_ldsem.c:338 __pfx_do_vfs_ioctl+0x10/0x10 fs/ioctl.c:805 tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 Allocated by task 65: gsm_data_alloc.constprop.0+0x27/0x190 drivers/tty/n_gsm.c:926 [n_gsm] gsm_send+0x2c/0x580 drivers/tty/n_gsm.c:819 [n_gsm] gsm1_receive+0x547/0xad0 drivers/tty/n_gsm.c:3038 [n_gsm] gsmld_receive_buf+0x176/0x280 drivers/tty/n_gsm.c:3609 [n_gsm] tty_ldisc_receive_buf+0x101/0x1e0 drivers/tty/tty_buffer.c:391 tty_port_default_receive_buf+0x61/0xa0 drivers/tty/tty_port.c:39 flush_to_ldisc+0x1b0/0x750 drivers/tty/tty_buffer.c:445 process_scheduled_works+0x2b0/0x10d0 kernel/workqueue.c:3229 worker_thread+0x3dc/0x950 kernel/workqueue.c:3391 kthread+0x2a3/0x370 kernel/kthread.c:389 ret_from_fork+0x2d/0x70 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:257 Freed by task 3367: kfree+0x126/0x420 mm/slub.c:4580 gsm_cleanup_mux+0x36c/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 [Analysis] gsm_msg on the tx_ctrl_list or tx_data_list of gsm_mux can be freed by multi threads through ioctl,which leads to the occurrence of uaf. Protect it by gsm tx lock.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50193", "url": "https://ubuntu.com/security/CVE-2024-50193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/entry_32: Clear CPU buffers after register restore in NMI return CPU buffers are currently cleared after call to exc_nmi, but before register state is restored. This may be okay for MDS mitigation but not for RDFS. Because RDFS mitigation requires CPU buffers to be cleared when registers don't have any sensitive data. Move CLEAR_CPU_BUFFERS after RESTORE_ALL_NMI.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50074", "url": "https://ubuntu.com/security/CVE-2024-50074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: parport: Proper fix for array out-of-bounds access The recent fix for array out-of-bounds accesses replaced sprintf() calls blindly with snprintf(). However, since snprintf() returns the would-be-printed size, not the actually output size, the length calculation can still go over the given limit. Use scnprintf() instead of snprintf(), which returns the actually output letters, for addressing the potential out-of-bounds access properly.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50100", "url": "https://ubuntu.com/security/CVE-2024-50100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: gadget: dummy-hcd: Fix \"task hung\" problem The syzbot fuzzer has been encountering \"task hung\" problems ever since the dummy-hcd driver was changed to use hrtimers instead of regular timers. It turns out that the problems are caused by a subtle difference between the timer_pending() and hrtimer_active() APIs. The changeover blindly replaced the first by the second. However, timer_pending() returns True when the timer is queued but not when its callback is running, whereas hrtimer_active() returns True when the hrtimer is queued _or_ its callback is running. This difference occasionally caused dummy_urb_enqueue() to think that the callback routine had not yet started when in fact it was almost finished. As a result the hrtimer was not restarted, which made it impossible for the driver to dequeue later the URB that was just enqueued. This caused usb_kill_urb() to hang, and things got worse from there. Since hrtimers have no API for telling when they are queued and the callback isn't running, the driver must keep track of this for itself. That's what this patch does, adding a new \"timer_pending\" flag and setting or clearing it at the appropriate times.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50075", "url": "https://ubuntu.com/security/CVE-2024-50075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xhci: tegra: fix checked USB2 port number If USB virtualizatoin is enabled, USB2 ports are shared between all Virtual Functions. The USB2 port number owned by an USB2 root hub in a Virtual Function may be less than total USB2 phy number supported by the Tegra XUSB controller. Using total USB2 phy number as port number to check all PORTSC values would cause invalid memory access. [ 116.923438] Unable to handle kernel paging request at virtual address 006c622f7665642f ... [ 117.213640] Call trace: [ 117.216783] tegra_xusb_enter_elpg+0x23c/0x658 [ 117.222021] tegra_xusb_runtime_suspend+0x40/0x68 [ 117.227260] pm_generic_runtime_suspend+0x30/0x50 [ 117.232847] __rpm_callback+0x84/0x3c0 [ 117.237038] rpm_suspend+0x2dc/0x740 [ 117.241229] pm_runtime_work+0xa0/0xb8 [ 117.245769] process_scheduled_works+0x24c/0x478 [ 117.251007] worker_thread+0x23c/0x328 [ 117.255547] kthread+0x104/0x1b0 [ 117.259389] ret_from_fork+0x10/0x20 [ 117.263582] Code: 54000222 f9461ae8 f8747908 b4ffff48 (f9400100)", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50076", "url": "https://ubuntu.com/security/CVE-2024-50076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vt: prevent kernel-infoleak in con_font_get() font.data may not initialize all memory spaces depending on the implementation of vc->vc_sw->con_font_get. This may cause info-leak, so to prevent this, it is safest to modify it to initialize the allocated memory space to 0, and it generally does not affect the overall performance of the system.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50077", "url": "https://ubuntu.com/security/CVE-2024-50077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix multiple init when debugfs is disabled If bt_debugfs is not created successfully, which happens if either CONFIG_DEBUG_FS or CONFIG_DEBUG_FS_ALLOW_ALL is unset, then iso_init() returns early and does not set iso_inited to true. This means that a subsequent call to iso_init() will result in duplicate calls to proto_register(), bt_sock_register(), etc. With CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, the duplicate call to proto_register() triggers this BUG(): list_add double add: new=ffffffffc0b280d0, prev=ffffffffbab56250, next=ffffffffc0b280d0. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:35! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 2 PID: 887 Comm: bluetoothd Not tainted 6.10.11-1-ao-desktop #1 RIP: 0010:__list_add_valid_or_report+0x9a/0xa0 ... __list_add_valid_or_report+0x9a/0xa0 proto_register+0x2b5/0x340 iso_init+0x23/0x150 [bluetooth] set_iso_socket_func+0x68/0x1b0 [bluetooth] kmem_cache_free+0x308/0x330 hci_sock_sendmsg+0x990/0x9e0 [bluetooth] __sock_sendmsg+0x7b/0x80 sock_write_iter+0x9a/0x110 do_iter_readv_writev+0x11d/0x220 vfs_writev+0x180/0x3e0 do_writev+0xca/0x100 ... This change removes the early return. The check for iso_debugfs being NULL was unnecessary, it is always NULL when iso_inited is false.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50078", "url": "https://ubuntu.com/security/CVE-2024-50078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Call iso_exit() on module unload If iso_init() has been called, iso_exit() must be called on module unload. Without that, the struct proto that iso_init() registered with proto_register() becomes invalid, which could cause unpredictable problems later. In my case, with CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, loading the module again usually triggers this BUG(): list_add corruption. next->prev should be prev (ffffffffb5355fd0), but was 0000000000000068. (next=ffffffffc0a010d0). ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:29! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 4159 Comm: modprobe Not tainted 6.10.11-4+bt2-ao-desktop #1 RIP: 0010:__list_add_valid_or_report+0x61/0xa0 ... __list_add_valid_or_report+0x61/0xa0 proto_register+0x299/0x320 hci_sock_init+0x16/0xc0 [bluetooth] bt_init+0x68/0xd0 [bluetooth] __pfx_bt_init+0x10/0x10 [bluetooth] do_one_initcall+0x80/0x2f0 do_init_module+0x8b/0x230 __do_sys_init_module+0x15f/0x190 do_syscall_64+0x68/0x110 ...", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50198", "url": "https://ubuntu.com/security/CVE-2024-50198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: veml6030: fix IIO device retrieval from embedded device The dev pointer that is received as an argument in the in_illuminance_period_available_show function references the device embedded in the IIO device, not in the i2c client. dev_to_iio_dev() must be used to accessthe right data. The current implementation leads to a segmentation fault on every attempt to read the attribute because indio_dev gets a NULL assignment. This bug has been present since the first appearance of the driver, apparently since the last version (V6) before getting applied. A constant attribute was used until then, and the last modifications might have not been tested again.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50201", "url": "https://ubuntu.com/security/CVE-2024-50201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: Fix encoder->possible_clones Include the encoder itself in its possible_clones bitmask. In the past nothing validated that drivers were populating possible_clones correctly, but that changed in commit 74d2aacbe840 (\"drm: Validate encoder->possible_clones\"). Looks like radeon never got the memo and is still not following the rules 100% correctly. This results in some warnings during driver initialization: Bogus possible_clones: [ENCODER:46:TV-46] possible_clones=0x4 (full encoder mask=0x7) WARNING: CPU: 0 PID: 170 at drivers/gpu/drm/drm_mode_config.c:615 drm_mode_config_validate+0x113/0x39c ... (cherry picked from commit 3b6e7d40649c0d75572039aff9d0911864c689db)", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50098", "url": "https://ubuntu.com/security/CVE-2024-50098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Set SDEV_OFFLINE when UFS is shut down There is a history of deadlock if reboot is performed at the beginning of booting. SDEV_QUIESCE was set for all LU's scsi_devices by UFS shutdown, and at that time the audio driver was waiting on blk_mq_submit_bio() holding a mutex_lock while reading the fw binary. After that, a deadlock issue occurred while audio driver shutdown was waiting for mutex_unlock of blk_mq_submit_bio(). To solve this, set SDEV_OFFLINE for all LUs except WLUN, so that any I/O that comes down after a UFS shutdown will return an error. [ 31.907781]I[0: swapper/0: 0] 1 130705007 1651079834 11289729804 0 D( 2) 3 ffffff882e208000 * init [device_shutdown] [ 31.907793]I[0: swapper/0: 0] Mutex: 0xffffff8849a2b8b0: owner[0xffffff882e28cb00 kworker/6:0 :49] [ 31.907806]I[0: swapper/0: 0] Call trace: [ 31.907810]I[0: swapper/0: 0] __switch_to+0x174/0x338 [ 31.907819]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc [ 31.907826]I[0: swapper/0: 0] schedule+0x7c/0xe8 [ 31.907834]I[0: swapper/0: 0] schedule_preempt_disabled+0x24/0x40 [ 31.907842]I[0: swapper/0: 0] __mutex_lock+0x408/0xdac [ 31.907849]I[0: swapper/0: 0] __mutex_lock_slowpath+0x14/0x24 [ 31.907858]I[0: swapper/0: 0] mutex_lock+0x40/0xec [ 31.907866]I[0: swapper/0: 0] device_shutdown+0x108/0x280 [ 31.907875]I[0: swapper/0: 0] kernel_restart+0x4c/0x11c [ 31.907883]I[0: swapper/0: 0] __arm64_sys_reboot+0x15c/0x280 [ 31.907890]I[0: swapper/0: 0] invoke_syscall+0x70/0x158 [ 31.907899]I[0: swapper/0: 0] el0_svc_common+0xb4/0xf4 [ 31.907909]I[0: swapper/0: 0] do_el0_svc+0x2c/0xb0 [ 31.907918]I[0: swapper/0: 0] el0_svc+0x34/0xe0 [ 31.907928]I[0: swapper/0: 0] el0t_64_sync_handler+0x68/0xb4 [ 31.907937]I[0: swapper/0: 0] el0t_64_sync+0x1a0/0x1a4 [ 31.908774]I[0: swapper/0: 0] 49 0 11960702 11236868007 0 D( 2) 6 ffffff882e28cb00 * kworker/6:0 [__bio_queue_enter] [ 31.908783]I[0: swapper/0: 0] Call trace: [ 31.908788]I[0: swapper/0: 0] __switch_to+0x174/0x338 [ 31.908796]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc [ 31.908803]I[0: swapper/0: 0] schedule+0x7c/0xe8 [ 31.908811]I[0: swapper/0: 0] __bio_queue_enter+0xb8/0x178 [ 31.908818]I[0: swapper/0: 0] blk_mq_submit_bio+0x194/0x67c [ 31.908827]I[0: swapper/0: 0] __submit_bio+0xb8/0x19c", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50079", "url": "https://ubuntu.com/security/CVE-2024-50079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/sqpoll: ensure task state is TASK_RUNNING when running task_work When the sqpoll is exiting and cancels pending work items, it may need to run task_work. If this happens from within io_uring_cancel_generic(), then it may be under waiting for the io_uring_task waitqueue. This results in the below splat from the scheduler, as the ring mutex may be attempted grabbed while in a TASK_INTERRUPTIBLE state. Ensure that the task state is set appropriately for that, just like what is done for the other cases in io_run_task_work(). do not call blocking ops when !TASK_RUNNING; state=1 set at [<0000000029387fd2>] prepare_to_wait+0x88/0x2fc WARNING: CPU: 6 PID: 59939 at kernel/sched/core.c:8561 __might_sleep+0xf4/0x140 Modules linked in: CPU: 6 UID: 0 PID: 59939 Comm: iou-sqp-59938 Not tainted 6.12.0-rc3-00113-g8d020023b155 #7456 Hardware name: linux,dummy-virt (DT) pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : __might_sleep+0xf4/0x140 lr : __might_sleep+0xf4/0x140 sp : ffff80008c5e7830 x29: ffff80008c5e7830 x28: ffff0000d93088c0 x27: ffff60001c2d7230 x26: dfff800000000000 x25: ffff0000e16b9180 x24: ffff80008c5e7a50 x23: 1ffff000118bcf4a x22: ffff0000e16b9180 x21: ffff0000e16b9180 x20: 000000000000011b x19: ffff80008310fac0 x18: 1ffff000118bcd90 x17: 30303c5b20746120 x16: 74657320313d6574 x15: 0720072007200720 x14: 0720072007200720 x13: 0720072007200720 x12: ffff600036c64f0b x11: 1fffe00036c64f0a x10: ffff600036c64f0a x9 : dfff800000000000 x8 : 00009fffc939b0f6 x7 : ffff0001b6327853 x6 : 0000000000000001 x5 : ffff0001b6327850 x4 : ffff600036c64f0b x3 : ffff8000803c35bc x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000e16b9180 Call trace: __might_sleep+0xf4/0x140 mutex_lock+0x84/0x124 io_handle_tw_list+0xf4/0x260 tctx_task_work_run+0x94/0x340 io_run_task_work+0x1ec/0x3c0 io_uring_cancel_generic+0x364/0x524 io_sq_thread+0x820/0x124c ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50080", "url": "https://ubuntu.com/security/CVE-2024-50080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: don't allow user copy for unprivileged device UBLK_F_USER_COPY requires userspace to call write() on ublk char device for filling request buffer, and unprivileged device can't be trusted. So don't allow user copy for unprivileged device.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50081", "url": "https://ubuntu.com/security/CVE-2024-50081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-mq: setup queue ->tag_set before initializing hctx Commit 7b815817aa58 (\"blk-mq: add helper for checking if one CPU is mapped to specified hctx\") needs to check queue mapping via tag set in hctx's cpuhp handler. However, q->tag_set may not be setup yet when the cpuhp handler is enabled, then kernel oops is triggered. Fix the issue by setup queue tag_set before initializing hctx.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50082", "url": "https://ubuntu.com/security/CVE-2024-50082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race We're seeing crashes from rq_qos_wake_function that look like this: BUG: unable to handle page fault for address: ffffafe180a40084 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 100000067 P4D 100000067 PUD 10027c067 PMD 10115d067 PTE 0 Oops: Oops: 0002 [#1] PREEMPT SMP PTI CPU: 17 UID: 0 PID: 0 Comm: swapper/17 Not tainted 6.12.0-rc3-00013-geca631b8fe80 #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:_raw_spin_lock_irqsave+0x1d/0x40 Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 9c 41 5c fa 65 ff 05 62 97 30 4c 31 c0 ba 01 00 00 00 0f b1 17 75 0a 4c 89 e0 41 5c c3 cc cc cc cc 89 c6 e8 2c 0b 00 RSP: 0018:ffffafe180580ca0 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffffafe180a3f7a8 RCX: 0000000000000011 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffffafe180a40084 RBP: 0000000000000000 R08: 00000000001e7240 R09: 0000000000000011 R10: 0000000000000028 R11: 0000000000000888 R12: 0000000000000002 R13: ffffafe180a40084 R14: 0000000000000000 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff9aaf1f280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffafe180a40084 CR3: 000000010e428002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: try_to_wake_up+0x5a/0x6a0 rq_qos_wake_function+0x71/0x80 __wake_up_common+0x75/0xa0 __wake_up+0x36/0x60 scale_up.part.0+0x50/0x110 wb_timer_fn+0x227/0x450 ... So rq_qos_wake_function() calls wake_up_process(data->task), which calls try_to_wake_up(), which faults in raw_spin_lock_irqsave(&p->pi_lock). p comes from data->task, and data comes from the waitqueue entry, which is stored on the waiter's stack in rq_qos_wait(). Analyzing the core dump with drgn, I found that the waiter had already woken up and moved on to a completely unrelated code path, clobbering what was previously data->task. Meanwhile, the waker was passing the clobbered garbage in data->task to wake_up_process(), leading to the crash. What's happening is that in between rq_qos_wake_function() deleting the waitqueue entry and calling wake_up_process(), rq_qos_wait() is finding that it already got a token and returning. The race looks like this: rq_qos_wait() rq_qos_wake_function() ============================================================== prepare_to_wait_exclusive() data->got_token = true; list_del_init(&curr->entry); if (data.got_token) break; finish_wait(&rqw->wait, &data.wq); ^- returns immediately because list_empty_careful(&wq_entry->entry) is true ... return, go do something else ... wake_up_process(data->task) (NO LONGER VALID!)-^ Normally, finish_wait() is supposed to synchronize against the waker. But, as noted above, it is returning immediately because the waitqueue entry has already been removed from the waitqueue. The bug is that rq_qos_wake_function() is accessing the waitqueue entry AFTER deleting it. Note that autoremove_wake_function() wakes the waiter and THEN deletes the waitqueue entry, which is the proper order. Fix it by swapping the order. We also need to use list_del_init_careful() to match the list_empty_careful() in finish_wait().", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50101", "url": "https://ubuntu.com/security/CVE-2024-50101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI devices Previously, the domain_context_clear() function incorrectly called pci_for_each_dma_alias() to set up context entries for non-PCI devices. This could lead to kernel hangs or other unexpected behavior. Add a check to only call pci_for_each_dma_alias() for PCI devices. For non-PCI devices, domain_context_clear_one() is called directly.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50083", "url": "https://ubuntu.com/security/CVE-2024-50083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix mptcp DSS corruption due to large pmtu xmit Syzkaller was able to trigger a DSS corruption: TCP: request_sock_subflow_v4: Possible SYN flooding on port [::]:20002. Sending cookies. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 5227 at net/mptcp/protocol.c:695 __mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695 Modules linked in: CPU: 0 UID: 0 PID: 5227 Comm: syz-executor350 Not tainted 6.11.0-syzkaller-08829-gaf9c191ac2a0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:__mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695 Code: 0f b6 dc 31 ff 89 de e8 b5 dd ea f5 89 d8 48 81 c4 50 01 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 98 da ea f5 90 <0f> 0b 90 e9 47 ff ff ff e8 8a da ea f5 90 0f 0b 90 e9 99 e0 ff ff RSP: 0018:ffffc90000006db8 EFLAGS: 00010246 RAX: ffffffff8ba9df18 RBX: 00000000000055f0 RCX: ffff888030023c00 RDX: 0000000000000100 RSI: 00000000000081e5 RDI: 00000000000055f0 RBP: 1ffff110062bf1ae R08: ffffffff8ba9cf12 R09: 1ffff110062bf1b8 R10: dffffc0000000000 R11: ffffed10062bf1b9 R12: 0000000000000000 R13: dffffc0000000000 R14: 00000000700cec61 R15: 00000000000081e5 FS: 000055556679c380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020287000 CR3: 0000000077892000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: move_skbs_to_msk net/mptcp/protocol.c:811 [inline] mptcp_data_ready+0x29c/0xa90 net/mptcp/protocol.c:854 subflow_data_ready+0x34a/0x920 net/mptcp/subflow.c:1490 tcp_data_queue+0x20fd/0x76c0 net/ipv4/tcp_input.c:5283 tcp_rcv_established+0xfba/0x2020 net/ipv4/tcp_input.c:6237 tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915 tcp_v4_rcv+0x2dc0/0x37f0 net/ipv4/tcp_ipv4.c:2350 ip_protocol_deliver_rcu+0x22e/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x341/0x5f0 net/ipv4/ip_input.c:233 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314 __netif_receive_skb_one_core net/core/dev.c:5662 [inline] __netif_receive_skb+0x2bf/0x650 net/core/dev.c:5775 process_backlog+0x662/0x15b0 net/core/dev.c:6107 __napi_poll+0xcb/0x490 net/core/dev.c:6771 napi_poll net/core/dev.c:6840 [inline] net_rx_action+0x89b/0x1240 net/core/dev.c:6962 handle_softirqs+0x2c5/0x980 kernel/softirq.c:554 do_softirq+0x11b/0x1e0 kernel/softirq.c:455 __local_bh_enable_ip+0x1bb/0x200 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0x1764/0x3e80 net/core/dev.c:4451 dev_queue_xmit include/linux/netdevice.h:3094 [inline] neigh_hh_output include/net/neighbour.h:526 [inline] neigh_output include/net/neighbour.h:540 [inline] ip_finish_output2+0xd41/0x1390 net/ipv4/ip_output.c:236 ip_local_out net/ipv4/ip_output.c:130 [inline] __ip_queue_xmit+0x118c/0x1b80 net/ipv4/ip_output.c:536 __tcp_transmit_skb+0x2544/0x3b30 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_mtu_probe net/ipv4/tcp_output.c:2547 [inline] tcp_write_xmit+0x641d/0x6bf0 net/ipv4/tcp_output.c:2752 __tcp_push_pending_frames+0x9b/0x360 net/ipv4/tcp_output.c:3015 tcp_push_pending_frames include/net/tcp.h:2107 [inline] tcp_data_snd_check net/ipv4/tcp_input.c:5714 [inline] tcp_rcv_established+0x1026/0x2020 net/ipv4/tcp_input.c:6239 tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915 sk_backlog_rcv include/net/sock.h:1113 [inline] __release_sock+0x214/0x350 net/core/sock.c:3072 release_sock+0x61/0x1f0 net/core/sock.c:3626 mptcp_push_ ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50068", "url": "https://ubuntu.com/security/CVE-2024-50068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/tests/sysfs-kunit.h: fix memory leak in damon_sysfs_test_add_targets() The sysfs_target->regions allocated in damon_sysfs_regions_alloc() is not freed in damon_sysfs_test_add_targets(), which cause the following memory leak, free it to fix it. \tunreferenced object 0xffffff80c2a8db80 (size 96): \t comm \"kunit_try_catch\", pid 187, jiffies 4294894363 \t hex dump (first 32 bytes): \t 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ \t 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ \t backtrace (crc 0): \t [<0000000001e3714d>] kmemleak_alloc+0x34/0x40 \t [<000000008e6835c1>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000001286d9f8>] damon_sysfs_test_add_targets+0x1cc/0x738 \t [<0000000032ef8f77>] kunit_try_run_case+0x13c/0x3ac \t [<00000000f3edea23>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000adf936cf>] kthread+0x2e8/0x374 \t [<0000000041bb1628>] ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50199", "url": "https://ubuntu.com/security/CVE-2024-50199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/swapfile: skip HugeTLB pages for unuse_vma I got a bad pud error and lost a 1GB HugeTLB when calling swapoff. The problem can be reproduced by the following steps: 1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory. 2. Swapout the above anonymous memory. 3. run swapoff and we will get a bad pud error in kernel message: mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7) We can tell that pud_clear_bad is called by pud_none_or_clear_bad in unuse_pud_range() by ftrace. And therefore the HugeTLB pages will never be freed because we lost it from page table. We can skip HugeTLB pages for unuse_vma to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50066", "url": "https://ubuntu.com/security/CVE-2024-50066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mremap: fix move_normal_pmd/retract_page_tables race In mremap(), move_page_tables() looks at the type of the PMD entry and the specified address range to figure out by which method the next chunk of page table entries should be moved. At that point, the mmap_lock is held in write mode, but no rmap locks are held yet. For PMD entries that point to page tables and are fully covered by the source address range, move_pgt_entry(NORMAL_PMD, ...) is called, which first takes rmap locks, then does move_normal_pmd(). move_normal_pmd() takes the necessary page table locks at source and destination, then moves an entire page table from the source to the destination. The problem is: The rmap locks, which protect against concurrent page table removal by retract_page_tables() in the THP code, are only taken after the PMD entry has been read and it has been decided how to move it. So we can race as follows (with two processes that have mappings of the same tmpfs file that is stored on a tmpfs mount with huge=advise); note that process A accesses page tables through the MM while process B does it through the file rmap: process A process B ========= ========= mremap mremap_to move_vma move_page_tables get_old_pmd alloc_new_pmd *** PREEMPT *** madvise(MADV_COLLAPSE) do_madvise madvise_walk_vmas madvise_vma_behavior madvise_collapse hpage_collapse_scan_file collapse_file retract_page_tables i_mmap_lock_read(mapping) pmdp_collapse_flush i_mmap_unlock_read(mapping) move_pgt_entry(NORMAL_PMD, ...) take_rmap_locks move_normal_pmd drop_rmap_locks When this happens, move_normal_pmd() can end up creating bogus PMD entries in the line `pmd_populate(mm, new_pmd, pmd_pgtable(pmd))`. The effect depends on arch-specific and machine-specific details; on x86, you can end up with physical page 0 mapped as a page table, which is likely exploitable for user->kernel privilege escalation. Fix the race by letting process B recheck that the PMD still points to a page table after the rmap locks have been taken. Otherwise, we bail and let the caller fall back to the PTE-level copying path, which will then bail immediately at the pmd_none() check. Bug reachability: Reaching this bug requires that you can create shmem/file THP mappings - anonymous THP uses different code that doesn't zap stuff under rmap locks. File THP is gated on an experimental config flag (CONFIG_READ_ONLY_THP_FOR_FS), so on normal distro kernels you need shmem THP to hit this bug. As far as I know, getting shmem THP normally requires that you can mount your own tmpfs with the right mount flags, which would require creating your own user+mount namespace; though I don't know if some distros maybe enable shmem THP by default or something like that. Bug impact: This issue can likely be used for user->kernel privilege escalation when it is reachable.", "cve_priority": "medium", "cve_public_date": "2024-10-23 06:15:00 UTC" }, { "cve": "CVE-2024-50202", "url": "https://ubuntu.com/security/CVE-2024-50202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: propagate directory read errors from nilfs_find_entry() Syzbot reported that a task hang occurs in vcs_open() during a fuzzing test for nilfs2. The root cause of this problem is that in nilfs_find_entry(), which searches for directory entries, ignores errors when loading a directory page/folio via nilfs_get_folio() fails. If the filesystem images is corrupted, and the i_size of the directory inode is large, and the directory page/folio is successfully read but fails the sanity check, for example when it is zero-filled, nilfs_check_folio() may continue to spit out error messages in bursts. Fix this issue by propagating the error to the callers when loading a page/folio fails in nilfs_find_entry(). The current interface of nilfs_find_entry() and its callers is outdated and cannot propagate error codes such as -EIO and -ENOMEM returned via nilfs_find_entry(), so fix it together.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50200", "url": "https://ubuntu.com/security/CVE-2024-50200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: maple_tree: correct tree corruption on spanning store Patch series \"maple_tree: correct tree corruption on spanning store\", v3. There has been a nasty yet subtle maple tree corruption bug that appears to have been in existence since the inception of the algorithm. This bug seems far more likely to happen since commit f8d112a4e657 (\"mm/mmap: avoid zeroing vma tree in mmap_region()\"), which is the point at which reports started to be submitted concerning this bug. We were made definitely aware of the bug thanks to the kind efforts of Bert Karwatzki who helped enormously in my being able to track this down and identify the cause of it. The bug arises when an attempt is made to perform a spanning store across two leaf nodes, where the right leaf node is the rightmost child of the shared parent, AND the store completely consumes the right-mode node. This results in mas_wr_spanning_store() mitakenly duplicating the new and existing entries at the maximum pivot within the range, and thus maple tree corruption. The fix patch corrects this by detecting this scenario and disallowing the mistaken duplicate copy. The fix patch commit message goes into great detail as to how this occurs. This series also includes a test which reliably reproduces the issue, and asserts that the fix works correctly. Bert has kindly tested the fix and confirmed it resolved his issues. Also Mikhail Gavrilov kindly reported what appears to be precisely the same bug, which this fix should also resolve. This patch (of 2): There has been a subtle bug present in the maple tree implementation from its inception. This arises from how stores are performed - when a store occurs, it will overwrite overlapping ranges and adjust the tree as necessary to accommodate this. A range may always ultimately span two leaf nodes. In this instance we walk the two leaf nodes, determine which elements are not overwritten to the left and to the right of the start and end of the ranges respectively and then rebalance the tree to contain these entries and the newly inserted one. This kind of store is dubbed a 'spanning store' and is implemented by mas_wr_spanning_store(). In order to reach this stage, mas_store_gfp() invokes mas_wr_preallocate(), mas_wr_store_type() and mas_wr_walk() in turn to walk the tree and update the object (mas) to traverse to the location where the write should be performed, determining its store type. When a spanning store is required, this function returns false stopping at the parent node which contains the target range, and mas_wr_store_type() marks the mas->store_type as wr_spanning_store to denote this fact. When we go to perform the store in mas_wr_spanning_store(), we first determine the elements AFTER the END of the range we wish to store (that is, to the right of the entry to be inserted) - we do this by walking to the NEXT pivot in the tree (i.e. r_mas.last + 1), starting at the node we have just determined contains the range over which we intend to write. We then turn our attention to the entries to the left of the entry we are inserting, whose state is represented by l_mas, and copy these into a 'big node', which is a special node which contains enough slots to contain two leaf node's worth of data. We then copy the entry we wish to store immediately after this - the copy and the insertion of the new entry is performed by mas_store_b_node(). After this we copy the elements to the right of the end of the range which we are inserting, if we have not exceeded the length of the node (i.e. r_mas.offset <= r_mas.end). Herein lies the bug - under very specific circumstances, this logic can break and corrupt the maple tree. Consider the following tree: Height 0 Root Node / \\ pivot = 0xffff / \\ pivot = ULONG_MAX / ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50084", "url": "https://ubuntu.com/security/CVE-2024-50084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: microchip: vcap api: Fix memory leaks in vcap_api_encode_rule_test() Commit a3c1e45156ad (\"net: microchip: vcap: Fix use-after-free error in kunit test\") fixed the use-after-free error, but introduced below memory leaks by removing necessary vcap_free_rule(), add it to fix it. \tunreferenced object 0xffffff80ca58b700 (size 192): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898264 \t hex dump (first 32 bytes): \t 00 12 7a 00 05 00 00 00 0a 00 00 00 64 00 00 00 ..z.........d... \t 00 00 00 00 00 00 00 00 00 04 0b cc 80 ff ff ff ................ \t backtrace (crc 9c09c3fe): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<0000000040a01b8d>] vcap_alloc_rule+0x3cc/0x9c4 \t [<000000003fe86110>] vcap_api_encode_rule_test+0x1ac/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0400 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898265 \t hex dump (first 32 bytes): \t 80 04 0b cc 80 ff ff ff 18 b7 58 ca 80 ff ff ff ..........X..... \t 39 00 00 00 02 00 00 00 06 05 04 03 02 01 ff ff 9............... \t backtrace (crc daf014e9): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<00000000dfdb1e81>] vcap_api_encode_rule_test+0x224/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0700 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898265 \t hex dump (first 32 bytes): \t 80 07 0b cc 80 ff ff ff 28 b7 58 ca 80 ff ff ff ........(.X..... \t 3c 00 00 00 00 00 00 00 01 2f 03 b3 ec ff ff ff <......../...... \t backtrace (crc 8d877792): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000006eadfab7>] vcap_rule_add_action+0x2d0/0x52c \t [<00000000323475d1>] vcap_api_encode_rule_test+0x4d4/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0900 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898266 \t hex dump (first 32 bytes): \t 80 09 0b cc 80 ff ff ff 80 06 0b cc 80 ff ff ff ................ \t 7d 00 00 00 01 00 00 00 00 00 00 00 ff 00 00 00 }............... \t backtrace (crc 34181e56): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<00000000991e3564>] vcap_val_rule+0xcf0/0x13e8 \t [<00000000fc9868e5>] vcap_api_encode_rule_test+0x678/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0980 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898266 \t hex dump (first 32 bytes): \t 18 b7 58 ca 80 ff ff ff 00 09 0b cc 80 ff ff ff ..X............. \t 67 00 00 00 00 00 00 00 01 01 74 88 c0 ff ff ff g.........t..... \t backtrace (crc 275fd9be): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<000000001396a1a2>] test_add_de ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50194", "url": "https://ubuntu.com/security/CVE-2024-50194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Fix uprobes for big-endian kernels The arm64 uprobes code is broken for big-endian kernels as it doesn't convert the in-memory instruction encoding (which is always little-endian) into the kernel's native endianness before analyzing and simulating instructions. This may result in a few distinct problems: * The kernel may may erroneously reject probing an instruction which can safely be probed. * The kernel may erroneously erroneously permit stepping an instruction out-of-line when that instruction cannot be stepped out-of-line safely. * The kernel may erroneously simulate instruction incorrectly dur to interpretting the byte-swapped encoding. The endianness mismatch isn't caught by the compiler or sparse because: * The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so the compiler and sparse have no idea these contain a little-endian 32-bit value. The core uprobes code populates these with a memcpy() which similarly does not handle endianness. * While the uprobe_opcode_t type is an alias for __le32, both arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[] to the similarly-named probe_opcode_t, which is an alias for u32. Hence there is no endianness conversion warning. Fix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and adding the appropriate __le32_to_cpu() conversions prior to consuming the instruction encoding. The core uprobes copies these fields as opaque ranges of bytes, and so is unaffected by this change. At the same time, remove MAX_UINSN_BYTES and consistently use AARCH64_INSN_SIZE for clarity. Tested with the following: | #include | #include | | #define noinline __attribute__((noinline)) | | static noinline void *adrp_self(void) | { | void *addr; | | asm volatile( | \" adrp %x0, adrp_self\\n\" | \" add %x0, %x0, :lo12:adrp_self\\n\" | : \"=r\" (addr)); | } | | | int main(int argc, char *argv) | { | void *ptr = adrp_self(); | bool equal = (ptr == adrp_self); | | printf(\"adrp_self => %p\\n\" | \"adrp_self() => %p\\n\" | \"%s\\n\", | adrp_self, ptr, equal ? \"EQUAL\" : \"NOT EQUAL\"); | | return 0; | } .... where the adrp_self() function was compiled to: | 00000000004007e0 : | 4007e0: 90000000 adrp x0, 400000 <__ehdr_start> | 4007e4: 911f8000 add x0, x0, #0x7e0 | 4007e8: d65f03c0 ret Before this patch, the ADRP is not recognized, and is assumed to be steppable, resulting in corruption of the result: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0xffffffffff7e0 | NOT EQUAL After this patch, the ADRP is correctly recognized and simulated: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50099", "url": "https://ubuntu.com/security/CVE-2024-50099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Remove broken LDR (literal) uprobe support The simulate_ldr_literal() and simulate_ldrsw_literal() functions are unsafe to use for uprobes. Both functions were originally written for use with kprobes, and access memory with plain C accesses. When uprobes was added, these were reused unmodified even though they cannot safely access user memory. There are three key problems: 1) The plain C accesses do not have corresponding extable entries, and thus if they encounter a fault the kernel will treat these as unintentional accesses to user memory, resulting in a BUG() which will kill the kernel thread, and likely lead to further issues (e.g. lockup or panic()). 2) The plain C accesses are subject to HW PAN and SW PAN, and so when either is in use, any attempt to simulate an access to user memory will fault. Thus neither simulate_ldr_literal() nor simulate_ldrsw_literal() can do anything useful when simulating a user instruction on any system with HW PAN or SW PAN. 3) The plain C accesses are privileged, as they run in kernel context, and in practice can access a small range of kernel virtual addresses. The instructions they simulate have a range of +/-1MiB, and since the simulated instructions must itself be a user instructions in the TTBR0 address range, these can address the final 1MiB of the TTBR1 acddress range by wrapping downwards from an address in the first 1MiB of the TTBR0 address range. In contemporary kernels the last 8MiB of TTBR1 address range is reserved, and accesses to this will always fault, meaning this is no worse than (1). Historically, it was theoretically possible for the linear map or vmemmap to spill into the final 8MiB of the TTBR1 address range, but in practice this is extremely unlikely to occur as this would require either: * Having enough physical memory to fill the entire linear map all the way to the final 1MiB of the TTBR1 address range. * Getting unlucky with KASLR randomization of the linear map such that the populated region happens to overlap with the last 1MiB of the TTBR address range. ... and in either case if we were to spill into the final page there would be larger problems as the final page would alias with error pointers. Practically speaking, (1) and (2) are the big issues. Given there have been no reports of problems since the broken code was introduced, it appears that no-one is relying on probing these instructions with uprobes. Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW (literal), limiting the use of simulate_ldr_literal() and simulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR (literal) and LDRSW (literal) will be rejected as arm_probe_decode_insn() will return INSN_REJECTED. In future we can consider introducing working uprobes support for these instructions, but this will require more significant work.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50195", "url": "https://ubuntu.com/security/CVE-2024-50195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-clock: Fix missing timespec64 check in pc_clock_settime() As Andrew pointed out, it will make sense that the PTP core checked timespec64 struct's tv_sec and tv_nsec range before calling ptp->info->settime64(). As the man manual of clock_settime() said, if tp.tv_sec is negative or tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL, which include dynamic clocks which handles PTP clock, and the condition is consistent with timespec64_valid(). As Thomas suggested, timespec64_valid() only check the timespec is valid, but not ensure that the time is in a valid range, so check it ahead using timespec64_valid_strict() in pc_clock_settime() and return -EINVAL if not valid. There are some drivers that use tp->tv_sec and tp->tv_nsec directly to write registers without validity checks and assume that the higher layer has checked it, which is dangerous and will benefit from this, such as hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(), and some drivers can remove the checks of itself.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50085", "url": "https://ubuntu.com/security/CVE-2024-50085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: fix UaF read in mptcp_pm_nl_rm_addr_or_subflow Syzkaller reported this splat: ================================================================== BUG: KASAN: slab-use-after-free in mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881 Read of size 4 at addr ffff8880569ac858 by task syz.1.2799/14662 CPU: 0 UID: 0 PID: 14662 Comm: syz.1.2799 Not tainted 6.12.0-rc2-syzkaller-00307-g36c254515dc6 #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+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881 mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:914 [inline] mptcp_nl_remove_id_zero_address+0x305/0x4a0 net/mptcp/pm_netlink.c:1572 mptcp_pm_nl_del_addr_doit+0x5c9/0x770 net/mptcp/pm_netlink.c:1603 genl_family_rcv_msg_doit+0x202/0x2f0 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x565/0x800 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x165/0x410 net/netlink/af_netlink.c:2551 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1331 [inline] netlink_unicast+0x53c/0x7f0 net/netlink/af_netlink.c:1357 netlink_sendmsg+0x8b8/0xd70 net/netlink/af_netlink.c:1901 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg net/socket.c:744 [inline] ____sys_sendmsg+0x9ae/0xb40 net/socket.c:2607 ___sys_sendmsg+0x135/0x1e0 net/socket.c:2661 __sys_sendmsg+0x117/0x1f0 net/socket.c:2690 do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline] __do_fast_syscall_32+0x73/0x120 arch/x86/entry/common.c:386 do_fast_syscall_32+0x32/0x80 arch/x86/entry/common.c:411 entry_SYSENTER_compat_after_hwframe+0x84/0x8e RIP: 0023:0xf7fe4579 Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00 RSP: 002b:00000000f574556c EFLAGS: 00000296 ORIG_RAX: 0000000000000172 RAX: ffffffffffffffda RBX: 000000000000000b RCX: 0000000020000140 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000296 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Allocated by task 5387: 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 kmalloc_noprof include/linux/slab.h:878 [inline] kzalloc_noprof include/linux/slab.h:1014 [inline] subflow_create_ctx+0x87/0x2a0 net/mptcp/subflow.c:1803 subflow_ulp_init+0xc3/0x4d0 net/mptcp/subflow.c:1956 __tcp_set_ulp net/ipv4/tcp_ulp.c:146 [inline] tcp_set_ulp+0x326/0x7f0 net/ipv4/tcp_ulp.c:167 mptcp_subflow_create_socket+0x4ae/0x10a0 net/mptcp/subflow.c:1764 __mptcp_subflow_connect+0x3cc/0x1490 net/mptcp/subflow.c:1592 mptcp_pm_create_subflow_or_signal_addr+0xbda/0x23a0 net/mptcp/pm_netlink.c:642 mptcp_pm_nl_fully_established net/mptcp/pm_netlink.c:650 [inline] mptcp_pm_nl_work+0x3a1/0x4f0 net/mptcp/pm_netlink.c:943 mptcp_worker+0x15a/0x1240 net/mptcp/protocol.c:2777 process_one_work+0x958/0x1b30 kernel/workqueue.c:3229 process_scheduled_works kernel/workqueue.c:3310 [inline] worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/ke ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50086", "url": "https://ubuntu.com/security/CVE-2024-50086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix user-after-free from session log off There is racy issue between smb2 session log off and smb2 session setup. It will cause user-after-free from session log off. This add session_lock when setting SMB2_SESSION_EXPIRED and referece count to session struct not to free session while it is being used.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50087", "url": "https://ubuntu.com/security/CVE-2024-50087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix uninitialized pointer free on read_alloc_one_name() error The function read_alloc_one_name() does not initialize the name field of the passed fscrypt_str struct if kmalloc fails to allocate the corresponding buffer. Thus, it is not guaranteed that fscrypt_str.name is initialized when freeing it. This is a follow-up to the linked patch that fixes the remaining instances of the bug introduced by commit e43eec81c516 (\"btrfs: use struct qstr instead of name and namelen pairs\").", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50088", "url": "https://ubuntu.com/security/CVE-2024-50088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix uninitialized pointer free in add_inode_ref() The add_inode_ref() function does not initialize the \"name\" struct when it is declared. If any of the following calls to \"read_one_inode() returns NULL, \tdir = read_one_inode(root, parent_objectid); \tif (!dir) { \t\tret = -ENOENT; \t\tgoto out; \t} \tinode = read_one_inode(root, inode_objectid); \tif (!inode) { \t\tret = -EIO; \t\tgoto out; \t} then \"name.name\" would be freed on \"out\" before being initialized. out: \t... \tkfree(name.name); This issue was reported by Coverity with CID 1526744.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50182", "url": "https://ubuntu.com/security/CVE-2024-50182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: secretmem: disable memfd_secret() if arch cannot set direct map Return -ENOSYS from memfd_secret() syscall if !can_set_direct_map(). This is the case for example on some arm64 configurations, where marking 4k PTEs in the direct map not present can only be done if the direct map is set up at 4k granularity in the first place (as ARM's break-before-make semantics do not easily allow breaking apart large/gigantic pages). More precisely, on arm64 systems with !can_set_direct_map(), set_direct_map_invalid_noflush() is a no-op, however it returns success (0) instead of an error. This means that memfd_secret will seemingly \"work\" (e.g. syscall succeeds, you can mmap the fd and fault in pages), but it does not actually achieve its goal of removing its memory from the direct map. Note that with this patch, memfd_secret() will start erroring on systems where can_set_direct_map() returns false (arm64 with CONFIG_RODATA_FULL_DEFAULT_ENABLED=n, CONFIG_DEBUG_PAGEALLOC=n and CONFIG_KFENCE=n), but that still seems better than the current silent failure. Since CONFIG_RODATA_FULL_DEFAULT_ENABLED defaults to 'y', most arm64 systems actually have a working memfd_secret() and aren't be affected. From going through the iterations of the original memfd_secret patch series, it seems that disabling the syscall in these scenarios was the intended behavior [1] (preferred over having set_direct_map_invalid_noflush return an error as that would result in SIGBUSes at page-fault time), however the check for it got dropped between v16 [2] and v17 [3], when secretmem moved away from CMA allocations. [1]: https://lore.kernel.org/lkml/20201124164930.GK8537@kernel.org/ [2]: https://lore.kernel.org/lkml/20210121122723.3446-11-rppt@kernel.org/#t [3]: https://lore.kernel.org/lkml/20201125092208.12544-10-rppt@kernel.org/", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50019", "url": "https://ubuntu.com/security/CVE-2024-50019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kthread: unpark only parked kthread Calling into kthread unparking unconditionally is mostly harmless when the kthread is already unparked. The wake up is then simply ignored because the target is not in TASK_PARKED state. However if the kthread is per CPU, the wake up is preceded by a call to kthread_bind() which expects the task to be inactive and in TASK_PARKED state, which obviously isn't the case if it is unparked. As a result, calling kthread_stop() on an unparked per-cpu kthread triggers such a warning: \tWARNING: CPU: 0 PID: 11 at kernel/kthread.c:525 __kthread_bind_mask kernel/kthread.c:525 \t \t kthread_stop+0x17a/0x630 kernel/kthread.c:707 \t destroy_workqueue+0x136/0xc40 kernel/workqueue.c:5810 \t wg_destruct+0x1e2/0x2e0 drivers/net/wireguard/device.c:257 \t netdev_run_todo+0xe1a/0x1000 net/core/dev.c:10693 \t default_device_exit_batch+0xa14/0xa90 net/core/dev.c:11769 \t ops_exit_list net/core/net_namespace.c:178 [inline] \t cleanup_net+0x89d/0xcc0 net/core/net_namespace.c:640 \t process_one_work kernel/workqueue.c:3231 [inline] \t process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 \t worker_thread+0x86d/0xd70 kernel/workqueue.c:3393 \t kthread+0x2f0/0x390 kernel/kthread.c:389 \t ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 \t ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 \t Fix this with skipping unecessary unparking while stopping a kthread.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50096", "url": "https://ubuntu.com/security/CVE-2024-50096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/dmem: Fix vulnerability in migrate_to_ram upon copy error The `nouveau_dmem_copy_one` function ensures that the copy push command is sent to the device firmware but does not track whether it was executed successfully. In the case of a copy error (e.g., firmware or hardware failure), the copy push command will be sent via the firmware channel, and `nouveau_dmem_copy_one` will likely report success, leading to the `migrate_to_ram` function returning a dirty HIGH_USER page to the user. This can result in a security vulnerability, as a HIGH_USER page that may contain sensitive or corrupted data could be returned to the user. To prevent this vulnerability, we allocate a zero page. Thus, in case of an error, a non-dirty (zero) page will be returned to the user.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50020", "url": "https://ubuntu.com/security/CVE-2024-50020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix improper handling of refcount in ice_sriov_set_msix_vec_count() This patch addresses an issue with improper reference count handling in the ice_sriov_set_msix_vec_count() function. First, the function calls ice_get_vf_by_id(), which increments the reference count of the vf pointer. If the subsequent call to ice_get_vf_vsi() fails, the function currently returns an error without decrementing the reference count of the vf pointer, leading to a reference count leak. The correct behavior, as implemented in this patch, is to decrement the reference count using ice_put_vf(vf) before returning an error when vsi is NULL. Second, the function calls ice_sriov_get_irqs(), which sets vf->first_vector_idx. If this call returns a negative value, indicating an error, the function returns an error without decrementing the reference count of the vf pointer, resulting in another reference count leak. The patch addresses this by adding a call to ice_put_vf(vf) before returning an error when vf->first_vector_idx < 0. This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and identifying potential mismanagement of reference counts. In this case, the tool flagged the missing decrement operation as a potential issue, leading to this patch.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50021", "url": "https://ubuntu.com/security/CVE-2024-50021", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix improper handling of refcount in ice_dpll_init_rclk_pins() This patch addresses a reference count handling issue in the ice_dpll_init_rclk_pins() function. The function calls ice_dpll_get_pins(), which increments the reference count of the relevant resources. However, if the condition WARN_ON((!vsi || !vsi->netdev)) is met, the function currently returns an error without properly releasing the resources acquired by ice_dpll_get_pins(), leading to a reference count leak. To resolve this, the check has been moved to the top of the function. This ensures that the function verifies the state before any resources are acquired, avoiding the need for additional resource management in the error path. This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and detecting potential issues where resources are not properly managed. In this case, the tool flagged the missing release operation as a potential problem, which led to the development of this patch.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50022", "url": "https://ubuntu.com/security/CVE-2024-50022", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: device-dax: correct pgoff align in dax_set_mapping() pgoff should be aligned using ALIGN_DOWN() instead of ALIGN(). Otherwise, vmf->address not aligned to fault_size will be aligned to the next alignment, that can result in memory failure getting the wrong address. It's a subtle situation that only can be observed in page_mapped_in_vma() after the page is page fault handled by dev_dax_huge_fault. Generally, there is little chance to perform page_mapped_in_vma in dev-dax's page unless in specific error injection to the dax device to trigger an MCE - memory-failure. In that case, page_mapped_in_vma() will be triggered to determine which task is accessing the failure address and kill that task in the end. We used self-developed dax device (which is 2M aligned mapping) , to perform error injection to random address. It turned out that error injected to non-2M-aligned address was causing endless MCE until panic. Because page_mapped_in_vma() kept resulting wrong address and the task accessing the failure address was never killed properly: [ 3783.719419] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.049006] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.049190] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.448042] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.448186] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.792026] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.792179] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.162502] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.162633] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.461116] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.461247] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.764730] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.764859] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.042128] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.042259] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.464293] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.464423] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.818090] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.818217] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3787.085297] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3787.085424] Memory failure: 0x200c9742: recovery action for dax page: Recovered It took us several weeks to pinpoint this problem,  but we eventually used bpftrace to trace the page fault and mce address and successfully identified the issue. Joao added: ; Likely we never reproduce in production because we always pin : device-dax regions in the region align they provide (Qemu does : similarly with prealloc in hugetlb/file backed memory). I think this : bug requires that we touch *unpinned* device-dax regions unaligned to : the device-dax selected alignment (page size i.e. 4K/2M/1G)", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50185", "url": "https://ubuntu.com/security/CVE-2024-50185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: handle consistently DSS corruption Bugged peer implementation can send corrupted DSS options, consistently hitting a few warning in the data path. Use DEBUG_NET assertions, to avoid the splat on some builds and handle consistently the error, dumping related MIBs and performing fallback and/or reset according to the subflow type.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50023", "url": "https://ubuntu.com/security/CVE-2024-50023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: Remove LED entry from LEDs list on unregister Commit c938ab4da0eb (\"net: phy: Manual remove LEDs to ensure correct ordering\") correctly fixed a problem with using devm_ but missed removing the LED entry from the LEDs list. This cause kernel panic on specific scenario where the port for the PHY is torn down and up and the kmod for the PHY is removed. On setting the port down the first time, the assosiacted LEDs are correctly unregistered. The associated kmod for the PHY is now removed. The kmod is now added again and the port is now put up, the associated LED are registered again. On putting the port down again for the second time after these step, the LED list now have 4 elements. With the first 2 already unregistered previously and the 2 new one registered again. This cause a kernel panic as the first 2 element should have been removed. Fix this by correctly removing the element when LED is unregistered.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50024", "url": "https://ubuntu.com/security/CVE-2024-50024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: Fix an unsafe loop on the list The kernel may crash when deleting a genetlink family if there are still listeners for that family: Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c000000000c080bc] netlink_update_socket_mc+0x3c/0xc0 LR [c000000000c0f764] __netlink_clear_multicast_users+0x74/0xc0 Call Trace: __netlink_clear_multicast_users+0x74/0xc0 genl_unregister_family+0xd4/0x2d0 Change the unsafe loop on the list to a safe one, because inside the loop there is an element removal from this list.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50186", "url": "https://ubuntu.com/security/CVE-2024-50186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: explicitly clear the sk pointer, when pf->create fails We have recently noticed the exact same KASAN splat as in commit 6cd4a78d962b (\"net: do not leave a dangling sk pointer, when socket creation fails\"). The problem is that commit did not fully address the problem, as some pf->create implementations do not use sk_common_release in their error paths. For example, we can use the same reproducer as in the above commit, but changing ping to arping. arping uses AF_PACKET socket and if packet_create fails, it will just sk_free the allocated sk object. While we could chase all the pf->create implementations and make sure they NULL the freed sk object on error from the socket, we can't guarantee future protocols will not make the same mistake. So it is easier to just explicitly NULL the sk pointer upon return from pf->create in __sock_create. We do know that pf->create always releases the allocated sk object on error, so if the pointer is not NULL, it is definitely dangling.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50025", "url": "https://ubuntu.com/security/CVE-2024-50025", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: fnic: Move flush_work initialization out of if block After commit 379a58caa199 (\"scsi: fnic: Move fnic_fnic_flush_tx() to a work queue\"), it can happen that a work item is sent to an uninitialized work queue. This may has the effect that the item being queued is never actually queued, and any further actions depending on it will not proceed. The following warning is observed while the fnic driver is loaded: kernel: WARNING: CPU: 11 PID: 0 at ../kernel/workqueue.c:1524 __queue_work+0x373/0x410 kernel: kernel: queue_work_on+0x3a/0x50 kernel: fnic_wq_copy_cmpl_handler+0x54a/0x730 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: fnic_isr_msix_wq_copy+0x2d/0x60 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: __handle_irq_event_percpu+0x36/0x1a0 kernel: handle_irq_event_percpu+0x30/0x70 kernel: handle_irq_event+0x34/0x60 kernel: handle_edge_irq+0x7e/0x1a0 kernel: __common_interrupt+0x3b/0xb0 kernel: common_interrupt+0x58/0xa0 kernel: It has been observed that this may break the rediscovery of Fibre Channel devices after a temporary fabric failure. This patch fixes it by moving the work queue initialization out of an if block in fnic_probe().", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50026", "url": "https://ubuntu.com/security/CVE-2024-50026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: wd33c93: Don't use stale scsi_pointer value A regression was introduced with commit dbb2da557a6a (\"scsi: wd33c93: Move the SCSI pointer to private command data\") which results in an oops in wd33c93_intr(). That commit added the scsi_pointer variable and initialized it from hostdata->connected. However, during selection, hostdata->connected is not yet valid. Fix this by getting the current scsi_pointer from hostdata->selecting.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50027", "url": "https://ubuntu.com/security/CVE-2024-50027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: core: Free tzp copy along with the thermal zone The object pointed to by tz->tzp may still be accessed after being freed in thermal_zone_device_unregister(), so move the freeing of it to the point after the removal completion has been completed at which it cannot be accessed any more.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50028", "url": "https://ubuntu.com/security/CVE-2024-50028", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: core: Reference count the zone in thermal_zone_get_by_id() There are places in the thermal netlink code where nothing prevents the thermal zone object from going away while being accessed after it has been returned by thermal_zone_get_by_id(). To address this, make thermal_zone_get_by_id() get a reference on the thermal zone device object to be returned with the help of get_device(), under thermal_list_lock, and adjust all of its callers to this change with the help of the cleanup.h infrastructure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50029", "url": "https://ubuntu.com/security/CVE-2024-50029", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_conn: Fix UAF in hci_enhanced_setup_sync This checks if the ACL connection remains valid as it could be destroyed while hci_enhanced_setup_sync is pending on cmd_sync leading to the following trace: BUG: KASAN: slab-use-after-free in hci_enhanced_setup_sync+0x91b/0xa60 Read of size 1 at addr ffff888002328ffd by task kworker/u5:2/37 CPU: 0 UID: 0 PID: 37 Comm: kworker/u5:2 Not tainted 6.11.0-rc6-01300-g810be445d8d6 #7099 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Workqueue: hci0 hci_cmd_sync_work Call Trace: dump_stack_lvl+0x5d/0x80 ? hci_enhanced_setup_sync+0x91b/0xa60 print_report+0x152/0x4c0 ? hci_enhanced_setup_sync+0x91b/0xa60 ? __virt_addr_valid+0x1fa/0x420 ? hci_enhanced_setup_sync+0x91b/0xa60 kasan_report+0xda/0x1b0 ? hci_enhanced_setup_sync+0x91b/0xa60 hci_enhanced_setup_sync+0x91b/0xa60 ? __pfx_hci_enhanced_setup_sync+0x10/0x10 ? __pfx___mutex_lock+0x10/0x10 hci_cmd_sync_work+0x1c2/0x330 process_one_work+0x7d9/0x1360 ? __pfx_lock_acquire+0x10/0x10 ? __pfx_process_one_work+0x10/0x10 ? assign_work+0x167/0x240 worker_thread+0x5b7/0xf60 ? __kthread_parkme+0xac/0x1c0 ? __pfx_worker_thread+0x10/0x10 ? __pfx_worker_thread+0x10/0x10 kthread+0x293/0x360 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2f/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 34: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __hci_conn_add+0x187/0x17d0 hci_connect_sco+0x2e1/0xb90 sco_sock_connect+0x2a2/0xb80 __sys_connect+0x227/0x2a0 __x64_sys_connect+0x6d/0xb0 do_syscall_64+0x71/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 37: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x101/0x160 kfree+0xd0/0x250 device_release+0x9a/0x210 kobject_put+0x151/0x280 hci_conn_del+0x448/0xbf0 hci_abort_conn_sync+0x46f/0x980 hci_cmd_sync_work+0x1c2/0x330 process_one_work+0x7d9/0x1360 worker_thread+0x5b7/0xf60 kthread+0x293/0x360 ret_from_fork+0x2f/0x70 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50030", "url": "https://ubuntu.com/security/CVE-2024-50030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/ct: prevent UAF in send_recv() Ensure we serialize with completion side to prevent UAF with fence going out of scope on the stack, since we have no clue if it will fire after the timeout before we can erase from the xa. Also we have some dependent loads and stores for which we need the correct ordering, and we lack the needed barriers. Fix this by grabbing the ct->lock after the wait, which is also held by the completion side. v2 (Badal): - Also print done after acquiring the lock and seeing timeout. (cherry picked from commit 52789ce35c55ccd30c4b67b9cc5b2af55e0122ea)", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50187", "url": "https://ubuntu.com/security/CVE-2024-50187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Stop the active perfmon before being destroyed Upon closing the file descriptor, the active performance monitor is not stopped. Although all perfmons are destroyed in `vc4_perfmon_close_file()`, the active performance monitor's pointer (`vc4->active_perfmon`) is still retained. If we open a new file descriptor and submit a few jobs with performance monitors, the driver will attempt to stop the active performance monitor using the stale pointer in `vc4->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50031", "url": "https://ubuntu.com/security/CVE-2024-50031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Stop the active perfmon before being destroyed When running `kmscube` with one or more performance monitors enabled via `GALLIUM_HUD`, the following kernel panic can occur: [ 55.008324] Unable to handle kernel paging request at virtual address 00000000052004a4 [ 55.008368] Mem abort info: [ 55.008377] ESR = 0x0000000096000005 [ 55.008387] EC = 0x25: DABT (current EL), IL = 32 bits [ 55.008402] SET = 0, FnV = 0 [ 55.008412] EA = 0, S1PTW = 0 [ 55.008421] FSC = 0x05: level 1 translation fault [ 55.008434] Data abort info: [ 55.008442] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 55.008455] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 55.008467] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 55.008481] user pgtable: 4k pages, 39-bit VAs, pgdp=00000001046c6000 [ 55.008497] [00000000052004a4] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 55.008525] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP [ 55.008542] Modules linked in: rfcomm [...] vc4 v3d snd_soc_hdmi_codec drm_display_helper gpu_sched drm_shmem_helper cec drm_dma_helper drm_kms_helper i2c_brcmstb drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight [ 55.008799] CPU: 2 PID: 166 Comm: v3d_bin Tainted: G C 6.6.47+rpt-rpi-v8 #1 Debian 1:6.6.47-1+rpt1 [ 55.008824] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [ 55.008838] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 55.008855] pc : __mutex_lock.constprop.0+0x90/0x608 [ 55.008879] lr : __mutex_lock.constprop.0+0x58/0x608 [ 55.008895] sp : ffffffc080673cf0 [ 55.008904] x29: ffffffc080673cf0 x28: 0000000000000000 x27: ffffff8106188a28 [ 55.008926] x26: ffffff8101e78040 x25: ffffff8101baa6c0 x24: ffffffd9d989f148 [ 55.008947] x23: ffffffda1c2a4008 x22: 0000000000000002 x21: ffffffc080673d38 [ 55.008968] x20: ffffff8101238000 x19: ffffff8104f83188 x18: 0000000000000000 [ 55.008988] x17: 0000000000000000 x16: ffffffda1bd04d18 x15: 00000055bb08bc90 [ 55.009715] x14: 0000000000000000 x13: 0000000000000000 x12: ffffffda1bd4cbb0 [ 55.010433] x11: 00000000fa83b2da x10: 0000000000001a40 x9 : ffffffda1bd04d04 [ 55.011162] x8 : ffffff8102097b80 x7 : 0000000000000000 x6 : 00000000030a5857 [ 55.011880] x5 : 00ffffffffffffff x4 : 0300000005200470 x3 : 0300000005200470 [ 55.012598] x2 : ffffff8101238000 x1 : 0000000000000021 x0 : 0300000005200470 [ 55.013292] Call trace: [ 55.013959] __mutex_lock.constprop.0+0x90/0x608 [ 55.014646] __mutex_lock_slowpath+0x1c/0x30 [ 55.015317] mutex_lock+0x50/0x68 [ 55.015961] v3d_perfmon_stop+0x40/0xe0 [v3d] [ 55.016627] v3d_bin_job_run+0x10c/0x2d8 [v3d] [ 55.017282] drm_sched_main+0x178/0x3f8 [gpu_sched] [ 55.017921] kthread+0x11c/0x128 [ 55.018554] ret_from_fork+0x10/0x20 [ 55.019168] Code: f9400260 f1001c1f 54001ea9 927df000 (b9403401) [ 55.019776] ---[ end trace 0000000000000000 ]--- [ 55.020411] note: v3d_bin[166] exited with preempt_count 1 This issue arises because, upon closing the file descriptor (which happens when we interrupt `kmscube`), the active performance monitor is not stopped. Although all perfmons are destroyed in `v3d_perfmon_close_file()`, the active performance monitor's pointer (`v3d->active_perfmon`) is still retained. If `kmscube` is run again, the driver will attempt to stop the active performance monitor using the stale pointer in `v3d->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50189", "url": "https://ubuntu.com/security/CVE-2024-50189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: amd_sfh: Switch to device-managed dmam_alloc_coherent() Using the device-managed version allows to simplify clean-up in probe() error path. Additionally, this device-managed ensures proper cleanup, which helps to resolve memory errors, page faults, btrfs going read-only, and btrfs disk corruption.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50033", "url": "https://ubuntu.com/security/CVE-2024-50033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slip: make slhc_remember() more robust against malicious packets syzbot found that slhc_remember() was missing checks against malicious packets [1]. slhc_remember() only checked the size of the packet was at least 20, which is not good enough. We need to make sure the packet includes the IPv4 and TCP header that are supposed to be carried. Add iph and th pointers to make the code more readable. [1] BUG: KMSAN: uninit-value in slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 ppp_receive_nonmp_frame+0xe45/0x35e0 drivers/net/ppp/ppp_generic.c:2455 ppp_receive_frame drivers/net/ppp/ppp_generic.c:2372 [inline] ppp_do_recv+0x65f/0x40d0 drivers/net/ppp/ppp_generic.c:2212 ppp_input+0x7dc/0xe60 drivers/net/ppp/ppp_generic.c:2327 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 Uninit was created at: slab_post_alloc_hook mm/slub.c:4091 [inline] slab_alloc_node mm/slub.c:4134 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 CPU: 0 UID: 0 PID: 5460 Comm: syz.2.33 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50034", "url": "https://ubuntu.com/security/CVE-2024-50034", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix lacks of icsk_syn_mss with IPPROTO_SMC Eric report a panic on IPPROTO_SMC, and give the facts that when INET_PROTOSW_ICSK was set, icsk->icsk_sync_mss must be set too. Bug: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000086000005 EC = 0x21: IABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault user pgtable: 4k pages, 48-bit VAs, pgdp=00000001195d1000 [0000000000000000] pgd=0800000109c46003, p4d=0800000109c46003, pud=0000000000000000 Internal error: Oops: 0000000086000005 [#1] PREEMPT SMP Modules linked in: CPU: 1 UID: 0 PID: 8037 Comm: syz.3.265 Not tainted 6.11.0-rc7-syzkaller-g5f5673607153 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0x0 lr : cipso_v4_sock_setattr+0x2a8/0x3c0 net/ipv4/cipso_ipv4.c:1910 sp : ffff80009b887a90 x29: ffff80009b887aa0 x28: ffff80008db94050 x27: 0000000000000000 x26: 1fffe0001aa6f5b3 x25: dfff800000000000 x24: ffff0000db75da00 x23: 0000000000000000 x22: ffff0000d8b78518 x21: 0000000000000000 x20: ffff0000d537ad80 x19: ffff0000d8b78000 x18: 1fffe000366d79ee x17: ffff8000800614a8 x16: ffff800080569b84 x15: 0000000000000001 x14: 000000008b336894 x13: 00000000cd96feaa x12: 0000000000000003 x11: 0000000000040000 x10: 00000000000020a3 x9 : 1fffe0001b16f0f1 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 000000000000003f x5 : 0000000000000040 x4 : 0000000000000001 x3 : 0000000000000000 x2 : 0000000000000002 x1 : 0000000000000000 x0 : ffff0000d8b78000 Call trace: 0x0 netlbl_sock_setattr+0x2e4/0x338 net/netlabel/netlabel_kapi.c:1000 smack_netlbl_add+0xa4/0x154 security/smack/smack_lsm.c:2593 smack_socket_post_create+0xa8/0x14c security/smack/smack_lsm.c:2973 security_socket_post_create+0x94/0xd4 security/security.c:4425 __sock_create+0x4c8/0x884 net/socket.c:1587 sock_create net/socket.c:1622 [inline] __sys_socket_create net/socket.c:1659 [inline] __sys_socket+0x134/0x340 net/socket.c:1706 __do_sys_socket net/socket.c:1720 [inline] __se_sys_socket net/socket.c:1718 [inline] __arm64_sys_socket+0x7c/0x94 net/socket.c:1718 __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:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 Code: ???????? ???????? ???????? ???????? (????????) ---[ end trace 0000000000000000 ]--- This patch add a toy implementation that performs a simple return to prevent such panic. This is because MSS can be set in sock_create_kern or smc_setsockopt, similar to how it's done in AF_SMC. However, for AF_SMC, there is currently no way to synchronize MSS within __sys_connect_file. This toy implementation lays the groundwork for us to support such feature for IPPROTO_SMC in the future.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50035", "url": "https://ubuntu.com/security/CVE-2024-50035", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: fix ppp_async_encode() illegal access syzbot reported an issue in ppp_async_encode() [1] In this case, pppoe_sendmsg() is called with a zero size. Then ppp_async_encode() is called with an empty skb. BUG: KMSAN: uninit-value in ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] BUG: KMSAN: uninit-value in ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_send+0x130/0x1b0 drivers/net/ppp/ppp_async.c:634 ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2280 [inline] ppp_input+0x1f1/0xe60 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 Uninit was created at: slab_post_alloc_hook mm/slub.c:4092 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4187 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 CPU: 1 UID: 0 PID: 5411 Comm: syz.1.14 Not tainted 6.12.0-rc1-syzkaller-00165-g360c1f1f24c6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50036", "url": "https://ubuntu.com/security/CVE-2024-50036", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: do not delay dst_entries_add() in dst_release() dst_entries_add() uses per-cpu data that might be freed at netns dismantle from ip6_route_net_exit() calling dst_entries_destroy() Before ip6_route_net_exit() can be called, we release all the dsts associated with this netns, via calls to dst_release(), which waits an rcu grace period before calling dst_destroy() dst_entries_add() use in dst_destroy() is racy, because dst_entries_destroy() could have been called already. Decrementing the number of dsts must happen sooner. Notes: 1) in CONFIG_XFRM case, dst_destroy() can call dst_release_immediate(child), this might also cause UAF if the child does not have DST_NOCOUNT set. IPSEC maintainers might take a look and see how to address this. 2) There is also discussion about removing this count of dst, which might happen in future kernels.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50037", "url": "https://ubuntu.com/security/CVE-2024-50037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/fbdev-dma: Only cleanup deferred I/O if necessary Commit 5a498d4d06d6 (\"drm/fbdev-dma: Only install deferred I/O if necessary\") initializes deferred I/O only if it is used. drm_fbdev_dma_fb_destroy() however calls fb_deferred_io_cleanup() unconditionally with struct fb_info.fbdefio == NULL. KASAN with the out-of-tree Apple silicon display driver posts following warning from __flush_work() of a random struct work_struct instead of the expected NULL pointer derefs. [ 22.053799] ------------[ cut here ]------------ [ 22.054832] WARNING: CPU: 2 PID: 1 at kernel/workqueue.c:4177 __flush_work+0x4d8/0x580 [ 22.056597] Modules linked in: uhid bnep uinput nls_ascii ip6_tables ip_tables i2c_dev loop fuse dm_multipath nfnetlink zram hid_magicmouse btrfs xor xor_neon brcmfmac_wcc raid6_pq hci_bcm4377 bluetooth brcmfmac hid_apple brcmutil nvmem_spmi_mfd simple_mfd_spmi dockchannel_hid cfg80211 joydev regmap_spmi nvme_apple ecdh_generic ecc macsmc_hid rfkill dwc3 appledrm snd_soc_macaudio macsmc_power nvme_core apple_isp phy_apple_atc apple_sart apple_rtkit_helper apple_dockchannel tps6598x macsmc_hwmon snd_soc_cs42l84 videobuf2_v4l2 spmi_apple_controller nvmem_apple_efuses videobuf2_dma_sg apple_z2 videobuf2_memops spi_nor panel_summit videobuf2_common asahi videodev pwm_apple apple_dcp snd_soc_apple_mca apple_admac spi_apple clk_apple_nco i2c_pasemi_platform snd_pcm_dmaengine mc i2c_pasemi_core mux_core ofpart adpdrm drm_dma_helper apple_dart apple_soc_cpufreq leds_pwm phram [ 22.073768] CPU: 2 UID: 0 PID: 1 Comm: systemd-shutdow Not tainted 6.11.2-asahi+ #asahi-dev [ 22.075612] Hardware name: Apple MacBook Pro (13-inch, M2, 2022) (DT) [ 22.077032] pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 22.078567] pc : __flush_work+0x4d8/0x580 [ 22.079471] lr : __flush_work+0x54/0x580 [ 22.080345] sp : ffffc000836ef820 [ 22.081089] x29: ffffc000836ef880 x28: 0000000000000000 x27: ffff80002ddb7128 [ 22.082678] x26: dfffc00000000000 x25: 1ffff000096f0c57 x24: ffffc00082d3e358 [ 22.084263] x23: ffff80004b7862b8 x22: dfffc00000000000 x21: ffff80005aa1d470 [ 22.085855] x20: ffff80004b786000 x19: ffff80004b7862a0 x18: 0000000000000000 [ 22.087439] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000005 [ 22.089030] x14: 1ffff800106ddf0a x13: 0000000000000000 x12: 0000000000000000 [ 22.090618] x11: ffffb800106ddf0f x10: dfffc00000000000 x9 : 1ffff800106ddf0e [ 22.092206] x8 : 0000000000000000 x7 : aaaaaaaaaaaaaaaa x6 : 0000000000000001 [ 22.093790] x5 : ffffc000836ef728 x4 : 0000000000000000 x3 : 0000000000000020 [ 22.095368] x2 : 0000000000000008 x1 : 00000000000000aa x0 : 0000000000000000 [ 22.096955] Call trace: [ 22.097505] __flush_work+0x4d8/0x580 [ 22.098330] flush_delayed_work+0x80/0xb8 [ 22.099231] fb_deferred_io_cleanup+0x3c/0x130 [ 22.100217] drm_fbdev_dma_fb_destroy+0x6c/0xe0 [drm_dma_helper] [ 22.101559] unregister_framebuffer+0x210/0x2f0 [ 22.102575] drm_fb_helper_unregister_info+0x48/0x60 [ 22.103683] drm_fbdev_dma_client_unregister+0x4c/0x80 [drm_dma_helper] [ 22.105147] drm_client_dev_unregister+0x1cc/0x230 [ 22.106217] drm_dev_unregister+0x58/0x570 [ 22.107125] apple_drm_unbind+0x50/0x98 [appledrm] [ 22.108199] component_del+0x1f8/0x3a8 [ 22.109042] dcp_platform_shutdown+0x24/0x38 [apple_dcp] [ 22.110357] platform_shutdown+0x70/0x90 [ 22.111219] device_shutdown+0x368/0x4d8 [ 22.112095] kernel_restart+0x6c/0x1d0 [ 22.112946] __arm64_sys_reboot+0x1c8/0x328 [ 22.113868] invoke_syscall+0x78/0x1a8 [ 22.114703] do_el0_svc+0x124/0x1a0 [ 22.115498] el0_svc+0x3c/0xe0 [ 22.116181] el0t_64_sync_handler+0x70/0xc0 [ 22.117110] el0t_64_sync+0x190/0x198 [ 22.117931] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50092", "url": "https://ubuntu.com/security/CVE-2024-50092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netconsole: fix wrong warning A warning is triggered when there is insufficient space in the buffer for userdata. However, this is not an issue since userdata will be sent in the next iteration. Current warning message: ------------[ cut here ]------------ WARNING: CPU: 13 PID: 3013042 at drivers/net/netconsole.c:1122 write_ext_msg+0x3b6/0x3d0 ? write_ext_msg+0x3b6/0x3d0 console_flush_all+0x1e9/0x330 The code incorrectly issues a warning when this_chunk is zero, which is a valid scenario. The warning should only be triggered when this_chunk is negative.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50038", "url": "https://ubuntu.com/security/CVE-2024-50038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xtables: avoid NFPROTO_UNSPEC where needed syzbot managed to call xt_cluster match via ebtables: WARNING: CPU: 0 PID: 11 at net/netfilter/xt_cluster.c:72 xt_cluster_mt+0x196/0x780 [..] ebt_do_table+0x174b/0x2a40 Module registers to NFPROTO_UNSPEC, but it assumes ipv4/ipv6 packet processing. As this is only useful to restrict locally terminating TCP/UDP traffic, register this for ipv4 and ipv6 family only. Pablo points out that this is a general issue, direct users of the set/getsockopt interface can call into targets/matches that were only intended for use with ip(6)tables. Check all UNSPEC matches and targets for similar issues: - matches and targets are fine except if they assume skb_network_header() is valid -- this is only true when called from inet layer: ip(6) stack pulls the ip/ipv6 header into linear data area. - targets that return XT_CONTINUE or other xtables verdicts must be restricted too, they are incompatbile with the ebtables traverser, e.g. EBT_CONTINUE is a completely different value than XT_CONTINUE. Most matches/targets are changed to register for NFPROTO_IPV4/IPV6, as they are provided for use by ip(6)tables. The MARK target is also used by arptables, so register for NFPROTO_ARP too. While at it, bail out if connbytes fails to enable the corresponding conntrack family. This change passes the selftests in iptables.git.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50039", "url": "https://ubuntu.com/security/CVE-2024-50039", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: accept TCA_STAB only for root qdisc Most qdiscs maintain their backlog using qdisc_pkt_len(skb) on the assumption it is invariant between the enqueue() and dequeue() handlers. Unfortunately syzbot can crash a host rather easily using a TBF + SFQ combination, with an STAB on SFQ [1] We can't support TCA_STAB on arbitrary level, this would require to maintain per-qdisc storage. [1] [ 88.796496] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 88.798611] #PF: supervisor read access in kernel mode [ 88.799014] #PF: error_code(0x0000) - not-present page [ 88.799506] PGD 0 P4D 0 [ 88.799829] Oops: Oops: 0000 [#1] SMP NOPTI [ 88.800569] CPU: 14 UID: 0 PID: 2053 Comm: b371744477 Not tainted 6.12.0-rc1-virtme #1117 [ 88.801107] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 88.801779] RIP: 0010:sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq [ 88.802544] Code: 0f b7 50 12 48 8d 04 d5 00 00 00 00 48 89 d6 48 29 d0 48 8b 91 c0 01 00 00 48 c1 e0 03 48 01 c2 66 83 7a 1a 00 7e c0 48 8b 3a <4c> 8b 07 4c 89 02 49 89 50 08 48 c7 47 08 00 00 00 00 48 c7 07 00 All code ======== 0:\t0f b7 50 12 \tmovzwl 0x12(%rax),%edx 4:\t48 8d 04 d5 00 00 00 \tlea 0x0(,%rdx,8),%rax b:\t00 c:\t48 89 d6 \tmov %rdx,%rsi f:\t48 29 d0 \tsub %rdx,%rax 12:\t48 8b 91 c0 01 00 00 \tmov 0x1c0(%rcx),%rdx 19:\t48 c1 e0 03 \tshl $0x3,%rax 1d:\t48 01 c2 \tadd %rax,%rdx 20:\t66 83 7a 1a 00 \tcmpw $0x0,0x1a(%rdx) 25:\t7e c0 \tjle 0xffffffffffffffe7 27:\t48 8b 3a \tmov (%rdx),%rdi 2a:*\t4c 8b 07 \tmov (%rdi),%r8\t\t<-- trapping instruction 2d:\t4c 89 02 \tmov %r8,(%rdx) 30:\t49 89 50 08 \tmov %rdx,0x8(%r8) 34:\t48 c7 47 08 00 00 00 \tmovq $0x0,0x8(%rdi) 3b:\t00 3c:\t48 \trex.W 3d:\tc7 \t.byte 0xc7 3e:\t07 \t(bad) \t... Code starting with the faulting instruction =========================================== 0:\t4c 8b 07 \tmov (%rdi),%r8 3:\t4c 89 02 \tmov %r8,(%rdx) 6:\t49 89 50 08 \tmov %rdx,0x8(%r8) a:\t48 c7 47 08 00 00 00 \tmovq $0x0,0x8(%rdi) 11:\t00 12:\t48 \trex.W 13:\tc7 \t.byte 0xc7 14:\t07 \t(bad) \t... [ 88.803721] RSP: 0018:ffff9a1f892b7d58 EFLAGS: 00000206 [ 88.804032] RAX: 0000000000000000 RBX: ffff9a1f8420c800 RCX: ffff9a1f8420c800 [ 88.804560] RDX: ffff9a1f81bc1440 RSI: 0000000000000000 RDI: 0000000000000000 [ 88.805056] RBP: ffffffffc04bb0e0 R08: 0000000000000001 R09: 00000000ff7f9a1f [ 88.805473] R10: 000000000001001b R11: 0000000000009a1f R12: 0000000000000140 [ 88.806194] R13: 0000000000000001 R14: ffff9a1f886df400 R15: ffff9a1f886df4ac [ 88.806734] FS: 00007f445601a740(0000) GS:ffff9a2e7fd80000(0000) knlGS:0000000000000000 [ 88.807225] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 88.807672] CR2: 0000000000000000 CR3: 000000050cc46000 CR4: 00000000000006f0 [ 88.808165] Call Trace: [ 88.808459] [ 88.808710] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434) [ 88.809261] ? page_fault_oops (arch/x86/mm/fault.c:715) [ 88.809561] ? exc_page_fault (./arch/x86/include/asm/irqflags.h:26 ./arch/x86/include/asm/irqflags.h:87 ./arch/x86/include/asm/irqflags.h:147 arch/x86/mm/fault.c:1489 arch/x86/mm/fault.c:1539) [ 88.809806] ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623) [ 88.810074] ? sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq [ 88.810411] sfq_reset (net/sched/sch_sfq.c:525) sch_sfq [ 88.810671] qdisc_reset (./include/linux/skbuff.h:2135 ./include/linux/skbuff.h:2441 ./include/linux/skbuff.h:3304 ./include/linux/skbuff.h:3310 net/sched/sch_g ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50040", "url": "https://ubuntu.com/security/CVE-2024-50040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: igb: Do not bring the device up after non-fatal error Commit 004d25060c78 (\"igb: Fix igb_down hung on surprise removal\") changed igb_io_error_detected() to ignore non-fatal pcie errors in order to avoid hung task that can happen when igb_down() is called multiple times. This caused an issue when processing transient non-fatal errors. igb_io_resume(), which is called after igb_io_error_detected(), assumes that device is brought down by igb_io_error_detected() if the interface is up. This resulted in panic with stacktrace below. [ T3256] igb 0000:09:00.0 haeth0: igb: haeth0 NIC Link is Down [ T292] pcieport 0000:00:1c.5: AER: Uncorrected (Non-Fatal) error received: 0000:09:00.0 [ T292] igb 0000:09:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, (Requester ID) [ T292] igb 0000:09:00.0: device [8086:1537] error status/mask=00004000/00000000 [ T292] igb 0000:09:00.0: [14] CmpltTO [ 200.105524,009][ T292] igb 0000:09:00.0: AER: TLP Header: 00000000 00000000 00000000 00000000 [ T292] pcieport 0000:00:1c.5: AER: broadcast error_detected message [ T292] igb 0000:09:00.0: Non-correctable non-fatal error reported. [ T292] pcieport 0000:00:1c.5: AER: broadcast mmio_enabled message [ T292] pcieport 0000:00:1c.5: AER: broadcast resume message [ T292] ------------[ cut here ]------------ [ T292] kernel BUG at net/core/dev.c:6539! [ T292] invalid opcode: 0000 [#1] PREEMPT SMP [ T292] RIP: 0010:napi_enable+0x37/0x40 [ T292] Call Trace: [ T292] [ T292] ? die+0x33/0x90 [ T292] ? do_trap+0xdc/0x110 [ T292] ? napi_enable+0x37/0x40 [ T292] ? do_error_trap+0x70/0xb0 [ T292] ? napi_enable+0x37/0x40 [ T292] ? napi_enable+0x37/0x40 [ T292] ? exc_invalid_op+0x4e/0x70 [ T292] ? napi_enable+0x37/0x40 [ T292] ? asm_exc_invalid_op+0x16/0x20 [ T292] ? napi_enable+0x37/0x40 [ T292] igb_up+0x41/0x150 [ T292] igb_io_resume+0x25/0x70 [ T292] report_resume+0x54/0x70 [ T292] ? report_frozen_detected+0x20/0x20 [ T292] pci_walk_bus+0x6c/0x90 [ T292] ? aer_print_port_info+0xa0/0xa0 [ T292] pcie_do_recovery+0x22f/0x380 [ T292] aer_process_err_devices+0x110/0x160 [ T292] aer_isr+0x1c1/0x1e0 [ T292] ? disable_irq_nosync+0x10/0x10 [ T292] irq_thread_fn+0x1a/0x60 [ T292] irq_thread+0xe3/0x1a0 [ T292] ? irq_set_affinity_notifier+0x120/0x120 [ T292] ? irq_affinity_notify+0x100/0x100 [ T292] kthread+0xe2/0x110 [ T292] ? kthread_complete_and_exit+0x20/0x20 [ T292] ret_from_fork+0x2d/0x50 [ T292] ? kthread_complete_and_exit+0x20/0x20 [ T292] ret_from_fork_asm+0x11/0x20 [ T292] To fix this issue igb_io_resume() checks if the interface is running and the device is not down this means igb_io_error_detected() did not bring the device down and there is no need to bring it up.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50041", "url": "https://ubuntu.com/security/CVE-2024-50041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: Fix macvlan leak by synchronizing access to mac_filter_hash This patch addresses a macvlan leak issue in the i40e driver caused by concurrent access to vsi->mac_filter_hash. The leak occurs when multiple threads attempt to modify the mac_filter_hash simultaneously, leading to inconsistent state and potential memory leaks. To fix this, we now wrap the calls to i40e_del_mac_filter() and zeroing vf->default_lan_addr.addr with spin_lock/unlock_bh(&vsi->mac_filter_hash_lock), ensuring atomic operations and preventing concurrent access. Additionally, we add lockdep_assert_held(&vsi->mac_filter_hash_lock) in i40e_add_mac_filter() to help catch similar issues in the future. Reproduction steps: 1. Spawn VFs and configure port vlan on them. 2. Trigger concurrent macvlan operations (e.g., adding and deleting \tportvlan and/or mac filters). 3. Observe the potential memory leak and inconsistent state in the \tmac_filter_hash. This synchronization ensures the integrity of the mac_filter_hash and prevents the described leak.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50042", "url": "https://ubuntu.com/security/CVE-2024-50042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix increasing MSI-X on VF Increasing MSI-X value on a VF leads to invalid memory operations. This is caused by not reallocating some arrays. Reproducer: modprobe ice echo 0 > /sys/bus/pci/devices/$PF_PCI/sriov_drivers_autoprobe echo 1 > /sys/bus/pci/devices/$PF_PCI/sriov_numvfs echo 17 > /sys/bus/pci/devices/$VF0_PCI/sriov_vf_msix_count Default MSI-X is 16, so 17 and above triggers this issue. KASAN reports: BUG: KASAN: slab-out-of-bounds in ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] Read of size 8 at addr ffff8888b937d180 by task bash/28433 (...) Call Trace: (...) ? ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] kasan_report+0xed/0x120 ? ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] ice_vsi_cfg_def+0x3360/0x4770 [ice] ? mutex_unlock+0x83/0xd0 ? __pfx_ice_vsi_cfg_def+0x10/0x10 [ice] ? __pfx_ice_remove_vsi_lkup_fltr+0x10/0x10 [ice] ice_vsi_cfg+0x7f/0x3b0 [ice] ice_vf_reconfig_vsi+0x114/0x210 [ice] ice_sriov_set_msix_vec_count+0x3d0/0x960 [ice] sriov_vf_msix_count_store+0x21c/0x300 (...) Allocated by task 28201: (...) ice_vsi_cfg_def+0x1c8e/0x4770 [ice] ice_vsi_cfg+0x7f/0x3b0 [ice] ice_vsi_setup+0x179/0xa30 [ice] ice_sriov_configure+0xcaa/0x1520 [ice] sriov_numvfs_store+0x212/0x390 (...) To fix it, use ice_vsi_rebuild() instead of ice_vf_reconfig_vsi(). This causes the required arrays to be reallocated taking the new queue count into account (ice_vsi_realloc_stat_arrays()). Set req_txq and req_rxq before ice_vsi_rebuild(), so that realloc uses the newly set queue count. Additionally, ice_vsi_rebuild() does not remove VSI filters (ice_fltr_remove_all()), so ice_vf_init_host_cfg() is no longer necessary.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50093", "url": "https://ubuntu.com/security/CVE-2024-50093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: intel: int340x: processor: Fix warning during module unload The processor_thermal driver uses pcim_device_enable() to enable a PCI device, which means the device will be automatically disabled on driver detach. Thus there is no need to call pci_disable_device() again on it. With recent PCI device resource management improvements, e.g. commit f748a07a0b64 (\"PCI: Remove legacy pcim_release()\"), this problem is exposed and triggers the warining below. [ 224.010735] proc_thermal_pci 0000:00:04.0: disabling already-disabled device [ 224.010747] WARNING: CPU: 8 PID: 4442 at drivers/pci/pci.c:2250 pci_disable_device+0xe5/0x100 ... [ 224.010844] Call Trace: [ 224.010845] [ 224.010847] ? show_regs+0x6d/0x80 [ 224.010851] ? __warn+0x8c/0x140 [ 224.010854] ? pci_disable_device+0xe5/0x100 [ 224.010856] ? report_bug+0x1c9/0x1e0 [ 224.010859] ? handle_bug+0x46/0x80 [ 224.010862] ? exc_invalid_op+0x1d/0x80 [ 224.010863] ? asm_exc_invalid_op+0x1f/0x30 [ 224.010867] ? pci_disable_device+0xe5/0x100 [ 224.010869] ? pci_disable_device+0xe5/0x100 [ 224.010871] ? kfree+0x21a/0x2b0 [ 224.010873] pcim_disable_device+0x20/0x30 [ 224.010875] devm_action_release+0x16/0x20 [ 224.010878] release_nodes+0x47/0xc0 [ 224.010880] devres_release_all+0x9f/0xe0 [ 224.010883] device_unbind_cleanup+0x12/0x80 [ 224.010885] device_release_driver_internal+0x1ca/0x210 [ 224.010887] driver_detach+0x4e/0xa0 [ 224.010889] bus_remove_driver+0x6f/0xf0 [ 224.010890] driver_unregister+0x35/0x60 [ 224.010892] pci_unregister_driver+0x44/0x90 [ 224.010894] proc_thermal_pci_driver_exit+0x14/0x5f0 [processor_thermal_device_pci] ... [ 224.010921] ---[ end trace 0000000000000000 ]--- Remove the excess pci_disable_device() calls. [ rjw: Subject and changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50043", "url": "https://ubuntu.com/security/CVE-2024-50043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix possible badness in FREE_STATEID When multiple FREE_STATEIDs are sent for the same delegation stateid, it can lead to a possible either use-after-free or counter refcount underflow errors. In nfsd4_free_stateid() under the client lock we find a delegation stateid, however the code drops the lock before calling nfs4_put_stid(), that allows another FREE_STATE to find the stateid again. The first one will proceed to then free the stateid which leads to either use-after-free or decrementing already zeroed counter.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50044", "url": "https://ubuntu.com/security/CVE-2024-50044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change rfcomm_sk_state_change attempts to use sock_lock so it must never be called with it locked but rfcomm_sock_ioctl always attempt to lock it causing the following trace: ====================================================== WARNING: possible circular locking dependency detected 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Not tainted ------------------------------------------------------ syz-executor386/5093 is trying to acquire lock: ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1671 [inline] ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73 but task is already holding lock: ffff88807badfd28 (&d->lock){+.+.}-{3:3}, at: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50045", "url": "https://ubuntu.com/security/CVE-2024-50045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: br_netfilter: fix panic with metadata_dst skb Fix a kernel panic in the br_netfilter module when sending untagged traffic via a VxLAN device. This happens during the check for fragmentation in br_nf_dev_queue_xmit. It is dependent on: 1) the br_netfilter module being loaded; 2) net.bridge.bridge-nf-call-iptables set to 1; 3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port; 4) untagged frames with size higher than the VxLAN MTU forwarded/flooded When forwarding the untagged packet to the VxLAN bridge port, before the netfilter hooks are called, br_handle_egress_vlan_tunnel is called and changes the skb_dst to the tunnel dst. The tunnel_dst is a metadata type of dst, i.e., skb_valid_dst(skb) is false, and metadata->dst.dev is NULL. Then in the br_netfilter hooks, in br_nf_dev_queue_xmit, there's a check for frames that needs to be fragmented: frames with higher MTU than the VxLAN device end up calling br_nf_ip_fragment, which in turns call ip_skb_dst_mtu. The ip_dst_mtu tries to use the skb_dst(skb) as if it was a valid dst with valid dst->dev, thus the crash. This case was never supported in the first place, so drop the packet instead. PING 10.0.0.2 (10.0.0.2) from 0.0.0.0 h1-eth0: 2000(2028) bytes of data. [ 176.291791] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000110 [ 176.292101] Mem abort info: [ 176.292184] ESR = 0x0000000096000004 [ 176.292322] EC = 0x25: DABT (current EL), IL = 32 bits [ 176.292530] SET = 0, FnV = 0 [ 176.292709] EA = 0, S1PTW = 0 [ 176.292862] FSC = 0x04: level 0 translation fault [ 176.293013] Data abort info: [ 176.293104] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 176.293488] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 176.293787] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 176.293995] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043ef5000 [ 176.294166] [0000000000000110] pgd=0000000000000000, p4d=0000000000000000 [ 176.294827] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 176.295252] Modules linked in: vxlan ip6_udp_tunnel udp_tunnel veth br_netfilter bridge stp llc ipv6 crct10dif_ce [ 176.295923] CPU: 0 PID: 188 Comm: ping Not tainted 6.8.0-rc3-g5b3fbd61b9d1 #2 [ 176.296314] Hardware name: linux,dummy-virt (DT) [ 176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 176.296808] pc : br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.297382] lr : br_nf_dev_queue_xmit+0x2ac/0x4ec [br_netfilter] [ 176.297636] sp : ffff800080003630 [ 176.297743] x29: ffff800080003630 x28: 0000000000000008 x27: ffff6828c49ad9f8 [ 176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24: 00000000000003e8 [ 176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21: ffff6828c3b16d28 [ 176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18: 0000000000000014 [ 176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15: 0000000095744632 [ 176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12: ffffb7e137926a70 [ 176.299574] x11: 0000000000000001 x10: ffff6828c3f1c898 x9 : 0000000000000000 [ 176.300049] x8 : ffff6828c49bf070 x7 : 0008460f18d5f20e x6 : f20e0100bebafeca [ 176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 : 0000000000000000 [ 176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 : ffff6828c7f918f0 [ 176.300889] Call trace: [ 176.301123] br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.301411] br_nf_post_routing+0x2a8/0x3e4 [br_netfilter] [ 176.301703] nf_hook_slow+0x48/0x124 [ 176.302060] br_forward_finish+0xc8/0xe8 [bridge] [ 176.302371] br_nf_hook_thresh+0x124/0x134 [br_netfilter] [ 176.302605] br_nf_forward_finish+0x118/0x22c [br_netfilter] [ 176.302824] br_nf_forward_ip.part.0+0x264/0x290 [br_netfilter] [ 176.303136] br_nf_forward+0x2b8/0x4e0 [br_netfilter] [ 176.303359] nf_hook_slow+0x48/0x124 [ 176.303 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50094", "url": "https://ubuntu.com/security/CVE-2024-50094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sfc: Don't invoke xdp_do_flush() from netpoll. Yury reported a crash in the sfc driver originated from netpoll_send_udp(). The netconsole sends a message and then netpoll invokes the driver's NAPI function with a budget of zero. It is dedicated to allow driver to free TX resources, that it may have used while sending the packet. In the netpoll case the driver invokes xdp_do_flush() unconditionally, leading to crash because bpf_net_context was never assigned. Invoke xdp_do_flush() only if budget is not zero.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50188", "url": "https://ubuntu.com/security/CVE-2024-50188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: dp83869: fix memory corruption when enabling fiber When configuring the fiber port, the DP83869 PHY driver incorrectly calls linkmode_set_bit() with a bit mask (1 << 10) rather than a bit number (10). This corrupts some other memory location -- in case of arm64 the priv pointer in the same structure. Since the advertising flags are updated from supported at the end of the function the incorrect line isn't needed at all and can be removed.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50046", "url": "https://ubuntu.com/security/CVE-2024-50046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies() On the node of an NFS client, some files saved in the mountpoint of the NFS server were copied to another location of the same NFS server. Accidentally, the nfs42_complete_copies() got a NULL-pointer dereference crash with the following syslog: [232064.838881] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232064.839360] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232066.588183] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 [232066.588586] Mem abort info: [232066.588701] ESR = 0x0000000096000007 [232066.588862] EC = 0x25: DABT (current EL), IL = 32 bits [232066.589084] SET = 0, FnV = 0 [232066.589216] EA = 0, S1PTW = 0 [232066.589340] FSC = 0x07: level 3 translation fault [232066.589559] Data abort info: [232066.589683] ISV = 0, ISS = 0x00000007 [232066.589842] CM = 0, WnR = 0 [232066.589967] user pgtable: 64k pages, 48-bit VAs, pgdp=00002000956ff400 [232066.590231] [0000000000000058] pgd=08001100ae100003, p4d=08001100ae100003, pud=08001100ae100003, pmd=08001100b3c00003, pte=0000000000000000 [232066.590757] Internal error: Oops: 96000007 [#1] SMP [232066.590958] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm vhost_net vhost vhost_iotlb tap tun ipt_rpfilter xt_multiport ip_set_hash_ip ip_set_hash_net xfrm_interface xfrm6_tunnel tunnel4 tunnel6 esp4 ah4 wireguard libcurve25519_generic veth xt_addrtype xt_set nf_conntrack_netlink ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_bitmap_port ip_set_hash_ipport dummy ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs iptable_filter sch_ingress nfnetlink_cttimeout vport_gre ip_gre ip_tunnel gre vport_geneve geneve vport_vxlan vxlan ip6_udp_tunnel udp_tunnel openvswitch nf_conncount dm_round_robin dm_service_time dm_multipath xt_nat xt_MASQUERADE nft_chain_nat nf_nat xt_mark xt_conntrack xt_comment nft_compat nft_counter nf_tables nfnetlink ocfs2 ocfs2_nodemanager ocfs2_stackglue iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_ssif nbd overlay 8021q garp mrp bonding tls rfkill sunrpc ext4 mbcache jbd2 [232066.591052] vfat fat cas_cache cas_disk ses enclosure scsi_transport_sas sg acpi_ipmi ipmi_si ipmi_devintf ipmi_msghandler ip_tables vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio dm_mirror dm_region_hash dm_log dm_mod nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc fuse xfs libcrc32c ast drm_vram_helper qla2xxx drm_kms_helper syscopyarea crct10dif_ce sysfillrect ghash_ce sysimgblt sha2_ce fb_sys_fops cec sha256_arm64 sha1_ce drm_ttm_helper ttm nvme_fc igb sbsa_gwdt nvme_fabrics drm nvme_core i2c_algo_bit i40e scsi_transport_fc megaraid_sas aes_neon_bs [232066.596953] CPU: 6 PID: 4124696 Comm: 10.253.166.125- Kdump: loaded Not tainted 5.15.131-9.cl9_ocfs2.aarch64 #1 [232066.597356] Hardware name: Great Wall .\\x93\\x8e...RF6260 V5/GWMSSE2GL1T, BIOS T656FBE_V3.0.18 2024-01-06 [232066.597721] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [232066.598034] pc : nfs4_reclaim_open_state+0x220/0x800 [nfsv4] [232066.598327] lr : nfs4_reclaim_open_state+0x12c/0x800 [nfsv4] [232066.598595] sp : ffff8000f568fc70 [232066.598731] x29: ffff8000f568fc70 x28: 0000000000001000 x27: ffff21003db33000 [232066.599030] x26: ffff800005521ae0 x25: ffff0100f98fa3f0 x24: 0000000000000001 [232066.599319] x23: ffff800009920008 x22: ffff21003db33040 x21: ffff21003db33050 [232066.599628] x20: ffff410172fe9e40 x19: ffff410172fe9e00 x18: 0000000000000000 [232066.599914] x17: 0000000000000000 x16: 0000000000000004 x15: 0000000000000000 [232066.600195] x14: 0000000000000000 x13: ffff800008e685a8 x12: 00000000eac0c6e6 [232066.600498] x11: 00000000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50190", "url": "https://ubuntu.com/security/CVE-2024-50190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix memleak in ice_init_tx_topology() Fix leak of the FW blob (DDP pkg). Make ice_cfg_tx_topo() const-correct, so ice_init_tx_topology() can avoid copying whole FW blob. Copy just the topology section, and only when needed. Reuse the buffer allocated for the read of the current topology. This was found by kmemleak, with the following trace for each PF: [] kmemdup_noprof+0x1d/0x50 [] ice_init_ddp_config+0x100/0x220 [ice] [] ice_init_dev+0x6f/0x200 [ice] [] ice_init+0x29/0x560 [ice] [] ice_probe+0x21d/0x310 [ice] Constify ice_cfg_tx_topo() @buf parameter. This cascades further down to few more functions.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50180", "url": "https://ubuntu.com/security/CVE-2024-50180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: sisfb: Fix strbuf array overflow The values of the variables xres and yres are placed in strbuf. These variables are obtained from strbuf1. The strbuf1 array contains digit characters and a space if the array contains non-digit characters. Then, when executing sprintf(strbuf, \"%ux%ux8\", xres, yres); more than 16 bytes will be written to strbuf. It is suggested to increase the size of the strbuf array to 24. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06: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": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50048", "url": "https://ubuntu.com/security/CVE-2024-50048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: Fix a NULL pointer dereference issue in fbcon_putcs syzbot has found a NULL pointer dereference bug in fbcon. Here is the simplified C reproducer: struct param { \tuint8_t type; \tstruct tiocl_selection ts; }; int main() { \tstruct fb_con2fbmap con2fb; \tstruct param param; \tint fd = open(\"/dev/fb1\", 0, 0); \tcon2fb.console = 0x19; \tcon2fb.framebuffer = 0; \tioctl(fd, FBIOPUT_CON2FBMAP, &con2fb); \tparam.type = 2; \tparam.ts.xs = 0; param.ts.ys = 0; \tparam.ts.xe = 0; param.ts.ye = 0; \tparam.ts.sel_mode = 0; \tint fd1 = open(\"/dev/tty1\", O_RDWR, 0); \tioctl(fd1, TIOCLINUX, ¶m); \tcon2fb.console = 1; \tcon2fb.framebuffer = 0; \tioctl(fd, FBIOPUT_CON2FBMAP, &con2fb); \treturn 0; } After calling ioctl(fd1, TIOCLINUX, ¶m), the subsequent ioctl(fd, FBIOPUT_CON2FBMAP, &con2fb) causes the kernel to follow a different execution path: set_con2fb_map -> con2fb_init_display -> fbcon_set_disp -> redraw_screen -> hide_cursor -> clear_selection -> highlight -> invert_screen -> do_update_region -> fbcon_putcs -> ops->putcs Since ops->putcs is a NULL pointer, this leads to a kernel panic. To prevent this, we need to call set_blitting_type() within set_con2fb_map() to properly initialize ops->putcs.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50049", "url": "https://ubuntu.com/security/CVE-2024-50049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before dereferencing se [WHAT & HOW] se is null checked previously in the same function, indicating it might be null; therefore, it must be checked when used again. This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50090", "url": "https://ubuntu.com/security/CVE-2024-50090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/oa: Fix overflow in oa batch buffer By default xe_bb_create_job() appends a MI_BATCH_BUFFER_END to batch buffer, this is not a problem if batch buffer is only used once but oa reuses the batch buffer for the same metric and at each call it appends a MI_BATCH_BUFFER_END, printing the warning below and then overflowing. [ 381.072016] ------------[ cut here ]------------ [ 381.072019] xe 0000:00:02.0: [drm] Assertion `bb->len * 4 + bb_prefetch(q->gt) <= size` failed! platform: LUNARLAKE subplatform: 1 graphics: Xe2_LPG / Xe2_HPG 20.04 step B0 media: Xe2_LPM / Xe2_HPM 20.00 step B0 tile: 0 VRAM 0 B GT: 0 type 1 So here checking if batch buffer already have MI_BATCH_BUFFER_END if not append it. v2: - simply fix, suggestion from Ashutosh (cherry picked from commit 9ba0e0f30ca42a98af3689460063edfb6315718a)", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50183", "url": "https://ubuntu.com/security/CVE-2024-50183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV instance Deleting an NPIV instance requires all fabric ndlps to be released before an NPIV's resources can be torn down. Failure to release fabric ndlps beforehand opens kref imbalance race conditions. Fix by forcing the DA_ID to complete synchronously with usage of wait_queue.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50055", "url": "https://ubuntu.com/security/CVE-2024-50055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: driver core: bus: Fix double free in driver API bus_register() For bus_register(), any error which happens after kset_register() will cause that @priv are freed twice, fixed by setting @priv with NULL after the first free.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50091", "url": "https://ubuntu.com/security/CVE-2024-50091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm vdo: don't refer to dedupe_context after releasing it Clear the dedupe_context pointer in a data_vio whenever ownership of the context is lost, so that vdo can't examine it accidentally.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50056", "url": "https://ubuntu.com/security/CVE-2024-50056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: Fix ERR_PTR dereference in uvc_v4l2.c Fix potential dereferencing of ERR_PTR() in find_format_by_pix() and uvc_v4l2_enum_format(). Fix the following smatch errors: drivers/usb/gadget/function/uvc_v4l2.c:124 find_format_by_pix() error: 'fmtdesc' dereferencing possible ERR_PTR() drivers/usb/gadget/function/uvc_v4l2.c:392 uvc_v4l2_enum_format() error: 'fmtdesc' dereferencing possible ERR_PTR() Also, fix similar issue in uvc_v4l2_try_format() for potential dereferencing of ERR_PTR().", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50184", "url": "https://ubuntu.com/security/CVE-2024-50184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_pmem: Check device status before requesting flush If a pmem device is in a bad status, the driver side could wait for host ack forever in virtio_pmem_flush(), causing the system to hang. So add a status check in the beginning of virtio_pmem_flush() to return early if the device is not activated.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50057", "url": "https://ubuntu.com/security/CVE-2024-50057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: tipd: Free IRQ only if it was requested before In polling mode, if no IRQ was requested there is no need to free it. Call devm_free_irq() only if client->irq is set. This fixes the warning caused by the tps6598x module removal: WARNING: CPU: 2 PID: 333 at kernel/irq/devres.c:144 devm_free_irq+0x80/0x8c ... ... Call trace: devm_free_irq+0x80/0x8c tps6598x_remove+0x28/0x88 [tps6598x] i2c_device_remove+0x2c/0x9c device_remove+0x4c/0x80 device_release_driver_internal+0x1cc/0x228 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 i2c_del_driver+0x54/0x64 tps6598x_i2c_driver_exit+0x18/0xc3c [tps6598x] __arm64_sys_delete_module+0x184/0x264 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc8/0xe8 do_el0_svc+0x20/0x2c el0_svc+0x28/0x98 el0t_64_sync_handler+0x13c/0x158 el0t_64_sync+0x190/0x194", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50058", "url": "https://ubuntu.com/security/CVE-2024-50058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: protect uart_port_dtr_rts() in uart_shutdown() too Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part 3) added few uport == NULL checks. It added one to uart_shutdown(), so the commit assumes, uport can be NULL in there. But right after that protection, there is an unprotected \"uart_port_dtr_rts(uport, false);\" call. That is invoked only if HUPCL is set, so I assume that is the reason why we do not see lots of these reports. Or it cannot be NULL at this point at all for some reason :P. Until the above is investigated, stay on the safe side and move this dereference to the if too. I got this inconsistency from Coverity under CID 1585130. Thanks.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50181", "url": "https://ubuntu.com/security/CVE-2024-50181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: imx: Remove CLK_SET_PARENT_GATE for DRAM mux for i.MX7D For i.MX7D DRAM related mux clock, the clock source change should ONLY be done done in low level asm code without accessing DRAM, and then calling clk API to sync the HW clock status with clk tree, it should never touch real clock source switch via clk API, so CLK_SET_PARENT_GATE flag should NOT be added, otherwise, DRAM's clock parent will be disabled when DRAM is active, and system will hang.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50059", "url": "https://ubuntu.com/security/CVE-2024-50059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntb: ntb_hw_switchtec: Fix use after free vulnerability in switchtec_ntb_remove due to race condition In the switchtec_ntb_add function, it can call switchtec_ntb_init_sndev function, then &sndev->check_link_status_work is bound with check_link_status_work. switchtec_ntb_link_notification may be called to start the work. If we remove the module which will call switchtec_ntb_remove to make cleanup, it will free sndev through kfree(sndev), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | check_link_status_work switchtec_ntb_remove | kfree(sndev); | | if (sndev->link_force_down) | // use sndev Fix it by ensuring that the work is canceled before proceeding with the cleanup in switchtec_ntb_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50060", "url": "https://ubuntu.com/security/CVE-2024-50060", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring: check if we need to reschedule during overflow flush In terms of normal application usage, this list will always be empty. And if an application does overflow a bit, it'll have a few entries. However, nothing obviously prevents syzbot from running a test case that generates a ton of overflow entries, and then flushing them can take quite a while. Check for needing to reschedule while flushing, and drop our locks and do so if necessary. There's no state to maintain here as overflows always prune from head-of-list, hence it's fine to drop and reacquire the locks at the end of the loop.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50061", "url": "https://ubuntu.com/security/CVE-2024-50061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: cdns: Fix use after free vulnerability in cdns_i3c_master Driver Due to Race Condition In the cdns_i3c_master_probe function, &master->hj_work is bound with cdns_i3c_master_hj. And cdns_i3c_master_interrupt can call cnds_i3c_master_demux_ibis function to start the work. If we remove the module which will call cdns_i3c_master_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | cdns_i3c_master_hj cdns_i3c_master_remove | i3c_master_unregister(&master->base) | device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in cdns_i3c_master_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50062", "url": "https://ubuntu.com/security/CVE-2024-50062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-srv: Avoid null pointer deref during path establishment For RTRS path establishment, RTRS client initiates and completes con_num of connections. After establishing all its connections, the information is exchanged between the client and server through the info_req message. During this exchange, it is essential that all connections have been established, and the state of the RTRS srv path is CONNECTED. So add these sanity checks, to make sure we detect and abort process in error scenarios to avoid null pointer deref.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50095", "url": "https://ubuntu.com/security/CVE-2024-50095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mad: Improve handling of timed out WRs of mad agent Current timeout handler of mad agent acquires/releases mad_agent_priv lock for every timed out WRs. This causes heavy locking contention when higher no. of WRs are to be handled inside timeout handler. This leads to softlockup with below trace in some use cases where rdma-cm path is used to establish connection between peer nodes Trace: ----- BUG: soft lockup - CPU#4 stuck for 26s! [kworker/u128:3:19767] CPU: 4 PID: 19767 Comm: kworker/u128:3 Kdump: loaded Tainted: G OE ------- --- 5.14.0-427.13.1.el9_4.x86_64 #1 Hardware name: Dell Inc. PowerEdge R740/01YM03, BIOS 2.4.8 11/26/2019 Workqueue: ib_mad1 timeout_sends [ib_core] RIP: 0010:__do_softirq+0x78/0x2ac RSP: 0018:ffffb253449e4f98 EFLAGS: 00000246 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 000000000000001f RDX: 000000000000001d RSI: 000000003d1879ab RDI: fff363b66fd3a86b RBP: ffffb253604cbcd8 R08: 0000009065635f3b R09: 0000000000000000 R10: 0000000000000040 R11: ffffb253449e4ff8 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000040 FS: 0000000000000000(0000) GS:ffff8caa1fc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd9ec9db900 CR3: 0000000891934006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? __irq_exit_rcu+0xa1/0xc0 ? watchdog_timer_fn+0x1b2/0x210 ? __pfx_watchdog_timer_fn+0x10/0x10 ? __hrtimer_run_queues+0x127/0x2c0 ? hrtimer_interrupt+0xfc/0x210 ? __sysvec_apic_timer_interrupt+0x5c/0x110 ? sysvec_apic_timer_interrupt+0x37/0x90 ? asm_sysvec_apic_timer_interrupt+0x16/0x20 ? __do_softirq+0x78/0x2ac ? __do_softirq+0x60/0x2ac __irq_exit_rcu+0xa1/0xc0 sysvec_call_function_single+0x72/0x90 asm_sysvec_call_function_single+0x16/0x20 RIP: 0010:_raw_spin_unlock_irq+0x14/0x30 RSP: 0018:ffffb253604cbd88 EFLAGS: 00000247 RAX: 000000000001960d RBX: 0000000000000002 RCX: ffff8cad2a064800 RDX: 000000008020001b RSI: 0000000000000001 RDI: ffff8cad5d39f66c RBP: ffff8cad5d39f600 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8caa443e0c00 R11: ffffb253604cbcd8 R12: ffff8cacb8682538 R13: 0000000000000005 R14: ffffb253604cbd90 R15: ffff8cad5d39f66c cm_process_send_error+0x122/0x1d0 [ib_cm] timeout_sends+0x1dd/0x270 [ib_core] process_one_work+0x1e2/0x3b0 ? __pfx_worker_thread+0x10/0x10 worker_thread+0x50/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xdd/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x50 Simplified timeout handler by creating local list of timed out WRs and invoke send handler post creating the list. The new method acquires/ releases lock once to fetch the list and hence helps to reduce locking contetiong when processing higher no. of WRs", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50063", "url": "https://ubuntu.com/security/CVE-2024-50063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Prevent tail call between progs attached to different hooks bpf progs can be attached to kernel functions, and the attached functions can take different parameters or return different return values. If prog attached to one kernel function tail calls prog attached to another kernel function, the ctx access or return value verification could be bypassed. For example, if prog1 is attached to func1 which takes only 1 parameter and prog2 is attached to func2 which takes two parameters. Since verifier assumes the bpf ctx passed to prog2 is constructed based on func2's prototype, verifier allows prog2 to access the second parameter from the bpf ctx passed to it. The problem is that verifier does not prevent prog1 from passing its bpf ctx to prog2 via tail call. In this case, the bpf ctx passed to prog2 is constructed from func1 instead of func2, that is, the assumption for ctx access verification is bypassed. Another example, if BPF LSM prog1 is attached to hook file_alloc_security, and BPF LSM prog2 is attached to hook bpf_lsm_audit_rule_known. Verifier knows the return value rules for these two hooks, e.g. it is legal for bpf_lsm_audit_rule_known to return positive number 1, and it is illegal for file_alloc_security to return positive number. So verifier allows prog2 to return positive number 1, but does not allow prog1 to return positive number. The problem is that verifier does not prevent prog1 from calling prog2 via tail call. In this case, prog2's return value 1 will be used as the return value for prog1's hook file_alloc_security. That is, the return value rule is bypassed. This patch adds restriction for tail call to prevent such bypasses.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50191", "url": "https://ubuntu.com/security/CVE-2024-50191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: don't set SB_RDONLY after filesystem errors When the filesystem is mounted with errors=remount-ro, we were setting SB_RDONLY flag to stop all filesystem modifications. We knew this misses proper locking (sb->s_umount) and does not go through proper filesystem remount procedure but it has been the way this worked since early ext2 days and it was good enough for catastrophic situation damage mitigation. Recently, syzbot has found a way (see link) to trigger warnings in filesystem freezing because the code got confused by SB_RDONLY changing under its hands. Since these days we set EXT4_FLAGS_SHUTDOWN on the superblock which is enough to stop all filesystem modifications, modifying SB_RDONLY shouldn't be needed. So stop doing that.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50064", "url": "https://ubuntu.com/security/CVE-2024-50064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: zram: free secondary algorithms names We need to kfree() secondary algorithms names when reset zram device that had multi-streams, otherwise we leak memory. [senozhatsky@chromium.org: kfree(NULL) is legal] Link: https://lkml.kernel.org/r/20240917013021.868769-1-senozhatsky@chromium.org", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50065", "url": "https://ubuntu.com/security/CVE-2024-50065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Change to non-blocking allocation in ntfs_d_hash d_hash is done while under \"rcu-walk\" and should not sleep. __get_name() allocates using GFP_KERNEL, having the possibility to sleep when under memory pressure. Change the allocation to GFP_NOWAIT.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50089", "url": "https://ubuntu.com/security/CVE-2024-50089", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-49863", "url": "https://ubuntu.com/security/CVE-2024-49863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost/scsi: null-ptr-dereference in vhost_scsi_get_req() Since commit 3f8ca2e115e5 (\"vhost/scsi: Extract common handling code from control queue handler\") a null pointer dereference bug can be triggered when guest sends an SCSI AN request. In vhost_scsi_ctl_handle_vq(), `vc.target` is assigned with `&v_req.tmf.lun[1]` within a switch-case block and is then passed to vhost_scsi_get_req() which extracts `vc->req` and `tpg`. However, for a `VIRTIO_SCSI_T_AN_*` request, tpg is not required, so `vc.target` is set to NULL in this branch. Later, in vhost_scsi_get_req(), `vc->target` is dereferenced without being checked, leading to a null pointer dereference bug. This bug can be triggered from guest. When this bug occurs, the vhost_worker process is killed while holding `vq->mutex` and the corresponding tpg will remain occupied indefinitely. Below is the KASAN report: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 PID: 840 Comm: poc Not tainted 6.10.0+ #1 Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:vhost_scsi_get_req+0x165/0x3a0 Code: 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 02 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 65 30 4c 89 e2 48 c1 ea 03 <0f> b6 04 02 4c 89 e2 83 e2 07 38 d0 7f 08 84 c0 0f 85 be 01 00 00 RSP: 0018:ffff888017affb50 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffff88801b000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888017affcb8 RBP: ffff888017affb80 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff888017affc88 R14: ffff888017affd1c R15: ffff888017993000 FS: 000055556e076500(0000) GS:ffff88806b100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200027c0 CR3: 0000000010ed0004 CR4: 0000000000370ef0 Call Trace: ? show_regs+0x86/0xa0 ? die_addr+0x4b/0xd0 ? exc_general_protection+0x163/0x260 ? asm_exc_general_protection+0x27/0x30 ? vhost_scsi_get_req+0x165/0x3a0 vhost_scsi_ctl_handle_vq+0x2a4/0xca0 ? __pfx_vhost_scsi_ctl_handle_vq+0x10/0x10 ? __switch_to+0x721/0xeb0 ? __schedule+0xda5/0x5710 ? __kasan_check_write+0x14/0x30 ? _raw_spin_lock+0x82/0xf0 vhost_scsi_ctl_handle_kick+0x52/0x90 vhost_run_work_list+0x134/0x1b0 vhost_task_fn+0x121/0x350 ... ---[ end trace 0000000000000000 ]--- Let's add a check in vhost_scsi_get_req. [whitespace fixes]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49864", "url": "https://ubuntu.com/security/CVE-2024-49864", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix a race between socket set up and I/O thread creation In rxrpc_open_socket(), it sets up the socket and then sets up the I/O thread that will handle it. This is a problem, however, as there's a gap between the two phases in which a packet may come into rxrpc_encap_rcv() from the UDP packet but we oops when trying to wake the not-yet created I/O thread. As a quick fix, just make rxrpc_encap_rcv() discard the packet if there's no I/O thread yet. A better, but more intrusive fix would perhaps be to rearrange things such that the socket creation is done by the I/O thread.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49865", "url": "https://ubuntu.com/security/CVE-2024-49865", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: move xa_alloc to prevent UAF Evil user can guess the next id of the vm before the ioctl completes and then call vm destroy ioctl to trigger UAF since create ioctl is still referencing the same vm. Move the xa_alloc all the way to the end to prevent this. v2: - Rebase (cherry picked from commit dcfd3971327f3ee92765154baebbaece833d3ca9)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49955", "url": "https://ubuntu.com/security/CVE-2024-49955", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: battery: Fix possible crash when unregistering a battery hook When a battery hook returns an error when adding a new battery, then the battery hook is automatically unregistered. However the battery hook provider cannot know that, so it will later call battery_hook_unregister() on the already unregistered battery hook, resulting in a crash. Fix this by using the list head to mark already unregistered battery hooks as already being unregistered so that they can be ignored by battery_hook_unregister().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49973", "url": "https://ubuntu.com/security/CVE-2024-49973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: r8169: add tally counter fields added with RTL8125 RTL8125 added fields to the tally counter, what may result in the chip dma'ing these new fields to unallocated memory. Therefore make sure that the allocated memory area is big enough to hold all of the tally counter values, even if we use only parts of it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49974", "url": "https://ubuntu.com/security/CVE-2024-49974", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Limit the number of concurrent async COPY operations Nothing appears to limit the number of concurrent async COPY operations that clients can start. In addition, AFAICT each async COPY can copy an unlimited number of 4MB chunks, so can run for a long time. Thus IMO async COPY can become a DoS vector. Add a restriction mechanism that bounds the number of concurrent background COPY operations. Start simple and try to be fair -- this patch implements a per-namespace limit. An async COPY request that occurs while this limit is exceeded gets NFS4ERR_DELAY. The requesting client can choose to send the request again after a delay or fall back to a traditional read/write style copy. If there is need to make the mechanism more sophisticated, we can visit that in future patches.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49975", "url": "https://ubuntu.com/security/CVE-2024-49975", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uprobes: fix kernel info leak via \"[uprobes]\" vma xol_add_vma() maps the uninitialized page allocated by __create_xol_area() into userspace. On some architectures (x86) this memory is readable even without VM_READ, VM_EXEC results in the same pgprot_t as VM_EXEC|VM_READ, although this doesn't really matter, debugger can read this memory anyway.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50003", "url": "https://ubuntu.com/security/CVE-2024-50003", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix system hang while resume with TBT monitor [Why] Connected with a Thunderbolt monitor and do the suspend and the system may hang while resume. The TBT monitor HPD will be triggered during the resume procedure and call the drm_client_modeset_probe() while struct drm_connector connector->dev->master is NULL. It will mess up the pipe topology after resume. [How] Skip the TBT monitor HPD during the resume procedure because we currently will probe the connectors after resume by default. (cherry picked from commit 453f86a26945207a16b8f66aaed5962dc2b95b85)", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50173", "url": "https://ubuntu.com/security/CVE-2024-50173", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix access to uninitialized variable in tick_ctx_cleanup() The group variable can't be used to retrieve ptdev in our second loop, because it points to the previously iterated list_head, not a valid group. Get the ptdev object from the scheduler instead.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49866", "url": "https://ubuntu.com/security/CVE-2024-49866", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Fix a race during cpuhp processing There is another found exception that the \"timerlat/1\" thread was scheduled on CPU0, and lead to timer corruption finally: ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ``` After tracing the scheduling event, it was discovered that the migration of the \"timerlat/1\" thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() | To fix this, skip online processing if the CPU is already offline.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49976", "url": "https://ubuntu.com/security/CVE-2024-49976", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Drop interface_lock in stop_kthread() stop_kthread() is the offline callback for \"trace/osnoise:online\", since commit 5bfbcd1ee57b (\"tracing/timerlat: Add interface_lock around clearing of kthread in stop_kthread()\"), the following ABBA deadlock scenario is introduced: T1 | T2 [BP] | T3 [AP] osnoise_hotplug_workfn() | work_for_cpu_fn() | cpuhp_thread_fun() | _cpu_down() | osnoise_cpu_die() mutex_lock(&interface_lock) | | stop_kthread() | cpus_write_lock() | mutex_lock(&interface_lock) cpus_read_lock() | cpuhp_kick_ap() | As the interface_lock here in just for protecting the \"kthread\" field of the osn_var, use xchg() instead to fix this issue. Also use for_each_online_cpu() back in stop_per_cpu_kthreads() as it can take cpu_read_lock() again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50005", "url": "https://ubuntu.com/security/CVE-2024-50005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: Fix potential RCU dereference issue in mac802154_scan_worker In the `mac802154_scan_worker` function, the `scan_req->type` field was accessed after the RCU read-side critical section was unlocked. According to RCU usage rules, this is illegal and can lead to unpredictable behavior, such as accessing memory that has been updated or causing use-after-free issues. This possible bug was identified using a static analysis tool developed by myself, specifically designed to detect RCU-related issues. To address this, the `scan_req->type` value is now stored in a local variable `scan_req_type` while still within the RCU read-side critical section. The `scan_req_type` is then used after the RCU lock is released, ensuring that the type value is safely accessed without violating RCU rules.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50012", "url": "https://ubuntu.com/security/CVE-2024-50012", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: Avoid a bad reference count on CPU node In the parse_perf_domain function, if the call to of_parse_phandle_with_args returns an error, then the reference to the CPU device node that was acquired at the start of the function would not be properly decremented. Address this by declaring the variable with the __free(device_node) cleanup attribute.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49867", "url": "https://ubuntu.com/security/CVE-2024-49867", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: wait for fixup workers before stopping cleaner kthread during umount During unmount, at close_ctree(), we have the following steps in this order: 1) Park the cleaner kthread - this doesn't destroy the kthread, it basically halts its execution (wake ups against it work but do nothing); 2) We stop the cleaner kthread - this results in freeing the respective struct task_struct; 3) We call btrfs_stop_all_workers() which waits for any jobs running in all the work queues and then free the work queues. Syzbot reported a case where a fixup worker resulted in a crash when doing a delayed iput on its inode while attempting to wake up the cleaner at btrfs_add_delayed_iput(), because the task_struct of the cleaner kthread was already freed. This can happen during unmount because we don't wait for any fixup workers still running before we call kthread_stop() against the cleaner kthread, which stops and free all its resources. Fix this by waiting for any fixup workers at close_ctree() before we call kthread_stop() against the cleaner and run pending delayed iputs. The stack traces reported by syzbot were the following: BUG: KASAN: slab-use-after-free in __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 Read of size 8 at addr ffff8880272a8a18 by task kworker/u8:3/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.12.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: btrfs-fixup btrfs_work_helper 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 __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline] try_to_wake_up+0xb0/0x1480 kernel/sched/core.c:4154 btrfs_writepage_fixup_worker+0xc16/0xdf0 fs/btrfs/inode.c:2842 btrfs_work_helper+0x390/0xc50 fs/btrfs/async-thread.c:314 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Allocated by task 2: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:319 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345 kasan_slab_alloc include/linux/kasan.h:247 [inline] slab_post_alloc_hook mm/slub.c:4086 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4187 alloc_task_struct_node kernel/fork.c:180 [inline] dup_task_struct+0x57/0x8c0 kernel/fork.c:1107 copy_process+0x5d1/0x3d50 kernel/fork.c:2206 kernel_clone+0x223/0x880 kernel/fork.c:2787 kernel_thread+0x1bc/0x240 kernel/fork.c:2849 create_kthread kernel/kthread.c:412 [inline] kthreadd+0x60d/0x810 kernel/kthread.c:765 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Freed by task 61: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:230 [inline] slab_free_h ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49868", "url": "https://ubuntu.com/security/CVE-2024-49868", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix a NULL pointer dereference when failed to start a new trasacntion [BUG] Syzbot reported a NULL pointer dereference with the following crash: FAULT_INJECTION: forcing a failure. start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676 prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642 relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678 ... BTRFS info (device loop0): balance: ended with status: -12 Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667] RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926 Call Trace: commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496 btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430 del_balance_item fs/btrfs/volumes.c:3678 [inline] reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742 btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574 btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673 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/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [CAUSE] The allocation failure happens at the start_transaction() inside prepare_to_relocate(), and during the error handling we call unset_reloc_control(), which makes fs_info->balance_ctl to be NULL. Then we continue the error path cleanup in btrfs_balance() by calling reset_balance_state() which will call del_balance_item() to fully delete the balance item in the root tree. However during the small window between set_reloc_contrl() and unset_reloc_control(), we can have a subvolume tree update and created a reloc_root for that subvolume. Then we go into the final btrfs_commit_transaction() of del_balance_item(), and into btrfs_update_reloc_root() inside commit_fs_roots(). That function checks if fs_info->reloc_ctl is in the merge_reloc_tree stage, but since fs_info->reloc_ctl is NULL, it results a NULL pointer dereference. [FIX] Just add extra check on fs_info->reloc_ctl inside btrfs_update_reloc_root(), before checking fs_info->reloc_ctl->merge_reloc_tree. That DEAD_RELOC_TREE handling is to prevent further modification to the reloc tree during merge stage, but since there is no reloc_ctl at all, we do not need to bother that.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49869", "url": "https://ubuntu.com/security/CVE-2024-49869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: send: fix buffer overflow detection when copying path to cache entry Starting with commit c0247d289e73 (\"btrfs: send: annotate struct name_cache_entry with __counted_by()\") we annotated the variable length array \"name\" from the name_cache_entry structure with __counted_by() to improve overflow detection. However that alone was not correct, because the length of that array does not match the \"name_len\" field - it matches that plus 1 to include the NUL string terminator, so that makes a fortified kernel think there's an overflow and report a splat like this: strcpy: detected buffer overflow: 20 byte write of buffer size 19 WARNING: CPU: 3 PID: 3310 at __fortify_report+0x45/0x50 CPU: 3 UID: 0 PID: 3310 Comm: btrfs Not tainted 6.11.0-prnet #1 Hardware name: CompuLab Ltd. sbc-ihsw/Intense-PC2 (IPC2), BIOS IPC2_3.330.7 X64 03/15/2018 RIP: 0010:__fortify_report+0x45/0x50 Code: 48 8b 34 (...) RSP: 0018:ffff97ebc0d6f650 EFLAGS: 00010246 RAX: 7749924ef60fa600 RBX: ffff8bf5446a521a RCX: 0000000000000027 RDX: 00000000ffffdfff RSI: ffff97ebc0d6f548 RDI: ffff8bf84e7a1cc8 RBP: ffff8bf548574080 R08: ffffffffa8c40e10 R09: 0000000000005ffd R10: 0000000000000004 R11: ffffffffa8c70e10 R12: ffff8bf551eef400 R13: 0000000000000000 R14: 0000000000000013 R15: 00000000000003a8 FS: 00007fae144de8c0(0000) GS:ffff8bf84e780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fae14691690 CR3: 00000001027a2003 CR4: 00000000001706f0 Call Trace: ? __warn+0x12a/0x1d0 ? __fortify_report+0x45/0x50 ? report_bug+0x154/0x1c0 ? handle_bug+0x42/0x70 ? exc_invalid_op+0x1a/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? __fortify_report+0x45/0x50 __fortify_panic+0x9/0x10 __get_cur_name_and_parent+0x3bc/0x3c0 get_cur_path+0x207/0x3b0 send_extent_data+0x709/0x10d0 ? find_parent_nodes+0x22df/0x25d0 ? mas_nomem+0x13/0x90 ? mtree_insert_range+0xa5/0x110 ? btrfs_lru_cache_store+0x5f/0x1e0 ? iterate_extent_inodes+0x52d/0x5a0 process_extent+0xa96/0x11a0 ? __pfx_lookup_backref_cache+0x10/0x10 ? __pfx_store_backref_cache+0x10/0x10 ? __pfx_iterate_backrefs+0x10/0x10 ? __pfx_check_extent_item+0x10/0x10 changed_cb+0x6fa/0x930 ? tree_advance+0x362/0x390 ? memcmp_extent_buffer+0xd7/0x160 send_subvol+0xf0a/0x1520 btrfs_ioctl_send+0x106b/0x11d0 ? __pfx___clone_root_cmp_sort+0x10/0x10 _btrfs_ioctl_send+0x1ac/0x240 btrfs_ioctl+0x75b/0x850 __se_sys_ioctl+0xca/0x150 do_syscall_64+0x85/0x160 ? __count_memcg_events+0x69/0x100 ? handle_mm_fault+0x1327/0x15c0 ? __se_sys_rt_sigprocmask+0xf1/0x180 ? syscall_exit_to_user_mode+0x75/0xa0 ? do_syscall_64+0x91/0x160 ? do_user_addr_fault+0x21d/0x630 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fae145eeb4f Code: 00 48 89 (...) RSP: 002b:00007ffdf1cb09b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fae145eeb4f RDX: 00007ffdf1cb0ad0 RSI: 0000000040489426 RDI: 0000000000000004 RBP: 00000000000078fe R08: 00007fae144006c0 R09: 00007ffdf1cb0927 R10: 0000000000000008 R11: 0000000000000246 R12: 00007ffdf1cb1ce8 R13: 0000000000000003 R14: 000055c499fab2e0 R15: 0000000000000004 Fix this by not storing the NUL string terminator since we don't actually need it for name cache entries, this way \"name_len\" corresponds to the actual size of the \"name\" array. This requires marking the \"name\" array field with __nonstring and using memcpy() instead of strcpy() as recommended by the guidelines at: https://github.com/KSPP/linux/issues/90", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49870", "url": "https://ubuntu.com/security/CVE-2024-49870", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cachefiles: fix dentry leak in cachefiles_open_file() A dentry leak may be caused when a lookup cookie and a cull are concurrent: P1 | P2 ----------------------------------------------------------- cachefiles_lookup_cookie cachefiles_look_up_object lookup_one_positive_unlocked // get dentry cachefiles_cull inode->i_flags |= S_KERNEL_FILE; cachefiles_open_file cachefiles_mark_inode_in_use __cachefiles_mark_inode_in_use can_use = false if (!(inode->i_flags & S_KERNEL_FILE)) can_use = true \t return false return false // Returns an error but doesn't put dentry After that the following WARNING will be triggered when the backend folder is umounted: ================================================================== BUG: Dentry 000000008ad87947{i=7a,n=Dx_1_1.img} still in use (1) [unmount of ext4 sda] WARNING: CPU: 4 PID: 359261 at fs/dcache.c:1767 umount_check+0x5d/0x70 CPU: 4 PID: 359261 Comm: umount Not tainted 6.6.0-dirty #25 RIP: 0010:umount_check+0x5d/0x70 Call Trace: d_walk+0xda/0x2b0 do_one_tree+0x20/0x40 shrink_dcache_for_umount+0x2c/0x90 generic_shutdown_super+0x20/0x160 kill_block_super+0x1a/0x40 ext4_kill_sb+0x22/0x40 deactivate_locked_super+0x35/0x80 cleanup_mnt+0x104/0x160 ================================================================== Whether cachefiles_open_file() returns true or false, the reference count obtained by lookup_positive_unlocked() in cachefiles_look_up_object() should be released. Therefore release that reference count in cachefiles_look_up_object() to fix the above issue and simplify the code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49871", "url": "https://ubuntu.com/security/CVE-2024-49871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: adp5589-keys - fix NULL pointer dereference We register a devm action to call adp5589_clear_config() and then pass the i2c client as argument so that we can call i2c_get_clientdata() in order to get our device object. However, i2c_set_clientdata() is only being set at the end of the probe function which means that we'll get a NULL pointer dereference in case the probe function fails early.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49872", "url": "https://ubuntu.com/security/CVE-2024-49872", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/gup: fix memfd_pin_folios alloc race panic If memfd_pin_folios tries to create a hugetlb page, but someone else already did, then folio gets the value -EEXIST here: folio = memfd_alloc_folio(memfd, start_idx); if (IS_ERR(folio)) { ret = PTR_ERR(folio); if (ret != -EEXIST) goto err; then on the next trip through the \"while start_idx\" loop we panic here: if (folio) { folio_put(folio); To fix, set the folio to NULL on error.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49964", "url": "https://ubuntu.com/security/CVE-2024-49964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix memfd_pin_folios free_huge_pages leak memfd_pin_folios followed by unpin_folios fails to restore free_huge_pages if the pages were not already faulted in, because the folio refcount for pages created by memfd_alloc_folio never goes to 0. memfd_pin_folios needs another folio_put to undo the folio_try_get below: memfd_alloc_folio() alloc_hugetlb_folio_nodemask() dequeue_hugetlb_folio_nodemask() dequeue_hugetlb_folio_node_exact() folio_ref_unfreeze(folio, 1); ; adds 1 refcount folio_try_get() ; adds 1 refcount hugetlb_add_to_page_cache() ; adds 512 refcount (on x86) With the fix, after memfd_pin_folios + unpin_folios, the refcount for the (unfaulted) page is 512, which is correct, as the refcount for a faulted unpinned page is 513.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49873", "url": "https://ubuntu.com/security/CVE-2024-49873", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/filemap: fix filemap_get_folios_contig THP panic Patch series \"memfd-pin huge page fixes\". Fix multiple bugs that occur when using memfd_pin_folios with hugetlb pages and THP. The hugetlb bugs only bite when the page is not yet faulted in when memfd_pin_folios is called. The THP bug bites when the starting offset passed to memfd_pin_folios is not huge page aligned. See the commit messages for details. This patch (of 5): memfd_pin_folios on memory backed by THP panics if the requested start offset is not huge page aligned: BUG: kernel NULL pointer dereference, address: 0000000000000036 RIP: 0010:filemap_get_folios_contig+0xdf/0x290 RSP: 0018:ffffc9002092fbe8 EFLAGS: 00010202 RAX: 0000000000000002 RBX: 0000000000000002 RCX: 0000000000000002 The fault occurs here, because xas_load returns a folio with value 2: filemap_get_folios_contig() for (folio = xas_load(&xas); folio && xas.xa_index <= end; folio = xas_next(&xas)) { ... if (!folio_try_get(folio)) <-- BOOM \"2\" is an xarray sibling entry. We get it because memfd_pin_folios does not round the indices passed to filemap_get_folios_contig to huge page boundaries for THP, so we load from the middle of a huge page range see a sibling. (It does round for hugetlbfs, at the is_file_hugepages test). To fix, if the folio is a sibling, then return the next index as the starting point for the next call to filemap_get_folios_contig.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49977", "url": "https://ubuntu.com/security/CVE-2024-49977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: Fix zero-division error when disabling tc cbs The commit b8c43360f6e4 (\"net: stmmac: No need to calculate speed divider when offload is disabled\") allows the \"port_transmit_rate_kbps\" to be set to a value of 0, which is then passed to the \"div_s64\" function when tc-cbs is disabled. This leads to a zero-division error. When tc-cbs is disabled, the idleslope, sendslope, and credit values the credit values are not required to be configured. Therefore, adding a return statement after setting the txQ mode to DCB when tc-cbs is disabled would prevent a zero-division error.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49978", "url": "https://ubuntu.com/security/CVE-2024-49978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gso: fix udp gso fraglist segmentation after pull from frag_list Detect gso fraglist skbs with corrupted geometry (see below) and pass these to skb_segment instead of skb_segment_list, as the first can segment them correctly. 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 these skbs, breaking these invariants. In extreme cases they pull all data into skb linear. For UDP, this causes a NULL ptr deref in __udpv4_gso_segment_list_csum at udp_hdr(seg->next)->dest. Detect invalid geometry due to pull, by checking head_skb size. Don't just drop, as this may blackhole a destination. Convert to be able to pass to regular skb_segment.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49979", "url": "https://ubuntu.com/security/CVE-2024-49979", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gso: fix tcp fraglist segmentation after pull from frag_list Detect tcp gso fraglist skbs with corrupted geometry (see below) and pass these to skb_segment instead of skb_segment_list, as the first can segment them correctly. 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 these skbs, breaking these invariants. In extreme cases they pull all data into skb linear. For TCP, this causes a NULL ptr deref in __tcpv4_gso_segment_list_csum at tcp_hdr(seg->next). Detect invalid geometry due to pull, by checking head_skb size. Don't just drop, as this may blackhole a destination. Convert to be able to pass to regular skb_segment. Approach and description based on a patch by Willem de Bruijn.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49980", "url": "https://ubuntu.com/security/CVE-2024-49980", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vrf: revert \"vrf: Remove unnecessary RCU-bh critical section\" This reverts commit 504fc6f4f7f681d2a03aa5f68aad549d90eab853. dev_queue_xmit_nit is expected to be called with BH disabled. __dev_queue_xmit has the following: /* Disable soft irqs for various locks below. Also * stops preemption for RCU. */ rcu_read_lock_bh(); VRF must follow this invariant. The referenced commit removed this protection. Which triggered a lockdep warning: \t================================ \tWARNING: inconsistent lock state \t6.11.0 #1 Tainted: G W \t-------------------------------- \tinconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage. \tbtserver/134819 [HC0[0]:SC0[0]:HE1:SE1] takes: \tffff8882da30c118 (rlock-AF_PACKET){+.?.}-{2:2}, at: tpacket_rcv+0x863/0x3b30 \t{IN-SOFTIRQ-W} state was registered at: \t lock_acquire+0x19a/0x4f0 \t _raw_spin_lock+0x27/0x40 \t packet_rcv+0xa33/0x1320 \t __netif_receive_skb_core.constprop.0+0xcb0/0x3a90 \t __netif_receive_skb_list_core+0x2c9/0x890 \t netif_receive_skb_list_internal+0x610/0xcc0 [...] \tother info that might help us debug this: \t Possible unsafe locking scenario: \t CPU0 \t ---- \t lock(rlock-AF_PACKET); \t \t lock(rlock-AF_PACKET); \t *** DEADLOCK *** \tCall Trace: \t \t dump_stack_lvl+0x73/0xa0 \t mark_lock+0x102e/0x16b0 \t __lock_acquire+0x9ae/0x6170 \t lock_acquire+0x19a/0x4f0 \t _raw_spin_lock+0x27/0x40 \t tpacket_rcv+0x863/0x3b30 \t dev_queue_xmit_nit+0x709/0xa40 \t vrf_finish_direct+0x26e/0x340 [vrf] \t vrf_l3_out+0x5f4/0xe80 [vrf] \t __ip_local_out+0x51e/0x7a0 [...]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49981", "url": "https://ubuntu.com/security/CVE-2024-49981", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: venus: fix use after free bug in venus_remove due to race condition in venus_probe, core->work is bound with venus_sys_error_handler, which is used to handle error. The code use core->sys_err_done to make sync work. The core->work is started in venus_event_notify. If we call venus_remove, there might be an unfished work. The possible sequence is as follows: CPU0 CPU1 |venus_sys_error_handler venus_remove | hfi_destroy\t \t\t | venus_hfi_destroy\t | kfree(hdev);\t | |hfi_reinit \t\t\t\t\t |venus_hfi_queues_reinit |//use hdev Fix it by canceling the work in venus_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49956", "url": "https://ubuntu.com/security/CVE-2024-49956", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: fix double destroy_workqueue error When gfs2_fill_super() fails, destroy_workqueue() is called within gfs2_gl_hash_clear(), and the subsequent code path calls destroy_workqueue() on the same work queue again. This issue can be fixed by setting the work queue pointer to NULL after the first destroy_workqueue() call and checking for a NULL pointer before attempting to destroy the work queue again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50176", "url": "https://ubuntu.com/security/CVE-2024-50176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: k3-r5: Fix error handling when power-up failed By simply bailing out, the driver was violating its rule and internal assumptions that either both or no rproc should be initialized. E.g., this could cause the first core to be available but not the second one, leading to crashes on its shutdown later on while trying to dereference that second instance.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49982", "url": "https://ubuntu.com/security/CVE-2024-49982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: aoe: fix the potential use-after-free problem in more places For fixing CVE-2023-6270, f98364e92662 (\"aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts\") makes tx() calling dev_put() instead of doing in aoecmd_cfg_pkts(). It avoids that the tx() runs into use-after-free. Then Nicolai Stange found more places in aoe have potential use-after-free problem with tx(). e.g. revalidate(), aoecmd_ata_rw(), resend(), probe() and aoecmd_cfg_rsp(). Those functions also use aoenet_xmit() to push packet to tx queue. So they should also use dev_hold() to increase the refcnt of skb->dev. On the other hand, moving dev_put() to tx() causes that the refcnt of skb->dev be reduced to a negative value, because corresponding dev_hold() are not called in revalidate(), aoecmd_ata_rw(), resend(), probe(), and aoecmd_cfg_rsp(). This patch fixed this issue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49874", "url": "https://ubuntu.com/security/CVE-2024-49874", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: svc: Fix use after free vulnerability in svc_i3c_master Driver Due to Race Condition In the svc_i3c_master_probe function, &master->hj_work is bound with svc_i3c_master_hj_work, &master->ibi_work is bound with svc_i3c_master_ibi_work. And svc_i3c_master_ibi_work can start the hj_work, svc_i3c_master_irq_handler can start the ibi_work. If we remove the module which will call svc_i3c_master_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | svc_i3c_master_hj_work svc_i3c_master_remove | i3c_master_unregister(&master->base)| device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in svc_i3c_master_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49875", "url": "https://ubuntu.com/security/CVE-2024-49875", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: map the EBADMSG to nfserr_io to avoid warning Ext4 will throw -EBADMSG through ext4_readdir when a checksum error occurs, resulting in the following WARNING. Fix it by mapping EBADMSG to nfserr_io. nfsd_buffered_readdir iterate_dir // -EBADMSG -74 ext4_readdir // .iterate_shared ext4_dx_readdir ext4_htree_fill_tree htree_dirblock_to_tree ext4_read_dirblock __ext4_read_dirblock ext4_dirblock_csum_verify warn_no_space_for_csum __warn_no_space_for_csum return ERR_PTR(-EFSBADCRC) // -EBADMSG -74 nfserrno // WARNING [ 161.115610] ------------[ cut here ]------------ [ 161.116465] nfsd: non-standard errno: -74 [ 161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0 [ 161.118596] Modules linked in: [ 161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138 [ 161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qe mu.org 04/01/2014 [ 161.123601] RIP: 0010:nfserrno+0x9d/0xd0 [ 161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6 05 ce 2b 61 03 01 e8 99 20 d8 00 <0f> 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33 [ 161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286 [ 161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a [ 161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827 [ 161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021 [ 161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8 [ 161.135244] FS: 0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000 [ 161.136695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0 [ 161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 161.141519] PKRU: 55555554 [ 161.142076] Call Trace: [ 161.142575] ? __warn+0x9b/0x140 [ 161.143229] ? nfserrno+0x9d/0xd0 [ 161.143872] ? report_bug+0x125/0x150 [ 161.144595] ? handle_bug+0x41/0x90 [ 161.145284] ? exc_invalid_op+0x14/0x70 [ 161.146009] ? asm_exc_invalid_op+0x12/0x20 [ 161.146816] ? nfserrno+0x9d/0xd0 [ 161.147487] nfsd_buffered_readdir+0x28b/0x2b0 [ 161.148333] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.149258] ? nfsd_buffered_filldir+0xf0/0xf0 [ 161.150093] ? wait_for_concurrent_writes+0x170/0x170 [ 161.151004] ? generic_file_llseek_size+0x48/0x160 [ 161.151895] nfsd_readdir+0x132/0x190 [ 161.152606] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.153516] ? nfsd_unlink+0x380/0x380 [ 161.154256] ? override_creds+0x45/0x60 [ 161.155006] nfsd4_encode_readdir+0x21a/0x3d0 [ 161.155850] ? nfsd4_encode_readlink+0x210/0x210 [ 161.156731] ? write_bytes_to_xdr_buf+0x97/0xe0 [ 161.157598] ? __write_bytes_to_xdr_buf+0xd0/0xd0 [ 161.158494] ? lock_downgrade+0x90/0x90 [ 161.159232] ? nfs4svc_decode_voidarg+0x10/0x10 [ 161.160092] nfsd4_encode_operation+0x15a/0x440 [ 161.160959] nfsd4_proc_compound+0x718/0xe90 [ 161.161818] nfsd_dispatch+0x18e/0x2c0 [ 161.162586] svc_process_common+0x786/0xc50 [ 161.163403] ? nfsd_svc+0x380/0x380 [ 161.164137] ? svc_printk+0x160/0x160 [ 161.164846] ? svc_xprt_do_enqueue.part.0+0x365/0x380 [ 161.165808] ? nfsd_svc+0x380/0x380 [ 161.166523] ? rcu_is_watching+0x23/0x40 [ 161.167309] svc_process+0x1a5/0x200 [ 161.168019] nfsd+0x1f5/0x380 [ 161.168663] ? nfsd_shutdown_threads+0x260/0x260 [ 161.169554] kthread+0x1c4/0x210 [ 161.170224] ? kthread_insert_work_sanity_check+0x80/0x80 [ 161.171246] ret_from_fork+0x1f/0x30", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50013", "url": "https://ubuntu.com/security/CVE-2024-50013", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix memory leak in exfat_load_bitmap() If the first directory entry in the root directory is not a bitmap directory entry, 'bh' will not be released and reassigned, which will cause a memory leak.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49876", "url": "https://ubuntu.com/security/CVE-2024-49876", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: fix UAF around queue destruction We currently do stuff like queuing the final destruction step on a random system wq, which will outlive the driver instance. With bad timing we can teardown the driver with one or more work workqueue still being alive leading to various UAF splats. Add a fini step to ensure user queues are properly torn down. At this point GuC should already be nuked so queue itself should no longer be referenced from hw pov. v2 (Matt B) - Looks much safer to use a waitqueue and then just wait for the xa_array to become empty before triggering the drain. (cherry picked from commit 861108666cc0e999cffeab6aff17b662e68774e3)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49877", "url": "https://ubuntu.com/security/CVE-2024-49877", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate When doing cleanup, if flags without OCFS2_BH_READAHEAD, it may trigger NULL pointer dereference in the following ocfs2_set_buffer_uptodate() if bh is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49957", "url": "https://ubuntu.com/security/CVE-2024-49957", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix null-ptr-deref when journal load failed. During the mounting process, if journal_reset() fails because of too short journal, then lead to jbd2_journal_load() fails with NULL j_sb_buffer. Subsequently, ocfs2_journal_shutdown() calls jbd2_journal_flush()->jbd2_cleanup_journal_tail()-> __jbd2_update_log_tail()->jbd2_journal_update_sb_log_tail() ->lock_buffer(journal->j_sb_buffer), resulting in a null-pointer dereference error. To resolve this issue, we should check the JBD2_LOADED flag to ensure the journal was properly loaded. Additionally, use journal instead of osb->journal directly to simplify the code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49965", "url": "https://ubuntu.com/security/CVE-2024-49965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove unreasonable unlock in ocfs2_read_blocks Patch series \"Misc fixes for ocfs2_read_blocks\", v5. This series contains 2 fixes for ocfs2_read_blocks(). The first patch fix the issue reported by syzbot, which detects bad unlock balance in ocfs2_read_blocks(). The second patch fixes an issue reported by Heming Zhao when reviewing above fix. This patch (of 2): There was a lock release before exiting, so remove the unreasonable unlock.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49966", "url": "https://ubuntu.com/security/CVE-2024-49966", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: cancel dqi_sync_work before freeing oinfo ocfs2_global_read_info() will initialize and schedule dqi_sync_work at the end, if error occurs after successfully reading global quota, it will trigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled: ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16c This reports that there is an active delayed work when freeing oinfo in error handling, so cancel dqi_sync_work first. BTW, return status instead of -1 when .read_file_info fails.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49958", "url": "https://ubuntu.com/security/CVE-2024-49958", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reserve space for inline xattr before attaching reflink tree One of our customers reported a crash and a corrupted ocfs2 filesystem. The crash was due to the detection of corruption. Upon troubleshooting, the fsck -fn output showed the below corruption [EXTENT_LIST_FREE] Extent list in owner 33080590 claims 230 as the next free chain record, but fsck believes the largest valid value is 227. Clamp the next record value? n The stat output from the debugfs.ocfs2 showed the following corruption where the \"Next Free Rec:\" had overshot the \"Count:\" in the root metadata block. Inode: 33080590 Mode: 0640 Generation: 2619713622 (0x9c25a856) FS Generation: 904309833 (0x35e6ac49) CRC32: 00000000 ECC: 0000 Type: Regular Attr: 0x0 Flags: Valid Dynamic Features: (0x16) HasXattr InlineXattr Refcounted Extended Attributes Block: 0 Extended Attributes Inline Size: 256 User: 0 (root) Group: 0 (root) Size: 281320357888 Links: 1 Clusters: 141738 ctime: 0x66911b56 0x316edcb8 -- Fri Jul 12 06:02:30.829349048 2024 atime: 0x66911d6b 0x7f7a28d -- Fri Jul 12 06:11:23.133669517 2024 mtime: 0x66911b56 0x12ed75d7 -- Fri Jul 12 06:02:30.317552087 2024 dtime: 0x0 -- Wed Dec 31 17:00:00 1969 Refcount Block: 2777346 Last Extblk: 2886943 Orphan Slot: 0 Sub Alloc Slot: 0 Sub Alloc Bit: 14 Tree Depth: 1 Count: 227 Next Free Rec: 230 ## Offset Clusters Block# 0 0 2310 2776351 1 2310 2139 2777375 2 4449 1221 2778399 3 5670 731 2779423 4 6401 566 2780447 ....... .... ....... ....... .... ....... The issue was in the reflink workfow while reserving space for inline xattr. The problematic function is ocfs2_reflink_xattr_inline(). By the time this function is called the reflink tree is already recreated at the destination inode from the source inode. At this point, this function reserves space for inline xattrs at the destination inode without even checking if there is space at the root metadata block. It simply reduces the l_count from 243 to 227 thereby making space of 256 bytes for inline xattr whereas the inode already has extents beyond this index (in this case up to 230), thereby causing corruption. The fix for this is to reserve space for inline metadata at the destination inode before the reflink tree gets recreated. The customer has verified the fix.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49959", "url": "https://ubuntu.com/security/CVE-2024-49959", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail() to recover some journal space. But if an error occurs while executing jbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for free space right away, we try other branches, and if j_committing_transaction is NULL (i.e., the tid is 0), we will get the following complain: ============================================ JBD2: I/O error when updating journal superblock for sdd-8. __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available __jbd2_log_wait_for_space: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Call Trace: add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70 [...] ============================================ So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways. Note that this fix relies on commit 6f6a6fda2945 (\"jbd2: fix ocfs2 corrupt when updating journal superblock fails\") to make jbd2_cleanup_journal_tail return the correct error code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49878", "url": "https://ubuntu.com/security/CVE-2024-49878", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: resource: fix region_intersects() vs add_memory_driver_managed() On a system with CXL memory, the resource tree (/proc/iomem) related to CXL memory may look like something as follows. 490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem) Because drivers/dax/kmem.c calls add_memory_driver_managed() during onlining CXL memory, which makes \"System RAM (kmem)\" a descendant of \"CXL Window X\". This confuses region_intersects(), which expects all \"System RAM\" resources to be at the top level of iomem_resource. This can lead to bugs. For example, when the following command line is executed to write some memory in CXL memory range via /dev/mem, $ dd if=data of=/dev/mem bs=$((1 << 10)) seek=$((0x490000000 >> 10)) count=1 dd: error writing '/dev/mem': Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/s the command fails as expected. However, the error code is wrong. It should be \"Operation not permitted\" instead of \"Bad address\". More seriously, the /dev/mem permission checking in devmem_is_allowed() passes incorrectly. Although the accessing is prevented later because ioremap() isn't allowed to map system RAM, it is a potential security issue. During command executing, the following warning is reported in the kernel log for calling ioremap() on system RAM. ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d Call Trace: memremap+0xcb/0x184 xlate_dev_mem_ptr+0x25/0x2f write_mem+0x94/0xfb vfs_write+0x128/0x26d ksys_write+0xac/0xfe do_syscall_64+0x9a/0xfd entry_SYSCALL_64_after_hwframe+0x4b/0x53 The details of command execution process are as follows. In the above resource tree, \"System RAM\" is a descendant of \"CXL Window 0\" instead of a top level resource. So, region_intersects() will report no System RAM resources in the CXL memory region incorrectly, because it only checks the top level resources. Consequently, devmem_is_allowed() will return 1 (allow access via /dev/mem) for CXL memory region incorrectly. Fortunately, ioremap() doesn't allow to map System RAM and reject the access. So, region_intersects() needs to be fixed to work correctly with the resource tree with \"System RAM\" not at top level as above. To fix it, if we found a unmatched resource in the top level, we will continue to search matched resources in its descendant resources. So, we will not miss any matched resources in resource tree anymore. In the new implementation, an example resource tree |------------- \"CXL Window 0\" ------------| |-- \"System RAM\" --| will behave similar as the following fake resource tree for region_intersects(, IORESOURCE_SYSTEM_RAM, ), |-- \"System RAM\" --||-- \"CXL Window 0a\" --| Where \"CXL Window 0a\" is part of the original \"CXL Window 0\" that isn't covered by \"System RAM\".", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49879", "url": "https://ubuntu.com/security/CVE-2024-49879", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm: omapdrm: Add missing check for alloc_ordered_workqueue As it may return NULL pointer and cause NULL pointer dereference. Add check for the return value of alloc_ordered_workqueue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49880", "url": "https://ubuntu.com/security/CVE-2024-49880", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix off by one issue in alloc_flex_gd() Wesley reported an issue: ================================================================== EXT4-fs (dm-5): resizing filesystem from 7168 to 786432 blocks ------------[ cut here ]------------ kernel BUG at fs/ext4/resize.c:324! CPU: 9 UID: 0 PID: 3576 Comm: resize2fs Not tainted 6.11.0+ #27 RIP: 0010:ext4_resize_fs+0x1212/0x12d0 Call Trace: __ext4_ioctl+0x4e0/0x1800 ext4_ioctl+0x12/0x20 __x64_sys_ioctl+0x99/0xd0 x64_sys_call+0x1206/0x20d0 do_syscall_64+0x72/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e ================================================================== While reviewing the patch, Honza found that when adjusting resize_bg in alloc_flex_gd(), it was possible for flex_gd->resize_bg to be bigger than flexbg_size. The reproduction of the problem requires the following: o_group = flexbg_size * 2 * n; o_size = (o_group + 1) * group_size; n_group: [o_group + flexbg_size, o_group + flexbg_size * 2) o_size = (n_group + 1) * group_size; Take n=0,flexbg_size=16 as an example: last:15 |o---------------|--------------n-| o_group:0 resize to n_group:30 The corresponding reproducer is: img=test.img rm -f $img truncate -s 600M $img mkfs.ext4 -F $img -b 1024 -G 16 8M dev=`losetup -f --show $img` mkdir -p /tmp/test mount $dev /tmp/test resize2fs $dev 248M Delete the problematic plus 1 to fix the issue, and add a WARN_ON_ONCE() to prevent the issue from happening again. [ Note: another reproucer which this commit fixes is: img=test.img rm -f $img truncate -s 25MiB $img mkfs.ext4 -b 4096 -E nodiscard,lazy_itable_init=0,lazy_journal_init=0 $img truncate -s 3GiB $img dev=`losetup -f --show $img` mkdir -p /tmp/test mount $dev /tmp/test resize2fs $dev 3G umount $dev losetup -d $dev -- TYT ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49881", "url": "https://ubuntu.com/security/CVE-2024-49881", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: update orig_path in ext4_find_extent() In ext4_find_extent(), if the path is not big enough, we free it and set *orig_path to NULL. But after reallocating and successfully initializing the path, we don't update *orig_path, in which case the caller gets a valid path but a NULL ppath, and this may cause a NULL pointer dereference or a path memory leak. For example: ext4_split_extent path = *ppath = 2000 ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path = 2000); *orig_path = path = NULL; path = kcalloc() = 3000 ext4_split_extent_at(*ppath = NULL) path = *ppath; ex = path[depth].p_ext; // NULL pointer dereference! ================================================================== BUG: kernel NULL pointer dereference, address: 0000000000000010 CPU: 6 UID: 0 PID: 576 Comm: fsstress Not tainted 6.11.0-rc2-dirty #847 RIP: 0010:ext4_split_extent_at+0x6d/0x560 Call Trace: ext4_split_extent.isra.0+0xcb/0x1b0 ext4_ext_convert_to_initialized+0x168/0x6c0 ext4_ext_handle_unwritten_extents+0x325/0x4d0 ext4_ext_map_blocks+0x520/0xdb0 ext4_map_blocks+0x2b0/0x690 ext4_iomap_begin+0x20e/0x2c0 [...] ================================================================== Therefore, *orig_path is updated when the extent lookup succeeds, so that the caller can safely use path or *ppath.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50014", "url": "https://ubuntu.com/security/CVE-2024-50014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix access to uninitialised lock in fc replay path The following kernel trace can be triggered with fstest generic/629 when executed against a filesystem with fast-commit feature enabled: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x66/0x90 register_lock_class+0x759/0x7d0 __lock_acquire+0x85/0x2630 ? __find_get_block+0xb4/0x380 lock_acquire+0xd1/0x2d0 ? __ext4_journal_get_write_access+0xd5/0x160 _raw_spin_lock+0x33/0x40 ? __ext4_journal_get_write_access+0xd5/0x160 __ext4_journal_get_write_access+0xd5/0x160 ext4_reserve_inode_write+0x61/0xb0 __ext4_mark_inode_dirty+0x79/0x270 ? ext4_ext_replay_set_iblocks+0x2f8/0x450 ext4_ext_replay_set_iblocks+0x330/0x450 ext4_fc_replay+0x14c8/0x1540 ? jread+0x88/0x2e0 ? rcu_is_watching+0x11/0x40 do_one_pass+0x447/0xd00 jbd2_journal_recover+0x139/0x1b0 jbd2_journal_load+0x96/0x390 ext4_load_and_init_journal+0x253/0xd40 ext4_fill_super+0x2cc6/0x3180 ... In the replay path there's an attempt to lock sbi->s_bdev_wb_lock in function ext4_check_bdev_write_error(). Unfortunately, at this point this spinlock has not been initialized yet. Moving it's initialization to an earlier point in __ext4_fill_super() fixes this splat.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49960", "url": "https://ubuntu.com/security/CVE-2024-49960", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix timer use-after-free on failed mount Syzbot has found an ODEBUG bug in ext4_fill_super The del_timer_sync function cancels the s_err_report timer, which reminds about filesystem errors daily. We should guarantee the timer is no longer active before kfree(sbi). When filesystem mounting fails, the flow goes to failed_mount3, where an error occurs when ext4_stop_mmpd is called, causing a read I/O failure. This triggers the ext4_handle_error function that ultimately re-arms the timer, leaving the s_err_report timer active before kfree(sbi) is called. Fix the issue by canceling the s_err_report timer after calling ext4_stop_mmpd.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49882", "url": "https://ubuntu.com/security/CVE-2024-49882", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix double brelse() the buffer of the extents path In ext4_ext_try_to_merge_up(), set path[1].p_bh to NULL after it has been released, otherwise it may be released twice. An example of what triggers this is as follows: split2 map split1 |--------|-------|--------| ext4_ext_map_blocks ext4_ext_handle_unwritten_extents ext4_split_convert_extents // path->p_depth == 0 ext4_split_extent // 1. do split1 ext4_split_extent_at |ext4_ext_insert_extent | ext4_ext_create_new_leaf | ext4_ext_grow_indepth | le16_add_cpu(&neh->eh_depth, 1) | ext4_find_extent | // return -ENOMEM |// get error and try zeroout |path = ext4_find_extent | path->p_depth = 1 |ext4_ext_try_to_merge | ext4_ext_try_to_merge_up | path->p_depth = 0 | brelse(path[1].p_bh) ---> not set to NULL here |// zeroout success // 2. update path ext4_find_extent // 3. do split2 ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth le16_add_cpu(&neh->eh_depth, 1) ext4_find_extent path[0].p_bh = NULL; path->p_depth = 1 read_extent_tree_block ---> return err // path[1].p_bh is still the old value ext4_free_ext_path ext4_ext_drop_refs // path->p_depth == 1 brelse(path[1].p_bh) ---> brelse a buffer twice Finally got the following WARRNING when removing the buffer from lru: ============================================ VFS: brelse: Trying to free free buffer WARNING: CPU: 2 PID: 72 at fs/buffer.c:1241 __brelse+0x58/0x90 CPU: 2 PID: 72 Comm: kworker/u19:1 Not tainted 6.9.0-dirty #716 RIP: 0010:__brelse+0x58/0x90 Call Trace: __find_get_block+0x6e7/0x810 bdev_getblk+0x2b/0x480 __ext4_get_inode_loc+0x48a/0x1240 ext4_get_inode_loc+0xb2/0x150 ext4_reserve_inode_write+0xb7/0x230 __ext4_mark_inode_dirty+0x144/0x6a0 ext4_ext_insert_extent+0x9c8/0x3230 ext4_ext_map_blocks+0xf45/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] ============================================", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49883", "url": "https://ubuntu.com/security/CVE-2024-49883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: aovid use-after-free in ext4_ext_insert_extent() As Ojaswin mentioned in Link, in ext4_ext_insert_extent(), if the path is reallocated in ext4_ext_create_new_leaf(), we'll use the stale path and cause UAF. Below is a sample trace with dummy values: ext4_ext_insert_extent path = *ppath = 2000 ext4_ext_create_new_leaf(ppath) ext4_find_extent(ppath) path = *ppath = 2000 if (depth > path[0].p_maxdepth) kfree(path = 2000); *ppath = path = NULL; path = kcalloc() = 3000 *ppath = 3000; return path; /* here path is still 2000, UAF! */ eh = path[depth].p_hdr ================================================================== BUG: KASAN: slab-use-after-free in ext4_ext_insert_extent+0x26d4/0x3330 Read of size 8 at addr ffff8881027bf7d0 by task kworker/u36:1/179 CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 Not tainted 6.11.0-rc2-dirty #866 Call Trace: ext4_ext_insert_extent+0x26d4/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 [...] Allocated by task 179: ext4_find_extent+0x81c/0x1f70 ext4_ext_map_blocks+0x146/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...] Freed by task 179: kfree+0xcb/0x240 ext4_find_extent+0x7c0/0x1f70 ext4_ext_insert_extent+0xa26/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...] ================================================================== So use *ppath to update the path to avoid the above problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49983", "url": "https://ubuntu.com/security/CVE-2024-49983", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-free When calling ext4_force_split_extent_at() in ext4_ext_replay_update_ex(), the 'ppath' is updated but it is the 'path' that is freed, thus potentially triggering a double-free in the following process: ext4_ext_replay_update_ex ppath = path ext4_force_split_extent_at(&ppath) ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path) ---> path First freed *orig_path = path = NULL ---> null ppath kfree(path) ---> path double-free !!! So drop the unnecessary ppath and use path directly to avoid this problem. And use ext4_find_extent() directly to update path, avoiding unnecessary memory allocation and freeing. Also, propagate the error returned by ext4_find_extent() instead of using strange error codes.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50015", "url": "https://ubuntu.com/security/CVE-2024-50015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: dax: fix overflowing extents beyond inode size when partially writing The dax_iomap_rw() does two things in each iteration: map written blocks and copy user data to blocks. If the process is killed by user(See signal handling in dax_iomap_iter()), the copied data will be returned and added on inode size, which means that the length of written extents may exceed the inode size, then fsck will fail. An example is given as: dd if=/dev/urandom of=file bs=4M count=1 dax_iomap_rw iomap_iter // round 1 ext4_iomap_begin ext4_iomap_alloc // allocate 0~2M extents(written flag) dax_iomap_iter // copy 2M data iomap_iter // round 2 iomap_iter_advance iter->pos += iter->processed // iter->pos = 2M ext4_iomap_begin ext4_iomap_alloc // allocate 2~4M extents(written flag) dax_iomap_iter fatal_signal_pending done = iter->pos - iocb->ki_pos // done = 2M ext4_handle_inode_extension ext4_update_inode_size // inode size = 2M fsck reports: Inode 13, i_size is 2097152, should be 4194304. Fix? Fix the problem by truncating extents if the written length is smaller than expected.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49884", "url": "https://ubuntu.com/security/CVE-2024-49884", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix slab-use-after-free in ext4_split_extent_at() We hit the following use-after-free: ================================================================== BUG: KASAN: slab-use-after-free in ext4_split_extent_at+0xba8/0xcc0 Read of size 2 at addr ffff88810548ed08 by task kworker/u20:0/40 CPU: 0 PID: 40 Comm: kworker/u20:0 Not tainted 6.9.0-dirty #724 Call Trace: kasan_report+0x93/0xc0 ext4_split_extent_at+0xba8/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] Allocated by task 40: __kmalloc_noprof+0x1ac/0x480 ext4_find_extent+0xf3b/0x1e70 ext4_ext_map_blocks+0x188/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] Freed by task 40: kfree+0xf1/0x2b0 ext4_find_extent+0xa71/0x1e70 ext4_ext_insert_extent+0xa22/0x3260 ext4_split_extent_at+0x3ef/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] ================================================================== The flow of issue triggering is as follows: ext4_split_extent_at path = *ppath ext4_ext_insert_extent(ppath) ext4_ext_create_new_leaf(ppath) ext4_find_extent(orig_path) path = *orig_path read_extent_tree_block // return -ENOMEM or -EIO ext4_free_ext_path(path) kfree(path) *orig_path = NULL a. If err is -ENOMEM: ext4_ext_dirty(path + path->p_depth) // path use-after-free !!! b. If err is -EIO and we have EXT_DEBUG defined: ext4_ext_show_leaf(path) eh = path[depth].p_hdr // path also use-after-free !!! So when trying to zeroout or fix the extent length, call ext4_find_extent() to update the path. In addition we use *ppath directly as an ext4_ext_show_leaf() input to avoid possible use-after-free when EXT_DEBUG is defined, and to avoid unnecessary path updates.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49885", "url": "https://ubuntu.com/security/CVE-2024-49885", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm, slub: avoid zeroing kmalloc redzone Since commit 946fa0dbf2d8 (\"mm/slub: extend redzone check to extra allocated kmalloc space than requested\"), setting orig_size treats the wasted space (object_size - orig_size) as a redzone. However with init_on_free=1 we clear the full object->size, including the redzone. Additionally we clear the object metadata, including the stored orig_size, making it zero, which makes check_object() treat the whole object as a redzone. These issues lead to the following BUG report with \"slub_debug=FUZ init_on_free=1\": [ 0.000000] ============================================================================= [ 0.000000] BUG kmalloc-8 (Not tainted): kmalloc Redzone overwritten [ 0.000000] ----------------------------------------------------------------------------- [ 0.000000] [ 0.000000] 0xffff000010032858-0xffff00001003285f @offset=2136. First byte 0x0 instead of 0xcc [ 0.000000] FIX kmalloc-8: Restoring kmalloc Redzone 0xffff000010032858-0xffff00001003285f=0xcc [ 0.000000] Slab 0xfffffdffc0400c80 objects=36 used=23 fp=0xffff000010032a18 flags=0x3fffe0000000200(workingset|node=0|zone=0|lastcpupid=0x1ffff) [ 0.000000] Object 0xffff000010032858 @offset=2136 fp=0xffff0000100328c8 [ 0.000000] [ 0.000000] Redzone ffff000010032850: cc cc cc cc cc cc cc cc ........ [ 0.000000] Object ffff000010032858: cc cc cc cc cc cc cc cc ........ [ 0.000000] Redzone ffff000010032860: cc cc cc cc cc cc cc cc ........ [ 0.000000] Padding ffff0000100328b4: 00 00 00 00 00 00 00 00 00 00 00 00 ............ [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.11.0-rc3-next-20240814-00004-g61844c55c3f4 #144 [ 0.000000] Hardware name: NXP i.MX95 19X19 board (DT) [ 0.000000] Call trace: [ 0.000000] dump_backtrace+0x90/0xe8 [ 0.000000] show_stack+0x18/0x24 [ 0.000000] dump_stack_lvl+0x74/0x8c [ 0.000000] dump_stack+0x18/0x24 [ 0.000000] print_trailer+0x150/0x218 [ 0.000000] check_object+0xe4/0x454 [ 0.000000] free_to_partial_list+0x2f8/0x5ec To address the issue, use orig_size to clear the used area. And restore the value of orig_size after clear the remaining area. When CONFIG_SLUB_DEBUG not defined, (get_orig_size()' directly returns s->object_size. So when using memset to init the area, the size can simply be orig_size, as orig_size returns object_size when CONFIG_SLUB_DEBUG not enabled. And orig_size can never be bigger than object_size.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49961", "url": "https://ubuntu.com/security/CVE-2024-49961", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: ar0521: Use cansleep version of gpiod_set_value() If we use GPIO reset from I2C port expander, we must use *_cansleep() variant of GPIO functions. This was not done in ar0521_power_on()/ar0521_power_off() functions. Let's fix that. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 11 at drivers/gpio/gpiolib.c:3496 gpiod_set_value+0x74/0x7c Modules linked in: CPU: 0 PID: 11 Comm: kworker/u16:0 Not tainted 6.10.0 #53 Hardware name: Diasom DS-RK3568-SOM-EVB (DT) Workqueue: events_unbound deferred_probe_work_func pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : gpiod_set_value+0x74/0x7c lr : ar0521_power_on+0xcc/0x290 sp : ffffff8001d7ab70 x29: ffffff8001d7ab70 x28: ffffff80027dcc90 x27: ffffff8003c82000 x26: ffffff8003ca9250 x25: ffffffc080a39c60 x24: ffffff8003ca9088 x23: ffffff8002402720 x22: ffffff8003ca9080 x21: ffffff8003ca9088 x20: 0000000000000000 x19: ffffff8001eb2a00 x18: ffffff80efeeac80 x17: 756d2d6332692f30 x16: 0000000000000000 x15: 0000000000000000 x14: ffffff8001d91d40 x13: 0000000000000016 x12: ffffffc080e98930 x11: ffffff8001eb2880 x10: 0000000000000890 x9 : ffffff8001d7a9f0 x8 : ffffff8001d92570 x7 : ffffff80efeeac80 x6 : 000000003fc6e780 x5 : ffffff8001d91c80 x4 : 0000000000000002 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000001 Call trace: gpiod_set_value+0x74/0x7c ar0521_power_on+0xcc/0x290 ...", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49985", "url": "https://ubuntu.com/security/CVE-2024-49985", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume In case there is any sort of clock controller attached to this I2C bus controller, for example Versaclock or even an AIC32x4 I2C codec, then an I2C transfer triggered from the clock controller clk_ops .prepare callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex. This is because the clock controller first grabs the prepare_lock mutex and then performs the prepare operation, including its I2C access. The I2C access resumes this I2C bus controller via .runtime_resume callback, which calls clk_prepare_enable(), which attempts to grab the prepare_lock mutex again and deadlocks. Since the clock are already prepared since probe() and unprepared in remove(), use simple clk_enable()/clk_disable() calls to enable and disable the clock on runtime suspend and resume, to avoid hitting the prepare_lock mutex.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49886", "url": "https://ubuntu.com/security/CVE-2024-49886", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bug Attaching SST PCI device to VM causes \"BUG: KASAN: slab-out-of-bounds\". kasan report: [ 19.411889] ================================================================== [ 19.413702] BUG: KASAN: slab-out-of-bounds in _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.415634] Read of size 8 at addr ffff888829e65200 by task cpuhp/16/113 [ 19.417368] [ 19.418627] CPU: 16 PID: 113 Comm: cpuhp/16 Tainted: G E 6.9.0 #10 [ 19.420435] Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.20192059.B64.2207280713 07/28/2022 [ 19.422687] Call Trace: [ 19.424091] [ 19.425448] dump_stack_lvl+0x5d/0x80 [ 19.426963] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.428694] print_report+0x19d/0x52e [ 19.430206] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 19.431837] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.433539] kasan_report+0xf0/0x170 [ 19.435019] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.436709] _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.438379] ? __pfx_sched_clock_cpu+0x10/0x10 [ 19.439910] isst_if_cpu_online+0x406/0x58f [isst_if_common] [ 19.441573] ? __pfx_isst_if_cpu_online+0x10/0x10 [isst_if_common] [ 19.443263] ? ttwu_queue_wakelist+0x2c1/0x360 [ 19.444797] cpuhp_invoke_callback+0x221/0xec0 [ 19.446337] cpuhp_thread_fun+0x21b/0x610 [ 19.447814] ? __pfx_cpuhp_thread_fun+0x10/0x10 [ 19.449354] smpboot_thread_fn+0x2e7/0x6e0 [ 19.450859] ? __pfx_smpboot_thread_fn+0x10/0x10 [ 19.452405] kthread+0x29c/0x350 [ 19.453817] ? __pfx_kthread+0x10/0x10 [ 19.455253] ret_from_fork+0x31/0x70 [ 19.456685] ? __pfx_kthread+0x10/0x10 [ 19.458114] ret_from_fork_asm+0x1a/0x30 [ 19.459573] [ 19.460853] [ 19.462055] Allocated by task 1198: [ 19.463410] kasan_save_stack+0x30/0x50 [ 19.464788] kasan_save_track+0x14/0x30 [ 19.466139] __kasan_kmalloc+0xaa/0xb0 [ 19.467465] __kmalloc+0x1cd/0x470 [ 19.468748] isst_if_cdev_register+0x1da/0x350 [isst_if_common] [ 19.470233] isst_if_mbox_init+0x108/0xff0 [isst_if_mbox_msr] [ 19.471670] do_one_initcall+0xa4/0x380 [ 19.472903] do_init_module+0x238/0x760 [ 19.474105] load_module+0x5239/0x6f00 [ 19.475285] init_module_from_file+0xd1/0x130 [ 19.476506] idempotent_init_module+0x23b/0x650 [ 19.477725] __x64_sys_finit_module+0xbe/0x130 [ 19.476506] idempotent_init_module+0x23b/0x650 [ 19.477725] __x64_sys_finit_module+0xbe/0x130 [ 19.478920] do_syscall_64+0x82/0x160 [ 19.480036] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 19.481292] [ 19.482205] The buggy address belongs to the object at ffff888829e65000 which belongs to the cache kmalloc-512 of size 512 [ 19.484818] The buggy address is located 0 bytes to the right of allocated 512-byte region [ffff888829e65000, ffff888829e65200) [ 19.487447] [ 19.488328] The buggy address belongs to the physical page: [ 19.489569] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888829e60c00 pfn:0x829e60 [ 19.491140] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [ 19.492466] anon flags: 0x57ffffc0000840(slab|head|node=1|zone=2|lastcpupid=0x1fffff) [ 19.493914] page_type: 0xffffffff() [ 19.494988] raw: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [ 19.496451] raw: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [ 19.497906] head: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [ 19.499379] head: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [ 19.500844] head: 0057ffffc0000003 ffffea0020a79801 ffffea0020a79848 00000000ffffffff [ 19.502316] head: 0000000800000000 0000000000000000 00000000ffffffff 0000000000000000 [ 19.503784] page dumped because: k ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49986", "url": "https://ubuntu.com/security/CVE-2024-49986", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: x86-android-tablets: Fix use after free on platform_device_register() errors x86_android_tablet_remove() frees the pdevs[] array, so it should not be used after calling x86_android_tablet_remove(). When platform_device_register() fails, store the pdevs[x] PTR_ERR() value into the local ret variable before calling x86_android_tablet_remove() to avoid using pdevs[] after it has been freed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49887", "url": "https://ubuntu.com/security/CVE-2024-49887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to don't panic system for no free segment fault injection f2fs: fix to don't panic system for no free segment fault injection syzbot reports a f2fs bug as below: F2FS-fs (loop0): inject no free segment in get_new_segment of __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3167 F2FS-fs (loop0): Stopped filesystem due to reason: 7 ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2748! CPU: 0 UID: 0 PID: 5109 Comm: syz-executor304 Not tainted 6.11.0-rc6-syzkaller-00363-g89f5e14d05b4 #0 RIP: 0010:get_new_segment fs/f2fs/segment.c:2748 [inline] RIP: 0010:new_curseg+0x1f61/0x1f70 fs/f2fs/segment.c:2836 Call Trace: __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3167 f2fs_allocate_new_section fs/f2fs/segment.c:3181 [inline] f2fs_allocate_pinning_section+0xfa/0x4e0 fs/f2fs/segment.c:3195 f2fs_expand_inode_data+0x5d6/0xbb0 fs/f2fs/file.c:1799 f2fs_fallocate+0x448/0x960 fs/f2fs/file.c:1903 vfs_fallocate+0x553/0x6c0 fs/open.c:334 do_vfs_ioctl+0x2592/0x2e50 fs/ioctl.c:886 __do_sys_ioctl fs/ioctl.c:905 [inline] __se_sys_ioctl+0x81/0x170 fs/ioctl.c:893 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: 0010:get_new_segment fs/f2fs/segment.c:2748 [inline] RIP: 0010:new_curseg+0x1f61/0x1f70 fs/f2fs/segment.c:2836 The root cause is when we inject no free segment fault into f2fs, we should not panic system, fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49888", "url": "https://ubuntu.com/security/CVE-2024-49888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix a sdiv overflow issue Zac Ecob reported a problem where a bpf program may cause kernel crash due to the following error: Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI The failure is due to the below signed divide: LLONG_MIN/-1 where LLONG_MIN equals to -9,223,372,036,854,775,808. LLONG_MIN/-1 is supposed to give a positive number 9,223,372,036,854,775,808, but it is impossible since for 64-bit system, the maximum positive number is 9,223,372,036,854,775,807. On x86_64, LLONG_MIN/-1 will cause a kernel exception. On arm64, the result for LLONG_MIN/-1 is LLONG_MIN. Further investigation found all the following sdiv/smod cases may trigger an exception when bpf program is running on x86_64 platform: - LLONG_MIN/-1 for 64bit operation - INT_MIN/-1 for 32bit operation - LLONG_MIN%-1 for 64bit operation - INT_MIN%-1 for 32bit operation where -1 can be an immediate or in a register. On arm64, there are no exceptions: - LLONG_MIN/-1 = LLONG_MIN - INT_MIN/-1 = INT_MIN - LLONG_MIN%-1 = 0 - INT_MIN%-1 = 0 where -1 can be an immediate or in a register. Insn patching is needed to handle the above cases and the patched codes produced results aligned with above arm64 result. The below are pseudo codes to handle sdiv/smod exceptions including both divisor -1 and divisor 0 and the divisor is stored in a register. sdiv: tmp = rX tmp += 1 /* [-1, 0] -> [0, 1] if tmp >(unsigned) 1 goto L2 if tmp == 0 goto L1 rY = 0 L1: rY = -rY; goto L3 L2: rY /= rX L3: smod: tmp = rX tmp += 1 /* [-1, 0] -> [0, 1] if tmp >(unsigned) 1 goto L1 if tmp == 1 (is64 ? goto L2 : goto L3) rY = 0; goto L2 L1: rY %= rX L2: goto L4 // only when !is64 L3: wY = wY // only when !is64 L4: [1] https://lore.kernel.org/bpf/tPJLTEh7S_DxFEqAI2Ji5MBSoZVg7_G-Py2iaZpAaWtM961fFTWtsnlzwvTbzBzaUzwQAoNATXKUlt0LZOFgnDcIyKCswAnAGdUF3LBrhGQ=@protonmail.com/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49987", "url": "https://ubuntu.com/security/CVE-2024-49987", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpftool: Fix undefined behavior in qsort(NULL, 0, ...) When netfilter has no entry to display, qsort is called with qsort(NULL, 0, ...). This results in undefined behavior, as UBSan reports: net.c:827:2: runtime error: null pointer passed as argument 1, which is declared to never be null Although the C standard does not explicitly state whether calling qsort with a NULL pointer when the size is 0 constitutes undefined behavior, Section 7.1.4 of the C standard (Use of library functions) mentions: \"Each of the following statements applies unless explicitly stated otherwise in the detailed descriptions that follow: If an argument to a function has an invalid value (such as a value outside the domain of the function, or a pointer outside the address space of the program, or a null pointer, or a pointer to non-modifiable storage when the corresponding parameter is not const-qualified) or a type (after promotion) not expected by a function with variable number of arguments, the behavior is undefined.\" To avoid this, add an early return when nf_link_info is NULL to prevent calling qsort with a NULL pointer.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50006", "url": "https://ubuntu.com/security/CVE-2024-50006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix i_data_sem unlock order in ext4_ind_migrate() Fuzzing reports a possible deadlock in jbd2_log_wait_commit. This issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to require synchronous updates because the file descriptor is opened with O_SYNC. This can lead to the jbd2_journal_stop() function calling jbd2_might_wait_for_commit(), potentially causing a deadlock if the EXT4_IOC_MIGRATE call races with a write(2) system call. This problem only arises when CONFIG_PROVE_LOCKING is enabled. In this case, the jbd2_might_wait_for_commit macro locks jbd2_handle in the jbd2_journal_stop function while i_data_sem is locked. This triggers lockdep because the jbd2_journal_start function might also lock the same jbd2_handle simultaneously. Found by Linux Verification Center (linuxtesting.org) with syzkaller. Rule: add", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49889", "url": "https://ubuntu.com/security/CVE-2024-49889", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid use-after-free in ext4_ext_show_leaf() In ext4_find_extent(), path may be freed by error or be reallocated, so using a previously saved *ppath may have been freed and thus may trigger use-after-free, as follows: ext4_split_extent path = *ppath; ext4_split_extent_at(ppath) path = ext4_find_extent(ppath) ext4_split_extent_at(ppath) // ext4_find_extent fails to free path // but zeroout succeeds ext4_ext_show_leaf(inode, path) eh = path[depth].p_hdr // path use-after-free !!! Similar to ext4_split_extent_at(), we use *ppath directly as an input to ext4_ext_show_leaf(). Fix a spelling error by the way. Same problem in ext4_ext_handle_unwritten_extents(). Since 'path' is only used in ext4_ext_show_leaf(), remove 'path' and use *ppath directly. This issue is triggered only when EXT_DEBUG is defined and therefore does not affect functionality.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49968", "url": "https://ubuntu.com/security/CVE-2024-49968", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: filesystems without casefold feature cannot be mounted with siphash When mounting the ext4 filesystem, if the default hash version is set to DX_HASH_SIPHASH but the casefold feature is not set, exit the mounting.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49988", "url": "https://ubuntu.com/security/CVE-2024-49988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: add refcnt to ksmbd_conn struct When sending an oplock break request, opinfo->conn is used, But freed ->conn can be used on multichannel. This patch add a reference count to the ksmbd_conn struct so that it can be freed when it is no longer used.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49890", "url": "https://ubuntu.com/security/CVE-2024-49890", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: ensure the fw_info is not null before using it This resolves the dereference null return value warning reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49891", "url": "https://ubuntu.com/security/CVE-2024-49891", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata paths When the HBA is undergoing a reset or is handling an errata event, NULL ptr dereference crashes may occur in routines such as lpfc_sli_flush_io_rings(), lpfc_dev_loss_tmo_callbk(), or lpfc_abort_handler(). Add NULL ptr checks before dereferencing hdwq pointers that may have been freed due to operations colliding with a reset or errata event handler.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49892", "url": "https://ubuntu.com/security/CVE-2024-49892", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize get_bytes_per_element's default to 1 Variables, used as denominators and maybe not assigned to other values, should not be 0. bytes_per_element_y & bytes_per_element_c are initialized by get_bytes_per_element() which should never return 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50016", "url": "https://ubuntu.com/security/CVE-2024-50016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Avoid overflow assignment in link_dp_cts sampling_rate is an uint8_t but is assigned an unsigned int, and thus it can overflow. As a result, sampling_rate is changed to uint32_t. Similarly, LINK_QUAL_PATTERN_SET has a size of 2 bits, and it should only be assigned to a value less or equal than 4. This fixes 2 INTEGER_OVERFLOW issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49893", "url": "https://ubuntu.com/security/CVE-2024-49893", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check stream_status before it is used [WHAT & HOW] dc_state_get_stream_status can return null, and therefore null must be checked before stream_status is used. This fixes 1 NULL_RETURNS issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49969", "url": "https://ubuntu.com/security/CVE-2024-49969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 color transformation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_hw_format` function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:180 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:181 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:182 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49970", "url": "https://ubuntu.com/security/CVE-2024-49970", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Implement bounds check for stream encoder creation in DCN401 'stream_enc_regs' array is an array of dcn10_stream_enc_registers structures. The array is initialized with four elements, corresponding to the four calls to stream_enc_regs() in the array initializer. This means that valid indices for this array are 0, 1, 2, and 3. The error message 'stream_enc_regs' 4 <= 5 below, is indicating that there is an attempt to access this array with an index of 5, which is out of bounds. This could lead to undefined behavior Here, eng_id is used as an index to access the stream_enc_regs array. If eng_id is 5, this would result in an out-of-bounds access on the stream_enc_regs array. Thus fixing Buffer overflow error in dcn401_stream_encoder_create Found by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn401/dcn401_resource.c:1209 dcn401_stream_encoder_create() error: buffer overflow 'stream_enc_regs' 4 <= 5", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49894", "url": "https://ubuntu.com/security/CVE-2024-49894", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in degamma hardware format translation Fixes index out of bounds issue in `cm_helper_translate_curve_to_degamma_hw_format` function. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49895", "url": "https://ubuntu.com/security/CVE-2024-49895", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format translation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_degamma_hw_format` function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:338 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:339 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:340 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49971", "url": "https://ubuntu.com/security/CVE-2024-49971", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Increase array size of dummy_boolean [WHY] dml2_core_shared_mode_support and dml_core_mode_support access the third element of dummy_boolean, i.e. hw_debug5 = &s->dummy_boolean[2], when dummy_boolean has size of 2. Any assignment to hw_debug5 causes an OVERRUN. [HOW] Increase dummy_boolean's array size to 3. This fixes 2 OVERRUN issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49972", "url": "https://ubuntu.com/security/CVE-2024-49972", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Deallocate DML memory if allocation fails [Why] When DC state create DML memory allocation fails, memory is not deallocated subsequently, resulting in uninitialized structure that is not NULL. [How] Deallocate memory if DML memory allocation fails.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49896", "url": "https://ubuntu.com/security/CVE-2024-49896", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check stream before comparing them [WHAT & HOW] amdgpu_dm can pass a null stream to dc_is_stream_unchanged. It is necessary to check for null before dereferencing them. This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49897", "url": "https://ubuntu.com/security/CVE-2024-49897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check phantom_stream before it is used dcn32_enable_phantom_stream can return null, so returned value must be checked before used. This fixes 1 NULL_RETURNS issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49898", "url": "https://ubuntu.com/security/CVE-2024-49898", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null-initialized variables [WHAT & HOW] drr_timing and subvp_pipe are initialized to null and they are not always assigned new values. It is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49899", "url": "https://ubuntu.com/security/CVE-2024-49899", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize denominators' default to 1 [WHAT & HOW] Variables used as denominators and maybe not assigned to other values, should not be 0. Change their default to 1 so they are never 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49900", "url": "https://ubuntu.com/security/CVE-2024-49900", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uninit-value access of new_ea in ea_buffer syzbot reports that lzo1x_1_do_compress is using uninit-value: ===================================================== BUG: KMSAN: uninit-value in lzo1x_1_do_compress+0x19f9/0x2510 lib/lzo/lzo1x_compress.c:178 ... Uninit was stored to memory at: ea_put fs/jfs/xattr.c:639 [inline] ... Local variable ea_buf created at: __jfs_setxattr+0x5d/0x1ae0 fs/jfs/xattr.c:662 __jfs_xattr_set+0xe6/0x1f0 fs/jfs/xattr.c:934 ===================================================== The reason is ea_buf->new_ea is not initialized properly. Fix this by using memset to empty its content at the beginning in ea_get().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49901", "url": "https://ubuntu.com/security/CVE-2024-49901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm/adreno: Assign msm_gpu->pdev earlier to avoid nullptrs There are some cases, such as the one uncovered by Commit 46d4efcccc68 (\"drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails\") where msm_gpu_cleanup() : platform_set_drvdata(gpu->pdev, NULL); is called on gpu->pdev == NULL, as the GPU device has not been fully initialized yet. Turns out that there's more than just the aforementioned path that causes this to happen (e.g. the case when there's speedbin data in the catalog, but opp-supported-hw is missing in DT). Assigning msm_gpu->pdev earlier seems like the least painful solution to this, therefore do so. Patchwork: https://patchwork.freedesktop.org/patch/602742/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49902", "url": "https://ubuntu.com/security/CVE-2024-49902", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: check if leafidx greater than num leaves per dmap tree syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf. Shaggy: Modified sanity check to apply to control pages as well as leaf pages.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49903", "url": "https://ubuntu.com/security/CVE-2024-49903", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uaf in dbFreeBits [syzbot reported] ================================================================== BUG: KASAN: slab-use-after-free in __mutex_lock_common kernel/locking/mutex.c:587 [inline] BUG: KASAN: slab-use-after-free in __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 Read of size 8 at addr ffff8880229254b0 by task syz-executor357/5216 CPU: 0 UID: 0 PID: 5216 Comm: syz-executor357 Not tainted 6.11.0-rc3-syzkaller-00156-gd7a5aa4b3c00 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 __mutex_lock_common kernel/locking/mutex.c:587 [inline] __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 dbFreeBits+0x7ea/0xd90 fs/jfs/jfs_dmap.c:2390 dbFreeDmap fs/jfs/jfs_dmap.c:2089 [inline] dbFree+0x35b/0x680 fs/jfs/jfs_dmap.c:409 dbDiscardAG+0x8a9/0xa20 fs/jfs/jfs_dmap.c:1650 jfs_ioc_trim+0x433/0x670 fs/jfs/jfs_discard.c:100 jfs_ioctl+0x2d0/0x3e0 fs/jfs/ioctl.c:131 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 Freed by task 5218: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object+0xe0/0x150 mm/kasan/common.c:240 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2252 [inline] slab_free mm/slub.c:4473 [inline] kfree+0x149/0x360 mm/slub.c:4594 dbUnmount+0x11d/0x190 fs/jfs/jfs_dmap.c:278 jfs_mount_rw+0x4ac/0x6a0 fs/jfs/jfs_mount.c:247 jfs_remount+0x3d1/0x6b0 fs/jfs/super.c:454 reconfigure_super+0x445/0x880 fs/super.c:1083 vfs_cmd_reconfigure fs/fsopen.c:263 [inline] vfs_fsconfig_locked fs/fsopen.c:292 [inline] __do_sys_fsconfig fs/fsopen.c:473 [inline] __se_sys_fsconfig+0xb6e/0xf80 fs/fsopen.c:345 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 [Analysis] There are two paths (dbUnmount and jfs_ioc_trim) that generate race condition when accessing bmap, which leads to the occurrence of uaf. Use the lock s_umount to synchronize them, in order to avoid uaf caused by race condition.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49904", "url": "https://ubuntu.com/security/CVE-2024-49904", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add list empty check to avoid null pointer issue Add list empty check to avoid null pointer issues in some corner cases. - list_for_each_entry_safe()", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49989", "url": "https://ubuntu.com/security/CVE-2024-49989", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix double free issue during amdgpu module unload Flexible endpoints use DIGs from available inflexible endpoints, so only the encoders of inflexible links need to be freed. Otherwise, a double free issue may occur when unloading the amdgpu module. [ 279.190523] RIP: 0010:__slab_free+0x152/0x2f0 [ 279.190577] Call Trace: [ 279.190580] [ 279.190582] ? show_regs+0x69/0x80 [ 279.190590] ? die+0x3b/0x90 [ 279.190595] ? do_trap+0xc8/0xe0 [ 279.190601] ? do_error_trap+0x73/0xa0 [ 279.190605] ? __slab_free+0x152/0x2f0 [ 279.190609] ? exc_invalid_op+0x56/0x70 [ 279.190616] ? __slab_free+0x152/0x2f0 [ 279.190642] ? asm_exc_invalid_op+0x1f/0x30 [ 279.190648] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191096] ? __slab_free+0x152/0x2f0 [ 279.191102] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191469] kfree+0x260/0x2b0 [ 279.191474] dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191821] link_destroy+0xd7/0x130 [amdgpu] [ 279.192248] dc_destruct+0x90/0x270 [amdgpu] [ 279.192666] dc_destroy+0x19/0x40 [amdgpu] [ 279.193020] amdgpu_dm_fini+0x16e/0x200 [amdgpu] [ 279.193432] dm_hw_fini+0x26/0x40 [amdgpu] [ 279.193795] amdgpu_device_fini_hw+0x24c/0x400 [amdgpu] [ 279.194108] amdgpu_driver_unload_kms+0x4f/0x70 [amdgpu] [ 279.194436] amdgpu_pci_remove+0x40/0x80 [amdgpu] [ 279.194632] pci_device_remove+0x3a/0xa0 [ 279.194638] device_remove+0x40/0x70 [ 279.194642] device_release_driver_internal+0x1ad/0x210 [ 279.194647] driver_detach+0x4e/0xa0 [ 279.194650] bus_remove_driver+0x6f/0xf0 [ 279.194653] driver_unregister+0x33/0x60 [ 279.194657] pci_unregister_driver+0x44/0x90 [ 279.194662] amdgpu_exit+0x19/0x1f0 [amdgpu] [ 279.194939] __do_sys_delete_module.isra.0+0x198/0x2f0 [ 279.194946] __x64_sys_delete_module+0x16/0x20 [ 279.194950] do_syscall_64+0x58/0x120 [ 279.194954] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 279.194980] ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49905", "url": "https://ubuntu.com/security/CVE-2024-49905", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for 'afb' in amdgpu_dm_plane_handle_cursor_update (v2) This commit adds a null check for the 'afb' variable in the amdgpu_dm_plane_handle_cursor_update function. Previously, 'afb' was assumed to be null, but was used later in the code without a null check. This could potentially lead to a null pointer dereference. Changes since v1: - Moved the null check for 'afb' to the line where 'afb' is used. (Alex) Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:1298 amdgpu_dm_plane_handle_cursor_update() error: we previously assumed 'afb' could be null (see line 1252)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49906", "url": "https://ubuntu.com/security/CVE-2024-49906", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before try to access it [why & how] Change the order of the pipe_ctx->plane_state check to ensure that plane_state is not null before accessing it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49907", "url": "https://ubuntu.com/security/CVE-2024-49907", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before using dc->clk_mgr [WHY & HOW] dc->clk_mgr is null checked previously in the same function, indicating it might be null. Passing \"dc\" to \"dc->hwss.apply_idle_power_optimizations\", which dereferences null \"dc->clk_mgr\". (The function pointer resolves to \"dcn35_apply_idle_power_optimizations\".) This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49908", "url": "https://ubuntu.com/security/CVE-2024-49908", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for 'afb' in amdgpu_dm_update_cursor (v2) This commit adds a null check for the 'afb' variable in the amdgpu_dm_update_cursor function. Previously, 'afb' was assumed to be null at line 8388, but was used later in the code without a null check. This could potentially lead to a null pointer dereference. Changes since v1: - Moved the null check for 'afb' to the line where 'afb' is used. (Alex) Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:8433 amdgpu_dm_update_cursor() \terror: we previously assumed 'afb' could be null (see line 8388)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50177", "url": "https://ubuntu.com/security/CVE-2024-50177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix a UBSAN warning in DML2.1 When programming phantom pipe, since cursor_width is explicity set to 0, this causes calculation logic to trigger overflow for an unsigned int triggering the kernel's UBSAN check as below: [ 40.962845] UBSAN: shift-out-of-bounds in /tmp/amd.EfpumTkO/amd/amdgpu/../display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c:3312:34 [ 40.962849] shift exponent 4294967170 is too large for 32-bit type 'unsigned int' [ 40.962852] CPU: 1 PID: 1670 Comm: gnome-shell Tainted: G W OE 6.5.0-41-generic #41~22.04.2-Ubuntu [ 40.962854] Hardware name: Gigabyte Technology Co., Ltd. X670E AORUS PRO X/X670E AORUS PRO X, BIOS F21 01/10/2024 [ 40.962856] Call Trace: [ 40.962857] [ 40.962860] dump_stack_lvl+0x48/0x70 [ 40.962870] dump_stack+0x10/0x20 [ 40.962872] __ubsan_handle_shift_out_of_bounds+0x1ac/0x360 [ 40.962878] calculate_cursor_req_attributes.cold+0x1b/0x28 [amdgpu] [ 40.963099] dml_core_mode_support+0x6b91/0x16bc0 [amdgpu] [ 40.963327] ? srso_alias_return_thunk+0x5/0x7f [ 40.963331] ? CalculateWatermarksMALLUseAndDRAMSpeedChangeSupport+0x18b8/0x2790 [amdgpu] [ 40.963534] ? srso_alias_return_thunk+0x5/0x7f [ 40.963536] ? dml_core_mode_support+0xb3db/0x16bc0 [amdgpu] [ 40.963730] dml2_core_calcs_mode_support_ex+0x2c/0x90 [amdgpu] [ 40.963906] ? srso_alias_return_thunk+0x5/0x7f [ 40.963909] ? dml2_core_calcs_mode_support_ex+0x2c/0x90 [amdgpu] [ 40.964078] core_dcn4_mode_support+0x72/0xbf0 [amdgpu] [ 40.964247] dml2_top_optimization_perform_optimization_phase+0x1d3/0x2a0 [amdgpu] [ 40.964420] dml2_build_mode_programming+0x23d/0x750 [amdgpu] [ 40.964587] dml21_validate+0x274/0x770 [amdgpu] [ 40.964761] ? srso_alias_return_thunk+0x5/0x7f [ 40.964763] ? resource_append_dpp_pipes_for_plane_composition+0x27c/0x3b0 [amdgpu] [ 40.964942] dml2_validate+0x504/0x750 [amdgpu] [ 40.965117] ? dml21_copy+0x95/0xb0 [amdgpu] [ 40.965291] ? srso_alias_return_thunk+0x5/0x7f [ 40.965295] dcn401_validate_bandwidth+0x4e/0x70 [amdgpu] [ 40.965491] update_planes_and_stream_state+0x38d/0x5c0 [amdgpu] [ 40.965672] update_planes_and_stream_v3+0x52/0x1e0 [amdgpu] [ 40.965845] ? srso_alias_return_thunk+0x5/0x7f [ 40.965849] dc_update_planes_and_stream+0x71/0xb0 [amdgpu] Fix this by adding a guard for checking cursor width before triggering the size calculation.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49909", "url": "https://ubuntu.com/security/CVE-2024-49909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn32_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn32_set_output_transfer_func function. Previously, set_output_gamma was being checked for null, but then it was being dereferenced without any null check. This could lead to a null pointer dereference if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49910", "url": "https://ubuntu.com/security/CVE-2024-49910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn401_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn401_set_output_transfer_func function. Previously, set_output_gamma was being checked for null, but then it was being dereferenced without any null check. This could lead to a null pointer dereference if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49911", "url": "https://ubuntu.com/security/CVE-2024-49911", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn20_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn20_set_output_transfer_func function. Previously, set_output_gamma was being checked for null at line 1030, but then it was being dereferenced without any null check at line 1048. This could potentially lead to a null pointer dereference error if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma at line 1048.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49912", "url": "https://ubuntu.com/security/CVE-2024-49912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Handle null 'stream_status' in 'planes_changed_for_existing_stream' This commit adds a null check for 'stream_status' in the function 'planes_changed_for_existing_stream'. Previously, the code assumed 'stream_status' could be null, but did not handle the case where it was actually null. This could lead to a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:3784 planes_changed_for_existing_stream() error: we previously assumed 'stream_status' could be null (see line 3774)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49913", "url": "https://ubuntu.com/security/CVE-2024-49913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for top_pipe_to_program in commit_planes_for_stream This commit addresses a null pointer dereference issue in the `commit_planes_for_stream` function at line 4140. The issue could occur when `top_pipe_to_program` is null. The fix adds a check to ensure `top_pipe_to_program` is not null before accessing its stream_res. This prevents a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:4140 commit_planes_for_stream() error: we previously assumed 'top_pipe_to_program' could be null (see line 3906)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49914", "url": "https://ubuntu.com/security/CVE-2024-49914", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for pipe_ctx->plane_state in dcn20_program_pipe This commit addresses a null pointer dereference issue in the `dcn20_program_pipe` function. The issue could occur when `pipe_ctx->plane_state` is null. The fix adds a check to ensure `pipe_ctx->plane_state` is not null before accessing. This prevents a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn20/dcn20_hwseq.c:1925 dcn20_program_pipe() error: we previously assumed 'pipe_ctx->plane_state' could be null (see line 1877)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49915", "url": "https://ubuntu.com/security/CVE-2024-49915", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr in dcn32_init_hw This commit addresses a potential null pointer dereference issue in the `dcn32_init_hw` function. The issue could occur when `dc->clk_mgr` is null. The fix adds a check to ensure `dc->clk_mgr` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn32/dcn32_hwseq.c:961 dcn32_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 782)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49916", "url": "https://ubuntu.com/security/CVE-2024-49916", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in dcn401_init_hw This commit addresses a potential null pointer dereference issue in the `dcn401_init_hw` function. The issue could occur when `dc->clk_mgr` or `dc->clk_mgr->funcs` is null. The fix adds a check to ensure `dc->clk_mgr` and `dc->clk_mgr->funcs` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn401/dcn401_hwseq.c:416 dcn401_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 225)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49917", "url": "https://ubuntu.com/security/CVE-2024-49917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in dcn30_init_hw This commit addresses a potential null pointer dereference issue in the `dcn30_init_hw` function. The issue could occur when `dc->clk_mgr` or `dc->clk_mgr->funcs` is null. The fix adds a check to ensure `dc->clk_mgr` and `dc->clk_mgr->funcs` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:789 dcn30_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 628)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49918", "url": "https://ubuntu.com/security/CVE-2024-49918", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for head_pipe in dcn32_acquire_idle_pipe_for_head_pipe_in_layer This commit addresses a potential null pointer dereference issue in the `dcn32_acquire_idle_pipe_for_head_pipe_in_layer` function. The issue could occur when `head_pipe` is null. The fix adds a check to ensure `head_pipe` is not null before asserting it. If `head_pipe` is null, the function returns NULL to prevent a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn32/dcn32_resource.c:2690 dcn32_acquire_idle_pipe_for_head_pipe_in_layer() error: we previously assumed 'head_pipe' could be null (see line 2681)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49919", "url": "https://ubuntu.com/security/CVE-2024-49919", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for head_pipe in dcn201_acquire_free_pipe_for_layer This commit addresses a potential null pointer dereference issue in the `dcn201_acquire_free_pipe_for_layer` function. The issue could occur when `head_pipe` is null. The fix adds a check to ensure `head_pipe` is not null before asserting it. If `head_pipe` is null, the function returns NULL to prevent a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn201/dcn201_resource.c:1016 dcn201_acquire_free_pipe_for_layer() error: we previously assumed 'head_pipe' could be null (see line 1010)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49991", "url": "https://ubuntu.com/security/CVE-2024-49991", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer Pass pointer reference to amdgpu_bo_unref to clear the correct pointer, otherwise amdgpu_bo_unref clear the local variable, the original pointer not set to NULL, this could cause use-after-free bug.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49920", "url": "https://ubuntu.com/security/CVE-2024-49920", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before multiple uses [WHAT & HOW] Poniters, such as stream_enc and dc->bw_vbios, are null checked previously in the same function, so Coverity warns \"implies that stream_enc and dc->bw_vbios might be null\". They are used multiple times in the subsequent code and need to be checked. This fixes 10 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49921", "url": "https://ubuntu.com/security/CVE-2024-49921", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before used [WHAT & HOW] Poniters, such as dc->clk_mgr, are null checked previously in the same function, so Coverity warns \"implies that \"dc->clk_mgr\" might be null\". As a result, these pointers need to be checked when used again. This fixes 10 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49922", "url": "https://ubuntu.com/security/CVE-2024-49922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before using them [WHAT & HOW] These pointers are null checked previously in the same function, indicating they might be null as reported by Coverity. As a result, they need to be checked when used again. This fixes 3 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49923", "url": "https://ubuntu.com/security/CVE-2024-49923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Pass non-null to dcn20_validate_apply_pipe_split_flags [WHAT & HOW] \"dcn20_validate_apply_pipe_split_flags\" dereferences merge, and thus it cannot be a null pointer. Let's pass a valid pointer to avoid null dereference. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49992", "url": "https://ubuntu.com/security/CVE-2024-49992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/stm: Avoid use-after-free issues with crtc and plane ltdc_load() calls functions drm_crtc_init_with_planes(), drm_universal_plane_init() and drm_encoder_init(). These functions should not be called with parameters allocated with devm_kzalloc() to avoid use-after-free issues [1]. Use allocations managed by the DRM framework. Found by Linux Verification Center (linuxtesting.org). [1] https://lore.kernel.org/lkml/u366i76e3qhh3ra5oxrtngjtm2u5lterkekcz6y2jkndhuxzli@diujon4h7qwb/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49993", "url": "https://ubuntu.com/security/CVE-2024-49993", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49924", "url": "https://ubuntu.com/security/CVE-2024-49924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: pxafb: Fix possible use after free in pxafb_task() In the pxafb_probe function, it calls the pxafb_init_fbinfo function, after which &fbi->task is associated with pxafb_task. Moreover, within this pxafb_init_fbinfo function, the pxafb_blank function within the &pxafb_ops struct is capable of scheduling work. If we remove the module which will call pxafb_remove to make cleanup, it will call unregister_framebuffer function which can call do_unregister_framebuffer to free fbi->fb through put_fb_info(fb_info), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | pxafb_task pxafb_remove | unregister_framebuffer(info) | do_unregister_framebuffer(fb_info) | put_fb_info(fb_info) | // free fbi->fb | set_ctrlr_state(fbi, state) | __pxafb_lcd_power(fbi, 0) | fbi->lcd_power(on, &fbi->fb.var) | //use fbi->fb Fix it by ensuring that the work is canceled before proceeding with the cleanup in pxafb_remove. Note that only root user can remove the driver at runtime.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49925", "url": "https://ubuntu.com/security/CVE-2024-49925", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: efifb: Register sysfs groups through driver core The driver core can register and cleanup sysfs groups already. Make use of that functionality to simplify the error handling and cleanup. Also avoid a UAF race during unregistering where the sysctl attributes were usable after the info struct was freed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49926", "url": "https://ubuntu.com/security/CVE-2024-49926", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rcu-tasks: Fix access non-existent percpu rtpcp variable in rcu_tasks_need_gpcb() For kernels built with CONFIG_FORCE_NR_CPUS=y, the nr_cpu_ids is defined as NR_CPUS instead of the number of possible cpus, this will cause the following system panic: smpboot: Allowing 4 CPUs, 0 hotplug CPUs ... setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:512 nr_node_ids:1 ... BUG: unable to handle page fault for address: ffffffff9911c8c8 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 15 Comm: rcu_tasks_trace Tainted: G W 6.6.21 #1 5dc7acf91a5e8e9ac9dcfc35bee0245691283ea6 RIP: 0010:rcu_tasks_need_gpcb+0x25d/0x2c0 RSP: 0018:ffffa371c00a3e60 EFLAGS: 00010082 CR2: ffffffff9911c8c8 CR3: 000000040fa20005 CR4: 00000000001706f0 Call Trace: ? __die+0x23/0x80 ? page_fault_oops+0xa4/0x180 ? exc_page_fault+0x152/0x180 ? asm_exc_page_fault+0x26/0x40 ? rcu_tasks_need_gpcb+0x25d/0x2c0 ? __pfx_rcu_tasks_kthread+0x40/0x40 rcu_tasks_one_gp+0x69/0x180 rcu_tasks_kthread+0x94/0xc0 kthread+0xe8/0x140 ? __pfx_kthread+0x40/0x40 ret_from_fork+0x34/0x80 ? __pfx_kthread+0x40/0x40 ret_from_fork_asm+0x1b/0x80 Considering that there may be holes in the CPU numbers, use the maximum possible cpu number, instead of nr_cpu_ids, for configuring enqueue and dequeue limits. [ neeraj.upadhyay: Fix htmldocs build error reported by Stephen Rothwell ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50007", "url": "https://ubuntu.com/security/CVE-2024-50007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: asihpi: Fix potential OOB array access ASIHPI driver stores some values in the static array upon a response from the driver, and its index depends on the firmware. We shouldn't trust it blindly. This patch adds a sanity check of the array index to fit in the array size.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50017", "url": "https://ubuntu.com/security/CVE-2024-50017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm/ident_map: Use gbpages only where full GB page should be mapped. When ident_pud_init() uses only GB pages to create identity maps, large ranges of addresses not actually requested can be included in the resulting table; a 4K request will map a full GB. This can include a lot of extra address space past that requested, including areas marked reserved by the BIOS. That allows processor speculation into reserved regions, that on UV systems can cause system halts. Only use GB pages when map creation requests include the full GB page of space. Fall back to using smaller 2M pages when only portions of a GB page are included in the request. No attempt is made to coalesce mapping requests. If a request requires a map entry at the 2M (pmd) level, subsequent mapping requests within the same 1G region will also be at the pmd level, even if adjacent or overlapping such requests could have been combined to map a full GB page. Existing usage starts with larger regions and then adds smaller regions, so this should not have any great consequence.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49927", "url": "https://ubuntu.com/security/CVE-2024-49927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/ioapic: Handle allocation failures gracefully Breno observed panics when using failslab under certain conditions during runtime: can not alloc irq_pin_list (-1,0,20) Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed panic+0x4e9/0x590 mp_irqdomain_alloc+0x9ab/0xa80 irq_domain_alloc_irqs_locked+0x25d/0x8d0 __irq_domain_alloc_irqs+0x80/0x110 mp_map_pin_to_irq+0x645/0x890 acpi_register_gsi_ioapic+0xe6/0x150 hpet_open+0x313/0x480 That's a pointless panic which is a leftover of the historic IO/APIC code which panic'ed during early boot when the interrupt allocation failed. The only place which might justify panic is the PIT/HPET timer_check() code which tries to figure out whether the timer interrupt is delivered through the IO/APIC. But that code does not require to handle interrupt allocation failures. If the interrupt cannot be allocated then timer delivery fails and it either panics due to that or falls back to legacy mode. Cure this by removing the panic wrapper around __add_pin_to_irq_node() and making mp_irqdomain_alloc() aware of the failure condition and handle it as any other failure in this function gracefully.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50008", "url": "https://ubuntu.com/security/CVE-2024-50008", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_cmd_802_11_scan_ext() Replace one-element array with a flexible-array member in `struct host_cmd_ds_802_11_scan_ext`. With this, fix the following warning: elo 16 17:51:58 surfacebook kernel: ------------[ cut here ]------------ elo 16 17:51:58 surfacebook kernel: memcpy: detected field-spanning write (size 243) of single field \"ext_scan->tlv_buffer\" at drivers/net/wireless/marvell/mwifiex/scan.c:2239 (size 1) elo 16 17:51:58 surfacebook kernel: WARNING: CPU: 0 PID: 498 at drivers/net/wireless/marvell/mwifiex/scan.c:2239 mwifiex_cmd_802_11_scan_ext+0x83/0x90 [mwifiex]", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50018", "url": "https://ubuntu.com/security/CVE-2024-50018", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49928", "url": "https://ubuntu.com/security/CVE-2024-49928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: avoid reading out of bounds when loading TX power FW elements Because the loop-expression will do one more time before getting false from cond-expression, the original code copied one more entry size beyond valid region. Fix it by moving the entry copy to loop-body.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50178", "url": "https://ubuntu.com/security/CVE-2024-50178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: loongson3: Use raw_smp_processor_id() in do_service_request() Use raw_smp_processor_id() instead of plain smp_processor_id() in do_service_request(), otherwise we may get some errors with the driver enabled: BUG: using smp_processor_id() in preemptible [00000000] code: (udev-worker)/208 caller is loongson3_cpufreq_probe+0x5c/0x250 [loongson3_cpufreq]", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50009", "url": "https://ubuntu.com/security/CVE-2024-50009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: amd-pstate: add check for cpufreq_cpu_get's return value cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it and return in case of error. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49994", "url": "https://ubuntu.com/security/CVE-2024-49994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix integer overflow in BLKSECDISCARD I independently rediscovered \tcommit 22d24a544b0d49bbcbd61c8c0eaf77d3c9297155 \tblock: fix overflow in blk_ioctl_discard() but for secure erase. Same problem: \tuint64_t r[2] = {512, 18446744073709551104ULL}; \tioctl(fd, BLKSECDISCARD, r); will enter near infinite loop inside blkdev_issue_secure_erase(): \ta.out: attempt to access beyond end of device \tloop0: rw=5, sector=3399043073, nr_sectors = 1024 limit=2048 \tbio_check_eod: 3286214 callbacks suppressed", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49929", "url": "https://ubuntu.com/security/CVE-2024-49929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: avoid NULL pointer dereference iwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta pointer is not NULL. It retrieves this pointer using iwl_mvm_sta_from_mac80211, which is dereferencing the ieee80211_sta pointer. If sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL pointer. Fix this by checking the sta pointer before retrieving the mvmsta from it. If sta is not NULL, then mvmsta isn't either.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49995", "url": "https://ubuntu.com/security/CVE-2024-49995", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: guard against string buffer overrun Smatch reports that copying media_name and if_name to name_parts may overwrite the destination. .../bearer.c:166 bearer_name_validate() error: strcpy() 'media_name' too large for 'name_parts->media_name' (32 vs 16) .../bearer.c:167 bearer_name_validate() error: strcpy() 'if_name' too large for 'name_parts->if_name' (1010102 vs 16) This does seem to be the case so guard against this possibility by using strscpy() and failing if truncation occurs. Introduced by commit b97bf3fd8f6a (\"[TIPC] Initial merge\") Compile tested only.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49962", "url": "https://ubuntu.com/security/CVE-2024-49962", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in acpi_db_convert_to_package() ACPICA commit 4d4547cf13cca820ff7e0f859ba83e1a610b9fd0 ACPI_ALLOCATE_ZEROED() may fail, elements might be NULL and will cause NULL pointer dereference later. [ rjw: Subject and changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49930", "url": "https://ubuntu.com/security/CVE-2024-49930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix array out-of-bound access in SoC stats Currently, the ath11k_soc_dp_stats::hal_reo_error array is defined with a maximum size of DP_REO_DST_RING_MAX. However, the ath11k_dp_process_rx() function access ath11k_soc_dp_stats::hal_reo_error using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath11k_dp_process_rx() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49931", "url": "https://ubuntu.com/security/CVE-2024-49931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix array out-of-bound access in SoC stats Currently, the ath12k_soc_dp_stats::hal_reo_error array is defined with a maximum size of DP_REO_DST_RING_MAX. However, the ath12k_dp_rx_process() function access ath12k_soc_dp_stats::hal_reo_error using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath12k_dp_rx_process() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49932", "url": "https://ubuntu.com/security/CVE-2024-49932", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: don't readahead the relocation inode on RST On relocation we're doing readahead on the relocation inode, but if the filesystem is backed by a RAID stripe tree we can get ENOENT (e.g. due to preallocated extents not being mapped in the RST) from the lookup. But readahead doesn't handle the error and submits invalid reads to the device, causing an assertion in the scatter-gather list code: BTRFS info (device nvme1n1): balance: start -d -m -s BTRFS info (device nvme1n1): relocating block group 6480920576 flags data|raid0 BTRFS error (device nvme1n1): cannot find raid-stripe for logical [6481928192, 6481969152] devid 2, profile raid0 ------------[ cut here ]------------ kernel BUG at include/linux/scatterlist.h:115! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 1012 Comm: btrfs Not tainted 6.10.0-rc7+ #567 RIP: 0010:__blk_rq_map_sg+0x339/0x4a0 RSP: 0018:ffffc90001a43820 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffea00045d4802 RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000 RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000001000 R12: ffff8881003d10b8 R13: ffffc90001a438f0 R14: 0000000000000000 R15: 0000000000003000 FS: 00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000002cd11000 CR3: 00000001109ea001 CR4: 0000000000370eb0 Call Trace: ? __die_body.cold+0x14/0x25 ? die+0x2e/0x50 ? do_trap+0xca/0x110 ? do_error_trap+0x65/0x80 ? __blk_rq_map_sg+0x339/0x4a0 ? exc_invalid_op+0x50/0x70 ? __blk_rq_map_sg+0x339/0x4a0 ? asm_exc_invalid_op+0x1a/0x20 ? __blk_rq_map_sg+0x339/0x4a0 nvme_prep_rq.part.0+0x9d/0x770 nvme_queue_rq+0x7d/0x1e0 __blk_mq_issue_directly+0x2a/0x90 ? blk_mq_get_budget_and_tag+0x61/0x90 blk_mq_try_issue_list_directly+0x56/0xf0 blk_mq_flush_plug_list.part.0+0x52b/0x5d0 __blk_flush_plug+0xc6/0x110 blk_finish_plug+0x28/0x40 read_pages+0x160/0x1c0 page_cache_ra_unbounded+0x109/0x180 relocate_file_extent_cluster+0x611/0x6a0 ? btrfs_search_slot+0xba4/0xd20 ? balance_dirty_pages_ratelimited_flags+0x26/0xb00 relocate_data_extent.constprop.0+0x134/0x160 relocate_block_group+0x3f2/0x500 btrfs_relocate_block_group+0x250/0x430 btrfs_relocate_chunk+0x3f/0x130 btrfs_balance+0x71b/0xef0 ? kmalloc_trace_noprof+0x13b/0x280 btrfs_ioctl+0x2c2e/0x3030 ? kvfree_call_rcu+0x1e6/0x340 ? list_lru_add_obj+0x66/0x80 ? mntput_no_expire+0x3a/0x220 __x64_sys_ioctl+0x96/0xc0 do_syscall_64+0x54/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fcc04514f9b Code: Unable to access opcode bytes at 0x7fcc04514f71. RSP: 002b:00007ffeba923370 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fcc04514f9b RDX: 00007ffeba923460 RSI: 00000000c4009420 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000013 R09: 0000000000000001 R10: 00007fcc043fbba8 R11: 0000000000000246 R12: 00007ffeba924fc5 R13: 00007ffeba923460 R14: 0000000000000002 R15: 00000000004d4bb0 Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:__blk_rq_map_sg+0x339/0x4a0 RSP: 0018:ffffc90001a43820 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffea00045d4802 RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000 RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000001000 R12: ffff8881003d10b8 R13: ffffc90001a438f0 R14: 0000000000000000 R15: 0000000000003000 FS: 00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcc04514f71 CR3: 00000001109ea001 CR4: 0000000000370eb0 Kernel p ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49933", "url": "https://ubuntu.com/security/CVE-2024-49933", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk_iocost: fix more out of bound shifts Recently running UBSAN caught few out of bound shifts in the ioc_forgive_debts() function: UBSAN: shift-out-of-bounds in block/blk-iocost.c:2142:38 shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long long') ... UBSAN: shift-out-of-bounds in block/blk-iocost.c:2144:30 shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long long') ... Call Trace: dump_stack_lvl+0xca/0x130 __ubsan_handle_shift_out_of_bounds+0x22c/0x280 ? __lock_acquire+0x6441/0x7c10 ioc_timer_fn+0x6cec/0x7750 ? blk_iocost_init+0x720/0x720 ? call_timer_fn+0x5d/0x470 call_timer_fn+0xfa/0x470 ? blk_iocost_init+0x720/0x720 __run_timer_base+0x519/0x700 ... Actual impact of this issue was not identified but I propose to fix the undefined behaviour. The proposed fix to prevent those out of bound shifts consist of precalculating exponent before using it the shift operations by taking min value from the actual exponent and maximum possible number of bits.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49934", "url": "https://ubuntu.com/security/CVE-2024-49934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/inode: Prevent dump_mapping() accessing invalid dentry.d_name.name It's observed that a crash occurs during hot-remove a memory device, in which user is accessing the hugetlb. See calltrace as following: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 14045 at arch/x86/mm/fault.c:1278 do_user_addr_fault+0x2a0/0x790 Modules linked in: kmem device_dax cxl_mem cxl_pmem cxl_port cxl_pci dax_hmem dax_pmem nd_pmem cxl_acpi nd_btt cxl_core crc32c_intel nvme virtiofs fuse nvme_core nfit libnvdimm dm_multipath scsi_dh_rdac scsi_dh_emc s mirror dm_region_hash dm_log dm_mod CPU: 1 PID: 14045 Comm: daxctl Not tainted 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:do_user_addr_fault+0x2a0/0x790 Code: 48 8b 00 a8 04 0f 84 b5 fe ff ff e9 1c ff ff ff 4c 89 e9 4c 89 e2 be 01 00 00 00 bf 02 00 00 00 e8 b5 ef 24 00 e9 42 fe ff ff <0f> 0b 48 83 c4 08 4c 89 ea 48 89 ee 4c 89 e7 5b 5d 41 5c 41 5d 41 RSP: 0000:ffffc90000a575f0 EFLAGS: 00010046 RAX: ffff88800c303600 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000001000 RSI: ffffffff82504162 RDI: ffffffff824b2c36 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffc90000a57658 R13: 0000000000001000 R14: ffff88800bc2e040 R15: 0000000000000000 FS: 00007f51cb57d880(0000) GS:ffff88807fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000001000 CR3: 00000000072e2004 CR4: 00000000001706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn+0x8d/0x190 ? do_user_addr_fault+0x2a0/0x790 ? report_bug+0x1c3/0x1d0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? do_user_addr_fault+0x2a0/0x790 ? exc_page_fault+0x31/0x200 exc_page_fault+0x68/0x200 <...snip...> BUG: unable to handle page fault for address: 0000000000001000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI ---[ end trace 0000000000000000 ]--- BUG: unable to handle page fault for address: 0000000000001000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 14045 Comm: daxctl Kdump: loaded Tainted: G W 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:dentry_name+0x1f4/0x440 <...snip...> ? dentry_name+0x2fa/0x440 vsnprintf+0x1f3/0x4f0 vprintk_store+0x23a/0x540 vprintk_emit+0x6d/0x330 _printk+0x58/0x80 dump_mapping+0x10b/0x1a0 ? __pfx_free_object_rcu+0x10/0x10 __dump_page+0x26b/0x3e0 ? vprintk_emit+0xe0/0x330 ? _printk+0x58/0x80 ? dump_page+0x17/0x50 dump_page+0x17/0x50 do_migrate_range+0x2f7/0x7f0 ? do_migrate_range+0x42/0x7f0 ? offline_pages+0x2f4/0x8c0 offline_pages+0x60a/0x8c0 memory_subsys_offline+0x9f/0x1c0 ? lockdep_hardirqs_on+0x77/0x100 ? _raw_spin_unlock_irqrestore+0x38/0x60 device_offline+0xe3/0x110 state_store+0x6e/0xc0 kernfs_fop_write_iter+0x143/0x200 vfs_write+0x39f/0x560 ksys_write+0x65/0xf0 do_syscall_64+0x62/0x130 Previously, some sanity check have been done in dump_mapping() before the print facility parsing '%pd' though, it's still possible to run into an invalid dentry.d_name.name. Since dump_mapping() only needs to dump the filename only, retrieve it by itself in a safer way to prevent an unnecessary crash. Note that either retrieving the filename with '%pd' or strncpy_from_kernel_nofault(), the filename could be unreliable.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49935", "url": "https://ubuntu.com/security/CVE-2024-49935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: PAD: fix crash in exit_round_robin() The kernel occasionally crashes in cpumask_clear_cpu(), which is called within exit_round_robin(), because when executing clear_bit(nr, addr) with nr set to 0xffffffff, the address calculation may cause misalignment within the memory, leading to access to an invalid memory address. ---------- BUG: unable to handle kernel paging request at ffffffffe0740618 ... CPU: 3 PID: 2919323 Comm: acpi_pad/14 Kdump: loaded Tainted: G OE X --------- - - 4.18.0-425.19.2.el8_7.x86_64 #1 ... RIP: 0010:power_saving_thread+0x313/0x411 [acpi_pad] Code: 89 cd 48 89 d3 eb d1 48 c7 c7 55 70 72 c0 e8 64 86 b0 e4 c6 05 0d a1 02 00 01 e9 bc fd ff ff 45 89 e4 42 8b 04 a5 20 82 72 c0 48 0f b3 05 f4 9c 01 00 42 c7 04 a5 20 82 72 c0 ff ff ff ff 31 RSP: 0018:ff72a5d51fa77ec8 EFLAGS: 00010202 RAX: 00000000ffffffff RBX: ff462981e5d8cb80 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246 RBP: ff46297556959d80 R08: 0000000000000382 R09: ff46297c8d0f38d8 R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000000e R13: 0000000000000000 R14: ffffffffffffffff R15: 000000000000000e FS: 0000000000000000(0000) GS:ff46297a800c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffe0740618 CR3: 0000007e20410004 CR4: 0000000000771ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? acpi_pad_add+0x120/0x120 [acpi_pad] kthread+0x10b/0x130 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x1f/0x40 ... CR2: ffffffffe0740618 crash> dis -lr ffffffffc0726923 ... /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 114 0xffffffffc0726918 :\tmov %r12d,%r12d /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 325 0xffffffffc072691b :\tmov -0x3f8d7de0(,%r12,4),%eax /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./arch/x86/include/asm/bitops.h: 80 0xffffffffc0726923 :\tlock btr %rax,0x19cf4(%rip) # 0xffffffffc0740620 crash> px tsk_in_cpu[14] $66 = 0xffffffff crash> px 0xffffffffc072692c+0x19cf4 $99 = 0xffffffffc0740620 crash> sym 0xffffffffc0740620 ffffffffc0740620 (b) pad_busy_cpus_bits [acpi_pad] crash> px pad_busy_cpus_bits[0] $42 = 0xfffc0 ---------- To fix this, ensure that tsk_in_cpu[tsk_index] != -1 before calling cpumask_clear_cpu() in exit_round_robin(), just as it is done in round_robin_cpu(). [ rjw: Subject edit, avoid updates to the same value ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49936", "url": "https://ubuntu.com/security/CVE-2024-49936", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/xen-netback: prevent UAF in xenvif_flush_hash() During the list_for_each_entry_rcu iteration call of xenvif_flush_hash, kfree_rcu does not exist inside the rcu read critical section, so if kfree_rcu is called when the rcu grace period ends during the iteration, UAF occurs when accessing head->next after the entry becomes free. Therefore, to solve this, you need to change it to list_for_each_entry_safe.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49937", "url": "https://ubuntu.com/security/CVE-2024-49937", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Set correct chandef when starting CAC When starting CAC in a mode other than AP mode, it return a \"WARNING: CPU: 0 PID: 63 at cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]\" caused by the chandef.chan being null at the end of CAC. Solution: Ensure the channel definition is set for the different modes when starting CAC to avoid getting a NULL 'chan' at the end of CAC. Call Trace: ? show_regs.part.0+0x14/0x16 ? __warn+0x67/0xc0 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? report_bug+0xa7/0x130 ? exc_overflow+0x30/0x30 ? handle_bug+0x27/0x50 ? exc_invalid_op+0x18/0x60 ? handle_exception+0xf6/0xf6 ? exc_overflow+0x30/0x30 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? exc_overflow+0x30/0x30 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? regulatory_propagate_dfs_state.cold+0x1b/0x4c [cfg80211] ? cfg80211_propagate_cac_done_wk+0x1a/0x30 [cfg80211] ? process_one_work+0x165/0x280 ? worker_thread+0x120/0x3f0 ? kthread+0xc2/0xf0 ? process_one_work+0x280/0x280 ? kthread_complete_and_exit+0x20/0x20 ? ret_from_fork+0x19/0x24 [shorten subject, remove OCB, reorder cases to match previous list]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49938", "url": "https://ubuntu.com/security/CVE-2024-49938", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmit Syzbot points out that skb_trim() has a sanity check on the existing length of the skb, which can be uninitialised in some error paths. The intent here is clearly just to reset the length to zero before resubmitting, so switch to calling __skb_set_length(skb, 0) directly. In addition, __skb_set_length() already contains a call to skb_reset_tail_pointer(), so remove the redundant call. The syzbot report came from ath9k_hif_usb_reg_in_cb(), but there's a similar usage of skb_trim() in ath9k_hif_usb_rx_cb(), change both while we're at it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49939", "url": "https://ubuntu.com/security/CVE-2024-49939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: avoid to add interface to list twice when SER If SER L2 occurs during the WoWLAN resume flow, the add interface flow is triggered by ieee80211_reconfig(). However, due to rtw89_wow_resume() return failure, it will cause the add interface flow to be executed again, resulting in a double add list and causing a kernel panic. Therefore, we have added a check to prevent double adding of the list. list_add double add: new=ffff99d6992e2010, prev=ffff99d6992e2010, next=ffff99d695302628. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:37! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G W O 6.6.30-02659-gc18865c4dfbd #1 770df2933251a0e3c888ba69d1053a817a6376a7 Hardware name: HP Grunt/Grunt, BIOS Google_Grunt.11031.169.0 06/24/2021 Workqueue: events_freezable ieee80211_restart_work [mac80211] RIP: 0010:__list_add_valid_or_report+0x5e/0xb0 Code: c7 74 18 48 39 ce 74 13 b0 01 59 5a 5e 5f 41 58 41 59 41 5a 5d e9 e2 d6 03 00 cc 48 c7 c7 8d 4f 17 83 48 89 c2 e8 02 c0 00 00 <0f> 0b 48 c7 c7 aa 8c 1c 83 e8 f4 bf 00 00 0f 0b 48 c7 c7 c8 bc 12 RSP: 0018:ffffa91b8007bc50 EFLAGS: 00010246 RAX: 0000000000000058 RBX: ffff99d6992e0900 RCX: a014d76c70ef3900 RDX: ffffa91b8007bae8 RSI: 00000000ffffdfff RDI: 0000000000000001 RBP: ffffa91b8007bc88 R08: 0000000000000000 R09: ffffa91b8007bae0 R10: 00000000ffffdfff R11: ffffffff83a79800 R12: ffff99d695302060 R13: ffff99d695300900 R14: ffff99d6992e1be0 R15: ffff99d6992e2010 FS: 0000000000000000(0000) GS:ffff99d6aac00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000078fbdba43480 CR3: 000000010e464000 CR4: 00000000001506f0 Call Trace: ? __die_body+0x1f/0x70 ? die+0x3d/0x60 ? do_trap+0xa4/0x110 ? __list_add_valid_or_report+0x5e/0xb0 ? do_error_trap+0x6d/0x90 ? __list_add_valid_or_report+0x5e/0xb0 ? handle_invalid_op+0x30/0x40 ? __list_add_valid_or_report+0x5e/0xb0 ? exc_invalid_op+0x3c/0x50 ? asm_exc_invalid_op+0x16/0x20 ? __list_add_valid_or_report+0x5e/0xb0 rtw89_ops_add_interface+0x309/0x310 [rtw89_core 7c32b1ee6854761c0321027c8a58c5160e41f48f] drv_add_interface+0x5c/0x130 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ieee80211_reconfig+0x241/0x13d0 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ? finish_wait+0x3e/0x90 ? synchronize_rcu_expedited+0x174/0x260 ? sync_rcu_exp_done_unlocked+0x50/0x50 ? wake_bit_function+0x40/0x40 ieee80211_restart_work+0xf0/0x140 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] process_scheduled_works+0x1e5/0x480 worker_thread+0xea/0x1e0 kthread+0xdb/0x110 ? move_linked_works+0x90/0x90 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork+0x3b/0x50 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork_asm+0x11/0x20 Modules linked in: dm_integrity async_xor xor async_tx lz4 lz4_compress zstd zstd_compress zram zsmalloc rfcomm cmac uinput algif_hash algif_skcipher af_alg btusb btrtl iio_trig_hrtimer industrialio_sw_trigger btmtk industrialio_configfs btbcm btintel uvcvideo videobuf2_vmalloc iio_trig_sysfs videobuf2_memops videobuf2_v4l2 videobuf2_common uvc snd_hda_codec_hdmi veth snd_hda_intel snd_intel_dspcfg acpi_als snd_hda_codec industrialio_triggered_buffer kfifo_buf snd_hwdep industrialio i2c_piix4 snd_hda_core designware_i2s ip6table_nat snd_soc_max98357a xt_MASQUERADE xt_cgroup snd_soc_acp_rt5682_mach fuse rtw89_8922ae(O) rtw89_8922a(O) rtw89_pci(O) rtw89_core(O) 8021q mac80211(O) bluetooth ecdh_generic ecc cfg80211 r8152 mii joydev gsmi: Log Shutdown Reason 0x03 ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49940", "url": "https://ubuntu.com/security/CVE-2024-49940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: prevent possible tunnel refcount underflow When a session is created, it sets a backpointer to its tunnel. When the session refcount drops to 0, l2tp_session_free drops the tunnel refcount if session->tunnel is non-NULL. However, session->tunnel is set in l2tp_session_create, before the tunnel refcount is incremented by l2tp_session_register, which leaves a small window where session->tunnel is non-NULL when the tunnel refcount hasn't been bumped. Moving the assignment to l2tp_session_register is trivial but l2tp_session_create calls l2tp_session_set_header_len which uses session->tunnel to get the tunnel's encap. Add an encap arg to l2tp_session_set_header_len to avoid using session->tunnel. If l2tpv3 sessions have colliding IDs, it is possible for l2tp_v3_session_get to race with l2tp_session_register and fetch a session which doesn't yet have session->tunnel set. Add a check for this case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49941", "url": "https://ubuntu.com/security/CVE-2024-49941", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpiolib: Fix potential NULL pointer dereference in gpiod_get_label() In `gpiod_get_label()`, it is possible that `srcu_dereference_check()` may return a NULL pointer, leading to a scenario where `label->str` is accessed without verifying if `label` itself is NULL. This patch adds a proper NULL check for `label` before accessing `label->str`. The check for `label->str != NULL` is removed because `label->str` can never be NULL if `label` is not NULL. This fixes the issue where the label name was being printed as `(efault)` when dumping the sysfs GPIO file when `label == NULL`.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49996", "url": "https://ubuntu.com/security/CVE-2024-49996", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: Fix buffer overflow when parsing NFS reparse points ReparseDataLength is sum of the InodeType size and DataBuffer size. So to get DataBuffer size it is needed to subtract InodeType's size from ReparseDataLength. Function cifs_strndup_from_utf16() is currentlly accessing buf->DataBuffer at position after the end of the buffer because it does not subtract InodeType size from the length. Fix this problem and correctly subtract variable len. Member InodeType is present only when reparse buffer is large enough. Check for ReparseDataLength before accessing InodeType to prevent another invalid memory access. Major and minor rdev values are present also only when reparse buffer is large enough. Check for reparse buffer size before calling reparse_mkdev().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49942", "url": "https://ubuntu.com/security/CVE-2024-49942", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Prevent null pointer access in xe_migrate_copy xe_migrate_copy designed to copy content of TTM resources. When source resource is null, it will trigger a NULL pointer dereference in xe_migrate_copy. To avoid this situation, update lacks source flag to true for this case, the flag will trigger xe_migrate_clear rather than xe_migrate_copy. Issue trace: <7> [317.089847] xe 0000:00:02.0: [drm:xe_migrate_copy [xe]] Pass 14, sizes: 4194304 & 4194304 <7> [317.089945] xe 0000:00:02.0: [drm:xe_migrate_copy [xe]] Pass 15, sizes: 4194304 & 4194304 <1> [317.128055] BUG: kernel NULL pointer dereference, address: 0000000000000010 <1> [317.128064] #PF: supervisor read access in kernel mode <1> [317.128066] #PF: error_code(0x0000) - not-present page <6> [317.128069] PGD 0 P4D 0 <4> [317.128071] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI <4> [317.128074] CPU: 1 UID: 0 PID: 1440 Comm: kunit_try_catch Tainted: G U N 6.11.0-rc7-xe #1 <4> [317.128078] Tainted: [U]=USER, [N]=TEST <4> [317.128080] Hardware name: Intel Corporation Lunar Lake Client Platform/LNL-M LP5 RVP1, BIOS LNLMFWI1.R00.3221.D80.2407291239 07/29/2024 <4> [317.128082] RIP: 0010:xe_migrate_copy+0x66/0x13e0 [xe] <4> [317.128158] Code: 00 00 48 89 8d e0 fe ff ff 48 8b 40 10 4c 89 85 c8 fe ff ff 44 88 8d bd fe ff ff 65 48 8b 3c 25 28 00 00 00 48 89 7d d0 31 ff <8b> 79 10 48 89 85 a0 fe ff ff 48 8b 00 48 89 b5 d8 fe ff ff 83 ff <4> [317.128162] RSP: 0018:ffffc9000167f9f0 EFLAGS: 00010246 <4> [317.128164] RAX: ffff8881120d8028 RBX: ffff88814d070428 RCX: 0000000000000000 <4> [317.128166] RDX: ffff88813cb99c00 RSI: 0000000004000000 RDI: 0000000000000000 <4> [317.128168] RBP: ffffc9000167fbb8 R08: ffff88814e7b1f08 R09: 0000000000000001 <4> [317.128170] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88814e7b1f08 <4> [317.128172] R13: ffff88814e7b1f08 R14: ffff88813cb99c00 R15: 0000000000000001 <4> [317.128174] FS: 0000000000000000(0000) GS:ffff88846f280000(0000) knlGS:0000000000000000 <4> [317.128176] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [317.128178] CR2: 0000000000000010 CR3: 000000011f676004 CR4: 0000000000770ef0 <4> [317.128180] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 <4> [317.128182] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400 <4> [317.128184] PKRU: 55555554 <4> [317.128185] Call Trace: <4> [317.128187] <4> [317.128189] ? show_regs+0x67/0x70 <4> [317.128194] ? __die_body+0x20/0x70 <4> [317.128196] ? __die+0x2b/0x40 <4> [317.128198] ? page_fault_oops+0x15f/0x4e0 <4> [317.128203] ? do_user_addr_fault+0x3fb/0x970 <4> [317.128205] ? lock_acquire+0xc7/0x2e0 <4> [317.128209] ? exc_page_fault+0x87/0x2b0 <4> [317.128212] ? asm_exc_page_fault+0x27/0x30 <4> [317.128216] ? xe_migrate_copy+0x66/0x13e0 [xe] <4> [317.128263] ? __lock_acquire+0xb9d/0x26f0 <4> [317.128265] ? __lock_acquire+0xb9d/0x26f0 <4> [317.128267] ? sg_free_append_table+0x20/0x80 <4> [317.128271] ? lock_acquire+0xc7/0x2e0 <4> [317.128273] ? mark_held_locks+0x4d/0x80 <4> [317.128275] ? trace_hardirqs_on+0x1e/0xd0 <4> [317.128278] ? _raw_spin_unlock_irqrestore+0x31/0x60 <4> [317.128281] ? __pm_runtime_resume+0x60/0xa0 <4> [317.128284] xe_bo_move+0x682/0xc50 [xe] <4> [317.128315] ? lock_is_held_type+0xaa/0x120 <4> [317.128318] ttm_bo_handle_move_mem+0xe5/0x1a0 [ttm] <4> [317.128324] ttm_bo_validate+0xd1/0x1a0 [ttm] <4> [317.128328] shrink_test_run_device+0x721/0xc10 [xe] <4> [317.128360] ? find_held_lock+0x31/0x90 <4> [317.128363] ? lock_release+0xd1/0x2a0 <4> [317.128365] ? __pfx_kunit_generic_run_threadfn_adapter+0x10/0x10 [kunit] <4> [317.128370] xe_bo_shrink_kunit+0x11/0x20 [xe] <4> [317.128397] kunit_try_run_case+0x6e/0x150 [kunit] <4> [317.128400] ? trace_hardirqs_on+0x1e/0xd0 <4> [317.128402] ? _raw_spin_unlock_irqrestore+0x31/0x60 <4> [317.128404] kunit_generic_run_threadfn_adapter+0x1e/0x40 [ku ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49943", "url": "https://ubuntu.com/security/CVE-2024-49943", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc_submit: add missing locking in wedged_fini Any non-wedged queue can have a zero refcount here and can be running concurrently with an async queue destroy, therefore dereferencing the queue ptr to check wedge status after the lookup can trigger UAF if queue is not wedged. Fix this by keeping the submission_state lock held around the check to postpone the free and make the check safe, before dropping again around the put() to avoid the deadlock. (cherry picked from commit d28af0b6b9580b9f90c265a7da0315b0ad20bbfd)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50011", "url": "https://ubuntu.com/security/CVE-2024-50011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: soc-acpi-intel-rpl-match: add missing empty item There is no links_num in struct snd_soc_acpi_mach {}, and we test !link->num_adr as a condition to end the loop in hda_sdw_machine_select(). So an empty item in struct snd_soc_acpi_link_adr array is required.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50174", "url": "https://ubuntu.com/security/CVE-2024-50174", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix race when converting group handle to group object XArray provides it's own internal lock which protects the internal array when entries are being simultaneously added and removed. However there is still a race between retrieving the pointer from the XArray and incrementing the reference count. To avoid this race simply hold the internal XArray lock when incrementing the reference count, this ensures there cannot be a racing call to xa_erase().", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49944", "url": "https://ubuntu.com/security/CVE-2024-49944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_start In sctp_listen_start() invoked by sctp_inet_listen(), it should set the sk_state back to CLOSED if sctp_autobind() fails due to whatever reason. Otherwise, next time when calling sctp_inet_listen(), if sctp_sk(sk)->reuse is already set via setsockopt(SCTP_REUSE_PORT), sctp_sk(sk)->bind_hash will be dereferenced as sk_state is LISTENING, which causes a crash as bind_hash is NULL. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:sctp_inet_listen+0x7f0/0xa20 net/sctp/socket.c:8617 Call Trace: __sys_listen_socket net/socket.c:1883 [inline] __sys_listen+0x1b7/0x230 net/socket.c:1894 __do_sys_listen net/socket.c:1902 [inline]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49945", "url": "https://ubuntu.com/security/CVE-2024-49945", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/ncsi: Disable the ncsi work before freeing the associated structure The work function can run after the ncsi device is freed, resulting in use-after-free bugs or kernel panic.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49946", "url": "https://ubuntu.com/security/CVE-2024-49946", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: do not assume bh is held in ppp_channel_bridge_input() Networking receive path is usually handled from BH handler. However, some protocols need to acquire the socket lock, and packets might be stored in the socket backlog is the socket was owned by a user process. In this case, release_sock(), __release_sock(), and sk_backlog_rcv() might call the sk->sk_backlog_rcv() handler in process context. sybot caught ppp was not considering this case in ppp_channel_bridge_input() : WARNING: inconsistent lock state 6.11.0-rc7-syzkaller-g5f5673607153 #0 Not tainted -------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. ksoftirqd/1/24 [HC0[0]:SC1[1]:HE1:SE0] takes: ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 {SOFTIRQ-ON-W} state was registered at: lock_acquire+0x240/0x728 kernel/locking/lockdep.c:5759 __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline] _raw_spin_lock+0x48/0x60 kernel/locking/spinlock.c:154 spin_lock include/linux/spinlock.h:351 [inline] ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline] ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0xfc/0x314 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv include/net/sock.h:1111 [inline] __release_sock+0x1a8/0x3d8 net/core/sock.c:3004 release_sock+0x68/0x1b8 net/core/sock.c:3558 pppoe_sendmsg+0xc8/0x5d8 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x374/0x4f4 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __arm64_sys_sendto+0xd8/0xf8 net/socket.c:2212 __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:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 irq event stamp: 282914 hardirqs last enabled at (282914): [] __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:151 [inline] hardirqs last enabled at (282914): [] _raw_spin_unlock_irqrestore+0x38/0x98 kernel/locking/spinlock.c:194 hardirqs last disabled at (282913): [] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline] hardirqs last disabled at (282913): [] _raw_spin_lock_irqsave+0x2c/0x7c kernel/locking/spinlock.c:162 softirqs last enabled at (282904): [] softirq_handle_end kernel/softirq.c:400 [inline] softirqs last enabled at (282904): [] handle_softirqs+0xa3c/0xbfc kernel/softirq.c:582 softirqs last disabled at (282909): [] run_ksoftirqd+0x70/0x158 kernel/softirq.c:928 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&pch->downl); lock(&pch->downl); *** DEADLOCK *** 1 lock held by ksoftirqd/1/24: #0: ffff80008f74dfa0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire+0x10/0x4c include/linux/rcupdate.h:325 stack backtrace: CPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 6.11.0-rc7-syzkaller-g5f5673607153 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call trace: dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:319 show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:326 __dump_sta ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49947", "url": "https://ubuntu.com/security/CVE-2024-49947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: test for not too small csum_start in virtio_net_hdr_to_skb() syzbot was able to trigger this warning [1], after injecting a malicious packet through af_packet, setting skb->csum_start and thus the transport header to an incorrect value. We can at least make sure the transport header is after the end of the network header (with a estimated minimal size). [1] [ 67.873027] skb len=4096 headroom=16 headlen=14 tailroom=0 mac=(-1,-1) mac_len=0 net=(16,-6) trans=10 shinfo(txflags=0 nr_frags=1 gso(size=0 type=0 segs=0)) csum(0xa start=10 offset=0 ip_summed=3 complete_sw=0 valid=0 level=0) hash(0x0 sw=0 l4=0) proto=0x0800 pkttype=0 iif=0 priority=0x0 mark=0x0 alloc_cpu=10 vlan_all=0x0 encapsulation=0 inner(proto=0x0000, mac=0, net=0, trans=0) [ 67.877172] dev name=veth0_vlan feat=0x000061164fdd09e9 [ 67.877764] sk family=17 type=3 proto=0 [ 67.878279] skb linear: 00000000: 00 00 10 00 00 00 00 00 0f 00 00 00 08 00 [ 67.879128] skb frag: 00000000: 0e 00 07 00 00 00 28 00 08 80 1c 00 04 00 00 02 [ 67.879877] skb frag: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.880647] skb frag: 00000020: 00 00 02 00 00 00 08 00 1b 00 00 00 00 00 00 00 [ 67.881156] skb frag: 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.881753] skb frag: 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.882173] skb frag: 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.882790] skb frag: 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.883171] skb frag: 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.883733] skb frag: 00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.884206] skb frag: 00000090: 00 00 00 00 00 00 00 00 00 00 69 70 76 6c 61 6e [ 67.884704] skb frag: 000000a0: 31 00 00 00 00 00 00 00 00 00 2b 00 00 00 00 00 [ 67.885139] skb frag: 000000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.885677] skb frag: 000000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.886042] skb frag: 000000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.886408] skb frag: 000000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.887020] skb frag: 000000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.887384] skb frag: 00000100: 00 00 [ 67.887878] ------------[ cut here ]------------ [ 67.887908] offset (-6) >= skb_headlen() (14) [ 67.888445] WARNING: CPU: 10 PID: 2088 at net/core/dev.c:3332 skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.889353] Modules linked in: macsec macvtap macvlan hsr wireguard curve25519_x86_64 libcurve25519_generic libchacha20poly1305 chacha_x86_64 libchacha poly1305_x86_64 dummy bridge sr_mod cdrom evdev pcspkr i2c_piix4 9pnet_virtio 9p 9pnet netfs [ 67.890111] CPU: 10 UID: 0 PID: 2088 Comm: b363492833 Not tainted 6.11.0-virtme #1011 [ 67.890183] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 67.890309] RIP: 0010:skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891043] Call Trace: [ 67.891173] [ 67.891274] ? __warn (kernel/panic.c:741) [ 67.891320] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891333] ? report_bug (lib/bug.c:180 lib/bug.c:219) [ 67.891348] ? handle_bug (arch/x86/kernel/traps.c:239) [ 67.891363] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) [ 67.891372] ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621) [ 67.891388] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891399] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891416] ip_do_fragment (net/ipv4/ip_output.c:777 (discriminator 1)) [ 67.891448] ? __ip_local_out (./include/linux/skbuff.h:1146 ./include/net/l3mdev.h:196 ./include/net/l3mdev.h:213 ne ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49948", "url": "https://ubuntu.com/security/CVE-2024-49948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: add more sanity checks to qdisc_pkt_len_init() One path takes care of SKB_GSO_DODGY, assuming skb->len is bigger than hdr_len. virtio_net_hdr_to_skb() does not fully dissect TCP headers, it only make sure it is at least 20 bytes. It is possible for an user to provide a malicious 'GSO' packet, total length of 80 bytes. - 20 bytes of IPv4 header - 60 bytes TCP header - a small gso_size like 8 virtio_net_hdr_to_skb() would declare this packet as a normal GSO packet, because it would see 40 bytes of payload, bigger than gso_size. We need to make detect this case to not underflow qdisc_skb_cb(skb)->pkt_len.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49949", "url": "https://ubuntu.com/security/CVE-2024-49949", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: avoid potential underflow in qdisc_pkt_len_init() with UFO After commit 7c6d2ecbda83 (\"net: be more gentle about silly gso requests coming from user\") virtio_net_hdr_to_skb() had sanity check to detect malicious attempts from user space to cook a bad GSO packet. Then commit cf9acc90c80ec (\"net: virtio_net_hdr_to_skb: count transport header in UFO\") while fixing one issue, allowed user space to cook a GSO packet with the following characteristic : IPv4 SKB_GSO_UDP, gso_size=3, skb->len = 28. When this packet arrives in qdisc_pkt_len_init(), we end up with hdr_len = 28 (IPv4 header + UDP header), matching skb->len Then the following sets gso_segs to 0 : gso_segs = DIV_ROUND_UP(skb->len - hdr_len, shinfo->gso_size); Then later we set qdisc_skb_cb(skb)->pkt_len to back to zero :/ qdisc_skb_cb(skb)->pkt_len += (gso_segs - 1) * hdr_len; This leads to the following crash in fq_codel [1] qdisc_pkt_len_init() is best effort, we only want an estimation of the bytes sent on the wire, not crashing the kernel. This patch is fixing this particular issue, a following one adds more sanity checks for another potential bug. [1] [ 70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 70.724561] #PF: supervisor read access in kernel mode [ 70.724561] #PF: error_code(0x0000) - not-present page [ 70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0 [ 70.724561] Oops: Oops: 0000 [#1] SMP NOPTI [ 70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991 [ 70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel [ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 <49> 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49 All code ======== 0:\t24 08 \tand $0x8,%al 2:\t49 c1 e1 06 \tshl $0x6,%r9 6:\t44 89 7c 24 18 \tmov %r15d,0x18(%rsp) b:\t45 31 ed \txor %r13d,%r13d e:\t45 31 c0 \txor %r8d,%r8d 11:\t31 ff \txor %edi,%edi 13:\t89 44 24 14 \tmov %eax,0x14(%rsp) 17:\t4c 03 8b 90 01 00 00 \tadd 0x190(%rbx),%r9 1e:\teb 04 \tjmp 0x24 20:\t39 ca \tcmp %ecx,%edx 22:\t73 37 \tjae 0x5b 24:\t4d 8b 39 \tmov (%r9),%r15 27:\t83 c7 01 \tadd $0x1,%edi 2a:*\t49 8b 17 \tmov (%r15),%rdx\t\t<-- trapping instruction 2d:\t49 89 11 \tmov %rdx,(%r9) 30:\t41 8b 57 28 \tmov 0x28(%r15),%edx 34:\t45 8b 5f 34 \tmov 0x34(%r15),%r11d 38:\t49 c7 07 00 00 00 00 \tmovq $0x0,(%r15) 3f:\t49 \trex.WB Code starting with the faulting instruction =========================================== 0:\t49 8b 17 \tmov (%r15),%rdx 3:\t49 89 11 \tmov %rdx,(%r9) 6:\t41 8b 57 28 \tmov 0x28(%r15),%edx a:\t45 8b 5f 34 \tmov 0x34(%r15),%r11d e:\t49 c7 07 00 00 00 00 \tmovq $0x0,(%r15) 15:\t49 \trex.WB [ 70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202 [ 70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000 [ 70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001 [ 70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000 [ 70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58 [ 70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000 [ 70.724561] FS: 000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000 [ 70.724561] CS: 0010 DS: 0000 ES: 0000 C ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49997", "url": "https://ubuntu.com/security/CVE-2024-49997", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: lantiq_etop: fix memory disclosure When applying padding, the buffer is not zeroed, which results in memory disclosure. The mentioned data is observed on the wire. This patch uses skb_put_padto() to pad Ethernet frames properly. The mentioned function zeroes the expanded buffer. In case the packet cannot be padded it is silently dropped. Statistics are also not incremented. This driver does not support statistics in the old 32-bit format or the new 64-bit format. These will be added in the future. In its current form, the patch should be easily backported to stable versions. Ethernet MACs on Amazon-SE and Danube cannot do padding of the packets in hardware, so software padding must be applied.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49998", "url": "https://ubuntu.com/security/CVE-2024-49998", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: improve shutdown sequence Alexander Sverdlin presents 2 problems during shutdown with the lan9303 driver. One is specific to lan9303 and the other just happens to reproduce there. The first problem is that lan9303 is unique among DSA drivers in that it calls dev_get_drvdata() at \"arbitrary runtime\" (not probe, not shutdown, not remove): phy_state_machine() -> ... -> dsa_user_phy_read() -> ds->ops->phy_read() -> lan9303_phy_read() -> chip->ops->phy_read() -> lan9303_mdio_phy_read() -> dev_get_drvdata() But we never stop the phy_state_machine(), so it may continue to run after dsa_switch_shutdown(). Our common pattern in all DSA drivers is to set drvdata to NULL to suppress the remove() method that may come afterwards. But in this case it will result in an NPD. The second problem is that the way in which we set dp->conduit->dsa_ptr = NULL; is concurrent with receive packet processing. dsa_switch_rcv() checks once whether dev->dsa_ptr is NULL, but afterwards, rather than continuing to use that non-NULL value, dev->dsa_ptr is dereferenced again and again without NULL checks: dsa_conduit_find_user() and many other places. In between dereferences, there is no locking to ensure that what was valid once continues to be valid. Both problems have the common aspect that closing the conduit interface solves them. In the first case, dev_close(conduit) triggers the NETDEV_GOING_DOWN event in dsa_user_netdevice_event() which closes user ports as well. dsa_port_disable_rt() calls phylink_stop(), which synchronously stops the phylink state machine, and ds->ops->phy_read() will thus no longer call into the driver after this point. In the second case, dev_close(conduit) should do this, as per Documentation/networking/driver.rst: | Quiescence | ---------- | | After the ndo_stop routine has been called, the hardware must | not receive or transmit any data. All in flight packets must | be aborted. If necessary, poll or wait for completion of | any reset commands. So it should be sufficient to ensure that later, when we zeroize conduit->dsa_ptr, there will be no concurrent dsa_switch_rcv() call on this conduit. The addition of the netif_device_detach() function is to ensure that ioctls, rtnetlinks and ethtool requests on the user ports no longer propagate down to the driver - we're no longer prepared to handle them. The race condition actually did not exist when commit 0650bf52b31f (\"net: dsa: be compatible with masters which unregister on shutdown\") first introduced dsa_switch_shutdown(). It was created later, when we stopped unregistering the user interfaces from a bad spot, and we just replaced that sequence with a racy zeroization of conduit->dsa_ptr (one which doesn't ensure that the interfaces aren't up).", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49999", "url": "https://ubuntu.com/security/CVE-2024-49999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix the setting of the server responding flag In afs_wait_for_operation(), we set transcribe the call responded flag to the server record that we used after doing the fileserver iteration loop - but it's possible to exit the loop having had a response from the server that we've discarded (e.g. it returned an abort or we started receiving data, but the call didn't complete). This means that op->server might be NULL, but we don't check that before attempting to set the server flag.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49950", "url": "https://ubuntu.com/security/CVE-2024-49950", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix uaf in l2cap_connect [Syzbot reported] BUG: KASAN: slab-use-after-free in l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 Read of size 8 at addr ffff8880241e9800 by task kworker/u9:0/54 CPU: 0 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-00268-g788220eee30d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Workqueue: hci2 hci_rx_work Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 l2cap_connect_req net/bluetooth/l2cap_core.c:4080 [inline] l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:4772 [inline] l2cap_sig_channel net/bluetooth/l2cap_core.c:5543 [inline] l2cap_recv_frame+0xf0b/0x8eb0 net/bluetooth/l2cap_core.c:6825 l2cap_recv_acldata+0x9b4/0xb70 net/bluetooth/l2cap_core.c:7514 hci_acldata_packet net/bluetooth/hci_core.c:3791 [inline] hci_rx_work+0xaab/0x1610 net/bluetooth/hci_core.c:4028 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 ... Freed by task 5245: 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:579 poison_slab_object+0xf7/0x160 mm/kasan/common.c:240 __kasan_slab_free+0x32/0x50 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2256 [inline] slab_free mm/slub.c:4477 [inline] kfree+0x12a/0x3b0 mm/slub.c:4598 l2cap_conn_free net/bluetooth/l2cap_core.c:1810 [inline] kref_put include/linux/kref.h:65 [inline] l2cap_conn_put net/bluetooth/l2cap_core.c:1822 [inline] l2cap_conn_del+0x59d/0x730 net/bluetooth/l2cap_core.c:1802 l2cap_connect_cfm+0x9e6/0xf80 net/bluetooth/l2cap_core.c:7241 hci_connect_cfm include/net/bluetooth/hci_core.h:1960 [inline] hci_conn_failed+0x1c3/0x370 net/bluetooth/hci_conn.c:1265 hci_abort_conn_sync+0x75a/0xb50 net/bluetooth/hci_sync.c:5583 abort_conn_sync+0x197/0x360 net/bluetooth/hci_conn.c:2917 hci_cmd_sync_work+0x1a4/0x410 net/bluetooth/hci_sync.c:328 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49951", "url": "https://ubuntu.com/security/CVE-2024-49951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Fix possible crash on mgmt_index_removed If mgmt_index_removed is called while there are commands queued on cmd_sync it could lead to crashes like the bellow trace: 0x0000053D: __list_del_entry_valid_or_report+0x98/0xdc 0x0000053D: mgmt_pending_remove+0x18/0x58 [bluetooth] 0x0000053E: mgmt_remove_adv_monitor_complete+0x80/0x108 [bluetooth] 0x0000053E: hci_cmd_sync_work+0xbc/0x164 [bluetooth] So while handling mgmt_index_removed this attempts to dequeue commands passed as user_data to cmd_sync.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49952", "url": "https://ubuntu.com/security/CVE-2024-49952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: prevent nf_skb_duplicated corruption syzbot found that nf_dup_ipv4() or nf_dup_ipv6() could write per-cpu variable nf_skb_duplicated in an unsafe way [1]. Disabling preemption as hinted by the splat is not enough, we have to disable soft interrupts as well. [1] BUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316 caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49 nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook+0x2c4/0x450 include/linux/netfilter.h:269 NF_HOOK_COND include/linux/netfilter.h:302 [inline] ip_output+0x185/0x230 net/ipv4/ip_output.c:433 ip_local_out net/ipv4/ip_output.c:129 [inline] ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495 udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981 udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737 __do_sys_sendmmsg net/socket.c:2766 [inline] __se_sys_sendmmsg net/socket.c:2763 [inline] __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763 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:0x7f4ce4f7def9 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:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9 RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006 RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49953", "url": "https://ubuntu.com/security/CVE-2024-49953", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix crash caused by calling __xfrm_state_delete() twice The km.state is not checked in driver's delayed work. When xfrm_state_check_expire() is called, the state can be reset to XFRM_STATE_EXPIRED, even if it is XFRM_STATE_DEAD already. This happens when xfrm state is deleted, but not freed yet. As __xfrm_state_delete() is called again in xfrm timer, the following crash occurs. To fix this issue, skip xfrm_state_check_expire() if km.state is not XFRM_STATE_VALID. Oops: general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] SMP CPU: 5 UID: 0 PID: 7448 Comm: kworker/u102:2 Not tainted 6.11.0-rc2+ #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5e_ipsec: eth%d mlx5e_ipsec_handle_sw_limits [mlx5_core] RIP: 0010:__xfrm_state_delete+0x3d/0x1b0 Code: 0f 84 8b 01 00 00 48 89 fd c6 87 c8 00 00 00 05 48 8d bb 40 10 00 00 e8 11 04 1a 00 48 8b 95 b8 00 00 00 48 8b 85 c0 00 00 00 <48> 89 42 08 48 89 10 48 8b 55 10 48 b8 00 01 00 00 00 00 ad de 48 RSP: 0018:ffff88885f945ec8 EFLAGS: 00010246 RAX: dead000000000122 RBX: ffffffff82afa940 RCX: 0000000000000036 RDX: dead000000000100 RSI: 0000000000000000 RDI: ffffffff82afb980 RBP: ffff888109a20340 R08: ffff88885f945ea0 R09: 0000000000000000 R10: 0000000000000000 R11: ffff88885f945ff8 R12: 0000000000000246 R13: ffff888109a20340 R14: ffff88885f95f420 R15: ffff88885f95f400 FS: 0000000000000000(0000) GS:ffff88885f940000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2163102430 CR3: 00000001128d6001 CR4: 0000000000370eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? die_addr+0x33/0x90 ? exc_general_protection+0x1a2/0x390 ? asm_exc_general_protection+0x22/0x30 ? __xfrm_state_delete+0x3d/0x1b0 ? __xfrm_state_delete+0x2f/0x1b0 xfrm_timer_handler+0x174/0x350 ? __xfrm_state_delete+0x1b0/0x1b0 __hrtimer_run_queues+0x121/0x270 hrtimer_run_softirq+0x88/0xd0 handle_softirqs+0xcc/0x270 do_softirq+0x3c/0x50 __local_bh_enable_ip+0x47/0x50 mlx5e_ipsec_handle_sw_limits+0x7d/0x90 [mlx5_core] process_one_work+0x137/0x2d0 worker_thread+0x28d/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50000", "url": "https://ubuntu.com/security/CVE-2024-50000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix NULL deref in mlx5e_tir_builder_alloc() In mlx5e_tir_builder_alloc() kvzalloc() may return NULL which is dereferenced on the next line in a reference to the modify field. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50001", "url": "https://ubuntu.com/security/CVE-2024-50001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix error path in multi-packet WQE transmit Remove the erroneous unmap in case no DMA mapping was established The multi-packet WQE transmit code attempts to obtain a DMA mapping for the skb. This could fail, e.g. under memory pressure, when the IOMMU driver just can't allocate more memory for page tables. While the code tries to handle this in the path below the err_unmap label it erroneously unmaps one entry from the sq's FIFO list of active mappings. Since the current map attempt failed this unmap is removing some random DMA mapping that might still be required. If the PCI function now presents that IOVA, the IOMMU may assumes a rogue DMA access and e.g. on s390 puts the PCI function in error state. The erroneous behavior was seen in a stress-test environment that created memory pressure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50179", "url": "https://ubuntu.com/security/CVE-2024-50179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: remove the incorrect Fw reference check when dirtying pages When doing the direct-io reads it will also try to mark pages dirty, but for the read path it won't hold the Fw caps and there is case will it get the Fw reference.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49963", "url": "https://ubuntu.com/security/CVE-2024-49963", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mailbox: bcm2835: Fix timeout during suspend mode During noirq suspend phase the Raspberry Pi power driver suffer of firmware property timeouts. The reason is that the IRQ of the underlying BCM2835 mailbox is disabled and rpi_firmware_property_list() will always run into a timeout [1]. Since the VideoCore side isn't consider as a wakeup source, set the IRQF_NO_SUSPEND flag for the mailbox IRQ in order to keep it enabled during suspend-resume cycle. [1] PM: late suspend of devices complete after 1.754 msecs WARNING: CPU: 0 PID: 438 at drivers/firmware/raspberrypi.c:128 rpi_firmware_property_list+0x204/0x22c Firmware transaction 0x00028001 timeout Modules linked in: CPU: 0 PID: 438 Comm: bash Tainted: G C 6.9.3-dirty #17 Hardware name: BCM2835 Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x44 dump_stack_lvl from __warn+0x88/0xec __warn from warn_slowpath_fmt+0x7c/0xb0 warn_slowpath_fmt from rpi_firmware_property_list+0x204/0x22c rpi_firmware_property_list from rpi_firmware_property+0x68/0x8c rpi_firmware_property from rpi_firmware_set_power+0x54/0xc0 rpi_firmware_set_power from _genpd_power_off+0xe4/0x148 _genpd_power_off from genpd_sync_power_off+0x7c/0x11c genpd_sync_power_off from genpd_finish_suspend+0xcc/0xe0 genpd_finish_suspend from dpm_run_callback+0x78/0xd0 dpm_run_callback from device_suspend_noirq+0xc0/0x238 device_suspend_noirq from dpm_suspend_noirq+0xb0/0x168 dpm_suspend_noirq from suspend_devices_and_enter+0x1b8/0x5ac suspend_devices_and_enter from pm_suspend+0x254/0x2e4 pm_suspend from state_store+0xa8/0xd4 state_store from kernfs_fop_write_iter+0x154/0x1a0 kernfs_fop_write_iter from vfs_write+0x12c/0x184 vfs_write from ksys_write+0x78/0xc0 ksys_write from ret_fast_syscall+0x0/0x54 Exception stack(0xcc93dfa8 to 0xcc93dff0) [...] PM: noirq suspend of devices complete after 3095.584 msecs", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49954", "url": "https://ubuntu.com/security/CVE-2024-49954", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: static_call: Replace pointless WARN_ON() in static_call_module_notify() static_call_module_notify() triggers a WARN_ON(), when memory allocation fails in __static_call_add_module(). That's not really justified, because the failure case must be correctly handled by the well known call chain and the error code is passed through to the initiating userspace application. A memory allocation fail is not a fatal problem, but the WARN_ON() takes the machine out when panic_on_warn is set. Replace it with a pr_warn().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50002", "url": "https://ubuntu.com/security/CVE-2024-50002", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: static_call: Handle module init failure correctly in static_call_del_module() Module insertion invokes static_call_add_module() to initialize the static calls in a module. static_call_add_module() invokes __static_call_init(), which allocates a struct static_call_mod to either encapsulate the built-in static call sites of the associated key into it so further modules can be added or to append the module to the module chain. If that allocation fails the function returns with an error code and the module core invokes static_call_del_module() to clean up eventually added static_call_mod entries. This works correctly, when all keys used by the module were converted over to a module chain before the failure. If not then static_call_del_module() causes a #GP as it blindly assumes that key::mods points to a valid struct static_call_mod. The problem is that key::mods is not a individual struct member of struct static_call_key, it's part of a union to save space: union { /* bit 0: 0 = mods, 1 = sites */ unsigned long type; struct static_call_mod *mods; struct static_call_site *sites; \t}; key::sites is a pointer to the list of built-in usage sites of the static call. The type of the pointer is differentiated by bit 0. A mods pointer has the bit clear, the sites pointer has the bit set. As static_call_del_module() blidly assumes that the pointer is a valid static_call_mod type, it fails to check for this failure case and dereferences the pointer to the list of built-in call sites, which is obviously bogus. Cure it by checking whether the key has a sites or a mods pointer. If it's a sites pointer then the key is not to be touched. As the sites are walked in the same order as in __static_call_init() the site walk can be terminated because all subsequent sites have not been touched by the init code due to the error exit. If it was converted before the allocation fail, then the inner loop which searches for a module match will find nothing. A fail in the second allocation in __static_call_init() is harmless and does not require special treatment. The first allocation succeeded and converted the key to a module chain. That first entry has mod::mod == NULL and mod::next == NULL, so the inner loop of static_call_del_module() will neither find a module match nor a module chain. The next site in the walk was either already converted, but can't match the module, or it will exit the outer loop because it has a static_call_site pointer and not a static_call_mod pointer.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-47675", "url": "https://ubuntu.com/security/CVE-2024-47675", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix use-after-free in bpf_uprobe_multi_link_attach() If bpf_link_prime() fails, bpf_uprobe_multi_link_attach() goes to the error_free label and frees the array of bpf_uprobe's without calling bpf_uprobe_unregister(). This leaks bpf_uprobe->uprobe and worse, this frees bpf_uprobe->consumer without removing it from the uprobe->consumers list.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47676", "url": "https://ubuntu.com/security/CVE-2024-47676", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb.c: fix UAF of vma in hugetlb fault pathway Syzbot reports a UAF in hugetlb_fault(). This happens because vmf_anon_prepare() could drop the per-VMA lock and allow the current VMA to be freed before hugetlb_vma_unlock_read() is called. We can fix this by using a modified version of vmf_anon_prepare() that doesn't release the VMA lock on failure, and then release it ourselves after hugetlb_vma_unlock_read().", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47677", "url": "https://ubuntu.com/security/CVE-2024-47677", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: resolve memory leak from exfat_create_upcase_table() If exfat_load_upcase_table reaches end and returns -EINVAL, allocated memory doesn't get freed and while exfat_load_default_upcase_table allocates more memory, leading to a memory leak. Here's link to syzkaller crash report illustrating this issue: https://syzkaller.appspot.com/text?tag=CrashReport&x=1406c201980000", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47725", "url": "https://ubuntu.com/security/CVE-2024-47725", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47739", "url": "https://ubuntu.com/security/CVE-2024-47739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: padata: use integer wrap around to prevent deadlock on seq_nr overflow When submitting more than 2^32 padata objects to padata_do_serial, the current sorting implementation incorrectly sorts padata objects with overflowed seq_nr, causing them to be placed before existing objects in the reorder list. This leads to a deadlock in the serialization process as padata_find_next cannot match padata->seq_nr and pd->processed because the padata instance with overflowed seq_nr will be selected next. To fix this, we use an unsigned integer wrap around to correctly sort padata objects in scenarios with integer overflow.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47678", "url": "https://ubuntu.com/security/CVE-2024-47678", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: icmp: change the order of rate limits ICMP messages are ratelimited : After the blamed commits, the two rate limiters are applied in this order: 1) host wide ratelimit (icmp_global_allow()) 2) Per destination ratelimit (inetpeer based) In order to avoid side-channels attacks, we need to apply the per destination check first. This patch makes the following change : 1) icmp_global_allow() checks if the host wide limit is reached. But credits are not yet consumed. This is deferred to 3) 2) The per destination limit is checked/updated. This might add a new node in inetpeer tree. 3) icmp_global_consume() consumes tokens if prior operations succeeded. This means that host wide ratelimit is still effective in keeping inetpeer tree small even under DDOS. As a bonus, I removed icmp_global.lock as the fast path can use a lock-free operation.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47733", "url": "https://ubuntu.com/security/CVE-2024-47733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfs: Delete subtree of 'fs/netfs' when netfs module exits In netfs_init() or fscache_proc_init(), we create dentry under 'fs/netfs', but in netfs_exit(), we only delete the proc entry of 'fs/netfs' without deleting its subtree. This triggers the following WARNING: ================================================================== remove_proc_entry: removing non-empty directory 'fs/netfs', leaking at least 'requests' WARNING: CPU: 4 PID: 566 at fs/proc/generic.c:717 remove_proc_entry+0x160/0x1c0 Modules linked in: netfs(-) CPU: 4 UID: 0 PID: 566 Comm: rmmod Not tainted 6.11.0-rc3 #860 RIP: 0010:remove_proc_entry+0x160/0x1c0 Call Trace: netfs_exit+0x12/0x620 [netfs] __do_sys_delete_module.isra.0+0x14c/0x2e0 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e ================================================================== Therefore use remove_proc_subtree() instead of remove_proc_entry() to fix the above problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47679", "url": "https://ubuntu.com/security/CVE-2024-47679", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfs: fix race between evice_inodes() and find_inode()&iput() Hi, all Recently I noticed a bug[1] in btrfs, after digged it into and I believe it'a race in vfs. Let's assume there's a inode (ie ino 261) with i_count 1 is called by iput(), and there's a concurrent thread calling generic_shutdown_super(). cpu0: cpu1: iput() // i_count is 1 ->spin_lock(inode) ->dec i_count to 0 ->iput_final() generic_shutdown_super() ->__inode_add_lru() ->evict_inodes() // cause some reason[2] ->if (atomic_read(inode->i_count)) continue; // return before // inode 261 passed the above check // list_lru_add_obj() // and then schedule out ->spin_unlock() // note here: the inode 261 // was still at sb list and hash list, // and I_FREEING|I_WILL_FREE was not been set btrfs_iget() // after some function calls ->find_inode() // found the above inode 261 ->spin_lock(inode) // check I_FREEING|I_WILL_FREE // and passed ->__iget() ->spin_unlock(inode) // schedule back ->spin_lock(inode) // check (I_NEW|I_FREEING|I_WILL_FREE) flags, // passed and set I_FREEING iput() ->spin_unlock(inode) ->spin_lock(inode)\t\t\t ->evict() // dec i_count to 0 ->iput_final() ->spin_unlock() ->evict() Now, we have two threads simultaneously evicting the same inode, which may trigger the BUG(inode->i_state & I_CLEAR) statement both within clear_inode() and iput(). To fix the bug, recheck the inode->i_count after holding i_lock. Because in the most scenarios, the first check is valid, and the overhead of spin_lock() can be reduced. If there is any misunderstanding, please let me know, thanks. [1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/ [2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable() return false when I reproduced the bug.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49859", "url": "https://ubuntu.com/security/CVE-2024-49859", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to check atomic_file in f2fs ioctl interfaces Some f2fs ioctl interfaces like f2fs_ioc_set_pin_file(), f2fs_move_file_range(), and f2fs_defragment_range() missed to check atomic_write status, which may cause potential race issue, fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47680", "url": "https://ubuntu.com/security/CVE-2024-47680", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: check discard support for conventional zones As the helper function f2fs_bdev_support_discard() shows, f2fs checks if the target block devices support discard by calling bdev_max_discard_sectors() and bdev_is_zoned(). This check works well for most cases, but it does not work for conventional zones on zoned block devices. F2fs assumes that zoned block devices support discard, and calls __submit_discard_cmd(). When __submit_discard_cmd() is called for sequential write required zones, it works fine since __submit_discard_cmd() issues zone reset commands instead of discard commands. However, when __submit_discard_cmd() is called for conventional zones, __blkdev_issue_discard() is called even when the devices do not support discard. The inappropriate __blkdev_issue_discard() call was not a problem before the commit 30f1e7241422 (\"block: move discard checks into the ioctl handler\") because __blkdev_issue_discard() checked if the target devices support discard or not. If not, it returned EOPNOTSUPP. After the commit, __blkdev_issue_discard() no longer checks it. It always returns zero and sets NULL to the given bio pointer. This NULL pointer triggers f2fs_bug_on() in __submit_discard_cmd(). The BUG is recreated with the commands below at the umount step, where /dev/nullb0 is a zoned null_blk with 5GB total size, 128MB zone size and 10 conventional zones. $ mkfs.f2fs -f -m /dev/nullb0 $ mount /dev/nullb0 /mnt $ for ((i=0;i<5;i++)); do dd if=/dev/zero of=/mnt/test bs=65536 count=1600 conv=fsync; done $ umount /mnt To fix the BUG, avoid the inappropriate __blkdev_issue_discard() call. When discard is requested for conventional zones, check if the device supports discard or not. If not, return EOPNOTSUPP.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47740", "url": "https://ubuntu.com/security/CVE-2024-47740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: Require FMODE_WRITE for atomic write ioctls The F2FS ioctls for starting and committing atomic writes check for inode_owner_or_capable(), but this does not give LSMs like SELinux or Landlock an opportunity to deny the write access - if the caller's FSUID matches the inode's UID, inode_owner_or_capable() immediately returns true. There are scenarios where LSMs want to deny a process the ability to write particular files, even files that the FSUID of the process owns; but this can currently partially be bypassed using atomic write ioctls in two ways: - F2FS_IOC_START_ATOMIC_REPLACE + F2FS_IOC_COMMIT_ATOMIC_WRITE can truncate an inode to size 0 - F2FS_IOC_START_ATOMIC_WRITE + F2FS_IOC_ABORT_ATOMIC_WRITE can revert changes another process concurrently made to a file Fix it by requiring FMODE_WRITE for these operations, just like for F2FS_IOC_MOVE_RANGE. Since any legitimate caller should only be using these ioctls when intending to write into the file, that seems unlikely to break anything.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47726", "url": "https://ubuntu.com/security/CVE-2024-47726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to wait dio completion It should wait all existing dio write IOs before block removal, otherwise, previous direct write IO may overwrite data in the block which may be reused by other inode.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47741", "url": "https://ubuntu.com/security/CVE-2024-47741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race setting file private on concurrent lseek using same fd When doing concurrent lseek(2) system calls against the same file descriptor, using multiple threads belonging to the same process, we have a short time window where a race happens and can result in a memory leak. The race happens like this: 1) A program opens a file descriptor for a file and then spawns two threads (with the pthreads library for example), lets call them task A and task B; 2) Task A calls lseek with SEEK_DATA or SEEK_HOLE and ends up at file.c:find_desired_extent() while holding a read lock on the inode; 3) At the start of find_desired_extent(), it extracts the file's private_data pointer into a local variable named 'private', which has a value of NULL; 4) Task B also calls lseek with SEEK_DATA or SEEK_HOLE, locks the inode in shared mode and enters file.c:find_desired_extent(), where it also extracts file->private_data into its local variable 'private', which has a NULL value; 5) Because it saw a NULL file private, task A allocates a private structure and assigns to the file structure; 6) Task B also saw a NULL file private so it also allocates its own file private and then assigns it to the same file structure, since both tasks are using the same file descriptor. At this point we leak the private structure allocated by task A. Besides the memory leak, there's also the detail that both tasks end up using the same cached state record in the private structure (struct btrfs_file_private::llseek_cached_state), which can result in a use-after-free problem since one task can free it while the other is still using it (only one task took a reference count on it). Also, sharing the cached state is not a good idea since it could result in incorrect results in the future - right now it should not be a problem because it end ups being used only in extent-io-tree.c:count_range_bits() where we do range validation before using the cached state. Fix this by protecting the private assignment and check of a file while holding the inode's spinlock and keep track of the task that allocated the private, so that it's used only by that task in order to prevent user-after-free issues with the cached state record as well as potentially using it incorrectly in the future.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47681", "url": "https://ubuntu.com/security/CVE-2024-47681", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix NULL pointer dereference in mt7996_mcu_sta_bfer_he Fix the NULL pointer dereference in mt7996_mcu_sta_bfer_he routine adding an sta interface to the mt7996 driver. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49858", "url": "https://ubuntu.com/security/CVE-2024-49858", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption The TPM event log table is a Linux specific construct, where the data produced by the GetEventLog() boot service is cached in memory, and passed on to the OS using an EFI configuration table. The use of EFI_LOADER_DATA here results in the region being left unreserved in the E820 memory map constructed by the EFI stub, and this is the memory description that is passed on to the incoming kernel by kexec, which is therefore unaware that the region should be reserved. Even though the utility of the TPM2 event log after a kexec is questionable, any corruption might send the parsing code off into the weeds and crash the kernel. So let's use EFI_ACPI_RECLAIM_MEMORY instead, which is always treated as reserved by the E820 conversion logic.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49860", "url": "https://ubuntu.com/security/CVE-2024-49860", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: sysfs: validate return type of _STR method Only buffer objects are valid return values of _STR. If something else is returned description_show() will access invalid memory.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47742", "url": "https://ubuntu.com/security/CVE-2024-47742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware_loader: Block path traversal Most firmware names are hardcoded strings, or are constructed from fairly constrained format strings where the dynamic parts are just some hex numbers or such. However, there are a couple codepaths in the kernel where firmware file names contain string components that are passed through from a device or semi-privileged userspace; the ones I could find (not counting interfaces that require root privileges) are: - lpfc_sli4_request_firmware_update() seems to construct the firmware filename from \"ModelName\", a string that was previously parsed out of some descriptor (\"Vital Product Data\") in lpfc_fill_vpd() - nfp_net_fw_find() seems to construct a firmware filename from a model name coming from nfp_hwinfo_lookup(pf->hwinfo, \"nffw.partno\"), which I think parses some descriptor that was read from the device. (But this case likely isn't exploitable because the format string looks like \"netronome/nic_%s\", and there shouldn't be any *folders* starting with \"netronome/nic_\". The previous case was different because there, the \"%s\" is *at the start* of the format string.) - module_flash_fw_schedule() is reachable from the ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is enough to pass the privilege check), and takes a userspace-provided firmware name. (But I think to reach this case, you need to have CAP_NET_ADMIN over a network namespace that a special kind of ethernet device is mapped into, so I think this is not a viable attack path in practice.) Fix it by rejecting any firmware names containing \"..\" path components. For what it's worth, I went looking and haven't found any USB device drivers that use the firmware loader dangerously.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47682", "url": "https://ubuntu.com/security/CVE-2024-47682", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sd: Fix off-by-one error in sd_read_block_characteristics() Ff the device returns page 0xb1 with length 8 (happens with qemu v2.x, for example), sd_read_block_characteristics() may attempt an out-of-bounds memory access when accessing the zoned field at offset 8.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47743", "url": "https://ubuntu.com/security/CVE-2024-47743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: prevent NULL pointer dereference in find_asymmetric_key() In find_asymmetric_key(), if all NULLs are passed in the id_{0,1,2} arguments, the kernel will first emit WARN but then have an oops because id_2 gets dereferenced anyway. Add the missing id_2 check and move WARN_ON() to the final else branch to avoid duplicate NULL checks. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47727", "url": "https://ubuntu.com/security/CVE-2024-47727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/tdx: Fix \"in-kernel MMIO\" check TDX only supports kernel-initiated MMIO operations. The handle_mmio() function checks if the #VE exception occurred in the kernel and rejects the operation if it did not. However, userspace can deceive the kernel into performing MMIO on its behalf. For example, if userspace can point a syscall to an MMIO address, syscall does get_user() or put_user() on it, triggering MMIO #VE. The kernel will treat the #VE as in-kernel MMIO. Ensure that the target MMIO address is within the kernel before decoding instruction.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47744", "url": "https://ubuntu.com/security/CVE-2024-47744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Use dedicated mutex to protect kvm_usage_count to avoid deadlock Use a dedicated mutex to guard kvm_usage_count to fix a potential deadlock on x86 due to a chain of locks and SRCU synchronizations. Translating the below lockdep splat, CPU1 #6 will wait on CPU0 #1, CPU0 #8 will wait on CPU2 #3, and CPU2 #7 will wait on CPU1 #4 (if there's a writer, due to the fairness of r/w semaphores). CPU0 CPU1 CPU2 1 lock(&kvm->slots_lock); 2 lock(&vcpu->mutex); 3 lock(&kvm->srcu); 4 lock(cpu_hotplug_lock); 5 lock(kvm_lock); 6 lock(&kvm->slots_lock); 7 lock(cpu_hotplug_lock); 8 sync(&kvm->srcu); Note, there are likely more potential deadlocks in KVM x86, e.g. the same pattern of taking cpu_hotplug_lock outside of kvm_lock likely exists with __kvmclock_cpufreq_notifier(): cpuhp_cpufreq_online() | -> cpufreq_online() | -> cpufreq_gov_performance_limits() | -> __cpufreq_driver_target() | -> __target_index() | -> cpufreq_freq_transition_begin() | -> cpufreq_notify_transition() | -> ... __kvmclock_cpufreq_notifier() But, actually triggering such deadlocks is beyond rare due to the combination of dependencies and timings involved. E.g. the cpufreq notifier is only used on older CPUs without a constant TSC, mucking with the NX hugepage mitigation while VMs are running is very uncommon, and doing so while also onlining/offlining a CPU (necessary to generate contention on cpu_hotplug_lock) would be even more unusual. The most robust solution to the general cpu_hotplug_lock issue is likely to switch vm_list to be an RCU-protected list, e.g. so that x86's cpufreq notifier doesn't to take kvm_lock. For now, settle for fixing the most blatant deadlock, as switching to an RCU-protected list is a much more involved change, but add a comment in locking.rst to call out that care needs to be taken when walking holding kvm_lock and walking vm_list. ====================================================== WARNING: possible circular locking dependency detected 6.10.0-smp--c257535a0c9d-pip #330 Tainted: G S O ------------------------------------------------------ tee/35048 is trying to acquire lock: ff6a80eced71e0a8 (&kvm->slots_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x179/0x1e0 [kvm] but task is already holding lock: ffffffffc07abb08 (kvm_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x14a/0x1e0 [kvm] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (kvm_lock){+.+.}-{3:3}: __mutex_lock+0x6a/0xb40 mutex_lock_nested+0x1f/0x30 kvm_dev_ioctl+0x4fb/0xe50 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #2 (cpu_hotplug_lock){++++}-{0:0}: cpus_read_lock+0x2e/0xb0 static_key_slow_inc+0x16/0x30 kvm_lapic_set_base+0x6a/0x1c0 [kvm] kvm_set_apic_base+0x8f/0xe0 [kvm] kvm_set_msr_common+0x9ae/0xf80 [kvm] vmx_set_msr+0xa54/0xbe0 [kvm_intel] __kvm_set_msr+0xb6/0x1a0 [kvm] kvm_arch_vcpu_ioctl+0xeca/0x10c0 [kvm] kvm_vcpu_ioctl+0x485/0x5b0 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (&kvm->srcu){.+.+}-{0:0}: __synchronize_srcu+0x44/0x1a0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47719", "url": "https://ubuntu.com/security/CVE-2024-47719", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommufd: Protect against overflow of ALIGN() during iova allocation Userspace can supply an iova and uptr such that the target iova alignment becomes really big and ALIGN() overflows which corrupts the selected area range during allocation. CONFIG_IOMMUFD_TEST can detect this: WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline] WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352 Modules linked in: CPU: 1 PID: 5092 Comm: syz-executor294 Not tainted 6.10.0-rc5-syzkaller-00294-g3ffea9a7a6f7 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024 RIP: 0010:iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline] RIP: 0010:iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352 Code: fc e9 a4 f3 ff ff e8 1a 8b 4c fc 41 be e4 ff ff ff e9 8a f3 ff ff e8 0a 8b 4c fc 90 0f 0b 90 e9 37 f5 ff ff e8 fc 8a 4c fc 90 <0f> 0b 90 e9 68 f3 ff ff 48 c7 c1 ec 82 ad 8f 80 e1 07 80 c1 03 38 RSP: 0018:ffffc90003ebf9e0 EFLAGS: 00010293 RAX: ffffffff85499fa4 RBX: 00000000ffffffef RCX: ffff888079b49e00 RDX: 0000000000000000 RSI: 00000000ffffffef RDI: 0000000000000000 RBP: ffffc90003ebfc50 R08: ffffffff85499b30 R09: ffffffff85499942 R10: 0000000000000002 R11: ffff888079b49e00 R12: ffff8880228e0010 R13: 0000000000000000 R14: 1ffff920007d7f68 R15: ffffc90003ebfd00 FS: 000055557d760380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000005fdeb8 CR3: 000000007404a000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: iommufd_ioas_copy+0x610/0x7b0 drivers/iommu/iommufd/ioas.c:274 iommufd_fops_ioctl+0x4d9/0x5a0 drivers/iommu/iommufd/main.c:421 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Cap the automatic alignment to the huge page size, which is probably a better idea overall. Huge automatic alignments can fragment and chew up the available IOVA space without any reason.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47745", "url": "https://ubuntu.com/security/CVE-2024-47745", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: call the security_mmap_file() LSM hook in remap_file_pages() The remap_file_pages syscall handler calls do_mmap() directly, which doesn't contain the LSM security check. And if the process has called personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for RW pages, this will actually result in remapping the pages to RWX, bypassing a W^X policy enforced by SELinux. So we should check prot by security_mmap_file LSM hook in the remap_file_pages syscall handler before do_mmap() is called. Otherwise, it potentially permits an attacker to bypass a W^X policy enforced by SELinux. The bypass is similar to CVE-2016-10044, which bypass the same thing via AIO and can be found in [1]. The PoC: $ cat > test.c int main(void) { \tsize_t pagesz = sysconf(_SC_PAGE_SIZE); \tint mfd = syscall(SYS_memfd_create, \"test\", 0); \tconst char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE, \t\tMAP_SHARED, mfd, 0); \tunsigned int old = syscall(SYS_personality, 0xffffffff); \tsyscall(SYS_personality, READ_IMPLIES_EXEC | old); \tsyscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0); \tsyscall(SYS_personality, old); \t// show the RWX page exists even if W^X policy is enforced \tint fd = open(\"/proc/self/maps\", O_RDONLY); \tunsigned char buf2[1024]; \twhile (1) { \t\tint ret = read(fd, buf2, 1024); \t\tif (ret <= 0) break; \t\twrite(1, buf2, ret); \t} \tclose(fd); } $ gcc test.c -o test $ ./test | grep rwx 7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted) [PM: subject line tweaks]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47746", "url": "https://ubuntu.com/security/CVE-2024-47746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: use exclusive lock when FUSE_I_CACHE_IO_MODE is set This may be a typo. The comment has said shared locks are not allowed when this bit is set. If using shared lock, the wait in `fuse_file_cached_io_open` may be forever.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47734", "url": "https://ubuntu.com/security/CVE-2024-47734", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: Fix unnecessary warnings and logs from bond_xdp_get_xmit_slave() syzbot reported a WARNING in bond_xdp_get_xmit_slave. To reproduce this[1], one bond device (bond1) has xdpdrv, which increases bpf_master_redirect_enabled_key. Another bond device (bond0) which is unsupported by XDP but its slave (veth3) has xdpgeneric that returns XDP_TX. This triggers WARN_ON_ONCE() from the xdp_master_redirect(). To reduce unnecessary warnings and improve log management, we need to delete the WARN_ON_ONCE() and add ratelimit to the netdev_err(). [1] Steps to reproduce: # Needs tx_xdp with return XDP_TX; ip l add veth0 type veth peer veth1 ip l add veth3 type veth peer veth4 ip l add bond0 type bond mode 6 # BOND_MODE_ALB, unsupported by XDP ip l add bond1 type bond # BOND_MODE_ROUNDROBIN by default ip l set veth0 master bond1 ip l set bond1 up # Increases bpf_master_redirect_enabled_key ip l set dev bond1 xdpdrv object tx_xdp.o section xdp_tx ip l set veth3 master bond0 ip l set bond0 up ip l set veth4 up # Triggers WARN_ON_ONCE() from the xdp_master_redirect() ip l set veth3 xdpgeneric object tx_xdp.o section xdp_tx", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47684", "url": "https://ubuntu.com/security/CVE-2024-47684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: check skb is non-NULL in tcp_rto_delta_us() We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic kernel that are running ceph and recently hit a null ptr dereference in tcp_rearm_rto(). Initially hitting it from the TLP path, but then later we also saw it getting hit from the RACK case as well. Here are examples of the oops messages we saw in each of those cases: Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020 Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode Jul 26 15:05:02 rx [11061395.792971] #PF: error_code(0x0000) - not-present page Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0 Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI Jul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu Jul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023 Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 <48> 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3 Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246 Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000 Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60 Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8 Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900 Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30 Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000 Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0 Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554 Jul 26 15:05:02 rx [11061395.916786] Call Trace: Jul 26 15:05:02 rx [11061395.919488] Jul 26 15:05:02 rx [11061395.921765] ? show_regs.cold+0x1a/0x1f Jul 26 15:05:02 rx [11061395.925859] ? __die+0x90/0xd9 Jul 26 15:05:02 rx [11061395.929169] ? no_context+0x196/0x380 Jul 26 15:05:02 rx [11061395.933088] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0 Jul 26 15:05:02 rx [11061395.938216] ? ip6_sublist_rcv_finish+0x3d/0x50 Jul 26 15:05:02 rx [11061395.943000] ? __bad_area_nosemaphore+0x50/0x1a0 Jul 26 15:05:02 rx [11061395.947873] ? bad_area_nosemaphore+0x16/0x20 Jul 26 15:05:02 rx [11061395.952486] ? do_user_addr_fault+0x267/0x450 Jul 26 15:05:02 rx [11061395.957104] ? ipv6_list_rcv+0x112/0x140 Jul 26 15:05:02 rx [11061395.961279] ? __do_page_fault+0x58/0x90 Jul 26 15:05:02 rx [11061395.965458] ? do_page_fault+0x2c/0xe0 Jul 26 15:05:02 rx [11061395.969465] ? page_fault+0x34/0x40 Jul 26 15:05:02 rx [11061395.973217] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.977313] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.981408] tcp_send_loss_probe+0x10b/0x220 Jul 26 15:05:02 rx [11061395.985937] tcp_write_timer_handler+0x1b4/0x240 Jul 26 15:05:02 rx [11061395.990809] tcp_write_timer+0x9e/0xe0 Jul 26 15:05:02 rx [11061395.994814] ? tcp_write_timer_handler+0x240/0x240 Jul 26 15:05:02 rx [11061395.999866] call_timer_fn+0x32/0x130 Jul 26 15:05:02 rx [11061396.003782] __run_timers.part.0+0x180/0x280 Jul 26 15:05:02 rx [11061396.008309] ? recalibrate_cpu_khz+0x10/0x10 Jul 26 15:05:02 rx [11061396.012841] ? native_x2apic_icr_write+0x30/0x30 Jul 26 15:05:02 rx [11061396.017718] ? lapic_next_even ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47747", "url": "https://ubuntu.com/security/CVE-2024-47747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race Condition In the ether3_probe function, a timer is initialized with a callback function ether3_ledoff, bound to &prev(dev)->timer. Once the timer is started, there is a risk of a race condition if the module or device is removed, triggering the ether3_remove function to perform cleanup. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | ether3_ledoff ether3_remove | free_netdev(dev); | put_devic | kfree(dev); | | ether3_outw(priv(dev)->regs.config2 |= CFG2_CTRLO, REG_CONFIG2); | // use dev Fix it by ensuring that the timer is canceled before proceeding with the cleanup in ether3_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47685", "url": "https://ubuntu.com/security/CVE-2024-47685", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put() syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending garbage on the four reserved tcp bits (th->res1) Use skb_put_zero() to clear the whole TCP header, as done in nf_reject_ip_tcphdr_put() BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5661 [inline] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775 process_backlog+0x4ad/0xa50 net/core/dev.c:6108 __napi_poll+0xe7/0x980 net/core/dev.c:6772 napi_poll net/core/dev.c:6841 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963 handle_softirqs+0x1ce/0x800 kernel/softirq.c:554 __do_softirq+0x14/0x1a kernel/softirq.c:588 do_softirq+0x9a/0x100 kernel/softirq.c:455 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline] __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450 dev_queue_xmit include/linux/netdevice.h:3105 [inline] neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366 inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135 __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143 tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333 __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679 inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750 __sys_connect_file net/socket.c:2061 [inline] __sys_connect+0x606/0x690 net/socket.c:2078 __do_sys_connect net/socket.c:2088 [inline] __se_sys_connect net/socket.c:2085 [inline] __x64_sys_connect+0x91/0xe0 net/socket.c:2085 x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43 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 Uninit was stored to memory at: nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47686", "url": "https://ubuntu.com/security/CVE-2024-47686", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ep93xx: clock: Fix off by one in ep93xx_div_recalc_rate() The psc->div[] array has psc->num_div elements. These values come from when we call clk_hw_register_div(). It's adc_divisors and ARRAY_SIZE(adc_divisors)) and so on. So this condition needs to be >= instead of > to prevent an out of bounds read.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47748", "url": "https://ubuntu.com/security/CVE-2024-47748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost_vdpa: assign irq bypass producer token correctly We used to call irq_bypass_unregister_producer() in vhost_vdpa_setup_vq_irq() which is problematic as we don't know if the token pointer is still valid or not. Actually, we use the eventfd_ctx as the token so the life cycle of the token should be bound to the VHOST_SET_VRING_CALL instead of vhost_vdpa_setup_vq_irq() which could be called by set_status(). Fixing this by setting up irq bypass producer's token when handling VHOST_SET_VRING_CALL and un-registering the producer before calling vhost_vring_ioctl() to prevent a possible use after free as eventfd could have been released in vhost_vring_ioctl(). And such registering and unregistering will only be done if DRIVER_OK is set.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47687", "url": "https://ubuntu.com/security/CVE-2024-47687", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa/mlx5: Fix invalid mr resource destroy Certain error paths from mlx5_vdpa_dev_add() can end up releasing mr resources which never got initialized in the first place. This patch adds the missing check in mlx5_vdpa_destroy_mr_resources() to block releasing non-initialized mr resources. Reference trace: mlx5_core 0000:08:00.2: mlx5_vdpa_dev_add:3274:(pid 2700) warning: No mac address provisioned? BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 140216067 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 8 PID: 2700 Comm: vdpa Kdump: loaded Not tainted 5.14.0-496.el9.x86_64 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:vhost_iotlb_del_range+0xf/0xe0 [vhost_iotlb] Code: [...] RSP: 0018:ff1c823ac23077f0 EFLAGS: 00010246 RAX: ffffffffc1a21a60 RBX: ffffffff899567a0 RCX: 0000000000000000 RDX: ffffffffffffffff RSI: 0000000000000000 RDI: 0000000000000000 RBP: ff1bda1f7c21e800 R08: 0000000000000000 R09: ff1c823ac2307670 R10: ff1c823ac2307668 R11: ffffffff8a9e7b68 R12: 0000000000000000 R13: 0000000000000000 R14: ff1bda1f43e341a0 R15: 00000000ffffffea FS: 00007f56eba7c740(0000) GS:ff1bda269f800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000104d90001 CR4: 0000000000771ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? mlx5_vdpa_free+0x3d/0x150 [mlx5_vdpa] ? __die_body.cold+0x8/0xd ? page_fault_oops+0x134/0x170 ? __irq_work_queue_local+0x2b/0xc0 ? irq_work_queue+0x2c/0x50 ? exc_page_fault+0x62/0x150 ? asm_exc_page_fault+0x22/0x30 ? __pfx_mlx5_vdpa_free+0x10/0x10 [mlx5_vdpa] ? vhost_iotlb_del_range+0xf/0xe0 [vhost_iotlb] mlx5_vdpa_free+0x3d/0x150 [mlx5_vdpa] vdpa_release_dev+0x1e/0x50 [vdpa] device_release+0x31/0x90 kobject_cleanup+0x37/0x130 mlx5_vdpa_dev_add+0x2d2/0x7a0 [mlx5_vdpa] vdpa_nl_cmd_dev_add_set_doit+0x277/0x4c0 [vdpa] genl_family_rcv_msg_doit+0xd9/0x130 genl_family_rcv_msg+0x14d/0x220 ? __pfx_vdpa_nl_cmd_dev_add_set_doit+0x10/0x10 [vdpa] ? _copy_to_user+0x1a/0x30 ? move_addr_to_user+0x4b/0xe0 genl_rcv_msg+0x47/0xa0 ? __import_iovec+0x46/0x150 ? __pfx_genl_rcv_msg+0x10/0x10 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x245/0x370 netlink_sendmsg+0x206/0x440 __sys_sendto+0x1dc/0x1f0 ? do_read_fault+0x10c/0x1d0 ? do_pte_missing+0x10d/0x190 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x5c/0xf0 ? __count_memcg_events+0x4f/0xb0 ? mm_account_fault+0x6c/0x100 ? handle_mm_fault+0x116/0x270 ? do_user_addr_fault+0x1d6/0x6a0 ? do_syscall_64+0x6b/0xf0 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 entry_SYSCALL_64_after_hwframe+0x78/0x80", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47688", "url": "https://ubuntu.com/security/CVE-2024-47688", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: driver core: Fix a potential null-ptr-deref in module_add_driver() Inject fault while probing of-fpga-region, if kasprintf() fails in module_add_driver(), the second sysfs_remove_link() in exit path will cause null-ptr-deref as below because kernfs_name_hash() will call strlen() with NULL driver_name. Fix it by releasing resources based on the exit path sequence. \t KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] \t Mem abort info: \t ESR = 0x0000000096000005 \t EC = 0x25: DABT (current EL), IL = 32 bits \t SET = 0, FnV = 0 \t EA = 0, S1PTW = 0 \t FSC = 0x05: level 1 translation fault \t Data abort info: \t ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 \t CM = 0, WnR = 0, TnD = 0, TagAccess = 0 \t GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 \t [dfffffc000000000] address between user and kernel address ranges \t Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP \t Dumping ftrace buffer: \t (ftrace buffer empty) \t Modules linked in: of_fpga_region(+) fpga_region fpga_bridge cfg80211 rfkill 8021q garp mrp stp llc ipv6 [last unloaded: of_fpga_region] \t CPU: 2 UID: 0 PID: 2036 Comm: modprobe Not tainted 6.11.0-rc2-g6a0e38264012 #295 \t Hardware name: linux,dummy-virt (DT) \t pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) \t pc : strlen+0x24/0xb0 \t lr : kernfs_name_hash+0x1c/0xc4 \t sp : ffffffc081f97380 \t x29: ffffffc081f97380 x28: ffffffc081f97b90 x27: ffffff80c821c2a0 \t x26: ffffffedac0be418 x25: 0000000000000000 x24: ffffff80c09d2000 \t x23: 0000000000000000 x22: 0000000000000000 x21: 0000000000000000 \t x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000001840 \t x17: 0000000000000000 x16: 0000000000000000 x15: 1ffffff8103f2e42 \t x14: 00000000f1f1f1f1 x13: 0000000000000004 x12: ffffffb01812d61d \t x11: 1ffffff01812d61c x10: ffffffb01812d61c x9 : dfffffc000000000 \t x8 : 0000004fe7ed29e4 x7 : ffffff80c096b0e7 x6 : 0000000000000001 \t x5 : ffffff80c096b0e0 x4 : 1ffffffdb990efa2 x3 : 0000000000000000 \t x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000000 \t Call trace: \t strlen+0x24/0xb0 \t kernfs_name_hash+0x1c/0xc4 \t kernfs_find_ns+0x118/0x2e8 \t kernfs_remove_by_name_ns+0x80/0x100 \t sysfs_remove_link+0x74/0xa8 \t module_add_driver+0x278/0x394 \t bus_add_driver+0x1f0/0x43c \t driver_register+0xf4/0x3c0 \t __platform_driver_register+0x60/0x88 \t of_fpga_region_init+0x20/0x1000 [of_fpga_region] \t do_one_initcall+0x110/0x788 \t do_init_module+0x1dc/0x5c8 \t load_module+0x3c38/0x4cac \t init_module_from_file+0xd4/0x128 \t idempotent_init_module+0x2cc/0x528 \t __arm64_sys_finit_module+0xac/0x100 \t invoke_syscall+0x6c/0x258 \t el0_svc_common.constprop.0+0x160/0x22c \t do_el0_svc+0x44/0x5c \t el0_svc+0x48/0xb8 \t el0t_64_sync_handler+0x13c/0x158 \t el0t_64_sync+0x190/0x194 \t Code: f2fbffe1 a90157f4 12000802 aa0003f5 (38e16861) \t ---[ end trace 0000000000000000 ]--- \t Kernel panic - not syncing: Oops: Fatal exception", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47689", "url": "https://ubuntu.com/security/CVE-2024-47689", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to don't set SB_RDONLY in f2fs_handle_critical_error() syzbot reports a f2fs bug as below: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 58 at kernel/rcu/sync.c:177 rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177 CPU: 1 UID: 0 PID: 58 Comm: kworker/1:2 Not tainted 6.10.0-syzkaller-12562-g1722389b0d86 #0 Workqueue: events destroy_super_work RIP: 0010:rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177 Call Trace: percpu_free_rwsem+0x41/0x80 kernel/locking/percpu-rwsem.c:42 destroy_super_work+0xec/0x130 fs/super.c:282 process_one_work kernel/workqueue.c:3231 [inline] process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 worker_thread+0x86d/0xd40 kernel/workqueue.c:3390 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 As Christian Brauner pointed out [1]: the root cause is f2fs sets SB_RDONLY flag in internal function, rather than setting the flag covered w/ sb->s_umount semaphore via remount procedure, then below race condition causes this bug: - freeze_super() - sb_wait_write(sb, SB_FREEZE_WRITE) - sb_wait_write(sb, SB_FREEZE_PAGEFAULT) - sb_wait_write(sb, SB_FREEZE_FS) \t\t\t\t\t- f2fs_handle_critical_error \t\t\t\t\t - sb->s_flags |= SB_RDONLY - thaw_super - thaw_super_locked - sb_rdonly() is true, so it skips sb_freeze_unlock(sb, SB_FREEZE_FS) - deactivate_locked_super Since f2fs has almost the same logic as ext4 [2] when handling critical error in filesystem if it mounts w/ errors=remount-ro option: - set CP_ERROR_FLAG flag which indicates filesystem is stopped - record errors to superblock - set SB_RDONLY falg Once we set CP_ERROR_FLAG flag, all writable interfaces can detect the flag and stop any further updates on filesystem. So, it is safe to not set SB_RDONLY flag, let's remove the logic and keep in line w/ ext4 [3]. [1] https://lore.kernel.org/all/20240729-himbeeren-funknetz-96e62f9c7aee@brauner [2] https://lore.kernel.org/all/20240729132721.hxih6ehigadqf7wx@quack3 [3] https://lore.kernel.org/linux-ext4/20240805201241.27286-1-jack@suse.cz", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47690", "url": "https://ubuntu.com/security/CVE-2024-47690", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: get rid of online repaire on corrupted directory syzbot reports a f2fs bug as below: kernel BUG at fs/f2fs/inode.c:896! RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Call Trace: evict+0x532/0x950 fs/inode.c:704 dispose_list fs/inode.c:747 [inline] evict_inodes+0x5f9/0x690 fs/inode.c:797 generic_shutdown_super+0x9d/0x2d0 fs/super.c:627 kill_block_super+0x44/0x90 fs/super.c:1696 kill_f2fs_super+0x344/0x690 fs/f2fs/super.c:4898 deactivate_locked_super+0xc4/0x130 fs/super.c:473 cleanup_mnt+0x41f/0x4b0 fs/namespace.c:1373 task_work_run+0x24f/0x310 kernel/task_work.c:228 ptrace_notify+0x2d2/0x380 kernel/signal.c:2402 ptrace_report_syscall include/linux/ptrace.h:415 [inline] ptrace_report_syscall_exit include/linux/ptrace.h:477 [inline] syscall_exit_work+0xc6/0x190 kernel/entry/common.c:173 syscall_exit_to_user_mode_prepare kernel/entry/common.c:200 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:205 [inline] syscall_exit_to_user_mode+0x279/0x370 kernel/entry/common.c:218 do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Online repaire on corrupted directory in f2fs_lookup() can generate dirty data/meta while racing w/ readonly remount, it may leave dirty inode after filesystem becomes readonly, however, checkpoint() will skips flushing dirty inode in a state of readonly mode, result in above panic. Let's get rid of online repaire in f2fs_lookup(), and leave the work to fsck.f2fs.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47691", "url": "https://ubuntu.com/security/CVE-2024-47691", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread() syzbot reports a f2fs bug as below: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_report+0xe8/0x550 mm/kasan/report.c:491 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 instrument_atomic_read_write include/linux/instrumented.h:96 [inline] atomic_fetch_add_relaxed include/linux/atomic/atomic-instrumented.h:252 [inline] __refcount_add include/linux/refcount.h:184 [inline] __refcount_inc include/linux/refcount.h:241 [inline] refcount_inc include/linux/refcount.h:258 [inline] get_task_struct include/linux/sched/task.h:118 [inline] kthread_stop+0xca/0x630 kernel/kthread.c:704 f2fs_stop_gc_thread+0x65/0xb0 fs/f2fs/gc.c:210 f2fs_do_shutdown+0x192/0x540 fs/f2fs/file.c:2283 f2fs_ioc_shutdown fs/f2fs/file.c:2325 [inline] __f2fs_ioctl+0x443a/0xbe60 fs/f2fs/file.c:4325 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f The root cause is below race condition, it may cause use-after-free issue in sbi->gc_th pointer. - remount - f2fs_remount - f2fs_stop_gc_thread - kfree(gc_th) \t\t\t\t- f2fs_ioc_shutdown \t\t\t\t - f2fs_do_shutdown \t\t\t\t - f2fs_stop_gc_thread \t\t\t\t - kthread_stop(gc_th->f2fs_gc_task) : sbi->gc_thread = NULL; We will call f2fs_do_shutdown() in two paths: - for f2fs_ioc_shutdown() path, we should grab sb->s_umount semaphore for fixing. - for f2fs_shutdown() path, it's safe since caller has already grabbed sb->s_umount semaphore.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47692", "url": "https://ubuntu.com/security/CVE-2024-47692", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: return -EINVAL when namelen is 0 When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may result in namelen being 0, which will cause memdup_user() to return ZERO_SIZE_PTR. When we access the name.data that has been assigned the value of ZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is triggered. [ T1205] ================================================================== [ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260 [ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205 [ T1205] [ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406 [ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ T1205] Call Trace: [ T1205] dump_stack+0x9a/0xd0 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] __kasan_report.cold+0x34/0x84 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] kasan_report+0x3a/0x50 [ T1205] nfs4_client_to_reclaim+0xe9/0x260 [ T1205] ? nfsd4_release_lockowner+0x410/0x410 [ T1205] cld_pipe_downcall+0x5ca/0x760 [ T1205] ? nfsd4_cld_tracking_exit+0x1d0/0x1d0 [ T1205] ? down_write_killable_nested+0x170/0x170 [ T1205] ? avc_policy_seqno+0x28/0x40 [ T1205] ? selinux_file_permission+0x1b4/0x1e0 [ T1205] rpc_pipe_write+0x84/0xb0 [ T1205] vfs_write+0x143/0x520 [ T1205] ksys_write+0xc9/0x170 [ T1205] ? __ia32_sys_read+0x50/0x50 [ T1205] ? ktime_get_coarse_real_ts64+0xfe/0x110 [ T1205] ? ktime_get_coarse_real_ts64+0xa2/0x110 [ T1205] do_syscall_64+0x33/0x40 [ T1205] entry_SYSCALL_64_after_hwframe+0x67/0xd1 [ T1205] RIP: 0033:0x7fdbdb761bc7 [ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 514 [ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7 [ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008 [ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001 [ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b [ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000 [ T1205] ================================================================== Fix it by checking namelen.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47737", "url": "https://ubuntu.com/security/CVE-2024-47737", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: call cache_put if xdr_reserve_space returns NULL If not enough buffer space available, but idmap_lookup has triggered lookup_fn which calls cache_get and returns successfully. Then we missed to call cache_put here which pairs with cache_get. Reviwed-by: Jeff Layton ", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2023-52917", "url": "https://ubuntu.com/security/CVE-2023-52917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir() The debugfs_create_dir() function returns error pointers. It never returns NULL. So use IS_ERR() to check it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47749", "url": "https://ubuntu.com/security/CVE-2024-47749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Added NULL check for lookup_atid The lookup_atid() function can return NULL if the ATID is invalid or does not exist in the identifier table, which could lead to dereferencing a null pointer without a check in the `act_establish()` and `act_open_rpl()` functions. Add a NULL check to prevent null pointer dereferencing. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47735", "url": "https://ubuntu.com/security/CVE-2024-47735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled Fix missuse of spin_lock_irq()/spin_unlock_irq() when spin_lock_irqsave()/spin_lock_irqrestore() was hold. This was discovered through the lock debugging, and the corresponding log is as follows: raw_local_irq_restore() called with IRQs enabled WARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40 ... Call trace: warn_bogus_irq_restore+0x30/0x40 _raw_spin_unlock_irqrestore+0x84/0xc8 add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2] hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2] hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2] create_qp+0x138/0x258 ib_create_qp_kernel+0x50/0xe8 create_mad_qp+0xa8/0x128 ib_mad_port_open+0x218/0x448 ib_mad_init_device+0x70/0x1f8 add_client_context+0xfc/0x220 enable_device_and_get+0xd0/0x140 ib_register_device.part.0+0xf4/0x1c8 ib_register_device+0x34/0x50 hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2] hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2] __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2] hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47750", "url": "https://ubuntu.com/security/CVE-2024-47750", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix Use-After-Free of rsv_qp on HIP08 Currently rsv_qp is freed before ib_unregister_device() is called on HIP08. During the time interval, users can still dereg MR and rsv_qp will be used in this process, leading to a UAF. Move the release of rsv_qp after calling ib_unregister_device() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47751", "url": "https://ubuntu.com/security/CVE-2024-47751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: kirin: Fix buffer overflow in kirin_pcie_parse_port() Within kirin_pcie_parse_port(), the pcie->num_slots is compared to pcie->gpio_id_reset size (MAX_PCI_SLOTS) which is correct and would lead to an overflow. Thus, fix condition to pcie->num_slots + 1 >= MAX_PCI_SLOTS and move pcie->num_slots increment below the if-statement to avoid out-of-bounds array access. Found by Linux Verification Center (linuxtesting.org) with SVACE. [kwilczynski: commit log]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47693", "url": "https://ubuntu.com/security/CVE-2024-47693", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/core: Fix ib_cache_setup_one error flow cleanup When ib_cache_update return an error, we exit ib_cache_setup_one instantly with no proper cleanup, even though before this we had already successfully done gid_table_setup_one, that results in the kernel WARN below. Do proper cleanup using gid_table_cleanup_one before returning the err in order to fix the issue. WARNING: CPU: 4 PID: 922 at drivers/infiniband/core/cache.c:806 gid_table_release_one+0x181/0x1a0 Modules linked in: CPU: 4 UID: 0 PID: 922 Comm: c_repro Not tainted 6.11.0-rc1+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:gid_table_release_one+0x181/0x1a0 Code: 44 8b 38 75 0c e8 2f cb 34 ff 4d 8b b5 28 05 00 00 e8 23 cb 34 ff 44 89 f9 89 da 4c 89 f6 48 c7 c7 d0 58 14 83 e8 4f de 21 ff <0f> 0b 4c 8b 75 30 e9 54 ff ff ff 48 8 3 c4 10 5b 5d 41 5c 41 5d 41 RSP: 0018:ffffc90002b835b0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c8527 RDX: 0000000000000000 RSI: ffffffff811c8534 RDI: 0000000000000001 RBP: ffff8881011b3d00 R08: ffff88810b3abe00 R09: 205d303839303631 R10: 666572207972746e R11: 72746e6520444947 R12: 0000000000000001 R13: ffff888106390000 R14: ffff8881011f2110 R15: 0000000000000001 FS: 00007fecc3b70800(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000340 CR3: 000000010435a001 CR4: 00000000003706b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? show_regs+0x94/0xa0 ? __warn+0x9e/0x1c0 ? gid_table_release_one+0x181/0x1a0 ? report_bug+0x1f9/0x340 ? gid_table_release_one+0x181/0x1a0 ? handle_bug+0xa2/0x110 ? exc_invalid_op+0x31/0xa0 ? asm_exc_invalid_op+0x16/0x20 ? __warn_printk+0xc7/0x180 ? __warn_printk+0xd4/0x180 ? gid_table_release_one+0x181/0x1a0 ib_device_release+0x71/0xe0 ? __pfx_ib_device_release+0x10/0x10 device_release+0x44/0xd0 kobject_put+0x135/0x3d0 put_device+0x20/0x30 rxe_net_add+0x7d/0xa0 rxe_newlink+0xd7/0x190 nldev_newlink+0x1b0/0x2a0 ? __pfx_nldev_newlink+0x10/0x10 rdma_nl_rcv_msg+0x1ad/0x2e0 rdma_nl_rcv_skb.constprop.0+0x176/0x210 netlink_unicast+0x2de/0x400 netlink_sendmsg+0x306/0x660 __sock_sendmsg+0x110/0x120 ____sys_sendmsg+0x30e/0x390 ___sys_sendmsg+0x9b/0xf0 ? kstrtouint+0x6e/0xa0 ? kstrtouint_from_user+0x7c/0xb0 ? get_pid_task+0xb0/0xd0 ? proc_fail_nth_write+0x5b/0x140 ? __fget_light+0x9a/0x200 ? preempt_count_add+0x47/0xa0 __sys_sendmsg+0x61/0xd0 do_syscall_64+0x50/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47694", "url": "https://ubuntu.com/security/CVE-2024-47694", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mlx5: Fix UMR pd cleanup on error flow of driver init The cited commit moves the pd allocation from function mlx5r_umr_resource_cleanup() to a new function mlx5r_umr_cleanup(). So the fix in commit [1] is broken. In error flow, will hit panic [2]. Fix it by checking pd pointer to avoid panic if it is NULL; [1] RDMA/mlx5: Fix UMR cleanup on error flow of driver init [2] [ 347.567063] infiniband mlx5_0: Couldn't register device with driver model [ 347.591382] BUG: kernel NULL pointer dereference, address: 0000000000000020 [ 347.593438] #PF: supervisor read access in kernel mode [ 347.595176] #PF: error_code(0x0000) - not-present page [ 347.596962] PGD 0 P4D 0 [ 347.601361] RIP: 0010:ib_dealloc_pd_user+0x12/0xc0 [ib_core] [ 347.604171] RSP: 0018:ffff888106293b10 EFLAGS: 00010282 [ 347.604834] RAX: 0000000000000000 RBX: 000000000000000e RCX: 0000000000000000 [ 347.605672] RDX: ffff888106293ad0 RSI: 0000000000000000 RDI: 0000000000000000 [ 347.606529] RBP: 0000000000000000 R08: ffff888106293ae0 R09: ffff888106293ae0 [ 347.607379] R10: 0000000000000a06 R11: 0000000000000000 R12: 0000000000000000 [ 347.608224] R13: ffffffffa0704dc0 R14: 0000000000000001 R15: 0000000000000001 [ 347.609067] FS: 00007fdc720cd9c0(0000) GS:ffff88852c880000(0000) knlGS:0000000000000000 [ 347.610094] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 347.610727] CR2: 0000000000000020 CR3: 0000000103012003 CR4: 0000000000370eb0 [ 347.611421] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 347.612113] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 347.612804] Call Trace: [ 347.613130] [ 347.613417] ? __die+0x20/0x60 [ 347.613793] ? page_fault_oops+0x150/0x3e0 [ 347.614243] ? free_msg+0x68/0x80 [mlx5_core] [ 347.614840] ? cmd_exec+0x48f/0x11d0 [mlx5_core] [ 347.615359] ? exc_page_fault+0x74/0x130 [ 347.615808] ? asm_exc_page_fault+0x22/0x30 [ 347.616273] ? ib_dealloc_pd_user+0x12/0xc0 [ib_core] [ 347.616801] mlx5r_umr_cleanup+0x23/0x90 [mlx5_ib] [ 347.617365] mlx5_ib_stage_pre_ib_reg_umr_cleanup+0x36/0x40 [mlx5_ib] [ 347.618025] __mlx5_ib_add+0x96/0xd0 [mlx5_ib] [ 347.618539] mlx5r_probe+0xe9/0x310 [mlx5_ib] [ 347.619032] ? kernfs_add_one+0x107/0x150 [ 347.619478] ? __mlx5_ib_add+0xd0/0xd0 [mlx5_ib] [ 347.619984] auxiliary_bus_probe+0x3e/0x90 [ 347.620448] really_probe+0xc5/0x3a0 [ 347.620857] __driver_probe_device+0x80/0x160 [ 347.621325] driver_probe_device+0x1e/0x90 [ 347.621770] __driver_attach+0xec/0x1c0 [ 347.622213] ? __device_attach_driver+0x100/0x100 [ 347.622724] bus_for_each_dev+0x71/0xc0 [ 347.623151] bus_add_driver+0xed/0x240 [ 347.623570] driver_register+0x58/0x100 [ 347.623998] __auxiliary_driver_register+0x6a/0xc0 [ 347.624499] ? driver_register+0xae/0x100 [ 347.624940] ? 0xffffffffa0893000 [ 347.625329] mlx5_ib_init+0x16a/0x1e0 [mlx5_ib] [ 347.625845] do_one_initcall+0x4a/0x2a0 [ 347.626273] ? gcov_event+0x2e2/0x3a0 [ 347.626706] do_init_module+0x8a/0x260 [ 347.627126] init_module_from_file+0x8b/0xd0 [ 347.627596] __x64_sys_finit_module+0x1ca/0x2f0 [ 347.628089] do_syscall_64+0x4c/0x100", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47695", "url": "https://ubuntu.com/security/CVE-2024-47695", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds In the function init_conns(), after the create_con() and create_cm() for loop if something fails. In the cleanup for loop after the destroy tag, we access out of bound memory because cid is set to clt_path->s.con_num. This commits resets the cid to clt_path->s.con_num - 1, to stay in bounds in the cleanup loop later.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47752", "url": "https://ubuntu.com/security/CVE-2024-47752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix H264 stateless decoder smatch warning Fix a smatch static checker warning on vdec_h264_req_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47753", "url": "https://ubuntu.com/security/CVE-2024-47753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix VP8 stateless decoder smatch warning Fix a smatch static checker warning on vdec_vp8_req_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47754", "url": "https://ubuntu.com/security/CVE-2024-47754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix H264 multi stateless decoder smatch warning Fix a smatch static checker warning on vdec_h264_req_multi_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47696", "url": "https://ubuntu.com/security/CVE-2024-47696", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency In the commit aee2424246f9 (\"RDMA/iwcm: Fix a use-after-free related to destroying CM IDs\"), the function flush_workqueue is invoked to flush the work queue iwcm_wq. But at that time, the work queue iwcm_wq was created via the function alloc_ordered_workqueue without the flag WQ_MEM_RECLAIM. Because the current process is trying to flush the whole iwcm_wq, if iwcm_wq doesn't have the flag WQ_MEM_RECLAIM, verify that the current process is not reclaiming memory or running on a workqueue which doesn't have the flag WQ_MEM_RECLAIM as that can break forward-progress guarantee leading to a deadlock. The call trace is as below: [ 125.350876][ T1430] Call Trace: [ 125.356281][ T1430] [ 125.361285][ T1430] ? __warn (kernel/panic.c:693) [ 125.367640][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.375689][ T1430] ? report_bug (lib/bug.c:180 lib/bug.c:219) [ 125.382505][ T1430] ? handle_bug (arch/x86/kernel/traps.c:239) [ 125.388987][ T1430] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) [ 125.395831][ T1430] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621) [ 125.403125][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.410984][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.418764][ T1430] __flush_workqueue (kernel/workqueue.c:3970) [ 125.426021][ T1430] ? __pfx___might_resched (kernel/sched/core.c:10151) [ 125.433431][ T1430] ? destroy_cm_id (drivers/infiniband/core/iwcm.c:375) iw_cm [ 125.441209][ T1430] ? __pfx___flush_workqueue (kernel/workqueue.c:3910) [ 125.473900][ T1430] ? _raw_spin_lock_irqsave (arch/x86/include/asm/atomic.h:107 include/linux/atomic/atomic-arch-fallback.h:2170 include/linux/atomic/atomic-instrumented.h:1302 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162) [ 125.473909][ T1430] ? __pfx__raw_spin_lock_irqsave (kernel/locking/spinlock.c:161) [ 125.482537][ T1430] _destroy_id (drivers/infiniband/core/cma.c:2044) rdma_cm [ 125.495072][ T1430] nvme_rdma_free_queue (drivers/nvme/host/rdma.c:656 drivers/nvme/host/rdma.c:650) nvme_rdma [ 125.505827][ T1430] nvme_rdma_reset_ctrl_work (drivers/nvme/host/rdma.c:2180) nvme_rdma [ 125.505831][ T1430] process_one_work (kernel/workqueue.c:3231) [ 125.515122][ T1430] worker_thread (kernel/workqueue.c:3306 kernel/workqueue.c:3393) [ 125.515127][ T1430] ? __pfx_worker_thread (kernel/workqueue.c:3339) [ 125.531837][ T1430] kthread (kernel/kthread.c:389) [ 125.539864][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.550628][ T1430] ret_from_fork (arch/x86/kernel/process.c:147) [ 125.558840][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.558844][ T1430] ret_from_fork_asm (arch/x86/entry/entry_64.S:257) [ 125.566487][ T1430] [ 125.566488][ T1430] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47755", "url": "https://ubuntu.com/security/CVE-2024-47755", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47756", "url": "https://ubuntu.com/security/CVE-2024-47756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: keystone: Fix if-statement expression in ks_pcie_quirk() This code accidentally uses && where || was intended. It potentially results in a NULL dereference. Thus, fix the if-statement expression to use the correct condition. [kwilczynski: commit log]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47697", "url": "https://ubuntu.com/security/CVE-2024-47697", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error Ensure index in rtl2830_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47698", "url": "https://ubuntu.com/security/CVE-2024-47698", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error Ensure index in rtl2832_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue. [hverkuil: added fixes tag, rtl2830_pid_filter -> rtl2832_pid_filter in logmsg]", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47728", "url": "https://ubuntu.com/security/CVE-2024-47728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error For all non-tracing helpers which formerly had ARG_PTR_TO_{LONG,INT} as input arguments, zero the value for the case of an error as otherwise it could leak memory. For tracing, it is not needed given CAP_PERFMON can already read all kernel memory anyway hence bpf_get_func_arg() and bpf_get_func_ret() is skipped in here. Also, the MTU helpers mtu_len pointer value is being written but also read. Technically, the MEM_UNINIT should not be there in order to always force init. Removing MEM_UNINIT needs more verifier rework though: MEM_UNINIT right now implies two things actually: i) write into memory, ii) memory does not have to be initialized. If we lift MEM_UNINIT, it then becomes: i) read into memory, ii) memory must be initialized. This means that for bpf_*_check_mtu() we're readding the issue we're trying to fix, that is, it would then be able to write back into things like .rodata BPF maps. Follow-up work will rework the MEM_UNINIT semantics such that the intent can be better expressed. For now just clear the *mtu_len on error path which can be lifted later again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49861", "url": "https://ubuntu.com/security/CVE-2024-49861", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix helper writes to read-only maps Lonial found an issue that despite user- and BPF-side frozen BPF map (like in case of .rodata), it was still possible to write into it from a BPF program side through specific helpers having ARG_PTR_TO_{LONG,INT} as arguments. In check_func_arg() when the argument is as mentioned, the meta->raw_mode is never set. Later, check_helper_mem_access(), under the case of PTR_TO_MAP_VALUE as register base type, it assumes BPF_READ for the subsequent call to check_map_access_type() and given the BPF map is read-only it succeeds. The helpers really need to be annotated as ARG_PTR_TO_{LONG,INT} | MEM_UNINIT when results are written into them as opposed to read out of them. The latter indicates that it's okay to pass a pointer to uninitialized memory as the memory is written to anyway. However, ARG_PTR_TO_{LONG,INT} is a special case of ARG_PTR_TO_FIXED_SIZE_MEM just with additional alignment requirement. So it is better to just get rid of the ARG_PTR_TO_{LONG,INT} special cases altogether and reuse the fixed size memory types. For this, add MEM_ALIGNED to additionally ensure alignment given these helpers write directly into the args via * = val. The .arg*_size has been initialized reflecting the actual sizeof(*). MEM_ALIGNED can only be used in combination with MEM_FIXED_SIZE annotated argument types, since in !MEM_FIXED_SIZE cases the verifier does not know the buffer size a priori and therefore cannot blindly write * = val.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47757", "url": "https://ubuntu.com/security/CVE-2024-47757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential oob read in nilfs_btree_check_delete() The function nilfs_btree_check_delete(), which checks whether degeneration to direct mapping occurs before deleting a b-tree entry, causes memory access outside the block buffer when retrieving the maximum key if the root node has no entries. This does not usually happen because b-tree mappings with 0 child nodes are never created by mkfs.nilfs2 or nilfs2 itself. However, it can happen if the b-tree root node read from a device is configured that way, so fix this potential issue by adding a check for that case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47699", "url": "https://ubuntu.com/security/CVE-2024-47699", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential null-ptr-deref in nilfs_btree_insert() Patch series \"nilfs2: fix potential issues with empty b-tree nodes\". This series addresses three potential issues with empty b-tree nodes that can occur with corrupted filesystem images, including one recently discovered by syzbot. This patch (of 3): If a b-tree is broken on the device, and the b-tree height is greater than 2 (the level of the root node is greater than 1) even if the number of child nodes of the b-tree root is 0, a NULL pointer dereference occurs in nilfs_btree_prepare_insert(), which is called from nilfs_btree_insert(). This is because, when the number of child nodes of the b-tree root is 0, nilfs_btree_do_lookup() does not set the block buffer head in any of path[x].bp_bh, leaving it as the initial value of NULL, but if the level of the b-tree root node is greater than 1, nilfs_btree_get_nonroot_node(), which accesses the buffer memory of path[x].bp_bh, is called. Fix this issue by adding a check to nilfs_btree_root_broken(), which performs sanity checks when reading the root node from the device, to detect this inconsistency. Thanks to Lizhi Xu for trying to solve the bug and clarifying the cause early on.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47700", "url": "https://ubuntu.com/security/CVE-2024-47700", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: check stripe size compatibility on remount as well We disable stripe size in __ext4_fill_super if it is not a multiple of the cluster ratio however this check is missed when trying to remount. This can leave us with cases where stripe < cluster_ratio after remount:set making EXT4_B2C(sbi->s_stripe) become 0 that can cause some unforeseen bugs like divide by 0. Fix that by adding the check in remount path as well.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47701", "url": "https://ubuntu.com/security/CVE-2024-47701", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid OOB when system.data xattr changes underneath the filesystem When looking up for an entry in an inlined directory, if e_value_offs is changed underneath the filesystem by some change in the block device, it will lead to an out-of-bounds access that KASAN detects as an UAF. EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none. loop0: detected capacity change from 2048 to 2047 ================================================================== BUG: KASAN: use-after-free in ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 Read of size 1 at addr ffff88803e91130f by task syz-executor269/5103 CPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 Not tainted 6.11.0-rc4-syzkaller #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:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 ext4_find_inline_entry+0x4be/0x5e0 fs/ext4/inline.c:1697 __ext4_find_entry+0x2b4/0x1b30 fs/ext4/namei.c:1573 ext4_lookup_entry fs/ext4/namei.c:1727 [inline] ext4_lookup+0x15f/0x750 fs/ext4/namei.c:1795 lookup_one_qstr_excl+0x11f/0x260 fs/namei.c:1633 filename_create+0x297/0x540 fs/namei.c:3980 do_symlinkat+0xf9/0x3a0 fs/namei.c:4587 __do_sys_symlinkat fs/namei.c:4610 [inline] __se_sys_symlinkat fs/namei.c:4607 [inline] __x64_sys_symlinkat+0x95/0xb0 fs/namei.c:4607 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:0x7f3e73ced469 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff4d40c258 EFLAGS: 00000246 ORIG_RAX: 000000000000010a RAX: ffffffffffffffda RBX: 0032656c69662f2e RCX: 00007f3e73ced469 RDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0 RBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290 R10: 0023706f6f6c2f76 R11: 0000000000000246 R12: 00007fff4d40c27c R13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0 Calling ext4_xattr_ibody_find right after reading the inode with ext4_get_inode_loc will lead to a check of the validity of the xattrs, avoiding this problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49850", "url": "https://ubuntu.com/security/CVE-2024-49850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: correctly handle malformed BPF_CORE_TYPE_ID_LOCAL relos In case of malformed relocation record of kind BPF_CORE_TYPE_ID_LOCAL referencing a non-existing BTF type, function bpf_core_calc_relo_insn would cause a null pointer deference. Fix this by adding a proper check upper in call stack, as malformed relocation records could be passed from user space. Simplest reproducer is a program: r0 = 0 exit With a single relocation record: .insn_off = 0, /* patch first instruction */ .type_id = 100500, /* this type id does not exist */ .access_str_off = 6, /* offset of string \"0\" */ .kind = BPF_CORE_TYPE_ID_LOCAL, See the link for original reproducer or next commit for a test case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47702", "url": "https://ubuntu.com/security/CVE-2024-47702", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fail verification for sign-extension of packet data/data_end/data_meta syzbot reported a kernel crash due to commit 1f1e864b6555 (\"bpf: Handle sign-extenstin ctx member accesses\"). The reason is due to sign-extension of 32-bit load for packet data/data_end/data_meta uapi field. The original code looks like: r2 = *(s32 *)(r1 + 76) /* load __sk_buff->data */ r3 = *(u32 *)(r1 + 80) /* load __sk_buff->data_end */ r0 = r2 r0 += 8 if r3 > r0 goto +1 ... Note that __sk_buff->data load has 32-bit sign extension. After verification and convert_ctx_accesses(), the final asm code looks like: r2 = *(u64 *)(r1 +208) r2 = (s32)r2 r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 ... Note that 'r2 = (s32)r2' may make the kernel __sk_buff->data address invalid which may cause runtime failure. Currently, in C code, typically we have void *data = (void *)(long)skb->data; void *data_end = (void *)(long)skb->data_end; ... and it will generate r2 = *(u64 *)(r1 +208) r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 If we allow sign-extension, void *data = (void *)(long)(int)skb->data; void *data_end = (void *)(long)skb->data_end; ... the generated code looks like r2 = *(u64 *)(r1 +208) r2 <<= 32 r2 s>>= 32 r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 and this will cause verification failure since \"r2 <<= 32\" is not allowed as \"r2\" is a packet pointer. To fix this issue for case r2 = *(s32 *)(r1 + 76) /* load __sk_buff->data */ this patch added additional checking in is_valid_access() callback function for packet data/data_end/data_meta access. If those accesses are with sign-extenstion, the verification will fail. [1] https://lore.kernel.org/bpf/000000000000c90eee061d236d37@google.com/", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47703", "url": "https://ubuntu.com/security/CVE-2024-47703", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, lsm: Add check for BPF LSM return value A bpf prog returning a positive number attached to file_alloc_security hook makes kernel panic. This happens because file system can not filter out the positive number returned by the LSM prog using IS_ERR, and misinterprets this positive number as a file pointer. Given that hook file_alloc_security never returned positive number before the introduction of BPF LSM, and other BPF LSM hooks may encounter similar issues, this patch adds LSM return value check in verifier, to ensure no unexpected value is returned.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49851", "url": "https://ubuntu.com/security/CVE-2024-49851", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: Clean up TPM space after command failure tpm_dev_transmit prepares the TPM space before attempting command transmission. However if the command fails no rollback of this preparation is done. This can result in transient handles being leaked if the device is subsequently closed with no further commands performed. Fix this by flushing the space in the event of command transmission failure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47723", "url": "https://ubuntu.com/security/CVE-2024-47723", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: fix out-of-bounds in dbNextAG() and diAlloc() In dbNextAG() , there is no check for the case where bmp->db_numag is greater or same than MAXAG due to a polluted image, which causes an out-of-bounds. Therefore, a bounds check should be added in dbMount(). And in dbNextAG(), a check for the case where agpref is greater than bmp->db_numag should be added, so an out-of-bounds exception should be prevented. Additionally, a check for the case where agno is greater or same than MAXAG should be added in diAlloc() to prevent out-of-bounds.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49852", "url": "https://ubuntu.com/security/CVE-2024-49852", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: elx: libefc: Fix potential use after free in efc_nport_vport_del() The kref_put() function will call nport->release if the refcount drops to zero. The nport->release release function is _efc_nport_free() which frees \"nport\". But then we dereference \"nport\" on the next line which is a use after free. Re-order these lines to avoid the use after free.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47720", "url": "https://ubuntu.com/security/CVE-2024-47720", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for set_output_gamma in dcn30_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn30_set_output_transfer_func function. Previously, set_output_gamma was being checked for nullity at line 386, but then it was being dereferenced without any nullity check at line 401. This could potentially lead to a null pointer dereference error if set_output_gamma is indeed null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a nullity check for set_output_gamma before the call to set_output_gamma at line 401. If set_output_gamma is null, we log an error message and do not call the function. This fix prevents a potential null pointer dereference error. drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:401 dcn30_set_output_transfer_func() error: we previously assumed 'mpc->funcs->set_output_gamma' could be null (see line 386) drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c 373 bool dcn30_set_output_transfer_func(struct dc *dc, 374 struct pipe_ctx *pipe_ctx, 375 const struct dc_stream_state *stream) 376 { 377 int mpcc_id = pipe_ctx->plane_res.hubp->inst; 378 struct mpc *mpc = pipe_ctx->stream_res.opp->ctx->dc->res_pool->mpc; 379 const struct pwl_params *params = NULL; 380 bool ret = false; 381 382 /* program OGAM or 3DLUT only for the top pipe*/ 383 if (pipe_ctx->top_pipe == NULL) { 384 /*program rmu shaper and 3dlut in MPC*/ 385 ret = dcn30_set_mpc_shaper_3dlut(pipe_ctx, stream); 386 if (ret == false && mpc->funcs->set_output_gamma) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If this is NULL 387 if (stream->out_transfer_func.type == TF_TYPE_HWPWL) 388 params = &stream->out_transfer_func.pwl; 389 else if (pipe_ctx->stream->out_transfer_func.type == 390 TF_TYPE_DISTRIBUTED_POINTS && 391 cm3_helper_translate_curve_to_hw_format( 392 &stream->out_transfer_func, 393 &mpc->blender_params, false)) 394 params = &mpc->blender_params; 395 /* there are no ROM LUTs in OUTGAM */ 396 if (stream->out_transfer_func.type == TF_TYPE_PREDEFINED) 397 BREAK_TO_DEBUGGER(); 398 } 399 } 400 --> 401 mpc->funcs->set_output_gamma(mpc, mpcc_id, params); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Then it will crash 402 return ret; 403 }", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47704", "url": "https://ubuntu.com/security/CVE-2024-47704", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check link_res->hpo_dp_link_enc before using it [WHAT & HOW] Functions dp_enable_link_phy and dp_disable_link_phy can pass link_res without initializing hpo_dp_link_enc and it is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49853", "url": "https://ubuntu.com/security/CVE-2024-49853", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix double free in OPTEE transport Channels can be shared between protocols, avoid freeing the same channel descriptors twice when unloading the stack.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47705", "url": "https://ubuntu.com/security/CVE-2024-47705", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix potential invalid pointer dereference in blk_add_partition The blk_add_partition() function initially used a single if-condition (IS_ERR(part)) to check for errors when adding a partition. This was modified to handle the specific case of -ENXIO separately, allowing the function to proceed without logging the error in this case. However, this change unintentionally left a path where md_autodetect_dev() could be called without confirming that part is a valid pointer. This commit separates the error handling logic by splitting the initial if-condition, improving code readability and handling specific error scenarios explicitly. The function now distinguishes the general error case from -ENXIO without altering the existing behavior of md_autodetect_dev() calls.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47736", "url": "https://ubuntu.com/security/CVE-2024-47736", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: handle overlapped pclusters out of crafted images properly syzbot reported a task hang issue due to a deadlock case where it is waiting for the folio lock of a cached folio that will be used for cache I/Os. After looking into the crafted fuzzed image, I found it's formed with several overlapped big pclusters as below: Ext: logical offset | length : physical offset | length 0: 0.. 16384 | 16384 : 151552.. 167936 | 16384 1: 16384.. 32768 | 16384 : 155648.. 172032 | 16384 2: 32768.. 49152 | 16384 : 537223168.. 537239552 | 16384 ... Here, extent 0/1 are physically overlapped although it's entirely _impossible_ for normal filesystem images generated by mkfs. First, managed folios containing compressed data will be marked as up-to-date and then unlocked immediately (unlike in-place folios) when compressed I/Os are complete. If physical blocks are not submitted in the incremental order, there should be separate BIOs to avoid dependency issues. However, the current code mis-arranges z_erofs_fill_bio_vec() and BIO submission which causes unexpected BIO waits. Second, managed folios will be connected to their own pclusters for efficient inter-queries. However, this is somewhat hard to implement easily if overlapped big pclusters exist. Again, these only appear in fuzzed images so let's simply fall back to temporary short-lived pages for correctness. Additionally, it justifies that referenced managed folios cannot be truncated for now and reverts part of commit 2080ca1ed3e4 (\"erofs: tidy up `struct z_erofs_bvec`\") for simplicity although it shouldn't be any difference.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47706", "url": "https://ubuntu.com/security/CVE-2024-47706", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block, bfq: fix possible UAF for bfqq->bic with merge chain 1) initial state, three tasks: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t\t | ? | ?\t\t | ? \t\t | | | |\t\t | | \t\t V | V |\t\t V | \t\t bfqq1 bfqq2\t\t bfqq3 process ref:\t 1\t\t 1\t\t 1 2) bfqq1 merged to bfqq2: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t\t | |\t\t | ? \t\t \\--------------\\|\t\t | | \t\t V\t\t V | \t\t bfqq1--------->bfqq2\t\t bfqq3 process ref:\t 0\t\t 2\t\t 1 3) bfqq2 merged to bfqq3: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t here -> ? |\t\t | \t\t \\--------------\\ \\-------------\\| \t\t V\t\t V \t\t bfqq1--------->bfqq2---------->bfqq3 process ref:\t 0\t\t 1\t\t 3 In this case, IO from Process 1 will get bfqq2 from BIC1 first, and then get bfqq3 through merge chain, and finially handle IO by bfqq3. Howerver, current code will think bfqq2 is owned by BIC1, like initial state, and set bfqq2->bic to BIC1. bfq_insert_request -> by Process 1 bfqq = bfq_init_rq(rq) bfqq = bfq_get_bfqq_handle_split bfqq = bic_to_bfqq -> get bfqq2 from BIC1 bfqq->ref++ rq->elv.priv[0] = bic rq->elv.priv[1] = bfqq if (bfqq_process_refs(bfqq) == 1) bfqq->bic = bic -> record BIC1 to bfqq2 __bfq_insert_request new_bfqq = bfq_setup_cooperator -> get bfqq3 from bfqq2->new_bfqq bfqq_request_freed(bfqq) new_bfqq->ref++ rq->elv.priv[1] = new_bfqq -> handle IO by bfqq3 Fix the problem by checking bfqq is from merge chain fist. And this might fix a following problem reported by our syzkaller(unreproducible): ================================================================== BUG: KASAN: slab-use-after-free in bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] BUG: KASAN: slab-use-after-free in bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] BUG: KASAN: slab-use-after-free in bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 Write of size 1 at addr ffff888123839eb8 by task kworker/0:1H/18595 CPU: 0 PID: 18595 Comm: kworker/0:1H Tainted: G L 6.6.0-07439-gba2303cacfda #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Workqueue: kblockd blk_mq_requeue_work Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [inline] print_report+0x10d/0x610 mm/kasan/report.c:475 kasan_report+0x8e/0xc0 mm/kasan/report.c:588 bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 bfq_get_bfqq_handle_split+0x169/0x5d0 block/bfq-iosched.c:6757 bfq_init_rq block/bfq-iosched.c:6876 [inline] bfq_insert_request block/bfq-iosched.c:6254 [inline] bfq_insert_requests+0x1112/0x5cf0 block/bfq-iosched.c:6304 blk_mq_insert_request+0x290/0x8d0 block/blk-mq.c:2593 blk_mq_requeue_work+0x6bc/0xa70 block/blk-mq.c:1502 process_one_work kernel/workqueue.c:2627 [inline] process_scheduled_works+0x432/0x13f0 kernel/workqueue.c:2700 worker_thread+0x6f2/0x1160 kernel/workqueue.c:2781 kthread+0x33c/0x440 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:305 Allocated by task 20776: kasan_save_stack+0x20/0x40 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 __kasan_slab_alloc+0x87/0x90 mm/kasan/common.c:328 kasan_slab_alloc include/linux/kasan.h:188 [inline] slab_post_alloc_hook mm/slab.h:763 [inline] slab_alloc_node mm/slub.c:3458 [inline] kmem_cache_alloc_node+0x1a4/0x6f0 mm/slub.c:3503 ioc_create_icq block/blk-ioc.c:370 [inline] ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49855", "url": "https://ubuntu.com/security/CVE-2024-49855", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: fix race between timeout and normal completion If request timetout is handled by nbd_requeue_cmd(), normal completion has to be stopped for avoiding to complete this requeued request, other use-after-free can be triggered. Fix the race by clearing NBD_CMD_INFLIGHT in nbd_requeue_cmd(), meantime make sure that cmd->lock is grabbed for clearing the flag and the requeue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47707", "url": "https://ubuntu.com/security/CVE-2024-47707", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev() Blamed commit accidentally removed a check for rt->rt6i_idev being NULL, as spotted by syzbot: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 UID: 0 PID: 10998 Comm: syz-executor Not tainted 6.11.0-rc6-syzkaller-00208-g625403177711 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 RBP: ffffc900047375d0 R08: 0000000000000003 R09: fffff520008e6e8c R10: dffffc0000000000 R11: fffff520008e6e8c R12: 1ffff1100fdf8f18 R13: ffff88807efc7998 R14: 0000000000000000 R15: ffff88807efc7930 FS: 0000000000000000(0000) GS:ffff8880b8900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020002a80 CR3: 0000000022f62000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: addrconf_ifdown+0x15d/0x1bd0 net/ipv6/addrconf.c:3856 addrconf_notify+0x3cb/0x1020 notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93 call_netdevice_notifiers_extack net/core/dev.c:2032 [inline] call_netdevice_notifiers net/core/dev.c:2046 [inline] unregister_netdevice_many_notify+0xd81/0x1c40 net/core/dev.c:11352 unregister_netdevice_many net/core/dev.c:11414 [inline] unregister_netdevice_queue+0x303/0x370 net/core/dev.c:11289 unregister_netdevice include/linux/netdevice.h:3129 [inline] __tun_detach+0x6b9/0x1600 drivers/net/tun.c:685 tun_detach drivers/net/tun.c:701 [inline] tun_chr_close+0x108/0x1b0 drivers/net/tun.c:3510 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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:0x7f1acc77def9 Code: Unable to access opcode bytes at 0x7f1acc77decf. RSP: 002b:00007ffeb26fa738 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1acc77def9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000043 RBP: 00007f1acc7dd508 R08: 00007ffeb26f84d7 R09: 0000000000000003 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 0000000000000003 R14: 00000000ffffffff R15: 00007ffeb26fa8e0 Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 R ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47708", "url": "https://ubuntu.com/security/CVE-2024-47708", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netkit: Assign missing bpf_net_context During the introduction of struct bpf_net_context handling for XDP-redirect, the netkit driver has been missed, which also requires it because NETKIT_REDIRECT invokes skb_do_redirect() which is accessing the per-CPU variables. Otherwise we see the following crash: \tBUG: kernel NULL pointer dereference, address: 0000000000000038 \tbpf_redirect() \tnetkit_xmit() \tdev_hard_start_xmit() Set the bpf_net_context before invoking netkit_xmit() program within the netkit driver.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47709", "url": "https://ubuntu.com/security/CVE-2024-47709", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: Clear bo->bcm_proc_read after remove_proc_entry(). syzbot reported a warning in bcm_release(). [0] The blamed change fixed another warning that is triggered when connect() is issued again for a socket whose connect()ed device has been unregistered. However, if the socket is just close()d without the 2nd connect(), the remaining bo->bcm_proc_read triggers unnecessary remove_proc_entry() in bcm_release(). Let's clear bo->bcm_proc_read after remove_proc_entry() in bcm_notify(). [0] name '4986' WARNING: CPU: 0 PID: 5234 at fs/proc/generic.c:711 remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Modules linked in: CPU: 0 UID: 0 PID: 5234 Comm: syz-executor606 Not tainted 6.11.0-rc5-syzkaller-00178-g5517ae241919 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Code: ff eb 05 e8 cb 1e 5e ff 48 8b 5c 24 10 48 c7 c7 e0 f7 aa 8e e8 2a 38 8e 09 90 48 c7 c7 60 3a 1b 8c 48 89 de e8 da 42 20 ff 90 <0f> 0b 90 90 48 8b 44 24 18 48 c7 44 24 40 0e 36 e0 45 49 c7 04 07 RSP: 0018:ffffc9000345fa20 EFLAGS: 00010246 RAX: 2a2d0aee2eb64600 RBX: ffff888032f1f548 RCX: ffff888029431e00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000345fb08 R08: ffffffff8155b2f2 R09: 1ffff1101710519a R10: dffffc0000000000 R11: ffffed101710519b R12: ffff888011d38640 R13: 0000000000000004 R14: 0000000000000000 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8880b8800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcfb52722f0 CR3: 000000000e734000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: bcm_release+0x250/0x880 net/can/bcm.c:1578 __sock_release net/socket.c:659 [inline] sock_close+0xbc/0x240 net/socket.c:1421 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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:0x7fcfb51ee969 Code: Unable to access opcode bytes at 0x7fcfb51ee93f. RSP: 002b:00007ffce0109ca8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fcfb51ee969 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 00007fcfb526f3b0 R08: ffffffffffffffb8 R09: 0000555500000000 R10: 0000555500000000 R11: 0000000000000246 R12: 00007fcfb526f3b0 R13: 0000000000000000 R14: 00007fcfb5271ee0 R15: 00007fcfb51bf160 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47710", "url": "https://ubuntu.com/security/CVE-2024-47710", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sock_map: Add a cond_resched() in sock_hash_free() Several syzbot soft lockup reports all have in common sock_hash_free() If a map with a large number of buckets is destroyed, we need to yield the cpu when needed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47711", "url": "https://ubuntu.com/security/CVE-2024-47711", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Don't return OOB skb in manage_oob(). syzbot reported use-after-free in unix_stream_recv_urg(). [0] The scenario is 1. send(MSG_OOB) 2. recv(MSG_OOB) -> The consumed OOB remains in recv queue 3. send(MSG_OOB) 4. recv() -> manage_oob() returns the next skb of the consumed OOB -> This is also OOB, but unix_sk(sk)->oob_skb is not cleared 5. recv(MSG_OOB) -> unix_sk(sk)->oob_skb is used but already freed The recent commit 8594d9b85c07 (\"af_unix: Don't call skb_get() for OOB skb.\") uncovered the issue. If the OOB skb is consumed and the next skb is peeked in manage_oob(), we still need to check if the skb is OOB. Let's do so by falling back to the following checks in manage_oob() and add the test case in selftest. Note that we need to add a similar check for SIOCATMARK. [0]: BUG: KASAN: slab-use-after-free in unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959 Read of size 4 at addr ffff8880326abcc4 by task syz-executor178/5235 CPU: 0 UID: 0 PID: 5235 Comm: syz-executor178 Not tainted 6.11.0-rc5-syzkaller-00742-gfbdaffe41adc #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959 unix_stream_recv_urg+0x1df/0x320 net/unix/af_unix.c:2640 unix_stream_read_generic+0x2456/0x2520 net/unix/af_unix.c:2778 unix_stream_recvmsg+0x22b/0x2c0 net/unix/af_unix.c:2996 sock_recvmsg_nosec net/socket.c:1046 [inline] sock_recvmsg+0x22f/0x280 net/socket.c:1068 ____sys_recvmsg+0x1db/0x470 net/socket.c:2816 ___sys_recvmsg net/socket.c:2858 [inline] __sys_recvmsg+0x2f0/0x3e0 net/socket.c:2888 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:0x7f5360d6b4e9 Code: 48 83 c4 28 c3 e8 37 17 00 00 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff29b3a458 EFLAGS: 00000246 ORIG_RAX: 000000000000002f RAX: ffffffffffffffda RBX: 00007fff29b3a638 RCX: 00007f5360d6b4e9 RDX: 0000000000002001 RSI: 0000000020000640 RDI: 0000000000000003 RBP: 00007f5360dde610 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 00007fff29b3a628 R14: 0000000000000001 R15: 0000000000000001 Allocated by task 5235: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:312 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slub.c:3988 [inline] slab_alloc_node mm/slub.c:4037 [inline] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4080 __alloc_skb+0x1c3/0x440 net/core/skbuff.c:667 alloc_skb include/linux/skbuff.h:1320 [inline] alloc_skb_with_frags+0xc3/0x770 net/core/skbuff.c:6528 sock_alloc_send_pskb+0x91a/0xa60 net/core/sock.c:2815 sock_alloc_send_skb include/net/sock.h:1778 [inline] queue_oob+0x108/0x680 net/unix/af_unix.c:2198 unix_stream_sendmsg+0xd24/0xf80 net/unix/af_unix.c:2351 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2680 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 Freed by task 5235: kasan_save_stack mm/kasan/common.c:47 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47712", "url": "https://ubuntu.com/security/CVE-2024-47712", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: fix potential RCU dereference issue in wilc_parse_join_bss_param In the `wilc_parse_join_bss_param` function, the TSF field of the `ies` structure is accessed after the RCU read-side critical section is unlocked. According to RCU usage rules, this is illegal. Reusing this pointer can lead to unpredictable behavior, including accessing memory that has been updated or causing use-after-free issues. This possible bug was identified using a static analysis tool developed by myself, specifically designed to detect RCU-related issues. To address this, the TSF value is now stored in a local variable `ies_tsf` before the RCU lock is released. The `param->tsf_lo` field is then assigned using this local variable, ensuring that the TSF value is safely accessed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47713", "url": "https://ubuntu.com/security/CVE-2024-47713", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop() Since '__dev_queue_xmit()' should be called with interrupts enabled, the following backtrace: ieee80211_do_stop() ... spin_lock_irqsave(&local->queue_stop_reason_lock, flags) ... ieee80211_free_txskb() ieee80211_report_used_skb() ieee80211_report_ack_skb() cfg80211_mgmt_tx_status_ext() nl80211_frame_tx_status() genlmsg_multicast_netns() genlmsg_multicast_netns_filtered() nlmsg_multicast_filtered() \t netlink_broadcast_filtered() \t do_one_broadcast() \t netlink_broadcast_deliver() \t __netlink_sendskb() \t netlink_deliver_tap() \t __netlink_deliver_tap_skb() \t dev_queue_xmit() \t __dev_queue_xmit() ; with IRQS disabled ... spin_unlock_irqrestore(&local->queue_stop_reason_lock, flags) issues the warning (as reported by syzbot reproducer): WARNING: CPU: 2 PID: 5128 at kernel/softirq.c:362 __local_bh_enable_ip+0xc3/0x120 Fix this by implementing a two-phase skb reclamation in 'ieee80211_do_stop()', where actual work is performed outside of a section with interrupts disabled.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47730", "url": "https://ubuntu.com/security/CVE-2024-47730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/qm - inject error before stopping queue The master ooo cannot be completely closed when the accelerator core reports memory error. Therefore, the driver needs to inject the qm error to close the master ooo. Currently, the qm error is injected after stopping queue, memory may be released immediately after stopping queue, causing the device to access the released memory. Therefore, error is injected to close master ooo before stopping queue to ensure that the device does not access the released memory.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49856", "url": "https://ubuntu.com/security/CVE-2024-49856", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/sgx: Fix deadlock in SGX NUMA node search When the current node doesn't have an EPC section configured by firmware and all other EPC sections are used up, CPU can get stuck inside the while loop that looks for an available EPC page from remote nodes indefinitely, leading to a soft lockup. Note how nid_of_current will never be equal to nid in that while loop because nid_of_current is not set in sgx_numa_mask. Also worth mentioning is that it's perfectly fine for the firmware not to setup an EPC section on a node. While setting up an EPC section on each node can enhance performance, it is not a requirement for functionality. Rework the loop to start and end on *a* node that has SGX memory. This avoids the deadlock looking for the current SGX-lacking node to show up in the loop when it never will.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47714", "url": "https://ubuntu.com/security/CVE-2024-47714", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: use hweight16 to get correct tx antenna The chainmask is u16 so using hweight8 cannot get correct tx_ant. Without this patch, the tx_ant of band 2 would be -1 and lead to the following issue: BUG: KASAN: stack-out-of-bounds in mt7996_mcu_add_sta+0x12e0/0x16e0 [mt7996e]", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47715", "url": "https://ubuntu.com/security/CVE-2024-47715", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: fix oops on non-dbdc mt7986 mt7915_band_config() sets band_idx = 1 on the main phy for mt7986 with MT7975_ONE_ADIE or MT7976_ONE_ADIE. Commit 0335c034e726 (\"wifi: mt76: fix race condition related to checking tx queue fill status\") introduced a dereference of the phys array indirectly indexed by band_idx via wcid->phy_idx in mt76_wcid_cleanup(). This caused the following Oops on affected mt7986 devices: Unable to handle kernel read from unreadable memory at virtual address 0000000000000024 Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x00000005 CM = 0, WnR = 0 user pgtable: 4k pages, 39-bit VAs, pgdp=0000000042545000 [0000000000000024] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 Internal error: Oops: 0000000096000005 [#1] SMP Modules linked in: ... mt7915e mt76_connac_lib mt76 mac80211 cfg80211 ... CPU: 2 PID: 1631 Comm: hostapd Not tainted 5.15.150 #0 Hardware name: ZyXEL EX5700 (Telenor) (DT) pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mt76_wcid_cleanup+0x84/0x22c [mt76] lr : mt76_wcid_cleanup+0x64/0x22c [mt76] sp : ffffffc00a803700 x29: ffffffc00a803700 x28: ffffff80008f7300 x27: ffffff80003f3c00 x26: ffffff80000a7880 x25: ffffffc008c26e00 x24: 0000000000000001 x23: ffffffc000a68114 x22: 0000000000000000 x21: ffffff8004172cc8 x20: ffffffc00a803748 x19: ffffff8004152020 x18: 0000000000000000 x17: 00000000000017c0 x16: ffffffc008ef5000 x15: 0000000000000be0 x14: ffffff8004172e28 x13: ffffff8004172e28 x12: 0000000000000000 x11: 0000000000000000 x10: ffffff8004172e30 x9 : ffffff8004172e28 x8 : 0000000000000000 x7 : ffffff8004156020 x6 : 0000000000000000 x5 : 0000000000000031 x4 : 0000000000000000 x3 : 0000000000000001 x2 : 0000000000000000 x1 : ffffff80008f7300 x0 : 0000000000000024 Call trace: mt76_wcid_cleanup+0x84/0x22c [mt76] __mt76_sta_remove+0x70/0xbc [mt76] mt76_sta_state+0x8c/0x1a4 [mt76] mt7915_eeprom_get_power_delta+0x11e4/0x23a0 [mt7915e] drv_sta_state+0x144/0x274 [mac80211] sta_info_move_state+0x1cc/0x2a4 [mac80211] sta_set_sinfo+0xaf8/0xc24 [mac80211] sta_info_destroy_addr_bss+0x4c/0x6c [mac80211] ieee80211_color_change_finish+0x1c08/0x1e70 [mac80211] cfg80211_check_station_change+0x1360/0x4710 [cfg80211] genl_family_rcv_msg_doit+0xb4/0x110 genl_rcv_msg+0xd0/0x1bc netlink_rcv_skb+0x58/0x120 genl_rcv+0x34/0x50 netlink_unicast+0x1f0/0x2ec netlink_sendmsg+0x198/0x3d0 ____sys_sendmsg+0x1b0/0x210 ___sys_sendmsg+0x80/0xf0 __sys_sendmsg+0x44/0xa0 __arm64_sys_sendmsg+0x20/0x30 invoke_syscall.constprop.0+0x4c/0xe0 do_el0_svc+0x40/0xd0 el0_svc+0x14/0x4c el0t_64_sync_handler+0x100/0x110 el0t_64_sync+0x15c/0x160 Code: d2800002 910092c0 52800023 f9800011 (885f7c01) ---[ end trace 7e42dd9a39ed2281 ]--- Fix by using mt76_dev_phy() which will map band_idx to the correct phy for all hardware combinations.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49857", "url": "https://ubuntu.com/security/CVE-2024-49857", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: set the cipher for secured NDP ranging The cipher pointer is not set, but is derefereced trying to set its content, which leads to a NULL pointer dereference. Fix it by pointing to the cipher parameter before dereferencing.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47738", "url": "https://ubuntu.com/security/CVE-2024-47738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: don't use rate mask for offchannel TX either Like the commit ab9177d83c04 (\"wifi: mac80211: don't use rate mask for scanning\"), ignore incorrect settings to avoid no supported rate warning reported by syzbot. The syzbot did bisect and found cause is commit 9df66d5b9f45 (\"cfg80211: fix default HE tx bitrate mask in 2G band\"), which however corrects bitmask of HE MCS and recognizes correctly settings of empty legacy rate plus HE MCS rate instead of returning -EINVAL. As suggestions [1], follow the change of SCAN TX to consider this case of offchannel TX as well. [1] https://lore.kernel.org/linux-wireless/6ab2dc9c3afe753ca6fdcdd1421e7a1f47e87b84.camel@sipsolutions.net/T/#m2ac2a6d2be06a37c9c47a3d8a44b4f647ed4f024", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47731", "url": "https://ubuntu.com/security/CVE-2024-47731", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers/perf: Fix ali_drw_pmu driver interrupt status clearing The alibaba_uncore_pmu driver forgot to clear all interrupt status in the interrupt processing function. After the PMU counter overflow interrupt occurred, an interrupt storm occurred, causing the system to hang. Therefore, clear the correct interrupt status in the interrupt handling function to fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49862", "url": "https://ubuntu.com/security/CVE-2024-49862", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powercap: intel_rapl: Fix off by one in get_rpi() The rp->priv->rpi array is either rpi_msr or rpi_tpmi which have NR_RAPL_PRIMITIVES number of elements. Thus the > needs to be >= to prevent an off by one access.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47716", "url": "https://ubuntu.com/security/CVE-2024-47716", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: 9410/1: vfp: Use asm volatile in fmrx/fmxr macros Floating point instructions in userspace can crash some arm kernels built with clang/LLD 17.0.6: BUG: unsupported FP instruction in kernel mode FPEXC == 0xc0000780 Internal error: Oops - undefined instruction: 0 [#1] ARM CPU: 0 PID: 196 Comm: vfp-reproducer Not tainted 6.10.0 #1 Hardware name: BCM2835 PC is at vfp_support_entry+0xc8/0x2cc LR is at do_undefinstr+0xa8/0x250 pc : [] lr : [] psr: a0000013 sp : dc8d1f68 ip : 60000013 fp : bedea19c r10: ec532b17 r9 : 00000010 r8 : 0044766c r7 : c0000780 r6 : ec532b17 r5 : c1c13800 r4 : dc8d1fb0 r3 : c10072c4 r2 : c0101c88 r1 : ec532b17 r0 : 0044766c Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 00c5387d Table: 0251c008 DAC: 00000051 Register r0 information: non-paged memory Register r1 information: vmalloc memory Register r2 information: non-slab/vmalloc memory Register r3 information: non-slab/vmalloc memory Register r4 information: 2-page vmalloc region Register r5 information: slab kmalloc-cg-2k Register r6 information: vmalloc memory Register r7 information: non-slab/vmalloc memory Register r8 information: non-paged memory Register r9 information: zero-size pointer Register r10 information: vmalloc memory Register r11 information: non-paged memory Register r12 information: non-paged memory Process vfp-reproducer (pid: 196, stack limit = 0x61aaaf8b) Stack: (0xdc8d1f68 to 0xdc8d2000) 1f60: 0000081f b6f69300 0000000f c10073f4 c10072c4 dc8d1fb0 1f80: ec532b17 0c532b17 0044766c b6f9ccd8 00000000 c010a80c 00447670 60000010 1fa0: ffffffff c1c13800 00c5387d c0100f10 b6f68af8 00448fc0 00000000 bedea188 1fc0: bedea314 00000001 00448ebc b6f9d000 00447608 b6f9ccd8 00000000 bedea19c 1fe0: bede9198 bedea188 b6e1061c 0044766c 60000010 ffffffff 00000000 00000000 Call trace: [] (vfp_support_entry) from [] (do_undefinstr+0xa8/0x250) [] (do_undefinstr) from [] (__und_usr+0x70/0x80) Exception stack(0xdc8d1fb0 to 0xdc8d1ff8) 1fa0: b6f68af8 00448fc0 00000000 bedea188 1fc0: bedea314 00000001 00448ebc b6f9d000 00447608 b6f9ccd8 00000000 bedea19c 1fe0: bede9198 bedea188 b6e1061c 0044766c 60000010 ffffffff Code: 0a000061 e3877202 e594003c e3a09010 (eef16a10) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Fatal exception in interrupt ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]--- This is a minimal userspace reproducer on a Raspberry Pi Zero W: #include #include int main(void) { double v = 1.0; printf(\"%fn\", NAN + *(volatile double *)&v); return 0; } Another way to consistently trigger the oops is: calvin@raspberry-pi-zero-w ~$ python -c \"import json\" The bug reproduces only when the kernel is built with DYNAMIC_DEBUG=n, because the pr_debug() calls act as barriers even when not activated. This is the output from the same kernel source built with the same compiler and DYNAMIC_DEBUG=y, where the userspace reproducer works as expected: VFP: bounce: trigger ec532b17 fpexc c0000780 VFP: emulate: INST=0xee377b06 SCR=0x00000000 VFP: bounce: trigger eef1fa10 fpexc c0000780 VFP: emulate: INST=0xeeb40b40 SCR=0x00000000 VFP: raising exceptions 30000000 calvin@raspberry-pi-zero-w ~$ ./vfp-reproducer nan Crudely grepping for vmsr/vmrs instructions in the otherwise nearly idential text for vfp_support_entry() makes the problem obvious: vmlinux.llvm.good [0xc0101cb8] <+48>: vmrs r7, fpexc vmlinux.llvm.good [0xc0101cd8] <+80>: vmsr fpexc, r0 vmlinux.llvm.good [0xc0101d20 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47717", "url": "https://ubuntu.com/security/CVE-2024-47717", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RISC-V: KVM: Don't zero-out PMU snapshot area before freeing data With the latest Linux-6.11-rc3, the below NULL pointer crash is observed when SBI PMU snapshot is enabled for the guest and the guest is forcefully powered-off. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000508 Oops [#1] Modules linked in: kvm CPU: 0 UID: 0 PID: 61 Comm: term-poll Not tainted 6.11.0-rc3-00018-g44d7178dd77a #3 Hardware name: riscv-virtio,qemu (DT) epc : __kvm_write_guest_page+0x94/0xa6 [kvm] ra : __kvm_write_guest_page+0x54/0xa6 [kvm] epc : ffffffff01590e98 ra : ffffffff01590e58 sp : ffff8f80001f39b0 gp : ffffffff81512a60 tp : ffffaf80024872c0 t0 : ffffaf800247e000 t1 : 00000000000007e0 t2 : 0000000000000000 s0 : ffff8f80001f39f0 s1 : 00007fff89ac4000 a0 : ffffffff015dd7e8 a1 : 0000000000000086 a2 : 0000000000000000 a3 : ffffaf8000000000 a4 : ffffaf80024882c0 a5 : 0000000000000000 a6 : ffffaf800328d780 a7 : 00000000000001cc s2 : ffffaf800197bd00 s3 : 00000000000828c4 s4 : ffffaf800248c000 s5 : ffffaf800247d000 s6 : 0000000000001000 s7 : 0000000000001000 s8 : 0000000000000000 s9 : 00007fff861fd500 s10: 0000000000000001 s11: 0000000000800000 t3 : 00000000000004d3 t4 : 00000000000004d3 t5 : ffffffff814126e0 t6 : ffffffff81412700 status: 0000000200000120 badaddr: 0000000000000508 cause: 000000000000000d [] __kvm_write_guest_page+0x94/0xa6 [kvm] [] kvm_vcpu_write_guest+0x56/0x90 [kvm] [] kvm_pmu_clear_snapshot_area+0x42/0x7e [kvm] [] kvm_riscv_vcpu_pmu_deinit.part.0+0xe0/0x14e [kvm] [] kvm_riscv_vcpu_pmu_deinit+0x1a/0x24 [kvm] [] kvm_arch_vcpu_destroy+0x28/0x4c [kvm] [] kvm_destroy_vcpus+0x5a/0xda [kvm] [] kvm_arch_destroy_vm+0x14/0x28 [kvm] [] kvm_destroy_vm+0x168/0x2a0 [kvm] [] kvm_put_kvm+0x3c/0x58 [kvm] [] kvm_vm_release+0x22/0x2e [kvm] Clearly, the kvm_vcpu_write_guest() function is crashing because it is being called from kvm_pmu_clear_snapshot_area() upon guest tear down. To address the above issue, simplify the kvm_pmu_clear_snapshot_area() to not zero-out PMU snapshot area from kvm_pmu_clear_snapshot_area() because the guest is anyway being tore down. The kvm_pmu_clear_snapshot_area() is also called when guest changes PMU snapshot area of a VCPU but even in this case the previous PMU snaphsot area must not be zeroed-out because the guest might have reclaimed the pervious PMU snapshot area for some other purpose.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47721", "url": "https://ubuntu.com/security/CVE-2024-47721", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: remove unused C2H event ID RTW89_MAC_C2H_FUNC_READ_WOW_CAM to prevent out-of-bounds reading The handler of firmware C2H event RTW89_MAC_C2H_FUNC_READ_WOW_CAM isn't implemented, but driver expects number of handlers is NUM_OF_RTW89_MAC_C2H_FUNC_WOW causing out-of-bounds access. Fix it by removing ID. Addresses-Coverity-ID: 1598775 (\"Out-of-bounds read\")", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47732", "url": "https://ubuntu.com/security/CVE-2024-47732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: iaa - Fix potential use after free bug The free_device_compression_mode(iaa_device, device_mode) function frees \"device_mode\" but it iss passed to iaa_compression_modes[i]->free() a few lines later resulting in a use after free. The good news is that, so far as I can tell, nothing implements the ->free() function and the use after free happens in dead code. But, with this fix, when something does implement it, we'll be ready. :)", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47718", "url": "https://ubuntu.com/security/CVE-2024-47718", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: always wait for both firmware loading attempts In 'rtw_wait_firmware_completion()', always wait for both (regular and wowlan) firmware loading attempts. Otherwise if 'rtw_usb_intf_init()' has failed in 'rtw_usb_probe()', 'rtw_usb_disconnect()' may issue 'ieee80211_free_hw()' when one of 'rtw_load_firmware_cb()' (usually the wowlan one) is still in progress, causing UAF detected by KASAN.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47724", "url": "https://ubuntu.com/security/CVE-2024-47724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: use work queue to process beacon tx event Commit 3a415daa3e8b (\"wifi: ath11k: add P2P IE in beacon template\") from Feb 28, 2024 (linux-next), leads to the following Smatch static checker warning: drivers/net/wireless/ath/ath11k/wmi.c:1742 ath11k_wmi_p2p_go_bcn_ie() warn: sleeping in atomic context The reason is that ath11k_bcn_tx_status_event() will directly call might sleep function ath11k_wmi_cmd_send() during RCU read-side critical sections. The call trace is like: ath11k_bcn_tx_status_event() -> rcu_read_lock() -> ath11k_mac_bcn_tx_event() \t-> ath11k_mac_setup_bcn_tmpl() \t…… \t\t-> ath11k_wmi_bcn_tmpl() \t\t\t-> ath11k_wmi_cmd_send() -> rcu_read_unlock() Commit 886433a98425 (\"ath11k: add support for BSS color change\") added the ath11k_mac_bcn_tx_event(), commit 01e782c89108 (\"ath11k: fix warning of RCU usage for ath11k_mac_get_arvif_by_vdev_id()\") added the RCU lock to avoid warning but also introduced this BUG. Use work queue to avoid directly calling ath11k_mac_bcn_tx_event() during RCU critical sections. No need to worry about the deletion of vif because cancel_work_sync() will drop the work if it doesn't start or block vif deletion until the running work is done. 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": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47671", "url": "https://ubuntu.com/security/CVE-2024-47671", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: usbtmc: prevent kernel-usb-infoleak The syzbot reported a kernel-usb-infoleak in usbtmc_write, we need to clear the structure before filling fields.", "cve_priority": "medium", "cve_public_date": "2024-10-09 15:15:00 UTC" }, { "cve": "CVE-2024-46869", "url": "https://ubuntu.com/security/CVE-2024-46869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btintel_pcie: Allocate memory for driver private data Fix driver not allocating memory for struct btintel_data which is used to store internal data.", "cve_priority": "medium", "cve_public_date": "2024-09-30 16:15:00 UTC" }, { "cve": "CVE-2024-53164", "url": "https://ubuntu.com/security/CVE-2024-53164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: fix ordering of qlen adjustment Changes to sch->q.qlen around qdisc_tree_reduce_backlog() need to happen _before_ a call to said function because otherwise it may fail to notify parent qdiscs when the child is about to become empty.", "cve_priority": "medium", "cve_public_date": "2024-12-27 14:15:00 UTC" }, { "cve": "CVE-2024-53103", "url": "https://ubuntu.com/security/CVE-2024-53103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hv_sock: Initializing vsk->trans to NULL to prevent a dangling pointer When hvs is released, there is a possibility that vsk->trans may not be initialized to NULL, which could lead to a dangling pointer. This issue is resolved by initializing vsk->trans to NULL.", "cve_priority": "high", "cve_public_date": "2024-12-02 08:15:00 UTC" } ], "log": [ "", " * oracular/linux: 6.11.0-17.17 -proposed tracker (LP: #2093643)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/2025.01.13)", "", " * When /dev/vmbus/hv_kvp is not present, disable hv-kvp-daemon (LP: #2091744)", " - [Packaging] disable hv-kvp-daemon if needed", "", " * Backport \"netkit: Add option for scrubbing skb meta data\" to 6.8", " (LP: #2091184)", " - netkit: Add option for scrubbing skb meta data", "", " * KVM: Cache CPUID at KVM.ko module init to reduce latency of VM-Enter and VM-", " Exit (LP: #2093146)", " - KVM: x86: Cache CPUID.0xD XSTATE offsets+sizes during module init", "", " * [SRU] add support of QCA BT 0489:e0fc (LP: #2085406)", " - Bluetooth: btusb: add Foxconn 0xe0fc for Qualcomm WCN785x", "", " * oracular: ubuntu_boot lib/dynamic_queue_limits.c:99! (LP: #2089684)", " - virtio_net: correct netdev_tx_reset_queue() invocation point", " - virtio_ring: add a func argument 'recycle_done' to virtqueue_resize()", " - virtio_net: ensure netdev_tx_reset_queue is called on tx ring resize", "", " * Failed to probe for OVTI02C1: chip id mismatch: 560243!=0 (LP: #2090932)", " - SAUCE: ACPI: scan: Update HID for new platform", "", " * Bluetooth[8086:a876] crash with \"hci0: Failed to read MSFT supported", " features (-110)\" (LP: #2085485)", " - Bluetooth: btintel_pcie: Add recovery mechanism", "", " * Poor bluetooth performance on Lenovo X13s (LP: #2089357)", " - SAUCE: Bluetooth: qca: Support downloading board ID specific NVM for WCN6855", "", " * vfio_pci soft lockup on VM start while using PCIe passthrough (LP: #2089306)", " - SAUCE: Revert \"mm: use rwsem assertion macros for mmap_lock\"", " - SAUCE: Revert \"vfio/pci: Insert full vma on mmap'd MMIO fault\"", " - SAUCE: Revert \"vfio/pci: Use unmap_mapping_range()\"", "", " * Oracular update: v6.11.11 upstream stable release (LP: #2091655)", " - wifi: mac80211: Fix setting txpower with emulate_chanctx", " - wifi: cfg80211: Add wiphy_delayed_work_pending()", " - wifi: mac80211: Convert color collision detection to wiphy work", " - wifi: radiotap: Avoid -Wflex-array-member-not-at-end warnings", " - spi: stm32: fix missing device mode capability in stm32mp25", " - ASoC: codecs: rt5640: Always disable IRQs from rt5640_cancel_work()", " - ASoC: Intel: bytcr_rt5640: Add support for non ACPI instantiated codec", " - ASoC: Intel: bytcr_rt5640: Add DMI quirk for Vexia Edu Atla 10 tablet", " - ASoC: Intel: sst: Support LPE0F28 ACPI HID", " - wifi: iwlwifi: mvm: Use the sync timepoint API in suspend", " - wifi: iwlwifi: mvm: SAR table alignment", " - mac80211: fix user-power when emulating chanctx", " - usb: add support for new USB device ID 0x17EF:0x3098 for the r8152 driver", " - usb: typec: use cleanup facility for 'altmodes_node'", " - selftests/watchdog-test: Fix system accidentally reset after watchdog-test", " - ALSA: hda/realtek: Add subwoofer quirk for Infinix ZERO BOOK 13", " - ASoC: codecs: wcd937x: add missing LO Switch control", " - ASoC: codecs: wcd937x: relax the AUX PDM watchdog", " - x86/amd_nb: Fix compile-testing without CONFIG_AMD_NB", " - bpf: fix filed access without lock", " - net: usb: qmi_wwan: add Quectel RG650V", " - soc: qcom: Add check devm_kasprintf() returned value", " - firmware: arm_scmi: Reject clear channel request on A2P", " - regulator: rk808: Add apply_bit for BUCK3 on RK809", " - platform/x86: dell-smbios-base: Extends support to Alienware products", " - platform/x86: dell-wmi-base: Handle META key Lock/Unlock events", " - platform/x86: ideapad-laptop: add missing Ideapad Pro 5 fn keys", " - ASoC: tas2781: Add new driver version for tas2563 & tas2781 qfn chip", " - tools/lib/thermal: Remove the thermal.h soft link when doing make clean", " - can: j1939: fix error in J1939 documentation.", " - platform/x86: thinkpad_acpi: Fix for ThinkPad's with ECFW showing incorrect", " fan speed", " - ASoC: amd: yc: Support dmic on another model of Lenovo Thinkpad E14 Gen 6", " - ASoC: stm: Prevent potential division by zero in stm32_sai_mclk_round_rate()", " - ASoC: stm: Prevent potential division by zero in stm32_sai_get_clk_div()", " - drm: panel-orientation-quirks: Make Lenovo Yoga Tab 3 X90F DMI match less", " strict", " - proc/softirqs: replace seq_printf with seq_put_decimal_ull_width", " - integrity: Use static_assert() to check struct sizes", " - ASoC: audio-graph-card2: Purge absent supplies for device tree nodes", " - LoongArch: For all possible CPUs setup logical-physical CPU mapping", " - LoongArch: Define a default value for VM_DATA_DEFAULT_FLAGS", " - ASoC: max9768: Fix event generation for playback mute", " - ALSA: usb-audio: Fix Yamaha P-125 Quirk Entry", " - ARM: 9420/1: smp: Fix SMP for xip kernels", " - ARM: 9434/1: cfi: Fix compilation corner case", " - ipmr: Fix access to mfc_cache_list without lock held", " - f2fs: fix fiemap failure issue when page size is 16KB", " - drm/amd/display: Skip Invalid Streams from DSC Policy", " - drm/amd/display: Fix incorrect DSC recompute trigger", " - s390/facilities: Fix warning about shadow of global variable", " - efs: fix the efs new mount api implementation", " - arm64: probes: Disable kprobes/uprobes on MOPS instructions", " - kselftest/arm64: hwcap: fix f8dp2 cpuinfo name", " - kselftest/arm64: mte: fix printf type warnings about __u64", " - kselftest/arm64: mte: fix printf type warnings about longs", " - block/fs: Pass an iocb to generic_atomic_write_valid()", " - fs/block: Check for IOCB_DIRECT in generic_atomic_write_valid()", " - s390/cio: Do not unregister the subchannel based on DNV", " - s390/pageattr: Implement missing kernel_page_present()", " - x86/pvh: Set phys_base when calling xen_prepare_pvh()", " - x86/pvh: Call C code via the kernel virtual mapping", " - brd: defer automatic disk creation until module initialization succeeds", " - ext4: avoid remount errors with 'abort' mount option", " - mips: asm: fix warning when disabling MIPS_FP_SUPPORT", " - arm64: Expose ID_AA64ISAR1_EL1.XS to sanitised feature consumers", " - kselftest/arm64: Fix encoding for SVE B16B16 test", " - nvme-pci: fix freeing of the HMB descriptor table", " - m68k: mvme147: Fix SCSI controller IRQ numbers", " - m68k: mvme147: Reinstate early console", " - arm64: fix .data.rel.ro size assertion when CONFIG_LTO_CLANG", " - acpi/arm64: Adjust error handling procedure in gtdt_parse_timer_block()", " - loop: fix type of block size", " - cachefiles: Fix incorrect length return value in", " cachefiles_ondemand_fd_write_iter()", " - cachefiles: Fix missing pos updates in cachefiles_ondemand_fd_write_iter()", " - cachefiles: Fix NULL pointer dereference in object->file", " - netfs/fscache: Add a memory barrier for FSCACHE_VOLUME_CREATING", " - block: constify the lim argument to queue_limits_max_zone_append_sectors", " - block: properly handle REQ_OP_ZONE_APPEND in __bio_split_to_limits", " - block: take chunk_sectors into account in bio_split_write_zeroes", " - block: fix bio_split_rw_at to take zone_write_granularity into account", " - s390/syscalls: Avoid creation of arch/arch/ directory", " - hfsplus: don't query the device logical block size multiple times", " - ext4: pipeline buffer reads in mext_page_mkuptodate()", " - ext4: remove array of buffer_heads from mext_page_mkuptodate()", " - ext4: fix race in buffer_head read fault injection", " - nvme-pci: reverse request order in nvme_queue_rqs", " - virtio_blk: reverse request order in virtio_queue_rqs", " - crypto: mxs-dcp - Fix AES-CBC with hardware-bound keys", " - crypto: caam - Fix the pointer passed to caam_qi_shutdown()", " - crypto: qat - remove check after debugfs_create_dir()", " - crypto: qat/qat_420xx - fix off by one in uof_get_name()", " - crypto: qat/qat_4xxx - fix off by one in uof_get_name()", " - firmware: google: Unregister driver_info on failure", " - EDAC/bluefield: Fix potential integer overflow", " - crypto: qat - remove faulty arbiter config reset", " - thermal: core: Initialize thermal zones before registering them", " - thermal: core: Drop thermal_zone_device_is_enabled()", " - thermal: core: Rearrange PM notification code", " - thermal: core: Represent suspend-related thermal zone flags as bits", " - thermal: core: Mark thermal zones as initializing to start with", " - thermal: core: Fix race between zone registration and system suspend", " - EDAC/fsl_ddr: Fix bad bit shift operations", " - EDAC/skx_common: Differentiate memory error sources", " - EDAC/{skx_common,i10nm}: Fix incorrect far-memory error source indicator", " - crypto: pcrypt - Call crypto layer directly when padata_do_parallel() return", " -EBUSY", " - crypto: cavium - Fix the if condition to exit loop after timeout", " - cpufreq/amd-pstate: Don't update CPPC request in", " amd_pstate_cpu_boost_update()", " - amd-pstate: Set min_perf to nominal_perf for active mode performance gov", " - crypto: hisilicon/qm - disable same error report before resetting", " - EDAC/igen6: Avoid segmentation fault on module unload", " - crypto: qat - Fix missing destroy_workqueue in adf_init_aer()", " - crypto: inside-secure - Fix the return value of safexcel_xcbcmac_cra_init()", " - sched/cpufreq: Ensure sd is rebuilt for EAS check", " - doc: rcu: update printed dynticks counter bits", " - rcu/srcutiny: don't return before reenabling preemption", " - rcu/kvfree: Fix data-race in __mod_timer / kvfree_call_rcu", " - hwmon: (pmbus/core) clear faults after setting smbalert mask", " - hwmon: (nct6775-core) Fix overflows seen when writing limit attributes", " - ACPI: CPPC: Fix _CPC register setting issue", " - crypto: caam - add error check to caam_rsa_set_priv_key_form", " - crypto: bcm - add error check in the ahash_hmac_init function", " - crypto: cavium - Fix an error handling path in cpt_ucode_load_fw()", " - rcuscale: Do a proper cleanup if kfree_scale_init() fails", " - tools/lib/thermal: Make more generic the command encoding function", " - thermal/lib: Fix memory leak on error in thermal_genl_auto()", " - x86/unwind/orc: Fix unwind for newly forked tasks", " - Revert \"scripts/faddr2line: Check only two symbols when calculating symbol", " size\"", " - cleanup: Remove address space of returned pointer", " - time: Partially revert cleanup on msecs_to_jiffies() documentation", " - time: Fix references to _msecs_to_jiffies() handling of values", " - locking/atomic/x86: Use ALT_OUTPUT_SP() for __alternative_atomic64()", " - locking/atomic/x86: Use ALT_OUTPUT_SP() for __arch_{,try_}cmpxchg64_emu()", " - kcsan, seqlock: Support seqcount_latch_t", " - kcsan, seqlock: Fix incorrect assumption in read_seqbegin()", " - clocksource/drivers:sp804: Make user selectable", " - clocksource/drivers/timer-ti-dm: Fix child node refcount handling", " - regulator: qcom-smd: make smd_vreg_rpm static", " - spi: spi-fsl-lpspi: Use IRQF_NO_AUTOEN flag in request_irq()", " - arm64: dts: qcom: qcs6390-rb3gen2: use modem.mbn for modem DSP", " - ARM: dts: renesas: genmai: Fix partition size for QSPI NOR Flash", " - drivers: soc: xilinx: add the missing kfree in xlnx_add_cb_for_suspend()", " - microblaze: Export xmb_manager functions", " - arm64: dts: mediatek: mt8188: Fix wrong clock provider in MFG1 power domain", " - arm64: dts: mediatek: mt8395-genio-1200-evk: Fix dtbs_check error for phy", " - arm64: dts: mt8195: Fix dtbs_check error for mutex node", " - arm64: dts: mt8195: Fix dtbs_check error for infracfg_ao node", " - soc: ti: smartreflex: Use IRQF_NO_AUTOEN flag in request_irq()", " - soc: qcom: geni-se: fix array underflow in geni_se_clk_tbl_get()", " - arm64: dts: qcom: sm6350: Fix GPU frequencies missing on some speedbins", " - arm64: dts: qcom: sda660-ifc6560: fix l10a voltage ranges", " - ARM: dts: microchip: sam9x60: Add missing property atmel,usart-mode", " - mmc: mmc_spi: drop buggy snprintf()", " - scripts/kernel-doc: Do not track section counter across processed files", " - arm64: dts: qcom: x1e80100-slim7x: Drop orientation-switch from USB SS[0-1]", " QMP PHYs", " - arm64: dts: qcom: x1e80100-vivobook-s15: Drop orientation-switch from USB", " SS[0-1] QMP PHYs", " - openrisc: Implement fixmap to fix earlycon", " - efi/libstub: fix efi_parse_options() ignoring the default command line", " - tpm: fix signed/unsigned bug when checking event logs", " - media: i2c: vgxy61: Fix an error handling path in vgxy61_detect()", " - media: i2c: ds90ub960: Fix missing return check on ub960_rxport_read call", " - arm64: dts: mt8183: krane: Fix the address of eeprom at i2c4", " - arm64: dts: mt8183: kukui: Fix the address of eeprom at i2c4", " - arm64: dts: qcom: x1e80100: Resize GIC Redistributor register region", " - kernel-doc: allow object-like macros in ReST output", " - arm64: dts: ti: k3-am62x-phyboard-lyra: Drop unnecessary McASP AFIFOs", " - arm64: dts: mediatek: mt8173-elm-hana: Add vdd-supply to second source", " trackpad", " - arm64: dts: mediatek: mt8188: Fix USB3 PHY port default status", " - arm64: dts: mediatek: mt8195-cherry: Use correct audio codec DAI", " - Revert \"cgroup: Fix memory leak caused by missing cgroup_bpf_offline\"", " - cgroup/bpf: only cgroup v2 can be attached by bpf programs", " - regulator: rk808: Restrict DVS GPIOs to the RK808 variant only", " - power: sequencing: make the QCom PMU pwrseq driver depend on CONFIG_OF", " - [Config] updateconfigs for POWER_SEQUENCING_QCOM_WCN", " - arm64: dts: rockchip: Remove 'enable-active-low' from two boards", " - arm64: dts: mt8183: fennel: add i2c2's i2c-scl-internal-delay-ns", " - arm64: dts: mt8183: burnet: add i2c2's i2c-scl-internal-delay-ns", " - arm64: dts: mt8183: cozmo: add i2c2's i2c-scl-internal-delay-ns", " - arm64: dts: mt8183: Damu: add i2c2's i2c-scl-internal-delay-ns", " - pwm: imx27: Workaround of the pwm output bug when decrease the duty cycle", " - ARM: dts: cubieboard4: Fix DCDC5 regulator constraints", " - arm64: dts: ti: k3-j7200: Fix register map for main domain pmx", " - arm64: dts: ti: k3-j7200: Fix clock ids for MCSPI instances", " - arm64: dts: ti: k3-j721e: Fix clock IDs for MCSPI instances", " - arm64: dts: ti: k3-j721s2: Fix clock IDs for MCSPI instances", " - watchdog: Add HAS_IOPORT dependency for SBC8360 and SBC7240", " - arm64: dts: qcom: x1e80100: Update C4/C5 residency/exit numbers", " - dt-bindings: cache: qcom,llcc: Fix X1E80100 reg entries", " - of/fdt: add dt_phys arg to early_init_dt_scan and early_init_dt_verify", " - pmdomain: ti-sci: Add missing of_node_put() for args.np", " - spi: tegra210-quad: Avoid shift-out-of-bounds", " - spi: zynqmp-gqspi: Undo runtime PM changes at driver exit time​", " - regmap: irq: Set lockdep class for hierarchical IRQ domains", " - arm64: dts: renesas: hihope: Drop #sound-dai-cells", " - arm64: dts: imx8mn-tqma8mqnl-mba8mx-usbot: fix coexistence of output-low and", " output-high in GPIO", " - arm64: dts: mediatek: Add ADC node on MT6357, MT6358, MT6359 PMICs", " - arm64: dts: mediatek: mt6358: fix dtbs_check error", " - arm64: dts: mediatek: mt8183-kukui-jacuzzi: Fix DP bridge supply names", " - arm64: dts: mediatek: mt8183-kukui-jacuzzi: Add supplies for fixed", " regulators", " - selftests/resctrl: Print accurate buffer size as part of MBM results", " - selftests/resctrl: Fix memory overflow due to unhandled wraparound", " - selftests/resctrl: Protect against array overrun during iMC config parsing", " - firmware: arm_scpi: Check the DVFS OPP count returned by the firmware", " - media: ipu6: Fix DMA and physical address debugging messages for 32-bit", " - media: ipu6: not override the dma_ops of device in driver", " - pwm: Assume a disabled PWM to emit a constant inactive output", " - media: atomisp: Add check for rgby_data memory allocation failure", " - arm64: dts: rockchip: correct analog audio name on Indiedroid Nova", " - HID: hyperv: streamline driver probe to avoid devres issues", " - platform/x86: panasonic-laptop: Return errno correctly in show callback", " - drm/imagination: Convert to use time_before macro", " - drm/imagination: Use pvr_vm_context_get()", " - drm/mm: Mark drm_mm_interval_tree*() functions with __maybe_unused", " - drm/vc4: hvs: Don't write gamma luts on 2711", " - drm/vc4: hdmi: Avoid hang with debug registers when suspended", " - drm/vc4: hvs: Fix dlist debug not resetting the next entry pointer", " - drm/vc4: hvs: Remove incorrect limit from hvs_dlist debugfs function", " - drm/vc4: hvs: Correct logic on stopping an HVS channel", " - wifi: ath9k: add range check for conn_rsp_epid in htc_connect_service()", " - drm/omap: Fix possible NULL dereference", " - drm/omap: Fix locking in omap_gem_new_dmabuf()", " - drm/v3d: Appease lockdep while updating GPU stats", " - wifi: p54: Use IRQF_NO_AUTOEN flag in request_irq()", " - wifi: mwifiex: Use IRQF_NO_AUTOEN flag in request_irq()", " - udmabuf: change folios array from kmalloc to kvmalloc", " - udmabuf: fix vmap_udmabuf error page set", " - [Config] updateconfigs for VMAP_PFN", " - drm/imx/dcss: Use IRQF_NO_AUTOEN flag in request_irq()", " - drm/imx/ipuv3: Use IRQF_NO_AUTOEN flag in request_irq()", " - drm/panel: nt35510: Make new commands optional", " - drm/v3d: Address race-condition in MMU flush", " - drm/v3d: Flush the MMU before we supply more memory to the binner", " - drm/amdgpu: Fix JPEG v4.0.3 register write", " - wifi: ath10k: fix invalid VHT parameters in supported_vht_mcs_rate_nss1", " - wifi: ath10k: fix invalid VHT parameters in supported_vht_mcs_rate_nss2", " - wifi: ath12k: Skip Rx TID cleanup for self peer", " - dt-bindings: vendor-prefixes: Add NeoFidelity, Inc", " - ASoC: fsl_micfil: fix regmap_write_bits usage", " - ASoC: dt-bindings: mt6359: Update generic node name and dmic-mode", " - ASoC: fsl-asoc-card: Add missing handling of {hp,mic}-dt-gpios", " - drm/bridge: anx7625: Drop EDID cache on bridge power off", " - drm/bridge: it6505: Drop EDID cache on bridge power off", " - libbpf: Fix expected_attach_type set handling in program load callback", " - libbpf: Fix output .symtab byte-order during linking", " - dlm: fix swapped args sb_flags vs sb_status", " - wifi: rtl8xxxu: Perform update_beacon_work when beaconing is enabled", " - drm/amd/display: fix a memleak issue when driver is removed", " - wifi: ath12k: fix use-after-free in ath12k_dp_cc_cleanup()", " - wifi: ath12k: fix one more memcpy size error", " - bpf: Fix the xdp_adjust_tail sample prog issue", " - selftests/bpf: netns_new() and netns_free() helpers.", " - selftests/bpf: Fix backtrace printing for selftests crashes", " - wifi: ath11k: Fix CE offset address calculation for WCN6750 in SSR", " - selftests/bpf: add missing header include for htons", " - wifi: cfg80211: check radio iface combination for multi radio per wiphy", " - ice: consistently use q_idx in ice_vc_cfg_qs_msg()", " - drm/vc4: hdmi: Increase audio MAI fifo dreq threshold", " - drm/vc4: Introduce generation number enum", " - drm/vc4: Match drm_dev_enter and exit calls in vc4_hvs_lut_load", " - drm/vc4: Match drm_dev_enter and exit calls in vc4_hvs_atomic_flush", " - drm/vc4: Correct generation check in vc4_hvs_lut_load", " - libbpf: fix sym_is_subprog() logic for weak global subprogs", " - accel/ivpu: Prevent recovery invocation during probe and resume", " - ASoC: rt722-sdca: Remove logically deadcode in rt722-sdca.c", " - libbpf: never interpret subprogs in .text as entry programs", " - netdevsim: copy addresses for both in and out paths", " - drm/bridge: tc358767: Fix link properties discovery", " - selftests/bpf: Fix msg_verify_data in test_sockmap", " - selftests/bpf: Fix txmsg_redir of test_txmsg_pull in test_sockmap", " - wifi: wilc1000: Set MAC after operation mode", " - wifi: mwifiex: Fix memcpy() field-spanning write warning in", " mwifiex_config_scan()", " - drm: fsl-dcu: enable PIXCLK on LS1021A", " - drm: panel: nv3052c: correct spi_device_id for RG35XX panel", " - drm/msm/dpu: on SDM845 move DSPP_3 to LM_5 block", " - drm/msm/dpu: drop LM_3 / LM_4 on SDM845", " - drm/msm/dpu: drop LM_3 / LM_4 on MSM8998", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_common.c", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_ethtool.c", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_flows.c", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in cn10k.c", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dmac_flt.c", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dcbnl.c", " - selftests/bpf: fix test_spin_lock_fail.c's global vars usage", " - libbpf: move global data mmap()'ing into bpf_object__load()", " - drm/panfrost: Remove unused id_mask from struct panfrost_model", " - bpf, arm64: Remove garbage frame for struct_ops trampoline", " - drm/msm/adreno: Use IRQF_NO_AUTOEN flag in request_irq()", " - drm/msm/gpu: Check the status of registration to PM QoS", " - drm/xe/hdcp: Fix gsc structure check in fw check status", " - drm/etnaviv: Request pages from DMA32 zone on addressing_limited", " - drm/etnaviv: hold GPU lock across perfmon sampling", " - drm/amd/display: Increase idle worker HPD detection time", " - drm/amd/display: Reduce HPD Detection Interval for IPS", " - drm/nouveau/gr/gf100: Fix missing unlock in gf100_gr_chan_new()", " - drm: zynqmp_kms: Unplug DRM device before removal", " - drm: xlnx: zynqmp_disp: layer may be null while releasing", " - wifi: wfx: Fix error handling in wfx_core_init()", " - wifi: cw1200: Fix potential NULL dereference", " - drm/msm/dpu: cast crtc_clk calculation to u64 in _dpu_core_perf_calc_clk()", " - bpf, bpftool: Fix incorrect disasm pc", " - bpf: Tighten tail call checks for lingering locks, RCU, preempt_disable", " - drm/vkms: Drop unnecessary call to drm_crtc_cleanup()", " - drm/amdgpu: Fix the memory allocation issue in", " amdgpu_discovery_get_nps_info()", " - bpf: Support __nullable argument suffix for tp_btf", " - selftests/bpf: Add test for __nullable suffix in tp_btf", " - bpf: Mark raw_tp arguments with PTR_MAYBE_NULL", " - drm: use ATOMIC64_INIT() for atomic64_t", " - netfilter: nf_tables: avoid false-positive lockdep splat on rule deletion", " - netfilter: nf_tables: must hold rcu read lock while iterating expression", " type list", " - netfilter: nf_tables: must hold rcu read lock while iterating object type", " list", " - netlink: typographical error in nlmsg_type constants definition", " - wifi: rtw89: coex: check NULL return of kmalloc in btc_fw_set_monreg()", " - drm/panfrost: Add missing OPP table refcnt decremental", " - drm/panthor: introduce job cycle and timestamp accounting", " - drm/panthor: record current and maximum device clock frequencies", " - drm/panthor: Fix OPP refcnt leaks in devfreq initialisation", " - isofs: avoid memory leak in iocharset", " - selftests/bpf: Add txmsg_pass to pull/push/pop in test_sockmap", " - selftests/bpf: Fix SENDPAGE data logic in test_sockmap", " - selftests/bpf: Fix total_bytes in msg_loop_rx in test_sockmap", " - selftests/bpf: Add push/pop checking for msg_verify_data in test_sockmap", " - bpf, sockmap: Several fixes to bpf_msg_push_data", " - bpf, sockmap: Several fixes to bpf_msg_pop_data", " - bpf, sockmap: Fix sk_msg_reset_curr", " - ipv6: release nexthop on device removal", " - selftests: net: really check for bg process completion", " - wifi: cfg80211: Remove the Medium Synchronization Delay validity check", " - wifi: iwlwifi: allow fast resume on ax200", " - wifi: iwlwifi: mvm: tell iwlmei when we finished suspending", " - drm/amdgpu: fix ACA bank count boundary check error", " - drm/amdgpu: Fix map/unmap queue logic", " - drm/amdkfd: Fix wrong usage of INIT_WORK()", " - bpf: Allow return values 0 and 1 for kprobe session", " - bpf: Force uprobe bpf program to always return 0", " - selftests/bpf: skip the timer_lockup test for single-CPU nodes", " - ipv6: Fix soft lockups in fib6_select_path under high next hop churn", " - net: rfkill: gpio: Add check for clk_enable()", " - Revert \"wifi: iwlegacy: do not skip frames with bad FCS\"", " - bpf: Use function pointers count as struct_ops links count", " - bpf: Add kernel symbol for struct_ops trampoline", " - ALSA: usx2y: Use snd_card_free_when_closed() at disconnection", " - ALSA: us122l: Use snd_card_free_when_closed() at disconnection", " - ALSA: caiaq: Use snd_card_free_when_closed() at disconnection", " - ALSA: 6fire: Release resources at card release", " - i2c: dev: Fix memory leak when underlying adapter does not support I2C", " - selftests: netfilter: Fix missing return values in conntrack_dump_flush", " - Bluetooth: btintel_pcie: Add handshake between driver and firmware", " - Bluetooth: btintel: Do no pass vendor events to stack", " - Bluetooth: btmtk: adjust the position to init iso data anchor", " - Bluetooth: btbcm: fix missing of_node_put() in btbcm_get_board_name()", " - Bluetooth: ISO: Use kref to track lifetime of iso_conn", " - Bluetooth: ISO: Do not emit LE PA Create Sync if previous is pending", " - Bluetooth: ISO: Do not emit LE BIG Create Sync if previous is pending", " - Bluetooth: ISO: Send BIG Create Sync via hci_sync", " - Bluetooth: fix use-after-free in device_for_each_child()", " - xsk: Free skb when TX metadata options are invalid", " - erofs: handle NONHEAD !delta[1] lclusters gracefully", " - dlm: fix dlm_recover_members refcount on error", " - eth: fbnic: don't disable the PCI device twice", " - net: txgbe: remove GPIO interrupt controller", " - net: txgbe: fix null pointer to pcs", " - netpoll: Use rcu_access_pointer() in netpoll_poll_lock", " - wireguard: selftests: load nf_conntrack if not present", " - bpf: fix recursive lock when verdict program return SK_PASS", " - unicode: Fix utf8_load() error path", " - cppc_cpufreq: Use desired perf if feedback ctrs are 0 or unchanged", " - RDMA/core: Provide rdma_user_mmap_disassociate() to disassociate mmap pages", " - RDMA/hns: Disassociate mmap pages for all uctx when HW is being reset", " - clk: mediatek: drop two dead config options", " - [Config] drop COMMON_CLK_MT8195_{AUDSYS,MSDC}", " - trace/trace_event_perf: remove duplicate samples on the first tracepoint", " event", " - pinctrl: zynqmp: drop excess struct member description", " - pinctrl: renesas: Select PINCTRL_RZG2L for RZ/V2H(P) SoC", " - clk: qcom: videocc-sm8550: depend on either gcc-sm8550 or gcc-sm8650", " - iommu/s390: Implement blocking domain", " - scsi: hisi_sas: Enable all PHYs that are not disabled by user during", " controller reset", " - powerpc/vdso: Flag VDSO64 entry points as functions", " - mfd: tps65010: Use IRQF_NO_AUTOEN flag in request_irq() to fix race", " - mfd: da9052-spi: Change read-mask to write-mask", " - mfd: intel_soc_pmic_bxtwc: Use IRQ domain for USB Type-C device", " - mfd: intel_soc_pmic_bxtwc: Use IRQ domain for TMU device", " - mfd: intel_soc_pmic_bxtwc: Use IRQ domain for PMIC devices", " - irqdomain: Simplify simple and legacy domain creation", " - irqdomain: Cleanup domain name allocation", " - irqdomain: Allow giving name suffix for domain", " - regmap: Allow setting IRQ domain name suffix", " - mfd: intel_soc_pmic_bxtwc: Fix IRQ domain names duplication", " - cpufreq: loongson2: Unregister platform_driver on failure", " - powerpc/fadump: Refactor and prepare fadump_cma_init for late init", " - powerpc/fadump: Move fadump_cma_init to setup_arch() after initmem_init()", " - mtd: hyperbus: rpc-if: Add missing MODULE_DEVICE_TABLE", " - mtd: rawnand: atmel: Fix possible memory leak", " - powerpc/mm/fault: Fix kfence page fault reporting", " - clk: sophgo: avoid integer overflow in sg2042_pll_recalc_rate()", " - mtd: spi-nor: spansion: Use nor->addr_nbytes in octal DTR mode in", " RD_ANY_REG_OP", " - powerpc/pseries: Fix dtl_access_lock to be a rw_semaphore", " - cpufreq: CPPC: Fix possible null-ptr-deref for cpufreq_cpu_get_raw()", " - cpufreq: CPPC: Fix possible null-ptr-deref for cppc_get_cpu_cost()", " - iommu/amd: Remove amd_iommu_domain_update() from page table freeing", " - iommu/amd: Remove the amd_iommu_domain_set_pt_root() and related", " - iommu/amd: Rename struct amd_io_pgtable iopt to pgtbl", " - iommu/amd: Store the nid in io_pgtable_cfg instead of the domain", " - iommu/amd: Narrow the use of struct protection_domain to invalidation", " - iommu/amd/pgtbl_v2: Take protection domain lock before invalidating TLB", " - RDMA/hns: Fix an AEQE overflow error caused by untimely update of eq_db_ci", " - RDMA/hns: Fix flush cqe error when racing with destroy qp", " - RDMA/hns: Modify debugfs name", " - RDMA/hns: Use dev_* printings in hem code instead of ibdev_*", " - RDMA/hns: Fix cpu stuck caused by printings during reset", " - RDMA/rxe: Fix the qp flush warnings in req", " - RDMA/bnxt_re: Check cqe flags to know imm_data vs inv_irkey", " - clk: sunxi-ng: d1: Fix PLL_AUDIO0 preset", " - clk: renesas: rzg2l: Fix FOUTPOSTDIV clk", " - RDMA/rxe: Set queue pair cur_qp_state when being queried", " - RISC-V: KVM: Fix APLIC in_clrip and clripnum write emulation", " - riscv: kvm: Fix out-of-bounds array access", " - clk: imx: lpcg-scu: SW workaround for errata (e10858)", " - clk: imx: fracn-gppll: correct PLL initialization flow", " - clk: imx: fracn-gppll: fix pll power up", " - clk: imx: clk-scu: fix clk enable state save and restore", " - clk: imx: imx8-acm: Fix return value check in", " clk_imx_acm_attach_pm_domains()", " - iommu/vt-d: Fix checks and print in dmar_fault_dump_ptes()", " - iommu/vt-d: Fix checks and print in pgtable_walk()", " - checkpatch: always parse orig_commit in fixes tag", " - mfd: rt5033: Fix missing regmap_del_irq_chip()", " - leds: max5970: Fix unreleased fwnode_handle in probe function", " - leds: ktd2692: Set missing timing properties", " - fs/proc/kcore.c: fix coccinelle reported ERROR instances", " - scsi: target: Fix incorrect function name in pscsi_create_type_disk()", " - scsi: bfa: Fix use-after-free in bfad_im_module_exit()", " - scsi: fusion: Remove unused variable 'rc'", " - scsi: qedf: Fix a possible memory leak in qedf_alloc_and_init_sb()", " - scsi: qedi: Fix a possible memory leak in qedi_alloc_and_init_sb()", " - scsi: sg: Enable runtime power management", " - x86/tdx: Introduce wrappers to read and write TD metadata", " - x86/tdx: Rename tdx_parse_tdinfo() to tdx_setup()", " - x86/tdx: Dynamically disable SEPT violations from causing #VEs", " - powerpc/fadump: allocate memory for additional parameters early", " - fadump: reserve param area if below boot_mem_top", " - RDMA/hns: Fix out-of-order issue of requester when setting FENCE", " - RDMA/hns: Fix NULL pointer derefernce in hns_roce_map_mr_sg()", " - cpufreq: loongson3: Check for error code from devm_mutex_init() call", " - cpufreq: CPPC: Fix wrong return value in cppc_get_cpu_cost()", " - cpufreq: CPPC: Fix wrong return value in cppc_get_cpu_power()", " - kasan: move checks to do_strncpy_from_user", " - kunit: skb: use \"gfp\" variable instead of hardcoding GFP_KERNEL", " - ocfs2: fix uninitialized value in ocfs2_file_read_iter()", " - dax: delete a stale directory pmem", " - KVM: PPC: Book3S HV: Stop using vc->dpdes for nested KVM guests", " - KVM: PPC: Book3S HV: Avoid returning to nested hypervisor on pending", " doorbells", " - powerpc/sstep: make emulate_vsx_load and emulate_vsx_store static", " - RDMA/hns: Fix different dgids mapping to the same dip_idx", " - KVM: PPC: Book3S HV: Fix kmv -> kvm typo", " - powerpc/kexec: Fix return of uninitialized variable", " - fbdev: sh7760fb: Fix a possible memory leak in sh7760fb_alloc_mem()", " - RDMA/mlx5: Move events notifier registration to be after device registration", " - clk: clk-apple-nco: Add NULL check in applnco_probe", " - clk: ralink: mtmips: fix clock plan for Ralink SoC RT3883", " - clk: ralink: mtmips: fix clocks probe order in oldest ralink SoCs", " - clk: en7523: remove REG_PCIE*_{MEM,MEM_MASK} configuration", " - clk: en7523: move clock_register in hw_init callback", " - clk: en7523: introduce chip_scu regmap", " - clk: en7523: fix estimation of fixed rate for EN7581", " - dt-bindings: clock: axi-clkgen: include AXI clk", " - clk: clk-axi-clkgen: make sure to enable the AXI bus clock", " - arm64: dts: qcom: sc8180x: Add a SoC-specific compatible to cpufreq-hw", " - pinctrl: k210: Undef K210_PC_DEFAULT", " - rtla/timerlat: Do not set params->user_workload with -U", " - smb: cached directories can be more than root file handle", " - mailbox: mtk-cmdq: fix wrong use of sizeof in cmdq_get_clocks()", " - mailbox: arm_mhuv2: clean up loop in get_irq_chan_comb()", " - x86: fix off-by-one in access_ok()", " - perf cs-etm: Don't flush when packet_queue fills up", " - gfs2: Rename GLF_VERIFY_EVICT to GLF_VERIFY_DELETE", " - gfs2: Allow immediate GLF_VERIFY_DELETE work", " - gfs2: Fix unlinked inode cleanup", " - perf test: Add test for Intel TPEBS counting mode", " - perf mem: Fix printing PERF_MEM_LVLNUM_{L2_MHB|MSC}", " - PCI: Fix reset_method_store() memory leak", " - perf stat: Close cork_fd when create_perf_stat_counter() failed", " - perf stat: Fix affinity memory leaks on error path", " - perf trace: Keep exited threads for summary", " - perf test attr: Add back missing topdown events", " - f2fs: compress: fix inconsistent update of i_blocks in", " release_compress_blocks and reserve_compress_blocks", " - f2fs: fix null-ptr-deref in f2fs_submit_page_bio()", " - f2fs: fix to account dirty data in __get_secs_required()", " - perf dso: Fix symtab_type for kmod compression", " - perf probe: Fix libdw memory leak", " - perf probe: Correct demangled symbols in C++ program", " - rust: kernel: fix THIS_MODULE header path in ThisModule doc comment", " - rust: macros: fix documentation of the paste! macro", " - PCI: cpqphp: Use PCI_POSSIBLE_ERROR() to check config reads", " - PCI: cpqphp: Fix PCIBIOS_* return value confusion", " - rust: block: fix formatting of `kernel::block::mq::request` module", " - perf disasm: Use disasm_line__free() to properly free disasm_line", " - virtiofs: use pages instead of pointer for kernel direct IO", " - perf ftrace latency: Fix unit on histogram first entry when using --use-nsec", " - i3c: master: Remove i3c_dev_disable_ibi_locked(olddev) on device hotjoin", " - f2fs: fix the wrong f2fs_bug_on condition in f2fs_do_replace_block", " - f2fs: check curseg->inited before write_sum_page in change_curseg", " - f2fs: Fix not used variable 'index'", " - f2fs: fix to avoid potential deadlock in f2fs_record_stop_reason()", " - f2fs: fix to avoid use GC_AT when setting gc_mode as GC_URGENT_LOW or", " GC_URGENT_MID", " - PCI: qcom-ep: Move controller cleanups to qcom_pcie_perst_deassert()", " - PCI: tegra194: Move controller cleanups to pex_ep_event_pex_rst_deassert()", " - PCI: cadence: Extract link setup sequence from cdns_pcie_host_setup()", " - PCI: cadence: Set cdns_pcie_host_init() global", " - PCI: j721e: Add reset GPIO to struct j721e_pcie", " - PCI: j721e: Use T_PERST_CLK_US macro", " - PCI: j721e: Add suspend and resume support", " - PCI: j721e: Deassert PERST# after a delay of PCIE_T_PVPERL_MS milliseconds", " - perf build: Add missing cflags when building with custom libtraceevent", " - f2fs: fix race in concurrent f2fs_stop_gc_thread", " - f2fs: fix to map blocks correctly for direct write", " - f2fs: fix to avoid forcing direct write to use buffered IO on inline_data", " inode", " - perf trace: avoid garbage when not printing a trace event's arguments", " - m68k: mcfgpio: Fix incorrect register offset for CONFIG_M5441x", " - m68k: coldfire/device.c: only build FEC when HW macros are defined", " - svcrdma: Address an integer overflow", " - nfsd: drop inode parameter from nfsd4_change_attribute()", " - perf list: Fix topic and pmu_name argument order", " - perf trace: Fix tracing itself, creating feedback loops", " - perf trace: Do not lose last events in a race", " - perf trace: Avoid garbage when not printing a syscall's arguments", " - remoteproc: qcom: pas: Remove subdevs on the error path of adsp_probe()", " - remoteproc: qcom: adsp: Remove subdevs on the error path of adsp_probe()", " - remoteproc: qcom: pas: add minidump_id to SM8350 resources", " - rpmsg: glink: use only lower 16-bits of param2 for CMD_OPEN name length", " - remoteproc: qcom_q6v5_mss: Re-order writes to the IMEM region", " - PCI: endpoint: epf-mhi: Avoid NULL dereference if DT lacks 'mmio'", " - NFSD: Prevent NULL dereference in nfsd4_process_cb_update()", " - NFSD: Cap the number of bytes copied by nfs4_reset_recoverydir()", " - nfsd: release svc_expkey/svc_export with rcu_work", " - svcrdma: fix miss destroy percpu_counter in svc_rdma_proc_init()", " - NFSD: Fix nfsd4_shutdown_copy()", " - f2fs: clean up val{>>,<<}F2FS_BLKSIZE_BITS", " - f2fs: fix to do cast in F2FS_{BLK_TO_BYTES, BTYES_TO_BLK} to avoid overflow", " - hwmon: (tps23861) Fix reporting of negative temperatures", " - hwmon: (aquacomputer_d5next) Fix length of speed_input array", " - phy: airoha: Fix REG_CSR_2L_PLL_CMN_RESERVE0 config in", " airoha_pcie_phy_init_clk_out()", " - phy: airoha: Fix REG_PCIE_PMA_TX_RESET config in", " airoha_pcie_phy_init_csr_2l()", " - phy: airoha: Fix REG_CSR_2L_JCPLL_SDM_HREN config in", " airoha_pcie_phy_init_ssc_jcpll()", " - phy: airoha: Fix REG_CSR_2L_RX{0,1}_REV0 definitions", " - vdpa/mlx5: Fix suboptimal range on iotlb iteration", " - vfio/mlx5: Fix an unwind issue in mlx5vf_add_migration_pages()", " - vfio/mlx5: Fix unwind flows in mlx5vf_pci_save/resume_device_data()", " - selftests/mount_setattr: Fix failures on 64K PAGE_SIZE kernels", " - gpio: zevio: Add missed label initialisation", " - vfio/pci: Properly hide first-in-list PCIe extended capability", " - fs_parser: update mount_api doc to match function signature", " - LoongArch: Fix build failure with GCC 15 (-std=gnu23)", " - LoongArch: BPF: Sign-extend return values", " - power: supply: core: Remove might_sleep() from power_supply_put()", " - power: supply: bq27xxx: Fix registers of bq27426", " - power: supply: rt9471: Fix wrong WDT function regfield declaration", " - power: supply: rt9471: Use IC status regfield to report real charger status", " - net: usb: lan78xx: Fix double free issue with interrupt buffer allocation", " - net: usb: lan78xx: Fix memory leak on device unplug by freeing PHY device", " - tg3: Set coherent DMA mask bits to 31 for BCM57766 chipsets", " - net: usb: lan78xx: Fix refcounting and autosuspend on invalid WoL", " configuration", " - net: microchip: vcap: Add typegroup table terminators in kunit tests", " - netlink: fix false positive warning in extack during dumps", " - exfat: fix file being changed by unaligned direct write", " - s390/iucv: MSG_PEEK causes memory leak in iucv_sock_destruct()", " - net/ipv6: delete temporary address if mngtmpaddr is removed or unmanaged", " - net: mdio-ipq4019: add missing error check", " - marvell: pxa168_eth: fix call balance of pep->clk handling routines", " - net: stmmac: dwmac-socfpga: Set RX watchdog interrupt as broken", " - octeontx2-af: RPM: Fix mismatch in lmac type", " - octeontx2-af: RPM: Fix low network performance", " - octeontx2-af: RPM: fix stale RSFEC counters", " - octeontx2-af: RPM: fix stale FCFEC counters", " - octeontx2-af: Quiesce traffic before NIX block reset", " - spi: atmel-quadspi: Fix register name in verbose logging function", " - net: hsr: fix hsr_init_sk() vs network/transport headers.", " - bnxt_en: Reserve rings after PCIe AER recovery if NIC interface is down", " - bnxt_en: Set backplane link modes correctly for ethtool", " - bnxt_en: Fix receive ring space parameters when XDP is active", " - bnxt_en: Refactor bnxt_ptp_init()", " - bnxt_en: Unregister PTP during PCI shutdown and suspend", " - Bluetooth: MGMT: Fix slab-use-after-free Read in set_powered_sync", " - Bluetooth: MGMT: Fix possible deadlocks", " - llc: Improve setsockopt() handling of malformed user input", " - rxrpc: Improve setsockopt() handling of malformed user input", " - tcp: Fix use-after-free of nreq in reqsk_timer_handler().", " - ip6mr: fix tables suspicious RCU usage", " - ipmr: fix tables suspicious RCU usage", " - iio: light: al3010: Fix an error handling path in al3010_probe()", " - usb: using mutex lock and supporting O_NONBLOCK flag in iowarrior_read()", " - usb: yurex: make waiting on yurex_write interruptible", " - USB: chaoskey: fail open after removal", " - USB: chaoskey: Fix possible deadlock chaoskey_list_lock", " - misc: apds990x: Fix missing pm_runtime_disable()", " - devres: Fix page faults when tracing devres from unloaded modules", " - usb: gadget: uvc: wake pump everytime we update the free list", " - interconnect: qcom: icc-rpmh: probe defer incase of missing QoS clock", " dependency", " - phy: realtek: usb: fix NULL deref in rtk_usb2phy_probe", " - phy: realtek: usb: fix NULL deref in rtk_usb3phy_probe", " - counter: stm32-timer-cnt: Add check for clk_enable()", " - counter: ti-ecap-capture: Add check for clk_enable()", " - bus: mhi: host: Switch trace_mhi_gen_tre fields to native endian", " - usb: typec: fix potential array underflow in ucsi_ccg_sync_control()", " - firmware_loader: Fix possible resource leak in fw_log_firmware_info()", " - ALSA: hda/realtek: Update ALC256 depop procedure", " - drm/radeon: add helper rdev_to_drm(rdev)", " - drm/radeon: change rdev->ddev to rdev_to_drm(rdev)", " - drm/radeon: Fix spurious unplug event on radeon HDMI", " - drm/amd/display: Fix null check for pipe_ctx->plane_state in", " dcn20_program_pipe", " - drm/amd/display: Fix null check for pipe_ctx->plane_state in hwss_setup_dpp", " - ASoC: imx-audmix: Add NULL check in imx_audmix_probe", " - drm/xe/ufence: Wake up waiters after setting ufence->signalled", " - apparmor: fix 'Do simple duplicate message elimination'", " - ALSA: core: Fix possible NULL dereference caused by kunit_kzalloc()", " - ASoC: amd: yc: Fix for enabling DMIC on acp6x via _DSD entry", " - ASoC: mediatek: Check num_codecs is not zero to avoid panic during probe", " - s390/pci: Fix potential double remove of hotplug slot", " - net_sched: sch_fq: don't follow the fast path if Tx is behind now", " - xen: Fix the issue of resource not being properly released in", " xenbus_dev_probe()", " - ALSA: usb-audio: Fix potential out-of-bound accesses for Extigy and Mbox", " devices", " - ALSA: usb-audio: Fix out of bounds reads when finding clock sources", " - usb: ehci-spear: fix call balance of sehci clk handling routines", " - usb: typec: ucsi: glink: fix off-by-one in connector_status", " - dm-cache: fix warnings about duplicate slab caches", " - dm-bufio: fix warnings about duplicate slab caches", " - ASoC: Intel: sst: Fix used of uninitialized ctx to log an error", " - soc: qcom: socinfo: fix revision check in qcom_socinfo_probe()", " - irqdomain: Always associate interrupts for legacy domains", " - ext4: supress data-race warnings in ext4_free_inodes_{count,set}()", " - ext4: fix FS_IOC_GETFSMAP handling", " - jfs: xattr: check invalid xattr size more strictly", " - ASoC: amd: yc: Add a quirk for microfone on Lenovo ThinkPad P14s Gen 5", " 21MES00B00", " - ASoC: codecs: Fix atomicity violation in snd_soc_component_get_drvdata()", " - ASoC: da7213: Populate max_register to regmap_config", " - perf/x86/intel/pt: Fix buffer full but size is 0 case", " - crypto: x86/aegis128 - access 32-bit arguments as 32-bit", " - KVM: x86: switch hugepage recovery thread to vhost_task", " - KVM: x86/mmu: Skip the \"try unsync\" path iff the old SPTE was a leaf SPTE", " - powerpc/pseries: Fix KVM guest detection for disabling hardlockup detector", " - KVM: arm64: vgic-v3: Sanitise guest writes to GICR_INVLPIR", " - KVM: arm64: Ignore PMCNTENSET_EL0 while checking for overflow status", " - KVM: arm64: Don't retire aborted MMIO instruction", " - KVM: arm64: vgic-its: Clear ITE when DISCARD frees an ITE", " - KVM: arm64: Get rid of userspace_irqchip_in_use", " - KVM: arm64: vgic-its: Add a data length check in vgic_its_save_*", " - KVM: arm64: vgic-its: Clear DTE when MAPD unmaps a device", " - Compiler Attributes: disable __counted_by for clang < 19.1.3", " - PCI: Fix use-after-free of slot->bus on hot remove", " - LoongArch: Explicitly specify code model in Makefile", " - clk: clk-loongson2: Fix memory corruption bug in struct", " loongson2_clk_provider", " - clk: clk-loongson2: Fix potential buffer overflow in flexible-array member", " access", " - fsnotify: fix sending inotify event with unexpected filename", " - comedi: Flush partial mappings in error case", " - apparmor: test: Fix memory leak for aa_unpack_strdup()", " - iio: dac: adi-axi-dac: fix wrong register bitfield", " - tty: ldsic: fix tty_ldisc_autoload sysctl's proc_handler", " - locking/lockdep: Avoid creating new name string literals in", " lockdep_set_subclass()", " - tools/nolibc: s390: include std.h", " - pinctrl: qcom: spmi: fix debugfs drive strength", " - dt-bindings: pinctrl: samsung: Fix interrupt constraint for variants with", " fallbacks", " - dt-bindings: iio: dac: ad3552r: fix maximum spi speed", " - exfat: fix uninit-value in __exfat_get_dentry_set", " - exfat: fix out-of-bounds access of directory entries", " - xhci: Fix control transfer error on Etron xHCI host", " - xhci: Combine two if statements for Etron xHCI host", " - xhci: Don't perform Soft Retry for Etron xHCI host", " - xhci: Don't issue Reset Device command to Etron xHCI host", " - Bluetooth: Fix type of len in rfcomm_sock_getsockopt{,_old}()", " - usb: xhci: Limit Stop Endpoint retries", " - usb: xhci: Fix TD invalidation under pending Set TR Dequeue", " - usb: xhci: Avoid queuing redundant Stop Endpoint commands", " - ARM: dts: omap36xx: declare 1GHz OPP as turbo again", " - wifi: ath12k: fix warning when unbinding", " - wifi: rtlwifi: Drastically reduce the attempts to read efuse in case of", " failures", " - wifi: nl80211: fix bounds checker error in nl80211_parse_sched_scan", " - wifi: ath12k: fix crash when unbinding", " - wifi: brcmfmac: release 'root' node in all execution paths", " - Revert \"fs: don't block i_writecount during exec\"", " - Revert \"f2fs: remove unreachable lazytime mount option parsing\"", " - Revert \"usb: gadget: composite: fix OS descriptors w_value logic\"", " - serial: sh-sci: Clean sci_ports[0] after at earlycon exit", " - Revert \"serial: sh-sci: Clean sci_ports[0] after at earlycon exit\"", " - io_uring: fix corner case forgetting to vunmap", " - io_uring: check for overflows in io_pin_pages", " - blk-settings: round down io_opt to physical_block_size", " - gpio: exar: set value when external pull-up or pull-down is present", " - spi: Fix acpi deferred irq probe", " - mtd: spi-nor: core: replace dummy buswidth from addr to data", " - cpufreq: mediatek-hw: Fix wrong return value in mtk_cpufreq_get_cpu_power()", " - cifs: support mounting with alternate password to allow password rotation", " - parisc/ftrace: Fix function graph tracing disablement", " - RISC-V: Scalar unaligned access emulated on hotplug CPUs", " - RISC-V: Check scalar unaligned access on all CPUs", " - ksmbd: fix use-after-free in SMB request handling", " - smb: client: fix NULL ptr deref in crypto_aead_setkey()", " - platform/chrome: cros_ec_typec: fix missing fwnode reference decrement", " - irqchip/irq-mvebu-sei: Move misplaced select() callback to SEI CP domain", " - x86/CPU/AMD: Terminate the erratum_1386_microcode array", " - ubi: wl: Put source PEB into correct list if trying locking LEB failed", " - um: ubd: Do not use drvdata in release", " - um: net: Do not use drvdata in release", " - dt-bindings: serial: rs485: Fix rs485-rts-delay property", " - serial: 8250_fintek: Add support for F81216E", " - serial: 8250: omap: Move pm_runtime_get_sync", " - serial: amba-pl011: Fix RX stall when DMA is used", " - serial: amba-pl011: fix build regression", " - mtd: ubi: fix unreleased fwnode_handle in find_volume_fwnode()", " - block: Prevent potential deadlock in blk_revalidate_disk_zones()", " - um: vector: Do not use drvdata in release", " - sh: cpuinfo: Fix a warning for CONFIG_CPUMASK_OFFSTACK", " - iio: gts: Fix uninitialized symbol 'ret'", " - ublk: fix ublk_ch_mmap() for 64K page size", " - arm64: tls: Fix context-switching of tpidrro_el0 when kpti is enabled", " - block: fix missing dispatching request when queue is started or unquiesced", " - block: fix ordering between checking QUEUE_FLAG_QUIESCED request adding", " - block: fix ordering between checking BLK_MQ_S_STOPPED request adding", " - blk-mq: Make blk_mq_quiesce_tagset() hold the tag list mutex less long", " - gve: Flow steering trigger reset only for timeout error", " - HID: wacom: Interpret tilt data from Intuos Pro BT as signed values", " - i40e: Fix handling changed priv flags", " - media: wl128x: Fix atomicity violation in fmc_send_cmd()", " - media: intel/ipu6: do not handle interrupts when device is disabled", " - arm64: dts: mediatek: mt8186-corsola-voltorb: Merge speaker codec nodes", " - netdev-genl: Hold rcu_read_lock in napi_get", " - soc: fsl: rcpm: fix missing of_node_put() in copy_ippdexpcr1_setting()", " - media: v4l2-core: v4l2-dv-timings: check cvt/gtf result", " - ALSA: rawmidi: Fix kvfree() call in spinlock", " - ALSA: ump: Fix evaluation of MIDI 1.0 FB info", " - ALSA: pcm: Add sanity NULL check for the default mmap fault handler", " - ALSA: hda/realtek: Update ALC225 depop procedure", " - ALSA: hda/realtek: Set PCBeep to default value for ALC274", " - ALSA: hda/realtek: Fix Internal Speaker and Mic boost of Infinix Y4 Max", " - ALSA: hda/realtek: Apply quirk for Medion E15433", " - smb3: request handle caching when caching directories", " - smb: client: handle max length for SMB symlinks", " - smb: Don't leak cfid when reconnect races with open_cached_dir", " - smb: prevent use-after-free due to open_cached_dir error paths", " - smb: During unmount, ensure all cached dir instances drop their dentry", " - usb: misc: ljca: set small runtime autosuspend delay", " - usb: misc: ljca: move usb_autopm_put_interface() after wait for response", " - usb: dwc3: ep0: Don't clear ep0 DWC3_EP_TRANSFER_STARTED", " - usb: musb: Fix hardware lockup on first Rx endpoint request", " - usb: dwc3: gadget: Fix checking for number of TRBs left", " - usb: dwc3: gadget: Fix looping of queued SG entries", " - staging: vchiq_arm: Fix missing refcount decrement in error path for fw_node", " - counter: stm32-timer-cnt: fix device_node handling in probe_encoder()", " - ublk: fix error code for unsupported command", " - lib: string_helpers: silence snprintf() output truncation warning", " - f2fs: fix to do sanity check on node blkaddr in truncate_node()", " - ipc: fix memleak if msg_init_ns failed in create_ipc_ns", " - Input: cs40l50 - fix wrong usage of INIT_WORK()", " - NFSD: Prevent a potential integer overflow", " - SUNRPC: make sure cache entry active before cache_show", " - um: Fix potential integer overflow during physmem setup", " - um: Fix the return value of elf_core_copy_task_fpregs", " - kfifo: don't include dma-mapping.h in kfifo.h", " - um: ubd: Initialize ubd's disk pointer in ubd_add", " - um: Always dump trace for specified task in show_stack", " - NFSv4.0: Fix a use-after-free problem in the asynchronous open()", " - rtc: st-lpc: Use IRQF_NO_AUTOEN flag in request_irq()", " - rtc: abx80x: Fix WDT bit position of the status register", " - rtc: check if __rtc_read_time was successful in rtc_timer_do_work()", " - ubi: fastmap: wl: Schedule fm_work if wear-leveling pool is empty", " - ubifs: Correct the total block count by deducting journal reservation", " - ubi: fastmap: Fix duplicate slab cache names while attaching", " - ubifs: authentication: Fix use-after-free in ubifs_tnc_end_commit", " - jffs2: fix use of uninitialized variable", " - rtc: rzn1: fix BCD to rtc_time conversion errors", " - Revert \"nfs: don't reuse partially completed requests in", " nfs_lock_and_join_requests\"", " - nvme-multipath: avoid hang on inaccessible namespaces", " - nvme/multipath: Fix RCU list traversal to use SRCU primitive", " - blk-mq: add non_owner variant of start_freeze/unfreeze queue APIs", " - block: model freeze & enter queue as lock for supporting lockdep", " - block: fix uaf for flush rq while iterating tags", " - block: return unsigned int from bdev_io_min", " - nvme-fabrics: fix kernel crash while shutting down controller", " - 9p/xen: fix init sequence", " - 9p/xen: fix release of IRQ", " - perf/arm-smmuv3: Fix lockdep assert in ->event_init()", " - perf/arm-cmn: Ensure port and device id bits are set properly", " - smb: client: disable directory caching when dir_cache_timeout is zero", " - x86/Documentation: Update algo in init_size description of boot protocol", " - cifs: Fix parsing native symlinks relative to the export", " - cifs: Fix parsing reparse point with native symlink in SMB1 non-UNICODE", " session", " - rtc: ab-eoz9: don't fail temperature reads on undervoltage notification", " - Rename .data.unlikely to .data..unlikely", " - Rename .data.once to .data..once to fix resetting WARN*_ONCE", " - kbuild: deb-pkg: Don't fail if modules.order is missing", " - smb: Initialize cfid->tcon before performing network ops", " - block: Don't allow an atomic write be truncated in blkdev_write_iter()", " - modpost: remove incorrect code in do_eisa_entry()", " - cifs: during remount, make sure passwords are in sync", " - cifs: unlock on error in smb3_reconfigure()", " - nfs: ignore SB_RDONLY when mounting nfs", " - sunrpc: clear XPRT_SOCK_UPD_TIMEOUT when reset transport", " - SUNRPC: timeout and cancel TLS handshake with -ETIMEDOUT", " - sunrpc: fix one UAF issue caused by sunrpc kernel tcp socket", " - nfs/blocklayout: Don't attempt unregister for invalid block device", " - nfs/blocklayout: Limit repeat device registration on failure", " - block, bfq: fix bfqq uaf in bfq_limit_depth()", " - brd: decrease the number of allocated pages which discarded", " - sh: intc: Fix use-after-free bug in register_intc_controller()", " - tools/power turbostat: Fix trailing '\\n' parsing", " - tools/power turbostat: Fix child's argument forwarding", " - block: always verify unfreeze lock on the owner task", " - block: don't verify IO lock for freeze/unfreeze in elevator_init_mq()", " - Linux 6.11.11", "", " * Oracular update: v6.11.11 upstream stable release (LP: #2091655) //", " CVE-2024-53141", " - netfilter: ipset: add missing range check in bitmap_ip_uadt", "", " * Oracular update: v6.11.11 upstream stable release (LP: #2091655) //", " CVE-2024-50010", " - Revert \"exec: don't WARN for racy path_noexec check\"", "", " * Oracular update: v6.11.11 upstream stable release (LP: #2091655) //", " CVE-2024-53143", " - fsnotify: Fix ordering of iput() and watched_objects decrement", "", " * Oracular update: v6.11.11 upstream stable release (LP: #2091655) //", " CVE-2024-53142", " - initramfs: avoid filename buffer overrun", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650)", " - net: vertexcom: mse102x: Fix tx_bytes calculation", " - net/mlx5: Fix msix vectors to respect platform limit", " - net/mlx5e: clear xdp features on non-uplink representors", " - net/mlx5e: Disable loopback self-test on multi-PF netdev", " - drm/i915/gsc: ARL-H and ARL-U need a newer GSC FW.", " - drivers: perf: Fix wrong put_cpu() placement", " - Bluetooth: hci_core: Fix calling mgmt_device_connected", " - Bluetooth: btintel: Direct exception event to bluetooth stack", " - net: sched: cls_u32: Fix u32's systematic failure to free IDR entries for", " hnodes.", " - net: phylink: ensure PHY momentary link-fails are handled", " - samples: pktgen: correct dev to DEV", " - net: stmmac: dwmac-mediatek: Fix inverted handling of mediatek,mac-wol", " - net: Make copy_safe_from_sockptr() match documentation", " - stmmac: dwmac-intel-plat: fix call balance of tx_clk handling routines", " - net: ti: icssg-prueth: Fix 1 PPS sync", " - bonding: add ns target multicast address to slave device", " - ARM: 9419/1: mm: Fix kernel memory mapping for xip kernels", " - tools/mm: fix compile error", " - drm/amd/display: Run idle optimizations at end of vblank handler", " - drm/amd/display: Change some variable name of psr", " - drm/amd/display: Fix Panel Replay not update screen correctly", " - x86/mm: Fix a kdump kernel failure on SME system when CONFIG_IMA_KEXEC=y", " - x86/stackprotector: Work around strict Clang TLS symbol requirements", " - crash, powerpc: default to CRASH_DUMP=n on PPC_BOOK3S_32", " - [Config] enable ARCH_DEFAULT_CRASH_DUMP", " - mm: revert \"mm: shmem: fix data-race in shmem_getattr()\"", " - vdpa/mlx5: Fix PA offset with unaligned starting iotlb map", " - evm: stop avoidably reading i_writecount in evm_file_release", " - KVM: selftests: Disable strict aliasing", " - KVM: nVMX: Treat vpid01 as current if L2 is active, but with VPID disabled", " - KVM: x86: Unconditionally set irr_pending when updating APICv state", " - tpm: Disable TPM on tpm2_create_primary() failure", " - ALSA: hda/realtek - Fixed Clevo platform headset Mic issue", " - ALSA: hda/realtek - update set GPIO3 to default for Thinkpad with ALC1318", " - mptcp: update local address flags when setting it", " - mptcp: hold pm lock when deleting entry", " - mptcp: pm: use _rcu variant under rcu_read_lock", " - ocfs2: fix UBSAN warning in ocfs2_verify_volume()", " - LoongArch: Fix early_numa_add_cpu() usage for FDT systems", " - LoongArch: Disable KASAN if PGDIR_SIZE is too large for cpu_vabits", " - LoongArch: Add WriteCombine shadow mapping in KASAN", " - LoongArch: Fix AP booting issue in VM mode", " - LoongArch: Make KASAN work with 5-level page-tables", " - selftests: hugetlb_dio: fixup check for initial conditions to skip in the", " start", " - btrfs: fix incorrect comparison for delayed refs", " - mailbox: qcom-cpucp: Mark the irq with IRQF_NO_SUSPEND flag", " - firmware: arm_scmi: Skip opp duplicates", " - firmware: arm_scmi: Report duplicate opps as firmware bugs", " - mmc: sunxi-mmc: Fix A100 compatible description", " - drm/bridge: tc358768: Fix DSI command tx", " - drm/xe: handle flat ccs during hibernation on igpu", " - pmdomain: arm: Use FLAG_DEV_NAME_FW to ensure unique names", " - pmdomain: core: Add GENPD_FLAG_DEV_NAME_FW flag", " - nouveau: fw: sync dma after setup is called.", " - nouveau: handle EBUSY and EAGAIN for GSP aux errors.", " - nouveau/dp: handle retries for AUX CH transfers with GSP.", " - drm/amd: Fix initialization mistake for NBIO 7.7.0", " - drm/amdgpu: fix check in gmc_v9_0_get_vm_pte()", " - drm/amdgpu: Fix video caps for H264 and HEVC encode maximum size", " - drm/amd/pm: print pp_dpm_mclk in ascending order on SMU v14.0.0", " - drm/amdgpu: enable GTT fallback handling for dGPUs only", " - drm/amdgpu/mes12: correct kiq unmap latency", " - drm/amd/display: Require minimum VBlank size for stutter optimization", " - drm/amd/display: Fix failure to read vram info due to static BP_RESULT", " - mm: refactor arch_calc_vm_flag_bits() and arm64 MTE handling", " - drm/xe: Restore system memory GGTT mappings", " - drm/xe: improve hibernation on igpu", " - lib/buildid: Fix build ID parsing logic", " - net: sched: u32: Add test case for systematic hnode IDR leaks", " - media: dvbdev: fix the logic when DVB_DYNAMIC_MINORS is not set", " - Linux 6.11.10", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53133", " - drm/amd/display: Handle dml allocation failure to avoid crash", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53108", " - drm/amd/display: Adjust VSDB parser for replay feature", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53134", " - pmdomain: imx93-blk-ctrl: correct remove path", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53132", " - drm/xe/oa: Fix \"Missing outer runtime PM protection\" warning", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53127", " - Revert \"mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K\"", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53130", " - nilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53105", " - mm: page_alloc: move mlocked flag clearance into free_pages_prepare()", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53109", " - nommu: pass NULL argument to vma_iter_prealloc()", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53131", " - nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53135", " - KVM: VMX: Bury Intel PT virtualization (guest/host mode) behind", " CONFIG_BROKEN", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53106", " - ima: fix buffer overrun in ima_eventdigest_init_common", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53110", " - vp_vdpa: fix id_table array not null terminated error", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53126", " - vdpa: solidrun: Fix UB bug with devres", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53111", " - mm/mremap: fix address wraparound in move_page_tables()", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53107", " - fs/proc/task_mmu: prevent integer overflow in pagemap_scan_get_args()", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53128", " - sched/task_stack: fix object_is_on_stack() for KASAN tagged pointers", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53112", " - ocfs2: uncache inode which has failed entering the group", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53113", " - mm: fix NULL pointer dereference in alloc_pages_bulk_noprof", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53114", " - x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 client", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53137", " - ARM: fix cacheflush with PAN", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53115", " - drm/vmwgfx: avoid null_ptr_deref in vmw_framebuffer_surface_create_handle", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53116", " - drm/panthor: Fix handling of partial GPU mapping of BOs", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53117", " - virtio/vsock: Improve MSG_ZEROCOPY error handling", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53118", " - vsock: Fix sk_error_queue memory leak", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53119", " - virtio/vsock: Fix accept_queue memory leak", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53120", " - net/mlx5e: CT: Fix null-ptr-deref in add rule err flow", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53138", " - net/mlx5e: kTLS, Fix incorrect page refcounting", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53121", " - net/mlx5: fs, lock FTE when checking if active", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53122", " - mptcp: cope racing subflow creation in mptcp_rcv_space_adjust", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53123", " - mptcp: error out earlier on disconnect", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53124", " - net: fix data-races around sk->sk_forward_alloc", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53129", " - drm/rockchip: vop: Fix a dereferenced before check warning", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53139", " - sctp: fix possible UAF in sctp_v6_available()", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53140", " - netlink: terminate outstanding dump on socket close", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649)", " - nvme/host: Fix RCU list traversal to use SRCU primitive", " - 9p: v9fs_fid_find: also lookup by inode if not found dentry", " - 9p: Avoid creating multiple slab caches with the same name", " - selftests/bpf: Verify that sync_linked_regs preserves subreg_def", " - nvmet-passthru: clear EUID/NGUID/UUID while using loop target", " - irqchip/ocelot: Fix trigger register address", " - pinctrl: aw9523: add missing mutex_destroy", " - pinctrl: intel: platform: Add Panther Lake to the list of supported", " - block: Fix elevator_get_default() checking for NULL q->tag_set", " - HID: multitouch: Add support for B2402FVA track point", " - HID: multitouch: Add quirk for HONOR MagicBook Art 14 touchpad", " - iommu/arm-smmu: Clarify MMU-500 CPRE workaround", " - nvme: disable CC.CRIME (NVME_CC_CRIME)", " - bpf: use kvzmalloc to allocate BPF verifier environment", " - crypto: api - Fix liveliness check in crypto_alg_tested", " - crypto: marvell/cesa - Disable hash algorithms", " - s390/ap: Fix CCA crypto card behavior within protected execution environment", " - sound: Make CONFIG_SND depend on INDIRECT_IOMEM instead of UML", " - drm/vmwgfx: Limit display layout ioctl array size to", " VMWGFX_NUM_DISPLAY_UNITS", " - selftests/bpf: Assert link info uprobe_multi count & path_size if unset", " - ALSA: hda/tas2781: Add new quirk for Lenovo, ASUS, Dell projects", " - drm/amdkfd: Accounting pdd vram_usage for svm", " - powerpc/powernv: Free name on error in opal_event_init()", " - net: phy: mdio-bcm-unimac: Add BCM6846 support", " - drm/xe/query: Increase timestamp width", " - nvme-loop: flush off pending I/O while shutting down loop controller", " - samples/landlock: Fix port parsing in sandboxer", " - vDPA/ifcvf: Fix pci_read_config_byte() return code handling", " - bpf: Fix mismatched RCU unlock flavour in bpf_out_neigh_v6", " - ASoC: Intel: avs: Update stream status in a separate thread", " - ASoC: codecs: Fix error handling in aw_dev_get_dsp_status function", " - ASoC: amd: yc: Add quirk for ASUS Vivobook S15 M3502RA", " - ASoC: amd: yc: Fix non-functional mic on ASUS E1404FA", " - ASoC: Intel: soc-acpi: lnl: Add match entry for TM2 laptops", " - netfs: Downgrade i_rwsem for a buffered write", " - HID: i2c-hid: Delayed i2c resume wakeup for 0x0d42 Goodix touchpad", " - HID: multitouch: Add quirk for Logitech Bolt receiver w/ Casa touchpad", " - HID: lenovo: Add support for Thinkpad X1 Tablet Gen 3 keyboard", " - ASoC: codecs: lpass-rx-macro: fix RXn(rx,n) macro for DSM_CTL and SEC7 regs", " - RISCV: KVM: use raw_spinlock for critical section in imsic", " - ASoC: rt722-sdca: increase clk_stop_timeout to fix clock stop issue", " - LoongArch: Use \"Exception return address\" to comment ERA", " - ASoC: fsl_micfil: Add sample rate constraint", " - net: usb: qmi_wwan: add Fibocom FG132 0x0112 composition", " - drm/xe: Enlarge the invalidation timeout from 150 to 500", " - drm/xe/guc/ct: Flush g2h worker in case of g2h response timeout", " - drm/xe: Handle unreliable MMIO reads during forcewake", " - drm/xe: Don't restart parallel queues multiple times on GT reset", " - mm: krealloc: Fix MTE false alarm in __do_krealloc", " - 9p: fix slab cache name creation for real", " - Linux 6.11.9", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53098", " - drm/xe/ufence: Prefetch ufence addr to catch bogus address", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53099", " - bpf: Check validity of link->type in bpf_link_show_fdinfo()", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53089", " - LoongArch: KVM: Mark hrtimer to expire in hard interrupt context", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53090", " - afs: Fix lock recursion", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53101", " - fs: Fix uninitialized value issue in from_kuid and from_kgid", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53091", " - bpf: Add sk_is_inet and IS_ICSK check in tls_sw_has_ctx_tx/rx", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53092", " - virtio_pci: Fix admin vq cleanup by using correct info pointer", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53102", " - nvme: make keep-alive synchronous operation", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53093", " - nvme-multipath: defer partition scanning", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53094", " - RDMA/siw: Add sendpage_ok() check to disable MSG_SPLICE_PAGES", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53100", " - nvme: tcp: avoid race between queue_lock lock and destroy", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53095", " - smb: client: Fix use-after-free of network namespace.", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645)", " - arm64: dts: rockchip: Fix rt5651 compatible value on rk3399-eaidk-610", " - arm64: dts: rockchip: Fix rt5651 compatible value on rk3399-sapphire-", " excavator", " - arm64: dts: rockchip: Move L3 cache outside CPUs in RK3588(S) SoC dtsi", " - arm64: dts: rockchip: Start cooling maps numbering from zero on ROCK 5B", " - arm64: dts: rockchip: Designate Turing RK1's system power controller", " - EDAC/qcom: Make irq configuration optional", " - arm64: dts: rockchip: Remove hdmi's 2nd interrupt on rk3328", " - arm64: dts: rockchip: Fix wakeup prop names on PineNote BT node", " - arm64: dts: rockchip: Fix reset-gpios property on brcm BT nodes", " - arm64: dts: rockchip: fix i2c2 pinctrl-names property on anbernic-rg353p/v", " - arm64: dts: rockchip: Drop regulator-init-microvolt from two boards", " - arm64: dts: rockchip: Fix bluetooth properties on rk3566 box demo", " - arm64: dts: rockchip: Fix bluetooth properties on Rock960 boards", " - arm64: dts: rockchip: Add DTS for FriendlyARM NanoPi R2S Plus", " - arm64: dts: rockchip: Remove undocumented supports-emmc property", " - arm64: dts: rockchip: Remove #cooling-cells from fan on Theobroma lion", " - arm64: dts: rockchip: Fix LED triggers on rk3308-roc-cc", " - arm64: dts: rockchip: remove num-slots property from rk3328-nanopi-r2s-plus", " - arm64: dts: qcom: sm8450 fix PIPE clock specification for pcie1", " - arm64: dts: imx8-ss-vpu: Fix imx8qm VPU IRQs", " - arm64: dts: imx8mp: correct sdhc ipg clk", " - arm64: dts: imx8mp-phyboard-pollux: Set Video PLL1 frequency to 506.8 MHz", " - firmware: qcom: scm: Return -EOPNOTSUPP for unsupported SHM bridge enabling", " - arm64: dts: rockchip: remove orphaned pinctrl-names from pinephone pro", " - ARM: dts: rockchip: fix rk3036 acodec node", " - ARM: dts: rockchip: drop grf reference from rk3036 hdmi", " - ARM: dts: rockchip: Fix the spi controller on rk3036", " - ARM: dts: rockchip: Fix the realtek audio codec on rk3036-kylin", " - arm64: dts: rockchip: Correct GPIO polarity on brcm BT nodes", " - sunrpc: handle -ENOTCONN in xs_tcp_setup_socket()", " - NFSv3: only use NFS timeout for MOUNT when protocols are compatible", " - NFS: Fix attribute delegation behaviour on exclusive create", " - NFS: Further fixes to attribute delegation a/mtime changes", " - nfs: avoid i_lock contention in nfs_clear_invalid_mapping", " - net: enetc: set MAC address to the VF net_device", " - net: dpaa_eth: print FD status in CPU endianness in dpaa_eth_fd tracepoint", " - dt-bindings: net: xlnx,axi-ethernet: Correct phy-mode property value", " - can: c_can: fix {rx,tx}_errors statistics", " - ice: change q_index variable type to s16 to store -1 value", " - e1000e: Remove Meteor Lake SMBUS workarounds", " - net: phy: ti: add PHY_RST_AFTER_CLK_EN flag", " - net: stmmac: Fix unbalanced IRQ wake disable warning on single irq case", " - netfilter: nf_tables: wait for rcu grace period on net_device removal", " - virtio_net: Support dynamic rss indirection table size", " - virtio_net: Sync rss config to device when virtnet_probe", " - virtio_net: Update rss when set queue", " - net: arc: rockchip: fix emac mdio node support", " - drivers: net: ionic: add missed debugfs cleanup to ionic_probe() error path", " - Revert \"ALSA: hda/conexant: Mute speakers at suspend / shutdown\"", " - media: stb0899_algo: initialize cfr before using it", " - media: dvb_frontend: don't play tricks with underflow values", " - media: adv7604: prevent underflow condition when reporting colorspace", " - scsi: sd_zbc: Use kvzalloc() to allocate REPORT ZONES buffer", " - ALSA: firewire-lib: fix return value on fail in amdtp_tscm_init()", " - tools/lib/thermal: Fix sampling handler context ptr", " - thermal/of: support thermal zones w/o trips subnode", " - ASoC: SOF: sof-client-probes-ipc4: Set param_size extension bits", " - media: pulse8-cec: fix data timestamp at pulse8_setup()", " - media: v4l2-ctrls-api: fix error handling for v4l2_g_ctrl()", " - can: m_can: m_can_close(): don't call free_irq() for IRQ-less devices", " - can: mcp251xfd: mcp251xfd_get_tef_len(): fix length calculation", " - can: mcp251xfd: mcp251xfd_ring_alloc(): fix coalescing configuration when", " switching CAN modes", " - can: {cc770,sja1000}_isa: allow building on x86_64", " - [Config] updateconfigs for CAN_{CC770,SJA1000}_ISA", " - drm/xe: Set mask bits for CCS_MODE register", " - pwm: imx-tpm: Use correct MODULO value for EPWM mode", " - rpmsg: glink: Handle rejected intent request better", " - drm/amd/pm: always pick the pptable from IFWI", " - drm/amd/display: Fix brightness level not retained over reboot", " - drm/imagination: Add a per-file PVR context list", " - drm/amdgpu: Adjust debugfs eviction and IB access permissions", " - drm/amdgpu: Adjust debugfs register access permissions", " - drm/amdgpu: Fix DPX valid mode check on GC 9.4.3", " - drm/amdgpu: prevent NULL pointer dereference if ATIF is not supported", " - thermal/drivers/qcom/lmh: Remove false lockdep backtrace", " - dm cache: correct the number of origin blocks to match the target length", " - dm cache: optimize dirty bit checking with find_next_bit when resizing", " - dm-unstriped: cast an operand to sector_t to prevent potential uint32_t", " overflow", " - mptcp: no admin perm to list endpoints", " - ALSA: usb-audio: Add quirk for HP 320 FHD Webcam", " - tracing: Fix tracefs mount options", " - net: wwan: t7xx: Fix off-by-one error in t7xx_dpmaif_rx_buf_alloc()", " - mptcp: use sock_kfree_s instead of kfree", " - arm64: Kconfig: Make SME depend on BROKEN for now", " - [Config] updateconfigs for ARM64_SME", " - arm64: smccc: Remove broken support for SMCCCv1.3 SVE discard hint", " - KVM: PPC: Book3S HV: Mask off LPCR_MER for a vCPU before running it to avoid", " spurious interrupts", " - btrfs: fix the length of reserved qgroup to free", " - btrfs: fix per-subvolume RO/RW flags with new mount API", " - platform/x86/amd/pmf: Relocate CPU ID macros to the PMF header", " - platform/x86/amd/pmf: Update SMU metrics table for 1AH family series", " - platform/x86/amd/pmf: Add SMU metrics table support for 1Ah family 60h model", " - i2c: designware: do not hold SCL low when I2C_DYNAMIC_TAR_UPDATE is not set", " - clk: qcom: gcc-x1e80100: Fix USB MP SS1 PHY GDSC pwrsts flags", " - clk: qcom: clk-alpha-pll: Fix pll post div mask when width is not set", " - fs/proc: fix compile warning about variable 'vmcore_mmap_ops'", " - objpool: fix to make percpu slot allocation more robust", " - mm/damon/core: handle zero {aggregation,ops_update} intervals", " - mm/damon/core: handle zero schemes apply interval", " - mm/mlock: set the correct prev on failure", " - thunderbolt: Add only on-board retimers when !CONFIG_USB4_DEBUGFS_MARGINING", " - usb: dwc3: fix fault at system suspend if device was already runtime", " suspended", " - USB: serial: qcserial: add support for Sierra Wireless EM86xx", " - USB: serial: option: add Fibocom FG132 0x0112 composition", " - USB: serial: option: add Quectel RG650V", " - clk: qcom: gcc-x1e80100: Fix halt_check for pipediv2 clocks", " - thunderbolt: Fix connection issue with Pluggable UD-4VPD dock", " - staging: vchiq_arm: Use devm_kzalloc() for drv_mgmt allocation", " - staging: vchiq_arm: Use devm_kzalloc() for vchiq_arm_state allocation", " - irqchip/gic-v3: Force propagation of the active state with a read-back", " - ucounts: fix counter leak in inc_rlimit_get_ucounts()", " - selftests: hugetlb_dio: check for initial conditions to skip in the start", " - firmware: qcom: scm: Refactor code to support multiple dload mode", " - [Config] updateconfigs for QCOM_SCM_DOWNLOAD_MODE_DEFAULT", " - firmware: qcom: scm: suppress download mode error", " - block: rework bio splitting", " - block: fix queue limits checks in blk_rq_map_user_bvec for real", " - drm/xe: Move LNL scheduling WA to xe_device.h", " - drm/xe/ufence: Flush xe ordered_wq in case of ufence timeout", " - drm/xe/guc/tlb: Flush g2h worker in case of tlb timeout", " - ASoC: amd: yc: fix internal mic on Xiaomi Book Pro 14 2022", " - xtensa: Emulate one-byte cmpxchg", " - Linux 6.11.8", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50265", " - ocfs2: remove entry once instead of null-ptr-dereference in", " ocfs2_xa_remove()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50266", " - clk: qcom: videocc-sm8350: use HW_CTRL_TRIGGER for vcodec GDSCs", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50267", " - USB: serial: io_edgeport: fix use after free in debug printk", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50268", " - usb: typec: fix potential out of bounds in ucsi_ccg_update_set_new_cam_cmd()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53083", " - usb: typec: qcom-pmic: init value of hdr_len/txbuf_len earlier", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50269", " - usb: musb: sunxi: Fix accessing an released usb phy", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53079", " - mm/thp: fix deferred split unqueue naming and locking", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50270", " - mm/damon/core: avoid overflow in damon_feed_loop_next_input()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50271", " - signal: restore the override_rlimit logic", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50272", " - filemap: Fix bounds checking in filemap_read()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53104", " - media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in", " uvc_parse_format", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50273", " - btrfs: reinitialize delayed ref list after deleting it from the list", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53064", " - idpf: fix idpf_vc_core_init error path", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50274", " - idpf: avoid vport access in idpf_get_link_ksettings", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53065", " - mm/slab: fix warning caused by duplicate kmem_cache creation in", " kmem_buckets_create", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50275", " - arm64/sve: Discard stale CPU state when handling SVE traps", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50276", " - net: vertexcom: mse102x: Fix possible double free of TX skb", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53066", " - nfs: Fix KMSAN warning in decode_getfattr_attrs()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53067", " - scsi: ufs: core: Start the RTC update work later", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50277", " - dm: fix a crash if blk_alloc_disk fails", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50278", " - dm cache: fix potential out-of-bounds access on the first resume", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50279", " - dm cache: fix out-of-bounds access to the dirty bitset when resizing", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50280", " - dm cache: fix flushing uninitialized delayed_work on cache_ctr error", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50281", " - KEYS: trusted: dcp: fix NULL dereference in AEAD crypto operation", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50282", " - drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53071", " - drm/panthor: Be stricter about IO mapping flags", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53080", " - drm/panthor: Lock XArray when getting entries for the VM", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53084", " - drm/imagination: Break an object reference loop", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53085", " - tpm: Lock TPM chip in tpm_pm_suspend() first", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53086", " - drm/xe: Drop VM dma-resv lock on xe_sync_in_fence_get failure in exec IOCTL", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53087", " - drm/xe: Fix possible exec queue leak in exec IOCTL", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50283", " - ksmbd: fix slab-use-after-free in smb3_preauth_hash_rsp", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50284", " - ksmbd: Fix the missing xa_store error check", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50285", " - ksmbd: check outstanding simultaneous SMB operations", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50286", " - ksmbd: fix slab-use-after-free in ksmbd_smb2_session_create", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50287", " - media: v4l2-tpg: prevent the risk of a division by zero", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50288", " - media: vivid: fix buffer overwrite when using > 32 buffers", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50289", " - media: av7110: fix a spectre vulnerability", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50290", " - media: cx24116: prevent overflows on SNR calculus", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53061", " - media: s5p-jpeg: prevent buffer overflows", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53081", " - media: ar0521: don't overflow when checking PLL values", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53062", " - media: mgb4: protect driver against spectre", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50291", " - media: dvb-core: add missing buffer index check", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50292", " - ASoC: stm32: spdifrx: fix dma channel release in stm32_spdifrx_remove", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53063", " - media: dvbdev: prevent the risk of out of memory access", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50293", " - net/smc: do not leave a dangling sk pointer in __smc_create()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50294", " - rxrpc: Fix missing locking causing hanging calls", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50295", " - net: arc: fix the device for dma_map_single/dma_unmap_single", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53082", " - virtio_net: Add hash_key_length check", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50296", " - net: hns3: fix kernel crash when uninstalling driver", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53088", " - i40e: fix race condition by adding filter's intermediate sync state", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50297", " - net: xilinx: axienet: Enqueue Tx packets in dql before dmaengine starts", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50298", " - net: enetc: allocate vf_state during PF probes", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50299", " - sctp: properly validate chunk size in sctp_sf_ootb()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50300", " - regulator: rtq2208: Fix uninitialized use of regulator_config", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50301", " - security/keys: fix slab-out-of-bounds in key_task_permission", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53072", " - platform/x86/amd/pmc: Detect when STB is not available", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50302", " - HID: core: zero-initialize the report buffer", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53068", " - firmware: arm_scmi: Fix slab-use-after-free in scmi_bus_notifier()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53069", " - firmware: qcom: scm: fix a NULL-pointer dereference", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629)", " - drm/amdgpu: fix random data corruption for sdma 7", " - cgroup: Fix potential overflow issue when checking max_depth", " - spi: geni-qcom: Fix boot warning related to pm_runtime and devres", " - perf trace: Fix non-listed archs in the syscalltbl routines", " - perf python: Fix up the build on architectures without HAVE_KVM_STAT_SUPPORT", " - scsi: scsi_debug: Fix do_device_access() handling of unexpected SG copy", " length", " - wifi: iwlegacy: Fix \"field-spanning write\" warning in il_enqueue_hcmd()", " - mac80211: MAC80211_MESSAGE_TRACING should depend on TRACING", " - wifi: mac80211: skip non-uploaded keys in ieee80211_iter_keys", " - wifi: ath11k: Fix invalid ring usage in full monitor mode", " - wifi: rtw89: pci: early chips only enable 36-bit DMA on specific PCI hosts", " - wifi: brcm80211: BRCM_TRACING should depend on TRACING", " - RDMA/cxgb4: Dump vendor specific QP details", " - RDMA/mlx5: Round max_rd_atomic/max_dest_rd_atomic up instead of down", " - RDMA/bnxt_re: Fix the usage of control path spin locks", " - RDMA/bnxt_re: synchronize the qp-handle table array", " - wifi: iwlwifi: mvm: really send iwl_txpower_constraints_cmd", " - wifi: iwlwifi: mvm: don't add default link in fw restart flow", " - Revert \"wifi: iwlwifi: remove retry loops in start\"", " - ASoC: cs42l51: Fix some error handling paths in cs42l51_probe()", " - net: stmmac: dwmac4: Fix high address display by updating reg_space[] from", " register values", " - dpll: add Embedded SYNC feature for a pin", " - ice: add callbacks for Embedded SYNC enablement on dpll pins", " - gtp: allow -1 to be specified as file description from userspace", " - bpf: Force checkpoint when jmp history is too long", " - bpf: Add bpf_mem_alloc_check_size() helper", " - net: skip offload for NETIF_F_IPV6_CSUM if ipv6 header contains extension", " - mlxsw: spectrum_ptp: Add missing verification before pushing Tx header", " - mlxsw: pci: Sync Rx buffers for CPU", " - mlxsw: pci: Sync Rx buffers for device", " - net: ethernet: mtk_wed: fix path of MT7988 WO firmware", " - bpf, test_run: Fix LIVE_FRAME frame update after a page has been recycled", " - iomap: improve shared block detection in iomap_unshare_iter", " - iomap: don't bother unsharing delalloc extents", " - iomap: share iomap_unshare_iter predicate code with fsdax", " - fsdax: remove zeroing code from dax_unshare_iter", " - iomap: turn iomap_want_unshare_iter into an inline function", " - kasan: Fix Software Tag-Based KASAN with GCC", " - firmware: arm_sdei: Fix the input parameter of cpuhp_remove_state()", " - afs: Fix missing subdir edit when renamed between parent dirs", " - gpio: sloppy-logic-analyzer: Check for error code from devm_mutex_init()", " call", " - smb: client: fix parsing of device numbers", " - smb: client: set correct device number on nfs reparse points", " - drm/mediatek: ovl: Remove the color format comment for ovl_fmt_convert()", " - drm/mediatek: Fix color format MACROs in OVL", " - drm/mediatek: Fix get efuse issue for MT8188 DPTX", " - drm/mediatek: Use cmdq_pkt_create() and cmdq_pkt_destroy()", " - cxl/events: Fix Trace DRAM Event Record", " - PCI: Fix pci_enable_acs() support for the ACS quirks", " - nvme: module parameter to disable pi with offsets", " - drm/panthor: Fix firmware initialization on systems with a page size > 4k", " - drm/panthor: Fail job creation when the group is dead", " - drm/panthor: Report group as timedout when we fail to properly suspend", " - fs/ntfs3: Fix warning possible deadlock in ntfs_set_state", " - fs/ntfs3: Stale inode instead of bad", " - rust: device: change the from_raw() function", " - scsi: scsi_transport_fc: Allow setting rport state to current state", " - cifs: Improve creating native symlinks pointing to directory", " - cifs: Fix creating native symlinks pointing to current or parent directory", " - ACPI: resource: Fold Asus Vivobook Pro N6506M* DMI quirks together", " - powercap: intel_rapl_msr: Add PL4 support for Arrowlake-U", " - thermal: intel: int340x: processor: Remove MMIO RAPL CPU hotplug support", " - thermal: intel: int340x: processor: Add MMIO RAPL PL4 support", " - net: amd: mvme147: Fix probe banner message", " - NFS: remove revoked delegation from server's delegation list", " - misc: sgi-gru: Don't disable preemption in GRU driver", " - NFSD: Initialize struct nfsd4_copy earlier", " - NFSD: Never decrement pending_async_copies on error", " - ALSA: usb-audio: Add quirks for Dell WD19 dock", " - wifi: rtlwifi: rtl8192du: Don't claim USB ID 0bda:8171", " - usbip: tools: Fix detach_port() invalid port error path", " - usb: phy: Fix API devm_usb_put_phy() can not release the phy", " - usb: typec: fix unreleased fwnode_handle in typec_port_register_altmodes()", " - usb: typec: tcpm: restrict SNK_WAIT_CAPABILITIES_TIMEOUT transitions to non", " self-powered devices", " - usb: typec: qcom-pmic-typec: use fwnode_handle_put() to release fwnodes", " - usb: typec: qcom-pmic-typec: fix missing fwnode removal in error path", " - xhci: Fix Link TRB DMA in command ring stopped completion event", " - xhci: Use pm_runtime_get to prevent RPM on unsupported systems", " - Revert \"driver core: Fix uevent_show() vs driver detach race\"", " - dt-bindings: iio: adc: ad7380: fix ad7380-4 reference supply", " - iio: light: veml6030: fix microlux value calculation", " - RISC-V: ACPI: fix early_ioremap to early_memremap", " - tools/mm: -Werror fixes in page-types/slabinfo", " - mm: shrinker: avoid memleak in alloc_shrinker_info", " - firmware: microchip: auto-update: fix poll_complete() to not report spurious", " timeout errors", " - thunderbolt: Honor TMU requirements in the domain when setting TMU mode", " - soc: qcom: pmic_glink: Handle GLINK intent allocation rejections", " - cxl/port: Fix CXL port initialization order when the subsystem is built-in", " - mmc: sdhci-pci-gli: GL9767: Fix low power mode on the set clock function", " - mmc: sdhci-pci-gli: GL9767: Fix low power mode in the SD Express process", " - block: fix sanity checks in blk_rq_map_user_bvec", " - phy: freescale: imx8m-pcie: Do CMN_RST just before PHY PLL lock check", " - btrfs: merge btrfs_orig_bbio_end_io() into btrfs_bio_end_io()", " - riscv: vdso: Prevent the compiler from inserting calls to memset()", " - Input: edt-ft5x06 - fix regmap leak when probe fails", " - ALSA: hda/realtek: Limit internal Mic boost on Dell platform", " - riscv: efi: Set NX compat flag in PE/COFF header", " - riscv: Use '%u' to format the output of 'cpu'", " - riscv: Remove unused GENERATING_ASM_OFFSETS", " - riscv: Remove duplicated GET_RM", " - cxl/port: Fix cxl_bus_rescan() vs bus_rescan_devices()", " - cxl/acpi: Ensure ports ready at cxl_acpi_probe() return", " - posix-cpu-timers: Clear TICK_DEP_BIT_POSIX_TIMER on clone", " - tpm: Return tpm2_sessions_init() when null key creation fails", " - tpm: Rollback tpm2_load_null()", " - drm/amdgpu/smu13: fix profile reporting", " - tpm: Lazily flush the auth session", " - mei: use kvmalloc for read buffer", " - x86/traps: Enable UBSAN traps on x86", " - x86/traps: move kmsan check after instrumentation_begin", " - accel/ivpu: Fix NOC firewall interrupt handling", " - ALSA: hda/realtek: Fix headset mic on TUXEDO Gemini 17 Gen3", " - ALSA: hda/realtek: Fix headset mic on TUXEDO Stellaris 16 Gen6 mb1", " - nvme: re-fix error-handling for io_uring nvme-passthrough", " - kasan: remove vmalloc_percpu test", " - drm/tests: helpers: Add helper for drm_display_mode_from_cea_vic()", " - drm/xe: Fix register definition order in xe_regs.h", " - drm/xe: Kill regs/xe_sriov_regs.h", " - drm/xe: Add mmio read before GGTT invalidate", " - drm/xe: Don't short circuit TDR on jobs not started", " - btrfs: fix extent map merging not happening for adjacent extents", " - btrfs: fix defrag not merging contiguous extents due to merged extent maps", " - gpiolib: fix debugfs newline separators", " - gpiolib: fix debugfs dangling chip separator", " - vmscan,migrate: fix page count imbalance on node stats when demoting pages", " - mm, mmap: limit THP alignment of anonymous mappings to PMD-aligned sizes", " - Input: fix regression when re-registering input handlers", " - mm: multi-gen LRU: ignore non-leaf pmd_young for force_scan=true", " - mm: multi-gen LRU: remove MM_LEAF_OLD and MM_NONLEAF_TOTAL stats", " - mm: shrink skip folio mapped by an exiting process", " - mm: multi-gen LRU: use {ptep,pmdp}_clear_young_notify()", " - riscv: dts: starfive: Update ethernet phy0 delay parameter values for Star64", " - riscv: dts: starfive: disable unused csi/camss nodes", " - arm64: dts: qcom: msm8939: revert use of APCS mbox for RPM", " - arm64: dts: qcom: x1e80100-yoga-slim7x: fix nvme regulator boot glitch", " - arm64: dts: qcom: x1e80100: Fix up BAR spaces", " - arm64: dts: qcom: x1e80100-vivobook-s15: fix nvme regulator boot glitch", " - arm64: dts: qcom: x1e80100: fix PCIe4 interconnect", " - arm64: dts: qcom: x1e80100-qcp: fix nvme regulator boot glitch", " - arm64: dts: qcom: x1e80100-crd: fix nvme regulator boot glitch", " - arm64: dts: qcom: x1e80100: Add Broadcast_AND region in LLCC block", " - arm64: dts: qcom: x1e80100: fix PCIe4 and PCIe6a PHY clocks", " - drm/xe/xe2hpg: Add Wa_15016589081", " - drm/amdgpu/swsmu: fix ordering for setting workload_mask", " - drm/amdgpu/swsmu: default to fullscreen 3D profile for dGPUs", " - fs/ntfs3: Sequential field availability check in mi_enum_attr()", " - drm/amdgpu: handle default profile on on devices without fullscreen 3D", " - MIPS: export __cmpxchg_small()", " - RISC-V: disallow gcc + rust builds", " - [Config] updateconfigs after disabling rust with gcc on riscv", " - rcu/kvfree: Add kvfree_rcu_barrier() API", " - rcu/kvfree: Refactor kvfree_rcu_queue_batch()", " - Linux 6.11.7", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50212", " - lib: alloc_tag_module_unload must wait for pending kfree_rcu calls", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53046", " - arm64: dts: imx8ulp: correct the flexspi compatible string", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53052", " - io_uring/rw: fix missing NOWAIT check for O_DIRECT start write", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50213", " - drm/tests: hdmi: Fix memory leaks in drm_display_mode_from_cea_vic()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50214", " - drm/connector: hdmi: Fix memory leak in drm_display_mode_from_cea_vic()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50215", " - nvmet-auth: assign dh_key to NULL after kfree_sensitive", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50216", " - xfs: fix finding a last resort AG in xfs_filestream_pick_ag", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50217", " - btrfs: fix use-after-free of block device file in", " __btrfs_free_extra_devids()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53043", " - mctp i2c: handle NULL header address", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50303", " - resource,kexec: walk_system_ram_res_rev must retain resource flags", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50218", " - ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50219", " - mm/page_alloc: let GFP_ATOMIC order-0 allocs access highatomic reserves", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50263", " - fork: only invoke khugepaged, ksm hooks if no error", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50220", " - fork: do not invoke uffd on fork if error occurs", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53047", " - mptcp: init: protect sched with rcu_read_lock", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50221", " - drm/amd/pm: Vangogh: Fix kernel memory out of bounds write", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50222", " - iov_iter: fix copy_page_from_iter_atomic() if KMAP_LOCAL_FORCE_MAP", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50223", " - sched/numa: Fix the potential null pointer dereference in task_numa_work()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53053", " - scsi: ufs: core: Fix another deadlock during RTC update", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53075", " - riscv: Prevent a bad reference count on CPU nodes", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50224", " - spi: spi-fsl-dspi: Fix crash when not using GPIO chip select", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50225", " - btrfs: fix error propagation of split bios", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53054", " - cgroup/bpf: use a dedicated workqueue for cgroup bpf destruction", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50226", " - cxl/port: Fix use-after-free, permit out-of-order decoder shutdown", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50227", " - thunderbolt: Fix KASAN reported stack out-of-bounds read in", " tb_retimer_scan()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50228", " - mm: shmem: fix data-race in shmem_getattr()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50229", " - nilfs2: fix potential deadlock with newly created symlinks", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50230", " - nilfs2: fix kernel bug due to missing clearing of checked flag", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50231", " - iio: gts-helper: Fix memory leaks in iio_gts_build_avail_scale_table()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53076", " - iio: gts-helper: Fix memory leaks for the error path of", " iio_gts_build_avail_scale_table()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50232", " - iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50233", " - staging: iio: frequency: ad9832: fix division by zero in", " ad9832_calc_freqreg()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53055", " - wifi: iwlwifi: mvm: fix 6 GHz scan construction", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50234", " - wifi: iwlegacy: Clear stale interrupts before resuming device", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50235", " - wifi: cfg80211: clear wdev->cqm_config pointer on free", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50236", " - wifi: ath10k: Fix memory leak in management tx", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50237", " - wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50238", " - phy: qcom: qmp-usbc: fix NULL-deref on runtime suspend", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50239", " - phy: qcom: qmp-usb-legacy: fix NULL-deref on runtime suspend", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50240", " - phy: qcom: qmp-usb: fix NULL-deref on runtime suspend", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53077", " - rpcrdma: Always release the rpcrdma_device's xa_array", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50242", " - fs/ntfs3: Additional check in ntfs_file_release", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50243", " - fs/ntfs3: Fix general protection fault in run_is_mapped_full", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50244", " - fs/ntfs3: Additional check in ni_clear()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50245", " - fs/ntfs3: Fix possible deadlock in mi_read", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50246", " - fs/ntfs3: Add rough attr alloc_size check", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50247", " - fs/ntfs3: Check if more than chunk-size bytes are written", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50248", " - ntfs3: Add bounds checking to mi_enum_attr()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53078", " - drm/tegra: Fix NULL vs IS_ERR() check in probe()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53056", " - drm/mediatek: Fix potential NULL dereference in mtk_crtc_destroy()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50249", " - ACPI: CPPC: Make rmw_lock a raw_spin_lock", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50250", " - fsdax: dax_unshare_iter needs to copy entire blocks", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50251", " - netfilter: nft_payload: sanitize offset and length before calling", " skb_checksum()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50252", " - mlxsw: spectrum_ipip: Fix memory leak when changing remote IPv6 address", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50253", " - bpf: Check the validity of nr_words in bpf_iter_bits_new()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50254", " - bpf: Free dynamically allocated bits in bpf_iter_bits_destroy()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50255", " - Bluetooth: hci: fix null-ptr-deref in hci_read_supported_codecs", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50256", " - netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50257", " - netfilter: Fix use-after-free in get_info()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50258", " - net: fix crash when config small gso_max_size/gso_ipv4_max_size", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50262", " - bpf: Fix out-of-bounds write in trie_get_next_key()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53044", " - net/sched: sch_api: fix xa_insert() error path in tcf_block_get_ext()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50259", " - netdevsim: Add trailing zero to terminate the string in", " nsim_nexthop_bucket_activity_write()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50304", " - ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53042", " - ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_init_flow()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53048", " - ice: fix crash on probe for DPLL enabled E810 LOM", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53058", " - net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50260", " - sock_map: fix a NULL pointer dereference in sock_map_link_update_prog()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53045", " - ASoC: dapm: fix bounds checker error in dapm_widget_list_create", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50261", " - macsec: Fix use-after-free while sending the offloading packet", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53059", " - wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53074", " - wifi: iwlwifi: mvm: don't leak a link on AP removal", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53049", " - slub/kunit: fix a WARNING due to unwrapped __kmalloc_cache_noprof", "", " * Oracular update: v6.11.6 upstream stable release (LP: #2091386)", " - bpf: Use raw_spinlock_t in ringbuf", " - iio: accel: bma400: Fix uninitialized variable field_value in tap event", " handling.", " - reset: starfive: jh71x0: Fix accessing the empty member on JH7110 SoC", " - bpf: sync_linked_regs() must preserve subreg_def", " - bpf: Make sure internal and UAPI bpf_redirect flags don't overlap", " - irqchip/riscv-imsic: Fix output text of base address", " - bpf: devmap: provide rxq after redirect", " - cpufreq/amd-pstate: Fix amd_pstate mode switch on shared memory systems", " - lib/Kconfig.debug: fix grammar in RUST_BUILD_ASSERT_ALLOW", " - bpf: Fix memory leak in bpf_core_apply", " - RDMA/bnxt_re: Fix a possible memory leak", " - RDMA/bnxt_re: Fix incorrect AVID type in WQE structure", " - RDMA/bnxt_re: Add a check for memory allocation", " - x86/resctrl: Avoid overflow in MB settings in bw_validate()", " - ARM: dts: bcm2837-rpi-cm3-io3: Fix HDMI hpd-gpio pin", " - clk: rockchip: fix finding of maximum clock ID", " - bpf: Check the remaining info_cnt before repeating btf fields", " - bpf: fix unpopulated name_len field in perf_event link info", " - selftests/bpf: fix perf_event link info name_len assertion", " - riscv, bpf: Fix possible infinite tailcall when CONFIG_CFI_CLANG is enabled", " - s390/pci: Handle PCI error codes other than 0x3a", " - bpf: fix kfunc btf caching for modules", " - iio: frequency: {admv4420,adrf6780}: format Kconfig entries", " - iio: frequency: admv4420: fix missing select REMAP_SPI in Kconfig", " - drm/vmwgfx: Handle possible ENOMEM in vmw_stdu_connector_atomic_check", " - selftests/bpf: Fix cross-compiling urandom_read", " - bpf: Fix unpopulated path_size when uprobe_multi fields unset", " - sched/core: Disable page allocation in task_tick_mm_cid()", " - ALSA: hda/cs8409: Fix possible NULL dereference", " - firmware: arm_scmi: Fix the double free in scmi_debugfs_common_setup()", " - RDMA/cxgb4: Fix RDMA_CM_EVENT_UNREACHABLE error for iWARP", " - RDMA/irdma: Fix misspelling of \"accept*\"", " - RDMA/srpt: Make slab cache names unique", " - elevator: do not request_module if elevator exists", " - elevator: Remove argument from elevator_find_get", " - ipv4: give an IPv4 dev to blackhole_netdev", " - net: sparx5: fix source port register when mirroring", " - RDMA/bnxt_re: Fix the max CQ WQEs for older adapters", " - RDMA/bnxt_re: Fix out of bound check", " - RDMA/bnxt_re: Fix incorrect dereference of srq in async event", " - RDMA/bnxt_re: Return more meaningful error", " - RDMA/bnxt_re: Avoid CPU lockups due fifo occupancy check loop", " - RDMA/bnxt_re: Get the toggle bits from SRQ events", " - RDMA/bnxt_re: Change the sequence of updating the CQ toggle value", " - RDMA/bnxt_re: Fix a bug while setting up Level-2 PBL pages", " - RDMA/bnxt_re: Fix the GID table length", " - accel/qaic: Fix the for loop used to walk SG table", " - drm/panel: himax-hx83102: Adjust power and gamma to optimize brightness", " - drm/msm/dpu: make sure phys resources are properly initialized", " - drm/msm/dpu: move CRTC resource assignment to dpu_encoder_virt_atomic_check", " - drm/msm/dpu: check for overflow in _dpu_crtc_setup_lm_bounds()", " - drm/msm/dsi: improve/fix dsc pclk calculation", " - drm/msm/dsi: fix 32-bit signed integer extension in pclk_rate calculation", " - drm/msm: Avoid NULL dereference in msm_disp_state_print_regs()", " - drm/msm: Allocate memory for disp snapshot with kvzalloc()", " - firmware: arm_scmi: Queue in scmi layer for mailbox implementation", " - net/smc: Fix memory leak when using percpu refs", " - [PATCH} hwmon: (jc42) Properly detect TSE2004-compliant devices again", " - net: usb: usbnet: fix race in probe failure", " - net: stmmac: dwmac-tegra: Fix link bring-up sequence", " - octeontx2-af: Fix potential integer overflows on integer shifts", " - ring-buffer: Fix reader locking when changing the sub buffer order", " - drm/amd/amdgpu: Fix double unlock in amdgpu_mes_add_ring", " - macsec: don't increment counters for an unrelated SA", " - netdevsim: use cond_resched() in nsim_dev_trap_report_work()", " - net: ethernet: aeroflex: fix potential memory leak in", " greth_start_xmit_gbit()", " - net/smc: Fix searching in list of known pnetids in smc_pnet_add_pnetid", " - net: xilinx: axienet: fix potential memory leak in axienet_start_xmit()", " - net: ethernet: rtsn: fix potential memory leak in rtsn_start_xmit()", " - bpf: Fix truncation bug in coerce_reg_to_size_sx()", " - net: systemport: fix potential memory leak in bcm_sysport_xmit()", " - irqchip/renesas-rzg2l: Fix missing put_device", " - drm/msm/dpu: Don't always set merge_3d pending flush", " - drm/msm/dpu: don't always program merge_3d block", " - net: bcmasp: fix potential memory leak in bcmasp_xmit()", " - drm/msm/a6xx+: Insert a fence wait before SMMU table update", " - tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink().", " - net: dsa: mv88e6xxx: Fix the max_vid definition for the MV88E6361", " - genetlink: hold RCU in genlmsg_mcast()", " - ravb: Remove setting of RX software timestamp", " - net: ravb: Only advertise Rx/Tx timestamps if hardware supports it", " - net: dsa: vsc73xx: fix reception from VLAN-unaware bridges", " - scsi: target: core: Fix null-ptr-deref in target_alloc_device()", " - smb: client: fix possible double free in smb2_set_ea()", " - smb: client: fix OOBs when building SMB2_IOCTL request", " - usb: typec: altmode should keep reference to parent", " - s390: Initialize psw mask in perf_arch_fetch_caller_regs()", " - drm/xe: fix unbalanced rpm put() with fence_fini()", " - drm/xe: fix unbalanced rpm put() with declare_wedged()", " - drm/xe: Take job list lock in xe_sched_add_pending_job", " - drm/xe: Don't free job in TDR", " - drm/xe: Use bookkeep slots for external BO's in exec IOCTL", " - bpf: Fix link info netfilter flags to populate defrag flag", " - Bluetooth: bnep: fix wild-memory-access in proto_unregister", " - vmxnet3: Fix packet corruption in vmxnet3_xdp_xmit_frame", " - net: ethernet: mtk_eth_soc: fix memory corruption during fq dma init", " - net/mlx5: Check for invalid vector index on EQ creation", " - net/mlx5: Fix command bitmask initialization", " - net/mlx5: Unregister notifier on eswitch init failure", " - net/mlx5e: Don't call cleanup on profile rollback failure", " - bpf, sockmap: SK_DROP on attempted redirects of unsupported af_vsock", " - vsock: Update rx_bytes on read_skb()", " - vsock: Update msg_count on read_skb()", " - bpf, vsock: Drop static vsock_bpf_prot initialization", " - riscv, bpf: Make BPF_CMPXCHG fully ordered", " - nvme-pci: fix race condition between reset and nvme_dev_disable()", " - bpf: Fix iter/task tid filtering", " - bpf: Fix incorrect delta propagation between linked registers", " - bpf: Fix print_reg_state's constant scalar dump", " - cdrom: Avoid barrier_nospec() in cdrom_ioctl_media_changed()", " - fgraph: Allocate ret_stack_list with proper size", " - mm: shmem: rename shmem_is_huge() to shmem_huge_global_enabled()", " - mm: shmem: move shmem_huge_global_enabled() into", " shmem_allowable_huge_orders()", " - mm: huge_memory: add vma_thp_disabled() and thp_disabled_by_hw()", " - mm: don't install PMD mappings when THPs are disabled by the hw/process/vma", " - iio: adc: ti-lmp92064: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - xhci: dbgtty: remove kfifo_out() wrapper", " - xhci: dbgtty: use kfifo from tty_port struct", " - xhci: dbc: honor usb transfer size boundaries.", " - uprobe: avoid out-of-bounds memory access of fetching args", " - drm/vboxvideo: Replace fake VLA at end of vbva_mouse_pointer_shape with real", " VLA", " - ASoC: amd: yc: Add quirk for HP Dragonfly pro one", " - ASoC: codecs: lpass-rx-macro: add missing CDC_RX_BCL_VBAT_RF_PROC2 to", " default regs values", " - ASoC: fsl_sai: Enable 'FIFO continue on error' FCONT bit", " - arm64: Force position-independent veneers", " - udf: refactor udf_current_aext() to handle error", " - udf: refactor udf_next_aext() to handle error", " - udf: refactor inode_bmap() to handle error", " - udf: fix uninit-value use in udf_get_fileshortad", " - ASoC: qcom: sm8250: add qrb4210-rb2-sndcard compatible string", " - fsnotify: Avoid data race between fsnotify_recalc_mask() and", " fsnotify_object_watched()", " - drm/xe/mcr: Use Xe2_LPM steering tables for Xe2_HPM", " - cifs: Validate content of NFS reparse point buffer", " - LoongArch: Don't crash in stack_top() for tasks without vDSO", " - objpool: fix choosing allocation for percpu slots", " - jfs: Fix sanity check in dbMount", " - tracing/probes: Fix MAX_TRACE_ARGS limit handling", " - tracing: Consider the NULL character when validating the event length", " - xfrm: extract dst lookup parameters into a struct", " - xfrm: respect ip protocols rules criteria when performing dst lookups", " - xfrm: validate new SA's prefixlen using SA family when sel.family is unset", " - netfilter: bpf: must hold reference on net namespace", " - net: pse-pd: Fix out of bound for loop", " - net/sun3_82586: fix potential memory leak in sun3_82586_send_packet()", " - be2net: fix potential memory leak in be_xmit()", " - net: plip: fix break; causing plip to never transmit", " - bnxt_en: replace ptp_lock with irqsave variant", " - octeon_ep: Implement helper for iterating packets in Rx queue", " - octeon_ep: Add SKB allocation failures handling in __octep_oq_process_rx()", " - net: dsa: mv88e6xxx: Fix error when setting port policy on mv88e6393x", " - bpf, arm64: Fix address emission with tag-based KASAN enabled", " - fsl/fman: Save device references taken in mac_probe()", " - fsl/fman: Fix refcount handling of fman-related devices", " - net: wwan: fix global oob in wwan_rtnl_policy", " - net: fix races in netdev_tx_sent_queue()/dev_watchdog()", " - virtio_net: fix integer overflow in stats", " - mlxsw: spectrum_router: fix xa_store() error checking", " - net: usb: usbnet: fix name regression", " - bpf: Preserve param->string when parsing mount options", " - bpf: Add MEM_WRITE attribute", " - bpf: Fix overloading of MEM_UNINIT's meaning", " - bpf: Remove MEM_UNINIT from skb/xdp MTU helpers", " - net/sched: act_api: deny mismatched skip_sw/skip_hw flags for actions", " created by classifiers", " - net: sched: fix use-after-free in taprio_change()", " - net: sched: use RCU read-side critical section in taprio_dump()", " - r8169: avoid unsolicited interrupts", " - posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime()", " - Bluetooth: hci_core: Disable works on hci_unregister_dev", " - Bluetooth: SCO: Fix UAF on sco_sock_timeout", " - Bluetooth: ISO: Fix UAF on iso_sock_timeout", " - bpf,perf: Fix perf_event_detach_bpf_prog error handling", " - bpf: fix do_misc_fixups() for bpf_get_branch_snapshot()", " - net: dsa: microchip: disable EEE for KSZ879x/KSZ877x/KSZ876x", " - net: dsa: mv88e6xxx: group cycle counter coefficients", " - net: dsa: mv88e6xxx: read cycle counter period from hardware", " - net: dsa: mv88e6xxx: support 4000ps cycle counter period", " - bpf: Add the missing BPF_LINK_TYPE invocation for sockmap", " - ASoC: dt-bindings: davinci-mcasp: Fix interrupts property", " - ASoC: dt-bindings: davinci-mcasp: Fix interrupt properties", " - ASoC: loongson: Fix component check failed on FDT systems", " - ASoC: topology: Bump minimal topology ABI version", " - ASoC: max98388: Fix missing increment of variable slot_found", " - ASoC: rsnd: Fix probe failure on HiHope boards due to endpoint parsing", " - PCI: Hold rescan lock while adding devices during host probe", " - fs: pass offset and result to backing_file end_write() callback", " - fuse: update inode size after extending passthrough write", " - ASoC: fsl_micfil: Add a flag to distinguish with different volume control", " types", " - ALSA: firewire-lib: Avoid division by zero in apply_constraint_to_size()", " - fbdev: wm8505fb: select CONFIG_FB_IOMEM_FOPS", " - powercap: dtpm_devfreq: Fix error check against dev_pm_qos_add_request()", " - nfsd: cancel nfsd_shrinker_work using sync mode in nfs4_state_shutdown_net", " - ALSA: hda/realtek: Update default depop procedure", " - smb: client: Handle kstrdup failures for passwords", " - cifs: fix warning when destroy 'cifs_io_request_pool'", " - PCI/pwrctl: Add WCN6855 support", " - PCI/pwrctl: Abandon QCom WCN probe on pre-pwrseq device-trees", " - cpufreq: CPPC: fix perf_to_khz/khz_to_perf conversion exception", " - btrfs: qgroup: set a more sane default value for subtree drop threshold", " - btrfs: clear force-compress on remount when compress mount option is given", " - btrfs: fix passing 0 to ERR_PTR in btrfs_search_dir_index_item()", " - perf/x86/rapl: Fix the energy-pkg event for AMD CPUs", " - btrfs: reject ro->rw reconfiguration if there are hard ro requirements", " - btrfs: zoned: fix zone unusable accounting for freed reserved extent", " - btrfs: fix read corruption due to race with extent map merging", " - drm/amd: Guard against bad data for ATIF ACPI method", " - ACPI: resource: Add LG 16T90SP to irq1_level_low_skip_override[]", " - ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context", " - ACPI: button: Add DMI quirk for Samsung Galaxy Book2 to fix initial lid", " detection issue", " - nilfs2: fix kernel bug due to missing clearing of buffer delay flag", " - fs: don't try and remove empty rbtree node", " - xfs: don't fail repairs on metadata files with no attr fork", " - openat2: explicitly return -E2BIG for (usize > PAGE_SIZE)", " - KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory", " - KVM: arm64: Unregister redistributor for failed vCPU creation", " - KVM: arm64: Fix shift-out-of-bounds bug", " - KVM: arm64: Don't eagerly teardown the vgic on init error", " - firewire: core: fix invalid port index for parent device", " - x86/lam: Disable ADDRESS_MASKING in most cases", " - [Config] updateconfigs to disable ADDRESS_MASKING", " - x86/sev: Ensure that RMP table fixups are reserved", " - ALSA: hda/tas2781: select CRC32 instead of CRC32_SARWATE", " - ALSA: hda/realtek: Add subwoofer quirk for Acer Predator G9-593", " - LoongArch: Get correct cores_per_package for SMT systems", " - LoongArch: Enable IRQ if do_ale() triggered in irq-enabled context", " - LoongArch: Make KASAN usable for variable cpu_vabits", " - xfrm: fix one more kernel-infoleak in algo dumping", " - hv_netvsc: Fix VF namespace also in synthetic NIC NETDEV_REGISTER event", " - md/raid10: fix null ptr dereference in raid10_size()", " - drm/bridge: Fix assignment of the of_node of the parent to aux bridge", " - drm/amd/display: Disable PSR-SU on Parade 08-01 TCON too", " - platform/x86/intel/pmc: Fix pmc_core_iounmap to call iounmap for valid", " addresses", " - fgraph: Fix missing unlock in register_ftrace_graph()", " - fgraph: Change the name of cpuhp state to \"fgraph:online\"", " - net: phy: dp83822: Fix reset pin definitions", " - nfsd: fix race between laundromat and free_stateid", " - drm/amd/display: temp w/a for DP Link Layer compliance", " - ata: libata: Set DID_TIME_OUT for commands that actually timed out", " - ASoC: SOF: Intel: hda-loader: do not wait for HDaudio IOC", " - ASoC: SOF: Intel: hda: Handle prepare without close for non-HDA DAI's", " - ASoC: SOF: Intel: hda: Always clean up link DMA during stop", " - ASoC: SOF: ipc4-topology: Do not set ALH node_id for aggregated DAIs", " - ASoC: dapm: avoid container_of() to get component", " - ASoC: qcom: sc7280: Fix missing Soundwire runtime stream alloc", " - ASoC: qcom: sdm845: add missing soundwire runtime stream alloc", " - ASoC: qcom: Fix NULL Dereference in asoc_qcom_lpass_cpu_platform_probe()", " - Revert \" fs/9p: mitigate inode collisions\"", " - Revert \"fs/9p: remove redundant pointer v9ses\"", " - Revert \"fs/9p: fix uaf in in v9fs_stat2inode_dotl\"", " - Revert \"fs/9p: simplify iget to remove unnecessary paths\"", " - soundwire: intel_ace2x: Send PDI stream number during prepare", " - x86: support user address masking instead of non-speculative conditional", " - x86: fix whitespace in runtime-const assembler output", " - x86: fix user address masking non-canonical speculation issue", " - platform/x86: dell-wmi: Ignore suspend notifications", " - ACPI: PRM: Clean up guid type in struct prm_handler_info", " - ASoC: qcom: Select missing common Soundwire module code on SDM845", " - Linux 6.11.6", "", " * ovs/linuxbridge jobs running on ubuntu jammy broken with latest kernel", " 5.15.0-127.137 (LP: #2091990)", " - netfilter: xtables: fix typo causing some targets not to load on IPv6", "", " * By always inlining _compound_head(), clone() sees 3%+ performance increase", " (LP: #2089327)", " - mm: always inline _compound_head() with", " CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP=y", "", " * Keyboard backlight controls do not work on Asus ROG Zephyrus GA503RM in", " Oracular (LP: #2089113)", " - hid-asus: use hid for brightness control on keyboard", "", " * Random flickering with Intel i915 (Comet Lake and Kaby Lake) on Linux 6.8+", " (LP: #2086587)", " - SAUCE: iommu/intel: disable DMAR for KBL and CML integrated gfx", "", " * Add list of source files to linux-buildinfo (LP: #2086606)", " - [Packaging] Sort build dependencies alphabetically", " - [Packaging] Add list of used source files to buildinfo package", "", " * asus: Fix thermal profile initialization on Lunar Lake (LP: #2085950)", " - platform/x86: asus-wmi: Fix thermal profile initialization", "", " * drm/xe: Fix LNL getting wedged after idling (LP: #2085944)", " - drm/xe/guc/ct: Flush g2h worker in case of g2h response timeout", "", " * UFS: uspi->s_3apb UBSAN: shift-out-of-bounds (LP: #2087853)", " - ufs: ufs_sb_private_info: remove unused s_{2, 3}apb fields", "", " * Mute/mic LEDs don't function on HP EliteBook 645 G10 (LP: #2087983)", " - ALSA: hda/realtek: fix mute/micmute LEDs for a HP EliteBook 645 G10", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152)", " - ALSA: scarlett2: Add error check after retrieving PEQ filter values", " - ALSA: hda/conexant - Fix audio routing for HP EliteOne 1000 G2", " - net: enetc: remove xdp_drops statistic from enetc_xdp_drop()", " - net: enetc: block concurrent XDP transmissions during ring reconfiguration", " - net: enetc: disable Tx BD rings after they are empty", " - net: enetc: disable NAPI after all rings are disabled", " - net: enetc: add missing static descriptor and inline keyword", " - udp: Compute L4 checksum as usual when not segmenting the skb", " - arm64: dts: marvell: cn9130-sr-som: fix cp0 mdio pin numbers", " - arm64: probes: Fix simulate_ldr*_literal()", " - net: macb: Avoid 20s boot delay by skipping MDIO bus registration for fixed-", " link PHY", " - selftests: mptcp: join: test for prohibited MPC to port-based endp", " - fat: fix uninitialized variable", " - mm: khugepaged: fix the arguments order in khugepaged_collapse_file trace", " point", " - net: fec: Move `fec_ptp_read()` to the top of the file", " - net: fec: Remove duplicated code", " - mptcp: prevent MPC handshake on port-based signal endpoints", " - s390/sclp: Deactivate sclp after all its users", " - s390/sclp_vt220: Convert newlines to CRLF instead of LFCR", " - KVM: s390: gaccess: Check if guest address is in memslot", " - KVM: s390: Change virtual to physical address access in diag 0x258 handler", " - x86/cpufeatures: Define X86_FEATURE_AMD_IBPB_RET", " - x86/cpufeatures: Add a IBPB_NO_RET BUG flag", " - x86/entry: Have entry_ibpb() invalidate return predictions", " - x86/bugs: Skip RSB fill at VMEXIT", " - x86/bugs: Do not use UNTRAIN_RET with IBPB on entry", " - fgraph: Use CPU hotplug mechanism to initialize idle shadow stacks", " - Input: xpad - add support for 8BitDo Ultimate 2C Wireless Controller", " - io_uring/sqpoll: close race on waiting for sqring entries", " - selftest: hid: add the missing tests directory", " - Input: xpad - add support for MSI Claw A1M", " - scsi: mpi3mr: Validate SAS port assignments", " - scsi: ufs: core: Fix the issue of ICU failure", " - scsi: ufs: core: Requeue aborted request", " - drm/i915/dp_mst: Handle error during DSC BW overhead/slice calculation", " - drm/i915/dp_mst: Don't require DSC hblank quirk for a non-DSC compatible", " mode", " - drm/xe/xe_sync: initialise ufence.signalled", " - drm/xe/ufence: ufence can be signaled right after wait_woken", " - drm/vmwgfx: Cleanup kms setup without 3d", " - drm/vmwgfx: Handle surface check failure correctly", " - drm/amdgpu/mes: fix issue of writing to the same log buffer from 2 MES pipes", " - drm/amdgpu/smu13: always apply the powersave optimization", " - drm/amdgpu/swsmu: Only force workload setup on init", " - drm/amdgpu: prevent BO_HANDLES error from being overwritten", " - iio: dac: ad5770r: add missing select REGMAP_SPI in Kconfig", " - iio: dac: ltc1660: add missing select REGMAP_SPI in Kconfig", " - iio: dac: stm32-dac-core: add missing select REGMAP_MMIO in Kconfig", " - iio: adc: ti-ads8688: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: hid-sensors: Fix an error handling path in", " _hid_sensor_set_report_latency()", " - iio: light: veml6030: fix ALS sensor resolution", " - iio: light: opt3001: add missing full-scale range value", " - iio: amplifiers: ada4250: add missing select REGMAP_SPI in Kconfig", " - iio: frequency: adf4377: add missing select REMAP_SPI in Kconfig", " - iio: chemical: ens160: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: light: bu27008: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: magnetometer: af8133j: add missing select IIO_(TRIGGERED_)BUFFER in", " Kconfig", " - iio: resolver: ad2s1210 add missing select REGMAP in Kconfig", " - iio: pressure: bm1390: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: dac: ad5766: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: proximity: mb1232: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: dac: ad3552r: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: adc: ti-lmp92064: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: adc: ti-lmp92064: add missing select REGMAP_SPI in Kconfig", " - iio: adc: ti-ads124s08: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: resolver: ad2s1210: add missing select (TRIGGERED_)BUFFER in Kconfig", " - iio: adc: ad7944: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: accel: kx022a: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - Bluetooth: Remove debugfs directory on module init failure", " - Bluetooth: btusb: Fix not being able to reconnect after suspend", " - Bluetooth: btusb: Fix regression with fake CSR controllers 0a12:0001", " - xhci: Fix incorrect stream context type macro", " - xhci: Mitigate failed set dequeue pointer commands", " - USB: serial: option: add support for Quectel EG916Q-GL", " - USB: serial: option: add Telit FN920C04 MBIM compositions", " - usb: typec: qcom-pmic-typec: fix sink status being overwritten with RP_DEF", " - usb: gadget: f_uac2: fix return value for UAC2_ATTRIBUTE_STRING store", " - usb: dwc3: Wait for EndXfer completion before restoring GUSB2PHYCFG", " - usb: dwc3: core: Fix system suspend on TI AM62 platforms", " - misc: microchip: pci1xxxx: add support for NVMEM_DEVID_AUTO for EEPROM", " device", " - misc: microchip: pci1xxxx: add support for NVMEM_DEVID_AUTO for OTP device", " - serial: imx: Update mctrl old_status on RTSD interrupt", " - x86/resctrl: Annotate get_mem_config() functions as __init", " - x86/CPU/AMD: Only apply Zenbleed fix for Zen2 during late microcode load", " - x86/entry_32: Do not clobber user EFLAGS.ZF", " - irqchip/sifive-plic: Unmask interrupt in plic_irq_enable()", " - irqchip/sifive-plic: Return error code on failure", " - serial: qcom-geni: fix polled console initialisation", " - serial: qcom-geni: revert broken hibernation support", " - serial: qcom-geni: fix shutdown race", " - serial: qcom-geni: fix dma rx cancellation", " - serial: qcom-geni: fix receiver enable", " - mm: vmscan.c: fix OOM on swap stress test", " - ALSA: hda/conexant - Use cached pin control for Node 0x1d on HP EliteOne", " 1000 G2", " - Linux 6.11.5", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50192", " - irqchip/gic-v4: Don't allow a VMOVP on a dying VPE", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50069", " - pinctrl: apple: check devm_kasprintf() returned value", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50070", " - pinctrl: stm32: check devm_kasprintf() returned value", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50196", " - pinctrl: ocelot: fix system hang on level based interrupts", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50197", " - pinctrl: intel: platform: fix error path in device_for_each_child_node()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50071", " - pinctrl: nuvoton: fix a double free in ma35_pinctrl_dt_node_to_map_func()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50072", " - x86/bugs: Use code segment selector for VERW operand", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50073", " - tty: n_gsm: Fix use-after-free in gsm_cleanup_mux", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50193", " - x86/entry_32: Clear CPU buffers after register restore in NMI return", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50074", " - parport: Proper fix for array out-of-bounds access", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50100", " - USB: gadget: dummy-hcd: Fix \"task hung\" problem", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50075", " - xhci: tegra: fix checked USB2 port number", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50076", " - vt: prevent kernel-infoleak in con_font_get()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50077", " - Bluetooth: ISO: Fix multiple init when debugfs is disabled", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50078", " - Bluetooth: Call iso_exit() on module unload", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50198", " - iio: light: veml6030: fix IIO device retrieval from embedded device", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50201", " - drm/radeon: Fix encoder->possible_clones", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50098", " - scsi: ufs: core: Set SDEV_OFFLINE when UFS is shut down", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50079", " - io_uring/sqpoll: ensure task state is TASK_RUNNING when running task_work", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50080", " - ublk: don't allow user copy for unprivileged device", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50081", " - blk-mq: setup queue ->tag_set before initializing hctx", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50082", " - blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50101", " - iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI devices", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50083", " - tcp: fix mptcp DSS corruption due to large pmtu xmit", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50068", " - mm/damon/tests/sysfs-kunit.h: fix memory leak in", " damon_sysfs_test_add_targets()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50199", " - mm/swapfile: skip HugeTLB pages for unuse_vma", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50066", " - mm/mremap: fix move_normal_pmd/retract_page_tables race", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50202", " - nilfs2: propagate directory read errors from nilfs_find_entry()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50200", " - maple_tree: correct tree corruption on spanning store", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50084", " - net: microchip: vcap api: Fix memory leaks in vcap_api_encode_rule_test()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50194", " - arm64: probes: Fix uprobes for big-endian kernels", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50099", " - arm64: probes: Remove broken LDR (literal) uprobe support", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50195", " - posix-clock: Fix missing timespec64 check in pc_clock_settime()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50085", " - mptcp: pm: fix UaF read in mptcp_pm_nl_rm_addr_or_subflow", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50086", " - ksmbd: fix user-after-free from session log off", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50087", " - btrfs: fix uninitialized pointer free on read_alloc_one_name() error", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50088", " - btrfs: fix uninitialized pointer free in add_inode_ref()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068)", " - net: fec: don't save PTP state if PTP is unsupported", " - fs/ntfs3: Do not call file_modified if collapse range failed", " - fs/ntfs3: Optimize large writes into sparse file", " - fs/ntfs3: Fix sparse warning for bigendian", " - fs/ntfs3: Fix sparse warning in ni_fiemap", " - fs/ntfs3: Refactor enum_rstbl to suppress static checker", " - vdpa/octeon_ep: Fix format specifier for pointers in debug messages", " - virtio_console: fix misc probe bugs", " - perf vdso: Missed put on 32-bit dsos", " - perf build: Fix static compilation error when libdw is not installed", " - perf build: Fix build feature-dwarf_getlocations fail for old libdw", " - zram: don't free statically defined names", " - bpf: Call the missed btf_record_free() when map creation fails", " - selftests/bpf: Fix ARG_PTR_TO_LONG {half-,}uninitialized test", " - bpf: Check percpu map value size first", " - s390/facility: Disable compile time optimization for decompressor code", " - s390/mm: Add cond_resched() to cmm_alloc/free_pages()", " - bpf, x64: Fix a jit convergence issue", " - ext4: nested locking for xattr inode", " - s390/cpum_sf: Remove WARN_ON_ONCE statements", " - s390/traps: Handle early warnings gracefully", " - ktest.pl: Avoid false positives with grub2 skip regex", " - soundwire: intel_bus_common: enable interrupts before exiting reset", " - PCI: Add function 0 DMA alias quirk for Glenfly Arise chip", " - clk: bcm: bcm53573: fix OF node leak in init", " - PCI: Add ACS quirk for Qualcomm SA8775P", " - i2c: i801: Use a different adapter-name for IDF adapters", " - PCI: Mark Creative Labs EMU20k2 INTx masking as broken", " - RISC-V: Don't have MAX_PHYSMEM_BITS exceed phys_addr_t", " - mfd: intel_soc_pmic_chtwc: Make Lenovo Yoga Tab 3 X90F DMI match less strict", " - mfd: intel-lpss: Add Intel Panther Lake LPSS PCI IDs", " - riscv: Omit optimized string routines when using KASAN", " - riscv: avoid Imbalance in RAS", " - RDMA/mlx5: Enforce umem boundaries for explicit ODP page faults", " - PCI: qcom: Disable mirroring of DBI and iATU register space in BAR region", " - PCI: endpoint: Assign PCI domain number for endpoint controllers", " - soundwire: cadence: re-check Peripheral status with delayed_work", " - riscv/kexec_file: Fix relocation type R_RISCV_ADD16 and R_RISCV_SUB16", " unknown", " - media: videobuf2-core: clear memory related fields in", " __vb2_plane_dmabuf_put()", " - remoteproc: imx_rproc: Use imx specific hook for find_loaded_rsc_table", " - usb: chipidea: udc: enable suspend interrupt after usb reset", " - usb: dwc2: Adjust the timing of USB Driver Interrupt Registration in the", " Crashkernel Scenario", " - xhci: dbc: Fix STALL transfer event handling", " - usb: host: xhci-plat: Parse xhci-missing_cas_quirk and apply quirk", " - comedi: ni_routing: tools: Check when the file could not be opened", " - LoongArch: Fix memleak in pci_acpi_scan_root()", " - netfilter: nf_nat: don't try nat source port reallocation for reverse dir", " clash", " - netfilter: nf_reject: Fix build warning when CONFIG_BRIDGE_NETFILTER=n", " - tools/iio: Add memory allocation failure check for trigger_name", " - staging: vme_user: added bound check to geoid", " - driver core: bus: Return -EIO instead of 0 when show/store invalid bus", " attribute", " - scsi: lpfc: Add ELS_RSP cmd to the list of WQEs to flush in", " lpfc_els_flush_cmd()", " - scsi: lpfc: Revise TRACE_EVENT log flag severities from KERN_ERR to", " KERN_WARNING", " - NFSD: Mark filecache \"down\" if init fails", " - nfsd: nfsd_destroy_serv() must call svc_destroy() even if nfsd_startup_net()", " failed", " - ice: set correct dst VSI in only LAN filters", " - ice: clear port vlan config during reset", " - ice: disallow DPLL_PIN_STATE_SELECTABLE for dpll output pins", " - ice: fix VLAN replay after reset", " - SUNRPC: Fix integer overflow in decode_rc_list()", " - net: phy: aquantia: AQR115c fix up PMA capabilities", " - net: phy: aquantia: remove usage of phy_set_max_speed", " - tcp: fix to allow timestamp undo if no retransmits were sent", " - tcp: fix tcp_enter_recovery() to zero retrans_stamp when it's safe", " - tcp: fix TFO SYN_RECV to not zero retrans_stamp with retransmits out", " - rxrpc: Fix uninitialised variable in rxrpc_send_data()", " - net: dsa: sja1105: fix reception from VLAN-unaware bridges", " - selftests: net: no_forwarding: fix VID for $swp2 in one_bridge_two_pvids()", " test", " - net: pse-pd: Fix enabled status mismatch", " - Bluetooth: btusb: Don't fail external suspend requests", " - net: phy: bcm84881: Fix some error handling paths", " - net: ethernet: adi: adin1110: Fix some error handling path in", " adin1110_read_fifo()", " - net: dsa: b53: fix jumbo frame mtu check", " - net: dsa: b53: fix max MTU for 1g switches", " - net: dsa: b53: fix max MTU for BCM5325/BCM5365", " - net: dsa: b53: allow lower MTUs on BCM5325/5365", " - net: dsa: b53: fix jumbo frames on 10/100 ports", " - drm/nouveau: pass cli to nouveau_channel_new() instead of drm+device", " - nouveau/dmem: Fix privileged error in copy engine channel", " - gpio: aspeed: Add the flush write to ensure the write complete.", " - gpio: aspeed: Use devm_clk api to manage clock source", " - x86/xen: mark boot CPU of PV guest in MSR_IA32_APICBASE", " - powercap: intel_rapl_tpmi: Ignore minor version change", " - ice: Fix entering Safe Mode", " - ice: Fix netif_is_ice() in Safe Mode", " - ice: Flush FDB entries before reset", " - drm/xe: Restore GT freq on GSC load error", " - drm/xe: Make wedged_mode debugfs writable", " - net: ibm: emac: mal: fix wrong goto", " - net: ti: icssg-prueth: Fix race condition for VLAN table access", " - btrfs: zoned: fix missing RCU locking in error message when loading zone", " info", " - sctp: ensure sk_state is set to CLOSED if hashing fails in sctp_listen_start", " - netfilter: fib: check correct rtable in vrf setups", " - net: ibm: emac: mal: add dcr_unmap to _remove", " - net: dsa: refuse cross-chip mirroring operations", " - rtnetlink: Add bulk registration helpers for rtnetlink message handlers.", " - vxlan: Handle error of rtnl_register_module().", " - bridge: Handle error of rtnl_register_module().", " - mctp: Handle error of rtnl_register_module().", " - mpls: Handle error of rtnl_register_module().", " - phonet: Handle error of rtnl_register_module().", " - rcu/nocb: Fix rcuog wake-up from offline softirq", " - HID: multitouch: Add support for lenovo Y9000P Touchpad", " - hwmon: intel-m10-bmc-hwmon: relabel Columbiaville to CVL Die Temperature", " - hwmon: (tmp513) Add missing dependency on REGMAP_I2C", " - hwmon: (mc34vr500) Add missing dependency on REGMAP_I2C", " - hwmon: (adm9240) Add missing dependency on REGMAP_I2C", " - hwmon: (adt7470) Add missing dependency on REGMAP_I2C", " - hwmon: (ltc2991) Add missing dependency on REGMAP_I2C", " - HID: plantronics: Workaround for an unexcepted opposite volume key", " - HID: wacom: Hardcode (non-inverted) AES pens as BTN_TOOL_PEN", " - Revert \"usb: yurex: Replace snprintf() with the safer scnprintf() variant\"", " - usb: dwc3: core: Stop processing of pending events if controller is halted", " - usb: xhci: Fix problem with xhci resume from suspend", " - usb: storage: ignore bogus device raised by JieLi BR21 USB sound chip", " - usb: dwc3: re-enable runtime PM after failed resume", " - usb: gadget: core: force synchronous registration", " - hid: intel-ish-hid: Fix uninitialized variable 'rv' in", " ish_fw_xfer_direct_dma", " - ACPI: resource: Make Asus ExpertBook B2402 matches cover more models", " - ACPI: resource: Make Asus ExpertBook B2502 matches cover more models", " - drm/amdgpu: partially revert powerplay `__counted_by` changes", " - drm/amd/display: Clear update flags after update has been applied", " - drm/amdkfd: Fix an eviction fence leak", " - drm/amd/display: fix hibernate entry for DCN35+", " - drm/xe/guc_submit: fix xa_store() error checking", " - drm/i915/hdcp: fix connector refcounting", " - drm/xe/ct: fix xa_store() error checking", " - scsi: ufs: Use pre-calculated offsets in ufshcd_init_lrb()", " - Revert \"mmc: mvsdio: Use sg_miter for PIO\"", " - mmc: sdhci-of-dwcmshc: Prevent stale command interrupt handling", " - mptcp: fallback when MPTCP opts are dropped after 1st data", " - ata: libata: avoid superfluous disk spin down + spin up during hibernation", " - OPP: fix error code in dev_pm_opp_set_config()", " - net: dsa: lan9303: ensure chip reset and wait for READY status", " - net: phy: realtek: Fix MMD access on RTL8126A-integrated PHY", " - mptcp: pm: do not remove closing subflows", " - powercap: intel_rapl_tpmi: Fix bogus register reading", " - selftests/mm: fix incorrect buffer->mirror size in hmm2 double_map test", " - selftests/rseq: Fix mm_cid test failure", " - btrfs: split remaining space to discard in chunks", " - btrfs: add cancellation points to trim loops", " - PM: domains: Fix alloc/free in dev_pm_domain_attach|detach_list()", " - idpf: use actual mbx receive payload length", " - fs/proc/kcore.c: allow translation of physical memory addresses", " - PCI: Pass domain number to pci_bus_release_domain_nr() explicitly", " - io_uring/rw: fix cflags posting for single issue multishot read", " - Linux 6.11.4", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50182", " - secretmem: disable memfd_secret() if arch cannot set direct map", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50019", " - kthread: unpark only parked kthread", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50096", " - nouveau/dmem: Fix vulnerability in migrate_to_ram upon copy error", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50020", " - ice: Fix improper handling of refcount in ice_sriov_set_msix_vec_count()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50021", " - ice: Fix improper handling of refcount in ice_dpll_init_rclk_pins()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50022", " - device-dax: correct pgoff align in dax_set_mapping()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50185", " - mptcp: handle consistently DSS corruption", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50023", " - net: phy: Remove LED entry from LEDs list on unregister", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50024", " - net: Fix an unsafe loop on the list", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50186", " - net: explicitly clear the sk pointer, when pf->create fails", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50025", " - scsi: fnic: Move flush_work initialization out of if block", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50026", " - scsi: wd33c93: Don't use stale scsi_pointer value", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50027", " - thermal: core: Free tzp copy along with the thermal zone", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50028", " - thermal: core: Reference count the zone in thermal_zone_get_by_id()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50029", " - Bluetooth: hci_conn: Fix UAF in hci_enhanced_setup_sync", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50030", " - drm/xe/ct: prevent UAF in send_recv()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50187", " - drm/vc4: Stop the active perfmon before being destroyed", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50031", " - drm/v3d: Stop the active perfmon before being destroyed", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50189", " - HID: amd_sfh: Switch to device-managed dmam_alloc_coherent()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50033", " - slip: make slhc_remember() more robust against malicious packets", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50034", " - net/smc: fix lacks of icsk_syn_mss with IPPROTO_SMC", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50035", " - ppp: fix ppp_async_encode() illegal access", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50036", " - net: do not delay dst_entries_add() in dst_release()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50037", " - drm/fbdev-dma: Only cleanup deferred I/O if necessary", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50092", " - net: netconsole: fix wrong warning", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50038", " - netfilter: xtables: avoid NFPROTO_UNSPEC where needed", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50039", " - net/sched: accept TCA_STAB only for root qdisc", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50040", " - igb: Do not bring the device up after non-fatal error", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50041", " - i40e: Fix macvlan leak by synchronizing access to mac_filter_hash", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50042", " - ice: Fix increasing MSI-X on VF", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50093", " - thermal: intel: int340x: processor: Fix warning during module unload", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50043", " - nfsd: fix possible badness in FREE_STATEID", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50044", " - Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50045", " - netfilter: br_netfilter: fix panic with metadata_dst skb", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50094", " - sfc: Don't invoke xdp_do_flush() from netpoll.", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50188", " - net: phy: dp83869: fix memory corruption when enabling fiber", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50046", " - NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50190", " - ice: fix memleak in ice_init_tx_topology()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50180", " - fbdev: sisfb: Fix strbuf array overflow", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50047", " - smb: client: fix UAF in async decryption", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50048", " - fbcon: Fix a NULL pointer dereference issue in fbcon_putcs", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50049", " - drm/amd/display: Check null pointer before dereferencing se", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50090", " - drm/xe/oa: Fix overflow in oa batch buffer", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50183", " - scsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV", " instance", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50055", " - driver core: bus: Fix double free in driver API bus_register()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50091", " - dm vdo: don't refer to dedupe_context after releasing it", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50056", " - usb: gadget: uvc: Fix ERR_PTR dereference in uvc_v4l2.c", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50184", " - virtio_pmem: Check device status before requesting flush", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50057", " - usb: typec: tipd: Free IRQ only if it was requested before", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50058", " - serial: protect uart_port_dtr_rts() in uart_shutdown() too", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50181", " - clk: imx: Remove CLK_SET_PARENT_GATE for DRAM mux for i.MX7D", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50059", " - ntb: ntb_hw_switchtec: Fix use after free vulnerability in", " switchtec_ntb_remove due to race condition", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50060", " - io_uring: check if we need to reschedule during overflow flush", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50061", " - i3c: master: cdns: Fix use after free vulnerability in cdns_i3c_master", " Driver Due to Race Condition", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50062", " - RDMA/rtrs-srv: Avoid null pointer deref during path establishment", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50095", " - RDMA/mad: Improve handling of timed out WRs of mad agent", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50063", " - bpf: Prevent tail call between progs attached to different hooks", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50191", " - ext4: don't set SB_RDONLY after filesystem errors", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50064", " - zram: free secondary algorithms names", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50065", " - ntfs3: Change to non-blocking allocation in ntfs_d_hash", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50089", " - unicode: Don't special case ignorable code points", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052)", " - jump_label: Fix static_key_slow_dec() yet again", " - scsi: st: Fix input/output error on empty drive reset", " - scsi: pm8001: Do not overwrite PCI queue mapping", " - drm/i915/psr: Do not wait for PSR being idle on on Panel Replay", " - drm/i915/display: BMG supports UHBR13.5", " - drm/i915/dp: Fix AUX IO power enabling for eDP PSR", " - drm/amdgpu: Fix get each xcp macro", " - drm/amd/display: handle nulled pipe context in DCE110's set_drr()", " - ksmbd: fix warning: comparison of distinct pointer types lacks a cast", " - mailbox: ARM_MHU_V3 should depend on ARM64", " - [Config] updateconfigs for ARM_MHU_V3", " - mailbox: rockchip: fix a typo in module autoloading", " - ceph: fix a memory leak on cap_auths in MDS client", " - drm/i915/dp: Fix colorimetry detection", " - ieee802154: Fix build error", " - net: sparx5: Fix invalid timestamps", " - net/mlx5: Added cond_resched() to crdump collection", " - net/mlx5e: SHAMPO, Fix overflow of hd_per_wq", " - netfilter: uapi: NFTA_FLOWTABLE_HOOK is NLA_NESTED", " - net: ieee802154: mcr20a: Use IRQF_NO_AUTOEN flag in request_irq()", " - net: wwan: qcom_bam_dmux: Fix missing pm_runtime_disable()", " - selftests: netfilter: Fix nft_audit.sh for newer nft binaries", " - selftests: netfilter: Add missing return value", " - Bluetooth: btmrvl: Use IRQF_NO_AUTOEN flag in request_irq()", " - afs: Fix missing wire-up of afs_retry_request()", " - net: Add netif_get_gro_max_size helper for GRO", " - net: Fix gso_features_check to check for both dev->gso_{ipv4_,}max_size", " - net: fec: Restart PPS after link state change", " - net: fec: Reload PTP registers after link-state change", " - net: stmmac: dwmac4: extend timeout for VLAN Tag register busy bit check", " - ipv4: ip_gre: Fix drops of small packets in ipgre_xmit", " - netfs: Fix missing wakeup after issuing writes", " - net: phy: realtek: Check the index value in led_hw_control_get", " - bridge: mcast: Fail MDB get request on empty entry", " - iomap: constrain the file range passed to iomap_file_unshare", " - dt-bindings: net: xlnx,axi-ethernet: Add missing reg minItems", " - ASoC: topology: Fix incorrect addressing assignments", " - ASoC: atmel: mchp-pdmc: Skip ALSA restoration if substream runtime is", " uninitialized", " - drm/connector: hdmi: Fix writing Dynamic Range Mastering infoframes", " - io_uring: fix memory leak when cache init fail", " - rust: kbuild: split up helpers.c", " - rust: kbuild: auto generate helper exports", " - rust: mutex: fix __mutex_init() usage in case of PREEMPT_RT", " - ALSA: mixer_oss: Remove some incorrect kfree_const() usages", " - ALSA: hda/realtek: Fix the push button function for the ALC257", " - cifs: Remove intermediate object of failed create reparse call", " - drm/panthor: Lock the VM resv before calling drm_gpuvm_bo_obtain_prealloc()", " - ALSA: hda/generic: Unconditionally prefer preferred_dacs pairs", " - ASoC: imx-card: Set card.owner to avoid a warning calltrace if SND=m", " - drm/xe: Restore pci state upon resume", " - drm/xe: Resume TDR after GT reset", " - cifs: Do not convert delimiter when parsing NFS-style symlinks", " - tools/rtla: Fix installation from out-of-tree build", " - ALSA: gus: Fix some error handling paths related to get_bpos() usage", " - ALSA: hda/conexant: Fix conflicting quirk for System76 Pangolin", " - drm/amd/display: Disable replay if VRR capability is false", " - drm/amd/display: Fix VRR cannot enable", " - drm/amd/display: Re-enable panel replay feature", " - e1000e: avoid failing the system during pm_suspend", " - wifi: ath9k: fix possible integer overflow in ath9k_get_et_stats()", " - crypto: x86/sha256 - Add parentheses around macros' single arguments", " - crypto: octeontx - Fix authenc setkey", " - crypto: octeontx2 - Fix authenc setkey", " - ice: Adjust over allocation of memory in ice_sched_add_root_node() and", " ice_sched_add_node()", " - wifi: iwlwifi: mvm: Fix a race in scan abort flow", " - wifi: iwlwifi: mvm: drop wrong STA selection in TX", " - net: hisilicon: hip04: fix OF node leak in probe()", " - net: hisilicon: hns_dsaf_mac: fix OF node leak in hns_mac_get_info()", " - net: hisilicon: hns_mdio: fix OF node leak in probe()", " - ACPICA: Fix memory leak if acpi_ps_get_next_namepath() fails", " - ACPICA: Fix memory leak if acpi_ps_get_next_field() fails", " - ACPI: resource: Skip IRQ override on Asus Vivobook Go E1404GAB", " - wifi: mt76: mt7915: disable tx worker during tx BA session enable/disable", " - net: sched: consistently use rcu_replace_pointer() in taprio_change()", " - Bluetooth: btusb: Add Realtek RTL8852C support ID 0x0489:0xe122", " - Bluetooth: btrtl: Set msft ext address filter quirk for RTL8852B", " - ACPI: video: Add force_vendor quirk for Panasonic Toughbook CF-18", " - ACPI: CPPC: Add support for setting EPP register in FFH", " - wifi: rtw88: select WANT_DEV_COREDUMP", " - l2tp: free sessions using rcu", " - l2tp: use rcu list add/del when updating lists", " - ACPI: EC: Do not release locks during operation region accesses", " - net: skbuff: sprinkle more __GFP_NOWARN on ingress allocs", " - net: mvpp2: Increase size of queue_name buffer", " - bnxt_en: Extend maximum length of version string by 1 byte", " - ipv4: Check !in_dev earlier for ioctl(SIOCSIFADDR).", " - wifi: rtw89: correct base HT rate mask for firmware", " - netfilter: nf_tables: do not remove elements if set backend implements", " .abort", " - ipv4: Mask upper DSCP bits and ECN bits in NETLINK_FIB_LOOKUP family", " - nvme-keyring: restrict match length for version '1' identifiers", " - nvme-tcp: sanitize TLS key handling", " - nvme-tcp: check for invalidated or revoked key", " - net: atlantic: Avoid warning about potential string truncation", " - crypto: simd - Do not call crypto_alloc_tfm during registration", " - netpoll: Ensure clean state on setup failures", " - tcp: avoid reusing FIN_WAIT2 when trying to find port in connect() process", " - wifi: iwlwifi: mvm: use correct key iteration", " - wifi: iwlwifi: allow only CN mcc from WRDD", " - virt: sev-guest: Ensure the SNP guest messages do not exceed a page", " - wifi: mac80211: fix RCU list iterations", " - ACPICA: iasl: handle empty connection_node", " - proc: add config & param to block forcing mem writes", " - [Config] updateconfigs to select PROC_MEM_ALWAYS_FORCE", " - vfs: use RCU in ilookup", " - drivers/perf: arm_spe: Use perf_allow_kernel() for permissions", " - nvme: fix metadata handling in nvme-passthrough", " - can: netlink: avoid call to do_set_data_bittiming callback with stale", " can_priv::ctrlmode", " - netdev-genl: Set extack and fix error on napi-get", " - wifi: wilc1000: Do not operate uninitialized hardware during suspend/resume", " - arm64: trans_pgd: mark PTEs entries as valid to avoid dead kexec()", " - net: phy: Check for read errors in SIOCGMIIREG", " - x86/bugs: Add missing NO_SSB flag", " - x86/bugs: Fix handling when SRSO mitigation is disabled", " - crypto: hisilicon - fix missed error branch", " - wifi: mt76: mt7915: add dummy HW offload of IEEE 802.11 fragmentation", " - wifi: mt76: mt7915: hold dev->mt76.mutex while disabling tx worker", " - netfs: Cancel dirty folios that have no storage destination", " - nfp: Use IRQF_NO_AUTOEN flag in request_irq()", " - ALSA: usb-audio: Add input value sanity checks for standard types", " - x86/apic: Remove logical destination mode for 64-bit", " - ALSA: usb-audio: Define macros for quirk table entries", " - ALSA: usb-audio: Replace complex quirk lines with macros", " - ALSA: usb-audio: Add quirk for RME Digiface USB", " - ALSA: usb-audio: Add mixer quirk for RME Digiface USB", " - ALSA: hda/realtek: Refactor and simplify Samsung Galaxy Book init", " - ALSA: usb-audio: Add logitech Audio profile quirk", " - ASoC: codecs: wsa883x: Handle reading version failure", " - ALSA: control: Take power_ref lock primarily", " - tools/x86/kcpuid: Protect against faulty \"max subleaf\" values", " - x86/pkeys: Add PKRU as a parameter in signal handling functions", " - x86/pkeys: Restore altstack access in sigreturn()", " - x86/kexec: Add EFI config table identity mapping for kexec kernel", " - ALSA: hdsp: Break infinite MIDI input flush loop", " - tools/nolibc: powerpc: limit stack-protector workaround to GCC", " - selftests/nolibc: avoid passing NULL to printf(\"%s\")", " - x86/syscall: Avoid memcpy() for ia32 syscall_get_arguments()", " - ASoC: Intel: boards: always check the result of", " acpi_dev_get_first_match_dev()", " - hwmon: (nct6775) add G15CF to ASUS WMI monitoring list", " - pmdomain: core: Don't hold the genpd-lock when calling dev_pm_domain_set()", " - pmdomain: core: Use dev_name() instead of kobject_get_path() in debugfs", " - rcuscale: Provide clear error when async specified without primitives", " - power: reset: brcmstb: Do not go into infinite loop if reset fails", " - iommu/arm-smmu-v3: Match Stall behaviour for S2", " - iommu/vt-d: Always reserve a domain ID for identity setup", " - iommu/vt-d: Unconditionally flush device TLB for pasid table updates", " - iommu/arm-smmu-v3: Do not use devm for the cd table allocations", " - drm/amdgpu: disallow multiple BO_HANDLES chunks in one submit", " - drm/amd/display: Use gpuvm_min_page_size_kbytes for DML2 surfaces", " - ata: pata_serverworks: Do not use the term blacklist", " - ata: sata_sil: Rename sil_blacklist to sil_quirks", " - selftests/bpf: fix uprobe.path leak in bpf_testmod", " - scsi: smartpqi: Add new controller PCI IDs", " - HID: Ignore battery for all ELAN I2C-HID devices", " - drm/amd/display: Underflow Seen on DCN401 eGPU", " - drm/xe: Name and document Wa_14019789679", " - jfs: UBSAN: shift-out-of-bounds in dbFindBits", " - scsi: smartpqi: correct stream detection", " - scsi: smartpqi: add new controller PCI IDs", " - drm/amdgpu: add raven1 gfxoff quirk", " - drm/amdgpu: enable gfxoff quirk on HP 705G4", " - drm/amdkfd: Fix resource leak in criu restore queue", " - HID: multitouch: Add support for Thinkpad X12 Gen 2 Kbd Portfolio", " - platform/x86: touchscreen_dmi: add nanote-next quirk", " - platform/x86/amd: pmf: Add quirk for TUF Gaming A14", " - drm/stm: ltdc: reset plane transparency after plane disable", " - drm/amdgpu/gfx12: properly handle error ints on all pipes", " - drm/amdgpu/gfx9: properly handle error ints on all pipes", " - drm/amd/display: Fix possible overflow in integer multiplication", " - drm/printer: Allow NULL data in devcoredump printer", " - perf,x86: avoid missing caller address in stack traces captured in uprobe", " - scsi: aacraid: Rearrange order of struct aac_srb_unit", " - scsi: lpfc: Fix unsolicited FLOGI kref imbalance when in direct attached", " topology", " - scsi: lpfc: Update PRLO handling in direct attached topology", " - drm/amd/display: Force enable 3DLUT DMA check for dcn401 in DML", " - drm/amdgpu: fix unchecked return value warning for amdgpu_gfx", " - drm/amdgpu: fix unchecked return value warning for amdgpu_atombios", " - perf: Fix event_function_call() locking", " - scsi: NCR5380: Initialize buffer for MSG IN and STATUS transfers", " - drm/radeon/r100: Handle unknown family in r100_cp_init_microcode()", " - drm/amd/display: Unlock Pipes Based On DET Allocation", " - drm/amdgpu: fix ptr check warning in gfx9 ip_dump", " - drm/amdgpu: fix ptr check warning in gfx10 ip_dump", " - drm/amdgpu: fix ptr check warning in gfx11 ip_dump", " - drm/amdgpu: Block MMR_READ IOCTL in reset", " - drm/amdgpu/gfx9: use rlc safe mode for soft recovery", " - drm/amdgpu/gfx11: enter safe mode before touching CP_INT_CNTL", " - drm/xe: Use topology to determine page fault queue size", " - drm/amdkfd: Check int source id for utcl2 poison event", " - of/irq: Refer to actual buffer size in of_irq_parse_one()", " - drm/amd/display: guard write a 0 post_divider value to HW", " - powerpc/pseries: Use correct data types from pseries_hp_errorlog struct", " - ovl: fsync after metadata copy-up", " - drm/amdgpu/gfx12: use rlc safe mode for soft recovery", " - drm/amdgpu/gfx11: use rlc safe mode for soft recovery", " - drm/amdgpu/gfx10: use rlc safe mode for soft recovery", " - platform/x86: lenovo-ymc: Ignore the 0x0 state", " - tools/hv: Add memory allocation check in hv_fcopy_start", " - HID: i2c-hid: ensure various commands do not interfere with each other", " - platform/mellanox: mlxbf-pmc: fix lockdep warning", " - platform/x86: x86-android-tablets: Adjust Xiaomi Pad 2 bottom bezel touch", " buttons LED", " - bpf: Make the pointer returned by iter next method valid", " - ext4: ext4_search_dir should return a proper error", " - bpftool: Fix undefined behavior caused by shifting into the sign bit", " - iomap: handle a post-direct I/O invalidate race in", " iomap_write_delalloc_release", " - EINJ, CXL: Fix CXL device SBDF calculation", " - spi: spi-imx: Fix pm_runtime_set_suspended() with runtime pm enabled", " - spi: spi-cadence: Fix pm_runtime_set_suspended() with runtime pm enabled", " - spi: spi-cadence: Fix missing spi_controller_is_target() check", " - selftest: hid: add missing run-hid-tools-tests.sh", " - spi: s3c64xx: fix timeout counters in flush_fifo", " - kselftest/devices/probe: Fix SyntaxWarning in regex strings for Python3", " - selftests: breakpoints: use remaining time to check if suspend succeed", " - accel/ivpu: Add missing MODULE_FIRMWARE metadata", " - spi: rpc-if: Add missing MODULE_DEVICE_TABLE", " - ALSA: control: Fix power_ref lock order for compat code, too", " - perf callchain: Fix stitch LBR memory leaks", " - perf: Really fix event_function_call() locking", " - drm/xe: fixup xe_alloc_pf_queue", " - drm/xe: Fix memory leak on xe_alloc_pf_queue failure", " - selftests: vDSO: fix vDSO name for powerpc", " - selftests: vDSO: fix vdso_config for powerpc", " - selftests: vDSO: fix vDSO symbols lookup for powerpc64", " - ext4: fix error message when rejecting the default hash", " - selftests/mm: fix charge_reserved_hugetlb.sh test", " - nvme-tcp: fix link failure for TCP auth", " - f2fs: add write priority option based on zone UFS", " - powerpc/vdso: Fix VDSO data access when running in a non-root time namespace", " - selftests: vDSO: fix ELF hash table entry size for s390x", " - selftests: vDSO: fix vdso_config for s390", " - f2fs: make BG GC more aggressive for zoned devices", " - f2fs: introduce migration_window_granularity", " - f2fs: increase BG GC migration window granularity when boosted for zoned", " devices", " - f2fs: do FG_GC when GC boosting is required for zoned devices", " - f2fs: forcibly migrate to secure space for zoned device file pinning", " - Revert \"ALSA: hda: Conditionally use snooping for AMD HDMI\"", " - KVM: arm64: Fix kvm_has_feat*() handling of negative features", " - i2c: qcom-geni: Use IRQF_NO_AUTOEN flag in request_irq()", " - i2c: xiic: Wait for TX empty to avoid missed TX NAKs", " - i2c: core: Lock address during client device instantiation", " - i2c: xiic: Fix pm_runtime_set_suspended() with runtime pm enabled", " - i2c: designware: fix controller is holding SCL low while ENABLE bit is", " disabled", " - i2c: synquacer: Deal with optional PCLK correctly", " - rust: sync: require `T: Sync` for `LockedBy::access`", " - ovl: fail if trusted xattrs are needed but caller lacks permission", " - firmware: tegra: bpmp: Drop unused mbox_client_to_bpmp()", " - memory: tegra186-emc: drop unused to_tegra186_emc()", " - dt-bindings: clock: exynos7885: Fix duplicated binding", " - spi: bcm63xx: Fix module autoloading", " - spi: bcm63xx: Fix missing pm_runtime_disable()", " - power: supply: hwmon: Fix missing temp1_max_alarm attribute", " - power: supply: Drop use_cnt check from power_supply_property_is_writeable()", " - perf/core: Fix small negative period being ignored", " - drm/v3d: Prevent out of bounds access in performance query extensions", " - parisc: Fix itlb miss handler for 64-bit programs", " - drm/mediatek: ovl_adaptor: Add missing of_node_put()", " - drm: Consistently use struct drm_mode_rect for FB_DAMAGE_CLIPS", " - ALSA: hda/tas2781: Add new quirk for Lenovo Y990 Laptop", " - ALSA: core: add isascii() check to card ID generator", " - ALSA: usb-audio: Add delay quirk for VIVO USB-C HEADSET", " - ALSA: usb-audio: Add native DSD support for Luxman D-08u", " - ALSA: line6: add hw monitor volume control to POD HD500X", " - ALSA: hda/realtek: fix mute/micmute LED for HP mt645 G8", " - ALSA: hda/realtek: Add quirk for Huawei MateBook 13 KLV-WX9", " - ALSA: hda/realtek: Add a quirk for HP Pavilion 15z-ec200", " - ext4: correct encrypted dentry name hash when not casefolded", " - ext4: propagate errors from ext4_find_extent() in ext4_insert_range()", " - ext4: fix incorrect tid assumption in ext4_fc_mark_ineligible()", " - ext4: fix incorrect tid assumption in __jbd2_log_wait_for_space()", " - ext4: fix incorrect tid assumption in ext4_wait_for_tail_page_commit()", " - ext4: fix incorrect tid assumption in jbd2_journal_shrink_checkpoint_list()", " - ext4: fix fast commit inode enqueueing during a full journal commit", " - ext4: use handle to mark fc as ineligible in __track_dentry_update()", " - ext4: mark fc as ineligible using an handle in ext4_xattr_set()", " - parisc: Fix 64-bit userspace syscall path", " - parisc: Allow mmap(MAP_STACK) memory to automatically expand upwards", " - parisc: Fix stack start for ADDR_NO_RANDOMIZE personality", " - drm/rockchip: vop: clear DMA stop bit on RK3066", " - of: address: Report error on resource bounds overflow", " - of/irq: Support #msi-cells=<0> in of_msi_get_domain", " - lib/buildid: harden build ID parsing logic", " - jbd2: correctly compare tids with tid_geq function in jbd2_fc_begin_commit", " - mm: krealloc: consider spare memory for __GFP_ZERO", " - ocfs2: fix the la space leak when unmounting an ocfs2 volume", " - ocfs2: fix uninit-value in ocfs2_get_block()", " - scripts/gdb: fix timerlist parsing issue", " - scripts/gdb: add iteration function for rbtree", " - scripts/gdb: fix lx-mounts command error", " - arm64: fix selection of HAVE_DYNAMIC_FTRACE_WITH_ARGS", " - arm64: Subscribe Microsoft Azure Cobalt 100 to erratum 3194386", " - drm/xe/oa: Don't reset OAC_CONTEXT_ENABLE on OA stream close", " - sched/deadline: Comment sched_dl_entity::dl_server variable", " - sched/core: Add clearing of ->dl_server in put_prev_task_balance()", " - sched/core: Clear prev->dl_server in CFS pick fast path", " - sched: psi: fix bogus pressure spikes from aggregation race", " - riscv: define ILLEGAL_POINTER_VALUE for 64bit", " - [Config] updateconfigs for ILLEGAL_POINTER_VALUE on riscv", " - perf python: Disable -Wno-cast-function-type-mismatch if present on clang", " - perf hist: Update hist symbol when updating maps", " - nfsd: fix delegation_blocked() to block correctly for at least 30 seconds", " - NFSD: Fix NFSv4's PUTPUBFH operation", " - sysctl: avoid spurious permanent empty tables", " - RDMA/mana_ib: use the correct page table index based on hardware page size", " - RDMA/mana_ib: use the correct page size for mapping user-mode doorbell page", " - drivers/perf: riscv: Align errno for unsupported perf event", " - riscv: Fix kernel stack size when KASAN is enabled", " - media: imx335: Fix reset-gpio handling", " - clk: rockchip: fix error for unknown clocks", " - leds: pca9532: Remove irrelevant blink configuration error message", " - media: videobuf2: Drop minimum allocation requirement of 2 buffers", " - clk: qcom: dispcc-sm8250: use CLK_SET_RATE_PARENT for branch clocks", " - media: sun4i_csi: Implement link validate for sun4i_csi subdev", " - clk: qcom: gcc-sm8450: Do not turn off PCIe GDSCs during gdsc_disable()", " - media: uapi/linux/cec.h: cec_msg_set_reply_to: zero flags", " - dt-bindings: clock: qcom: Add GPLL9 support on gcc-sc8180x", " - clk: qcom: gcc-sc8180x: Register QUPv3 RCGs for DFS on sc8180x", " - clk: qcom: clk-rpmh: Fix overflow in BCM vote", " - clk: samsung: exynos7885: Update CLKS_NR_FSYS after bindings fix", " - clk: qcom: gcc-sm8150: De-register gcc_cpuss_ahb_clk_src", " - clk: qcom: gcc-sm8250: Do not turn off PCIe GDSCs during gdsc_disable()", " - clk: qcom: gcc-sc8180x: Add GPLL9 support", " - clk: qcom: gcc-sc8180x: Fix the sdcc2 and sdcc4 clocks freq table", " - clk: qcom: clk-alpha-pll: Fix CAL_L_VAL override for LUCID EVO PLL", " - drm/amd/display: avoid set dispclk to 0", " - smb: client: use actual path when queryfs", " - smb3: fix incorrect mode displayed for read-only files", " - iio: magnetometer: ak8975: Fix reading for ak099xx sensors", " - iio: pressure: bmp280: Fix regmap for BMP280 device", " - iio: pressure: bmp280: Fix waiting time for BMP3xx configuration", " - tomoyo: fallback to realpath if symlink's pathname does not exist", " - kselftests: mm: fix wrong __NR_userfaultfd value", " - rtc: at91sam9: fix OF node leak in probe() error path", " - mm/hugetlb: fix memfd_pin_folios resv_huge_pages leak", " - mm/gup: fix memfd_pin_folios hugetlb page allocation", " - mm/hugetlb: simplify refs in memfd_alloc_folio", " - Input: adp5589-keys - fix adp5589_gpio_get_value()", " - HID: bpf: fix cfi stubs for hid_bpf_ops", " - pidfs: check for valid pid namespace", " - ACPI: video: Add backlight=native quirk for Dell OptiPlex 5480 AIO", " - ACPI: resource: Remove duplicate Asus E1504GAB IRQ override", " - ACPI: resource: Loosen the Asus E1404GAB DMI match to also cover the E1404GA", " - ACPI: resource: Add Asus Vivobook X1704VAP to irq1_level_low_skip_override[]", " - ACPI: resource: Add Asus ExpertBook B2502CVA to", " irq1_level_low_skip_override[]", " - btrfs: drop the backref cache during relocation if we commit", " - btrfs: send: fix invalid clone operation for file that got its size", " decreased", " - cpufreq: intel_pstate: Make hwp_notify_lock a raw spinlock", " - gpio: davinci: fix lazy disable", " - net: pcs: xpcs: fix the wrong register that was written back", " - Bluetooth: hci_event: Align BR/EDR JUST_WORKS paring with LE", " - io_uring/net: harden multishot termination case for recv", " - ceph: fix cap ref leak via netfs init_request", " - tracing/hwlat: Fix a race during cpuhp processing", " - tracing/timerlat: Fix duplicated kthread creation due to CPU online/offline", " - rtla: Fix the help text in osnoise and timerlat top tools", " - firmware/sysfb: Disable sysfb for firmware buffers with unknown parent", " - close_range(): fix the logics in descriptor table trimming", " - drm/i915/gem: fix bitwise and logical AND mixup", " - drm/panthor: Don't add write fences to the shared BOs", " - drm/panthor: Don't declare a queue blocked if deferred operations are", " pending", " - drm/sched: Fix dynamic job-flow control race", " - drm/sched: Add locking to drm_sched_entity_modify_sched", " - drm/sched: Always wake up correct scheduler in drm_sched_entity_push_job", " - drm/sched: Always increment correct scheduler score", " - drm/amd/display: Restore Optimized pbn Value if Failed to Disable DSC", " - drm/amd/display: Add HDR workaround for specific eDP", " - drm/amd/display: Enable idle workqueue for more IPS modes", " - kconfig: fix infinite loop in sym_calc_choice()", " - kconfig: qconf: move conf_read() before drawing tree pain", " - kconfig: qconf: fix buffer overflow in debug links", " - arm64: cputype: Add Neoverse-N3 definitions", " - arm64: errata: Expand speculative SSBS workaround once more", " - mm: z3fold: deprecate CONFIG_Z3FOLD", " - [Config] updateconfigs after deprecating Z3FOLD", " - drm/amd/display: Allow backlight to go below", " `AMDGPU_DM_DEFAULT_MIN_BACKLIGHT`", " - sunrpc: change sp_nrthreads from atomic_t to unsigned int.", " - NFSD: Async COPY result needs to return a write verifier", " - remoteproc: k3-r5: Acquire mailbox handle during probe routine", " - remoteproc: k3-r5: Delay notification of wakeup event", " - r8169: Fix spelling mistake: \"tx_underun\" -> \"tx_underrun\"", " - ACPI: battery: Simplify battery hook locking", " - drm/xe: Clean up VM / exec queue file lock usage.", " - drm/rockchip: vop: enable VOP_FEATURE_INTERNAL_RGB on RK3066", " - drm/xe/vram: fix ccs offset calculation", " - drm/sched: revert \"Always increment correct scheduler score\"", " - ALSA: control: Fix leftover snd_power_unref()", " - crypto: octeontx* - Select CRYPTO_AUTHENC", " - drm/amd/display: Revert Avoid overflow assignment", " - perf report: Fix segfault when 'sym' sort key is not used", " - pmdomain: core: Reduce debug summary table width", " - perf python: Allow checking for the existence of warning options in clang", " - Linux 6.11.3", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49863", " - vhost/scsi: null-ptr-dereference in vhost_scsi_get_req()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49864", " - rxrpc: Fix a race between socket set up and I/O thread creation", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49865", " - drm/xe/vm: move xa_alloc to prevent UAF", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49955", " - ACPI: battery: Fix possible crash when unregistering a battery hook", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49973", " - r8169: add tally counter fields added with RTL8125", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49974", " - NFSD: Limit the number of concurrent async COPY operations", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49975", " - uprobes: fix kernel info leak via \"[uprobes]\" vma", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50003", " - drm/amd/display: Fix system hang while resume with TBT monitor", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50173", " - drm/panthor: Fix access to uninitialized variable in tick_ctx_cleanup()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49866", " - tracing/timerlat: Fix a race during cpuhp processing", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49976", " - tracing/timerlat: Drop interface_lock in stop_kthread()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50005", " - mac802154: Fix potential RCU dereference issue in mac802154_scan_worker", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50012", " - cpufreq: Avoid a bad reference count on CPU node", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49867", " - btrfs: wait for fixup workers before stopping cleaner kthread during umount", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49868", " - btrfs: fix a NULL pointer dereference when failed to start a new trasacntion", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49869", " - btrfs: send: fix buffer overflow detection when copying path to cache entry", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49870", " - cachefiles: fix dentry leak in cachefiles_open_file()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49871", " - Input: adp5589-keys - fix NULL pointer dereference", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49872", " - mm/gup: fix memfd_pin_folios alloc race panic", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49964", " - mm/hugetlb: fix memfd_pin_folios free_huge_pages leak", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49873", " - mm/filemap: fix filemap_get_folios_contig THP panic", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49977", " - net: stmmac: Fix zero-division error when disabling tc cbs", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49978", " - gso: fix udp gso fraglist segmentation after pull from frag_list", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49979", " - net: gso: fix tcp fraglist segmentation after pull from frag_list", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49980", " - vrf: revert \"vrf: Remove unnecessary RCU-bh critical section\"", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49981", " - media: venus: fix use after free bug in venus_remove due to race condition", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49956", " - gfs2: fix double destroy_workqueue error", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50176", " - remoteproc: k3-r5: Fix error handling when power-up failed", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49982", " - aoe: fix the potential use-after-free problem in more places", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49874", " - i3c: master: svc: Fix use after free vulnerability in svc_i3c_master Driver", " Due to Race Condition", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49875", " - nfsd: map the EBADMSG to nfserr_io to avoid warning", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50013", " - exfat: fix memory leak in exfat_load_bitmap()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49876", " - drm/xe: fix UAF around queue destruction", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49877", " - ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49957", " - ocfs2: fix null-ptr-deref when journal load failed.", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49965", " - ocfs2: remove unreasonable unlock in ocfs2_read_blocks", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49966", " - ocfs2: cancel dqi_sync_work before freeing oinfo", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49958", " - ocfs2: reserve space for inline xattr before attaching reflink tree", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49959", " - jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49878", " - resource: fix region_intersects() vs add_memory_driver_managed()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49879", " - drm: omapdrm: Add missing check for alloc_ordered_workqueue", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49880", " - ext4: fix off by one issue in alloc_flex_gd()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49881", " - ext4: update orig_path in ext4_find_extent()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50014", " - ext4: fix access to uninitialised lock in fc replay path", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49960", " - ext4: fix timer use-after-free on failed mount", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49882", " - ext4: fix double brelse() the buffer of the extents path", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49883", " - ext4: aovid use-after-free in ext4_ext_insert_extent()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49983", " - ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-free", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50015", " - ext4: dax: fix overflowing extents beyond inode size when partially writing", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49884", " - ext4: fix slab-use-after-free in ext4_split_extent_at()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49885", " - mm, slub: avoid zeroing kmalloc redzone", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49961", " - media: i2c: ar0521: Use cansleep version of gpiod_set_value()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49985", " - i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49886", " - platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bug", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49986", " - platform/x86: x86-android-tablets: Fix use after free on", " platform_device_register() errors", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49887", " - f2fs: fix to don't panic system for no free segment fault injection", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49888", " - bpf: Fix a sdiv overflow issue", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49987", " - bpftool: Fix undefined behavior in qsort(NULL, 0, ...)", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50006", " - ext4: fix i_data_sem unlock order in ext4_ind_migrate()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49889", " - ext4: avoid use-after-free in ext4_ext_show_leaf()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49968", " - ext4: filesystems without casefold feature cannot be mounted with siphash", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49988", " - ksmbd: add refcnt to ksmbd_conn struct", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49890", " - drm/amd/pm: ensure the fw_info is not null before using it", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49891", " - scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata", " paths", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49892", " - drm/amd/display: Initialize get_bytes_per_element's default to 1", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50016", " - drm/amd/display: Avoid overflow assignment in link_dp_cts", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49893", " - drm/amd/display: Check stream_status before it is used", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49969", " - drm/amd/display: Fix index out of bounds in DCN30 color transformation", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49970", " - drm/amd/display: Implement bounds check for stream encoder creation in", " DCN401", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49894", " - drm/amd/display: Fix index out of bounds in degamma hardware format", " translation", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49895", " - drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format", " translation", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49971", " - drm/amd/display: Increase array size of dummy_boolean", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49972", " - drm/amd/display: Deallocate DML memory if allocation fails", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49896", " - drm/amd/display: Check stream before comparing them", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49897", " - drm/amd/display: Check phantom_stream before it is used", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49898", " - drm/amd/display: Check null-initialized variables", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49899", " - drm/amd/display: Initialize denominators' default to 1", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49900", " - jfs: Fix uninit-value access of new_ea in ea_buffer", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49901", " - drm/msm/adreno: Assign msm_gpu->pdev earlier to avoid nullptrs", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49902", " - jfs: check if leafidx greater than num leaves per dmap tree", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49903", " - jfs: Fix uaf in dbFreeBits", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49904", " - drm/amdgpu: add list empty check to avoid null pointer issue", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49989", " - drm/amd/display: fix double free issue during amdgpu module unload", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49905", " - drm/amd/display: Add null check for 'afb' in", " amdgpu_dm_plane_handle_cursor_update (v2)", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49906", " - drm/amd/display: Check null pointer before try to access it", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49907", " - drm/amd/display: Check null pointers before using dc->clk_mgr", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49908", " - drm/amd/display: Add null check for 'afb' in amdgpu_dm_update_cursor (v2)", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50177", " - drm/amd/display: fix a UBSAN warning in DML2.1", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49909", " - drm/amd/display: Add NULL check for function pointer in", " dcn32_set_output_transfer_func", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49910", " - drm/amd/display: Add NULL check for function pointer in", " dcn401_set_output_transfer_func", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49911", " - drm/amd/display: Add NULL check for function pointer in", " dcn20_set_output_transfer_func", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49912", " - drm/amd/display: Handle null 'stream_status' in", " 'planes_changed_for_existing_stream'", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49913", " - drm/amd/display: Add null check for top_pipe_to_program in", " commit_planes_for_stream", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49914", " - drm/amd/display: Add null check for pipe_ctx->plane_state in", " dcn20_program_pipe", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49915", " - drm/amd/display: Add NULL check for clk_mgr in dcn32_init_hw", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49916", " - drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in", " dcn401_init_hw", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49917", " - drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in", " dcn30_init_hw", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49918", " - drm/amd/display: Add null check for head_pipe in", " dcn32_acquire_idle_pipe_for_head_pipe_in_layer", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49919", " - drm/amd/display: Add null check for head_pipe in", " dcn201_acquire_free_pipe_for_layer", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49991", " - drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49920", " - drm/amd/display: Check null pointers before multiple uses", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49921", " - drm/amd/display: Check null pointers before used", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49922", " - drm/amd/display: Check null pointers before using them", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49923", " - drm/amd/display: Pass non-null to dcn20_validate_apply_pipe_split_flags", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49992", " - drm/stm: Avoid use-after-free issues with crtc and plane", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49993", " - iommu/vt-d: Fix potential lockup if qi_submit_sync called with 0 count", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49924", " - fbdev: pxafb: Fix possible use after free in pxafb_task()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49925", " - fbdev: efifb: Register sysfs groups through driver core", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49926", " - rcu-tasks: Fix access non-existent percpu rtpcp variable in", " rcu_tasks_need_gpcb()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50007", " - ALSA: asihpi: Fix potential OOB array access", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50017", " - x86/mm/ident_map: Use gbpages only where full GB page should be mapped.", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49927", " - x86/ioapic: Handle allocation failures gracefully", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50008", " - wifi: mwifiex: Fix memcpy() field-spanning write warning in", " mwifiex_cmd_802_11_scan_ext()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50018", " - net: napi: Prevent overflow of napi_defer_hard_irqs", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49928", " - wifi: rtw89: avoid reading out of bounds when loading TX power FW elements", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50178", " - cpufreq: loongson3: Use raw_smp_processor_id() in do_service_request()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50009", " - cpufreq: amd-pstate: add check for cpufreq_cpu_get's return value", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49994", " - block: fix integer overflow in BLKSECDISCARD", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49929", " - wifi: iwlwifi: mvm: avoid NULL pointer dereference", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49995", " - tipc: guard against string buffer overrun", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49962", " - ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in", " acpi_db_convert_to_package()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49930", " - wifi: ath11k: fix array out-of-bound access in SoC stats", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49931", " - wifi: ath12k: fix array out-of-bound access in SoC stats", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49932", " - btrfs: don't readahead the relocation inode on RST", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49933", " - blk_iocost: fix more out of bound shifts", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49934", " - fs/inode: Prevent dump_mapping() accessing invalid dentry.d_name.name", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50010", " - exec: don't WARN for racy path_noexec check", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49935", " - ACPI: PAD: fix crash in exit_round_robin()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49936", " - net/xen-netback: prevent UAF in xenvif_flush_hash()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49937", " - wifi: cfg80211: Set correct chandef when starting CAC", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49938", " - wifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmit", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49939", " - wifi: rtw89: avoid to add interface to list twice when SER", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49940", " - l2tp: prevent possible tunnel refcount underflow", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49941", " - gpiolib: Fix potential NULL pointer dereference in gpiod_get_label()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49996", " - cifs: Fix buffer overflow when parsing NFS reparse points", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49942", " - drm/xe: Prevent null pointer access in xe_migrate_copy", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49943", " - drm/xe/guc_submit: add missing locking in wedged_fini", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50011", " - ASoC: Intel: soc-acpi-intel-rpl-match: add missing empty item", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50174", " - drm/panthor: Fix race when converting group handle to group object", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49944", " - sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_start", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49945", " - net/ncsi: Disable the ncsi work before freeing the associated structure", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49946", " - ppp: do not assume bh is held in ppp_channel_bridge_input()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49947", " - net: test for not too small csum_start in virtio_net_hdr_to_skb()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49948", " - net: add more sanity checks to qdisc_pkt_len_init()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49949", " - net: avoid potential underflow in qdisc_pkt_len_init() with UFO", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49997", " - net: ethernet: lantiq_etop: fix memory disclosure", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49998", " - net: dsa: improve shutdown sequence", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49999", " - afs: Fix the setting of the server responding flag", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49950", " - Bluetooth: L2CAP: Fix uaf in l2cap_connect", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49951", " - Bluetooth: MGMT: Fix possible crash on mgmt_index_removed", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49952", " - netfilter: nf_tables: prevent nf_skb_duplicated corruption", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49953", " - net/mlx5e: Fix crash caused by calling __xfrm_state_delete() twice", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50000", " - net/mlx5e: Fix NULL deref in mlx5e_tir_builder_alloc()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50001", " - net/mlx5: Fix error path in multi-packet WQE transmit", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50179", " - ceph: remove the incorrect Fw reference check when dirtying pages", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49963", " - mailbox: bcm2835: Fix timeout during suspend mode", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49954", " - static_call: Replace pointless WARN_ON() in static_call_module_notify()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50002", " - static_call: Handle module init failure correctly in", " static_call_del_module()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033)", " - EDAC/synopsys: Fix error injection on Zynq UltraScale+", " - crypto: xor - fix template benchmarking", " - crypto: qat - disable IOV in adf_dev_stop()", " - crypto: qat - fix recovery flow for VFs", " - crypto: qat - ensure correct order in VF restarting handler", " - ACPI: PMIC: Remove unneeded check in tps68470_pmic_opregion_probe()", " - eth: fbnic: select DEVLINK and PAGE_POOL", " - wifi: brcmfmac: introducing fwil query functions", " - wifi: ath9k: Remove error checks when creating debugfs entries", " - wifi: ath12k: fix BSS chan info request WMI command", " - wifi: ath12k: match WMI BSS chan info structure with firmware definition", " - wifi: ath12k: fix invalid AMPDU factor calculation in", " ath12k_peer_assoc_h_he()", " - hwrng: cn10k - Enable by default CN10K driver if Thunder SoC is enabled", " - crypto: x86/aes-gcm - fix PREEMPT_RT issue in gcm_crypt()", " - net: stmmac: dwmac-loongson: Init ref and PTP clocks rate", " - virtio: rename virtio_config_enabled to virtio_config_core_enabled", " - virtio: allow driver to disable the configure change notification", " - virtio-net: synchronize operstate with admin state on up/down", " - virtio-net: synchronize probe with ndo_set_features", " - arm64: signal: Fix some under-bracketed UAPI macros", " - wifi: rtw88: remove CPT execution branch never used", " - RISC-V: KVM: Fix sbiret init before forwarding to userspace", " - RISC-V: KVM: Allow legacy PMU access from guest", " - RISC-V: KVM: Fix to allow hpmcounter31 from the guest", " - mount: handle OOM on mnt_warn_timestamp_expiry", " - autofs: fix missing fput for FSCONFIG_SET_FD", " - netfilter: nf_tables: store new sets in dedicated list", " - wifi: rtw89: limit the PPDU length for VHT rate to 0x40000", " - kselftest/arm64: signal: fix/refactor SVE vector length enumeration", " - arm64: smp: smp_send_stop() and crash_smp_send_stop() should try non-NMI", " first", " - thermal: core: Fold two functions into their respective callers", " - thermal: core: Fix rounding of delay jiffies", " - perf/dwc_pcie: Fix registration issue in multi PCIe controller instances", " - perf/dwc_pcie: Always register for PCIe bus notifier", " - crypto: qat - fix \"Full Going True\" macro definition", " - ACPI: video: force native for Apple MacbookPro9,2", " - wifi: mac80211_hwsim: correct MODULE_PARM_DESC of multi_radio", " - wifi: iwlwifi: config: label 'gl' devices as discrete", " - wifi: iwlwifi: mvm: increase the time between ranging measurements", " - wifi: cfg80211: fix bug of mapping AF3x to incorrect User Priority", " - wifi: mac80211: fix the comeback long retry times", " - wifi: iwlwifi: mvm: allow ESR when we the ROC expires", " - wifi: mac80211: Check for missing VHT elements only for 5 GHz", " - ACPICA: Implement ACPI_WARNING_ONCE and ACPI_ERROR_ONCE", " - ACPICA: executer/exsystem: Don't nag user about every Stall() violating the", " spec", " - padata: Honor the caller's alignment in case of chunk_size 0", " - drivers/perf: hisi_pcie: Record hardware counts correctly", " - drivers/perf: hisi_pcie: Fix TLP headers bandwidth counting", " - kselftest/arm64: Actually test SME vector length changes via sigreturn", " - can: j1939: use correct function name in comment", " - wifi: rtw89: wow: fix wait condition for AOAC report request", " - ACPI: CPPC: Fix MASK_VAL() usage", " - netfilter: nf_tables: elements with timeout below CONFIG_HZ never expire", " - netfilter: nf_tables: reject element expiration with no timeout", " - netfilter: nf_tables: reject expiration higher than timeout", " - netfilter: nf_tables: remove annotation to access set timeout while holding", " lock", " - netfilter: nft_dynset: annotate data-races around set timeout", " - perf/arm-cmn: Refactor node ID handling. Again.", " - perf/arm-cmn: Fix CCLA register offset", " - perf/arm-cmn: Ensure dtm_idx is big enough", " - cpufreq: ti-cpufreq: Introduce quirks to handle syscon fails appropriately", " - thermal: gov_bang_bang: Adjust states of all uninitialized instances", " - wifi: mt76: mt7921: fix wrong UNII-4 freq range check for the channel usage", " - wifi: mt76: mt7996: fix traffic delay when switching back to working channel", " - wifi: mt76: mt7996: fix wmm set of station interface to 3", " - wifi: mt76: mt7996: fix HE and EHT beamforming capabilities", " - wifi: mt76: mt7996: fix EHT beamforming capability check", " - pm:cpupower: Add missing powercap_set_enabled() stub function", " - crypto: ccp - do not request interrupt on cmd completion when irqs disabled", " - crypto: hisilicon/hpre - mask cluster timeout error", " - crypto: hisilicon/qm - reset device before enabling it", " - wifi: mt76: mt7996: fix handling mbss enable/disable", " - wifi: mt76: connac: fix checksum offload fields of connac3 RXD", " - wifi: mt76: mt7603: fix mixed declarations and code", " - wifi: cfg80211: fix UBSAN noise in cfg80211_wext_siwscan()", " - wifi: mt76: mt7915: fix rx filter setting for bfee functionality", " - wifi: mt76: mt7996: fix uninitialized TLV data", " - wifi: cfg80211: fix two more possible UBSAN-detected off-by-one errors", " - af_unix: Don't call skb_get() for OOB skb.", " - af_unix: Remove single nest in manage_oob().", " - af_unix: Rename unlinked_skb in manage_oob().", " - af_unix: Move spin_lock() in manage_oob().", " - Bluetooth: hci_core: Fix sending MGMT_EV_CONNECT_FAILED", " - Bluetooth: hci_sync: Ignore errors from HCI_OP_REMOTE_NAME_REQ_CANCEL", " - can: m_can: enable NAPI before enabling interrupts", " - can: m_can: m_can_close(): stop clocks after device has been shut down", " - Bluetooth: btusb: Fix not handling ZPL/short-transfer", " - bareudp: Pull inner IP header in bareudp_udp_encap_recv().", " - bareudp: Pull inner IP header on xmit.", " - net: enetc: Use IRQF_NO_AUTOEN flag in request_irq()", " - crypto: n2 - Set err to EINVAL if snprintf fails for hmac", " - xsk: fix batch alloc API on non-coherent systems", " - net: ipv6: rpl_iptunnel: Fix memory leak in rpl_input", " - fbnic: Set napi irq value after calling netif_napi_add", " - net: tipc: avoid possible garbage value", " - ublk: move zone report data out of request pdu", " - block, bfq: choose the last bfqq from merge chain in bfq_setup_cooperator()", " - block, bfq: don't break merge chain in bfq_split_bfqq()", " - cachefiles: Fix non-taking of sb_writers around set/removexattr", " - nbd: correct the maximum value for discard sectors", " - erofs: fix incorrect symlink detection in fast symlink", " - erofs: fix error handling in z_erofs_init_decompressor", " - block, bfq: fix uaf for accessing waker_bfqq after splitting", " - block, bfq: fix procress reference leakage for bfqq in merge chain", " - io_uring/io-wq: do not allow pinning outside of cpuset", " - io_uring/io-wq: inherit cpuset of cgroup in io worker", " - spi: ppc4xx: handle irq_of_parse_and_map() errors", " - arm64: dts: exynos: exynos7885-jackpotlte: Correct RAM amount to 4GB", " - arm64: dts: mediatek: mt8186: Fix supported-hw mask for GPU OPPs", " - spi: ppc4xx: Avoid returning 0 when failed to parse and map IRQ", " - firmware: qcom: scm: Disable SDI and write no dump to dump mode", " - regulator: Return actual error in of_regulator_bulk_get_all()", " - arm64: dts: renesas: r9a08g045: Correct GICD and GICR sizes", " - arm64: dts: renesas: r9a07g043u: Correct GICD and GICR sizes", " - arm64: dts: renesas: r9a07g054: Correct GICD and GICR sizes", " - arm64: dts: renesas: r9a07g044: Correct GICD and GICR sizes", " - ARM: dts: microchip: sam9x60: Fix rtc/rtt clocks", " - arm64: tegra: Correct location of power-sensors for IGX Orin", " - arm64: dts: rockchip: Correct vendor prefix for Hardkernel ODROID-M1", " - arm64: dts: ti: k3-j721e-sk: Fix reversed C6x carveout locations", " - arm64: dts: ti: k3-j721e-beagleboneai64: Fix reversed C6x carveout locations", " - spi: bcmbca-hsspi: Fix missing pm_runtime_disable()", " - arm64: dts: qcom: x1e80100: Fix PHY for DP2", " - ARM: dts: microchip: sama7g5: Fix RTT clock", " - ARM: dts: imx7d-zii-rmu2: fix Ethernet PHY pinctrl property", " - arm64: dts: ti: k3-am654-idk: Fix dtbs_check warning in ICSSG dmas", " - ARM: versatile: fix OF node leak in CPUs prepare", " - reset: berlin: fix OF node leak in probe() error path", " - reset: k210: fix OF node leak in probe() error path", " - platform: cznic: turris-omnia-mcu: Fix error check in", " omnia_mcu_register_trng()", " - clocksource/drivers/qcom: Add missing iounmap() on errors in", " msm_dt_timer_init()", " - arm64: dts: mediatek: mt8195: Correct clock order for dp_intf*", " - x86/mm: Use IPIs to synchronize LAM enablement", " - ASoC: rt5682s: Return devm_of_clk_add_hw_provider to transfer the error", " - ASoC: tas2781: Fix a compiling warning reported by robot kernel test due to", " adding tas2563_dvc_table", " - ASoC: tas2781-i2c: Drop weird GPIO code", " - ASoC: tas2781-i2c: Get the right GPIO line", " - selftests/ftrace: Add required dependency for kprobe tests", " - ALSA: hda: cs35l41: fix module autoloading", " - selftests/ftrace: Fix test to handle both old and new kernels", " - x86/boot/64: Strip percpu address space when setting up GDT descriptors", " - m68k: Fix kernel_clone_args.flags in m68k_clone()", " - ASoC: loongson: fix error release", " - selftests/ftrace: Fix eventfs ownership testcase to find mount point", " - selftests:resctrl: Fix build failure on archs without __cpuid_count()", " - cgroup/pids: Avoid spurious event notification", " - hwmon: (max16065) Fix overflows seen when writing limits", " - hwmon: (max16065) Fix alarm attributes", " - iommu/arm-smmu: Un-demote unhandled-fault msg", " - iommu/arm-smmu-v3: Fix a NULL vs IS_ERR() check", " - mtd: slram: insert break after errors in parsing the map", " - hwmon: (ntc_thermistor) fix module autoloading", " - power: supply: axp20x_battery: Remove design from min and max voltage", " - power: supply: max17042_battery: Fix SOC threshold calc w/ no current sense", " - fbdev: hpfb: Fix an error handling path in hpfb_dio_probe()", " - iommu/amd: Handle error path in amd_iommu_probe_device()", " - iommu/amd: Allocate the page table root using GFP_KERNEL", " - iommu/amd: Move allocation of the top table into v1_alloc_pgtable", " - iommu/amd: Set the pgsize_bitmap correctly", " - iommu/amd: Do not set the D bit on AMD v2 table entries", " - mtd: powernv: Add check devm_kasprintf() returned value", " - rcu/nocb: Fix RT throttling hrtimer armed from offline CPU", " - mtd: rawnand: mtk: Use for_each_child_of_node_scoped()", " - mtd: rawnand: mtk: Factorize out the logic cleaning mtk chips", " - mtd: rawnand: mtk: Fix init error path", " - iommu/arm-smmu-qcom: hide last LPASS SMMU context bank from linux", " - iommu/arm-smmu-qcom: Work around SDM845 Adreno SMMU w/ 16K pages", " - iommu/arm-smmu-qcom: apply num_context_bank fixes for SDM630 / SDM660", " - pmdomain: core: Harden inter-column space in debug summary", " - pmdomain: core: Fix \"managed by\" alignment in debug summary", " - drm/stm: Fix an error handling path in stm_drm_platform_probe()", " - drm/stm: ltdc: check memory returned by devm_kzalloc()", " - drm/amd/display: free bo used for dmub bounding box", " - drm/amdgpu: properly handle vbios fake edid sizing", " - drm/radeon: properly handle vbios fake edid sizing", " - drm/amd/display: Reset VRR config during resume", " - scsi: smartpqi: revert propagate-the-multipath-failure-to-SML-quickly", " - scsi: sd: Don't check if a write for REQ_ATOMIC", " - scsi: block: Don't check REQ_ATOMIC for reads", " - scsi: NCR5380: Check for phase match during PDMA fixup", " - drm/amd/amdgpu: Properly tune the size of struct", " - drm/amd/display: Improve FAM control for DCN401", " - drm/rockchip: vop: Allow 4096px width scaling", " - drm/rockchip: dw_hdmi: Fix reading EDID when using a forced mode", " - drm/radeon/evergreen_cs: fix int overflow errors in cs track offsets", " - drm/bridge: lontium-lt8912b: Validate mode in drm_bridge_funcs::mode_valid()", " - drm/vc4: hdmi: Handle error case of pm_runtime_resume_and_get", " - drm/mediatek: Fix missing configuration flags in mtk_crtc_ddp_config()", " - drm/mediatek: Use spin_lock_irqsave() for CRTC event lock", " - powerpc/8xx: Fix initial memory mapping", " - powerpc/8xx: Fix kernel vs user address comparison", " - powerpc/vdso: Inconditionally use CFUNC macro", " - drm/msm: Use a7xx family directly in gpu_state", " - drm/msm: Dump correct dbgahb clusters on a750", " - drm/msm: Fix CP_BV_DRAW_STATE_ADDR name", " - drm/msm: Fix incorrect file name output in adreno_request_fw()", " - drm/msm/a5xx: disable preemption in submits by default", " - drm/msm/a5xx: properly clear preemption records on resume", " - drm/msm/a5xx: fix races in preemption evaluation stage", " - drm/msm/a5xx: workaround early ring-buffer emptiness check", " - ipmi: docs: don't advertise deprecated sysfs entries", " - drm/msm/dp: enable widebus on all relevant chipsets", " - drm/msm/dsi: correct programming sequence for SM8350 / SM8450", " - drm/msm: fix %s null argument error", " - platform/x86: ideapad-laptop: Make the scope_guard() clear of its scope", " - kselftest: dt: Ignore nodes that have ancestors disabled", " - drivers:drm:exynos_drm_gsc:Fix wrong assignment in gsc_bind()", " - drm/amdgpu: fix invalid fence handling in amdgpu_vm_tlb_flush", " - xen: use correct end address of kernel for conflict checking", " - HID: wacom: Support sequence numbers smaller than 16-bit", " - HID: wacom: Do not warn about dropped packets for first packet", " - ata: libata: Clear DID_TIME_OUT for ATA PT commands with sense data", " - xen: introduce generic helper checking for memory map conflicts", " - xen: move max_pfn in xen_memory_setup() out of function scope", " - xen: add capability to remap non-RAM pages to different PFNs", " - xen: tolerate ACPI NVS memory overlapping with Xen allocated memory", " - drm/xe: fix missing 'xe_vm_put'", " - xen/swiotlb: add alignment check for dma buffers", " - xen/swiotlb: fix allocated size", " - sched/fair: Make SCHED_IDLE entity be preempted in strict hierarchy", " - bpf, x64: Fix tailcall hierarchy", " - bpf, arm64: Fix tailcall hierarchy", " - bpf: Fix compare error in function retval_range_within", " - selftests/bpf: Workaround strict bpf_lsm return value check.", " - selftests/bpf: Fix error linking uprobe_multi on mips", " - selftests/bpf: Fix wrong binary in Makefile log output", " - tools/runqslower: Fix LDFLAGS and add LDLIBS support", " - selftests/bpf: Use pid_t consistently in test_progs.c", " - selftests/bpf: Fix compile error from rlim_t in sk_storage_map.c", " - selftests/bpf: Fix error compiling bpf_iter_setsockopt.c with musl libc", " - selftests/bpf: Drop unneeded error.h includes", " - selftests/bpf: Fix missing ARRAY_SIZE() definition in bench.c", " - selftests/bpf: Fix missing UINT_MAX definitions in benchmarks", " - selftests/bpf: Fix missing BUILD_BUG_ON() declaration", " - selftests/bpf: Fix include of ", " - selftests/bpf: Fix compiling parse_tcp_hdr_opt.c with musl-libc", " - selftests/bpf: Fix compiling kfree_skb.c with musl-libc", " - selftests/bpf: Fix compiling flow_dissector.c with musl-libc", " - selftests/bpf: Fix compiling tcp_rtt.c with musl-libc", " - selftests/bpf: Fix compiling core_reloc.c with musl-libc", " - selftests/bpf: Fix errors compiling lwt_redirect.c with musl libc", " - selftests/bpf: Fix errors compiling decap_sanity.c with musl libc", " - selftests/bpf: Fix errors compiling crypto_sanity.c with musl libc", " - selftests/bpf: Fix errors compiling cg_storage_multi.h with musl libc", " - libbpf: Don't take direct pointers into BTF data from st_ops", " - selftests/bpf: Fix arg parsing in veristat, test_progs", " - selftests/bpf: Fix error compiling test_lru_map.c", " - selftests/bpf: Fix C++ compile error from missing _Bool type", " - selftests/bpf: Fix redefinition errors compiling lwt_reroute.c", " - selftests/bpf: Fix compile if backtrace support missing in libc", " - selftests/bpf: Fix error compiling tc_redirect.c with musl libc", " - s390/entry: Move early program check handler to entry.S", " - s390/entry: Make early program check handler relocated lowcore aware", " - libbpf: Fix license for btf_relocate.c", " - samples/bpf: Fix compilation errors with cf-protection option", " - selftests/bpf: no need to track next_match_pos in struct test_loader", " - selftests/bpf: extract test_loader->expect_msgs as a data structure", " - selftests/bpf: allow checking xlated programs in verifier_* tests", " - selftests/bpf: __arch_* macro to limit test cases to specific archs", " - selftests/bpf: fix to avoid __msg tag de-duplication by clang", " - selftests/bpf: Fix incorrect parameters in NULL pointer checking", " - libbpf: Fix bpf_object__open_skeleton()'s mishandling of options", " - s390/ap: Fix deadlock caused by recursive lock of the AP bus scan mutex", " - libbpf: Ensure new BTF objects inherit input endianness", " - xz: cleanup CRC32 edits from 2018", " - kthread: fix task state in kthread worker if being frozen", " - ext4: clear EXT4_GROUP_INFO_WAS_TRIMMED_BIT even mount with discard", " - bpftool: Fix handling enum64 in btf dump sorting", " - sched/deadline: Fix schedstats vs deadline servers", " - smackfs: Use rcu_assign_pointer() to ensure safe assignment in smk_set_cipso", " - ext4: avoid buffer_head leak in ext4_mark_inode_used()", " - ext4: avoid potential buffer_head leak in __ext4_new_inode()", " - ext4: avoid negative min_clusters in find_group_orlov()", " - ext4: return error on ext4_find_inline_entry", " - sched/numa: Fix the vma scan starving issue", " - nilfs2: determine empty node blocks as corrupted", " - sched/pelt: Use rq_clock_task() for hw_pressure", " - bpf: Fix bpf_strtol and bpf_strtoul helpers for 32bit", " - bpf: Improve check_raw_mode_ok test for MEM_UNINIT-tagged types", " - perf scripts python cs-etm: Restore first sample log in verbose mode", " - perf bpf: Move BPF disassembly routines to separate file to avoid clash with", " capstone bpf headers", " - perf mem: Free the allocated sort string, fixing a leak", " - perf lock contention: Change stack_id type to s32", " - perf vendor events: SKX, CLX, SNR uncore cache event fixes", " - perf inject: Fix leader sampling inserting additional samples", " - perf report: Fix --total-cycles --stdio output error", " - perf build: Fix up broken capstone feature detection fast path", " - perf sched timehist: Fix missing free of session in perf_sched__timehist()", " - perf stat: Display iostat headers correctly", " - perf dwarf-aux: Check allowed location expressions when collecting variables", " - perf annotate-data: Fix off-by-one in location range check", " - perf dwarf-aux: Handle bitfield members from pointer access", " - perf hist: Don't set hpp_fmt_value for members in --no-group", " - perf sched timehist: Fixed timestamp error when unable to confirm event", " sched_in time", " - perf time-utils: Fix 32-bit nsec parsing", " - perf mem: Check mem_events for all eligible PMUs", " - perf mem: Fix missed p-core mem events on ADL and RPL", " - clk: imx: clk-audiomix: Correct parent clock for earc_phy and audpll", " - clk: imx: imx6ul: fix default parent for enet*_ref_sel", " - clk: imx: composite-8m: Enable gate clk with mcore_booted", " - clk: imx: composite-93: keep root clock on when mcore enabled", " - clk: imx: composite-7ulp: Check the PCC present bit", " - clk: imx: fracn-gppll: fix fractional part of PLL getting lost", " - clk: imx: imx8mp: fix clock tree update of TF-A managed clocks", " - clk: imx: imx8qxp: Register dc0_bypass0_clk before disp clk", " - clk: imx: imx8qxp: Parent should be initialized earlier than the clock", " - quota: avoid missing put_quota_format when DQUOT_SUSPENDED is passed", " - remoteproc: imx_rproc: Correct ddr alias for i.MX8M", " - remoteproc: imx_rproc: Initialize workqueue earlier", " - clk: rockchip: Set parent rate for DCLK_VOP clock on RK3228", " - clk: qcom: dispcc-sm8550: fix several supposed typos", " - clk: qcom: dispcc-sm8550: use rcg2_ops for mdss_dptx1_aux_clk_src", " - clk: qcom: dispcc-sm8650: Update the GDSC flags", " - clk: qcom: dispcc-sm8550: use rcg2_shared_ops for ESC RCGs", " - leds: bd2606mvv: Fix device child node usage in bd2606mvv_probe()", " - pinctrl: renesas: rzg2l: Return -EINVAL if the pin doesn't support", " PIN_CFG_OEN", " - pinctrl: ti: ti-iodelay: Fix some error handling paths", " - phy: phy-rockchip-samsung-hdptx: Explicitly include pm_runtime.h", " - Input: ilitek_ts_i2c - avoid wrong input subsystem sync", " - Input: ilitek_ts_i2c - add report id message validation", " - media: raspberrypi: VIDEO_RASPBERRYPI_PISP_BE should depend on ARCH_BCM2835", " - [Config] updateconfigs for VIDEO_RASPBERRYPI_PISP_BE", " - PCI: Wait for Link before restoring Downstream Buses", " - firewire: core: correct range of block for case of switch statement", " - media: staging: media: starfive: camss: Drop obsolete return value", " documentation", " - clk: qcom: ipq5332: Register gcc_qdss_tsctr_clk_src", " - clk: qcom: dispcc-sm8250: use special function for Lucid 5LPE PLL", " - leds: pca995x: Use device_for_each_child_node() to access device child nodes", " - leds: pca995x: Fix device child node usage in pca995x_probe()", " - x86/PCI: Check pcie_find_root_port() return for NULL", " - PCI: xilinx-nwl: Fix register misspelling", " - PCI: xilinx-nwl: Clean up clock on probe failure/removal", " - leds: gpio: Set num_leds after allocation", " - media: platform: rzg2l-cru: rzg2l-csi2: Add missing MODULE_DEVICE_TABLE", " - pinctrl: single: fix missing error code in pcs_probe()", " - clk: at91: sama7g5: Allocate only the needed amount of memory for PLLs", " - iommufd/selftest: Fix buffer read overrrun in the dirty test", " - RDMA/bnxt_re: Fix the table size for PSN/MSN entries", " - media: imagination: VIDEO_E5010_JPEG_ENC should depend on ARCH_K3", " - [Config] updateconfigs for VIDEO_E5010_JPEG_ENC", " - RDMA/rtrs: Reset hb_missed_cnt after receiving other traffic from peer", " - clk: ti: dra7-atl: Fix leak of of_nodes", " - clk: starfive: Use pm_runtime_resume_and_get to fix pm_runtime_get_sync()", " usage", " - clk: rockchip: rk3588: Fix 32k clock name for pmu_24m_32k_100m_src_p", " - nfsd: remove unneeded EEXIST error check in nfsd_do_file_acquire", " - nfsd: fix refcount leak when file is unhashed after being found", " - pinctrl: mvebu: Fix devinit_dove_pinctrl_probe function", " - dt-bindings: PCI: layerscape-pci: Replace fsl,lx2160a-pcie with", " fsl,lx2160ar2-pcie", " - iommufd: Check the domain owner of the parent before creating a nesting", " domain", " - RDMA/erdma: Return QP state in erdma_query_qp", " - RDMA/mlx5: Fix counter update on MR cache mkey creation", " - RDMA/mlx5: Limit usage of over-sized mkeys from the MR cache", " - RDMA/mlx5: Drop redundant work canceling from clean_keys()", " - RDMA/mlx5: Fix MR cache temp entries cleanup", " - watchdog: imx_sc_wdt: Don't disable WDT in suspend", " - RDMA/hns: Don't modify rq next block addr in HIP09 QPC", " - RDMA/hns: Fix the overflow risk of hem_list_calc_ba_range()", " - RDMA/hns: Fix VF triggering PF reset in abnormal interrupt handler", " - RDMA/hns: Fix 1bit-ECC recovery address in non-4K OS", " - RDMA/hns: Optimize hem allocation performance", " - RDMA/hns: Fix restricted __le16 degrades to integer issue", " - Input: ims-pcu - fix calling interruptible mutex", " - RDMA/mlx5: Obtain upper net device only when needed", " - PCI: qcom-ep: Enable controller resources like PHY only after refclk is", " available", " - riscv: Fix fp alignment bug in perf_callchain_user()", " - RDMA/hns: Fix ah error counter in sw stat not increasing", " - RDMA/irdma: fix error message in irdma_modify_qp_roce()", " - ntb_perf: Fix printk format", " - ntb: Force physically contiguous allocation of rx ring buffers", " - nfsd: untangle code in nfsd4_deleg_getattr_conflict()", " - nfsd: fix initial getattr on write delegation", " - crypto: caam - Pad SG length when allocating hash edesc", " - crypto: powerpc/p10-aes-gcm - Disable CRYPTO_AES_GCM_P10", " - [Config] disable CRYPTO_AES_GCM_P10", " - f2fs: atomic: fix to avoid racing w/ GC", " - f2fs: reduce expensive checkpoint trigger frequency", " - f2fs: fix to avoid racing in between read and OPU dio write", " - f2fs: Create COW inode from parent dentry for atomic write", " - f2fs: fix to wait page writeback before setting gcing flag", " - f2fs: atomic: fix to truncate pagecache before on-disk metadata truncation", " - f2fs: compress: don't redirty sparse cluster during {,de}compress", " - f2fs: prevent atomic file from being dirtied before commit", " - spi: airoha: fix dirmap_{read,write} operations", " - spi: airoha: fix airoha_snand_{write,read}_data data_len estimation", " - spi: atmel-quadspi: Undo runtime PM changes at driver exit time", " - spi: spi-fsl-lpspi: Undo runtime PM changes at driver exit time", " - lib/sbitmap: define swap_lock as raw_spinlock_t", " - spi: airoha: remove read cache in airoha_snand_dirmap_read()", " - spi: atmel-quadspi: Avoid overwriting delay register settings", " - NFSv4.2: Fix detection of \"Proxying of Times\" server support", " - nvme-multipath: system fails to create generic nvme device", " - iio: adc: ad7606: fix oversampling gpio array", " - iio: adc: ad7606: fix standby gpio state to match the documentation", " - driver core: Fix error handling in driver API device_rename()", " - ABI: testing: fix admv8818 attr description", " - iio: chemical: bme680: Fix read/write ops to device by adding mutexes", " - iio: magnetometer: ak8975: drop incorrect AK09116 compatible", " - dt-bindings: iio: asahi-kasei,ak8975: drop incorrect AK09116 compatible", " - serial: 8250: omap: Cleanup on error in request_irq", " - Coresight: Set correct cs_mode for TPDM to fix disable issue", " - Coresight: Set correct cs_mode for dummy source to fix disable issue", " - coresight: tmc: sg: Do not leak sg_table", " - interconnect: icc-clk: Add missed num_nodes initialization", " - interconnect: qcom: sm8250: Enable sync_state", " - dm integrity: fix gcc 5 warning", " - cxl/pci: Fix to record only non-zero ranges", " - um: remove ARCH_NO_PREEMPT_DYNAMIC", " - Revert \"dm: requeue IO if mapping table not yet available\"", " - net: phy: aquantia: fix -ETIMEDOUT PHY probe failure when firmware not", " present", " - net: xilinx: axienet: Schedule NAPI in two steps", " - net: xilinx: axienet: Fix packet counting", " - net: ipv6: select DST_CACHE from IPV6_RPL_LWTUNNEL", " - net: qrtr: Update packets cloning when broadcasting", " - net: phy: aquantia: fix setting active_low bit", " - net: phy: aquantia: fix applying active_low bit after reset", " - net: ravb: Fix maximum TX frame size for GbEth devices", " - net: ravb: Fix R-Car RX frame size limit", " - virtio_net: Fix mismatched buf address when unmapping for small packets", " - netfilter: nf_tables: Keep deleted flowtable hooks until after RCU", " - netfilter: ctnetlink: compile ctnetlink_label_size with", " CONFIG_NF_CONNTRACK_EVENTS", " - netfilter: nf_tables: use rcu chain hook list iterator from netlink dump", " path", " - netfilter: nf_tables: missing objects with no memcg accounting", " - selftests: netfilter: Avoid hanging ipvs.sh", " - io_uring/sqpoll: do not allow pinning outside of cpuset", " - io_uring/rw: treat -EOPNOTSUPP for IOCB_NOWAIT like -EAGAIN", " - io_uring: check for presence of task_work rather than TIF_NOTIFY_SIGNAL", " - mm: migrate: annotate data-race in migrate_folio_unmap()", " - drm/amd/display: Fix Synaptics Cascaded Panamera DSC Determination", " - drm/amd/display: Add DSC Debug Log", " - drm/amdgpu/display: Fix a mistake in revert commit", " - xen: move checks for e820 conflicts further up", " - xen: allow mapping ACPI data using a different physical address", " - io_uring/sqpoll: retain test for whether the CPU is valid", " - drm/amd/display: disable_hpo_dp_link_output: Check link_res->hpo_dp_link_enc", " before using it", " - io_uring/sqpoll: do not put cpumask on stack", " - selftests/bpf: correctly move 'log' upon successful match", " - Remove *.orig pattern from .gitignore", " - PCI: Revert to the original speed after PCIe failed link retraining", " - PCI: Clear the LBMS bit after a link retrain", " - PCI: dra7xx: Fix threaded IRQ request for \"dra7xx-pcie-main\" IRQ", " - PCI: imx6: Fix missing call to phy_power_off() in error handling", " - PCI: imx6: Fix establish link failure in EP mode for i.MX8MM and i.MX8MP", " - PCI: imx6: Fix i.MX8MP PCIe EP's occasional failure to trigger MSI", " - PCI: Correct error reporting with PCIe failed link retraining", " - PCI: Use an error code with PCIe failed link retraining", " - PCI: xilinx-nwl: Fix off-by-one in INTx IRQ handler", " - PCI: dra7xx: Fix error handling when IRQ request fails in probe", " - Revert \"soc: qcom: smd-rpm: Match rpmsg channel instead of compatible\"", " - ASoC: rt5682: Return devm_of_clk_add_hw_provider to transfer the error", " - soc: fsl: cpm1: qmc: Update TRNSYNC only in transparent mode", " - soc: fsl: cpm1: tsa: Fix tsa_write8()", " - soc: versatile: integrator: fix OF node leak in probe() error path", " - Revert \"media: tuners: fix error return code of", " hybrid_tuner_request_state()\"", " - iommu/amd: Fix argument order in amd_iommu_dev_flush_pasid_all()", " - Input: adp5588-keys - fix check on return code", " - Input: i8042 - add TUXEDO Stellaris 16 Gen5 AMD to i8042 quirk table", " - Input: i8042 - add TUXEDO Stellaris 15 Slim Gen6 AMD to i8042 quirk table", " - Input: i8042 - add another board name for TUXEDO Stellaris Gen5 AMD line", " - KVM: arm64: Add memory length checks and remove inline in do_ffa_mem_xfer", " - KVM: x86: Enforce x2APIC's must-be-zero reserved ICR bits", " - KVM: x86: Move x2APIC ICR helper above kvm_apic_write_nodecode()", " - KVM: x86: Re-split x2APIC ICR into ICR+ICR2 for AMD (x2AVIC)", " - drm/amdgpu/mes12: reduce timeout", " - drm/amdgpu/mes11: reduce timeout", " - drm/amdkfd: Add SDMA queue quantum support for GFX12", " - drm/amdgpu: update golden regs for gfx12", " - drm/amdgpu/mes12: set enable_level_process_quantum_check", " - drm/amdgpu/vcn: enable AV1 on both instances", " - drm/amd/pm: update workload mask after the setting", " - drm/amdgpu: fix PTE copy corruption for sdma 7", " - drm/amdgpu: bump driver version for cleared VRAM", " - drm/amdgpu/mes12: switch SET_SHADER_DEBUGGER pkt to mes schq pipe", " - drm/amdgpu: Fix selfring initialization sequence on soc24", " - drm/amd/display: Add HDMI DSC native YCbCr422 support", " - drm/amd/display: Round calculated vtotal", " - drm/amd/display: Clean up dsc blocks in accelerated mode", " - drm/amd/display: Block timing sync for different output formats in pmo", " - drm/amd/display: Validate backlight caps are sane", " - drm/amd/display: Disable SYMCLK32_LE root clock gating", " - drm/amd/display: Block dynamic IPS2 on DCN35 for incompatible FW versions", " - drm/amd/display: Enable DML2 override_det_buffer_size_kbytes", " - drm/amd/display: Skip to enable dsc if it has been off", " - drm/amd/display: Fix underflow when setting underscan on DCN401", " - drm/amd/display: Update IPS default mode for DCN35/DCN351", " - objtool: Handle frame pointer related instructions", " - powerpc/atomic: Use YZ constraints for DS-form instructions", " - ksmbd: make __dir_empty() compatible with POSIX", " - ksmbd: allow write with FILE_APPEND_DATA", " - ksmbd: handle caseless file creation", " - ata: libata-scsi: Fix ata_msense_control() CDL page reporting", " - scsi: ufs: qcom: Update MODE_MAX cfg_bw value", " - scsi: lpfc: Restrict support for 32 byte CDBs to specific HBAs", " - scsi: mac_scsi: Revise printk(KERN_DEBUG ...) messages", " - scsi: mac_scsi: Refactor polling loop", " - scsi: mac_scsi: Disallow bus errors during PDMA send", " - can: esd_usb: Remove CAN_CTRLMODE_3_SAMPLES for CAN-USB/3-FD", " - wifi: rtw88: Fix USB/SDIO devices not transmitting beacons", " - usbnet: fix cyclical race on disconnect with work queue", " - arm64: dts: mediatek: mt8195-cherry: Mark USB 3.0 on xhci1 as disabled", " - arm64: dts: mediatek: mt8395-nio-12l: Mark USB 3.0 on xhci1 as disabled", " - USB: appledisplay: close race between probe and completion handler", " - USB: misc: cypress_cy7c63: check for short transfer", " - USB: class: CDC-ACM: fix race between get_serial and set_serial", " - USB: misc: yurex: fix race between read and write", " - usb: xhci: fix loss of data on Cadence xHC", " - usb: cdnsp: Fix incorrect usb_request status", " - usb: xHCI: add XHCI_RESET_ON_RESUME quirk for Phytium xHCI host", " - usb: gadget: dummy_hcd: execute hrtimer callback in softirq context", " - usb: dwc2: drd: fix clock gating on USB role switch", " - bus: integrator-lm: fix OF node leak in probe()", " - bus: mhi: host: pci_generic: Update EDL firmware path for Foxconn modems", " - bus: mhi: host: pci_generic: Fix the name for the Telit FE990A", " - tty: rp2: Fix reset with non forgiving PCIe host bridges", " - pps: add an error check in parport_attach", " - serial: don't use uninitialized value in uart_poll_init()", " - xhci: Set quirky xHC PCI hosts to D3 _after_ stopping and freeing them.", " - serial: qcom-geni: fix fifo polling timeout", " - serial: qcom-geni: fix false console tx restart", " - crypto: qcom-rng - fix support for ACPI-based systems", " - crypto: ccp - Properly unregister /dev/sev on sev PLATFORM_STATUS failure", " - drbd: Fix atomicity violation in drbd_uuid_set_bm()", " - drbd: Add NULL check for net_conf to prevent dereference in state validation", " - ACPI: resource: Do IRQ override on MECHREV GM7XG0M", " - ACPI: resource: Add another DMI match for the TongFang GMxXGxx", " - intel_idle: add Granite Rapids Xeon support", " - intel_idle: fix ACPI _CST matching for newer Xeon platforms", " - x86/entry: Remove unwanted instrumentation in common_interrupt()", " - perf/x86/intel: Allow to setup LBR for counting event for BPF", " - perf/x86/intel/pt: Fix sampling synchronization", " - btrfs: subpage: fix the bitmap dump which can cause bitmap corruption", " - wifi: mt76: mt7921: Check devm_kasprintf() returned value", " - wifi: mt76: mt7915: check devm_kasprintf() returned value", " - idpf: fix netdev Tx queue stop/wake", " - wifi: rtw88: 8821cu: Remove VID/PID 0bda:c82c", " - wifi: rtw88: 8822c: Fix reported RX band width", " - wifi: rtw88: 8703b: Fix reported RX band width", " - wifi: mt76: mt7615: check devm_kasprintf() returned value", " - wifi: mt76: mt7925: fix a potential association failure upon resuming", " - debugfs show actual source in /proc/mounts", " - debugobjects: Fix conditions in fill_pool()", " - btrfs: tree-checker: fix the wrong output of data backref objectid", " - btrfs: always update fstrim_range on failure in FITRIM ioctl", " - f2fs: fix several potential integer overflows in file offsets", " - f2fs: prevent possible int overflow in dir_block_index()", " - f2fs: avoid potential int overflow in sanity_check_area_boundary()", " - hwrng: mtk - Use devm_pm_runtime_enable", " - hwrng: bcm2835 - Add missing clk_disable_unprepare in bcm2835_rng_init", " - hwrng: cctrng - Add missing clk_disable_unprepare in cctrng_resume", " - arm64: esr: Define ESR_ELx_EC_* constants as UL", " - arm64: errata: Enable the AC03_CPU_38 workaround for ampere1a", " - arm64: dts: mediatek: mt8186-corsola: Disable DPI display interface", " - arm64: dts: rockchip: Raise Pinebook Pro's panel backlight PWM frequency", " - arm64: dts: qcom: sa8775p: Mark APPS and PCIe SMMUs as DMA coherent", " - arm64: dts: rockchip: Correct the Pinebook Pro battery design capacity", " - fs: Fix file_set_fowner LSM hook inconsistencies", " - nfs: fix memory leak in error path of nfs4_do_reclaim", " - EDAC/igen6: Fix conversion of system address to physical memory address", " - eventpoll: Annotate data-race of busy_poll_usecs", " - md: Don't flush sync_work in md_write_start()", " - cpuidle: riscv-sbi: Use scoped device node handling to fix missing", " of_node_put", " - lsm: add the inode_free_security_rcu() LSM implementation hook", " - spi: fspi: involve lut_num for struct nxp_fspi_devtype_data", " - dt-bindings: spi: nxp-fspi: add imx8ulp support", " - ARM: dts: imx6ul-geam: fix fsl,pins property in tscgrp pinctrl", " - ARM: dts: imx6ull-seeed-npi: fix fsl,pins property in tscgrp pinctrl", " - tools/nolibc: include arch.h from string.h", " - soc: versatile: realview: fix memory leak during device remove", " - soc: versatile: realview: fix soc_dev leak during device remove", " - usb: typec: ucsi: Call CANCEL from single location", " - usb: typec: ucsi: Fix busy loop on ASUS VivoBooks", " - soc: qcom: geni-se: add GP_LENGTH/IRQ_EN_SET/IRQ_EN_CLEAR registers", " - serial: qcom-geni: fix arg types for qcom_geni_serial_poll_bit()", " - serial: qcom-geni: introduce qcom_geni_serial_poll_bitfield()", " - serial: qcom-geni: fix console corruption", " - thermal: core: Store trip sysfs attributes in thermal_trip_desc", " - thermal: sysfs: Get to trips via attribute pointers", " - thermal: sysfs: Refine the handling of trip hysteresis changes", " - thermal: sysfs: Add sanity checks for trip temperature and hysteresis", " - bpf: lsm: Set bpf_lsm_blob_sizes.lbs_task to 0", " - compiler.h: specify correct attribute for .rodata..c_jump_table", " - lockdep: fix deadlock issue between lockdep and rcu", " - mm/hugetlb_vmemmap: batch HVO work when demoting", " - s390/ftrace: Avoid calling unwinder in ftrace_return_address()", " - selftest mm/mseal: fix test_seal_mremap_move_dontunmap_anyaddr", " - mm: only enforce minimum stack gap size if it's sensible", " - spi: fspi: add support for imx8ulp", " - module: Fix KCOV-ignored file name", " - fbdev: xen-fbfront: Assign fb_info->device", " - tpm: export tpm2_sessions_init() to fix ibmvtpm building", " - mm/huge_memory: ensure huge_zero_folio won't have large_rmappable flag set", " - mm: change vmf_anon_prepare() to __vmf_anon_prepare()", " - mm/damon/vaddr: protect vma traversal in __damon_va_thre_regions() with rcu", " read lock", " - i2c: aspeed: Update the stop sw state when the bus recovery occurs", " - i2c: isch: Add missed 'else'", " - i2c: xiic: Try re-initialization on bus busy timeout", " - Documentation: KVM: fix warning in \"make htmldocs\"", " - spi: atmel-quadspi: Fix wrong register value written to MR", " - Revert: \"dm-verity: restart or panic on an I/O error\"", " - Linux 6.11.2", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47675", " - bpf: Fix use-after-free in bpf_uprobe_multi_link_attach()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47676", " - mm/hugetlb.c: fix UAF of vma in hugetlb fault pathway", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47677", " - exfat: resolve memory leak from exfat_create_upcase_table()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47725", " - dm-verity: restart or panic on an I/O error", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47739", " - padata: use integer wrap around to prevent deadlock on seq_nr overflow", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47678", " - icmp: change the order of rate limits", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47733", " - netfs: Delete subtree of 'fs/netfs' when netfs module exits", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47679", " - vfs: fix race between evice_inodes() and find_inode()&iput()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49859", " - f2fs: fix to check atomic_file in f2fs ioctl interfaces", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47680", " - f2fs: check discard support for conventional zones", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47740", " - f2fs: Require FMODE_WRITE for atomic write ioctls", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47726", " - f2fs: fix to wait dio completion", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47741", " - btrfs: fix race setting file private on concurrent lseek using same fd", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47681", " - wifi: mt76: mt7996: fix NULL pointer dereference in mt7996_mcu_sta_bfer_he", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49858", " - efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49860", " - ACPI: sysfs: validate return type of _STR method", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47742", " - firmware_loader: Block path traversal", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47682", " - scsi: sd: Fix off-by-one error in sd_read_block_characteristics()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47743", " - KEYS: prevent NULL pointer dereference in find_asymmetric_key()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47727", " - x86/tdx: Fix \"in-kernel MMIO\" check", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47744", " - KVM: Use dedicated mutex to protect kvm_usage_count to avoid deadlock", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47719", " - iommufd: Protect against overflow of ALIGN() during iova allocation", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47745", " - mm: call the security_mmap_file() LSM hook in remap_file_pages()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47746", " - fuse: use exclusive lock when FUSE_I_CACHE_IO_MODE is set", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47734", " - bonding: Fix unnecessary warnings and logs from bond_xdp_get_xmit_slave()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47684", " - tcp: check skb is non-NULL in tcp_rto_delta_us()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47747", " - net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race", " Condition", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47685", " - netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47686", " - ep93xx: clock: Fix off by one in ep93xx_div_recalc_rate()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47748", " - vhost_vdpa: assign irq bypass producer token correctly", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47687", " - vdpa/mlx5: Fix invalid mr resource destroy", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47688", " - driver core: Fix a potential null-ptr-deref in module_add_driver()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47689", " - f2fs: fix to don't set SB_RDONLY in f2fs_handle_critical_error()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47690", " - f2fs: get rid of online repaire on corrupted directory", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47691", " - f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47692", " - nfsd: return -EINVAL when namelen is 0", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47737", " - nfsd: call cache_put if xdr_reserve_space returns NULL", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2023-52917", " - ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47749", " - RDMA/cxgb4: Added NULL check for lookup_atid", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47735", " - RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47750", " - RDMA/hns: Fix Use-After-Free of rsv_qp on HIP08", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47751", " - PCI: kirin: Fix buffer overflow in kirin_pcie_parse_port()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47693", " - IB/core: Fix ib_cache_setup_one error flow cleanup", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47694", " - IB/mlx5: Fix UMR pd cleanup on error flow of driver init", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47695", " - RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47752", " - media: mediatek: vcodec: Fix H264 stateless decoder smatch warning", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47753", " - media: mediatek: vcodec: Fix VP8 stateless decoder smatch warning", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47754", " - media: mediatek: vcodec: Fix H264 multi stateless decoder smatch warning", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47696", " - RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47755", " - nvdimm: Fix devs leaks in scan_labels()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47756", " - PCI: keystone: Fix if-statement expression in ks_pcie_quirk()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47697", " - drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47698", " - drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47728", " - bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49861", " - bpf: Fix helper writes to read-only maps", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47757", " - nilfs2: fix potential oob read in nilfs_btree_check_delete()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47699", " - nilfs2: fix potential null-ptr-deref in nilfs_btree_insert()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47700", " - ext4: check stripe size compatibility on remount as well", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47701", " - ext4: avoid OOB when system.data xattr changes underneath the filesystem", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49850", " - bpf: correctly handle malformed BPF_CORE_TYPE_ID_LOCAL relos", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47702", " - bpf: Fail verification for sign-extension of packet data/data_end/data_meta", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47703", " - bpf, lsm: Add check for BPF LSM return value", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49851", " - tpm: Clean up TPM space after command failure", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47723", " - jfs: fix out-of-bounds in dbNextAG() and diAlloc()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49852", " - scsi: elx: libefc: Fix potential use after free in efc_nport_vport_del()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47720", " - drm/amd/display: Add null check for set_output_gamma in", " dcn30_set_output_transfer_func", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47704", " - drm/amd/display: Check link_res->hpo_dp_link_enc before using it", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49853", " - firmware: arm_scmi: Fix double free in OPTEE transport", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47705", " - block: fix potential invalid pointer dereference in blk_add_partition", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47736", " - erofs: handle overlapped pclusters out of crafted images properly", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47706", " - block, bfq: fix possible UAF for bfqq->bic with merge chain", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49855", " - nbd: fix race between timeout and normal completion", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47707", " - ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47708", " - netkit: Assign missing bpf_net_context", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47709", " - can: bcm: Clear bo->bcm_proc_read after remove_proc_entry().", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47710", " - sock_map: Add a cond_resched() in sock_hash_free()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47711", " - af_unix: Don't return OOB skb in manage_oob().", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47712", " - wifi: wilc1000: fix potential RCU dereference issue in", " wilc_parse_join_bss_param", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47713", " - wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47730", " - crypto: hisilicon/qm - inject error before stopping queue", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49856", " - x86/sgx: Fix deadlock in SGX NUMA node search", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47714", " - wifi: mt76: mt7996: use hweight16 to get correct tx antenna", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47715", " - wifi: mt76: mt7915: fix oops on non-dbdc mt7986", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49857", " - wifi: iwlwifi: mvm: set the cipher for secured NDP ranging", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47738", " - wifi: mac80211: don't use rate mask for offchannel TX either", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47731", " - drivers/perf: Fix ali_drw_pmu driver interrupt status clearing", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49862", " - powercap: intel_rapl: Fix off by one in get_rpi()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47716", " - ARM: 9410/1: vfp: Use asm volatile in fmrx/fmxr macros", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47717", " - RISC-V: KVM: Don't zero-out PMU snapshot area before freeing data", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47721", " - wifi: rtw89: remove unused C2H event ID RTW89_MAC_C2H_FUNC_READ_WOW_CAM to", " prevent out-of-bounds reading", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47732", " - crypto: iaa - Fix potential use after free bug", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47718", " - wifi: rtw88: always wait for both firmware loading attempts", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47724", " - wifi: ath11k: use work queue to process beacon tx event", "", " * Oracular update: v6.11.1 upstream stable release (LP: #2089020)", " - powercap/intel_rapl: Add support for AMD family 1Ah", " - powercap/intel_rapl: Fix the energy-pkg event for AMD CPUs", " - cpufreq/amd-pstate: Add the missing cpufreq_cpu_put()", " - netfilter: nft_socket: Fix a NULL vs IS_ERR() bug in", " nft_socket_cgroup_subtree_level()", " - ASoC: amd: acp: add ZSC control register programming sequence", " - nvme-pci: qdepth 1 quirk", " - USB: serial: pl2303: add device id for Macrosilicon MS3020", " - powercap: intel_rapl: Change an error pointer to NULL", " - Linux 6.11.1", "", " * Oracular update: v6.11.1 upstream stable release (LP: #2089020) //", " CVE-2024-47671", " - USB: usbtmc: prevent kernel-usb-infoleak", "", " * Oracular update: v6.11.1 upstream stable release (LP: #2089020) //", " CVE-2024-46869", " - Bluetooth: btintel_pcie: Allocate memory for driver private data", "", " * CVE-2024-53164", " - net: sched: fix ordering of qlen adjustment", "", " * CVE-2024-53103", " - hv_sock: Initializing vsk->trans to NULL to prevent a dangling pointer", "" ], "package": "linux", "version": "6.11.0-17.17", "urgency": "medium", "distributions": "oracular", "launchpad_bugs_fixed": [ 2093643, 1786013, 2091744, 2091184, 2093146, 2085406, 2089684, 2090932, 2085485, 2089357, 2089306, 2091655, 2091655, 2091655, 2091655, 2091655, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091386, 2091990, 2089327, 2089113, 2086587, 2086606, 2085950, 2085944, 2087853, 2087983, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089020, 2089020, 2089020 ], "author": "Stefan Bader ", "date": "Thu, 16 Jan 2025 22:38:59 +0100" } ], "notes": "linux-tools-6.11.0-18 version '6.11.0-18.18' (source package linux version '6.11.0-18.18') was added. linux-tools-6.11.0-18 version '6.11.0-18.18' has the same source package name, linux, as removed package linux-headers-6.11.0-14. As such we can use the source package version of the removed package, '6.11.0-14.15', 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." }, { "name": "linux-tools-6.11.0-18-generic", "from_version": { "source_package_name": "linux", "source_package_version": "6.11.0-14.15", "version": null }, "to_version": { "source_package_name": "linux", "source_package_version": "6.11.0-18.18", "version": "6.11.0-18.18" }, "cves": [ { "cve": "CVE-2025-0927", "url": "https://ubuntu.com/security/CVE-2025-0927", "cve_description": "[fs: hfs/hfsplus: add key_len boundary check to hfs_bnode_read_key]", "cve_priority": "medium", "cve_public_date": "2025-02-13" }, { "cve": "CVE-2024-53141", "url": "https://ubuntu.com/security/CVE-2024-53141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: add missing range check in bitmap_ip_uadt When tb[IPSET_ATTR_IP_TO] is not present but tb[IPSET_ATTR_CIDR] exists, the values of ip and ip_to are slightly swapped. Therefore, the range check for ip should be done later, but this part is missing and it seems that the vulnerability occurs. So we should add missing range checks and remove unnecessary range checks.", "cve_priority": "medium", "cve_public_date": "2024-12-06 10:15:00 UTC" }, { "cve": "CVE-2024-50010", "url": "https://ubuntu.com/security/CVE-2024-50010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exec: don't WARN for racy path_noexec check Both i_mode and noexec checks wrapped in WARN_ON stem from an artifact of the previous implementation. They used to legitimately check for the condition, but that got moved up in two commits: 633fb6ac3980 (\"exec: move S_ISREG() check earlier\") 0fd338b2d2cd (\"exec: move path_noexec() check earlier\") Instead of being removed said checks are WARN_ON'ed instead, which has some debug value. However, the spurious path_noexec check is racy, resulting in unwarranted warnings should someone race with setting the noexec flag. One can note there is more to perm-checking whether execve is allowed and none of the conditions are guaranteed to still hold after they were tested for. Additionally this does not validate whether the code path did any perm checking to begin with -- it will pass if the inode happens to be regular. Keep the redundant path_noexec() check even though it's mindless nonsense checking for guarantee that isn't given so drop the WARN. Reword the commentary and do small tidy ups while here. [brauner: keep redundant path_noexec() check]", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-53143", "url": "https://ubuntu.com/security/CVE-2024-53143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fsnotify: Fix ordering of iput() and watched_objects decrement Ensure the superblock is kept alive until we're done with iput(). Holding a reference to an inode is not allowed unless we ensure the superblock stays alive, which fsnotify does by keeping the watched_objects count elevated, so iput() must happen before the watched_objects decrement. This can lead to a UAF of something like sb->s_fs_info in tmpfs, but the UAF is hard to hit because race orderings that oops are more likely, thanks to the CHECK_DATA_CORRUPTION() block in generic_shutdown_super(). Also, ensure that fsnotify_put_sb_watched_objects() doesn't call fsnotify_sb_watched_objects() on a superblock that may have already been freed, which would cause a UAF read of sb->s_fsnotify_info.", "cve_priority": "medium", "cve_public_date": "2024-12-07 07:15:00 UTC" }, { "cve": "CVE-2024-53142", "url": "https://ubuntu.com/security/CVE-2024-53142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: initramfs: avoid filename buffer overrun The initramfs filename field is defined in Documentation/driver-api/early-userspace/buffer-format.rst as: 37 cpio_file := ALGN(4) + cpio_header + filename + \"\\0\" + ALGN(4) + data ... 55 ============= ================== ========================= 56 Field name Field size Meaning 57 ============= ================== ========================= ... 70 c_namesize 8 bytes Length of filename, including final \\0 When extracting an initramfs cpio archive, the kernel's do_name() path handler assumes a zero-terminated path at @collected, passing it directly to filp_open() / init_mkdir() / init_mknod(). If a specially crafted cpio entry carries a non-zero-terminated filename and is followed by uninitialized memory, then a file may be created with trailing characters that represent the uninitialized memory. The ability to create an initramfs entry would imply already having full control of the system, so the buffer overrun shouldn't be considered a security vulnerability. Append the output of the following bash script to an existing initramfs and observe any created /initramfs_test_fname_overrunAA* path. E.g. ./reproducer.sh | gzip >> /myinitramfs It's easiest to observe non-zero uninitialized memory when the output is gzipped, as it'll overflow the heap allocated @out_buf in __gunzip(), rather than the initrd_start+initrd_size block. ---- reproducer.sh ---- nilchar=\"A\"\t# change to \"\\0\" to properly zero terminate / pad magic=\"070701\" ino=1 mode=$(( 0100777 )) uid=0 gid=0 nlink=1 mtime=1 filesize=0 devmajor=0 devminor=1 rdevmajor=0 rdevminor=0 csum=0 fname=\"initramfs_test_fname_overrun\" namelen=$(( ${#fname} + 1 ))\t# plus one to account for terminator printf \"%s%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%s\" \\ \t$magic $ino $mode $uid $gid $nlink $mtime $filesize \\ \t$devmajor $devminor $rdevmajor $rdevminor $namelen $csum $fname termpadlen=$(( 1 + ((4 - ((110 + $namelen) & 3)) % 4) )) printf \"%.s${nilchar}\" $(seq 1 $termpadlen) ---- reproducer.sh ---- Symlink filename fields handled in do_symlink() won't overrun past the data segment, due to the explicit zero-termination of the symlink target. Fix filename buffer overrun by aborting the initramfs FSM if any cpio entry doesn't carry a zero-terminator at the expected (name_len - 1) offset.", "cve_priority": "medium", "cve_public_date": "2024-12-06 10:15:00 UTC" }, { "cve": "CVE-2024-53133", "url": "https://ubuntu.com/security/CVE-2024-53133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Handle dml allocation failure to avoid crash [Why] In the case where a dml allocation fails for any reason, the current state's dml contexts would no longer be valid. Then subsequent calls dc_state_copy_internal would shallow copy invalid memory and if the new state was released, a double free would occur. [How] Reset dml pointers in new_state to NULL and avoid invalid pointer (cherry picked from commit bcafdc61529a48f6f06355d78eb41b3aeda5296c)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53108", "url": "https://ubuntu.com/security/CVE-2024-53108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Adjust VSDB parser for replay feature At some point, the IEEE ID identification for the replay check in the AMD EDID was added. However, this check causes the following out-of-bounds issues when using KASAN: [ 27.804016] BUG: KASAN: slab-out-of-bounds in amdgpu_dm_update_freesync_caps+0xefa/0x17a0 [amdgpu] [ 27.804788] Read of size 1 at addr ffff8881647fdb00 by task systemd-udevd/383 ... [ 27.821207] Memory state around the buggy address: [ 27.821215] ffff8881647fda00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821224] ffff8881647fda80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821234] >ffff8881647fdb00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821243] ^ [ 27.821250] ffff8881647fdb80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821259] ffff8881647fdc00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821268] ================================================================== This is caused because the ID extraction happens outside of the range of the edid lenght. This commit addresses this issue by considering the amd_vsdb_block size. (cherry picked from commit b7e381b1ccd5e778e3d9c44c669ad38439a861d8)", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53134", "url": "https://ubuntu.com/security/CVE-2024-53134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pmdomain: imx93-blk-ctrl: correct remove path The check condition should be 'i < bc->onecell_data.num_domains', not 'bc->onecell_data.num_domains' which will make the look never finish and cause kernel panic. Also disable runtime to address \"imx93-blk-ctrl 4ac10000.system-controller: Unbalanced pm_runtime_enable!\"", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53132", "url": "https://ubuntu.com/security/CVE-2024-53132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/oa: Fix \"Missing outer runtime PM protection\" warning Fix the following drm_WARN: [953.586396] xe 0000:00:02.0: [drm] Missing outer runtime PM protection ... <4> [953.587090] ? xe_pm_runtime_get_noresume+0x8d/0xa0 [xe] <4> [953.587208] guc_exec_queue_add_msg+0x28/0x130 [xe] <4> [953.587319] guc_exec_queue_fini+0x3a/0x40 [xe] <4> [953.587425] xe_exec_queue_destroy+0xb3/0xf0 [xe] <4> [953.587515] xe_oa_release+0x9c/0xc0 [xe] (cherry picked from commit b107c63d2953907908fd0cafb0e543b3c3167b75)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53127", "url": "https://ubuntu.com/security/CVE-2024-53127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Revert \"mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K\" The commit 8396c793ffdf (\"mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K\") increased the max_req_size, even for 4K pages, causing various issues: - Panic booting the kernel/rootfs from an SD card on Rockchip RK3566 - Panic booting the kernel/rootfs from an SD card on StarFive JH7100 - \"swiotlb buffer is full\" and data corruption on StarFive JH7110 At this stage no fix have been found, so it's probably better to just revert the change. This reverts commit 8396c793ffdf28bb8aee7cfe0891080f8cab7890.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53130", "url": "https://ubuntu.com/security/CVE-2024-53130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint When using the \"block:block_dirty_buffer\" tracepoint, mark_buffer_dirty() may cause a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because, since the tracepoint was added in mark_buffer_dirty(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, nilfs_grab_buffer(), which grabs a buffer to read (or create) a block of metadata, including b-tree node blocks, does not set the block device, but instead does so only if the buffer is not in the \"uptodate\" state for each of its caller block reading functions. However, if the uptodate flag is set on a folio/page, and the buffer heads are detached from it by try_to_free_buffers(), and new buffer heads are then attached by create_empty_buffers(), the uptodate flag may be restored to each buffer without the block device being set to bh->b_bdev, and mark_buffer_dirty() may be called later in that state, resulting in the bug mentioned above. Fix this issue by making nilfs_grab_buffer() always set the block device of the super block structure to the buffer head, regardless of the state of the buffer's uptodate flag.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53105", "url": "https://ubuntu.com/security/CVE-2024-53105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: page_alloc: move mlocked flag clearance into free_pages_prepare() Syzbot reported a bad page state problem caused by a page being freed using free_page() still having a mlocked flag at free_pages_prepare() stage: BUG: Bad page state in process syz.5.504 pfn:61f45 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x61f45 flags: 0xfff00000080204(referenced|workingset|mlocked|node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000080204 0000000000000000 dead000000000122 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set page_owner tracks the page as allocated page last allocated via order 0, migratetype Unmovable, gfp_mask 0x400dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO), pid 8443, tgid 8442 (syz.5.504), ts 201884660643, free_ts 201499827394 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1537 prep_new_page mm/page_alloc.c:1545 [inline] get_page_from_freelist+0x303f/0x3190 mm/page_alloc.c:3457 __alloc_pages_noprof+0x292/0x710 mm/page_alloc.c:4733 alloc_pages_mpol_noprof+0x3e8/0x680 mm/mempolicy.c:2265 kvm_coalesced_mmio_init+0x1f/0xf0 virt/kvm/coalesced_mmio.c:99 kvm_create_vm virt/kvm/kvm_main.c:1235 [inline] kvm_dev_ioctl_create_vm virt/kvm/kvm_main.c:5488 [inline] kvm_dev_ioctl+0x12dc/0x2240 virt/kvm/kvm_main.c:5530 __do_compat_sys_ioctl fs/ioctl.c:1007 [inline] __se_compat_sys_ioctl+0x510/0xc90 fs/ioctl.c:950 do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline] __do_fast_syscall_32+0xb4/0x110 arch/x86/entry/common.c:386 do_fast_syscall_32+0x34/0x80 arch/x86/entry/common.c:411 entry_SYSENTER_compat_after_hwframe+0x84/0x8e page last free pid 8399 tgid 8399 stack trace: reset_page_owner include/linux/page_owner.h:25 [inline] free_pages_prepare mm/page_alloc.c:1108 [inline] free_unref_folios+0xf12/0x18d0 mm/page_alloc.c:2686 folios_put_refs+0x76c/0x860 mm/swap.c:1007 free_pages_and_swap_cache+0x5c8/0x690 mm/swap_state.c:335 __tlb_batch_free_encoded_pages mm/mmu_gather.c:136 [inline] tlb_batch_pages_flush mm/mmu_gather.c:149 [inline] tlb_flush_mmu_free mm/mmu_gather.c:366 [inline] tlb_flush_mmu+0x3a3/0x680 mm/mmu_gather.c:373 tlb_finish_mmu+0xd4/0x200 mm/mmu_gather.c:465 exit_mmap+0x496/0xc40 mm/mmap.c:1926 __mmput+0x115/0x390 kernel/fork.c:1348 exit_mm+0x220/0x310 kernel/exit.c:571 do_exit+0x9b2/0x28e0 kernel/exit.c:926 do_group_exit+0x207/0x2c0 kernel/exit.c:1088 __do_sys_exit_group kernel/exit.c:1099 [inline] __se_sys_exit_group kernel/exit.c:1097 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1097 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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 Modules linked in: CPU: 0 UID: 0 PID: 8442 Comm: syz.5.504 Not tainted 6.12.0-rc6-syzkaller #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 bad_page+0x176/0x1d0 mm/page_alloc.c:501 free_page_is_bad mm/page_alloc.c:918 [inline] free_pages_prepare mm/page_alloc.c:1100 [inline] free_unref_page+0xed0/0xf20 mm/page_alloc.c:2638 kvm_destroy_vm virt/kvm/kvm_main.c:1327 [inline] kvm_put_kvm+0xc75/0x1350 virt/kvm/kvm_main.c:1386 kvm_vcpu_release+0x54/0x60 virt/kvm/kvm_main.c:4143 __fput+0x23f/0x880 fs/file_table.c:431 task_work_run+0x24f/0x310 kernel/task_work.c:239 exit_task_work include/linux/task_work.h:43 [inline] do_exit+0xa2f/0x28e0 kernel/exit.c:939 do_group_exit+0x207/0x2c0 kernel/exit.c:1088 __do_sys_exit_group kernel/exit.c:1099 [in ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53109", "url": "https://ubuntu.com/security/CVE-2024-53109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nommu: pass NULL argument to vma_iter_prealloc() When deleting a vma entry from a maple tree, it has to pass NULL to vma_iter_prealloc() in order to calculate internal state of the tree, but it passed a wrong argument. As a result, nommu kernels crashed upon accessing a vma iterator, such as acct_collect() reading the size of vma entries after do_munmap(). This commit fixes this issue by passing a right argument to the preallocation call.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53131", "url": "https://ubuntu.com/security/CVE-2024-53131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint Patch series \"nilfs2: fix null-ptr-deref bugs on block tracepoints\". This series fixes null pointer dereference bugs that occur when using nilfs2 and two block-related tracepoints. This patch (of 2): It has been reported that when using \"block:block_touch_buffer\" tracepoint, touch_buffer() called from __nilfs_get_folio_block() causes a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because since the tracepoint was added in touch_buffer(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, the block_device structure is set after the function returns to the caller. Here, touch_buffer() is used to mark the folio/page that owns the buffer head as accessed, but the common search helper for folio/page used by the caller function was optimized to mark the folio/page as accessed when it was reimplemented a long time ago, eliminating the need to call touch_buffer() here in the first place. So this solves the issue by eliminating the touch_buffer() call itself.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53135", "url": "https://ubuntu.com/security/CVE-2024-53135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: VMX: Bury Intel PT virtualization (guest/host mode) behind CONFIG_BROKEN Hide KVM's pt_mode module param behind CONFIG_BROKEN, i.e. disable support for virtualizing Intel PT via guest/host mode unless BROKEN=y. There are myriad bugs in the implementation, some of which are fatal to the guest, and others which put the stability and health of the host at risk. For guest fatalities, the most glaring issue is that KVM fails to ensure tracing is disabled, and *stays* disabled prior to VM-Enter, which is necessary as hardware disallows loading (the guest's) RTIT_CTL if tracing is enabled (enforced via a VMX consistency check). Per the SDM: If the logical processor is operating with Intel PT enabled (if IA32_RTIT_CTL.TraceEn = 1) at the time of VM entry, the \"load IA32_RTIT_CTL\" VM-entry control must be 0. On the host side, KVM doesn't validate the guest CPUID configuration provided by userspace, and even worse, uses the guest configuration to decide what MSRs to save/load at VM-Enter and VM-Exit. E.g. configuring guest CPUID to enumerate more address ranges than are supported in hardware will result in KVM trying to passthrough, save, and load non-existent MSRs, which generates a variety of WARNs, ToPA ERRORs in the host, a potential deadlock, etc.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53106", "url": "https://ubuntu.com/security/CVE-2024-53106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: fix buffer overrun in ima_eventdigest_init_common Function ima_eventdigest_init() calls ima_eventdigest_init_common() with HASH_ALGO__LAST which is then used to access the array hash_digest_size[] leading to buffer overrun. Have a conditional statement to handle this.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53110", "url": "https://ubuntu.com/security/CVE-2024-53110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vp_vdpa: fix id_table array not null terminated error Allocate one extra virtio_device_id as null terminator, otherwise vdpa_mgmtdev_get_classes() may iterate multiple times and visit undefined memory.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53126", "url": "https://ubuntu.com/security/CVE-2024-53126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa: solidrun: Fix UB bug with devres In psnet_open_pf_bar() and snet_open_vf_bar() a string later passed to pcim_iomap_regions() is placed on the stack. Neither pcim_iomap_regions() nor the functions it calls copy that string. Should the string later ever be used, this, consequently, causes undefined behavior since the stack frame will by then have disappeared. Fix the bug by allocating the strings on the heap through devm_kasprintf().", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53111", "url": "https://ubuntu.com/security/CVE-2024-53111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mremap: fix address wraparound in move_page_tables() On 32-bit platforms, it is possible for the expression `len + old_addr < old_end` to be false-positive if `len + old_addr` wraps around. `old_addr` is the cursor in the old range up to which page table entries have been moved; so if the operation succeeded, `old_addr` is the *end* of the old region, and adding `len` to it can wrap. The overflow causes mremap() to mistakenly believe that PTEs have been copied; the consequence is that mremap() bails out, but doesn't move the PTEs back before the new VMA is unmapped, causing anonymous pages in the region to be lost. So basically if userspace tries to mremap() a private-anon region and hits this bug, mremap() will return an error and the private-anon region's contents appear to have been zeroed. The idea of this check is that `old_end - len` is the original start address, and writing the check that way also makes it easier to read; so fix the check by rearranging the comparison accordingly. (An alternate fix would be to refactor this function by introducing an \"orig_old_start\" variable or such.) Tested in a VM with a 32-bit X86 kernel; without the patch: ``` user@horn:~/big_mremap$ cat test.c #define _GNU_SOURCE #include #include #include #include #define ADDR1 ((void*)0x60000000) #define ADDR2 ((void*)0x10000000) #define SIZE 0x50000000uL int main(void) { unsigned char *p1 = mmap(ADDR1, SIZE, PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0); if (p1 == MAP_FAILED) err(1, \"mmap 1\"); unsigned char *p2 = mmap(ADDR2, SIZE, PROT_NONE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0); if (p2 == MAP_FAILED) err(1, \"mmap 2\"); *p1 = 0x41; printf(\"first char is 0x%02hhx\\n\", *p1); unsigned char *p3 = mremap(p1, SIZE, SIZE, MREMAP_MAYMOVE|MREMAP_FIXED, p2); if (p3 == MAP_FAILED) { printf(\"mremap() failed; first char is 0x%02hhx\\n\", *p1); } else { printf(\"mremap() succeeded; first char is 0x%02hhx\\n\", *p3); } } user@horn:~/big_mremap$ gcc -static -o test test.c user@horn:~/big_mremap$ setarch -R ./test first char is 0x41 mremap() failed; first char is 0x00 ``` With the patch: ``` user@horn:~/big_mremap$ setarch -R ./test first char is 0x41 mremap() succeeded; first char is 0x41 ```", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53107", "url": "https://ubuntu.com/security/CVE-2024-53107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: prevent integer overflow in pagemap_scan_get_args() The \"arg->vec_len\" variable is a u64 that comes from the user at the start of the function. The \"arg->vec_len * sizeof(struct page_region))\" multiplication can lead to integer wrapping. Use size_mul() to avoid that. Also the size_add/mul() functions work on unsigned long so for 32bit systems we need to ensure that \"arg->vec_len\" fits in an unsigned long.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53128", "url": "https://ubuntu.com/security/CVE-2024-53128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/task_stack: fix object_is_on_stack() for KASAN tagged pointers When CONFIG_KASAN_SW_TAGS and CONFIG_KASAN_STACK are enabled, the object_is_on_stack() function may produce incorrect results due to the presence of tags in the obj pointer, while the stack pointer does not have tags. This discrepancy can lead to incorrect stack object detection and subsequently trigger warnings if CONFIG_DEBUG_OBJECTS is also enabled. Example of the warning: ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at lib/debugobjects.c:557 __debug_object_init+0x330/0x364 Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5 #4 Hardware name: linux,dummy-virt (DT) pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __debug_object_init+0x330/0x364 lr : __debug_object_init+0x330/0x364 sp : ffff800082ea7b40 x29: ffff800082ea7b40 x28: 98ff0000c0164518 x27: 98ff0000c0164534 x26: ffff800082d93ec8 x25: 0000000000000001 x24: 1cff0000c00172a0 x23: 0000000000000000 x22: ffff800082d93ed0 x21: ffff800081a24418 x20: 3eff800082ea7bb0 x19: efff800000000000 x18: 0000000000000000 x17: 00000000000000ff x16: 0000000000000047 x15: 206b63617473206e x14: 0000000000000018 x13: ffff800082ea7780 x12: 0ffff800082ea78e x11: 0ffff800082ea790 x10: 0ffff800082ea79d x9 : 34d77febe173e800 x8 : 34d77febe173e800 x7 : 0000000000000001 x6 : 0000000000000001 x5 : feff800082ea74b8 x4 : ffff800082870a90 x3 : ffff80008018d3c4 x2 : 0000000000000001 x1 : ffff800082858810 x0 : 0000000000000050 Call trace: __debug_object_init+0x330/0x364 debug_object_init_on_stack+0x30/0x3c schedule_hrtimeout_range_clock+0xac/0x26c schedule_hrtimeout+0x1c/0x30 wait_task_inactive+0x1d4/0x25c kthread_bind_mask+0x28/0x98 init_rescuer+0x1e8/0x280 workqueue_init+0x1a0/0x3cc kernel_init_freeable+0x118/0x200 kernel_init+0x28/0x1f0 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53112", "url": "https://ubuntu.com/security/CVE-2024-53112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: uncache inode which has failed entering the group Syzbot has reported the following BUG: kernel BUG at fs/ocfs2/uptodate.c:509! ... Call Trace: ? __die_body+0x5f/0xb0 ? die+0x9e/0xc0 ? do_trap+0x15a/0x3a0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? do_error_trap+0x1dc/0x2c0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? __pfx_do_error_trap+0x10/0x10 ? handle_invalid_op+0x34/0x40 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? exc_invalid_op+0x38/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? ocfs2_set_new_buffer_uptodate+0x2e/0x160 ? ocfs2_set_new_buffer_uptodate+0x144/0x160 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ocfs2_group_add+0x39f/0x15a0 ? __pfx_ocfs2_group_add+0x10/0x10 ? __pfx_lock_acquire+0x10/0x10 ? mnt_get_write_access+0x68/0x2b0 ? __pfx_lock_release+0x10/0x10 ? rcu_read_lock_any_held+0xb7/0x160 ? __pfx_rcu_read_lock_any_held+0x10/0x10 ? smack_log+0x123/0x540 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x226/0x2b0 ocfs2_ioctl+0x65e/0x7d0 ? __pfx_ocfs2_ioctl+0x10/0x10 ? smack_file_ioctl+0x29e/0x3a0 ? __pfx_smack_file_ioctl+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x43d/0x780 ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10 ? __pfx_ocfs2_ioctl+0x10/0x10 __se_sys_ioctl+0xfb/0x170 do_syscall_64+0xf3/0x230 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... When 'ioctl(OCFS2_IOC_GROUP_ADD, ...)' has failed for the particular inode in 'ocfs2_verify_group_and_input()', corresponding buffer head remains cached and subsequent call to the same 'ioctl()' for the same inode issues the BUG() in 'ocfs2_set_new_buffer_uptodate()' (trying to cache the same buffer head of that inode). Fix this by uncaching the buffer head with 'ocfs2_remove_from_cache()' on error path in 'ocfs2_group_add()'.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53113", "url": "https://ubuntu.com/security/CVE-2024-53113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: fix NULL pointer dereference in alloc_pages_bulk_noprof We triggered a NULL pointer dereference for ac.preferred_zoneref->zone in alloc_pages_bulk_noprof() when the task is migrated between cpusets. When cpuset is enabled, in prepare_alloc_pages(), ac->nodemask may be ¤t->mems_allowed. when first_zones_zonelist() is called to find preferred_zoneref, the ac->nodemask may be modified concurrently if the task is migrated between different cpusets. Assuming we have 2 NUMA Node, when traversing Node1 in ac->zonelist, the nodemask is 2, and when traversing Node2 in ac->zonelist, the nodemask is 1. As a result, the ac->preferred_zoneref points to NULL zone. In alloc_pages_bulk_noprof(), for_each_zone_zonelist_nodemask() finds a allowable zone and calls zonelist_node_idx(ac.preferred_zoneref), leading to NULL pointer dereference. __alloc_pages_noprof() fixes this issue by checking NULL pointer in commit ea57485af8f4 (\"mm, page_alloc: fix check for NULL preferred_zone\") and commit df76cee6bbeb (\"mm, page_alloc: remove redundant checks from alloc fastpath\"). To fix it, check NULL pointer for preferred_zoneref->zone.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53114", "url": "https://ubuntu.com/security/CVE-2024-53114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 client A number of Zen4 client SoCs advertise the ability to use virtualized VMLOAD/VMSAVE, but using these instructions is reported to be a cause of a random host reboot. These instructions aren't intended to be advertised on Zen4 client so clear the capability.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53137", "url": "https://ubuntu.com/security/CVE-2024-53137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: fix cacheflush with PAN It seems that the cacheflush syscall got broken when PAN for LPAE was implemented. User access was not enabled around the cache maintenance instructions, causing them to fault.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53115", "url": "https://ubuntu.com/security/CVE-2024-53115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: avoid null_ptr_deref in vmw_framebuffer_surface_create_handle The 'vmw_user_object_buffer' function may return NULL with incorrect inputs. To avoid possible null pointer dereference, add a check whether the 'bo' is NULL in the vmw_framebuffer_surface_create_handle.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53116", "url": "https://ubuntu.com/security/CVE-2024-53116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix handling of partial GPU mapping of BOs This commit fixes the bug in the handling of partial mapping of the buffer objects to the GPU, which caused kernel warnings. Panthor didn't correctly handle the case where the partial mapping spanned multiple scatterlists and the mapping offset didn't point to the 1st page of starting scatterlist. The offset variable was not cleared after reaching the starting scatterlist. Following warning messages were seen. WARNING: CPU: 1 PID: 650 at drivers/iommu/io-pgtable-arm.c:659 __arm_lpae_unmap+0x254/0x5a0 pc : __arm_lpae_unmap+0x254/0x5a0 lr : __arm_lpae_unmap+0x2cc/0x5a0 Call trace: __arm_lpae_unmap+0x254/0x5a0 __arm_lpae_unmap+0x108/0x5a0 __arm_lpae_unmap+0x108/0x5a0 __arm_lpae_unmap+0x108/0x5a0 arm_lpae_unmap_pages+0x80/0xa0 panthor_vm_unmap_pages+0xac/0x1c8 [panthor] panthor_gpuva_sm_step_unmap+0x4c/0xc8 [panthor] op_unmap_cb.isra.23.constprop.30+0x54/0x80 __drm_gpuvm_sm_unmap+0x184/0x1c8 drm_gpuvm_sm_unmap+0x40/0x60 panthor_vm_exec_op+0xa8/0x120 [panthor] panthor_vm_bind_exec_sync_op+0xc4/0xe8 [panthor] panthor_ioctl_vm_bind+0x10c/0x170 [panthor] drm_ioctl_kernel+0xbc/0x138 drm_ioctl+0x210/0x4b0 __arm64_sys_ioctl+0xb0/0xf8 invoke_syscall+0x4c/0x110 el0_svc_common.constprop.1+0x98/0xf8 do_el0_svc+0x24/0x38 el0_svc+0x34/0xc8 el0t_64_sync_handler+0xa0/0xc8 el0t_64_sync+0x174/0x178 panthor : [drm] drm_WARN_ON(unmapped_sz != pgsize * pgcount) WARNING: CPU: 1 PID: 650 at drivers/gpu/drm/panthor/panthor_mmu.c:922 panthor_vm_unmap_pages+0x124/0x1c8 [panthor] pc : panthor_vm_unmap_pages+0x124/0x1c8 [panthor] lr : panthor_vm_unmap_pages+0x124/0x1c8 [panthor] panthor : [drm] *ERROR* failed to unmap range ffffa388f000-ffffa3890000 (requested range ffffa388c000-ffffa3890000)", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53117", "url": "https://ubuntu.com/security/CVE-2024-53117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio/vsock: Improve MSG_ZEROCOPY error handling Add a missing kfree_skb() to prevent memory leaks.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53118", "url": "https://ubuntu.com/security/CVE-2024-53118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Fix sk_error_queue memory leak Kernel queues MSG_ZEROCOPY completion notifications on the error queue. Where they remain, until explicitly recv()ed. To prevent memory leaks, clean up the queue when the socket is destroyed. unreferenced object 0xffff8881028beb00 (size 224): comm \"vsock_test\", pid 1218, jiffies 4294694897 hex dump (first 32 bytes): 90 b0 21 17 81 88 ff ff 90 b0 21 17 81 88 ff ff ..!.......!..... 00 00 00 00 00 00 00 00 00 b0 21 17 81 88 ff ff ..........!..... backtrace (crc 6c7031ca): [] kmem_cache_alloc_node_noprof+0x2f7/0x370 [] __alloc_skb+0x132/0x180 [] sock_omalloc+0x4b/0x80 [] msg_zerocopy_realloc+0x9e/0x240 [] virtio_transport_send_pkt_info+0x412/0x4c0 [] virtio_transport_stream_enqueue+0x43/0x50 [] vsock_connectible_sendmsg+0x373/0x450 [] ____sys_sendmsg+0x365/0x3a0 [] ___sys_sendmsg+0x84/0xd0 [] __sys_sendmsg+0x47/0x80 [] do_syscall_64+0x93/0x180 [] entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53119", "url": "https://ubuntu.com/security/CVE-2024-53119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio/vsock: Fix accept_queue memory leak As the final stages of socket destruction may be delayed, it is possible that virtio_transport_recv_listen() will be called after the accept_queue has been flushed, but before the SOCK_DONE flag has been set. As a result, sockets enqueued after the flush would remain unremoved, leading to a memory leak. vsock_release __vsock_release lock virtio_transport_release virtio_transport_close schedule_delayed_work(close_work) sk_shutdown = SHUTDOWN_MASK (!) flush accept_queue release virtio_transport_recv_pkt vsock_find_bound_socket lock if flag(SOCK_DONE) return virtio_transport_recv_listen child = vsock_create_connected (!) vsock_enqueue_accept(child) release close_work lock virtio_transport_do_close set_flag(SOCK_DONE) virtio_transport_remove_sock vsock_remove_sock vsock_remove_bound release Introduce a sk_shutdown check to disallow vsock_enqueue_accept() during socket destruction. unreferenced object 0xffff888109e3f800 (size 2040): comm \"kworker/5:2\", pid 371, jiffies 4294940105 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00 (..@............ backtrace (crc 9e5f4e84): [] kmem_cache_alloc_noprof+0x2c1/0x360 [] sk_prot_alloc+0x30/0x120 [] sk_alloc+0x2c/0x4b0 [] __vsock_create.constprop.0+0x2a/0x310 [] virtio_transport_recv_pkt+0x4dc/0x9a0 [] vsock_loopback_work+0xfd/0x140 [] process_one_work+0x20c/0x570 [] worker_thread+0x1bf/0x3a0 [] kthread+0xdd/0x110 [] ret_from_fork+0x2d/0x50 [] ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53120", "url": "https://ubuntu.com/security/CVE-2024-53120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: CT: Fix null-ptr-deref in add rule err flow In error flow of mlx5_tc_ct_entry_add_rule(), in case ct_rule_add() callback returns error, zone_rule->attr is used uninitiated. Fix it to use attr which has the needed pointer value. Kernel log: BUG: kernel NULL pointer dereference, address: 0000000000000110 RIP: 0010:mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core] … Call Trace: ? __die+0x20/0x70 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x140 ? asm_exc_page_fault+0x22/0x30 ? mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core] ? mlx5_tc_ct_entry_add_rule+0x1d5/0x2f0 [mlx5_core] mlx5_tc_ct_block_flow_offload+0xc6a/0xf90 [mlx5_core] ? nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] flow_offload_work_handler+0x142/0x320 [nf_flow_table] ? finish_task_switch.isra.0+0x15b/0x2b0 process_one_work+0x16c/0x320 worker_thread+0x28c/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xb8/0xf0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53138", "url": "https://ubuntu.com/security/CVE-2024-53138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: kTLS, Fix incorrect page refcounting The kTLS tx handling code is using a mix of get_page() and page_ref_inc() APIs to increment the page reference. But on the release path (mlx5e_ktls_tx_handle_resync_dump_comp()), only put_page() is used. This is an issue when using pages from large folios: the get_page() references are stored on the folio page while the page_ref_inc() references are stored directly in the given page. On release the folio page will be dereferenced too many times. This was found while doing kTLS testing with sendfile() + ZC when the served file was read from NFS on a kernel with NFS large folios support (commit 49b29a573da8 (\"nfs: add support for large folios\")).", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53121", "url": "https://ubuntu.com/security/CVE-2024-53121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: fs, lock FTE when checking if active The referenced commits introduced a two-step process for deleting FTEs: - Lock the FTE, delete it from hardware, set the hardware deletion function to NULL and unlock the FTE. - Lock the parent flow group, delete the software copy of the FTE, and remove it from the xarray. However, this approach encounters a race condition if a rule with the same match value is added simultaneously. In this scenario, fs_core may set the hardware deletion function to NULL prematurely, causing a panic during subsequent rule deletions. To prevent this, ensure the active flag of the FTE is checked under a lock, which will prevent the fs_core layer from attaching a new steering rule to an FTE that is in the process of deletion. [ 438.967589] MOSHE: 2496 mlx5_del_flow_rules del_hw_func [ 438.968205] ------------[ cut here ]------------ [ 438.968654] refcount_t: decrement hit 0; leaking memory. [ 438.969249] WARNING: CPU: 0 PID: 8957 at lib/refcount.c:31 refcount_warn_saturate+0xfb/0x110 [ 438.970054] Modules linked in: act_mirred cls_flower act_gact sch_ingress openvswitch nsh mlx5_vdpa vringh vhost_iotlb vdpa mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core zram zsmalloc fuse [last unloaded: cls_flower] [ 438.973288] CPU: 0 UID: 0 PID: 8957 Comm: tc Not tainted 6.12.0-rc1+ #8 [ 438.973888] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 438.974874] RIP: 0010:refcount_warn_saturate+0xfb/0x110 [ 438.975363] Code: 40 66 3b 82 c6 05 16 e9 4d 01 01 e8 1f 7c a0 ff 0f 0b c3 cc cc cc cc 48 c7 c7 10 66 3b 82 c6 05 fd e8 4d 01 01 e8 05 7c a0 ff <0f> 0b c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 90 [ 438.976947] RSP: 0018:ffff888124a53610 EFLAGS: 00010286 [ 438.977446] RAX: 0000000000000000 RBX: ffff888119d56de0 RCX: 0000000000000000 [ 438.978090] RDX: ffff88852c828700 RSI: ffff88852c81b3c0 RDI: ffff88852c81b3c0 [ 438.978721] RBP: ffff888120fa0e88 R08: 0000000000000000 R09: ffff888124a534b0 [ 438.979353] R10: 0000000000000001 R11: 0000000000000001 R12: ffff888119d56de0 [ 438.979979] R13: ffff888120fa0ec0 R14: ffff888120fa0ee8 R15: ffff888119d56de0 [ 438.980607] FS: 00007fe6dcc0f800(0000) GS:ffff88852c800000(0000) knlGS:0000000000000000 [ 438.983984] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 438.984544] CR2: 00000000004275e0 CR3: 0000000186982001 CR4: 0000000000372eb0 [ 438.985205] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 438.985842] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 438.986507] Call Trace: [ 438.986799] [ 438.987070] ? __warn+0x7d/0x110 [ 438.987426] ? refcount_warn_saturate+0xfb/0x110 [ 438.987877] ? report_bug+0x17d/0x190 [ 438.988261] ? prb_read_valid+0x17/0x20 [ 438.988659] ? handle_bug+0x53/0x90 [ 438.989054] ? exc_invalid_op+0x14/0x70 [ 438.989458] ? asm_exc_invalid_op+0x16/0x20 [ 438.989883] ? refcount_warn_saturate+0xfb/0x110 [ 438.990348] mlx5_del_flow_rules+0x2f7/0x340 [mlx5_core] [ 438.990932] __mlx5_eswitch_del_rule+0x49/0x170 [mlx5_core] [ 438.991519] ? mlx5_lag_is_sriov+0x3c/0x50 [mlx5_core] [ 438.992054] ? xas_load+0x9/0xb0 [ 438.992407] mlx5e_tc_rule_unoffload+0x45/0xe0 [mlx5_core] [ 438.993037] mlx5e_tc_del_fdb_flow+0x2a6/0x2e0 [mlx5_core] [ 438.993623] mlx5e_flow_put+0x29/0x60 [mlx5_core] [ 438.994161] mlx5e_delete_flower+0x261/0x390 [mlx5_core] [ 438.994728] tc_setup_cb_destroy+0xb9/0x190 [ 438.995150] fl_hw_destroy_filter+0x94/0xc0 [cls_flower] [ 438.995650] fl_change+0x11a4/0x13c0 [cls_flower] [ 438.996105] tc_new_tfilter+0x347/0xbc0 [ 438.996503] ? __ ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53122", "url": "https://ubuntu.com/security/CVE-2024-53122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: cope racing subflow creation in mptcp_rcv_space_adjust Additional active subflows - i.e. created by the in kernel path manager - are included into the subflow list before starting the 3whs. A racing recvmsg() spooling data received on an already established subflow would unconditionally call tcp_cleanup_rbuf() on all the current subflows, potentially hitting a divide by zero error on the newly created ones. Explicitly check that the subflow is in a suitable state before invoking tcp_cleanup_rbuf().", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53123", "url": "https://ubuntu.com/security/CVE-2024-53123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: error out earlier on disconnect Eric reported a division by zero splat in the MPTCP protocol: Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 6094 Comm: syz-executor317 Not tainted 6.12.0-rc5-syzkaller-00291-g05b92660cdfe #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:__tcp_select_window+0x5b4/0x1310 net/ipv4/tcp_output.c:3163 Code: f6 44 01 e3 89 df e8 9b 75 09 f8 44 39 f3 0f 8d 11 ff ff ff e8 0d 74 09 f8 45 89 f4 e9 04 ff ff ff e8 00 74 09 f8 44 89 f0 99 7c 24 14 41 29 d6 45 89 f4 e9 ec fe ff ff e8 e8 73 09 f8 48 89 RSP: 0018:ffffc900041f7930 EFLAGS: 00010293 RAX: 0000000000017e67 RBX: 0000000000017e67 RCX: ffffffff8983314b RDX: 0000000000000000 RSI: ffffffff898331b0 RDI: 0000000000000004 RBP: 00000000005d6000 R08: 0000000000000004 R09: 0000000000017e67 R10: 0000000000003e80 R11: 0000000000000000 R12: 0000000000003e80 R13: ffff888031d9b440 R14: 0000000000017e67 R15: 00000000002eb000 FS: 00007feb5d7f16c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007feb5d8adbb8 CR3: 0000000074e4c000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __tcp_cleanup_rbuf+0x3e7/0x4b0 net/ipv4/tcp.c:1493 mptcp_rcv_space_adjust net/mptcp/protocol.c:2085 [inline] mptcp_recvmsg+0x2156/0x2600 net/mptcp/protocol.c:2289 inet_recvmsg+0x469/0x6a0 net/ipv4/af_inet.c:885 sock_recvmsg_nosec net/socket.c:1051 [inline] sock_recvmsg+0x1b2/0x250 net/socket.c:1073 __sys_recvfrom+0x1a5/0x2e0 net/socket.c:2265 __do_sys_recvfrom net/socket.c:2283 [inline] __se_sys_recvfrom net/socket.c:2279 [inline] __x64_sys_recvfrom+0xe0/0x1c0 net/socket.c:2279 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 RIP: 0033:0x7feb5d857559 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:00007feb5d7f1208 EFLAGS: 00000246 ORIG_RAX: 000000000000002d RAX: ffffffffffffffda RBX: 00007feb5d8e1318 RCX: 00007feb5d857559 RDX: 000000800000000e RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007feb5d8e1310 R08: 0000000000000000 R09: ffffffff81000000 R10: 0000000000000100 R11: 0000000000000246 R12: 00007feb5d8e131c R13: 00007feb5d8ae074 R14: 000000800000000e R15: 00000000fffffdef and provided a nice reproducer. The root cause is the current bad handling of racing disconnect. After the blamed commit below, sk_wait_data() can return (with error) with the underlying socket disconnected and a zero rcv_mss. Catch the error and return without performing any additional operations on the current socket.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53124", "url": "https://ubuntu.com/security/CVE-2024-53124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix data-races around sk->sk_forward_alloc Syzkaller reported this warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 16 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x1c5/0x1e0 Modules linked in: CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:inet_sock_destruct+0x1c5/0x1e0 Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 <0f> 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00 RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206 RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007 RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00 RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007 R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00 R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78 FS: 0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn+0x88/0x130 ? inet_sock_destruct+0x1c5/0x1e0 ? report_bug+0x18e/0x1a0 ? handle_bug+0x53/0x90 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? inet_sock_destruct+0x1c5/0x1e0 __sk_destruct+0x2a/0x200 rcu_do_batch+0x1aa/0x530 ? rcu_do_batch+0x13b/0x530 rcu_core+0x159/0x2f0 handle_softirqs+0xd3/0x2b0 ? __pfx_smpboot_thread_fn+0x10/0x10 run_ksoftirqd+0x25/0x30 smpboot_thread_fn+0xdd/0x1d0 kthread+0xd3/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ---[ end trace 0000000000000000 ]--- Its possible that two threads call tcp_v6_do_rcv()/sk_forward_alloc_add() concurrently when sk->sk_state == TCP_LISTEN with sk->sk_lock unlocked, which triggers a data-race around sk->sk_forward_alloc: tcp_v6_rcv tcp_v6_do_rcv skb_clone_and_charge_r sk_rmem_schedule __sk_mem_schedule sk_forward_alloc_add() skb_set_owner_r sk_mem_charge sk_forward_alloc_add() __kfree_skb skb_release_all skb_release_head_state sock_rfree sk_mem_uncharge sk_forward_alloc_add() sk_mem_reclaim // set local var reclaimable __sk_mem_reclaim sk_forward_alloc_add() In this syzkaller testcase, two threads call tcp_v6_do_rcv() with skb->truesize=768, the sk_forward_alloc changes like this: (cpu 1) | (cpu 2) | sk_forward_alloc ... | ... | 0 __sk_mem_schedule() | | +4096 = 4096 | __sk_mem_schedule() | +4096 = 8192 sk_mem_charge() | | -768 = 7424 | sk_mem_charge() | -768 = 6656 ... | ... | sk_mem_uncharge() | | +768 = 7424 reclaimable=7424 | | | sk_mem_uncharge() | +768 = 8192 | reclaimable=8192 | __sk_mem_reclaim() | | -4096 = 4096 | __sk_mem_reclaim() | -8192 = -4096 != 0 The skb_clone_and_charge_r() should not be called in tcp_v6_do_rcv() when sk->sk_state is TCP_LISTEN, it happens later in tcp_v6_syn_recv_sock(). Fix the same issue in dccp_v6_do_rcv().", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53129", "url": "https://ubuntu.com/security/CVE-2024-53129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: vop: Fix a dereferenced before check warning The 'state' can't be NULL, we should check crtc_state. Fix warning: drivers/gpu/drm/rockchip/rockchip_drm_vop.c:1096 vop_plane_atomic_async_check() warn: variable dereferenced before check 'state' (see line 1077)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53139", "url": "https://ubuntu.com/security/CVE-2024-53139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix possible UAF in sctp_v6_available() A lockdep report [1] with CONFIG_PROVE_RCU_LIST=y hints that sctp_v6_available() is calling dev_get_by_index_rcu() and ipv6_chk_addr() without holding rcu. [1] ============================= WARNING: suspicious RCU usage 6.12.0-rc5-virtme #1216 Tainted: G W ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by sctp_hello/31495: #0: ffff9f1ebbdb7418 (sk_lock-AF_INET6){+.+.}-{0:0}, at: sctp_bind (./arch/x86/include/asm/jump_label.h:27 net/sctp/socket.c:315) sctp stack backtrace: CPU: 7 UID: 0 PID: 31495 Comm: sctp_hello Tainted: G W 6.12.0-rc5-virtme #1216 Tainted: [W]=WARN 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:123) lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822) dev_get_by_index_rcu (net/core/dev.c:876 (discriminator 7)) sctp_v6_available (net/sctp/ipv6.c:701) sctp sctp_do_bind (net/sctp/socket.c:400 (discriminator 1)) sctp sctp_bind (net/sctp/socket.c:320) sctp inet6_bind_sk (net/ipv6/af_inet6.c:465) ? security_socket_bind (security/security.c:4581 (discriminator 1)) __sys_bind (net/socket.c:1848 net/socket.c:1869) ? do_user_addr_fault (./include/linux/rcupdate.h:347 ./include/linux/rcupdate.h:880 ./include/linux/mm.h:729 arch/x86/mm/fault.c:1340) ? do_user_addr_fault (./arch/x86/include/asm/preempt.h:84 (discriminator 13) ./include/linux/rcupdate.h:98 (discriminator 13) ./include/linux/rcupdate.h:882 (discriminator 13) ./include/linux/mm.h:729 (discriminator 13) arch/x86/mm/fault.c:1340 (discriminator 13)) __x64_sys_bind (net/socket.c:1877 (discriminator 1) net/socket.c:1875 (discriminator 1) net/socket.c:1875 (discriminator 1)) do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f59b934a1e7 Code: 44 00 00 48 8b 15 39 8c 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 b8 31 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 09 8c 0c 00 f7 d8 64 89 01 48 All code ======== 0:\t44 00 00 \tadd %r8b,(%rax) 3:\t48 8b 15 39 8c 0c 00 \tmov 0xc8c39(%rip),%rdx # 0xc8c43 a:\tf7 d8 \tneg %eax c:\t64 89 02 \tmov %eax,%fs:(%rdx) f:\tb8 ff ff ff ff \tmov $0xffffffff,%eax 14:\teb bd \tjmp 0xffffffffffffffd3 16:\t66 2e 0f 1f 84 00 00 \tcs nopw 0x0(%rax,%rax,1) 1d:\t00 00 00 20:\t0f 1f 00 \tnopl (%rax) 23:\tb8 31 00 00 00 \tmov $0x31,%eax 28:\t0f 05 \tsyscall 2a:*\t48 3d 01 f0 ff ff \tcmp $0xfffffffffffff001,%rax\t\t<-- trapping instruction 30:\t73 01 \tjae 0x33 32:\tc3 \tret 33:\t48 8b 0d 09 8c 0c 00 \tmov 0xc8c09(%rip),%rcx # 0xc8c43 3a:\tf7 d8 \tneg %eax 3c:\t64 89 01 \tmov %eax,%fs:(%rcx) 3f:\t48 \trex.W Code starting with the faulting instruction =========================================== 0:\t48 3d 01 f0 ff ff \tcmp $0xfffffffffffff001,%rax 6:\t73 01 \tjae 0x9 8:\tc3 \tret 9:\t48 8b 0d 09 8c 0c 00 \tmov 0xc8c09(%rip),%rcx # 0xc8c19 10:\tf7 d8 \tneg %eax 12:\t64 89 01 \tmov %eax,%fs:(%rcx) 15:\t48 \trex.W RSP: 002b:00007ffe2d0ad398 EFLAGS: 00000202 ORIG_RAX: 0000000000000031 RAX: ffffffffffffffda RBX: 00007ffe2d0ad3d0 RCX: 00007f59b934a1e7 RDX: 000000000000001c RSI: 00007ffe2d0ad3d0 RDI: 0000000000000005 RBP: 0000000000000005 R08: 1999999999999999 R09: 0000000000000000 R10: 00007f59b9253298 R11: 000000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53140", "url": "https://ubuntu.com/security/CVE-2024-53140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netlink: terminate outstanding dump on socket close Netlink supports iterative dumping of data. It provides the families the following ops: - start - (optional) kicks off the dumping process - dump - actual dump helper, keeps getting called until it returns 0 - done - (optional) pairs with .start, can be used for cleanup The whole process is asynchronous and the repeated calls to .dump don't actually happen in a tight loop, but rather are triggered in response to recvmsg() on the socket. This gives the user full control over the dump, but also means that the user can close the socket without getting to the end of the dump. To make sure .start is always paired with .done we check if there is an ongoing dump before freeing the socket, and if so call .done. The complication is that sockets can get freed from BH and .done is allowed to sleep. So we use a workqueue to defer the call, when needed. Unfortunately this does not work correctly. What we defer is not the cleanup but rather releasing a reference on the socket. We have no guarantee that we own the last reference, if someone else holds the socket they may release it in BH and we're back to square one. The whole dance, however, appears to be unnecessary. Only the user can interact with dumps, so we can clean up when socket is closed. And close always happens in process context. Some async code may still access the socket after close, queue notification skbs to it etc. but no dumps can start, end or otherwise make progress. Delete the workqueue and flush the dump state directly from the release handler. Note that further cleanup is possible in -next, for instance we now always call .done before releasing the main module reference, so dump doesn't have to take a reference of its own.", "cve_priority": "high", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53098", "url": "https://ubuntu.com/security/CVE-2024-53098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/ufence: Prefetch ufence addr to catch bogus address access_ok() only checks for addr overflow so also try to read the addr to catch invalid addr sent from userspace. (cherry picked from commit 9408c4508483ffc60811e910a93d6425b8e63928)", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53099", "url": "https://ubuntu.com/security/CVE-2024-53099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check validity of link->type in bpf_link_show_fdinfo() If a newly-added link type doesn't invoke BPF_LINK_TYPE(), accessing bpf_link_type_strs[link->type] may result in an out-of-bounds access. To spot such missed invocations early in the future, checking the validity of link->type in bpf_link_show_fdinfo() and emitting a warning when such invocations are missed.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53089", "url": "https://ubuntu.com/security/CVE-2024-53089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: KVM: Mark hrtimer to expire in hard interrupt context Like commit 2c0d278f3293f (\"KVM: LAPIC: Mark hrtimer to expire in hard interrupt context\") and commit 9090825fa9974 (\"KVM: arm/arm64: Let the timer expire in hardirq context on RT\"), On PREEMPT_RT enabled kernels unmarked hrtimers are moved into soft interrupt expiry mode by default. Then the timers are canceled from an preempt-notifier which is invoked with disabled preemption which is not allowed on PREEMPT_RT. The timer callback is short so in could be invoked in hard-IRQ context. So let the timer expire on hard-IRQ context even on -RT. This fix a \"scheduling while atomic\" bug for PREEMPT_RT enabled kernels: BUG: scheduling while atomic: qemu-system-loo/1011/0x00000002 Modules linked in: amdgpu rfkill nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat ns CPU: 1 UID: 0 PID: 1011 Comm: qemu-system-loo Tainted: G W 6.12.0-rc2+ #1774 Tainted: [W]=WARN Hardware name: Loongson Loongson-3A5000-7A1000-1w-CRB/Loongson-LS3A5000-7A1000-1w-CRB, BIOS vUDK2018-LoongArch-V2.0.0-prebeta9 10/21/2022 Stack : ffffffffffffffff 0000000000000000 9000000004e3ea38 9000000116744000 90000001167475a0 0000000000000000 90000001167475a8 9000000005644830 90000000058dc000 90000000058dbff8 9000000116747420 0000000000000001 0000000000000001 6a613fc938313980 000000000790c000 90000001001c1140 00000000000003fe 0000000000000001 000000000000000d 0000000000000003 0000000000000030 00000000000003f3 000000000790c000 9000000116747830 90000000057ef000 0000000000000000 9000000005644830 0000000000000004 0000000000000000 90000000057f4b58 0000000000000001 9000000116747868 900000000451b600 9000000005644830 9000000003a13998 0000000010000020 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d ... Call Trace: [<9000000003a13998>] show_stack+0x38/0x180 [<9000000004e3ea34>] dump_stack_lvl+0x84/0xc0 [<9000000003a71708>] __schedule_bug+0x48/0x60 [<9000000004e45734>] __schedule+0x1114/0x1660 [<9000000004e46040>] schedule_rtlock+0x20/0x60 [<9000000004e4e330>] rtlock_slowlock_locked+0x3f0/0x10a0 [<9000000004e4f038>] rt_spin_lock+0x58/0x80 [<9000000003b02d68>] hrtimer_cancel_wait_running+0x68/0xc0 [<9000000003b02e30>] hrtimer_cancel+0x70/0x80 [] kvm_restore_timer+0x50/0x1a0 [kvm] [] kvm_arch_vcpu_load+0x68/0x2a0 [kvm] [] kvm_sched_in+0x34/0x60 [kvm] [<9000000003a749a0>] finish_task_switch.isra.0+0x140/0x2e0 [<9000000004e44a70>] __schedule+0x450/0x1660 [<9000000004e45cb0>] schedule+0x30/0x180 [] kvm_vcpu_block+0x70/0x120 [kvm] [] kvm_vcpu_halt+0x60/0x3e0 [kvm] [] kvm_handle_gspr+0x3f4/0x4e0 [kvm] [] kvm_handle_exit+0x1c8/0x260 [kvm]", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53090", "url": "https://ubuntu.com/security/CVE-2024-53090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix lock recursion afs_wake_up_async_call() can incur lock recursion. The problem is that it is called from AF_RXRPC whilst holding the ->notify_lock, but it tries to take a ref on the afs_call struct in order to pass it to a work queue - but if the afs_call is already queued, we then have an extraneous ref that must be put... calling afs_put_call() may call back down into AF_RXRPC through rxrpc_kernel_shutdown_call(), however, which might try taking the ->notify_lock again. This case isn't very common, however, so defer it to a workqueue. The oops looks something like: BUG: spinlock recursion on CPU#0, krxrpcio/7001/1646 lock: 0xffff888141399b30, .magic: dead4ead, .owner: krxrpcio/7001/1646, .owner_cpu: 0 CPU: 0 UID: 0 PID: 1646 Comm: krxrpcio/7001 Not tainted 6.12.0-rc2-build3+ #4351 Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014 Call Trace: dump_stack_lvl+0x47/0x70 do_raw_spin_lock+0x3c/0x90 rxrpc_kernel_shutdown_call+0x83/0xb0 afs_put_call+0xd7/0x180 rxrpc_notify_socket+0xa0/0x190 rxrpc_input_split_jumbo+0x198/0x1d0 rxrpc_input_data+0x14b/0x1e0 ? rxrpc_input_call_packet+0xc2/0x1f0 rxrpc_input_call_event+0xad/0x6b0 rxrpc_input_packet_on_conn+0x1e1/0x210 rxrpc_input_packet+0x3f2/0x4d0 rxrpc_io_thread+0x243/0x410 ? __pfx_rxrpc_io_thread+0x10/0x10 kthread+0xcf/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x24/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53101", "url": "https://ubuntu.com/security/CVE-2024-53101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized value issue in from_kuid and from_kgid ocfs2_setattr() uses attr->ia_mode, attr->ia_uid and attr->ia_gid in a trace point even though ATTR_MODE, ATTR_UID and ATTR_GID aren't set. Initialize all fields of newattrs to avoid uninitialized variables, by checking if ATTR_MODE, ATTR_UID, ATTR_GID are initialized, otherwise 0.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53091", "url": "https://ubuntu.com/security/CVE-2024-53091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Add sk_is_inet and IS_ICSK check in tls_sw_has_ctx_tx/rx As the introduction of the support for vsock and unix sockets in sockmap, tls_sw_has_ctx_tx/rx cannot presume the socket passed in must be IS_ICSK. vsock and af_unix sockets have vsock_sock and unix_sock instead of inet_connection_sock. For these sockets, tls_get_ctx may return an invalid pointer and cause page fault in function tls_sw_ctx_rx. BUG: unable to handle page fault for address: 0000000000040030 Workqueue: vsock-loopback vsock_loopback_work RIP: 0010:sk_psock_strp_data_ready+0x23/0x60 Call Trace: ? __die+0x81/0xc3 ? no_context+0x194/0x350 ? do_page_fault+0x30/0x110 ? async_page_fault+0x3e/0x50 ? sk_psock_strp_data_ready+0x23/0x60 virtio_transport_recv_pkt+0x750/0x800 ? update_load_avg+0x7e/0x620 vsock_loopback_work+0xd0/0x100 process_one_work+0x1a7/0x360 worker_thread+0x30/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x112/0x130 ? __kthread_cancel_work+0x40/0x40 ret_from_fork+0x1f/0x40 v2: - Add IS_ICSK check v3: - Update the commits in Fixes", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53092", "url": "https://ubuntu.com/security/CVE-2024-53092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_pci: Fix admin vq cleanup by using correct info pointer vp_modern_avq_cleanup() and vp_del_vqs() clean up admin vq resources by virtio_pci_vq_info pointer. The info pointer of admin vq is stored in vp_dev->admin_vq.info instead of vp_dev->vqs[]. Using the info pointer from vp_dev->vqs[] for admin vq causes a kernel NULL pointer dereference bug. In vp_modern_avq_cleanup() and vp_del_vqs(), get the info pointer from vp_dev->admin_vq.info for admin vq to clean up the resources. Also make info ptr as argument of vp_del_vq() to be symmetric with vp_setup_vq(). vp_reset calls vp_modern_avq_cleanup, and causes the Call Trace: ================================================================== BUG: kernel NULL pointer dereference, address:0000000000000000 ... CPU: 49 UID: 0 PID: 4439 Comm: modprobe Not tainted 6.11.0-rc5 #1 RIP: 0010:vp_reset+0x57/0x90 [virtio_pci] Call Trace: ... ? vp_reset+0x57/0x90 [virtio_pci] ? vp_reset+0x38/0x90 [virtio_pci] virtio_reset_device+0x1d/0x30 remove_vq_common+0x1c/0x1a0 [virtio_net] virtnet_remove+0xa1/0xc0 [virtio_net] virtio_dev_remove+0x46/0xa0 ... virtio_pci_driver_exit+0x14/0x810 [virtio_pci] ==================================================================", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53102", "url": "https://ubuntu.com/security/CVE-2024-53102", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53093", "url": "https://ubuntu.com/security/CVE-2024-53093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: defer partition scanning We need to suppress the partition scan from occuring within the controller's scan_work context. If a path error occurs here, the IO will wait until a path becomes available or all paths are torn down, but that action also occurs within scan_work, so it would deadlock. Defer the partion scan to a different context that does not block scan_work.", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53094", "url": "https://ubuntu.com/security/CVE-2024-53094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Add sendpage_ok() check to disable MSG_SPLICE_PAGES While running ISER over SIW, the initiator machine encounters a warning from skb_splice_from_iter() indicating that a slab page is being used in send_page. To address this, it is better to add a sendpage_ok() check within the driver itself, and if it returns 0, then MSG_SPLICE_PAGES flag should be disabled before entering the network stack. A similar issue has been discussed for NVMe in this thread: https://lore.kernel.org/all/20240530142417.146696-1-ofir.gal@volumez.com/ WARNING: CPU: 0 PID: 5342 at net/core/skbuff.c:7140 skb_splice_from_iter+0x173/0x320 Call Trace: tcp_sendmsg_locked+0x368/0xe40 siw_tx_hdt+0x695/0xa40 [siw] siw_qp_sq_process+0x102/0xb00 [siw] siw_sq_resume+0x39/0x110 [siw] siw_run_sq+0x74/0x160 [siw] kthread+0xd2/0x100 ret_from_fork+0x34/0x40 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53100", "url": "https://ubuntu.com/security/CVE-2024-53100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: tcp: avoid race between queue_lock lock and destroy Commit 76d54bf20cdc (\"nvme-tcp: don't access released socket during error recovery\") added a mutex_lock() call for the queue->queue_lock in nvme_tcp_get_address(). However, the mutex_lock() races with mutex_destroy() in nvme_tcp_free_queue(), and causes the WARN below. DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: CPU: 3 PID: 34077 at kernel/locking/mutex.c:587 __mutex_lock+0xcf0/0x1220 Modules linked in: nvmet_tcp nvmet nvme_tcp nvme_fabrics iw_cm ib_cm ib_core pktcdvd nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables qrtr sunrpc ppdev 9pnet_virtio 9pnet pcspkr netfs parport_pc parport e1000 i2c_piix4 i2c_smbus loop fuse nfnetlink zram bochs drm_vram_helper drm_ttm_helper ttm drm_kms_helper xfs drm sym53c8xx floppy nvme scsi_transport_spi nvme_core nvme_auth serio_raw ata_generic pata_acpi dm_multipath qemu_fw_cfg [last unloaded: ib_uverbs] CPU: 3 UID: 0 PID: 34077 Comm: udisksd Not tainted 6.11.0-rc7 #319 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:__mutex_lock+0xcf0/0x1220 Code: 08 84 d2 0f 85 c8 04 00 00 8b 15 ef b6 c8 01 85 d2 0f 85 78 f4 ff ff 48 c7 c6 20 93 ee af 48 c7 c7 60 91 ee af e8 f0 a7 6d fd <0f> 0b e9 5e f4 ff ff 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 RSP: 0018:ffff88811305f760 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff88812c652058 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000001 RBP: ffff88811305f8b0 R08: 0000000000000001 R09: ffffed1075c36341 R10: ffff8883ae1b1a0b R11: 0000000000010498 R12: 0000000000000000 R13: 0000000000000000 R14: dffffc0000000000 R15: ffff88812c652058 FS: 00007f9713ae4980(0000) GS:ffff8883ae180000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcd78483c7c CR3: 0000000122c38000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn.cold+0x5b/0x1af ? __mutex_lock+0xcf0/0x1220 ? report_bug+0x1ec/0x390 ? handle_bug+0x3c/0x80 ? exc_invalid_op+0x13/0x40 ? asm_exc_invalid_op+0x16/0x20 ? __mutex_lock+0xcf0/0x1220 ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] ? __pfx___mutex_lock+0x10/0x10 ? __lock_acquire+0xd6a/0x59e0 ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] ? __pfx_nvme_tcp_get_address+0x10/0x10 [nvme_tcp] nvme_sysfs_show_address+0x81/0xc0 [nvme_core] dev_attr_show+0x42/0x80 ? __asan_memset+0x1f/0x40 sysfs_kf_seq_show+0x1f0/0x370 seq_read_iter+0x2cb/0x1130 ? rw_verify_area+0x3b1/0x590 ? __mutex_lock+0x433/0x1220 vfs_read+0x6a6/0xa20 ? lockdep_hardirqs_on+0x78/0x100 ? __pfx_vfs_read+0x10/0x10 ksys_read+0xf7/0x1d0 ? __pfx_ksys_read+0x10/0x10 ? __x64_sys_openat+0x105/0x1d0 do_syscall_64+0x93/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? __pfx_ksys_read+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? do_syscall_64+0x9f/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f9713f55cfa Code: 55 48 89 e5 48 83 ec 20 48 89 55 e8 48 89 75 f0 89 7d f8 e8 e8 74 f8 ff 48 8b 55 e8 48 8b 75 f0 4 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53095", "url": "https://ubuntu.com/security/CVE-2024-53095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix use-after-free of network namespace. Recently, we got a customer report that CIFS triggers oops while reconnecting to a server. [0] The workload runs on Kubernetes, and some pods mount CIFS servers in non-root network namespaces. The problem rarely happened, but it was always while the pod was dying. The root cause is wrong reference counting for network namespace. CIFS uses kernel sockets, which do not hold refcnt of the netns that the socket belongs to. That means CIFS must ensure the socket is always freed before its netns; otherwise, use-after-free happens. The repro steps are roughly: 1. mount CIFS in a non-root netns 2. drop packets from the netns 3. destroy the netns 4. unmount CIFS We can reproduce the issue quickly with the script [1] below and see the splat [2] if CONFIG_NET_NS_REFCNT_TRACKER is enabled. When the socket is TCP, it is hard to guarantee the netns lifetime without holding refcnt due to async timers. Let's hold netns refcnt for each socket as done for SMC in commit 9744d2bf1976 (\"smc: Fix use-after-free in tcp_write_timer_handler().\"). Note that we need to move put_net() from cifs_put_tcp_session() to clean_demultiplex_info(); otherwise, __sock_create() still could touch a freed netns while cifsd tries to reconnect from cifs_demultiplex_thread(). Also, maybe_get_net() cannot be put just before __sock_create() because the code is not under RCU and there is a small chance that the same address happened to be reallocated to another netns. [0]: CIFS: VFS: \\\\XXXXXXXXXXX has not responded in 15 seconds. Reconnecting... CIFS: Serverclose failed 4 times, giving up Unable to handle kernel paging request at virtual address 14de99e461f84a07 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 CM = 0, WnR = 0 [14de99e461f84a07] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: cls_bpf sch_ingress nls_utf8 cifs cifs_arc4 cifs_md4 dns_resolver tcp_diag inet_diag veth xt_state xt_connmark nf_conntrack_netlink xt_nat xt_statistic xt_MASQUERADE xt_mark xt_addrtype ipt_REJECT nf_reject_ipv4 nft_chain_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment nft_compat nf_tables nfnetlink overlay nls_ascii nls_cp437 sunrpc vfat fat aes_ce_blk aes_ce_cipher ghash_ce sm4_ce_cipher sm4 sm3_ce sm3 sha3_ce sha512_ce sha512_arm64 sha1_ce ena button sch_fq_codel loop fuse configfs dmi_sysfs sha2_ce sha256_arm64 dm_mirror dm_region_hash dm_log dm_mod dax efivarfs CPU: 5 PID: 2690970 Comm: cifsd Not tainted 6.1.103-109.184.amzn2023.aarch64 #1 Hardware name: Amazon EC2 r7g.4xlarge/, BIOS 1.0 11/1/2018 pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : fib_rules_lookup+0x44/0x238 lr : __fib_lookup+0x64/0xbc sp : ffff8000265db790 x29: ffff8000265db790 x28: 0000000000000000 x27: 000000000000bd01 x26: 0000000000000000 x25: ffff000b4baf8000 x24: ffff00047b5e4580 x23: ffff8000265db7e0 x22: 0000000000000000 x21: ffff00047b5e4500 x20: ffff0010e3f694f8 x19: 14de99e461f849f7 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 3f92800abd010002 x11: 0000000000000001 x10: ffff0010e3f69420 x9 : ffff800008a6f294 x8 : 0000000000000000 x7 : 0000000000000006 x6 : 0000000000000000 x5 : 0000000000000001 x4 : ffff001924354280 x3 : ffff8000265db7e0 x2 : 0000000000000000 x1 : ffff0010e3f694f8 x0 : ffff00047b5e4500 Call trace: fib_rules_lookup+0x44/0x238 __fib_lookup+0x64/0xbc ip_route_output_key_hash_rcu+0x2c4/0x398 ip_route_output_key_hash+0x60/0x8c tcp_v4_connect+0x290/0x488 __inet_stream_connect+0x108/0x3d0 inet_stream_connect+0x50/0x78 kernel_connect+0x6c/0xac generic_ip_conne ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-50265", "url": "https://ubuntu.com/security/CVE-2024-50265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove() Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove(): [ 57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12 [ 57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry [ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004 [...] [ 57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [...] [ 57.331328] Call Trace: [ 57.331477] [...] [ 57.333511] ? do_user_addr_fault+0x3e5/0x740 [ 57.333778] ? exc_page_fault+0x70/0x170 [ 57.334016] ? asm_exc_page_fault+0x2b/0x30 [ 57.334263] ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10 [ 57.334596] ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [ 57.334913] ocfs2_xa_remove_entry+0x23/0xc0 [ 57.335164] ocfs2_xa_set+0x704/0xcf0 [ 57.335381] ? _raw_spin_unlock+0x1a/0x40 [ 57.335620] ? ocfs2_inode_cache_unlock+0x16/0x20 [ 57.335915] ? trace_preempt_on+0x1e/0x70 [ 57.336153] ? start_this_handle+0x16c/0x500 [ 57.336410] ? preempt_count_sub+0x50/0x80 [ 57.336656] ? _raw_read_unlock+0x20/0x40 [ 57.336906] ? start_this_handle+0x16c/0x500 [ 57.337162] ocfs2_xattr_block_set+0xa6/0x1e0 [ 57.337424] __ocfs2_xattr_set_handle+0x1fd/0x5d0 [ 57.337706] ? ocfs2_start_trans+0x13d/0x290 [ 57.337971] ocfs2_xattr_set+0xb13/0xfb0 [ 57.338207] ? dput+0x46/0x1c0 [ 57.338393] ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338665] ? ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338948] __vfs_removexattr+0x92/0xc0 [ 57.339182] __vfs_removexattr_locked+0xd5/0x190 [ 57.339456] ? preempt_count_sub+0x50/0x80 [ 57.339705] vfs_removexattr+0x5f/0x100 [...] Reproducer uses faultinject facility to fail ocfs2_xa_remove() -> ocfs2_xa_value_truncate() with -ENOMEM. In this case the comment mentions that we can return 0 if ocfs2_xa_cleanup_value_truncate() is going to wipe the entry anyway. But the following 'rc' check is wrong and execution flow do 'ocfs2_xa_remove_entry(loc);' twice: * 1st: in ocfs2_xa_cleanup_value_truncate(); * 2nd: returning back to ocfs2_xa_remove() instead of going to 'out'. Fix this by skipping the 2nd removal of the same entry and making syzkaller repro happy.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50266", "url": "https://ubuntu.com/security/CVE-2024-50266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: qcom: videocc-sm8350: use HW_CTRL_TRIGGER for vcodec GDSCs A recent change in the venus driver results in a stuck clock on the Lenovo ThinkPad X13s, for example, when streaming video in firefox: \tvideo_cc_mvs0_clk status stuck at 'off' \tWARNING: CPU: 6 PID: 2885 at drivers/clk/qcom/clk-branch.c:87 clk_branch_wait+0x144/0x15c \t... \tCall trace: \t clk_branch_wait+0x144/0x15c \t clk_branch2_enable+0x30/0x40 \t clk_core_enable+0xd8/0x29c \t clk_enable+0x2c/0x4c \t vcodec_clks_enable.isra.0+0x94/0xd8 [venus_core] \t coreid_power_v4+0x464/0x628 [venus_core] \t vdec_start_streaming+0xc4/0x510 [venus_dec] \t vb2_start_streaming+0x6c/0x180 [videobuf2_common] \t vb2_core_streamon+0x120/0x1dc [videobuf2_common] \t vb2_streamon+0x1c/0x6c [videobuf2_v4l2] \t v4l2_m2m_ioctl_streamon+0x30/0x80 [v4l2_mem2mem] \t v4l_streamon+0x24/0x30 [videodev] using the out-of-tree sm8350/sc8280xp venus support. [1] Update also the sm8350/sc8280xp GDSC definitions so that the hw control mode can be changed at runtime as the venus driver now requires.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50267", "url": "https://ubuntu.com/security/CVE-2024-50267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: fix use after free in debug printk The \"dev_dbg(&urb->dev->dev, ...\" which happens after usb_free_urb(urb) is a use after free of the \"urb\" pointer. Store the \"dev\" pointer at the start of the function to avoid this issue.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50268", "url": "https://ubuntu.com/security/CVE-2024-50268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: fix potential out of bounds in ucsi_ccg_update_set_new_cam_cmd() The \"*cmd\" variable can be controlled by the user via debugfs. That means \"new_cam\" can be as high as 255 while the size of the uc->updated[] array is UCSI_MAX_ALTMODES (30). The call tree is: ucsi_cmd() // val comes from simple_attr_write_xsigned() -> ucsi_send_command() -> ucsi_send_command_common() -> ucsi_run_command() // calls ucsi->ops->sync_control() -> ucsi_ccg_sync_control()", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53083", "url": "https://ubuntu.com/security/CVE-2024-53083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: qcom-pmic: init value of hdr_len/txbuf_len earlier If the read of USB_PDPHY_RX_ACKNOWLEDGE_REG failed, then hdr_len and txbuf_len are uninitialized. This commit stops to print uninitialized value and misleading/false data.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50269", "url": "https://ubuntu.com/security/CVE-2024-50269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: musb: sunxi: Fix accessing an released usb phy Commit 6ed05c68cbca (\"usb: musb: sunxi: Explicitly release USB PHY on exit\") will cause that usb phy @glue->xceiv is accessed after released. 1) register platform driver @sunxi_musb_driver // get the usb phy @glue->xceiv sunxi_musb_probe() -> devm_usb_get_phy(). 2) register and unregister platform driver @musb_driver musb_probe() -> sunxi_musb_init() use the phy here //the phy is released here musb_remove() -> sunxi_musb_exit() -> devm_usb_put_phy() 3) register @musb_driver again musb_probe() -> sunxi_musb_init() use the phy here but the phy has been released at 2). ... Fixed by reverting the commit, namely, removing devm_usb_put_phy() from sunxi_musb_exit().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53079", "url": "https://ubuntu.com/security/CVE-2024-53079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/thp: fix deferred split unqueue naming and locking Recent changes are putting more pressure on THP deferred split queues: under load revealing long-standing races, causing list_del corruptions, \"Bad page state\"s and worse (I keep BUGs in both of those, so usually don't get to see how badly they end up without). The relevant recent changes being 6.8's mTHP, 6.10's mTHP swapout, and 6.12's mTHP swapin, improved swap allocation, and underused THP splitting. Before fixing locking: rename misleading folio_undo_large_rmappable(), which does not undo large_rmappable, to folio_unqueue_deferred_split(), which is what it does. But that and its out-of-line __callee are mm internals of very limited usability: add comment and WARN_ON_ONCEs to check usage; and return a bool to say if a deferred split was unqueued, which can then be used in WARN_ON_ONCEs around safety checks (sparing callers the arcane conditionals in __folio_unqueue_deferred_split()). Just omit the folio_unqueue_deferred_split() from free_unref_folios(), all of whose callers now call it beforehand (and if any forget then bad_page() will tell) - except for its caller put_pages_list(), which itself no longer has any callers (and will be deleted separately). Swapout: mem_cgroup_swapout() has been resetting folio->memcg_data 0 without checking and unqueueing a THP folio from deferred split list; which is unfortunate, since the split_queue_lock depends on the memcg (when memcg is enabled); so swapout has been unqueueing such THPs later, when freeing the folio, using the pgdat's lock instead: potentially corrupting the memcg's list. __remove_mapping() has frozen refcount to 0 here, so no problem with calling folio_unqueue_deferred_split() before resetting memcg_data. That goes back to 5.4 commit 87eaceb3faa5 (\"mm: thp: make deferred split shrinker memcg aware\"): which included a check on swapcache before adding to deferred queue, but no check on deferred queue before adding THP to swapcache. That worked fine with the usual sequence of events in reclaim (though there were a couple of rare ways in which a THP on deferred queue could have been swapped out), but 6.12 commit dafff3f4c850 (\"mm: split underused THPs\") avoids splitting underused THPs in reclaim, which makes swapcache THPs on deferred queue commonplace. Keep the check on swapcache before adding to deferred queue? Yes: it is no longer essential, but preserves the existing behaviour, and is likely to be a worthwhile optimization (vmstat showed much more traffic on the queue under swapping load if the check was removed); update its comment. Memcg-v1 move (deprecated): mem_cgroup_move_account() has been changing folio->memcg_data without checking and unqueueing a THP folio from the deferred list, sometimes corrupting \"from\" memcg's list, like swapout. Refcount is non-zero here, so folio_unqueue_deferred_split() can only be used in a WARN_ON_ONCE to validate the fix, which must be done earlier: mem_cgroup_move_charge_pte_range() first try to split the THP (splitting of course unqueues), or skip it if that fails. Not ideal, but moving charge has been requested, and khugepaged should repair the THP later: nobody wants new custom unqueueing code just for this deprecated case. The 87eaceb3faa5 commit did have the code to move from one deferred list to another (but was not conscious of its unsafety while refcount non-0); but that was removed by 5.6 commit fac0516b5534 (\"mm: thp: don't need care deferred split queue in memcg charge move path\"), which argued that the existence of a PMD mapping guarantees that the THP cannot be on a deferred list. As above, false in rare cases, and now commonly false. Backport to 6.11 should be straightforward. Earlier backports must take care that other _deferred_list fixes and dependencies are included. There is not a strong case for backports, but they can fix cornercases.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50270", "url": "https://ubuntu.com/security/CVE-2024-50270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: avoid overflow in damon_feed_loop_next_input() damon_feed_loop_next_input() is inefficient and fragile to overflows. Specifically, 'score_goal_diff_bp' calculation can overflow when 'score' is high. The calculation is actually unnecessary at all because 'goal' is a constant of value 10,000. Calculation of 'compensation' is again fragile to overflow. Final calculation of return value for under-achiving case is again fragile to overflow when the current score is under-achieving the target. Add two corner cases handling at the beginning of the function to make the body easier to read, and rewrite the body of the function to avoid overflows and the unnecessary bp value calcuation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50271", "url": "https://ubuntu.com/security/CVE-2024-50271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: signal: restore the override_rlimit logic Prior to commit d64696905554 (\"Reimplement RLIMIT_SIGPENDING on top of ucounts\") UCOUNT_RLIMIT_SIGPENDING rlimit was not enforced for a class of signals. However now it's enforced unconditionally, even if override_rlimit is set. This behavior change caused production issues. For example, if the limit is reached and a process receives a SIGSEGV signal, sigqueue_alloc fails to allocate the necessary resources for the signal delivery, preventing the signal from being delivered with siginfo. This prevents the process from correctly identifying the fault address and handling the error. From the user-space perspective, applications are unaware that the limit has been reached and that the siginfo is effectively 'corrupted'. This can lead to unpredictable behavior and crashes, as we observed with java applications. Fix this by passing override_rlimit into inc_rlimit_get_ucounts() and skip the comparison to max there if override_rlimit is set. This effectively restores the old behavior.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50272", "url": "https://ubuntu.com/security/CVE-2024-50272", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: filemap: Fix bounds checking in filemap_read() If the caller supplies an iocb->ki_pos value that is close to the filesystem upper limit, and an iterator with a count that causes us to overflow that limit, then filemap_read() enters an infinite loop. This behaviour was discovered when testing xfstests generic/525 with the \"localio\" optimisation for loopback NFS mounts.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53104", "url": "https://ubuntu.com/security/CVE-2024-53104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_parse_format This can lead to out of bounds writes since frames of this type were not taken into account when calculating the size of the frames buffer in uvc_parse_streaming.", "cve_priority": "high", "cve_public_date": "2024-12-02 08:15:00 UTC" }, { "cve": "CVE-2024-50273", "url": "https://ubuntu.com/security/CVE-2024-50273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reinitialize delayed ref list after deleting it from the list At insert_delayed_ref() if we need to update the action of an existing ref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head's ref_add_list using list_del(), which leaves the ref's add_list member not reinitialized, as list_del() sets the next and prev members of the list to LIST_POISON1 and LIST_POISON2, respectively. If later we end up calling drop_delayed_ref() against the ref, which can happen during merging or when destroying delayed refs due to a transaction abort, we can trigger a crash since at drop_delayed_ref() we call list_empty() against the ref's add_list, which returns false since the list was not reinitialized after the list_del() and as a consequence we call list_del() again at drop_delayed_ref(). This results in an invalid list access since the next and prev members are set to poison pointers, resulting in a splat if CONFIG_LIST_HARDENED and CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences otherwise. So fix this by deleting from the list with list_del_init() instead.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53064", "url": "https://ubuntu.com/security/CVE-2024-53064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix idpf_vc_core_init error path In an event where the platform running the device control plane is rebooted, reset is detected on the driver. It releases all the resources and waits for the reset to complete. Once the reset is done, it tries to build the resources back. At this time if the device control plane is not yet started, then the driver timeouts on the virtchnl message and retries to establish the mailbox again. In the retry flow, mailbox is deinitialized but the mailbox workqueue is still alive and polling for the mailbox message. This results in accessing the released control queue leading to null-ptr-deref. Fix it by unrolling the work queue cancellation and mailbox deinitialization in the reverse order which they got initialized.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50274", "url": "https://ubuntu.com/security/CVE-2024-50274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: avoid vport access in idpf_get_link_ksettings When the device control plane is removed or the platform running device control plane is rebooted, a reset is detected on the driver. On driver reset, it releases the resources and waits for the reset to complete. If the reset fails, it takes the error path and releases the vport lock. At this time if the monitoring tools tries to access link settings, it call traces for accessing released vport pointer. To avoid it, move link_speed_mbps to netdev_priv structure which removes the dependency on vport pointer and the vport lock in idpf_get_link_ksettings. Also use netif_carrier_ok() to check the link status and adjust the offsetof to use link_up instead of link_speed_mbps.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53065", "url": "https://ubuntu.com/security/CVE-2024-53065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/slab: fix warning caused by duplicate kmem_cache creation in kmem_buckets_create Commit b035f5a6d852 (\"mm: slab: reduce the kmalloc() minimum alignment if DMA bouncing possible\") reduced ARCH_KMALLOC_MINALIGN to 8 on arm64. However, with KASAN_HW_TAGS enabled, arch_slab_minalign() becomes 16. This causes kmalloc_caches[*][8] to be aliased to kmalloc_caches[*][16], resulting in kmem_buckets_create() attempting to create a kmem_cache for size 16 twice. This duplication triggers warnings on boot: [ 2.325108] ------------[ cut here ]------------ [ 2.325135] kmem_cache of name 'memdup_user-16' already exists [ 2.325783] WARNING: CPU: 0 PID: 1 at mm/slab_common.c:107 __kmem_cache_create_args+0xb8/0x3b0 [ 2.327957] Modules linked in: [ 2.328550] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5mm-unstable-arm64+ #12 [ 2.328683] Hardware name: QEMU QEMU Virtual Machine, BIOS 2024.02-2 03/11/2024 [ 2.328790] pstate: 61000009 (nZCv daif -PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 2.328911] pc : __kmem_cache_create_args+0xb8/0x3b0 [ 2.328930] lr : __kmem_cache_create_args+0xb8/0x3b0 [ 2.328942] sp : ffff800083d6fc50 [ 2.328961] x29: ffff800083d6fc50 x28: f2ff0000c1674410 x27: ffff8000820b0598 [ 2.329061] x26: 000000007fffffff x25: 0000000000000010 x24: 0000000000002000 [ 2.329101] x23: ffff800083d6fce8 x22: ffff8000832222e8 x21: ffff800083222388 [ 2.329118] x20: f2ff0000c1674410 x19: f5ff0000c16364c0 x18: ffff800083d80030 [ 2.329135] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 2.329152] x14: 0000000000000000 x13: 0a73747369786520 x12: 79646165726c6120 [ 2.329169] x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : 0000000000000000 [ 2.329194] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 [ 2.329210] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 2.329226] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 2.329291] Call trace: [ 2.329407] __kmem_cache_create_args+0xb8/0x3b0 [ 2.329499] kmem_buckets_create+0xfc/0x320 [ 2.329526] init_user_buckets+0x34/0x78 [ 2.329540] do_one_initcall+0x64/0x3c8 [ 2.329550] kernel_init_freeable+0x26c/0x578 [ 2.329562] kernel_init+0x3c/0x258 [ 2.329574] ret_from_fork+0x10/0x20 [ 2.329698] ---[ end trace 0000000000000000 ]--- [ 2.403704] ------------[ cut here ]------------ [ 2.404716] kmem_cache of name 'msg_msg-16' already exists [ 2.404801] WARNING: CPU: 2 PID: 1 at mm/slab_common.c:107 __kmem_cache_create_args+0xb8/0x3b0 [ 2.404842] Modules linked in: [ 2.404971] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.12.0-rc5mm-unstable-arm64+ #12 [ 2.405026] Tainted: [W]=WARN [ 2.405043] Hardware name: QEMU QEMU Virtual Machine, BIOS 2024.02-2 03/11/2024 [ 2.405057] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2.405079] pc : __kmem_cache_create_args+0xb8/0x3b0 [ 2.405100] lr : __kmem_cache_create_args+0xb8/0x3b0 [ 2.405111] sp : ffff800083d6fc50 [ 2.405115] x29: ffff800083d6fc50 x28: fbff0000c1674410 x27: ffff8000820b0598 [ 2.405135] x26: 000000000000ffd0 x25: 0000000000000010 x24: 0000000000006000 [ 2.405153] x23: ffff800083d6fce8 x22: ffff8000832222e8 x21: ffff800083222388 [ 2.405169] x20: fbff0000c1674410 x19: fdff0000c163d6c0 x18: ffff800083d80030 [ 2.405185] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 2.405201] x14: 0000000000000000 x13: 0a73747369786520 x12: 79646165726c6120 [ 2.405217] x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : 0000000000000000 [ 2.405233] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 [ 2.405248] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 2.405271] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 2.405287] Call trace: [ 2 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50275", "url": "https://ubuntu.com/security/CVE-2024-50275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64/sve: Discard stale CPU state when handling SVE traps The logic for handling SVE traps manipulates saved FPSIMD/SVE state incorrectly, and a race with preemption can result in a task having TIF_SVE set and TIF_FOREIGN_FPSTATE clear even though the live CPU state is stale (e.g. with SVE traps enabled). This has been observed to result in warnings from do_sve_acc() where SVE traps are not expected while TIF_SVE is set: | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* SVE access shouldn't have trapped */ Warnings of this form have been reported intermittently, e.g. https://lore.kernel.org/linux-arm-kernel/CA+G9fYtEGe_DhY2Ms7+L7NKsLYUomGsgqpdBj+QwDLeSg=JhGg@mail.gmail.com/ https://lore.kernel.org/linux-arm-kernel/000000000000511e9a060ce5a45c@google.com/ The race can occur when the SVE trap handler is preempted before and after manipulating the saved FPSIMD/SVE state, starting and ending on the same CPU, e.g. | void do_sve_acc(unsigned long esr, struct pt_regs *regs) | { | // Trap on CPU 0 with TIF_SVE clear, SVE 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(); | | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* SVE access shouldn't have trapped */ | | sve_init_regs() { | if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) { | ... | } else { | fpsimd_to_sve(current); | current->thread.fp_type = FP_STATE_SVE; | } | } | | 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 SVE 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.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50276", "url": "https://ubuntu.com/security/CVE-2024-50276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: vertexcom: mse102x: Fix possible double free of TX skb The scope of the TX skb is wider than just mse102x_tx_frame_spi(), so in case the TX skb room needs to be expanded, we should free the the temporary skb instead of the original skb. Otherwise the original TX skb pointer would be freed again in mse102x_tx_work(), which leads to crashes: Internal error: Oops: 0000000096000004 [#2] PREEMPT SMP CPU: 0 PID: 712 Comm: kworker/0:1 Tainted: G D 6.6.23 Hardware name: chargebyte Charge SOM DC-ONE (DT) Workqueue: events mse102x_tx_work [mse102x] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_release_data+0xb8/0x1d8 lr : skb_release_data+0x1ac/0x1d8 sp : ffff8000819a3cc0 x29: ffff8000819a3cc0 x28: ffff0000046daa60 x27: ffff0000057f2dc0 x26: ffff000005386c00 x25: 0000000000000002 x24: 00000000ffffffff x23: 0000000000000000 x22: 0000000000000001 x21: ffff0000057f2e50 x20: 0000000000000006 x19: 0000000000000000 x18: ffff00003fdacfcc x17: e69ad452d0c49def x16: 84a005feff870102 x15: 0000000000000000 x14: 000000000000024a x13: 0000000000000002 x12: 0000000000000000 x11: 0000000000000400 x10: 0000000000000930 x9 : ffff00003fd913e8 x8 : fffffc00001bc008 x7 : 0000000000000000 x6 : 0000000000000008 x5 : ffff00003fd91340 x4 : 0000000000000000 x3 : 0000000000000009 x2 : 00000000fffffffe x1 : 0000000000000000 x0 : 0000000000000000 Call trace: skb_release_data+0xb8/0x1d8 kfree_skb_reason+0x48/0xb0 mse102x_tx_work+0x164/0x35c [mse102x] process_one_work+0x138/0x260 worker_thread+0x32c/0x438 kthread+0x118/0x11c ret_from_fork+0x10/0x20 Code: aa1303e0 97fffab6 72001c1f 54000141 (f9400660)", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53066", "url": "https://ubuntu.com/security/CVE-2024-53066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfs: Fix KMSAN warning in decode_getfattr_attrs() Fix the following KMSAN warning: CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G B Tainted: [B]=BAD_PAGE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) ===================================================== ===================================================== BUG: KMSAN: uninit-value in decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_generic+0x806/0xb00 nfs4_xdr_dec_getattr+0x1de/0x240 rpcauth_unwrap_resp_decode+0xab/0x100 rpcauth_unwrap_resp+0x95/0xc0 call_decode+0x4ff/0xb50 __rpc_execute+0x57b/0x19d0 rpc_execute+0x368/0x5e0 rpc_run_task+0xcfe/0xee0 nfs4_proc_getattr+0x5b5/0x990 __nfs_revalidate_inode+0x477/0xd00 nfs_access_get_cached+0x1021/0x1cc0 nfs_do_access+0x9f/0xae0 nfs_permission+0x1e4/0x8c0 inode_permission+0x356/0x6c0 link_path_walk+0x958/0x1330 path_lookupat+0xce/0x6b0 filename_lookup+0x23e/0x770 vfs_statx+0xe7/0x970 vfs_fstatat+0x1f2/0x2c0 __se_sys_newfstatat+0x67/0x880 __x64_sys_newfstatat+0xbd/0x120 x64_sys_call+0x1826/0x3cf0 do_syscall_64+0xd0/0x1b0 entry_SYSCALL_64_after_hwframe+0x77/0x7f The KMSAN warning is triggered in decode_getfattr_attrs(), when calling decode_attr_mdsthreshold(). It appears that fattr->mdsthreshold is not initialized. Fix the issue by initializing fattr->mdsthreshold to NULL in nfs_fattr_init().", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53067", "url": "https://ubuntu.com/security/CVE-2024-53067", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Start the RTC update work later The RTC update work involves runtime resuming the UFS controller. Hence, only start the RTC update work after runtime power management in the UFS driver has been fully initialized. This patch fixes the following kernel crash: Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP Workqueue: events ufshcd_rtc_work Call trace: _raw_spin_lock_irqsave+0x34/0x8c (P) pm_runtime_get_if_active+0x24/0x9c (L) pm_runtime_get_if_active+0x24/0x9c ufshcd_rtc_work+0x138/0x1b4 process_one_work+0x148/0x288 worker_thread+0x2cc/0x3d4 kthread+0x110/0x114 ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50277", "url": "https://ubuntu.com/security/CVE-2024-50277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: fix a crash if blk_alloc_disk fails If blk_alloc_disk fails, the variable md->disk is set to an error value. cleanup_mapped_device will see that md->disk is non-NULL and it will attempt to access it, causing a crash on this statement \"md->disk->private_data = NULL;\".", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50278", "url": "https://ubuntu.com/security/CVE-2024-50278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix potential out-of-bounds access on the first resume Out-of-bounds access occurs if the fast device is expanded unexpectedly before the first-time resume of the cache table. This happens because expanding the fast device requires reloading the cache table for cache_create to allocate new in-core data structures that fit the new size, and the check in cache_preresume is not performed during the first resume, leading to the issue. Reproduce steps: 1. prepare component devices: 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\" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct 2. load a cache table of 512 cache blocks, and deliberately expand the fast device before resuming the cache, making the in-core data structures inadequate. dmsetup create cache --notable dmsetup reload cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" dmsetup reload cdata --table \"0 131072 linear /dev/sdc 8192\" dmsetup resume cdata dmsetup resume cache 3. suspend the cache to write out the in-core dirty bitset and hint array, leading to out-of-bounds access to the dirty bitset at offset 0x40: dmsetup suspend cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80 Read of size 8 at addr ffffc90000085040 by task dmsetup/90 (...snip...) The buggy address belongs to the virtual mapping at [ffffc90000085000, ffffc90000087000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by checking the size change on the first resume.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50279", "url": "https://ubuntu.com/security/CVE-2024-50279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix out-of-bounds access to the dirty bitset when resizing dm-cache checks the dirty bits of the cache blocks to be dropped when shrinking the fast device, but an index bug in bitset iteration causes out-of-bounds access. Reproduce steps: 1. create a cache device of 1024 cache blocks (128 bytes dirty bitset) dmsetup create cmeta --table \"0 8192 linear /dev/sdc 0\" dmsetup create cdata --table \"0 131072 linear /dev/sdc 8192\" dmsetup create corig --table \"0 524288 linear /dev/sdc 262144\" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" 2. shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80) dmsetup suspend cache dmsetup reload cdata --table \"0 65536 linear /dev/sdc 8192\" dmsetup resume cdata dmsetup resume cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131 (...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by making the index post-incremented.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50280", "url": "https://ubuntu.com/security/CVE-2024-50280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix flushing uninitialized delayed_work on cache_ctr error An unexpected WARN_ON from flush_work() may occur when cache creation fails, caused by destroying the uninitialized delayed_work waker in the error path of cache_create(). For example, the warning appears on the superblock checksum error. Reproduce steps: 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\" dd if=/dev/urandom of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" Kernel logs: (snip) WARNING: CPU: 0 PID: 84 at kernel/workqueue.c:4178 __flush_work+0x5d4/0x890 Fix by pulling out the cancel_delayed_work_sync() from the constructor's error path. This patch doesn't affect the use-after-free fix for concurrent dm_resume and dm_destroy (commit 6a459d8edbdb (\"dm cache: Fix UAF in destroy()\")) as cache_dtr is not changed.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50281", "url": "https://ubuntu.com/security/CVE-2024-50281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: trusted: dcp: fix NULL dereference in AEAD crypto operation When sealing or unsealing a key blob we currently do not wait for the AEAD cipher operation to finish and simply return after submitting the request. If there is some load on the system we can exit before the cipher operation is done and the buffer we read from/write to is already removed from the stack. This will e.g. result in NULL pointer dereference errors in the DCP driver during blob creation. Fix this by waiting for the AEAD cipher operation to finish before resuming the seal and unseal calls.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50282", "url": "https://ubuntu.com/security/CVE-2024-50282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read() Avoid a possible buffer overflow if size is larger than 4K. (cherry picked from commit f5d873f5825b40d886d03bd2aede91d4cf002434)", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53071", "url": "https://ubuntu.com/security/CVE-2024-53071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Be stricter about IO mapping flags The current panthor_device_mmap_io() implementation has two issues: 1. For mapping DRM_PANTHOR_USER_FLUSH_ID_MMIO_OFFSET, panthor_device_mmap_io() bails if VM_WRITE is set, but does not clear VM_MAYWRITE. That means userspace can use mprotect() to make the mapping writable later on. This is a classic Linux driver gotcha. I don't think this actually has any impact in practice: When the GPU is powered, writes to the FLUSH_ID seem to be ignored; and when the GPU is not powered, the dummy_latest_flush page provided by the driver is deliberately designed to not do any flushes, so the only thing writing to the dummy_latest_flush could achieve would be to make *more* flushes happen. 2. panthor_device_mmap_io() does not block MAP_PRIVATE mappings (which are mappings without the VM_SHARED flag). MAP_PRIVATE in combination with VM_MAYWRITE indicates that the VMA has copy-on-write semantics, which for VM_PFNMAP are semi-supported but fairly cursed. In particular, in such a mapping, the driver can only install PTEs during mmap() by calling remap_pfn_range() (because remap_pfn_range() wants to **store the physical address of the mapped physical memory into the vm_pgoff of the VMA**); installing PTEs later on with a fault handler (as panthor does) is not supported in private mappings, and so if you try to fault in such a mapping, vmf_insert_pfn_prot() splats when it hits a BUG() check. Fix it by clearing the VM_MAYWRITE flag (userspace writing to the FLUSH_ID doesn't make sense) and requiring VM_SHARED (copy-on-write semantics for the FLUSH_ID don't make sense). Reproducers for both scenarios are in the notes of my patch on the mailing list; I tested that these bugs exist on a Rock 5B machine. Note that I only compile-tested the patch, I haven't tested it; I don't have a working kernel build setup for the test machine yet. Please test it before applying it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53080", "url": "https://ubuntu.com/security/CVE-2024-53080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Lock XArray when getting entries for the VM Similar to commit cac075706f29 (\"drm/panthor: Fix race when converting group handle to group object\") we need to use the XArray's internal locking when retrieving a vm pointer from there. v2: Removed part of the patch that was trying to protect fetching the heap pointer from XArray, as that operation is protected by the @pool->lock.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53084", "url": "https://ubuntu.com/security/CVE-2024-53084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Break an object reference loop When remaining resources are being cleaned up on driver close, outstanding VM mappings may result in resources being leaked, due to an object reference loop, as shown below, with each object (or set of objects) referencing the object below it: PVR GEM Object GPU scheduler \"finished\" fence GPU scheduler “scheduled” fence PVR driver “done” fence PVR Context PVR VM Context PVR VM Mappings PVR GEM Object The reference that the PVR VM Context has on the VM mappings is a soft one, in the sense that the freeing of outstanding VM mappings is done as part of VM context destruction; no reference counts are involved, as is the case for all the other references in the loop. To break the reference loop during cleanup, free the outstanding VM mappings before destroying the PVR Context associated with the VM context.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53085", "url": "https://ubuntu.com/security/CVE-2024-53085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: Lock TPM chip in tpm_pm_suspend() first Setting TPM_CHIP_FLAG_SUSPENDED in the end of tpm_pm_suspend() can be racy according, as this leaves window for tpm_hwrng_read() to be called while the operation is in progress. The recent bug report gives also evidence of this behaviour. Aadress this by locking the TPM chip before checking any chip->flags both in tpm_pm_suspend() and tpm_hwrng_read(). Move TPM_CHIP_FLAG_SUSPENDED check inside tpm_get_random() so that it will be always checked only when the lock is reserved.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53086", "url": "https://ubuntu.com/security/CVE-2024-53086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Drop VM dma-resv lock on xe_sync_in_fence_get failure in exec IOCTL Upon failure all locks need to be dropped before returning to the user. (cherry picked from commit 7d1a4258e602ffdce529f56686925034c1b3b095)", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53087", "url": "https://ubuntu.com/security/CVE-2024-53087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix possible exec queue leak in exec IOCTL In a couple of places after an exec queue is looked up the exec IOCTL returns on input errors without dropping the exec queue ref. Fix this ensuring the exec queue ref is dropped on input error. (cherry picked from commit 07064a200b40ac2195cb6b7b779897d9377e5e6f)", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50283", "url": "https://ubuntu.com/security/CVE-2024-50283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-use-after-free in smb3_preauth_hash_rsp ksmbd_user_session_put should be called under smb3_preauth_hash_rsp(). It will avoid freeing session before calling smb3_preauth_hash_rsp().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50284", "url": "https://ubuntu.com/security/CVE-2024-50284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix the missing xa_store error check xa_store() can fail, it return xa_err(-EINVAL) if the entry cannot be stored in an XArray, or xa_err(-ENOMEM) if memory allocation failed, so check error for xa_store() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50285", "url": "https://ubuntu.com/security/CVE-2024-50285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: check outstanding simultaneous SMB operations If Client send simultaneous SMB operations to ksmbd, It exhausts too much memory through the \"ksmbd_work_cache”. It will cause OOM issue. ksmbd has a credit mechanism but it can't handle this problem. This patch add the check if it exceeds max credits to prevent this problem by assuming that one smb request consumes at least one credit.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50286", "url": "https://ubuntu.com/security/CVE-2024-50286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-use-after-free in ksmbd_smb2_session_create There is a race condition between ksmbd_smb2_session_create and ksmbd_expire_session. This patch add missing sessions_table_lock while adding/deleting session from global session table.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50287", "url": "https://ubuntu.com/security/CVE-2024-50287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-tpg: prevent the risk of a division by zero As reported by Coverity, the logic at tpg_precalculate_line() blindly rescales the buffer even when scaled_witdh is equal to zero. If this ever happens, this will cause a division by zero. Instead, add a WARN_ON_ONCE() to trigger such cases and return without doing any precalculation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50288", "url": "https://ubuntu.com/security/CVE-2024-50288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: fix buffer overwrite when using > 32 buffers The maximum number of buffers that can be requested was increased to 64 for the video capture queue. But video capture used a must_blank array that was still sized for 32 (VIDEO_MAX_FRAME). This caused an out-of-bounds write when using buffer indices >= 32. Create a new define MAX_VID_CAP_BUFFERS that is used to access the must_blank array and set max_num_buffers for the video capture queue. This solves a crash reported by: \thttps://bugzilla.kernel.org/show_bug.cgi?id=219258", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50289", "url": "https://ubuntu.com/security/CVE-2024-50289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: av7110: fix a spectre vulnerability As warned by smatch: \tdrivers/staging/media/av7110/av7110_ca.c:270 dvb_ca_ioctl() warn: potential spectre issue 'av7110->ci_slot' [w] (local cap) There is a spectre-related vulnerability at the code. Fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50290", "url": "https://ubuntu.com/security/CVE-2024-50290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx24116: prevent overflows on SNR calculus as reported by Coverity, if reading SNR registers fail, a negative number will be returned, causing an underflow when reading SNR registers. Prevent that.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53061", "url": "https://ubuntu.com/security/CVE-2024-53061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: s5p-jpeg: prevent buffer overflows The current logic allows word to be less than 2. If this happens, there will be buffer overflows, as reported by smatch. Add extra checks to prevent it. While here, remove an unused word = 0 assignment.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53081", "url": "https://ubuntu.com/security/CVE-2024-53081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ar0521: don't overflow when checking PLL values The PLL checks are comparing 64 bit integers with 32 bit ones, as reported by Coverity. Depending on the values of the variables, this may underflow. Fix it ensuring that both sides of the expression are u64.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53062", "url": "https://ubuntu.com/security/CVE-2024-53062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mgb4: protect driver against spectre Frequency range is set from sysfs via frequency_range_store(), being vulnerable to spectre, as reported by smatch: \tdrivers/media/pci/mgb4/mgb4_cmt.c:231 mgb4_cmt_set_vin_freq_range() warn: potential spectre issue 'cmt_vals_in' [r] \tdrivers/media/pci/mgb4/mgb4_cmt.c:238 mgb4_cmt_set_vin_freq_range() warn: possible spectre second half. 'reg_set' Fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50291", "url": "https://ubuntu.com/security/CVE-2024-50291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvb-core: add missing buffer index check dvb_vb2_expbuf() didn't check if the given buffer index was for a valid buffer. Add this check.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50292", "url": "https://ubuntu.com/security/CVE-2024-50292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: stm32: spdifrx: fix dma channel release in stm32_spdifrx_remove In case of error when requesting ctrl_chan DMA channel, ctrl_chan is not null. So the release of the dma channel leads to the following issue: [ 4.879000] st,stm32-spdifrx 500d0000.audio-controller: dma_request_slave_channel error -19 [ 4.888975] Unable to handle kernel NULL pointer dereference at virtual address 000000000000003d [...] [ 5.096577] Call trace: [ 5.099099] dma_release_channel+0x24/0x100 [ 5.103235] stm32_spdifrx_remove+0x24/0x60 [snd_soc_stm32_spdifrx] [ 5.109494] stm32_spdifrx_probe+0x320/0x4c4 [snd_soc_stm32_spdifrx] To avoid this issue, release channel only if the pointer is valid.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53063", "url": "https://ubuntu.com/security/CVE-2024-53063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvbdev: prevent the risk of out of memory access The dvbdev contains a static variable used to store dvb minors. The behavior of it depends if CONFIG_DVB_DYNAMIC_MINORS is set or not. When not set, dvb_register_device() won't check for boundaries, as it will rely that a previous call to dvb_register_adapter() would already be enforcing it. On a similar way, dvb_device_open() uses the assumption that the register functions already did the needed checks. This can be fragile if some device ends using different calls. This also generate warnings on static check analysers like Coverity. So, add explicit guards to prevent potential risk of OOM issues.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50293", "url": "https://ubuntu.com/security/CVE-2024-50293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: do not leave a dangling sk pointer in __smc_create() Thanks to commit 4bbd360a5084 (\"socket: Print pf->create() when it does not clear sock->sk on failure.\"), syzbot found an issue with AF_SMC: smc_create must clear sock->sk on failure, family: 43, type: 1, protocol: 0 WARNING: CPU: 0 PID: 5827 at net/socket.c:1565 __sock_create+0x96f/0xa30 net/socket.c:1563 Modules linked in: CPU: 0 UID: 0 PID: 5827 Comm: syz-executor259 Not tainted 6.12.0-rc6-next-20241106-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:__sock_create+0x96f/0xa30 net/socket.c:1563 Code: 03 00 74 08 4c 89 e7 e8 4f 3b 85 f8 49 8b 34 24 48 c7 c7 40 89 0c 8d 8b 54 24 04 8b 4c 24 0c 44 8b 44 24 08 e8 32 78 db f7 90 <0f> 0b 90 90 e9 d3 fd ff ff 89 e9 80 e1 07 fe c1 38 c1 0f 8c ee f7 RSP: 0018:ffffc90003e4fda0 EFLAGS: 00010246 RAX: 099c6f938c7f4700 RBX: 1ffffffff1a595fd RCX: ffff888034823c00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 00000000ffffffe9 R08: ffffffff81567052 R09: 1ffff920007c9f50 R10: dffffc0000000000 R11: fffff520007c9f51 R12: ffffffff8d2cafe8 R13: 1ffffffff1a595fe R14: ffffffff9a789c40 R15: ffff8880764298c0 FS: 000055557b518380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa62ff43225 CR3: 0000000031628000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: sock_create net/socket.c:1616 [inline] __sys_socket_create net/socket.c:1653 [inline] __sys_socket+0x150/0x3c0 net/socket.c:1700 __do_sys_socket net/socket.c:1714 [inline] __se_sys_socket net/socket.c:1712 [inline] For reference, see commit 2d859aff775d (\"Merge branch 'do-not-leave-dangling-sk-pointers-in-pf-create-functions'\")", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50294", "url": "https://ubuntu.com/security/CVE-2024-50294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix missing locking causing hanging calls If a call gets aborted (e.g. because kafs saw a signal) between it being queued for connection and the I/O thread picking up the call, the abort will be prioritised over the connection and it will be removed from local->new_client_calls by rxrpc_disconnect_client_call() without a lock being held. This may cause other calls on the list to disappear if a race occurs. Fix this by taking the client_call_lock when removing a call from whatever list its ->wait_link happens to be on.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50295", "url": "https://ubuntu.com/security/CVE-2024-50295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: arc: fix the device for dma_map_single/dma_unmap_single The ndev->dev and pdev->dev aren't the same device, use ndev->dev.parent which has dma_mask, ndev->dev.parent is just pdev->dev. Or it would cause the following issue: [ 39.933526] ------------[ cut here ]------------ [ 39.938414] WARNING: CPU: 1 PID: 501 at kernel/dma/mapping.c:149 dma_map_page_attrs+0x90/0x1f8", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53082", "url": "https://ubuntu.com/security/CVE-2024-53082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_net: Add hash_key_length check Add hash_key_length check in virtnet_probe() to avoid possible out of bound errors when setting/reading the hash key.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50296", "url": "https://ubuntu.com/security/CVE-2024-50296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash when uninstalling driver When the driver is uninstalled and the VF is disabled concurrently, a kernel crash occurs. The reason is that the two actions call function pci_disable_sriov(). The num_VFs is checked to determine whether to release the corresponding resources. During the second calling, num_VFs is not 0 and the resource release function is called. However, the corresponding resource has been released during the first invoking. Therefore, the problem occurs: [15277.839633][T50670] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ... [15278.131557][T50670] Call trace: [15278.134686][T50670] klist_put+0x28/0x12c [15278.138682][T50670] klist_del+0x14/0x20 [15278.142592][T50670] device_del+0xbc/0x3c0 [15278.146676][T50670] pci_remove_bus_device+0x84/0x120 [15278.151714][T50670] pci_stop_and_remove_bus_device+0x6c/0x80 [15278.157447][T50670] pci_iov_remove_virtfn+0xb4/0x12c [15278.162485][T50670] sriov_disable+0x50/0x11c [15278.166829][T50670] pci_disable_sriov+0x24/0x30 [15278.171433][T50670] hnae3_unregister_ae_algo_prepare+0x60/0x90 [hnae3] [15278.178039][T50670] hclge_exit+0x28/0xd0 [hclge] [15278.182730][T50670] __se_sys_delete_module.isra.0+0x164/0x230 [15278.188550][T50670] __arm64_sys_delete_module+0x1c/0x30 [15278.193848][T50670] invoke_syscall+0x50/0x11c [15278.198278][T50670] el0_svc_common.constprop.0+0x158/0x164 [15278.203837][T50670] do_el0_svc+0x34/0xcc [15278.207834][T50670] el0_svc+0x20/0x30 For details, see the following figure. rmmod hclge disable VFs ---------------------------------------------------- hclge_exit() sriov_numvfs_store() ... device_lock() pci_disable_sriov() hns3_pci_sriov_configure() pci_disable_sriov() sriov_disable() sriov_disable() if !num_VFs : if !num_VFs : return; return; sriov_del_vfs() sriov_del_vfs() ... ... klist_put() klist_put() ... ... num_VFs = 0; num_VFs = 0; device_unlock(); In this patch, when driver is removing, we get the device_lock() to protect num_VFs, just like sriov_numvfs_store().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53088", "url": "https://ubuntu.com/security/CVE-2024-53088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: fix race condition by adding filter's intermediate sync state Fix a race condition in the i40e driver that leads to MAC/VLAN filters becoming corrupted and leaking. Address the issue that occurs under heavy load when multiple threads are concurrently modifying MAC/VLAN filters by setting mac and port VLAN. 1. Thread T0 allocates a filter in i40e_add_filter() within i40e_ndo_set_vf_port_vlan(). 2. Thread T1 concurrently frees the filter in __i40e_del_filter() within i40e_ndo_set_vf_mac(). 3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which refers to the already freed filter memory, causing corruption. Reproduction steps: 1. Spawn multiple VFs. 2. Apply a concurrent heavy load by running parallel operations to change MAC addresses on the VFs and change port VLANs on the host. 3. Observe errors in dmesg: \"Error I40E_AQ_RC_ENOSPC adding RX filters on VF XX, \tplease set promiscuous on manually for VF XX\". Exact code for stable reproduction Intel can't open-source now. The fix involves implementing a new intermediate filter state, I40E_FILTER_NEW_SYNC, for the time when a filter is on a tmp_add_list. These filters cannot be deleted from the hash list directly but must be removed using the full process.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50297", "url": "https://ubuntu.com/security/CVE-2024-50297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: xilinx: axienet: Enqueue Tx packets in dql before dmaengine starts Enqueue packets in dql after dma engine starts causes race condition. Tx transfer starts once dma engine is started and may execute dql dequeue in completion before it gets queued. It results in following kernel crash while running iperf stress test: kernel BUG at lib/dynamic_queue_limits.c:99! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP pc : dql_completed+0x238/0x248 lr : dql_completed+0x3c/0x248 Call trace: dql_completed+0x238/0x248 axienet_dma_tx_cb+0xa0/0x170 xilinx_dma_do_tasklet+0xdc/0x290 tasklet_action_common+0xf8/0x11c tasklet_action+0x30/0x3c handle_softirqs+0xf8/0x230 Start dmaengine after enqueue in dql fixes the crash.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50298", "url": "https://ubuntu.com/security/CVE-2024-50298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: enetc: allocate vf_state during PF probes In the previous implementation, vf_state is allocated memory only when VF is enabled. However, net_device_ops::ndo_set_vf_mac() may be called before VF is enabled to configure the MAC address of VF. If this is the case, enetc_pf_set_vf_mac() will access vf_state, resulting in access to a null pointer. The simplified error log is as follows. root@ls1028ardb:~# ip link set eno0 vf 1 mac 00:0c:e7:66:77:89 [ 173.543315] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 [ 173.637254] pc : enetc_pf_set_vf_mac+0x3c/0x80 Message from sy [ 173.641973] lr : do_setlink+0x4a8/0xec8 [ 173.732292] Call trace: [ 173.734740] enetc_pf_set_vf_mac+0x3c/0x80 [ 173.738847] __rtnl_newlink+0x530/0x89c [ 173.742692] rtnl_newlink+0x50/0x7c [ 173.746189] rtnetlink_rcv_msg+0x128/0x390 [ 173.750298] netlink_rcv_skb+0x60/0x130 [ 173.754145] rtnetlink_rcv+0x18/0x24 [ 173.757731] netlink_unicast+0x318/0x380 [ 173.761665] netlink_sendmsg+0x17c/0x3c8", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50299", "url": "https://ubuntu.com/security/CVE-2024-50299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: properly validate chunk size in sctp_sf_ootb() A size validation fix similar to that in Commit 50619dbf8db7 (\"sctp: add size validation when walking chunks\") is also required in sctp_sf_ootb() to address a crash reported by syzbot: BUG: KMSAN: uninit-value in sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_do_sm+0x181/0x93d0 net/sctp/sm_sideeffect.c:1166 sctp_endpoint_bh_rcv+0xc38/0xf90 net/sctp/endpointola.c:407 sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88 sctp_rcv+0x3831/0x3b20 net/sctp/input.c:243 sctp4_rcv+0x42/0x50 net/sctp/protocol.c:1159 ip_protocol_deliver_rcu+0xb51/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50300", "url": "https://ubuntu.com/security/CVE-2024-50300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: rtq2208: Fix uninitialized use of regulator_config Fix rtq2208 driver uninitialized use to cause kernel error.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50301", "url": "https://ubuntu.com/security/CVE-2024-50301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: security/keys: fix slab-out-of-bounds in key_task_permission KASAN reports an out of bounds read: BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline] BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362 CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0x107/0x167 lib/dump_stack.c:123 print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 __kuid_val include/linux/uidgid.h:36 [inline] uid_eq include/linux/uidgid.h:63 [inline] key_task_permission+0x394/0x410 security/keys/permission.c:54 search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793 This issue was also reported by syzbot. It can be reproduced by following these steps(more details [1]): 1. Obtain more than 32 inputs that have similar hashes, which ends with the pattern '0xxxxxxxe6'. 2. Reboot and add the keys obtained in step 1. The reproducer demonstrates how this issue happened: 1. In the search_nested_keyrings function, when it iterates through the slots in a node(below tag ascend_to_node), if the slot pointer is meta and node->back_pointer != NULL(it means a root), it will proceed to descend_to_node. However, there is an exception. If node is the root, and one of the slots points to a shortcut, it will be treated as a keyring. 2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function. However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as ASSOC_ARRAY_PTR_SUBTYPE_MASK. 3. When 32 keys with the similar hashes are added to the tree, the ROOT has keys with hashes that are not similar (e.g. slot 0) and it splits NODE A without using a shortcut. When NODE A is filled with keys that all hashes are xxe6, the keys are similar, NODE A will split with a shortcut. Finally, it forms the tree as shown below, where slot 6 points to a shortcut. NODE A +------>+---+ ROOT | | 0 | xxe6 +---+ | +---+ xxxx | 0 | shortcut : : xxe6 +---+ | +---+ xxe6 : : | | | xxe6 +---+ | +---+ | 6 |---+ : : xxe6 +---+ +---+ xxe6 : : | f | xxe6 +---+ +---+ xxe6 | f | +---+ 4. As mentioned above, If a slot(slot 6) of the root points to a shortcut, it may be mistakenly transferred to a key*, leading to a read out-of-bounds read. To fix this issue, one should jump to descend_to_node if the ptr is a shortcut, regardless of whether the node is root or not. [1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/ [jarkko: tweaked the commit message a bit to have an appropriate closes tag.]", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53072", "url": "https://ubuntu.com/security/CVE-2024-53072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/pmc: Detect when STB is not available Loading the amd_pmc module as: amd_pmc enable_stb=1 ...can result in the following messages in the kernel ring buffer: amd_pmc AMDI0009:00: SMU cmd failed. err: 0xff ioremap on RAM at 0x0000000000000000 - 0x0000000000ffffff WARNING: CPU: 10 PID: 2151 at arch/x86/mm/ioremap.c:217 __ioremap_caller+0x2cd/0x340 Further debugging reveals that this occurs when the requests for S2D_PHYS_ADDR_LOW and S2D_PHYS_ADDR_HIGH return a value of 0, indicating that the STB is inaccessible. To prevent the ioremap warning and provide clarity to the user, handle the invalid address and display an error message.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50302", "url": "https://ubuntu.com/security/CVE-2024-50302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: zero-initialize the report buffer Since the report buffer is used by all kinds of drivers in various ways, let's zero-initialize it during allocation to make sure that it can't be ever used to leak kernel memory via specially-crafted report.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53068", "url": "https://ubuntu.com/security/CVE-2024-53068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix slab-use-after-free in scmi_bus_notifier() The scmi_dev->name is released prematurely in __scmi_device_destroy(), which causes slab-use-after-free when accessing scmi_dev->name in scmi_bus_notifier(). So move the release of scmi_dev->name to scmi_device_release() to avoid slab-use-after-free. | BUG: KASAN: slab-use-after-free in strncmp+0xe4/0xec | Read of size 1 at addr ffffff80a482bcc0 by task swapper/0/1 | | CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.6.38-debug #1 | Hardware name: Qualcomm Technologies, Inc. SA8775P Ride (DT) | Call trace: | dump_backtrace+0x94/0x114 | show_stack+0x18/0x24 | dump_stack_lvl+0x48/0x60 | print_report+0xf4/0x5b0 | kasan_report+0xa4/0xec | __asan_report_load1_noabort+0x20/0x2c | strncmp+0xe4/0xec | scmi_bus_notifier+0x5c/0x54c | notifier_call_chain+0xb4/0x31c | blocking_notifier_call_chain+0x68/0x9c | bus_notify+0x54/0x78 | device_del+0x1bc/0x840 | device_unregister+0x20/0xb4 | __scmi_device_destroy+0xac/0x280 | scmi_device_destroy+0x94/0xd0 | scmi_chan_setup+0x524/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20 | | Allocated by task 1: | kasan_save_stack+0x2c/0x54 | kasan_set_track+0x2c/0x40 | kasan_save_alloc_info+0x24/0x34 | __kasan_kmalloc+0xa0/0xb8 | __kmalloc_node_track_caller+0x6c/0x104 | kstrdup+0x48/0x84 | kstrdup_const+0x34/0x40 | __scmi_device_create.part.0+0x8c/0x408 | scmi_device_create+0x104/0x370 | scmi_chan_setup+0x2a0/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20 | | Freed by task 1: | kasan_save_stack+0x2c/0x54 | kasan_set_track+0x2c/0x40 | kasan_save_free_info+0x38/0x5c | __kasan_slab_free+0xe8/0x164 | __kmem_cache_free+0x11c/0x230 | kfree+0x70/0x130 | kfree_const+0x20/0x40 | __scmi_device_destroy+0x70/0x280 | scmi_device_destroy+0x94/0xd0 | scmi_chan_setup+0x524/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53069", "url": "https://ubuntu.com/security/CVE-2024-53069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: qcom: scm: fix a NULL-pointer dereference Some SCM calls can be invoked with __scm being NULL (the driver may not have been and will not be probed as there's no SCM entry in device-tree). Make sure we don't dereference a NULL pointer.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50212", "url": "https://ubuntu.com/security/CVE-2024-50212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib: alloc_tag_module_unload must wait for pending kfree_rcu calls Ben Greear reports following splat: ------------[ cut here ]------------ net/netfilter/nf_nat_core.c:1114 module nf_nat func:nf_nat_register_fn has 256 allocated at module unload WARNING: CPU: 1 PID: 10421 at lib/alloc_tag.c:168 alloc_tag_module_unload+0x22b/0x3f0 Modules linked in: nf_nat(-) btrfs ufs qnx4 hfsplus hfs minix vfat msdos fat ... Hardware name: Default string Default string/SKYBAY, BIOS 5.12 08/04/2020 RIP: 0010:alloc_tag_module_unload+0x22b/0x3f0 codetag_unload_module+0x19b/0x2a0 ? codetag_load_module+0x80/0x80 nf_nat module exit calls kfree_rcu on those addresses, but the free operation is likely still pending by the time alloc_tag checks for leaks. Wait for outstanding kfree_rcu operations to complete before checking resolves this warning. Reproducer: unshare -n iptables-nft -t nat -A PREROUTING -p tcp grep nf_nat /proc/allocinfo # will list 4 allocations rmmod nft_chain_nat rmmod nf_nat # will WARN. [akpm@linux-foundation.org: add comment]", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53046", "url": "https://ubuntu.com/security/CVE-2024-53046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: dts: imx8ulp: correct the flexspi compatible string The flexspi on imx8ulp only has 16 LUTs, and imx8mm flexspi has 32 LUTs, so correct the compatible string here, otherwise will meet below error: [ 1.119072] ------------[ cut here ]------------ [ 1.123926] WARNING: CPU: 0 PID: 1 at drivers/spi/spi-nxp-fspi.c:855 nxp_fspi_exec_op+0xb04/0xb64 [ 1.133239] Modules linked in: [ 1.136448] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-rc6-next-20240902-00001-g131bf9439dd9 #69 [ 1.146821] Hardware name: NXP i.MX8ULP EVK (DT) [ 1.151647] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.158931] pc : nxp_fspi_exec_op+0xb04/0xb64 [ 1.163496] lr : nxp_fspi_exec_op+0xa34/0xb64 [ 1.168060] sp : ffff80008002b2a0 [ 1.171526] x29: ffff80008002b2d0 x28: 0000000000000000 x27: 0000000000000000 [ 1.179002] x26: ffff2eb645542580 x25: ffff800080610014 x24: ffff800080610000 [ 1.186480] x23: ffff2eb645548080 x22: 0000000000000006 x21: ffff2eb6455425e0 [ 1.193956] x20: 0000000000000000 x19: ffff80008002b5e0 x18: ffffffffffffffff [ 1.201432] x17: ffff2eb644467508 x16: 0000000000000138 x15: 0000000000000002 [ 1.208907] x14: 0000000000000000 x13: ffff2eb6400d8080 x12: 00000000ffffff00 [ 1.216378] x11: 0000000000000000 x10: ffff2eb6400d8080 x9 : ffff2eb697adca80 [ 1.223850] x8 : ffff2eb697ad3cc0 x7 : 0000000100000000 x6 : 0000000000000001 [ 1.231324] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000007a6 [ 1.238795] x2 : 0000000000000000 x1 : 00000000000001ce x0 : 00000000ffffff92 [ 1.246267] Call trace: [ 1.248824] nxp_fspi_exec_op+0xb04/0xb64 [ 1.253031] spi_mem_exec_op+0x3a0/0x430 [ 1.257139] spi_nor_read_id+0x80/0xcc [ 1.261065] spi_nor_scan+0x1ec/0xf10 [ 1.264901] spi_nor_probe+0x108/0x2fc [ 1.268828] spi_mem_probe+0x6c/0xbc [ 1.272574] spi_probe+0x84/0xe4 [ 1.275958] really_probe+0xbc/0x29c [ 1.279713] __driver_probe_device+0x78/0x12c [ 1.284277] driver_probe_device+0xd8/0x15c [ 1.288660] __device_attach_driver+0xb8/0x134 [ 1.293316] bus_for_each_drv+0x88/0xe8 [ 1.297337] __device_attach+0xa0/0x190 [ 1.301353] device_initial_probe+0x14/0x20 [ 1.305734] bus_probe_device+0xac/0xb0 [ 1.309752] device_add+0x5d0/0x790 [ 1.313408] __spi_add_device+0x134/0x204 [ 1.317606] of_register_spi_device+0x3b4/0x590 [ 1.322348] spi_register_controller+0x47c/0x754 [ 1.327181] devm_spi_register_controller+0x4c/0xa4 [ 1.332289] nxp_fspi_probe+0x1cc/0x2b0 [ 1.336307] platform_probe+0x68/0xc4 [ 1.340145] really_probe+0xbc/0x29c [ 1.343893] __driver_probe_device+0x78/0x12c [ 1.348457] driver_probe_device+0xd8/0x15c [ 1.352838] __driver_attach+0x90/0x19c [ 1.356857] bus_for_each_dev+0x7c/0xdc [ 1.360877] driver_attach+0x24/0x30 [ 1.364624] bus_add_driver+0xe4/0x208 [ 1.368552] driver_register+0x5c/0x124 [ 1.372573] __platform_driver_register+0x28/0x34 [ 1.377497] nxp_fspi_driver_init+0x1c/0x28 [ 1.381888] do_one_initcall+0x80/0x1c8 [ 1.385908] kernel_init_freeable+0x1c4/0x28c [ 1.390472] kernel_init+0x20/0x1d8 [ 1.394138] ret_from_fork+0x10/0x20 [ 1.397885] ---[ end trace 0000000000000000 ]--- [ 1.407908] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53052", "url": "https://ubuntu.com/security/CVE-2024-53052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/rw: fix missing NOWAIT check for O_DIRECT start write When io_uring starts a write, it'll call kiocb_start_write() to bump the super block rwsem, preventing any freezes from happening while that write is in-flight. The freeze side will grab that rwsem for writing, excluding any new writers from happening and waiting for existing writes to finish. But io_uring unconditionally uses kiocb_start_write(), which will block if someone is currently attempting to freeze the mount point. This causes a deadlock where freeze is waiting for previous writes to complete, but the previous writes cannot complete, as the task that is supposed to complete them is blocked waiting on starting a new write. This results in the following stuck trace showing that dependency with the write blocked starting a new write: task:fio state:D stack:0 pid:886 tgid:886 ppid:876 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_rwsem_wait+0x1e8/0x3f8 __percpu_down_read+0xe8/0x500 io_write+0xbb8/0xff8 io_issue_sqe+0x10c/0x1020 io_submit_sqes+0x614/0x2110 __arm64_sys_io_uring_enter+0x524/0x1038 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 INFO: task fsfreeze:7364 blocked for more than 15 seconds. Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963 with the attempting freezer stuck trying to grab the rwsem: task:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_down_write+0x2b0/0x680 freeze_super+0x248/0x8a8 do_vfs_ioctl+0x149c/0x1b18 __arm64_sys_ioctl+0xd0/0x1a0 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 Fix this by having the io_uring side honor IOCB_NOWAIT, and only attempt a blocking grab of the super block rwsem if it isn't set. For normal issue where IOCB_NOWAIT would always be set, this returns -EAGAIN which will have io_uring core issue a blocking attempt of the write. That will in turn also get completions run, ensuring forward progress. Since freezing requires CAP_SYS_ADMIN in the first place, this isn't something that can be triggered by a regular user.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50213", "url": "https://ubuntu.com/security/CVE-2024-50213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tests: hdmi: Fix memory leaks in drm_display_mode_from_cea_vic() modprobe drm_hdmi_state_helper_test and then rmmod it, the following memory leak occurs. The `mode` allocated in drm_mode_duplicate() called by drm_display_mode_from_cea_vic() is not freed, which cause the memory leak: \tunreferenced object 0xffffff80ccd18100 (size 128): \t comm \"kunit_try_catch\", pid 1851, jiffies 4295059695 \t hex dump (first 32 bytes): \t 57 62 00 00 80 02 90 02 f0 02 20 03 00 00 e0 01 Wb........ ..... \t ea 01 ec 01 0d 02 00 00 0a 00 00 00 00 00 00 00 ................ \t backtrace (crc c2f1aa95): \t [<000000000f10b11b>] kmemleak_alloc+0x34/0x40 \t [<000000001cd4cf73>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<00000000f1f3cffa>] drm_mode_duplicate+0x44/0x19c \t [<000000008cbeef13>] drm_display_mode_from_cea_vic+0x88/0x98 \t [<0000000019daaacf>] 0xffffffedc11ae69c \t [<000000000aad0f85>] kunit_try_run_case+0x13c/0x3ac \t [<00000000a9210bac>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<000000000a0b2e9e>] kthread+0x2e8/0x374 \t [<00000000bd668858>] ret_from_fork+0x10/0x20 \t...... Free `mode` by using drm_kunit_display_mode_from_cea_vic() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50214", "url": "https://ubuntu.com/security/CVE-2024-50214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/connector: hdmi: Fix memory leak in drm_display_mode_from_cea_vic() modprobe drm_connector_test and then rmmod drm_connector_test, the following memory leak occurs. The `mode` allocated in drm_mode_duplicate() called by drm_display_mode_from_cea_vic() is not freed, which cause the memory leak: \tunreferenced object 0xffffff80cb0ee400 (size 128): \t comm \"kunit_try_catch\", pid 1948, jiffies 4294950339 \t hex dump (first 32 bytes): \t 14 44 02 00 80 07 d8 07 04 08 98 08 00 00 38 04 .D............8. \t 3c 04 41 04 65 04 00 00 05 00 00 00 00 00 00 00 <.A.e........... \t backtrace (crc 90e9585c): \t [<00000000ec42e3d7>] kmemleak_alloc+0x34/0x40 \t [<00000000d0ef055a>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<00000000c2062161>] drm_mode_duplicate+0x44/0x19c \t [<00000000f96c74aa>] drm_display_mode_from_cea_vic+0x88/0x98 \t [<00000000d8f2c8b4>] 0xffffffdc982a4868 \t [<000000005d164dbc>] kunit_try_run_case+0x13c/0x3ac \t [<000000006fb23398>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<000000006ea56ca0>] kthread+0x2e8/0x374 \t [<000000000676063f>] ret_from_fork+0x10/0x20 \t...... Free `mode` by using drm_kunit_display_mode_from_cea_vic() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50215", "url": "https://ubuntu.com/security/CVE-2024-50215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: assign dh_key to NULL after kfree_sensitive ctrl->dh_key might be used across multiple calls to nvmet_setup_dhgroup() for the same controller. So it's better to nullify it after release on error path in order to avoid double free later in nvmet_destroy_auth(). Found by Linux Verification Center (linuxtesting.org) with Svace.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50216", "url": "https://ubuntu.com/security/CVE-2024-50216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix finding a last resort AG in xfs_filestream_pick_ag When the main loop in xfs_filestream_pick_ag fails to find a suitable AG it tries to just pick the online AG. But the loop for that uses args->pag as loop iterator while the later code expects pag to be set. Fix this by reusing the max_pag case for this last resort, and also add a check for impossible case of no AG just to make sure that the uninitialized pag doesn't even escape in theory.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50217", "url": "https://ubuntu.com/security/CVE-2024-50217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free of block device file in __btrfs_free_extra_devids() Mounting btrfs from two images (which have the same one fsid and two different dev_uuids) in certain executing order may trigger an UAF for variable 'device->bdev_file' in __btrfs_free_extra_devids(). And following are the details: 1. Attach image_1 to loop0, attach image_2 to loop1, and scan btrfs devices by ioctl(BTRFS_IOC_SCAN_DEV): / btrfs_device_1 ? loop0 fs_device \\ btrfs_device_2 ? loop1 2. mount /dev/loop0 /mnt btrfs_open_devices btrfs_device_1->bdev_file = btrfs_get_bdev_and_sb(loop0) btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree fail: btrfs_close_devices // -ENOMEM \t btrfs_close_bdev(btrfs_device_1) fput(btrfs_device_1->bdev_file) \t // btrfs_device_1->bdev_file is freed \t btrfs_close_bdev(btrfs_device_2) fput(btrfs_device_2->bdev_file) 3. mount /dev/loop1 /mnt btrfs_open_devices btrfs_get_bdev_and_sb(&bdev_file) // EIO, btrfs_device_1->bdev_file is not assigned, // which points to a freed memory area btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree btrfs_free_extra_devids if (btrfs_device_1->bdev_file) fput(btrfs_device_1->bdev_file) // UAF ! Fix it by setting 'device->bdev_file' as 'NULL' after closing the btrfs_device in btrfs_close_one_device().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53043", "url": "https://ubuntu.com/security/CVE-2024-53043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mctp i2c: handle NULL header address daddr can be NULL if there is no neighbour table entry present, in that case the tx packet should be dropped. saddr will usually be set by MCTP core, but check for NULL in case a packet is transmitted by a different protocol.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50303", "url": "https://ubuntu.com/security/CVE-2024-50303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: resource,kexec: walk_system_ram_res_rev must retain resource flags walk_system_ram_res_rev() erroneously discards resource flags when passing the information to the callback. This causes systems with IORESOURCE_SYSRAM_DRIVER_MANAGED memory to have these resources selected during kexec to store kexec buffers if that memory happens to be at placed above normal system ram. This leads to undefined behavior after reboot. If the kexec buffer is never touched, nothing happens. If the kexec buffer is touched, it could lead to a crash (like below) or undefined behavior. Tested on a system with CXL memory expanders with driver managed memory, TPM enabled, and CONFIG_IMA_KEXEC=y. Adding printk's showed the flags were being discarded and as a result the check for IORESOURCE_SYSRAM_DRIVER_MANAGED passes. find_next_iomem_res: name(System RAM (kmem)) \t\t start(10000000000) \t\t end(1034fffffff) \t\t flags(83000200) locate_mem_hole_top_down: start(10000000000) end(1034fffffff) flags(0) [.] BUG: unable to handle page fault for address: ffff89834ffff000 [.] #PF: supervisor read access in kernel mode [.] #PF: error_code(0x0000) - not-present page [.] PGD c04c8bf067 P4D c04c8bf067 PUD c04c8be067 PMD 0 [.] Oops: 0000 [#1] SMP [.] RIP: 0010:ima_restore_measurement_list+0x95/0x4b0 [.] RSP: 0018:ffffc900000d3a80 EFLAGS: 00010286 [.] RAX: 0000000000001000 RBX: 0000000000000000 RCX: ffff89834ffff000 [.] RDX: 0000000000000018 RSI: ffff89834ffff000 RDI: ffff89834ffff018 [.] RBP: ffffc900000d3ba0 R08: 0000000000000020 R09: ffff888132b8a900 [.] R10: 4000000000000000 R11: 000000003a616d69 R12: 0000000000000000 [.] R13: ffffffff8404ac28 R14: 0000000000000000 R15: ffff89834ffff000 [.] FS: 0000000000000000(0000) GS:ffff893d44640000(0000) knlGS:0000000000000000 [.] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [.] ata5: SATA link down (SStatus 0 SControl 300) [.] CR2: ffff89834ffff000 CR3: 000001034d00f001 CR4: 0000000000770ef0 [.] PKRU: 55555554 [.] Call Trace: [.] [.] ? __die+0x78/0xc0 [.] ? page_fault_oops+0x2a8/0x3a0 [.] ? exc_page_fault+0x84/0x130 [.] ? asm_exc_page_fault+0x22/0x30 [.] ? ima_restore_measurement_list+0x95/0x4b0 [.] ? template_desc_init_fields+0x317/0x410 [.] ? crypto_alloc_tfm_node+0x9c/0xc0 [.] ? init_ima_lsm+0x30/0x30 [.] ima_load_kexec_buffer+0x72/0xa0 [.] ima_init+0x44/0xa0 [.] __initstub__kmod_ima__373_1201_init_ima7+0x1e/0xb0 [.] ? init_ima_lsm+0x30/0x30 [.] do_one_initcall+0xad/0x200 [.] ? idr_alloc_cyclic+0xaa/0x110 [.] ? new_slab+0x12c/0x420 [.] ? new_slab+0x12c/0x420 [.] ? number+0x12a/0x430 [.] ? sysvec_apic_timer_interrupt+0xa/0x80 [.] ? asm_sysvec_apic_timer_interrupt+0x16/0x20 [.] ? parse_args+0xd4/0x380 [.] ? parse_args+0x14b/0x380 [.] kernel_init_freeable+0x1c1/0x2b0 [.] ? rest_init+0xb0/0xb0 [.] kernel_init+0x16/0x1a0 [.] ret_from_fork+0x2f/0x40 [.] ? rest_init+0xb0/0xb0 [.] ret_from_fork_asm+0x11/0x20 [.] ", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50218", "url": "https://ubuntu.com/security/CVE-2024-50218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow Syzbot reported a kernel BUG in ocfs2_truncate_inline. There are two reasons for this: first, the parameter value passed is greater than ocfs2_max_inline_data_with_xattr, second, the start and end parameters of ocfs2_truncate_inline are \"unsigned int\". So, we need to add a sanity check for byte_start and byte_len right before ocfs2_truncate_inline() in ocfs2_remove_inode_range(), if they are greater than ocfs2_max_inline_data_with_xattr return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50219", "url": "https://ubuntu.com/security/CVE-2024-50219", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50263", "url": "https://ubuntu.com/security/CVE-2024-50263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fork: only invoke khugepaged, ksm hooks if no error There is no reason to invoke these hooks early against an mm that is in an incomplete state. The change in commit d24062914837 (\"fork: use __mt_dup() to duplicate maple tree in dup_mmap()\") makes this more pertinent as we may be in a state where entries in the maple tree are not yet consistent. Their placement early in dup_mmap() only appears to have been meaningful for early error checking, and since functionally it'd require a very small allocation to fail (in practice 'too small to fail') that'd only occur in the most dire circumstances, meaning the fork would fail or be OOM'd in any case. Since both khugepaged and KSM tracking are there to provide optimisations to memory performance rather than critical functionality, it doesn't really matter all that much if, under such dire memory pressure, we fail to register an mm with these. As a result, we follow the example of commit d2081b2bf819 (\"mm: khugepaged: make khugepaged_enter() void function\") and make ksm_fork() a void function also. We only expose the mm to these functions once we are done with them and only if no error occurred in the fork operation.", "cve_priority": "medium", "cve_public_date": "2024-11-11 14:15:00 UTC" }, { "cve": "CVE-2024-50220", "url": "https://ubuntu.com/security/CVE-2024-50220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fork: do not invoke uffd on fork if error occurs Patch series \"fork: do not expose incomplete mm on fork\". During fork we may place the virtual memory address space into an inconsistent state before the fork operation is complete. In addition, we may encounter an error during the fork operation that indicates that the virtual memory address space is invalidated. As a result, we should not be exposing it in any way to external machinery that might interact with the mm or VMAs, machinery that is not designed to deal with incomplete state. We specifically update the fork logic to defer khugepaged and ksm to the end of the operation and only to be invoked if no error arose, and disallow uffd from observing fork events should an error have occurred. This patch (of 2): Currently on fork we expose the virtual address space of a process to userland unconditionally if uffd is registered in VMAs, regardless of whether an error arose in the fork. This is performed in dup_userfaultfd_complete() which is invoked unconditionally, and performs two duties - invoking registered handlers for the UFFD_EVENT_FORK event via dup_fctx(), and clearing down userfaultfd_fork_ctx objects established in dup_userfaultfd(). This is problematic, because the virtual address space may not yet be correctly initialised if an error arose. The change in commit d24062914837 (\"fork: use __mt_dup() to duplicate maple tree in dup_mmap()\") makes this more pertinent as we may be in a state where entries in the maple tree are not yet consistent. We address this by, on fork error, ensuring that we roll back state that we would otherwise expect to clean up through the event being handled by userland and perform the memory freeing duty otherwise performed by dup_userfaultfd_complete(). We do this by implementing a new function, dup_userfaultfd_fail(), which performs the same loop, only decrementing reference counts. Note that we perform mmgrab() on the parent and child mm's, however userfaultfd_ctx_put() will mmdrop() this once the reference count drops to zero, so we will avoid memory leaks correctly here.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53047", "url": "https://ubuntu.com/security/CVE-2024-53047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: init: protect sched with rcu_read_lock Enabling CONFIG_PROVE_RCU_LIST with its dependence CONFIG_RCU_EXPERT creates this splat when an MPTCP socket is created: ============================= WARNING: suspicious RCU usage 6.12.0-rc2+ #11 Not tainted ----------------------------- net/mptcp/sched.c:44 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 no locks held by mptcp_connect/176. stack backtrace: CPU: 0 UID: 0 PID: 176 Comm: mptcp_connect Not tainted 6.12.0-rc2+ #11 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl (lib/dump_stack.c:123) lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822) mptcp_sched_find (net/mptcp/sched.c:44 (discriminator 7)) mptcp_init_sock (net/mptcp/protocol.c:2867 (discriminator 1)) ? sock_init_data_uid (arch/x86/include/asm/atomic.h:28) inet_create.part.0.constprop.0 (net/ipv4/af_inet.c:386) ? __sock_create (include/linux/rcupdate.h:347 (discriminator 1)) __sock_create (net/socket.c:1576) __sys_socket (net/socket.c:1671) ? __pfx___sys_socket (net/socket.c:1712) ? do_user_addr_fault (arch/x86/mm/fault.c:1419 (discriminator 1)) __x64_sys_socket (net/socket.c:1728) do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) That's because when the socket is initialised, rcu_read_lock() is not used despite the explicit comment written above the declaration of mptcp_sched_find() in sched.c. Adding the missing lock/unlock avoids the warning.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50221", "url": "https://ubuntu.com/security/CVE-2024-50221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Vangogh: Fix kernel memory out of bounds write KASAN reports that the GPU metrics table allocated in vangogh_tables_init() is not large enough for the memset done in smu_cmn_init_soft_gpu_metrics(). Condensed report follows: [ 33.861314] BUG: KASAN: slab-out-of-bounds in smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu] [ 33.861799] Write of size 168 at addr ffff888129f59500 by task mangoapp/1067 ... [ 33.861808] CPU: 6 UID: 1000 PID: 1067 Comm: mangoapp Tainted: G W 6.12.0-rc4 #356 1a56f59a8b5182eeaf67eb7cb8b13594dd23b544 [ 33.861816] Tainted: [W]=WARN [ 33.861818] Hardware name: Valve Galileo/Galileo, BIOS F7G0107 12/01/2023 [ 33.861822] Call Trace: [ 33.861826] [ 33.861829] dump_stack_lvl+0x66/0x90 [ 33.861838] print_report+0xce/0x620 [ 33.861853] kasan_report+0xda/0x110 [ 33.862794] kasan_check_range+0xfd/0x1a0 [ 33.862799] __asan_memset+0x23/0x40 [ 33.862803] smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.863306] vangogh_get_gpu_metrics_v2_4+0x123/0xad0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.864257] vangogh_common_get_gpu_metrics+0xb0c/0xbc0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.865682] amdgpu_dpm_get_gpu_metrics+0xcc/0x110 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.866160] amdgpu_get_gpu_metrics+0x154/0x2d0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.867135] dev_attr_show+0x43/0xc0 [ 33.867147] sysfs_kf_seq_show+0x1f1/0x3b0 [ 33.867155] seq_read_iter+0x3f8/0x1140 [ 33.867173] vfs_read+0x76c/0xc50 [ 33.867198] ksys_read+0xfb/0x1d0 [ 33.867214] do_syscall_64+0x90/0x160 ... [ 33.867353] Allocated by task 378 on cpu 7 at 22.794876s: [ 33.867358] kasan_save_stack+0x33/0x50 [ 33.867364] kasan_save_track+0x17/0x60 [ 33.867367] __kasan_kmalloc+0x87/0x90 [ 33.867371] vangogh_init_smc_tables+0x3f9/0x840 [amdgpu] [ 33.867835] smu_sw_init+0xa32/0x1850 [amdgpu] [ 33.868299] amdgpu_device_init+0x467b/0x8d90 [amdgpu] [ 33.868733] amdgpu_driver_load_kms+0x19/0xf0 [amdgpu] [ 33.869167] amdgpu_pci_probe+0x2d6/0xcd0 [amdgpu] [ 33.869608] local_pci_probe+0xda/0x180 [ 33.869614] pci_device_probe+0x43f/0x6b0 Empirically we can confirm that the former allocates 152 bytes for the table, while the latter memsets the 168 large block. Root cause appears that when GPU metrics tables for v2_4 parts were added it was not considered to enlarge the table to fit. The fix in this patch is rather \"brute force\" and perhaps later should be done in a smarter way, by extracting and consolidating the part version to size logic to a common helper, instead of brute forcing the largest possible allocation. Nevertheless, for now this works and fixes the out of bounds write. v2: * Drop impossible v3_0 case. (Mario) (cherry picked from commit 0880f58f9609f0200483a49429af0f050d281703)", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50222", "url": "https://ubuntu.com/security/CVE-2024-50222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iov_iter: fix copy_page_from_iter_atomic() if KMAP_LOCAL_FORCE_MAP generic/077 on x86_32 CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP=y with highmem, on huge=always tmpfs, issues a warning and then hangs (interruptibly): WARNING: CPU: 5 PID: 3517 at mm/highmem.c:622 kunmap_local_indexed+0x62/0xc9 CPU: 5 UID: 0 PID: 3517 Comm: cp Not tainted 6.12.0-rc4 #2 ... copy_page_from_iter_atomic+0xa6/0x5ec generic_perform_write+0xf6/0x1b4 shmem_file_write_iter+0x54/0x67 Fix copy_page_from_iter_atomic() by limiting it in that case (include/linux/skbuff.h skb_frag_must_loop() does similar). But going forward, perhaps CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP is too surprising, has outlived its usefulness, and should just be removed?", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50223", "url": "https://ubuntu.com/security/CVE-2024-50223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/numa: Fix the potential null pointer dereference in task_numa_work() When running stress-ng-vm-segv test, we found a null pointer dereference error in task_numa_work(). Here is the backtrace: [323676.066985] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ...... [323676.067108] CPU: 35 PID: 2694524 Comm: stress-ng-vm-se ...... [323676.067113] pstate: 23401009 (nzCv daif +PAN -UAO +TCO +DIT +SSBS BTYPE=--) [323676.067115] pc : vma_migratable+0x1c/0xd0 [323676.067122] lr : task_numa_work+0x1ec/0x4e0 [323676.067127] sp : ffff8000ada73d20 [323676.067128] x29: ffff8000ada73d20 x28: 0000000000000000 x27: 000000003e89f010 [323676.067130] x26: 0000000000080000 x25: ffff800081b5c0d8 x24: ffff800081b27000 [323676.067133] x23: 0000000000010000 x22: 0000000104d18cc0 x21: ffff0009f7158000 [323676.067135] x20: 0000000000000000 x19: 0000000000000000 x18: ffff8000ada73db8 [323676.067138] x17: 0001400000000000 x16: ffff800080df40b0 x15: 0000000000000035 [323676.067140] x14: ffff8000ada73cc8 x13: 1fffe0017cc72001 x12: ffff8000ada73cc8 [323676.067142] x11: ffff80008001160c x10: ffff000be639000c x9 : ffff8000800f4ba4 [323676.067145] x8 : ffff000810375000 x7 : ffff8000ada73974 x6 : 0000000000000001 [323676.067147] x5 : 0068000b33e26707 x4 : 0000000000000001 x3 : ffff0009f7158000 [323676.067149] x2 : 0000000000000041 x1 : 0000000000004400 x0 : 0000000000000000 [323676.067152] Call trace: [323676.067153] vma_migratable+0x1c/0xd0 [323676.067155] task_numa_work+0x1ec/0x4e0 [323676.067157] task_work_run+0x78/0xd8 [323676.067161] do_notify_resume+0x1ec/0x290 [323676.067163] el0_svc+0x150/0x160 [323676.067167] el0t_64_sync_handler+0xf8/0x128 [323676.067170] el0t_64_sync+0x17c/0x180 [323676.067173] Code: d2888001 910003fd f9000bf3 aa0003f3 (f9401000) [323676.067177] SMP: stopping secondary CPUs [323676.070184] Starting crashdump kernel... stress-ng-vm-segv in stress-ng is used to stress test the SIGSEGV error handling function of the system, which tries to cause a SIGSEGV error on return from unmapping the whole address space of the child process. Normally this program will not cause kernel crashes. But before the munmap system call returns to user mode, a potential task_numa_work() for numa balancing could be added and executed. In this scenario, since the child process has no vma after munmap, the vma_next() in task_numa_work() will return a null pointer even if the vma iterator restarts from 0. Recheck the vma pointer before dereferencing it in task_numa_work().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53053", "url": "https://ubuntu.com/security/CVE-2024-53053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Fix another deadlock during RTC update If ufshcd_rtc_work calls ufshcd_rpm_put_sync() and the pm's usage_count is 0, we will enter the runtime suspend callback. However, the runtime suspend callback will wait to flush ufshcd_rtc_work, causing a deadlock. Replace ufshcd_rpm_put_sync() with ufshcd_rpm_put() to avoid the deadlock.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53075", "url": "https://ubuntu.com/security/CVE-2024-53075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv: Prevent a bad reference count on CPU nodes When populating cache leaves we previously fetched the CPU device node at the very beginning. But when ACPI is enabled we go through a specific branch which returns early and does not call 'of_node_put' for the node that was acquired. Since we are not using a CPU device node for the ACPI code anyways, we can simply move the initialization of it just passed the ACPI block, and we are guaranteed to have an 'of_node_put' call for the acquired node. This prevents a bad reference count of the CPU device node. Moreover, the previous function did not check for errors when acquiring the device node, so a return -ENOENT has been added for that case.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50224", "url": "https://ubuntu.com/security/CVE-2024-50224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: spi-fsl-dspi: Fix crash when not using GPIO chip select Add check for the return value of spi_get_csgpiod() to avoid passing a NULL pointer to gpiod_direction_output(), preventing a crash when GPIO chip select is not used. Fix below crash: [ 4.251960] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 4.260762] Mem abort info: [ 4.263556] ESR = 0x0000000096000004 [ 4.267308] EC = 0x25: DABT (current EL), IL = 32 bits [ 4.272624] SET = 0, FnV = 0 [ 4.275681] EA = 0, S1PTW = 0 [ 4.278822] FSC = 0x04: level 0 translation fault [ 4.283704] Data abort info: [ 4.286583] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 4.292074] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 4.297130] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 4.302445] [0000000000000000] user address but active_mm is swapper [ 4.308805] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 4.315072] Modules linked in: [ 4.318124] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc4-next-20241023-00008-ga20ec42c5fc1 #359 [ 4.328130] Hardware name: LS1046A QDS Board (DT) [ 4.332832] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 4.339794] pc : gpiod_direction_output+0x34/0x5c [ 4.344505] lr : gpiod_direction_output+0x18/0x5c [ 4.349208] sp : ffff80008003b8f0 [ 4.352517] x29: ffff80008003b8f0 x28: 0000000000000000 x27: ffffc96bcc7e9068 [ 4.359659] x26: ffffc96bcc6e00b0 x25: ffffc96bcc598398 x24: ffff447400132810 [ 4.366800] x23: 0000000000000000 x22: 0000000011e1a300 x21: 0000000000020002 [ 4.373940] x20: 0000000000000000 x19: 0000000000000000 x18: ffffffffffffffff [ 4.381081] x17: ffff44740016e600 x16: 0000000500000003 x15: 0000000000000007 [ 4.388221] x14: 0000000000989680 x13: 0000000000020000 x12: 000000000000001e [ 4.395362] x11: 0044b82fa09b5a53 x10: 0000000000000019 x9 : 0000000000000008 [ 4.402502] x8 : 0000000000000002 x7 : 0000000000000007 x6 : 0000000000000000 [ 4.409641] x5 : 0000000000000200 x4 : 0000000002000000 x3 : 0000000000000000 [ 4.416781] x2 : 0000000000022202 x1 : 0000000000000000 x0 : 0000000000000000 [ 4.423921] Call trace: [ 4.426362] gpiod_direction_output+0x34/0x5c (P) [ 4.431067] gpiod_direction_output+0x18/0x5c (L) [ 4.435771] dspi_setup+0x220/0x334", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50225", "url": "https://ubuntu.com/security/CVE-2024-50225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix error propagation of split bios The purpose of btrfs_bbio_propagate_error() shall be propagating an error of split bio to its original btrfs_bio, and tell the error to the upper layer. However, it's not working well on some cases. * Case 1. Immediate (or quick) end_bio with an error When btrfs sends btrfs_bio to mirrored devices, btrfs calls btrfs_bio_end_io() when all the mirroring bios are completed. If that btrfs_bio was split, it is from btrfs_clone_bioset and its end_io function is btrfs_orig_write_end_io. For this case, btrfs_bbio_propagate_error() accesses the orig_bbio's bio context to increase the error count. That works well in most cases. However, if the end_io is called enough fast, orig_bbio's (remaining part after split) bio context may not be properly set at that time. Since the bio context is set when the orig_bbio (the last btrfs_bio) is sent to devices, that might be too late for earlier split btrfs_bio's completion. That will result in NULL pointer dereference. That bug is easily reproducible by running btrfs/146 on zoned devices [1] and it shows the following trace. [1] You need raid-stripe-tree feature as it create \"-d raid0 -m raid1\" FS. BUG: kernel NULL pointer dereference, address: 0000000000000020 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 UID: 0 PID: 13 Comm: kworker/u32:1 Not tainted 6.11.0-rc7-BTRFS-ZNS+ #474 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Workqueue: writeback wb_workfn (flush-btrfs-5) RIP: 0010:btrfs_bio_end_io+0xae/0xc0 [btrfs] BTRFS error (device dm-0): bdev /dev/mapper/error-test errs: wr 2, rd 0, flush 0, corrupt 0, gen 0 RSP: 0018:ffffc9000006f248 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888005a7f080 RCX: ffffc9000006f1dc RDX: 0000000000000000 RSI: 000000000000000a RDI: ffff888005a7f080 RBP: ffff888011dfc540 R08: 0000000000000000 R09: 0000000000000001 R10: ffffffff82e508e0 R11: 0000000000000005 R12: ffff88800ddfbe58 R13: ffff888005a7f080 R14: ffff888005a7f158 R15: ffff888005a7f158 FS: 0000000000000000(0000) GS:ffff88803ea80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000020 CR3: 0000000002e22006 CR4: 0000000000370ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __die_body.cold+0x19/0x26 ? page_fault_oops+0x13e/0x2b0 ? _printk+0x58/0x73 ? do_user_addr_fault+0x5f/0x750 ? exc_page_fault+0x76/0x240 ? asm_exc_page_fault+0x22/0x30 ? btrfs_bio_end_io+0xae/0xc0 [btrfs] ? btrfs_log_dev_io_error+0x7f/0x90 [btrfs] btrfs_orig_write_end_io+0x51/0x90 [btrfs] dm_submit_bio+0x5c2/0xa50 [dm_mod] ? find_held_lock+0x2b/0x80 ? blk_try_enter_queue+0x90/0x1e0 __submit_bio+0xe0/0x130 ? ktime_get+0x10a/0x160 ? lockdep_hardirqs_on+0x74/0x100 submit_bio_noacct_nocheck+0x199/0x410 btrfs_submit_bio+0x7d/0x150 [btrfs] btrfs_submit_chunk+0x1a1/0x6d0 [btrfs] ? lockdep_hardirqs_on+0x74/0x100 ? __folio_start_writeback+0x10/0x2c0 btrfs_submit_bbio+0x1c/0x40 [btrfs] submit_one_bio+0x44/0x60 [btrfs] submit_extent_folio+0x13f/0x330 [btrfs] ? btrfs_set_range_writeback+0xa3/0xd0 [btrfs] extent_writepage_io+0x18b/0x360 [btrfs] extent_write_locked_range+0x17c/0x340 [btrfs] ? __pfx_end_bbio_data_write+0x10/0x10 [btrfs] run_delalloc_cow+0x71/0xd0 [btrfs] btrfs_run_delalloc_range+0x176/0x500 [btrfs] ? find_lock_delalloc_range+0x119/0x260 [btrfs] writepage_delalloc+0x2ab/0x480 [btrfs] extent_write_cache_pages+0x236/0x7d0 [btrfs] btrfs_writepages+0x72/0x130 [btrfs] do_writepages+0xd4/0x240 ? find_held_lock+0x2b/0x80 ? wbc_attach_and_unlock_inode+0x12c/0x290 ? wbc_attach_and_unlock_inode+0x12c/0x29 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53054", "url": "https://ubuntu.com/security/CVE-2024-53054", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50226", "url": "https://ubuntu.com/security/CVE-2024-50226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cxl/port: Fix use-after-free, permit out-of-order decoder shutdown In support of investigating an initialization failure report [1], cxl_test was updated to register mock memory-devices after the mock root-port/bus device had been registered. That led to cxl_test crashing with a use-after-free bug with the following signature: cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem0:decoder7.0 @ 0 next: cxl_switch_uport.0 nr_eps: 1 nr_targets: 1 cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem4:decoder14.0 @ 1 next: cxl_switch_uport.0 nr_eps: 2 nr_targets: 1 cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[0] = cxl_switch_dport.0 for mem0:decoder7.0 @ 0 1) cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[1] = cxl_switch_dport.4 for mem4:decoder14.0 @ 1 [..] cxld_unregister: cxl decoder14.0: cxl_region_decode_reset: cxl_region region3: mock_decoder_reset: cxl_port port3: decoder3.0 reset 2) mock_decoder_reset: cxl_port port3: decoder3.0: out of order reset, expected decoder3.1 cxl_endpoint_decoder_release: cxl decoder14.0: [..] cxld_unregister: cxl decoder7.0: 3) cxl_region_decode_reset: cxl_region region3: Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6bc3: 0000 [#1] PREEMPT SMP PTI [..] RIP: 0010:to_cxl_port+0x8/0x60 [cxl_core] [..] Call Trace: cxl_region_decode_reset+0x69/0x190 [cxl_core] cxl_region_detach+0xe8/0x210 [cxl_core] cxl_decoder_kill_region+0x27/0x40 [cxl_core] cxld_unregister+0x5d/0x60 [cxl_core] At 1) a region has been established with 2 endpoint decoders (7.0 and 14.0). Those endpoints share a common switch-decoder in the topology (3.0). At teardown, 2), decoder14.0 is the first to be removed and hits the \"out of order reset case\" in the switch decoder. The effect though is that region3 cleanup is aborted leaving it in-tact and referencing decoder14.0. At 3) the second attempt to teardown region3 trips over the stale decoder14.0 object which has long since been deleted. The fix here is to recognize that the CXL specification places no mandate on in-order shutdown of switch-decoders, the driver enforces in-order allocation, and hardware enforces in-order commit. So, rather than fail and leave objects dangling, always remove them. In support of making cxl_region_decode_reset() always succeed, cxl_region_invalidate_memregion() failures are turned into warnings. Crashing the kernel is ok there since system integrity is at risk if caches cannot be managed around physical address mutation events like CXL region destruction. A new device_for_each_child_reverse_from() is added to cleanup port->commit_end after all dependent decoders have been disabled. In other words if decoders are allocated 0->1->2 and disabled 1->2->0 then port->commit_end only decrements from 2 after 2 has been disabled, and it decrements all the way to zero since 1 was disabled previously.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50227", "url": "https://ubuntu.com/security/CVE-2024-50227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Fix KASAN reported stack out-of-bounds read in tb_retimer_scan() KASAN reported following issue: BUG: KASAN: stack-out-of-bounds in tb_retimer_scan+0xffe/0x1550 [thunderbolt] Read of size 4 at addr ffff88810111fc1c by task kworker/u56:0/11 CPU: 0 UID: 0 PID: 11 Comm: kworker/u56:0 Tainted: G U 6.11.0+ #1387 Tainted: [U]=USER Workqueue: thunderbolt0 tb_handle_hotplug [thunderbolt] Call Trace: dump_stack_lvl+0x6c/0x90 print_report+0xd1/0x630 kasan_report+0xdb/0x110 __asan_report_load4_noabort+0x14/0x20 tb_retimer_scan+0xffe/0x1550 [thunderbolt] tb_scan_port+0xa6f/0x2060 [thunderbolt] tb_handle_hotplug+0x17b1/0x3080 [thunderbolt] process_one_work+0x626/0x1100 worker_thread+0x6c8/0xfa0 kthread+0x2c8/0x3a0 ret_from_fork+0x3a/0x80 ret_from_fork_asm+0x1a/0x30 This happens because the loop variable still gets incremented by one so max becomes 3 instead of 2, and this makes the second loop read past the the array declared on the stack. Fix this by assigning to max directly in the loop body.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50228", "url": "https://ubuntu.com/security/CVE-2024-50228", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50229", "url": "https://ubuntu.com/security/CVE-2024-50229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential deadlock with newly created symlinks Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers memory reclamation involving the filesystem layer, which can result in circular lock dependencies among the reader/writer semaphore nilfs->ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the fs_reclaim pseudo lock. This is because after commit 21fc61c73c39 (\"don't put symlink bodies in pagecache into highmem\"), the gfp flags of the page cache for symbolic links are overwritten to GFP_KERNEL via inode_nohighmem(). This is not a problem for symlinks read from the backing device, because the __GFP_FS flag is dropped after inode_nohighmem() is called. However, when a new symlink is created with nilfs_symlink(), the gfp flags remain overwritten to GFP_KERNEL. Then, memory allocation called from page_symlink() etc. triggers memory reclamation including the FS layer, which may call nilfs_evict_inode() or nilfs_dirty_inode(). And these can cause a deadlock if they are called while nilfs->ns_segctor_sem is held: Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags of newly created symlinks in the same way that nilfs_new_inode() and __nilfs_read_inode() do, as a workaround until we adopt nofs allocation scope consistently or improve the locking constraints.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50230", "url": "https://ubuntu.com/security/CVE-2024-50230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug due to missing clearing of checked flag Syzbot reported that in directory operations after nilfs2 detects filesystem corruption and degrades to read-only, __block_write_begin_int(), which is called to prepare block writes, may fail the BUG_ON check for accesses exceeding the folio/page size, triggering a kernel bug. This was found to be because the \"checked\" flag of a page/folio was not cleared when it was discarded by nilfs2's own routine, which causes the sanity check of directory entries to be skipped when the directory page/folio is reloaded. So, fix that. This was necessary when the use of nilfs2's own page discard routine was applied to more than just metadata files.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50231", "url": "https://ubuntu.com/security/CVE-2024-50231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gts-helper: Fix memory leaks in iio_gts_build_avail_scale_table() modprobe iio-test-gts and rmmod it, then the following memory leak occurs: \tunreferenced object 0xffffff80c810be00 (size 64): \t comm \"kunit_try_catch\", pid 1654, jiffies 4294913981 \t hex dump (first 32 bytes): \t 02 00 00 00 08 00 00 00 20 00 00 00 40 00 00 00 ........ ...@... \t 80 00 00 00 00 02 00 00 00 04 00 00 00 08 00 00 ................ \t backtrace (crc a63d875e): \t [<0000000028c1b3c2>] kmemleak_alloc+0x34/0x40 \t [<000000001d6ecc87>] __kmalloc_noprof+0x2bc/0x3c0 \t [<00000000393795c1>] devm_iio_init_iio_gts+0x4b4/0x16f4 \t [<0000000071bb4b09>] 0xffffffdf052a62e0 \t [<000000000315bc18>] 0xffffffdf052a6488 \t [<00000000f9dc55b5>] kunit_try_run_case+0x13c/0x3ac \t [<00000000175a3fd4>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000f505065d>] kthread+0x2e8/0x374 \t [<00000000bbfb0e5d>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cbfe9e70 (size 16): \t comm \"kunit_try_catch\", pid 1658, jiffies 4294914015 \t hex dump (first 16 bytes): \t 10 00 00 00 40 00 00 00 80 00 00 00 00 00 00 00 ....@........... \t backtrace (crc 857f0cb4): \t [<0000000028c1b3c2>] kmemleak_alloc+0x34/0x40 \t [<000000001d6ecc87>] __kmalloc_noprof+0x2bc/0x3c0 \t [<00000000393795c1>] devm_iio_init_iio_gts+0x4b4/0x16f4 \t [<0000000071bb4b09>] 0xffffffdf052a62e0 \t [<000000007d089d45>] 0xffffffdf052a6864 \t [<00000000f9dc55b5>] kunit_try_run_case+0x13c/0x3ac \t [<00000000175a3fd4>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000f505065d>] kthread+0x2e8/0x374 \t [<00000000bbfb0e5d>] ret_from_fork+0x10/0x20 \t...... It includes 5*5 times \"size 64\" memory leaks, which correspond to 5 times test_init_iio_gain_scale() calls with gts_test_gains size 10 (10*size(int)) and gts_test_itimes size 5. It also includes 5*1 times \"size 16\" memory leak, which correspond to one time __test_init_iio_gain_scale() call with gts_test_gains_gain_low size 3 (3*size(int)) and gts_test_itimes size 5. The reason is that the per_time_gains[i] is not freed which is allocated in the \"gts->num_itime\" for loop in iio_gts_build_avail_scale_table().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53076", "url": "https://ubuntu.com/security/CVE-2024-53076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gts-helper: Fix memory leaks for the error path of iio_gts_build_avail_scale_table() If per_time_scales[i] or per_time_gains[i] kcalloc fails in the for loop of iio_gts_build_avail_scale_table(), the err_free_out will fail to call kfree() each time when i is reduced to 0, so all the per_time_scales[0] and per_time_gains[0] will not be freed, which will cause memory leaks. Fix it by checking if i >= 0.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50232", "url": "https://ubuntu.com/security/CVE-2024-50232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr() In the ad7124_write_raw() function, parameter val can potentially be zero. This may lead to a division by zero when DIV_ROUND_CLOSEST() is called within ad7124_set_channel_odr(). The ad7124_write_raw() function is invoked through the sequence: iio_write_channel_raw() -> iio_write_channel_attribute() -> iio_channel_write(), with no checks in place to ensure val is non-zero.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50233", "url": "https://ubuntu.com/security/CVE-2024-50233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: iio: frequency: ad9832: fix division by zero in ad9832_calc_freqreg() In the ad9832_write_frequency() function, clk_get_rate() might return 0. This can lead to a division by zero when calling ad9832_calc_freqreg(). The check if (fout > (clk_get_rate(st->mclk) / 2)) does not protect against the case when fout is 0. The ad9832_write_frequency() function is called from ad9832_write(), and fout is derived from a text buffer, which can contain any value.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53055", "url": "https://ubuntu.com/security/CVE-2024-53055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix 6 GHz scan construction If more than 255 colocated APs exist for the set of all APs found during 2.4/5 GHz scanning, then the 6 GHz scan construction will loop forever since the loop variable has type u8, which can never reach the number found when that's bigger than 255, and is stored in a u32 variable. Also move it into the loops to have a smaller scope. Using a u32 there is fine, we limit the number of APs in the scan list and each has a limit on the number of RNR entries due to the frame size. With a limit of 1000 scan results, a frame size upper bound of 4096 (really it's more like ~2300) and a TBTT entry size of at least 11, we get an upper bound for the number of ~372k, well in the bounds of a u32.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50234", "url": "https://ubuntu.com/security/CVE-2024-50234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlegacy: Clear stale interrupts before resuming device iwl4965 fails upon resume from hibernation on my laptop. The reason seems to be a stale interrupt which isn't being cleared out before interrupts are enabled. We end up with a race beween the resume trying to bring things back up, and the restart work (queued form the interrupt handler) trying to bring things down. Eventually the whole thing blows up. Fix the problem by clearing out any stale interrupts before interrupts get enabled during resume. Here's a debug log of the indicent: [ 12.042589] ieee80211 phy0: il_isr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000 [ 12.042625] ieee80211 phy0: il4965_irq_tasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000 [ 12.042651] iwl4965 0000:10:00.0: RF_KILL bit toggled to enable radio. [ 12.042653] iwl4965 0000:10:00.0: On demand firmware reload [ 12.042690] ieee80211 phy0: il4965_irq_tasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282 [ 12.052207] ieee80211 phy0: il4965_mac_start enter [ 12.052212] ieee80211 phy0: il_prep_station Add STA to driver ID 31: ff:ff:ff:ff:ff:ff [ 12.052244] ieee80211 phy0: il4965_set_hw_ready hardware ready [ 12.052324] ieee80211 phy0: il_apm_init Init card's basic functions [ 12.052348] ieee80211 phy0: il_apm_init L1 Enabled; Disabling L0S [ 12.055727] ieee80211 phy0: il4965_load_bsm Begin load bsm [ 12.056140] ieee80211 phy0: il4965_verify_bsm Begin verify bsm [ 12.058642] ieee80211 phy0: il4965_verify_bsm BSM bootstrap uCode image OK [ 12.058721] ieee80211 phy0: il4965_load_bsm BSM write complete, poll 1 iterations [ 12.058734] ieee80211 phy0: __il4965_up iwl4965 is coming up [ 12.058737] ieee80211 phy0: il4965_mac_start Start UP work done. [ 12.058757] ieee80211 phy0: __il4965_down iwl4965 is going down [ 12.058761] ieee80211 phy0: il_scan_cancel_timeout Scan cancel timeout [ 12.058762] ieee80211 phy0: il_do_scan_abort Not performing scan to abort [ 12.058765] ieee80211 phy0: il_clear_ucode_stations Clearing ucode stations in driver [ 12.058767] ieee80211 phy0: il_clear_ucode_stations No active stations found to be cleared [ 12.058819] ieee80211 phy0: _il_apm_stop Stop card, put in low power state [ 12.058827] ieee80211 phy0: _il_apm_stop_master stop master [ 12.058864] ieee80211 phy0: il4965_clear_free_frames 0 frames on pre-allocated heap on clear. [ 12.058869] ieee80211 phy0: Hardware restart was requested [ 16.132299] iwl4965 0000:10:00.0: START_ALIVE timeout after 4000ms. [ 16.132303] ------------[ cut here ]------------ [ 16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue. [ 16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132390] Modules linked in: ctr ccm sch_fq_codel xt_tcpudp xt_multiport xt_state iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables binfmt_misc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdh_generic ecc iTCO_wdt i2c_dev iwl4965 iwlegacy coretemp snd_hda_codec_analog pcspkr psmouse mac80211 snd_hda_codec_generic libarc4 sdhci_pci cqhci sha256_generic sdhci libsha256 firewire_ohci snd_hda_intel snd_intel_dspcfg mmc_core snd_hda_codec snd_hwdep firewire_core led_class iosf_mbi snd_hda_core uhci_hcd lpc_ich crc_itu_t cfg80211 ehci_pci ehci_hcd snd_pcm usbcore mfd_core rfkill snd_timer snd usb_common soundcore video parport_pc parport intel_agp wmi intel_gtt backlight e1000e agpgart evdev [ 16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143 [ 16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010 [ 16.132463] Workqueue: async async_run_entry_fn [ 16.132469] RIP: 0010:ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132501] Code: da 02 00 0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50235", "url": "https://ubuntu.com/security/CVE-2024-50235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: clear wdev->cqm_config pointer on free When we free wdev->cqm_config when unregistering, we also need to clear out the pointer since the same wdev/netdev may get re-registered in another network namespace, then destroyed later, running this code again, which results in a double-free.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50236", "url": "https://ubuntu.com/security/CVE-2024-50236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: Fix memory leak in management tx In the current logic, memory is allocated for storing the MSDU context during management packet TX but this memory is not being freed during management TX completion. Similar leaks are seen in the management TX cleanup logic. Kmemleak reports this problem as below, unreferenced object 0xffffff80b64ed250 (size 16): comm \"kworker/u16:7\", pid 148, jiffies 4294687130 (age 714.199s) hex dump (first 16 bytes): 00 2b d8 d8 80 ff ff ff c4 74 e9 fd 07 00 00 00 .+.......t...... backtrace: [] __kmem_cache_alloc_node+0x1e4/0x2d8 [] kmalloc_trace+0x48/0x110 [] ath10k_wmi_tlv_op_gen_mgmt_tx_send+0xd4/0x1d8 [ath10k_core] [] ath10k_mgmt_over_wmi_tx_work+0x134/0x298 [ath10k_core] [] process_scheduled_works+0x1ac/0x400 [] worker_thread+0x208/0x328 [] kthread+0x100/0x1c0 [] ret_from_fork+0x10/0x20 Free the memory during completion and cleanup to fix the leak. Protect the mgmt_pending_tx idr_remove() operation in ath10k_wmi_tlv_op_cleanup_mgmt_tx_send() using ar->data_lock similar to other instances. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50237", "url": "https://ubuntu.com/security/CVE-2024-50237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower Avoid potentially crashing in the driver because of uninitialized private data", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50238", "url": "https://ubuntu.com/security/CVE-2024-50238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usbc: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data from the qcom-qmp-usb driver, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. This bug was later reproduced when the driver was copied to create the qmp-usbc driver. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with these drivers.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50239", "url": "https://ubuntu.com/security/CVE-2024-50239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usb-legacy: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data from the qcom-qmp-usb driver, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. This bug was later reproduced when the driver was copied to create the qmp-usb-legacy driver. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with these drivers.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50240", "url": "https://ubuntu.com/security/CVE-2024-50240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usb: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with this driver.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53077", "url": "https://ubuntu.com/security/CVE-2024-53077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpcrdma: Always release the rpcrdma_device's xa_array Dai pointed out that the xa_init_flags() in rpcrdma_add_one() needs to have a matching xa_destroy() in rpcrdma_remove_one() to release underlying memory that the xarray might have accrued during operation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50242", "url": "https://ubuntu.com/security/CVE-2024-50242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ntfs_file_release", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50243", "url": "https://ubuntu.com/security/CVE-2024-50243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix general protection fault in run_is_mapped_full Fixed deleating of a non-resident attribute in ntfs_create_inode() rollback.", "cve_priority": "low", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50244", "url": "https://ubuntu.com/security/CVE-2024-50244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ni_clear() Checking of NTFS_FLAGS_LOG_REPLAYING added to prevent access to uninitialized bitmap during replay process.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50245", "url": "https://ubuntu.com/security/CVE-2024-50245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix possible deadlock in mi_read Mutex lock with another subclass used in ni_lock_dir().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50246", "url": "https://ubuntu.com/security/CVE-2024-50246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Add rough attr alloc_size check", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50247", "url": "https://ubuntu.com/security/CVE-2024-50247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Check if more than chunk-size bytes are written A incorrectly formatted chunk may decompress into more than LZNT_CHUNK_SIZE bytes and a index out of bounds will occur in s_max_off.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50248", "url": "https://ubuntu.com/security/CVE-2024-50248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Add bounds checking to mi_enum_attr() Added bounds checking to make sure that every attr don't stray beyond valid memory region.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53078", "url": "https://ubuntu.com/security/CVE-2024-53078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Fix NULL vs IS_ERR() check in probe() The iommu_paging_domain_alloc() function doesn't return NULL pointers, it returns error pointers. Update the check to match.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53056", "url": "https://ubuntu.com/security/CVE-2024-53056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Fix potential NULL dereference in mtk_crtc_destroy() In mtk_crtc_create(), if the call to mbox_request_channel() fails then we set the \"mtk_crtc->cmdq_client.chan\" pointer to NULL. In that situation, we do not call cmdq_pkt_create(). During the cleanup, we need to check if the \"mtk_crtc->cmdq_client.chan\" is NULL first before calling cmdq_pkt_destroy(). Calling cmdq_pkt_destroy() is unnecessary if we didn't call cmdq_pkt_create() and it will result in a NULL pointer dereference.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50249", "url": "https://ubuntu.com/security/CVE-2024-50249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Make rmw_lock a raw_spin_lock The following BUG was triggered: ============================= [ BUG: Invalid wait context ] 6.12.0-rc2-XXX #406 Not tainted ----------------------------- kworker/1:1/62 is trying to lock: ffffff8801593030 (&cpc_ptr->rmw_lock){+.+.}-{3:3}, at: cpc_write+0xcc/0x370 other info that might help us debug this: context-{5:5} 2 locks held by kworker/1:1/62: #0: ffffff897ef5ec98 (&rq->__lock){-.-.}-{2:2}, at: raw_spin_rq_lock_nested+0x2c/0x50 #1: ffffff880154e238 (&sg_policy->update_lock){....}-{2:2}, at: sugov_update_shared+0x3c/0x280 stack backtrace: CPU: 1 UID: 0 PID: 62 Comm: kworker/1:1 Not tainted 6.12.0-rc2-g9654bd3e8806 #406 Workqueue: 0x0 (events) Call trace: dump_backtrace+0xa4/0x130 show_stack+0x20/0x38 dump_stack_lvl+0x90/0xd0 dump_stack+0x18/0x28 __lock_acquire+0x480/0x1ad8 lock_acquire+0x114/0x310 _raw_spin_lock+0x50/0x70 cpc_write+0xcc/0x370 cppc_set_perf+0xa0/0x3a8 cppc_cpufreq_fast_switch+0x40/0xc0 cpufreq_driver_fast_switch+0x4c/0x218 sugov_update_shared+0x234/0x280 update_load_avg+0x6ec/0x7b8 dequeue_entities+0x108/0x830 dequeue_task_fair+0x58/0x408 __schedule+0x4f0/0x1070 schedule+0x54/0x130 worker_thread+0xc0/0x2e8 kthread+0x130/0x148 ret_from_fork+0x10/0x20 sugov_update_shared() locks a raw_spinlock while cpc_write() locks a spinlock. To have a correct wait-type order, update rmw_lock to a raw spinlock and ensure that interrupts will be disabled on the CPU holding it. [ rjw: Changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50250", "url": "https://ubuntu.com/security/CVE-2024-50250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fsdax: dax_unshare_iter needs to copy entire blocks The code that copies data from srcmap to iomap in dax_unshare_iter is very very broken, which bfoster's recent fsx changes have exposed. If the pos and len passed to dax_file_unshare are not aligned to an fsblock boundary, the iter pos and length in the _iter function will reflect this unalignment. dax_iomap_direct_access always returns a pointer to the start of the kmapped fsdax page, even if its pos argument is in the middle of that page. This is catastrophic for data integrity when iter->pos is not aligned to a page, because daddr/saddr do not point to the same byte in the file as iter->pos. Hence we corrupt user data by copying it to the wrong place. If iter->pos + iomap_length() in the _iter function not aligned to a page, then we fail to copy a full block, and only partially populate the destination block. This is catastrophic for data confidentiality because we expose stale pmem contents. Fix both of these issues by aligning copy_pos/copy_len to a page boundary (remember, this is fsdax so 1 fsblock == 1 base page) so that we always copy full blocks. We're not done yet -- there's no call to invalidate_inode_pages2_range, so programs that have the file range mmap'd will continue accessing the old memory mapping after the file metadata updates have completed. Be careful with the return value -- if the unshare succeeds, we still need to return the number of bytes that the iomap iter thinks we're operating on.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50251", "url": "https://ubuntu.com/security/CVE-2024-50251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_payload: sanitize offset and length before calling skb_checksum() If access to offset + length is larger than the skbuff length, then skb_checksum() triggers BUG_ON(). skb_checksum() internally subtracts the length parameter while iterating over skbuff, BUG_ON(len) at the end of it checks that the expected length to be included in the checksum calculation is fully consumed.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50252", "url": "https://ubuntu.com/security/CVE-2024-50252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_ipip: Fix memory leak when changing remote IPv6 address The device stores IPv6 addresses that are used for encapsulation in linear memory that is managed by the driver. Changing the remote address of an ip6gre net device never worked properly, but since cited commit the following reproducer [1] would result in a warning [2] and a memory leak [3]. The problem is that the new remote address is never added by the driver to its hash table (and therefore the device) and the old address is never removed from it. Fix by programming the new address when the configuration of the ip6gre net device changes and removing the old one. If the address did not change, then the above would result in increasing the reference count of the address and then decreasing it. [1] # ip link add name bla up type ip6gre local 2001:db8:1::1 remote 2001:db8:2::1 tos inherit ttl inherit # ip link set dev bla type ip6gre remote 2001:db8:3::1 # ip link del dev bla # devlink dev reload pci/0000:01:00.0 [2] WARNING: CPU: 0 PID: 1682 at drivers/net/ethernet/mellanox/mlxsw/spectrum.c:3002 mlxsw_sp_ipv6_addr_put+0x140/0x1d0 Modules linked in: CPU: 0 UID: 0 PID: 1682 Comm: ip Not tainted 6.12.0-rc3-custom-g86b5b55bc835 #151 Hardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023 RIP: 0010:mlxsw_sp_ipv6_addr_put+0x140/0x1d0 [...] Call Trace: mlxsw_sp_router_netdevice_event+0x55f/0x1240 notifier_call_chain+0x5a/0xd0 call_netdevice_notifiers_info+0x39/0x90 unregister_netdevice_many_notify+0x63e/0x9d0 rtnl_dellink+0x16b/0x3a0 rtnetlink_rcv_msg+0x142/0x3f0 netlink_rcv_skb+0x50/0x100 netlink_unicast+0x242/0x390 netlink_sendmsg+0x1de/0x420 ____sys_sendmsg+0x2bd/0x320 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xd0 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f [3] unreferenced object 0xffff898081f597a0 (size 32): comm \"ip\", pid 1626, jiffies 4294719324 hex dump (first 32 bytes): 20 01 0d b8 00 02 00 00 00 00 00 00 00 00 00 01 ............... 21 49 61 83 80 89 ff ff 00 00 00 00 01 00 00 00 !Ia............. backtrace (crc fd9be911): [<00000000df89c55d>] __kmalloc_cache_noprof+0x1da/0x260 [<00000000ff2a1ddb>] mlxsw_sp_ipv6_addr_kvdl_index_get+0x281/0x340 [<000000009ddd445d>] mlxsw_sp_router_netdevice_event+0x47b/0x1240 [<00000000743e7757>] notifier_call_chain+0x5a/0xd0 [<000000007c7b9e13>] call_netdevice_notifiers_info+0x39/0x90 [<000000002509645d>] register_netdevice+0x5f7/0x7a0 [<00000000c2e7d2a9>] ip6gre_newlink_common.isra.0+0x65/0x130 [<0000000087cd6d8d>] ip6gre_newlink+0x72/0x120 [<000000004df7c7cc>] rtnl_newlink+0x471/0xa20 [<0000000057ed632a>] rtnetlink_rcv_msg+0x142/0x3f0 [<0000000032e0d5b5>] netlink_rcv_skb+0x50/0x100 [<00000000908bca63>] netlink_unicast+0x242/0x390 [<00000000cdbe1c87>] netlink_sendmsg+0x1de/0x420 [<0000000011db153e>] ____sys_sendmsg+0x2bd/0x320 [<000000003b6d53eb>] ___sys_sendmsg+0x9a/0xe0 [<00000000cae27c62>] __sys_sendmsg+0x7a/0xd0", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50253", "url": "https://ubuntu.com/security/CVE-2024-50253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check the validity of nr_words in bpf_iter_bits_new() Check the validity of nr_words in bpf_iter_bits_new(). Without this check, when multiplication overflow occurs for nr_bits (e.g., when nr_words = 0x0400-0001, nr_bits becomes 64), stack corruption may occur due to bpf_probe_read_kernel_common(..., nr_bytes = 0x2000-0008). Fix it by limiting the maximum value of nr_words to 511. The value is derived from the current implementation of BPF memory allocator. To ensure compatibility if the BPF memory allocator's size limitation changes in the future, use the helper bpf_mem_alloc_check_size() to check whether nr_bytes is too larger. And return -E2BIG instead of -ENOMEM for oversized nr_bytes.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50254", "url": "https://ubuntu.com/security/CVE-2024-50254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free dynamically allocated bits in bpf_iter_bits_destroy() bpf_iter_bits_destroy() uses \"kit->nr_bits <= 64\" to check whether the bits are dynamically allocated. However, the check is incorrect and may cause a kmemleak as shown below: unreferenced object 0xffff88812628c8c0 (size 32): comm \"swapper/0\", pid 1, jiffies 4294727320 hex dump (first 32 bytes): \tb0 c1 55 f5 81 88 ff ff f0 f0 f0 f0 f0 f0 f0 f0 ..U........... \tf0 f0 f0 f0 f0 f0 f0 f0 00 00 00 00 00 00 00 00 .............. backtrace (crc 781e32cc): \t[<00000000c452b4ab>] kmemleak_alloc+0x4b/0x80 \t[<0000000004e09f80>] __kmalloc_node_noprof+0x480/0x5c0 \t[<00000000597124d6>] __alloc.isra.0+0x89/0xb0 \t[<000000004ebfffcd>] alloc_bulk+0x2af/0x720 \t[<00000000d9c10145>] prefill_mem_cache+0x7f/0xb0 \t[<00000000ff9738ff>] bpf_mem_alloc_init+0x3e2/0x610 \t[<000000008b616eac>] bpf_global_ma_init+0x19/0x30 \t[<00000000fc473efc>] do_one_initcall+0xd3/0x3c0 \t[<00000000ec81498c>] kernel_init_freeable+0x66a/0x940 \t[<00000000b119f72f>] kernel_init+0x20/0x160 \t[<00000000f11ac9a7>] ret_from_fork+0x3c/0x70 \t[<0000000004671da4>] ret_from_fork_asm+0x1a/0x30 That is because nr_bits will be set as zero in bpf_iter_bits_next() after all bits have been iterated. Fix the issue by setting kit->bit to kit->nr_bits instead of setting kit->nr_bits to zero when the iteration completes in bpf_iter_bits_next(). In addition, use \"!nr_bits || bits >= nr_bits\" to check whether the iteration is complete and still use \"nr_bits > 64\" to indicate whether bits are dynamically allocated. The \"!nr_bits\" check is necessary because bpf_iter_bits_new() may fail before setting kit->nr_bits, and this condition will stop the iteration early instead of accessing the zeroed or freed kit->bits. Considering the initial value of kit->bits is -1 and the type of kit->nr_bits is unsigned int, change the type of kit->nr_bits to int. The potential overflow problem will be handled in the following patch.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50255", "url": "https://ubuntu.com/security/CVE-2024-50255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci: fix null-ptr-deref in hci_read_supported_codecs Fix __hci_cmd_sync_sk() to return not NULL for unknown opcodes. __hci_cmd_sync_sk() returns NULL if a command returns a status event. However, it also returns NULL where an opcode doesn't exist in the hci_cc table because hci_cmd_complete_evt() assumes status = skb->data[0] for unknown opcodes. This leads to null-ptr-deref in cmd_sync for HCI_OP_READ_LOCAL_CODECS as there is no hci_cc for HCI_OP_READ_LOCAL_CODECS, which always assumes status = skb->data[0]. KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077] CPU: 1 PID: 2000 Comm: kworker/u9:5 Not tainted 6.9.0-ga6bcb805883c-dirty #10 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: hci7 hci_power_on RIP: 0010:hci_read_supported_codecs+0xb9/0x870 net/bluetooth/hci_codec.c:138 Code: 08 48 89 ef e8 b8 c1 8f fd 48 8b 75 00 e9 96 00 00 00 49 89 c6 48 ba 00 00 00 00 00 fc ff df 4c 8d 60 70 4c 89 e3 48 c1 eb 03 <0f> b6 04 13 84 c0 0f 85 82 06 00 00 41 83 3c 24 02 77 0a e8 bf 78 RSP: 0018:ffff888120bafac8 EFLAGS: 00010212 RAX: 0000000000000000 RBX: 000000000000000e RCX: ffff8881173f0040 RDX: dffffc0000000000 RSI: ffffffffa58496c0 RDI: ffff88810b9ad1e4 RBP: ffff88810b9ac000 R08: ffffffffa77882a7 R09: 1ffffffff4ef1054 R10: dffffc0000000000 R11: fffffbfff4ef1055 R12: 0000000000000070 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88810b9ac000 FS: 0000000000000000(0000) GS:ffff8881f6c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6ddaa3439e CR3: 0000000139764003 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: hci_read_local_codecs_sync net/bluetooth/hci_sync.c:4546 [inline] hci_init_stage_sync net/bluetooth/hci_sync.c:3441 [inline] hci_init4_sync net/bluetooth/hci_sync.c:4706 [inline] hci_init_sync net/bluetooth/hci_sync.c:4742 [inline] hci_dev_init_sync net/bluetooth/hci_sync.c:4912 [inline] hci_dev_open_sync+0x19a9/0x2d30 net/bluetooth/hci_sync.c:4994 hci_dev_do_open net/bluetooth/hci_core.c:483 [inline] hci_power_on+0x11e/0x560 net/bluetooth/hci_core.c:1015 process_one_work kernel/workqueue.c:3267 [inline] process_scheduled_works+0x8ef/0x14f0 kernel/workqueue.c:3348 worker_thread+0x91f/0xe50 kernel/workqueue.c:3429 kthread+0x2cb/0x360 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50256", "url": "https://ubuntu.com/security/CVE-2024-50256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6() I got a syzbot report without a repro [1] crashing in nf_send_reset6() I think the issue is that dev->hard_header_len is zero, and we attempt later to push an Ethernet header. Use LL_MAX_HEADER, as other functions in net/ipv6/netfilter/nf_reject_ipv6.c. [1] skbuff: skb_under_panic: text:ffffffff89b1d008 len:74 put:14 head:ffff88803123aa00 data:ffff88803123a9f2 tail:0x3c end:0x140 dev:syz_tun kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 UID: 0 PID: 7373 Comm: syz.1.568 Not tainted 6.12.0-rc2-syzkaller-00631-g6d858708d465 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:skb_panic net/core/skbuff.c:206 [inline] RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216 Code: 0d 8d 48 c7 c6 60 a6 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 ba 30 38 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP: 0018:ffffc900045269b0 EFLAGS: 00010282 RAX: 0000000000000088 RBX: dffffc0000000000 RCX: cd66dacdc5d8e800 RDX: 0000000000000000 RSI: 0000000000000200 RDI: 0000000000000000 RBP: ffff88802d39a3d0 R08: ffffffff8174afec R09: 1ffff920008a4ccc R10: dffffc0000000000 R11: fffff520008a4ccd R12: 0000000000000140 R13: ffff88803123aa00 R14: ffff88803123a9f2 R15: 000000000000003c FS: 00007fdbee5ff6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000005d322000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: skb_push+0xe5/0x100 net/core/skbuff.c:2636 eth_header+0x38/0x1f0 net/ethernet/eth.c:83 dev_hard_header include/linux/netdevice.h:3208 [inline] nf_send_reset6+0xce6/0x1270 net/ipv6/netfilter/nf_reject_ipv6.c:358 nft_reject_inet_eval+0x3b9/0x690 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x418/0x6b0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] br_nf_pre_routing_ipv6+0x63e/0x770 net/bridge/br_netfilter_ipv6.c:184 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_bridge_pre net/bridge/br_input.c:277 [inline] br_handle_frame+0x9fd/0x1530 net/bridge/br_input.c:424 __netif_receive_skb_core+0x13e8/0x4570 net/core/dev.c:5562 __netif_receive_skb_one_core net/core/dev.c:5666 [inline] __netif_receive_skb+0x12f/0x650 net/core/dev.c:5781 netif_receive_skb_internal net/core/dev.c:5867 [inline] netif_receive_skb+0x1e8/0x890 net/core/dev.c:5926 tun_rx_batched+0x1b7/0x8f0 drivers/net/tun.c:1550 tun_get_user+0x3056/0x47e0 drivers/net/tun.c:2007 tun_chr_write_iter+0x10d/0x1f0 drivers/net/tun.c:2053 new_sync_write fs/read_write.c:590 [inline] vfs_write+0xa6d/0xc90 fs/read_write.c:683 ksys_write+0x183/0x2b0 fs/read_write.c:736 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:0x7fdbeeb7d1ff Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 c9 8d 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 1c 8e 02 00 48 RSP: 002b:00007fdbee5ff000 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fdbeed36058 RCX: 00007fdbeeb7d1ff RDX: 000000000000008e RSI: 0000000020000040 RDI: 00000000000000c8 RBP: 00007fdbeebf12be R08: 0000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50257", "url": "https://ubuntu.com/security/CVE-2024-50257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: Fix use-after-free in get_info() ip6table_nat module unload has refcnt warning for UAF. call trace is: WARNING: CPU: 1 PID: 379 at kernel/module/main.c:853 module_put+0x6f/0x80 Modules linked in: ip6table_nat(-) CPU: 1 UID: 0 PID: 379 Comm: ip6tables Not tainted 6.12.0-rc4-00047-gc2ee9f594da8-dirty #205 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:module_put+0x6f/0x80 Call Trace: get_info+0x128/0x180 do_ip6t_get_ctl+0x6a/0x430 nf_getsockopt+0x46/0x80 ipv6_getsockopt+0xb9/0x100 rawv6_getsockopt+0x42/0x190 do_sock_getsockopt+0xaa/0x180 __sys_getsockopt+0x70/0xc0 __x64_sys_getsockopt+0x20/0x30 do_syscall_64+0xa2/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Concurrent execution of module unload and get_info() trigered the warning. The root cause is as follows: cpu0\t\t\t\t cpu1 module_exit //mod->state = MODULE_STATE_GOING ip6table_nat_exit xt_unregister_template \tkfree(t) \t//removed from templ_list \t\t\t\t getinfo() \t\t\t\t\t t = xt_find_table_lock \t\t\t\t\t\tlist_for_each_entry(tmpl, &xt_templates[af]...) \t\t\t\t\t\t\tif (strcmp(tmpl->name, name)) \t\t\t\t\t\t\t\tcontinue; //table not found \t\t\t\t\t\t\ttry_module_get \t\t\t\t\t\tlist_for_each_entry(t, &xt_net->tables[af]...) \t\t\t\t\t\t\treturn t; //not get refcnt \t\t\t\t\t module_put(t->me) //uaf unregister_pernet_subsys //remove table from xt_net list While xt_table module was going away and has been removed from xt_templates list, we couldnt get refcnt of xt_table->me. Check module in xt_net->tables list re-traversal to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50258", "url": "https://ubuntu.com/security/CVE-2024-50258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix crash when config small gso_max_size/gso_ipv4_max_size Config a small gso_max_size/gso_ipv4_max_size will lead to an underflow in sk_dst_gso_max_size(), which may trigger a BUG_ON crash, because sk->sk_gso_max_size would be much bigger than device limits. Call Trace: tcp_write_xmit tso_segs = tcp_init_tso_segs(skb, mss_now); tcp_set_skb_tso_segs tcp_skb_pcount_set // skb->len = 524288, mss_now = 8 // u16 tso_segs = 524288/8 = 65535 -> 0 tso_segs = DIV_ROUND_UP(skb->len, mss_now) BUG_ON(!tso_segs) Add check for the minimum value of gso_max_size and gso_ipv4_max_size.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50262", "url": "https://ubuntu.com/security/CVE-2024-50262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix out-of-bounds write in trie_get_next_key() trie_get_next_key() allocates a node stack with size trie->max_prefixlen, while it writes (trie->max_prefixlen + 1) nodes to the stack when it has full paths from the root to leaves. For example, consider a trie with max_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ... 0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with .prefixlen = 8 make 9 nodes be written on the node stack with size 8.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53044", "url": "https://ubuntu.com/security/CVE-2024-53044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_api: fix xa_insert() error path in tcf_block_get_ext() This command: $ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact Error: block dev insert failed: -EBUSY. fails because user space requests the same block index to be set for both ingress and egress. [ side note, I don't think it even failed prior to commit 913b47d3424e (\"net/sched: Introduce tc block netdev tracking infra\"), because this is a command from an old set of notes of mine which used to work, but alas, I did not scientifically bisect this ] The problem is not that it fails, but rather, that the second time around, it fails differently (and irrecoverably): $ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact Error: dsa_core: Flow block cb is busy. [ another note: the extack is added by me for illustration purposes. the context of the problem is that clsact_init() obtains the same &q->ingress_block pointer as &q->egress_block, and since we call tcf_block_get_ext() on both of them, \"dev\" will be added to the block->ports xarray twice, thus failing the operation: once through the ingress block pointer, and once again through the egress block pointer. the problem itself is that when xa_insert() fails, we have emitted a FLOW_BLOCK_BIND command through ndo_setup_tc(), but the offload never sees a corresponding FLOW_BLOCK_UNBIND. ] Even correcting the bad user input, we still cannot recover: $ tc qdisc replace dev swp3 ingress_block 1 egress_block 2 clsact Error: dsa_core: Flow block cb is busy. Basically the only way to recover is to reboot the system, or unbind and rebind the net device driver. To fix the bug, we need to fill the correct error teardown path which was missed during code movement, and call tcf_block_offload_unbind() when xa_insert() fails. [ last note, fundamentally I blame the label naming convention in tcf_block_get_ext() for the bug. The labels should be named after what they do, not after the error path that jumps to them. This way, it is obviously wrong that two labels pointing to the same code mean something is wrong, and checking the code correctness at the goto site is also easier ]", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50259", "url": "https://ubuntu.com/security/CVE-2024-50259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netdevsim: Add trailing zero to terminate the string in nsim_nexthop_bucket_activity_write() This was found by a static analyzer. We should not forget the trailing zero after copy_from_user() if we will further do some string operations, sscanf() in this case. Adding a trailing zero will ensure that the function performs properly.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50304", "url": "https://ubuntu.com/security/CVE-2024-50304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find() The per-netns IP tunnel hash table is protected by the RTNL mutex and ip_tunnel_find() is only called from the control path where the mutex is taken. Add a lockdep expression to hlist_for_each_entry_rcu() in ip_tunnel_find() in order to validate that the mutex is held and to silence the suspicious RCU usage warning [1]. [1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gd95d9a31aceb #139 Not tainted ----------------------------- net/ipv4/ip_tunnel.c:221 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/362: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60 stack backtrace: CPU: 12 UID: 0 PID: 362 Comm: ip Not tainted 6.12.0-rc3-custom-gd95d9a31aceb #139 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 ip_tunnel_find+0x435/0x4d0 ip_tunnel_newlink+0x517/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53042", "url": "https://ubuntu.com/security/CVE-2024-53042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_init_flow() There are code paths from which the function is called without holding the RCU read lock, resulting in a suspicious RCU usage warning [1]. Fix by using l3mdev_master_upper_ifindex_by_index() which will acquire the RCU read lock before calling l3mdev_master_upper_ifindex_by_index_rcu(). [1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gac8f72681cf2 #141 Not tainted ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/361: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60 stack backtrace: CPU: 3 UID: 0 PID: 361 Comm: ip Not tainted 6.12.0-rc3-custom-gac8f72681cf2 #141 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 dev_get_by_index_rcu+0x1d3/0x210 l3mdev_master_upper_ifindex_by_index_rcu+0x2b/0xf0 ip_tunnel_bind_dev+0x72f/0xa00 ip_tunnel_newlink+0x368/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53048", "url": "https://ubuntu.com/security/CVE-2024-53048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix crash on probe for DPLL enabled E810 LOM The E810 Lan On Motherboard (LOM) design is vendor specific. Intel provides the reference design, but it is up to vendor on the final product design. For some cases, like Linux DPLL support, the static values defined in the driver does not reflect the actual LOM design. Current implementation of dpll pins is causing the crash on probe of the ice driver for such DPLL enabled E810 LOM designs: WARNING: (...) at drivers/dpll/dpll_core.c:495 dpll_pin_get+0x2c4/0x330 ... Call Trace: ? __warn+0x83/0x130 ? dpll_pin_get+0x2c4/0x330 ? report_bug+0x1b7/0x1d0 ? handle_bug+0x42/0x70 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? dpll_pin_get+0x117/0x330 ? dpll_pin_get+0x2c4/0x330 ? dpll_pin_get+0x117/0x330 ice_dpll_get_pins.isra.0+0x52/0xe0 [ice] ... The number of dpll pins enabled by LOM vendor is greater than expected and defined in the driver for Intel designed NICs, which causes the crash. Prevent the crash and allow generic pin initialization within Linux DPLL subsystem for DPLL enabled E810 LOM designs. Newly designed solution for described issue will be based on \"per HW design\" pin initialization. It requires pin information dynamically acquired from the firmware and is already in progress, planned for next-tree only.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53058", "url": "https://ubuntu.com/security/CVE-2024-53058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data In case the non-paged data of a SKB carries protocol header and protocol payload to be transmitted on a certain platform that the DMA AXI address width is configured to 40-bit/48-bit, or the size of the non-paged data is bigger than TSO_MAX_BUFF_SIZE on a certain platform that the DMA AXI address width is configured to 32-bit, then this SKB requires at least two DMA transmit descriptors to serve it. For example, three descriptors are allocated to split one DMA buffer mapped from one piece of non-paged data: dma_desc[N + 0], dma_desc[N + 1], dma_desc[N + 2]. Then three elements of tx_q->tx_skbuff_dma[] will be allocated to hold extra information to be reused in stmmac_tx_clean(): tx_q->tx_skbuff_dma[N + 0], tx_q->tx_skbuff_dma[N + 1], tx_q->tx_skbuff_dma[N + 2]. Now we focus on tx_q->tx_skbuff_dma[entry].buf, which is the DMA buffer address returned by DMA mapping call. stmmac_tx_clean() will try to unmap the DMA buffer _ONLY_IF_ tx_q->tx_skbuff_dma[entry].buf is a valid buffer address. The expected behavior that saves DMA buffer address of this non-paged data to tx_q->tx_skbuff_dma[entry].buf is: tx_q->tx_skbuff_dma[N + 0].buf = NULL; tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = dma_map_single(); Unfortunately, the current code misbehaves like this: tx_q->tx_skbuff_dma[N + 0].buf = dma_map_single(); tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = NULL; On the stmmac_tx_clean() side, when dma_desc[N + 0] is closed by the DMA engine, tx_q->tx_skbuff_dma[N + 0].buf is a valid buffer address obviously, then the DMA buffer will be unmapped immediately. There may be a rare case that the DMA engine does not finish the pending dma_desc[N + 1], dma_desc[N + 2] yet. Now things will go horribly wrong, DMA is going to access a unmapped/unreferenced memory region, corrupted data will be transmited or iommu fault will be triggered :( In contrast, the for-loop that maps SKB fragments behaves perfectly as expected, and that is how the driver should do for both non-paged data and paged frags actually. This patch corrects DMA map/unmap sequences by fixing the array index for tx_q->tx_skbuff_dma[entry].buf when assigning DMA buffer address. Tested and verified on DWXGMAC CORE 3.20a", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50260", "url": "https://ubuntu.com/security/CVE-2024-50260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sock_map: fix a NULL pointer dereference in sock_map_link_update_prog() The following race condition could trigger a NULL pointer dereference: sock_map_link_detach():\t\tsock_map_link_update_prog(): mutex_lock(&sockmap_mutex); ... sockmap_link->map = NULL; mutex_unlock(&sockmap_mutex); \t\t\t\t mutex_lock(&sockmap_mutex); \t\t\t\t ... \t\t\t\t sock_map_prog_link_lookup(sockmap_link->map); \t\t\t\t mutex_unlock(&sockmap_mutex); Fix it by adding a NULL pointer check. In this specific case, it makes no sense to update a link which is being released.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53045", "url": "https://ubuntu.com/security/CVE-2024-53045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: dapm: fix bounds checker error in dapm_widget_list_create The widgets array in the snd_soc_dapm_widget_list has a __counted_by attribute attached to it, which points to the num_widgets variable. This attribute is used in bounds checking, and if it is not set before the array is filled, then the bounds sanitizer will issue a warning or a kernel panic if CONFIG_UBSAN_TRAP is set. This patch sets the size of the widgets list calculated with list_for_each as the initial value for num_widgets as it is used for allocating memory for the array. It is updated with the actual number of added elements after the array is filled.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50261", "url": "https://ubuntu.com/security/CVE-2024-50261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macsec: Fix use-after-free while sending the offloading packet KASAN reports the following UAF. The metadata_dst, which is used to store the SCI value for macsec offload, is already freed by metadata_dst_free() in macsec_free_netdev(), while driver still use it for sending the packet. To fix this issue, dst_release() is used instead to release metadata_dst. So it is not freed instantly in macsec_free_netdev() if still referenced by skb. BUG: KASAN: slab-use-after-free in mlx5e_xmit+0x1e8f/0x4190 [mlx5_core] Read of size 2 at addr ffff88813e42e038 by task kworker/7:2/714 [...] Workqueue: mld mld_ifc_work Call Trace: dump_stack_lvl+0x51/0x60 print_report+0xc1/0x600 kasan_report+0xab/0xe0 mlx5e_xmit+0x1e8f/0x4190 [mlx5_core] dev_hard_start_xmit+0x120/0x530 sch_direct_xmit+0x149/0x11e0 __qdisc_run+0x3ad/0x1730 __dev_queue_xmit+0x1196/0x2ed0 vlan_dev_hard_start_xmit+0x32e/0x510 [8021q] dev_hard_start_xmit+0x120/0x530 __dev_queue_xmit+0x14a7/0x2ed0 macsec_start_xmit+0x13e9/0x2340 dev_hard_start_xmit+0x120/0x530 __dev_queue_xmit+0x14a7/0x2ed0 ip6_finish_output2+0x923/0x1a70 ip6_finish_output+0x2d7/0x970 ip6_output+0x1ce/0x3a0 NF_HOOK.constprop.0+0x15f/0x190 mld_sendpack+0x59a/0xbd0 mld_ifc_work+0x48a/0xa80 process_one_work+0x5aa/0xe50 worker_thread+0x79c/0x1290 kthread+0x28f/0x350 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x11/0x20 Allocated by task 3922: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 __kasan_kmalloc+0x77/0x90 __kmalloc_noprof+0x188/0x400 metadata_dst_alloc+0x1f/0x4e0 macsec_newlink+0x914/0x1410 __rtnl_newlink+0xe08/0x15b0 rtnl_newlink+0x5f/0x90 rtnetlink_rcv_msg+0x667/0xa80 netlink_rcv_skb+0x12c/0x360 netlink_unicast+0x551/0x770 netlink_sendmsg+0x72d/0xbd0 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x52e/0x6a0 ___sys_sendmsg+0xeb/0x170 __sys_sendmsg+0xb5/0x140 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Freed by task 4011: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x50 poison_slab_object+0x10c/0x190 __kasan_slab_free+0x11/0x30 kfree+0xe0/0x290 macsec_free_netdev+0x3f/0x140 netdev_run_todo+0x450/0xc70 rtnetlink_rcv_msg+0x66f/0xa80 netlink_rcv_skb+0x12c/0x360 netlink_unicast+0x551/0x770 netlink_sendmsg+0x72d/0xbd0 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x52e/0x6a0 ___sys_sendmsg+0xeb/0x170 __sys_sendmsg+0xb5/0x140 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53059", "url": "https://ubuntu.com/security/CVE-2024-53059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd() 1. The size of the response packet is not validated. 2. The response buffer is not freed. Resolve these issues by switching to iwl_mvm_send_cmd_status(), which handles both size validation and frees the buffer.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53074", "url": "https://ubuntu.com/security/CVE-2024-53074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: don't leak a link on AP removal Release the link mapping resource in AP removal. This impacted devices that do not support the MLD API (9260 and down). On those devices, we couldn't start the AP again after the AP has been already started and stopped.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53049", "url": "https://ubuntu.com/security/CVE-2024-53049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slub/kunit: fix a WARNING due to unwrapped __kmalloc_cache_noprof 'modprobe slub_kunit' will have a warning as shown below. The root cause is that __kmalloc_cache_noprof was directly used, which resulted in no alloc_tag being allocated. This caused current->alloc_tag to be null, leading to a warning in alloc_tag_add_check. Let's add an alloc_hook layer to __kmalloc_cache_noprof specifically within lib/slub_kunit.c, which is the only user of this internal slub function outside kmalloc implementation itself. [58162.947016] WARNING: CPU: 2 PID: 6210 at ./include/linux/alloc_tag.h:125 alloc_tagging_slab_alloc_hook+0x268/0x27c [58162.957721] Call trace: [58162.957919] alloc_tagging_slab_alloc_hook+0x268/0x27c [58162.958286] __kmalloc_cache_noprof+0x14c/0x344 [58162.958615] test_kmalloc_redzone_access+0x50/0x10c [slub_kunit] [58162.959045] kunit_try_run_case+0x74/0x184 [kunit] [58162.959401] kunit_generic_run_threadfn_adapter+0x2c/0x4c [kunit] [58162.959841] kthread+0x10c/0x118 [58162.960093] ret_from_fork+0x10/0x20 [58162.960363] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50192", "url": "https://ubuntu.com/security/CVE-2024-50192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v4: Don't allow a VMOVP on a dying VPE Kunkun Jiang reported that there is a small window of opportunity for userspace to force a change of affinity for a VPE while the VPE has already been unmapped, but the corresponding doorbell interrupt still visible in /proc/irq/. Plug the race by checking the value of vmapp_count, which tracks whether the VPE is mapped ot not, and returning an error in this case. This involves making vmapp_count common to both GICv4.1 and its v4.0 ancestor.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50069", "url": "https://ubuntu.com/security/CVE-2024-50069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: apple: check devm_kasprintf() returned value devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked. Fix this lack and check the returned value. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50070", "url": "https://ubuntu.com/security/CVE-2024-50070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: stm32: check devm_kasprintf() returned value devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked. Fix this lack and check the returned value. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50196", "url": "https://ubuntu.com/security/CVE-2024-50196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: ocelot: fix system hang on level based interrupts The current implementation only calls chained_irq_enter() and chained_irq_exit() if it detects pending interrupts. ``` for (i = 0; i < info->stride; i++) { \turegmap_read(info->map, id_reg + 4 * i, ®); \tif (!reg) \t\tcontinue; \tchained_irq_enter(parent_chip, desc); ``` However, in case of GPIO pin configured in level mode and the parent controller configured in edge mode, GPIO interrupt might be lowered by the hardware. In the result, if the interrupt is short enough, the parent interrupt is still pending while the GPIO interrupt is cleared; chained_irq_enter() never gets called and the system hangs trying to service the parent interrupt. Moving chained_irq_enter() and chained_irq_exit() outside the for loop ensures that they are called even when GPIO interrupt is lowered by the hardware. The similar code with chained_irq_enter() / chained_irq_exit() functions wrapping interrupt checking loop may be found in many other drivers: ``` grep -r -A 10 chained_irq_enter drivers/pinctrl ```", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50197", "url": "https://ubuntu.com/security/CVE-2024-50197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: intel: platform: fix error path in device_for_each_child_node() The device_for_each_child_node() loop requires calls to fwnode_handle_put() upon early returns to decrement the refcount of the child node and avoid leaking memory if that error path is triggered. There is one early returns within that loop in intel_platform_pinctrl_prepare_community(), but fwnode_handle_put() is missing. Instead of adding the missing call, the scoped version of the loop can be used to simplify the code and avoid mistakes in the future if new early returns are added, as the child node is only used for parsing, and it is never assigned.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50071", "url": "https://ubuntu.com/security/CVE-2024-50071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: nuvoton: fix a double free in ma35_pinctrl_dt_node_to_map_func() 'new_map' is allocated using devm_* which takes care of freeing the allocated data on device removal, call to \t.dt_free_map = pinconf_generic_dt_free_map double frees the map as pinconf_generic_dt_free_map() calls pinctrl_utils_free_map(). Fix this by using kcalloc() instead of auto-managed devm_kcalloc().", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50072", "url": "https://ubuntu.com/security/CVE-2024-50072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/bugs: Use code segment selector for VERW operand Robert Gill reported below #GP in 32-bit mode when dosemu software was executing vm86() system call: general protection fault: 0000 [#1] PREEMPT SMP CPU: 4 PID: 4610 Comm: dosemu.bin Not tainted 6.6.21-gentoo-x86 #1 Hardware name: Dell Inc. PowerEdge 1950/0H723K, BIOS 2.7.0 10/30/2010 EIP: restore_all_switch_stack+0xbe/0xcf EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000 ESI: 00000000 EDI: 00000000 EBP: 00000000 ESP: ff8affdc DS: 0000 ES: 0000 FS: 0000 GS: 0033 SS: 0068 EFLAGS: 00010046 CR0: 80050033 CR2: 00c2101c CR3: 04b6d000 CR4: 000406d0 Call Trace: show_regs+0x70/0x78 die_addr+0x29/0x70 exc_general_protection+0x13c/0x348 exc_bounds+0x98/0x98 handle_exception+0x14d/0x14d exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf This only happens in 32-bit mode when VERW based mitigations like MDS/RFDS are enabled. This is because segment registers with an arbitrary user value can result in #GP when executing VERW. Intel SDM vol. 2C documents the following behavior for VERW instruction: #GP(0) - If a memory operand effective address is outside the CS, DS, ES, \t FS, or GS segment limit. CLEAR_CPU_BUFFERS macro executes VERW instruction before returning to user space. Use %cs selector to reference VERW operand. This ensures VERW will not #GP for an arbitrary user %ds. [ mingo: Fixed the SOB chain. ]", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50073", "url": "https://ubuntu.com/security/CVE-2024-50073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: Fix use-after-free in gsm_cleanup_mux BUG: KASAN: slab-use-after-free in gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] Read of size 8 at addr ffff88815fe99c00 by task poc/3379 CPU: 0 UID: 0 PID: 3379 Comm: poc Not tainted 6.11.0+ #56 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] __pfx_gsm_cleanup_mux+0x10/0x10 drivers/tty/n_gsm.c:3124 [n_gsm] __pfx_sched_clock_cpu+0x10/0x10 kernel/sched/clock.c:389 update_load_avg+0x1c1/0x27b0 kernel/sched/fair.c:4500 __pfx_min_vruntime_cb_rotate+0x10/0x10 kernel/sched/fair.c:846 __rb_insert_augmented+0x492/0xbf0 lib/rbtree.c:161 gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] _raw_spin_lock_irqsave+0x92/0xf0 arch/x86/include/asm/atomic.h:107 __pfx_gsmld_ioctl+0x10/0x10 drivers/tty/n_gsm.c:3822 [n_gsm] ktime_get+0x5e/0x140 kernel/time/timekeeping.c:195 ldsem_down_read+0x94/0x4e0 arch/x86/include/asm/atomic64_64.h:79 __pfx_ldsem_down_read+0x10/0x10 drivers/tty/tty_ldsem.c:338 __pfx_do_vfs_ioctl+0x10/0x10 fs/ioctl.c:805 tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 Allocated by task 65: gsm_data_alloc.constprop.0+0x27/0x190 drivers/tty/n_gsm.c:926 [n_gsm] gsm_send+0x2c/0x580 drivers/tty/n_gsm.c:819 [n_gsm] gsm1_receive+0x547/0xad0 drivers/tty/n_gsm.c:3038 [n_gsm] gsmld_receive_buf+0x176/0x280 drivers/tty/n_gsm.c:3609 [n_gsm] tty_ldisc_receive_buf+0x101/0x1e0 drivers/tty/tty_buffer.c:391 tty_port_default_receive_buf+0x61/0xa0 drivers/tty/tty_port.c:39 flush_to_ldisc+0x1b0/0x750 drivers/tty/tty_buffer.c:445 process_scheduled_works+0x2b0/0x10d0 kernel/workqueue.c:3229 worker_thread+0x3dc/0x950 kernel/workqueue.c:3391 kthread+0x2a3/0x370 kernel/kthread.c:389 ret_from_fork+0x2d/0x70 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:257 Freed by task 3367: kfree+0x126/0x420 mm/slub.c:4580 gsm_cleanup_mux+0x36c/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 [Analysis] gsm_msg on the tx_ctrl_list or tx_data_list of gsm_mux can be freed by multi threads through ioctl,which leads to the occurrence of uaf. Protect it by gsm tx lock.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50193", "url": "https://ubuntu.com/security/CVE-2024-50193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/entry_32: Clear CPU buffers after register restore in NMI return CPU buffers are currently cleared after call to exc_nmi, but before register state is restored. This may be okay for MDS mitigation but not for RDFS. Because RDFS mitigation requires CPU buffers to be cleared when registers don't have any sensitive data. Move CLEAR_CPU_BUFFERS after RESTORE_ALL_NMI.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50074", "url": "https://ubuntu.com/security/CVE-2024-50074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: parport: Proper fix for array out-of-bounds access The recent fix for array out-of-bounds accesses replaced sprintf() calls blindly with snprintf(). However, since snprintf() returns the would-be-printed size, not the actually output size, the length calculation can still go over the given limit. Use scnprintf() instead of snprintf(), which returns the actually output letters, for addressing the potential out-of-bounds access properly.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50100", "url": "https://ubuntu.com/security/CVE-2024-50100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: gadget: dummy-hcd: Fix \"task hung\" problem The syzbot fuzzer has been encountering \"task hung\" problems ever since the dummy-hcd driver was changed to use hrtimers instead of regular timers. It turns out that the problems are caused by a subtle difference between the timer_pending() and hrtimer_active() APIs. The changeover blindly replaced the first by the second. However, timer_pending() returns True when the timer is queued but not when its callback is running, whereas hrtimer_active() returns True when the hrtimer is queued _or_ its callback is running. This difference occasionally caused dummy_urb_enqueue() to think that the callback routine had not yet started when in fact it was almost finished. As a result the hrtimer was not restarted, which made it impossible for the driver to dequeue later the URB that was just enqueued. This caused usb_kill_urb() to hang, and things got worse from there. Since hrtimers have no API for telling when they are queued and the callback isn't running, the driver must keep track of this for itself. That's what this patch does, adding a new \"timer_pending\" flag and setting or clearing it at the appropriate times.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50075", "url": "https://ubuntu.com/security/CVE-2024-50075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xhci: tegra: fix checked USB2 port number If USB virtualizatoin is enabled, USB2 ports are shared between all Virtual Functions. The USB2 port number owned by an USB2 root hub in a Virtual Function may be less than total USB2 phy number supported by the Tegra XUSB controller. Using total USB2 phy number as port number to check all PORTSC values would cause invalid memory access. [ 116.923438] Unable to handle kernel paging request at virtual address 006c622f7665642f ... [ 117.213640] Call trace: [ 117.216783] tegra_xusb_enter_elpg+0x23c/0x658 [ 117.222021] tegra_xusb_runtime_suspend+0x40/0x68 [ 117.227260] pm_generic_runtime_suspend+0x30/0x50 [ 117.232847] __rpm_callback+0x84/0x3c0 [ 117.237038] rpm_suspend+0x2dc/0x740 [ 117.241229] pm_runtime_work+0xa0/0xb8 [ 117.245769] process_scheduled_works+0x24c/0x478 [ 117.251007] worker_thread+0x23c/0x328 [ 117.255547] kthread+0x104/0x1b0 [ 117.259389] ret_from_fork+0x10/0x20 [ 117.263582] Code: 54000222 f9461ae8 f8747908 b4ffff48 (f9400100)", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50076", "url": "https://ubuntu.com/security/CVE-2024-50076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vt: prevent kernel-infoleak in con_font_get() font.data may not initialize all memory spaces depending on the implementation of vc->vc_sw->con_font_get. This may cause info-leak, so to prevent this, it is safest to modify it to initialize the allocated memory space to 0, and it generally does not affect the overall performance of the system.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50077", "url": "https://ubuntu.com/security/CVE-2024-50077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix multiple init when debugfs is disabled If bt_debugfs is not created successfully, which happens if either CONFIG_DEBUG_FS or CONFIG_DEBUG_FS_ALLOW_ALL is unset, then iso_init() returns early and does not set iso_inited to true. This means that a subsequent call to iso_init() will result in duplicate calls to proto_register(), bt_sock_register(), etc. With CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, the duplicate call to proto_register() triggers this BUG(): list_add double add: new=ffffffffc0b280d0, prev=ffffffffbab56250, next=ffffffffc0b280d0. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:35! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 2 PID: 887 Comm: bluetoothd Not tainted 6.10.11-1-ao-desktop #1 RIP: 0010:__list_add_valid_or_report+0x9a/0xa0 ... __list_add_valid_or_report+0x9a/0xa0 proto_register+0x2b5/0x340 iso_init+0x23/0x150 [bluetooth] set_iso_socket_func+0x68/0x1b0 [bluetooth] kmem_cache_free+0x308/0x330 hci_sock_sendmsg+0x990/0x9e0 [bluetooth] __sock_sendmsg+0x7b/0x80 sock_write_iter+0x9a/0x110 do_iter_readv_writev+0x11d/0x220 vfs_writev+0x180/0x3e0 do_writev+0xca/0x100 ... This change removes the early return. The check for iso_debugfs being NULL was unnecessary, it is always NULL when iso_inited is false.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50078", "url": "https://ubuntu.com/security/CVE-2024-50078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Call iso_exit() on module unload If iso_init() has been called, iso_exit() must be called on module unload. Without that, the struct proto that iso_init() registered with proto_register() becomes invalid, which could cause unpredictable problems later. In my case, with CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, loading the module again usually triggers this BUG(): list_add corruption. next->prev should be prev (ffffffffb5355fd0), but was 0000000000000068. (next=ffffffffc0a010d0). ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:29! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 4159 Comm: modprobe Not tainted 6.10.11-4+bt2-ao-desktop #1 RIP: 0010:__list_add_valid_or_report+0x61/0xa0 ... __list_add_valid_or_report+0x61/0xa0 proto_register+0x299/0x320 hci_sock_init+0x16/0xc0 [bluetooth] bt_init+0x68/0xd0 [bluetooth] __pfx_bt_init+0x10/0x10 [bluetooth] do_one_initcall+0x80/0x2f0 do_init_module+0x8b/0x230 __do_sys_init_module+0x15f/0x190 do_syscall_64+0x68/0x110 ...", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50198", "url": "https://ubuntu.com/security/CVE-2024-50198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: veml6030: fix IIO device retrieval from embedded device The dev pointer that is received as an argument in the in_illuminance_period_available_show function references the device embedded in the IIO device, not in the i2c client. dev_to_iio_dev() must be used to accessthe right data. The current implementation leads to a segmentation fault on every attempt to read the attribute because indio_dev gets a NULL assignment. This bug has been present since the first appearance of the driver, apparently since the last version (V6) before getting applied. A constant attribute was used until then, and the last modifications might have not been tested again.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50201", "url": "https://ubuntu.com/security/CVE-2024-50201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: Fix encoder->possible_clones Include the encoder itself in its possible_clones bitmask. In the past nothing validated that drivers were populating possible_clones correctly, but that changed in commit 74d2aacbe840 (\"drm: Validate encoder->possible_clones\"). Looks like radeon never got the memo and is still not following the rules 100% correctly. This results in some warnings during driver initialization: Bogus possible_clones: [ENCODER:46:TV-46] possible_clones=0x4 (full encoder mask=0x7) WARNING: CPU: 0 PID: 170 at drivers/gpu/drm/drm_mode_config.c:615 drm_mode_config_validate+0x113/0x39c ... (cherry picked from commit 3b6e7d40649c0d75572039aff9d0911864c689db)", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50098", "url": "https://ubuntu.com/security/CVE-2024-50098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Set SDEV_OFFLINE when UFS is shut down There is a history of deadlock if reboot is performed at the beginning of booting. SDEV_QUIESCE was set for all LU's scsi_devices by UFS shutdown, and at that time the audio driver was waiting on blk_mq_submit_bio() holding a mutex_lock while reading the fw binary. After that, a deadlock issue occurred while audio driver shutdown was waiting for mutex_unlock of blk_mq_submit_bio(). To solve this, set SDEV_OFFLINE for all LUs except WLUN, so that any I/O that comes down after a UFS shutdown will return an error. [ 31.907781]I[0: swapper/0: 0] 1 130705007 1651079834 11289729804 0 D( 2) 3 ffffff882e208000 * init [device_shutdown] [ 31.907793]I[0: swapper/0: 0] Mutex: 0xffffff8849a2b8b0: owner[0xffffff882e28cb00 kworker/6:0 :49] [ 31.907806]I[0: swapper/0: 0] Call trace: [ 31.907810]I[0: swapper/0: 0] __switch_to+0x174/0x338 [ 31.907819]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc [ 31.907826]I[0: swapper/0: 0] schedule+0x7c/0xe8 [ 31.907834]I[0: swapper/0: 0] schedule_preempt_disabled+0x24/0x40 [ 31.907842]I[0: swapper/0: 0] __mutex_lock+0x408/0xdac [ 31.907849]I[0: swapper/0: 0] __mutex_lock_slowpath+0x14/0x24 [ 31.907858]I[0: swapper/0: 0] mutex_lock+0x40/0xec [ 31.907866]I[0: swapper/0: 0] device_shutdown+0x108/0x280 [ 31.907875]I[0: swapper/0: 0] kernel_restart+0x4c/0x11c [ 31.907883]I[0: swapper/0: 0] __arm64_sys_reboot+0x15c/0x280 [ 31.907890]I[0: swapper/0: 0] invoke_syscall+0x70/0x158 [ 31.907899]I[0: swapper/0: 0] el0_svc_common+0xb4/0xf4 [ 31.907909]I[0: swapper/0: 0] do_el0_svc+0x2c/0xb0 [ 31.907918]I[0: swapper/0: 0] el0_svc+0x34/0xe0 [ 31.907928]I[0: swapper/0: 0] el0t_64_sync_handler+0x68/0xb4 [ 31.907937]I[0: swapper/0: 0] el0t_64_sync+0x1a0/0x1a4 [ 31.908774]I[0: swapper/0: 0] 49 0 11960702 11236868007 0 D( 2) 6 ffffff882e28cb00 * kworker/6:0 [__bio_queue_enter] [ 31.908783]I[0: swapper/0: 0] Call trace: [ 31.908788]I[0: swapper/0: 0] __switch_to+0x174/0x338 [ 31.908796]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc [ 31.908803]I[0: swapper/0: 0] schedule+0x7c/0xe8 [ 31.908811]I[0: swapper/0: 0] __bio_queue_enter+0xb8/0x178 [ 31.908818]I[0: swapper/0: 0] blk_mq_submit_bio+0x194/0x67c [ 31.908827]I[0: swapper/0: 0] __submit_bio+0xb8/0x19c", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50079", "url": "https://ubuntu.com/security/CVE-2024-50079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/sqpoll: ensure task state is TASK_RUNNING when running task_work When the sqpoll is exiting and cancels pending work items, it may need to run task_work. If this happens from within io_uring_cancel_generic(), then it may be under waiting for the io_uring_task waitqueue. This results in the below splat from the scheduler, as the ring mutex may be attempted grabbed while in a TASK_INTERRUPTIBLE state. Ensure that the task state is set appropriately for that, just like what is done for the other cases in io_run_task_work(). do not call blocking ops when !TASK_RUNNING; state=1 set at [<0000000029387fd2>] prepare_to_wait+0x88/0x2fc WARNING: CPU: 6 PID: 59939 at kernel/sched/core.c:8561 __might_sleep+0xf4/0x140 Modules linked in: CPU: 6 UID: 0 PID: 59939 Comm: iou-sqp-59938 Not tainted 6.12.0-rc3-00113-g8d020023b155 #7456 Hardware name: linux,dummy-virt (DT) pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : __might_sleep+0xf4/0x140 lr : __might_sleep+0xf4/0x140 sp : ffff80008c5e7830 x29: ffff80008c5e7830 x28: ffff0000d93088c0 x27: ffff60001c2d7230 x26: dfff800000000000 x25: ffff0000e16b9180 x24: ffff80008c5e7a50 x23: 1ffff000118bcf4a x22: ffff0000e16b9180 x21: ffff0000e16b9180 x20: 000000000000011b x19: ffff80008310fac0 x18: 1ffff000118bcd90 x17: 30303c5b20746120 x16: 74657320313d6574 x15: 0720072007200720 x14: 0720072007200720 x13: 0720072007200720 x12: ffff600036c64f0b x11: 1fffe00036c64f0a x10: ffff600036c64f0a x9 : dfff800000000000 x8 : 00009fffc939b0f6 x7 : ffff0001b6327853 x6 : 0000000000000001 x5 : ffff0001b6327850 x4 : ffff600036c64f0b x3 : ffff8000803c35bc x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000e16b9180 Call trace: __might_sleep+0xf4/0x140 mutex_lock+0x84/0x124 io_handle_tw_list+0xf4/0x260 tctx_task_work_run+0x94/0x340 io_run_task_work+0x1ec/0x3c0 io_uring_cancel_generic+0x364/0x524 io_sq_thread+0x820/0x124c ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50080", "url": "https://ubuntu.com/security/CVE-2024-50080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: don't allow user copy for unprivileged device UBLK_F_USER_COPY requires userspace to call write() on ublk char device for filling request buffer, and unprivileged device can't be trusted. So don't allow user copy for unprivileged device.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50081", "url": "https://ubuntu.com/security/CVE-2024-50081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-mq: setup queue ->tag_set before initializing hctx Commit 7b815817aa58 (\"blk-mq: add helper for checking if one CPU is mapped to specified hctx\") needs to check queue mapping via tag set in hctx's cpuhp handler. However, q->tag_set may not be setup yet when the cpuhp handler is enabled, then kernel oops is triggered. Fix the issue by setup queue tag_set before initializing hctx.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50082", "url": "https://ubuntu.com/security/CVE-2024-50082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race We're seeing crashes from rq_qos_wake_function that look like this: BUG: unable to handle page fault for address: ffffafe180a40084 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 100000067 P4D 100000067 PUD 10027c067 PMD 10115d067 PTE 0 Oops: Oops: 0002 [#1] PREEMPT SMP PTI CPU: 17 UID: 0 PID: 0 Comm: swapper/17 Not tainted 6.12.0-rc3-00013-geca631b8fe80 #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:_raw_spin_lock_irqsave+0x1d/0x40 Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 9c 41 5c fa 65 ff 05 62 97 30 4c 31 c0 ba 01 00 00 00 0f b1 17 75 0a 4c 89 e0 41 5c c3 cc cc cc cc 89 c6 e8 2c 0b 00 RSP: 0018:ffffafe180580ca0 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffffafe180a3f7a8 RCX: 0000000000000011 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffffafe180a40084 RBP: 0000000000000000 R08: 00000000001e7240 R09: 0000000000000011 R10: 0000000000000028 R11: 0000000000000888 R12: 0000000000000002 R13: ffffafe180a40084 R14: 0000000000000000 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff9aaf1f280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffafe180a40084 CR3: 000000010e428002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: try_to_wake_up+0x5a/0x6a0 rq_qos_wake_function+0x71/0x80 __wake_up_common+0x75/0xa0 __wake_up+0x36/0x60 scale_up.part.0+0x50/0x110 wb_timer_fn+0x227/0x450 ... So rq_qos_wake_function() calls wake_up_process(data->task), which calls try_to_wake_up(), which faults in raw_spin_lock_irqsave(&p->pi_lock). p comes from data->task, and data comes from the waitqueue entry, which is stored on the waiter's stack in rq_qos_wait(). Analyzing the core dump with drgn, I found that the waiter had already woken up and moved on to a completely unrelated code path, clobbering what was previously data->task. Meanwhile, the waker was passing the clobbered garbage in data->task to wake_up_process(), leading to the crash. What's happening is that in between rq_qos_wake_function() deleting the waitqueue entry and calling wake_up_process(), rq_qos_wait() is finding that it already got a token and returning. The race looks like this: rq_qos_wait() rq_qos_wake_function() ============================================================== prepare_to_wait_exclusive() data->got_token = true; list_del_init(&curr->entry); if (data.got_token) break; finish_wait(&rqw->wait, &data.wq); ^- returns immediately because list_empty_careful(&wq_entry->entry) is true ... return, go do something else ... wake_up_process(data->task) (NO LONGER VALID!)-^ Normally, finish_wait() is supposed to synchronize against the waker. But, as noted above, it is returning immediately because the waitqueue entry has already been removed from the waitqueue. The bug is that rq_qos_wake_function() is accessing the waitqueue entry AFTER deleting it. Note that autoremove_wake_function() wakes the waiter and THEN deletes the waitqueue entry, which is the proper order. Fix it by swapping the order. We also need to use list_del_init_careful() to match the list_empty_careful() in finish_wait().", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50101", "url": "https://ubuntu.com/security/CVE-2024-50101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI devices Previously, the domain_context_clear() function incorrectly called pci_for_each_dma_alias() to set up context entries for non-PCI devices. This could lead to kernel hangs or other unexpected behavior. Add a check to only call pci_for_each_dma_alias() for PCI devices. For non-PCI devices, domain_context_clear_one() is called directly.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50083", "url": "https://ubuntu.com/security/CVE-2024-50083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix mptcp DSS corruption due to large pmtu xmit Syzkaller was able to trigger a DSS corruption: TCP: request_sock_subflow_v4: Possible SYN flooding on port [::]:20002. Sending cookies. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 5227 at net/mptcp/protocol.c:695 __mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695 Modules linked in: CPU: 0 UID: 0 PID: 5227 Comm: syz-executor350 Not tainted 6.11.0-syzkaller-08829-gaf9c191ac2a0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:__mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695 Code: 0f b6 dc 31 ff 89 de e8 b5 dd ea f5 89 d8 48 81 c4 50 01 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 98 da ea f5 90 <0f> 0b 90 e9 47 ff ff ff e8 8a da ea f5 90 0f 0b 90 e9 99 e0 ff ff RSP: 0018:ffffc90000006db8 EFLAGS: 00010246 RAX: ffffffff8ba9df18 RBX: 00000000000055f0 RCX: ffff888030023c00 RDX: 0000000000000100 RSI: 00000000000081e5 RDI: 00000000000055f0 RBP: 1ffff110062bf1ae R08: ffffffff8ba9cf12 R09: 1ffff110062bf1b8 R10: dffffc0000000000 R11: ffffed10062bf1b9 R12: 0000000000000000 R13: dffffc0000000000 R14: 00000000700cec61 R15: 00000000000081e5 FS: 000055556679c380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020287000 CR3: 0000000077892000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: move_skbs_to_msk net/mptcp/protocol.c:811 [inline] mptcp_data_ready+0x29c/0xa90 net/mptcp/protocol.c:854 subflow_data_ready+0x34a/0x920 net/mptcp/subflow.c:1490 tcp_data_queue+0x20fd/0x76c0 net/ipv4/tcp_input.c:5283 tcp_rcv_established+0xfba/0x2020 net/ipv4/tcp_input.c:6237 tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915 tcp_v4_rcv+0x2dc0/0x37f0 net/ipv4/tcp_ipv4.c:2350 ip_protocol_deliver_rcu+0x22e/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x341/0x5f0 net/ipv4/ip_input.c:233 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314 __netif_receive_skb_one_core net/core/dev.c:5662 [inline] __netif_receive_skb+0x2bf/0x650 net/core/dev.c:5775 process_backlog+0x662/0x15b0 net/core/dev.c:6107 __napi_poll+0xcb/0x490 net/core/dev.c:6771 napi_poll net/core/dev.c:6840 [inline] net_rx_action+0x89b/0x1240 net/core/dev.c:6962 handle_softirqs+0x2c5/0x980 kernel/softirq.c:554 do_softirq+0x11b/0x1e0 kernel/softirq.c:455 __local_bh_enable_ip+0x1bb/0x200 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0x1764/0x3e80 net/core/dev.c:4451 dev_queue_xmit include/linux/netdevice.h:3094 [inline] neigh_hh_output include/net/neighbour.h:526 [inline] neigh_output include/net/neighbour.h:540 [inline] ip_finish_output2+0xd41/0x1390 net/ipv4/ip_output.c:236 ip_local_out net/ipv4/ip_output.c:130 [inline] __ip_queue_xmit+0x118c/0x1b80 net/ipv4/ip_output.c:536 __tcp_transmit_skb+0x2544/0x3b30 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_mtu_probe net/ipv4/tcp_output.c:2547 [inline] tcp_write_xmit+0x641d/0x6bf0 net/ipv4/tcp_output.c:2752 __tcp_push_pending_frames+0x9b/0x360 net/ipv4/tcp_output.c:3015 tcp_push_pending_frames include/net/tcp.h:2107 [inline] tcp_data_snd_check net/ipv4/tcp_input.c:5714 [inline] tcp_rcv_established+0x1026/0x2020 net/ipv4/tcp_input.c:6239 tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915 sk_backlog_rcv include/net/sock.h:1113 [inline] __release_sock+0x214/0x350 net/core/sock.c:3072 release_sock+0x61/0x1f0 net/core/sock.c:3626 mptcp_push_ ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50068", "url": "https://ubuntu.com/security/CVE-2024-50068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/tests/sysfs-kunit.h: fix memory leak in damon_sysfs_test_add_targets() The sysfs_target->regions allocated in damon_sysfs_regions_alloc() is not freed in damon_sysfs_test_add_targets(), which cause the following memory leak, free it to fix it. \tunreferenced object 0xffffff80c2a8db80 (size 96): \t comm \"kunit_try_catch\", pid 187, jiffies 4294894363 \t hex dump (first 32 bytes): \t 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ \t 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ \t backtrace (crc 0): \t [<0000000001e3714d>] kmemleak_alloc+0x34/0x40 \t [<000000008e6835c1>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000001286d9f8>] damon_sysfs_test_add_targets+0x1cc/0x738 \t [<0000000032ef8f77>] kunit_try_run_case+0x13c/0x3ac \t [<00000000f3edea23>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000adf936cf>] kthread+0x2e8/0x374 \t [<0000000041bb1628>] ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50199", "url": "https://ubuntu.com/security/CVE-2024-50199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/swapfile: skip HugeTLB pages for unuse_vma I got a bad pud error and lost a 1GB HugeTLB when calling swapoff. The problem can be reproduced by the following steps: 1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory. 2. Swapout the above anonymous memory. 3. run swapoff and we will get a bad pud error in kernel message: mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7) We can tell that pud_clear_bad is called by pud_none_or_clear_bad in unuse_pud_range() by ftrace. And therefore the HugeTLB pages will never be freed because we lost it from page table. We can skip HugeTLB pages for unuse_vma to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50066", "url": "https://ubuntu.com/security/CVE-2024-50066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mremap: fix move_normal_pmd/retract_page_tables race In mremap(), move_page_tables() looks at the type of the PMD entry and the specified address range to figure out by which method the next chunk of page table entries should be moved. At that point, the mmap_lock is held in write mode, but no rmap locks are held yet. For PMD entries that point to page tables and are fully covered by the source address range, move_pgt_entry(NORMAL_PMD, ...) is called, which first takes rmap locks, then does move_normal_pmd(). move_normal_pmd() takes the necessary page table locks at source and destination, then moves an entire page table from the source to the destination. The problem is: The rmap locks, which protect against concurrent page table removal by retract_page_tables() in the THP code, are only taken after the PMD entry has been read and it has been decided how to move it. So we can race as follows (with two processes that have mappings of the same tmpfs file that is stored on a tmpfs mount with huge=advise); note that process A accesses page tables through the MM while process B does it through the file rmap: process A process B ========= ========= mremap mremap_to move_vma move_page_tables get_old_pmd alloc_new_pmd *** PREEMPT *** madvise(MADV_COLLAPSE) do_madvise madvise_walk_vmas madvise_vma_behavior madvise_collapse hpage_collapse_scan_file collapse_file retract_page_tables i_mmap_lock_read(mapping) pmdp_collapse_flush i_mmap_unlock_read(mapping) move_pgt_entry(NORMAL_PMD, ...) take_rmap_locks move_normal_pmd drop_rmap_locks When this happens, move_normal_pmd() can end up creating bogus PMD entries in the line `pmd_populate(mm, new_pmd, pmd_pgtable(pmd))`. The effect depends on arch-specific and machine-specific details; on x86, you can end up with physical page 0 mapped as a page table, which is likely exploitable for user->kernel privilege escalation. Fix the race by letting process B recheck that the PMD still points to a page table after the rmap locks have been taken. Otherwise, we bail and let the caller fall back to the PTE-level copying path, which will then bail immediately at the pmd_none() check. Bug reachability: Reaching this bug requires that you can create shmem/file THP mappings - anonymous THP uses different code that doesn't zap stuff under rmap locks. File THP is gated on an experimental config flag (CONFIG_READ_ONLY_THP_FOR_FS), so on normal distro kernels you need shmem THP to hit this bug. As far as I know, getting shmem THP normally requires that you can mount your own tmpfs with the right mount flags, which would require creating your own user+mount namespace; though I don't know if some distros maybe enable shmem THP by default or something like that. Bug impact: This issue can likely be used for user->kernel privilege escalation when it is reachable.", "cve_priority": "medium", "cve_public_date": "2024-10-23 06:15:00 UTC" }, { "cve": "CVE-2024-50202", "url": "https://ubuntu.com/security/CVE-2024-50202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: propagate directory read errors from nilfs_find_entry() Syzbot reported that a task hang occurs in vcs_open() during a fuzzing test for nilfs2. The root cause of this problem is that in nilfs_find_entry(), which searches for directory entries, ignores errors when loading a directory page/folio via nilfs_get_folio() fails. If the filesystem images is corrupted, and the i_size of the directory inode is large, and the directory page/folio is successfully read but fails the sanity check, for example when it is zero-filled, nilfs_check_folio() may continue to spit out error messages in bursts. Fix this issue by propagating the error to the callers when loading a page/folio fails in nilfs_find_entry(). The current interface of nilfs_find_entry() and its callers is outdated and cannot propagate error codes such as -EIO and -ENOMEM returned via nilfs_find_entry(), so fix it together.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50200", "url": "https://ubuntu.com/security/CVE-2024-50200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: maple_tree: correct tree corruption on spanning store Patch series \"maple_tree: correct tree corruption on spanning store\", v3. There has been a nasty yet subtle maple tree corruption bug that appears to have been in existence since the inception of the algorithm. This bug seems far more likely to happen since commit f8d112a4e657 (\"mm/mmap: avoid zeroing vma tree in mmap_region()\"), which is the point at which reports started to be submitted concerning this bug. We were made definitely aware of the bug thanks to the kind efforts of Bert Karwatzki who helped enormously in my being able to track this down and identify the cause of it. The bug arises when an attempt is made to perform a spanning store across two leaf nodes, where the right leaf node is the rightmost child of the shared parent, AND the store completely consumes the right-mode node. This results in mas_wr_spanning_store() mitakenly duplicating the new and existing entries at the maximum pivot within the range, and thus maple tree corruption. The fix patch corrects this by detecting this scenario and disallowing the mistaken duplicate copy. The fix patch commit message goes into great detail as to how this occurs. This series also includes a test which reliably reproduces the issue, and asserts that the fix works correctly. Bert has kindly tested the fix and confirmed it resolved his issues. Also Mikhail Gavrilov kindly reported what appears to be precisely the same bug, which this fix should also resolve. This patch (of 2): There has been a subtle bug present in the maple tree implementation from its inception. This arises from how stores are performed - when a store occurs, it will overwrite overlapping ranges and adjust the tree as necessary to accommodate this. A range may always ultimately span two leaf nodes. In this instance we walk the two leaf nodes, determine which elements are not overwritten to the left and to the right of the start and end of the ranges respectively and then rebalance the tree to contain these entries and the newly inserted one. This kind of store is dubbed a 'spanning store' and is implemented by mas_wr_spanning_store(). In order to reach this stage, mas_store_gfp() invokes mas_wr_preallocate(), mas_wr_store_type() and mas_wr_walk() in turn to walk the tree and update the object (mas) to traverse to the location where the write should be performed, determining its store type. When a spanning store is required, this function returns false stopping at the parent node which contains the target range, and mas_wr_store_type() marks the mas->store_type as wr_spanning_store to denote this fact. When we go to perform the store in mas_wr_spanning_store(), we first determine the elements AFTER the END of the range we wish to store (that is, to the right of the entry to be inserted) - we do this by walking to the NEXT pivot in the tree (i.e. r_mas.last + 1), starting at the node we have just determined contains the range over which we intend to write. We then turn our attention to the entries to the left of the entry we are inserting, whose state is represented by l_mas, and copy these into a 'big node', which is a special node which contains enough slots to contain two leaf node's worth of data. We then copy the entry we wish to store immediately after this - the copy and the insertion of the new entry is performed by mas_store_b_node(). After this we copy the elements to the right of the end of the range which we are inserting, if we have not exceeded the length of the node (i.e. r_mas.offset <= r_mas.end). Herein lies the bug - under very specific circumstances, this logic can break and corrupt the maple tree. Consider the following tree: Height 0 Root Node / \\ pivot = 0xffff / \\ pivot = ULONG_MAX / ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50084", "url": "https://ubuntu.com/security/CVE-2024-50084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: microchip: vcap api: Fix memory leaks in vcap_api_encode_rule_test() Commit a3c1e45156ad (\"net: microchip: vcap: Fix use-after-free error in kunit test\") fixed the use-after-free error, but introduced below memory leaks by removing necessary vcap_free_rule(), add it to fix it. \tunreferenced object 0xffffff80ca58b700 (size 192): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898264 \t hex dump (first 32 bytes): \t 00 12 7a 00 05 00 00 00 0a 00 00 00 64 00 00 00 ..z.........d... \t 00 00 00 00 00 00 00 00 00 04 0b cc 80 ff ff ff ................ \t backtrace (crc 9c09c3fe): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<0000000040a01b8d>] vcap_alloc_rule+0x3cc/0x9c4 \t [<000000003fe86110>] vcap_api_encode_rule_test+0x1ac/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0400 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898265 \t hex dump (first 32 bytes): \t 80 04 0b cc 80 ff ff ff 18 b7 58 ca 80 ff ff ff ..........X..... \t 39 00 00 00 02 00 00 00 06 05 04 03 02 01 ff ff 9............... \t backtrace (crc daf014e9): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<00000000dfdb1e81>] vcap_api_encode_rule_test+0x224/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0700 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898265 \t hex dump (first 32 bytes): \t 80 07 0b cc 80 ff ff ff 28 b7 58 ca 80 ff ff ff ........(.X..... \t 3c 00 00 00 00 00 00 00 01 2f 03 b3 ec ff ff ff <......../...... \t backtrace (crc 8d877792): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000006eadfab7>] vcap_rule_add_action+0x2d0/0x52c \t [<00000000323475d1>] vcap_api_encode_rule_test+0x4d4/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0900 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898266 \t hex dump (first 32 bytes): \t 80 09 0b cc 80 ff ff ff 80 06 0b cc 80 ff ff ff ................ \t 7d 00 00 00 01 00 00 00 00 00 00 00 ff 00 00 00 }............... \t backtrace (crc 34181e56): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<00000000991e3564>] vcap_val_rule+0xcf0/0x13e8 \t [<00000000fc9868e5>] vcap_api_encode_rule_test+0x678/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0980 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898266 \t hex dump (first 32 bytes): \t 18 b7 58 ca 80 ff ff ff 00 09 0b cc 80 ff ff ff ..X............. \t 67 00 00 00 00 00 00 00 01 01 74 88 c0 ff ff ff g.........t..... \t backtrace (crc 275fd9be): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<000000001396a1a2>] test_add_de ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50194", "url": "https://ubuntu.com/security/CVE-2024-50194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Fix uprobes for big-endian kernels The arm64 uprobes code is broken for big-endian kernels as it doesn't convert the in-memory instruction encoding (which is always little-endian) into the kernel's native endianness before analyzing and simulating instructions. This may result in a few distinct problems: * The kernel may may erroneously reject probing an instruction which can safely be probed. * The kernel may erroneously erroneously permit stepping an instruction out-of-line when that instruction cannot be stepped out-of-line safely. * The kernel may erroneously simulate instruction incorrectly dur to interpretting the byte-swapped encoding. The endianness mismatch isn't caught by the compiler or sparse because: * The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so the compiler and sparse have no idea these contain a little-endian 32-bit value. The core uprobes code populates these with a memcpy() which similarly does not handle endianness. * While the uprobe_opcode_t type is an alias for __le32, both arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[] to the similarly-named probe_opcode_t, which is an alias for u32. Hence there is no endianness conversion warning. Fix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and adding the appropriate __le32_to_cpu() conversions prior to consuming the instruction encoding. The core uprobes copies these fields as opaque ranges of bytes, and so is unaffected by this change. At the same time, remove MAX_UINSN_BYTES and consistently use AARCH64_INSN_SIZE for clarity. Tested with the following: | #include | #include | | #define noinline __attribute__((noinline)) | | static noinline void *adrp_self(void) | { | void *addr; | | asm volatile( | \" adrp %x0, adrp_self\\n\" | \" add %x0, %x0, :lo12:adrp_self\\n\" | : \"=r\" (addr)); | } | | | int main(int argc, char *argv) | { | void *ptr = adrp_self(); | bool equal = (ptr == adrp_self); | | printf(\"adrp_self => %p\\n\" | \"adrp_self() => %p\\n\" | \"%s\\n\", | adrp_self, ptr, equal ? \"EQUAL\" : \"NOT EQUAL\"); | | return 0; | } .... where the adrp_self() function was compiled to: | 00000000004007e0 : | 4007e0: 90000000 adrp x0, 400000 <__ehdr_start> | 4007e4: 911f8000 add x0, x0, #0x7e0 | 4007e8: d65f03c0 ret Before this patch, the ADRP is not recognized, and is assumed to be steppable, resulting in corruption of the result: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0xffffffffff7e0 | NOT EQUAL After this patch, the ADRP is correctly recognized and simulated: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50099", "url": "https://ubuntu.com/security/CVE-2024-50099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Remove broken LDR (literal) uprobe support The simulate_ldr_literal() and simulate_ldrsw_literal() functions are unsafe to use for uprobes. Both functions were originally written for use with kprobes, and access memory with plain C accesses. When uprobes was added, these were reused unmodified even though they cannot safely access user memory. There are three key problems: 1) The plain C accesses do not have corresponding extable entries, and thus if they encounter a fault the kernel will treat these as unintentional accesses to user memory, resulting in a BUG() which will kill the kernel thread, and likely lead to further issues (e.g. lockup or panic()). 2) The plain C accesses are subject to HW PAN and SW PAN, and so when either is in use, any attempt to simulate an access to user memory will fault. Thus neither simulate_ldr_literal() nor simulate_ldrsw_literal() can do anything useful when simulating a user instruction on any system with HW PAN or SW PAN. 3) The plain C accesses are privileged, as they run in kernel context, and in practice can access a small range of kernel virtual addresses. The instructions they simulate have a range of +/-1MiB, and since the simulated instructions must itself be a user instructions in the TTBR0 address range, these can address the final 1MiB of the TTBR1 acddress range by wrapping downwards from an address in the first 1MiB of the TTBR0 address range. In contemporary kernels the last 8MiB of TTBR1 address range is reserved, and accesses to this will always fault, meaning this is no worse than (1). Historically, it was theoretically possible for the linear map or vmemmap to spill into the final 8MiB of the TTBR1 address range, but in practice this is extremely unlikely to occur as this would require either: * Having enough physical memory to fill the entire linear map all the way to the final 1MiB of the TTBR1 address range. * Getting unlucky with KASLR randomization of the linear map such that the populated region happens to overlap with the last 1MiB of the TTBR address range. ... and in either case if we were to spill into the final page there would be larger problems as the final page would alias with error pointers. Practically speaking, (1) and (2) are the big issues. Given there have been no reports of problems since the broken code was introduced, it appears that no-one is relying on probing these instructions with uprobes. Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW (literal), limiting the use of simulate_ldr_literal() and simulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR (literal) and LDRSW (literal) will be rejected as arm_probe_decode_insn() will return INSN_REJECTED. In future we can consider introducing working uprobes support for these instructions, but this will require more significant work.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50195", "url": "https://ubuntu.com/security/CVE-2024-50195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-clock: Fix missing timespec64 check in pc_clock_settime() As Andrew pointed out, it will make sense that the PTP core checked timespec64 struct's tv_sec and tv_nsec range before calling ptp->info->settime64(). As the man manual of clock_settime() said, if tp.tv_sec is negative or tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL, which include dynamic clocks which handles PTP clock, and the condition is consistent with timespec64_valid(). As Thomas suggested, timespec64_valid() only check the timespec is valid, but not ensure that the time is in a valid range, so check it ahead using timespec64_valid_strict() in pc_clock_settime() and return -EINVAL if not valid. There are some drivers that use tp->tv_sec and tp->tv_nsec directly to write registers without validity checks and assume that the higher layer has checked it, which is dangerous and will benefit from this, such as hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(), and some drivers can remove the checks of itself.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50085", "url": "https://ubuntu.com/security/CVE-2024-50085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: fix UaF read in mptcp_pm_nl_rm_addr_or_subflow Syzkaller reported this splat: ================================================================== BUG: KASAN: slab-use-after-free in mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881 Read of size 4 at addr ffff8880569ac858 by task syz.1.2799/14662 CPU: 0 UID: 0 PID: 14662 Comm: syz.1.2799 Not tainted 6.12.0-rc2-syzkaller-00307-g36c254515dc6 #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+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881 mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:914 [inline] mptcp_nl_remove_id_zero_address+0x305/0x4a0 net/mptcp/pm_netlink.c:1572 mptcp_pm_nl_del_addr_doit+0x5c9/0x770 net/mptcp/pm_netlink.c:1603 genl_family_rcv_msg_doit+0x202/0x2f0 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x565/0x800 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x165/0x410 net/netlink/af_netlink.c:2551 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1331 [inline] netlink_unicast+0x53c/0x7f0 net/netlink/af_netlink.c:1357 netlink_sendmsg+0x8b8/0xd70 net/netlink/af_netlink.c:1901 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg net/socket.c:744 [inline] ____sys_sendmsg+0x9ae/0xb40 net/socket.c:2607 ___sys_sendmsg+0x135/0x1e0 net/socket.c:2661 __sys_sendmsg+0x117/0x1f0 net/socket.c:2690 do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline] __do_fast_syscall_32+0x73/0x120 arch/x86/entry/common.c:386 do_fast_syscall_32+0x32/0x80 arch/x86/entry/common.c:411 entry_SYSENTER_compat_after_hwframe+0x84/0x8e RIP: 0023:0xf7fe4579 Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00 RSP: 002b:00000000f574556c EFLAGS: 00000296 ORIG_RAX: 0000000000000172 RAX: ffffffffffffffda RBX: 000000000000000b RCX: 0000000020000140 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000296 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Allocated by task 5387: 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 kmalloc_noprof include/linux/slab.h:878 [inline] kzalloc_noprof include/linux/slab.h:1014 [inline] subflow_create_ctx+0x87/0x2a0 net/mptcp/subflow.c:1803 subflow_ulp_init+0xc3/0x4d0 net/mptcp/subflow.c:1956 __tcp_set_ulp net/ipv4/tcp_ulp.c:146 [inline] tcp_set_ulp+0x326/0x7f0 net/ipv4/tcp_ulp.c:167 mptcp_subflow_create_socket+0x4ae/0x10a0 net/mptcp/subflow.c:1764 __mptcp_subflow_connect+0x3cc/0x1490 net/mptcp/subflow.c:1592 mptcp_pm_create_subflow_or_signal_addr+0xbda/0x23a0 net/mptcp/pm_netlink.c:642 mptcp_pm_nl_fully_established net/mptcp/pm_netlink.c:650 [inline] mptcp_pm_nl_work+0x3a1/0x4f0 net/mptcp/pm_netlink.c:943 mptcp_worker+0x15a/0x1240 net/mptcp/protocol.c:2777 process_one_work+0x958/0x1b30 kernel/workqueue.c:3229 process_scheduled_works kernel/workqueue.c:3310 [inline] worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/ke ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50086", "url": "https://ubuntu.com/security/CVE-2024-50086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix user-after-free from session log off There is racy issue between smb2 session log off and smb2 session setup. It will cause user-after-free from session log off. This add session_lock when setting SMB2_SESSION_EXPIRED and referece count to session struct not to free session while it is being used.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50087", "url": "https://ubuntu.com/security/CVE-2024-50087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix uninitialized pointer free on read_alloc_one_name() error The function read_alloc_one_name() does not initialize the name field of the passed fscrypt_str struct if kmalloc fails to allocate the corresponding buffer. Thus, it is not guaranteed that fscrypt_str.name is initialized when freeing it. This is a follow-up to the linked patch that fixes the remaining instances of the bug introduced by commit e43eec81c516 (\"btrfs: use struct qstr instead of name and namelen pairs\").", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50088", "url": "https://ubuntu.com/security/CVE-2024-50088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix uninitialized pointer free in add_inode_ref() The add_inode_ref() function does not initialize the \"name\" struct when it is declared. If any of the following calls to \"read_one_inode() returns NULL, \tdir = read_one_inode(root, parent_objectid); \tif (!dir) { \t\tret = -ENOENT; \t\tgoto out; \t} \tinode = read_one_inode(root, inode_objectid); \tif (!inode) { \t\tret = -EIO; \t\tgoto out; \t} then \"name.name\" would be freed on \"out\" before being initialized. out: \t... \tkfree(name.name); This issue was reported by Coverity with CID 1526744.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50182", "url": "https://ubuntu.com/security/CVE-2024-50182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: secretmem: disable memfd_secret() if arch cannot set direct map Return -ENOSYS from memfd_secret() syscall if !can_set_direct_map(). This is the case for example on some arm64 configurations, where marking 4k PTEs in the direct map not present can only be done if the direct map is set up at 4k granularity in the first place (as ARM's break-before-make semantics do not easily allow breaking apart large/gigantic pages). More precisely, on arm64 systems with !can_set_direct_map(), set_direct_map_invalid_noflush() is a no-op, however it returns success (0) instead of an error. This means that memfd_secret will seemingly \"work\" (e.g. syscall succeeds, you can mmap the fd and fault in pages), but it does not actually achieve its goal of removing its memory from the direct map. Note that with this patch, memfd_secret() will start erroring on systems where can_set_direct_map() returns false (arm64 with CONFIG_RODATA_FULL_DEFAULT_ENABLED=n, CONFIG_DEBUG_PAGEALLOC=n and CONFIG_KFENCE=n), but that still seems better than the current silent failure. Since CONFIG_RODATA_FULL_DEFAULT_ENABLED defaults to 'y', most arm64 systems actually have a working memfd_secret() and aren't be affected. From going through the iterations of the original memfd_secret patch series, it seems that disabling the syscall in these scenarios was the intended behavior [1] (preferred over having set_direct_map_invalid_noflush return an error as that would result in SIGBUSes at page-fault time), however the check for it got dropped between v16 [2] and v17 [3], when secretmem moved away from CMA allocations. [1]: https://lore.kernel.org/lkml/20201124164930.GK8537@kernel.org/ [2]: https://lore.kernel.org/lkml/20210121122723.3446-11-rppt@kernel.org/#t [3]: https://lore.kernel.org/lkml/20201125092208.12544-10-rppt@kernel.org/", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50019", "url": "https://ubuntu.com/security/CVE-2024-50019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kthread: unpark only parked kthread Calling into kthread unparking unconditionally is mostly harmless when the kthread is already unparked. The wake up is then simply ignored because the target is not in TASK_PARKED state. However if the kthread is per CPU, the wake up is preceded by a call to kthread_bind() which expects the task to be inactive and in TASK_PARKED state, which obviously isn't the case if it is unparked. As a result, calling kthread_stop() on an unparked per-cpu kthread triggers such a warning: \tWARNING: CPU: 0 PID: 11 at kernel/kthread.c:525 __kthread_bind_mask kernel/kthread.c:525 \t \t kthread_stop+0x17a/0x630 kernel/kthread.c:707 \t destroy_workqueue+0x136/0xc40 kernel/workqueue.c:5810 \t wg_destruct+0x1e2/0x2e0 drivers/net/wireguard/device.c:257 \t netdev_run_todo+0xe1a/0x1000 net/core/dev.c:10693 \t default_device_exit_batch+0xa14/0xa90 net/core/dev.c:11769 \t ops_exit_list net/core/net_namespace.c:178 [inline] \t cleanup_net+0x89d/0xcc0 net/core/net_namespace.c:640 \t process_one_work kernel/workqueue.c:3231 [inline] \t process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 \t worker_thread+0x86d/0xd70 kernel/workqueue.c:3393 \t kthread+0x2f0/0x390 kernel/kthread.c:389 \t ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 \t ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 \t Fix this with skipping unecessary unparking while stopping a kthread.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50096", "url": "https://ubuntu.com/security/CVE-2024-50096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/dmem: Fix vulnerability in migrate_to_ram upon copy error The `nouveau_dmem_copy_one` function ensures that the copy push command is sent to the device firmware but does not track whether it was executed successfully. In the case of a copy error (e.g., firmware or hardware failure), the copy push command will be sent via the firmware channel, and `nouveau_dmem_copy_one` will likely report success, leading to the `migrate_to_ram` function returning a dirty HIGH_USER page to the user. This can result in a security vulnerability, as a HIGH_USER page that may contain sensitive or corrupted data could be returned to the user. To prevent this vulnerability, we allocate a zero page. Thus, in case of an error, a non-dirty (zero) page will be returned to the user.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50020", "url": "https://ubuntu.com/security/CVE-2024-50020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix improper handling of refcount in ice_sriov_set_msix_vec_count() This patch addresses an issue with improper reference count handling in the ice_sriov_set_msix_vec_count() function. First, the function calls ice_get_vf_by_id(), which increments the reference count of the vf pointer. If the subsequent call to ice_get_vf_vsi() fails, the function currently returns an error without decrementing the reference count of the vf pointer, leading to a reference count leak. The correct behavior, as implemented in this patch, is to decrement the reference count using ice_put_vf(vf) before returning an error when vsi is NULL. Second, the function calls ice_sriov_get_irqs(), which sets vf->first_vector_idx. If this call returns a negative value, indicating an error, the function returns an error without decrementing the reference count of the vf pointer, resulting in another reference count leak. The patch addresses this by adding a call to ice_put_vf(vf) before returning an error when vf->first_vector_idx < 0. This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and identifying potential mismanagement of reference counts. In this case, the tool flagged the missing decrement operation as a potential issue, leading to this patch.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50021", "url": "https://ubuntu.com/security/CVE-2024-50021", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix improper handling of refcount in ice_dpll_init_rclk_pins() This patch addresses a reference count handling issue in the ice_dpll_init_rclk_pins() function. The function calls ice_dpll_get_pins(), which increments the reference count of the relevant resources. However, if the condition WARN_ON((!vsi || !vsi->netdev)) is met, the function currently returns an error without properly releasing the resources acquired by ice_dpll_get_pins(), leading to a reference count leak. To resolve this, the check has been moved to the top of the function. This ensures that the function verifies the state before any resources are acquired, avoiding the need for additional resource management in the error path. This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and detecting potential issues where resources are not properly managed. In this case, the tool flagged the missing release operation as a potential problem, which led to the development of this patch.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50022", "url": "https://ubuntu.com/security/CVE-2024-50022", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: device-dax: correct pgoff align in dax_set_mapping() pgoff should be aligned using ALIGN_DOWN() instead of ALIGN(). Otherwise, vmf->address not aligned to fault_size will be aligned to the next alignment, that can result in memory failure getting the wrong address. It's a subtle situation that only can be observed in page_mapped_in_vma() after the page is page fault handled by dev_dax_huge_fault. Generally, there is little chance to perform page_mapped_in_vma in dev-dax's page unless in specific error injection to the dax device to trigger an MCE - memory-failure. In that case, page_mapped_in_vma() will be triggered to determine which task is accessing the failure address and kill that task in the end. We used self-developed dax device (which is 2M aligned mapping) , to perform error injection to random address. It turned out that error injected to non-2M-aligned address was causing endless MCE until panic. Because page_mapped_in_vma() kept resulting wrong address and the task accessing the failure address was never killed properly: [ 3783.719419] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.049006] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.049190] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.448042] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.448186] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.792026] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.792179] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.162502] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.162633] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.461116] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.461247] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.764730] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.764859] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.042128] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.042259] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.464293] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.464423] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.818090] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.818217] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3787.085297] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3787.085424] Memory failure: 0x200c9742: recovery action for dax page: Recovered It took us several weeks to pinpoint this problem,  but we eventually used bpftrace to trace the page fault and mce address and successfully identified the issue. Joao added: ; Likely we never reproduce in production because we always pin : device-dax regions in the region align they provide (Qemu does : similarly with prealloc in hugetlb/file backed memory). I think this : bug requires that we touch *unpinned* device-dax regions unaligned to : the device-dax selected alignment (page size i.e. 4K/2M/1G)", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50185", "url": "https://ubuntu.com/security/CVE-2024-50185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: handle consistently DSS corruption Bugged peer implementation can send corrupted DSS options, consistently hitting a few warning in the data path. Use DEBUG_NET assertions, to avoid the splat on some builds and handle consistently the error, dumping related MIBs and performing fallback and/or reset according to the subflow type.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50023", "url": "https://ubuntu.com/security/CVE-2024-50023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: Remove LED entry from LEDs list on unregister Commit c938ab4da0eb (\"net: phy: Manual remove LEDs to ensure correct ordering\") correctly fixed a problem with using devm_ but missed removing the LED entry from the LEDs list. This cause kernel panic on specific scenario where the port for the PHY is torn down and up and the kmod for the PHY is removed. On setting the port down the first time, the assosiacted LEDs are correctly unregistered. The associated kmod for the PHY is now removed. The kmod is now added again and the port is now put up, the associated LED are registered again. On putting the port down again for the second time after these step, the LED list now have 4 elements. With the first 2 already unregistered previously and the 2 new one registered again. This cause a kernel panic as the first 2 element should have been removed. Fix this by correctly removing the element when LED is unregistered.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50024", "url": "https://ubuntu.com/security/CVE-2024-50024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: Fix an unsafe loop on the list The kernel may crash when deleting a genetlink family if there are still listeners for that family: Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c000000000c080bc] netlink_update_socket_mc+0x3c/0xc0 LR [c000000000c0f764] __netlink_clear_multicast_users+0x74/0xc0 Call Trace: __netlink_clear_multicast_users+0x74/0xc0 genl_unregister_family+0xd4/0x2d0 Change the unsafe loop on the list to a safe one, because inside the loop there is an element removal from this list.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50186", "url": "https://ubuntu.com/security/CVE-2024-50186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: explicitly clear the sk pointer, when pf->create fails We have recently noticed the exact same KASAN splat as in commit 6cd4a78d962b (\"net: do not leave a dangling sk pointer, when socket creation fails\"). The problem is that commit did not fully address the problem, as some pf->create implementations do not use sk_common_release in their error paths. For example, we can use the same reproducer as in the above commit, but changing ping to arping. arping uses AF_PACKET socket and if packet_create fails, it will just sk_free the allocated sk object. While we could chase all the pf->create implementations and make sure they NULL the freed sk object on error from the socket, we can't guarantee future protocols will not make the same mistake. So it is easier to just explicitly NULL the sk pointer upon return from pf->create in __sock_create. We do know that pf->create always releases the allocated sk object on error, so if the pointer is not NULL, it is definitely dangling.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50025", "url": "https://ubuntu.com/security/CVE-2024-50025", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: fnic: Move flush_work initialization out of if block After commit 379a58caa199 (\"scsi: fnic: Move fnic_fnic_flush_tx() to a work queue\"), it can happen that a work item is sent to an uninitialized work queue. This may has the effect that the item being queued is never actually queued, and any further actions depending on it will not proceed. The following warning is observed while the fnic driver is loaded: kernel: WARNING: CPU: 11 PID: 0 at ../kernel/workqueue.c:1524 __queue_work+0x373/0x410 kernel: kernel: queue_work_on+0x3a/0x50 kernel: fnic_wq_copy_cmpl_handler+0x54a/0x730 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: fnic_isr_msix_wq_copy+0x2d/0x60 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: __handle_irq_event_percpu+0x36/0x1a0 kernel: handle_irq_event_percpu+0x30/0x70 kernel: handle_irq_event+0x34/0x60 kernel: handle_edge_irq+0x7e/0x1a0 kernel: __common_interrupt+0x3b/0xb0 kernel: common_interrupt+0x58/0xa0 kernel: It has been observed that this may break the rediscovery of Fibre Channel devices after a temporary fabric failure. This patch fixes it by moving the work queue initialization out of an if block in fnic_probe().", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50026", "url": "https://ubuntu.com/security/CVE-2024-50026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: wd33c93: Don't use stale scsi_pointer value A regression was introduced with commit dbb2da557a6a (\"scsi: wd33c93: Move the SCSI pointer to private command data\") which results in an oops in wd33c93_intr(). That commit added the scsi_pointer variable and initialized it from hostdata->connected. However, during selection, hostdata->connected is not yet valid. Fix this by getting the current scsi_pointer from hostdata->selecting.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50027", "url": "https://ubuntu.com/security/CVE-2024-50027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: core: Free tzp copy along with the thermal zone The object pointed to by tz->tzp may still be accessed after being freed in thermal_zone_device_unregister(), so move the freeing of it to the point after the removal completion has been completed at which it cannot be accessed any more.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50028", "url": "https://ubuntu.com/security/CVE-2024-50028", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: core: Reference count the zone in thermal_zone_get_by_id() There are places in the thermal netlink code where nothing prevents the thermal zone object from going away while being accessed after it has been returned by thermal_zone_get_by_id(). To address this, make thermal_zone_get_by_id() get a reference on the thermal zone device object to be returned with the help of get_device(), under thermal_list_lock, and adjust all of its callers to this change with the help of the cleanup.h infrastructure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50029", "url": "https://ubuntu.com/security/CVE-2024-50029", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_conn: Fix UAF in hci_enhanced_setup_sync This checks if the ACL connection remains valid as it could be destroyed while hci_enhanced_setup_sync is pending on cmd_sync leading to the following trace: BUG: KASAN: slab-use-after-free in hci_enhanced_setup_sync+0x91b/0xa60 Read of size 1 at addr ffff888002328ffd by task kworker/u5:2/37 CPU: 0 UID: 0 PID: 37 Comm: kworker/u5:2 Not tainted 6.11.0-rc6-01300-g810be445d8d6 #7099 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Workqueue: hci0 hci_cmd_sync_work Call Trace: dump_stack_lvl+0x5d/0x80 ? hci_enhanced_setup_sync+0x91b/0xa60 print_report+0x152/0x4c0 ? hci_enhanced_setup_sync+0x91b/0xa60 ? __virt_addr_valid+0x1fa/0x420 ? hci_enhanced_setup_sync+0x91b/0xa60 kasan_report+0xda/0x1b0 ? hci_enhanced_setup_sync+0x91b/0xa60 hci_enhanced_setup_sync+0x91b/0xa60 ? __pfx_hci_enhanced_setup_sync+0x10/0x10 ? __pfx___mutex_lock+0x10/0x10 hci_cmd_sync_work+0x1c2/0x330 process_one_work+0x7d9/0x1360 ? __pfx_lock_acquire+0x10/0x10 ? __pfx_process_one_work+0x10/0x10 ? assign_work+0x167/0x240 worker_thread+0x5b7/0xf60 ? __kthread_parkme+0xac/0x1c0 ? __pfx_worker_thread+0x10/0x10 ? __pfx_worker_thread+0x10/0x10 kthread+0x293/0x360 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2f/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 34: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __hci_conn_add+0x187/0x17d0 hci_connect_sco+0x2e1/0xb90 sco_sock_connect+0x2a2/0xb80 __sys_connect+0x227/0x2a0 __x64_sys_connect+0x6d/0xb0 do_syscall_64+0x71/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 37: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x101/0x160 kfree+0xd0/0x250 device_release+0x9a/0x210 kobject_put+0x151/0x280 hci_conn_del+0x448/0xbf0 hci_abort_conn_sync+0x46f/0x980 hci_cmd_sync_work+0x1c2/0x330 process_one_work+0x7d9/0x1360 worker_thread+0x5b7/0xf60 kthread+0x293/0x360 ret_from_fork+0x2f/0x70 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50030", "url": "https://ubuntu.com/security/CVE-2024-50030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/ct: prevent UAF in send_recv() Ensure we serialize with completion side to prevent UAF with fence going out of scope on the stack, since we have no clue if it will fire after the timeout before we can erase from the xa. Also we have some dependent loads and stores for which we need the correct ordering, and we lack the needed barriers. Fix this by grabbing the ct->lock after the wait, which is also held by the completion side. v2 (Badal): - Also print done after acquiring the lock and seeing timeout. (cherry picked from commit 52789ce35c55ccd30c4b67b9cc5b2af55e0122ea)", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50187", "url": "https://ubuntu.com/security/CVE-2024-50187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Stop the active perfmon before being destroyed Upon closing the file descriptor, the active performance monitor is not stopped. Although all perfmons are destroyed in `vc4_perfmon_close_file()`, the active performance monitor's pointer (`vc4->active_perfmon`) is still retained. If we open a new file descriptor and submit a few jobs with performance monitors, the driver will attempt to stop the active performance monitor using the stale pointer in `vc4->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50031", "url": "https://ubuntu.com/security/CVE-2024-50031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Stop the active perfmon before being destroyed When running `kmscube` with one or more performance monitors enabled via `GALLIUM_HUD`, the following kernel panic can occur: [ 55.008324] Unable to handle kernel paging request at virtual address 00000000052004a4 [ 55.008368] Mem abort info: [ 55.008377] ESR = 0x0000000096000005 [ 55.008387] EC = 0x25: DABT (current EL), IL = 32 bits [ 55.008402] SET = 0, FnV = 0 [ 55.008412] EA = 0, S1PTW = 0 [ 55.008421] FSC = 0x05: level 1 translation fault [ 55.008434] Data abort info: [ 55.008442] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 55.008455] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 55.008467] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 55.008481] user pgtable: 4k pages, 39-bit VAs, pgdp=00000001046c6000 [ 55.008497] [00000000052004a4] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 55.008525] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP [ 55.008542] Modules linked in: rfcomm [...] vc4 v3d snd_soc_hdmi_codec drm_display_helper gpu_sched drm_shmem_helper cec drm_dma_helper drm_kms_helper i2c_brcmstb drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight [ 55.008799] CPU: 2 PID: 166 Comm: v3d_bin Tainted: G C 6.6.47+rpt-rpi-v8 #1 Debian 1:6.6.47-1+rpt1 [ 55.008824] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [ 55.008838] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 55.008855] pc : __mutex_lock.constprop.0+0x90/0x608 [ 55.008879] lr : __mutex_lock.constprop.0+0x58/0x608 [ 55.008895] sp : ffffffc080673cf0 [ 55.008904] x29: ffffffc080673cf0 x28: 0000000000000000 x27: ffffff8106188a28 [ 55.008926] x26: ffffff8101e78040 x25: ffffff8101baa6c0 x24: ffffffd9d989f148 [ 55.008947] x23: ffffffda1c2a4008 x22: 0000000000000002 x21: ffffffc080673d38 [ 55.008968] x20: ffffff8101238000 x19: ffffff8104f83188 x18: 0000000000000000 [ 55.008988] x17: 0000000000000000 x16: ffffffda1bd04d18 x15: 00000055bb08bc90 [ 55.009715] x14: 0000000000000000 x13: 0000000000000000 x12: ffffffda1bd4cbb0 [ 55.010433] x11: 00000000fa83b2da x10: 0000000000001a40 x9 : ffffffda1bd04d04 [ 55.011162] x8 : ffffff8102097b80 x7 : 0000000000000000 x6 : 00000000030a5857 [ 55.011880] x5 : 00ffffffffffffff x4 : 0300000005200470 x3 : 0300000005200470 [ 55.012598] x2 : ffffff8101238000 x1 : 0000000000000021 x0 : 0300000005200470 [ 55.013292] Call trace: [ 55.013959] __mutex_lock.constprop.0+0x90/0x608 [ 55.014646] __mutex_lock_slowpath+0x1c/0x30 [ 55.015317] mutex_lock+0x50/0x68 [ 55.015961] v3d_perfmon_stop+0x40/0xe0 [v3d] [ 55.016627] v3d_bin_job_run+0x10c/0x2d8 [v3d] [ 55.017282] drm_sched_main+0x178/0x3f8 [gpu_sched] [ 55.017921] kthread+0x11c/0x128 [ 55.018554] ret_from_fork+0x10/0x20 [ 55.019168] Code: f9400260 f1001c1f 54001ea9 927df000 (b9403401) [ 55.019776] ---[ end trace 0000000000000000 ]--- [ 55.020411] note: v3d_bin[166] exited with preempt_count 1 This issue arises because, upon closing the file descriptor (which happens when we interrupt `kmscube`), the active performance monitor is not stopped. Although all perfmons are destroyed in `v3d_perfmon_close_file()`, the active performance monitor's pointer (`v3d->active_perfmon`) is still retained. If `kmscube` is run again, the driver will attempt to stop the active performance monitor using the stale pointer in `v3d->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50189", "url": "https://ubuntu.com/security/CVE-2024-50189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: amd_sfh: Switch to device-managed dmam_alloc_coherent() Using the device-managed version allows to simplify clean-up in probe() error path. Additionally, this device-managed ensures proper cleanup, which helps to resolve memory errors, page faults, btrfs going read-only, and btrfs disk corruption.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50033", "url": "https://ubuntu.com/security/CVE-2024-50033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slip: make slhc_remember() more robust against malicious packets syzbot found that slhc_remember() was missing checks against malicious packets [1]. slhc_remember() only checked the size of the packet was at least 20, which is not good enough. We need to make sure the packet includes the IPv4 and TCP header that are supposed to be carried. Add iph and th pointers to make the code more readable. [1] BUG: KMSAN: uninit-value in slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 ppp_receive_nonmp_frame+0xe45/0x35e0 drivers/net/ppp/ppp_generic.c:2455 ppp_receive_frame drivers/net/ppp/ppp_generic.c:2372 [inline] ppp_do_recv+0x65f/0x40d0 drivers/net/ppp/ppp_generic.c:2212 ppp_input+0x7dc/0xe60 drivers/net/ppp/ppp_generic.c:2327 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 Uninit was created at: slab_post_alloc_hook mm/slub.c:4091 [inline] slab_alloc_node mm/slub.c:4134 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 CPU: 0 UID: 0 PID: 5460 Comm: syz.2.33 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50034", "url": "https://ubuntu.com/security/CVE-2024-50034", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix lacks of icsk_syn_mss with IPPROTO_SMC Eric report a panic on IPPROTO_SMC, and give the facts that when INET_PROTOSW_ICSK was set, icsk->icsk_sync_mss must be set too. Bug: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000086000005 EC = 0x21: IABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault user pgtable: 4k pages, 48-bit VAs, pgdp=00000001195d1000 [0000000000000000] pgd=0800000109c46003, p4d=0800000109c46003, pud=0000000000000000 Internal error: Oops: 0000000086000005 [#1] PREEMPT SMP Modules linked in: CPU: 1 UID: 0 PID: 8037 Comm: syz.3.265 Not tainted 6.11.0-rc7-syzkaller-g5f5673607153 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0x0 lr : cipso_v4_sock_setattr+0x2a8/0x3c0 net/ipv4/cipso_ipv4.c:1910 sp : ffff80009b887a90 x29: ffff80009b887aa0 x28: ffff80008db94050 x27: 0000000000000000 x26: 1fffe0001aa6f5b3 x25: dfff800000000000 x24: ffff0000db75da00 x23: 0000000000000000 x22: ffff0000d8b78518 x21: 0000000000000000 x20: ffff0000d537ad80 x19: ffff0000d8b78000 x18: 1fffe000366d79ee x17: ffff8000800614a8 x16: ffff800080569b84 x15: 0000000000000001 x14: 000000008b336894 x13: 00000000cd96feaa x12: 0000000000000003 x11: 0000000000040000 x10: 00000000000020a3 x9 : 1fffe0001b16f0f1 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 000000000000003f x5 : 0000000000000040 x4 : 0000000000000001 x3 : 0000000000000000 x2 : 0000000000000002 x1 : 0000000000000000 x0 : ffff0000d8b78000 Call trace: 0x0 netlbl_sock_setattr+0x2e4/0x338 net/netlabel/netlabel_kapi.c:1000 smack_netlbl_add+0xa4/0x154 security/smack/smack_lsm.c:2593 smack_socket_post_create+0xa8/0x14c security/smack/smack_lsm.c:2973 security_socket_post_create+0x94/0xd4 security/security.c:4425 __sock_create+0x4c8/0x884 net/socket.c:1587 sock_create net/socket.c:1622 [inline] __sys_socket_create net/socket.c:1659 [inline] __sys_socket+0x134/0x340 net/socket.c:1706 __do_sys_socket net/socket.c:1720 [inline] __se_sys_socket net/socket.c:1718 [inline] __arm64_sys_socket+0x7c/0x94 net/socket.c:1718 __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:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 Code: ???????? ???????? ???????? ???????? (????????) ---[ end trace 0000000000000000 ]--- This patch add a toy implementation that performs a simple return to prevent such panic. This is because MSS can be set in sock_create_kern or smc_setsockopt, similar to how it's done in AF_SMC. However, for AF_SMC, there is currently no way to synchronize MSS within __sys_connect_file. This toy implementation lays the groundwork for us to support such feature for IPPROTO_SMC in the future.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50035", "url": "https://ubuntu.com/security/CVE-2024-50035", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: fix ppp_async_encode() illegal access syzbot reported an issue in ppp_async_encode() [1] In this case, pppoe_sendmsg() is called with a zero size. Then ppp_async_encode() is called with an empty skb. BUG: KMSAN: uninit-value in ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] BUG: KMSAN: uninit-value in ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_send+0x130/0x1b0 drivers/net/ppp/ppp_async.c:634 ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2280 [inline] ppp_input+0x1f1/0xe60 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 Uninit was created at: slab_post_alloc_hook mm/slub.c:4092 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4187 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 CPU: 1 UID: 0 PID: 5411 Comm: syz.1.14 Not tainted 6.12.0-rc1-syzkaller-00165-g360c1f1f24c6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50036", "url": "https://ubuntu.com/security/CVE-2024-50036", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: do not delay dst_entries_add() in dst_release() dst_entries_add() uses per-cpu data that might be freed at netns dismantle from ip6_route_net_exit() calling dst_entries_destroy() Before ip6_route_net_exit() can be called, we release all the dsts associated with this netns, via calls to dst_release(), which waits an rcu grace period before calling dst_destroy() dst_entries_add() use in dst_destroy() is racy, because dst_entries_destroy() could have been called already. Decrementing the number of dsts must happen sooner. Notes: 1) in CONFIG_XFRM case, dst_destroy() can call dst_release_immediate(child), this might also cause UAF if the child does not have DST_NOCOUNT set. IPSEC maintainers might take a look and see how to address this. 2) There is also discussion about removing this count of dst, which might happen in future kernels.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50037", "url": "https://ubuntu.com/security/CVE-2024-50037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/fbdev-dma: Only cleanup deferred I/O if necessary Commit 5a498d4d06d6 (\"drm/fbdev-dma: Only install deferred I/O if necessary\") initializes deferred I/O only if it is used. drm_fbdev_dma_fb_destroy() however calls fb_deferred_io_cleanup() unconditionally with struct fb_info.fbdefio == NULL. KASAN with the out-of-tree Apple silicon display driver posts following warning from __flush_work() of a random struct work_struct instead of the expected NULL pointer derefs. [ 22.053799] ------------[ cut here ]------------ [ 22.054832] WARNING: CPU: 2 PID: 1 at kernel/workqueue.c:4177 __flush_work+0x4d8/0x580 [ 22.056597] Modules linked in: uhid bnep uinput nls_ascii ip6_tables ip_tables i2c_dev loop fuse dm_multipath nfnetlink zram hid_magicmouse btrfs xor xor_neon brcmfmac_wcc raid6_pq hci_bcm4377 bluetooth brcmfmac hid_apple brcmutil nvmem_spmi_mfd simple_mfd_spmi dockchannel_hid cfg80211 joydev regmap_spmi nvme_apple ecdh_generic ecc macsmc_hid rfkill dwc3 appledrm snd_soc_macaudio macsmc_power nvme_core apple_isp phy_apple_atc apple_sart apple_rtkit_helper apple_dockchannel tps6598x macsmc_hwmon snd_soc_cs42l84 videobuf2_v4l2 spmi_apple_controller nvmem_apple_efuses videobuf2_dma_sg apple_z2 videobuf2_memops spi_nor panel_summit videobuf2_common asahi videodev pwm_apple apple_dcp snd_soc_apple_mca apple_admac spi_apple clk_apple_nco i2c_pasemi_platform snd_pcm_dmaengine mc i2c_pasemi_core mux_core ofpart adpdrm drm_dma_helper apple_dart apple_soc_cpufreq leds_pwm phram [ 22.073768] CPU: 2 UID: 0 PID: 1 Comm: systemd-shutdow Not tainted 6.11.2-asahi+ #asahi-dev [ 22.075612] Hardware name: Apple MacBook Pro (13-inch, M2, 2022) (DT) [ 22.077032] pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 22.078567] pc : __flush_work+0x4d8/0x580 [ 22.079471] lr : __flush_work+0x54/0x580 [ 22.080345] sp : ffffc000836ef820 [ 22.081089] x29: ffffc000836ef880 x28: 0000000000000000 x27: ffff80002ddb7128 [ 22.082678] x26: dfffc00000000000 x25: 1ffff000096f0c57 x24: ffffc00082d3e358 [ 22.084263] x23: ffff80004b7862b8 x22: dfffc00000000000 x21: ffff80005aa1d470 [ 22.085855] x20: ffff80004b786000 x19: ffff80004b7862a0 x18: 0000000000000000 [ 22.087439] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000005 [ 22.089030] x14: 1ffff800106ddf0a x13: 0000000000000000 x12: 0000000000000000 [ 22.090618] x11: ffffb800106ddf0f x10: dfffc00000000000 x9 : 1ffff800106ddf0e [ 22.092206] x8 : 0000000000000000 x7 : aaaaaaaaaaaaaaaa x6 : 0000000000000001 [ 22.093790] x5 : ffffc000836ef728 x4 : 0000000000000000 x3 : 0000000000000020 [ 22.095368] x2 : 0000000000000008 x1 : 00000000000000aa x0 : 0000000000000000 [ 22.096955] Call trace: [ 22.097505] __flush_work+0x4d8/0x580 [ 22.098330] flush_delayed_work+0x80/0xb8 [ 22.099231] fb_deferred_io_cleanup+0x3c/0x130 [ 22.100217] drm_fbdev_dma_fb_destroy+0x6c/0xe0 [drm_dma_helper] [ 22.101559] unregister_framebuffer+0x210/0x2f0 [ 22.102575] drm_fb_helper_unregister_info+0x48/0x60 [ 22.103683] drm_fbdev_dma_client_unregister+0x4c/0x80 [drm_dma_helper] [ 22.105147] drm_client_dev_unregister+0x1cc/0x230 [ 22.106217] drm_dev_unregister+0x58/0x570 [ 22.107125] apple_drm_unbind+0x50/0x98 [appledrm] [ 22.108199] component_del+0x1f8/0x3a8 [ 22.109042] dcp_platform_shutdown+0x24/0x38 [apple_dcp] [ 22.110357] platform_shutdown+0x70/0x90 [ 22.111219] device_shutdown+0x368/0x4d8 [ 22.112095] kernel_restart+0x6c/0x1d0 [ 22.112946] __arm64_sys_reboot+0x1c8/0x328 [ 22.113868] invoke_syscall+0x78/0x1a8 [ 22.114703] do_el0_svc+0x124/0x1a0 [ 22.115498] el0_svc+0x3c/0xe0 [ 22.116181] el0t_64_sync_handler+0x70/0xc0 [ 22.117110] el0t_64_sync+0x190/0x198 [ 22.117931] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50092", "url": "https://ubuntu.com/security/CVE-2024-50092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netconsole: fix wrong warning A warning is triggered when there is insufficient space in the buffer for userdata. However, this is not an issue since userdata will be sent in the next iteration. Current warning message: ------------[ cut here ]------------ WARNING: CPU: 13 PID: 3013042 at drivers/net/netconsole.c:1122 write_ext_msg+0x3b6/0x3d0 ? write_ext_msg+0x3b6/0x3d0 console_flush_all+0x1e9/0x330 The code incorrectly issues a warning when this_chunk is zero, which is a valid scenario. The warning should only be triggered when this_chunk is negative.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50038", "url": "https://ubuntu.com/security/CVE-2024-50038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xtables: avoid NFPROTO_UNSPEC where needed syzbot managed to call xt_cluster match via ebtables: WARNING: CPU: 0 PID: 11 at net/netfilter/xt_cluster.c:72 xt_cluster_mt+0x196/0x780 [..] ebt_do_table+0x174b/0x2a40 Module registers to NFPROTO_UNSPEC, but it assumes ipv4/ipv6 packet processing. As this is only useful to restrict locally terminating TCP/UDP traffic, register this for ipv4 and ipv6 family only. Pablo points out that this is a general issue, direct users of the set/getsockopt interface can call into targets/matches that were only intended for use with ip(6)tables. Check all UNSPEC matches and targets for similar issues: - matches and targets are fine except if they assume skb_network_header() is valid -- this is only true when called from inet layer: ip(6) stack pulls the ip/ipv6 header into linear data area. - targets that return XT_CONTINUE or other xtables verdicts must be restricted too, they are incompatbile with the ebtables traverser, e.g. EBT_CONTINUE is a completely different value than XT_CONTINUE. Most matches/targets are changed to register for NFPROTO_IPV4/IPV6, as they are provided for use by ip(6)tables. The MARK target is also used by arptables, so register for NFPROTO_ARP too. While at it, bail out if connbytes fails to enable the corresponding conntrack family. This change passes the selftests in iptables.git.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50039", "url": "https://ubuntu.com/security/CVE-2024-50039", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: accept TCA_STAB only for root qdisc Most qdiscs maintain their backlog using qdisc_pkt_len(skb) on the assumption it is invariant between the enqueue() and dequeue() handlers. Unfortunately syzbot can crash a host rather easily using a TBF + SFQ combination, with an STAB on SFQ [1] We can't support TCA_STAB on arbitrary level, this would require to maintain per-qdisc storage. [1] [ 88.796496] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 88.798611] #PF: supervisor read access in kernel mode [ 88.799014] #PF: error_code(0x0000) - not-present page [ 88.799506] PGD 0 P4D 0 [ 88.799829] Oops: Oops: 0000 [#1] SMP NOPTI [ 88.800569] CPU: 14 UID: 0 PID: 2053 Comm: b371744477 Not tainted 6.12.0-rc1-virtme #1117 [ 88.801107] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 88.801779] RIP: 0010:sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq [ 88.802544] Code: 0f b7 50 12 48 8d 04 d5 00 00 00 00 48 89 d6 48 29 d0 48 8b 91 c0 01 00 00 48 c1 e0 03 48 01 c2 66 83 7a 1a 00 7e c0 48 8b 3a <4c> 8b 07 4c 89 02 49 89 50 08 48 c7 47 08 00 00 00 00 48 c7 07 00 All code ======== 0:\t0f b7 50 12 \tmovzwl 0x12(%rax),%edx 4:\t48 8d 04 d5 00 00 00 \tlea 0x0(,%rdx,8),%rax b:\t00 c:\t48 89 d6 \tmov %rdx,%rsi f:\t48 29 d0 \tsub %rdx,%rax 12:\t48 8b 91 c0 01 00 00 \tmov 0x1c0(%rcx),%rdx 19:\t48 c1 e0 03 \tshl $0x3,%rax 1d:\t48 01 c2 \tadd %rax,%rdx 20:\t66 83 7a 1a 00 \tcmpw $0x0,0x1a(%rdx) 25:\t7e c0 \tjle 0xffffffffffffffe7 27:\t48 8b 3a \tmov (%rdx),%rdi 2a:*\t4c 8b 07 \tmov (%rdi),%r8\t\t<-- trapping instruction 2d:\t4c 89 02 \tmov %r8,(%rdx) 30:\t49 89 50 08 \tmov %rdx,0x8(%r8) 34:\t48 c7 47 08 00 00 00 \tmovq $0x0,0x8(%rdi) 3b:\t00 3c:\t48 \trex.W 3d:\tc7 \t.byte 0xc7 3e:\t07 \t(bad) \t... Code starting with the faulting instruction =========================================== 0:\t4c 8b 07 \tmov (%rdi),%r8 3:\t4c 89 02 \tmov %r8,(%rdx) 6:\t49 89 50 08 \tmov %rdx,0x8(%r8) a:\t48 c7 47 08 00 00 00 \tmovq $0x0,0x8(%rdi) 11:\t00 12:\t48 \trex.W 13:\tc7 \t.byte 0xc7 14:\t07 \t(bad) \t... [ 88.803721] RSP: 0018:ffff9a1f892b7d58 EFLAGS: 00000206 [ 88.804032] RAX: 0000000000000000 RBX: ffff9a1f8420c800 RCX: ffff9a1f8420c800 [ 88.804560] RDX: ffff9a1f81bc1440 RSI: 0000000000000000 RDI: 0000000000000000 [ 88.805056] RBP: ffffffffc04bb0e0 R08: 0000000000000001 R09: 00000000ff7f9a1f [ 88.805473] R10: 000000000001001b R11: 0000000000009a1f R12: 0000000000000140 [ 88.806194] R13: 0000000000000001 R14: ffff9a1f886df400 R15: ffff9a1f886df4ac [ 88.806734] FS: 00007f445601a740(0000) GS:ffff9a2e7fd80000(0000) knlGS:0000000000000000 [ 88.807225] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 88.807672] CR2: 0000000000000000 CR3: 000000050cc46000 CR4: 00000000000006f0 [ 88.808165] Call Trace: [ 88.808459] [ 88.808710] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434) [ 88.809261] ? page_fault_oops (arch/x86/mm/fault.c:715) [ 88.809561] ? exc_page_fault (./arch/x86/include/asm/irqflags.h:26 ./arch/x86/include/asm/irqflags.h:87 ./arch/x86/include/asm/irqflags.h:147 arch/x86/mm/fault.c:1489 arch/x86/mm/fault.c:1539) [ 88.809806] ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623) [ 88.810074] ? sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq [ 88.810411] sfq_reset (net/sched/sch_sfq.c:525) sch_sfq [ 88.810671] qdisc_reset (./include/linux/skbuff.h:2135 ./include/linux/skbuff.h:2441 ./include/linux/skbuff.h:3304 ./include/linux/skbuff.h:3310 net/sched/sch_g ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50040", "url": "https://ubuntu.com/security/CVE-2024-50040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: igb: Do not bring the device up after non-fatal error Commit 004d25060c78 (\"igb: Fix igb_down hung on surprise removal\") changed igb_io_error_detected() to ignore non-fatal pcie errors in order to avoid hung task that can happen when igb_down() is called multiple times. This caused an issue when processing transient non-fatal errors. igb_io_resume(), which is called after igb_io_error_detected(), assumes that device is brought down by igb_io_error_detected() if the interface is up. This resulted in panic with stacktrace below. [ T3256] igb 0000:09:00.0 haeth0: igb: haeth0 NIC Link is Down [ T292] pcieport 0000:00:1c.5: AER: Uncorrected (Non-Fatal) error received: 0000:09:00.0 [ T292] igb 0000:09:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, (Requester ID) [ T292] igb 0000:09:00.0: device [8086:1537] error status/mask=00004000/00000000 [ T292] igb 0000:09:00.0: [14] CmpltTO [ 200.105524,009][ T292] igb 0000:09:00.0: AER: TLP Header: 00000000 00000000 00000000 00000000 [ T292] pcieport 0000:00:1c.5: AER: broadcast error_detected message [ T292] igb 0000:09:00.0: Non-correctable non-fatal error reported. [ T292] pcieport 0000:00:1c.5: AER: broadcast mmio_enabled message [ T292] pcieport 0000:00:1c.5: AER: broadcast resume message [ T292] ------------[ cut here ]------------ [ T292] kernel BUG at net/core/dev.c:6539! [ T292] invalid opcode: 0000 [#1] PREEMPT SMP [ T292] RIP: 0010:napi_enable+0x37/0x40 [ T292] Call Trace: [ T292] [ T292] ? die+0x33/0x90 [ T292] ? do_trap+0xdc/0x110 [ T292] ? napi_enable+0x37/0x40 [ T292] ? do_error_trap+0x70/0xb0 [ T292] ? napi_enable+0x37/0x40 [ T292] ? napi_enable+0x37/0x40 [ T292] ? exc_invalid_op+0x4e/0x70 [ T292] ? napi_enable+0x37/0x40 [ T292] ? asm_exc_invalid_op+0x16/0x20 [ T292] ? napi_enable+0x37/0x40 [ T292] igb_up+0x41/0x150 [ T292] igb_io_resume+0x25/0x70 [ T292] report_resume+0x54/0x70 [ T292] ? report_frozen_detected+0x20/0x20 [ T292] pci_walk_bus+0x6c/0x90 [ T292] ? aer_print_port_info+0xa0/0xa0 [ T292] pcie_do_recovery+0x22f/0x380 [ T292] aer_process_err_devices+0x110/0x160 [ T292] aer_isr+0x1c1/0x1e0 [ T292] ? disable_irq_nosync+0x10/0x10 [ T292] irq_thread_fn+0x1a/0x60 [ T292] irq_thread+0xe3/0x1a0 [ T292] ? irq_set_affinity_notifier+0x120/0x120 [ T292] ? irq_affinity_notify+0x100/0x100 [ T292] kthread+0xe2/0x110 [ T292] ? kthread_complete_and_exit+0x20/0x20 [ T292] ret_from_fork+0x2d/0x50 [ T292] ? kthread_complete_and_exit+0x20/0x20 [ T292] ret_from_fork_asm+0x11/0x20 [ T292] To fix this issue igb_io_resume() checks if the interface is running and the device is not down this means igb_io_error_detected() did not bring the device down and there is no need to bring it up.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50041", "url": "https://ubuntu.com/security/CVE-2024-50041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: Fix macvlan leak by synchronizing access to mac_filter_hash This patch addresses a macvlan leak issue in the i40e driver caused by concurrent access to vsi->mac_filter_hash. The leak occurs when multiple threads attempt to modify the mac_filter_hash simultaneously, leading to inconsistent state and potential memory leaks. To fix this, we now wrap the calls to i40e_del_mac_filter() and zeroing vf->default_lan_addr.addr with spin_lock/unlock_bh(&vsi->mac_filter_hash_lock), ensuring atomic operations and preventing concurrent access. Additionally, we add lockdep_assert_held(&vsi->mac_filter_hash_lock) in i40e_add_mac_filter() to help catch similar issues in the future. Reproduction steps: 1. Spawn VFs and configure port vlan on them. 2. Trigger concurrent macvlan operations (e.g., adding and deleting \tportvlan and/or mac filters). 3. Observe the potential memory leak and inconsistent state in the \tmac_filter_hash. This synchronization ensures the integrity of the mac_filter_hash and prevents the described leak.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50042", "url": "https://ubuntu.com/security/CVE-2024-50042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix increasing MSI-X on VF Increasing MSI-X value on a VF leads to invalid memory operations. This is caused by not reallocating some arrays. Reproducer: modprobe ice echo 0 > /sys/bus/pci/devices/$PF_PCI/sriov_drivers_autoprobe echo 1 > /sys/bus/pci/devices/$PF_PCI/sriov_numvfs echo 17 > /sys/bus/pci/devices/$VF0_PCI/sriov_vf_msix_count Default MSI-X is 16, so 17 and above triggers this issue. KASAN reports: BUG: KASAN: slab-out-of-bounds in ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] Read of size 8 at addr ffff8888b937d180 by task bash/28433 (...) Call Trace: (...) ? ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] kasan_report+0xed/0x120 ? ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] ice_vsi_cfg_def+0x3360/0x4770 [ice] ? mutex_unlock+0x83/0xd0 ? __pfx_ice_vsi_cfg_def+0x10/0x10 [ice] ? __pfx_ice_remove_vsi_lkup_fltr+0x10/0x10 [ice] ice_vsi_cfg+0x7f/0x3b0 [ice] ice_vf_reconfig_vsi+0x114/0x210 [ice] ice_sriov_set_msix_vec_count+0x3d0/0x960 [ice] sriov_vf_msix_count_store+0x21c/0x300 (...) Allocated by task 28201: (...) ice_vsi_cfg_def+0x1c8e/0x4770 [ice] ice_vsi_cfg+0x7f/0x3b0 [ice] ice_vsi_setup+0x179/0xa30 [ice] ice_sriov_configure+0xcaa/0x1520 [ice] sriov_numvfs_store+0x212/0x390 (...) To fix it, use ice_vsi_rebuild() instead of ice_vf_reconfig_vsi(). This causes the required arrays to be reallocated taking the new queue count into account (ice_vsi_realloc_stat_arrays()). Set req_txq and req_rxq before ice_vsi_rebuild(), so that realloc uses the newly set queue count. Additionally, ice_vsi_rebuild() does not remove VSI filters (ice_fltr_remove_all()), so ice_vf_init_host_cfg() is no longer necessary.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50093", "url": "https://ubuntu.com/security/CVE-2024-50093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: intel: int340x: processor: Fix warning during module unload The processor_thermal driver uses pcim_device_enable() to enable a PCI device, which means the device will be automatically disabled on driver detach. Thus there is no need to call pci_disable_device() again on it. With recent PCI device resource management improvements, e.g. commit f748a07a0b64 (\"PCI: Remove legacy pcim_release()\"), this problem is exposed and triggers the warining below. [ 224.010735] proc_thermal_pci 0000:00:04.0: disabling already-disabled device [ 224.010747] WARNING: CPU: 8 PID: 4442 at drivers/pci/pci.c:2250 pci_disable_device+0xe5/0x100 ... [ 224.010844] Call Trace: [ 224.010845] [ 224.010847] ? show_regs+0x6d/0x80 [ 224.010851] ? __warn+0x8c/0x140 [ 224.010854] ? pci_disable_device+0xe5/0x100 [ 224.010856] ? report_bug+0x1c9/0x1e0 [ 224.010859] ? handle_bug+0x46/0x80 [ 224.010862] ? exc_invalid_op+0x1d/0x80 [ 224.010863] ? asm_exc_invalid_op+0x1f/0x30 [ 224.010867] ? pci_disable_device+0xe5/0x100 [ 224.010869] ? pci_disable_device+0xe5/0x100 [ 224.010871] ? kfree+0x21a/0x2b0 [ 224.010873] pcim_disable_device+0x20/0x30 [ 224.010875] devm_action_release+0x16/0x20 [ 224.010878] release_nodes+0x47/0xc0 [ 224.010880] devres_release_all+0x9f/0xe0 [ 224.010883] device_unbind_cleanup+0x12/0x80 [ 224.010885] device_release_driver_internal+0x1ca/0x210 [ 224.010887] driver_detach+0x4e/0xa0 [ 224.010889] bus_remove_driver+0x6f/0xf0 [ 224.010890] driver_unregister+0x35/0x60 [ 224.010892] pci_unregister_driver+0x44/0x90 [ 224.010894] proc_thermal_pci_driver_exit+0x14/0x5f0 [processor_thermal_device_pci] ... [ 224.010921] ---[ end trace 0000000000000000 ]--- Remove the excess pci_disable_device() calls. [ rjw: Subject and changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50043", "url": "https://ubuntu.com/security/CVE-2024-50043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix possible badness in FREE_STATEID When multiple FREE_STATEIDs are sent for the same delegation stateid, it can lead to a possible either use-after-free or counter refcount underflow errors. In nfsd4_free_stateid() under the client lock we find a delegation stateid, however the code drops the lock before calling nfs4_put_stid(), that allows another FREE_STATE to find the stateid again. The first one will proceed to then free the stateid which leads to either use-after-free or decrementing already zeroed counter.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50044", "url": "https://ubuntu.com/security/CVE-2024-50044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change rfcomm_sk_state_change attempts to use sock_lock so it must never be called with it locked but rfcomm_sock_ioctl always attempt to lock it causing the following trace: ====================================================== WARNING: possible circular locking dependency detected 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Not tainted ------------------------------------------------------ syz-executor386/5093 is trying to acquire lock: ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1671 [inline] ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73 but task is already holding lock: ffff88807badfd28 (&d->lock){+.+.}-{3:3}, at: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50045", "url": "https://ubuntu.com/security/CVE-2024-50045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: br_netfilter: fix panic with metadata_dst skb Fix a kernel panic in the br_netfilter module when sending untagged traffic via a VxLAN device. This happens during the check for fragmentation in br_nf_dev_queue_xmit. It is dependent on: 1) the br_netfilter module being loaded; 2) net.bridge.bridge-nf-call-iptables set to 1; 3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port; 4) untagged frames with size higher than the VxLAN MTU forwarded/flooded When forwarding the untagged packet to the VxLAN bridge port, before the netfilter hooks are called, br_handle_egress_vlan_tunnel is called and changes the skb_dst to the tunnel dst. The tunnel_dst is a metadata type of dst, i.e., skb_valid_dst(skb) is false, and metadata->dst.dev is NULL. Then in the br_netfilter hooks, in br_nf_dev_queue_xmit, there's a check for frames that needs to be fragmented: frames with higher MTU than the VxLAN device end up calling br_nf_ip_fragment, which in turns call ip_skb_dst_mtu. The ip_dst_mtu tries to use the skb_dst(skb) as if it was a valid dst with valid dst->dev, thus the crash. This case was never supported in the first place, so drop the packet instead. PING 10.0.0.2 (10.0.0.2) from 0.0.0.0 h1-eth0: 2000(2028) bytes of data. [ 176.291791] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000110 [ 176.292101] Mem abort info: [ 176.292184] ESR = 0x0000000096000004 [ 176.292322] EC = 0x25: DABT (current EL), IL = 32 bits [ 176.292530] SET = 0, FnV = 0 [ 176.292709] EA = 0, S1PTW = 0 [ 176.292862] FSC = 0x04: level 0 translation fault [ 176.293013] Data abort info: [ 176.293104] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 176.293488] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 176.293787] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 176.293995] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043ef5000 [ 176.294166] [0000000000000110] pgd=0000000000000000, p4d=0000000000000000 [ 176.294827] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 176.295252] Modules linked in: vxlan ip6_udp_tunnel udp_tunnel veth br_netfilter bridge stp llc ipv6 crct10dif_ce [ 176.295923] CPU: 0 PID: 188 Comm: ping Not tainted 6.8.0-rc3-g5b3fbd61b9d1 #2 [ 176.296314] Hardware name: linux,dummy-virt (DT) [ 176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 176.296808] pc : br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.297382] lr : br_nf_dev_queue_xmit+0x2ac/0x4ec [br_netfilter] [ 176.297636] sp : ffff800080003630 [ 176.297743] x29: ffff800080003630 x28: 0000000000000008 x27: ffff6828c49ad9f8 [ 176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24: 00000000000003e8 [ 176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21: ffff6828c3b16d28 [ 176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18: 0000000000000014 [ 176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15: 0000000095744632 [ 176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12: ffffb7e137926a70 [ 176.299574] x11: 0000000000000001 x10: ffff6828c3f1c898 x9 : 0000000000000000 [ 176.300049] x8 : ffff6828c49bf070 x7 : 0008460f18d5f20e x6 : f20e0100bebafeca [ 176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 : 0000000000000000 [ 176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 : ffff6828c7f918f0 [ 176.300889] Call trace: [ 176.301123] br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.301411] br_nf_post_routing+0x2a8/0x3e4 [br_netfilter] [ 176.301703] nf_hook_slow+0x48/0x124 [ 176.302060] br_forward_finish+0xc8/0xe8 [bridge] [ 176.302371] br_nf_hook_thresh+0x124/0x134 [br_netfilter] [ 176.302605] br_nf_forward_finish+0x118/0x22c [br_netfilter] [ 176.302824] br_nf_forward_ip.part.0+0x264/0x290 [br_netfilter] [ 176.303136] br_nf_forward+0x2b8/0x4e0 [br_netfilter] [ 176.303359] nf_hook_slow+0x48/0x124 [ 176.303 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50094", "url": "https://ubuntu.com/security/CVE-2024-50094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sfc: Don't invoke xdp_do_flush() from netpoll. Yury reported a crash in the sfc driver originated from netpoll_send_udp(). The netconsole sends a message and then netpoll invokes the driver's NAPI function with a budget of zero. It is dedicated to allow driver to free TX resources, that it may have used while sending the packet. In the netpoll case the driver invokes xdp_do_flush() unconditionally, leading to crash because bpf_net_context was never assigned. Invoke xdp_do_flush() only if budget is not zero.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50188", "url": "https://ubuntu.com/security/CVE-2024-50188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: dp83869: fix memory corruption when enabling fiber When configuring the fiber port, the DP83869 PHY driver incorrectly calls linkmode_set_bit() with a bit mask (1 << 10) rather than a bit number (10). This corrupts some other memory location -- in case of arm64 the priv pointer in the same structure. Since the advertising flags are updated from supported at the end of the function the incorrect line isn't needed at all and can be removed.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50046", "url": "https://ubuntu.com/security/CVE-2024-50046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies() On the node of an NFS client, some files saved in the mountpoint of the NFS server were copied to another location of the same NFS server. Accidentally, the nfs42_complete_copies() got a NULL-pointer dereference crash with the following syslog: [232064.838881] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232064.839360] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232066.588183] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 [232066.588586] Mem abort info: [232066.588701] ESR = 0x0000000096000007 [232066.588862] EC = 0x25: DABT (current EL), IL = 32 bits [232066.589084] SET = 0, FnV = 0 [232066.589216] EA = 0, S1PTW = 0 [232066.589340] FSC = 0x07: level 3 translation fault [232066.589559] Data abort info: [232066.589683] ISV = 0, ISS = 0x00000007 [232066.589842] CM = 0, WnR = 0 [232066.589967] user pgtable: 64k pages, 48-bit VAs, pgdp=00002000956ff400 [232066.590231] [0000000000000058] pgd=08001100ae100003, p4d=08001100ae100003, pud=08001100ae100003, pmd=08001100b3c00003, pte=0000000000000000 [232066.590757] Internal error: Oops: 96000007 [#1] SMP [232066.590958] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm vhost_net vhost vhost_iotlb tap tun ipt_rpfilter xt_multiport ip_set_hash_ip ip_set_hash_net xfrm_interface xfrm6_tunnel tunnel4 tunnel6 esp4 ah4 wireguard libcurve25519_generic veth xt_addrtype xt_set nf_conntrack_netlink ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_bitmap_port ip_set_hash_ipport dummy ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs iptable_filter sch_ingress nfnetlink_cttimeout vport_gre ip_gre ip_tunnel gre vport_geneve geneve vport_vxlan vxlan ip6_udp_tunnel udp_tunnel openvswitch nf_conncount dm_round_robin dm_service_time dm_multipath xt_nat xt_MASQUERADE nft_chain_nat nf_nat xt_mark xt_conntrack xt_comment nft_compat nft_counter nf_tables nfnetlink ocfs2 ocfs2_nodemanager ocfs2_stackglue iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_ssif nbd overlay 8021q garp mrp bonding tls rfkill sunrpc ext4 mbcache jbd2 [232066.591052] vfat fat cas_cache cas_disk ses enclosure scsi_transport_sas sg acpi_ipmi ipmi_si ipmi_devintf ipmi_msghandler ip_tables vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio dm_mirror dm_region_hash dm_log dm_mod nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc fuse xfs libcrc32c ast drm_vram_helper qla2xxx drm_kms_helper syscopyarea crct10dif_ce sysfillrect ghash_ce sysimgblt sha2_ce fb_sys_fops cec sha256_arm64 sha1_ce drm_ttm_helper ttm nvme_fc igb sbsa_gwdt nvme_fabrics drm nvme_core i2c_algo_bit i40e scsi_transport_fc megaraid_sas aes_neon_bs [232066.596953] CPU: 6 PID: 4124696 Comm: 10.253.166.125- Kdump: loaded Not tainted 5.15.131-9.cl9_ocfs2.aarch64 #1 [232066.597356] Hardware name: Great Wall .\\x93\\x8e...RF6260 V5/GWMSSE2GL1T, BIOS T656FBE_V3.0.18 2024-01-06 [232066.597721] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [232066.598034] pc : nfs4_reclaim_open_state+0x220/0x800 [nfsv4] [232066.598327] lr : nfs4_reclaim_open_state+0x12c/0x800 [nfsv4] [232066.598595] sp : ffff8000f568fc70 [232066.598731] x29: ffff8000f568fc70 x28: 0000000000001000 x27: ffff21003db33000 [232066.599030] x26: ffff800005521ae0 x25: ffff0100f98fa3f0 x24: 0000000000000001 [232066.599319] x23: ffff800009920008 x22: ffff21003db33040 x21: ffff21003db33050 [232066.599628] x20: ffff410172fe9e40 x19: ffff410172fe9e00 x18: 0000000000000000 [232066.599914] x17: 0000000000000000 x16: 0000000000000004 x15: 0000000000000000 [232066.600195] x14: 0000000000000000 x13: ffff800008e685a8 x12: 00000000eac0c6e6 [232066.600498] x11: 00000000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50190", "url": "https://ubuntu.com/security/CVE-2024-50190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix memleak in ice_init_tx_topology() Fix leak of the FW blob (DDP pkg). Make ice_cfg_tx_topo() const-correct, so ice_init_tx_topology() can avoid copying whole FW blob. Copy just the topology section, and only when needed. Reuse the buffer allocated for the read of the current topology. This was found by kmemleak, with the following trace for each PF: [] kmemdup_noprof+0x1d/0x50 [] ice_init_ddp_config+0x100/0x220 [ice] [] ice_init_dev+0x6f/0x200 [ice] [] ice_init+0x29/0x560 [ice] [] ice_probe+0x21d/0x310 [ice] Constify ice_cfg_tx_topo() @buf parameter. This cascades further down to few more functions.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50180", "url": "https://ubuntu.com/security/CVE-2024-50180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: sisfb: Fix strbuf array overflow The values of the variables xres and yres are placed in strbuf. These variables are obtained from strbuf1. The strbuf1 array contains digit characters and a space if the array contains non-digit characters. Then, when executing sprintf(strbuf, \"%ux%ux8\", xres, yres); more than 16 bytes will be written to strbuf. It is suggested to increase the size of the strbuf array to 24. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06: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": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50048", "url": "https://ubuntu.com/security/CVE-2024-50048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: Fix a NULL pointer dereference issue in fbcon_putcs syzbot has found a NULL pointer dereference bug in fbcon. Here is the simplified C reproducer: struct param { \tuint8_t type; \tstruct tiocl_selection ts; }; int main() { \tstruct fb_con2fbmap con2fb; \tstruct param param; \tint fd = open(\"/dev/fb1\", 0, 0); \tcon2fb.console = 0x19; \tcon2fb.framebuffer = 0; \tioctl(fd, FBIOPUT_CON2FBMAP, &con2fb); \tparam.type = 2; \tparam.ts.xs = 0; param.ts.ys = 0; \tparam.ts.xe = 0; param.ts.ye = 0; \tparam.ts.sel_mode = 0; \tint fd1 = open(\"/dev/tty1\", O_RDWR, 0); \tioctl(fd1, TIOCLINUX, ¶m); \tcon2fb.console = 1; \tcon2fb.framebuffer = 0; \tioctl(fd, FBIOPUT_CON2FBMAP, &con2fb); \treturn 0; } After calling ioctl(fd1, TIOCLINUX, ¶m), the subsequent ioctl(fd, FBIOPUT_CON2FBMAP, &con2fb) causes the kernel to follow a different execution path: set_con2fb_map -> con2fb_init_display -> fbcon_set_disp -> redraw_screen -> hide_cursor -> clear_selection -> highlight -> invert_screen -> do_update_region -> fbcon_putcs -> ops->putcs Since ops->putcs is a NULL pointer, this leads to a kernel panic. To prevent this, we need to call set_blitting_type() within set_con2fb_map() to properly initialize ops->putcs.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50049", "url": "https://ubuntu.com/security/CVE-2024-50049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before dereferencing se [WHAT & HOW] se is null checked previously in the same function, indicating it might be null; therefore, it must be checked when used again. This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50090", "url": "https://ubuntu.com/security/CVE-2024-50090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/oa: Fix overflow in oa batch buffer By default xe_bb_create_job() appends a MI_BATCH_BUFFER_END to batch buffer, this is not a problem if batch buffer is only used once but oa reuses the batch buffer for the same metric and at each call it appends a MI_BATCH_BUFFER_END, printing the warning below and then overflowing. [ 381.072016] ------------[ cut here ]------------ [ 381.072019] xe 0000:00:02.0: [drm] Assertion `bb->len * 4 + bb_prefetch(q->gt) <= size` failed! platform: LUNARLAKE subplatform: 1 graphics: Xe2_LPG / Xe2_HPG 20.04 step B0 media: Xe2_LPM / Xe2_HPM 20.00 step B0 tile: 0 VRAM 0 B GT: 0 type 1 So here checking if batch buffer already have MI_BATCH_BUFFER_END if not append it. v2: - simply fix, suggestion from Ashutosh (cherry picked from commit 9ba0e0f30ca42a98af3689460063edfb6315718a)", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50183", "url": "https://ubuntu.com/security/CVE-2024-50183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV instance Deleting an NPIV instance requires all fabric ndlps to be released before an NPIV's resources can be torn down. Failure to release fabric ndlps beforehand opens kref imbalance race conditions. Fix by forcing the DA_ID to complete synchronously with usage of wait_queue.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50055", "url": "https://ubuntu.com/security/CVE-2024-50055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: driver core: bus: Fix double free in driver API bus_register() For bus_register(), any error which happens after kset_register() will cause that @priv are freed twice, fixed by setting @priv with NULL after the first free.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50091", "url": "https://ubuntu.com/security/CVE-2024-50091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm vdo: don't refer to dedupe_context after releasing it Clear the dedupe_context pointer in a data_vio whenever ownership of the context is lost, so that vdo can't examine it accidentally.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50056", "url": "https://ubuntu.com/security/CVE-2024-50056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: Fix ERR_PTR dereference in uvc_v4l2.c Fix potential dereferencing of ERR_PTR() in find_format_by_pix() and uvc_v4l2_enum_format(). Fix the following smatch errors: drivers/usb/gadget/function/uvc_v4l2.c:124 find_format_by_pix() error: 'fmtdesc' dereferencing possible ERR_PTR() drivers/usb/gadget/function/uvc_v4l2.c:392 uvc_v4l2_enum_format() error: 'fmtdesc' dereferencing possible ERR_PTR() Also, fix similar issue in uvc_v4l2_try_format() for potential dereferencing of ERR_PTR().", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50184", "url": "https://ubuntu.com/security/CVE-2024-50184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_pmem: Check device status before requesting flush If a pmem device is in a bad status, the driver side could wait for host ack forever in virtio_pmem_flush(), causing the system to hang. So add a status check in the beginning of virtio_pmem_flush() to return early if the device is not activated.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50057", "url": "https://ubuntu.com/security/CVE-2024-50057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: tipd: Free IRQ only if it was requested before In polling mode, if no IRQ was requested there is no need to free it. Call devm_free_irq() only if client->irq is set. This fixes the warning caused by the tps6598x module removal: WARNING: CPU: 2 PID: 333 at kernel/irq/devres.c:144 devm_free_irq+0x80/0x8c ... ... Call trace: devm_free_irq+0x80/0x8c tps6598x_remove+0x28/0x88 [tps6598x] i2c_device_remove+0x2c/0x9c device_remove+0x4c/0x80 device_release_driver_internal+0x1cc/0x228 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 i2c_del_driver+0x54/0x64 tps6598x_i2c_driver_exit+0x18/0xc3c [tps6598x] __arm64_sys_delete_module+0x184/0x264 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc8/0xe8 do_el0_svc+0x20/0x2c el0_svc+0x28/0x98 el0t_64_sync_handler+0x13c/0x158 el0t_64_sync+0x190/0x194", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50058", "url": "https://ubuntu.com/security/CVE-2024-50058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: protect uart_port_dtr_rts() in uart_shutdown() too Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part 3) added few uport == NULL checks. It added one to uart_shutdown(), so the commit assumes, uport can be NULL in there. But right after that protection, there is an unprotected \"uart_port_dtr_rts(uport, false);\" call. That is invoked only if HUPCL is set, so I assume that is the reason why we do not see lots of these reports. Or it cannot be NULL at this point at all for some reason :P. Until the above is investigated, stay on the safe side and move this dereference to the if too. I got this inconsistency from Coverity under CID 1585130. Thanks.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50181", "url": "https://ubuntu.com/security/CVE-2024-50181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: imx: Remove CLK_SET_PARENT_GATE for DRAM mux for i.MX7D For i.MX7D DRAM related mux clock, the clock source change should ONLY be done done in low level asm code without accessing DRAM, and then calling clk API to sync the HW clock status with clk tree, it should never touch real clock source switch via clk API, so CLK_SET_PARENT_GATE flag should NOT be added, otherwise, DRAM's clock parent will be disabled when DRAM is active, and system will hang.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50059", "url": "https://ubuntu.com/security/CVE-2024-50059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntb: ntb_hw_switchtec: Fix use after free vulnerability in switchtec_ntb_remove due to race condition In the switchtec_ntb_add function, it can call switchtec_ntb_init_sndev function, then &sndev->check_link_status_work is bound with check_link_status_work. switchtec_ntb_link_notification may be called to start the work. If we remove the module which will call switchtec_ntb_remove to make cleanup, it will free sndev through kfree(sndev), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | check_link_status_work switchtec_ntb_remove | kfree(sndev); | | if (sndev->link_force_down) | // use sndev Fix it by ensuring that the work is canceled before proceeding with the cleanup in switchtec_ntb_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50060", "url": "https://ubuntu.com/security/CVE-2024-50060", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring: check if we need to reschedule during overflow flush In terms of normal application usage, this list will always be empty. And if an application does overflow a bit, it'll have a few entries. However, nothing obviously prevents syzbot from running a test case that generates a ton of overflow entries, and then flushing them can take quite a while. Check for needing to reschedule while flushing, and drop our locks and do so if necessary. There's no state to maintain here as overflows always prune from head-of-list, hence it's fine to drop and reacquire the locks at the end of the loop.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50061", "url": "https://ubuntu.com/security/CVE-2024-50061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: cdns: Fix use after free vulnerability in cdns_i3c_master Driver Due to Race Condition In the cdns_i3c_master_probe function, &master->hj_work is bound with cdns_i3c_master_hj. And cdns_i3c_master_interrupt can call cnds_i3c_master_demux_ibis function to start the work. If we remove the module which will call cdns_i3c_master_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | cdns_i3c_master_hj cdns_i3c_master_remove | i3c_master_unregister(&master->base) | device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in cdns_i3c_master_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50062", "url": "https://ubuntu.com/security/CVE-2024-50062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-srv: Avoid null pointer deref during path establishment For RTRS path establishment, RTRS client initiates and completes con_num of connections. After establishing all its connections, the information is exchanged between the client and server through the info_req message. During this exchange, it is essential that all connections have been established, and the state of the RTRS srv path is CONNECTED. So add these sanity checks, to make sure we detect and abort process in error scenarios to avoid null pointer deref.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50095", "url": "https://ubuntu.com/security/CVE-2024-50095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mad: Improve handling of timed out WRs of mad agent Current timeout handler of mad agent acquires/releases mad_agent_priv lock for every timed out WRs. This causes heavy locking contention when higher no. of WRs are to be handled inside timeout handler. This leads to softlockup with below trace in some use cases where rdma-cm path is used to establish connection between peer nodes Trace: ----- BUG: soft lockup - CPU#4 stuck for 26s! [kworker/u128:3:19767] CPU: 4 PID: 19767 Comm: kworker/u128:3 Kdump: loaded Tainted: G OE ------- --- 5.14.0-427.13.1.el9_4.x86_64 #1 Hardware name: Dell Inc. PowerEdge R740/01YM03, BIOS 2.4.8 11/26/2019 Workqueue: ib_mad1 timeout_sends [ib_core] RIP: 0010:__do_softirq+0x78/0x2ac RSP: 0018:ffffb253449e4f98 EFLAGS: 00000246 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 000000000000001f RDX: 000000000000001d RSI: 000000003d1879ab RDI: fff363b66fd3a86b RBP: ffffb253604cbcd8 R08: 0000009065635f3b R09: 0000000000000000 R10: 0000000000000040 R11: ffffb253449e4ff8 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000040 FS: 0000000000000000(0000) GS:ffff8caa1fc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd9ec9db900 CR3: 0000000891934006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? __irq_exit_rcu+0xa1/0xc0 ? watchdog_timer_fn+0x1b2/0x210 ? __pfx_watchdog_timer_fn+0x10/0x10 ? __hrtimer_run_queues+0x127/0x2c0 ? hrtimer_interrupt+0xfc/0x210 ? __sysvec_apic_timer_interrupt+0x5c/0x110 ? sysvec_apic_timer_interrupt+0x37/0x90 ? asm_sysvec_apic_timer_interrupt+0x16/0x20 ? __do_softirq+0x78/0x2ac ? __do_softirq+0x60/0x2ac __irq_exit_rcu+0xa1/0xc0 sysvec_call_function_single+0x72/0x90 asm_sysvec_call_function_single+0x16/0x20 RIP: 0010:_raw_spin_unlock_irq+0x14/0x30 RSP: 0018:ffffb253604cbd88 EFLAGS: 00000247 RAX: 000000000001960d RBX: 0000000000000002 RCX: ffff8cad2a064800 RDX: 000000008020001b RSI: 0000000000000001 RDI: ffff8cad5d39f66c RBP: ffff8cad5d39f600 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8caa443e0c00 R11: ffffb253604cbcd8 R12: ffff8cacb8682538 R13: 0000000000000005 R14: ffffb253604cbd90 R15: ffff8cad5d39f66c cm_process_send_error+0x122/0x1d0 [ib_cm] timeout_sends+0x1dd/0x270 [ib_core] process_one_work+0x1e2/0x3b0 ? __pfx_worker_thread+0x10/0x10 worker_thread+0x50/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xdd/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x50 Simplified timeout handler by creating local list of timed out WRs and invoke send handler post creating the list. The new method acquires/ releases lock once to fetch the list and hence helps to reduce locking contetiong when processing higher no. of WRs", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50063", "url": "https://ubuntu.com/security/CVE-2024-50063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Prevent tail call between progs attached to different hooks bpf progs can be attached to kernel functions, and the attached functions can take different parameters or return different return values. If prog attached to one kernel function tail calls prog attached to another kernel function, the ctx access or return value verification could be bypassed. For example, if prog1 is attached to func1 which takes only 1 parameter and prog2 is attached to func2 which takes two parameters. Since verifier assumes the bpf ctx passed to prog2 is constructed based on func2's prototype, verifier allows prog2 to access the second parameter from the bpf ctx passed to it. The problem is that verifier does not prevent prog1 from passing its bpf ctx to prog2 via tail call. In this case, the bpf ctx passed to prog2 is constructed from func1 instead of func2, that is, the assumption for ctx access verification is bypassed. Another example, if BPF LSM prog1 is attached to hook file_alloc_security, and BPF LSM prog2 is attached to hook bpf_lsm_audit_rule_known. Verifier knows the return value rules for these two hooks, e.g. it is legal for bpf_lsm_audit_rule_known to return positive number 1, and it is illegal for file_alloc_security to return positive number. So verifier allows prog2 to return positive number 1, but does not allow prog1 to return positive number. The problem is that verifier does not prevent prog1 from calling prog2 via tail call. In this case, prog2's return value 1 will be used as the return value for prog1's hook file_alloc_security. That is, the return value rule is bypassed. This patch adds restriction for tail call to prevent such bypasses.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50191", "url": "https://ubuntu.com/security/CVE-2024-50191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: don't set SB_RDONLY after filesystem errors When the filesystem is mounted with errors=remount-ro, we were setting SB_RDONLY flag to stop all filesystem modifications. We knew this misses proper locking (sb->s_umount) and does not go through proper filesystem remount procedure but it has been the way this worked since early ext2 days and it was good enough for catastrophic situation damage mitigation. Recently, syzbot has found a way (see link) to trigger warnings in filesystem freezing because the code got confused by SB_RDONLY changing under its hands. Since these days we set EXT4_FLAGS_SHUTDOWN on the superblock which is enough to stop all filesystem modifications, modifying SB_RDONLY shouldn't be needed. So stop doing that.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50064", "url": "https://ubuntu.com/security/CVE-2024-50064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: zram: free secondary algorithms names We need to kfree() secondary algorithms names when reset zram device that had multi-streams, otherwise we leak memory. [senozhatsky@chromium.org: kfree(NULL) is legal] Link: https://lkml.kernel.org/r/20240917013021.868769-1-senozhatsky@chromium.org", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50065", "url": "https://ubuntu.com/security/CVE-2024-50065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Change to non-blocking allocation in ntfs_d_hash d_hash is done while under \"rcu-walk\" and should not sleep. __get_name() allocates using GFP_KERNEL, having the possibility to sleep when under memory pressure. Change the allocation to GFP_NOWAIT.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50089", "url": "https://ubuntu.com/security/CVE-2024-50089", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-49863", "url": "https://ubuntu.com/security/CVE-2024-49863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost/scsi: null-ptr-dereference in vhost_scsi_get_req() Since commit 3f8ca2e115e5 (\"vhost/scsi: Extract common handling code from control queue handler\") a null pointer dereference bug can be triggered when guest sends an SCSI AN request. In vhost_scsi_ctl_handle_vq(), `vc.target` is assigned with `&v_req.tmf.lun[1]` within a switch-case block and is then passed to vhost_scsi_get_req() which extracts `vc->req` and `tpg`. However, for a `VIRTIO_SCSI_T_AN_*` request, tpg is not required, so `vc.target` is set to NULL in this branch. Later, in vhost_scsi_get_req(), `vc->target` is dereferenced without being checked, leading to a null pointer dereference bug. This bug can be triggered from guest. When this bug occurs, the vhost_worker process is killed while holding `vq->mutex` and the corresponding tpg will remain occupied indefinitely. Below is the KASAN report: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 PID: 840 Comm: poc Not tainted 6.10.0+ #1 Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:vhost_scsi_get_req+0x165/0x3a0 Code: 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 02 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 65 30 4c 89 e2 48 c1 ea 03 <0f> b6 04 02 4c 89 e2 83 e2 07 38 d0 7f 08 84 c0 0f 85 be 01 00 00 RSP: 0018:ffff888017affb50 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffff88801b000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888017affcb8 RBP: ffff888017affb80 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff888017affc88 R14: ffff888017affd1c R15: ffff888017993000 FS: 000055556e076500(0000) GS:ffff88806b100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200027c0 CR3: 0000000010ed0004 CR4: 0000000000370ef0 Call Trace: ? show_regs+0x86/0xa0 ? die_addr+0x4b/0xd0 ? exc_general_protection+0x163/0x260 ? asm_exc_general_protection+0x27/0x30 ? vhost_scsi_get_req+0x165/0x3a0 vhost_scsi_ctl_handle_vq+0x2a4/0xca0 ? __pfx_vhost_scsi_ctl_handle_vq+0x10/0x10 ? __switch_to+0x721/0xeb0 ? __schedule+0xda5/0x5710 ? __kasan_check_write+0x14/0x30 ? _raw_spin_lock+0x82/0xf0 vhost_scsi_ctl_handle_kick+0x52/0x90 vhost_run_work_list+0x134/0x1b0 vhost_task_fn+0x121/0x350 ... ---[ end trace 0000000000000000 ]--- Let's add a check in vhost_scsi_get_req. [whitespace fixes]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49864", "url": "https://ubuntu.com/security/CVE-2024-49864", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix a race between socket set up and I/O thread creation In rxrpc_open_socket(), it sets up the socket and then sets up the I/O thread that will handle it. This is a problem, however, as there's a gap between the two phases in which a packet may come into rxrpc_encap_rcv() from the UDP packet but we oops when trying to wake the not-yet created I/O thread. As a quick fix, just make rxrpc_encap_rcv() discard the packet if there's no I/O thread yet. A better, but more intrusive fix would perhaps be to rearrange things such that the socket creation is done by the I/O thread.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49865", "url": "https://ubuntu.com/security/CVE-2024-49865", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: move xa_alloc to prevent UAF Evil user can guess the next id of the vm before the ioctl completes and then call vm destroy ioctl to trigger UAF since create ioctl is still referencing the same vm. Move the xa_alloc all the way to the end to prevent this. v2: - Rebase (cherry picked from commit dcfd3971327f3ee92765154baebbaece833d3ca9)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49955", "url": "https://ubuntu.com/security/CVE-2024-49955", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: battery: Fix possible crash when unregistering a battery hook When a battery hook returns an error when adding a new battery, then the battery hook is automatically unregistered. However the battery hook provider cannot know that, so it will later call battery_hook_unregister() on the already unregistered battery hook, resulting in a crash. Fix this by using the list head to mark already unregistered battery hooks as already being unregistered so that they can be ignored by battery_hook_unregister().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49973", "url": "https://ubuntu.com/security/CVE-2024-49973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: r8169: add tally counter fields added with RTL8125 RTL8125 added fields to the tally counter, what may result in the chip dma'ing these new fields to unallocated memory. Therefore make sure that the allocated memory area is big enough to hold all of the tally counter values, even if we use only parts of it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49974", "url": "https://ubuntu.com/security/CVE-2024-49974", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Limit the number of concurrent async COPY operations Nothing appears to limit the number of concurrent async COPY operations that clients can start. In addition, AFAICT each async COPY can copy an unlimited number of 4MB chunks, so can run for a long time. Thus IMO async COPY can become a DoS vector. Add a restriction mechanism that bounds the number of concurrent background COPY operations. Start simple and try to be fair -- this patch implements a per-namespace limit. An async COPY request that occurs while this limit is exceeded gets NFS4ERR_DELAY. The requesting client can choose to send the request again after a delay or fall back to a traditional read/write style copy. If there is need to make the mechanism more sophisticated, we can visit that in future patches.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49975", "url": "https://ubuntu.com/security/CVE-2024-49975", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uprobes: fix kernel info leak via \"[uprobes]\" vma xol_add_vma() maps the uninitialized page allocated by __create_xol_area() into userspace. On some architectures (x86) this memory is readable even without VM_READ, VM_EXEC results in the same pgprot_t as VM_EXEC|VM_READ, although this doesn't really matter, debugger can read this memory anyway.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50003", "url": "https://ubuntu.com/security/CVE-2024-50003", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix system hang while resume with TBT monitor [Why] Connected with a Thunderbolt monitor and do the suspend and the system may hang while resume. The TBT monitor HPD will be triggered during the resume procedure and call the drm_client_modeset_probe() while struct drm_connector connector->dev->master is NULL. It will mess up the pipe topology after resume. [How] Skip the TBT monitor HPD during the resume procedure because we currently will probe the connectors after resume by default. (cherry picked from commit 453f86a26945207a16b8f66aaed5962dc2b95b85)", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50173", "url": "https://ubuntu.com/security/CVE-2024-50173", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix access to uninitialized variable in tick_ctx_cleanup() The group variable can't be used to retrieve ptdev in our second loop, because it points to the previously iterated list_head, not a valid group. Get the ptdev object from the scheduler instead.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49866", "url": "https://ubuntu.com/security/CVE-2024-49866", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Fix a race during cpuhp processing There is another found exception that the \"timerlat/1\" thread was scheduled on CPU0, and lead to timer corruption finally: ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ``` After tracing the scheduling event, it was discovered that the migration of the \"timerlat/1\" thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() | To fix this, skip online processing if the CPU is already offline.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49976", "url": "https://ubuntu.com/security/CVE-2024-49976", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Drop interface_lock in stop_kthread() stop_kthread() is the offline callback for \"trace/osnoise:online\", since commit 5bfbcd1ee57b (\"tracing/timerlat: Add interface_lock around clearing of kthread in stop_kthread()\"), the following ABBA deadlock scenario is introduced: T1 | T2 [BP] | T3 [AP] osnoise_hotplug_workfn() | work_for_cpu_fn() | cpuhp_thread_fun() | _cpu_down() | osnoise_cpu_die() mutex_lock(&interface_lock) | | stop_kthread() | cpus_write_lock() | mutex_lock(&interface_lock) cpus_read_lock() | cpuhp_kick_ap() | As the interface_lock here in just for protecting the \"kthread\" field of the osn_var, use xchg() instead to fix this issue. Also use for_each_online_cpu() back in stop_per_cpu_kthreads() as it can take cpu_read_lock() again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50005", "url": "https://ubuntu.com/security/CVE-2024-50005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: Fix potential RCU dereference issue in mac802154_scan_worker In the `mac802154_scan_worker` function, the `scan_req->type` field was accessed after the RCU read-side critical section was unlocked. According to RCU usage rules, this is illegal and can lead to unpredictable behavior, such as accessing memory that has been updated or causing use-after-free issues. This possible bug was identified using a static analysis tool developed by myself, specifically designed to detect RCU-related issues. To address this, the `scan_req->type` value is now stored in a local variable `scan_req_type` while still within the RCU read-side critical section. The `scan_req_type` is then used after the RCU lock is released, ensuring that the type value is safely accessed without violating RCU rules.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50012", "url": "https://ubuntu.com/security/CVE-2024-50012", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: Avoid a bad reference count on CPU node In the parse_perf_domain function, if the call to of_parse_phandle_with_args returns an error, then the reference to the CPU device node that was acquired at the start of the function would not be properly decremented. Address this by declaring the variable with the __free(device_node) cleanup attribute.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49867", "url": "https://ubuntu.com/security/CVE-2024-49867", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: wait for fixup workers before stopping cleaner kthread during umount During unmount, at close_ctree(), we have the following steps in this order: 1) Park the cleaner kthread - this doesn't destroy the kthread, it basically halts its execution (wake ups against it work but do nothing); 2) We stop the cleaner kthread - this results in freeing the respective struct task_struct; 3) We call btrfs_stop_all_workers() which waits for any jobs running in all the work queues and then free the work queues. Syzbot reported a case where a fixup worker resulted in a crash when doing a delayed iput on its inode while attempting to wake up the cleaner at btrfs_add_delayed_iput(), because the task_struct of the cleaner kthread was already freed. This can happen during unmount because we don't wait for any fixup workers still running before we call kthread_stop() against the cleaner kthread, which stops and free all its resources. Fix this by waiting for any fixup workers at close_ctree() before we call kthread_stop() against the cleaner and run pending delayed iputs. The stack traces reported by syzbot were the following: BUG: KASAN: slab-use-after-free in __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 Read of size 8 at addr ffff8880272a8a18 by task kworker/u8:3/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.12.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: btrfs-fixup btrfs_work_helper 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 __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline] try_to_wake_up+0xb0/0x1480 kernel/sched/core.c:4154 btrfs_writepage_fixup_worker+0xc16/0xdf0 fs/btrfs/inode.c:2842 btrfs_work_helper+0x390/0xc50 fs/btrfs/async-thread.c:314 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Allocated by task 2: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:319 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345 kasan_slab_alloc include/linux/kasan.h:247 [inline] slab_post_alloc_hook mm/slub.c:4086 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4187 alloc_task_struct_node kernel/fork.c:180 [inline] dup_task_struct+0x57/0x8c0 kernel/fork.c:1107 copy_process+0x5d1/0x3d50 kernel/fork.c:2206 kernel_clone+0x223/0x880 kernel/fork.c:2787 kernel_thread+0x1bc/0x240 kernel/fork.c:2849 create_kthread kernel/kthread.c:412 [inline] kthreadd+0x60d/0x810 kernel/kthread.c:765 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Freed by task 61: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:230 [inline] slab_free_h ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49868", "url": "https://ubuntu.com/security/CVE-2024-49868", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix a NULL pointer dereference when failed to start a new trasacntion [BUG] Syzbot reported a NULL pointer dereference with the following crash: FAULT_INJECTION: forcing a failure. start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676 prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642 relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678 ... BTRFS info (device loop0): balance: ended with status: -12 Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667] RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926 Call Trace: commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496 btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430 del_balance_item fs/btrfs/volumes.c:3678 [inline] reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742 btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574 btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673 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/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [CAUSE] The allocation failure happens at the start_transaction() inside prepare_to_relocate(), and during the error handling we call unset_reloc_control(), which makes fs_info->balance_ctl to be NULL. Then we continue the error path cleanup in btrfs_balance() by calling reset_balance_state() which will call del_balance_item() to fully delete the balance item in the root tree. However during the small window between set_reloc_contrl() and unset_reloc_control(), we can have a subvolume tree update and created a reloc_root for that subvolume. Then we go into the final btrfs_commit_transaction() of del_balance_item(), and into btrfs_update_reloc_root() inside commit_fs_roots(). That function checks if fs_info->reloc_ctl is in the merge_reloc_tree stage, but since fs_info->reloc_ctl is NULL, it results a NULL pointer dereference. [FIX] Just add extra check on fs_info->reloc_ctl inside btrfs_update_reloc_root(), before checking fs_info->reloc_ctl->merge_reloc_tree. That DEAD_RELOC_TREE handling is to prevent further modification to the reloc tree during merge stage, but since there is no reloc_ctl at all, we do not need to bother that.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49869", "url": "https://ubuntu.com/security/CVE-2024-49869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: send: fix buffer overflow detection when copying path to cache entry Starting with commit c0247d289e73 (\"btrfs: send: annotate struct name_cache_entry with __counted_by()\") we annotated the variable length array \"name\" from the name_cache_entry structure with __counted_by() to improve overflow detection. However that alone was not correct, because the length of that array does not match the \"name_len\" field - it matches that plus 1 to include the NUL string terminator, so that makes a fortified kernel think there's an overflow and report a splat like this: strcpy: detected buffer overflow: 20 byte write of buffer size 19 WARNING: CPU: 3 PID: 3310 at __fortify_report+0x45/0x50 CPU: 3 UID: 0 PID: 3310 Comm: btrfs Not tainted 6.11.0-prnet #1 Hardware name: CompuLab Ltd. sbc-ihsw/Intense-PC2 (IPC2), BIOS IPC2_3.330.7 X64 03/15/2018 RIP: 0010:__fortify_report+0x45/0x50 Code: 48 8b 34 (...) RSP: 0018:ffff97ebc0d6f650 EFLAGS: 00010246 RAX: 7749924ef60fa600 RBX: ffff8bf5446a521a RCX: 0000000000000027 RDX: 00000000ffffdfff RSI: ffff97ebc0d6f548 RDI: ffff8bf84e7a1cc8 RBP: ffff8bf548574080 R08: ffffffffa8c40e10 R09: 0000000000005ffd R10: 0000000000000004 R11: ffffffffa8c70e10 R12: ffff8bf551eef400 R13: 0000000000000000 R14: 0000000000000013 R15: 00000000000003a8 FS: 00007fae144de8c0(0000) GS:ffff8bf84e780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fae14691690 CR3: 00000001027a2003 CR4: 00000000001706f0 Call Trace: ? __warn+0x12a/0x1d0 ? __fortify_report+0x45/0x50 ? report_bug+0x154/0x1c0 ? handle_bug+0x42/0x70 ? exc_invalid_op+0x1a/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? __fortify_report+0x45/0x50 __fortify_panic+0x9/0x10 __get_cur_name_and_parent+0x3bc/0x3c0 get_cur_path+0x207/0x3b0 send_extent_data+0x709/0x10d0 ? find_parent_nodes+0x22df/0x25d0 ? mas_nomem+0x13/0x90 ? mtree_insert_range+0xa5/0x110 ? btrfs_lru_cache_store+0x5f/0x1e0 ? iterate_extent_inodes+0x52d/0x5a0 process_extent+0xa96/0x11a0 ? __pfx_lookup_backref_cache+0x10/0x10 ? __pfx_store_backref_cache+0x10/0x10 ? __pfx_iterate_backrefs+0x10/0x10 ? __pfx_check_extent_item+0x10/0x10 changed_cb+0x6fa/0x930 ? tree_advance+0x362/0x390 ? memcmp_extent_buffer+0xd7/0x160 send_subvol+0xf0a/0x1520 btrfs_ioctl_send+0x106b/0x11d0 ? __pfx___clone_root_cmp_sort+0x10/0x10 _btrfs_ioctl_send+0x1ac/0x240 btrfs_ioctl+0x75b/0x850 __se_sys_ioctl+0xca/0x150 do_syscall_64+0x85/0x160 ? __count_memcg_events+0x69/0x100 ? handle_mm_fault+0x1327/0x15c0 ? __se_sys_rt_sigprocmask+0xf1/0x180 ? syscall_exit_to_user_mode+0x75/0xa0 ? do_syscall_64+0x91/0x160 ? do_user_addr_fault+0x21d/0x630 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fae145eeb4f Code: 00 48 89 (...) RSP: 002b:00007ffdf1cb09b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fae145eeb4f RDX: 00007ffdf1cb0ad0 RSI: 0000000040489426 RDI: 0000000000000004 RBP: 00000000000078fe R08: 00007fae144006c0 R09: 00007ffdf1cb0927 R10: 0000000000000008 R11: 0000000000000246 R12: 00007ffdf1cb1ce8 R13: 0000000000000003 R14: 000055c499fab2e0 R15: 0000000000000004 Fix this by not storing the NUL string terminator since we don't actually need it for name cache entries, this way \"name_len\" corresponds to the actual size of the \"name\" array. This requires marking the \"name\" array field with __nonstring and using memcpy() instead of strcpy() as recommended by the guidelines at: https://github.com/KSPP/linux/issues/90", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49870", "url": "https://ubuntu.com/security/CVE-2024-49870", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cachefiles: fix dentry leak in cachefiles_open_file() A dentry leak may be caused when a lookup cookie and a cull are concurrent: P1 | P2 ----------------------------------------------------------- cachefiles_lookup_cookie cachefiles_look_up_object lookup_one_positive_unlocked // get dentry cachefiles_cull inode->i_flags |= S_KERNEL_FILE; cachefiles_open_file cachefiles_mark_inode_in_use __cachefiles_mark_inode_in_use can_use = false if (!(inode->i_flags & S_KERNEL_FILE)) can_use = true \t return false return false // Returns an error but doesn't put dentry After that the following WARNING will be triggered when the backend folder is umounted: ================================================================== BUG: Dentry 000000008ad87947{i=7a,n=Dx_1_1.img} still in use (1) [unmount of ext4 sda] WARNING: CPU: 4 PID: 359261 at fs/dcache.c:1767 umount_check+0x5d/0x70 CPU: 4 PID: 359261 Comm: umount Not tainted 6.6.0-dirty #25 RIP: 0010:umount_check+0x5d/0x70 Call Trace: d_walk+0xda/0x2b0 do_one_tree+0x20/0x40 shrink_dcache_for_umount+0x2c/0x90 generic_shutdown_super+0x20/0x160 kill_block_super+0x1a/0x40 ext4_kill_sb+0x22/0x40 deactivate_locked_super+0x35/0x80 cleanup_mnt+0x104/0x160 ================================================================== Whether cachefiles_open_file() returns true or false, the reference count obtained by lookup_positive_unlocked() in cachefiles_look_up_object() should be released. Therefore release that reference count in cachefiles_look_up_object() to fix the above issue and simplify the code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49871", "url": "https://ubuntu.com/security/CVE-2024-49871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: adp5589-keys - fix NULL pointer dereference We register a devm action to call adp5589_clear_config() and then pass the i2c client as argument so that we can call i2c_get_clientdata() in order to get our device object. However, i2c_set_clientdata() is only being set at the end of the probe function which means that we'll get a NULL pointer dereference in case the probe function fails early.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49872", "url": "https://ubuntu.com/security/CVE-2024-49872", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/gup: fix memfd_pin_folios alloc race panic If memfd_pin_folios tries to create a hugetlb page, but someone else already did, then folio gets the value -EEXIST here: folio = memfd_alloc_folio(memfd, start_idx); if (IS_ERR(folio)) { ret = PTR_ERR(folio); if (ret != -EEXIST) goto err; then on the next trip through the \"while start_idx\" loop we panic here: if (folio) { folio_put(folio); To fix, set the folio to NULL on error.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49964", "url": "https://ubuntu.com/security/CVE-2024-49964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix memfd_pin_folios free_huge_pages leak memfd_pin_folios followed by unpin_folios fails to restore free_huge_pages if the pages were not already faulted in, because the folio refcount for pages created by memfd_alloc_folio never goes to 0. memfd_pin_folios needs another folio_put to undo the folio_try_get below: memfd_alloc_folio() alloc_hugetlb_folio_nodemask() dequeue_hugetlb_folio_nodemask() dequeue_hugetlb_folio_node_exact() folio_ref_unfreeze(folio, 1); ; adds 1 refcount folio_try_get() ; adds 1 refcount hugetlb_add_to_page_cache() ; adds 512 refcount (on x86) With the fix, after memfd_pin_folios + unpin_folios, the refcount for the (unfaulted) page is 512, which is correct, as the refcount for a faulted unpinned page is 513.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49873", "url": "https://ubuntu.com/security/CVE-2024-49873", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/filemap: fix filemap_get_folios_contig THP panic Patch series \"memfd-pin huge page fixes\". Fix multiple bugs that occur when using memfd_pin_folios with hugetlb pages and THP. The hugetlb bugs only bite when the page is not yet faulted in when memfd_pin_folios is called. The THP bug bites when the starting offset passed to memfd_pin_folios is not huge page aligned. See the commit messages for details. This patch (of 5): memfd_pin_folios on memory backed by THP panics if the requested start offset is not huge page aligned: BUG: kernel NULL pointer dereference, address: 0000000000000036 RIP: 0010:filemap_get_folios_contig+0xdf/0x290 RSP: 0018:ffffc9002092fbe8 EFLAGS: 00010202 RAX: 0000000000000002 RBX: 0000000000000002 RCX: 0000000000000002 The fault occurs here, because xas_load returns a folio with value 2: filemap_get_folios_contig() for (folio = xas_load(&xas); folio && xas.xa_index <= end; folio = xas_next(&xas)) { ... if (!folio_try_get(folio)) <-- BOOM \"2\" is an xarray sibling entry. We get it because memfd_pin_folios does not round the indices passed to filemap_get_folios_contig to huge page boundaries for THP, so we load from the middle of a huge page range see a sibling. (It does round for hugetlbfs, at the is_file_hugepages test). To fix, if the folio is a sibling, then return the next index as the starting point for the next call to filemap_get_folios_contig.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49977", "url": "https://ubuntu.com/security/CVE-2024-49977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: Fix zero-division error when disabling tc cbs The commit b8c43360f6e4 (\"net: stmmac: No need to calculate speed divider when offload is disabled\") allows the \"port_transmit_rate_kbps\" to be set to a value of 0, which is then passed to the \"div_s64\" function when tc-cbs is disabled. This leads to a zero-division error. When tc-cbs is disabled, the idleslope, sendslope, and credit values the credit values are not required to be configured. Therefore, adding a return statement after setting the txQ mode to DCB when tc-cbs is disabled would prevent a zero-division error.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49978", "url": "https://ubuntu.com/security/CVE-2024-49978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gso: fix udp gso fraglist segmentation after pull from frag_list Detect gso fraglist skbs with corrupted geometry (see below) and pass these to skb_segment instead of skb_segment_list, as the first can segment them correctly. 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 these skbs, breaking these invariants. In extreme cases they pull all data into skb linear. For UDP, this causes a NULL ptr deref in __udpv4_gso_segment_list_csum at udp_hdr(seg->next)->dest. Detect invalid geometry due to pull, by checking head_skb size. Don't just drop, as this may blackhole a destination. Convert to be able to pass to regular skb_segment.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49979", "url": "https://ubuntu.com/security/CVE-2024-49979", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gso: fix tcp fraglist segmentation after pull from frag_list Detect tcp gso fraglist skbs with corrupted geometry (see below) and pass these to skb_segment instead of skb_segment_list, as the first can segment them correctly. 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 these skbs, breaking these invariants. In extreme cases they pull all data into skb linear. For TCP, this causes a NULL ptr deref in __tcpv4_gso_segment_list_csum at tcp_hdr(seg->next). Detect invalid geometry due to pull, by checking head_skb size. Don't just drop, as this may blackhole a destination. Convert to be able to pass to regular skb_segment. Approach and description based on a patch by Willem de Bruijn.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49980", "url": "https://ubuntu.com/security/CVE-2024-49980", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vrf: revert \"vrf: Remove unnecessary RCU-bh critical section\" This reverts commit 504fc6f4f7f681d2a03aa5f68aad549d90eab853. dev_queue_xmit_nit is expected to be called with BH disabled. __dev_queue_xmit has the following: /* Disable soft irqs for various locks below. Also * stops preemption for RCU. */ rcu_read_lock_bh(); VRF must follow this invariant. The referenced commit removed this protection. Which triggered a lockdep warning: \t================================ \tWARNING: inconsistent lock state \t6.11.0 #1 Tainted: G W \t-------------------------------- \tinconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage. \tbtserver/134819 [HC0[0]:SC0[0]:HE1:SE1] takes: \tffff8882da30c118 (rlock-AF_PACKET){+.?.}-{2:2}, at: tpacket_rcv+0x863/0x3b30 \t{IN-SOFTIRQ-W} state was registered at: \t lock_acquire+0x19a/0x4f0 \t _raw_spin_lock+0x27/0x40 \t packet_rcv+0xa33/0x1320 \t __netif_receive_skb_core.constprop.0+0xcb0/0x3a90 \t __netif_receive_skb_list_core+0x2c9/0x890 \t netif_receive_skb_list_internal+0x610/0xcc0 [...] \tother info that might help us debug this: \t Possible unsafe locking scenario: \t CPU0 \t ---- \t lock(rlock-AF_PACKET); \t \t lock(rlock-AF_PACKET); \t *** DEADLOCK *** \tCall Trace: \t \t dump_stack_lvl+0x73/0xa0 \t mark_lock+0x102e/0x16b0 \t __lock_acquire+0x9ae/0x6170 \t lock_acquire+0x19a/0x4f0 \t _raw_spin_lock+0x27/0x40 \t tpacket_rcv+0x863/0x3b30 \t dev_queue_xmit_nit+0x709/0xa40 \t vrf_finish_direct+0x26e/0x340 [vrf] \t vrf_l3_out+0x5f4/0xe80 [vrf] \t __ip_local_out+0x51e/0x7a0 [...]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49981", "url": "https://ubuntu.com/security/CVE-2024-49981", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: venus: fix use after free bug in venus_remove due to race condition in venus_probe, core->work is bound with venus_sys_error_handler, which is used to handle error. The code use core->sys_err_done to make sync work. The core->work is started in venus_event_notify. If we call venus_remove, there might be an unfished work. The possible sequence is as follows: CPU0 CPU1 |venus_sys_error_handler venus_remove | hfi_destroy\t \t\t | venus_hfi_destroy\t | kfree(hdev);\t | |hfi_reinit \t\t\t\t\t |venus_hfi_queues_reinit |//use hdev Fix it by canceling the work in venus_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49956", "url": "https://ubuntu.com/security/CVE-2024-49956", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: fix double destroy_workqueue error When gfs2_fill_super() fails, destroy_workqueue() is called within gfs2_gl_hash_clear(), and the subsequent code path calls destroy_workqueue() on the same work queue again. This issue can be fixed by setting the work queue pointer to NULL after the first destroy_workqueue() call and checking for a NULL pointer before attempting to destroy the work queue again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50176", "url": "https://ubuntu.com/security/CVE-2024-50176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: k3-r5: Fix error handling when power-up failed By simply bailing out, the driver was violating its rule and internal assumptions that either both or no rproc should be initialized. E.g., this could cause the first core to be available but not the second one, leading to crashes on its shutdown later on while trying to dereference that second instance.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49982", "url": "https://ubuntu.com/security/CVE-2024-49982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: aoe: fix the potential use-after-free problem in more places For fixing CVE-2023-6270, f98364e92662 (\"aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts\") makes tx() calling dev_put() instead of doing in aoecmd_cfg_pkts(). It avoids that the tx() runs into use-after-free. Then Nicolai Stange found more places in aoe have potential use-after-free problem with tx(). e.g. revalidate(), aoecmd_ata_rw(), resend(), probe() and aoecmd_cfg_rsp(). Those functions also use aoenet_xmit() to push packet to tx queue. So they should also use dev_hold() to increase the refcnt of skb->dev. On the other hand, moving dev_put() to tx() causes that the refcnt of skb->dev be reduced to a negative value, because corresponding dev_hold() are not called in revalidate(), aoecmd_ata_rw(), resend(), probe(), and aoecmd_cfg_rsp(). This patch fixed this issue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49874", "url": "https://ubuntu.com/security/CVE-2024-49874", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: svc: Fix use after free vulnerability in svc_i3c_master Driver Due to Race Condition In the svc_i3c_master_probe function, &master->hj_work is bound with svc_i3c_master_hj_work, &master->ibi_work is bound with svc_i3c_master_ibi_work. And svc_i3c_master_ibi_work can start the hj_work, svc_i3c_master_irq_handler can start the ibi_work. If we remove the module which will call svc_i3c_master_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | svc_i3c_master_hj_work svc_i3c_master_remove | i3c_master_unregister(&master->base)| device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in svc_i3c_master_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49875", "url": "https://ubuntu.com/security/CVE-2024-49875", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: map the EBADMSG to nfserr_io to avoid warning Ext4 will throw -EBADMSG through ext4_readdir when a checksum error occurs, resulting in the following WARNING. Fix it by mapping EBADMSG to nfserr_io. nfsd_buffered_readdir iterate_dir // -EBADMSG -74 ext4_readdir // .iterate_shared ext4_dx_readdir ext4_htree_fill_tree htree_dirblock_to_tree ext4_read_dirblock __ext4_read_dirblock ext4_dirblock_csum_verify warn_no_space_for_csum __warn_no_space_for_csum return ERR_PTR(-EFSBADCRC) // -EBADMSG -74 nfserrno // WARNING [ 161.115610] ------------[ cut here ]------------ [ 161.116465] nfsd: non-standard errno: -74 [ 161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0 [ 161.118596] Modules linked in: [ 161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138 [ 161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qe mu.org 04/01/2014 [ 161.123601] RIP: 0010:nfserrno+0x9d/0xd0 [ 161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6 05 ce 2b 61 03 01 e8 99 20 d8 00 <0f> 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33 [ 161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286 [ 161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a [ 161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827 [ 161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021 [ 161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8 [ 161.135244] FS: 0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000 [ 161.136695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0 [ 161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 161.141519] PKRU: 55555554 [ 161.142076] Call Trace: [ 161.142575] ? __warn+0x9b/0x140 [ 161.143229] ? nfserrno+0x9d/0xd0 [ 161.143872] ? report_bug+0x125/0x150 [ 161.144595] ? handle_bug+0x41/0x90 [ 161.145284] ? exc_invalid_op+0x14/0x70 [ 161.146009] ? asm_exc_invalid_op+0x12/0x20 [ 161.146816] ? nfserrno+0x9d/0xd0 [ 161.147487] nfsd_buffered_readdir+0x28b/0x2b0 [ 161.148333] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.149258] ? nfsd_buffered_filldir+0xf0/0xf0 [ 161.150093] ? wait_for_concurrent_writes+0x170/0x170 [ 161.151004] ? generic_file_llseek_size+0x48/0x160 [ 161.151895] nfsd_readdir+0x132/0x190 [ 161.152606] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.153516] ? nfsd_unlink+0x380/0x380 [ 161.154256] ? override_creds+0x45/0x60 [ 161.155006] nfsd4_encode_readdir+0x21a/0x3d0 [ 161.155850] ? nfsd4_encode_readlink+0x210/0x210 [ 161.156731] ? write_bytes_to_xdr_buf+0x97/0xe0 [ 161.157598] ? __write_bytes_to_xdr_buf+0xd0/0xd0 [ 161.158494] ? lock_downgrade+0x90/0x90 [ 161.159232] ? nfs4svc_decode_voidarg+0x10/0x10 [ 161.160092] nfsd4_encode_operation+0x15a/0x440 [ 161.160959] nfsd4_proc_compound+0x718/0xe90 [ 161.161818] nfsd_dispatch+0x18e/0x2c0 [ 161.162586] svc_process_common+0x786/0xc50 [ 161.163403] ? nfsd_svc+0x380/0x380 [ 161.164137] ? svc_printk+0x160/0x160 [ 161.164846] ? svc_xprt_do_enqueue.part.0+0x365/0x380 [ 161.165808] ? nfsd_svc+0x380/0x380 [ 161.166523] ? rcu_is_watching+0x23/0x40 [ 161.167309] svc_process+0x1a5/0x200 [ 161.168019] nfsd+0x1f5/0x380 [ 161.168663] ? nfsd_shutdown_threads+0x260/0x260 [ 161.169554] kthread+0x1c4/0x210 [ 161.170224] ? kthread_insert_work_sanity_check+0x80/0x80 [ 161.171246] ret_from_fork+0x1f/0x30", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50013", "url": "https://ubuntu.com/security/CVE-2024-50013", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix memory leak in exfat_load_bitmap() If the first directory entry in the root directory is not a bitmap directory entry, 'bh' will not be released and reassigned, which will cause a memory leak.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49876", "url": "https://ubuntu.com/security/CVE-2024-49876", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: fix UAF around queue destruction We currently do stuff like queuing the final destruction step on a random system wq, which will outlive the driver instance. With bad timing we can teardown the driver with one or more work workqueue still being alive leading to various UAF splats. Add a fini step to ensure user queues are properly torn down. At this point GuC should already be nuked so queue itself should no longer be referenced from hw pov. v2 (Matt B) - Looks much safer to use a waitqueue and then just wait for the xa_array to become empty before triggering the drain. (cherry picked from commit 861108666cc0e999cffeab6aff17b662e68774e3)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49877", "url": "https://ubuntu.com/security/CVE-2024-49877", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate When doing cleanup, if flags without OCFS2_BH_READAHEAD, it may trigger NULL pointer dereference in the following ocfs2_set_buffer_uptodate() if bh is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49957", "url": "https://ubuntu.com/security/CVE-2024-49957", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix null-ptr-deref when journal load failed. During the mounting process, if journal_reset() fails because of too short journal, then lead to jbd2_journal_load() fails with NULL j_sb_buffer. Subsequently, ocfs2_journal_shutdown() calls jbd2_journal_flush()->jbd2_cleanup_journal_tail()-> __jbd2_update_log_tail()->jbd2_journal_update_sb_log_tail() ->lock_buffer(journal->j_sb_buffer), resulting in a null-pointer dereference error. To resolve this issue, we should check the JBD2_LOADED flag to ensure the journal was properly loaded. Additionally, use journal instead of osb->journal directly to simplify the code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49965", "url": "https://ubuntu.com/security/CVE-2024-49965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove unreasonable unlock in ocfs2_read_blocks Patch series \"Misc fixes for ocfs2_read_blocks\", v5. This series contains 2 fixes for ocfs2_read_blocks(). The first patch fix the issue reported by syzbot, which detects bad unlock balance in ocfs2_read_blocks(). The second patch fixes an issue reported by Heming Zhao when reviewing above fix. This patch (of 2): There was a lock release before exiting, so remove the unreasonable unlock.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49966", "url": "https://ubuntu.com/security/CVE-2024-49966", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: cancel dqi_sync_work before freeing oinfo ocfs2_global_read_info() will initialize and schedule dqi_sync_work at the end, if error occurs after successfully reading global quota, it will trigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled: ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16c This reports that there is an active delayed work when freeing oinfo in error handling, so cancel dqi_sync_work first. BTW, return status instead of -1 when .read_file_info fails.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49958", "url": "https://ubuntu.com/security/CVE-2024-49958", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reserve space for inline xattr before attaching reflink tree One of our customers reported a crash and a corrupted ocfs2 filesystem. The crash was due to the detection of corruption. Upon troubleshooting, the fsck -fn output showed the below corruption [EXTENT_LIST_FREE] Extent list in owner 33080590 claims 230 as the next free chain record, but fsck believes the largest valid value is 227. Clamp the next record value? n The stat output from the debugfs.ocfs2 showed the following corruption where the \"Next Free Rec:\" had overshot the \"Count:\" in the root metadata block. Inode: 33080590 Mode: 0640 Generation: 2619713622 (0x9c25a856) FS Generation: 904309833 (0x35e6ac49) CRC32: 00000000 ECC: 0000 Type: Regular Attr: 0x0 Flags: Valid Dynamic Features: (0x16) HasXattr InlineXattr Refcounted Extended Attributes Block: 0 Extended Attributes Inline Size: 256 User: 0 (root) Group: 0 (root) Size: 281320357888 Links: 1 Clusters: 141738 ctime: 0x66911b56 0x316edcb8 -- Fri Jul 12 06:02:30.829349048 2024 atime: 0x66911d6b 0x7f7a28d -- Fri Jul 12 06:11:23.133669517 2024 mtime: 0x66911b56 0x12ed75d7 -- Fri Jul 12 06:02:30.317552087 2024 dtime: 0x0 -- Wed Dec 31 17:00:00 1969 Refcount Block: 2777346 Last Extblk: 2886943 Orphan Slot: 0 Sub Alloc Slot: 0 Sub Alloc Bit: 14 Tree Depth: 1 Count: 227 Next Free Rec: 230 ## Offset Clusters Block# 0 0 2310 2776351 1 2310 2139 2777375 2 4449 1221 2778399 3 5670 731 2779423 4 6401 566 2780447 ....... .... ....... ....... .... ....... The issue was in the reflink workfow while reserving space for inline xattr. The problematic function is ocfs2_reflink_xattr_inline(). By the time this function is called the reflink tree is already recreated at the destination inode from the source inode. At this point, this function reserves space for inline xattrs at the destination inode without even checking if there is space at the root metadata block. It simply reduces the l_count from 243 to 227 thereby making space of 256 bytes for inline xattr whereas the inode already has extents beyond this index (in this case up to 230), thereby causing corruption. The fix for this is to reserve space for inline metadata at the destination inode before the reflink tree gets recreated. The customer has verified the fix.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49959", "url": "https://ubuntu.com/security/CVE-2024-49959", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail() to recover some journal space. But if an error occurs while executing jbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for free space right away, we try other branches, and if j_committing_transaction is NULL (i.e., the tid is 0), we will get the following complain: ============================================ JBD2: I/O error when updating journal superblock for sdd-8. __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available __jbd2_log_wait_for_space: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Call Trace: add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70 [...] ============================================ So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways. Note that this fix relies on commit 6f6a6fda2945 (\"jbd2: fix ocfs2 corrupt when updating journal superblock fails\") to make jbd2_cleanup_journal_tail return the correct error code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49878", "url": "https://ubuntu.com/security/CVE-2024-49878", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: resource: fix region_intersects() vs add_memory_driver_managed() On a system with CXL memory, the resource tree (/proc/iomem) related to CXL memory may look like something as follows. 490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem) Because drivers/dax/kmem.c calls add_memory_driver_managed() during onlining CXL memory, which makes \"System RAM (kmem)\" a descendant of \"CXL Window X\". This confuses region_intersects(), which expects all \"System RAM\" resources to be at the top level of iomem_resource. This can lead to bugs. For example, when the following command line is executed to write some memory in CXL memory range via /dev/mem, $ dd if=data of=/dev/mem bs=$((1 << 10)) seek=$((0x490000000 >> 10)) count=1 dd: error writing '/dev/mem': Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/s the command fails as expected. However, the error code is wrong. It should be \"Operation not permitted\" instead of \"Bad address\". More seriously, the /dev/mem permission checking in devmem_is_allowed() passes incorrectly. Although the accessing is prevented later because ioremap() isn't allowed to map system RAM, it is a potential security issue. During command executing, the following warning is reported in the kernel log for calling ioremap() on system RAM. ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d Call Trace: memremap+0xcb/0x184 xlate_dev_mem_ptr+0x25/0x2f write_mem+0x94/0xfb vfs_write+0x128/0x26d ksys_write+0xac/0xfe do_syscall_64+0x9a/0xfd entry_SYSCALL_64_after_hwframe+0x4b/0x53 The details of command execution process are as follows. In the above resource tree, \"System RAM\" is a descendant of \"CXL Window 0\" instead of a top level resource. So, region_intersects() will report no System RAM resources in the CXL memory region incorrectly, because it only checks the top level resources. Consequently, devmem_is_allowed() will return 1 (allow access via /dev/mem) for CXL memory region incorrectly. Fortunately, ioremap() doesn't allow to map System RAM and reject the access. So, region_intersects() needs to be fixed to work correctly with the resource tree with \"System RAM\" not at top level as above. To fix it, if we found a unmatched resource in the top level, we will continue to search matched resources in its descendant resources. So, we will not miss any matched resources in resource tree anymore. In the new implementation, an example resource tree |------------- \"CXL Window 0\" ------------| |-- \"System RAM\" --| will behave similar as the following fake resource tree for region_intersects(, IORESOURCE_SYSTEM_RAM, ), |-- \"System RAM\" --||-- \"CXL Window 0a\" --| Where \"CXL Window 0a\" is part of the original \"CXL Window 0\" that isn't covered by \"System RAM\".", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49879", "url": "https://ubuntu.com/security/CVE-2024-49879", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm: omapdrm: Add missing check for alloc_ordered_workqueue As it may return NULL pointer and cause NULL pointer dereference. Add check for the return value of alloc_ordered_workqueue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49880", "url": "https://ubuntu.com/security/CVE-2024-49880", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix off by one issue in alloc_flex_gd() Wesley reported an issue: ================================================================== EXT4-fs (dm-5): resizing filesystem from 7168 to 786432 blocks ------------[ cut here ]------------ kernel BUG at fs/ext4/resize.c:324! CPU: 9 UID: 0 PID: 3576 Comm: resize2fs Not tainted 6.11.0+ #27 RIP: 0010:ext4_resize_fs+0x1212/0x12d0 Call Trace: __ext4_ioctl+0x4e0/0x1800 ext4_ioctl+0x12/0x20 __x64_sys_ioctl+0x99/0xd0 x64_sys_call+0x1206/0x20d0 do_syscall_64+0x72/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e ================================================================== While reviewing the patch, Honza found that when adjusting resize_bg in alloc_flex_gd(), it was possible for flex_gd->resize_bg to be bigger than flexbg_size. The reproduction of the problem requires the following: o_group = flexbg_size * 2 * n; o_size = (o_group + 1) * group_size; n_group: [o_group + flexbg_size, o_group + flexbg_size * 2) o_size = (n_group + 1) * group_size; Take n=0,flexbg_size=16 as an example: last:15 |o---------------|--------------n-| o_group:0 resize to n_group:30 The corresponding reproducer is: img=test.img rm -f $img truncate -s 600M $img mkfs.ext4 -F $img -b 1024 -G 16 8M dev=`losetup -f --show $img` mkdir -p /tmp/test mount $dev /tmp/test resize2fs $dev 248M Delete the problematic plus 1 to fix the issue, and add a WARN_ON_ONCE() to prevent the issue from happening again. [ Note: another reproucer which this commit fixes is: img=test.img rm -f $img truncate -s 25MiB $img mkfs.ext4 -b 4096 -E nodiscard,lazy_itable_init=0,lazy_journal_init=0 $img truncate -s 3GiB $img dev=`losetup -f --show $img` mkdir -p /tmp/test mount $dev /tmp/test resize2fs $dev 3G umount $dev losetup -d $dev -- TYT ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49881", "url": "https://ubuntu.com/security/CVE-2024-49881", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: update orig_path in ext4_find_extent() In ext4_find_extent(), if the path is not big enough, we free it and set *orig_path to NULL. But after reallocating and successfully initializing the path, we don't update *orig_path, in which case the caller gets a valid path but a NULL ppath, and this may cause a NULL pointer dereference or a path memory leak. For example: ext4_split_extent path = *ppath = 2000 ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path = 2000); *orig_path = path = NULL; path = kcalloc() = 3000 ext4_split_extent_at(*ppath = NULL) path = *ppath; ex = path[depth].p_ext; // NULL pointer dereference! ================================================================== BUG: kernel NULL pointer dereference, address: 0000000000000010 CPU: 6 UID: 0 PID: 576 Comm: fsstress Not tainted 6.11.0-rc2-dirty #847 RIP: 0010:ext4_split_extent_at+0x6d/0x560 Call Trace: ext4_split_extent.isra.0+0xcb/0x1b0 ext4_ext_convert_to_initialized+0x168/0x6c0 ext4_ext_handle_unwritten_extents+0x325/0x4d0 ext4_ext_map_blocks+0x520/0xdb0 ext4_map_blocks+0x2b0/0x690 ext4_iomap_begin+0x20e/0x2c0 [...] ================================================================== Therefore, *orig_path is updated when the extent lookup succeeds, so that the caller can safely use path or *ppath.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50014", "url": "https://ubuntu.com/security/CVE-2024-50014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix access to uninitialised lock in fc replay path The following kernel trace can be triggered with fstest generic/629 when executed against a filesystem with fast-commit feature enabled: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x66/0x90 register_lock_class+0x759/0x7d0 __lock_acquire+0x85/0x2630 ? __find_get_block+0xb4/0x380 lock_acquire+0xd1/0x2d0 ? __ext4_journal_get_write_access+0xd5/0x160 _raw_spin_lock+0x33/0x40 ? __ext4_journal_get_write_access+0xd5/0x160 __ext4_journal_get_write_access+0xd5/0x160 ext4_reserve_inode_write+0x61/0xb0 __ext4_mark_inode_dirty+0x79/0x270 ? ext4_ext_replay_set_iblocks+0x2f8/0x450 ext4_ext_replay_set_iblocks+0x330/0x450 ext4_fc_replay+0x14c8/0x1540 ? jread+0x88/0x2e0 ? rcu_is_watching+0x11/0x40 do_one_pass+0x447/0xd00 jbd2_journal_recover+0x139/0x1b0 jbd2_journal_load+0x96/0x390 ext4_load_and_init_journal+0x253/0xd40 ext4_fill_super+0x2cc6/0x3180 ... In the replay path there's an attempt to lock sbi->s_bdev_wb_lock in function ext4_check_bdev_write_error(). Unfortunately, at this point this spinlock has not been initialized yet. Moving it's initialization to an earlier point in __ext4_fill_super() fixes this splat.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49960", "url": "https://ubuntu.com/security/CVE-2024-49960", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix timer use-after-free on failed mount Syzbot has found an ODEBUG bug in ext4_fill_super The del_timer_sync function cancels the s_err_report timer, which reminds about filesystem errors daily. We should guarantee the timer is no longer active before kfree(sbi). When filesystem mounting fails, the flow goes to failed_mount3, where an error occurs when ext4_stop_mmpd is called, causing a read I/O failure. This triggers the ext4_handle_error function that ultimately re-arms the timer, leaving the s_err_report timer active before kfree(sbi) is called. Fix the issue by canceling the s_err_report timer after calling ext4_stop_mmpd.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49882", "url": "https://ubuntu.com/security/CVE-2024-49882", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix double brelse() the buffer of the extents path In ext4_ext_try_to_merge_up(), set path[1].p_bh to NULL after it has been released, otherwise it may be released twice. An example of what triggers this is as follows: split2 map split1 |--------|-------|--------| ext4_ext_map_blocks ext4_ext_handle_unwritten_extents ext4_split_convert_extents // path->p_depth == 0 ext4_split_extent // 1. do split1 ext4_split_extent_at |ext4_ext_insert_extent | ext4_ext_create_new_leaf | ext4_ext_grow_indepth | le16_add_cpu(&neh->eh_depth, 1) | ext4_find_extent | // return -ENOMEM |// get error and try zeroout |path = ext4_find_extent | path->p_depth = 1 |ext4_ext_try_to_merge | ext4_ext_try_to_merge_up | path->p_depth = 0 | brelse(path[1].p_bh) ---> not set to NULL here |// zeroout success // 2. update path ext4_find_extent // 3. do split2 ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth le16_add_cpu(&neh->eh_depth, 1) ext4_find_extent path[0].p_bh = NULL; path->p_depth = 1 read_extent_tree_block ---> return err // path[1].p_bh is still the old value ext4_free_ext_path ext4_ext_drop_refs // path->p_depth == 1 brelse(path[1].p_bh) ---> brelse a buffer twice Finally got the following WARRNING when removing the buffer from lru: ============================================ VFS: brelse: Trying to free free buffer WARNING: CPU: 2 PID: 72 at fs/buffer.c:1241 __brelse+0x58/0x90 CPU: 2 PID: 72 Comm: kworker/u19:1 Not tainted 6.9.0-dirty #716 RIP: 0010:__brelse+0x58/0x90 Call Trace: __find_get_block+0x6e7/0x810 bdev_getblk+0x2b/0x480 __ext4_get_inode_loc+0x48a/0x1240 ext4_get_inode_loc+0xb2/0x150 ext4_reserve_inode_write+0xb7/0x230 __ext4_mark_inode_dirty+0x144/0x6a0 ext4_ext_insert_extent+0x9c8/0x3230 ext4_ext_map_blocks+0xf45/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] ============================================", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49883", "url": "https://ubuntu.com/security/CVE-2024-49883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: aovid use-after-free in ext4_ext_insert_extent() As Ojaswin mentioned in Link, in ext4_ext_insert_extent(), if the path is reallocated in ext4_ext_create_new_leaf(), we'll use the stale path and cause UAF. Below is a sample trace with dummy values: ext4_ext_insert_extent path = *ppath = 2000 ext4_ext_create_new_leaf(ppath) ext4_find_extent(ppath) path = *ppath = 2000 if (depth > path[0].p_maxdepth) kfree(path = 2000); *ppath = path = NULL; path = kcalloc() = 3000 *ppath = 3000; return path; /* here path is still 2000, UAF! */ eh = path[depth].p_hdr ================================================================== BUG: KASAN: slab-use-after-free in ext4_ext_insert_extent+0x26d4/0x3330 Read of size 8 at addr ffff8881027bf7d0 by task kworker/u36:1/179 CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 Not tainted 6.11.0-rc2-dirty #866 Call Trace: ext4_ext_insert_extent+0x26d4/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 [...] Allocated by task 179: ext4_find_extent+0x81c/0x1f70 ext4_ext_map_blocks+0x146/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...] Freed by task 179: kfree+0xcb/0x240 ext4_find_extent+0x7c0/0x1f70 ext4_ext_insert_extent+0xa26/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...] ================================================================== So use *ppath to update the path to avoid the above problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49983", "url": "https://ubuntu.com/security/CVE-2024-49983", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-free When calling ext4_force_split_extent_at() in ext4_ext_replay_update_ex(), the 'ppath' is updated but it is the 'path' that is freed, thus potentially triggering a double-free in the following process: ext4_ext_replay_update_ex ppath = path ext4_force_split_extent_at(&ppath) ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path) ---> path First freed *orig_path = path = NULL ---> null ppath kfree(path) ---> path double-free !!! So drop the unnecessary ppath and use path directly to avoid this problem. And use ext4_find_extent() directly to update path, avoiding unnecessary memory allocation and freeing. Also, propagate the error returned by ext4_find_extent() instead of using strange error codes.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50015", "url": "https://ubuntu.com/security/CVE-2024-50015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: dax: fix overflowing extents beyond inode size when partially writing The dax_iomap_rw() does two things in each iteration: map written blocks and copy user data to blocks. If the process is killed by user(See signal handling in dax_iomap_iter()), the copied data will be returned and added on inode size, which means that the length of written extents may exceed the inode size, then fsck will fail. An example is given as: dd if=/dev/urandom of=file bs=4M count=1 dax_iomap_rw iomap_iter // round 1 ext4_iomap_begin ext4_iomap_alloc // allocate 0~2M extents(written flag) dax_iomap_iter // copy 2M data iomap_iter // round 2 iomap_iter_advance iter->pos += iter->processed // iter->pos = 2M ext4_iomap_begin ext4_iomap_alloc // allocate 2~4M extents(written flag) dax_iomap_iter fatal_signal_pending done = iter->pos - iocb->ki_pos // done = 2M ext4_handle_inode_extension ext4_update_inode_size // inode size = 2M fsck reports: Inode 13, i_size is 2097152, should be 4194304. Fix? Fix the problem by truncating extents if the written length is smaller than expected.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49884", "url": "https://ubuntu.com/security/CVE-2024-49884", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix slab-use-after-free in ext4_split_extent_at() We hit the following use-after-free: ================================================================== BUG: KASAN: slab-use-after-free in ext4_split_extent_at+0xba8/0xcc0 Read of size 2 at addr ffff88810548ed08 by task kworker/u20:0/40 CPU: 0 PID: 40 Comm: kworker/u20:0 Not tainted 6.9.0-dirty #724 Call Trace: kasan_report+0x93/0xc0 ext4_split_extent_at+0xba8/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] Allocated by task 40: __kmalloc_noprof+0x1ac/0x480 ext4_find_extent+0xf3b/0x1e70 ext4_ext_map_blocks+0x188/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] Freed by task 40: kfree+0xf1/0x2b0 ext4_find_extent+0xa71/0x1e70 ext4_ext_insert_extent+0xa22/0x3260 ext4_split_extent_at+0x3ef/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] ================================================================== The flow of issue triggering is as follows: ext4_split_extent_at path = *ppath ext4_ext_insert_extent(ppath) ext4_ext_create_new_leaf(ppath) ext4_find_extent(orig_path) path = *orig_path read_extent_tree_block // return -ENOMEM or -EIO ext4_free_ext_path(path) kfree(path) *orig_path = NULL a. If err is -ENOMEM: ext4_ext_dirty(path + path->p_depth) // path use-after-free !!! b. If err is -EIO and we have EXT_DEBUG defined: ext4_ext_show_leaf(path) eh = path[depth].p_hdr // path also use-after-free !!! So when trying to zeroout or fix the extent length, call ext4_find_extent() to update the path. In addition we use *ppath directly as an ext4_ext_show_leaf() input to avoid possible use-after-free when EXT_DEBUG is defined, and to avoid unnecessary path updates.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49885", "url": "https://ubuntu.com/security/CVE-2024-49885", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm, slub: avoid zeroing kmalloc redzone Since commit 946fa0dbf2d8 (\"mm/slub: extend redzone check to extra allocated kmalloc space than requested\"), setting orig_size treats the wasted space (object_size - orig_size) as a redzone. However with init_on_free=1 we clear the full object->size, including the redzone. Additionally we clear the object metadata, including the stored orig_size, making it zero, which makes check_object() treat the whole object as a redzone. These issues lead to the following BUG report with \"slub_debug=FUZ init_on_free=1\": [ 0.000000] ============================================================================= [ 0.000000] BUG kmalloc-8 (Not tainted): kmalloc Redzone overwritten [ 0.000000] ----------------------------------------------------------------------------- [ 0.000000] [ 0.000000] 0xffff000010032858-0xffff00001003285f @offset=2136. First byte 0x0 instead of 0xcc [ 0.000000] FIX kmalloc-8: Restoring kmalloc Redzone 0xffff000010032858-0xffff00001003285f=0xcc [ 0.000000] Slab 0xfffffdffc0400c80 objects=36 used=23 fp=0xffff000010032a18 flags=0x3fffe0000000200(workingset|node=0|zone=0|lastcpupid=0x1ffff) [ 0.000000] Object 0xffff000010032858 @offset=2136 fp=0xffff0000100328c8 [ 0.000000] [ 0.000000] Redzone ffff000010032850: cc cc cc cc cc cc cc cc ........ [ 0.000000] Object ffff000010032858: cc cc cc cc cc cc cc cc ........ [ 0.000000] Redzone ffff000010032860: cc cc cc cc cc cc cc cc ........ [ 0.000000] Padding ffff0000100328b4: 00 00 00 00 00 00 00 00 00 00 00 00 ............ [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.11.0-rc3-next-20240814-00004-g61844c55c3f4 #144 [ 0.000000] Hardware name: NXP i.MX95 19X19 board (DT) [ 0.000000] Call trace: [ 0.000000] dump_backtrace+0x90/0xe8 [ 0.000000] show_stack+0x18/0x24 [ 0.000000] dump_stack_lvl+0x74/0x8c [ 0.000000] dump_stack+0x18/0x24 [ 0.000000] print_trailer+0x150/0x218 [ 0.000000] check_object+0xe4/0x454 [ 0.000000] free_to_partial_list+0x2f8/0x5ec To address the issue, use orig_size to clear the used area. And restore the value of orig_size after clear the remaining area. When CONFIG_SLUB_DEBUG not defined, (get_orig_size()' directly returns s->object_size. So when using memset to init the area, the size can simply be orig_size, as orig_size returns object_size when CONFIG_SLUB_DEBUG not enabled. And orig_size can never be bigger than object_size.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49961", "url": "https://ubuntu.com/security/CVE-2024-49961", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: ar0521: Use cansleep version of gpiod_set_value() If we use GPIO reset from I2C port expander, we must use *_cansleep() variant of GPIO functions. This was not done in ar0521_power_on()/ar0521_power_off() functions. Let's fix that. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 11 at drivers/gpio/gpiolib.c:3496 gpiod_set_value+0x74/0x7c Modules linked in: CPU: 0 PID: 11 Comm: kworker/u16:0 Not tainted 6.10.0 #53 Hardware name: Diasom DS-RK3568-SOM-EVB (DT) Workqueue: events_unbound deferred_probe_work_func pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : gpiod_set_value+0x74/0x7c lr : ar0521_power_on+0xcc/0x290 sp : ffffff8001d7ab70 x29: ffffff8001d7ab70 x28: ffffff80027dcc90 x27: ffffff8003c82000 x26: ffffff8003ca9250 x25: ffffffc080a39c60 x24: ffffff8003ca9088 x23: ffffff8002402720 x22: ffffff8003ca9080 x21: ffffff8003ca9088 x20: 0000000000000000 x19: ffffff8001eb2a00 x18: ffffff80efeeac80 x17: 756d2d6332692f30 x16: 0000000000000000 x15: 0000000000000000 x14: ffffff8001d91d40 x13: 0000000000000016 x12: ffffffc080e98930 x11: ffffff8001eb2880 x10: 0000000000000890 x9 : ffffff8001d7a9f0 x8 : ffffff8001d92570 x7 : ffffff80efeeac80 x6 : 000000003fc6e780 x5 : ffffff8001d91c80 x4 : 0000000000000002 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000001 Call trace: gpiod_set_value+0x74/0x7c ar0521_power_on+0xcc/0x290 ...", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49985", "url": "https://ubuntu.com/security/CVE-2024-49985", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume In case there is any sort of clock controller attached to this I2C bus controller, for example Versaclock or even an AIC32x4 I2C codec, then an I2C transfer triggered from the clock controller clk_ops .prepare callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex. This is because the clock controller first grabs the prepare_lock mutex and then performs the prepare operation, including its I2C access. The I2C access resumes this I2C bus controller via .runtime_resume callback, which calls clk_prepare_enable(), which attempts to grab the prepare_lock mutex again and deadlocks. Since the clock are already prepared since probe() and unprepared in remove(), use simple clk_enable()/clk_disable() calls to enable and disable the clock on runtime suspend and resume, to avoid hitting the prepare_lock mutex.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49886", "url": "https://ubuntu.com/security/CVE-2024-49886", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bug Attaching SST PCI device to VM causes \"BUG: KASAN: slab-out-of-bounds\". kasan report: [ 19.411889] ================================================================== [ 19.413702] BUG: KASAN: slab-out-of-bounds in _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.415634] Read of size 8 at addr ffff888829e65200 by task cpuhp/16/113 [ 19.417368] [ 19.418627] CPU: 16 PID: 113 Comm: cpuhp/16 Tainted: G E 6.9.0 #10 [ 19.420435] Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.20192059.B64.2207280713 07/28/2022 [ 19.422687] Call Trace: [ 19.424091] [ 19.425448] dump_stack_lvl+0x5d/0x80 [ 19.426963] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.428694] print_report+0x19d/0x52e [ 19.430206] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 19.431837] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.433539] kasan_report+0xf0/0x170 [ 19.435019] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.436709] _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.438379] ? __pfx_sched_clock_cpu+0x10/0x10 [ 19.439910] isst_if_cpu_online+0x406/0x58f [isst_if_common] [ 19.441573] ? __pfx_isst_if_cpu_online+0x10/0x10 [isst_if_common] [ 19.443263] ? ttwu_queue_wakelist+0x2c1/0x360 [ 19.444797] cpuhp_invoke_callback+0x221/0xec0 [ 19.446337] cpuhp_thread_fun+0x21b/0x610 [ 19.447814] ? __pfx_cpuhp_thread_fun+0x10/0x10 [ 19.449354] smpboot_thread_fn+0x2e7/0x6e0 [ 19.450859] ? __pfx_smpboot_thread_fn+0x10/0x10 [ 19.452405] kthread+0x29c/0x350 [ 19.453817] ? __pfx_kthread+0x10/0x10 [ 19.455253] ret_from_fork+0x31/0x70 [ 19.456685] ? __pfx_kthread+0x10/0x10 [ 19.458114] ret_from_fork_asm+0x1a/0x30 [ 19.459573] [ 19.460853] [ 19.462055] Allocated by task 1198: [ 19.463410] kasan_save_stack+0x30/0x50 [ 19.464788] kasan_save_track+0x14/0x30 [ 19.466139] __kasan_kmalloc+0xaa/0xb0 [ 19.467465] __kmalloc+0x1cd/0x470 [ 19.468748] isst_if_cdev_register+0x1da/0x350 [isst_if_common] [ 19.470233] isst_if_mbox_init+0x108/0xff0 [isst_if_mbox_msr] [ 19.471670] do_one_initcall+0xa4/0x380 [ 19.472903] do_init_module+0x238/0x760 [ 19.474105] load_module+0x5239/0x6f00 [ 19.475285] init_module_from_file+0xd1/0x130 [ 19.476506] idempotent_init_module+0x23b/0x650 [ 19.477725] __x64_sys_finit_module+0xbe/0x130 [ 19.476506] idempotent_init_module+0x23b/0x650 [ 19.477725] __x64_sys_finit_module+0xbe/0x130 [ 19.478920] do_syscall_64+0x82/0x160 [ 19.480036] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 19.481292] [ 19.482205] The buggy address belongs to the object at ffff888829e65000 which belongs to the cache kmalloc-512 of size 512 [ 19.484818] The buggy address is located 0 bytes to the right of allocated 512-byte region [ffff888829e65000, ffff888829e65200) [ 19.487447] [ 19.488328] The buggy address belongs to the physical page: [ 19.489569] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888829e60c00 pfn:0x829e60 [ 19.491140] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [ 19.492466] anon flags: 0x57ffffc0000840(slab|head|node=1|zone=2|lastcpupid=0x1fffff) [ 19.493914] page_type: 0xffffffff() [ 19.494988] raw: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [ 19.496451] raw: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [ 19.497906] head: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [ 19.499379] head: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [ 19.500844] head: 0057ffffc0000003 ffffea0020a79801 ffffea0020a79848 00000000ffffffff [ 19.502316] head: 0000000800000000 0000000000000000 00000000ffffffff 0000000000000000 [ 19.503784] page dumped because: k ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49986", "url": "https://ubuntu.com/security/CVE-2024-49986", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: x86-android-tablets: Fix use after free on platform_device_register() errors x86_android_tablet_remove() frees the pdevs[] array, so it should not be used after calling x86_android_tablet_remove(). When platform_device_register() fails, store the pdevs[x] PTR_ERR() value into the local ret variable before calling x86_android_tablet_remove() to avoid using pdevs[] after it has been freed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49887", "url": "https://ubuntu.com/security/CVE-2024-49887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to don't panic system for no free segment fault injection f2fs: fix to don't panic system for no free segment fault injection syzbot reports a f2fs bug as below: F2FS-fs (loop0): inject no free segment in get_new_segment of __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3167 F2FS-fs (loop0): Stopped filesystem due to reason: 7 ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2748! CPU: 0 UID: 0 PID: 5109 Comm: syz-executor304 Not tainted 6.11.0-rc6-syzkaller-00363-g89f5e14d05b4 #0 RIP: 0010:get_new_segment fs/f2fs/segment.c:2748 [inline] RIP: 0010:new_curseg+0x1f61/0x1f70 fs/f2fs/segment.c:2836 Call Trace: __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3167 f2fs_allocate_new_section fs/f2fs/segment.c:3181 [inline] f2fs_allocate_pinning_section+0xfa/0x4e0 fs/f2fs/segment.c:3195 f2fs_expand_inode_data+0x5d6/0xbb0 fs/f2fs/file.c:1799 f2fs_fallocate+0x448/0x960 fs/f2fs/file.c:1903 vfs_fallocate+0x553/0x6c0 fs/open.c:334 do_vfs_ioctl+0x2592/0x2e50 fs/ioctl.c:886 __do_sys_ioctl fs/ioctl.c:905 [inline] __se_sys_ioctl+0x81/0x170 fs/ioctl.c:893 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: 0010:get_new_segment fs/f2fs/segment.c:2748 [inline] RIP: 0010:new_curseg+0x1f61/0x1f70 fs/f2fs/segment.c:2836 The root cause is when we inject no free segment fault into f2fs, we should not panic system, fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49888", "url": "https://ubuntu.com/security/CVE-2024-49888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix a sdiv overflow issue Zac Ecob reported a problem where a bpf program may cause kernel crash due to the following error: Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI The failure is due to the below signed divide: LLONG_MIN/-1 where LLONG_MIN equals to -9,223,372,036,854,775,808. LLONG_MIN/-1 is supposed to give a positive number 9,223,372,036,854,775,808, but it is impossible since for 64-bit system, the maximum positive number is 9,223,372,036,854,775,807. On x86_64, LLONG_MIN/-1 will cause a kernel exception. On arm64, the result for LLONG_MIN/-1 is LLONG_MIN. Further investigation found all the following sdiv/smod cases may trigger an exception when bpf program is running on x86_64 platform: - LLONG_MIN/-1 for 64bit operation - INT_MIN/-1 for 32bit operation - LLONG_MIN%-1 for 64bit operation - INT_MIN%-1 for 32bit operation where -1 can be an immediate or in a register. On arm64, there are no exceptions: - LLONG_MIN/-1 = LLONG_MIN - INT_MIN/-1 = INT_MIN - LLONG_MIN%-1 = 0 - INT_MIN%-1 = 0 where -1 can be an immediate or in a register. Insn patching is needed to handle the above cases and the patched codes produced results aligned with above arm64 result. The below are pseudo codes to handle sdiv/smod exceptions including both divisor -1 and divisor 0 and the divisor is stored in a register. sdiv: tmp = rX tmp += 1 /* [-1, 0] -> [0, 1] if tmp >(unsigned) 1 goto L2 if tmp == 0 goto L1 rY = 0 L1: rY = -rY; goto L3 L2: rY /= rX L3: smod: tmp = rX tmp += 1 /* [-1, 0] -> [0, 1] if tmp >(unsigned) 1 goto L1 if tmp == 1 (is64 ? goto L2 : goto L3) rY = 0; goto L2 L1: rY %= rX L2: goto L4 // only when !is64 L3: wY = wY // only when !is64 L4: [1] https://lore.kernel.org/bpf/tPJLTEh7S_DxFEqAI2Ji5MBSoZVg7_G-Py2iaZpAaWtM961fFTWtsnlzwvTbzBzaUzwQAoNATXKUlt0LZOFgnDcIyKCswAnAGdUF3LBrhGQ=@protonmail.com/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49987", "url": "https://ubuntu.com/security/CVE-2024-49987", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpftool: Fix undefined behavior in qsort(NULL, 0, ...) When netfilter has no entry to display, qsort is called with qsort(NULL, 0, ...). This results in undefined behavior, as UBSan reports: net.c:827:2: runtime error: null pointer passed as argument 1, which is declared to never be null Although the C standard does not explicitly state whether calling qsort with a NULL pointer when the size is 0 constitutes undefined behavior, Section 7.1.4 of the C standard (Use of library functions) mentions: \"Each of the following statements applies unless explicitly stated otherwise in the detailed descriptions that follow: If an argument to a function has an invalid value (such as a value outside the domain of the function, or a pointer outside the address space of the program, or a null pointer, or a pointer to non-modifiable storage when the corresponding parameter is not const-qualified) or a type (after promotion) not expected by a function with variable number of arguments, the behavior is undefined.\" To avoid this, add an early return when nf_link_info is NULL to prevent calling qsort with a NULL pointer.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50006", "url": "https://ubuntu.com/security/CVE-2024-50006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix i_data_sem unlock order in ext4_ind_migrate() Fuzzing reports a possible deadlock in jbd2_log_wait_commit. This issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to require synchronous updates because the file descriptor is opened with O_SYNC. This can lead to the jbd2_journal_stop() function calling jbd2_might_wait_for_commit(), potentially causing a deadlock if the EXT4_IOC_MIGRATE call races with a write(2) system call. This problem only arises when CONFIG_PROVE_LOCKING is enabled. In this case, the jbd2_might_wait_for_commit macro locks jbd2_handle in the jbd2_journal_stop function while i_data_sem is locked. This triggers lockdep because the jbd2_journal_start function might also lock the same jbd2_handle simultaneously. Found by Linux Verification Center (linuxtesting.org) with syzkaller. Rule: add", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49889", "url": "https://ubuntu.com/security/CVE-2024-49889", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid use-after-free in ext4_ext_show_leaf() In ext4_find_extent(), path may be freed by error or be reallocated, so using a previously saved *ppath may have been freed and thus may trigger use-after-free, as follows: ext4_split_extent path = *ppath; ext4_split_extent_at(ppath) path = ext4_find_extent(ppath) ext4_split_extent_at(ppath) // ext4_find_extent fails to free path // but zeroout succeeds ext4_ext_show_leaf(inode, path) eh = path[depth].p_hdr // path use-after-free !!! Similar to ext4_split_extent_at(), we use *ppath directly as an input to ext4_ext_show_leaf(). Fix a spelling error by the way. Same problem in ext4_ext_handle_unwritten_extents(). Since 'path' is only used in ext4_ext_show_leaf(), remove 'path' and use *ppath directly. This issue is triggered only when EXT_DEBUG is defined and therefore does not affect functionality.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49968", "url": "https://ubuntu.com/security/CVE-2024-49968", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: filesystems without casefold feature cannot be mounted with siphash When mounting the ext4 filesystem, if the default hash version is set to DX_HASH_SIPHASH but the casefold feature is not set, exit the mounting.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49988", "url": "https://ubuntu.com/security/CVE-2024-49988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: add refcnt to ksmbd_conn struct When sending an oplock break request, opinfo->conn is used, But freed ->conn can be used on multichannel. This patch add a reference count to the ksmbd_conn struct so that it can be freed when it is no longer used.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49890", "url": "https://ubuntu.com/security/CVE-2024-49890", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: ensure the fw_info is not null before using it This resolves the dereference null return value warning reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49891", "url": "https://ubuntu.com/security/CVE-2024-49891", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata paths When the HBA is undergoing a reset or is handling an errata event, NULL ptr dereference crashes may occur in routines such as lpfc_sli_flush_io_rings(), lpfc_dev_loss_tmo_callbk(), or lpfc_abort_handler(). Add NULL ptr checks before dereferencing hdwq pointers that may have been freed due to operations colliding with a reset or errata event handler.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49892", "url": "https://ubuntu.com/security/CVE-2024-49892", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize get_bytes_per_element's default to 1 Variables, used as denominators and maybe not assigned to other values, should not be 0. bytes_per_element_y & bytes_per_element_c are initialized by get_bytes_per_element() which should never return 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50016", "url": "https://ubuntu.com/security/CVE-2024-50016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Avoid overflow assignment in link_dp_cts sampling_rate is an uint8_t but is assigned an unsigned int, and thus it can overflow. As a result, sampling_rate is changed to uint32_t. Similarly, LINK_QUAL_PATTERN_SET has a size of 2 bits, and it should only be assigned to a value less or equal than 4. This fixes 2 INTEGER_OVERFLOW issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49893", "url": "https://ubuntu.com/security/CVE-2024-49893", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check stream_status before it is used [WHAT & HOW] dc_state_get_stream_status can return null, and therefore null must be checked before stream_status is used. This fixes 1 NULL_RETURNS issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49969", "url": "https://ubuntu.com/security/CVE-2024-49969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 color transformation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_hw_format` function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:180 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:181 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:182 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49970", "url": "https://ubuntu.com/security/CVE-2024-49970", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Implement bounds check for stream encoder creation in DCN401 'stream_enc_regs' array is an array of dcn10_stream_enc_registers structures. The array is initialized with four elements, corresponding to the four calls to stream_enc_regs() in the array initializer. This means that valid indices for this array are 0, 1, 2, and 3. The error message 'stream_enc_regs' 4 <= 5 below, is indicating that there is an attempt to access this array with an index of 5, which is out of bounds. This could lead to undefined behavior Here, eng_id is used as an index to access the stream_enc_regs array. If eng_id is 5, this would result in an out-of-bounds access on the stream_enc_regs array. Thus fixing Buffer overflow error in dcn401_stream_encoder_create Found by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn401/dcn401_resource.c:1209 dcn401_stream_encoder_create() error: buffer overflow 'stream_enc_regs' 4 <= 5", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49894", "url": "https://ubuntu.com/security/CVE-2024-49894", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in degamma hardware format translation Fixes index out of bounds issue in `cm_helper_translate_curve_to_degamma_hw_format` function. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49895", "url": "https://ubuntu.com/security/CVE-2024-49895", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format translation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_degamma_hw_format` function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:338 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:339 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:340 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49971", "url": "https://ubuntu.com/security/CVE-2024-49971", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Increase array size of dummy_boolean [WHY] dml2_core_shared_mode_support and dml_core_mode_support access the third element of dummy_boolean, i.e. hw_debug5 = &s->dummy_boolean[2], when dummy_boolean has size of 2. Any assignment to hw_debug5 causes an OVERRUN. [HOW] Increase dummy_boolean's array size to 3. This fixes 2 OVERRUN issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49972", "url": "https://ubuntu.com/security/CVE-2024-49972", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Deallocate DML memory if allocation fails [Why] When DC state create DML memory allocation fails, memory is not deallocated subsequently, resulting in uninitialized structure that is not NULL. [How] Deallocate memory if DML memory allocation fails.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49896", "url": "https://ubuntu.com/security/CVE-2024-49896", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check stream before comparing them [WHAT & HOW] amdgpu_dm can pass a null stream to dc_is_stream_unchanged. It is necessary to check for null before dereferencing them. This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49897", "url": "https://ubuntu.com/security/CVE-2024-49897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check phantom_stream before it is used dcn32_enable_phantom_stream can return null, so returned value must be checked before used. This fixes 1 NULL_RETURNS issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49898", "url": "https://ubuntu.com/security/CVE-2024-49898", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null-initialized variables [WHAT & HOW] drr_timing and subvp_pipe are initialized to null and they are not always assigned new values. It is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49899", "url": "https://ubuntu.com/security/CVE-2024-49899", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize denominators' default to 1 [WHAT & HOW] Variables used as denominators and maybe not assigned to other values, should not be 0. Change their default to 1 so they are never 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49900", "url": "https://ubuntu.com/security/CVE-2024-49900", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uninit-value access of new_ea in ea_buffer syzbot reports that lzo1x_1_do_compress is using uninit-value: ===================================================== BUG: KMSAN: uninit-value in lzo1x_1_do_compress+0x19f9/0x2510 lib/lzo/lzo1x_compress.c:178 ... Uninit was stored to memory at: ea_put fs/jfs/xattr.c:639 [inline] ... Local variable ea_buf created at: __jfs_setxattr+0x5d/0x1ae0 fs/jfs/xattr.c:662 __jfs_xattr_set+0xe6/0x1f0 fs/jfs/xattr.c:934 ===================================================== The reason is ea_buf->new_ea is not initialized properly. Fix this by using memset to empty its content at the beginning in ea_get().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49901", "url": "https://ubuntu.com/security/CVE-2024-49901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm/adreno: Assign msm_gpu->pdev earlier to avoid nullptrs There are some cases, such as the one uncovered by Commit 46d4efcccc68 (\"drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails\") where msm_gpu_cleanup() : platform_set_drvdata(gpu->pdev, NULL); is called on gpu->pdev == NULL, as the GPU device has not been fully initialized yet. Turns out that there's more than just the aforementioned path that causes this to happen (e.g. the case when there's speedbin data in the catalog, but opp-supported-hw is missing in DT). Assigning msm_gpu->pdev earlier seems like the least painful solution to this, therefore do so. Patchwork: https://patchwork.freedesktop.org/patch/602742/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49902", "url": "https://ubuntu.com/security/CVE-2024-49902", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: check if leafidx greater than num leaves per dmap tree syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf. Shaggy: Modified sanity check to apply to control pages as well as leaf pages.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49903", "url": "https://ubuntu.com/security/CVE-2024-49903", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uaf in dbFreeBits [syzbot reported] ================================================================== BUG: KASAN: slab-use-after-free in __mutex_lock_common kernel/locking/mutex.c:587 [inline] BUG: KASAN: slab-use-after-free in __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 Read of size 8 at addr ffff8880229254b0 by task syz-executor357/5216 CPU: 0 UID: 0 PID: 5216 Comm: syz-executor357 Not tainted 6.11.0-rc3-syzkaller-00156-gd7a5aa4b3c00 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 __mutex_lock_common kernel/locking/mutex.c:587 [inline] __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 dbFreeBits+0x7ea/0xd90 fs/jfs/jfs_dmap.c:2390 dbFreeDmap fs/jfs/jfs_dmap.c:2089 [inline] dbFree+0x35b/0x680 fs/jfs/jfs_dmap.c:409 dbDiscardAG+0x8a9/0xa20 fs/jfs/jfs_dmap.c:1650 jfs_ioc_trim+0x433/0x670 fs/jfs/jfs_discard.c:100 jfs_ioctl+0x2d0/0x3e0 fs/jfs/ioctl.c:131 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 Freed by task 5218: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object+0xe0/0x150 mm/kasan/common.c:240 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2252 [inline] slab_free mm/slub.c:4473 [inline] kfree+0x149/0x360 mm/slub.c:4594 dbUnmount+0x11d/0x190 fs/jfs/jfs_dmap.c:278 jfs_mount_rw+0x4ac/0x6a0 fs/jfs/jfs_mount.c:247 jfs_remount+0x3d1/0x6b0 fs/jfs/super.c:454 reconfigure_super+0x445/0x880 fs/super.c:1083 vfs_cmd_reconfigure fs/fsopen.c:263 [inline] vfs_fsconfig_locked fs/fsopen.c:292 [inline] __do_sys_fsconfig fs/fsopen.c:473 [inline] __se_sys_fsconfig+0xb6e/0xf80 fs/fsopen.c:345 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 [Analysis] There are two paths (dbUnmount and jfs_ioc_trim) that generate race condition when accessing bmap, which leads to the occurrence of uaf. Use the lock s_umount to synchronize them, in order to avoid uaf caused by race condition.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49904", "url": "https://ubuntu.com/security/CVE-2024-49904", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add list empty check to avoid null pointer issue Add list empty check to avoid null pointer issues in some corner cases. - list_for_each_entry_safe()", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49989", "url": "https://ubuntu.com/security/CVE-2024-49989", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix double free issue during amdgpu module unload Flexible endpoints use DIGs from available inflexible endpoints, so only the encoders of inflexible links need to be freed. Otherwise, a double free issue may occur when unloading the amdgpu module. [ 279.190523] RIP: 0010:__slab_free+0x152/0x2f0 [ 279.190577] Call Trace: [ 279.190580] [ 279.190582] ? show_regs+0x69/0x80 [ 279.190590] ? die+0x3b/0x90 [ 279.190595] ? do_trap+0xc8/0xe0 [ 279.190601] ? do_error_trap+0x73/0xa0 [ 279.190605] ? __slab_free+0x152/0x2f0 [ 279.190609] ? exc_invalid_op+0x56/0x70 [ 279.190616] ? __slab_free+0x152/0x2f0 [ 279.190642] ? asm_exc_invalid_op+0x1f/0x30 [ 279.190648] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191096] ? __slab_free+0x152/0x2f0 [ 279.191102] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191469] kfree+0x260/0x2b0 [ 279.191474] dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191821] link_destroy+0xd7/0x130 [amdgpu] [ 279.192248] dc_destruct+0x90/0x270 [amdgpu] [ 279.192666] dc_destroy+0x19/0x40 [amdgpu] [ 279.193020] amdgpu_dm_fini+0x16e/0x200 [amdgpu] [ 279.193432] dm_hw_fini+0x26/0x40 [amdgpu] [ 279.193795] amdgpu_device_fini_hw+0x24c/0x400 [amdgpu] [ 279.194108] amdgpu_driver_unload_kms+0x4f/0x70 [amdgpu] [ 279.194436] amdgpu_pci_remove+0x40/0x80 [amdgpu] [ 279.194632] pci_device_remove+0x3a/0xa0 [ 279.194638] device_remove+0x40/0x70 [ 279.194642] device_release_driver_internal+0x1ad/0x210 [ 279.194647] driver_detach+0x4e/0xa0 [ 279.194650] bus_remove_driver+0x6f/0xf0 [ 279.194653] driver_unregister+0x33/0x60 [ 279.194657] pci_unregister_driver+0x44/0x90 [ 279.194662] amdgpu_exit+0x19/0x1f0 [amdgpu] [ 279.194939] __do_sys_delete_module.isra.0+0x198/0x2f0 [ 279.194946] __x64_sys_delete_module+0x16/0x20 [ 279.194950] do_syscall_64+0x58/0x120 [ 279.194954] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 279.194980] ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49905", "url": "https://ubuntu.com/security/CVE-2024-49905", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for 'afb' in amdgpu_dm_plane_handle_cursor_update (v2) This commit adds a null check for the 'afb' variable in the amdgpu_dm_plane_handle_cursor_update function. Previously, 'afb' was assumed to be null, but was used later in the code without a null check. This could potentially lead to a null pointer dereference. Changes since v1: - Moved the null check for 'afb' to the line where 'afb' is used. (Alex) Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:1298 amdgpu_dm_plane_handle_cursor_update() error: we previously assumed 'afb' could be null (see line 1252)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49906", "url": "https://ubuntu.com/security/CVE-2024-49906", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before try to access it [why & how] Change the order of the pipe_ctx->plane_state check to ensure that plane_state is not null before accessing it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49907", "url": "https://ubuntu.com/security/CVE-2024-49907", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before using dc->clk_mgr [WHY & HOW] dc->clk_mgr is null checked previously in the same function, indicating it might be null. Passing \"dc\" to \"dc->hwss.apply_idle_power_optimizations\", which dereferences null \"dc->clk_mgr\". (The function pointer resolves to \"dcn35_apply_idle_power_optimizations\".) This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49908", "url": "https://ubuntu.com/security/CVE-2024-49908", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for 'afb' in amdgpu_dm_update_cursor (v2) This commit adds a null check for the 'afb' variable in the amdgpu_dm_update_cursor function. Previously, 'afb' was assumed to be null at line 8388, but was used later in the code without a null check. This could potentially lead to a null pointer dereference. Changes since v1: - Moved the null check for 'afb' to the line where 'afb' is used. (Alex) Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:8433 amdgpu_dm_update_cursor() \terror: we previously assumed 'afb' could be null (see line 8388)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50177", "url": "https://ubuntu.com/security/CVE-2024-50177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix a UBSAN warning in DML2.1 When programming phantom pipe, since cursor_width is explicity set to 0, this causes calculation logic to trigger overflow for an unsigned int triggering the kernel's UBSAN check as below: [ 40.962845] UBSAN: shift-out-of-bounds in /tmp/amd.EfpumTkO/amd/amdgpu/../display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c:3312:34 [ 40.962849] shift exponent 4294967170 is too large for 32-bit type 'unsigned int' [ 40.962852] CPU: 1 PID: 1670 Comm: gnome-shell Tainted: G W OE 6.5.0-41-generic #41~22.04.2-Ubuntu [ 40.962854] Hardware name: Gigabyte Technology Co., Ltd. X670E AORUS PRO X/X670E AORUS PRO X, BIOS F21 01/10/2024 [ 40.962856] Call Trace: [ 40.962857] [ 40.962860] dump_stack_lvl+0x48/0x70 [ 40.962870] dump_stack+0x10/0x20 [ 40.962872] __ubsan_handle_shift_out_of_bounds+0x1ac/0x360 [ 40.962878] calculate_cursor_req_attributes.cold+0x1b/0x28 [amdgpu] [ 40.963099] dml_core_mode_support+0x6b91/0x16bc0 [amdgpu] [ 40.963327] ? srso_alias_return_thunk+0x5/0x7f [ 40.963331] ? CalculateWatermarksMALLUseAndDRAMSpeedChangeSupport+0x18b8/0x2790 [amdgpu] [ 40.963534] ? srso_alias_return_thunk+0x5/0x7f [ 40.963536] ? dml_core_mode_support+0xb3db/0x16bc0 [amdgpu] [ 40.963730] dml2_core_calcs_mode_support_ex+0x2c/0x90 [amdgpu] [ 40.963906] ? srso_alias_return_thunk+0x5/0x7f [ 40.963909] ? dml2_core_calcs_mode_support_ex+0x2c/0x90 [amdgpu] [ 40.964078] core_dcn4_mode_support+0x72/0xbf0 [amdgpu] [ 40.964247] dml2_top_optimization_perform_optimization_phase+0x1d3/0x2a0 [amdgpu] [ 40.964420] dml2_build_mode_programming+0x23d/0x750 [amdgpu] [ 40.964587] dml21_validate+0x274/0x770 [amdgpu] [ 40.964761] ? srso_alias_return_thunk+0x5/0x7f [ 40.964763] ? resource_append_dpp_pipes_for_plane_composition+0x27c/0x3b0 [amdgpu] [ 40.964942] dml2_validate+0x504/0x750 [amdgpu] [ 40.965117] ? dml21_copy+0x95/0xb0 [amdgpu] [ 40.965291] ? srso_alias_return_thunk+0x5/0x7f [ 40.965295] dcn401_validate_bandwidth+0x4e/0x70 [amdgpu] [ 40.965491] update_planes_and_stream_state+0x38d/0x5c0 [amdgpu] [ 40.965672] update_planes_and_stream_v3+0x52/0x1e0 [amdgpu] [ 40.965845] ? srso_alias_return_thunk+0x5/0x7f [ 40.965849] dc_update_planes_and_stream+0x71/0xb0 [amdgpu] Fix this by adding a guard for checking cursor width before triggering the size calculation.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49909", "url": "https://ubuntu.com/security/CVE-2024-49909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn32_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn32_set_output_transfer_func function. Previously, set_output_gamma was being checked for null, but then it was being dereferenced without any null check. This could lead to a null pointer dereference if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49910", "url": "https://ubuntu.com/security/CVE-2024-49910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn401_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn401_set_output_transfer_func function. Previously, set_output_gamma was being checked for null, but then it was being dereferenced without any null check. This could lead to a null pointer dereference if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49911", "url": "https://ubuntu.com/security/CVE-2024-49911", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn20_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn20_set_output_transfer_func function. Previously, set_output_gamma was being checked for null at line 1030, but then it was being dereferenced without any null check at line 1048. This could potentially lead to a null pointer dereference error if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma at line 1048.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49912", "url": "https://ubuntu.com/security/CVE-2024-49912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Handle null 'stream_status' in 'planes_changed_for_existing_stream' This commit adds a null check for 'stream_status' in the function 'planes_changed_for_existing_stream'. Previously, the code assumed 'stream_status' could be null, but did not handle the case where it was actually null. This could lead to a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:3784 planes_changed_for_existing_stream() error: we previously assumed 'stream_status' could be null (see line 3774)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49913", "url": "https://ubuntu.com/security/CVE-2024-49913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for top_pipe_to_program in commit_planes_for_stream This commit addresses a null pointer dereference issue in the `commit_planes_for_stream` function at line 4140. The issue could occur when `top_pipe_to_program` is null. The fix adds a check to ensure `top_pipe_to_program` is not null before accessing its stream_res. This prevents a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:4140 commit_planes_for_stream() error: we previously assumed 'top_pipe_to_program' could be null (see line 3906)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49914", "url": "https://ubuntu.com/security/CVE-2024-49914", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for pipe_ctx->plane_state in dcn20_program_pipe This commit addresses a null pointer dereference issue in the `dcn20_program_pipe` function. The issue could occur when `pipe_ctx->plane_state` is null. The fix adds a check to ensure `pipe_ctx->plane_state` is not null before accessing. This prevents a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn20/dcn20_hwseq.c:1925 dcn20_program_pipe() error: we previously assumed 'pipe_ctx->plane_state' could be null (see line 1877)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49915", "url": "https://ubuntu.com/security/CVE-2024-49915", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr in dcn32_init_hw This commit addresses a potential null pointer dereference issue in the `dcn32_init_hw` function. The issue could occur when `dc->clk_mgr` is null. The fix adds a check to ensure `dc->clk_mgr` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn32/dcn32_hwseq.c:961 dcn32_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 782)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49916", "url": "https://ubuntu.com/security/CVE-2024-49916", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in dcn401_init_hw This commit addresses a potential null pointer dereference issue in the `dcn401_init_hw` function. The issue could occur when `dc->clk_mgr` or `dc->clk_mgr->funcs` is null. The fix adds a check to ensure `dc->clk_mgr` and `dc->clk_mgr->funcs` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn401/dcn401_hwseq.c:416 dcn401_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 225)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49917", "url": "https://ubuntu.com/security/CVE-2024-49917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in dcn30_init_hw This commit addresses a potential null pointer dereference issue in the `dcn30_init_hw` function. The issue could occur when `dc->clk_mgr` or `dc->clk_mgr->funcs` is null. The fix adds a check to ensure `dc->clk_mgr` and `dc->clk_mgr->funcs` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:789 dcn30_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 628)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49918", "url": "https://ubuntu.com/security/CVE-2024-49918", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for head_pipe in dcn32_acquire_idle_pipe_for_head_pipe_in_layer This commit addresses a potential null pointer dereference issue in the `dcn32_acquire_idle_pipe_for_head_pipe_in_layer` function. The issue could occur when `head_pipe` is null. The fix adds a check to ensure `head_pipe` is not null before asserting it. If `head_pipe` is null, the function returns NULL to prevent a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn32/dcn32_resource.c:2690 dcn32_acquire_idle_pipe_for_head_pipe_in_layer() error: we previously assumed 'head_pipe' could be null (see line 2681)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49919", "url": "https://ubuntu.com/security/CVE-2024-49919", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for head_pipe in dcn201_acquire_free_pipe_for_layer This commit addresses a potential null pointer dereference issue in the `dcn201_acquire_free_pipe_for_layer` function. The issue could occur when `head_pipe` is null. The fix adds a check to ensure `head_pipe` is not null before asserting it. If `head_pipe` is null, the function returns NULL to prevent a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn201/dcn201_resource.c:1016 dcn201_acquire_free_pipe_for_layer() error: we previously assumed 'head_pipe' could be null (see line 1010)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49991", "url": "https://ubuntu.com/security/CVE-2024-49991", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer Pass pointer reference to amdgpu_bo_unref to clear the correct pointer, otherwise amdgpu_bo_unref clear the local variable, the original pointer not set to NULL, this could cause use-after-free bug.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49920", "url": "https://ubuntu.com/security/CVE-2024-49920", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before multiple uses [WHAT & HOW] Poniters, such as stream_enc and dc->bw_vbios, are null checked previously in the same function, so Coverity warns \"implies that stream_enc and dc->bw_vbios might be null\". They are used multiple times in the subsequent code and need to be checked. This fixes 10 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49921", "url": "https://ubuntu.com/security/CVE-2024-49921", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before used [WHAT & HOW] Poniters, such as dc->clk_mgr, are null checked previously in the same function, so Coverity warns \"implies that \"dc->clk_mgr\" might be null\". As a result, these pointers need to be checked when used again. This fixes 10 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49922", "url": "https://ubuntu.com/security/CVE-2024-49922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before using them [WHAT & HOW] These pointers are null checked previously in the same function, indicating they might be null as reported by Coverity. As a result, they need to be checked when used again. This fixes 3 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49923", "url": "https://ubuntu.com/security/CVE-2024-49923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Pass non-null to dcn20_validate_apply_pipe_split_flags [WHAT & HOW] \"dcn20_validate_apply_pipe_split_flags\" dereferences merge, and thus it cannot be a null pointer. Let's pass a valid pointer to avoid null dereference. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49992", "url": "https://ubuntu.com/security/CVE-2024-49992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/stm: Avoid use-after-free issues with crtc and plane ltdc_load() calls functions drm_crtc_init_with_planes(), drm_universal_plane_init() and drm_encoder_init(). These functions should not be called with parameters allocated with devm_kzalloc() to avoid use-after-free issues [1]. Use allocations managed by the DRM framework. Found by Linux Verification Center (linuxtesting.org). [1] https://lore.kernel.org/lkml/u366i76e3qhh3ra5oxrtngjtm2u5lterkekcz6y2jkndhuxzli@diujon4h7qwb/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49993", "url": "https://ubuntu.com/security/CVE-2024-49993", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49924", "url": "https://ubuntu.com/security/CVE-2024-49924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: pxafb: Fix possible use after free in pxafb_task() In the pxafb_probe function, it calls the pxafb_init_fbinfo function, after which &fbi->task is associated with pxafb_task. Moreover, within this pxafb_init_fbinfo function, the pxafb_blank function within the &pxafb_ops struct is capable of scheduling work. If we remove the module which will call pxafb_remove to make cleanup, it will call unregister_framebuffer function which can call do_unregister_framebuffer to free fbi->fb through put_fb_info(fb_info), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | pxafb_task pxafb_remove | unregister_framebuffer(info) | do_unregister_framebuffer(fb_info) | put_fb_info(fb_info) | // free fbi->fb | set_ctrlr_state(fbi, state) | __pxafb_lcd_power(fbi, 0) | fbi->lcd_power(on, &fbi->fb.var) | //use fbi->fb Fix it by ensuring that the work is canceled before proceeding with the cleanup in pxafb_remove. Note that only root user can remove the driver at runtime.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49925", "url": "https://ubuntu.com/security/CVE-2024-49925", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: efifb: Register sysfs groups through driver core The driver core can register and cleanup sysfs groups already. Make use of that functionality to simplify the error handling and cleanup. Also avoid a UAF race during unregistering where the sysctl attributes were usable after the info struct was freed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49926", "url": "https://ubuntu.com/security/CVE-2024-49926", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rcu-tasks: Fix access non-existent percpu rtpcp variable in rcu_tasks_need_gpcb() For kernels built with CONFIG_FORCE_NR_CPUS=y, the nr_cpu_ids is defined as NR_CPUS instead of the number of possible cpus, this will cause the following system panic: smpboot: Allowing 4 CPUs, 0 hotplug CPUs ... setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:512 nr_node_ids:1 ... BUG: unable to handle page fault for address: ffffffff9911c8c8 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 15 Comm: rcu_tasks_trace Tainted: G W 6.6.21 #1 5dc7acf91a5e8e9ac9dcfc35bee0245691283ea6 RIP: 0010:rcu_tasks_need_gpcb+0x25d/0x2c0 RSP: 0018:ffffa371c00a3e60 EFLAGS: 00010082 CR2: ffffffff9911c8c8 CR3: 000000040fa20005 CR4: 00000000001706f0 Call Trace: ? __die+0x23/0x80 ? page_fault_oops+0xa4/0x180 ? exc_page_fault+0x152/0x180 ? asm_exc_page_fault+0x26/0x40 ? rcu_tasks_need_gpcb+0x25d/0x2c0 ? __pfx_rcu_tasks_kthread+0x40/0x40 rcu_tasks_one_gp+0x69/0x180 rcu_tasks_kthread+0x94/0xc0 kthread+0xe8/0x140 ? __pfx_kthread+0x40/0x40 ret_from_fork+0x34/0x80 ? __pfx_kthread+0x40/0x40 ret_from_fork_asm+0x1b/0x80 Considering that there may be holes in the CPU numbers, use the maximum possible cpu number, instead of nr_cpu_ids, for configuring enqueue and dequeue limits. [ neeraj.upadhyay: Fix htmldocs build error reported by Stephen Rothwell ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50007", "url": "https://ubuntu.com/security/CVE-2024-50007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: asihpi: Fix potential OOB array access ASIHPI driver stores some values in the static array upon a response from the driver, and its index depends on the firmware. We shouldn't trust it blindly. This patch adds a sanity check of the array index to fit in the array size.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50017", "url": "https://ubuntu.com/security/CVE-2024-50017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm/ident_map: Use gbpages only where full GB page should be mapped. When ident_pud_init() uses only GB pages to create identity maps, large ranges of addresses not actually requested can be included in the resulting table; a 4K request will map a full GB. This can include a lot of extra address space past that requested, including areas marked reserved by the BIOS. That allows processor speculation into reserved regions, that on UV systems can cause system halts. Only use GB pages when map creation requests include the full GB page of space. Fall back to using smaller 2M pages when only portions of a GB page are included in the request. No attempt is made to coalesce mapping requests. If a request requires a map entry at the 2M (pmd) level, subsequent mapping requests within the same 1G region will also be at the pmd level, even if adjacent or overlapping such requests could have been combined to map a full GB page. Existing usage starts with larger regions and then adds smaller regions, so this should not have any great consequence.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49927", "url": "https://ubuntu.com/security/CVE-2024-49927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/ioapic: Handle allocation failures gracefully Breno observed panics when using failslab under certain conditions during runtime: can not alloc irq_pin_list (-1,0,20) Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed panic+0x4e9/0x590 mp_irqdomain_alloc+0x9ab/0xa80 irq_domain_alloc_irqs_locked+0x25d/0x8d0 __irq_domain_alloc_irqs+0x80/0x110 mp_map_pin_to_irq+0x645/0x890 acpi_register_gsi_ioapic+0xe6/0x150 hpet_open+0x313/0x480 That's a pointless panic which is a leftover of the historic IO/APIC code which panic'ed during early boot when the interrupt allocation failed. The only place which might justify panic is the PIT/HPET timer_check() code which tries to figure out whether the timer interrupt is delivered through the IO/APIC. But that code does not require to handle interrupt allocation failures. If the interrupt cannot be allocated then timer delivery fails and it either panics due to that or falls back to legacy mode. Cure this by removing the panic wrapper around __add_pin_to_irq_node() and making mp_irqdomain_alloc() aware of the failure condition and handle it as any other failure in this function gracefully.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50008", "url": "https://ubuntu.com/security/CVE-2024-50008", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_cmd_802_11_scan_ext() Replace one-element array with a flexible-array member in `struct host_cmd_ds_802_11_scan_ext`. With this, fix the following warning: elo 16 17:51:58 surfacebook kernel: ------------[ cut here ]------------ elo 16 17:51:58 surfacebook kernel: memcpy: detected field-spanning write (size 243) of single field \"ext_scan->tlv_buffer\" at drivers/net/wireless/marvell/mwifiex/scan.c:2239 (size 1) elo 16 17:51:58 surfacebook kernel: WARNING: CPU: 0 PID: 498 at drivers/net/wireless/marvell/mwifiex/scan.c:2239 mwifiex_cmd_802_11_scan_ext+0x83/0x90 [mwifiex]", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50018", "url": "https://ubuntu.com/security/CVE-2024-50018", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49928", "url": "https://ubuntu.com/security/CVE-2024-49928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: avoid reading out of bounds when loading TX power FW elements Because the loop-expression will do one more time before getting false from cond-expression, the original code copied one more entry size beyond valid region. Fix it by moving the entry copy to loop-body.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50178", "url": "https://ubuntu.com/security/CVE-2024-50178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: loongson3: Use raw_smp_processor_id() in do_service_request() Use raw_smp_processor_id() instead of plain smp_processor_id() in do_service_request(), otherwise we may get some errors with the driver enabled: BUG: using smp_processor_id() in preemptible [00000000] code: (udev-worker)/208 caller is loongson3_cpufreq_probe+0x5c/0x250 [loongson3_cpufreq]", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50009", "url": "https://ubuntu.com/security/CVE-2024-50009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: amd-pstate: add check for cpufreq_cpu_get's return value cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it and return in case of error. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49994", "url": "https://ubuntu.com/security/CVE-2024-49994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix integer overflow in BLKSECDISCARD I independently rediscovered \tcommit 22d24a544b0d49bbcbd61c8c0eaf77d3c9297155 \tblock: fix overflow in blk_ioctl_discard() but for secure erase. Same problem: \tuint64_t r[2] = {512, 18446744073709551104ULL}; \tioctl(fd, BLKSECDISCARD, r); will enter near infinite loop inside blkdev_issue_secure_erase(): \ta.out: attempt to access beyond end of device \tloop0: rw=5, sector=3399043073, nr_sectors = 1024 limit=2048 \tbio_check_eod: 3286214 callbacks suppressed", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49929", "url": "https://ubuntu.com/security/CVE-2024-49929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: avoid NULL pointer dereference iwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta pointer is not NULL. It retrieves this pointer using iwl_mvm_sta_from_mac80211, which is dereferencing the ieee80211_sta pointer. If sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL pointer. Fix this by checking the sta pointer before retrieving the mvmsta from it. If sta is not NULL, then mvmsta isn't either.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49995", "url": "https://ubuntu.com/security/CVE-2024-49995", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: guard against string buffer overrun Smatch reports that copying media_name and if_name to name_parts may overwrite the destination. .../bearer.c:166 bearer_name_validate() error: strcpy() 'media_name' too large for 'name_parts->media_name' (32 vs 16) .../bearer.c:167 bearer_name_validate() error: strcpy() 'if_name' too large for 'name_parts->if_name' (1010102 vs 16) This does seem to be the case so guard against this possibility by using strscpy() and failing if truncation occurs. Introduced by commit b97bf3fd8f6a (\"[TIPC] Initial merge\") Compile tested only.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49962", "url": "https://ubuntu.com/security/CVE-2024-49962", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in acpi_db_convert_to_package() ACPICA commit 4d4547cf13cca820ff7e0f859ba83e1a610b9fd0 ACPI_ALLOCATE_ZEROED() may fail, elements might be NULL and will cause NULL pointer dereference later. [ rjw: Subject and changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49930", "url": "https://ubuntu.com/security/CVE-2024-49930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix array out-of-bound access in SoC stats Currently, the ath11k_soc_dp_stats::hal_reo_error array is defined with a maximum size of DP_REO_DST_RING_MAX. However, the ath11k_dp_process_rx() function access ath11k_soc_dp_stats::hal_reo_error using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath11k_dp_process_rx() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49931", "url": "https://ubuntu.com/security/CVE-2024-49931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix array out-of-bound access in SoC stats Currently, the ath12k_soc_dp_stats::hal_reo_error array is defined with a maximum size of DP_REO_DST_RING_MAX. However, the ath12k_dp_rx_process() function access ath12k_soc_dp_stats::hal_reo_error using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath12k_dp_rx_process() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49932", "url": "https://ubuntu.com/security/CVE-2024-49932", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: don't readahead the relocation inode on RST On relocation we're doing readahead on the relocation inode, but if the filesystem is backed by a RAID stripe tree we can get ENOENT (e.g. due to preallocated extents not being mapped in the RST) from the lookup. But readahead doesn't handle the error and submits invalid reads to the device, causing an assertion in the scatter-gather list code: BTRFS info (device nvme1n1): balance: start -d -m -s BTRFS info (device nvme1n1): relocating block group 6480920576 flags data|raid0 BTRFS error (device nvme1n1): cannot find raid-stripe for logical [6481928192, 6481969152] devid 2, profile raid0 ------------[ cut here ]------------ kernel BUG at include/linux/scatterlist.h:115! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 1012 Comm: btrfs Not tainted 6.10.0-rc7+ #567 RIP: 0010:__blk_rq_map_sg+0x339/0x4a0 RSP: 0018:ffffc90001a43820 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffea00045d4802 RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000 RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000001000 R12: ffff8881003d10b8 R13: ffffc90001a438f0 R14: 0000000000000000 R15: 0000000000003000 FS: 00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000002cd11000 CR3: 00000001109ea001 CR4: 0000000000370eb0 Call Trace: ? __die_body.cold+0x14/0x25 ? die+0x2e/0x50 ? do_trap+0xca/0x110 ? do_error_trap+0x65/0x80 ? __blk_rq_map_sg+0x339/0x4a0 ? exc_invalid_op+0x50/0x70 ? __blk_rq_map_sg+0x339/0x4a0 ? asm_exc_invalid_op+0x1a/0x20 ? __blk_rq_map_sg+0x339/0x4a0 nvme_prep_rq.part.0+0x9d/0x770 nvme_queue_rq+0x7d/0x1e0 __blk_mq_issue_directly+0x2a/0x90 ? blk_mq_get_budget_and_tag+0x61/0x90 blk_mq_try_issue_list_directly+0x56/0xf0 blk_mq_flush_plug_list.part.0+0x52b/0x5d0 __blk_flush_plug+0xc6/0x110 blk_finish_plug+0x28/0x40 read_pages+0x160/0x1c0 page_cache_ra_unbounded+0x109/0x180 relocate_file_extent_cluster+0x611/0x6a0 ? btrfs_search_slot+0xba4/0xd20 ? balance_dirty_pages_ratelimited_flags+0x26/0xb00 relocate_data_extent.constprop.0+0x134/0x160 relocate_block_group+0x3f2/0x500 btrfs_relocate_block_group+0x250/0x430 btrfs_relocate_chunk+0x3f/0x130 btrfs_balance+0x71b/0xef0 ? kmalloc_trace_noprof+0x13b/0x280 btrfs_ioctl+0x2c2e/0x3030 ? kvfree_call_rcu+0x1e6/0x340 ? list_lru_add_obj+0x66/0x80 ? mntput_no_expire+0x3a/0x220 __x64_sys_ioctl+0x96/0xc0 do_syscall_64+0x54/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fcc04514f9b Code: Unable to access opcode bytes at 0x7fcc04514f71. RSP: 002b:00007ffeba923370 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fcc04514f9b RDX: 00007ffeba923460 RSI: 00000000c4009420 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000013 R09: 0000000000000001 R10: 00007fcc043fbba8 R11: 0000000000000246 R12: 00007ffeba924fc5 R13: 00007ffeba923460 R14: 0000000000000002 R15: 00000000004d4bb0 Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:__blk_rq_map_sg+0x339/0x4a0 RSP: 0018:ffffc90001a43820 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffea00045d4802 RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000 RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000001000 R12: ffff8881003d10b8 R13: ffffc90001a438f0 R14: 0000000000000000 R15: 0000000000003000 FS: 00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcc04514f71 CR3: 00000001109ea001 CR4: 0000000000370eb0 Kernel p ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49933", "url": "https://ubuntu.com/security/CVE-2024-49933", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk_iocost: fix more out of bound shifts Recently running UBSAN caught few out of bound shifts in the ioc_forgive_debts() function: UBSAN: shift-out-of-bounds in block/blk-iocost.c:2142:38 shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long long') ... UBSAN: shift-out-of-bounds in block/blk-iocost.c:2144:30 shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long long') ... Call Trace: dump_stack_lvl+0xca/0x130 __ubsan_handle_shift_out_of_bounds+0x22c/0x280 ? __lock_acquire+0x6441/0x7c10 ioc_timer_fn+0x6cec/0x7750 ? blk_iocost_init+0x720/0x720 ? call_timer_fn+0x5d/0x470 call_timer_fn+0xfa/0x470 ? blk_iocost_init+0x720/0x720 __run_timer_base+0x519/0x700 ... Actual impact of this issue was not identified but I propose to fix the undefined behaviour. The proposed fix to prevent those out of bound shifts consist of precalculating exponent before using it the shift operations by taking min value from the actual exponent and maximum possible number of bits.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49934", "url": "https://ubuntu.com/security/CVE-2024-49934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/inode: Prevent dump_mapping() accessing invalid dentry.d_name.name It's observed that a crash occurs during hot-remove a memory device, in which user is accessing the hugetlb. See calltrace as following: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 14045 at arch/x86/mm/fault.c:1278 do_user_addr_fault+0x2a0/0x790 Modules linked in: kmem device_dax cxl_mem cxl_pmem cxl_port cxl_pci dax_hmem dax_pmem nd_pmem cxl_acpi nd_btt cxl_core crc32c_intel nvme virtiofs fuse nvme_core nfit libnvdimm dm_multipath scsi_dh_rdac scsi_dh_emc s mirror dm_region_hash dm_log dm_mod CPU: 1 PID: 14045 Comm: daxctl Not tainted 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:do_user_addr_fault+0x2a0/0x790 Code: 48 8b 00 a8 04 0f 84 b5 fe ff ff e9 1c ff ff ff 4c 89 e9 4c 89 e2 be 01 00 00 00 bf 02 00 00 00 e8 b5 ef 24 00 e9 42 fe ff ff <0f> 0b 48 83 c4 08 4c 89 ea 48 89 ee 4c 89 e7 5b 5d 41 5c 41 5d 41 RSP: 0000:ffffc90000a575f0 EFLAGS: 00010046 RAX: ffff88800c303600 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000001000 RSI: ffffffff82504162 RDI: ffffffff824b2c36 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffc90000a57658 R13: 0000000000001000 R14: ffff88800bc2e040 R15: 0000000000000000 FS: 00007f51cb57d880(0000) GS:ffff88807fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000001000 CR3: 00000000072e2004 CR4: 00000000001706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn+0x8d/0x190 ? do_user_addr_fault+0x2a0/0x790 ? report_bug+0x1c3/0x1d0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? do_user_addr_fault+0x2a0/0x790 ? exc_page_fault+0x31/0x200 exc_page_fault+0x68/0x200 <...snip...> BUG: unable to handle page fault for address: 0000000000001000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI ---[ end trace 0000000000000000 ]--- BUG: unable to handle page fault for address: 0000000000001000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 14045 Comm: daxctl Kdump: loaded Tainted: G W 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:dentry_name+0x1f4/0x440 <...snip...> ? dentry_name+0x2fa/0x440 vsnprintf+0x1f3/0x4f0 vprintk_store+0x23a/0x540 vprintk_emit+0x6d/0x330 _printk+0x58/0x80 dump_mapping+0x10b/0x1a0 ? __pfx_free_object_rcu+0x10/0x10 __dump_page+0x26b/0x3e0 ? vprintk_emit+0xe0/0x330 ? _printk+0x58/0x80 ? dump_page+0x17/0x50 dump_page+0x17/0x50 do_migrate_range+0x2f7/0x7f0 ? do_migrate_range+0x42/0x7f0 ? offline_pages+0x2f4/0x8c0 offline_pages+0x60a/0x8c0 memory_subsys_offline+0x9f/0x1c0 ? lockdep_hardirqs_on+0x77/0x100 ? _raw_spin_unlock_irqrestore+0x38/0x60 device_offline+0xe3/0x110 state_store+0x6e/0xc0 kernfs_fop_write_iter+0x143/0x200 vfs_write+0x39f/0x560 ksys_write+0x65/0xf0 do_syscall_64+0x62/0x130 Previously, some sanity check have been done in dump_mapping() before the print facility parsing '%pd' though, it's still possible to run into an invalid dentry.d_name.name. Since dump_mapping() only needs to dump the filename only, retrieve it by itself in a safer way to prevent an unnecessary crash. Note that either retrieving the filename with '%pd' or strncpy_from_kernel_nofault(), the filename could be unreliable.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49935", "url": "https://ubuntu.com/security/CVE-2024-49935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: PAD: fix crash in exit_round_robin() The kernel occasionally crashes in cpumask_clear_cpu(), which is called within exit_round_robin(), because when executing clear_bit(nr, addr) with nr set to 0xffffffff, the address calculation may cause misalignment within the memory, leading to access to an invalid memory address. ---------- BUG: unable to handle kernel paging request at ffffffffe0740618 ... CPU: 3 PID: 2919323 Comm: acpi_pad/14 Kdump: loaded Tainted: G OE X --------- - - 4.18.0-425.19.2.el8_7.x86_64 #1 ... RIP: 0010:power_saving_thread+0x313/0x411 [acpi_pad] Code: 89 cd 48 89 d3 eb d1 48 c7 c7 55 70 72 c0 e8 64 86 b0 e4 c6 05 0d a1 02 00 01 e9 bc fd ff ff 45 89 e4 42 8b 04 a5 20 82 72 c0 48 0f b3 05 f4 9c 01 00 42 c7 04 a5 20 82 72 c0 ff ff ff ff 31 RSP: 0018:ff72a5d51fa77ec8 EFLAGS: 00010202 RAX: 00000000ffffffff RBX: ff462981e5d8cb80 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246 RBP: ff46297556959d80 R08: 0000000000000382 R09: ff46297c8d0f38d8 R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000000e R13: 0000000000000000 R14: ffffffffffffffff R15: 000000000000000e FS: 0000000000000000(0000) GS:ff46297a800c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffe0740618 CR3: 0000007e20410004 CR4: 0000000000771ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? acpi_pad_add+0x120/0x120 [acpi_pad] kthread+0x10b/0x130 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x1f/0x40 ... CR2: ffffffffe0740618 crash> dis -lr ffffffffc0726923 ... /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 114 0xffffffffc0726918 :\tmov %r12d,%r12d /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 325 0xffffffffc072691b :\tmov -0x3f8d7de0(,%r12,4),%eax /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./arch/x86/include/asm/bitops.h: 80 0xffffffffc0726923 :\tlock btr %rax,0x19cf4(%rip) # 0xffffffffc0740620 crash> px tsk_in_cpu[14] $66 = 0xffffffff crash> px 0xffffffffc072692c+0x19cf4 $99 = 0xffffffffc0740620 crash> sym 0xffffffffc0740620 ffffffffc0740620 (b) pad_busy_cpus_bits [acpi_pad] crash> px pad_busy_cpus_bits[0] $42 = 0xfffc0 ---------- To fix this, ensure that tsk_in_cpu[tsk_index] != -1 before calling cpumask_clear_cpu() in exit_round_robin(), just as it is done in round_robin_cpu(). [ rjw: Subject edit, avoid updates to the same value ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49936", "url": "https://ubuntu.com/security/CVE-2024-49936", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/xen-netback: prevent UAF in xenvif_flush_hash() During the list_for_each_entry_rcu iteration call of xenvif_flush_hash, kfree_rcu does not exist inside the rcu read critical section, so if kfree_rcu is called when the rcu grace period ends during the iteration, UAF occurs when accessing head->next after the entry becomes free. Therefore, to solve this, you need to change it to list_for_each_entry_safe.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49937", "url": "https://ubuntu.com/security/CVE-2024-49937", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Set correct chandef when starting CAC When starting CAC in a mode other than AP mode, it return a \"WARNING: CPU: 0 PID: 63 at cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]\" caused by the chandef.chan being null at the end of CAC. Solution: Ensure the channel definition is set for the different modes when starting CAC to avoid getting a NULL 'chan' at the end of CAC. Call Trace: ? show_regs.part.0+0x14/0x16 ? __warn+0x67/0xc0 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? report_bug+0xa7/0x130 ? exc_overflow+0x30/0x30 ? handle_bug+0x27/0x50 ? exc_invalid_op+0x18/0x60 ? handle_exception+0xf6/0xf6 ? exc_overflow+0x30/0x30 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? exc_overflow+0x30/0x30 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? regulatory_propagate_dfs_state.cold+0x1b/0x4c [cfg80211] ? cfg80211_propagate_cac_done_wk+0x1a/0x30 [cfg80211] ? process_one_work+0x165/0x280 ? worker_thread+0x120/0x3f0 ? kthread+0xc2/0xf0 ? process_one_work+0x280/0x280 ? kthread_complete_and_exit+0x20/0x20 ? ret_from_fork+0x19/0x24 [shorten subject, remove OCB, reorder cases to match previous list]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49938", "url": "https://ubuntu.com/security/CVE-2024-49938", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmit Syzbot points out that skb_trim() has a sanity check on the existing length of the skb, which can be uninitialised in some error paths. The intent here is clearly just to reset the length to zero before resubmitting, so switch to calling __skb_set_length(skb, 0) directly. In addition, __skb_set_length() already contains a call to skb_reset_tail_pointer(), so remove the redundant call. The syzbot report came from ath9k_hif_usb_reg_in_cb(), but there's a similar usage of skb_trim() in ath9k_hif_usb_rx_cb(), change both while we're at it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49939", "url": "https://ubuntu.com/security/CVE-2024-49939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: avoid to add interface to list twice when SER If SER L2 occurs during the WoWLAN resume flow, the add interface flow is triggered by ieee80211_reconfig(). However, due to rtw89_wow_resume() return failure, it will cause the add interface flow to be executed again, resulting in a double add list and causing a kernel panic. Therefore, we have added a check to prevent double adding of the list. list_add double add: new=ffff99d6992e2010, prev=ffff99d6992e2010, next=ffff99d695302628. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:37! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G W O 6.6.30-02659-gc18865c4dfbd #1 770df2933251a0e3c888ba69d1053a817a6376a7 Hardware name: HP Grunt/Grunt, BIOS Google_Grunt.11031.169.0 06/24/2021 Workqueue: events_freezable ieee80211_restart_work [mac80211] RIP: 0010:__list_add_valid_or_report+0x5e/0xb0 Code: c7 74 18 48 39 ce 74 13 b0 01 59 5a 5e 5f 41 58 41 59 41 5a 5d e9 e2 d6 03 00 cc 48 c7 c7 8d 4f 17 83 48 89 c2 e8 02 c0 00 00 <0f> 0b 48 c7 c7 aa 8c 1c 83 e8 f4 bf 00 00 0f 0b 48 c7 c7 c8 bc 12 RSP: 0018:ffffa91b8007bc50 EFLAGS: 00010246 RAX: 0000000000000058 RBX: ffff99d6992e0900 RCX: a014d76c70ef3900 RDX: ffffa91b8007bae8 RSI: 00000000ffffdfff RDI: 0000000000000001 RBP: ffffa91b8007bc88 R08: 0000000000000000 R09: ffffa91b8007bae0 R10: 00000000ffffdfff R11: ffffffff83a79800 R12: ffff99d695302060 R13: ffff99d695300900 R14: ffff99d6992e1be0 R15: ffff99d6992e2010 FS: 0000000000000000(0000) GS:ffff99d6aac00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000078fbdba43480 CR3: 000000010e464000 CR4: 00000000001506f0 Call Trace: ? __die_body+0x1f/0x70 ? die+0x3d/0x60 ? do_trap+0xa4/0x110 ? __list_add_valid_or_report+0x5e/0xb0 ? do_error_trap+0x6d/0x90 ? __list_add_valid_or_report+0x5e/0xb0 ? handle_invalid_op+0x30/0x40 ? __list_add_valid_or_report+0x5e/0xb0 ? exc_invalid_op+0x3c/0x50 ? asm_exc_invalid_op+0x16/0x20 ? __list_add_valid_or_report+0x5e/0xb0 rtw89_ops_add_interface+0x309/0x310 [rtw89_core 7c32b1ee6854761c0321027c8a58c5160e41f48f] drv_add_interface+0x5c/0x130 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ieee80211_reconfig+0x241/0x13d0 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ? finish_wait+0x3e/0x90 ? synchronize_rcu_expedited+0x174/0x260 ? sync_rcu_exp_done_unlocked+0x50/0x50 ? wake_bit_function+0x40/0x40 ieee80211_restart_work+0xf0/0x140 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] process_scheduled_works+0x1e5/0x480 worker_thread+0xea/0x1e0 kthread+0xdb/0x110 ? move_linked_works+0x90/0x90 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork+0x3b/0x50 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork_asm+0x11/0x20 Modules linked in: dm_integrity async_xor xor async_tx lz4 lz4_compress zstd zstd_compress zram zsmalloc rfcomm cmac uinput algif_hash algif_skcipher af_alg btusb btrtl iio_trig_hrtimer industrialio_sw_trigger btmtk industrialio_configfs btbcm btintel uvcvideo videobuf2_vmalloc iio_trig_sysfs videobuf2_memops videobuf2_v4l2 videobuf2_common uvc snd_hda_codec_hdmi veth snd_hda_intel snd_intel_dspcfg acpi_als snd_hda_codec industrialio_triggered_buffer kfifo_buf snd_hwdep industrialio i2c_piix4 snd_hda_core designware_i2s ip6table_nat snd_soc_max98357a xt_MASQUERADE xt_cgroup snd_soc_acp_rt5682_mach fuse rtw89_8922ae(O) rtw89_8922a(O) rtw89_pci(O) rtw89_core(O) 8021q mac80211(O) bluetooth ecdh_generic ecc cfg80211 r8152 mii joydev gsmi: Log Shutdown Reason 0x03 ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49940", "url": "https://ubuntu.com/security/CVE-2024-49940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: prevent possible tunnel refcount underflow When a session is created, it sets a backpointer to its tunnel. When the session refcount drops to 0, l2tp_session_free drops the tunnel refcount if session->tunnel is non-NULL. However, session->tunnel is set in l2tp_session_create, before the tunnel refcount is incremented by l2tp_session_register, which leaves a small window where session->tunnel is non-NULL when the tunnel refcount hasn't been bumped. Moving the assignment to l2tp_session_register is trivial but l2tp_session_create calls l2tp_session_set_header_len which uses session->tunnel to get the tunnel's encap. Add an encap arg to l2tp_session_set_header_len to avoid using session->tunnel. If l2tpv3 sessions have colliding IDs, it is possible for l2tp_v3_session_get to race with l2tp_session_register and fetch a session which doesn't yet have session->tunnel set. Add a check for this case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49941", "url": "https://ubuntu.com/security/CVE-2024-49941", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpiolib: Fix potential NULL pointer dereference in gpiod_get_label() In `gpiod_get_label()`, it is possible that `srcu_dereference_check()` may return a NULL pointer, leading to a scenario where `label->str` is accessed without verifying if `label` itself is NULL. This patch adds a proper NULL check for `label` before accessing `label->str`. The check for `label->str != NULL` is removed because `label->str` can never be NULL if `label` is not NULL. This fixes the issue where the label name was being printed as `(efault)` when dumping the sysfs GPIO file when `label == NULL`.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49996", "url": "https://ubuntu.com/security/CVE-2024-49996", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: Fix buffer overflow when parsing NFS reparse points ReparseDataLength is sum of the InodeType size and DataBuffer size. So to get DataBuffer size it is needed to subtract InodeType's size from ReparseDataLength. Function cifs_strndup_from_utf16() is currentlly accessing buf->DataBuffer at position after the end of the buffer because it does not subtract InodeType size from the length. Fix this problem and correctly subtract variable len. Member InodeType is present only when reparse buffer is large enough. Check for ReparseDataLength before accessing InodeType to prevent another invalid memory access. Major and minor rdev values are present also only when reparse buffer is large enough. Check for reparse buffer size before calling reparse_mkdev().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49942", "url": "https://ubuntu.com/security/CVE-2024-49942", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Prevent null pointer access in xe_migrate_copy xe_migrate_copy designed to copy content of TTM resources. When source resource is null, it will trigger a NULL pointer dereference in xe_migrate_copy. To avoid this situation, update lacks source flag to true for this case, the flag will trigger xe_migrate_clear rather than xe_migrate_copy. Issue trace: <7> [317.089847] xe 0000:00:02.0: [drm:xe_migrate_copy [xe]] Pass 14, sizes: 4194304 & 4194304 <7> [317.089945] xe 0000:00:02.0: [drm:xe_migrate_copy [xe]] Pass 15, sizes: 4194304 & 4194304 <1> [317.128055] BUG: kernel NULL pointer dereference, address: 0000000000000010 <1> [317.128064] #PF: supervisor read access in kernel mode <1> [317.128066] #PF: error_code(0x0000) - not-present page <6> [317.128069] PGD 0 P4D 0 <4> [317.128071] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI <4> [317.128074] CPU: 1 UID: 0 PID: 1440 Comm: kunit_try_catch Tainted: G U N 6.11.0-rc7-xe #1 <4> [317.128078] Tainted: [U]=USER, [N]=TEST <4> [317.128080] Hardware name: Intel Corporation Lunar Lake Client Platform/LNL-M LP5 RVP1, BIOS LNLMFWI1.R00.3221.D80.2407291239 07/29/2024 <4> [317.128082] RIP: 0010:xe_migrate_copy+0x66/0x13e0 [xe] <4> [317.128158] Code: 00 00 48 89 8d e0 fe ff ff 48 8b 40 10 4c 89 85 c8 fe ff ff 44 88 8d bd fe ff ff 65 48 8b 3c 25 28 00 00 00 48 89 7d d0 31 ff <8b> 79 10 48 89 85 a0 fe ff ff 48 8b 00 48 89 b5 d8 fe ff ff 83 ff <4> [317.128162] RSP: 0018:ffffc9000167f9f0 EFLAGS: 00010246 <4> [317.128164] RAX: ffff8881120d8028 RBX: ffff88814d070428 RCX: 0000000000000000 <4> [317.128166] RDX: ffff88813cb99c00 RSI: 0000000004000000 RDI: 0000000000000000 <4> [317.128168] RBP: ffffc9000167fbb8 R08: ffff88814e7b1f08 R09: 0000000000000001 <4> [317.128170] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88814e7b1f08 <4> [317.128172] R13: ffff88814e7b1f08 R14: ffff88813cb99c00 R15: 0000000000000001 <4> [317.128174] FS: 0000000000000000(0000) GS:ffff88846f280000(0000) knlGS:0000000000000000 <4> [317.128176] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [317.128178] CR2: 0000000000000010 CR3: 000000011f676004 CR4: 0000000000770ef0 <4> [317.128180] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 <4> [317.128182] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400 <4> [317.128184] PKRU: 55555554 <4> [317.128185] Call Trace: <4> [317.128187] <4> [317.128189] ? show_regs+0x67/0x70 <4> [317.128194] ? __die_body+0x20/0x70 <4> [317.128196] ? __die+0x2b/0x40 <4> [317.128198] ? page_fault_oops+0x15f/0x4e0 <4> [317.128203] ? do_user_addr_fault+0x3fb/0x970 <4> [317.128205] ? lock_acquire+0xc7/0x2e0 <4> [317.128209] ? exc_page_fault+0x87/0x2b0 <4> [317.128212] ? asm_exc_page_fault+0x27/0x30 <4> [317.128216] ? xe_migrate_copy+0x66/0x13e0 [xe] <4> [317.128263] ? __lock_acquire+0xb9d/0x26f0 <4> [317.128265] ? __lock_acquire+0xb9d/0x26f0 <4> [317.128267] ? sg_free_append_table+0x20/0x80 <4> [317.128271] ? lock_acquire+0xc7/0x2e0 <4> [317.128273] ? mark_held_locks+0x4d/0x80 <4> [317.128275] ? trace_hardirqs_on+0x1e/0xd0 <4> [317.128278] ? _raw_spin_unlock_irqrestore+0x31/0x60 <4> [317.128281] ? __pm_runtime_resume+0x60/0xa0 <4> [317.128284] xe_bo_move+0x682/0xc50 [xe] <4> [317.128315] ? lock_is_held_type+0xaa/0x120 <4> [317.128318] ttm_bo_handle_move_mem+0xe5/0x1a0 [ttm] <4> [317.128324] ttm_bo_validate+0xd1/0x1a0 [ttm] <4> [317.128328] shrink_test_run_device+0x721/0xc10 [xe] <4> [317.128360] ? find_held_lock+0x31/0x90 <4> [317.128363] ? lock_release+0xd1/0x2a0 <4> [317.128365] ? __pfx_kunit_generic_run_threadfn_adapter+0x10/0x10 [kunit] <4> [317.128370] xe_bo_shrink_kunit+0x11/0x20 [xe] <4> [317.128397] kunit_try_run_case+0x6e/0x150 [kunit] <4> [317.128400] ? trace_hardirqs_on+0x1e/0xd0 <4> [317.128402] ? _raw_spin_unlock_irqrestore+0x31/0x60 <4> [317.128404] kunit_generic_run_threadfn_adapter+0x1e/0x40 [ku ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49943", "url": "https://ubuntu.com/security/CVE-2024-49943", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc_submit: add missing locking in wedged_fini Any non-wedged queue can have a zero refcount here and can be running concurrently with an async queue destroy, therefore dereferencing the queue ptr to check wedge status after the lookup can trigger UAF if queue is not wedged. Fix this by keeping the submission_state lock held around the check to postpone the free and make the check safe, before dropping again around the put() to avoid the deadlock. (cherry picked from commit d28af0b6b9580b9f90c265a7da0315b0ad20bbfd)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50011", "url": "https://ubuntu.com/security/CVE-2024-50011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: soc-acpi-intel-rpl-match: add missing empty item There is no links_num in struct snd_soc_acpi_mach {}, and we test !link->num_adr as a condition to end the loop in hda_sdw_machine_select(). So an empty item in struct snd_soc_acpi_link_adr array is required.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50174", "url": "https://ubuntu.com/security/CVE-2024-50174", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix race when converting group handle to group object XArray provides it's own internal lock which protects the internal array when entries are being simultaneously added and removed. However there is still a race between retrieving the pointer from the XArray and incrementing the reference count. To avoid this race simply hold the internal XArray lock when incrementing the reference count, this ensures there cannot be a racing call to xa_erase().", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49944", "url": "https://ubuntu.com/security/CVE-2024-49944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_start In sctp_listen_start() invoked by sctp_inet_listen(), it should set the sk_state back to CLOSED if sctp_autobind() fails due to whatever reason. Otherwise, next time when calling sctp_inet_listen(), if sctp_sk(sk)->reuse is already set via setsockopt(SCTP_REUSE_PORT), sctp_sk(sk)->bind_hash will be dereferenced as sk_state is LISTENING, which causes a crash as bind_hash is NULL. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:sctp_inet_listen+0x7f0/0xa20 net/sctp/socket.c:8617 Call Trace: __sys_listen_socket net/socket.c:1883 [inline] __sys_listen+0x1b7/0x230 net/socket.c:1894 __do_sys_listen net/socket.c:1902 [inline]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49945", "url": "https://ubuntu.com/security/CVE-2024-49945", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/ncsi: Disable the ncsi work before freeing the associated structure The work function can run after the ncsi device is freed, resulting in use-after-free bugs or kernel panic.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49946", "url": "https://ubuntu.com/security/CVE-2024-49946", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: do not assume bh is held in ppp_channel_bridge_input() Networking receive path is usually handled from BH handler. However, some protocols need to acquire the socket lock, and packets might be stored in the socket backlog is the socket was owned by a user process. In this case, release_sock(), __release_sock(), and sk_backlog_rcv() might call the sk->sk_backlog_rcv() handler in process context. sybot caught ppp was not considering this case in ppp_channel_bridge_input() : WARNING: inconsistent lock state 6.11.0-rc7-syzkaller-g5f5673607153 #0 Not tainted -------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. ksoftirqd/1/24 [HC0[0]:SC1[1]:HE1:SE0] takes: ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 {SOFTIRQ-ON-W} state was registered at: lock_acquire+0x240/0x728 kernel/locking/lockdep.c:5759 __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline] _raw_spin_lock+0x48/0x60 kernel/locking/spinlock.c:154 spin_lock include/linux/spinlock.h:351 [inline] ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline] ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0xfc/0x314 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv include/net/sock.h:1111 [inline] __release_sock+0x1a8/0x3d8 net/core/sock.c:3004 release_sock+0x68/0x1b8 net/core/sock.c:3558 pppoe_sendmsg+0xc8/0x5d8 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x374/0x4f4 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __arm64_sys_sendto+0xd8/0xf8 net/socket.c:2212 __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:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 irq event stamp: 282914 hardirqs last enabled at (282914): [] __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:151 [inline] hardirqs last enabled at (282914): [] _raw_spin_unlock_irqrestore+0x38/0x98 kernel/locking/spinlock.c:194 hardirqs last disabled at (282913): [] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline] hardirqs last disabled at (282913): [] _raw_spin_lock_irqsave+0x2c/0x7c kernel/locking/spinlock.c:162 softirqs last enabled at (282904): [] softirq_handle_end kernel/softirq.c:400 [inline] softirqs last enabled at (282904): [] handle_softirqs+0xa3c/0xbfc kernel/softirq.c:582 softirqs last disabled at (282909): [] run_ksoftirqd+0x70/0x158 kernel/softirq.c:928 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&pch->downl); lock(&pch->downl); *** DEADLOCK *** 1 lock held by ksoftirqd/1/24: #0: ffff80008f74dfa0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire+0x10/0x4c include/linux/rcupdate.h:325 stack backtrace: CPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 6.11.0-rc7-syzkaller-g5f5673607153 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call trace: dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:319 show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:326 __dump_sta ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49947", "url": "https://ubuntu.com/security/CVE-2024-49947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: test for not too small csum_start in virtio_net_hdr_to_skb() syzbot was able to trigger this warning [1], after injecting a malicious packet through af_packet, setting skb->csum_start and thus the transport header to an incorrect value. We can at least make sure the transport header is after the end of the network header (with a estimated minimal size). [1] [ 67.873027] skb len=4096 headroom=16 headlen=14 tailroom=0 mac=(-1,-1) mac_len=0 net=(16,-6) trans=10 shinfo(txflags=0 nr_frags=1 gso(size=0 type=0 segs=0)) csum(0xa start=10 offset=0 ip_summed=3 complete_sw=0 valid=0 level=0) hash(0x0 sw=0 l4=0) proto=0x0800 pkttype=0 iif=0 priority=0x0 mark=0x0 alloc_cpu=10 vlan_all=0x0 encapsulation=0 inner(proto=0x0000, mac=0, net=0, trans=0) [ 67.877172] dev name=veth0_vlan feat=0x000061164fdd09e9 [ 67.877764] sk family=17 type=3 proto=0 [ 67.878279] skb linear: 00000000: 00 00 10 00 00 00 00 00 0f 00 00 00 08 00 [ 67.879128] skb frag: 00000000: 0e 00 07 00 00 00 28 00 08 80 1c 00 04 00 00 02 [ 67.879877] skb frag: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.880647] skb frag: 00000020: 00 00 02 00 00 00 08 00 1b 00 00 00 00 00 00 00 [ 67.881156] skb frag: 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.881753] skb frag: 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.882173] skb frag: 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.882790] skb frag: 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.883171] skb frag: 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.883733] skb frag: 00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.884206] skb frag: 00000090: 00 00 00 00 00 00 00 00 00 00 69 70 76 6c 61 6e [ 67.884704] skb frag: 000000a0: 31 00 00 00 00 00 00 00 00 00 2b 00 00 00 00 00 [ 67.885139] skb frag: 000000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.885677] skb frag: 000000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.886042] skb frag: 000000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.886408] skb frag: 000000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.887020] skb frag: 000000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.887384] skb frag: 00000100: 00 00 [ 67.887878] ------------[ cut here ]------------ [ 67.887908] offset (-6) >= skb_headlen() (14) [ 67.888445] WARNING: CPU: 10 PID: 2088 at net/core/dev.c:3332 skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.889353] Modules linked in: macsec macvtap macvlan hsr wireguard curve25519_x86_64 libcurve25519_generic libchacha20poly1305 chacha_x86_64 libchacha poly1305_x86_64 dummy bridge sr_mod cdrom evdev pcspkr i2c_piix4 9pnet_virtio 9p 9pnet netfs [ 67.890111] CPU: 10 UID: 0 PID: 2088 Comm: b363492833 Not tainted 6.11.0-virtme #1011 [ 67.890183] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 67.890309] RIP: 0010:skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891043] Call Trace: [ 67.891173] [ 67.891274] ? __warn (kernel/panic.c:741) [ 67.891320] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891333] ? report_bug (lib/bug.c:180 lib/bug.c:219) [ 67.891348] ? handle_bug (arch/x86/kernel/traps.c:239) [ 67.891363] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) [ 67.891372] ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621) [ 67.891388] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891399] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891416] ip_do_fragment (net/ipv4/ip_output.c:777 (discriminator 1)) [ 67.891448] ? __ip_local_out (./include/linux/skbuff.h:1146 ./include/net/l3mdev.h:196 ./include/net/l3mdev.h:213 ne ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49948", "url": "https://ubuntu.com/security/CVE-2024-49948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: add more sanity checks to qdisc_pkt_len_init() One path takes care of SKB_GSO_DODGY, assuming skb->len is bigger than hdr_len. virtio_net_hdr_to_skb() does not fully dissect TCP headers, it only make sure it is at least 20 bytes. It is possible for an user to provide a malicious 'GSO' packet, total length of 80 bytes. - 20 bytes of IPv4 header - 60 bytes TCP header - a small gso_size like 8 virtio_net_hdr_to_skb() would declare this packet as a normal GSO packet, because it would see 40 bytes of payload, bigger than gso_size. We need to make detect this case to not underflow qdisc_skb_cb(skb)->pkt_len.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49949", "url": "https://ubuntu.com/security/CVE-2024-49949", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: avoid potential underflow in qdisc_pkt_len_init() with UFO After commit 7c6d2ecbda83 (\"net: be more gentle about silly gso requests coming from user\") virtio_net_hdr_to_skb() had sanity check to detect malicious attempts from user space to cook a bad GSO packet. Then commit cf9acc90c80ec (\"net: virtio_net_hdr_to_skb: count transport header in UFO\") while fixing one issue, allowed user space to cook a GSO packet with the following characteristic : IPv4 SKB_GSO_UDP, gso_size=3, skb->len = 28. When this packet arrives in qdisc_pkt_len_init(), we end up with hdr_len = 28 (IPv4 header + UDP header), matching skb->len Then the following sets gso_segs to 0 : gso_segs = DIV_ROUND_UP(skb->len - hdr_len, shinfo->gso_size); Then later we set qdisc_skb_cb(skb)->pkt_len to back to zero :/ qdisc_skb_cb(skb)->pkt_len += (gso_segs - 1) * hdr_len; This leads to the following crash in fq_codel [1] qdisc_pkt_len_init() is best effort, we only want an estimation of the bytes sent on the wire, not crashing the kernel. This patch is fixing this particular issue, a following one adds more sanity checks for another potential bug. [1] [ 70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 70.724561] #PF: supervisor read access in kernel mode [ 70.724561] #PF: error_code(0x0000) - not-present page [ 70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0 [ 70.724561] Oops: Oops: 0000 [#1] SMP NOPTI [ 70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991 [ 70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel [ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 <49> 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49 All code ======== 0:\t24 08 \tand $0x8,%al 2:\t49 c1 e1 06 \tshl $0x6,%r9 6:\t44 89 7c 24 18 \tmov %r15d,0x18(%rsp) b:\t45 31 ed \txor %r13d,%r13d e:\t45 31 c0 \txor %r8d,%r8d 11:\t31 ff \txor %edi,%edi 13:\t89 44 24 14 \tmov %eax,0x14(%rsp) 17:\t4c 03 8b 90 01 00 00 \tadd 0x190(%rbx),%r9 1e:\teb 04 \tjmp 0x24 20:\t39 ca \tcmp %ecx,%edx 22:\t73 37 \tjae 0x5b 24:\t4d 8b 39 \tmov (%r9),%r15 27:\t83 c7 01 \tadd $0x1,%edi 2a:*\t49 8b 17 \tmov (%r15),%rdx\t\t<-- trapping instruction 2d:\t49 89 11 \tmov %rdx,(%r9) 30:\t41 8b 57 28 \tmov 0x28(%r15),%edx 34:\t45 8b 5f 34 \tmov 0x34(%r15),%r11d 38:\t49 c7 07 00 00 00 00 \tmovq $0x0,(%r15) 3f:\t49 \trex.WB Code starting with the faulting instruction =========================================== 0:\t49 8b 17 \tmov (%r15),%rdx 3:\t49 89 11 \tmov %rdx,(%r9) 6:\t41 8b 57 28 \tmov 0x28(%r15),%edx a:\t45 8b 5f 34 \tmov 0x34(%r15),%r11d e:\t49 c7 07 00 00 00 00 \tmovq $0x0,(%r15) 15:\t49 \trex.WB [ 70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202 [ 70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000 [ 70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001 [ 70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000 [ 70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58 [ 70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000 [ 70.724561] FS: 000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000 [ 70.724561] CS: 0010 DS: 0000 ES: 0000 C ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49997", "url": "https://ubuntu.com/security/CVE-2024-49997", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: lantiq_etop: fix memory disclosure When applying padding, the buffer is not zeroed, which results in memory disclosure. The mentioned data is observed on the wire. This patch uses skb_put_padto() to pad Ethernet frames properly. The mentioned function zeroes the expanded buffer. In case the packet cannot be padded it is silently dropped. Statistics are also not incremented. This driver does not support statistics in the old 32-bit format or the new 64-bit format. These will be added in the future. In its current form, the patch should be easily backported to stable versions. Ethernet MACs on Amazon-SE and Danube cannot do padding of the packets in hardware, so software padding must be applied.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49998", "url": "https://ubuntu.com/security/CVE-2024-49998", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: improve shutdown sequence Alexander Sverdlin presents 2 problems during shutdown with the lan9303 driver. One is specific to lan9303 and the other just happens to reproduce there. The first problem is that lan9303 is unique among DSA drivers in that it calls dev_get_drvdata() at \"arbitrary runtime\" (not probe, not shutdown, not remove): phy_state_machine() -> ... -> dsa_user_phy_read() -> ds->ops->phy_read() -> lan9303_phy_read() -> chip->ops->phy_read() -> lan9303_mdio_phy_read() -> dev_get_drvdata() But we never stop the phy_state_machine(), so it may continue to run after dsa_switch_shutdown(). Our common pattern in all DSA drivers is to set drvdata to NULL to suppress the remove() method that may come afterwards. But in this case it will result in an NPD. The second problem is that the way in which we set dp->conduit->dsa_ptr = NULL; is concurrent with receive packet processing. dsa_switch_rcv() checks once whether dev->dsa_ptr is NULL, but afterwards, rather than continuing to use that non-NULL value, dev->dsa_ptr is dereferenced again and again without NULL checks: dsa_conduit_find_user() and many other places. In between dereferences, there is no locking to ensure that what was valid once continues to be valid. Both problems have the common aspect that closing the conduit interface solves them. In the first case, dev_close(conduit) triggers the NETDEV_GOING_DOWN event in dsa_user_netdevice_event() which closes user ports as well. dsa_port_disable_rt() calls phylink_stop(), which synchronously stops the phylink state machine, and ds->ops->phy_read() will thus no longer call into the driver after this point. In the second case, dev_close(conduit) should do this, as per Documentation/networking/driver.rst: | Quiescence | ---------- | | After the ndo_stop routine has been called, the hardware must | not receive or transmit any data. All in flight packets must | be aborted. If necessary, poll or wait for completion of | any reset commands. So it should be sufficient to ensure that later, when we zeroize conduit->dsa_ptr, there will be no concurrent dsa_switch_rcv() call on this conduit. The addition of the netif_device_detach() function is to ensure that ioctls, rtnetlinks and ethtool requests on the user ports no longer propagate down to the driver - we're no longer prepared to handle them. The race condition actually did not exist when commit 0650bf52b31f (\"net: dsa: be compatible with masters which unregister on shutdown\") first introduced dsa_switch_shutdown(). It was created later, when we stopped unregistering the user interfaces from a bad spot, and we just replaced that sequence with a racy zeroization of conduit->dsa_ptr (one which doesn't ensure that the interfaces aren't up).", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49999", "url": "https://ubuntu.com/security/CVE-2024-49999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix the setting of the server responding flag In afs_wait_for_operation(), we set transcribe the call responded flag to the server record that we used after doing the fileserver iteration loop - but it's possible to exit the loop having had a response from the server that we've discarded (e.g. it returned an abort or we started receiving data, but the call didn't complete). This means that op->server might be NULL, but we don't check that before attempting to set the server flag.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49950", "url": "https://ubuntu.com/security/CVE-2024-49950", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix uaf in l2cap_connect [Syzbot reported] BUG: KASAN: slab-use-after-free in l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 Read of size 8 at addr ffff8880241e9800 by task kworker/u9:0/54 CPU: 0 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-00268-g788220eee30d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Workqueue: hci2 hci_rx_work Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 l2cap_connect_req net/bluetooth/l2cap_core.c:4080 [inline] l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:4772 [inline] l2cap_sig_channel net/bluetooth/l2cap_core.c:5543 [inline] l2cap_recv_frame+0xf0b/0x8eb0 net/bluetooth/l2cap_core.c:6825 l2cap_recv_acldata+0x9b4/0xb70 net/bluetooth/l2cap_core.c:7514 hci_acldata_packet net/bluetooth/hci_core.c:3791 [inline] hci_rx_work+0xaab/0x1610 net/bluetooth/hci_core.c:4028 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 ... Freed by task 5245: 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:579 poison_slab_object+0xf7/0x160 mm/kasan/common.c:240 __kasan_slab_free+0x32/0x50 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2256 [inline] slab_free mm/slub.c:4477 [inline] kfree+0x12a/0x3b0 mm/slub.c:4598 l2cap_conn_free net/bluetooth/l2cap_core.c:1810 [inline] kref_put include/linux/kref.h:65 [inline] l2cap_conn_put net/bluetooth/l2cap_core.c:1822 [inline] l2cap_conn_del+0x59d/0x730 net/bluetooth/l2cap_core.c:1802 l2cap_connect_cfm+0x9e6/0xf80 net/bluetooth/l2cap_core.c:7241 hci_connect_cfm include/net/bluetooth/hci_core.h:1960 [inline] hci_conn_failed+0x1c3/0x370 net/bluetooth/hci_conn.c:1265 hci_abort_conn_sync+0x75a/0xb50 net/bluetooth/hci_sync.c:5583 abort_conn_sync+0x197/0x360 net/bluetooth/hci_conn.c:2917 hci_cmd_sync_work+0x1a4/0x410 net/bluetooth/hci_sync.c:328 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49951", "url": "https://ubuntu.com/security/CVE-2024-49951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Fix possible crash on mgmt_index_removed If mgmt_index_removed is called while there are commands queued on cmd_sync it could lead to crashes like the bellow trace: 0x0000053D: __list_del_entry_valid_or_report+0x98/0xdc 0x0000053D: mgmt_pending_remove+0x18/0x58 [bluetooth] 0x0000053E: mgmt_remove_adv_monitor_complete+0x80/0x108 [bluetooth] 0x0000053E: hci_cmd_sync_work+0xbc/0x164 [bluetooth] So while handling mgmt_index_removed this attempts to dequeue commands passed as user_data to cmd_sync.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49952", "url": "https://ubuntu.com/security/CVE-2024-49952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: prevent nf_skb_duplicated corruption syzbot found that nf_dup_ipv4() or nf_dup_ipv6() could write per-cpu variable nf_skb_duplicated in an unsafe way [1]. Disabling preemption as hinted by the splat is not enough, we have to disable soft interrupts as well. [1] BUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316 caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49 nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook+0x2c4/0x450 include/linux/netfilter.h:269 NF_HOOK_COND include/linux/netfilter.h:302 [inline] ip_output+0x185/0x230 net/ipv4/ip_output.c:433 ip_local_out net/ipv4/ip_output.c:129 [inline] ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495 udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981 udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737 __do_sys_sendmmsg net/socket.c:2766 [inline] __se_sys_sendmmsg net/socket.c:2763 [inline] __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763 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:0x7f4ce4f7def9 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:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9 RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006 RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49953", "url": "https://ubuntu.com/security/CVE-2024-49953", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix crash caused by calling __xfrm_state_delete() twice The km.state is not checked in driver's delayed work. When xfrm_state_check_expire() is called, the state can be reset to XFRM_STATE_EXPIRED, even if it is XFRM_STATE_DEAD already. This happens when xfrm state is deleted, but not freed yet. As __xfrm_state_delete() is called again in xfrm timer, the following crash occurs. To fix this issue, skip xfrm_state_check_expire() if km.state is not XFRM_STATE_VALID. Oops: general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] SMP CPU: 5 UID: 0 PID: 7448 Comm: kworker/u102:2 Not tainted 6.11.0-rc2+ #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5e_ipsec: eth%d mlx5e_ipsec_handle_sw_limits [mlx5_core] RIP: 0010:__xfrm_state_delete+0x3d/0x1b0 Code: 0f 84 8b 01 00 00 48 89 fd c6 87 c8 00 00 00 05 48 8d bb 40 10 00 00 e8 11 04 1a 00 48 8b 95 b8 00 00 00 48 8b 85 c0 00 00 00 <48> 89 42 08 48 89 10 48 8b 55 10 48 b8 00 01 00 00 00 00 ad de 48 RSP: 0018:ffff88885f945ec8 EFLAGS: 00010246 RAX: dead000000000122 RBX: ffffffff82afa940 RCX: 0000000000000036 RDX: dead000000000100 RSI: 0000000000000000 RDI: ffffffff82afb980 RBP: ffff888109a20340 R08: ffff88885f945ea0 R09: 0000000000000000 R10: 0000000000000000 R11: ffff88885f945ff8 R12: 0000000000000246 R13: ffff888109a20340 R14: ffff88885f95f420 R15: ffff88885f95f400 FS: 0000000000000000(0000) GS:ffff88885f940000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2163102430 CR3: 00000001128d6001 CR4: 0000000000370eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? die_addr+0x33/0x90 ? exc_general_protection+0x1a2/0x390 ? asm_exc_general_protection+0x22/0x30 ? __xfrm_state_delete+0x3d/0x1b0 ? __xfrm_state_delete+0x2f/0x1b0 xfrm_timer_handler+0x174/0x350 ? __xfrm_state_delete+0x1b0/0x1b0 __hrtimer_run_queues+0x121/0x270 hrtimer_run_softirq+0x88/0xd0 handle_softirqs+0xcc/0x270 do_softirq+0x3c/0x50 __local_bh_enable_ip+0x47/0x50 mlx5e_ipsec_handle_sw_limits+0x7d/0x90 [mlx5_core] process_one_work+0x137/0x2d0 worker_thread+0x28d/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50000", "url": "https://ubuntu.com/security/CVE-2024-50000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix NULL deref in mlx5e_tir_builder_alloc() In mlx5e_tir_builder_alloc() kvzalloc() may return NULL which is dereferenced on the next line in a reference to the modify field. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50001", "url": "https://ubuntu.com/security/CVE-2024-50001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix error path in multi-packet WQE transmit Remove the erroneous unmap in case no DMA mapping was established The multi-packet WQE transmit code attempts to obtain a DMA mapping for the skb. This could fail, e.g. under memory pressure, when the IOMMU driver just can't allocate more memory for page tables. While the code tries to handle this in the path below the err_unmap label it erroneously unmaps one entry from the sq's FIFO list of active mappings. Since the current map attempt failed this unmap is removing some random DMA mapping that might still be required. If the PCI function now presents that IOVA, the IOMMU may assumes a rogue DMA access and e.g. on s390 puts the PCI function in error state. The erroneous behavior was seen in a stress-test environment that created memory pressure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50179", "url": "https://ubuntu.com/security/CVE-2024-50179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: remove the incorrect Fw reference check when dirtying pages When doing the direct-io reads it will also try to mark pages dirty, but for the read path it won't hold the Fw caps and there is case will it get the Fw reference.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49963", "url": "https://ubuntu.com/security/CVE-2024-49963", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mailbox: bcm2835: Fix timeout during suspend mode During noirq suspend phase the Raspberry Pi power driver suffer of firmware property timeouts. The reason is that the IRQ of the underlying BCM2835 mailbox is disabled and rpi_firmware_property_list() will always run into a timeout [1]. Since the VideoCore side isn't consider as a wakeup source, set the IRQF_NO_SUSPEND flag for the mailbox IRQ in order to keep it enabled during suspend-resume cycle. [1] PM: late suspend of devices complete after 1.754 msecs WARNING: CPU: 0 PID: 438 at drivers/firmware/raspberrypi.c:128 rpi_firmware_property_list+0x204/0x22c Firmware transaction 0x00028001 timeout Modules linked in: CPU: 0 PID: 438 Comm: bash Tainted: G C 6.9.3-dirty #17 Hardware name: BCM2835 Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x44 dump_stack_lvl from __warn+0x88/0xec __warn from warn_slowpath_fmt+0x7c/0xb0 warn_slowpath_fmt from rpi_firmware_property_list+0x204/0x22c rpi_firmware_property_list from rpi_firmware_property+0x68/0x8c rpi_firmware_property from rpi_firmware_set_power+0x54/0xc0 rpi_firmware_set_power from _genpd_power_off+0xe4/0x148 _genpd_power_off from genpd_sync_power_off+0x7c/0x11c genpd_sync_power_off from genpd_finish_suspend+0xcc/0xe0 genpd_finish_suspend from dpm_run_callback+0x78/0xd0 dpm_run_callback from device_suspend_noirq+0xc0/0x238 device_suspend_noirq from dpm_suspend_noirq+0xb0/0x168 dpm_suspend_noirq from suspend_devices_and_enter+0x1b8/0x5ac suspend_devices_and_enter from pm_suspend+0x254/0x2e4 pm_suspend from state_store+0xa8/0xd4 state_store from kernfs_fop_write_iter+0x154/0x1a0 kernfs_fop_write_iter from vfs_write+0x12c/0x184 vfs_write from ksys_write+0x78/0xc0 ksys_write from ret_fast_syscall+0x0/0x54 Exception stack(0xcc93dfa8 to 0xcc93dff0) [...] PM: noirq suspend of devices complete after 3095.584 msecs", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49954", "url": "https://ubuntu.com/security/CVE-2024-49954", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: static_call: Replace pointless WARN_ON() in static_call_module_notify() static_call_module_notify() triggers a WARN_ON(), when memory allocation fails in __static_call_add_module(). That's not really justified, because the failure case must be correctly handled by the well known call chain and the error code is passed through to the initiating userspace application. A memory allocation fail is not a fatal problem, but the WARN_ON() takes the machine out when panic_on_warn is set. Replace it with a pr_warn().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50002", "url": "https://ubuntu.com/security/CVE-2024-50002", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: static_call: Handle module init failure correctly in static_call_del_module() Module insertion invokes static_call_add_module() to initialize the static calls in a module. static_call_add_module() invokes __static_call_init(), which allocates a struct static_call_mod to either encapsulate the built-in static call sites of the associated key into it so further modules can be added or to append the module to the module chain. If that allocation fails the function returns with an error code and the module core invokes static_call_del_module() to clean up eventually added static_call_mod entries. This works correctly, when all keys used by the module were converted over to a module chain before the failure. If not then static_call_del_module() causes a #GP as it blindly assumes that key::mods points to a valid struct static_call_mod. The problem is that key::mods is not a individual struct member of struct static_call_key, it's part of a union to save space: union { /* bit 0: 0 = mods, 1 = sites */ unsigned long type; struct static_call_mod *mods; struct static_call_site *sites; \t}; key::sites is a pointer to the list of built-in usage sites of the static call. The type of the pointer is differentiated by bit 0. A mods pointer has the bit clear, the sites pointer has the bit set. As static_call_del_module() blidly assumes that the pointer is a valid static_call_mod type, it fails to check for this failure case and dereferences the pointer to the list of built-in call sites, which is obviously bogus. Cure it by checking whether the key has a sites or a mods pointer. If it's a sites pointer then the key is not to be touched. As the sites are walked in the same order as in __static_call_init() the site walk can be terminated because all subsequent sites have not been touched by the init code due to the error exit. If it was converted before the allocation fail, then the inner loop which searches for a module match will find nothing. A fail in the second allocation in __static_call_init() is harmless and does not require special treatment. The first allocation succeeded and converted the key to a module chain. That first entry has mod::mod == NULL and mod::next == NULL, so the inner loop of static_call_del_module() will neither find a module match nor a module chain. The next site in the walk was either already converted, but can't match the module, or it will exit the outer loop because it has a static_call_site pointer and not a static_call_mod pointer.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-47675", "url": "https://ubuntu.com/security/CVE-2024-47675", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix use-after-free in bpf_uprobe_multi_link_attach() If bpf_link_prime() fails, bpf_uprobe_multi_link_attach() goes to the error_free label and frees the array of bpf_uprobe's without calling bpf_uprobe_unregister(). This leaks bpf_uprobe->uprobe and worse, this frees bpf_uprobe->consumer without removing it from the uprobe->consumers list.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47676", "url": "https://ubuntu.com/security/CVE-2024-47676", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb.c: fix UAF of vma in hugetlb fault pathway Syzbot reports a UAF in hugetlb_fault(). This happens because vmf_anon_prepare() could drop the per-VMA lock and allow the current VMA to be freed before hugetlb_vma_unlock_read() is called. We can fix this by using a modified version of vmf_anon_prepare() that doesn't release the VMA lock on failure, and then release it ourselves after hugetlb_vma_unlock_read().", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47677", "url": "https://ubuntu.com/security/CVE-2024-47677", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: resolve memory leak from exfat_create_upcase_table() If exfat_load_upcase_table reaches end and returns -EINVAL, allocated memory doesn't get freed and while exfat_load_default_upcase_table allocates more memory, leading to a memory leak. Here's link to syzkaller crash report illustrating this issue: https://syzkaller.appspot.com/text?tag=CrashReport&x=1406c201980000", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47725", "url": "https://ubuntu.com/security/CVE-2024-47725", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47739", "url": "https://ubuntu.com/security/CVE-2024-47739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: padata: use integer wrap around to prevent deadlock on seq_nr overflow When submitting more than 2^32 padata objects to padata_do_serial, the current sorting implementation incorrectly sorts padata objects with overflowed seq_nr, causing them to be placed before existing objects in the reorder list. This leads to a deadlock in the serialization process as padata_find_next cannot match padata->seq_nr and pd->processed because the padata instance with overflowed seq_nr will be selected next. To fix this, we use an unsigned integer wrap around to correctly sort padata objects in scenarios with integer overflow.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47678", "url": "https://ubuntu.com/security/CVE-2024-47678", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: icmp: change the order of rate limits ICMP messages are ratelimited : After the blamed commits, the two rate limiters are applied in this order: 1) host wide ratelimit (icmp_global_allow()) 2) Per destination ratelimit (inetpeer based) In order to avoid side-channels attacks, we need to apply the per destination check first. This patch makes the following change : 1) icmp_global_allow() checks if the host wide limit is reached. But credits are not yet consumed. This is deferred to 3) 2) The per destination limit is checked/updated. This might add a new node in inetpeer tree. 3) icmp_global_consume() consumes tokens if prior operations succeeded. This means that host wide ratelimit is still effective in keeping inetpeer tree small even under DDOS. As a bonus, I removed icmp_global.lock as the fast path can use a lock-free operation.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47733", "url": "https://ubuntu.com/security/CVE-2024-47733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfs: Delete subtree of 'fs/netfs' when netfs module exits In netfs_init() or fscache_proc_init(), we create dentry under 'fs/netfs', but in netfs_exit(), we only delete the proc entry of 'fs/netfs' without deleting its subtree. This triggers the following WARNING: ================================================================== remove_proc_entry: removing non-empty directory 'fs/netfs', leaking at least 'requests' WARNING: CPU: 4 PID: 566 at fs/proc/generic.c:717 remove_proc_entry+0x160/0x1c0 Modules linked in: netfs(-) CPU: 4 UID: 0 PID: 566 Comm: rmmod Not tainted 6.11.0-rc3 #860 RIP: 0010:remove_proc_entry+0x160/0x1c0 Call Trace: netfs_exit+0x12/0x620 [netfs] __do_sys_delete_module.isra.0+0x14c/0x2e0 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e ================================================================== Therefore use remove_proc_subtree() instead of remove_proc_entry() to fix the above problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47679", "url": "https://ubuntu.com/security/CVE-2024-47679", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfs: fix race between evice_inodes() and find_inode()&iput() Hi, all Recently I noticed a bug[1] in btrfs, after digged it into and I believe it'a race in vfs. Let's assume there's a inode (ie ino 261) with i_count 1 is called by iput(), and there's a concurrent thread calling generic_shutdown_super(). cpu0: cpu1: iput() // i_count is 1 ->spin_lock(inode) ->dec i_count to 0 ->iput_final() generic_shutdown_super() ->__inode_add_lru() ->evict_inodes() // cause some reason[2] ->if (atomic_read(inode->i_count)) continue; // return before // inode 261 passed the above check // list_lru_add_obj() // and then schedule out ->spin_unlock() // note here: the inode 261 // was still at sb list and hash list, // and I_FREEING|I_WILL_FREE was not been set btrfs_iget() // after some function calls ->find_inode() // found the above inode 261 ->spin_lock(inode) // check I_FREEING|I_WILL_FREE // and passed ->__iget() ->spin_unlock(inode) // schedule back ->spin_lock(inode) // check (I_NEW|I_FREEING|I_WILL_FREE) flags, // passed and set I_FREEING iput() ->spin_unlock(inode) ->spin_lock(inode)\t\t\t ->evict() // dec i_count to 0 ->iput_final() ->spin_unlock() ->evict() Now, we have two threads simultaneously evicting the same inode, which may trigger the BUG(inode->i_state & I_CLEAR) statement both within clear_inode() and iput(). To fix the bug, recheck the inode->i_count after holding i_lock. Because in the most scenarios, the first check is valid, and the overhead of spin_lock() can be reduced. If there is any misunderstanding, please let me know, thanks. [1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/ [2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable() return false when I reproduced the bug.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49859", "url": "https://ubuntu.com/security/CVE-2024-49859", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to check atomic_file in f2fs ioctl interfaces Some f2fs ioctl interfaces like f2fs_ioc_set_pin_file(), f2fs_move_file_range(), and f2fs_defragment_range() missed to check atomic_write status, which may cause potential race issue, fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47680", "url": "https://ubuntu.com/security/CVE-2024-47680", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: check discard support for conventional zones As the helper function f2fs_bdev_support_discard() shows, f2fs checks if the target block devices support discard by calling bdev_max_discard_sectors() and bdev_is_zoned(). This check works well for most cases, but it does not work for conventional zones on zoned block devices. F2fs assumes that zoned block devices support discard, and calls __submit_discard_cmd(). When __submit_discard_cmd() is called for sequential write required zones, it works fine since __submit_discard_cmd() issues zone reset commands instead of discard commands. However, when __submit_discard_cmd() is called for conventional zones, __blkdev_issue_discard() is called even when the devices do not support discard. The inappropriate __blkdev_issue_discard() call was not a problem before the commit 30f1e7241422 (\"block: move discard checks into the ioctl handler\") because __blkdev_issue_discard() checked if the target devices support discard or not. If not, it returned EOPNOTSUPP. After the commit, __blkdev_issue_discard() no longer checks it. It always returns zero and sets NULL to the given bio pointer. This NULL pointer triggers f2fs_bug_on() in __submit_discard_cmd(). The BUG is recreated with the commands below at the umount step, where /dev/nullb0 is a zoned null_blk with 5GB total size, 128MB zone size and 10 conventional zones. $ mkfs.f2fs -f -m /dev/nullb0 $ mount /dev/nullb0 /mnt $ for ((i=0;i<5;i++)); do dd if=/dev/zero of=/mnt/test bs=65536 count=1600 conv=fsync; done $ umount /mnt To fix the BUG, avoid the inappropriate __blkdev_issue_discard() call. When discard is requested for conventional zones, check if the device supports discard or not. If not, return EOPNOTSUPP.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47740", "url": "https://ubuntu.com/security/CVE-2024-47740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: Require FMODE_WRITE for atomic write ioctls The F2FS ioctls for starting and committing atomic writes check for inode_owner_or_capable(), but this does not give LSMs like SELinux or Landlock an opportunity to deny the write access - if the caller's FSUID matches the inode's UID, inode_owner_or_capable() immediately returns true. There are scenarios where LSMs want to deny a process the ability to write particular files, even files that the FSUID of the process owns; but this can currently partially be bypassed using atomic write ioctls in two ways: - F2FS_IOC_START_ATOMIC_REPLACE + F2FS_IOC_COMMIT_ATOMIC_WRITE can truncate an inode to size 0 - F2FS_IOC_START_ATOMIC_WRITE + F2FS_IOC_ABORT_ATOMIC_WRITE can revert changes another process concurrently made to a file Fix it by requiring FMODE_WRITE for these operations, just like for F2FS_IOC_MOVE_RANGE. Since any legitimate caller should only be using these ioctls when intending to write into the file, that seems unlikely to break anything.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47726", "url": "https://ubuntu.com/security/CVE-2024-47726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to wait dio completion It should wait all existing dio write IOs before block removal, otherwise, previous direct write IO may overwrite data in the block which may be reused by other inode.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47741", "url": "https://ubuntu.com/security/CVE-2024-47741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race setting file private on concurrent lseek using same fd When doing concurrent lseek(2) system calls against the same file descriptor, using multiple threads belonging to the same process, we have a short time window where a race happens and can result in a memory leak. The race happens like this: 1) A program opens a file descriptor for a file and then spawns two threads (with the pthreads library for example), lets call them task A and task B; 2) Task A calls lseek with SEEK_DATA or SEEK_HOLE and ends up at file.c:find_desired_extent() while holding a read lock on the inode; 3) At the start of find_desired_extent(), it extracts the file's private_data pointer into a local variable named 'private', which has a value of NULL; 4) Task B also calls lseek with SEEK_DATA or SEEK_HOLE, locks the inode in shared mode and enters file.c:find_desired_extent(), where it also extracts file->private_data into its local variable 'private', which has a NULL value; 5) Because it saw a NULL file private, task A allocates a private structure and assigns to the file structure; 6) Task B also saw a NULL file private so it also allocates its own file private and then assigns it to the same file structure, since both tasks are using the same file descriptor. At this point we leak the private structure allocated by task A. Besides the memory leak, there's also the detail that both tasks end up using the same cached state record in the private structure (struct btrfs_file_private::llseek_cached_state), which can result in a use-after-free problem since one task can free it while the other is still using it (only one task took a reference count on it). Also, sharing the cached state is not a good idea since it could result in incorrect results in the future - right now it should not be a problem because it end ups being used only in extent-io-tree.c:count_range_bits() where we do range validation before using the cached state. Fix this by protecting the private assignment and check of a file while holding the inode's spinlock and keep track of the task that allocated the private, so that it's used only by that task in order to prevent user-after-free issues with the cached state record as well as potentially using it incorrectly in the future.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47681", "url": "https://ubuntu.com/security/CVE-2024-47681", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix NULL pointer dereference in mt7996_mcu_sta_bfer_he Fix the NULL pointer dereference in mt7996_mcu_sta_bfer_he routine adding an sta interface to the mt7996 driver. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49858", "url": "https://ubuntu.com/security/CVE-2024-49858", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption The TPM event log table is a Linux specific construct, where the data produced by the GetEventLog() boot service is cached in memory, and passed on to the OS using an EFI configuration table. The use of EFI_LOADER_DATA here results in the region being left unreserved in the E820 memory map constructed by the EFI stub, and this is the memory description that is passed on to the incoming kernel by kexec, which is therefore unaware that the region should be reserved. Even though the utility of the TPM2 event log after a kexec is questionable, any corruption might send the parsing code off into the weeds and crash the kernel. So let's use EFI_ACPI_RECLAIM_MEMORY instead, which is always treated as reserved by the E820 conversion logic.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49860", "url": "https://ubuntu.com/security/CVE-2024-49860", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: sysfs: validate return type of _STR method Only buffer objects are valid return values of _STR. If something else is returned description_show() will access invalid memory.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47742", "url": "https://ubuntu.com/security/CVE-2024-47742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware_loader: Block path traversal Most firmware names are hardcoded strings, or are constructed from fairly constrained format strings where the dynamic parts are just some hex numbers or such. However, there are a couple codepaths in the kernel where firmware file names contain string components that are passed through from a device or semi-privileged userspace; the ones I could find (not counting interfaces that require root privileges) are: - lpfc_sli4_request_firmware_update() seems to construct the firmware filename from \"ModelName\", a string that was previously parsed out of some descriptor (\"Vital Product Data\") in lpfc_fill_vpd() - nfp_net_fw_find() seems to construct a firmware filename from a model name coming from nfp_hwinfo_lookup(pf->hwinfo, \"nffw.partno\"), which I think parses some descriptor that was read from the device. (But this case likely isn't exploitable because the format string looks like \"netronome/nic_%s\", and there shouldn't be any *folders* starting with \"netronome/nic_\". The previous case was different because there, the \"%s\" is *at the start* of the format string.) - module_flash_fw_schedule() is reachable from the ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is enough to pass the privilege check), and takes a userspace-provided firmware name. (But I think to reach this case, you need to have CAP_NET_ADMIN over a network namespace that a special kind of ethernet device is mapped into, so I think this is not a viable attack path in practice.) Fix it by rejecting any firmware names containing \"..\" path components. For what it's worth, I went looking and haven't found any USB device drivers that use the firmware loader dangerously.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47682", "url": "https://ubuntu.com/security/CVE-2024-47682", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sd: Fix off-by-one error in sd_read_block_characteristics() Ff the device returns page 0xb1 with length 8 (happens with qemu v2.x, for example), sd_read_block_characteristics() may attempt an out-of-bounds memory access when accessing the zoned field at offset 8.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47743", "url": "https://ubuntu.com/security/CVE-2024-47743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: prevent NULL pointer dereference in find_asymmetric_key() In find_asymmetric_key(), if all NULLs are passed in the id_{0,1,2} arguments, the kernel will first emit WARN but then have an oops because id_2 gets dereferenced anyway. Add the missing id_2 check and move WARN_ON() to the final else branch to avoid duplicate NULL checks. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47727", "url": "https://ubuntu.com/security/CVE-2024-47727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/tdx: Fix \"in-kernel MMIO\" check TDX only supports kernel-initiated MMIO operations. The handle_mmio() function checks if the #VE exception occurred in the kernel and rejects the operation if it did not. However, userspace can deceive the kernel into performing MMIO on its behalf. For example, if userspace can point a syscall to an MMIO address, syscall does get_user() or put_user() on it, triggering MMIO #VE. The kernel will treat the #VE as in-kernel MMIO. Ensure that the target MMIO address is within the kernel before decoding instruction.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47744", "url": "https://ubuntu.com/security/CVE-2024-47744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Use dedicated mutex to protect kvm_usage_count to avoid deadlock Use a dedicated mutex to guard kvm_usage_count to fix a potential deadlock on x86 due to a chain of locks and SRCU synchronizations. Translating the below lockdep splat, CPU1 #6 will wait on CPU0 #1, CPU0 #8 will wait on CPU2 #3, and CPU2 #7 will wait on CPU1 #4 (if there's a writer, due to the fairness of r/w semaphores). CPU0 CPU1 CPU2 1 lock(&kvm->slots_lock); 2 lock(&vcpu->mutex); 3 lock(&kvm->srcu); 4 lock(cpu_hotplug_lock); 5 lock(kvm_lock); 6 lock(&kvm->slots_lock); 7 lock(cpu_hotplug_lock); 8 sync(&kvm->srcu); Note, there are likely more potential deadlocks in KVM x86, e.g. the same pattern of taking cpu_hotplug_lock outside of kvm_lock likely exists with __kvmclock_cpufreq_notifier(): cpuhp_cpufreq_online() | -> cpufreq_online() | -> cpufreq_gov_performance_limits() | -> __cpufreq_driver_target() | -> __target_index() | -> cpufreq_freq_transition_begin() | -> cpufreq_notify_transition() | -> ... __kvmclock_cpufreq_notifier() But, actually triggering such deadlocks is beyond rare due to the combination of dependencies and timings involved. E.g. the cpufreq notifier is only used on older CPUs without a constant TSC, mucking with the NX hugepage mitigation while VMs are running is very uncommon, and doing so while also onlining/offlining a CPU (necessary to generate contention on cpu_hotplug_lock) would be even more unusual. The most robust solution to the general cpu_hotplug_lock issue is likely to switch vm_list to be an RCU-protected list, e.g. so that x86's cpufreq notifier doesn't to take kvm_lock. For now, settle for fixing the most blatant deadlock, as switching to an RCU-protected list is a much more involved change, but add a comment in locking.rst to call out that care needs to be taken when walking holding kvm_lock and walking vm_list. ====================================================== WARNING: possible circular locking dependency detected 6.10.0-smp--c257535a0c9d-pip #330 Tainted: G S O ------------------------------------------------------ tee/35048 is trying to acquire lock: ff6a80eced71e0a8 (&kvm->slots_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x179/0x1e0 [kvm] but task is already holding lock: ffffffffc07abb08 (kvm_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x14a/0x1e0 [kvm] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (kvm_lock){+.+.}-{3:3}: __mutex_lock+0x6a/0xb40 mutex_lock_nested+0x1f/0x30 kvm_dev_ioctl+0x4fb/0xe50 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #2 (cpu_hotplug_lock){++++}-{0:0}: cpus_read_lock+0x2e/0xb0 static_key_slow_inc+0x16/0x30 kvm_lapic_set_base+0x6a/0x1c0 [kvm] kvm_set_apic_base+0x8f/0xe0 [kvm] kvm_set_msr_common+0x9ae/0xf80 [kvm] vmx_set_msr+0xa54/0xbe0 [kvm_intel] __kvm_set_msr+0xb6/0x1a0 [kvm] kvm_arch_vcpu_ioctl+0xeca/0x10c0 [kvm] kvm_vcpu_ioctl+0x485/0x5b0 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (&kvm->srcu){.+.+}-{0:0}: __synchronize_srcu+0x44/0x1a0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47719", "url": "https://ubuntu.com/security/CVE-2024-47719", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommufd: Protect against overflow of ALIGN() during iova allocation Userspace can supply an iova and uptr such that the target iova alignment becomes really big and ALIGN() overflows which corrupts the selected area range during allocation. CONFIG_IOMMUFD_TEST can detect this: WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline] WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352 Modules linked in: CPU: 1 PID: 5092 Comm: syz-executor294 Not tainted 6.10.0-rc5-syzkaller-00294-g3ffea9a7a6f7 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024 RIP: 0010:iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline] RIP: 0010:iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352 Code: fc e9 a4 f3 ff ff e8 1a 8b 4c fc 41 be e4 ff ff ff e9 8a f3 ff ff e8 0a 8b 4c fc 90 0f 0b 90 e9 37 f5 ff ff e8 fc 8a 4c fc 90 <0f> 0b 90 e9 68 f3 ff ff 48 c7 c1 ec 82 ad 8f 80 e1 07 80 c1 03 38 RSP: 0018:ffffc90003ebf9e0 EFLAGS: 00010293 RAX: ffffffff85499fa4 RBX: 00000000ffffffef RCX: ffff888079b49e00 RDX: 0000000000000000 RSI: 00000000ffffffef RDI: 0000000000000000 RBP: ffffc90003ebfc50 R08: ffffffff85499b30 R09: ffffffff85499942 R10: 0000000000000002 R11: ffff888079b49e00 R12: ffff8880228e0010 R13: 0000000000000000 R14: 1ffff920007d7f68 R15: ffffc90003ebfd00 FS: 000055557d760380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000005fdeb8 CR3: 000000007404a000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: iommufd_ioas_copy+0x610/0x7b0 drivers/iommu/iommufd/ioas.c:274 iommufd_fops_ioctl+0x4d9/0x5a0 drivers/iommu/iommufd/main.c:421 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Cap the automatic alignment to the huge page size, which is probably a better idea overall. Huge automatic alignments can fragment and chew up the available IOVA space without any reason.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47745", "url": "https://ubuntu.com/security/CVE-2024-47745", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: call the security_mmap_file() LSM hook in remap_file_pages() The remap_file_pages syscall handler calls do_mmap() directly, which doesn't contain the LSM security check. And if the process has called personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for RW pages, this will actually result in remapping the pages to RWX, bypassing a W^X policy enforced by SELinux. So we should check prot by security_mmap_file LSM hook in the remap_file_pages syscall handler before do_mmap() is called. Otherwise, it potentially permits an attacker to bypass a W^X policy enforced by SELinux. The bypass is similar to CVE-2016-10044, which bypass the same thing via AIO and can be found in [1]. The PoC: $ cat > test.c int main(void) { \tsize_t pagesz = sysconf(_SC_PAGE_SIZE); \tint mfd = syscall(SYS_memfd_create, \"test\", 0); \tconst char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE, \t\tMAP_SHARED, mfd, 0); \tunsigned int old = syscall(SYS_personality, 0xffffffff); \tsyscall(SYS_personality, READ_IMPLIES_EXEC | old); \tsyscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0); \tsyscall(SYS_personality, old); \t// show the RWX page exists even if W^X policy is enforced \tint fd = open(\"/proc/self/maps\", O_RDONLY); \tunsigned char buf2[1024]; \twhile (1) { \t\tint ret = read(fd, buf2, 1024); \t\tif (ret <= 0) break; \t\twrite(1, buf2, ret); \t} \tclose(fd); } $ gcc test.c -o test $ ./test | grep rwx 7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted) [PM: subject line tweaks]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47746", "url": "https://ubuntu.com/security/CVE-2024-47746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: use exclusive lock when FUSE_I_CACHE_IO_MODE is set This may be a typo. The comment has said shared locks are not allowed when this bit is set. If using shared lock, the wait in `fuse_file_cached_io_open` may be forever.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47734", "url": "https://ubuntu.com/security/CVE-2024-47734", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: Fix unnecessary warnings and logs from bond_xdp_get_xmit_slave() syzbot reported a WARNING in bond_xdp_get_xmit_slave. To reproduce this[1], one bond device (bond1) has xdpdrv, which increases bpf_master_redirect_enabled_key. Another bond device (bond0) which is unsupported by XDP but its slave (veth3) has xdpgeneric that returns XDP_TX. This triggers WARN_ON_ONCE() from the xdp_master_redirect(). To reduce unnecessary warnings and improve log management, we need to delete the WARN_ON_ONCE() and add ratelimit to the netdev_err(). [1] Steps to reproduce: # Needs tx_xdp with return XDP_TX; ip l add veth0 type veth peer veth1 ip l add veth3 type veth peer veth4 ip l add bond0 type bond mode 6 # BOND_MODE_ALB, unsupported by XDP ip l add bond1 type bond # BOND_MODE_ROUNDROBIN by default ip l set veth0 master bond1 ip l set bond1 up # Increases bpf_master_redirect_enabled_key ip l set dev bond1 xdpdrv object tx_xdp.o section xdp_tx ip l set veth3 master bond0 ip l set bond0 up ip l set veth4 up # Triggers WARN_ON_ONCE() from the xdp_master_redirect() ip l set veth3 xdpgeneric object tx_xdp.o section xdp_tx", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47684", "url": "https://ubuntu.com/security/CVE-2024-47684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: check skb is non-NULL in tcp_rto_delta_us() We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic kernel that are running ceph and recently hit a null ptr dereference in tcp_rearm_rto(). Initially hitting it from the TLP path, but then later we also saw it getting hit from the RACK case as well. Here are examples of the oops messages we saw in each of those cases: Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020 Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode Jul 26 15:05:02 rx [11061395.792971] #PF: error_code(0x0000) - not-present page Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0 Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI Jul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu Jul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023 Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 <48> 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3 Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246 Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000 Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60 Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8 Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900 Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30 Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000 Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0 Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554 Jul 26 15:05:02 rx [11061395.916786] Call Trace: Jul 26 15:05:02 rx [11061395.919488] Jul 26 15:05:02 rx [11061395.921765] ? show_regs.cold+0x1a/0x1f Jul 26 15:05:02 rx [11061395.925859] ? __die+0x90/0xd9 Jul 26 15:05:02 rx [11061395.929169] ? no_context+0x196/0x380 Jul 26 15:05:02 rx [11061395.933088] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0 Jul 26 15:05:02 rx [11061395.938216] ? ip6_sublist_rcv_finish+0x3d/0x50 Jul 26 15:05:02 rx [11061395.943000] ? __bad_area_nosemaphore+0x50/0x1a0 Jul 26 15:05:02 rx [11061395.947873] ? bad_area_nosemaphore+0x16/0x20 Jul 26 15:05:02 rx [11061395.952486] ? do_user_addr_fault+0x267/0x450 Jul 26 15:05:02 rx [11061395.957104] ? ipv6_list_rcv+0x112/0x140 Jul 26 15:05:02 rx [11061395.961279] ? __do_page_fault+0x58/0x90 Jul 26 15:05:02 rx [11061395.965458] ? do_page_fault+0x2c/0xe0 Jul 26 15:05:02 rx [11061395.969465] ? page_fault+0x34/0x40 Jul 26 15:05:02 rx [11061395.973217] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.977313] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.981408] tcp_send_loss_probe+0x10b/0x220 Jul 26 15:05:02 rx [11061395.985937] tcp_write_timer_handler+0x1b4/0x240 Jul 26 15:05:02 rx [11061395.990809] tcp_write_timer+0x9e/0xe0 Jul 26 15:05:02 rx [11061395.994814] ? tcp_write_timer_handler+0x240/0x240 Jul 26 15:05:02 rx [11061395.999866] call_timer_fn+0x32/0x130 Jul 26 15:05:02 rx [11061396.003782] __run_timers.part.0+0x180/0x280 Jul 26 15:05:02 rx [11061396.008309] ? recalibrate_cpu_khz+0x10/0x10 Jul 26 15:05:02 rx [11061396.012841] ? native_x2apic_icr_write+0x30/0x30 Jul 26 15:05:02 rx [11061396.017718] ? lapic_next_even ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47747", "url": "https://ubuntu.com/security/CVE-2024-47747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race Condition In the ether3_probe function, a timer is initialized with a callback function ether3_ledoff, bound to &prev(dev)->timer. Once the timer is started, there is a risk of a race condition if the module or device is removed, triggering the ether3_remove function to perform cleanup. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | ether3_ledoff ether3_remove | free_netdev(dev); | put_devic | kfree(dev); | | ether3_outw(priv(dev)->regs.config2 |= CFG2_CTRLO, REG_CONFIG2); | // use dev Fix it by ensuring that the timer is canceled before proceeding with the cleanup in ether3_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47685", "url": "https://ubuntu.com/security/CVE-2024-47685", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put() syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending garbage on the four reserved tcp bits (th->res1) Use skb_put_zero() to clear the whole TCP header, as done in nf_reject_ip_tcphdr_put() BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5661 [inline] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775 process_backlog+0x4ad/0xa50 net/core/dev.c:6108 __napi_poll+0xe7/0x980 net/core/dev.c:6772 napi_poll net/core/dev.c:6841 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963 handle_softirqs+0x1ce/0x800 kernel/softirq.c:554 __do_softirq+0x14/0x1a kernel/softirq.c:588 do_softirq+0x9a/0x100 kernel/softirq.c:455 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline] __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450 dev_queue_xmit include/linux/netdevice.h:3105 [inline] neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366 inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135 __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143 tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333 __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679 inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750 __sys_connect_file net/socket.c:2061 [inline] __sys_connect+0x606/0x690 net/socket.c:2078 __do_sys_connect net/socket.c:2088 [inline] __se_sys_connect net/socket.c:2085 [inline] __x64_sys_connect+0x91/0xe0 net/socket.c:2085 x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43 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 Uninit was stored to memory at: nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47686", "url": "https://ubuntu.com/security/CVE-2024-47686", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ep93xx: clock: Fix off by one in ep93xx_div_recalc_rate() The psc->div[] array has psc->num_div elements. These values come from when we call clk_hw_register_div(). It's adc_divisors and ARRAY_SIZE(adc_divisors)) and so on. So this condition needs to be >= instead of > to prevent an out of bounds read.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47748", "url": "https://ubuntu.com/security/CVE-2024-47748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost_vdpa: assign irq bypass producer token correctly We used to call irq_bypass_unregister_producer() in vhost_vdpa_setup_vq_irq() which is problematic as we don't know if the token pointer is still valid or not. Actually, we use the eventfd_ctx as the token so the life cycle of the token should be bound to the VHOST_SET_VRING_CALL instead of vhost_vdpa_setup_vq_irq() which could be called by set_status(). Fixing this by setting up irq bypass producer's token when handling VHOST_SET_VRING_CALL and un-registering the producer before calling vhost_vring_ioctl() to prevent a possible use after free as eventfd could have been released in vhost_vring_ioctl(). And such registering and unregistering will only be done if DRIVER_OK is set.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47687", "url": "https://ubuntu.com/security/CVE-2024-47687", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa/mlx5: Fix invalid mr resource destroy Certain error paths from mlx5_vdpa_dev_add() can end up releasing mr resources which never got initialized in the first place. This patch adds the missing check in mlx5_vdpa_destroy_mr_resources() to block releasing non-initialized mr resources. Reference trace: mlx5_core 0000:08:00.2: mlx5_vdpa_dev_add:3274:(pid 2700) warning: No mac address provisioned? BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 140216067 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 8 PID: 2700 Comm: vdpa Kdump: loaded Not tainted 5.14.0-496.el9.x86_64 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:vhost_iotlb_del_range+0xf/0xe0 [vhost_iotlb] Code: [...] RSP: 0018:ff1c823ac23077f0 EFLAGS: 00010246 RAX: ffffffffc1a21a60 RBX: ffffffff899567a0 RCX: 0000000000000000 RDX: ffffffffffffffff RSI: 0000000000000000 RDI: 0000000000000000 RBP: ff1bda1f7c21e800 R08: 0000000000000000 R09: ff1c823ac2307670 R10: ff1c823ac2307668 R11: ffffffff8a9e7b68 R12: 0000000000000000 R13: 0000000000000000 R14: ff1bda1f43e341a0 R15: 00000000ffffffea FS: 00007f56eba7c740(0000) GS:ff1bda269f800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000104d90001 CR4: 0000000000771ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? mlx5_vdpa_free+0x3d/0x150 [mlx5_vdpa] ? __die_body.cold+0x8/0xd ? page_fault_oops+0x134/0x170 ? __irq_work_queue_local+0x2b/0xc0 ? irq_work_queue+0x2c/0x50 ? exc_page_fault+0x62/0x150 ? asm_exc_page_fault+0x22/0x30 ? __pfx_mlx5_vdpa_free+0x10/0x10 [mlx5_vdpa] ? vhost_iotlb_del_range+0xf/0xe0 [vhost_iotlb] mlx5_vdpa_free+0x3d/0x150 [mlx5_vdpa] vdpa_release_dev+0x1e/0x50 [vdpa] device_release+0x31/0x90 kobject_cleanup+0x37/0x130 mlx5_vdpa_dev_add+0x2d2/0x7a0 [mlx5_vdpa] vdpa_nl_cmd_dev_add_set_doit+0x277/0x4c0 [vdpa] genl_family_rcv_msg_doit+0xd9/0x130 genl_family_rcv_msg+0x14d/0x220 ? __pfx_vdpa_nl_cmd_dev_add_set_doit+0x10/0x10 [vdpa] ? _copy_to_user+0x1a/0x30 ? move_addr_to_user+0x4b/0xe0 genl_rcv_msg+0x47/0xa0 ? __import_iovec+0x46/0x150 ? __pfx_genl_rcv_msg+0x10/0x10 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x245/0x370 netlink_sendmsg+0x206/0x440 __sys_sendto+0x1dc/0x1f0 ? do_read_fault+0x10c/0x1d0 ? do_pte_missing+0x10d/0x190 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x5c/0xf0 ? __count_memcg_events+0x4f/0xb0 ? mm_account_fault+0x6c/0x100 ? handle_mm_fault+0x116/0x270 ? do_user_addr_fault+0x1d6/0x6a0 ? do_syscall_64+0x6b/0xf0 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 entry_SYSCALL_64_after_hwframe+0x78/0x80", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47688", "url": "https://ubuntu.com/security/CVE-2024-47688", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: driver core: Fix a potential null-ptr-deref in module_add_driver() Inject fault while probing of-fpga-region, if kasprintf() fails in module_add_driver(), the second sysfs_remove_link() in exit path will cause null-ptr-deref as below because kernfs_name_hash() will call strlen() with NULL driver_name. Fix it by releasing resources based on the exit path sequence. \t KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] \t Mem abort info: \t ESR = 0x0000000096000005 \t EC = 0x25: DABT (current EL), IL = 32 bits \t SET = 0, FnV = 0 \t EA = 0, S1PTW = 0 \t FSC = 0x05: level 1 translation fault \t Data abort info: \t ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 \t CM = 0, WnR = 0, TnD = 0, TagAccess = 0 \t GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 \t [dfffffc000000000] address between user and kernel address ranges \t Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP \t Dumping ftrace buffer: \t (ftrace buffer empty) \t Modules linked in: of_fpga_region(+) fpga_region fpga_bridge cfg80211 rfkill 8021q garp mrp stp llc ipv6 [last unloaded: of_fpga_region] \t CPU: 2 UID: 0 PID: 2036 Comm: modprobe Not tainted 6.11.0-rc2-g6a0e38264012 #295 \t Hardware name: linux,dummy-virt (DT) \t pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) \t pc : strlen+0x24/0xb0 \t lr : kernfs_name_hash+0x1c/0xc4 \t sp : ffffffc081f97380 \t x29: ffffffc081f97380 x28: ffffffc081f97b90 x27: ffffff80c821c2a0 \t x26: ffffffedac0be418 x25: 0000000000000000 x24: ffffff80c09d2000 \t x23: 0000000000000000 x22: 0000000000000000 x21: 0000000000000000 \t x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000001840 \t x17: 0000000000000000 x16: 0000000000000000 x15: 1ffffff8103f2e42 \t x14: 00000000f1f1f1f1 x13: 0000000000000004 x12: ffffffb01812d61d \t x11: 1ffffff01812d61c x10: ffffffb01812d61c x9 : dfffffc000000000 \t x8 : 0000004fe7ed29e4 x7 : ffffff80c096b0e7 x6 : 0000000000000001 \t x5 : ffffff80c096b0e0 x4 : 1ffffffdb990efa2 x3 : 0000000000000000 \t x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000000 \t Call trace: \t strlen+0x24/0xb0 \t kernfs_name_hash+0x1c/0xc4 \t kernfs_find_ns+0x118/0x2e8 \t kernfs_remove_by_name_ns+0x80/0x100 \t sysfs_remove_link+0x74/0xa8 \t module_add_driver+0x278/0x394 \t bus_add_driver+0x1f0/0x43c \t driver_register+0xf4/0x3c0 \t __platform_driver_register+0x60/0x88 \t of_fpga_region_init+0x20/0x1000 [of_fpga_region] \t do_one_initcall+0x110/0x788 \t do_init_module+0x1dc/0x5c8 \t load_module+0x3c38/0x4cac \t init_module_from_file+0xd4/0x128 \t idempotent_init_module+0x2cc/0x528 \t __arm64_sys_finit_module+0xac/0x100 \t invoke_syscall+0x6c/0x258 \t el0_svc_common.constprop.0+0x160/0x22c \t do_el0_svc+0x44/0x5c \t el0_svc+0x48/0xb8 \t el0t_64_sync_handler+0x13c/0x158 \t el0t_64_sync+0x190/0x194 \t Code: f2fbffe1 a90157f4 12000802 aa0003f5 (38e16861) \t ---[ end trace 0000000000000000 ]--- \t Kernel panic - not syncing: Oops: Fatal exception", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47689", "url": "https://ubuntu.com/security/CVE-2024-47689", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to don't set SB_RDONLY in f2fs_handle_critical_error() syzbot reports a f2fs bug as below: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 58 at kernel/rcu/sync.c:177 rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177 CPU: 1 UID: 0 PID: 58 Comm: kworker/1:2 Not tainted 6.10.0-syzkaller-12562-g1722389b0d86 #0 Workqueue: events destroy_super_work RIP: 0010:rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177 Call Trace: percpu_free_rwsem+0x41/0x80 kernel/locking/percpu-rwsem.c:42 destroy_super_work+0xec/0x130 fs/super.c:282 process_one_work kernel/workqueue.c:3231 [inline] process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 worker_thread+0x86d/0xd40 kernel/workqueue.c:3390 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 As Christian Brauner pointed out [1]: the root cause is f2fs sets SB_RDONLY flag in internal function, rather than setting the flag covered w/ sb->s_umount semaphore via remount procedure, then below race condition causes this bug: - freeze_super() - sb_wait_write(sb, SB_FREEZE_WRITE) - sb_wait_write(sb, SB_FREEZE_PAGEFAULT) - sb_wait_write(sb, SB_FREEZE_FS) \t\t\t\t\t- f2fs_handle_critical_error \t\t\t\t\t - sb->s_flags |= SB_RDONLY - thaw_super - thaw_super_locked - sb_rdonly() is true, so it skips sb_freeze_unlock(sb, SB_FREEZE_FS) - deactivate_locked_super Since f2fs has almost the same logic as ext4 [2] when handling critical error in filesystem if it mounts w/ errors=remount-ro option: - set CP_ERROR_FLAG flag which indicates filesystem is stopped - record errors to superblock - set SB_RDONLY falg Once we set CP_ERROR_FLAG flag, all writable interfaces can detect the flag and stop any further updates on filesystem. So, it is safe to not set SB_RDONLY flag, let's remove the logic and keep in line w/ ext4 [3]. [1] https://lore.kernel.org/all/20240729-himbeeren-funknetz-96e62f9c7aee@brauner [2] https://lore.kernel.org/all/20240729132721.hxih6ehigadqf7wx@quack3 [3] https://lore.kernel.org/linux-ext4/20240805201241.27286-1-jack@suse.cz", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47690", "url": "https://ubuntu.com/security/CVE-2024-47690", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: get rid of online repaire on corrupted directory syzbot reports a f2fs bug as below: kernel BUG at fs/f2fs/inode.c:896! RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Call Trace: evict+0x532/0x950 fs/inode.c:704 dispose_list fs/inode.c:747 [inline] evict_inodes+0x5f9/0x690 fs/inode.c:797 generic_shutdown_super+0x9d/0x2d0 fs/super.c:627 kill_block_super+0x44/0x90 fs/super.c:1696 kill_f2fs_super+0x344/0x690 fs/f2fs/super.c:4898 deactivate_locked_super+0xc4/0x130 fs/super.c:473 cleanup_mnt+0x41f/0x4b0 fs/namespace.c:1373 task_work_run+0x24f/0x310 kernel/task_work.c:228 ptrace_notify+0x2d2/0x380 kernel/signal.c:2402 ptrace_report_syscall include/linux/ptrace.h:415 [inline] ptrace_report_syscall_exit include/linux/ptrace.h:477 [inline] syscall_exit_work+0xc6/0x190 kernel/entry/common.c:173 syscall_exit_to_user_mode_prepare kernel/entry/common.c:200 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:205 [inline] syscall_exit_to_user_mode+0x279/0x370 kernel/entry/common.c:218 do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Online repaire on corrupted directory in f2fs_lookup() can generate dirty data/meta while racing w/ readonly remount, it may leave dirty inode after filesystem becomes readonly, however, checkpoint() will skips flushing dirty inode in a state of readonly mode, result in above panic. Let's get rid of online repaire in f2fs_lookup(), and leave the work to fsck.f2fs.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47691", "url": "https://ubuntu.com/security/CVE-2024-47691", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread() syzbot reports a f2fs bug as below: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_report+0xe8/0x550 mm/kasan/report.c:491 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 instrument_atomic_read_write include/linux/instrumented.h:96 [inline] atomic_fetch_add_relaxed include/linux/atomic/atomic-instrumented.h:252 [inline] __refcount_add include/linux/refcount.h:184 [inline] __refcount_inc include/linux/refcount.h:241 [inline] refcount_inc include/linux/refcount.h:258 [inline] get_task_struct include/linux/sched/task.h:118 [inline] kthread_stop+0xca/0x630 kernel/kthread.c:704 f2fs_stop_gc_thread+0x65/0xb0 fs/f2fs/gc.c:210 f2fs_do_shutdown+0x192/0x540 fs/f2fs/file.c:2283 f2fs_ioc_shutdown fs/f2fs/file.c:2325 [inline] __f2fs_ioctl+0x443a/0xbe60 fs/f2fs/file.c:4325 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f The root cause is below race condition, it may cause use-after-free issue in sbi->gc_th pointer. - remount - f2fs_remount - f2fs_stop_gc_thread - kfree(gc_th) \t\t\t\t- f2fs_ioc_shutdown \t\t\t\t - f2fs_do_shutdown \t\t\t\t - f2fs_stop_gc_thread \t\t\t\t - kthread_stop(gc_th->f2fs_gc_task) : sbi->gc_thread = NULL; We will call f2fs_do_shutdown() in two paths: - for f2fs_ioc_shutdown() path, we should grab sb->s_umount semaphore for fixing. - for f2fs_shutdown() path, it's safe since caller has already grabbed sb->s_umount semaphore.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47692", "url": "https://ubuntu.com/security/CVE-2024-47692", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: return -EINVAL when namelen is 0 When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may result in namelen being 0, which will cause memdup_user() to return ZERO_SIZE_PTR. When we access the name.data that has been assigned the value of ZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is triggered. [ T1205] ================================================================== [ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260 [ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205 [ T1205] [ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406 [ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ T1205] Call Trace: [ T1205] dump_stack+0x9a/0xd0 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] __kasan_report.cold+0x34/0x84 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] kasan_report+0x3a/0x50 [ T1205] nfs4_client_to_reclaim+0xe9/0x260 [ T1205] ? nfsd4_release_lockowner+0x410/0x410 [ T1205] cld_pipe_downcall+0x5ca/0x760 [ T1205] ? nfsd4_cld_tracking_exit+0x1d0/0x1d0 [ T1205] ? down_write_killable_nested+0x170/0x170 [ T1205] ? avc_policy_seqno+0x28/0x40 [ T1205] ? selinux_file_permission+0x1b4/0x1e0 [ T1205] rpc_pipe_write+0x84/0xb0 [ T1205] vfs_write+0x143/0x520 [ T1205] ksys_write+0xc9/0x170 [ T1205] ? __ia32_sys_read+0x50/0x50 [ T1205] ? ktime_get_coarse_real_ts64+0xfe/0x110 [ T1205] ? ktime_get_coarse_real_ts64+0xa2/0x110 [ T1205] do_syscall_64+0x33/0x40 [ T1205] entry_SYSCALL_64_after_hwframe+0x67/0xd1 [ T1205] RIP: 0033:0x7fdbdb761bc7 [ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 514 [ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7 [ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008 [ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001 [ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b [ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000 [ T1205] ================================================================== Fix it by checking namelen.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47737", "url": "https://ubuntu.com/security/CVE-2024-47737", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: call cache_put if xdr_reserve_space returns NULL If not enough buffer space available, but idmap_lookup has triggered lookup_fn which calls cache_get and returns successfully. Then we missed to call cache_put here which pairs with cache_get. Reviwed-by: Jeff Layton ", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2023-52917", "url": "https://ubuntu.com/security/CVE-2023-52917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir() The debugfs_create_dir() function returns error pointers. It never returns NULL. So use IS_ERR() to check it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47749", "url": "https://ubuntu.com/security/CVE-2024-47749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Added NULL check for lookup_atid The lookup_atid() function can return NULL if the ATID is invalid or does not exist in the identifier table, which could lead to dereferencing a null pointer without a check in the `act_establish()` and `act_open_rpl()` functions. Add a NULL check to prevent null pointer dereferencing. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47735", "url": "https://ubuntu.com/security/CVE-2024-47735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled Fix missuse of spin_lock_irq()/spin_unlock_irq() when spin_lock_irqsave()/spin_lock_irqrestore() was hold. This was discovered through the lock debugging, and the corresponding log is as follows: raw_local_irq_restore() called with IRQs enabled WARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40 ... Call trace: warn_bogus_irq_restore+0x30/0x40 _raw_spin_unlock_irqrestore+0x84/0xc8 add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2] hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2] hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2] create_qp+0x138/0x258 ib_create_qp_kernel+0x50/0xe8 create_mad_qp+0xa8/0x128 ib_mad_port_open+0x218/0x448 ib_mad_init_device+0x70/0x1f8 add_client_context+0xfc/0x220 enable_device_and_get+0xd0/0x140 ib_register_device.part.0+0xf4/0x1c8 ib_register_device+0x34/0x50 hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2] hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2] __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2] hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47750", "url": "https://ubuntu.com/security/CVE-2024-47750", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix Use-After-Free of rsv_qp on HIP08 Currently rsv_qp is freed before ib_unregister_device() is called on HIP08. During the time interval, users can still dereg MR and rsv_qp will be used in this process, leading to a UAF. Move the release of rsv_qp after calling ib_unregister_device() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47751", "url": "https://ubuntu.com/security/CVE-2024-47751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: kirin: Fix buffer overflow in kirin_pcie_parse_port() Within kirin_pcie_parse_port(), the pcie->num_slots is compared to pcie->gpio_id_reset size (MAX_PCI_SLOTS) which is correct and would lead to an overflow. Thus, fix condition to pcie->num_slots + 1 >= MAX_PCI_SLOTS and move pcie->num_slots increment below the if-statement to avoid out-of-bounds array access. Found by Linux Verification Center (linuxtesting.org) with SVACE. [kwilczynski: commit log]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47693", "url": "https://ubuntu.com/security/CVE-2024-47693", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/core: Fix ib_cache_setup_one error flow cleanup When ib_cache_update return an error, we exit ib_cache_setup_one instantly with no proper cleanup, even though before this we had already successfully done gid_table_setup_one, that results in the kernel WARN below. Do proper cleanup using gid_table_cleanup_one before returning the err in order to fix the issue. WARNING: CPU: 4 PID: 922 at drivers/infiniband/core/cache.c:806 gid_table_release_one+0x181/0x1a0 Modules linked in: CPU: 4 UID: 0 PID: 922 Comm: c_repro Not tainted 6.11.0-rc1+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:gid_table_release_one+0x181/0x1a0 Code: 44 8b 38 75 0c e8 2f cb 34 ff 4d 8b b5 28 05 00 00 e8 23 cb 34 ff 44 89 f9 89 da 4c 89 f6 48 c7 c7 d0 58 14 83 e8 4f de 21 ff <0f> 0b 4c 8b 75 30 e9 54 ff ff ff 48 8 3 c4 10 5b 5d 41 5c 41 5d 41 RSP: 0018:ffffc90002b835b0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c8527 RDX: 0000000000000000 RSI: ffffffff811c8534 RDI: 0000000000000001 RBP: ffff8881011b3d00 R08: ffff88810b3abe00 R09: 205d303839303631 R10: 666572207972746e R11: 72746e6520444947 R12: 0000000000000001 R13: ffff888106390000 R14: ffff8881011f2110 R15: 0000000000000001 FS: 00007fecc3b70800(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000340 CR3: 000000010435a001 CR4: 00000000003706b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? show_regs+0x94/0xa0 ? __warn+0x9e/0x1c0 ? gid_table_release_one+0x181/0x1a0 ? report_bug+0x1f9/0x340 ? gid_table_release_one+0x181/0x1a0 ? handle_bug+0xa2/0x110 ? exc_invalid_op+0x31/0xa0 ? asm_exc_invalid_op+0x16/0x20 ? __warn_printk+0xc7/0x180 ? __warn_printk+0xd4/0x180 ? gid_table_release_one+0x181/0x1a0 ib_device_release+0x71/0xe0 ? __pfx_ib_device_release+0x10/0x10 device_release+0x44/0xd0 kobject_put+0x135/0x3d0 put_device+0x20/0x30 rxe_net_add+0x7d/0xa0 rxe_newlink+0xd7/0x190 nldev_newlink+0x1b0/0x2a0 ? __pfx_nldev_newlink+0x10/0x10 rdma_nl_rcv_msg+0x1ad/0x2e0 rdma_nl_rcv_skb.constprop.0+0x176/0x210 netlink_unicast+0x2de/0x400 netlink_sendmsg+0x306/0x660 __sock_sendmsg+0x110/0x120 ____sys_sendmsg+0x30e/0x390 ___sys_sendmsg+0x9b/0xf0 ? kstrtouint+0x6e/0xa0 ? kstrtouint_from_user+0x7c/0xb0 ? get_pid_task+0xb0/0xd0 ? proc_fail_nth_write+0x5b/0x140 ? __fget_light+0x9a/0x200 ? preempt_count_add+0x47/0xa0 __sys_sendmsg+0x61/0xd0 do_syscall_64+0x50/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47694", "url": "https://ubuntu.com/security/CVE-2024-47694", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mlx5: Fix UMR pd cleanup on error flow of driver init The cited commit moves the pd allocation from function mlx5r_umr_resource_cleanup() to a new function mlx5r_umr_cleanup(). So the fix in commit [1] is broken. In error flow, will hit panic [2]. Fix it by checking pd pointer to avoid panic if it is NULL; [1] RDMA/mlx5: Fix UMR cleanup on error flow of driver init [2] [ 347.567063] infiniband mlx5_0: Couldn't register device with driver model [ 347.591382] BUG: kernel NULL pointer dereference, address: 0000000000000020 [ 347.593438] #PF: supervisor read access in kernel mode [ 347.595176] #PF: error_code(0x0000) - not-present page [ 347.596962] PGD 0 P4D 0 [ 347.601361] RIP: 0010:ib_dealloc_pd_user+0x12/0xc0 [ib_core] [ 347.604171] RSP: 0018:ffff888106293b10 EFLAGS: 00010282 [ 347.604834] RAX: 0000000000000000 RBX: 000000000000000e RCX: 0000000000000000 [ 347.605672] RDX: ffff888106293ad0 RSI: 0000000000000000 RDI: 0000000000000000 [ 347.606529] RBP: 0000000000000000 R08: ffff888106293ae0 R09: ffff888106293ae0 [ 347.607379] R10: 0000000000000a06 R11: 0000000000000000 R12: 0000000000000000 [ 347.608224] R13: ffffffffa0704dc0 R14: 0000000000000001 R15: 0000000000000001 [ 347.609067] FS: 00007fdc720cd9c0(0000) GS:ffff88852c880000(0000) knlGS:0000000000000000 [ 347.610094] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 347.610727] CR2: 0000000000000020 CR3: 0000000103012003 CR4: 0000000000370eb0 [ 347.611421] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 347.612113] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 347.612804] Call Trace: [ 347.613130] [ 347.613417] ? __die+0x20/0x60 [ 347.613793] ? page_fault_oops+0x150/0x3e0 [ 347.614243] ? free_msg+0x68/0x80 [mlx5_core] [ 347.614840] ? cmd_exec+0x48f/0x11d0 [mlx5_core] [ 347.615359] ? exc_page_fault+0x74/0x130 [ 347.615808] ? asm_exc_page_fault+0x22/0x30 [ 347.616273] ? ib_dealloc_pd_user+0x12/0xc0 [ib_core] [ 347.616801] mlx5r_umr_cleanup+0x23/0x90 [mlx5_ib] [ 347.617365] mlx5_ib_stage_pre_ib_reg_umr_cleanup+0x36/0x40 [mlx5_ib] [ 347.618025] __mlx5_ib_add+0x96/0xd0 [mlx5_ib] [ 347.618539] mlx5r_probe+0xe9/0x310 [mlx5_ib] [ 347.619032] ? kernfs_add_one+0x107/0x150 [ 347.619478] ? __mlx5_ib_add+0xd0/0xd0 [mlx5_ib] [ 347.619984] auxiliary_bus_probe+0x3e/0x90 [ 347.620448] really_probe+0xc5/0x3a0 [ 347.620857] __driver_probe_device+0x80/0x160 [ 347.621325] driver_probe_device+0x1e/0x90 [ 347.621770] __driver_attach+0xec/0x1c0 [ 347.622213] ? __device_attach_driver+0x100/0x100 [ 347.622724] bus_for_each_dev+0x71/0xc0 [ 347.623151] bus_add_driver+0xed/0x240 [ 347.623570] driver_register+0x58/0x100 [ 347.623998] __auxiliary_driver_register+0x6a/0xc0 [ 347.624499] ? driver_register+0xae/0x100 [ 347.624940] ? 0xffffffffa0893000 [ 347.625329] mlx5_ib_init+0x16a/0x1e0 [mlx5_ib] [ 347.625845] do_one_initcall+0x4a/0x2a0 [ 347.626273] ? gcov_event+0x2e2/0x3a0 [ 347.626706] do_init_module+0x8a/0x260 [ 347.627126] init_module_from_file+0x8b/0xd0 [ 347.627596] __x64_sys_finit_module+0x1ca/0x2f0 [ 347.628089] do_syscall_64+0x4c/0x100", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47695", "url": "https://ubuntu.com/security/CVE-2024-47695", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds In the function init_conns(), after the create_con() and create_cm() for loop if something fails. In the cleanup for loop after the destroy tag, we access out of bound memory because cid is set to clt_path->s.con_num. This commits resets the cid to clt_path->s.con_num - 1, to stay in bounds in the cleanup loop later.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47752", "url": "https://ubuntu.com/security/CVE-2024-47752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix H264 stateless decoder smatch warning Fix a smatch static checker warning on vdec_h264_req_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47753", "url": "https://ubuntu.com/security/CVE-2024-47753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix VP8 stateless decoder smatch warning Fix a smatch static checker warning on vdec_vp8_req_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47754", "url": "https://ubuntu.com/security/CVE-2024-47754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix H264 multi stateless decoder smatch warning Fix a smatch static checker warning on vdec_h264_req_multi_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47696", "url": "https://ubuntu.com/security/CVE-2024-47696", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency In the commit aee2424246f9 (\"RDMA/iwcm: Fix a use-after-free related to destroying CM IDs\"), the function flush_workqueue is invoked to flush the work queue iwcm_wq. But at that time, the work queue iwcm_wq was created via the function alloc_ordered_workqueue without the flag WQ_MEM_RECLAIM. Because the current process is trying to flush the whole iwcm_wq, if iwcm_wq doesn't have the flag WQ_MEM_RECLAIM, verify that the current process is not reclaiming memory or running on a workqueue which doesn't have the flag WQ_MEM_RECLAIM as that can break forward-progress guarantee leading to a deadlock. The call trace is as below: [ 125.350876][ T1430] Call Trace: [ 125.356281][ T1430] [ 125.361285][ T1430] ? __warn (kernel/panic.c:693) [ 125.367640][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.375689][ T1430] ? report_bug (lib/bug.c:180 lib/bug.c:219) [ 125.382505][ T1430] ? handle_bug (arch/x86/kernel/traps.c:239) [ 125.388987][ T1430] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) [ 125.395831][ T1430] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621) [ 125.403125][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.410984][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.418764][ T1430] __flush_workqueue (kernel/workqueue.c:3970) [ 125.426021][ T1430] ? __pfx___might_resched (kernel/sched/core.c:10151) [ 125.433431][ T1430] ? destroy_cm_id (drivers/infiniband/core/iwcm.c:375) iw_cm [ 125.441209][ T1430] ? __pfx___flush_workqueue (kernel/workqueue.c:3910) [ 125.473900][ T1430] ? _raw_spin_lock_irqsave (arch/x86/include/asm/atomic.h:107 include/linux/atomic/atomic-arch-fallback.h:2170 include/linux/atomic/atomic-instrumented.h:1302 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162) [ 125.473909][ T1430] ? __pfx__raw_spin_lock_irqsave (kernel/locking/spinlock.c:161) [ 125.482537][ T1430] _destroy_id (drivers/infiniband/core/cma.c:2044) rdma_cm [ 125.495072][ T1430] nvme_rdma_free_queue (drivers/nvme/host/rdma.c:656 drivers/nvme/host/rdma.c:650) nvme_rdma [ 125.505827][ T1430] nvme_rdma_reset_ctrl_work (drivers/nvme/host/rdma.c:2180) nvme_rdma [ 125.505831][ T1430] process_one_work (kernel/workqueue.c:3231) [ 125.515122][ T1430] worker_thread (kernel/workqueue.c:3306 kernel/workqueue.c:3393) [ 125.515127][ T1430] ? __pfx_worker_thread (kernel/workqueue.c:3339) [ 125.531837][ T1430] kthread (kernel/kthread.c:389) [ 125.539864][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.550628][ T1430] ret_from_fork (arch/x86/kernel/process.c:147) [ 125.558840][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.558844][ T1430] ret_from_fork_asm (arch/x86/entry/entry_64.S:257) [ 125.566487][ T1430] [ 125.566488][ T1430] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47755", "url": "https://ubuntu.com/security/CVE-2024-47755", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47756", "url": "https://ubuntu.com/security/CVE-2024-47756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: keystone: Fix if-statement expression in ks_pcie_quirk() This code accidentally uses && where || was intended. It potentially results in a NULL dereference. Thus, fix the if-statement expression to use the correct condition. [kwilczynski: commit log]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47697", "url": "https://ubuntu.com/security/CVE-2024-47697", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error Ensure index in rtl2830_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47698", "url": "https://ubuntu.com/security/CVE-2024-47698", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error Ensure index in rtl2832_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue. [hverkuil: added fixes tag, rtl2830_pid_filter -> rtl2832_pid_filter in logmsg]", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47728", "url": "https://ubuntu.com/security/CVE-2024-47728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error For all non-tracing helpers which formerly had ARG_PTR_TO_{LONG,INT} as input arguments, zero the value for the case of an error as otherwise it could leak memory. For tracing, it is not needed given CAP_PERFMON can already read all kernel memory anyway hence bpf_get_func_arg() and bpf_get_func_ret() is skipped in here. Also, the MTU helpers mtu_len pointer value is being written but also read. Technically, the MEM_UNINIT should not be there in order to always force init. Removing MEM_UNINIT needs more verifier rework though: MEM_UNINIT right now implies two things actually: i) write into memory, ii) memory does not have to be initialized. If we lift MEM_UNINIT, it then becomes: i) read into memory, ii) memory must be initialized. This means that for bpf_*_check_mtu() we're readding the issue we're trying to fix, that is, it would then be able to write back into things like .rodata BPF maps. Follow-up work will rework the MEM_UNINIT semantics such that the intent can be better expressed. For now just clear the *mtu_len on error path which can be lifted later again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49861", "url": "https://ubuntu.com/security/CVE-2024-49861", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix helper writes to read-only maps Lonial found an issue that despite user- and BPF-side frozen BPF map (like in case of .rodata), it was still possible to write into it from a BPF program side through specific helpers having ARG_PTR_TO_{LONG,INT} as arguments. In check_func_arg() when the argument is as mentioned, the meta->raw_mode is never set. Later, check_helper_mem_access(), under the case of PTR_TO_MAP_VALUE as register base type, it assumes BPF_READ for the subsequent call to check_map_access_type() and given the BPF map is read-only it succeeds. The helpers really need to be annotated as ARG_PTR_TO_{LONG,INT} | MEM_UNINIT when results are written into them as opposed to read out of them. The latter indicates that it's okay to pass a pointer to uninitialized memory as the memory is written to anyway. However, ARG_PTR_TO_{LONG,INT} is a special case of ARG_PTR_TO_FIXED_SIZE_MEM just with additional alignment requirement. So it is better to just get rid of the ARG_PTR_TO_{LONG,INT} special cases altogether and reuse the fixed size memory types. For this, add MEM_ALIGNED to additionally ensure alignment given these helpers write directly into the args via * = val. The .arg*_size has been initialized reflecting the actual sizeof(*). MEM_ALIGNED can only be used in combination with MEM_FIXED_SIZE annotated argument types, since in !MEM_FIXED_SIZE cases the verifier does not know the buffer size a priori and therefore cannot blindly write * = val.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47757", "url": "https://ubuntu.com/security/CVE-2024-47757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential oob read in nilfs_btree_check_delete() The function nilfs_btree_check_delete(), which checks whether degeneration to direct mapping occurs before deleting a b-tree entry, causes memory access outside the block buffer when retrieving the maximum key if the root node has no entries. This does not usually happen because b-tree mappings with 0 child nodes are never created by mkfs.nilfs2 or nilfs2 itself. However, it can happen if the b-tree root node read from a device is configured that way, so fix this potential issue by adding a check for that case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47699", "url": "https://ubuntu.com/security/CVE-2024-47699", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential null-ptr-deref in nilfs_btree_insert() Patch series \"nilfs2: fix potential issues with empty b-tree nodes\". This series addresses three potential issues with empty b-tree nodes that can occur with corrupted filesystem images, including one recently discovered by syzbot. This patch (of 3): If a b-tree is broken on the device, and the b-tree height is greater than 2 (the level of the root node is greater than 1) even if the number of child nodes of the b-tree root is 0, a NULL pointer dereference occurs in nilfs_btree_prepare_insert(), which is called from nilfs_btree_insert(). This is because, when the number of child nodes of the b-tree root is 0, nilfs_btree_do_lookup() does not set the block buffer head in any of path[x].bp_bh, leaving it as the initial value of NULL, but if the level of the b-tree root node is greater than 1, nilfs_btree_get_nonroot_node(), which accesses the buffer memory of path[x].bp_bh, is called. Fix this issue by adding a check to nilfs_btree_root_broken(), which performs sanity checks when reading the root node from the device, to detect this inconsistency. Thanks to Lizhi Xu for trying to solve the bug and clarifying the cause early on.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47700", "url": "https://ubuntu.com/security/CVE-2024-47700", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: check stripe size compatibility on remount as well We disable stripe size in __ext4_fill_super if it is not a multiple of the cluster ratio however this check is missed when trying to remount. This can leave us with cases where stripe < cluster_ratio after remount:set making EXT4_B2C(sbi->s_stripe) become 0 that can cause some unforeseen bugs like divide by 0. Fix that by adding the check in remount path as well.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47701", "url": "https://ubuntu.com/security/CVE-2024-47701", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid OOB when system.data xattr changes underneath the filesystem When looking up for an entry in an inlined directory, if e_value_offs is changed underneath the filesystem by some change in the block device, it will lead to an out-of-bounds access that KASAN detects as an UAF. EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none. loop0: detected capacity change from 2048 to 2047 ================================================================== BUG: KASAN: use-after-free in ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 Read of size 1 at addr ffff88803e91130f by task syz-executor269/5103 CPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 Not tainted 6.11.0-rc4-syzkaller #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:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 ext4_find_inline_entry+0x4be/0x5e0 fs/ext4/inline.c:1697 __ext4_find_entry+0x2b4/0x1b30 fs/ext4/namei.c:1573 ext4_lookup_entry fs/ext4/namei.c:1727 [inline] ext4_lookup+0x15f/0x750 fs/ext4/namei.c:1795 lookup_one_qstr_excl+0x11f/0x260 fs/namei.c:1633 filename_create+0x297/0x540 fs/namei.c:3980 do_symlinkat+0xf9/0x3a0 fs/namei.c:4587 __do_sys_symlinkat fs/namei.c:4610 [inline] __se_sys_symlinkat fs/namei.c:4607 [inline] __x64_sys_symlinkat+0x95/0xb0 fs/namei.c:4607 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:0x7f3e73ced469 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff4d40c258 EFLAGS: 00000246 ORIG_RAX: 000000000000010a RAX: ffffffffffffffda RBX: 0032656c69662f2e RCX: 00007f3e73ced469 RDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0 RBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290 R10: 0023706f6f6c2f76 R11: 0000000000000246 R12: 00007fff4d40c27c R13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0 Calling ext4_xattr_ibody_find right after reading the inode with ext4_get_inode_loc will lead to a check of the validity of the xattrs, avoiding this problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49850", "url": "https://ubuntu.com/security/CVE-2024-49850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: correctly handle malformed BPF_CORE_TYPE_ID_LOCAL relos In case of malformed relocation record of kind BPF_CORE_TYPE_ID_LOCAL referencing a non-existing BTF type, function bpf_core_calc_relo_insn would cause a null pointer deference. Fix this by adding a proper check upper in call stack, as malformed relocation records could be passed from user space. Simplest reproducer is a program: r0 = 0 exit With a single relocation record: .insn_off = 0, /* patch first instruction */ .type_id = 100500, /* this type id does not exist */ .access_str_off = 6, /* offset of string \"0\" */ .kind = BPF_CORE_TYPE_ID_LOCAL, See the link for original reproducer or next commit for a test case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47702", "url": "https://ubuntu.com/security/CVE-2024-47702", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fail verification for sign-extension of packet data/data_end/data_meta syzbot reported a kernel crash due to commit 1f1e864b6555 (\"bpf: Handle sign-extenstin ctx member accesses\"). The reason is due to sign-extension of 32-bit load for packet data/data_end/data_meta uapi field. The original code looks like: r2 = *(s32 *)(r1 + 76) /* load __sk_buff->data */ r3 = *(u32 *)(r1 + 80) /* load __sk_buff->data_end */ r0 = r2 r0 += 8 if r3 > r0 goto +1 ... Note that __sk_buff->data load has 32-bit sign extension. After verification and convert_ctx_accesses(), the final asm code looks like: r2 = *(u64 *)(r1 +208) r2 = (s32)r2 r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 ... Note that 'r2 = (s32)r2' may make the kernel __sk_buff->data address invalid which may cause runtime failure. Currently, in C code, typically we have void *data = (void *)(long)skb->data; void *data_end = (void *)(long)skb->data_end; ... and it will generate r2 = *(u64 *)(r1 +208) r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 If we allow sign-extension, void *data = (void *)(long)(int)skb->data; void *data_end = (void *)(long)skb->data_end; ... the generated code looks like r2 = *(u64 *)(r1 +208) r2 <<= 32 r2 s>>= 32 r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 and this will cause verification failure since \"r2 <<= 32\" is not allowed as \"r2\" is a packet pointer. To fix this issue for case r2 = *(s32 *)(r1 + 76) /* load __sk_buff->data */ this patch added additional checking in is_valid_access() callback function for packet data/data_end/data_meta access. If those accesses are with sign-extenstion, the verification will fail. [1] https://lore.kernel.org/bpf/000000000000c90eee061d236d37@google.com/", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47703", "url": "https://ubuntu.com/security/CVE-2024-47703", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, lsm: Add check for BPF LSM return value A bpf prog returning a positive number attached to file_alloc_security hook makes kernel panic. This happens because file system can not filter out the positive number returned by the LSM prog using IS_ERR, and misinterprets this positive number as a file pointer. Given that hook file_alloc_security never returned positive number before the introduction of BPF LSM, and other BPF LSM hooks may encounter similar issues, this patch adds LSM return value check in verifier, to ensure no unexpected value is returned.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49851", "url": "https://ubuntu.com/security/CVE-2024-49851", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: Clean up TPM space after command failure tpm_dev_transmit prepares the TPM space before attempting command transmission. However if the command fails no rollback of this preparation is done. This can result in transient handles being leaked if the device is subsequently closed with no further commands performed. Fix this by flushing the space in the event of command transmission failure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47723", "url": "https://ubuntu.com/security/CVE-2024-47723", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: fix out-of-bounds in dbNextAG() and diAlloc() In dbNextAG() , there is no check for the case where bmp->db_numag is greater or same than MAXAG due to a polluted image, which causes an out-of-bounds. Therefore, a bounds check should be added in dbMount(). And in dbNextAG(), a check for the case where agpref is greater than bmp->db_numag should be added, so an out-of-bounds exception should be prevented. Additionally, a check for the case where agno is greater or same than MAXAG should be added in diAlloc() to prevent out-of-bounds.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49852", "url": "https://ubuntu.com/security/CVE-2024-49852", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: elx: libefc: Fix potential use after free in efc_nport_vport_del() The kref_put() function will call nport->release if the refcount drops to zero. The nport->release release function is _efc_nport_free() which frees \"nport\". But then we dereference \"nport\" on the next line which is a use after free. Re-order these lines to avoid the use after free.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47720", "url": "https://ubuntu.com/security/CVE-2024-47720", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for set_output_gamma in dcn30_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn30_set_output_transfer_func function. Previously, set_output_gamma was being checked for nullity at line 386, but then it was being dereferenced without any nullity check at line 401. This could potentially lead to a null pointer dereference error if set_output_gamma is indeed null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a nullity check for set_output_gamma before the call to set_output_gamma at line 401. If set_output_gamma is null, we log an error message and do not call the function. This fix prevents a potential null pointer dereference error. drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:401 dcn30_set_output_transfer_func() error: we previously assumed 'mpc->funcs->set_output_gamma' could be null (see line 386) drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c 373 bool dcn30_set_output_transfer_func(struct dc *dc, 374 struct pipe_ctx *pipe_ctx, 375 const struct dc_stream_state *stream) 376 { 377 int mpcc_id = pipe_ctx->plane_res.hubp->inst; 378 struct mpc *mpc = pipe_ctx->stream_res.opp->ctx->dc->res_pool->mpc; 379 const struct pwl_params *params = NULL; 380 bool ret = false; 381 382 /* program OGAM or 3DLUT only for the top pipe*/ 383 if (pipe_ctx->top_pipe == NULL) { 384 /*program rmu shaper and 3dlut in MPC*/ 385 ret = dcn30_set_mpc_shaper_3dlut(pipe_ctx, stream); 386 if (ret == false && mpc->funcs->set_output_gamma) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If this is NULL 387 if (stream->out_transfer_func.type == TF_TYPE_HWPWL) 388 params = &stream->out_transfer_func.pwl; 389 else if (pipe_ctx->stream->out_transfer_func.type == 390 TF_TYPE_DISTRIBUTED_POINTS && 391 cm3_helper_translate_curve_to_hw_format( 392 &stream->out_transfer_func, 393 &mpc->blender_params, false)) 394 params = &mpc->blender_params; 395 /* there are no ROM LUTs in OUTGAM */ 396 if (stream->out_transfer_func.type == TF_TYPE_PREDEFINED) 397 BREAK_TO_DEBUGGER(); 398 } 399 } 400 --> 401 mpc->funcs->set_output_gamma(mpc, mpcc_id, params); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Then it will crash 402 return ret; 403 }", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47704", "url": "https://ubuntu.com/security/CVE-2024-47704", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check link_res->hpo_dp_link_enc before using it [WHAT & HOW] Functions dp_enable_link_phy and dp_disable_link_phy can pass link_res without initializing hpo_dp_link_enc and it is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49853", "url": "https://ubuntu.com/security/CVE-2024-49853", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix double free in OPTEE transport Channels can be shared between protocols, avoid freeing the same channel descriptors twice when unloading the stack.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47705", "url": "https://ubuntu.com/security/CVE-2024-47705", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix potential invalid pointer dereference in blk_add_partition The blk_add_partition() function initially used a single if-condition (IS_ERR(part)) to check for errors when adding a partition. This was modified to handle the specific case of -ENXIO separately, allowing the function to proceed without logging the error in this case. However, this change unintentionally left a path where md_autodetect_dev() could be called without confirming that part is a valid pointer. This commit separates the error handling logic by splitting the initial if-condition, improving code readability and handling specific error scenarios explicitly. The function now distinguishes the general error case from -ENXIO without altering the existing behavior of md_autodetect_dev() calls.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47736", "url": "https://ubuntu.com/security/CVE-2024-47736", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: handle overlapped pclusters out of crafted images properly syzbot reported a task hang issue due to a deadlock case where it is waiting for the folio lock of a cached folio that will be used for cache I/Os. After looking into the crafted fuzzed image, I found it's formed with several overlapped big pclusters as below: Ext: logical offset | length : physical offset | length 0: 0.. 16384 | 16384 : 151552.. 167936 | 16384 1: 16384.. 32768 | 16384 : 155648.. 172032 | 16384 2: 32768.. 49152 | 16384 : 537223168.. 537239552 | 16384 ... Here, extent 0/1 are physically overlapped although it's entirely _impossible_ for normal filesystem images generated by mkfs. First, managed folios containing compressed data will be marked as up-to-date and then unlocked immediately (unlike in-place folios) when compressed I/Os are complete. If physical blocks are not submitted in the incremental order, there should be separate BIOs to avoid dependency issues. However, the current code mis-arranges z_erofs_fill_bio_vec() and BIO submission which causes unexpected BIO waits. Second, managed folios will be connected to their own pclusters for efficient inter-queries. However, this is somewhat hard to implement easily if overlapped big pclusters exist. Again, these only appear in fuzzed images so let's simply fall back to temporary short-lived pages for correctness. Additionally, it justifies that referenced managed folios cannot be truncated for now and reverts part of commit 2080ca1ed3e4 (\"erofs: tidy up `struct z_erofs_bvec`\") for simplicity although it shouldn't be any difference.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47706", "url": "https://ubuntu.com/security/CVE-2024-47706", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block, bfq: fix possible UAF for bfqq->bic with merge chain 1) initial state, three tasks: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t\t | ? | ?\t\t | ? \t\t | | | |\t\t | | \t\t V | V |\t\t V | \t\t bfqq1 bfqq2\t\t bfqq3 process ref:\t 1\t\t 1\t\t 1 2) bfqq1 merged to bfqq2: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t\t | |\t\t | ? \t\t \\--------------\\|\t\t | | \t\t V\t\t V | \t\t bfqq1--------->bfqq2\t\t bfqq3 process ref:\t 0\t\t 2\t\t 1 3) bfqq2 merged to bfqq3: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t here -> ? |\t\t | \t\t \\--------------\\ \\-------------\\| \t\t V\t\t V \t\t bfqq1--------->bfqq2---------->bfqq3 process ref:\t 0\t\t 1\t\t 3 In this case, IO from Process 1 will get bfqq2 from BIC1 first, and then get bfqq3 through merge chain, and finially handle IO by bfqq3. Howerver, current code will think bfqq2 is owned by BIC1, like initial state, and set bfqq2->bic to BIC1. bfq_insert_request -> by Process 1 bfqq = bfq_init_rq(rq) bfqq = bfq_get_bfqq_handle_split bfqq = bic_to_bfqq -> get bfqq2 from BIC1 bfqq->ref++ rq->elv.priv[0] = bic rq->elv.priv[1] = bfqq if (bfqq_process_refs(bfqq) == 1) bfqq->bic = bic -> record BIC1 to bfqq2 __bfq_insert_request new_bfqq = bfq_setup_cooperator -> get bfqq3 from bfqq2->new_bfqq bfqq_request_freed(bfqq) new_bfqq->ref++ rq->elv.priv[1] = new_bfqq -> handle IO by bfqq3 Fix the problem by checking bfqq is from merge chain fist. And this might fix a following problem reported by our syzkaller(unreproducible): ================================================================== BUG: KASAN: slab-use-after-free in bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] BUG: KASAN: slab-use-after-free in bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] BUG: KASAN: slab-use-after-free in bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 Write of size 1 at addr ffff888123839eb8 by task kworker/0:1H/18595 CPU: 0 PID: 18595 Comm: kworker/0:1H Tainted: G L 6.6.0-07439-gba2303cacfda #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Workqueue: kblockd blk_mq_requeue_work Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [inline] print_report+0x10d/0x610 mm/kasan/report.c:475 kasan_report+0x8e/0xc0 mm/kasan/report.c:588 bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 bfq_get_bfqq_handle_split+0x169/0x5d0 block/bfq-iosched.c:6757 bfq_init_rq block/bfq-iosched.c:6876 [inline] bfq_insert_request block/bfq-iosched.c:6254 [inline] bfq_insert_requests+0x1112/0x5cf0 block/bfq-iosched.c:6304 blk_mq_insert_request+0x290/0x8d0 block/blk-mq.c:2593 blk_mq_requeue_work+0x6bc/0xa70 block/blk-mq.c:1502 process_one_work kernel/workqueue.c:2627 [inline] process_scheduled_works+0x432/0x13f0 kernel/workqueue.c:2700 worker_thread+0x6f2/0x1160 kernel/workqueue.c:2781 kthread+0x33c/0x440 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:305 Allocated by task 20776: kasan_save_stack+0x20/0x40 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 __kasan_slab_alloc+0x87/0x90 mm/kasan/common.c:328 kasan_slab_alloc include/linux/kasan.h:188 [inline] slab_post_alloc_hook mm/slab.h:763 [inline] slab_alloc_node mm/slub.c:3458 [inline] kmem_cache_alloc_node+0x1a4/0x6f0 mm/slub.c:3503 ioc_create_icq block/blk-ioc.c:370 [inline] ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49855", "url": "https://ubuntu.com/security/CVE-2024-49855", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: fix race between timeout and normal completion If request timetout is handled by nbd_requeue_cmd(), normal completion has to be stopped for avoiding to complete this requeued request, other use-after-free can be triggered. Fix the race by clearing NBD_CMD_INFLIGHT in nbd_requeue_cmd(), meantime make sure that cmd->lock is grabbed for clearing the flag and the requeue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47707", "url": "https://ubuntu.com/security/CVE-2024-47707", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev() Blamed commit accidentally removed a check for rt->rt6i_idev being NULL, as spotted by syzbot: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 UID: 0 PID: 10998 Comm: syz-executor Not tainted 6.11.0-rc6-syzkaller-00208-g625403177711 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 RBP: ffffc900047375d0 R08: 0000000000000003 R09: fffff520008e6e8c R10: dffffc0000000000 R11: fffff520008e6e8c R12: 1ffff1100fdf8f18 R13: ffff88807efc7998 R14: 0000000000000000 R15: ffff88807efc7930 FS: 0000000000000000(0000) GS:ffff8880b8900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020002a80 CR3: 0000000022f62000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: addrconf_ifdown+0x15d/0x1bd0 net/ipv6/addrconf.c:3856 addrconf_notify+0x3cb/0x1020 notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93 call_netdevice_notifiers_extack net/core/dev.c:2032 [inline] call_netdevice_notifiers net/core/dev.c:2046 [inline] unregister_netdevice_many_notify+0xd81/0x1c40 net/core/dev.c:11352 unregister_netdevice_many net/core/dev.c:11414 [inline] unregister_netdevice_queue+0x303/0x370 net/core/dev.c:11289 unregister_netdevice include/linux/netdevice.h:3129 [inline] __tun_detach+0x6b9/0x1600 drivers/net/tun.c:685 tun_detach drivers/net/tun.c:701 [inline] tun_chr_close+0x108/0x1b0 drivers/net/tun.c:3510 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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:0x7f1acc77def9 Code: Unable to access opcode bytes at 0x7f1acc77decf. RSP: 002b:00007ffeb26fa738 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1acc77def9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000043 RBP: 00007f1acc7dd508 R08: 00007ffeb26f84d7 R09: 0000000000000003 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 0000000000000003 R14: 00000000ffffffff R15: 00007ffeb26fa8e0 Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 R ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47708", "url": "https://ubuntu.com/security/CVE-2024-47708", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netkit: Assign missing bpf_net_context During the introduction of struct bpf_net_context handling for XDP-redirect, the netkit driver has been missed, which also requires it because NETKIT_REDIRECT invokes skb_do_redirect() which is accessing the per-CPU variables. Otherwise we see the following crash: \tBUG: kernel NULL pointer dereference, address: 0000000000000038 \tbpf_redirect() \tnetkit_xmit() \tdev_hard_start_xmit() Set the bpf_net_context before invoking netkit_xmit() program within the netkit driver.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47709", "url": "https://ubuntu.com/security/CVE-2024-47709", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: Clear bo->bcm_proc_read after remove_proc_entry(). syzbot reported a warning in bcm_release(). [0] The blamed change fixed another warning that is triggered when connect() is issued again for a socket whose connect()ed device has been unregistered. However, if the socket is just close()d without the 2nd connect(), the remaining bo->bcm_proc_read triggers unnecessary remove_proc_entry() in bcm_release(). Let's clear bo->bcm_proc_read after remove_proc_entry() in bcm_notify(). [0] name '4986' WARNING: CPU: 0 PID: 5234 at fs/proc/generic.c:711 remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Modules linked in: CPU: 0 UID: 0 PID: 5234 Comm: syz-executor606 Not tainted 6.11.0-rc5-syzkaller-00178-g5517ae241919 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Code: ff eb 05 e8 cb 1e 5e ff 48 8b 5c 24 10 48 c7 c7 e0 f7 aa 8e e8 2a 38 8e 09 90 48 c7 c7 60 3a 1b 8c 48 89 de e8 da 42 20 ff 90 <0f> 0b 90 90 48 8b 44 24 18 48 c7 44 24 40 0e 36 e0 45 49 c7 04 07 RSP: 0018:ffffc9000345fa20 EFLAGS: 00010246 RAX: 2a2d0aee2eb64600 RBX: ffff888032f1f548 RCX: ffff888029431e00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000345fb08 R08: ffffffff8155b2f2 R09: 1ffff1101710519a R10: dffffc0000000000 R11: ffffed101710519b R12: ffff888011d38640 R13: 0000000000000004 R14: 0000000000000000 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8880b8800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcfb52722f0 CR3: 000000000e734000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: bcm_release+0x250/0x880 net/can/bcm.c:1578 __sock_release net/socket.c:659 [inline] sock_close+0xbc/0x240 net/socket.c:1421 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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:0x7fcfb51ee969 Code: Unable to access opcode bytes at 0x7fcfb51ee93f. RSP: 002b:00007ffce0109ca8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fcfb51ee969 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 00007fcfb526f3b0 R08: ffffffffffffffb8 R09: 0000555500000000 R10: 0000555500000000 R11: 0000000000000246 R12: 00007fcfb526f3b0 R13: 0000000000000000 R14: 00007fcfb5271ee0 R15: 00007fcfb51bf160 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47710", "url": "https://ubuntu.com/security/CVE-2024-47710", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sock_map: Add a cond_resched() in sock_hash_free() Several syzbot soft lockup reports all have in common sock_hash_free() If a map with a large number of buckets is destroyed, we need to yield the cpu when needed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47711", "url": "https://ubuntu.com/security/CVE-2024-47711", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Don't return OOB skb in manage_oob(). syzbot reported use-after-free in unix_stream_recv_urg(). [0] The scenario is 1. send(MSG_OOB) 2. recv(MSG_OOB) -> The consumed OOB remains in recv queue 3. send(MSG_OOB) 4. recv() -> manage_oob() returns the next skb of the consumed OOB -> This is also OOB, but unix_sk(sk)->oob_skb is not cleared 5. recv(MSG_OOB) -> unix_sk(sk)->oob_skb is used but already freed The recent commit 8594d9b85c07 (\"af_unix: Don't call skb_get() for OOB skb.\") uncovered the issue. If the OOB skb is consumed and the next skb is peeked in manage_oob(), we still need to check if the skb is OOB. Let's do so by falling back to the following checks in manage_oob() and add the test case in selftest. Note that we need to add a similar check for SIOCATMARK. [0]: BUG: KASAN: slab-use-after-free in unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959 Read of size 4 at addr ffff8880326abcc4 by task syz-executor178/5235 CPU: 0 UID: 0 PID: 5235 Comm: syz-executor178 Not tainted 6.11.0-rc5-syzkaller-00742-gfbdaffe41adc #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959 unix_stream_recv_urg+0x1df/0x320 net/unix/af_unix.c:2640 unix_stream_read_generic+0x2456/0x2520 net/unix/af_unix.c:2778 unix_stream_recvmsg+0x22b/0x2c0 net/unix/af_unix.c:2996 sock_recvmsg_nosec net/socket.c:1046 [inline] sock_recvmsg+0x22f/0x280 net/socket.c:1068 ____sys_recvmsg+0x1db/0x470 net/socket.c:2816 ___sys_recvmsg net/socket.c:2858 [inline] __sys_recvmsg+0x2f0/0x3e0 net/socket.c:2888 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:0x7f5360d6b4e9 Code: 48 83 c4 28 c3 e8 37 17 00 00 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff29b3a458 EFLAGS: 00000246 ORIG_RAX: 000000000000002f RAX: ffffffffffffffda RBX: 00007fff29b3a638 RCX: 00007f5360d6b4e9 RDX: 0000000000002001 RSI: 0000000020000640 RDI: 0000000000000003 RBP: 00007f5360dde610 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 00007fff29b3a628 R14: 0000000000000001 R15: 0000000000000001 Allocated by task 5235: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:312 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slub.c:3988 [inline] slab_alloc_node mm/slub.c:4037 [inline] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4080 __alloc_skb+0x1c3/0x440 net/core/skbuff.c:667 alloc_skb include/linux/skbuff.h:1320 [inline] alloc_skb_with_frags+0xc3/0x770 net/core/skbuff.c:6528 sock_alloc_send_pskb+0x91a/0xa60 net/core/sock.c:2815 sock_alloc_send_skb include/net/sock.h:1778 [inline] queue_oob+0x108/0x680 net/unix/af_unix.c:2198 unix_stream_sendmsg+0xd24/0xf80 net/unix/af_unix.c:2351 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2680 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 Freed by task 5235: kasan_save_stack mm/kasan/common.c:47 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47712", "url": "https://ubuntu.com/security/CVE-2024-47712", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: fix potential RCU dereference issue in wilc_parse_join_bss_param In the `wilc_parse_join_bss_param` function, the TSF field of the `ies` structure is accessed after the RCU read-side critical section is unlocked. According to RCU usage rules, this is illegal. Reusing this pointer can lead to unpredictable behavior, including accessing memory that has been updated or causing use-after-free issues. This possible bug was identified using a static analysis tool developed by myself, specifically designed to detect RCU-related issues. To address this, the TSF value is now stored in a local variable `ies_tsf` before the RCU lock is released. The `param->tsf_lo` field is then assigned using this local variable, ensuring that the TSF value is safely accessed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47713", "url": "https://ubuntu.com/security/CVE-2024-47713", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop() Since '__dev_queue_xmit()' should be called with interrupts enabled, the following backtrace: ieee80211_do_stop() ... spin_lock_irqsave(&local->queue_stop_reason_lock, flags) ... ieee80211_free_txskb() ieee80211_report_used_skb() ieee80211_report_ack_skb() cfg80211_mgmt_tx_status_ext() nl80211_frame_tx_status() genlmsg_multicast_netns() genlmsg_multicast_netns_filtered() nlmsg_multicast_filtered() \t netlink_broadcast_filtered() \t do_one_broadcast() \t netlink_broadcast_deliver() \t __netlink_sendskb() \t netlink_deliver_tap() \t __netlink_deliver_tap_skb() \t dev_queue_xmit() \t __dev_queue_xmit() ; with IRQS disabled ... spin_unlock_irqrestore(&local->queue_stop_reason_lock, flags) issues the warning (as reported by syzbot reproducer): WARNING: CPU: 2 PID: 5128 at kernel/softirq.c:362 __local_bh_enable_ip+0xc3/0x120 Fix this by implementing a two-phase skb reclamation in 'ieee80211_do_stop()', where actual work is performed outside of a section with interrupts disabled.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47730", "url": "https://ubuntu.com/security/CVE-2024-47730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/qm - inject error before stopping queue The master ooo cannot be completely closed when the accelerator core reports memory error. Therefore, the driver needs to inject the qm error to close the master ooo. Currently, the qm error is injected after stopping queue, memory may be released immediately after stopping queue, causing the device to access the released memory. Therefore, error is injected to close master ooo before stopping queue to ensure that the device does not access the released memory.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49856", "url": "https://ubuntu.com/security/CVE-2024-49856", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/sgx: Fix deadlock in SGX NUMA node search When the current node doesn't have an EPC section configured by firmware and all other EPC sections are used up, CPU can get stuck inside the while loop that looks for an available EPC page from remote nodes indefinitely, leading to a soft lockup. Note how nid_of_current will never be equal to nid in that while loop because nid_of_current is not set in sgx_numa_mask. Also worth mentioning is that it's perfectly fine for the firmware not to setup an EPC section on a node. While setting up an EPC section on each node can enhance performance, it is not a requirement for functionality. Rework the loop to start and end on *a* node that has SGX memory. This avoids the deadlock looking for the current SGX-lacking node to show up in the loop when it never will.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47714", "url": "https://ubuntu.com/security/CVE-2024-47714", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: use hweight16 to get correct tx antenna The chainmask is u16 so using hweight8 cannot get correct tx_ant. Without this patch, the tx_ant of band 2 would be -1 and lead to the following issue: BUG: KASAN: stack-out-of-bounds in mt7996_mcu_add_sta+0x12e0/0x16e0 [mt7996e]", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47715", "url": "https://ubuntu.com/security/CVE-2024-47715", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: fix oops on non-dbdc mt7986 mt7915_band_config() sets band_idx = 1 on the main phy for mt7986 with MT7975_ONE_ADIE or MT7976_ONE_ADIE. Commit 0335c034e726 (\"wifi: mt76: fix race condition related to checking tx queue fill status\") introduced a dereference of the phys array indirectly indexed by band_idx via wcid->phy_idx in mt76_wcid_cleanup(). This caused the following Oops on affected mt7986 devices: Unable to handle kernel read from unreadable memory at virtual address 0000000000000024 Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x00000005 CM = 0, WnR = 0 user pgtable: 4k pages, 39-bit VAs, pgdp=0000000042545000 [0000000000000024] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 Internal error: Oops: 0000000096000005 [#1] SMP Modules linked in: ... mt7915e mt76_connac_lib mt76 mac80211 cfg80211 ... CPU: 2 PID: 1631 Comm: hostapd Not tainted 5.15.150 #0 Hardware name: ZyXEL EX5700 (Telenor) (DT) pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mt76_wcid_cleanup+0x84/0x22c [mt76] lr : mt76_wcid_cleanup+0x64/0x22c [mt76] sp : ffffffc00a803700 x29: ffffffc00a803700 x28: ffffff80008f7300 x27: ffffff80003f3c00 x26: ffffff80000a7880 x25: ffffffc008c26e00 x24: 0000000000000001 x23: ffffffc000a68114 x22: 0000000000000000 x21: ffffff8004172cc8 x20: ffffffc00a803748 x19: ffffff8004152020 x18: 0000000000000000 x17: 00000000000017c0 x16: ffffffc008ef5000 x15: 0000000000000be0 x14: ffffff8004172e28 x13: ffffff8004172e28 x12: 0000000000000000 x11: 0000000000000000 x10: ffffff8004172e30 x9 : ffffff8004172e28 x8 : 0000000000000000 x7 : ffffff8004156020 x6 : 0000000000000000 x5 : 0000000000000031 x4 : 0000000000000000 x3 : 0000000000000001 x2 : 0000000000000000 x1 : ffffff80008f7300 x0 : 0000000000000024 Call trace: mt76_wcid_cleanup+0x84/0x22c [mt76] __mt76_sta_remove+0x70/0xbc [mt76] mt76_sta_state+0x8c/0x1a4 [mt76] mt7915_eeprom_get_power_delta+0x11e4/0x23a0 [mt7915e] drv_sta_state+0x144/0x274 [mac80211] sta_info_move_state+0x1cc/0x2a4 [mac80211] sta_set_sinfo+0xaf8/0xc24 [mac80211] sta_info_destroy_addr_bss+0x4c/0x6c [mac80211] ieee80211_color_change_finish+0x1c08/0x1e70 [mac80211] cfg80211_check_station_change+0x1360/0x4710 [cfg80211] genl_family_rcv_msg_doit+0xb4/0x110 genl_rcv_msg+0xd0/0x1bc netlink_rcv_skb+0x58/0x120 genl_rcv+0x34/0x50 netlink_unicast+0x1f0/0x2ec netlink_sendmsg+0x198/0x3d0 ____sys_sendmsg+0x1b0/0x210 ___sys_sendmsg+0x80/0xf0 __sys_sendmsg+0x44/0xa0 __arm64_sys_sendmsg+0x20/0x30 invoke_syscall.constprop.0+0x4c/0xe0 do_el0_svc+0x40/0xd0 el0_svc+0x14/0x4c el0t_64_sync_handler+0x100/0x110 el0t_64_sync+0x15c/0x160 Code: d2800002 910092c0 52800023 f9800011 (885f7c01) ---[ end trace 7e42dd9a39ed2281 ]--- Fix by using mt76_dev_phy() which will map band_idx to the correct phy for all hardware combinations.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49857", "url": "https://ubuntu.com/security/CVE-2024-49857", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: set the cipher for secured NDP ranging The cipher pointer is not set, but is derefereced trying to set its content, which leads to a NULL pointer dereference. Fix it by pointing to the cipher parameter before dereferencing.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47738", "url": "https://ubuntu.com/security/CVE-2024-47738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: don't use rate mask for offchannel TX either Like the commit ab9177d83c04 (\"wifi: mac80211: don't use rate mask for scanning\"), ignore incorrect settings to avoid no supported rate warning reported by syzbot. The syzbot did bisect and found cause is commit 9df66d5b9f45 (\"cfg80211: fix default HE tx bitrate mask in 2G band\"), which however corrects bitmask of HE MCS and recognizes correctly settings of empty legacy rate plus HE MCS rate instead of returning -EINVAL. As suggestions [1], follow the change of SCAN TX to consider this case of offchannel TX as well. [1] https://lore.kernel.org/linux-wireless/6ab2dc9c3afe753ca6fdcdd1421e7a1f47e87b84.camel@sipsolutions.net/T/#m2ac2a6d2be06a37c9c47a3d8a44b4f647ed4f024", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47731", "url": "https://ubuntu.com/security/CVE-2024-47731", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers/perf: Fix ali_drw_pmu driver interrupt status clearing The alibaba_uncore_pmu driver forgot to clear all interrupt status in the interrupt processing function. After the PMU counter overflow interrupt occurred, an interrupt storm occurred, causing the system to hang. Therefore, clear the correct interrupt status in the interrupt handling function to fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49862", "url": "https://ubuntu.com/security/CVE-2024-49862", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powercap: intel_rapl: Fix off by one in get_rpi() The rp->priv->rpi array is either rpi_msr or rpi_tpmi which have NR_RAPL_PRIMITIVES number of elements. Thus the > needs to be >= to prevent an off by one access.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47716", "url": "https://ubuntu.com/security/CVE-2024-47716", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: 9410/1: vfp: Use asm volatile in fmrx/fmxr macros Floating point instructions in userspace can crash some arm kernels built with clang/LLD 17.0.6: BUG: unsupported FP instruction in kernel mode FPEXC == 0xc0000780 Internal error: Oops - undefined instruction: 0 [#1] ARM CPU: 0 PID: 196 Comm: vfp-reproducer Not tainted 6.10.0 #1 Hardware name: BCM2835 PC is at vfp_support_entry+0xc8/0x2cc LR is at do_undefinstr+0xa8/0x250 pc : [] lr : [] psr: a0000013 sp : dc8d1f68 ip : 60000013 fp : bedea19c r10: ec532b17 r9 : 00000010 r8 : 0044766c r7 : c0000780 r6 : ec532b17 r5 : c1c13800 r4 : dc8d1fb0 r3 : c10072c4 r2 : c0101c88 r1 : ec532b17 r0 : 0044766c Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 00c5387d Table: 0251c008 DAC: 00000051 Register r0 information: non-paged memory Register r1 information: vmalloc memory Register r2 information: non-slab/vmalloc memory Register r3 information: non-slab/vmalloc memory Register r4 information: 2-page vmalloc region Register r5 information: slab kmalloc-cg-2k Register r6 information: vmalloc memory Register r7 information: non-slab/vmalloc memory Register r8 information: non-paged memory Register r9 information: zero-size pointer Register r10 information: vmalloc memory Register r11 information: non-paged memory Register r12 information: non-paged memory Process vfp-reproducer (pid: 196, stack limit = 0x61aaaf8b) Stack: (0xdc8d1f68 to 0xdc8d2000) 1f60: 0000081f b6f69300 0000000f c10073f4 c10072c4 dc8d1fb0 1f80: ec532b17 0c532b17 0044766c b6f9ccd8 00000000 c010a80c 00447670 60000010 1fa0: ffffffff c1c13800 00c5387d c0100f10 b6f68af8 00448fc0 00000000 bedea188 1fc0: bedea314 00000001 00448ebc b6f9d000 00447608 b6f9ccd8 00000000 bedea19c 1fe0: bede9198 bedea188 b6e1061c 0044766c 60000010 ffffffff 00000000 00000000 Call trace: [] (vfp_support_entry) from [] (do_undefinstr+0xa8/0x250) [] (do_undefinstr) from [] (__und_usr+0x70/0x80) Exception stack(0xdc8d1fb0 to 0xdc8d1ff8) 1fa0: b6f68af8 00448fc0 00000000 bedea188 1fc0: bedea314 00000001 00448ebc b6f9d000 00447608 b6f9ccd8 00000000 bedea19c 1fe0: bede9198 bedea188 b6e1061c 0044766c 60000010 ffffffff Code: 0a000061 e3877202 e594003c e3a09010 (eef16a10) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Fatal exception in interrupt ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]--- This is a minimal userspace reproducer on a Raspberry Pi Zero W: #include #include int main(void) { double v = 1.0; printf(\"%fn\", NAN + *(volatile double *)&v); return 0; } Another way to consistently trigger the oops is: calvin@raspberry-pi-zero-w ~$ python -c \"import json\" The bug reproduces only when the kernel is built with DYNAMIC_DEBUG=n, because the pr_debug() calls act as barriers even when not activated. This is the output from the same kernel source built with the same compiler and DYNAMIC_DEBUG=y, where the userspace reproducer works as expected: VFP: bounce: trigger ec532b17 fpexc c0000780 VFP: emulate: INST=0xee377b06 SCR=0x00000000 VFP: bounce: trigger eef1fa10 fpexc c0000780 VFP: emulate: INST=0xeeb40b40 SCR=0x00000000 VFP: raising exceptions 30000000 calvin@raspberry-pi-zero-w ~$ ./vfp-reproducer nan Crudely grepping for vmsr/vmrs instructions in the otherwise nearly idential text for vfp_support_entry() makes the problem obvious: vmlinux.llvm.good [0xc0101cb8] <+48>: vmrs r7, fpexc vmlinux.llvm.good [0xc0101cd8] <+80>: vmsr fpexc, r0 vmlinux.llvm.good [0xc0101d20 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47717", "url": "https://ubuntu.com/security/CVE-2024-47717", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RISC-V: KVM: Don't zero-out PMU snapshot area before freeing data With the latest Linux-6.11-rc3, the below NULL pointer crash is observed when SBI PMU snapshot is enabled for the guest and the guest is forcefully powered-off. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000508 Oops [#1] Modules linked in: kvm CPU: 0 UID: 0 PID: 61 Comm: term-poll Not tainted 6.11.0-rc3-00018-g44d7178dd77a #3 Hardware name: riscv-virtio,qemu (DT) epc : __kvm_write_guest_page+0x94/0xa6 [kvm] ra : __kvm_write_guest_page+0x54/0xa6 [kvm] epc : ffffffff01590e98 ra : ffffffff01590e58 sp : ffff8f80001f39b0 gp : ffffffff81512a60 tp : ffffaf80024872c0 t0 : ffffaf800247e000 t1 : 00000000000007e0 t2 : 0000000000000000 s0 : ffff8f80001f39f0 s1 : 00007fff89ac4000 a0 : ffffffff015dd7e8 a1 : 0000000000000086 a2 : 0000000000000000 a3 : ffffaf8000000000 a4 : ffffaf80024882c0 a5 : 0000000000000000 a6 : ffffaf800328d780 a7 : 00000000000001cc s2 : ffffaf800197bd00 s3 : 00000000000828c4 s4 : ffffaf800248c000 s5 : ffffaf800247d000 s6 : 0000000000001000 s7 : 0000000000001000 s8 : 0000000000000000 s9 : 00007fff861fd500 s10: 0000000000000001 s11: 0000000000800000 t3 : 00000000000004d3 t4 : 00000000000004d3 t5 : ffffffff814126e0 t6 : ffffffff81412700 status: 0000000200000120 badaddr: 0000000000000508 cause: 000000000000000d [] __kvm_write_guest_page+0x94/0xa6 [kvm] [] kvm_vcpu_write_guest+0x56/0x90 [kvm] [] kvm_pmu_clear_snapshot_area+0x42/0x7e [kvm] [] kvm_riscv_vcpu_pmu_deinit.part.0+0xe0/0x14e [kvm] [] kvm_riscv_vcpu_pmu_deinit+0x1a/0x24 [kvm] [] kvm_arch_vcpu_destroy+0x28/0x4c [kvm] [] kvm_destroy_vcpus+0x5a/0xda [kvm] [] kvm_arch_destroy_vm+0x14/0x28 [kvm] [] kvm_destroy_vm+0x168/0x2a0 [kvm] [] kvm_put_kvm+0x3c/0x58 [kvm] [] kvm_vm_release+0x22/0x2e [kvm] Clearly, the kvm_vcpu_write_guest() function is crashing because it is being called from kvm_pmu_clear_snapshot_area() upon guest tear down. To address the above issue, simplify the kvm_pmu_clear_snapshot_area() to not zero-out PMU snapshot area from kvm_pmu_clear_snapshot_area() because the guest is anyway being tore down. The kvm_pmu_clear_snapshot_area() is also called when guest changes PMU snapshot area of a VCPU but even in this case the previous PMU snaphsot area must not be zeroed-out because the guest might have reclaimed the pervious PMU snapshot area for some other purpose.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47721", "url": "https://ubuntu.com/security/CVE-2024-47721", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: remove unused C2H event ID RTW89_MAC_C2H_FUNC_READ_WOW_CAM to prevent out-of-bounds reading The handler of firmware C2H event RTW89_MAC_C2H_FUNC_READ_WOW_CAM isn't implemented, but driver expects number of handlers is NUM_OF_RTW89_MAC_C2H_FUNC_WOW causing out-of-bounds access. Fix it by removing ID. Addresses-Coverity-ID: 1598775 (\"Out-of-bounds read\")", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47732", "url": "https://ubuntu.com/security/CVE-2024-47732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: iaa - Fix potential use after free bug The free_device_compression_mode(iaa_device, device_mode) function frees \"device_mode\" but it iss passed to iaa_compression_modes[i]->free() a few lines later resulting in a use after free. The good news is that, so far as I can tell, nothing implements the ->free() function and the use after free happens in dead code. But, with this fix, when something does implement it, we'll be ready. :)", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47718", "url": "https://ubuntu.com/security/CVE-2024-47718", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: always wait for both firmware loading attempts In 'rtw_wait_firmware_completion()', always wait for both (regular and wowlan) firmware loading attempts. Otherwise if 'rtw_usb_intf_init()' has failed in 'rtw_usb_probe()', 'rtw_usb_disconnect()' may issue 'ieee80211_free_hw()' when one of 'rtw_load_firmware_cb()' (usually the wowlan one) is still in progress, causing UAF detected by KASAN.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47724", "url": "https://ubuntu.com/security/CVE-2024-47724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: use work queue to process beacon tx event Commit 3a415daa3e8b (\"wifi: ath11k: add P2P IE in beacon template\") from Feb 28, 2024 (linux-next), leads to the following Smatch static checker warning: drivers/net/wireless/ath/ath11k/wmi.c:1742 ath11k_wmi_p2p_go_bcn_ie() warn: sleeping in atomic context The reason is that ath11k_bcn_tx_status_event() will directly call might sleep function ath11k_wmi_cmd_send() during RCU read-side critical sections. The call trace is like: ath11k_bcn_tx_status_event() -> rcu_read_lock() -> ath11k_mac_bcn_tx_event() \t-> ath11k_mac_setup_bcn_tmpl() \t…… \t\t-> ath11k_wmi_bcn_tmpl() \t\t\t-> ath11k_wmi_cmd_send() -> rcu_read_unlock() Commit 886433a98425 (\"ath11k: add support for BSS color change\") added the ath11k_mac_bcn_tx_event(), commit 01e782c89108 (\"ath11k: fix warning of RCU usage for ath11k_mac_get_arvif_by_vdev_id()\") added the RCU lock to avoid warning but also introduced this BUG. Use work queue to avoid directly calling ath11k_mac_bcn_tx_event() during RCU critical sections. No need to worry about the deletion of vif because cancel_work_sync() will drop the work if it doesn't start or block vif deletion until the running work is done. 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": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47671", "url": "https://ubuntu.com/security/CVE-2024-47671", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: usbtmc: prevent kernel-usb-infoleak The syzbot reported a kernel-usb-infoleak in usbtmc_write, we need to clear the structure before filling fields.", "cve_priority": "medium", "cve_public_date": "2024-10-09 15:15:00 UTC" }, { "cve": "CVE-2024-46869", "url": "https://ubuntu.com/security/CVE-2024-46869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btintel_pcie: Allocate memory for driver private data Fix driver not allocating memory for struct btintel_data which is used to store internal data.", "cve_priority": "medium", "cve_public_date": "2024-09-30 16:15:00 UTC" }, { "cve": "CVE-2024-53164", "url": "https://ubuntu.com/security/CVE-2024-53164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: fix ordering of qlen adjustment Changes to sch->q.qlen around qdisc_tree_reduce_backlog() need to happen _before_ a call to said function because otherwise it may fail to notify parent qdiscs when the child is about to become empty.", "cve_priority": "medium", "cve_public_date": "2024-12-27 14:15:00 UTC" }, { "cve": "CVE-2024-53103", "url": "https://ubuntu.com/security/CVE-2024-53103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hv_sock: Initializing vsk->trans to NULL to prevent a dangling pointer When hvs is released, there is a possibility that vsk->trans may not be initialized to NULL, which could lead to a dangling pointer. This issue is resolved by initializing vsk->trans to NULL.", "cve_priority": "high", "cve_public_date": "2024-12-02 08:15:00 UTC" } ], "launchpad_bugs_fixed": [ 2093643, 1786013, 2091744, 2091184, 2093146, 2085406, 2089684, 2090932, 2085485, 2089357, 2089306, 2091655, 2091655, 2091655, 2091655, 2091655, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091386, 2091990, 2089327, 2089113, 2086587, 2086606, 2085950, 2085944, 2087853, 2087983, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089020, 2089020, 2089020 ], "changes": [ { "cves": [ { "cve": "CVE-2025-0927", "url": "https://ubuntu.com/security/CVE-2025-0927", "cve_description": "[fs: hfs/hfsplus: add key_len boundary check to hfs_bnode_read_key]", "cve_priority": "medium", "cve_public_date": "2025-02-13" } ], "log": [ "", " * CVE-2025-0927", " - SAUCE: fs: hfs/hfsplus: add key_len boundary check to hfs_bnode_read_key", "" ], "package": "linux", "version": "6.11.0-18.18", "urgency": "medium", "distributions": "oracular", "launchpad_bugs_fixed": [], "author": "Manuel Diewald ", "date": "Fri, 07 Feb 2025 18:44:32 +0100" }, { "cves": [ { "cve": "CVE-2024-53141", "url": "https://ubuntu.com/security/CVE-2024-53141", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: add missing range check in bitmap_ip_uadt When tb[IPSET_ATTR_IP_TO] is not present but tb[IPSET_ATTR_CIDR] exists, the values of ip and ip_to are slightly swapped. Therefore, the range check for ip should be done later, but this part is missing and it seems that the vulnerability occurs. So we should add missing range checks and remove unnecessary range checks.", "cve_priority": "medium", "cve_public_date": "2024-12-06 10:15:00 UTC" }, { "cve": "CVE-2024-50010", "url": "https://ubuntu.com/security/CVE-2024-50010", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exec: don't WARN for racy path_noexec check Both i_mode and noexec checks wrapped in WARN_ON stem from an artifact of the previous implementation. They used to legitimately check for the condition, but that got moved up in two commits: 633fb6ac3980 (\"exec: move S_ISREG() check earlier\") 0fd338b2d2cd (\"exec: move path_noexec() check earlier\") Instead of being removed said checks are WARN_ON'ed instead, which has some debug value. However, the spurious path_noexec check is racy, resulting in unwarranted warnings should someone race with setting the noexec flag. One can note there is more to perm-checking whether execve is allowed and none of the conditions are guaranteed to still hold after they were tested for. Additionally this does not validate whether the code path did any perm checking to begin with -- it will pass if the inode happens to be regular. Keep the redundant path_noexec() check even though it's mindless nonsense checking for guarantee that isn't given so drop the WARN. Reword the commentary and do small tidy ups while here. [brauner: keep redundant path_noexec() check]", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-53143", "url": "https://ubuntu.com/security/CVE-2024-53143", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fsnotify: Fix ordering of iput() and watched_objects decrement Ensure the superblock is kept alive until we're done with iput(). Holding a reference to an inode is not allowed unless we ensure the superblock stays alive, which fsnotify does by keeping the watched_objects count elevated, so iput() must happen before the watched_objects decrement. This can lead to a UAF of something like sb->s_fs_info in tmpfs, but the UAF is hard to hit because race orderings that oops are more likely, thanks to the CHECK_DATA_CORRUPTION() block in generic_shutdown_super(). Also, ensure that fsnotify_put_sb_watched_objects() doesn't call fsnotify_sb_watched_objects() on a superblock that may have already been freed, which would cause a UAF read of sb->s_fsnotify_info.", "cve_priority": "medium", "cve_public_date": "2024-12-07 07:15:00 UTC" }, { "cve": "CVE-2024-53142", "url": "https://ubuntu.com/security/CVE-2024-53142", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: initramfs: avoid filename buffer overrun The initramfs filename field is defined in Documentation/driver-api/early-userspace/buffer-format.rst as: 37 cpio_file := ALGN(4) + cpio_header + filename + \"\\0\" + ALGN(4) + data ... 55 ============= ================== ========================= 56 Field name Field size Meaning 57 ============= ================== ========================= ... 70 c_namesize 8 bytes Length of filename, including final \\0 When extracting an initramfs cpio archive, the kernel's do_name() path handler assumes a zero-terminated path at @collected, passing it directly to filp_open() / init_mkdir() / init_mknod(). If a specially crafted cpio entry carries a non-zero-terminated filename and is followed by uninitialized memory, then a file may be created with trailing characters that represent the uninitialized memory. The ability to create an initramfs entry would imply already having full control of the system, so the buffer overrun shouldn't be considered a security vulnerability. Append the output of the following bash script to an existing initramfs and observe any created /initramfs_test_fname_overrunAA* path. E.g. ./reproducer.sh | gzip >> /myinitramfs It's easiest to observe non-zero uninitialized memory when the output is gzipped, as it'll overflow the heap allocated @out_buf in __gunzip(), rather than the initrd_start+initrd_size block. ---- reproducer.sh ---- nilchar=\"A\"\t# change to \"\\0\" to properly zero terminate / pad magic=\"070701\" ino=1 mode=$(( 0100777 )) uid=0 gid=0 nlink=1 mtime=1 filesize=0 devmajor=0 devminor=1 rdevmajor=0 rdevminor=0 csum=0 fname=\"initramfs_test_fname_overrun\" namelen=$(( ${#fname} + 1 ))\t# plus one to account for terminator printf \"%s%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%08x%s\" \\ \t$magic $ino $mode $uid $gid $nlink $mtime $filesize \\ \t$devmajor $devminor $rdevmajor $rdevminor $namelen $csum $fname termpadlen=$(( 1 + ((4 - ((110 + $namelen) & 3)) % 4) )) printf \"%.s${nilchar}\" $(seq 1 $termpadlen) ---- reproducer.sh ---- Symlink filename fields handled in do_symlink() won't overrun past the data segment, due to the explicit zero-termination of the symlink target. Fix filename buffer overrun by aborting the initramfs FSM if any cpio entry doesn't carry a zero-terminator at the expected (name_len - 1) offset.", "cve_priority": "medium", "cve_public_date": "2024-12-06 10:15:00 UTC" }, { "cve": "CVE-2024-53133", "url": "https://ubuntu.com/security/CVE-2024-53133", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Handle dml allocation failure to avoid crash [Why] In the case where a dml allocation fails for any reason, the current state's dml contexts would no longer be valid. Then subsequent calls dc_state_copy_internal would shallow copy invalid memory and if the new state was released, a double free would occur. [How] Reset dml pointers in new_state to NULL and avoid invalid pointer (cherry picked from commit bcafdc61529a48f6f06355d78eb41b3aeda5296c)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53108", "url": "https://ubuntu.com/security/CVE-2024-53108", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Adjust VSDB parser for replay feature At some point, the IEEE ID identification for the replay check in the AMD EDID was added. However, this check causes the following out-of-bounds issues when using KASAN: [ 27.804016] BUG: KASAN: slab-out-of-bounds in amdgpu_dm_update_freesync_caps+0xefa/0x17a0 [amdgpu] [ 27.804788] Read of size 1 at addr ffff8881647fdb00 by task systemd-udevd/383 ... [ 27.821207] Memory state around the buggy address: [ 27.821215] ffff8881647fda00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821224] ffff8881647fda80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821234] >ffff8881647fdb00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821243] ^ [ 27.821250] ffff8881647fdb80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 27.821259] ffff8881647fdc00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 27.821268] ================================================================== This is caused because the ID extraction happens outside of the range of the edid lenght. This commit addresses this issue by considering the amd_vsdb_block size. (cherry picked from commit b7e381b1ccd5e778e3d9c44c669ad38439a861d8)", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53134", "url": "https://ubuntu.com/security/CVE-2024-53134", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pmdomain: imx93-blk-ctrl: correct remove path The check condition should be 'i < bc->onecell_data.num_domains', not 'bc->onecell_data.num_domains' which will make the look never finish and cause kernel panic. Also disable runtime to address \"imx93-blk-ctrl 4ac10000.system-controller: Unbalanced pm_runtime_enable!\"", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53132", "url": "https://ubuntu.com/security/CVE-2024-53132", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/oa: Fix \"Missing outer runtime PM protection\" warning Fix the following drm_WARN: [953.586396] xe 0000:00:02.0: [drm] Missing outer runtime PM protection ... <4> [953.587090] ? xe_pm_runtime_get_noresume+0x8d/0xa0 [xe] <4> [953.587208] guc_exec_queue_add_msg+0x28/0x130 [xe] <4> [953.587319] guc_exec_queue_fini+0x3a/0x40 [xe] <4> [953.587425] xe_exec_queue_destroy+0xb3/0xf0 [xe] <4> [953.587515] xe_oa_release+0x9c/0xc0 [xe] (cherry picked from commit b107c63d2953907908fd0cafb0e543b3c3167b75)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53127", "url": "https://ubuntu.com/security/CVE-2024-53127", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Revert \"mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K\" The commit 8396c793ffdf (\"mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K\") increased the max_req_size, even for 4K pages, causing various issues: - Panic booting the kernel/rootfs from an SD card on Rockchip RK3566 - Panic booting the kernel/rootfs from an SD card on StarFive JH7100 - \"swiotlb buffer is full\" and data corruption on StarFive JH7110 At this stage no fix have been found, so it's probably better to just revert the change. This reverts commit 8396c793ffdf28bb8aee7cfe0891080f8cab7890.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53130", "url": "https://ubuntu.com/security/CVE-2024-53130", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint When using the \"block:block_dirty_buffer\" tracepoint, mark_buffer_dirty() may cause a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because, since the tracepoint was added in mark_buffer_dirty(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, nilfs_grab_buffer(), which grabs a buffer to read (or create) a block of metadata, including b-tree node blocks, does not set the block device, but instead does so only if the buffer is not in the \"uptodate\" state for each of its caller block reading functions. However, if the uptodate flag is set on a folio/page, and the buffer heads are detached from it by try_to_free_buffers(), and new buffer heads are then attached by create_empty_buffers(), the uptodate flag may be restored to each buffer without the block device being set to bh->b_bdev, and mark_buffer_dirty() may be called later in that state, resulting in the bug mentioned above. Fix this issue by making nilfs_grab_buffer() always set the block device of the super block structure to the buffer head, regardless of the state of the buffer's uptodate flag.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53105", "url": "https://ubuntu.com/security/CVE-2024-53105", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: page_alloc: move mlocked flag clearance into free_pages_prepare() Syzbot reported a bad page state problem caused by a page being freed using free_page() still having a mlocked flag at free_pages_prepare() stage: BUG: Bad page state in process syz.5.504 pfn:61f45 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x61f45 flags: 0xfff00000080204(referenced|workingset|mlocked|node=0|zone=1|lastcpupid=0x7ff) raw: 00fff00000080204 0000000000000000 dead000000000122 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set page_owner tracks the page as allocated page last allocated via order 0, migratetype Unmovable, gfp_mask 0x400dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO), pid 8443, tgid 8442 (syz.5.504), ts 201884660643, free_ts 201499827394 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1537 prep_new_page mm/page_alloc.c:1545 [inline] get_page_from_freelist+0x303f/0x3190 mm/page_alloc.c:3457 __alloc_pages_noprof+0x292/0x710 mm/page_alloc.c:4733 alloc_pages_mpol_noprof+0x3e8/0x680 mm/mempolicy.c:2265 kvm_coalesced_mmio_init+0x1f/0xf0 virt/kvm/coalesced_mmio.c:99 kvm_create_vm virt/kvm/kvm_main.c:1235 [inline] kvm_dev_ioctl_create_vm virt/kvm/kvm_main.c:5488 [inline] kvm_dev_ioctl+0x12dc/0x2240 virt/kvm/kvm_main.c:5530 __do_compat_sys_ioctl fs/ioctl.c:1007 [inline] __se_compat_sys_ioctl+0x510/0xc90 fs/ioctl.c:950 do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline] __do_fast_syscall_32+0xb4/0x110 arch/x86/entry/common.c:386 do_fast_syscall_32+0x34/0x80 arch/x86/entry/common.c:411 entry_SYSENTER_compat_after_hwframe+0x84/0x8e page last free pid 8399 tgid 8399 stack trace: reset_page_owner include/linux/page_owner.h:25 [inline] free_pages_prepare mm/page_alloc.c:1108 [inline] free_unref_folios+0xf12/0x18d0 mm/page_alloc.c:2686 folios_put_refs+0x76c/0x860 mm/swap.c:1007 free_pages_and_swap_cache+0x5c8/0x690 mm/swap_state.c:335 __tlb_batch_free_encoded_pages mm/mmu_gather.c:136 [inline] tlb_batch_pages_flush mm/mmu_gather.c:149 [inline] tlb_flush_mmu_free mm/mmu_gather.c:366 [inline] tlb_flush_mmu+0x3a3/0x680 mm/mmu_gather.c:373 tlb_finish_mmu+0xd4/0x200 mm/mmu_gather.c:465 exit_mmap+0x496/0xc40 mm/mmap.c:1926 __mmput+0x115/0x390 kernel/fork.c:1348 exit_mm+0x220/0x310 kernel/exit.c:571 do_exit+0x9b2/0x28e0 kernel/exit.c:926 do_group_exit+0x207/0x2c0 kernel/exit.c:1088 __do_sys_exit_group kernel/exit.c:1099 [inline] __se_sys_exit_group kernel/exit.c:1097 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1097 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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 Modules linked in: CPU: 0 UID: 0 PID: 8442 Comm: syz.5.504 Not tainted 6.12.0-rc6-syzkaller #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 bad_page+0x176/0x1d0 mm/page_alloc.c:501 free_page_is_bad mm/page_alloc.c:918 [inline] free_pages_prepare mm/page_alloc.c:1100 [inline] free_unref_page+0xed0/0xf20 mm/page_alloc.c:2638 kvm_destroy_vm virt/kvm/kvm_main.c:1327 [inline] kvm_put_kvm+0xc75/0x1350 virt/kvm/kvm_main.c:1386 kvm_vcpu_release+0x54/0x60 virt/kvm/kvm_main.c:4143 __fput+0x23f/0x880 fs/file_table.c:431 task_work_run+0x24f/0x310 kernel/task_work.c:239 exit_task_work include/linux/task_work.h:43 [inline] do_exit+0xa2f/0x28e0 kernel/exit.c:939 do_group_exit+0x207/0x2c0 kernel/exit.c:1088 __do_sys_exit_group kernel/exit.c:1099 [in ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53109", "url": "https://ubuntu.com/security/CVE-2024-53109", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nommu: pass NULL argument to vma_iter_prealloc() When deleting a vma entry from a maple tree, it has to pass NULL to vma_iter_prealloc() in order to calculate internal state of the tree, but it passed a wrong argument. As a result, nommu kernels crashed upon accessing a vma iterator, such as acct_collect() reading the size of vma entries after do_munmap(). This commit fixes this issue by passing a right argument to the preallocation call.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53131", "url": "https://ubuntu.com/security/CVE-2024-53131", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint Patch series \"nilfs2: fix null-ptr-deref bugs on block tracepoints\". This series fixes null pointer dereference bugs that occur when using nilfs2 and two block-related tracepoints. This patch (of 2): It has been reported that when using \"block:block_touch_buffer\" tracepoint, touch_buffer() called from __nilfs_get_folio_block() causes a NULL pointer dereference, or a general protection fault when KASAN is enabled. This happens because since the tracepoint was added in touch_buffer(), it references the dev_t member bh->b_bdev->bd_dev regardless of whether the buffer head has a pointer to a block_device structure. In the current implementation, the block_device structure is set after the function returns to the caller. Here, touch_buffer() is used to mark the folio/page that owns the buffer head as accessed, but the common search helper for folio/page used by the caller function was optimized to mark the folio/page as accessed when it was reimplemented a long time ago, eliminating the need to call touch_buffer() here in the first place. So this solves the issue by eliminating the touch_buffer() call itself.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53135", "url": "https://ubuntu.com/security/CVE-2024-53135", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: VMX: Bury Intel PT virtualization (guest/host mode) behind CONFIG_BROKEN Hide KVM's pt_mode module param behind CONFIG_BROKEN, i.e. disable support for virtualizing Intel PT via guest/host mode unless BROKEN=y. There are myriad bugs in the implementation, some of which are fatal to the guest, and others which put the stability and health of the host at risk. For guest fatalities, the most glaring issue is that KVM fails to ensure tracing is disabled, and *stays* disabled prior to VM-Enter, which is necessary as hardware disallows loading (the guest's) RTIT_CTL if tracing is enabled (enforced via a VMX consistency check). Per the SDM: If the logical processor is operating with Intel PT enabled (if IA32_RTIT_CTL.TraceEn = 1) at the time of VM entry, the \"load IA32_RTIT_CTL\" VM-entry control must be 0. On the host side, KVM doesn't validate the guest CPUID configuration provided by userspace, and even worse, uses the guest configuration to decide what MSRs to save/load at VM-Enter and VM-Exit. E.g. configuring guest CPUID to enumerate more address ranges than are supported in hardware will result in KVM trying to passthrough, save, and load non-existent MSRs, which generates a variety of WARNs, ToPA ERRORs in the host, a potential deadlock, etc.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53106", "url": "https://ubuntu.com/security/CVE-2024-53106", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ima: fix buffer overrun in ima_eventdigest_init_common Function ima_eventdigest_init() calls ima_eventdigest_init_common() with HASH_ALGO__LAST which is then used to access the array hash_digest_size[] leading to buffer overrun. Have a conditional statement to handle this.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53110", "url": "https://ubuntu.com/security/CVE-2024-53110", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vp_vdpa: fix id_table array not null terminated error Allocate one extra virtio_device_id as null terminator, otherwise vdpa_mgmtdev_get_classes() may iterate multiple times and visit undefined memory.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53126", "url": "https://ubuntu.com/security/CVE-2024-53126", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa: solidrun: Fix UB bug with devres In psnet_open_pf_bar() and snet_open_vf_bar() a string later passed to pcim_iomap_regions() is placed on the stack. Neither pcim_iomap_regions() nor the functions it calls copy that string. Should the string later ever be used, this, consequently, causes undefined behavior since the stack frame will by then have disappeared. Fix the bug by allocating the strings on the heap through devm_kasprintf().", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53111", "url": "https://ubuntu.com/security/CVE-2024-53111", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mremap: fix address wraparound in move_page_tables() On 32-bit platforms, it is possible for the expression `len + old_addr < old_end` to be false-positive if `len + old_addr` wraps around. `old_addr` is the cursor in the old range up to which page table entries have been moved; so if the operation succeeded, `old_addr` is the *end* of the old region, and adding `len` to it can wrap. The overflow causes mremap() to mistakenly believe that PTEs have been copied; the consequence is that mremap() bails out, but doesn't move the PTEs back before the new VMA is unmapped, causing anonymous pages in the region to be lost. So basically if userspace tries to mremap() a private-anon region and hits this bug, mremap() will return an error and the private-anon region's contents appear to have been zeroed. The idea of this check is that `old_end - len` is the original start address, and writing the check that way also makes it easier to read; so fix the check by rearranging the comparison accordingly. (An alternate fix would be to refactor this function by introducing an \"orig_old_start\" variable or such.) Tested in a VM with a 32-bit X86 kernel; without the patch: ``` user@horn:~/big_mremap$ cat test.c #define _GNU_SOURCE #include #include #include #include #define ADDR1 ((void*)0x60000000) #define ADDR2 ((void*)0x10000000) #define SIZE 0x50000000uL int main(void) { unsigned char *p1 = mmap(ADDR1, SIZE, PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0); if (p1 == MAP_FAILED) err(1, \"mmap 1\"); unsigned char *p2 = mmap(ADDR2, SIZE, PROT_NONE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0); if (p2 == MAP_FAILED) err(1, \"mmap 2\"); *p1 = 0x41; printf(\"first char is 0x%02hhx\\n\", *p1); unsigned char *p3 = mremap(p1, SIZE, SIZE, MREMAP_MAYMOVE|MREMAP_FIXED, p2); if (p3 == MAP_FAILED) { printf(\"mremap() failed; first char is 0x%02hhx\\n\", *p1); } else { printf(\"mremap() succeeded; first char is 0x%02hhx\\n\", *p3); } } user@horn:~/big_mremap$ gcc -static -o test test.c user@horn:~/big_mremap$ setarch -R ./test first char is 0x41 mremap() failed; first char is 0x00 ``` With the patch: ``` user@horn:~/big_mremap$ setarch -R ./test first char is 0x41 mremap() succeeded; first char is 0x41 ```", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53107", "url": "https://ubuntu.com/security/CVE-2024-53107", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/proc/task_mmu: prevent integer overflow in pagemap_scan_get_args() The \"arg->vec_len\" variable is a u64 that comes from the user at the start of the function. The \"arg->vec_len * sizeof(struct page_region))\" multiplication can lead to integer wrapping. Use size_mul() to avoid that. Also the size_add/mul() functions work on unsigned long so for 32bit systems we need to ensure that \"arg->vec_len\" fits in an unsigned long.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53128", "url": "https://ubuntu.com/security/CVE-2024-53128", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/task_stack: fix object_is_on_stack() for KASAN tagged pointers When CONFIG_KASAN_SW_TAGS and CONFIG_KASAN_STACK are enabled, the object_is_on_stack() function may produce incorrect results due to the presence of tags in the obj pointer, while the stack pointer does not have tags. This discrepancy can lead to incorrect stack object detection and subsequently trigger warnings if CONFIG_DEBUG_OBJECTS is also enabled. Example of the warning: ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at lib/debugobjects.c:557 __debug_object_init+0x330/0x364 Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5 #4 Hardware name: linux,dummy-virt (DT) pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __debug_object_init+0x330/0x364 lr : __debug_object_init+0x330/0x364 sp : ffff800082ea7b40 x29: ffff800082ea7b40 x28: 98ff0000c0164518 x27: 98ff0000c0164534 x26: ffff800082d93ec8 x25: 0000000000000001 x24: 1cff0000c00172a0 x23: 0000000000000000 x22: ffff800082d93ed0 x21: ffff800081a24418 x20: 3eff800082ea7bb0 x19: efff800000000000 x18: 0000000000000000 x17: 00000000000000ff x16: 0000000000000047 x15: 206b63617473206e x14: 0000000000000018 x13: ffff800082ea7780 x12: 0ffff800082ea78e x11: 0ffff800082ea790 x10: 0ffff800082ea79d x9 : 34d77febe173e800 x8 : 34d77febe173e800 x7 : 0000000000000001 x6 : 0000000000000001 x5 : feff800082ea74b8 x4 : ffff800082870a90 x3 : ffff80008018d3c4 x2 : 0000000000000001 x1 : ffff800082858810 x0 : 0000000000000050 Call trace: __debug_object_init+0x330/0x364 debug_object_init_on_stack+0x30/0x3c schedule_hrtimeout_range_clock+0xac/0x26c schedule_hrtimeout+0x1c/0x30 wait_task_inactive+0x1d4/0x25c kthread_bind_mask+0x28/0x98 init_rescuer+0x1e8/0x280 workqueue_init+0x1a0/0x3cc kernel_init_freeable+0x118/0x200 kernel_init+0x28/0x1f0 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53112", "url": "https://ubuntu.com/security/CVE-2024-53112", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: uncache inode which has failed entering the group Syzbot has reported the following BUG: kernel BUG at fs/ocfs2/uptodate.c:509! ... Call Trace: ? __die_body+0x5f/0xb0 ? die+0x9e/0xc0 ? do_trap+0x15a/0x3a0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? do_error_trap+0x1dc/0x2c0 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? __pfx_do_error_trap+0x10/0x10 ? handle_invalid_op+0x34/0x40 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ? exc_invalid_op+0x38/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? ocfs2_set_new_buffer_uptodate+0x2e/0x160 ? ocfs2_set_new_buffer_uptodate+0x144/0x160 ? ocfs2_set_new_buffer_uptodate+0x145/0x160 ocfs2_group_add+0x39f/0x15a0 ? __pfx_ocfs2_group_add+0x10/0x10 ? __pfx_lock_acquire+0x10/0x10 ? mnt_get_write_access+0x68/0x2b0 ? __pfx_lock_release+0x10/0x10 ? rcu_read_lock_any_held+0xb7/0x160 ? __pfx_rcu_read_lock_any_held+0x10/0x10 ? smack_log+0x123/0x540 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x68/0x2b0 ? mnt_get_write_access+0x226/0x2b0 ocfs2_ioctl+0x65e/0x7d0 ? __pfx_ocfs2_ioctl+0x10/0x10 ? smack_file_ioctl+0x29e/0x3a0 ? __pfx_smack_file_ioctl+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x43d/0x780 ? __pfx_lockdep_hardirqs_on_prepare+0x10/0x10 ? __pfx_ocfs2_ioctl+0x10/0x10 __se_sys_ioctl+0xfb/0x170 do_syscall_64+0xf3/0x230 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... When 'ioctl(OCFS2_IOC_GROUP_ADD, ...)' has failed for the particular inode in 'ocfs2_verify_group_and_input()', corresponding buffer head remains cached and subsequent call to the same 'ioctl()' for the same inode issues the BUG() in 'ocfs2_set_new_buffer_uptodate()' (trying to cache the same buffer head of that inode). Fix this by uncaching the buffer head with 'ocfs2_remove_from_cache()' on error path in 'ocfs2_group_add()'.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53113", "url": "https://ubuntu.com/security/CVE-2024-53113", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: fix NULL pointer dereference in alloc_pages_bulk_noprof We triggered a NULL pointer dereference for ac.preferred_zoneref->zone in alloc_pages_bulk_noprof() when the task is migrated between cpusets. When cpuset is enabled, in prepare_alloc_pages(), ac->nodemask may be ¤t->mems_allowed. when first_zones_zonelist() is called to find preferred_zoneref, the ac->nodemask may be modified concurrently if the task is migrated between different cpusets. Assuming we have 2 NUMA Node, when traversing Node1 in ac->zonelist, the nodemask is 2, and when traversing Node2 in ac->zonelist, the nodemask is 1. As a result, the ac->preferred_zoneref points to NULL zone. In alloc_pages_bulk_noprof(), for_each_zone_zonelist_nodemask() finds a allowable zone and calls zonelist_node_idx(ac.preferred_zoneref), leading to NULL pointer dereference. __alloc_pages_noprof() fixes this issue by checking NULL pointer in commit ea57485af8f4 (\"mm, page_alloc: fix check for NULL preferred_zone\") and commit df76cee6bbeb (\"mm, page_alloc: remove redundant checks from alloc fastpath\"). To fix it, check NULL pointer for preferred_zoneref->zone.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53114", "url": "https://ubuntu.com/security/CVE-2024-53114", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 client A number of Zen4 client SoCs advertise the ability to use virtualized VMLOAD/VMSAVE, but using these instructions is reported to be a cause of a random host reboot. These instructions aren't intended to be advertised on Zen4 client so clear the capability.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53137", "url": "https://ubuntu.com/security/CVE-2024-53137", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: fix cacheflush with PAN It seems that the cacheflush syscall got broken when PAN for LPAE was implemented. User access was not enabled around the cache maintenance instructions, causing them to fault.", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53115", "url": "https://ubuntu.com/security/CVE-2024-53115", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: avoid null_ptr_deref in vmw_framebuffer_surface_create_handle The 'vmw_user_object_buffer' function may return NULL with incorrect inputs. To avoid possible null pointer dereference, add a check whether the 'bo' is NULL in the vmw_framebuffer_surface_create_handle.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53116", "url": "https://ubuntu.com/security/CVE-2024-53116", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix handling of partial GPU mapping of BOs This commit fixes the bug in the handling of partial mapping of the buffer objects to the GPU, which caused kernel warnings. Panthor didn't correctly handle the case where the partial mapping spanned multiple scatterlists and the mapping offset didn't point to the 1st page of starting scatterlist. The offset variable was not cleared after reaching the starting scatterlist. Following warning messages were seen. WARNING: CPU: 1 PID: 650 at drivers/iommu/io-pgtable-arm.c:659 __arm_lpae_unmap+0x254/0x5a0 pc : __arm_lpae_unmap+0x254/0x5a0 lr : __arm_lpae_unmap+0x2cc/0x5a0 Call trace: __arm_lpae_unmap+0x254/0x5a0 __arm_lpae_unmap+0x108/0x5a0 __arm_lpae_unmap+0x108/0x5a0 __arm_lpae_unmap+0x108/0x5a0 arm_lpae_unmap_pages+0x80/0xa0 panthor_vm_unmap_pages+0xac/0x1c8 [panthor] panthor_gpuva_sm_step_unmap+0x4c/0xc8 [panthor] op_unmap_cb.isra.23.constprop.30+0x54/0x80 __drm_gpuvm_sm_unmap+0x184/0x1c8 drm_gpuvm_sm_unmap+0x40/0x60 panthor_vm_exec_op+0xa8/0x120 [panthor] panthor_vm_bind_exec_sync_op+0xc4/0xe8 [panthor] panthor_ioctl_vm_bind+0x10c/0x170 [panthor] drm_ioctl_kernel+0xbc/0x138 drm_ioctl+0x210/0x4b0 __arm64_sys_ioctl+0xb0/0xf8 invoke_syscall+0x4c/0x110 el0_svc_common.constprop.1+0x98/0xf8 do_el0_svc+0x24/0x38 el0_svc+0x34/0xc8 el0t_64_sync_handler+0xa0/0xc8 el0t_64_sync+0x174/0x178 panthor : [drm] drm_WARN_ON(unmapped_sz != pgsize * pgcount) WARNING: CPU: 1 PID: 650 at drivers/gpu/drm/panthor/panthor_mmu.c:922 panthor_vm_unmap_pages+0x124/0x1c8 [panthor] pc : panthor_vm_unmap_pages+0x124/0x1c8 [panthor] lr : panthor_vm_unmap_pages+0x124/0x1c8 [panthor] panthor : [drm] *ERROR* failed to unmap range ffffa388f000-ffffa3890000 (requested range ffffa388c000-ffffa3890000)", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53117", "url": "https://ubuntu.com/security/CVE-2024-53117", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio/vsock: Improve MSG_ZEROCOPY error handling Add a missing kfree_skb() to prevent memory leaks.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53118", "url": "https://ubuntu.com/security/CVE-2024-53118", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vsock: Fix sk_error_queue memory leak Kernel queues MSG_ZEROCOPY completion notifications on the error queue. Where they remain, until explicitly recv()ed. To prevent memory leaks, clean up the queue when the socket is destroyed. unreferenced object 0xffff8881028beb00 (size 224): comm \"vsock_test\", pid 1218, jiffies 4294694897 hex dump (first 32 bytes): 90 b0 21 17 81 88 ff ff 90 b0 21 17 81 88 ff ff ..!.......!..... 00 00 00 00 00 00 00 00 00 b0 21 17 81 88 ff ff ..........!..... backtrace (crc 6c7031ca): [] kmem_cache_alloc_node_noprof+0x2f7/0x370 [] __alloc_skb+0x132/0x180 [] sock_omalloc+0x4b/0x80 [] msg_zerocopy_realloc+0x9e/0x240 [] virtio_transport_send_pkt_info+0x412/0x4c0 [] virtio_transport_stream_enqueue+0x43/0x50 [] vsock_connectible_sendmsg+0x373/0x450 [] ____sys_sendmsg+0x365/0x3a0 [] ___sys_sendmsg+0x84/0xd0 [] __sys_sendmsg+0x47/0x80 [] do_syscall_64+0x93/0x180 [] entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53119", "url": "https://ubuntu.com/security/CVE-2024-53119", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio/vsock: Fix accept_queue memory leak As the final stages of socket destruction may be delayed, it is possible that virtio_transport_recv_listen() will be called after the accept_queue has been flushed, but before the SOCK_DONE flag has been set. As a result, sockets enqueued after the flush would remain unremoved, leading to a memory leak. vsock_release __vsock_release lock virtio_transport_release virtio_transport_close schedule_delayed_work(close_work) sk_shutdown = SHUTDOWN_MASK (!) flush accept_queue release virtio_transport_recv_pkt vsock_find_bound_socket lock if flag(SOCK_DONE) return virtio_transport_recv_listen child = vsock_create_connected (!) vsock_enqueue_accept(child) release close_work lock virtio_transport_do_close set_flag(SOCK_DONE) virtio_transport_remove_sock vsock_remove_sock vsock_remove_bound release Introduce a sk_shutdown check to disallow vsock_enqueue_accept() during socket destruction. unreferenced object 0xffff888109e3f800 (size 2040): comm \"kworker/5:2\", pid 371, jiffies 4294940105 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00 (..@............ backtrace (crc 9e5f4e84): [] kmem_cache_alloc_noprof+0x2c1/0x360 [] sk_prot_alloc+0x30/0x120 [] sk_alloc+0x2c/0x4b0 [] __vsock_create.constprop.0+0x2a/0x310 [] virtio_transport_recv_pkt+0x4dc/0x9a0 [] vsock_loopback_work+0xfd/0x140 [] process_one_work+0x20c/0x570 [] worker_thread+0x1bf/0x3a0 [] kthread+0xdd/0x110 [] ret_from_fork+0x2d/0x50 [] ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53120", "url": "https://ubuntu.com/security/CVE-2024-53120", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: CT: Fix null-ptr-deref in add rule err flow In error flow of mlx5_tc_ct_entry_add_rule(), in case ct_rule_add() callback returns error, zone_rule->attr is used uninitiated. Fix it to use attr which has the needed pointer value. Kernel log: BUG: kernel NULL pointer dereference, address: 0000000000000110 RIP: 0010:mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core] … Call Trace: ? __die+0x20/0x70 ? page_fault_oops+0x150/0x3e0 ? exc_page_fault+0x74/0x140 ? asm_exc_page_fault+0x22/0x30 ? mlx5_tc_ct_entry_add_rule+0x2b1/0x2f0 [mlx5_core] ? mlx5_tc_ct_entry_add_rule+0x1d5/0x2f0 [mlx5_core] mlx5_tc_ct_block_flow_offload+0xc6a/0xf90 [mlx5_core] ? nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] nf_flow_offload_tuple+0xd8/0x190 [nf_flow_table] flow_offload_work_handler+0x142/0x320 [nf_flow_table] ? finish_task_switch.isra.0+0x15b/0x2b0 process_one_work+0x16c/0x320 worker_thread+0x28c/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xb8/0xf0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53138", "url": "https://ubuntu.com/security/CVE-2024-53138", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: kTLS, Fix incorrect page refcounting The kTLS tx handling code is using a mix of get_page() and page_ref_inc() APIs to increment the page reference. But on the release path (mlx5e_ktls_tx_handle_resync_dump_comp()), only put_page() is used. This is an issue when using pages from large folios: the get_page() references are stored on the folio page while the page_ref_inc() references are stored directly in the given page. On release the folio page will be dereferenced too many times. This was found while doing kTLS testing with sendfile() + ZC when the served file was read from NFS on a kernel with NFS large folios support (commit 49b29a573da8 (\"nfs: add support for large folios\")).", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53121", "url": "https://ubuntu.com/security/CVE-2024-53121", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: fs, lock FTE when checking if active The referenced commits introduced a two-step process for deleting FTEs: - Lock the FTE, delete it from hardware, set the hardware deletion function to NULL and unlock the FTE. - Lock the parent flow group, delete the software copy of the FTE, and remove it from the xarray. However, this approach encounters a race condition if a rule with the same match value is added simultaneously. In this scenario, fs_core may set the hardware deletion function to NULL prematurely, causing a panic during subsequent rule deletions. To prevent this, ensure the active flag of the FTE is checked under a lock, which will prevent the fs_core layer from attaching a new steering rule to an FTE that is in the process of deletion. [ 438.967589] MOSHE: 2496 mlx5_del_flow_rules del_hw_func [ 438.968205] ------------[ cut here ]------------ [ 438.968654] refcount_t: decrement hit 0; leaking memory. [ 438.969249] WARNING: CPU: 0 PID: 8957 at lib/refcount.c:31 refcount_warn_saturate+0xfb/0x110 [ 438.970054] Modules linked in: act_mirred cls_flower act_gact sch_ingress openvswitch nsh mlx5_vdpa vringh vhost_iotlb vdpa mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core zram zsmalloc fuse [last unloaded: cls_flower] [ 438.973288] CPU: 0 UID: 0 PID: 8957 Comm: tc Not tainted 6.12.0-rc1+ #8 [ 438.973888] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 438.974874] RIP: 0010:refcount_warn_saturate+0xfb/0x110 [ 438.975363] Code: 40 66 3b 82 c6 05 16 e9 4d 01 01 e8 1f 7c a0 ff 0f 0b c3 cc cc cc cc 48 c7 c7 10 66 3b 82 c6 05 fd e8 4d 01 01 e8 05 7c a0 ff <0f> 0b c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 90 [ 438.976947] RSP: 0018:ffff888124a53610 EFLAGS: 00010286 [ 438.977446] RAX: 0000000000000000 RBX: ffff888119d56de0 RCX: 0000000000000000 [ 438.978090] RDX: ffff88852c828700 RSI: ffff88852c81b3c0 RDI: ffff88852c81b3c0 [ 438.978721] RBP: ffff888120fa0e88 R08: 0000000000000000 R09: ffff888124a534b0 [ 438.979353] R10: 0000000000000001 R11: 0000000000000001 R12: ffff888119d56de0 [ 438.979979] R13: ffff888120fa0ec0 R14: ffff888120fa0ee8 R15: ffff888119d56de0 [ 438.980607] FS: 00007fe6dcc0f800(0000) GS:ffff88852c800000(0000) knlGS:0000000000000000 [ 438.983984] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 438.984544] CR2: 00000000004275e0 CR3: 0000000186982001 CR4: 0000000000372eb0 [ 438.985205] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 438.985842] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 438.986507] Call Trace: [ 438.986799] [ 438.987070] ? __warn+0x7d/0x110 [ 438.987426] ? refcount_warn_saturate+0xfb/0x110 [ 438.987877] ? report_bug+0x17d/0x190 [ 438.988261] ? prb_read_valid+0x17/0x20 [ 438.988659] ? handle_bug+0x53/0x90 [ 438.989054] ? exc_invalid_op+0x14/0x70 [ 438.989458] ? asm_exc_invalid_op+0x16/0x20 [ 438.989883] ? refcount_warn_saturate+0xfb/0x110 [ 438.990348] mlx5_del_flow_rules+0x2f7/0x340 [mlx5_core] [ 438.990932] __mlx5_eswitch_del_rule+0x49/0x170 [mlx5_core] [ 438.991519] ? mlx5_lag_is_sriov+0x3c/0x50 [mlx5_core] [ 438.992054] ? xas_load+0x9/0xb0 [ 438.992407] mlx5e_tc_rule_unoffload+0x45/0xe0 [mlx5_core] [ 438.993037] mlx5e_tc_del_fdb_flow+0x2a6/0x2e0 [mlx5_core] [ 438.993623] mlx5e_flow_put+0x29/0x60 [mlx5_core] [ 438.994161] mlx5e_delete_flower+0x261/0x390 [mlx5_core] [ 438.994728] tc_setup_cb_destroy+0xb9/0x190 [ 438.995150] fl_hw_destroy_filter+0x94/0xc0 [cls_flower] [ 438.995650] fl_change+0x11a4/0x13c0 [cls_flower] [ 438.996105] tc_new_tfilter+0x347/0xbc0 [ 438.996503] ? __ ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53122", "url": "https://ubuntu.com/security/CVE-2024-53122", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: cope racing subflow creation in mptcp_rcv_space_adjust Additional active subflows - i.e. created by the in kernel path manager - are included into the subflow list before starting the 3whs. A racing recvmsg() spooling data received on an already established subflow would unconditionally call tcp_cleanup_rbuf() on all the current subflows, potentially hitting a divide by zero error on the newly created ones. Explicitly check that the subflow is in a suitable state before invoking tcp_cleanup_rbuf().", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53123", "url": "https://ubuntu.com/security/CVE-2024-53123", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: error out earlier on disconnect Eric reported a division by zero splat in the MPTCP protocol: Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 6094 Comm: syz-executor317 Not tainted 6.12.0-rc5-syzkaller-00291-g05b92660cdfe #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:__tcp_select_window+0x5b4/0x1310 net/ipv4/tcp_output.c:3163 Code: f6 44 01 e3 89 df e8 9b 75 09 f8 44 39 f3 0f 8d 11 ff ff ff e8 0d 74 09 f8 45 89 f4 e9 04 ff ff ff e8 00 74 09 f8 44 89 f0 99 7c 24 14 41 29 d6 45 89 f4 e9 ec fe ff ff e8 e8 73 09 f8 48 89 RSP: 0018:ffffc900041f7930 EFLAGS: 00010293 RAX: 0000000000017e67 RBX: 0000000000017e67 RCX: ffffffff8983314b RDX: 0000000000000000 RSI: ffffffff898331b0 RDI: 0000000000000004 RBP: 00000000005d6000 R08: 0000000000000004 R09: 0000000000017e67 R10: 0000000000003e80 R11: 0000000000000000 R12: 0000000000003e80 R13: ffff888031d9b440 R14: 0000000000017e67 R15: 00000000002eb000 FS: 00007feb5d7f16c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007feb5d8adbb8 CR3: 0000000074e4c000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __tcp_cleanup_rbuf+0x3e7/0x4b0 net/ipv4/tcp.c:1493 mptcp_rcv_space_adjust net/mptcp/protocol.c:2085 [inline] mptcp_recvmsg+0x2156/0x2600 net/mptcp/protocol.c:2289 inet_recvmsg+0x469/0x6a0 net/ipv4/af_inet.c:885 sock_recvmsg_nosec net/socket.c:1051 [inline] sock_recvmsg+0x1b2/0x250 net/socket.c:1073 __sys_recvfrom+0x1a5/0x2e0 net/socket.c:2265 __do_sys_recvfrom net/socket.c:2283 [inline] __se_sys_recvfrom net/socket.c:2279 [inline] __x64_sys_recvfrom+0xe0/0x1c0 net/socket.c:2279 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 RIP: 0033:0x7feb5d857559 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:00007feb5d7f1208 EFLAGS: 00000246 ORIG_RAX: 000000000000002d RAX: ffffffffffffffda RBX: 00007feb5d8e1318 RCX: 00007feb5d857559 RDX: 000000800000000e RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007feb5d8e1310 R08: 0000000000000000 R09: ffffffff81000000 R10: 0000000000000100 R11: 0000000000000246 R12: 00007feb5d8e131c R13: 00007feb5d8ae074 R14: 000000800000000e R15: 00000000fffffdef and provided a nice reproducer. The root cause is the current bad handling of racing disconnect. After the blamed commit below, sk_wait_data() can return (with error) with the underlying socket disconnected and a zero rcv_mss. Catch the error and return without performing any additional operations on the current socket.", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53124", "url": "https://ubuntu.com/security/CVE-2024-53124", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix data-races around sk->sk_forward_alloc Syzkaller reported this warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 16 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x1c5/0x1e0 Modules linked in: CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:inet_sock_destruct+0x1c5/0x1e0 Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 <0f> 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00 RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206 RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007 RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00 RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007 R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00 R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78 FS: 0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn+0x88/0x130 ? inet_sock_destruct+0x1c5/0x1e0 ? report_bug+0x18e/0x1a0 ? handle_bug+0x53/0x90 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? inet_sock_destruct+0x1c5/0x1e0 __sk_destruct+0x2a/0x200 rcu_do_batch+0x1aa/0x530 ? rcu_do_batch+0x13b/0x530 rcu_core+0x159/0x2f0 handle_softirqs+0xd3/0x2b0 ? __pfx_smpboot_thread_fn+0x10/0x10 run_ksoftirqd+0x25/0x30 smpboot_thread_fn+0xdd/0x1d0 kthread+0xd3/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ---[ end trace 0000000000000000 ]--- Its possible that two threads call tcp_v6_do_rcv()/sk_forward_alloc_add() concurrently when sk->sk_state == TCP_LISTEN with sk->sk_lock unlocked, which triggers a data-race around sk->sk_forward_alloc: tcp_v6_rcv tcp_v6_do_rcv skb_clone_and_charge_r sk_rmem_schedule __sk_mem_schedule sk_forward_alloc_add() skb_set_owner_r sk_mem_charge sk_forward_alloc_add() __kfree_skb skb_release_all skb_release_head_state sock_rfree sk_mem_uncharge sk_forward_alloc_add() sk_mem_reclaim // set local var reclaimable __sk_mem_reclaim sk_forward_alloc_add() In this syzkaller testcase, two threads call tcp_v6_do_rcv() with skb->truesize=768, the sk_forward_alloc changes like this: (cpu 1) | (cpu 2) | sk_forward_alloc ... | ... | 0 __sk_mem_schedule() | | +4096 = 4096 | __sk_mem_schedule() | +4096 = 8192 sk_mem_charge() | | -768 = 7424 | sk_mem_charge() | -768 = 6656 ... | ... | sk_mem_uncharge() | | +768 = 7424 reclaimable=7424 | | | sk_mem_uncharge() | +768 = 8192 | reclaimable=8192 | __sk_mem_reclaim() | | -4096 = 4096 | __sk_mem_reclaim() | -8192 = -4096 != 0 The skb_clone_and_charge_r() should not be called in tcp_v6_do_rcv() when sk->sk_state is TCP_LISTEN, it happens later in tcp_v6_syn_recv_sock(). Fix the same issue in dccp_v6_do_rcv().", "cve_priority": "medium", "cve_public_date": "2024-12-02 14:15:00 UTC" }, { "cve": "CVE-2024-53129", "url": "https://ubuntu.com/security/CVE-2024-53129", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/rockchip: vop: Fix a dereferenced before check warning The 'state' can't be NULL, we should check crtc_state. Fix warning: drivers/gpu/drm/rockchip/rockchip_drm_vop.c:1096 vop_plane_atomic_async_check() warn: variable dereferenced before check 'state' (see line 1077)", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53139", "url": "https://ubuntu.com/security/CVE-2024-53139", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: fix possible UAF in sctp_v6_available() A lockdep report [1] with CONFIG_PROVE_RCU_LIST=y hints that sctp_v6_available() is calling dev_get_by_index_rcu() and ipv6_chk_addr() without holding rcu. [1] ============================= WARNING: suspicious RCU usage 6.12.0-rc5-virtme #1216 Tainted: G W ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by sctp_hello/31495: #0: ffff9f1ebbdb7418 (sk_lock-AF_INET6){+.+.}-{0:0}, at: sctp_bind (./arch/x86/include/asm/jump_label.h:27 net/sctp/socket.c:315) sctp stack backtrace: CPU: 7 UID: 0 PID: 31495 Comm: sctp_hello Tainted: G W 6.12.0-rc5-virtme #1216 Tainted: [W]=WARN 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:123) lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822) dev_get_by_index_rcu (net/core/dev.c:876 (discriminator 7)) sctp_v6_available (net/sctp/ipv6.c:701) sctp sctp_do_bind (net/sctp/socket.c:400 (discriminator 1)) sctp sctp_bind (net/sctp/socket.c:320) sctp inet6_bind_sk (net/ipv6/af_inet6.c:465) ? security_socket_bind (security/security.c:4581 (discriminator 1)) __sys_bind (net/socket.c:1848 net/socket.c:1869) ? do_user_addr_fault (./include/linux/rcupdate.h:347 ./include/linux/rcupdate.h:880 ./include/linux/mm.h:729 arch/x86/mm/fault.c:1340) ? do_user_addr_fault (./arch/x86/include/asm/preempt.h:84 (discriminator 13) ./include/linux/rcupdate.h:98 (discriminator 13) ./include/linux/rcupdate.h:882 (discriminator 13) ./include/linux/mm.h:729 (discriminator 13) arch/x86/mm/fault.c:1340 (discriminator 13)) __x64_sys_bind (net/socket.c:1877 (discriminator 1) net/socket.c:1875 (discriminator 1) net/socket.c:1875 (discriminator 1)) do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f59b934a1e7 Code: 44 00 00 48 8b 15 39 8c 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 b8 31 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 09 8c 0c 00 f7 d8 64 89 01 48 All code ======== 0:\t44 00 00 \tadd %r8b,(%rax) 3:\t48 8b 15 39 8c 0c 00 \tmov 0xc8c39(%rip),%rdx # 0xc8c43 a:\tf7 d8 \tneg %eax c:\t64 89 02 \tmov %eax,%fs:(%rdx) f:\tb8 ff ff ff ff \tmov $0xffffffff,%eax 14:\teb bd \tjmp 0xffffffffffffffd3 16:\t66 2e 0f 1f 84 00 00 \tcs nopw 0x0(%rax,%rax,1) 1d:\t00 00 00 20:\t0f 1f 00 \tnopl (%rax) 23:\tb8 31 00 00 00 \tmov $0x31,%eax 28:\t0f 05 \tsyscall 2a:*\t48 3d 01 f0 ff ff \tcmp $0xfffffffffffff001,%rax\t\t<-- trapping instruction 30:\t73 01 \tjae 0x33 32:\tc3 \tret 33:\t48 8b 0d 09 8c 0c 00 \tmov 0xc8c09(%rip),%rcx # 0xc8c43 3a:\tf7 d8 \tneg %eax 3c:\t64 89 01 \tmov %eax,%fs:(%rcx) 3f:\t48 \trex.W Code starting with the faulting instruction =========================================== 0:\t48 3d 01 f0 ff ff \tcmp $0xfffffffffffff001,%rax 6:\t73 01 \tjae 0x9 8:\tc3 \tret 9:\t48 8b 0d 09 8c 0c 00 \tmov 0xc8c09(%rip),%rcx # 0xc8c19 10:\tf7 d8 \tneg %eax 12:\t64 89 01 \tmov %eax,%fs:(%rcx) 15:\t48 \trex.W RSP: 002b:00007ffe2d0ad398 EFLAGS: 00000202 ORIG_RAX: 0000000000000031 RAX: ffffffffffffffda RBX: 00007ffe2d0ad3d0 RCX: 00007f59b934a1e7 RDX: 000000000000001c RSI: 00007ffe2d0ad3d0 RDI: 0000000000000005 RBP: 0000000000000005 R08: 1999999999999999 R09: 0000000000000000 R10: 00007f59b9253298 R11: 000000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53140", "url": "https://ubuntu.com/security/CVE-2024-53140", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netlink: terminate outstanding dump on socket close Netlink supports iterative dumping of data. It provides the families the following ops: - start - (optional) kicks off the dumping process - dump - actual dump helper, keeps getting called until it returns 0 - done - (optional) pairs with .start, can be used for cleanup The whole process is asynchronous and the repeated calls to .dump don't actually happen in a tight loop, but rather are triggered in response to recvmsg() on the socket. This gives the user full control over the dump, but also means that the user can close the socket without getting to the end of the dump. To make sure .start is always paired with .done we check if there is an ongoing dump before freeing the socket, and if so call .done. The complication is that sockets can get freed from BH and .done is allowed to sleep. So we use a workqueue to defer the call, when needed. Unfortunately this does not work correctly. What we defer is not the cleanup but rather releasing a reference on the socket. We have no guarantee that we own the last reference, if someone else holds the socket they may release it in BH and we're back to square one. The whole dance, however, appears to be unnecessary. Only the user can interact with dumps, so we can clean up when socket is closed. And close always happens in process context. Some async code may still access the socket after close, queue notification skbs to it etc. but no dumps can start, end or otherwise make progress. Delete the workqueue and flush the dump state directly from the release handler. Note that further cleanup is possible in -next, for instance we now always call .done before releasing the main module reference, so dump doesn't have to take a reference of its own.", "cve_priority": "high", "cve_public_date": "2024-12-04 15:15:00 UTC" }, { "cve": "CVE-2024-53098", "url": "https://ubuntu.com/security/CVE-2024-53098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/ufence: Prefetch ufence addr to catch bogus address access_ok() only checks for addr overflow so also try to read the addr to catch invalid addr sent from userspace. (cherry picked from commit 9408c4508483ffc60811e910a93d6425b8e63928)", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53099", "url": "https://ubuntu.com/security/CVE-2024-53099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check validity of link->type in bpf_link_show_fdinfo() If a newly-added link type doesn't invoke BPF_LINK_TYPE(), accessing bpf_link_type_strs[link->type] may result in an out-of-bounds access. To spot such missed invocations early in the future, checking the validity of link->type in bpf_link_show_fdinfo() and emitting a warning when such invocations are missed.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53089", "url": "https://ubuntu.com/security/CVE-2024-53089", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: LoongArch: KVM: Mark hrtimer to expire in hard interrupt context Like commit 2c0d278f3293f (\"KVM: LAPIC: Mark hrtimer to expire in hard interrupt context\") and commit 9090825fa9974 (\"KVM: arm/arm64: Let the timer expire in hardirq context on RT\"), On PREEMPT_RT enabled kernels unmarked hrtimers are moved into soft interrupt expiry mode by default. Then the timers are canceled from an preempt-notifier which is invoked with disabled preemption which is not allowed on PREEMPT_RT. The timer callback is short so in could be invoked in hard-IRQ context. So let the timer expire on hard-IRQ context even on -RT. This fix a \"scheduling while atomic\" bug for PREEMPT_RT enabled kernels: BUG: scheduling while atomic: qemu-system-loo/1011/0x00000002 Modules linked in: amdgpu rfkill nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat ns CPU: 1 UID: 0 PID: 1011 Comm: qemu-system-loo Tainted: G W 6.12.0-rc2+ #1774 Tainted: [W]=WARN Hardware name: Loongson Loongson-3A5000-7A1000-1w-CRB/Loongson-LS3A5000-7A1000-1w-CRB, BIOS vUDK2018-LoongArch-V2.0.0-prebeta9 10/21/2022 Stack : ffffffffffffffff 0000000000000000 9000000004e3ea38 9000000116744000 90000001167475a0 0000000000000000 90000001167475a8 9000000005644830 90000000058dc000 90000000058dbff8 9000000116747420 0000000000000001 0000000000000001 6a613fc938313980 000000000790c000 90000001001c1140 00000000000003fe 0000000000000001 000000000000000d 0000000000000003 0000000000000030 00000000000003f3 000000000790c000 9000000116747830 90000000057ef000 0000000000000000 9000000005644830 0000000000000004 0000000000000000 90000000057f4b58 0000000000000001 9000000116747868 900000000451b600 9000000005644830 9000000003a13998 0000000010000020 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d ... Call Trace: [<9000000003a13998>] show_stack+0x38/0x180 [<9000000004e3ea34>] dump_stack_lvl+0x84/0xc0 [<9000000003a71708>] __schedule_bug+0x48/0x60 [<9000000004e45734>] __schedule+0x1114/0x1660 [<9000000004e46040>] schedule_rtlock+0x20/0x60 [<9000000004e4e330>] rtlock_slowlock_locked+0x3f0/0x10a0 [<9000000004e4f038>] rt_spin_lock+0x58/0x80 [<9000000003b02d68>] hrtimer_cancel_wait_running+0x68/0xc0 [<9000000003b02e30>] hrtimer_cancel+0x70/0x80 [] kvm_restore_timer+0x50/0x1a0 [kvm] [] kvm_arch_vcpu_load+0x68/0x2a0 [kvm] [] kvm_sched_in+0x34/0x60 [kvm] [<9000000003a749a0>] finish_task_switch.isra.0+0x140/0x2e0 [<9000000004e44a70>] __schedule+0x450/0x1660 [<9000000004e45cb0>] schedule+0x30/0x180 [] kvm_vcpu_block+0x70/0x120 [kvm] [] kvm_vcpu_halt+0x60/0x3e0 [kvm] [] kvm_handle_gspr+0x3f4/0x4e0 [kvm] [] kvm_handle_exit+0x1c8/0x260 [kvm]", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53090", "url": "https://ubuntu.com/security/CVE-2024-53090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix lock recursion afs_wake_up_async_call() can incur lock recursion. The problem is that it is called from AF_RXRPC whilst holding the ->notify_lock, but it tries to take a ref on the afs_call struct in order to pass it to a work queue - but if the afs_call is already queued, we then have an extraneous ref that must be put... calling afs_put_call() may call back down into AF_RXRPC through rxrpc_kernel_shutdown_call(), however, which might try taking the ->notify_lock again. This case isn't very common, however, so defer it to a workqueue. The oops looks something like: BUG: spinlock recursion on CPU#0, krxrpcio/7001/1646 lock: 0xffff888141399b30, .magic: dead4ead, .owner: krxrpcio/7001/1646, .owner_cpu: 0 CPU: 0 UID: 0 PID: 1646 Comm: krxrpcio/7001 Not tainted 6.12.0-rc2-build3+ #4351 Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014 Call Trace: dump_stack_lvl+0x47/0x70 do_raw_spin_lock+0x3c/0x90 rxrpc_kernel_shutdown_call+0x83/0xb0 afs_put_call+0xd7/0x180 rxrpc_notify_socket+0xa0/0x190 rxrpc_input_split_jumbo+0x198/0x1d0 rxrpc_input_data+0x14b/0x1e0 ? rxrpc_input_call_packet+0xc2/0x1f0 rxrpc_input_call_event+0xad/0x6b0 rxrpc_input_packet_on_conn+0x1e1/0x210 rxrpc_input_packet+0x3f2/0x4d0 rxrpc_io_thread+0x243/0x410 ? __pfx_rxrpc_io_thread+0x10/0x10 kthread+0xcf/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x24/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53101", "url": "https://ubuntu.com/security/CVE-2024-53101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs: Fix uninitialized value issue in from_kuid and from_kgid ocfs2_setattr() uses attr->ia_mode, attr->ia_uid and attr->ia_gid in a trace point even though ATTR_MODE, ATTR_UID and ATTR_GID aren't set. Initialize all fields of newattrs to avoid uninitialized variables, by checking if ATTR_MODE, ATTR_UID, ATTR_GID are initialized, otherwise 0.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53091", "url": "https://ubuntu.com/security/CVE-2024-53091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Add sk_is_inet and IS_ICSK check in tls_sw_has_ctx_tx/rx As the introduction of the support for vsock and unix sockets in sockmap, tls_sw_has_ctx_tx/rx cannot presume the socket passed in must be IS_ICSK. vsock and af_unix sockets have vsock_sock and unix_sock instead of inet_connection_sock. For these sockets, tls_get_ctx may return an invalid pointer and cause page fault in function tls_sw_ctx_rx. BUG: unable to handle page fault for address: 0000000000040030 Workqueue: vsock-loopback vsock_loopback_work RIP: 0010:sk_psock_strp_data_ready+0x23/0x60 Call Trace: ? __die+0x81/0xc3 ? no_context+0x194/0x350 ? do_page_fault+0x30/0x110 ? async_page_fault+0x3e/0x50 ? sk_psock_strp_data_ready+0x23/0x60 virtio_transport_recv_pkt+0x750/0x800 ? update_load_avg+0x7e/0x620 vsock_loopback_work+0xd0/0x100 process_one_work+0x1a7/0x360 worker_thread+0x30/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x112/0x130 ? __kthread_cancel_work+0x40/0x40 ret_from_fork+0x1f/0x40 v2: - Add IS_ICSK check v3: - Update the commits in Fixes", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53092", "url": "https://ubuntu.com/security/CVE-2024-53092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_pci: Fix admin vq cleanup by using correct info pointer vp_modern_avq_cleanup() and vp_del_vqs() clean up admin vq resources by virtio_pci_vq_info pointer. The info pointer of admin vq is stored in vp_dev->admin_vq.info instead of vp_dev->vqs[]. Using the info pointer from vp_dev->vqs[] for admin vq causes a kernel NULL pointer dereference bug. In vp_modern_avq_cleanup() and vp_del_vqs(), get the info pointer from vp_dev->admin_vq.info for admin vq to clean up the resources. Also make info ptr as argument of vp_del_vq() to be symmetric with vp_setup_vq(). vp_reset calls vp_modern_avq_cleanup, and causes the Call Trace: ================================================================== BUG: kernel NULL pointer dereference, address:0000000000000000 ... CPU: 49 UID: 0 PID: 4439 Comm: modprobe Not tainted 6.11.0-rc5 #1 RIP: 0010:vp_reset+0x57/0x90 [virtio_pci] Call Trace: ... ? vp_reset+0x57/0x90 [virtio_pci] ? vp_reset+0x38/0x90 [virtio_pci] virtio_reset_device+0x1d/0x30 remove_vq_common+0x1c/0x1a0 [virtio_net] virtnet_remove+0xa1/0xc0 [virtio_net] virtio_dev_remove+0x46/0xa0 ... virtio_pci_driver_exit+0x14/0x810 [virtio_pci] ==================================================================", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53102", "url": "https://ubuntu.com/security/CVE-2024-53102", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53093", "url": "https://ubuntu.com/security/CVE-2024-53093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme-multipath: defer partition scanning We need to suppress the partition scan from occuring within the controller's scan_work context. If a path error occurs here, the IO will wait until a path becomes available or all paths are torn down, but that action also occurs within scan_work, so it would deadlock. Defer the partion scan to a different context that does not block scan_work.", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53094", "url": "https://ubuntu.com/security/CVE-2024-53094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Add sendpage_ok() check to disable MSG_SPLICE_PAGES While running ISER over SIW, the initiator machine encounters a warning from skb_splice_from_iter() indicating that a slab page is being used in send_page. To address this, it is better to add a sendpage_ok() check within the driver itself, and if it returns 0, then MSG_SPLICE_PAGES flag should be disabled before entering the network stack. A similar issue has been discussed for NVMe in this thread: https://lore.kernel.org/all/20240530142417.146696-1-ofir.gal@volumez.com/ WARNING: CPU: 0 PID: 5342 at net/core/skbuff.c:7140 skb_splice_from_iter+0x173/0x320 Call Trace: tcp_sendmsg_locked+0x368/0xe40 siw_tx_hdt+0x695/0xa40 [siw] siw_qp_sq_process+0x102/0xb00 [siw] siw_sq_resume+0x39/0x110 [siw] siw_run_sq+0x74/0x160 [siw] kthread+0xd2/0x100 ret_from_fork+0x34/0x40 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-53100", "url": "https://ubuntu.com/security/CVE-2024-53100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvme: tcp: avoid race between queue_lock lock and destroy Commit 76d54bf20cdc (\"nvme-tcp: don't access released socket during error recovery\") added a mutex_lock() call for the queue->queue_lock in nvme_tcp_get_address(). However, the mutex_lock() races with mutex_destroy() in nvme_tcp_free_queue(), and causes the WARN below. DEBUG_LOCKS_WARN_ON(lock->magic != lock) WARNING: CPU: 3 PID: 34077 at kernel/locking/mutex.c:587 __mutex_lock+0xcf0/0x1220 Modules linked in: nvmet_tcp nvmet nvme_tcp nvme_fabrics iw_cm ib_cm ib_core pktcdvd nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables qrtr sunrpc ppdev 9pnet_virtio 9pnet pcspkr netfs parport_pc parport e1000 i2c_piix4 i2c_smbus loop fuse nfnetlink zram bochs drm_vram_helper drm_ttm_helper ttm drm_kms_helper xfs drm sym53c8xx floppy nvme scsi_transport_spi nvme_core nvme_auth serio_raw ata_generic pata_acpi dm_multipath qemu_fw_cfg [last unloaded: ib_uverbs] CPU: 3 UID: 0 PID: 34077 Comm: udisksd Not tainted 6.11.0-rc7 #319 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:__mutex_lock+0xcf0/0x1220 Code: 08 84 d2 0f 85 c8 04 00 00 8b 15 ef b6 c8 01 85 d2 0f 85 78 f4 ff ff 48 c7 c6 20 93 ee af 48 c7 c7 60 91 ee af e8 f0 a7 6d fd <0f> 0b e9 5e f4 ff ff 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 RSP: 0018:ffff88811305f760 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff88812c652058 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000001 RBP: ffff88811305f8b0 R08: 0000000000000001 R09: ffffed1075c36341 R10: ffff8883ae1b1a0b R11: 0000000000010498 R12: 0000000000000000 R13: 0000000000000000 R14: dffffc0000000000 R15: ffff88812c652058 FS: 00007f9713ae4980(0000) GS:ffff8883ae180000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcd78483c7c CR3: 0000000122c38000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn.cold+0x5b/0x1af ? __mutex_lock+0xcf0/0x1220 ? report_bug+0x1ec/0x390 ? handle_bug+0x3c/0x80 ? exc_invalid_op+0x13/0x40 ? asm_exc_invalid_op+0x16/0x20 ? __mutex_lock+0xcf0/0x1220 ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] ? __pfx___mutex_lock+0x10/0x10 ? __lock_acquire+0xd6a/0x59e0 ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp] ? __pfx_nvme_tcp_get_address+0x10/0x10 [nvme_tcp] nvme_sysfs_show_address+0x81/0xc0 [nvme_core] dev_attr_show+0x42/0x80 ? __asan_memset+0x1f/0x40 sysfs_kf_seq_show+0x1f0/0x370 seq_read_iter+0x2cb/0x1130 ? rw_verify_area+0x3b1/0x590 ? __mutex_lock+0x433/0x1220 vfs_read+0x6a6/0xa20 ? lockdep_hardirqs_on+0x78/0x100 ? __pfx_vfs_read+0x10/0x10 ksys_read+0xf7/0x1d0 ? __pfx_ksys_read+0x10/0x10 ? __x64_sys_openat+0x105/0x1d0 do_syscall_64+0x93/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? __pfx_ksys_read+0x10/0x10 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on_prepare+0x16d/0x400 ? do_syscall_64+0x9f/0x180 ? lockdep_hardirqs_on+0x78/0x100 ? do_syscall_64+0x9f/0x180 ? do_syscall_64+0x9f/0x180 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7f9713f55cfa Code: 55 48 89 e5 48 83 ec 20 48 89 55 e8 48 89 75 f0 89 7d f8 e8 e8 74 f8 ff 48 8b 55 e8 48 8b 75 f0 4 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-25 22:15:00 UTC" }, { "cve": "CVE-2024-53095", "url": "https://ubuntu.com/security/CVE-2024-53095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: smb: client: Fix use-after-free of network namespace. Recently, we got a customer report that CIFS triggers oops while reconnecting to a server. [0] The workload runs on Kubernetes, and some pods mount CIFS servers in non-root network namespaces. The problem rarely happened, but it was always while the pod was dying. The root cause is wrong reference counting for network namespace. CIFS uses kernel sockets, which do not hold refcnt of the netns that the socket belongs to. That means CIFS must ensure the socket is always freed before its netns; otherwise, use-after-free happens. The repro steps are roughly: 1. mount CIFS in a non-root netns 2. drop packets from the netns 3. destroy the netns 4. unmount CIFS We can reproduce the issue quickly with the script [1] below and see the splat [2] if CONFIG_NET_NS_REFCNT_TRACKER is enabled. When the socket is TCP, it is hard to guarantee the netns lifetime without holding refcnt due to async timers. Let's hold netns refcnt for each socket as done for SMC in commit 9744d2bf1976 (\"smc: Fix use-after-free in tcp_write_timer_handler().\"). Note that we need to move put_net() from cifs_put_tcp_session() to clean_demultiplex_info(); otherwise, __sock_create() still could touch a freed netns while cifsd tries to reconnect from cifs_demultiplex_thread(). Also, maybe_get_net() cannot be put just before __sock_create() because the code is not under RCU and there is a small chance that the same address happened to be reallocated to another netns. [0]: CIFS: VFS: \\\\XXXXXXXXXXX has not responded in 15 seconds. Reconnecting... CIFS: Serverclose failed 4 times, giving up Unable to handle kernel paging request at virtual address 14de99e461f84a07 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 CM = 0, WnR = 0 [14de99e461f84a07] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: cls_bpf sch_ingress nls_utf8 cifs cifs_arc4 cifs_md4 dns_resolver tcp_diag inet_diag veth xt_state xt_connmark nf_conntrack_netlink xt_nat xt_statistic xt_MASQUERADE xt_mark xt_addrtype ipt_REJECT nf_reject_ipv4 nft_chain_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment nft_compat nf_tables nfnetlink overlay nls_ascii nls_cp437 sunrpc vfat fat aes_ce_blk aes_ce_cipher ghash_ce sm4_ce_cipher sm4 sm3_ce sm3 sha3_ce sha512_ce sha512_arm64 sha1_ce ena button sch_fq_codel loop fuse configfs dmi_sysfs sha2_ce sha256_arm64 dm_mirror dm_region_hash dm_log dm_mod dax efivarfs CPU: 5 PID: 2690970 Comm: cifsd Not tainted 6.1.103-109.184.amzn2023.aarch64 #1 Hardware name: Amazon EC2 r7g.4xlarge/, BIOS 1.0 11/1/2018 pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : fib_rules_lookup+0x44/0x238 lr : __fib_lookup+0x64/0xbc sp : ffff8000265db790 x29: ffff8000265db790 x28: 0000000000000000 x27: 000000000000bd01 x26: 0000000000000000 x25: ffff000b4baf8000 x24: ffff00047b5e4580 x23: ffff8000265db7e0 x22: 0000000000000000 x21: ffff00047b5e4500 x20: ffff0010e3f694f8 x19: 14de99e461f849f7 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 3f92800abd010002 x11: 0000000000000001 x10: ffff0010e3f69420 x9 : ffff800008a6f294 x8 : 0000000000000000 x7 : 0000000000000006 x6 : 0000000000000000 x5 : 0000000000000001 x4 : ffff001924354280 x3 : ffff8000265db7e0 x2 : 0000000000000000 x1 : ffff0010e3f694f8 x0 : ffff00047b5e4500 Call trace: fib_rules_lookup+0x44/0x238 __fib_lookup+0x64/0xbc ip_route_output_key_hash_rcu+0x2c4/0x398 ip_route_output_key_hash+0x60/0x8c tcp_v4_connect+0x290/0x488 __inet_stream_connect+0x108/0x3d0 inet_stream_connect+0x50/0x78 kernel_connect+0x6c/0xac generic_ip_conne ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-21 19:15:00 UTC" }, { "cve": "CVE-2024-50265", "url": "https://ubuntu.com/security/CVE-2024-50265", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove entry once instead of null-ptr-dereference in ocfs2_xa_remove() Syzkaller is able to provoke null-ptr-dereference in ocfs2_xa_remove(): [ 57.319872] (a.out,1161,7):ocfs2_xa_remove:2028 ERROR: status = -12 [ 57.320420] (a.out,1161,7):ocfs2_xa_cleanup_value_truncate:1999 ERROR: Partial truncate while removing xattr overlay.upper. Leaking 1 clusters and removing the entry [ 57.321727] BUG: kernel NULL pointer dereference, address: 0000000000000004 [...] [ 57.325727] RIP: 0010:ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [...] [ 57.331328] Call Trace: [ 57.331477] [...] [ 57.333511] ? do_user_addr_fault+0x3e5/0x740 [ 57.333778] ? exc_page_fault+0x70/0x170 [ 57.334016] ? asm_exc_page_fault+0x2b/0x30 [ 57.334263] ? __pfx_ocfs2_xa_block_wipe_namevalue+0x10/0x10 [ 57.334596] ? ocfs2_xa_block_wipe_namevalue+0x2a/0xc0 [ 57.334913] ocfs2_xa_remove_entry+0x23/0xc0 [ 57.335164] ocfs2_xa_set+0x704/0xcf0 [ 57.335381] ? _raw_spin_unlock+0x1a/0x40 [ 57.335620] ? ocfs2_inode_cache_unlock+0x16/0x20 [ 57.335915] ? trace_preempt_on+0x1e/0x70 [ 57.336153] ? start_this_handle+0x16c/0x500 [ 57.336410] ? preempt_count_sub+0x50/0x80 [ 57.336656] ? _raw_read_unlock+0x20/0x40 [ 57.336906] ? start_this_handle+0x16c/0x500 [ 57.337162] ocfs2_xattr_block_set+0xa6/0x1e0 [ 57.337424] __ocfs2_xattr_set_handle+0x1fd/0x5d0 [ 57.337706] ? ocfs2_start_trans+0x13d/0x290 [ 57.337971] ocfs2_xattr_set+0xb13/0xfb0 [ 57.338207] ? dput+0x46/0x1c0 [ 57.338393] ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338665] ? ocfs2_xattr_trusted_set+0x28/0x30 [ 57.338948] __vfs_removexattr+0x92/0xc0 [ 57.339182] __vfs_removexattr_locked+0xd5/0x190 [ 57.339456] ? preempt_count_sub+0x50/0x80 [ 57.339705] vfs_removexattr+0x5f/0x100 [...] Reproducer uses faultinject facility to fail ocfs2_xa_remove() -> ocfs2_xa_value_truncate() with -ENOMEM. In this case the comment mentions that we can return 0 if ocfs2_xa_cleanup_value_truncate() is going to wipe the entry anyway. But the following 'rc' check is wrong and execution flow do 'ocfs2_xa_remove_entry(loc);' twice: * 1st: in ocfs2_xa_cleanup_value_truncate(); * 2nd: returning back to ocfs2_xa_remove() instead of going to 'out'. Fix this by skipping the 2nd removal of the same entry and making syzkaller repro happy.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50266", "url": "https://ubuntu.com/security/CVE-2024-50266", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: qcom: videocc-sm8350: use HW_CTRL_TRIGGER for vcodec GDSCs A recent change in the venus driver results in a stuck clock on the Lenovo ThinkPad X13s, for example, when streaming video in firefox: \tvideo_cc_mvs0_clk status stuck at 'off' \tWARNING: CPU: 6 PID: 2885 at drivers/clk/qcom/clk-branch.c:87 clk_branch_wait+0x144/0x15c \t... \tCall trace: \t clk_branch_wait+0x144/0x15c \t clk_branch2_enable+0x30/0x40 \t clk_core_enable+0xd8/0x29c \t clk_enable+0x2c/0x4c \t vcodec_clks_enable.isra.0+0x94/0xd8 [venus_core] \t coreid_power_v4+0x464/0x628 [venus_core] \t vdec_start_streaming+0xc4/0x510 [venus_dec] \t vb2_start_streaming+0x6c/0x180 [videobuf2_common] \t vb2_core_streamon+0x120/0x1dc [videobuf2_common] \t vb2_streamon+0x1c/0x6c [videobuf2_v4l2] \t v4l2_m2m_ioctl_streamon+0x30/0x80 [v4l2_mem2mem] \t v4l_streamon+0x24/0x30 [videodev] using the out-of-tree sm8350/sc8280xp venus support. [1] Update also the sm8350/sc8280xp GDSC definitions so that the hw control mode can be changed at runtime as the venus driver now requires.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50267", "url": "https://ubuntu.com/security/CVE-2024-50267", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: fix use after free in debug printk The \"dev_dbg(&urb->dev->dev, ...\" which happens after usb_free_urb(urb) is a use after free of the \"urb\" pointer. Store the \"dev\" pointer at the start of the function to avoid this issue.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50268", "url": "https://ubuntu.com/security/CVE-2024-50268", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: fix potential out of bounds in ucsi_ccg_update_set_new_cam_cmd() The \"*cmd\" variable can be controlled by the user via debugfs. That means \"new_cam\" can be as high as 255 while the size of the uc->updated[] array is UCSI_MAX_ALTMODES (30). The call tree is: ucsi_cmd() // val comes from simple_attr_write_xsigned() -> ucsi_send_command() -> ucsi_send_command_common() -> ucsi_run_command() // calls ucsi->ops->sync_control() -> ucsi_ccg_sync_control()", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53083", "url": "https://ubuntu.com/security/CVE-2024-53083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: qcom-pmic: init value of hdr_len/txbuf_len earlier If the read of USB_PDPHY_RX_ACKNOWLEDGE_REG failed, then hdr_len and txbuf_len are uninitialized. This commit stops to print uninitialized value and misleading/false data.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50269", "url": "https://ubuntu.com/security/CVE-2024-50269", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: musb: sunxi: Fix accessing an released usb phy Commit 6ed05c68cbca (\"usb: musb: sunxi: Explicitly release USB PHY on exit\") will cause that usb phy @glue->xceiv is accessed after released. 1) register platform driver @sunxi_musb_driver // get the usb phy @glue->xceiv sunxi_musb_probe() -> devm_usb_get_phy(). 2) register and unregister platform driver @musb_driver musb_probe() -> sunxi_musb_init() use the phy here //the phy is released here musb_remove() -> sunxi_musb_exit() -> devm_usb_put_phy() 3) register @musb_driver again musb_probe() -> sunxi_musb_init() use the phy here but the phy has been released at 2). ... Fixed by reverting the commit, namely, removing devm_usb_put_phy() from sunxi_musb_exit().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53079", "url": "https://ubuntu.com/security/CVE-2024-53079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/thp: fix deferred split unqueue naming and locking Recent changes are putting more pressure on THP deferred split queues: under load revealing long-standing races, causing list_del corruptions, \"Bad page state\"s and worse (I keep BUGs in both of those, so usually don't get to see how badly they end up without). The relevant recent changes being 6.8's mTHP, 6.10's mTHP swapout, and 6.12's mTHP swapin, improved swap allocation, and underused THP splitting. Before fixing locking: rename misleading folio_undo_large_rmappable(), which does not undo large_rmappable, to folio_unqueue_deferred_split(), which is what it does. But that and its out-of-line __callee are mm internals of very limited usability: add comment and WARN_ON_ONCEs to check usage; and return a bool to say if a deferred split was unqueued, which can then be used in WARN_ON_ONCEs around safety checks (sparing callers the arcane conditionals in __folio_unqueue_deferred_split()). Just omit the folio_unqueue_deferred_split() from free_unref_folios(), all of whose callers now call it beforehand (and if any forget then bad_page() will tell) - except for its caller put_pages_list(), which itself no longer has any callers (and will be deleted separately). Swapout: mem_cgroup_swapout() has been resetting folio->memcg_data 0 without checking and unqueueing a THP folio from deferred split list; which is unfortunate, since the split_queue_lock depends on the memcg (when memcg is enabled); so swapout has been unqueueing such THPs later, when freeing the folio, using the pgdat's lock instead: potentially corrupting the memcg's list. __remove_mapping() has frozen refcount to 0 here, so no problem with calling folio_unqueue_deferred_split() before resetting memcg_data. That goes back to 5.4 commit 87eaceb3faa5 (\"mm: thp: make deferred split shrinker memcg aware\"): which included a check on swapcache before adding to deferred queue, but no check on deferred queue before adding THP to swapcache. That worked fine with the usual sequence of events in reclaim (though there were a couple of rare ways in which a THP on deferred queue could have been swapped out), but 6.12 commit dafff3f4c850 (\"mm: split underused THPs\") avoids splitting underused THPs in reclaim, which makes swapcache THPs on deferred queue commonplace. Keep the check on swapcache before adding to deferred queue? Yes: it is no longer essential, but preserves the existing behaviour, and is likely to be a worthwhile optimization (vmstat showed much more traffic on the queue under swapping load if the check was removed); update its comment. Memcg-v1 move (deprecated): mem_cgroup_move_account() has been changing folio->memcg_data without checking and unqueueing a THP folio from the deferred list, sometimes corrupting \"from\" memcg's list, like swapout. Refcount is non-zero here, so folio_unqueue_deferred_split() can only be used in a WARN_ON_ONCE to validate the fix, which must be done earlier: mem_cgroup_move_charge_pte_range() first try to split the THP (splitting of course unqueues), or skip it if that fails. Not ideal, but moving charge has been requested, and khugepaged should repair the THP later: nobody wants new custom unqueueing code just for this deprecated case. The 87eaceb3faa5 commit did have the code to move from one deferred list to another (but was not conscious of its unsafety while refcount non-0); but that was removed by 5.6 commit fac0516b5534 (\"mm: thp: don't need care deferred split queue in memcg charge move path\"), which argued that the existence of a PMD mapping guarantees that the THP cannot be on a deferred list. As above, false in rare cases, and now commonly false. Backport to 6.11 should be straightforward. Earlier backports must take care that other _deferred_list fixes and dependencies are included. There is not a strong case for backports, but they can fix cornercases.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50270", "url": "https://ubuntu.com/security/CVE-2024-50270", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/core: avoid overflow in damon_feed_loop_next_input() damon_feed_loop_next_input() is inefficient and fragile to overflows. Specifically, 'score_goal_diff_bp' calculation can overflow when 'score' is high. The calculation is actually unnecessary at all because 'goal' is a constant of value 10,000. Calculation of 'compensation' is again fragile to overflow. Final calculation of return value for under-achiving case is again fragile to overflow when the current score is under-achieving the target. Add two corner cases handling at the beginning of the function to make the body easier to read, and rewrite the body of the function to avoid overflows and the unnecessary bp value calcuation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50271", "url": "https://ubuntu.com/security/CVE-2024-50271", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: signal: restore the override_rlimit logic Prior to commit d64696905554 (\"Reimplement RLIMIT_SIGPENDING on top of ucounts\") UCOUNT_RLIMIT_SIGPENDING rlimit was not enforced for a class of signals. However now it's enforced unconditionally, even if override_rlimit is set. This behavior change caused production issues. For example, if the limit is reached and a process receives a SIGSEGV signal, sigqueue_alloc fails to allocate the necessary resources for the signal delivery, preventing the signal from being delivered with siginfo. This prevents the process from correctly identifying the fault address and handling the error. From the user-space perspective, applications are unaware that the limit has been reached and that the siginfo is effectively 'corrupted'. This can lead to unpredictable behavior and crashes, as we observed with java applications. Fix this by passing override_rlimit into inc_rlimit_get_ucounts() and skip the comparison to max there if override_rlimit is set. This effectively restores the old behavior.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50272", "url": "https://ubuntu.com/security/CVE-2024-50272", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: filemap: Fix bounds checking in filemap_read() If the caller supplies an iocb->ki_pos value that is close to the filesystem upper limit, and an iterator with a count that causes us to overflow that limit, then filemap_read() enters an infinite loop. This behaviour was discovered when testing xfstests generic/525 with the \"localio\" optimisation for loopback NFS mounts.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53104", "url": "https://ubuntu.com/security/CVE-2024-53104", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_parse_format This can lead to out of bounds writes since frames of this type were not taken into account when calculating the size of the frames buffer in uvc_parse_streaming.", "cve_priority": "high", "cve_public_date": "2024-12-02 08:15:00 UTC" }, { "cve": "CVE-2024-50273", "url": "https://ubuntu.com/security/CVE-2024-50273", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: reinitialize delayed ref list after deleting it from the list At insert_delayed_ref() if we need to update the action of an existing ref to BTRFS_DROP_DELAYED_REF, we delete the ref from its ref head's ref_add_list using list_del(), which leaves the ref's add_list member not reinitialized, as list_del() sets the next and prev members of the list to LIST_POISON1 and LIST_POISON2, respectively. If later we end up calling drop_delayed_ref() against the ref, which can happen during merging or when destroying delayed refs due to a transaction abort, we can trigger a crash since at drop_delayed_ref() we call list_empty() against the ref's add_list, which returns false since the list was not reinitialized after the list_del() and as a consequence we call list_del() again at drop_delayed_ref(). This results in an invalid list access since the next and prev members are set to poison pointers, resulting in a splat if CONFIG_LIST_HARDENED and CONFIG_DEBUG_LIST are set or invalid poison pointer dereferences otherwise. So fix this by deleting from the list with list_del_init() instead.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53064", "url": "https://ubuntu.com/security/CVE-2024-53064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: fix idpf_vc_core_init error path In an event where the platform running the device control plane is rebooted, reset is detected on the driver. It releases all the resources and waits for the reset to complete. Once the reset is done, it tries to build the resources back. At this time if the device control plane is not yet started, then the driver timeouts on the virtchnl message and retries to establish the mailbox again. In the retry flow, mailbox is deinitialized but the mailbox workqueue is still alive and polling for the mailbox message. This results in accessing the released control queue leading to null-ptr-deref. Fix it by unrolling the work queue cancellation and mailbox deinitialization in the reverse order which they got initialized.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50274", "url": "https://ubuntu.com/security/CVE-2024-50274", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: idpf: avoid vport access in idpf_get_link_ksettings When the device control plane is removed or the platform running device control plane is rebooted, a reset is detected on the driver. On driver reset, it releases the resources and waits for the reset to complete. If the reset fails, it takes the error path and releases the vport lock. At this time if the monitoring tools tries to access link settings, it call traces for accessing released vport pointer. To avoid it, move link_speed_mbps to netdev_priv structure which removes the dependency on vport pointer and the vport lock in idpf_get_link_ksettings. Also use netif_carrier_ok() to check the link status and adjust the offsetof to use link_up instead of link_speed_mbps.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53065", "url": "https://ubuntu.com/security/CVE-2024-53065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/slab: fix warning caused by duplicate kmem_cache creation in kmem_buckets_create Commit b035f5a6d852 (\"mm: slab: reduce the kmalloc() minimum alignment if DMA bouncing possible\") reduced ARCH_KMALLOC_MINALIGN to 8 on arm64. However, with KASAN_HW_TAGS enabled, arch_slab_minalign() becomes 16. This causes kmalloc_caches[*][8] to be aliased to kmalloc_caches[*][16], resulting in kmem_buckets_create() attempting to create a kmem_cache for size 16 twice. This duplication triggers warnings on boot: [ 2.325108] ------------[ cut here ]------------ [ 2.325135] kmem_cache of name 'memdup_user-16' already exists [ 2.325783] WARNING: CPU: 0 PID: 1 at mm/slab_common.c:107 __kmem_cache_create_args+0xb8/0x3b0 [ 2.327957] Modules linked in: [ 2.328550] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5mm-unstable-arm64+ #12 [ 2.328683] Hardware name: QEMU QEMU Virtual Machine, BIOS 2024.02-2 03/11/2024 [ 2.328790] pstate: 61000009 (nZCv daif -PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 2.328911] pc : __kmem_cache_create_args+0xb8/0x3b0 [ 2.328930] lr : __kmem_cache_create_args+0xb8/0x3b0 [ 2.328942] sp : ffff800083d6fc50 [ 2.328961] x29: ffff800083d6fc50 x28: f2ff0000c1674410 x27: ffff8000820b0598 [ 2.329061] x26: 000000007fffffff x25: 0000000000000010 x24: 0000000000002000 [ 2.329101] x23: ffff800083d6fce8 x22: ffff8000832222e8 x21: ffff800083222388 [ 2.329118] x20: f2ff0000c1674410 x19: f5ff0000c16364c0 x18: ffff800083d80030 [ 2.329135] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 2.329152] x14: 0000000000000000 x13: 0a73747369786520 x12: 79646165726c6120 [ 2.329169] x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : 0000000000000000 [ 2.329194] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 [ 2.329210] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 2.329226] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 2.329291] Call trace: [ 2.329407] __kmem_cache_create_args+0xb8/0x3b0 [ 2.329499] kmem_buckets_create+0xfc/0x320 [ 2.329526] init_user_buckets+0x34/0x78 [ 2.329540] do_one_initcall+0x64/0x3c8 [ 2.329550] kernel_init_freeable+0x26c/0x578 [ 2.329562] kernel_init+0x3c/0x258 [ 2.329574] ret_from_fork+0x10/0x20 [ 2.329698] ---[ end trace 0000000000000000 ]--- [ 2.403704] ------------[ cut here ]------------ [ 2.404716] kmem_cache of name 'msg_msg-16' already exists [ 2.404801] WARNING: CPU: 2 PID: 1 at mm/slab_common.c:107 __kmem_cache_create_args+0xb8/0x3b0 [ 2.404842] Modules linked in: [ 2.404971] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.12.0-rc5mm-unstable-arm64+ #12 [ 2.405026] Tainted: [W]=WARN [ 2.405043] Hardware name: QEMU QEMU Virtual Machine, BIOS 2024.02-2 03/11/2024 [ 2.405057] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 2.405079] pc : __kmem_cache_create_args+0xb8/0x3b0 [ 2.405100] lr : __kmem_cache_create_args+0xb8/0x3b0 [ 2.405111] sp : ffff800083d6fc50 [ 2.405115] x29: ffff800083d6fc50 x28: fbff0000c1674410 x27: ffff8000820b0598 [ 2.405135] x26: 000000000000ffd0 x25: 0000000000000010 x24: 0000000000006000 [ 2.405153] x23: ffff800083d6fce8 x22: ffff8000832222e8 x21: ffff800083222388 [ 2.405169] x20: fbff0000c1674410 x19: fdff0000c163d6c0 x18: ffff800083d80030 [ 2.405185] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 2.405201] x14: 0000000000000000 x13: 0a73747369786520 x12: 79646165726c6120 [ 2.405217] x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : 0000000000000000 [ 2.405233] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 [ 2.405248] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 [ 2.405271] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 [ 2.405287] Call trace: [ 2 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50275", "url": "https://ubuntu.com/security/CVE-2024-50275", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64/sve: Discard stale CPU state when handling SVE traps The logic for handling SVE traps manipulates saved FPSIMD/SVE state incorrectly, and a race with preemption can result in a task having TIF_SVE set and TIF_FOREIGN_FPSTATE clear even though the live CPU state is stale (e.g. with SVE traps enabled). This has been observed to result in warnings from do_sve_acc() where SVE traps are not expected while TIF_SVE is set: | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* SVE access shouldn't have trapped */ Warnings of this form have been reported intermittently, e.g. https://lore.kernel.org/linux-arm-kernel/CA+G9fYtEGe_DhY2Ms7+L7NKsLYUomGsgqpdBj+QwDLeSg=JhGg@mail.gmail.com/ https://lore.kernel.org/linux-arm-kernel/000000000000511e9a060ce5a45c@google.com/ The race can occur when the SVE trap handler is preempted before and after manipulating the saved FPSIMD/SVE state, starting and ending on the same CPU, e.g. | void do_sve_acc(unsigned long esr, struct pt_regs *regs) | { | // Trap on CPU 0 with TIF_SVE clear, SVE 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(); | | if (test_and_set_thread_flag(TIF_SVE)) | WARN_ON(1); /* SVE access shouldn't have trapped */ | | sve_init_regs() { | if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) { | ... | } else { | fpsimd_to_sve(current); | current->thread.fp_type = FP_STATE_SVE; | } | } | | 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 SVE 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.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50276", "url": "https://ubuntu.com/security/CVE-2024-50276", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: vertexcom: mse102x: Fix possible double free of TX skb The scope of the TX skb is wider than just mse102x_tx_frame_spi(), so in case the TX skb room needs to be expanded, we should free the the temporary skb instead of the original skb. Otherwise the original TX skb pointer would be freed again in mse102x_tx_work(), which leads to crashes: Internal error: Oops: 0000000096000004 [#2] PREEMPT SMP CPU: 0 PID: 712 Comm: kworker/0:1 Tainted: G D 6.6.23 Hardware name: chargebyte Charge SOM DC-ONE (DT) Workqueue: events mse102x_tx_work [mse102x] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skb_release_data+0xb8/0x1d8 lr : skb_release_data+0x1ac/0x1d8 sp : ffff8000819a3cc0 x29: ffff8000819a3cc0 x28: ffff0000046daa60 x27: ffff0000057f2dc0 x26: ffff000005386c00 x25: 0000000000000002 x24: 00000000ffffffff x23: 0000000000000000 x22: 0000000000000001 x21: ffff0000057f2e50 x20: 0000000000000006 x19: 0000000000000000 x18: ffff00003fdacfcc x17: e69ad452d0c49def x16: 84a005feff870102 x15: 0000000000000000 x14: 000000000000024a x13: 0000000000000002 x12: 0000000000000000 x11: 0000000000000400 x10: 0000000000000930 x9 : ffff00003fd913e8 x8 : fffffc00001bc008 x7 : 0000000000000000 x6 : 0000000000000008 x5 : ffff00003fd91340 x4 : 0000000000000000 x3 : 0000000000000009 x2 : 00000000fffffffe x1 : 0000000000000000 x0 : 0000000000000000 Call trace: skb_release_data+0xb8/0x1d8 kfree_skb_reason+0x48/0xb0 mse102x_tx_work+0x164/0x35c [mse102x] process_one_work+0x138/0x260 worker_thread+0x32c/0x438 kthread+0x118/0x11c ret_from_fork+0x10/0x20 Code: aa1303e0 97fffab6 72001c1f 54000141 (f9400660)", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53066", "url": "https://ubuntu.com/security/CVE-2024-53066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfs: Fix KMSAN warning in decode_getfattr_attrs() Fix the following KMSAN warning: CPU: 1 UID: 0 PID: 7651 Comm: cp Tainted: G B Tainted: [B]=BAD_PAGE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009) ===================================================== ===================================================== BUG: KMSAN: uninit-value in decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_attrs+0x2d6d/0x2f90 decode_getfattr_generic+0x806/0xb00 nfs4_xdr_dec_getattr+0x1de/0x240 rpcauth_unwrap_resp_decode+0xab/0x100 rpcauth_unwrap_resp+0x95/0xc0 call_decode+0x4ff/0xb50 __rpc_execute+0x57b/0x19d0 rpc_execute+0x368/0x5e0 rpc_run_task+0xcfe/0xee0 nfs4_proc_getattr+0x5b5/0x990 __nfs_revalidate_inode+0x477/0xd00 nfs_access_get_cached+0x1021/0x1cc0 nfs_do_access+0x9f/0xae0 nfs_permission+0x1e4/0x8c0 inode_permission+0x356/0x6c0 link_path_walk+0x958/0x1330 path_lookupat+0xce/0x6b0 filename_lookup+0x23e/0x770 vfs_statx+0xe7/0x970 vfs_fstatat+0x1f2/0x2c0 __se_sys_newfstatat+0x67/0x880 __x64_sys_newfstatat+0xbd/0x120 x64_sys_call+0x1826/0x3cf0 do_syscall_64+0xd0/0x1b0 entry_SYSCALL_64_after_hwframe+0x77/0x7f The KMSAN warning is triggered in decode_getfattr_attrs(), when calling decode_attr_mdsthreshold(). It appears that fattr->mdsthreshold is not initialized. Fix the issue by initializing fattr->mdsthreshold to NULL in nfs_fattr_init().", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53067", "url": "https://ubuntu.com/security/CVE-2024-53067", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Start the RTC update work later The RTC update work involves runtime resuming the UFS controller. Hence, only start the RTC update work after runtime power management in the UFS driver has been fully initialized. This patch fixes the following kernel crash: Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP Workqueue: events ufshcd_rtc_work Call trace: _raw_spin_lock_irqsave+0x34/0x8c (P) pm_runtime_get_if_active+0x24/0x9c (L) pm_runtime_get_if_active+0x24/0x9c ufshcd_rtc_work+0x138/0x1b4 process_one_work+0x148/0x288 worker_thread+0x2cc/0x3d4 kthread+0x110/0x114 ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50277", "url": "https://ubuntu.com/security/CVE-2024-50277", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm: fix a crash if blk_alloc_disk fails If blk_alloc_disk fails, the variable md->disk is set to an error value. cleanup_mapped_device will see that md->disk is non-NULL and it will attempt to access it, causing a crash on this statement \"md->disk->private_data = NULL;\".", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50278", "url": "https://ubuntu.com/security/CVE-2024-50278", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix potential out-of-bounds access on the first resume Out-of-bounds access occurs if the fast device is expanded unexpectedly before the first-time resume of the cache table. This happens because expanding the fast device requires reloading the cache table for cache_create to allocate new in-core data structures that fit the new size, and the check in cache_preresume is not performed during the first resume, leading to the issue. Reproduce steps: 1. prepare component devices: 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\" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct 2. load a cache table of 512 cache blocks, and deliberately expand the fast device before resuming the cache, making the in-core data structures inadequate. dmsetup create cache --notable dmsetup reload cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" dmsetup reload cdata --table \"0 131072 linear /dev/sdc 8192\" dmsetup resume cdata dmsetup resume cache 3. suspend the cache to write out the in-core dirty bitset and hint array, leading to out-of-bounds access to the dirty bitset at offset 0x40: dmsetup suspend cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80 Read of size 8 at addr ffffc90000085040 by task dmsetup/90 (...snip...) The buggy address belongs to the virtual mapping at [ffffc90000085000, ffffc90000087000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by checking the size change on the first resume.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50279", "url": "https://ubuntu.com/security/CVE-2024-50279", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix out-of-bounds access to the dirty bitset when resizing dm-cache checks the dirty bits of the cache blocks to be dropped when shrinking the fast device, but an index bug in bitset iteration causes out-of-bounds access. Reproduce steps: 1. create a cache device of 1024 cache blocks (128 bytes dirty bitset) dmsetup create cmeta --table \"0 8192 linear /dev/sdc 0\" dmsetup create cdata --table \"0 131072 linear /dev/sdc 8192\" dmsetup create corig --table \"0 524288 linear /dev/sdc 262144\" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" 2. shrink the fast device to 512 cache blocks, triggering out-of-bounds access to the dirty bitset (offset 0x80) dmsetup suspend cache dmsetup reload cdata --table \"0 65536 linear /dev/sdc 8192\" dmsetup resume cdata dmsetup resume cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in cache_preresume+0x269/0x7b0 Read of size 8 at addr ffffc900000f3080 by task dmsetup/131 (...snip...) The buggy address belongs to the virtual mapping at [ffffc900000f3000, ffffc900000f5000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc900000f2f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffffc900000f3080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc900000f3100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc900000f3180: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by making the index post-incremented.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50280", "url": "https://ubuntu.com/security/CVE-2024-50280", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm cache: fix flushing uninitialized delayed_work on cache_ctr error An unexpected WARN_ON from flush_work() may occur when cache creation fails, caused by destroying the uninitialized delayed_work waker in the error path of cache_create(). For example, the warning appears on the superblock checksum error. Reproduce steps: 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\" dd if=/dev/urandom of=/dev/mapper/cmeta bs=4k count=1 oflag=direct dmsetup create cache --table \"0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\" Kernel logs: (snip) WARNING: CPU: 0 PID: 84 at kernel/workqueue.c:4178 __flush_work+0x5d4/0x890 Fix by pulling out the cancel_delayed_work_sync() from the constructor's error path. This patch doesn't affect the use-after-free fix for concurrent dm_resume and dm_destroy (commit 6a459d8edbdb (\"dm cache: Fix UAF in destroy()\")) as cache_dtr is not changed.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50281", "url": "https://ubuntu.com/security/CVE-2024-50281", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: trusted: dcp: fix NULL dereference in AEAD crypto operation When sealing or unsealing a key blob we currently do not wait for the AEAD cipher operation to finish and simply return after submitting the request. If there is some load on the system we can exit before the cipher operation is done and the buffer we read from/write to is already removed from the stack. This will e.g. result in NULL pointer dereference errors in the DCP driver during blob creation. Fix this by waiting for the AEAD cipher operation to finish before resuming the seal and unseal calls.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50282", "url": "https://ubuntu.com/security/CVE-2024-50282", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read() Avoid a possible buffer overflow if size is larger than 4K. (cherry picked from commit f5d873f5825b40d886d03bd2aede91d4cf002434)", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53071", "url": "https://ubuntu.com/security/CVE-2024-53071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Be stricter about IO mapping flags The current panthor_device_mmap_io() implementation has two issues: 1. For mapping DRM_PANTHOR_USER_FLUSH_ID_MMIO_OFFSET, panthor_device_mmap_io() bails if VM_WRITE is set, but does not clear VM_MAYWRITE. That means userspace can use mprotect() to make the mapping writable later on. This is a classic Linux driver gotcha. I don't think this actually has any impact in practice: When the GPU is powered, writes to the FLUSH_ID seem to be ignored; and when the GPU is not powered, the dummy_latest_flush page provided by the driver is deliberately designed to not do any flushes, so the only thing writing to the dummy_latest_flush could achieve would be to make *more* flushes happen. 2. panthor_device_mmap_io() does not block MAP_PRIVATE mappings (which are mappings without the VM_SHARED flag). MAP_PRIVATE in combination with VM_MAYWRITE indicates that the VMA has copy-on-write semantics, which for VM_PFNMAP are semi-supported but fairly cursed. In particular, in such a mapping, the driver can only install PTEs during mmap() by calling remap_pfn_range() (because remap_pfn_range() wants to **store the physical address of the mapped physical memory into the vm_pgoff of the VMA**); installing PTEs later on with a fault handler (as panthor does) is not supported in private mappings, and so if you try to fault in such a mapping, vmf_insert_pfn_prot() splats when it hits a BUG() check. Fix it by clearing the VM_MAYWRITE flag (userspace writing to the FLUSH_ID doesn't make sense) and requiring VM_SHARED (copy-on-write semantics for the FLUSH_ID don't make sense). Reproducers for both scenarios are in the notes of my patch on the mailing list; I tested that these bugs exist on a Rock 5B machine. Note that I only compile-tested the patch, I haven't tested it; I don't have a working kernel build setup for the test machine yet. Please test it before applying it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53080", "url": "https://ubuntu.com/security/CVE-2024-53080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Lock XArray when getting entries for the VM Similar to commit cac075706f29 (\"drm/panthor: Fix race when converting group handle to group object\") we need to use the XArray's internal locking when retrieving a vm pointer from there. v2: Removed part of the patch that was trying to protect fetching the heap pointer from XArray, as that operation is protected by the @pool->lock.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53084", "url": "https://ubuntu.com/security/CVE-2024-53084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/imagination: Break an object reference loop When remaining resources are being cleaned up on driver close, outstanding VM mappings may result in resources being leaked, due to an object reference loop, as shown below, with each object (or set of objects) referencing the object below it: PVR GEM Object GPU scheduler \"finished\" fence GPU scheduler “scheduled” fence PVR driver “done” fence PVR Context PVR VM Context PVR VM Mappings PVR GEM Object The reference that the PVR VM Context has on the VM mappings is a soft one, in the sense that the freeing of outstanding VM mappings is done as part of VM context destruction; no reference counts are involved, as is the case for all the other references in the loop. To break the reference loop during cleanup, free the outstanding VM mappings before destroying the PVR Context associated with the VM context.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53085", "url": "https://ubuntu.com/security/CVE-2024-53085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: Lock TPM chip in tpm_pm_suspend() first Setting TPM_CHIP_FLAG_SUSPENDED in the end of tpm_pm_suspend() can be racy according, as this leaves window for tpm_hwrng_read() to be called while the operation is in progress. The recent bug report gives also evidence of this behaviour. Aadress this by locking the TPM chip before checking any chip->flags both in tpm_pm_suspend() and tpm_hwrng_read(). Move TPM_CHIP_FLAG_SUSPENDED check inside tpm_get_random() so that it will be always checked only when the lock is reserved.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53086", "url": "https://ubuntu.com/security/CVE-2024-53086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Drop VM dma-resv lock on xe_sync_in_fence_get failure in exec IOCTL Upon failure all locks need to be dropped before returning to the user. (cherry picked from commit 7d1a4258e602ffdce529f56686925034c1b3b095)", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53087", "url": "https://ubuntu.com/security/CVE-2024-53087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Fix possible exec queue leak in exec IOCTL In a couple of places after an exec queue is looked up the exec IOCTL returns on input errors without dropping the exec queue ref. Fix this ensuring the exec queue ref is dropped on input error. (cherry picked from commit 07064a200b40ac2195cb6b7b779897d9377e5e6f)", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50283", "url": "https://ubuntu.com/security/CVE-2024-50283", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-use-after-free in smb3_preauth_hash_rsp ksmbd_user_session_put should be called under smb3_preauth_hash_rsp(). It will avoid freeing session before calling smb3_preauth_hash_rsp().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50284", "url": "https://ubuntu.com/security/CVE-2024-50284", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix the missing xa_store error check xa_store() can fail, it return xa_err(-EINVAL) if the entry cannot be stored in an XArray, or xa_err(-ENOMEM) if memory allocation failed, so check error for xa_store() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50285", "url": "https://ubuntu.com/security/CVE-2024-50285", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: check outstanding simultaneous SMB operations If Client send simultaneous SMB operations to ksmbd, It exhausts too much memory through the \"ksmbd_work_cache”. It will cause OOM issue. ksmbd has a credit mechanism but it can't handle this problem. This patch add the check if it exceeds max credits to prevent this problem by assuming that one smb request consumes at least one credit.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50286", "url": "https://ubuntu.com/security/CVE-2024-50286", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix slab-use-after-free in ksmbd_smb2_session_create There is a race condition between ksmbd_smb2_session_create and ksmbd_expire_session. This patch add missing sessions_table_lock while adding/deleting session from global session table.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50287", "url": "https://ubuntu.com/security/CVE-2024-50287", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: v4l2-tpg: prevent the risk of a division by zero As reported by Coverity, the logic at tpg_precalculate_line() blindly rescales the buffer even when scaled_witdh is equal to zero. If this ever happens, this will cause a division by zero. Instead, add a WARN_ON_ONCE() to trigger such cases and return without doing any precalculation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50288", "url": "https://ubuntu.com/security/CVE-2024-50288", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: vivid: fix buffer overwrite when using > 32 buffers The maximum number of buffers that can be requested was increased to 64 for the video capture queue. But video capture used a must_blank array that was still sized for 32 (VIDEO_MAX_FRAME). This caused an out-of-bounds write when using buffer indices >= 32. Create a new define MAX_VID_CAP_BUFFERS that is used to access the must_blank array and set max_num_buffers for the video capture queue. This solves a crash reported by: \thttps://bugzilla.kernel.org/show_bug.cgi?id=219258", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50289", "url": "https://ubuntu.com/security/CVE-2024-50289", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: av7110: fix a spectre vulnerability As warned by smatch: \tdrivers/staging/media/av7110/av7110_ca.c:270 dvb_ca_ioctl() warn: potential spectre issue 'av7110->ci_slot' [w] (local cap) There is a spectre-related vulnerability at the code. Fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50290", "url": "https://ubuntu.com/security/CVE-2024-50290", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: cx24116: prevent overflows on SNR calculus as reported by Coverity, if reading SNR registers fail, a negative number will be returned, causing an underflow when reading SNR registers. Prevent that.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53061", "url": "https://ubuntu.com/security/CVE-2024-53061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: s5p-jpeg: prevent buffer overflows The current logic allows word to be less than 2. If this happens, there will be buffer overflows, as reported by smatch. Add extra checks to prevent it. While here, remove an unused word = 0 assignment.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53081", "url": "https://ubuntu.com/security/CVE-2024-53081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: ar0521: don't overflow when checking PLL values The PLL checks are comparing 64 bit integers with 32 bit ones, as reported by Coverity. Depending on the values of the variables, this may underflow. Fix it ensuring that both sides of the expression are u64.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53062", "url": "https://ubuntu.com/security/CVE-2024-53062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mgb4: protect driver against spectre Frequency range is set from sysfs via frequency_range_store(), being vulnerable to spectre, as reported by smatch: \tdrivers/media/pci/mgb4/mgb4_cmt.c:231 mgb4_cmt_set_vin_freq_range() warn: potential spectre issue 'cmt_vals_in' [r] \tdrivers/media/pci/mgb4/mgb4_cmt.c:238 mgb4_cmt_set_vin_freq_range() warn: possible spectre second half. 'reg_set' Fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50291", "url": "https://ubuntu.com/security/CVE-2024-50291", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvb-core: add missing buffer index check dvb_vb2_expbuf() didn't check if the given buffer index was for a valid buffer. Add this check.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50292", "url": "https://ubuntu.com/security/CVE-2024-50292", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: stm32: spdifrx: fix dma channel release in stm32_spdifrx_remove In case of error when requesting ctrl_chan DMA channel, ctrl_chan is not null. So the release of the dma channel leads to the following issue: [ 4.879000] st,stm32-spdifrx 500d0000.audio-controller: dma_request_slave_channel error -19 [ 4.888975] Unable to handle kernel NULL pointer dereference at virtual address 000000000000003d [...] [ 5.096577] Call trace: [ 5.099099] dma_release_channel+0x24/0x100 [ 5.103235] stm32_spdifrx_remove+0x24/0x60 [snd_soc_stm32_spdifrx] [ 5.109494] stm32_spdifrx_probe+0x320/0x4c4 [snd_soc_stm32_spdifrx] To avoid this issue, release channel only if the pointer is valid.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53063", "url": "https://ubuntu.com/security/CVE-2024-53063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: dvbdev: prevent the risk of out of memory access The dvbdev contains a static variable used to store dvb minors. The behavior of it depends if CONFIG_DVB_DYNAMIC_MINORS is set or not. When not set, dvb_register_device() won't check for boundaries, as it will rely that a previous call to dvb_register_adapter() would already be enforcing it. On a similar way, dvb_device_open() uses the assumption that the register functions already did the needed checks. This can be fragile if some device ends using different calls. This also generate warnings on static check analysers like Coverity. So, add explicit guards to prevent potential risk of OOM issues.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50293", "url": "https://ubuntu.com/security/CVE-2024-50293", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: do not leave a dangling sk pointer in __smc_create() Thanks to commit 4bbd360a5084 (\"socket: Print pf->create() when it does not clear sock->sk on failure.\"), syzbot found an issue with AF_SMC: smc_create must clear sock->sk on failure, family: 43, type: 1, protocol: 0 WARNING: CPU: 0 PID: 5827 at net/socket.c:1565 __sock_create+0x96f/0xa30 net/socket.c:1563 Modules linked in: CPU: 0 UID: 0 PID: 5827 Comm: syz-executor259 Not tainted 6.12.0-rc6-next-20241106-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:__sock_create+0x96f/0xa30 net/socket.c:1563 Code: 03 00 74 08 4c 89 e7 e8 4f 3b 85 f8 49 8b 34 24 48 c7 c7 40 89 0c 8d 8b 54 24 04 8b 4c 24 0c 44 8b 44 24 08 e8 32 78 db f7 90 <0f> 0b 90 90 e9 d3 fd ff ff 89 e9 80 e1 07 fe c1 38 c1 0f 8c ee f7 RSP: 0018:ffffc90003e4fda0 EFLAGS: 00010246 RAX: 099c6f938c7f4700 RBX: 1ffffffff1a595fd RCX: ffff888034823c00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 00000000ffffffe9 R08: ffffffff81567052 R09: 1ffff920007c9f50 R10: dffffc0000000000 R11: fffff520007c9f51 R12: ffffffff8d2cafe8 R13: 1ffffffff1a595fe R14: ffffffff9a789c40 R15: ffff8880764298c0 FS: 000055557b518380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa62ff43225 CR3: 0000000031628000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: sock_create net/socket.c:1616 [inline] __sys_socket_create net/socket.c:1653 [inline] __sys_socket+0x150/0x3c0 net/socket.c:1700 __do_sys_socket net/socket.c:1714 [inline] __se_sys_socket net/socket.c:1712 [inline] For reference, see commit 2d859aff775d (\"Merge branch 'do-not-leave-dangling-sk-pointers-in-pf-create-functions'\")", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50294", "url": "https://ubuntu.com/security/CVE-2024-50294", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix missing locking causing hanging calls If a call gets aborted (e.g. because kafs saw a signal) between it being queued for connection and the I/O thread picking up the call, the abort will be prioritised over the connection and it will be removed from local->new_client_calls by rxrpc_disconnect_client_call() without a lock being held. This may cause other calls on the list to disappear if a race occurs. Fix this by taking the client_call_lock when removing a call from whatever list its ->wait_link happens to be on.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50295", "url": "https://ubuntu.com/security/CVE-2024-50295", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: arc: fix the device for dma_map_single/dma_unmap_single The ndev->dev and pdev->dev aren't the same device, use ndev->dev.parent which has dma_mask, ndev->dev.parent is just pdev->dev. Or it would cause the following issue: [ 39.933526] ------------[ cut here ]------------ [ 39.938414] WARNING: CPU: 1 PID: 501 at kernel/dma/mapping.c:149 dma_map_page_attrs+0x90/0x1f8", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53082", "url": "https://ubuntu.com/security/CVE-2024-53082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_net: Add hash_key_length check Add hash_key_length check in virtnet_probe() to avoid possible out of bound errors when setting/reading the hash key.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50296", "url": "https://ubuntu.com/security/CVE-2024-50296", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix kernel crash when uninstalling driver When the driver is uninstalled and the VF is disabled concurrently, a kernel crash occurs. The reason is that the two actions call function pci_disable_sriov(). The num_VFs is checked to determine whether to release the corresponding resources. During the second calling, num_VFs is not 0 and the resource release function is called. However, the corresponding resource has been released during the first invoking. Therefore, the problem occurs: [15277.839633][T50670] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ... [15278.131557][T50670] Call trace: [15278.134686][T50670] klist_put+0x28/0x12c [15278.138682][T50670] klist_del+0x14/0x20 [15278.142592][T50670] device_del+0xbc/0x3c0 [15278.146676][T50670] pci_remove_bus_device+0x84/0x120 [15278.151714][T50670] pci_stop_and_remove_bus_device+0x6c/0x80 [15278.157447][T50670] pci_iov_remove_virtfn+0xb4/0x12c [15278.162485][T50670] sriov_disable+0x50/0x11c [15278.166829][T50670] pci_disable_sriov+0x24/0x30 [15278.171433][T50670] hnae3_unregister_ae_algo_prepare+0x60/0x90 [hnae3] [15278.178039][T50670] hclge_exit+0x28/0xd0 [hclge] [15278.182730][T50670] __se_sys_delete_module.isra.0+0x164/0x230 [15278.188550][T50670] __arm64_sys_delete_module+0x1c/0x30 [15278.193848][T50670] invoke_syscall+0x50/0x11c [15278.198278][T50670] el0_svc_common.constprop.0+0x158/0x164 [15278.203837][T50670] do_el0_svc+0x34/0xcc [15278.207834][T50670] el0_svc+0x20/0x30 For details, see the following figure. rmmod hclge disable VFs ---------------------------------------------------- hclge_exit() sriov_numvfs_store() ... device_lock() pci_disable_sriov() hns3_pci_sriov_configure() pci_disable_sriov() sriov_disable() sriov_disable() if !num_VFs : if !num_VFs : return; return; sriov_del_vfs() sriov_del_vfs() ... ... klist_put() klist_put() ... ... num_VFs = 0; num_VFs = 0; device_unlock(); In this patch, when driver is removing, we get the device_lock() to protect num_VFs, just like sriov_numvfs_store().", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53088", "url": "https://ubuntu.com/security/CVE-2024-53088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: fix race condition by adding filter's intermediate sync state Fix a race condition in the i40e driver that leads to MAC/VLAN filters becoming corrupted and leaking. Address the issue that occurs under heavy load when multiple threads are concurrently modifying MAC/VLAN filters by setting mac and port VLAN. 1. Thread T0 allocates a filter in i40e_add_filter() within i40e_ndo_set_vf_port_vlan(). 2. Thread T1 concurrently frees the filter in __i40e_del_filter() within i40e_ndo_set_vf_mac(). 3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which refers to the already freed filter memory, causing corruption. Reproduction steps: 1. Spawn multiple VFs. 2. Apply a concurrent heavy load by running parallel operations to change MAC addresses on the VFs and change port VLANs on the host. 3. Observe errors in dmesg: \"Error I40E_AQ_RC_ENOSPC adding RX filters on VF XX, \tplease set promiscuous on manually for VF XX\". Exact code for stable reproduction Intel can't open-source now. The fix involves implementing a new intermediate filter state, I40E_FILTER_NEW_SYNC, for the time when a filter is on a tmp_add_list. These filters cannot be deleted from the hash list directly but must be removed using the full process.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50297", "url": "https://ubuntu.com/security/CVE-2024-50297", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: xilinx: axienet: Enqueue Tx packets in dql before dmaengine starts Enqueue packets in dql after dma engine starts causes race condition. Tx transfer starts once dma engine is started and may execute dql dequeue in completion before it gets queued. It results in following kernel crash while running iperf stress test: kernel BUG at lib/dynamic_queue_limits.c:99! Internal error: Oops - BUG: 00000000f2000800 [#1] SMP pc : dql_completed+0x238/0x248 lr : dql_completed+0x3c/0x248 Call trace: dql_completed+0x238/0x248 axienet_dma_tx_cb+0xa0/0x170 xilinx_dma_do_tasklet+0xdc/0x290 tasklet_action_common+0xf8/0x11c tasklet_action+0x30/0x3c handle_softirqs+0xf8/0x230 Start dmaengine after enqueue in dql fixes the crash.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50298", "url": "https://ubuntu.com/security/CVE-2024-50298", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: enetc: allocate vf_state during PF probes In the previous implementation, vf_state is allocated memory only when VF is enabled. However, net_device_ops::ndo_set_vf_mac() may be called before VF is enabled to configure the MAC address of VF. If this is the case, enetc_pf_set_vf_mac() will access vf_state, resulting in access to a null pointer. The simplified error log is as follows. root@ls1028ardb:~# ip link set eno0 vf 1 mac 00:0c:e7:66:77:89 [ 173.543315] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004 [ 173.637254] pc : enetc_pf_set_vf_mac+0x3c/0x80 Message from sy [ 173.641973] lr : do_setlink+0x4a8/0xec8 [ 173.732292] Call trace: [ 173.734740] enetc_pf_set_vf_mac+0x3c/0x80 [ 173.738847] __rtnl_newlink+0x530/0x89c [ 173.742692] rtnl_newlink+0x50/0x7c [ 173.746189] rtnetlink_rcv_msg+0x128/0x390 [ 173.750298] netlink_rcv_skb+0x60/0x130 [ 173.754145] rtnetlink_rcv+0x18/0x24 [ 173.757731] netlink_unicast+0x318/0x380 [ 173.761665] netlink_sendmsg+0x17c/0x3c8", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50299", "url": "https://ubuntu.com/security/CVE-2024-50299", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: properly validate chunk size in sctp_sf_ootb() A size validation fix similar to that in Commit 50619dbf8db7 (\"sctp: add size validation when walking chunks\") is also required in sctp_sf_ootb() to address a crash reported by syzbot: BUG: KMSAN: uninit-value in sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_sf_ootb+0x7f5/0xce0 net/sctp/sm_statefuns.c:3712 sctp_do_sm+0x181/0x93d0 net/sctp/sm_sideeffect.c:1166 sctp_endpoint_bh_rcv+0xc38/0xf90 net/sctp/endpointola.c:407 sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88 sctp_rcv+0x3831/0x3b20 net/sctp/input.c:243 sctp4_rcv+0x42/0x50 net/sctp/protocol.c:1159 ip_protocol_deliver_rcu+0xb51/0x13d0 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x336/0x500 net/ipv4/ip_input.c:233", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50300", "url": "https://ubuntu.com/security/CVE-2024-50300", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: regulator: rtq2208: Fix uninitialized use of regulator_config Fix rtq2208 driver uninitialized use to cause kernel error.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-50301", "url": "https://ubuntu.com/security/CVE-2024-50301", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: security/keys: fix slab-out-of-bounds in key_task_permission KASAN reports an out of bounds read: BUG: KASAN: slab-out-of-bounds in __kuid_val include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uid_eq include/linux/uidgid.h:63 [inline] BUG: KASAN: slab-out-of-bounds in key_task_permission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362 CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace: __dump_stack lib/dump_stack.c:82 [inline] dump_stack+0x107/0x167 lib/dump_stack.c:123 print_address_description.constprop.0+0x19/0x170 mm/kasan/report.c:400 __kasan_report.cold+0x6c/0x84 mm/kasan/report.c:560 kasan_report+0x3a/0x50 mm/kasan/report.c:585 __kuid_val include/linux/uidgid.h:36 [inline] uid_eq include/linux/uidgid.h:63 [inline] key_task_permission+0x394/0x410 security/keys/permission.c:54 search_nested_keyrings+0x90e/0xe90 security/keys/keyring.c:793 This issue was also reported by syzbot. It can be reproduced by following these steps(more details [1]): 1. Obtain more than 32 inputs that have similar hashes, which ends with the pattern '0xxxxxxxe6'. 2. Reboot and add the keys obtained in step 1. The reproducer demonstrates how this issue happened: 1. In the search_nested_keyrings function, when it iterates through the slots in a node(below tag ascend_to_node), if the slot pointer is meta and node->back_pointer != NULL(it means a root), it will proceed to descend_to_node. However, there is an exception. If node is the root, and one of the slots points to a shortcut, it will be treated as a keyring. 2. Whether the ptr is keyring decided by keyring_ptr_is_keyring function. However, KEYRING_PTR_SUBTYPE is 0x2UL, the same as ASSOC_ARRAY_PTR_SUBTYPE_MASK. 3. When 32 keys with the similar hashes are added to the tree, the ROOT has keys with hashes that are not similar (e.g. slot 0) and it splits NODE A without using a shortcut. When NODE A is filled with keys that all hashes are xxe6, the keys are similar, NODE A will split with a shortcut. Finally, it forms the tree as shown below, where slot 6 points to a shortcut. NODE A +------>+---+ ROOT | | 0 | xxe6 +---+ | +---+ xxxx | 0 | shortcut : : xxe6 +---+ | +---+ xxe6 : : | | | xxe6 +---+ | +---+ | 6 |---+ : : xxe6 +---+ +---+ xxe6 : : | f | xxe6 +---+ +---+ xxe6 | f | +---+ 4. As mentioned above, If a slot(slot 6) of the root points to a shortcut, it may be mistakenly transferred to a key*, leading to a read out-of-bounds read. To fix this issue, one should jump to descend_to_node if the ptr is a shortcut, regardless of whether the node is root or not. [1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/ [jarkko: tweaked the commit message a bit to have an appropriate closes tag.]", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53072", "url": "https://ubuntu.com/security/CVE-2024-53072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86/amd/pmc: Detect when STB is not available Loading the amd_pmc module as: amd_pmc enable_stb=1 ...can result in the following messages in the kernel ring buffer: amd_pmc AMDI0009:00: SMU cmd failed. err: 0xff ioremap on RAM at 0x0000000000000000 - 0x0000000000ffffff WARNING: CPU: 10 PID: 2151 at arch/x86/mm/ioremap.c:217 __ioremap_caller+0x2cd/0x340 Further debugging reveals that this occurs when the requests for S2D_PHYS_ADDR_LOW and S2D_PHYS_ADDR_HIGH return a value of 0, indicating that the STB is inaccessible. To prevent the ioremap warning and provide clarity to the user, handle the invalid address and display an error message.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50302", "url": "https://ubuntu.com/security/CVE-2024-50302", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: core: zero-initialize the report buffer Since the report buffer is used by all kinds of drivers in various ways, let's zero-initialize it during allocation to make sure that it can't be ever used to leak kernel memory via specially-crafted report.", "cve_priority": "medium", "cve_public_date": "2024-11-19 02:16:00 UTC" }, { "cve": "CVE-2024-53068", "url": "https://ubuntu.com/security/CVE-2024-53068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix slab-use-after-free in scmi_bus_notifier() The scmi_dev->name is released prematurely in __scmi_device_destroy(), which causes slab-use-after-free when accessing scmi_dev->name in scmi_bus_notifier(). So move the release of scmi_dev->name to scmi_device_release() to avoid slab-use-after-free. | BUG: KASAN: slab-use-after-free in strncmp+0xe4/0xec | Read of size 1 at addr ffffff80a482bcc0 by task swapper/0/1 | | CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.6.38-debug #1 | Hardware name: Qualcomm Technologies, Inc. SA8775P Ride (DT) | Call trace: | dump_backtrace+0x94/0x114 | show_stack+0x18/0x24 | dump_stack_lvl+0x48/0x60 | print_report+0xf4/0x5b0 | kasan_report+0xa4/0xec | __asan_report_load1_noabort+0x20/0x2c | strncmp+0xe4/0xec | scmi_bus_notifier+0x5c/0x54c | notifier_call_chain+0xb4/0x31c | blocking_notifier_call_chain+0x68/0x9c | bus_notify+0x54/0x78 | device_del+0x1bc/0x840 | device_unregister+0x20/0xb4 | __scmi_device_destroy+0xac/0x280 | scmi_device_destroy+0x94/0xd0 | scmi_chan_setup+0x524/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20 | | Allocated by task 1: | kasan_save_stack+0x2c/0x54 | kasan_set_track+0x2c/0x40 | kasan_save_alloc_info+0x24/0x34 | __kasan_kmalloc+0xa0/0xb8 | __kmalloc_node_track_caller+0x6c/0x104 | kstrdup+0x48/0x84 | kstrdup_const+0x34/0x40 | __scmi_device_create.part.0+0x8c/0x408 | scmi_device_create+0x104/0x370 | scmi_chan_setup+0x2a0/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20 | | Freed by task 1: | kasan_save_stack+0x2c/0x54 | kasan_set_track+0x2c/0x40 | kasan_save_free_info+0x38/0x5c | __kasan_slab_free+0xe8/0x164 | __kmem_cache_free+0x11c/0x230 | kfree+0x70/0x130 | kfree_const+0x20/0x40 | __scmi_device_destroy+0x70/0x280 | scmi_device_destroy+0x94/0xd0 | scmi_chan_setup+0x524/0x750 | scmi_probe+0x7fc/0x1508 | platform_probe+0xc4/0x19c | really_probe+0x32c/0x99c | __driver_probe_device+0x15c/0x3c4 | driver_probe_device+0x5c/0x170 | __driver_attach+0x1c8/0x440 | bus_for_each_dev+0xf4/0x178 | driver_attach+0x3c/0x58 | bus_add_driver+0x234/0x4d4 | driver_register+0xf4/0x3c0 | __platform_driver_register+0x60/0x88 | scmi_driver_init+0xb0/0x104 | do_one_initcall+0xb4/0x664 | kernel_init_freeable+0x3c8/0x894 | kernel_init+0x24/0x1e8 | ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53069", "url": "https://ubuntu.com/security/CVE-2024-53069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: qcom: scm: fix a NULL-pointer dereference Some SCM calls can be invoked with __scm being NULL (the driver may not have been and will not be probed as there's no SCM entry in device-tree). Make sure we don't dereference a NULL pointer.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50212", "url": "https://ubuntu.com/security/CVE-2024-50212", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: lib: alloc_tag_module_unload must wait for pending kfree_rcu calls Ben Greear reports following splat: ------------[ cut here ]------------ net/netfilter/nf_nat_core.c:1114 module nf_nat func:nf_nat_register_fn has 256 allocated at module unload WARNING: CPU: 1 PID: 10421 at lib/alloc_tag.c:168 alloc_tag_module_unload+0x22b/0x3f0 Modules linked in: nf_nat(-) btrfs ufs qnx4 hfsplus hfs minix vfat msdos fat ... Hardware name: Default string Default string/SKYBAY, BIOS 5.12 08/04/2020 RIP: 0010:alloc_tag_module_unload+0x22b/0x3f0 codetag_unload_module+0x19b/0x2a0 ? codetag_load_module+0x80/0x80 nf_nat module exit calls kfree_rcu on those addresses, but the free operation is likely still pending by the time alloc_tag checks for leaks. Wait for outstanding kfree_rcu operations to complete before checking resolves this warning. Reproducer: unshare -n iptables-nft -t nat -A PREROUTING -p tcp grep nf_nat /proc/allocinfo # will list 4 allocations rmmod nft_chain_nat rmmod nf_nat # will WARN. [akpm@linux-foundation.org: add comment]", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53046", "url": "https://ubuntu.com/security/CVE-2024-53046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: dts: imx8ulp: correct the flexspi compatible string The flexspi on imx8ulp only has 16 LUTs, and imx8mm flexspi has 32 LUTs, so correct the compatible string here, otherwise will meet below error: [ 1.119072] ------------[ cut here ]------------ [ 1.123926] WARNING: CPU: 0 PID: 1 at drivers/spi/spi-nxp-fspi.c:855 nxp_fspi_exec_op+0xb04/0xb64 [ 1.133239] Modules linked in: [ 1.136448] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-rc6-next-20240902-00001-g131bf9439dd9 #69 [ 1.146821] Hardware name: NXP i.MX8ULP EVK (DT) [ 1.151647] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 1.158931] pc : nxp_fspi_exec_op+0xb04/0xb64 [ 1.163496] lr : nxp_fspi_exec_op+0xa34/0xb64 [ 1.168060] sp : ffff80008002b2a0 [ 1.171526] x29: ffff80008002b2d0 x28: 0000000000000000 x27: 0000000000000000 [ 1.179002] x26: ffff2eb645542580 x25: ffff800080610014 x24: ffff800080610000 [ 1.186480] x23: ffff2eb645548080 x22: 0000000000000006 x21: ffff2eb6455425e0 [ 1.193956] x20: 0000000000000000 x19: ffff80008002b5e0 x18: ffffffffffffffff [ 1.201432] x17: ffff2eb644467508 x16: 0000000000000138 x15: 0000000000000002 [ 1.208907] x14: 0000000000000000 x13: ffff2eb6400d8080 x12: 00000000ffffff00 [ 1.216378] x11: 0000000000000000 x10: ffff2eb6400d8080 x9 : ffff2eb697adca80 [ 1.223850] x8 : ffff2eb697ad3cc0 x7 : 0000000100000000 x6 : 0000000000000001 [ 1.231324] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000007a6 [ 1.238795] x2 : 0000000000000000 x1 : 00000000000001ce x0 : 00000000ffffff92 [ 1.246267] Call trace: [ 1.248824] nxp_fspi_exec_op+0xb04/0xb64 [ 1.253031] spi_mem_exec_op+0x3a0/0x430 [ 1.257139] spi_nor_read_id+0x80/0xcc [ 1.261065] spi_nor_scan+0x1ec/0xf10 [ 1.264901] spi_nor_probe+0x108/0x2fc [ 1.268828] spi_mem_probe+0x6c/0xbc [ 1.272574] spi_probe+0x84/0xe4 [ 1.275958] really_probe+0xbc/0x29c [ 1.279713] __driver_probe_device+0x78/0x12c [ 1.284277] driver_probe_device+0xd8/0x15c [ 1.288660] __device_attach_driver+0xb8/0x134 [ 1.293316] bus_for_each_drv+0x88/0xe8 [ 1.297337] __device_attach+0xa0/0x190 [ 1.301353] device_initial_probe+0x14/0x20 [ 1.305734] bus_probe_device+0xac/0xb0 [ 1.309752] device_add+0x5d0/0x790 [ 1.313408] __spi_add_device+0x134/0x204 [ 1.317606] of_register_spi_device+0x3b4/0x590 [ 1.322348] spi_register_controller+0x47c/0x754 [ 1.327181] devm_spi_register_controller+0x4c/0xa4 [ 1.332289] nxp_fspi_probe+0x1cc/0x2b0 [ 1.336307] platform_probe+0x68/0xc4 [ 1.340145] really_probe+0xbc/0x29c [ 1.343893] __driver_probe_device+0x78/0x12c [ 1.348457] driver_probe_device+0xd8/0x15c [ 1.352838] __driver_attach+0x90/0x19c [ 1.356857] bus_for_each_dev+0x7c/0xdc [ 1.360877] driver_attach+0x24/0x30 [ 1.364624] bus_add_driver+0xe4/0x208 [ 1.368552] driver_register+0x5c/0x124 [ 1.372573] __platform_driver_register+0x28/0x34 [ 1.377497] nxp_fspi_driver_init+0x1c/0x28 [ 1.381888] do_one_initcall+0x80/0x1c8 [ 1.385908] kernel_init_freeable+0x1c4/0x28c [ 1.390472] kernel_init+0x20/0x1d8 [ 1.394138] ret_from_fork+0x10/0x20 [ 1.397885] ---[ end trace 0000000000000000 ]--- [ 1.407908] ------------[ cut here ]------------", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53052", "url": "https://ubuntu.com/security/CVE-2024-53052", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/rw: fix missing NOWAIT check for O_DIRECT start write When io_uring starts a write, it'll call kiocb_start_write() to bump the super block rwsem, preventing any freezes from happening while that write is in-flight. The freeze side will grab that rwsem for writing, excluding any new writers from happening and waiting for existing writes to finish. But io_uring unconditionally uses kiocb_start_write(), which will block if someone is currently attempting to freeze the mount point. This causes a deadlock where freeze is waiting for previous writes to complete, but the previous writes cannot complete, as the task that is supposed to complete them is blocked waiting on starting a new write. This results in the following stuck trace showing that dependency with the write blocked starting a new write: task:fio state:D stack:0 pid:886 tgid:886 ppid:876 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_rwsem_wait+0x1e8/0x3f8 __percpu_down_read+0xe8/0x500 io_write+0xbb8/0xff8 io_issue_sqe+0x10c/0x1020 io_submit_sqes+0x614/0x2110 __arm64_sys_io_uring_enter+0x524/0x1038 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 INFO: task fsfreeze:7364 blocked for more than 15 seconds. Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963 with the attempting freezer stuck trying to grab the rwsem: task:fsfreeze state:D stack:0 pid:7364 tgid:7364 ppid:995 Call trace: __switch_to+0x1d8/0x348 __schedule+0x8e8/0x2248 schedule+0x110/0x3f0 percpu_down_write+0x2b0/0x680 freeze_super+0x248/0x8a8 do_vfs_ioctl+0x149c/0x1b18 __arm64_sys_ioctl+0xd0/0x1a0 invoke_syscall+0x74/0x268 el0_svc_common.constprop.0+0x160/0x238 do_el0_svc+0x44/0x60 el0_svc+0x44/0xb0 el0t_64_sync_handler+0x118/0x128 el0t_64_sync+0x168/0x170 Fix this by having the io_uring side honor IOCB_NOWAIT, and only attempt a blocking grab of the super block rwsem if it isn't set. For normal issue where IOCB_NOWAIT would always be set, this returns -EAGAIN which will have io_uring core issue a blocking attempt of the write. That will in turn also get completions run, ensuring forward progress. Since freezing requires CAP_SYS_ADMIN in the first place, this isn't something that can be triggered by a regular user.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50213", "url": "https://ubuntu.com/security/CVE-2024-50213", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tests: hdmi: Fix memory leaks in drm_display_mode_from_cea_vic() modprobe drm_hdmi_state_helper_test and then rmmod it, the following memory leak occurs. The `mode` allocated in drm_mode_duplicate() called by drm_display_mode_from_cea_vic() is not freed, which cause the memory leak: \tunreferenced object 0xffffff80ccd18100 (size 128): \t comm \"kunit_try_catch\", pid 1851, jiffies 4295059695 \t hex dump (first 32 bytes): \t 57 62 00 00 80 02 90 02 f0 02 20 03 00 00 e0 01 Wb........ ..... \t ea 01 ec 01 0d 02 00 00 0a 00 00 00 00 00 00 00 ................ \t backtrace (crc c2f1aa95): \t [<000000000f10b11b>] kmemleak_alloc+0x34/0x40 \t [<000000001cd4cf73>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<00000000f1f3cffa>] drm_mode_duplicate+0x44/0x19c \t [<000000008cbeef13>] drm_display_mode_from_cea_vic+0x88/0x98 \t [<0000000019daaacf>] 0xffffffedc11ae69c \t [<000000000aad0f85>] kunit_try_run_case+0x13c/0x3ac \t [<00000000a9210bac>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<000000000a0b2e9e>] kthread+0x2e8/0x374 \t [<00000000bd668858>] ret_from_fork+0x10/0x20 \t...... Free `mode` by using drm_kunit_display_mode_from_cea_vic() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50214", "url": "https://ubuntu.com/security/CVE-2024-50214", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/connector: hdmi: Fix memory leak in drm_display_mode_from_cea_vic() modprobe drm_connector_test and then rmmod drm_connector_test, the following memory leak occurs. The `mode` allocated in drm_mode_duplicate() called by drm_display_mode_from_cea_vic() is not freed, which cause the memory leak: \tunreferenced object 0xffffff80cb0ee400 (size 128): \t comm \"kunit_try_catch\", pid 1948, jiffies 4294950339 \t hex dump (first 32 bytes): \t 14 44 02 00 80 07 d8 07 04 08 98 08 00 00 38 04 .D............8. \t 3c 04 41 04 65 04 00 00 05 00 00 00 00 00 00 00 <.A.e........... \t backtrace (crc 90e9585c): \t [<00000000ec42e3d7>] kmemleak_alloc+0x34/0x40 \t [<00000000d0ef055a>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<00000000c2062161>] drm_mode_duplicate+0x44/0x19c \t [<00000000f96c74aa>] drm_display_mode_from_cea_vic+0x88/0x98 \t [<00000000d8f2c8b4>] 0xffffffdc982a4868 \t [<000000005d164dbc>] kunit_try_run_case+0x13c/0x3ac \t [<000000006fb23398>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<000000006ea56ca0>] kthread+0x2e8/0x374 \t [<000000000676063f>] ret_from_fork+0x10/0x20 \t...... Free `mode` by using drm_kunit_display_mode_from_cea_vic() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50215", "url": "https://ubuntu.com/security/CVE-2024-50215", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nvmet-auth: assign dh_key to NULL after kfree_sensitive ctrl->dh_key might be used across multiple calls to nvmet_setup_dhgroup() for the same controller. So it's better to nullify it after release on error path in order to avoid double free later in nvmet_destroy_auth(). Found by Linux Verification Center (linuxtesting.org) with Svace.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50216", "url": "https://ubuntu.com/security/CVE-2024-50216", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xfs: fix finding a last resort AG in xfs_filestream_pick_ag When the main loop in xfs_filestream_pick_ag fails to find a suitable AG it tries to just pick the online AG. But the loop for that uses args->pag as loop iterator while the later code expects pag to be set. Fix this by reusing the max_pag case for this last resort, and also add a check for impossible case of no AG just to make sure that the uninitialized pag doesn't even escape in theory.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50217", "url": "https://ubuntu.com/security/CVE-2024-50217", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix use-after-free of block device file in __btrfs_free_extra_devids() Mounting btrfs from two images (which have the same one fsid and two different dev_uuids) in certain executing order may trigger an UAF for variable 'device->bdev_file' in __btrfs_free_extra_devids(). And following are the details: 1. Attach image_1 to loop0, attach image_2 to loop1, and scan btrfs devices by ioctl(BTRFS_IOC_SCAN_DEV): / btrfs_device_1 ? loop0 fs_device \\ btrfs_device_2 ? loop1 2. mount /dev/loop0 /mnt btrfs_open_devices btrfs_device_1->bdev_file = btrfs_get_bdev_and_sb(loop0) btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree fail: btrfs_close_devices // -ENOMEM \t btrfs_close_bdev(btrfs_device_1) fput(btrfs_device_1->bdev_file) \t // btrfs_device_1->bdev_file is freed \t btrfs_close_bdev(btrfs_device_2) fput(btrfs_device_2->bdev_file) 3. mount /dev/loop1 /mnt btrfs_open_devices btrfs_get_bdev_and_sb(&bdev_file) // EIO, btrfs_device_1->bdev_file is not assigned, // which points to a freed memory area btrfs_device_2->bdev_file = btrfs_get_bdev_and_sb(loop1) btrfs_fill_super open_ctree btrfs_free_extra_devids if (btrfs_device_1->bdev_file) fput(btrfs_device_1->bdev_file) // UAF ! Fix it by setting 'device->bdev_file' as 'NULL' after closing the btrfs_device in btrfs_close_one_device().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53043", "url": "https://ubuntu.com/security/CVE-2024-53043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mctp i2c: handle NULL header address daddr can be NULL if there is no neighbour table entry present, in that case the tx packet should be dropped. saddr will usually be set by MCTP core, but check for NULL in case a packet is transmitted by a different protocol.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50303", "url": "https://ubuntu.com/security/CVE-2024-50303", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: resource,kexec: walk_system_ram_res_rev must retain resource flags walk_system_ram_res_rev() erroneously discards resource flags when passing the information to the callback. This causes systems with IORESOURCE_SYSRAM_DRIVER_MANAGED memory to have these resources selected during kexec to store kexec buffers if that memory happens to be at placed above normal system ram. This leads to undefined behavior after reboot. If the kexec buffer is never touched, nothing happens. If the kexec buffer is touched, it could lead to a crash (like below) or undefined behavior. Tested on a system with CXL memory expanders with driver managed memory, TPM enabled, and CONFIG_IMA_KEXEC=y. Adding printk's showed the flags were being discarded and as a result the check for IORESOURCE_SYSRAM_DRIVER_MANAGED passes. find_next_iomem_res: name(System RAM (kmem)) \t\t start(10000000000) \t\t end(1034fffffff) \t\t flags(83000200) locate_mem_hole_top_down: start(10000000000) end(1034fffffff) flags(0) [.] BUG: unable to handle page fault for address: ffff89834ffff000 [.] #PF: supervisor read access in kernel mode [.] #PF: error_code(0x0000) - not-present page [.] PGD c04c8bf067 P4D c04c8bf067 PUD c04c8be067 PMD 0 [.] Oops: 0000 [#1] SMP [.] RIP: 0010:ima_restore_measurement_list+0x95/0x4b0 [.] RSP: 0018:ffffc900000d3a80 EFLAGS: 00010286 [.] RAX: 0000000000001000 RBX: 0000000000000000 RCX: ffff89834ffff000 [.] RDX: 0000000000000018 RSI: ffff89834ffff000 RDI: ffff89834ffff018 [.] RBP: ffffc900000d3ba0 R08: 0000000000000020 R09: ffff888132b8a900 [.] R10: 4000000000000000 R11: 000000003a616d69 R12: 0000000000000000 [.] R13: ffffffff8404ac28 R14: 0000000000000000 R15: ffff89834ffff000 [.] FS: 0000000000000000(0000) GS:ffff893d44640000(0000) knlGS:0000000000000000 [.] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [.] ata5: SATA link down (SStatus 0 SControl 300) [.] CR2: ffff89834ffff000 CR3: 000001034d00f001 CR4: 0000000000770ef0 [.] PKRU: 55555554 [.] Call Trace: [.] [.] ? __die+0x78/0xc0 [.] ? page_fault_oops+0x2a8/0x3a0 [.] ? exc_page_fault+0x84/0x130 [.] ? asm_exc_page_fault+0x22/0x30 [.] ? ima_restore_measurement_list+0x95/0x4b0 [.] ? template_desc_init_fields+0x317/0x410 [.] ? crypto_alloc_tfm_node+0x9c/0xc0 [.] ? init_ima_lsm+0x30/0x30 [.] ima_load_kexec_buffer+0x72/0xa0 [.] ima_init+0x44/0xa0 [.] __initstub__kmod_ima__373_1201_init_ima7+0x1e/0xb0 [.] ? init_ima_lsm+0x30/0x30 [.] do_one_initcall+0xad/0x200 [.] ? idr_alloc_cyclic+0xaa/0x110 [.] ? new_slab+0x12c/0x420 [.] ? new_slab+0x12c/0x420 [.] ? number+0x12a/0x430 [.] ? sysvec_apic_timer_interrupt+0xa/0x80 [.] ? asm_sysvec_apic_timer_interrupt+0x16/0x20 [.] ? parse_args+0xd4/0x380 [.] ? parse_args+0x14b/0x380 [.] kernel_init_freeable+0x1c1/0x2b0 [.] ? rest_init+0xb0/0xb0 [.] kernel_init+0x16/0x1a0 [.] ret_from_fork+0x2f/0x40 [.] ? rest_init+0xb0/0xb0 [.] ret_from_fork_asm+0x11/0x20 [.] ", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50218", "url": "https://ubuntu.com/security/CVE-2024-50218", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow Syzbot reported a kernel BUG in ocfs2_truncate_inline. There are two reasons for this: first, the parameter value passed is greater than ocfs2_max_inline_data_with_xattr, second, the start and end parameters of ocfs2_truncate_inline are \"unsigned int\". So, we need to add a sanity check for byte_start and byte_len right before ocfs2_truncate_inline() in ocfs2_remove_inode_range(), if they are greater than ocfs2_max_inline_data_with_xattr return -EINVAL.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50219", "url": "https://ubuntu.com/security/CVE-2024-50219", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50263", "url": "https://ubuntu.com/security/CVE-2024-50263", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fork: only invoke khugepaged, ksm hooks if no error There is no reason to invoke these hooks early against an mm that is in an incomplete state. The change in commit d24062914837 (\"fork: use __mt_dup() to duplicate maple tree in dup_mmap()\") makes this more pertinent as we may be in a state where entries in the maple tree are not yet consistent. Their placement early in dup_mmap() only appears to have been meaningful for early error checking, and since functionally it'd require a very small allocation to fail (in practice 'too small to fail') that'd only occur in the most dire circumstances, meaning the fork would fail or be OOM'd in any case. Since both khugepaged and KSM tracking are there to provide optimisations to memory performance rather than critical functionality, it doesn't really matter all that much if, under such dire memory pressure, we fail to register an mm with these. As a result, we follow the example of commit d2081b2bf819 (\"mm: khugepaged: make khugepaged_enter() void function\") and make ksm_fork() a void function also. We only expose the mm to these functions once we are done with them and only if no error occurred in the fork operation.", "cve_priority": "medium", "cve_public_date": "2024-11-11 14:15:00 UTC" }, { "cve": "CVE-2024-50220", "url": "https://ubuntu.com/security/CVE-2024-50220", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fork: do not invoke uffd on fork if error occurs Patch series \"fork: do not expose incomplete mm on fork\". During fork we may place the virtual memory address space into an inconsistent state before the fork operation is complete. In addition, we may encounter an error during the fork operation that indicates that the virtual memory address space is invalidated. As a result, we should not be exposing it in any way to external machinery that might interact with the mm or VMAs, machinery that is not designed to deal with incomplete state. We specifically update the fork logic to defer khugepaged and ksm to the end of the operation and only to be invoked if no error arose, and disallow uffd from observing fork events should an error have occurred. This patch (of 2): Currently on fork we expose the virtual address space of a process to userland unconditionally if uffd is registered in VMAs, regardless of whether an error arose in the fork. This is performed in dup_userfaultfd_complete() which is invoked unconditionally, and performs two duties - invoking registered handlers for the UFFD_EVENT_FORK event via dup_fctx(), and clearing down userfaultfd_fork_ctx objects established in dup_userfaultfd(). This is problematic, because the virtual address space may not yet be correctly initialised if an error arose. The change in commit d24062914837 (\"fork: use __mt_dup() to duplicate maple tree in dup_mmap()\") makes this more pertinent as we may be in a state where entries in the maple tree are not yet consistent. We address this by, on fork error, ensuring that we roll back state that we would otherwise expect to clean up through the event being handled by userland and perform the memory freeing duty otherwise performed by dup_userfaultfd_complete(). We do this by implementing a new function, dup_userfaultfd_fail(), which performs the same loop, only decrementing reference counts. Note that we perform mmgrab() on the parent and child mm's, however userfaultfd_ctx_put() will mmdrop() this once the reference count drops to zero, so we will avoid memory leaks correctly here.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53047", "url": "https://ubuntu.com/security/CVE-2024-53047", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: init: protect sched with rcu_read_lock Enabling CONFIG_PROVE_RCU_LIST with its dependence CONFIG_RCU_EXPERT creates this splat when an MPTCP socket is created: ============================= WARNING: suspicious RCU usage 6.12.0-rc2+ #11 Not tainted ----------------------------- net/mptcp/sched.c:44 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 no locks held by mptcp_connect/176. stack backtrace: CPU: 0 UID: 0 PID: 176 Comm: mptcp_connect Not tainted 6.12.0-rc2+ #11 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl (lib/dump_stack.c:123) lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822) mptcp_sched_find (net/mptcp/sched.c:44 (discriminator 7)) mptcp_init_sock (net/mptcp/protocol.c:2867 (discriminator 1)) ? sock_init_data_uid (arch/x86/include/asm/atomic.h:28) inet_create.part.0.constprop.0 (net/ipv4/af_inet.c:386) ? __sock_create (include/linux/rcupdate.h:347 (discriminator 1)) __sock_create (net/socket.c:1576) __sys_socket (net/socket.c:1671) ? __pfx___sys_socket (net/socket.c:1712) ? do_user_addr_fault (arch/x86/mm/fault.c:1419 (discriminator 1)) __x64_sys_socket (net/socket.c:1728) do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1)) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) That's because when the socket is initialised, rcu_read_lock() is not used despite the explicit comment written above the declaration of mptcp_sched_find() in sched.c. Adding the missing lock/unlock avoids the warning.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50221", "url": "https://ubuntu.com/security/CVE-2024-50221", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: Vangogh: Fix kernel memory out of bounds write KASAN reports that the GPU metrics table allocated in vangogh_tables_init() is not large enough for the memset done in smu_cmn_init_soft_gpu_metrics(). Condensed report follows: [ 33.861314] BUG: KASAN: slab-out-of-bounds in smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu] [ 33.861799] Write of size 168 at addr ffff888129f59500 by task mangoapp/1067 ... [ 33.861808] CPU: 6 UID: 1000 PID: 1067 Comm: mangoapp Tainted: G W 6.12.0-rc4 #356 1a56f59a8b5182eeaf67eb7cb8b13594dd23b544 [ 33.861816] Tainted: [W]=WARN [ 33.861818] Hardware name: Valve Galileo/Galileo, BIOS F7G0107 12/01/2023 [ 33.861822] Call Trace: [ 33.861826] [ 33.861829] dump_stack_lvl+0x66/0x90 [ 33.861838] print_report+0xce/0x620 [ 33.861853] kasan_report+0xda/0x110 [ 33.862794] kasan_check_range+0xfd/0x1a0 [ 33.862799] __asan_memset+0x23/0x40 [ 33.862803] smu_cmn_init_soft_gpu_metrics+0x73/0x200 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.863306] vangogh_get_gpu_metrics_v2_4+0x123/0xad0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.864257] vangogh_common_get_gpu_metrics+0xb0c/0xbc0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.865682] amdgpu_dpm_get_gpu_metrics+0xcc/0x110 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.866160] amdgpu_get_gpu_metrics+0x154/0x2d0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.867135] dev_attr_show+0x43/0xc0 [ 33.867147] sysfs_kf_seq_show+0x1f1/0x3b0 [ 33.867155] seq_read_iter+0x3f8/0x1140 [ 33.867173] vfs_read+0x76c/0xc50 [ 33.867198] ksys_read+0xfb/0x1d0 [ 33.867214] do_syscall_64+0x90/0x160 ... [ 33.867353] Allocated by task 378 on cpu 7 at 22.794876s: [ 33.867358] kasan_save_stack+0x33/0x50 [ 33.867364] kasan_save_track+0x17/0x60 [ 33.867367] __kasan_kmalloc+0x87/0x90 [ 33.867371] vangogh_init_smc_tables+0x3f9/0x840 [amdgpu] [ 33.867835] smu_sw_init+0xa32/0x1850 [amdgpu] [ 33.868299] amdgpu_device_init+0x467b/0x8d90 [amdgpu] [ 33.868733] amdgpu_driver_load_kms+0x19/0xf0 [amdgpu] [ 33.869167] amdgpu_pci_probe+0x2d6/0xcd0 [amdgpu] [ 33.869608] local_pci_probe+0xda/0x180 [ 33.869614] pci_device_probe+0x43f/0x6b0 Empirically we can confirm that the former allocates 152 bytes for the table, while the latter memsets the 168 large block. Root cause appears that when GPU metrics tables for v2_4 parts were added it was not considered to enlarge the table to fit. The fix in this patch is rather \"brute force\" and perhaps later should be done in a smarter way, by extracting and consolidating the part version to size logic to a common helper, instead of brute forcing the largest possible allocation. Nevertheless, for now this works and fixes the out of bounds write. v2: * Drop impossible v3_0 case. (Mario) (cherry picked from commit 0880f58f9609f0200483a49429af0f050d281703)", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50222", "url": "https://ubuntu.com/security/CVE-2024-50222", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iov_iter: fix copy_page_from_iter_atomic() if KMAP_LOCAL_FORCE_MAP generic/077 on x86_32 CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP=y with highmem, on huge=always tmpfs, issues a warning and then hangs (interruptibly): WARNING: CPU: 5 PID: 3517 at mm/highmem.c:622 kunmap_local_indexed+0x62/0xc9 CPU: 5 UID: 0 PID: 3517 Comm: cp Not tainted 6.12.0-rc4 #2 ... copy_page_from_iter_atomic+0xa6/0x5ec generic_perform_write+0xf6/0x1b4 shmem_file_write_iter+0x54/0x67 Fix copy_page_from_iter_atomic() by limiting it in that case (include/linux/skbuff.h skb_frag_must_loop() does similar). But going forward, perhaps CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP is too surprising, has outlived its usefulness, and should just be removed?", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50223", "url": "https://ubuntu.com/security/CVE-2024-50223", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sched/numa: Fix the potential null pointer dereference in task_numa_work() When running stress-ng-vm-segv test, we found a null pointer dereference error in task_numa_work(). Here is the backtrace: [323676.066985] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020 ...... [323676.067108] CPU: 35 PID: 2694524 Comm: stress-ng-vm-se ...... [323676.067113] pstate: 23401009 (nzCv daif +PAN -UAO +TCO +DIT +SSBS BTYPE=--) [323676.067115] pc : vma_migratable+0x1c/0xd0 [323676.067122] lr : task_numa_work+0x1ec/0x4e0 [323676.067127] sp : ffff8000ada73d20 [323676.067128] x29: ffff8000ada73d20 x28: 0000000000000000 x27: 000000003e89f010 [323676.067130] x26: 0000000000080000 x25: ffff800081b5c0d8 x24: ffff800081b27000 [323676.067133] x23: 0000000000010000 x22: 0000000104d18cc0 x21: ffff0009f7158000 [323676.067135] x20: 0000000000000000 x19: 0000000000000000 x18: ffff8000ada73db8 [323676.067138] x17: 0001400000000000 x16: ffff800080df40b0 x15: 0000000000000035 [323676.067140] x14: ffff8000ada73cc8 x13: 1fffe0017cc72001 x12: ffff8000ada73cc8 [323676.067142] x11: ffff80008001160c x10: ffff000be639000c x9 : ffff8000800f4ba4 [323676.067145] x8 : ffff000810375000 x7 : ffff8000ada73974 x6 : 0000000000000001 [323676.067147] x5 : 0068000b33e26707 x4 : 0000000000000001 x3 : ffff0009f7158000 [323676.067149] x2 : 0000000000000041 x1 : 0000000000004400 x0 : 0000000000000000 [323676.067152] Call trace: [323676.067153] vma_migratable+0x1c/0xd0 [323676.067155] task_numa_work+0x1ec/0x4e0 [323676.067157] task_work_run+0x78/0xd8 [323676.067161] do_notify_resume+0x1ec/0x290 [323676.067163] el0_svc+0x150/0x160 [323676.067167] el0t_64_sync_handler+0xf8/0x128 [323676.067170] el0t_64_sync+0x17c/0x180 [323676.067173] Code: d2888001 910003fd f9000bf3 aa0003f3 (f9401000) [323676.067177] SMP: stopping secondary CPUs [323676.070184] Starting crashdump kernel... stress-ng-vm-segv in stress-ng is used to stress test the SIGSEGV error handling function of the system, which tries to cause a SIGSEGV error on return from unmapping the whole address space of the child process. Normally this program will not cause kernel crashes. But before the munmap system call returns to user mode, a potential task_numa_work() for numa balancing could be added and executed. In this scenario, since the child process has no vma after munmap, the vma_next() in task_numa_work() will return a null pointer even if the vma iterator restarts from 0. Recheck the vma pointer before dereferencing it in task_numa_work().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53053", "url": "https://ubuntu.com/security/CVE-2024-53053", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Fix another deadlock during RTC update If ufshcd_rtc_work calls ufshcd_rpm_put_sync() and the pm's usage_count is 0, we will enter the runtime suspend callback. However, the runtime suspend callback will wait to flush ufshcd_rtc_work, causing a deadlock. Replace ufshcd_rpm_put_sync() with ufshcd_rpm_put() to avoid the deadlock.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53075", "url": "https://ubuntu.com/security/CVE-2024-53075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: riscv: Prevent a bad reference count on CPU nodes When populating cache leaves we previously fetched the CPU device node at the very beginning. But when ACPI is enabled we go through a specific branch which returns early and does not call 'of_node_put' for the node that was acquired. Since we are not using a CPU device node for the ACPI code anyways, we can simply move the initialization of it just passed the ACPI block, and we are guaranteed to have an 'of_node_put' call for the acquired node. This prevents a bad reference count of the CPU device node. Moreover, the previous function did not check for errors when acquiring the device node, so a return -ENOENT has been added for that case.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50224", "url": "https://ubuntu.com/security/CVE-2024-50224", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: spi: spi-fsl-dspi: Fix crash when not using GPIO chip select Add check for the return value of spi_get_csgpiod() to avoid passing a NULL pointer to gpiod_direction_output(), preventing a crash when GPIO chip select is not used. Fix below crash: [ 4.251960] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 4.260762] Mem abort info: [ 4.263556] ESR = 0x0000000096000004 [ 4.267308] EC = 0x25: DABT (current EL), IL = 32 bits [ 4.272624] SET = 0, FnV = 0 [ 4.275681] EA = 0, S1PTW = 0 [ 4.278822] FSC = 0x04: level 0 translation fault [ 4.283704] Data abort info: [ 4.286583] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 4.292074] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 4.297130] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 4.302445] [0000000000000000] user address but active_mm is swapper [ 4.308805] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 4.315072] Modules linked in: [ 4.318124] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc4-next-20241023-00008-ga20ec42c5fc1 #359 [ 4.328130] Hardware name: LS1046A QDS Board (DT) [ 4.332832] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 4.339794] pc : gpiod_direction_output+0x34/0x5c [ 4.344505] lr : gpiod_direction_output+0x18/0x5c [ 4.349208] sp : ffff80008003b8f0 [ 4.352517] x29: ffff80008003b8f0 x28: 0000000000000000 x27: ffffc96bcc7e9068 [ 4.359659] x26: ffffc96bcc6e00b0 x25: ffffc96bcc598398 x24: ffff447400132810 [ 4.366800] x23: 0000000000000000 x22: 0000000011e1a300 x21: 0000000000020002 [ 4.373940] x20: 0000000000000000 x19: 0000000000000000 x18: ffffffffffffffff [ 4.381081] x17: ffff44740016e600 x16: 0000000500000003 x15: 0000000000000007 [ 4.388221] x14: 0000000000989680 x13: 0000000000020000 x12: 000000000000001e [ 4.395362] x11: 0044b82fa09b5a53 x10: 0000000000000019 x9 : 0000000000000008 [ 4.402502] x8 : 0000000000000002 x7 : 0000000000000007 x6 : 0000000000000000 [ 4.409641] x5 : 0000000000000200 x4 : 0000000002000000 x3 : 0000000000000000 [ 4.416781] x2 : 0000000000022202 x1 : 0000000000000000 x0 : 0000000000000000 [ 4.423921] Call trace: [ 4.426362] gpiod_direction_output+0x34/0x5c (P) [ 4.431067] gpiod_direction_output+0x18/0x5c (L) [ 4.435771] dspi_setup+0x220/0x334", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50225", "url": "https://ubuntu.com/security/CVE-2024-50225", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix error propagation of split bios The purpose of btrfs_bbio_propagate_error() shall be propagating an error of split bio to its original btrfs_bio, and tell the error to the upper layer. However, it's not working well on some cases. * Case 1. Immediate (or quick) end_bio with an error When btrfs sends btrfs_bio to mirrored devices, btrfs calls btrfs_bio_end_io() when all the mirroring bios are completed. If that btrfs_bio was split, it is from btrfs_clone_bioset and its end_io function is btrfs_orig_write_end_io. For this case, btrfs_bbio_propagate_error() accesses the orig_bbio's bio context to increase the error count. That works well in most cases. However, if the end_io is called enough fast, orig_bbio's (remaining part after split) bio context may not be properly set at that time. Since the bio context is set when the orig_bbio (the last btrfs_bio) is sent to devices, that might be too late for earlier split btrfs_bio's completion. That will result in NULL pointer dereference. That bug is easily reproducible by running btrfs/146 on zoned devices [1] and it shows the following trace. [1] You need raid-stripe-tree feature as it create \"-d raid0 -m raid1\" FS. BUG: kernel NULL pointer dereference, address: 0000000000000020 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 UID: 0 PID: 13 Comm: kworker/u32:1 Not tainted 6.11.0-rc7-BTRFS-ZNS+ #474 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Workqueue: writeback wb_workfn (flush-btrfs-5) RIP: 0010:btrfs_bio_end_io+0xae/0xc0 [btrfs] BTRFS error (device dm-0): bdev /dev/mapper/error-test errs: wr 2, rd 0, flush 0, corrupt 0, gen 0 RSP: 0018:ffffc9000006f248 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888005a7f080 RCX: ffffc9000006f1dc RDX: 0000000000000000 RSI: 000000000000000a RDI: ffff888005a7f080 RBP: ffff888011dfc540 R08: 0000000000000000 R09: 0000000000000001 R10: ffffffff82e508e0 R11: 0000000000000005 R12: ffff88800ddfbe58 R13: ffff888005a7f080 R14: ffff888005a7f158 R15: ffff888005a7f158 FS: 0000000000000000(0000) GS:ffff88803ea80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000020 CR3: 0000000002e22006 CR4: 0000000000370ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __die_body.cold+0x19/0x26 ? page_fault_oops+0x13e/0x2b0 ? _printk+0x58/0x73 ? do_user_addr_fault+0x5f/0x750 ? exc_page_fault+0x76/0x240 ? asm_exc_page_fault+0x22/0x30 ? btrfs_bio_end_io+0xae/0xc0 [btrfs] ? btrfs_log_dev_io_error+0x7f/0x90 [btrfs] btrfs_orig_write_end_io+0x51/0x90 [btrfs] dm_submit_bio+0x5c2/0xa50 [dm_mod] ? find_held_lock+0x2b/0x80 ? blk_try_enter_queue+0x90/0x1e0 __submit_bio+0xe0/0x130 ? ktime_get+0x10a/0x160 ? lockdep_hardirqs_on+0x74/0x100 submit_bio_noacct_nocheck+0x199/0x410 btrfs_submit_bio+0x7d/0x150 [btrfs] btrfs_submit_chunk+0x1a1/0x6d0 [btrfs] ? lockdep_hardirqs_on+0x74/0x100 ? __folio_start_writeback+0x10/0x2c0 btrfs_submit_bbio+0x1c/0x40 [btrfs] submit_one_bio+0x44/0x60 [btrfs] submit_extent_folio+0x13f/0x330 [btrfs] ? btrfs_set_range_writeback+0xa3/0xd0 [btrfs] extent_writepage_io+0x18b/0x360 [btrfs] extent_write_locked_range+0x17c/0x340 [btrfs] ? __pfx_end_bbio_data_write+0x10/0x10 [btrfs] run_delalloc_cow+0x71/0xd0 [btrfs] btrfs_run_delalloc_range+0x176/0x500 [btrfs] ? find_lock_delalloc_range+0x119/0x260 [btrfs] writepage_delalloc+0x2ab/0x480 [btrfs] extent_write_cache_pages+0x236/0x7d0 [btrfs] btrfs_writepages+0x72/0x130 [btrfs] do_writepages+0xd4/0x240 ? find_held_lock+0x2b/0x80 ? wbc_attach_and_unlock_inode+0x12c/0x290 ? wbc_attach_and_unlock_inode+0x12c/0x29 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53054", "url": "https://ubuntu.com/security/CVE-2024-53054", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50226", "url": "https://ubuntu.com/security/CVE-2024-50226", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cxl/port: Fix use-after-free, permit out-of-order decoder shutdown In support of investigating an initialization failure report [1], cxl_test was updated to register mock memory-devices after the mock root-port/bus device had been registered. That led to cxl_test crashing with a use-after-free bug with the following signature: cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem0:decoder7.0 @ 0 next: cxl_switch_uport.0 nr_eps: 1 nr_targets: 1 cxl_port_attach_region: cxl region3: cxl_host_bridge.0:port3 decoder3.0 add: mem4:decoder14.0 @ 1 next: cxl_switch_uport.0 nr_eps: 2 nr_targets: 1 cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[0] = cxl_switch_dport.0 for mem0:decoder7.0 @ 0 1) cxl_port_setup_targets: cxl region3: cxl_switch_uport.0:port6 target[1] = cxl_switch_dport.4 for mem4:decoder14.0 @ 1 [..] cxld_unregister: cxl decoder14.0: cxl_region_decode_reset: cxl_region region3: mock_decoder_reset: cxl_port port3: decoder3.0 reset 2) mock_decoder_reset: cxl_port port3: decoder3.0: out of order reset, expected decoder3.1 cxl_endpoint_decoder_release: cxl decoder14.0: [..] cxld_unregister: cxl decoder7.0: 3) cxl_region_decode_reset: cxl_region region3: Oops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6bc3: 0000 [#1] PREEMPT SMP PTI [..] RIP: 0010:to_cxl_port+0x8/0x60 [cxl_core] [..] Call Trace: cxl_region_decode_reset+0x69/0x190 [cxl_core] cxl_region_detach+0xe8/0x210 [cxl_core] cxl_decoder_kill_region+0x27/0x40 [cxl_core] cxld_unregister+0x5d/0x60 [cxl_core] At 1) a region has been established with 2 endpoint decoders (7.0 and 14.0). Those endpoints share a common switch-decoder in the topology (3.0). At teardown, 2), decoder14.0 is the first to be removed and hits the \"out of order reset case\" in the switch decoder. The effect though is that region3 cleanup is aborted leaving it in-tact and referencing decoder14.0. At 3) the second attempt to teardown region3 trips over the stale decoder14.0 object which has long since been deleted. The fix here is to recognize that the CXL specification places no mandate on in-order shutdown of switch-decoders, the driver enforces in-order allocation, and hardware enforces in-order commit. So, rather than fail and leave objects dangling, always remove them. In support of making cxl_region_decode_reset() always succeed, cxl_region_invalidate_memregion() failures are turned into warnings. Crashing the kernel is ok there since system integrity is at risk if caches cannot be managed around physical address mutation events like CXL region destruction. A new device_for_each_child_reverse_from() is added to cleanup port->commit_end after all dependent decoders have been disabled. In other words if decoders are allocated 0->1->2 and disabled 1->2->0 then port->commit_end only decrements from 2 after 2 has been disabled, and it decrements all the way to zero since 1 was disabled previously.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50227", "url": "https://ubuntu.com/security/CVE-2024-50227", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thunderbolt: Fix KASAN reported stack out-of-bounds read in tb_retimer_scan() KASAN reported following issue: BUG: KASAN: stack-out-of-bounds in tb_retimer_scan+0xffe/0x1550 [thunderbolt] Read of size 4 at addr ffff88810111fc1c by task kworker/u56:0/11 CPU: 0 UID: 0 PID: 11 Comm: kworker/u56:0 Tainted: G U 6.11.0+ #1387 Tainted: [U]=USER Workqueue: thunderbolt0 tb_handle_hotplug [thunderbolt] Call Trace: dump_stack_lvl+0x6c/0x90 print_report+0xd1/0x630 kasan_report+0xdb/0x110 __asan_report_load4_noabort+0x14/0x20 tb_retimer_scan+0xffe/0x1550 [thunderbolt] tb_scan_port+0xa6f/0x2060 [thunderbolt] tb_handle_hotplug+0x17b1/0x3080 [thunderbolt] process_one_work+0x626/0x1100 worker_thread+0x6c8/0xfa0 kthread+0x2c8/0x3a0 ret_from_fork+0x3a/0x80 ret_from_fork_asm+0x1a/0x30 This happens because the loop variable still gets incremented by one so max becomes 3 instead of 2, and this makes the second loop read past the the array declared on the stack. Fix this by assigning to max directly in the loop body.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50228", "url": "https://ubuntu.com/security/CVE-2024-50228", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50229", "url": "https://ubuntu.com/security/CVE-2024-50229", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential deadlock with newly created symlinks Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers memory reclamation involving the filesystem layer, which can result in circular lock dependencies among the reader/writer semaphore nilfs->ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the fs_reclaim pseudo lock. This is because after commit 21fc61c73c39 (\"don't put symlink bodies in pagecache into highmem\"), the gfp flags of the page cache for symbolic links are overwritten to GFP_KERNEL via inode_nohighmem(). This is not a problem for symlinks read from the backing device, because the __GFP_FS flag is dropped after inode_nohighmem() is called. However, when a new symlink is created with nilfs_symlink(), the gfp flags remain overwritten to GFP_KERNEL. Then, memory allocation called from page_symlink() etc. triggers memory reclamation including the FS layer, which may call nilfs_evict_inode() or nilfs_dirty_inode(). And these can cause a deadlock if they are called while nilfs->ns_segctor_sem is held: Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags of newly created symlinks in the same way that nilfs_new_inode() and __nilfs_read_inode() do, as a workaround until we adopt nofs allocation scope consistently or improve the locking constraints.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50230", "url": "https://ubuntu.com/security/CVE-2024-50230", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug due to missing clearing of checked flag Syzbot reported that in directory operations after nilfs2 detects filesystem corruption and degrades to read-only, __block_write_begin_int(), which is called to prepare block writes, may fail the BUG_ON check for accesses exceeding the folio/page size, triggering a kernel bug. This was found to be because the \"checked\" flag of a page/folio was not cleared when it was discarded by nilfs2's own routine, which causes the sanity check of directory entries to be skipped when the directory page/folio is reloaded. So, fix that. This was necessary when the use of nilfs2's own page discard routine was applied to more than just metadata files.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50231", "url": "https://ubuntu.com/security/CVE-2024-50231", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gts-helper: Fix memory leaks in iio_gts_build_avail_scale_table() modprobe iio-test-gts and rmmod it, then the following memory leak occurs: \tunreferenced object 0xffffff80c810be00 (size 64): \t comm \"kunit_try_catch\", pid 1654, jiffies 4294913981 \t hex dump (first 32 bytes): \t 02 00 00 00 08 00 00 00 20 00 00 00 40 00 00 00 ........ ...@... \t 80 00 00 00 00 02 00 00 00 04 00 00 00 08 00 00 ................ \t backtrace (crc a63d875e): \t [<0000000028c1b3c2>] kmemleak_alloc+0x34/0x40 \t [<000000001d6ecc87>] __kmalloc_noprof+0x2bc/0x3c0 \t [<00000000393795c1>] devm_iio_init_iio_gts+0x4b4/0x16f4 \t [<0000000071bb4b09>] 0xffffffdf052a62e0 \t [<000000000315bc18>] 0xffffffdf052a6488 \t [<00000000f9dc55b5>] kunit_try_run_case+0x13c/0x3ac \t [<00000000175a3fd4>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000f505065d>] kthread+0x2e8/0x374 \t [<00000000bbfb0e5d>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cbfe9e70 (size 16): \t comm \"kunit_try_catch\", pid 1658, jiffies 4294914015 \t hex dump (first 16 bytes): \t 10 00 00 00 40 00 00 00 80 00 00 00 00 00 00 00 ....@........... \t backtrace (crc 857f0cb4): \t [<0000000028c1b3c2>] kmemleak_alloc+0x34/0x40 \t [<000000001d6ecc87>] __kmalloc_noprof+0x2bc/0x3c0 \t [<00000000393795c1>] devm_iio_init_iio_gts+0x4b4/0x16f4 \t [<0000000071bb4b09>] 0xffffffdf052a62e0 \t [<000000007d089d45>] 0xffffffdf052a6864 \t [<00000000f9dc55b5>] kunit_try_run_case+0x13c/0x3ac \t [<00000000175a3fd4>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000f505065d>] kthread+0x2e8/0x374 \t [<00000000bbfb0e5d>] ret_from_fork+0x10/0x20 \t...... It includes 5*5 times \"size 64\" memory leaks, which correspond to 5 times test_init_iio_gain_scale() calls with gts_test_gains size 10 (10*size(int)) and gts_test_itimes size 5. It also includes 5*1 times \"size 16\" memory leak, which correspond to one time __test_init_iio_gain_scale() call with gts_test_gains_gain_low size 3 (3*size(int)) and gts_test_itimes size 5. The reason is that the per_time_gains[i] is not freed which is allocated in the \"gts->num_itime\" for loop in iio_gts_build_avail_scale_table().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53076", "url": "https://ubuntu.com/security/CVE-2024-53076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: gts-helper: Fix memory leaks for the error path of iio_gts_build_avail_scale_table() If per_time_scales[i] or per_time_gains[i] kcalloc fails in the for loop of iio_gts_build_avail_scale_table(), the err_free_out will fail to call kfree() each time when i is reduced to 0, so all the per_time_scales[0] and per_time_gains[0] will not be freed, which will cause memory leaks. Fix it by checking if i >= 0.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50232", "url": "https://ubuntu.com/security/CVE-2024-50232", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr() In the ad7124_write_raw() function, parameter val can potentially be zero. This may lead to a division by zero when DIV_ROUND_CLOSEST() is called within ad7124_set_channel_odr(). The ad7124_write_raw() function is invoked through the sequence: iio_write_channel_raw() -> iio_write_channel_attribute() -> iio_channel_write(), with no checks in place to ensure val is non-zero.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50233", "url": "https://ubuntu.com/security/CVE-2024-50233", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: staging: iio: frequency: ad9832: fix division by zero in ad9832_calc_freqreg() In the ad9832_write_frequency() function, clk_get_rate() might return 0. This can lead to a division by zero when calling ad9832_calc_freqreg(). The check if (fout > (clk_get_rate(st->mclk) / 2)) does not protect against the case when fout is 0. The ad9832_write_frequency() function is called from ad9832_write(), and fout is derived from a text buffer, which can contain any value.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53055", "url": "https://ubuntu.com/security/CVE-2024-53055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: fix 6 GHz scan construction If more than 255 colocated APs exist for the set of all APs found during 2.4/5 GHz scanning, then the 6 GHz scan construction will loop forever since the loop variable has type u8, which can never reach the number found when that's bigger than 255, and is stored in a u32 variable. Also move it into the loops to have a smaller scope. Using a u32 there is fine, we limit the number of APs in the scan list and each has a limit on the number of RNR entries due to the frame size. With a limit of 1000 scan results, a frame size upper bound of 4096 (really it's more like ~2300) and a TBTT entry size of at least 11, we get an upper bound for the number of ~372k, well in the bounds of a u32.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50234", "url": "https://ubuntu.com/security/CVE-2024-50234", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlegacy: Clear stale interrupts before resuming device iwl4965 fails upon resume from hibernation on my laptop. The reason seems to be a stale interrupt which isn't being cleared out before interrupts are enabled. We end up with a race beween the resume trying to bring things back up, and the restart work (queued form the interrupt handler) trying to bring things down. Eventually the whole thing blows up. Fix the problem by clearing out any stale interrupts before interrupts get enabled during resume. Here's a debug log of the indicent: [ 12.042589] ieee80211 phy0: il_isr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000 [ 12.042625] ieee80211 phy0: il4965_irq_tasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000 [ 12.042651] iwl4965 0000:10:00.0: RF_KILL bit toggled to enable radio. [ 12.042653] iwl4965 0000:10:00.0: On demand firmware reload [ 12.042690] ieee80211 phy0: il4965_irq_tasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282 [ 12.052207] ieee80211 phy0: il4965_mac_start enter [ 12.052212] ieee80211 phy0: il_prep_station Add STA to driver ID 31: ff:ff:ff:ff:ff:ff [ 12.052244] ieee80211 phy0: il4965_set_hw_ready hardware ready [ 12.052324] ieee80211 phy0: il_apm_init Init card's basic functions [ 12.052348] ieee80211 phy0: il_apm_init L1 Enabled; Disabling L0S [ 12.055727] ieee80211 phy0: il4965_load_bsm Begin load bsm [ 12.056140] ieee80211 phy0: il4965_verify_bsm Begin verify bsm [ 12.058642] ieee80211 phy0: il4965_verify_bsm BSM bootstrap uCode image OK [ 12.058721] ieee80211 phy0: il4965_load_bsm BSM write complete, poll 1 iterations [ 12.058734] ieee80211 phy0: __il4965_up iwl4965 is coming up [ 12.058737] ieee80211 phy0: il4965_mac_start Start UP work done. [ 12.058757] ieee80211 phy0: __il4965_down iwl4965 is going down [ 12.058761] ieee80211 phy0: il_scan_cancel_timeout Scan cancel timeout [ 12.058762] ieee80211 phy0: il_do_scan_abort Not performing scan to abort [ 12.058765] ieee80211 phy0: il_clear_ucode_stations Clearing ucode stations in driver [ 12.058767] ieee80211 phy0: il_clear_ucode_stations No active stations found to be cleared [ 12.058819] ieee80211 phy0: _il_apm_stop Stop card, put in low power state [ 12.058827] ieee80211 phy0: _il_apm_stop_master stop master [ 12.058864] ieee80211 phy0: il4965_clear_free_frames 0 frames on pre-allocated heap on clear. [ 12.058869] ieee80211 phy0: Hardware restart was requested [ 16.132299] iwl4965 0000:10:00.0: START_ALIVE timeout after 4000ms. [ 16.132303] ------------[ cut here ]------------ [ 16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue. [ 16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132390] Modules linked in: ctr ccm sch_fq_codel xt_tcpudp xt_multiport xt_state iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv4 ip_tables x_tables binfmt_misc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdh_generic ecc iTCO_wdt i2c_dev iwl4965 iwlegacy coretemp snd_hda_codec_analog pcspkr psmouse mac80211 snd_hda_codec_generic libarc4 sdhci_pci cqhci sha256_generic sdhci libsha256 firewire_ohci snd_hda_intel snd_intel_dspcfg mmc_core snd_hda_codec snd_hwdep firewire_core led_class iosf_mbi snd_hda_core uhci_hcd lpc_ich crc_itu_t cfg80211 ehci_pci ehci_hcd snd_pcm usbcore mfd_core rfkill snd_timer snd usb_common soundcore video parport_pc parport intel_agp wmi intel_gtt backlight e1000e agpgart evdev [ 16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143 [ 16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010 [ 16.132463] Workqueue: async async_run_entry_fn [ 16.132469] RIP: 0010:ieee80211_reconfig+0x8f/0x14b0 [mac80211] [ 16.132501] Code: da 02 00 0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50235", "url": "https://ubuntu.com/security/CVE-2024-50235", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: clear wdev->cqm_config pointer on free When we free wdev->cqm_config when unregistering, we also need to clear out the pointer since the same wdev/netdev may get re-registered in another network namespace, then destroyed later, running this code again, which results in a double-free.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50236", "url": "https://ubuntu.com/security/CVE-2024-50236", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath10k: Fix memory leak in management tx In the current logic, memory is allocated for storing the MSDU context during management packet TX but this memory is not being freed during management TX completion. Similar leaks are seen in the management TX cleanup logic. Kmemleak reports this problem as below, unreferenced object 0xffffff80b64ed250 (size 16): comm \"kworker/u16:7\", pid 148, jiffies 4294687130 (age 714.199s) hex dump (first 16 bytes): 00 2b d8 d8 80 ff ff ff c4 74 e9 fd 07 00 00 00 .+.......t...... backtrace: [] __kmem_cache_alloc_node+0x1e4/0x2d8 [] kmalloc_trace+0x48/0x110 [] ath10k_wmi_tlv_op_gen_mgmt_tx_send+0xd4/0x1d8 [ath10k_core] [] ath10k_mgmt_over_wmi_tx_work+0x134/0x298 [ath10k_core] [] process_scheduled_works+0x1ac/0x400 [] worker_thread+0x208/0x328 [] kthread+0x100/0x1c0 [] ret_from_fork+0x10/0x20 Free the memory during completion and cleanup to fix the leak. Protect the mgmt_pending_tx idr_remove() operation in ath10k_wmi_tlv_op_cleanup_mgmt_tx_send() using ar->data_lock similar to other instances. Tested-on: WCN3990 hw1.0 SNOC WLAN.HL.2.0-01387-QCAHLSWMTPLZ-1", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50237", "url": "https://ubuntu.com/security/CVE-2024-50237", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower Avoid potentially crashing in the driver because of uninitialized private data", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50238", "url": "https://ubuntu.com/security/CVE-2024-50238", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usbc: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data from the qcom-qmp-usb driver, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. This bug was later reproduced when the driver was copied to create the qmp-usbc driver. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with these drivers.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50239", "url": "https://ubuntu.com/security/CVE-2024-50239", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usb-legacy: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data from the qcom-qmp-usb driver, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. This bug was later reproduced when the driver was copied to create the qmp-usb-legacy driver. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with these drivers.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50240", "url": "https://ubuntu.com/security/CVE-2024-50240", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: phy: qcom: qmp-usb: fix NULL-deref on runtime suspend Commit 413db06c05e7 (\"phy: qcom-qmp-usb: clean up probe initialisation\") removed most users of the platform device driver data, but mistakenly also removed the initialisation despite the data still being used in the runtime PM callbacks. Restore the driver data initialisation at probe to avoid a NULL-pointer dereference on runtime suspend. Apparently no one uses runtime PM, which currently needs to be enabled manually through sysfs, with this driver.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53077", "url": "https://ubuntu.com/security/CVE-2024-53077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rpcrdma: Always release the rpcrdma_device's xa_array Dai pointed out that the xa_init_flags() in rpcrdma_add_one() needs to have a matching xa_destroy() in rpcrdma_remove_one() to release underlying memory that the xarray might have accrued during operation.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50242", "url": "https://ubuntu.com/security/CVE-2024-50242", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ntfs_file_release", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50243", "url": "https://ubuntu.com/security/CVE-2024-50243", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix general protection fault in run_is_mapped_full Fixed deleating of a non-resident attribute in ntfs_create_inode() rollback.", "cve_priority": "low", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50244", "url": "https://ubuntu.com/security/CVE-2024-50244", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Additional check in ni_clear() Checking of NTFS_FLAGS_LOG_REPLAYING added to prevent access to uninitialized bitmap during replay process.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50245", "url": "https://ubuntu.com/security/CVE-2024-50245", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix possible deadlock in mi_read Mutex lock with another subclass used in ni_lock_dir().", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50246", "url": "https://ubuntu.com/security/CVE-2024-50246", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Add rough attr alloc_size check", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50247", "url": "https://ubuntu.com/security/CVE-2024-50247", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Check if more than chunk-size bytes are written A incorrectly formatted chunk may decompress into more than LZNT_CHUNK_SIZE bytes and a index out of bounds will occur in s_max_off.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50248", "url": "https://ubuntu.com/security/CVE-2024-50248", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Add bounds checking to mi_enum_attr() Added bounds checking to make sure that every attr don't stray beyond valid memory region.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53078", "url": "https://ubuntu.com/security/CVE-2024-53078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/tegra: Fix NULL vs IS_ERR() check in probe() The iommu_paging_domain_alloc() function doesn't return NULL pointers, it returns error pointers. Update the check to match.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53056", "url": "https://ubuntu.com/security/CVE-2024-53056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/mediatek: Fix potential NULL dereference in mtk_crtc_destroy() In mtk_crtc_create(), if the call to mbox_request_channel() fails then we set the \"mtk_crtc->cmdq_client.chan\" pointer to NULL. In that situation, we do not call cmdq_pkt_create(). During the cleanup, we need to check if the \"mtk_crtc->cmdq_client.chan\" is NULL first before calling cmdq_pkt_destroy(). Calling cmdq_pkt_destroy() is unnecessary if we didn't call cmdq_pkt_create() and it will result in a NULL pointer dereference.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50249", "url": "https://ubuntu.com/security/CVE-2024-50249", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: CPPC: Make rmw_lock a raw_spin_lock The following BUG was triggered: ============================= [ BUG: Invalid wait context ] 6.12.0-rc2-XXX #406 Not tainted ----------------------------- kworker/1:1/62 is trying to lock: ffffff8801593030 (&cpc_ptr->rmw_lock){+.+.}-{3:3}, at: cpc_write+0xcc/0x370 other info that might help us debug this: context-{5:5} 2 locks held by kworker/1:1/62: #0: ffffff897ef5ec98 (&rq->__lock){-.-.}-{2:2}, at: raw_spin_rq_lock_nested+0x2c/0x50 #1: ffffff880154e238 (&sg_policy->update_lock){....}-{2:2}, at: sugov_update_shared+0x3c/0x280 stack backtrace: CPU: 1 UID: 0 PID: 62 Comm: kworker/1:1 Not tainted 6.12.0-rc2-g9654bd3e8806 #406 Workqueue: 0x0 (events) Call trace: dump_backtrace+0xa4/0x130 show_stack+0x20/0x38 dump_stack_lvl+0x90/0xd0 dump_stack+0x18/0x28 __lock_acquire+0x480/0x1ad8 lock_acquire+0x114/0x310 _raw_spin_lock+0x50/0x70 cpc_write+0xcc/0x370 cppc_set_perf+0xa0/0x3a8 cppc_cpufreq_fast_switch+0x40/0xc0 cpufreq_driver_fast_switch+0x4c/0x218 sugov_update_shared+0x234/0x280 update_load_avg+0x6ec/0x7b8 dequeue_entities+0x108/0x830 dequeue_task_fair+0x58/0x408 __schedule+0x4f0/0x1070 schedule+0x54/0x130 worker_thread+0xc0/0x2e8 kthread+0x130/0x148 ret_from_fork+0x10/0x20 sugov_update_shared() locks a raw_spinlock while cpc_write() locks a spinlock. To have a correct wait-type order, update rmw_lock to a raw spinlock and ensure that interrupts will be disabled on the CPU holding it. [ rjw: Changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50250", "url": "https://ubuntu.com/security/CVE-2024-50250", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fsdax: dax_unshare_iter needs to copy entire blocks The code that copies data from srcmap to iomap in dax_unshare_iter is very very broken, which bfoster's recent fsx changes have exposed. If the pos and len passed to dax_file_unshare are not aligned to an fsblock boundary, the iter pos and length in the _iter function will reflect this unalignment. dax_iomap_direct_access always returns a pointer to the start of the kmapped fsdax page, even if its pos argument is in the middle of that page. This is catastrophic for data integrity when iter->pos is not aligned to a page, because daddr/saddr do not point to the same byte in the file as iter->pos. Hence we corrupt user data by copying it to the wrong place. If iter->pos + iomap_length() in the _iter function not aligned to a page, then we fail to copy a full block, and only partially populate the destination block. This is catastrophic for data confidentiality because we expose stale pmem contents. Fix both of these issues by aligning copy_pos/copy_len to a page boundary (remember, this is fsdax so 1 fsblock == 1 base page) so that we always copy full blocks. We're not done yet -- there's no call to invalidate_inode_pages2_range, so programs that have the file range mmap'd will continue accessing the old memory mapping after the file metadata updates have completed. Be careful with the return value -- if the unshare succeeds, we still need to return the number of bytes that the iomap iter thinks we're operating on.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50251", "url": "https://ubuntu.com/security/CVE-2024-50251", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_payload: sanitize offset and length before calling skb_checksum() If access to offset + length is larger than the skbuff length, then skb_checksum() triggers BUG_ON(). skb_checksum() internally subtracts the length parameter while iterating over skbuff, BUG_ON(len) at the end of it checks that the expected length to be included in the checksum calculation is fully consumed.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50252", "url": "https://ubuntu.com/security/CVE-2024-50252", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_ipip: Fix memory leak when changing remote IPv6 address The device stores IPv6 addresses that are used for encapsulation in linear memory that is managed by the driver. Changing the remote address of an ip6gre net device never worked properly, but since cited commit the following reproducer [1] would result in a warning [2] and a memory leak [3]. The problem is that the new remote address is never added by the driver to its hash table (and therefore the device) and the old address is never removed from it. Fix by programming the new address when the configuration of the ip6gre net device changes and removing the old one. If the address did not change, then the above would result in increasing the reference count of the address and then decreasing it. [1] # ip link add name bla up type ip6gre local 2001:db8:1::1 remote 2001:db8:2::1 tos inherit ttl inherit # ip link set dev bla type ip6gre remote 2001:db8:3::1 # ip link del dev bla # devlink dev reload pci/0000:01:00.0 [2] WARNING: CPU: 0 PID: 1682 at drivers/net/ethernet/mellanox/mlxsw/spectrum.c:3002 mlxsw_sp_ipv6_addr_put+0x140/0x1d0 Modules linked in: CPU: 0 UID: 0 PID: 1682 Comm: ip Not tainted 6.12.0-rc3-custom-g86b5b55bc835 #151 Hardware name: Nvidia SN5600/VMOD0013, BIOS 5.13 05/31/2023 RIP: 0010:mlxsw_sp_ipv6_addr_put+0x140/0x1d0 [...] Call Trace: mlxsw_sp_router_netdevice_event+0x55f/0x1240 notifier_call_chain+0x5a/0xd0 call_netdevice_notifiers_info+0x39/0x90 unregister_netdevice_many_notify+0x63e/0x9d0 rtnl_dellink+0x16b/0x3a0 rtnetlink_rcv_msg+0x142/0x3f0 netlink_rcv_skb+0x50/0x100 netlink_unicast+0x242/0x390 netlink_sendmsg+0x1de/0x420 ____sys_sendmsg+0x2bd/0x320 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xd0 do_syscall_64+0x9e/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f [3] unreferenced object 0xffff898081f597a0 (size 32): comm \"ip\", pid 1626, jiffies 4294719324 hex dump (first 32 bytes): 20 01 0d b8 00 02 00 00 00 00 00 00 00 00 00 01 ............... 21 49 61 83 80 89 ff ff 00 00 00 00 01 00 00 00 !Ia............. backtrace (crc fd9be911): [<00000000df89c55d>] __kmalloc_cache_noprof+0x1da/0x260 [<00000000ff2a1ddb>] mlxsw_sp_ipv6_addr_kvdl_index_get+0x281/0x340 [<000000009ddd445d>] mlxsw_sp_router_netdevice_event+0x47b/0x1240 [<00000000743e7757>] notifier_call_chain+0x5a/0xd0 [<000000007c7b9e13>] call_netdevice_notifiers_info+0x39/0x90 [<000000002509645d>] register_netdevice+0x5f7/0x7a0 [<00000000c2e7d2a9>] ip6gre_newlink_common.isra.0+0x65/0x130 [<0000000087cd6d8d>] ip6gre_newlink+0x72/0x120 [<000000004df7c7cc>] rtnl_newlink+0x471/0xa20 [<0000000057ed632a>] rtnetlink_rcv_msg+0x142/0x3f0 [<0000000032e0d5b5>] netlink_rcv_skb+0x50/0x100 [<00000000908bca63>] netlink_unicast+0x242/0x390 [<00000000cdbe1c87>] netlink_sendmsg+0x1de/0x420 [<0000000011db153e>] ____sys_sendmsg+0x2bd/0x320 [<000000003b6d53eb>] ___sys_sendmsg+0x9a/0xe0 [<00000000cae27c62>] __sys_sendmsg+0x7a/0xd0", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50253", "url": "https://ubuntu.com/security/CVE-2024-50253", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Check the validity of nr_words in bpf_iter_bits_new() Check the validity of nr_words in bpf_iter_bits_new(). Without this check, when multiplication overflow occurs for nr_bits (e.g., when nr_words = 0x0400-0001, nr_bits becomes 64), stack corruption may occur due to bpf_probe_read_kernel_common(..., nr_bytes = 0x2000-0008). Fix it by limiting the maximum value of nr_words to 511. The value is derived from the current implementation of BPF memory allocator. To ensure compatibility if the BPF memory allocator's size limitation changes in the future, use the helper bpf_mem_alloc_check_size() to check whether nr_bytes is too larger. And return -E2BIG instead of -ENOMEM for oversized nr_bytes.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50254", "url": "https://ubuntu.com/security/CVE-2024-50254", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Free dynamically allocated bits in bpf_iter_bits_destroy() bpf_iter_bits_destroy() uses \"kit->nr_bits <= 64\" to check whether the bits are dynamically allocated. However, the check is incorrect and may cause a kmemleak as shown below: unreferenced object 0xffff88812628c8c0 (size 32): comm \"swapper/0\", pid 1, jiffies 4294727320 hex dump (first 32 bytes): \tb0 c1 55 f5 81 88 ff ff f0 f0 f0 f0 f0 f0 f0 f0 ..U........... \tf0 f0 f0 f0 f0 f0 f0 f0 00 00 00 00 00 00 00 00 .............. backtrace (crc 781e32cc): \t[<00000000c452b4ab>] kmemleak_alloc+0x4b/0x80 \t[<0000000004e09f80>] __kmalloc_node_noprof+0x480/0x5c0 \t[<00000000597124d6>] __alloc.isra.0+0x89/0xb0 \t[<000000004ebfffcd>] alloc_bulk+0x2af/0x720 \t[<00000000d9c10145>] prefill_mem_cache+0x7f/0xb0 \t[<00000000ff9738ff>] bpf_mem_alloc_init+0x3e2/0x610 \t[<000000008b616eac>] bpf_global_ma_init+0x19/0x30 \t[<00000000fc473efc>] do_one_initcall+0xd3/0x3c0 \t[<00000000ec81498c>] kernel_init_freeable+0x66a/0x940 \t[<00000000b119f72f>] kernel_init+0x20/0x160 \t[<00000000f11ac9a7>] ret_from_fork+0x3c/0x70 \t[<0000000004671da4>] ret_from_fork_asm+0x1a/0x30 That is because nr_bits will be set as zero in bpf_iter_bits_next() after all bits have been iterated. Fix the issue by setting kit->bit to kit->nr_bits instead of setting kit->nr_bits to zero when the iteration completes in bpf_iter_bits_next(). In addition, use \"!nr_bits || bits >= nr_bits\" to check whether the iteration is complete and still use \"nr_bits > 64\" to indicate whether bits are dynamically allocated. The \"!nr_bits\" check is necessary because bpf_iter_bits_new() may fail before setting kit->nr_bits, and this condition will stop the iteration early instead of accessing the zeroed or freed kit->bits. Considering the initial value of kit->bits is -1 and the type of kit->nr_bits is unsigned int, change the type of kit->nr_bits to int. The potential overflow problem will be handled in the following patch.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50255", "url": "https://ubuntu.com/security/CVE-2024-50255", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci: fix null-ptr-deref in hci_read_supported_codecs Fix __hci_cmd_sync_sk() to return not NULL for unknown opcodes. __hci_cmd_sync_sk() returns NULL if a command returns a status event. However, it also returns NULL where an opcode doesn't exist in the hci_cc table because hci_cmd_complete_evt() assumes status = skb->data[0] for unknown opcodes. This leads to null-ptr-deref in cmd_sync for HCI_OP_READ_LOCAL_CODECS as there is no hci_cc for HCI_OP_READ_LOCAL_CODECS, which always assumes status = skb->data[0]. KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077] CPU: 1 PID: 2000 Comm: kworker/u9:5 Not tainted 6.9.0-ga6bcb805883c-dirty #10 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: hci7 hci_power_on RIP: 0010:hci_read_supported_codecs+0xb9/0x870 net/bluetooth/hci_codec.c:138 Code: 08 48 89 ef e8 b8 c1 8f fd 48 8b 75 00 e9 96 00 00 00 49 89 c6 48 ba 00 00 00 00 00 fc ff df 4c 8d 60 70 4c 89 e3 48 c1 eb 03 <0f> b6 04 13 84 c0 0f 85 82 06 00 00 41 83 3c 24 02 77 0a e8 bf 78 RSP: 0018:ffff888120bafac8 EFLAGS: 00010212 RAX: 0000000000000000 RBX: 000000000000000e RCX: ffff8881173f0040 RDX: dffffc0000000000 RSI: ffffffffa58496c0 RDI: ffff88810b9ad1e4 RBP: ffff88810b9ac000 R08: ffffffffa77882a7 R09: 1ffffffff4ef1054 R10: dffffc0000000000 R11: fffffbfff4ef1055 R12: 0000000000000070 R13: 0000000000000000 R14: 0000000000000000 R15: ffff88810b9ac000 FS: 0000000000000000(0000) GS:ffff8881f6c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f6ddaa3439e CR3: 0000000139764003 CR4: 0000000000770ef0 PKRU: 55555554 Call Trace: hci_read_local_codecs_sync net/bluetooth/hci_sync.c:4546 [inline] hci_init_stage_sync net/bluetooth/hci_sync.c:3441 [inline] hci_init4_sync net/bluetooth/hci_sync.c:4706 [inline] hci_init_sync net/bluetooth/hci_sync.c:4742 [inline] hci_dev_init_sync net/bluetooth/hci_sync.c:4912 [inline] hci_dev_open_sync+0x19a9/0x2d30 net/bluetooth/hci_sync.c:4994 hci_dev_do_open net/bluetooth/hci_core.c:483 [inline] hci_power_on+0x11e/0x560 net/bluetooth/hci_core.c:1015 process_one_work kernel/workqueue.c:3267 [inline] process_scheduled_works+0x8ef/0x14f0 kernel/workqueue.c:3348 worker_thread+0x91f/0xe50 kernel/workqueue.c:3429 kthread+0x2cb/0x360 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50256", "url": "https://ubuntu.com/security/CVE-2024-50256", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6() I got a syzbot report without a repro [1] crashing in nf_send_reset6() I think the issue is that dev->hard_header_len is zero, and we attempt later to push an Ethernet header. Use LL_MAX_HEADER, as other functions in net/ipv6/netfilter/nf_reject_ipv6.c. [1] skbuff: skb_under_panic: text:ffffffff89b1d008 len:74 put:14 head:ffff88803123aa00 data:ffff88803123a9f2 tail:0x3c end:0x140 dev:syz_tun kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 UID: 0 PID: 7373 Comm: syz.1.568 Not tainted 6.12.0-rc2-syzkaller-00631-g6d858708d465 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:skb_panic net/core/skbuff.c:206 [inline] RIP: 0010:skb_under_panic+0x14b/0x150 net/core/skbuff.c:216 Code: 0d 8d 48 c7 c6 60 a6 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 ba 30 38 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP: 0018:ffffc900045269b0 EFLAGS: 00010282 RAX: 0000000000000088 RBX: dffffc0000000000 RCX: cd66dacdc5d8e800 RDX: 0000000000000000 RSI: 0000000000000200 RDI: 0000000000000000 RBP: ffff88802d39a3d0 R08: ffffffff8174afec R09: 1ffff920008a4ccc R10: dffffc0000000000 R11: fffff520008a4ccd R12: 0000000000000140 R13: ffff88803123aa00 R14: ffff88803123a9f2 R15: 000000000000003c FS: 00007fdbee5ff6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000005d322000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: skb_push+0xe5/0x100 net/core/skbuff.c:2636 eth_header+0x38/0x1f0 net/ethernet/eth.c:83 dev_hard_header include/linux/netdevice.h:3208 [inline] nf_send_reset6+0xce6/0x1270 net/ipv6/netfilter/nf_reject_ipv6.c:358 nft_reject_inet_eval+0x3b9/0x690 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x418/0x6b0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] br_nf_pre_routing_ipv6+0x63e/0x770 net/bridge/br_netfilter_ipv6.c:184 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_bridge_pre net/bridge/br_input.c:277 [inline] br_handle_frame+0x9fd/0x1530 net/bridge/br_input.c:424 __netif_receive_skb_core+0x13e8/0x4570 net/core/dev.c:5562 __netif_receive_skb_one_core net/core/dev.c:5666 [inline] __netif_receive_skb+0x12f/0x650 net/core/dev.c:5781 netif_receive_skb_internal net/core/dev.c:5867 [inline] netif_receive_skb+0x1e8/0x890 net/core/dev.c:5926 tun_rx_batched+0x1b7/0x8f0 drivers/net/tun.c:1550 tun_get_user+0x3056/0x47e0 drivers/net/tun.c:2007 tun_chr_write_iter+0x10d/0x1f0 drivers/net/tun.c:2053 new_sync_write fs/read_write.c:590 [inline] vfs_write+0xa6d/0xc90 fs/read_write.c:683 ksys_write+0x183/0x2b0 fs/read_write.c:736 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:0x7fdbeeb7d1ff Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 c9 8d 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 1c 8e 02 00 48 RSP: 002b:00007fdbee5ff000 EFLAGS: 00000293 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fdbeed36058 RCX: 00007fdbeeb7d1ff RDX: 000000000000008e RSI: 0000000020000040 RDI: 00000000000000c8 RBP: 00007fdbeebf12be R08: 0000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50257", "url": "https://ubuntu.com/security/CVE-2024-50257", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: Fix use-after-free in get_info() ip6table_nat module unload has refcnt warning for UAF. call trace is: WARNING: CPU: 1 PID: 379 at kernel/module/main.c:853 module_put+0x6f/0x80 Modules linked in: ip6table_nat(-) CPU: 1 UID: 0 PID: 379 Comm: ip6tables Not tainted 6.12.0-rc4-00047-gc2ee9f594da8-dirty #205 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:module_put+0x6f/0x80 Call Trace: get_info+0x128/0x180 do_ip6t_get_ctl+0x6a/0x430 nf_getsockopt+0x46/0x80 ipv6_getsockopt+0xb9/0x100 rawv6_getsockopt+0x42/0x190 do_sock_getsockopt+0xaa/0x180 __sys_getsockopt+0x70/0xc0 __x64_sys_getsockopt+0x20/0x30 do_syscall_64+0xa2/0x1a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Concurrent execution of module unload and get_info() trigered the warning. The root cause is as follows: cpu0\t\t\t\t cpu1 module_exit //mod->state = MODULE_STATE_GOING ip6table_nat_exit xt_unregister_template \tkfree(t) \t//removed from templ_list \t\t\t\t getinfo() \t\t\t\t\t t = xt_find_table_lock \t\t\t\t\t\tlist_for_each_entry(tmpl, &xt_templates[af]...) \t\t\t\t\t\t\tif (strcmp(tmpl->name, name)) \t\t\t\t\t\t\t\tcontinue; //table not found \t\t\t\t\t\t\ttry_module_get \t\t\t\t\t\tlist_for_each_entry(t, &xt_net->tables[af]...) \t\t\t\t\t\t\treturn t; //not get refcnt \t\t\t\t\t module_put(t->me) //uaf unregister_pernet_subsys //remove table from xt_net list While xt_table module was going away and has been removed from xt_templates list, we couldnt get refcnt of xt_table->me. Check module in xt_net->tables list re-traversal to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50258", "url": "https://ubuntu.com/security/CVE-2024-50258", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: fix crash when config small gso_max_size/gso_ipv4_max_size Config a small gso_max_size/gso_ipv4_max_size will lead to an underflow in sk_dst_gso_max_size(), which may trigger a BUG_ON crash, because sk->sk_gso_max_size would be much bigger than device limits. Call Trace: tcp_write_xmit tso_segs = tcp_init_tso_segs(skb, mss_now); tcp_set_skb_tso_segs tcp_skb_pcount_set // skb->len = 524288, mss_now = 8 // u16 tso_segs = 524288/8 = 65535 -> 0 tso_segs = DIV_ROUND_UP(skb->len, mss_now) BUG_ON(!tso_segs) Add check for the minimum value of gso_max_size and gso_ipv4_max_size.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50262", "url": "https://ubuntu.com/security/CVE-2024-50262", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix out-of-bounds write in trie_get_next_key() trie_get_next_key() allocates a node stack with size trie->max_prefixlen, while it writes (trie->max_prefixlen + 1) nodes to the stack when it has full paths from the root to leaves. For example, consider a trie with max_prefixlen is 8, and the nodes with key 0x00/0, 0x00/1, 0x00/2, ... 0x00/8 inserted. Subsequent calls to trie_get_next_key with _key with .prefixlen = 8 make 9 nodes be written on the node stack with size 8.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53044", "url": "https://ubuntu.com/security/CVE-2024-53044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_api: fix xa_insert() error path in tcf_block_get_ext() This command: $ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact Error: block dev insert failed: -EBUSY. fails because user space requests the same block index to be set for both ingress and egress. [ side note, I don't think it even failed prior to commit 913b47d3424e (\"net/sched: Introduce tc block netdev tracking infra\"), because this is a command from an old set of notes of mine which used to work, but alas, I did not scientifically bisect this ] The problem is not that it fails, but rather, that the second time around, it fails differently (and irrecoverably): $ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact Error: dsa_core: Flow block cb is busy. [ another note: the extack is added by me for illustration purposes. the context of the problem is that clsact_init() obtains the same &q->ingress_block pointer as &q->egress_block, and since we call tcf_block_get_ext() on both of them, \"dev\" will be added to the block->ports xarray twice, thus failing the operation: once through the ingress block pointer, and once again through the egress block pointer. the problem itself is that when xa_insert() fails, we have emitted a FLOW_BLOCK_BIND command through ndo_setup_tc(), but the offload never sees a corresponding FLOW_BLOCK_UNBIND. ] Even correcting the bad user input, we still cannot recover: $ tc qdisc replace dev swp3 ingress_block 1 egress_block 2 clsact Error: dsa_core: Flow block cb is busy. Basically the only way to recover is to reboot the system, or unbind and rebind the net device driver. To fix the bug, we need to fill the correct error teardown path which was missed during code movement, and call tcf_block_offload_unbind() when xa_insert() fails. [ last note, fundamentally I blame the label naming convention in tcf_block_get_ext() for the bug. The labels should be named after what they do, not after the error path that jumps to them. This way, it is obviously wrong that two labels pointing to the same code mean something is wrong, and checking the code correctness at the goto site is also easier ]", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50259", "url": "https://ubuntu.com/security/CVE-2024-50259", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netdevsim: Add trailing zero to terminate the string in nsim_nexthop_bucket_activity_write() This was found by a static analyzer. We should not forget the trailing zero after copy_from_user() if we will further do some string operations, sscanf() in this case. Adding a trailing zero will ensure that the function performs properly.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-50304", "url": "https://ubuntu.com/security/CVE-2024-50304", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find() The per-netns IP tunnel hash table is protected by the RTNL mutex and ip_tunnel_find() is only called from the control path where the mutex is taken. Add a lockdep expression to hlist_for_each_entry_rcu() in ip_tunnel_find() in order to validate that the mutex is held and to silence the suspicious RCU usage warning [1]. [1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gd95d9a31aceb #139 Not tainted ----------------------------- net/ipv4/ip_tunnel.c:221 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/362: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60 stack backtrace: CPU: 12 UID: 0 PID: 362 Comm: ip Not tainted 6.12.0-rc3-custom-gd95d9a31aceb #139 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 ip_tunnel_find+0x435/0x4d0 ip_tunnel_newlink+0x517/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53042", "url": "https://ubuntu.com/security/CVE-2024-53042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_init_flow() There are code paths from which the function is called without holding the RCU read lock, resulting in a suspicious RCU usage warning [1]. Fix by using l3mdev_master_upper_ifindex_by_index() which will acquire the RCU read lock before calling l3mdev_master_upper_ifindex_by_index_rcu(). [1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gac8f72681cf2 #141 Not tainted ----------------------------- net/core/dev.c:876 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/361: #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60 stack backtrace: CPU: 3 UID: 0 PID: 361 Comm: ip Not tainted 6.12.0-rc3-custom-gac8f72681cf2 #141 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack_lvl+0xba/0x110 lockdep_rcu_suspicious.cold+0x4f/0xd6 dev_get_by_index_rcu+0x1d3/0x210 l3mdev_master_upper_ifindex_by_index_rcu+0x2b/0xf0 ip_tunnel_bind_dev+0x72f/0xa00 ip_tunnel_newlink+0x368/0x7a0 ipgre_newlink+0x14c/0x170 __rtnl_newlink+0x1173/0x19c0 rtnl_newlink+0x6c/0xa0 rtnetlink_rcv_msg+0x3cc/0xf60 netlink_rcv_skb+0x171/0x450 netlink_unicast+0x539/0x7f0 netlink_sendmsg+0x8c1/0xd80 ____sys_sendmsg+0x8f9/0xc20 ___sys_sendmsg+0x197/0x1e0 __sys_sendmsg+0x122/0x1f0 do_syscall_64+0xbb/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7f", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53048", "url": "https://ubuntu.com/security/CVE-2024-53048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix crash on probe for DPLL enabled E810 LOM The E810 Lan On Motherboard (LOM) design is vendor specific. Intel provides the reference design, but it is up to vendor on the final product design. For some cases, like Linux DPLL support, the static values defined in the driver does not reflect the actual LOM design. Current implementation of dpll pins is causing the crash on probe of the ice driver for such DPLL enabled E810 LOM designs: WARNING: (...) at drivers/dpll/dpll_core.c:495 dpll_pin_get+0x2c4/0x330 ... Call Trace: ? __warn+0x83/0x130 ? dpll_pin_get+0x2c4/0x330 ? report_bug+0x1b7/0x1d0 ? handle_bug+0x42/0x70 ? exc_invalid_op+0x18/0x70 ? asm_exc_invalid_op+0x1a/0x20 ? dpll_pin_get+0x117/0x330 ? dpll_pin_get+0x2c4/0x330 ? dpll_pin_get+0x117/0x330 ice_dpll_get_pins.isra.0+0x52/0xe0 [ice] ... The number of dpll pins enabled by LOM vendor is greater than expected and defined in the driver for Intel designed NICs, which causes the crash. Prevent the crash and allow generic pin initialization within Linux DPLL subsystem for DPLL enabled E810 LOM designs. Newly designed solution for described issue will be based on \"per HW design\" pin initialization. It requires pin information dynamically acquired from the firmware and is already in progress, planned for next-tree only.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53058", "url": "https://ubuntu.com/security/CVE-2024-53058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data In case the non-paged data of a SKB carries protocol header and protocol payload to be transmitted on a certain platform that the DMA AXI address width is configured to 40-bit/48-bit, or the size of the non-paged data is bigger than TSO_MAX_BUFF_SIZE on a certain platform that the DMA AXI address width is configured to 32-bit, then this SKB requires at least two DMA transmit descriptors to serve it. For example, three descriptors are allocated to split one DMA buffer mapped from one piece of non-paged data: dma_desc[N + 0], dma_desc[N + 1], dma_desc[N + 2]. Then three elements of tx_q->tx_skbuff_dma[] will be allocated to hold extra information to be reused in stmmac_tx_clean(): tx_q->tx_skbuff_dma[N + 0], tx_q->tx_skbuff_dma[N + 1], tx_q->tx_skbuff_dma[N + 2]. Now we focus on tx_q->tx_skbuff_dma[entry].buf, which is the DMA buffer address returned by DMA mapping call. stmmac_tx_clean() will try to unmap the DMA buffer _ONLY_IF_ tx_q->tx_skbuff_dma[entry].buf is a valid buffer address. The expected behavior that saves DMA buffer address of this non-paged data to tx_q->tx_skbuff_dma[entry].buf is: tx_q->tx_skbuff_dma[N + 0].buf = NULL; tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = dma_map_single(); Unfortunately, the current code misbehaves like this: tx_q->tx_skbuff_dma[N + 0].buf = dma_map_single(); tx_q->tx_skbuff_dma[N + 1].buf = NULL; tx_q->tx_skbuff_dma[N + 2].buf = NULL; On the stmmac_tx_clean() side, when dma_desc[N + 0] is closed by the DMA engine, tx_q->tx_skbuff_dma[N + 0].buf is a valid buffer address obviously, then the DMA buffer will be unmapped immediately. There may be a rare case that the DMA engine does not finish the pending dma_desc[N + 1], dma_desc[N + 2] yet. Now things will go horribly wrong, DMA is going to access a unmapped/unreferenced memory region, corrupted data will be transmited or iommu fault will be triggered :( In contrast, the for-loop that maps SKB fragments behaves perfectly as expected, and that is how the driver should do for both non-paged data and paged frags actually. This patch corrects DMA map/unmap sequences by fixing the array index for tx_q->tx_skbuff_dma[entry].buf when assigning DMA buffer address. Tested and verified on DWXGMAC CORE 3.20a", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50260", "url": "https://ubuntu.com/security/CVE-2024-50260", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sock_map: fix a NULL pointer dereference in sock_map_link_update_prog() The following race condition could trigger a NULL pointer dereference: sock_map_link_detach():\t\tsock_map_link_update_prog(): mutex_lock(&sockmap_mutex); ... sockmap_link->map = NULL; mutex_unlock(&sockmap_mutex); \t\t\t\t mutex_lock(&sockmap_mutex); \t\t\t\t ... \t\t\t\t sock_map_prog_link_lookup(sockmap_link->map); \t\t\t\t mutex_unlock(&sockmap_mutex); Fix it by adding a NULL pointer check. In this specific case, it makes no sense to update a link which is being released.", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53045", "url": "https://ubuntu.com/security/CVE-2024-53045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: dapm: fix bounds checker error in dapm_widget_list_create The widgets array in the snd_soc_dapm_widget_list has a __counted_by attribute attached to it, which points to the num_widgets variable. This attribute is used in bounds checking, and if it is not set before the array is filled, then the bounds sanitizer will issue a warning or a kernel panic if CONFIG_UBSAN_TRAP is set. This patch sets the size of the widgets list calculated with list_for_each as the initial value for num_widgets as it is used for allocating memory for the array. It is updated with the actual number of added elements after the array is filled.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50261", "url": "https://ubuntu.com/security/CVE-2024-50261", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: macsec: Fix use-after-free while sending the offloading packet KASAN reports the following UAF. The metadata_dst, which is used to store the SCI value for macsec offload, is already freed by metadata_dst_free() in macsec_free_netdev(), while driver still use it for sending the packet. To fix this issue, dst_release() is used instead to release metadata_dst. So it is not freed instantly in macsec_free_netdev() if still referenced by skb. BUG: KASAN: slab-use-after-free in mlx5e_xmit+0x1e8f/0x4190 [mlx5_core] Read of size 2 at addr ffff88813e42e038 by task kworker/7:2/714 [...] Workqueue: mld mld_ifc_work Call Trace: dump_stack_lvl+0x51/0x60 print_report+0xc1/0x600 kasan_report+0xab/0xe0 mlx5e_xmit+0x1e8f/0x4190 [mlx5_core] dev_hard_start_xmit+0x120/0x530 sch_direct_xmit+0x149/0x11e0 __qdisc_run+0x3ad/0x1730 __dev_queue_xmit+0x1196/0x2ed0 vlan_dev_hard_start_xmit+0x32e/0x510 [8021q] dev_hard_start_xmit+0x120/0x530 __dev_queue_xmit+0x14a7/0x2ed0 macsec_start_xmit+0x13e9/0x2340 dev_hard_start_xmit+0x120/0x530 __dev_queue_xmit+0x14a7/0x2ed0 ip6_finish_output2+0x923/0x1a70 ip6_finish_output+0x2d7/0x970 ip6_output+0x1ce/0x3a0 NF_HOOK.constprop.0+0x15f/0x190 mld_sendpack+0x59a/0xbd0 mld_ifc_work+0x48a/0xa80 process_one_work+0x5aa/0xe50 worker_thread+0x79c/0x1290 kthread+0x28f/0x350 ret_from_fork+0x2d/0x70 ret_from_fork_asm+0x11/0x20 Allocated by task 3922: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 __kasan_kmalloc+0x77/0x90 __kmalloc_noprof+0x188/0x400 metadata_dst_alloc+0x1f/0x4e0 macsec_newlink+0x914/0x1410 __rtnl_newlink+0xe08/0x15b0 rtnl_newlink+0x5f/0x90 rtnetlink_rcv_msg+0x667/0xa80 netlink_rcv_skb+0x12c/0x360 netlink_unicast+0x551/0x770 netlink_sendmsg+0x72d/0xbd0 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x52e/0x6a0 ___sys_sendmsg+0xeb/0x170 __sys_sendmsg+0xb5/0x140 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Freed by task 4011: kasan_save_stack+0x20/0x40 kasan_save_track+0x10/0x30 kasan_save_free_info+0x37/0x50 poison_slab_object+0x10c/0x190 __kasan_slab_free+0x11/0x30 kfree+0xe0/0x290 macsec_free_netdev+0x3f/0x140 netdev_run_todo+0x450/0xc70 rtnetlink_rcv_msg+0x66f/0xa80 netlink_rcv_skb+0x12c/0x360 netlink_unicast+0x551/0x770 netlink_sendmsg+0x72d/0xbd0 __sock_sendmsg+0xc5/0x190 ____sys_sendmsg+0x52e/0x6a0 ___sys_sendmsg+0xeb/0x170 __sys_sendmsg+0xb5/0x140 do_syscall_64+0x4c/0x100 entry_SYSCALL_64_after_hwframe+0x4b/0x53", "cve_priority": "medium", "cve_public_date": "2024-11-09 11:15:00 UTC" }, { "cve": "CVE-2024-53059", "url": "https://ubuntu.com/security/CVE-2024-53059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd() 1. The size of the response packet is not validated. 2. The response buffer is not freed. Resolve these issues by switching to iwl_mvm_send_cmd_status(), which handles both size validation and frees the buffer.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53074", "url": "https://ubuntu.com/security/CVE-2024-53074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: don't leak a link on AP removal Release the link mapping resource in AP removal. This impacted devices that do not support the MLD API (9260 and down). On those devices, we couldn't start the AP again after the AP has been already started and stopped.", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-53049", "url": "https://ubuntu.com/security/CVE-2024-53049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slub/kunit: fix a WARNING due to unwrapped __kmalloc_cache_noprof 'modprobe slub_kunit' will have a warning as shown below. The root cause is that __kmalloc_cache_noprof was directly used, which resulted in no alloc_tag being allocated. This caused current->alloc_tag to be null, leading to a warning in alloc_tag_add_check. Let's add an alloc_hook layer to __kmalloc_cache_noprof specifically within lib/slub_kunit.c, which is the only user of this internal slub function outside kmalloc implementation itself. [58162.947016] WARNING: CPU: 2 PID: 6210 at ./include/linux/alloc_tag.h:125 alloc_tagging_slab_alloc_hook+0x268/0x27c [58162.957721] Call trace: [58162.957919] alloc_tagging_slab_alloc_hook+0x268/0x27c [58162.958286] __kmalloc_cache_noprof+0x14c/0x344 [58162.958615] test_kmalloc_redzone_access+0x50/0x10c [slub_kunit] [58162.959045] kunit_try_run_case+0x74/0x184 [kunit] [58162.959401] kunit_generic_run_threadfn_adapter+0x2c/0x4c [kunit] [58162.959841] kthread+0x10c/0x118 [58162.960093] ret_from_fork+0x10/0x20 [58162.960363] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-11-19 18:15:00 UTC" }, { "cve": "CVE-2024-50192", "url": "https://ubuntu.com/security/CVE-2024-50192", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v4: Don't allow a VMOVP on a dying VPE Kunkun Jiang reported that there is a small window of opportunity for userspace to force a change of affinity for a VPE while the VPE has already been unmapped, but the corresponding doorbell interrupt still visible in /proc/irq/. Plug the race by checking the value of vmapp_count, which tracks whether the VPE is mapped ot not, and returning an error in this case. This involves making vmapp_count common to both GICv4.1 and its v4.0 ancestor.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50069", "url": "https://ubuntu.com/security/CVE-2024-50069", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: apple: check devm_kasprintf() returned value devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked. Fix this lack and check the returned value. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50070", "url": "https://ubuntu.com/security/CVE-2024-50070", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: stm32: check devm_kasprintf() returned value devm_kasprintf() can return a NULL pointer on failure but this returned value is not checked. Fix this lack and check the returned value. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50196", "url": "https://ubuntu.com/security/CVE-2024-50196", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: ocelot: fix system hang on level based interrupts The current implementation only calls chained_irq_enter() and chained_irq_exit() if it detects pending interrupts. ``` for (i = 0; i < info->stride; i++) { \turegmap_read(info->map, id_reg + 4 * i, ®); \tif (!reg) \t\tcontinue; \tchained_irq_enter(parent_chip, desc); ``` However, in case of GPIO pin configured in level mode and the parent controller configured in edge mode, GPIO interrupt might be lowered by the hardware. In the result, if the interrupt is short enough, the parent interrupt is still pending while the GPIO interrupt is cleared; chained_irq_enter() never gets called and the system hangs trying to service the parent interrupt. Moving chained_irq_enter() and chained_irq_exit() outside the for loop ensures that they are called even when GPIO interrupt is lowered by the hardware. The similar code with chained_irq_enter() / chained_irq_exit() functions wrapping interrupt checking loop may be found in many other drivers: ``` grep -r -A 10 chained_irq_enter drivers/pinctrl ```", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50197", "url": "https://ubuntu.com/security/CVE-2024-50197", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: intel: platform: fix error path in device_for_each_child_node() The device_for_each_child_node() loop requires calls to fwnode_handle_put() upon early returns to decrement the refcount of the child node and avoid leaking memory if that error path is triggered. There is one early returns within that loop in intel_platform_pinctrl_prepare_community(), but fwnode_handle_put() is missing. Instead of adding the missing call, the scoped version of the loop can be used to simplify the code and avoid mistakes in the future if new early returns are added, as the child node is only used for parsing, and it is never assigned.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50071", "url": "https://ubuntu.com/security/CVE-2024-50071", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: pinctrl: nuvoton: fix a double free in ma35_pinctrl_dt_node_to_map_func() 'new_map' is allocated using devm_* which takes care of freeing the allocated data on device removal, call to \t.dt_free_map = pinconf_generic_dt_free_map double frees the map as pinconf_generic_dt_free_map() calls pinctrl_utils_free_map(). Fix this by using kcalloc() instead of auto-managed devm_kcalloc().", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50072", "url": "https://ubuntu.com/security/CVE-2024-50072", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/bugs: Use code segment selector for VERW operand Robert Gill reported below #GP in 32-bit mode when dosemu software was executing vm86() system call: general protection fault: 0000 [#1] PREEMPT SMP CPU: 4 PID: 4610 Comm: dosemu.bin Not tainted 6.6.21-gentoo-x86 #1 Hardware name: Dell Inc. PowerEdge 1950/0H723K, BIOS 2.7.0 10/30/2010 EIP: restore_all_switch_stack+0xbe/0xcf EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000 ESI: 00000000 EDI: 00000000 EBP: 00000000 ESP: ff8affdc DS: 0000 ES: 0000 FS: 0000 GS: 0033 SS: 0068 EFLAGS: 00010046 CR0: 80050033 CR2: 00c2101c CR3: 04b6d000 CR4: 000406d0 Call Trace: show_regs+0x70/0x78 die_addr+0x29/0x70 exc_general_protection+0x13c/0x348 exc_bounds+0x98/0x98 handle_exception+0x14d/0x14d exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf exc_bounds+0x98/0x98 restore_all_switch_stack+0xbe/0xcf This only happens in 32-bit mode when VERW based mitigations like MDS/RFDS are enabled. This is because segment registers with an arbitrary user value can result in #GP when executing VERW. Intel SDM vol. 2C documents the following behavior for VERW instruction: #GP(0) - If a memory operand effective address is outside the CS, DS, ES, \t FS, or GS segment limit. CLEAR_CPU_BUFFERS macro executes VERW instruction before returning to user space. Use %cs selector to reference VERW operand. This ensures VERW will not #GP for an arbitrary user %ds. [ mingo: Fixed the SOB chain. ]", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50073", "url": "https://ubuntu.com/security/CVE-2024-50073", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: Fix use-after-free in gsm_cleanup_mux BUG: KASAN: slab-use-after-free in gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] Read of size 8 at addr ffff88815fe99c00 by task poc/3379 CPU: 0 UID: 0 PID: 3379 Comm: poc Not tainted 6.11.0+ #56 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] __pfx_gsm_cleanup_mux+0x10/0x10 drivers/tty/n_gsm.c:3124 [n_gsm] __pfx_sched_clock_cpu+0x10/0x10 kernel/sched/clock.c:389 update_load_avg+0x1c1/0x27b0 kernel/sched/fair.c:4500 __pfx_min_vruntime_cb_rotate+0x10/0x10 kernel/sched/fair.c:846 __rb_insert_augmented+0x492/0xbf0 lib/rbtree.c:161 gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] _raw_spin_lock_irqsave+0x92/0xf0 arch/x86/include/asm/atomic.h:107 __pfx_gsmld_ioctl+0x10/0x10 drivers/tty/n_gsm.c:3822 [n_gsm] ktime_get+0x5e/0x140 kernel/time/timekeeping.c:195 ldsem_down_read+0x94/0x4e0 arch/x86/include/asm/atomic64_64.h:79 __pfx_ldsem_down_read+0x10/0x10 drivers/tty/tty_ldsem.c:338 __pfx_do_vfs_ioctl+0x10/0x10 fs/ioctl.c:805 tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 Allocated by task 65: gsm_data_alloc.constprop.0+0x27/0x190 drivers/tty/n_gsm.c:926 [n_gsm] gsm_send+0x2c/0x580 drivers/tty/n_gsm.c:819 [n_gsm] gsm1_receive+0x547/0xad0 drivers/tty/n_gsm.c:3038 [n_gsm] gsmld_receive_buf+0x176/0x280 drivers/tty/n_gsm.c:3609 [n_gsm] tty_ldisc_receive_buf+0x101/0x1e0 drivers/tty/tty_buffer.c:391 tty_port_default_receive_buf+0x61/0xa0 drivers/tty/tty_port.c:39 flush_to_ldisc+0x1b0/0x750 drivers/tty/tty_buffer.c:445 process_scheduled_works+0x2b0/0x10d0 kernel/workqueue.c:3229 worker_thread+0x3dc/0x950 kernel/workqueue.c:3391 kthread+0x2a3/0x370 kernel/kthread.c:389 ret_from_fork+0x2d/0x70 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:257 Freed by task 3367: kfree+0x126/0x420 mm/slub.c:4580 gsm_cleanup_mux+0x36c/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 [Analysis] gsm_msg on the tx_ctrl_list or tx_data_list of gsm_mux can be freed by multi threads through ioctl,which leads to the occurrence of uaf. Protect it by gsm tx lock.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50193", "url": "https://ubuntu.com/security/CVE-2024-50193", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/entry_32: Clear CPU buffers after register restore in NMI return CPU buffers are currently cleared after call to exc_nmi, but before register state is restored. This may be okay for MDS mitigation but not for RDFS. Because RDFS mitigation requires CPU buffers to be cleared when registers don't have any sensitive data. Move CLEAR_CPU_BUFFERS after RESTORE_ALL_NMI.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50074", "url": "https://ubuntu.com/security/CVE-2024-50074", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: parport: Proper fix for array out-of-bounds access The recent fix for array out-of-bounds accesses replaced sprintf() calls blindly with snprintf(). However, since snprintf() returns the would-be-printed size, not the actually output size, the length calculation can still go over the given limit. Use scnprintf() instead of snprintf(), which returns the actually output letters, for addressing the potential out-of-bounds access properly.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50100", "url": "https://ubuntu.com/security/CVE-2024-50100", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: gadget: dummy-hcd: Fix \"task hung\" problem The syzbot fuzzer has been encountering \"task hung\" problems ever since the dummy-hcd driver was changed to use hrtimers instead of regular timers. It turns out that the problems are caused by a subtle difference between the timer_pending() and hrtimer_active() APIs. The changeover blindly replaced the first by the second. However, timer_pending() returns True when the timer is queued but not when its callback is running, whereas hrtimer_active() returns True when the hrtimer is queued _or_ its callback is running. This difference occasionally caused dummy_urb_enqueue() to think that the callback routine had not yet started when in fact it was almost finished. As a result the hrtimer was not restarted, which made it impossible for the driver to dequeue later the URB that was just enqueued. This caused usb_kill_urb() to hang, and things got worse from there. Since hrtimers have no API for telling when they are queued and the callback isn't running, the driver must keep track of this for itself. That's what this patch does, adding a new \"timer_pending\" flag and setting or clearing it at the appropriate times.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50075", "url": "https://ubuntu.com/security/CVE-2024-50075", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: xhci: tegra: fix checked USB2 port number If USB virtualizatoin is enabled, USB2 ports are shared between all Virtual Functions. The USB2 port number owned by an USB2 root hub in a Virtual Function may be less than total USB2 phy number supported by the Tegra XUSB controller. Using total USB2 phy number as port number to check all PORTSC values would cause invalid memory access. [ 116.923438] Unable to handle kernel paging request at virtual address 006c622f7665642f ... [ 117.213640] Call trace: [ 117.216783] tegra_xusb_enter_elpg+0x23c/0x658 [ 117.222021] tegra_xusb_runtime_suspend+0x40/0x68 [ 117.227260] pm_generic_runtime_suspend+0x30/0x50 [ 117.232847] __rpm_callback+0x84/0x3c0 [ 117.237038] rpm_suspend+0x2dc/0x740 [ 117.241229] pm_runtime_work+0xa0/0xb8 [ 117.245769] process_scheduled_works+0x24c/0x478 [ 117.251007] worker_thread+0x23c/0x328 [ 117.255547] kthread+0x104/0x1b0 [ 117.259389] ret_from_fork+0x10/0x20 [ 117.263582] Code: 54000222 f9461ae8 f8747908 b4ffff48 (f9400100)", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50076", "url": "https://ubuntu.com/security/CVE-2024-50076", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vt: prevent kernel-infoleak in con_font_get() font.data may not initialize all memory spaces depending on the implementation of vc->vc_sw->con_font_get. This may cause info-leak, so to prevent this, it is safest to modify it to initialize the allocated memory space to 0, and it generally does not affect the overall performance of the system.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50077", "url": "https://ubuntu.com/security/CVE-2024-50077", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: ISO: Fix multiple init when debugfs is disabled If bt_debugfs is not created successfully, which happens if either CONFIG_DEBUG_FS or CONFIG_DEBUG_FS_ALLOW_ALL is unset, then iso_init() returns early and does not set iso_inited to true. This means that a subsequent call to iso_init() will result in duplicate calls to proto_register(), bt_sock_register(), etc. With CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, the duplicate call to proto_register() triggers this BUG(): list_add double add: new=ffffffffc0b280d0, prev=ffffffffbab56250, next=ffffffffc0b280d0. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:35! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 2 PID: 887 Comm: bluetoothd Not tainted 6.10.11-1-ao-desktop #1 RIP: 0010:__list_add_valid_or_report+0x9a/0xa0 ... __list_add_valid_or_report+0x9a/0xa0 proto_register+0x2b5/0x340 iso_init+0x23/0x150 [bluetooth] set_iso_socket_func+0x68/0x1b0 [bluetooth] kmem_cache_free+0x308/0x330 hci_sock_sendmsg+0x990/0x9e0 [bluetooth] __sock_sendmsg+0x7b/0x80 sock_write_iter+0x9a/0x110 do_iter_readv_writev+0x11d/0x220 vfs_writev+0x180/0x3e0 do_writev+0xca/0x100 ... This change removes the early return. The check for iso_debugfs being NULL was unnecessary, it is always NULL when iso_inited is false.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50078", "url": "https://ubuntu.com/security/CVE-2024-50078", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Call iso_exit() on module unload If iso_init() has been called, iso_exit() must be called on module unload. Without that, the struct proto that iso_init() registered with proto_register() becomes invalid, which could cause unpredictable problems later. In my case, with CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, loading the module again usually triggers this BUG(): list_add corruption. next->prev should be prev (ffffffffb5355fd0), but was 0000000000000068. (next=ffffffffc0a010d0). ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:29! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 4159 Comm: modprobe Not tainted 6.10.11-4+bt2-ao-desktop #1 RIP: 0010:__list_add_valid_or_report+0x61/0xa0 ... __list_add_valid_or_report+0x61/0xa0 proto_register+0x299/0x320 hci_sock_init+0x16/0xc0 [bluetooth] bt_init+0x68/0xd0 [bluetooth] __pfx_bt_init+0x10/0x10 [bluetooth] do_one_initcall+0x80/0x2f0 do_init_module+0x8b/0x230 __do_sys_init_module+0x15f/0x190 do_syscall_64+0x68/0x110 ...", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50198", "url": "https://ubuntu.com/security/CVE-2024-50198", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iio: light: veml6030: fix IIO device retrieval from embedded device The dev pointer that is received as an argument in the in_illuminance_period_available_show function references the device embedded in the IIO device, not in the i2c client. dev_to_iio_dev() must be used to accessthe right data. The current implementation leads to a segmentation fault on every attempt to read the attribute because indio_dev gets a NULL assignment. This bug has been present since the first appearance of the driver, apparently since the last version (V6) before getting applied. A constant attribute was used until then, and the last modifications might have not been tested again.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50201", "url": "https://ubuntu.com/security/CVE-2024-50201", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/radeon: Fix encoder->possible_clones Include the encoder itself in its possible_clones bitmask. In the past nothing validated that drivers were populating possible_clones correctly, but that changed in commit 74d2aacbe840 (\"drm: Validate encoder->possible_clones\"). Looks like radeon never got the memo and is still not following the rules 100% correctly. This results in some warnings during driver initialization: Bogus possible_clones: [ENCODER:46:TV-46] possible_clones=0x4 (full encoder mask=0x7) WARNING: CPU: 0 PID: 170 at drivers/gpu/drm/drm_mode_config.c:615 drm_mode_config_validate+0x113/0x39c ... (cherry picked from commit 3b6e7d40649c0d75572039aff9d0911864c689db)", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50098", "url": "https://ubuntu.com/security/CVE-2024-50098", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Set SDEV_OFFLINE when UFS is shut down There is a history of deadlock if reboot is performed at the beginning of booting. SDEV_QUIESCE was set for all LU's scsi_devices by UFS shutdown, and at that time the audio driver was waiting on blk_mq_submit_bio() holding a mutex_lock while reading the fw binary. After that, a deadlock issue occurred while audio driver shutdown was waiting for mutex_unlock of blk_mq_submit_bio(). To solve this, set SDEV_OFFLINE for all LUs except WLUN, so that any I/O that comes down after a UFS shutdown will return an error. [ 31.907781]I[0: swapper/0: 0] 1 130705007 1651079834 11289729804 0 D( 2) 3 ffffff882e208000 * init [device_shutdown] [ 31.907793]I[0: swapper/0: 0] Mutex: 0xffffff8849a2b8b0: owner[0xffffff882e28cb00 kworker/6:0 :49] [ 31.907806]I[0: swapper/0: 0] Call trace: [ 31.907810]I[0: swapper/0: 0] __switch_to+0x174/0x338 [ 31.907819]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc [ 31.907826]I[0: swapper/0: 0] schedule+0x7c/0xe8 [ 31.907834]I[0: swapper/0: 0] schedule_preempt_disabled+0x24/0x40 [ 31.907842]I[0: swapper/0: 0] __mutex_lock+0x408/0xdac [ 31.907849]I[0: swapper/0: 0] __mutex_lock_slowpath+0x14/0x24 [ 31.907858]I[0: swapper/0: 0] mutex_lock+0x40/0xec [ 31.907866]I[0: swapper/0: 0] device_shutdown+0x108/0x280 [ 31.907875]I[0: swapper/0: 0] kernel_restart+0x4c/0x11c [ 31.907883]I[0: swapper/0: 0] __arm64_sys_reboot+0x15c/0x280 [ 31.907890]I[0: swapper/0: 0] invoke_syscall+0x70/0x158 [ 31.907899]I[0: swapper/0: 0] el0_svc_common+0xb4/0xf4 [ 31.907909]I[0: swapper/0: 0] do_el0_svc+0x2c/0xb0 [ 31.907918]I[0: swapper/0: 0] el0_svc+0x34/0xe0 [ 31.907928]I[0: swapper/0: 0] el0t_64_sync_handler+0x68/0xb4 [ 31.907937]I[0: swapper/0: 0] el0t_64_sync+0x1a0/0x1a4 [ 31.908774]I[0: swapper/0: 0] 49 0 11960702 11236868007 0 D( 2) 6 ffffff882e28cb00 * kworker/6:0 [__bio_queue_enter] [ 31.908783]I[0: swapper/0: 0] Call trace: [ 31.908788]I[0: swapper/0: 0] __switch_to+0x174/0x338 [ 31.908796]I[0: swapper/0: 0] __schedule+0x5ec/0x9cc [ 31.908803]I[0: swapper/0: 0] schedule+0x7c/0xe8 [ 31.908811]I[0: swapper/0: 0] __bio_queue_enter+0xb8/0x178 [ 31.908818]I[0: swapper/0: 0] blk_mq_submit_bio+0x194/0x67c [ 31.908827]I[0: swapper/0: 0] __submit_bio+0xb8/0x19c", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50079", "url": "https://ubuntu.com/security/CVE-2024-50079", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring/sqpoll: ensure task state is TASK_RUNNING when running task_work When the sqpoll is exiting and cancels pending work items, it may need to run task_work. If this happens from within io_uring_cancel_generic(), then it may be under waiting for the io_uring_task waitqueue. This results in the below splat from the scheduler, as the ring mutex may be attempted grabbed while in a TASK_INTERRUPTIBLE state. Ensure that the task state is set appropriately for that, just like what is done for the other cases in io_run_task_work(). do not call blocking ops when !TASK_RUNNING; state=1 set at [<0000000029387fd2>] prepare_to_wait+0x88/0x2fc WARNING: CPU: 6 PID: 59939 at kernel/sched/core.c:8561 __might_sleep+0xf4/0x140 Modules linked in: CPU: 6 UID: 0 PID: 59939 Comm: iou-sqp-59938 Not tainted 6.12.0-rc3-00113-g8d020023b155 #7456 Hardware name: linux,dummy-virt (DT) pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) pc : __might_sleep+0xf4/0x140 lr : __might_sleep+0xf4/0x140 sp : ffff80008c5e7830 x29: ffff80008c5e7830 x28: ffff0000d93088c0 x27: ffff60001c2d7230 x26: dfff800000000000 x25: ffff0000e16b9180 x24: ffff80008c5e7a50 x23: 1ffff000118bcf4a x22: ffff0000e16b9180 x21: ffff0000e16b9180 x20: 000000000000011b x19: ffff80008310fac0 x18: 1ffff000118bcd90 x17: 30303c5b20746120 x16: 74657320313d6574 x15: 0720072007200720 x14: 0720072007200720 x13: 0720072007200720 x12: ffff600036c64f0b x11: 1fffe00036c64f0a x10: ffff600036c64f0a x9 : dfff800000000000 x8 : 00009fffc939b0f6 x7 : ffff0001b6327853 x6 : 0000000000000001 x5 : ffff0001b6327850 x4 : ffff600036c64f0b x3 : ffff8000803c35bc x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000e16b9180 Call trace: __might_sleep+0xf4/0x140 mutex_lock+0x84/0x124 io_handle_tw_list+0xf4/0x260 tctx_task_work_run+0x94/0x340 io_run_task_work+0x1ec/0x3c0 io_uring_cancel_generic+0x364/0x524 io_sq_thread+0x820/0x124c ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50080", "url": "https://ubuntu.com/security/CVE-2024-50080", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ublk: don't allow user copy for unprivileged device UBLK_F_USER_COPY requires userspace to call write() on ublk char device for filling request buffer, and unprivileged device can't be trusted. So don't allow user copy for unprivileged device.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50081", "url": "https://ubuntu.com/security/CVE-2024-50081", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-mq: setup queue ->tag_set before initializing hctx Commit 7b815817aa58 (\"blk-mq: add helper for checking if one CPU is mapped to specified hctx\") needs to check queue mapping via tag set in hctx's cpuhp handler. However, q->tag_set may not be setup yet when the cpuhp handler is enabled, then kernel oops is triggered. Fix the issue by setup queue tag_set before initializing hctx.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50082", "url": "https://ubuntu.com/security/CVE-2024-50082", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race We're seeing crashes from rq_qos_wake_function that look like this: BUG: unable to handle page fault for address: ffffafe180a40084 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 100000067 P4D 100000067 PUD 10027c067 PMD 10115d067 PTE 0 Oops: Oops: 0002 [#1] PREEMPT SMP PTI CPU: 17 UID: 0 PID: 0 Comm: swapper/17 Not tainted 6.12.0-rc3-00013-geca631b8fe80 #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:_raw_spin_lock_irqsave+0x1d/0x40 Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 9c 41 5c fa 65 ff 05 62 97 30 4c 31 c0 ba 01 00 00 00 0f b1 17 75 0a 4c 89 e0 41 5c c3 cc cc cc cc 89 c6 e8 2c 0b 00 RSP: 0018:ffffafe180580ca0 EFLAGS: 00010046 RAX: 0000000000000000 RBX: ffffafe180a3f7a8 RCX: 0000000000000011 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffffafe180a40084 RBP: 0000000000000000 R08: 00000000001e7240 R09: 0000000000000011 R10: 0000000000000028 R11: 0000000000000888 R12: 0000000000000002 R13: ffffafe180a40084 R14: 0000000000000000 R15: 0000000000000003 FS: 0000000000000000(0000) GS:ffff9aaf1f280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffafe180a40084 CR3: 000000010e428002 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: try_to_wake_up+0x5a/0x6a0 rq_qos_wake_function+0x71/0x80 __wake_up_common+0x75/0xa0 __wake_up+0x36/0x60 scale_up.part.0+0x50/0x110 wb_timer_fn+0x227/0x450 ... So rq_qos_wake_function() calls wake_up_process(data->task), which calls try_to_wake_up(), which faults in raw_spin_lock_irqsave(&p->pi_lock). p comes from data->task, and data comes from the waitqueue entry, which is stored on the waiter's stack in rq_qos_wait(). Analyzing the core dump with drgn, I found that the waiter had already woken up and moved on to a completely unrelated code path, clobbering what was previously data->task. Meanwhile, the waker was passing the clobbered garbage in data->task to wake_up_process(), leading to the crash. What's happening is that in between rq_qos_wake_function() deleting the waitqueue entry and calling wake_up_process(), rq_qos_wait() is finding that it already got a token and returning. The race looks like this: rq_qos_wait() rq_qos_wake_function() ============================================================== prepare_to_wait_exclusive() data->got_token = true; list_del_init(&curr->entry); if (data.got_token) break; finish_wait(&rqw->wait, &data.wq); ^- returns immediately because list_empty_careful(&wq_entry->entry) is true ... return, go do something else ... wake_up_process(data->task) (NO LONGER VALID!)-^ Normally, finish_wait() is supposed to synchronize against the waker. But, as noted above, it is returning immediately because the waitqueue entry has already been removed from the waitqueue. The bug is that rq_qos_wake_function() is accessing the waitqueue entry AFTER deleting it. Note that autoremove_wake_function() wakes the waiter and THEN deletes the waitqueue entry, which is the proper order. Fix it by swapping the order. We also need to use list_del_init_careful() to match the list_empty_careful() in finish_wait().", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50101", "url": "https://ubuntu.com/security/CVE-2024-50101", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI devices Previously, the domain_context_clear() function incorrectly called pci_for_each_dma_alias() to set up context entries for non-PCI devices. This could lead to kernel hangs or other unexpected behavior. Add a check to only call pci_for_each_dma_alias() for PCI devices. For non-PCI devices, domain_context_clear_one() is called directly.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50083", "url": "https://ubuntu.com/security/CVE-2024-50083", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: fix mptcp DSS corruption due to large pmtu xmit Syzkaller was able to trigger a DSS corruption: TCP: request_sock_subflow_v4: Possible SYN flooding on port [::]:20002. Sending cookies. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 5227 at net/mptcp/protocol.c:695 __mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695 Modules linked in: CPU: 0 UID: 0 PID: 5227 Comm: syz-executor350 Not tainted 6.11.0-syzkaller-08829-gaf9c191ac2a0 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:__mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695 Code: 0f b6 dc 31 ff 89 de e8 b5 dd ea f5 89 d8 48 81 c4 50 01 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 98 da ea f5 90 <0f> 0b 90 e9 47 ff ff ff e8 8a da ea f5 90 0f 0b 90 e9 99 e0 ff ff RSP: 0018:ffffc90000006db8 EFLAGS: 00010246 RAX: ffffffff8ba9df18 RBX: 00000000000055f0 RCX: ffff888030023c00 RDX: 0000000000000100 RSI: 00000000000081e5 RDI: 00000000000055f0 RBP: 1ffff110062bf1ae R08: ffffffff8ba9cf12 R09: 1ffff110062bf1b8 R10: dffffc0000000000 R11: ffffed10062bf1b9 R12: 0000000000000000 R13: dffffc0000000000 R14: 00000000700cec61 R15: 00000000000081e5 FS: 000055556679c380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020287000 CR3: 0000000077892000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: move_skbs_to_msk net/mptcp/protocol.c:811 [inline] mptcp_data_ready+0x29c/0xa90 net/mptcp/protocol.c:854 subflow_data_ready+0x34a/0x920 net/mptcp/subflow.c:1490 tcp_data_queue+0x20fd/0x76c0 net/ipv4/tcp_input.c:5283 tcp_rcv_established+0xfba/0x2020 net/ipv4/tcp_input.c:6237 tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915 tcp_v4_rcv+0x2dc0/0x37f0 net/ipv4/tcp_ipv4.c:2350 ip_protocol_deliver_rcu+0x22e/0x440 net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x341/0x5f0 net/ipv4/ip_input.c:233 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314 NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314 __netif_receive_skb_one_core net/core/dev.c:5662 [inline] __netif_receive_skb+0x2bf/0x650 net/core/dev.c:5775 process_backlog+0x662/0x15b0 net/core/dev.c:6107 __napi_poll+0xcb/0x490 net/core/dev.c:6771 napi_poll net/core/dev.c:6840 [inline] net_rx_action+0x89b/0x1240 net/core/dev.c:6962 handle_softirqs+0x2c5/0x980 kernel/softirq.c:554 do_softirq+0x11b/0x1e0 kernel/softirq.c:455 __local_bh_enable_ip+0x1bb/0x200 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline] __dev_queue_xmit+0x1764/0x3e80 net/core/dev.c:4451 dev_queue_xmit include/linux/netdevice.h:3094 [inline] neigh_hh_output include/net/neighbour.h:526 [inline] neigh_output include/net/neighbour.h:540 [inline] ip_finish_output2+0xd41/0x1390 net/ipv4/ip_output.c:236 ip_local_out net/ipv4/ip_output.c:130 [inline] __ip_queue_xmit+0x118c/0x1b80 net/ipv4/ip_output.c:536 __tcp_transmit_skb+0x2544/0x3b30 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_mtu_probe net/ipv4/tcp_output.c:2547 [inline] tcp_write_xmit+0x641d/0x6bf0 net/ipv4/tcp_output.c:2752 __tcp_push_pending_frames+0x9b/0x360 net/ipv4/tcp_output.c:3015 tcp_push_pending_frames include/net/tcp.h:2107 [inline] tcp_data_snd_check net/ipv4/tcp_input.c:5714 [inline] tcp_rcv_established+0x1026/0x2020 net/ipv4/tcp_input.c:6239 tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915 sk_backlog_rcv include/net/sock.h:1113 [inline] __release_sock+0x214/0x350 net/core/sock.c:3072 release_sock+0x61/0x1f0 net/core/sock.c:3626 mptcp_push_ ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50068", "url": "https://ubuntu.com/security/CVE-2024-50068", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/damon/tests/sysfs-kunit.h: fix memory leak in damon_sysfs_test_add_targets() The sysfs_target->regions allocated in damon_sysfs_regions_alloc() is not freed in damon_sysfs_test_add_targets(), which cause the following memory leak, free it to fix it. \tunreferenced object 0xffffff80c2a8db80 (size 96): \t comm \"kunit_try_catch\", pid 187, jiffies 4294894363 \t hex dump (first 32 bytes): \t 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ \t 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ \t backtrace (crc 0): \t [<0000000001e3714d>] kmemleak_alloc+0x34/0x40 \t [<000000008e6835c1>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000001286d9f8>] damon_sysfs_test_add_targets+0x1cc/0x738 \t [<0000000032ef8f77>] kunit_try_run_case+0x13c/0x3ac \t [<00000000f3edea23>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000adf936cf>] kthread+0x2e8/0x374 \t [<0000000041bb1628>] ret_from_fork+0x10/0x20", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50199", "url": "https://ubuntu.com/security/CVE-2024-50199", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/swapfile: skip HugeTLB pages for unuse_vma I got a bad pud error and lost a 1GB HugeTLB when calling swapoff. The problem can be reproduced by the following steps: 1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory. 2. Swapout the above anonymous memory. 3. run swapoff and we will get a bad pud error in kernel message: mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7) We can tell that pud_clear_bad is called by pud_none_or_clear_bad in unuse_pud_range() by ftrace. And therefore the HugeTLB pages will never be freed because we lost it from page table. We can skip HugeTLB pages for unuse_vma to fix it.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50066", "url": "https://ubuntu.com/security/CVE-2024-50066", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/mremap: fix move_normal_pmd/retract_page_tables race In mremap(), move_page_tables() looks at the type of the PMD entry and the specified address range to figure out by which method the next chunk of page table entries should be moved. At that point, the mmap_lock is held in write mode, but no rmap locks are held yet. For PMD entries that point to page tables and are fully covered by the source address range, move_pgt_entry(NORMAL_PMD, ...) is called, which first takes rmap locks, then does move_normal_pmd(). move_normal_pmd() takes the necessary page table locks at source and destination, then moves an entire page table from the source to the destination. The problem is: The rmap locks, which protect against concurrent page table removal by retract_page_tables() in the THP code, are only taken after the PMD entry has been read and it has been decided how to move it. So we can race as follows (with two processes that have mappings of the same tmpfs file that is stored on a tmpfs mount with huge=advise); note that process A accesses page tables through the MM while process B does it through the file rmap: process A process B ========= ========= mremap mremap_to move_vma move_page_tables get_old_pmd alloc_new_pmd *** PREEMPT *** madvise(MADV_COLLAPSE) do_madvise madvise_walk_vmas madvise_vma_behavior madvise_collapse hpage_collapse_scan_file collapse_file retract_page_tables i_mmap_lock_read(mapping) pmdp_collapse_flush i_mmap_unlock_read(mapping) move_pgt_entry(NORMAL_PMD, ...) take_rmap_locks move_normal_pmd drop_rmap_locks When this happens, move_normal_pmd() can end up creating bogus PMD entries in the line `pmd_populate(mm, new_pmd, pmd_pgtable(pmd))`. The effect depends on arch-specific and machine-specific details; on x86, you can end up with physical page 0 mapped as a page table, which is likely exploitable for user->kernel privilege escalation. Fix the race by letting process B recheck that the PMD still points to a page table after the rmap locks have been taken. Otherwise, we bail and let the caller fall back to the PTE-level copying path, which will then bail immediately at the pmd_none() check. Bug reachability: Reaching this bug requires that you can create shmem/file THP mappings - anonymous THP uses different code that doesn't zap stuff under rmap locks. File THP is gated on an experimental config flag (CONFIG_READ_ONLY_THP_FOR_FS), so on normal distro kernels you need shmem THP to hit this bug. As far as I know, getting shmem THP normally requires that you can mount your own tmpfs with the right mount flags, which would require creating your own user+mount namespace; though I don't know if some distros maybe enable shmem THP by default or something like that. Bug impact: This issue can likely be used for user->kernel privilege escalation when it is reachable.", "cve_priority": "medium", "cve_public_date": "2024-10-23 06:15:00 UTC" }, { "cve": "CVE-2024-50202", "url": "https://ubuntu.com/security/CVE-2024-50202", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: propagate directory read errors from nilfs_find_entry() Syzbot reported that a task hang occurs in vcs_open() during a fuzzing test for nilfs2. The root cause of this problem is that in nilfs_find_entry(), which searches for directory entries, ignores errors when loading a directory page/folio via nilfs_get_folio() fails. If the filesystem images is corrupted, and the i_size of the directory inode is large, and the directory page/folio is successfully read but fails the sanity check, for example when it is zero-filled, nilfs_check_folio() may continue to spit out error messages in bursts. Fix this issue by propagating the error to the callers when loading a page/folio fails in nilfs_find_entry(). The current interface of nilfs_find_entry() and its callers is outdated and cannot propagate error codes such as -EIO and -ENOMEM returned via nilfs_find_entry(), so fix it together.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50200", "url": "https://ubuntu.com/security/CVE-2024-50200", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: maple_tree: correct tree corruption on spanning store Patch series \"maple_tree: correct tree corruption on spanning store\", v3. There has been a nasty yet subtle maple tree corruption bug that appears to have been in existence since the inception of the algorithm. This bug seems far more likely to happen since commit f8d112a4e657 (\"mm/mmap: avoid zeroing vma tree in mmap_region()\"), which is the point at which reports started to be submitted concerning this bug. We were made definitely aware of the bug thanks to the kind efforts of Bert Karwatzki who helped enormously in my being able to track this down and identify the cause of it. The bug arises when an attempt is made to perform a spanning store across two leaf nodes, where the right leaf node is the rightmost child of the shared parent, AND the store completely consumes the right-mode node. This results in mas_wr_spanning_store() mitakenly duplicating the new and existing entries at the maximum pivot within the range, and thus maple tree corruption. The fix patch corrects this by detecting this scenario and disallowing the mistaken duplicate copy. The fix patch commit message goes into great detail as to how this occurs. This series also includes a test which reliably reproduces the issue, and asserts that the fix works correctly. Bert has kindly tested the fix and confirmed it resolved his issues. Also Mikhail Gavrilov kindly reported what appears to be precisely the same bug, which this fix should also resolve. This patch (of 2): There has been a subtle bug present in the maple tree implementation from its inception. This arises from how stores are performed - when a store occurs, it will overwrite overlapping ranges and adjust the tree as necessary to accommodate this. A range may always ultimately span two leaf nodes. In this instance we walk the two leaf nodes, determine which elements are not overwritten to the left and to the right of the start and end of the ranges respectively and then rebalance the tree to contain these entries and the newly inserted one. This kind of store is dubbed a 'spanning store' and is implemented by mas_wr_spanning_store(). In order to reach this stage, mas_store_gfp() invokes mas_wr_preallocate(), mas_wr_store_type() and mas_wr_walk() in turn to walk the tree and update the object (mas) to traverse to the location where the write should be performed, determining its store type. When a spanning store is required, this function returns false stopping at the parent node which contains the target range, and mas_wr_store_type() marks the mas->store_type as wr_spanning_store to denote this fact. When we go to perform the store in mas_wr_spanning_store(), we first determine the elements AFTER the END of the range we wish to store (that is, to the right of the entry to be inserted) - we do this by walking to the NEXT pivot in the tree (i.e. r_mas.last + 1), starting at the node we have just determined contains the range over which we intend to write. We then turn our attention to the entries to the left of the entry we are inserting, whose state is represented by l_mas, and copy these into a 'big node', which is a special node which contains enough slots to contain two leaf node's worth of data. We then copy the entry we wish to store immediately after this - the copy and the insertion of the new entry is performed by mas_store_b_node(). After this we copy the elements to the right of the end of the range which we are inserting, if we have not exceeded the length of the node (i.e. r_mas.offset <= r_mas.end). Herein lies the bug - under very specific circumstances, this logic can break and corrupt the maple tree. Consider the following tree: Height 0 Root Node / \\ pivot = 0xffff / \\ pivot = ULONG_MAX / ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50084", "url": "https://ubuntu.com/security/CVE-2024-50084", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: microchip: vcap api: Fix memory leaks in vcap_api_encode_rule_test() Commit a3c1e45156ad (\"net: microchip: vcap: Fix use-after-free error in kunit test\") fixed the use-after-free error, but introduced below memory leaks by removing necessary vcap_free_rule(), add it to fix it. \tunreferenced object 0xffffff80ca58b700 (size 192): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898264 \t hex dump (first 32 bytes): \t 00 12 7a 00 05 00 00 00 0a 00 00 00 64 00 00 00 ..z.........d... \t 00 00 00 00 00 00 00 00 00 04 0b cc 80 ff ff ff ................ \t backtrace (crc 9c09c3fe): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<0000000040a01b8d>] vcap_alloc_rule+0x3cc/0x9c4 \t [<000000003fe86110>] vcap_api_encode_rule_test+0x1ac/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0400 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898265 \t hex dump (first 32 bytes): \t 80 04 0b cc 80 ff ff ff 18 b7 58 ca 80 ff ff ff ..........X..... \t 39 00 00 00 02 00 00 00 06 05 04 03 02 01 ff ff 9............... \t backtrace (crc daf014e9): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<00000000dfdb1e81>] vcap_api_encode_rule_test+0x224/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0700 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898265 \t hex dump (first 32 bytes): \t 80 07 0b cc 80 ff ff ff 28 b7 58 ca 80 ff ff ff ........(.X..... \t 3c 00 00 00 00 00 00 00 01 2f 03 b3 ec ff ff ff <......../...... \t backtrace (crc 8d877792): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000006eadfab7>] vcap_rule_add_action+0x2d0/0x52c \t [<00000000323475d1>] vcap_api_encode_rule_test+0x4d4/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0900 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898266 \t hex dump (first 32 bytes): \t 80 09 0b cc 80 ff ff ff 80 06 0b cc 80 ff ff ff ................ \t 7d 00 00 00 01 00 00 00 00 00 00 00 ff 00 00 00 }............... \t backtrace (crc 34181e56): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<00000000991e3564>] vcap_val_rule+0xcf0/0x13e8 \t [<00000000fc9868e5>] vcap_api_encode_rule_test+0x678/0x16b0 \t [<00000000b3595fc4>] kunit_try_run_case+0x13c/0x3ac \t [<0000000010f5d2bf>] kunit_generic_run_threadfn_adapter+0x80/0xec \t [<00000000c5d82c9a>] kthread+0x2e8/0x374 \t [<00000000f4287308>] ret_from_fork+0x10/0x20 \tunreferenced object 0xffffff80cc0b0980 (size 64): \t comm \"kunit_try_catch\", pid 1215, jiffies 4294898266 \t hex dump (first 32 bytes): \t 18 b7 58 ca 80 ff ff ff 00 09 0b cc 80 ff ff ff ..X............. \t 67 00 00 00 00 00 00 00 01 01 74 88 c0 ff ff ff g.........t..... \t backtrace (crc 275fd9be): \t [<0000000052a0be73>] kmemleak_alloc+0x34/0x40 \t [<0000000043605459>] __kmalloc_cache_noprof+0x26c/0x2f4 \t [<000000000ff63fd4>] vcap_rule_add_key+0x2cc/0x528 \t [<000000001396a1a2>] test_add_de ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50194", "url": "https://ubuntu.com/security/CVE-2024-50194", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Fix uprobes for big-endian kernels The arm64 uprobes code is broken for big-endian kernels as it doesn't convert the in-memory instruction encoding (which is always little-endian) into the kernel's native endianness before analyzing and simulating instructions. This may result in a few distinct problems: * The kernel may may erroneously reject probing an instruction which can safely be probed. * The kernel may erroneously erroneously permit stepping an instruction out-of-line when that instruction cannot be stepped out-of-line safely. * The kernel may erroneously simulate instruction incorrectly dur to interpretting the byte-swapped encoding. The endianness mismatch isn't caught by the compiler or sparse because: * The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so the compiler and sparse have no idea these contain a little-endian 32-bit value. The core uprobes code populates these with a memcpy() which similarly does not handle endianness. * While the uprobe_opcode_t type is an alias for __le32, both arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[] to the similarly-named probe_opcode_t, which is an alias for u32. Hence there is no endianness conversion warning. Fix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and adding the appropriate __le32_to_cpu() conversions prior to consuming the instruction encoding. The core uprobes copies these fields as opaque ranges of bytes, and so is unaffected by this change. At the same time, remove MAX_UINSN_BYTES and consistently use AARCH64_INSN_SIZE for clarity. Tested with the following: | #include | #include | | #define noinline __attribute__((noinline)) | | static noinline void *adrp_self(void) | { | void *addr; | | asm volatile( | \" adrp %x0, adrp_self\\n\" | \" add %x0, %x0, :lo12:adrp_self\\n\" | : \"=r\" (addr)); | } | | | int main(int argc, char *argv) | { | void *ptr = adrp_self(); | bool equal = (ptr == adrp_self); | | printf(\"adrp_self => %p\\n\" | \"adrp_self() => %p\\n\" | \"%s\\n\", | adrp_self, ptr, equal ? \"EQUAL\" : \"NOT EQUAL\"); | | return 0; | } .... where the adrp_self() function was compiled to: | 00000000004007e0 : | 4007e0: 90000000 adrp x0, 400000 <__ehdr_start> | 4007e4: 911f8000 add x0, x0, #0x7e0 | 4007e8: d65f03c0 ret Before this patch, the ADRP is not recognized, and is assumed to be steppable, resulting in corruption of the result: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0xffffffffff7e0 | NOT EQUAL After this patch, the ADRP is correctly recognized and simulated: | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL | # | # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events | # echo 1 > /sys/kernel/tracing/events/uprobes/enable | # ./adrp-self | adrp_self => 0x4007e0 | adrp_self() => 0x4007e0 | EQUAL", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50099", "url": "https://ubuntu.com/security/CVE-2024-50099", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: arm64: probes: Remove broken LDR (literal) uprobe support The simulate_ldr_literal() and simulate_ldrsw_literal() functions are unsafe to use for uprobes. Both functions were originally written for use with kprobes, and access memory with plain C accesses. When uprobes was added, these were reused unmodified even though they cannot safely access user memory. There are three key problems: 1) The plain C accesses do not have corresponding extable entries, and thus if they encounter a fault the kernel will treat these as unintentional accesses to user memory, resulting in a BUG() which will kill the kernel thread, and likely lead to further issues (e.g. lockup or panic()). 2) The plain C accesses are subject to HW PAN and SW PAN, and so when either is in use, any attempt to simulate an access to user memory will fault. Thus neither simulate_ldr_literal() nor simulate_ldrsw_literal() can do anything useful when simulating a user instruction on any system with HW PAN or SW PAN. 3) The plain C accesses are privileged, as they run in kernel context, and in practice can access a small range of kernel virtual addresses. The instructions they simulate have a range of +/-1MiB, and since the simulated instructions must itself be a user instructions in the TTBR0 address range, these can address the final 1MiB of the TTBR1 acddress range by wrapping downwards from an address in the first 1MiB of the TTBR0 address range. In contemporary kernels the last 8MiB of TTBR1 address range is reserved, and accesses to this will always fault, meaning this is no worse than (1). Historically, it was theoretically possible for the linear map or vmemmap to spill into the final 8MiB of the TTBR1 address range, but in practice this is extremely unlikely to occur as this would require either: * Having enough physical memory to fill the entire linear map all the way to the final 1MiB of the TTBR1 address range. * Getting unlucky with KASLR randomization of the linear map such that the populated region happens to overlap with the last 1MiB of the TTBR address range. ... and in either case if we were to spill into the final page there would be larger problems as the final page would alias with error pointers. Practically speaking, (1) and (2) are the big issues. Given there have been no reports of problems since the broken code was introduced, it appears that no-one is relying on probing these instructions with uprobes. Avoid these issues by not allowing uprobes on LDR (literal) and LDRSW (literal), limiting the use of simulate_ldr_literal() and simulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR (literal) and LDRSW (literal) will be rejected as arm_probe_decode_insn() will return INSN_REJECTED. In future we can consider introducing working uprobes support for these instructions, but this will require more significant work.", "cve_priority": "medium", "cve_public_date": "2024-11-05 18:15:00 UTC" }, { "cve": "CVE-2024-50195", "url": "https://ubuntu.com/security/CVE-2024-50195", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: posix-clock: Fix missing timespec64 check in pc_clock_settime() As Andrew pointed out, it will make sense that the PTP core checked timespec64 struct's tv_sec and tv_nsec range before calling ptp->info->settime64(). As the man manual of clock_settime() said, if tp.tv_sec is negative or tp.tv_nsec is outside the range [0..999,999,999], it should return EINVAL, which include dynamic clocks which handles PTP clock, and the condition is consistent with timespec64_valid(). As Thomas suggested, timespec64_valid() only check the timespec is valid, but not ensure that the time is in a valid range, so check it ahead using timespec64_valid_strict() in pc_clock_settime() and return -EINVAL if not valid. There are some drivers that use tp->tv_sec and tp->tv_nsec directly to write registers without validity checks and assume that the higher layer has checked it, which is dangerous and will benefit from this, such as hclge_ptp_settime(), igb_ptp_settime_i210(), _rcar_gen4_ptp_settime(), and some drivers can remove the checks of itself.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50085", "url": "https://ubuntu.com/security/CVE-2024-50085", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: pm: fix UaF read in mptcp_pm_nl_rm_addr_or_subflow Syzkaller reported this splat: ================================================================== BUG: KASAN: slab-use-after-free in mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881 Read of size 4 at addr ffff8880569ac858 by task syz.1.2799/14662 CPU: 0 UID: 0 PID: 14662 Comm: syz.1.2799 Not tainted 6.12.0-rc2-syzkaller-00307-g36c254515dc6 #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+0x116/0x1f0 lib/dump_stack.c:120 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 mptcp_pm_nl_rm_addr_or_subflow+0xb44/0xcc0 net/mptcp/pm_netlink.c:881 mptcp_pm_nl_rm_subflow_received net/mptcp/pm_netlink.c:914 [inline] mptcp_nl_remove_id_zero_address+0x305/0x4a0 net/mptcp/pm_netlink.c:1572 mptcp_pm_nl_del_addr_doit+0x5c9/0x770 net/mptcp/pm_netlink.c:1603 genl_family_rcv_msg_doit+0x202/0x2f0 net/netlink/genetlink.c:1115 genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline] genl_rcv_msg+0x565/0x800 net/netlink/genetlink.c:1210 netlink_rcv_skb+0x165/0x410 net/netlink/af_netlink.c:2551 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219 netlink_unicast_kernel net/netlink/af_netlink.c:1331 [inline] netlink_unicast+0x53c/0x7f0 net/netlink/af_netlink.c:1357 netlink_sendmsg+0x8b8/0xd70 net/netlink/af_netlink.c:1901 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg net/socket.c:744 [inline] ____sys_sendmsg+0x9ae/0xb40 net/socket.c:2607 ___sys_sendmsg+0x135/0x1e0 net/socket.c:2661 __sys_sendmsg+0x117/0x1f0 net/socket.c:2690 do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline] __do_fast_syscall_32+0x73/0x120 arch/x86/entry/common.c:386 do_fast_syscall_32+0x32/0x80 arch/x86/entry/common.c:411 entry_SYSENTER_compat_after_hwframe+0x84/0x8e RIP: 0023:0xf7fe4579 Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00 RSP: 002b:00000000f574556c EFLAGS: 00000296 ORIG_RAX: 0000000000000172 RAX: ffffffffffffffda RBX: 000000000000000b RCX: 0000000020000140 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000296 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Allocated by task 5387: 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 kmalloc_noprof include/linux/slab.h:878 [inline] kzalloc_noprof include/linux/slab.h:1014 [inline] subflow_create_ctx+0x87/0x2a0 net/mptcp/subflow.c:1803 subflow_ulp_init+0xc3/0x4d0 net/mptcp/subflow.c:1956 __tcp_set_ulp net/ipv4/tcp_ulp.c:146 [inline] tcp_set_ulp+0x326/0x7f0 net/ipv4/tcp_ulp.c:167 mptcp_subflow_create_socket+0x4ae/0x10a0 net/mptcp/subflow.c:1764 __mptcp_subflow_connect+0x3cc/0x1490 net/mptcp/subflow.c:1592 mptcp_pm_create_subflow_or_signal_addr+0xbda/0x23a0 net/mptcp/pm_netlink.c:642 mptcp_pm_nl_fully_established net/mptcp/pm_netlink.c:650 [inline] mptcp_pm_nl_work+0x3a1/0x4f0 net/mptcp/pm_netlink.c:943 mptcp_worker+0x15a/0x1240 net/mptcp/protocol.c:2777 process_one_work+0x958/0x1b30 kernel/workqueue.c:3229 process_scheduled_works kernel/workqueue.c:3310 [inline] worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/ke ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50086", "url": "https://ubuntu.com/security/CVE-2024-50086", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix user-after-free from session log off There is racy issue between smb2 session log off and smb2 session setup. It will cause user-after-free from session log off. This add session_lock when setting SMB2_SESSION_EXPIRED and referece count to session struct not to free session while it is being used.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50087", "url": "https://ubuntu.com/security/CVE-2024-50087", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix uninitialized pointer free on read_alloc_one_name() error The function read_alloc_one_name() does not initialize the name field of the passed fscrypt_str struct if kmalloc fails to allocate the corresponding buffer. Thus, it is not guaranteed that fscrypt_str.name is initialized when freeing it. This is a follow-up to the linked patch that fixes the remaining instances of the bug introduced by commit e43eec81c516 (\"btrfs: use struct qstr instead of name and namelen pairs\").", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50088", "url": "https://ubuntu.com/security/CVE-2024-50088", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix uninitialized pointer free in add_inode_ref() The add_inode_ref() function does not initialize the \"name\" struct when it is declared. If any of the following calls to \"read_one_inode() returns NULL, \tdir = read_one_inode(root, parent_objectid); \tif (!dir) { \t\tret = -ENOENT; \t\tgoto out; \t} \tinode = read_one_inode(root, inode_objectid); \tif (!inode) { \t\tret = -EIO; \t\tgoto out; \t} then \"name.name\" would be freed on \"out\" before being initialized. out: \t... \tkfree(name.name); This issue was reported by Coverity with CID 1526744.", "cve_priority": "medium", "cve_public_date": "2024-10-29 01:15:00 UTC" }, { "cve": "CVE-2024-50182", "url": "https://ubuntu.com/security/CVE-2024-50182", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: secretmem: disable memfd_secret() if arch cannot set direct map Return -ENOSYS from memfd_secret() syscall if !can_set_direct_map(). This is the case for example on some arm64 configurations, where marking 4k PTEs in the direct map not present can only be done if the direct map is set up at 4k granularity in the first place (as ARM's break-before-make semantics do not easily allow breaking apart large/gigantic pages). More precisely, on arm64 systems with !can_set_direct_map(), set_direct_map_invalid_noflush() is a no-op, however it returns success (0) instead of an error. This means that memfd_secret will seemingly \"work\" (e.g. syscall succeeds, you can mmap the fd and fault in pages), but it does not actually achieve its goal of removing its memory from the direct map. Note that with this patch, memfd_secret() will start erroring on systems where can_set_direct_map() returns false (arm64 with CONFIG_RODATA_FULL_DEFAULT_ENABLED=n, CONFIG_DEBUG_PAGEALLOC=n and CONFIG_KFENCE=n), but that still seems better than the current silent failure. Since CONFIG_RODATA_FULL_DEFAULT_ENABLED defaults to 'y', most arm64 systems actually have a working memfd_secret() and aren't be affected. From going through the iterations of the original memfd_secret patch series, it seems that disabling the syscall in these scenarios was the intended behavior [1] (preferred over having set_direct_map_invalid_noflush return an error as that would result in SIGBUSes at page-fault time), however the check for it got dropped between v16 [2] and v17 [3], when secretmem moved away from CMA allocations. [1]: https://lore.kernel.org/lkml/20201124164930.GK8537@kernel.org/ [2]: https://lore.kernel.org/lkml/20210121122723.3446-11-rppt@kernel.org/#t [3]: https://lore.kernel.org/lkml/20201125092208.12544-10-rppt@kernel.org/", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50019", "url": "https://ubuntu.com/security/CVE-2024-50019", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: kthread: unpark only parked kthread Calling into kthread unparking unconditionally is mostly harmless when the kthread is already unparked. The wake up is then simply ignored because the target is not in TASK_PARKED state. However if the kthread is per CPU, the wake up is preceded by a call to kthread_bind() which expects the task to be inactive and in TASK_PARKED state, which obviously isn't the case if it is unparked. As a result, calling kthread_stop() on an unparked per-cpu kthread triggers such a warning: \tWARNING: CPU: 0 PID: 11 at kernel/kthread.c:525 __kthread_bind_mask kernel/kthread.c:525 \t \t kthread_stop+0x17a/0x630 kernel/kthread.c:707 \t destroy_workqueue+0x136/0xc40 kernel/workqueue.c:5810 \t wg_destruct+0x1e2/0x2e0 drivers/net/wireguard/device.c:257 \t netdev_run_todo+0xe1a/0x1000 net/core/dev.c:10693 \t default_device_exit_batch+0xa14/0xa90 net/core/dev.c:11769 \t ops_exit_list net/core/net_namespace.c:178 [inline] \t cleanup_net+0x89d/0xcc0 net/core/net_namespace.c:640 \t process_one_work kernel/workqueue.c:3231 [inline] \t process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 \t worker_thread+0x86d/0xd70 kernel/workqueue.c:3393 \t kthread+0x2f0/0x390 kernel/kthread.c:389 \t ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 \t ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 \t Fix this with skipping unecessary unparking while stopping a kthread.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50096", "url": "https://ubuntu.com/security/CVE-2024-50096", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nouveau/dmem: Fix vulnerability in migrate_to_ram upon copy error The `nouveau_dmem_copy_one` function ensures that the copy push command is sent to the device firmware but does not track whether it was executed successfully. In the case of a copy error (e.g., firmware or hardware failure), the copy push command will be sent via the firmware channel, and `nouveau_dmem_copy_one` will likely report success, leading to the `migrate_to_ram` function returning a dirty HIGH_USER page to the user. This can result in a security vulnerability, as a HIGH_USER page that may contain sensitive or corrupted data could be returned to the user. To prevent this vulnerability, we allocate a zero page. Thus, in case of an error, a non-dirty (zero) page will be returned to the user.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50020", "url": "https://ubuntu.com/security/CVE-2024-50020", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix improper handling of refcount in ice_sriov_set_msix_vec_count() This patch addresses an issue with improper reference count handling in the ice_sriov_set_msix_vec_count() function. First, the function calls ice_get_vf_by_id(), which increments the reference count of the vf pointer. If the subsequent call to ice_get_vf_vsi() fails, the function currently returns an error without decrementing the reference count of the vf pointer, leading to a reference count leak. The correct behavior, as implemented in this patch, is to decrement the reference count using ice_put_vf(vf) before returning an error when vsi is NULL. Second, the function calls ice_sriov_get_irqs(), which sets vf->first_vector_idx. If this call returns a negative value, indicating an error, the function returns an error without decrementing the reference count of the vf pointer, resulting in another reference count leak. The patch addresses this by adding a call to ice_put_vf(vf) before returning an error when vf->first_vector_idx < 0. This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and identifying potential mismanagement of reference counts. In this case, the tool flagged the missing decrement operation as a potential issue, leading to this patch.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50021", "url": "https://ubuntu.com/security/CVE-2024-50021", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix improper handling of refcount in ice_dpll_init_rclk_pins() This patch addresses a reference count handling issue in the ice_dpll_init_rclk_pins() function. The function calls ice_dpll_get_pins(), which increments the reference count of the relevant resources. However, if the condition WARN_ON((!vsi || !vsi->netdev)) is met, the function currently returns an error without properly releasing the resources acquired by ice_dpll_get_pins(), leading to a reference count leak. To resolve this, the check has been moved to the top of the function. This ensures that the function verifies the state before any resources are acquired, avoiding the need for additional resource management in the error path. This bug was identified by an experimental static analysis tool developed by our team. The tool specializes in analyzing reference count operations and detecting potential issues where resources are not properly managed. In this case, the tool flagged the missing release operation as a potential problem, which led to the development of this patch.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50022", "url": "https://ubuntu.com/security/CVE-2024-50022", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: device-dax: correct pgoff align in dax_set_mapping() pgoff should be aligned using ALIGN_DOWN() instead of ALIGN(). Otherwise, vmf->address not aligned to fault_size will be aligned to the next alignment, that can result in memory failure getting the wrong address. It's a subtle situation that only can be observed in page_mapped_in_vma() after the page is page fault handled by dev_dax_huge_fault. Generally, there is little chance to perform page_mapped_in_vma in dev-dax's page unless in specific error injection to the dax device to trigger an MCE - memory-failure. In that case, page_mapped_in_vma() will be triggered to determine which task is accessing the failure address and kill that task in the end. We used self-developed dax device (which is 2M aligned mapping) , to perform error injection to random address. It turned out that error injected to non-2M-aligned address was causing endless MCE until panic. Because page_mapped_in_vma() kept resulting wrong address and the task accessing the failure address was never killed properly: [ 3783.719419] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.049006] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.049190] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.448042] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.448186] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3784.792026] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3784.792179] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.162502] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.162633] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.461116] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.461247] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3785.764730] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3785.764859] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.042128] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.042259] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.464293] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.464423] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3786.818090] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3786.818217] Memory failure: 0x200c9742: recovery action for dax page: Recovered [ 3787.085297] mce: Uncorrected hardware memory error in user-access at 200c9742380 [ 3787.085424] Memory failure: 0x200c9742: recovery action for dax page: Recovered It took us several weeks to pinpoint this problem,  but we eventually used bpftrace to trace the page fault and mce address and successfully identified the issue. Joao added: ; Likely we never reproduce in production because we always pin : device-dax regions in the region align they provide (Qemu does : similarly with prealloc in hugetlb/file backed memory). I think this : bug requires that we touch *unpinned* device-dax regions unaligned to : the device-dax selected alignment (page size i.e. 4K/2M/1G)", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50185", "url": "https://ubuntu.com/security/CVE-2024-50185", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mptcp: handle consistently DSS corruption Bugged peer implementation can send corrupted DSS options, consistently hitting a few warning in the data path. Use DEBUG_NET assertions, to avoid the splat on some builds and handle consistently the error, dumping related MIBs and performing fallback and/or reset according to the subflow type.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50023", "url": "https://ubuntu.com/security/CVE-2024-50023", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: Remove LED entry from LEDs list on unregister Commit c938ab4da0eb (\"net: phy: Manual remove LEDs to ensure correct ordering\") correctly fixed a problem with using devm_ but missed removing the LED entry from the LEDs list. This cause kernel panic on specific scenario where the port for the PHY is torn down and up and the kmod for the PHY is removed. On setting the port down the first time, the assosiacted LEDs are correctly unregistered. The associated kmod for the PHY is now removed. The kmod is now added again and the port is now put up, the associated LED are registered again. On putting the port down again for the second time after these step, the LED list now have 4 elements. With the first 2 already unregistered previously and the 2 new one registered again. This cause a kernel panic as the first 2 element should have been removed. Fix this by correctly removing the element when LED is unregistered.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50024", "url": "https://ubuntu.com/security/CVE-2024-50024", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: Fix an unsafe loop on the list The kernel may crash when deleting a genetlink family if there are still listeners for that family: Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c000000000c080bc] netlink_update_socket_mc+0x3c/0xc0 LR [c000000000c0f764] __netlink_clear_multicast_users+0x74/0xc0 Call Trace: __netlink_clear_multicast_users+0x74/0xc0 genl_unregister_family+0xd4/0x2d0 Change the unsafe loop on the list to a safe one, because inside the loop there is an element removal from this list.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50186", "url": "https://ubuntu.com/security/CVE-2024-50186", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: explicitly clear the sk pointer, when pf->create fails We have recently noticed the exact same KASAN splat as in commit 6cd4a78d962b (\"net: do not leave a dangling sk pointer, when socket creation fails\"). The problem is that commit did not fully address the problem, as some pf->create implementations do not use sk_common_release in their error paths. For example, we can use the same reproducer as in the above commit, but changing ping to arping. arping uses AF_PACKET socket and if packet_create fails, it will just sk_free the allocated sk object. While we could chase all the pf->create implementations and make sure they NULL the freed sk object on error from the socket, we can't guarantee future protocols will not make the same mistake. So it is easier to just explicitly NULL the sk pointer upon return from pf->create in __sock_create. We do know that pf->create always releases the allocated sk object on error, so if the pointer is not NULL, it is definitely dangling.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50025", "url": "https://ubuntu.com/security/CVE-2024-50025", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: fnic: Move flush_work initialization out of if block After commit 379a58caa199 (\"scsi: fnic: Move fnic_fnic_flush_tx() to a work queue\"), it can happen that a work item is sent to an uninitialized work queue. This may has the effect that the item being queued is never actually queued, and any further actions depending on it will not proceed. The following warning is observed while the fnic driver is loaded: kernel: WARNING: CPU: 11 PID: 0 at ../kernel/workqueue.c:1524 __queue_work+0x373/0x410 kernel: kernel: queue_work_on+0x3a/0x50 kernel: fnic_wq_copy_cmpl_handler+0x54a/0x730 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: fnic_isr_msix_wq_copy+0x2d/0x60 [fnic 62fbff0c42e7fb825c60a55cde2fb91facb2ed24] kernel: __handle_irq_event_percpu+0x36/0x1a0 kernel: handle_irq_event_percpu+0x30/0x70 kernel: handle_irq_event+0x34/0x60 kernel: handle_edge_irq+0x7e/0x1a0 kernel: __common_interrupt+0x3b/0xb0 kernel: common_interrupt+0x58/0xa0 kernel: It has been observed that this may break the rediscovery of Fibre Channel devices after a temporary fabric failure. This patch fixes it by moving the work queue initialization out of an if block in fnic_probe().", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50026", "url": "https://ubuntu.com/security/CVE-2024-50026", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: wd33c93: Don't use stale scsi_pointer value A regression was introduced with commit dbb2da557a6a (\"scsi: wd33c93: Move the SCSI pointer to private command data\") which results in an oops in wd33c93_intr(). That commit added the scsi_pointer variable and initialized it from hostdata->connected. However, during selection, hostdata->connected is not yet valid. Fix this by getting the current scsi_pointer from hostdata->selecting.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50027", "url": "https://ubuntu.com/security/CVE-2024-50027", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: core: Free tzp copy along with the thermal zone The object pointed to by tz->tzp may still be accessed after being freed in thermal_zone_device_unregister(), so move the freeing of it to the point after the removal completion has been completed at which it cannot be accessed any more.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50028", "url": "https://ubuntu.com/security/CVE-2024-50028", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: core: Reference count the zone in thermal_zone_get_by_id() There are places in the thermal netlink code where nothing prevents the thermal zone object from going away while being accessed after it has been returned by thermal_zone_get_by_id(). To address this, make thermal_zone_get_by_id() get a reference on the thermal zone device object to be returned with the help of get_device(), under thermal_list_lock, and adjust all of its callers to this change with the help of the cleanup.h infrastructure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50029", "url": "https://ubuntu.com/security/CVE-2024-50029", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_conn: Fix UAF in hci_enhanced_setup_sync This checks if the ACL connection remains valid as it could be destroyed while hci_enhanced_setup_sync is pending on cmd_sync leading to the following trace: BUG: KASAN: slab-use-after-free in hci_enhanced_setup_sync+0x91b/0xa60 Read of size 1 at addr ffff888002328ffd by task kworker/u5:2/37 CPU: 0 UID: 0 PID: 37 Comm: kworker/u5:2 Not tainted 6.11.0-rc6-01300-g810be445d8d6 #7099 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Workqueue: hci0 hci_cmd_sync_work Call Trace: dump_stack_lvl+0x5d/0x80 ? hci_enhanced_setup_sync+0x91b/0xa60 print_report+0x152/0x4c0 ? hci_enhanced_setup_sync+0x91b/0xa60 ? __virt_addr_valid+0x1fa/0x420 ? hci_enhanced_setup_sync+0x91b/0xa60 kasan_report+0xda/0x1b0 ? hci_enhanced_setup_sync+0x91b/0xa60 hci_enhanced_setup_sync+0x91b/0xa60 ? __pfx_hci_enhanced_setup_sync+0x10/0x10 ? __pfx___mutex_lock+0x10/0x10 hci_cmd_sync_work+0x1c2/0x330 process_one_work+0x7d9/0x1360 ? __pfx_lock_acquire+0x10/0x10 ? __pfx_process_one_work+0x10/0x10 ? assign_work+0x167/0x240 worker_thread+0x5b7/0xf60 ? __kthread_parkme+0xac/0x1c0 ? __pfx_worker_thread+0x10/0x10 ? __pfx_worker_thread+0x10/0x10 kthread+0x293/0x360 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2f/0x70 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 Allocated by task 34: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x8f/0xa0 __hci_conn_add+0x187/0x17d0 hci_connect_sco+0x2e1/0xb90 sco_sock_connect+0x2a2/0xb80 __sys_connect+0x227/0x2a0 __x64_sys_connect+0x6d/0xb0 do_syscall_64+0x71/0x140 entry_SYSCALL_64_after_hwframe+0x76/0x7e Freed by task 37: kasan_save_stack+0x30/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3b/0x60 __kasan_slab_free+0x101/0x160 kfree+0xd0/0x250 device_release+0x9a/0x210 kobject_put+0x151/0x280 hci_conn_del+0x448/0xbf0 hci_abort_conn_sync+0x46f/0x980 hci_cmd_sync_work+0x1c2/0x330 process_one_work+0x7d9/0x1360 worker_thread+0x5b7/0xf60 kthread+0x293/0x360 ret_from_fork+0x2f/0x70 ret_from_fork_asm+0x1a/0x30", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50030", "url": "https://ubuntu.com/security/CVE-2024-50030", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/ct: prevent UAF in send_recv() Ensure we serialize with completion side to prevent UAF with fence going out of scope on the stack, since we have no clue if it will fire after the timeout before we can erase from the xa. Also we have some dependent loads and stores for which we need the correct ordering, and we lack the needed barriers. Fix this by grabbing the ct->lock after the wait, which is also held by the completion side. v2 (Badal): - Also print done after acquiring the lock and seeing timeout. (cherry picked from commit 52789ce35c55ccd30c4b67b9cc5b2af55e0122ea)", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50187", "url": "https://ubuntu.com/security/CVE-2024-50187", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/vc4: Stop the active perfmon before being destroyed Upon closing the file descriptor, the active performance monitor is not stopped. Although all perfmons are destroyed in `vc4_perfmon_close_file()`, the active performance monitor's pointer (`vc4->active_perfmon`) is still retained. If we open a new file descriptor and submit a few jobs with performance monitors, the driver will attempt to stop the active performance monitor using the stale pointer in `vc4->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50031", "url": "https://ubuntu.com/security/CVE-2024-50031", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/v3d: Stop the active perfmon before being destroyed When running `kmscube` with one or more performance monitors enabled via `GALLIUM_HUD`, the following kernel panic can occur: [ 55.008324] Unable to handle kernel paging request at virtual address 00000000052004a4 [ 55.008368] Mem abort info: [ 55.008377] ESR = 0x0000000096000005 [ 55.008387] EC = 0x25: DABT (current EL), IL = 32 bits [ 55.008402] SET = 0, FnV = 0 [ 55.008412] EA = 0, S1PTW = 0 [ 55.008421] FSC = 0x05: level 1 translation fault [ 55.008434] Data abort info: [ 55.008442] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 [ 55.008455] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 55.008467] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 55.008481] user pgtable: 4k pages, 39-bit VAs, pgdp=00000001046c6000 [ 55.008497] [00000000052004a4] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 55.008525] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP [ 55.008542] Modules linked in: rfcomm [...] vc4 v3d snd_soc_hdmi_codec drm_display_helper gpu_sched drm_shmem_helper cec drm_dma_helper drm_kms_helper i2c_brcmstb drm drm_panel_orientation_quirks snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd backlight [ 55.008799] CPU: 2 PID: 166 Comm: v3d_bin Tainted: G C 6.6.47+rpt-rpi-v8 #1 Debian 1:6.6.47-1+rpt1 [ 55.008824] Hardware name: Raspberry Pi 4 Model B Rev 1.5 (DT) [ 55.008838] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 55.008855] pc : __mutex_lock.constprop.0+0x90/0x608 [ 55.008879] lr : __mutex_lock.constprop.0+0x58/0x608 [ 55.008895] sp : ffffffc080673cf0 [ 55.008904] x29: ffffffc080673cf0 x28: 0000000000000000 x27: ffffff8106188a28 [ 55.008926] x26: ffffff8101e78040 x25: ffffff8101baa6c0 x24: ffffffd9d989f148 [ 55.008947] x23: ffffffda1c2a4008 x22: 0000000000000002 x21: ffffffc080673d38 [ 55.008968] x20: ffffff8101238000 x19: ffffff8104f83188 x18: 0000000000000000 [ 55.008988] x17: 0000000000000000 x16: ffffffda1bd04d18 x15: 00000055bb08bc90 [ 55.009715] x14: 0000000000000000 x13: 0000000000000000 x12: ffffffda1bd4cbb0 [ 55.010433] x11: 00000000fa83b2da x10: 0000000000001a40 x9 : ffffffda1bd04d04 [ 55.011162] x8 : ffffff8102097b80 x7 : 0000000000000000 x6 : 00000000030a5857 [ 55.011880] x5 : 00ffffffffffffff x4 : 0300000005200470 x3 : 0300000005200470 [ 55.012598] x2 : ffffff8101238000 x1 : 0000000000000021 x0 : 0300000005200470 [ 55.013292] Call trace: [ 55.013959] __mutex_lock.constprop.0+0x90/0x608 [ 55.014646] __mutex_lock_slowpath+0x1c/0x30 [ 55.015317] mutex_lock+0x50/0x68 [ 55.015961] v3d_perfmon_stop+0x40/0xe0 [v3d] [ 55.016627] v3d_bin_job_run+0x10c/0x2d8 [v3d] [ 55.017282] drm_sched_main+0x178/0x3f8 [gpu_sched] [ 55.017921] kthread+0x11c/0x128 [ 55.018554] ret_from_fork+0x10/0x20 [ 55.019168] Code: f9400260 f1001c1f 54001ea9 927df000 (b9403401) [ 55.019776] ---[ end trace 0000000000000000 ]--- [ 55.020411] note: v3d_bin[166] exited with preempt_count 1 This issue arises because, upon closing the file descriptor (which happens when we interrupt `kmscube`), the active performance monitor is not stopped. Although all perfmons are destroyed in `v3d_perfmon_close_file()`, the active performance monitor's pointer (`v3d->active_perfmon`) is still retained. If `kmscube` is run again, the driver will attempt to stop the active performance monitor using the stale pointer in `v3d->active_perfmon`. However, this pointer is no longer valid because the previous process has already terminated, and all performance monitors associated with it have been destroyed and freed. To fix this, when the active performance monitor belongs to a given process, explicitly stop it before destroying and freeing it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50189", "url": "https://ubuntu.com/security/CVE-2024-50189", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: HID: amd_sfh: Switch to device-managed dmam_alloc_coherent() Using the device-managed version allows to simplify clean-up in probe() error path. Additionally, this device-managed ensures proper cleanup, which helps to resolve memory errors, page faults, btrfs going read-only, and btrfs disk corruption.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50033", "url": "https://ubuntu.com/security/CVE-2024-50033", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: slip: make slhc_remember() more robust against malicious packets syzbot found that slhc_remember() was missing checks against malicious packets [1]. slhc_remember() only checked the size of the packet was at least 20, which is not good enough. We need to make sure the packet includes the IPv4 and TCP header that are supposed to be carried. Add iph and th pointers to make the code more readable. [1] BUG: KMSAN: uninit-value in slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666 ppp_receive_nonmp_frame+0xe45/0x35e0 drivers/net/ppp/ppp_generic.c:2455 ppp_receive_frame drivers/net/ppp/ppp_generic.c:2372 [inline] ppp_do_recv+0x65f/0x40d0 drivers/net/ppp/ppp_generic.c:2212 ppp_input+0x7dc/0xe60 drivers/net/ppp/ppp_generic.c:2327 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 Uninit was created at: slab_post_alloc_hook mm/slub.c:4091 [inline] slab_alloc_node mm/slub.c:4134 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 CPU: 0 UID: 0 PID: 5460 Comm: syz.2.33 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50034", "url": "https://ubuntu.com/security/CVE-2024-50034", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/smc: fix lacks of icsk_syn_mss with IPPROTO_SMC Eric report a panic on IPPROTO_SMC, and give the facts that when INET_PROTOSW_ICSK was set, icsk->icsk_sync_mss must be set too. Bug: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000086000005 EC = 0x21: IABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault user pgtable: 4k pages, 48-bit VAs, pgdp=00000001195d1000 [0000000000000000] pgd=0800000109c46003, p4d=0800000109c46003, pud=0000000000000000 Internal error: Oops: 0000000086000005 [#1] PREEMPT SMP Modules linked in: CPU: 1 UID: 0 PID: 8037 Comm: syz.3.265 Not tainted 6.11.0-rc7-syzkaller-g5f5673607153 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : 0x0 lr : cipso_v4_sock_setattr+0x2a8/0x3c0 net/ipv4/cipso_ipv4.c:1910 sp : ffff80009b887a90 x29: ffff80009b887aa0 x28: ffff80008db94050 x27: 0000000000000000 x26: 1fffe0001aa6f5b3 x25: dfff800000000000 x24: ffff0000db75da00 x23: 0000000000000000 x22: ffff0000d8b78518 x21: 0000000000000000 x20: ffff0000d537ad80 x19: ffff0000d8b78000 x18: 1fffe000366d79ee x17: ffff8000800614a8 x16: ffff800080569b84 x15: 0000000000000001 x14: 000000008b336894 x13: 00000000cd96feaa x12: 0000000000000003 x11: 0000000000040000 x10: 00000000000020a3 x9 : 1fffe0001b16f0f1 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 000000000000003f x5 : 0000000000000040 x4 : 0000000000000001 x3 : 0000000000000000 x2 : 0000000000000002 x1 : 0000000000000000 x0 : ffff0000d8b78000 Call trace: 0x0 netlbl_sock_setattr+0x2e4/0x338 net/netlabel/netlabel_kapi.c:1000 smack_netlbl_add+0xa4/0x154 security/smack/smack_lsm.c:2593 smack_socket_post_create+0xa8/0x14c security/smack/smack_lsm.c:2973 security_socket_post_create+0x94/0xd4 security/security.c:4425 __sock_create+0x4c8/0x884 net/socket.c:1587 sock_create net/socket.c:1622 [inline] __sys_socket_create net/socket.c:1659 [inline] __sys_socket+0x134/0x340 net/socket.c:1706 __do_sys_socket net/socket.c:1720 [inline] __se_sys_socket net/socket.c:1718 [inline] __arm64_sys_socket+0x7c/0x94 net/socket.c:1718 __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:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 Code: ???????? ???????? ???????? ???????? (????????) ---[ end trace 0000000000000000 ]--- This patch add a toy implementation that performs a simple return to prevent such panic. This is because MSS can be set in sock_create_kern or smc_setsockopt, similar to how it's done in AF_SMC. However, for AF_SMC, there is currently no way to synchronize MSS within __sys_connect_file. This toy implementation lays the groundwork for us to support such feature for IPPROTO_SMC in the future.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50035", "url": "https://ubuntu.com/security/CVE-2024-50035", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: fix ppp_async_encode() illegal access syzbot reported an issue in ppp_async_encode() [1] In this case, pppoe_sendmsg() is called with a zero size. Then ppp_async_encode() is called with an empty skb. BUG: KMSAN: uninit-value in ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] BUG: KMSAN: uninit-value in ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline] ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675 ppp_async_send+0x130/0x1b0 drivers/net/ppp/ppp_async.c:634 ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2280 [inline] ppp_input+0x1f1/0xe60 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113 __release_sock+0x1da/0x330 net/core/sock.c:3072 release_sock+0x6b/0x250 net/core/sock.c:3626 pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 Uninit was created at: slab_post_alloc_hook mm/slub.c:4092 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4187 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587 __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678 alloc_skb include/linux/skbuff.h:1322 [inline] sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732 pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867 sock_sendmsg_nosec net/socket.c:729 [inline] __sock_sendmsg+0x30f/0x380 net/socket.c:744 ____sys_sendmsg+0x903/0xb60 net/socket.c:2602 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656 __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742 __do_sys_sendmmsg net/socket.c:2771 [inline] __se_sys_sendmmsg net/socket.c:2768 [inline] __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768 x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308 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 CPU: 1 UID: 0 PID: 5411 Comm: syz.1.14 Not tainted 6.12.0-rc1-syzkaller-00165-g360c1f1f24c6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50036", "url": "https://ubuntu.com/security/CVE-2024-50036", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: do not delay dst_entries_add() in dst_release() dst_entries_add() uses per-cpu data that might be freed at netns dismantle from ip6_route_net_exit() calling dst_entries_destroy() Before ip6_route_net_exit() can be called, we release all the dsts associated with this netns, via calls to dst_release(), which waits an rcu grace period before calling dst_destroy() dst_entries_add() use in dst_destroy() is racy, because dst_entries_destroy() could have been called already. Decrementing the number of dsts must happen sooner. Notes: 1) in CONFIG_XFRM case, dst_destroy() can call dst_release_immediate(child), this might also cause UAF if the child does not have DST_NOCOUNT set. IPSEC maintainers might take a look and see how to address this. 2) There is also discussion about removing this count of dst, which might happen in future kernels.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50037", "url": "https://ubuntu.com/security/CVE-2024-50037", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/fbdev-dma: Only cleanup deferred I/O if necessary Commit 5a498d4d06d6 (\"drm/fbdev-dma: Only install deferred I/O if necessary\") initializes deferred I/O only if it is used. drm_fbdev_dma_fb_destroy() however calls fb_deferred_io_cleanup() unconditionally with struct fb_info.fbdefio == NULL. KASAN with the out-of-tree Apple silicon display driver posts following warning from __flush_work() of a random struct work_struct instead of the expected NULL pointer derefs. [ 22.053799] ------------[ cut here ]------------ [ 22.054832] WARNING: CPU: 2 PID: 1 at kernel/workqueue.c:4177 __flush_work+0x4d8/0x580 [ 22.056597] Modules linked in: uhid bnep uinput nls_ascii ip6_tables ip_tables i2c_dev loop fuse dm_multipath nfnetlink zram hid_magicmouse btrfs xor xor_neon brcmfmac_wcc raid6_pq hci_bcm4377 bluetooth brcmfmac hid_apple brcmutil nvmem_spmi_mfd simple_mfd_spmi dockchannel_hid cfg80211 joydev regmap_spmi nvme_apple ecdh_generic ecc macsmc_hid rfkill dwc3 appledrm snd_soc_macaudio macsmc_power nvme_core apple_isp phy_apple_atc apple_sart apple_rtkit_helper apple_dockchannel tps6598x macsmc_hwmon snd_soc_cs42l84 videobuf2_v4l2 spmi_apple_controller nvmem_apple_efuses videobuf2_dma_sg apple_z2 videobuf2_memops spi_nor panel_summit videobuf2_common asahi videodev pwm_apple apple_dcp snd_soc_apple_mca apple_admac spi_apple clk_apple_nco i2c_pasemi_platform snd_pcm_dmaengine mc i2c_pasemi_core mux_core ofpart adpdrm drm_dma_helper apple_dart apple_soc_cpufreq leds_pwm phram [ 22.073768] CPU: 2 UID: 0 PID: 1 Comm: systemd-shutdow Not tainted 6.11.2-asahi+ #asahi-dev [ 22.075612] Hardware name: Apple MacBook Pro (13-inch, M2, 2022) (DT) [ 22.077032] pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 22.078567] pc : __flush_work+0x4d8/0x580 [ 22.079471] lr : __flush_work+0x54/0x580 [ 22.080345] sp : ffffc000836ef820 [ 22.081089] x29: ffffc000836ef880 x28: 0000000000000000 x27: ffff80002ddb7128 [ 22.082678] x26: dfffc00000000000 x25: 1ffff000096f0c57 x24: ffffc00082d3e358 [ 22.084263] x23: ffff80004b7862b8 x22: dfffc00000000000 x21: ffff80005aa1d470 [ 22.085855] x20: ffff80004b786000 x19: ffff80004b7862a0 x18: 0000000000000000 [ 22.087439] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000005 [ 22.089030] x14: 1ffff800106ddf0a x13: 0000000000000000 x12: 0000000000000000 [ 22.090618] x11: ffffb800106ddf0f x10: dfffc00000000000 x9 : 1ffff800106ddf0e [ 22.092206] x8 : 0000000000000000 x7 : aaaaaaaaaaaaaaaa x6 : 0000000000000001 [ 22.093790] x5 : ffffc000836ef728 x4 : 0000000000000000 x3 : 0000000000000020 [ 22.095368] x2 : 0000000000000008 x1 : 00000000000000aa x0 : 0000000000000000 [ 22.096955] Call trace: [ 22.097505] __flush_work+0x4d8/0x580 [ 22.098330] flush_delayed_work+0x80/0xb8 [ 22.099231] fb_deferred_io_cleanup+0x3c/0x130 [ 22.100217] drm_fbdev_dma_fb_destroy+0x6c/0xe0 [drm_dma_helper] [ 22.101559] unregister_framebuffer+0x210/0x2f0 [ 22.102575] drm_fb_helper_unregister_info+0x48/0x60 [ 22.103683] drm_fbdev_dma_client_unregister+0x4c/0x80 [drm_dma_helper] [ 22.105147] drm_client_dev_unregister+0x1cc/0x230 [ 22.106217] drm_dev_unregister+0x58/0x570 [ 22.107125] apple_drm_unbind+0x50/0x98 [appledrm] [ 22.108199] component_del+0x1f8/0x3a8 [ 22.109042] dcp_platform_shutdown+0x24/0x38 [apple_dcp] [ 22.110357] platform_shutdown+0x70/0x90 [ 22.111219] device_shutdown+0x368/0x4d8 [ 22.112095] kernel_restart+0x6c/0x1d0 [ 22.112946] __arm64_sys_reboot+0x1c8/0x328 [ 22.113868] invoke_syscall+0x78/0x1a8 [ 22.114703] do_el0_svc+0x124/0x1a0 [ 22.115498] el0_svc+0x3c/0xe0 [ 22.116181] el0t_64_sync_handler+0x70/0xc0 [ 22.117110] el0t_64_sync+0x190/0x198 [ 22.117931] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50092", "url": "https://ubuntu.com/security/CVE-2024-50092", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: netconsole: fix wrong warning A warning is triggered when there is insufficient space in the buffer for userdata. However, this is not an issue since userdata will be sent in the next iteration. Current warning message: ------------[ cut here ]------------ WARNING: CPU: 13 PID: 3013042 at drivers/net/netconsole.c:1122 write_ext_msg+0x3b6/0x3d0 ? write_ext_msg+0x3b6/0x3d0 console_flush_all+0x1e9/0x330 The code incorrectly issues a warning when this_chunk is zero, which is a valid scenario. The warning should only be triggered when this_chunk is negative.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50038", "url": "https://ubuntu.com/security/CVE-2024-50038", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: xtables: avoid NFPROTO_UNSPEC where needed syzbot managed to call xt_cluster match via ebtables: WARNING: CPU: 0 PID: 11 at net/netfilter/xt_cluster.c:72 xt_cluster_mt+0x196/0x780 [..] ebt_do_table+0x174b/0x2a40 Module registers to NFPROTO_UNSPEC, but it assumes ipv4/ipv6 packet processing. As this is only useful to restrict locally terminating TCP/UDP traffic, register this for ipv4 and ipv6 family only. Pablo points out that this is a general issue, direct users of the set/getsockopt interface can call into targets/matches that were only intended for use with ip(6)tables. Check all UNSPEC matches and targets for similar issues: - matches and targets are fine except if they assume skb_network_header() is valid -- this is only true when called from inet layer: ip(6) stack pulls the ip/ipv6 header into linear data area. - targets that return XT_CONTINUE or other xtables verdicts must be restricted too, they are incompatbile with the ebtables traverser, e.g. EBT_CONTINUE is a completely different value than XT_CONTINUE. Most matches/targets are changed to register for NFPROTO_IPV4/IPV6, as they are provided for use by ip(6)tables. The MARK target is also used by arptables, so register for NFPROTO_ARP too. While at it, bail out if connbytes fails to enable the corresponding conntrack family. This change passes the selftests in iptables.git.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50039", "url": "https://ubuntu.com/security/CVE-2024-50039", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/sched: accept TCA_STAB only for root qdisc Most qdiscs maintain their backlog using qdisc_pkt_len(skb) on the assumption it is invariant between the enqueue() and dequeue() handlers. Unfortunately syzbot can crash a host rather easily using a TBF + SFQ combination, with an STAB on SFQ [1] We can't support TCA_STAB on arbitrary level, this would require to maintain per-qdisc storage. [1] [ 88.796496] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 88.798611] #PF: supervisor read access in kernel mode [ 88.799014] #PF: error_code(0x0000) - not-present page [ 88.799506] PGD 0 P4D 0 [ 88.799829] Oops: Oops: 0000 [#1] SMP NOPTI [ 88.800569] CPU: 14 UID: 0 PID: 2053 Comm: b371744477 Not tainted 6.12.0-rc1-virtme #1117 [ 88.801107] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 88.801779] RIP: 0010:sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq [ 88.802544] Code: 0f b7 50 12 48 8d 04 d5 00 00 00 00 48 89 d6 48 29 d0 48 8b 91 c0 01 00 00 48 c1 e0 03 48 01 c2 66 83 7a 1a 00 7e c0 48 8b 3a <4c> 8b 07 4c 89 02 49 89 50 08 48 c7 47 08 00 00 00 00 48 c7 07 00 All code ======== 0:\t0f b7 50 12 \tmovzwl 0x12(%rax),%edx 4:\t48 8d 04 d5 00 00 00 \tlea 0x0(,%rdx,8),%rax b:\t00 c:\t48 89 d6 \tmov %rdx,%rsi f:\t48 29 d0 \tsub %rdx,%rax 12:\t48 8b 91 c0 01 00 00 \tmov 0x1c0(%rcx),%rdx 19:\t48 c1 e0 03 \tshl $0x3,%rax 1d:\t48 01 c2 \tadd %rax,%rdx 20:\t66 83 7a 1a 00 \tcmpw $0x0,0x1a(%rdx) 25:\t7e c0 \tjle 0xffffffffffffffe7 27:\t48 8b 3a \tmov (%rdx),%rdi 2a:*\t4c 8b 07 \tmov (%rdi),%r8\t\t<-- trapping instruction 2d:\t4c 89 02 \tmov %r8,(%rdx) 30:\t49 89 50 08 \tmov %rdx,0x8(%r8) 34:\t48 c7 47 08 00 00 00 \tmovq $0x0,0x8(%rdi) 3b:\t00 3c:\t48 \trex.W 3d:\tc7 \t.byte 0xc7 3e:\t07 \t(bad) \t... Code starting with the faulting instruction =========================================== 0:\t4c 8b 07 \tmov (%rdi),%r8 3:\t4c 89 02 \tmov %r8,(%rdx) 6:\t49 89 50 08 \tmov %rdx,0x8(%r8) a:\t48 c7 47 08 00 00 00 \tmovq $0x0,0x8(%rdi) 11:\t00 12:\t48 \trex.W 13:\tc7 \t.byte 0xc7 14:\t07 \t(bad) \t... [ 88.803721] RSP: 0018:ffff9a1f892b7d58 EFLAGS: 00000206 [ 88.804032] RAX: 0000000000000000 RBX: ffff9a1f8420c800 RCX: ffff9a1f8420c800 [ 88.804560] RDX: ffff9a1f81bc1440 RSI: 0000000000000000 RDI: 0000000000000000 [ 88.805056] RBP: ffffffffc04bb0e0 R08: 0000000000000001 R09: 00000000ff7f9a1f [ 88.805473] R10: 000000000001001b R11: 0000000000009a1f R12: 0000000000000140 [ 88.806194] R13: 0000000000000001 R14: ffff9a1f886df400 R15: ffff9a1f886df4ac [ 88.806734] FS: 00007f445601a740(0000) GS:ffff9a2e7fd80000(0000) knlGS:0000000000000000 [ 88.807225] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 88.807672] CR2: 0000000000000000 CR3: 000000050cc46000 CR4: 00000000000006f0 [ 88.808165] Call Trace: [ 88.808459] [ 88.808710] ? __die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434) [ 88.809261] ? page_fault_oops (arch/x86/mm/fault.c:715) [ 88.809561] ? exc_page_fault (./arch/x86/include/asm/irqflags.h:26 ./arch/x86/include/asm/irqflags.h:87 ./arch/x86/include/asm/irqflags.h:147 arch/x86/mm/fault.c:1489 arch/x86/mm/fault.c:1539) [ 88.809806] ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:623) [ 88.810074] ? sfq_dequeue (net/sched/sch_sfq.c:272 net/sched/sch_sfq.c:499) sch_sfq [ 88.810411] sfq_reset (net/sched/sch_sfq.c:525) sch_sfq [ 88.810671] qdisc_reset (./include/linux/skbuff.h:2135 ./include/linux/skbuff.h:2441 ./include/linux/skbuff.h:3304 ./include/linux/skbuff.h:3310 net/sched/sch_g ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50040", "url": "https://ubuntu.com/security/CVE-2024-50040", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: igb: Do not bring the device up after non-fatal error Commit 004d25060c78 (\"igb: Fix igb_down hung on surprise removal\") changed igb_io_error_detected() to ignore non-fatal pcie errors in order to avoid hung task that can happen when igb_down() is called multiple times. This caused an issue when processing transient non-fatal errors. igb_io_resume(), which is called after igb_io_error_detected(), assumes that device is brought down by igb_io_error_detected() if the interface is up. This resulted in panic with stacktrace below. [ T3256] igb 0000:09:00.0 haeth0: igb: haeth0 NIC Link is Down [ T292] pcieport 0000:00:1c.5: AER: Uncorrected (Non-Fatal) error received: 0000:09:00.0 [ T292] igb 0000:09:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, (Requester ID) [ T292] igb 0000:09:00.0: device [8086:1537] error status/mask=00004000/00000000 [ T292] igb 0000:09:00.0: [14] CmpltTO [ 200.105524,009][ T292] igb 0000:09:00.0: AER: TLP Header: 00000000 00000000 00000000 00000000 [ T292] pcieport 0000:00:1c.5: AER: broadcast error_detected message [ T292] igb 0000:09:00.0: Non-correctable non-fatal error reported. [ T292] pcieport 0000:00:1c.5: AER: broadcast mmio_enabled message [ T292] pcieport 0000:00:1c.5: AER: broadcast resume message [ T292] ------------[ cut here ]------------ [ T292] kernel BUG at net/core/dev.c:6539! [ T292] invalid opcode: 0000 [#1] PREEMPT SMP [ T292] RIP: 0010:napi_enable+0x37/0x40 [ T292] Call Trace: [ T292] [ T292] ? die+0x33/0x90 [ T292] ? do_trap+0xdc/0x110 [ T292] ? napi_enable+0x37/0x40 [ T292] ? do_error_trap+0x70/0xb0 [ T292] ? napi_enable+0x37/0x40 [ T292] ? napi_enable+0x37/0x40 [ T292] ? exc_invalid_op+0x4e/0x70 [ T292] ? napi_enable+0x37/0x40 [ T292] ? asm_exc_invalid_op+0x16/0x20 [ T292] ? napi_enable+0x37/0x40 [ T292] igb_up+0x41/0x150 [ T292] igb_io_resume+0x25/0x70 [ T292] report_resume+0x54/0x70 [ T292] ? report_frozen_detected+0x20/0x20 [ T292] pci_walk_bus+0x6c/0x90 [ T292] ? aer_print_port_info+0xa0/0xa0 [ T292] pcie_do_recovery+0x22f/0x380 [ T292] aer_process_err_devices+0x110/0x160 [ T292] aer_isr+0x1c1/0x1e0 [ T292] ? disable_irq_nosync+0x10/0x10 [ T292] irq_thread_fn+0x1a/0x60 [ T292] irq_thread+0xe3/0x1a0 [ T292] ? irq_set_affinity_notifier+0x120/0x120 [ T292] ? irq_affinity_notify+0x100/0x100 [ T292] kthread+0xe2/0x110 [ T292] ? kthread_complete_and_exit+0x20/0x20 [ T292] ret_from_fork+0x2d/0x50 [ T292] ? kthread_complete_and_exit+0x20/0x20 [ T292] ret_from_fork_asm+0x11/0x20 [ T292] To fix this issue igb_io_resume() checks if the interface is running and the device is not down this means igb_io_error_detected() did not bring the device down and there is no need to bring it up.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50041", "url": "https://ubuntu.com/security/CVE-2024-50041", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i40e: Fix macvlan leak by synchronizing access to mac_filter_hash This patch addresses a macvlan leak issue in the i40e driver caused by concurrent access to vsi->mac_filter_hash. The leak occurs when multiple threads attempt to modify the mac_filter_hash simultaneously, leading to inconsistent state and potential memory leaks. To fix this, we now wrap the calls to i40e_del_mac_filter() and zeroing vf->default_lan_addr.addr with spin_lock/unlock_bh(&vsi->mac_filter_hash_lock), ensuring atomic operations and preventing concurrent access. Additionally, we add lockdep_assert_held(&vsi->mac_filter_hash_lock) in i40e_add_mac_filter() to help catch similar issues in the future. Reproduction steps: 1. Spawn VFs and configure port vlan on them. 2. Trigger concurrent macvlan operations (e.g., adding and deleting \tportvlan and/or mac filters). 3. Observe the potential memory leak and inconsistent state in the \tmac_filter_hash. This synchronization ensures the integrity of the mac_filter_hash and prevents the described leak.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50042", "url": "https://ubuntu.com/security/CVE-2024-50042", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: Fix increasing MSI-X on VF Increasing MSI-X value on a VF leads to invalid memory operations. This is caused by not reallocating some arrays. Reproducer: modprobe ice echo 0 > /sys/bus/pci/devices/$PF_PCI/sriov_drivers_autoprobe echo 1 > /sys/bus/pci/devices/$PF_PCI/sriov_numvfs echo 17 > /sys/bus/pci/devices/$VF0_PCI/sriov_vf_msix_count Default MSI-X is 16, so 17 and above triggers this issue. KASAN reports: BUG: KASAN: slab-out-of-bounds in ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] Read of size 8 at addr ffff8888b937d180 by task bash/28433 (...) Call Trace: (...) ? ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] kasan_report+0xed/0x120 ? ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] ice_vsi_alloc_ring_stats+0x38d/0x4b0 [ice] ice_vsi_cfg_def+0x3360/0x4770 [ice] ? mutex_unlock+0x83/0xd0 ? __pfx_ice_vsi_cfg_def+0x10/0x10 [ice] ? __pfx_ice_remove_vsi_lkup_fltr+0x10/0x10 [ice] ice_vsi_cfg+0x7f/0x3b0 [ice] ice_vf_reconfig_vsi+0x114/0x210 [ice] ice_sriov_set_msix_vec_count+0x3d0/0x960 [ice] sriov_vf_msix_count_store+0x21c/0x300 (...) Allocated by task 28201: (...) ice_vsi_cfg_def+0x1c8e/0x4770 [ice] ice_vsi_cfg+0x7f/0x3b0 [ice] ice_vsi_setup+0x179/0xa30 [ice] ice_sriov_configure+0xcaa/0x1520 [ice] sriov_numvfs_store+0x212/0x390 (...) To fix it, use ice_vsi_rebuild() instead of ice_vf_reconfig_vsi(). This causes the required arrays to be reallocated taking the new queue count into account (ice_vsi_realloc_stat_arrays()). Set req_txq and req_rxq before ice_vsi_rebuild(), so that realloc uses the newly set queue count. Additionally, ice_vsi_rebuild() does not remove VSI filters (ice_fltr_remove_all()), so ice_vf_init_host_cfg() is no longer necessary.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50093", "url": "https://ubuntu.com/security/CVE-2024-50093", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: thermal: intel: int340x: processor: Fix warning during module unload The processor_thermal driver uses pcim_device_enable() to enable a PCI device, which means the device will be automatically disabled on driver detach. Thus there is no need to call pci_disable_device() again on it. With recent PCI device resource management improvements, e.g. commit f748a07a0b64 (\"PCI: Remove legacy pcim_release()\"), this problem is exposed and triggers the warining below. [ 224.010735] proc_thermal_pci 0000:00:04.0: disabling already-disabled device [ 224.010747] WARNING: CPU: 8 PID: 4442 at drivers/pci/pci.c:2250 pci_disable_device+0xe5/0x100 ... [ 224.010844] Call Trace: [ 224.010845] [ 224.010847] ? show_regs+0x6d/0x80 [ 224.010851] ? __warn+0x8c/0x140 [ 224.010854] ? pci_disable_device+0xe5/0x100 [ 224.010856] ? report_bug+0x1c9/0x1e0 [ 224.010859] ? handle_bug+0x46/0x80 [ 224.010862] ? exc_invalid_op+0x1d/0x80 [ 224.010863] ? asm_exc_invalid_op+0x1f/0x30 [ 224.010867] ? pci_disable_device+0xe5/0x100 [ 224.010869] ? pci_disable_device+0xe5/0x100 [ 224.010871] ? kfree+0x21a/0x2b0 [ 224.010873] pcim_disable_device+0x20/0x30 [ 224.010875] devm_action_release+0x16/0x20 [ 224.010878] release_nodes+0x47/0xc0 [ 224.010880] devres_release_all+0x9f/0xe0 [ 224.010883] device_unbind_cleanup+0x12/0x80 [ 224.010885] device_release_driver_internal+0x1ca/0x210 [ 224.010887] driver_detach+0x4e/0xa0 [ 224.010889] bus_remove_driver+0x6f/0xf0 [ 224.010890] driver_unregister+0x35/0x60 [ 224.010892] pci_unregister_driver+0x44/0x90 [ 224.010894] proc_thermal_pci_driver_exit+0x14/0x5f0 [processor_thermal_device_pci] ... [ 224.010921] ---[ end trace 0000000000000000 ]--- Remove the excess pci_disable_device() calls. [ rjw: Subject and changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50043", "url": "https://ubuntu.com/security/CVE-2024-50043", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: fix possible badness in FREE_STATEID When multiple FREE_STATEIDs are sent for the same delegation stateid, it can lead to a possible either use-after-free or counter refcount underflow errors. In nfsd4_free_stateid() under the client lock we find a delegation stateid, however the code drops the lock before calling nfs4_put_stid(), that allows another FREE_STATE to find the stateid again. The first one will proceed to then free the stateid which leads to either use-after-free or decrementing already zeroed counter.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50044", "url": "https://ubuntu.com/security/CVE-2024-50044", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change rfcomm_sk_state_change attempts to use sock_lock so it must never be called with it locked but rfcomm_sock_ioctl always attempt to lock it causing the following trace: ====================================================== WARNING: possible circular locking dependency detected 6.8.0-syzkaller-08951-gfe46a7dd189e #0 Not tainted ------------------------------------------------------ syz-executor386/5093 is trying to acquire lock: ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1671 [inline] ffff88807c396258 (sk_lock-AF_BLUETOOTH-BTPROTO_RFCOMM){+.+.}-{0:0}, at: rfcomm_sk_state_change+0x5b/0x310 net/bluetooth/rfcomm/sock.c:73 but task is already holding lock: ffff88807badfd28 (&d->lock){+.+.}-{3:3}, at: __rfcomm_dlc_close+0x226/0x6a0 net/bluetooth/rfcomm/core.c:491", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50045", "url": "https://ubuntu.com/security/CVE-2024-50045", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: br_netfilter: fix panic with metadata_dst skb Fix a kernel panic in the br_netfilter module when sending untagged traffic via a VxLAN device. This happens during the check for fragmentation in br_nf_dev_queue_xmit. It is dependent on: 1) the br_netfilter module being loaded; 2) net.bridge.bridge-nf-call-iptables set to 1; 3) a bridge with a VxLAN (single-vxlan-device) netdevice as a bridge port; 4) untagged frames with size higher than the VxLAN MTU forwarded/flooded When forwarding the untagged packet to the VxLAN bridge port, before the netfilter hooks are called, br_handle_egress_vlan_tunnel is called and changes the skb_dst to the tunnel dst. The tunnel_dst is a metadata type of dst, i.e., skb_valid_dst(skb) is false, and metadata->dst.dev is NULL. Then in the br_netfilter hooks, in br_nf_dev_queue_xmit, there's a check for frames that needs to be fragmented: frames with higher MTU than the VxLAN device end up calling br_nf_ip_fragment, which in turns call ip_skb_dst_mtu. The ip_dst_mtu tries to use the skb_dst(skb) as if it was a valid dst with valid dst->dev, thus the crash. This case was never supported in the first place, so drop the packet instead. PING 10.0.0.2 (10.0.0.2) from 0.0.0.0 h1-eth0: 2000(2028) bytes of data. [ 176.291791] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000110 [ 176.292101] Mem abort info: [ 176.292184] ESR = 0x0000000096000004 [ 176.292322] EC = 0x25: DABT (current EL), IL = 32 bits [ 176.292530] SET = 0, FnV = 0 [ 176.292709] EA = 0, S1PTW = 0 [ 176.292862] FSC = 0x04: level 0 translation fault [ 176.293013] Data abort info: [ 176.293104] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [ 176.293488] CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [ 176.293787] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 [ 176.293995] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000043ef5000 [ 176.294166] [0000000000000110] pgd=0000000000000000, p4d=0000000000000000 [ 176.294827] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 176.295252] Modules linked in: vxlan ip6_udp_tunnel udp_tunnel veth br_netfilter bridge stp llc ipv6 crct10dif_ce [ 176.295923] CPU: 0 PID: 188 Comm: ping Not tainted 6.8.0-rc3-g5b3fbd61b9d1 #2 [ 176.296314] Hardware name: linux,dummy-virt (DT) [ 176.296535] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 176.296808] pc : br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.297382] lr : br_nf_dev_queue_xmit+0x2ac/0x4ec [br_netfilter] [ 176.297636] sp : ffff800080003630 [ 176.297743] x29: ffff800080003630 x28: 0000000000000008 x27: ffff6828c49ad9f8 [ 176.298093] x26: ffff6828c49ad000 x25: 0000000000000000 x24: 00000000000003e8 [ 176.298430] x23: 0000000000000000 x22: ffff6828c4960b40 x21: ffff6828c3b16d28 [ 176.298652] x20: ffff6828c3167048 x19: ffff6828c3b16d00 x18: 0000000000000014 [ 176.298926] x17: ffffb0476322f000 x16: ffffb7e164023730 x15: 0000000095744632 [ 176.299296] x14: ffff6828c3f1c880 x13: 0000000000000002 x12: ffffb7e137926a70 [ 176.299574] x11: 0000000000000001 x10: ffff6828c3f1c898 x9 : 0000000000000000 [ 176.300049] x8 : ffff6828c49bf070 x7 : 0008460f18d5f20e x6 : f20e0100bebafeca [ 176.300302] x5 : ffff6828c7f918fe x4 : ffff6828c49bf070 x3 : 0000000000000000 [ 176.300586] x2 : 0000000000000000 x1 : ffff6828c3c7ad00 x0 : ffff6828c7f918f0 [ 176.300889] Call trace: [ 176.301123] br_nf_dev_queue_xmit+0x390/0x4ec [br_netfilter] [ 176.301411] br_nf_post_routing+0x2a8/0x3e4 [br_netfilter] [ 176.301703] nf_hook_slow+0x48/0x124 [ 176.302060] br_forward_finish+0xc8/0xe8 [bridge] [ 176.302371] br_nf_hook_thresh+0x124/0x134 [br_netfilter] [ 176.302605] br_nf_forward_finish+0x118/0x22c [br_netfilter] [ 176.302824] br_nf_forward_ip.part.0+0x264/0x290 [br_netfilter] [ 176.303136] br_nf_forward+0x2b8/0x4e0 [br_netfilter] [ 176.303359] nf_hook_slow+0x48/0x124 [ 176.303 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50094", "url": "https://ubuntu.com/security/CVE-2024-50094", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sfc: Don't invoke xdp_do_flush() from netpoll. Yury reported a crash in the sfc driver originated from netpoll_send_udp(). The netconsole sends a message and then netpoll invokes the driver's NAPI function with a budget of zero. It is dedicated to allow driver to free TX resources, that it may have used while sending the packet. In the netpoll case the driver invokes xdp_do_flush() unconditionally, leading to crash because bpf_net_context was never assigned. Invoke xdp_do_flush() only if budget is not zero.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50188", "url": "https://ubuntu.com/security/CVE-2024-50188", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: phy: dp83869: fix memory corruption when enabling fiber When configuring the fiber port, the DP83869 PHY driver incorrectly calls linkmode_set_bit() with a bit mask (1 << 10) rather than a bit number (10). This corrupts some other memory location -- in case of arm64 the priv pointer in the same structure. Since the advertising flags are updated from supported at the end of the function the incorrect line isn't needed at all and can be removed.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50046", "url": "https://ubuntu.com/security/CVE-2024-50046", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies() On the node of an NFS client, some files saved in the mountpoint of the NFS server were copied to another location of the same NFS server. Accidentally, the nfs42_complete_copies() got a NULL-pointer dereference crash with the following syslog: [232064.838881] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232064.839360] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232066.588183] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 [232066.588586] Mem abort info: [232066.588701] ESR = 0x0000000096000007 [232066.588862] EC = 0x25: DABT (current EL), IL = 32 bits [232066.589084] SET = 0, FnV = 0 [232066.589216] EA = 0, S1PTW = 0 [232066.589340] FSC = 0x07: level 3 translation fault [232066.589559] Data abort info: [232066.589683] ISV = 0, ISS = 0x00000007 [232066.589842] CM = 0, WnR = 0 [232066.589967] user pgtable: 64k pages, 48-bit VAs, pgdp=00002000956ff400 [232066.590231] [0000000000000058] pgd=08001100ae100003, p4d=08001100ae100003, pud=08001100ae100003, pmd=08001100b3c00003, pte=0000000000000000 [232066.590757] Internal error: Oops: 96000007 [#1] SMP [232066.590958] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm vhost_net vhost vhost_iotlb tap tun ipt_rpfilter xt_multiport ip_set_hash_ip ip_set_hash_net xfrm_interface xfrm6_tunnel tunnel4 tunnel6 esp4 ah4 wireguard libcurve25519_generic veth xt_addrtype xt_set nf_conntrack_netlink ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_bitmap_port ip_set_hash_ipport dummy ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs iptable_filter sch_ingress nfnetlink_cttimeout vport_gre ip_gre ip_tunnel gre vport_geneve geneve vport_vxlan vxlan ip6_udp_tunnel udp_tunnel openvswitch nf_conncount dm_round_robin dm_service_time dm_multipath xt_nat xt_MASQUERADE nft_chain_nat nf_nat xt_mark xt_conntrack xt_comment nft_compat nft_counter nf_tables nfnetlink ocfs2 ocfs2_nodemanager ocfs2_stackglue iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_ssif nbd overlay 8021q garp mrp bonding tls rfkill sunrpc ext4 mbcache jbd2 [232066.591052] vfat fat cas_cache cas_disk ses enclosure scsi_transport_sas sg acpi_ipmi ipmi_si ipmi_devintf ipmi_msghandler ip_tables vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio dm_mirror dm_region_hash dm_log dm_mod nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc fuse xfs libcrc32c ast drm_vram_helper qla2xxx drm_kms_helper syscopyarea crct10dif_ce sysfillrect ghash_ce sysimgblt sha2_ce fb_sys_fops cec sha256_arm64 sha1_ce drm_ttm_helper ttm nvme_fc igb sbsa_gwdt nvme_fabrics drm nvme_core i2c_algo_bit i40e scsi_transport_fc megaraid_sas aes_neon_bs [232066.596953] CPU: 6 PID: 4124696 Comm: 10.253.166.125- Kdump: loaded Not tainted 5.15.131-9.cl9_ocfs2.aarch64 #1 [232066.597356] Hardware name: Great Wall .\\x93\\x8e...RF6260 V5/GWMSSE2GL1T, BIOS T656FBE_V3.0.18 2024-01-06 [232066.597721] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [232066.598034] pc : nfs4_reclaim_open_state+0x220/0x800 [nfsv4] [232066.598327] lr : nfs4_reclaim_open_state+0x12c/0x800 [nfsv4] [232066.598595] sp : ffff8000f568fc70 [232066.598731] x29: ffff8000f568fc70 x28: 0000000000001000 x27: ffff21003db33000 [232066.599030] x26: ffff800005521ae0 x25: ffff0100f98fa3f0 x24: 0000000000000001 [232066.599319] x23: ffff800009920008 x22: ffff21003db33040 x21: ffff21003db33050 [232066.599628] x20: ffff410172fe9e40 x19: ffff410172fe9e00 x18: 0000000000000000 [232066.599914] x17: 0000000000000000 x16: 0000000000000004 x15: 0000000000000000 [232066.600195] x14: 0000000000000000 x13: ffff800008e685a8 x12: 00000000eac0c6e6 [232066.600498] x11: 00000000000000 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50190", "url": "https://ubuntu.com/security/CVE-2024-50190", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ice: fix memleak in ice_init_tx_topology() Fix leak of the FW blob (DDP pkg). Make ice_cfg_tx_topo() const-correct, so ice_init_tx_topology() can avoid copying whole FW blob. Copy just the topology section, and only when needed. Reuse the buffer allocated for the read of the current topology. This was found by kmemleak, with the following trace for each PF: [] kmemdup_noprof+0x1d/0x50 [] ice_init_ddp_config+0x100/0x220 [ice] [] ice_init_dev+0x6f/0x200 [ice] [] ice_init+0x29/0x560 [ice] [] ice_probe+0x21d/0x310 [ice] Constify ice_cfg_tx_topo() @buf parameter. This cascades further down to few more functions.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50180", "url": "https://ubuntu.com/security/CVE-2024-50180", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: sisfb: Fix strbuf array overflow The values of the variables xres and yres are placed in strbuf. These variables are obtained from strbuf1. The strbuf1 array contains digit characters and a space if the array contains non-digit characters. Then, when executing sprintf(strbuf, \"%ux%ux8\", xres, yres); more than 16 bytes will be written to strbuf. It is suggested to increase the size of the strbuf array to 24. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06: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": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50048", "url": "https://ubuntu.com/security/CVE-2024-50048", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbcon: Fix a NULL pointer dereference issue in fbcon_putcs syzbot has found a NULL pointer dereference bug in fbcon. Here is the simplified C reproducer: struct param { \tuint8_t type; \tstruct tiocl_selection ts; }; int main() { \tstruct fb_con2fbmap con2fb; \tstruct param param; \tint fd = open(\"/dev/fb1\", 0, 0); \tcon2fb.console = 0x19; \tcon2fb.framebuffer = 0; \tioctl(fd, FBIOPUT_CON2FBMAP, &con2fb); \tparam.type = 2; \tparam.ts.xs = 0; param.ts.ys = 0; \tparam.ts.xe = 0; param.ts.ye = 0; \tparam.ts.sel_mode = 0; \tint fd1 = open(\"/dev/tty1\", O_RDWR, 0); \tioctl(fd1, TIOCLINUX, ¶m); \tcon2fb.console = 1; \tcon2fb.framebuffer = 0; \tioctl(fd, FBIOPUT_CON2FBMAP, &con2fb); \treturn 0; } After calling ioctl(fd1, TIOCLINUX, ¶m), the subsequent ioctl(fd, FBIOPUT_CON2FBMAP, &con2fb) causes the kernel to follow a different execution path: set_con2fb_map -> con2fb_init_display -> fbcon_set_disp -> redraw_screen -> hide_cursor -> clear_selection -> highlight -> invert_screen -> do_update_region -> fbcon_putcs -> ops->putcs Since ops->putcs is a NULL pointer, this leads to a kernel panic. To prevent this, we need to call set_blitting_type() within set_con2fb_map() to properly initialize ops->putcs.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50049", "url": "https://ubuntu.com/security/CVE-2024-50049", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before dereferencing se [WHAT & HOW] se is null checked previously in the same function, indicating it might be null; therefore, it must be checked when used again. This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50090", "url": "https://ubuntu.com/security/CVE-2024-50090", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/oa: Fix overflow in oa batch buffer By default xe_bb_create_job() appends a MI_BATCH_BUFFER_END to batch buffer, this is not a problem if batch buffer is only used once but oa reuses the batch buffer for the same metric and at each call it appends a MI_BATCH_BUFFER_END, printing the warning below and then overflowing. [ 381.072016] ------------[ cut here ]------------ [ 381.072019] xe 0000:00:02.0: [drm] Assertion `bb->len * 4 + bb_prefetch(q->gt) <= size` failed! platform: LUNARLAKE subplatform: 1 graphics: Xe2_LPG / Xe2_HPG 20.04 step B0 media: Xe2_LPM / Xe2_HPM 20.00 step B0 tile: 0 VRAM 0 B GT: 0 type 1 So here checking if batch buffer already have MI_BATCH_BUFFER_END if not append it. v2: - simply fix, suggestion from Ashutosh (cherry picked from commit 9ba0e0f30ca42a98af3689460063edfb6315718a)", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50183", "url": "https://ubuntu.com/security/CVE-2024-50183", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV instance Deleting an NPIV instance requires all fabric ndlps to be released before an NPIV's resources can be torn down. Failure to release fabric ndlps beforehand opens kref imbalance race conditions. Fix by forcing the DA_ID to complete synchronously with usage of wait_queue.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50055", "url": "https://ubuntu.com/security/CVE-2024-50055", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: driver core: bus: Fix double free in driver API bus_register() For bus_register(), any error which happens after kset_register() will cause that @priv are freed twice, fixed by setting @priv with NULL after the first free.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50091", "url": "https://ubuntu.com/security/CVE-2024-50091", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: dm vdo: don't refer to dedupe_context after releasing it Clear the dedupe_context pointer in a data_vio whenever ownership of the context is lost, so that vdo can't examine it accidentally.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50056", "url": "https://ubuntu.com/security/CVE-2024-50056", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: gadget: uvc: Fix ERR_PTR dereference in uvc_v4l2.c Fix potential dereferencing of ERR_PTR() in find_format_by_pix() and uvc_v4l2_enum_format(). Fix the following smatch errors: drivers/usb/gadget/function/uvc_v4l2.c:124 find_format_by_pix() error: 'fmtdesc' dereferencing possible ERR_PTR() drivers/usb/gadget/function/uvc_v4l2.c:392 uvc_v4l2_enum_format() error: 'fmtdesc' dereferencing possible ERR_PTR() Also, fix similar issue in uvc_v4l2_try_format() for potential dereferencing of ERR_PTR().", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50184", "url": "https://ubuntu.com/security/CVE-2024-50184", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: virtio_pmem: Check device status before requesting flush If a pmem device is in a bad status, the driver side could wait for host ack forever in virtio_pmem_flush(), causing the system to hang. So add a status check in the beginning of virtio_pmem_flush() to return early if the device is not activated.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50057", "url": "https://ubuntu.com/security/CVE-2024-50057", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: usb: typec: tipd: Free IRQ only if it was requested before In polling mode, if no IRQ was requested there is no need to free it. Call devm_free_irq() only if client->irq is set. This fixes the warning caused by the tps6598x module removal: WARNING: CPU: 2 PID: 333 at kernel/irq/devres.c:144 devm_free_irq+0x80/0x8c ... ... Call trace: devm_free_irq+0x80/0x8c tps6598x_remove+0x28/0x88 [tps6598x] i2c_device_remove+0x2c/0x9c device_remove+0x4c/0x80 device_release_driver_internal+0x1cc/0x228 driver_detach+0x50/0x98 bus_remove_driver+0x6c/0xbc driver_unregister+0x30/0x60 i2c_del_driver+0x54/0x64 tps6598x_i2c_driver_exit+0x18/0xc3c [tps6598x] __arm64_sys_delete_module+0x184/0x264 invoke_syscall+0x48/0x110 el0_svc_common.constprop.0+0xc8/0xe8 do_el0_svc+0x20/0x2c el0_svc+0x28/0x98 el0t_64_sync_handler+0x13c/0x158 el0t_64_sync+0x190/0x194", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50058", "url": "https://ubuntu.com/security/CVE-2024-50058", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: serial: protect uart_port_dtr_rts() in uart_shutdown() too Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part 3) added few uport == NULL checks. It added one to uart_shutdown(), so the commit assumes, uport can be NULL in there. But right after that protection, there is an unprotected \"uart_port_dtr_rts(uport, false);\" call. That is invoked only if HUPCL is set, so I assume that is the reason why we do not see lots of these reports. Or it cannot be NULL at this point at all for some reason :P. Until the above is investigated, stay on the safe side and move this dereference to the if too. I got this inconsistency from Coverity under CID 1585130. Thanks.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50181", "url": "https://ubuntu.com/security/CVE-2024-50181", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: clk: imx: Remove CLK_SET_PARENT_GATE for DRAM mux for i.MX7D For i.MX7D DRAM related mux clock, the clock source change should ONLY be done done in low level asm code without accessing DRAM, and then calling clk API to sync the HW clock status with clk tree, it should never touch real clock source switch via clk API, so CLK_SET_PARENT_GATE flag should NOT be added, otherwise, DRAM's clock parent will be disabled when DRAM is active, and system will hang.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50059", "url": "https://ubuntu.com/security/CVE-2024-50059", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntb: ntb_hw_switchtec: Fix use after free vulnerability in switchtec_ntb_remove due to race condition In the switchtec_ntb_add function, it can call switchtec_ntb_init_sndev function, then &sndev->check_link_status_work is bound with check_link_status_work. switchtec_ntb_link_notification may be called to start the work. If we remove the module which will call switchtec_ntb_remove to make cleanup, it will free sndev through kfree(sndev), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | check_link_status_work switchtec_ntb_remove | kfree(sndev); | | if (sndev->link_force_down) | // use sndev Fix it by ensuring that the work is canceled before proceeding with the cleanup in switchtec_ntb_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50060", "url": "https://ubuntu.com/security/CVE-2024-50060", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: io_uring: check if we need to reschedule during overflow flush In terms of normal application usage, this list will always be empty. And if an application does overflow a bit, it'll have a few entries. However, nothing obviously prevents syzbot from running a test case that generates a ton of overflow entries, and then flushing them can take quite a while. Check for needing to reschedule while flushing, and drop our locks and do so if necessary. There's no state to maintain here as overflows always prune from head-of-list, hence it's fine to drop and reacquire the locks at the end of the loop.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50061", "url": "https://ubuntu.com/security/CVE-2024-50061", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: cdns: Fix use after free vulnerability in cdns_i3c_master Driver Due to Race Condition In the cdns_i3c_master_probe function, &master->hj_work is bound with cdns_i3c_master_hj. And cdns_i3c_master_interrupt can call cnds_i3c_master_demux_ibis function to start the work. If we remove the module which will call cdns_i3c_master_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | cdns_i3c_master_hj cdns_i3c_master_remove | i3c_master_unregister(&master->base) | device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in cdns_i3c_master_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50062", "url": "https://ubuntu.com/security/CVE-2024-50062", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-srv: Avoid null pointer deref during path establishment For RTRS path establishment, RTRS client initiates and completes con_num of connections. After establishing all its connections, the information is exchanged between the client and server through the info_req message. During this exchange, it is essential that all connections have been established, and the state of the RTRS srv path is CONNECTED. So add these sanity checks, to make sure we detect and abort process in error scenarios to avoid null pointer deref.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50095", "url": "https://ubuntu.com/security/CVE-2024-50095", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/mad: Improve handling of timed out WRs of mad agent Current timeout handler of mad agent acquires/releases mad_agent_priv lock for every timed out WRs. This causes heavy locking contention when higher no. of WRs are to be handled inside timeout handler. This leads to softlockup with below trace in some use cases where rdma-cm path is used to establish connection between peer nodes Trace: ----- BUG: soft lockup - CPU#4 stuck for 26s! [kworker/u128:3:19767] CPU: 4 PID: 19767 Comm: kworker/u128:3 Kdump: loaded Tainted: G OE ------- --- 5.14.0-427.13.1.el9_4.x86_64 #1 Hardware name: Dell Inc. PowerEdge R740/01YM03, BIOS 2.4.8 11/26/2019 Workqueue: ib_mad1 timeout_sends [ib_core] RIP: 0010:__do_softirq+0x78/0x2ac RSP: 0018:ffffb253449e4f98 EFLAGS: 00000246 RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 000000000000001f RDX: 000000000000001d RSI: 000000003d1879ab RDI: fff363b66fd3a86b RBP: ffffb253604cbcd8 R08: 0000009065635f3b R09: 0000000000000000 R10: 0000000000000040 R11: ffffb253449e4ff8 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000040 FS: 0000000000000000(0000) GS:ffff8caa1fc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fd9ec9db900 CR3: 0000000891934006 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? __irq_exit_rcu+0xa1/0xc0 ? watchdog_timer_fn+0x1b2/0x210 ? __pfx_watchdog_timer_fn+0x10/0x10 ? __hrtimer_run_queues+0x127/0x2c0 ? hrtimer_interrupt+0xfc/0x210 ? __sysvec_apic_timer_interrupt+0x5c/0x110 ? sysvec_apic_timer_interrupt+0x37/0x90 ? asm_sysvec_apic_timer_interrupt+0x16/0x20 ? __do_softirq+0x78/0x2ac ? __do_softirq+0x60/0x2ac __irq_exit_rcu+0xa1/0xc0 sysvec_call_function_single+0x72/0x90 asm_sysvec_call_function_single+0x16/0x20 RIP: 0010:_raw_spin_unlock_irq+0x14/0x30 RSP: 0018:ffffb253604cbd88 EFLAGS: 00000247 RAX: 000000000001960d RBX: 0000000000000002 RCX: ffff8cad2a064800 RDX: 000000008020001b RSI: 0000000000000001 RDI: ffff8cad5d39f66c RBP: ffff8cad5d39f600 R08: 0000000000000001 R09: 0000000000000000 R10: ffff8caa443e0c00 R11: ffffb253604cbcd8 R12: ffff8cacb8682538 R13: 0000000000000005 R14: ffffb253604cbd90 R15: ffff8cad5d39f66c cm_process_send_error+0x122/0x1d0 [ib_cm] timeout_sends+0x1dd/0x270 [ib_core] process_one_work+0x1e2/0x3b0 ? __pfx_worker_thread+0x10/0x10 worker_thread+0x50/0x3a0 ? __pfx_worker_thread+0x10/0x10 kthread+0xdd/0x100 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x29/0x50 Simplified timeout handler by creating local list of timed out WRs and invoke send handler post creating the list. The new method acquires/ releases lock once to fetch the list and hence helps to reduce locking contetiong when processing higher no. of WRs", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-50063", "url": "https://ubuntu.com/security/CVE-2024-50063", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Prevent tail call between progs attached to different hooks bpf progs can be attached to kernel functions, and the attached functions can take different parameters or return different return values. If prog attached to one kernel function tail calls prog attached to another kernel function, the ctx access or return value verification could be bypassed. For example, if prog1 is attached to func1 which takes only 1 parameter and prog2 is attached to func2 which takes two parameters. Since verifier assumes the bpf ctx passed to prog2 is constructed based on func2's prototype, verifier allows prog2 to access the second parameter from the bpf ctx passed to it. The problem is that verifier does not prevent prog1 from passing its bpf ctx to prog2 via tail call. In this case, the bpf ctx passed to prog2 is constructed from func1 instead of func2, that is, the assumption for ctx access verification is bypassed. Another example, if BPF LSM prog1 is attached to hook file_alloc_security, and BPF LSM prog2 is attached to hook bpf_lsm_audit_rule_known. Verifier knows the return value rules for these two hooks, e.g. it is legal for bpf_lsm_audit_rule_known to return positive number 1, and it is illegal for file_alloc_security to return positive number. So verifier allows prog2 to return positive number 1, but does not allow prog1 to return positive number. The problem is that verifier does not prevent prog1 from calling prog2 via tail call. In this case, prog2's return value 1 will be used as the return value for prog1's hook file_alloc_security. That is, the return value rule is bypassed. This patch adds restriction for tail call to prevent such bypasses.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50191", "url": "https://ubuntu.com/security/CVE-2024-50191", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: don't set SB_RDONLY after filesystem errors When the filesystem is mounted with errors=remount-ro, we were setting SB_RDONLY flag to stop all filesystem modifications. We knew this misses proper locking (sb->s_umount) and does not go through proper filesystem remount procedure but it has been the way this worked since early ext2 days and it was good enough for catastrophic situation damage mitigation. Recently, syzbot has found a way (see link) to trigger warnings in filesystem freezing because the code got confused by SB_RDONLY changing under its hands. Since these days we set EXT4_FLAGS_SHUTDOWN on the superblock which is enough to stop all filesystem modifications, modifying SB_RDONLY shouldn't be needed. So stop doing that.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50064", "url": "https://ubuntu.com/security/CVE-2024-50064", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: zram: free secondary algorithms names We need to kfree() secondary algorithms names when reset zram device that had multi-streams, otherwise we leak memory. [senozhatsky@chromium.org: kfree(NULL) is legal] Link: https://lkml.kernel.org/r/20240917013021.868769-1-senozhatsky@chromium.org", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50065", "url": "https://ubuntu.com/security/CVE-2024-50065", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntfs3: Change to non-blocking allocation in ntfs_d_hash d_hash is done while under \"rcu-walk\" and should not sleep. __get_name() allocates using GFP_KERNEL, having the possibility to sleep when under memory pressure. Change the allocation to GFP_NOWAIT.", "cve_priority": "medium", "cve_public_date": "2024-10-21 20:15:00 UTC" }, { "cve": "CVE-2024-50089", "url": "https://ubuntu.com/security/CVE-2024-50089", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-11-05 17:15:00 UTC" }, { "cve": "CVE-2024-49863", "url": "https://ubuntu.com/security/CVE-2024-49863", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost/scsi: null-ptr-dereference in vhost_scsi_get_req() Since commit 3f8ca2e115e5 (\"vhost/scsi: Extract common handling code from control queue handler\") a null pointer dereference bug can be triggered when guest sends an SCSI AN request. In vhost_scsi_ctl_handle_vq(), `vc.target` is assigned with `&v_req.tmf.lun[1]` within a switch-case block and is then passed to vhost_scsi_get_req() which extracts `vc->req` and `tpg`. However, for a `VIRTIO_SCSI_T_AN_*` request, tpg is not required, so `vc.target` is set to NULL in this branch. Later, in vhost_scsi_get_req(), `vc->target` is dereferenced without being checked, leading to a null pointer dereference bug. This bug can be triggered from guest. When this bug occurs, the vhost_worker process is killed while holding `vq->mutex` and the corresponding tpg will remain occupied indefinitely. Below is the KASAN report: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 PID: 840 Comm: poc Not tainted 6.10.0+ #1 Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:vhost_scsi_get_req+0x165/0x3a0 Code: 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 02 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 65 30 4c 89 e2 48 c1 ea 03 <0f> b6 04 02 4c 89 e2 83 e2 07 38 d0 7f 08 84 c0 0f 85 be 01 00 00 RSP: 0018:ffff888017affb50 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffff88801b000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888017affcb8 RBP: ffff888017affb80 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff888017affc88 R14: ffff888017affd1c R15: ffff888017993000 FS: 000055556e076500(0000) GS:ffff88806b100000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200027c0 CR3: 0000000010ed0004 CR4: 0000000000370ef0 Call Trace: ? show_regs+0x86/0xa0 ? die_addr+0x4b/0xd0 ? exc_general_protection+0x163/0x260 ? asm_exc_general_protection+0x27/0x30 ? vhost_scsi_get_req+0x165/0x3a0 vhost_scsi_ctl_handle_vq+0x2a4/0xca0 ? __pfx_vhost_scsi_ctl_handle_vq+0x10/0x10 ? __switch_to+0x721/0xeb0 ? __schedule+0xda5/0x5710 ? __kasan_check_write+0x14/0x30 ? _raw_spin_lock+0x82/0xf0 vhost_scsi_ctl_handle_kick+0x52/0x90 vhost_run_work_list+0x134/0x1b0 vhost_task_fn+0x121/0x350 ... ---[ end trace 0000000000000000 ]--- Let's add a check in vhost_scsi_get_req. [whitespace fixes]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49864", "url": "https://ubuntu.com/security/CVE-2024-49864", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix a race between socket set up and I/O thread creation In rxrpc_open_socket(), it sets up the socket and then sets up the I/O thread that will handle it. This is a problem, however, as there's a gap between the two phases in which a packet may come into rxrpc_encap_rcv() from the UDP packet but we oops when trying to wake the not-yet created I/O thread. As a quick fix, just make rxrpc_encap_rcv() discard the packet if there's no I/O thread yet. A better, but more intrusive fix would perhaps be to rearrange things such that the socket creation is done by the I/O thread.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49865", "url": "https://ubuntu.com/security/CVE-2024-49865", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/vm: move xa_alloc to prevent UAF Evil user can guess the next id of the vm before the ioctl completes and then call vm destroy ioctl to trigger UAF since create ioctl is still referencing the same vm. Move the xa_alloc all the way to the end to prevent this. v2: - Rebase (cherry picked from commit dcfd3971327f3ee92765154baebbaece833d3ca9)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49955", "url": "https://ubuntu.com/security/CVE-2024-49955", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: battery: Fix possible crash when unregistering a battery hook When a battery hook returns an error when adding a new battery, then the battery hook is automatically unregistered. However the battery hook provider cannot know that, so it will later call battery_hook_unregister() on the already unregistered battery hook, resulting in a crash. Fix this by using the list head to mark already unregistered battery hooks as already being unregistered so that they can be ignored by battery_hook_unregister().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49973", "url": "https://ubuntu.com/security/CVE-2024-49973", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: r8169: add tally counter fields added with RTL8125 RTL8125 added fields to the tally counter, what may result in the chip dma'ing these new fields to unallocated memory. Therefore make sure that the allocated memory area is big enough to hold all of the tally counter values, even if we use only parts of it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49974", "url": "https://ubuntu.com/security/CVE-2024-49974", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: NFSD: Limit the number of concurrent async COPY operations Nothing appears to limit the number of concurrent async COPY operations that clients can start. In addition, AFAICT each async COPY can copy an unlimited number of 4MB chunks, so can run for a long time. Thus IMO async COPY can become a DoS vector. Add a restriction mechanism that bounds the number of concurrent background COPY operations. Start simple and try to be fair -- this patch implements a per-namespace limit. An async COPY request that occurs while this limit is exceeded gets NFS4ERR_DELAY. The requesting client can choose to send the request again after a delay or fall back to a traditional read/write style copy. If there is need to make the mechanism more sophisticated, we can visit that in future patches.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49975", "url": "https://ubuntu.com/security/CVE-2024-49975", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: uprobes: fix kernel info leak via \"[uprobes]\" vma xol_add_vma() maps the uninitialized page allocated by __create_xol_area() into userspace. On some architectures (x86) this memory is readable even without VM_READ, VM_EXEC results in the same pgprot_t as VM_EXEC|VM_READ, although this doesn't really matter, debugger can read this memory anyway.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50003", "url": "https://ubuntu.com/security/CVE-2024-50003", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix system hang while resume with TBT monitor [Why] Connected with a Thunderbolt monitor and do the suspend and the system may hang while resume. The TBT monitor HPD will be triggered during the resume procedure and call the drm_client_modeset_probe() while struct drm_connector connector->dev->master is NULL. It will mess up the pipe topology after resume. [How] Skip the TBT monitor HPD during the resume procedure because we currently will probe the connectors after resume by default. (cherry picked from commit 453f86a26945207a16b8f66aaed5962dc2b95b85)", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50173", "url": "https://ubuntu.com/security/CVE-2024-50173", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix access to uninitialized variable in tick_ctx_cleanup() The group variable can't be used to retrieve ptdev in our second loop, because it points to the previously iterated list_head, not a valid group. Get the ptdev object from the scheduler instead.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49866", "url": "https://ubuntu.com/security/CVE-2024-49866", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Fix a race during cpuhp processing There is another found exception that the \"timerlat/1\" thread was scheduled on CPU0, and lead to timer corruption finally: ``` ODEBUG: init active (active state 0) object: ffff888237c2e108 object type: hrtimer hint: timerlat_irq+0x0/0x220 WARNING: CPU: 0 PID: 426 at lib/debugobjects.c:518 debug_print_object+0x7d/0xb0 Modules linked in: CPU: 0 UID: 0 PID: 426 Comm: timerlat/1 Not tainted 6.11.0-rc7+ #45 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:debug_print_object+0x7d/0xb0 ... Call Trace: ? __warn+0x7c/0x110 ? debug_print_object+0x7d/0xb0 ? report_bug+0xf1/0x1d0 ? prb_read_valid+0x17/0x20 ? handle_bug+0x3f/0x70 ? exc_invalid_op+0x13/0x60 ? asm_exc_invalid_op+0x16/0x20 ? debug_print_object+0x7d/0xb0 ? debug_print_object+0x7d/0xb0 ? __pfx_timerlat_irq+0x10/0x10 __debug_object_init+0x110/0x150 hrtimer_init+0x1d/0x60 timerlat_main+0xab/0x2d0 ? __pfx_timerlat_main+0x10/0x10 kthread+0xb7/0xe0 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2d/0x40 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1a/0x30 ``` After tracing the scheduling event, it was discovered that the migration of the \"timerlat/1\" thread was performed during thread creation. Further analysis confirmed that it is because the CPU online processing for osnoise is implemented through workers, which is asynchronous with the offline processing. When the worker was scheduled to create a thread, the CPU may has already been removed from the cpu_online_mask during the offline process, resulting in the inability to select the right CPU: T1 | T2 [CPUHP_ONLINE] | cpu_device_down() osnoise_hotplug_workfn() | | cpus_write_lock() | takedown_cpu(1) | cpus_write_unlock() [CPUHP_OFFLINE] | cpus_read_lock() | start_kthread(1) | cpus_read_unlock() | To fix this, skip online processing if the CPU is already offline.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49976", "url": "https://ubuntu.com/security/CVE-2024-49976", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tracing/timerlat: Drop interface_lock in stop_kthread() stop_kthread() is the offline callback for \"trace/osnoise:online\", since commit 5bfbcd1ee57b (\"tracing/timerlat: Add interface_lock around clearing of kthread in stop_kthread()\"), the following ABBA deadlock scenario is introduced: T1 | T2 [BP] | T3 [AP] osnoise_hotplug_workfn() | work_for_cpu_fn() | cpuhp_thread_fun() | _cpu_down() | osnoise_cpu_die() mutex_lock(&interface_lock) | | stop_kthread() | cpus_write_lock() | mutex_lock(&interface_lock) cpus_read_lock() | cpuhp_kick_ap() | As the interface_lock here in just for protecting the \"kthread\" field of the osn_var, use xchg() instead to fix this issue. Also use for_each_online_cpu() back in stop_per_cpu_kthreads() as it can take cpu_read_lock() again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50005", "url": "https://ubuntu.com/security/CVE-2024-50005", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mac802154: Fix potential RCU dereference issue in mac802154_scan_worker In the `mac802154_scan_worker` function, the `scan_req->type` field was accessed after the RCU read-side critical section was unlocked. According to RCU usage rules, this is illegal and can lead to unpredictable behavior, such as accessing memory that has been updated or causing use-after-free issues. This possible bug was identified using a static analysis tool developed by myself, specifically designed to detect RCU-related issues. To address this, the `scan_req->type` value is now stored in a local variable `scan_req_type` while still within the RCU read-side critical section. The `scan_req_type` is then used after the RCU lock is released, ensuring that the type value is safely accessed without violating RCU rules.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50012", "url": "https://ubuntu.com/security/CVE-2024-50012", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: Avoid a bad reference count on CPU node In the parse_perf_domain function, if the call to of_parse_phandle_with_args returns an error, then the reference to the CPU device node that was acquired at the start of the function would not be properly decremented. Address this by declaring the variable with the __free(device_node) cleanup attribute.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49867", "url": "https://ubuntu.com/security/CVE-2024-49867", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: wait for fixup workers before stopping cleaner kthread during umount During unmount, at close_ctree(), we have the following steps in this order: 1) Park the cleaner kthread - this doesn't destroy the kthread, it basically halts its execution (wake ups against it work but do nothing); 2) We stop the cleaner kthread - this results in freeing the respective struct task_struct; 3) We call btrfs_stop_all_workers() which waits for any jobs running in all the work queues and then free the work queues. Syzbot reported a case where a fixup worker resulted in a crash when doing a delayed iput on its inode while attempting to wake up the cleaner at btrfs_add_delayed_iput(), because the task_struct of the cleaner kthread was already freed. This can happen during unmount because we don't wait for any fixup workers still running before we call kthread_stop() against the cleaner kthread, which stops and free all its resources. Fix this by waiting for any fixup workers at close_ctree() before we call kthread_stop() against the cleaner and run pending delayed iputs. The stack traces reported by syzbot were the following: BUG: KASAN: slab-use-after-free in __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 Read of size 8 at addr ffff8880272a8a18 by task kworker/u8:3/52 CPU: 1 UID: 0 PID: 52 Comm: kworker/u8:3 Not tainted 6.12.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Workqueue: btrfs-fixup btrfs_work_helper 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 __lock_acquire+0x77/0x2050 kernel/locking/lockdep.c:5065 lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5825 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0xd5/0x120 kernel/locking/spinlock.c:162 class_raw_spinlock_irqsave_constructor include/linux/spinlock.h:551 [inline] try_to_wake_up+0xb0/0x1480 kernel/sched/core.c:4154 btrfs_writepage_fixup_worker+0xc16/0xdf0 fs/btrfs/inode.c:2842 btrfs_work_helper+0x390/0xc50 fs/btrfs/async-thread.c:314 process_one_work kernel/workqueue.c:3229 [inline] process_scheduled_works+0xa63/0x1850 kernel/workqueue.c:3310 worker_thread+0x870/0xd30 kernel/workqueue.c:3391 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Allocated by task 2: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:319 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:345 kasan_slab_alloc include/linux/kasan.h:247 [inline] slab_post_alloc_hook mm/slub.c:4086 [inline] slab_alloc_node mm/slub.c:4135 [inline] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4187 alloc_task_struct_node kernel/fork.c:180 [inline] dup_task_struct+0x57/0x8c0 kernel/fork.c:1107 copy_process+0x5d1/0x3d50 kernel/fork.c:2206 kernel_clone+0x223/0x880 kernel/fork.c:2787 kernel_thread+0x1bc/0x240 kernel/fork.c:2849 create_kthread kernel/kthread.c:412 [inline] kthreadd+0x60d/0x810 kernel/kthread.c:765 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 Freed by task 61: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object mm/kasan/common.c:247 [inline] __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264 kasan_slab_free include/linux/kasan.h:230 [inline] slab_free_h ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49868", "url": "https://ubuntu.com/security/CVE-2024-49868", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix a NULL pointer dereference when failed to start a new trasacntion [BUG] Syzbot reported a NULL pointer dereference with the following crash: FAULT_INJECTION: forcing a failure. start_transaction+0x830/0x1670 fs/btrfs/transaction.c:676 prepare_to_relocate+0x31f/0x4c0 fs/btrfs/relocation.c:3642 relocate_block_group+0x169/0xd20 fs/btrfs/relocation.c:3678 ... BTRFS info (device loop0): balance: ended with status: -12 Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cc: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000660-0x0000000000000667] RIP: 0010:btrfs_update_reloc_root+0x362/0xa80 fs/btrfs/relocation.c:926 Call Trace: commit_fs_roots+0x2ee/0x720 fs/btrfs/transaction.c:1496 btrfs_commit_transaction+0xfaf/0x3740 fs/btrfs/transaction.c:2430 del_balance_item fs/btrfs/volumes.c:3678 [inline] reset_balance_state+0x25e/0x3c0 fs/btrfs/volumes.c:3742 btrfs_balance+0xead/0x10c0 fs/btrfs/volumes.c:4574 btrfs_ioctl_balance+0x493/0x7c0 fs/btrfs/ioctl.c:3673 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/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f [CAUSE] The allocation failure happens at the start_transaction() inside prepare_to_relocate(), and during the error handling we call unset_reloc_control(), which makes fs_info->balance_ctl to be NULL. Then we continue the error path cleanup in btrfs_balance() by calling reset_balance_state() which will call del_balance_item() to fully delete the balance item in the root tree. However during the small window between set_reloc_contrl() and unset_reloc_control(), we can have a subvolume tree update and created a reloc_root for that subvolume. Then we go into the final btrfs_commit_transaction() of del_balance_item(), and into btrfs_update_reloc_root() inside commit_fs_roots(). That function checks if fs_info->reloc_ctl is in the merge_reloc_tree stage, but since fs_info->reloc_ctl is NULL, it results a NULL pointer dereference. [FIX] Just add extra check on fs_info->reloc_ctl inside btrfs_update_reloc_root(), before checking fs_info->reloc_ctl->merge_reloc_tree. That DEAD_RELOC_TREE handling is to prevent further modification to the reloc tree during merge stage, but since there is no reloc_ctl at all, we do not need to bother that.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49869", "url": "https://ubuntu.com/security/CVE-2024-49869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: send: fix buffer overflow detection when copying path to cache entry Starting with commit c0247d289e73 (\"btrfs: send: annotate struct name_cache_entry with __counted_by()\") we annotated the variable length array \"name\" from the name_cache_entry structure with __counted_by() to improve overflow detection. However that alone was not correct, because the length of that array does not match the \"name_len\" field - it matches that plus 1 to include the NUL string terminator, so that makes a fortified kernel think there's an overflow and report a splat like this: strcpy: detected buffer overflow: 20 byte write of buffer size 19 WARNING: CPU: 3 PID: 3310 at __fortify_report+0x45/0x50 CPU: 3 UID: 0 PID: 3310 Comm: btrfs Not tainted 6.11.0-prnet #1 Hardware name: CompuLab Ltd. sbc-ihsw/Intense-PC2 (IPC2), BIOS IPC2_3.330.7 X64 03/15/2018 RIP: 0010:__fortify_report+0x45/0x50 Code: 48 8b 34 (...) RSP: 0018:ffff97ebc0d6f650 EFLAGS: 00010246 RAX: 7749924ef60fa600 RBX: ffff8bf5446a521a RCX: 0000000000000027 RDX: 00000000ffffdfff RSI: ffff97ebc0d6f548 RDI: ffff8bf84e7a1cc8 RBP: ffff8bf548574080 R08: ffffffffa8c40e10 R09: 0000000000005ffd R10: 0000000000000004 R11: ffffffffa8c70e10 R12: ffff8bf551eef400 R13: 0000000000000000 R14: 0000000000000013 R15: 00000000000003a8 FS: 00007fae144de8c0(0000) GS:ffff8bf84e780000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fae14691690 CR3: 00000001027a2003 CR4: 00000000001706f0 Call Trace: ? __warn+0x12a/0x1d0 ? __fortify_report+0x45/0x50 ? report_bug+0x154/0x1c0 ? handle_bug+0x42/0x70 ? exc_invalid_op+0x1a/0x50 ? asm_exc_invalid_op+0x1a/0x20 ? __fortify_report+0x45/0x50 __fortify_panic+0x9/0x10 __get_cur_name_and_parent+0x3bc/0x3c0 get_cur_path+0x207/0x3b0 send_extent_data+0x709/0x10d0 ? find_parent_nodes+0x22df/0x25d0 ? mas_nomem+0x13/0x90 ? mtree_insert_range+0xa5/0x110 ? btrfs_lru_cache_store+0x5f/0x1e0 ? iterate_extent_inodes+0x52d/0x5a0 process_extent+0xa96/0x11a0 ? __pfx_lookup_backref_cache+0x10/0x10 ? __pfx_store_backref_cache+0x10/0x10 ? __pfx_iterate_backrefs+0x10/0x10 ? __pfx_check_extent_item+0x10/0x10 changed_cb+0x6fa/0x930 ? tree_advance+0x362/0x390 ? memcmp_extent_buffer+0xd7/0x160 send_subvol+0xf0a/0x1520 btrfs_ioctl_send+0x106b/0x11d0 ? __pfx___clone_root_cmp_sort+0x10/0x10 _btrfs_ioctl_send+0x1ac/0x240 btrfs_ioctl+0x75b/0x850 __se_sys_ioctl+0xca/0x150 do_syscall_64+0x85/0x160 ? __count_memcg_events+0x69/0x100 ? handle_mm_fault+0x1327/0x15c0 ? __se_sys_rt_sigprocmask+0xf1/0x180 ? syscall_exit_to_user_mode+0x75/0xa0 ? do_syscall_64+0x91/0x160 ? do_user_addr_fault+0x21d/0x630 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fae145eeb4f Code: 00 48 89 (...) RSP: 002b:00007ffdf1cb09b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fae145eeb4f RDX: 00007ffdf1cb0ad0 RSI: 0000000040489426 RDI: 0000000000000004 RBP: 00000000000078fe R08: 00007fae144006c0 R09: 00007ffdf1cb0927 R10: 0000000000000008 R11: 0000000000000246 R12: 00007ffdf1cb1ce8 R13: 0000000000000003 R14: 000055c499fab2e0 R15: 0000000000000004 Fix this by not storing the NUL string terminator since we don't actually need it for name cache entries, this way \"name_len\" corresponds to the actual size of the \"name\" array. This requires marking the \"name\" array field with __nonstring and using memcpy() instead of strcpy() as recommended by the guidelines at: https://github.com/KSPP/linux/issues/90", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49870", "url": "https://ubuntu.com/security/CVE-2024-49870", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cachefiles: fix dentry leak in cachefiles_open_file() A dentry leak may be caused when a lookup cookie and a cull are concurrent: P1 | P2 ----------------------------------------------------------- cachefiles_lookup_cookie cachefiles_look_up_object lookup_one_positive_unlocked // get dentry cachefiles_cull inode->i_flags |= S_KERNEL_FILE; cachefiles_open_file cachefiles_mark_inode_in_use __cachefiles_mark_inode_in_use can_use = false if (!(inode->i_flags & S_KERNEL_FILE)) can_use = true \t return false return false // Returns an error but doesn't put dentry After that the following WARNING will be triggered when the backend folder is umounted: ================================================================== BUG: Dentry 000000008ad87947{i=7a,n=Dx_1_1.img} still in use (1) [unmount of ext4 sda] WARNING: CPU: 4 PID: 359261 at fs/dcache.c:1767 umount_check+0x5d/0x70 CPU: 4 PID: 359261 Comm: umount Not tainted 6.6.0-dirty #25 RIP: 0010:umount_check+0x5d/0x70 Call Trace: d_walk+0xda/0x2b0 do_one_tree+0x20/0x40 shrink_dcache_for_umount+0x2c/0x90 generic_shutdown_super+0x20/0x160 kill_block_super+0x1a/0x40 ext4_kill_sb+0x22/0x40 deactivate_locked_super+0x35/0x80 cleanup_mnt+0x104/0x160 ================================================================== Whether cachefiles_open_file() returns true or false, the reference count obtained by lookup_positive_unlocked() in cachefiles_look_up_object() should be released. Therefore release that reference count in cachefiles_look_up_object() to fix the above issue and simplify the code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49871", "url": "https://ubuntu.com/security/CVE-2024-49871", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Input: adp5589-keys - fix NULL pointer dereference We register a devm action to call adp5589_clear_config() and then pass the i2c client as argument so that we can call i2c_get_clientdata() in order to get our device object. However, i2c_set_clientdata() is only being set at the end of the probe function which means that we'll get a NULL pointer dereference in case the probe function fails early.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49872", "url": "https://ubuntu.com/security/CVE-2024-49872", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/gup: fix memfd_pin_folios alloc race panic If memfd_pin_folios tries to create a hugetlb page, but someone else already did, then folio gets the value -EEXIST here: folio = memfd_alloc_folio(memfd, start_idx); if (IS_ERR(folio)) { ret = PTR_ERR(folio); if (ret != -EEXIST) goto err; then on the next trip through the \"while start_idx\" loop we panic here: if (folio) { folio_put(folio); To fix, set the folio to NULL on error.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49964", "url": "https://ubuntu.com/security/CVE-2024-49964", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb: fix memfd_pin_folios free_huge_pages leak memfd_pin_folios followed by unpin_folios fails to restore free_huge_pages if the pages were not already faulted in, because the folio refcount for pages created by memfd_alloc_folio never goes to 0. memfd_pin_folios needs another folio_put to undo the folio_try_get below: memfd_alloc_folio() alloc_hugetlb_folio_nodemask() dequeue_hugetlb_folio_nodemask() dequeue_hugetlb_folio_node_exact() folio_ref_unfreeze(folio, 1); ; adds 1 refcount folio_try_get() ; adds 1 refcount hugetlb_add_to_page_cache() ; adds 512 refcount (on x86) With the fix, after memfd_pin_folios + unpin_folios, the refcount for the (unfaulted) page is 512, which is correct, as the refcount for a faulted unpinned page is 513.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49873", "url": "https://ubuntu.com/security/CVE-2024-49873", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/filemap: fix filemap_get_folios_contig THP panic Patch series \"memfd-pin huge page fixes\". Fix multiple bugs that occur when using memfd_pin_folios with hugetlb pages and THP. The hugetlb bugs only bite when the page is not yet faulted in when memfd_pin_folios is called. The THP bug bites when the starting offset passed to memfd_pin_folios is not huge page aligned. See the commit messages for details. This patch (of 5): memfd_pin_folios on memory backed by THP panics if the requested start offset is not huge page aligned: BUG: kernel NULL pointer dereference, address: 0000000000000036 RIP: 0010:filemap_get_folios_contig+0xdf/0x290 RSP: 0018:ffffc9002092fbe8 EFLAGS: 00010202 RAX: 0000000000000002 RBX: 0000000000000002 RCX: 0000000000000002 The fault occurs here, because xas_load returns a folio with value 2: filemap_get_folios_contig() for (folio = xas_load(&xas); folio && xas.xa_index <= end; folio = xas_next(&xas)) { ... if (!folio_try_get(folio)) <-- BOOM \"2\" is an xarray sibling entry. We get it because memfd_pin_folios does not round the indices passed to filemap_get_folios_contig to huge page boundaries for THP, so we load from the middle of a huge page range see a sibling. (It does round for hugetlbfs, at the is_file_hugepages test). To fix, if the folio is a sibling, then return the next index as the starting point for the next call to filemap_get_folios_contig.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49977", "url": "https://ubuntu.com/security/CVE-2024-49977", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: stmmac: Fix zero-division error when disabling tc cbs The commit b8c43360f6e4 (\"net: stmmac: No need to calculate speed divider when offload is disabled\") allows the \"port_transmit_rate_kbps\" to be set to a value of 0, which is then passed to the \"div_s64\" function when tc-cbs is disabled. This leads to a zero-division error. When tc-cbs is disabled, the idleslope, sendslope, and credit values the credit values are not required to be configured. Therefore, adding a return statement after setting the txQ mode to DCB when tc-cbs is disabled would prevent a zero-division error.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49978", "url": "https://ubuntu.com/security/CVE-2024-49978", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gso: fix udp gso fraglist segmentation after pull from frag_list Detect gso fraglist skbs with corrupted geometry (see below) and pass these to skb_segment instead of skb_segment_list, as the first can segment them correctly. 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 these skbs, breaking these invariants. In extreme cases they pull all data into skb linear. For UDP, this causes a NULL ptr deref in __udpv4_gso_segment_list_csum at udp_hdr(seg->next)->dest. Detect invalid geometry due to pull, by checking head_skb size. Don't just drop, as this may blackhole a destination. Convert to be able to pass to regular skb_segment.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49979", "url": "https://ubuntu.com/security/CVE-2024-49979", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: gso: fix tcp fraglist segmentation after pull from frag_list Detect tcp gso fraglist skbs with corrupted geometry (see below) and pass these to skb_segment instead of skb_segment_list, as the first can segment them correctly. 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 these skbs, breaking these invariants. In extreme cases they pull all data into skb linear. For TCP, this causes a NULL ptr deref in __tcpv4_gso_segment_list_csum at tcp_hdr(seg->next). Detect invalid geometry due to pull, by checking head_skb size. Don't just drop, as this may blackhole a destination. Convert to be able to pass to regular skb_segment. Approach and description based on a patch by Willem de Bruijn.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49980", "url": "https://ubuntu.com/security/CVE-2024-49980", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vrf: revert \"vrf: Remove unnecessary RCU-bh critical section\" This reverts commit 504fc6f4f7f681d2a03aa5f68aad549d90eab853. dev_queue_xmit_nit is expected to be called with BH disabled. __dev_queue_xmit has the following: /* Disable soft irqs for various locks below. Also * stops preemption for RCU. */ rcu_read_lock_bh(); VRF must follow this invariant. The referenced commit removed this protection. Which triggered a lockdep warning: \t================================ \tWARNING: inconsistent lock state \t6.11.0 #1 Tainted: G W \t-------------------------------- \tinconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage. \tbtserver/134819 [HC0[0]:SC0[0]:HE1:SE1] takes: \tffff8882da30c118 (rlock-AF_PACKET){+.?.}-{2:2}, at: tpacket_rcv+0x863/0x3b30 \t{IN-SOFTIRQ-W} state was registered at: \t lock_acquire+0x19a/0x4f0 \t _raw_spin_lock+0x27/0x40 \t packet_rcv+0xa33/0x1320 \t __netif_receive_skb_core.constprop.0+0xcb0/0x3a90 \t __netif_receive_skb_list_core+0x2c9/0x890 \t netif_receive_skb_list_internal+0x610/0xcc0 [...] \tother info that might help us debug this: \t Possible unsafe locking scenario: \t CPU0 \t ---- \t lock(rlock-AF_PACKET); \t \t lock(rlock-AF_PACKET); \t *** DEADLOCK *** \tCall Trace: \t \t dump_stack_lvl+0x73/0xa0 \t mark_lock+0x102e/0x16b0 \t __lock_acquire+0x9ae/0x6170 \t lock_acquire+0x19a/0x4f0 \t _raw_spin_lock+0x27/0x40 \t tpacket_rcv+0x863/0x3b30 \t dev_queue_xmit_nit+0x709/0xa40 \t vrf_finish_direct+0x26e/0x340 [vrf] \t vrf_l3_out+0x5f4/0xe80 [vrf] \t __ip_local_out+0x51e/0x7a0 [...]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49981", "url": "https://ubuntu.com/security/CVE-2024-49981", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: venus: fix use after free bug in venus_remove due to race condition in venus_probe, core->work is bound with venus_sys_error_handler, which is used to handle error. The code use core->sys_err_done to make sync work. The core->work is started in venus_event_notify. If we call venus_remove, there might be an unfished work. The possible sequence is as follows: CPU0 CPU1 |venus_sys_error_handler venus_remove | hfi_destroy\t \t\t | venus_hfi_destroy\t | kfree(hdev);\t | |hfi_reinit \t\t\t\t\t |venus_hfi_queues_reinit |//use hdev Fix it by canceling the work in venus_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49956", "url": "https://ubuntu.com/security/CVE-2024-49956", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gfs2: fix double destroy_workqueue error When gfs2_fill_super() fails, destroy_workqueue() is called within gfs2_gl_hash_clear(), and the subsequent code path calls destroy_workqueue() on the same work queue again. This issue can be fixed by setting the work queue pointer to NULL after the first destroy_workqueue() call and checking for a NULL pointer before attempting to destroy the work queue again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50176", "url": "https://ubuntu.com/security/CVE-2024-50176", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: remoteproc: k3-r5: Fix error handling when power-up failed By simply bailing out, the driver was violating its rule and internal assumptions that either both or no rproc should be initialized. E.g., this could cause the first core to be available but not the second one, leading to crashes on its shutdown later on while trying to dereference that second instance.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49982", "url": "https://ubuntu.com/security/CVE-2024-49982", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: aoe: fix the potential use-after-free problem in more places For fixing CVE-2023-6270, f98364e92662 (\"aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts\") makes tx() calling dev_put() instead of doing in aoecmd_cfg_pkts(). It avoids that the tx() runs into use-after-free. Then Nicolai Stange found more places in aoe have potential use-after-free problem with tx(). e.g. revalidate(), aoecmd_ata_rw(), resend(), probe() and aoecmd_cfg_rsp(). Those functions also use aoenet_xmit() to push packet to tx queue. So they should also use dev_hold() to increase the refcnt of skb->dev. On the other hand, moving dev_put() to tx() causes that the refcnt of skb->dev be reduced to a negative value, because corresponding dev_hold() are not called in revalidate(), aoecmd_ata_rw(), resend(), probe(), and aoecmd_cfg_rsp(). This patch fixed this issue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49874", "url": "https://ubuntu.com/security/CVE-2024-49874", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i3c: master: svc: Fix use after free vulnerability in svc_i3c_master Driver Due to Race Condition In the svc_i3c_master_probe function, &master->hj_work is bound with svc_i3c_master_hj_work, &master->ibi_work is bound with svc_i3c_master_ibi_work. And svc_i3c_master_ibi_work can start the hj_work, svc_i3c_master_irq_handler can start the ibi_work. If we remove the module which will call svc_i3c_master_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | svc_i3c_master_hj_work svc_i3c_master_remove | i3c_master_unregister(&master->base)| device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in svc_i3c_master_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49875", "url": "https://ubuntu.com/security/CVE-2024-49875", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: map the EBADMSG to nfserr_io to avoid warning Ext4 will throw -EBADMSG through ext4_readdir when a checksum error occurs, resulting in the following WARNING. Fix it by mapping EBADMSG to nfserr_io. nfsd_buffered_readdir iterate_dir // -EBADMSG -74 ext4_readdir // .iterate_shared ext4_dx_readdir ext4_htree_fill_tree htree_dirblock_to_tree ext4_read_dirblock __ext4_read_dirblock ext4_dirblock_csum_verify warn_no_space_for_csum __warn_no_space_for_csum return ERR_PTR(-EFSBADCRC) // -EBADMSG -74 nfserrno // WARNING [ 161.115610] ------------[ cut here ]------------ [ 161.116465] nfsd: non-standard errno: -74 [ 161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0 [ 161.118596] Modules linked in: [ 161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138 [ 161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qe mu.org 04/01/2014 [ 161.123601] RIP: 0010:nfserrno+0x9d/0xd0 [ 161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6 05 ce 2b 61 03 01 e8 99 20 d8 00 <0f> 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33 [ 161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286 [ 161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a [ 161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827 [ 161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021 [ 161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8 [ 161.135244] FS: 0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000 [ 161.136695] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0 [ 161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 161.141519] PKRU: 55555554 [ 161.142076] Call Trace: [ 161.142575] ? __warn+0x9b/0x140 [ 161.143229] ? nfserrno+0x9d/0xd0 [ 161.143872] ? report_bug+0x125/0x150 [ 161.144595] ? handle_bug+0x41/0x90 [ 161.145284] ? exc_invalid_op+0x14/0x70 [ 161.146009] ? asm_exc_invalid_op+0x12/0x20 [ 161.146816] ? nfserrno+0x9d/0xd0 [ 161.147487] nfsd_buffered_readdir+0x28b/0x2b0 [ 161.148333] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.149258] ? nfsd_buffered_filldir+0xf0/0xf0 [ 161.150093] ? wait_for_concurrent_writes+0x170/0x170 [ 161.151004] ? generic_file_llseek_size+0x48/0x160 [ 161.151895] nfsd_readdir+0x132/0x190 [ 161.152606] ? nfsd4_encode_dirent_fattr+0x380/0x380 [ 161.153516] ? nfsd_unlink+0x380/0x380 [ 161.154256] ? override_creds+0x45/0x60 [ 161.155006] nfsd4_encode_readdir+0x21a/0x3d0 [ 161.155850] ? nfsd4_encode_readlink+0x210/0x210 [ 161.156731] ? write_bytes_to_xdr_buf+0x97/0xe0 [ 161.157598] ? __write_bytes_to_xdr_buf+0xd0/0xd0 [ 161.158494] ? lock_downgrade+0x90/0x90 [ 161.159232] ? nfs4svc_decode_voidarg+0x10/0x10 [ 161.160092] nfsd4_encode_operation+0x15a/0x440 [ 161.160959] nfsd4_proc_compound+0x718/0xe90 [ 161.161818] nfsd_dispatch+0x18e/0x2c0 [ 161.162586] svc_process_common+0x786/0xc50 [ 161.163403] ? nfsd_svc+0x380/0x380 [ 161.164137] ? svc_printk+0x160/0x160 [ 161.164846] ? svc_xprt_do_enqueue.part.0+0x365/0x380 [ 161.165808] ? nfsd_svc+0x380/0x380 [ 161.166523] ? rcu_is_watching+0x23/0x40 [ 161.167309] svc_process+0x1a5/0x200 [ 161.168019] nfsd+0x1f5/0x380 [ 161.168663] ? nfsd_shutdown_threads+0x260/0x260 [ 161.169554] kthread+0x1c4/0x210 [ 161.170224] ? kthread_insert_work_sanity_check+0x80/0x80 [ 161.171246] ret_from_fork+0x1f/0x30", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50013", "url": "https://ubuntu.com/security/CVE-2024-50013", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: fix memory leak in exfat_load_bitmap() If the first directory entry in the root directory is not a bitmap directory entry, 'bh' will not be released and reassigned, which will cause a memory leak.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49876", "url": "https://ubuntu.com/security/CVE-2024-49876", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: fix UAF around queue destruction We currently do stuff like queuing the final destruction step on a random system wq, which will outlive the driver instance. With bad timing we can teardown the driver with one or more work workqueue still being alive leading to various UAF splats. Add a fini step to ensure user queues are properly torn down. At this point GuC should already be nuked so queue itself should no longer be referenced from hw pov. v2 (Matt B) - Looks much safer to use a waitqueue and then just wait for the xa_array to become empty before triggering the drain. (cherry picked from commit 861108666cc0e999cffeab6aff17b662e68774e3)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49877", "url": "https://ubuntu.com/security/CVE-2024-49877", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate When doing cleanup, if flags without OCFS2_BH_READAHEAD, it may trigger NULL pointer dereference in the following ocfs2_set_buffer_uptodate() if bh is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49957", "url": "https://ubuntu.com/security/CVE-2024-49957", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix null-ptr-deref when journal load failed. During the mounting process, if journal_reset() fails because of too short journal, then lead to jbd2_journal_load() fails with NULL j_sb_buffer. Subsequently, ocfs2_journal_shutdown() calls jbd2_journal_flush()->jbd2_cleanup_journal_tail()-> __jbd2_update_log_tail()->jbd2_journal_update_sb_log_tail() ->lock_buffer(journal->j_sb_buffer), resulting in a null-pointer dereference error. To resolve this issue, we should check the JBD2_LOADED flag to ensure the journal was properly loaded. Additionally, use journal instead of osb->journal directly to simplify the code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49965", "url": "https://ubuntu.com/security/CVE-2024-49965", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: remove unreasonable unlock in ocfs2_read_blocks Patch series \"Misc fixes for ocfs2_read_blocks\", v5. This series contains 2 fixes for ocfs2_read_blocks(). The first patch fix the issue reported by syzbot, which detects bad unlock balance in ocfs2_read_blocks(). The second patch fixes an issue reported by Heming Zhao when reviewing above fix. This patch (of 2): There was a lock release before exiting, so remove the unreasonable unlock.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49966", "url": "https://ubuntu.com/security/CVE-2024-49966", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: cancel dqi_sync_work before freeing oinfo ocfs2_global_read_info() will initialize and schedule dqi_sync_work at the end, if error occurs after successfully reading global quota, it will trigger the following warning with CONFIG_DEBUG_OBJECTS_* enabled: ODEBUG: free active (active state 0) object: 00000000d8b0ce28 object type: timer_list hint: qsync_work_fn+0x0/0x16c This reports that there is an active delayed work when freeing oinfo in error handling, so cancel dqi_sync_work first. BTW, return status instead of -1 when .read_file_info fails.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49958", "url": "https://ubuntu.com/security/CVE-2024-49958", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: reserve space for inline xattr before attaching reflink tree One of our customers reported a crash and a corrupted ocfs2 filesystem. The crash was due to the detection of corruption. Upon troubleshooting, the fsck -fn output showed the below corruption [EXTENT_LIST_FREE] Extent list in owner 33080590 claims 230 as the next free chain record, but fsck believes the largest valid value is 227. Clamp the next record value? n The stat output from the debugfs.ocfs2 showed the following corruption where the \"Next Free Rec:\" had overshot the \"Count:\" in the root metadata block. Inode: 33080590 Mode: 0640 Generation: 2619713622 (0x9c25a856) FS Generation: 904309833 (0x35e6ac49) CRC32: 00000000 ECC: 0000 Type: Regular Attr: 0x0 Flags: Valid Dynamic Features: (0x16) HasXattr InlineXattr Refcounted Extended Attributes Block: 0 Extended Attributes Inline Size: 256 User: 0 (root) Group: 0 (root) Size: 281320357888 Links: 1 Clusters: 141738 ctime: 0x66911b56 0x316edcb8 -- Fri Jul 12 06:02:30.829349048 2024 atime: 0x66911d6b 0x7f7a28d -- Fri Jul 12 06:11:23.133669517 2024 mtime: 0x66911b56 0x12ed75d7 -- Fri Jul 12 06:02:30.317552087 2024 dtime: 0x0 -- Wed Dec 31 17:00:00 1969 Refcount Block: 2777346 Last Extblk: 2886943 Orphan Slot: 0 Sub Alloc Slot: 0 Sub Alloc Bit: 14 Tree Depth: 1 Count: 227 Next Free Rec: 230 ## Offset Clusters Block# 0 0 2310 2776351 1 2310 2139 2777375 2 4449 1221 2778399 3 5670 731 2779423 4 6401 566 2780447 ....... .... ....... ....... .... ....... The issue was in the reflink workfow while reserving space for inline xattr. The problematic function is ocfs2_reflink_xattr_inline(). By the time this function is called the reflink tree is already recreated at the destination inode from the source inode. At this point, this function reserves space for inline xattrs at the destination inode without even checking if there is space at the root metadata block. It simply reduces the l_count from 243 to 227 thereby making space of 256 bytes for inline xattr whereas the inode already has extents beyond this index (in this case up to 230), thereby causing corruption. The fix for this is to reserve space for inline metadata at the destination inode before the reflink tree gets recreated. The customer has verified the fix.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49959", "url": "https://ubuntu.com/security/CVE-2024-49959", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error In __jbd2_log_wait_for_space(), we might call jbd2_cleanup_journal_tail() to recover some journal space. But if an error occurs while executing jbd2_cleanup_journal_tail() (e.g., an EIO), we don't stop waiting for free space right away, we try other branches, and if j_committing_transaction is NULL (i.e., the tid is 0), we will get the following complain: ============================================ JBD2: I/O error when updating journal superblock for sdd-8. __jbd2_log_wait_for_space: needed 256 blocks and only had 217 space available __jbd2_log_wait_for_space: no way to get more journal space in sdd-8 ------------[ cut here ]------------ WARNING: CPU: 2 PID: 139804 at fs/jbd2/checkpoint.c:109 __jbd2_log_wait_for_space+0x251/0x2e0 Modules linked in: CPU: 2 PID: 139804 Comm: kworker/u8:3 Not tainted 6.6.0+ #1 RIP: 0010:__jbd2_log_wait_for_space+0x251/0x2e0 Call Trace: add_transaction_credits+0x5d1/0x5e0 start_this_handle+0x1ef/0x6a0 jbd2__journal_start+0x18b/0x340 ext4_dirty_inode+0x5d/0xb0 __mark_inode_dirty+0xe4/0x5d0 generic_update_time+0x60/0x70 [...] ============================================ So only if jbd2_cleanup_journal_tail() returns 1, i.e., there is nothing to clean up at the moment, continue to try to reclaim free space in other ways. Note that this fix relies on commit 6f6a6fda2945 (\"jbd2: fix ocfs2 corrupt when updating journal superblock fails\") to make jbd2_cleanup_journal_tail return the correct error code.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49878", "url": "https://ubuntu.com/security/CVE-2024-49878", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: resource: fix region_intersects() vs add_memory_driver_managed() On a system with CXL memory, the resource tree (/proc/iomem) related to CXL memory may look like something as follows. 490000000-50fffffff : CXL Window 0 490000000-50fffffff : region0 490000000-50fffffff : dax0.0 490000000-50fffffff : System RAM (kmem) Because drivers/dax/kmem.c calls add_memory_driver_managed() during onlining CXL memory, which makes \"System RAM (kmem)\" a descendant of \"CXL Window X\". This confuses region_intersects(), which expects all \"System RAM\" resources to be at the top level of iomem_resource. This can lead to bugs. For example, when the following command line is executed to write some memory in CXL memory range via /dev/mem, $ dd if=data of=/dev/mem bs=$((1 << 10)) seek=$((0x490000000 >> 10)) count=1 dd: error writing '/dev/mem': Bad address 1+0 records in 0+0 records out 0 bytes copied, 0.0283507 s, 0.0 kB/s the command fails as expected. However, the error code is wrong. It should be \"Operation not permitted\" instead of \"Bad address\". More seriously, the /dev/mem permission checking in devmem_is_allowed() passes incorrectly. Although the accessing is prevented later because ioremap() isn't allowed to map system RAM, it is a potential security issue. During command executing, the following warning is reported in the kernel log for calling ioremap() on system RAM. ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d Call Trace: memremap+0xcb/0x184 xlate_dev_mem_ptr+0x25/0x2f write_mem+0x94/0xfb vfs_write+0x128/0x26d ksys_write+0xac/0xfe do_syscall_64+0x9a/0xfd entry_SYSCALL_64_after_hwframe+0x4b/0x53 The details of command execution process are as follows. In the above resource tree, \"System RAM\" is a descendant of \"CXL Window 0\" instead of a top level resource. So, region_intersects() will report no System RAM resources in the CXL memory region incorrectly, because it only checks the top level resources. Consequently, devmem_is_allowed() will return 1 (allow access via /dev/mem) for CXL memory region incorrectly. Fortunately, ioremap() doesn't allow to map System RAM and reject the access. So, region_intersects() needs to be fixed to work correctly with the resource tree with \"System RAM\" not at top level as above. To fix it, if we found a unmatched resource in the top level, we will continue to search matched resources in its descendant resources. So, we will not miss any matched resources in resource tree anymore. In the new implementation, an example resource tree |------------- \"CXL Window 0\" ------------| |-- \"System RAM\" --| will behave similar as the following fake resource tree for region_intersects(, IORESOURCE_SYSTEM_RAM, ), |-- \"System RAM\" --||-- \"CXL Window 0a\" --| Where \"CXL Window 0a\" is part of the original \"CXL Window 0\" that isn't covered by \"System RAM\".", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49879", "url": "https://ubuntu.com/security/CVE-2024-49879", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm: omapdrm: Add missing check for alloc_ordered_workqueue As it may return NULL pointer and cause NULL pointer dereference. Add check for the return value of alloc_ordered_workqueue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49880", "url": "https://ubuntu.com/security/CVE-2024-49880", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix off by one issue in alloc_flex_gd() Wesley reported an issue: ================================================================== EXT4-fs (dm-5): resizing filesystem from 7168 to 786432 blocks ------------[ cut here ]------------ kernel BUG at fs/ext4/resize.c:324! CPU: 9 UID: 0 PID: 3576 Comm: resize2fs Not tainted 6.11.0+ #27 RIP: 0010:ext4_resize_fs+0x1212/0x12d0 Call Trace: __ext4_ioctl+0x4e0/0x1800 ext4_ioctl+0x12/0x20 __x64_sys_ioctl+0x99/0xd0 x64_sys_call+0x1206/0x20d0 do_syscall_64+0x72/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e ================================================================== While reviewing the patch, Honza found that when adjusting resize_bg in alloc_flex_gd(), it was possible for flex_gd->resize_bg to be bigger than flexbg_size. The reproduction of the problem requires the following: o_group = flexbg_size * 2 * n; o_size = (o_group + 1) * group_size; n_group: [o_group + flexbg_size, o_group + flexbg_size * 2) o_size = (n_group + 1) * group_size; Take n=0,flexbg_size=16 as an example: last:15 |o---------------|--------------n-| o_group:0 resize to n_group:30 The corresponding reproducer is: img=test.img rm -f $img truncate -s 600M $img mkfs.ext4 -F $img -b 1024 -G 16 8M dev=`losetup -f --show $img` mkdir -p /tmp/test mount $dev /tmp/test resize2fs $dev 248M Delete the problematic plus 1 to fix the issue, and add a WARN_ON_ONCE() to prevent the issue from happening again. [ Note: another reproucer which this commit fixes is: img=test.img rm -f $img truncate -s 25MiB $img mkfs.ext4 -b 4096 -E nodiscard,lazy_itable_init=0,lazy_journal_init=0 $img truncate -s 3GiB $img dev=`losetup -f --show $img` mkdir -p /tmp/test mount $dev /tmp/test resize2fs $dev 3G umount $dev losetup -d $dev -- TYT ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49881", "url": "https://ubuntu.com/security/CVE-2024-49881", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: update orig_path in ext4_find_extent() In ext4_find_extent(), if the path is not big enough, we free it and set *orig_path to NULL. But after reallocating and successfully initializing the path, we don't update *orig_path, in which case the caller gets a valid path but a NULL ppath, and this may cause a NULL pointer dereference or a path memory leak. For example: ext4_split_extent path = *ppath = 2000 ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path = 2000); *orig_path = path = NULL; path = kcalloc() = 3000 ext4_split_extent_at(*ppath = NULL) path = *ppath; ex = path[depth].p_ext; // NULL pointer dereference! ================================================================== BUG: kernel NULL pointer dereference, address: 0000000000000010 CPU: 6 UID: 0 PID: 576 Comm: fsstress Not tainted 6.11.0-rc2-dirty #847 RIP: 0010:ext4_split_extent_at+0x6d/0x560 Call Trace: ext4_split_extent.isra.0+0xcb/0x1b0 ext4_ext_convert_to_initialized+0x168/0x6c0 ext4_ext_handle_unwritten_extents+0x325/0x4d0 ext4_ext_map_blocks+0x520/0xdb0 ext4_map_blocks+0x2b0/0x690 ext4_iomap_begin+0x20e/0x2c0 [...] ================================================================== Therefore, *orig_path is updated when the extent lookup succeeds, so that the caller can safely use path or *ppath.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50014", "url": "https://ubuntu.com/security/CVE-2024-50014", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix access to uninitialised lock in fc replay path The following kernel trace can be triggered with fstest generic/629 when executed against a filesystem with fast-commit feature enabled: INFO: trying to register non-static key. The code is fine but needs lockdep annotation, or maybe you didn't initialize this object before use? turning off the locking correctness validator. CPU: 0 PID: 866 Comm: mount Not tainted 6.10.0+ #11 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014 Call Trace: dump_stack_lvl+0x66/0x90 register_lock_class+0x759/0x7d0 __lock_acquire+0x85/0x2630 ? __find_get_block+0xb4/0x380 lock_acquire+0xd1/0x2d0 ? __ext4_journal_get_write_access+0xd5/0x160 _raw_spin_lock+0x33/0x40 ? __ext4_journal_get_write_access+0xd5/0x160 __ext4_journal_get_write_access+0xd5/0x160 ext4_reserve_inode_write+0x61/0xb0 __ext4_mark_inode_dirty+0x79/0x270 ? ext4_ext_replay_set_iblocks+0x2f8/0x450 ext4_ext_replay_set_iblocks+0x330/0x450 ext4_fc_replay+0x14c8/0x1540 ? jread+0x88/0x2e0 ? rcu_is_watching+0x11/0x40 do_one_pass+0x447/0xd00 jbd2_journal_recover+0x139/0x1b0 jbd2_journal_load+0x96/0x390 ext4_load_and_init_journal+0x253/0xd40 ext4_fill_super+0x2cc6/0x3180 ... In the replay path there's an attempt to lock sbi->s_bdev_wb_lock in function ext4_check_bdev_write_error(). Unfortunately, at this point this spinlock has not been initialized yet. Moving it's initialization to an earlier point in __ext4_fill_super() fixes this splat.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49960", "url": "https://ubuntu.com/security/CVE-2024-49960", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix timer use-after-free on failed mount Syzbot has found an ODEBUG bug in ext4_fill_super The del_timer_sync function cancels the s_err_report timer, which reminds about filesystem errors daily. We should guarantee the timer is no longer active before kfree(sbi). When filesystem mounting fails, the flow goes to failed_mount3, where an error occurs when ext4_stop_mmpd is called, causing a read I/O failure. This triggers the ext4_handle_error function that ultimately re-arms the timer, leaving the s_err_report timer active before kfree(sbi) is called. Fix the issue by canceling the s_err_report timer after calling ext4_stop_mmpd.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49882", "url": "https://ubuntu.com/security/CVE-2024-49882", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix double brelse() the buffer of the extents path In ext4_ext_try_to_merge_up(), set path[1].p_bh to NULL after it has been released, otherwise it may be released twice. An example of what triggers this is as follows: split2 map split1 |--------|-------|--------| ext4_ext_map_blocks ext4_ext_handle_unwritten_extents ext4_split_convert_extents // path->p_depth == 0 ext4_split_extent // 1. do split1 ext4_split_extent_at |ext4_ext_insert_extent | ext4_ext_create_new_leaf | ext4_ext_grow_indepth | le16_add_cpu(&neh->eh_depth, 1) | ext4_find_extent | // return -ENOMEM |// get error and try zeroout |path = ext4_find_extent | path->p_depth = 1 |ext4_ext_try_to_merge | ext4_ext_try_to_merge_up | path->p_depth = 0 | brelse(path[1].p_bh) ---> not set to NULL here |// zeroout success // 2. update path ext4_find_extent // 3. do split2 ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth le16_add_cpu(&neh->eh_depth, 1) ext4_find_extent path[0].p_bh = NULL; path->p_depth = 1 read_extent_tree_block ---> return err // path[1].p_bh is still the old value ext4_free_ext_path ext4_ext_drop_refs // path->p_depth == 1 brelse(path[1].p_bh) ---> brelse a buffer twice Finally got the following WARRNING when removing the buffer from lru: ============================================ VFS: brelse: Trying to free free buffer WARNING: CPU: 2 PID: 72 at fs/buffer.c:1241 __brelse+0x58/0x90 CPU: 2 PID: 72 Comm: kworker/u19:1 Not tainted 6.9.0-dirty #716 RIP: 0010:__brelse+0x58/0x90 Call Trace: __find_get_block+0x6e7/0x810 bdev_getblk+0x2b/0x480 __ext4_get_inode_loc+0x48a/0x1240 ext4_get_inode_loc+0xb2/0x150 ext4_reserve_inode_write+0xb7/0x230 __ext4_mark_inode_dirty+0x144/0x6a0 ext4_ext_insert_extent+0x9c8/0x3230 ext4_ext_map_blocks+0xf45/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] ============================================", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49883", "url": "https://ubuntu.com/security/CVE-2024-49883", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: aovid use-after-free in ext4_ext_insert_extent() As Ojaswin mentioned in Link, in ext4_ext_insert_extent(), if the path is reallocated in ext4_ext_create_new_leaf(), we'll use the stale path and cause UAF. Below is a sample trace with dummy values: ext4_ext_insert_extent path = *ppath = 2000 ext4_ext_create_new_leaf(ppath) ext4_find_extent(ppath) path = *ppath = 2000 if (depth > path[0].p_maxdepth) kfree(path = 2000); *ppath = path = NULL; path = kcalloc() = 3000 *ppath = 3000; return path; /* here path is still 2000, UAF! */ eh = path[depth].p_hdr ================================================================== BUG: KASAN: slab-use-after-free in ext4_ext_insert_extent+0x26d4/0x3330 Read of size 8 at addr ffff8881027bf7d0 by task kworker/u36:1/179 CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 Not tainted 6.11.0-rc2-dirty #866 Call Trace: ext4_ext_insert_extent+0x26d4/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 [...] Allocated by task 179: ext4_find_extent+0x81c/0x1f70 ext4_ext_map_blocks+0x146/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...] Freed by task 179: kfree+0xcb/0x240 ext4_find_extent+0x7c0/0x1f70 ext4_ext_insert_extent+0xa26/0x3330 ext4_ext_map_blocks+0xe22/0x2d40 ext4_map_blocks+0x71e/0x1700 ext4_do_writepages+0x1290/0x2800 ext4_writepages+0x26d/0x4e0 do_writepages+0x175/0x700 [...] ================================================================== So use *ppath to update the path to avoid the above problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49983", "url": "https://ubuntu.com/security/CVE-2024-49983", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-free When calling ext4_force_split_extent_at() in ext4_ext_replay_update_ex(), the 'ppath' is updated but it is the 'path' that is freed, thus potentially triggering a double-free in the following process: ext4_ext_replay_update_ex ppath = path ext4_force_split_extent_at(&ppath) ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path) ---> path First freed *orig_path = path = NULL ---> null ppath kfree(path) ---> path double-free !!! So drop the unnecessary ppath and use path directly to avoid this problem. And use ext4_find_extent() directly to update path, avoiding unnecessary memory allocation and freeing. Also, propagate the error returned by ext4_find_extent() instead of using strange error codes.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50015", "url": "https://ubuntu.com/security/CVE-2024-50015", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: dax: fix overflowing extents beyond inode size when partially writing The dax_iomap_rw() does two things in each iteration: map written blocks and copy user data to blocks. If the process is killed by user(See signal handling in dax_iomap_iter()), the copied data will be returned and added on inode size, which means that the length of written extents may exceed the inode size, then fsck will fail. An example is given as: dd if=/dev/urandom of=file bs=4M count=1 dax_iomap_rw iomap_iter // round 1 ext4_iomap_begin ext4_iomap_alloc // allocate 0~2M extents(written flag) dax_iomap_iter // copy 2M data iomap_iter // round 2 iomap_iter_advance iter->pos += iter->processed // iter->pos = 2M ext4_iomap_begin ext4_iomap_alloc // allocate 2~4M extents(written flag) dax_iomap_iter fatal_signal_pending done = iter->pos - iocb->ki_pos // done = 2M ext4_handle_inode_extension ext4_update_inode_size // inode size = 2M fsck reports: Inode 13, i_size is 2097152, should be 4194304. Fix? Fix the problem by truncating extents if the written length is smaller than expected.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49884", "url": "https://ubuntu.com/security/CVE-2024-49884", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix slab-use-after-free in ext4_split_extent_at() We hit the following use-after-free: ================================================================== BUG: KASAN: slab-use-after-free in ext4_split_extent_at+0xba8/0xcc0 Read of size 2 at addr ffff88810548ed08 by task kworker/u20:0/40 CPU: 0 PID: 40 Comm: kworker/u20:0 Not tainted 6.9.0-dirty #724 Call Trace: kasan_report+0x93/0xc0 ext4_split_extent_at+0xba8/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] Allocated by task 40: __kmalloc_noprof+0x1ac/0x480 ext4_find_extent+0xf3b/0x1e70 ext4_ext_map_blocks+0x188/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] Freed by task 40: kfree+0xf1/0x2b0 ext4_find_extent+0xa71/0x1e70 ext4_ext_insert_extent+0xa22/0x3260 ext4_split_extent_at+0x3ef/0xcc0 ext4_split_extent.isra.0+0x18f/0x500 ext4_split_convert_extents+0x275/0x750 ext4_ext_handle_unwritten_extents+0x73e/0x1580 ext4_ext_map_blocks+0xe20/0x2dc0 ext4_map_blocks+0x724/0x1700 ext4_do_writepages+0x12d6/0x2a70 [...] ================================================================== The flow of issue triggering is as follows: ext4_split_extent_at path = *ppath ext4_ext_insert_extent(ppath) ext4_ext_create_new_leaf(ppath) ext4_find_extent(orig_path) path = *orig_path read_extent_tree_block // return -ENOMEM or -EIO ext4_free_ext_path(path) kfree(path) *orig_path = NULL a. If err is -ENOMEM: ext4_ext_dirty(path + path->p_depth) // path use-after-free !!! b. If err is -EIO and we have EXT_DEBUG defined: ext4_ext_show_leaf(path) eh = path[depth].p_hdr // path also use-after-free !!! So when trying to zeroout or fix the extent length, call ext4_find_extent() to update the path. In addition we use *ppath directly as an ext4_ext_show_leaf() input to avoid possible use-after-free when EXT_DEBUG is defined, and to avoid unnecessary path updates.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49885", "url": "https://ubuntu.com/security/CVE-2024-49885", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm, slub: avoid zeroing kmalloc redzone Since commit 946fa0dbf2d8 (\"mm/slub: extend redzone check to extra allocated kmalloc space than requested\"), setting orig_size treats the wasted space (object_size - orig_size) as a redzone. However with init_on_free=1 we clear the full object->size, including the redzone. Additionally we clear the object metadata, including the stored orig_size, making it zero, which makes check_object() treat the whole object as a redzone. These issues lead to the following BUG report with \"slub_debug=FUZ init_on_free=1\": [ 0.000000] ============================================================================= [ 0.000000] BUG kmalloc-8 (Not tainted): kmalloc Redzone overwritten [ 0.000000] ----------------------------------------------------------------------------- [ 0.000000] [ 0.000000] 0xffff000010032858-0xffff00001003285f @offset=2136. First byte 0x0 instead of 0xcc [ 0.000000] FIX kmalloc-8: Restoring kmalloc Redzone 0xffff000010032858-0xffff00001003285f=0xcc [ 0.000000] Slab 0xfffffdffc0400c80 objects=36 used=23 fp=0xffff000010032a18 flags=0x3fffe0000000200(workingset|node=0|zone=0|lastcpupid=0x1ffff) [ 0.000000] Object 0xffff000010032858 @offset=2136 fp=0xffff0000100328c8 [ 0.000000] [ 0.000000] Redzone ffff000010032850: cc cc cc cc cc cc cc cc ........ [ 0.000000] Object ffff000010032858: cc cc cc cc cc cc cc cc ........ [ 0.000000] Redzone ffff000010032860: cc cc cc cc cc cc cc cc ........ [ 0.000000] Padding ffff0000100328b4: 00 00 00 00 00 00 00 00 00 00 00 00 ............ [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.11.0-rc3-next-20240814-00004-g61844c55c3f4 #144 [ 0.000000] Hardware name: NXP i.MX95 19X19 board (DT) [ 0.000000] Call trace: [ 0.000000] dump_backtrace+0x90/0xe8 [ 0.000000] show_stack+0x18/0x24 [ 0.000000] dump_stack_lvl+0x74/0x8c [ 0.000000] dump_stack+0x18/0x24 [ 0.000000] print_trailer+0x150/0x218 [ 0.000000] check_object+0xe4/0x454 [ 0.000000] free_to_partial_list+0x2f8/0x5ec To address the issue, use orig_size to clear the used area. And restore the value of orig_size after clear the remaining area. When CONFIG_SLUB_DEBUG not defined, (get_orig_size()' directly returns s->object_size. So when using memset to init the area, the size can simply be orig_size, as orig_size returns object_size when CONFIG_SLUB_DEBUG not enabled. And orig_size can never be bigger than object_size.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49961", "url": "https://ubuntu.com/security/CVE-2024-49961", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: i2c: ar0521: Use cansleep version of gpiod_set_value() If we use GPIO reset from I2C port expander, we must use *_cansleep() variant of GPIO functions. This was not done in ar0521_power_on()/ar0521_power_off() functions. Let's fix that. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 11 at drivers/gpio/gpiolib.c:3496 gpiod_set_value+0x74/0x7c Modules linked in: CPU: 0 PID: 11 Comm: kworker/u16:0 Not tainted 6.10.0 #53 Hardware name: Diasom DS-RK3568-SOM-EVB (DT) Workqueue: events_unbound deferred_probe_work_func pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : gpiod_set_value+0x74/0x7c lr : ar0521_power_on+0xcc/0x290 sp : ffffff8001d7ab70 x29: ffffff8001d7ab70 x28: ffffff80027dcc90 x27: ffffff8003c82000 x26: ffffff8003ca9250 x25: ffffffc080a39c60 x24: ffffff8003ca9088 x23: ffffff8002402720 x22: ffffff8003ca9080 x21: ffffff8003ca9088 x20: 0000000000000000 x19: ffffff8001eb2a00 x18: ffffff80efeeac80 x17: 756d2d6332692f30 x16: 0000000000000000 x15: 0000000000000000 x14: ffffff8001d91d40 x13: 0000000000000016 x12: ffffffc080e98930 x11: ffffff8001eb2880 x10: 0000000000000890 x9 : ffffff8001d7a9f0 x8 : ffffff8001d92570 x7 : ffffff80efeeac80 x6 : 000000003fc6e780 x5 : ffffff8001d91c80 x4 : 0000000000000002 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000001 Call trace: gpiod_set_value+0x74/0x7c ar0521_power_on+0xcc/0x290 ...", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49985", "url": "https://ubuntu.com/security/CVE-2024-49985", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume In case there is any sort of clock controller attached to this I2C bus controller, for example Versaclock or even an AIC32x4 I2C codec, then an I2C transfer triggered from the clock controller clk_ops .prepare callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex. This is because the clock controller first grabs the prepare_lock mutex and then performs the prepare operation, including its I2C access. The I2C access resumes this I2C bus controller via .runtime_resume callback, which calls clk_prepare_enable(), which attempts to grab the prepare_lock mutex again and deadlocks. Since the clock are already prepared since probe() and unprepared in remove(), use simple clk_enable()/clk_disable() calls to enable and disable the clock on runtime suspend and resume, to avoid hitting the prepare_lock mutex.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49886", "url": "https://ubuntu.com/security/CVE-2024-49886", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bug Attaching SST PCI device to VM causes \"BUG: KASAN: slab-out-of-bounds\". kasan report: [ 19.411889] ================================================================== [ 19.413702] BUG: KASAN: slab-out-of-bounds in _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.415634] Read of size 8 at addr ffff888829e65200 by task cpuhp/16/113 [ 19.417368] [ 19.418627] CPU: 16 PID: 113 Comm: cpuhp/16 Tainted: G E 6.9.0 #10 [ 19.420435] Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.20192059.B64.2207280713 07/28/2022 [ 19.422687] Call Trace: [ 19.424091] [ 19.425448] dump_stack_lvl+0x5d/0x80 [ 19.426963] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.428694] print_report+0x19d/0x52e [ 19.430206] ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [ 19.431837] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.433539] kasan_report+0xf0/0x170 [ 19.435019] ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.436709] _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [ 19.438379] ? __pfx_sched_clock_cpu+0x10/0x10 [ 19.439910] isst_if_cpu_online+0x406/0x58f [isst_if_common] [ 19.441573] ? __pfx_isst_if_cpu_online+0x10/0x10 [isst_if_common] [ 19.443263] ? ttwu_queue_wakelist+0x2c1/0x360 [ 19.444797] cpuhp_invoke_callback+0x221/0xec0 [ 19.446337] cpuhp_thread_fun+0x21b/0x610 [ 19.447814] ? __pfx_cpuhp_thread_fun+0x10/0x10 [ 19.449354] smpboot_thread_fn+0x2e7/0x6e0 [ 19.450859] ? __pfx_smpboot_thread_fn+0x10/0x10 [ 19.452405] kthread+0x29c/0x350 [ 19.453817] ? __pfx_kthread+0x10/0x10 [ 19.455253] ret_from_fork+0x31/0x70 [ 19.456685] ? __pfx_kthread+0x10/0x10 [ 19.458114] ret_from_fork_asm+0x1a/0x30 [ 19.459573] [ 19.460853] [ 19.462055] Allocated by task 1198: [ 19.463410] kasan_save_stack+0x30/0x50 [ 19.464788] kasan_save_track+0x14/0x30 [ 19.466139] __kasan_kmalloc+0xaa/0xb0 [ 19.467465] __kmalloc+0x1cd/0x470 [ 19.468748] isst_if_cdev_register+0x1da/0x350 [isst_if_common] [ 19.470233] isst_if_mbox_init+0x108/0xff0 [isst_if_mbox_msr] [ 19.471670] do_one_initcall+0xa4/0x380 [ 19.472903] do_init_module+0x238/0x760 [ 19.474105] load_module+0x5239/0x6f00 [ 19.475285] init_module_from_file+0xd1/0x130 [ 19.476506] idempotent_init_module+0x23b/0x650 [ 19.477725] __x64_sys_finit_module+0xbe/0x130 [ 19.476506] idempotent_init_module+0x23b/0x650 [ 19.477725] __x64_sys_finit_module+0xbe/0x130 [ 19.478920] do_syscall_64+0x82/0x160 [ 19.480036] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 19.481292] [ 19.482205] The buggy address belongs to the object at ffff888829e65000 which belongs to the cache kmalloc-512 of size 512 [ 19.484818] The buggy address is located 0 bytes to the right of allocated 512-byte region [ffff888829e65000, ffff888829e65200) [ 19.487447] [ 19.488328] The buggy address belongs to the physical page: [ 19.489569] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888829e60c00 pfn:0x829e60 [ 19.491140] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [ 19.492466] anon flags: 0x57ffffc0000840(slab|head|node=1|zone=2|lastcpupid=0x1fffff) [ 19.493914] page_type: 0xffffffff() [ 19.494988] raw: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [ 19.496451] raw: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [ 19.497906] head: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [ 19.499379] head: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [ 19.500844] head: 0057ffffc0000003 ffffea0020a79801 ffffea0020a79848 00000000ffffffff [ 19.502316] head: 0000000800000000 0000000000000000 00000000ffffffff 0000000000000000 [ 19.503784] page dumped because: k ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49986", "url": "https://ubuntu.com/security/CVE-2024-49986", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: platform/x86: x86-android-tablets: Fix use after free on platform_device_register() errors x86_android_tablet_remove() frees the pdevs[] array, so it should not be used after calling x86_android_tablet_remove(). When platform_device_register() fails, store the pdevs[x] PTR_ERR() value into the local ret variable before calling x86_android_tablet_remove() to avoid using pdevs[] after it has been freed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49887", "url": "https://ubuntu.com/security/CVE-2024-49887", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to don't panic system for no free segment fault injection f2fs: fix to don't panic system for no free segment fault injection syzbot reports a f2fs bug as below: F2FS-fs (loop0): inject no free segment in get_new_segment of __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3167 F2FS-fs (loop0): Stopped filesystem due to reason: 7 ------------[ cut here ]------------ kernel BUG at fs/f2fs/segment.c:2748! CPU: 0 UID: 0 PID: 5109 Comm: syz-executor304 Not tainted 6.11.0-rc6-syzkaller-00363-g89f5e14d05b4 #0 RIP: 0010:get_new_segment fs/f2fs/segment.c:2748 [inline] RIP: 0010:new_curseg+0x1f61/0x1f70 fs/f2fs/segment.c:2836 Call Trace: __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3167 f2fs_allocate_new_section fs/f2fs/segment.c:3181 [inline] f2fs_allocate_pinning_section+0xfa/0x4e0 fs/f2fs/segment.c:3195 f2fs_expand_inode_data+0x5d6/0xbb0 fs/f2fs/file.c:1799 f2fs_fallocate+0x448/0x960 fs/f2fs/file.c:1903 vfs_fallocate+0x553/0x6c0 fs/open.c:334 do_vfs_ioctl+0x2592/0x2e50 fs/ioctl.c:886 __do_sys_ioctl fs/ioctl.c:905 [inline] __se_sys_ioctl+0x81/0x170 fs/ioctl.c:893 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: 0010:get_new_segment fs/f2fs/segment.c:2748 [inline] RIP: 0010:new_curseg+0x1f61/0x1f70 fs/f2fs/segment.c:2836 The root cause is when we inject no free segment fault into f2fs, we should not panic system, fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49888", "url": "https://ubuntu.com/security/CVE-2024-49888", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix a sdiv overflow issue Zac Ecob reported a problem where a bpf program may cause kernel crash due to the following error: Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI The failure is due to the below signed divide: LLONG_MIN/-1 where LLONG_MIN equals to -9,223,372,036,854,775,808. LLONG_MIN/-1 is supposed to give a positive number 9,223,372,036,854,775,808, but it is impossible since for 64-bit system, the maximum positive number is 9,223,372,036,854,775,807. On x86_64, LLONG_MIN/-1 will cause a kernel exception. On arm64, the result for LLONG_MIN/-1 is LLONG_MIN. Further investigation found all the following sdiv/smod cases may trigger an exception when bpf program is running on x86_64 platform: - LLONG_MIN/-1 for 64bit operation - INT_MIN/-1 for 32bit operation - LLONG_MIN%-1 for 64bit operation - INT_MIN%-1 for 32bit operation where -1 can be an immediate or in a register. On arm64, there are no exceptions: - LLONG_MIN/-1 = LLONG_MIN - INT_MIN/-1 = INT_MIN - LLONG_MIN%-1 = 0 - INT_MIN%-1 = 0 where -1 can be an immediate or in a register. Insn patching is needed to handle the above cases and the patched codes produced results aligned with above arm64 result. The below are pseudo codes to handle sdiv/smod exceptions including both divisor -1 and divisor 0 and the divisor is stored in a register. sdiv: tmp = rX tmp += 1 /* [-1, 0] -> [0, 1] if tmp >(unsigned) 1 goto L2 if tmp == 0 goto L1 rY = 0 L1: rY = -rY; goto L3 L2: rY /= rX L3: smod: tmp = rX tmp += 1 /* [-1, 0] -> [0, 1] if tmp >(unsigned) 1 goto L1 if tmp == 1 (is64 ? goto L2 : goto L3) rY = 0; goto L2 L1: rY %= rX L2: goto L4 // only when !is64 L3: wY = wY // only when !is64 L4: [1] https://lore.kernel.org/bpf/tPJLTEh7S_DxFEqAI2Ji5MBSoZVg7_G-Py2iaZpAaWtM961fFTWtsnlzwvTbzBzaUzwQAoNATXKUlt0LZOFgnDcIyKCswAnAGdUF3LBrhGQ=@protonmail.com/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49987", "url": "https://ubuntu.com/security/CVE-2024-49987", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpftool: Fix undefined behavior in qsort(NULL, 0, ...) When netfilter has no entry to display, qsort is called with qsort(NULL, 0, ...). This results in undefined behavior, as UBSan reports: net.c:827:2: runtime error: null pointer passed as argument 1, which is declared to never be null Although the C standard does not explicitly state whether calling qsort with a NULL pointer when the size is 0 constitutes undefined behavior, Section 7.1.4 of the C standard (Use of library functions) mentions: \"Each of the following statements applies unless explicitly stated otherwise in the detailed descriptions that follow: If an argument to a function has an invalid value (such as a value outside the domain of the function, or a pointer outside the address space of the program, or a null pointer, or a pointer to non-modifiable storage when the corresponding parameter is not const-qualified) or a type (after promotion) not expected by a function with variable number of arguments, the behavior is undefined.\" To avoid this, add an early return when nf_link_info is NULL to prevent calling qsort with a NULL pointer.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50006", "url": "https://ubuntu.com/security/CVE-2024-50006", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: fix i_data_sem unlock order in ext4_ind_migrate() Fuzzing reports a possible deadlock in jbd2_log_wait_commit. This issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to require synchronous updates because the file descriptor is opened with O_SYNC. This can lead to the jbd2_journal_stop() function calling jbd2_might_wait_for_commit(), potentially causing a deadlock if the EXT4_IOC_MIGRATE call races with a write(2) system call. This problem only arises when CONFIG_PROVE_LOCKING is enabled. In this case, the jbd2_might_wait_for_commit macro locks jbd2_handle in the jbd2_journal_stop function while i_data_sem is locked. This triggers lockdep because the jbd2_journal_start function might also lock the same jbd2_handle simultaneously. Found by Linux Verification Center (linuxtesting.org) with syzkaller. Rule: add", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49889", "url": "https://ubuntu.com/security/CVE-2024-49889", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid use-after-free in ext4_ext_show_leaf() In ext4_find_extent(), path may be freed by error or be reallocated, so using a previously saved *ppath may have been freed and thus may trigger use-after-free, as follows: ext4_split_extent path = *ppath; ext4_split_extent_at(ppath) path = ext4_find_extent(ppath) ext4_split_extent_at(ppath) // ext4_find_extent fails to free path // but zeroout succeeds ext4_ext_show_leaf(inode, path) eh = path[depth].p_hdr // path use-after-free !!! Similar to ext4_split_extent_at(), we use *ppath directly as an input to ext4_ext_show_leaf(). Fix a spelling error by the way. Same problem in ext4_ext_handle_unwritten_extents(). Since 'path' is only used in ext4_ext_show_leaf(), remove 'path' and use *ppath directly. This issue is triggered only when EXT_DEBUG is defined and therefore does not affect functionality.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49968", "url": "https://ubuntu.com/security/CVE-2024-49968", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: filesystems without casefold feature cannot be mounted with siphash When mounting the ext4 filesystem, if the default hash version is set to DX_HASH_SIPHASH but the casefold feature is not set, exit the mounting.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49988", "url": "https://ubuntu.com/security/CVE-2024-49988", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ksmbd: add refcnt to ksmbd_conn struct When sending an oplock break request, opinfo->conn is used, But freed ->conn can be used on multichannel. This patch add a reference count to the ksmbd_conn struct so that it can be freed when it is no longer used.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49890", "url": "https://ubuntu.com/security/CVE-2024-49890", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/pm: ensure the fw_info is not null before using it This resolves the dereference null return value warning reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49891", "url": "https://ubuntu.com/security/CVE-2024-49891", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata paths When the HBA is undergoing a reset or is handling an errata event, NULL ptr dereference crashes may occur in routines such as lpfc_sli_flush_io_rings(), lpfc_dev_loss_tmo_callbk(), or lpfc_abort_handler(). Add NULL ptr checks before dereferencing hdwq pointers that may have been freed due to operations colliding with a reset or errata event handler.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49892", "url": "https://ubuntu.com/security/CVE-2024-49892", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize get_bytes_per_element's default to 1 Variables, used as denominators and maybe not assigned to other values, should not be 0. bytes_per_element_y & bytes_per_element_c are initialized by get_bytes_per_element() which should never return 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50016", "url": "https://ubuntu.com/security/CVE-2024-50016", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Avoid overflow assignment in link_dp_cts sampling_rate is an uint8_t but is assigned an unsigned int, and thus it can overflow. As a result, sampling_rate is changed to uint32_t. Similarly, LINK_QUAL_PATTERN_SET has a size of 2 bits, and it should only be assigned to a value less or equal than 4. This fixes 2 INTEGER_OVERFLOW issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49893", "url": "https://ubuntu.com/security/CVE-2024-49893", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check stream_status before it is used [WHAT & HOW] dc_state_get_stream_status can return null, and therefore null must be checked before stream_status is used. This fixes 1 NULL_RETURNS issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49969", "url": "https://ubuntu.com/security/CVE-2024-49969", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 color transformation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_hw_format` function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:180 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:181 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:182 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49970", "url": "https://ubuntu.com/security/CVE-2024-49970", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Implement bounds check for stream encoder creation in DCN401 'stream_enc_regs' array is an array of dcn10_stream_enc_registers structures. The array is initialized with four elements, corresponding to the four calls to stream_enc_regs() in the array initializer. This means that valid indices for this array are 0, 1, 2, and 3. The error message 'stream_enc_regs' 4 <= 5 below, is indicating that there is an attempt to access this array with an index of 5, which is out of bounds. This could lead to undefined behavior Here, eng_id is used as an index to access the stream_enc_regs array. If eng_id is 5, this would result in an out-of-bounds access on the stream_enc_regs array. Thus fixing Buffer overflow error in dcn401_stream_encoder_create Found by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn401/dcn401_resource.c:1209 dcn401_stream_encoder_create() error: buffer overflow 'stream_enc_regs' 4 <= 5", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49894", "url": "https://ubuntu.com/security/CVE-2024-49894", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in degamma hardware format translation Fixes index out of bounds issue in `cm_helper_translate_curve_to_degamma_hw_format` function. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:594 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:595 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:596 cm_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49895", "url": "https://ubuntu.com/security/CVE-2024-49895", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format translation This commit addresses a potential index out of bounds issue in the `cm3_helper_translate_curve_to_degamma_hw_format` function in the DCN30 color management module. The issue could occur when the index 'i' exceeds the number of transfer function points (TRANSFER_FUNC_POINTS). The fix adds a check to ensure 'i' is within bounds before accessing the transfer function points. If 'i' is out of bounds, the function returns false to indicate an error. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:338 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:339 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:340 cm3_helper_translate_curve_to_degamma_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49971", "url": "https://ubuntu.com/security/CVE-2024-49971", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Increase array size of dummy_boolean [WHY] dml2_core_shared_mode_support and dml_core_mode_support access the third element of dummy_boolean, i.e. hw_debug5 = &s->dummy_boolean[2], when dummy_boolean has size of 2. Any assignment to hw_debug5 causes an OVERRUN. [HOW] Increase dummy_boolean's array size to 3. This fixes 2 OVERRUN issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49972", "url": "https://ubuntu.com/security/CVE-2024-49972", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Deallocate DML memory if allocation fails [Why] When DC state create DML memory allocation fails, memory is not deallocated subsequently, resulting in uninitialized structure that is not NULL. [How] Deallocate memory if DML memory allocation fails.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49896", "url": "https://ubuntu.com/security/CVE-2024-49896", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check stream before comparing them [WHAT & HOW] amdgpu_dm can pass a null stream to dc_is_stream_unchanged. It is necessary to check for null before dereferencing them. This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49897", "url": "https://ubuntu.com/security/CVE-2024-49897", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check phantom_stream before it is used dcn32_enable_phantom_stream can return null, so returned value must be checked before used. This fixes 1 NULL_RETURNS issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49898", "url": "https://ubuntu.com/security/CVE-2024-49898", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null-initialized variables [WHAT & HOW] drr_timing and subvp_pipe are initialized to null and they are not always assigned new values. It is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49899", "url": "https://ubuntu.com/security/CVE-2024-49899", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Initialize denominators' default to 1 [WHAT & HOW] Variables used as denominators and maybe not assigned to other values, should not be 0. Change their default to 1 so they are never 0. This fixes 10 DIVIDE_BY_ZERO issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49900", "url": "https://ubuntu.com/security/CVE-2024-49900", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uninit-value access of new_ea in ea_buffer syzbot reports that lzo1x_1_do_compress is using uninit-value: ===================================================== BUG: KMSAN: uninit-value in lzo1x_1_do_compress+0x19f9/0x2510 lib/lzo/lzo1x_compress.c:178 ... Uninit was stored to memory at: ea_put fs/jfs/xattr.c:639 [inline] ... Local variable ea_buf created at: __jfs_setxattr+0x5d/0x1ae0 fs/jfs/xattr.c:662 __jfs_xattr_set+0xe6/0x1f0 fs/jfs/xattr.c:934 ===================================================== The reason is ea_buf->new_ea is not initialized properly. Fix this by using memset to empty its content at the beginning in ea_get().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49901", "url": "https://ubuntu.com/security/CVE-2024-49901", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/msm/adreno: Assign msm_gpu->pdev earlier to avoid nullptrs There are some cases, such as the one uncovered by Commit 46d4efcccc68 (\"drm/msm/a6xx: Avoid a nullptr dereference when speedbin setting fails\") where msm_gpu_cleanup() : platform_set_drvdata(gpu->pdev, NULL); is called on gpu->pdev == NULL, as the GPU device has not been fully initialized yet. Turns out that there's more than just the aforementioned path that causes this to happen (e.g. the case when there's speedbin data in the catalog, but opp-supported-hw is missing in DT). Assigning msm_gpu->pdev earlier seems like the least painful solution to this, therefore do so. Patchwork: https://patchwork.freedesktop.org/patch/602742/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49902", "url": "https://ubuntu.com/security/CVE-2024-49902", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: check if leafidx greater than num leaves per dmap tree syzbot report a out of bounds in dbSplit, it because dmt_leafidx greater than num leaves per dmap tree, add a checking for dmt_leafidx in dbFindLeaf. Shaggy: Modified sanity check to apply to control pages as well as leaf pages.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49903", "url": "https://ubuntu.com/security/CVE-2024-49903", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: Fix uaf in dbFreeBits [syzbot reported] ================================================================== BUG: KASAN: slab-use-after-free in __mutex_lock_common kernel/locking/mutex.c:587 [inline] BUG: KASAN: slab-use-after-free in __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 Read of size 8 at addr ffff8880229254b0 by task syz-executor357/5216 CPU: 0 UID: 0 PID: 5216 Comm: syz-executor357 Not tainted 6.11.0-rc3-syzkaller-00156-gd7a5aa4b3c00 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 __mutex_lock_common kernel/locking/mutex.c:587 [inline] __mutex_lock+0xfe/0xd70 kernel/locking/mutex.c:752 dbFreeBits+0x7ea/0xd90 fs/jfs/jfs_dmap.c:2390 dbFreeDmap fs/jfs/jfs_dmap.c:2089 [inline] dbFree+0x35b/0x680 fs/jfs/jfs_dmap.c:409 dbDiscardAG+0x8a9/0xa20 fs/jfs/jfs_dmap.c:1650 jfs_ioc_trim+0x433/0x670 fs/jfs/jfs_discard.c:100 jfs_ioctl+0x2d0/0x3e0 fs/jfs/ioctl.c:131 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 Freed by task 5218: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579 poison_slab_object+0xe0/0x150 mm/kasan/common.c:240 __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2252 [inline] slab_free mm/slub.c:4473 [inline] kfree+0x149/0x360 mm/slub.c:4594 dbUnmount+0x11d/0x190 fs/jfs/jfs_dmap.c:278 jfs_mount_rw+0x4ac/0x6a0 fs/jfs/jfs_mount.c:247 jfs_remount+0x3d1/0x6b0 fs/jfs/super.c:454 reconfigure_super+0x445/0x880 fs/super.c:1083 vfs_cmd_reconfigure fs/fsopen.c:263 [inline] vfs_fsconfig_locked fs/fsopen.c:292 [inline] __do_sys_fsconfig fs/fsopen.c:473 [inline] __se_sys_fsconfig+0xb6e/0xf80 fs/fsopen.c:345 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 [Analysis] There are two paths (dbUnmount and jfs_ioc_trim) that generate race condition when accessing bmap, which leads to the occurrence of uaf. Use the lock s_umount to synchronize them, in order to avoid uaf caused by race condition.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49904", "url": "https://ubuntu.com/security/CVE-2024-49904", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu: add list empty check to avoid null pointer issue Add list empty check to avoid null pointer issues in some corner cases. - list_for_each_entry_safe()", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49989", "url": "https://ubuntu.com/security/CVE-2024-49989", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix double free issue during amdgpu module unload Flexible endpoints use DIGs from available inflexible endpoints, so only the encoders of inflexible links need to be freed. Otherwise, a double free issue may occur when unloading the amdgpu module. [ 279.190523] RIP: 0010:__slab_free+0x152/0x2f0 [ 279.190577] Call Trace: [ 279.190580] [ 279.190582] ? show_regs+0x69/0x80 [ 279.190590] ? die+0x3b/0x90 [ 279.190595] ? do_trap+0xc8/0xe0 [ 279.190601] ? do_error_trap+0x73/0xa0 [ 279.190605] ? __slab_free+0x152/0x2f0 [ 279.190609] ? exc_invalid_op+0x56/0x70 [ 279.190616] ? __slab_free+0x152/0x2f0 [ 279.190642] ? asm_exc_invalid_op+0x1f/0x30 [ 279.190648] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191096] ? __slab_free+0x152/0x2f0 [ 279.191102] ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191469] kfree+0x260/0x2b0 [ 279.191474] dcn10_link_encoder_destroy+0x19/0x30 [amdgpu] [ 279.191821] link_destroy+0xd7/0x130 [amdgpu] [ 279.192248] dc_destruct+0x90/0x270 [amdgpu] [ 279.192666] dc_destroy+0x19/0x40 [amdgpu] [ 279.193020] amdgpu_dm_fini+0x16e/0x200 [amdgpu] [ 279.193432] dm_hw_fini+0x26/0x40 [amdgpu] [ 279.193795] amdgpu_device_fini_hw+0x24c/0x400 [amdgpu] [ 279.194108] amdgpu_driver_unload_kms+0x4f/0x70 [amdgpu] [ 279.194436] amdgpu_pci_remove+0x40/0x80 [amdgpu] [ 279.194632] pci_device_remove+0x3a/0xa0 [ 279.194638] device_remove+0x40/0x70 [ 279.194642] device_release_driver_internal+0x1ad/0x210 [ 279.194647] driver_detach+0x4e/0xa0 [ 279.194650] bus_remove_driver+0x6f/0xf0 [ 279.194653] driver_unregister+0x33/0x60 [ 279.194657] pci_unregister_driver+0x44/0x90 [ 279.194662] amdgpu_exit+0x19/0x1f0 [amdgpu] [ 279.194939] __do_sys_delete_module.isra.0+0x198/0x2f0 [ 279.194946] __x64_sys_delete_module+0x16/0x20 [ 279.194950] do_syscall_64+0x58/0x120 [ 279.194954] entry_SYSCALL_64_after_hwframe+0x6e/0x76 [ 279.194980] ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49905", "url": "https://ubuntu.com/security/CVE-2024-49905", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for 'afb' in amdgpu_dm_plane_handle_cursor_update (v2) This commit adds a null check for the 'afb' variable in the amdgpu_dm_plane_handle_cursor_update function. Previously, 'afb' was assumed to be null, but was used later in the code without a null check. This could potentially lead to a null pointer dereference. Changes since v1: - Moved the null check for 'afb' to the line where 'afb' is used. (Alex) Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_plane.c:1298 amdgpu_dm_plane_handle_cursor_update() error: we previously assumed 'afb' could be null (see line 1252)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49906", "url": "https://ubuntu.com/security/CVE-2024-49906", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointer before try to access it [why & how] Change the order of the pipe_ctx->plane_state check to ensure that plane_state is not null before accessing it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49907", "url": "https://ubuntu.com/security/CVE-2024-49907", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before using dc->clk_mgr [WHY & HOW] dc->clk_mgr is null checked previously in the same function, indicating it might be null. Passing \"dc\" to \"dc->hwss.apply_idle_power_optimizations\", which dereferences null \"dc->clk_mgr\". (The function pointer resolves to \"dcn35_apply_idle_power_optimizations\".) This fixes 1 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49908", "url": "https://ubuntu.com/security/CVE-2024-49908", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for 'afb' in amdgpu_dm_update_cursor (v2) This commit adds a null check for the 'afb' variable in the amdgpu_dm_update_cursor function. Previously, 'afb' was assumed to be null at line 8388, but was used later in the code without a null check. This could potentially lead to a null pointer dereference. Changes since v1: - Moved the null check for 'afb' to the line where 'afb' is used. (Alex) Fixes the below: drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:8433 amdgpu_dm_update_cursor() \terror: we previously assumed 'afb' could be null (see line 8388)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50177", "url": "https://ubuntu.com/security/CVE-2024-50177", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fix a UBSAN warning in DML2.1 When programming phantom pipe, since cursor_width is explicity set to 0, this causes calculation logic to trigger overflow for an unsigned int triggering the kernel's UBSAN check as below: [ 40.962845] UBSAN: shift-out-of-bounds in /tmp/amd.EfpumTkO/amd/amdgpu/../display/dc/dml2/dml21/src/dml2_core/dml2_core_dcn4_calcs.c:3312:34 [ 40.962849] shift exponent 4294967170 is too large for 32-bit type 'unsigned int' [ 40.962852] CPU: 1 PID: 1670 Comm: gnome-shell Tainted: G W OE 6.5.0-41-generic #41~22.04.2-Ubuntu [ 40.962854] Hardware name: Gigabyte Technology Co., Ltd. X670E AORUS PRO X/X670E AORUS PRO X, BIOS F21 01/10/2024 [ 40.962856] Call Trace: [ 40.962857] [ 40.962860] dump_stack_lvl+0x48/0x70 [ 40.962870] dump_stack+0x10/0x20 [ 40.962872] __ubsan_handle_shift_out_of_bounds+0x1ac/0x360 [ 40.962878] calculate_cursor_req_attributes.cold+0x1b/0x28 [amdgpu] [ 40.963099] dml_core_mode_support+0x6b91/0x16bc0 [amdgpu] [ 40.963327] ? srso_alias_return_thunk+0x5/0x7f [ 40.963331] ? CalculateWatermarksMALLUseAndDRAMSpeedChangeSupport+0x18b8/0x2790 [amdgpu] [ 40.963534] ? srso_alias_return_thunk+0x5/0x7f [ 40.963536] ? dml_core_mode_support+0xb3db/0x16bc0 [amdgpu] [ 40.963730] dml2_core_calcs_mode_support_ex+0x2c/0x90 [amdgpu] [ 40.963906] ? srso_alias_return_thunk+0x5/0x7f [ 40.963909] ? dml2_core_calcs_mode_support_ex+0x2c/0x90 [amdgpu] [ 40.964078] core_dcn4_mode_support+0x72/0xbf0 [amdgpu] [ 40.964247] dml2_top_optimization_perform_optimization_phase+0x1d3/0x2a0 [amdgpu] [ 40.964420] dml2_build_mode_programming+0x23d/0x750 [amdgpu] [ 40.964587] dml21_validate+0x274/0x770 [amdgpu] [ 40.964761] ? srso_alias_return_thunk+0x5/0x7f [ 40.964763] ? resource_append_dpp_pipes_for_plane_composition+0x27c/0x3b0 [amdgpu] [ 40.964942] dml2_validate+0x504/0x750 [amdgpu] [ 40.965117] ? dml21_copy+0x95/0xb0 [amdgpu] [ 40.965291] ? srso_alias_return_thunk+0x5/0x7f [ 40.965295] dcn401_validate_bandwidth+0x4e/0x70 [amdgpu] [ 40.965491] update_planes_and_stream_state+0x38d/0x5c0 [amdgpu] [ 40.965672] update_planes_and_stream_v3+0x52/0x1e0 [amdgpu] [ 40.965845] ? srso_alias_return_thunk+0x5/0x7f [ 40.965849] dc_update_planes_and_stream+0x71/0xb0 [amdgpu] Fix this by adding a guard for checking cursor width before triggering the size calculation.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49909", "url": "https://ubuntu.com/security/CVE-2024-49909", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn32_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn32_set_output_transfer_func function. Previously, set_output_gamma was being checked for null, but then it was being dereferenced without any null check. This could lead to a null pointer dereference if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49910", "url": "https://ubuntu.com/security/CVE-2024-49910", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn401_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn401_set_output_transfer_func function. Previously, set_output_gamma was being checked for null, but then it was being dereferenced without any null check. This could lead to a null pointer dereference if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49911", "url": "https://ubuntu.com/security/CVE-2024-49911", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for function pointer in dcn20_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn20_set_output_transfer_func function. Previously, set_output_gamma was being checked for null at line 1030, but then it was being dereferenced without any null check at line 1048. This could potentially lead to a null pointer dereference error if set_output_gamma is null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a null check for set_output_gamma before the call to set_output_gamma at line 1048.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49912", "url": "https://ubuntu.com/security/CVE-2024-49912", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Handle null 'stream_status' in 'planes_changed_for_existing_stream' This commit adds a null check for 'stream_status' in the function 'planes_changed_for_existing_stream'. Previously, the code assumed 'stream_status' could be null, but did not handle the case where it was actually null. This could lead to a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:3784 planes_changed_for_existing_stream() error: we previously assumed 'stream_status' could be null (see line 3774)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49913", "url": "https://ubuntu.com/security/CVE-2024-49913", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for top_pipe_to_program in commit_planes_for_stream This commit addresses a null pointer dereference issue in the `commit_planes_for_stream` function at line 4140. The issue could occur when `top_pipe_to_program` is null. The fix adds a check to ensure `top_pipe_to_program` is not null before accessing its stream_res. This prevents a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:4140 commit_planes_for_stream() error: we previously assumed 'top_pipe_to_program' could be null (see line 3906)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49914", "url": "https://ubuntu.com/security/CVE-2024-49914", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for pipe_ctx->plane_state in dcn20_program_pipe This commit addresses a null pointer dereference issue in the `dcn20_program_pipe` function. The issue could occur when `pipe_ctx->plane_state` is null. The fix adds a check to ensure `pipe_ctx->plane_state` is not null before accessing. This prevents a null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn20/dcn20_hwseq.c:1925 dcn20_program_pipe() error: we previously assumed 'pipe_ctx->plane_state' could be null (see line 1877)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49915", "url": "https://ubuntu.com/security/CVE-2024-49915", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr in dcn32_init_hw This commit addresses a potential null pointer dereference issue in the `dcn32_init_hw` function. The issue could occur when `dc->clk_mgr` is null. The fix adds a check to ensure `dc->clk_mgr` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn32/dcn32_hwseq.c:961 dcn32_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 782)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49916", "url": "https://ubuntu.com/security/CVE-2024-49916", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in dcn401_init_hw This commit addresses a potential null pointer dereference issue in the `dcn401_init_hw` function. The issue could occur when `dc->clk_mgr` or `dc->clk_mgr->funcs` is null. The fix adds a check to ensure `dc->clk_mgr` and `dc->clk_mgr->funcs` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn401/dcn401_hwseq.c:416 dcn401_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 225)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49917", "url": "https://ubuntu.com/security/CVE-2024-49917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in dcn30_init_hw This commit addresses a potential null pointer dereference issue in the `dcn30_init_hw` function. The issue could occur when `dc->clk_mgr` or `dc->clk_mgr->funcs` is null. The fix adds a check to ensure `dc->clk_mgr` and `dc->clk_mgr->funcs` is not null before accessing its functions. This prevents a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:789 dcn30_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 628)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49918", "url": "https://ubuntu.com/security/CVE-2024-49918", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for head_pipe in dcn32_acquire_idle_pipe_for_head_pipe_in_layer This commit addresses a potential null pointer dereference issue in the `dcn32_acquire_idle_pipe_for_head_pipe_in_layer` function. The issue could occur when `head_pipe` is null. The fix adds a check to ensure `head_pipe` is not null before asserting it. If `head_pipe` is null, the function returns NULL to prevent a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn32/dcn32_resource.c:2690 dcn32_acquire_idle_pipe_for_head_pipe_in_layer() error: we previously assumed 'head_pipe' could be null (see line 2681)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49919", "url": "https://ubuntu.com/security/CVE-2024-49919", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for head_pipe in dcn201_acquire_free_pipe_for_layer This commit addresses a potential null pointer dereference issue in the `dcn201_acquire_free_pipe_for_layer` function. The issue could occur when `head_pipe` is null. The fix adds a check to ensure `head_pipe` is not null before asserting it. If `head_pipe` is null, the function returns NULL to prevent a potential null pointer dereference. Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn201/dcn201_resource.c:1016 dcn201_acquire_free_pipe_for_layer() error: we previously assumed 'head_pipe' could be null (see line 1010)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49991", "url": "https://ubuntu.com/security/CVE-2024-49991", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer Pass pointer reference to amdgpu_bo_unref to clear the correct pointer, otherwise amdgpu_bo_unref clear the local variable, the original pointer not set to NULL, this could cause use-after-free bug.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49920", "url": "https://ubuntu.com/security/CVE-2024-49920", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before multiple uses [WHAT & HOW] Poniters, such as stream_enc and dc->bw_vbios, are null checked previously in the same function, so Coverity warns \"implies that stream_enc and dc->bw_vbios might be null\". They are used multiple times in the subsequent code and need to be checked. This fixes 10 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49921", "url": "https://ubuntu.com/security/CVE-2024-49921", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before used [WHAT & HOW] Poniters, such as dc->clk_mgr, are null checked previously in the same function, so Coverity warns \"implies that \"dc->clk_mgr\" might be null\". As a result, these pointers need to be checked when used again. This fixes 10 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49922", "url": "https://ubuntu.com/security/CVE-2024-49922", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check null pointers before using them [WHAT & HOW] These pointers are null checked previously in the same function, indicating they might be null as reported by Coverity. As a result, they need to be checked when used again. This fixes 3 FORWARD_NULL issue reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49923", "url": "https://ubuntu.com/security/CVE-2024-49923", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Pass non-null to dcn20_validate_apply_pipe_split_flags [WHAT & HOW] \"dcn20_validate_apply_pipe_split_flags\" dereferences merge, and thus it cannot be a null pointer. Let's pass a valid pointer to avoid null dereference. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49992", "url": "https://ubuntu.com/security/CVE-2024-49992", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/stm: Avoid use-after-free issues with crtc and plane ltdc_load() calls functions drm_crtc_init_with_planes(), drm_universal_plane_init() and drm_encoder_init(). These functions should not be called with parameters allocated with devm_kzalloc() to avoid use-after-free issues [1]. Use allocations managed by the DRM framework. Found by Linux Verification Center (linuxtesting.org). [1] https://lore.kernel.org/lkml/u366i76e3qhh3ra5oxrtngjtm2u5lterkekcz6y2jkndhuxzli@diujon4h7qwb/", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49993", "url": "https://ubuntu.com/security/CVE-2024-49993", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49924", "url": "https://ubuntu.com/security/CVE-2024-49924", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: pxafb: Fix possible use after free in pxafb_task() In the pxafb_probe function, it calls the pxafb_init_fbinfo function, after which &fbi->task is associated with pxafb_task. Moreover, within this pxafb_init_fbinfo function, the pxafb_blank function within the &pxafb_ops struct is capable of scheduling work. If we remove the module which will call pxafb_remove to make cleanup, it will call unregister_framebuffer function which can call do_unregister_framebuffer to free fbi->fb through put_fb_info(fb_info), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | pxafb_task pxafb_remove | unregister_framebuffer(info) | do_unregister_framebuffer(fb_info) | put_fb_info(fb_info) | // free fbi->fb | set_ctrlr_state(fbi, state) | __pxafb_lcd_power(fbi, 0) | fbi->lcd_power(on, &fbi->fb.var) | //use fbi->fb Fix it by ensuring that the work is canceled before proceeding with the cleanup in pxafb_remove. Note that only root user can remove the driver at runtime.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49925", "url": "https://ubuntu.com/security/CVE-2024-49925", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fbdev: efifb: Register sysfs groups through driver core The driver core can register and cleanup sysfs groups already. Make use of that functionality to simplify the error handling and cleanup. Also avoid a UAF race during unregistering where the sysctl attributes were usable after the info struct was freed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49926", "url": "https://ubuntu.com/security/CVE-2024-49926", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: rcu-tasks: Fix access non-existent percpu rtpcp variable in rcu_tasks_need_gpcb() For kernels built with CONFIG_FORCE_NR_CPUS=y, the nr_cpu_ids is defined as NR_CPUS instead of the number of possible cpus, this will cause the following system panic: smpboot: Allowing 4 CPUs, 0 hotplug CPUs ... setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:512 nr_node_ids:1 ... BUG: unable to handle page fault for address: ffffffff9911c8c8 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 15 Comm: rcu_tasks_trace Tainted: G W 6.6.21 #1 5dc7acf91a5e8e9ac9dcfc35bee0245691283ea6 RIP: 0010:rcu_tasks_need_gpcb+0x25d/0x2c0 RSP: 0018:ffffa371c00a3e60 EFLAGS: 00010082 CR2: ffffffff9911c8c8 CR3: 000000040fa20005 CR4: 00000000001706f0 Call Trace: ? __die+0x23/0x80 ? page_fault_oops+0xa4/0x180 ? exc_page_fault+0x152/0x180 ? asm_exc_page_fault+0x26/0x40 ? rcu_tasks_need_gpcb+0x25d/0x2c0 ? __pfx_rcu_tasks_kthread+0x40/0x40 rcu_tasks_one_gp+0x69/0x180 rcu_tasks_kthread+0x94/0xc0 kthread+0xe8/0x140 ? __pfx_kthread+0x40/0x40 ret_from_fork+0x34/0x80 ? __pfx_kthread+0x40/0x40 ret_from_fork_asm+0x1b/0x80 Considering that there may be holes in the CPU numbers, use the maximum possible cpu number, instead of nr_cpu_ids, for configuring enqueue and dequeue limits. [ neeraj.upadhyay: Fix htmldocs build error reported by Stephen Rothwell ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50007", "url": "https://ubuntu.com/security/CVE-2024-50007", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ALSA: asihpi: Fix potential OOB array access ASIHPI driver stores some values in the static array upon a response from the driver, and its index depends on the firmware. We shouldn't trust it blindly. This patch adds a sanity check of the array index to fit in the array size.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50017", "url": "https://ubuntu.com/security/CVE-2024-50017", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/mm/ident_map: Use gbpages only where full GB page should be mapped. When ident_pud_init() uses only GB pages to create identity maps, large ranges of addresses not actually requested can be included in the resulting table; a 4K request will map a full GB. This can include a lot of extra address space past that requested, including areas marked reserved by the BIOS. That allows processor speculation into reserved regions, that on UV systems can cause system halts. Only use GB pages when map creation requests include the full GB page of space. Fall back to using smaller 2M pages when only portions of a GB page are included in the request. No attempt is made to coalesce mapping requests. If a request requires a map entry at the 2M (pmd) level, subsequent mapping requests within the same 1G region will also be at the pmd level, even if adjacent or overlapping such requests could have been combined to map a full GB page. Existing usage starts with larger regions and then adds smaller regions, so this should not have any great consequence.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49927", "url": "https://ubuntu.com/security/CVE-2024-49927", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/ioapic: Handle allocation failures gracefully Breno observed panics when using failslab under certain conditions during runtime: can not alloc irq_pin_list (-1,0,20) Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed panic+0x4e9/0x590 mp_irqdomain_alloc+0x9ab/0xa80 irq_domain_alloc_irqs_locked+0x25d/0x8d0 __irq_domain_alloc_irqs+0x80/0x110 mp_map_pin_to_irq+0x645/0x890 acpi_register_gsi_ioapic+0xe6/0x150 hpet_open+0x313/0x480 That's a pointless panic which is a leftover of the historic IO/APIC code which panic'ed during early boot when the interrupt allocation failed. The only place which might justify panic is the PIT/HPET timer_check() code which tries to figure out whether the timer interrupt is delivered through the IO/APIC. But that code does not require to handle interrupt allocation failures. If the interrupt cannot be allocated then timer delivery fails and it either panics due to that or falls back to legacy mode. Cure this by removing the panic wrapper around __add_pin_to_irq_node() and making mp_irqdomain_alloc() aware of the failure condition and handle it as any other failure in this function gracefully.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50008", "url": "https://ubuntu.com/security/CVE-2024-50008", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_cmd_802_11_scan_ext() Replace one-element array with a flexible-array member in `struct host_cmd_ds_802_11_scan_ext`. With this, fix the following warning: elo 16 17:51:58 surfacebook kernel: ------------[ cut here ]------------ elo 16 17:51:58 surfacebook kernel: memcpy: detected field-spanning write (size 243) of single field \"ext_scan->tlv_buffer\" at drivers/net/wireless/marvell/mwifiex/scan.c:2239 (size 1) elo 16 17:51:58 surfacebook kernel: WARNING: CPU: 0 PID: 498 at drivers/net/wireless/marvell/mwifiex/scan.c:2239 mwifiex_cmd_802_11_scan_ext+0x83/0x90 [mwifiex]", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50018", "url": "https://ubuntu.com/security/CVE-2024-50018", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49928", "url": "https://ubuntu.com/security/CVE-2024-49928", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: avoid reading out of bounds when loading TX power FW elements Because the loop-expression will do one more time before getting false from cond-expression, the original code copied one more entry size beyond valid region. Fix it by moving the entry copy to loop-body.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50178", "url": "https://ubuntu.com/security/CVE-2024-50178", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: loongson3: Use raw_smp_processor_id() in do_service_request() Use raw_smp_processor_id() instead of plain smp_processor_id() in do_service_request(), otherwise we may get some errors with the driver enabled: BUG: using smp_processor_id() in preemptible [00000000] code: (udev-worker)/208 caller is loongson3_cpufreq_probe+0x5c/0x250 [loongson3_cpufreq]", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-50009", "url": "https://ubuntu.com/security/CVE-2024-50009", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cpufreq: amd-pstate: add check for cpufreq_cpu_get's return value cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it and return in case of error. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-49994", "url": "https://ubuntu.com/security/CVE-2024-49994", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix integer overflow in BLKSECDISCARD I independently rediscovered \tcommit 22d24a544b0d49bbcbd61c8c0eaf77d3c9297155 \tblock: fix overflow in blk_ioctl_discard() but for secure erase. Same problem: \tuint64_t r[2] = {512, 18446744073709551104ULL}; \tioctl(fd, BLKSECDISCARD, r); will enter near infinite loop inside blkdev_issue_secure_erase(): \ta.out: attempt to access beyond end of device \tloop0: rw=5, sector=3399043073, nr_sectors = 1024 limit=2048 \tbio_check_eod: 3286214 callbacks suppressed", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49929", "url": "https://ubuntu.com/security/CVE-2024-49929", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: avoid NULL pointer dereference iwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta pointer is not NULL. It retrieves this pointer using iwl_mvm_sta_from_mac80211, which is dereferencing the ieee80211_sta pointer. If sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL pointer. Fix this by checking the sta pointer before retrieving the mvmsta from it. If sta is not NULL, then mvmsta isn't either.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49995", "url": "https://ubuntu.com/security/CVE-2024-49995", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tipc: guard against string buffer overrun Smatch reports that copying media_name and if_name to name_parts may overwrite the destination. .../bearer.c:166 bearer_name_validate() error: strcpy() 'media_name' too large for 'name_parts->media_name' (32 vs 16) .../bearer.c:167 bearer_name_validate() error: strcpy() 'if_name' too large for 'name_parts->if_name' (1010102 vs 16) This does seem to be the case so guard against this possibility by using strscpy() and failing if truncation occurs. Introduced by commit b97bf3fd8f6a (\"[TIPC] Initial merge\") Compile tested only.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49962", "url": "https://ubuntu.com/security/CVE-2024-49962", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in acpi_db_convert_to_package() ACPICA commit 4d4547cf13cca820ff7e0f859ba83e1a610b9fd0 ACPI_ALLOCATE_ZEROED() may fail, elements might be NULL and will cause NULL pointer dereference later. [ rjw: Subject and changelog edits ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49930", "url": "https://ubuntu.com/security/CVE-2024-49930", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix array out-of-bound access in SoC stats Currently, the ath11k_soc_dp_stats::hal_reo_error array is defined with a maximum size of DP_REO_DST_RING_MAX. However, the ath11k_dp_process_rx() function access ath11k_soc_dp_stats::hal_reo_error using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath11k_dp_process_rx() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49931", "url": "https://ubuntu.com/security/CVE-2024-49931", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix array out-of-bound access in SoC stats Currently, the ath12k_soc_dp_stats::hal_reo_error array is defined with a maximum size of DP_REO_DST_RING_MAX. However, the ath12k_dp_rx_process() function access ath12k_soc_dp_stats::hal_reo_error using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath12k_dp_rx_process() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access. Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49932", "url": "https://ubuntu.com/security/CVE-2024-49932", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: don't readahead the relocation inode on RST On relocation we're doing readahead on the relocation inode, but if the filesystem is backed by a RAID stripe tree we can get ENOENT (e.g. due to preallocated extents not being mapped in the RST) from the lookup. But readahead doesn't handle the error and submits invalid reads to the device, causing an assertion in the scatter-gather list code: BTRFS info (device nvme1n1): balance: start -d -m -s BTRFS info (device nvme1n1): relocating block group 6480920576 flags data|raid0 BTRFS error (device nvme1n1): cannot find raid-stripe for logical [6481928192, 6481969152] devid 2, profile raid0 ------------[ cut here ]------------ kernel BUG at include/linux/scatterlist.h:115! Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 1012 Comm: btrfs Not tainted 6.10.0-rc7+ #567 RIP: 0010:__blk_rq_map_sg+0x339/0x4a0 RSP: 0018:ffffc90001a43820 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffea00045d4802 RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000 RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000001000 R12: ffff8881003d10b8 R13: ffffc90001a438f0 R14: 0000000000000000 R15: 0000000000003000 FS: 00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000002cd11000 CR3: 00000001109ea001 CR4: 0000000000370eb0 Call Trace: ? __die_body.cold+0x14/0x25 ? die+0x2e/0x50 ? do_trap+0xca/0x110 ? do_error_trap+0x65/0x80 ? __blk_rq_map_sg+0x339/0x4a0 ? exc_invalid_op+0x50/0x70 ? __blk_rq_map_sg+0x339/0x4a0 ? asm_exc_invalid_op+0x1a/0x20 ? __blk_rq_map_sg+0x339/0x4a0 nvme_prep_rq.part.0+0x9d/0x770 nvme_queue_rq+0x7d/0x1e0 __blk_mq_issue_directly+0x2a/0x90 ? blk_mq_get_budget_and_tag+0x61/0x90 blk_mq_try_issue_list_directly+0x56/0xf0 blk_mq_flush_plug_list.part.0+0x52b/0x5d0 __blk_flush_plug+0xc6/0x110 blk_finish_plug+0x28/0x40 read_pages+0x160/0x1c0 page_cache_ra_unbounded+0x109/0x180 relocate_file_extent_cluster+0x611/0x6a0 ? btrfs_search_slot+0xba4/0xd20 ? balance_dirty_pages_ratelimited_flags+0x26/0xb00 relocate_data_extent.constprop.0+0x134/0x160 relocate_block_group+0x3f2/0x500 btrfs_relocate_block_group+0x250/0x430 btrfs_relocate_chunk+0x3f/0x130 btrfs_balance+0x71b/0xef0 ? kmalloc_trace_noprof+0x13b/0x280 btrfs_ioctl+0x2c2e/0x3030 ? kvfree_call_rcu+0x1e6/0x340 ? list_lru_add_obj+0x66/0x80 ? mntput_no_expire+0x3a/0x220 __x64_sys_ioctl+0x96/0xc0 do_syscall_64+0x54/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e RIP: 0033:0x7fcc04514f9b Code: Unable to access opcode bytes at 0x7fcc04514f71. RSP: 002b:00007ffeba923370 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fcc04514f9b RDX: 00007ffeba923460 RSI: 00000000c4009420 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000000000013 R09: 0000000000000001 R10: 00007fcc043fbba8 R11: 0000000000000246 R12: 00007ffeba924fc5 R13: 00007ffeba923460 R14: 0000000000000002 R15: 00000000004d4bb0 Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:__blk_rq_map_sg+0x339/0x4a0 RSP: 0018:ffffc90001a43820 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffea00045d4802 RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000 RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000001000 R12: ffff8881003d10b8 R13: ffffc90001a438f0 R14: 0000000000000000 R15: 0000000000003000 FS: 00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcc04514f71 CR3: 00000001109ea001 CR4: 0000000000370eb0 Kernel p ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49933", "url": "https://ubuntu.com/security/CVE-2024-49933", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: blk_iocost: fix more out of bound shifts Recently running UBSAN caught few out of bound shifts in the ioc_forgive_debts() function: UBSAN: shift-out-of-bounds in block/blk-iocost.c:2142:38 shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long long') ... UBSAN: shift-out-of-bounds in block/blk-iocost.c:2144:30 shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long long') ... Call Trace: dump_stack_lvl+0xca/0x130 __ubsan_handle_shift_out_of_bounds+0x22c/0x280 ? __lock_acquire+0x6441/0x7c10 ioc_timer_fn+0x6cec/0x7750 ? blk_iocost_init+0x720/0x720 ? call_timer_fn+0x5d/0x470 call_timer_fn+0xfa/0x470 ? blk_iocost_init+0x720/0x720 __run_timer_base+0x519/0x700 ... Actual impact of this issue was not identified but I propose to fix the undefined behaviour. The proposed fix to prevent those out of bound shifts consist of precalculating exponent before using it the shift operations by taking min value from the actual exponent and maximum possible number of bits.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49934", "url": "https://ubuntu.com/security/CVE-2024-49934", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fs/inode: Prevent dump_mapping() accessing invalid dentry.d_name.name It's observed that a crash occurs during hot-remove a memory device, in which user is accessing the hugetlb. See calltrace as following: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 14045 at arch/x86/mm/fault.c:1278 do_user_addr_fault+0x2a0/0x790 Modules linked in: kmem device_dax cxl_mem cxl_pmem cxl_port cxl_pci dax_hmem dax_pmem nd_pmem cxl_acpi nd_btt cxl_core crc32c_intel nvme virtiofs fuse nvme_core nfit libnvdimm dm_multipath scsi_dh_rdac scsi_dh_emc s mirror dm_region_hash dm_log dm_mod CPU: 1 PID: 14045 Comm: daxctl Not tainted 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:do_user_addr_fault+0x2a0/0x790 Code: 48 8b 00 a8 04 0f 84 b5 fe ff ff e9 1c ff ff ff 4c 89 e9 4c 89 e2 be 01 00 00 00 bf 02 00 00 00 e8 b5 ef 24 00 e9 42 fe ff ff <0f> 0b 48 83 c4 08 4c 89 ea 48 89 ee 4c 89 e7 5b 5d 41 5c 41 5d 41 RSP: 0000:ffffc90000a575f0 EFLAGS: 00010046 RAX: ffff88800c303600 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000001000 RSI: ffffffff82504162 RDI: ffffffff824b2c36 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffc90000a57658 R13: 0000000000001000 R14: ffff88800bc2e040 R15: 0000000000000000 FS: 00007f51cb57d880(0000) GS:ffff88807fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000001000 CR3: 00000000072e2004 CR4: 00000000001706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __warn+0x8d/0x190 ? do_user_addr_fault+0x2a0/0x790 ? report_bug+0x1c3/0x1d0 ? handle_bug+0x3c/0x70 ? exc_invalid_op+0x14/0x70 ? asm_exc_invalid_op+0x16/0x20 ? do_user_addr_fault+0x2a0/0x790 ? exc_page_fault+0x31/0x200 exc_page_fault+0x68/0x200 <...snip...> BUG: unable to handle page fault for address: 0000000000001000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI ---[ end trace 0000000000000000 ]--- BUG: unable to handle page fault for address: 0000000000001000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 14045 Comm: daxctl Kdump: loaded Tainted: G W 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:dentry_name+0x1f4/0x440 <...snip...> ? dentry_name+0x2fa/0x440 vsnprintf+0x1f3/0x4f0 vprintk_store+0x23a/0x540 vprintk_emit+0x6d/0x330 _printk+0x58/0x80 dump_mapping+0x10b/0x1a0 ? __pfx_free_object_rcu+0x10/0x10 __dump_page+0x26b/0x3e0 ? vprintk_emit+0xe0/0x330 ? _printk+0x58/0x80 ? dump_page+0x17/0x50 dump_page+0x17/0x50 do_migrate_range+0x2f7/0x7f0 ? do_migrate_range+0x42/0x7f0 ? offline_pages+0x2f4/0x8c0 offline_pages+0x60a/0x8c0 memory_subsys_offline+0x9f/0x1c0 ? lockdep_hardirqs_on+0x77/0x100 ? _raw_spin_unlock_irqrestore+0x38/0x60 device_offline+0xe3/0x110 state_store+0x6e/0xc0 kernfs_fop_write_iter+0x143/0x200 vfs_write+0x39f/0x560 ksys_write+0x65/0xf0 do_syscall_64+0x62/0x130 Previously, some sanity check have been done in dump_mapping() before the print facility parsing '%pd' though, it's still possible to run into an invalid dentry.d_name.name. Since dump_mapping() only needs to dump the filename only, retrieve it by itself in a safer way to prevent an unnecessary crash. Note that either retrieving the filename with '%pd' or strncpy_from_kernel_nofault(), the filename could be unreliable.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49935", "url": "https://ubuntu.com/security/CVE-2024-49935", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: PAD: fix crash in exit_round_robin() The kernel occasionally crashes in cpumask_clear_cpu(), which is called within exit_round_robin(), because when executing clear_bit(nr, addr) with nr set to 0xffffffff, the address calculation may cause misalignment within the memory, leading to access to an invalid memory address. ---------- BUG: unable to handle kernel paging request at ffffffffe0740618 ... CPU: 3 PID: 2919323 Comm: acpi_pad/14 Kdump: loaded Tainted: G OE X --------- - - 4.18.0-425.19.2.el8_7.x86_64 #1 ... RIP: 0010:power_saving_thread+0x313/0x411 [acpi_pad] Code: 89 cd 48 89 d3 eb d1 48 c7 c7 55 70 72 c0 e8 64 86 b0 e4 c6 05 0d a1 02 00 01 e9 bc fd ff ff 45 89 e4 42 8b 04 a5 20 82 72 c0 48 0f b3 05 f4 9c 01 00 42 c7 04 a5 20 82 72 c0 ff ff ff ff 31 RSP: 0018:ff72a5d51fa77ec8 EFLAGS: 00010202 RAX: 00000000ffffffff RBX: ff462981e5d8cb80 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246 RBP: ff46297556959d80 R08: 0000000000000382 R09: ff46297c8d0f38d8 R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000000e R13: 0000000000000000 R14: ffffffffffffffff R15: 000000000000000e FS: 0000000000000000(0000) GS:ff46297a800c0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffe0740618 CR3: 0000007e20410004 CR4: 0000000000771ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? acpi_pad_add+0x120/0x120 [acpi_pad] kthread+0x10b/0x130 ? set_kthread_struct+0x50/0x50 ret_from_fork+0x1f/0x40 ... CR2: ffffffffe0740618 crash> dis -lr ffffffffc0726923 ... /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 114 0xffffffffc0726918 :\tmov %r12d,%r12d /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 325 0xffffffffc072691b :\tmov -0x3f8d7de0(,%r12,4),%eax /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./arch/x86/include/asm/bitops.h: 80 0xffffffffc0726923 :\tlock btr %rax,0x19cf4(%rip) # 0xffffffffc0740620 crash> px tsk_in_cpu[14] $66 = 0xffffffff crash> px 0xffffffffc072692c+0x19cf4 $99 = 0xffffffffc0740620 crash> sym 0xffffffffc0740620 ffffffffc0740620 (b) pad_busy_cpus_bits [acpi_pad] crash> px pad_busy_cpus_bits[0] $42 = 0xfffc0 ---------- To fix this, ensure that tsk_in_cpu[tsk_index] != -1 before calling cpumask_clear_cpu() in exit_round_robin(), just as it is done in round_robin_cpu(). [ rjw: Subject edit, avoid updates to the same value ]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49936", "url": "https://ubuntu.com/security/CVE-2024-49936", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/xen-netback: prevent UAF in xenvif_flush_hash() During the list_for_each_entry_rcu iteration call of xenvif_flush_hash, kfree_rcu does not exist inside the rcu read critical section, so if kfree_rcu is called when the rcu grace period ends during the iteration, UAF occurs when accessing head->next after the entry becomes free. Therefore, to solve this, you need to change it to list_for_each_entry_safe.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49937", "url": "https://ubuntu.com/security/CVE-2024-49937", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: Set correct chandef when starting CAC When starting CAC in a mode other than AP mode, it return a \"WARNING: CPU: 0 PID: 63 at cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211]\" caused by the chandef.chan being null at the end of CAC. Solution: Ensure the channel definition is set for the different modes when starting CAC to avoid getting a NULL 'chan' at the end of CAC. Call Trace: ? show_regs.part.0+0x14/0x16 ? __warn+0x67/0xc0 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? report_bug+0xa7/0x130 ? exc_overflow+0x30/0x30 ? handle_bug+0x27/0x50 ? exc_invalid_op+0x18/0x60 ? handle_exception+0xf6/0xf6 ? exc_overflow+0x30/0x30 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? exc_overflow+0x30/0x30 ? cfg80211_chandef_dfs_usable+0x20/0xaf [cfg80211] ? regulatory_propagate_dfs_state.cold+0x1b/0x4c [cfg80211] ? cfg80211_propagate_cac_done_wk+0x1a/0x30 [cfg80211] ? process_one_work+0x165/0x280 ? worker_thread+0x120/0x3f0 ? kthread+0xc2/0xf0 ? process_one_work+0x280/0x280 ? kthread_complete_and_exit+0x20/0x20 ? ret_from_fork+0x19/0x24 [shorten subject, remove OCB, reorder cases to match previous list]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49938", "url": "https://ubuntu.com/security/CVE-2024-49938", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmit Syzbot points out that skb_trim() has a sanity check on the existing length of the skb, which can be uninitialised in some error paths. The intent here is clearly just to reset the length to zero before resubmitting, so switch to calling __skb_set_length(skb, 0) directly. In addition, __skb_set_length() already contains a call to skb_reset_tail_pointer(), so remove the redundant call. The syzbot report came from ath9k_hif_usb_reg_in_cb(), but there's a similar usage of skb_trim() in ath9k_hif_usb_rx_cb(), change both while we're at it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49939", "url": "https://ubuntu.com/security/CVE-2024-49939", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: avoid to add interface to list twice when SER If SER L2 occurs during the WoWLAN resume flow, the add interface flow is triggered by ieee80211_reconfig(). However, due to rtw89_wow_resume() return failure, it will cause the add interface flow to be executed again, resulting in a double add list and causing a kernel panic. Therefore, we have added a check to prevent double adding of the list. list_add double add: new=ffff99d6992e2010, prev=ffff99d6992e2010, next=ffff99d695302628. ------------[ cut here ]------------ kernel BUG at lib/list_debug.c:37! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G W O 6.6.30-02659-gc18865c4dfbd #1 770df2933251a0e3c888ba69d1053a817a6376a7 Hardware name: HP Grunt/Grunt, BIOS Google_Grunt.11031.169.0 06/24/2021 Workqueue: events_freezable ieee80211_restart_work [mac80211] RIP: 0010:__list_add_valid_or_report+0x5e/0xb0 Code: c7 74 18 48 39 ce 74 13 b0 01 59 5a 5e 5f 41 58 41 59 41 5a 5d e9 e2 d6 03 00 cc 48 c7 c7 8d 4f 17 83 48 89 c2 e8 02 c0 00 00 <0f> 0b 48 c7 c7 aa 8c 1c 83 e8 f4 bf 00 00 0f 0b 48 c7 c7 c8 bc 12 RSP: 0018:ffffa91b8007bc50 EFLAGS: 00010246 RAX: 0000000000000058 RBX: ffff99d6992e0900 RCX: a014d76c70ef3900 RDX: ffffa91b8007bae8 RSI: 00000000ffffdfff RDI: 0000000000000001 RBP: ffffa91b8007bc88 R08: 0000000000000000 R09: ffffa91b8007bae0 R10: 00000000ffffdfff R11: ffffffff83a79800 R12: ffff99d695302060 R13: ffff99d695300900 R14: ffff99d6992e1be0 R15: ffff99d6992e2010 FS: 0000000000000000(0000) GS:ffff99d6aac00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000078fbdba43480 CR3: 000000010e464000 CR4: 00000000001506f0 Call Trace: ? __die_body+0x1f/0x70 ? die+0x3d/0x60 ? do_trap+0xa4/0x110 ? __list_add_valid_or_report+0x5e/0xb0 ? do_error_trap+0x6d/0x90 ? __list_add_valid_or_report+0x5e/0xb0 ? handle_invalid_op+0x30/0x40 ? __list_add_valid_or_report+0x5e/0xb0 ? exc_invalid_op+0x3c/0x50 ? asm_exc_invalid_op+0x16/0x20 ? __list_add_valid_or_report+0x5e/0xb0 rtw89_ops_add_interface+0x309/0x310 [rtw89_core 7c32b1ee6854761c0321027c8a58c5160e41f48f] drv_add_interface+0x5c/0x130 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ieee80211_reconfig+0x241/0x13d0 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] ? finish_wait+0x3e/0x90 ? synchronize_rcu_expedited+0x174/0x260 ? sync_rcu_exp_done_unlocked+0x50/0x50 ? wake_bit_function+0x40/0x40 ieee80211_restart_work+0xf0/0x140 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc] process_scheduled_works+0x1e5/0x480 worker_thread+0xea/0x1e0 kthread+0xdb/0x110 ? move_linked_works+0x90/0x90 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork+0x3b/0x50 ? kthread_associate_blkcg+0xa0/0xa0 ret_from_fork_asm+0x11/0x20 Modules linked in: dm_integrity async_xor xor async_tx lz4 lz4_compress zstd zstd_compress zram zsmalloc rfcomm cmac uinput algif_hash algif_skcipher af_alg btusb btrtl iio_trig_hrtimer industrialio_sw_trigger btmtk industrialio_configfs btbcm btintel uvcvideo videobuf2_vmalloc iio_trig_sysfs videobuf2_memops videobuf2_v4l2 videobuf2_common uvc snd_hda_codec_hdmi veth snd_hda_intel snd_intel_dspcfg acpi_als snd_hda_codec industrialio_triggered_buffer kfifo_buf snd_hwdep industrialio i2c_piix4 snd_hda_core designware_i2s ip6table_nat snd_soc_max98357a xt_MASQUERADE xt_cgroup snd_soc_acp_rt5682_mach fuse rtw89_8922ae(O) rtw89_8922a(O) rtw89_pci(O) rtw89_core(O) 8021q mac80211(O) bluetooth ecdh_generic ecc cfg80211 r8152 mii joydev gsmi: Log Shutdown Reason 0x03 ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49940", "url": "https://ubuntu.com/security/CVE-2024-49940", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: l2tp: prevent possible tunnel refcount underflow When a session is created, it sets a backpointer to its tunnel. When the session refcount drops to 0, l2tp_session_free drops the tunnel refcount if session->tunnel is non-NULL. However, session->tunnel is set in l2tp_session_create, before the tunnel refcount is incremented by l2tp_session_register, which leaves a small window where session->tunnel is non-NULL when the tunnel refcount hasn't been bumped. Moving the assignment to l2tp_session_register is trivial but l2tp_session_create calls l2tp_session_set_header_len which uses session->tunnel to get the tunnel's encap. Add an encap arg to l2tp_session_set_header_len to avoid using session->tunnel. If l2tpv3 sessions have colliding IDs, it is possible for l2tp_v3_session_get to race with l2tp_session_register and fetch a session which doesn't yet have session->tunnel set. Add a check for this case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49941", "url": "https://ubuntu.com/security/CVE-2024-49941", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: gpiolib: Fix potential NULL pointer dereference in gpiod_get_label() In `gpiod_get_label()`, it is possible that `srcu_dereference_check()` may return a NULL pointer, leading to a scenario where `label->str` is accessed without verifying if `label` itself is NULL. This patch adds a proper NULL check for `label` before accessing `label->str`. The check for `label->str != NULL` is removed because `label->str` can never be NULL if `label` is not NULL. This fixes the issue where the label name was being printed as `(efault)` when dumping the sysfs GPIO file when `label == NULL`.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49996", "url": "https://ubuntu.com/security/CVE-2024-49996", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: cifs: Fix buffer overflow when parsing NFS reparse points ReparseDataLength is sum of the InodeType size and DataBuffer size. So to get DataBuffer size it is needed to subtract InodeType's size from ReparseDataLength. Function cifs_strndup_from_utf16() is currentlly accessing buf->DataBuffer at position after the end of the buffer because it does not subtract InodeType size from the length. Fix this problem and correctly subtract variable len. Member InodeType is present only when reparse buffer is large enough. Check for ReparseDataLength before accessing InodeType to prevent another invalid memory access. Major and minor rdev values are present also only when reparse buffer is large enough. Check for reparse buffer size before calling reparse_mkdev().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49942", "url": "https://ubuntu.com/security/CVE-2024-49942", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe: Prevent null pointer access in xe_migrate_copy xe_migrate_copy designed to copy content of TTM resources. When source resource is null, it will trigger a NULL pointer dereference in xe_migrate_copy. To avoid this situation, update lacks source flag to true for this case, the flag will trigger xe_migrate_clear rather than xe_migrate_copy. Issue trace: <7> [317.089847] xe 0000:00:02.0: [drm:xe_migrate_copy [xe]] Pass 14, sizes: 4194304 & 4194304 <7> [317.089945] xe 0000:00:02.0: [drm:xe_migrate_copy [xe]] Pass 15, sizes: 4194304 & 4194304 <1> [317.128055] BUG: kernel NULL pointer dereference, address: 0000000000000010 <1> [317.128064] #PF: supervisor read access in kernel mode <1> [317.128066] #PF: error_code(0x0000) - not-present page <6> [317.128069] PGD 0 P4D 0 <4> [317.128071] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI <4> [317.128074] CPU: 1 UID: 0 PID: 1440 Comm: kunit_try_catch Tainted: G U N 6.11.0-rc7-xe #1 <4> [317.128078] Tainted: [U]=USER, [N]=TEST <4> [317.128080] Hardware name: Intel Corporation Lunar Lake Client Platform/LNL-M LP5 RVP1, BIOS LNLMFWI1.R00.3221.D80.2407291239 07/29/2024 <4> [317.128082] RIP: 0010:xe_migrate_copy+0x66/0x13e0 [xe] <4> [317.128158] Code: 00 00 48 89 8d e0 fe ff ff 48 8b 40 10 4c 89 85 c8 fe ff ff 44 88 8d bd fe ff ff 65 48 8b 3c 25 28 00 00 00 48 89 7d d0 31 ff <8b> 79 10 48 89 85 a0 fe ff ff 48 8b 00 48 89 b5 d8 fe ff ff 83 ff <4> [317.128162] RSP: 0018:ffffc9000167f9f0 EFLAGS: 00010246 <4> [317.128164] RAX: ffff8881120d8028 RBX: ffff88814d070428 RCX: 0000000000000000 <4> [317.128166] RDX: ffff88813cb99c00 RSI: 0000000004000000 RDI: 0000000000000000 <4> [317.128168] RBP: ffffc9000167fbb8 R08: ffff88814e7b1f08 R09: 0000000000000001 <4> [317.128170] R10: 0000000000000001 R11: 0000000000000001 R12: ffff88814e7b1f08 <4> [317.128172] R13: ffff88814e7b1f08 R14: ffff88813cb99c00 R15: 0000000000000001 <4> [317.128174] FS: 0000000000000000(0000) GS:ffff88846f280000(0000) knlGS:0000000000000000 <4> [317.128176] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [317.128178] CR2: 0000000000000010 CR3: 000000011f676004 CR4: 0000000000770ef0 <4> [317.128180] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 <4> [317.128182] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7: 0000000000000400 <4> [317.128184] PKRU: 55555554 <4> [317.128185] Call Trace: <4> [317.128187] <4> [317.128189] ? show_regs+0x67/0x70 <4> [317.128194] ? __die_body+0x20/0x70 <4> [317.128196] ? __die+0x2b/0x40 <4> [317.128198] ? page_fault_oops+0x15f/0x4e0 <4> [317.128203] ? do_user_addr_fault+0x3fb/0x970 <4> [317.128205] ? lock_acquire+0xc7/0x2e0 <4> [317.128209] ? exc_page_fault+0x87/0x2b0 <4> [317.128212] ? asm_exc_page_fault+0x27/0x30 <4> [317.128216] ? xe_migrate_copy+0x66/0x13e0 [xe] <4> [317.128263] ? __lock_acquire+0xb9d/0x26f0 <4> [317.128265] ? __lock_acquire+0xb9d/0x26f0 <4> [317.128267] ? sg_free_append_table+0x20/0x80 <4> [317.128271] ? lock_acquire+0xc7/0x2e0 <4> [317.128273] ? mark_held_locks+0x4d/0x80 <4> [317.128275] ? trace_hardirqs_on+0x1e/0xd0 <4> [317.128278] ? _raw_spin_unlock_irqrestore+0x31/0x60 <4> [317.128281] ? __pm_runtime_resume+0x60/0xa0 <4> [317.128284] xe_bo_move+0x682/0xc50 [xe] <4> [317.128315] ? lock_is_held_type+0xaa/0x120 <4> [317.128318] ttm_bo_handle_move_mem+0xe5/0x1a0 [ttm] <4> [317.128324] ttm_bo_validate+0xd1/0x1a0 [ttm] <4> [317.128328] shrink_test_run_device+0x721/0xc10 [xe] <4> [317.128360] ? find_held_lock+0x31/0x90 <4> [317.128363] ? lock_release+0xd1/0x2a0 <4> [317.128365] ? __pfx_kunit_generic_run_threadfn_adapter+0x10/0x10 [kunit] <4> [317.128370] xe_bo_shrink_kunit+0x11/0x20 [xe] <4> [317.128397] kunit_try_run_case+0x6e/0x150 [kunit] <4> [317.128400] ? trace_hardirqs_on+0x1e/0xd0 <4> [317.128402] ? _raw_spin_unlock_irqrestore+0x31/0x60 <4> [317.128404] kunit_generic_run_threadfn_adapter+0x1e/0x40 [ku ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49943", "url": "https://ubuntu.com/security/CVE-2024-49943", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc_submit: add missing locking in wedged_fini Any non-wedged queue can have a zero refcount here and can be running concurrently with an async queue destroy, therefore dereferencing the queue ptr to check wedge status after the lookup can trigger UAF if queue is not wedged. Fix this by keeping the submission_state lock held around the check to postpone the free and make the check safe, before dropping again around the put() to avoid the deadlock. (cherry picked from commit d28af0b6b9580b9f90c265a7da0315b0ad20bbfd)", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50011", "url": "https://ubuntu.com/security/CVE-2024-50011", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ASoC: Intel: soc-acpi-intel-rpl-match: add missing empty item There is no links_num in struct snd_soc_acpi_mach {}, and we test !link->num_adr as a condition to end the loop in hda_sdw_machine_select(). So an empty item in struct snd_soc_acpi_link_adr array is required.", "cve_priority": "medium", "cve_public_date": "2024-10-21 19:15:00 UTC" }, { "cve": "CVE-2024-50174", "url": "https://ubuntu.com/security/CVE-2024-50174", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Fix race when converting group handle to group object XArray provides it's own internal lock which protects the internal array when entries are being simultaneously added and removed. However there is still a race between retrieving the pointer from the XArray and incrementing the reference count. To avoid this race simply hold the internal XArray lock when incrementing the reference count, this ensures there cannot be a racing call to xa_erase().", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49944", "url": "https://ubuntu.com/security/CVE-2024-49944", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_start In sctp_listen_start() invoked by sctp_inet_listen(), it should set the sk_state back to CLOSED if sctp_autobind() fails due to whatever reason. Otherwise, next time when calling sctp_inet_listen(), if sctp_sk(sk)->reuse is already set via setsockopt(SCTP_REUSE_PORT), sctp_sk(sk)->bind_hash will be dereferenced as sk_state is LISTENING, which causes a crash as bind_hash is NULL. KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:sctp_inet_listen+0x7f0/0xa20 net/sctp/socket.c:8617 Call Trace: __sys_listen_socket net/socket.c:1883 [inline] __sys_listen+0x1b7/0x230 net/socket.c:1894 __do_sys_listen net/socket.c:1902 [inline]", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49945", "url": "https://ubuntu.com/security/CVE-2024-49945", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/ncsi: Disable the ncsi work before freeing the associated structure The work function can run after the ncsi device is freed, resulting in use-after-free bugs or kernel panic.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49946", "url": "https://ubuntu.com/security/CVE-2024-49946", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ppp: do not assume bh is held in ppp_channel_bridge_input() Networking receive path is usually handled from BH handler. However, some protocols need to acquire the socket lock, and packets might be stored in the socket backlog is the socket was owned by a user process. In this case, release_sock(), __release_sock(), and sk_backlog_rcv() might call the sk->sk_backlog_rcv() handler in process context. sybot caught ppp was not considering this case in ppp_channel_bridge_input() : WARNING: inconsistent lock state 6.11.0-rc7-syzkaller-g5f5673607153 #0 Not tainted -------------------------------- inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. ksoftirqd/1/24 [HC0[0]:SC1[1]:HE1:SE0] takes: ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 {SOFTIRQ-ON-W} state was registered at: lock_acquire+0x240/0x728 kernel/locking/lockdep.c:5759 __raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline] _raw_spin_lock+0x48/0x60 kernel/locking/spinlock.c:154 spin_lock include/linux/spinlock.h:351 [inline] ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline] ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304 pppoe_rcv_core+0xfc/0x314 drivers/net/ppp/pppoe.c:379 sk_backlog_rcv include/net/sock.h:1111 [inline] __release_sock+0x1a8/0x3d8 net/core/sock.c:3004 release_sock+0x68/0x1b8 net/core/sock.c:3558 pppoe_sendmsg+0xc8/0x5d8 drivers/net/ppp/pppoe.c:903 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg net/socket.c:745 [inline] __sys_sendto+0x374/0x4f4 net/socket.c:2204 __do_sys_sendto net/socket.c:2216 [inline] __se_sys_sendto net/socket.c:2212 [inline] __arm64_sys_sendto+0xd8/0xf8 net/socket.c:2212 __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:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598 irq event stamp: 282914 hardirqs last enabled at (282914): [] __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:151 [inline] hardirqs last enabled at (282914): [] _raw_spin_unlock_irqrestore+0x38/0x98 kernel/locking/spinlock.c:194 hardirqs last disabled at (282913): [] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline] hardirqs last disabled at (282913): [] _raw_spin_lock_irqsave+0x2c/0x7c kernel/locking/spinlock.c:162 softirqs last enabled at (282904): [] softirq_handle_end kernel/softirq.c:400 [inline] softirqs last enabled at (282904): [] handle_softirqs+0xa3c/0xbfc kernel/softirq.c:582 softirqs last disabled at (282909): [] run_ksoftirqd+0x70/0x158 kernel/softirq.c:928 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&pch->downl); lock(&pch->downl); *** DEADLOCK *** 1 lock held by ksoftirqd/1/24: #0: ffff80008f74dfa0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire+0x10/0x4c include/linux/rcupdate.h:325 stack backtrace: CPU: 1 UID: 0 PID: 24 Comm: ksoftirqd/1 Not tainted 6.11.0-rc7-syzkaller-g5f5673607153 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call trace: dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:319 show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:326 __dump_sta ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49947", "url": "https://ubuntu.com/security/CVE-2024-49947", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: test for not too small csum_start in virtio_net_hdr_to_skb() syzbot was able to trigger this warning [1], after injecting a malicious packet through af_packet, setting skb->csum_start and thus the transport header to an incorrect value. We can at least make sure the transport header is after the end of the network header (with a estimated minimal size). [1] [ 67.873027] skb len=4096 headroom=16 headlen=14 tailroom=0 mac=(-1,-1) mac_len=0 net=(16,-6) trans=10 shinfo(txflags=0 nr_frags=1 gso(size=0 type=0 segs=0)) csum(0xa start=10 offset=0 ip_summed=3 complete_sw=0 valid=0 level=0) hash(0x0 sw=0 l4=0) proto=0x0800 pkttype=0 iif=0 priority=0x0 mark=0x0 alloc_cpu=10 vlan_all=0x0 encapsulation=0 inner(proto=0x0000, mac=0, net=0, trans=0) [ 67.877172] dev name=veth0_vlan feat=0x000061164fdd09e9 [ 67.877764] sk family=17 type=3 proto=0 [ 67.878279] skb linear: 00000000: 00 00 10 00 00 00 00 00 0f 00 00 00 08 00 [ 67.879128] skb frag: 00000000: 0e 00 07 00 00 00 28 00 08 80 1c 00 04 00 00 02 [ 67.879877] skb frag: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.880647] skb frag: 00000020: 00 00 02 00 00 00 08 00 1b 00 00 00 00 00 00 00 [ 67.881156] skb frag: 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.881753] skb frag: 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.882173] skb frag: 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.882790] skb frag: 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.883171] skb frag: 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.883733] skb frag: 00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.884206] skb frag: 00000090: 00 00 00 00 00 00 00 00 00 00 69 70 76 6c 61 6e [ 67.884704] skb frag: 000000a0: 31 00 00 00 00 00 00 00 00 00 2b 00 00 00 00 00 [ 67.885139] skb frag: 000000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.885677] skb frag: 000000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.886042] skb frag: 000000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.886408] skb frag: 000000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.887020] skb frag: 000000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 67.887384] skb frag: 00000100: 00 00 [ 67.887878] ------------[ cut here ]------------ [ 67.887908] offset (-6) >= skb_headlen() (14) [ 67.888445] WARNING: CPU: 10 PID: 2088 at net/core/dev.c:3332 skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.889353] Modules linked in: macsec macvtap macvlan hsr wireguard curve25519_x86_64 libcurve25519_generic libchacha20poly1305 chacha_x86_64 libchacha poly1305_x86_64 dummy bridge sr_mod cdrom evdev pcspkr i2c_piix4 9pnet_virtio 9p 9pnet netfs [ 67.890111] CPU: 10 UID: 0 PID: 2088 Comm: b363492833 Not tainted 6.11.0-virtme #1011 [ 67.890183] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 67.890309] RIP: 0010:skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891043] Call Trace: [ 67.891173] [ 67.891274] ? __warn (kernel/panic.c:741) [ 67.891320] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891333] ? report_bug (lib/bug.c:180 lib/bug.c:219) [ 67.891348] ? handle_bug (arch/x86/kernel/traps.c:239) [ 67.891363] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) [ 67.891372] ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621) [ 67.891388] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891399] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2)) [ 67.891416] ip_do_fragment (net/ipv4/ip_output.c:777 (discriminator 1)) [ 67.891448] ? __ip_local_out (./include/linux/skbuff.h:1146 ./include/net/l3mdev.h:196 ./include/net/l3mdev.h:213 ne ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49948", "url": "https://ubuntu.com/security/CVE-2024-49948", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: add more sanity checks to qdisc_pkt_len_init() One path takes care of SKB_GSO_DODGY, assuming skb->len is bigger than hdr_len. virtio_net_hdr_to_skb() does not fully dissect TCP headers, it only make sure it is at least 20 bytes. It is possible for an user to provide a malicious 'GSO' packet, total length of 80 bytes. - 20 bytes of IPv4 header - 60 bytes TCP header - a small gso_size like 8 virtio_net_hdr_to_skb() would declare this packet as a normal GSO packet, because it would see 40 bytes of payload, bigger than gso_size. We need to make detect this case to not underflow qdisc_skb_cb(skb)->pkt_len.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49949", "url": "https://ubuntu.com/security/CVE-2024-49949", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: avoid potential underflow in qdisc_pkt_len_init() with UFO After commit 7c6d2ecbda83 (\"net: be more gentle about silly gso requests coming from user\") virtio_net_hdr_to_skb() had sanity check to detect malicious attempts from user space to cook a bad GSO packet. Then commit cf9acc90c80ec (\"net: virtio_net_hdr_to_skb: count transport header in UFO\") while fixing one issue, allowed user space to cook a GSO packet with the following characteristic : IPv4 SKB_GSO_UDP, gso_size=3, skb->len = 28. When this packet arrives in qdisc_pkt_len_init(), we end up with hdr_len = 28 (IPv4 header + UDP header), matching skb->len Then the following sets gso_segs to 0 : gso_segs = DIV_ROUND_UP(skb->len - hdr_len, shinfo->gso_size); Then later we set qdisc_skb_cb(skb)->pkt_len to back to zero :/ qdisc_skb_cb(skb)->pkt_len += (gso_segs - 1) * hdr_len; This leads to the following crash in fq_codel [1] qdisc_pkt_len_init() is best effort, we only want an estimation of the bytes sent on the wire, not crashing the kernel. This patch is fixing this particular issue, a following one adds more sanity checks for another potential bug. [1] [ 70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 70.724561] #PF: supervisor read access in kernel mode [ 70.724561] #PF: error_code(0x0000) - not-present page [ 70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0 [ 70.724561] Oops: Oops: 0000 [#1] SMP NOPTI [ 70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991 [ 70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel [ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 <49> 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49 All code ======== 0:\t24 08 \tand $0x8,%al 2:\t49 c1 e1 06 \tshl $0x6,%r9 6:\t44 89 7c 24 18 \tmov %r15d,0x18(%rsp) b:\t45 31 ed \txor %r13d,%r13d e:\t45 31 c0 \txor %r8d,%r8d 11:\t31 ff \txor %edi,%edi 13:\t89 44 24 14 \tmov %eax,0x14(%rsp) 17:\t4c 03 8b 90 01 00 00 \tadd 0x190(%rbx),%r9 1e:\teb 04 \tjmp 0x24 20:\t39 ca \tcmp %ecx,%edx 22:\t73 37 \tjae 0x5b 24:\t4d 8b 39 \tmov (%r9),%r15 27:\t83 c7 01 \tadd $0x1,%edi 2a:*\t49 8b 17 \tmov (%r15),%rdx\t\t<-- trapping instruction 2d:\t49 89 11 \tmov %rdx,(%r9) 30:\t41 8b 57 28 \tmov 0x28(%r15),%edx 34:\t45 8b 5f 34 \tmov 0x34(%r15),%r11d 38:\t49 c7 07 00 00 00 00 \tmovq $0x0,(%r15) 3f:\t49 \trex.WB Code starting with the faulting instruction =========================================== 0:\t49 8b 17 \tmov (%r15),%rdx 3:\t49 89 11 \tmov %rdx,(%r9) 6:\t41 8b 57 28 \tmov 0x28(%r15),%edx a:\t45 8b 5f 34 \tmov 0x34(%r15),%r11d e:\t49 c7 07 00 00 00 00 \tmovq $0x0,(%r15) 15:\t49 \trex.WB [ 70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202 [ 70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000 [ 70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001 [ 70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000 [ 70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58 [ 70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000 [ 70.724561] FS: 000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000 [ 70.724561] CS: 0010 DS: 0000 ES: 0000 C ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49997", "url": "https://ubuntu.com/security/CVE-2024-49997", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: ethernet: lantiq_etop: fix memory disclosure When applying padding, the buffer is not zeroed, which results in memory disclosure. The mentioned data is observed on the wire. This patch uses skb_put_padto() to pad Ethernet frames properly. The mentioned function zeroes the expanded buffer. In case the packet cannot be padded it is silently dropped. Statistics are also not incremented. This driver does not support statistics in the old 32-bit format or the new 64-bit format. These will be added in the future. In its current form, the patch should be easily backported to stable versions. Ethernet MACs on Amazon-SE and Danube cannot do padding of the packets in hardware, so software padding must be applied.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49998", "url": "https://ubuntu.com/security/CVE-2024-49998", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: dsa: improve shutdown sequence Alexander Sverdlin presents 2 problems during shutdown with the lan9303 driver. One is specific to lan9303 and the other just happens to reproduce there. The first problem is that lan9303 is unique among DSA drivers in that it calls dev_get_drvdata() at \"arbitrary runtime\" (not probe, not shutdown, not remove): phy_state_machine() -> ... -> dsa_user_phy_read() -> ds->ops->phy_read() -> lan9303_phy_read() -> chip->ops->phy_read() -> lan9303_mdio_phy_read() -> dev_get_drvdata() But we never stop the phy_state_machine(), so it may continue to run after dsa_switch_shutdown(). Our common pattern in all DSA drivers is to set drvdata to NULL to suppress the remove() method that may come afterwards. But in this case it will result in an NPD. The second problem is that the way in which we set dp->conduit->dsa_ptr = NULL; is concurrent with receive packet processing. dsa_switch_rcv() checks once whether dev->dsa_ptr is NULL, but afterwards, rather than continuing to use that non-NULL value, dev->dsa_ptr is dereferenced again and again without NULL checks: dsa_conduit_find_user() and many other places. In between dereferences, there is no locking to ensure that what was valid once continues to be valid. Both problems have the common aspect that closing the conduit interface solves them. In the first case, dev_close(conduit) triggers the NETDEV_GOING_DOWN event in dsa_user_netdevice_event() which closes user ports as well. dsa_port_disable_rt() calls phylink_stop(), which synchronously stops the phylink state machine, and ds->ops->phy_read() will thus no longer call into the driver after this point. In the second case, dev_close(conduit) should do this, as per Documentation/networking/driver.rst: | Quiescence | ---------- | | After the ndo_stop routine has been called, the hardware must | not receive or transmit any data. All in flight packets must | be aborted. If necessary, poll or wait for completion of | any reset commands. So it should be sufficient to ensure that later, when we zeroize conduit->dsa_ptr, there will be no concurrent dsa_switch_rcv() call on this conduit. The addition of the netif_device_detach() function is to ensure that ioctls, rtnetlinks and ethtool requests on the user ports no longer propagate down to the driver - we're no longer prepared to handle them. The race condition actually did not exist when commit 0650bf52b31f (\"net: dsa: be compatible with masters which unregister on shutdown\") first introduced dsa_switch_shutdown(). It was created later, when we stopped unregistering the user interfaces from a bad spot, and we just replaced that sequence with a racy zeroization of conduit->dsa_ptr (one which doesn't ensure that the interfaces aren't up).", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49999", "url": "https://ubuntu.com/security/CVE-2024-49999", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: afs: Fix the setting of the server responding flag In afs_wait_for_operation(), we set transcribe the call responded flag to the server record that we used after doing the fileserver iteration loop - but it's possible to exit the loop having had a response from the server that we've discarded (e.g. it returned an abort or we started receiving data, but the call didn't complete). This means that op->server might be NULL, but we don't check that before attempting to set the server flag.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49950", "url": "https://ubuntu.com/security/CVE-2024-49950", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix uaf in l2cap_connect [Syzbot reported] BUG: KASAN: slab-use-after-free in l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 Read of size 8 at addr ffff8880241e9800 by task kworker/u9:0/54 CPU: 0 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-00268-g788220eee30d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Workqueue: hci2 hci_rx_work Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:119 print_address_description mm/kasan/report.c:377 [inline] print_report+0xc3/0x620 mm/kasan/report.c:488 kasan_report+0xd9/0x110 mm/kasan/report.c:601 l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 l2cap_connect_req net/bluetooth/l2cap_core.c:4080 [inline] l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:4772 [inline] l2cap_sig_channel net/bluetooth/l2cap_core.c:5543 [inline] l2cap_recv_frame+0xf0b/0x8eb0 net/bluetooth/l2cap_core.c:6825 l2cap_recv_acldata+0x9b4/0xb70 net/bluetooth/l2cap_core.c:7514 hci_acldata_packet net/bluetooth/hci_core.c:3791 [inline] hci_rx_work+0xaab/0x1610 net/bluetooth/hci_core.c:4028 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 ... Freed by task 5245: 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:579 poison_slab_object+0xf7/0x160 mm/kasan/common.c:240 __kasan_slab_free+0x32/0x50 mm/kasan/common.c:256 kasan_slab_free include/linux/kasan.h:184 [inline] slab_free_hook mm/slub.c:2256 [inline] slab_free mm/slub.c:4477 [inline] kfree+0x12a/0x3b0 mm/slub.c:4598 l2cap_conn_free net/bluetooth/l2cap_core.c:1810 [inline] kref_put include/linux/kref.h:65 [inline] l2cap_conn_put net/bluetooth/l2cap_core.c:1822 [inline] l2cap_conn_del+0x59d/0x730 net/bluetooth/l2cap_core.c:1802 l2cap_connect_cfm+0x9e6/0xf80 net/bluetooth/l2cap_core.c:7241 hci_connect_cfm include/net/bluetooth/hci_core.h:1960 [inline] hci_conn_failed+0x1c3/0x370 net/bluetooth/hci_conn.c:1265 hci_abort_conn_sync+0x75a/0xb50 net/bluetooth/hci_sync.c:5583 abort_conn_sync+0x197/0x360 net/bluetooth/hci_conn.c:2917 hci_cmd_sync_work+0x1a4/0x410 net/bluetooth/hci_sync.c:328 process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231 process_scheduled_works kernel/workqueue.c:3312 [inline] worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389 kthread+0x2c1/0x3a0 kernel/kthread.c:389 ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49951", "url": "https://ubuntu.com/security/CVE-2024-49951", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Fix possible crash on mgmt_index_removed If mgmt_index_removed is called while there are commands queued on cmd_sync it could lead to crashes like the bellow trace: 0x0000053D: __list_del_entry_valid_or_report+0x98/0xdc 0x0000053D: mgmt_pending_remove+0x18/0x58 [bluetooth] 0x0000053E: mgmt_remove_adv_monitor_complete+0x80/0x108 [bluetooth] 0x0000053E: hci_cmd_sync_work+0xbc/0x164 [bluetooth] So while handling mgmt_index_removed this attempts to dequeue commands passed as user_data to cmd_sync.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49952", "url": "https://ubuntu.com/security/CVE-2024-49952", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: prevent nf_skb_duplicated corruption syzbot found that nf_dup_ipv4() or nf_dup_ipv6() could write per-cpu variable nf_skb_duplicated in an unsafe way [1]. Disabling preemption as hinted by the splat is not enough, we have to disable soft interrupts as well. [1] BUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316 caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 CPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49 nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87 nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x4ad/0x1da0 net/netfilter/nf_tables_core.c:288 nft_do_chain_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xc3/0x220 net/netfilter/core.c:626 nf_hook+0x2c4/0x450 include/linux/netfilter.h:269 NF_HOOK_COND include/linux/netfilter.h:302 [inline] ip_output+0x185/0x230 net/ipv4/ip_output.c:433 ip_local_out net/ipv4/ip_output.c:129 [inline] ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495 udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981 udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x1a6/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737 __do_sys_sendmmsg net/socket.c:2766 [inline] __se_sys_sendmmsg net/socket.c:2763 [inline] __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763 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:0x7f4ce4f7def9 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:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133 RAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9 RDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006 RBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49953", "url": "https://ubuntu.com/security/CVE-2024-49953", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix crash caused by calling __xfrm_state_delete() twice The km.state is not checked in driver's delayed work. When xfrm_state_check_expire() is called, the state can be reset to XFRM_STATE_EXPIRED, even if it is XFRM_STATE_DEAD already. This happens when xfrm state is deleted, but not freed yet. As __xfrm_state_delete() is called again in xfrm timer, the following crash occurs. To fix this issue, skip xfrm_state_check_expire() if km.state is not XFRM_STATE_VALID. Oops: general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] SMP CPU: 5 UID: 0 PID: 7448 Comm: kworker/u102:2 Not tainted 6.11.0-rc2+ #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5e_ipsec: eth%d mlx5e_ipsec_handle_sw_limits [mlx5_core] RIP: 0010:__xfrm_state_delete+0x3d/0x1b0 Code: 0f 84 8b 01 00 00 48 89 fd c6 87 c8 00 00 00 05 48 8d bb 40 10 00 00 e8 11 04 1a 00 48 8b 95 b8 00 00 00 48 8b 85 c0 00 00 00 <48> 89 42 08 48 89 10 48 8b 55 10 48 b8 00 01 00 00 00 00 ad de 48 RSP: 0018:ffff88885f945ec8 EFLAGS: 00010246 RAX: dead000000000122 RBX: ffffffff82afa940 RCX: 0000000000000036 RDX: dead000000000100 RSI: 0000000000000000 RDI: ffffffff82afb980 RBP: ffff888109a20340 R08: ffff88885f945ea0 R09: 0000000000000000 R10: 0000000000000000 R11: ffff88885f945ff8 R12: 0000000000000246 R13: ffff888109a20340 R14: ffff88885f95f420 R15: ffff88885f95f400 FS: 0000000000000000(0000) GS:ffff88885f940000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2163102430 CR3: 00000001128d6001 CR4: 0000000000370eb0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? die_addr+0x33/0x90 ? exc_general_protection+0x1a2/0x390 ? asm_exc_general_protection+0x22/0x30 ? __xfrm_state_delete+0x3d/0x1b0 ? __xfrm_state_delete+0x2f/0x1b0 xfrm_timer_handler+0x174/0x350 ? __xfrm_state_delete+0x1b0/0x1b0 __hrtimer_run_queues+0x121/0x270 hrtimer_run_softirq+0x88/0xd0 handle_softirqs+0xcc/0x270 do_softirq+0x3c/0x50 __local_bh_enable_ip+0x47/0x50 mlx5e_ipsec_handle_sw_limits+0x7d/0x90 [mlx5_core] process_one_work+0x137/0x2d0 worker_thread+0x28d/0x3a0 ? rescuer_thread+0x480/0x480 kthread+0xb8/0xe0 ? kthread_park+0x80/0x80 ret_from_fork+0x2d/0x50 ? kthread_park+0x80/0x80 ret_from_fork_asm+0x11/0x20 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50000", "url": "https://ubuntu.com/security/CVE-2024-50000", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix NULL deref in mlx5e_tir_builder_alloc() In mlx5e_tir_builder_alloc() kvzalloc() may return NULL which is dereferenced on the next line in a reference to the modify field. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50001", "url": "https://ubuntu.com/security/CVE-2024-50001", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix error path in multi-packet WQE transmit Remove the erroneous unmap in case no DMA mapping was established The multi-packet WQE transmit code attempts to obtain a DMA mapping for the skb. This could fail, e.g. under memory pressure, when the IOMMU driver just can't allocate more memory for page tables. While the code tries to handle this in the path below the err_unmap label it erroneously unmaps one entry from the sq's FIFO list of active mappings. Since the current map attempt failed this unmap is removing some random DMA mapping that might still be required. If the PCI function now presents that IOVA, the IOMMU may assumes a rogue DMA access and e.g. on s390 puts the PCI function in error state. The erroneous behavior was seen in a stress-test environment that created memory pressure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50179", "url": "https://ubuntu.com/security/CVE-2024-50179", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ceph: remove the incorrect Fw reference check when dirtying pages When doing the direct-io reads it will also try to mark pages dirty, but for the read path it won't hold the Fw caps and there is case will it get the Fw reference.", "cve_priority": "medium", "cve_public_date": "2024-11-08 06:15:00 UTC" }, { "cve": "CVE-2024-49963", "url": "https://ubuntu.com/security/CVE-2024-49963", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mailbox: bcm2835: Fix timeout during suspend mode During noirq suspend phase the Raspberry Pi power driver suffer of firmware property timeouts. The reason is that the IRQ of the underlying BCM2835 mailbox is disabled and rpi_firmware_property_list() will always run into a timeout [1]. Since the VideoCore side isn't consider as a wakeup source, set the IRQF_NO_SUSPEND flag for the mailbox IRQ in order to keep it enabled during suspend-resume cycle. [1] PM: late suspend of devices complete after 1.754 msecs WARNING: CPU: 0 PID: 438 at drivers/firmware/raspberrypi.c:128 rpi_firmware_property_list+0x204/0x22c Firmware transaction 0x00028001 timeout Modules linked in: CPU: 0 PID: 438 Comm: bash Tainted: G C 6.9.3-dirty #17 Hardware name: BCM2835 Call trace: unwind_backtrace from show_stack+0x18/0x1c show_stack from dump_stack_lvl+0x34/0x44 dump_stack_lvl from __warn+0x88/0xec __warn from warn_slowpath_fmt+0x7c/0xb0 warn_slowpath_fmt from rpi_firmware_property_list+0x204/0x22c rpi_firmware_property_list from rpi_firmware_property+0x68/0x8c rpi_firmware_property from rpi_firmware_set_power+0x54/0xc0 rpi_firmware_set_power from _genpd_power_off+0xe4/0x148 _genpd_power_off from genpd_sync_power_off+0x7c/0x11c genpd_sync_power_off from genpd_finish_suspend+0xcc/0xe0 genpd_finish_suspend from dpm_run_callback+0x78/0xd0 dpm_run_callback from device_suspend_noirq+0xc0/0x238 device_suspend_noirq from dpm_suspend_noirq+0xb0/0x168 dpm_suspend_noirq from suspend_devices_and_enter+0x1b8/0x5ac suspend_devices_and_enter from pm_suspend+0x254/0x2e4 pm_suspend from state_store+0xa8/0xd4 state_store from kernfs_fop_write_iter+0x154/0x1a0 kernfs_fop_write_iter from vfs_write+0x12c/0x184 vfs_write from ksys_write+0x78/0xc0 ksys_write from ret_fast_syscall+0x0/0x54 Exception stack(0xcc93dfa8 to 0xcc93dff0) [...] PM: noirq suspend of devices complete after 3095.584 msecs", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-49954", "url": "https://ubuntu.com/security/CVE-2024-49954", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: static_call: Replace pointless WARN_ON() in static_call_module_notify() static_call_module_notify() triggers a WARN_ON(), when memory allocation fails in __static_call_add_module(). That's not really justified, because the failure case must be correctly handled by the well known call chain and the error code is passed through to the initiating userspace application. A memory allocation fail is not a fatal problem, but the WARN_ON() takes the machine out when panic_on_warn is set. Replace it with a pr_warn().", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-50002", "url": "https://ubuntu.com/security/CVE-2024-50002", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: static_call: Handle module init failure correctly in static_call_del_module() Module insertion invokes static_call_add_module() to initialize the static calls in a module. static_call_add_module() invokes __static_call_init(), which allocates a struct static_call_mod to either encapsulate the built-in static call sites of the associated key into it so further modules can be added or to append the module to the module chain. If that allocation fails the function returns with an error code and the module core invokes static_call_del_module() to clean up eventually added static_call_mod entries. This works correctly, when all keys used by the module were converted over to a module chain before the failure. If not then static_call_del_module() causes a #GP as it blindly assumes that key::mods points to a valid struct static_call_mod. The problem is that key::mods is not a individual struct member of struct static_call_key, it's part of a union to save space: union { /* bit 0: 0 = mods, 1 = sites */ unsigned long type; struct static_call_mod *mods; struct static_call_site *sites; \t}; key::sites is a pointer to the list of built-in usage sites of the static call. The type of the pointer is differentiated by bit 0. A mods pointer has the bit clear, the sites pointer has the bit set. As static_call_del_module() blidly assumes that the pointer is a valid static_call_mod type, it fails to check for this failure case and dereferences the pointer to the list of built-in call sites, which is obviously bogus. Cure it by checking whether the key has a sites or a mods pointer. If it's a sites pointer then the key is not to be touched. As the sites are walked in the same order as in __static_call_init() the site walk can be terminated because all subsequent sites have not been touched by the init code due to the error exit. If it was converted before the allocation fail, then the inner loop which searches for a module match will find nothing. A fail in the second allocation in __static_call_init() is harmless and does not require special treatment. The first allocation succeeded and converted the key to a module chain. That first entry has mod::mod == NULL and mod::next == NULL, so the inner loop of static_call_del_module() will neither find a module match nor a module chain. The next site in the walk was either already converted, but can't match the module, or it will exit the outer loop because it has a static_call_site pointer and not a static_call_mod pointer.", "cve_priority": "medium", "cve_public_date": "2024-10-21 18:15:00 UTC" }, { "cve": "CVE-2024-47675", "url": "https://ubuntu.com/security/CVE-2024-47675", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix use-after-free in bpf_uprobe_multi_link_attach() If bpf_link_prime() fails, bpf_uprobe_multi_link_attach() goes to the error_free label and frees the array of bpf_uprobe's without calling bpf_uprobe_unregister(). This leaks bpf_uprobe->uprobe and worse, this frees bpf_uprobe->consumer without removing it from the uprobe->consumers list.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47676", "url": "https://ubuntu.com/security/CVE-2024-47676", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm/hugetlb.c: fix UAF of vma in hugetlb fault pathway Syzbot reports a UAF in hugetlb_fault(). This happens because vmf_anon_prepare() could drop the per-VMA lock and allow the current VMA to be freed before hugetlb_vma_unlock_read() is called. We can fix this by using a modified version of vmf_anon_prepare() that doesn't release the VMA lock on failure, and then release it ourselves after hugetlb_vma_unlock_read().", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47677", "url": "https://ubuntu.com/security/CVE-2024-47677", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: exfat: resolve memory leak from exfat_create_upcase_table() If exfat_load_upcase_table reaches end and returns -EINVAL, allocated memory doesn't get freed and while exfat_load_default_upcase_table allocates more memory, leading to a memory leak. Here's link to syzkaller crash report illustrating this issue: https://syzkaller.appspot.com/text?tag=CrashReport&x=1406c201980000", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47725", "url": "https://ubuntu.com/security/CVE-2024-47725", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47739", "url": "https://ubuntu.com/security/CVE-2024-47739", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: padata: use integer wrap around to prevent deadlock on seq_nr overflow When submitting more than 2^32 padata objects to padata_do_serial, the current sorting implementation incorrectly sorts padata objects with overflowed seq_nr, causing them to be placed before existing objects in the reorder list. This leads to a deadlock in the serialization process as padata_find_next cannot match padata->seq_nr and pd->processed because the padata instance with overflowed seq_nr will be selected next. To fix this, we use an unsigned integer wrap around to correctly sort padata objects in scenarios with integer overflow.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47678", "url": "https://ubuntu.com/security/CVE-2024-47678", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: icmp: change the order of rate limits ICMP messages are ratelimited : After the blamed commits, the two rate limiters are applied in this order: 1) host wide ratelimit (icmp_global_allow()) 2) Per destination ratelimit (inetpeer based) In order to avoid side-channels attacks, we need to apply the per destination check first. This patch makes the following change : 1) icmp_global_allow() checks if the host wide limit is reached. But credits are not yet consumed. This is deferred to 3) 2) The per destination limit is checked/updated. This might add a new node in inetpeer tree. 3) icmp_global_consume() consumes tokens if prior operations succeeded. This means that host wide ratelimit is still effective in keeping inetpeer tree small even under DDOS. As a bonus, I removed icmp_global.lock as the fast path can use a lock-free operation.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47733", "url": "https://ubuntu.com/security/CVE-2024-47733", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfs: Delete subtree of 'fs/netfs' when netfs module exits In netfs_init() or fscache_proc_init(), we create dentry under 'fs/netfs', but in netfs_exit(), we only delete the proc entry of 'fs/netfs' without deleting its subtree. This triggers the following WARNING: ================================================================== remove_proc_entry: removing non-empty directory 'fs/netfs', leaking at least 'requests' WARNING: CPU: 4 PID: 566 at fs/proc/generic.c:717 remove_proc_entry+0x160/0x1c0 Modules linked in: netfs(-) CPU: 4 UID: 0 PID: 566 Comm: rmmod Not tainted 6.11.0-rc3 #860 RIP: 0010:remove_proc_entry+0x160/0x1c0 Call Trace: netfs_exit+0x12/0x620 [netfs] __do_sys_delete_module.isra.0+0x14c/0x2e0 do_syscall_64+0x4b/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e ================================================================== Therefore use remove_proc_subtree() instead of remove_proc_entry() to fix the above problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47679", "url": "https://ubuntu.com/security/CVE-2024-47679", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vfs: fix race between evice_inodes() and find_inode()&iput() Hi, all Recently I noticed a bug[1] in btrfs, after digged it into and I believe it'a race in vfs. Let's assume there's a inode (ie ino 261) with i_count 1 is called by iput(), and there's a concurrent thread calling generic_shutdown_super(). cpu0: cpu1: iput() // i_count is 1 ->spin_lock(inode) ->dec i_count to 0 ->iput_final() generic_shutdown_super() ->__inode_add_lru() ->evict_inodes() // cause some reason[2] ->if (atomic_read(inode->i_count)) continue; // return before // inode 261 passed the above check // list_lru_add_obj() // and then schedule out ->spin_unlock() // note here: the inode 261 // was still at sb list and hash list, // and I_FREEING|I_WILL_FREE was not been set btrfs_iget() // after some function calls ->find_inode() // found the above inode 261 ->spin_lock(inode) // check I_FREEING|I_WILL_FREE // and passed ->__iget() ->spin_unlock(inode) // schedule back ->spin_lock(inode) // check (I_NEW|I_FREEING|I_WILL_FREE) flags, // passed and set I_FREEING iput() ->spin_unlock(inode) ->spin_lock(inode)\t\t\t ->evict() // dec i_count to 0 ->iput_final() ->spin_unlock() ->evict() Now, we have two threads simultaneously evicting the same inode, which may trigger the BUG(inode->i_state & I_CLEAR) statement both within clear_inode() and iput(). To fix the bug, recheck the inode->i_count after holding i_lock. Because in the most scenarios, the first check is valid, and the overhead of spin_lock() can be reduced. If there is any misunderstanding, please let me know, thanks. [1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/ [2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable() return false when I reproduced the bug.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49859", "url": "https://ubuntu.com/security/CVE-2024-49859", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to check atomic_file in f2fs ioctl interfaces Some f2fs ioctl interfaces like f2fs_ioc_set_pin_file(), f2fs_move_file_range(), and f2fs_defragment_range() missed to check atomic_write status, which may cause potential race issue, fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47680", "url": "https://ubuntu.com/security/CVE-2024-47680", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: check discard support for conventional zones As the helper function f2fs_bdev_support_discard() shows, f2fs checks if the target block devices support discard by calling bdev_max_discard_sectors() and bdev_is_zoned(). This check works well for most cases, but it does not work for conventional zones on zoned block devices. F2fs assumes that zoned block devices support discard, and calls __submit_discard_cmd(). When __submit_discard_cmd() is called for sequential write required zones, it works fine since __submit_discard_cmd() issues zone reset commands instead of discard commands. However, when __submit_discard_cmd() is called for conventional zones, __blkdev_issue_discard() is called even when the devices do not support discard. The inappropriate __blkdev_issue_discard() call was not a problem before the commit 30f1e7241422 (\"block: move discard checks into the ioctl handler\") because __blkdev_issue_discard() checked if the target devices support discard or not. If not, it returned EOPNOTSUPP. After the commit, __blkdev_issue_discard() no longer checks it. It always returns zero and sets NULL to the given bio pointer. This NULL pointer triggers f2fs_bug_on() in __submit_discard_cmd(). The BUG is recreated with the commands below at the umount step, where /dev/nullb0 is a zoned null_blk with 5GB total size, 128MB zone size and 10 conventional zones. $ mkfs.f2fs -f -m /dev/nullb0 $ mount /dev/nullb0 /mnt $ for ((i=0;i<5;i++)); do dd if=/dev/zero of=/mnt/test bs=65536 count=1600 conv=fsync; done $ umount /mnt To fix the BUG, avoid the inappropriate __blkdev_issue_discard() call. When discard is requested for conventional zones, check if the device supports discard or not. If not, return EOPNOTSUPP.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47740", "url": "https://ubuntu.com/security/CVE-2024-47740", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: Require FMODE_WRITE for atomic write ioctls The F2FS ioctls for starting and committing atomic writes check for inode_owner_or_capable(), but this does not give LSMs like SELinux or Landlock an opportunity to deny the write access - if the caller's FSUID matches the inode's UID, inode_owner_or_capable() immediately returns true. There are scenarios where LSMs want to deny a process the ability to write particular files, even files that the FSUID of the process owns; but this can currently partially be bypassed using atomic write ioctls in two ways: - F2FS_IOC_START_ATOMIC_REPLACE + F2FS_IOC_COMMIT_ATOMIC_WRITE can truncate an inode to size 0 - F2FS_IOC_START_ATOMIC_WRITE + F2FS_IOC_ABORT_ATOMIC_WRITE can revert changes another process concurrently made to a file Fix it by requiring FMODE_WRITE for these operations, just like for F2FS_IOC_MOVE_RANGE. Since any legitimate caller should only be using these ioctls when intending to write into the file, that seems unlikely to break anything.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47726", "url": "https://ubuntu.com/security/CVE-2024-47726", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to wait dio completion It should wait all existing dio write IOs before block removal, otherwise, previous direct write IO may overwrite data in the block which may be reused by other inode.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47741", "url": "https://ubuntu.com/security/CVE-2024-47741", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race setting file private on concurrent lseek using same fd When doing concurrent lseek(2) system calls against the same file descriptor, using multiple threads belonging to the same process, we have a short time window where a race happens and can result in a memory leak. The race happens like this: 1) A program opens a file descriptor for a file and then spawns two threads (with the pthreads library for example), lets call them task A and task B; 2) Task A calls lseek with SEEK_DATA or SEEK_HOLE and ends up at file.c:find_desired_extent() while holding a read lock on the inode; 3) At the start of find_desired_extent(), it extracts the file's private_data pointer into a local variable named 'private', which has a value of NULL; 4) Task B also calls lseek with SEEK_DATA or SEEK_HOLE, locks the inode in shared mode and enters file.c:find_desired_extent(), where it also extracts file->private_data into its local variable 'private', which has a NULL value; 5) Because it saw a NULL file private, task A allocates a private structure and assigns to the file structure; 6) Task B also saw a NULL file private so it also allocates its own file private and then assigns it to the same file structure, since both tasks are using the same file descriptor. At this point we leak the private structure allocated by task A. Besides the memory leak, there's also the detail that both tasks end up using the same cached state record in the private structure (struct btrfs_file_private::llseek_cached_state), which can result in a use-after-free problem since one task can free it while the other is still using it (only one task took a reference count on it). Also, sharing the cached state is not a good idea since it could result in incorrect results in the future - right now it should not be a problem because it end ups being used only in extent-io-tree.c:count_range_bits() where we do range validation before using the cached state. Fix this by protecting the private assignment and check of a file while holding the inode's spinlock and keep track of the task that allocated the private, so that it's used only by that task in order to prevent user-after-free issues with the cached state record as well as potentially using it incorrectly in the future.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47681", "url": "https://ubuntu.com/security/CVE-2024-47681", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: fix NULL pointer dereference in mt7996_mcu_sta_bfer_he Fix the NULL pointer dereference in mt7996_mcu_sta_bfer_he routine adding an sta interface to the mt7996 driver. Found by code review.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49858", "url": "https://ubuntu.com/security/CVE-2024-49858", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption The TPM event log table is a Linux specific construct, where the data produced by the GetEventLog() boot service is cached in memory, and passed on to the OS using an EFI configuration table. The use of EFI_LOADER_DATA here results in the region being left unreserved in the E820 memory map constructed by the EFI stub, and this is the memory description that is passed on to the incoming kernel by kexec, which is therefore unaware that the region should be reserved. Even though the utility of the TPM2 event log after a kexec is questionable, any corruption might send the parsing code off into the weeds and crash the kernel. So let's use EFI_ACPI_RECLAIM_MEMORY instead, which is always treated as reserved by the E820 conversion logic.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49860", "url": "https://ubuntu.com/security/CVE-2024-49860", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ACPI: sysfs: validate return type of _STR method Only buffer objects are valid return values of _STR. If something else is returned description_show() will access invalid memory.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47742", "url": "https://ubuntu.com/security/CVE-2024-47742", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware_loader: Block path traversal Most firmware names are hardcoded strings, or are constructed from fairly constrained format strings where the dynamic parts are just some hex numbers or such. However, there are a couple codepaths in the kernel where firmware file names contain string components that are passed through from a device or semi-privileged userspace; the ones I could find (not counting interfaces that require root privileges) are: - lpfc_sli4_request_firmware_update() seems to construct the firmware filename from \"ModelName\", a string that was previously parsed out of some descriptor (\"Vital Product Data\") in lpfc_fill_vpd() - nfp_net_fw_find() seems to construct a firmware filename from a model name coming from nfp_hwinfo_lookup(pf->hwinfo, \"nffw.partno\"), which I think parses some descriptor that was read from the device. (But this case likely isn't exploitable because the format string looks like \"netronome/nic_%s\", and there shouldn't be any *folders* starting with \"netronome/nic_\". The previous case was different because there, the \"%s\" is *at the start* of the format string.) - module_flash_fw_schedule() is reachable from the ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is enough to pass the privilege check), and takes a userspace-provided firmware name. (But I think to reach this case, you need to have CAP_NET_ADMIN over a network namespace that a special kind of ethernet device is mapped into, so I think this is not a viable attack path in practice.) Fix it by rejecting any firmware names containing \"..\" path components. For what it's worth, I went looking and haven't found any USB device drivers that use the firmware loader dangerously.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47682", "url": "https://ubuntu.com/security/CVE-2024-47682", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: sd: Fix off-by-one error in sd_read_block_characteristics() Ff the device returns page 0xb1 with length 8 (happens with qemu v2.x, for example), sd_read_block_characteristics() may attempt an out-of-bounds memory access when accessing the zoned field at offset 8.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47743", "url": "https://ubuntu.com/security/CVE-2024-47743", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KEYS: prevent NULL pointer dereference in find_asymmetric_key() In find_asymmetric_key(), if all NULLs are passed in the id_{0,1,2} arguments, the kernel will first emit WARN but then have an oops because id_2 gets dereferenced anyway. Add the missing id_2 check and move WARN_ON() to the final else branch to avoid duplicate NULL checks. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47727", "url": "https://ubuntu.com/security/CVE-2024-47727", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/tdx: Fix \"in-kernel MMIO\" check TDX only supports kernel-initiated MMIO operations. The handle_mmio() function checks if the #VE exception occurred in the kernel and rejects the operation if it did not. However, userspace can deceive the kernel into performing MMIO on its behalf. For example, if userspace can point a syscall to an MMIO address, syscall does get_user() or put_user() on it, triggering MMIO #VE. The kernel will treat the #VE as in-kernel MMIO. Ensure that the target MMIO address is within the kernel before decoding instruction.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47744", "url": "https://ubuntu.com/security/CVE-2024-47744", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: KVM: Use dedicated mutex to protect kvm_usage_count to avoid deadlock Use a dedicated mutex to guard kvm_usage_count to fix a potential deadlock on x86 due to a chain of locks and SRCU synchronizations. Translating the below lockdep splat, CPU1 #6 will wait on CPU0 #1, CPU0 #8 will wait on CPU2 #3, and CPU2 #7 will wait on CPU1 #4 (if there's a writer, due to the fairness of r/w semaphores). CPU0 CPU1 CPU2 1 lock(&kvm->slots_lock); 2 lock(&vcpu->mutex); 3 lock(&kvm->srcu); 4 lock(cpu_hotplug_lock); 5 lock(kvm_lock); 6 lock(&kvm->slots_lock); 7 lock(cpu_hotplug_lock); 8 sync(&kvm->srcu); Note, there are likely more potential deadlocks in KVM x86, e.g. the same pattern of taking cpu_hotplug_lock outside of kvm_lock likely exists with __kvmclock_cpufreq_notifier(): cpuhp_cpufreq_online() | -> cpufreq_online() | -> cpufreq_gov_performance_limits() | -> __cpufreq_driver_target() | -> __target_index() | -> cpufreq_freq_transition_begin() | -> cpufreq_notify_transition() | -> ... __kvmclock_cpufreq_notifier() But, actually triggering such deadlocks is beyond rare due to the combination of dependencies and timings involved. E.g. the cpufreq notifier is only used on older CPUs without a constant TSC, mucking with the NX hugepage mitigation while VMs are running is very uncommon, and doing so while also onlining/offlining a CPU (necessary to generate contention on cpu_hotplug_lock) would be even more unusual. The most robust solution to the general cpu_hotplug_lock issue is likely to switch vm_list to be an RCU-protected list, e.g. so that x86's cpufreq notifier doesn't to take kvm_lock. For now, settle for fixing the most blatant deadlock, as switching to an RCU-protected list is a much more involved change, but add a comment in locking.rst to call out that care needs to be taken when walking holding kvm_lock and walking vm_list. ====================================================== WARNING: possible circular locking dependency detected 6.10.0-smp--c257535a0c9d-pip #330 Tainted: G S O ------------------------------------------------------ tee/35048 is trying to acquire lock: ff6a80eced71e0a8 (&kvm->slots_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x179/0x1e0 [kvm] but task is already holding lock: ffffffffc07abb08 (kvm_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x14a/0x1e0 [kvm] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (kvm_lock){+.+.}-{3:3}: __mutex_lock+0x6a/0xb40 mutex_lock_nested+0x1f/0x30 kvm_dev_ioctl+0x4fb/0xe50 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #2 (cpu_hotplug_lock){++++}-{0:0}: cpus_read_lock+0x2e/0xb0 static_key_slow_inc+0x16/0x30 kvm_lapic_set_base+0x6a/0x1c0 [kvm] kvm_set_apic_base+0x8f/0xe0 [kvm] kvm_set_msr_common+0x9ae/0xf80 [kvm] vmx_set_msr+0xa54/0xbe0 [kvm_intel] __kvm_set_msr+0xb6/0x1a0 [kvm] kvm_arch_vcpu_ioctl+0xeca/0x10c0 [kvm] kvm_vcpu_ioctl+0x485/0x5b0 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (&kvm->srcu){.+.+}-{0:0}: __synchronize_srcu+0x44/0x1a0 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47719", "url": "https://ubuntu.com/security/CVE-2024-47719", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: iommufd: Protect against overflow of ALIGN() during iova allocation Userspace can supply an iova and uptr such that the target iova alignment becomes really big and ALIGN() overflows which corrupts the selected area range during allocation. CONFIG_IOMMUFD_TEST can detect this: WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline] WARNING: CPU: 1 PID: 5092 at drivers/iommu/iommufd/io_pagetable.c:268 iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352 Modules linked in: CPU: 1 PID: 5092 Comm: syz-executor294 Not tainted 6.10.0-rc5-syzkaller-00294-g3ffea9a7a6f7 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024 RIP: 0010:iopt_alloc_area_pages drivers/iommu/iommufd/io_pagetable.c:268 [inline] RIP: 0010:iopt_map_pages+0xf95/0x1050 drivers/iommu/iommufd/io_pagetable.c:352 Code: fc e9 a4 f3 ff ff e8 1a 8b 4c fc 41 be e4 ff ff ff e9 8a f3 ff ff e8 0a 8b 4c fc 90 0f 0b 90 e9 37 f5 ff ff e8 fc 8a 4c fc 90 <0f> 0b 90 e9 68 f3 ff ff 48 c7 c1 ec 82 ad 8f 80 e1 07 80 c1 03 38 RSP: 0018:ffffc90003ebf9e0 EFLAGS: 00010293 RAX: ffffffff85499fa4 RBX: 00000000ffffffef RCX: ffff888079b49e00 RDX: 0000000000000000 RSI: 00000000ffffffef RDI: 0000000000000000 RBP: ffffc90003ebfc50 R08: ffffffff85499b30 R09: ffffffff85499942 R10: 0000000000000002 R11: ffff888079b49e00 R12: ffff8880228e0010 R13: 0000000000000000 R14: 1ffff920007d7f68 R15: ffffc90003ebfd00 FS: 000055557d760380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000005fdeb8 CR3: 000000007404a000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: iommufd_ioas_copy+0x610/0x7b0 drivers/iommu/iommufd/ioas.c:274 iommufd_fops_ioctl+0x4d9/0x5a0 drivers/iommu/iommufd/main.c:421 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f Cap the automatic alignment to the huge page size, which is probably a better idea overall. Huge automatic alignments can fragment and chew up the available IOVA space without any reason.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47745", "url": "https://ubuntu.com/security/CVE-2024-47745", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: mm: call the security_mmap_file() LSM hook in remap_file_pages() The remap_file_pages syscall handler calls do_mmap() directly, which doesn't contain the LSM security check. And if the process has called personality(READ_IMPLIES_EXEC) before and remap_file_pages() is called for RW pages, this will actually result in remapping the pages to RWX, bypassing a W^X policy enforced by SELinux. So we should check prot by security_mmap_file LSM hook in the remap_file_pages syscall handler before do_mmap() is called. Otherwise, it potentially permits an attacker to bypass a W^X policy enforced by SELinux. The bypass is similar to CVE-2016-10044, which bypass the same thing via AIO and can be found in [1]. The PoC: $ cat > test.c int main(void) { \tsize_t pagesz = sysconf(_SC_PAGE_SIZE); \tint mfd = syscall(SYS_memfd_create, \"test\", 0); \tconst char *buf = mmap(NULL, 4 * pagesz, PROT_READ | PROT_WRITE, \t\tMAP_SHARED, mfd, 0); \tunsigned int old = syscall(SYS_personality, 0xffffffff); \tsyscall(SYS_personality, READ_IMPLIES_EXEC | old); \tsyscall(SYS_remap_file_pages, buf, pagesz, 0, 2, 0); \tsyscall(SYS_personality, old); \t// show the RWX page exists even if W^X policy is enforced \tint fd = open(\"/proc/self/maps\", O_RDONLY); \tunsigned char buf2[1024]; \twhile (1) { \t\tint ret = read(fd, buf2, 1024); \t\tif (ret <= 0) break; \t\twrite(1, buf2, ret); \t} \tclose(fd); } $ gcc test.c -o test $ ./test | grep rwx 7f1836c34000-7f1836c35000 rwxs 00002000 00:01 2050 /memfd:test (deleted) [PM: subject line tweaks]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47746", "url": "https://ubuntu.com/security/CVE-2024-47746", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: fuse: use exclusive lock when FUSE_I_CACHE_IO_MODE is set This may be a typo. The comment has said shared locks are not allowed when this bit is set. If using shared lock, the wait in `fuse_file_cached_io_open` may be forever.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47734", "url": "https://ubuntu.com/security/CVE-2024-47734", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bonding: Fix unnecessary warnings and logs from bond_xdp_get_xmit_slave() syzbot reported a WARNING in bond_xdp_get_xmit_slave. To reproduce this[1], one bond device (bond1) has xdpdrv, which increases bpf_master_redirect_enabled_key. Another bond device (bond0) which is unsupported by XDP but its slave (veth3) has xdpgeneric that returns XDP_TX. This triggers WARN_ON_ONCE() from the xdp_master_redirect(). To reduce unnecessary warnings and improve log management, we need to delete the WARN_ON_ONCE() and add ratelimit to the netdev_err(). [1] Steps to reproduce: # Needs tx_xdp with return XDP_TX; ip l add veth0 type veth peer veth1 ip l add veth3 type veth peer veth4 ip l add bond0 type bond mode 6 # BOND_MODE_ALB, unsupported by XDP ip l add bond1 type bond # BOND_MODE_ROUNDROBIN by default ip l set veth0 master bond1 ip l set bond1 up # Increases bpf_master_redirect_enabled_key ip l set dev bond1 xdpdrv object tx_xdp.o section xdp_tx ip l set veth3 master bond0 ip l set bond0 up ip l set veth4 up # Triggers WARN_ON_ONCE() from the xdp_master_redirect() ip l set veth3 xdpgeneric object tx_xdp.o section xdp_tx", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47684", "url": "https://ubuntu.com/security/CVE-2024-47684", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tcp: check skb is non-NULL in tcp_rto_delta_us() We have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic kernel that are running ceph and recently hit a null ptr dereference in tcp_rearm_rto(). Initially hitting it from the TLP path, but then later we also saw it getting hit from the RACK case as well. Here are examples of the oops messages we saw in each of those cases: Jul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020 Jul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode Jul 26 15:05:02 rx [11061395.792971] #PF: error_code(0x0000) - not-present page Jul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0 Jul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI Jul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu Jul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023 Jul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 <48> 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3 Jul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246 Jul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000 Jul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60 Jul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8 Jul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900 Jul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30 Jul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000 Jul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0 Jul 26 15:05:02 rx [11061395.913822] PKRU: 55555554 Jul 26 15:05:02 rx [11061395.916786] Call Trace: Jul 26 15:05:02 rx [11061395.919488] Jul 26 15:05:02 rx [11061395.921765] ? show_regs.cold+0x1a/0x1f Jul 26 15:05:02 rx [11061395.925859] ? __die+0x90/0xd9 Jul 26 15:05:02 rx [11061395.929169] ? no_context+0x196/0x380 Jul 26 15:05:02 rx [11061395.933088] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0 Jul 26 15:05:02 rx [11061395.938216] ? ip6_sublist_rcv_finish+0x3d/0x50 Jul 26 15:05:02 rx [11061395.943000] ? __bad_area_nosemaphore+0x50/0x1a0 Jul 26 15:05:02 rx [11061395.947873] ? bad_area_nosemaphore+0x16/0x20 Jul 26 15:05:02 rx [11061395.952486] ? do_user_addr_fault+0x267/0x450 Jul 26 15:05:02 rx [11061395.957104] ? ipv6_list_rcv+0x112/0x140 Jul 26 15:05:02 rx [11061395.961279] ? __do_page_fault+0x58/0x90 Jul 26 15:05:02 rx [11061395.965458] ? do_page_fault+0x2c/0xe0 Jul 26 15:05:02 rx [11061395.969465] ? page_fault+0x34/0x40 Jul 26 15:05:02 rx [11061395.973217] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.977313] ? tcp_rearm_rto+0xe4/0x160 Jul 26 15:05:02 rx [11061395.981408] tcp_send_loss_probe+0x10b/0x220 Jul 26 15:05:02 rx [11061395.985937] tcp_write_timer_handler+0x1b4/0x240 Jul 26 15:05:02 rx [11061395.990809] tcp_write_timer+0x9e/0xe0 Jul 26 15:05:02 rx [11061395.994814] ? tcp_write_timer_handler+0x240/0x240 Jul 26 15:05:02 rx [11061395.999866] call_timer_fn+0x32/0x130 Jul 26 15:05:02 rx [11061396.003782] __run_timers.part.0+0x180/0x280 Jul 26 15:05:02 rx [11061396.008309] ? recalibrate_cpu_khz+0x10/0x10 Jul 26 15:05:02 rx [11061396.012841] ? native_x2apic_icr_write+0x30/0x30 Jul 26 15:05:02 rx [11061396.017718] ? lapic_next_even ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47747", "url": "https://ubuntu.com/security/CVE-2024-47747", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race Condition In the ether3_probe function, a timer is initialized with a callback function ether3_ledoff, bound to &prev(dev)->timer. Once the timer is started, there is a risk of a race condition if the module or device is removed, triggering the ether3_remove function to perform cleanup. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | ether3_ledoff ether3_remove | free_netdev(dev); | put_devic | kfree(dev); | | ether3_outw(priv(dev)->regs.config2 |= CFG2_CTRLO, REG_CONFIG2); | // use dev Fix it by ensuring that the timer is canceled before proceeding with the cleanup in ether3_remove.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47685", "url": "https://ubuntu.com/security/CVE-2024-47685", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put() syzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending garbage on the four reserved tcp bits (th->res1) Use skb_put_zero() to clear the whole TCP header, as done in nf_reject_ip_tcphdr_put() BUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5661 [inline] __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775 process_backlog+0x4ad/0xa50 net/core/dev.c:6108 __napi_poll+0xe7/0x980 net/core/dev.c:6772 napi_poll net/core/dev.c:6841 [inline] net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963 handle_softirqs+0x1ce/0x800 kernel/softirq.c:554 __do_softirq+0x14/0x1a kernel/softirq.c:588 do_softirq+0x9a/0x100 kernel/softirq.c:455 __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382 local_bh_enable include/linux/bottom_half.h:33 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline] __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450 dev_queue_xmit include/linux/netdevice.h:3105 [inline] neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565 neigh_output include/net/neighbour.h:542 [inline] ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141 __ip6_finish_output net/ipv6/ip6_output.c:215 [inline] ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226 NF_HOOK_COND include/linux/netfilter.h:303 [inline] ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247 dst_output include/net/dst.h:450 [inline] NF_HOOK include/linux/netfilter.h:314 [inline] ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366 inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135 __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466 tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline] tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143 tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333 __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679 inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750 __sys_connect_file net/socket.c:2061 [inline] __sys_connect+0x606/0x690 net/socket.c:2078 __do_sys_connect net/socket.c:2088 [inline] __se_sys_connect net/socket.c:2085 [inline] __x64_sys_connect+0x91/0xe0 net/socket.c:2085 x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43 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 Uninit was stored to memory at: nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249 nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344 nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48 expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline] nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288 nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161 nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline] nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626 nf_hook include/linux/netfilter.h:269 [inline] NF_HOOK include/linux/netfilter.h:312 [inline] ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47686", "url": "https://ubuntu.com/security/CVE-2024-47686", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ep93xx: clock: Fix off by one in ep93xx_div_recalc_rate() The psc->div[] array has psc->num_div elements. These values come from when we call clk_hw_register_div(). It's adc_divisors and ARRAY_SIZE(adc_divisors)) and so on. So this condition needs to be >= instead of > to prevent an out of bounds read.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47748", "url": "https://ubuntu.com/security/CVE-2024-47748", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vhost_vdpa: assign irq bypass producer token correctly We used to call irq_bypass_unregister_producer() in vhost_vdpa_setup_vq_irq() which is problematic as we don't know if the token pointer is still valid or not. Actually, we use the eventfd_ctx as the token so the life cycle of the token should be bound to the VHOST_SET_VRING_CALL instead of vhost_vdpa_setup_vq_irq() which could be called by set_status(). Fixing this by setting up irq bypass producer's token when handling VHOST_SET_VRING_CALL and un-registering the producer before calling vhost_vring_ioctl() to prevent a possible use after free as eventfd could have been released in vhost_vring_ioctl(). And such registering and unregistering will only be done if DRIVER_OK is set.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47687", "url": "https://ubuntu.com/security/CVE-2024-47687", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: vdpa/mlx5: Fix invalid mr resource destroy Certain error paths from mlx5_vdpa_dev_add() can end up releasing mr resources which never got initialized in the first place. This patch adds the missing check in mlx5_vdpa_destroy_mr_resources() to block releasing non-initialized mr resources. Reference trace: mlx5_core 0000:08:00.2: mlx5_vdpa_dev_add:3274:(pid 2700) warning: No mac address provisioned? BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 140216067 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 8 PID: 2700 Comm: vdpa Kdump: loaded Not tainted 5.14.0-496.el9.x86_64 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:vhost_iotlb_del_range+0xf/0xe0 [vhost_iotlb] Code: [...] RSP: 0018:ff1c823ac23077f0 EFLAGS: 00010246 RAX: ffffffffc1a21a60 RBX: ffffffff899567a0 RCX: 0000000000000000 RDX: ffffffffffffffff RSI: 0000000000000000 RDI: 0000000000000000 RBP: ff1bda1f7c21e800 R08: 0000000000000000 R09: ff1c823ac2307670 R10: ff1c823ac2307668 R11: ffffffff8a9e7b68 R12: 0000000000000000 R13: 0000000000000000 R14: ff1bda1f43e341a0 R15: 00000000ffffffea FS: 00007f56eba7c740(0000) GS:ff1bda269f800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000104d90001 CR4: 0000000000771ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? show_trace_log_lvl+0x1c4/0x2df ? show_trace_log_lvl+0x1c4/0x2df ? mlx5_vdpa_free+0x3d/0x150 [mlx5_vdpa] ? __die_body.cold+0x8/0xd ? page_fault_oops+0x134/0x170 ? __irq_work_queue_local+0x2b/0xc0 ? irq_work_queue+0x2c/0x50 ? exc_page_fault+0x62/0x150 ? asm_exc_page_fault+0x22/0x30 ? __pfx_mlx5_vdpa_free+0x10/0x10 [mlx5_vdpa] ? vhost_iotlb_del_range+0xf/0xe0 [vhost_iotlb] mlx5_vdpa_free+0x3d/0x150 [mlx5_vdpa] vdpa_release_dev+0x1e/0x50 [vdpa] device_release+0x31/0x90 kobject_cleanup+0x37/0x130 mlx5_vdpa_dev_add+0x2d2/0x7a0 [mlx5_vdpa] vdpa_nl_cmd_dev_add_set_doit+0x277/0x4c0 [vdpa] genl_family_rcv_msg_doit+0xd9/0x130 genl_family_rcv_msg+0x14d/0x220 ? __pfx_vdpa_nl_cmd_dev_add_set_doit+0x10/0x10 [vdpa] ? _copy_to_user+0x1a/0x30 ? move_addr_to_user+0x4b/0xe0 genl_rcv_msg+0x47/0xa0 ? __import_iovec+0x46/0x150 ? __pfx_genl_rcv_msg+0x10/0x10 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x245/0x370 netlink_sendmsg+0x206/0x440 __sys_sendto+0x1dc/0x1f0 ? do_read_fault+0x10c/0x1d0 ? do_pte_missing+0x10d/0x190 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x5c/0xf0 ? __count_memcg_events+0x4f/0xb0 ? mm_account_fault+0x6c/0x100 ? handle_mm_fault+0x116/0x270 ? do_user_addr_fault+0x1d6/0x6a0 ? do_syscall_64+0x6b/0xf0 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 ? clear_bhb_loop+0x25/0x80 entry_SYSCALL_64_after_hwframe+0x78/0x80", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47688", "url": "https://ubuntu.com/security/CVE-2024-47688", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: driver core: Fix a potential null-ptr-deref in module_add_driver() Inject fault while probing of-fpga-region, if kasprintf() fails in module_add_driver(), the second sysfs_remove_link() in exit path will cause null-ptr-deref as below because kernfs_name_hash() will call strlen() with NULL driver_name. Fix it by releasing resources based on the exit path sequence. \t KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] \t Mem abort info: \t ESR = 0x0000000096000005 \t EC = 0x25: DABT (current EL), IL = 32 bits \t SET = 0, FnV = 0 \t EA = 0, S1PTW = 0 \t FSC = 0x05: level 1 translation fault \t Data abort info: \t ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000 \t CM = 0, WnR = 0, TnD = 0, TagAccess = 0 \t GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 \t [dfffffc000000000] address between user and kernel address ranges \t Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP \t Dumping ftrace buffer: \t (ftrace buffer empty) \t Modules linked in: of_fpga_region(+) fpga_region fpga_bridge cfg80211 rfkill 8021q garp mrp stp llc ipv6 [last unloaded: of_fpga_region] \t CPU: 2 UID: 0 PID: 2036 Comm: modprobe Not tainted 6.11.0-rc2-g6a0e38264012 #295 \t Hardware name: linux,dummy-virt (DT) \t pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) \t pc : strlen+0x24/0xb0 \t lr : kernfs_name_hash+0x1c/0xc4 \t sp : ffffffc081f97380 \t x29: ffffffc081f97380 x28: ffffffc081f97b90 x27: ffffff80c821c2a0 \t x26: ffffffedac0be418 x25: 0000000000000000 x24: ffffff80c09d2000 \t x23: 0000000000000000 x22: 0000000000000000 x21: 0000000000000000 \t x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000001840 \t x17: 0000000000000000 x16: 0000000000000000 x15: 1ffffff8103f2e42 \t x14: 00000000f1f1f1f1 x13: 0000000000000004 x12: ffffffb01812d61d \t x11: 1ffffff01812d61c x10: ffffffb01812d61c x9 : dfffffc000000000 \t x8 : 0000004fe7ed29e4 x7 : ffffff80c096b0e7 x6 : 0000000000000001 \t x5 : ffffff80c096b0e0 x4 : 1ffffffdb990efa2 x3 : 0000000000000000 \t x2 : 0000000000000000 x1 : dfffffc000000000 x0 : 0000000000000000 \t Call trace: \t strlen+0x24/0xb0 \t kernfs_name_hash+0x1c/0xc4 \t kernfs_find_ns+0x118/0x2e8 \t kernfs_remove_by_name_ns+0x80/0x100 \t sysfs_remove_link+0x74/0xa8 \t module_add_driver+0x278/0x394 \t bus_add_driver+0x1f0/0x43c \t driver_register+0xf4/0x3c0 \t __platform_driver_register+0x60/0x88 \t of_fpga_region_init+0x20/0x1000 [of_fpga_region] \t do_one_initcall+0x110/0x788 \t do_init_module+0x1dc/0x5c8 \t load_module+0x3c38/0x4cac \t init_module_from_file+0xd4/0x128 \t idempotent_init_module+0x2cc/0x528 \t __arm64_sys_finit_module+0xac/0x100 \t invoke_syscall+0x6c/0x258 \t el0_svc_common.constprop.0+0x160/0x22c \t do_el0_svc+0x44/0x5c \t el0_svc+0x48/0xb8 \t el0t_64_sync_handler+0x13c/0x158 \t el0t_64_sync+0x190/0x194 \t Code: f2fbffe1 a90157f4 12000802 aa0003f5 (38e16861) \t ---[ end trace 0000000000000000 ]--- \t Kernel panic - not syncing: Oops: Fatal exception", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47689", "url": "https://ubuntu.com/security/CVE-2024-47689", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to don't set SB_RDONLY in f2fs_handle_critical_error() syzbot reports a f2fs bug as below: ------------[ cut here ]------------ WARNING: CPU: 1 PID: 58 at kernel/rcu/sync.c:177 rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177 CPU: 1 UID: 0 PID: 58 Comm: kworker/1:2 Not tainted 6.10.0-syzkaller-12562-g1722389b0d86 #0 Workqueue: events destroy_super_work RIP: 0010:rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177 Call Trace: percpu_free_rwsem+0x41/0x80 kernel/locking/percpu-rwsem.c:42 destroy_super_work+0xec/0x130 fs/super.c:282 process_one_work kernel/workqueue.c:3231 [inline] process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 worker_thread+0x86d/0xd40 kernel/workqueue.c:3390 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 As Christian Brauner pointed out [1]: the root cause is f2fs sets SB_RDONLY flag in internal function, rather than setting the flag covered w/ sb->s_umount semaphore via remount procedure, then below race condition causes this bug: - freeze_super() - sb_wait_write(sb, SB_FREEZE_WRITE) - sb_wait_write(sb, SB_FREEZE_PAGEFAULT) - sb_wait_write(sb, SB_FREEZE_FS) \t\t\t\t\t- f2fs_handle_critical_error \t\t\t\t\t - sb->s_flags |= SB_RDONLY - thaw_super - thaw_super_locked - sb_rdonly() is true, so it skips sb_freeze_unlock(sb, SB_FREEZE_FS) - deactivate_locked_super Since f2fs has almost the same logic as ext4 [2] when handling critical error in filesystem if it mounts w/ errors=remount-ro option: - set CP_ERROR_FLAG flag which indicates filesystem is stopped - record errors to superblock - set SB_RDONLY falg Once we set CP_ERROR_FLAG flag, all writable interfaces can detect the flag and stop any further updates on filesystem. So, it is safe to not set SB_RDONLY flag, let's remove the logic and keep in line w/ ext4 [3]. [1] https://lore.kernel.org/all/20240729-himbeeren-funknetz-96e62f9c7aee@brauner [2] https://lore.kernel.org/all/20240729132721.hxih6ehigadqf7wx@quack3 [3] https://lore.kernel.org/linux-ext4/20240805201241.27286-1-jack@suse.cz", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47690", "url": "https://ubuntu.com/security/CVE-2024-47690", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: get rid of online repaire on corrupted directory syzbot reports a f2fs bug as below: kernel BUG at fs/f2fs/inode.c:896! RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Call Trace: evict+0x532/0x950 fs/inode.c:704 dispose_list fs/inode.c:747 [inline] evict_inodes+0x5f9/0x690 fs/inode.c:797 generic_shutdown_super+0x9d/0x2d0 fs/super.c:627 kill_block_super+0x44/0x90 fs/super.c:1696 kill_f2fs_super+0x344/0x690 fs/f2fs/super.c:4898 deactivate_locked_super+0xc4/0x130 fs/super.c:473 cleanup_mnt+0x41f/0x4b0 fs/namespace.c:1373 task_work_run+0x24f/0x310 kernel/task_work.c:228 ptrace_notify+0x2d2/0x380 kernel/signal.c:2402 ptrace_report_syscall include/linux/ptrace.h:415 [inline] ptrace_report_syscall_exit include/linux/ptrace.h:477 [inline] syscall_exit_work+0xc6/0x190 kernel/entry/common.c:173 syscall_exit_to_user_mode_prepare kernel/entry/common.c:200 [inline] __syscall_exit_to_user_mode_work kernel/entry/common.c:205 [inline] syscall_exit_to_user_mode+0x279/0x370 kernel/entry/common.c:218 do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89 entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Online repaire on corrupted directory in f2fs_lookup() can generate dirty data/meta while racing w/ readonly remount, it may leave dirty inode after filesystem becomes readonly, however, checkpoint() will skips flushing dirty inode in a state of readonly mode, result in above panic. Let's get rid of online repaire in f2fs_lookup(), and leave the work to fsck.f2fs.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47691", "url": "https://ubuntu.com/security/CVE-2024-47691", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread() syzbot reports a f2fs bug as below: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_report+0xe8/0x550 mm/kasan/report.c:491 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 instrument_atomic_read_write include/linux/instrumented.h:96 [inline] atomic_fetch_add_relaxed include/linux/atomic/atomic-instrumented.h:252 [inline] __refcount_add include/linux/refcount.h:184 [inline] __refcount_inc include/linux/refcount.h:241 [inline] refcount_inc include/linux/refcount.h:258 [inline] get_task_struct include/linux/sched/task.h:118 [inline] kthread_stop+0xca/0x630 kernel/kthread.c:704 f2fs_stop_gc_thread+0x65/0xb0 fs/f2fs/gc.c:210 f2fs_do_shutdown+0x192/0x540 fs/f2fs/file.c:2283 f2fs_ioc_shutdown fs/f2fs/file.c:2325 [inline] __f2fs_ioctl+0x443a/0xbe60 fs/f2fs/file.c:4325 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f The root cause is below race condition, it may cause use-after-free issue in sbi->gc_th pointer. - remount - f2fs_remount - f2fs_stop_gc_thread - kfree(gc_th) \t\t\t\t- f2fs_ioc_shutdown \t\t\t\t - f2fs_do_shutdown \t\t\t\t - f2fs_stop_gc_thread \t\t\t\t - kthread_stop(gc_th->f2fs_gc_task) : sbi->gc_thread = NULL; We will call f2fs_do_shutdown() in two paths: - for f2fs_ioc_shutdown() path, we should grab sb->s_umount semaphore for fixing. - for f2fs_shutdown() path, it's safe since caller has already grabbed sb->s_umount semaphore.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47692", "url": "https://ubuntu.com/security/CVE-2024-47692", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: return -EINVAL when namelen is 0 When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may result in namelen being 0, which will cause memdup_user() to return ZERO_SIZE_PTR. When we access the name.data that has been assigned the value of ZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is triggered. [ T1205] ================================================================== [ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260 [ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205 [ T1205] [ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406 [ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ T1205] Call Trace: [ T1205] dump_stack+0x9a/0xd0 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] __kasan_report.cold+0x34/0x84 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] kasan_report+0x3a/0x50 [ T1205] nfs4_client_to_reclaim+0xe9/0x260 [ T1205] ? nfsd4_release_lockowner+0x410/0x410 [ T1205] cld_pipe_downcall+0x5ca/0x760 [ T1205] ? nfsd4_cld_tracking_exit+0x1d0/0x1d0 [ T1205] ? down_write_killable_nested+0x170/0x170 [ T1205] ? avc_policy_seqno+0x28/0x40 [ T1205] ? selinux_file_permission+0x1b4/0x1e0 [ T1205] rpc_pipe_write+0x84/0xb0 [ T1205] vfs_write+0x143/0x520 [ T1205] ksys_write+0xc9/0x170 [ T1205] ? __ia32_sys_read+0x50/0x50 [ T1205] ? ktime_get_coarse_real_ts64+0xfe/0x110 [ T1205] ? ktime_get_coarse_real_ts64+0xa2/0x110 [ T1205] do_syscall_64+0x33/0x40 [ T1205] entry_SYSCALL_64_after_hwframe+0x67/0xd1 [ T1205] RIP: 0033:0x7fdbdb761bc7 [ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 514 [ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7 [ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008 [ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001 [ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b [ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000 [ T1205] ================================================================== Fix it by checking namelen.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47737", "url": "https://ubuntu.com/security/CVE-2024-47737", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nfsd: call cache_put if xdr_reserve_space returns NULL If not enough buffer space available, but idmap_lookup has triggered lookup_fn which calls cache_get and returns successfully. Then we missed to call cache_put here which pairs with cache_get. Reviwed-by: Jeff Layton ", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2023-52917", "url": "https://ubuntu.com/security/CVE-2023-52917", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir() The debugfs_create_dir() function returns error pointers. It never returns NULL. So use IS_ERR() to check it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47749", "url": "https://ubuntu.com/security/CVE-2024-47749", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/cxgb4: Added NULL check for lookup_atid The lookup_atid() function can return NULL if the ATID is invalid or does not exist in the identifier table, which could lead to dereferencing a null pointer without a check in the `act_establish()` and `act_open_rpl()` functions. Add a NULL check to prevent null pointer dereferencing. Found by Linux Verification Center (linuxtesting.org) with SVACE.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47735", "url": "https://ubuntu.com/security/CVE-2024-47735", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled Fix missuse of spin_lock_irq()/spin_unlock_irq() when spin_lock_irqsave()/spin_lock_irqrestore() was hold. This was discovered through the lock debugging, and the corresponding log is as follows: raw_local_irq_restore() called with IRQs enabled WARNING: CPU: 96 PID: 2074 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x30/0x40 ... Call trace: warn_bogus_irq_restore+0x30/0x40 _raw_spin_unlock_irqrestore+0x84/0xc8 add_qp_to_list+0x11c/0x148 [hns_roce_hw_v2] hns_roce_create_qp_common.constprop.0+0x240/0x780 [hns_roce_hw_v2] hns_roce_create_qp+0x98/0x160 [hns_roce_hw_v2] create_qp+0x138/0x258 ib_create_qp_kernel+0x50/0xe8 create_mad_qp+0xa8/0x128 ib_mad_port_open+0x218/0x448 ib_mad_init_device+0x70/0x1f8 add_client_context+0xfc/0x220 enable_device_and_get+0xd0/0x140 ib_register_device.part.0+0xf4/0x1c8 ib_register_device+0x34/0x50 hns_roce_register_device+0x174/0x3d0 [hns_roce_hw_v2] hns_roce_init+0xfc/0x2c0 [hns_roce_hw_v2] __hns_roce_hw_v2_init_instance+0x7c/0x1d0 [hns_roce_hw_v2] hns_roce_hw_v2_init_instance+0x9c/0x180 [hns_roce_hw_v2]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47750", "url": "https://ubuntu.com/security/CVE-2024-47750", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix Use-After-Free of rsv_qp on HIP08 Currently rsv_qp is freed before ib_unregister_device() is called on HIP08. During the time interval, users can still dereg MR and rsv_qp will be used in this process, leading to a UAF. Move the release of rsv_qp after calling ib_unregister_device() to fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47751", "url": "https://ubuntu.com/security/CVE-2024-47751", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: kirin: Fix buffer overflow in kirin_pcie_parse_port() Within kirin_pcie_parse_port(), the pcie->num_slots is compared to pcie->gpio_id_reset size (MAX_PCI_SLOTS) which is correct and would lead to an overflow. Thus, fix condition to pcie->num_slots + 1 >= MAX_PCI_SLOTS and move pcie->num_slots increment below the if-statement to avoid out-of-bounds array access. Found by Linux Verification Center (linuxtesting.org) with SVACE. [kwilczynski: commit log]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47693", "url": "https://ubuntu.com/security/CVE-2024-47693", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/core: Fix ib_cache_setup_one error flow cleanup When ib_cache_update return an error, we exit ib_cache_setup_one instantly with no proper cleanup, even though before this we had already successfully done gid_table_setup_one, that results in the kernel WARN below. Do proper cleanup using gid_table_cleanup_one before returning the err in order to fix the issue. WARNING: CPU: 4 PID: 922 at drivers/infiniband/core/cache.c:806 gid_table_release_one+0x181/0x1a0 Modules linked in: CPU: 4 UID: 0 PID: 922 Comm: c_repro Not tainted 6.11.0-rc1+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:gid_table_release_one+0x181/0x1a0 Code: 44 8b 38 75 0c e8 2f cb 34 ff 4d 8b b5 28 05 00 00 e8 23 cb 34 ff 44 89 f9 89 da 4c 89 f6 48 c7 c7 d0 58 14 83 e8 4f de 21 ff <0f> 0b 4c 8b 75 30 e9 54 ff ff ff 48 8 3 c4 10 5b 5d 41 5c 41 5d 41 RSP: 0018:ffffc90002b835b0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c8527 RDX: 0000000000000000 RSI: ffffffff811c8534 RDI: 0000000000000001 RBP: ffff8881011b3d00 R08: ffff88810b3abe00 R09: 205d303839303631 R10: 666572207972746e R11: 72746e6520444947 R12: 0000000000000001 R13: ffff888106390000 R14: ffff8881011f2110 R15: 0000000000000001 FS: 00007fecc3b70800(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000340 CR3: 000000010435a001 CR4: 00000000003706b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? show_regs+0x94/0xa0 ? __warn+0x9e/0x1c0 ? gid_table_release_one+0x181/0x1a0 ? report_bug+0x1f9/0x340 ? gid_table_release_one+0x181/0x1a0 ? handle_bug+0xa2/0x110 ? exc_invalid_op+0x31/0xa0 ? asm_exc_invalid_op+0x16/0x20 ? __warn_printk+0xc7/0x180 ? __warn_printk+0xd4/0x180 ? gid_table_release_one+0x181/0x1a0 ib_device_release+0x71/0xe0 ? __pfx_ib_device_release+0x10/0x10 device_release+0x44/0xd0 kobject_put+0x135/0x3d0 put_device+0x20/0x30 rxe_net_add+0x7d/0xa0 rxe_newlink+0xd7/0x190 nldev_newlink+0x1b0/0x2a0 ? __pfx_nldev_newlink+0x10/0x10 rdma_nl_rcv_msg+0x1ad/0x2e0 rdma_nl_rcv_skb.constprop.0+0x176/0x210 netlink_unicast+0x2de/0x400 netlink_sendmsg+0x306/0x660 __sock_sendmsg+0x110/0x120 ____sys_sendmsg+0x30e/0x390 ___sys_sendmsg+0x9b/0xf0 ? kstrtouint+0x6e/0xa0 ? kstrtouint_from_user+0x7c/0xb0 ? get_pid_task+0xb0/0xd0 ? proc_fail_nth_write+0x5b/0x140 ? __fget_light+0x9a/0x200 ? preempt_count_add+0x47/0xa0 __sys_sendmsg+0x61/0xd0 do_syscall_64+0x50/0x110 entry_SYSCALL_64_after_hwframe+0x76/0x7e", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47694", "url": "https://ubuntu.com/security/CVE-2024-47694", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: IB/mlx5: Fix UMR pd cleanup on error flow of driver init The cited commit moves the pd allocation from function mlx5r_umr_resource_cleanup() to a new function mlx5r_umr_cleanup(). So the fix in commit [1] is broken. In error flow, will hit panic [2]. Fix it by checking pd pointer to avoid panic if it is NULL; [1] RDMA/mlx5: Fix UMR cleanup on error flow of driver init [2] [ 347.567063] infiniband mlx5_0: Couldn't register device with driver model [ 347.591382] BUG: kernel NULL pointer dereference, address: 0000000000000020 [ 347.593438] #PF: supervisor read access in kernel mode [ 347.595176] #PF: error_code(0x0000) - not-present page [ 347.596962] PGD 0 P4D 0 [ 347.601361] RIP: 0010:ib_dealloc_pd_user+0x12/0xc0 [ib_core] [ 347.604171] RSP: 0018:ffff888106293b10 EFLAGS: 00010282 [ 347.604834] RAX: 0000000000000000 RBX: 000000000000000e RCX: 0000000000000000 [ 347.605672] RDX: ffff888106293ad0 RSI: 0000000000000000 RDI: 0000000000000000 [ 347.606529] RBP: 0000000000000000 R08: ffff888106293ae0 R09: ffff888106293ae0 [ 347.607379] R10: 0000000000000a06 R11: 0000000000000000 R12: 0000000000000000 [ 347.608224] R13: ffffffffa0704dc0 R14: 0000000000000001 R15: 0000000000000001 [ 347.609067] FS: 00007fdc720cd9c0(0000) GS:ffff88852c880000(0000) knlGS:0000000000000000 [ 347.610094] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 347.610727] CR2: 0000000000000020 CR3: 0000000103012003 CR4: 0000000000370eb0 [ 347.611421] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 347.612113] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 347.612804] Call Trace: [ 347.613130] [ 347.613417] ? __die+0x20/0x60 [ 347.613793] ? page_fault_oops+0x150/0x3e0 [ 347.614243] ? free_msg+0x68/0x80 [mlx5_core] [ 347.614840] ? cmd_exec+0x48f/0x11d0 [mlx5_core] [ 347.615359] ? exc_page_fault+0x74/0x130 [ 347.615808] ? asm_exc_page_fault+0x22/0x30 [ 347.616273] ? ib_dealloc_pd_user+0x12/0xc0 [ib_core] [ 347.616801] mlx5r_umr_cleanup+0x23/0x90 [mlx5_ib] [ 347.617365] mlx5_ib_stage_pre_ib_reg_umr_cleanup+0x36/0x40 [mlx5_ib] [ 347.618025] __mlx5_ib_add+0x96/0xd0 [mlx5_ib] [ 347.618539] mlx5r_probe+0xe9/0x310 [mlx5_ib] [ 347.619032] ? kernfs_add_one+0x107/0x150 [ 347.619478] ? __mlx5_ib_add+0xd0/0xd0 [mlx5_ib] [ 347.619984] auxiliary_bus_probe+0x3e/0x90 [ 347.620448] really_probe+0xc5/0x3a0 [ 347.620857] __driver_probe_device+0x80/0x160 [ 347.621325] driver_probe_device+0x1e/0x90 [ 347.621770] __driver_attach+0xec/0x1c0 [ 347.622213] ? __device_attach_driver+0x100/0x100 [ 347.622724] bus_for_each_dev+0x71/0xc0 [ 347.623151] bus_add_driver+0xed/0x240 [ 347.623570] driver_register+0x58/0x100 [ 347.623998] __auxiliary_driver_register+0x6a/0xc0 [ 347.624499] ? driver_register+0xae/0x100 [ 347.624940] ? 0xffffffffa0893000 [ 347.625329] mlx5_ib_init+0x16a/0x1e0 [mlx5_ib] [ 347.625845] do_one_initcall+0x4a/0x2a0 [ 347.626273] ? gcov_event+0x2e2/0x3a0 [ 347.626706] do_init_module+0x8a/0x260 [ 347.627126] init_module_from_file+0x8b/0xd0 [ 347.627596] __x64_sys_finit_module+0x1ca/0x2f0 [ 347.628089] do_syscall_64+0x4c/0x100", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47695", "url": "https://ubuntu.com/security/CVE-2024-47695", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds In the function init_conns(), after the create_con() and create_cm() for loop if something fails. In the cleanup for loop after the destroy tag, we access out of bound memory because cid is set to clt_path->s.con_num. This commits resets the cid to clt_path->s.con_num - 1, to stay in bounds in the cleanup loop later.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47752", "url": "https://ubuntu.com/security/CVE-2024-47752", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix H264 stateless decoder smatch warning Fix a smatch static checker warning on vdec_h264_req_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47753", "url": "https://ubuntu.com/security/CVE-2024-47753", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix VP8 stateless decoder smatch warning Fix a smatch static checker warning on vdec_vp8_req_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47754", "url": "https://ubuntu.com/security/CVE-2024-47754", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: Fix H264 multi stateless decoder smatch warning Fix a smatch static checker warning on vdec_h264_req_multi_if.c. Which leads to a kernel crash when fb is NULL.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47696", "url": "https://ubuntu.com/security/CVE-2024-47696", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency In the commit aee2424246f9 (\"RDMA/iwcm: Fix a use-after-free related to destroying CM IDs\"), the function flush_workqueue is invoked to flush the work queue iwcm_wq. But at that time, the work queue iwcm_wq was created via the function alloc_ordered_workqueue without the flag WQ_MEM_RECLAIM. Because the current process is trying to flush the whole iwcm_wq, if iwcm_wq doesn't have the flag WQ_MEM_RECLAIM, verify that the current process is not reclaiming memory or running on a workqueue which doesn't have the flag WQ_MEM_RECLAIM as that can break forward-progress guarantee leading to a deadlock. The call trace is as below: [ 125.350876][ T1430] Call Trace: [ 125.356281][ T1430] [ 125.361285][ T1430] ? __warn (kernel/panic.c:693) [ 125.367640][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.375689][ T1430] ? report_bug (lib/bug.c:180 lib/bug.c:219) [ 125.382505][ T1430] ? handle_bug (arch/x86/kernel/traps.c:239) [ 125.388987][ T1430] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) [ 125.395831][ T1430] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621) [ 125.403125][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.410984][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.418764][ T1430] __flush_workqueue (kernel/workqueue.c:3970) [ 125.426021][ T1430] ? __pfx___might_resched (kernel/sched/core.c:10151) [ 125.433431][ T1430] ? destroy_cm_id (drivers/infiniband/core/iwcm.c:375) iw_cm [ 125.441209][ T1430] ? __pfx___flush_workqueue (kernel/workqueue.c:3910) [ 125.473900][ T1430] ? _raw_spin_lock_irqsave (arch/x86/include/asm/atomic.h:107 include/linux/atomic/atomic-arch-fallback.h:2170 include/linux/atomic/atomic-instrumented.h:1302 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162) [ 125.473909][ T1430] ? __pfx__raw_spin_lock_irqsave (kernel/locking/spinlock.c:161) [ 125.482537][ T1430] _destroy_id (drivers/infiniband/core/cma.c:2044) rdma_cm [ 125.495072][ T1430] nvme_rdma_free_queue (drivers/nvme/host/rdma.c:656 drivers/nvme/host/rdma.c:650) nvme_rdma [ 125.505827][ T1430] nvme_rdma_reset_ctrl_work (drivers/nvme/host/rdma.c:2180) nvme_rdma [ 125.505831][ T1430] process_one_work (kernel/workqueue.c:3231) [ 125.515122][ T1430] worker_thread (kernel/workqueue.c:3306 kernel/workqueue.c:3393) [ 125.515127][ T1430] ? __pfx_worker_thread (kernel/workqueue.c:3339) [ 125.531837][ T1430] kthread (kernel/kthread.c:389) [ 125.539864][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.550628][ T1430] ret_from_fork (arch/x86/kernel/process.c:147) [ 125.558840][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.558844][ T1430] ret_from_fork_asm (arch/x86/entry/entry_64.S:257) [ 125.566487][ T1430] [ 125.566488][ T1430] ---[ end trace 0000000000000000 ]---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47755", "url": "https://ubuntu.com/security/CVE-2024-47755", "cve_description": "Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47756", "url": "https://ubuntu.com/security/CVE-2024-47756", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: PCI: keystone: Fix if-statement expression in ks_pcie_quirk() This code accidentally uses && where || was intended. It potentially results in a NULL dereference. Thus, fix the if-statement expression to use the correct condition. [kwilczynski: commit log]", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47697", "url": "https://ubuntu.com/security/CVE-2024-47697", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error Ensure index in rtl2830_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47698", "url": "https://ubuntu.com/security/CVE-2024-47698", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error Ensure index in rtl2832_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue. [hverkuil: added fixes tag, rtl2830_pid_filter -> rtl2832_pid_filter in logmsg]", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47728", "url": "https://ubuntu.com/security/CVE-2024-47728", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error For all non-tracing helpers which formerly had ARG_PTR_TO_{LONG,INT} as input arguments, zero the value for the case of an error as otherwise it could leak memory. For tracing, it is not needed given CAP_PERFMON can already read all kernel memory anyway hence bpf_get_func_arg() and bpf_get_func_ret() is skipped in here. Also, the MTU helpers mtu_len pointer value is being written but also read. Technically, the MEM_UNINIT should not be there in order to always force init. Removing MEM_UNINIT needs more verifier rework though: MEM_UNINIT right now implies two things actually: i) write into memory, ii) memory does not have to be initialized. If we lift MEM_UNINIT, it then becomes: i) read into memory, ii) memory must be initialized. This means that for bpf_*_check_mtu() we're readding the issue we're trying to fix, that is, it would then be able to write back into things like .rodata BPF maps. Follow-up work will rework the MEM_UNINIT semantics such that the intent can be better expressed. For now just clear the *mtu_len on error path which can be lifted later again.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49861", "url": "https://ubuntu.com/security/CVE-2024-49861", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fix helper writes to read-only maps Lonial found an issue that despite user- and BPF-side frozen BPF map (like in case of .rodata), it was still possible to write into it from a BPF program side through specific helpers having ARG_PTR_TO_{LONG,INT} as arguments. In check_func_arg() when the argument is as mentioned, the meta->raw_mode is never set. Later, check_helper_mem_access(), under the case of PTR_TO_MAP_VALUE as register base type, it assumes BPF_READ for the subsequent call to check_map_access_type() and given the BPF map is read-only it succeeds. The helpers really need to be annotated as ARG_PTR_TO_{LONG,INT} | MEM_UNINIT when results are written into them as opposed to read out of them. The latter indicates that it's okay to pass a pointer to uninitialized memory as the memory is written to anyway. However, ARG_PTR_TO_{LONG,INT} is a special case of ARG_PTR_TO_FIXED_SIZE_MEM just with additional alignment requirement. So it is better to just get rid of the ARG_PTR_TO_{LONG,INT} special cases altogether and reuse the fixed size memory types. For this, add MEM_ALIGNED to additionally ensure alignment given these helpers write directly into the args via * = val. The .arg*_size has been initialized reflecting the actual sizeof(*). MEM_ALIGNED can only be used in combination with MEM_FIXED_SIZE annotated argument types, since in !MEM_FIXED_SIZE cases the verifier does not know the buffer size a priori and therefore cannot blindly write * = val.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47757", "url": "https://ubuntu.com/security/CVE-2024-47757", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential oob read in nilfs_btree_check_delete() The function nilfs_btree_check_delete(), which checks whether degeneration to direct mapping occurs before deleting a b-tree entry, causes memory access outside the block buffer when retrieving the maximum key if the root node has no entries. This does not usually happen because b-tree mappings with 0 child nodes are never created by mkfs.nilfs2 or nilfs2 itself. However, it can happen if the b-tree root node read from a device is configured that way, so fix this potential issue by adding a check for that case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47699", "url": "https://ubuntu.com/security/CVE-2024-47699", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential null-ptr-deref in nilfs_btree_insert() Patch series \"nilfs2: fix potential issues with empty b-tree nodes\". This series addresses three potential issues with empty b-tree nodes that can occur with corrupted filesystem images, including one recently discovered by syzbot. This patch (of 3): If a b-tree is broken on the device, and the b-tree height is greater than 2 (the level of the root node is greater than 1) even if the number of child nodes of the b-tree root is 0, a NULL pointer dereference occurs in nilfs_btree_prepare_insert(), which is called from nilfs_btree_insert(). This is because, when the number of child nodes of the b-tree root is 0, nilfs_btree_do_lookup() does not set the block buffer head in any of path[x].bp_bh, leaving it as the initial value of NULL, but if the level of the b-tree root node is greater than 1, nilfs_btree_get_nonroot_node(), which accesses the buffer memory of path[x].bp_bh, is called. Fix this issue by adding a check to nilfs_btree_root_broken(), which performs sanity checks when reading the root node from the device, to detect this inconsistency. Thanks to Lizhi Xu for trying to solve the bug and clarifying the cause early on.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47700", "url": "https://ubuntu.com/security/CVE-2024-47700", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: check stripe size compatibility on remount as well We disable stripe size in __ext4_fill_super if it is not a multiple of the cluster ratio however this check is missed when trying to remount. This can leave us with cases where stripe < cluster_ratio after remount:set making EXT4_B2C(sbi->s_stripe) become 0 that can cause some unforeseen bugs like divide by 0. Fix that by adding the check in remount path as well.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47701", "url": "https://ubuntu.com/security/CVE-2024-47701", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ext4: avoid OOB when system.data xattr changes underneath the filesystem When looking up for an entry in an inlined directory, if e_value_offs is changed underneath the filesystem by some change in the block device, it will lead to an out-of-bounds access that KASAN detects as an UAF. EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none. loop0: detected capacity change from 2048 to 2047 ================================================================== BUG: KASAN: use-after-free in ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 Read of size 1 at addr ffff88803e91130f by task syz-executor269/5103 CPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 Not tainted 6.11.0-rc4-syzkaller #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:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 ext4_find_inline_entry+0x4be/0x5e0 fs/ext4/inline.c:1697 __ext4_find_entry+0x2b4/0x1b30 fs/ext4/namei.c:1573 ext4_lookup_entry fs/ext4/namei.c:1727 [inline] ext4_lookup+0x15f/0x750 fs/ext4/namei.c:1795 lookup_one_qstr_excl+0x11f/0x260 fs/namei.c:1633 filename_create+0x297/0x540 fs/namei.c:3980 do_symlinkat+0xf9/0x3a0 fs/namei.c:4587 __do_sys_symlinkat fs/namei.c:4610 [inline] __se_sys_symlinkat fs/namei.c:4607 [inline] __x64_sys_symlinkat+0x95/0xb0 fs/namei.c:4607 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:0x7f3e73ced469 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff4d40c258 EFLAGS: 00000246 ORIG_RAX: 000000000000010a RAX: ffffffffffffffda RBX: 0032656c69662f2e RCX: 00007f3e73ced469 RDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0 RBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290 R10: 0023706f6f6c2f76 R11: 0000000000000246 R12: 00007fff4d40c27c R13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0 Calling ext4_xattr_ibody_find right after reading the inode with ext4_get_inode_loc will lead to a check of the validity of the xattrs, avoiding this problem.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49850", "url": "https://ubuntu.com/security/CVE-2024-49850", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: correctly handle malformed BPF_CORE_TYPE_ID_LOCAL relos In case of malformed relocation record of kind BPF_CORE_TYPE_ID_LOCAL referencing a non-existing BTF type, function bpf_core_calc_relo_insn would cause a null pointer deference. Fix this by adding a proper check upper in call stack, as malformed relocation records could be passed from user space. Simplest reproducer is a program: r0 = 0 exit With a single relocation record: .insn_off = 0, /* patch first instruction */ .type_id = 100500, /* this type id does not exist */ .access_str_off = 6, /* offset of string \"0\" */ .kind = BPF_CORE_TYPE_ID_LOCAL, See the link for original reproducer or next commit for a test case.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47702", "url": "https://ubuntu.com/security/CVE-2024-47702", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf: Fail verification for sign-extension of packet data/data_end/data_meta syzbot reported a kernel crash due to commit 1f1e864b6555 (\"bpf: Handle sign-extenstin ctx member accesses\"). The reason is due to sign-extension of 32-bit load for packet data/data_end/data_meta uapi field. The original code looks like: r2 = *(s32 *)(r1 + 76) /* load __sk_buff->data */ r3 = *(u32 *)(r1 + 80) /* load __sk_buff->data_end */ r0 = r2 r0 += 8 if r3 > r0 goto +1 ... Note that __sk_buff->data load has 32-bit sign extension. After verification and convert_ctx_accesses(), the final asm code looks like: r2 = *(u64 *)(r1 +208) r2 = (s32)r2 r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 ... Note that 'r2 = (s32)r2' may make the kernel __sk_buff->data address invalid which may cause runtime failure. Currently, in C code, typically we have void *data = (void *)(long)skb->data; void *data_end = (void *)(long)skb->data_end; ... and it will generate r2 = *(u64 *)(r1 +208) r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 If we allow sign-extension, void *data = (void *)(long)(int)skb->data; void *data_end = (void *)(long)skb->data_end; ... the generated code looks like r2 = *(u64 *)(r1 +208) r2 <<= 32 r2 s>>= 32 r3 = *(u64 *)(r1 +80) r0 = r2 r0 += 8 if r3 > r0 goto pc+1 and this will cause verification failure since \"r2 <<= 32\" is not allowed as \"r2\" is a packet pointer. To fix this issue for case r2 = *(s32 *)(r1 + 76) /* load __sk_buff->data */ this patch added additional checking in is_valid_access() callback function for packet data/data_end/data_meta access. If those accesses are with sign-extenstion, the verification will fail. [1] https://lore.kernel.org/bpf/000000000000c90eee061d236d37@google.com/", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47703", "url": "https://ubuntu.com/security/CVE-2024-47703", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: bpf, lsm: Add check for BPF LSM return value A bpf prog returning a positive number attached to file_alloc_security hook makes kernel panic. This happens because file system can not filter out the positive number returned by the LSM prog using IS_ERR, and misinterprets this positive number as a file pointer. Given that hook file_alloc_security never returned positive number before the introduction of BPF LSM, and other BPF LSM hooks may encounter similar issues, this patch adds LSM return value check in verifier, to ensure no unexpected value is returned.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49851", "url": "https://ubuntu.com/security/CVE-2024-49851", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: tpm: Clean up TPM space after command failure tpm_dev_transmit prepares the TPM space before attempting command transmission. However if the command fails no rollback of this preparation is done. This can result in transient handles being leaked if the device is subsequently closed with no further commands performed. Fix this by flushing the space in the event of command transmission failure.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47723", "url": "https://ubuntu.com/security/CVE-2024-47723", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: jfs: fix out-of-bounds in dbNextAG() and diAlloc() In dbNextAG() , there is no check for the case where bmp->db_numag is greater or same than MAXAG due to a polluted image, which causes an out-of-bounds. Therefore, a bounds check should be added in dbMount(). And in dbNextAG(), a check for the case where agpref is greater than bmp->db_numag should be added, so an out-of-bounds exception should be prevented. Additionally, a check for the case where agno is greater or same than MAXAG should be added in diAlloc() to prevent out-of-bounds.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49852", "url": "https://ubuntu.com/security/CVE-2024-49852", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: scsi: elx: libefc: Fix potential use after free in efc_nport_vport_del() The kref_put() function will call nport->release if the refcount drops to zero. The nport->release release function is _efc_nport_free() which frees \"nport\". But then we dereference \"nport\" on the next line which is a use after free. Re-order these lines to avoid the use after free.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47720", "url": "https://ubuntu.com/security/CVE-2024-47720", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check for set_output_gamma in dcn30_set_output_transfer_func This commit adds a null check for the set_output_gamma function pointer in the dcn30_set_output_transfer_func function. Previously, set_output_gamma was being checked for nullity at line 386, but then it was being dereferenced without any nullity check at line 401. This could potentially lead to a null pointer dereference error if set_output_gamma is indeed null. To fix this, we now ensure that set_output_gamma is not null before dereferencing it. We do this by adding a nullity check for set_output_gamma before the call to set_output_gamma at line 401. If set_output_gamma is null, we log an error message and do not call the function. This fix prevents a potential null pointer dereference error. drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:401 dcn30_set_output_transfer_func() error: we previously assumed 'mpc->funcs->set_output_gamma' could be null (see line 386) drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c 373 bool dcn30_set_output_transfer_func(struct dc *dc, 374 struct pipe_ctx *pipe_ctx, 375 const struct dc_stream_state *stream) 376 { 377 int mpcc_id = pipe_ctx->plane_res.hubp->inst; 378 struct mpc *mpc = pipe_ctx->stream_res.opp->ctx->dc->res_pool->mpc; 379 const struct pwl_params *params = NULL; 380 bool ret = false; 381 382 /* program OGAM or 3DLUT only for the top pipe*/ 383 if (pipe_ctx->top_pipe == NULL) { 384 /*program rmu shaper and 3dlut in MPC*/ 385 ret = dcn30_set_mpc_shaper_3dlut(pipe_ctx, stream); 386 if (ret == false && mpc->funcs->set_output_gamma) { ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ If this is NULL 387 if (stream->out_transfer_func.type == TF_TYPE_HWPWL) 388 params = &stream->out_transfer_func.pwl; 389 else if (pipe_ctx->stream->out_transfer_func.type == 390 TF_TYPE_DISTRIBUTED_POINTS && 391 cm3_helper_translate_curve_to_hw_format( 392 &stream->out_transfer_func, 393 &mpc->blender_params, false)) 394 params = &mpc->blender_params; 395 /* there are no ROM LUTs in OUTGAM */ 396 if (stream->out_transfer_func.type == TF_TYPE_PREDEFINED) 397 BREAK_TO_DEBUGGER(); 398 } 399 } 400 --> 401 mpc->funcs->set_output_gamma(mpc, mpcc_id, params); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Then it will crash 402 return ret; 403 }", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47704", "url": "https://ubuntu.com/security/CVE-2024-47704", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check link_res->hpo_dp_link_enc before using it [WHAT & HOW] Functions dp_enable_link_phy and dp_disable_link_phy can pass link_res without initializing hpo_dp_link_enc and it is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49853", "url": "https://ubuntu.com/security/CVE-2024-49853", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: firmware: arm_scmi: Fix double free in OPTEE transport Channels can be shared between protocols, avoid freeing the same channel descriptors twice when unloading the stack.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47705", "url": "https://ubuntu.com/security/CVE-2024-47705", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block: fix potential invalid pointer dereference in blk_add_partition The blk_add_partition() function initially used a single if-condition (IS_ERR(part)) to check for errors when adding a partition. This was modified to handle the specific case of -ENXIO separately, allowing the function to proceed without logging the error in this case. However, this change unintentionally left a path where md_autodetect_dev() could be called without confirming that part is a valid pointer. This commit separates the error handling logic by splitting the initial if-condition, improving code readability and handling specific error scenarios explicitly. The function now distinguishes the general error case from -ENXIO without altering the existing behavior of md_autodetect_dev() calls.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47736", "url": "https://ubuntu.com/security/CVE-2024-47736", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: erofs: handle overlapped pclusters out of crafted images properly syzbot reported a task hang issue due to a deadlock case where it is waiting for the folio lock of a cached folio that will be used for cache I/Os. After looking into the crafted fuzzed image, I found it's formed with several overlapped big pclusters as below: Ext: logical offset | length : physical offset | length 0: 0.. 16384 | 16384 : 151552.. 167936 | 16384 1: 16384.. 32768 | 16384 : 155648.. 172032 | 16384 2: 32768.. 49152 | 16384 : 537223168.. 537239552 | 16384 ... Here, extent 0/1 are physically overlapped although it's entirely _impossible_ for normal filesystem images generated by mkfs. First, managed folios containing compressed data will be marked as up-to-date and then unlocked immediately (unlike in-place folios) when compressed I/Os are complete. If physical blocks are not submitted in the incremental order, there should be separate BIOs to avoid dependency issues. However, the current code mis-arranges z_erofs_fill_bio_vec() and BIO submission which causes unexpected BIO waits. Second, managed folios will be connected to their own pclusters for efficient inter-queries. However, this is somewhat hard to implement easily if overlapped big pclusters exist. Again, these only appear in fuzzed images so let's simply fall back to temporary short-lived pages for correctness. Additionally, it justifies that referenced managed folios cannot be truncated for now and reverts part of commit 2080ca1ed3e4 (\"erofs: tidy up `struct z_erofs_bvec`\") for simplicity although it shouldn't be any difference.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47706", "url": "https://ubuntu.com/security/CVE-2024-47706", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: block, bfq: fix possible UAF for bfqq->bic with merge chain 1) initial state, three tasks: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t\t | ? | ?\t\t | ? \t\t | | | |\t\t | | \t\t V | V |\t\t V | \t\t bfqq1 bfqq2\t\t bfqq3 process ref:\t 1\t\t 1\t\t 1 2) bfqq1 merged to bfqq2: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t\t | |\t\t | ? \t\t \\--------------\\|\t\t | | \t\t V\t\t V | \t\t bfqq1--------->bfqq2\t\t bfqq3 process ref:\t 0\t\t 2\t\t 1 3) bfqq2 merged to bfqq3: \t\tProcess 1 Process 2\tProcess 3 \t\t (BIC1) (BIC2)\t\t (BIC3) \t here -> ? |\t\t | \t\t \\--------------\\ \\-------------\\| \t\t V\t\t V \t\t bfqq1--------->bfqq2---------->bfqq3 process ref:\t 0\t\t 1\t\t 3 In this case, IO from Process 1 will get bfqq2 from BIC1 first, and then get bfqq3 through merge chain, and finially handle IO by bfqq3. Howerver, current code will think bfqq2 is owned by BIC1, like initial state, and set bfqq2->bic to BIC1. bfq_insert_request -> by Process 1 bfqq = bfq_init_rq(rq) bfqq = bfq_get_bfqq_handle_split bfqq = bic_to_bfqq -> get bfqq2 from BIC1 bfqq->ref++ rq->elv.priv[0] = bic rq->elv.priv[1] = bfqq if (bfqq_process_refs(bfqq) == 1) bfqq->bic = bic -> record BIC1 to bfqq2 __bfq_insert_request new_bfqq = bfq_setup_cooperator -> get bfqq3 from bfqq2->new_bfqq bfqq_request_freed(bfqq) new_bfqq->ref++ rq->elv.priv[1] = new_bfqq -> handle IO by bfqq3 Fix the problem by checking bfqq is from merge chain fist. And this might fix a following problem reported by our syzkaller(unreproducible): ================================================================== BUG: KASAN: slab-use-after-free in bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] BUG: KASAN: slab-use-after-free in bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] BUG: KASAN: slab-use-after-free in bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 Write of size 1 at addr ffff888123839eb8 by task kworker/0:1H/18595 CPU: 0 PID: 18595 Comm: kworker/0:1H Tainted: G L 6.6.0-07439-gba2303cacfda #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Workqueue: kblockd blk_mq_requeue_work Call Trace: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:364 [inline] print_report+0x10d/0x610 mm/kasan/report.c:475 kasan_report+0x8e/0xc0 mm/kasan/report.c:588 bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline] bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline] bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889 bfq_get_bfqq_handle_split+0x169/0x5d0 block/bfq-iosched.c:6757 bfq_init_rq block/bfq-iosched.c:6876 [inline] bfq_insert_request block/bfq-iosched.c:6254 [inline] bfq_insert_requests+0x1112/0x5cf0 block/bfq-iosched.c:6304 blk_mq_insert_request+0x290/0x8d0 block/blk-mq.c:2593 blk_mq_requeue_work+0x6bc/0xa70 block/blk-mq.c:1502 process_one_work kernel/workqueue.c:2627 [inline] process_scheduled_works+0x432/0x13f0 kernel/workqueue.c:2700 worker_thread+0x6f2/0x1160 kernel/workqueue.c:2781 kthread+0x33c/0x440 kernel/kthread.c:388 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:305 Allocated by task 20776: kasan_save_stack+0x20/0x40 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 __kasan_slab_alloc+0x87/0x90 mm/kasan/common.c:328 kasan_slab_alloc include/linux/kasan.h:188 [inline] slab_post_alloc_hook mm/slab.h:763 [inline] slab_alloc_node mm/slub.c:3458 [inline] kmem_cache_alloc_node+0x1a4/0x6f0 mm/slub.c:3503 ioc_create_icq block/blk-ioc.c:370 [inline] ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49855", "url": "https://ubuntu.com/security/CVE-2024-49855", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: nbd: fix race between timeout and normal completion If request timetout is handled by nbd_requeue_cmd(), normal completion has to be stopped for avoiding to complete this requeued request, other use-after-free can be triggered. Fix the race by clearing NBD_CMD_INFLIGHT in nbd_requeue_cmd(), meantime make sure that cmd->lock is grabbed for clearing the flag and the requeue.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47707", "url": "https://ubuntu.com/security/CVE-2024-47707", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev() Blamed commit accidentally removed a check for rt->rt6i_idev being NULL, as spotted by syzbot: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 UID: 0 PID: 10998 Comm: syz-executor Not tainted 6.11.0-rc6-syzkaller-00208-g625403177711 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 RBP: ffffc900047375d0 R08: 0000000000000003 R09: fffff520008e6e8c R10: dffffc0000000000 R11: fffff520008e6e8c R12: 1ffff1100fdf8f18 R13: ffff88807efc7998 R14: 0000000000000000 R15: ffff88807efc7930 FS: 0000000000000000(0000) GS:ffff8880b8900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020002a80 CR3: 0000000022f62000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: addrconf_ifdown+0x15d/0x1bd0 net/ipv6/addrconf.c:3856 addrconf_notify+0x3cb/0x1020 notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93 call_netdevice_notifiers_extack net/core/dev.c:2032 [inline] call_netdevice_notifiers net/core/dev.c:2046 [inline] unregister_netdevice_many_notify+0xd81/0x1c40 net/core/dev.c:11352 unregister_netdevice_many net/core/dev.c:11414 [inline] unregister_netdevice_queue+0x303/0x370 net/core/dev.c:11289 unregister_netdevice include/linux/netdevice.h:3129 [inline] __tun_detach+0x6b9/0x1600 drivers/net/tun.c:685 tun_detach drivers/net/tun.c:701 [inline] tun_chr_close+0x108/0x1b0 drivers/net/tun.c:3510 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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:0x7f1acc77def9 Code: Unable to access opcode bytes at 0x7f1acc77decf. RSP: 002b:00007ffeb26fa738 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1acc77def9 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000043 RBP: 00007f1acc7dd508 R08: 00007ffeb26f84d7 R09: 0000000000000003 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 0000000000000003 R14: 00000000ffffffff R15: 00007ffeb26fa8e0 Modules linked in: ---[ end trace 0000000000000000 ]--- RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline] RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914 Code: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06 RSP: 0018:ffffc900047374e0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0 R ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47708", "url": "https://ubuntu.com/security/CVE-2024-47708", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: netkit: Assign missing bpf_net_context During the introduction of struct bpf_net_context handling for XDP-redirect, the netkit driver has been missed, which also requires it because NETKIT_REDIRECT invokes skb_do_redirect() which is accessing the per-CPU variables. Otherwise we see the following crash: \tBUG: kernel NULL pointer dereference, address: 0000000000000038 \tbpf_redirect() \tnetkit_xmit() \tdev_hard_start_xmit() Set the bpf_net_context before invoking netkit_xmit() program within the netkit driver.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47709", "url": "https://ubuntu.com/security/CVE-2024-47709", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: can: bcm: Clear bo->bcm_proc_read after remove_proc_entry(). syzbot reported a warning in bcm_release(). [0] The blamed change fixed another warning that is triggered when connect() is issued again for a socket whose connect()ed device has been unregistered. However, if the socket is just close()d without the 2nd connect(), the remaining bo->bcm_proc_read triggers unnecessary remove_proc_entry() in bcm_release(). Let's clear bo->bcm_proc_read after remove_proc_entry() in bcm_notify(). [0] name '4986' WARNING: CPU: 0 PID: 5234 at fs/proc/generic.c:711 remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Modules linked in: CPU: 0 UID: 0 PID: 5234 Comm: syz-executor606 Not tainted 6.11.0-rc5-syzkaller-00178-g5517ae241919 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:remove_proc_entry+0x2e7/0x5d0 fs/proc/generic.c:711 Code: ff eb 05 e8 cb 1e 5e ff 48 8b 5c 24 10 48 c7 c7 e0 f7 aa 8e e8 2a 38 8e 09 90 48 c7 c7 60 3a 1b 8c 48 89 de e8 da 42 20 ff 90 <0f> 0b 90 90 48 8b 44 24 18 48 c7 44 24 40 0e 36 e0 45 49 c7 04 07 RSP: 0018:ffffc9000345fa20 EFLAGS: 00010246 RAX: 2a2d0aee2eb64600 RBX: ffff888032f1f548 RCX: ffff888029431e00 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffffc9000345fb08 R08: ffffffff8155b2f2 R09: 1ffff1101710519a R10: dffffc0000000000 R11: ffffed101710519b R12: ffff888011d38640 R13: 0000000000000004 R14: 0000000000000000 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8880b8800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcfb52722f0 CR3: 000000000e734000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: bcm_release+0x250/0x880 net/can/bcm.c:1578 __sock_release net/socket.c:659 [inline] sock_close+0xbc/0x240 net/socket.c:1421 __fput+0x24a/0x8a0 fs/file_table.c:422 task_work_run+0x24f/0x310 kernel/task_work.c:228 exit_task_work include/linux/task_work.h:40 [inline] do_exit+0xa2f/0x27f0 kernel/exit.c:882 do_group_exit+0x207/0x2c0 kernel/exit.c:1031 __do_sys_exit_group kernel/exit.c:1042 [inline] __se_sys_exit_group kernel/exit.c:1040 [inline] __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040 x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232 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:0x7fcfb51ee969 Code: Unable to access opcode bytes at 0x7fcfb51ee93f. RSP: 002b:00007ffce0109ca8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7 RAX: ffffffffffffffda RBX: 0000000000000001 RCX: 00007fcfb51ee969 RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001 RBP: 00007fcfb526f3b0 R08: ffffffffffffffb8 R09: 0000555500000000 R10: 0000555500000000 R11: 0000000000000246 R12: 00007fcfb526f3b0 R13: 0000000000000000 R14: 00007fcfb5271ee0 R15: 00007fcfb51bf160 ", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47710", "url": "https://ubuntu.com/security/CVE-2024-47710", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: sock_map: Add a cond_resched() in sock_hash_free() Several syzbot soft lockup reports all have in common sock_hash_free() If a map with a large number of buckets is destroyed, we need to yield the cpu when needed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47711", "url": "https://ubuntu.com/security/CVE-2024-47711", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: af_unix: Don't return OOB skb in manage_oob(). syzbot reported use-after-free in unix_stream_recv_urg(). [0] The scenario is 1. send(MSG_OOB) 2. recv(MSG_OOB) -> The consumed OOB remains in recv queue 3. send(MSG_OOB) 4. recv() -> manage_oob() returns the next skb of the consumed OOB -> This is also OOB, but unix_sk(sk)->oob_skb is not cleared 5. recv(MSG_OOB) -> unix_sk(sk)->oob_skb is used but already freed The recent commit 8594d9b85c07 (\"af_unix: Don't call skb_get() for OOB skb.\") uncovered the issue. If the OOB skb is consumed and the next skb is peeked in manage_oob(), we still need to check if the skb is OOB. Let's do so by falling back to the following checks in manage_oob() and add the test case in selftest. Note that we need to add a similar check for SIOCATMARK. [0]: BUG: KASAN: slab-use-after-free in unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959 Read of size 4 at addr ffff8880326abcc4 by task syz-executor178/5235 CPU: 0 UID: 0 PID: 5235 Comm: syz-executor178 Not tainted 6.11.0-rc5-syzkaller-00742-gfbdaffe41adc #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Call Trace: __dump_stack lib/dump_stack.c:93 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119 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 unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959 unix_stream_recv_urg+0x1df/0x320 net/unix/af_unix.c:2640 unix_stream_read_generic+0x2456/0x2520 net/unix/af_unix.c:2778 unix_stream_recvmsg+0x22b/0x2c0 net/unix/af_unix.c:2996 sock_recvmsg_nosec net/socket.c:1046 [inline] sock_recvmsg+0x22f/0x280 net/socket.c:1068 ____sys_recvmsg+0x1db/0x470 net/socket.c:2816 ___sys_recvmsg net/socket.c:2858 [inline] __sys_recvmsg+0x2f0/0x3e0 net/socket.c:2888 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:0x7f5360d6b4e9 Code: 48 83 c4 28 c3 e8 37 17 00 00 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff29b3a458 EFLAGS: 00000246 ORIG_RAX: 000000000000002f RAX: ffffffffffffffda RBX: 00007fff29b3a638 RCX: 00007f5360d6b4e9 RDX: 0000000000002001 RSI: 0000000020000640 RDI: 0000000000000003 RBP: 00007f5360dde610 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001 R13: 00007fff29b3a628 R14: 0000000000000001 R15: 0000000000000001 Allocated by task 5235: kasan_save_stack mm/kasan/common.c:47 [inline] kasan_save_track+0x3f/0x80 mm/kasan/common.c:68 unpoison_slab_object mm/kasan/common.c:312 [inline] __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338 kasan_slab_alloc include/linux/kasan.h:201 [inline] slab_post_alloc_hook mm/slub.c:3988 [inline] slab_alloc_node mm/slub.c:4037 [inline] kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4080 __alloc_skb+0x1c3/0x440 net/core/skbuff.c:667 alloc_skb include/linux/skbuff.h:1320 [inline] alloc_skb_with_frags+0xc3/0x770 net/core/skbuff.c:6528 sock_alloc_send_pskb+0x91a/0xa60 net/core/sock.c:2815 sock_alloc_send_skb include/net/sock.h:1778 [inline] queue_oob+0x108/0x680 net/unix/af_unix.c:2198 unix_stream_sendmsg+0xd24/0xf80 net/unix/af_unix.c:2351 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597 ___sys_sendmsg net/socket.c:2651 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2680 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 Freed by task 5235: kasan_save_stack mm/kasan/common.c:47 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47712", "url": "https://ubuntu.com/security/CVE-2024-47712", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: wilc1000: fix potential RCU dereference issue in wilc_parse_join_bss_param In the `wilc_parse_join_bss_param` function, the TSF field of the `ies` structure is accessed after the RCU read-side critical section is unlocked. According to RCU usage rules, this is illegal. Reusing this pointer can lead to unpredictable behavior, including accessing memory that has been updated or causing use-after-free issues. This possible bug was identified using a static analysis tool developed by myself, specifically designed to detect RCU-related issues. To address this, the TSF value is now stored in a local variable `ies_tsf` before the RCU lock is released. The `param->tsf_lo` field is then assigned using this local variable, ensuring that the TSF value is safely accessed.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47713", "url": "https://ubuntu.com/security/CVE-2024-47713", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop() Since '__dev_queue_xmit()' should be called with interrupts enabled, the following backtrace: ieee80211_do_stop() ... spin_lock_irqsave(&local->queue_stop_reason_lock, flags) ... ieee80211_free_txskb() ieee80211_report_used_skb() ieee80211_report_ack_skb() cfg80211_mgmt_tx_status_ext() nl80211_frame_tx_status() genlmsg_multicast_netns() genlmsg_multicast_netns_filtered() nlmsg_multicast_filtered() \t netlink_broadcast_filtered() \t do_one_broadcast() \t netlink_broadcast_deliver() \t __netlink_sendskb() \t netlink_deliver_tap() \t __netlink_deliver_tap_skb() \t dev_queue_xmit() \t __dev_queue_xmit() ; with IRQS disabled ... spin_unlock_irqrestore(&local->queue_stop_reason_lock, flags) issues the warning (as reported by syzbot reproducer): WARNING: CPU: 2 PID: 5128 at kernel/softirq.c:362 __local_bh_enable_ip+0xc3/0x120 Fix this by implementing a two-phase skb reclamation in 'ieee80211_do_stop()', where actual work is performed outside of a section with interrupts disabled.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47730", "url": "https://ubuntu.com/security/CVE-2024-47730", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: hisilicon/qm - inject error before stopping queue The master ooo cannot be completely closed when the accelerator core reports memory error. Therefore, the driver needs to inject the qm error to close the master ooo. Currently, the qm error is injected after stopping queue, memory may be released immediately after stopping queue, causing the device to access the released memory. Therefore, error is injected to close master ooo before stopping queue to ensure that the device does not access the released memory.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49856", "url": "https://ubuntu.com/security/CVE-2024-49856", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: x86/sgx: Fix deadlock in SGX NUMA node search When the current node doesn't have an EPC section configured by firmware and all other EPC sections are used up, CPU can get stuck inside the while loop that looks for an available EPC page from remote nodes indefinitely, leading to a soft lockup. Note how nid_of_current will never be equal to nid in that while loop because nid_of_current is not set in sgx_numa_mask. Also worth mentioning is that it's perfectly fine for the firmware not to setup an EPC section on a node. While setting up an EPC section on each node can enhance performance, it is not a requirement for functionality. Rework the loop to start and end on *a* node that has SGX memory. This avoids the deadlock looking for the current SGX-lacking node to show up in the loop when it never will.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47714", "url": "https://ubuntu.com/security/CVE-2024-47714", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7996: use hweight16 to get correct tx antenna The chainmask is u16 so using hweight8 cannot get correct tx_ant. Without this patch, the tx_ant of band 2 would be -1 and lead to the following issue: BUG: KASAN: stack-out-of-bounds in mt7996_mcu_add_sta+0x12e0/0x16e0 [mt7996e]", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47715", "url": "https://ubuntu.com/security/CVE-2024-47715", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7915: fix oops on non-dbdc mt7986 mt7915_band_config() sets band_idx = 1 on the main phy for mt7986 with MT7975_ONE_ADIE or MT7976_ONE_ADIE. Commit 0335c034e726 (\"wifi: mt76: fix race condition related to checking tx queue fill status\") introduced a dereference of the phys array indirectly indexed by band_idx via wcid->phy_idx in mt76_wcid_cleanup(). This caused the following Oops on affected mt7986 devices: Unable to handle kernel read from unreadable memory at virtual address 0000000000000024 Mem abort info: ESR = 0x0000000096000005 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x05: level 1 translation fault Data abort info: ISV = 0, ISS = 0x00000005 CM = 0, WnR = 0 user pgtable: 4k pages, 39-bit VAs, pgdp=0000000042545000 [0000000000000024] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 Internal error: Oops: 0000000096000005 [#1] SMP Modules linked in: ... mt7915e mt76_connac_lib mt76 mac80211 cfg80211 ... CPU: 2 PID: 1631 Comm: hostapd Not tainted 5.15.150 #0 Hardware name: ZyXEL EX5700 (Telenor) (DT) pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mt76_wcid_cleanup+0x84/0x22c [mt76] lr : mt76_wcid_cleanup+0x64/0x22c [mt76] sp : ffffffc00a803700 x29: ffffffc00a803700 x28: ffffff80008f7300 x27: ffffff80003f3c00 x26: ffffff80000a7880 x25: ffffffc008c26e00 x24: 0000000000000001 x23: ffffffc000a68114 x22: 0000000000000000 x21: ffffff8004172cc8 x20: ffffffc00a803748 x19: ffffff8004152020 x18: 0000000000000000 x17: 00000000000017c0 x16: ffffffc008ef5000 x15: 0000000000000be0 x14: ffffff8004172e28 x13: ffffff8004172e28 x12: 0000000000000000 x11: 0000000000000000 x10: ffffff8004172e30 x9 : ffffff8004172e28 x8 : 0000000000000000 x7 : ffffff8004156020 x6 : 0000000000000000 x5 : 0000000000000031 x4 : 0000000000000000 x3 : 0000000000000001 x2 : 0000000000000000 x1 : ffffff80008f7300 x0 : 0000000000000024 Call trace: mt76_wcid_cleanup+0x84/0x22c [mt76] __mt76_sta_remove+0x70/0xbc [mt76] mt76_sta_state+0x8c/0x1a4 [mt76] mt7915_eeprom_get_power_delta+0x11e4/0x23a0 [mt7915e] drv_sta_state+0x144/0x274 [mac80211] sta_info_move_state+0x1cc/0x2a4 [mac80211] sta_set_sinfo+0xaf8/0xc24 [mac80211] sta_info_destroy_addr_bss+0x4c/0x6c [mac80211] ieee80211_color_change_finish+0x1c08/0x1e70 [mac80211] cfg80211_check_station_change+0x1360/0x4710 [cfg80211] genl_family_rcv_msg_doit+0xb4/0x110 genl_rcv_msg+0xd0/0x1bc netlink_rcv_skb+0x58/0x120 genl_rcv+0x34/0x50 netlink_unicast+0x1f0/0x2ec netlink_sendmsg+0x198/0x3d0 ____sys_sendmsg+0x1b0/0x210 ___sys_sendmsg+0x80/0xf0 __sys_sendmsg+0x44/0xa0 __arm64_sys_sendmsg+0x20/0x30 invoke_syscall.constprop.0+0x4c/0xe0 do_el0_svc+0x40/0xd0 el0_svc+0x14/0x4c el0t_64_sync_handler+0x100/0x110 el0t_64_sync+0x15c/0x160 Code: d2800002 910092c0 52800023 f9800011 (885f7c01) ---[ end trace 7e42dd9a39ed2281 ]--- Fix by using mt76_dev_phy() which will map band_idx to the correct phy for all hardware combinations.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-49857", "url": "https://ubuntu.com/security/CVE-2024-49857", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: set the cipher for secured NDP ranging The cipher pointer is not set, but is derefereced trying to set its content, which leads to a NULL pointer dereference. Fix it by pointing to the cipher parameter before dereferencing.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47738", "url": "https://ubuntu.com/security/CVE-2024-47738", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: don't use rate mask for offchannel TX either Like the commit ab9177d83c04 (\"wifi: mac80211: don't use rate mask for scanning\"), ignore incorrect settings to avoid no supported rate warning reported by syzbot. The syzbot did bisect and found cause is commit 9df66d5b9f45 (\"cfg80211: fix default HE tx bitrate mask in 2G band\"), which however corrects bitmask of HE MCS and recognizes correctly settings of empty legacy rate plus HE MCS rate instead of returning -EINVAL. As suggestions [1], follow the change of SCAN TX to consider this case of offchannel TX as well. [1] https://lore.kernel.org/linux-wireless/6ab2dc9c3afe753ca6fdcdd1421e7a1f47e87b84.camel@sipsolutions.net/T/#m2ac2a6d2be06a37c9c47a3d8a44b4f647ed4f024", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47731", "url": "https://ubuntu.com/security/CVE-2024-47731", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: drivers/perf: Fix ali_drw_pmu driver interrupt status clearing The alibaba_uncore_pmu driver forgot to clear all interrupt status in the interrupt processing function. After the PMU counter overflow interrupt occurred, an interrupt storm occurred, causing the system to hang. Therefore, clear the correct interrupt status in the interrupt handling function to fix it.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-49862", "url": "https://ubuntu.com/security/CVE-2024-49862", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: powercap: intel_rapl: Fix off by one in get_rpi() The rp->priv->rpi array is either rpi_msr or rpi_tpmi which have NR_RAPL_PRIMITIVES number of elements. Thus the > needs to be >= to prevent an off by one access.", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47716", "url": "https://ubuntu.com/security/CVE-2024-47716", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: ARM: 9410/1: vfp: Use asm volatile in fmrx/fmxr macros Floating point instructions in userspace can crash some arm kernels built with clang/LLD 17.0.6: BUG: unsupported FP instruction in kernel mode FPEXC == 0xc0000780 Internal error: Oops - undefined instruction: 0 [#1] ARM CPU: 0 PID: 196 Comm: vfp-reproducer Not tainted 6.10.0 #1 Hardware name: BCM2835 PC is at vfp_support_entry+0xc8/0x2cc LR is at do_undefinstr+0xa8/0x250 pc : [] lr : [] psr: a0000013 sp : dc8d1f68 ip : 60000013 fp : bedea19c r10: ec532b17 r9 : 00000010 r8 : 0044766c r7 : c0000780 r6 : ec532b17 r5 : c1c13800 r4 : dc8d1fb0 r3 : c10072c4 r2 : c0101c88 r1 : ec532b17 r0 : 0044766c Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none Control: 00c5387d Table: 0251c008 DAC: 00000051 Register r0 information: non-paged memory Register r1 information: vmalloc memory Register r2 information: non-slab/vmalloc memory Register r3 information: non-slab/vmalloc memory Register r4 information: 2-page vmalloc region Register r5 information: slab kmalloc-cg-2k Register r6 information: vmalloc memory Register r7 information: non-slab/vmalloc memory Register r8 information: non-paged memory Register r9 information: zero-size pointer Register r10 information: vmalloc memory Register r11 information: non-paged memory Register r12 information: non-paged memory Process vfp-reproducer (pid: 196, stack limit = 0x61aaaf8b) Stack: (0xdc8d1f68 to 0xdc8d2000) 1f60: 0000081f b6f69300 0000000f c10073f4 c10072c4 dc8d1fb0 1f80: ec532b17 0c532b17 0044766c b6f9ccd8 00000000 c010a80c 00447670 60000010 1fa0: ffffffff c1c13800 00c5387d c0100f10 b6f68af8 00448fc0 00000000 bedea188 1fc0: bedea314 00000001 00448ebc b6f9d000 00447608 b6f9ccd8 00000000 bedea19c 1fe0: bede9198 bedea188 b6e1061c 0044766c 60000010 ffffffff 00000000 00000000 Call trace: [] (vfp_support_entry) from [] (do_undefinstr+0xa8/0x250) [] (do_undefinstr) from [] (__und_usr+0x70/0x80) Exception stack(0xdc8d1fb0 to 0xdc8d1ff8) 1fa0: b6f68af8 00448fc0 00000000 bedea188 1fc0: bedea314 00000001 00448ebc b6f9d000 00447608 b6f9ccd8 00000000 bedea19c 1fe0: bede9198 bedea188 b6e1061c 0044766c 60000010 ffffffff Code: 0a000061 e3877202 e594003c e3a09010 (eef16a10) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Fatal exception in interrupt ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]--- This is a minimal userspace reproducer on a Raspberry Pi Zero W: #include #include int main(void) { double v = 1.0; printf(\"%fn\", NAN + *(volatile double *)&v); return 0; } Another way to consistently trigger the oops is: calvin@raspberry-pi-zero-w ~$ python -c \"import json\" The bug reproduces only when the kernel is built with DYNAMIC_DEBUG=n, because the pr_debug() calls act as barriers even when not activated. This is the output from the same kernel source built with the same compiler and DYNAMIC_DEBUG=y, where the userspace reproducer works as expected: VFP: bounce: trigger ec532b17 fpexc c0000780 VFP: emulate: INST=0xee377b06 SCR=0x00000000 VFP: bounce: trigger eef1fa10 fpexc c0000780 VFP: emulate: INST=0xeeb40b40 SCR=0x00000000 VFP: raising exceptions 30000000 calvin@raspberry-pi-zero-w ~$ ./vfp-reproducer nan Crudely grepping for vmsr/vmrs instructions in the otherwise nearly idential text for vfp_support_entry() makes the problem obvious: vmlinux.llvm.good [0xc0101cb8] <+48>: vmrs r7, fpexc vmlinux.llvm.good [0xc0101cd8] <+80>: vmsr fpexc, r0 vmlinux.llvm.good [0xc0101d20 ---truncated---", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47717", "url": "https://ubuntu.com/security/CVE-2024-47717", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: RISC-V: KVM: Don't zero-out PMU snapshot area before freeing data With the latest Linux-6.11-rc3, the below NULL pointer crash is observed when SBI PMU snapshot is enabled for the guest and the guest is forcefully powered-off. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000508 Oops [#1] Modules linked in: kvm CPU: 0 UID: 0 PID: 61 Comm: term-poll Not tainted 6.11.0-rc3-00018-g44d7178dd77a #3 Hardware name: riscv-virtio,qemu (DT) epc : __kvm_write_guest_page+0x94/0xa6 [kvm] ra : __kvm_write_guest_page+0x54/0xa6 [kvm] epc : ffffffff01590e98 ra : ffffffff01590e58 sp : ffff8f80001f39b0 gp : ffffffff81512a60 tp : ffffaf80024872c0 t0 : ffffaf800247e000 t1 : 00000000000007e0 t2 : 0000000000000000 s0 : ffff8f80001f39f0 s1 : 00007fff89ac4000 a0 : ffffffff015dd7e8 a1 : 0000000000000086 a2 : 0000000000000000 a3 : ffffaf8000000000 a4 : ffffaf80024882c0 a5 : 0000000000000000 a6 : ffffaf800328d780 a7 : 00000000000001cc s2 : ffffaf800197bd00 s3 : 00000000000828c4 s4 : ffffaf800248c000 s5 : ffffaf800247d000 s6 : 0000000000001000 s7 : 0000000000001000 s8 : 0000000000000000 s9 : 00007fff861fd500 s10: 0000000000000001 s11: 0000000000800000 t3 : 00000000000004d3 t4 : 00000000000004d3 t5 : ffffffff814126e0 t6 : ffffffff81412700 status: 0000000200000120 badaddr: 0000000000000508 cause: 000000000000000d [] __kvm_write_guest_page+0x94/0xa6 [kvm] [] kvm_vcpu_write_guest+0x56/0x90 [kvm] [] kvm_pmu_clear_snapshot_area+0x42/0x7e [kvm] [] kvm_riscv_vcpu_pmu_deinit.part.0+0xe0/0x14e [kvm] [] kvm_riscv_vcpu_pmu_deinit+0x1a/0x24 [kvm] [] kvm_arch_vcpu_destroy+0x28/0x4c [kvm] [] kvm_destroy_vcpus+0x5a/0xda [kvm] [] kvm_arch_destroy_vm+0x14/0x28 [kvm] [] kvm_destroy_vm+0x168/0x2a0 [kvm] [] kvm_put_kvm+0x3c/0x58 [kvm] [] kvm_vm_release+0x22/0x2e [kvm] Clearly, the kvm_vcpu_write_guest() function is crashing because it is being called from kvm_pmu_clear_snapshot_area() upon guest tear down. To address the above issue, simplify the kvm_pmu_clear_snapshot_area() to not zero-out PMU snapshot area from kvm_pmu_clear_snapshot_area() because the guest is anyway being tore down. The kvm_pmu_clear_snapshot_area() is also called when guest changes PMU snapshot area of a VCPU but even in this case the previous PMU snaphsot area must not be zeroed-out because the guest might have reclaimed the pervious PMU snapshot area for some other purpose.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47721", "url": "https://ubuntu.com/security/CVE-2024-47721", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: remove unused C2H event ID RTW89_MAC_C2H_FUNC_READ_WOW_CAM to prevent out-of-bounds reading The handler of firmware C2H event RTW89_MAC_C2H_FUNC_READ_WOW_CAM isn't implemented, but driver expects number of handlers is NUM_OF_RTW89_MAC_C2H_FUNC_WOW causing out-of-bounds access. Fix it by removing ID. Addresses-Coverity-ID: 1598775 (\"Out-of-bounds read\")", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47732", "url": "https://ubuntu.com/security/CVE-2024-47732", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: crypto: iaa - Fix potential use after free bug The free_device_compression_mode(iaa_device, device_mode) function frees \"device_mode\" but it iss passed to iaa_compression_modes[i]->free() a few lines later resulting in a use after free. The good news is that, so far as I can tell, nothing implements the ->free() function and the use after free happens in dead code. But, with this fix, when something does implement it, we'll be ready. :)", "cve_priority": "medium", "cve_public_date": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47718", "url": "https://ubuntu.com/security/CVE-2024-47718", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: rtw88: always wait for both firmware loading attempts In 'rtw_wait_firmware_completion()', always wait for both (regular and wowlan) firmware loading attempts. Otherwise if 'rtw_usb_intf_init()' has failed in 'rtw_usb_probe()', 'rtw_usb_disconnect()' may issue 'ieee80211_free_hw()' when one of 'rtw_load_firmware_cb()' (usually the wowlan one) is still in progress, causing UAF detected by KASAN.", "cve_priority": "medium", "cve_public_date": "2024-10-21 12:15:00 UTC" }, { "cve": "CVE-2024-47724", "url": "https://ubuntu.com/security/CVE-2024-47724", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: use work queue to process beacon tx event Commit 3a415daa3e8b (\"wifi: ath11k: add P2P IE in beacon template\") from Feb 28, 2024 (linux-next), leads to the following Smatch static checker warning: drivers/net/wireless/ath/ath11k/wmi.c:1742 ath11k_wmi_p2p_go_bcn_ie() warn: sleeping in atomic context The reason is that ath11k_bcn_tx_status_event() will directly call might sleep function ath11k_wmi_cmd_send() during RCU read-side critical sections. The call trace is like: ath11k_bcn_tx_status_event() -> rcu_read_lock() -> ath11k_mac_bcn_tx_event() \t-> ath11k_mac_setup_bcn_tmpl() \t…… \t\t-> ath11k_wmi_bcn_tmpl() \t\t\t-> ath11k_wmi_cmd_send() -> rcu_read_unlock() Commit 886433a98425 (\"ath11k: add support for BSS color change\") added the ath11k_mac_bcn_tx_event(), commit 01e782c89108 (\"ath11k: fix warning of RCU usage for ath11k_mac_get_arvif_by_vdev_id()\") added the RCU lock to avoid warning but also introduced this BUG. Use work queue to avoid directly calling ath11k_mac_bcn_tx_event() during RCU critical sections. No need to worry about the deletion of vif because cancel_work_sync() will drop the work if it doesn't start or block vif deletion until the running work is done. 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": "2024-10-21 13:15:00 UTC" }, { "cve": "CVE-2024-47671", "url": "https://ubuntu.com/security/CVE-2024-47671", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: USB: usbtmc: prevent kernel-usb-infoleak The syzbot reported a kernel-usb-infoleak in usbtmc_write, we need to clear the structure before filling fields.", "cve_priority": "medium", "cve_public_date": "2024-10-09 15:15:00 UTC" }, { "cve": "CVE-2024-46869", "url": "https://ubuntu.com/security/CVE-2024-46869", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: Bluetooth: btintel_pcie: Allocate memory for driver private data Fix driver not allocating memory for struct btintel_data which is used to store internal data.", "cve_priority": "medium", "cve_public_date": "2024-09-30 16:15:00 UTC" }, { "cve": "CVE-2024-53164", "url": "https://ubuntu.com/security/CVE-2024-53164", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: net: sched: fix ordering of qlen adjustment Changes to sch->q.qlen around qdisc_tree_reduce_backlog() need to happen _before_ a call to said function because otherwise it may fail to notify parent qdiscs when the child is about to become empty.", "cve_priority": "medium", "cve_public_date": "2024-12-27 14:15:00 UTC" }, { "cve": "CVE-2024-53103", "url": "https://ubuntu.com/security/CVE-2024-53103", "cve_description": "In the Linux kernel, the following vulnerability has been resolved: hv_sock: Initializing vsk->trans to NULL to prevent a dangling pointer When hvs is released, there is a possibility that vsk->trans may not be initialized to NULL, which could lead to a dangling pointer. This issue is resolved by initializing vsk->trans to NULL.", "cve_priority": "high", "cve_public_date": "2024-12-02 08:15:00 UTC" } ], "log": [ "", " * oracular/linux: 6.11.0-17.17 -proposed tracker (LP: #2093643)", "", " * Packaging resync (LP: #1786013)", " - [Packaging] debian.master/dkms-versions -- update from kernel-versions", " (main/2025.01.13)", "", " * When /dev/vmbus/hv_kvp is not present, disable hv-kvp-daemon (LP: #2091744)", " - [Packaging] disable hv-kvp-daemon if needed", "", " * Backport \"netkit: Add option for scrubbing skb meta data\" to 6.8", " (LP: #2091184)", " - netkit: Add option for scrubbing skb meta data", "", " * KVM: Cache CPUID at KVM.ko module init to reduce latency of VM-Enter and VM-", " Exit (LP: #2093146)", " - KVM: x86: Cache CPUID.0xD XSTATE offsets+sizes during module init", "", " * [SRU] add support of QCA BT 0489:e0fc (LP: #2085406)", " - Bluetooth: btusb: add Foxconn 0xe0fc for Qualcomm WCN785x", "", " * oracular: ubuntu_boot lib/dynamic_queue_limits.c:99! (LP: #2089684)", " - virtio_net: correct netdev_tx_reset_queue() invocation point", " - virtio_ring: add a func argument 'recycle_done' to virtqueue_resize()", " - virtio_net: ensure netdev_tx_reset_queue is called on tx ring resize", "", " * Failed to probe for OVTI02C1: chip id mismatch: 560243!=0 (LP: #2090932)", " - SAUCE: ACPI: scan: Update HID for new platform", "", " * Bluetooth[8086:a876] crash with \"hci0: Failed to read MSFT supported", " features (-110)\" (LP: #2085485)", " - Bluetooth: btintel_pcie: Add recovery mechanism", "", " * Poor bluetooth performance on Lenovo X13s (LP: #2089357)", " - SAUCE: Bluetooth: qca: Support downloading board ID specific NVM for WCN6855", "", " * vfio_pci soft lockup on VM start while using PCIe passthrough (LP: #2089306)", " - SAUCE: Revert \"mm: use rwsem assertion macros for mmap_lock\"", " - SAUCE: Revert \"vfio/pci: Insert full vma on mmap'd MMIO fault\"", " - SAUCE: Revert \"vfio/pci: Use unmap_mapping_range()\"", "", " * Oracular update: v6.11.11 upstream stable release (LP: #2091655)", " - wifi: mac80211: Fix setting txpower with emulate_chanctx", " - wifi: cfg80211: Add wiphy_delayed_work_pending()", " - wifi: mac80211: Convert color collision detection to wiphy work", " - wifi: radiotap: Avoid -Wflex-array-member-not-at-end warnings", " - spi: stm32: fix missing device mode capability in stm32mp25", " - ASoC: codecs: rt5640: Always disable IRQs from rt5640_cancel_work()", " - ASoC: Intel: bytcr_rt5640: Add support for non ACPI instantiated codec", " - ASoC: Intel: bytcr_rt5640: Add DMI quirk for Vexia Edu Atla 10 tablet", " - ASoC: Intel: sst: Support LPE0F28 ACPI HID", " - wifi: iwlwifi: mvm: Use the sync timepoint API in suspend", " - wifi: iwlwifi: mvm: SAR table alignment", " - mac80211: fix user-power when emulating chanctx", " - usb: add support for new USB device ID 0x17EF:0x3098 for the r8152 driver", " - usb: typec: use cleanup facility for 'altmodes_node'", " - selftests/watchdog-test: Fix system accidentally reset after watchdog-test", " - ALSA: hda/realtek: Add subwoofer quirk for Infinix ZERO BOOK 13", " - ASoC: codecs: wcd937x: add missing LO Switch control", " - ASoC: codecs: wcd937x: relax the AUX PDM watchdog", " - x86/amd_nb: Fix compile-testing without CONFIG_AMD_NB", " - bpf: fix filed access without lock", " - net: usb: qmi_wwan: add Quectel RG650V", " - soc: qcom: Add check devm_kasprintf() returned value", " - firmware: arm_scmi: Reject clear channel request on A2P", " - regulator: rk808: Add apply_bit for BUCK3 on RK809", " - platform/x86: dell-smbios-base: Extends support to Alienware products", " - platform/x86: dell-wmi-base: Handle META key Lock/Unlock events", " - platform/x86: ideapad-laptop: add missing Ideapad Pro 5 fn keys", " - ASoC: tas2781: Add new driver version for tas2563 & tas2781 qfn chip", " - tools/lib/thermal: Remove the thermal.h soft link when doing make clean", " - can: j1939: fix error in J1939 documentation.", " - platform/x86: thinkpad_acpi: Fix for ThinkPad's with ECFW showing incorrect", " fan speed", " - ASoC: amd: yc: Support dmic on another model of Lenovo Thinkpad E14 Gen 6", " - ASoC: stm: Prevent potential division by zero in stm32_sai_mclk_round_rate()", " - ASoC: stm: Prevent potential division by zero in stm32_sai_get_clk_div()", " - drm: panel-orientation-quirks: Make Lenovo Yoga Tab 3 X90F DMI match less", " strict", " - proc/softirqs: replace seq_printf with seq_put_decimal_ull_width", " - integrity: Use static_assert() to check struct sizes", " - ASoC: audio-graph-card2: Purge absent supplies for device tree nodes", " - LoongArch: For all possible CPUs setup logical-physical CPU mapping", " - LoongArch: Define a default value for VM_DATA_DEFAULT_FLAGS", " - ASoC: max9768: Fix event generation for playback mute", " - ALSA: usb-audio: Fix Yamaha P-125 Quirk Entry", " - ARM: 9420/1: smp: Fix SMP for xip kernels", " - ARM: 9434/1: cfi: Fix compilation corner case", " - ipmr: Fix access to mfc_cache_list without lock held", " - f2fs: fix fiemap failure issue when page size is 16KB", " - drm/amd/display: Skip Invalid Streams from DSC Policy", " - drm/amd/display: Fix incorrect DSC recompute trigger", " - s390/facilities: Fix warning about shadow of global variable", " - efs: fix the efs new mount api implementation", " - arm64: probes: Disable kprobes/uprobes on MOPS instructions", " - kselftest/arm64: hwcap: fix f8dp2 cpuinfo name", " - kselftest/arm64: mte: fix printf type warnings about __u64", " - kselftest/arm64: mte: fix printf type warnings about longs", " - block/fs: Pass an iocb to generic_atomic_write_valid()", " - fs/block: Check for IOCB_DIRECT in generic_atomic_write_valid()", " - s390/cio: Do not unregister the subchannel based on DNV", " - s390/pageattr: Implement missing kernel_page_present()", " - x86/pvh: Set phys_base when calling xen_prepare_pvh()", " - x86/pvh: Call C code via the kernel virtual mapping", " - brd: defer automatic disk creation until module initialization succeeds", " - ext4: avoid remount errors with 'abort' mount option", " - mips: asm: fix warning when disabling MIPS_FP_SUPPORT", " - arm64: Expose ID_AA64ISAR1_EL1.XS to sanitised feature consumers", " - kselftest/arm64: Fix encoding for SVE B16B16 test", " - nvme-pci: fix freeing of the HMB descriptor table", " - m68k: mvme147: Fix SCSI controller IRQ numbers", " - m68k: mvme147: Reinstate early console", " - arm64: fix .data.rel.ro size assertion when CONFIG_LTO_CLANG", " - acpi/arm64: Adjust error handling procedure in gtdt_parse_timer_block()", " - loop: fix type of block size", " - cachefiles: Fix incorrect length return value in", " cachefiles_ondemand_fd_write_iter()", " - cachefiles: Fix missing pos updates in cachefiles_ondemand_fd_write_iter()", " - cachefiles: Fix NULL pointer dereference in object->file", " - netfs/fscache: Add a memory barrier for FSCACHE_VOLUME_CREATING", " - block: constify the lim argument to queue_limits_max_zone_append_sectors", " - block: properly handle REQ_OP_ZONE_APPEND in __bio_split_to_limits", " - block: take chunk_sectors into account in bio_split_write_zeroes", " - block: fix bio_split_rw_at to take zone_write_granularity into account", " - s390/syscalls: Avoid creation of arch/arch/ directory", " - hfsplus: don't query the device logical block size multiple times", " - ext4: pipeline buffer reads in mext_page_mkuptodate()", " - ext4: remove array of buffer_heads from mext_page_mkuptodate()", " - ext4: fix race in buffer_head read fault injection", " - nvme-pci: reverse request order in nvme_queue_rqs", " - virtio_blk: reverse request order in virtio_queue_rqs", " - crypto: mxs-dcp - Fix AES-CBC with hardware-bound keys", " - crypto: caam - Fix the pointer passed to caam_qi_shutdown()", " - crypto: qat - remove check after debugfs_create_dir()", " - crypto: qat/qat_420xx - fix off by one in uof_get_name()", " - crypto: qat/qat_4xxx - fix off by one in uof_get_name()", " - firmware: google: Unregister driver_info on failure", " - EDAC/bluefield: Fix potential integer overflow", " - crypto: qat - remove faulty arbiter config reset", " - thermal: core: Initialize thermal zones before registering them", " - thermal: core: Drop thermal_zone_device_is_enabled()", " - thermal: core: Rearrange PM notification code", " - thermal: core: Represent suspend-related thermal zone flags as bits", " - thermal: core: Mark thermal zones as initializing to start with", " - thermal: core: Fix race between zone registration and system suspend", " - EDAC/fsl_ddr: Fix bad bit shift operations", " - EDAC/skx_common: Differentiate memory error sources", " - EDAC/{skx_common,i10nm}: Fix incorrect far-memory error source indicator", " - crypto: pcrypt - Call crypto layer directly when padata_do_parallel() return", " -EBUSY", " - crypto: cavium - Fix the if condition to exit loop after timeout", " - cpufreq/amd-pstate: Don't update CPPC request in", " amd_pstate_cpu_boost_update()", " - amd-pstate: Set min_perf to nominal_perf for active mode performance gov", " - crypto: hisilicon/qm - disable same error report before resetting", " - EDAC/igen6: Avoid segmentation fault on module unload", " - crypto: qat - Fix missing destroy_workqueue in adf_init_aer()", " - crypto: inside-secure - Fix the return value of safexcel_xcbcmac_cra_init()", " - sched/cpufreq: Ensure sd is rebuilt for EAS check", " - doc: rcu: update printed dynticks counter bits", " - rcu/srcutiny: don't return before reenabling preemption", " - rcu/kvfree: Fix data-race in __mod_timer / kvfree_call_rcu", " - hwmon: (pmbus/core) clear faults after setting smbalert mask", " - hwmon: (nct6775-core) Fix overflows seen when writing limit attributes", " - ACPI: CPPC: Fix _CPC register setting issue", " - crypto: caam - add error check to caam_rsa_set_priv_key_form", " - crypto: bcm - add error check in the ahash_hmac_init function", " - crypto: cavium - Fix an error handling path in cpt_ucode_load_fw()", " - rcuscale: Do a proper cleanup if kfree_scale_init() fails", " - tools/lib/thermal: Make more generic the command encoding function", " - thermal/lib: Fix memory leak on error in thermal_genl_auto()", " - x86/unwind/orc: Fix unwind for newly forked tasks", " - Revert \"scripts/faddr2line: Check only two symbols when calculating symbol", " size\"", " - cleanup: Remove address space of returned pointer", " - time: Partially revert cleanup on msecs_to_jiffies() documentation", " - time: Fix references to _msecs_to_jiffies() handling of values", " - locking/atomic/x86: Use ALT_OUTPUT_SP() for __alternative_atomic64()", " - locking/atomic/x86: Use ALT_OUTPUT_SP() for __arch_{,try_}cmpxchg64_emu()", " - kcsan, seqlock: Support seqcount_latch_t", " - kcsan, seqlock: Fix incorrect assumption in read_seqbegin()", " - clocksource/drivers:sp804: Make user selectable", " - clocksource/drivers/timer-ti-dm: Fix child node refcount handling", " - regulator: qcom-smd: make smd_vreg_rpm static", " - spi: spi-fsl-lpspi: Use IRQF_NO_AUTOEN flag in request_irq()", " - arm64: dts: qcom: qcs6390-rb3gen2: use modem.mbn for modem DSP", " - ARM: dts: renesas: genmai: Fix partition size for QSPI NOR Flash", " - drivers: soc: xilinx: add the missing kfree in xlnx_add_cb_for_suspend()", " - microblaze: Export xmb_manager functions", " - arm64: dts: mediatek: mt8188: Fix wrong clock provider in MFG1 power domain", " - arm64: dts: mediatek: mt8395-genio-1200-evk: Fix dtbs_check error for phy", " - arm64: dts: mt8195: Fix dtbs_check error for mutex node", " - arm64: dts: mt8195: Fix dtbs_check error for infracfg_ao node", " - soc: ti: smartreflex: Use IRQF_NO_AUTOEN flag in request_irq()", " - soc: qcom: geni-se: fix array underflow in geni_se_clk_tbl_get()", " - arm64: dts: qcom: sm6350: Fix GPU frequencies missing on some speedbins", " - arm64: dts: qcom: sda660-ifc6560: fix l10a voltage ranges", " - ARM: dts: microchip: sam9x60: Add missing property atmel,usart-mode", " - mmc: mmc_spi: drop buggy snprintf()", " - scripts/kernel-doc: Do not track section counter across processed files", " - arm64: dts: qcom: x1e80100-slim7x: Drop orientation-switch from USB SS[0-1]", " QMP PHYs", " - arm64: dts: qcom: x1e80100-vivobook-s15: Drop orientation-switch from USB", " SS[0-1] QMP PHYs", " - openrisc: Implement fixmap to fix earlycon", " - efi/libstub: fix efi_parse_options() ignoring the default command line", " - tpm: fix signed/unsigned bug when checking event logs", " - media: i2c: vgxy61: Fix an error handling path in vgxy61_detect()", " - media: i2c: ds90ub960: Fix missing return check on ub960_rxport_read call", " - arm64: dts: mt8183: krane: Fix the address of eeprom at i2c4", " - arm64: dts: mt8183: kukui: Fix the address of eeprom at i2c4", " - arm64: dts: qcom: x1e80100: Resize GIC Redistributor register region", " - kernel-doc: allow object-like macros in ReST output", " - arm64: dts: ti: k3-am62x-phyboard-lyra: Drop unnecessary McASP AFIFOs", " - arm64: dts: mediatek: mt8173-elm-hana: Add vdd-supply to second source", " trackpad", " - arm64: dts: mediatek: mt8188: Fix USB3 PHY port default status", " - arm64: dts: mediatek: mt8195-cherry: Use correct audio codec DAI", " - Revert \"cgroup: Fix memory leak caused by missing cgroup_bpf_offline\"", " - cgroup/bpf: only cgroup v2 can be attached by bpf programs", " - regulator: rk808: Restrict DVS GPIOs to the RK808 variant only", " - power: sequencing: make the QCom PMU pwrseq driver depend on CONFIG_OF", " - [Config] updateconfigs for POWER_SEQUENCING_QCOM_WCN", " - arm64: dts: rockchip: Remove 'enable-active-low' from two boards", " - arm64: dts: mt8183: fennel: add i2c2's i2c-scl-internal-delay-ns", " - arm64: dts: mt8183: burnet: add i2c2's i2c-scl-internal-delay-ns", " - arm64: dts: mt8183: cozmo: add i2c2's i2c-scl-internal-delay-ns", " - arm64: dts: mt8183: Damu: add i2c2's i2c-scl-internal-delay-ns", " - pwm: imx27: Workaround of the pwm output bug when decrease the duty cycle", " - ARM: dts: cubieboard4: Fix DCDC5 regulator constraints", " - arm64: dts: ti: k3-j7200: Fix register map for main domain pmx", " - arm64: dts: ti: k3-j7200: Fix clock ids for MCSPI instances", " - arm64: dts: ti: k3-j721e: Fix clock IDs for MCSPI instances", " - arm64: dts: ti: k3-j721s2: Fix clock IDs for MCSPI instances", " - watchdog: Add HAS_IOPORT dependency for SBC8360 and SBC7240", " - arm64: dts: qcom: x1e80100: Update C4/C5 residency/exit numbers", " - dt-bindings: cache: qcom,llcc: Fix X1E80100 reg entries", " - of/fdt: add dt_phys arg to early_init_dt_scan and early_init_dt_verify", " - pmdomain: ti-sci: Add missing of_node_put() for args.np", " - spi: tegra210-quad: Avoid shift-out-of-bounds", " - spi: zynqmp-gqspi: Undo runtime PM changes at driver exit time​", " - regmap: irq: Set lockdep class for hierarchical IRQ domains", " - arm64: dts: renesas: hihope: Drop #sound-dai-cells", " - arm64: dts: imx8mn-tqma8mqnl-mba8mx-usbot: fix coexistence of output-low and", " output-high in GPIO", " - arm64: dts: mediatek: Add ADC node on MT6357, MT6358, MT6359 PMICs", " - arm64: dts: mediatek: mt6358: fix dtbs_check error", " - arm64: dts: mediatek: mt8183-kukui-jacuzzi: Fix DP bridge supply names", " - arm64: dts: mediatek: mt8183-kukui-jacuzzi: Add supplies for fixed", " regulators", " - selftests/resctrl: Print accurate buffer size as part of MBM results", " - selftests/resctrl: Fix memory overflow due to unhandled wraparound", " - selftests/resctrl: Protect against array overrun during iMC config parsing", " - firmware: arm_scpi: Check the DVFS OPP count returned by the firmware", " - media: ipu6: Fix DMA and physical address debugging messages for 32-bit", " - media: ipu6: not override the dma_ops of device in driver", " - pwm: Assume a disabled PWM to emit a constant inactive output", " - media: atomisp: Add check for rgby_data memory allocation failure", " - arm64: dts: rockchip: correct analog audio name on Indiedroid Nova", " - HID: hyperv: streamline driver probe to avoid devres issues", " - platform/x86: panasonic-laptop: Return errno correctly in show callback", " - drm/imagination: Convert to use time_before macro", " - drm/imagination: Use pvr_vm_context_get()", " - drm/mm: Mark drm_mm_interval_tree*() functions with __maybe_unused", " - drm/vc4: hvs: Don't write gamma luts on 2711", " - drm/vc4: hdmi: Avoid hang with debug registers when suspended", " - drm/vc4: hvs: Fix dlist debug not resetting the next entry pointer", " - drm/vc4: hvs: Remove incorrect limit from hvs_dlist debugfs function", " - drm/vc4: hvs: Correct logic on stopping an HVS channel", " - wifi: ath9k: add range check for conn_rsp_epid in htc_connect_service()", " - drm/omap: Fix possible NULL dereference", " - drm/omap: Fix locking in omap_gem_new_dmabuf()", " - drm/v3d: Appease lockdep while updating GPU stats", " - wifi: p54: Use IRQF_NO_AUTOEN flag in request_irq()", " - wifi: mwifiex: Use IRQF_NO_AUTOEN flag in request_irq()", " - udmabuf: change folios array from kmalloc to kvmalloc", " - udmabuf: fix vmap_udmabuf error page set", " - [Config] updateconfigs for VMAP_PFN", " - drm/imx/dcss: Use IRQF_NO_AUTOEN flag in request_irq()", " - drm/imx/ipuv3: Use IRQF_NO_AUTOEN flag in request_irq()", " - drm/panel: nt35510: Make new commands optional", " - drm/v3d: Address race-condition in MMU flush", " - drm/v3d: Flush the MMU before we supply more memory to the binner", " - drm/amdgpu: Fix JPEG v4.0.3 register write", " - wifi: ath10k: fix invalid VHT parameters in supported_vht_mcs_rate_nss1", " - wifi: ath10k: fix invalid VHT parameters in supported_vht_mcs_rate_nss2", " - wifi: ath12k: Skip Rx TID cleanup for self peer", " - dt-bindings: vendor-prefixes: Add NeoFidelity, Inc", " - ASoC: fsl_micfil: fix regmap_write_bits usage", " - ASoC: dt-bindings: mt6359: Update generic node name and dmic-mode", " - ASoC: fsl-asoc-card: Add missing handling of {hp,mic}-dt-gpios", " - drm/bridge: anx7625: Drop EDID cache on bridge power off", " - drm/bridge: it6505: Drop EDID cache on bridge power off", " - libbpf: Fix expected_attach_type set handling in program load callback", " - libbpf: Fix output .symtab byte-order during linking", " - dlm: fix swapped args sb_flags vs sb_status", " - wifi: rtl8xxxu: Perform update_beacon_work when beaconing is enabled", " - drm/amd/display: fix a memleak issue when driver is removed", " - wifi: ath12k: fix use-after-free in ath12k_dp_cc_cleanup()", " - wifi: ath12k: fix one more memcpy size error", " - bpf: Fix the xdp_adjust_tail sample prog issue", " - selftests/bpf: netns_new() and netns_free() helpers.", " - selftests/bpf: Fix backtrace printing for selftests crashes", " - wifi: ath11k: Fix CE offset address calculation for WCN6750 in SSR", " - selftests/bpf: add missing header include for htons", " - wifi: cfg80211: check radio iface combination for multi radio per wiphy", " - ice: consistently use q_idx in ice_vc_cfg_qs_msg()", " - drm/vc4: hdmi: Increase audio MAI fifo dreq threshold", " - drm/vc4: Introduce generation number enum", " - drm/vc4: Match drm_dev_enter and exit calls in vc4_hvs_lut_load", " - drm/vc4: Match drm_dev_enter and exit calls in vc4_hvs_atomic_flush", " - drm/vc4: Correct generation check in vc4_hvs_lut_load", " - libbpf: fix sym_is_subprog() logic for weak global subprogs", " - accel/ivpu: Prevent recovery invocation during probe and resume", " - ASoC: rt722-sdca: Remove logically deadcode in rt722-sdca.c", " - libbpf: never interpret subprogs in .text as entry programs", " - netdevsim: copy addresses for both in and out paths", " - drm/bridge: tc358767: Fix link properties discovery", " - selftests/bpf: Fix msg_verify_data in test_sockmap", " - selftests/bpf: Fix txmsg_redir of test_txmsg_pull in test_sockmap", " - wifi: wilc1000: Set MAC after operation mode", " - wifi: mwifiex: Fix memcpy() field-spanning write warning in", " mwifiex_config_scan()", " - drm: fsl-dcu: enable PIXCLK on LS1021A", " - drm: panel: nv3052c: correct spi_device_id for RG35XX panel", " - drm/msm/dpu: on SDM845 move DSPP_3 to LM_5 block", " - drm/msm/dpu: drop LM_3 / LM_4 on SDM845", " - drm/msm/dpu: drop LM_3 / LM_4 on MSM8998", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_common.c", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_ethtool.c", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_flows.c", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in cn10k.c", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dmac_flt.c", " - octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_dcbnl.c", " - selftests/bpf: fix test_spin_lock_fail.c's global vars usage", " - libbpf: move global data mmap()'ing into bpf_object__load()", " - drm/panfrost: Remove unused id_mask from struct panfrost_model", " - bpf, arm64: Remove garbage frame for struct_ops trampoline", " - drm/msm/adreno: Use IRQF_NO_AUTOEN flag in request_irq()", " - drm/msm/gpu: Check the status of registration to PM QoS", " - drm/xe/hdcp: Fix gsc structure check in fw check status", " - drm/etnaviv: Request pages from DMA32 zone on addressing_limited", " - drm/etnaviv: hold GPU lock across perfmon sampling", " - drm/amd/display: Increase idle worker HPD detection time", " - drm/amd/display: Reduce HPD Detection Interval for IPS", " - drm/nouveau/gr/gf100: Fix missing unlock in gf100_gr_chan_new()", " - drm: zynqmp_kms: Unplug DRM device before removal", " - drm: xlnx: zynqmp_disp: layer may be null while releasing", " - wifi: wfx: Fix error handling in wfx_core_init()", " - wifi: cw1200: Fix potential NULL dereference", " - drm/msm/dpu: cast crtc_clk calculation to u64 in _dpu_core_perf_calc_clk()", " - bpf, bpftool: Fix incorrect disasm pc", " - bpf: Tighten tail call checks for lingering locks, RCU, preempt_disable", " - drm/vkms: Drop unnecessary call to drm_crtc_cleanup()", " - drm/amdgpu: Fix the memory allocation issue in", " amdgpu_discovery_get_nps_info()", " - bpf: Support __nullable argument suffix for tp_btf", " - selftests/bpf: Add test for __nullable suffix in tp_btf", " - bpf: Mark raw_tp arguments with PTR_MAYBE_NULL", " - drm: use ATOMIC64_INIT() for atomic64_t", " - netfilter: nf_tables: avoid false-positive lockdep splat on rule deletion", " - netfilter: nf_tables: must hold rcu read lock while iterating expression", " type list", " - netfilter: nf_tables: must hold rcu read lock while iterating object type", " list", " - netlink: typographical error in nlmsg_type constants definition", " - wifi: rtw89: coex: check NULL return of kmalloc in btc_fw_set_monreg()", " - drm/panfrost: Add missing OPP table refcnt decremental", " - drm/panthor: introduce job cycle and timestamp accounting", " - drm/panthor: record current and maximum device clock frequencies", " - drm/panthor: Fix OPP refcnt leaks in devfreq initialisation", " - isofs: avoid memory leak in iocharset", " - selftests/bpf: Add txmsg_pass to pull/push/pop in test_sockmap", " - selftests/bpf: Fix SENDPAGE data logic in test_sockmap", " - selftests/bpf: Fix total_bytes in msg_loop_rx in test_sockmap", " - selftests/bpf: Add push/pop checking for msg_verify_data in test_sockmap", " - bpf, sockmap: Several fixes to bpf_msg_push_data", " - bpf, sockmap: Several fixes to bpf_msg_pop_data", " - bpf, sockmap: Fix sk_msg_reset_curr", " - ipv6: release nexthop on device removal", " - selftests: net: really check for bg process completion", " - wifi: cfg80211: Remove the Medium Synchronization Delay validity check", " - wifi: iwlwifi: allow fast resume on ax200", " - wifi: iwlwifi: mvm: tell iwlmei when we finished suspending", " - drm/amdgpu: fix ACA bank count boundary check error", " - drm/amdgpu: Fix map/unmap queue logic", " - drm/amdkfd: Fix wrong usage of INIT_WORK()", " - bpf: Allow return values 0 and 1 for kprobe session", " - bpf: Force uprobe bpf program to always return 0", " - selftests/bpf: skip the timer_lockup test for single-CPU nodes", " - ipv6: Fix soft lockups in fib6_select_path under high next hop churn", " - net: rfkill: gpio: Add check for clk_enable()", " - Revert \"wifi: iwlegacy: do not skip frames with bad FCS\"", " - bpf: Use function pointers count as struct_ops links count", " - bpf: Add kernel symbol for struct_ops trampoline", " - ALSA: usx2y: Use snd_card_free_when_closed() at disconnection", " - ALSA: us122l: Use snd_card_free_when_closed() at disconnection", " - ALSA: caiaq: Use snd_card_free_when_closed() at disconnection", " - ALSA: 6fire: Release resources at card release", " - i2c: dev: Fix memory leak when underlying adapter does not support I2C", " - selftests: netfilter: Fix missing return values in conntrack_dump_flush", " - Bluetooth: btintel_pcie: Add handshake between driver and firmware", " - Bluetooth: btintel: Do no pass vendor events to stack", " - Bluetooth: btmtk: adjust the position to init iso data anchor", " - Bluetooth: btbcm: fix missing of_node_put() in btbcm_get_board_name()", " - Bluetooth: ISO: Use kref to track lifetime of iso_conn", " - Bluetooth: ISO: Do not emit LE PA Create Sync if previous is pending", " - Bluetooth: ISO: Do not emit LE BIG Create Sync if previous is pending", " - Bluetooth: ISO: Send BIG Create Sync via hci_sync", " - Bluetooth: fix use-after-free in device_for_each_child()", " - xsk: Free skb when TX metadata options are invalid", " - erofs: handle NONHEAD !delta[1] lclusters gracefully", " - dlm: fix dlm_recover_members refcount on error", " - eth: fbnic: don't disable the PCI device twice", " - net: txgbe: remove GPIO interrupt controller", " - net: txgbe: fix null pointer to pcs", " - netpoll: Use rcu_access_pointer() in netpoll_poll_lock", " - wireguard: selftests: load nf_conntrack if not present", " - bpf: fix recursive lock when verdict program return SK_PASS", " - unicode: Fix utf8_load() error path", " - cppc_cpufreq: Use desired perf if feedback ctrs are 0 or unchanged", " - RDMA/core: Provide rdma_user_mmap_disassociate() to disassociate mmap pages", " - RDMA/hns: Disassociate mmap pages for all uctx when HW is being reset", " - clk: mediatek: drop two dead config options", " - [Config] drop COMMON_CLK_MT8195_{AUDSYS,MSDC}", " - trace/trace_event_perf: remove duplicate samples on the first tracepoint", " event", " - pinctrl: zynqmp: drop excess struct member description", " - pinctrl: renesas: Select PINCTRL_RZG2L for RZ/V2H(P) SoC", " - clk: qcom: videocc-sm8550: depend on either gcc-sm8550 or gcc-sm8650", " - iommu/s390: Implement blocking domain", " - scsi: hisi_sas: Enable all PHYs that are not disabled by user during", " controller reset", " - powerpc/vdso: Flag VDSO64 entry points as functions", " - mfd: tps65010: Use IRQF_NO_AUTOEN flag in request_irq() to fix race", " - mfd: da9052-spi: Change read-mask to write-mask", " - mfd: intel_soc_pmic_bxtwc: Use IRQ domain for USB Type-C device", " - mfd: intel_soc_pmic_bxtwc: Use IRQ domain for TMU device", " - mfd: intel_soc_pmic_bxtwc: Use IRQ domain for PMIC devices", " - irqdomain: Simplify simple and legacy domain creation", " - irqdomain: Cleanup domain name allocation", " - irqdomain: Allow giving name suffix for domain", " - regmap: Allow setting IRQ domain name suffix", " - mfd: intel_soc_pmic_bxtwc: Fix IRQ domain names duplication", " - cpufreq: loongson2: Unregister platform_driver on failure", " - powerpc/fadump: Refactor and prepare fadump_cma_init for late init", " - powerpc/fadump: Move fadump_cma_init to setup_arch() after initmem_init()", " - mtd: hyperbus: rpc-if: Add missing MODULE_DEVICE_TABLE", " - mtd: rawnand: atmel: Fix possible memory leak", " - powerpc/mm/fault: Fix kfence page fault reporting", " - clk: sophgo: avoid integer overflow in sg2042_pll_recalc_rate()", " - mtd: spi-nor: spansion: Use nor->addr_nbytes in octal DTR mode in", " RD_ANY_REG_OP", " - powerpc/pseries: Fix dtl_access_lock to be a rw_semaphore", " - cpufreq: CPPC: Fix possible null-ptr-deref for cpufreq_cpu_get_raw()", " - cpufreq: CPPC: Fix possible null-ptr-deref for cppc_get_cpu_cost()", " - iommu/amd: Remove amd_iommu_domain_update() from page table freeing", " - iommu/amd: Remove the amd_iommu_domain_set_pt_root() and related", " - iommu/amd: Rename struct amd_io_pgtable iopt to pgtbl", " - iommu/amd: Store the nid in io_pgtable_cfg instead of the domain", " - iommu/amd: Narrow the use of struct protection_domain to invalidation", " - iommu/amd/pgtbl_v2: Take protection domain lock before invalidating TLB", " - RDMA/hns: Fix an AEQE overflow error caused by untimely update of eq_db_ci", " - RDMA/hns: Fix flush cqe error when racing with destroy qp", " - RDMA/hns: Modify debugfs name", " - RDMA/hns: Use dev_* printings in hem code instead of ibdev_*", " - RDMA/hns: Fix cpu stuck caused by printings during reset", " - RDMA/rxe: Fix the qp flush warnings in req", " - RDMA/bnxt_re: Check cqe flags to know imm_data vs inv_irkey", " - clk: sunxi-ng: d1: Fix PLL_AUDIO0 preset", " - clk: renesas: rzg2l: Fix FOUTPOSTDIV clk", " - RDMA/rxe: Set queue pair cur_qp_state when being queried", " - RISC-V: KVM: Fix APLIC in_clrip and clripnum write emulation", " - riscv: kvm: Fix out-of-bounds array access", " - clk: imx: lpcg-scu: SW workaround for errata (e10858)", " - clk: imx: fracn-gppll: correct PLL initialization flow", " - clk: imx: fracn-gppll: fix pll power up", " - clk: imx: clk-scu: fix clk enable state save and restore", " - clk: imx: imx8-acm: Fix return value check in", " clk_imx_acm_attach_pm_domains()", " - iommu/vt-d: Fix checks and print in dmar_fault_dump_ptes()", " - iommu/vt-d: Fix checks and print in pgtable_walk()", " - checkpatch: always parse orig_commit in fixes tag", " - mfd: rt5033: Fix missing regmap_del_irq_chip()", " - leds: max5970: Fix unreleased fwnode_handle in probe function", " - leds: ktd2692: Set missing timing properties", " - fs/proc/kcore.c: fix coccinelle reported ERROR instances", " - scsi: target: Fix incorrect function name in pscsi_create_type_disk()", " - scsi: bfa: Fix use-after-free in bfad_im_module_exit()", " - scsi: fusion: Remove unused variable 'rc'", " - scsi: qedf: Fix a possible memory leak in qedf_alloc_and_init_sb()", " - scsi: qedi: Fix a possible memory leak in qedi_alloc_and_init_sb()", " - scsi: sg: Enable runtime power management", " - x86/tdx: Introduce wrappers to read and write TD metadata", " - x86/tdx: Rename tdx_parse_tdinfo() to tdx_setup()", " - x86/tdx: Dynamically disable SEPT violations from causing #VEs", " - powerpc/fadump: allocate memory for additional parameters early", " - fadump: reserve param area if below boot_mem_top", " - RDMA/hns: Fix out-of-order issue of requester when setting FENCE", " - RDMA/hns: Fix NULL pointer derefernce in hns_roce_map_mr_sg()", " - cpufreq: loongson3: Check for error code from devm_mutex_init() call", " - cpufreq: CPPC: Fix wrong return value in cppc_get_cpu_cost()", " - cpufreq: CPPC: Fix wrong return value in cppc_get_cpu_power()", " - kasan: move checks to do_strncpy_from_user", " - kunit: skb: use \"gfp\" variable instead of hardcoding GFP_KERNEL", " - ocfs2: fix uninitialized value in ocfs2_file_read_iter()", " - dax: delete a stale directory pmem", " - KVM: PPC: Book3S HV: Stop using vc->dpdes for nested KVM guests", " - KVM: PPC: Book3S HV: Avoid returning to nested hypervisor on pending", " doorbells", " - powerpc/sstep: make emulate_vsx_load and emulate_vsx_store static", " - RDMA/hns: Fix different dgids mapping to the same dip_idx", " - KVM: PPC: Book3S HV: Fix kmv -> kvm typo", " - powerpc/kexec: Fix return of uninitialized variable", " - fbdev: sh7760fb: Fix a possible memory leak in sh7760fb_alloc_mem()", " - RDMA/mlx5: Move events notifier registration to be after device registration", " - clk: clk-apple-nco: Add NULL check in applnco_probe", " - clk: ralink: mtmips: fix clock plan for Ralink SoC RT3883", " - clk: ralink: mtmips: fix clocks probe order in oldest ralink SoCs", " - clk: en7523: remove REG_PCIE*_{MEM,MEM_MASK} configuration", " - clk: en7523: move clock_register in hw_init callback", " - clk: en7523: introduce chip_scu regmap", " - clk: en7523: fix estimation of fixed rate for EN7581", " - dt-bindings: clock: axi-clkgen: include AXI clk", " - clk: clk-axi-clkgen: make sure to enable the AXI bus clock", " - arm64: dts: qcom: sc8180x: Add a SoC-specific compatible to cpufreq-hw", " - pinctrl: k210: Undef K210_PC_DEFAULT", " - rtla/timerlat: Do not set params->user_workload with -U", " - smb: cached directories can be more than root file handle", " - mailbox: mtk-cmdq: fix wrong use of sizeof in cmdq_get_clocks()", " - mailbox: arm_mhuv2: clean up loop in get_irq_chan_comb()", " - x86: fix off-by-one in access_ok()", " - perf cs-etm: Don't flush when packet_queue fills up", " - gfs2: Rename GLF_VERIFY_EVICT to GLF_VERIFY_DELETE", " - gfs2: Allow immediate GLF_VERIFY_DELETE work", " - gfs2: Fix unlinked inode cleanup", " - perf test: Add test for Intel TPEBS counting mode", " - perf mem: Fix printing PERF_MEM_LVLNUM_{L2_MHB|MSC}", " - PCI: Fix reset_method_store() memory leak", " - perf stat: Close cork_fd when create_perf_stat_counter() failed", " - perf stat: Fix affinity memory leaks on error path", " - perf trace: Keep exited threads for summary", " - perf test attr: Add back missing topdown events", " - f2fs: compress: fix inconsistent update of i_blocks in", " release_compress_blocks and reserve_compress_blocks", " - f2fs: fix null-ptr-deref in f2fs_submit_page_bio()", " - f2fs: fix to account dirty data in __get_secs_required()", " - perf dso: Fix symtab_type for kmod compression", " - perf probe: Fix libdw memory leak", " - perf probe: Correct demangled symbols in C++ program", " - rust: kernel: fix THIS_MODULE header path in ThisModule doc comment", " - rust: macros: fix documentation of the paste! macro", " - PCI: cpqphp: Use PCI_POSSIBLE_ERROR() to check config reads", " - PCI: cpqphp: Fix PCIBIOS_* return value confusion", " - rust: block: fix formatting of `kernel::block::mq::request` module", " - perf disasm: Use disasm_line__free() to properly free disasm_line", " - virtiofs: use pages instead of pointer for kernel direct IO", " - perf ftrace latency: Fix unit on histogram first entry when using --use-nsec", " - i3c: master: Remove i3c_dev_disable_ibi_locked(olddev) on device hotjoin", " - f2fs: fix the wrong f2fs_bug_on condition in f2fs_do_replace_block", " - f2fs: check curseg->inited before write_sum_page in change_curseg", " - f2fs: Fix not used variable 'index'", " - f2fs: fix to avoid potential deadlock in f2fs_record_stop_reason()", " - f2fs: fix to avoid use GC_AT when setting gc_mode as GC_URGENT_LOW or", " GC_URGENT_MID", " - PCI: qcom-ep: Move controller cleanups to qcom_pcie_perst_deassert()", " - PCI: tegra194: Move controller cleanups to pex_ep_event_pex_rst_deassert()", " - PCI: cadence: Extract link setup sequence from cdns_pcie_host_setup()", " - PCI: cadence: Set cdns_pcie_host_init() global", " - PCI: j721e: Add reset GPIO to struct j721e_pcie", " - PCI: j721e: Use T_PERST_CLK_US macro", " - PCI: j721e: Add suspend and resume support", " - PCI: j721e: Deassert PERST# after a delay of PCIE_T_PVPERL_MS milliseconds", " - perf build: Add missing cflags when building with custom libtraceevent", " - f2fs: fix race in concurrent f2fs_stop_gc_thread", " - f2fs: fix to map blocks correctly for direct write", " - f2fs: fix to avoid forcing direct write to use buffered IO on inline_data", " inode", " - perf trace: avoid garbage when not printing a trace event's arguments", " - m68k: mcfgpio: Fix incorrect register offset for CONFIG_M5441x", " - m68k: coldfire/device.c: only build FEC when HW macros are defined", " - svcrdma: Address an integer overflow", " - nfsd: drop inode parameter from nfsd4_change_attribute()", " - perf list: Fix topic and pmu_name argument order", " - perf trace: Fix tracing itself, creating feedback loops", " - perf trace: Do not lose last events in a race", " - perf trace: Avoid garbage when not printing a syscall's arguments", " - remoteproc: qcom: pas: Remove subdevs on the error path of adsp_probe()", " - remoteproc: qcom: adsp: Remove subdevs on the error path of adsp_probe()", " - remoteproc: qcom: pas: add minidump_id to SM8350 resources", " - rpmsg: glink: use only lower 16-bits of param2 for CMD_OPEN name length", " - remoteproc: qcom_q6v5_mss: Re-order writes to the IMEM region", " - PCI: endpoint: epf-mhi: Avoid NULL dereference if DT lacks 'mmio'", " - NFSD: Prevent NULL dereference in nfsd4_process_cb_update()", " - NFSD: Cap the number of bytes copied by nfs4_reset_recoverydir()", " - nfsd: release svc_expkey/svc_export with rcu_work", " - svcrdma: fix miss destroy percpu_counter in svc_rdma_proc_init()", " - NFSD: Fix nfsd4_shutdown_copy()", " - f2fs: clean up val{>>,<<}F2FS_BLKSIZE_BITS", " - f2fs: fix to do cast in F2FS_{BLK_TO_BYTES, BTYES_TO_BLK} to avoid overflow", " - hwmon: (tps23861) Fix reporting of negative temperatures", " - hwmon: (aquacomputer_d5next) Fix length of speed_input array", " - phy: airoha: Fix REG_CSR_2L_PLL_CMN_RESERVE0 config in", " airoha_pcie_phy_init_clk_out()", " - phy: airoha: Fix REG_PCIE_PMA_TX_RESET config in", " airoha_pcie_phy_init_csr_2l()", " - phy: airoha: Fix REG_CSR_2L_JCPLL_SDM_HREN config in", " airoha_pcie_phy_init_ssc_jcpll()", " - phy: airoha: Fix REG_CSR_2L_RX{0,1}_REV0 definitions", " - vdpa/mlx5: Fix suboptimal range on iotlb iteration", " - vfio/mlx5: Fix an unwind issue in mlx5vf_add_migration_pages()", " - vfio/mlx5: Fix unwind flows in mlx5vf_pci_save/resume_device_data()", " - selftests/mount_setattr: Fix failures on 64K PAGE_SIZE kernels", " - gpio: zevio: Add missed label initialisation", " - vfio/pci: Properly hide first-in-list PCIe extended capability", " - fs_parser: update mount_api doc to match function signature", " - LoongArch: Fix build failure with GCC 15 (-std=gnu23)", " - LoongArch: BPF: Sign-extend return values", " - power: supply: core: Remove might_sleep() from power_supply_put()", " - power: supply: bq27xxx: Fix registers of bq27426", " - power: supply: rt9471: Fix wrong WDT function regfield declaration", " - power: supply: rt9471: Use IC status regfield to report real charger status", " - net: usb: lan78xx: Fix double free issue with interrupt buffer allocation", " - net: usb: lan78xx: Fix memory leak on device unplug by freeing PHY device", " - tg3: Set coherent DMA mask bits to 31 for BCM57766 chipsets", " - net: usb: lan78xx: Fix refcounting and autosuspend on invalid WoL", " configuration", " - net: microchip: vcap: Add typegroup table terminators in kunit tests", " - netlink: fix false positive warning in extack during dumps", " - exfat: fix file being changed by unaligned direct write", " - s390/iucv: MSG_PEEK causes memory leak in iucv_sock_destruct()", " - net/ipv6: delete temporary address if mngtmpaddr is removed or unmanaged", " - net: mdio-ipq4019: add missing error check", " - marvell: pxa168_eth: fix call balance of pep->clk handling routines", " - net: stmmac: dwmac-socfpga: Set RX watchdog interrupt as broken", " - octeontx2-af: RPM: Fix mismatch in lmac type", " - octeontx2-af: RPM: Fix low network performance", " - octeontx2-af: RPM: fix stale RSFEC counters", " - octeontx2-af: RPM: fix stale FCFEC counters", " - octeontx2-af: Quiesce traffic before NIX block reset", " - spi: atmel-quadspi: Fix register name in verbose logging function", " - net: hsr: fix hsr_init_sk() vs network/transport headers.", " - bnxt_en: Reserve rings after PCIe AER recovery if NIC interface is down", " - bnxt_en: Set backplane link modes correctly for ethtool", " - bnxt_en: Fix receive ring space parameters when XDP is active", " - bnxt_en: Refactor bnxt_ptp_init()", " - bnxt_en: Unregister PTP during PCI shutdown and suspend", " - Bluetooth: MGMT: Fix slab-use-after-free Read in set_powered_sync", " - Bluetooth: MGMT: Fix possible deadlocks", " - llc: Improve setsockopt() handling of malformed user input", " - rxrpc: Improve setsockopt() handling of malformed user input", " - tcp: Fix use-after-free of nreq in reqsk_timer_handler().", " - ip6mr: fix tables suspicious RCU usage", " - ipmr: fix tables suspicious RCU usage", " - iio: light: al3010: Fix an error handling path in al3010_probe()", " - usb: using mutex lock and supporting O_NONBLOCK flag in iowarrior_read()", " - usb: yurex: make waiting on yurex_write interruptible", " - USB: chaoskey: fail open after removal", " - USB: chaoskey: Fix possible deadlock chaoskey_list_lock", " - misc: apds990x: Fix missing pm_runtime_disable()", " - devres: Fix page faults when tracing devres from unloaded modules", " - usb: gadget: uvc: wake pump everytime we update the free list", " - interconnect: qcom: icc-rpmh: probe defer incase of missing QoS clock", " dependency", " - phy: realtek: usb: fix NULL deref in rtk_usb2phy_probe", " - phy: realtek: usb: fix NULL deref in rtk_usb3phy_probe", " - counter: stm32-timer-cnt: Add check for clk_enable()", " - counter: ti-ecap-capture: Add check for clk_enable()", " - bus: mhi: host: Switch trace_mhi_gen_tre fields to native endian", " - usb: typec: fix potential array underflow in ucsi_ccg_sync_control()", " - firmware_loader: Fix possible resource leak in fw_log_firmware_info()", " - ALSA: hda/realtek: Update ALC256 depop procedure", " - drm/radeon: add helper rdev_to_drm(rdev)", " - drm/radeon: change rdev->ddev to rdev_to_drm(rdev)", " - drm/radeon: Fix spurious unplug event on radeon HDMI", " - drm/amd/display: Fix null check for pipe_ctx->plane_state in", " dcn20_program_pipe", " - drm/amd/display: Fix null check for pipe_ctx->plane_state in hwss_setup_dpp", " - ASoC: imx-audmix: Add NULL check in imx_audmix_probe", " - drm/xe/ufence: Wake up waiters after setting ufence->signalled", " - apparmor: fix 'Do simple duplicate message elimination'", " - ALSA: core: Fix possible NULL dereference caused by kunit_kzalloc()", " - ASoC: amd: yc: Fix for enabling DMIC on acp6x via _DSD entry", " - ASoC: mediatek: Check num_codecs is not zero to avoid panic during probe", " - s390/pci: Fix potential double remove of hotplug slot", " - net_sched: sch_fq: don't follow the fast path if Tx is behind now", " - xen: Fix the issue of resource not being properly released in", " xenbus_dev_probe()", " - ALSA: usb-audio: Fix potential out-of-bound accesses for Extigy and Mbox", " devices", " - ALSA: usb-audio: Fix out of bounds reads when finding clock sources", " - usb: ehci-spear: fix call balance of sehci clk handling routines", " - usb: typec: ucsi: glink: fix off-by-one in connector_status", " - dm-cache: fix warnings about duplicate slab caches", " - dm-bufio: fix warnings about duplicate slab caches", " - ASoC: Intel: sst: Fix used of uninitialized ctx to log an error", " - soc: qcom: socinfo: fix revision check in qcom_socinfo_probe()", " - irqdomain: Always associate interrupts for legacy domains", " - ext4: supress data-race warnings in ext4_free_inodes_{count,set}()", " - ext4: fix FS_IOC_GETFSMAP handling", " - jfs: xattr: check invalid xattr size more strictly", " - ASoC: amd: yc: Add a quirk for microfone on Lenovo ThinkPad P14s Gen 5", " 21MES00B00", " - ASoC: codecs: Fix atomicity violation in snd_soc_component_get_drvdata()", " - ASoC: da7213: Populate max_register to regmap_config", " - perf/x86/intel/pt: Fix buffer full but size is 0 case", " - crypto: x86/aegis128 - access 32-bit arguments as 32-bit", " - KVM: x86: switch hugepage recovery thread to vhost_task", " - KVM: x86/mmu: Skip the \"try unsync\" path iff the old SPTE was a leaf SPTE", " - powerpc/pseries: Fix KVM guest detection for disabling hardlockup detector", " - KVM: arm64: vgic-v3: Sanitise guest writes to GICR_INVLPIR", " - KVM: arm64: Ignore PMCNTENSET_EL0 while checking for overflow status", " - KVM: arm64: Don't retire aborted MMIO instruction", " - KVM: arm64: vgic-its: Clear ITE when DISCARD frees an ITE", " - KVM: arm64: Get rid of userspace_irqchip_in_use", " - KVM: arm64: vgic-its: Add a data length check in vgic_its_save_*", " - KVM: arm64: vgic-its: Clear DTE when MAPD unmaps a device", " - Compiler Attributes: disable __counted_by for clang < 19.1.3", " - PCI: Fix use-after-free of slot->bus on hot remove", " - LoongArch: Explicitly specify code model in Makefile", " - clk: clk-loongson2: Fix memory corruption bug in struct", " loongson2_clk_provider", " - clk: clk-loongson2: Fix potential buffer overflow in flexible-array member", " access", " - fsnotify: fix sending inotify event with unexpected filename", " - comedi: Flush partial mappings in error case", " - apparmor: test: Fix memory leak for aa_unpack_strdup()", " - iio: dac: adi-axi-dac: fix wrong register bitfield", " - tty: ldsic: fix tty_ldisc_autoload sysctl's proc_handler", " - locking/lockdep: Avoid creating new name string literals in", " lockdep_set_subclass()", " - tools/nolibc: s390: include std.h", " - pinctrl: qcom: spmi: fix debugfs drive strength", " - dt-bindings: pinctrl: samsung: Fix interrupt constraint for variants with", " fallbacks", " - dt-bindings: iio: dac: ad3552r: fix maximum spi speed", " - exfat: fix uninit-value in __exfat_get_dentry_set", " - exfat: fix out-of-bounds access of directory entries", " - xhci: Fix control transfer error on Etron xHCI host", " - xhci: Combine two if statements for Etron xHCI host", " - xhci: Don't perform Soft Retry for Etron xHCI host", " - xhci: Don't issue Reset Device command to Etron xHCI host", " - Bluetooth: Fix type of len in rfcomm_sock_getsockopt{,_old}()", " - usb: xhci: Limit Stop Endpoint retries", " - usb: xhci: Fix TD invalidation under pending Set TR Dequeue", " - usb: xhci: Avoid queuing redundant Stop Endpoint commands", " - ARM: dts: omap36xx: declare 1GHz OPP as turbo again", " - wifi: ath12k: fix warning when unbinding", " - wifi: rtlwifi: Drastically reduce the attempts to read efuse in case of", " failures", " - wifi: nl80211: fix bounds checker error in nl80211_parse_sched_scan", " - wifi: ath12k: fix crash when unbinding", " - wifi: brcmfmac: release 'root' node in all execution paths", " - Revert \"fs: don't block i_writecount during exec\"", " - Revert \"f2fs: remove unreachable lazytime mount option parsing\"", " - Revert \"usb: gadget: composite: fix OS descriptors w_value logic\"", " - serial: sh-sci: Clean sci_ports[0] after at earlycon exit", " - Revert \"serial: sh-sci: Clean sci_ports[0] after at earlycon exit\"", " - io_uring: fix corner case forgetting to vunmap", " - io_uring: check for overflows in io_pin_pages", " - blk-settings: round down io_opt to physical_block_size", " - gpio: exar: set value when external pull-up or pull-down is present", " - spi: Fix acpi deferred irq probe", " - mtd: spi-nor: core: replace dummy buswidth from addr to data", " - cpufreq: mediatek-hw: Fix wrong return value in mtk_cpufreq_get_cpu_power()", " - cifs: support mounting with alternate password to allow password rotation", " - parisc/ftrace: Fix function graph tracing disablement", " - RISC-V: Scalar unaligned access emulated on hotplug CPUs", " - RISC-V: Check scalar unaligned access on all CPUs", " - ksmbd: fix use-after-free in SMB request handling", " - smb: client: fix NULL ptr deref in crypto_aead_setkey()", " - platform/chrome: cros_ec_typec: fix missing fwnode reference decrement", " - irqchip/irq-mvebu-sei: Move misplaced select() callback to SEI CP domain", " - x86/CPU/AMD: Terminate the erratum_1386_microcode array", " - ubi: wl: Put source PEB into correct list if trying locking LEB failed", " - um: ubd: Do not use drvdata in release", " - um: net: Do not use drvdata in release", " - dt-bindings: serial: rs485: Fix rs485-rts-delay property", " - serial: 8250_fintek: Add support for F81216E", " - serial: 8250: omap: Move pm_runtime_get_sync", " - serial: amba-pl011: Fix RX stall when DMA is used", " - serial: amba-pl011: fix build regression", " - mtd: ubi: fix unreleased fwnode_handle in find_volume_fwnode()", " - block: Prevent potential deadlock in blk_revalidate_disk_zones()", " - um: vector: Do not use drvdata in release", " - sh: cpuinfo: Fix a warning for CONFIG_CPUMASK_OFFSTACK", " - iio: gts: Fix uninitialized symbol 'ret'", " - ublk: fix ublk_ch_mmap() for 64K page size", " - arm64: tls: Fix context-switching of tpidrro_el0 when kpti is enabled", " - block: fix missing dispatching request when queue is started or unquiesced", " - block: fix ordering between checking QUEUE_FLAG_QUIESCED request adding", " - block: fix ordering between checking BLK_MQ_S_STOPPED request adding", " - blk-mq: Make blk_mq_quiesce_tagset() hold the tag list mutex less long", " - gve: Flow steering trigger reset only for timeout error", " - HID: wacom: Interpret tilt data from Intuos Pro BT as signed values", " - i40e: Fix handling changed priv flags", " - media: wl128x: Fix atomicity violation in fmc_send_cmd()", " - media: intel/ipu6: do not handle interrupts when device is disabled", " - arm64: dts: mediatek: mt8186-corsola-voltorb: Merge speaker codec nodes", " - netdev-genl: Hold rcu_read_lock in napi_get", " - soc: fsl: rcpm: fix missing of_node_put() in copy_ippdexpcr1_setting()", " - media: v4l2-core: v4l2-dv-timings: check cvt/gtf result", " - ALSA: rawmidi: Fix kvfree() call in spinlock", " - ALSA: ump: Fix evaluation of MIDI 1.0 FB info", " - ALSA: pcm: Add sanity NULL check for the default mmap fault handler", " - ALSA: hda/realtek: Update ALC225 depop procedure", " - ALSA: hda/realtek: Set PCBeep to default value for ALC274", " - ALSA: hda/realtek: Fix Internal Speaker and Mic boost of Infinix Y4 Max", " - ALSA: hda/realtek: Apply quirk for Medion E15433", " - smb3: request handle caching when caching directories", " - smb: client: handle max length for SMB symlinks", " - smb: Don't leak cfid when reconnect races with open_cached_dir", " - smb: prevent use-after-free due to open_cached_dir error paths", " - smb: During unmount, ensure all cached dir instances drop their dentry", " - usb: misc: ljca: set small runtime autosuspend delay", " - usb: misc: ljca: move usb_autopm_put_interface() after wait for response", " - usb: dwc3: ep0: Don't clear ep0 DWC3_EP_TRANSFER_STARTED", " - usb: musb: Fix hardware lockup on first Rx endpoint request", " - usb: dwc3: gadget: Fix checking for number of TRBs left", " - usb: dwc3: gadget: Fix looping of queued SG entries", " - staging: vchiq_arm: Fix missing refcount decrement in error path for fw_node", " - counter: stm32-timer-cnt: fix device_node handling in probe_encoder()", " - ublk: fix error code for unsupported command", " - lib: string_helpers: silence snprintf() output truncation warning", " - f2fs: fix to do sanity check on node blkaddr in truncate_node()", " - ipc: fix memleak if msg_init_ns failed in create_ipc_ns", " - Input: cs40l50 - fix wrong usage of INIT_WORK()", " - NFSD: Prevent a potential integer overflow", " - SUNRPC: make sure cache entry active before cache_show", " - um: Fix potential integer overflow during physmem setup", " - um: Fix the return value of elf_core_copy_task_fpregs", " - kfifo: don't include dma-mapping.h in kfifo.h", " - um: ubd: Initialize ubd's disk pointer in ubd_add", " - um: Always dump trace for specified task in show_stack", " - NFSv4.0: Fix a use-after-free problem in the asynchronous open()", " - rtc: st-lpc: Use IRQF_NO_AUTOEN flag in request_irq()", " - rtc: abx80x: Fix WDT bit position of the status register", " - rtc: check if __rtc_read_time was successful in rtc_timer_do_work()", " - ubi: fastmap: wl: Schedule fm_work if wear-leveling pool is empty", " - ubifs: Correct the total block count by deducting journal reservation", " - ubi: fastmap: Fix duplicate slab cache names while attaching", " - ubifs: authentication: Fix use-after-free in ubifs_tnc_end_commit", " - jffs2: fix use of uninitialized variable", " - rtc: rzn1: fix BCD to rtc_time conversion errors", " - Revert \"nfs: don't reuse partially completed requests in", " nfs_lock_and_join_requests\"", " - nvme-multipath: avoid hang on inaccessible namespaces", " - nvme/multipath: Fix RCU list traversal to use SRCU primitive", " - blk-mq: add non_owner variant of start_freeze/unfreeze queue APIs", " - block: model freeze & enter queue as lock for supporting lockdep", " - block: fix uaf for flush rq while iterating tags", " - block: return unsigned int from bdev_io_min", " - nvme-fabrics: fix kernel crash while shutting down controller", " - 9p/xen: fix init sequence", " - 9p/xen: fix release of IRQ", " - perf/arm-smmuv3: Fix lockdep assert in ->event_init()", " - perf/arm-cmn: Ensure port and device id bits are set properly", " - smb: client: disable directory caching when dir_cache_timeout is zero", " - x86/Documentation: Update algo in init_size description of boot protocol", " - cifs: Fix parsing native symlinks relative to the export", " - cifs: Fix parsing reparse point with native symlink in SMB1 non-UNICODE", " session", " - rtc: ab-eoz9: don't fail temperature reads on undervoltage notification", " - Rename .data.unlikely to .data..unlikely", " - Rename .data.once to .data..once to fix resetting WARN*_ONCE", " - kbuild: deb-pkg: Don't fail if modules.order is missing", " - smb: Initialize cfid->tcon before performing network ops", " - block: Don't allow an atomic write be truncated in blkdev_write_iter()", " - modpost: remove incorrect code in do_eisa_entry()", " - cifs: during remount, make sure passwords are in sync", " - cifs: unlock on error in smb3_reconfigure()", " - nfs: ignore SB_RDONLY when mounting nfs", " - sunrpc: clear XPRT_SOCK_UPD_TIMEOUT when reset transport", " - SUNRPC: timeout and cancel TLS handshake with -ETIMEDOUT", " - sunrpc: fix one UAF issue caused by sunrpc kernel tcp socket", " - nfs/blocklayout: Don't attempt unregister for invalid block device", " - nfs/blocklayout: Limit repeat device registration on failure", " - block, bfq: fix bfqq uaf in bfq_limit_depth()", " - brd: decrease the number of allocated pages which discarded", " - sh: intc: Fix use-after-free bug in register_intc_controller()", " - tools/power turbostat: Fix trailing '\\n' parsing", " - tools/power turbostat: Fix child's argument forwarding", " - block: always verify unfreeze lock on the owner task", " - block: don't verify IO lock for freeze/unfreeze in elevator_init_mq()", " - Linux 6.11.11", "", " * Oracular update: v6.11.11 upstream stable release (LP: #2091655) //", " CVE-2024-53141", " - netfilter: ipset: add missing range check in bitmap_ip_uadt", "", " * Oracular update: v6.11.11 upstream stable release (LP: #2091655) //", " CVE-2024-50010", " - Revert \"exec: don't WARN for racy path_noexec check\"", "", " * Oracular update: v6.11.11 upstream stable release (LP: #2091655) //", " CVE-2024-53143", " - fsnotify: Fix ordering of iput() and watched_objects decrement", "", " * Oracular update: v6.11.11 upstream stable release (LP: #2091655) //", " CVE-2024-53142", " - initramfs: avoid filename buffer overrun", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650)", " - net: vertexcom: mse102x: Fix tx_bytes calculation", " - net/mlx5: Fix msix vectors to respect platform limit", " - net/mlx5e: clear xdp features on non-uplink representors", " - net/mlx5e: Disable loopback self-test on multi-PF netdev", " - drm/i915/gsc: ARL-H and ARL-U need a newer GSC FW.", " - drivers: perf: Fix wrong put_cpu() placement", " - Bluetooth: hci_core: Fix calling mgmt_device_connected", " - Bluetooth: btintel: Direct exception event to bluetooth stack", " - net: sched: cls_u32: Fix u32's systematic failure to free IDR entries for", " hnodes.", " - net: phylink: ensure PHY momentary link-fails are handled", " - samples: pktgen: correct dev to DEV", " - net: stmmac: dwmac-mediatek: Fix inverted handling of mediatek,mac-wol", " - net: Make copy_safe_from_sockptr() match documentation", " - stmmac: dwmac-intel-plat: fix call balance of tx_clk handling routines", " - net: ti: icssg-prueth: Fix 1 PPS sync", " - bonding: add ns target multicast address to slave device", " - ARM: 9419/1: mm: Fix kernel memory mapping for xip kernels", " - tools/mm: fix compile error", " - drm/amd/display: Run idle optimizations at end of vblank handler", " - drm/amd/display: Change some variable name of psr", " - drm/amd/display: Fix Panel Replay not update screen correctly", " - x86/mm: Fix a kdump kernel failure on SME system when CONFIG_IMA_KEXEC=y", " - x86/stackprotector: Work around strict Clang TLS symbol requirements", " - crash, powerpc: default to CRASH_DUMP=n on PPC_BOOK3S_32", " - [Config] enable ARCH_DEFAULT_CRASH_DUMP", " - mm: revert \"mm: shmem: fix data-race in shmem_getattr()\"", " - vdpa/mlx5: Fix PA offset with unaligned starting iotlb map", " - evm: stop avoidably reading i_writecount in evm_file_release", " - KVM: selftests: Disable strict aliasing", " - KVM: nVMX: Treat vpid01 as current if L2 is active, but with VPID disabled", " - KVM: x86: Unconditionally set irr_pending when updating APICv state", " - tpm: Disable TPM on tpm2_create_primary() failure", " - ALSA: hda/realtek - Fixed Clevo platform headset Mic issue", " - ALSA: hda/realtek - update set GPIO3 to default for Thinkpad with ALC1318", " - mptcp: update local address flags when setting it", " - mptcp: hold pm lock when deleting entry", " - mptcp: pm: use _rcu variant under rcu_read_lock", " - ocfs2: fix UBSAN warning in ocfs2_verify_volume()", " - LoongArch: Fix early_numa_add_cpu() usage for FDT systems", " - LoongArch: Disable KASAN if PGDIR_SIZE is too large for cpu_vabits", " - LoongArch: Add WriteCombine shadow mapping in KASAN", " - LoongArch: Fix AP booting issue in VM mode", " - LoongArch: Make KASAN work with 5-level page-tables", " - selftests: hugetlb_dio: fixup check for initial conditions to skip in the", " start", " - btrfs: fix incorrect comparison for delayed refs", " - mailbox: qcom-cpucp: Mark the irq with IRQF_NO_SUSPEND flag", " - firmware: arm_scmi: Skip opp duplicates", " - firmware: arm_scmi: Report duplicate opps as firmware bugs", " - mmc: sunxi-mmc: Fix A100 compatible description", " - drm/bridge: tc358768: Fix DSI command tx", " - drm/xe: handle flat ccs during hibernation on igpu", " - pmdomain: arm: Use FLAG_DEV_NAME_FW to ensure unique names", " - pmdomain: core: Add GENPD_FLAG_DEV_NAME_FW flag", " - nouveau: fw: sync dma after setup is called.", " - nouveau: handle EBUSY and EAGAIN for GSP aux errors.", " - nouveau/dp: handle retries for AUX CH transfers with GSP.", " - drm/amd: Fix initialization mistake for NBIO 7.7.0", " - drm/amdgpu: fix check in gmc_v9_0_get_vm_pte()", " - drm/amdgpu: Fix video caps for H264 and HEVC encode maximum size", " - drm/amd/pm: print pp_dpm_mclk in ascending order on SMU v14.0.0", " - drm/amdgpu: enable GTT fallback handling for dGPUs only", " - drm/amdgpu/mes12: correct kiq unmap latency", " - drm/amd/display: Require minimum VBlank size for stutter optimization", " - drm/amd/display: Fix failure to read vram info due to static BP_RESULT", " - mm: refactor arch_calc_vm_flag_bits() and arm64 MTE handling", " - drm/xe: Restore system memory GGTT mappings", " - drm/xe: improve hibernation on igpu", " - lib/buildid: Fix build ID parsing logic", " - net: sched: u32: Add test case for systematic hnode IDR leaks", " - media: dvbdev: fix the logic when DVB_DYNAMIC_MINORS is not set", " - Linux 6.11.10", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53133", " - drm/amd/display: Handle dml allocation failure to avoid crash", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53108", " - drm/amd/display: Adjust VSDB parser for replay feature", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53134", " - pmdomain: imx93-blk-ctrl: correct remove path", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53132", " - drm/xe/oa: Fix \"Missing outer runtime PM protection\" warning", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53127", " - Revert \"mmc: dw_mmc: Fix IDMAC operation with pages bigger than 4K\"", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53130", " - nilfs2: fix null-ptr-deref in block_dirty_buffer tracepoint", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53105", " - mm: page_alloc: move mlocked flag clearance into free_pages_prepare()", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53109", " - nommu: pass NULL argument to vma_iter_prealloc()", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53131", " - nilfs2: fix null-ptr-deref in block_touch_buffer tracepoint", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53135", " - KVM: VMX: Bury Intel PT virtualization (guest/host mode) behind", " CONFIG_BROKEN", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53106", " - ima: fix buffer overrun in ima_eventdigest_init_common", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53110", " - vp_vdpa: fix id_table array not null terminated error", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53126", " - vdpa: solidrun: Fix UB bug with devres", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53111", " - mm/mremap: fix address wraparound in move_page_tables()", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53107", " - fs/proc/task_mmu: prevent integer overflow in pagemap_scan_get_args()", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53128", " - sched/task_stack: fix object_is_on_stack() for KASAN tagged pointers", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53112", " - ocfs2: uncache inode which has failed entering the group", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53113", " - mm: fix NULL pointer dereference in alloc_pages_bulk_noprof", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53114", " - x86/CPU/AMD: Clear virtualized VMLOAD/VMSAVE on Zen4 client", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53137", " - ARM: fix cacheflush with PAN", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53115", " - drm/vmwgfx: avoid null_ptr_deref in vmw_framebuffer_surface_create_handle", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53116", " - drm/panthor: Fix handling of partial GPU mapping of BOs", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53117", " - virtio/vsock: Improve MSG_ZEROCOPY error handling", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53118", " - vsock: Fix sk_error_queue memory leak", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53119", " - virtio/vsock: Fix accept_queue memory leak", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53120", " - net/mlx5e: CT: Fix null-ptr-deref in add rule err flow", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53138", " - net/mlx5e: kTLS, Fix incorrect page refcounting", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53121", " - net/mlx5: fs, lock FTE when checking if active", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53122", " - mptcp: cope racing subflow creation in mptcp_rcv_space_adjust", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53123", " - mptcp: error out earlier on disconnect", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53124", " - net: fix data-races around sk->sk_forward_alloc", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53129", " - drm/rockchip: vop: Fix a dereferenced before check warning", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53139", " - sctp: fix possible UAF in sctp_v6_available()", "", " * Oracular update: v6.11.10 upstream stable release (LP: #2091650) //", " CVE-2024-53140", " - netlink: terminate outstanding dump on socket close", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649)", " - nvme/host: Fix RCU list traversal to use SRCU primitive", " - 9p: v9fs_fid_find: also lookup by inode if not found dentry", " - 9p: Avoid creating multiple slab caches with the same name", " - selftests/bpf: Verify that sync_linked_regs preserves subreg_def", " - nvmet-passthru: clear EUID/NGUID/UUID while using loop target", " - irqchip/ocelot: Fix trigger register address", " - pinctrl: aw9523: add missing mutex_destroy", " - pinctrl: intel: platform: Add Panther Lake to the list of supported", " - block: Fix elevator_get_default() checking for NULL q->tag_set", " - HID: multitouch: Add support for B2402FVA track point", " - HID: multitouch: Add quirk for HONOR MagicBook Art 14 touchpad", " - iommu/arm-smmu: Clarify MMU-500 CPRE workaround", " - nvme: disable CC.CRIME (NVME_CC_CRIME)", " - bpf: use kvzmalloc to allocate BPF verifier environment", " - crypto: api - Fix liveliness check in crypto_alg_tested", " - crypto: marvell/cesa - Disable hash algorithms", " - s390/ap: Fix CCA crypto card behavior within protected execution environment", " - sound: Make CONFIG_SND depend on INDIRECT_IOMEM instead of UML", " - drm/vmwgfx: Limit display layout ioctl array size to", " VMWGFX_NUM_DISPLAY_UNITS", " - selftests/bpf: Assert link info uprobe_multi count & path_size if unset", " - ALSA: hda/tas2781: Add new quirk for Lenovo, ASUS, Dell projects", " - drm/amdkfd: Accounting pdd vram_usage for svm", " - powerpc/powernv: Free name on error in opal_event_init()", " - net: phy: mdio-bcm-unimac: Add BCM6846 support", " - drm/xe/query: Increase timestamp width", " - nvme-loop: flush off pending I/O while shutting down loop controller", " - samples/landlock: Fix port parsing in sandboxer", " - vDPA/ifcvf: Fix pci_read_config_byte() return code handling", " - bpf: Fix mismatched RCU unlock flavour in bpf_out_neigh_v6", " - ASoC: Intel: avs: Update stream status in a separate thread", " - ASoC: codecs: Fix error handling in aw_dev_get_dsp_status function", " - ASoC: amd: yc: Add quirk for ASUS Vivobook S15 M3502RA", " - ASoC: amd: yc: Fix non-functional mic on ASUS E1404FA", " - ASoC: Intel: soc-acpi: lnl: Add match entry for TM2 laptops", " - netfs: Downgrade i_rwsem for a buffered write", " - HID: i2c-hid: Delayed i2c resume wakeup for 0x0d42 Goodix touchpad", " - HID: multitouch: Add quirk for Logitech Bolt receiver w/ Casa touchpad", " - HID: lenovo: Add support for Thinkpad X1 Tablet Gen 3 keyboard", " - ASoC: codecs: lpass-rx-macro: fix RXn(rx,n) macro for DSM_CTL and SEC7 regs", " - RISCV: KVM: use raw_spinlock for critical section in imsic", " - ASoC: rt722-sdca: increase clk_stop_timeout to fix clock stop issue", " - LoongArch: Use \"Exception return address\" to comment ERA", " - ASoC: fsl_micfil: Add sample rate constraint", " - net: usb: qmi_wwan: add Fibocom FG132 0x0112 composition", " - drm/xe: Enlarge the invalidation timeout from 150 to 500", " - drm/xe/guc/ct: Flush g2h worker in case of g2h response timeout", " - drm/xe: Handle unreliable MMIO reads during forcewake", " - drm/xe: Don't restart parallel queues multiple times on GT reset", " - mm: krealloc: Fix MTE false alarm in __do_krealloc", " - 9p: fix slab cache name creation for real", " - Linux 6.11.9", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53098", " - drm/xe/ufence: Prefetch ufence addr to catch bogus address", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53099", " - bpf: Check validity of link->type in bpf_link_show_fdinfo()", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53089", " - LoongArch: KVM: Mark hrtimer to expire in hard interrupt context", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53090", " - afs: Fix lock recursion", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53101", " - fs: Fix uninitialized value issue in from_kuid and from_kgid", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53091", " - bpf: Add sk_is_inet and IS_ICSK check in tls_sw_has_ctx_tx/rx", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53092", " - virtio_pci: Fix admin vq cleanup by using correct info pointer", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53102", " - nvme: make keep-alive synchronous operation", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53093", " - nvme-multipath: defer partition scanning", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53094", " - RDMA/siw: Add sendpage_ok() check to disable MSG_SPLICE_PAGES", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53100", " - nvme: tcp: avoid race between queue_lock lock and destroy", "", " * Oracular update: v6.11.9 upstream stable release (LP: #2091649) //", " CVE-2024-53095", " - smb: client: Fix use-after-free of network namespace.", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645)", " - arm64: dts: rockchip: Fix rt5651 compatible value on rk3399-eaidk-610", " - arm64: dts: rockchip: Fix rt5651 compatible value on rk3399-sapphire-", " excavator", " - arm64: dts: rockchip: Move L3 cache outside CPUs in RK3588(S) SoC dtsi", " - arm64: dts: rockchip: Start cooling maps numbering from zero on ROCK 5B", " - arm64: dts: rockchip: Designate Turing RK1's system power controller", " - EDAC/qcom: Make irq configuration optional", " - arm64: dts: rockchip: Remove hdmi's 2nd interrupt on rk3328", " - arm64: dts: rockchip: Fix wakeup prop names on PineNote BT node", " - arm64: dts: rockchip: Fix reset-gpios property on brcm BT nodes", " - arm64: dts: rockchip: fix i2c2 pinctrl-names property on anbernic-rg353p/v", " - arm64: dts: rockchip: Drop regulator-init-microvolt from two boards", " - arm64: dts: rockchip: Fix bluetooth properties on rk3566 box demo", " - arm64: dts: rockchip: Fix bluetooth properties on Rock960 boards", " - arm64: dts: rockchip: Add DTS for FriendlyARM NanoPi R2S Plus", " - arm64: dts: rockchip: Remove undocumented supports-emmc property", " - arm64: dts: rockchip: Remove #cooling-cells from fan on Theobroma lion", " - arm64: dts: rockchip: Fix LED triggers on rk3308-roc-cc", " - arm64: dts: rockchip: remove num-slots property from rk3328-nanopi-r2s-plus", " - arm64: dts: qcom: sm8450 fix PIPE clock specification for pcie1", " - arm64: dts: imx8-ss-vpu: Fix imx8qm VPU IRQs", " - arm64: dts: imx8mp: correct sdhc ipg clk", " - arm64: dts: imx8mp-phyboard-pollux: Set Video PLL1 frequency to 506.8 MHz", " - firmware: qcom: scm: Return -EOPNOTSUPP for unsupported SHM bridge enabling", " - arm64: dts: rockchip: remove orphaned pinctrl-names from pinephone pro", " - ARM: dts: rockchip: fix rk3036 acodec node", " - ARM: dts: rockchip: drop grf reference from rk3036 hdmi", " - ARM: dts: rockchip: Fix the spi controller on rk3036", " - ARM: dts: rockchip: Fix the realtek audio codec on rk3036-kylin", " - arm64: dts: rockchip: Correct GPIO polarity on brcm BT nodes", " - sunrpc: handle -ENOTCONN in xs_tcp_setup_socket()", " - NFSv3: only use NFS timeout for MOUNT when protocols are compatible", " - NFS: Fix attribute delegation behaviour on exclusive create", " - NFS: Further fixes to attribute delegation a/mtime changes", " - nfs: avoid i_lock contention in nfs_clear_invalid_mapping", " - net: enetc: set MAC address to the VF net_device", " - net: dpaa_eth: print FD status in CPU endianness in dpaa_eth_fd tracepoint", " - dt-bindings: net: xlnx,axi-ethernet: Correct phy-mode property value", " - can: c_can: fix {rx,tx}_errors statistics", " - ice: change q_index variable type to s16 to store -1 value", " - e1000e: Remove Meteor Lake SMBUS workarounds", " - net: phy: ti: add PHY_RST_AFTER_CLK_EN flag", " - net: stmmac: Fix unbalanced IRQ wake disable warning on single irq case", " - netfilter: nf_tables: wait for rcu grace period on net_device removal", " - virtio_net: Support dynamic rss indirection table size", " - virtio_net: Sync rss config to device when virtnet_probe", " - virtio_net: Update rss when set queue", " - net: arc: rockchip: fix emac mdio node support", " - drivers: net: ionic: add missed debugfs cleanup to ionic_probe() error path", " - Revert \"ALSA: hda/conexant: Mute speakers at suspend / shutdown\"", " - media: stb0899_algo: initialize cfr before using it", " - media: dvb_frontend: don't play tricks with underflow values", " - media: adv7604: prevent underflow condition when reporting colorspace", " - scsi: sd_zbc: Use kvzalloc() to allocate REPORT ZONES buffer", " - ALSA: firewire-lib: fix return value on fail in amdtp_tscm_init()", " - tools/lib/thermal: Fix sampling handler context ptr", " - thermal/of: support thermal zones w/o trips subnode", " - ASoC: SOF: sof-client-probes-ipc4: Set param_size extension bits", " - media: pulse8-cec: fix data timestamp at pulse8_setup()", " - media: v4l2-ctrls-api: fix error handling for v4l2_g_ctrl()", " - can: m_can: m_can_close(): don't call free_irq() for IRQ-less devices", " - can: mcp251xfd: mcp251xfd_get_tef_len(): fix length calculation", " - can: mcp251xfd: mcp251xfd_ring_alloc(): fix coalescing configuration when", " switching CAN modes", " - can: {cc770,sja1000}_isa: allow building on x86_64", " - [Config] updateconfigs for CAN_{CC770,SJA1000}_ISA", " - drm/xe: Set mask bits for CCS_MODE register", " - pwm: imx-tpm: Use correct MODULO value for EPWM mode", " - rpmsg: glink: Handle rejected intent request better", " - drm/amd/pm: always pick the pptable from IFWI", " - drm/amd/display: Fix brightness level not retained over reboot", " - drm/imagination: Add a per-file PVR context list", " - drm/amdgpu: Adjust debugfs eviction and IB access permissions", " - drm/amdgpu: Adjust debugfs register access permissions", " - drm/amdgpu: Fix DPX valid mode check on GC 9.4.3", " - drm/amdgpu: prevent NULL pointer dereference if ATIF is not supported", " - thermal/drivers/qcom/lmh: Remove false lockdep backtrace", " - dm cache: correct the number of origin blocks to match the target length", " - dm cache: optimize dirty bit checking with find_next_bit when resizing", " - dm-unstriped: cast an operand to sector_t to prevent potential uint32_t", " overflow", " - mptcp: no admin perm to list endpoints", " - ALSA: usb-audio: Add quirk for HP 320 FHD Webcam", " - tracing: Fix tracefs mount options", " - net: wwan: t7xx: Fix off-by-one error in t7xx_dpmaif_rx_buf_alloc()", " - mptcp: use sock_kfree_s instead of kfree", " - arm64: Kconfig: Make SME depend on BROKEN for now", " - [Config] updateconfigs for ARM64_SME", " - arm64: smccc: Remove broken support for SMCCCv1.3 SVE discard hint", " - KVM: PPC: Book3S HV: Mask off LPCR_MER for a vCPU before running it to avoid", " spurious interrupts", " - btrfs: fix the length of reserved qgroup to free", " - btrfs: fix per-subvolume RO/RW flags with new mount API", " - platform/x86/amd/pmf: Relocate CPU ID macros to the PMF header", " - platform/x86/amd/pmf: Update SMU metrics table for 1AH family series", " - platform/x86/amd/pmf: Add SMU metrics table support for 1Ah family 60h model", " - i2c: designware: do not hold SCL low when I2C_DYNAMIC_TAR_UPDATE is not set", " - clk: qcom: gcc-x1e80100: Fix USB MP SS1 PHY GDSC pwrsts flags", " - clk: qcom: clk-alpha-pll: Fix pll post div mask when width is not set", " - fs/proc: fix compile warning about variable 'vmcore_mmap_ops'", " - objpool: fix to make percpu slot allocation more robust", " - mm/damon/core: handle zero {aggregation,ops_update} intervals", " - mm/damon/core: handle zero schemes apply interval", " - mm/mlock: set the correct prev on failure", " - thunderbolt: Add only on-board retimers when !CONFIG_USB4_DEBUGFS_MARGINING", " - usb: dwc3: fix fault at system suspend if device was already runtime", " suspended", " - USB: serial: qcserial: add support for Sierra Wireless EM86xx", " - USB: serial: option: add Fibocom FG132 0x0112 composition", " - USB: serial: option: add Quectel RG650V", " - clk: qcom: gcc-x1e80100: Fix halt_check for pipediv2 clocks", " - thunderbolt: Fix connection issue with Pluggable UD-4VPD dock", " - staging: vchiq_arm: Use devm_kzalloc() for drv_mgmt allocation", " - staging: vchiq_arm: Use devm_kzalloc() for vchiq_arm_state allocation", " - irqchip/gic-v3: Force propagation of the active state with a read-back", " - ucounts: fix counter leak in inc_rlimit_get_ucounts()", " - selftests: hugetlb_dio: check for initial conditions to skip in the start", " - firmware: qcom: scm: Refactor code to support multiple dload mode", " - [Config] updateconfigs for QCOM_SCM_DOWNLOAD_MODE_DEFAULT", " - firmware: qcom: scm: suppress download mode error", " - block: rework bio splitting", " - block: fix queue limits checks in blk_rq_map_user_bvec for real", " - drm/xe: Move LNL scheduling WA to xe_device.h", " - drm/xe/ufence: Flush xe ordered_wq in case of ufence timeout", " - drm/xe/guc/tlb: Flush g2h worker in case of tlb timeout", " - ASoC: amd: yc: fix internal mic on Xiaomi Book Pro 14 2022", " - xtensa: Emulate one-byte cmpxchg", " - Linux 6.11.8", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50265", " - ocfs2: remove entry once instead of null-ptr-dereference in", " ocfs2_xa_remove()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50266", " - clk: qcom: videocc-sm8350: use HW_CTRL_TRIGGER for vcodec GDSCs", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50267", " - USB: serial: io_edgeport: fix use after free in debug printk", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50268", " - usb: typec: fix potential out of bounds in ucsi_ccg_update_set_new_cam_cmd()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53083", " - usb: typec: qcom-pmic: init value of hdr_len/txbuf_len earlier", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50269", " - usb: musb: sunxi: Fix accessing an released usb phy", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53079", " - mm/thp: fix deferred split unqueue naming and locking", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50270", " - mm/damon/core: avoid overflow in damon_feed_loop_next_input()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50271", " - signal: restore the override_rlimit logic", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50272", " - filemap: Fix bounds checking in filemap_read()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53104", " - media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in", " uvc_parse_format", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50273", " - btrfs: reinitialize delayed ref list after deleting it from the list", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53064", " - idpf: fix idpf_vc_core_init error path", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50274", " - idpf: avoid vport access in idpf_get_link_ksettings", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53065", " - mm/slab: fix warning caused by duplicate kmem_cache creation in", " kmem_buckets_create", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50275", " - arm64/sve: Discard stale CPU state when handling SVE traps", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50276", " - net: vertexcom: mse102x: Fix possible double free of TX skb", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53066", " - nfs: Fix KMSAN warning in decode_getfattr_attrs()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53067", " - scsi: ufs: core: Start the RTC update work later", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50277", " - dm: fix a crash if blk_alloc_disk fails", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50278", " - dm cache: fix potential out-of-bounds access on the first resume", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50279", " - dm cache: fix out-of-bounds access to the dirty bitset when resizing", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50280", " - dm cache: fix flushing uninitialized delayed_work on cache_ctr error", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50281", " - KEYS: trusted: dcp: fix NULL dereference in AEAD crypto operation", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50282", " - drm/amdgpu: add missing size check in amdgpu_debugfs_gprwave_read()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53071", " - drm/panthor: Be stricter about IO mapping flags", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53080", " - drm/panthor: Lock XArray when getting entries for the VM", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53084", " - drm/imagination: Break an object reference loop", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53085", " - tpm: Lock TPM chip in tpm_pm_suspend() first", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53086", " - drm/xe: Drop VM dma-resv lock on xe_sync_in_fence_get failure in exec IOCTL", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53087", " - drm/xe: Fix possible exec queue leak in exec IOCTL", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50283", " - ksmbd: fix slab-use-after-free in smb3_preauth_hash_rsp", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50284", " - ksmbd: Fix the missing xa_store error check", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50285", " - ksmbd: check outstanding simultaneous SMB operations", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50286", " - ksmbd: fix slab-use-after-free in ksmbd_smb2_session_create", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50287", " - media: v4l2-tpg: prevent the risk of a division by zero", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50288", " - media: vivid: fix buffer overwrite when using > 32 buffers", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50289", " - media: av7110: fix a spectre vulnerability", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50290", " - media: cx24116: prevent overflows on SNR calculus", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53061", " - media: s5p-jpeg: prevent buffer overflows", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53081", " - media: ar0521: don't overflow when checking PLL values", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53062", " - media: mgb4: protect driver against spectre", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50291", " - media: dvb-core: add missing buffer index check", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50292", " - ASoC: stm32: spdifrx: fix dma channel release in stm32_spdifrx_remove", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53063", " - media: dvbdev: prevent the risk of out of memory access", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50293", " - net/smc: do not leave a dangling sk pointer in __smc_create()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50294", " - rxrpc: Fix missing locking causing hanging calls", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50295", " - net: arc: fix the device for dma_map_single/dma_unmap_single", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53082", " - virtio_net: Add hash_key_length check", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50296", " - net: hns3: fix kernel crash when uninstalling driver", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53088", " - i40e: fix race condition by adding filter's intermediate sync state", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50297", " - net: xilinx: axienet: Enqueue Tx packets in dql before dmaengine starts", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50298", " - net: enetc: allocate vf_state during PF probes", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50299", " - sctp: properly validate chunk size in sctp_sf_ootb()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50300", " - regulator: rtq2208: Fix uninitialized use of regulator_config", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50301", " - security/keys: fix slab-out-of-bounds in key_task_permission", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53072", " - platform/x86/amd/pmc: Detect when STB is not available", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-50302", " - HID: core: zero-initialize the report buffer", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53068", " - firmware: arm_scmi: Fix slab-use-after-free in scmi_bus_notifier()", "", " * Oracular update: v6.11.8 upstream stable release (LP: #2091645) //", " CVE-2024-53069", " - firmware: qcom: scm: fix a NULL-pointer dereference", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629)", " - drm/amdgpu: fix random data corruption for sdma 7", " - cgroup: Fix potential overflow issue when checking max_depth", " - spi: geni-qcom: Fix boot warning related to pm_runtime and devres", " - perf trace: Fix non-listed archs in the syscalltbl routines", " - perf python: Fix up the build on architectures without HAVE_KVM_STAT_SUPPORT", " - scsi: scsi_debug: Fix do_device_access() handling of unexpected SG copy", " length", " - wifi: iwlegacy: Fix \"field-spanning write\" warning in il_enqueue_hcmd()", " - mac80211: MAC80211_MESSAGE_TRACING should depend on TRACING", " - wifi: mac80211: skip non-uploaded keys in ieee80211_iter_keys", " - wifi: ath11k: Fix invalid ring usage in full monitor mode", " - wifi: rtw89: pci: early chips only enable 36-bit DMA on specific PCI hosts", " - wifi: brcm80211: BRCM_TRACING should depend on TRACING", " - RDMA/cxgb4: Dump vendor specific QP details", " - RDMA/mlx5: Round max_rd_atomic/max_dest_rd_atomic up instead of down", " - RDMA/bnxt_re: Fix the usage of control path spin locks", " - RDMA/bnxt_re: synchronize the qp-handle table array", " - wifi: iwlwifi: mvm: really send iwl_txpower_constraints_cmd", " - wifi: iwlwifi: mvm: don't add default link in fw restart flow", " - Revert \"wifi: iwlwifi: remove retry loops in start\"", " - ASoC: cs42l51: Fix some error handling paths in cs42l51_probe()", " - net: stmmac: dwmac4: Fix high address display by updating reg_space[] from", " register values", " - dpll: add Embedded SYNC feature for a pin", " - ice: add callbacks for Embedded SYNC enablement on dpll pins", " - gtp: allow -1 to be specified as file description from userspace", " - bpf: Force checkpoint when jmp history is too long", " - bpf: Add bpf_mem_alloc_check_size() helper", " - net: skip offload for NETIF_F_IPV6_CSUM if ipv6 header contains extension", " - mlxsw: spectrum_ptp: Add missing verification before pushing Tx header", " - mlxsw: pci: Sync Rx buffers for CPU", " - mlxsw: pci: Sync Rx buffers for device", " - net: ethernet: mtk_wed: fix path of MT7988 WO firmware", " - bpf, test_run: Fix LIVE_FRAME frame update after a page has been recycled", " - iomap: improve shared block detection in iomap_unshare_iter", " - iomap: don't bother unsharing delalloc extents", " - iomap: share iomap_unshare_iter predicate code with fsdax", " - fsdax: remove zeroing code from dax_unshare_iter", " - iomap: turn iomap_want_unshare_iter into an inline function", " - kasan: Fix Software Tag-Based KASAN with GCC", " - firmware: arm_sdei: Fix the input parameter of cpuhp_remove_state()", " - afs: Fix missing subdir edit when renamed between parent dirs", " - gpio: sloppy-logic-analyzer: Check for error code from devm_mutex_init()", " call", " - smb: client: fix parsing of device numbers", " - smb: client: set correct device number on nfs reparse points", " - drm/mediatek: ovl: Remove the color format comment for ovl_fmt_convert()", " - drm/mediatek: Fix color format MACROs in OVL", " - drm/mediatek: Fix get efuse issue for MT8188 DPTX", " - drm/mediatek: Use cmdq_pkt_create() and cmdq_pkt_destroy()", " - cxl/events: Fix Trace DRAM Event Record", " - PCI: Fix pci_enable_acs() support for the ACS quirks", " - nvme: module parameter to disable pi with offsets", " - drm/panthor: Fix firmware initialization on systems with a page size > 4k", " - drm/panthor: Fail job creation when the group is dead", " - drm/panthor: Report group as timedout when we fail to properly suspend", " - fs/ntfs3: Fix warning possible deadlock in ntfs_set_state", " - fs/ntfs3: Stale inode instead of bad", " - rust: device: change the from_raw() function", " - scsi: scsi_transport_fc: Allow setting rport state to current state", " - cifs: Improve creating native symlinks pointing to directory", " - cifs: Fix creating native symlinks pointing to current or parent directory", " - ACPI: resource: Fold Asus Vivobook Pro N6506M* DMI quirks together", " - powercap: intel_rapl_msr: Add PL4 support for Arrowlake-U", " - thermal: intel: int340x: processor: Remove MMIO RAPL CPU hotplug support", " - thermal: intel: int340x: processor: Add MMIO RAPL PL4 support", " - net: amd: mvme147: Fix probe banner message", " - NFS: remove revoked delegation from server's delegation list", " - misc: sgi-gru: Don't disable preemption in GRU driver", " - NFSD: Initialize struct nfsd4_copy earlier", " - NFSD: Never decrement pending_async_copies on error", " - ALSA: usb-audio: Add quirks for Dell WD19 dock", " - wifi: rtlwifi: rtl8192du: Don't claim USB ID 0bda:8171", " - usbip: tools: Fix detach_port() invalid port error path", " - usb: phy: Fix API devm_usb_put_phy() can not release the phy", " - usb: typec: fix unreleased fwnode_handle in typec_port_register_altmodes()", " - usb: typec: tcpm: restrict SNK_WAIT_CAPABILITIES_TIMEOUT transitions to non", " self-powered devices", " - usb: typec: qcom-pmic-typec: use fwnode_handle_put() to release fwnodes", " - usb: typec: qcom-pmic-typec: fix missing fwnode removal in error path", " - xhci: Fix Link TRB DMA in command ring stopped completion event", " - xhci: Use pm_runtime_get to prevent RPM on unsupported systems", " - Revert \"driver core: Fix uevent_show() vs driver detach race\"", " - dt-bindings: iio: adc: ad7380: fix ad7380-4 reference supply", " - iio: light: veml6030: fix microlux value calculation", " - RISC-V: ACPI: fix early_ioremap to early_memremap", " - tools/mm: -Werror fixes in page-types/slabinfo", " - mm: shrinker: avoid memleak in alloc_shrinker_info", " - firmware: microchip: auto-update: fix poll_complete() to not report spurious", " timeout errors", " - thunderbolt: Honor TMU requirements in the domain when setting TMU mode", " - soc: qcom: pmic_glink: Handle GLINK intent allocation rejections", " - cxl/port: Fix CXL port initialization order when the subsystem is built-in", " - mmc: sdhci-pci-gli: GL9767: Fix low power mode on the set clock function", " - mmc: sdhci-pci-gli: GL9767: Fix low power mode in the SD Express process", " - block: fix sanity checks in blk_rq_map_user_bvec", " - phy: freescale: imx8m-pcie: Do CMN_RST just before PHY PLL lock check", " - btrfs: merge btrfs_orig_bbio_end_io() into btrfs_bio_end_io()", " - riscv: vdso: Prevent the compiler from inserting calls to memset()", " - Input: edt-ft5x06 - fix regmap leak when probe fails", " - ALSA: hda/realtek: Limit internal Mic boost on Dell platform", " - riscv: efi: Set NX compat flag in PE/COFF header", " - riscv: Use '%u' to format the output of 'cpu'", " - riscv: Remove unused GENERATING_ASM_OFFSETS", " - riscv: Remove duplicated GET_RM", " - cxl/port: Fix cxl_bus_rescan() vs bus_rescan_devices()", " - cxl/acpi: Ensure ports ready at cxl_acpi_probe() return", " - posix-cpu-timers: Clear TICK_DEP_BIT_POSIX_TIMER on clone", " - tpm: Return tpm2_sessions_init() when null key creation fails", " - tpm: Rollback tpm2_load_null()", " - drm/amdgpu/smu13: fix profile reporting", " - tpm: Lazily flush the auth session", " - mei: use kvmalloc for read buffer", " - x86/traps: Enable UBSAN traps on x86", " - x86/traps: move kmsan check after instrumentation_begin", " - accel/ivpu: Fix NOC firewall interrupt handling", " - ALSA: hda/realtek: Fix headset mic on TUXEDO Gemini 17 Gen3", " - ALSA: hda/realtek: Fix headset mic on TUXEDO Stellaris 16 Gen6 mb1", " - nvme: re-fix error-handling for io_uring nvme-passthrough", " - kasan: remove vmalloc_percpu test", " - drm/tests: helpers: Add helper for drm_display_mode_from_cea_vic()", " - drm/xe: Fix register definition order in xe_regs.h", " - drm/xe: Kill regs/xe_sriov_regs.h", " - drm/xe: Add mmio read before GGTT invalidate", " - drm/xe: Don't short circuit TDR on jobs not started", " - btrfs: fix extent map merging not happening for adjacent extents", " - btrfs: fix defrag not merging contiguous extents due to merged extent maps", " - gpiolib: fix debugfs newline separators", " - gpiolib: fix debugfs dangling chip separator", " - vmscan,migrate: fix page count imbalance on node stats when demoting pages", " - mm, mmap: limit THP alignment of anonymous mappings to PMD-aligned sizes", " - Input: fix regression when re-registering input handlers", " - mm: multi-gen LRU: ignore non-leaf pmd_young for force_scan=true", " - mm: multi-gen LRU: remove MM_LEAF_OLD and MM_NONLEAF_TOTAL stats", " - mm: shrink skip folio mapped by an exiting process", " - mm: multi-gen LRU: use {ptep,pmdp}_clear_young_notify()", " - riscv: dts: starfive: Update ethernet phy0 delay parameter values for Star64", " - riscv: dts: starfive: disable unused csi/camss nodes", " - arm64: dts: qcom: msm8939: revert use of APCS mbox for RPM", " - arm64: dts: qcom: x1e80100-yoga-slim7x: fix nvme regulator boot glitch", " - arm64: dts: qcom: x1e80100: Fix up BAR spaces", " - arm64: dts: qcom: x1e80100-vivobook-s15: fix nvme regulator boot glitch", " - arm64: dts: qcom: x1e80100: fix PCIe4 interconnect", " - arm64: dts: qcom: x1e80100-qcp: fix nvme regulator boot glitch", " - arm64: dts: qcom: x1e80100-crd: fix nvme regulator boot glitch", " - arm64: dts: qcom: x1e80100: Add Broadcast_AND region in LLCC block", " - arm64: dts: qcom: x1e80100: fix PCIe4 and PCIe6a PHY clocks", " - drm/xe/xe2hpg: Add Wa_15016589081", " - drm/amdgpu/swsmu: fix ordering for setting workload_mask", " - drm/amdgpu/swsmu: default to fullscreen 3D profile for dGPUs", " - fs/ntfs3: Sequential field availability check in mi_enum_attr()", " - drm/amdgpu: handle default profile on on devices without fullscreen 3D", " - MIPS: export __cmpxchg_small()", " - RISC-V: disallow gcc + rust builds", " - [Config] updateconfigs after disabling rust with gcc on riscv", " - rcu/kvfree: Add kvfree_rcu_barrier() API", " - rcu/kvfree: Refactor kvfree_rcu_queue_batch()", " - Linux 6.11.7", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50212", " - lib: alloc_tag_module_unload must wait for pending kfree_rcu calls", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53046", " - arm64: dts: imx8ulp: correct the flexspi compatible string", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53052", " - io_uring/rw: fix missing NOWAIT check for O_DIRECT start write", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50213", " - drm/tests: hdmi: Fix memory leaks in drm_display_mode_from_cea_vic()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50214", " - drm/connector: hdmi: Fix memory leak in drm_display_mode_from_cea_vic()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50215", " - nvmet-auth: assign dh_key to NULL after kfree_sensitive", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50216", " - xfs: fix finding a last resort AG in xfs_filestream_pick_ag", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50217", " - btrfs: fix use-after-free of block device file in", " __btrfs_free_extra_devids()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53043", " - mctp i2c: handle NULL header address", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50303", " - resource,kexec: walk_system_ram_res_rev must retain resource flags", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50218", " - ocfs2: pass u64 to ocfs2_truncate_inline maybe overflow", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50219", " - mm/page_alloc: let GFP_ATOMIC order-0 allocs access highatomic reserves", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50263", " - fork: only invoke khugepaged, ksm hooks if no error", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50220", " - fork: do not invoke uffd on fork if error occurs", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53047", " - mptcp: init: protect sched with rcu_read_lock", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50221", " - drm/amd/pm: Vangogh: Fix kernel memory out of bounds write", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50222", " - iov_iter: fix copy_page_from_iter_atomic() if KMAP_LOCAL_FORCE_MAP", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50223", " - sched/numa: Fix the potential null pointer dereference in task_numa_work()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53053", " - scsi: ufs: core: Fix another deadlock during RTC update", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53075", " - riscv: Prevent a bad reference count on CPU nodes", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50224", " - spi: spi-fsl-dspi: Fix crash when not using GPIO chip select", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50225", " - btrfs: fix error propagation of split bios", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53054", " - cgroup/bpf: use a dedicated workqueue for cgroup bpf destruction", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50226", " - cxl/port: Fix use-after-free, permit out-of-order decoder shutdown", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50227", " - thunderbolt: Fix KASAN reported stack out-of-bounds read in", " tb_retimer_scan()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50228", " - mm: shmem: fix data-race in shmem_getattr()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50229", " - nilfs2: fix potential deadlock with newly created symlinks", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50230", " - nilfs2: fix kernel bug due to missing clearing of checked flag", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50231", " - iio: gts-helper: Fix memory leaks in iio_gts_build_avail_scale_table()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53076", " - iio: gts-helper: Fix memory leaks for the error path of", " iio_gts_build_avail_scale_table()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50232", " - iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50233", " - staging: iio: frequency: ad9832: fix division by zero in", " ad9832_calc_freqreg()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53055", " - wifi: iwlwifi: mvm: fix 6 GHz scan construction", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50234", " - wifi: iwlegacy: Clear stale interrupts before resuming device", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50235", " - wifi: cfg80211: clear wdev->cqm_config pointer on free", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50236", " - wifi: ath10k: Fix memory leak in management tx", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50237", " - wifi: mac80211: do not pass a stopped vif to the driver in .get_txpower", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50238", " - phy: qcom: qmp-usbc: fix NULL-deref on runtime suspend", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50239", " - phy: qcom: qmp-usb-legacy: fix NULL-deref on runtime suspend", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50240", " - phy: qcom: qmp-usb: fix NULL-deref on runtime suspend", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53077", " - rpcrdma: Always release the rpcrdma_device's xa_array", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50242", " - fs/ntfs3: Additional check in ntfs_file_release", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50243", " - fs/ntfs3: Fix general protection fault in run_is_mapped_full", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50244", " - fs/ntfs3: Additional check in ni_clear()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50245", " - fs/ntfs3: Fix possible deadlock in mi_read", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50246", " - fs/ntfs3: Add rough attr alloc_size check", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50247", " - fs/ntfs3: Check if more than chunk-size bytes are written", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50248", " - ntfs3: Add bounds checking to mi_enum_attr()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53078", " - drm/tegra: Fix NULL vs IS_ERR() check in probe()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53056", " - drm/mediatek: Fix potential NULL dereference in mtk_crtc_destroy()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50249", " - ACPI: CPPC: Make rmw_lock a raw_spin_lock", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50250", " - fsdax: dax_unshare_iter needs to copy entire blocks", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50251", " - netfilter: nft_payload: sanitize offset and length before calling", " skb_checksum()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50252", " - mlxsw: spectrum_ipip: Fix memory leak when changing remote IPv6 address", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50253", " - bpf: Check the validity of nr_words in bpf_iter_bits_new()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50254", " - bpf: Free dynamically allocated bits in bpf_iter_bits_destroy()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50255", " - Bluetooth: hci: fix null-ptr-deref in hci_read_supported_codecs", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50256", " - netfilter: nf_reject_ipv6: fix potential crash in nf_send_reset6()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50257", " - netfilter: Fix use-after-free in get_info()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50258", " - net: fix crash when config small gso_max_size/gso_ipv4_max_size", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50262", " - bpf: Fix out-of-bounds write in trie_get_next_key()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53044", " - net/sched: sch_api: fix xa_insert() error path in tcf_block_get_ext()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50259", " - netdevsim: Add trailing zero to terminate the string in", " nsim_nexthop_bucket_activity_write()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50304", " - ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53042", " - ipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_init_flow()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53048", " - ice: fix crash on probe for DPLL enabled E810 LOM", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53058", " - net: stmmac: TSO: Fix unbalanced DMA map/unmap for non-paged SKB data", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50260", " - sock_map: fix a NULL pointer dereference in sock_map_link_update_prog()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53045", " - ASoC: dapm: fix bounds checker error in dapm_widget_list_create", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-50261", " - macsec: Fix use-after-free while sending the offloading packet", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53059", " - wifi: iwlwifi: mvm: Fix response handling in iwl_mvm_send_recovery_cmd()", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53074", " - wifi: iwlwifi: mvm: don't leak a link on AP removal", "", " * Oracular update: v6.11.7 upstream stable release (LP: #2091629) //", " CVE-2024-53049", " - slub/kunit: fix a WARNING due to unwrapped __kmalloc_cache_noprof", "", " * Oracular update: v6.11.6 upstream stable release (LP: #2091386)", " - bpf: Use raw_spinlock_t in ringbuf", " - iio: accel: bma400: Fix uninitialized variable field_value in tap event", " handling.", " - reset: starfive: jh71x0: Fix accessing the empty member on JH7110 SoC", " - bpf: sync_linked_regs() must preserve subreg_def", " - bpf: Make sure internal and UAPI bpf_redirect flags don't overlap", " - irqchip/riscv-imsic: Fix output text of base address", " - bpf: devmap: provide rxq after redirect", " - cpufreq/amd-pstate: Fix amd_pstate mode switch on shared memory systems", " - lib/Kconfig.debug: fix grammar in RUST_BUILD_ASSERT_ALLOW", " - bpf: Fix memory leak in bpf_core_apply", " - RDMA/bnxt_re: Fix a possible memory leak", " - RDMA/bnxt_re: Fix incorrect AVID type in WQE structure", " - RDMA/bnxt_re: Add a check for memory allocation", " - x86/resctrl: Avoid overflow in MB settings in bw_validate()", " - ARM: dts: bcm2837-rpi-cm3-io3: Fix HDMI hpd-gpio pin", " - clk: rockchip: fix finding of maximum clock ID", " - bpf: Check the remaining info_cnt before repeating btf fields", " - bpf: fix unpopulated name_len field in perf_event link info", " - selftests/bpf: fix perf_event link info name_len assertion", " - riscv, bpf: Fix possible infinite tailcall when CONFIG_CFI_CLANG is enabled", " - s390/pci: Handle PCI error codes other than 0x3a", " - bpf: fix kfunc btf caching for modules", " - iio: frequency: {admv4420,adrf6780}: format Kconfig entries", " - iio: frequency: admv4420: fix missing select REMAP_SPI in Kconfig", " - drm/vmwgfx: Handle possible ENOMEM in vmw_stdu_connector_atomic_check", " - selftests/bpf: Fix cross-compiling urandom_read", " - bpf: Fix unpopulated path_size when uprobe_multi fields unset", " - sched/core: Disable page allocation in task_tick_mm_cid()", " - ALSA: hda/cs8409: Fix possible NULL dereference", " - firmware: arm_scmi: Fix the double free in scmi_debugfs_common_setup()", " - RDMA/cxgb4: Fix RDMA_CM_EVENT_UNREACHABLE error for iWARP", " - RDMA/irdma: Fix misspelling of \"accept*\"", " - RDMA/srpt: Make slab cache names unique", " - elevator: do not request_module if elevator exists", " - elevator: Remove argument from elevator_find_get", " - ipv4: give an IPv4 dev to blackhole_netdev", " - net: sparx5: fix source port register when mirroring", " - RDMA/bnxt_re: Fix the max CQ WQEs for older adapters", " - RDMA/bnxt_re: Fix out of bound check", " - RDMA/bnxt_re: Fix incorrect dereference of srq in async event", " - RDMA/bnxt_re: Return more meaningful error", " - RDMA/bnxt_re: Avoid CPU lockups due fifo occupancy check loop", " - RDMA/bnxt_re: Get the toggle bits from SRQ events", " - RDMA/bnxt_re: Change the sequence of updating the CQ toggle value", " - RDMA/bnxt_re: Fix a bug while setting up Level-2 PBL pages", " - RDMA/bnxt_re: Fix the GID table length", " - accel/qaic: Fix the for loop used to walk SG table", " - drm/panel: himax-hx83102: Adjust power and gamma to optimize brightness", " - drm/msm/dpu: make sure phys resources are properly initialized", " - drm/msm/dpu: move CRTC resource assignment to dpu_encoder_virt_atomic_check", " - drm/msm/dpu: check for overflow in _dpu_crtc_setup_lm_bounds()", " - drm/msm/dsi: improve/fix dsc pclk calculation", " - drm/msm/dsi: fix 32-bit signed integer extension in pclk_rate calculation", " - drm/msm: Avoid NULL dereference in msm_disp_state_print_regs()", " - drm/msm: Allocate memory for disp snapshot with kvzalloc()", " - firmware: arm_scmi: Queue in scmi layer for mailbox implementation", " - net/smc: Fix memory leak when using percpu refs", " - [PATCH} hwmon: (jc42) Properly detect TSE2004-compliant devices again", " - net: usb: usbnet: fix race in probe failure", " - net: stmmac: dwmac-tegra: Fix link bring-up sequence", " - octeontx2-af: Fix potential integer overflows on integer shifts", " - ring-buffer: Fix reader locking when changing the sub buffer order", " - drm/amd/amdgpu: Fix double unlock in amdgpu_mes_add_ring", " - macsec: don't increment counters for an unrelated SA", " - netdevsim: use cond_resched() in nsim_dev_trap_report_work()", " - net: ethernet: aeroflex: fix potential memory leak in", " greth_start_xmit_gbit()", " - net/smc: Fix searching in list of known pnetids in smc_pnet_add_pnetid", " - net: xilinx: axienet: fix potential memory leak in axienet_start_xmit()", " - net: ethernet: rtsn: fix potential memory leak in rtsn_start_xmit()", " - bpf: Fix truncation bug in coerce_reg_to_size_sx()", " - net: systemport: fix potential memory leak in bcm_sysport_xmit()", " - irqchip/renesas-rzg2l: Fix missing put_device", " - drm/msm/dpu: Don't always set merge_3d pending flush", " - drm/msm/dpu: don't always program merge_3d block", " - net: bcmasp: fix potential memory leak in bcmasp_xmit()", " - drm/msm/a6xx+: Insert a fence wait before SMMU table update", " - tcp/dccp: Don't use timer_pending() in reqsk_queue_unlink().", " - net: dsa: mv88e6xxx: Fix the max_vid definition for the MV88E6361", " - genetlink: hold RCU in genlmsg_mcast()", " - ravb: Remove setting of RX software timestamp", " - net: ravb: Only advertise Rx/Tx timestamps if hardware supports it", " - net: dsa: vsc73xx: fix reception from VLAN-unaware bridges", " - scsi: target: core: Fix null-ptr-deref in target_alloc_device()", " - smb: client: fix possible double free in smb2_set_ea()", " - smb: client: fix OOBs when building SMB2_IOCTL request", " - usb: typec: altmode should keep reference to parent", " - s390: Initialize psw mask in perf_arch_fetch_caller_regs()", " - drm/xe: fix unbalanced rpm put() with fence_fini()", " - drm/xe: fix unbalanced rpm put() with declare_wedged()", " - drm/xe: Take job list lock in xe_sched_add_pending_job", " - drm/xe: Don't free job in TDR", " - drm/xe: Use bookkeep slots for external BO's in exec IOCTL", " - bpf: Fix link info netfilter flags to populate defrag flag", " - Bluetooth: bnep: fix wild-memory-access in proto_unregister", " - vmxnet3: Fix packet corruption in vmxnet3_xdp_xmit_frame", " - net: ethernet: mtk_eth_soc: fix memory corruption during fq dma init", " - net/mlx5: Check for invalid vector index on EQ creation", " - net/mlx5: Fix command bitmask initialization", " - net/mlx5: Unregister notifier on eswitch init failure", " - net/mlx5e: Don't call cleanup on profile rollback failure", " - bpf, sockmap: SK_DROP on attempted redirects of unsupported af_vsock", " - vsock: Update rx_bytes on read_skb()", " - vsock: Update msg_count on read_skb()", " - bpf, vsock: Drop static vsock_bpf_prot initialization", " - riscv, bpf: Make BPF_CMPXCHG fully ordered", " - nvme-pci: fix race condition between reset and nvme_dev_disable()", " - bpf: Fix iter/task tid filtering", " - bpf: Fix incorrect delta propagation between linked registers", " - bpf: Fix print_reg_state's constant scalar dump", " - cdrom: Avoid barrier_nospec() in cdrom_ioctl_media_changed()", " - fgraph: Allocate ret_stack_list with proper size", " - mm: shmem: rename shmem_is_huge() to shmem_huge_global_enabled()", " - mm: shmem: move shmem_huge_global_enabled() into", " shmem_allowable_huge_orders()", " - mm: huge_memory: add vma_thp_disabled() and thp_disabled_by_hw()", " - mm: don't install PMD mappings when THPs are disabled by the hw/process/vma", " - iio: adc: ti-lmp92064: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - xhci: dbgtty: remove kfifo_out() wrapper", " - xhci: dbgtty: use kfifo from tty_port struct", " - xhci: dbc: honor usb transfer size boundaries.", " - uprobe: avoid out-of-bounds memory access of fetching args", " - drm/vboxvideo: Replace fake VLA at end of vbva_mouse_pointer_shape with real", " VLA", " - ASoC: amd: yc: Add quirk for HP Dragonfly pro one", " - ASoC: codecs: lpass-rx-macro: add missing CDC_RX_BCL_VBAT_RF_PROC2 to", " default regs values", " - ASoC: fsl_sai: Enable 'FIFO continue on error' FCONT bit", " - arm64: Force position-independent veneers", " - udf: refactor udf_current_aext() to handle error", " - udf: refactor udf_next_aext() to handle error", " - udf: refactor inode_bmap() to handle error", " - udf: fix uninit-value use in udf_get_fileshortad", " - ASoC: qcom: sm8250: add qrb4210-rb2-sndcard compatible string", " - fsnotify: Avoid data race between fsnotify_recalc_mask() and", " fsnotify_object_watched()", " - drm/xe/mcr: Use Xe2_LPM steering tables for Xe2_HPM", " - cifs: Validate content of NFS reparse point buffer", " - LoongArch: Don't crash in stack_top() for tasks without vDSO", " - objpool: fix choosing allocation for percpu slots", " - jfs: Fix sanity check in dbMount", " - tracing/probes: Fix MAX_TRACE_ARGS limit handling", " - tracing: Consider the NULL character when validating the event length", " - xfrm: extract dst lookup parameters into a struct", " - xfrm: respect ip protocols rules criteria when performing dst lookups", " - xfrm: validate new SA's prefixlen using SA family when sel.family is unset", " - netfilter: bpf: must hold reference on net namespace", " - net: pse-pd: Fix out of bound for loop", " - net/sun3_82586: fix potential memory leak in sun3_82586_send_packet()", " - be2net: fix potential memory leak in be_xmit()", " - net: plip: fix break; causing plip to never transmit", " - bnxt_en: replace ptp_lock with irqsave variant", " - octeon_ep: Implement helper for iterating packets in Rx queue", " - octeon_ep: Add SKB allocation failures handling in __octep_oq_process_rx()", " - net: dsa: mv88e6xxx: Fix error when setting port policy on mv88e6393x", " - bpf, arm64: Fix address emission with tag-based KASAN enabled", " - fsl/fman: Save device references taken in mac_probe()", " - fsl/fman: Fix refcount handling of fman-related devices", " - net: wwan: fix global oob in wwan_rtnl_policy", " - net: fix races in netdev_tx_sent_queue()/dev_watchdog()", " - virtio_net: fix integer overflow in stats", " - mlxsw: spectrum_router: fix xa_store() error checking", " - net: usb: usbnet: fix name regression", " - bpf: Preserve param->string when parsing mount options", " - bpf: Add MEM_WRITE attribute", " - bpf: Fix overloading of MEM_UNINIT's meaning", " - bpf: Remove MEM_UNINIT from skb/xdp MTU helpers", " - net/sched: act_api: deny mismatched skip_sw/skip_hw flags for actions", " created by classifiers", " - net: sched: fix use-after-free in taprio_change()", " - net: sched: use RCU read-side critical section in taprio_dump()", " - r8169: avoid unsolicited interrupts", " - posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime()", " - Bluetooth: hci_core: Disable works on hci_unregister_dev", " - Bluetooth: SCO: Fix UAF on sco_sock_timeout", " - Bluetooth: ISO: Fix UAF on iso_sock_timeout", " - bpf,perf: Fix perf_event_detach_bpf_prog error handling", " - bpf: fix do_misc_fixups() for bpf_get_branch_snapshot()", " - net: dsa: microchip: disable EEE for KSZ879x/KSZ877x/KSZ876x", " - net: dsa: mv88e6xxx: group cycle counter coefficients", " - net: dsa: mv88e6xxx: read cycle counter period from hardware", " - net: dsa: mv88e6xxx: support 4000ps cycle counter period", " - bpf: Add the missing BPF_LINK_TYPE invocation for sockmap", " - ASoC: dt-bindings: davinci-mcasp: Fix interrupts property", " - ASoC: dt-bindings: davinci-mcasp: Fix interrupt properties", " - ASoC: loongson: Fix component check failed on FDT systems", " - ASoC: topology: Bump minimal topology ABI version", " - ASoC: max98388: Fix missing increment of variable slot_found", " - ASoC: rsnd: Fix probe failure on HiHope boards due to endpoint parsing", " - PCI: Hold rescan lock while adding devices during host probe", " - fs: pass offset and result to backing_file end_write() callback", " - fuse: update inode size after extending passthrough write", " - ASoC: fsl_micfil: Add a flag to distinguish with different volume control", " types", " - ALSA: firewire-lib: Avoid division by zero in apply_constraint_to_size()", " - fbdev: wm8505fb: select CONFIG_FB_IOMEM_FOPS", " - powercap: dtpm_devfreq: Fix error check against dev_pm_qos_add_request()", " - nfsd: cancel nfsd_shrinker_work using sync mode in nfs4_state_shutdown_net", " - ALSA: hda/realtek: Update default depop procedure", " - smb: client: Handle kstrdup failures for passwords", " - cifs: fix warning when destroy 'cifs_io_request_pool'", " - PCI/pwrctl: Add WCN6855 support", " - PCI/pwrctl: Abandon QCom WCN probe on pre-pwrseq device-trees", " - cpufreq: CPPC: fix perf_to_khz/khz_to_perf conversion exception", " - btrfs: qgroup: set a more sane default value for subtree drop threshold", " - btrfs: clear force-compress on remount when compress mount option is given", " - btrfs: fix passing 0 to ERR_PTR in btrfs_search_dir_index_item()", " - perf/x86/rapl: Fix the energy-pkg event for AMD CPUs", " - btrfs: reject ro->rw reconfiguration if there are hard ro requirements", " - btrfs: zoned: fix zone unusable accounting for freed reserved extent", " - btrfs: fix read corruption due to race with extent map merging", " - drm/amd: Guard against bad data for ATIF ACPI method", " - ACPI: resource: Add LG 16T90SP to irq1_level_low_skip_override[]", " - ACPI: PRM: Find EFI_MEMORY_RUNTIME block for PRM handler and context", " - ACPI: button: Add DMI quirk for Samsung Galaxy Book2 to fix initial lid", " detection issue", " - nilfs2: fix kernel bug due to missing clearing of buffer delay flag", " - fs: don't try and remove empty rbtree node", " - xfs: don't fail repairs on metadata files with no attr fork", " - openat2: explicitly return -E2BIG for (usize > PAGE_SIZE)", " - KVM: nSVM: Ignore nCR3[4:0] when loading PDPTEs from memory", " - KVM: arm64: Unregister redistributor for failed vCPU creation", " - KVM: arm64: Fix shift-out-of-bounds bug", " - KVM: arm64: Don't eagerly teardown the vgic on init error", " - firewire: core: fix invalid port index for parent device", " - x86/lam: Disable ADDRESS_MASKING in most cases", " - [Config] updateconfigs to disable ADDRESS_MASKING", " - x86/sev: Ensure that RMP table fixups are reserved", " - ALSA: hda/tas2781: select CRC32 instead of CRC32_SARWATE", " - ALSA: hda/realtek: Add subwoofer quirk for Acer Predator G9-593", " - LoongArch: Get correct cores_per_package for SMT systems", " - LoongArch: Enable IRQ if do_ale() triggered in irq-enabled context", " - LoongArch: Make KASAN usable for variable cpu_vabits", " - xfrm: fix one more kernel-infoleak in algo dumping", " - hv_netvsc: Fix VF namespace also in synthetic NIC NETDEV_REGISTER event", " - md/raid10: fix null ptr dereference in raid10_size()", " - drm/bridge: Fix assignment of the of_node of the parent to aux bridge", " - drm/amd/display: Disable PSR-SU on Parade 08-01 TCON too", " - platform/x86/intel/pmc: Fix pmc_core_iounmap to call iounmap for valid", " addresses", " - fgraph: Fix missing unlock in register_ftrace_graph()", " - fgraph: Change the name of cpuhp state to \"fgraph:online\"", " - net: phy: dp83822: Fix reset pin definitions", " - nfsd: fix race between laundromat and free_stateid", " - drm/amd/display: temp w/a for DP Link Layer compliance", " - ata: libata: Set DID_TIME_OUT for commands that actually timed out", " - ASoC: SOF: Intel: hda-loader: do not wait for HDaudio IOC", " - ASoC: SOF: Intel: hda: Handle prepare without close for non-HDA DAI's", " - ASoC: SOF: Intel: hda: Always clean up link DMA during stop", " - ASoC: SOF: ipc4-topology: Do not set ALH node_id for aggregated DAIs", " - ASoC: dapm: avoid container_of() to get component", " - ASoC: qcom: sc7280: Fix missing Soundwire runtime stream alloc", " - ASoC: qcom: sdm845: add missing soundwire runtime stream alloc", " - ASoC: qcom: Fix NULL Dereference in asoc_qcom_lpass_cpu_platform_probe()", " - Revert \" fs/9p: mitigate inode collisions\"", " - Revert \"fs/9p: remove redundant pointer v9ses\"", " - Revert \"fs/9p: fix uaf in in v9fs_stat2inode_dotl\"", " - Revert \"fs/9p: simplify iget to remove unnecessary paths\"", " - soundwire: intel_ace2x: Send PDI stream number during prepare", " - x86: support user address masking instead of non-speculative conditional", " - x86: fix whitespace in runtime-const assembler output", " - x86: fix user address masking non-canonical speculation issue", " - platform/x86: dell-wmi: Ignore suspend notifications", " - ACPI: PRM: Clean up guid type in struct prm_handler_info", " - ASoC: qcom: Select missing common Soundwire module code on SDM845", " - Linux 6.11.6", "", " * ovs/linuxbridge jobs running on ubuntu jammy broken with latest kernel", " 5.15.0-127.137 (LP: #2091990)", " - netfilter: xtables: fix typo causing some targets not to load on IPv6", "", " * By always inlining _compound_head(), clone() sees 3%+ performance increase", " (LP: #2089327)", " - mm: always inline _compound_head() with", " CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP=y", "", " * Keyboard backlight controls do not work on Asus ROG Zephyrus GA503RM in", " Oracular (LP: #2089113)", " - hid-asus: use hid for brightness control on keyboard", "", " * Random flickering with Intel i915 (Comet Lake and Kaby Lake) on Linux 6.8+", " (LP: #2086587)", " - SAUCE: iommu/intel: disable DMAR for KBL and CML integrated gfx", "", " * Add list of source files to linux-buildinfo (LP: #2086606)", " - [Packaging] Sort build dependencies alphabetically", " - [Packaging] Add list of used source files to buildinfo package", "", " * asus: Fix thermal profile initialization on Lunar Lake (LP: #2085950)", " - platform/x86: asus-wmi: Fix thermal profile initialization", "", " * drm/xe: Fix LNL getting wedged after idling (LP: #2085944)", " - drm/xe/guc/ct: Flush g2h worker in case of g2h response timeout", "", " * UFS: uspi->s_3apb UBSAN: shift-out-of-bounds (LP: #2087853)", " - ufs: ufs_sb_private_info: remove unused s_{2, 3}apb fields", "", " * Mute/mic LEDs don't function on HP EliteBook 645 G10 (LP: #2087983)", " - ALSA: hda/realtek: fix mute/micmute LEDs for a HP EliteBook 645 G10", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152)", " - ALSA: scarlett2: Add error check after retrieving PEQ filter values", " - ALSA: hda/conexant - Fix audio routing for HP EliteOne 1000 G2", " - net: enetc: remove xdp_drops statistic from enetc_xdp_drop()", " - net: enetc: block concurrent XDP transmissions during ring reconfiguration", " - net: enetc: disable Tx BD rings after they are empty", " - net: enetc: disable NAPI after all rings are disabled", " - net: enetc: add missing static descriptor and inline keyword", " - udp: Compute L4 checksum as usual when not segmenting the skb", " - arm64: dts: marvell: cn9130-sr-som: fix cp0 mdio pin numbers", " - arm64: probes: Fix simulate_ldr*_literal()", " - net: macb: Avoid 20s boot delay by skipping MDIO bus registration for fixed-", " link PHY", " - selftests: mptcp: join: test for prohibited MPC to port-based endp", " - fat: fix uninitialized variable", " - mm: khugepaged: fix the arguments order in khugepaged_collapse_file trace", " point", " - net: fec: Move `fec_ptp_read()` to the top of the file", " - net: fec: Remove duplicated code", " - mptcp: prevent MPC handshake on port-based signal endpoints", " - s390/sclp: Deactivate sclp after all its users", " - s390/sclp_vt220: Convert newlines to CRLF instead of LFCR", " - KVM: s390: gaccess: Check if guest address is in memslot", " - KVM: s390: Change virtual to physical address access in diag 0x258 handler", " - x86/cpufeatures: Define X86_FEATURE_AMD_IBPB_RET", " - x86/cpufeatures: Add a IBPB_NO_RET BUG flag", " - x86/entry: Have entry_ibpb() invalidate return predictions", " - x86/bugs: Skip RSB fill at VMEXIT", " - x86/bugs: Do not use UNTRAIN_RET with IBPB on entry", " - fgraph: Use CPU hotplug mechanism to initialize idle shadow stacks", " - Input: xpad - add support for 8BitDo Ultimate 2C Wireless Controller", " - io_uring/sqpoll: close race on waiting for sqring entries", " - selftest: hid: add the missing tests directory", " - Input: xpad - add support for MSI Claw A1M", " - scsi: mpi3mr: Validate SAS port assignments", " - scsi: ufs: core: Fix the issue of ICU failure", " - scsi: ufs: core: Requeue aborted request", " - drm/i915/dp_mst: Handle error during DSC BW overhead/slice calculation", " - drm/i915/dp_mst: Don't require DSC hblank quirk for a non-DSC compatible", " mode", " - drm/xe/xe_sync: initialise ufence.signalled", " - drm/xe/ufence: ufence can be signaled right after wait_woken", " - drm/vmwgfx: Cleanup kms setup without 3d", " - drm/vmwgfx: Handle surface check failure correctly", " - drm/amdgpu/mes: fix issue of writing to the same log buffer from 2 MES pipes", " - drm/amdgpu/smu13: always apply the powersave optimization", " - drm/amdgpu/swsmu: Only force workload setup on init", " - drm/amdgpu: prevent BO_HANDLES error from being overwritten", " - iio: dac: ad5770r: add missing select REGMAP_SPI in Kconfig", " - iio: dac: ltc1660: add missing select REGMAP_SPI in Kconfig", " - iio: dac: stm32-dac-core: add missing select REGMAP_MMIO in Kconfig", " - iio: adc: ti-ads8688: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: hid-sensors: Fix an error handling path in", " _hid_sensor_set_report_latency()", " - iio: light: veml6030: fix ALS sensor resolution", " - iio: light: opt3001: add missing full-scale range value", " - iio: amplifiers: ada4250: add missing select REGMAP_SPI in Kconfig", " - iio: frequency: adf4377: add missing select REMAP_SPI in Kconfig", " - iio: chemical: ens160: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: light: bu27008: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: magnetometer: af8133j: add missing select IIO_(TRIGGERED_)BUFFER in", " Kconfig", " - iio: resolver: ad2s1210 add missing select REGMAP in Kconfig", " - iio: pressure: bm1390: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: dac: ad5766: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: proximity: mb1232: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: dac: ad3552r: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: adc: ti-lmp92064: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: adc: ti-lmp92064: add missing select REGMAP_SPI in Kconfig", " - iio: adc: ti-ads124s08: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: resolver: ad2s1210: add missing select (TRIGGERED_)BUFFER in Kconfig", " - iio: adc: ad7944: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - iio: accel: kx022a: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig", " - Bluetooth: Remove debugfs directory on module init failure", " - Bluetooth: btusb: Fix not being able to reconnect after suspend", " - Bluetooth: btusb: Fix regression with fake CSR controllers 0a12:0001", " - xhci: Fix incorrect stream context type macro", " - xhci: Mitigate failed set dequeue pointer commands", " - USB: serial: option: add support for Quectel EG916Q-GL", " - USB: serial: option: add Telit FN920C04 MBIM compositions", " - usb: typec: qcom-pmic-typec: fix sink status being overwritten with RP_DEF", " - usb: gadget: f_uac2: fix return value for UAC2_ATTRIBUTE_STRING store", " - usb: dwc3: Wait for EndXfer completion before restoring GUSB2PHYCFG", " - usb: dwc3: core: Fix system suspend on TI AM62 platforms", " - misc: microchip: pci1xxxx: add support for NVMEM_DEVID_AUTO for EEPROM", " device", " - misc: microchip: pci1xxxx: add support for NVMEM_DEVID_AUTO for OTP device", " - serial: imx: Update mctrl old_status on RTSD interrupt", " - x86/resctrl: Annotate get_mem_config() functions as __init", " - x86/CPU/AMD: Only apply Zenbleed fix for Zen2 during late microcode load", " - x86/entry_32: Do not clobber user EFLAGS.ZF", " - irqchip/sifive-plic: Unmask interrupt in plic_irq_enable()", " - irqchip/sifive-plic: Return error code on failure", " - serial: qcom-geni: fix polled console initialisation", " - serial: qcom-geni: revert broken hibernation support", " - serial: qcom-geni: fix shutdown race", " - serial: qcom-geni: fix dma rx cancellation", " - serial: qcom-geni: fix receiver enable", " - mm: vmscan.c: fix OOM on swap stress test", " - ALSA: hda/conexant - Use cached pin control for Node 0x1d on HP EliteOne", " 1000 G2", " - Linux 6.11.5", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50192", " - irqchip/gic-v4: Don't allow a VMOVP on a dying VPE", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50069", " - pinctrl: apple: check devm_kasprintf() returned value", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50070", " - pinctrl: stm32: check devm_kasprintf() returned value", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50196", " - pinctrl: ocelot: fix system hang on level based interrupts", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50197", " - pinctrl: intel: platform: fix error path in device_for_each_child_node()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50071", " - pinctrl: nuvoton: fix a double free in ma35_pinctrl_dt_node_to_map_func()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50072", " - x86/bugs: Use code segment selector for VERW operand", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50073", " - tty: n_gsm: Fix use-after-free in gsm_cleanup_mux", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50193", " - x86/entry_32: Clear CPU buffers after register restore in NMI return", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50074", " - parport: Proper fix for array out-of-bounds access", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50100", " - USB: gadget: dummy-hcd: Fix \"task hung\" problem", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50075", " - xhci: tegra: fix checked USB2 port number", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50076", " - vt: prevent kernel-infoleak in con_font_get()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50077", " - Bluetooth: ISO: Fix multiple init when debugfs is disabled", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50078", " - Bluetooth: Call iso_exit() on module unload", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50198", " - iio: light: veml6030: fix IIO device retrieval from embedded device", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50201", " - drm/radeon: Fix encoder->possible_clones", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50098", " - scsi: ufs: core: Set SDEV_OFFLINE when UFS is shut down", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50079", " - io_uring/sqpoll: ensure task state is TASK_RUNNING when running task_work", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50080", " - ublk: don't allow user copy for unprivileged device", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50081", " - blk-mq: setup queue ->tag_set before initializing hctx", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50082", " - blk-rq-qos: fix crash on rq_qos_wait vs. rq_qos_wake_function race", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50101", " - iommu/vt-d: Fix incorrect pci_for_each_dma_alias() for non-PCI devices", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50083", " - tcp: fix mptcp DSS corruption due to large pmtu xmit", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50068", " - mm/damon/tests/sysfs-kunit.h: fix memory leak in", " damon_sysfs_test_add_targets()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50199", " - mm/swapfile: skip HugeTLB pages for unuse_vma", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50066", " - mm/mremap: fix move_normal_pmd/retract_page_tables race", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50202", " - nilfs2: propagate directory read errors from nilfs_find_entry()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50200", " - maple_tree: correct tree corruption on spanning store", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50084", " - net: microchip: vcap api: Fix memory leaks in vcap_api_encode_rule_test()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50194", " - arm64: probes: Fix uprobes for big-endian kernels", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50099", " - arm64: probes: Remove broken LDR (literal) uprobe support", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50195", " - posix-clock: Fix missing timespec64 check in pc_clock_settime()", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50085", " - mptcp: pm: fix UaF read in mptcp_pm_nl_rm_addr_or_subflow", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50086", " - ksmbd: fix user-after-free from session log off", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50087", " - btrfs: fix uninitialized pointer free on read_alloc_one_name() error", "", " * Oracular update: v6.11.5 upstream stable release (LP: #2089152) //", " CVE-2024-50088", " - btrfs: fix uninitialized pointer free in add_inode_ref()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068)", " - net: fec: don't save PTP state if PTP is unsupported", " - fs/ntfs3: Do not call file_modified if collapse range failed", " - fs/ntfs3: Optimize large writes into sparse file", " - fs/ntfs3: Fix sparse warning for bigendian", " - fs/ntfs3: Fix sparse warning in ni_fiemap", " - fs/ntfs3: Refactor enum_rstbl to suppress static checker", " - vdpa/octeon_ep: Fix format specifier for pointers in debug messages", " - virtio_console: fix misc probe bugs", " - perf vdso: Missed put on 32-bit dsos", " - perf build: Fix static compilation error when libdw is not installed", " - perf build: Fix build feature-dwarf_getlocations fail for old libdw", " - zram: don't free statically defined names", " - bpf: Call the missed btf_record_free() when map creation fails", " - selftests/bpf: Fix ARG_PTR_TO_LONG {half-,}uninitialized test", " - bpf: Check percpu map value size first", " - s390/facility: Disable compile time optimization for decompressor code", " - s390/mm: Add cond_resched() to cmm_alloc/free_pages()", " - bpf, x64: Fix a jit convergence issue", " - ext4: nested locking for xattr inode", " - s390/cpum_sf: Remove WARN_ON_ONCE statements", " - s390/traps: Handle early warnings gracefully", " - ktest.pl: Avoid false positives with grub2 skip regex", " - soundwire: intel_bus_common: enable interrupts before exiting reset", " - PCI: Add function 0 DMA alias quirk for Glenfly Arise chip", " - clk: bcm: bcm53573: fix OF node leak in init", " - PCI: Add ACS quirk for Qualcomm SA8775P", " - i2c: i801: Use a different adapter-name for IDF adapters", " - PCI: Mark Creative Labs EMU20k2 INTx masking as broken", " - RISC-V: Don't have MAX_PHYSMEM_BITS exceed phys_addr_t", " - mfd: intel_soc_pmic_chtwc: Make Lenovo Yoga Tab 3 X90F DMI match less strict", " - mfd: intel-lpss: Add Intel Panther Lake LPSS PCI IDs", " - riscv: Omit optimized string routines when using KASAN", " - riscv: avoid Imbalance in RAS", " - RDMA/mlx5: Enforce umem boundaries for explicit ODP page faults", " - PCI: qcom: Disable mirroring of DBI and iATU register space in BAR region", " - PCI: endpoint: Assign PCI domain number for endpoint controllers", " - soundwire: cadence: re-check Peripheral status with delayed_work", " - riscv/kexec_file: Fix relocation type R_RISCV_ADD16 and R_RISCV_SUB16", " unknown", " - media: videobuf2-core: clear memory related fields in", " __vb2_plane_dmabuf_put()", " - remoteproc: imx_rproc: Use imx specific hook for find_loaded_rsc_table", " - usb: chipidea: udc: enable suspend interrupt after usb reset", " - usb: dwc2: Adjust the timing of USB Driver Interrupt Registration in the", " Crashkernel Scenario", " - xhci: dbc: Fix STALL transfer event handling", " - usb: host: xhci-plat: Parse xhci-missing_cas_quirk and apply quirk", " - comedi: ni_routing: tools: Check when the file could not be opened", " - LoongArch: Fix memleak in pci_acpi_scan_root()", " - netfilter: nf_nat: don't try nat source port reallocation for reverse dir", " clash", " - netfilter: nf_reject: Fix build warning when CONFIG_BRIDGE_NETFILTER=n", " - tools/iio: Add memory allocation failure check for trigger_name", " - staging: vme_user: added bound check to geoid", " - driver core: bus: Return -EIO instead of 0 when show/store invalid bus", " attribute", " - scsi: lpfc: Add ELS_RSP cmd to the list of WQEs to flush in", " lpfc_els_flush_cmd()", " - scsi: lpfc: Revise TRACE_EVENT log flag severities from KERN_ERR to", " KERN_WARNING", " - NFSD: Mark filecache \"down\" if init fails", " - nfsd: nfsd_destroy_serv() must call svc_destroy() even if nfsd_startup_net()", " failed", " - ice: set correct dst VSI in only LAN filters", " - ice: clear port vlan config during reset", " - ice: disallow DPLL_PIN_STATE_SELECTABLE for dpll output pins", " - ice: fix VLAN replay after reset", " - SUNRPC: Fix integer overflow in decode_rc_list()", " - net: phy: aquantia: AQR115c fix up PMA capabilities", " - net: phy: aquantia: remove usage of phy_set_max_speed", " - tcp: fix to allow timestamp undo if no retransmits were sent", " - tcp: fix tcp_enter_recovery() to zero retrans_stamp when it's safe", " - tcp: fix TFO SYN_RECV to not zero retrans_stamp with retransmits out", " - rxrpc: Fix uninitialised variable in rxrpc_send_data()", " - net: dsa: sja1105: fix reception from VLAN-unaware bridges", " - selftests: net: no_forwarding: fix VID for $swp2 in one_bridge_two_pvids()", " test", " - net: pse-pd: Fix enabled status mismatch", " - Bluetooth: btusb: Don't fail external suspend requests", " - net: phy: bcm84881: Fix some error handling paths", " - net: ethernet: adi: adin1110: Fix some error handling path in", " adin1110_read_fifo()", " - net: dsa: b53: fix jumbo frame mtu check", " - net: dsa: b53: fix max MTU for 1g switches", " - net: dsa: b53: fix max MTU for BCM5325/BCM5365", " - net: dsa: b53: allow lower MTUs on BCM5325/5365", " - net: dsa: b53: fix jumbo frames on 10/100 ports", " - drm/nouveau: pass cli to nouveau_channel_new() instead of drm+device", " - nouveau/dmem: Fix privileged error in copy engine channel", " - gpio: aspeed: Add the flush write to ensure the write complete.", " - gpio: aspeed: Use devm_clk api to manage clock source", " - x86/xen: mark boot CPU of PV guest in MSR_IA32_APICBASE", " - powercap: intel_rapl_tpmi: Ignore minor version change", " - ice: Fix entering Safe Mode", " - ice: Fix netif_is_ice() in Safe Mode", " - ice: Flush FDB entries before reset", " - drm/xe: Restore GT freq on GSC load error", " - drm/xe: Make wedged_mode debugfs writable", " - net: ibm: emac: mal: fix wrong goto", " - net: ti: icssg-prueth: Fix race condition for VLAN table access", " - btrfs: zoned: fix missing RCU locking in error message when loading zone", " info", " - sctp: ensure sk_state is set to CLOSED if hashing fails in sctp_listen_start", " - netfilter: fib: check correct rtable in vrf setups", " - net: ibm: emac: mal: add dcr_unmap to _remove", " - net: dsa: refuse cross-chip mirroring operations", " - rtnetlink: Add bulk registration helpers for rtnetlink message handlers.", " - vxlan: Handle error of rtnl_register_module().", " - bridge: Handle error of rtnl_register_module().", " - mctp: Handle error of rtnl_register_module().", " - mpls: Handle error of rtnl_register_module().", " - phonet: Handle error of rtnl_register_module().", " - rcu/nocb: Fix rcuog wake-up from offline softirq", " - HID: multitouch: Add support for lenovo Y9000P Touchpad", " - hwmon: intel-m10-bmc-hwmon: relabel Columbiaville to CVL Die Temperature", " - hwmon: (tmp513) Add missing dependency on REGMAP_I2C", " - hwmon: (mc34vr500) Add missing dependency on REGMAP_I2C", " - hwmon: (adm9240) Add missing dependency on REGMAP_I2C", " - hwmon: (adt7470) Add missing dependency on REGMAP_I2C", " - hwmon: (ltc2991) Add missing dependency on REGMAP_I2C", " - HID: plantronics: Workaround for an unexcepted opposite volume key", " - HID: wacom: Hardcode (non-inverted) AES pens as BTN_TOOL_PEN", " - Revert \"usb: yurex: Replace snprintf() with the safer scnprintf() variant\"", " - usb: dwc3: core: Stop processing of pending events if controller is halted", " - usb: xhci: Fix problem with xhci resume from suspend", " - usb: storage: ignore bogus device raised by JieLi BR21 USB sound chip", " - usb: dwc3: re-enable runtime PM after failed resume", " - usb: gadget: core: force synchronous registration", " - hid: intel-ish-hid: Fix uninitialized variable 'rv' in", " ish_fw_xfer_direct_dma", " - ACPI: resource: Make Asus ExpertBook B2402 matches cover more models", " - ACPI: resource: Make Asus ExpertBook B2502 matches cover more models", " - drm/amdgpu: partially revert powerplay `__counted_by` changes", " - drm/amd/display: Clear update flags after update has been applied", " - drm/amdkfd: Fix an eviction fence leak", " - drm/amd/display: fix hibernate entry for DCN35+", " - drm/xe/guc_submit: fix xa_store() error checking", " - drm/i915/hdcp: fix connector refcounting", " - drm/xe/ct: fix xa_store() error checking", " - scsi: ufs: Use pre-calculated offsets in ufshcd_init_lrb()", " - Revert \"mmc: mvsdio: Use sg_miter for PIO\"", " - mmc: sdhci-of-dwcmshc: Prevent stale command interrupt handling", " - mptcp: fallback when MPTCP opts are dropped after 1st data", " - ata: libata: avoid superfluous disk spin down + spin up during hibernation", " - OPP: fix error code in dev_pm_opp_set_config()", " - net: dsa: lan9303: ensure chip reset and wait for READY status", " - net: phy: realtek: Fix MMD access on RTL8126A-integrated PHY", " - mptcp: pm: do not remove closing subflows", " - powercap: intel_rapl_tpmi: Fix bogus register reading", " - selftests/mm: fix incorrect buffer->mirror size in hmm2 double_map test", " - selftests/rseq: Fix mm_cid test failure", " - btrfs: split remaining space to discard in chunks", " - btrfs: add cancellation points to trim loops", " - PM: domains: Fix alloc/free in dev_pm_domain_attach|detach_list()", " - idpf: use actual mbx receive payload length", " - fs/proc/kcore.c: allow translation of physical memory addresses", " - PCI: Pass domain number to pci_bus_release_domain_nr() explicitly", " - io_uring/rw: fix cflags posting for single issue multishot read", " - Linux 6.11.4", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50182", " - secretmem: disable memfd_secret() if arch cannot set direct map", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50019", " - kthread: unpark only parked kthread", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50096", " - nouveau/dmem: Fix vulnerability in migrate_to_ram upon copy error", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50020", " - ice: Fix improper handling of refcount in ice_sriov_set_msix_vec_count()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50021", " - ice: Fix improper handling of refcount in ice_dpll_init_rclk_pins()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50022", " - device-dax: correct pgoff align in dax_set_mapping()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50185", " - mptcp: handle consistently DSS corruption", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50023", " - net: phy: Remove LED entry from LEDs list on unregister", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50024", " - net: Fix an unsafe loop on the list", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50186", " - net: explicitly clear the sk pointer, when pf->create fails", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50025", " - scsi: fnic: Move flush_work initialization out of if block", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50026", " - scsi: wd33c93: Don't use stale scsi_pointer value", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50027", " - thermal: core: Free tzp copy along with the thermal zone", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50028", " - thermal: core: Reference count the zone in thermal_zone_get_by_id()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50029", " - Bluetooth: hci_conn: Fix UAF in hci_enhanced_setup_sync", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50030", " - drm/xe/ct: prevent UAF in send_recv()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50187", " - drm/vc4: Stop the active perfmon before being destroyed", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50031", " - drm/v3d: Stop the active perfmon before being destroyed", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50189", " - HID: amd_sfh: Switch to device-managed dmam_alloc_coherent()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50033", " - slip: make slhc_remember() more robust against malicious packets", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50034", " - net/smc: fix lacks of icsk_syn_mss with IPPROTO_SMC", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50035", " - ppp: fix ppp_async_encode() illegal access", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50036", " - net: do not delay dst_entries_add() in dst_release()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50037", " - drm/fbdev-dma: Only cleanup deferred I/O if necessary", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50092", " - net: netconsole: fix wrong warning", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50038", " - netfilter: xtables: avoid NFPROTO_UNSPEC where needed", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50039", " - net/sched: accept TCA_STAB only for root qdisc", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50040", " - igb: Do not bring the device up after non-fatal error", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50041", " - i40e: Fix macvlan leak by synchronizing access to mac_filter_hash", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50042", " - ice: Fix increasing MSI-X on VF", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50093", " - thermal: intel: int340x: processor: Fix warning during module unload", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50043", " - nfsd: fix possible badness in FREE_STATEID", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50044", " - Bluetooth: RFCOMM: FIX possible deadlock in rfcomm_sk_state_change", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50045", " - netfilter: br_netfilter: fix panic with metadata_dst skb", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50094", " - sfc: Don't invoke xdp_do_flush() from netpoll.", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50188", " - net: phy: dp83869: fix memory corruption when enabling fiber", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50046", " - NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50190", " - ice: fix memleak in ice_init_tx_topology()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50180", " - fbdev: sisfb: Fix strbuf array overflow", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50047", " - smb: client: fix UAF in async decryption", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50048", " - fbcon: Fix a NULL pointer dereference issue in fbcon_putcs", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50049", " - drm/amd/display: Check null pointer before dereferencing se", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50090", " - drm/xe/oa: Fix overflow in oa batch buffer", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50183", " - scsi: lpfc: Ensure DA_ID handling completion before deleting an NPIV", " instance", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50055", " - driver core: bus: Fix double free in driver API bus_register()", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50091", " - dm vdo: don't refer to dedupe_context after releasing it", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50056", " - usb: gadget: uvc: Fix ERR_PTR dereference in uvc_v4l2.c", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50184", " - virtio_pmem: Check device status before requesting flush", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50057", " - usb: typec: tipd: Free IRQ only if it was requested before", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50058", " - serial: protect uart_port_dtr_rts() in uart_shutdown() too", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50181", " - clk: imx: Remove CLK_SET_PARENT_GATE for DRAM mux for i.MX7D", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50059", " - ntb: ntb_hw_switchtec: Fix use after free vulnerability in", " switchtec_ntb_remove due to race condition", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50060", " - io_uring: check if we need to reschedule during overflow flush", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50061", " - i3c: master: cdns: Fix use after free vulnerability in cdns_i3c_master", " Driver Due to Race Condition", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50062", " - RDMA/rtrs-srv: Avoid null pointer deref during path establishment", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50095", " - RDMA/mad: Improve handling of timed out WRs of mad agent", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50063", " - bpf: Prevent tail call between progs attached to different hooks", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50191", " - ext4: don't set SB_RDONLY after filesystem errors", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50064", " - zram: free secondary algorithms names", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50065", " - ntfs3: Change to non-blocking allocation in ntfs_d_hash", "", " * Oracular update: v6.11.4 upstream stable release (LP: #2089068) //", " CVE-2024-50089", " - unicode: Don't special case ignorable code points", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052)", " - jump_label: Fix static_key_slow_dec() yet again", " - scsi: st: Fix input/output error on empty drive reset", " - scsi: pm8001: Do not overwrite PCI queue mapping", " - drm/i915/psr: Do not wait for PSR being idle on on Panel Replay", " - drm/i915/display: BMG supports UHBR13.5", " - drm/i915/dp: Fix AUX IO power enabling for eDP PSR", " - drm/amdgpu: Fix get each xcp macro", " - drm/amd/display: handle nulled pipe context in DCE110's set_drr()", " - ksmbd: fix warning: comparison of distinct pointer types lacks a cast", " - mailbox: ARM_MHU_V3 should depend on ARM64", " - [Config] updateconfigs for ARM_MHU_V3", " - mailbox: rockchip: fix a typo in module autoloading", " - ceph: fix a memory leak on cap_auths in MDS client", " - drm/i915/dp: Fix colorimetry detection", " - ieee802154: Fix build error", " - net: sparx5: Fix invalid timestamps", " - net/mlx5: Added cond_resched() to crdump collection", " - net/mlx5e: SHAMPO, Fix overflow of hd_per_wq", " - netfilter: uapi: NFTA_FLOWTABLE_HOOK is NLA_NESTED", " - net: ieee802154: mcr20a: Use IRQF_NO_AUTOEN flag in request_irq()", " - net: wwan: qcom_bam_dmux: Fix missing pm_runtime_disable()", " - selftests: netfilter: Fix nft_audit.sh for newer nft binaries", " - selftests: netfilter: Add missing return value", " - Bluetooth: btmrvl: Use IRQF_NO_AUTOEN flag in request_irq()", " - afs: Fix missing wire-up of afs_retry_request()", " - net: Add netif_get_gro_max_size helper for GRO", " - net: Fix gso_features_check to check for both dev->gso_{ipv4_,}max_size", " - net: fec: Restart PPS after link state change", " - net: fec: Reload PTP registers after link-state change", " - net: stmmac: dwmac4: extend timeout for VLAN Tag register busy bit check", " - ipv4: ip_gre: Fix drops of small packets in ipgre_xmit", " - netfs: Fix missing wakeup after issuing writes", " - net: phy: realtek: Check the index value in led_hw_control_get", " - bridge: mcast: Fail MDB get request on empty entry", " - iomap: constrain the file range passed to iomap_file_unshare", " - dt-bindings: net: xlnx,axi-ethernet: Add missing reg minItems", " - ASoC: topology: Fix incorrect addressing assignments", " - ASoC: atmel: mchp-pdmc: Skip ALSA restoration if substream runtime is", " uninitialized", " - drm/connector: hdmi: Fix writing Dynamic Range Mastering infoframes", " - io_uring: fix memory leak when cache init fail", " - rust: kbuild: split up helpers.c", " - rust: kbuild: auto generate helper exports", " - rust: mutex: fix __mutex_init() usage in case of PREEMPT_RT", " - ALSA: mixer_oss: Remove some incorrect kfree_const() usages", " - ALSA: hda/realtek: Fix the push button function for the ALC257", " - cifs: Remove intermediate object of failed create reparse call", " - drm/panthor: Lock the VM resv before calling drm_gpuvm_bo_obtain_prealloc()", " - ALSA: hda/generic: Unconditionally prefer preferred_dacs pairs", " - ASoC: imx-card: Set card.owner to avoid a warning calltrace if SND=m", " - drm/xe: Restore pci state upon resume", " - drm/xe: Resume TDR after GT reset", " - cifs: Do not convert delimiter when parsing NFS-style symlinks", " - tools/rtla: Fix installation from out-of-tree build", " - ALSA: gus: Fix some error handling paths related to get_bpos() usage", " - ALSA: hda/conexant: Fix conflicting quirk for System76 Pangolin", " - drm/amd/display: Disable replay if VRR capability is false", " - drm/amd/display: Fix VRR cannot enable", " - drm/amd/display: Re-enable panel replay feature", " - e1000e: avoid failing the system during pm_suspend", " - wifi: ath9k: fix possible integer overflow in ath9k_get_et_stats()", " - crypto: x86/sha256 - Add parentheses around macros' single arguments", " - crypto: octeontx - Fix authenc setkey", " - crypto: octeontx2 - Fix authenc setkey", " - ice: Adjust over allocation of memory in ice_sched_add_root_node() and", " ice_sched_add_node()", " - wifi: iwlwifi: mvm: Fix a race in scan abort flow", " - wifi: iwlwifi: mvm: drop wrong STA selection in TX", " - net: hisilicon: hip04: fix OF node leak in probe()", " - net: hisilicon: hns_dsaf_mac: fix OF node leak in hns_mac_get_info()", " - net: hisilicon: hns_mdio: fix OF node leak in probe()", " - ACPICA: Fix memory leak if acpi_ps_get_next_namepath() fails", " - ACPICA: Fix memory leak if acpi_ps_get_next_field() fails", " - ACPI: resource: Skip IRQ override on Asus Vivobook Go E1404GAB", " - wifi: mt76: mt7915: disable tx worker during tx BA session enable/disable", " - net: sched: consistently use rcu_replace_pointer() in taprio_change()", " - Bluetooth: btusb: Add Realtek RTL8852C support ID 0x0489:0xe122", " - Bluetooth: btrtl: Set msft ext address filter quirk for RTL8852B", " - ACPI: video: Add force_vendor quirk for Panasonic Toughbook CF-18", " - ACPI: CPPC: Add support for setting EPP register in FFH", " - wifi: rtw88: select WANT_DEV_COREDUMP", " - l2tp: free sessions using rcu", " - l2tp: use rcu list add/del when updating lists", " - ACPI: EC: Do not release locks during operation region accesses", " - net: skbuff: sprinkle more __GFP_NOWARN on ingress allocs", " - net: mvpp2: Increase size of queue_name buffer", " - bnxt_en: Extend maximum length of version string by 1 byte", " - ipv4: Check !in_dev earlier for ioctl(SIOCSIFADDR).", " - wifi: rtw89: correct base HT rate mask for firmware", " - netfilter: nf_tables: do not remove elements if set backend implements", " .abort", " - ipv4: Mask upper DSCP bits and ECN bits in NETLINK_FIB_LOOKUP family", " - nvme-keyring: restrict match length for version '1' identifiers", " - nvme-tcp: sanitize TLS key handling", " - nvme-tcp: check for invalidated or revoked key", " - net: atlantic: Avoid warning about potential string truncation", " - crypto: simd - Do not call crypto_alloc_tfm during registration", " - netpoll: Ensure clean state on setup failures", " - tcp: avoid reusing FIN_WAIT2 when trying to find port in connect() process", " - wifi: iwlwifi: mvm: use correct key iteration", " - wifi: iwlwifi: allow only CN mcc from WRDD", " - virt: sev-guest: Ensure the SNP guest messages do not exceed a page", " - wifi: mac80211: fix RCU list iterations", " - ACPICA: iasl: handle empty connection_node", " - proc: add config & param to block forcing mem writes", " - [Config] updateconfigs to select PROC_MEM_ALWAYS_FORCE", " - vfs: use RCU in ilookup", " - drivers/perf: arm_spe: Use perf_allow_kernel() for permissions", " - nvme: fix metadata handling in nvme-passthrough", " - can: netlink: avoid call to do_set_data_bittiming callback with stale", " can_priv::ctrlmode", " - netdev-genl: Set extack and fix error on napi-get", " - wifi: wilc1000: Do not operate uninitialized hardware during suspend/resume", " - arm64: trans_pgd: mark PTEs entries as valid to avoid dead kexec()", " - net: phy: Check for read errors in SIOCGMIIREG", " - x86/bugs: Add missing NO_SSB flag", " - x86/bugs: Fix handling when SRSO mitigation is disabled", " - crypto: hisilicon - fix missed error branch", " - wifi: mt76: mt7915: add dummy HW offload of IEEE 802.11 fragmentation", " - wifi: mt76: mt7915: hold dev->mt76.mutex while disabling tx worker", " - netfs: Cancel dirty folios that have no storage destination", " - nfp: Use IRQF_NO_AUTOEN flag in request_irq()", " - ALSA: usb-audio: Add input value sanity checks for standard types", " - x86/apic: Remove logical destination mode for 64-bit", " - ALSA: usb-audio: Define macros for quirk table entries", " - ALSA: usb-audio: Replace complex quirk lines with macros", " - ALSA: usb-audio: Add quirk for RME Digiface USB", " - ALSA: usb-audio: Add mixer quirk for RME Digiface USB", " - ALSA: hda/realtek: Refactor and simplify Samsung Galaxy Book init", " - ALSA: usb-audio: Add logitech Audio profile quirk", " - ASoC: codecs: wsa883x: Handle reading version failure", " - ALSA: control: Take power_ref lock primarily", " - tools/x86/kcpuid: Protect against faulty \"max subleaf\" values", " - x86/pkeys: Add PKRU as a parameter in signal handling functions", " - x86/pkeys: Restore altstack access in sigreturn()", " - x86/kexec: Add EFI config table identity mapping for kexec kernel", " - ALSA: hdsp: Break infinite MIDI input flush loop", " - tools/nolibc: powerpc: limit stack-protector workaround to GCC", " - selftests/nolibc: avoid passing NULL to printf(\"%s\")", " - x86/syscall: Avoid memcpy() for ia32 syscall_get_arguments()", " - ASoC: Intel: boards: always check the result of", " acpi_dev_get_first_match_dev()", " - hwmon: (nct6775) add G15CF to ASUS WMI monitoring list", " - pmdomain: core: Don't hold the genpd-lock when calling dev_pm_domain_set()", " - pmdomain: core: Use dev_name() instead of kobject_get_path() in debugfs", " - rcuscale: Provide clear error when async specified without primitives", " - power: reset: brcmstb: Do not go into infinite loop if reset fails", " - iommu/arm-smmu-v3: Match Stall behaviour for S2", " - iommu/vt-d: Always reserve a domain ID for identity setup", " - iommu/vt-d: Unconditionally flush device TLB for pasid table updates", " - iommu/arm-smmu-v3: Do not use devm for the cd table allocations", " - drm/amdgpu: disallow multiple BO_HANDLES chunks in one submit", " - drm/amd/display: Use gpuvm_min_page_size_kbytes for DML2 surfaces", " - ata: pata_serverworks: Do not use the term blacklist", " - ata: sata_sil: Rename sil_blacklist to sil_quirks", " - selftests/bpf: fix uprobe.path leak in bpf_testmod", " - scsi: smartpqi: Add new controller PCI IDs", " - HID: Ignore battery for all ELAN I2C-HID devices", " - drm/amd/display: Underflow Seen on DCN401 eGPU", " - drm/xe: Name and document Wa_14019789679", " - jfs: UBSAN: shift-out-of-bounds in dbFindBits", " - scsi: smartpqi: correct stream detection", " - scsi: smartpqi: add new controller PCI IDs", " - drm/amdgpu: add raven1 gfxoff quirk", " - drm/amdgpu: enable gfxoff quirk on HP 705G4", " - drm/amdkfd: Fix resource leak in criu restore queue", " - HID: multitouch: Add support for Thinkpad X12 Gen 2 Kbd Portfolio", " - platform/x86: touchscreen_dmi: add nanote-next quirk", " - platform/x86/amd: pmf: Add quirk for TUF Gaming A14", " - drm/stm: ltdc: reset plane transparency after plane disable", " - drm/amdgpu/gfx12: properly handle error ints on all pipes", " - drm/amdgpu/gfx9: properly handle error ints on all pipes", " - drm/amd/display: Fix possible overflow in integer multiplication", " - drm/printer: Allow NULL data in devcoredump printer", " - perf,x86: avoid missing caller address in stack traces captured in uprobe", " - scsi: aacraid: Rearrange order of struct aac_srb_unit", " - scsi: lpfc: Fix unsolicited FLOGI kref imbalance when in direct attached", " topology", " - scsi: lpfc: Update PRLO handling in direct attached topology", " - drm/amd/display: Force enable 3DLUT DMA check for dcn401 in DML", " - drm/amdgpu: fix unchecked return value warning for amdgpu_gfx", " - drm/amdgpu: fix unchecked return value warning for amdgpu_atombios", " - perf: Fix event_function_call() locking", " - scsi: NCR5380: Initialize buffer for MSG IN and STATUS transfers", " - drm/radeon/r100: Handle unknown family in r100_cp_init_microcode()", " - drm/amd/display: Unlock Pipes Based On DET Allocation", " - drm/amdgpu: fix ptr check warning in gfx9 ip_dump", " - drm/amdgpu: fix ptr check warning in gfx10 ip_dump", " - drm/amdgpu: fix ptr check warning in gfx11 ip_dump", " - drm/amdgpu: Block MMR_READ IOCTL in reset", " - drm/amdgpu/gfx9: use rlc safe mode for soft recovery", " - drm/amdgpu/gfx11: enter safe mode before touching CP_INT_CNTL", " - drm/xe: Use topology to determine page fault queue size", " - drm/amdkfd: Check int source id for utcl2 poison event", " - of/irq: Refer to actual buffer size in of_irq_parse_one()", " - drm/amd/display: guard write a 0 post_divider value to HW", " - powerpc/pseries: Use correct data types from pseries_hp_errorlog struct", " - ovl: fsync after metadata copy-up", " - drm/amdgpu/gfx12: use rlc safe mode for soft recovery", " - drm/amdgpu/gfx11: use rlc safe mode for soft recovery", " - drm/amdgpu/gfx10: use rlc safe mode for soft recovery", " - platform/x86: lenovo-ymc: Ignore the 0x0 state", " - tools/hv: Add memory allocation check in hv_fcopy_start", " - HID: i2c-hid: ensure various commands do not interfere with each other", " - platform/mellanox: mlxbf-pmc: fix lockdep warning", " - platform/x86: x86-android-tablets: Adjust Xiaomi Pad 2 bottom bezel touch", " buttons LED", " - bpf: Make the pointer returned by iter next method valid", " - ext4: ext4_search_dir should return a proper error", " - bpftool: Fix undefined behavior caused by shifting into the sign bit", " - iomap: handle a post-direct I/O invalidate race in", " iomap_write_delalloc_release", " - EINJ, CXL: Fix CXL device SBDF calculation", " - spi: spi-imx: Fix pm_runtime_set_suspended() with runtime pm enabled", " - spi: spi-cadence: Fix pm_runtime_set_suspended() with runtime pm enabled", " - spi: spi-cadence: Fix missing spi_controller_is_target() check", " - selftest: hid: add missing run-hid-tools-tests.sh", " - spi: s3c64xx: fix timeout counters in flush_fifo", " - kselftest/devices/probe: Fix SyntaxWarning in regex strings for Python3", " - selftests: breakpoints: use remaining time to check if suspend succeed", " - accel/ivpu: Add missing MODULE_FIRMWARE metadata", " - spi: rpc-if: Add missing MODULE_DEVICE_TABLE", " - ALSA: control: Fix power_ref lock order for compat code, too", " - perf callchain: Fix stitch LBR memory leaks", " - perf: Really fix event_function_call() locking", " - drm/xe: fixup xe_alloc_pf_queue", " - drm/xe: Fix memory leak on xe_alloc_pf_queue failure", " - selftests: vDSO: fix vDSO name for powerpc", " - selftests: vDSO: fix vdso_config for powerpc", " - selftests: vDSO: fix vDSO symbols lookup for powerpc64", " - ext4: fix error message when rejecting the default hash", " - selftests/mm: fix charge_reserved_hugetlb.sh test", " - nvme-tcp: fix link failure for TCP auth", " - f2fs: add write priority option based on zone UFS", " - powerpc/vdso: Fix VDSO data access when running in a non-root time namespace", " - selftests: vDSO: fix ELF hash table entry size for s390x", " - selftests: vDSO: fix vdso_config for s390", " - f2fs: make BG GC more aggressive for zoned devices", " - f2fs: introduce migration_window_granularity", " - f2fs: increase BG GC migration window granularity when boosted for zoned", " devices", " - f2fs: do FG_GC when GC boosting is required for zoned devices", " - f2fs: forcibly migrate to secure space for zoned device file pinning", " - Revert \"ALSA: hda: Conditionally use snooping for AMD HDMI\"", " - KVM: arm64: Fix kvm_has_feat*() handling of negative features", " - i2c: qcom-geni: Use IRQF_NO_AUTOEN flag in request_irq()", " - i2c: xiic: Wait for TX empty to avoid missed TX NAKs", " - i2c: core: Lock address during client device instantiation", " - i2c: xiic: Fix pm_runtime_set_suspended() with runtime pm enabled", " - i2c: designware: fix controller is holding SCL low while ENABLE bit is", " disabled", " - i2c: synquacer: Deal with optional PCLK correctly", " - rust: sync: require `T: Sync` for `LockedBy::access`", " - ovl: fail if trusted xattrs are needed but caller lacks permission", " - firmware: tegra: bpmp: Drop unused mbox_client_to_bpmp()", " - memory: tegra186-emc: drop unused to_tegra186_emc()", " - dt-bindings: clock: exynos7885: Fix duplicated binding", " - spi: bcm63xx: Fix module autoloading", " - spi: bcm63xx: Fix missing pm_runtime_disable()", " - power: supply: hwmon: Fix missing temp1_max_alarm attribute", " - power: supply: Drop use_cnt check from power_supply_property_is_writeable()", " - perf/core: Fix small negative period being ignored", " - drm/v3d: Prevent out of bounds access in performance query extensions", " - parisc: Fix itlb miss handler for 64-bit programs", " - drm/mediatek: ovl_adaptor: Add missing of_node_put()", " - drm: Consistently use struct drm_mode_rect for FB_DAMAGE_CLIPS", " - ALSA: hda/tas2781: Add new quirk for Lenovo Y990 Laptop", " - ALSA: core: add isascii() check to card ID generator", " - ALSA: usb-audio: Add delay quirk for VIVO USB-C HEADSET", " - ALSA: usb-audio: Add native DSD support for Luxman D-08u", " - ALSA: line6: add hw monitor volume control to POD HD500X", " - ALSA: hda/realtek: fix mute/micmute LED for HP mt645 G8", " - ALSA: hda/realtek: Add quirk for Huawei MateBook 13 KLV-WX9", " - ALSA: hda/realtek: Add a quirk for HP Pavilion 15z-ec200", " - ext4: correct encrypted dentry name hash when not casefolded", " - ext4: propagate errors from ext4_find_extent() in ext4_insert_range()", " - ext4: fix incorrect tid assumption in ext4_fc_mark_ineligible()", " - ext4: fix incorrect tid assumption in __jbd2_log_wait_for_space()", " - ext4: fix incorrect tid assumption in ext4_wait_for_tail_page_commit()", " - ext4: fix incorrect tid assumption in jbd2_journal_shrink_checkpoint_list()", " - ext4: fix fast commit inode enqueueing during a full journal commit", " - ext4: use handle to mark fc as ineligible in __track_dentry_update()", " - ext4: mark fc as ineligible using an handle in ext4_xattr_set()", " - parisc: Fix 64-bit userspace syscall path", " - parisc: Allow mmap(MAP_STACK) memory to automatically expand upwards", " - parisc: Fix stack start for ADDR_NO_RANDOMIZE personality", " - drm/rockchip: vop: clear DMA stop bit on RK3066", " - of: address: Report error on resource bounds overflow", " - of/irq: Support #msi-cells=<0> in of_msi_get_domain", " - lib/buildid: harden build ID parsing logic", " - jbd2: correctly compare tids with tid_geq function in jbd2_fc_begin_commit", " - mm: krealloc: consider spare memory for __GFP_ZERO", " - ocfs2: fix the la space leak when unmounting an ocfs2 volume", " - ocfs2: fix uninit-value in ocfs2_get_block()", " - scripts/gdb: fix timerlist parsing issue", " - scripts/gdb: add iteration function for rbtree", " - scripts/gdb: fix lx-mounts command error", " - arm64: fix selection of HAVE_DYNAMIC_FTRACE_WITH_ARGS", " - arm64: Subscribe Microsoft Azure Cobalt 100 to erratum 3194386", " - drm/xe/oa: Don't reset OAC_CONTEXT_ENABLE on OA stream close", " - sched/deadline: Comment sched_dl_entity::dl_server variable", " - sched/core: Add clearing of ->dl_server in put_prev_task_balance()", " - sched/core: Clear prev->dl_server in CFS pick fast path", " - sched: psi: fix bogus pressure spikes from aggregation race", " - riscv: define ILLEGAL_POINTER_VALUE for 64bit", " - [Config] updateconfigs for ILLEGAL_POINTER_VALUE on riscv", " - perf python: Disable -Wno-cast-function-type-mismatch if present on clang", " - perf hist: Update hist symbol when updating maps", " - nfsd: fix delegation_blocked() to block correctly for at least 30 seconds", " - NFSD: Fix NFSv4's PUTPUBFH operation", " - sysctl: avoid spurious permanent empty tables", " - RDMA/mana_ib: use the correct page table index based on hardware page size", " - RDMA/mana_ib: use the correct page size for mapping user-mode doorbell page", " - drivers/perf: riscv: Align errno for unsupported perf event", " - riscv: Fix kernel stack size when KASAN is enabled", " - media: imx335: Fix reset-gpio handling", " - clk: rockchip: fix error for unknown clocks", " - leds: pca9532: Remove irrelevant blink configuration error message", " - media: videobuf2: Drop minimum allocation requirement of 2 buffers", " - clk: qcom: dispcc-sm8250: use CLK_SET_RATE_PARENT for branch clocks", " - media: sun4i_csi: Implement link validate for sun4i_csi subdev", " - clk: qcom: gcc-sm8450: Do not turn off PCIe GDSCs during gdsc_disable()", " - media: uapi/linux/cec.h: cec_msg_set_reply_to: zero flags", " - dt-bindings: clock: qcom: Add GPLL9 support on gcc-sc8180x", " - clk: qcom: gcc-sc8180x: Register QUPv3 RCGs for DFS on sc8180x", " - clk: qcom: clk-rpmh: Fix overflow in BCM vote", " - clk: samsung: exynos7885: Update CLKS_NR_FSYS after bindings fix", " - clk: qcom: gcc-sm8150: De-register gcc_cpuss_ahb_clk_src", " - clk: qcom: gcc-sm8250: Do not turn off PCIe GDSCs during gdsc_disable()", " - clk: qcom: gcc-sc8180x: Add GPLL9 support", " - clk: qcom: gcc-sc8180x: Fix the sdcc2 and sdcc4 clocks freq table", " - clk: qcom: clk-alpha-pll: Fix CAL_L_VAL override for LUCID EVO PLL", " - drm/amd/display: avoid set dispclk to 0", " - smb: client: use actual path when queryfs", " - smb3: fix incorrect mode displayed for read-only files", " - iio: magnetometer: ak8975: Fix reading for ak099xx sensors", " - iio: pressure: bmp280: Fix regmap for BMP280 device", " - iio: pressure: bmp280: Fix waiting time for BMP3xx configuration", " - tomoyo: fallback to realpath if symlink's pathname does not exist", " - kselftests: mm: fix wrong __NR_userfaultfd value", " - rtc: at91sam9: fix OF node leak in probe() error path", " - mm/hugetlb: fix memfd_pin_folios resv_huge_pages leak", " - mm/gup: fix memfd_pin_folios hugetlb page allocation", " - mm/hugetlb: simplify refs in memfd_alloc_folio", " - Input: adp5589-keys - fix adp5589_gpio_get_value()", " - HID: bpf: fix cfi stubs for hid_bpf_ops", " - pidfs: check for valid pid namespace", " - ACPI: video: Add backlight=native quirk for Dell OptiPlex 5480 AIO", " - ACPI: resource: Remove duplicate Asus E1504GAB IRQ override", " - ACPI: resource: Loosen the Asus E1404GAB DMI match to also cover the E1404GA", " - ACPI: resource: Add Asus Vivobook X1704VAP to irq1_level_low_skip_override[]", " - ACPI: resource: Add Asus ExpertBook B2502CVA to", " irq1_level_low_skip_override[]", " - btrfs: drop the backref cache during relocation if we commit", " - btrfs: send: fix invalid clone operation for file that got its size", " decreased", " - cpufreq: intel_pstate: Make hwp_notify_lock a raw spinlock", " - gpio: davinci: fix lazy disable", " - net: pcs: xpcs: fix the wrong register that was written back", " - Bluetooth: hci_event: Align BR/EDR JUST_WORKS paring with LE", " - io_uring/net: harden multishot termination case for recv", " - ceph: fix cap ref leak via netfs init_request", " - tracing/hwlat: Fix a race during cpuhp processing", " - tracing/timerlat: Fix duplicated kthread creation due to CPU online/offline", " - rtla: Fix the help text in osnoise and timerlat top tools", " - firmware/sysfb: Disable sysfb for firmware buffers with unknown parent", " - close_range(): fix the logics in descriptor table trimming", " - drm/i915/gem: fix bitwise and logical AND mixup", " - drm/panthor: Don't add write fences to the shared BOs", " - drm/panthor: Don't declare a queue blocked if deferred operations are", " pending", " - drm/sched: Fix dynamic job-flow control race", " - drm/sched: Add locking to drm_sched_entity_modify_sched", " - drm/sched: Always wake up correct scheduler in drm_sched_entity_push_job", " - drm/sched: Always increment correct scheduler score", " - drm/amd/display: Restore Optimized pbn Value if Failed to Disable DSC", " - drm/amd/display: Add HDR workaround for specific eDP", " - drm/amd/display: Enable idle workqueue for more IPS modes", " - kconfig: fix infinite loop in sym_calc_choice()", " - kconfig: qconf: move conf_read() before drawing tree pain", " - kconfig: qconf: fix buffer overflow in debug links", " - arm64: cputype: Add Neoverse-N3 definitions", " - arm64: errata: Expand speculative SSBS workaround once more", " - mm: z3fold: deprecate CONFIG_Z3FOLD", " - [Config] updateconfigs after deprecating Z3FOLD", " - drm/amd/display: Allow backlight to go below", " `AMDGPU_DM_DEFAULT_MIN_BACKLIGHT`", " - sunrpc: change sp_nrthreads from atomic_t to unsigned int.", " - NFSD: Async COPY result needs to return a write verifier", " - remoteproc: k3-r5: Acquire mailbox handle during probe routine", " - remoteproc: k3-r5: Delay notification of wakeup event", " - r8169: Fix spelling mistake: \"tx_underun\" -> \"tx_underrun\"", " - ACPI: battery: Simplify battery hook locking", " - drm/xe: Clean up VM / exec queue file lock usage.", " - drm/rockchip: vop: enable VOP_FEATURE_INTERNAL_RGB on RK3066", " - drm/xe/vram: fix ccs offset calculation", " - drm/sched: revert \"Always increment correct scheduler score\"", " - ALSA: control: Fix leftover snd_power_unref()", " - crypto: octeontx* - Select CRYPTO_AUTHENC", " - drm/amd/display: Revert Avoid overflow assignment", " - perf report: Fix segfault when 'sym' sort key is not used", " - pmdomain: core: Reduce debug summary table width", " - perf python: Allow checking for the existence of warning options in clang", " - Linux 6.11.3", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49863", " - vhost/scsi: null-ptr-dereference in vhost_scsi_get_req()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49864", " - rxrpc: Fix a race between socket set up and I/O thread creation", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49865", " - drm/xe/vm: move xa_alloc to prevent UAF", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49955", " - ACPI: battery: Fix possible crash when unregistering a battery hook", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49973", " - r8169: add tally counter fields added with RTL8125", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49974", " - NFSD: Limit the number of concurrent async COPY operations", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49975", " - uprobes: fix kernel info leak via \"[uprobes]\" vma", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50003", " - drm/amd/display: Fix system hang while resume with TBT monitor", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50173", " - drm/panthor: Fix access to uninitialized variable in tick_ctx_cleanup()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49866", " - tracing/timerlat: Fix a race during cpuhp processing", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49976", " - tracing/timerlat: Drop interface_lock in stop_kthread()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50005", " - mac802154: Fix potential RCU dereference issue in mac802154_scan_worker", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50012", " - cpufreq: Avoid a bad reference count on CPU node", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49867", " - btrfs: wait for fixup workers before stopping cleaner kthread during umount", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49868", " - btrfs: fix a NULL pointer dereference when failed to start a new trasacntion", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49869", " - btrfs: send: fix buffer overflow detection when copying path to cache entry", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49870", " - cachefiles: fix dentry leak in cachefiles_open_file()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49871", " - Input: adp5589-keys - fix NULL pointer dereference", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49872", " - mm/gup: fix memfd_pin_folios alloc race panic", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49964", " - mm/hugetlb: fix memfd_pin_folios free_huge_pages leak", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49873", " - mm/filemap: fix filemap_get_folios_contig THP panic", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49977", " - net: stmmac: Fix zero-division error when disabling tc cbs", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49978", " - gso: fix udp gso fraglist segmentation after pull from frag_list", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49979", " - net: gso: fix tcp fraglist segmentation after pull from frag_list", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49980", " - vrf: revert \"vrf: Remove unnecessary RCU-bh critical section\"", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49981", " - media: venus: fix use after free bug in venus_remove due to race condition", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49956", " - gfs2: fix double destroy_workqueue error", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50176", " - remoteproc: k3-r5: Fix error handling when power-up failed", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49982", " - aoe: fix the potential use-after-free problem in more places", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49874", " - i3c: master: svc: Fix use after free vulnerability in svc_i3c_master Driver", " Due to Race Condition", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49875", " - nfsd: map the EBADMSG to nfserr_io to avoid warning", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50013", " - exfat: fix memory leak in exfat_load_bitmap()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49876", " - drm/xe: fix UAF around queue destruction", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49877", " - ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49957", " - ocfs2: fix null-ptr-deref when journal load failed.", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49965", " - ocfs2: remove unreasonable unlock in ocfs2_read_blocks", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49966", " - ocfs2: cancel dqi_sync_work before freeing oinfo", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49958", " - ocfs2: reserve space for inline xattr before attaching reflink tree", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49959", " - jbd2: stop waiting for space when jbd2_cleanup_journal_tail() returns error", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49878", " - resource: fix region_intersects() vs add_memory_driver_managed()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49879", " - drm: omapdrm: Add missing check for alloc_ordered_workqueue", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49880", " - ext4: fix off by one issue in alloc_flex_gd()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49881", " - ext4: update orig_path in ext4_find_extent()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50014", " - ext4: fix access to uninitialised lock in fc replay path", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49960", " - ext4: fix timer use-after-free on failed mount", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49882", " - ext4: fix double brelse() the buffer of the extents path", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49883", " - ext4: aovid use-after-free in ext4_ext_insert_extent()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49983", " - ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-free", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50015", " - ext4: dax: fix overflowing extents beyond inode size when partially writing", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49884", " - ext4: fix slab-use-after-free in ext4_split_extent_at()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49885", " - mm, slub: avoid zeroing kmalloc redzone", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49961", " - media: i2c: ar0521: Use cansleep version of gpiod_set_value()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49985", " - i2c: stm32f7: Do not prepare/unprepare clock during runtime suspend/resume", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49886", " - platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bug", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49986", " - platform/x86: x86-android-tablets: Fix use after free on", " platform_device_register() errors", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49887", " - f2fs: fix to don't panic system for no free segment fault injection", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49888", " - bpf: Fix a sdiv overflow issue", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49987", " - bpftool: Fix undefined behavior in qsort(NULL, 0, ...)", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50006", " - ext4: fix i_data_sem unlock order in ext4_ind_migrate()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49889", " - ext4: avoid use-after-free in ext4_ext_show_leaf()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49968", " - ext4: filesystems without casefold feature cannot be mounted with siphash", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49988", " - ksmbd: add refcnt to ksmbd_conn struct", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49890", " - drm/amd/pm: ensure the fw_info is not null before using it", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49891", " - scsi: lpfc: Validate hdwq pointers before dereferencing in reset/errata", " paths", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49892", " - drm/amd/display: Initialize get_bytes_per_element's default to 1", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50016", " - drm/amd/display: Avoid overflow assignment in link_dp_cts", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49893", " - drm/amd/display: Check stream_status before it is used", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49969", " - drm/amd/display: Fix index out of bounds in DCN30 color transformation", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49970", " - drm/amd/display: Implement bounds check for stream encoder creation in", " DCN401", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49894", " - drm/amd/display: Fix index out of bounds in degamma hardware format", " translation", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49895", " - drm/amd/display: Fix index out of bounds in DCN30 degamma hardware format", " translation", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49971", " - drm/amd/display: Increase array size of dummy_boolean", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49972", " - drm/amd/display: Deallocate DML memory if allocation fails", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49896", " - drm/amd/display: Check stream before comparing them", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49897", " - drm/amd/display: Check phantom_stream before it is used", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49898", " - drm/amd/display: Check null-initialized variables", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49899", " - drm/amd/display: Initialize denominators' default to 1", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49900", " - jfs: Fix uninit-value access of new_ea in ea_buffer", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49901", " - drm/msm/adreno: Assign msm_gpu->pdev earlier to avoid nullptrs", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49902", " - jfs: check if leafidx greater than num leaves per dmap tree", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49903", " - jfs: Fix uaf in dbFreeBits", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49904", " - drm/amdgpu: add list empty check to avoid null pointer issue", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49989", " - drm/amd/display: fix double free issue during amdgpu module unload", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49905", " - drm/amd/display: Add null check for 'afb' in", " amdgpu_dm_plane_handle_cursor_update (v2)", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49906", " - drm/amd/display: Check null pointer before try to access it", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49907", " - drm/amd/display: Check null pointers before using dc->clk_mgr", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49908", " - drm/amd/display: Add null check for 'afb' in amdgpu_dm_update_cursor (v2)", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50177", " - drm/amd/display: fix a UBSAN warning in DML2.1", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49909", " - drm/amd/display: Add NULL check for function pointer in", " dcn32_set_output_transfer_func", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49910", " - drm/amd/display: Add NULL check for function pointer in", " dcn401_set_output_transfer_func", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49911", " - drm/amd/display: Add NULL check for function pointer in", " dcn20_set_output_transfer_func", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49912", " - drm/amd/display: Handle null 'stream_status' in", " 'planes_changed_for_existing_stream'", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49913", " - drm/amd/display: Add null check for top_pipe_to_program in", " commit_planes_for_stream", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49914", " - drm/amd/display: Add null check for pipe_ctx->plane_state in", " dcn20_program_pipe", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49915", " - drm/amd/display: Add NULL check for clk_mgr in dcn32_init_hw", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49916", " - drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in", " dcn401_init_hw", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49917", " - drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in", " dcn30_init_hw", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49918", " - drm/amd/display: Add null check for head_pipe in", " dcn32_acquire_idle_pipe_for_head_pipe_in_layer", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49919", " - drm/amd/display: Add null check for head_pipe in", " dcn201_acquire_free_pipe_for_layer", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49991", " - drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49920", " - drm/amd/display: Check null pointers before multiple uses", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49921", " - drm/amd/display: Check null pointers before used", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49922", " - drm/amd/display: Check null pointers before using them", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49923", " - drm/amd/display: Pass non-null to dcn20_validate_apply_pipe_split_flags", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49992", " - drm/stm: Avoid use-after-free issues with crtc and plane", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49993", " - iommu/vt-d: Fix potential lockup if qi_submit_sync called with 0 count", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49924", " - fbdev: pxafb: Fix possible use after free in pxafb_task()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49925", " - fbdev: efifb: Register sysfs groups through driver core", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49926", " - rcu-tasks: Fix access non-existent percpu rtpcp variable in", " rcu_tasks_need_gpcb()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50007", " - ALSA: asihpi: Fix potential OOB array access", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50017", " - x86/mm/ident_map: Use gbpages only where full GB page should be mapped.", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49927", " - x86/ioapic: Handle allocation failures gracefully", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50008", " - wifi: mwifiex: Fix memcpy() field-spanning write warning in", " mwifiex_cmd_802_11_scan_ext()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50018", " - net: napi: Prevent overflow of napi_defer_hard_irqs", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49928", " - wifi: rtw89: avoid reading out of bounds when loading TX power FW elements", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50178", " - cpufreq: loongson3: Use raw_smp_processor_id() in do_service_request()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50009", " - cpufreq: amd-pstate: add check for cpufreq_cpu_get's return value", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49994", " - block: fix integer overflow in BLKSECDISCARD", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49929", " - wifi: iwlwifi: mvm: avoid NULL pointer dereference", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49995", " - tipc: guard against string buffer overrun", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49962", " - ACPICA: check null return of ACPI_ALLOCATE_ZEROED() in", " acpi_db_convert_to_package()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49930", " - wifi: ath11k: fix array out-of-bound access in SoC stats", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49931", " - wifi: ath12k: fix array out-of-bound access in SoC stats", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49932", " - btrfs: don't readahead the relocation inode on RST", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49933", " - blk_iocost: fix more out of bound shifts", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49934", " - fs/inode: Prevent dump_mapping() accessing invalid dentry.d_name.name", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50010", " - exec: don't WARN for racy path_noexec check", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49935", " - ACPI: PAD: fix crash in exit_round_robin()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49936", " - net/xen-netback: prevent UAF in xenvif_flush_hash()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49937", " - wifi: cfg80211: Set correct chandef when starting CAC", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49938", " - wifi: ath9k_htc: Use __skb_set_length() for resetting urb before resubmit", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49939", " - wifi: rtw89: avoid to add interface to list twice when SER", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49940", " - l2tp: prevent possible tunnel refcount underflow", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49941", " - gpiolib: Fix potential NULL pointer dereference in gpiod_get_label()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49996", " - cifs: Fix buffer overflow when parsing NFS reparse points", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49942", " - drm/xe: Prevent null pointer access in xe_migrate_copy", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49943", " - drm/xe/guc_submit: add missing locking in wedged_fini", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50011", " - ASoC: Intel: soc-acpi-intel-rpl-match: add missing empty item", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50174", " - drm/panthor: Fix race when converting group handle to group object", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49944", " - sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_start", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49945", " - net/ncsi: Disable the ncsi work before freeing the associated structure", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49946", " - ppp: do not assume bh is held in ppp_channel_bridge_input()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49947", " - net: test for not too small csum_start in virtio_net_hdr_to_skb()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49948", " - net: add more sanity checks to qdisc_pkt_len_init()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49949", " - net: avoid potential underflow in qdisc_pkt_len_init() with UFO", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49997", " - net: ethernet: lantiq_etop: fix memory disclosure", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49998", " - net: dsa: improve shutdown sequence", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49999", " - afs: Fix the setting of the server responding flag", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49950", " - Bluetooth: L2CAP: Fix uaf in l2cap_connect", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49951", " - Bluetooth: MGMT: Fix possible crash on mgmt_index_removed", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49952", " - netfilter: nf_tables: prevent nf_skb_duplicated corruption", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49953", " - net/mlx5e: Fix crash caused by calling __xfrm_state_delete() twice", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50000", " - net/mlx5e: Fix NULL deref in mlx5e_tir_builder_alloc()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50001", " - net/mlx5: Fix error path in multi-packet WQE transmit", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50179", " - ceph: remove the incorrect Fw reference check when dirtying pages", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49963", " - mailbox: bcm2835: Fix timeout during suspend mode", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-49954", " - static_call: Replace pointless WARN_ON() in static_call_module_notify()", "", " * Oracular update: v6.11.3 upstream stable release (LP: #2089052) //", " CVE-2024-50002", " - static_call: Handle module init failure correctly in", " static_call_del_module()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033)", " - EDAC/synopsys: Fix error injection on Zynq UltraScale+", " - crypto: xor - fix template benchmarking", " - crypto: qat - disable IOV in adf_dev_stop()", " - crypto: qat - fix recovery flow for VFs", " - crypto: qat - ensure correct order in VF restarting handler", " - ACPI: PMIC: Remove unneeded check in tps68470_pmic_opregion_probe()", " - eth: fbnic: select DEVLINK and PAGE_POOL", " - wifi: brcmfmac: introducing fwil query functions", " - wifi: ath9k: Remove error checks when creating debugfs entries", " - wifi: ath12k: fix BSS chan info request WMI command", " - wifi: ath12k: match WMI BSS chan info structure with firmware definition", " - wifi: ath12k: fix invalid AMPDU factor calculation in", " ath12k_peer_assoc_h_he()", " - hwrng: cn10k - Enable by default CN10K driver if Thunder SoC is enabled", " - crypto: x86/aes-gcm - fix PREEMPT_RT issue in gcm_crypt()", " - net: stmmac: dwmac-loongson: Init ref and PTP clocks rate", " - virtio: rename virtio_config_enabled to virtio_config_core_enabled", " - virtio: allow driver to disable the configure change notification", " - virtio-net: synchronize operstate with admin state on up/down", " - virtio-net: synchronize probe with ndo_set_features", " - arm64: signal: Fix some under-bracketed UAPI macros", " - wifi: rtw88: remove CPT execution branch never used", " - RISC-V: KVM: Fix sbiret init before forwarding to userspace", " - RISC-V: KVM: Allow legacy PMU access from guest", " - RISC-V: KVM: Fix to allow hpmcounter31 from the guest", " - mount: handle OOM on mnt_warn_timestamp_expiry", " - autofs: fix missing fput for FSCONFIG_SET_FD", " - netfilter: nf_tables: store new sets in dedicated list", " - wifi: rtw89: limit the PPDU length for VHT rate to 0x40000", " - kselftest/arm64: signal: fix/refactor SVE vector length enumeration", " - arm64: smp: smp_send_stop() and crash_smp_send_stop() should try non-NMI", " first", " - thermal: core: Fold two functions into their respective callers", " - thermal: core: Fix rounding of delay jiffies", " - perf/dwc_pcie: Fix registration issue in multi PCIe controller instances", " - perf/dwc_pcie: Always register for PCIe bus notifier", " - crypto: qat - fix \"Full Going True\" macro definition", " - ACPI: video: force native for Apple MacbookPro9,2", " - wifi: mac80211_hwsim: correct MODULE_PARM_DESC of multi_radio", " - wifi: iwlwifi: config: label 'gl' devices as discrete", " - wifi: iwlwifi: mvm: increase the time between ranging measurements", " - wifi: cfg80211: fix bug of mapping AF3x to incorrect User Priority", " - wifi: mac80211: fix the comeback long retry times", " - wifi: iwlwifi: mvm: allow ESR when we the ROC expires", " - wifi: mac80211: Check for missing VHT elements only for 5 GHz", " - ACPICA: Implement ACPI_WARNING_ONCE and ACPI_ERROR_ONCE", " - ACPICA: executer/exsystem: Don't nag user about every Stall() violating the", " spec", " - padata: Honor the caller's alignment in case of chunk_size 0", " - drivers/perf: hisi_pcie: Record hardware counts correctly", " - drivers/perf: hisi_pcie: Fix TLP headers bandwidth counting", " - kselftest/arm64: Actually test SME vector length changes via sigreturn", " - can: j1939: use correct function name in comment", " - wifi: rtw89: wow: fix wait condition for AOAC report request", " - ACPI: CPPC: Fix MASK_VAL() usage", " - netfilter: nf_tables: elements with timeout below CONFIG_HZ never expire", " - netfilter: nf_tables: reject element expiration with no timeout", " - netfilter: nf_tables: reject expiration higher than timeout", " - netfilter: nf_tables: remove annotation to access set timeout while holding", " lock", " - netfilter: nft_dynset: annotate data-races around set timeout", " - perf/arm-cmn: Refactor node ID handling. Again.", " - perf/arm-cmn: Fix CCLA register offset", " - perf/arm-cmn: Ensure dtm_idx is big enough", " - cpufreq: ti-cpufreq: Introduce quirks to handle syscon fails appropriately", " - thermal: gov_bang_bang: Adjust states of all uninitialized instances", " - wifi: mt76: mt7921: fix wrong UNII-4 freq range check for the channel usage", " - wifi: mt76: mt7996: fix traffic delay when switching back to working channel", " - wifi: mt76: mt7996: fix wmm set of station interface to 3", " - wifi: mt76: mt7996: fix HE and EHT beamforming capabilities", " - wifi: mt76: mt7996: fix EHT beamforming capability check", " - pm:cpupower: Add missing powercap_set_enabled() stub function", " - crypto: ccp - do not request interrupt on cmd completion when irqs disabled", " - crypto: hisilicon/hpre - mask cluster timeout error", " - crypto: hisilicon/qm - reset device before enabling it", " - wifi: mt76: mt7996: fix handling mbss enable/disable", " - wifi: mt76: connac: fix checksum offload fields of connac3 RXD", " - wifi: mt76: mt7603: fix mixed declarations and code", " - wifi: cfg80211: fix UBSAN noise in cfg80211_wext_siwscan()", " - wifi: mt76: mt7915: fix rx filter setting for bfee functionality", " - wifi: mt76: mt7996: fix uninitialized TLV data", " - wifi: cfg80211: fix two more possible UBSAN-detected off-by-one errors", " - af_unix: Don't call skb_get() for OOB skb.", " - af_unix: Remove single nest in manage_oob().", " - af_unix: Rename unlinked_skb in manage_oob().", " - af_unix: Move spin_lock() in manage_oob().", " - Bluetooth: hci_core: Fix sending MGMT_EV_CONNECT_FAILED", " - Bluetooth: hci_sync: Ignore errors from HCI_OP_REMOTE_NAME_REQ_CANCEL", " - can: m_can: enable NAPI before enabling interrupts", " - can: m_can: m_can_close(): stop clocks after device has been shut down", " - Bluetooth: btusb: Fix not handling ZPL/short-transfer", " - bareudp: Pull inner IP header in bareudp_udp_encap_recv().", " - bareudp: Pull inner IP header on xmit.", " - net: enetc: Use IRQF_NO_AUTOEN flag in request_irq()", " - crypto: n2 - Set err to EINVAL if snprintf fails for hmac", " - xsk: fix batch alloc API on non-coherent systems", " - net: ipv6: rpl_iptunnel: Fix memory leak in rpl_input", " - fbnic: Set napi irq value after calling netif_napi_add", " - net: tipc: avoid possible garbage value", " - ublk: move zone report data out of request pdu", " - block, bfq: choose the last bfqq from merge chain in bfq_setup_cooperator()", " - block, bfq: don't break merge chain in bfq_split_bfqq()", " - cachefiles: Fix non-taking of sb_writers around set/removexattr", " - nbd: correct the maximum value for discard sectors", " - erofs: fix incorrect symlink detection in fast symlink", " - erofs: fix error handling in z_erofs_init_decompressor", " - block, bfq: fix uaf for accessing waker_bfqq after splitting", " - block, bfq: fix procress reference leakage for bfqq in merge chain", " - io_uring/io-wq: do not allow pinning outside of cpuset", " - io_uring/io-wq: inherit cpuset of cgroup in io worker", " - spi: ppc4xx: handle irq_of_parse_and_map() errors", " - arm64: dts: exynos: exynos7885-jackpotlte: Correct RAM amount to 4GB", " - arm64: dts: mediatek: mt8186: Fix supported-hw mask for GPU OPPs", " - spi: ppc4xx: Avoid returning 0 when failed to parse and map IRQ", " - firmware: qcom: scm: Disable SDI and write no dump to dump mode", " - regulator: Return actual error in of_regulator_bulk_get_all()", " - arm64: dts: renesas: r9a08g045: Correct GICD and GICR sizes", " - arm64: dts: renesas: r9a07g043u: Correct GICD and GICR sizes", " - arm64: dts: renesas: r9a07g054: Correct GICD and GICR sizes", " - arm64: dts: renesas: r9a07g044: Correct GICD and GICR sizes", " - ARM: dts: microchip: sam9x60: Fix rtc/rtt clocks", " - arm64: tegra: Correct location of power-sensors for IGX Orin", " - arm64: dts: rockchip: Correct vendor prefix for Hardkernel ODROID-M1", " - arm64: dts: ti: k3-j721e-sk: Fix reversed C6x carveout locations", " - arm64: dts: ti: k3-j721e-beagleboneai64: Fix reversed C6x carveout locations", " - spi: bcmbca-hsspi: Fix missing pm_runtime_disable()", " - arm64: dts: qcom: x1e80100: Fix PHY for DP2", " - ARM: dts: microchip: sama7g5: Fix RTT clock", " - ARM: dts: imx7d-zii-rmu2: fix Ethernet PHY pinctrl property", " - arm64: dts: ti: k3-am654-idk: Fix dtbs_check warning in ICSSG dmas", " - ARM: versatile: fix OF node leak in CPUs prepare", " - reset: berlin: fix OF node leak in probe() error path", " - reset: k210: fix OF node leak in probe() error path", " - platform: cznic: turris-omnia-mcu: Fix error check in", " omnia_mcu_register_trng()", " - clocksource/drivers/qcom: Add missing iounmap() on errors in", " msm_dt_timer_init()", " - arm64: dts: mediatek: mt8195: Correct clock order for dp_intf*", " - x86/mm: Use IPIs to synchronize LAM enablement", " - ASoC: rt5682s: Return devm_of_clk_add_hw_provider to transfer the error", " - ASoC: tas2781: Fix a compiling warning reported by robot kernel test due to", " adding tas2563_dvc_table", " - ASoC: tas2781-i2c: Drop weird GPIO code", " - ASoC: tas2781-i2c: Get the right GPIO line", " - selftests/ftrace: Add required dependency for kprobe tests", " - ALSA: hda: cs35l41: fix module autoloading", " - selftests/ftrace: Fix test to handle both old and new kernels", " - x86/boot/64: Strip percpu address space when setting up GDT descriptors", " - m68k: Fix kernel_clone_args.flags in m68k_clone()", " - ASoC: loongson: fix error release", " - selftests/ftrace: Fix eventfs ownership testcase to find mount point", " - selftests:resctrl: Fix build failure on archs without __cpuid_count()", " - cgroup/pids: Avoid spurious event notification", " - hwmon: (max16065) Fix overflows seen when writing limits", " - hwmon: (max16065) Fix alarm attributes", " - iommu/arm-smmu: Un-demote unhandled-fault msg", " - iommu/arm-smmu-v3: Fix a NULL vs IS_ERR() check", " - mtd: slram: insert break after errors in parsing the map", " - hwmon: (ntc_thermistor) fix module autoloading", " - power: supply: axp20x_battery: Remove design from min and max voltage", " - power: supply: max17042_battery: Fix SOC threshold calc w/ no current sense", " - fbdev: hpfb: Fix an error handling path in hpfb_dio_probe()", " - iommu/amd: Handle error path in amd_iommu_probe_device()", " - iommu/amd: Allocate the page table root using GFP_KERNEL", " - iommu/amd: Move allocation of the top table into v1_alloc_pgtable", " - iommu/amd: Set the pgsize_bitmap correctly", " - iommu/amd: Do not set the D bit on AMD v2 table entries", " - mtd: powernv: Add check devm_kasprintf() returned value", " - rcu/nocb: Fix RT throttling hrtimer armed from offline CPU", " - mtd: rawnand: mtk: Use for_each_child_of_node_scoped()", " - mtd: rawnand: mtk: Factorize out the logic cleaning mtk chips", " - mtd: rawnand: mtk: Fix init error path", " - iommu/arm-smmu-qcom: hide last LPASS SMMU context bank from linux", " - iommu/arm-smmu-qcom: Work around SDM845 Adreno SMMU w/ 16K pages", " - iommu/arm-smmu-qcom: apply num_context_bank fixes for SDM630 / SDM660", " - pmdomain: core: Harden inter-column space in debug summary", " - pmdomain: core: Fix \"managed by\" alignment in debug summary", " - drm/stm: Fix an error handling path in stm_drm_platform_probe()", " - drm/stm: ltdc: check memory returned by devm_kzalloc()", " - drm/amd/display: free bo used for dmub bounding box", " - drm/amdgpu: properly handle vbios fake edid sizing", " - drm/radeon: properly handle vbios fake edid sizing", " - drm/amd/display: Reset VRR config during resume", " - scsi: smartpqi: revert propagate-the-multipath-failure-to-SML-quickly", " - scsi: sd: Don't check if a write for REQ_ATOMIC", " - scsi: block: Don't check REQ_ATOMIC for reads", " - scsi: NCR5380: Check for phase match during PDMA fixup", " - drm/amd/amdgpu: Properly tune the size of struct", " - drm/amd/display: Improve FAM control for DCN401", " - drm/rockchip: vop: Allow 4096px width scaling", " - drm/rockchip: dw_hdmi: Fix reading EDID when using a forced mode", " - drm/radeon/evergreen_cs: fix int overflow errors in cs track offsets", " - drm/bridge: lontium-lt8912b: Validate mode in drm_bridge_funcs::mode_valid()", " - drm/vc4: hdmi: Handle error case of pm_runtime_resume_and_get", " - drm/mediatek: Fix missing configuration flags in mtk_crtc_ddp_config()", " - drm/mediatek: Use spin_lock_irqsave() for CRTC event lock", " - powerpc/8xx: Fix initial memory mapping", " - powerpc/8xx: Fix kernel vs user address comparison", " - powerpc/vdso: Inconditionally use CFUNC macro", " - drm/msm: Use a7xx family directly in gpu_state", " - drm/msm: Dump correct dbgahb clusters on a750", " - drm/msm: Fix CP_BV_DRAW_STATE_ADDR name", " - drm/msm: Fix incorrect file name output in adreno_request_fw()", " - drm/msm/a5xx: disable preemption in submits by default", " - drm/msm/a5xx: properly clear preemption records on resume", " - drm/msm/a5xx: fix races in preemption evaluation stage", " - drm/msm/a5xx: workaround early ring-buffer emptiness check", " - ipmi: docs: don't advertise deprecated sysfs entries", " - drm/msm/dp: enable widebus on all relevant chipsets", " - drm/msm/dsi: correct programming sequence for SM8350 / SM8450", " - drm/msm: fix %s null argument error", " - platform/x86: ideapad-laptop: Make the scope_guard() clear of its scope", " - kselftest: dt: Ignore nodes that have ancestors disabled", " - drivers:drm:exynos_drm_gsc:Fix wrong assignment in gsc_bind()", " - drm/amdgpu: fix invalid fence handling in amdgpu_vm_tlb_flush", " - xen: use correct end address of kernel for conflict checking", " - HID: wacom: Support sequence numbers smaller than 16-bit", " - HID: wacom: Do not warn about dropped packets for first packet", " - ata: libata: Clear DID_TIME_OUT for ATA PT commands with sense data", " - xen: introduce generic helper checking for memory map conflicts", " - xen: move max_pfn in xen_memory_setup() out of function scope", " - xen: add capability to remap non-RAM pages to different PFNs", " - xen: tolerate ACPI NVS memory overlapping with Xen allocated memory", " - drm/xe: fix missing 'xe_vm_put'", " - xen/swiotlb: add alignment check for dma buffers", " - xen/swiotlb: fix allocated size", " - sched/fair: Make SCHED_IDLE entity be preempted in strict hierarchy", " - bpf, x64: Fix tailcall hierarchy", " - bpf, arm64: Fix tailcall hierarchy", " - bpf: Fix compare error in function retval_range_within", " - selftests/bpf: Workaround strict bpf_lsm return value check.", " - selftests/bpf: Fix error linking uprobe_multi on mips", " - selftests/bpf: Fix wrong binary in Makefile log output", " - tools/runqslower: Fix LDFLAGS and add LDLIBS support", " - selftests/bpf: Use pid_t consistently in test_progs.c", " - selftests/bpf: Fix compile error from rlim_t in sk_storage_map.c", " - selftests/bpf: Fix error compiling bpf_iter_setsockopt.c with musl libc", " - selftests/bpf: Drop unneeded error.h includes", " - selftests/bpf: Fix missing ARRAY_SIZE() definition in bench.c", " - selftests/bpf: Fix missing UINT_MAX definitions in benchmarks", " - selftests/bpf: Fix missing BUILD_BUG_ON() declaration", " - selftests/bpf: Fix include of ", " - selftests/bpf: Fix compiling parse_tcp_hdr_opt.c with musl-libc", " - selftests/bpf: Fix compiling kfree_skb.c with musl-libc", " - selftests/bpf: Fix compiling flow_dissector.c with musl-libc", " - selftests/bpf: Fix compiling tcp_rtt.c with musl-libc", " - selftests/bpf: Fix compiling core_reloc.c with musl-libc", " - selftests/bpf: Fix errors compiling lwt_redirect.c with musl libc", " - selftests/bpf: Fix errors compiling decap_sanity.c with musl libc", " - selftests/bpf: Fix errors compiling crypto_sanity.c with musl libc", " - selftests/bpf: Fix errors compiling cg_storage_multi.h with musl libc", " - libbpf: Don't take direct pointers into BTF data from st_ops", " - selftests/bpf: Fix arg parsing in veristat, test_progs", " - selftests/bpf: Fix error compiling test_lru_map.c", " - selftests/bpf: Fix C++ compile error from missing _Bool type", " - selftests/bpf: Fix redefinition errors compiling lwt_reroute.c", " - selftests/bpf: Fix compile if backtrace support missing in libc", " - selftests/bpf: Fix error compiling tc_redirect.c with musl libc", " - s390/entry: Move early program check handler to entry.S", " - s390/entry: Make early program check handler relocated lowcore aware", " - libbpf: Fix license for btf_relocate.c", " - samples/bpf: Fix compilation errors with cf-protection option", " - selftests/bpf: no need to track next_match_pos in struct test_loader", " - selftests/bpf: extract test_loader->expect_msgs as a data structure", " - selftests/bpf: allow checking xlated programs in verifier_* tests", " - selftests/bpf: __arch_* macro to limit test cases to specific archs", " - selftests/bpf: fix to avoid __msg tag de-duplication by clang", " - selftests/bpf: Fix incorrect parameters in NULL pointer checking", " - libbpf: Fix bpf_object__open_skeleton()'s mishandling of options", " - s390/ap: Fix deadlock caused by recursive lock of the AP bus scan mutex", " - libbpf: Ensure new BTF objects inherit input endianness", " - xz: cleanup CRC32 edits from 2018", " - kthread: fix task state in kthread worker if being frozen", " - ext4: clear EXT4_GROUP_INFO_WAS_TRIMMED_BIT even mount with discard", " - bpftool: Fix handling enum64 in btf dump sorting", " - sched/deadline: Fix schedstats vs deadline servers", " - smackfs: Use rcu_assign_pointer() to ensure safe assignment in smk_set_cipso", " - ext4: avoid buffer_head leak in ext4_mark_inode_used()", " - ext4: avoid potential buffer_head leak in __ext4_new_inode()", " - ext4: avoid negative min_clusters in find_group_orlov()", " - ext4: return error on ext4_find_inline_entry", " - sched/numa: Fix the vma scan starving issue", " - nilfs2: determine empty node blocks as corrupted", " - sched/pelt: Use rq_clock_task() for hw_pressure", " - bpf: Fix bpf_strtol and bpf_strtoul helpers for 32bit", " - bpf: Improve check_raw_mode_ok test for MEM_UNINIT-tagged types", " - perf scripts python cs-etm: Restore first sample log in verbose mode", " - perf bpf: Move BPF disassembly routines to separate file to avoid clash with", " capstone bpf headers", " - perf mem: Free the allocated sort string, fixing a leak", " - perf lock contention: Change stack_id type to s32", " - perf vendor events: SKX, CLX, SNR uncore cache event fixes", " - perf inject: Fix leader sampling inserting additional samples", " - perf report: Fix --total-cycles --stdio output error", " - perf build: Fix up broken capstone feature detection fast path", " - perf sched timehist: Fix missing free of session in perf_sched__timehist()", " - perf stat: Display iostat headers correctly", " - perf dwarf-aux: Check allowed location expressions when collecting variables", " - perf annotate-data: Fix off-by-one in location range check", " - perf dwarf-aux: Handle bitfield members from pointer access", " - perf hist: Don't set hpp_fmt_value for members in --no-group", " - perf sched timehist: Fixed timestamp error when unable to confirm event", " sched_in time", " - perf time-utils: Fix 32-bit nsec parsing", " - perf mem: Check mem_events for all eligible PMUs", " - perf mem: Fix missed p-core mem events on ADL and RPL", " - clk: imx: clk-audiomix: Correct parent clock for earc_phy and audpll", " - clk: imx: imx6ul: fix default parent for enet*_ref_sel", " - clk: imx: composite-8m: Enable gate clk with mcore_booted", " - clk: imx: composite-93: keep root clock on when mcore enabled", " - clk: imx: composite-7ulp: Check the PCC present bit", " - clk: imx: fracn-gppll: fix fractional part of PLL getting lost", " - clk: imx: imx8mp: fix clock tree update of TF-A managed clocks", " - clk: imx: imx8qxp: Register dc0_bypass0_clk before disp clk", " - clk: imx: imx8qxp: Parent should be initialized earlier than the clock", " - quota: avoid missing put_quota_format when DQUOT_SUSPENDED is passed", " - remoteproc: imx_rproc: Correct ddr alias for i.MX8M", " - remoteproc: imx_rproc: Initialize workqueue earlier", " - clk: rockchip: Set parent rate for DCLK_VOP clock on RK3228", " - clk: qcom: dispcc-sm8550: fix several supposed typos", " - clk: qcom: dispcc-sm8550: use rcg2_ops for mdss_dptx1_aux_clk_src", " - clk: qcom: dispcc-sm8650: Update the GDSC flags", " - clk: qcom: dispcc-sm8550: use rcg2_shared_ops for ESC RCGs", " - leds: bd2606mvv: Fix device child node usage in bd2606mvv_probe()", " - pinctrl: renesas: rzg2l: Return -EINVAL if the pin doesn't support", " PIN_CFG_OEN", " - pinctrl: ti: ti-iodelay: Fix some error handling paths", " - phy: phy-rockchip-samsung-hdptx: Explicitly include pm_runtime.h", " - Input: ilitek_ts_i2c - avoid wrong input subsystem sync", " - Input: ilitek_ts_i2c - add report id message validation", " - media: raspberrypi: VIDEO_RASPBERRYPI_PISP_BE should depend on ARCH_BCM2835", " - [Config] updateconfigs for VIDEO_RASPBERRYPI_PISP_BE", " - PCI: Wait for Link before restoring Downstream Buses", " - firewire: core: correct range of block for case of switch statement", " - media: staging: media: starfive: camss: Drop obsolete return value", " documentation", " - clk: qcom: ipq5332: Register gcc_qdss_tsctr_clk_src", " - clk: qcom: dispcc-sm8250: use special function for Lucid 5LPE PLL", " - leds: pca995x: Use device_for_each_child_node() to access device child nodes", " - leds: pca995x: Fix device child node usage in pca995x_probe()", " - x86/PCI: Check pcie_find_root_port() return for NULL", " - PCI: xilinx-nwl: Fix register misspelling", " - PCI: xilinx-nwl: Clean up clock on probe failure/removal", " - leds: gpio: Set num_leds after allocation", " - media: platform: rzg2l-cru: rzg2l-csi2: Add missing MODULE_DEVICE_TABLE", " - pinctrl: single: fix missing error code in pcs_probe()", " - clk: at91: sama7g5: Allocate only the needed amount of memory for PLLs", " - iommufd/selftest: Fix buffer read overrrun in the dirty test", " - RDMA/bnxt_re: Fix the table size for PSN/MSN entries", " - media: imagination: VIDEO_E5010_JPEG_ENC should depend on ARCH_K3", " - [Config] updateconfigs for VIDEO_E5010_JPEG_ENC", " - RDMA/rtrs: Reset hb_missed_cnt after receiving other traffic from peer", " - clk: ti: dra7-atl: Fix leak of of_nodes", " - clk: starfive: Use pm_runtime_resume_and_get to fix pm_runtime_get_sync()", " usage", " - clk: rockchip: rk3588: Fix 32k clock name for pmu_24m_32k_100m_src_p", " - nfsd: remove unneeded EEXIST error check in nfsd_do_file_acquire", " - nfsd: fix refcount leak when file is unhashed after being found", " - pinctrl: mvebu: Fix devinit_dove_pinctrl_probe function", " - dt-bindings: PCI: layerscape-pci: Replace fsl,lx2160a-pcie with", " fsl,lx2160ar2-pcie", " - iommufd: Check the domain owner of the parent before creating a nesting", " domain", " - RDMA/erdma: Return QP state in erdma_query_qp", " - RDMA/mlx5: Fix counter update on MR cache mkey creation", " - RDMA/mlx5: Limit usage of over-sized mkeys from the MR cache", " - RDMA/mlx5: Drop redundant work canceling from clean_keys()", " - RDMA/mlx5: Fix MR cache temp entries cleanup", " - watchdog: imx_sc_wdt: Don't disable WDT in suspend", " - RDMA/hns: Don't modify rq next block addr in HIP09 QPC", " - RDMA/hns: Fix the overflow risk of hem_list_calc_ba_range()", " - RDMA/hns: Fix VF triggering PF reset in abnormal interrupt handler", " - RDMA/hns: Fix 1bit-ECC recovery address in non-4K OS", " - RDMA/hns: Optimize hem allocation performance", " - RDMA/hns: Fix restricted __le16 degrades to integer issue", " - Input: ims-pcu - fix calling interruptible mutex", " - RDMA/mlx5: Obtain upper net device only when needed", " - PCI: qcom-ep: Enable controller resources like PHY only after refclk is", " available", " - riscv: Fix fp alignment bug in perf_callchain_user()", " - RDMA/hns: Fix ah error counter in sw stat not increasing", " - RDMA/irdma: fix error message in irdma_modify_qp_roce()", " - ntb_perf: Fix printk format", " - ntb: Force physically contiguous allocation of rx ring buffers", " - nfsd: untangle code in nfsd4_deleg_getattr_conflict()", " - nfsd: fix initial getattr on write delegation", " - crypto: caam - Pad SG length when allocating hash edesc", " - crypto: powerpc/p10-aes-gcm - Disable CRYPTO_AES_GCM_P10", " - [Config] disable CRYPTO_AES_GCM_P10", " - f2fs: atomic: fix to avoid racing w/ GC", " - f2fs: reduce expensive checkpoint trigger frequency", " - f2fs: fix to avoid racing in between read and OPU dio write", " - f2fs: Create COW inode from parent dentry for atomic write", " - f2fs: fix to wait page writeback before setting gcing flag", " - f2fs: atomic: fix to truncate pagecache before on-disk metadata truncation", " - f2fs: compress: don't redirty sparse cluster during {,de}compress", " - f2fs: prevent atomic file from being dirtied before commit", " - spi: airoha: fix dirmap_{read,write} operations", " - spi: airoha: fix airoha_snand_{write,read}_data data_len estimation", " - spi: atmel-quadspi: Undo runtime PM changes at driver exit time", " - spi: spi-fsl-lpspi: Undo runtime PM changes at driver exit time", " - lib/sbitmap: define swap_lock as raw_spinlock_t", " - spi: airoha: remove read cache in airoha_snand_dirmap_read()", " - spi: atmel-quadspi: Avoid overwriting delay register settings", " - NFSv4.2: Fix detection of \"Proxying of Times\" server support", " - nvme-multipath: system fails to create generic nvme device", " - iio: adc: ad7606: fix oversampling gpio array", " - iio: adc: ad7606: fix standby gpio state to match the documentation", " - driver core: Fix error handling in driver API device_rename()", " - ABI: testing: fix admv8818 attr description", " - iio: chemical: bme680: Fix read/write ops to device by adding mutexes", " - iio: magnetometer: ak8975: drop incorrect AK09116 compatible", " - dt-bindings: iio: asahi-kasei,ak8975: drop incorrect AK09116 compatible", " - serial: 8250: omap: Cleanup on error in request_irq", " - Coresight: Set correct cs_mode for TPDM to fix disable issue", " - Coresight: Set correct cs_mode for dummy source to fix disable issue", " - coresight: tmc: sg: Do not leak sg_table", " - interconnect: icc-clk: Add missed num_nodes initialization", " - interconnect: qcom: sm8250: Enable sync_state", " - dm integrity: fix gcc 5 warning", " - cxl/pci: Fix to record only non-zero ranges", " - um: remove ARCH_NO_PREEMPT_DYNAMIC", " - Revert \"dm: requeue IO if mapping table not yet available\"", " - net: phy: aquantia: fix -ETIMEDOUT PHY probe failure when firmware not", " present", " - net: xilinx: axienet: Schedule NAPI in two steps", " - net: xilinx: axienet: Fix packet counting", " - net: ipv6: select DST_CACHE from IPV6_RPL_LWTUNNEL", " - net: qrtr: Update packets cloning when broadcasting", " - net: phy: aquantia: fix setting active_low bit", " - net: phy: aquantia: fix applying active_low bit after reset", " - net: ravb: Fix maximum TX frame size for GbEth devices", " - net: ravb: Fix R-Car RX frame size limit", " - virtio_net: Fix mismatched buf address when unmapping for small packets", " - netfilter: nf_tables: Keep deleted flowtable hooks until after RCU", " - netfilter: ctnetlink: compile ctnetlink_label_size with", " CONFIG_NF_CONNTRACK_EVENTS", " - netfilter: nf_tables: use rcu chain hook list iterator from netlink dump", " path", " - netfilter: nf_tables: missing objects with no memcg accounting", " - selftests: netfilter: Avoid hanging ipvs.sh", " - io_uring/sqpoll: do not allow pinning outside of cpuset", " - io_uring/rw: treat -EOPNOTSUPP for IOCB_NOWAIT like -EAGAIN", " - io_uring: check for presence of task_work rather than TIF_NOTIFY_SIGNAL", " - mm: migrate: annotate data-race in migrate_folio_unmap()", " - drm/amd/display: Fix Synaptics Cascaded Panamera DSC Determination", " - drm/amd/display: Add DSC Debug Log", " - drm/amdgpu/display: Fix a mistake in revert commit", " - xen: move checks for e820 conflicts further up", " - xen: allow mapping ACPI data using a different physical address", " - io_uring/sqpoll: retain test for whether the CPU is valid", " - drm/amd/display: disable_hpo_dp_link_output: Check link_res->hpo_dp_link_enc", " before using it", " - io_uring/sqpoll: do not put cpumask on stack", " - selftests/bpf: correctly move 'log' upon successful match", " - Remove *.orig pattern from .gitignore", " - PCI: Revert to the original speed after PCIe failed link retraining", " - PCI: Clear the LBMS bit after a link retrain", " - PCI: dra7xx: Fix threaded IRQ request for \"dra7xx-pcie-main\" IRQ", " - PCI: imx6: Fix missing call to phy_power_off() in error handling", " - PCI: imx6: Fix establish link failure in EP mode for i.MX8MM and i.MX8MP", " - PCI: imx6: Fix i.MX8MP PCIe EP's occasional failure to trigger MSI", " - PCI: Correct error reporting with PCIe failed link retraining", " - PCI: Use an error code with PCIe failed link retraining", " - PCI: xilinx-nwl: Fix off-by-one in INTx IRQ handler", " - PCI: dra7xx: Fix error handling when IRQ request fails in probe", " - Revert \"soc: qcom: smd-rpm: Match rpmsg channel instead of compatible\"", " - ASoC: rt5682: Return devm_of_clk_add_hw_provider to transfer the error", " - soc: fsl: cpm1: qmc: Update TRNSYNC only in transparent mode", " - soc: fsl: cpm1: tsa: Fix tsa_write8()", " - soc: versatile: integrator: fix OF node leak in probe() error path", " - Revert \"media: tuners: fix error return code of", " hybrid_tuner_request_state()\"", " - iommu/amd: Fix argument order in amd_iommu_dev_flush_pasid_all()", " - Input: adp5588-keys - fix check on return code", " - Input: i8042 - add TUXEDO Stellaris 16 Gen5 AMD to i8042 quirk table", " - Input: i8042 - add TUXEDO Stellaris 15 Slim Gen6 AMD to i8042 quirk table", " - Input: i8042 - add another board name for TUXEDO Stellaris Gen5 AMD line", " - KVM: arm64: Add memory length checks and remove inline in do_ffa_mem_xfer", " - KVM: x86: Enforce x2APIC's must-be-zero reserved ICR bits", " - KVM: x86: Move x2APIC ICR helper above kvm_apic_write_nodecode()", " - KVM: x86: Re-split x2APIC ICR into ICR+ICR2 for AMD (x2AVIC)", " - drm/amdgpu/mes12: reduce timeout", " - drm/amdgpu/mes11: reduce timeout", " - drm/amdkfd: Add SDMA queue quantum support for GFX12", " - drm/amdgpu: update golden regs for gfx12", " - drm/amdgpu/mes12: set enable_level_process_quantum_check", " - drm/amdgpu/vcn: enable AV1 on both instances", " - drm/amd/pm: update workload mask after the setting", " - drm/amdgpu: fix PTE copy corruption for sdma 7", " - drm/amdgpu: bump driver version for cleared VRAM", " - drm/amdgpu/mes12: switch SET_SHADER_DEBUGGER pkt to mes schq pipe", " - drm/amdgpu: Fix selfring initialization sequence on soc24", " - drm/amd/display: Add HDMI DSC native YCbCr422 support", " - drm/amd/display: Round calculated vtotal", " - drm/amd/display: Clean up dsc blocks in accelerated mode", " - drm/amd/display: Block timing sync for different output formats in pmo", " - drm/amd/display: Validate backlight caps are sane", " - drm/amd/display: Disable SYMCLK32_LE root clock gating", " - drm/amd/display: Block dynamic IPS2 on DCN35 for incompatible FW versions", " - drm/amd/display: Enable DML2 override_det_buffer_size_kbytes", " - drm/amd/display: Skip to enable dsc if it has been off", " - drm/amd/display: Fix underflow when setting underscan on DCN401", " - drm/amd/display: Update IPS default mode for DCN35/DCN351", " - objtool: Handle frame pointer related instructions", " - powerpc/atomic: Use YZ constraints for DS-form instructions", " - ksmbd: make __dir_empty() compatible with POSIX", " - ksmbd: allow write with FILE_APPEND_DATA", " - ksmbd: handle caseless file creation", " - ata: libata-scsi: Fix ata_msense_control() CDL page reporting", " - scsi: ufs: qcom: Update MODE_MAX cfg_bw value", " - scsi: lpfc: Restrict support for 32 byte CDBs to specific HBAs", " - scsi: mac_scsi: Revise printk(KERN_DEBUG ...) messages", " - scsi: mac_scsi: Refactor polling loop", " - scsi: mac_scsi: Disallow bus errors during PDMA send", " - can: esd_usb: Remove CAN_CTRLMODE_3_SAMPLES for CAN-USB/3-FD", " - wifi: rtw88: Fix USB/SDIO devices not transmitting beacons", " - usbnet: fix cyclical race on disconnect with work queue", " - arm64: dts: mediatek: mt8195-cherry: Mark USB 3.0 on xhci1 as disabled", " - arm64: dts: mediatek: mt8395-nio-12l: Mark USB 3.0 on xhci1 as disabled", " - USB: appledisplay: close race between probe and completion handler", " - USB: misc: cypress_cy7c63: check for short transfer", " - USB: class: CDC-ACM: fix race between get_serial and set_serial", " - USB: misc: yurex: fix race between read and write", " - usb: xhci: fix loss of data on Cadence xHC", " - usb: cdnsp: Fix incorrect usb_request status", " - usb: xHCI: add XHCI_RESET_ON_RESUME quirk for Phytium xHCI host", " - usb: gadget: dummy_hcd: execute hrtimer callback in softirq context", " - usb: dwc2: drd: fix clock gating on USB role switch", " - bus: integrator-lm: fix OF node leak in probe()", " - bus: mhi: host: pci_generic: Update EDL firmware path for Foxconn modems", " - bus: mhi: host: pci_generic: Fix the name for the Telit FE990A", " - tty: rp2: Fix reset with non forgiving PCIe host bridges", " - pps: add an error check in parport_attach", " - serial: don't use uninitialized value in uart_poll_init()", " - xhci: Set quirky xHC PCI hosts to D3 _after_ stopping and freeing them.", " - serial: qcom-geni: fix fifo polling timeout", " - serial: qcom-geni: fix false console tx restart", " - crypto: qcom-rng - fix support for ACPI-based systems", " - crypto: ccp - Properly unregister /dev/sev on sev PLATFORM_STATUS failure", " - drbd: Fix atomicity violation in drbd_uuid_set_bm()", " - drbd: Add NULL check for net_conf to prevent dereference in state validation", " - ACPI: resource: Do IRQ override on MECHREV GM7XG0M", " - ACPI: resource: Add another DMI match for the TongFang GMxXGxx", " - intel_idle: add Granite Rapids Xeon support", " - intel_idle: fix ACPI _CST matching for newer Xeon platforms", " - x86/entry: Remove unwanted instrumentation in common_interrupt()", " - perf/x86/intel: Allow to setup LBR for counting event for BPF", " - perf/x86/intel/pt: Fix sampling synchronization", " - btrfs: subpage: fix the bitmap dump which can cause bitmap corruption", " - wifi: mt76: mt7921: Check devm_kasprintf() returned value", " - wifi: mt76: mt7915: check devm_kasprintf() returned value", " - idpf: fix netdev Tx queue stop/wake", " - wifi: rtw88: 8821cu: Remove VID/PID 0bda:c82c", " - wifi: rtw88: 8822c: Fix reported RX band width", " - wifi: rtw88: 8703b: Fix reported RX band width", " - wifi: mt76: mt7615: check devm_kasprintf() returned value", " - wifi: mt76: mt7925: fix a potential association failure upon resuming", " - debugfs show actual source in /proc/mounts", " - debugobjects: Fix conditions in fill_pool()", " - btrfs: tree-checker: fix the wrong output of data backref objectid", " - btrfs: always update fstrim_range on failure in FITRIM ioctl", " - f2fs: fix several potential integer overflows in file offsets", " - f2fs: prevent possible int overflow in dir_block_index()", " - f2fs: avoid potential int overflow in sanity_check_area_boundary()", " - hwrng: mtk - Use devm_pm_runtime_enable", " - hwrng: bcm2835 - Add missing clk_disable_unprepare in bcm2835_rng_init", " - hwrng: cctrng - Add missing clk_disable_unprepare in cctrng_resume", " - arm64: esr: Define ESR_ELx_EC_* constants as UL", " - arm64: errata: Enable the AC03_CPU_38 workaround for ampere1a", " - arm64: dts: mediatek: mt8186-corsola: Disable DPI display interface", " - arm64: dts: rockchip: Raise Pinebook Pro's panel backlight PWM frequency", " - arm64: dts: qcom: sa8775p: Mark APPS and PCIe SMMUs as DMA coherent", " - arm64: dts: rockchip: Correct the Pinebook Pro battery design capacity", " - fs: Fix file_set_fowner LSM hook inconsistencies", " - nfs: fix memory leak in error path of nfs4_do_reclaim", " - EDAC/igen6: Fix conversion of system address to physical memory address", " - eventpoll: Annotate data-race of busy_poll_usecs", " - md: Don't flush sync_work in md_write_start()", " - cpuidle: riscv-sbi: Use scoped device node handling to fix missing", " of_node_put", " - lsm: add the inode_free_security_rcu() LSM implementation hook", " - spi: fspi: involve lut_num for struct nxp_fspi_devtype_data", " - dt-bindings: spi: nxp-fspi: add imx8ulp support", " - ARM: dts: imx6ul-geam: fix fsl,pins property in tscgrp pinctrl", " - ARM: dts: imx6ull-seeed-npi: fix fsl,pins property in tscgrp pinctrl", " - tools/nolibc: include arch.h from string.h", " - soc: versatile: realview: fix memory leak during device remove", " - soc: versatile: realview: fix soc_dev leak during device remove", " - usb: typec: ucsi: Call CANCEL from single location", " - usb: typec: ucsi: Fix busy loop on ASUS VivoBooks", " - soc: qcom: geni-se: add GP_LENGTH/IRQ_EN_SET/IRQ_EN_CLEAR registers", " - serial: qcom-geni: fix arg types for qcom_geni_serial_poll_bit()", " - serial: qcom-geni: introduce qcom_geni_serial_poll_bitfield()", " - serial: qcom-geni: fix console corruption", " - thermal: core: Store trip sysfs attributes in thermal_trip_desc", " - thermal: sysfs: Get to trips via attribute pointers", " - thermal: sysfs: Refine the handling of trip hysteresis changes", " - thermal: sysfs: Add sanity checks for trip temperature and hysteresis", " - bpf: lsm: Set bpf_lsm_blob_sizes.lbs_task to 0", " - compiler.h: specify correct attribute for .rodata..c_jump_table", " - lockdep: fix deadlock issue between lockdep and rcu", " - mm/hugetlb_vmemmap: batch HVO work when demoting", " - s390/ftrace: Avoid calling unwinder in ftrace_return_address()", " - selftest mm/mseal: fix test_seal_mremap_move_dontunmap_anyaddr", " - mm: only enforce minimum stack gap size if it's sensible", " - spi: fspi: add support for imx8ulp", " - module: Fix KCOV-ignored file name", " - fbdev: xen-fbfront: Assign fb_info->device", " - tpm: export tpm2_sessions_init() to fix ibmvtpm building", " - mm/huge_memory: ensure huge_zero_folio won't have large_rmappable flag set", " - mm: change vmf_anon_prepare() to __vmf_anon_prepare()", " - mm/damon/vaddr: protect vma traversal in __damon_va_thre_regions() with rcu", " read lock", " - i2c: aspeed: Update the stop sw state when the bus recovery occurs", " - i2c: isch: Add missed 'else'", " - i2c: xiic: Try re-initialization on bus busy timeout", " - Documentation: KVM: fix warning in \"make htmldocs\"", " - spi: atmel-quadspi: Fix wrong register value written to MR", " - Revert: \"dm-verity: restart or panic on an I/O error\"", " - Linux 6.11.2", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47675", " - bpf: Fix use-after-free in bpf_uprobe_multi_link_attach()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47676", " - mm/hugetlb.c: fix UAF of vma in hugetlb fault pathway", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47677", " - exfat: resolve memory leak from exfat_create_upcase_table()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47725", " - dm-verity: restart or panic on an I/O error", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47739", " - padata: use integer wrap around to prevent deadlock on seq_nr overflow", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47678", " - icmp: change the order of rate limits", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47733", " - netfs: Delete subtree of 'fs/netfs' when netfs module exits", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47679", " - vfs: fix race between evice_inodes() and find_inode()&iput()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49859", " - f2fs: fix to check atomic_file in f2fs ioctl interfaces", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47680", " - f2fs: check discard support for conventional zones", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47740", " - f2fs: Require FMODE_WRITE for atomic write ioctls", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47726", " - f2fs: fix to wait dio completion", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47741", " - btrfs: fix race setting file private on concurrent lseek using same fd", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47681", " - wifi: mt76: mt7996: fix NULL pointer dereference in mt7996_mcu_sta_bfer_he", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49858", " - efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49860", " - ACPI: sysfs: validate return type of _STR method", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47742", " - firmware_loader: Block path traversal", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47682", " - scsi: sd: Fix off-by-one error in sd_read_block_characteristics()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47743", " - KEYS: prevent NULL pointer dereference in find_asymmetric_key()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47727", " - x86/tdx: Fix \"in-kernel MMIO\" check", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47744", " - KVM: Use dedicated mutex to protect kvm_usage_count to avoid deadlock", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47719", " - iommufd: Protect against overflow of ALIGN() during iova allocation", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47745", " - mm: call the security_mmap_file() LSM hook in remap_file_pages()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47746", " - fuse: use exclusive lock when FUSE_I_CACHE_IO_MODE is set", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47734", " - bonding: Fix unnecessary warnings and logs from bond_xdp_get_xmit_slave()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47684", " - tcp: check skb is non-NULL in tcp_rto_delta_us()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47747", " - net: seeq: Fix use after free vulnerability in ether3 Driver Due to Race", " Condition", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47685", " - netfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47686", " - ep93xx: clock: Fix off by one in ep93xx_div_recalc_rate()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47748", " - vhost_vdpa: assign irq bypass producer token correctly", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47687", " - vdpa/mlx5: Fix invalid mr resource destroy", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47688", " - driver core: Fix a potential null-ptr-deref in module_add_driver()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47689", " - f2fs: fix to don't set SB_RDONLY in f2fs_handle_critical_error()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47690", " - f2fs: get rid of online repaire on corrupted directory", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47691", " - f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47692", " - nfsd: return -EINVAL when namelen is 0", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47737", " - nfsd: call cache_put if xdr_reserve_space returns NULL", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2023-52917", " - ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47749", " - RDMA/cxgb4: Added NULL check for lookup_atid", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47735", " - RDMA/hns: Fix spin_unlock_irqrestore() called with IRQs enabled", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47750", " - RDMA/hns: Fix Use-After-Free of rsv_qp on HIP08", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47751", " - PCI: kirin: Fix buffer overflow in kirin_pcie_parse_port()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47693", " - IB/core: Fix ib_cache_setup_one error flow cleanup", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47694", " - IB/mlx5: Fix UMR pd cleanup on error flow of driver init", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47695", " - RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47752", " - media: mediatek: vcodec: Fix H264 stateless decoder smatch warning", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47753", " - media: mediatek: vcodec: Fix VP8 stateless decoder smatch warning", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47754", " - media: mediatek: vcodec: Fix H264 multi stateless decoder smatch warning", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47696", " - RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47755", " - nvdimm: Fix devs leaks in scan_labels()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47756", " - PCI: keystone: Fix if-statement expression in ks_pcie_quirk()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47697", " - drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47698", " - drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47728", " - bpf: Zero former ARG_PTR_TO_{LONG,INT} args in case of error", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49861", " - bpf: Fix helper writes to read-only maps", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47757", " - nilfs2: fix potential oob read in nilfs_btree_check_delete()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47699", " - nilfs2: fix potential null-ptr-deref in nilfs_btree_insert()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47700", " - ext4: check stripe size compatibility on remount as well", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47701", " - ext4: avoid OOB when system.data xattr changes underneath the filesystem", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49850", " - bpf: correctly handle malformed BPF_CORE_TYPE_ID_LOCAL relos", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47702", " - bpf: Fail verification for sign-extension of packet data/data_end/data_meta", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47703", " - bpf, lsm: Add check for BPF LSM return value", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49851", " - tpm: Clean up TPM space after command failure", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47723", " - jfs: fix out-of-bounds in dbNextAG() and diAlloc()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49852", " - scsi: elx: libefc: Fix potential use after free in efc_nport_vport_del()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47720", " - drm/amd/display: Add null check for set_output_gamma in", " dcn30_set_output_transfer_func", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47704", " - drm/amd/display: Check link_res->hpo_dp_link_enc before using it", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49853", " - firmware: arm_scmi: Fix double free in OPTEE transport", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47705", " - block: fix potential invalid pointer dereference in blk_add_partition", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47736", " - erofs: handle overlapped pclusters out of crafted images properly", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47706", " - block, bfq: fix possible UAF for bfqq->bic with merge chain", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49855", " - nbd: fix race between timeout and normal completion", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47707", " - ipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47708", " - netkit: Assign missing bpf_net_context", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47709", " - can: bcm: Clear bo->bcm_proc_read after remove_proc_entry().", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47710", " - sock_map: Add a cond_resched() in sock_hash_free()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47711", " - af_unix: Don't return OOB skb in manage_oob().", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47712", " - wifi: wilc1000: fix potential RCU dereference issue in", " wilc_parse_join_bss_param", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47713", " - wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47730", " - crypto: hisilicon/qm - inject error before stopping queue", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49856", " - x86/sgx: Fix deadlock in SGX NUMA node search", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47714", " - wifi: mt76: mt7996: use hweight16 to get correct tx antenna", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47715", " - wifi: mt76: mt7915: fix oops on non-dbdc mt7986", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49857", " - wifi: iwlwifi: mvm: set the cipher for secured NDP ranging", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47738", " - wifi: mac80211: don't use rate mask for offchannel TX either", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47731", " - drivers/perf: Fix ali_drw_pmu driver interrupt status clearing", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-49862", " - powercap: intel_rapl: Fix off by one in get_rpi()", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47716", " - ARM: 9410/1: vfp: Use asm volatile in fmrx/fmxr macros", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47717", " - RISC-V: KVM: Don't zero-out PMU snapshot area before freeing data", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47721", " - wifi: rtw89: remove unused C2H event ID RTW89_MAC_C2H_FUNC_READ_WOW_CAM to", " prevent out-of-bounds reading", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47732", " - crypto: iaa - Fix potential use after free bug", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47718", " - wifi: rtw88: always wait for both firmware loading attempts", "", " * Oracular update: v6.11.2 upstream stable release (LP: #2089033) //", " CVE-2024-47724", " - wifi: ath11k: use work queue to process beacon tx event", "", " * Oracular update: v6.11.1 upstream stable release (LP: #2089020)", " - powercap/intel_rapl: Add support for AMD family 1Ah", " - powercap/intel_rapl: Fix the energy-pkg event for AMD CPUs", " - cpufreq/amd-pstate: Add the missing cpufreq_cpu_put()", " - netfilter: nft_socket: Fix a NULL vs IS_ERR() bug in", " nft_socket_cgroup_subtree_level()", " - ASoC: amd: acp: add ZSC control register programming sequence", " - nvme-pci: qdepth 1 quirk", " - USB: serial: pl2303: add device id for Macrosilicon MS3020", " - powercap: intel_rapl: Change an error pointer to NULL", " - Linux 6.11.1", "", " * Oracular update: v6.11.1 upstream stable release (LP: #2089020) //", " CVE-2024-47671", " - USB: usbtmc: prevent kernel-usb-infoleak", "", " * Oracular update: v6.11.1 upstream stable release (LP: #2089020) //", " CVE-2024-46869", " - Bluetooth: btintel_pcie: Allocate memory for driver private data", "", " * CVE-2024-53164", " - net: sched: fix ordering of qlen adjustment", "", " * CVE-2024-53103", " - hv_sock: Initializing vsk->trans to NULL to prevent a dangling pointer", "" ], "package": "linux", "version": "6.11.0-17.17", "urgency": "medium", "distributions": "oracular", "launchpad_bugs_fixed": [ 2093643, 1786013, 2091744, 2091184, 2093146, 2085406, 2089684, 2090932, 2085485, 2089357, 2089306, 2091655, 2091655, 2091655, 2091655, 2091655, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091650, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091649, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091645, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091629, 2091386, 2091990, 2089327, 2089113, 2086587, 2086606, 2085950, 2085944, 2087853, 2087983, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089152, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089068, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089052, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089033, 2089020, 2089020, 2089020 ], "author": "Stefan Bader ", "date": "Thu, 16 Jan 2025 22:38:59 +0100" } ], "notes": "linux-tools-6.11.0-18-generic version '6.11.0-18.18' (source package linux version '6.11.0-18.18') was added. linux-tools-6.11.0-18-generic version '6.11.0-18.18' has the same source package name, linux, as removed package linux-headers-6.11.0-14. As such we can use the source package version of the removed package, '6.11.0-14.15', 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." } ], "snap": [] }, "removed": { "deb": [ { "name": "linux-headers-6.11.0-14", "from_version": { "source_package_name": "linux", "source_package_version": "6.11.0-14.15", "version": "6.11.0-14.15" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null }, { "name": "linux-headers-6.11.0-14-generic", "from_version": { "source_package_name": "linux", "source_package_version": "6.11.0-14.15", "version": "6.11.0-14.15" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null }, { "name": "linux-image-6.11.0-14-generic", "from_version": { "source_package_name": "linux", "source_package_version": "6.11.0-14.15", "version": "6.11.0-14.15" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null }, { "name": "linux-modules-6.11.0-14-generic", "from_version": { "source_package_name": "linux", "source_package_version": "6.11.0-14.15", "version": "6.11.0-14.15" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null }, { "name": "linux-tools-6.11.0-14", "from_version": { "source_package_name": "linux", "source_package_version": "6.11.0-14.15", "version": "6.11.0-14.15" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null }, { "name": "linux-tools-6.11.0-14-generic", "from_version": { "source_package_name": "linux", "source_package_version": "6.11.0-14.15", "version": "6.11.0-14.15" }, "to_version": { "source_package_name": null, "source_package_version": null, "version": null }, "cves": [], "launchpad_bugs_fixed": [], "changes": [], "notes": null } ], "snap": [] }, "notes": "Changelog diff for Ubuntu 24.10 oracular image from release image serial 20250129 to 20250224", "from_series": "oracular", "to_series": "oracular", "from_serial": "20250129", "to_serial": "20250224", "from_manifest_filename": "release_manifest.previous", "to_manifest_filename": "manifest.current" }